ERP: make fit-to-standard an explicit business decision

The standard is a decision baseline

Fit-to-standard should mean comparing a demonstrated business need with an executed standard capability. It should not mean signing a sales presentation or rebuilding every old ERP screen. The workshop must lead to a choice: adopt the process, change the organisation, configure the product, build an extension or retain a temporary external capability. Each choice creates cost, ownership and upgrade consequences.

The way a request is written matters. ‘We need the old field’ describes a screen. ‘The supervisor must identify blocked orders before dispatch’ describes an outcome. A demonstration can establish whether the standard achieves that outcome with representative data. The business owner assesses usefulness, the architect assesses sustainability and finance quantifies consequences. None of these roles can decide every exception alone.

A fictional workshop on blocked orders

In a fictional distributor, seven branches request 26 changes to order handling. All figures are teaching examples. One branch manager wants to preserve a special colour indicating that credit has been exceeded. The demonstration reveals a standard block reason and a filtered list. The actual difference is decision timing: the old organisation waits for a local manager, while the target delegates the decision centrally.

The workshop uses 40 fictional orders, including ordinary sales, late payments, credits, customers spanning branches and partial deliveries. The credit manager executes cases rather than merely watching a consultant. The team measures decision time and mistakes. Three gaps emerge: a display preference, a training need and a missing contractual rule. Only the last initially justifies technical investigation. The resulting record describes operating decisions rather than an undifferentiated list of requests.

Prepare a demonstration that can produce evidence

Before the workshop, the process owner specifies the desired outcome and common exceptions. The integrator prepares a system with a known version, configuration and limitations. The data team includes missing values, currencies, units, returns and linked documents. A perfectly clean demonstration does not expose data quality or control ownership. Invite the person who handles exceptions daily; that person often knows the last operation omitted from the procedure.

Record what worked, failed and remained untested. A feature promised for a future release cannot close a present gap. The business decision owner restates each gap as an obligation or expected benefit. Legal specialists identify the precise requirement and scope of a legal claim. Commercial teams explain observable consequences of refusing a contractual request. Keep this evidence in the register so the next decision does not depend on someone remembering a conversation.

Worked exception register

Price the entire exception lifecycle

For this model, total exception cost equals design, development and initial acceptance plus cumulative operations, upgrade testing and planned removal. Include the business people needed for every release. Recurring costs do not vanish when allocated to a maintenance budget. A custom function dependent on one scarce individual also carries capacity risk. Make that risk visible rather than claiming it can be converted precisely into money.

A fictional extension costs EUR 48,000 initially, EUR 9,000 annually to maintain and EUR 6,000 annually to test. Over four years, before discounting and removal, it costs EUR 108,000. Saving 20 minutes on 300 monthly transactions at EUR 35 an hour creates a theoretical EUR 42,000 annual benefit. If only half the time can actually be redeployed, the benefit falls to EUR 21,000 annually, or EUR 84,000 over four years. Time savings alone do not cover the cost.

That conclusion does not automatically prohibit the extension. It requires another demonstrated benefit, such as avoiding contractual exposure or enabling profitable service. Compare the standard with organisational adaptation, configuration, extension and external retention at equivalent volume. An inexpensive technical option that creates an extra hour of daily branch work may be the costliest option for the enterprise.

Allocate decision rights to the actual risk

In this exercise, the process owner can accept configuration without code changes after testing. An extension affecting financial calculation needs finance, architect and product-owner approval. A change to the ERP core goes to programme leadership with evidence that alternatives are inadequate. The fictional financial threshold is EUR 30,000 of initial expense: above it, require a four-year lifecycle estimate and named sponsor. This is an example of governance rather than a universal purchasing rule.

Security checks permissions, interfaces and logging. Operations checks monitoring and diagnosis. Training assesses changes to daily tasks. A veto should identify a specific risk rather than express a technical preference. A sponsor can accept residual risk within their authority, but cannot assert compliance that has not been demonstrated. Record the decision date, dissent and reconsideration trigger. Approval does not make an exception permanent.

Test business results and continued maintainability

Acceptance must cover the entire journey. A discount can be correct on an order and wrong on a credit note. A peripheral interface can copy an item while losing its sales unit. Follow identifiers end to end, reconcile quantities and amounts and test correction permissions. The business owner accepts observed results; the developer cannot be the sole approver of the requirement they implemented.

Before wider rollout, execute the scenario on a representative target release and test its behaviour after upgrade. An extension depending on an undocumented interface remains an unresolved issue. In this example, development stops if nobody can diagnose failures in operations or if financial controls cannot detect divergence. A small prototype success does not establish maintainability across every branch. Define ownership and diagnostic evidence before deployment.

Make removal a managed decision

Assign each exception a review date or event: a new standard capability, a customer-contract change, a branch merger or an interface replacement. The product owner records actual users, cost and incidents. Measure removal only when the component has genuinely been disabled. A hidden feature still called by an automated job continues to create debt.

Later requests should follow the same evidence-based reasoning. An urgent incident needs a fast route with temporary authorisation followed by substantive review. Otherwise the programme recreates the customisations it removed, now without documentation. Sustainable standardisation creates an architecture the company can explain, change and operate using its own resources, rather than a prohibition that users must circumvent to finish their work.

Sector implications

Manufacturing requires tests of bills of material, traceability and consumption variances. A change to cost calculation needs joint production and finance controls. Retail needs promotions, returns and multi-site availability cases, rather than ordinary order entry alone. Standard adoption may require common item governance: changing the screen does not resolve duplicated branch records.

Services organisations should test time allocation, scope changes and fixed-price contracts. International groups must distinguish local tax requirements, working languages and inherited habits because they lead to different decisions. Countries contribute evidence without automatically receiving their own product variant. Nevertheless the process must preserve applicable obligations and capabilities needed for local markets. Standardisation requires knowing which operations can truly be shared.

Sources and method

This is a 2022 retrospective written in 2026. The consulted SAP training pages are current resources describing Activate workshops. They verify concepts without establishing that every current screen or function existed in 2022. The 2010 NIST guide supplies an earlier reference for exercises and recovery. The economic choices and thresholds here are teaching proposals, rather than SAP requirements.

Primary sources checked in October 2026. SAP, Fit-to-Standard Analysis Workshops. SAP, Preparing for Fit-to-Standard Analysis Workshops. NIST SP 800-34 Rev. 1, 2010.

All situations, amounts, durations and thresholds are fictional teaching examples. They illustrate a decision method and do not describe any CYTIZEN engagement or market benchmark. The operational recommendations are the author’s proposals, separate from the cited documents.