Q: When is it easier to ship a $600 electronic device across the country and back, than it is to change a field in a database?
A: When you are a phone company.
This is a true story, and one that perfectly illustrates how IT systems, when implemented, can actually make a company less flexible and less able to cope with unpredictable things. Information technology can actually make a company more fragile.
The most important point of Nassim Taleb’s new book “Antifragile” is that a flexible, antifragile system, such as a human organization, when successfully shielded from stress, can be made inflexible and fragile. The point of most IT systems is to make all work repeatable and predictable; to determine one way to do things, and then force everything to be done that way. The expressed purpose is to eliminate non-uniform situations.
We do this to control costs and enforce best practices. Disorganized and non-uniform organizations evoke images of a rat’s nest of busy rodents scurrying around bureaucratic tunnels like a vision out of Terry Gilliam’s movie “Brazil“. The stereotypical well-run organization hums like a well oiled machine taking care of each piece of work with uniform precision. It is intuitively obvious that the well-run organization is less wasteful. Still, there is an unseen cost, and that is fragility.
If Taleb’s theory is true, then these systems, if successfully implemented, should make the organization less able to cope with situations outside of the normal parameters. It took me only a moment to remember a recent relevant personal example.
A New Phone
In October I ordered a new phone. After years on the iPhone, I am jumping ship, and switching to an Android phone. Not just any phone, the celebrated Samsung Galaxy SIII which everyone raves about. So I order the phone and a couple of days later it arrives, I turn it on, and it works perfectly.
Then I notice that the phone has been billed to the wrong account. It was supposed to be billed to me, but it had been set up to be billed to the company. I know it is going to be quite a bit of trouble to get this straightened out in accounting, so I call the phone company to get them to allow me to pay for it directly with a credit card. That is not possible. It is not possible to change the billing method on a phone order. But, they would be happy to send me a new phone, and I just ship the old one back.
In disbelief, I asked a couple of times for clarification. The full shipping both ways would be covered for free. I would get a new SIM card so I would not have to switch anything. Just package the old phone and send it back after the new phone is working.
I asked why not simply order a new phone, and then just change the serial number to the phone I had. No, that is not possible. I had to be actually sent a new phone with a new serial number and new SIM card, simply because they can not change the billing method on the existing order.
This is a great example of how IT systems can create a kind of uniformity that prevents people from being able to handle exceptions. The IT systems at the phone company worked beautifully for normal orders. The new phone arrived in two days, everything was in order, and when I turned it on, it immediately activated with my regular phone number. But it was impossible to change the billing method.
Now, imagine a company from 40 years ago that kept its records in bound paper books. The idea that they would have to ship a complete new device simply because they can’t change the billing method is inconceivable. In those days people needed to take a lot more care to make the entries correctly, but at the same time there was flexibility to do the right thing.
The person I was talking to at the phone company knew perfectly well what I wanted, and also knew how silly it was to have to send a completely new device, but the system he was using was simply not set up to allow the kind of change needed. It was the IT system enforcement of a particular set pattern of behavior that caused the problem.
When an IT system enforces a single way of working, I am reminded of the problems in agriculture when you grow a single kind of plant in a large area. The problems with a large monoculture are well known: everything is fine until it isn’t, and then it is terrible. If a pest or disease gets loose in the middle of the monoculture, it spreads far faster, and destroys far more effectively than if there was a mixture of plants.
An ecosystem with a wide variety of plants living in a codependent way is far more resilient to disease and pests. It is antifragile. When a farmer decides to grow only a single crop in a large area, it looks at first to be highly efficient: everything is uniform and done in the same way every time. One can focus on perfecting all the nuances of that one crop. The risk is hidden: when disaster strikes, it wipes the whole thing out.
The hidden risk with enforcing best practices of a business process in a BPM system is that you might get what you wished for: everyone in the company doing things exactly the same way. All works well until you need some action outside the normal. Since everyone is doing things exactly the same way, nobody has any experience doing it differently. Getting all instances of a process working exactly the same, best, way is precisely the goal of BPM. You might actually end up with a “Business Process Monoculture”.
Here is an odd idea: perhaps we should force people to do things in different ways across the organization, even though less efficient, so that you retain a greater variety of skills in case they are needed some day.
Imagine a system that purposefully mixed things up occasionally, forcing people to do things a different way sometimes. This might work the way that a vaccine does, by forcing your immune system to work in a non-lethal situation so that it is prepared in case it encounters the real thing.
The lesson is: be careful of what you wish for. Be careful of Enlightenment — thinking that an organization is just a machine that follows simplistic rules. Successful organizations are much more complex than any of us realize. Finding a ‘best practice’ is always a laudable goal, but enforcing uniformity might make your organization fragile.
And maybe, just maybe, there will still be someone who knows how to change the billing method on a new order.