How to turn PLM, ERP & MES into a 360-degree system

How to turn PLM, ERP & MES into a 360-degree system

a-360-degree-integrated-view-plm-erp-mes

Major pillars of enterprise software in every manufacturing company are represented by the silos – engineering, manufacturing planning, shop-flow control. Historically each silo developed its own system to manage information and processes. Nothing wrong with that, but within time, created a huge problem of data handover between organizations.

With increased competition, demand for efficiency and data transparency, inefficient data handover is a bottleneck that can bring a manufacturing processes in a full stop. Integration between PLM and ERP is one of the most painful examples. I shared my thoughts on why manufacturing future will depend on solving old PLM/ERP integration problem.

Existing PLM/ERP integration model with complicated data synchronization is bad and won’t work for future of manufacturing. It is heavily relies on the idea of data synchronization and replication between systems. It is too costly to implement and maintain. It is sometimes too slow and requires lots of data manipulation and transformation.

Automation world article PLM + MES + ERP = Closed-Loop Product Lifecycle brings few examples to highlight the importance of integration between core systems – PLM, ERP and MES in manufacturing.

What struck me is how the demand between achievement of a 360-degree view is conflicting with the idea of data synchronization between systems. To replicate data is hard. To replicated a massive amount of data between existing systems enterprise and legacy systems is even harder. Many of these systems were developed decades ago and using data foundation technologies not capable to maintain efficient data integration.

The following passage from the article speaks about problems of integration:

Despite the huge upside, integration between these core enterprise systems is relatively immature for a very simple reason: It’s historically been way too complex. Closed systems coupled with proprietary networks and communication protocols have been huge technical hurdles preventing data from flowing easily between core enterprise platforms to create a closed-loop system, says Khris Kammer, information partner and competency manager for Rockwell Automation.

“These systems are used by different industries and different companies in different ways,” Kammer explains. “One company’s master data might mean something different than another company’s master data, and this lack of a common definition of what fields mean or what data means has been a hindrance.”

Data ownership is another key element, which is a major divide between how different enterprise systems are managing data. Clearly BoM is an apple of discord between PLM and ERP. Ownership model is preventing to build an efficient handover as well as create complex political tension between enterprise stakeholders.

The question of who owns the BOM data is just one of the many cultural and people-related issues hampering widespread integration efforts. Historically, IT, engineering and operations have had their own systems that they kept pretty close to the vest. It’s also been unclear at the vendor level which company is responsible for driving the integration, says SAP’s Lackey. “Is it the MES, middleware or ERP vendor that owns the integration?” he asks. “There’s been no one point of ownership to make it work.”

So, how to stitch PLM, ERP and MES systems for 21st century manufacturing? I can see few possible options:

1. Point-to-point integration between systems with semi-automatic handover. This is the option most of companies are using. Development of “bridges” between systems is a business of service providers and small software development outfits capable to pick a small integration opportunity and make profit out of it.

2. Integration Middleware or Enterprise Service Bus (ESB). This model is support by IT as a strategic option for many years. Back 10-15 years, it was mostly an infrastructure provided by IBM, Microsoft and other giant vendors. These days, we can see examples of integration services leveraging cloud and event driven infrastructure. This option is usually required implementation service provider and cannot be done out-of-the-box.

3. Break large systems into separate integrated services. In my view, this option can be considered by many large companies to solve a problem of legacy systems lifecycle and to improve integration among silos. Branch by abstraction model can be used in order not to break existing systems and to insure smooth transition. Some of PLM replacement projects are following this paradigm, but this is still not a mainstream option used by manufacturing companies.

What is my conclusion? Closing the loop between engineering and manufacturing silos is a big problem for all companies. I don’t see any universal direction that can work for all companies. It depends on many factors and existing systems. I expect companies will start actively cut old and legacy systems to achieve better integration and data handover. “Less is more” will become future IT strategy. Just my thoughts…

Best, Oleg

Image Courtesy of Prime Focus

Share

