Episode 7: Steadfast Consistency: Delving into Configuration Management with Martijn Dullaart

Come join Share PLM for another podcast episode with Martijn Dullaart, the man behind the blog MDUX: The Future of CM and author of the book The Essential Guide to Part Re-Identification: Unleash the Power of Interchangeability and Traceability.

Martijn is CM2-P and CM2-S (CMII) certified and has a solid track record of introducing configuration management (CM) and product lifecycle management (PLM) best practices into organizations to achieve operational excellence.

In this episode, we will unpack:

⚉ What is configuration management (CM)?
⚉ The role and impact of CM in a business
⚉ The differences between PLM and CM
⚉ What are the business drivers for CM at C-level?
⚉ Winning board support for CM and PLM initiatives 
⚉ Challenges and rewards of working in CM and PLM
⚉ Breaking down silos and uniting diverse teams in CM
⚉ CM as a distinct business element
⚉ The importance of training and education in CM
⚉ Part Re-Identification (book) as a valuable resource for CM practitioners
⚉ Martijn's blog posts


RESOURCES:

⚉ (Book) The Essential Guide to Part Re-Identification: Unleash the Power of Interchangeability and Traceability - https://mdux.net/books/
⚉ IPX Training - https://ipxhq.com/training/cm2-certification-courses/about-ipx 


CONNECT WITH MARTIJN:

⚉ Website: https://mdux.net/
⚉ Linkedin: https://www.linkedin.com/in/mdullaart/


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:00] HELENA:
Hello, everybody. Welcome to Share PLM's podcast. Today, we are very excited to have with us Martijn Dullaart. Hello, Martijn. Welcome.

[00:00:21] MARTIJN:
Hi, Helena. Thank you for inviting me.

[00:00:24] HELENA:
Very good. And Martijn is a special person for me because I have been following him for some time. And this is the first time that we really get to discuss in the podcast.

[00:00:35] JOS:
Hello, Martijn, and great to see you here, yeah, as two Dutch guys meeting virtually. Silence.

[00:00:41] MARTIJN:
Yeah.

[00:00:43] HELENA:
Martijn is a business architect at ASML. So Martin, could you explain a bit what you do?

[00:00:51] MARTIJN:
Yeah. So basically, as an architect I focus on the improvement of the configuration management capabilities within ASML, and of course, IT is an important component. But for me, the main focus is also how can we change the minds and the hearts of the people to, to ensure that the configuration and the changes on that configuration are maintained properly.

[00:01:12 ] HELENA:
Very good. You can see why we have you here in this podcast. This topic is close to our hearts too.

[00:01:18] JOS:
Yeah, so you're saying changing the mind of the people and not an I.T. focus. It's a famous triangle people, processes, and tools. Are you also doing the processes?

[00:01:30] MARTIJN:
Yeah. So also involved in looking at processes. And I think in a lot of cases a lot of problems can be solved when you dive into the processes, even to the level of work instructions that in some cases are too detailed that people are literally shown step by step. What they have to do is sometimes it goes a bit too far because that basically limits the freedom of the people to fear or a little bit to the left, to the right, whenever that might be required. And I think looking at these processes and understanding the requirements of what the output should be. That should be the main focus first. Because if you start looking at tools from the beginning, the main focus will always be what can the tool do and not so much on what do you need to do? And that is also one of the big struggles I've always had in my career that it is often very quickly becoming a tool-focused discussion because that is tangible. While I feel that the biggest successes that I have seen in my personal career is that when processes were in the lead.

[00:02:34] JOS:
Okay.

[00:02:35] MARTIJN:
And a famous quote is also processes must lead, and tools must follow because if tools lead fools follow,  Steve Easterbrook who passed away a couple of years ago. He made that quote, and I think it still rings for me every time. So…

[00:02:52] JOS:
Okay, you're talking about your career. Can you give us some background of your career? Where did you start loving PLM or configuration management?

