Episode 6: Revolutionizing PLM: Insights from Yousef Hooshmand

Come join Share PLM for another podcast episode with Yousef Hooshmand, a prominent expert and pioneer in PLM. 

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.

🌐 Website: https://shareplm.com/ 

Transcript

[00:00:01.050] - Claire
Welcome to the Share PLM podcast, the show that explores the vast universe of product lifecycle management.

[00:00:11.810] - Helena
Welcome to another exciting episode of Share PLM's podcast. I'm your host, Helena Gutierrez, and I'm here today with our podcast co host Jos Voskuil. In today's episode, we have the great pleasure of welcoming Yousef Hooshmand at. Yousef is the PLM lead at NIO. He is a well known expert advocating for Federated approaches in PLM. He is a true PLM trailblazer, someone who is at the forefront of changing the way we do PLM. So welcome, Yousef. It's an absolute pleasure to have you here.

[00:00:42.740] - Yousef
Thanks, Helena. And thanks, Jos. I'm honored to be here with you.

[00:00:47.490] - Helena
Maybe before we start, can you please introduce yourself and your role at NIO?

[00:00:52.670] - Yousef
Yeah, my name is Yousef. My last name is Hooshmand. I am, let's say, lead architect at NIO. And as a global lead architect, I have a responsibility to design the NIO PLM landscape and implement that new landscape. There's similar activities that I have done also in my previous job. And since 15 years I am in the PLM domain. I have done also my study, my PhD in the same domain. And at that time it was for the Siemens Energy in Dusburg, Germany, and now working for NIO. If you don't know, NIO is a Chinese battery electric car producer.

[00:01:33.470] - Jos
Hi, Yousuf, great to see you again. I think we also talked in the past in the PLM Global Green Alliance. My first question to you is what make you interested in the area of PLM? What drew your interest?

[00:01:45.650] - Yousef
The way we try to organize the work, it's both at a process and also at technology level. It was what's really interesting for me, it was in 2007 or 2008 that's for the first time I was in contact with PLM in one of the courses of Professor Under at Technical University Darmishtat. And immediately I say it could be something that I can do for 30, 40 years. The way we can optimize, the way the people work, the way the people use the tools and the holistic consideration of end to end the philosophy of PLM from the design or from the requirements up to the recycling or reuse. Considering this big picture, it was what was really interesting for me.

[00:02:29.580] - Jos
So it's interesting because I think you're one of the first in the podcast who really started a career with focusing on PLM, also with an education on PLM. A lot of people roll into it because they are expert in something and then they get the job.

[00:02:43.970] - Helena
Very interesting. And you mentioned you said that what interested you about PLM was the notion of organizing the world. How successful have you been now? That was the dream. But how about the execution now after how much experience did you say you had? 20 years already? 30 years?

[00:03:00.990] - Yousef
Yeah, I think let's say about 15 years. If you consider the time that I have done my PhD and also later at Mercedes Benz and now at NIO. In total it is about 15 years, 14-15 years. And changing the processes- it wasn't maybe so successful to changing the processes because there are a lot of challenges in process change. We can easier change the tools than the processes. I bring one of the examples that I have done at my previous job is that who analyze the value stream and analyze what's happening in one end to end processes and then says okay, this is your pains. We can eliminate the pain points and provide you a tool that is really for you. And I can talk about it. It is for example, was configuration management. It belongs to the PLM. Configuration management belongs to the PLM. But when we consider PLM as one system, it was very painful to work on them. But as soon as we consider PLM as a landscape that consists of different tools and different applications, then we start to think, okay, what we can do for you? The domain of the PLM or configuration management domain, the user of this domain, how we can satisfy your needs?

 
[00:04:13.420] - Yousef
We didn't change much the processes, but we eliminated the pain points in the processes that they already had. And at the end we had a tool that satisfied the needs of the users and not satisfied the needs of some technical monolith PLM system.

[00:04:28.070] - Jos
It's interesting you're mentioning the focus on value streams. I think that's the modern way of thinking at PLM. But I think especially in the automotive area, there's a lot of dependency on legacy systems. How did you combine, I would say, those two different approaches because value streams is very modern. I would say also the system of engagement. Yes, automotive infrastructures are very much, sometimes even mainframe based.

