7 Things That Are Extremely Wrong With The Current Microsoft Dynamics AX/365 Implementation Methods

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 introspective than it 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.

Microsoft AX

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. The demos must be carefully evaluated 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 through their answers to 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 the major role in drafting) rather than third party sourcing solutions – as they are more familiar with the company requirements and pain points that need to be addressed by the ERP solution.

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

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

All the information gathered in the sales cycle does not even see the light of the day when the ERP implementation is sanctioned and the project moves into development. If the kick-off is not done in collaboration with the sales team that has worked on the requirement gathering, the development team often misses out on bits of vital information specific to the client that has been 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) on board 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.

  1. 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 go about digging 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 the rest 20% client-specific information from the client company.

  1. Expectation gap between vendor and client.

More often than not, vendors put their technical expert in direct communication with the client. This is a big mistake, as most clients expect their point of contact to guide them on how to better their ERP solutions to address their business-related problems. This creates expectation gaps as the technical experts keeps 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.

  1. 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. The vendor on the other hand waits for pointers from clients as to what they want to be incorporated in the ERP Solution. The budget too depends on a lot of factors like short term and long term plans, change request processes, getting the right resources allocated to the project, etc. – as 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 both have to work to provide the best quality services and to proactively participate in the ERP implementation. With Microsoft Lifecycle Services (LCS), things are looking better for the future. A lot depends on the service model also, 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.