xTuple.com xTupleU Blog & News Customer Support

Integrated Open Source PDM and ERP product

I assume from what little I have read of the XTuple operation that only the ERP functions of a design and manufacturing company are addressed by the XTuple offerings.

Having worked in engineering and configuration management for several large and small manufacturing companies that both designed and manufactured products, it is my opinion that a great deal of cost and effort could be saved by design and manufacturing companies if they used one master database system that handled both the PDM and ERP functions.

I am convinced this could be accomplished with open source tools but no one seems willing to attempt it.

I would be very interested to know why. Can anyone enlighten me?



Well it is a great idea to start an open source effort to integrate these two crucial parts of any enterprise, I think intent should be posted in various popular open source platforms, may be some body can help there.

It just happens to be a larger undertaking than it seems. While PDM/PLM and ERP are often found within the same environments, in my experience in the field I have only ever seen one system integrated and it was entirely written by the company who used it. That being said,  this topic has come up more than a few times recently, and continued requests do tend to draw our attention. 

I personally have looked at integrating OpenPLM, which is an open source product lifecycle management product, but one of the first hurdles to overcome is that xTuple does not have revisions at the item level, only at bill of material, bill of operation level. While this can be solved by creating a new item with the revision in the item number, this workflow doesn't always work for everyone. 

What would an integration between PDM/PLM and xTuple look like to you? What would you like to get out of the integration? Any open source PDM/PLM you have worked with?



Thanks David for the quick response.

The main reason for having an integrated PDM and ERP is to facilitate and ensure that the product shipped out to customers exactly matches the engineering released production design documentation by having the design engineering department and the manufacturing department work from the same item master and bill of materials database.
I sort of partially did this at the last place where I worked using Fourth Shift ERP, which had an engineering module front end portal based on Microsoft Access or something similar in which I populated links to pdf files of every defining document for every item number so that an on screen displayed exploded bill of material would allow a user to open every defining document for every part number including every engineering change notice record at every level of the product structure. We used item status fields to distinguish unreleased engineering items and bills from production released items and bills.
You have to have item revision levels for all bill of material parent and component items that correspond to the revision levels on your legal defining documents of record for each item, and we did. These were FDA regulated medical device products so that the absolute accuracy of our item number and bill of material effectivity dates and engineering change notice effectivity dates was critical for legal and regulatory reasons.
The people at Fourth Shift told me I was the only person they knew of in their customer base who was doing this to this extent.
In general Fourth Shift was a very loose system with a lot of functional weaknesses which I had to work around in the way I set up the configuration management process.

Every place I have worked that had completely separate PDM and ERP systems was a configuration management nightmare. You usually have to have special homemade software interconnection systems to move item numbers and bills of material via ECNs from the engineering system into the production system and this is further confused and complicated when the company decides for whatever reason to go from one brand of software to another.
At one company I went from an old IBM erp system called copics to Oracle and then from Oracle to SAP when the company was bought by a competitor. Now the competitor company that bought that company out has become a part of yet another company that probably uses something else.
Millions and millions of dollars are spent doing these conversion from one system to another and because of the separation between the engineering systems and the production systems, non-engineering people usually end up being allowed to enter data into the production ERP system that may and often does conflict with what is in the engineering system.
At the company where I had to use Fourth Shift, we had six or seven separate homemade Microsoft Access databases, several of which I had to create myself, to keep track of information that Fourth Shift could not do.
There is no real engineering or technical reason that all of that informationj, including accounting information, could not be residing in one master integrated PDM and ERP database. This would impose informational discipline and integrity on the business operation that too often is sorely lacking.
I self-published a couple of ebooks where I stated my opinions about these subjects. They can be downloaded from Amazon on 8-16-13 and 8-17-13 for free if anyone would like to glance at them. They are very short and meant to be read through quickly. Just enter “Process Integrity in Engineering and Manufacturing” and “True Product and Process Excellence Versus Fake Quality and Gimmicks” in the Google search field and they willl come up in Amazon.
I want to go to open source because I hate the stuff that is not open source for all the reasons that are described on the ERP graveyard blog.
Thanks again,
Jim Williams (tenntexjlw)

This is an interesting topic, and I think David is right that integrating PDM is a bigger technical undertaking than it appears. However, I believe the lack of interest in a built-in product actually has more to do with political constraints than it does technical ones. You could ask the same question about CRM. Why do all these CRM companies exist selling separate software when operating CRM separately creates such a mess with your data? I think the answer is just that it is very difficult in many organizations to get everybody coordinated and playing on the same page. The sales people want CRM, they want it now, and they don't want to have to talk to or coordinate with the people in accounting to get it implemented, so they implement a separate system.  I once did consulting on implementation for an integrated quality assurance system on an ERP package, and discovered surprisingly stiff resistance from QA department managers to implement that. They had moved heaven and Earth to get ISO certified and had no interest in re-implementing all that again just so they could be on the same database as the accountants. I suspect the same politics might exist with PDM.

In any case if you think there is an opportunity here we do have methodologies for building extensions on to xTuple for people like yourself who have domain expertise and believe there is value added by integrating that seamlessly into our ERP system. The next question, then, is who will either do or underwrite the development work, sell and implement the product? These are important questions that require substantial financial and time commitments from some party. If you are interested in committing time or money to getting that kind of work done, we're certainly open to having a conversation on how to coordinate with you on that.

If you are interested in learning more about how our extension methodologies work check out this page:


I look forward to hearing more about your ideas. The idea of integrating PDM with ERP does seem logical to me.


I laughed when I saw your implementation stream that included Copics. I too was involved in a company a while back that went from Macola to Copics, Copics to Oracle, and Oracle to what is today an Infor product, all the while because the company kept changing hands. It's amazing how much effort is expended by people to accommodate these acquisition transactions, with pretty much no value add at the end of the day.

Jim, I'll echo David and John's responses - we'd love to hear more about how you might want to do this.  I just wanted to point out that we do have an integration with the Arena hosted PLM solution - https://www.xtuple.com/xchange/product/arena-solutions-integration