On Importance of Information and Technology in the Operating Model Design

This article concludes the series in which we have explored the six domains presented in the 2016 book Operating Model canvas. The purpose was to expand on each area and give some advice on how to populate each one with particular emphasis on linkage to value.

Information represents how the operating model considers the management of technology, information and data. In most cases this equates to information technology; it is interesting to note that in the past some organisations used to refer to their IT as IS (Information Systems) or even IS&T (Information Systems & Technology) so this Information domain clearly makes sense.

IT as a subject in operating model design has some issues that we need to explore; one of which is that often that transformation is led by technology, or that transformation equals some change in technology. Thus the transformation becomes the implementation of a system. The nascent ‘digital revolution’ is one perfect example. Many established companies jumped on various e-platforms simply because ‘they are there’. The goal for many became to implement the technology, and in doing this the principles of identifying client value and then tracking that back to what is needed to deliver that value, have been lost in the process.

Careful operating model design thinking steps back from the excitement of technological innovation and asks itself “what does one actually want to achieve through IT”. In most instances, it will be necessary to consider the intended impact of IT in the overall value delivery chain and the financial results. Several options of IT deployment are available and each will produce different impacts on value delivery and financial metrics.

There are three main traditional options on implementing one’s I.T. :

Build

Adapt and Configure

Purchase and Use

These options vary in cost and time to deploy them and have their constraints and issues. In building your own you can follow the idea that we present in these series of articles – of enabling value chains to maximise value; this is of course costly and requires volume and substantial activity to justify.

The opposite is purchase and use, whereby you do business according to how the software developer determines. In this process, you frequently lose control of the creativity of the operating model – you get given a set model to implement. The end result is a lack of differentiation and a commoditised Porter’s cost leadership approach – making money by being more efficient than others through scale while doing things in essentially the same way.

The half-way house is buying a solution and then getting certain things changed to fit what you want to do – adapt and configure. This enables a compromise between differentiation of value provision and high costs. Although this sounds a good idea on the surface, it itself has the issue that bespoken additional development cost money – lots of money, emphasised by the fact that the skills required are in the minds of solution integrators on high day rates. Additionally, many have found that problems occur when the vendor upgrades a version with older versions falling out of support; then you have to upgrade your bespoke content all over again – more cost.

More recently, a fourth option has appeared due to technological advancement with the development of cloud, web services and API Application programme interfaces – stitch and integrate. You buy software services and then “stitch” them together. This is effectively a cheaper version of build as described above with some constraints of having to use what is provided also, but at least you have some choice in terms of functionality and process organisation. There are risks of continuity of service, security and data integrity with this option that need to be mentioned but can be read about elsewhere.

To be sure, this appears a bit of a weighing up exercise with issues pulling us in different directions. Little surprise then that, unfortunately, many non-IT executives see IT as part of a problem, not a solution.

In operating model design I.T. can be a constraint, a negative force, or an enabler, a positive force. A new technology can create new ways of doing things or a shift in an operating model but conversely it can be restricting with legacy systems hold a company back.

Like all of the other sections in the canvas, we should start with value and work back through value chains. Yet in the case of IT, we need to challenge the way technology gives those value chains new ways of delivering value. Technology always should have a value check – just because we can do something clever doesn’t necessarily mean we should do it.

This ‘value check’ process should be circular, linking value creation back to IT to see what functionality creates that value and assessing whether it is still required and whether it can be done better through new enablers.

Even though we live today in a world of so called digital transformation and disruption (to use a couple of well-worn buzz words of 2018), I.T. should still be seen as a means to an end or a means to deliver or add value, not a reason to transform. Start with end-user value and challenge technology – then map out how IT solutions can implement that value within constraints of cost, or risk the danger of creating an operating model that becomes ‘unfit for its purpose’.