One of the biggest questions organizations face before implementing new technology is when and how business process mapping fits into the project. Do you let the software determine how your processes work? Or do you map your processes first and use them to drive how the software is configured? The answer depends on what type of process you are mapping, how much detail is needed, and where you are in the project lifecycle. This post breaks down the practical approach to business process mapping across the three major phases of a transformation.
Phase 1: Evaluate Before You Select
In the evaluation phase, the goal is to define what your future-state business processes should look like before you begin evaluating technology platforms. The clearer your vision for how the organization should operate, the better your ability to identify the right solution.
This does not mean you need to document every process in exhaustive detail. In our experience, the organizations that get the most value from this phase are those that define their business processes at a conceptual level, enough to establish clear evaluation criteria, without getting bogged down in transactional specifics that will change depending on which platform is selected.
The unfortunate reality is that many organizations skip this step because they lack the budget, time, or resources. But even a high-level process framework built during evaluation pays for itself by preventing poor technology decisions downstream. This is one of the most valuable activities you can complete during Phase 0 planning.
Phase 2: Design with Core Competencies and Commodity Processes
Once you have a high-level framework, the next step is to begin filling in the detail. To do this effectively, you need to categorize your processes into two types.
Core Competencies
These are the processes that make your organization unique. They are the reason you win against competition, what you do exceptionally well, and what you want to continue doing well. Core competencies are usually customer-facing, employee-experience-driven, or product-specific. These are the processes you invest the most time in mapping because the technology must support them, not the other way around.
Commodity Processes
These are essential functions like accounts payable, purchase order processing, and payroll. Every organization performs them, and they are largely the same across industries. For commodity processes, it typically makes sense to adopt the software’s standard functionality rather than investing in custom process design.
Understanding which processes fall into each category is critical because it determines how much mapping effort each one requires. When we advise clients on their business process optimization work, this categorization is always the first step.
In addition to categorizing, you should also document how data flows through each process and identify every employee who touches a given workflow. Understanding data flows helps you select the right technology. Identifying the people affected helps you plan for organizational change management from the start.
Phase 3: The Hierarchy of Business Process Detail
Not all processes need the same depth of mapping. A practical way to think about this is a five-level hierarchy:
- Level 1: High-level macro processes (e.g., the 15 to 20 major steps in order-to-cash). This is the starting point for all process mapping.
- Level 2: Sub-steps within each macro process, including key decision points and departmental handoffs.
- Level 3: Functional detail, including business rules, approval workflows, and exception handling.
- Level 4: Technology-specific configuration, including which fields are populated, which screens are used, and how the system handles each step.
- Level 5: Transactional detail, down to button clicks, data validation rules, and system-level automation.
Levels 4 and 5 are technology-specific. You cannot define them until you know which platform you are implementing. These levels belong in the design phase, after software selection.
For commodity processes, levels 1 and 2 are usually sufficient during evaluation. The software can handle the rest. For core competencies, you should go deeper into levels 2 and 3 during evaluation so that vendors can demonstrate how their platform supports your most important workflows.
This hierarchy also determines where the technology matters. Somewhere around level 3, the specific platform you are using starts to influence how the process is executed. Below that line, you need to know your technology before you can complete the mapping. Above it, your process work should be entirely technology-agnostic.
From Process Mapping to Change Management
Business process mapping is not just a technical exercise. It is also the foundation for managing organizational change. As you map future-state processes, you are simultaneously defining how individual jobs will evolve, which roles will change, and what the day-to-day impact of the transformation will be on each team.
This information feeds directly into your change impact analysis, training design, and communication planning. Organizations that treat process mapping as separate from change management miss the connection between how work will change and how people need to be supported through that change.
In our experience, the organizations that get process mapping right are those that involve frontline employees in the workshops, not just managers and IT. The people doing the work know where the real inefficiencies are, and their involvement builds the buy-in that makes adoption smoother. Understanding your processes end-to-end also helps you make better decisions about where to invest in technology enablement versus where process redesign alone will solve the problem.
Questions We Hear Most
What Is the Difference Between Business Process Mapping and Business Process Analysis?
Business process mapping is the act of documenting and visualizing how a process works. It produces the diagrams, flowcharts, and models that represent each step, decision point, and handoff. Business process analysis (BPA) is broader. It includes mapping but also encompasses data analysis, root cause investigation, and the identification of improvement opportunities.
Think of mapping as one technique within the larger discipline of analysis. You can map a process without analyzing it, but you cannot effectively analyze a process without first mapping it.
How Detailed Should Process Maps Be Before Selecting Software?
For most organizations, levels 1 through 3 of the hierarchy are sufficient before software selection. The goal is to have enough detail to evaluate whether a platform can support your core competencies and to identify where customization may be needed.
Going deeper than level 3 before you know which technology you are implementing is usually a waste of effort because the transactional details will change depending on the platform. When we advise clients on this, we recommend focusing depth on the processes that matter most (core competencies) and keeping commodity processes at a high level. This ensures that your ERP selection process is grounded in real requirements without overinvesting in detail that will need to be reworked.
Should You Map As-Is Processes or Jump Straight to To-Be?
Both, but in the right proportion. As-is mapping helps you understand where breakdowns, inefficiencies, and workarounds exist today. To-be mapping defines what the future state should look like. The gap between the two represents the change that must be managed.
The mistake is spending too much time on as-is documentation. You do not need to map every current-state process in detail. Focus your as-is work on the areas where the most significant changes are expected, and keep the rest at a high level. In our experience, organizations that spend months on exhaustive as-is mapping often lose momentum before they ever get to the more valuable to-be design work.
If you are preparing for a digital transformation and want guidance on how to approach your process mapping, contact us at eric.kimberling@thirdstage-consulting.com.
Eric is recognized globally as a leading voice in digital transformation and ERP strategy. Over the past two decades, he has helped hundreds of organizations – including Nucor Steel, Fisher & Paykel Healthcare, Kodak, Coors, Boeing, and Duke Energy – define their technology roadmaps, modernize complex operations, and deliver real business value from large-scale transformation initiatives.
As Founder and CEO of Third Stage Consulting, Eric leads an independent, technology-agnostic advisory firm focused on helping clients navigate the shift from traditional ERP to more flexible, AI-enabled Digital Enterprise Operations (DEO) models. His work spans ERP selection, implementation quality assurance, organizational change, and operating model design across a wide range of industries and geographies.
Eric is also a prolific thought leader, known for his pragmatic takes on AI, cloud, and enterprise software trends, as well as his firm’s benchmark research and frameworks for de-risking transformation. He is dedicated to helping executive teams cut through vendor hype, make confident investment decisions, and successfully reach the “third stage” of their digital evolution.
