In the world of knowledge management for technical troubleshooting of advanced products, the Acquisition phase is where it all begins. From tapping into internal expertise to harnessing external sources, both explicit and tacit, this phase identifies what knowledge is needed to tackle challenges and drive progress. This first phase of the Dezide Knowledge Value Chain is about identifying, collecting, and refining the knowledge to make it usable.
The Knowledge Value Chain
The KVC is a practical roadmap for service organizations looking to harness the power of knowledge to improve their field service efficiency and drive value creation. The three major stages of the KVC – acquisition, validation, and sharing – are essential for building and maintaining a technical troubleshooting knowledge base effectively. In our last post, we described the KVC on a general level, and this time, we are diving into the first stage, Acquisition.
Knowledge acquisition
The acquisition of knowledge is the first step of the Knowledge Value Chain. This involves identifying and locating data, information, and knowledge from various sources of tacit and explicit knowledge. After collecting and capturing the raw knowledge material, it must be transformed and matured into dynamic troubleshooting guides, which involve analyzing the data, extracting knowledge from it, and turning it into causes, actions, questions, probabilities, and costs.
The Acquisition phase comprises three major components in a systematic process each with a set of operational activities that ensures our goals for the knowledge base are reached.
-
Stage input:
-
In this stage, the input consists of raw troubleshooting knowledge obtained from unstructured and structured data sources. This diverse range of information is the foundation for the knowledge-building process.
-
-
Stage output:
-
On the other end of the spectrum, the output is dynamic troubleshooting knowledge matured into guides that are not only informative but also actionable.
-
Identification
The first step in Acquisition is “Identification,” where we determine where explicit and tacit service knowledge lives in the service organization. We map out how to get that knowledge and who is responsible for it. We need to source knowledge from diverse sources as the heart of Knowledge Acquisition is identifying and locating knowledge. These sources range from documents, notes, and technical manuals to interviews, observations, and expert interactions. Both explicit knowledge that can be readily articulated and tacit knowledge residing in the minds of experienced individuals are essential components of this knowledge pool.
Identify Explicit and Tacit Knowledge
For most service organizations, you’ll find that the essential knowledge data must be collected from a diverse range of sources. Information and knowledge are scattered throughout endless product manuals, electrical diagrams, printouts and binders, flow charts, notes, and even in employees’ minds. Often, you will see documentation and expert advice captured in everything from old IT systems, SAP documents, Sharepoint, and ticket system knowledge base articles to “homegrown” knowledge bases built by former Employees – often grossly outdated and not very informative. You will see “underground” efforts to collect simple static documents and spreadsheets containing information related to best practices and random solution descriptions for common errors across shared network drives. You might even see FAQ systems (often in the form of hand-coded HTML files) internally built by employees who need a central place to get help and are forced to start building something on their own that colleagues can share. These systems are rarely maintained, as they are time-consuming to update. There is no real ownership, procedure, feedback cycle, or sense of community to ensure continuous growth in the knowledge base. Solutions like these never really gain traction in environments already using many different software systems, and adopting a new system is a tough challenge.
On top of that, we consider explicit knowledge, as described above, and tacit knowledge, such as skills and expertise gained through years of experience, what most people call “know-how.” We need to capture both to build the best possible knowledge base that will shorten training time for new technicians, help new or less skilled technicians troubleshoot issues faster than they do today, and instantly transfer knowledge to the entire workforce, allowing all technicians troubleshoot multiple issues as an expert, even outside of their skill set and work area
Operational Activities in Identification
The Identification component lists operational activities necessary to drive the entire Acquisition stage. Some of these include:
-
Product selection
-
Troubleshooting guide list and priority
-
Knowledge graph and semantics
-
Defining findability
-
etc.
Let’s look at the first one:
Product Selection
Determining where to start building the knowledge base and who should do it can be difficult. Sometimes, the available people dictate what part of the knowledge base should be built first, and sometimes, it is the other way around – the parts that need to be built first dictate who needs to build it.
But how do you choose where to start?
Going through the exercises in the Acquisition component will enable you to assign your team members to the critical troubleshooting guides in their chronological order and assign the time and resources needed to build them along with a deadline to provide a time scope. This will provide a complete overview of the employee and time resources involved in building your knowledge base’s first part for roll-out.
So, how do I select the first product to work on? You should consider, amongst other factors, selecting a product:
-
That matches your business case objectives and goals for implementing the troubleshooting solution.
-
That makes sense for the end users.
-
Where the largest volumes are.
-
That is used a lot.
-
That will generate the fastest ROI when optimizing service.
Based on our experience, it is compelling to go for one of the most popular products and the issues you are seeing the most in the field for this product, as this is where the guides would be used the most times. Likewise, it is enticing to select a brand new product as it would be good to have a new modern guided step-by-step troubleshooting solution for this new product when it arrives in the market. Another compelling approach is to build a list of the 50 most occurring issues across the entire product fleet as we definitely would like to reduce the number of these and the time we spend fixing them.
However, in our experience, these might not be the best approaches.
The most popular product might not be the one that sees the biggest volume of issues or the most complex issues. A brand-new product doesn’t have any good troubleshooting information, as documentation for new products often comes from the engineering department and could be based on previous generations of the product. Finally, the list of the most occurring faults might not be the best choice either, as that list doesn’t tell us if the issues are 5-minute fixes or long-running, complex tasks.
Instead, consider aspects such as:
-
Top 50 most time-consuming errors across products and derive the important products.
-
Top 10 most time-consuming errors for a product with a large distribution.
-
The most used error codes by new/junior/inexperienced technicians as these are 80% of the workforce and in fast rotation.
Also, look into the data from the 1-week PoC project report and end-user stakeholder feedback on inquired guides.
Generally, we recommend that you select products that see common issues that are not easily resolvable. Issues that require a lot of calls to HQ/gurus, as this will ensure that the field service technicians get a good experience from the first uses of the new tool.
This should help you narrow down the potential products or product lines that are a good fit for the initial knowledge base.
Collection
The “Collection” step in the Acquisition phase of the Knowledge Value Chain is a crucial starting point in the process of maximizing the value of knowledge assets in an organization. As described above, knowledge is collected from a diverse range of sources. These can include internal sources like company databases, employee insights, and historical records. This step involves systematically gathering knowledge from those various sources to amass a comprehensive set of data, information, and insights for further refinement and use.
Operational Activities in Collection
The Collection component lists operational activities necessary such as:
-
Training in back-office procedures
-
Defining how to collect the knowledge in a usable form
-
etc.
Let’s take a look at how we are going to collect knowledge because that is a big topic in and by itself:
Defining how to collect the knowledge in a usable form
Collecting knowledge must be a systematic process where identified knowledge is gathered, compiled, and illuminated. This phase is important in knowledge management as it ensures that valuable insights and expertise are not only recognized but also captured in a manner that facilitates easy access and reuse within your organization.
One of the pivotal methods for eliciting knowledge during the Collection phase is through Communities of Practice (CoPs). CoPs are groups of people who share a common interest, profession, or passion and come together to fulfill both individual and group goals. They are inherently knowledge-rich environments where members exchange information, insights, and best practices continuously. The role of CoPs in troubleshooting knowledge elicitation during the collection phase can be understood through several key activities that we have seen working for our customers at Dezide. Over the years, we have seen our customers establish CoPs in many different forms depending on the unique properties of their service organization. We have captured the various methods we have seen working in the KVC for others to apply to their organization. Some of the common concepts that we have seen are:
- Shared Experiences and Stories:
- Within CoPs, members frequently share their experiences and stories related to the problem or error code being discussed. This narrative approach is a powerful means of transferring tacit knowledge, which is often difficult to capture through traditional documentation methods.
- Collaborative Problem-Solving Mapping:
- CoPs often engage in joint problem-solving mapping activities, where members bring diverse perspectives and expertise to the table, and they map out the key elements of solving the problems being modeled. They come prepared with cue cards describing the problem at hand on a high level and discuss it with the group accordingly. This collaborative approach fosters innovative solutions and facilitates the conversion of tacit-to-explicit knowledge, making it easier to collect and document.
- Discussions and Forums:
- Many CoPs utilize online forums or regular meetings to discuss new developments, challenges, and opportunities within their domain. These interactions are rich sources of both tacit and explicit knowledge, providing a wealth of information that can be collected and archived.
- Best Practices and Lessons Learned:
- CoPs are ideal environments for identifying and disseminating best practices and lessons learned. By systematically collecting these insights, organizations can prevent reinvention of the wheel and promote more efficient and effective practices.
- Mentoring and Coaching:
- While not a formalized part of the process, we often see the more experienced members within CoPs take on mentoring roles, helping to guide and develop less experienced members. The CoPs are often comprised of several stakeholders, and this is a form of implicit mentoring, which, over time, aligns the whole group and fosters efficiency in the process. This interaction is a direct way of transferring knowledge and skills, contributing significantly to the knowledge-collection process.
To effectively leverage CoPs for knowledge elicitation during the Collection phase, organizations should foster an environment that encourages active participation and open sharing. This can be achieved through providing platforms for interaction and ensuring that the knowledge collected is accessible and utilized by the troubleshooting guide builders afterward, as these may or may not be a part of the CoP. This could involve choosing between digital platforms, physical documents, or hybrid systems and ensuring that the chosen format aligns with the organization’s capabilities and the nature of the collected knowledge. Setting clear criteria for what information is pertinent and filtering out irrelevant data is important to managing the scope of knowledge. By doing so, CoPs can become a cornerstone of an organization’s troubleshooting knowledge management strategy, significantly enriching the knowledge base and fostering a continuous learning and improvement culture.
Example using the PDCA (Plan Do Check Act) method
This is a real-life example from a Dezide customer who implemented a CoP around the troubleshooting knowledge base using the PDCA method. The PDCA (Plan-Do-Check-Act) cycle is a four-step management method used to control and continuously improve processes and products. It is particularly effective in the context of CoPs focused on technical troubleshooting, where the goal is to refine and enhance a knowledge base over time. By integrating the PDCA cycle into the CoP process, the community can systematically improve its technical troubleshooting knowledge base through iterative learning and adaptation.
-
Company type: Manufacturer of heavy equipment for material handlers and cranes
-
Location: Germany
-
Technicians in the field: approx. 500
-
Back-office troubleshooting guide creators: 1
-
Members of the CoP: 30
-
Stakeholder groups:
-
Research & Development
-
Test & Research
-
Field service operational centers
-
Tech docs
- etc.
-
-
-
CoP methodology: Adopted the PDCA method, modified to fit the customer’s organizational setup.
-
CoP meeting frequency: weekly
-
Setup: Virtual meetings using OneNote for note-taking, audio, and video captures, sketching, etc.
-
Assets: Q-cards
Every week, the community of approximately 30 people meets (every Monday) in a virtual setup using OneNote. Here, participants can directly type in feedback notes, add recorded audio, and/or sketch and write ideas in a collective environment. Participants from various backgrounds and stakeholder groups join in on the weekly meeting.
This setup allows the different teams to provide, listen to, and give feedback, making them all more knowledgeable in the long run, including the one person responsible for creating the troubleshooting guides in the Dezide administration tool. Another benefit is that the setup not only facilitates knowledge capture but also allows for knowledge coordination across business units. Involving different business units forces the group to consider the company ontology to ensure everything is captured using the same language, terminology, and meaning and aligned with the organization’s core semantics, objectives, and values.
During the weekly sessions, causes and actions are directly shared collectively for the back-office team to capture them and document them in the missing troubleshooting guides that need to be created or modified. With all of this being done in OneNote, there is also the advantage that the knowledge being stored in its raw format can easily be located and reverted upon when needed. The back-office team comes well prepared for the weekly meetings, equipped with what they term Q-cards. This allows them to have questions and queries prepared upfront for third-level support topics, which can be extremely hard to locate otherwise.
In summary, the community meetings allow for challenges to be presented openly by any given person, for this then to be highlighted where others having similar challenges can relate. It is a successful method of how a Dezide customer captures knowledge via a community setting. New knowledge is being created through social interaction and interpersonal connections.
By repeatedly cycling through the PDCA stages, a CoP can foster a culture of continuous improvement, ensuring that the technical troubleshooting knowledge base remains a dynamic, evolving resource that effectively meets the needs of its users. This iterative process enhances the knowledge base’s quality and engages CoP members, promoting a sense of ownership and collaboration within the community.
—
As organizations navigate the Collection phase, the focus should be on creating a structured yet flexible process that accommodates the dynamic nature of troubleshooting knowledge. The ultimate goal is to cultivate a repository of knowledge that is not only comprehensive and reliable but also readily available and applicable across various organizational contexts. This step is crucial for empowering the subsequent Transformation phase, driving field service efficiency, fostering innovation, and ultimately contributing to sustained value creation within the service organization.
Transformation
The “Transformation” step in the Knowledge Value Chain is a component where the collected knowledge is converted into a practical and usable form in the troubleshooting guides. This step follows the initial Collection step and is essential for making the knowledge actionable and relevant.
The Transformation step’s primary goal is to take the raw, collected knowledge, mature it, and transform it into a structured, easily digestible, and practical form. Here, the focus is on creating troubleshooting guides that provide clear, step-by-step solutions to problems.
Experts can provide nuanced understanding and practical tips that enrich the guides’ content. Challenges in this step include ensuring the accuracy and relevance of the guides, making them user-friendly, and keeping them up to date with changing knowledge and practices. Maintaining a balance between detail and simplicity is crucial to cater to a diverse user base.
The Transformation step is pivotal as it turns theoretical or raw knowledge into practical guides. Without this step, the knowledge collected remains underutilized and fails to contribute effectively to problem-solving and efficiency improvements. By diligently transforming collected knowledge into troubleshooting guides, organizations can ensure that their knowledge assets are stored and actively used to drive solutions, improve processes, and add value.
Operational Activities in Transformation
This phase begins with a thorough analysis of the collected knowledge. It involves identifying key themes, patterns, and insights critical for problem-solving. The core operational activity in this phase is the creation of troubleshooting guides. The guides are designed to be practical for problem resolution, offering clear instructions and solutions based on the analyzed knowledge. They should be user-friendly, easy to understand, and tailored to the needs of those who will use them.
Collaboration with subject matter experts and stakeholders is vital in this step. Their insights ensure that the guides are accurate, comprehensive, and applicable.
Maturing Collected Data Into Troubleshooting Guides
Dezide has its concept based on Bayesian networks for capturing expert knowledge. The concept builds on three central elements for building intelligent troubleshooting guides. Basically, we describe a problem and its solution via three components: Causes of the problem, Observations (questions) that may narrow down the potential causes, and repair actions (solutions) that we may perform to fix the problem:
-
Causes
-
The root cause is a specific item known to be an actual cause of the problem. A cause can be anything from “the device isn’t turned on” to “ component X failed on electrical board Y.” The depth of causes will depend on who the intended audience is and what level of detail is needed
-
-
Solutions
-
A solution is a specific task known to solve a cause. A solution is any corrective step taken within the troubleshooting process that requires performing an actual task.
-
-
Questions
-
Questions are observations used to identify, remove, or clarify causes and are integral to any complex troubleshooting situation. In complex guides that contain a wide range of causes, questions can help zero in on the solution that needs to be performed to solve the problem.
-
For each question and solution, we also associate a cost describing the resources required to make or perform the action. As a final component, the model describes the probabilistic relationship of the domain via a probabilistic model over all the causes, questions, and solutions.
In Dezide, that model is Bayesian Belief Networks.
As opposed to other AI technologies such as neural networks/machine learning, fuzzy systems, and case-based reasoning, Bayesian networks provide a theoretically sound approach that scales well with the amount of information unaffected by some uncertain or conflicting information. Most other methods are based on ad hoc computational algorithms that break down when the complexity or uncertainty increases.
Structuring Knowledge in the Knowledge Base
Experience shows us that technicians can spend as much as 30% of their time finding the relevant content in any given troubleshooting scenario. To prevent this massive waste of time, we must ensure the knowledge base is neatly organized for maximum findability.
When everything is built and organized the same way, we can save a lot of time for both the editorial team and the workforce in the field, as everyone can expect to find what they are looking for in the same way across products and errors.
Therefore, it is our job to ensure we maintain a high level of housekeeping and don’t make a mess in the knowledge base when transforming the raw data into troubleshooting guides. The easier it is for the few back-office workers to find their way around potentially thousands of troubleshooting guides, the easier it is for the hundreds or thousands of field service technicians that need to get to a solution as quickly as possible when on site – the quicker the technicians can fix the problem, the more professional he/she appears to the customer, the faster the machine is back in production – and the happier the customer gets!
Conclusion
The Knowledge Acquisition stage is a crucial segment of the Dezide Knowledge Value Chain, encompassing three key steps: Identification, Collection, and Transformation.
Identification: This initial step involves recognizing and pinpointing the specific knowledge that needs to be acquired to address troubleshooting goals and challenges. It’s about understanding what knowledge is essential, where it can be found, and how it aligns with your strategic service objectives. This phase requires a clear understanding of knowledge gaps and the potential sources to fill these gaps.
Collection: Following identification, the next step is systematically gathering the identified knowledge. This stage involves acquiring knowledge from diverse sources such as company databases and employee expertise. It includes defining, planning, and conducting training in Dezide methodologies, determining the collection format, and creating a plan for troubleshooting guide creation. The aim is to amass a comprehensive set of data and insights, ensuring relevance and manageability through effective filtering and documentation.
Transformation: This final step converts the collected knowledge into usable troubleshooting guides. This process involves analyzing and structuring the knowledge, collaborating with experts for accuracy and applicability, and creating efficient guides. The transformation phase ensures that the collected knowledge is made practical and accessible for efficient problem-solving.
Each step is interconnected, forming a cohesive process that ensures knowledge is gathered and made relevant and actionable. This phase is fundamental in ensuring that knowledge assets within your organization are effectively utilized, leading to enhanced problem-solving capabilities, better decision-making, and overall service efficiency.
In essence, the Knowledge Acquisition stage is the birthplace of valuable knowledge assets. It is where disparate pieces of information are carefully gathered, refined, and molded into dynamic troubleshooting guides. This foundational phase sets the stage for subsequent stages within the Knowledge Value Chain, ensuring the knowledge base is primed to empower field service engineers and drive operational excellence.
