Going digital: to customize or not to customize?
Digitalization strategies include the selection, design, build, test, deployment, continuous improvement and maintenance of enterprise IT solutions, such as Product Lifecycle Management (PLM), Enterprise Resource Planning (ERP), and other enterprise solutions like Manufacturing Execution Systems (MES) and Customer Relationship Management (CRM) solutions. While there are differences in implementing PLM and other enterprise platforms, there are also many similarities.
Enterprise drivers for digitalization often include the need for:
- Application consolidation or modernization: replacing obsolete solutions, integrating or harmonizing application landscape, including front end and back end IT solutions
- Digitalization and business transformation: implementing operational changes, including both front and back end processes, focusing where most business benefits can be realized (ref. the PLM business case)
Digitalization is the use of digital technologies to change a business model and provide new revenue and value-producing opportunities: the process of moving to a digital business. (Gartner)
Digital transformation includes technology innovation, customer behavior and demand, external environmental factors, from front to back end processes, focusing where most business benefits can be realized.
Digital transformation implies fundamental change in an organization’s operations across the people-process-technology stack.
Digital transformation implies that changes are to be implemented across the people-process-technology stack (aka the “golden triangle of change“). Typically, this requires the adaptation of enterprise applications, such as PLM or ERP solutions, so that capabilities are aligned with the required processes and organizational alignments. Integration and configuration / customization are often inevitable means to implement business requirements, though they must be controlled and minimized.
Typically, configuration is about behavior adjustments and non-invasive valorization, while customization is rather perceived as filling a capability gap, such as in terms of lifecycle business rule, workflow or integration requirement. This “gap” is actually not simply about “capability”; it also includes differences between business expectations and technology state-of-the-art (“what’s in the box”).
- Align Out-Of-The-Box (OOTB) technology with internal practices
- Develop or tailor workflow, attributes and required automation to gain further advantage or business benefits
- Fill capability or technical gaps
- Ease data migration or other interface operations
- Integrate apps and processes across the enterprise capability landscape, especially integration across boundaries and with third party apps
- Focus on the business differentiators to create unique competitive advantage (above and beyond what others would be getting from the off-the-shelf solution)
Why not customize:
- Adopt off-the-shelf technology vendor-led best practices
- Focus on configuration to ease future compatibility and upgrades
- Minimize total cost of ownership (implementation and maintenance cost)
- Transform processes (business tradeoffs), align skills and organizations to technology best practices
First, understand “what’s in the box” (i.e. off-the-shelf technology-led ‘best practices’ and how to adapt and adopt them)
Typical PLM implementations concern how much of technical OOTB capabilities or solution elements align with business requirements, and how much configuration and / or customization is required to tailor the system to the required process designs.
- Should the business processes be adapted to the enterprise software vendor so-called best practices?
- Should the enterprise software be configured and customized to be tailored to the required business requirements?
There are different types of customization, from simple to complex, more or less invasive, from fairly easy to maintain through software configuration to expensive bespoke customization.
Some organizations customize enterprise software to the way they work or the way they think they should work; rather than focusing on understanding the reverse: how to adopt ‘off-the-shelf best practices’.
Zero customization solution: myths and legends…
One can assume that PLM editors, which have invested billions of dollars in the R&D of their product suite, have captured and capitalized on industry best practice as well as digital leadership. It does not mean that there is one-size-fits-all in using PLM solutions. “No customization” is one of the most common mantras about PLM (and ERP) system implementations; strictly speaking, zero customization does make sense as it hinders competitive advantage.
As utopian as a zero customization PLM implementation may sound, the unfortunate fact is that most organizations customize their PLM systems – at least to some degree.
No matter how mature any given software may be, it is not going to address 100% of any organization’s needs. PLM product enhancement requests sent to PLM editors are also customizations that one (the requestor) will be paying for in intensive design and testing – as the first adopter often pays the bill of validating in-situ the enterprise solution. Customizations done at source are not always going to be adopted by all other users. Product enhancements will often need de-customization of other workarounds or dependencies, and re-configuration or even re-customization to be tailored to the final wanted state or behavior.
Considering these factors, it is worth noting that most complex so-called product enhancements or “under the hood” customizations done directly by PLM editors are likely to cost more than normal “approved customizations” done by PLM services providers who have experience in designing and coordinating the required tradeoffs for successful implementations.
Implementing PLM involves tradeoffs between flexibility and standardization across organizational functions, tradeoffs between one system for all versus a best of breed or hybrid approach, and a host of other compromises.
There are different types of configuration-customization, some are more invasive, complex and costly than others. PLM customization can create problems during implementation as well as after implementation and deployment.
Controlled tradeoffs between process and tool change; controlled customization
Measuring the level of customization is always a subjective and difficult activity which can take into consideration some or a combination of the following parameters:
- The number of API used
- The volume (lines of code?) of code modified
- The number of modules or libraries which have been modified following a range of specific coding principles
- The number of hours spent in the customization implementation (design, build and test)
- The number of ‘tradeoffs’ requiring tool adaptation – monitored through formal change management of impacted requirements and use cases
- The number of approved customization change requests implemented, by type of customization / configuration
- The number of non-standard or non-OOTB features, capabilities or requirements
- The number of integration points and usable bridges
Despite being qualitative, the above is mostly subjective and can only be compared in the same context, which is closed to being “most likely” impossible – unless implemented by the same party.
Most PLM solution providers recommend that customization be entirely avoided, and that configuration be minimized, as much as possible… (CIMdata)
This is therefore a matter of preparing for people-process-technology capability tradeoffs. It is clear that heavy customizations need to be avoided, independently of whom is to implement them… including the software editors / vendors themselves, even if they promise to include them in their standard OOTB offering in the next few releases. As a matter of fact, any client driven product enhancement will have to be evaluated against the primary default intent. It will require standardization and tradeoffs against other client’s expectations and requirements.
Whenever an enterprise software is upgraded, there is a risk that the custom code might no longer be working, and that it might require significant rework to be made compatible. It is obvious that heavy customizations can hinder upgrades and add significantly to the total cost of ownership. For these reasons, it is usually better to stay with the “plain vanilla” version of the software with controlled and approved levels of customization only. Successfully implementing enterprise PLM is partly a science and an art – in controlling interdependent requirements and their related configuration and customization tradeoffs.
What are your thoughts?