I worked with a fellow analyst in the 1990s who used to stand on stage and say that buying SAP was a lot like pouring concrete over an organization.
That’s not a dig at SAP — you could have said it about any of the major mega-packages involved under the “ERP” (Enterprise Resource Planning) rubric.
But, looking back over the past fifteen years, the claim that it was a lot like pouring concrete over an organization has held up pretty well.
This, in turn, is what needs to be undone.
There are four different domains of work, and well-defined processes that are rigorously implemented is typical of only one of them. Trying to fit any of the other three types into a rigid framework merely leads to eruptions of disorder — and much higher costs (financial and human) than need to be borne.
Even in the one domain to which processes are appropriate, increasingly it’s subprocesses that matter, not the process as a whole. The ability to mix, match, combine parts, add human initiative and accomplish things with partial scripts has become much more important.
Alas, the barely repeatable process, the human ingenuity bridge process and the like are seen as working against “best practice” (which is what these large-scale packages implement).
They’re also seen as potential control violations, which means implementing all the use cases within them and then forcing a single interaction script is not a norm, but the norm.
Yet breaking these up into sub-processes is important for customer service, for innovation, and for providing the adaptability a system requires to avoid crises.
Underneath every ordered system is disorder, waiting to break out. The more rigid the system is, the more ways in which that disorder can manifest itself.
More completely planned out systems, for instance, lock in a cost of operation. If there are twenty-five sub-steps that must be completed each and every time there is an interaction, these take time (and thus cost money). Make it possible to interact by doing only what’s necessary and you can save time and money. (This on top of the benefits that may accrue when you become an organization that is easier to deal with.)
Systems where “all the use cases have been included” also have no adaptability in the face of change. Suppose you are an airline that charges for luggage in the hold. A competitor decides to take market share on certain routes by not charging for this. If your system steps to the next screen demanding payment information, you have no ability to respond in the field to the emerging danger — and if your competitor succeeds, many passengers will stay with them even if, a few weeks later, the system update to allow a waiving of the fee has been implemented.
That permanent shift of share is increased disorder waiting to break out in a too-rigid business.
For the past twenty years, IT professionals have been process-centric. They have analysed the work flow and developed the use cases that handle all contingencies. The software market has followed the same course.
Today, what we need are well-designed subcomponents — and the ability to draw upon them in unique ways. The information base is the connector, not a rigid system.
Those that get there get the advantage needed for a period of economic turmoil.