So you’ve made the big step of choosing a new financial system. Many of you have gone out and done all of the research and determined that it’s best to bring in an experienced team to accomplish the implementation. Some of you want to take a full hands off approach. All of you have made the great decision to implement Dynamics 365 Financials with KTL Solutions as your partner.
So, how do you implement Dynamics 365?
As our customer we know you have some concerns and KTL Solutions would like to put your mind at ease by telling you a bit about our vetted process that we use to provide consistent, on time delivery of your project. Deciding to make the switch can be daunting. You don’t know how long it will take, you don’t know if your systems will be down, how much data should you pull? How long to spend training?
As I said earlier switching to Dynamics 365 Financials is something we’d like to help you with.
Implementing in Phases
Evaluation Phase
Considerations
Though Dynamics 365 Financials is based on Dynamics NAV 2017, there are significant changes between them that a consultant should know when implementing a new company. Most significant is that custom functionality is now only available through standardized extensions in Appsource (Microsoft’s app store). The significance here is that unlike in GP, custom modifications become an issue when attempting to migrate to Dynamics 365 Financials. There are some other differences in the systems as identified below:
| Feature | D365 | NAV |
| Date Established | 2016 | 1987 |
| Number of Users | Less than 1000 | 100,000+ |
| Infrastructure | SaaS only | Any |
| Licensing | Rigid | Flexible |
| Cost | Low | Mid-range |
| Upgrades/Updates | Automatic | Requires Project |
| Functionality (Financials) | Included | Included |
| Functionality (Manufacturing/Warehousing) | AppSource | Extended Pack |
| Configurability | Medium | Extreme |
Functionality
A primary discussion that needs to be had here revolves more around “what will you need in five years” more so than “what do you need now”. We have seen clients both upgrade from systems such as quick books, or downgrade from GP. Regardless of their legacy system, you will need to make sure both existing functionality and potential growth meets their needs.
As indicated above, the ability to apply customizations does not exist. Any add on functionality must be found through AppSource, (where there is well over 600 apps to choose from for Dynamics 365 alone.).
Planning Phase
Discovery
New Dynamics implementation vs migrating from existing ERP system, what’s the diff?
From a planning standpoint, not much. Regardless of if the client is starting fresh or migrating, you will want an experienced consultant to walk the client through the functions and features, comparing them to existing systems if required and allowing for a thorough evaluation. Full knowledge of the licensing models is important as there are several modules available depending on the needs of the client.
Documentation
After this walk through we like to schedule a discovery session. Prior to this, we send our client a Functional Requirements Document, or FRD. This document is filled with many of the questions that come up and helps shorten the discovery session, and allows for a quicker implementation.
During discovery we walk through the FRD, supplementing their answers where needed until we have a complete understanding of the scope of their business. This by the way is also commonly refer to as the Joint Application Design or JAD. We ask if there are any tasks or functions they run outside of their GP. This discussion helps us outline the follow up document that we will create. Clients will provide documents such as client reports or checks. From here we deliver the functional design document.
Client Deliverables – Functional Design Document. This is a module by module, screen by screen guide for configurations and settings. It also lays out the design to the system as expected to be delivered.
Data migration
As part of any implementation there is a data migration. This is the importation of client history into the new system,
Currently there appears to be many options to do this. A quick search of AppSource shows a half dozen to start with a total of 109:
Keep in mind not all of these migrate data, but rest assured, if there are many options to choose from.
Many of these tools will help you pull in the following:
- Master records and transactions from the current system
- GL Accounts and a beginning balance transaction
- Customers and Vendors
- Open transactions
- Inventory items, current quantity on hand and service items
Client Deliverables – Data migration plan where the data, tool, and process are predetermined and agreed upon
Let’s Go!
So, you’ve done your planning, and you are ready to roll. A typical implementation occurs in two environments, test, and then production. This ensures that there are no critical business interruptions during the implementation cycle.
Test Upgrade
Install
The consultant starts out by installing the software into the test environment and configures it based on the functional design document. Using the data migration plan, the data is brought over. The system is now technically stood up but we like to incorporate an additional step, internal validation.
Validate
We assign an additional consultant to know go through the FDD and validate the settings and checks them off individually. We walk through each process such as issuing a check, and running a report. We validate that the report ties into the legacy system data. This is all done prior to handing over to the client for their testing.
Train
The client is fully trained before accessing the test system so that they know how to test. KTL Provides user guides from Microsoft as well as any custom documentation such as the FDD.
Client Deliverable – fully validated system ready for testing
UAT
The client proceeds with UAT based on their user cases. These will be client specific and best practice calls for independence here. As bugs are identified, KTL updates and corrects as required. Once the system is complete and validated by the customer, we agree on a go live date. This date is typically the first business day of the month, allowing for KTL to do the upgrade over the weekend.
Production Upgrade
This is our pre cutover process that involves the consultant moving the test system into production during a maintenance window, (typically over the weekend. The steps involved are as follows:
- Copy all test databases over to production servers
- Update data from test upgrade to current date
- Internal validation
- Turn over to client on go live day (first business day after upgrade)
- Go live support
Go Live
Go live is essentially returning your fully trained staff to everyday operations with their new, fully operational system. KTL provides support for any questions or issues that arise. This is typically conducted remotely or on site by a highly qualified consultant.
Client Deliverable – fully functional system
Summary
Migrating to Dynamics 365 for Financials should not be a painful journey. KTL Solutions has a solid migration methodology in place, and can help you navigate the conversion. I hope this article has been helpful in your understanding of how to implement Dynamics 365.
We are keeping up on the rapidly changing tools available, and evolving our methods to account for better and faster ways to go live. Our goal is to make the result as seamless as possible for our clients.
