On inertia, garages and the future of ERP
Disrupting yourself is vastly preferable to having the industry disrupt you
Secret CIO Success has a by-product. The more success we experience as a result of doing something, the more of it we do. Even once the success rate slows, we keep doing the same thing in the hope the change is a blip and that if we keep doing what worked before good things will happen any minute now if we persevere.
This happens with people but it also happens with businesses. That time you shifted marketing spend to concentrate on appealing to the baby boomer demographic resulted in a sales spike. Woohoo, nice work marketing team, meetings are then scheduled to refine the brand message even more closely to one aligned to the baby boomer market. When sales begin to slip, more meetings, more message refining until some bright spark points out that the baby boomer demographic are finally starting to pop their clogs at a furious rate (much to the relief of many a western economy) and there just ain't that many of them left to market to.
When the truth finally becomes irrefutable, there is a long period of time where the inertia of the old way of doing things continues to prevail. People have built careers on the previous way of operating and have generated a great deal of influence as a result. They are therefore undestandably loathe to let go of the previous model as it means they might be thought of as less right.
It's possible to predict the length of the period of inertia by multiplying the level of success of past behaviour by the duration of the success experienced to produce the duration of inertia required to be endured before real change can be made.
This phenomenon exists even at an intra-company or business unit level. This isn’t a surprise as it is a human failing and people run business units. As this is a technology publication, let us consider the IT business unit. In the 1990s, CIOs made careers out of implementing large, scale up systems to provide centralised control of centralised data for centralised applications run by centralised management teams for centralised decision-making.
It went tremendously well. All of a sudden, we could see what those bandit warlords in the country-level business units were up to. We got to help expose their largess, which made for high fives and back patting all around. Still flushed with the success of the previous decade, the turn of the century came along and we prescribed ourselves (or more likely had prescribed for us) more of the same. ERP projects sprung up around the business world and CEOs and Boards signed off trillions of dollars’ worth of ERP projects.
Being the good little back office functionaries we are, we started to pour ERP cement over our processes and began crafting it into the magnificently intricate sculptures that business owners (and ERP consultants) dictated were required. We stepped back from our work, around 2007, and again it was high fives and back patting all around. The financial results of the fancy process footwork, which in most cases butted right up against tax evasion, began to flow through and people were pretty happy. OK, so about a quarter of those projects failed but that was declared an acceptable casualty rate and we all went to the pub win or lose. Back in the office, there was a creaking sound which at first no one noticed. The creaking sound was the ERP cement beginning to dry, and little did we know what an effect this would have in only a couple of years.
Whilst all this was going on, there was another revolution going on in technology. Bright young kids were congregating in their parents’ garage and coming up with ways to do more with less. These kids didn’t have the kind of budgets that ERP projects required – they were lucky to have a couple of hand built servers and a switch they picked up from the bargain bin at a consumer electronics retailer. Every time they made a little money, they would buy another server and stitch it to the side of the thing they were creating. This mindset continued and even when they sold a lot of their twigoobookazon, they just handmade a stack more servers and scoured electronics retailers for more switches. It turned out they could build some pretty damn amazing things this way. In some cases, they built systems which rivalled ERP applications in their complexity. Consumers were amazed by the combination of innovative technology and creative economic models and flocked to the – to all intents and purposes, free – twigoobookazon in droves.
Back in enterprise land, things were not going as well as had been planned. In some cases, the various governments around the world had caught on to the
tax evasion income efficiency measures and had begun to legislate changes to some of the processes we had built – that is, you could no longer pretend that everything you made was bought by a Swiss shell company and sold to other business units at roughly the same price they charged customers. Dutifully, we sent the soldier ants in to make the changes required and were shocked to find that the concrete had entirely set and any changes from this point on were going to require more than soldier ants. From here, we were going to need heavy excavation equipment.
CIOs put together business cases to bring in the heavy equipment and were met by astonished and less than pleased CEOs who didn’t understand why the cost of change had escalated so quickly. All of a sudden the cost of responding to mandated change (let alone iterative or experimental change) had become so high that it impacted business decisions. Fewer risks were being taken in order to expose the business to less change, and CIOs began to focus on governance, risk management and compliance (GRC). How do you imagine they went about this? Well, ERP had worked for them so far. Sure it was kind of responsible for the problems they were facing now, and they had a suspicion that a big change was due in the industry. But, unfortunately, inertia won the day and ERP GRC projects sprouted around the industry like locusts after a heavy rain.
Those GRC projects did a great job of pointing out that some of the processes we had introduced were inherently risky. “This guy can change a customer record and initiate stock transfer!” (gasps all round). “Quick, we need a role re-design stat”, said the risk guy. And before we could turn around, we had slapped a little bit of concrete not only around the process but around the people that run it. “There. That’s better”, we said, as we stood back and admired our handywork (creak, creak, creak).
The CEO is poring over a factory productivity and staff costs report in his office when you are called in. “This factory is too expensive to run, the staff costs are too high, they have a person for changing customer records and a person for initiating stock transfers. Close the factory.”
I think you can see where I am going with this (I did deliberately exaggerate and over simplify the point after all).
Sponsored: DevOps and continuous delivery