The Redundant Back-Up

I worked at a location that was running a single, world-wide instance of SAP. The whole of their HR, Finance, and some of their manufacturing was running from this single instance, twenty four hours per day, seven days per week. Naturally, the process analyst in me (and to some extent, the pragmatist) had a number of questions about this:

- “How do you back-up?” - “We mirror and back-up the mirror”

- “How do you do maintenance?” - “We have a back-up machine at a separate location across town. We transfer the users to that and perform the maintenance then”

The questions went on and on. Each one had a suitable reply. But then I started thinking about this single instance and it didn’t seem to sit right with me. For some reason I could foresee problems with it. Finally, I was able to verbalise the issues I was having: “How do you deal with disaster recovery?”

Most of my readers will know what disaster recovery is, but for those that do not, a quick explanation. When something happens to a computer system that renders it unusable, a business continuity plan (BCP) needs to kick in. This is where processes are enacted that allow the business to continue operating without the damaged/unusable machine. Running in parallel with this is a recovery process that attempts to repair or replace the damaged/unusable machine and reinstate all the data and transactions that were damaged or missing as a result of the disaster. I had concerns that because this was a single instance, and because it was being used globally, BCP and disaster recovery would be a nightmare.

The project team had already thought about this.

They told me that for BCP purposes, every affiliate running the software had processes on-site that would kick in if the system was unavailable. Even in the worst case scenario, the system would not be offline for any more than 48 hours because they had an agreement with a third-party provider to have a hot-site at a remote location which would be implemented at the first signs the redundant back-up didn’t work.

I asked if this had been tested. It hadn’t. But I was assured that it had been implemented in other organisations within 48 hours.

I turned my attention to the redundant back-up. What happens if there is a fire that destroys the main machine? The redundant back-up would kick in, and all systems would be re-routed. How is the rerouting done? Through underground cables that link the two sites. What happens if someone cuts through the underground cables? There are redundant underground cables that route North and South of the city between the two sites. The chances of both being cut are infinitesimally small. What happens if there is a power spike that takes out both systems? Both systems run off separate power supplies. A power spike would only take out one, not both. What happens if a small nuclear device takes out the town, both sites and the power sources? We would have bigger things to worry about than the system, but in that case the hot-site would kick into action.

I grilled the technical operators and designers of this system for almost two days, coming back to them time and time again when a new scenario occurred to me. They had a suitable answer for every single one of my questions. So, at the end of it - despite my reservations - I had nothing concrete to justify them

Then, a couple of weeks after I left the site they ran a new interface program. It was an HR population interface that filled in specific records on an HR master file. The interface had not been tested properly and it went into a loop. The program ran all day and most of the night. It kept populating the file overnight, making this file larger and larger and larger. It made it so large, in fact, that it completely filled all the disk space on the system.

The main computer, and global SAP instance, shut down.

As designed, it failed over to the redundant back-up across town. The system was on-line, ready to go as expected. It dutifully continued running all the processes it should be running - including the HR population interface. This ran for the rest of the night until it, too, had filled up the disk space on the redundant back-up.

That machine failed.

Plan C was, of course, the hot-site located in another town. A town which was, in fact almost 500 miles away from where the two main sites had been. The hot site didn’t work. It took almost 72 hours to get up and on-line and even then all the information needed to make the system run globally wasn’t there. The comms lines to the global sites were not connected. Anything that could go wrong, did go wrong.

The rest of the story gets a little fuzzy. All I know is that the global SAP system did not come back on line in the host town for almost six weeks. Retrofitting all the missed transactions from within the BCP took another few months.

Nobody lost their job over this. The hot-site provider lost their contract, I believe. I sat there shaking my head.

But that wasn’t the worst of it. The worst part came when I spoke to people who were affected by the outage. I asked them what their BCP was for when they had no access to the system. (remember I had been told by the tech crew that each affiliate had processes for dealing with on-going business when the system was down). They told me “We wait.” The BCP for operating a multi-billion dollar global business across numerous affiliates, sites and countries was “Wait”. Wait until the redundant back-up kicks in and, if this doesn’t work, wait 48 hours until the hot-site is ready to run. I wondered how they dealt with a six week backlog of waiting? Nobody was able to tell me. But I’m reasonably sure it involved manual work arounds.

The moral of the story?

Your redundant back-up isn’t. There is always the scenario where you will find yourself without it. Plan for that scenario. Make sure that you have processes in place to deal with it - even if the chances of that happening are remote. Remember the Twin Towers of the World Trade Centre were designed to withstand the impact of commercial airliners when they were built. The chances of an airliner destroying more than a few floors was negligible. But the impact of the jets didn’t bring down the towers. It was the thousands of gallons of jet fuel burning away at vital support beams that did it. Once a couple of these had weakened, gravity did the rest.

Photo Credit: pchow98 via Compfight cc

---

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

It's Just Not Cricket!

I was sitting over the weekend watching the guys practice their cricketing skills on the local cricket green. (For those of you who want an in-depth explanation of cricket I would recommend this:  Or for a more in-depth and less humourous look, this).

The exercise was simple. A batter would lob a ball really high into the air and the fielder would have to catch the high ball, immediately throw it back accurately towards the batter who would knock it along the ground. The fielder would then catch the low ball and return it to the batter who would lob another high ball for the next fielder in the line.

Simple straightforward and practical.

The problem came when one of the fielders didn't catch the ball. It threw the rythmn of the practice and the guys would have to regroup and start again.

I got to thinking how this applies to process.

At first glance it’s a simple process with a number of moving parts (or steps). The process is designed so that each step can be executed in a sequence and the output of one step is used as the input of another. The problem comes when the output of one step is not what is expected by the following step. This is the case with the cricket practice. The batter was expecting a ball to come at him from the previous fielder so he could launch that to the next participant in the process. When the ball didn’t come back (because the fielder dropped it) it made the process grind to a halt.

In reality that solution is really simple: Have a second ball ready to throw into the process when the previous step fails to deliver. But this is what a lot of process definitions steps fail to take into account. They are designed to run with an optimum process flow (i.e. they assume that the output from previous steps is valid). Designing some error handling into a process is always easier than trying to fix a process when it doesn’t work as designed.

How many error processing steps do you have in your processes?

Photo Credit: siddharthkhajuria via Compfight cc

---

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

Filming for TV: Some thoughts on process ownership

Those of you who have been reading this blog for a while will realise that I do, occasionally, like to look into things that happen in every day life and try to understand the process issues inherent within them.  I want to move onto something related, but a little different.

Television.

I was fortunate enough recently to spend time working on a new comedy series to be produced for UK television. It was filmed (as many comedy programs are nowadays) in from of a live studio audience.

This is different to a lot of things I have filmed in the past for two reasons

1) There is a live studio audience!

2) The dynamics of command and control are very subtly different.

Let me explain.

In ‘filmed’ television (‘Downton Abbey’, for example), the director is in charge of the filming production and the first assistant director (1st AD) is in charge of running the set. The chain of command goes Director --> 1st AD --> heads of department. It’s a little slow, but it works and it keep the unions happy. Filming is done with one camera at a time (usually) and the final footage is edited together separately for transmission.

Television works quite differently. For a start there are more cameras. On the show I did recently there were five cameras running independently. These were big broadcast cameras which didn’t have on-board recording facilities. The signal from their feed was sent to a control room where they were mixed together by a producer. He is - effectively - editing the show as it is being filmed. 

Takes are quite long and complex involving a lot of camera movement and choreography. If a camera isn’t in the right place at the right time the take is blown and we have to go again.

So far, so good. But here’s the rub. I couldn’t work out who was in charge on the set. Sure there is a director and 1st AD. These two worked together in a similar way to on a film set. But there was also the producer character who was involved in all the artistic decisions because he had to make it all work in the control room. The issue came when the Director wanted one thing and the producer wanted another. It became a case of review & decide, cajole & threaten in order to reach a compromise. And a compromise is never good, artistically.

But the whole discussion got me to thinking about a topic which is close to my heart : Process Ownership. I think it's accepted that processes need to have somebody responsible for them. But is it accepted what the scope of process ownership should be? I don't think so.

I think that process ownership is oftentimes equated to project ownership at the senior level. In many cases someone is allocated project ownership at C-level purely as a way of ensuring that the project is seen as having “clout”. In reality the assigned C-level executive has minimal, if any, ’skin in the game’ for this project.

And so it is with processes.

An executive Vice President for finance might be nominated as the process owner for a process in the finance department, but - in the big scheme of things - has very little, if any, involvement in the day to day running or execution of the process. Some would say that this is fine - after all, why would a senior executive need to be involved at that level?  But I have a different opinion. I am sure that the are arguments that can equate the ROI of having the exec manage a process vs delegating, and these are all totally valid calculations. 

But they miss the big picture. 

Process is not something that happens in parts of an organisation. Process is something that happens across the whole organisation and having someone who can manage that at the organisational level makes a lot of sense. Any lower in the organisation and you start to suffer from the problem of silo mentality and not invented here syndrome. But at the senior level you have someone who has both the executive clout and the mandate to manage a process from start to finish right across the organisation.

However the logical extension of this is that there are going to be senior executives who mange processes but who will not manage them appropriately. Take, for example, a senior Vice President of Finance who is managing a process which touches more areas than just finance. If a change needs to be made he will, most likely (and politically) favour his own department if anything needs to be done that is positive, and favour other departments if negative changes need to be made. This is human nature. Of course the simple way to do that is by following the old guideline of “whatever gets measured gets managed”. If you recompense the finance executive on his ability to appropriately manage the whole of the process rather than on the results of the finance department alone, this will start to remove any political bias that may exist.

On the other side of things is the issue we experience in the TV studio where the process owner is not adequately defined and this results in two people having differing idea related to a change. They end up with a compromise, and this is - by definition - less than optimal.

Of course this isn't easy. Nothing at this level ever is, process even more so because it covers a larger part of the organisation. But these are the challenges that need to be addressed to make process management as a competency work in your company.

Photo Credit: Corvair Owner via Compfight cc

---

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

Priorities, priorities...

It occurred to me recently that I haven’t asked a question of my readers for a while - one that will provoke some conversation, I mean.

Obviously there are different forums that these conversations can take place - and if you want to do so, please continue those there and link to them in the comments so I can follow along.

My question today is focused on all those people who have responsibility for process (process definition, process management, process implementation etc. - in whatever form you wish to define it - Case Management, Workflow, BPM etc)

What is your main process priority this year? (and why?)

Potential answers could include (but are not limited to):

• Understanding process gaps.
• Defining process owners.
• Documenting my processes.
• Rationalising my current process inventory.
• Getting senior management commitment for process change.

I’m interested to understand what people are focusing on this year.

If you feel like indicating how or if this has changed since last year, please do.

Thank you.
Photo Credit: Leo Reynolds via Compfight cc

---

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

Standards.

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

Selfishness and Process.

Back in the mists of time I used to have a valid private pilots licence (PPL). One of the things I wanted to do was get a share of an aircraft so I could increase my flying hours and learn more about this great pastime of flying. I inquired at the local airport and found a great little plane that was within my price range at the time.

But when I looked into the small print of the costs there appeared to be something which - at first - struck me as strange, but than raised a red flag.

As a bit of background: when using a plane there is always a cost involved. This cost varies depending on whether you own a piece of the plane or are borrowing it without an equity involvement. But regardless of whether you are, or are not, there is always the cost of fuel that needs to be factored in. In many cases you take the plane, use it for however long you want and then fill it up when finished, at your own cost. In some instances you can fill it up on a company account and it gets charged to your costs or - and this was the case with the plane I was looking at - you were charged a fixed amount per hour for fuel, regardless of what you used.

