I am right now finishing up an engagement that consisted of mapping out business processes for a new call center organization. The client is a utility that is in the process of brining the billing and customer care functions back in-house after having used an outsourcer for a long time. Looking back at what we did and what worked or didn’t work a few things stand out that I will keep in mind for future similar engagements. All of these items are common sense but it is amazing how easy it is to forget them.
Define what a business process is
The term business process is used in a wide range of situations and it quite often means different things to different people. For some, it means detailed step by step descriptions for an end user of a system. For others it is a high-level description of how their organization operates. There is no right or wrong here but make sure you have a clear definition of what your group means by a business process
Keep the end use in mind
This ties directly in to the previous point of defining what a business process is. Defining business processes is usually not an end in itself. Having a big stack of business process documentation does not provide any value unless it is being used for something. When you start out, make sure you have clearly defined what the business processes will be used for. Is it training, testing, organizational design, IT system design or maybe policy review. Figure out who will use your business processes and invite them early in the discussion of defining what a business process is and how it will be documented.
Keep things simple
There are a lot of really great methodologies and standards for business processes. The problem with a lot of them is that they get very detailed and can be hard to understand and use for someone without the proper training. If your organization has a standard methodology and everyone is trained on this methodology, you should of course use it. However, if you do not, I recommend to keep tings VERY simple so that people can understand your process with minimal instructions.
In our project we used Visio for our swimlane diagrams and only used three types of symbols. We even took out decision boxes since they can easily be eliminated with a process step box and labeling the connectors.
Do not get stuck in semantics
The devil is always in the details and often you have to dig down deep. However, do not get stuck discussing details that in the end do not add much value. When the discussions go around in circles or you feel you are spending too much time working out little details, take a step back and re-evaluate if sorting out these details will add value for your particular situation. Will it bring value to the people that will use your business processes? If not, move on. Who cares if there is a small gap or inconsistency between business processes if this will not cause an issue.
Plan your workshops
You will with all certainty run a number of workshops where you will map out your business processes. As with all workshops, you need a good facilitator and you need to have a clear plan for how the workshops will be organized, e.g. who is doing what and playing what role. Before you start, spend a little bit of time planning how you want your workshops to function and get consensus among the team.
As mentioned above, non of these items are new but somehow we often forget about them and head down in the wrong direction. Hopefully, this list can help you save some time.
What is your experience with business processes? What have you’ve done or what would you do different?