PLM: Share Data or Die

PLM: Share Data or Die

I’m still digesting a huge amount of information I learned from PLM Innovation Congress earlier this week in London. However, there is one trend that I can identify that struck me as a major one coming across all presentations and talks. I can call it “integrate and share” trend. The problem of integration and share of data is not new in manufacturing organization. The need for integration of various elements of data for product development, manufacturing and supply chain is clear. Software vendors and customers are working for on this for years. However, something new happens now that allow me to have a fresh look on this.

Integration Processes

The sound of integration needs is very loud, and you are able to see it in presentations. I put few examples of pictures I made during the event to show how customers explain their critical business issues related to integration of data and processes in organizations. In a nutshell, inability to provide smooth integration prevents streamlining of organizational processes. It appears in communication between engineering and manufacturing, sales and production, support and sales.

Share Data

The need to share data is obvious. However, data sharing was never realized in an easy way. There are multiple reasons for that. Some of them are including the nature of people (keep my data close to me), company organization (departments, hierarchy, etc.) and competition between vendors (lock-in data inside of proprietary formats and data structures). At the same the value of data sharing is obvious. Organizations are losing money, projects are going out of schedules just because of that. PLM aimed to solve this problem during the past decade. I have to note a significant success in multiple implementations I had a chance to see. I personally participated in some of them. However, the ability to share data efficiently is still more science that ordinary process.

What is my conclusion? The need to integrate and share data is urgent. However, the way organizations are doing it, reminds me space shuttle programs. There is a need to downgrade and simplify these integration efforts to become more similar to transatlantic flights or even car trips. Just my thoughts…

Best, Oleg

Share

Share This Post

  • I guess that from these statements you’ll come to talk about MDM pretty quickly?

  • beyondplm

    Yoann, Actually not. I don’t like first “M” in this technology. Master is somewhat orthogonal to network. My prediction is the future belongs to “data networks” and not to “data masters”. Best, Oleg

  • DiscussPaul

    I read this note with interest – for years, I’ve been supporting an “unsupportable” product that locked customers into a clunky set of information exchange tools that made it, well, incompatible with itself (Okay, unreliable…)
    In 2006, Boeing made an interesting presentation at a CATIA Operator Exchange (COE) meeting, “Leaving Money on the Table”, that actually made a case of better interop as, at that time, PDM use was estimated at about $5.0 billion for the auto industry, and the supply chain integration was estimated at $1.4 billion (for the N.A. area). Interop problems cost dear to EADS as the A380 program was in jeopardy in 2005-06 due to clunky interop. A drop of 28% to 23 euros in its stock price meant the company lost roughly 7 billions of value at the time.
    I do believe in streamlining sharing, but this effort is often countered by the need to ensure security – ie, increased security in commercial airports. How about an e-passport?…

  • beyondplm

    Paul, Thank you for your comment! Actually, I think, I remember this Boeing presentation. Interop is a strange space. I think, vendors are afraid of interop improvements because most of the enterprise business strategies are focusing on lock-in and recurrent sales. I think, future enterprise software leaders will be making money out of interop and data sharing. However, this transformation won’t be easy. CAD/PLM mindshare vendors are not ready for this, for the moment. Best, Oleg