Business Process Mapping

I work with business owners everyday who are frustrated with their business software, inefficient processes, and bottlenecks. When we are engaged to implement Odoo, we first spend time in a workshop or focused group sessions to really understand the business needs and process workflow. Spending this time on the front end of the project is invaluable to our success.

Business Process Mapping is a non-technical exercise of identifying the steps to completion for everything a company does. In large organizations, there are teams of people whose job it is to investigate and document these processes all day long. For most of our customers however, the time required to do this is hard to find. Our customers range between a couple million dollars in revenue to about 75 million in revenue. This means that the owners, and key managers are still highly involved in the day to day transactions and often do not have the time to build perfect documentation.

Completing the Business Process Mapping is something that can save our clients significant amount of money and time, not to mention frustration. If our customers cannot provide it, we engage in the discovery to uncover and document the needs ourselves, a service we enjoy providing. 

Categories

I typically like to start this by identifying and categorizing the various requirements that we are going to implement with Odoo. By doing this first it helps to prioritize our efforts and identify potential roadblocks early in the implementation project.

The categories I use are as follows:

I have compiled in this Google Sheet some of the common tasks our customers have worked with us to map in Odoo. 

Click Here for Examples

Operating Processes

Operating Processes are activities that happen frequently and usually only require one person to complete. They directly impact the success of the company in delivering the product or service that they sell to a customer. There are exceptions to this but from a broad perspective we let the customer decide whether or not Odoo meets their requirements for each task and if so we will either decide to document the steps or not based on the complexity. 

Supporting Processes 

Support Processes are things that a company does to keep the wheels turning. They are generally not customer facing activities but if they were not completed, the company could not be successful. An example of a support task that we want to document would be Purchase Tax Accrual. This activity might not happen daily, and a new user to Odoo might be confused on whether or not they are doing it correctly. We publish these steps in each project's wiki so that all employees of that company can login and see that information whenever necessary.

Management Processes

Management Processes are more complex than tasks and usually involve a more comprehensive workflow to completion. Multiple tasks could be included in the Process. For process documentation we often use flow charts to help all stakeholders visualize the requirements before we work on the technical components. Sometimes the process requires modification to complete, or sometimes it's just a series of task steps.

Below is an example of a manufacturing process based on made to order inventory. This process requires multiple people to complete and the management needs visibility into each step to ensure accuracy and quality.

I think there is some room for debate on this but I look at major concepts like "Order to Cash" as a management process. There are multiple people and departments involved in taking an order, delivering it, invoicing it, and receiving cash. For this reason, these very large, multi step processes are typically labelled as Management Processes by me. 

Now We Have a List

If a customer can give us a spreadsheet of these activities, we can work with them to understand the correct category and prioritization of how to proceed with implementation. The next step once we have the list is to discuss with the client on their specific requirements for each activity. It's hard to for us to predict some of the curve-balls we have seen in what we think of as routine business activities but our customers are always capable of explaining the requirements. 

I like to usually just jump on a demo with the client and walk them through each one of the requirements that they have provided me. By doing this I can give them examples of how I expect it to work and they will give me feedback or objections.

For each process that you plan to outline, the following information should be documented at a minimum. 

• Responsibilities

• Steps to Complete

• Expected Outcome

• Risks

Summary

The biggest take away here is that regardless of how small or big your organization is you need to sit down before implementing new software and identify the key processes to document. Some things are simple, and routine so those will be quick. Some other processes have never been thoroughly documented or thought through and they will require more of your attention. If you have never documented a business process I suggest just grabbing a piece of paper and scribbling it down. You will find out very quickly that there are exceptions and holes to fill. By investing the effort on the front end you will be a happier manager after implementation!