What is difference between PLM and Content Management System?

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?

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

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.

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

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

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

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

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).

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?

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

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.

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.

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.