What is difference between PLM and Content Management System?

What is difference between PLM and Content Management System?

corporate acronymsDuring last week, I’ve been discussing with one of my long time friends different types of enterprise systems. Very fast we came to the conclusion that using TLA (Three Letter Acronyms), we stack very fast, and actually we need to figure out what is practically inside and what are those systems are doing (or expecting to do). So we passed all EIM, EDM, PDM, PIM, PLM, cPDM…. I want to discuss actually comparison between Product Lifecycle Management and Enterprise Content Management Systems. I think this combination happens very often in organization and I will be very interesting to discuss and have feedback from readers of PLM Think Tank about how they see these two systems.

According to the Wikipedia:

A content management system (CMS) such as a document management system (DMS) is a computer application used to manage work flow needed to collaboratively create, edit, review, index, search, publish and archive various kinds of digital media and electronic text.[1] An enterprise content management (ECM) system is concerned with content, documents, details and records related to the organizational processes of an enterprise. The purpose is to manage the organization’s unstructured information content, with all its diversity of format and location.

Product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from its conception, through design and manufacture, to service and disposal. [1] PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise.[2] …. The core of PLM (product lifecycle management) is in the creations and central management of all product data and the technology used to access this information and knowledge.

So, the purpose of ECM is to manage organization’s information content and the core purpose of PLM is to manage all product data. So, with some simplification I came to the conclusion that both classes of systems are managing content. In my view, major piece of organization’s content in manufacturing organization is related to their products, and I’d expect product data to be hidden behind this magic word “content”. At the same time, it so called “product data” in PLM system is also sort of content, but probably very specific and related to special systems such as – CAD and BOM management. This is time to remember a magic word “unstructured” used by ECM definition. Since CAD and BOM management systems are very “structured” by nature, looks like ECM creators put fences and said “all non-CAD”… oops, content, belongs to ECM and CAD/BOM related stuff is going to PDM/PLM.

What is my conclusion from this analyzes? I think PLM vs. ECM is only small slice of enterprise system landscape. Enterprise systems successfully created so many overlapped silos. These silos and associated with these silos systems create very complex enterprise content, information, data and tools landscape. I think time is coming to rationalize this landscape.

So, what do you think? What is your company’s enterprise landscape? Do you have all possible data, product, information etc. management systems? How do you see these systems evolve in current economical situations?

Best, Oleg.

Share

