By: James Fleming
When I joined Element Material Technologies two-and-a-half years ago, the company had gone live on Dynamics AX 2009 fairly recently, in 2010. So when Dynamics AX 2012 came along, there just wasn’t much of an appetite for an upgrade.
The task became to maximize AX 2009’s capabilities and future-proof it, and we developed a lot of extra functionality for it, between internal developers and our Dynamics partner.
We are now at the point of moving forward, if for no other reason than heading off the expense of extended support for Dynamics AX 2009. But alongside that there are a ton of really good new features in Dynamics 365 for Operations that we could take advantage of, and that is the version we’ll migrate to.
The features aside, I really like the whole ethos behind Dynamics 365, the whole client story that Microsoft is building. In the cloud upgrade path, it’s all quite incremental and small, and no new major version ever comes along.
With Dynamics 365 comes the Microsoft stack.
For us, a lot of the value proposition of Dynamics 365 is around cloud enablement, Azure Machine Learning and other Azure functionality that we’ll have access to out-of-the-box, and the integration of Power BI.
It’s an ambition of mine to enable our end users to consume data more easily, which they will be able to do with Power BI, just in terms of easy-to-use dashboarding. They must be able to drill down into our data, and whilst there are plenty of tools that can do similar things, the fact that this will be built into the application has great pulling power for me.
As for how we, as an engineering firm, will use the Microsoft stack, a lot of that’s still under investigation.
Machine learning is one area we’ve played with for a while, and we believe we can get some benefit in the area of predictive maintenance. A large portion of our business is carrying out testing on our precision machines, and like any machines, ours break down periodically. So our ability to predict when that is likely will save us money. And in testing, by combining the data that we’ll be able to get out of Dynamics 365 with the historic tests we’ve carried out and new data that we pull off the testing equipment, we should be able to start building up a whole data structure using machine learning to predict results.
At the moment, we don’t know everything that’s possible. But I’m certain that given the amount of data that we’ve got and that we continue to generate, those capabilities are going to really pay dividends for us.
We’ve invested an awful lot in the product over the years to get it to where it is today, absolutely.
Much of that is now out-of-the-box functionality that we’ll get as part of the Dynamics 365 license, and that’s great news. Bearing in mind we’re on Dynamics AX 2009, being able to use things like apps for expense management and purchasing will be big shifts for us. It will be a step up in A/R and A/P functionality that’s not in 2009, but came into AX 2012 and later into Dynamics 365.
We expect to use fewer ISV solutions as well. One thing we may do down the road is to look at implementing the new HR features. Historically that’s something we would have looked to an ISV for, but we may well not have to. That’s a great example of Microsoft building out those core capabilities.
All of that aside, we do not expect all of the functionality we need. In some cases, those customizations we’ve built are just very specific to an engineering and testing firm.
Dynamics 365 calls for a new IT mindset
As user companies, we’ve really got to get the IT people into that state of mind where they’re on a continuous improvement path, which is very different from the way a lot of IT teams are focused.
In a company with a headcount of about 2,000, our IT team is 34 people, and I expect the move to Dynamics 365 will be a paradigm shift for them. The infrastructure and servers on which we relied will start to disappear.
But an even greater change will be getting into that mode of continual updates, and ones that you can’t not take, which is a slightly scary place for a number of IT people. They like to feel they’re in control of what happens, and when. The challenge becomes that a user company waits a long time before doing anything and discovers it’s no longer looking at an upgrade, but a reimplementation. In the new paradigm, you can wait perhaps six months, but there comes a point at which you’re going to have to take the latest update.
That’s a very new mindset, and I think a very positive one. We can then deliver enhanced functionality and security updates on a more predictable basis.
The end of building a business case for updates
There’s still, obviously, a great need for testing and checking compatibility before you roll these things out. You still must have a very structured, disciplined way of doing that. But it removes the whole need to do mass versions of upgrades in the way that we have, historically.
In on-premise architectures, Dynamics updates or upgrades involved big, chunky costs. The same was true of Microsoft Office or Windows, in that if you ever wanted to do a complete rollout to get everybody on the same version, you were suddenly looking at a lot of money.
Those more frequent and cloud-based updates keep everybody on those later versions and halt that need to do huge investment cases and huge projects. So, in addition to migrating to Dynamics 365, we’re piloting Office 365 and will look at the whole Microsoft Systems Center application later in the year, to standardize our Windows environment.
Essentially, we still must build a business case, but just once, at the point of migration to the cloud.
I don’t believe that Element is atypical in that we’ve implemented AX 2009 and maintained it, rather than upgrade to AX 2012. But with AX 2009 going out of support in a few years, we need to move on, and I look forward to it. Between continual updates and leveraging the Dynamics stack, the business case is clear.