More silo thinking (It's still bad for you)

One of the most popular posts on this blog is about Silo thinking and why it is bad for you.

In that post I discussed the concept of silo thinking, what it is, how it occurs, why it is bad and how to solve it. But I recently came across a very interesting example of silo thinking where the project put together to document the companies processes are themselves designing the processes in silo's.

Picture the situation. A financial organisation, globally known, well respected. It commissions a project to document the whole of its customer facing processes to enable it to better understand what is happening and to present a better view to the customer of the services it offers.

The project is outsourced (!) to a third party, Indian based company. They send a team of people to the UK headquarters of the financial institution (which we'll call JohnPeterCorp) and they set about documenting the processes in a modeling tool

But the first mistake they made is that rather than taking the processes as a Gestalt whole they have split them out into sub processes and have teams working on each one. So we have the team looking at Investment Pricing. We have the team looking at Asset Trading. We have the team looking at Month-End Reporting.

Can you see why this is a problem?

Now - after almost 6 months in the project the team have realised that all they have managed to do is take a bunch of Visio documents that JohnPeterCorp had done last year and drop them into an expensive modeling tool. They are effectively no further forward on their ability to better understand their processes than they were 6 months ago.

I was talking with the modeling lead recently and he told me that they were having modeling issues now because a lot of what they wanted to do involved linking the processes together which, if they had started looking at this from an overall process point-of-view would have been easy but - because they had siloed their processes - is becoming increasingly difficult.

The net result is a lot of work an effort has gone into this but very little actual progress has been made.

Why did this happen?
The question has to be asked about why something like this was able to happen. Surely the third party company were experienced in doing things like this? Durely the senior management of JohnPeterCorp knew exactly what they wanted and what they were going to do with it? Why did this happen?

The truth is that this was a case of the blind leading the partially sighted. I don't believe JohnPeterCorp really had any idea about what they wanted to do with the information they would get out of the project. They were looking at 'documenting things' to get a customer's eye view of this but they constrained themselves in the documentation by adding a codecil which specified that processes had to be linked up to an existing hierarchical view that they have traditionally been working on. Nobody questioned this. The third party company then made their best efforts to actually meet the brief passed by the customer, but nobody took the time to step back and understand why this was needed in the way it was needed. It is only now that the modeling issue have arisen that people are starting to look back at the original brief and wonder if they might have done this in a different way.

So this has turned into an interesting project where - in order to try and remove silos - the modelers have modeled the processes in silos and are now stuck trying to sort this issue out.

Take a look around some of the projects you are working on. Are you 'silo bound'?


Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.

All information is Copyright (C) G Comerford See related info below

Related Posts by Categories

Widget by Hoctro | Jack Book
For blog comments policy see this post
blog comments powered by Disqus