How to Use a Process Framework Before an ERP Rollout
For Operations leaders preparing for an ERP implementation · Based on APQC Process Framework Implementation Method
// TL;DR
Operations leaders about to implement an ERP should apply the APQC Process Framework Implementation Method to establish governance BEFORE technology. Document and standardise current processes, build a process library, and inventory IT applications first — this gives you leverage to configure the ERP to your architecture rather than inheriting the vendor's defaults. Skipping this step leads to costly customisations, complicated upgrades, and sometimes a second implementation. Use value stream mapping to expose waste before it gets hardwired into the new system, and apply the relevance filter so you only document what involves risk, affects day-to-day operations, or is mission-critical.
Why should I establish a process framework before selecting an ERP?
Because of the Governance Before Technology principle: if you adopt technology before establishing process frameworks and governance, the vendor imposes their own process architecture on your organisation. That leads to costly customisations, complicated upgrades, and — in the worst cases — a second implementation to fix the first. Establishing a framework first gives you the leverage to configure the ERP to your architecture, documented in your common language, aligned to your actual operations.
The framework — such as APQC's Process Classification Framework (PCF) — provides a ready-made library of process categories and definitions. Instead of inventing processes from scratch or accepting the vendor's defaults, you select what's relevant and build a process library the implementation can be configured around.
What should I do before ERP configuration begins?
Work through the early steps of the method deliberately:
1. Select the right framework using the three selection questions — does it have the level of detail you need, the additional information you need, and coverage of your functional and industry processes? Check for industry-specific PCF variants and assess alignment with software already in use.
2. Document and standardise current processes using the framework's common language, so every function describes work the same way.
3. Build a process library the ERP can map to.
4. Take inventory of current IT applications so you know what's being replaced or integrated.
5. Use value stream mapping to capture the end-to-end flow of information and materials and drive out waste — before that waste gets hardwired into the new system.
Apply the Relevance Over Completeness principle throughout. Do not attempt to map every process. Filter candidates through three criteria: does it involve risk, affect day-to-day operations, or include mission-critical tasks? For an ERP, that focus keeps configuration effort on the processes that actually matter.
How does this change my negotiation with the ERP vendor?
It flips the power dynamic. When you arrive with a documented, standardised process library, you're specifying how the system should support your operations rather than asking the vendor how you should work. The default architecture becomes a starting point you accept or reject on your terms — not a fait accompli. This is the single most effective way to avoid the customisation spiral that inflates ERP budgets and delays go-live.
How do I sustain the framework after go-live?
An ERP is exactly the kind of high-maturity tooling the method recommends for framework management — roughly 40% of the most mature organisations manage their framework in an ERP platform, versus about 18% at lowest maturity. So the implementation isn't the end; it's a step toward embedding the framework into your operating platform.
After go-live, execute the four-stage change management process — Plan, Design, Implement, Sustain — and communicate what's changing, when, and how staff will be supported. Track the top five benefits year-over-year: transparency, clarified communications, established buy-in, reduced operational silos, and reduced redundant processes. Remember that value compounds: 96% of organisations using the PCF for 10+ years strongly agree it improved their processes, so treat this as a sustained practice, not a one-time project tied to the ERP launch.
Next step
Before your ERP vendor kicks off configuration, run the framework selection questions and a current state assessment (a survey-plus-workshop combination works well) to baseline your processes. Build your process library and value stream maps first — then let the technology serve your architecture, not the other way around.
// FREQUENTLY ASKED QUESTIONS
Why not just let the ERP vendor configure our processes?
Because you inherit their default architecture, which rarely matches your operations. That causes costly customisations, complicated upgrades, and sometimes a second implementation. Establishing a process framework and governance first — the Governance Before Technology principle — lets you configure the ERP to your architecture, documented in your common language and aligned to your actual work.
Do I need to document every process before an ERP implementation?
No. Apply the Relevance Over Completeness principle and only document processes that involve risk, affect day-to-day operations, or are mission-critical. Use the framework's ready-made library to identify relevant categories fast, then build your process library and value stream maps for those before configuration begins.
Should I manage my process framework inside the ERP after go-live?
If you're a higher-maturity organisation, yes — roughly 40% of the most mature organisations manage their framework in an ERP platform. Post-launch, embed the framework, run the four-stage change management process, and track benefits year-over-year, since framework value compounds over time rather than appearing immediately.