Customization vs Configuration

Lionel Grealou ERP PLM 4 minutes


Implementing any enterprise-IT solution, PLMERP, or others, requires a degree of personalization in the form of either (or more realistically a combination of) configuration, extension or customization. Typically, choosing one or another application, tool or technology, implies choosing one that is best fit-for-purpose against a set of critical use cases as well as other non-technical criteria (commercial, relationship, etc.).

Managing the amount and complexity of customization is critical to control cost of implementation, support, future maintenance, bespoke training material, etc. and reduce the risk of issues.

CriteriaConfigurationExtensionCustomisation
DefinitionAdjustment or “tweak” of product parameters to tailor process and achieve desired functionalityCapability to “extend” existing capabilities by applying “light” customizations – typically using an approved frameworkChange of code or logic that is not included in the OOTB product – typically using approved APIs and programming languages requiring compiled code (creating binary or executable files)
Vendor approvedYesYesIt depends if uses supported APIs, for the purpose that they were created for in the first place; excludes direct database access
PurposeTo tailor the behaviour of the product to the process requirementTo augment certain capabilities, but without using complex customizationTo significantly augment existing or create new capabilities implementing workarounds to certain OOTB limitations or fill unaccepted gaps
ComplexitySimpleSimple to complexSimple to very complex
Typical effort to
implement
LowLow-MediumMedium-High
Duration of
implementation
Generally less than what is required to customizeAnything in betweenWeeks, months, or years
TestingMinimum, can be
automated
Moderate, some of which can be automatedAll of the above, up to very advanced and high maintenance)
MiddlewareTypically not required, or embedded into the productProvided or embedded into the productCan be embedded but not necessarily (e.g. for integration with other products)
Cost of ownershipLow maintenance, can be done by administrators or qualified super usersDepending on the type of
extension, how it is supported during upgrades; bust typically easy to adjust when needed
Can be very costly to implement AND
maintain, requires advanced IT implementation tools and knowledge (e.g. language, middleware, source code control management, extensive testing, etc.)
TransparencyDoes not require
access to product
code, can be done
through user
interface
Require access to macro or intermediate product codeCan requires access to the product code, APIs, sometimes data model (e.g. for an interface where no useful API is available) – can be considered as a “hack” and can compromise data integrity
Buying processPreferred approach
to reduce dependence on service provider
Low risk but not always
fit for purpose (to be evaluated based on purpose)
Typically an objective to avoid, keep to a minimum in a controlled manner; requires a trusted advisor to inform on potential risks or impact to future evolutions
Integration requirementsLimited tuning possible in this contextLimited use possible in this context unless common integration framework OOTB (if same vendor, then why not possible to configure OOTB)Typically required – not always understood in early stage of implementation, especially PLM-ERP integration
CloudSome is possible / requiredSome is possible / requiredLimited – not always possible depending on internal or external cloud approach
Future enhancementNot requiredCan be pushed to the vendor as a product enhancement requestCan be pushed to the vendor as a product enhancement request with a view of future de-customization if / when it becomes part of the OOTB package (general availability or not)
OpennessStandard product knowledge required – some magic “tweaks” might reveal certain configurability optionsRequire experience in using the framework and the business processesRequire transparency on the costs and implications, having in mind the long term cost of ownership; best to bet on a service provider who is not shy to propose alternative pragmatic solutions
PerformanceLimited impact – if used as designed (which can bring surprises if first time use)Can impact performance if complex process or poor coding techniqueCan have serious implications to performance, even if using approved APIs (requires technical assurance and validation on realistic production alike QA system); Can impact performance if complex process or poor coding technique
Control and change managementBasic requiredRequires impact analysis and option assessmentRequires impact analysis and extensive option assessment (short and long term costs vs benefits)
Data migrationMapping requiredCan imply complex ETL and data alignment to the new capabilitySimple to very complex, requiring logical data model alignment and sometimes understanding of the physical data model

PLM and ERP implementations sometimes fail as they go massively over-budget due to under-estimation or lack of control of customization.

Below are typical questions to consider when mitigating that risk include (non-exhaustive list):

  • What is the art-of-the-possible with the OOTB application? 
  • Why is it not covered by the OOTB application?
  • What is the impact to the business (if not implemented)?
  • What is the expected business benefit if implemented (which will include, but not limited to the above)?
  • What are the impacted use cases?
  • Will education / training be required or impacted (if already performed)?
  • Can the process be adjusted using only configuration?
  • Is there coding involved to alter the way the application works or behave?
  • Has the vendor declared a plan to improve or include this in a future release and, if yes, when is it due? 
  • Who will perform the configuration / customization?
  • How much will it cost to implement, support and de-customization (should it be required)?
  • What is the impact of existing and future data quality, integrity and consistency (e.g. data to be migrated)?
  • Is there an integration or data model impact?
  • Who will be testing the configuration / customization?
  • How will these changes affect future vendor upgrades?
  • What kind of support will be needed?
  • Is it part of the organization’s Intellectual Property?

What are your thoughts?


This post was originally published on LinkedIn on 15 October 2015.

About the Author
Lionel Grealou

Lionel Grealou

Twitter

Lio is founder and independent consultant with Xlifecycle Ltd—helping organizations make the most from their digital enterprise strategies and manage the 'Lifecycle of Things' across PLM, MES, ERP, IOT, SCM platforms.

You may also like: