Microsoft Dynamics, do not use
-
@scottalanmiller said in Microsoft Dynamics, do not use:
@travisdh1 said in Microsoft Dynamics, do not use:
@carnival-boy said in Microsoft Dynamics, do not use:
The product is great, if you have problems it's likely to be because of a poor partner, of which there are many. Microsoft made it too easy to be become a partner.
Yep, this was our issue. They use the same partner that the CEO has used for years. To say I'm not impressed is an understatement.
.... with the CEO.
Both
-
No-one is writing an ERP system from scratch and no-one wants a completely inflexible system. Microsoft has met the challenge of making a SaaS solution that allows for customisation and third-party add-ons whilst still being seamlessly upgraded to a new version every month. I'm not sure if other ERP vendors have managed this.
-
@carnival-boy
Many moons ago (when most screens were still monochrome) I wrote an ERP for a manufacturing company. It was built from the ground up to meet their needs. It was extended to include barcode scanning and some other enhancements that were not considered initially. Long story short, this solution is still in use today decades later. Did it take a lot longer to work it from the ground up? Hell ya. If a framework like Dynamics existed, it would have saved a lot of Dev time. We would have been quicker to market using a framework. Would it have been better? More reliable? I'll vote for more troublesome using a generic platform like Dynamics.
Given how long it has been used with only minor enhancements, their TCO is awesome. Is it the right answer for everyone? Obviously not. However, it should always be part of the conversation. -
@jclambert I've developed ERP systems, also many moons ago, working for an ERP vendor. But the world has moved on, and gotten more complex.
I would never consider developing a bespoke finance system now. Not least because of modern statutory requirements. For example, in the UK, the government will only accept tax returns directly from an ERP system. Apart from the complexity that developing that requires, the rules are constantly changing. It is so good being on SaaS knowing that as the government changes the rules, Microsoft will quickly roll-out a solution, and next month the software will be automatically updated in the middle of the night and just work.
-
@carnival-boy said in Microsoft Dynamics, do not use:
@jclambert I've developed ERP systems, also many moons ago, working for an ERP vendor. But the world has moved on, and gotten more complex.
...It is so good being on SaaS knowing that as the government changes the rules, Microsoft will quickly roll-out a solution,...
That is a double-edged sword.
-
@carnival-boy said in Microsoft Dynamics, do not use:
No-one is writing an ERP system from scratch and no-one wants a completely inflexible system. Microsoft has met the challenge of making a SaaS solution that allows for customisation and third-party add-ons whilst still being seamlessly upgraded to a new version every month. I'm not sure if other ERP vendors have managed this.
People actually do write ERP from scratch. @pchiodo did it recently for what is now a Fortune 100 manufacturer in the US that's worth $51BN. So that no one does I think is very overblown.
I've yet to have a customer that didn't write their own from scratch that wasn't sorry afterwards when they realized that they paid more and got less.
-
@scottalanmiller I don't believe that's possible. Standalone systems to handle, say, stock control, maybe. But full ERP with finance for a $51bn company - no way.
-
Unless you're talking a massive team and millions in development. But even then...
-
@carnival-boy said in Microsoft Dynamics, do not use:
@scottalanmiller I don't believe that's possible. Standalone systems to handle, say, stock control, maybe. But full ERP with finance for a $51bn company - no way.
Big ERP vendors make it seem like there is SO much than has to be done. And there is a bit. But the amount necessary is far less than they would have you believe in most cases. At least in the US where you dont' have some legal ERP interface requirement where your ERP vendor has to have a government deal to be usable.
-
@carnival-boy said in Microsoft Dynamics, do not use:
Unless you're talking a massive team and millions in development. But even then...
Millions, of course. But ever found an existing ERP implementation of any size that didn't take millions?
But no massive team, that's a common mistake. Big teams rarely make good software.
-
OK, I don't work in the enterprise space. Or in the US. Maybe the US is simpler with less statutory requirements.
Although having just implemented US Sales Tax for a client, I really wouldn't fancy developing that from scratch.
-
@carnival-boy said in Microsoft Dynamics, do not use:
OK, I don't work in the enterprise space. Or in the US. Maybe the US is simpler with less statutory requirements.
Although having just implemented US Sales Tax for a client, I really wouldn't fancy developing that from scratch.
Well, keep in mind that sales tax doesn't apply to business to business vendors (so very few manufacturers, for example) and that there are simple products you can buy that do the sales tax for you. So even if you build your own ERP in the US, and you need sales tax, that's generally just an API call to a paid tax calculation service.
That's kind of cheating, but these days nothing is a completely contained product. Almost always going to call out to SOME other system. Even big commercial ERP products often use these third party tax calculators for specific tax functions.
-
And when you build an ERP in house, you are obviously stuck maintaining a team for that, for forever. But generally the same if you put in SAP. A good friend of mine does SAP integration for a smaller manufacturer in New York. Their full time, dedicated SAP support team is larger than the in house development team for the bespoke ERP for a larger company.
They are similar manufacturers in that they are both multi-nationals, use similar supply chains, etc. And the SAP implementation is more costly up front, took longer to implement, carries more ongoing risk, requires more ongoing cost, and does less.