Share This Post

  • Stan Przybylinski

    Hi Oleg, this covers the lifecycle until the product goes out the door. You still need something like CAPA or other processes to bring field data back. That is one of the promises of the IoT. I still want to hear how people are going to integrate the data and analytics back into the front end of the product development process, but that is just me.

  • beyondplm

    Stan, thanks for this comment! Indeed IoT promise is to bring data back from the field to design and product development. In my view, IoT can potentially create even bigger silo than existing PLM-ERP-MES bundle.

    So, without IoT, it will be probably 270-degree system 🙂

  • Stan Przybylinski

    As a word, silo has a bad rap. (My stepdad was a dairy farmer and silos were vital tools to keep the cows fed in winter.) Specialists have their own jargon, own data requirements, and own tools. The problem is that silos, like most of those down on the farm, have solid, impermeable walls. Good for storing grain, not so good for managing products through their lifecycle.

    That is part of what the platformization stuff is about. These silos need to be permeable, with well-defined, public data structures that can
    “snap on” to other organizational systems like multi-dimensional Legos.

  • beyondplm

    Stan, thank you for sharing your insight – this is really good! I already can see the next presentation about “platformization” coming between lines of your comment :). Permeable silos with open data service interfaces. How is that?

  • Stan Przybylinski

    Like I said, the metaphor I think of is Lego blocks. Standard to connect. You could even use Duplos to extend the metophor. For the uninitiated (or those without kids), Duplos are larger blocks that are Lego-compatible. You could argue that some enterprise connections have wider, less discriminating “pipes” between them, so they can connect with both very focused domains, or less.

    Someone like Granta can be seen as doing this for their domain, materials. They know all of the important DBs at the schema level, are connected to all the right standards bodies and industry groups, etc. to help influence, structure and interpret all of this information for the benefit of users. They are creating THEIR standard Lego connector, but are malleable to adjust to others.

    To go all sci-fi on you, this is sort of like the Borg on Star Trek: ” ”We are the Borg. Lower your shields and surrender your ships. We will add your biological and technological distinctiveness to our own. Your culture will adapt to service us. Resistance is futile.”” (http://www.bitrebels.com/entertainment/we-are-the-borg-you-will-be-assimilated/) SOA-based solutions

    I think of SOA-based solutions the same way. You can assimilate the actions (services) and data that characterize the type of business processes and data needed in that domain. You extend your data schema to add this distinctiveness to your own.

    Hopefully resistance won’t be futile.

    Lastly, to be featured in your blog? That’s almost as good as a cup of tea with you at my kitchen table.

    Stan

  • beyondplm

    Hi Stan,

    You are right – to create connectors and suck data from the outside world. Then make analysis and provide services. I can see how Granta doing similar things for material management.

    The things can be more challenging with ERP and MES world. The devil is in details. SOA doesn’t help here. If I will use your paradigm, it helps to connect blocks, but you’re on your own to solve the problem with specific data elements. Similar to event driven integration tools – IFTTT and Zapier. It is easy to create connectors, but it hards to handle data. It is a work that usually done by special contractors of this magic integration kingdom.

    Look forward to grab a cup of tea with you soon. Weather is much better in Newton and Brookline neighborhood these days :).

    Best, Oleg

  • Really love this – but is this really possible with the current powers in the PLM market? It’d be one thing if every vendor had their own silo and they just need to play as a piece of a larger whole, but with constant acquisitions they’re constantly getting in each other’s business (and ERP’s, and SLM’s, etc). There’s no compelling business case for them to do this on their own as it might tighten margins and undermine their pursuit/capture philosophy. The demand must come from the user end. But how influential is the user end, really?

    To continue the analogy, they don’t want Lego-ize because then they can only sell a brick at a time, now you have to buy the whole airport set. Which is better for stockholders? Which is better for customers?

    I think we can all agree a common schema is a fool’s errand, but a common abstraction layer is achievable – but do vendors really want to go that route? An old but relevant article:
    http://www.infoworld.com/article/2641537/service-oriented-architecture/using-a-common-data-model-with-soa.html

  • beyondplm

    Ed, thank you for comments!

    You explained very well the drivers behind vendors’ decision as of today in the market.

    In current situation, the only way to make a significant progress is to buy “the whole airport set” :)… love your metaphor, btw. Even so, the ROI of new implementations is very questionable. But this probably the best decision for most of medium size companies (single digit $B revenues).

    But most of larger enterprises are using multiple systems with lot of history and integration complications. From 3 options I explained, #1 is the option most of companies are following. It is the option that minimizes the tactical risks – no surprise every IT manager is preferring that one.

    What you call “common abstraction level” is probably something that most of vendors will call standards. What is good about standards? There is always one more to support 🙂

    You can find some ideas about problems with standards in my blog — Why standards are not a silver bullet to create PLM innovation platform.

    http://beyondplm.com/2016/01/07/why-standards-is-not-a-silver-bullet-to-create-plm-innovation-platform/

    I’d love to discuss it with you when we have a chance.

    Best, Oleg