Enterprise performance, productivity & competitiveness

I have lost count of the number of times that I have heard people complain about how IT is undervalued, how the CIO deserves a place at the Executive table or at the Board table.  All too often this is because the proponents are unable to clearly and succinctly articulate the value proposition for the CIO function or for the more effective use of IT by an enterprise.

Combined with this, I also have lost count of the number of times that I have seen Board members eyes glaze over as soon as someone mentions that awful word “IT” or any of the associated technobabble.  Yet, these same people are often worried about the future of their enterprise and the impact of significant changes in the markets in which they operate, sometimes due to the capacity of their competitors to make more effective use of IT than they are able to!!

So, I have taken an interest in exploring and discussing these problems from a different angle, such as whether an organisation needs to be more innovative, and if so, how this might be achieved.

And in doing so, I have found that this brings me back to understanding enterprise performance, staff productivity and enterprise competitiveness.  Often times this then leads to thinking about the capabilities required by the enterprise, their adequacy for current and future demands, and ways in which the performance of particular capabilities can be improved.

Enter process innovation!

That is, here is where enterprise modeling comes and adds some value, by enabling an enterprise view of current and future capabilities and identifying the gaps, whether missing entirely or simply not performing adequately, identifying where the performance gap is and determining innovative ways of addressing this gap, sometimes involving process innovation.

And so, it has become increasingly evident to me that process innovation has a place in contributing to improved enterprise performance, improved productivity and increased competitiveness, and enterprise modeling offers tools, techniques, thinking models which enable an enterprise to tackle these sort of questions, these sorts of demands, these sorts of business change and transformation, most often combined with some commensurate systems transformation!

More business, less technical?

Enterprise modeling (or enterprise architecture) started off in the technology world, with the CIO and others needing to make sound investment decisions about enterprise wide infrastructure (such as mainframes, networks, etc).  These decisions involved resources which would support multiple change initiatives and where it would be “unfair” and “unjustifiable” for the initiating project to bear the full cost of the resource.  Equally, there was a need to ensure that these enterprise wide and longer-term investments would prove to be sustainable investments in situations where future project requirements were not well defined or understood.  Hence, the strong technical focus during the “childhood” years of enterprise architecture.

In its adolescent years, enterprise models incorporated business models AND technical models, such that the technical investments were informed by business considerations and were more “business aligned” or “business driven”.

In the early adult years (now), greater attention is being given to modeling business capabilities over technical capabilities.  Further, business architects are being more strongly valued and technical architects are being found  to be deficient in meeting the enterprise modeling needs in rapidly changing times, where businesses need to be able to respond to market disruptions in much shorter timeframes than was previously the case.

In such an environment, questions are starting to arise as to the balance of effort between modeling the business capabilities versus modeling the technical capabilities.   I recently indicated that I expected the demands for technical modeling would reduce due to greater use of “cloud services”, and then was given cause to provide the following explanation for why I thought so.

With the increasing alignment between business and technical capabilities, there will be less need to architect the technical capabilities. These will progressively become tightly defined capabilities which can be easily and effectively used by business capabilities.

Business agility will come through the flexibility to mix and match business and technical capabilities to meet changing market needs. Put a different way – agile businesses will become plug-and-play business capabilities with the supporting technical capabilities being enablers rather than barriers – architecture is needed moreso when there is poor alignment.

What do you think?

An invaluable pattern

One of the most useful patterns (models) in enterprise modeling can be summarised as SICOCUO.

SIPOCUO For those who are familiar with IDEF0, you will be familiar with IPO – input, process, output

For those who are familiar with Six Sigma, you will be familiar with SIPOC – supplier, input, process, output, customer

SICOCUO is a further extension of this thinking, firstly be extending beyond customer to include use, outcome

An important element in the design and delivery of an output is an understanding of its prospective use by the customer and the outcomes realised through this use.  The simplest way to describe this is in terms of an car manufacturer and a purchaser of a car. The intended use by the customer – whether to transport a family, to participate in a car rally, or to distribute bales of hay to livestock, dictates a range of the features and characteristics which need to be designed into the car and which influence the processes (and capabilities) required to deliver cars which will be valued (and hence purchased) by prospective customers.

Hence, the extension of SIPOC to SIPOCUO.

SICOCUO is a variant to SIPOCUO in as much as it treats the focus as a capability rather than a process.  By focusing on a capability, appropriate attention to be given to all elements required for the effective performance of the capability and hence the organisation deploying this capability.

Hence, the final formulation:

  • Supplier
  • Input
  • Capability
  • Output
  • Customer
  • Use
  • Outcome

This pattern can be used at any level of an organisation.   It is quite valuable in distinguishing the responsibility of CXO and LOB Execs to realise the benefits from using a system versus the responsibility of the CIO to deliver a quality system.  It is equally valuable in positioning the current operation of an enterprise, its overall outputs (products or services) and the outcomes sought by its chosen customer segments.