Albert Einstein during a lecture in Vienna in 1921
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 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 '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?

Reblog this post [with Zemanta]

Lessons Learned - Why do we never learn the lessons?

Ute Kraus, Physics education group Kraus, Theo...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...?

The philosophy of BPM (Or 'The 3 questions you should ask yourself')

The philosopher PlatoImage via Wikipedia

In today's modern world of tools, frameworks, standards and vendors it is often easy to forget that at its heart BPM is actually more of a philosophy surrounded by a lot of ancilliary detritus - at least that's my attitude when it comes to deciding what's important from a BPM point of view

As Dennis Parker from K2 said in a recent interview I did with him: "BPM is a completely overloaded term" and there is no clear definition of the term itself.

One of the key way's of ensuring success when it comes to process is to make sure you focus on the correct parts of the puzzle. It's too easy to get distracted with deciding what is the best tool to use or which third party systems integrator will provide the best value for your organisation. Don't get me wrong: Once you have your fundamentals in place and know what you want to achieve and why it is vitally important to have the right resources on board working in the right direction. This could be the correct tools, associated vendors, or system integrators, but fundamentally BPM comes down answering the following philosophical questions:
  • What are you trying to achieve with your change?
  • Who is responsible for making this happen?
  • How are you going to manage the change in your organisation?
The last one is a key issue which is all too often left out of the equation. Change management is key to making most projects successful and BPM projects are no different. A survey I ran last year highlighted that point dramatically.

Knowing which tools to use is something that should come at the end of your BPM journey rather than at the beginning (which my experience tells me is quite often the way things actually happen). This could be a result of a couple of things. The first is that companies tend to approach BPM tool selection from two points of view. The first is the 'I need a tool for this job so I'll get procurement onto the task'. The second is 'I have an urgent need to solve a particular problem or problems so I'll get a tool to help me'. Fundamentally nothing is wrong with either of these approaches but in essence what you are saying is that you are more focused on the tool than the solution. A solution may be possible without having to resort to any sort of tool - at least not immediately.

This is why if you come to GCP Consulting I won't try to baffle you with lots of jargon or talk about all these different tools and solutions that I can help provide you (although there are several of those that we can discuss at the appropriate time). What I will do is have a detailed, focused discussion with you about what, exactly, it is you are wanting to achieve, who in your organisation is responsibly for making this happen, and how are you going to manage the inevitable change within your organisation. I firmly believe that if you don't have these fundamental concepts in place then there is nothing more worth discussing on your project. I also believe that if you have answered all these questions - or at least given them serious thought - then I can probably add value to your project with my knowledge and experience.

I would also suggest that if your are in discussion with system integrators, vendors or consultancies and they don't seem to be bothered about these questions then your project may end up being more 'interesting' than you originally planned.

So before you go off and waste/spend a lot of time looking at tools, frameworks, vendors, SI's, approaches, solutions et al just spend a few moments thinking philosophically about your project and trying to understand exactly what you are trying to achieve. Ask yourself the three questions listed above and see if any of the answers make you re-evaluate your current thinking.

Topics such as these listed above are covered in my eBook 'The Perfect Process Project" which is available here.

A big thank you to you all

Serve by John Safer 1989Image via Wikipedia

This is a big thank you to everyone who took advantage of my 'Free Consultancy' offer. As I said in my earlier post I was astonished at the response especially in these times of economic cut-backs.

This offer is now closed for the summer. I am anticipating running a similar promotion in August so if you would like to be involved in this please drop me a line and I'll add you to the waiting list.

Remember first come, first served.

BPM and Golf part 2

A golf ball directly before the holeImage via Wikipedia

I while back I wrote a piece that equated golf with BPM (more particularly how identifying a weakness in your golf game and attacking it can reap dividends to your final score) well today I want to give you another golf story. This one is a little closer to home.

Both my parents play golf. They started as they approached retirement age and are now very enthusiastic players (My mother is even on the committee at the local golf club). But here's the thing. Even though they are both of an equal level of experience - having started playing around the same time - my father tends to get more out of his golf game than my mother. By that I mean that he hits better shots, places the ball better and has a better mental attitude to the game. Don't get me wrong, my mother has a fundamentally sound game. She hits the ball well, is always accurate with her shots and tends to know her limitations when trying shots across, say, water or other hazards. But the one area she is admittedly very weak in is putting. In a typical round she will average 3 putts per hole. Over 18 holes this adds up to a lot of extra strokes. These extra strokes start to annoy my mother over time. So in order to solve this problem she will.... buy another club to give her more distance off the tee. Or buy a fairway wood that she can use to strike the ball cleanly off the short stuff. Despite my many attempts she cannot see the benefit of taking some time to be taught the fundamentals of putting so that she can practice and reduce the shots she plays in a round. If she could reduce her putts by an average of one per hole she will have instantly knocked 18 shots off her score - a feat that very, very few players have managed to do without a great deal of effort. But I believe my mother could do this easily with the right approach.

However mother doesn't subscribe to this point of view. She thinks that she can't putt any better than she does because "She's tried already", and that spending the money on lessons would be a waste - especially when there are shiny new clubs beckoning her with the promise of 'an extra 20 yards off the tee'.

So how does this relate to BPM? (You knew if you read on long enough it would get back to that didn't you?) Fundamentally I believe that what my mother is doing is exhibiting the same tendencies a number of companies are doing when it comes to process improvement. They believe that getting the tools in to do the job is a substitute for knowing and understanding the fundamentals of the discipline. Vendors (and research companies alike) have been so successful in positioning products and services that companies lose site of the fact that the best product in the world will not help you if you don't use it right - or even worse - if you don't know how to use it at all.

Anecdotally I have heard of any number of organisations who have gone encountered a problem, identified it as 'BPM' related and the instantly gone out and purchased a BPM(S) tool to help them. Want to bet that this solved their problem? I guess you know that it didn't. They have missed the fundamental point that a tool is just a tool. It can't do everything for you. In the same way that a box of tools will not build a house by itself, a BPM solution will not streamline your processes by itself. The more insidious issue here is when you've purchased a 'tool' to help you but it's not the right tool. This will effect your approach to problem solving. Remember 'when all you have is a hammer, every problem is a nail'

Don't misinterpret this article as being a rail against BPM vendors. It isn't. What I am trying to highlight is the growing problem of companies using BPM solutions as panaceas to solve problems they were not designed to. Or more importantly substituting solutions for knowledge and trying to 'do BPM' without building the BPM capability. Just like my mother with her putting, getting a shiny new golf club won't help her learn to putt anymore than buying a flashy new BPM system will teach you how to manage your processes better.

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 (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