How to Decustomize PLM?


Customization is one of the most favorite topics in PLM. Back 20-30 years ago, product data management (PDM) was born as a toolkit. Earlier PDM implementations took months and required deep changes in PDM system code and behaviors. It was leading to a growing complexity of implementation, highly sophisticated implementation skills and time. What is even more important and dangerous it was a reason many PDM/PLM implementations stuck in the back and failed to upgrade to newer versions of PLM software. I expressed it in one of my old articles – Is PLM Customization a Data Management Titanic? My guess back in 2010 was that future flexibility of data management technologies should make future customization and updates easier.

Customization problem exists in other domains of enterprise software. I found an interesting example of how extensive customization can damage enterprise software deployment and implementations. CMSWire article 6 Predictions for SharePoint, Office 365 in 2014 speaks about adoption of SharePoint 2013. One of the prediction speaks about SharePoint customization or actually… decustomization. I found this passage interesting:

We’ve heard Microsoft strongly suggest not to customize SharePoint, that branding doesn’t improve user experience or make processes better. That migration to new versions is easier without a lot of customization. The new SharePoint 2013 app model is also a strong pointer from Microsoft to keep SharePoint as out of the box as possible and focus on using Apps for additional customizations.

I think this is a good thing. Many of the challenges we see with migration projects are the result of branding and customizations — some of which may not have been necessary. Part of the reason SharePoint has been customized in the past is that developers are learning to use the platform and trying new things. The new App model reduces much of this, putting the testing and learning outside of SharePoint directly.

It made me think again about PLM implementation and customization projects. For the last decade, PLM vendors put a lot of efforts in developing of out-of-the-box offerings and strategies. Marketing used different names for this activity – from "express solutions" to "industry offerings". In my view, the result was somewhat mixed – it simplified PDM implementations and some smaller PLM deployment. At the same time, many even relatively smaller PLM implementations are still far from go simple way. In my view, the best confirmation to that is growing interest in acquiring service and consulting companies by PLM vendors. The last one was Siemens PLM acquiring TESIS PLMWare focuses on PLM integrations.

What is my conclusion? Decustomization of PLM will be one of the most important elements in the future PLM infrastructure improvements. To make implementation cost effective and to support future cloud deployments, PLM vendors will have to invest in technologies and methods to simplify deployment, flexibility and speed of implementations. Just my thoughts…

Best, Oleg

2 Responses to How to Decustomize PLM?

  1. Devanaga says:

    Nice blog topic as always. My 2 cents.

    I am surprised that share point blog points out that customization was done by developers for trial and to learn features. Really ? This shows absence of well proven Dev,Test and Prod environments and change control to prod environment is all together missing.In that case I would think its a process issue rather than customization issue.

    In my opinion, whenever PLM upgrade happens, there has to be conscious effort on several activities. Some of the things that I can think of

    – If the system is legacy, first and foremost thing is to make sure there is master document list of all customizations, to which area it belongs, impact on system, how many typical users etc.
    – Review each high level customization and evaluate its relevance in today’s context of the system.
    – Review new features and significant architectural changes in version of software chosen to upgrade to. Some times introduction of new preferences in system could alone result in obsoleting customizations.
    – As rightly pointed out by you, there are several features which can be achieved by configuration. Carefully review and see which customization can be obsoleted.
    – Re-review people, process and system for opportunities to simplify. Re negotiate with business team if there are reduced functionality due to decustomization and address training needs.
    – Make sure the organization’s PLM road map aligns with PLM vendor road map.

    Lastly, upgrades can be nightmare from customizations point of view if current system is in Lava Flow state. Anyone customizing should keep in mind that maintenance phase is going to be much much longer than development phase and make sure proper SDLC processes are followed. Also ROI for new customziations should be carefully evaluated.


  2. @Devanga, thanks for your comment and insight! I agree, customization is a nightmare. Sometimes, you cannot avoid that. The question how to make them painless is still relevant. Best, Oleg

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 290 other followers

%d bloggers like this: