Back to basics: PLM and ERP Integration

I want to finish my ‘back to basics’ set of posts with the topic of PLM and ERP integration. Staying in CAD/PDM/PLM related market for while, I have to say that this topic always was one heavily discussed during PLM implementation. First, I want to distance from discussion about benefits of PLM vs. ERP and how can ERP do PLM or opposite. Let assume we do have both PLM and ERP systems in place. What are options to integrate these systems we have and what is the efficiency of the proposed option.

1. No integration. Manual. People do it. This is a very simple option. Full stop. You think PLM+ERP is too complex or too expensive. You think people are cheap, and they can move data between two systems by hands. Not a bad one, until your designers are waiting for new Part Number from ERP for a couple of days or your manufacturing planning people getting EBOM once in a while.

2. Batch integration.
This is in my view the most widely used type of integration. You understand that type information twice (or even more) in all systems is beyond of what you are ready to do in 21st century. So, your decision is to push information between both systems. It may happen in both directions, but for the most cases, I’ve seen a push BOM from PDM/PLM to ERP is the option company implement the most.

3. Direct integration. Next stop after “Batch integration”. Sometimes it comes after your experience with batch processes. You discovered that some business logic around batch processes is a good idea. Sometimes you need to make some validation or prompt user for a question. This is a time when you hire programmers or service company to develop this integration between “your PLM” and “your ERP”. Some PLM vendors offer “pre-packaged” integration. Despite claims of pre-packaged and out-of-the-box, these integrations never work without tuning, configuration and some additional customization. For many of the customers, this option is a compromise between “no integration” or “batch integration” and something they perceive as a more expensive option. For short term, this type of solution can be pretty good, and if you successfully manage complexity of integration, this will be, probably, your “final stop”. However, I see this type of solution as a problem with timer. In the end of the day, cost of this solution adjustment to your “next problem” will be too high.

4. Middleware based integration. Very popular option for end of 90s and beginning of 2000s. Why do you need to implement n-complete number of integration for your enterprise? You can just implement integration of your PLM (and other systems) to something called “middleware” (various TLA used and continue used for this – EAI, ESB…) and you are done. Integration middleware (such as BizTalk, WebSphere or others) can help you to map data and provide tools for business logic development. In addition to generic middleware/EAI/ESB, there are some vendors in the market that tuned their integration solution for PLM and ERP. In my view, these companies are getting premium price for their experience with PLM and ERP packages. You can consider it as a valid option too. My conclusion is that you need to go to various types of middleware and more complicated integration solution only if you understand what value your organization will get due to this significant investment. This option is robust, however, be prepared to pay the cost of middleware as well as keep experienced people or consulting company to deal with this complicated animal.  Don’t believe in magic and out-of-the-box solutions and your integration will be just fine.

5. Mashups and other Web-like technologies. This is not widely used option. Speaking precisely, this is even not “integration” in our traditional understanding. Mashup automatically will not provide you support for transferring of data between both systems. However, with growing amount of Web -related development, mashups become an interesting example of lean approach in data integration. Most of the mashups are web-client application that extracts data from a different web-sites (in our case it can be the web interface of your PLM and ERP systems) and present combined view on data. Originally developed for internet space, this option is getting some initial traction in enterprise too, but this is a topic for separate post. If you feel very innovative and your staff is experienced in Web technologies, you can try to experiment with mashups in your organization. Be prepared to be misunderstood by customers and management…

Note. I have to say that efficient PLM integration with ERP can affect your company decision with regards to deployment of PLM-related functions and in the end of the day, PLM system at all. So, choosing the right option to integrate you PLM with ERP can improve your decision with regards to PLM and sometime even with ERP implementation roadmap.

Best, Oleg

About these ads

