If you’re at the front-end of an ERP selection process, you’ve probably heard conflicting approaches to ERP business process mapping.
Some consulting firms recommend an end-to-end, exhaustive ERP business process mapping exercise. They say it’s worth it. They say anything less can expose your business to risk: “what happens if you miss a key process that the software can’t support?”.
The consultants will spend weeks or months discovering each and every business process and then weeks or months more documenting them. It’ll cost you tens upon tens of thousands of dollars, sometimes hundreds.
Fast-forward to implementation. Once you’ve selected the system, you’ll quickly learn that you’ll have to fully 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 the project.
Having said that, 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 full remapping your business processes before selection.
Three downsides to fully 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 full business process mapping before selection?”
There are a few major downsides:
- You’ll have to remap your processes during implementation regardless of whether you’ve mapped them before selection. 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 catalogue 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). For ERP implementation purposes, learn more about business blueprinting here, business scenario listing here, and business process mapping here.
- Your consultant’s biases might inappropriately skew your ERP evaluations. If the consultants design your “to be” processes, you introduce a risk that they bias your decision towards or away from certain systems. 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 cataloguing those needs in a matrix. That way, you’ll be able to open your mind to options.
- Your internal core team should perform the detailed ERP business process mapping exercise, not the consultants. 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 best 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). 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 an effective way 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 your 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 providing 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 they have, the better positioned they’ll be to show you where their systems meet your needs, where they don’t and what workarounds are viable.
For more information about ERP business process mapping and ERP selection, download our 5 ERP Selection Best Practices whitepaper.