Microsoft Dynamics AX/365 Implementation Methods: 7 Wrong Things

Data Engineering Solutions

It is a disheartening fact that even though Microsoft Dynamics AX has evolved over the years (with the most recent version being Microsoft Dynamics 365), the industry has not kept up with the changes, thus rendering the implementation methodologies and staffing plans stagnant.

This has led to the companies being less reflective than they used to be in the initial days of the ERP software launch.

This has created a huge gap between vendors (service providers who manage the Microsoft Dynamics AX needs) and clients (companies who avail these services) in terms of system deployment and staffing, which results in a damaging rift in the working relationship of the vendor and the client.

Following are the pressing challenges of the present day and represent everything that is wrong with the current Dynamics implementations (both AX and 365):

1. Vague and overly trusting buying behavior of the clients.

Most companies select an ERP system (and vendor) based on the demo given by the sales team consisting of ‘MS Dynamics Consultants’ who are projected as the domain experts.

Who must carefully evaluate the demos for actual value additions that the vendor can bring on the table rather than their visual appeal in terms of presentation?

The vendors selected for pitching these demos are invited to answer an RFP floated by the client. More often than not, a generic format is used that does not underline the exact client requirements.

It is essential that internal employees draft (or play a major role in drafting) rather than third-party sourcing solutions. They are more familiar with the company requirements and pain points that need to be addressed by the ERP solution and Data Engineering Solutions.

As the vendors are bound to showcase their best ‘sales resources’ in the initial discussions, the client must ask for the profiles of the resources that will work on the actual development.

2. Vital information is lost during knowledge transfer from sales to development teams.

All the information gathered in the sales cycle does not light the day when the ERP implementation is sanctioned, and the project progresses.

Suppose the kick-off is not done in collaboration with the sales team that has worked on the requirement gathering.

In that case, the development team often misses out on bits of vital information specific to the client discussed in the sales cycle.

It is necessary to maintain communication logs and understanding documents for this purpose.

It is also advisable to have atleast one member from the sales team (preferably a Business Analyst) onboard the project to guide the development team effectively and to do away with the overhead involved in asking the client for the same information twice.

3. The Discovery cycle does not deliver up to the standards that are expected in return for the heavy budgets allocated to the process.

Contrary to the information loss in knowledge transfer, there is information overload in the discovery process, as analysts and consultants dig for industry and project-related information from the client.

This is the most costly process in the whole project implementation.

A thumbs rule to effectively reduce the discovery cycle cost and time would be to utilize the 80% generic industry information already available with the vendor and only extract 20% client-specific information from the client company.

4. Expectation gap between vendor and client.

More often than not, vendors put their technical experts in direct communication with the client.

This is a big mistake, as most clients expect their point of contact to guide them on better their ERP solutions to address their business-related problems.

This creates expectation gaps as the technical experts keep looking only to better the solution architecture and functionality-wise.

Hence, the vendor contact liaising with the client should always be a business analyst or an expert who knows both – the technical and the business logic side of the ERP solution.

5. The onus of ownership is passed from client to vendor, whereas it should be the other way around.

Clients make the fatal mistake of thinking that once they have invested money in their Microsoft Dynamics AX solution and vendor, their role in the project is over.

On the other hand, the vendor waits for pointers from clients as to what they want to be incorporated in the ERP Solution.

The budget also depends on the short-term and long-term plans, change request processes, allocating the right resources to the project, etc. These factors determine whether your costs will be in control or spiral out of the normal budget range.

Active involvement of the client representatives (even on the technical side) is required to determine all these factors. Hence, the partner channels (vendors) and clients must provide the best quality services and proactively participate in the ERP implementation.

With Microsoft Lifecycle Services (LCS), things are looking better for the future. A lot also depends on the service model, like whether vendors levy a monthly fee or charge on areas of specialty? A fragmented service model is more preferred as the Microsoft Dynamics suite keeps on expanding.

You might like

1 Comment

  1. Pingback: AX | Pearltrees

Comments are closed.

We use cookies in order to give you the best possible experience on our website. By continuing to use this site, you agree to our use of cookies.
Accept