14 Responses to Back to basics: PLM and ERP Integration

  1. Francois says:

    Hello Oleg

    may be the most important thing is the first sentence of the final Note of your post. So, while you define staged levels of integration between PLM and ERP, trigger by IT complexity, I think that manufacturers should first focus on business requirements and business impacts, in order to choose one solution or another. A realistic status on the as-is situation in terms of organization and business flows is a must to do. Manufacturers should, for that topic like for others, think “Improvement” and not “Break-through”.

  2. Francois, IT complexity of the solution, of course, need to be balanced by business need. Companies that have agreed business need to integrate PLM and ERP likely to decide for the solution 3 or 4. However, underestimate IT effort is a very big mistake company can do in their plans for PLM+ERP. Lots of project failed on this, in my view. Best, Oleg

  3. Oleg

    This is one element of PLM implementations which can make/break the deal!, your comment about underestimating the work effort within IT and the business groups is very true.

    Having been through direct, middleware and batch based integrations, my preference is more towards middle ware based solutions so that benefit from enhanced queue/job management routines which can optimize performance.

    As ERP companies continue to embed PLM capabilities one of their value proposition becomes no integration. This has some merit for companies just embarking on PLM software selection.

  4. Swati, You are right. In many mid-large size implementation PLM+ERP marriage is a deal-breaker. Today these companies are paying six digits to connect PLM to ERP, since they have no other option. On the other side, ERP companies are pretty challenged by ability to connect with engineering environment and even with CAD (in case PLM modules are part of such ERPs like Oracle, SAP and some others). Thanks for your comment! Best, Oleg

  5. Jeff says:

    A big benefit of the middleware method of linking PLM to ERP is reporting and the integration/linkage of product information that doesn’t fit well or has yet to integrated into the PLM system, e.g. validation/test results. Regarding reporting, I have found that this is a real weakness in the current PLM tools.

  6. Randy Omlie says:

    Oleg et all;
    Great discussion. Thank you!

    Best,
    Randy

  7. Dvora says:

    Very interesting. I agree the business requirements are essential. Questions such as should be discussed:
    Do we work top down or bottom up?
    Do Balloon numbers stands for the same thing in each of the departments using the data ?
    What functionalities we use in the CAD to create and update the BOM? Does the PDM 0- CAD integration is aware of this functionality ?
    Do we use standard items from a supplier catalogue ?

  8. Jeff, Agree. The benefit of middleware in providing of common layer on top of all systems. However, the same thing is the major cause for high upfront cost of middleware based solutions. There is a need to create mediated schema between all systems. I haven’t seen any vendor successfully solved this problem. All of them relies on partners/services and therefore, all these projects cost big $$$. With regards to reports, you are just right. Most of them done by partners/service providers. Best, Oleg

  9. Randy, You are welcome! Oleg.

  10. Dvora, Thank you for your comments and welcome to Daily PLM Think Tank! I will try to answer on your questions…
    1. In my view, we cannot limit ourselves to one of the approaches. Balance between both will be good. However, it is a bit challenge to support it in most of the products today.
    2. Semantics of data potentially can be different in each system. Therefore, integrations are trying to bridge between them. Sometimes it happens successfully and sometimes it causes to create mediated schema between all systems (this is what middleware is doing) and it makes integration very costly.
    3. Most of CAD systems today provide capabilities to create/extract BOM. Some of products (CAD-PDM) can successfully create engineering BOM from CAD.
    4. I think, “standard items” or sometimes it called “catalog” is a functionality that supported at least on several CAD systems, I’m familiar with. However, connection with ERP domain very often is problematic and requires a lot of customization in existing system to make it done.

    You asked good questions, thank you! I’m sure will use them for the future discussions. Stay tuned :)…
    Best, Oleg

  11. AndyF says:

    Oleg,

    I agree with the comments above on meeting business requirements. For example, PLM vs. ERP used to be a big deal for us. Then the management team decided to outsource manufacturing and now ERP isn’t a requirement anymore. We send the EBOM to Flextronics and let them deal with ERP issues in their systems. Production planning regressed back to spreadsheet forecasts that are emailed to Flextronics. These things are always changing and the big ERP and PLM vendors can’t really keep up with the rate of change. Sometime in the near future we might be able to get rid of all code from the big vendors and run everything on stuff developed internally using platforms such as Aras Innovator and Microsoft SharePoint. At least that gives us some flexibility to change the code on the fly to meet the new business requirements. And new business requirements seem to show up on a daily basis via email!

  12. Andy, I think you are absolutely right with regards to the issue of business requirements and changes. PLM+ERP is the topic where the gap between what possible to do today and business requirements is the biggest in industry. Things like design to manufacturing, engineering to order, etc. are in a huge danger if your PLM environment is loosely connected with ERP. From my experience, any PLM+ERP project requires lots of special skills, time and expensive software (depends on what solution you decided to choose). You either will be dependent on specialist-person who will do everything you need or on very costly software provider. Probably good compromise is to have a qualified IT staff that can handle it internally. Best, Oleg

  13. Okay UGURLU says:

    Oleg,

    Great to read such comments about PLM & ERP integration. I think, especially for the fast revising products area like home appliances, solution architects should decide where to stop about ERP integration because of the designer and production planner synchronization. PLM systems are generally CAD centric and rely on revisions which can be not the case for ERP systems.

    Let me express myself with the help of an example:

    Assume we have an assembly in AA revision.

    Designer revises the assembly by adding part X to AB revision, which is valid 30 days later for production. This data is sent to ERP by the integration.

    One day later designer faces an urgent change. This new revision should be valid 15 days later. He must add part Y to the assembly. He revises the assy to AC but… he needs it without part X. That is where he stops with two possibilities:

    A) He should revise to AC by only adding Y. Now AC rev has part X and Y. 30 day later revision AB is in charge. No Y anymore… Both AB and AC are wrong. Manual product planning effort is needed.

    B) He revises to AC by adding Y and removing X. The effectivity date is between 15 – 30 days. After that he revises a new revision; AD with adding X again. AD revision has both X and Y. The effectivity date is 30 days to UP (infinity).

    In this case, revisions are true. However by removing part X and adding it again later on, designer makes a design change depending to the past. I don’t think that such a design method is feasible for fast revising products.

    Hope my example does not seem weird.

  14. Okay, I think your scenario is ok and not seems weird. The way I’d handle it is using effectivity dates together with design revisions. For me, this is the most natural way to keep design and ERP information consistent. You can also consider adding information about engineering bill (if you need one). Does it make sense to you? What systems do you use in your organization? Best, Oleg

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 250 other followers

%d bloggers like this: