The problem with BPM Solutions....

BPM software is big business today. There are, literally, dozens of companies on this particular software space. Gartner classify some of them on various different magic quadrants. Forrester classify them on various different waves. Every day companies are pitched at by software vendors to put in the latest and greatest tool to help them.

But are they any better than people?

At a fundamental level, the answer is - obviously - yes. Software well designed to fulfil a particular task will always beat a human doing the same task (providing the task is something that can be automated or computerised - I wouldn't want a computer performing open heart surgery on me - although computers are now driving cars by themselves). A machine which is programmed to deal with workflow simulation is always going to be able to simulate thousands of transactions through a workflow better than a human.

But do we need them? Do we need to purchase a BPM system in order to be able to implement BPM in an organisation? Is it necessary to spend outlandish amounts of money to make BPM part of your everyday workflow? No. It isn’t. 

BPM - at a fundamental level - is the analysis and implementation of ideal process flows. These can be repetitive, or on a case-by-case basis. But they do not HAVE to be implemented via a computerised system. 

Working on basics it is simple enough to perform process analysis using pens, sticky notes and brown paper. This can then be documented in a workflow drawing, or a process flow, or a procedure. Employees can be trained and the new procedures can be implemented. All of this can be done without a dedicated BPM system.

But why would you?

Well, for one thing, you would do this to determine whether you have the right mindset to implement BPM It is wrong, in my opinion, to think that implementing a tool to solve a problem will solve that problem. Time and time again we see examples of computer systems being put in place to solve problems that don't actually solve those problems.

The problem itself, is, of course, that the problem under consideration is the wrong problem. (There were a lot of problems in that last, sentence, heh?). By this I mean that identifying a problem that needs a tool solution is the wrong problem. It’s similar to saying “This patient has a heart problem that needs a stent”. NO. The problem is that the patient has blocked veins. The stent is a solution for that problem.

Likewise companies become enamoured of the software solution to help them become more efficient, more effective, more responsive, whereas the problem may not be that the company is inefficient, ineffective or unresponsive in the first place.

This is why the first step in deciding whether to implement a BPM solution is NOT to decide to implement a BPM solution. It is to decide what the issue is that you are trying to address. Remove the system from the equation. Ask yourself  “If I was doing this manually, what is going wrong?” Understand what is the fundamental underlying item that needs to be changed to make your problem go away.

Losing customers? The problem might be that you need a CRM solution to better handle them. But it might also be that your product doesn’t give them what they want or you aren’t selling it right (See Jeffrey Gitomer for more about that) 

Manufacturing not fast enough? It might be that you are wasting time on a particular piece of the process and creating a bottleneck. But it might also be that your line is old-fashioned or your employees aren't trained to operate it correctly.

In the examples listed above, knowing what the actual problem is can lead to a completely different solution to the one first anticipated.

That's a good thing.

---

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

When people don't understand controls.

I had an interesting situation occur today. 

Recently I've been in discussion with an organisation who want me to do some work for them. As part of this, they set up a new e-mail account for me on their domain email system. I received the confirmation e-mail details from a third party supplier who deals with setting these things up for them. The third-party supplier had sent my username, e-mail, POP details, SMTP details, and other e-mail information to me, in an e-mail, in plain text. In addition, they had copied in two members of the third party and my potential future client contact. One of the third party addresses was a generic e-mail account for "IT Support". 

So far, so straightforward.

Then I wrote back to the 3rd-party asking how can I change my e-mail password because it was sent in plain text to several people, most of whom I don't know and wouldn't trust. Their reply?  "There is no way of changing your e-mail details. It's our policy." When I pointed out, from a process point of view, how much of a risk and liability this was, the organisation said that because theirs was a small business and everybody knew each other "it was okay". 

Basically this organisation has now said to me (in not so many words) "We are setting up an email account for you. The password details are know to several members of the organisation, you can't change them and we're comfortable with that."  The logical extension of this was that I personally now have no further accountability for anything sent from my e-mail account as I couldn't guarantee that I was the only person using it.

The next communication I received from this organisation was a note telling me they were terminating their agreement with me and we would no longer be working together.

Which I am actually quite pleased about.

Can you imagine the situation if something went out to a client under my e-mail account and it said something inaccurate, derogatory, racist, sexist, libelous, rude or illegal? The fact that it was under my name would immediately throw the finger of suspicion on me, whereas - in effect - anyone in the host company IT department could have sent it.

Of course my contact in the organisation was working on the basis that 'It won't happen because we trust each other', and I understand that. But trust in an organisation will last until an employee feels disgruntled, has been badly treated, or decides they no longer want to play by the rules. This increases dramatically when you bring in a third party IT service provider who has no vested interest in me as an individual.

All in all the situation was fraught with potential for disaster.

But it did bring up the bigger process question about controls. A process will only work well if it is controlled appropriately. This doesn't mean it needs lots and lots of checks and balances at all points, but it does need something in there to ensure that the actual outcome of a process is the same as the required outcome.

In audit terms this could be something such as segregation of duties (making sure no single role has too much power to be able to subvert the outcome), or appropriate authorisation (ensuring that there is more than one signature required on a check, for example). No single control will work for every step of a process, but taking an overall look at the process and understanding which are the key controls that are needed is one way of building integrity into the process itself.

How many of your processes have appropriate controls built in?

---

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

Can you outsource customer service?

Just a question that occurred to me: Can you outsource customer service?

Outsourcing of business processes is becoming more and more prevalent. But the logical extension of this is that you can outsource your customer facing processes. After all this is what call centres do. So the question arising from that is 'Can you outsource customer service?'

Sure you can outsource the service function. But is this outsourcing the service?

I posted this question on a number of BPM/ process related forums. Here are a selection of the replies I received:

'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).

Process inconsistencies hit the customer... Again.

I rented a van last week. Just a standard Luton van. I used it for transporting some set pieces to the performance venue for a local group I am a member of.

When I went to the rental location I took my drivers license and the associated 'paper documentation' which is issued by the UK DVLA. This details all the endorsements "points" you have as well as your entitlements to drive (Motorcycle, Heavy good vehicle etc.)

I've rented vans from this location before and they have my details on file so I filled out the form, signed on the line gave them my credit card and went. The guy didn't ask to see my license or paper documentation but did ask if I had any endorsements since my last visit (which I hadn't).

This week I had to rent a van again now that the production has finished. I asked a colleague of mine to drive me to the rental location. At the desk the woman asked me for my driving license (Which I supplied) and for the paper documentation. I told her she didn't need it as the last time I rented a van I hadn't needed it and all my details were on file. She insisted that I needed to produce the paper documentation. I told her I hadn't brought it because last time I brought it to this same location I hadn't been asked for it.

She insisted that she needed to see the paper documentation before she could rent the van to me. I told her that I didn't have it with me and she would have to phone the DVLA to get the authorisation (This is a 'fall-back' process which has been put in place for just such a situation)

"It's Sunday" she said. "The DVLA isn't open"

So, in other words, because she is following a different implementation of a standard process, I would have to schlep myself back home (with my colleague who had dragged himself out of bed early on a Sunday morning) just to get a piece of paper which I had told her was all in order and wouldn't need to be checked when she got it.

Stifling the urge to strangle her (or at the very least to use harsh language) I went back and got the documentation and the deal was done.

But it got me thinking. Where did the process break down? I had taken the right documentation last week but hadn't been asked for it. Obviously it wasn't needed as part of the process otherwise I wouldn't have been able to take the rental van. If this was my first time renting with them then this would have been different, but because they had my details on file the process was modified. If a licence had been needed to rent a van the process would have stopped me from taking the van away when it wasn't presented, like a credit card. A credit card was needed to rent the van. If I hadn't taken a credit card then I wouldn't have been able to rent the van. Therefore the credit card was needed, but the license wasn't. It might have been desired, but it wasn't needed.  If it wasn't needed, then I shouldn't have had to schlep back home to pick up the documentation this week.

If, on the other hand, the first guy had made a mistake and let me take the van without seeing the licence - despite the fact that it was needed - then their internal process is broken to such an extent that a major check such as this was bypassed. Either way this company has a problem.

As a customer the aim of the company should have been to make my interaction with them as painless and as rewarding as possible - especially in a service industry. But this company obviously doesn't work that way. To quote the BPM guru's on the web 'The company doesn't use 'outside-in' thinking". It's one of the process maxims: 'Keep it as simple as possible'. Having my details on file was meant to keep things simple. Requiring me to produce additional documentation was complicating things when it wasn't needed.

Should I avail myself of their services the next time I rent a van, or should I go elsewhere?

---

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

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?

How ONE Bad Business process Doomed GM

Just had to draw your attention to this excellent post entitled 'How ONE Bad Business Process Doomed GM' from the Bex Huff blog.

Look at the article and - as you read the decisions made by GM regarding their business process - think carefully about what the issues are associated with this. Try to understand exactly what problems will ultimately arise as a result of it and then ask yourself 2 questions

1) Why couldn't the GM senior management see this?
2) How many similar decisions are you making in your organisation?