[00:04:51.420] - Yousef
Yeah, exactly.

[00:04:52.910] - Jos
So what did you do to make those users happy in configuration management?

[00:04:58.750] - Yousef
As I said, this is published already. It's not something that I'm talking from internal communication or internal information. Regarding configuration management, the work has been done in three systems. One of them was in Metaphase in Alt Siemens PLM system. Two other aspects were done in some mainframe solutions. Dialogue is known and for example, configuration management was scattered in three different system, three legacy systems. And what we have done was based on modern approaches like domain driven design and Onion architecture. That is also in software development you may heard of. We tried to analyze what happens, what the user is doing in each one of these legacy systems and migrated the functionalities and the data from that legacy systems to new domain application. You may say, okay, how the migration went. First we start with read operations. It means the data stays in the legacy system. When the functionality of RIT operation, as soon as it means the master is still legacy, then when you have the stability and the confidence, then the master will be this new domain application. That is created, the data still will be pushed to the legacy systems. It means the tables that they used to have, some let's say tables of configuration, et cetera, that table still exist, but the creation of that information and everything else altering happens in the new domain application, in the new software application.

[00:06:24.410] - Yousef
And in this way then we can have a smooth transition. It's not a greenfield that we can say easily transit. No, we need to keep the processes live and keep these legacy systems also in place. It means the legacy system still stay there. When we migrated more functionalities, more data and more domains in new applications, piece by piece, we can shut down that applications and that functions in the legacy systems so that the transition stays smooth.

[00:06:55.010] - Jos
Wow. It sounds like a very technical adventure, but I think you didn't do it alone. And how did you come into this mission? Who were pushing you to work on this and what were your challenges?

[00:07:07.350] - Yousef
As I said, I don't want to go in details what was the decision process, but you see that you cannot cope with the challenges you have ahead and no really monolithic PLM system that exists in the market can satisfy your needs and what's the state remaining. You say we developed it ourselves. It means Mercedes are now new, they are not PLM produced, they are not PLM software provider. But because we don't have the capabilities that we need or the flexibility to change not only the functionality, maybe the functionality exists, but if you want to change something that's adapt to your processes, it is a nightmare to get it done. Maybe you need six months or one year in best cases to get that things implemented. And because of that pain points and because of that huge amount of customization, there wasn't other way of working. And therefore the decision was we build our own PLM landscape. And this was a strategic decision not done at, let's say some team level or department level. It was a CIO level that decided and says yes, it is strategic for us, we work on it the same at Mercedes and now at NIO.

[00:08:17.990] - Yousef
It is a CIO level decision. We are to go and to consider PLM as an important thing for the company. Actually at NIO it is also at a level of Vice President. It is discussed and we push forward. And therefore if you want to have a landscape that help you be successful and help the company cope with the challenges ahead, then you need that level of decision making and that level of support. Otherwise this is just trying to fix small things that will not work at the end.

[00:08:50.070] - Helena
I have one question, Yousuf, because I'm a bit new to these concepts that you are introducing. When you explained before that you are migrating data to the new systems, how can I imagine? Is it so that the users are working in the new systems or part of the users for part of the functionalities are working in the new systems or are they still working in the old systems?

[00:09:12.130] - Yousef
This will be a transition phase. For example, the users want to do something. There are some functionalities that we provide in the new system. They immediately can come and start working in the new system. The old system will stay in place in case something goes wrong and we need to switch back. But in general they start with in the new system. In the beginning, the master of that data was the legacy system. As soon as we had the confidence in the new system, then the master changed from the legacy system to the new system. Still we pushed the data from the new application to the legacy system so that that table that used to have the data, let's say configuration data, part data, whatever data, they still have that data so that the pipelines doesn't break. Let's say in the car company they produce about, let's say 2 million cars a year. You cannot break that pipeline. Say, okay, three weeks, we don't have a pipeline. No, it's not going to work. Actually, the development of new application is easier than keeping that pipeline alive. We have more challenges of thinking how we can fix the things, how we can introduce new functionalities and new applications in the ecosystem and at the same time keeping everything intact as much as possible so that the processes and the manufacturing goes forward.

[00:10:31.610] - Helena
I have one more question. How do you govern that change of master system? When you are moving the master into the new system, do you prohibit users to change some parts of the data in the old system or are you leaving it open?

[00:10:46.160] - Yousef
No, it means if we introduce the new functionalities in the new system, then the users are forced to work in the new system. But we don't force them. They love to go to the new system because it is so user friendly. And in the development phase we eliminated all the pain points and so that they eagerly go and work in the new system. Not they wait till that system is ready that we have test users for in the beginning, but at some point of time. Then you say okay, this is a new system that you ask for. We developed it together, please use it. And they just immediately go there. It means the data will be we have the concept of single source of change. The data can be changed only on one place, but multiple source of access or multiple source of truth. This was introduced also in the paper that I wrote last year. Single source of change and multiple source of truth.

[00:11:40.110] - Jos
That's an interesting terminology. A single source of change, not a single source of truth. I think this is often mixed by many people and they still dream. There is a single source of truth.

[00:11:51.740] - Helena
And you mentioned that through the process of this transition you already start engaging with users so that when they are ready to move they will actually adopt the new system. Can you give us some insights on how you conduct that process?

[00:12:05.910] - Yousef
There are product owners in PLM and there are some, for example product owner, configuration management and product owner CAD, et cetera, et cetera. And there are these domains that exist also. The domains exist also in monolithic PLM systems and all the product owners are from the It departments. What we change is that there is a product owner in the IT department, there is a product owner in the business and these two together are responsible for that product. And we name it product because it is a real product and it is not just some functionalities or features and if it is successful, both of them are responsible have done it and if it fails, then both of them are responsible. In this way there is no finger pointing of you have done this, you have done this. There is business department and It department that work together. The responsibility of product owner in the business is to gather enough information and to develop these MVPs based on the user feedback. Even a small functionality will be discussed with the user. Where to place a button to click on will be discussed with the user. In that way the domain owners and those who really work with the domain are designing that tool together with the It department and the PLM department.

[00:13:13.810] - Yousef
And then at the end we have a solution that they really like to use. Sure, there is always something to optimize, there will be always something that okay, we thought it worked in this way, but it's not good then optimize it. But because we develop it ourselves, let's say together with partner companies, partner solution providers, some software developers, then we can easily adopt it. We can easily change for example, interfaces, the back end, et cetera. And we are not anymore independent on, let's say some big monolithic software solutions that any change you need to test 200 other use cases to be sure that if you change something still everything else works.

[00:13:52.010] - Helena
That's interesting, this concept of product owners, can you give us an example of products?

[00:13:56.380] - Yousef
When you talk about products there are different products. You can say the domains or the products. For example, configuration management is a product for itself. If we consider, for example, let's say other things like change management, it can be seen also as a product. We can see, let's say the functionalities related to CAT data handling. This is also for itself. We can consider that product. It depends on the company. At Mercedes we had about 16 as I remember, domains or products. At NIO it is different and my current company it is different number of products or domains based on the needs of the users because the culture is different, how the people work. Still more or less they are similar. We have configuration management, we have CAT, we have exchange, data exchange, et cetera. Sure, some of them are more business domains, some of them are a little bit more, let's say technical domains, but still both of them are necessary. You cannot say only we want to have business cuts, it wasn't possible. And for us the goal of having flexibility is more important than having only pure business capability cuts of the system.

[00:15:04.320] - Yousef
Again, also for previous jobs everything was developed or is going to be still in the process. They were developing everything. They are replacing old legacy PLM system. In my new job at NIO we are not going to replace, let's say Dassault. It will be used as some core capabilities, some, let's say CAD data handling or some other aspects that in Dassault system exists. Enovia system we are using it, but all other domains will be developed by ourselves, together with our partners companies and will not be anymore developed on top of, let's say Enovia system. We will use Enovia but not anymore as a center that everything else going to be on it and customized.

[00:15:45.950] - Jos
So, interesting point. More or less if I translate it Yousef, you say PLM vendors, stop building processes and best practices in your tools, make it flexible, available and we will build a landscape on top of the different systems that exist. Would this be a recommendation for car companies or would it even be a general recommendation?

[00:16:09.110] - Yousef
The final goal would be that we have a PLM landscape that consists of modules of applications that are replaceable. If one cannot satisfy our need, we can replace it with other vendor. As I said again, why Mercedes decided to develop its own application? Because there wasn't anything else that they can use. There was monolithic PLM systems. Sure, and if they wanted to introduce them, they needed to, let's say, customize it and write another formal units of lines of code so that it satisfied their needs. And the same is at NIO that I am now lead architect responsible for the design of the new landscape. Either you use a PLM solution that we have Enovia and always customize something on top of it, or you say okay, Enovia has some good capability, we use it. That's right. But everything else that we want to have new functionalities, let's say how to handle MBOM, how to for example, doing configuration management and many other aspects, or prototype BOM or really many other domains. About 30 domains we defined at NIO we will do it separate from Enovia. It will be interaction, we have interfaces that work with them.

[00:17:21.650] - Yousef
Why we are developing these things ourselves? Because you cannot buy them from the market. Really? Believe me, no one at NIU or Mercedes or other car producer or not only car producers, other companies like to spend so much money and time on developing these solutions if we could get them on the market. But such solutions doesn't exist. Therefore we build them so that we can optimize our processes, so that we are flexible at changing things and not anymore stuck with the systems that need one year to implement some new functionalities. And you need to test 500 use cases to be sure that everything works.

[00:18:01.210] - Jos
And here we are talking really about the massive scale of PLM operations. I heard the messages from other companies also. It's better to develop our own PLM infrastructure. But from the other hand, it requires a big staff, it requires a vision. And how many companies have this vision? How would you see this happening in other industries? Can it happen? Or is it something that is quite unique in the environment? For example of automotive with massive production?

[00:18:30.890] - Yousef
Yeah, it can be done everywhere. The good things is this new approach that we are following is based on MVP. You know, the example of SAP or example of Mercedes or know where I am working, example of NIU. No one come and says oh okay, shut down everything we want to start building and in five years we have new PLM system. No, you need to have a vision to say okay, what we want to achieve, where we want to be in five years or in ten years even. And then it says which pieces we can introduce now? For example, these which products and piece by piece replace them and at some point of time you replaced everything, or let's say not replace everything. Some legacy system still will be in place, but at least some crucial pieces are replaced. And you have your own landscape that is much more flexible. All other companies, based on their budget restriction, resource restriction, can do that. You cannot, for example, compare Mercedes with some small or mid sized companies. Sure, they have different amount of resources, but their landscape is also smaller if you consider it, and therefore the challenges is a little bit smaller.

[00:19:45.230] - Yousef
You need to consider that based on MVP principles, develop something new. Based on MVP principles, minimum viable products develop new domains, new domain applications, even in one domain. Bring the example also, both from Mercedes and also NIU, where I am now working. One domain replacement needs about one and a half to two years time. But we don't wait two years until that is finished. After three months, the first users can use the first functionalities in the new landscape and there's six months new one and so on and so on. After two years, then the old system is shut down. The functionality, not the data providing solutions. The functionality will be only in the new application. This is the piece by piece, step by step and a slow transition from old to new.

[00:20:30.490] - Jos
Exactly. I think we are quite aligned here. We are both, I would say fan of a hybrid environment. Don't migrate, but slowly build a new environment. As a company, you can support a hybrid environment, but the users, of course, they decide once they switch system, because they cannot work hybrid. I think something that the PLM world still has to learn that stop thinking migration, also the future data.

[00:20:57.570] - Yousef
No big bank, no big bank. And sure it's not possible. Big bank migrations are always not so successful.

[00:21:07.910] - Helena
Yousef, I have one question for people like me who are new to these concepts and are interested in learning more. You already mentioned that you have a paper, but what other resources are available for people to learn about these new approaches?

