The Dynamics ecosystem love to complicate things. And now with the AX 2012 R3 it can really get complex, with the biggest codebase ever. The more functionality we demand to get into Dynamics AX, the better it will become, and the more we can sell, right?
Simplicity wins. Every time. (iPod, anyone?)
As a Dynamics AX “expert”, I get to hang out with other Dynamics AX “experts” (and we act all clubby and hip and cool like it’s some secret club – but it really is). In those circles I get to see and hear a gajillion awesome features that allows us so solve ANY problem. (Basically because the solutions is sets of LEGO-bricks we are selling, and you can build anything with LEGO)
Oftentimes, many of the solutions is over-complicated complex. For the ones that isn’t, the difference between a winning or losing solution invariably comes down to simplicity and elegance.
Look folks – if we want to win in the ERP-marketplace, we must focus more on simplicity (twitter’s 140 characters anyone?). A few things to think about:
– What EXACTLY is the problem we are trying to solve? Do a lot of people have it and want it to go away?
– What’s the CURRENT way our customers treating the problem? THAT’S our competition – it’s their next-best alternative relative to your proposed solution. THAT’S what your solution has to beat (both from a capability and cost standpoint including accounting for switching costs).
– What’s the ABSOLUTE MINIMUM solution you need to put on the market to solve the problem? BUILD THAT and validate you have a solution that works.
Stop making solutions so hard, complex, and confusing. We are wasting investment dollars that instead could be used for marketing and scaling our much simpler (and cheaper to build) alternative solutions.
Create solutions that only require a few weeks of implementation time, and that is so easy to use that it can be trained in minutes.
“Simplicity is the ultimate sophistication.”
– Leonardo da Vinci
2 thoughts on “Dynamics AX: Why simplicity always wins”
Pingback: EPL DATA | epldata
Nice article! But what about those two customers of “do-it-my-way” and “just-do-it” type? Which one would you prefer to work with? How do you evaluate an average budget of a project of each type? How would you implement several projects with different business needs? Would you build and support several simple solutions for each project or one sophisticated solution to fit them all? How would you support local regulations in your projects? Would you implement and support several localizations for each country/region (like DIS layers in Axapta 3.0)? What about global implementation across several countries/regions?
Software complexity is kind of a function from the business needs and local regulations’ complexity. If your software product is simple and neat then that’s what your customers have to be: “just-do-it” type, nice to deal with, not demanding – and with limited budgets for their IT projects. Muck and money go together 😉