[00:03:01] MARTIJN:
Yeah. So I started actually at Atos Origin Consultancy Company implementing PLM tools. And at that time, it was mainly for me EMatrix. Of course, nowadays people know that there's ENOVIA. But at that time, it was still EMatrix from MatrixOne, and I did several implementations. And then, and at some point, I ended up at Philips Consumer Electronics, what it was still called at the time, and they had their own homegrown PLM system, which evolved from EMatrix, actually, but at some point there was no EMatrix anymore and everything was completely homegrown. And I was asked to extend that to not only support the engineering bill of materials and the engineering change process at the time, but also to include the manufacturing bill of material and the service bill of material and the communication to suppliers to make sure that everything got covered basically. And that was a nice challenge because you'd really dive into what users need and how you can make their lives easier and achieve the goals that they need to achieve.

[00:04:04] JOS:
So you really got the enterprise machine already for PLM.

[00:04:07] MARTIJN:
Yes, yes. And then after Philips, of course, at some point Philips decided to move to one PLM platform and for Philips it was Windchill, did some implementation work there as architect and as process lead, and then I moved to ASML in my current role.

[00:04:26] HELENA:
Very good. And you have been working at PLM and now you are at configuration management. Can you tell us a bit about what configuration management is?

[00:04:36] MARTIJN:
Yeah, I always say configuration management is the foundation for everything you want to achieve with Product Lifecycle Management. I think there is no PLM if you don't do CM. And CM is everywhere. So whether you are even aware of it or not, you are doing CM in some ways or form in a company. So the moment you have a part, yeah, you probably have an identification for that part, that is part of CM, of course. And when you do changes, well that is part of CM because CM is also about changing your configuration and facilitating those changes. So there are, uh, there is, the most, yeah, probably extensive open standard is a SAE EIA-649, at currently revision C and, yeah, it is quite extensive. It's one of the challenges that I always face is that when you are working in the domain of configuration management, you are working with every function in the company. And you are impacting all of these functions and that is from engineering all the way to finance because you have touch points with all of them because an engineer wants to process a change on only his design. And that change requires changes two parts to your configuration. So there must be a change and that needs to be a business case. Then you already touch finance, but you also touch the supply chain because if there are new parts going in, yeah, they have to understand which parts will be phased in and which parts will be phased out and they have to prepare the supply chain for that and the factory needs to be involved because they also will be impacted, et cetera. So it's very quickly, of course, touching a lot of these different functions. And that is, I think also the biggest challenge for configuration management. And I think also for product life cycle management in the most broad sense of product life cycle management, because you touch so many different functions, and to make an impact, you have to get alignment on all these functions. And I think for product life cycle management, just one thing. What I've so far seen for public life cycle management is still very much oriented to the engineering work preparation kind of area and not so much yet to other domains because the life cycle management of course goes way beyond. And I think that's also one of the reasons because it's easier to stay within one domain with a limited group of functions than to try to branch out and see how you can support all these different functions that somehow have all interlinked dependencies.

[00:06:56] HELENA:
Right. That's interesting. So you see product lifecycle management more centered on engineering.

[00:07:01] JOS:
Historically. 

[00:07:02] MARTIJN:
Historically, yes, I do see some steps out there. So I do see the, but I think historically, and I think it's still in many cases, there is a lot of focus or let's say more weight in that domain. But I do see, I'm talking to also other people around the world and and I do see some projects that are going beyond that original scope, so to say, but that's more hard. It's harder to bring product lifecycle management holistically in end to end in a company. Then just to focus on what is typically its origin, which is engineering and work preparation kind of area. I would say that means you are talking more or less to similar folks with similar backgrounds and that so the language is still similar, but if you have to talk to the supply chain to your people in the fields, to finance, to all these different functions, suddenly it's becomes a much more complicated story.

[00:07:56] JOS:
I was just thinking when you talk about the PLM tool Martijn that we don't know about the CM tool. I mean, so maybe that's also one of the benefits. If there is no dominant tool, you can spread across the organization.

[00:08:10] MARTIJN:
Maybe that's true. Although there are specific CM tools which are often in the aerospace defense world. But I agree. I think typically CM is solved with a different range that unique PLM tool, but you also need ERP tool. So it's not just one tool you need to solve the entire CM set of capabilities. And I think the same would be for product lifecycle management more and not from a tool perspective, but more from a capability perspective, you need a lot more than just a PLM tool. And that's why I think why there is also a misnomer in labeling a PLM tool, a PLM tool.

[00:08:43] JOS:
I think you've seen and maybe also heard the discussion with Yousef about federated PLM and also the trend of, it's not a single system anymore. It's really actual at this moment in the PLM world.

[00:08:55] MARTIJN:
I also liked his comment about, what was it, instead of single source of truth, a single source of change. I really liked that statement. Yeah, that comes close to your business, I think.

[00:09:06] HELENA:
Very good. So Martijn, you have been in PLM and now you're at CM. What are the differences in your view? We have talked a bit about this collaboration and different functions having to work together. What are the difference now?

[00:09:19] MARTIJN:
I think configuration management is not so much about the content. So when an engineer works, it's also about the 3D model for instance, the simulation that you have to do all this, all that content work that is part of that expert in that sense, that is not what CM is about. CM is about connecting the dots and making sure that all that information is controlled to the level that it needs to be controlled, and that in the end you have a configuration, you achieve in the configuration integrity that you need because not every business is the same. Yeah, the most efficient and effective way possible. And I think where P L M comes in, PLM is broader than just CM in my mind because PLM also it's looking into, for instance, model based definition. And when I talk, when I look at model based definition from a CM perspective, I only care about how do we manage that information? How do you manage change on that? But what you put in and how you put that in, that's for me, not really relevant. I don't really care. So that I leave up to experts in that domain. But I do have requirements of course, to ensure, well, how do I identify then that model, is that one thing? Is it, is geometry and PMI information? Is that one set of information or are there two sets of information that is where one set is based on the other set of information? How should I then identify it? How should I deal with it? How should I manage change on that information? And of course, a lot is depending also on the tools that are available for that. So certain tools have certain behaviors. So here, where for instance, PMI and the geometry information is put into one file, well, if that is in one file, it will be difficult to manage it as two different sets of information and therefore also treat them independently to some regard. Even though if you want to, you might not be able to. So these kinds of things, I think if you will go to the nuances, I think that's where you will find most differences. But in the end, I think foundationally, CM is the foundation for everything you want to do PLM wise. 

[00:11:18] JOS:
And this brings me to the question, it's a story I understand, but now when you talk at C-level, what are the messages that you say? What is the business drivers for CM? Why it's not only aerospace and defense that should do CM?

[00:11:30] MARTIJN:
Customers demand, I think. Customers demand quality. Customers don't want that systems are down for a long time and that we don't know what's wrong with it or we don't know which parts need to be used to fix it. Customers want to understand which upgrades will be available for a certain system, and if you can't tell them which upgrades are viable for your for the customer system, then you would have to open up that system to look what's inside. Then you have a very bad storyline. And I think that's, I think one of the main business case drivers also that CM is enabling that you have all, you always know what is in and should be in and what will be in a system at any point in time.

[00:12:09] JOS:
And, and of course this is valid if you have a competitive mark, but like ASML, if you don't have so much competition, does the customer choose?

[00:13:55] MARTIJN:
I think it, no, no, I think even in ASML. Customers don't accept that you're doing a subpar job. They will not accept it. So they will demand this also from ASML. And I think also from other companies and while we arem quite large in certain areas, not for all our products, so maybe for EUV we don't have a lot of competitors, but for our DUV business, we do have a lot of competition.

[00:12:42] JOS:
Okay, because I'm asking this question, I've seen many of those specialized machine manufacturing companies. Their R and D is focusing on always pushing the latest technology and they take it as a, as a fact that the configuration management is not done that well because they have to deliver as fast as possible. Customers want the latest features.

[00:13:01] MARTIJN:
Yeah. So that's always a trade off, right? So even for, yes, customers, also for ASML, but also in other businesses, they want latest and greatest, but at the same time, they don't accept subpar quality. So you have to balance that. And the only way to balance that is to have configuration management capabilities in place that allow you to tinker with that balance. So you can have like very rigid control, like you might have in aerospace or in the medical device industry, or you can give people a little bit more wiggle room. But you can choose the kind of setup you need for your business. But if you don't do it at all. Then it just becomes chaos because people start shooting changes and hoping for the best and just creating a lot of ripple effects and all these ripple effects start to compound basically and before you know it things go haywire.

[00:13:55] HELENA:
Talking about management and getting buying, you have explained us a bit about your career and you have been in corporate for a very long time, what tips do you have for people to sell configuration management to the board or even PLM to the board? I mean, at the end, it's similar topics we are talking about.

[00:14:15] MARTIJN:
Yeah, I think it all drives to what is the value for your business. So what kind of business are you in? What is the value drivers that your business have? And how does CM or PLM relate to those value drivers? Because if you can find a value driver that is very easy to link to your CM or PLM capabilities, then you can start making a small story about that to see how can you improve that as kind of as a proof of concept and show the value and then from there say, well, now we've created some more value. Can we use that part of the value also to do some more step ups and then slowly grow. You can't do everything at once. Uh, that's impossible. So you have to choose your battles. But I think looking at the value drivers for a specific business can help you identify what are the best opportunities to show the value of CM and, or PLM and start choosing what you want to change first.

[00:15:09] HELENA:
Very good.

[00:15:10] JOS:
And then there are other people, Martijn, I mean, I think it’s also you’re point of interest. How do you make them enthusiastic for configuration management like PLM? Also, people say the tool is blocking me. I cannot be creative. I cannot do my job. What are your secrets?

[00:15:27] MARTIJN:
So I think that it's a mix. There's not one special source that you can apply and it works miracles. I think it's, it has to do with the fact that you need to involve your customers. Yeah, your users, user base in projects and keep them close to all the decisions that are being made, the changes that you are proposing to the process, but also to the tools and how that will influence their work and their behavior. But also make sure that there is a sufficient training and follow-up available because you can just create a new process, you can create a new tool, but if you don't deploy it with real involvement, then it's just a click training, and that doesn't work. I mean, I've seen so many click through trainings that you say, well, click this, click this, and now you're trained. Okay. Yeah, I know what to have to do. And then suddenly, just one thing changes compared to the five clicks that you have to go through and then suddenly you don't know, right? So really understanding what the change is about and the underlying process before people even start using a tool. But also using the good tools with a good user experience. So I think, one of the things that ASML has done is implemente an impact analysis tool. And that tool is basically used to identify the impact of a change. So you, you literally see it kind of a graph being built up by users. So you're showing up this part is going to change. This part is going to change. By the way, this needs a new part number. This part is going to be backwards compatible. By the way, this part is going to be where we fade out to change, et cetera, these documents need to change, et cetera. All these kinds of things are these work instructions and we document that and that becomes the basis for your business case, but also the basis for your planning. And I think the way we implemented that, I think we evolved the user base from the beginning. Actually, we built a new tool recently to replace the old one because the old one was actually a proof of concept and never intended to become like a tool for 8,000-plus users. And suddenly, we had 8, 000 plus users and the tool couldn't handle it, but it was still proof of concept. And now we were actually building with some, some good technology stack, a proper tool. We've gone live with that, also using the CM baseline, as I wrote about as a foundation for that tool so that you can start going through not just the bill of materials, but also the bill of processes, the work restrictions, but also in a later stage that you can also see, well, if you're changing something in your functions or in your logical components and your requirements over there, how does that, that influence and trickle down to the work of the design engineer? And I think doing these kinds of things, not just the tools, not just training, but also looking at people and how they are using the tools and how they interact with one another, bringing them together making it a collaborative, effort. I think that really make these things successful.

