Assessing the Need for Enterprise Platform Customization
Enterprise digital platforms include PLM, ERP, MES, CRM and other solutions, none of which typically operate in isolation. Data flows across these platforms as business function collaborate throughout the product lifecycle, from introduction to development and industrialization, relying on data continuity and a robust integration backbone, a.k.a. the Digital Thread. Each platform has built-in ‘practice intent’ per its respective out-of-the-box (OOTB) capabilities.
Most mainstream vendors provide ready-to-use open APIs, low-code and other development environments, including both configuration methods and customization frameworks to adapt and expand OOTB capabilities to business needs. Minimizing customization is always mandated to reduce complexity and control total cost of ownership with future upgrade; it does not mean that customization is not acceptable, but that it should be continuously controlled.
In this post, I discuss how to assess the need for enterprise platform customization: where to start, how to understand OOTB capabilities and behaviors, how to control current and future cost of ownership when implementing advanced customization and integration bridges?
There are typically different schools of thought when it comes to platform customization:
On one side of the spectrum: avoid customization like the plague, stick to the OOTB solution, especially if it is on a shared multi-tenant SaaS platform.
On the other side of the spectrum: accept heavy customizations, including data integration and interfaces, to fill perceived OOTB gaps.
The reality is often in between the two sides: the need for customization should not be considered as a showstopper, but an opportunity to understand how the platform is meant to be implemented, what is designed to be adapted and what are the personalization options, what could be short- and long-term implications between options.
“Implementing any enterprise-IT solution, PLM, ERP, or others, requires a degree of personalization in the form of either (or more realistically a combination of) configuration, extension or customization.” (virtual+digital, 2015)
Platform customization: where to start
By design, PLM solutions are the product innovation ‘data backbones’ for NPI process realization, as well as integrating into the wider enterprise; as a matter of fact, there is no such thing as standalone PLM solutions. Therefore, integrating PLM (and other) platforms to the rest of the enterprise landscape is very likely require levels of customization.
Beyond the end-to-end data integration requirements, a number of process or system gaps might require customization. When selecting a given digital platform is it important to understand what are the fundamental OOTB principles and high-level storyboards; also, what are the open APIs and adaptation means, the required skills, development tools and licenses to implement these, and potential alignment with future platform enhancements.
“First, understand what’s in the box.” (virtual+digital, 2017)
It is essential to perform a thorough capability assessment as early as possible when selecting or upgrading a digital platform to confirm what elements are likely to require which type of customization. With upgrades, there could also be opportunities for future de-customization to leverage OOTB enhancements or business process simplification.
Performing fit-gap capability assessments
Understanding digital platform capabilities is essential to selecting new solutions or performing upgrades. When it comes to cascading business requirements into technical and potential customization requirements, it is important to assess the following:
What business processes are not natively supported, what and why are these perceived gaps.
Do these gaps relate to OOTB capability limitations?
Are TO BE process expectations too high or misaligned with regards to how the platform should be used and compared to industry ‘best practice’?
Can the organization change its expectations to align to the OOTB solution provided with the digital platform that it purchased?
Are other platforms able to perform the same capability across the wider enterprise landscape? (if so, can they bridge the gaps as previously identified?)
What business value relate to using the capability, and what are the quantifiable benefits (or dis-benefits) when adopting the OOTB solution compared to implementing customization?
Defining clear rules of engagement: what to customize and how
Understanding customization ability of a given digital platform is critical. It is equally important to understand the enhancement process with any vendor to balance with the need for customization:
Is the gap recognized as and enhancement or bug?
Does it make sense to wait for an enhancement request or bug fix to address a given gap as identified?
Will the gap require a short-term solution using customization?
Will the customization add a greater ROI than the OOTB solution, and is it more likely to be accepted by the business?
Does the ROI include potential future maintenance or de-customization cost?
What kind of customization is required, and how difficult will it be to implement it?
Which party will have the knowledge and IP of such customization and it is ‘approved’ by the vendor?