Share This Post

  • Martijn Dullaart

    Hi Oleg,

    I think you have point here. We should look at functions instead of acronyms of big silos. Based on these functions we are able to decide what kind of application or part of an application to use for a certain combination of functions.

    For instance in a PLM application, there are functions to manage documents. And yes this is done in a very structured way, but is storing a file and managing versions of documents really that different? I can imagine that you use a manage BOM function and a manage documents function that are not part of the same tool, but are part of an integrated enterprise tool set. Especially with Office 2010 and Google Apps this will become more and more reality.

    The big question here is can we all agree on a standard communication protocol between all those functions?

  • Hi Martijn, Your example is absolutely correct. My point is with so many overlapped enterprise silos and functions we need to start some rationalizations. My answer on your big questions – we have no chance to agree on something your called protocol and therefore we need to find way to resolve issue of co-existence of multiple systems. This is technological problem in my view. People cannot agree and in the end have different point of views and this is ok. I think enterprise systems (and I’m taking PLM as an example) need to make change in the basics (http://plmtwine.com/2009/06/09/do-we-need-to-fix-plm-basics/)
    -Regards, Oleg

  • Tom van Geffen

    Oleg, Martijn,

    just a quick comment:

    In the last weeks several people, and several presentations have told me that the solution would be to expose functionality of (silo-)systems in the form of web-services. (there is “kind-of” a standard protocol SOA)
    This would make it possible to build light enduserapplications that use all functionality on the network by issuing calls to the services.

    It seems that a lot of (plm) vendors are “web-service-enabling” their silos

    regards,
    Tom

  • Tom, Thanks for your comment! Yes, you are right, SOA/WebServices is quite wide-adopted technological buzz behind enterprise software integration. The idea behind is that you will be able to develop so called “composite applications”. You can use ESB (Enterprise Service Brokers) and other middle-ware platforms to do so… Regards, Oleg

  • I think one of the reasons that there is a perceived overlap in these two systems is that in some cases the prime driver for PLM selection is “document control”. Most of Arena’s and Agile’s early sales were to the document control group which was trying to manage the myriad of structured and unstructured data they had historically managed in files, folders and binders. TO this group, a ECM solution does solve a significant part of the challenge (but not all) and has greater organizational buy-in for other document management tasks — in this way it is perceived to have broader utility across the organization. PLM tends to be much more specialized to engineering and operations. Agile became very successful in it’s early days convincing the doc control group that it needed more than ECM, it needed to manage the BOM and ECO structured conversations.

  • Mark, Yes, in my view early success of PLM was based on solutions going beyond “CAD document management”. So, BOM component (and you Agile example is very relevant) is significant part of success. The success wasn’t the same in different industries and fight for BOM-ownership is continues between PLM/PDM and ERP. On the other side ECM is constantly fighting for document management. Sometimes ECM merge their forces as part of ERP and adding some 3D visualization software… Bottom line – we have too many overlapped forces… Best, Oleg

  • I worked for a company which produced documents – complex technical and legal products with a long life span (many years). In addition to ECM we had a project-management application (any new version of a document is a project) and an SGML/XML publishing system (ECM tools can’t produce a high-quality and complex documents).

    Sure, there are overlap of functionally in many modern tools and often some “supportive” functionality is not “first class”.

    So, it would be desirable to have many perfect (or best of breed) specialized tools (business rules engine, BI, ESB, BAM, pure ECM, pure PLM?, etc.) and a tool (e.g. a BPM suite) to coordinate work with the use of those specialised tools around a client’s core business. Of course, a proper architecture is very necessary as well.

    Thanks,
    AS

  • Hello Alexander, Thank you for your example. I’m sure each company have their own story with implemented systems, overlaps and integration tools. This is typical enterprise landscape in my view. But, in my view, in case of ECM and PLM, overlap is going to the level that starting to disturb organization and affect performance. What is your view on this? Best, Oleg.

  • Hi Oleg,
    Yes, sure — exiting functionality of monolith ECM and PLM should be available as building blocks to be pluged into a solution optimized for a particular case. For example, almost any of modern “enterprise” products (ECM, PLM, ITIL, ERP, etc.) comes with its own workflow/process functionality. As a customer, I don’t want to pay many times for many poor solutions.

    Unfortunately, BPM (as a promise to integrate everything around end-to-end business processes) is still a vendor-centric market. So, we have to buy a horse+chariot when we just need a saddle.

    Of course, the PLM industry should clearly define its core business as a coherent and commonly agreed set of services/processes (the ECM industry is already doing this as far as I know).

    Thanks,
    AS

  • Alexander, You pointed on the fact ECM industry already defining set of services/processes…What systems/vendors are doing so? Can you bring examples? Thanks, Oleg.

  • Alexander Samarin

    A few links:

    http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services

    Java Content Repositories spec (originally JSR 170; now JSR 283)

    About archiving – http://nost.gsfc.nasa.gov/isoas/

    Thanks,
    AS

  • Alexander, Thanks for links… Oleg.

  • As a consultant, what I have seen in the last 10 years in multiple clients is a growing realization of two points which contradict the need to separate the PLM and CMS.
    Firstly, for years in multiple sectors, from Aerospace to Consumer Products, there has been a realization of the close ties between content & product data. Whether it is the procedure under which the model was created, the validation under which the formula was certified or the customer request for which the product was developed or enhanced the two “types” of data are jointly tied, and to change one without a serious look at spider web of “ties” is going to lead to re-work or questions being asked somewhere down the line. To even attempt to separate them
    Secondly, and this idea is fast gaining momentum, is that content needs to be structured. The label on a can of soup has MANY shared elements, and if you change the size of the can, all of those elements need to be taken into account. Even the cases and pallets by which it is shipped are affected! And let’s not forget the machine set up procedures and checks to make sure the right amount of soup is in the can. And why does the entire procedure or check need to change? Is it not just paragraph or element? Does one logo or the font need to be resized? The same for the automotive industry, if the wheel base changes due I not need to change the wheel base on all of my advertising? The specifications on my website?
    I have watched company after company come to, and struggle with required functionality of this realization. And now, the big players in the PLM market have finally understood and move to close this area. For better or for worse, PLM is in a better position, having the concept of structured data and the required change processes, to close the gaps.
    Where will we be in another five years? If we learn from history, we will have a merger of functionality and a new TLA.
    Thanks,
    Keith

  • Keith, Thanks a lot for sharing your experience! Welcome to plmtwine! Definitely PLM will be moving to Content Management and offer more structured capabilities. So, in potential we will see new TLA. But I see some Content management stuff related to work with unstructured data that will be needed to complement PLM offering too…. Best, Oleg

  • We use to say here that the PLM objective is to master the definition of product.
    The definition is the limit (as the word suggests it) between existence and non existence, i.e. what makes your (future) product “real” against the background.
    The definition is composed of the operational principle of the product (what the product is supposed to do and how it is functioning), and of the technological process to run to get the product (how the product must be made to operate) from the resources it catches from its environment.
    For a mechanical system, the definition is composed of the digital mock-up (the operational principle) and of the production process, i.e. the engineering configuration, that leads to the list of components the company must buy to produce it (the leaf levels of the famous EBOM).

  • Herve, Thanks for comment! I think I got your point. PLM is a master of product record. For me it make sense. However, I see it overlaps in organization with some other definitions and system deployment. Best, Oleg

  • Andre

    Hi, I am new to the DMS-/ECM and related world. Is it not possible to depict this in a one picture tick-sheet (a spreadsheet) listing the related functions vertically and the “disciplines” viz ECM, DMS, PLM horizontally?

  • Andre, thank you for your question! I think that difference is not simple and can be overlapped from various perspectives. Your documents in ECM can be related to product data, but some of PDM/PLM related info can be considered as a general content in an organization, for example, marketing brochures. The bottom line -devil is in details… However, some general rules can be defined and that’s what I tried to do. Best, Oleg

  • Nagesh

    Hi, I was talking to senior person from power plant. With “product” as “power plant” , there was discussion on whether document/content management would suffice the requirement or they have to go for PLM. This guys largly work on AutoCAD as design tool.

    Any input /guidance on where the ‘power plant” is BOM centric or content centric.

    Any link where I can get the comparison between DMS & PLM

  • Nagesh, Thank you for your reply! The word “content” is very misleading, in my view. If “content” is documents, my preference is to establish a system (you can call it BOM) that will represent the information you have. However, don’t overkill your system by complications of PLM BOM management. See what you need in terms of data representation. What you need is to build a taxonomy (structure) of information you have about your “power plant”. I think, PLM is just starting to touch this space. The fundamental believe of PLM vendors is that to manage “aircraft” is as complicated as “a power plant”. I think, there are some systems that dedicated to such a “process” oriented environment you may consider PLM. I hope it helps… Best, Oleg

  • Nagesh

    Oleg, You are right! what we need is structure of information.

    It started all with my concern that the transaction world(ERP) will requires part/BOM level info, whether it is ‘aircraft” or a “power plant”.

    so How & at what point the part/BOM is getting created & upload in ERP?
    How do i maintain the document to part relationship in such scenario?

    Doing more ‘research’ over the web, I could see solution like ‘documentum’, a matured solution for docuement management from EMC2 & SMARTPLANT from Intergraph with special module to manage the power plant challenges.

  • Nagesh, In my view, there is a certain overlap in solutions. This is a result of competition and attempts of customers to eat “competitor’s” dog food. So, you can see PLM is doing a little bit ERP, ERP is doing some PLM, content management is trying to manage more structured data. There is no strict rules. The customer adoption is the most important factor. Therefore, if a customer already have ERP in use, most probably ERP vendor will try to propose some BOM functionality to lock-in customer to use only one system. Of course, if requirements are much broader, customer may decide to get an additional solution. As soon as a customer will have 2+ solutions, the question of integration will come and all will be very dependent on organizational processes, usages, etc. Best, Oleg

  • Like Seroski said above the change management process is where ECM and PLM bind to one another and do not overlap. In our system, all product documents from the PLM ‘module'(structures or nonstructured) CAN BE managed in our ECM module, with revision control, electronic signature, etc. If the company does not want all the complete (and complicated but mandatory for ISO, FDA etc.) approval and version management, it can use a simpler document management built in the PDM component. In my point of view, if one of our competitors say their PLM system can control document as required by standard regulations they are in fact using a simpler version of a ECM built in the PLM, and not just a PDM.

  • Roberto, Thanks for your comment and insight! I agree, PLM can provide certain ECM capabilities, but cannot overlap full ECM scope. The main question I want to ask in this case is about how do you see a connection between them? Best, Oleg

  • Pingback: Wellington accommodation()

  • Haran

    In practical a product is need to design based on certain parameters in a engineering, which involves drafter, reviewer, checker,engineer,lead engineer to draw,check and approve the design respectively and if any change in the design/drawings, it will be identified by checker or engineer and the drawing undergoes a new revision for change/correction by creating design change request (DCR),if the design needs to change based on the market needs, available material and other governmental requirements, safety issues, service requirements, or functional and competitive reasons, created DCR and needs approval from client before going for manufacturing and in manufacturing needs a change in design it will come again as a DCR to Engineering and change is get approved the newly revised design/drawings are sent for manufacturing to proceed.
    the above activities/process like Engineering change management,BOM Management, Manufacturing BOM Management the total product flow from start to end done in “PLM” ..

    But IN ECM i.e., Documentum or Filenet, e.t.c it will not handle Engineering change and Manufacturing change Management, it deals with the Content management alone.

  • beyondplm

    Haran. thanks for your comment! I had to re-read my own blog… it was almost 7 years ago. I agree with your description of the process. PLM systems are designed to manage this process. At the same time, PLM systems are producing content (eg. product sales materials, specifications, tech sheets, user manuals) – this is a consumable content, which is interconnected with PLM data. Very often, there is not well defined boundary where to store this information and how to maintain consistency of data.

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll