In Enterprise Architecture as Strategy: Creating a Foundation for Business Execution (Harvard Business School Press, 2006), authors Jeanne W. Ross, Peter Weill, and David C. Robertson established a framework for the development of a company’s (or business unit’s) operating model. The model is a two-by-two matrix, with business-process standardization and business-process integration (the latter defined as the degree to which units are linked through shared data) as the framework’s axes. Where a company is located in this matrix determines its optimal operating model: “coordination” (a high degree of integration coupled with a low degree of standardization), “unification” (high integration, high standardization), “diversification” (low integration, low standardization), and “replication” (low integration, high standardization).
ING found this framework compelling and decided to use it as the basis for its own customized framework for the definition of IT operating models, which would guide related technology decisions. Standardization and integration would remain the key variables, per the Ross/Weill/Robertson framework. But ING defined them differently: standardization would refer to the similarity of transactions across countries or business units, while integration would refer to the similarity of outputs. ING called the four resulting IT operating models “coordinated,” “shared,” “isolated,” and “replicated.” (See Exhibit 1.)
A coordinated model would be the default choice for situations with high integration and low standardization—for example, multiple countries using their own distinct software to produce standardized output, such as a prescribed format for reporting key risk ratios. A shared model would be the default for situations combining a single solution and a single output, with little or no need for local customization—for example, multiple countries using a single general ledger to comply with GAAP reporting standards. An isolated model would serve situations demanding multiple solutions for many different types of output—for example, individual countries using their own unique systems for tax reporting or local sales support. Finally, a replicated model would be the default for situations in which a single solution satisfies multiple types of output—for example, a single packaged software solution for retail banking that is used across countries but is customized to meet different countries’ individual needs.
With this framework in place and the models defined, ING now had an established and transparent logic for decision-making. But other factors would influence those decisions as well. Before applying a prescribed model to a specific situation, ING would ensure that certain preconditions were met. For a coordinated model, for example, ING would confirm that the right governance was in place to ensure the implementation of common metrics across the different systems. For a shared model, ING would ensure that the governance organization could maintain the shared solution and that the costs of adjusting the shared system to different local requirements were low. For an isolated model, ING would confirm that there was sufficient local scale to justify a unique solution and that there were sufficient local skills and resources available to implement and maintain it.
ING would also conduct a thorough cost-benefit analysis. When judging the suitability of a shared model, for example, ING would weigh the potential economies of scale against the costs of the coordination effort and the greater financial impact if the solution were to fail. For an isolated model, it would weigh the flexibility and agility gained by each individual market against the greater run and maintenance costs and the costs of achieving the necessary cross-market transparency (for reporting purposes or to support selling efforts beyond the local market, for example).
Finally, ING would consider the risks associated with a model along with ways to mitigate those risks. (See Exhibit 2.) The risks of an isolated model—a lack of transparency and the potential for choosing the wrong solution owing to a lack of knowledge—could be lessened by creating a centralized reporting process to track isolated IT systems and by allowing isolated solutions only when local IT had met specific thresholds for skills and capabilities. The risks of a coordinated model—including a high risk of errors due to heightened complexity—could be mitigated by keeping the system structure as simple as possible and clearly defining the interfaces.