[00:18:18] JOS:
Yeah, here I see a lot of similarity with what Yousef was saying is a, we don't expect the tools to serve our company and we want to have those customizations that are made for our end users to make them happy as a the main interfaces.

[00:18:35] MARTIJN:
Yeah, I've seen it in other companies as well. So in aerospace companies, I've seen exactly the same. When I visited an aerospace company in the past, I even saw that they used the exact same technology stack that we used for building our change application. So we have also change orchestrated application, so to say, to orchestrate changes. And they had to use the exact same technology stack to build it themselves. So it was very eye opening to see that we are not alone in this and also in the podcast with the Youssef it's so recognizable. I think this is where these siloed vendors are, these monoliths are still too rigid and too old school, so to say, to be ready for the future. That is why we are forced to do it ourselves.

[00:19:23] HELENA:
When we started the podcast, you mentioned bringing people together from different functions as one of the main challenges that you face in CM. Do you have some tips there? How do you bring these functions together? How do you get people from finance to understand people from engineering?

[00:19:40] MARTIJN:
I think it's, uh, it's about interaction bringing people together. Martin Hake, my colleague and I always talk about the triangle. So we say, well, we have all these expert domains, they have their peers and they work with their peers a lot, but they don't often go beyond their expert domains. And through CM, we want to bring them together in what we call then the cross functional domain where people need to work together and to make certain changes happen in certain processes. Yeah. If you talk about a business case, well, finance has a role in that. I mean you cannot ignore them. So if you have a project that goes, is about the business case of a change, then you need to involve all the stakeholders, including finance. And you put them on the table and you start discussing what are the needs, what are the requirements and do we understand one another? And I think that's the only way we as humans can collaborate is it's talking and interacting with one another and not just writing some document, throwing it over the wall and hope for the best. And the CM game, yes, we do have a CM game. Yes. 

[00:20:41] JOS:
...involving people, yeah.

[00:20:43] MARTIJN:
Yeah. No, the CM game is really fun. It's a, we actually in, at ASML, it was developed to create awareness for the supply chain management staff about effectivity as one of the concepts. But it has grown to so much more. And luckily I was able to make it open source and I know about different people now using the game also for, in their own companies to create awareness, at least I think. And it's a fun way to create awareness about CM.

[00:21:10] JOS:
I think Helena you should look at the CM game from Martijn and the team and maybe extended to a PLM CM game.

[00:21:20] MARTIJN:
It is easy to do, I think, because there are a lot of PLM related topics in it as well.

[00:21:25] HELENA:
Yeah, that's I wanted to ask you a bit about the industries because probably it's something we also do in other industries, but I haven't seen it so much as a kind of own domain in my past, maybe because of the main industries that I've worked with. When does CM become its own element in a company?

[00:21:45] MARTIJN:
I think it depends. I think in a lot of companies, historically, CM has grown from the engineering domain, like PLM, oftentimes even still, CM is part of the engineering department. In ASML, it's a little bit different. We have actually two departments. We are working as one, but we have two reporting lines, one in engineering and one in the supply chain. But it is personally, I think CM is like finance. It's like a main function of a company that you need to have to support the value stream functions. Because it is so crucial that you do CM right, because if you do it wrong, you'll pay in corrective actions. And the problem is, these corrective actions are always they don't happen directly after you make the mistake. You probably happen somewhere down the line. And for the people that experienced the pain, it's not always obvious what the root cause was. And so that is, uh, so for me, CM is more about being proactive in preventing things from going wrong instead of trying to fix things. And of course, there are a lot of CM folks that are on a daily basis running to correct the issues and have firefighting. And that probably is also due to, I think, a lot of cultures where firefighters, and I don't mean the real firefighters, but the company firefighters that fix company problems, are rewarded more than they should. Yes, they solve the business, and urgent need in the business, but yeah, probably that's because you were hired to do so. So good job, but it's not special, but somehow people get more credit for fixing a problem than preventing it. And because that's not always visible. And I think that is one of the struggles of getting people to do the right thing. Cause if you are rewarded for fixing the wrong thing, then how do you ensure that people do the right thing?

