The Multi-Headed Dragon

tiamatWhen talking large enterprise IT environments, digital backbones, and fountains/sources of truth, it’s not long before the conversation turns towards either Product Lifecycle Management (PLM) or Enterprise Resource Planning (ERP).  Both PLM and ERP visions are positioned by their corresponding champions as the indispensable key element of the digital enterprise.  But on planet reality, neither vision proves wholly sufficient, end to end.  And since both PLM and ERP have differing centers of power, most enterprises of size end up with both.  You need two coins to continue.  The backbone of the enterprise belongs to a multi-headed dragon.  Please do not taunt happy-fun multi-headed dragon.

To grasp the problem fully, requires understanding the driving visions behind the acronyms.  It’s important to emphasize that both PLM and ERP are business visions, and not the specific software manifestations thereof.  The ERP and PLM visions originated from different parts of the enterprise and have different foci, however there is significant overlap both thematically and functionally.  PLM having been birthed from Product Data Management (PDM) and CAD retains a product centric focus.  In contrast, ERP is drawn originally from work orders and supply chain activities, resulting logically in a transaction centric focus.  Too often we erect and/or stretch the limits of either vision based on what available software does (or is marketed as), ignoring the concept behind the software.  You can blame marketing for that one.  The software providers on both sides, secure in their expertise in the core of each separate vision, are now competing for the same dollars in the middle, and redefining the limits is an artifact of this ongoing turf war.  The result is needless confusion for most.

But PLM and ERP don’t play well together – because of their differing foci they are championed and implemented from different points in the enterprise at different times.  They answer to different masters.  And often, they aren’t remotely on each other’s RADAR.  Blip.  Blip.  Blip…  In many ways, Enterprise IT has been molded in the image of the very silos they were meant to replace.

And that’s where PLM and ERP often have their first awkward meeting within an enterprise… in that contested territory right between the two largest dragon heads.  Where ownership is disputed and concepts about how things should operate vary significantly.  It’s usually within some conversation about EBOM/MBOM conversion or what have you, and it’s guaranteed to have copious amounts of fire, ash, and a burninated knight or two.  And this happens at a critical inflection point in the product life-cycle: the transformation from a product centric focus to a transaction-centric focus.  While the prime focus shifts, both transactional and product models still have relevance, but the question of ownership clouds all.

Think about it, how efficient is a two-headed dragon?  Both dragon heads think they are the one in control.  The only time they can agree is when it’s time to devour IT budgets.

And it can be worse.  If other tools such as CRM or MRO join the fray, and if perhaps a legacy PLM/ERP system is coexisting with a replacement, before you know it you have your very own pet Tiamat.  Except Tiamat is a rather evil dragon deity, and generally refuses to behave (especially at dinner parties).  Before you know it, you have enough digital backbones to open a Halloween store.

Consequently, integration is often accomplished after the fact – once systems have been well established and/or entrenched in their respective silos.  The PLM/ERP digital divide is an arbitrary one largely handled by clunky custom bridges or more robust yet complicated Enterprise Service Buses (ESB)’s.  It’s rarely efficient, often a bit of a nightmare, and hard to deal with over time as software transforms in multiple directions.

In Elysium (where Jodie Foster lives), there would be one system managing enterprise data with multiple interfaces depending on whether the user is more product (PLM) centric or transaction (ERP) centric – making the distinction largely meaningless.  Of course it’s not Utopia, and there’s not one product or architecture that can handle it all elegantly, so we compromise with a heterogeneous mix of federated systems.

The very concept of one unified system does tend to make heads spin because of the pure idealism and little practicality behind it.  Besides, the simple dependence on a single vendor would be troublesome should that relationship turn sour.  But a more important point is tools must be adapted to their specific use.  After all, your MS Office suite wouldn’t be right without Word, Excel, and Powerpoint as complimentary but distinct products, right?   How workable would one office do-all product be? And would you call it Wexcelpoint or Powordcel?  Maybe Expoinord?  That’s a perfectly sensible argument, where tools are specially honed with purpose, and so it should be with the enterprise.  But that does ignore a vital fact in this example, which is that Office is usually bought, managed implemented, and utilized in a very tight package with distinct modules.  Enterprise implementations are rarely ever coordinated and software selection rarely even happens at the same time.

