ERP Hypercare Design Guide for Thailand Factory Go-Live

ERP hypercare is not simply a period when the implementation team remains on standby after launch. It is a time-boxed operating mode that brings incident decisions, business reconciliation, data correction, adoption, and support handover under one command structure so the organization can move safely into steady-state operations. This guide provides a practical 30-day plan, organization model, KPIs, exit criteria, and RFP clauses for a factory in Thailand.

Define ERP hypercare as a time-boxed operating mode

ERP go-live is not the end of a project. It is the point at which the organization proves that the designed processes work with real transactions, inventory, and financial closes. A process that passed in a test environment can behave differently when production volumes, cut-off times, multiple sites, exception approvals, and actual operator sequences converge. A vague arrangement in which users simply “ask the implementation vendor if anything goes wrong” is therefore insufficient. The organization must define, as a daily operating system, who can stop a process, who approves a workaround, and who confirms financial and inventory integrity.

In this guide, hypercare is a temporary framework that performs six functions at the same time:

1. Receive incidents through one command structure and assign severity and ownership.
2. Reconcile sales, procurement, production, and finance daily to identify business impact early.
3. Control data corrections through request, approval, execution, and evidence review.
4. Monitor interfaces, batches, access, and performance and identify recurring patterns.
5. Measure user adoption and proficiency and update training and procedures.
6. Transfer knowledge and decision rights to the steady-state support team and exit through objective criteria.

Microsoft’s go-live checklist covers more than testing and migration. It also calls for monitoring, help-desk and ticket processes, support transition, and readiness for elevated post-go-live support. ERP stabilization support should therefore be a distinct operating workstream in the RFP and contract scope, not an appendix to the cutover plan.

Hypercare versus steady-state support

The service should end because evidence shows that steady-state support can absorb it, not merely because 30 days have elapsed.

Establish entry conditions for ERP stabilization support before go-live

Hypercare is not an unlimited rescue period for incomplete launch preparation. If too many open items enter hypercare, design changes, training gaps, migration errors, and production incidents compete in the same queue and priorities collapse. Microsoft’s official guidance lists signed-off scope, SIT, UAT, performance testing, migration rehearsals, cutover ownership, and operational support readiness among the prerequisites for go-live.

At minimum, confirm the following entry conditions at the go-live decision meeting.

For a Thailand factory, do not hide VAT, withholding tax, tax branch codes, tax invoices, inventory reports, and intersite inventory movements in a single line called “finance testing.” SAP’s Thailand localization documentation identifies VAT, withholding tax, tax invoices, inventory reporting, and purchase-order formats. Microsoft’s Thailand guidance explains that tax branch codes affect VAT and withholding-tax transactions and inventory movement among sites. Product configuration and compliance with local requirements are different questions; obtain advice from qualified Thai tax and accounting professionals for tax and accounting decisions.

For migration, parallel-running, and rollback design, see the production management system migration guide for Thailand. This article focuses on what follows: control after real production transactions begin.

State the assumptions of the 30-day Thailand factory model

The figures below are neither market averages nor guaranteed values suitable for every ERP. They are an illustrative RFP baseline for discussing responsibilities. Adjust them for plant size, operating calendar, closing dates, product risk, regulations, and system architecture.

The four processes are order-to-cash, procure-to-pay, plan-to-produce, and record-to-report. Because “P2P” usually means procure-to-pay, this guide spells out Plan-to-Produce to avoid ambiguity. Give every flow a start event, completion evidence, value and quantity checkpoints, and an exception approver.

Staffing must define working hours and authority, not just headcount. If everyone is available only during the day at a two-shift factory, night-shift issues wait until morning. Keeping every specialist onsite around the clock is usually excessive. A practical model places super-users and first-line intake across shifts while specialists have defined on-call triggers and response times.

Remove accountability gaps with one command center and RACI

Role of the command center

The command center is a decision route, not a room. It consolidates shop-floor reports in one ticketing system and manages business impact, priority, workaround, permanent correction, evidence, and prevention as one chain. Solutions agreed in chat must later be recorded in the ticket. Otherwise the same symptom recurs on another shift and the knowledge disappears during support handover.

