Business Process-Technology 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 ‘Formula-Based PLM’: Red or Blue Pill?
There is therefore no ‘formula-based PLM’ that will satisfy each and every business requirements without considering the following two types of trade-off:
- Choose the red pill: adopt AS IS the PLM solution OOTB (and its related so-called ‘best practice’) and simply ‘tweak’ the business process to align to what the tool has to offer; assuming the business can cope with such change which needs to be assessed (…)
- Choose the blue pill: define the required business process (if possible without compromising the OOTB data model and core principles) and make the OOTB tool fit the requirements by using a combination of configuration and customisation solution elements.
The above is simplistic, however the fundamental principle is sound: the ‘best practice’ that the PLM OOTB solution offers must be a commonly used set of processes, an established approach in industry, or a set of new capabilities that can be explained in context of specific business requirements including upstream and downstream dependencies.
Choosing not to customise is a valid strategy, but one needs to assess the reality of its execution: will every capabilities of a PLM OOTB solution be by default fully aligned with the organisation? The answer is likely to be negative. It does not mean that the OOTB solution is not fit for purpose, neither that the organisation is not aligned to the ‘best practice’ that was implemented into the tool. It is in fact more complex than that and various challenges can relate to a set of reasons, including one or more of the following:
- The OOTB PLM solution does not have a recognised so-called ‘best practice’ if it is not used extensively or truly adopted in industry.
- The OOTB solution is too generic or too high-level and must be configured or customised to be used in context.
- The OOTB capability is new and nobody (or not many) in industry is yet using it extensively (other than perhaps the first paying customer who initiated and funded the ‘product enhancement’); it is also possible that the OOTB solution does not fit clearly into the end-to-end OOTB process or is still very immature and not fully effective.
- The OOTB capability is not working (reported bugs?) and does not appear to have been tested properly (yes, it happens!).
- The business expectation is not aligned to the OOTB capability ‘best practice’ and there is no possible trade-off (this happens a lot too!).
- The high-level requirement is aligned, but the detailed requirement is not aligned or not clear at all (…)
Organisations which strongly advocate to take the ‘red pill’ are often reluctant to admit that the ‘blue pill’ option might sometimes be more acceptable for some requirements. As a matter of fact, the ‘red or blue pill’ debate needs to happen as at a requirement level and is subject to robust holistic delivery governance.
It makes sense to assess ‘what is in the box‘ and ‘what is in the vendor roadmap for the product OOTB‘. In addition, what is ‘best practice’ can only apply to what have been previously deployed in production in certain context. Therefore, not all OOTB solutions are best practices. Going with the ‘red pill’ and expecting each and every product enhancements to be done at source by the vendor is an option. However, it will certainly imply a high dependency on vendor roadmaps and understanding of the business, while vendors usually have a robust understanding of the R&D behind their own product platform and must satisfy a large number of – even sometimes contradicting – customer requirements.
Product Enhancements: ‘Special Ops’ Customisations at Source
If customisation was not possible, the PLM platform would not be open and could barely be used end-to-end. APIs and other advanced configuration languages are important to tailor practices to the business context, create integration bridges, etc.
One must differentiate between taking the ‘red pill’ and having to wait for and test future product enhancements for the first time, whereas there are often non-invasive customisation options that can be adopted in the short term (saving time and money vs delayed deployment and manual operations). Product enhancement change requests are nothing more than ‘customisation at source‘ which can be considered as PLM ‘product special operations‘: they take time to define, develop at high cost – even if hidden in software license deal – take time test and implement later on. This is usually done on the assumption that ‘customisation done at source’ is fully covered by the vendor’s product warranty, and therefore allowing organisations to lower their cost of ownership of PLM. This is however debatable since:
‘PLM special ops’ is not different from any other special operations: they are directly or indirectly less cost effective than any mass-production solutions, take more time to implement, and help entertaining the myth that end-to-end PLM can be fully adopted OOTB without any compromise or trade-off.
In a nutshell, ‘PLM special ops’ are relevant for first adopters who wish to create competitive advantage by leveraging enterprise software R&D centres from vendors, and are not pressured by deployment time and budget, or are perhaps struggling to make though delivery decisions and wish to offset warranty risk to vendors. Leveraging business benefitsfrom being a first time adopter assumes that the business Intellectual Property that made accessible to the PLM vendor is not given straight away to everyone as part of the OOTB product platform; somewhat this can be protected using commercial contracts, however it contradicts the ‘red pill’ principle… In addition, OOTB changes do not always negate the need for de-customisation and re-customisation.
What are your thoughts?
This post was originally published on LinkedIn on 4 February 2018.
About the Author
