The PLM Insider
Jyotirmoy Dutta works as a PLM Lead Consultant at Infosys with more than 13 years of expertise in PLM Strategy Consulting, Solution Architecting, Offshore Project Management and Technical Leadership. He has led several full life-cycle PLM implementations, in the Consumer Products, Electronics & … More »
Understanding PLM System Customization
July 3rd, 2012 by Jyotirmoy Dutta
I have worked on PLM applications for the last decade, by and large in the implementation and customization side. Customizations have been and are often pigeonholed as the problem child of PLM. Many argue that the best way to put into service a PLM system is to have it implemented “out-of-the-box”. However, when business processes in an organization cannot be effectively and efficiently modeled in a “vanilla software” PLM system, the impact of an assessment whether to or not to customize becomes pertinent. I write this post based on my familiarity with PLM customization in diverse implementations.
Definition of Customization
I would conceptually characterize customization as an alteration put into place because the “vanilla software” PLM solution does not reflect the “desired” business needs. Changing packaged software to meet user needs is the essence of customization.
Decision to Customize
PLM systems are packaged software solutions and not customized systems. Packaged solutions traditionally involve software and/or services tailored to achieve a specific scope of work and are intended to meet the broad-spectrum needs of a class of organizations, rather than the unique needs of a particular organization, as is the case in custom software development. By adopting standard packages, organizations substantially reduce the costs, risks and delays associated with custom software development, and benefit from the on-going support services provided for packages by vendors. Conversely, packaged solutions come with built-in assumptions and procedures about organizations’ business processes. These suppositions and rules seldom tie in with exactly with those of the implementing organization’s existing processes. The so-called “industry best practices” embedded in PLM systems is hardly universal – the misfits between business requirements and PLM capabilities can be company-specific, industry-specific, or even country-specific. Any successful PLM implementation requires a fit between the PLM system and the organizational processes it supports. A divergence can have substantial bearing on organizational acceptance, and could be one of the main reasons of a PLM implementation failure.
More often for misfits, customization is the way out. PLM system customization can ensue either during the implementation phase when the gaps are well-known or after roll-out, when the system is operational, and as a response to changing business needs. Customization at times offers the ability to obtain competitive advantage vis-à-vis companies using only standard features. However they come with a cost and risks. Hence the assessment to customize is complex and is so made with a trade-off in mind.
Types of Customizations
I would categorize most of the customizations I have seen or done in the following order:
1. Configuration Customization,
1.1. Pure Configuration Update
2. Process Customization (Workflow Programming), and
3. Technical Customization
3.1. Extended Reporting,
3.2. UI Customizations,
3.3. PLM Programming,
3.4. Interface development,
3.5. Package Code Modification
Let us look into each in more detail:
1. Configuration Customization: I would subdivide this customization into two sub types:
a. Pure Configuration Update: This type of customization involves setting of parameters, properties etc. Examples: Server settings, logging parameters etc. It usually is benign, and affects the application and sometimes the database layer. Such updates are vendor supported too.
b. Bolt-Ons: Bolt-Ons are third-party packages designed to work with the PLM system from independent software vendors (under license agreements with the original PLM vendor) to meet the needs of a particular customer segment and provide specific functionality. Example: The ShapeSpace 3D Search tool for Aras PLM which extends the searching capabilities of Aras to enable searching by shape or FLUENT for CATIA V5 software brings fluid flow and heat transfer analysis into the CATIA V5 product lifecycle management (PLM) environment. The quality of the bolt-on depends on the quality of the relationship between the PLM vendor and the bolt-on developer. Note that there may be a “release lag”, where the bolt-on vendor is supporting an older release of the PLM system that the one the PLM vendor is currently offering to customers. This is likely to be an issue during PLM system upgrade.
2. Process Customization: This type of customization involves Workflow Programming – Creation of organizationally unique workflows or customized logic in standard workflows. Example: Set up automated engineering change order approval process. This typically affects the application layer and/ or database layer.
3. Technical Customizations: These are code changes that the vendor usually does not support and can be split into 5 categories:
a. Extended Reporting: This type of customization is programming of extended data output and reporting options. Example: Design a new report to show the health of each project and compare it to the time taken in each portion of the change management process for specific criteria. This typically affects the application layer and/ or database layer.
b. UI Customizations: This involves changing the UI Look and Feel or functionality and changes to terminology and layout. Such customizations might occasionally add extra business logic specific UI validations too. I was consulting for a major medical devices manufacturer in 2006 – they had decided to upgrade their old PLM system with two major versions in a single upgrade. Fearful of adoption and training issues in their 7000+ user base they resorted to reprogram the UI to look as much as possible as the original system even though the new system provided with lesser picks and clicks.
c. PLM Programming: I would define this as programming of additional applications, without changing the product source code (using the computer language used by the vendor). For example if there is a requirement to detect when a particular event happens in the lifecycle of a drawing or a product and to take further actions based on that (which the PLM system doesn’t support) then one would need to resort to such programming. This typically affects all layers.
d. Interface Development: Programming of interfaces to legacy systems or 3rd party products when such interfaces are not available off the shelf. I have implemented interfaces with custom-build MRP package or with an archaic CRM package. This typically affects the application layer and/ or database layer.
e. Package Code Modification: This type of customization is atypical, and involves changing the product source-code – ranging from small changes to changing whole modules / functionality. An example would be changing of the system behavior when a CAD file is checked into the system from a CAD tool. In 2004 I was consulting for a Taiwanese OEM and the PLM tool they were using was quite immature as compared to their requirement – leading to vast amount of changes in the underlying product. Product source code was not available – we had to decompile the code to make modifications. Needless to say such customizations point towards a bigger issue which I will discuss shortly.
Risks of Customization
The risk impact of customizations can be classified as underneath – The deeper the customization the higher is the impact and likelihood of risk.
If customizations are built as part of a development effort during an implementation time frame, they may have bugs which can impediment development during the PLM implementation, and thus distress a successful implementation (e.g. overspent budget and an unreliable system due to poor quality of customization, unresolved system bugs and insufficient testing). Also note that there is supplementary end user training and consulting costs towards adoption of customized code. By and large, less customization will mean shorter implementation times.
Over-reliance on heavy customization suggests a deeper problem – It can mean that due to poor PLM selection and evaluation process, the software is ill-fitting with the business requirements.
Customization of PLM will have maintenance and upgrade impact too. The more complex a customization endeavor the more likely it is to require greater effort in maintenance and post-implementation. Each time a change/upgrade is required to the system, the effect of the change on the customization will have to be assessed by the organization, as the software vendor will not support these customizations. Many times, this requires bringing in an external expert to help with this assessment. Once the system is upgraded the customizations would have to be manually updated too. These additional requirements reduce flexibility or agility of the system and increase costs.
The following table presents an estimate, based on experience, of the effort needed during system maintenance and post implementation of different customization types.
Another associated issue is poor consultant effectiveness. Poor consultant effectiveness will contribute to mediocre quality of code customizations (and associated documentation) and inferior knowledge transfer of the customizations to the organizations IT resources. This in turn leads to higher maintenance costs. The better the knowledge consultants have about their PLM package, the more likely they are to address business objectives with light (and probably configuration driven), rather than (code driven) heavy, customizations.
Configuration vs. Customization
Customers are almost always better off in choosing a PLM system with an open architecture, one that can often be adapted with relatively uncomplicated configuration changes rather than code rewrites. It is vital to realize the key differences between customization and configuration to appreciate the benefits:
Wrapping up, organizations should steer clear of a dash to customize. It is to be expected that any new PLM system will have inadequacies, both factual and alleged. All workarounds and alternatives should be investigated first before making a commitment to changing the system. It is important to take into consideration that though customization might bring in a competitive gain, there are risks and costs associated with different types of customization. The heavier the customization is the riskier and costlier it becomes.
2 Responses to “Understanding PLM System Customization”