Cap the daily command call at 30 minutes and keep the agenda fixed:

1. Review S1 issues affecting safety, shipping, production stoppage, or statutory processing.
2. Review open S2 issues and overdue items from the previous day.
3. Review seven interfaces and overnight batch results.
4. Review variances in sales, procurement, inventory, production reporting, and finance.
5. Approve or reject data corrections and production changes.
6. Decide updates to training, FAQs, and runbooks.
7. Read back the owner, next deadline, and user communicator for every item.

RACI and escalation matrix

R means responsible, A accountable, C consulted, and I informed. As a rule, assign A to one person or role because multiple accountable parties delay final decisions. Treat the exit decision as an explicit exception that requires joint approval by the factory business owner and steady-state operations owner. When several suppliers participate, name roles and deputies in the contract schedule instead of listing only company names.

Standardize S1, S2, and S3 triage and recovery

Severity should follow business impact and time sensitivity, not technical difficulty. A display issue affecting one person may be critical if that person cannot issue a tax invoice before a deadline and has no alternative. Conversely, a minor layout defect visible to many users may be S3.

These are illustrative RFP targets, not universal SLAs. A 24-hour plant, food or pharmaceutical production, hazardous processes, or month-end closing may require stricter timing and definitions. Lower-impact back-office functions may justify different targets.

Mandatory ticket information

• Time, site, shift, user, and terminal or equipment.
• Identifiers such as document, material, lot, order, or journal.
• Expected and actual results, including inputs rather than screenshots alone.
• Business impact, workaround, deadline, and affected volume.
• Cause hypothesis, logs reviewed, and actions already taken.
• Workaround, permanent correction, approver, and verifier.
• Counts, values, or quantities before and after correction, with evidence links.
• Prevention action and the FAQ or runbook update location.

Separate recovery from permanent correction

For S1 incidents, controlled workarounds may restore operations before the full cause is known. Do not mark a workaround as a final resolution. Update the parent ticket when operations resume, then track root-cause analysis, permanent correction, regression testing, and documentation as child tasks. If manual entry or an external spreadsheet was used, reconcile duplicate postings and number gaps when returning the data to ERP.

Control data correction from request through evidence

Master-data and opening-balance errors often surface immediately after go-live, creating pressure to update the database directly. Unapproved corrections can damage audit trails, downstream documents, interfaces, and accounting periods. Prefer standard screens, approved adjustment documents, and product reprocessing functions. Limit direct updates to exceptional cases supported by the product vendor’s formal procedure and responsible-owner approval.

A correction request should contain target data, cause, method, before value, after value, impact analysis, approver, executor, verifier, execution time, and rollback approach. Separate executor and verifier, then recheck values, quantities, tax classification, inventory valuation, and affected interfaces. For bulk corrections, run a limited sample before the full load and compare control totals for records and values.

Priority of correction methods

A falling number of corrections is not sufficient evidence of stabilization. Confirm that the same cause is not repeating and that upstream master data, training, or interface defects have permanent actions.

Distinguish system availability from business integrity through daily reconciliation

An available screen and a running server do not prove that revenue, inventory, and tax are correct. Maintain two layers: technical monitoring and business reconciliation.

In Thailand, tax branch and warehouse structures may affect processing even within one legal entity. If an intersite movement posts a goods issue at one site but remains unreceived at the other overnight, physical location and book stock diverge. Missing or incorrect tax branch codes may later affect VAT or withholding-tax reporting. In addition to product configuration checks, validate statutory reports and filings with qualified local tax and accounting professionals.

Do not carry a difference merely because its value is small. Define tolerance, approver, and resolution deadline. Classify rounding differences, timing differences, and true errors; if a balance rolls forward, record its amount and reason. If the first month-end or tax close falls outside the 30-day period, add a clause for elevated support through that first close.

A 30-day post-go-live ERP roadmap

Operating at maximum intensity for all 30 days increases fatigue and cost. Provide stronger immediate response in the high-risk first week, then move leadership to steady-state support as stability improves. Do not reduce support automatically by calendar; advance only when the relevant gate is satisfied.

Day 0–3: Keep the plant moving

