Description
Key Learnings
- 1. Create a Business Case for a global PDM implementation project
- 2. Plan and setup a global project implementing PDM and common working methods
- 3. Manage local versus global demands moving in to one Common Data environment
Speakers
- MEMattias Lorvi-EricsonWith more than 20 years in large enterprise IT, I have a passion for global collaboration. Bringing people in under common processes and improving ways of working, have always been a driver for me. Lately, my work has been to bring our engineering community in to a common platform and common processes.
- JWJonas WicksellIn my role as a Business Developer I head Business and Process prestudies and assessments with our customers, leading up to suggestions and prioritization of recommended actions of improvement, creating solid Business Cases and justifications for investment decisions. I have 30 years of experience from this business both as a former Autodesk Employee, managing the Autodesk Manufacturing business in the Nordics and Baltics and as an Autodesk Platinum reseller focusing on PDM/ PLM and system integrations.
FREDRIK CLARSTEDT: Hello, everyone. Warmly welcome to IPCO's case study together with us from NTI group. So what can you expect from our presentation here today? We have a business case that we've done together with IPCO, and we're going to go deeper into how involvement with a C level, what preparation we've done to implement a global PDM/PLM system. Last but not least, we will share insights and keys from our global implementation of the OneVault.
So a short look at the agenda here for today-- we're going to start with some introduction. Then we're going to hand over to Mattias here that's going to do IPCO in brief. And from there, we're going to go deeper into why IPCO started this journey together with NTI, and then we're going to look at the Critical Three, the hows and whys, and the result and the way forward from where we are today.
JONAS WICKSELL: So about the presenters, I guess you will start, Mattias. Will you say who you are?
MATTIAS LORVI-ERICSON: Yes. Hi, everyone. I'm Mattias. I'm head of IT and OT infrastructure at IPCO, and with that, I'm responsible for all IT infrastructure globally. I'm especially supporting business in engineering platforms and industrial IoT, and my main focus areas lately have been process automation, information lifecycle management, and machine learning.
I have more than 20 years experience in IT management in large Swedish industrial enterprises both in Sweden and abroad, and my contribution to the Autodesk family is that I've been a AutoCAD trainer for four years back in the '90s. I believe it was AutoCAD 12.
JONAS WICKSELL: OK, thanks. Let's move on to me then, Jonas Wicksell. I have a role as a business developer within the NTI group, meaning that I'm heading different type of prestudies and unveiled the challenges and bottlenecks with our customers. I'm a specialist in the PDM/PLM area and work a lot about design standardization, engineering automation, and process improvement businesses. OK, Fredrik. Who are you?
FREDRIK CLARSTEDT: I'm the key account manager at NTI group, works a lot with PDM and PLM integrations. I have a background from the automotive industry. I worked a lot with global platforms so you can share data between different companies, been with Autodesk now for years, but before that a lot of other systems.
JONAS WICKSELL: So let's move on. Mattias, could you give us some insight in who IPCO are?
MATTIAS LORVI-ERICSON: Yes, IPCO-- who are we? We are a Swedish company with the headquarters up north in Sweden. We are currently in 30 different countries and only about 630 employees. And we are owned by an investment portfolio called FAM, which is the small portfolio of the better known investor, which is the Wallenberg family back in Sweden. And we have 120 years or so history of producing steel belts, which has been the main product for us over the years.
And of course, as a steel belt manufacturer, you need to grow into other businesses, so we grew our equipment business as well. So we are building machinery for the belts. And as a supplier of machinery to customers, we need to be in the aftermarket, so we tend to grow in the service and support area as well.
So the products that we have, everything evolves around the steel belt and various applications to make products on a steel belt. We have the double-belt presses, where we produce boards and mainly wood-based panels. We also have the rotor forms or the granulation part where we put small dots of different material on the belt, and either we cool it or heat it so it becomes better to handle.
And we also do steel belts for film casting where we are in the medical industry or the electronics industry where we have highly polished steel belts. And also, in food industry, where we freeze or heat food, we either do bake oven belts, or we do dry freezing of food or vegetables.
And with that comes a very vast customer spectrum, if you say so. We have customers in many different areas, and this is a subset of all these. We have chemicals. We have electronics. We have food. Sulfur is the byproducts of oil industry, and we think that is kind of for a greener planet. Our main products that we had earlier on over the years was wood-based panels. And during COVID, we saw that we have another product area that actually surfaced, and that was chocolate. So everyone wants comfort food in different times.
If you look at the history of IPCO, we started the steel belt manufacturing in 1901, and as I said, we have been around for more than 120 years. So we did the first equipment in the '90s and evolving the business ever since, so some mergers and some expansions into newer markets. But the journey with our former owners ended in 2017, where Sandvik, the previous owner, decided to sell us to FAM. And this is where I came back to Sandvik to do the carve-out to become one standalone company, IPCO, in 2018, and we did that in 10 months.
So that was short about company. So why did we make this move? We know that from the experience of group functions that all sites out there do not have the resources or the capacity to take over the workload when it comes to payroll, IT, legal, even engineering-supporting platforms. They are sales and services, so they were kind of left alone.
All the other functions they had they had with the cloud fee from Sandvik locally, so they were quite a lot left alone. And we saw that we need to do something in the engineering area as well to help the sites out there. Looking into the processes, we could see that it was not one, it was not two either. It was either nonexistent or very complicated or just different.
So since we have the ambition to connect everything in the platforms and having the products live in our systems, this was a no-go. So we had to do something about the process alignment. So looking into the way when the different sites tried to collaborate, we saw that it was a mess.
When some sites tried to get spare parts, when they tried to get the right drawings for service jobs, trying to order a belt from Sweden, it was a lot of quality issues. We had a lot of time issues. So we saw that we could do a lot of good for IPCO by sorting these things out.
So with this in mind, we decided to go for one platform, one instance of Autodesk Vault, and try to make all the 10 sites using Autodesk tools agree on one process for going forward and connected to the rest of the processes downstream. And this is how the journey started in 2022.
JONAS WICKSELL: Thank you, Mattias. So let's move into the hows and whys, meaning what did we do and how did you do it and why did we do it. So I would like to introduce something we call the Critical Three, and that's basically the three major components that we recommend that you look into, running these type of projects.
First, it's about executive sponsorship. How do you get your executives' buy-in and, by that, come up with the right resources and the funding and the sponsorship needed be able to run this type of project?
The second of the critical ones is, how do you get the proper user engagement and the willingness to change? And I would even say not willingness. I would say eager to change because that's something that we found that was quite important, that the users not only were willing to change, but they were quite eager and were helping us to drive this project.
And the last but not least component of this are the actual move from where IPCO were in the beginning, where we started two years ago, and where they wanted to be when the project was finalized and they started to get their hands dirty doing the changes. So these three will be what I will focus on here.
And so let's start with the executive sponsorship part. And I will say the four most important takeaways here is that what we found out that what we need to do was to get the awareness from the executives that there were things inside of the organization that we needed to address.
And this was exactly the ones that Mattias covered a while ago, that there needed to be one IPCO, so the critical issues and all the needs that had to be addressed or one of the critical parts, and, of course, get the executive ownership and, by that, get access to the proper resources. So all the people that we needed to get on board to run prestudies, et cetera, those were available while doing their ordinary job.
And then, of course, in a large organization, you will always end up in politics and also something that we needed to spend time navigating around and sort out on the way. And the way that we saw that we had to do this was helping IPCO creating a business case where we could justify all the actions and get the real fundings.
So this is what I'd like to cover and start with, how did we create the business case. So that started in late 2022-- this was two years ago-- where we had some meetings with the executives, get an idea of where IPCO were heading, getting some executive attention, and look into the possible roadmap. And then we moved into the hard work, trying to figure out where were the challenges, the bottlenecks, where were the consequences not addressing these issues.
And this was done by local interviews. So with the core team for this project, we flew around the world, meeting all the engineering sites and having workshops and interviews with the users, gathering all their needs and wishes, finding out what took time, what didn't work, et cetera.
And out of that, we created a series of recommendations in the report where we pointed out our findings and did some analytics around this, proposed actions to improvement. And last but not least, this ended up with a report with the business justification some six months later where we looked into the potential outcome and return on investment for doing this project.
Some of the highlights that we found during this process was what we usually find in most companies of this type, a lot of different applications and a lot of different storages of data you can call data silos. And as Mattias mentioned, a lot of engineering sites that had no common processes and no real collaboration, that was also an issue with the goal to have one IPCO, a lot of bottlenecks between processes and lack of handovers, problems with data sharing, and a lot of manual work and often repetitive manual work, which was not all that effective.
And what we saw as the possible benefits was, of course, where we started where were no one IPCO, and there was a lot of different setups. They used Vault and Inventor and AutoCAD previously, but everything looks like different companies. So by putting everything together in one bucket, we expected to see a lot of lower total cost of ownership with one common setup and also one single source of truth, not 10 different data storages and versions of the data, just one, and a lot of improved collaboration between the different engineering sites and users and try to automate as much as possible from these previous manual processes and manual tasks.
And also one important thing is that-- and Mattias recover a little bit later in this presentation-- there were a mission what they wanted to be in five or 10 years timeframe, so what we did here with the OneVault was also creating the foundation for growth, the foundation for being more collaborative with both internal players and customers and the subsuppliers, of course, and, like always, the means to be more competitive in a quite competitive world. So that was basically the business case and how we perform that one.
The next one I would like to cover is how we engage the users and get their commitment to this, and that's also for high points in this is that we found that was quite important to both involve and engage all the key users in the whole organization, not just engineering. Everyone that will be affected needs to be included so they feel that they are part of the new solution and part of the change.
What you also found was quite important is to find out all the personal reasons, and that was something we struggled with initially. The people were more eager to look out what benefit themselves than what would benefit the whole company, so we need to bring that in as well so that everyone should feel as a winner in this, not loser. And one way of doing that is to identify some quick wins so people feel, wow, something happens, and that is also something that we found was a high motivator to embrace the coming change.
And last but not least, the communication part, the importance of keeping everyone up to date, what's happening, especially in these type of projects, is quite long. You need to show some progress. Otherwise, people will lose faith and start to do other stuff. So this was the main four points as we saw it.
So the question is, what's the biggest challenge in this? We had a lot of challenges, but what we found out in the engagement phase of this project, we had some things that we struggled with, of course, get people to prioritize the meetings, start to engage and share knowledge. They were not used to talk to each other, so that's a challenge.
And I would say the biggest one was to get the users to shift from "my way" to the IPCO way and start to look in the greater good of everyone. While discussing with the customers in these early meetings, there was a quote popping up in my head all the time, and that was actually from one of my favorite bands from the '80s, a Danish band called D-A-D.
And this was typically what popped up, that everyone liked to share their opinions as long as their opinions didn't collide with their perception or the way they have worked previously and their setup. So there was a lot of discussions. Why should we change? Couldn't the other sides change instead? So this was a real struggle that we had to face.
And what we really tried to do to come over this was something that we call in Nordics to create the Hygge. So if you're familiar with especially Denmark, you will know that Hygge is an easy way to get people on board, get the same mindset, and start to share information and a willingness to both compromise and contribute to the process, to improve. So that was something that we worked a lot with to get people on board and get the right mindset and feel, a Hygge.
So how did we do this? User involvement, especially get people engaged, get people involved, get them a part of the requirements input so everyone has the chance to talk. Of course, with a company like IPCO with some 130 engineers, it's quite hard to get everyone involved, but at least bring out the key users, and they can be the ambassadors for the rest. Get them part of the workshops. Get them part of the requirement workshops. Get them engaged in the pilot testing, et cetera so they contribute with energy and insight for the collective.
And by doing this, you also start to create the community, and so we had some formal meetings with the steering groups, the project groups. We had these key user meetings, et cetera, and all that contributed to have one common way of thinking. Everyone would like to contribute, and we're quite engaged to see what it would end up with.
And last but not least, the communication part-- so we spent a lot of time setting up the proper communication channels so everyone was involved and notified and informed what was happening. And meetings-- we rotated through different sites in the world so everyone would feel that they was a part of this process. So that's quite important to have those on board. So let's spend a couple of minutes and listen to what some of the users have to say about this process.
[VIDEO PLAYBACK]
- For us, as a very distributed engineering community, it was really important for us to understand the differences between the countries that we work in.
- At this moment, we are starting new projects, starting with a digital workshop floor, a new PLM system, and we are thinking about moving M3 to a cloud solution.
- The challenge I see with the current phase of the project is figuring out what all the requirements are. It's got to be careful consideration because not all aspects can be fully integrated, so you've got to work collaboratively and come up with a finished product that suits everybody as best as possible.
- To be more standardized and be more competitive is really important in our business. Therefore, we would like to get to know how we are working in the different countries and starting to align that into one way of working.
- Planning ahead is key to making any project successful, so it's really important to develop a path forward and figure out the best method to tackle the obstacles at hand.
- My expectations of this project are improving towards the customer, improving in productivity, improving in capacity. Yeah, I think it will be a whole improvement.
- Alongside with the OneVault, we are working with connecting to ERP, and we also do the digital shop floor where we remove all the drawings from the shop floor.
- The expectation for this product is basically a common way of working, using the data to provide our customers with a valuable product. I
- Think our customers will see a more precise engineering, more accurate deliveries, and hopefully more speed as well.
[END PLAYBACK]
JONAS WICKSELL: So a lot of expectations and a lot of ideas, and that was quite interesting because this was the selected part of some of the users. And there's a lot of expectations, a lot of ideas and wishes, and that was really, really good. But of course, a lot of expectations revolve of us in the steering group and the project group to deliver on the promises.
And that leads us into the final part, and that's basically, how did we do the move or the transition from the "as is" to the "to be"? And as before, as the four critical points here, and that's the first one. We call it focus on looking forward, and what that means is that it's quite easy when you sit with a lot of users.
They know what they have. They don't know what they will get. They are quite focused in, this is the way we always have done things, we need to use this, we need to use this, we need to use this, we need to have that data in our hand. So you tend to start looking backwards and build the solution on that instead of looking forwards.
The other one is take and maintain project leadership. It's quite easy when you have a lot of users in different sites, different cultures, different site managers and line managers that they want to start to take over and ensure that their needs are prioritized before others. And that's where the strong leadership and the executive sponsorship comes in to be able to run this in a good way.
The third one, I would say, do your homework before starting up so we don't end up in finding issues, things that don't work late in the process. So do your homework. Do the studies. Do the analysis in good forehand so the user experience will be good, and hopefully, you will find all the issues at least in pilot testing and definitely not when you are moving into rollout and adoption.
And one thing that was also learned in this project is, don't over complicate things. If it's hard to use, no one wants to use it. So try to prioritize the wishes and the needs. So if you want to do everything, no one will do anything. It's my experience.
So from this, what's the biggest challenge in the specification phase? I would say, of course, it's all of these, but some of the big challenges here was trying to balance not spending too much time on history, how things has been, more focused on how things should be, and also quite hard to prioritize the local needs versus the global needs. So that's also something that we had to spend a lot of time on.
And the last one that's quite typical, when you start to engage people and they start to understand and realize, it's like sending a Christmas list to Santa. You want everything, and by doing that, you end up with basically achieving nothing because it takes forever to deliver everything. So get the balance, and try to get good enough. And that doesn't get in the way and stop the project. So go for good enough and then continuous improvements instead.
But the biggest one in this case was basically trying to avoid doing the same things that they had done previously and try-- and believe that they can get another outcome of it. So that's this quote from-- I thought this was from Einstein, but as I read around, it seemed that it's not Einstein. But at least trying to do something the same way repeatedly and expect that you get different result, well, that's insanity, and that's basically the take from this.
Don't focus on looking backwards. Focus looking forward because the solution that IPCO wanted was a change of work, one way of working, one common way, one database, one set of applications, and you can never achieve that by doing the same thing in the same setup as you have previously. So focus looking forward, not backwards is my biggest take on this one.
So let's move on and see how did we specify it. What did we do to get the move from "as is" to "to be"? First of all, we, of course, have the requirements collection. That started quite early already in the prestudy phase where we did a lot of prestudies looking into the legacy data, for instance, the business process assessments, look into the technical prestudy.
And then we moved into starting to do the prioritizations. That's quite important because we got to list off I don't know how many points but as many points that we, together with IPCO, could spend years and years and years trying to set it up, so quite important in this phase is to prioritize. And what we did was start looking at initial assessment and the wishes from IPCO management and the road ahead for IPCO. What should we prioritize to be able to meet the corporate goal and the corporate vision?
So we mapped that towards the strategic initiatives and the strategic issues that IPCO looked into, and those should be prioritized in setting up the new system. So the engineer community could, from day one, start to produce in the right direction. One thing that was also quite important as we moved from a lot of different engineering sites around the world with local setups and now moving to one world, one setup was the security versus the accessibility.
So if you open up for everyone, it's quite unsafe, so this was something we need to balance, and that was one of the big concern from Mattias and the IT department, how to ensure that the wrong people doesn't access to the wrong data, but the right people should access the right data. So that was something that we spent a lot of time setting up, the security model and the access model for the engineering data and all the documentation around it.
Also, part of the requirements presentation is to look into the effort versus value. How much effort, and what does that provide from the value standpoint to IPCO community? So spend time on the things that have a good impact, and save the others for later.
And also, start with the planning for training and option quite early so you have a solid plan when it comes to that part. And from the system configuration part, it's like every other project. Have a testing environment. Have a sandbox environment to run it. Try to balance the agility versus the static approach.
Of course, if you are too agile, that's a risk for scope creep, so that's why we had a change management strategy that was run by the steering group. So small changes-- that's OK as long as it doesn't affect the delivery time, the solution, or the budget. But if there are the risk, then it's up to the steering group, and we run it as a change management process. So that meant that we could keep track of everything, keeping track on the budget, keeping track on the resources needed, keeping track of delivery time and the solution itself.
The other part here also was to set up some legacy data strategy, as IPCO, former Sandvik, have been doing this type of machines since the early 1900s. So, of course, there's a lot of drawings, a lot of 3D models, a lot of archiving. And you need to have a strategy because you can't bring it all in. Then you will start the translation project, the legacy data translation project that will run for forever. So you need a reasonable view on how to handle that.
Last but not least, the go live and adoption phase, and I think the most important lesson here is you need to have the local management involvement here because you will always end up in issues with balancing, training, adoption versus ongoing projects. And if you don't have the management approval and the management push here, you will start seeing that the users will not move into the new solution at all. They will stay with the old things as you don't have to learn-- don't have the time to learn anything new.
So that's the important part. And also realization when we have delivered the system, as we are doing right now with IPCO, then it starts. I almost said, "the fun starts," but I would say the hard work starts because now it's time when you start to change the behavior for the users when you start to move into the new system.
OK, what did we end up with? The results and also what lies ahead for IPCO-- if you take a little step back, look into the challenges that we're trying to meet, I will say the metrics for the projects, and that was basically the one IPCO approach that Mattias spoke about. That was the goal for this project.
So we take a look and see how did we meet up these. First of all, what we did was moving all the local servers into one central server in Azure and also setting up the security layer for it. So that was the first thing that we did, bring everyone into a bucket, set up the security, set up the configuration, so a check on that one.
And one of the parameters that we worked with here was, like Mattias always says, if it's not connected, well, then it's wrong. So that was also one of the foundations, that we should connect this with other IT systems so we will have a complete digital flow of not only engineering data but all product data that was created before engineering, during engineering, and after engineering.
So what did we deliver? Well, as we said before, IPCO already had both the AutoCAD Inventor-- some sites were using Vault as well, and they had the Infor M3 as the ERP system. So that was the basic common tools. So what we did here was to ensure that they had the same setup for all the creation data, the Inventor and AutoCAD, for product design.
We set up one common application layer we called Property Management to ensure that all the properties were entered in a correct way with the right language, with the right templates that later would be used inside of M3. So we already, in engineering, prepared for the handover to the ERP system.
And we also set up one common configuration with the Vault Professional. So everything on the blue side was equal. Regardless if you were in engineering in Sweden or in Germany or Italy or in the US, everything should look the same, the same properties, the same set of data, and the same way of building up the data from a part and assembly standpoint.
Then we moved into the integration layer and provided our NTI integrator as the foundation to share data between Vault and M3. And this is bidirectional, so we are getting information to pass back and forth. We will show this also with the film in a while so you can get an idea of how it works.
So I think we'll leave the schematics and move into short video where one of the users will show how this work and how they're working with OneVault.
[VIDEO PLAYBACK]
- Let's take a look at this assembly right here. I will create a new sheet metal part and place into this assembly. So let's create simple geometry, save it into Vault, and also apply some properties with the Property Manager. So I have some description in English, and also, I have in my local language, which is Swedish, some description as well.
Let's put it into the assembly and check it into Vault. I will also create simple drawing in my assembly here so I can put some balloons, maybe a part list. And we can now also clearly see that we haven't got any number from our ERP system for this new plate, and that will be the next thing here to actually update the assembly item in Vault.
You can see now we have a brand-new item created, the clamp plate. It's in Draft mode. It doesn't have an item number from the ERP really yet. But here we go, and now I'm ready to add some additional properties. And this has to be done in order to get the number out of our ERP system, so it's specific properties, for example the item template, that's going to be used. In our case, we also have the material group, which warehouse, where it's going to be manufactured or purchased and so on.
So here we go. We are done, and we can now put it to state retrieve ERP number, which basically means it starts to communicate with the ERP system through the job processor, and we will receive ERP item number back into Vault. So now the item is in a new state, work in progress.
And let's have a look at the structure. So now we can see that our top-level assembly is a work In progress, and obviously, we want a clamp plate as well. And what we want to do now is just to update the drawing that we created before so we get the number all the way back into Inventor.
So now let's release the whole thingy. Just to save some time, let's put it straight to Release. Otherwise, we can have a review and approval process as well. And now job processor will do some work, obviously. So here we have it released. We have some secondary files, this design representation, published, STEP files DXF files, PDF file, obviously.
If we go to the assembly, we can see that our even the files from the whole structure, so here we have all the STEP files, for example. And not only the published files, everything-- all the information regarding the items will go all the way to the ERP system. You can see here, here is my English description, and I have my drawing number and so on. And here we can also find the product structure that comes, basically, all the way from Inventor through Vault and into ERP.
[END PLAYBACK]
So that was a short way of showing you what we, together with IPCO, has set up so far and the workflow from engineering over to manufacturing. So if you take a look at the time plan, the project timeline, as we mentioned before, this started some two years ago with the prestudies and the preparations.
Then we moved into the specification and data analysis phase and then the configuration, the pilot and testing, and now we are in the rollout and adoption phase. And this is done stepwise. So we started now in Europe, and we'll continue for the rest of this year and moving over to the next year with Asia.
So if we have this discussion a couple of months from now, they will all be running up or be running on a global basis. And the overall time frame for this, as you see, more or less two years from the initial prestudies now to the finalization phase, and that's what I think you can expect for this type of project if you want to do it in a proper, secure way, I will say.
So if you look at some figures, a little fast, this is now a global solution for the whole IPCO community. So we have some 10 engineering sites worldwide now using Vault, and we also have a lot of downstream users. So the engineering community is some 130 engineering users, and now we are also starting to add PLM users. I will cover that a little bit also as well.
So we have moved from Vault Professional to Vault PLM now to start adding the more business layers to this, and we have a lot of downstream users as well. We've also moved into an environment taking care of the facilities. And as I mentioned before, we have one central Vault database and one central integration platform.
So with this, we have created the foundation, and the work now is, of course, to move away from the old way of doing things to the new way of doing things. And that's also one of the big challenges where we have spent a lot of time figuring out how should we do the adoption phase, how should we do the user training.
And that's a huge task, especially if you look in the-- we are a Swedish company, a Swedish-based company, with the engineering sites all over the world. The foundation here is in English, but we have users in Japan and China and Korea that are not native English-speaking, so that's something that needs to be taken care of when you look into adoption phase.
So moving forward, what is happening now? As I mentioned, we started now with the OneVault, and that's what we have now finalized and starting to deliver together, IPCO and NTI, and that's the foundation for growth, as we call it. So with the foundation in place, we was able to start moving beyond the PDM environment and start adding more business processes, and this started with taking care of the project management parts in the new factory in Forsbacka, outside Sandvik in Sweden, where they needed help to take care of all the project data, all the drawings or requirements for the remodeling of the new factory.
And we also started now to move into the downstream processes as we have now created the secure environment for all the product data, ensuring that it's done in the same way all over the world, and that we have full engineering collaboration and communication. Then we can start to utilize that data for other users inside of the company.
And here we started with the guys and girls from the off-the-market department and setting up an off-the-market portal where they could access all the engineering data, all the product data, get all the 3D models and drawings and specifications, and from that speed up the process to get the ordering processes for spare parts or even trace the correct spare parts from the machines they have delivered to the customers previously.
And from this, the starting point was to take the build material from the OneVault environment, the engineering build material, and move it into the PLM environment. And for that, we could start to restructure it to ensure that it could be used for other reasons than just engineering, like service personnel, the off-the-market personnel, and, well, just the imagination that sets the limits here.
And with the build material taken care of and starting to be utilized in the whole organization, then we can also start using that for quality management purposes, and that's something that we are now starting to look into. What are the typical quality management processes that we should add into the PLM environment and also, of course, the change management processes.
And these are processes that are done today on the document level. So it's quite hard to track changes, quite hard to find a region for changes, and starting to get some good reporting, how many issues do we have with the certain machine from a certain vendor at the certain customers, for instance. So that's typically areas that we are now starting to look into while we have set the good foundation for it. And then, of course, step by step, we can start adding more and more business processes where it makes sense. So Mattias, what do you think about the moving forward and your vision from IPCO?
MATTIAS LORVI-ERICSON: Technology is easy. Getting people to do the right thing and do the same things, that's more of a challenge. As of now, we have the platforms, the major platforms in place. We communicate between the platforms, so we keep information up to date in all instances. Previously, we had a history of when we sent the information over from the PDM system up to the ERP, it was gone. We never saw it again. And the drawings were more and more-- became more and more wrong.
And that is not the case any longer, so we have the connected information between the platforms. And also, we have the data to follow the products, both internally in the factories and also out with the customers. So what we're looking into now is adding machine automation and also harvesting data from the machines to learn more about the machine health.
Of course, we do recipes and maybe product measurements internally on the machinery where we produce the belts, but with the customers, we are not really obliged to do that. So we focus on machine health, and with that in place, we can look at trends. We can learn from the machines out there, compare the machinery, and we have those machine insights that we can feed back to the engineering department to continue with the continuous improvement. So we have the full circle of life, really.
And, of course, in the far end out there somewhere, we're looking at the digital twin as the Nirvana of everything, we think. Then we're done. Don't you think?
JONAS WICKSELL: Thank you, Mattias, for sharing your ideas how to utilize this in a more sophisticated way than ever before. So with that said, we all would like to thank you for your time and your interest. If you have any further questions or anything, please reach out to any one of us. We have our contact detail on this slide. So with that said, big thank-you, and thanks for now.