Delivering enterprise projects using Dynamics 365 is different from delivering smaller projects and it’s important to get the solution configured to match. A large solution typically covers several distinct business areas with a large organisation and use many components of the Microsoft Cloud. The Dynamics 365 SaaS applications are a significant part of this; but not the only ones.
Dynamics 365 can be deployed at enterprise scale; but its implementation needs to match the needs of a complex business organisation. Defining the correct instance strategy, potentially multiple instances driven by business architecture, is vital.
Gaining a ‘single view of the customer’ is an important goal of many Dynamics 365 implementations focusing on Customer Service, Sales and Marketing. If this principle is applied in a simplistic fashion, this tends to a design where the entire Dynamics 365 solution is designed and implemented in a single instance. Initially this appears to offer a quick short cut to a ‘single customer view’; however, problems rapidly multiply:
· The single customer view is lost in a complex data model: the data may be there but can’t be found without significant effort;
· Excessive customisation is required;
· Opportunities for configuration are lost — which business area gets to use the standard entities? Which business area gets the customisation?
· The security model mushrooms to ensure that the correct data is seen by the correct teams in different business groups with differing roles and needs;
· Deployment and upgrade agility are hindered. The benefits of ever greening are diluted; upgrades move from BAU to major projects — at least twice a year based on the current Microsoft Dynamics cadence;
· Changes for a single business area potentially require regression testing by several business areas increasing cost, time and complexity of the delivery;
· Increased possibility for multiple active simultaneous developments for the different business areas requiring complex processes for managing and releasing new functionality;
· Release planning more complex as agreement is required from multiple stakeholders from different business areas;
The single instance short cut rapidly becomes a trap for the project — progress is slowed, and it’s harder to maintain and upgrade diluting the TCO benefits of a Dynamics 365 project for an enterprise.
To avoid this trap, you could consider some of the approaches below:
1. Define an approach to Instances at the start of the project based on business needs and the organisational structure. Changing this part way through a project will be an issue especially if two instances are collapsed into one;
3. Keep it simple
4. Assess the requirements in an Object Orientated fashion — both data and behaviour need to be considered; not just the data. For example, a supplier and customer are likely to have similar data fields — their relationship to the Enterprise couldn’t be more different. It’s the behaviour which will call this out;
5. Be open to multiple instances: separate instances for separate business areas with key entities synchronised using Flow is a good approach. Minimal customisation to the Entity model will help here.
6. Consider if the single customer view is better delivered in Power BI using the Common Data Service (CDS). It’s unlikely that all customer data captured by a complex, large enterprise will ever be stored in a single system — the considerable costs of this could outweigh even the benefits of a single customer view. So, delivering a Power BI solution which realises the single customer view as a series of reports is a pragmatic alternative. This can be delivered in a series of phases minimising risk and business impact.
There is no magic formula to getting instance design right quickly. It’s worth investing time at the start of any major Dynamics 365 project to understand the business requirements and drivers over the differing business units to create an instance and entity design which balances sharing customer data with making best use of Dynamics 365 capability. Avoiding customisation remains the golden rule.