Business Process-Customization Trade-Offs
The typical approach to successfully implementing enterprise Product Lifecycle Management (PLM) solutions includes considering a number of people-process-technology related compromises and concurrent trade-offs:
- How much of the Engineering-IT landscape should be changed vs maintained or upgraded?
- What are the current pain points vs current and future business capability requirements?
- What remediation actions are required to “keep the lights on” of the current working practices, tools and technologies?
- How much change can the organisation undergo at once and what cultural risks must be mitigated?
- What modern technologies can be adopted and implemented to gain or sustain future competitive advantage?
- What are the industry trends in future technology and new business model adoption?
- What are the out-of-the-box (OOTB) solutions and how can they be integrated into the enterprise landscape?
- What are the tool and technology recommended OOTB practices vs the industry or capability ‘best practices’?
- What can be configured or customised to adapt business processes vs the PLM tools and technologies and vice-et-versa, and how to control the cost of ownership, including current implementation cost vs future maintenance cost?
- How to control the level of customisation and is it avoidable now and how about tomorrow?
- How to balance the need for low cost of ownership and the need to manage business change and adoption?
- How to manage dependencies with vendor future roadmap or product enhancement vs deploy a fit-for-purpose solution now?
The typical approach to address the above considerations imply a solid understanding of what is in the box and the ability to rapidly understand whether the OOTB capability is fit for purpose or not. As a matter of fact, it is unlikely that all business requirements will strictly align to what the OOTB solution offers. This is due to the fact that, despite most high-level requirements being almost similar in a given industry, every organisation operates differently and have distinct culture, legacy operations, budget and competitive ambitions.
Simply put, there is no OOTB one-size-fits-all enterprise solution that will satisfy each and every requirements across so many critical business capabilities and across a single industry without the need for specific controlled configuration and customisation.
No One-size-fits-all PLM: Red or Blue Pill?
There is no single, one-size-fits-all PLM solution that can meet every business requirement. You must consider two key trade-offs:
- Red Pill: Adopt the PLM solution “as is” (out-of-the-box) with its built-in best practices. This means adjusting your business processes to fit the tool, assuming the business can handle such changes—which requires careful assessment.
- Blue Pill: Define the necessary business processes and, where possible, align them with the out-of-the-box data model and core principles. Then, modify the tool through a mix of configuration and customization to meet the specific requirements.
The concept is simple, but the principle holds: the best practice offered by an OOTB PLM solution should be either a widely used process, a proven industry approach, or a new capability that aligns with specific business needs, including upstream and downstream dependencies. While choosing not to customize is a valid strategy, the reality of its execution must be assessed. Will every feature of an OOTB PLM solution fully align with the organization? The answer is often no. However, this doesn’t mean the solution isn’t suitable, nor that the organization is misaligned with the best practices built into the tool. The situation is more complex, with challenges often stemming from several factors:
- The OOTB solution may lack a recognized best practice if it’s not widely used or adopted within the industry.
- The solution may be too generic or high-level, requiring configuration or customization to fit the business context.
- New OOTB capabilities might not yet be widely adopted in the industry and may still be immature or incomplete.
- There could be bugs or issues in the OOTB capabilities that haven’t been properly addressed.
- The business expectations may not align with the OOTB best practice, leaving no room for compromise.
- High-level requirements may align, but the detailed needs might not be clear or in sync.
Organizations that strongly advocate for the red pill approach by default may hesitate to admit that the blue pill option (customization) can be more practical for some requirements. In reality, the red or blue pill decision should happen at the requirement level, supported by strong governance.
It is important to assess both what’s in the box and what is on the vendor’s product roadmap. Best practice only applies to what has already been deployed in production within a specific context, so not all OOTB solutions can be considered true best practices. Opting for the red pill and relying on the vendor for future product enhancements may lead to high dependency on the vendor’s roadmap, which is shaped by diverse and sometimes conflicting customer needs.
Product Enhancements: Customisations at Source
If customization were not possible, a PLM platform wouldn’t be open or useful for end-to-end processes. APIs and advanced configuration tools are crucial for adapting practices to the business context, building integrations, and more. There is a distinction between taking the red pill and waiting for future product enhancements, and leveraging short-term, non-invasive customization options that can save time and reduce manual work. Change requests for product enhancements are essentially customizations at source, often referred to as PLM special operations. These enhancements take time, come at a high cost (often hidden in licensing deals), and require extensive testing and implementation. The assumption is that such customizations, when handled by the vendor, are covered under the product warranty, potentially lowering the total cost of ownership. However, this assumption can be debated because:
If customization were not possible, a PLM platform would not be open or useful for end-to-end processes. APIs and advanced configuration tools are crucial for adapting practices to the business context, building integrations, and more. There is a distinction between taking the red pill and waiting for future product enhancements, and leveraging short-term, non-invasive customisation options that can save time and reduce manual work. Change requests for product enhancements are essentially customizations at source, often referred to as PLM special operations. These enhancements take time, come at a high cost (often hidden in licensing deals), and require extensive testing and implementation. The assumption is that such customizations, when handled by the vendor, are covered under the product warranty, potentially lowering the total cost of ownership. However, this assumption can be debated because:
PLM special ops are not more cost-effective than mass-produced solutions, take more time to implement, and feed the myth that an end-to-end PLM solution can be fully adopted without compromise.
In summary, PLM special ops are more relevant for early adopters seeking a competitive advantage by leveraging vendor R&D. These organizations may not be pressured by time or budget and are willing to offset risks to vendors. However, businesses must ensure that any intellectual property shared with vendors during this process is protected, as sharing too much migth contradict the red pill principle. Furthermore, even OOTB changes may require subsequent de-customisation and re-customisation.
What are your thoughts?
This post was originally published on LinkedIn on 4 February 2018.
About the Author
