Lean Repair Shop Workflow: How a Technical Service Department Saved About €1 Million in Two Years

So, how a technical service department across three locations improved its repair flow, quality and productivity before investing in more technology?

A repair operation does not become efficient because someone buys a new system; it becomes efficient when people can see the work, understand what is holding it up and move it through the business without unnecessary waiting.

Around 2014, I was asked to conduct a independent process audit – at that time, the term Lean Management Audit was popular – in the technical service department of a retail and wholesale group in Central Europe.

The department handled warranty and after-warranty repairs for internal and external clients.

It operated across three locations and had more than twenty technicians and engineers.

The operation had capable people, but in my opinion the workflow made their work harder than it needed to be… back then I was still a young consultant and I thought this was the perfect sales pitch to sell more of my services… aaand it worked! BTW, this gave me faith in the openness and sincerity of business relationships for the years to come.

Anyway, jobs passed through several stages, parts were not always where they were needed, and technicians used sticky notes to keep track of work in progress.

Those notes were not exactly a reliable information system as you can imagine… they fell off benches, got buried under parts, collected grease or vanished without leaving an audit trail.

So, yes, the workshop had many mysteries, but where a repair job was supposed to be was one of the more persistent ones.

Over the following two years, we changed how work was coordinated, reorganised the physical repair flow into dedicated stations and introduced barcode-based inventory processes.

We started with the information and the process, not with a major software purchase.

The department’s recorded results included a threefold increase in productivity and owners estimated savings of approximately €1 million over two years.

The other reported indicators included fewer quality issues, less rework, shorter waits for parts and a substantial reduction in returns.

From the comfortable armchair of my own long-term perspective this was an operational improvement programme, not a technology project dressed up as one.

The operation: three locations, more than twenty technicians

The technical service department repaired products for two main client groups: customers and businesses within the retail network and external B2B clients; it handled both warranty and after-warranty work.

A repair could pass through five stages or more, depending on the item.

That meant the department needed a reliable way to understand:

• what had arrived;

• what needed to be checked;

• which repair stage it had reached;

• whether a part was required;

• what was waiting for attention;

• and whether the repair had passed its final check.

In practice, much of that information lived on sticky notes and in people’s heads.

The benches were crowded, parts accumulated around the work areas, and there was no consistent, visible way to coordinate the flow.

A technician might postpone a job until there were enough notes to make a batch worthwhile, from an individual technician’s perspective, that could feel practical but across the whole department, it made waiting and work-in-progress harder to control.

The physical working environment also needed attention. At one location, ventilation was inadequate and soldering fumes and smoke from heat guns were a problem.

That was a health and safety issue, not a Lean Management exercise, it needed to be addressed as a priority in its own right… so the first serious conversation with the owners, in my capacity as a newly appointed manager, took place in a rather quiet atmosphere.

My showing up at the office wearing a gas mask might have contributed to this.

Start where the work happens

I began by walking the benches – the famous Gemba Walk – and observing how repairs actually moved through the department.

There is a difference between a process as described in a meeting and a process as performed on a busy workbench.

The first is usually tidy.

The second tends to contain workarounds, waiting, missing parts and several unofficial ways of deciding what happens next.

The conversations were technical, I was coming from outside and from larger-business environment, while some of the technicians had been doing this work longer than I had been living.

There was no point arriving with a presentation and explaining to experienced technicians how to repair things.

I needed to understand what they were dealing with and where the process was getting in their way.

The walk-through made the main problems visible: work status was difficult to see, coordination depended too heavily on informal communication, parts availability interrupted repairs, and the physical layout did not consistently support the sequence of work.

The first task was therefore not to automate the workshop, it was to make the work visible and establish a process people could actually use.

First change: make the work visible without buying another system

The technicians already had screens at their benches, mainly for viewing schematics and technical information.

Buying more screens to solve an information problem would have been an interesting way to create another problem, and that is why we reused the existing equipment to display repair status, improving resource utilisation and eliminating the waste associated with paper-based tracking.

In Lean terms, this was waste prevention and resource optimisation through Muda (waste elimination), supported by the broader Toyota Production System principles of eliminating Muda, Mura (unevenness) and Muri (overburden).

The first version was deliberately simple, we used an existing spreadsheet, a few macros and the screens already available.

The objective was not to introduce a sophisticated production-management platform, it was to give technicians a clearer view of what needed attention and reduce the dependence on pieces of paper moving around the workshop.

I remembered seeing the large screens at the last location and realised I could give them another job.

By then, the guys knew I was probably up to something.

Let’s just say we had a few discussions over a beer or two before everyone agreed on what those screens should be doing.

They were already part of the working environment, although their usual duties included broadcasting football or Formula 1.

I decided they deserved another responsibility: showing the team what needed to be done, where each repair stood and what was holding it up… at least during commercial breaks.

We introduced the changes iteratively, we tried an approach, observed how it worked in practice, checked the available figures and adjusted it.. I used PDCA or Deming cycle before it was fancy.

