Humpty Dumpty sat on a wall, Humpty Dumpty had a great fall, all of the consultants and IT resources couldn’t put Humpty together again. I know it doesn’t flow as well as the original version but it is more relevant for this article. Throughout the history of product lifecycle management (PLM) companies and vendors have struggled with the challenge of enhancements to the “out of the box” versions of PLM software and the issues that are created by customization. Most experts strongly discourage customization of PLM or for that matter, any enterprise software but unfortunately business requirements and productivity needs usually prevail and most clients find themselves with a patchwork quilt of process extensions and scripts that optimize their PLM system for their companies. Most of the time these enhancements deliver positive outcomes otherwise they would not be so prevalent but there is always a downside to this part of PLM. This article will review this downside and what companies can do to mitigate the risk.
Before we get into the risks of customization it is important to understand the definitions of customization in regards to PLM. I came across and excellent article by Jyotirmoy Dutta who was at ITC Infotech at the time he wrote the article and is now a program manager at Stryker titled Understanding PLM Customization. In his article he defines customization as “changing packaged software to meet user needs”. He also attributes the need for customization as due to the failure of “vanilla software” to reflect the business needs of the organization. I think this does a pretty good job of capturing the high level definition and motivation for customization. He goes on to break down the types of customization as follows: Configuration, Process, and Technical. Specifically, configuration customization addresses solutions that ease the administration of the PLM tool and also provide pre-packaged application used to integrate with other systems. This might include applications that set parameters of permissions for items as they are checked in and third party solutions that allow data to be brought in from CAD PDM tools or application that enhance search or reporting capabilities. Process customization is defined as something that usually interacts with a PLM systems workflow engine. He uses the example of automating the approval of engineering change orders. These types of customizations are typically very specific and are driven by business processes. There are some situations where automation can be put in place that supports best practices and enforces standards. This type of process enhancement can be somewhat similar to the third party integrations he talks about under configuration. The last area highlighted in the article is technical customizations. This includes user interface enhancements, custom reports, custom built interfaces to 3rd party solutions and package code modification which I think are very rare and should be avoided if at all possible. There may be some alterations that fall outside of these categories but overall I think this is an excellent summary of the type of modifications I have seen deployed for PLM implementations.
Now that we have a good understanding of the type of PLM customizations that are typically developed then the next logical question might be why are these even used? Shouldn’t PLM systems be flexible and configurable enough to accommodate almost all vital business needs and use cases? Certainly as PLM has matured the core capabilities of most of the PLM technologies available have expanded and a majority of things can be done without requiring some sort of custom process extension. However, there are still gaps and there are always unique aspects of process. To quote the article “Any successful PLM implementation requires a fit between the PLM systems and the organizational processes it supports”. It is not accidental that most robust PLM solutions offer an equally robust Application Programming Interface, (API) that allows for automation and extension of capabilities. It is also no accident that almost all companies that use PLM take advantage of this API to tailor their application to improve productivity and adoption of the PLM solution. The real key to customization is not that you don’t do it but that you do it properly.
What are the risks of customization? Why is it such a bad thing? When done in the typical fashion you can run into several pitfalls. The first risk occurs when initially deploying PLM. Highly customized elements of your deployment can lead to long lead times for go live and for the potential to have bugs and shortcoming around the customizations. It is generally a good rule to minimize up front customization until you have a system in place and can get real time feedback on where the gaps are versus trying to anticipate them up front. The next challenge comes with who and how you develop customizations. There are numerous resources both internal and external that have the ability to write scripts or process extensions for PLM. Larger companies will have IT staff resources that have programming backgrounds and can support user requests to address software functional gaps. The problem with this method is that typically the turnover in these positions can be high and documentation can be scant when it comes time to upgrade your PLM software. Also since these types of resources work with numerous systems there methods may not be the best when it comes to automating the PLM tool. Another method of customization would be to use external resources to write code for you. While these types of resources may be more familiar with the PLM tool and the API and thus deliver a better solution you still run into issues around lack of documentation and each developer will have unique methods that will create inconsistency in how scripts are written. They also typically do not have much incentive to provide documentation or source code. These issues will start to impact companies when they try and upgrade to new versions of software or change their processes. Without consistent methods and thorough documentation it can be very challenging to transition customizations to new versions of PLM software or make modifications to code to accommodate new use cases. Ideally, using tools that enforce a consistent approach for customization and ensure the ability to make changes are necessary to sustain PLM customization. Based on our experience with the shortcomings of customization but faced with the reality that it is necessary for companies to be successful with PLM we have developed solutions in this manner.
To avoid Humpty Dumpty syndrome you can either avoid customization entirely or ensure consistent approaches to customization. This can be accomplished through discipline and diligence and can be enhanced by using frameworks that optimize your ability to create and change your extensions. The future direction of PLM is to offer the flexibility to accommodate business requirements to maximize efficiency and minimize tedium and user errors. But it must be done in a manner that is sustainable and supported as companies and PLM software continue to evolve.
Learn more about how to mazimize efficiency and minimize tedium and user errors!
