An ERP clean core implementation is not a blanket ban on customisation. It moves non-differentiating work to standard processes, puts genuine competitive requirements behind upgrade-safe boundaries, and gives every remaining exception an owner, an expiry date, and a retirement condition. This guide turns that principle into an RFP, fit-to-standard workshop, 90-day assessment, and acceptance model for factories in Thailand and ASEAN.
What clean core means in an operating factory
Clean core is the discipline of keeping an ERP estate upgradeable while still supporting necessary differentiation. SAP’s guidance frames it across five dimensions: business processes, extensibility, data, integration, and operations. Reducing the number of add-ons is therefore not enough. Duplicate master data, unmonitored interfaces, unsupported APIs, or manual operations can leave a technically “clean” system operationally fragile.
A Thai factory may need a global template, Thai localisation, customer-specific labels, warehouse practices, machine connectivity, and multilingual approval at the same time. Forcing every need into standard software can break execution; putting every request into the core can block the next release. The practical answer is to classify each requirement, decide where it belongs, document who approved it, and set a review point.
| Common misconception | Working interpretation | Evidence to retain |
|---|---|---|
| No customisation is allowed | Reduce non-differentiating changes and move valid extensions to safe boundaries | Requirement decision and extension register |
| A high standardisation ratio equals success | Balance process outcomes, upgradeability, and control | KPIs, regression scope, exception expiry |
| Cloud ERP is automatically clean | Redesign data, interfaces, and operations as well | Data ownership, interface inventory, monitoring |
| Deleting an add-on completes the work | Change the procedure, permissions, training, and audit trail | Retirement approval and usage evidence |
The governing question is not merely “standard or custom?” First ask whether the requirement protects compliance, customer value, safety, quality, or a real competitive capability. Then test standard configuration, an approved in-app extension, and a side-by-side service in that order. Only unresolved requirements should become time-limited exceptions.
Translate the five clean-core principles into factory evidence
The five dimensions become useful when an RFP asks for verifiable artefacts rather than marketing statements.
| Dimension | Factory question | Minimum deliverable |
|---|---|---|
| Business processes | Is the delta driven by law, customer value, quality, or differentiation? | Process delta and KPI |
| Extensibility | Does it use an approved extension point and remain upgradeable? | Extension pattern, owner, retirement rule |
| Data | Who owns the golden record and quality rule? | Data dictionary and stewardship matrix |
| Integration | Are contract, retry, monitoring, and outage responsibilities defined? | Interface register and SLA |
| Operations | Can the team test and support each release? | Regression pack and runbook |
Do not convert today’s workaround directly into a requirement. “We must continue triple entry” describes the current state. “The release owner must verify lot approval evidence within ten minutes” describes an outcome that standard workflow or a separate approval app may satisfy.
For data, assign ownership of material, BOM, equipment, supplier, batch, and unit-of-measure records. For integration, decide when to use an API, event, or file and how each path is observed. For operations, name the people who run regression tests after quarterly releases. One governance forum should cover all five dimensions so that a clean development design does not become an unowned operating model.
Run fit-to-standard as a decision workshop, not a screen-copying session
In a fit-to-standard workshop, demonstrate the standard scenario first. Ask whether it delivers the business outcome, not whether every field appears in the same position as the legacy screen. Discuss the standard process, the required outcome and control, and then the delta.
The room should include the process owner, shop-floor key users, quality, finance, IT, integration specialists, and the implementation partner. Local users alone cannot approve a global exception; headquarters alone may overlook whether the line can actually operate. Each delta should leave the workshop as accepted, rejected, evidence required, or temporarily held with a due date.
| Workshop step | Decision question | Output | Accountable role |
|---|---|---|---|
| Standard walkthrough | Can the standard scenario achieve the result? | Fit record | Process owner |
| Delta statement | What is missing, for whom, and how often? | Delta requirement | Business owner |
| Evidence review | Is it legal, contractual, differentiating, or customary? | Supporting evidence | Quality/finance/management |
| Pattern selection | Which of the four classes applies? | Decision record | Standardisation board |
| Acceptance definition | What evidence will prove completion? | Acceptance criteria | Business and IT |
SAP’s clean-core business-process paper discusses fit-to-standard, delta requirements, fit/gap classification, and a Solution Standardization Board. The forum’s authority matters more than its name. It must compare cross-site reuse, safe extension, cost, and the expiry of technical debt. Record rejection reasons and conditions for resubmission as carefully as approvals.
Classify requirements as STANDARD, IN APP, SIDE BY SIDE, or EXCEPTION
STANDARD
Use configuration and process change for non-differentiating accounting, purchasing, inventory movements, and routine production confirmation. Standard does not mean untested. Segregation of duties, Thai tax documents, customer contracts, and quality approval must still pass acceptance.
IN APP
Use an approved in-app or on-stack extension for a field, permitted logic, form support, or transaction-adjacent behaviour that must execute inside ERP. Record the released API or extension point and its compatibility. “It was easier for the developer” is not a valid selection criterion.
SIDE BY SIDE
Place complex planning, portals, AI assistance, equipment-data processing, or rapidly changing applications outside the ERP core and connect them through released APIs or events. SAP guidance recommends side-by-side on SAP BTP for complex SAP Cloud ERP extensions, with on-stack considered when execution must occur in ERP. In a real selection, compare the ERP product, existing cloud estate, security model, and operating skills; do not assume one platform is mandatory for every system.
EXCEPTION
Use a time-limited exception when a legal interpretation, forthcoming standard feature, temporary customer contract, or transition dependency prevents immediate resolution. An exception needs a business owner, technical owner, reason, risk, expiry date, next review, workaround, and retirement condition. It must not renew silently.
| Class | Selection test | Mandatory evidence | Review trigger |
|---|---|---|---|
| STANDARD | Configuration and procedure meet the outcome | Configuration and fit evidence | Product release |
| IN APP | ERP execution is necessary and a released extension is available | API/extension record and regression result | Quarterly release |
| SIDE BY SIDE | Independent deployment or complex differentiation is justified | API contract, SLA, monitoring, recovery | Architecture or contract change |
| EXCEPTION | Immediate resolution is impossible but an end condition exists | Owner, expiry, impact, retirement plan | Due date, at least twice yearly |
Reduce ERP add-ons by risk and actual use, not by headline count
Moving from 100 add-ons to 50 says little about business risk. Thirty unused reports and one tightly coupled shipment routine are not equivalent. Inventory every add-on by usage frequency, business criticality, core coupling, standard replacement, regression effort, incident history, and data sensitivity.
Collect execution logs before relying on interviews. Identify unused functions, duplicates, expired legal logic, and functions now covered by standard releases. Retirement includes procedure change, training, permission removal, data retention, and audit evidence—not only deleting code.
| Assessment factor | Low | Medium | High |
|---|---|---|---|
| Usage | Unused for more than 90 days | Monthly | Daily or continuous |
| Core coupling | Released API only | Approved extension point | Direct table access/core modification |
| Business impact | Reference only | Manual fallback exists | Shipping, accounting, or quality stops |
| Standard replacement | Available now | Needs configuration/training | No replacement |
| Regression burden | Automated | Partly automated | Manual and person-dependent |
A company may score “coupling × change frequency × business impact” for internal prioritisation. That score is not an industry benchmark. Retire high-risk items with a viable standard replacement first; redesign high-risk but differentiating capability as side-by-side where appropriate.
Govern side-by-side extensions so they do not become a new legacy estate
Side-by-side can protect the core and accelerate differentiation, but only with explicit boundaries. Distinguish the ERP system of record, an application-owned record, temporary cache, and analytical copy. Minimise bidirectional updates.
Good candidates include shop-floor user experience, equipment preprocessing, supplier portals, AI recommendations, and advanced scheduling. Avoid duplicating tightly coupled accounting or inventory-valuation logic outside ERP without a compelling reason. Acceptance must show how the factory operates while disconnected and how it prevents duplicate posting after recovery.
The RFP should require released APIs, authentication and authorisation, audit logs, idempotency, retry, timeout, versioning, monitoring, incident ownership, deletion, and exit support. Incorporate the contract-level controls in our guide to manufacturing API integration development into the clean-core decision gate.
Protect the ERP core through interface governance
Factories connect ERP to MES, WMS, equipment gateways, labelling, quality, EDI, banks, tax services, and BI. The interface register should state source, target, data owner, pattern, frequency, maximum latency, retry, duplicate prevention, monitoring, sensitive data, and outage procedure.
SAP’s Clean Core Integration guidance describes technical classification, compliance visibility, monitoring scope, and improvement candidates. An implementation should distinguish released from unreleased, synchronous from asynchronous, governed from unmanaged, and monitored from unmonitored. If direct database access or shared folders remain, log them as exceptions with an impact and migration deadline rather than hiding them.
| Register field | Acceptance question | Failure example |
|---|---|---|
| Data contract | Are required fields, units, timestamps, and code sets agreed? | Dependency on an undocumented column order |
| Error handling | Who retries, quarantines, corrects, and approves? | Failure only generates an email |
| Idempotency | Can a message be replayed without duplicate posting? | A retry creates a second goods receipt |
| Monitoring | Are technical health and business completeness observed? | Only HTTP success is checked |
| Change control | Are versions and deprecation notices governed? | Partner update stops production unexpectedly |
| Continuity | Is there an outage process and post-recovery reconciliation? | Paper fallback has no re-entry rule |
Monitor business counts—orders, movements, and aged errors—as well as servers. A green infrastructure dashboard can still hide missing transactions. Operations meetings should review expired interface exceptions, missing monitoring, and unreleased API retirement alongside incident totals.
Compare a five-year TCO with explicit assumptions
Clean-core work may raise the initial budget because boundaries, automation, and monitoring require investment. Compare implementation, annual regression/maintenance, and upgrades separately. The following is a planning illustration, not vendor pricing, a market average, a benchmark, or promised savings.
Assumption: one factory in Thailand, 120 users, five years.
| Scenario | Initial | Annual regression/maintenance | Year-three upgrade | Five-year total |
|---|---|---|---|---|
| A: core-modification led | THB 4.80M | THB 1.20M × 5 | THB 2.40M | THB 13.20M |
| B: standard + in-app/side-by-side | THB 5.40M | THB 0.65M × 5 | THB 0.80M | THB 9.45M |
The arithmetic is 4.80 + (1.20 × 5) + 2.40 = THB 13.20M for A and 5.40 + (0.65 × 5) + 0.80 = THB 9.45M for B. The difference is 13.20 − 9.45 = THB 3.75M, or 3.75 ÷ 13.20 × 100 = 28.4% lower than A after rounding. B starts THB 0.60M higher but finishes lower under these assumptions.
Do not market 28.4% as a general saving. Actual outcomes depend on the current add-ons, data quality, licences, cloud contracts, sites, downtime constraints, internal capability, and number of interfaces. Require bidders to answer the same five-year cost template, including retirement and exit costs.
Use a 90-day assessment to create a decision-ready roadmap
A 90-day review should reduce uncertainty rather than pretend to finish the whole design.
Days 1–20: DISCOVER
Collect add-ons, interfaces, jobs, reports, master data, roles, incidents, and change records. Walk the plant to observe terminals, paper, spreadsheets, labels, and equipment. If usage evidence is unavailable, record that uncertainty.
Days 21–45: DECIDE
Run fit-to-standard for priority processes and place deltas into the four classes. Identify high-risk add-ons and interfaces. Approve principles, owners, and exception deadlines.
Days 46–70: BUILD
Test representative standard, in-app, side-by-side, and monitoring patterns. Include errors, disconnection, replay, authorisation, and audit logs—not only an attractive user interface. Draft the RFP response and cost templates.
Days 71–90: VERIFY
Review roadmap, TCO assumptions, deployment waves, acceptance, organisation, and risk with plant and management. Assign owners and deadlines to unresolved items. The outcome may be proceed, reduce scope, phase, or pause; it is not automatically a purchase decision.
| Period | Deliverable | Exit condition |
|---|---|---|
| Days 1–20 | Current-state inventory and usage evidence | Critical systems and owners identified |
| Days 21–45 | Four-class decisions and exception register | Priority requirements have an owner and due date |
| Days 46–70 | Representative proof and RFP draft | Key technical risks and response format tested |
| Days 71–90 | Roadmap, acceptance, investment assumptions | Management, plant, and IT agree the next decision |
Combine this assessment with our production-management implementation timeline so the 90-day diagnosis is not confused with the full delivery schedule.
Put clean-core evidence into the RFP and acceptance plan
Avoid a yes/no question such as “Do you support clean core?” Ask bidders to show:
- How standard scenarios, deltas, and approvers are managed.
- The decision criteria for all four classes.
- Released APIs, extension points, deprecated components, and compatibility.
- Systems of record, synchronisation, replay, audit, and monitoring.
- Regression scope, responsibility, and effort after each release.
- Usage evidence and acceptance for add-on retirement.
- Exception ownership, expiry, and review forum.
- Source, configuration, logs, data, and knowledge transfer at exit.
FAT should test configuration, extensions, API behaviour, and failures in a controlled environment. SAT/UAT should exercise the real plant network, devices, labels, connected systems, permissions, and realistic data. Include outage, timeout, duplicate messages, incorrect master data, unavailable approvers, and reconciliation after recovery.
| Class | FAT focus | SAT/UAT focus | Completion evidence |
|---|---|---|---|
| STANDARD | Configuration, roles, standard flow | Shop-floor procedure and control | Scenario result and approval |
| IN APP | Extension point, unit and regression tests | Device, form, and role behaviour | API/extension record and regression result |
| SIDE BY SIDE | Contract, error, monitoring | Outage, replay, reconciliation, SLA | Logs, dashboard, recovery record |
| EXCEPTION | Impact and workaround | Temporary operation is executable | Owner, expiry, retirement plan |
Continue the evidence after go-live. Link defects, workarounds, permanent fixes, and return-to-standard actions to a controlled backlog. Our ERP hypercare guide explains how to govern the first 30 days without turning temporary workarounds into permanent exceptions.
Handle the Thai depa scheme and local requirements carefully
The depa Thailand Digital Catalog Tax 200% page states eligibility conditions for SMEs of paid-up capital not exceeding THB 5 million and annual revenue not exceeding THB 30 million. It covers qualifying purchase or rental of registered digital products and services, states a special-deduction ceiling of THB 300,000, and gives a period from 24 June 2025 to 31 December 2027. This summary does not confirm eligibility for any company. Check the latest depa guidance and obtain Thai tax and accounting advice on qualifying expenditure, evidence, and filing.
Do not select an ERP only because an incentive may apply. Confirm the Thai contracting entity, registration of the product or service, expenditure date, and administration cost. An initial benefit should not conceal higher five-year integration or upgrade cost.
Local discovery should also cover Thai tax documentation, personal data, Thai-language use, plant connectivity, holidays, import/export, and BOI-related processes. Separate legal requirements from “we have always done it this way,” and retain the source and owner for each local delta.
Read vendor case studies as examples, not benchmarks
SAP’s September 2026 Colombina story describes a simultaneous migration across 16 countries for a company with seven factories and 39 distribution centres, integrating ERP and surrounding systems. Its Damen Shipyards story says 80% of operations are being consolidated on one SAP foundation with “Reuse before Buy before Build.” Its Evatec story describes a ten-month Cloud ERP Public Edition implementation followed by six months of hypercare.
These are vendor-published, company-specific cases. Do not present 16 countries, 80%, ten months, or six months as the normal result for a Thai factory. The transferable lessons are to establish one decision principle across sites, define the sequence of reuse/buy/build, and plan post-go-live stabilisation. Estimate your own plan from inventories, interfaces, data quality, user population, and downtime constraints.
Run a standardisation board with balanced post-implementation KPIs
If the only KPI is the standard-adoption rate, teams may remove differentiation that the business actually needs. A useful scorecard combines business outcomes, upgradeability, exception control, and operating quality.
| KPI | Example definition | Caution |
|---|---|---|
| Standard adoption rate | Requirements accepted as standard / requirements decided | Do not make a high percentage the objective by itself |
| Non-public API count | Non-public connections still used in production | Record an expiry date and replacement plan |
| Expired-exception rate | Expired exceptions / active exceptions | Prohibit automatic renewal |
| Upgrade regression effort | Total test hours for each update | Watch for apparent improvement caused only by reducing test scope |
| Automated-test coverage | Automated critical cases / all critical cases | Measure evidence quality, not only successful execution |
| Interface detection time | Time from interface failure to detection | Include missing business transactions, not just technical alarms |
| Extensions retired | Extensions decommissioned with evidence | Record risk reduction, not only the number removed |
Hold the standardisation board monthly or at each release. Its agenda should cover new requirements, exceptions approaching expiry, deprecated APIs, upgrade impact, and improvements arising from incidents. Put items awaiting a decision above information-only items. For every decision, retain the rationale, alternatives, impact, owner, and deadline so another team can reconstruct it six months later.
Frequently asked questions
What is an ERP clean core implementation?
It is an implementation and operating model that governs process, extension, data, integration, and operations so the ERP remains upgradeable. Standard is preferred, justified differentiation is placed in approved extension patterns, and exceptions receive owners and retirement dates.
Does SAP clean core prohibit customisation?
No. It discourages uncontrolled core modification. Use an approved in-app/on-stack extension when execution must occur inside ERP and side-by-side when a complex capability should be independently deployed. Record the decision and test compatibility.
Will fit-to-standard ignore shop-floor requirements?
It should not. Separate a legacy-screen preference from a compliance, quality, customer, safety, or competitive outcome. Evaluate the evidence, frequency, impact, and alternative transparently through a standardisation board.
Where should ERP add-on reduction begin?
Start with execution logs, criticality, coupling, standard replacement, regression effort, and incident history. Retire unused duplicates and redesign necessary high-risk functions behind approved boundaries.
What is the main risk of a side-by-side ERP extension?
An external application can become a new legacy system if data ownership, API contracts, identity, retry, monitoring, SLA, recovery, and exit are not governed. Test disconnection and reconciliation before acceptance.
How should clean-core value be compared?
Compare implementation, annual maintenance and regression, upgrades, integration, monitoring, retirement, and exit across the same period. The THB 13.20M versus THB 9.45M illustration above is a planning assumption—not a benchmark or quote.
Conclusion: do not let exceptions become permanent and ownerless
The goal is not to maximise a standardisation percentage. Move non-differentiating work to standard, protect necessary differentiation with upgrade-safe boundaries, and manage every exception with an owner, deadline, and retirement condition. Connect the five dimensions, fit-to-standard, four-class decisions, interface register, FAT/SAT evidence, and operating KPIs into one governance loop.
TOMAS TECH can support an extension inventory before product selection, a fit-to-standard workshop, and the preparation of an RFP or acceptance criteria. If you are still defining scope and want to separate standard work from valuable differentiation in a Thai factory, contact us for an initial discussion.
References
- SAP Help: Clean Core Extensibility for SAP Cloud ERP
- SAP Help: Clean Core Integration
- SAP: Clean Core Business Processes for SAP S/4HANA Cloud
- SAP News: Colombina, 18 September 2026
- SAP News: Damen Shipyards, 14 September 2026
- SAP News: Evatec, 16 September 2026
- depa Thailand Digital Catalog: Tax 200%
*Based on public information available on 20 September 2026. Confirm current legal, tax, product, and programme conditions with official sources and qualified advisers. Case-study figures and the TCO illustration are not market averages or performance guarantees.*
