Implementation Best Practices: Straight from a Field Expert

Laura Jacobowitz is the Axtegrity Delivery Manager, with over a decade of experience implementing Dynamics AX and Dynamics 365. She is a development and process expert working in the ERP changing landscape to help customers and clients reach their business goals. We recently sat down to get Laura’s feedback and best practices for implementing D365 for Finance and Supply Chain Management. In this Q&A, Laura shares her insights. It’s great overall guidance when planning a potential upgrade or re-implementation of an existing software solution.

What’s your background in the ERP industry?

I’ve worked in development and the ERP industry my entire career. With Microsoft products, I started with GP in 2006, and moved to AX a few years later, I believe that was version 4.0. Prior to that, I worked on legacy custom ERP systems, spending many years at Readers Digest working on IT and mainframe infrastructure.

How many Dynamics deployments have you been a part of?

Somewhere between 50 and 100, so let’s settle on 75! I’ve worked in multiple roles, but primarily in two: as a Development Manager, responsible for leading a core team of developers who are engaged in coding and contributing to an ERP implementation, and as an overall Delivery Manager, responsible for entire end-to-end implementations.

Can you describe your current position with Axtegrity?

I’m currently the Delivery Manager. In that capacity, I’m involved in every implementation project, from meeting with potential prospects and customers, to contract agreements, to planning and delivering software solutions throughout the entire customer lifecycle. It’s an interesting perspective, because I understand what the customer’s pain points are from the beginning and can use that insight to alleviate those issues with the new D365 solution.

I fit all roles—I’m one of those people who do both technical and functional, and that can change the implementation for the better. There has always been a barrier between technical and functional roles and I break down that barrier. I get both sides of the team to understand the other by providing technical insight to the functional team and functional insight to the technical team.

There are many ways to organize a software implementation project. What has worked successfully for you?

Every project tends to be organized a bit differently but must include the deliverables and expected outcomes of the engagement in a project plan. Everyone in the client organization should be involved and have a clear understanding of what is going to happen, why it is happening and how they can help. Clients also need a detailed understanding of how much time their internal users and process experts will need to spend defining processes, identifying gaps, testing, validating data, and so on. People must be taken out of their normal jobs to make it successful. You can’t hire someone from outside your business to do this. Project Managers on both sides must have a close relationship and share the same plan and the same goals.

How important is defining your business processes up front? Is this how you determine the functional gaps?

Conversations can’t be all about out-of-the-box software functionality, they must focus on unique business processes. It is important for clients to identify core business processes, first the ‘as is’ (how the system currently functions) and the ‘to be’ (how you would like them to evolve). We start with the ‘as is’ process flow, define the ‘to be,’ and work through the process as it needs to evolve. The ‘as is’ is crucial because it brings out key points that are sometimes forgotten when people describe what they hope the system will do for them (‘to be’) even though their business depends upon some of those processes – they are just natural to them and not described when thinking about the future. We determine the list of processes in the very beginning of the project and design to those we are carrying forward, configure to those processes, and test those processes.

When do you consider ISVs and custom code?

Once we understand the business process ‘to be’ state, we take it to the next level and look at what out-of-the-box features exist that can address those areas. There are often ISV solutions to fill gaps or provide industry-specific functionality, but sometimes custom code development is required. As partners we need to be ready to talk about the potential for customizations and how we work together to find the best most cost-effective solution. Customizations or third-party add-ins must be considered as part of the Statement of Work, so the client has a complete idea of what the project looks like in both in terms of time and cost. Although I have a development background, I know that process changes are often better than customizations.

Data considerations for migration?

Most data migrations fail due to lack of planning and mapping. As part of the initial planning conversation (before aSOW), we need to discuss what the client truly needs to migrate: how many years of historical data, at what level of detail, and whether transactional data or just journal entries are necessary. This is crucial to understanding necessary bandwidth and can save or cost clients a lot over the long run. A tighter scope means less data, less storage and fewer costs. When migrating, we start with a sample set of data very early in the process, then nearly complete data for UAT (user testing), and final data when we cut over to production.

We also suggest clients clean up their data prior to any migration. If your data is clean, it saves expense from inaccuracies after migration. If the level of cleanup involves only master data with addresses, it can be out-sourced relatively cheaply.

What can be a big hiccup or potential problem area?

Security is often a big gotcha and is often left until the end of an implementation because it’s so difficult. It’s hard to accurately define security needs just by looking at the security roles in Dynamics. The client and the partner need to examine each window and follow the workflow paths to identify who needs access to what at each step of the process flow. We start with out-of-the-box roles, but for clients who have unique security requirements, we need to look at every menu item, window, and field. It’s really an evolutionary process, with the client testing along the way.

Axtegrity offers rapid deployment options. Why might that be a better way to start?

I’m very keen on our rapid deployment options for all the D365 ERP products. Within a couple of weeks, you can see a new system with your configuration and your data in it as opposed to sample or demo data. That’s important because it makes it easier for you to understand what you are getting. It’s so eye-opening to see your own data! It’s also important to remember that for a rapid deployment implementation, we assume the customer is using normal accounting processes – customizations are not part of a rapid deployment and can slow down the implementation.

How does a company avoid an implementation failure?

Get everyone familiar with D365FO because it is an architectural change, especially if you are coming from a highly customized, on-premises system. Most clients have their own internal IT and Financial Managers. Getting them up-to-speed with the new features, along with one-version release lifecycle is very important for managing the implementation both pre and post go-live. Allow your team enough time to understand the new high-level concepts and familiarize themselves with the new environment. Encourage everyone to dedicate time along the way to experiment, try new things and learn. And always, to provide their feedback!

if you’d like to discuss Dynamics 365 Finance and/or Supply Chain and whether you think it might be a good fit for your organization, please don’t hesitate to contact Laura at ljacobowitz@axtegrity.com.