Keep your hand up if you built it yourself.
I'm guessing most of the imagined hands went up and went down again. For those few who really did build their own car, I'd wager an adult beverage that you also have a daily driver in the family that is standard.
We don't build our own cars very often because we accept that modern cars are reliable, fully-featured and well-designed. We pick the type of platform we need, people-carrier, SUV, sporty roadster, station wagon and so on, based on our analysis of our needs and the benefits we are looking to get. We know that to commission a bespoke vehicle would be prohibitively expensive for most of us and standard vehicles do most of what we want. We fit our needs to the platform because the platforms are good.
For example, when going on vacation I pack our things into the car I have. I don't assemble all the things and then build a car that shape. Years ago, I chose a car that was a reasonable size for us and our things.
It was not always the case. In the dawn of private motoring, if one was lucky enough to be able to purchase a motor car then one could specify the chassis and engine required from Rolls Royce and then describe the body one would like to be built atop of it, to one's precise requirements. These "coachworks" would be created by a third party.
How else could it possibly work, as no manufacturer could ever know your individual needs?
To most of us that sounds ridiculous. When Rolls Royce expanded into the United States they found that Americans wanted to buy, you know, a whole car, and so gradually standardized onto a catalogue of bodies.
These days few of us would consider specifying a bespoke vehicle, or even customizing the one we are buying beyond choosing from configuration options carefully curated by the manufacturer for compatibility and future serviceability.
So use it.
When you keep your platform as close to standard (some people like to say out of the box, or OOB) as possible you get the most out of what you are actually paying for:
All of which add up to velocity on the road ahead.
All platforms have their strengths and weaknesses and so you might have to live with some imperfections, but doing so is a lot better than starting to bolt on your own code if you don't need to.
Remember that Configuration will have to be performed in any case, and is generally ok. Examples of Configuration might include loading your Customer list, Product list, Employees, locations and names of Warehouses and the names of your Sales Stages and Territories. This is all to be expected. In our car analogy this would be like picking the colour of the interior.
Customization, alternatively, means modifying the actual functioning of the system with new code, screens and objects. In our car analogy that would be like installing our own exhaust or brake system.
Firstly, if your platform is mature, map your business process to the way the platform works, not the other way around. I know this sounds backwards, as the platform is there to serve your business needs, but remember the car analogy. By customizing to adapt to your existing business process you are adding cost, reducing your access to platform innovations and likely reducing your velocity.
This is especially true when you have a common use case. I specialize in CRM systems, so my mind goes to processes like Pipeline Management, Sales Forecasting, Customer Support and Field Service, all of which are familiar processes well-modelled in established platforms.
If your process doesn't easily map to the platform, there is an even chance you are not using best practice.
Customize to implement a business process only when that process really, really needs it. Examples could include:
In your project meetings ensure that any proposed customization is properly justified with a least a comparison of how things would look if implemented using standard capability. Chances are the first reviews will reveal opportunities for deeper process transformation.
This needs to be integrated with the Change Management side of your program, as more transformation might be added, increasing the Change load for the enterprise. This gets into Program Management thinking about how to tranche your program to provide safe Landing Zones for the business as you proceed. You will need engagement with stakeholders in leadership and operational roles in the affected area to make the right decision. Sometimes time pressures preclude this but realize that there will often be some process debt accrued by customizing. A key point is that the group requesting the customization is often not the group who will bear the burden of the future costs, and so the decision should be structured carefully.
Have a senior person who has a balance of business process and technical awareness be the Decision Maker on allowing the customization to proceed.
Check the vendor really does know best practice in your industry. Ensure advice from architects and SIs who are very familiar with the platform but not your industry best practice is appropriately calibrated. Business-focussed third parties can be better for this in my experience.
Levels of customization
Perform only the mildest customizations you can. An example of levels of risk might look like:
| Level | Example | Notes |
| 1 | Adding an attribute to a standard object. |
Mild and often required. Make sure you are not perpetuating a legacy process that would be better to be transformed into something that can be achieved with a standard attribute |
| 2 | Adding a new kind of object that is not available in the standard platform |
Not too risky, as the core functioning of the platform is unaltered. Realize you are on the hook for future maintenance, at a pace determined by the vendor's changes not your desire. Budget for this. Realize your area will likely lag the rest of the platform and be a support cost. |
| 3 | Modifying a standard object or process flow |
Do not do if at all possible. This stores up a future tax of issues, perpetual rework, testing and inability to access future vendor features. If you must, ensure resources to manage in the future exist. Often exposing the requestor to these future costs can make process transformation happen. |
If I think back to the customizations I've allowed in the past, in most cases I think I could have gone deeper into the business transformation route and either opened the aperture on the business problem or found a more standard way.
And I, as you can tell, am a standardization hawk, because I think there is higher velocity with standard approaches.
I've seen programs where the governance was too light, or the time-pressure too high and so too many customizations crept in. It all ends up in tears later on...
One of the most famous examples of where things can go wrong is the SAP ERP implementation at the European grocer Lidl. Reportedly, a key element that lead to the expensive abandonment of the project was heavy core customization required to alter SAP ERP to match the inventory pricing practices established at Lidl. This would have needed extensive Level 3 changes and my understanding is that the work then just cascaded in an uncontrolled way. In the end the company went back to their old system.
The Lidl example contrasts with the example of Cadbury's implementation, where reportedly the business altered its warehouse management practices to work with the mature platform, enjoying a successful implementation and realizing cost savings with new efficiencies.
Of course, sometimes you will have to do a little Customization. Just be careful out there. Where have you seen customization triumph or detract in your work?
If you would like to talk more about appropriate use of Customization then please reach out on LinkedIn, or view my services at fieldenablement.com
G.
-