Where time is lost between delivery and start of work

The main mistake in reports is simple: taking the delivery date as the start date. In reality, there is almost always a gap between boxes arriving at the site and the moment an employee sits down and signs into the required systems. Sometimes it’s 1–2 days, sometimes a week.

The delay begins right after acceptance. Equipment needs to be unpacked, checked for completeness, entered into inventory, allocated to rooms or employees, imaged, configured with access, connected to the network and peripherals. Until that whole process is complete, the PCs are delivered, but the workstation is not ready.

Time is usually lost for everyday reasons: there’s no one to quickly receive and distribute equipment, accounts and access rights aren’t ready, there’s a queue for software installation and security configuration, monitors, cables, tokens or licenses are missing. Sometimes the employee is already at work, but their workstation still hasn’t been assembled and checked.

So delivered PCs and ready workstations are not the same thing. Delivery closes the logistics loop. A ready workstation closes the business task: the person can start work without waiting, workarounds, or manual fixes.

For employees this is very concrete. A new hire arrived on their first day but can’t log into email, CRM, or the accounting system. The team lead spends time on organizational issues instead of getting the team started. Formally the hardware is delivered, but the department is still waiting.

This is especially noticeable when opening an office, branch, training room or a new project team. If only 30 out of 50 seats are ready, the department won’t start at full capacity. On paper the project looks nearly complete, but people are idle in practice.

Management needs a single clear number in this situation: how much time passes from delivery to an actually ready workstation. This metric removes arguments between procurement, IT and the business. It shows not the fact of delivery, but the real time it takes to commission a batch for use.

How to define the metric without disputes

The problem is usually not the calculation itself, but that different teams measure different things. Procurement looks at the shipment date, warehouse at acceptance, IT at configuration, the business at the day the employee can actually work. If this isn’t agreed in advance, the number loses meaning.

For the metric, first define the start point. In most cases it’s more practical to use the moment when the batch is physically handed over to the customer and available for internal actions, rather than the manufacturer shipment date or the contract date. That way the metric doesn’t include stages that IT can no longer influence.

The finish point should also be practical. The criterion “PC powers on” is too weak. “Acceptance certificate signed” also doesn’t reflect reality. For the business, the finish is a ready workstation: device installed, connected, configured, the required accounts work, basic software is installed, and the employee can perform their tasks on day one.

To avoid mixing stages, it’s useful to separate three statuses:

batch acceptance — equipment received, checked and accepted into the warehouse or IT domain;
technical readiness — PC configured and matching the standard image;
ready workstation — device handed over to the user and usable for its intended purpose.

This is especially important when delivery is fast but configuration and issuance are delayed. For example, a batch arrived on Monday, certificates were signed on Tuesday, but employees only started working on Friday. If acceptance is counted as the finish, the report will look good even though the department lost three working days.

The rule should be documented and applied uniformly to all batches. You can’t count to the warehouse in one project and to the desk in another. Otherwise the numbers will look nice but will not be comparable.

In practice it’s convenient to agree on a short formula: start — the date and time of actual transfer of the batch to the customer; finish — the date and time when 90% of devices in the batch became ready workstations. This approach removes the influence of single problematic cases and shows the real speed of rollout.

If equipment is supplied with integration services, the rule remains the same. It doesn’t matter who did the configuration — the in-house IT team or an external partner. What matters is that the metric ends not at the boxes or certificates, but when people can actually start working.

What data to collect

To calculate the impact fairly, collect facts about time and volume rather than opinions. If there are discrepancies at this stage, the next argument will not be about business impact but about when the count even starts.

The minimum dataset is:

the date and exact time the batch was delivered to the site;
the date each workstation became ready, not just a single date for the whole batch;
the total number of PCs in the batch and the number of seats that actually started working;
who was waiting for the rollout — a new department, branch, project team or temporary group;
reasons for delays, separated into external and internal causes.

A common mistake is to record only one final date when “everything was completed.” That’s not enough for management. If 70 out of 100 PCs were ready on day two and the remaining 30 were delayed by access or network issues, that’s not the same as a single value “batch launched in 6 days.”

It’s important to agree in advance what counts as a ready workstation. Usually it’s not an unpacked PC, but a device that is connected, configured, has the correct image, access to corporate systems and can be handed to an employee without additional steps. Otherwise the commissioning speed will be overstated.

Also note who exactly depended on the delivery. If equipment is needed to open a branch or a new sales team, the value of speeding up is higher than for a routine scheduled hardware refresh. Then the metric ties not only to an IT operation but to people starting work.

It’s useful to record points of responsibility handover. If the supplier covers delivery, the integrator covers pre-configuration, and the internal IT covers connection and issuance, this should be visible in the data. Otherwise it’s hard to see where days are actually lost.

A simple example: a batch arrived on Monday at 10:00, 40 seats were ready by Wednesday, another 20 only by Friday. The delay for the last 20 was missing passes for contractors and unfinished network cabling. Presented this way, the manager immediately sees where the process failed and where it didn’t.

