How do we actually capture all that knowledge embedded within the organisation?
Models for capturing expert knowledge in Dynamic and Static guides makes 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 through 15 years tells us that the businesses who can capture the knowledge embedded within their organisations owns the future …
So how do we actually capture all that knowledge embedded within the organisation? 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 customers 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, looks to the documentation as to what the error code means and how to fix it. If the technician was to follow the product documentation only and basically 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 in what the technician is assumed to do and what he actually does.
The standard documentation is often written before product launch and builds on assumptions about a product that is often new and 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 operates 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 posses the knowledge to help out in a given situation. Alternatively, he will end up calling HQ to get a hold on somebody in R&D. It’s a collective pool of relevant knowledge that anyone can use but it’s not formalised 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 cost is capable of capturing that very important know how and make 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 is usually what 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 analogue.
No computer application, no wizards or document templates just a plain old white board 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 need 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 fee us 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 effectively share knowledge -We have spoken to several organisations 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.
At the whiteboard people can focus on building a guide for a known issue and not be distracted by having to learn a new application at the same time. A full guide complete with causes, probabilities, actions and costs can be built on the whiteboard and afterwards it’s much easier to learn the knowledge management application as the knowledge on the whiteboard can be entered straight into the tool where 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 at 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 documentation department has no importance? Off 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 best troubleshoot a specific issue, just image the impact of a continuously updated knowledge base improved constantly by technicians giving their feedback containing their favourite solutions.
It’s a structured method of organising and circulating knowledge.