Defining high level organizational architectures

Defining high levelorganizationalarchitecturesNicolay WorrenWorren Consultingwww.organizationdesign.net

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

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

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

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

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

Guidingprinciples © Nicolay Worren

The notion of architecture is increasingly seen as a powerful metaphor for organization design © Nicolay Worren

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

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

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

How weproceeded © Nicolay Worren

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

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

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

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

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

…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

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

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

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

http://www.organizationdesign.net	457
http://feeds.feedburner.com	9
http://translate.googleusercontent.com	1

Defining high level organizational architectures

by Nicolay Worren on Nov 12, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 467

Statistics

Defining high level organizational architectures — Presentation Transcript