KAIZUNO^® strengthens organizations and their people from within.

How we went about it

We want to preserve our service know-how through the generational change and keep helping customers reliably. To do so, we look at our initiative from the perspective of our goals, our way of working and the people involved.

What the report is based on

The sample team consists of eight participants from service, assembly and management. The in-depth assessment shown covers ten practices with 29 strength and 44 potential mentions. In addition, there are ratings of our way of working, five values and five priorities, as well as three free-text comments shown.

How complete the picture is

All answers are voluntary. For the ten practices, 73 of 80 possible ratings are shown. For the five values, there are 33 of 40 possible ratings. Priorities were chosen 22 times in total; everyone could choose up to three. Whether all questionnaires were filled in completely cannot be read from this shortened example.

What we can conclude from it

The answers show how we experience our daily work and how we see our way of working. Where experiences differ, it is worth looking at concrete cases together. The “My view” under “What came out?” shows one personal view; the following view of our way of working combines the team’s individual ratings.

How the report is structured

The vision is followed by views of where we stand, strengths and selected analyses with recommendations. In the real system, the report is created with the support of AI. It is a basis for our conversation, not a judgment of individuals.

We want to become more independent, but the plan for it is not yet convincing.

We want to make new service colleagues more independent and keep helping our customers reliably. But how we manage knowledge transfer alongside ongoing jobs is not yet convincingly planned.

We contribute, but we need a more reliable framework.

We are willing to pass on our experience, and we support one another. In daily work, however, there is not enough time for knowledge transfer. And we still check too little whether others can then apply the knowledge on their own.

We handle service cases more reliably than we learn from them.

We handle service requests and fix faults reliably. What we learn along the way does not yet flow systematically into knowledge transfer and documentation. As a result, solved cases still help other colleagues too little with similar jobs.

We maintain good contacts, but we still ask too little.

We are in good contact with our service colleagues and the maintenance staff. But we still explore too little how their expectations are changing. After difficult jobs, we don’t regularly ask whether our support was enough. So we only learn some things when help is needed again.

We record how we recognize the causes of difficult faults.

In difficult service cases, we document the observations that led to the right diagnosis. That keeps it traceable how we narrowed down the cause.

We make customer-specific modifications traceable for later service jobs.

We record modifications so that service colleagues can understand the machine’s current state. That way, for the next job, they have the information on what was changed on the machine.

We work on difficult service cases together and support one another in troubleshooting.

Experienced and new service colleagues solve difficult cases together. When we get stuck on a fault, we receive the right support in time. That is how we bring our experience into our joint work.

We document solutions, but we rarely check yet whether others can apply them without asking.

We record how we solved difficult faults. We have hardly checked so far whether colleagues can manage with this documentation without asking. So it is not yet certain that the documentation can replace the personal help of the people who hold the knowledge today.

“With standard cases, the handover works. With rare faults, we still call the same experienced colleagues.”

From service

We record machine states, but we can’t yet reliably find suitable solutions by machine type and fault pattern.

We document what was changed on customer machines. But we can’t yet reliably find the suitable solutions by machine type and fault pattern. So in a service case we have to keep searching or ask someone who knows the machine.

We support our customers, but often only learn at the next call what is still missing.

After difficult service cases, we don’t yet regularly ask whether the instructions helped. We don’t yet systematically add to the documentation what remains unclear when they are used.

“We usually only hear whether our instructions helped the maintenance technician when they call again.”

From service coordination

Our willingness to help could hide how dependent we are on individuals.

With difficult faults, experienced colleagues help quickly. That keeps service running, and we experience the cooperation as a strength. Perhaps that is why we notice too little which knowledge others can’t yet apply on their own. With the generational change, this dependence could become noticeable.

“Well documented” could too quickly mean “knowledge secured” to us.

We record diagnostic paths and modifications. We have checked little so far whether others can find the right solution and apply it without asking. So we may be relying on documentation that only helps once its authors explain it.

A fixed fault could give us more confidence than it gives the maintenance staff.

We help get the machine running again. We often only find out when they call again whether the maintenance staff understood our instructions and can manage on their own next time. The case may already count as closed for us while uncertainty remains at the customer’s end.

1 · Clarify which service know-how must be secured first

We want to secure knowledge and make new colleagues more independent. Before we create more documentation, we should decide which faults they must be able to solve on their own and which knowledge is missing for that. What matters is where we still depend on individuals and when their experience will no longer be available. That way we focus the available time on the most important knowledge gaps.

2 · Make existing solutions findable and test how they are applied

We already document diagnostic paths and machine modifications. Even so, the same experts are still called on for rare faults. That is why we should clearly assign existing solutions to machine type and fault pattern and have them tested by knowledgeable colleagues who were not involved in the original case. Their questions show what we need to add. This brings us closer to the goal of independence than more documentation alone.

3 · Include the maintenance staff’s experience from the start

In the team, securing knowledge and usable documentation rank ahead of customer feedback. For our goal of reliable help, however, this feedback belongs in from the start. Otherwise we improve instructions without knowing enough about what is missing when they are used. After the first tested service cases, we should therefore discuss with the maintenance staff what helped and where they were still unsure.