Welcome to my first simulation blog post – and it’s as an award-winning modelling practitioner. The award was for swimming, I was 12, and I had completed 25m – but it still one of my proudest achievements.
In 2017 I celebrate another “25” – this time it’s for 25 years being involved in computer simulation. After all this time and 100s of projects, I think I can safely say that the first step to solving any problem remains the same – and that’s to understand it. That’s hardly rocket science. Having said that, it was the director of a rocket fuel company who said to me: “I know I have a problem but I don’t know what it is.”
Different people will have different perspectives on the impact of an issue and may have multiple views on the causes. The tool of choice for the Simulation Consultant here is not a piece of software, or a management technique. It’s simply Listening – closely and objectively. Gathering first-hand evidence to understand the problem is your primary task. You need to empathise with the impact on people and the business, without being led into accepting the believed causes. If the problem has persisted for some time, there could be deep-seated views on the causes, and at best these are tricky to shift. In the most complex problems, such preconceptions can unwittingly lead you to a wrong or incomplete understanding.
One project for a media company involved a process where information from multiple sources was being combined to trigger 1000s of actions on a daily basis. But a small number generated chaos for the business and for customers. Anyone that changed their telephone number received a pair of unexpected automated communications: a “sorry you’re leaving us” letter, followed shortly after by a “welcome” letter and new customer media pack, and sometimes and seemingly randomly the other way round. This affected 100s of customers every month. Understandably this resulted in the contact centre processing calls from anxious customers, who had simply changed their number with BT and got a strange response from another company!
The problem had persisted for over 15 years, and downstream corrective action had become part of the solution, involving a separate team. I was working with the company on another issue at the time, but I was approached to see if I could examine this problem as a side-project. So I spoke with several people involved in the process, and I received a pile of documents describing what the process rules were.
Unfortunately the documents contained wrong assumptions when the system was designed. As a result, incorrect process rules had been implemented from the outset (although correctly according to the documentation) and successive projects over the years had re-stated the incorrect process rules, so it was now very difficult to change people’s views. I think I was able to identify this because I was on the “outside looking in” and wasn’t conditioned by years of believing these false assumptions. But how was I to tackle this with the team?
“Insanity is doing the same thing over and over and expecting different results.” – Einstein
In this case, I was able to gain the team’s agreement that if the process was correct there would be zero incorrect events; so you had to change the process rules to eliminate these events. Zero incorrect events would be the evidence that the revised process was correct. As this involved challenging assumptions that had existed for years, it seemed harder to shift peoples’ thinking than it was to change the process itself.
So I developed a simple model that first mimicked the way that telephone amendment data was processed, and then how the existing process rules would treat them. The model generated two false events for each amendment – a “cancellation” followed by a “new business” event. Sometimes the order of the events was reversed. I could play with both the data and the rules, until I had a full understanding of the relationship. I then identified the solution, changed the way that the incoming data was processed, and the false events were eliminated.
A model wasn’t really needed to solve this problem – it certainly wasn’t that complicated. But its value was demonstrating to the team and managers both how the existing process created problems, and what needed to be done to eliminate them. The team was finally convinced and the decision to change the real process was made. It was up and running in just a few weeks.
The benefit was disprorpotionate to the modelling effort! A permanent team of around six people was redeployed from this thankless task to more meaningful customer service; customers were no longer being worried by unwanted and unexpected changes to their services; and the business was able to put to bed a problem that had dogged them for years.
