With the release of Microsoft Dynamics AX 2012 coming very soon, there is a lot of great new technical abilities that will exist. There is a slew of articles, blog post, etc. that cover some of these topics, from Services, to Reporting, to the Model Driven Layered Architecture (MDLA), and so on.
With this, and being a techie at heart, I'm super excited about all the great possibilities that exists. This includes, with all the great features, and choices even within X++ and the use of Eventing, as well as the choice in development with what can now be done with .Net / C#. This represents new ways to solve business domain issues, and opens the door to implement some great, in theory, new features and practices. Now with this said, we have to take a step back, take a deep breath, and realize, that we are still working in the ERP / SCM domain.
The goal then, for such software, is always to solve business domain issues for companies, and the underlying driving factor is to drive value. This is the only reason we should ever do something, to drive business value. So as the post title states "Just because you can, doesn't mean you should", really has to be applied to implementations. This has always been the case really, and still will be the case for AX 2012. I think its easy to get caught up in making technical decisions, that might be very elegant solutions, that in the end though, does not drive true, best value and ROI for the cost of doing such designs.
One story, that I know most any ERP or CRM consultant tells, and has been through if they have been in the game long enough, is around replacing older, legacy systems. In this process, there is always requirements gathering, and GAP analysis that takes place. During that, we as the partners and consultants run into the 'Well in our old system, we only had to press one button to do 'X', and in AX you have to press, in this example for simplicity sake, two buttons to achieve the same end result.'
Now, if there is truly a valid business case, that AX should be customized to have that easy button, and weighted ROI can be shown, then fine, that's what should drive such custom scope. However, most likely the cost in real dollars to create the new custom scope, for enabling such an easy button, and then the weight of having that as 'just one more thing' to maintain, does not typically justify the ROI for such an effort. And in reality, the process might be better suited, as designed, without moving forward with the customization. If this is true, then the correct action, is to update the companies process, and have the persons role no longer have an easy button. Instead have two easy clicks, from our point!
Obvious this is very simple, in comparison to what a lot of scope looks like. The idea is the point, not the example. The idea, and the vision, and driving force behind any scope of any project relating to Microsoft Dynamics AX 2012, should always be driven by functional design, and true business requirements, that drive bottom line value to the company that will be using AX.
So, it's exciting that we are on the verge of such a great new release of Microsoft Dynamics AX, and there is such much to look forward too. Microsoft has really done a great job, still the burden of correct use, correct implementation, falls upon the shoulders of the Partner Ecosystem, and the Customer, in a joint effort to deliver true value for it's use.
I will end, with something I start a lot of project kick offs with, one of the greatest things about Microsoft Dynamics AX is that you can change almost anything about it. This happens enable one of the worst things about Dynamics AX at the same time, you can change almost anything about it! Not to say I think there is anything bad at all with Microsoft Dynamics AX. It's meant to be Dynamic, as the name implies. It's also not to say it cant be done, for whatever 'it' may be. Heck I can integrate Dynamics AX into anything, including to working your business lights, with the right automation tools, development time and dollars. But does it make sense to do so? Or is the better value, is to still allow your employee's to use the good old light switch to perform this action?
I hope the point is made, step back to look at the problem or, business domain issue, at hand to see why that may exists, before jumping right into a solution, that might not be needed. That's all for now, till next month!