Process Cafe

Holiday Greetings from The Process Cafe

Wherever you are, and whatever your denomination, I would like to take the opportunity of thanking all my readers, subscribers, Twitter followers and Google+ circlers, and wishing you all the best for the New Year.

Thank you.
Gary

The System is not the Process. The Process is not the System

(In the style of Seth Godin)

It is well worth remembering that when you design a process it should be designed independently of the underlying system that will support it. That's what procedures are for.

Designing a process based on a specific piece of software means that when the software changes the process needs to change as well.

You don't want that.

All information is Copyright (C) G Comerford
See related info below

Levels of Detail.

I've spent a lot of the last month or so in process facilitation sessions with different departments of a specific company.

It's been a very interesting set of sessions. I've learned a lot of the particular business area (probably more than I really wanted to know), but I've also learned a lot about peoples attitude when it comes to the world of 'process'.

Let me see if this scenario rings true to any of my readers: (In the style of Adam Deane)

Me: So what I want to do is understand, at a high level, what are the main chunks of work you do from a process point of view
Attendee 1: Right, well, let's see. We produce the weekly TPM reports.
Me: OK. That's not a process, that's a deliverable. What's the process that produces that?
Attendee 1: I don't understand
Me: Producing the TPM reports is something that happens at the end of a particular process. What is that process.
Attendee 1 : It's the process to produce the TPM reports.
Me: Is that all you do?
Attendee 1: We send the TPM reports to management
Me: Prior to that?
Attendee: We run the programme to produce the TPM reports.
Me: Are those the only reports you run?
Attendee 2: Oh no. I run the quarterly QQZ report!
Me: So, what I'm hearing you say is that you have a process to 'Manage management reporting', and you both do that?
Attendee 1: Wait a minute. The TPM and the QQZ are different reports.
Me: And..?
Attendee 1: It's not the same process.
Attendee 2: Not the same process at all.
Me: Oh. So what's different?
Attendee 1: TPM reports are run off monthly.
Attendee 2: QQZ reports are run off quarterly.
Me: But other than that there are no differences?
Attendee 1: Oh yes, there are lots of differences. The TPM reports run off the transaction file and the QQZ reports run off the summary file.
Attendee 2: And I run the QQZ reports from menu 3, but the TPM reports are run from menu 1.
Me: But from a physical 'What is the process' point of view your process is basically 'Gather report data, produce reports, send to end user'?
Attendee 1: I send mine to different end users than she does.
Me: But you still send them to an end user?
Attendee 2: I send them to management
Me: But management do something with them?
Attendee 2: I don't know. I never asked..
Me: Right. So I think we defined a 'Manage management reporting' process at a high level. As we decompose that proccess we'll find differences specific to each report, but at a high level are we happy?
Attendee 1: Yes
Attendee 2: Yes
Me: So what else do you do?
Attendee 2: I update the system when somebody leaves
Me: Does that happen often?
Attendee 2: More often than you would imagine
Attendee 1: I update the system when somebody gets married. I change their marital status.
Me: Ok So I'm hearing that we have a 'Maintain employee data' process?
Attendee 2: But when they leave is different to when they get married. It's a different process.
Me: Is it?
Attendee 2: Oh yes. It uses completely different screens and different people approve it. It's completely different.
Me: So it's not a case of 'identify data to be modified. Modify data. Gain approval'?
Attendee 2: Er. Well.. yes. I suppose it is
Me: And is that what you do too?
Attendee 1: Yes. But using different scree--
Me: I understand the actual details are different, but is it fair to say you are performing the same basic process over a different set of data..?

(silence as this is digested)
Attendee 1: ...er.... Yes?

You can see where I'm going with this. People tend to get fixated at a very low level of detail when it comes to their processes. In fact, I would go as far as to say they're almost looking at procedures or work instructions in some cases.

The art of process mapping is to be able to roll that up to (or, indeed, drill down to it from) a high level. This gives the overall view of the business and helps to understand the touchpoints for other processes or functions. Sure, you can then start to drill down into the lower levels of detail and understand what and where things happen. At some point you'll decompose to the level where producing the TPM report is different to the QQZ report, or maintaining a marital status flag is different to maintaining an employment status flag. But at a higher level of detail this doesn't matter.

I think one of the reasons that a lot of process management projects tend to get bogged down is because they try to understand the 'whole level of detail' issue way too early. I sat today with one guy who had brought Visio diagrams to the meeting detailing everything he did. These diagrams had about 25 or 30 activities on each one. At the end of the sessions we had been able to simplify and condense those activities into about four boxes. For each workflow we were looking for: A trigger, A set of high level activities, any important deliverables, touchpoints to other processes and an end state. Nothing more.

At the end of the day that's all you really need.... .

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?

All information is Copyright (C) G Comerford
See related info below

Top Ten Tips for Business Process Projects

I recently read Jacob Ukelson's post: top 10 tips for integrating a start-up after an acquisition.

One thing that struck me about these top ten tips is that a lot of them apply equally validly to ensuring a BPM project is appropriately managed, and the resulting solution integrated into your enterprises.

Let's go through these and see:

Tip 1 - Make sure that someone is thinking about the day after. In M&A Jacob was referring to ensuring that the focus isn't just on the process of the integration but also on determining how things will run when the whole integration effort is finished. With BPM this is equally as important. Somebody who can ensure that the effort put in by the implementation teams is mirrored by the effort needed to ensure smooth running of new (or improved) processes on day one.

Tip 2, 3 & 4 - Communicate. Communicate. Communicate. As Jacob says, you can never communicate enough. This is equally as vital a comment when major change is happening to a department, a region, or an enterprise as a result of process implementation or modification. There will be fear, uncertainty and doubt on the part of the business. They will look at a lot of what is being done and consider that it is 'getting in the way' of allowing them to work. Appropriate communication will ensure they understand the importance of the BPM effort and their role in making it happen. This is also very important if there isn't a common language between implementation team and users.