For the first three days, reducing blind spots is more important than reducing ticket count. Before every shift, reconfirm critical flows and intake channels. After each shift, review unprocessed documents, interface queues, and inventory differences. Do not distribute workarounds only verbally; use a short instruction with version number and expiry time.

Day 4–14: Move from symptom response to cause management

Classify tickets not only by module but also by design, migration data, master data, access, integration, training, operation, and performance. Group symptoms sharing the same cause and prioritize permanent fixes. Confirm through logins, transaction volumes, and user interviews that a decline in questions does not mean users have given up.

Day 15–30: Make steady-state support the lead

If the implementation team continues to chair every call, knowledge drops off a cliff on exit day. Have the operations team lead daily calls and demonstrate S1 drills, interface replay, backup restoration, access requests, and vendor escalation. Microsoft’s transition guidance also calls for knowledge transfer on design decisions and changes, plus training in rollback, failover, disaster recovery, and backup restoration.

Standardize the daily evidence pack and shift handover

Freeze a daily “evidence pack” at the same time each day so decisions can be reconstructed. It should contain tickets by severity, movement since the previous day, overdue work, results for seven interfaces, critical batches, volumes for four critical flows, finance, inventory, and tax differences, data corrections, production changes, adoption, and open decisions. Do not retain dashboard screenshots alone; record extraction conditions, the observation time, and references to source data. A live screen that changes later cannot explain what evidence supported a decision at that moment.

Separate the preparer and approver, and explicitly write “none” on days with zero items. A blank does not reveal whether the value is zero, uncollected, or unreviewed. When reconciliation differences are copied manually, record the source total, destination total, and verifier. With automated aggregation, confirm not only job success but also whether the population is plausible against the previous day and production plan.

At a two-shift factory, information loss during handover is a material risk. The outgoing shift reads back open cases, active workarounds, processes that must not be touched, the next check, and triggers for calling specialists. The incoming shift repeats the information and accepts its tickets. Do not rely on “read the chat”; log the handover as a business event with time and owners.

Every workaround needs an owner, scope, start time, and end condition. If shipments are temporarily recorded in an external sheet, specify warehouses, documents, numbering, the owner for returning data to ERP, and reconciliation against double posting. An expired workaround that survives by habit becomes an uncontrolled shadow process. The daily call must review whether existing workarounds can end, not only approve new ones.

Do not compress daily performance into one executive line. “Zero S1” can hide a rapidly growing S2 backlog, widening inventory differences, or slow night-shift intake. Provide executives a short view of continuity, financial impact, customer impact, and likely exit, while retaining cause, site, and shift detail for operators. Build two views from the same data and keep definitions common.

Define the repository, naming convention, access rights, and retention period so evidence remains traceable after 30 days. Avoid unnecessary personal or confidential data in screenshots and restrict access when it is required. Hypercare demands speed, but speed does not mean abandoning evidence. Because this period contains many decisions, concise standardized records become the most valuable training material for steady-state support.

Do not measure adoption by ticket count alone

Fewer questions do not necessarily mean adoption. Users may have returned to old spreadsheets or paper, shared incorrect shortcuts, or asked super-users to transact informally on their behalf. Combine quantitative and qualitative indicators.

Microsoft identifies sign-ins, transaction counts, inventory and forecast accuracy, interviews, and surveys as examples of post-go-live adoption measures. If results are weak, do not label the issue “user resistance” without checking screen design, response time, access, procedures, and master-data quality. Five- to ten-minute scenario lessons, shift-specific clinics, and updated FAQs can work faster than another large classroom course.

Our guide to choosing packaged-software implementation support in Thailand discusses local support and vendor selection. For hypercare staffing, assess not only product knowledge but also shop-floor language, shift coverage, and access to business decision-makers.

Accept ERP support handover through deliverables and demonstrations

Support handover does not finish when design documents are placed in a shared folder. It finishes when the receiving team demonstrates that it can detect, decide, recover, and explain without relying on the implementation team.

Required runbook contents

