Microsoft Dynamics, do not use
-
@dashrender said in Microsoft Dynamics, do not use:
Why aren't there super flexible completely online solutions available for this? Do those two things cancel each other out? super flexible - online (think SAAS).
Microsoft Dynamics is endlessly flexible, and that's part of what creates it's problems. The number of spreadsheets management creates with it is mind numbing.
-
@dashrender said in Microsoft Dynamics, do not use:
is it as flexible as on prem?
SaaS or on-prem is not the issue really it is still Dynamics. There is no fixed way it works. It is always 100% custom for each application. Then even within the application, the various developers seem to not be very standards based.
Dynamics was a great idea, poorly implemented by the various partners and developers.
-
Dynamics is just the brand name Microsoft gives to a number of different ERP/CRM products - none of them related.
Dynamics F&O (formally AX) is their enterprise product, competing with the likes of Oracle and SAP.
Dynamics Business Central (formally NAV) is their SMB product.
I work with Business Central and think it's great. They've done a ton of work in recent years to separate out the standard code from custom code which makes upgrades very easy. If you're on the SaaS version (which is the same as the on-premise version), Microsoft will automatically upgrade to the latest version every month, even with a loads of customisations.
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.
-
@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.
-
@jaredbusch said in Microsoft Dynamics, do not use:
@dashrender said in Microsoft Dynamics, do not use:
Why aren't there super flexible completely online solutions available for this? Do those two things cancel each other out? super flexible - online (think SAAS).
Microsoft Dynamics NAV is extremely flexible (customizable). This is the problem.
Right, flexibility is the core issue. Eventually, with enough flexibility, any product just returns to being a programming language.
-
@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.
-
@jaredbusch said in Microsoft Dynamics, do not use:
@dashrender said in Microsoft Dynamics, do not use:
is it as flexible as on prem?
SaaS or on-prem is not the issue really it is still Dynamics. There is no fixed way it works. It is always 100% custom for each application. Then even within the application, the various developers seem to not be very standards based.
Dynamics was a great idea, poorly implemented by the various partners and developers.
Similar to SAP or more ERP products. To make a generic ERP you have to offer so much flexibility that you essentially need custom programmers who specialize in programming that ERP to make things work. This generally falls into a really bad space where skilled people don't bother as the work isn't fun or generalized enough, and the people who are willing to do it can charge anything that they want, and there is little competition or good knowledge of what to do.
Something even more general, like PHP or ASP.NET gives you more power at often lower cost. Something more rigid like a specially built ERP means you need no programming at all and adapt your workflows to it. Both of those have huge advantages. General purpose ERPs tend to fall in the crack where you get the worst of everything, rather than the best.
-
@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.
