PLM implementations: nuts and bolts of data silos

PLM implementations: nuts and bolts of data silos

data-silos-architecture

Data is an essential part of every PLM implementation. It all starts from data – design, engineering, manufacturing, supply chain, support, etc. Enterprise systems are fragmented and representing individual silos of enterprise organization. To manage product data located in multiple enterprise data silos is a challenge for every PLM implementation.

To “demolish enterprise data silos” is a popular topic in PLM strategies and deployments. The idea of having one single point of truth is always in mind of PLM developers. Some of my latest notes about that here – PLM One Big Silo.

MCADCafe article – Developing Better Products is a “Piece of Cake” by Scott Reedy also speaks about how PLM implementation can help to aggregate all product development information scattered in multiple places into single PLM system. The  picture from the article presents the problem:

product-data-silos

The following passage is the most important, in my view:

Without a PLM system, companies often end up with disconnected silos of information. These silos inhibit the ability to control the entire product record and employees waste unnecessary time searching for the correct revision of the product design. As companies outsource design or manufacturing, it becomes even harder to ensure the right configuration of the product is leveraged by external partners.

Whether your company makes medical devices, industrial equipment, laptops, cell phones or other consumer products – PLM provides a secure, centralized database to manage the entire product record into a “Single Record of the Truth”… With a centralized product record, it is easy to propose and submit changes to the product design, track quality issues and collaborate with your internal teams and supply-chain partners.

The strategy of “single record of truth” is a centerpiece of each PLM implementation. However, here is the thing… if you look on the picture above you can certainly see some key enterprise  systems – ERP, CRM, MES, Project and program management, etc. PLM system can contain scattered data about product design, CAD files,  Part data, ECO records, Bill of Materials. However, some of the data will still remain in other systems. Some of the data gets duplicated. This is what happens in real world.

It made me think about 3 important data architecture aspects of every PLM implementation: data management, data reporting and data consistency.

Data management layer is focusing on what system is controlling data and providing master source of information.  Data cannot be mastered in multiple places. Implementation needs to organize logical split of information as well as ability to control “data truth”. This is the most fundamental part of data architecture.

Data reporting is focusing how PLM can get data extracted from multiple sources and presented in seamless way to end user. Imagine, you need to provide an “open ECO” report. The information can reside in PLM, ERP and maybe some other sources. To get right data in a right moment of time, can be another problem to resolve.

Last, but not least – data consistency. When data located in multiple places system will rely on so-called “eventual consistency” of information. The system of events and related transactions is keeping data in sync. This is not a trivial process, but many systems are operating in such way. What is important is to have a coordinated data flow between systems supporting eventual consistency and data management and reporting tools.

What is my conclusion? To demolish silos and manage single point of truth is a very good and important strategic message. However, when it comes to nuts and bolts of implementation, an appropriate data architecture must be in place to insure you will have right data at right time. Many PLM implementations are underestimating the complexity of data architecture. It leaves them with marketing slogans, burned budgets and wrong data. Just my thoughts…

Best, Oleg

picture credit MCADCafe article

Share

Share This Post

  • Steve Bodnar

    We did this in the mid 1990’s with Info*Engine from Control Data, then Auxilium, then PTC. Ironic that companies are still trying to solve this problem with the solutions have been around for nearly 20 years.

  • Anders T. Laursen

    Hi Oleg,

    Thanks for your inspiring thoughts.

    Regarding your statement: ” Data cannot be mastered in multiple places”.

    I would like to add, “but it may change ownership as part of it’s life cycle”.

    Weight, may early on be estimated by “Product Engineering”, but as the product is being produced, the weight attribute will be replaced the actual weight measured and maintained by eg. “Logistics or Receiving Stock department”.

    These 2 department’s often work in different systems.

  • Hello Oleg, I really like your blog and enjoy generally your inspiring thoughts, but I don’t get your point in this case. A “Single-Source-of-Truth” system is better for data management, easier for reporting and most efficient for data consistency – agreed.
    Is your point: Don’t try, because some companies underestimate the complexity? – Yea – that’s probably why companies with a PLM system in place are more successful.

  • beyondplm

    Steve, thanks for reminding Info*Engine! You are right. I think, the problem of silos is not disappeared. EAI, ESB, SOA,Web Services … (add your own tech) are capable to jungle and sync data between silos. This is how it works. It is complex, expensive and requires customization per every case. As far as I’m aware, there is no other solution invented to solve problem of silos. The alternative is to go into single product suite (like do everything SAP or Oracle). But even in that case, you will have to integrated design data managed by PDM… (I guess).

  • beyondplm

    Klaus, thanks for your question! I think, the topic is complex by itself. The meaning of “single source of truth” is vary depends who you will talk to. One position is to keep all data in a single databases (which I doubt is possible). Another could be something like MDM solution where you know where the most updated information is located (eventual consistency). So, my point is – when dealing with silos you need to handle 3 things: 1/data management and master data definition; 2/data availability for reporting (how to get most updated data in a meaningful report); 3/ system to handle data synchronization between silos (eventual consistency). All in all, requires time, resource and planning… Best, Oleg

  • beyondplm

    Anders, thanks for your clarification. Yes, logically, data may change the ownership. However, let me ask you- would it be the same data in that case? when EBOM transformed into MBOM, the EBOM won’t disappear… right? This is what you call by working in different systems (Silos).

  • “To demolish silos and manage single point of truth is a very good and important strategic message.”

    Is it a good message?

    The concept of a “single point of truth” is a fantasy — an exercise in magical thinking.

    I look at what you did with Inforbix, and what Bodnar is doing with doing with Kenesto, and I see a common thread of being able to work with complex and messy data structures. Neither of you said “first, we have to demolish silos.” You found a way to work with the silos, piles, drawers and boxes of data that are typical in real-world organizations. You didn’t try to manage a single point of truth — you just tried to give people enough information and context so that they could get their jobs done.

  • beyondplm

    @Evan, “to demolish silos…” – this is a statement most recently used by Dassault. IMHO, it is kind of “elephant” story. Different people will tell you what does it mean – to bring data physically into a single database or rationalize the way to work with complex and messy data. The cost of the solution and complexity of implementation will depend on your objectives. For example, for some companies “to demolish silos” is about how to bring multiple CAD models into single DMU and make clash analysis. However, for another company it can be about how to rationalize EBOM and MBOM.