Implementing Microsoft Dynamics 365 for sales: DO YOU need a consulting partner?
With the November 2016 release of Dynamics 365, Microsoft’s product management strategy took a huge step forward in its efforts to align solution offerings with customer needs. Customers today want to “consume services” vs. “buy products.” A new “apps” model for Dynamics software capabilities, a more plug-and-play approach to functionality and a user-based subscription mean that Dynamics 365 has really democratized ERP and CRM capabilities. As Catapult CRM Consultant Monica Heir explains in Part 1 of our Microsoft Dynamics 365 blog series, “Everyone is able to access Dynamics 365 . . . it is a win for customers new to Microsoft Dynamics.”
However, the question remains – does this accessibility extend to implementing Microsoft Dynamics 365? Can organizations just plug it in and go? In this blog we’ll explore what it really takes to get up and running with Dynamics 365.
Getting Started with Implementing Microsoft Dynamics 365
It’s true – with easy setup and data migration tools organizations can get online with these capabilities pretty quickly. “Dynamics 365 is deployed with dead simple wizards . . . click next, next, next and you are running within 5 minutes,” says Catapult Senior NAV Developer Jeff Landeen. Plus, because Dynamics 365 is a bundle of interchangeable business services, customers don’t need to spend time on functionality that they don’t need. In other words, they can turn only what they need, vs. everything in the kitchen sink.
It’s in the configuration of Dynamics 365 where customers can get easily overwhelmed with a DIY approach. While its out-of-the-box model certainly aims to make this process quite simple, it’s important to recognize that this model relies on organizations executing their business processes in the exact manner intended by the application. Any deviation from this and it starts to get tricky. For any customer that has used SharePoint this will be familiar. It’s dead easy to create sites and workspaces, but some planning, design and configuration is really important to align it’s capabilities to the way you want to work.
Like What You've Read? Subscribe to Our Newsletter!
Taking the “Road Less Traveled” is not as poetic as it sounds
When business processes do not tidily align to “OOC” (out-of-the-cloud) configurations, as often happens, organizations must reconcile the differences. In other words, they need to configure the software in a way that works in the context of their business. Customers can either do this alone or work with a partner. Given the “clicks not code” nature of Dynamics 365 they often have the impulse to do the former. However, this can raise a variety of challenges.
First of all, customers may not have a solid internal consensus around their business processes. Without this consensus it is extremely hard to adopt software effectively. This is especially true for smaller organizations – who many consider to be the target market for Dynamics 365. Take the example of Opportunity management in CRM. While in larger organizations there is often a sales manager to define or dictate this process, smaller organizations typically have salespeople who tend to operate more independently and have their own way of doing things. Coming to a consensus on something like standard sales stages from lead to close is therefore quite difficult. However, this consensus is necessary to move forward with the configuration.
Another problem that organizations may face is a lack of technical understanding. With a platform such as Dynamics 365 there are usually 3 or 4 different ways to achieve the same outcome. Each approach has its benefits and its drawbacks and organizations need to understand each one to decide what the best option is. Moreover, once they have decided which approach to take they need to understand how changes to the out-of-the-box configuration can affect the rest of the system. For example, look at drop down lists. It’s very easy to add a value to a drop down list. What’s not so easy is understanding the implications of this action. How will this affect other functionality, such as reporting and dashboards? What happens if you need to disable this value over time or change the label?
Lastly, customers configuring Microsoft Dynamics 365 on their own often do so without a holistic vision for how the application is going to be architected, i.e., not starting with the end in mind. They make decisions or implement in way that satisfies an immediate or short term need. Failing to take the long-term into account can lead to rework or inefficiencies within the application over time. Data redundancy is one such inefficiency. Managing the same piece of information in multiple places requires not only a lot of manual work, as multiple parts of the system need to be touched to update it, but also issues with data quality. If this information becomes out of sync, how is the organization to know what the truth is?
Why Reinvent the Wheel?
As you can see from the above, successfully adopting Dynamics 365 takes a bit of planning. And even if a customer is able to get the system configured quickly on their own, how likely is it that they will be able to get it right the first time and configure it to their specific long term needs?
Consequently, customers looking to implement Microsoft Dynamics 365 should strongly consider working with a partner. An experienced partner will enable organizations to get the most out of Dynamics 365. They’ve seen what works and what doesn’t and will have a vision for how all of the pieces of Dynamics 365 can fit together in the organization’s specific context. Why not take advantage of this expertise and knowledge of best practices? Why try and reinvent the wheel?
A word of warning: Configuration vs Customization
For simplicity’s sake I’ve only used “configuration” in this blog. However, when implementing Microsoft Dynamics 365 (and any other ERP or CRM system for that matter), it’s incredibly important to understand the difference between configuration and customization. Configuration usually refers to organizing functionality with administrative setup tools and interfaces, i.e., not code. Customization on the other hand refers to custom development which is entirely different. It needs to be designed, built, tested, integrated, maintained and upgraded. There is nothing bad or wrong about customizing, it just needs to be done carefully by experts.
Organizations need to be cognizant of these differences, especially when they are speaking with prospective vendors. They need to challenge vendors them and ask questions. Understanding what vendors are suggesting is key to understanding the implications.
After Implementation: Set it and forget it?
In Part 2 of this blog series, we take a look at what happens after Go-Live. We explain why, rather than “set it and forget it;” customers should think about “set it, monitor KPIs, adapt, modify, tailor, absorb new capabilities and tune performance.”
At Catapult our aim is to provide Unprecedented Support for ERP and CRM systems, and consequently, to enable our clients to achieve sustained business performance improvements. This philosophy is deeply embedded into the way we work with clients implementing Microsoft Dynamics 365.
Understanding the needs of an organization’s stakeholders and business users is paramount. Only then can we identify misalignment and inefficiencies within the organization. This understanding also enables us to suggest different approaches to achieving outcomes and explain their associated pros and cons. Because we’ve been through this before, we know what works and what doesn’t. We leverage this information to ensure that our clients take complete advantage of the application.
Thinking of Implementing Microsoft Dynamics 365?
Looking to move to Microsoft Dynamics 365? Or maybe you’ve already made the investment but struggled to configure Dynamics 365 for your business needs? Get in touch with us to learn how we can help your organization get the most out of Microsoft Dynamics 365.
If you’d like to read more about Dynamics 365, check out our 3 part blog series: