What does a project on a high-level operating model need to say about IT?  And what does it need to deliver to the IT architecture team?  This is the focus of this blog.   The detailed work on IT architecture and an operating model for the IT function will be done by the head of IT with support from an Enterprise Architect.  So the work that is done on a higher level operating model must take into account what the head of IT and his or her enterprise architect need.  I suggest the following

1. The head of IT will need information about the strategy and the broader operating model that IT is supporting. This, of course, is the reason for creating an operating model in the first place.  It translates strategy into a high-level design for the operations and the organization, that can then be handed down to each function and each business unit, who will then do the next level of design.
2. The head of IT needs to know who the business owner is for each important application.  With this information, the head of IT will know who to interact with, who to deliver value to and, hence, who are the prime customers of the IT architecture that will be created.
3. The head of IT needs to know which of the software applications need to be part of an integrated enterprise system and which can standalone.  Since it is only IT that can mastermind the integration, it is important that IT knows which applications need to be integrated.  In this context, integration means that the applications can communicate seamlessly, that the data architecture and coding is the same in each application, etc.   Those applications that do not need to be integrated may not even need to be included in the remit of IT.  It is possible that the business owner can be responsible for sourcing, maintaining and running these applications, in the same way that employees are often responsible for their mobile telephones and the applications they have on them.  For example, an engineering team may have a CAD/CAM application supporting their design work which is sourced and maintained by the engineering team.
4. The head of IT needs to know which software applications will need to be bespoke and whether IT will be expected to develop or commission these bespoke solutions.   Typically, the only applications that need to be bespoke are those that help create a competitive advantage for the company.  Hence, it is the operating model team, supported by the strategy people who are in the best place to identify where tailoring is likely to create advantage.  Everywhere else it is normally best to use a standard package and change the internal processes to fit the standard.  When dealing with business owners, IT needs to know whether to support or resist the special requirements that business owners are likely to request.

This list of four outputs from a high-level operating model project is all that needs to be done on information systems: everything else can be delegated to the IT steering committee – the next level of operating model design.  If you have a different view, please comment below.

Since I believe that operating model work should result in something visual – map, chart, table, etc – my co-authors and I (of the book Operating Model Canvas) have developed a high-level IT blueprint to capture these four points.  Lots of readers of this blog will have their own views about what the term “IT blueprint” means – and please feel free to comment.  This is a “high-level” IT blueprint, and it has been developed without much attention being given to the other forms of IT blueprint.

ch3-p12-it-blueprint-2

The high-level IT blueprint is a table with the main steps in the value delivery chain listed along the top axis and the main organizational units listed down the side axis.   As Mikel Gutierrez likes to say, “when you match the organization against the processes, something magical happens”.  The magical thing that happens is that you are able to visualize the following design choices.

First, you can identify which organizational unit is involved in each of the steps of the value delivery chain.  So, in the example, the step “design product” involves customers/distributors, sales and specials unit: to design a specials product, the specials unit who will do the design must know what the customer or distributor wants and what the sales team has committed to the customer.

Second, you can decide whether this step requires a software application (or sometimes more than one).  The “design product” step does require software support.

Third, you can decide which organizational unit is the business owner of the application: it may be a committee of all of the units; it may be one unit; or it may be possible to sub-divide the application into two or more sub-applications and have multiple business owners.  In this case, the specials unit was the business owner.

Fourth, you can decide which software applications need to be integrated into the enterprise system (the pink boxes in the chart).  Typically these are the applications that touch multiple parts of the organization.  The software for designing specials did not need to be integrated into the enterprise system.

Fifth, based on your understanding of where, in the value delivery chain, competitive advantage is created, you can identify which applications are likely to need to be bespoke. The design application for specials was expected to be a source of advantage, hence it would need to be bespoke.

And, when you have made all of these choices, and recorded them on the table, you have produced  a high-level IT blueprint: a single page that delivers to IT the information that IT needs about the IT implications of the operating model.   Of course, you can rarely get it all on one page – mainly because you will typically have multiple value deliver chains.  However, you can normally produce a high-level IT blueprint with only a handful of pages.