How do we actually capture all that knowledge embedded within the organization?
Models for capturing expert knowledge in Dynamic and Static guides make a lot of sense, as we have previously discussed. We have also looked at what knowledge is and where it can be found, and our experience working with knowledge management for 20 years tells us that the businesses who can capture the knowledge embedded within their organizations own the future …
So how do we actually capture all that knowledge embedded within the organization? Well, as we previously established, we consider knowledge from different perspectives – expert knowledge about, for instance, error codes and problem areas and more static procedures for replacing components, assembly instructions, commissioning procedures, and so on.
On top of that, we consider both explicit knowledge like formal work procedures and diagnostic maps as well as tacit knowledge such as skills and expertise gained through years of experience, what most people call “know-how”.
It’s amazing that an employee in South Africa can report feedback from the top of a wind turbine that proves valuable to others worldwide a few days later
The shortcomings of formal procedures
The combination of tacit and explicit knowledge is extremely powerful for field service engineers and technicians when they go to the customer’s site – and it’s entirely necessary to use both. Typically an alarm is triggered in the contact center if a piece of equipment breaks down or starts performing inadequately. The contact center creates a work order, and a technician is dispatched to the customer site. With the help of error codes and machine state data, the technician diagnoses the problem and looks to the documentation as to what the error code means and how to fix it. If the technician were to follow the product documentation only and follow the map that is laid out in the documentation, he would most likely not be able to fix the problem as there is often a big difference between what the technician is assumed to do and what he actually does.
The standard documentation is often written before the product launch. It builds on assumptions about a product that is often new. Before operational data becomes available, so the documentation department draws on experience with similar products to create some form of manual that is, in many cases, both imprecise and inadequate for assisting technicians when troubleshooting complex problems. So, if the technician follows only the pre-delivered static documents, the problem will most likely not be solved. This is why what they actually did on-site is very different from the formal processes laid out by the documentation department.
A collective pool of relevant knowledge
The formal documented repair process often assumes that all deployed machines in the field operate as intended and predictably. However, complex machinery with multiple components and sub-systems doesn’t work as predicted in all scenarios. Each machine is deployed in a unique environment which can be cold, hot, humid, dusty, or otherwise. Furthermore, each machine will behave differently depending on the way it has been operated by the driver, the age, the service level, and many other factors and will have its own ‘soul’ if you will – you remember that old car you had back in the days that would only start if you treated it really nice and rubbed its back. The same goes for industrial equipment; each will have its own peculiarities that the field service technician knows or has experienced with other machines in similar condition – but it’s not in the official documentation and is therefore not generally available to the entire population of technicians.
Consequently, the technician ends up calling a colleague that he knows to possess the knowledge to help out in a given situation. Alternatively, he will end up calling HQ to get a hold of somebody in R&D. It’s a collective pool of relevant knowledge that anyone can use, but it’s not formalized, and it’s not easily accessible, especially for new employees.
A new way of thinking
The dynamic guide knowledge model using causes, probabilities, actions, and the cost is capable of capturing that very important know-how and making it available to everybody – but we need to extract the knowledge from the minds of the experts and populate the guides first, and this is where it takes a little getting used to for most people as they adapt to a different way of thinking about problem-solving.
Most of us are used to thinking in terms of steps performed in a certain order when fixing a problem, as this usually takes us to a solution. However, this technology is a new way of thinking that forces us to start at the end with the root cause – what was the actual cause of the issue? That cause must be captured and a corresponding corrective action created.
- Cause: “dirty spark plugs.”
- Action: “clean or replace spark plugs.”
- Cause: “battery depleted.”
- Action: “recharge the battery.”
At no point do we specify the actual troubleshooting sequence; we only provide the necessary information that lets the application perform the reasoning for us and always present the most efficient action.
Analog knowledge capture
The best way to learn this is completely analog.
No computer application, no wizards or document templates, just a plain old whiteboard and a few good guys ready to flesh out their know-how on a certain topic.
The first time around, it takes a while as everybody needs a few minutes to learn to think in causes and probabilities instead of sequences of steps of “how we usually do it.”
And exactly because we want to free ourselves from “how we do things around here,” we do not necessarily need the oldest, most skilled grand wizard of all products and problem scenarios. Those guys can be a little caught up in their ways to be able to share knowledge effectively -We have spoken to several organizations where they see that younger gifted technicians are the best at eliciting knowledge into tangible models as they are more tech-savvy and eager to help build and share knowledge that will help everybody get better.
On the whiteboard, people can focus on building a guide for a known issue and not be distracted by having to learn a new application simultaneously. A full guide complete with causes, probabilities, actions, and costs can be built on the whiteboard. Afterward, it’s much easier to learn the knowledge management application as the knowledge on the whiteboard can be entered straight into the tool where the focus now can be on learning the tool.
When we do this exercise with even the most skilled technicians, we always end up with four guys on the whiteboard discussing how to solve a problem, and interestingly enough, they have a hard time agreeing on the best way to solve the same issue in the same machine.
It is an advanced form of self-adjusting knowledge base that is automatically adapted based on feedback, solutions and experience from engineers, who experiences great value from using the systems
Does this mean that formal processes defined by the documentation department have no importance? Of course not! But it’s important to capture what really happens on-site and capture that – because if four experts cannot easily agree on how to troubleshoot a specific issue best, just imagine the impact of a continuously updated knowledge base constantly improved by technicians giving their feedback containing their favorite solutions.
It’s a structured method of organizing and circulating knowledge.