[00:21:21.050] - Yousef
As I said, there are other experts that also publish some papers you can read from Professor Eichner. I have also some other papers with some other colleagues like Michelle Fenning, that we talk about killing the PLM monoliths. There are actually enough information in LinkedIn or other places. If someone is interested, really, they can find interesting topics and interesting approaches, at least papers at academical level or examples, industrial examples about these topics. And also what I explained regarding what we are using domain driven design. This is something that since 2003 actually the people using it is not new. It is 20 year old approach that you are using. It means it is not lacking information. We have enough information and enough. It is just the commitment and this courage to do this change is missing. Why Mercedes have done this? Because it was a CIO at CIO level and a team that says yes, we can do it, we do it. Why at NIO we are doing it? Because it is at CIO level and at Vice President level that says yes, we can do it, it is necessary, we do it. It is just this is that's missing and not the people. There are so brilliant guys in the industry, in PLM and also software development that know all these approaches, know how to migrate old system, legacy system to the new legacy system. I learned them from also different books. They are existing. If someone interested, write me an email or message in LinkedIn, I will send a list what to read. Just the commitment and courage to do it is missing.

[00:22:54.230] - Jos
It's an interesting observation. As you say there is enough information. I think it's specialized information. I mean, you need to be interested in architectures, et cetera, where a lot of the PLM side is also people processes or establishing processes because they are not there yet or not even invented.

[00:23:15.570] - Helena
That Yousef is also mentioning people. From what I'm hearing, people is really the key to this. To get the board to talk about these topics and to get interest on these topics and to buy into it. What tips do you have for other companies? Yousef who want to get their board to understand PLM and give it the importance that it has.

[00:23:36.230] - Yousef
There is this approach that you say first of all they need to think about why they want to do it, to understand what happened. If they continue the same path that they are currently working on and what are the challenges and why they need something else. If they don't have this why, then as soon as they see some challenge and some problems, they give up. But for example, as I said, the companies that have worked on it says the understanding, the why is that they need this, let's say, flexibility that they are trying to have. They are seeing the vision that in five years, in ten years, in eight years, there are these challenges ahead of us. And if we want to, for example, wait for a monolithic PLM solution to customize it or to wait for a feature one year, six months, one year, one and a half year, believe me, two years or so I experience in some cases for some complex things, then it's not going to work anymore. If you see these why, make the why clear for each company? As I said, for some companies maybe they are happy with they are, let's say mid sized company or small companies, they have some solutions in place and it works for them.

[00:24:44.570] - Yousef
And their industry doesn't change so often because they are producing, let's say one ring and then in the last 30 years they produce that ring and in the next 50 years they will produce the same ring. I think they don't need really a PLM system. Also they can stick to what they have. But if they are working in an industry that is a lot of change inside it, they need to be prepared for that change. If not, they will suffer later or even go down. And this is this why.

[00:25:13.170] - Jos
So here you're talking like a real PLM consultant. If you don't change, you're out of business. And I think the automotive industry is always one of the leading industries in PLM. I mean, they have people thinking about the strategy. I think also at the C-level there is really the realization that they have to change, especially the, I think German automotive compared to the Tesla automotive. They see the difference between mechanical car with software or software on wheels. But yeah, those mid sized companies, sometimes they are even family owned. They won't or they don't want to see the change. They think we've always done it this way and software is making things more difficult. But that's not changed too much. And that I think is also one of the big challenges of PLM. There's so much difference in scale, but.

[00:26:01.250] - Helena
I think the concept can be applied for other industries as well. Maybe the change required is not really the underlying driver. Imagine for example, you are having a new acquisition of a new company where you are having different systems. That could be a case where this concept could be very interesting for companies, or companies that do have from the past, from the history. They are very distributed and scattered and they have different systems in different places. I see that this approach could be also very interesting for them without having maybe the chains as a driver.

[00:26:32.590] - Jos
I fully agree that the concept is perfect and I'm a big fan of it also. But as Yousuf said, it's the importance that at the C-level there is the courage to do it and the understanding.

