How should you approach Dynamics 365 as a standard system?

Many companies that buy Dynamics 365 or Power Platform actively try to stick to standard functionality as much as possible. This is often because they previously had tailored systems and suffered the consequences. Now they want to try to minimize the adaptations they make so that the system is more manageable and cheaper to operate. But it isn’t always easy to know where to draw the line. When are standard functions enough? When do you need to make adaptations?

To begin with, you need to understand what you get when you choose Dynamics 365. Take Dynamics 365 Sales, for example. It includes functions such as collecting and managing leads, processing business opportunities and quotation management. These features, as well as many others included that I don’t have room to list here, are presented in a useable interface. Both functions and appearance come with a framework however, and there are restrictions on how much you can change these without having too great an impact on the system; this is particularly true of the system appearance.

The simple answer is: When the business benefit exceeds the complexity that arises from an adaptation. All customization means an increased amount of complexity for your system as a whole, but this can be smaller or larger depending on what you want to change. Increased complexity in turn leads to higher management costs, such as system maintenance, as well as possible challenges when making additional changes.

This means that any requirement for an adaptation to the standard system must include a proposed solution detailing the complexities involved, and from there a decision can be made whether to implement it or not.

High business value + low complexity = ✔

Low business value + high complexity = ❌

If we want to change a function that does not really support the existing work process, we need to analyze whether there is a reason to change the way we work or to change the function of the system.

When it comes to adapting the appearance, it can be difficult to see high business value from such requirements. Not to detract from the importance of the system’s user experience and its ease of use, but requirements should be questioned if it’s merely the case that a certain button is usually on the left, for example, or if it’s actually so important to the end users that a change is worth considering.

But what happens if we have a requirement that means high business value + high complexity? Should you make that adaptation anyway?

It is always tough to make such decisions. One thing to consider is whether the requirement needs to be met 100 percent.

What I usually do in these situations is try to challenge the need for the adaptation. You may propose a solution that meets the requirement by 70 or 80 percent, but the remaining part you choose not to adapt. With such a solution, the complexity would drop to low while the business benefit may still be relatively high or medium.

The balance between sticking to the standard but still succeeding in tailoring the system in such a way that it really becomes an operational support and not an ”administrative must” is difficult. But by thinking through the decisions about which adaptations to implement and comparing the business benefits with the complexity, you can have the best of both worlds – with an adapted standard system!

Want to know more about how Dynamics 365/Power Platform can help your organization? Feel free to contact us and we can tell you even more.