Corporate IT has a hard time doing anything right. In most companies it is so dammed complex and costly to change IT Systems. Let’s take a look at the current business transformation practice in respect to IT.

bridge

Let’s map out the traditional path by looking at the example of a typical mid sized company with between 300 M€ to 2 B€ of Revenue p.a. This company spends about 80% of expenditure on ERP related operations and projects year by year. Beside ERP there are other systems, an outsourced webshop, sales and supply chain specialist systems, some of them even cloud based. A typical total number of systems for a mid sized company will be at about 25 to 90 systems, not counting classical desktop applications (like MS Office, Adobe etc.). This number will go up into the hundreds for larger companies and thousands for global banks and conglomerates. The lower the number of systems given the same business complexity of companies, the better ordered the IT application landscape, i.e. the higher the readiness of IT is to support change.

Each of these 25 to 90 Systems link to the ERP system, in one way or another. The ERP system captures the valid data, the reliable data. It is the single source of truth for a company. That’s what its build for. If there are multiple ERP systems in one company, there is reason to worry. Multiple sources of truth lead to unreliable data, in-transparency and discussions about the quality of data, instead of discussion about solutions.

The ERP system has evolved over time: New lines of business (or product) have been added. Customers, who were supposed to be served only by one are now served by multiple business lines. Supply chain flows of goods should have been limited to go from the central distribution center to the point of sales, but  are now flowing from the point of sales to the distribution center, too, as inventory is redistributed across lines of business or point of sales. Every major change to ERP systems may violate yet another vital assumption that has been made in the initial implementation of the ERP system. A familiar dialogue, that lead to such a “violation” is going like this:

The Dilemma of an IT Manager

  • IT manager exasperated: “Well, you (business) said we should build the system around the assumption that all line of business will remain separate entities, with separate article master, deliveries and invoicing. Now these lines of business are merging? Our master structures do not support this change!”
  • Business manager slightly annoyed at the obstructionism: “There is huge potential with a line of business selling multiple products. We extend our offerings, drive sales, even our logistics costs are driven down by shipping the products in the same boxes. Just change it!”
  • The IT manager remembers his last training communications training course and shapes his message with a positive spin: “Oh, I see it. This will be huge. I am excited by this change, this way we can fulfill some requests of the guys in logistics, too. It will not be easy though, but let me work on a plan and get back to you next week.”

Next, the IT manager comes back with a clever solution. She knows she can not change master data structure. It is carved in stone, as most central algorithms rely on this specific data structure and data -once captured in ERP systems- is very hard and even next to impossible to convert to entirely new structures. So she comes back with an 80% solution. A work around, that fulfills the most pressing needs of business without changing the basic structures. This will make work for business and IT more complex and prone to errors, as new interfaces, algorithms and processes are build that consciously violate central assumptions under which the ERP systems have been build. Reporting will be impacted and more complex to interpret or extract, decreasing companies transparency. People need to be taught about these new “exceptions”. Still, offering no solution to business is not beneficial for IT management:

  • IT is there to support business. The voice of business is strong and usually better heard and understood in the hierarchy
  • A “can do” attitude is valued in all organizations. To be a “Nay” sayer is not a clever career choice
  • It is so hard to distinguish “constructive objection” from just “objecting all the time”
  • The benefits for the business appear reasonable, measurable and are even committed by business. The costs of a work around is abstract, not measurable. Who can value the costs of increasing “complexity” or loss of transparency? Who can measure increasing error rates and value the costs of the impacts of these errors?

Now image this fictional exchange between business and IT is going on in multiple units in the organization over month and years. All the time something new is requested. Some of this has never been foreseen. It all ends with a jumble of process and system solutions that are quite unmanageable for business and IT. Both ways the IT Manager looses: Either she is obstructing changes or increasing complexity makes work more tedious for everyone – that is the dilemma of IT Management. No matter what, IT will be seen under to be under delivering over time.