[00:26:43.970] - Yousef
Yeah, exactly. As I said, the concept and the approach is not that someone just last year found it. No, it is more than 20 years old. It is just for the first time, maybe during last few years is implemented at some companies like Mercerdes Benz and now in NIO. I am sure that there are also some other companies that followed the same path and have done this, but not maybe published it somewhere or talk about it, because it is not really rocket science. It's just you have a legacy system. Piece by piece. You define the domains, you replace them in a way that first the data pipelines stay intact. It means even you don't touch the tables, because over some pipelines you push the data in that tables, everything stay the same. Just the functionalities move somewhere else and the master system will be somewhere else. Really, as I said and this approach of migration also I read it in books. It's not that I came up with this solution, no, I forgot the name of the books, but I can write it in the comments. There exists, all these pieces exist and we have brilliant software developers, brilliant people that can implement what we want.

[00:27:49.510] - Yousef
It is what the first step is that's missing at  C-level and the courage to do it and not just give up when something comes up or say wow, it is too complex. Yes, as a whole it is complex, but each step can be done. Each step is doable. And we have examples that we see that yes, it is possible. Maybe it needs eight years or ten years, but it is just based on minimum viable products. Every three months, four months, six months you have some software that can be used and make the life of the domain owners and domain users easier. You increase the productivity and efficiency in the company without disrupting everything, without breaking any process. And just piece by piece you replace old systems. And it is important. You need to stay on it and stick to it. Five years is the minimum for a transition. Is a minimum, really. At NIO you designed a five year plan and I hope that in five years we are done. I am optimistic because we don't have so much legacy system, but in other companies that they have a lot of legacy five to eight years. They need to have a transition phase.

[00:28:55.810] - Jos
Yes. And this is often, I think, also the challenge. I've seen some projects where we said it's a five or seven years transition and then the investor says that's too long, we want to do it in three.

[00:29:07.710] - Yousef
Yes, yes, if you say after five years you get the benefit, but in this approach, after three months you get the benefit and after six months other benefit, et cetera, et cetera. This is how it works.

[00:29:19.650] - Helena
Thank you very much, Yousef. I think we are approaching the end of the podcast. We stay with the benefits of the new approach, with the courage required to make it happen and with the agile methodology to deliver value in small steps. Is there any other takeaways that you want our listeners to have from our conversations?

[00:29:41.210] - Yousef
Nothing special. Thanks. First of all, I want to thank you for this opportunity to talk about PLM and our vision. Some request I have in the community, PLM community, we need to work on it to make this transition possible and doable for everyone, for every company. It is not just companies are responsible. Also the vendors will benefit from these things. If we can go in a direction that we have a standard data models, standard interfaces and a standard definition for, let's say, domains as much as possible, then the vendors can provide these modules or applications or software solutions and then it can help both the vendors and the users. And both of us will benefit because this current situation that we are in is not so helpful and future proof. Therefore also my last request is also going to I hope that we can collaborate together with vendors and all industry to move to the future.

[00:30:40.810] - Helena
That's a good call to action, Yousef. Collaboration to move things forward. Is there already any forum where you are trying to achieve this or is it something that needs to be established?

[00:30:50.270] - Yousef
There was some, let's say in that ProSTEP is the organization some organ that can be used as a basic so that different industries come together and discuss this standardization processes or hold. Actually we have enough standards also there. We don't need more standards, just we need to define where to put which pieces and hold to define these interfaces and collaboration aspects. There are some places there and in Next PDT in Paris, I hope we can talk about it more and maybe define what is the next step together with, as I said, experts like Jos and other respected experts in the industry.

[00:31:29.930] - Jos
I'm looking forward to this further discussion and as you mentioned, also the importance of standards. I think that's always a challenge to agree with a group of people on standards. But first of all, you have to bring them together. Let's see if we can do this.

[00:31:44.610] - Helena
Thank you very much, Yousef. It's been such a pleasure to have you here. And you are by the way, a very good teacher.

[00:31:52.050] - Yousef
Thanks for having me.

[00:31:53.030] - Jos
Thanks, Yousef. It was a pleasure again. Thank you.

[00:31:57.730] - Claire
Thanks for listening to today's episode of the Shareplm Podcast, where we bring PLM professionals together. Do you have any questions, topics, suggestions or know a PLM person who would be a great fit for the podcast? Let us know by visiting shareplm.com/podcast.