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.


Digg!

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.



Digg!

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?

Digg!




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

Process improvement in the National Health Service

Those of you who have seen Michael Moore's film "Sicko" will, no doubt, have a rather rose-tinted view of the UK's National Health Service (NHS)

Yes. It's true, when you have a baby the government pays you to have it in a hospital. And yes it's true that you can walk in off the street without any form of health insurance and be admitted. And yes it's true that no matter what medication they put you on your prescription cost is limited to about £8 ($16).

But there is a downside to that, and I noticed it at a recent trip to 'The Blood Bank'

Following Mr Sean Bean in his UK adverts I decided to "Do something amazing. Give Blood" (Actually, full disclosure here: I decided to accompany a friend who was doing something amazing. I was the designated driver). It gave me an excellent opportunity to check out some of the process issue the NHS have (For more thoughts - of a non-process nature - around the NHS check out The Musing Cafe)

For those of you who have never given blood before here is the proposed workflow

  • Arrive and show documentation
  • Complete a separate questionnaire and take a processing number
  • Have form reviewed and answer ancillary questions
  • Give blood
  • Have Tea and Biscuits
  • Leave.

So far so good, right?

Well, lets' go through the reality of that process and see if we can identify a few failings - either in the process itself or tin the implementation of the process.

As a scene setter let me say that the blood donation centre was a hall in a local community building with a single entrance and exit. The room was nominally divided into a waiting area, a processing area, an area with 10 beds to get the blood and a place for your tea and biscuits. (For those of you outside the US, Google "Hancock" + "Blood donor" for classic comedy about this very situation)

Arrive and show documentation. Ideally this should be a quick and easy step. You show the documentation, there is a review of the content to identify if you are in the right place at the right time. If so, proceed. If not, exception process. However the people dealing with this were on the same side of the desk as the people coming in through the door, thus creating a bottleneck. In addition the administrators were also the same ones updating the computers (As a separate step...) and retrieving the completed questionnaire forms. Result: Slow processing and queues

Complete a separate questionnaire and take a processing number: To be fair the completion of the questionnaire was well handled. They had enough pens and everyone got a clipboard with some advice about the questions. Filling it in was easy enough (Tick either 'yes' or 'no' in the boxes) but then you had to go back to the same queue as before to hand the forms in. The same guy was now dealing with new arrivals and completed forms whilst standing on the same side of the table as everyone else causing a blockage at the door. Once dealt with, you received a processing number which was added to you form. The form was then dropped into a processing pile.

Have form reviewed and answer ancillary questions: There were three 'booths' in the corner where the forms were processed. In each booth was a uniformed nurse who came out, took a document from the pile, called the number and took you in for 'processing'. This consisted of checking blood type with a pin-prick sample and asking any clarifying questions about answers on the form (My friend, for example had answered 'No' to the question 'Have you taken any medication in the last 7 days', forgetting totally about the fact that she's asthmatic and is on an inhaler. This part of the process worked really well, with the exception that the forms (while apparently being taken from the form in a numerical sequence) were actually taken somewhat randomly causing my friend to miss her turn. Obviously a process flaw in the organisation of the filing system,

Give Blood: This, in theory, should have been the easiest part. Lie down, get a needle stuck in your arm. Wait for 10 minutes. In fact it did work almost that slickly. We had a venepuncturist called Leslie who was very adept and very experienced. There was minimal fuss and everything went smoothly. However, once the blood had been collected there was a call for 'Bag Check' where a third party had to come from some other part of the room and check that everything was alright with the plasma. Again this should work quite well, but with 10 beds in use and only 1 or 2 qualified checkers, it didn't quite go as slickly as required.

Have Tea and Biscuits: The far corner of the room was set out with a small table and some chairs where an old lady served steaming hot tea from a boiler and you helped yourself to biscuits. Very civilised. However once you had finished you had to pick your way back through the beds, the waiting area and the processing desk to get out. Good process, bad execution.

Lessons learned: Overall the process was reasonably slick. There were one or two small gaps (such as the filing system for forms waiting to be processed), but the main issue was with the layout of the room. Having reviewed the layout while waiting (I was in there 1 hour and 15 minutes) I believe that a few simple changes would have sped things up.

  • Have the form processes seated behind the desk to allow more folks into the room at once
  • Have two people dealing with forms - one for initial review and another for completed questionnaires
  • Either invite fewer people to give blood at a time OR add an extra person to the processing (75 minutes for a 10 minute blood giving session as too much)
  • Create a processing channel around the room that kept the people and the documents flowing in a single direction - Reception -> processing -> blood giving -> tea and biscuits -> Exit

I would be interested in thoughts and feedback from other folks who've been through this process. If they use those special mobile blood gathering units is the process any better?

What's the difference between ERP and BPM?

Jim Sinur has a great post over at his Blog about the difference between BPM and ERP.

This is something which is a vey important topic to understand. Many folks think that just because they've implemented a snazzy new ERP system that has built in 'best practice' processes, they actually have a BPM system in place. This is way off the reality!

Jim talks about what the differences are, as well as the pro's and con's of each facet of this issue.

Do yourself a favour and take 10 minutes to read through it

Some great posts from the Enterprise Decision Management Blog


I ran across the links below at the EDMBLOG where they had posted a link to 10 of the most popular stories and entries they made during 2007.

Some of these are really good and I recommend you check out the EDMBLOG whenever you can. If you don't have it on your RSS feed, you should!

  1. Business Intelligence 2.0 and Enterprise Decision Management
  2. Why are business rules better than traditional code?
  3. Windows Workflow Foundation - rule engines and rule management
  4. The secret of business user rule maintenance
  5. Customer Segmentation to increase profits
  6. Business Rules, Business Decisions, Intelligent Processes, Enterprise Decision Management
  7. Book Review: Competing on Analytics (the only book review to make the top 10, though Execution. The Discipline of Getting Things Done came close)
  8. What's the difference between Business Rules Management Systems and Business Rules Engines?
  9. Different Perspectives
  10. Using decisioning to build the bank of the future


The Customer - A victim of poor business process


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

The Customer A victim of poor business process

Effective Business Process Solutions To Achieve Business Goals


An interesting article on "Effective Business Process Solutions To Achieve Business Goals"

Effective Business Process Solutions To Achieve Business Goals/

More to come soon....

ProVision

I am a big user of the ProVision Business Process software from Metastorm.

If you haven't already seen this software you should go to the Metastorm site and check it out.

In future posts I'll be looking at this tool in some detail, as well as looking at other tools in the market with reference to Gartner and Forrester groups.

What is Process Cafe?


Hello and welcome to Process Cafe.

If you work in the world of business processes, or you do any sort of business process analysis then Process Cafe is for you.

I'll be looking at some of the tools of the trade, the major players, answering some philosopical questions about processes and also giving real life examples of Business Processes, how they work (or more usually why they don't) and looking at some of the issues and errors related to that.

Ever wondered what the difference is between BPA and BPM? I'll be looking at this distinction in a future entry.

I'll be updating this site about every three or four days so hopefully you'll come back and check it out.