This is a keynote transkript. If you don’t want to read, you can access the video of the keynote here.

… We’re here to discuss why it becomes more and more important to consider a strategy on how to efficiently allocate and transfer knowhow across your teams. And this is especially relevant for activities such as problem solving. The success of problem solving is directly related to how efficiently you can allocate the right knowhow to the specific problem you are trying to solve.

You will get some insights on how a foundation of such a strategy could look like. First, a more theoretical approach and then also some practical tips.

Example

Let’s start with an example. Let’s say you are a large automotive/manufacturing/…  company. Your teams are spread around 5 different locations. Within these, all your operational staff is working: Engineers, supply chain managers, customer service, quality managers. There are a lot of technical, organizational, procedural problems, challenges, questions, and also customer requests or complaints arising. And this happens on a day-to-day basis. Let’s say one of your plants is a polish plant and a technical challenge or issue arises in the daily business of one of your employees there.

We know from a study done by Deloitte that 72% of employees do not find the knowledge they need, even though it exists within your company. What does that mean? Whenever a problem comes up in your employee’s daily business, they do not find the info they need to prepare for a proper solution finding and they waste a lot of time. What they are doing in most cases is: they are setting up a local team of colleagues and discuss solutions and answers to that problem within their polish plant. Or sometimes the employee tries to find solutions on his own.

Inefficiencies

Now why is this inefficient? Two reasons: First, there might already be the same, similar or related problems that might have already been solved in the past, maybe in a different location, in a different team, in a different function. And this solution, these lessons learned, might have already been documented somewhere in a certain system that your employees are using, or maybe in a certain database.

Secondly, there might be very specific experts somewhere else in a different location in a different team or function with good experience, with a lot of knowhow on a very specific problem that came up in Poland. But it is hard to identify these experts and then to engage them into a solution finding.

Your employees that are in Poland and have that problem, they lose a lot of time. A lot of energy and maybe they do not end up with the best solution. Let’s take a look at where that knowledge lies.

There are 2 major locations within your company. On the one hand there is internal data. That is all the documented data in certain systems, software tools, also data in databases. And on the other hand, there is your internal expertise. This is way larger. There is knowhow, experience, that your employees have gained. And they have it in their head. Let’s take a deeper look into both!

Internal Data

Let’s start with internal data. There are system silos in your company. There are different databases and systems that your employees are using daily. On average there are 37 different systems and databases that your employees are using to do their operations. There is for example SAP where information about the companies’ resources is located, there are all your Microsoft applications with documents, lessons learned, guidelines, etc. There is a lot of collaboration going on. Then there are all your projects that you are working on in Jira for example. Then there is customer data in Salesforce and product data in Teamcenter. Just to name a few examples.

Across these different systems, there is very bad traceability of information. So whenever new problems arise, it is hard to find information across different systems. There are also different languages, depending on where your employees are located and there are very intransparent access restrictions within these different systems. And we know that a solution for one specific problem could be found in the combination of valuable information from up to 5 to 10 different systems. So, imagine the polish employee has a technical challenge and needs to look for and find information, to solve it, in a lot of different systems. It takes ages and is not even possible to find all information.

Internal Expertise

Next, let’s look at the second pillar, which is internal expertise. These are your employee silos. So, as I said I the beginning, there are employees that work in different locations, in different teams, in different functions. And in these different areas they might work on similar or at least related topics within their daily business. So, there could be an overlap of product groups for example. An overlap of customers, technologies, partners, etc. Also here, within your employee silos there maybe is a worse traceability of expertise. There is an old saying. “What if we knew, what we actually know”.

Different locations, different languages, time zones, availabilities, cultures, silo thinking, etc. It is hard to identify and engage the right experts in time, whenever a new, very specific problem or challenge might have come up in the daily business. And we know that only 20% of a company’s knowhow is actually documented. So, when we talk about your system silos, this is only a problem for 20% of your knowledge. But there is the rest of it, which is 80%. And this is all the ideas and experience and knowhow within the heads of your employees.

Where is this relevant?

Let’s take a quick look on where this is relevant. From our perspective this is relevant across operations.

Sales and services. Let’s say it’s a technological company and the sales manager is trying to acquire a new project, has technical requests from customers and your sales manager is trying to find the right knowhow within the bid phase of the project. But then also within the execution phase or the after sales of a project. Next: Quality. Of course, there are customer complaints everywhere that reach your customer services managers. And they could be very complex and technical and therefore knowhow needs to be allocated in real time whenever a new complaint comes up. Of course, it’s self-explanatory: Production and Engineering, this is where big challenges are solved. And Logistics & Supply Chain, where we have a lot of organization topics, when it comes to supplier management, integrating procurement into the supply chain, etc.

I am going to show you an approach on how to bring this all together. This will be a theoretical approach first and then I will give you some insights into how a practical approach could look like.

System Silos

Let’s start with the system silos. The documented knowledge and information within your systems. To get these different silos under control, you need to build a system spanning network. That means, a network, where valuable information across systems and languages is considered. And there are 2 methods that need to be taken into consideration. And both are vitally important.

Pull

First, it’s the pull method. That means problem first, and solution second. So, an employee in a polish plant that has a technical problem needs to somehow describe the problem in his or her own language, his or her own style of speaking or writing. And then, across different systems an automatic assignment of information to that problem needs to happen in real time. So that your employee knows: what are the information sources and can directly get into them to the right place, at the right time.

Push

The second method has at least the same level of importance: The push method. It means: no problem first, but solution first. Means: Issue prevention. So, let’s say: an issue is solved in Poland, lessons learned are generated, and other locations, teams or functions are working on similar topics in general. So, you need to proactively inform and notify these stakeholders on relevant solutions and lessons learned generated somewhere else. And you need to do that across silos, and you need to do that across languages. This helps to prevent issues, that might have already been solved in a certain team, to come up in the first place in a different team in the future. Why should a problem come up somewhere if it has already been solved within the company?

Access Restrictions

Also, there are, I have already touched that in the beginning: access restrictions in these different systems. And don’t misunderstand me. These access restrictions are everywhere, and they are very important. Especially if it comes to customer data for example. But why not, at least, guide your employees in the direction where valuable information lies for them? So, they can at least ask for access. This is not possible for all systems or for all kind of data, but in some cases, access is restricted without reason, and it’s more like a technical restriction, a business restriction it that sense. I hope that makes sense.

Documentation

And finally, it is also important to try to document new information or lessons learned automatically, while the problem solving happens. Because you might have already tried it. Telling your employees to document all their information and knowhow manually. This leads to a lot of gaps, a lot of errors and it’s a lot of effort for your employees that should rather work on solving problems than documenting the solutions of already solved problems. So there needs to be automatic documentation of information while the problem solving happens.

Expert Network

Next step: An Expert Network. This is the internal expertise, your expert silos. In this case you need to build an expert network. This is a network to easily identify and engage experts on very specific problems and challenges. Especially if these experts are setup across locations, silos, languages and different availabilities and it is hard to get them together, to identify them and to work on solutions together.

So somehow you need to map out expertise’s of employees based on the digital footprints they leave within your systems. This means it’s rather inefficient to set up expert profiles based on HR directories, job descriptions, because this is very basic information. And there are a lot of blind spots in your systems, your databases, the tools you are using on their daily basis. Because this is the place where your employees are adding and editing information. They are working on solutions, on projects, on customers on guidelines, on documents.

This is the real valuable information. And if you could somehow understand that information and understand who is working on what kind of topics, lessons learned, customers and products, and build that within a network, understand who is an expert on what specific topic, that would be valuable. And this obviously changes dynamically, because there are new topics coming up, new information is shared in this different tools, and expert statuses are not fixed, they are dynamic. That’s important, yet a real challenge.

Finally, within your expert network you need to allow asynchronous communication. Because you need to break time and availability barriers. It’s hard to get all experts at the table at the right time together, which is needed to select from a wider group of expertise, solutions and ideas on specific problems.

Now if you’d like, I will jump a bit into how we at Johari go about it. You’ll then understand what the foundation of our platform is and how we bring all this information together in one Knowhow Network.

Book your free usecase demo here.