Go-live ERP & Cutover Checklist: Runbook, Go/No-Go và Rollback

Go-live ERP và cutover là giai đoạn chuyển từ hệ thống/quy trình cũ sang hệ thống ERP mới theo một runbook đã được duyệt. Mục tiêu không phải “bật hệ thống vào cuối tuần”, mà là kiểm soát freeze, migration cuối, reconciliation, integration, quyền truy cập, communication và quyết định go/no-go trong một cửa sổ thời gian cụ thể.

Cutover chỉ nên bắt đầu khi evidence từ testing, UAT, migration, training và readiness đã đạt ngưỡng dự án đặt ra. Nếu các hard gate này chưa rõ, xem Kiểm thử ERP & UAT, Data Migration ERP và Change Management ERP trước khi lập runbook.

Cutover ERP gồm những workstream nào?

Workstream	Ví dụ đầu việc	Owner
Business Freeze	Dừng tạo/sửa giao dịch theo rule	Process Owner
Data	Extract cuối, load, reconciliation	Data Lead + Business Owner
Integration	Tắt/bật interface, queue control	Integration Lead
Access	Provision role, unlock user	IT/Security
Technical	Deployment, job, backup, monitoring	Technical Lead
Communication	Status, downtime, go/no-go message	Change/PM
Support	War room, severity, escalation	Support Lead

Sơ đồ cutover: chuỗi gate trước khi mở hệ thống

Cutover là chuỗi dependency có gate, không phải checklist song song. Nếu data chưa reconcile hoặc critical interface chưa phục hồi được, việc “đã tới giờ mở hệ thống” không phải lý do để bỏ qua No-Go.

Bước 1: Khóa cutover scope và cửa sổ chuyển đổi

Cutover scope phải nêu rõ system, company/site, data object, interface và user group nào chuyển trong đợt này. Với phased rollout, tránh dùng một runbook chung cho tất cả phase nếu dependency khác nhau.

• Cutover start/end window.
• Business downtime hoặc degraded operation.
• System nào read-only, system nào shutdown.
• Data snapshot/extract time.
• Đơn vị/pháp nhân/site nằm trong wave.
• Critical dependency với vendor hoặc third party.

Bước 2: Thiết kế freeze strategy

Freeze không nhất thiết có nghĩa toàn bộ doanh nghiệp dừng giao dịch. Có thể có nhiều lớp: master data freeze, transaction freeze, financial posting freeze hoặc controlled exception. Điều quan trọng là biết giao dịch phát sinh trong cửa sổ cutover sẽ được ghi ở đâu và ai chịu trách nhiệm nhập bù nếu cần.

Loại freeze	Câu hỏi cần khóa
Master Data	Từ thời điểm nào không tạo/sửa customer, vendor, item?
Transaction	Order/PO/inventory movement có dừng hoàn toàn không?
Finance	Posting nào bị khóa và exception nào được phép?
Integration	Interface nào pause, queue hay tiếp tục?

Bước 3: Migration cuối phải chạy theo runbook đã rehearsal

Không nên viết migration script mới trong đêm cutover nếu có thể tránh. Final load nên dùng pipeline và thứ tự đã rehearsal, với run ID, record count, reject log và owner rõ.

• Extract theo timestamp đã khóa.
• Load reference/master trước transaction nếu dependency yêu cầu.
• Open balance/open order theo sequence đã test.
• Reject/error có rule xử lý và owner.
• Rerun không tạo duplicate ngoài dự kiến.
• Thời lượng nằm trong cutover window đã rehearsal.

Bước 4: Reconciliation trước khi mở hệ thống

Load job “Success” chưa đủ. Business owner cần đối soát những domain trọng yếu trước khi người dùng bắt đầu giao dịch thật.

• Inventory quantity/value theo item/warehouse/lot nếu cần.
• AR/AP open item và total balance.
• GL opening balance theo account/dimension.
• Open sales order và purchase order.
• Critical master count và key mapping.
• Integration queue/message tồn trước khi bật lại.

Ngưỡng chấp nhận phải theo rule của từng domain; không dùng một tỷ lệ chung cho mọi dữ liệu.

Bước 5: Bật integration theo dependency, không bật tất cả cùng lúc

Interface cần thứ tự rõ: system of record nào phải sẵn sàng trước, queue cũ xử lý thế nào, message trong freeze window đi đâu và khi nào bắt đầu monitor SLA. Xem tích hợp ERP cho idempotency, retry và reconciliation.

Bước 6: Provision user và smoke test đúng role

Trước mở rộng user base, nên smoke test một nhóm critical role: đăng nhập, quyền menu/transaction, tạo giao dịch mẫu, approval, report và integration downstream. Cần có cả negative permission check ở những role nhạy cảm.

