Episode 8: Beyond Tools: Guiding Sustainable PLM Journeys with Jonathan Scott

In this episode of the Share PLM Podcast, we are joined by Jonathan Scott, the Chief Architect at Razorleaf Corporation. Jonathan is a digitalization evangelist, promoting the use of Product Lifecycle Management (PLM) concepts and methodologies for discrete manufacturers. He is a former solution architect, project manager, and technical consultant with hands-on experience across multiple PLM and CAD platforms, including Aras, Autodesk, Dassault, and PTC toolsets. His strengths lie in vision and strategy planning, as well as in detailed solution development. Jonathan is also an experienced public speaker and enjoys delivering training on technical topics.

Here are the key takeaways from this rich conversation:

⚉ Jonathan’s Background & Strategic Thinking in SMEs
⚉ System Longevity and Requirements Management
⚉ Agile vs. Waterfall in PLM
⚉ Digital Transformation: Framing the Conversation
⚉ From Documents to Data: Making the Shift Tangible
⚉ Business Case and ROI: Showing the Money
⚉ Rehearsals and Business Involvement in Testing
⚉ The Communication Gap in Digital Transformation
⚉ People, Process, Data, and Technology: The Four Pillars

CONNECT WITH JONATHAN:
⚉ LinkedIn: https://www.linkedin.com/in/jonathanpscott/ 

CONNECT WITH SHARE PLM:
⚉ Website: https://shareplm.com/ 

Join us every month to listen to fascinating interviews, where we cover a wide array of topics, from actionable tips, to personal experiences, to strategies that you can implement into your PLM strategy.

If you have an interesting story to share and want to join the conversation, contact us and let's chat. We can't wait to hear from you!

Transcript

[00:00:12] BEATRIZ GONZALEZ:
Hello everyone and welcome to the Share PLM podcast. I'm Beatriz Gonzalez, CEO of Share PLM and today, as always, I'm with our lovely cohost, Jos Voskuil. And today we are very happy because we have a partner and also my old friend from Jos joining. So Jos how are you and tell us who is joining us?

[00:00:32] JOS VOSKUIL:
Hi Bea, I'm doing fine, mucho gusto. I'm practicing for the PLM summit at the moment, Spanish, and I'm happy to talk today with a long-term PLM friend, Jonathan Scott, which I knew from the early days of smart team. And we have been in touch since then, always discussing PLM related experiences and he always wear his characteristic bow tie, so I thought. We can't miss it. So first of all, welcome Jonathan, and happy to have you in our podcast. And please tell us more about you and your passion.

[00:01:02] JONATHAN SCOTT:
Yeah, Thank you. Thank you, Beatrice and Jos both for inviting me to join your podcast. It's, uh, it's exciting for me to be the guest instead of being the host for a change. We do our own podcast over at RazorLeaf, so it's different to be in this position.

So to give some information about myself. My background is in mechanical and systems engineering and I worked in the transportation industry and in the nuclear industry for a while before finding a career I really love in PLM. So getting into that, I was at a SolidWorks reseller briefly doing PDM for them, and I joined RazorLeaf back in 2001.

And I haven't looked back honestly. For those who don't know, RazorLeaf, we're a global provider of services and tools related to, I'll say digital engineering and manufacturing. I've done a bunch of different things at RazorLeaf from implementing smart team back in the day, like Jos mentioned, to working with multiple different PDM and PLM tools to leading projects and small teams.

And now I spend my time. Advising clients and marrying strategy with digital engineering capabilities. I think for those who know the term, a lot of people would describe it as enterprise architecture kind of work. So that's, uh, that's me in a nutshell.

[00:02:18] JOS VOSKUIL:
Okay, great. And yeah, you already mentioned the word strategy and you and I, we have been working a lot in small and medium enterprises, and we see the challenges of having a strategy because most of the people are too busy doing their day-to-day work. What is your experience with bringing strategy to the small and medium enterprises?

[00:02:37] JONATHAN SCOTT:
That's a great question, Jos, and I think it's a challenge for a lot of those organizations. Like you said, they are focused on the day-to-day because they have to be. Right? I feel this and live it every day at RazorLeaf, right? We started as a small company. We're still small or medium sized, and people wear multiple hats, they have a lot of responsibility. So it's a challenge for them to think about strategy. 

