If you’re at the front-end of an ERP selection process, you’ve probably heard conflicting approaches to ERP business process mapping. Some consultants say it’s essential before implementation. Others say it isn’t.
For example, some consulting firms recommend an end-to-end, exhaustive ERP business process mapping exercise. They say it’s worth the time and expense involved. They say anything less will expose your business to risk. “What happens if you miss a key process that the software can’t support?” they ask.
These consultants will spend weeks or months discovering each business process and then weeks or months more documenting them. The process will cost you tens of thousands of dollars, sometimes hundreds of thousands.
Fast-forward to implementation. Once you’ve selected your ERP system, you’ll quickly learn that you’ll have to remap your processes because the system has a particular way of supporting business processing. In the end, you’ll have wasted precious time and a lot of money at the front-end of your project.
Having said this, there are still benefits to mapping certain processes in certain ways before selection. We’ll get to those below. But first, I break down three downsides to mapping your business processes before selection.
Three downsides to mapping your processes before ERP selection
Clients often ask us, “since we’ll eventually have to remap our processes during implementation, what are the downsides of doing business process mapping before selection?”
There are three major downsides:
- You’ll have to remap your processes all over again during implementation. Each system processes transactions differently. So, you’ll eventually have to remap your processes to conform to the selected system’s capabilities. During implementation, the purpose of ERP business process mapping is to precisely catalog how your business users will use the system to process their transactions. And, you’ll want to systematically drill-down from a cross-functional, summary-level business flow (Level-2) down to a business process (Level-3), and finally down to the application / work-instruction level (Level-4).
- Your consultant’s biases might skew your ERP evaluations. If consultants design your “to be” processes, you introduce a risk that they bias your decision towards or away from certain systems. For example, if your consultant has a lot of hands-on experience with SAP functionality, how do you think she’s going to map your processes? At such an early stage, you’d be remiss if you eliminated systems that offered reasonable alternatives. In areas where you intend to leverage system best-practices, you should consider cataloging those needs in a matrix. That way, you’ll be able to open your mind to options.
- Your key users might resist your implementation. Your core team, not consultants, should perform the detailed ERP business process mapping exercise. User adoption is a critical ERP implementation success factor. If you select and implement a system based on consultant-designed processes, you run a risk of key user resistance or even outright rejection. You want your users to own their future processes. Getting them to that stage requires that they take a lead role in business process design, documentation, and testing.
How process mapping for ERP selection differs from ERP implementation
Process mapping still plays several important roles in an ERP selection project, including:
- Documenting your non-negotiable requirements: Your business’s competitive advantage can be partly reduced to “secret sauce” business processes and technologies (the other parts include strategy and people). These are non-negotiable for your business and should be the price of admission for any vendor wanting to participate in your ERP selection project. To communicate these needs, you’ll want to carefully document the processes, data flows and technologies.
- Demonstrating your major opportunities for improvement: Oftentimes, an ERP business case needs to be justified by the benefits of automation, efficiency, error reduction and/or waste reduction. You may want to map and quantify key processes that are ripe for improvement. In these cases, you should map the “as is” processes, highlight the gaps, and match them against best-practices at a moderate level of detail (Level-3, for example). Remember: when crafting best-practices, keep them sufficiently generic so that you don’t rule out other acceptable options.
- Initiating change: Mapping changes to corporate structures, organizational structures and business processes are effective ways to introduce major changes that come along with ERP implementation. At the corporate level, you can start planning changes to the centralization and decentralization of functions and how ERP data models should respond. At the organizational level, you can start to plan changes to departments, roles and responsibilities. At this level, you should also plan your ERP project teams and any backfilling needs that may arise. At the process level, you can start planning changes to the business flows, along with the impacts on data, technology architecture and job duties.
- Educating prospective ERP vendors: One of your main ERP selection objectives is to evaluate how well candidate ERP software systems support your business needs. You should consider giving the vendors as much information as is practical so that they can tailor their demonstrations and RFP responses to your needs. We advise our clients to err on the side of being overly transparent. You should feel free to share your business process maps, key data elements, sample documents and project plans. The more information the vendors have, the better positioned they are to show you where their systems meet your needs, where they don’t and what workarounds are viable.