Demo

Follow one change in plans to a coordinated response, then one improvement across the rollout.

In an illustrative shared services rollout, a supplier slips as leadership asks for an earlier launch. The Programme Sponsor decides the response. Then test a change to one recurring step across all 4 waves.

Watch ZedNerve in 30 seconds

Respond to a change in plans

One change in plans, from its impact to coordinated execution.

An organisation is moving HR, finance and procurement requests into a shared services centre, in 4 waves. The objective: cut service turnaround from 6.0 to 3.0 working days per request while keeping service quality and control. Wave 1, 1,200 staff at head office, is planned to go live in week 12.

Illustrative example. Fictional data. Weeks count working days from today, 5 to a week. Amounts in AED, for illustration only.

  1. See the execution gap

    Leadership wants go-live in week 9, not 12, and a supplier is 3 weeks late. Launched together, services slip to week 15; each week past plan defers AED 150,000 (AED 7.8M ÷ 52), counted once.

    Nerve Center

    Programme Shared services programme 4 waves · 4,800 staff

    Wave 1 · first user group

    1,200 staff at head office

    Target: 3.0 working days per request, from 6.0

    Forecast go-live: week 15 · approved plan: week 12

    Deferred savings AED 150,000 per week AED 7.8M agreed annual saving ÷ 52 programme figure, counted once

    Gap to the requested week 9: 6 weeks

    • 3 weeks launch requested before the approved week 12
    • 3 weeks supplier delay, passed through to go-live

    The finance test environment is 2 weeks late as well. It overlaps the supplier delay, so it adds no time.

    What affects the launch

    • Supplier readiness Procurement lead Finance module now due week 7, 3 weeks late
    • IT configuration IT lead Finance test environment now due week 6, 2 weeks late
    • Staff training People and training lead 15 working days, after testing

    Deferred savings count against the approved plan.

    Show the full screen Show less
  2. Understand the dependencies

    Dependencies come from the programme plan; the simulated analysis puts the critical path through the supplier. The two delays overlap, so go-live moves 3 weeks, not 5.

    Journey

    Shared services programme Wave 1 · first user group

    Dependencies between activities Recorded in the programme plan
    # Activity Owner Waits for Due, plan Due, now
    1 Finance module from the supplier Procurement lead — Week 4 Week 7 (moved)
    2 Finance test environment IT lead — Week 4 Week 6 (moved)
    3 HR and procurement configuration IT lead — Week 4 Week 4
    4 Finance configuration IT lead 1 and 2 Week 6 Week 9 (moved)
    5 User acceptance testing Operations lead 3 and 4 Week 8 Week 11 (moved)
    6 Finance controls sign-off Finance lead 5 Week 9 Week 12 (moved)
    7 Training, first user group People and training lead 5 Week 11 Week 14 (moved)
    8 Readiness review and go-live Operations lead 6 and 7 Week 12 Week 15 (moved)

    Effect on go-live Simulated

    • Critical path: supplier module → finance configuration → testing → training → go-live
    • The two delays overlap: go-live moves 3 weeks, not 5
    • Float: HR and procurement configuration 5 weeks, finance controls sign-off 2 weeks

    Decisions needed

    • Launch approach for wave 1

      Programme Sponsor Authorised person

    • Extra capacity hours

      Programme Sponsor Authorised person

    Show the full screen Show less
  3. Assess the response options

    The Programme Manager and team leads compare two responses: all services in week 15, or HR and procurement in week 9 and finance in week 12. Phasing defers no savings but needs 280 more hours.

    Response options

    Wave 1: two responses compared

    Dates: forecasts from completed steps in 2 earlier rollouts. Hours and service level: advisory estimates.

    Full launch Phased launch
    HR and procurement go-live Week 15 Week 9
    Finance go-live Week 15 Week 12
    After the requested week 9 6 weeks later On time; finance 3 weeks later
    Deferred savings, at AED 150,000 a week 3 weeks None
    Extra capacity hours 210 h 490 h
    Within service level, first 4 weeks (estimate) 80% 74%
    Schedule risk Every service waits for the supplier No float before week 9

    Trade-off The phased launch meets week 9 for three quarters of requests and defers no savings. In return it needs 280 more capacity hours, starts at a lower service level in the first 4 weeks (74% against 80%) and leaves no float before week 9.

    Comparing options is advisory work, supported by forecasts from history (built, pre-production). A comparison screen in the product is planned.

    Show the full screen Show less
  4. Make a governed decision

    An AI agent checked the supplier's evidence and recommended, and people reviewed. The Programme Sponsor decided, with one condition on the week-9 readiness review.

    Journey

    Decision chain: wave 1 launch approach

    Readiness check of the supplier's evidence 3 findings

    1. Interface test report covers 4 of 6 finance interfaces
    2. New delivery date, week 7, has no recovery plan attached
    3. Go-live support arrangements not provided
    1. Check and summary

      Readiness Agent AI agent

      3 findings in the supplier's evidence; recommends planning finance separately

    2. Recommendation

      Programme Manager Person

      Recommends the phased launch

    3. Review

      Finance lead · Operations lead Person

      Savings and controls; service level and capacity

    4. Decision

      Programme Sponsor Authorised person

      Chose the phased launch and approved 490 extra hours

      Condition If the week-9 readiness review is not passed, HR and procurement go live with finance in week 12.

    Four kinds of action

    • Routine action under an agreed rule The reminder to the supplier on day −5
    • Check, recommendation or draft The agent's check of the supplier's evidence
    • Decision by an authorised person Choosing the phased launch
    • Exception and escalation The escalation to the supplier: drafted by the agent, sent once the Procurement lead confirmed it
    Show the full screen Show less
  5. Coordinate and measure

    Every team gets a named owner and an agreed date, and the decision is recorded with its evidence. Each measure keeps a baseline, a target and a forecast; actual results come only after go-live.

    Nerve Center

    Wave 1, after the decision

    Owners and agreed dates

    1. Day 5 Recovery plan from the supplier Procurement lead
    2. Week 8 First user group trained on HR and procurement People and training lead
    3. Week 8 Go/no-go pack for the Programme Sponsor Programme Manager
    4. Week 9 HR and procurement go-live Operations lead
    5. Week 9 Finance configuration complete IT lead
    6. Week 11 Finance controls signed off Finance lead
    7. Week 12 Finance go-live Operations lead

    Reminders go out automatically under the agreed rules; an escalation is sent only once a person confirms it.

    Decision record

    Decided
    Programme Sponsor
    When
    Day 3, programme board
    Recommended
    Programme Manager
    Reviewed
    Finance lead and Operations lead
    Condition
    If the week-9 readiness review is not passed, HR and procurement go live with finance in week 12
    Evidence
    Readiness check (3 findings), dependency analysis, options comparison
    Show the full screen Show less
    Outcome measurement

    Wave 1 measures

    Measure Baseline Target Forecast Actual
    Turnaround, working days per request 6.0 3.0 3.5 Not yet measured
    Requests within service level (5 working days) 64% 90% 85% Not yet measured
    Requests resolved right first time 82% 95% 92% Not yet measured

    Actual results come only from real operation, measured 8 weeks after each go-live the same way as the baseline.

    Show the full screen Show less

Improve the operating model

One recurring step, tested across the rollout waves.

A separate question: not how to respond to one delay, but which steps recur in every wave and who should do them. In the simulation, the baseline comes from comparable checks in the organisation's earlier rollouts.

Illustrative example. Fictional data; the figures are simulated projections, not results.

  1. A step that recurs in every wave

    Before each wave, a Procurement analyst checks every supplier's readiness evidence by hand, and the check takes most of the time before approval. It is a check, not a decision: the Procurement lead approves.

    AI Operating Model

    Where the time goes: supplier readiness, per wave

    Baseline from 10 earlier checks

    Evidence received to readiness approval The check takes 6 of 7 working days

    Checking each supplier's readiness evidence, about 60 items

    • Procurement analyst Person

      6 working days, 30 h Finds 4 of 7 issues

    • Readiness Agent, in the simulation AI agent

      2 working days with review, 10 h Finds 6 of 7 issues

    A check, not a decision: the Procurement lead still approves each wave's supplier readiness.

  2. A specific change to roles

    From wave 2, the Readiness Agent runs the check and the analyst reviews what it flags, plus a sample. The Procurement lead still approves, and nothing changes until the Programme Sponsor decides.

    AI Operating Model

    What-if: supplier readiness, waves 2 to 4

    Baseline from 10 earlier checks

    Change being tested

    • Supplier readiness check, before each wave

      Now Procurement analyst Person

      Moves to Readiness Agent; the analyst reviews what it flags AI agent

    Stays with a person

    Supplier readiness approval

    Procurement lead Authorised person

    Applies from wave 2. Nothing changes in operation until the Programme Sponsor decides on the evidence.

  3. Forecast assumptions

    The projection states what it rests on: where each figure comes from, what a person still reviews, and what stays the same.

    AI Operating Model

    What-if: supplier readiness, waves 2 to 4

    Baseline from 10 earlier checks

    Assumptions behind the forecast

    • Baseline from 10 supplier readiness checks in 2 earlier rollouts
    • The agent's timing and flag rate come from the simulation's sample
    • About 60 evidence items and 7 issues per wave; half an hour for a person to review an item
    • A person reviews every flagged item and 1 in 8 passed items
    • The evidence list and the approval rules stay the same
    • The Procurement lead keeps every approval
  4. Projected benefits and trade-offs

    The projection shows the effect on days per wave, analyst hours and issues found before approval. The cost: items the agent flags that turn out fine, which a person must still clear.

    AI Operating Model

    What-if: supplier readiness, waves 2 to 4

    Baseline from 10 earlier checks
    Projected impact, per wave
    MeasureBaselineProjected
    Evidence received to approval 7 working days 3 working days 4 days, about 57% shorter
    Analyst hours 30 h 10 h
    Issues found before approval 4 of 7 6 of 7
    Hours freed, waves 2 to 4 No baseline 60 h
    Trade-off: flagged items that turn out fine No baseline 6 per wave
    Show the full screen Show less
  5. How actual results will be measured

    After wave 2, we measure each result the same way as the baseline and compare it with the target and the forecast. Actual results come only from real operation, so this example shows none.

    Outcome measurement

    The tested change, waves 2 to 4

    Measure Baseline Target Forecast Actual
    Evidence to approval, working days per wave 7 4 3 After wave 2
    Analyst hours per wave 30 h 15 h 10 h After wave 2
    Issues found before approval, per wave 4 of 7 6 of 7 6 of 7 After wave 2
    Show the full screen Show less
Illustrative simulation

Supporting simulation

How ZedNerve connects your departments.

Every department is a nerve, and at the end of each one are the people and AI agents doing the work. Their task updates flow into ZedNerve, which spots what is late or waiting for approval and sends that back to where it is needed.

Illustrative simulation. No real people, departments or projects.

  1. 1 Data flows in. Each department's people and AI agents send their task updates to the brain, in cyan.
  2. 2 ZedNerve spots the risk. It flags work that is overdue or waiting for approval, and sends that back, in violet.
  3. 3 People decide. Leads approve or nudge in the project status below. Agents never approve.
  • Data in
  • Insight out
  • Person
  • AI agent

Hover over or tap a person or an agent to see their task. Tap a department to send its data, or tap the brain to run a check.

Departments in the simulation · tap to switch one off

    Data in
    0
    Insights out
    0
    Active
    8/8

    Activity feed

      Project status

      What the simulation shows now.

      Every task held by a person or an AI agent in the simulation, rolled up by project, department and owner. It changes as the simulation runs.

        By project

        All tasks, this session and before

        Approvals and overdue work

        Open tasks over the last few minutes

        By department

        All tasks

        Agents and people

        Who holds which work

        Needs attention

        Overdue first, then work waiting for a person to approve

        Want to see it with your own process?

        In a conversation, we show the interactive demo and map your departments and approval rules onto ZedNerve. A pilot then runs on one real process for about 12 weeks, in an environment agreed with you. The interactive demo currently follows a property-development programme.