We try to do that when we engage with people by just asking them to take a minute and think about it. Just step back and think about where you're going to be. What are you really investing in? Whatever that tool might be that they're focused on, they're interested in the moment. And consider how long they might have it or might need it, and to let that, give them pause to say, wait, you know, yeah, if I'm gonna put my data in a system, or if I'm gonna start creating data in a certain format and it's about my product and my product is gonna last 10, 20, 30 years, maybe I need to take a moment and think about that long term and that long term thought gets them into thinking a little more strategically. 

So that, that's some of what I try to do to encourage them. But separate from that, I guess I want to add another point that, I guess it's advice that I'm offering to a lot of companie in that situation, and that is to think about what you're doing, whatever your project may be. If it's a CAD tool, if it's a PDM or a PLM system, if it's some other digital engineering system, think about the requirements that you have for it and how you're going to maintain those over time. Right? 

So if the system's gonna last for 10 or 15 years. How are you gonna keep the requirements up? Because they'll change something will be different. And if you lose track, what ends up happening, and I see this with a lot of clients and I think it costs them a lot of time and energy, is they then treat every new round of requirements or change in their business as a project, as a little discreet project, where they should think about these digital engineering tools like a program, right? 

Like an automotive or aerospace program, and how you're going to sort of maintain your system and your capabilities over 5, 10, 15, 20 years and evolve it instead of, okay, we turned it on, we started using it, we used it for a while, we didn't think about it, and then all of a sudden something happened and now we have to do a new project. 

So for me, that's what I think about when I think strategy for those folks.

[00:05:02] BEATRIZ GONZALEZ:
And do you recommend then an Agile approach better than a Waterfall approach to be able to maintain and update these requirements?

[00:05:11] JONATHAN SCOTT:
I do think Agile has some benefit, right? And that mindset related to agile of thinking about things not always sequentially and not taking some of the traditional approaches to projects is good, but I guess I don't advocate for pure Agile either because I don't feel like it fits well in the world of off the shelf software.

I've seen Agile have tremendous benefits when you're developing bespoke solutions to things, from the ground up and having the users involved, but I think it's a challenge when you've got existing software. Agile doesn't always quite fit there, so to me it's a blend in those.

[00:05:52] JOS VOSKUIL:
And coming back to the smaller and medium enterprises, I mean that's where we don't expect revolutions. And I think we both always talk about digital transformation, maybe internally, but perhaps you don't talk even about digital transformation with your customers. I mean, because they are on a journey and they don't want to hear the word transformation. How are you wrapping it in? Is it discussing the long term?

[00:06:15] JONATHAN SCOTT:
I think it's, to your point, it's different for different companies, some small and medium businesses they're doing what I would consider transformative things but not because they intend to, because they have a startup mentality or they have that sort of I'm disruptive mentality. They just want to go do what works.

And so when they see something new, they see a new approach, a new tool, a new technique. They're willing to try it, they're willing to experiment and go for it. And of course those people are easier to help. Of course it's not always easy with new techniques to help them understand what might or might not work because they are new.

But I think your real question there, Jos about how do you help people who maybe don't have an appetite for transformation, but they, they need something major, they need things to change. Um, it's a real challenge. There's a lot of conversation that needs to take place about what kind of outcomes they have in mind. What are they really trying to accomplish?

[00:07:10] JOS VOSKUIL:
Because somewhere we want to make the shifts from documents to data.

[00:07:14] JONATHAN SCOTT:
That's right. And people, that's an easy phrase to say, right? And I know what you mean when you say it. You know, I, I know exactly what you mean. But a lot of people don't, right? If you can get tangible with them, they start to understand it. When they say, oh okay, you mean not a document that is sort of, this container that is hard for people to access and understand and use to data that is somehow exposed.

My favorite example of that is requirements, right? People will have these very long requirements, documents, pages, and pages. If you could take each individual requirement and do something with it that's meaningful in terms of connecting it to other information. But when it's in a 50 page document, it's hard to do that.

[00:07:56] JOS VOSKUIL:
Exactly, and what about a 2D drawing?

[00:07:59] JONATHAN SCOTT:
Same thing, right? Yeah.

[00:08:01] JOS VOSKUIL:
But, yeah, this transition to data driven, I mean, is it something that you, as RazorLeaf are also guiding companies or are you looking for them? What are the best tools? Like the modern SaaS solutions are usually by default, data driven.

