Understand the Challenges When Adapting Microsoft Dynamics AX for Multinational Companies

January 25 2012

More and more enterprise users of Microsoft Dynamics AX are adapting the ERP software for businesses scattered around the world.

About Linda Rosencrance

Linda Rosencrance is a freelance writer/editor in the Boston area. Rosencrance has over 25 years experience as an reporter/investigative reporter, writing for many newspapers in the metropolitan Boston area. Rosencrance has been writing about information technology for the past 16 years.

She has covered a variety of IT subjects, including Microsoft Dynamics, mobile security issues such as data loss prevention, network management, secure mobile app development, privacy, cloud computing, BI, big data, analytics, HR, CRM, ERP, and enterprise IT.

Rosencrance is the author of six true crime books for Kensington Publishing Corp.

More about Linda Rosencrance


magic1949's picture

multi company is best when the verticals and processes are similar and there is a lot of scope for central services such as finance and purchasing. Ax 2012 makes it easier to enforce consistent data policies etc. Far more challenges come when there are multi-verticals and multi statutory localisations - in such cases central services are less feasible and the problems of conflicting code and upgrade fo multi companies is much greater. Each isv is unlikely to be compatible with the same Ax service pack, SQl pack etc at the same time, nor will they all be ready to migrate to a new release at the same time. The bigger the operation the grater the need for database emaiantenace such as defragmentaton and reindexing - the more companies and time zones, and audit dates involved the harder it is to plan system outages. Regional hubs with central financial consolidation may be a workable compromise. Consider the impact of a global payroll system- each country h=as an annual budget that chanes parolltaxes - what si the impact on your operations of taking your systen down each month to add the new code? What if one coutnry needs to upograde for staturoty reaosns and another couunty cannot because its isv module is not yet compatible at the new release? dotnet developments that are integrated make more sense- then you only have an interface upgrade to worry about. And those are just the easy points to cosndier!