The problem with this was the behaviours it promoted. Imagine the situation: regardless of how fast or how far you fly, you are going to be charged a set amount of money for fuel. This was not an insignificant amount either. It equated to 55 litres of fuel per hour for a single engine Cessna. (That's pretty much the same amount of fuel as my road car uses in about 8 days - and aviation fuel is more expensive). So in that situation, would you take it easy with the plane? Would you lean the fuel mixture to be as conservative as possible? Or would you just slam those throttles open and scream across the sky as fast as you could and as inefficiently as you could? Human nature would expect us to do the latter rather than the former. After all if there are ten people renting this plane in a week and they are all paying the same amount per hour, why should you be the one who only uses 75% as much fuel as them but still gets charged for 100%?

There was a knock on effect of this, too. The amount per hour was calculated on the average fuel usage that the owners of the plane were being charged. (They paid for all the fuel themselves and offset it against the hourly fuel rate). But the rate they set was based on current behaviour rather than future expected behaviour. Which means that after a few months of running at the new fuel amount (55 litres per hour), they discovered that they were actually paying for 70 litres per hour of usage (for example). Therefore the owners were losing out on this deal. So what did they do? That's right, the increased the hourly fuel charge to 75 litres regardless of actual usage.

Can you see how this would then become a bit of a problem? The upshot was that a lot of the guys who were renting the plane found that the fuel cost became prohibitive (even though they were using that much fuel per hour), and stopped flying. The owners then started to lose out on the rental charges for the plane. When it came to doing routine maintenance such as replacing the engine or the propellor, they found they had to stump up the money from their own pockets.

As I thought about this today I realised that there is a lesson in there from a process point of view. The process that was being initiated had measures or metrics that were - effectively - Key Performance Indicators for the whole process. They determined the efficacy of the process (after all, if the plane was using more than 55 litres of fuel per hour then the ROI on the process was reduced). But what had happened to this process was that it had become driven by the KPI rather than measured by the KPI. This was an occasion when the adage "What gets measured gets rewarded" did not apply. Quite the opposite intact.

The process had been designed with a flaw in it. The measure was inappropriate for the process. A more correct measure would have been to remove the fixed cost per hour and replace it with a variable cost based on actual usage. This added a small administrative burden to the billing process, but resulted in more flexible (and better run) flights, where the fuel usage wasn't excessive.

It might be worth having a look around your current process and seeing if there is anything in there which is working in a counterintuitive way. Do you have any process steps that are time dependent and allow a larger amount of time than is needed? Could you cut down that time to enforce the right behaviours of efficiency and speed? Could you organise your workflow in such a way that you are not encouraging unwanted behaviours from the participants.

You might be surprised at what you can change.

---

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

Illusion and reality in BPM

Over the weekend I was reading through a couple of blog posts written by various BPM bloggers. One of these in particular stood out to me as it very succinctly highlighted one or two of the human nature issues that plague BPM.

The post in question was written by Keith Swenson and was entitled "Structure is in the eye of the beholder". In the post Keith talks about certain illusions that are ingrained into the human psyche which can effect the way people perceive and understand their world. This is particularly important when it comes to mapping it from a business point of view.

For example: When I look at a landscape I see the ground, the hills, the sky and the trees. There are no definite demarcation lines between each of these pieces, but when I draw them I tend to draw a line to indicate the horizon, a line to indicate the hills, and the trees are outlined to separate them from the background. In other words there us a tendency to add separation when - in reality - no separation exists. Translate this to business process and you have a situation where we try to compartmentalise things. As Keith says :

In reality activity is continuous and without distinct boundaries.  It is the mind that interprets the activity, and draws in the boundaries between different activities.  Without drawing these boundaries, it would be impossible to talk about what it being done, yet we should not forget that they are merely the result of analytical reasoning about the activity

Furthermore there is the ability of the mind in hindsight allowing us to know and understand things that we didn't know or couldn't understand at the time things were happening. This manifests itself in the form of complete knowledge and understanding of something after the fact but an inability to appropriately describe or map it during the heat of battle. With hindsight people can't understand why it was so difficult to map a process when - in fact - it was merely the fact that it was mapped and understood that made the hindsight so clear.

The summary of these two pieces of human nature is the fact that we tend to try and put artificial boundaries around things that shouldn't have them, and tend to misunderstand how complex things really are after we have mapped them by thinking that we could have done a lot of the mapping in advance.

Does this mean that our efforts at mapping processes are all for nought? Are we doomed to fall into traps set by our own human nature? Will we forever fail at being able to make sense out of the reality of our life? Well, without this turning into a philosophical treatise (and I believe it could quite easily do so) we must remember that there will never be a perfect solution for problems such as these. The key is to know that there is a potential issue and to understand what impact that will have. Human nature will always play a major part in events when humans are involved. It's the same reason why 80% of people think they are good drivers but in reality this can't be true. But we know that this is how people rate themselves because it's human nature. As long as we take this into account we will be in an appropriate position to understand the reality of a situation rather than the perceived reality of the situation.

My thanks to Keith for his insightful post.

==========================================

Some housekeeping:

In one of my top posts from last year I wrote about '10 BPM Blogs you should follow'. After seeing the response to this post I have revised some of the entries following feedback and will be producing a curated list of top BPM bloggers that I am referring to as 'The BPM Blacklist'. This list will be available within the week and I will produce a post and a link to both the list, the feeds and the twitter accounts (where available)


.

---

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

'In Any Business, 60-70 % are Non Value Activities

A recent article I read was headlined "In Any Business, 60-70 % are Non Value Activities". Further investigation outlined the fact that this was related to the Indian health care system, but it did get me thinking about whether there is a similar percentage for other industries.

I don't think anyone would argue with me if I said that all industries have some sort of non-value added activities in their processes. My interest is in minimising these activities.

Of course Six Sigma specialises in identifying and minimising these, but the problem I have with Six Sigma is that it tends to focus on specific parts of a process rather than the process as a whole. This results in either a sub-optimised process (but one which can be easily measured and quantified) or problems being shunted further along the process chain in either direction (any Six Sigma black belts out there who have a different opinion are welcome to reply in the comments).

Friday review - What happened last week 6th November 2009

With the inclusion of posts on the Posterous Cafe,  this will be a regular weekly consolidation post highlighting some of the key entries made on the Posterous Cafe that may have escaped your attention:

Teamworks 7 BPMS Report - A report from Bruce Silver on Teamworks 7's latest update. If you're not following Bruce, by the way, you should be)