[00:08:17] JONATHAN SCOTT:
Yeah, it's interesting, for a lot of work that we do, we are there to help guide customers who have something in their mind already, right? We have a few customers who come to us with a business objective or a business outcome, and they ask us the best way to get there. But for a lot of things they have a target in mind and they want to know the best way to get there. And that's the kind of help that we're providing.

So to your point, people who come to us with a SaaS solution in mind or a solution that maybe looks at digital engineering data differently. They already have the concept of like, well, I like this better because the data's more granular. Right? Like some bill of material solutions that comes up a lot these days.

So for the customers who don't have that in mind, when they are asking us for more help with strategy, that is one of the things that we try to raise to them is that notion of you need to be on a journey to get to more data driven, and then we always have to give them examples to help make that clear what's the benefit they're going to get. Right?

One of my favorite ones is impact analysis, right? A lot of people understand engineering change, and how costly that can be inside an organization, and so helping them see that well your engineering change really is around what changed in the requirement and then what changed in the outputs, whether it's models, drawings, downstream and manufacturing, et cetera. And so many people, they just think of it as, I'm changing the engineering documents.

So when we can help them see if your requirements are data instead of documents. If your engineering content is data instead of, you know, multi-page drawings and other content, then your engineering change becomes clearer. It's even possible to start automating it and looking at things that you can do to speed up the process. So we try to help them see those examples to get them down that road.

[00:10:13] BEATRIZ GONZALEZ:
Also what I have seen is that people pretend to implement a process of engineering, change management in a system that in reality, they don't have it outside of the system. Because change engineering change request, you can do it in paper. So you can do engineer change order in paper. Right?

So, but if the business process, they don't have it, it's really difficult to try to pretend that system will define the process for you. And and it will streamline the unexisting process. So are you supporting also the companies to define the, for example, in this case, the engineering change process that switch for their business so they can take out the most out of the system.

[00:10:57] JONATHAN SCOTT:
Yes. I mean we absolutely help people do that and we see companies coming at it from any number of different directions. To your point, Bea, sometimes they come at it from a paper process. And when you try to do, I'll say the process analysis of what are you doing and why they really struggle to sort of decouple the what we do from why we do it, and that's essential to know what do you put in place in a digital system.

I think another thing that we see people struggle with sometimes is they want to bring that process, either paper-based or existing digital processes right into their new tool and they want the tool to do exactly the thing they used to do. And it's, you have to be patient and remind them. If you keep doing the same thing, you'll get very similar results. If you really want different results, you have to stop and analyze and do something different.

[00:11:47] BEATRIZ GONZALEZ:
Yeah. Totally.

[00:11:48] JOS VOSKUIL:
Right. And this remembers me at the item 9,000 processes that were very popular, uh, in the previous century to prove that you had a quality process in place in your company to deliver the right product. It was often manual or paper based. And I think one of the goals of the new PLM was, if you can implement those processes in a digital manner, then at least you had consistency and people doing the same thing.

But then comes the question, Jonathan, that probably suddenly you meet the CFO and says, show me the money. What about business cases? Are you doing business cases or are you also explaining the logic that it has to deliver money and storytelling?

[00:12:28] JONATHAN SCOTT:
It's a combination. My experience, and I've had a lot of experience on this topic over my career is that a lot of companies, at least in the US are very skeptical about someone outside of their organization providing any kind of financial information even, right? Because we get the question a lot about, well what's the return on investment of this system or this process improvement, or whatever it might be.

And we have provided a lot of useful information to companies over the years to help them support that. But so often it needs to be our champion inside their organization that has to go make that case because they just won't hear it from someone outside. Oh, they don't know. Oh, they have a bias. Oh, you know, and even someone like us, sort of vendor independent.

We're not really trying to do anything but support them in the best way we can, but they're still very skeptical of it. And I think there's another piece of that too that I often encourage people with when they do ask for that advice. And that is go to your finance people, go to that CFO and ask them to explain what arguments are valid to them. Right?

Because some companies will say, I don't wanna hear about internal savings. I only want to hear about hard cost savings, material savings. You know, time is not of interest to me, or engineering time isn't. I want to hear about new revenue. So if you get that information upfront to know what is a valid argument, then you can shape the case much better. So those are the kinds of things that I've done.

[00:13:57] JOS VOSKUIL:
Right. And when I discuss with companies also the ROIs, they're often not able to justify their own numbers. I mean, they don't have the visibility. But one of the numbers that they often have is the cost of non-quality. Because that is often very visible and they are quite ashamed of it. So they will not expose it to you, but many times that is one of the value drivers for a PLM improvement process.

[00:14:22] JONATHAN SCOTT:
Yeah, I remember that was one of my first interactions with ROI was when I was still in industry. Right? And we had a quality problem exactly like that. It's an example I've used probably with more clients than people wish that they didn't hear this example so much, but it was with a CAD tool at the time and it had to do with an update and file management where the files were and the problem was a drawing didn't get updated. It made its way out to a vendor. The vendor made the part and it was $100,000 of scrap. And this was 25 years ago. Right. And you know, it was a very expensive mistake, but it made a very clear point by using that story with people about a change that needed to happen to the way the process worked.

And I think you mentioned it a minute ago about it's storytelling. There are some calculations you need to do, but if you can explain the story, and it's a case that people understand, that makes a big difference in being able to make the point.

[00:16:22] BEATRIZ GONZALEZ:
And talking about the story that people can understand, have you seen system implementation that fail or don't success due that the people side is not taken care of?

[00:16:34] JONATHAN SCOTT:
Absolutely. At RazorLeaf we've seen plenty of projects that have failed. We've actually followed, we did a lot of this work back when we started implementations that failed and the customer said, look, I think this software still works, but for whatever reason, the project didn't get it implemented and we came in to solve the problem afterward.

And to your point, Bea in early years, a lot of it had to do with training. A lot of it had to do with knowledge of the system when they thought, the first implementer said, you can't do that. The reality was, well, you can, they just didn't understand how. 

So a lot of different reasons why things have failed, but your, your point about the people side, we've seen frequently and unfortunately we've seen on a number of our projects that ultimately succeed that it actually ignoring the people side, what it does is just slows the project down and makes it cost more money.

So we'll recommend to people upfront sometimes, you know, you need to have a communications program and not just a training program, but an education program. So there are a lot of elements that they need to have, and sometimes our customers, particularly if it's an engineering led or an IT led project, we'll say, yeah okay, we'll handle all that. Don't worry about it. We'll take it. And they take that scope of the project. 

We go to work on the technical piece of the project. And when the two are supposed to meet later, we find they haven't been doing it. Lots of people are uninformed, they're unaware schedules are missed. I mean, it's all sorts of problems that come out and then you have to stop and reset. It's cost everybody time and money, but ultimately you get complete. It's just they really aren't putting the right emphasis on it.

[00:18:14] BEATRIZ GONZALEZ:
And Jonathan, what would you say it is MVP for change management. What are the activities that needs to be done? Yes, yes to have a success not everything but what are the key activities?

[00:18:26] JONATHAN SCOTT:
Yeah, I think the most key activity is having an executive led vision and strategy from the start. So even if the strategy isn't entirely clear, if there's an executive who is willing to say, I agree to it, whatever that strategy is, and they communicate that vision, it's how much it has to be communicated, whether it's he communicates it or she communicates out to everyone, or whether it's a sort of a pyramid approach down the levels.

If that happens, so many of the other right things can happen, even if they're not completely organized. Right? It feels weird to not say training because training's always essential, but in my view, if that strategy and vision communication happens, then so many other things will happen. I shouldn't say automatically, but they'll remember that they need to happen because people realize, oh the whole organization is committed to this. The boss is paying attention. We need to do it right?

[00:19:25] JOS VOSKUIL:
And I agree with the fact that yeah, the boss has to communicate and to pay attention, and that is the why.

But I think also, it's crucial often that also the boss gets involved in the how, because sometimes they leave it to the others and then nothing will happen. I mean and I think that's the, the strategy we are looking for.

[00:19:44] JONATHAN SCOTT:
And I agree. I think the culture matters a lot in the company. To your point, Jos, because I have seen a few cases where you know the boss does do the why, and they're not intimately involved, but they do follow up. They ask questions. They want to know how are things progressing, and that can work in a certain culture.

But you're right, in other places, I think the boss has to ask the why. They have to be involved in the how.

[00:20:08] BEATRIZ GONZALEZ:
Jonathan talking about different cultures, what are the differences you see between Europe and United States as they are your main markets for your service, right?

[00:20:19] JONATHAN SCOTT:
Yeah. And you're right, we do, we work in the US, in North America and Europe. And I do see differences. I struggle to characterize them a little bit. I think I see differences in process, how comfortable people are with process and, changing that in the US there's a lot of desire to change a process even when it's not necessary.

In Europe, I think a lot of companies are more comfortable with keeping a process that's working, not feeling like they have to change it for the sake of change. But for me, a lot of the differences are larger across corporate culture, more than between certain continents and geographies.

And I see huge differences both places in how they approach projects like this. And they really influence success or failure of projects very significantly. So to me, that's the biggest thing. When companies really value their people and you see it in their culture, you can see that the adoption side of these projects is going to thrive. And when they don't, you see those outcomes too.

[00:21:20] JOS VOSKUIL:
And do you see any difference in size of companies?

[00:21:23] JONATHAN SCOTT:
I do, but again, I don't see it as correlated directly. Right? I see those cultures different in different sized companies, but I've seen some very large companies that behave like small ones that are more nimble, that are more people focused. And it's like from top to bottom, everyone's aligned on a goal.

It's harder in larger companies I think sometimes for that. But I've seen small companies which are quite dysfunctional that way.

[00:21:47] JOS VOSKUIL:
Okay. I want to come back to our story of transformation and as work a lot with assisting companies. I was curious about the big elephant in the room, the data migration. What are your experiences with data migrations? Are they discussed upfront? Are they big surprises? What can you guide us for companies to think about migration?

[00:22:08] JONATHAN SCOTT:
That's a great question, Jos. Yeah. So I think, migration is an important topic and it's one I, I feel like just came up recently in some conversations about digital thread and people saying, well, maybe you don't need to move data anymore, and that kind of thing. I should come back to that, but I, I think it's important for people to talk about it and think about it anytime they have a project in mind to implement a new system.

And the key question is to ask, why do they need some of this data? Like why are they moving it? And there's a lot of good reasons to need it. Regulatory requirements, the life of the product, the length of the life of the product, those kinds of things. But if you know why you need it, that drives a lot about how you move it across from one system to another.

And that's where really costly and important decisions are made. We do a lot of data migrations and understand those points and topics quite well, but you've gotta have that business discussion about why is it important, what would happen if you didn't have it? And that really gets you to the right approach and the right project to make it happen. 

But people also need to think about what some of the challenges are with their data too.

[00:23:17] BEATRIZ GONZALEZ:
Yes. And also after the scoping and analyzing the current data, what are the challenges on the definition of current data?

In my experience, I think it's very important to manage expectations because I've seen that people is have in mind that the data is gonna be perfect, migrated, and then comes the go live day and say, okay, my data cannot use my data, or some issues with the data. So I think managing expectation, what do you think Jonathan, in your opinion, how do you manage expectations in data migration?

[00:23:46] JOS VOSKUIL:
Uh, I have the same question. Are you ever going to say no to your customer?

[00:23:50] JONATHAN SCOTT:
Yeah. Yeah. I fully agree that that is one of the big issues, is the expectation that people have, and I think there are a handful of ways to deal with it, steps that you need to take along the way. And that it starts with at the beginning of a process, or maybe not at the very beginning, but early in the process.

Inspecting the data and having an honest conversation with the customer about what you find, right? You know, oh, the, the data is not as clean as you thought it was. Let's talk about what that means to the outcome. I think another important piece is involving that customer throughout the process. One of the things that's part of our methodology with migration is rehearsals.

If you rehearse multiple times and the customer is involved in inspecting those rehearsals. Then they sort of see it as they go. If there's a point where they say, wait, stop, we need to change or fix something. It's not on go live day that they find it. And I think, you make another great point, Bea, about when they go to use it, and again, they should figure this out in a rehearsal, but they should be thinking about how will my old data behave in my new system and process?

That's the key that a lot of people miss, right, is I could get the data moved over and I could look at it and observe it just sitting there and it looks fine. But the way the new system works, oh, there's a flag missing or there's data it needs or something. That means it won't behave the way I expect it to.

That's a dynamic thing. You don't find that out by just inspecting it. You find that out by trying to use it, and that's where those rehearsals are so important. So I think it's a combination of things that help you set the right expectation to get the best outcome.

[00:25:28] BEATRIZ GONZALEZ:
So rehearsal for you, Jonathan. It means also testing, like unit testing, system testing. So we involve the business from the beginning, right? Not only the IT.

[00:25:38] JONATHAN SCOTT:
Absolutely right. And that's a great point, you can do all the technical tests in the world, but if you haven't thought about what the business needs, what the business process is going to be, then you're likely to miss something. Right? And we do tons of testing for customers and with customers, but it is important to us that they are involved in that testing, right?

Because lots of times they would like us, oh, can't you test for me? I can, but I need to know what's important. And that's hard to know unless you're them.

[00:26:06] JOS VOSKUIL:
I think when we talk about this type of migrations it stays within the same data model scope. I mean, I have some very bad experiences from mainframes to, uh, modern object oriented environments.

One with, uh, smart team where I coach the reseller in Europe. They sold the migration for two months project. It became two years because every time we discovered the inconsistencies in the data, because yeah, you don't notice in the relational tables if the data is correct, you only see what you see on the screen. So my lesson learned here is that if you go from different data paradigm, don't migrate, try to connect.

[00:26:44] JONATHAN SCOTT:
Yeah. I It's an interesting point, Jos, because that that idea of connecting to existing data sets and not migrating, I think is a challenging one, when you can, it's good. I like that advice. Right? But so much gets missed today when people say, oh, just build out your digital thread and connect to that old repository.

Great. But can you keep that old repository running? Do you have the licenses to keep it running? Is it secure? You know.

[00:27:12] BEATRIZ GONZALEZ:
Yes, there are several questions to analyze and define the data migration strategy for sure.

We are approaching to the end of the episode. But before we'll wrap up, Jos do you have any final question for Jonathan?

[00:27:24] JOS VOSKUIL:
Yeah. I already shared one of my experiences with data migration, but Jonathan, you are also quite experienced in the PLM domain and experiences what you get when you don't get what you expect. So I'm curious, what is your biggest experience?

[00:27:38] JONATHAN SCOTT:
Yeah. I love that quote, Jos. I think that's, that's one of my favorites too, right? Because we often get a lot of experience that we weren't looking for.

I think my biggest experience to share has been about communication. That I've talked with a lot of leaders of organizations, of various education levels about PLM and digital engineering and that kind of thing. But the biggest challenges I face regularly are making sure that we understand each other. In communication and I'll, I'll give you a quick story for a, a client we worked with, in transportation. It was a reasonably mature organization, but they had a new CIO and we were having a conversation about how to put some of the PLM capabilities in place.

And he kept reverting to, and this is, you'll find this interesting Bea because it goes back to your question about Agile earlier, he kept referring to an MVP. Can you just put an MVP in place? And my answer to him was, yes, we can, but you have to have processes defined that you'll follow. Can you understand how you'll use the MVP with your existing processes?

And he just kept reverting to no, no, M-V-P-M-V-P. And we were missing each other. And it caused a problem in the project because we did what he asked. We did deploy some MVP capabilities. But there were no processes around it. And so on the day everyone was supposed to start using it, they said, we don't know what to do with this MVP.
So that kind of communication, I think is my biggest experience.

[00:29:10] JOS VOSKUIL:
Okay. Yeah. Great example. Yeah.

[00:29:12] BEATRIZ GONZALEZ:
Yes. And Jonathan, before we finish the episode, what's one of the key takeaways you would like our audience to remember?

[00:29:19] JONATHAN SCOTT:
Yeah. I think the thing that I, I hope people take away is that although these are technology related projects, they are not just technology projects. You have to remember a lot of other things and people is one. Right? Talking to you guys, it's a logical place to talk about the people side of projects.

But it's other things too, right? It's process and it's data, right? And I think of those four things, technology, people, process and data as all essential parts of these kinds of projects. And remembering that traditional approaches like Waterfall and a Big Bang, you know, release at some point and even Agile are not the right fit for a lot of these projects.

It's actually a combination of things and it's, it's pieces that you can pull from multiple areas, whether it's a little bit from Agile, a little bit from Waterfall, maybe a little bit from systems engineering. I think that I'm a fan of that, but it's find the right approach for your organization and your culture and keep those four things in mind.

That's what my takeaway is.

[00:30:21] JOS VOSKUIL:
Okay, great.

[00:30:22] BEATRIZ GONZALEZ:
Thank you very much. Thank you very much Jonathan for this great conversation.

[00:30:26] JONATHAN SCOTT:
Yeah. Thank you for having me.

[00:30:28] BEATRIZ GONZALEZ:
And thank you so much to our listeners. So if you want us to talk about any specific topic, please just write a comment or contact us. Jos and I in LinkedIn, for example. So also Jos and I will be joining the Share PLM Summit and also RazorLeaf, so we welcome everyone to join us and try to make the PLM world a little bit better with the focus on people.