Eye opening commentary from Brian Huff. Great post, Brian!

---

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

Ryanair's process issues.

Image via Wikipedia

A couple of months ago over on the 'Flying Cafe' blog, I wrote a post about what I considered to be a misleading airline ticket pricing strategy. The airline - Ryanair - had advertised a 'free flight' which ultimately could have cost me as much as £105 including taxes and the 'additional charges' they levy.

This follows a discussion on the Linked-In Business Process Group where Steve Towers was positing that Ryanair's business model had improved as a result of a proposal to remove check-in desks at the airport. He called this the removal of a 'Moment of Truth' in the process. I argued against this saying that Ryanair may have a cost saving business model (although their profit percentage has decreased steadily over the last 3 years despite rapidly increasing revenue), but as a model for creating satisfied customers it leaves a lot to be desired.

Well this week I actually took the flight and I wanted to post a few thoughts on some of the process issues I picked up whilst flying with them.

I checked in at Bournemouth Airport for a flight to Southern Spain. 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 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 Ryanair'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 Ryanair have made it perfectly clear that their priority is extracting the maximum amount of revenue from each customer rather than providing a peaceful and efficient service to them. Therefore a change to the check in procedure would not benefit them at all.

If you would like to see my overall thoughts on 'The Ryanair Experience' then click here.