The important thing was to improve the actual workflow, not to create a process that looked impressive in a diagram but became another inconvenience at the bench.

Then redesign the physical flow

Once work status was easier to follow, we reorganised the repair operation around dedicated stations.

The revised arrangement included:

1. Initial inspection – a visual and external check to identify obvious issues early.

2. Electronic and mechanical inspection – three stations for more detailed diagnosis.

3. Donor disassembly and parts magazine – a dedicated area for recovering and organising usable electronic and mechanical parts.

4. Soldering – a station for work requiring soldering and related repairs.

5. Final inspection and detailing– a final check before the item returned to the customer.

The intention was to make the sequence of work clearer and reduce unnecessary movement and waiting.

Initial checks could identify obvious problems before an item moved further into the process.

Inspection and repair work had defined places.

Recovered parts were organised so that technicians were less likely to lose time looking for something that could be reused.

Completed work went through a final check.

In factory terminology, the arrangement resembled a small production cell.

The products were being repaired rather than manufactured, but the operational principle was similar: organise the work around a repeatable flow instead of allowing every job to become its own improvised journey.

The reported waiting time for parts fell from around three working days to less than one, that was one of the practical benefits of making parts and work status easier to manage.

Automate the administrative friction, not the repair itself

Automation came after the process changes.

We introduced barcodes for items including parts and tools, improving the way information was captured and inventory was managed.

The aim was to reduce manual data handling and make inventory management less labour-intensive.

The mandatory annual inventory used to take about a week; a week of counting, recounting, arguments, swearing and people gradually losing their patience with one another.

After the change, it took two afternoons of almost continuous barcode beeping; not exactly entertainment, but a considerable improvement on the previous arrangement.

Oh… and we did not automate the soldering station, at the time, around 2014, that was not a practical or sensible target for this operation.

The work could be improved without trying to automate every physical task.

In my opinion that distinction matters.

Automation is not automatically valuable just because a task is repetitive, the question is whether automating it improves the operation enough to justify the cost, complexity and maintenance.

In this case, the data flow and inventory processes were better candidates than the repair work itself.

The sequence was straightforward:

• understand the work;

• make its status visible;

• organise the flow;

• improve the handling of parts and inventory;

• then automate suitable information and administrative tasks.

The technology supported the process, but it did not define it.

Results: what changed over two years

The figures below are the results recorded by the team during the period, they compare departmental KPIs and operational records before and after the changes.

The operational changes were accompanied by improvements in the department’s recorded quality, productivity and customer indicators.

The most visible practical changes included shorter waits for parts, less soldering rework and a much shorter annual inventory.

The approximately €1 million figure is the owners estimate of the savings achieved over the two-year period.

The operational figures came from departmental logs, fault and complaint records, and customer surveys that I collected at the time.

The changes were introduced as a programme rather than as isolated experiments.

The information flow, station layout, parts handling, barcode processes and logging all changed during the period.

So I believe you will understand why I cannot reliably attribute a specific share of the overall result to any single intervention.

The results should therefore be read as the reported outcome of the combined operational changes I introduced over 2 years.

What I would do differently

I was also trying to help other departments across the group. Looking back, I would have concentrated more of my time on the technical service operation first.

The workshop had enough problems to keep me busy, every hour spent elsewhere was an hour not spent understanding the repair flow, supporting the technicians or checking whether the changes were working as intended.

At the time, however, I did not know in which direction or how quickly the market for shared services and business process outsourcing, which was only just beginning to grow, would evolve….

That is an easy lesson to state afterwards.

In a real management role, requests come from all directions and everything appears urgent to the person asking.

The trick is to distinguish between being helpful everywhere and actually moving the most important problem.

What the experience taught me

1. Observe the operation before redesigning it. A process map created in a meeting is a hypothesis. The workbench tells you whether it is true.

2. Make work visible before adding complexity. The first improvement used screens and equipment the department already had. Better coordination did not require a new platform.

3. Fix the flow before automating it. Automating a confusing process usually makes the confusion faster and more expensive. Establish a workable process first.

4. Treat inventory and information as part of operations. Parts availability, work status and accurate records directly affect how much time technicians spend repairing products rather than looking for information or materials.

5. Measure what changes. Fault logs, complaint records and customer surveys gave us a basis for comparing performance. Without records, claims about quality and productivity would have been little more than workshop folklore.

The wider lesson: technology should follow the operating model

This project took place around 2014, long before today’s enthusiasm for AI and industrial automation. The underlying management question has not changed.

Before introducing another system, sensor, robot or AI tool, understand how work moves through the business. Find the waiting, rework, unnecessary handling and information gaps. Decide which problems are worth solving. Then choose technology that supports the improved process.

Sometimes the right answer is a new platform. Sometimes it is a barcode. Sometimes it is a spreadsheet and a screen that used to show Formula 1.

The point is not to avoid technology. It is to avoid buying technology before understanding what the business needs it to do.

I use the same principle in my work with owners, management teams and boards: understand the operation, its constraints and its economics before recommending the next system or automation project.