Time for the next generation of knowledge automation - Some interesting thoughts about EDM, complex event management, ERP and BPM from Haleyai.com

CIO: Don't attempt BPM system without mapping process flows - A neat little article from Niel Nickolaisen about how he learned the hard way that mapping process flows is a pre-requisite to attempting BPM

Piloting social media creates more problems than it mitigates - Some thoughts on the use of project pilots for social media projects, and how process issues mean they may just fail...

Process excellence: No loose change - A lengthy case study on achieving process excellence at a UK high street financial institute. A good read.


6 Business Process Management Best Practices - I'm not sure these would be called 'Best Practices'. More like common sense to me, but useful nonetheless.

What can BPM vendors learn from the iPhone? - Mark Mcgregor (Fellow BPM Nexus Board member) discusses the thing that Apple (in a saturated mobile phone market) did very well with it's iPhone that BPM vendors should look at. Some very astute observations here and something that I think more vendors should be focusing on.

Why are Business Rules Subjugated to Process Management When Business Rules Should be Leading Process Management? - Read the discussion around this topical question.


BPM Promises "Simplicity" In 2010. Is This "Hope We Can Believe In" Or Still A Pipe Dream? -
A thought provoking and well thought out piece by Mr. Richardson on upcoming hot topics for BPM. Take 5 minutes to read this, you'll thank me later.

---

Reminder: 'The Perfect Process Project' is still 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

"Tone from the top" - is your project already doomed?

I was in discussion yesterday with a senior manager at a major international bank. They have set up a worldwide business process initiative and were looking for people with my skills and experience to come on board to help. I told them I was happy to do so, and we discussed terms etc.

The main reason for the discussion, though, was for them to understand my skills and expertise when it comes to processes. Obviously they have never met me and they don't know whether I am up to job they were offering. As such this was really a job interview. One question they asked actually got me thinking about a situation which I wanted to discuss with you today.

The questions was "What is the main stumbling block you have encountered when trying to implement a BPA initiative across a large organisation?". The answer to this was actually really, really, easy. It's the same answer that I would give to the questions "What is the main reason a lot of projects do not achieve successful completion?". The answer is 'change management"

I told him that the single most important thing to have in place to ensure the success of such an initiative was a good level of change management. It is too easy when working in a small project of 10 to 15 people to forget that what you are defining and mandating may affect thousands of people in the organisation. In the case of the last company I worked at as an employee they had 45,000 people in their employ. We would be directly affecting a large proportion of them and we were relying on our ability to sell the proposition as a means of making it work. Suffice it to say we had problems.

But as I was talking about this it occurred to me that there was another way of thinking about this. It is a method which is mentioned in my book "The Perfect Process Project" and it is completely applicable here: "Tone from the Top" or senior management buy in.

Let me explain.

Several years ago, at the company I was working in at the time, the top four senior managers in the organisation had a meeting. They were the CEO, the CIO, The VP of finance and the VP of Manufacturing. At this meeting they decided between themselves that they were going to replace all the legacy finance and manufacturing ERP software with a global implementation of SAP. Shortly after this meeting they sent a memo out to all their direct reports telling them "You will implement SAP". These direct reports, in turn, sent this down to their subordinates telling them "They guys at the top want SAP installed. Make it happen". Before long I experienced things such as line managers funding and attending SAP training internally so that they would have knowledge and expertise when the package came on line. Everyone had the 'let's implement SAP' mindset. It was all being led by the 'tone from the top' i.e. the senior management buy-in.

Can you imaging the difference if someone at a lower level had tried to sell this to his people without getting the buy-in from people above him? Can you imagine how much more difficult it would have been to get people motivated if there wasn't someone at a senior level - someone with a written and agreed objective linked to their performance payment - who had made it his mission to make this happen? And now we had the top four people in the organisation buying into this. In words and in actions.

It made a huge difference.

I will say, at this point, that I was one of many people who didn't think that the SAP decision was the correct one. The business case was weak, the benefits were ethereal and the timescales were unrealistic (and indeed with the benefit of hindsight we were proven correct). But this didn't detract from the fact that everyone in the organisation was aligned behind the senior management in making this happen.

Compare this with the previous organisation I worked with. We had been tasked with implementing an ERP system across 13 European countries in 18 months. This was a difficult task at the best of times, but things were about to get a lot worse.

At the project kick-off meeting in Germany (an affiliate that was already running a well established - German - SAP implementation) we were introduced by the Finance Director as follows "Ladies and Gentlemen, Thank you for attending this kick-off meeting today. Gary and Luc are here to put this package in and replace our SAP system. We know that it isn't as good as SAP and we will lose a lot of functionality because of it, but let's let them explain it to us". He then turned around and sat down leaving my boss and I to try and salvage the situation. Talk about the wrong 'Tone from the top'! Needless to say that was a long, drawn-out and difficult implementation.

As you go about your work today - especially those of you working on projects and implementations - ask yourself how many of them are actually being championed by a senior manager in the organisation. A senior manager who has his performance measured on the success or failure of this project. If you don't have one in place, ask yourself if the project is as successful as it could be.

Photo of Barack Obama courtesy of Pete Souza, official White House photographer

---

Reminder: 'The Perfect Process Project' is still 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.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Outsourcing and Process Management

Image via Wikipedia

My next door neighbour works for a military contractor. They are looking at taking over a division of another company on an outsourced basis and I asked him if he had done the process work behind this. He looked at me a little quizzically. "What do you mean?" he asked. I shook my head a little ruefully and asked him "Presumably you will be putting together contracts that define service levels around the outsourced division? Presumably these contracts will have financial penalties if you can't meet any given contractual clause? Presumably you have therefore, asked for (or created) a detailed process map for exactly what it is this division does and exactly how this division does it. This will then give you enough information to be able to negotiate better penalty clauses and payments based on actual data rather than something the outsourcing division is arbitrarily asking for?"

I think I hit a nerve there as my neighbour retreated quickly into his house with a nasty facial tick starting just above his left eye.

It never ceases to amaze me how companies - respected companies at that - can hope to enter into outsourcing agreements without knowing (from either side) what exactly they are outsourcing.

But it doesn't have to be that way.

I worked a couple of years ago with a pharma company that was outsourcing part of their clinical trial work to a third party clinical trial organisation. The first thing we did prior to bringing anyone in was to create a current state process map of the whole of the process to be outsourced. This allowed us - in negotiation with potential outsourcing companies - to delineate exactly which part of the process would fall under the jurisdiction of our company and which would be their responsibility. It also defined what the interactions would be between the two companies (the hand-offs and 'white space' which cause so much problem). Ultimately when we got into negotiations about the terms of the outsourcing we were in a much better position to be able to state our case for what was needed. It also meant that the outsourcing company was clear on expectations and responsibility.

With the current economic climate there are numerous companies that may be considering putting up some or all of their internal work for outsourcing. It is essential that you know and understand exactly where the demarcation lines are on this outsourced work.

Here are a few tips:

1) Before you go to any external company create an 'as-is' view of your current process. (I'll be talking about 'as-is' and 'to-be' processes in a later post). If the outsource company wants to change this process when they are managing it then they can do so. But only within the context of the following point.

2) Identify from your as-is process exactly which steps you are willing to outsource. (The whole philosophy of what to outsource is outside the mandate of this post but suffice it to say that you should not outsource your key business process - whatever that may be). Changes to the process by the outsourcing company must still fall within the steps you have defined above.

3) Concentrate on the linkages between your in-house and outsourced processes. What are the hand-offs? Who has responsibility? What is the regularity of data transfer? Again, if the outsourcing company has changed the process internally then they should still provide the appropriate linkages, to your satisfaction of course, back to your process.

4) Identify and define the expectations around those linkages. This is your means of controlling the outsourced process. The whole outsourcing contract will revolve around the ability of the company to provide what you need via the linkages you have defined. If they cannot provide what you need through these linkages then they are not the right outsourcing company for your needs.

5) If internal quality of process is key, define metrics to manage this. In other words if you are only bothered about what comes out of the process at the hand-off's, then only measure the hand-offs. If you are concerned with how the outsourced process is working then put measures in place to track this: For an outsourced clinical trial you would want, for example, to track patient enrollment rates, patient drop-out rates and adverse event information. But for outsourced printing you might only want to track quality of received product and turn-around times.

Outsourcing is probably one of the better ways of reducing your bottom line in the curent economic times, but it will only do so if you are aware of exactly what you are outsourcing and why. Address a couple of the points raised in this post (and get the right people in to help you define your process) and you are well on the way to doing this.

---

Reminder: 'The Perfect Process Project' is still 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.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

The "As-is" vs 'the "To-Be"

Image via wikipedia

I am a big proponent of 'As-is' modeling. Unfortunately I appear to be in something of a minority.

When I work with clients I am constantly reminding them to document what they are currently doing before they move onto their future state. Quite often the reply I get is "If we're going to move to our future state we shouldn't waste time documenting the old way of doing things" I can certainly see the logic in this statement. However it does ignore one of the fundamental issues which cause problems on projects and that is "Change". Let me explain:

In 'Alice In Wonderland' Lewis Carrol wrote 'If you don't know were you are going any road will get you there'. I think this is the polite thinking behind a lot of process project leaders. They don't know where they are going and therefore they try to manufacture a way of getting to this destination not even knowing where they are going from.

In real life if you are using a satnav to navigate to a destination it always has to know where you are starting from in order to determine the best way to the destination. Granted, it can produce a number of different routes to get there, but they are all predicated on the fact that you know where you are starting from. No navigation system in the world can work effectively without knowing a starting and ending location.

Let's go back to our early map reading days before the satellite navigation systems became ubiquitous. We used to start with a road map, or an Ordnance Survey map, and plot our route to our destination But we always started on the page which showed us where we were at the beginning of the journey. There was no other way of doing this. It happens in the world of aviation, marine navigation, and orienteering. There is no way of navigating to an unknown destination without knowing where you are starting from.

So why do projects try and do this when implementing processes?

Not creating an as-is situation is tantamount to starting your journey to a new destination without knowing where you are now. It is like opening your road atlas at the destination age and hoping to navigate their without checking the page that has your origin location. It just won't happen.

However there is a flip side to this argument. There is an old joke which goes something like this "A guy was lost in the countryside and he stopped to ask one of the locals. He said 'How do I get to the castle'. The local shook his head and said 'If I was going to the castle I wouldn't start from here'" In other words 'This is the wrong starting point to get to where you need to be'. In the process world there are also 'bad' or 'wrong' starting points. Heavily outdated manual processes that no longer reflect current working practices and which are due to be replaced by automated systems, are an example of this.

But even so, documenting what actually happens (as opposed to what should happen) is usually a good place to start

Can anyone think of a reason why an 'as-is' process would not be documented?

---

Reminder: 'The Perfect Process Project' is still 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.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Dead Time... How do you treat yours?

Image by Stuck in Customs via Flickr

Craig over at The Process Ninja has an interesting little post discussing 'Dead Time' in processes. Basically it comes from a study which occurred many years ago where 'fast' workers could only work flat out for a length of time before dropping back and becoming unproductive, whereas 'productive' workers worked constantly at a lower efficiency rate. Overall the 'productive' workers beat the 'fast' workers. The difference between the 100% worker rate and the 'productive' rate is what Craig calls "Dead Time". He gives a couple of, admittedly simple, examples:

...is it worth installing new lifts in a building that are super fast to enable employees to get to their desks quicker? I'd say probably not as this period of time may fall into 'dead time'. Is it worth spending money on a super fast coffee machine in the kitchen? Probably not because people will still stand around and talk to whoever is in the kitchen at the time.

Now this got me thinking about the application of 'dead time' within process management itself. It obviously has applications within aspects such as simulation: Whenever you are working through simulation there is always the temptation to try and load the figures one way or another to affect the results. In a given simulation step you will have metrics values such as 'Total work time' and 'total delay time' as well as 'transit time' and 'queuing time'. Nominally these times are gathered by monitoring existing processes and recording the time for the process steps there. The problem with that is that you can quite easily forget about the dead time in the process. Isn't it easy to watch two or three people who are working a process step and capture the fastest time as a 'best practice' timing? The obvious problem with this is that if this person is not the most productive person you could be falling into the trap of ignoring the 'dead time'

The other thing with 'dead time' is that it affects productivity for some people but can also then start to reduce the productivity of unproductive people even more. Let's follow Craig's example of the super fast coffee machine. If the '30%' worker comes into the kitchen and sees the '100%' worker chatting with someone over a super-fast cappuccino isn't there a chance that he or she will also stop and chat for a while? Suddenly the 30% worker then become a 50% worker. It's a slippery slope.

I honestly don't think we understand - or at least acknowledge - the concept of 'dead time' enough. Fundamentally it has the ability to change the way we view processes - or at least to alter our perception of productivity within a process. It can do this either in a positive or a negative fashion too.

I'm going to do some thinking about the effects of this and get back to you with more about this soon. In the meantime, do you have examples of 'dead-time'?

(You should follow me on Twitter by clicking here)

---

Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link now and follow the instructions to get the book.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Simplify!

If I was to sum up the whole concept of process improvement in one word it would be 'Simplify'.

Too often today we get lost in the morass of detail and unnecessary detritus which detracts from the key fundamental of process design which is to keep things as straightforward as possible. After all it was the great Albert Einstein who said "Make everything as simple as possible, but not simpler." and by that I think he mean that the ideal approach to almost everything is to ensure that you have got the easiest, quickest, least complex solution to any problem that will actually solve the problem itself. That last phrase is actually critical and is often lost on people. it is very easy to make a simple solution which - when implemented- will not actually solve the problem (or - more particularly - will solve the problem in it's pure form but not in an adulterated form)

For example if I was trying to streamline an on-line ordering function the simplest it can be is to be able to buy something with 'one-click'. Our good friends at Amazon.com have mastered this level of simplicity but still there are sites around which make you go through several hoops to try and give them money. When I come across sites like that they generally don't end up received a purchase request from me. However even Amazon.com 'one-click' ordering does not work when you have 'non-standard' requests to make. These can include shipping to multiple addresses or requesting gift wrap options. This needs an alternate method of purchase. Yet again Amazon does have this purchase method included in their site. This is an example of making things as simple as they need to be but no simpler.

Recently I had cause to contact my bank to query a transaction on my account. Previously I could contact my branch directly and speak to a personal account manager who has been assigned to me. But recently the process has changed and I now contact a call centre who deal with the query. This works very well until I have a non-standard request. In this case I was asking for a refund on more than one bank charge. I was told that I couldn't request this over the phone. Despite the fact that I had answered four security questions prior to the discussion taking place they call centre employee said I would have to make a personal visit to the bank (my branch is 200 miles away) to speak to someone personally about this so they knew it was really me... I suggest this is a case where they have simplified the process BEYOND the state where it is useful.

I would imagine that if you were to think long and hard about processes you encounter on a daily basis you would find examples of both under- and over-simplification. Case in point would be a low-cost airline I have used recently who pride themselves on having the lowest fares. They was they achieve this is twofold - 1) They get the passengers to do as much of the work as possible and 2) they charge for everything they can that is not included in the ticket price. As far as getting the passengers to do as much of the work as possible is concerned, the upshot it that their processes are somewhat confused - as evidenced by the following example:

I had one bag and a set of golf clubs. The bag had been paid for as part of the check in (an additional charge over and above the original ticket price), but the golf clubs had not. The process was as follows:

* Queue up
* Give details to check-in lady
* Show passport
* Check one bag in
* Take second bag (golf clubs) round to another desk
* Queue up
* Give details to second check-in lady
* Pay for second bag
* Receive confirmation slip/receipt
* Take second bag (golf clubs) back to first desk.
* Queue up
* Give confirmation slip/receipt to first check-in lady
* Receive boarding card
* Take clubs to a third check-in area
* Show boarding card to guard behind glass screen
* Drop clubs on conveyer belt - hope they get treated well and arrive at destination.

16 steps including three queue's to check in one bag, one set of clubs and receive a boarding card. Multiply this by 180 people on a plane (although not all of them will have additional charges to pay) and pretty soon you can see the issue with the complexity of this particular process. Compare this with a similar flight I took to the US a couple of years ago:

• Queue up
• Hand passport to check-in lady
• Put bags on belt
• Select 'Aisle' or 'window'
• Receive boarding pass
• Drop clubs on an oversized baggage belt nearby