[00:23:37] JOS:
It's interesting. We like firefighters.

[00:23:41] MARTIJN:
Yeah. Who didn't want to be the firefighter. Right?

[00:23:43] JOS:
Yeah.

[00:23:46] HELENA:
Martin, if you could go back in time, what advice could you give yourself when you first got into the CM world?

[00:23:55] MARTIJN:
I would even go a little bit further back because I first got in the PLM world without a lot of CM knowledge. And I would give my advice, get CM training as soon as possible, because in universities there's not a lot of CM training. There is some engineering training, but there is no CM training. And I think to be a good engineer or in whatever role you will be in I think some foundational knowledge of CM is required to be really good at your job. 

[00:24:23] HELENA:
How can you get CM training?

[00:24:25] MARTIJN:
There are different companies providing that. So I got mine from IPX. That's a CM two model that they train. And they also provide the SAE EIA-649 trainings. But in my case, because also ASML and at Phillips, we chose for CM two as the model that we followed, we got called that training. And of course another option is to read about it. There are a lot of books about configuration management. There is even the standards that you can read. There are even guidance documents on how to implement these standards. So I think there's a lot of material available to get knowledge. But it's finding the one that fits your needs. Because if you're not doing CM2, but you're doing the 649 and probably you have to look more at what providers are available for me to get that training.

[00:25:13] JOS:
Interesting. You say read the standards Martijn, I think the same for PLM. If you read the academic books, they are good for going to sleep but they are not good for a reference when you have an issue and have to read about on the topic.  

[00:25:27] MARTIJN:
No, that is true. I think that's why I personally like CM2 a lot because CM2 is not just telling you what needs to be in place, but also gives you details on how you should implement certain things. So for instance, the change process also at ASML is based on the CM2 change process and the roles that are defined in there and the steps that are defined in there. And they, they go in pretty much detail. They even offer standardized forms that you with a certain attributes that you need to have to make that process useful. And of course they, you have to tailor it to your needs, but you already get a good starting point to start tailoring. And that's personally what I really liked. And there's a lot of reference material on what problem requires what solution.

[00:26:11] JOS:
I'm glad you're so modest, Martijn, because I also, you wrote an excellent book recently, Part Re-Identification.

[00:26:19] MARTIJN:
Thank you.

[00:30:05] JOS:
Can you tell us something about, because when I read it, I think, why? Why we don't have this in school like you said, like, CM?

[00:26:28] MARTIJN:
Yeah, I wish I could have gotten the information that I put in my book already during my master studies, but unfortunately that was not the case. I also didn't intend to start writing the book actually, or a book. As you know, I write blog posts and the intent was to write a blog post about part re-identification. And I was doing research about the topic, finding out all the information that I could find. And at some points I had so many snippets of information and search snippets of text that I worked out and I collected those who will. Ooh, that's a lot of posts. If I would start writing posts, I'll be writing the idea posts for about two years. And I didn't want to go there. So, okay. That was the moment I decided, okay, let's see if I can format this into a kind of a book. And I started thinking about the chapters, about the structure, about what I wanted to share. And you've read it. So yeah, you're better just than me, of course, about the book. But I personally, for me, I really learned something. And that was that in many of the trees and my, many of the questions that I see out there to deal with re-identification the main focus is always on the most difficult ones. That is something fully interchangeable or not after the change. And it's related to form, fit, function, and I now also included interface as one of the aspects because I think that was one of the things that I was always had difficulty with. But there are a lot of questions you can ask yourself whether re-identification is needed without answering the complex ones. If it's never been produced, if you never shared the documentation with the supplier, then probably you're quite safe to just do a revision change on the document and then you're done. But if you already send out an order, can you still do with it? These kind of questions are way more important. Actually, is it interchangeable or not? Because that makes it sometimes already difficult to communicate certain changes because in some companies, changes are communicated by the fact that you send a new number. Not a new document because it depends also on the maturity of your organization, the maturity of your supply chain. So all these things matter. And that's for me, it was a big learning point to realize that a lot of the decisions that I've seen didn't highlight that enough in my perspective.

