u/BrownAnclourne

Dimensions seems to works well when the entities mostly share similar structure and you mainly need consolidated reporting, but I want to know what happens once you have acquisitions, different COAs or entities that operate slightly differently.

Does the whole thing end up messy? (you keep adding dimensions to handle another entity, another exception, etc.) and at some point does it become harder to manage than having separate companies? I'm interested to hear from people who've actually dealt with this, where did the problems arise, if any?

Everyone talks about agents automating stuff after an ERP is deployed but I'm more interested on the implementation itself.

If you think about it, there's a lot of repetitive grind in any project, like :

• writing functional/technical specs
• putting together test scripts
• documenting configs
• checking data quality
• writing status updates
• fielding the same implementation questions over and over
• digging through release notes for what changed

Best case I can picture is someone opens a draft that's already halfway there instead of a blank doc and spends their time catching the stuff that actually needs a human like weird client exceptions, the thing that technically works but blows up in UAT. That's really it. Not automation, just less staring at nothing.

So where's the line for you? What's something you'd hand off without thinking twice, and something you'd never trust it with, even years from now?

I would like to hear from consultants who've been through bigger rollouts.

Had azure autoscaling setup for a workload with spiky traffic. The logic was straightforward, scale out during peaks, scale back in when demand dropped and nothing was actually wrong per se with the config but the scale down rules were conservative enough that azure kept running extra instances most the day as a safety buffer and we were paying for near peak capacity for long stretches even though we only hit the levels a few times per week.

Tightened the scale down threshold and its better now, but still not fully sure that its the right balance, is going aggressive and eating occasional latency the way or keeping buffer and eating the cost?

Set up automated purchase requisitions based on min/max levels instead of having someone eyeball stock every morning which worked okay for the standard parts, but the trouble started when the system kept triggering reorders from flat historical averages with seasonal items, so a few line leads started adjusting the quantities before the job ran.

Took a while before anyone realized what was happening (everything looked fine because requisitions were still being generated on schedule) but it wasn't until we talked it out with the planners that we found out about a third of the SKU's were getting manually changed almost everytime, so we're still deciding if its worth building seasonality into the planning logic or whether some product lines need a planner to make the final call.

How do you usually handle seasonality in M3?

Was involved with a rollout for an industrial parts distributor after a few regional acquisitions and each site was on a different version of the same legacy ERP, so going forward with everything at once wasn't really realistic, and the migration happened by site which meant the old and new systems had to run together for a bit.

The difficulty was keeping GL,AP and AR aligned when some sites had already moved and others hadn't. Finance still needed to operate normally and couldn't really be paused/put at halt till the end of the migration, we had a daily sync process which kept transactions aligned between systems while each site moved through its cutover window. The issues arose in the in between period where one site would be live on the new ERP and another still on the old and finance needed both sets of numbers to lineup during close.

the numbers were solid but nobody wanted to trust it because nobody trusted WHY it said what it said, it just felt like a black box next to their own sense of the market, ended up stripping it back to three visible drivers so people could sanity check everyday before opening. still bothers me a bit that accuracy alone wasn't enough to earn trust and I wonder how many other models are just sitting around unused for similar reasons.

how do people balance building an accurate model vs one that a business will actually use?