I’ve written on this blog before about some of the issues and problems with BPM as a concept and implementation of these concepts. Mainly the issues can be boiled down to a few key items: Lack of correct change management. Lack of Executive Sponsorship. Lack of ownership.The key thing that these have in common is that they identify something that isn’t there - be it an owner, a manager, an objective. But today I want to talk briefly about something that is usually there - and often in too many different places to be useful: Standards.
Time for the obligatory anecdote:
Back when I worked with a pharmaceutical company we developed a set of standards that would be applied to technology across the organisation. These standards detailed the operating systems we would adhere to, the specification of PC’s we would use, the types of devices we would allow to attach to our networks etc. etc. This was referred to as “The Standards List” for obvious reasons.
However, there was one part of the company who believed that these standards didn't apply to them. They were always looking to use something different, or not use something on the standards list. They were applying for exceptions on a regular basis and getting these approved. It helped that they were a large part of the organisation with a huge budget and some political clout at the CIO level.
But the result of this is that we, effectively, ended up with two lists. There was “The Standards List” that was used by 90% of the company, and there were the exceptions that were used by the remaining 10% (usually this one functional area)
In effect we had two sets of standards. Which, in effect, meant we had no standards. Because it then became known that if you wanted to bring something into the organisation that was non-standard it could be done because there was a precedent. You only had to say ‘This area uses Mac computers on our networks so we want to use them as well - it’s on the list', and we couldn’t stop you.
Why are standards important?
While each department had a perfectly legitimate reason for wanting to bring in something that was non-standard, it did create a problem that was one the standards list was trying to avoid - maintenance and associated costs.
One reason why the company decided on Windows 2000 (at the time) as the standard for desktop operating systems was because we had agreements in place with Microsoft to supply the software and associated upgrades. These were then placed on a disk image which would be quickly and easily replicated onto new machines. Centralised software roll-outs were also provided which meant that a new piece of software could be rolled out to the 30,000 pc’s in the company virtually overnight and under controlled circumstances. All this resulted in lower maintenance costs for the organisation.
However, once we started to allow Ubuntu and MacOS into the company we had to add new steps to our maintenance processes. These steps were exceptions to the standard. They cost time and money to implement and they slowed down software roll-out and burned resources at a time when the company was resource constrained.
Of course these costs were not born by the department that requested the exceptions. These costs were born by the support organisations that had to roll out new software and manage the desktop environment. These costs came out of their budget. They cost the company money it didn’t have.
I suppose it would have been easy to take these costs and bill them back to the appropriate department and make them feel the pain (and in fact I believe that’s what they did towards the end), but this merely resulted in justification for the departments who then took the view that “If you’re billing us for maintenance of our own systems why should we adhere to your standards anyway? We might as well do our own thing”. As a result they created a parallel support organisation which sapped overall costs across the company.
You can see the problem. It all came down to standards. Standards are there for a reason. They have been defined to allow consistency across organisations and allow ease of use and maintenance. It’s the same with process diagram notation. BPMN is a standard, as are TOGAF, Enterprise Architecture and Rummler and Brache. I’m not about to give any credence to one over the other, other than to say as long as you have made your choice and know what you want it doesn’t matter which one you use. But you must ALL use the same one in an organisation.
This can become particularly onerous when you are part of a company that has recently been bought by another company. You will, no doubt, have your own set of standards for many things in the business. The purchasing company will have similar. The chances of the two being the same are very small. So at some point there has to be a rationalisation. The two standards have to become one. This can either be through wholesale replacement of one set with another, or through the merging of the two into a third, common, standard. Either way the newly defined standard has to be accepted and implemented across the organisation.
But what is more important - and often overlooked - is a process for managing the standards. The set of standards you put in place when a business is two years old working in a manual environment manufacturing goods, for example, will not be the same set of standards used by that company after it has been running for twenty years and has automated many manufacturing steps. The management of that evolution should be in place as well. This is an area that is too often left to chance. Without a standardised process to manage your standards, you will end up with a process of half-measures. But you will have a process.
But I’m not sure it’s a process you really want.
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
