Employee onboarding as a ready-made computational model

Inflow: 260 hires a year, about 1.05 on a working day, with a day-to-day variation of 30 % and a peak factor of 1.4 on 6 % of days. Hiring arrives in waves, not at a takt.

The decisive finding. One case a day sounds like a process where nothing can get tight. The arithmetic disagrees: two and a half hours at 92 % effective time is 138 minutes, and at an average 110 minutes per provisioning that is 1.3 cases a day against 1.05 arriving. It fits, as long as a day's demand stays under that day's capacity. On 28 % of days it does not, because acceptances cluster.

The column adds up to 100 %: each run counts exactly one binding step, the one carrying the highest load that day. So "86 %" does not mean "86 % utilised". That figure sits next to it and happens to average 86 % too, but reaches 134 % on a busy day.

Capacity is not attendance. IT is there all day. Onboarding gets two and a half hours of it. Enter head count instead of hours and you compute a process that never gets tight, then wonder about the first day without a laptop.

1. Hires per working day. Last year's hires ÷ working days. HR has it; in a small organisation the count of new payroll numbers will do.
2. Peak factor. Hiring arrives in waves. An intake month, a quarter start, a new team. How many hires land on a single day in the busiest month compared with a normal one? A factor of 1.4 to 2 is common. Without it you are computing a process that is never under load, and you miss precisely the week in which it tears.
3. Hours IT gives onboarding. Not the size of the IT team. What matters is the share of the day somebody genuinely has for provisioning while operations run alongside, usually two to four hours.
4. The processing range for IT provisioning. Low end and high end, not the average. The difference between "standard workstation" and "special case with three line-of-business applications" is exactly that range, and it drives waiting time harder than the average does.
5. Induction plans per day. How many does a team lead write in a day when several are due? The template says 1.8, which makes this the second constraint, in 13 % of runs. Almost nobody measures it.
6. Fully loaded rates per role. Gross salary × 1.5 to 1.8, divided by roughly 1,500 productive hours a year. A €50,000 position therefore costs about €53 an hour, not the naive €24 from salary ÷ 2,080 hours.

Cross-check before you compute: count the hires of the last twelve weeks where something was missing on day one. If that share is close to the days over capacity the model reports, the model is usable.

What the template does not contain, and here it weighs most. Lead time is processing plus queueing, in working days. Calendar chains are not modelled: the signed contract coming back, the notebook's delivery time, the date of the safety briefing. In practice these often make up the larger part of onboarding time. If you have them, enter them as their own waiting steps; the model then computes the weeks the new colleague actually experiences, not just the work behind them.

Lever 1. More IT time for onboarding. One more hour a day, agreed rather than hoped for. The P90 of lead time falls from 9.6 to 2.7 working days, busy-day load from 134 % to 96 %. It costs a conversation, not a headcount, which makes it the best ratio in the table, as long as the hour is genuinely held free.

Lever 2. A standard image instead of hand-building. A prepared image for the three most common roles. Provisioning drops from 75–150 to 40–80 minutes. Effect: P90 from 9.6 to 1.0 working days, busy-day load from 134 % to 71 %, working time per hire from €243 to €188. The only lever that moves both time and money, because it attacks the duration of the work rather than the capacity around it.

Lever 3. A second person in IT. The most expensive lever, and weaker than lever 2. Compute it anyway and the reason shows: half an extra person doubles the capacity of a step whose work still takes 110 minutes. Shorter work beats more hands.

Lever 4. Speed up the induction plan. The null result. The induction plan is the second-tightest step at 87 % on a busy day and binds in 13 % of runs; nearly doubling its takt buys 0.2 days. Because while IT binds, not enough reaches the team lead. A lever on the second constraint is not half a win. It is none.

The other direction is the notable one: under three of the four levers the constraint moves to the induction plan, to a team lead nobody currently blames. That knock-on effect is the part a spreadsheet cannot show, because it computes each step on its own.

How 20,000 runs turn into a percentage per step is covered in Monte Carlo simulation for processes; why the spread between P50 and P90 is the real statement, in Understanding P10, P50 and P90.

After saving the baseline, changing one lever and running a second time, the comparison produces:

• Lead time before/after as P50 and P90. A commitment to the business is made against the P90, not against the median. Promising "everything is ready on day one" because the median says 1.3 days is promising something that breaks on every tenth hire.
• Utilisation per step on the busy day and the new constraint after the measure. In this model it moves to the induction plan under three of the four levers.
• Throughput as hires per week against hires arriving: 4.9 of 5.3 as shipped.
• Working-time cost per hire and per year, from volumes, durations and fully loaded rates. The template computes roughly €243 per hire, of which 477 hours a year fall on IT.
• The assumption list with every estimated input, stated. The sentence "hardware delivery time is not modelled" takes the sting out of the sharpest question before it is asked.

That is exported as two PDFs: a proposal for the decision maker and documentation for traceability, with your letterhead if you have set one.

One model, two questions. This page answers the arithmetic one: where the 86 % comes from, and where the constraint moves once you solve it. The other question (what would you recommend, and what does an unproductive first week cost) belongs to the method rather than the tool. It lives next door in the Flowrefy analysis archive, alongside the approach these templates came out of. One dataset, two questions, two audiences.

• Order handling runs from the order to the confirmation. The case with a shared role: two steps that look comfortable on their own are one person's afternoon.
• Quotation process is the case where lead time acts on revenue rather than on cost.
• Invoice approval is the volatility case: under capacity on average, over it at month end.
• Complaint handling puts the constraint outside the company, so the honest recommendation is not "automate".
• Employee onboarding is this page.
• IT ticket shows classic queueing behaviour with a branch: 65 % solved on the spot, 35 % escalated to second level.

Every template opens from the welcome window via Browse templates. The first time round it is worth opening one before starting your own model. Otherwise people build too finely.