Customise, De-customise, Re-customise: the Enterprise Digitalisation Dilemma

Lionel Grealou Enterprise, ERP, PLM Leave a Comment


Going digital: to customise or not to customise?

Digitalisation 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 digitalisation often include the need for:

  • Application consolidation or modernisation: replacing obsolete solutions, integrating or harmonising application landscape, including front end and back end IT solutions
  • Digitalisation and business transformation: implementing operational changes, including both front and back end processes, focusing where most business benefits can be realised (ref. the PLM business case)

Digitalisation 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 behaviour and demand, external environmental factors, from front to back end processes, focusing where most business benefits can be realised.

Digital transformation implies fundamental change in an organisation’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 organisational alignments. Integration and configuration / customisation are often inevitable means to implement business requirements, though they must be controlled and minimised.

Typically, configuration is about behaviour adjustments and non-invasive tailorisation, while customisation is rather perceived as filling a capability gap, such as in terms of lifecycle business rule, workflow or integration requirement. Actually, 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”).

Why customise:

  • 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 capatibility 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 geeting from the off-the-shelf solution)

Why not customise:

  • Adopt off-the-shelf technology vendor-led best practices
  • Focus on configutation to ease future compatibility and upgrades
  • Minimise total cost of ownership (implementation and maintenance cost)
  • Transform processes (business tradeoffs), align skills and organisations to technology best practices

First, understand “what’s in the box” (ie 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 customisation 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 customised to be tailored to the required business requirements?

There are different types of customisation, from simple to complex, more or less invasive, from fairly easy to maintain through software configuration to expensive bespoke customisation.

Some organisations customise 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 customisation 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 capitalised 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 customisation” is one of the most common mantras about PLM (and ERP) system implementations; strictly speaking, zero customisation does make sense as it hinder competitive advantage.

As utopian as a zero customisation PLM implementation may sound, the unfortunate fact is that most organisations customise 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 organisation’s needs. PLM product enhancement requests sent to PLM editors are also customisations 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. Customisations done at source are not always going to be adopted by all other users. Product enhancements will often need de-customisation of other workarounds or dependencies, and re-configuration or even re-customisation to be taylored to the final wanted state or behaviour.

Considering these factors, it is worth noting that most complex so-called product enhancements or “under the hood” customisations done directly by PLM editors are likely to cost more than normal “approved customisations” 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 standardisation across organisational 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-customisation, some are more invasive, complex and costly than others. PLM customisation can create problems during implementation as well as after implementation and deployment.

Controlled tradeoffs between process and tool change; controlled customisation

Measuring the level of customisation 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 customisation 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 customisation change requests implemented, by type of customisation / 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 customisation be entirely avoided and that configuration be minimised, as much as possible… (CIMdata)

This is therefore a matter of preparing for people-process-technology capability tradeoffs. It is clear that heavy customisations 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 standardisation 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 customisations 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 customisation only. Successfully implementing enterprise PLM is partly a science and an art – in controlling interdependent requirements and their related configuration and customisation tradeoffs.

What are your thoughts?


This post was originally published on LinkedIn on 11 August 2017.