1. Start conditions, normal completion, exceptions, and reconciliation points for four critical flows.
2. Monitoring, replay, duplicate prevention, and contacts for seven interfaces.
3. Batch dependencies, deadlines, and safe restart after failure.
4. S1, S2, and S3 examples and escalation contacts.
5. Request, approval, and expiry for users, roles, and emergency access.
6. Backup, restore, failover, and disaster recovery.
7. Request, approval, validation, and evidence for correction and production change.
8. Checks for Thailand tax branch, VAT, withholding tax, and inventory reporting.
9. Different procedures for month-end, year-end, and physical inventory.
10. Logs, reproduction details, and contract numbers required for vendor support.

Validate knowledge transfer with reverse shadowing: the recipient executes while the implementation team observes. In this model, steady-state support leads two daily command calls and the implementation team intervenes only to correct an error. Require the deputy to demonstrate the same capability so the process survives absence.

Combine this with the production management system implementation process for Thailand factories to design a continuous accountability chain from requirements through handover and prevent issues falling between implementation and maintenance contracts.

Make hypercare exit criteria an objective gate

Agree exit criteria during the RFP, not just before the contract end date. In this illustrative model, every condition below must remain satisfied for 10 consecutive business days. These are proposal baselines, not universal guarantees.

A 99.5% interface success rate cannot automatically be translated into five failures per 1,000 transactions. The denominator may be messages, files, or business documents, and the result changes depending on whether successful replay is counted. State the formula, aggregation time, exclusions, and source in the RFP.

Also decide whether an S1 event resets the 10-day sequence to zero or whether a known, contained cause may be treated as an exception. Exception approval should be joint between the business owner and steady-state operations owner, not the command lead alone.

What vendor cases teach—and what they do not prove

Recent official case studies show the importance of post-go-live operations and people readiness, not only implementation speed. However, all are vendor-published individual cases. Their durations and benefits cannot be assumed for another company.

In SAP’s Evatec case published on September 16, 2026, the approximately 550-person high-tech equipment manufacturer reportedly moved from contract to go-live in 10 months and then ran six months of hypercare. Scope included finance, sales, procurement, production, and project business, while process and data ownership, clean core, and standardization were emphasized. This is not evidence that every project needs six months; it demonstrates that broad transformation may require a longer stabilization period.

The Daikin case published the same day reports a pilot go-live in 10 months affecting more than 300 frontline users. SAP and EY report early results of a 10% improvement in counter efficiency and a 20% faster financial close. These are results reported for that vendor case, not general improvement rates. An organization must define its own baseline, measurement period, workload, and population.

SAP’s July 2026 Swarovski case reports approximately 25,000 tests involving more than 600 participants, two dress rehearsals, a 66-hour conversion window, and 24×7 support during hypercare. This, too, is a specific large-transformation case. The transferable lesson is not to copy the numbers but to design testing, rehearsal, conversion, and elevated support as one operating chain.

RFP clauses for post-go-live ERP support

“Post-go-live support included” leaves staffing, working hours, deliverables, and exit open to interpretation. Put the following clauses in the RFP or statement of work so proposals can be compared.

RFP checklist

Evaluate not only how many people are proposed, but also which shifts they cover, which decisions they can make, and which languages they can use with the shop floor. Agree the boundary between no-cost correction and chargeable extension, and between product defect, configuration error, and additional request.

Sample contract wording

“The supplier shall provide elevated support for 30 calendar days from go-live. Completion shall not be determined by expiry alone, but when the exit gates in the schedule have been met for 10 consecutive business days and approved by the customer’s business and operations owners. Where critical incidents, reconciliation differences, or incomplete runbooks remain, both parties shall document scope, cause ownership, extended staffing, and cost before deciding the continuation method.”

This wording is an issue-framing example, not legal advice. Have legal counsel review actual terms under the applicable law and internal procurement conditions.

Common failures and preventive actions

The implementation team solves everything

It may be faster initially, but operations gains no experience. From Day 15, make operations responsible and move implementation into a supervisory role. Accept a temporary increase in resolution time to build independence after exit.

Cases disappear in chats and conversations

Convenient shop-floor channels need not be banned, but every case must ultimately enter one ticket with cause, workaround, fix, and evidence. If a chatbot or form is used, return a ticket number automatically.

KPIs show averages only

Average response time hides one very old case or poor night-shift performance. Break results down by severity, site, shift, and age, and review the 95th percentile and overdue count.