Tip 5 - First do no harm This is an interesting tip because the definition of harm is very fluid depending on who you ask. If you are a dyed-in-the-wool long time employee who has worked in the same department for several years, has their own way of doing things and is comfortable with the work arounds, the short cuts and the omissions that can form part of your daily work, when someone comes in and want to replace these with a new, shiny process you will feel uncomfortable. You will see the possibility for control to get away from you and you will interpret this as 'harm'. But in the big scheme of things it is just old habits dying hard. But, likewise this applies to the BPM team who may come in with an attitude of "There is a big problem here so we need to ensure we do something to fix it". As a result they may ride rough shod over parts of the organisation before taking an opportunity to review what is the right way to do things rather than the quick way to do things. Do no harm!

Tip 6 - Get help. Thinking that process management is something that can be done in isolation, or can be done by someone with little knowledge of existing systems, departments and work, is likely to result in a failure. So ensure that the user base are involved in the process. Ensure that help is taken wherever it can be. After all, these people know their environment far better than you do. Make sure you use that knowledge whenever and wherever possible.

Tip 7 - Visit Early, Visit often. How many projects have you been in where the project team meet the implementation goal and then immediately transition off onto other projects leaving the newly implemented processes to work purely with the users? This is a recipe for disaster. Ensure you keep project team members in the loop. Keep up to date with how processes are running. Meet early and meet often!

Tip 8 - Remember that the company acquired is different than your own, with their own unique culture. Or - to put this into a BPM context - remember that the company having their processes implemented is not your own and that culture is the biggest thing you'll need to overcome to make your project successful.

Tips 9 & 10 - Make sure you remember why you did the transaction. Or - from a BPM point of view - remember why you have made process changes. It is easy to get lost in politics, budgets and the management of change in the user base. But being able to stand back and remember the situation as it was prior to the project starting is a great way of focusing people and helping them understand why you have made the changes you have.

Sure, not all the tips from Jacob's article translate neatly to a BPM context, but there are enough there to ensure that sooner or later a few of them will be relevant to the project you're currently working on.

How many of these do you recognise? Which ones are missing?

All information is Copyright (C) G Comerford
See related info below

The Two Axioms explained

I posted the following last week

I wanted to explain a little more about what I meant, having listened to and read the replies that came forward on this.

1) There are a large number of process issues that are common amongst most companies, regardless of market sector and line of business

By this I mean that using Pareto's rule (80/20) 80% of the process issues that turn up in a company are similar across most organisations. These include items such as Segregation of Duties not being managed appropriately; Authorisations taking to long or being inappropriately routed; Inappropriate reward systems leading to processes being bypassed; Silo behaviour and Inappropriate process ownership. Of course a business that is manufacturing widgets at a rate of 10,000 per hour using automated manufacturing processes is going to have a large number of process issues that lack any commonality with a service company operating a 1000 person call centre. But at a macro level I am willing to bet that there are a lot of process issues that are common amongst both these types of business.

2) Most people in the company know what their process issues are but don't address them

Back when I used to work with the internal audit group of a large American multinational I used to spend two weeks in a specific business function looking at their processes and talking to the people that design, manage and operate them. At the end of the two weeks I would present a report - along with the rest of the audit team - that would identify weaknesses or deficiencies we had identified. In 80% of the cases the reply from management would be some variation of "We already knew that". Of course my reply would be "Well if you already knew that why hasn't it been fixed?" There were always reasons : Time, money, resources, priorities etc. But it didn't remove the fact that this were generally known issues that could have been fixed. The reason many of these were not fixed was because the department didn't realise, or understand, the business impact of not fixing them. It's ironic that it usually takes a major catastrophe that loses the company money to identify why a relatively small change should have been made. (Think of the company that kept it's computer back-ups in an on-site cupboard and lost both the computer room and the storage cupboard in a major fire. Sourcing a back-up computer to run their business on was easy, finding a back-up of their customer and transaction database was less so.

There are, of course, other reasons why these processes were not followed. I am indebted to Stephen Baishya for providing a small list from his own experience

These are all valid reasons, but do point, fundamentally, to a cultural issue where the company is not set up to appropriately manage the issues that come with running effective processes.

So, given that you know what the problems usually are, and you have pretty common problems that are not specific to your industry, why are you not addressing these issues already?

All information is Copyright (C) G Comerford
See related info below

The two axioms of process management

There are two axioms that I have found to be true in almost 100% of the places I have visited to work on their processes :

1) There are a large number of process issues that are common amongst most companies, regardless of market sector and line of business
2) Most people in the company know what their process issues are but don't address them

Discuss.

(P.S. A more detailed post about this will be forthcoming in the near future. I just wanted readers opinions at this time)

All information is Copyright (C) G Comerford
See related info below

Silo thinking - It's still bad!

The most popular post on this blog (by a long way) is one entitled "Silo thinking and why it is bad...". It was written back in January of 2010 and appears to consistently get the highest number of views of any post I have written. Obviously I'm looking at it thinking "Why is that?'

Sure, it's a well reasoned, thoroughly researched treatise on the nature of the silo mentality in organisations, along with accurate and incisive commentary on how to get around it. (At least in my own mind it is...) but there's obviously something more than that.

So what?

I think it's because it hit a nerve with a large number of the readers of this blog (over 4,500 last month - thank you!), and it is apparently something that everyone can identify with.

The first paragraph read:

I believe this to be as true now as the day it was written. The beauty is that it isn't just a process thing but a company wide thing.

The main thrust of that post relates to how a process is usually optimised to run as well as it can within a single department (or silo) and as such is not optimised to run as well across other departments or silos. I'm sure you've heard the tale of the manufacturing process which created some sort of metal engineering device. At the first department responsible for the manufacturing they put together the main three components of the device - the hub, the sprocket and the flange. They then boxed these up and sent them across to the next step where the electronics were added. The first thing this department did was remove the flange that had been added in the previous step. Then they fitted their electronic wiring & circuits and refitted the flange.

This sounds like an apocryphal tale, but it does illustrate quite graphically the ability of two departments working in the same company and producing the same product to - effectively - be working against each other. The first department had an optimised sub-process that meant it was efficient enough to be able to manufacture and construct the three main parts of the assembly, and - without reference to any further parts of the process - they were able to make themselves as efficient as possible. Across the whole of the process, though, this silo mentality was having an adverse effect.

I was reminded of this recently when working on a guest post for Squawkpoint.com which covered the topic of 'Who owns your processes'. In that post I mentioned that the process owner wants to be

It we take the example given above it means that we want to be able to make the first step of the manufacturing process slightly less efficient whilst, at the same time, making the overall process more efficient. Having someone owning the individual parts of the process (silo'd) does not allow that to happen.

The other point I mentioned in the original post was that reward plays a large part in this. It has been proven in survey after survey, and experiment after experiment, that people generally tend to focus on the things that will reward them the best. If I am a department boss and I tell my workers "Your annual review and associated compensation is based on your ability to process 1000 widgets per day come hell or high water" you can bet that my employees will be focused on finding ways to process 1000 widgets per day. If it means that they have a way of doing this which is optimal for their own department but sub-optimal for the rest of the widget manufacturing process then that's not their fault.

This is how silos occur.

The solution is - obviously - to reward and recognise people based not on their own individual performance, but on the company performance as a whole. The correct statement should be "Your annual review and compensation is based on the company as a whole being able to produce 1000 quality widgets per day come hell or high-water". The approach is still the same - the employees how to find a process which works in their best interests - but the end result is different - you finish up with a process optimised for the whole process rather than one which is optimised for individual departments.

It is my opinion that - despite the interest in the original post from nearly two years ago - there still appears to be a large amount of silo thinking happening in organisations.

Am I right?

.

All information is Copyright (C) G Comerford
See related info below

Business Process Management and Common Sense

This is a guest post by James Lawther:

In the beginning all businesses start out as small businesses. They start with one, two or at most a handful of employees with a vision to give customers something new and different, or just better. They then focus like crazy on those illusive customers, doing everything that they can to find and please them.

If the new, different or just better is truly new, different or just better; then slowly but surely the customers start to materialise, they like what they see and what they are getting and then they start to hand over their hard earned cash so they can have it.

And then the company grows.

If things go well the business won't be a small business any more. It will have a hundred employees and it will be time to become organised like a big business. Groups of accountants and IT professionals start to congregate, a sales force is born, a human resources manager is hired, functions develop.

Sensible business owners put dynamic pushy people in charge of these new functions and give them targets to hit, financial targets, cost targets, revenue targets, growth targets. Now success looks like hitting your targets and those dynamic pushy people start to optimise away like crazy. They start to focus on the internal mechanisms of their organisations and before you know it you have Sales people who are dragging in sales, Operations people who are slashing costs and Marketing people who are building new markets.

And they all do this with gleeful disregard to one another. After all no operations guy is going to be rewarded if the accountants hit their target.

As all this happens the customer who everybody started off obsessing about becomes of secondary importance, and their sales orders, complaints and queries start to fall between the cracks of the SLA’s, targets and departmental objectives.

Then things start to stagnate, accusations are thrown and the functions become more and more retrenched, each striving harder than before to hit their targets. And so it goes on.

Maybe I have painted a very black picture, maybe a truthful one; either way the solution is not very difficult. It is remarkably simple. Get your business to re-focus on the customer and optimise around them not their functions.

And that is all business process management asks you to do. There is nothing very clever about it, it is just common sense.

Are you using yours?

Author Bio

James Lawther is a middle aged middle manager.

To reach this highly elevated position he has worked for numerous organisations, from supermarkets to tax collectors and has had several operational roles including running the night shift for a frozen pea packing factory and doing operational research for a credit card company.

As you can see from his CV he has either a wealth of experience, or is incapable of holding down a job. If the latter is true his post isn’t worth a minute of your attention.

Unfortunately, the only way to find out is to read it and decide for yourself.

Visit his web site “The Squawk Point” to find out more about service improvement.

www.squawkpoint.com

All information is Copyright (C) G Comerford See related info below

Why improving the process is not always in the company's interest.

For those of you in the UK (and no doubt in other places) who have ever had the opportunity of travelling with British railway operators, you will notice a few things about these august enterprises which may startle you.

1) They are notoriously unreliable in their timings. Trains are late more often than should be expected
2) There are delays for many, many unknown reasons. Leaves on the line and 'The wrong type of snow' are two examples
3) The ticketing system is completely nonsensical and misleading.

With relation to the last point I would like to say a few words.

Back in the old days getting from one place to another on the train was a case of telling the ticket officer where you wanted to go and when. This resulted in a ticket being issued and a price being paid. It was more or less a standard fare between two points.

As 'customer service' started to be brought in to the rail ticketing arena, rail companies chose to offer multiple fares based on complex criteria such as 'peak' and 'off-peak', 'advance purchase' and similar criteria. This resulted in a set of fares which were both complex and misleading.

Coupled with that the ticket inspectors were given additional powers to fine and charge passengers who were not in possession of a 'valid' ticket. This resulted in miscreants being given a criminal record as a result of not understanding the criteria for application of a ticket.

So let's examine this: The process of a rail company calls for multiple, confusing fares which the customer has to decipher and understand. The penalty for buying and using an incorrect fare is a spot fine or the requirement to purchase a higher priced ticket to continue ones journey.

Can you see how improving this process would help the customer but not the company? They would end up with passengers buying the right fares, penalty fares being reduced and higher-priced ticket repurchases being eliminated. The end result would be a reduction in rail-fare income and associated profit. Of course the rail companies are not going to go for this.

Of course the rail companies will say that there are always people who try to game the system by buying a lower fare and using it on the wrong train, or at the wrong time. Of course these sorts of people need to be fined and charged as appropriate. But a large number of victims of this type are actually innocent people who have mistakenly used a valid ticket at an invalid time.

Steve Cable at CXPartners has written a great little post identifying and solving one key aspect of the problem - misleading ticket information. He contends that clearer ticketing would reduce the number of mistakes made by rail travellers. He states that

And he's correct. His post - which is well worth the five minute it takes to read it - identifies a number of instances where key information that would make the passenger's journey easier and less stressful is, in fact, either hidden or missing on the ticket, whereas other information that is not necessary for the passenger's journey is displayed prominently.

But the post misses the point that in reality the rail companies would not want to do this becasue this would effectively decrease the amount of money they earn through penalty fares or purchase of additional higher paid tickets to avoid the penalty fares.

Can you think of an example in businesses you work in where changing the process to make things easier would not be in your best interests?
.

All information is Copyright (C) G Comerford
See related info below

Process vs Common Sense

A good friend of mine, Michael, has just started a blog about his life experiences. He's an actor in musical theatre and is currently on tour with a show around the UK so he's spending a lot of time on the move.

His blog from today '"London" Luton Airport', highlights an interesting process issue.

What Michael is saying, basically, is that the airport owners have decided that they will charge people £1 to drop off (and park for ten minutes) in the area just outside the terminal building at "London" Luton Airport. (For those of you who don't understand the "London" part, Luton is situated quite a few miles North of London and is really misnamed as being a London airport. In reality the same could be applied to many 'out-of-town' airports which are a journey in themselves from the city they allegedly serve).

The problem with this new system is that it is encouraging people to use as much of the ten minutes as they feel they have paid for and, hence, causing tailbacks and queues at rush hours. In effect Michael had to be dropped off several hundred yards from the terminal in order to catch his flight. This behaviour is now being noticed and the airport is threatening to issue £80 fines for those dropping off outside the allocated £1 zone.

So in other words:

The airport has started charging for something that used to be free
The charging is affecting people's behaviour causing congestion
The congestion is affecting people's behaviour causing unexpected actions
The airport is trying to capitalise on this by charging fines for people reacting in a way caused by their initial change.

Does this sound familiar?

It's a typical badly thought through process change and one where common sense has been ignored.

Don't get me wrong, the charging is not, in itself, a bad change to the process. But the consequences have obviously not been thought through. This change has been put in, I would suggest, by management who are anxious to increase revenues but with very little thought to the customer impact this would have.

Again, "Sound Familiar?"

So what should they do?

How about having variable charge rates and times? In rush hour - when they traffic is heavy - reduce the cost but also reduce the time that someone can wait. Charge 50p but make it 2 minutes. This will increase the throughput of vehicles thus reducing the congestion.

Or maybe the airport is counting on the £80 fines to boost income and that's the reason for the change?

You may think that, I couldn't possibly comment....

All information is Copyright (C) G Comerford
See related info below

A review of the 'As Is'

A year or two back I wrote an article entitled 'As-is vs To-Be'. It attempted to identified specific reasons why it is important to perform an 'As-is' review prior to starting any work on the 'To-be' status.

Unfortunately not many people are willing to do this. They quote reasons such as 'If we're not going to be using the 'As-is' state in future then there's no reason to waste time actually documenting it. It's a zero-gain effort.

But as I stated in the original post:

What I actually found interesting is that I posed a question at the end of the post which was 'Can anyone think of a reason why an 'as-is' process would not be documented?' Nobody posted any responses with reasons why the 'As is' would not be documented.

So let me pose a different question 'How many of you are currently involved in projects where you feel that documenting where you are is a waste of time?'
If so, why?

All information is Copyright (C) G Comerford
See related info below

5 Take Aways for business process work

I was reading through the past posts in this blog and came across this one from November 2008. It relates to a post from Amber Naslund on her Brass Tack Thinking blog.

The post discuss a number of 'take-aways' that came from a discussion with Ford's Social Media guru Scott Monty.

I would recommend a read of the discussion because it highlights five things which apply to social media but apply equally well to business process work. Since the original blog was posted there has been a much wider linkage between social media and BPM which makes the post even more relevant.

The five take aways are:

Strategy First.
The tools don’t matter a fig. They’ll change, ebb, flow, and go away. Yes, you probably need some sort of tool to help you manage your process definition and evolution, and yes, Visio may well be what you end up using (although you know my thoughts on "Visio - the Devil's tool"), but at the end of the day it is the strategy for your process initiatives that is more important than the tools you use.

Individual faces matter.
It's worth remembering with business process management (and with pretty much any sort of human facing change) that adoption of the change is a human process. Faces matter in this case. You need to put a face at the head of the effort.

Business Process requires commitment.
A good business process programme will touch many areas of the business. As such it will require good management buy-in. The benefit of getting the management buy-in is that you can then start to focus on commitment from other parts of the business. It is much easier to push things forward with the right commitment at the top.

Keep your feet on the ground.
It’s very easy to get swept up in the idea that everyone and every business ought to be using the latest and greatest shiny new tools. This is even more apparent when you come to something like business process management. This tends to work on a 'hype-cycle' basis where people tend to get caught up in the fever of what can happen and then expect it to deliver more than it will. The ability to keep one's feet on the ground and link your efforts to a reality rather than a dream are paramount to making things like this work effectively.

Measure based on your goals.
It all comes down to the simple question of "Why are we doing this and can we prove that it is adding value?". If you can't measure whether you are being successful in what you are doing, you can't measure whether this is something that needs to be continued. Nobody wants to be in a situation where you are actually removing value from a value chain, or adding overhead unnecessarily.

How often do you use these take aways when working in your own organisations?

More importantly how much more relevant are these take aways with the growth of Social BPM?

All information is Copyright (C) G Comerford See related info below

The Business Value of BPM

It's the one question the C-suite will always want to have an answer for: "What is the business value of BPM?"

But what are they really asking? The answer is simple. They want to know - at the very lowest level - "If I spend $xm implementing this thing you call BPM - what will it do to my bottom line? Or, more precisely, how will it increase my profits/ value/ shareholder return?"

It's an exceedingly simple question. But one which does not have an easy answer.

In the big scheme of things I believe that there are very few organisations in the world who would not benefit from having their processes reviewed - whether this is a simple as documenting what they do so that they know where the problems are, or as complex as redesigning the whole operation to be more customer-centric (or 'Outside-In'). History has indicated that any organisation which that has been operating for more than a very short time will have process inefficiencies. These will have built up over a period of time as a result of laziness, people taking short-cuts or even changes which were made legitimately to deal with changing market conditions. The business has worked these changes into its day-to-day operations and everything is running admirably.

But it's very similar to a car. My car is a very reliable, locally built hatchback. It always starts on time, never lets me down and carries me and my things from A to B with no hassle, no complaints and no troubles. It just works. But over the few years that I have had it the tyres have started to wear down, the brake pads are wearing down and - more importantly - the engine is not as finely tuned as it was. I don't notice this, though, because I drive it everyday and the tiny changse in performance etc. are negligible on that basis.

But, being the good car owner that I am, I take the care in to be serviced. The service centre will take all the replaceable bits and replace them. It will put new tyres on them, check the pressures, clean the air filter and - most importantly - tune up the engine. When I get it back it will look like the old car I had (it may even be cleaner as they tend to give it a valet as well), it will feel like the old car I had but it will be completely different. It will run more efficiently, it will brake quicker, it will do more miles to the gallon.

The big question, though, is what is this worth to me as a driver? Will the reduced fuel consumption pay for the cost of the service? Probably not. Is the whole experience worth it? Absolutely! The car becomes a better machine. It does less harm to the environment. It is a safer vehicle all round.

But could I justify this to someone who had to pay for it? Of course I could - but probably not in monetary terms. The return on investment is probably not going to be good. However the other tangibles - and the intangibles - are going to be.

It's oftentimes the same with BPM projects. The benefit they give to your organisation in terms of improving efficiency and the ability to do the job better are more intangible than tangible.

Of course you can always fudge the figures. I worked for an organisation that justified the huge cost of a project by extrapolating the additional income that would be raised 20 years in the future by getting a product to market 2 years earlier in the patent cycle - blatantly unjustifiable numbers - and yet the project was approved on that basis. But I would encourage you not to fall into that trap. Look at your organisation and determine what you feel the benefit of the project is going to be rather than what you feel the monetary improvement of the project is going to be. With any well scoped BPM project your ROI is going to be 15% according to Gartner, so take this as a starting point and then add in all the intengibles that relate to it.

It makes sense.

.

All information is Copyright (C) G Comerford See related info below

The distraction of BPM

(In the style of Seth Godin)

For many project people the tools and associated detritus around BPM are what makes the project interesting: Get a good tool, implement it, either with your SI or internally, roll it out and watch the users flock to this brand new way of doing thngs.

Except that's not what happens.

Your user base couldn't care less about a new tool, or some new way of doing things. All they want is to be able to finish their work in the quickest, easiest way possible and go home.

Anything you put in the way of that will meet resistance

(And everything you do is in the way of that!)

All information is Copyright (C) G Comerford
See related info below

ABPMP Members - Is litigation the way to go? (A bit of a rant)

I don't usually use this forum to put together a rant - normally I leave that to my personal blog. However something came to my attention recently that, I think, warranted this.

Sandy Kemsley - respected BPM professional, blogger and thought leader in the BPM arena - is part of an initiative to put together an open-source body of knowledge for process. This is something that has been mooted for a while and the PKI initiative who are running this have started a wiki to form the basis of the document.

At that point the ABPMP (The Association of Business Process Management Professionals) has weighed in threatening legal action against the PKI for copyright infringement against their document 'The BPM BOK'. This is despite the fact that the PKI has not used BPM POK in their documentation and have, instead, created a document called PKBoK.

So far so good. Now comes the interesting part. Sandy blogged about the PKBoK, the ABPMP's legal action and her thoughts on this last week and one of the comments to that entry came from Tony Benedict the President of ABPMP International. It starts with "I’ll try to address your misdirected rant one by one." and ends with "Your blog seems like a desperate attempt for attention in a BPM market where you have no reputation as a practitioner, only a “criticizer".

Strong words.

And also, quite inaccurate and unnecessary.

Sandy - to her credit - has replied with factual statements without resorting to ad-hominem attacks.

But I find the whole thing disturbing.

It doesn't matter whether you agree with the PKI's efforts to put together such a document (and The Process Ninja is critical of their efforts so far). It doesn't matter whether you think that this is something that should be done (or indeed can be done). It doesn't matter whether there is a legal issue with the proposed PKI document (and as far as I can tell the legal complaint that has been raised does not appear to have foundation in fact - although I am not a lawyer). What matters is that the President of an international industry body feels it appropriate to comment on a public forum with a personal attack on an individual.

I have been in the Business Process world now for about ten years and I am fully aware of who Sandy Kemsley is. She and I have had conversations over social media and through blogs and I know of the work she does and the effort she puts into her work. In those ten years of BPM work I have never heard of Tony Benedict. I have never seen or read anything written by him (other than the ad-hominem attack on Sandy), and I certainly haven't heard anything about his reputation - good or otherwise - within the BPM field. In fact a quick search on the internet reveals that the only link I can find to him outside the ABPMP is the Amazon link to the book he is co-author of called (surprise, surprise) "Business Process Management Common Body Of Knowledge".

Maybe that's a failing of mine. Maybe I am not reading the right blogs, going to the right conferences or attending the right webcasts. But when somebody I don't know places himself above another person by referring to that person (a member of my blogging BPM Black List) as having no reputation as a practitioner, only a criticiser, I have to wonder.

I have to wonder why this individual feels the need to make a personal attack. I have to wonder what insecurities he is trying to hide and I have to wonder whether he is fulfilling his obligations as the president of an industry body by making attacks such as these. If I were a member of the ABPMP I would cancel that membership immediately.

Let me be absolutely clear here about a few facts as well. I have no problem with anyone trying to protect their intellectual property. If I had co-authored a book and somebody else ripped that off I would attempt legal actions to stop that too. But the PKI is not ripping off that book. As far as I know they are not plagiarising anything from the ABPMP, nor are they even producing anything with the same name. They are merely taking the underlying idea (which is not copyrightable) and interpreting it a different way. As Scott Francis says on the BP3 blog "PKI have their sights set on an open collaboration around a body of knowledge for BPM that is transparent and freely available, to advance a common understanding of the state of the art." and "I think ABPMP is in the unenviable position of trying to fight the future.". I agree. But fighting it by trying to belittle the people who are involved in it is not the right way to do it.

Comments on Sandy's blog also indicate that Mr Benedict is doing more harm than good to the ABPMP.

Hopefully he will read these comments and understand the meaning of them.

UPDATE: I have deliberately removed commenting from this post because I think that anyone who wishes to comment should visit Sandy's blog and comment there instead. I note that several of my respected BPM bloggers have already done so. Please add your $0.02 worth
.

All information is Copyright (C) G Comerford See related info below

The No. 1 Success Factor for BPM Projects

In the style of Seth Godin

I recently asked The $64m question about BPM and the answers I received were many and diverse.

So it got me thinking "What is the number one success factor you need to have for BPM projects".

Is it training?
Is it C-Suite buy-in?
Is it an understanding of the benefits?
Is it dealing with the hottest burning issue?

The answer is "Yes". It's all of those.

And none of those.

What is most important to your organisation is the factor that will get BPM implemented quicker and easier.

It might be getting C-suite buy-in. It might be getting people trained. It might be making sure everyone understands the benefits of BPM. It might be finding a burning issue that you need to solve.

One thing's for sure: There is always a key success factor in each project.

The next time you're starting a BPM project, consider that the reason the last one failed might be because you had the wrong factor identified. Your challenge is to identify what the right one is and make sure everyone is aligned.

All information is Copyright (C) G Comerford
See related info below

The State of BPM Part 3

This is the third and final of three articles discussing the state of BPM today. In the first article we discussed the current state of the BPM capability and covered items such as training, project failure and the definition (or lack thereof) of BPM. In the second article we looked at the state of the technology surrounding BPM. In particular we looked at the vendor segment and try to understand the impact of the consolidation occurring there.

The third and final part of this series will attempt to summarise the last two posts and also try and foresee where we are with the whole capability and what the future will be. Sure, it's a bit of crystal-ball gazing, but I think something like this is useful to try and work out where the whole market is going and what they key areas to focus on are.

If you want an official view on this then our friends at Gartner will be all to eager to give you their version of BPM based on extensive market research and discussions with both vendors and customers. My view is slightly different. I'm looking at this through a lens of social media. And by that I mean I'm reading the posts, tweets and similar updates that have occurred to try and make sense of where BPM is as a topic, what the hot buttons are within it, and where these are going to lead.

Primarily I will be talking about three things.

The evolution of BPM as a concept.
The introduction of Social Media to BPM.
The future for BPM technology.

The Evolution of BPM as a concept.
In part one of this series I talked about the fact that there is little common understanding of the definition of BPM. I mentioned the fact that this fuzzy definition is being further clouded by the introduction of alternate aspects of BPM such as ACM, Agile BPM, Adaptive BPM, etc (and some people are trying to differentiate what is what). All of these are totally legitimate aspects of the craft. My personal opinion is that they will continue to evolve a little further and - in a couple of years time - the market will fragment to such a point that there will be a marked distinction in the different types of "BPM".

One of the key areas of discussion at the moment is that of workflow documentation matched against unstructured processes. In today's world (as, indeed throughout history) the work that people do has fallen into two camps: The work that is repetitive - and can be documented, improved and automated - versus the unstructured work - which in reality is where the bulk of the innovation and associated work occurs. For example a call centre process can be analysed, documented and - to a certain degree - automated (think Interactive Voice Response and call routing systems), but the solution of a customer problem is something that depends on a lot of items, not all of which can be appropriately defined. The unstructured part of a call centre is that part where the true value of the process is found, but it is also the part where the BPM aspect is least sufficient. I can see as we progress that more companies will start to look at the unstructured part with a closer eye and want tools and methodologies to help them appropriately manage this. Any company which can provide that toolset and methodology will have a head start in this market.

I have written in the past about Outside-in processing. There are the usual proponents of this style who swear by it and say they have the case studies to back this up, pointing to companies such as Southwest Airlines, Apple and Best Buy as prime examples. But they then turn round in the following breath and tell us that a lot of these companies don't call it 'outside-in' but refer to it under some other name. I have another name for it too: Common sense. In my view Outside-in is just merely sense under another guise. Companies who have used common sense when defining their process have determined that the customer needs to be at the heart of everything they do, and have redesigned their methods to enable that to happen. The lack of a defined methodology for Outside-in coupled with the lack of firm case-studies identifying customers who have moved from a non common-sense approach to one with common sense but without a compelling underlying product (iPhone or iPad, anyone?) does make me nervous about fully endorsing this.

The Introduction of Social media to BPM
Is this a passing fad? Will social media have a dramatic effect on BPM? I think yes - in certain cases. If we are talking about passing status updates of process steps - or even reviewing and managing unstructured processes - then 'yes'. If we are talking about using Twitter, Facebook and similar tools to help define processes then I see a key problem: As with a lot of the current vendors, once you lock into a particular toolset it will inhibit your ability to be as flexible as you wish. With Facebook's current predilection for changing security settings on an almost weekly basis I can see this being an issue within the BPM sphere. After all you wouldn't want key process data for your organisation suddenly being passed to third party organisations, would you? As one of Facebook's privacy officers said recently "If you don't want your private information used by Facebook, don't put private information on Facebook". Such a move - like having a BPM vendor change their current functionality - will impact your ability to appropriately manage your process through social media. If you have gone down a route whereby you are heavily invested in social media and BPM, this could have a severe detrimental impact on your business.

The Future for Technology
Technology is - and always has been for me - the least important part of BPM. It is a tool in the same way as a hammer is a tool. If you are not trying to hammer in a nail but are wanting to paint a wall instead, then a hammer isn't very much use. This is the same with BPM tools. The plethora of tools available is starting to bewilder the market. The inclusion of a number of bits of functionality from various aspects of BPM is starting to make Vendor offerings into BPM 'Swiss-Army' Suites. i.e they can do all sorts of everything. But it also means they can't always do them all very well. Take simulation, for example. This is a key function of BPM and process design and yet there isn't a single vendor on the market that has produced a good, fully functioned process simulation tool. By that I mean a tool that will load a process and determine, for example, the optimum staffing level for each step according to various user-defined parameters. Sure, there are simulation suites in many tools - my personal favourite is the Proforma/Metastorm tool which is both visually well designed and produces good output- but it is still an add-on to a larger suite and one which cannot answer the type of question I have just raised.

In the previous post I talked about the potential consolidation of the market as companies start to buy out competitors and produce larger and larger BPM vendors. In some ways this is good for the end customer because it means that a given vendor will have more integrated offerings including increased functionality that may have been lacking prior to the merger. But the flip side of this is that it will reduce competition in the marketplace and automatically inflate prices (After all this is more or less what happened with the petroleum market and - as far as I can see - my gallon of petrol costs about the same price regardless of where I buy it from. Surely this is a market that is ripe for competition?). It will stifle the ability of the end customer to guide the direction in which the tools can emerge and leave the vendors in complete control. Do you want your company processes controlled by some vendor CEO outside your company?

However, what this will do then is open the field up for more and more niche vendors to provide their wares targeted at specific markets. Smaller vendors will be more open to listening to their customers and will provide software to plug gaps in the market that the larger vendors do not want to fill. They will also offer increased competition and a good price point.

Summary
This short series of posts has been aimed at helping you understand the current state of BPM as a concept, a toolset and a future direction. A lot of the opinions here are my own and do not always reflect the current market reality. For that I make no apology. I believe that the BPM market is due for a good shake-up soon. We must get to the stage where we fully understand what me mean by BPM, what we want to do to support and it where we want to take it in future. If we - as customers and consultants - don't take this step then we will be at the mercy of the vendors who will not always produce a future state that we agree with.

Hopefully you have found something of interest in this series of posts to help you understand BPM and where I, in particular, stand with it.

All information is Copyright (C) G Comerford
See related info below

Why BPM Won't Work In Your Organization

In the style of Seth Godin

Because it's hard work. Because it involves change. Because you don't know what you don't know about the project.

Your BPM project will take longer, cost more and hurt more people than you imagine. Make sure you know this in advance and work through it.

The world is full of BPM projects that didn't achieve their potential.

Don't let yours be one of them.

All information is Copyright (C) G Comerford
See related info below

The State of BPM Part 2

This is the second in a set of three articles discussing the state of BPM today. In the first article we discussed the current state of the BPM capability and covered items such as training, project failure and the defintion (or lack thereof) of BPM.

In part three we will look at the future of BPM

But part 2 will discuss the state of the technology surrounding BPM. In particular we will look at the vendor segment and try to understand the impact of the consolidation that is occurring there.

For many people - especially IT people - the mention of the words Business Process Management is immediately equated to 'A business process management Tool'. This tool can be something as simple as a Visio diagram showing a workflow, right up to a complex BPMS package which integrates with Enterprise Architecture, process analysis and the automation of such tools.

As a result I feel the capability of process management has become inextricably linked with the underlying supporting tools to do that management. Unfortunately I feel this is something which is burdening the capability far too much.

In this week's discussion we are going to look at the state of the BPM tools market and try to decipher what issues or problems are occurring as a result.

If we cast our minds back not too many years the BPM tool market basically (at least according to Gartner) consisted of a number of the larger software providers such as Aris, Mega/Pega and Provision. Alongside these there were niche manufacturers who focused on particular segments of the market or particular functionality (Metastorm comes to mind as an automation provider that had very little - if no - process development capability)

Then in recent years there has been a consolidation in the market. Some of the larger vendors bought each other out. Other larger vendors purchased (or were purchased by) a niche vendor in order to create today's market, which basically consists of a smaller number of larger software vendors with fairly comprehensive offering covering many facets of process management. Metastorm, for example, purchased Provision which gave them the tools they needed to map processes and provide simulations appropriately (and Metastorm were, themselves purchased recently by another vendor. OpenText).

IBM got into the BPM market in a big way by buying one of the leaders in the sector, and Microsoft have made major moves into this area too.

But has this actually provided anything which is better for the end users? One complaint I hear constantly - both in person and in blogs/tweets etc - is that the tools are very much 'IT focused' or 'Business Process focused' and not 'user focused'. The ability of an end user to actually get in and use a lot of these tools in a meaningful way appears to be quite limited. I do not have detailed experience of all the tools on the market but I can tell you that for the tools I have experience of this is a valid comment. Recently Craig Reid, The Process Ninja, posted an article discussing the Nimbus tool which - in his opinion - appears to be more focused on the end user and less on process professionals. But I would suggest that this is more of an exception than the rule. A lot of tools are now starting to focus on using the BPMN standard for documenting processes and this is something which - in itself - is not completely intuitive and requires training to bring a user up to speed. The tools I have used have defined a minimum 5 day training session to bring everyone up to speed on them, and these factors lead me to believe that we do not have 'user focused' tools on the market

But do we need user focused tools? Should BPM be something which is managed and maintained by the end users or should it be looked after by a dedicated group of process management professionals? That is a subject of debate (and one which I, naturally, have my own opinions on), but suffice it to say the dichotomy between having users who know little about managing processes, using tools that help them manage processes in the way they wish to rather than how the process professional might wish to, is an interesting one and one which will keep process professionals in work for many years.

So where is the process tool market going in the next couple of years?

Of course nobody knows for sure. But if the current trend of consolidation in the market continues, it could safely be assumed that the market will come to be dominated by a small number of large vendors who provide integrated process management tools that can take a business from complete process novices right the way through to Level 5 process gurus.

Or it might go the other way. There is a case to say that integration of this sort is just constricting businesses. Do we really want all of our company running at the mercy of a single software vendor? This is - effectively - what happened with ERP systems back in the 1990's. Vendors such as Oracle, JDE (before they merged) and SAP provided single systems that whole organisations could align with, but can anyone say for sure whether this provided any sort of appropriate ROI? I, personally, worked with one organisation that spent the best part of $500m implementing an ERP system across the globe. Will they ever, realistically, make that return? I don't know. But I do know that when the main system went down at their HQ they were without a global system for almost 1 month - with the appropriate loss of business, reputation and earnings that this entailed.

Whichever way the tool market goes for BPM, one thing is for sure, There will always be people who will try to buck the tend and provide something else for the market. This is - after all - where the niche vendors come from. They have recognised that a unified, bloated, system which does everything, cannot make sense for every sort of business. It's for this reason that companies have now developed Visio add-ons which allow more integrated process mapping from their Visio tool. This removes the need for customers to purchase an extra process mapping tool and allows users who are trained on Visio - which is pretty much everyone in certain organisations - to transit over to process management quite easily.

Colleagues of mine in the BPM field are talking about other facets of the capability which are more 'niche' in themselves. Terms such as ACM and Social BPM are gaining traction in the community and I would expect tools that support these to become more widespread in the near future.

However, on the flip side many organizations remain "process ignorant" when it comes to BPM because many still don't necessarily understand exactly how things are getting done in their own business. Some cited issues such as a lack of interchange standards between process modeling and execution tools, which can render system interoperability difficult. One reason that this issue exists is that organizations are using modeling-only tools that lack an execution component. Organizations are finding the breadth of available BPM systems confusing in that each vendor interface will dictate how business processes are to be designed and applied. Could it be that a single unified interchange system will prevail in the future which will allow any modelling tool to interchange data with any execution tool? The salesman at some of the larger vendors will tell you that this already exists, but seeing the number of forum questions that appear from developers who are building these execution systems, it is apparent that all is not totally well from this point of view.

But are there positives to be taken away from this? Of course there are. The consolidation of the market is not being totally driven by the need of vendors to make more money although this is, indeed, one of the main factors. There does appear to be a push from customers to get vendors to provide a complete package that will minimise the issues mentioned earlier regarding interoperabilty. Vendors are identifying the weaknesses in their own products and purchasing niche products to fill those gaps (Metastorm buying Provision was a prime example of that). All of this is good for the overall market.

Newer capabilities - such as Social BPM, Adaptive process management, MDD etc. will force the vendors to once again review their offerings and provide something to support he end user needs. This will - in turn - create a number of niche vendors who will dominate their own segment of the market. Over time the larger vendors will probably seek to consolidate by purchasing these niche vendors and incorporating their functionality into existing offerings. In the long term this will, in my opinion, produce bloated, unfriendly, unstable software (I’m looking at you, Microsoft) and the market will fragment once again.

In the final section of this series we will look at the state of things to come in BPM and try to extrapolate where this will take us and what the problems are going to be with that.

Part three will be released next week.

All information is Copyright (C) G Comerford
See related info below

Process Cafe

Pages

CATEGORIES

Free Publications

Blog Archive

Holiday Greetings from The Process Cafe

The System is not the Process. The Process is not the System

Levels of Detail.

When people don't understand controls.

Top Ten Tips for Business Process Projects

The Two Axioms explained

The two axioms of process management

Silo thinking - It's still bad!

Business Process Management and Common Sense

Why improving the process is not always in the company's interest.

Process vs Common Sense

A review of the 'As Is'

5 Take Aways for business process work

The Business Value of BPM

The distraction of BPM

ABPMP Members - Is litigation the way to go? (A bit of a rant)

The No. 1 Success Factor for BPM Projects

The State of BPM Part 3

Why BPM Won't Work In Your Organization

The State of BPM Part 2

Subscribers

Subscribe Now:

Process Articles in the news

Process Books at Amazon