… and spreadsheets are not helping ! It seems like this sentence comes to my mind pretty much everyday. And we don’t have a 100% valid solution today to provide to our customers as they still use Excel files or Access databases spread into their organisations and not connected to each others. As I alread
just integration won’t solve it all
A few month ago I was writing about integration because I could meet more and more prospects telling me that they have the right interfaces for their users they just miss the connections from one job to another. And coming with a complete PLM solution, I felt like I had no point showing them the solution as they just wanted to invest in integration. But integration is not connecting simple stuffs. Who uses standards in the industry? And Once again I’m not talking about complicated stuff like STEP. I’m just talking about simpler things like requirement management, simple BOMs. How many times have I had someone telling me: “we have a pretty standard spreadsheet for our BOM”. No you don’t! I’ve heard this many times and they were all different. So the phrase “shit in, shit out” is also true for integration. Make sure your data as the right format and is clean and then integrate.
PLM as MDM+BPM+…
I wrote an article in french about this a few year ago. I was explaining why PLM was a sum of other tools like MDM and BPM. And recently I was being interviewed by a company who needed some consulting on how to structure their product management. And one of the person asked me: “what do you think is the difference between PLM and MDM?” It was honestly a strange question, I would understand a question like “do you think PLM can be used as an MDM?” because PLM and MDM are on different levels, PLM is more functionnal and less IT it gathers various tools to enable the automation and overall IT support for the business rules related to product data management during its whole lifecycle. Then yes, PLM could be a single point of truth and take the role of an MDM, but then you would fight with ERP.
Then, I think MDM is n interesting topic and should not be studied without looking at who is using the data and what other solutions are interacting with it. As we can see today with Aras Innovator, we have HR departements asking us if they can manage yearly performance review within Aras. And of course they can, is it related to product? it could be but it’s not the point. The point is that the mix of a convenient technical architecture with a correct business model makes it possible. But don’t forget to think about how you could us standard formats.
These last weeks were pretty crazy in terms of projects to work on. Travelling from sites to sites and visiting various industries. From tractors production (about 40 to 50 units a day) to navigation systems (few thousands a day and highly automated), it is always good to get back to basics and meet the people who are actually consuming the design data to understand what should be enhanced, not so much in terms of CAD data quality (I’m not a CAD vendor) but more in terms of general information management. The last strong argument I have had with one of our customer is about versionning. I’m not sure the discussion is over yet so I’m using the blog to exchange with you, our readers the decision process on versionning strategy.
Who is versionning things?
So, I’m writing this article to make some follow-up on one of the latest article of Oleg about versionning. This is an endless topic. He was mentionning versionning in PDM as a follow-up on my article about the existence of various understanding of what is versionning depending of the kind of work you are doing, or depending on your field of education. I would like to extend the versionning on another axis which is to understand why someone may or may not lead the versionning in a global supply chain. Our customer case is quite special as their are manufacturing devices that are designed from their mother company and sold to car manufacturers. So they get product definitions with a versionning system, and they are due to follow this versionning in order to deliver their product to the final customer.
So they are really concerned about following their supplier’s versionning because the mother company is the one communicating version with the final customer. They already have multiple level in their versionning. With a minor revision and a major revision but these are based on design change, nothing is directly related to manufacturing-related changes. But still, changes happen all the time and I believe that anyone one making changes should use an appropriate versionning system.
Multiple versionning object or one versionning with multiple level?
And this is a question I haven’t 100% answered yet mainly for a lack of time and discussions. My initial idea is to be completely independent from others whatever the relationship you have with your suppliers and customers. You should own your versionning systems. So that would mean allowing multiple versionning objects related to items (like parts) that you want to track. But what would be the difference with a single versionning object but based on multiple levels? This wouldn’t not allow so much independence. As they recently experienced it, the mother company can sometime change almost completely their way of managing versions. So, if you don’t want your system to be affected, multiple objects makes sense.
So that’s the idea for now. I’ll try to define a stronger position with illustrations once we will have decided of a system to use.