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 processes, APQC’s Process Classification Framework, industry benchmarks: the literature on how core processes should work is extensive. What is less discussed is how far that literature sits from the conditions in which most organizations actually operate.
Advancing from Level 2 to Level 3 process maturity requires standardization: processes executed consistently against a defined standard. Best practice can provide a reference standard. This article is about what happens between identifying the standard and achieving the standardization: why the translation is harder than it looks, and what best practice is actually useful for along the way.
The Promise and the Reality
Best practice documents how a process should work under generalized and simplified assumptions. A clean data model. A single ERP instance. An organizational structure that mirrors the process flow. Roles defined in line with accountability. Incentives aligned with outcomes.
Few large organizations have all of these conditions in place simultaneously.
The ERP system was implemented fifteen years ago and has been customized in ways that were rational at the time and are now structural constraints. The chart of accounts reflects a previous organizational structure and has never been fully rationalized. The approval workflows were configured for a business model that has since changed. Three acquisitions have added three sets of legacy systems, each with its own data structures, each integrated through middleware that is rarely fully documented and often poorly understood across the organization.
Best practice, in this architecture, is not a template to follow. It is a description of a destination that the accumulated constraints make difficult to reach directly.
This is not a failure. It is the normal condition of large, mature, multi-entity organizations, those that have grown through acquisition, operated across geographies, and accumulated system and process decisions over decades. The question is not Whether the organization deviates from best practice, and it does and it will, is not the question. The question is whether those deviations are understood, intentional, and managed. Understanding them requires knowing what best practice actually is, and what it is not.
What Best Practice Actually Is
That understanding starts with a structural property the major best practice frameworks share: the broader their applicability, the higher their level of abstraction, and the more translation work they require before they can be operationalized.
APQC’s Process Classification Framework applies across industries and organizational types precisely because it defines processes at a level of generality that abstracts away context. SAP’s reference processes specify transaction flows for an SAP environment, but the reference environment and a heavily customized fifteen-year-old implementation are not the same thing. Industry benchmarks describe what leading performers achieve, but the practices that produced those outcomes in one organizational context may not transfer to another.
Best practice, in other words, tends to be principled rather than prescriptive, particularly in cross-industry frameworks such as APQC’s PCF, which is explicitly classificatory rather than normative. Vendor-specific content, such as preconfigured SAP S/4HANA processes, sits closer to the prescriptive end of the spectrum, but still makes assumptions about organizational and data structures that many implementations do not match. In both cases, the framework defines what good looks like at a process level: end-to-end flow, ownership, measurement, continuous improvement. It does not fully specify how to achieve this in any particular organizational context. The specification is the work that remains after the best practice has been identified.
Consider a common situation in Procure-to-Pay. APQC’s PCF defines the process at a level that applies across all industries and organizational types: requisitioning, sourcing, contracting, ordering, receiving, payment. SAP’s reference process specifies how those activities should flow in an SAP environment. Neither tells an organization how to handle the approval workflow for a business unit with a mandatory four-eyes requirement above a locally defined threshold, a legacy ERP instance that cannot be upgraded before the next fiscal year, and a procurement team that reports to operations rather than finance. That is the actual 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. But it means that the work of translating best practice into operational design is substantial, and is consistently underestimated.
Where the Gap Opens
The gap between best practice and operational reality opens at four points, consistently, across organizations and process families.
The first is data structure. Best practice assumes a data model in which transactions are tagged, categorized, and linked in ways that make end-to-end process visibility possible. In most organizations, the data model reflects historical decisions made for different purposes. Cost centers were designed for financial reporting, not for process performance measurement. Supplier master data is fragmented across entities. Customer hierarchies do not align with how commercial relationships actually work. Building process-level visibility requires either reforming the data model, which is expensive and disruptive, or building analytical layers on top of it, which creates its own maintenance burden.
The second is system landscape. Best practice assumes a coherent system environment. Most large organizations operate across multiple ERP instances, supplemented by specialist systems for treasury, HR, and tax, connected through integrations that were built incrementally and are now difficult to change. Each integration point is a potential deviation from the best practice flow. Each specialist system has its own data model, its own processing logic, and its own update cycle. The process does not flow cleanly end-to-end because the systems through which it flows were not designed as an integrated whole.
The third is organizational structure. Best practice assumes process ownership is structurally possible, meaning an organization can appoint an owner with visibility across all contributing functions and authority to act on what they see. In most large organizations, the functional structure, the reporting lines, and the incentive systems are not designed for cross-functional process accountability. Best practice assumes the governance conditions that most organizations are still working to create. This helps explain why process governance often stalls at Level 3 rather than advancing to Level 4.
The fourth is business model specificity. Best practice is designed for a generic business. Most organizations are not generic. A manufacturing company with engineer-to-order production, a professional services firm billing on time and materials, a financial institution with regulatory constraints on transaction processing: each has process requirements that standard best practice does not fully address. The adaptation required is not cosmetic. It goes to the design of the process itself.
A fifth dimension, sometimes treated separately, is organizational culture and informal practice: the unwritten conventions, behavioural norms, and local interpretations that shape how processes are actually executed regardless of what is documented. Culture is harder to map than the other four dimensions but equally consequential for whether a standardization effort holds. The typical response to these gaps is a gap analysis. That response needs to be applied carefully.
The Gap-Analysis Trap
Gap analysis is the standard method for bridging as-is reality and best practice: compare the current process to the standard, identify the gaps, and build a program to close them.
The method is sound. The application is frequently not.
The misapplication is treating all gaps as problems to be closed. A useful distinction, one that does not yet have standard terminology in the field but reflects a pattern well documented in ERP implementation research, is between deficiencies and adaptations. Some gaps are deficiencies: deviations that reduce process effectiveness with no compensating business rationale. Others are adaptations: deliberate responses to specific business requirements that best practice, by design, does not account for. A customized approval workflow may deviate from best practice, but it may exist because the standard workflow creates a bottleneck that the business cannot afford. A non-standard data structure may complicate process reporting, but it may reflect a business model that standard structures cannot represent.
Closing these gaps without understanding why they exist produces processes that are closer to best practice on paper and less functional in practice. The workarounds return, because the underlying constraints that created them have not been addressed.
Effective gap analysis requires two disciplines that are frequently underweighted in practice.
The first is gap classification. Before deciding whether to close a gap, classify it as a deficiency or an adaptation. Deficiencies should be closed. Adaptations should be understood, documented, and managed as intentional design choices.
The second is root cause analysis before solution design. Most gaps have causes that are not visible in the gap itself. A process that deviates from best practice at the approval step may do so because the data arriving at that step is insufficient to support the approval decision. The root cause is earlier in the process, in the data capture or data quality step. Designing a solution at the approval step without addressing the data quality issue upstream will not close the gap. It will relocate it.
Figure 1: Gap Analysis Classification Matrix
Gap classification determines the right response to each deviation. Deficiencies should be closed. Adaptations should be understood and managed. Unclassified gaps require investigation before any action.
What Best Practice Is Actually Good For
If best practice cannot be applied directly, and gap analysis must be handled carefully, what is best practice actually useful for in the work of advancing process maturity?
Three things, specifically.
First, it is a shared language. Best practice frameworks give organizations a vocabulary for discussing process design that is not specific to their own history or architecture. When a process owner and an ERP architect use APQC process categories as a reference, they are working from a common frame of reference that makes the conversation more precise. Without that shared language, process design discussions tend to be conducted in organizational vernacular that means different things to different participants.
Second, it is a diagnostic benchmark. The value of best practice is not in the gap it reveals per se, but in the questions that gap forces. Why does the organization deviate from the benchmark at this step? Is it because the business requires it, because the system constrains it, or because nobody has ever questioned whether it needs to be this way? The third answer surfaces more often than organizations expect, and best practice is the tool that makes it visible.
Third, it is a sequencing guide. Best practice defines the logical dependencies in a process: what needs to happen before what, and why. That sequencing logic is often the most transferable element of a best practice framework, even when the specific activities need to be adapted. Understanding why goods receipt should precede invoice matching in P2P is more durable knowledge than knowing exactly how to configure the three-way match in a specific system version.
What This Means Before Your Next Best Practice Adoption
Before adopting a best practice framework , or commissioning a gap analysis against one, three questions serve as useful heuristics for assessing whether the program is structured to produce actionable results.
1. Is the best practice defined at the level of granularity where the organization needs guidance? Principles-level best practice (end-to-end flow, ownership model, measurement approach) is broadly applicable. Configuration-level best practice (specific workflow design, data structure recommendations) is context-dependent. Most gap analyses mix the two without distinguishing between them.
2. Does the gap analysis classify gaps as deficiencies or adaptations, or does it treat all gaps as problems to close? An analysis that produces a list of deviations without classifying them is a description of difference, not a basis for design decisions.
3. Is root cause analysis part of the program before solution design begins? A program that designs solutions to gaps without establishing why those gaps exist will produce changes that are correct in principle and ineffective in practice.
Best practice can appear from a distance as something 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 organizational context are temporarily set aside. The work of advancing from Level 2 to Level 3 maturity is bringing that description into contact with those constraints: classifying which gaps are deficiencies to close and which are adaptations to manage, establishing root causes before designing solutions, and building a standard that the organization actually owns rather than borrows.
Organizations that do this work gain something that no framework can substitute for: a standardized process grounded in operational reality rather than a description of what operational reality should eventually become.
#BPM #ProcessManagement #BusinessTransformation #ProcessImprovement #OperationalExcellence #ERP #BestPractice