"The Way It's Always Been Done" (or how an aversion to change can hurt your business)

If you search this blog thoroughly you'll find reference to the following story, but I wanted to repeat it because I think it highlights a fundamental point when looking at processes: The need to ask yourself "Why?"

A well known UK insurance company was trying to compete with the new on-line insurance companies that could issue a policy document in three days. The current standard for this company was 33 days. A project was launched to understand why. Analysis indicated that after the policy is reviewed and approved (1 day) it was sent to a warehouse in Cardiff, Wales for storage. The state of the art warehouse was temperature and humidity controlled by computer, and stored the policies for 30 days prior to sending the final documents out to the end customers.

Further analysis at the warehouse indicated that the reason this step was taken (and had been brought in from the previous manual system when the computerised warehouse had been implemented) was not entirely clear. Everyone who was interviewed was very positive about the investment in the computer controlled warehouse and was anxious to tell stories about the speed and efficiencies that were gained by not needing men in fork-lift trucks searching for documents from the vast stores. Nobody seemed to know why the documents were stored for 30 days, though. Tracking down the longest serving employee in the company it was determined that was how it had always been done because this step was necessary to allow the policy to dry.

"Allow the policy to dry....?!?!?!"

Apparently back in the mists of time when policies were printed in ink on parchment they were stored for 30 days to allow the ink to thoroughly dry. In todays modern world this step was no longer needed. It was removed and suddenly the insurance company was able to mix it up with the new boys.

The story was told to me by Steve Towers from the BPMG at a BPM conference a number of years ago. Now I have no idea if this story as apocryphal or not and - frankly - I don't care. The reason I like it (and the reason I have retold it dozens of times in the intervening few years) is that it does identify a key problem that occurs when people look at streamlining processes and making them more efficient.
'That's the way it's always been done'
This is the curse of modern society (ironically enough). People are hesitant to change things that have traditionally been done because they think that this will - in some way - cause bigger issues.

I come from a background of heavily regulated industry. This is the sort of place where you need to have 24 people review a document before it can be officially approved. When electronic signatures were introduced into the process it was still felt that all 24 people needed to review each document despite the fact that research showed that, in fact, only about 5 people in each case had input into the review, the others either didn't review it or too so long to review it that the whole approval cycle took forever to complete. Reviewers were added so that they couldn't later come back and say 'Well I didn't know anything about this'.

When we looked at the problem through a different lens we were able to say 'Suppose this document was stored in a central place and you were informed when it was updated, would you be happy to take that as proof that you were informed, given 3 working days to come back with issues and - if nothing is heard - we take it that you are aware and up-to-date?' By adding in this 'Implicit review' step we were able to do several things.

1) We were able to minimise the number of folks reviewing the actual document.
2) We were able to substantially reduce the approval cycle time for a document.

The key was to ignore the way things had been done previously and concentrate on why we need to do things a certain way now.

So take a look around your own organisation and ask yourself the question 'Why are we doing these things? Is it because this is the way things have always been done?"

You might be surprised.

Just a reminder the free download 'Doing Business Process Work in your organisation - A White paper' is still available. Click this link and follow the instructions. Your White paper will be sent as soon as possible. Don't miss the chance to get this valuable insight into how to make business processes work for you!

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

All information is Copyright (C) G Comerford

Technorati Tags: , , , ,

BPM in the Pharmaceutical Industry

Being an ex-pharma employee myself (no names here, but the company invented Prozac...), I was interested to read the CIO.com article about the use of BPM products in the pharmaceutical industry.

The article itself (by David Carr) applies to Wyeth Pharamaceuticals, but I know from experience that the concepts and issues identified would be applicable to any and all pharma companies.

The thing that makes this interesting is that the driver for the BPM work actually came from the R&D function. In my experience the R&D function is very freewheeling and one of the last parts of a Pharma company to promote adherence to standards. This is particularly true of technology, for example, where non-standard applications and systems are rife. However as the Wyeth CIO Jeffrey E. Keisling mentions, they were looking at results rather than technology adherence. The key result of this initial phase of work is that they were able to streamline the process for label creation (This is an extremely time consuming and fiddly process where data from diverse parts of the organisation has to be collated, analysed and presented in a manner which is acceptable to regulator authorities).

