Does the Customer have a place in the Process?

I have previously written about Finding the End-to-End Customer Perspective, in which I wrote about the scope of the defined Business Process having a big impact on the value proposition for the customer or stakeholder. Another aspect of end-to-end thinking is including the customer inside the Business Process.

Why do we need to include the Customer?

Think of a typical Business Process where a customer is making a request of your organisation, maybe they are filling in an application for credit.

The current (as-is) process is considered inefficient as customer contacts the Accounts department and an Accounting Clerk collects all of the relevant information from the customer and then faxes the customer a nearly completed form to finalise and return. It is decided that implementing a self-service web-site will improve efficiency and save the company several staff years in the Accounting department.

The new (to-be) process is implemented, at the start everything looks good, the customers are able to fill in the form on-line and easily print, sign and send the form in. The form is also easy for the Accounting department to process as the information is already available in the accounting system.

However, the Accounting department is busier than ever, the phone seems to be ringing more and staff morale is down. What happened?

The customer is not part of the process. A key part of this process, getting and completing the customer application form, has been pushed out and is no longer considered part of the process; however customers are taking longer to complete the information required, they often don’t understand what is require and they are ringing up for help to complete the form. Once submitted a high percentage of forms are rejected back to the customer because they are incorrectly completed, causing re-work and unhappy customers.

If the customer part of the process was measured, then it would show that the end-to-end process is now less efficient at achieving its customer driven goals than it was previously. The process design may be more efficient from the Accounting department’s perspective; however that is the wrong way to look at it – unhappy customers and staff is a guaranteed recipe for failure.

Another example of this concept is in Gary Comerford’s e-book, The Perfect Process Project; In Chapter 6 there is a great customer perspective story relating to a call centre. Call centres (ironically they are often called customer service centres) are always a good source for processes examples that do not include the customer!

Finally, Michael zur Muehlen has written a great article on the BPTrends site, Service Processes: The Customer at the Centre.

Can you think of one of your Business Processes that does not include the customer? What difference could you make if it did?

What should come first, AS-IS or TO-BE?

Most process modelling methods start with analysis of the existing processes, an as-is model.  One of the challenges with as-is modelling is deciding how much work to do.  Very detailed as-is models can be time consuming (costly) and may drain the organisations tolerance for Process Management activities very quickly.

As-is modelling can also be quite hit-and-miss as the analysts try to decipher what the current process actually looks like, this can often be because there is not a single as-is process, there are many.

The main purpose of an as-is model is to give a Process Project the information it needs to work out where improvements are needed and what is the starting point for change?

On the other hand, to-be modelling is a description of future desired processes. To-be modelling requires analysts to be creative in solving problems and designing processes to achieve business outcomes, often with not so perfect information about what the organisation wants to achieve.

I find it fascinating to sit in a room and watch a selection of staff have a to-be model presented to them, you can see the defences rise – and everyone thinks it is not going to work – for different reasons.

So it doesn’t sound like either will work? not true.

My approach is to start with high-level to-be modelling. This often involves developing a future state, Process Architecture – aligning the organisations strategic goals with it’s process management goals. Further detail can be added about key processes in the form of IGOE Process Scope models  (more on these in future posts).

When agreement has been reached on the future state, then we can go back and look at the as-is. This is limited to the processes that will transition into the new architecture and only to the level of detail required to find the areas of process improvement and develop the change plan to implement the new to-be models.

With this approach there are plenty of stops along the way to make sure that everyone is in agreement.

When you do Process Modelling, which type of analysis do you do first? How effective is it?