The single solution is a wild idea I admit – but not one that should be totally discarded, imagine a federated or hybrid combination of relational DB’s and key/value stores optimized and aligned with specific enterprise tasks.  I would love to see some interesting concepts that don’t treat the PLM/ERP as two segregated islands with traffic in-between, but rather a truly unified (and singular) digital backbone.  Sometimes we have to think a little crazy to get the innovation going.  My prices are insane!  The point is the status quo is driving complexity to a breaking point and we’ll quickly get reach a limit where only a handful of companies can afford it all.  If we’re not already there.

So, what do you think?  And what would you call an Excel/Word/Powerpoint mashup?

  • Ed I agree with your dream for a truly unified (and singular) digital backbone where PLM and ERP work seamlessly together. SAP would claim they already provide this solution, so why did not you consider them ?

    For the real solution I would like to look at the brain. The left side – logical and structured (ERP), the right side creative, emotional (PLM) with a lot of interactions between the two sides. Actually the right/left side behavior is a generalization to make things digestible from the high level, and this is what we need for PLM and ERP too.

    Now coming to the singular backbone. Here I believe the brain is again the answer. A brain never can hold all the information required as situations change. Therefore brains communicate with each other in standard collections (work / relations) or ad-hoc and they communicate through standardized interfaces (visual/sound/smell). This should be the same for an enterprise there is a need for structured connections with suppliers but also an need for unstructured information required in the context a person is working – to my opinion the search based applications.

    As you may notice I am fascinated by the brain, it is in my company’s logo and as Woody Allen said ” My brain? That’s my second favorite organ.”

    Thanks for sharing your thoughts – best regards Jos

    • BerkenG

      I don’t think that a single system is a wild idea, although it doesn’t seem to be a point that many agree with. The analogy of the brain is a good one, however I believe the PLM side is as structured as the ERP side.

      So my question is: are we talking about one system or a higher level joining of the systems, like the brain? I tend to lean towards the joining of the two systems. They do have to work together (like the brain), but they exist separately.

      We have considered pulling the MBOM into PLM in the past. ERP would still exist of course, but the two BOMs would exist and be managed in PLM. ERP would be updated to reflect… No doubt one of the clunky custom bridges you speak of.

      • Agree PLM also has structure. The advantage of PLM is that is supports unstructured activities combined with iterations till a concept, a product reached the right maturity level.

        Personally I also think we are moving away from a single system (goodbye SAP / Oracle ?) but more and more we will have a connectivity of services communicating with each other, where relevant.

        In the area of MBOM I understand the challenge – it is one of my favorite topics to discuss with customers and there is not always the same solution that fits all

    • Jos, thanks for your sharing your insight! I don’t really consider any of the interconnection technologies as a whole potato solution, because despite the robustness of the interfaces (take SAP’s), the software players on either end tend not to play nice together. That invariably means gaps, problems, and surprises often in that order. I hesitate to give it anymore than partial credit.

      The brain analogy is a truly fascinating one and worthy of exploration. Great thought indeed! Though it’s worth noting that brain lateralization (where dominance of left/right exists for particular functions) is still under some scientific research and debate. The human brain, more than anything else – seems to be ultimately adaptable and carries built in redundancy and damage tolerance. Our brains have proven to be far more adaptable, yet computing executes far faster. When computing gets fast and parallel enough, will we be able to perceive a difference? Though at today’s sophistication levels, I’m more likely to compare enterprise systems to my pancreas or kidneys than either of my cerebral hemispheres.

      As for brains for the digital backbone (gotta love all this techno-biology talk) I think you are on the right track – but I think we really need more forward thinking on the unstructured front with respect to software, because it looks all rather structured at this point in time.

      • Ed I agree with your comments – I am also fascinated by the brain and its hidden powers. Back to business, the issue is indeed often between the software players, or what I have seen in larger enterprises , the IT-department with SAP as their kingdom and Engineering with CAD as their kingdom, considering falsly that PLM is an engineering tool

        • Paul Cassidy

          Ed, excellent blog I have just stumbled upon today. Sincere thanks for the sharing!

          I am very interested in the SAP PLM/ERP question.

          Can you expand some more on why you don’t think they address the PLM/ERP divide, at least for those companies who use SAP as their ERP etc backbone.

          I can see that for some companies the PLM suite is not rich enough, (eg need rich functionality to manage a huge BOM/DMU requirement eg Boeing) but for most companies the PLM capabilities meet the key needs, and the CAD integrations are solid for Autodesk, NX, Catia, Creo and Solidworks.

          What are they missing in your vision?

          Many thanks in advance for your thoughts on this…

          • Paul you are asking the classical IT/Management question. We have SAP and we invested a lot in that, why do we need another system to do PLM as isn’t it beautiful all data in a single database in a single environment. And as you stated there is a PLM module and there are CAD integrations.

            It is like we have a van, well equipped to deliver materials, why no use our van for discovery trips on unpaved roads as we have a steering wheel that can turn it in any direction.

            Two main arguments why not:
            1. the first one is related to the above statement – usability. SAP is known for its lack of usability and for people working in the ERP domain this has been a fact to accept. Other employees in the organization (not only engineers – as PLM is company-wide) have not yet been exposed to this lack of usability as they have their flexible tools to perform flexible and iterative actions, based on outputs and findings. This is a key differentiator for PLM, you cannot can impose so much of the rigidness on the whole organization. As an example a German SAP partner has built an engineering suite on top of SAP, which looks good and has the right interface. The people working in this module do not see the SAP interface, the data is stored in the SAP database. So why not use an interface between a best in class PLM system and SAP in that case.

            2. the second argument is the single database concept. More and more it becomes clear that this is an approach of the past. Federated data, sometimes tightly integrated, sometime loosely connected (or searchable/findable) is the future. Specially in the product innovation area companies work with partner and supplier in a les structured way, until the product gets formalized and manufactured. These, sometimes conceptual interactions do not fit in a transactional system.

            For me PLM and ERP are equally important and I will consider SAP as a PLM company once PLM is considered as important as the core modules instead of currently as an add-on. As soon as there is a PLM voice in the board of directors of SAP there might be a change.

            Coming back to the brain analogy. The SAP brain is the logical and structured part and if this one would be the only one, you get an autistic person. Outperforming in a certain skill, but unaware of other even so required human skills

          • Thanks for stumbling on by Paul. Welcome.

            Jos has provided some solid reasons with his usual elegance. I completely agree with him. But I’ll also add some of my own thoughts:

            The chief problem I have with the “PLM” capability within ERP is truth in labeling – it’s really integration of CAD files, and not really PDM nor PLM which is really across the enterprise.

            It’s kinda of like your favorite coffee pot maker found out you also eat french fries. So they manage to figure a way you can stuff a small cup of french fries in the coffee maker and fry ’em up. Technically it works within limitations but of course, your fries taste a bit like coffee. And then you realize half the time you try to make fries it breaks – and then suddenly you’re coffee tastes like cold potatoes in oil.

            I’ll pick on SAP a little here – but their expertise and vision is in the transactional space on the business end. Anything related to configuration and visualization of product they’ve had to acquire and bolt in, like what they did with Right Hemisphere. Up until recently all CAD integrations were strictly third party affairs.

            So with respect to the product space, where configuration and robust revision control is really important, you’ll find there are far too many limitations derived from certain immutable db schema choices on the ERP side. More disturbingly there is no vision of anything else. And if there were a vision it would be one based on an entirely different transactional paradigm. They are two different worlds with different problems and solutions.

            For companies that have a simple enough product that they can get away with it… I think it to be a rather narrow case of some particularly one-sided companies. Many of the simpler firms are small enough that they can’t afford ERP anyway… So they are using either a boutique solution or they are still banging rocks together with spreadsheets. You’d be surprised how far some companies get with rocks.

  • Ross Bernheim

    There are different requirements for how data is handled as well as what data attaches to a part or BOM between ERP and PLM. While the part or BOM may be the same, these different and sometimes conflicting requirements would make a single database overly complex even if all the conflicting requirements could be met.

    Requiring PLM to communicate with ERP is a part of the solution, but often overlooked is defining what the common information requirements of the ERP system and PLM system are as well as the additional requirements of each system.

    ERP, specifically accounting systems have strict requirements as to keeping things in line for accounting and tax purposes. What can be altered and when is most important. Who has access to what portion of the system is important to ERP.

    PLM lets you change things, but keeps a history of who did what when. PLM needs to store a lot of additional information that is quite often not well structured. Part data sheets, RoHS information and so forth. PLM quite often is used to also manage content such as user manuals, test procedures, assembly procedures, deliverable software images, etc.

    When we have some idea of what is required by each side of the coin as it were, we can try to communicate how what anyone on either side of the PLM/ERP divide does and how it effects the other and try to get people to think beyond their immediate silo and work towards a common goal.

    Does the engineer fully comprehend cost, availability, compliance issues when they specify a part? Does the purchasing person communicate with the engineer when they design in a hard to get or expensive part? Do the manufacturing people communicate problems back to engineering?

    Are changes in engineering or manufacturing communicated back to both PLM and ERP databases?

    The business needs to be treated as a whole and both ERP and PLM must work towards improving the business as a whole, not just making life easier for one portion of the organization or another.

    • Ross – the different schema approaches are certainly one of the obstacles that has kept the two domains separate – but DB technology has been rather creative of late – there are increasingly interesting ways to provide the flexibility for the data that’s not quite so organized while still maintaining the integrity.

      I think the communication examples you cite are spot on – that’s the richness of information that supports the need for a singular digital backbone.

  • beyondplm

    Ed, great article. I think, tension between PLM and ERP is getting more and more interesting. The integration is not simple and very challenging for everybody. Some of my thoughts are here – 3 steps how to put PLM and ERP each in their place. http://beyondplm.com/2013/03/14/3-steps-how-to-put-plm-erp-each-in-their-place/
    Best, Oleg

  • Ross Bernheim

    I think we are looking at the problems from the wrong angle. I think we first need to specify the needs of the different players in the ‘enterprise’. Engineering and product development have one set of requirements. Production has another set of requirements. Purchasing another set. Inventory management another. Accounting another. Management has another set and QA and compliance yet another set.

    Defining these requirements and seeing how we can assign them to as few databases that will fulfill everyone’s requirements with the least effort and overlap will be a good start. It will also allow us to figure out what and how information should flow. This will allow for minimizing the number of communication bridges needed as well as helping to assure data integrity across the enterprise.

    • Ross, I’m pretty sure they do this in Elysium, but the challenge on planet reality is how to objectively collect and analyze the various requirements across all those individual silos you just mentioned. What’s typical is they each participate at different times and with different buckets of money – the end result is more bridges and less unity. Usually the bigger the company, the nastier the dragon.

  • pgarrish

    I think your analogy with Office is interesting. But the main difference is I rarely work on the same data with more than one Office product. The closest is probably a Mail merge of addresses in Excel into a document in Word. The reason this works is that the responsibilities are clearly delimited. For me that is the crux of the PLM/ERP debate – yes it is ownership, but it is ownership of a task, not the data. Perhaps if we defined the boundaries of PLM/ERP based on actions, not data, we could make them fit. And it has the added benefit of not being based on WHERE the data lives – if I own the TASK, I don’t necessarily care where the data lives.

    • One example I can recall is working Visio with Powerpoint – that’s something that I’ve dealt with considerably driving flowcharts for presentations but maintaining the editable control for which Visio excels at.
      But I like your thinking. The problem is that requires either a shared data model or at least respect for each other’s data models from a read/write perspective to support the task at hand. Considering how long it took just for disparate applications in PLM to appear in a unified db, the outlook for this level of integration probably isn’t great.
      But I also recognize that is one of the larger challenges of Big Data – so divorcing task ownership from data ownership may yet be achievable.

  • Pingback: A Red BOM Rises | E(E)()

  • Pingback: Put Your PLM in the Box | E(E)()