The only constant in BPM is change (but certainly not the 'M')

Mark McGregor has a great post over at his blog about how the meaning of 'BPM' has changed over the years. First it was Business Process Modeling then Business Process Management then.. Oh, wait I'm starting to confuse myself. It's probably best to head over to Mark's blog and read the article yourself.

What is does highlight to me though, in all seriousness, is that we are living in a world where the only constant is change. From the work that we are asked to do right through to the what the three letter acronyms actually stand for, nothing seems to stay still for long enough. I subscribe to various news feeds which highlight BPM and I am constantly amazed, for example, at the number of companies who are now in the market place offering BPM (or BPMS, or EA or BPA) applications. This is a burgeoning marketplace and as such, each new vendor will likely want to give his or her own spin on various things to keep that competitive edge. This is one of the reasons that things change so fast. As a business process practitioner I love working in an environment of change. The challenges are far better than when things are constant.

But is that good or bad....?

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.

Why your process project will fail

Here's the problem with most companies when they try to implement business process management.

Nobody owns the processes.

If nobody owns the processes then nobody owns the management of them, nobody has accountability for them, therefore nobody cares if they don't work correctly.

Now don't get me wrong: the project manager owns the project, the business sponsor sponsors the project, and the project team members do the work, but when the project has been implemented and the folks have moved onto the next big thing the company is left with a set of (hopefully) well defined processes which work well but which nobody has the job of looking after.

I'm not saying that nobody is concerned about the processes, however. For example there will be somebody in the customer service department who will be looking at his objectives for the year and seeing that he has to manage customer complaints within a set period of time, and therefore he will do whatever he can to get this done. This may involve circumventing 'difficult' parts of the process (such as reviews or approvals or paperwork) or even creating sub-processes that help him work more how he wants to work rather than how the process was designed. And because nobody at a more senior level has been given responsibility for that process, that's how it will continue to be handled until suddenly all the parts of the process have been altered from their original design and now the whole (gestalt) process doesn't work.

So what went wrong? Governance!

Historically in companies (especially large companies) different parts of the organisation evolved along their own lines into what they felt was the best way of doing things. Finance did things their way, Manufacturing did things their way, Sales and marketing did things their way. Everything was fine because each part of the process evolved to work alongside the other parts. But at the end of the day Manufacturing were responsible for Manufacturing processes, Marketing were responsible for Marketing processes and Finance were.. well, you get the idea.

With the advent of business process re-engineering, or BPM or just plain process modelling, the demarcation lines between the different functions became less and less obvious. As we start to look at product life cycles, the functional view of processes no longer worked. Suddenly a single 'business' process starts to cover multiple 'functional' areas. Manufacturing and Marketing needed to to start working together and be part of the same process.

Which is where the problems started. Or rather, this is where a lack of governance caused problems to start appearing. Who owns a business process that covers Product Development, Manufacturing, Marketing and Sales? Who is held ultimately accountable - in their performance objectives for the year - for ensuring that the different functional silos work together on the process?

If you are in this situation now and cannot answer that question then your process improvement project will fail. The unfortunate thing is that even if you can answer that question, your process improvement project may still fail because the wrong person may be in that role or the supporting governance process to enable her to do that may not exist.

Process governance is all about managing expectations and arbitrating between different factions. It needs someone with senior level responsibility (ideally at a global level in a multinational organisation) who has the authority to say to several different functional areas 'No, this is how you will do it'. It needs a set of governing processes which can manage requests for change in a business process, and it needs representatives from all the affected areas to be included. If you miss even one of these things you will find it very difficult to get appropriate governance implemented.

That's not to say that it has to be a big, complex process, or that it needs to add a large overhead to the running of the organisation. At it's very basic you get all the players involved to review a proposed change, define what impact it will have and either approve or reject it. Majority rules. The more complex implementations of this are run by committee's with representatives from each area who negotiate the changes with each other. It can be as simple or as complex as you wish

But at the end of the day you need to be able to ask and answer the following questions

1. Who is the process owner for this overall process within the business


2. How do I get this process changed?

If you can answer these two questions you are probably well on your way to having good process governance.

Is Process Free?

What does it cost to implement good processes and associated BPM?

Jim Sinur over at Global 360.com makes a good case for process being free. But one of the questions I have floated to him is the following: "If process is 'free' or indeed if it is a net profit centre, why aren't more companies jumping onto this?" It would seem to be to make good business sense to do this as it will

• Improve your business
• reduce your costs
• potentially do the above for zero net cost

What are your thoughts on this?

(The link to Global 360 has been changed to a mirror posting at BPM Enterprise.com as Jim's blog at Global 360 has been deleted)

Comerford's Three Laws of Metrics

I work a lot with organisations that look at process and follow the standard company line

"Once we have our process in place we need to ensure we measure it. Let's put some metrics around it"

"Excellent", I think "They've got their act together and know what they mean."

However, when it comes to the implementation of the metrics they don't seem to focus on the right things. I've had companies looking at submission processes (i.e. a process whereby something is submitted for review and approval) where they want to capture a metric for 'Number of things submitted'. I've had companies looking at processes to manage performance where they weren't looking at the actual performance, they were looking at the ability of someone to meet an arbitary performance deadline so they can say "I met this compliance metric"

Through all of this I have to ask myself why the company feels they wish to collect metrics. To distill it all down I use "Comerford's Three Laws of Metrics" to help focus thinking

1) Metrics for the sake of metrics are a waste of time: Essentially if you are gathering data about a process because someone said it's a good idea to gather this data then you are wasting your time. I don't care if you massage it, re-format it and stick it on an executives dashboard, if you're just doing it to show figures you might as well make the data up. It's more important in that case to gather some meaningful data about the process. So you managed to deal with 35 documents this month in your approval process. So what? What does this tell you about the process? It tells you that 35 documents went through it. How many of these were approved? How many rejected? What was the capacity of the process (in other words is 35 documents a lot for this process or a little)? These are the kinds of things you need to track

2) A metric which says 'I said I was going to do it and I did it' is also a waste of time: I worked with an organisation that had a performance management process which measured you on your ability to produce a certain document by a certain date. If you had your objectives completed and signed off by Feb 21st you got a little star, an 'Attaboy' and - more importantly - something that contributed towards your pay review at the end of the year. However at no point in this process was there a measure of the quality of the objectives, or even the effectiveness of the objectives. All they were concerned about from a process point of view was 'Did we complete what we said we were going to do when we said we were going to do it?'

3) If you are going to gather metrics, at least have a way of feeding them back into the process to effect change: This is, essentially, the key part of the three laws. If you are going to the trouble of actually gathering data, tracking it and reporting it, where is the part of your metrics gathering process that feeds that data back into the process and permits a change? Going back to our submission process: We have 35 documents going through, each document takes 2 days to process, 20% are rejected, 70% are approved and 10% are re-worked and resubmitted prior to a decision. This starts to become meaningful data, but if we also tracked data such as "%age of resource time spent working on processing" and "%age of processing time spent awaiting decision" we have some key data to help change the process. If we found that it is only 8% of a resource time to process a document , it means that either we have more capacity than we need for dealing with these documents, or we can, alternatively, increase the throughput of documents. However if 95% of the processing time of the document is waiting for approval then we need to feed this back to the process to understand why we have a bottleneck: Too few approval resources? Inappropriate allocation of time for approval? Technical issues in the approval process? All of these can work to feed back into the process and effect change

How many of these seem familiar to you?

Global outsourcing to grow 8% in 2008

The Gartner group have just released a survey indicating that they feel global outsourcing (including Business Process Outsourcing) will increase by 8% in 2008

A Business week article about this can be read here

A key point to be made is

• More companies are favouring smaller deals and splitting services between several providers and countries, the Gartner report found. This shift away from large high-value deals is partly responsible for the fact that publicly reported BPO and ITO contract values fell by 50 per cent in 2007

So in summary - More BPO work to be had. but potentially it will be in lots of smaller chunks.....