As I circulate through the Product Lifecycle Management (PLM) community I encounter numerous opinions about customizing PLM. We are encouraged by our vendor partners to use the word "configure" instead to prevent spooking prospective customers with visions of science projects and million dollar implementations. I am concerned however that customization is getting a bad rap and that if we are really honest about PLM customization it is an essential part of PLM deployment. This blog will analyze the benefits and challenges of customization and answer the question of whether customization is indeed an uncontrollable monster or an essential and valuable aspect of any effective PLM installation.
Keep in mind there are varying levels of customization. Ideally, customization should be limited to automation or integration activities and should not be something that dramatically impacts the core functionality or user interface of a PLM system. I have seen examples where companies dramatically altered their PLM systems by changing the interface to the point that it was almost unrecognizable from the original system. Generally, these types of projects ended up being extremely costly but more importantly the software becomes the responsibility of the client instead of the vendor. Future upgrades become virtually impossible. With the maturation of PLM software I see less and less of these types of situations but their legacy tends to bias IT and PLM resources inside some companies. Their past exposure to costly customization causes them to react negatively to any type of functionality that might involve new software code being written to automate process or integrate between systems. While it is a good idea to proceed cautiously with any type of software add-on to PLM this type of approach should not be rejected out of hand.
One type of customization that is widely adopted in the PLM space is the process extension (PX). Typically, process extensions are script based tools that combine multiple functions in a PLM or blend external functions like spreadsheets or reporting tools into the PLM system. PX's are usually fairly straightforward and consist of a few lines of code. Oracle has extended their PLM system to support Groovy Script for these applications which creates some positives for creating and some negatives for maintaining PX's. Other PLM vendors offer various ways to support some types of limited customization or as they like to say "configuration". The point is that in general, process extensions and the like are very valuable and useful types of customization. They allow companies to fill in the gaps of missing functionality and to automate tedious tasks. The release cycles of most PLM tools are 12-36 months so even if a missing piece of functionality is identified by a PLM vendor chances are it will be a while before it shows up in the core application so having process extensions can be essential for a fully optimized environment. Another area where process extensions can be useful is in importing and exporting information. Governance and compliance is a rapidly shifting landscape and it is virtually impossible for PLM vendors to keep up with the constantly growing material standards. Customization tools like process extensions allow companies to leverage PLM for compliance while staying current with the latest regulations. There are numerous examples where small automation scripts can be extremely valuable to productivity and functionality for PLM.
There is a dark side to customization for PLM. We have already discussed the pitfalls of wholesale user interface overhauls and what that means. Even customization on a smaller scale can create havoc when it comes time to upgrade. You also have the issues of fully understanding how your customized tools function in your IT environment. All it takes is one overly aggressive antivirus install and your entire PLM system could be shutdown. You also need to have access to source code for the applications in case you need to recompile to work with newer versions of your PLM. Many PLM installations look like a geology sampling of the earth. You can see the various layers in time where certain external or internal groups worked on the systems but it is all in a natural evolutionary state. When you decide to modify the "out of the box" configuration for PLM by adding automation or integration applications it is mandatory that you map out a comprehensive strategy around how you will develop and document these application and where they will live on your system. You will want to store the source code in a safe place probably multiple places and you will want to include readme documentation on how the customization was built and what it is supposed to do. This seems like common sense but I have yet to find a company that has taken these steps when it comes to customized applications for PLM.
Frankenstein was a cautionary tale about man's hubris in attempting to create life. Obviously customizing PLM tools isn't on that scale but we have the same risk of creating a monster that can't be controlled. Careful planning will allow companies to experience the full benefit of PLM by tailoring it to meet their product development needs. Keeping track of what you have developed and how it was built are the first steps in building out an environment to support the custom aspects of PLM. This is a healthy and reasonable approach to ensuring that you have the capability you need without generating unreasonable overhead for maintaining your PLM environment. If you follow these steps you'll really be "putting on the Ritz".
[Edit: Repost from 2011]
[clear-line]
[one-half]
Learn more about our automation tools!
[/one-half][one-half]
[/one-half]