[00:28:40] HELENA:
Just from the outside, what do you think people can take from Martijn's book?

[00:28:45] JOS:
I think, as I said, Martijn said, it's a great summary of maybe 40 blog posts because he is addressing it from different sides, very understandable. And I think if you are in a company and you are struggling with it, you find your use case there in the book there are even exercises in. So Martijn remains a teacher.

[00:29:07] HELENA:
Mm-hmm. . Very good. And Martijn, I also have a question for you. You mentioned writing and writing blog post, and I think following some of the blog posts that you've been writing for a while. What did you decide to start writing?

[00:29:21] MARTIJN:
I think if I remember so, I realized I had a certain knowledge build up around configuration management and a lot of people were coming to me for with questions about configuration management and how to deal with that. And also when I was looking myself, of course, I knew the blog of yours and of Oleg and of some others, but they were indeed much more PLM focused and I wanted to see, well, I couldn't really find a CM focus blog unless it was software configuration management. And that is for me, like a subset of CM but I wanted to look at more holistically at CM and I couldn't really find a blog and I started writing just a few posts for myself. Not posting anything, just seeing if it was something that could work. And then I decided to just start posting the first and then the second and then slowly, yeah, I realized that I was able to give people a back a little bit of the knowledge that I gained from a lot of other people. And yeah, I think, that's for me, one of the main drivers for me, just being able to give back from all the people that I've learned.

[00:30:31] JOS:
And I think, Martijn, I think we have the same experience by blogging, you're even also pushing yourself to understand even better because you have to explain it.

[00:30:42] MARTIJN:
Yeah. Yeah. So a lot of concepts that I try to apply in my work, like for instance, the CM baseline, I first wrote the blog posts before I actually wrote the requirements documents for ASML. So it is because I sometimes need more time than I have during my daily work. Just to start thinking and actually, how can I make this worded in a way that it is useful and understandable for a lot of people, not even in the requirements terms, but just in a storytelling term. Because if you can't story-tell the requirements are still useless because it's nice to have a set of requirements, but you need the story to have the context to go with it. And when I wrote the first two, I think I already written like the first three blog posts, I think before I actually started posting about them. And that's also about the time I started actually writing requirements for ASML about it.

[00:31:39] JOS:
Right.

[00:31:40] MARTIJN:
So it helps indeed also learning yourself. Yeah,

[00:31:45] JOS:
Exactly. Yeah.

[00:31:46] HELENA:
Very good, Martijn. I think we are coming to an end. What would you, what do you hope listeners will take away from this podcast episode?

[00:36:34] MARTIJN:
I think I would say if you're in the business of PLM and you have not been CM trained, I would say find the CM training that is relevant for you. Because I started in the PLM business and for me, it started to make way more sense the moment I got training in CM. Because for me, there are so many fundamental principles within CM that are like the foundation for everything you do in PLM, and of course, you learn about them when you do PLM, but it is not like, it's all the separate puzzle pieces. And when I was doing the CM training, if all these puzzle pieces started to come together and got all the connections and that for me was very valuable. So if anything, I would say, if you're working in PLM also don't forget to get trained in CM as well.

[00:32:40] HELENA:
That's a clear call to action. Thank you very much.

[00:32:44] MARTIJN:
Thank you.

[00:32:45] JOS:
Okay, then, thanks, and I look forward to a future discussions that we had discussions in the past about the model-based future. Also, another topic maybe for another podcast.

[00:32:57] MARTIJN:
Definitely.

[00:32:58] JOS:
Yeah.

[00:32:59] HELENA:
Thank you, Martijn. Have a good day.

[00:33:01] JOS:
Okay. Thank you.