Image via Wikipedia
I was reading one of the multitude of blogs I read daily when I came upon an excellent post from Havi Brooks at The Fluent Self. In this post Havi was talking about 'The hole in the system'.
Basically, she explains, most people define 'systems' around themselves but leave some sort of a hole in there which causes problems later on.
Specifically she gives 3 examples:
1) "The baby-bathwater thing": Which is where systems are in place but are subverted because of some emergency situation
2) "The misguided assumption thing": Which is where systems are bypassed based on assumptions that would not have been made had the system been followed
3) "The 'not allowing for stuff going wrong' thing". Where systems only account for the ideal situation to occur and are not designed to cope with occurrences where things don't happen as designed.
What struck me about the post (and the three examples quoted) is that they are pretty universal - especially when applied to business processes. When I look at processes in place in business today they tend to be designed from the point of view of 'this is what should happen' rather than 'this is what can happen' it's a subtle difference, but very important.
There are, of course, whole industries that have sprung up to deal with the different scenarios detailed above - things like decision management systems for example. But am I the only one who thinks that it might be a good idea to design your systems correctly in the first place? How many times have people fallen into the trap of designing a business process - for example - to match a specific piece of software functionality but then suffered when that software can't cope with a customer who comes in with an emergency (The 'baby-bathwater thing')? It happens all too often. This is not to denigrate business decisons systems at all, but merely to look at specific probems through a different prism.
I am a firm believer that processes should be designed to be tool independent. That way when you change your underlying ERP or CRM system (for example) you don't actually need to redesign your processes. Havi says:
It seems to me as though most challenges that tend to come up in these situations have two sources.
Maybe the system is flawed. There’s a spot where things get stuck, jammed, or fall through and get lost. Or a great system is already in place, but we’re just not using it. Which is the flaw.
Fundamentally Havi is speaking of the two bugbears that dog any system's implementation: Putting in a system that works but isn't used correctly or putting in a system that doesn't work correctly.
So how do we solve these two problems?
I would say we don't.
Or, more particularly, we can't. It is fundamental in human nature that we seek the easiest solution. Generally the easiest solution is that which needs the least amount of work, or that which produces the ideal result the quickest. This can be the kind of thinking that produces systems that don't work correctly. Alternatively we can spend time, money and effort in creating virtually foolproof systems only to then have the users bypass these systems when an 'emergency' arises. But let's also look at the opposite side of that equation. How many time have you rung the bank, or some other 'call centre' system and asked them to do something only to be told that 'the system won't let us do that'? This is an example of a system that has been designed to work in one way but which we now want to subvert by not following the process. The well designed system has had safeguards built in that will not allow you to do anything like this. But at the end of the day you end up as a dissatisified customer. So is the system working correctly?
Yes it is. It is working absolutely as designed. But is it working in the best way for the customer?
I don't think so.
Perhaps the solution is to make systems more flexible? Maybe we need to try and ensure that users can perform the tasks they wish (regardless of what those tasks are) and then manage the fall-out using something such as decisions or rules based systems. But somehow I can't help feeling that this is tantamount to creating another 'hole in the system'
Thanks to Havi for the original post.
