Having worked together on an exclusive new Field Service News White Paper, Kris Oldland joined Martin Knook, CEO of Gomocha, to discuss the various layers of knowledge transfer and the art of information.
In this engaging long-form discussion, the two cover a vast range of topics relating to the importance of knowledge transfer, including why developing a culture of continuous learning is critical and what technologies need to be in place to make putting the correct information where and when it is needed the most.
In this segment from that hour-long, full-length discussion, the two take a moment to look at how valuable utilizing asset data effectively can be – particularly for field service organizations as they seek to evolve in these times of mass disruption and continuous challenge.
This interview is part of the FSN PRO library of premium content. It is available in FSN’s free subscription tier FSN FREE. Make sure you log in to view the complete whitepaper and videos.
Transcript
Kris Oldland: As the opposite of everything we’ve been moving towards in this industry, it’s the opposite when considering servitization outcome-based services. So we’ve almost moved away from the traditional break-fix, the transaction. We’ve tried to make the service more experiential. We look at the customer’s needs rather than what we sell. And so, there’s a danger of slipping off that path. And that’s not to say that’s correct. Whenever I’ve talked about servitization, I say it’s not right for every business. Some businesses can do that break-fix model forever. They make their money fast. It’s not that one is right or wrong, but there’s a red flag of companies moving to outcome-based. We’re moving outcome-based, servitization, and we’re doing everything remotely. It can be done. I know companies are. But there’s a human element that needs to be acknowledged. And it’s, it’s not quite that.
Martin Knook: So those outcome-based assets, and you know, them being autonomous, healing themselves, let’s bring attention to that. So the field service we currently have, break-fix, if that wasn’t applicable, for businesses transitioning to that model. They need to figure out different services around your assets. You should not forget to promote the value you have delivered, knowledge. How has the asset performed? Review your portfolio of assets and see if there are optimizations. On many different other aspects of only outcome-based energy consumption, effectiveness. Many other parameters can come into play, such as a service you’re selling or offering to your customer that you don’t see for a break-fix.
Kris Oldland: The obvious one that leaps out right now is ESG, with the measures and regulations. You’ve mentioned energy consumption. Any service provider, like a manufacturer, can get a third-party contractor to look after all your assets and do break fixes. We can come in. This is where the technology starts to come into the equation. We can come in. We can help you optimize your goals, but they can fluctuate. So you’ve got quite a seasonal business, and we need to ramp up production in a certain period. And then we want to bring that down. Production is slightly slower in our off-time when we can reduce energy consumption. You can start demonstrating sustainability credentials. That is something we touched on in that first paper, knowledge? We often get caught up in our industry knowledge. Knowledge is just: how do we fix an asset? How do we tell the tech to fix the asset? But there are all these other layers. We went with that art of information because it’s a broader stroke.
Martin Knook: We’re touching on the dynamics of knowledge, right? It’s not like a static theme that knowledge as an asset is static. You have a model over time. It has no specific composition of whatever exists. That’s static. Still, the whole knowledge around assets, including what’s relevant today, is a different type of knowledge that needs to be shared—even more challenging.
Kris Oldland: There are two layers of this conversation. There’s the dynamics of knowledge. But there are two layers to this. Our audience here, the service leaders, executives, and VP of service, will need to know about these two layers. They’re going to be interested in the two. They’re going to be thinking of knowledge differently. But of course, we do need to bring that back as well, which we did in the paper. What are the dynamics of knowledge transfer in the traditional sense?
There were a few areas that I looked at as challenges—as somebody that is a technologist, got that operational expertise and experience. As somebody that’s built a platform that inherently understands the challenges field service organizations faces and solves. I would like your thoughts on how we should tackle these, whether they’re one issue we tackle or check them off. These are the common [challenges]. I speak to many service leaders, and these are common themes that I see: a lack of a centralized knowledge repository and difficulty in capturing and transferring knowledge. And that could be the tech or the asset, or the IoT. It could be capturing that knowledge, information, and data. That data is consistent. So we don’t get lost in a data warehouse. That’s something that you hear quite a lot from older techs. It’s that tribal knowledge; I don’t need to; I know everything about this. I’ve been fixing these assets for 20 years. There’s that resistance to sharing as well. It’s like, I own this knowledge; it took me 20 years to get to this point. I’m not just going to share it. And then, with the high turnover, it’s become a cutthroat sector to keep techs because they are in demand. And that adds to the limited time and resources for things like training. So there are many challenges, Martin, and that’s the nitty-gritty. Is it one magic bullet? We’re going to build out an approach to improve our knowledge transfer. We’re going to improve our approach tool. Or should companies go through this? We’re going to tackle building out that knowledge repository. So do these feed into one place?
Martin Knook: That would have been nice. If I could say, do this first and then do that. You have to work simultaneously. And it depends. It may sound strange for me to focus on enabling these organizations with it, but I’m still conversing with customers that do not have unique asset IDs or have yet to document everything. They have practical issues that are rooted in and hinder knowledge transfer. Foundationally, there is nothing in place to do that. So you have to reach a certain level of a centralized knowledge repository. You can only do that with good structured asset identification and categorization because you’re not running field service on one type of asset that you produced 20 years ago. There is a whole dynamic of versions, releases, and modifications that you have done. So and then put on top of a knowledge repository. That is one of the most important pillars, just as an enabler. It doesn’t do much. It only does a little for knowledge transfer but makes it possible. It’s the starting point. So that is important.
I hear a bit of resistance and difficulties, and people don’t want it. I’m Dutch, so I’m direct. Still, that says more about the weakness of the management organization to approach reasonable notes and transfer methods than those field engineers who go out with passion every day, love their job, and are proud people that they are against it, if that is the perception, if that’s on the management agenda, you have another problem to solve. And, just capturing the history of what happened to an asset is a practical thing you can learn from. In particular, when you use frequent root-cause analysis, if you have the data, it’s simple to learn. But you can do that without that knowledge repository in place. And you can’t do that without winning your team, making notes transfer. So make it fun; try to find a way to make it fun.
I was talking to one of our customers about this subject and said, you have a pretty all-round team of field engineers. We were talking about skill sets and how to optimize planning and the efficiency of his operation. And he was holding his positions. “I’m not worried about skill sets in my team. I’ve been evaluating my team. I asked them, Where do you feel uncomfortable? What kind of tasks do you feel uncomfortable with doing?” And his remedy was not to shy away from assigning tasks but instead assign those tasks, which was simple. It enabled knowledge distribution in his team. He had a very open mind, transparent and communicative with a large population of field engineers that were non-resistant to knowledge sharing. Still, you must find the right trick for your team and business.
End of Transcript
You can view the full white paper, Knowledge Transfer: The Art of Information.
This blog was originally posted on the Field Service News blog.