Twenty-Seven Steps to Onboard an Employee
An insurer wants to improve onboarding of new employees, from offer accepted to the person being fully productive. The stream crosses HR, IT provisioning, facilities, security and the line manager: 27 steps, 11 handoffs and 4 approval gates, with a median lead time of 14 working days of which roughly 3 hours is hands-on work. About 22% of cases are reworked because the laptop specification or access request was wrong. No one owns the end-to-end stream and every team's own dashboard is green. Volume is around 40 hires a month, rising to 120 in September. Leadership has approved budget for an RPA tool and wants to 'automate the whole thing'.
1. Define how you would scope and conduct the value stream mapping exercise, and what you must capture to make it decision-useful.
Read the worked answer
Scope first, and scope tightly. Agree the trigger (offer accepted), the exit (fully productive, defined concretely with the line manager), the customer (the new hire and the hiring manager), and the unit of demand (one hire, with the September spike treated as a separate flow condition). Leaving the exit undefined is the most common way these exercises fail, because 'productive' can be stretched until the map shows no problem.
Map the flow as it really is, not as documented. Walk a small number of recent cases end to end with the people who do the work, including at least two of the reworked cases. For each step capture: who does it, trigger, system, processing time, waiting time, handoffs, approvals, rework loops, and where information is re-keyed.
What must be captured to support decisions.
- Flow efficiency: 3 hours of work inside 14 days of lead time is roughly 3% - the finding that reframes the problem.
- Queue locations and sizes, since queues, not work, consume the lead time.
- Rework sources: which upstream step causes the wrong laptop spec or access request, and how the 22% propagates.
- Approval gates: what each gate actually prevents, evidenced rather than assumed.
- Demand and variation: the September spike changes the constraint.
Judgement point. Present the map with the September case included. A solution that works at 40 hires a month may collapse at 120, and that is a decision the leadership needs to make now, not discover in September.
2. Leadership wants to buy RPA and automate the stream. Give your recommendation and the reasoning behind the sequence you propose.
Read the worked answer
Recommendation: do not automate the current stream. Simplify it first, then automate what survives.
Reasoning. Automating a process with 11 handoffs and 22% rework makes the defects faster and harder to see. Automating a step that should not exist locks in a design you will later have to unpick; automation also tends to embed the wrong laptop specification logic at machine speed. With flow efficiency around 3%, the largest available gain is in queues and handoffs, which cost nothing to remove and are not what RPA addresses.
Proposed sequence.
- Remove or reduce: collapse approval gates that no one can justify, eliminate duplicate data entry, give one role end-to-end ownership of the stream.
- Standardise and stabilise: agree a single definition of the standard hardware and access profile from the role, so the rework cause is designed out; measure whether rework falls before proceeding.
- Then automate the remaining high-volume, low-variation steps - plausibly access provisioning and status notification - where the step is stable and worth keeping.
Governance and measurement. Assign an end-to-end owner accountable for lead time and rework, and replace the five green team dashboards with a small set of stream measures: lead time, flow efficiency, rework rate, first-time-right provisioning, and the September peak throughput. Team-level measures stay, but they must not reward local speed that creates downstream rework.
Trade-off to state. Sequencing delays the visible 'automation' deliverable, so agree with leadership up front that the RPA budget is released only after rework and gates are addressed - otherwise the tool becomes the programme.