Process Modeling Tips and Tricks for Business Process Experts
Start Big
A process modeling initiative should start at a high level. Figure out how the business processes you plan on modeling fit into the overall context of the entire company. That first diagram should use simple shapes like chevrons for each process entity. A very suitable model — based on these simple chevrons — is the value-added chain diagram. It allows you to model the interaction of major business units like HR, finance, procurement, manufacturing, etc. Alternatively, you can model main process steps for a traditional lead to order process or a sophisticated composite process in a coarse grained flow. The value added chain diagram allows you to model any of these diagrams on a single page. The relative orientation of chevrons in the value added chain diagram will show how major steps relate: Sales occurs before sales operation, for example. Production planning triggers parts procurement. HR and Finance processes support most processes along the entire value chain and therefore run in parallel to the logistics processes. Please be careful not to over-engineer this initial high level process map. It does not need to show the exact structure of the enterprise. But a process owner should be able to find himself on the map and be reasonably happy with where he stands. Have a look at the example below to drive home these points.
Picture 1: Value added chain diagram for iTelO Know When to Stop
Underneath the major process pieces that you have mapped, begin to define the sub functions, or the processes that support those main functions. Aim for a medium level of granularity, you are not on a systems or field level. If the discussion begins focusing on the systems, the specifics of your ERP system or your business applications in general, then you have left the enterprise modeling domain. You are approaching a more technical level. It’s important to touch on this a little bit, but not too much at this point of time in the process modeling effort.Look for Pain Points
Avoid the temptation to map the value chain down through the hundreds or possibly thousands of processes at work. This will lead you to analysis paralysis and you may loose the vision of the true goal. The goal at this stage is not to achieve completeness, but rather to find the high impact areas where understanding the process, improving the process, and documenting the process will supply business value. Another way to think about this is to look for high pain areas. Customer shipments don’t add much value in general, but when they go wrong can cause huge pain. So identify these areas and then drill down to the deeper processes underneath.Stay in the Now
After you have defined the basic functions of each business unit, and found the pain points you want to address, it’s time to drill down into supporting processes. How much granularity should you aim for? The answer depends on what you are setting out to achieve. There are two extremes. You could either model processes exactly as they exist today or envision the processes as you would like them to work in the future. Mapping the processes that already exist is about the same as producing systems documentation or a training manual, which may be useful depending on the context. Modeling the future creates a blueprint, but doesn’t give you much of an idea about how to get from here to there. I recommend to model somewhere in the middle of as-is and to-be. This will help understand todays process and how it can map to the future state. Of course, this is then a working document and not a systems documentation.Avoid Becoming Outdated
Be forewarned: The process you document today is going to become outdated tomorrow. Processes are dynamic. The macro level won’t change as quickly as the micro, but IT is constantly fielding requests for small enhancements that fly below the radar. This is why you should avoid documenting every little sub-process. Set these expectations with your participants early on. It will allow you to focus on a goal with immediate benefit. Also keep the time scale in mind. If you were going to renovate a house next year, you wouldn’t buy your tools for the project today. The same applies for mapping: Avoid over-documenting a project today that you aren’t going to tackle right away.Lay a Foundation for Change
Process change is not always welcome. One way to navigate change is to bring multiple stakeholders in a project together in the same room to help you understand the processes at the core of their work. Invite them together in a timely fashion. Not too early, but with enough time for their points to be given real consideration; three-to-six months ahead of a large project should suffice. Solicit their ideas for improvements, and encourage them to be visionary. Process modeling can be a great tool for involving people and removing resistance. For more on change management, read my previous blog: Change Management Demystified.Use Modeling as a Hammer
Most all process models should fit on two printed pages. When a model exceeds the boundaries of two pages, it’s a sign that you need to start opening sub-processes. Modeling from a 'business lead' all the way to 'invoicing' is going to be too big to fit on two pages. Instead, break it down into smaller pieces. Look for the clear milestones; 'lead to order' or 'order to delivery', for example. It is far better to have a process that looks too small for its own model than to have too many processes crammed into a single model. Decouple the steps, look for logical break points where a process pauses and continues. Only rarely have I ever encountered a process that did not fit on two pages. A pulp and paper company that I worked with shipped its pulp via boat. If production was running late and the ship had already departed with a partial order, the company would send trucks out to chase the boat. This process did not fit into any schema I had seen before, and there were no logical break points. The model filled three or four pages in the end and that was ok since it brought everybody in the room on the same page, including external consultants. But most standard processes related to sales orders, manufacturing and shipping have reasonably well understood breakpoints that you should use. Keep the goal in focus. You don’t need to map the process that takes place after every break point. If it’s not part of the objective you may be able to leave that level of detail out.Be a "Pull it All Together" Person, Not a Know-it-All
Even if you don’t know much about a particular business process, you can become a respected team leader. How? Ask the right questions. In your role, knowing every little detail is less important than understanding the methodology of how processes are done. You can be a guide just by knowing a good way to get things done. Guide people in a sensible fashion and they will stick with you as long as you can guide them through the complexity of the process. Every organization has people with knowledge, but there is a big need for people who can put all that knowledge together and use it to achieve an outcome.Call to Action
Diagram a process flow without words. Often, requirements documents in IT are just text and words. Try using pictures instead. Don’t wait for the manager to buy you a tool. Use anything; a white board is ideal. After that, you’ll be better prepared to use a more sophisticated tool such as ARIS for SAP NetWeaver.
2 Comments