Which metrics to calculate first

To show impact quickly, you don’t need dozens of figures. Usually four metrics are enough.

First — average time from delivery to ready workstation. This is the basic metric. Count it in calendar or business days, but don’t mix approaches in one report.

Second — share of seats ready on time. A single average can hide problems. If 20 PCs were ready in 2 days and another 10 only after a week, the average looks acceptable, but the team’s start will still be delayed.

Third — lost working days. This is the clearest metric for the business. If 15 employees waited 3 working days for workstations, the company lost 45 working days of startup.

Fourth — the difference between the current and target time. Management needs to know not only that things improved but by how many days the delay was reduced.

A small example:

current preparation time — 6 working days;
target time — 3 working days;
deviation — 3 working days per seat;
for 40 seats this is already a significant idle time for the team.

If a department rolls out in waves, calculate each wave separately. That gives a more honest picture. For a management report this set is usually sufficient: average time, on-time rate, lost working days and gap to target.

How to calculate in practice

To avoid extra disputes, narrow the scope at first. Choose a clear period, e.g. a quarter, and one specific delivery: 50 PCs for a new department, 120 workstations for a branch, or the batch for a team move. Mixing batches with different conditions produces a number, but it won’t be useful.

Next, fix a single rule for start and finish. Start is best recorded when the batch is physically accepted on site. Finish is the status “ready workstation”: device configured, connected, checked, and the employee can start work.

A simple workflow to follow:

Choose the batch and the number of workstations in it.
Record the date and time of the start by the agreed rule.
For each PC, record the moment it became ready for use.
Calculate average and median commissioning times.
Compare results before and after changes.

The average shows the overall picture but is easily skewed by 2–3 problematic devices. That’s why it’s useful to also show the median. If the average is 2.8 days and the median is 1.9 days, it means most seats start quickly and the problem is in a few exceptions.

Business impact is easier to express in days than in percentages:

saved days = (old average time - new average time) × number of workstations

If a batch of 80 PCs used to be commissioned in 4 days and now in 2.5 days, the saving is 120 person-days of waiting. That sounds clearer to managers than “a 37.5% reduction.”

At the end add a short non-technical explanation of what changed and why the result is trustworthy. For example: "After standardizing the OS image, pre-labeling equipment and applying a clear acceptance rule, commissioning time fell from 4 to 2.5 days. This sped up preparation of 80 workstations and reduced the risk of a delayed team start."

How to link the metric to department launch

The metric is useful only when it shows not just IT speed but the impact on people starting work. So tie it to the date when the employee actually received a ready workstation and can perform tasks without waiting.

If a department is scheduled to start on the 1st, the main question is simple: how many people actually started work that day. Not all delays are equal. One missing PC for an accountant, receptionist or shift manager can affect the launch more than several seats for staff who can be connected later.

Management usually needs four numbers:

how many employees were planned to start;
how many of them received a ready workstation by the required date;
how many working days were lost due to delay;
by how many days the department or project phase was shifted.

This presentation translates the technical timeline into business language. The manager hears not "the batch was deployed 3 days late," but "12 people started later, 24 working days were lost, and the team training was delayed by 2 days."

It’s important to show that price alone isn’t enough. A cheaper option can worsen the overall result if installation, configuration, issuance and connection take longer. For the business, cost of purchase is not the only metric — how quickly each seat becomes operational matters too.

The simplest calculation: multiply the number of employees without ready PCs by the number of days of delay. Then compare the actual date when the department reached the minimal readiness for start with the planned launch date.

For example, a new 20-person team was to start on Monday. By that date 14 seats were ready; 6 employees received PCs only 3 working days later. That’s 18 lost working days. If all 20 are required for start, the launch shifts by 3 days. If 15 seats suffice, the department can start almost on time but with limited capacity.

In this form the metric becomes managerial. It shows how PC delays affect project timelines, team performance and the department’s actual readiness.

Simple example calculation for a new team

Imagine a new department of 40 employees. The batch of PCs arrived on time, so formally everything looked fine. But business care about when an employee actually has a ready workstation.

Initial data

The plan was:

delivery on Monday;
workstation preparation in 2 days;
full team operational on Wednesday.

In reality, the equipment arrived on time, but configuration took 6 days instead of 2. Typical causes: slow image deployment, manual software installation, delays with accounts or insufficient IT staff.

By Wednesday only 12 workstations were ready. The other 28 employees started work only the following Monday, 4 working days later than planned.

The clearest number for a report is lost person-days of startup:

28 employees × 4 days = 112 person-days of delay

If the company uses a benchmark of 35,000 KZT per working day for a new employee, the estimate is:

112 × 35,000 KZT = 3,920,000 KZT

This is not necessarily a direct accounting loss, but it’s a clear estimate of what the business missed due to the delayed department launch.

Now look at the scenario after improvements. Some preparation was done in advance: software lists agreed before delivery, responsible owners assigned, accounts prepared, and part of the configuration completed before issuing equipment.

After changes the picture became:

