You can't get where you're going without a map. In ERP that means Business Process Mapping (BPM), one of the most important, and difficult parts of the ERP process.
A process is a sequential series of steps that accomplishes a goal. A business process is a sequential series of steps, automated or not, that accomplishes a business goal.
Business process mapping is a way of setting out a process in terms of the steps needed to accomplish the business process.
In ERP, BPM consists of inventorying and analyzing the processes necessary to accomplish a goal, like shipping an order, and then seeing how ERP process integration can allow you to accomplish the process more efficiently.
ERP Is NOT About Technology
A common mistake in ERP implementation is to focus on the technology – the computers and software used in ERP. This is a mistake because the real heart of ERP is the business processes.
In the early days of systems analysis (of which BPM is a subset) the standing joke was that a company should analyze its processes, modify them to make them better, and then run the modified process without bothering to automate them. There was enough truth in the early days to make that joke funny and it still contains a grain of truth. Automation doesn't determine the success or failure of you ERP effort – at least it's not the overriding factor – Business Process Mapping does.
Inventory For BPM
The first step in BPM is to do a complete inventory of all the processes used to run the business. At this stage you want a fairly high level, 10,000 foot, look at your process. Think in terms like “Shipping an Order”, or better yet “Order Fulfillment.”
The list can be general, but it needs to be exhaustive. Everything the business does that will involve the ERP system must be included. This will add up to a lot of processes, which is fine.
The process of BPM needs to include all the stakeholders. That is all the departments involved and management. This is another one of the ERP implementation processes that cannot be done by IT and the vendor/consultant alone.
Breaking It Down
The next step is to break each of these processes down into sub-processes that are more manageable. For example, now is the place for “shipping an order” as a subtask. Again, there will be a lot of subtasks, and again, completeness is vital. You must cover every step in every process if BPM is to succeed.
Skipped or missed steps are one of the most common causes of problems in ERP implementation. This is why it's most effective to have a meeting with representatives of all the groups involved in each process when considering that process. For example shipping an order involves more than shipping. It involves accounting and possibly credit, inventory and sales as well. Having everyone sitting around a table kicking the steps back and forth is much more likely to get a complete list.
The next step is to write it down. That means every step in every process, including what the inputs are from other processes, who is responsible for seeing the process through, what the flow of work is within each step, what the output of each step is and what the output of the process is.
Be prepared for surprises. You – and the others – will undoubtedly find that some processes don't work the way you thought they did. You will probably find some steps are superfluous and it's very likely you'll turn up some steps that were missed. It's very important to identify these missing or extra steps. Also be sure to record people in terms of roles rather than the names of the people doing the job. “Shipping clerk” is more appropriate than “Andy”
Once you've got the process on paper, circulate it to all interested departments and get them to either modify it or sign off on it as is. This represents the starting point for BPM.
Of course this first iteration only represents the process as it is. Your goal is to re-engineer the process using the power of ERP to make it more efficient and to better meet the enterprise's needs.
That requires re-examining every step in every process looking for more efficient, more economical ways to do something. The players are generally the same, but this time the focus is on how to do the job better.
You're likely to find that a lot of sub-processes duplicate sub-processes in other processes. Can you tease those out and combine them? Are there any steps which are unnecessary? Make sure they are and eliminate them. Be on the lookout for fossilized processes – steps that were important once in a different environment but which aren't needed any more.
There are two extremely important parts of this re-engineering. The first is to make sure the process as redesigned is complete. The second is to make sure it will actually do the job.
Here again a committee of all the involved parties is important. Everyone needs to go over the redefined process to make sure it will actually do what it is supposed to do and that nothing is left out.
At this stage it is very helpful to draw pictures. Use a flow-chart type diagram or other visual representation to show all the steps in sequence. These visual aids are very helpful in finding exception conditions – things that can happen, usually rarely, but which aren't covered by the process.
Remember each process needs to be complete with all possible conditions accounted for.
Another important question is: Is the right person or department doing this job? Often you'll find steps in the process which are better handled by another department. If this is in fact the case (and not someone trying to shift work onto another department) try reworking the process chart and see how it flies.