For those of you who know about these things, is this similar to the modus operandi of Southwest Airlines or do they tend to go more for customer service as well as cheap fares?

It's a TRAP! - "Documenting" processes rather than managing them

Image by c w l f o t o g r a f i via Flickr

You know you've done it. The boss has said "Let's get our business processes sorted out" So you've drafted in some Visio guy who's put together your business process documentation. Now it has been printed off, bound up, reviewed and signed by the department head. Everyone is happy, right?

Wrong!

It's a waste of time and money doing this because it's just paying lip service to the whole concept of business process management, and will result (usually) in a set of documentation languishing in a drawer for years.

If you think doing this is going to help you become a sleeker, more efficient, business entity then you are sorely mistaken. This will actually have the opposite effect as your users. They will resent the time they've spent helping put the documentation together. There is no guarantee that it's the right process and therefore there's no guarantee it will actually be followed.

Actually you're not alone in doing this. Many companies have fallen into the same trap of thinking that a documented process is a defined and managed process. But it doesn't have to be like that. Let's look at ways out:

How to solve this issue

1) Don't go there in the first place.
If at all possible try to make sure that you don't confuse documenting processes with defining and managing them. If you want to get some documentation of what your processes are, bring in someone who knows about facilitating processes and get them to do the work for you. But understand yourself WHY you are doing this. If it's just to say "I've documented the processes" then you're probably doing this for the wrong reasons. If it is part of a bigger review then this is slightly better. If it is a small step in a larger Business Process Management initiative this is the best reason of all

2) Don't take the documents as gospel.
Given that you've spent the time documenting your processes, make sure this is the start of the process rather than the end. Look at how you can take the documented processes and use them as a basis for improvements. Don't look at this as the end state i.e the gospel according to St Swim-lane (the patron saint of process), but look at this as the first step in a journey to process salvation. Use the existing documentation as a springboard to build a full process documentation set - along with a process management capability.

3) Ignore and start again
I know it's painful to throw away things that you've worked hard on but the fact is that unless the process documents were put together under the authority of someone who knows how to document and manage processes, the chances are they will not be right. The might not fully reflect the process as it exists. They might not be a complete record of all the items needed for process documentation. They might not even be documented according to set documentation standards. All these factors mean that it is probably just as useful to throw them away and start again using someone who knows what they are doing. As in the previous suggestion, use this as a basis to build an internal process management capability

Build the capability
Managing processes is much more than just documenting the work in Visio. Building a process management capability involves identifying and training individuals who can expertly analyse and document current state processes, who can design future state processes and who can appropriately work a tool to store all this information in. They can identify owners at a process level, implement a governance process and put in place appropriate metrics to measure the processes.

The next time someone asks you to 'just document our processes' you should be wary of this and understand the pitfalls and problems associated with it.

With an appropriate strategy - and a couple of rules about 'what' and 'why' - you should be able to appropriately manage this request and end up with a useful end product.

---

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

Oops! - Business Continuity?.....

So I'm sitting here in the dark. Not by choice, but because there is a large power cut in the area. Everything appears to be out. I'm trying to work out how extensive the outage is, but for my purposes I'm totally without power.

Which also means I'm without heat. My heating system - although gas powered - relies on electricity to run the timer and to provide the initial spark. So as long as the guys sort out the problem within a reasonably short period of time I should be alright. Otherwise it could get cold.

Luckily the Macbook is all powered up and I can make a few notes ("when life gives you lemons...") although I can't post this immediately because my router is not working.

I figured now was a good time to break out the candles so I can actually see where I'm going. I fumbled my way to the kitchen using the light from my cell phone and found the candles in the drawer. Hah! Now.. matches.

No matches!

I'm not a smoker so I have neither matches nor a lighter. Never fear I'll use the gas ring on the cooker to light one. ... except that the cooker - like the heater - runs on gas but relies on electricity to provide the initial spark. Damn!

I've found a torch in the meantime. It's a small 'penlight' torch which works off a single LED bulb. Very bright but, unfortunately it doesn't throw the beam too far because the batteries are running low.

The other 'big' torch that I have near the front door ready for emergencies is still awaiting the four very large and incredibly expensive batteries it needs to operate.

So, basically, I'm stuck in the dark and the cold using the screen from my Macbook to see by.

Which got me thinking (as these things do) about business continuity planning. I, quite obviously, have an excellent disaster recovery plan (candles, torches etc.) but this has never been tested. (To be fair the house is prone to power outages but this usually occurs during the day when light and heat is less of an issue). As a result I am in the same situation that a lot of businesses are in when it comes to their BCP.

I'm stuck.

A business continuity plan is a set of tested instructions (a process, no less) for managing during a disaster of some sort. The key in all of this is that BCP's have to be tested.

In my case it's no good having a power outage only to then find out that I have candles but no matches, torches but no batteries, and heating but nothing to start it with. In the big scheme of things this isn't a major issue for me. I can sit for a while, wrap up warm and wait for the utility company to sort things out. If nothing is fixed within a couple of hours I can drive to somewhere with heat and power and stay there (assuming this isn't nationwide - and as the trains are still running I have to presume this isn't the case)

But if I was a company, with customers, orders, employees and deadlines something like this could be terminal. BCP's are meant to be plans to allow your business to continue (the clue is in the name). If it comes to the crux of the matter and you can't run your business in a disaster than you are in big trouble. (O.K. in a disaster of Hurricane Katrina levels the last thing on your mind will probably be restarting your servers and raising invoices, ... but still).

Most businesses only find out that their BCP's are not working when they come to use them for real. They find - like me - that they don't have all the resources they need to continue, that the plans they have set up to take over various functions rely on items or people that are not available and that they are now officially in trouble

When was the last time you tested your BCP? Do you even have one? Are you concerned? You should be. Otherwise you might find yourself sitting in the dark trying to find a match.

What's "Best" in "Best Practice"?

How does "Best Practice" come to be? Is it just an example of "most common practice"?

It's a question I often ponder when confronted by "guru's" who talk about following "Best Practice". Oh, don't get me wrong, I think there are certainly bad ways of doing anything and, therefore, there are better ways of doing something. But does this constitute a "Best Practice"?

The problem I have with "Best Practice" is that it isn't always "best". Often times it's one company succeeding in a business then being approached by others wanting to know how they've done it. The company provides examples of their 'practice', it gets assimilated by the inquirer and disseminated to others. This becomes "Best Practice".

But let's review this. When somebody (usually your competitor) comes calling looking for "Best Practice", do you actually give them what they need? Do you provide them with your trade secrets? (When you're at trade shows how open are you? I know companies I've worked for have had strict 'non-disclosure' practices when not amongst internal people). You end up providing them with some stuff that shows how things work basically but doesn't give away the farm (as they say). So how can this provide "Best Practice"?

It doesn't.

ERP manufacturers (and similar) tend to try and define a 'set way' of doing things which allows them to define their software along those lines: Check out any CRM product for example and you'll see that it mandates a particular way of operating (within boundaries). Major accounting or order processing systems are also similar.

So is this really "Best Practice"?

I put it to you that "Best Practice" is actually a combination of sub-optimal process definitions married together with a predefined logic flow mandated by a program.

Consider this: Nobody actually has a "Best Practice". By definition it comes from the collected will of the participants. But even then there are usually many ways of doing something - so much so that it is actually 'common' practice. This will result in a best practice being an amalgamation of various ways of doing things. On top of that the way things are done will, oftentimes, be influenced by the software someone is using to do that thing. If this software mandates a particular methodology then this will influence "Best Practice"

Think of a situation where everyone was doing something one way - "Best Practice" - when it was discovered that this was the wrong way to do it.

• How about trying to motivate people by paying them more. It was considered the way to motivate people until it was discovered that money is a hygiene factor not a motivator (i.e. they prevent dissatisfaction only when present instead of increasing satisfaction)
• What about smoking? Look back at films, TV series, adverts and even literature of the last century. Everyone smoked. It was considered a "Best Practice" to be seen with a cigarette in your hand or hanging from your lips. This went on for years and years. Then someone discovered that it wasn't actually good for you and it stopped becoming a best practice.
• Did you know, for example, that up until the 1950's it was best practice when driving a car to not wear a seat belt. It was thought that the best chance of survival was through being thrown clear of an accident.

So I put my initial question to you again

What's "Best" in "Best Practice"?

---

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.

---

The Poll is up. Vote now.

I wanted to add a poll to complement the recent post on process project failure. That post (based on a question at Linked-In) defined a number of reasons that process projects are unsuccessful. I really wanted to understand what readers think is the single most important reason so I've added a quick poll at the top of the page to allow you to vote.

Come on over and register your thoughts. I'm excited to know what everyone thinks!

---

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 see why you should buy this book.

---

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

All information is Copyright (C) G Comerford

"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, process, processes, business process, tips

BPM vendors need to understand customer business goals and operations

A new survey from the Butler group makes for interesting (and disturbing) reading

Apparently there is a growing gap between BPM Vendor assumptions and customer expectations. As the article says

The industry analysts find many of the latest features -- which BPM vendors genuinely see as adding value to their product offerings -- are viewed by the end-user community as little more than lightweight "bells and whistles."

That's a bit of a damning indictment of the BPM vendors, but one that I think is more than justified. Another, more worrying theme, that has appeared from this research is that

BPM is often brought in to a business to solve a particular problem or provide facilities in a part of the business operation where there is currently a technology gap or integration shortfall. This approach leaves the value-to-business model for BPM being driven by the technology’s ability to allow business professionals – process owners and business analysts – to develop operational processes that accurately reflect their business requirements

So, basically, we're in the situation where IT is now the driver for BPM implementation and the business is being left behind, somewhat. In reality what we need is a situation where the business is driving the BPM need, IT is aligned with this and a vendor comes along that can match the two sets of requirements and still remain within everyone's expectation.

That's a high bar to reach. I wonder if anyone can?

Over half your processes are not working!

I recently linked to an article from Online Recruitment which detailed the findings of a survey held of IT directors.

This survey indicated that 52% of the directors interviewed admitted that more than half of their current strategic business processes could not be easily shared across the organisation. A further 27 per cent said that between 25 and 50 per cent of their critical business processes suffered in this way. In other words up to 75% of the respondants said that up to 75% of their processes had problems.

So I asked myself "Am I surprised?". The answer was "Yes. I'm surprised the number was so small!". I've mentioned before in posts how processes become 'manipulated' or altered in day-to-day processing through various reasons, the most common of which is lack of process ownership. This leads to barriers being created between processes, hand-off's being missed and data being corrupted or lost. Very few businesses have the required senior level sponsorship to make business process management live and breath on a day to day basis. This is the very reason, I believe, why so many companies now find themselves in this situation.

Or at least it's one of the reasons. The article goes on to mention how it believes that poor business rules and out-of-date systems are also contributing factors. I am always hesitant in blaming business process failures on poor systems as I believe that a process should be designed in such a way as to be tool independent (that way when you change your software you don't have to re-design all your processes, just the 'implementation' of those processes), however there is no escaping the fact that historically, business processes that are designed around a system are prone to become less efficient as the system gets older and older and the underlying business needs change.

So what should be done about this?

Well, the article states an opinion from Jim Close, Senior VP and Country Manager (UK) of Software AG -who ran the survey - which is that companies should be doing a business process MOT (this being a UK term referring to the Governments mandate that all road vehicles over 3 years old should be subject to a yearly inspection) , even going as far as to say:

...this is a major indicator of a company’s long-term viability, to the extent that it should be considered a significant indicator for investors. If a company can’t measure its business operations and adapt as the market changes, then will it survive? Investors should be asking their operational executives about the adaptability of their operations.

There is no doubt in my mind that any company which is not focusing on understanding, managing, and improving it's business processes is missing a huge opportunity to improve itself. I actually quite like the idea of a regular check. although I suspect this is something of a pipedream at the moment - businesses just won't see the benefit of this when compared with the cost and time needed to perform the review. However, as Jim Sinur says in his blog - "Process is free" so maybe there is hope for us yet.

So what should you do if you are in the situation that 52% of the IT directors above found themselves in? Panic? Hand in your resignation? Soldier on painfully through the problems, the complaints and the low-points?

Well, those are all possible alternatives. But my immediate suggestion to you would be to do a mini-MOT yourself:

1) Identify the pain points in your process: If you could only change two things about the process what would they be? Is your process too slow? Too many people involved? Too bureaucratic? Identifying these would immediately give you the option of proposing a solution that would reduce the pain

2) Identify the 'white-space'. It is a widely held belief that many process problems are related to hand-offs between groups, departments or other processes, the so-called "white space". If you can identify the top two or three problems resulting from hand-offs in the processes you identified above you are starting on the right track

3) Put together a plan to alleviate the issue identified in the previous two points. This will release pressure on your process in the short term, build up good will with your customers (internal and external) and enable you to focus then on a longer term strategy for improving your business processes.

52% of IT directors not having faith in their processes is a damning indictment of the way our businesses are evolving, but with a little application and some careful thought, this needn't be the end of the world for businesses and their customers.

The Customer - A victim of poor business process

I've seen this happen time and time again - and I'll give you further examples at a later date, but this article by Rajas Daithankar at 'Consulting for Success' is typical of the kind of things that happen when processes are not thought through

The Customer A victim of poor business process