I’m often asked: Why can’t we use SharePoint as our PLM system? It’s a legitimate question. After all, SharePoint manages documents, has security, web interface, reporting … even a workflow. It smells like a PLM system and you already own it. So, why not?
SharePoint does informal processes very well. If you want to replace your shared network drive with a document library in SharePoint, you will not be disappointed.
But remember that SharePoint treats EVERYTHING as lists; lists of documents, lists of products, lists of customers, lists of parts… This offers no value add over your shared network drive, except now you have web interface. Hmm… so what’s really missing from SharePoint?
The #1 missing functionality is context (Configuration Management). You have a list of documents and a list of parts, but what’s the connection between the two? And how does that relationship between parts and BOMs and documents change over time (Effectivity)? Configuration Management rules are difficult to implement. There are only a few PLM systems that do configuration management well, and they all have well over 50 man-years of development each on the CM rules.
The #2 SharePoint limitation is its workflow engine. SharePoint has a simple task engine; very easy to quickly build a List of people who need to approve a change. But in the real world workflows loop, branch, loop again and need to programmatically change mid-process. That’s just not possible without heavily customizing SharePoint.
But SharePoint is of course infinitely customizable. It’s possible to build the PLM functions that are missing from out-of-the-box SharePoint. Right? Well…
One of the first things you’ll need to develop is formal Change Management controls. SharePoint will track changes and show the history of changes, but there is no concept of asking permission to make a change, which is the basic building block of a formal Engineering Change process. SharePoint lacks the out-of-the-box processes that prevent users from making random changes to documents. You’ll also need to develop the business logic for Impact Analysis, Cost Analysis and Change Request workflows. My favorite quote about SharePoint customization is from a Director of IT at General Motors. He refers to their SharePoint experience as the “SharePoint Graveyard.” Over 2,000 SharePoint sites (tombstones) created throughout GM. All are 80% finished and then abandoned when the users found out the last 20% of functionality was not possible without considerable effort and knowledge.
And then you need to ask yourself, if SharePoint is capable of PLM, why isn’t Microsoft pushing it as a PLM system? Recently, I heard a funny story about a huge Taiwan semiconductor manufacturing company who was pushed by a Microsoft sales person to use SharePoint as a PLM. After millions in customizing and a big failure, the company had to ctrl-alt-del and re-start their PLM journey from the beginning, with a commercial PLM solution. In general, Microsoft does not recommend SharePoint be used as the PLM system.
And finally, if SharePoint is capable of PLM, why did Microsoft provide joint development funding to both Aras and PTC to buildSharePoint-embedded PLM solutions? Microsoft understands that the Configuration Management, CAD Management and complex workflow capabilities of commercial PLM system are not matched by SharePoint. However, I do agree that SharePoint has a role in bringing PLM data to the extended enterprise, especially if your PLM vendor sells expensive named-used licenses. And SharePoint has a powerful suite of Reporting and Business Intelligence applications which add value to any PLM deployment.
Bottom line: SharePoint is a powerful tool that has a very useful place in your PLM strategy, however, unless you are ready to invest significant time and resources into customization (i.e. building all the PLM functionality), it is not a replacement for choosing and deploying a real PLM system.