As you can see this was significantly less hassle and more efficient. Of course looking at this from the airline's point of view there is no efficiency to be gained by changing the process. There is no financial gain to them, merely improvement in their customer service. However the airline have made it perfectly clear that their priority is extracting the maximum amount of revenue from each customer rather than providing a quick and efficient service to them. Therefore a change to the check in procedure would not benefit them at all.

Have a look around your organisation or workplace. Identify where you have overly complex processes. Would they benefit from becoming simpler?

Lessons Learned - Why do we never learn the lessons?

Image via Wikipedia

I've worked in companies in the past who insist on performing "lessons learned' exercises after each of their projects. This is an excellent idea.

When each project has finished, the team gets together and dissects what went wrong, what went right and what they would do differently the next time. The points are noted down and documented in a "lessons learned' document.

I remember after we had implemented a particular financial system (Which I came in on the back end of, I might add) we sat around the table and came up with the following points:

• Better communication of objectives
• Keep the users informed. Often!
• Identify Early Adopters and use them to move the project forward
• Build great buzz to get the project excited
• Allocate budget for celebrating success.

....(The list went on and on)

My initial thought on reading these was that they were all pretty valid and all pretty obvious. In fact I would go so far as to say that they were all common sense. (But as readers of this blog will know, I regularly remind them that 'The problem with common sense is that it isn't that common!')

Let's skip forward now about 5 years. The company had taken a decision to replace their multiple financial systems with a single, global SAP implementation. The project started and had been progressing for about 18 months. I spoke to one of the local folks who was working on it to understand what they were doing and how they were getting on. In the space of about 20 minutes I found out the following:

• Senior management had changed their minds 5 times about the objective of the implementation
• Nobody in the proposed user community had any idea what was happening with the project
• They were not involving early adopters or people who were anxious to be involved, instead they were using mostly internal project people to get this going
• Nobody had a good word to say about the project
• Budgets were so tight nobody could afford to even buy branded pens or mugs let along have a team dinner to celebrate when something was implemented. Moral was quite low.
  

About this time I started to remember the lessons learned from the previous financial implementation and I dug out a copy of the document. When I matched the problems the SAP implementation was having with the problems the previous project had I could see a very close similarity.What it meant, in reality, is that despite the fact that we had identified and documented the lessons learned from the previous project, NOBODY HAD, IN FACT LEARNED THE LESSONS. Which got me thinking: Why?

I was obvious that there were problems in the way this company ran projects. They were repeating the same problems over and over again without understanding why. They were also wasting time on capturing lessons learned as they obviously had no intention of referring to these lessons in future. Or maybe it was something a little simpler than that. Maybe it was simply the fact that there was no process to integrate the lessons learned into future projects. The documents were created and filed, but at no point in the project initiation processes was any further reference made to the previous documents. The effectively fell into a black hole never to be referenced again.

Another simple case whereby a small lapse in process had resulted in wasted time, effort and money.

I wonder how many 'lapses' like this exist in your organisation...?

Distilled Wisdom - A free business process e-book

Over the last couple of years I have been keeping this Business Process focused blog. The articles that are posted here cover the whole range of BPM subjects from process facilitation to interviews with key vendors in the discipline and almost everything in between.

I have selected 22 of my more important and interesting posts and compiled them here into this small e-book which I am providing free-of-charge to you.

The book is called 'Distilled Wisdom Thoughts and Musings on the Art and Science of 'BPM' and it can be downloaded directly from my company web-site at GCP Consulting.com (UPDATE: If you downloaded and ended up with a load of garbage text, please try again)

My hope is that if you are starting to look at processes in your organisation, or you have a project underway that attempts to either document, review or update your existing processes, you will be able to glean some useful information from the 'distilled wisdom' in these pages.

---

Reminder: 'The Perfect Process Project' is still 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.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

What happens if you win the lottery? (or 'The Single Point of Failure')

Recently I did some work with a small distribution company operating from the South of England and Belgium. We looked at their general process set-up in an attempt to understand exactly how well they were organised to manage and improve their processes capability.

I was working with their head financial person who, it appeared, wore many hats. She was responsible for running the whole financial department, approving expenses, managing suppliers, creating monthly reports and even helping recruit and train new employees. It seemed that every question I asked about how the company operated appeared to come back to this single individual.

Alarm bells started ringing in my head immediately for many reasons. As an ex-auditor this situation was prime for an exploitation of 'segregation of duty' control failures. With a little bit of application this single individual could raise a phony invoice from a 'new' supplier, approve the invoice and pay the money directly into her own bank account. A little bit of judicious accounting or an unfortunate 'lost document' or two would leave her tracks completely covered and enable her to continue this for some time.

However this wasn't what worried me most. The fact of the matter was that she was a single point of failure in the company. I asked her the question "Who would take over your role and run this company if you won the lottery and left the next day?". There was no answer to this question. (Actually the question I used to ask in this situation was "How would the company cope if you got run over by a bus?" but this is now deemed to be politically insensitive..) The real answer to this question is that companies will, generally, cope, but their efficiency and effectiveness will suffer in the short to medium term, as will their customer service and, more importantly, their financial situation. Imagine if one individual knows the bank account details, the cheque book locations, the outstanding creditor balances and the key contact numbers at creditor organisations, and then all this information is lost. As bills fail to get paid creditors will start to withdraw lines of credit, causing cash-flow problems. This can lead to further inability to pay creditors and staff and, ultimately, lead to the companies failure. Granted this is an extreme example, but it can happen.

I've come across situations like this before and they are usually a result of rapid expansion in a smaller company where the supporting back-office infrastructure growth hasn't matched the rest of the organisation leaving small groups of people (or single individuals) with lots of knowledge and power. For the companies it is usually easier just to rely on the key individuals rather than to bring in and train additional people to help spread the workload. The results (as we've seen above) can be disasterous.

If we translate this situation into a process one, what we efeectively have is a very human-centric process where multiple workflows route through a single individual. This individual performs key decision making as well as holding knowledge of key business rules (and business relationships). The impact of removing this knowledge is easily imagined.

So how can we make sure this never happens?

1) Ensure every individual in the organisation has a back-up. This person has the same access, information and span of control and can take over the role in an emergency
2) Regularly hand responsibility over the the back-up individual to ensure they can cope with any issues that may arise
3) Re-design your business processes to allow multiple processing routes rather than channeling everything through a single person.

