The People, Process, and Organizational Change Side of PLM w/ Nick Owens
In this episode we will be talking with Nick Owens from Delta PLM.
Nick Owens is the owner of the PLM consulting firm Delta PLM. Nick is a manufacturing engineer through and through, having worked in high volume consumer goods and telecoms industries for brands such as Candy, Baxi, and Marconi.
After 12 years of factory work, he joined Dassault Systèmes as a solution architect for digital manufacturing, leading projects at Airbus, Bombardier, and PepsiCo. Following this, he moved to Rolls-Royce in Derby, to work as a senior member of their corporate PLM program, before moving back to work for Siemens as an enterprise architect.
In 2019, he decided to go his own way and set up Delta PLM. His aim was to provide a people, process, and digitalization consultancy service independent of technology, and to enable customers to achieve a level of digitalization maturity that is appropriate for them.
Subscribe and leave a review, would ya?
Hi everyone, Helena Gutierrez here, from SharePLM. And today, our guests on the SharePLM Podcast is Nick Owens. He’s the owner and principal consultant at Delta PLM. And Nick has a strong background in manufacturing, and he has worked as a PLM architect for the big two: Dassault System and Siemens TeamCenter. Hi, Nick. Thanks so much for joining us.
OK, Nick. So as an engineer with a strong background in manufacturing, what brought you to product lifecycle management?
It’s a it’s an interesting story, actually, because my move out of real world engineering into PLM was the other bet. So I was working at a white goods engineering company where I was a senior production engineer, and they just bought some discrete event simulation software through Delmia. And when I joined, I picked it up to help me in one of my projects, which was looking at manufacturing feasibility of a power plant and I started using the software.
And as the project got more complex, I had to turn to Delmia for some help so they’d come along. One of their consultants came on board with the project and helped me through modeling some of the complexities of it. Then I later found out that there was an internal battle within within Delm, that I couldn’t complete the project because it was quite complex. Anyway, I did complete the project and and then a few months later, they offered me a job. So that was my transition from engineering to PLM.
Wow. Very interesting.
Not not not very not very standard, but it’s a start.
Excellent. OK, so after working as a system architect for some of the big PLM software vendors, why did you decide to start your own company, Delta PLM?
I think it was a mix of few things, really. Obviously, I saw a gap in the approach that the vendors were taking, which was very much my point of view at the time. But over the last few years, I’ve come to realize that a lot of companies out there can benefit from PLM without necessarily deploying PLM to lower PLM technology. And that is more focused on adopting the people, process, organizational change side of PLM. Now, granted, you need the tool and the technology as well.
Clearly, but but yeah, it was a whole raft of different companies out there from very small engineering companies to major global manufacturers, but they’re all trying to achieve the same thing, and that is control of engineering, control of manufacturing and traceability and compliance. We’re all working towards the same end goal. And unfortunately, you know, the big multinationals can afford huge, great integrated systems. But your smaller engineering companies can’t. But there’s no reason why they can’t still succeed.
So from working in different companies of different sizes, you know, it’s clear that the vendors, they are very happy working in that technology space. They can commend, do business assessment, do business consulting and deploy a tool to solve their problems. But then none of the vendors really tackle the organizational change pace, and that’s fine because they are technology providers, but I think we’re all agreed that if you don’t address the OCM, then you’re never going to have a truly successful PLM project.
Now, don’t get me wrong, the vendors come with their view of industry best practice, but it’s still their view and customers can be seen sometimes as a bit of a skewed view on the world, making the process fit their tool. But then when you look at it the other way, the people who are specialists in OCM, they’re great to do in the people and process bit but they lack on the technology side of things.
So, you know, there’s the needs to be harmony between these two sides of PLM and in my experience, have only ever come across two people that can really talk both sides. And again, they are inde pendent people. So we decided to put myself out there and having a bit of a unique background myself in terms of strong manufacturing come from the shop floor, have been burned by these engineering and manufacturing problems. I thought, well, I’ll give it a go.
So set myself up and up. Over the last couple of years, I’ve created some strategic alliances with other people in and around the industry to offer quite a wide offering to my current customers and future customers. And, we go in and we can offer truly independent consulting advice that can address the people, the process, and the technology. But, um, and, you know, my approach, I’m quite having come from the shop floor.
I say it as it is. And I think well, certainly the feedback we’ve got from customers is that, you know, that is that they value that. Two comments stand out for me. One person referred to me as a rough diamond. Great. But, you know, a bit too direct. And another people see me as a bit of a critical friend because at the end of the day, that’s what I’m there to do.
I’m there to challenge them. Are you making the right decision? Have you not thought of this? And that’s what PLM is all about, really.
Absolutely, and that’s actually rare to find. I’ve also seen that as a gap in the PLM market, the people who come from the more of the human resources side, they are very good at OCM. But maybe they are not trusted by engineers.
Yeah, exactly. And it’s not sort of positive friction between the customer and the vendor. And I think it was in one of your previous podcasts where you were talking about vendor selection processes. And, you know, the gentleman that you interviewed made some very similar comments and that a vendor can comment and provide consultancy, but it’s always in the back of the customer’s mind. Are they doing this for their own benefit? Is it truly independent advice?And you know that’s what we’re positioning ourselves to get.
Right, then maybe you can you can guide me through that. Now, what kind of problems are you are paid to solve at Delta PLM?
So we cover all sorts of things. We’re trying not to put ourselves in a particular pigeonhole. But what it’s clear that no matter what the company is, a customer will always fall into one or maybe two or three different categories. So we’ve got the companies who are evaluating options in terms of PLM or they may well be evaluating vendors. And, you know, we can go in, work with the customer and be that.
Be that critical friend both to the customer, but also act as an independent to keep the vendors honest so that, you know, having worked for Dassault and Siemens, we can somewhat look through some of the sales patter. And, you know, I’m not saying that we should call these people out, but that’s really not what we’re about. But having that, um, having that independence to a customer, I think is is quite valued.
And and we’ve done and been engaged with with a number of customers just doing that. We’re not doing the technology deployment. We’re not doing the process deployment. But they want to use those sounding boards to say, is this right? What’s your opinion on this? And, you know, does it fit with our future strategy so we can do some strategy, work with them as well. We’ve then got you’ve then got the next two categories, which are your customers, either a new company or it’s a heritage company.
So your new companies are your start ups and and these customers really have a huge advantage over the market. And if they didn’t shoot for the stars, they would be selling themselves short because they don’t have the constraints that heritage companies do. So, you know, we can work with these people to say, OK, you don’t have the legacy thinking, the legacy processes and, you know, 23 years worth of data within your volumes. So, you know, you can really push the boundaries of the technology to say, well, this is what we want to do.
Therefore, we want to structure our data like this. And it can sometimes cause the vendors a bit of pain because the vendors clearly have a very forward looking software and they’re always trying to be one step ahead of where industry’s going. But some of the thinking sometimes can be based back in heritage processes so we can work with customers who are startups, if you will, or mold breakers to say, OK, let’s start this business off on a good foot.
And one of my current customers is is exactly that, you know, they are brand new new into the market, new into the industry and are wanting to get things right from the outset so that they’ve got a good, strong foundation on which they’re going to build that PLM strategy over the next five, 10, 15 years. So they’re the model breakers, they are the startups, the newbies. But then you’ve got the heritage companies, these companies that have been dominant and seen it and got the T-shirt.
They will approach things in a very traditional way, and that is predominantly because it’s part of their DNA, you know, that they’re organized around silos or sorry, we don’t call them silos. We call them cylinder’s of excellence. But, yeah, that they’re organized in silos. And as a consequence, the data is organized in silos and they may well say that they’re operating PLM but in if we’re being very picky and truthful, they’re actually running PDM or TDM systems so we can work with these type of heritage companies to try and move them forward into PLM them and give them that moment of realization to go.
Actually, guys, you know, you need to in order to take that next step, that paradigm shift, what you actually need to do is you need to do an element of process or organizational change. In order to really cash in on your technology, because quite often these companies already have a technology and a tool in place, but they’re probably not using it to the best advantage or or they’ve got a ground-breaking new manufacturing process like additive, for example, that doesn’t quite fit with that traditional manufacturing processes.
So we can work with these guys to try and integrate in their new ways of thinking into their current and traditional PLM systems. So, you know, without sounding corny, we can work with you no matter whatever your needs are. And you know whereas we every month that goes by with our customer base, we’re beginning to get more and more credibility behind us in terms of tangible and real experience dealing with these different problems from a wide range of companies.
Right. And I think that that experience and the background is really what makes you unique. And I think that the combination of engineering, manufacturing and software, that’s what makes it interesting for this software selection process you mentioned at the beginning, but also your background positioned you as a trusted partner for start-ups, but also for heritage companies that want to the PLM. Can you maybe share with us some tips for companies who are looking to integrate their manufacturing processes with their products?
So, you know, we’ve got we could start talking about things like design for manufacturing initiatives and establishing integrated project teams. And, you know, that’s not really anything new. And really, I’m not going to tell you anything new, but it’s hammering the same message home again in terms of, you know, to really get the integration between manufacturing and engineering. You really do need to break down that wall that is always there between engineering and manufacturing.
And you need to do that as early on in the DMPI processes as possible. And you do that by instilling a culture of openness and instilling, you know, an organizational construct like a Matrix organization instead of a functional organization, for example, which promotes design for manufacturing and promotes that communication. But so you can do a lot without a tool in technology, but what you also need to do, and this is very specific to tool and technology and that the end to end value chain in which these DF teams or or IPT at work, that value chain from engineering power through to the execution of a work order on the shop floor that value chain consist of.
A lot of data and a lot of connectivity, and that end to end chain needs to be communicated and agreed with everyone, because quite often what we say is when people, processes and technologies are deployed, we map out that value chain. That’s part of the day job. But what we need to do is get people to buy in to the value chain, because when we when the project’s deployed and we all go back to our desks, what you end up with is this, again, this siloed thinking of, OK, it’s my job to offer this bit of the data in the value chain, and that’s all I’m going to do.
Now, we need to change that so that people think about, well, who is my customer in the value chain? What information do they need from me in order to make their life a little bit easier? Or what do I need to give them to allow them to extract more value out of the data that I’m beginning to create? And things like PMI is a great example, you know, and making that three day data available throughout that value chain just makes everyone’s life easier and allows us to exploit downstream activities because we’ve built in that three days PMI. A great example.
And it’s something that I’m working with one of my customers currently. But it’s also understanding that, you know, you’ve got it’s the age-Old scenario where engineering spends all of the time and all of the budget in creating this ultimate design. And then manufacturing is compressed, and the PM is got sort of 20 percent of the entire value chain in order to make it make it real and happen. So, we need to we need to really address that. And I strongly believe that that is a tool or a technology thing.
It’s a people and process thing. But after a bit of a brainwave on this next piece, we focus traditionally within PLM, we focus on creating things like manufacturing BOMs, process with a means to an end. And that means to an end is to create the as planned structure. This is how we’re going to build our product. It’s all product focused. But what if we turn that around on its head and said, OK, why can’t we create manufacturing BOMs and build the process to develop our own manufacturing processes, now, if you think about that, you could say, well, that’s just part of the day job, but in actual fact, using our PLM tool to allow for the connectivity data as we progress through things like process excellence initiatives, where we are gathering a PQ type data, where we’re gathering statistical analysis data, and embedding that into a process that is sort of self-fulfilling, if you will, something that can be matured so that our processes become better and therefore our manufacturing capabilities become stronger.
If we have this data connected and available across our value chain, that then allows us to be more engaged in design for manufacturing activities because we understand our processes better, and if we understand our processes better and drive the engineering definition stronger and more efficiently, then we can really start pushing the boundaries and getting our products to a much higher standard. And if we can use that in further and business cases, then what that means is we’ve got a process definition to back up a business case and the business cases where PLM programs traditionally fall down.
If you’ve got a strong business case that’s secure funds that sorry, that secures funding. So we’re able to do more PLM programs. So we’re beginning to build a positive spiral. And this positive spiral when there’s something good going on within a company. That positive spiral, I imagine it like a whirlwind, it begins to suck people in from different parts of the business and the people who stood on the sidelines would always, you know, be very critical of new things.
But if they see something positive going on, the more likely to get engaged, the more people we have engaged, the better it is. So just by doing something simple is integrating manufacturing into engineering that can really have a massive effect on an organization and therefore the PLM programs.
Absolutely. And those are really good tips to get people in the value chain to buy life cycle thinking. How do you think companies can overcome the complexity, challenges of all these connected functions and departments, is systems engineering the path to deal with complexity?
So, you know, we’re all we’re all sitting on LinkedIn. You know, we met through LinkedIn and we all read the articles and there’s an awful lot of posts around model based systems engineering currently. And we tend to hear less about systems engineering. It’s all about NBCE because because that’s really the the on trend thing to be deploying or getting involved with. So if we if we boil it down, you know, the way that we deal with complexity as got to be addressed by systems engineering or an NBAC approach. There is no other way. What we are what we’re beginning to see within the market is obviously a product: the cars, the commercial vehicles, the boats, medical devices, whatever aircraft. They’re all getting more complex. And that is predominantly due to things like software integration into vehicles, for example. And when we have that in an organization that is organized in a traditional manner, for example, Chassy Power Train, you know, we’ve got these cylinders of excellence again that are looking at the individual bits, but software and electronics is blurring that boundary.
And the only way that we can deal with that is through exposing it. And adopting a systems engineering approach is the only way to expose that. That complexity, because it’s masked by the organizational structure within the business. It’s masked by people. You know, we can you could walk into any automotive company, any traditional automotive company, and they will have, you know, these cylinders of excellence, but then they will have people managing the interfaces between those silos.
So but what they’re not doing is fundamentally addressing the complexity of that interface. They’re just putting more people in there. And this has obviously having a detrimental effect on the bottom line of these companies, because they’re just throwing people at it. And where you’ve got people in an organization, these people are running processes and using technology. So so the complexity is getting blurred and hidden. It’s it’s like we’re just putting a sticking plaster over it.
But one thing is for sure is that complexity will always get the better of you. And I put my mortgage on the fact that complexity will win at the most inopportune time. You know, you’re late for delivery. Your project has gone over cost, you know, and these are the things that can really set companies back and affect things like time to market and adversely give them a disadvantage for things like competitive advantage.
It’s not a case of throwing people at it, what it is a case of is looking at the process that would to do that. And by adopting NBAC or I’ll just use the one term NBAC approach that allows us to understand the complexity. It’s not going to take it away. Nothing will take it away. The product that we demand as consumers need to be complex because we want integration with our phone and, you know, Google activation on everything so we can’t get rid of it.
But what we can do is accept it and understand and manage it and take an NBAC approach allows us to do that by taking the complex areas. Well, first of all, identifying the complex areas of urban engineering design, but then be able to look at it using things like abstract models of that particular area to really understand it. And once we understand it, we can then learn to embrace it and live with it and manage it through its lifecycle. So, you know, tackling it by process is the only way.
What I’m afraid of is that there are a lot of customers out there that are just throwing technology at it. And, you know, we the vendors have a systems engineering aspect of their particular tool. But when you look at it from a systems engineering point of view, actually the tool is just the enabler of the process. It’s not the solution to the complexity. And I think that is creating a little bit of confusion within the customer base.
So if you look at it from a systems engineering point of view, like say that the technology enables us to manage this data and if we take that approach by addressing complexity through systems engineering. In doing that, that will allow us to build a more robust tool offering, i.e. PLM, that allows us to manage the complexity rather than manage the structure that’s causing the complexity. And what that results in is a more robust digital thread for the customer, because all the interfaces are connected.
All of the data object to all of the models, all of of the substantiation material, all of that is connected in a way that is dealing with the complexities straight on rather than going the other way around, which is making the PLM system adapt to the complexity, and I think that will that will create more complexity later on.
But you are saying that understanding complexities is understanding and accepting the complexity is the first step to actually address it, right?
And you mentioned technology being the solution that customers think they can use to help them address that complexity and not being that… What is seen in your view? What are the primary reasons why people in those organizations with this technology and what specifically PLM systems?
I think there’s I think there’s a number of contributing factors here. I think PLM is quite often misunderstood. There’s a lot of people out there that can talk, but I’ve only just learned how to spell it. And there are a number of issues around PLM in terms of its its perception. PLM systems are costly and they are hard to scope. They are hard to build a business case around. And the change that is demanded on an organization to properly implement is far reaching and it’s very invasive into an organization.
So there’s a lot of issues around resistance to PLM, but it doesn’t need to be that way. If we look at things like cost and sponsorship, they generally go hand in hand. So PLM is not equivalent to Microsoft Office, for example, you can’t just buy the CD and the license and the next finish and you’ve got a PLM system. It takes a lot of scope and it takes a lot of defining and as a consequence, takes many years in which to properly deploy and exploit.
You know, I’ve worked with customers that are that started a PLM journey back in 2004, and they’re still very much on that journey today. So, you know, they’re coming up for 20 years now. And these long programs quite often are beyond the tenure of the seniors who are putting their name against the purchase orders to go and do this work. So, you know, if you consider a C suite sponsor, they’re probably only going to be in position, what, three to five years maybe?
And you’re asking them to put the name to. I don’t know, five, let’s say, five-million-pound PLM program. They’re very unlikely to do that if they’re not going to see the payback in that tenure because they want the kudos that goes with it. So what we need to do is start looking at how we tackle PLM. And, you know, there’s these methods out there, like an agile that can facilitate that and that allows us to tackle the beast in bite sized chunks so that we can create that positive spiral that I was talking about and that self-fulfilling prophecy where it just begins to create positivity and therefore excitement.
And if we have that, then the business case will be much easier to do it. We’ve also got technology issues. There’s been a big change in PLM going from sort of installed and managed on site to cloud based, and I think you spoke to Oleg Shilovistky about that a while ago. So, you know, this does technology issues. And quite often the people and the customers that are on the IT side of the fence, they don’t always appreciate the intricacies and the complexity of deploying a PLM system because it’s not standard software deployment.
So there’s resistance to change there. Then you’ve got the custodians of the data. You know, PLM will potentially create data migration activities and that in itself can create nervousness within the business and therefore create resistance. So we need to understand and we can boil it down into a business case. We can boil it down into technology and data, and we can also apply a sort of application to this. You know, the UI that people will be using day on day will change.
And that in turn creates resistance. So, you know, adopting things like the toe approach that tackles those aspects as discrete entities can can can only help because we really do need to get rid of this resistance to PLM, because PLM will be the success or failure of our current engineering companies. And in my opinion, you know, with things like Brexit going on, I don’t I’m no political animal. Don’t get me wrong. But I really feel that in order for us to stand on our own two feet as a country, we need to really get behind engineering within the UK. And PLM has got to be a fundamental to that. It will be do or die for UK engineering.
Absolutely. And what’s your experience with companies seeing PLM as the basis to do all their stuff? Cool stuff like artificial intelligence or smart engineering, or IOT?
Yeah, I mean, there’s that you only need to go on social media platforms like LinkedIn to realize what the next sexy technology is. But when I was on the tools, it was five bucks this machine was was sexy. But now but doing things really cool stuff with additive manufacturing, augmented reality with which really common. But um, I’m not doing these, doing these solutions and injustice or doing them down.
But we need to we need to really consider that if we’re truly going to exploit these new technologies, we really need to focus our attentions. If we haven’t done already on getting that core engineering data under control and getting that data in the way that these new technologies can exploit that data, because otherwise all we’re doing is we’re going in we’re deploying some new sexy technology that is just creating another mini-industry within our company. So, you know, you end up with the engineering department over here and they do engineering draw and CAD whatever else.
But then over there in the corner, you’ve got the the the youngsters doing the additive manufacturing stuff. But when we look at things like engineering change. Those two things need to be directly connected, not independent. So we need to address that and not be not be dazzled by the next shiny thing that comes along from industry or out of some of these manufacturing think tanks. Well, I’m not I’m not saying we shouldn’t deploy it. I’m saying we should go into it with our eyes open and understand that, you know, the foundation of our business is our engineering data, not the next shiny new tool.
Absolutely. And I think that long payback and long programs that you mentioned before and I’ll tell you the primary reason why people are motivated and finally they resist.
Yeah, exactly. Exactly. And, you know, quite often you can go down the route and have seen that happen where customers go and buy. You know, we need to do this because it looks good. And the engineering director was at a trade show when he got wooed by a loader salesman. And therefore, we’ve got to do this. OK, but as soon as that is deployed. Then as soon as we run into problems with that, it’s then somebody else’s problem, God forbid, it should be the new technologies problem.
Unless we really focus on integrating that new technology, then those problems will happen. And it will it will then create negativity within the organization that says, well, yeah, let’s not change again, because last time it hurt us, which isn’t a good place to be when we’re talking about PLM systems.
That right. So Nick, what are some books you would recommend to them so that they can utilize them or help them with their PLM implementation, the decisions and people going to change management program so that they’re being more effective and satisfying in the jobs.
So I’m I’m laughing internally that question, because for anyone who’s listening to this that knows me, knows that I am no book reader. However, I have recently read three books. So the roles seem to be focused around the people process and change. But and there’s one real tacky book in there as well. So John Cotter’s Our Iceberg is melting. That is a done that is a brilliant book. It will, it will bring a smile to your face.
I guarantee it. I listened to it recently and. It’s a very cute story about some penguins, and it will make you smile and give you that warm feeling inside, but actually the message that it’s delivering it’s very strong. And, you know, I challenge anyone that hasn’t experienced what the narrative of that story is. And the second book is from a lady I’ve worked with before, a lady called Aminada, and her book is called Transform Your Business.
And again, it’s an excellent book. It’s digestible. So much so I read it and, you know, it’s broken down into into into steps and stories. And those steps and stories are focused around the various phases of change. So, you know, they are grouped together. In a way that it becomes it can be a bit of a reference manual for you, once you’ve read it, it’s by all means, pick it up and read end to end.
But the actual value for me has been referring back to it and just reading that particular step or that particular set of steps to sort of refocus and sharpen your mind when dealing with organizational change, resistance. The third is a new book, and it’s helped me massively in get my head around some of the systems engineering and complexity topics. And that’s written by John Holt, who is one of the partners of Scarecrow Consulting and his book, Systems Engineering Demystified.
And its systems engineering is something I’ve dipped in and out of. I’m by no means a systems engineering expert, but it’s been very helpful to me in coming up with my take on software systems engineering and PLM meet and to that and I’m working with a colleague of mine who is a systems engineering expert. And we’re looking at specifically focusing on the interface between systems engineering and PLM. And that book is becoming are also reference manual.
So that the three books that I would recommend. But, you know. It’s not all about reading, and then there’s other things like TOGAF and IFL and I believe are fundamental to tackling this PLM issue and beginning to have the conversations with customers, IT departments. You really do need to speak their language. And when you’re looking at things like transition strategies of a PLM system from having to prod, then adopting a ITL approach I believe is the only way to do it.
And breaking the PLM down into bite sized chunks, as we’ve already discussed my go to process for that is embedded within TOGAF. So I can only recommend reading around those subjects or getting trained and accredited if it’s something that you’re going to take seriously.
Nick, thank you very much for those. I’ve read the first book, but I didn’t know the other two. So everything goes down now. Thank you very much. It was a great interview. And do you have still any final thoughts of words or wisdom you would like to share?
Again, for those who know me, I’m no philosopher and what I would really like to say isn’t probably appropriate for a podcast, so I’ll try and keep it clean. But the something that sort of resonates with me is that this is going to sound really corny, but it was from Aristotle and one of his statements was the whole is greater than the sum of its parts. And that, to me, bring bells with PLM because there’s a lot of independence between PLM and yes, you could attribute a business case for each one of those.
But when looking at things like PLM, you need to look at it as an overall thing. It’s not a summation of individual bits. You really do need to look at it as a whole because that’s where the greater business benefit is for the customer who’s deploying a PLM system. So, yeah, other than that, I’d say be brave, go big or go home.
OK, that was great. Thank you for those words and it’s been great having you.
Thank you very much for the for the entire time I enjoyed.