Metric	Before	After
Time from delivery to full readiness	6 days	3 days
Employees with delayed start	28	8
Average delay	4 days	1 day
Lost person-days	112	8
Monetary estimate at 35,000 KZT/day	3,920,000 KZT	280,000 KZT

Economic effect of the time reduction:

3,920,000 KZT - 280,000 KZT = 3,640,000 KZT

What the manager sees from this:

on-time delivery alone doesn’t guarantee a department start;
the main risk is often hidden in the days after delivery;
even a 3-day reduction matters for a 40-person team;
pre-configured infrastructure and clear launch organization materially reduce losses.

This example moves the discussion from "IT didn’t make it" to business language: how many days the team lost, when the department reached plan, and what effect faster commissioning brings.

Common mistakes in calculation

The most frequent mistake is taking the delivery date as the date when employees can already work. But that’s not the same. A batch may reach the warehouse on time, while real workstations become ready only after unpacking, configuration, software installation, network connection and access checks.

As a result the report looks better than reality. Management cares about when a new seat can be handed to an employee without caveats, not when the equipment crossed the gate.

Another typical mistake is looking only at the average. If 80% of workstations were ready in 2 days and the remaining 20% waited a week, the average hides the problem. For department launches these extreme cases often cause the schedule failure.

Distortion also appears during partial rollouts. For example, a 40-person department may be formally launched while only 28 seats were ready on day one. On paper the department is up, but it’s not operating at full capacity.

Another common issue is not counting repeated IT visits. On paper a workstation may be marked ready after the first setup, but later it turns out drivers are missing, access doesn’t work, or additional configuration is needed. In such cases count readiness only after mandatory tasks are actually completed.

Finally, don’t mix external and internal delays. If logistics delayed delivery by 3 days and internal preparation took another 4 days, these are distinct causes. Without separating them management won’t know whether time was lost at the supplier, warehouse, IT or within the department.

Before calculating, check four things:

which date is considered the start;
what is counted as the finish;
whether problematic cases are included and not just the average;
whether logistics and internal delays are separated.

If these rules aren’t fixed in advance, the report numbers will be neat but nearly useless for management decisions.

Short checklist before a meeting with management

Before the meeting remove all ambiguous points. Management doesn’t need a long technical breakdown. They need to quickly understand where time is lost, how much it costs the business and what will change if commissioning time is shortened.

The most common mistake is bringing numbers that can be interpreted in different ways. If there’s no single definition of a ready workstation, the conversation will immediately go into minutiae.

Before the meeting check the following:

a single clear definition of a ready workstation is agreed;
for each batch two key points are marked: actual arrival and actual readiness;
how many employees or seats were waiting for rollout is counted;
plan vs fact are expressed in days;
one simple table is prepared that can be understood without long explanations.

A good table usually has five columns: batch, delivery date, readiness date, number of workstations, deviation from plan. If space allows, add a column showing the impact on department launch — e.g. how many people started later.

Don’t overload the meeting with extra metrics. If one slide or one table doesn’t explain the situation, the material isn’t ready. The manager should be able to see the answers to three questions in a minute: how long they waited, why they waited, and what effect reducing the time will have.

What to do next

If the metric is clear, the next step is to turn it into an operational rule. Management doesn’t need measurement for its own sake. They need a clear target: how many days a typical batch should take to become ready workstations and what prevents meeting that target.

First, fix a target time for a standard delivery. Not "as fast as possible," but for example "up to 5 working days from acceptance to readiness of 80 workstations." Such a target immediately makes the discussion concrete.

Then assign a single data owner for all stages. That person doesn’t need to do all the work themselves. Their task is to collect facts at key points: delivery, acceptance, unpacking, configuration, installation, handover to user. When everyone keeps separate files and accounting rules, the metric quickly loses credibility.

Agree in advance the report format. IT usually looks at stages and causes of delay, while the business cares more about when the team can start, how many days were lost and how this affects the department launch. So keep two parts in one report: a short management summary and a simple breakdown by stages.

Minimum starting actions:

define the target time for a typical batch;
appoint a data owner for all stages;
approve a single report format for IT and management;
agree which deviations are critical and require separate analysis.

If the goal is not just to deliver devices but to commission them quickly, discuss this before procurement or project start. Agree in advance who is responsible for pre-configuration, the system image, delivery to sites, connection and post-installation support. These are the stages where days are most often lost.

For large organizations this approach fits well into an overall infrastructure plan. If the company is updating PCs, server infrastructure and branch support at the same time, the workstation readiness metric is best embedded in the overall rollout schedule. In such projects it’s useful to define the partner’s role in advance. For example, GSE.kz works as a Kazakhstan-based equipment manufacturer and system integrator, so delivery, pre-configuration and ongoing support can be pre-agreed in a single scope. This doesn’t replace internal metric control, but it noticeably reduces gaps between delivery and actual workstation commissioning.

A good outcome looks simple: you don’t have to explain why equipment has long been delivered but people are still waiting. You show the timeline, risks and the cost of delays to the business in advance.