Process and System solutions degrade over time. 

It is not just systems that degrade over time, it is the whole fabric of process solutions and with it the ability for individuals to contribute. All this becomes a major drag on company performance.

After a while, even the most non process and IT minded CEO will take no more of this inhibition, as the gap between his plans and the ability to execute grows too large. At this point of time a clever IT Manager sees a window of opportunity for a complete revamp of processes and systems: She calls out the “burning platform“, i.e. she alerts senior executives of an existential threat to the company if the status quo is not changed. To continue with the status quo can not be a solution any more: “We need to do something now”. Once a process and system landscape is no longer fitting companies desired strategy or operating model the company is heading for a major revamp.

csi

The major corporate transformation program is handled as a major “one off” initiative, but actually reoccurs typically every 5 to 12 years, depending on the dynamics of the industry and mergers & acquisitions events (see Pfeffer, J. “Zone Management). The program will take a mid sized company let us say between 9 to 24 month and consume between 8 and 35 Mio. Euros.

At the beginning of the transformation, all the strategic directions and their implications for the operating model are gathered and broken down into a more or less coherent set of processes, which are in turn determining the system landscape. This is usually an analytical process driven by highly specialized consultants and supported by change management teams. Accelerators such as “best practice processes”, “fit gap workshops” or “conference room pilots” displaying limited prototypes are used.  Once all this analytical work is done, in about 3 to 9 months, the blueprint is signed off by the important stakeholders of the company and implementation starts. The work product arrives after a total throughput time of 9 to 24 month, on average.

All this time the world changes –  faster and faster because of digitalization. Business opportunities or threats arise, executives change, priorities change, financial quarterly targets need to be met. The “fit” of the new application and process landscape is already degraded during the implementation period, decreasing the return investment from the day the blueprint is signed off. Yet constant update of the blueprint during implementation time risks risks all three dimensions of successful project delivery: Budget, Time and Quality.

Experienced managers know of this degradation and provide the needed stability for the implementation team to succeed. These managers compromise on the strategic value of the transformation programme in order to get the work done. But this is the lesser of two evils: The alternative, meedling with the scope or fundamental decisions of the project, will accomplish chaos, budget overrun, instability and never ending “death marches”.

Over the course of a typical project, the rational of the transformation changes from “creating a competitive advantage” to “building a solid business core on which to build competitive advantage”. 

Once the new process and system core is delivered, it is already degraded in usefulness to the organization. Not outdated, but degraded. And it will degrade more and more over time, until a “burning platform” is called out and the organization is in for another iteration.

This cycle of stuttered innovation (aptly named CSI) results in companies making major updates to their operational, process and systems engines only every 5 to 12 years. This could be alright, if

  • enough flexibility is engineered into the process and application solution to allow minor but important changes during the time frame and
  • the company part of a slow moving industry without much innovation and
  • IT operations enable swift enough deployment of changes to the production systems

But the cycle of stuttered innovation is totally inadequate in a business environment of frequent change. Information Technology offers enormous business potential, but the way it’s used in most companies is totally contra-productive. So what to do about it? See next post.

Posted by frankthun

Management. Systems. Liberation

2 Comments

  1. […] Continuous delivery is the ability of an organization to work and deploy changes in small batches, deployed continually. This is no big deal, given the changes are small and insignificant, e.g. change a text description, move a field in an user interface. But it is a huge deal for complex changes, with huge interdependencies, e.g.structural changes to master data, reworked business processes featuring changes to document flow. Because of all these interdependencies, these changes need to be deployed at the same time, creating a lot of risks in the deployment and a lot of delays, all contributing to the aforementioned “cycle of stuttered innovation“. […]

    Like

    Reply

  2. […] The sorry state of IT departments contribution to Innovation: Escape the cycle of stuttered innovation. Always waiting for the next big investments, the next big system project is not winning strategy […]

    Like

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s