How to Do ERP, CRM, and HCM Business Process Management

One of the biggest debates in digital transformation is when and how to tackle business process management. Should the software determine how your processes work? Or should your business processes drive how the software is configured? The answer is not as simple as picking one side or the other. It depends on which processes you are talking about, how much detail you need, and where you are in the project lifecycle. This post breaks down a practical framework for prioritizing and managing business processes across ERP, CRM, and HCM initiatives.

When Does Business Process Management Happen?

In most transformation projects, there are three major phases:

1. Software Selection: evaluating different options and identifying the right technology platform
2. Design: defining business processes in detail, configuring workflows, and mapping out the future state
3. Implementation: executing the build, testing, training, and go-live

In a perfect world, organizations would invest significant time defining their future-state business processes during the software selection phase. The clearer your vision for what the transformation should achieve, the more effectively you can evaluate which technology platform supports that vision.

In our experience, the organizations that define their business processes before selecting software consistently make better technology decisions and avoid costly rework during design. However, the reality is that many organizations do not have the budget, time, or resources to complete detailed process mapping during selection. For those organizations, the bulk of the process work ends up happening during the design phase, which is still workable but carries more risk.

Core Competencies vs. Commodity Processes

Not all business processes deserve the same level of attention. A practical approach is to separate your processes into two categories.

Core Competencies

These are the differentiators that make your organization unique. They are the reason you win against competitors, the processes that represent your “secret sauce.” Core competencies are typically customer-facing or deeply tied to how you deliver value. Because they are unique to your organization, most off-the-shelf software will not handle them perfectly out of the box. These processes will likely require customization or at minimum, careful configuration to preserve what makes them effective.

Commodity Processes

These are essential functions that every organization must perform, but they are not competitive differentiators. Examples include general ledger accounting, accounts payable, purchase order processing, and standard HR transactions. Most enterprise software platforms handle these processes well with minimal customization. For commodity processes, it often makes sense to adopt the software’s standard approach rather than investing heavily in custom process design.

When we advise clients on how to allocate their process mapping effort, we recommend investing the most time and rigor in core competencies and accepting standard software functionality for commodity processes. This ensures that limited resources are focused where they will deliver the most business value.

Levels of Business Process Detail

Business processes exist at multiple levels of detail, and understanding this hierarchy is essential for deciding how deep to go at each stage of the project.

• Level 0-1 (Macro): The 15 to 20 major steps in an end-to-end process like order-to-cash or procure-to-pay. This is the high-level outline.
• Level 2-3 (Functional): The sub-steps within each macro step, including decision points, handoffs between departments, and key business rules.
• Level 4-5 (Transactional): The specific system actions, including which fields are populated, which buttons are clicked, what approvals are triggered, and what happens outside the system.

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. Levels 0 through 3, however, can and should be defined in a technology-agnostic way, ideally during or before the ERP selection and evaluation process.

For core competencies, we recommend going deeper into levels 2 and 3 during selection so that vendors can demonstrate how their platform would support your most important processes. For commodity processes, levels 0 and 1 are usually sufficient at the selection stage.

How to Facilitate Business Process Mapping

If the software is not driving the process definitions, how do you actually do the mapping work? The most effective approach we have seen uses facilitated workshops with cross-functional teams.

These workshops bring together the people who actually perform the work, not just managers or IT staff. The goal is to document how the process works today (as-is), identify pain points and inefficiencies, and define what the process should look like in the future (to-be). In our experience, the most productive sessions are those that focus on outcomes rather than system transactions. The question should be “What does this process need to accomplish?” rather than “What screens do we use today?”

A thorough business process analysis conducted through these workshops also surfaces the integration points between departments, which are often where the most critical breakdowns occur during implementation.

Business Process Management and Change Management

This exercise is not just about process design. It is also about preparing the organization for change.

As you define future-state business processes, you are simultaneously defining how individual jobs will evolve, which roles will change, and what impact the transformation will have on day-to-day work. This information is the foundation of your organizational change management strategy. The earlier you identify these change impacts, the more time you have to address them through communication, training, and leadership alignment.

This is another reason why moving as much process work as possible to the front end of the project is so valuable. It gives the change management team a head start on the people side of the transformation, rather than scrambling to react once the technology is already being built.

Should You Let the Software Define Your Processes?

This is one of the most common questions organizations ask, and the answer depends on the type of process.

For commodity processes, yes. Adopting the software’s standard functionality reduces customization, lowers implementation costs, and makes future upgrades easier. There is little competitive advantage in reinventing how you process accounts payable or run payroll.

For core competencies, no. Letting the software override what makes your organization unique is one of the most common mistakes in digital transformation strategy. In our experience, organizations that allow system integrators to push “best practice” configurations across the board often end up losing the very processes that differentiate them in the market.

The practical approach is to be deliberate about which processes you standardize and which you protect. This requires the upfront prioritization work described earlier.

What Is the Difference Between Business Process Management and Business Process Re-engineering?

Business process management (BPM) is the ongoing discipline of documenting, analyzing, and improving business processes. It applies before, during, and after a technology implementation.

Business process re-engineering (BPR) is a more radical approach that involves fundamentally rethinking and redesigning processes from scratch. BPR is typically reserved for situations where incremental improvement is not enough, such as when an organization is entering a new market, consolidating after an acquisition, or replacing a legacy system that enforced outdated workflows.

Most digital transformations involve a mix of both. Commodity processes may only need incremental BPM improvements, while core competencies may benefit from a more fundamental BPR exercise. Understanding which approach to apply where is key to getting the most value from your process work.

How Do You Measure the Success of Business Process Management?

Effective business process management should produce measurable results. Key indicators include:

• Reduction in cycle time for end-to-end processes (e.g., order-to-cash, procure-to-pay)
• Decrease in manual touchpoints and handoffs within a process
• Improvement in data accuracy and consistency across systems
• Higher user adoption rates during and after implementation
• Fewer workarounds and manual overrides in the live system

When we advise clients on this, we recommend establishing baseline metrics for your highest-priority processes before the transformation begins. Without a baseline, it is difficult to demonstrate the value the process work delivered. Organizations that build measurement into their approach from the start are better positioned to justify the investment and identify areas that need further refinement after go-live.

Common Mistakes in Business Process Management

Based on what we have seen across hundreds of transformations, the most frequent mistakes include:

• Skipping process work entirely and letting the system integrator define processes based on software defaults
• Going too deep too early, spending months on transactional-level mapping before knowing which software will be implemented
• Treating all processes equally instead of prioritizing core competencies over commodity functions
• Excluding end users from process workshops and relying solely on management or IT perspectives
• Ignoring the change management connection, treating process design as a purely technical exercise rather than a foundation for organizational change

Avoiding these pitfalls requires a structured approach to prioritization, clear ownership of the process work, and alignment between your process, technology, supply chain, and operations transformation teams.

If you are preparing for an ERP, CRM, or HCM transformation and want guidance on how to structure your business process management approach, contact us at eric.kimberling@thirdstage-consulting.com.