Documentation waits until the final week

Update the runbook whenever an issue is resolved. Make relevant FAQ and procedure updates part of ticket closure so documentation does not pile up at the end.

IT alone approves tax readiness

A technically correct configuration does not prove that reports and filings meet local requirements. Separate the review scopes of product specialists, finance, and qualified local tax advisers and retain approvals.

FAQ: ERP hypercare cost, duration, and exit decisions

What is ERP hypercare?

It is a time-boxed operating mode in which business, IT, and implementation teams use one command structure for incident response, daily reconciliation, data correction, adoption, and knowledge transfer. Unlike simple standby or a warranty period, it has meetings, RACI, KPIs, evidence, and exit gates.

How long should ERP hypercare last?

There is no universal answer. Base it on the time needed to complete critical processes, month-end and tax cycles, shifts, site count, and change scale. This guide uses 30 days as an illustrative model; the Evatec vendor case reports six months. Decide with exit gates, not days alone.

How should ERP stabilization support be priced?

Build the price from headcount by role, coverage hours, onsite versus remote work, language, holidays, on-call duty, process scope, number of interfaces, deliverables, and extension rates. Even with a fixed price, define treatment of requests or large changes beyond the assumptions.

Is a 15-minute S1 response mandatory?

No. The 15-minute acknowledgement and 60-minute workaround decision in this guide are examples for an RFP discussion. Agree achievable values based on plant hazards, downtime cost, alternatives, and 24-hour coverage.

What belongs in hypercare exit criteria?

Include unresolved critical incidents, aged S2 backlog, interface success, financial and inventory reconciliation, ticket evidence, runbook coverage, operations demonstrations, and adoption. For a Thailand factory, consider tax branch, VAT, withholding tax, tax invoice, and intersite inventory checks.

Is ERP support handover complete when documents are accepted?

Not by itself. Confirm that the receiving team can demonstrate daily command, severity assignment, replay, recovery, correction requests, and vendor contact and can explain its decisions. This model includes two operations-led daily calls in the exit gate.

Can the implementation vendor alone approve Thailand tax configuration?

Separate technical validation of product configuration from legal and filing compliance. This guide is not legal or tax advice. Confirm VAT, withholding tax, tax branches, and tax invoices with qualified Thai tax and accounting professionals.

Summary: Prove ERP go-live success through exit gates

Post-go-live stabilization should not depend only on the goodwill or experience of the implementation team. Design a time-boxed operating model that includes one command center, severity and ownership, daily business reconciliation, controlled data correction, adoption measurement, and support handover through runbooks and demonstrations. Exit based on consecutive achievement of gates for critical incidents, backlog, integration, finance and inventory, evidence, and knowledge transfer—not merely a calendar date. At a Thailand factory, include tax branch, VAT, withholding tax, tax invoices, and intersite inventory movement alongside system availability to reduce operational blind spots.

TOMAS TECH can support Thailand factories from pre-go-live readiness reviews through 30-day hypercare, daily reconciliation, and local support handover. If you are still shaping the RFP and exit gates for two shifts, multiple sites, or Thailand tax requirements, you can contact us at the planning stage.

References

• SAP News, Evatec Cloud ERP case, 2026-09-16: https://news.sap.com/germany/2026/09/cloud-erp-einfuhrung-evatec/
• SAP News, Daikin ERP transformation, 2026-09-16: https://news.sap.com/2026/09/daikin-people-centric-erp-transformation-disconnected-to-autonomous/
• Microsoft Learn, Dynamics 365 go-live checklist: https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/prepare-go-live-checklist
• Microsoft Learn, transition and handover: https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/change-management-transition-handover
• SAP News, Swarovski Cloud ERP migration, 2026-07: https://news.sap.com/2026/07/swarovski-redefining-excellence-sap-cloud-erp/
• SAP Help Portal, Thailand localization, 2025 FPS01: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/7340a09096454b7abf4379f926a21567/6b3a4b6767f64ae3b2eb5b48b199d511-87.html
• Microsoft Learn, Thailand tax branches: https://learn.microsoft.com/en-us/dynamics365/finance/localizations/thailand/apac-tha-tax-branch-dimensions