Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Defining high level organizational architectures

2,227 views

Published on

Presentation that I held October 10, 2011 at the European Organisation Design Forum meeting in Frankfurt, Germany. See my blog for more information about the meeting.

Published in: Business, Economy & Finance
  • Be the first to comment

Defining high level organizational architectures

  1. 1. Defining high levelorganizationalarchitecturesNicolay WorrenWorren Consultingwww.organizationdesign.net
  2. 2. CaseCompanyLeading Nordic financial services group Executive Mngmt team CFORated as one of the world’s safests banks byGlobal Finance MandateEmployeesApprox. 14 000 Project teamCustomersMore than 2.3 million retail customers Advisor/ ExternalMore than 200 000 corporate customers Internal consultant consultant Thats me © Nicolay Worren
  3. 3. Project mandate Decision approved in executive mngt meeting January 19, 2011“One has attempted to clarify the high level roles with associated responsibilitiesin the Group Governance document. As a follow-up to this, each area, including sub-units, should describe and clarity their roles and responsibilities according to theallocation of roles given in the the Group Governance document. It is particularlyimportant to distinguish between delivery roles and Group roles of the differentareas as well as the interfaces between the areas. It is natural that HR willprovide coordination and quality assurance in carrying outthis task.” © Nicolay Worren
  4. 4. What the Group Governance document said Board of Directors Business Area (BA) Support Unit (SU) Group Audit Staff Function (SF) Group chief executive Marketing and Communications Corporate Centre Group Finance and Risk HR Management Retail Large Corporate Non-life Life Insurance and Asset Insurance and Markets Operations IT Banking and International insurance insurance management Division Country X © Nicolay Worren
  5. 5. Some constraints Existing work having been done to define “Unclear roles” identified governance principles as key risk in Operational Risk CommitteePrevious reorganisationhad led to combination of Limited willingness instaff and support roles business areas to participate © Nicolay Worren
  6. 6. Discussion: How would you have proceeded?Example:- What steps would you have followed?- What data would you have gathered?- How would you have analyzed the data?In groups of 3, spend a few minutes discussing this © Nicolay Worren
  7. 7. Guidingprinciples © Nicolay Worren
  8. 8. The notion of architecture is increasingly seen as a powerful metaphor for organization design © Nicolay Worren
  9. 9. A system’s architecture can be operationalised by considering its functions and structure Function (Functional Requirement) Structure (Design Parameter) Supply O2 to blood andBiological system Lung remove CO2 from bloodPhysical system Transport passengers Bus Organization Support IT users IT Help Desk © Nicolay Worren
  10. 10. One way to examine a design is to map thecorrespondence between functions and structure Function (Functional Requirement) Structure (Design Parameter) Maximize quality care Many physician visits, local Provide presence, expensive equipment, health care etc. services… Optimize costs Fewer physician visits, centralized care, less expensive equipment, etc. “Coupling” Key assertion: Coupling decreases (system) performance (By the way, in some contexts, ambidexterity can be defined as the ability to remove coupling between functional requirements) © Nicolay Worren
  11. 11. The actual implementation (and presentation) of a design may differ from the optimal solution How it is presented How it actually works… What would be ideal… © Nicolay Worren
  12. 12. How weproceeded © Nicolay Worren
  13. 13. Steps 3 months Analyse and Write report Gather data V.01 to V.17… interpret• Interviews with • Describe each of the • Present/distribute and representatives from all 14 units update based on areas • Create detail + high feedback from all areas• Process documentation level FR-DP matrix • Link to and integrate• Consider other banks (35 FRs) with other ongoing • Create interface initiatives diagrams for 14 units © Nicolay Worren
  14. 14. The first step was to consider why a bank exists and what it does Broken down to 35 more detailed FRs … Sell financial services and products Develop financial services and products Maximize economic profit by providing Provide delivery capacity financial services Manage risk, secure funding, and allocate capital Ensure compliance to guidlines, policies © Nicolay Worren
  15. 15. We then mapped the units and their interfaces - SIMPLIFED EXAMPLE - CFO Credit limits LoanGroup Finance and Funding products Individual Retail BankingRisk Management clients Transactional services Operations (For details about this methodology, see my 2006 ODF presentation or my textbook, which contains a chapter about subunit interfaces) © Nicolay Worren
  16. 16. …and attempted to draw units and their functions © Nicolay Worren
  17. 17. We noted several deviances from the principles outlined in the bank’s governance document Busines Support Staff Areas Units Units 5 4 Sell financial services and products Develop financial services and products 3 Provide delivery capacity 1 2 Manage risk, secure funding, and allocate capital Ensure compliance to guidelines, policies © Nicolay Worren
  18. 18. We then indicated that it is possible to consider a model with more independent functions… Sales Product Support Staff units units units units Sell financial services and products Develop financial services and products Provide delivery capacity Manage risk, secure funding, and allocate capital Ensure compliance to guidelines, policies © Nicolay Worren
  19. 19. …and asked what advantages such a model might confer Decouple product development and sale /distribution Sales Product Support Staff units units units units Sell financial services and products Consolidate transactional processes Develop financial services and products Provide delivery capacity Manage risk, secure funding, and allocate capital Separate staff and Ensure compliance to guidelines, policies support roles © Nicolay Worren
  20. 20. 0° self-evaluationWhat I think we may have accomplished What I would do differently next timeIncreased understanding for how the bank Tried to use more goal oriented FRsworks and the gap between intended and (increases saliency of «coupling»)actual role allocations Differentiate more strongly betweenContributed to a process of reflection re. operational and financial interdependenciesrole requirements and potential roleconflicts (?) Perhaps attempt a bit more strongly to gain more involvement among areas at earlyIdentified some key “fault lines” in the stagecurrent organisational architectureRaised awareness re. an alternative, morescaleable organisational architecture © Nicolay Worren
  21. 21. This was a collaborative projectThe client has not been named to preserve confidentiality butgave permission to use the case. I gratefully acknowledge this opportunity. © Nicolay Worren
  22. 22. For more information My textbook where I extend on the principles described here will be published shortly by Pearson Education. I will post updated information on my blog: www.organizationdesign.net I will publish an article about organisation design of banks in the upcoming special issue of People & Strategy. You can view my 2006 ODF presentation here: http://www.slideshare.net/NicolayWorren/managing -interdependencies-in-complex-organizations- 2406305 The approach described here is inspired by systems theory as described by Ackoff & Emery (1973) and the axiomatic design approach developed by Suh (2001). I also recommend the 1997 article by Gresov & Drazin in the Academy of Management Review (Issue 2, p. 403-428 ) © Nicolay Worren

×