What is less surprising is the way in which BPM has ben embraced within the IT part of the orgaisation. One senior IT person is quoted as saying that with the use of the Metastorm BPM tool they have been able to reduce the cycle time for program development to a point where they are doing twice as many projects in a year as they had planned. Now don't misinterpet this to mean that they software helps them code programs twice as fast, my reading of the situation is that it doesn't completely eliminates the need for a software development effort on the projects. What happens is that a business analyst can do more of the up-front work of defining a business process, but there is still additional effort needed to integrate the systems that must work with the BPM software. However, overall the cycle time is lower.

As I mentioned above Wheth have done this using the Metastorm BPM tool. On of the problems they have found with this tool, though is that it is very IT-centric. To combat that they have started to implement the Provision modelling tool. This is a more user-focused tool that allows processes to be modelled intuitively then permitting them to be dropped into the BPM tool for coding up.

Feel free to read the complete article as it has some excellent points, but if you don't wish to wade through 5 screens worth of text I have extracted the following 'gems' from the article, which I think apply to process management in general

1) Do whatever is needed to get buy-in for this. Wyeth had stonrg push-back for purchasing the BPM tool as folks thought it replicated functionality they had in other existing tools. They were able to convince them of the business benefit of doing this

2) When you have the buy-in, build the competence. Wyeth are building a Centre of Excellence which is something they only do for strategic parts of the business. This has the dual benefit of creating a single organisation responsible for standards and metrics as well as providing resource to help build and improve the process management capability

3) Start small, go viral. Wyeth took the same approach I did with BPM in Pharma - they started small. Instead of rolling out a large project encompassing all areas of the business they identified a smaller, key project that would benefit, succesfully rolled this out and stood back. Other parts of the organisation saw the succes, decided they wanted that as well, and it went viral. This is, by far, the easiest way of implementing major change in an organisation.

4) Bust the silo's. For Wyeth, the decision to focus on BPM emerged from an analysis of where the research systems group was putting its energy. The tendency was to create systems from scratch each time and build them in-house. On top of that the focus on transactional systems was shifted more towards integration of systems rather than improving transactional systems. This meant identifying individual processes within a system and then tying these processes together across systems. This, effectively, meant busting the traditional silo mentality which resides in many large , well established companies.

This article corresponds very closely with my own experience implementing processes within the Pharma industry. The very tight governance and regulatory aspect makes every job more difficult and time consuming than with many other industries. This causes a great deal of inertia in companies in embracing change. But by following some of the tips here and emulating both Wyeth and my last company, it shows that this inertia can be overcome to great benefit.

Photo courtesy of Rodrigo Senna
Technorati Tags: , ,

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

All information is Copyright (C) G Comerford

Get the Process Cafe by Email!

I have just enabled e-mail subscriptions to the Process Cafe.

Those of you who wish to read this blog and don't want to use RSS (which is approximately 80% of the population, apparently) can now subscribe to an e-mail version which will be sent to you whenever the site is updated.

Just click on the link below to subscribe or fill in the form at the right hand side of the page and click 'Subscribe!'

It couldn't be easier.

Click here to subscribe

(I promise that all e-mail information is safe, will only be used for the Process Cafe and will not be given, sold or lent to any other person/company or entity)

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

All information is Copyright (C) G Comerford

Doing Business Process Work in your Organisation - A White Paper

For those of you who are interested there is a new white paper out called 'Doing Business Process Work in your Organisation: A Practical Guide to Success'.

It's the first in a series of papers I'm doing leading up to the release of my eBook 'The Perfect Process Project' which is now complete and ready to go.

Click this link to read more about it and request a copy through email. It's a 5 page PDF that should take you about 10 minutes to read.

