[{"data":1,"prerenderedAt":345},["ShallowReactive",2],{"blog-\u002Fblog\u002Foperational-readiness-and-acceptance":3,"blog-surround-\u002Fblog\u002Foperational-readiness-and-acceptance":322,"blog-related-\u002Fblog\u002Foperational-readiness-and-acceptance":332},{"id":4,"title":5,"audience":6,"body":10,"cluster":286,"contentRole":287,"conversionGoal":287,"date":288,"description":289,"draft":290,"extension":291,"factCheckedAt":287,"faq":292,"featured":290,"language":287,"meta":302,"navigation":70,"order":303,"originalAsset":287,"path":304,"pillar":305,"primaryKeyword":306,"relatedProject":287,"releaseScope":287,"reviewCycle":307,"reviewStatus":308,"reviewedBy":309,"searchIntent":310,"seo":311,"sources":287,"stem":312,"tags":313,"type":320,"updated":287,"__hash__":321},"blog\u002Fblog\u002Foperational-readiness-and-acceptance.md","Operational Readiness & Acceptance for Finance Systems",[7,8,9],"service-owner","finance-transformation-lead","delivery-manager",{"type":11,"value":12,"toc":276},"minimark",[13,21,26,43,50,54,57,154,160,164,171,177,181,203,207,239,243,250,253],[14,15,16,20],"p",{},[17,18,19],"strong",{},"A system can pass go-live and still not be ready to run — because \"does it work?\" and \"can we operate it?\" are different questions with different owners."," Projects pour effort into building and cutting over, then treat the moment of go-live as the finish line. It isn't. The finish line is when the run organisation can support the thing day after day — fix what breaks, monitor what matters, own each interface, close each period — without the project team in the room. Operational readiness is whether that's true; operational acceptance is the run team formally agreeing it is. Skip these and you get the classic post-go-live disaster: a \"successful\" launch, followed by an operations team discovering on day two that they own a system nobody prepared them to run.",[22,23,25],"h2",{"id":24},"go-live-readiness-and-operational-readiness-are-not-the-same-gate","Go-live readiness and operational readiness are not the same gate",[14,27,28,29,34,35,38,39,42],{},"This is the distinction that gets collapsed, and the collapse is expensive. ",[30,31,33],"a",{"href":32},"\u002Fblog\u002Fcutover-and-go-live-for-finance-systems","Cutover go\u002Fno-go"," asks: ",[17,36,37],{},"is it safe to switch on?"," — data migrated, critical processes tested, a fallback ready. Operational readiness asks a different question: ",[17,40,41],{},"can we live with this, day after day?"," — is there a support model, are there runbooks, is it monitored, does someone own each interface?",[14,44,45,46,49],{},"A project can pass the first gate and fail the second completely. The system is live, the data's clean, the payment run works — and there's no defined support path, no monitoring, no named owner for the bank interface that'll fail at the first month-end. Go-live succeeded; the operation is a disaster waiting for day two. ",[17,47,48],{},"Two questions, two gates, two owners"," — and operational acceptance belongs to the people who'll run it, not the project that built it.",[22,51,53],{"id":52},"the-operational-readiness-checklist","The operational readiness checklist",[14,55,56],{},"Readiness is provable, not assumable. Each item is evidenced — \"we have monitoring\" means alerts exist and someone receives them, not that monitoring is theoretically possible.",[58,59,62,77,91,100,109,118,127,141],"ul",{"className":60},[61],"contains-task-list",[63,64,67,72,73,76],"li",{"className":65},[66],"task-list-item",[68,69],"input",{"disabled":70,"type":71},true,"checkbox"," ",[17,74,75],{},"Support model defined"," — levels, priorities, and who owns what (including the interfaces, not just the app).",[63,78,80,72,82,85,86,90],{"className":79},[66],[68,81],{"disabled":70,"type":71},[17,83,84],{},"Runbooks written"," — routine operations ",[87,88,89],"em",{},"and"," the exception procedures (a failed interface, a stuck payment, a period that won't close).",[63,92,94,72,96,99],{"className":93},[66],[68,95],{"disabled":70,"type":71},[17,97,98],{},"Monitoring & alerting live"," — on the system and every integration, with a named recipient for each alert.",[63,101,103,72,105,108],{"className":102},[66],[68,104],{"disabled":70,"type":71},[17,106,107],{},"Owners named"," — for the system and each interface; \"the team owns it\" means no one does.",[63,110,112,72,114,117],{"className":111},[66],[68,113],{"disabled":70,"type":71},[17,115,116],{},"Knowledge transfer complete"," — the run team has been walked through it and can operate it, evidenced by them doing it, not attending a session.",[63,119,121,72,123,126],{"className":120},[66],[68,122],{"disabled":70,"type":71},[17,124,125],{},"Operational access & roles provisioned"," — the run team can actually do their job on day one.",[63,128,130,72,132,135,136,140],{"className":129},[66],[68,131],{"disabled":70,"type":71},[17,133,134],{},"Hypercare plan agreed"," — who's on standby, for how long, and how issues escalate during ",[30,137,139],{"href":138},"\u002Fblog\u002Fhypercare-and-post-go-live-stabilization","stabilisation",".",[63,142,144,72,146,149,150,153],{"className":143},[66],[68,145],{"disabled":70,"type":71},[17,147,148],{},"Acceptance criteria agreed"," — what \"operationally accepted\" means, defined ",[87,151,152],{},"before"," the run team is asked to sign.",[155,156,157],"pull-quote",{},[14,158,159],{},"\"We have monitoring\" is a claim; an alert firing to a named person who knows what to do is readiness. Evidence every item, because the ones taken on trust are exactly the ones that aren't real.",[22,161,163],{"id":162},"operational-acceptance-the-run-team-signs-not-the-project","Operational acceptance: the run team signs, not the project",[14,165,166,167,170],{},"The gate has to be owned by the people who inherit the system. Operational acceptance is the ",[17,168,169],{},"run organisation"," formally agreeing it can support and operate what's being handed over — against the criteria agreed up front. This matters because the incentives diverge at go-live: the project wants to declare success and roll off; operations wants to not be handed a liability. A real acceptance gate protects operations from inheriting a system it can't run, and protects the project from the accusation that it walked away — because the handover is a signed, criteria-based agreement, not an assumption.",[14,172,173,174,176],{},"The failure mode when this gate is missing: the project declares victory at go-live, the team disperses, and operations discovers the gaps alone, in production, with no one left who knows the design. Operational acceptance is the forcing function that makes the project close the gaps ",[87,175,152],{}," it leaves.",[22,178,180],{"id":179},"where-this-sits-relative-to-hypercare","Where this sits relative to hypercare",[14,182,183,184,186,187,190,191,194,195,198,199,202],{},"Operational readiness is what you prove ",[87,185,152],{}," go-live; ",[30,188,189],{"href":138},"hypercare"," is the staffed stabilisation period ",[87,192,193],{},"after"," it. They're complementary, not alternatives: readiness ensures the run team ",[87,196,197],{},"can"," operate the system; hypercare is the safety net while they get fluent and the last defects surface. A common mistake is using hypercare to ",[87,200,201],{},"substitute"," for readiness — \"we'll figure out support during hypercare\" — which just means the stabilisation period is spent building the operational basics that should have existed at go-live, while real incidents pile up unaddressed.",[22,204,206],{"id":205},"what-usually-goes-wrong","What usually goes wrong",[58,208,209,215,221,227,233],{},[63,210,211,214],{},[17,212,213],{},"Go-live treated as the finish."," The project declares success at switch-on and disperses, leaving operations to discover the gaps.",[63,216,217,220],{},[17,218,219],{},"No support model."," Nobody's defined who fixes what, so the first incident becomes a scramble to find an owner.",[63,222,223,226],{},[17,224,225],{},"Interfaces unowned and unmonitored."," The app is watched; the integrations that actually break aren't.",[63,228,229,232],{},[17,230,231],{},"Knowledge transfer as a slide deck."," A session held, not competence built — so the run team \"accepted\" a system they can't actually operate.",[63,234,235,238],{},[17,236,237],{},"Acceptance criteria invented at handover."," No agreed definition of ready, so acceptance is a rushed signature under go-live pressure, not a real gate.",[22,240,242],{"id":241},"what-i-would-decide","What I would decide",[14,244,245,246,249],{},"Separate the two gates explicitly and give operational acceptance to the run team, with criteria agreed at the ",[87,247,248],{},"start"," of the project, not the end. Evidence every readiness item — an alert that fires, a runbook that's been followed, a run-team member who's done the task — because the items taken on trust are the ones that fail on day two. And never let hypercare become a substitute for readiness: hypercare is the net for the last defects and the learning curve, not the time to build the support model you skipped. Going live is switching the system on; being ready is being able to run it after everyone who built it has gone home.",[251,252],"hr",{},[14,254,255],{},[87,256,257,258,262,263,266,267,270,271,275],{},"Part of the ",[30,259,261],{"href":260},"\u002Ftopics\u002Ffinance-systems-delivery","Finance Systems Delivery guide",". See also ",[30,264,265],{"href":32},"cutover & go-live for finance systems"," and ",[30,268,269],{"href":138},"hypercare and post-go-live stabilization",". The ",[30,272,274],{"href":273},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern, product decision or build lesson every two weeks.",{"title":277,"searchDepth":278,"depth":278,"links":279},"",2,[280,281,282,283,284,285],{"id":24,"depth":278,"text":25},{"id":52,"depth":278,"text":53},{"id":162,"depth":278,"text":163},{"id":179,"depth":278,"text":180},{"id":205,"depth":278,"text":206},{"id":241,"depth":278,"text":242},"execution",null,"2026-07-28","Passing go-live isn't the same as being ready to run. How to prove operational readiness — support, monitoring, runbooks, ownership — and get real operational acceptance before handover.",false,"md",[293,296,299],{"question":294,"answer":295},"What is operational readiness?","Operational readiness is whether the organisation can actually run and support a system once it's live — as distinct from whether the system passed its build and cutover. It covers the support model (who fixes what, at what priority), runbooks and operational procedures, monitoring and alerting, named owners for the system and its interfaces, knowledge transfer from the project to the run team, and access and roles for day-to-day operation. A system can pass every test and go live cleanly and still not be operationally ready — because nobody's defined who supports it, how it's monitored, or what to do when an interface fails at month-end.",{"question":297,"answer":298},"What is the difference between go-live and operational acceptance?","Go-live is the moment the system starts being used in production; operational acceptance is the run organisation formally agreeing it can support and operate it. They're different gates with different owners: go\u002Fno-go asks 'is it safe to switch on?'; operational acceptance asks 'can we live with this day after day?' A project can be desperate to go live and the operations team entirely unready to run it — no support model, no runbooks, no monitoring. Separating the two gates stops a project declaring victory at go-live and walking away, leaving operations to discover on day two that they own something they were never prepared for.",{"question":300,"answer":301},"What should an operational readiness checklist include?","The essentials: a defined support model (levels, priorities, who owns what), runbooks for routine and exception operations, monitoring and alerting on the system and its interfaces, named owners for the system and each integration, completed knowledge transfer from the project team to the run team, operational access and roles provisioned, and a hypercare plan for the stabilisation period after go-live. Each item should be evidenced, not assumed — 'we have monitoring' means the alerts exist and someone receives them, not that monitoring is theoretically possible. The checklist gates operational acceptance: unmet items are either fixed or explicitly accepted as risks before the run team signs.",{},8.5,"\u002Fblog\u002Foperational-readiness-and-acceptance","finance-systems-delivery","operational readiness and acceptance","annual","reviewed","Tan Gravam","informational",{"title":5,"description":289},"blog\u002Foperational-readiness-and-acceptance",[314,315,316,317,318,319,189],"finance-systems","delivery","operational-readiness","acceptance","support","handover","pattern","7_tqkHtyodg9a1PjE60K2U0raTH4GAgphCPmGrBcDo0",[323,328],{"title":324,"path":325,"stem":326,"type":327,"language":287,"draft":290,"children":-1},"One Exposure from Operations & FQM_FLOW Explained","\u002Fblog\u002Fone-exposure-from-operations-fqm-flow","blog\u002Fone-exposure-from-operations-fqm-flow","text",{"title":329,"path":330,"stem":331,"type":327,"language":287,"draft":290,"children":-1},"Payment Fraud Prevention and Controls in Treasury","\u002Fblog\u002Fpayment-fraud-prevention-in-treasury","blog\u002Fpayment-fraud-prevention-in-treasury",[333,337,341],{"path":334,"title":335,"description":336},"\u002Fblog\u002Ffit-gap-analysis-for-finance-systems","Fit-Gap Analysis for Finance Systems","A fit-gap analysis compares what a standard system does against what the business needs — fit, gap, or change the process. Avoiding the customization trap.",{"path":338,"title":339,"description":340},"\u002Fblog\u002Fsolution-design-and-blueprint-for-finance-systems","Solution Design and Blueprint for Finance Systems","How to turn agreed requirements into a signed solution design before build starts — and why skipping the blueprint is what quietly buys you months of rework.",{"path":342,"title":343,"description":344},"\u002Fblog\u002Fconfiguration-vs-customization-finance-systems","Configuration vs Customization in Finance Systems","Configuration fits your process using shipped settings; customization builds bespoke — a permanent liability paid at every upgrade.",1785237640047]