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. 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.
| Criteria | Configuration | Extension | Customisation |
| Definition | Adjustment or “tweak” of product parameters to tailor process and achieve desired functionality | Capability to “extend” existing capabilities by applying “light” customizations – typically using an approved framework | Change 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 approved | Yes | Yes | It depends if uses supported APIs, for the purpose that they were created for in the first place; excludes direct database access |
| Purpose | To tailor the behaviour of the product to the process requirement | To augment certain capabilities, but without using complex customization | To significantly augment existing or create new capabilities implementing workarounds to certain OOTB limitations or fill unaccepted gaps |
| Complexity | Simple | Simple to complex | Simple to very complex |
| Typical effort to implement | Low | Low-Medium | Medium-High |
| Duration of implementation | Generally less than what is required to customize | Anything in between | Weeks, months, or years |
| Testing | Minimum, can be automated | Moderate, some of which can be automated | All of the above, up to very advanced and high maintenance) |
| Middleware | Typically not required, or embedded into the product | Provided or embedded into the product | Can be embedded but not necessarily (e.g. for integration with other products) |
| Cost of ownership | Low maintenance, can be done by administrators or qualified super users | Depending 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.) |
| Transparency | Does not require access to product code, can be done through user interface | Require access to macro or intermediate product code | Can 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 process | Preferred 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 requirements | Limited tuning possible in this context | Limited 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 |
| Cloud | Some is possible / required | Some is possible / required | Limited – not always possible depending on internal or external cloud approach |
| Future enhancement | Not required | Can be pushed to the vendor as a product enhancement request | Can 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) |
| Openness | Standard product knowledge required – some magic “tweaks” might reveal certain configurability options | Require experience in using the framework and the business processes | Require 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 |
| Performance | Limited impact – if used as designed (which can bring surprises if first time use) | Can impact performance if complex process or poor coding technique | Can 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 management | Basic required | Requires impact analysis and option assessment | Requires impact analysis and extensive option assessment (short and long term costs vs benefits) |
| Data migration | Mapping required | Can imply complex ETL and data alignment to the new capability | Simple 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