Now look at your own internal processes and imaging what would happen if everyone there were replaced by someone else in the organisation. Would your company survive? If it wouldn't, where are your single points of failure in the process?

Find them and fix them.

(Photo courtesy of Sergis Blog. Released under a Creative Commons Attribution licence)

Stormchasing - the art of business process management

Image via Wikipedia

I don't get a lot of time to watch television, but when I do, one of the first channels I usually turn to is the Discovery Channel. The main reason for this is the excellent documentaries and the second reason is for Storm Chasers.

In theory Storm Chasers as a concept shouldn't work. It is a reality TV series following a group of meteorological geeks chasing tornado's in the American mid-west. It generally consists of long shots of people driving SUV's as well as some - usually- very dark shots of clouds stretching from horizon to horizon. All this is usually done in quite inclement weather.

What keeps me coming back to watch is the same thing that attracts people to all sorts of reality TV - it's to see real people in real, unscripted situations trying to beat the odds. Storm Chasers has the usual mix of personalities some of which are guaranteed to start sparking off each other - but what they also have (and one the things that sort of attracts me more) is technology. Lot's of technology.

There are two key groups of people in the chase. One are meteorologists who are trying to survey tornado's and are attempting to capture information to help understand the forces behind these awesome spectacles. The other side are a small group of film-makers who want to take a huge IMAX camera into the eye of a tornado and film it. They - basically - have a large camera which they have mounted on a specially adapted 16,000 pound armour-plated SUV (That's right, 16,000 pounds).

Between them they use lots of electronics. The researchers even have their own Doppler radar dish on wheels (known as the DOW), as well as internet weather, lot's of complex weather measuring apparatus running through computers and computer algorithms. Yet they only seem to actually achieve their objective once every 6 to 10 tornadoes.

Why?

The reason is that they still need human intervention. The data is purely that - it is data. It is the actual state of play at a given situation. The forecast is purely that, it is a possible situation at a time in the future. The glue holding all this together is the human interpreting the data.

Now before you start wondering why I am giving you a report on some Discovery Channel reality TV show and click away I want to pose a simple question to you: How is the Storm Chaser's paradigm like managing your business processes?

Well, I see three similarities:

1) They both start with understanding what you already have.
The technology and data they have is used to create an 'as-is' situation. They need to know what the current state of play is before they can start to forecast what the future will look like (or in their case where a tornado might touch down). Sure, there are schools of thought which disagree with collecting an as-is state, but I believe that in the world of business process (as in the world of Storm Chasing) you need to know where you are starting from to work out where you are going.

2) Both can use technology to the detriment of the ultimate solution
One thing that is constantly being referenced on the program is the all powerful nature of the DOW (The Doppler-on-wheels) which is revered as the key piece of technology that is driving them forward. Whilst lots of other items are used, the key decider about future direction is the DOW. Thus it has taken on a significance out of proportion with the actual value it delivers. This is particularly true given the fact that it is a data provider and still needs interpretation. To illustrate this fact, in a recent episode a rival group of Storm Chasers - armed with just a Dell laptop and wireless internet connection - managed to make exactly the same deduction about where a tornado would land as the DOW did. This is a prime example of relying too much on the technology as a solution to the problem rather than as a human enabler. How often do we do that in our day-to-day lives as process analysts? How many times have we relied on some magical BPM tool (or similar technology) as the solution to all our problems? And how often has this proven to not be the case?

3) They still need human intervention to make things work 100%
As mentioned previously, the ability of the technology to make a precise prediction about where a tornado is expected to touch down is minimal. Sure, there are general predictions but when you want to get a truck into the middle of a tornado, you need to be a bit more precise than 'general'. In order to finesse the location they rely on the experience and expertise of other people. They have a weather forecaster on board who isolates potential danger areas at the beginning of the day and then the team leader will make a decision about where to send the equipment to intercept based on that (except often he ignores the data and recommendation and goes somewhere else). Furthermore, despite the presence of several $100,000's worth of equipment and vehicles all the data is being funnelled through the team leader to help make the prediction. So far his ability to accurately forecast - especially in a quickly changing environment - has been less then optimal. But this is a failing on behalf of the individual and his decision making skills rather than the human intervention itself. In the business world as well there are often decisions that need to be made around processes to make them 100%. As with the Storm Chasers, these decisions do not always accurately occur within the system and rely on human intervention. Again - as with the Storm Chasers - management style and ability will predicate the success of these decisions.

I found it very interesting to see the parallels between the world of the Storm Chasers and the world of the business process analysts. Although I'm not sure I want to spend my working life driving a 16,000 truck through the eye of a tornado for a living!

The Dangers of "Getting Used to it"

Craig over at 'The Process Ninja' has a great little post about the dangers of 'Getting used to it'

As he says:

It's easy getting used to something not being quite right, but we have to continually challenge and question the way things are done. Continuous improvement is all about setting up regular reviews where we need to ask some hard questions. Don't be afraid to tear up a process and start again

I think it's important for people to try and understand that just because you are in a 'comfortable' mode with the way you do something it doesn't mean that it's always the best way of doing it. Nor does it mean that you can't find a different, more efficient way of doing it

Head over to The Process Ninja blog and see if there's something there you recognise in his post