Death By A Thousand Customisations, And Death By None

Customise everything

A path to complexity

Some organisations do not compromise. For them, it’s imperative that the new system behaves exactly like the old one. And by that I mean absolutely identical, spot-the-differences level.

Needless to say, this is an unrealistic expectation: how can the new D365 F&O mirror a legacy solution that have evolved over a decade or more, incorporating years of tweaks, adjustments, and changing requirements?

But the question doesn’t matter, so the company embarks on a journey of extensive customisations. It’s irrelevant that the new ERP does thing in a different (even better!) way: it’s not like the old system, so it must be changed. It’s irrelevant that the old processes are convoluted and confusing: it’s what employees are used to, so it must be kept.

This is a lot more common with legacy systems that are already heavily customised, where stakeholders are indulged on every change request their heart desires. The allure of maintaining the status quo, coupled with a natural resistance to change, leads to over-customisation in the new system.

All requirements are considered essential, so lift-and-shift becomes the only possible solution, because stakeholders will not be satisfied unless and until all current features are available in D365 F&O.

Unfortunately, this comes with far-reaching and often underestimated consequences:

1. Inflated project scope: As more customisations are added, the project scope balloons beyond the initial plan, adding complexity and extra chances to fail.
2. Increased costs: More customisations mean more man-hours for consultants and developers, rapidly consuming the project budget.
3. Delayed timeline: Each customisation requires time for design, development, and testing, applying pressure to the go-live date.
4. Training complications: Heavily customised systems require bespoke training materials, increasing the time and cost of onboarding new users and sharing knowledge internally.
5. Complex maintenance: Heavily customised systems require specialised knowledge to maintain, often tying companies to specific partners.
6. Challenges with updates: Customisations can conflict with standard features in new releases, making upgrades a nightmare of regression testing and rework of existing features.
7. Reduced performance: Excessive customisations can slow down system performance, impacting business operations and making users frustrated.

How do they translate in reality? Let’s have a look at a plausible scenario.

Customise nothing

The rigidity trap

Some organisations are at the opposite end of the spectrum. Driven by a fixation on standardisation as a desire to minimise implementation costs, they adopt a strict “no customisation” policy. True, this case is less common than over-customisation (but not unheard of), yet let’s play along for the sake of demonstration.

In this case, chances are that the governance team is aware of the perils of over-customisations, maybe because some C-suite executive heard a horror story or two. So they rely on the incorrect assumption that adopting an out-of-the-box solution will make it easier to go live in time and on budget, with less hiccups. Everyone else in the organisation simply has to adapt to the new system.

Clearly, this one too is an unrealistic expectation: we already said that every company is unique and, even in the best cases, it’s perfectly normal to find differences between how an organisation operates and how an out-of-the-box business application is designed. Key stakeholders may have a misguided understanding of the application working according to best practices.

The truth? There is no such thing as “best practices” per se. There is no committee that designs and certifies specific working practices before they are implemented in the ERP. D365 F&O, like most other applications out there, is the result of years of organic growth, sometimes subject to chance and sometimes subject to circumstances.

But this is irrelevant, because the governance team believes that standardisation is the correct answer. And so it begins: requirements are forcefully met by standard features of D365 F&O, even if there are clear gaps. All standard features are deemed sufficient, so adapt-or-die becomes the only possible option. Key users are told they must make do with what D365 F&O offers out of the box.

Even in this case, the consequences are easily predicted:

1. Unfit system: The standard features may not adequately support unique business processes, leading to a solution unfit for purpose and wasted opportunities.
2. Operational impacts: Critical business processes may be compromised or slowed down, affecting overall company performance.
3. Manual workarounds: Users often create manual processes or rely on external tools to bridge the gaps left by the standard system.
4. User resistance: When the system does not behave as expected, users may passively or actively resist the new ERP, reducing and slowing down adoption.
5. Need for rework: The expected improvements in process efficiency do not materialise, causing the need to rework the solution at a later stage.

Once more, let’s have a look at a plausible scenario to see how this could happen in reality.

Customise meaningfully

The right balance

As you may have guessed by now, the key to successful D365 F&O customisations lies in striking the right balance. Customisations may be unavoidable to realise the full benefits of an ERP solution, but what makes the difference is how they are designed and executed.

Let’s be clear: there’s no magic formula to determine the perfect level of customisation. The right balance is more of an art than a science, requiring a careful assessment of the business needs and the willingness to make some compromises on the solution blueprint for go-live.

The first ingredient is a healthy dose of scepticism. Not all requirements are created equal, so ask yourself: is this truly necessary? Is it adding tangible value? Is it possible to live without it? Does the request even make sense? You’d be surprised how many “absolutely critical” requirements melt like snow under the sun when put under scrutiny.

Then, before rushing to customise, consider if changing your business processes might be the path of least resistance. Many processes accumulate inefficiency and variance over time, so implementing a new ERP is the perfect opportunity to review and simplify them.

Don’t discount workarounds either. A manual workaround can be quicker and cheaper to implement than a customisation, providing a temporary solution before a more permanent fix is developed (if it’s even necessary).

Finally, if everything else fails, consider a customisation. But make it meaningful. We define a customisation as meaningful when it is:

• Necessary: Investigate your requirements thoroughly to see if the need is real. Customise only when the alternative would be a significant gap in the business process, with a taxing manual workaround.
• Valuable: Ensure enough value is realised by the customisation to justify the effort required. Some customisation requests may not be needed today, or not required in the form proposed.
• Limited in scope: Evaluate the impact of each customisation on standard system features, including performance. Limit the extend of any modifications, avoiding the need to reinvent the wheel.
• Non-intrusive: Avoid disrupting or modifying the core features of D365 F&O. Extend rather than changing and, wherever possible, use existing third-party solutions rather than modifying the base code.
• Scalable: Ensure that any custom design can grow with your business, preferring flexible frameworks to rigid solutions.
• Future-proof: Design with future updates and upgrades in mind. Stress-test assumptions that may prove wrong as your company processes evolve.

So there you have it. These are the guidelines to customise D365 F&O in a meaningful way, to avoid slipping towards one of the two extremes.