This blog originally posted on Jim Gavigan's LinkedIn page here.
Wikipedia defines tribal knowledge as:
"Tribal knowledge is any unwritten information that is not commonly known by others within a company."
Imagine a world where all we had was tribal knowledge of how things work, yet no data to validate the knowledge. How could we get that knowledge out of the few and into the many, yet still make the ones with the tribal knowledge as useful as they can be since they have knowledge that isn't common? They would just spend most of their time educating others on what they are good at, instead of doing what they do best. On the flip side, imagine data in absence of any tribal knowledge. This would be a very undesirable situation as well. How could we turn data into information? Then information into knowledge? Knowledge into action? Action into dollars? It would be impossible. It is obvious that we need both good data and an improved knowledge base.
My last post discussed how we have to get the tribal knowledge out of the battle tested and/or soon to be retired workforce into the younger and up and coming workforce. However, there is also a danger lurking if we aren’t careful. We cannot let tribal knowledge block us from new insights we might glean from data and information and different sets of eyes on a same set of problems. Sometimes, having lots of tribal knowledge gives us preconceived notions, right or wrong, that need to be re-examined. Sometimes, our hard fought experience and the data all line up. There are other times that the data will take us in a new direction that goes against our tribal knowledge and one that could lead to efficiency and optimization breakthroughs. I use the terms ”we” and “our” as I am including myself in making sure my own tribal knowledge isn’t a hindrance to my company, our customers, or even me, in moving forward.
I recently have read many of Gerhard Greeff's posts on LinkedIn and one that really intrigued me on this topic of tribal knowledge was "Three reasons “Tribal Knowledge” is not effective in decision-making." I think Mr. Greeff is spot on and I would like to expound on his thoughts as it relates to manufacturing intelligence.
Here are some statements that Mr. Greeff makes that I am in agreement with:
"A lot of our decisions are based on prior experience and not necessarily on detailed domain knowledge. If something worked before, humans tend to repeat the action given the same situation. They will keep on repeating the action even if they do not understand why they get the results they do. Operators will teach their subordinates or replacements the same actions, without batting an eyelid. This is tribal knowledge. Tribal or experiential knowledge reduce the time between event or incident and action. The operator thinking process is eliminated, leading to faster reaction times. It also leads to a “monkey see monkey do” situation in the long run. Eli Goldratt calls these ‘local optima rules’ – because people lack a complete understanding of what’s happening within the entire production process."
"The problem with this is that if the operator doesn’t understand why an action has a specific consequence, he will not know what to do if the action does not give the expected outcome. The operator will not even know where to look for a problem. The experiential training process does not identify, by default, the correct set of key parameters affecting performance of a process. The more complex the process is, the bigger is the potential for making incorrect assumptions regarding cause and effect, especially under adverse conditions."
In this era of big data, analytics, and machine learning, conventional thought processes and the status quo will be challenged as companies are still striving for efficiency improvements that have leveled off in recent years. Many times, tribal knowledge can be a hindrance to improvements, because the person with the tribal knowledge remembers all of the prior attempted improvements that didn't work. We often pass off a re-hash of an old idea that didn't work out, despite the fact that the technology available to implement that idea may have drastically changed for the better since the last time the idea was tried. Now, mind you, that doesn't mean that we need to re-hash ideas that truly don't make sense, but ones where the data and technology available might make the idea more realistic. I think as we get older and gain experience, we often don't want to relive past pains of lessons learned. We somehow have to balance our experience with what is viable and realistic. Again, I say "We" as I have been guilty of passing off a young engineer's ideas without any study. I think that this is a dangerous behavior in this very competitive world.
I have often observed tribal knowledge in silos as well. The operator has a certain tribal knowledge of how a process operates. The process and automation engineer often has a different set of tribal knowledge and perspective. Often, this tribal knowledge can lead to blind spots. The process may have plenty of designed capacity, but because of the way the automation engineer has the operator interact with the process controls, the designed output may not be reached. On the flip side, the operator may ask for things that physically are impossible because of a lack of domain knowledge on the process side.
Often, a manufacturing intelligence system can be where the two entities have common ground and can begin to understand the true root cause of an issue in the process. A great example of this was described at this year's OSIsoft User's Conference in San Francisco, where Deschutes Brewery talked about how neither engineering nor operations really understood why fermentation tank stratification was happening. Brian and Tim even remarked light heartedly about a bit of finger pointing between engineering and operations (this was not mean spirited finger pointing, but just shows how human nature seems to lead all of us to look elsewhere for blame to a problem first). As an example, the operations team first seemed to think that there wasn't enough glycol being delivered, and engineering felt that the glycol system was designed with enough capacity. It turns out that glycol delivery was certainly not an issue, but both sides were pointing fingers a bit until they both had the data in front of them. They did discover some of their manufacturing process may need to change (i.e. when they do yeast pulls) and a few other nuggets of information, but there was no "silver bullet" that solved the issue. Having the right data available, as well as having that data turned into actionable information, and through proper application of shared knowledge, the engineering and operations teams are working on a solution to the fermentation stratification issue together.
To go back to Gerhard’s article, I agree with his conclusions:
People will make decisions, take actions and teach others their “tribal knowledge” based on their personal perspective and experience, even if the environment changes
People select the data and information they use to base their “tribal knowledge” decisions on, without necessarily understanding the governing principles of the process
The way information is conveyed to operators can define “tribal knowledge” and influence the way they react to changes in process conditions.
The third bullet is where manufacturing intelligence plays a role and I will expand on what he says. It isn't just how information is presented to operators (as he was addressing HMI visualization for operators in his post), but also to operations management, engineering, maintenance, etc.
In doing further research on this topic, I found this statement (emphasis mine) written by Mike Collins, who wrote the book "Saving American Manufacturing," in his blog "Workplace Continuity: How To Replace Tribal Knowledge" I think this a good call to action for all of us:
"-- Commit to the time — Both the downloading of the information and the development of new training programs is much like an apprentice program that will lead to journeymen. One must accept the fact that it is a long-term investment that may be three to five years. As soon as it is practical, it is necessary to appoint the people who are likely to replace the gurus to both learn from their mentors and to get the tribal information onto paper.
The cost justification is always difficult because you are asking management to invest. The costs for the additional labor and training costs could be in the hundreds of thousands and it is difficult to pin down in a return on investment formula. But the danger of doing nothing is endangering millions of dollars in future sales. This problem is not going to be solved by just an aggressive hiring program of new people after the gurus have retired. It will take a long time to transfer all of the skills and knowledge needed to replace the baby boomers with most of the tribal knowledge."
Blog bottom line: The key is that we have to leverage this tribal knowledge before it gets out the door. Let's just make sure that we don't have blinders on when doing so.