Go/No-Go criteria nên gồm những gì?

Gate	Evidence
UAT	Critical scenario pass, known issue có owner
Data	Critical reconciliation đạt acceptance
Integration	Critical interface test/recovery sẵn sàng
Access	Critical role provision và test đúng
Training	Key role sẵn sàng và support channel rõ
Technical	Backup/monitoring/job/deployment hoàn tất
Business	Sponsor/process owner chấp nhận residual risk

Khả năng restore và recovery của ERP không nên chỉ xuất hiện như một checkbox kỹ thuật. Nếu RTO/RPO, restore test hoặc DR runbook chưa rõ, xem Backup & Disaster Recovery ERP trước khi chấp nhận technical readiness.

Không nên thay đổi tiêu chí vào phút cuối chỉ vì gần deadline. Nếu một blocker bị hạ severity để “kịp go-live”, steering team phải ghi rõ business risk và người phê duyệt.

Rollback criteria: quyết định trước khi cần dùng

Rollback có thể khó sau khi giao dịch thật phát sinh, nên architecture và rule phải được xác định trước. Một số trigger có thể gồm critical data không reconcile, production transaction không thể hoàn tất, integration critical không phục hồi trong window hoặc risk bảo mật vượt ngưỡng chấp nhận.

• Điểm cuối cùng còn có thể rollback an toàn.
• Ai có quyền kích hoạt rollback.
• Dữ liệu phát sinh sau cutover start xử lý thế nào.
• Hệ thống cũ có thể mở lại ở trạng thái nào.
• Communication khi rollback.
• Kế hoạch retry cutover sau rollback.

Cutover runbook mẫu

ID	Task	Owner	Planned	Dependency	Evidence	Status
CUT-001	Freeze master data	Data Owner	T0	Business approval	Freeze confirmation
CUT-002	Final extract	Data Lead	T+1	CUT-001	Run ID/count
CUT-003	Load opening data	Data Lead	T+2	CUT-002	Load log
CUT-004	Reconcile critical balance	Business Owner	T+3	CUT-003	Signed reconciliation
CUT-005	Enable critical interface	Integration Lead	T+4	CUT-004	Smoke test

War room và communication trong ngày go-live

War room cần channel, severity taxonomy, triage owner và escalation path. Không để mọi user nhắn trực tiếp cho consultant riêng lẻ vì issue sẽ mất traceability.

• Status cadence theo risk, không nhất thiết cố định cho mọi dự án.
• Một source of truth cho cutover status.
• Issue ID, severity, owner, ETA/next action.
• Decision log cho go/no-go/rollback.
• Message template cho user và management.

Hypercare bắt đầu ngay sau go-live

Go-live không phải điểm kết thúc. Hypercare cần theo dõi critical incident, integration failure, data issue, training/process issue và transaction blocker. Nên phân loại issue đúng bản chất để defect không che mất adoption hoặc data governance problem.

Để đo hệ thống có thực sự ổn định và tạo giá trị, xem KPI ERP sau go-live.

Checklist Go-live ERP & Cutover

• Cutover scope/window và dependency đã khóa.
• Freeze strategy và exception rule đã thông báo.
• Final migration dùng pipeline đã rehearsal.
• Critical data reconciliation có business sign-off.
• Integration enable sequence và queue handling đã rõ.
• Critical user/role smoke test pass.
• Go/no-go criteria được review bằng evidence.
• Rollback trigger và decision authority đã xác định.
• War room, severity và escalation hoạt động.
• User communication và support channel sẵn sàng.
• Hypercare metric và owner đã được bàn giao.

Kết luận

Go-live ERP thành công không được chứng minh bằng việc hệ thống “bật lên”, mà bằng việc cutover hoàn tất trong phạm vi kiểm soát, dữ liệu và critical flow được xác minh, residual risk được business owner chấp nhận và support/hypercare sẵn sàng. Runbook, evidence và rollback logic phải được chuẩn bị trước ngày go-live chứ không được sáng tạo trong lúc sự cố xảy ra.

Sau cutover: chuyển từ hypercare sang operating support

Ngay khi hệ thống nhận giao dịch thật, dùng Hỗ trợ vận hành ERP sau go-live để thiết kế exit criteria cho hypercare, L1/L2/L3, incident/problem/change, knowledge transfer, monitoring và continuous improvement thay vì kéo dài project team như helpdesk không chính thức.

Khi cutover thuộc dự án Odoo

Bài này tiếp tục sở hữu intent Go-live ERP & Cutover vendor-neutral. Khi freeze, final migration, reconciliation, go/no-go và hypercare là workstream trong dự án Odoo, xem dịch vụ triển khai Odoo để đặt cutover vào cùng delivery plan và handover.