Category: Capability Engineering

Information Management in a Process-based Management Paradigm

I conducted a very interesting experiment this week.  I presented a basic information management roadmap workshop at a business process management (BPM) conference.  It went quite well and I think (and know from feedback) that most people got something of value out of it.  That’s not to say it didn’t have the awkwardness of an information management guy presenting to a process-focused audience.  It was a challenge.  

But it was really an experiment in cross-dicipline workshopping.  I have very little interest in promoting information management as a function these days.  I agree that the part of most organisations that ensures that information is invested in as an asset simply doesn’t exist (hint: it isn’t I.T.) but I’m more interested in what I call “capability engineering”.

My work on the ManageWithoutThem Management Model has – among other themes – determined that information management IS management.  The process-based management paradigm has enormous value but is basically being eroded by technological advancements and network intelligence that puts outcomes (and in particular information outcomes) ahead of the processes that produce them.

The very idea of a business process management (BPM) workshop disturbs me slightly.  As does an information management (IM) workshop.  I’m more interested in developing hard-to-replicate business capabilities that combine people, process, information, and technology.  

The whole concept of BPM conferences, information management conferences, and any other conference based on a functional view of organisations is completely at odds with the capability-based governance view that says: start with what you want to be able to do for your customers or with your assets and decide who is responsible – and then let them coordinate across functions.

For those that requested the workshop materials the slides and hand-outs are below: 

 

 

The year of capability engineering keeps on giving

After my previous post on “The end of IT alignment“, which was really a post about capability-based governance models, I get this little gem in my inbox this morning:

Second, creating meaningful differentiation requires capabilities that are almost always cross-functional. For example, building a competitive global brand requires more than a marketing skill set. It requires a plethora of competencies, including managing digital media and tracking consumer insights (both of which involve IT), relationship building (which requires good customer service and interface design), ethnographic insight and employee engagement (enlisting talent and HR), highly targeted product design and development (engaging R&D), and more.

Third, functions have a natural tendency to become isolated organizational silos, focusing on their own excellence and performance instead of the company’s strategy. The specialists’ natural imperative—to be excellent in everything they do—leads to incoherence. Many functions have devoted a significant part of their budgets over the years to initiatives and technologies that make them world-class, but that have very little to do with the true drivers of the company’s success.

Although all these problems can be addressed in small ways, none of them can be fully resolved under the current functional model. In that context, it seems increasingly likely that the functional model is obsolete. But if so, what might replace it?

Read it all here.

The end of IT alignment

The language of IT alignment has to end. It’s no longer serving any purpose except to isolate disciplines that no longer need to be managed in isolation.

The convergence of the commoditisation of IT and the socialisation of business means that IT in its strictest purest sense has won. Paradoxically it also makes IT completely unimportant as a competitive differentiator.

IT is available cheaply to anybody who wants it. IT can be acquired easily in packaged form, or as a service, through any number of cloud or “… as-a-service” vendors. Many would argue that this doesn’t solve all problems – but to quote the old joke about alcohol, neither does milk.

For IT systems that are not easy to acquire there are strong incentives for IT service providers and outsourcing organisations to build them. You might pay more than you’d like but that’s because it’s hard to manage these guys not because of any real scarcity.

The so-called socialisation of business is a trend that slightly trails the commoditisation of IT. In fact, the consumerisation of IT appears to drive both. While it might have once been the IT departments job to drive adoption of IT to improve efficiency this is no longer the case. IT departments are now more likely to be seen as holding back the adoption of IT.

So why does this mean the end of business and IT alignment? Because there isn’t any “business” and “IT” to align! It’s always been a misnomer. Firstly, IT’s view that there was “us” in IT with all this complexity and then there was one bug lump out there called “the business” was always a farce. “The business” was just shorthand for a generic “them” that moved and shifted like bad requirements.

On the other side there was “The business” – rich and complex and important. In “the business” there were performance incentives, real customers, governance considerations, all that important people management and cultural change, etc. But this side of the fence had some delusions too. Over the last 20-30 years much of the value that business units mentored was shifted into IT systems. But unfortunately this meant managers thought it was shifting to IT.

When I asked who is responsible for the information in the IT systems during a recent meeting everybody in the room pointed to the IT guy. When I clarified and added that I meant the real details of what the information means they still – and they always do in my experience – pointed to the IT guy.

You see somewhere along the line people started believing that if something passed through an IT system it was suddenly owned by IT. But it got even worse than that. Because these “IT alignment” problems went on for so long, and nobody ever fixed them, and because IT was the service provider and “the business” was “the customer”, the IT team compensated.

So not only did everything that pasted through an IT system become owned by IT, everything that was “detailed” became an IT problem. Let me explain. The thing with IT systems is that they persist. If you have a human system you need to teach the new humans the system so the system can continue to operate when the old humans leave. This process keeps the system alive. IT systems, except for some overworked back-end humans, don’t need this. IT systems continue to operate regardless of the passing of knowledge to new humans.

Over time this has meant that where systems are built on technology the detailed knowledge of the system are lost. Nobody knows the details of the system. However, when things went wrong somebody had to find out those details. The IT groups had the keys to the back-end of the system so were able to find out how the system worked.

Even though IT people could find out how the system worked it didn’t mean that they were the cause of the problem. Sometimes the world had changed and the system didn’t work in the new world. But at the end of a long investigation the only person who could fix the problem was the one person who had spent time looking at the details.

This process had an interesting effect on the users of IT systems. Not only did they think that things that passed through IT were now owned by IT, but they thought that “the details” were owned by IT. In fact, I think that in many contexts the term “technical” and “detailed” have become interchangeable.

I’ll skip over the process where all of the people with “technical” knowledge – including detailed knowledge of “the business” – were outsourced. That’s just progress – it’s done – get over it. But it’s an important step in the story. Because it’s now possible to acquire the IT components of your business easier they are no longer a competitive differentiator. Trouble is because the IT components still have value, and your competitors can acquire them, they are a business imperative.

To actually differentiate you have to do what you’ve always had to do, build hard-to-replicate capabilities that combine people, process, information, and technology. It’s the integration of all of these that creates value. So why all the talk of “IT Alignment” in the first place? Who knows! Growing pains?

So, What’s next?

Because IT is easy to acquire, and because business units can’t seem to manage the details of how their processes operate, and because it’s integrated capabilities that drive competitiveness, a complete governance change needs to occur. It is no longer effective or necessary to have a primary governance separation between business functions and IT.

But hang on! I could also track a whole history of cross-functional collaboration within organisations. Every single problem in every single organisation appears to be solved by “a cross-functional team” right? In fact, the whole structure of management education has become about educating future managers that a. All organisations are made up of common functions (IT, HR, Finance, etc) and b. that their job as managers is to coordinate across these functions.

This process, that builds organisations in which every collaboration of value is an exception and then creates managers who are rewarded for intervening is bullshit (!). Our governance models need to change.

The thing that needs to change first is to give people responsibility for capabilities. The end-to-end responsibility for something regardless of the separation between “the business” and IT is the very first step towards “alignment”. If you haven’t done this stop working on alignment issues until you do.

Business Capability Maturity Model – Simplified

With this year the year of capability engineering I spent last night building out a simplified maturity model for how new business capabilities might evolve.  This model is a lot of thinking packed into a single artefact, and still a work in progress.

All new business capabilities got through a number of maturity levels before they are a recognised capability of the organisation.  Aspirational capabilities identified and sponsored by the executive team also go through the same journey; however, there is in this case greater visibility of the progress through maturity levels to the executive team.

Capability Maturity Model - Simplified

Level 1 – No capability

No formal capability exists.  Although competencies may exist in the organisation there is:
1.     No explicit decision on the level of standardisation / centralisation required. 
2.     No formal accountably for the capability within governance structures
3.     No agreed understanding of the capability and how it contributes to the operating model at the executive level
4.     No explicit references to the capability in strategic planning (or equivalent) processes
5.     No understanding of how the capability contributes to the product strategy or to the development and delivery of products / services

Level 2 – Isolated capability

An isolated capability exists.  This isolation can appear in any or all of the following dimensions:
1.     Isolated application of the capability to solve a single or small number of business problems
2.     Recognition of duplication where superficially similar pockets of capability are identified throughout the organisation but they are isolated from one another
3.     New or business critical application of the capability is built or identified but considered an exception to one or more policies, standards, or organisational behaviours despite having clear business benefits

Level 3 – Servicing capability

Integration of an isolated capability with the organisation begins with establishing service managed around the capability.  This creates dependencies with other business units and makes the capability critical to operations.
The use of service management principles achieves the following:
1.     Creates internal “customers” for the capability
2.     Allows the operation of the capability to be separated from the services; providing an opportunity to leverage the services of other business units to deliver the capability’s services. 

Level 4 – Strategic capability

The executive team explicitly reference the capability during decision-making and the strategic planning (or equivalent) process.

Level 5 – Differentiating capability

The relationship between the capability and how the capability contributes to the product strategy and to the development and delivery of products / services is managed.
 

2013 – the year of “Capability Engineering”

Highlight Capability Engineering in the MWT Components

Image above is from my MWT notes ~2005.  Finally getting to build it out as a proposition.

Page 2 of 2

Powered by WordPress & Theme by Anders Norén