PLUS: If you do read the white paper it will tell you how to get a separate document called 'The Art of Process Facilitation' which gives you lots of tips about running facilitated sessions to define processes.

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

All information is Copyright (C) G Comerford

Technorati Tags: , , , ,

The kittens and the business rules..

So, for various reasons over the weekend I ended up feeding 6 felines. (Not the ones in the picture! Thanks to rodrigobasaure for the snap) 2 were mine (10 months old), 1 was next doors (17 years old, arthritic) and 3 belonged to a friend (2 young 'uns of 18 months old and a very infirm 18 year old cat who's been given The Last Rights 3 time by the vet)

Why do I tell you this (and what's it got to do with processes?) Well, in principle the process of feeding a cat is quite straightforward:

1) Locate cat food dish
2) Open cat food container
3) Dispense appropriate amount of food into dish.
4) Give to cat

This works for all cat's, regardless of age etc.

However, the problem comes when the cats have special medical needs. For example: My two are straightforward. I follow the process above. End of story.

But next doors cat has need of medication for her arthritis. It's a syringe of goo (4.5ml) that needs to be squirted on her food once per day

And the three cats that my friend has are peculiar too. The old one has completely different food than the two younger ones. It's special food to help the renal problems he has. Plus he needs lactose on it to help some other complaint. The lactose is 1/2 spoonful administered with all meals.

The two younger ones have normal food like my two. But here's the problem. The older cat doesn't like eating his food and prefers the younger cat's food. And the younger cats would rather eat the renal food with the lactose on (go figure!). So they need to be separated and watched to ensure no cross contamination.

How does that effect the process?

Well it causes issues. If we change the process to deal with the arthritis medicine, it won't work for my two (or the two younger ones of my friend), however if we add a decision to the process to deal with the discrepancy, we then need to complicate the process through the addition of a separate process for 'food with medicine' vs 'food without medicine'. This works (and it works very well) but it wouldn't deal with the need to separate the cat food between the older and younger cats.

I can't help feeling that there should be a different way of looking at this.

This is where decision systems and business rules come in. This is also where the proceduralisation of a written process takes over.

Let me explain.

What happens in a particular sequence of events is the process. The three items I listed at the top of this post, for example. How that actually gets implemented is the procedure.

In the case of the process for feeding the cats I would modify it to look something like this:

1) Locate cat food dish
2) Open cat food container
3) Dispense appropriate amount of food into dish (as per business rules).
4) Add medicine (as per business rules)
5) Give to cat (as per business rules)

