Best Practice Is a Concept Sketch, Not the Blueprint
Why best practice requires translation and what gets lost when that work is skipped
Best practice in process management is well documented. SAP reference models, APQC’s Process Classification Framework, and industry benchmarks all describe how core processes are expected to operate. The body of guidance is extensive. What receives far less attention is the distance between these models and the conditions in which most organisations actually operate.
Moving from Level 2 to Level 3 process maturity requires standardisation, processes executed consistently against a defined standard. Best practice can provide that reference point.
This article focuses on what happens between defining the standard and achieving consistent execution. It examines why that translation is more difficult than it appears, and what best practice is actually useful for in the process.
The Promise and the Reality
Best practice describes how a process should operate under a set of simplified assumptions: clean data models, a single ERP instance, an organisational structure aligned with the process flow, clearly defined roles, and incentives that reinforce the intended outcomes.
Few large organisations operate under all of these conditions at the same time.
The ERP system was implemented fifteen years ago and has since been customised in ways that were sensible at the time but now act as structural constraints. The chart of accounts reflects a previous organisational model and has not been fully rationalised. Approval workflows were designed for a business model that has since evolved. Multiple acquisitions have introduced legacy systems with different data structures, integrated through middleware that is only partially documented and unevenly understood across the organisation.
In this environment, best practice is not a template to follow. It is a description of a destination that is difficult to reach directly given the accumulated constraints.
This is not a failure. It is the normal condition of large, mature, multi-entity organisations, those that have grown through acquisition, operate across geographies, and carry layers of historical system and process decisions.
The relevant question is not whether the organisation deviates from best practice. It does, and it will. The question is whether those deviations are understood, intentional, and actively managed.
Answering that requires clarity on what best practice actually is, and what it is not.
What Best Practice Actually Is
Understanding best practice starts with a structural property shared by the major frameworks: the broader their applicability, the higher their level of abstraction and the more translation is required before they can be operationalised.
APQC’s Process Classification Framework applies across industries and organisational types because it defines processes at a level that strips away context. SAP’s reference processes specify transaction flows within a standard SAP environment, but the reference model and a heavily customised fifteen-year-old implementation rarely align. Industry benchmarks describe what leading performers achieve, yet the practices that produced those outcomes in one context do not necessarily transfer to another.
APQC makes this scope explicit in its own documentation: the framework does not claim to list every process present in a given organisation, nor that every process it lists exists in every organisation. That is a structural admission, not a caveat, the framework is declaring the boundary of what it can specify before any translation work begins.
In this sense, best practice is typically principled rather than prescriptive. This is particularly true for cross-industry frameworks such as APQC’s PCF, which is explicitly classificatory. Vendor-specific content, such as preconfigured SAP S/4HANA processes, is more prescriptive, but still assumes data models and organisational structures that many implementations do not reflect. In both cases, the framework defines what good looks like end-to-end flow, ownership, measurement, continuous improvement, but does not fully specify how to achieve it within a given organisation. That specification is the work that remains after best practice has been identified.
This is visible in the framework’s own architecture. APQC structures the PCF across five levels: Category, Process Group, Process, Activity, and Task moving from broad classification down to granular steps. The label gets more specific at each level, but the substance does not always follow. At Task level, where the language sounds most operational, “Maintain chart of accounts,” for instance the definition still resolves into an instruction to alter the structure “according to business requirements,” handing the configuration decision straight back to the organisation. Specificity of label is not specificity of guidance.
Consider a common situation in Procure-to-Pay. APQC’s PCF defines the process at a level that applies across industries: requisitioning, sourcing, contracting, ordering, receiving, and payment. SAP’s reference process outlines how these activities should flow in a standard SAP environment. Neither addresses how to design an approval workflow for a business unit with a mandatory four-eyes requirement above a locally defined threshold, a legacy ERP that cannot be upgraded before the next fiscal year, and a procurement function that reports into operations rather than finance. That is the real design problem. Best practice is the starting point, not the answer.
The generality of best practice frameworks is a feature, not a limitation. A framework that prescribed specific solutions would be too narrow to apply broadly. The implication is clear: translating best practice into an operational design requires substantial effort, and that effort is consistently underestimated.
Where the Gap Opens
The gap between best practice and operational reality opens at four points. The pattern is consistent across organisations and process families.
The first is data structure. Best practice assumes a data model in which transactions can be tagged, categorised, and linked to provide end-to-end visibility. In most organisations, however, the data model reflects historical decisions made for other purposes. Cost centres were designed for financial reporting, not for process performance. Supplier master data is fragmented across entities. Customer hierarchies do not reflect how commercial relationships actually operate. Creating process-level visibility therefore requires either restructuring the data model, which is costly and disruptive, or building analytical layers on top, which introduces ongoing complexity.
The second is the system landscape. Best practice assumes a coherent system environment. Most large organisations operate across multiple ERP instances, supported by specialist systems for treasury, HR, and tax. These are connected through integrations built incrementally over time and now difficult to change. Each integration point introduces potential deviation. Each system has its own data model, processing logic, and release cycle. The process does not flow cleanly end-to-end because the systems through which it flows were never designed as an integrated whole.
The third is organisational structure. Best practice assumes that process ownership is structurally feasible that an organisation can assign an owner with end-to-end visibility and the authority to act. In practice, functional structures, reporting lines, and incentive systems are rarely designed for cross-functional accountability. Best practice assumes governance conditions that many organisations have not yet established. This helps explain why process governance often stabilises at Level 3 rather than progressing to Level 4.
The fourth is business model specificity. Best practice is designed for a generic enterprise. Most organisations are not generic. A manufacturing company with engineer-to-order production, a professional services firm billing on time and materials, and a financial institution operating under regulatory constraints all face requirements that standard frameworks do not fully address. The adaptation required is not superficial. It affects the design of the process itself.
A fifth dimension, sometimes treated separately, is organisational culture and informal practice. Unwritten conventions, behavioural norms, and local interpretations shape how processes are executed regardless of what is documented. Culture is harder to map than the other dimensions, but it is equally decisive in determining whether standardisation efforts hold.
The typical response to these gaps is gap analysis. That response needs to be applied with care.
The Gap-Analysis Trap
Gap analysis is the standard method for linking as-is reality to best practice: compare the current process to the standard, identify the gaps, and build a program to address them.
The method is sound. The way it is applied often is not.
The most common issue is treating all gaps as problems to be eliminated. A more useful distinction is between deficiencies and adaptations. The terminology is not fully standardised, but the pattern is well recognised in ERP implementation research. Some gaps are deficiencies, deviations that reduce process effectiveness without a clear business rationale. Others are adaptations, deliberate responses to specific business conditions that best practice does not account for.
A customised approval workflow may diverge from best practice, yet exist because the standard workflow creates a bottleneck the business cannot absorb. A non-standard data structure may complicate reporting, yet reflect a business model that standard templates cannot represent.
Closing these gaps without understanding their origin produces processes that appear closer to best practice but perform worse in practice. The workarounds return because the constraints that created them remain.
Effective gap analysis depends on two disciplines that are often underapplied.
The first is gap classification. Before deciding on action, each gap should be explicitly classified as a deficiency or an adaptation. Deficiencies should be resolved. Adaptations should be understood, documented, and managed as intentional design choices.
The second is root cause analysis before solution design. Most gaps are symptoms of causes that are not visible at the point where they appear. A deviation at the approval step may stem from insufficient data quality upstream. The issue originates earlier in the process in how data is captured or validated. Designing a solution at the point of deviation without addressing upstream causes does not remove the gap, it relocates it.
Figure 1: Gap Analysis Classification Matrix
Gap classification determines the appropriate response to each deviation. Deficiencies should be resolved. Adaptations should be understood and actively managed. Gaps that have not yet been classified should be investigated before any action is taken.
What Best Practice Is Actually Good For
If best practice cannot be applied directly, and gap analysis must be handled with care, what role does it actually play in advancing process maturity?
First, it provides a shared language. Best practice frameworks offer a vocabulary for discussing process design that is not tied to a specific organisation’s history or system landscape. When a process owner and an ERP architect use APQC categories as a reference, they operate within a common frame that makes discussions more precise. Without that shared language, design conversations default to internal terminology, terms that often vary in meaning across functions.
Second, it acts as a diagnostic benchmark. The value of best practice lies less in the gaps it identifies than in the questions those gaps raise. Why does the organisation deviate at this step? Is the reason rooted in business requirements, system constraints, or simply in historical habit? The third explanation appears more often than expected, and best practice helps make it visible.
Third, it serves as a sequencing guide. Best practice clarifies the logical dependencies within a process: what needs to happen before what, and why. This sequencing logic is often the most transferable element, even when specific activities require adaptation. Understanding why goods receipt precedes invoice matching in Procure-to-Pay is more durable than knowing how to configure a three-way match in a particular system.
These three uses are what survives once best practice has been translated rather than applied directly.
Figure 2: What Best Practice Is Actually Good For
What This Means Before Your Next Best Practice Adoption
Before adopting a best practice framework or commissioning a gap analysis against one, three questions can help determine whether the program is likely to produce actionable results.
Is the best practice defined at the level of granularity where guidance is actually needed? Principles-level best practice, such as end-to-end flow, ownership models, and measurement approaches, is broadly applicable. Configuration-level best practice, such as workflow design and data structure choices, is context-dependent. Many gap analyses combine the two without distinguishing between them.
Does the gap analysis classify gaps as deficiencies or adaptations, or does it treat all gaps as issues to be addressed? An analysis that lists deviations without classifying them describes difference, but does not support design decisions.
Is root cause analysis built into the program before solution design begins? Designing solutions to gaps without understanding why they exist leads to changes that are correct in principle but ineffective in practice.
Best practice can appear, from a distance, closer to a theoretical ideal than an operational guide. It is a well-researched description of what effective process design looks like when the constraints of a specific organisation are set aside.
Advancing from Level 2 to Level 3 requires bringing that description into contact with those constraints. This means distinguishing between deficiencies to resolve and adaptations to manage, establishing root causes before designing solutions, and building a standard the organisation can actually operate, not one it only references.
Organisations that do this work gain something no framework can substitute for: a standardised process grounded in operational reality, rather than a description of what that reality is supposed to become.
#BPM #ProcessManagement #BusinessTransformation #ProcessImprovement #OperationalExcellence #ERP #BestPractice #KaldLabs