When the detail behind this is understood for each occurrence of the process then we get a procedure. This can be governed by 'business rules' as well. In essence we end up with three procedures related to the same process
  • one for feeding my cats (business rule says 'no medicine')
  • one for feeding next doors cat (business rule says 'Arthritis medicine, 4.5ml once per day)
  • one for feeding the three cats (business rule 1 says 'Renal food for old cat', business rule 2 says 'Lactose on renal food', business rule 3 says 'Feed old cat and young cats separately to ensure appropriate food is eaten'
So it appears that a fairly simple process can - with the addition of appropriate business rules to aid decision making - be turned into a set of more comprehensive procedures.

Where could this apply to your business?

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

All information is Copyright (C) G Comerford

Technorati Tags: , , , ,

Getting started.....

James Taylor at Smart Enough Systems has written a post about getting started with Decision Management Systems.

Although I'm not an expert on Decision Management I can see the sense in what he is saying.

It also struck me that the steps he mentions there are very similar to the best ways to start a general process definition project:
  • Begin - even if the first version is not perfect or even close.
    With a lot of process projects the momentum is what carries it through. If you can move from the 'planning what we are going to do' into the 'we are doing it' phase you've overcome a huge barrier and are well on your way to being successful
  • Build - for change not to last.
    Chances are things will change. Your processes run your business but they are guided by your business strategy. If that changes your processes may need to change. Have a good change management process in place.
  • Test - to see what works better.
    Keep working on your processes to determine if there is a better way doing them. Try different alternatives to see if something works better. Move an approval to a different stage of the process. Batch items together. Merge roles. Be creative.
  • Measure - to see how it’s going.
    I'm a big fan of measuring processes (ideally using Comerford's Three Laws of Metrics). Remember if you're not keeping count you're just practicing!
  • Iterate - keep updating and improving the process.
    Fail fast, learn fast, respond faster than your competitors.
Thanks to James for his post

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

All information is Copyright (C) G Comerford

Flying - a complicated process?

In a recent post I talked about the linkage between golf and process. My contention was that good golf is process based to the point where measuring the appropriate item and focusing on improving the process around that item can reap dividends.

Now I want to expand on that by giving an example where this is not appropriate


Last year I got my Private Pilot's Licence and I now spend as much time as I can afford in the 'wild blue yonder' learning as much as I can about the plane, navigation, Air Traffic Control, circuits, VP propellers etc. etc.

It struck me recently that flying is very much process based and usually it is when processes fail that aircraft accidents occur.

Let me give you an example: Most Controlled Flight Into Terrain (CFIT - basically a plane hitting a hill, mountain or rising ground) is a result of several factors: Tiredness, lack of concentration, spatial disorientation, flight into poor weather, lack of communication, wrong pressure settings on the altimeter and poor flight planning. Basically all of these can be solved through an appropriate process.

Tiredness: Business Rule"Don't fly on less than 8 hours sleep"
Lack of concentration: Process step "Follow appropriate check lists when operating"
Spatial Disorientation: Process Step "Follow Instrument readins to remove disorientation"
Flight into poor weather : Decision "Is weather bad? If yes then turn back or land immediately"
Lack of Communication : Process Step "Always contact ATC and keep them informed" plus 'Read back all clearances and permissions"
Wrong presure settings on Altimeter : Business Rule "Review Altimeter setting regularly and confirm setting with ATC"

This is, actually, a rather flippant approach to what is a very complex matter.

Flying is controlled by processes. Check lists, standards, licenses, ratings, reviews, evaluations etc. All of these things apply to pilots worldwide - from folks like me who have less than 100 hours experience on a single-engined plane right through to the guys with thousands of hours flying 747's across the globe. We are all subject to the same standards when it comes to flying.

All of these standards boil down to one thing: The correct way to operate a flying machine. In other words the process of flying. Every plane has a Pilots Operating Handbook (POH). The POH mandates performance envelopes for just about every factor regarding the plane itself: How much fuel it can carry, how much fuel it uses at what speed, how fast it can climb, how high it can climb, what is the best speed to glide the plane in at if there is an engine failure, what's the fastest speed this plane can fly without damaging the structural integrity. In the process world these parameters are either business rules or decision criteria.

Likewise, a pilot has a set of criteria to govern how he flies: Is he approved to fly this type of plane? If he is, can he fly in bad weather, or at night? Can he fly a plane with more than one engine? Can he fly a plane where the cockpit is primarily computer screens rather than the traditional dials?

Even before getting into the plane the pilot has a list of items that need to be carried out - the pre-flight checklist: How much fuel is in the tanks? Has the engine compartment been visually checked for oil leaks? Is the oil level in the engine between acceptable limits? Are the flying surfaces free to move? Is there damage on the leading edges? Do the wheel supports have sufficient travel in them? Are the pitot tubes blocked? Are all the radio aerials attached correctly. Do the flaps extend fully? Does the fuel pump work? Do the radio's work?

The list extends once the pilot gets into the cockpit: Are the dials functioning correctly? Are the circuit breakers set appropriately? Is the compass deviation card present and up to date? etc. etc. etc

Even when talking on the radio there is a set protocol to be followed (In fact you can't use a radio without having passed a specific exam and been granted a Radio Telephony Operators certificate).

All of these things work together to reduce the possibility of misunderstandings, omissions, errors and issues.

But of course problems still occur. So why is that?

Mainly, because there are human factors involved. A large proportion of aircraft accidents have an element of human error as the attribute. The worlds worst air crash (Which occurred between two 747's on the runway in Tenerife in 1974) was caused by a pilot hearing what he wanted to hear on a radio and not what was actually said. This was because he wanted to hear a take-off clearance rather than a delay. A delay would put the crew passed their flight window and result in them not getting back home that evening. He heard a take-off clearance and went, unaware that another 747 was taxying up the runway at that point. The two planes collided in fog resulting in 583 fatalities. At it's basic level this was a process failure because the pilot did not read back the correct clearance and this resulted in a communication error.

Let's come back to earth (so to speak) and talk about something a lot less drastic, but still as dangerous: Carb Icing. Without going into too much detail, propeller planes that are not fuel injected have a carburetor. The carb feeds high pressure air into the engine to allow it to work. however the mere fact that it is high pressure (it is forced into the engine through a constriction rather like putting your finger over part of the end of a hosepipe) means that certain physical forces come into play regarding temperature. The long and the short of it that under the right conditions (i.e when you have lots of moisture in the air and cold air in the carb - or example when you reduce engine power), a large lump of ice can form in your carb and stop your engine. Not what you want! To combat this, engines have a carb heater which can be turned on to remove the ice blocks. They generally work like a treat. However they can't be left on too long as they reduce the efficiency of the engine. Therefore there are key moments when you can add carb heat to be most effective.

The process says you add carb heat when reducing power on a warm day. The process says you add carb heat when making final checks for landing (although you don't keep it on). What the process doesn't say is that you add carb heat during taxying over wet grass on a cold day. However this is another occasion when ice can form.

So is the process wrong? No.

The 'rule' attached to the process says that carb heat should be applied 'whenever conditions for carb icing are present'. Training should indicate that any occasion which would allow moist air to enter the carb under conditions where the temperature is low should warrant carb heating. The problem is that the conditions for carb heating are not always known and understood.

Believe or not carb ice can form in an engine when the outside temperature is 20 degrees celcius. It can also form very quickly so action needs to be taken ASAP. I learned to fly in Florida with very high ambient temperatures, but was still taught to add carb heat at the appropriate time.

All this could lead us to think that even if the process works correctly there are always circumstances where things can fail. This is, of course, absolutely true. What happens when all the process and procedure is followed and there is a technical issue with the carb heater? Answer: The engine will probably starve through lack of oxygen, stop working and you will be forced to follow a different procedure that of an emergency landing.

"But isn't flying a skill rather than a process": I would maintain (in a similar way to my golf analogy of recently) that the skill comes in the application of the process to the best ends. Good pilots are those who have technically applied the process to a finite degree of skill. The guys who know exactly the correct approach path to bring a plane down at it's POH operating speed and bleed the airspeed off until it stalls right onto the ground without a bump or a jump. These are the guys who are following the process in exactly the right way. The pilots who drop the plane from a height after realising they are going to overshoot the runway, slam the wheels onto the tarmac, bounce (or 'porpoise') three or four times down the runway and then wear the brakes down trying to stop before reaching the end are the ones who haven't followed the process correctly.

Being a good pilot actually means being a skillful process follower!

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

All information is Copyright (C) G Comerford

Eyes bigger than your brain...?

James Taylor at Smart (enough) Systems has a great post about Ostriches!

Basically the Ostrich has an eye bigger than it's brain, and James is drawing the analogy between that and managers who want lots of data on a dashboard that they can look at (eyes) but not process (brains)

It all links back to Comerford's Third Law of Metrics which states that "If you're going to measure something at least have a way of feeding it back into the process and affect change" Too many managers and senior executives have fantastic looking dashboards with lots and lots of data on them only to realise that they're either not measuring the right things, or if they are they're not doing anything with that data.

James put's it very succinctly when he say's
.. far too many organizations are obsessed with what they can see in their data and spend far too little time thinking about what to do based on their data.
Couldn't agree more.

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

All information is Copyright (C) G Comerford