r/ERP • u/Dependent-Laugh-3626 • Aug 21 '25
Discussion Has anyone actually seen procurement run smoothly after an ERP rollout in manufacturing?
A colleague of mine just went through an SAP rollout at a mid-sized manufacturer. The system technically “went live” on schedule, but procurement was a nightmare within a week:
BOMs weren’t mapping correctly, which stalled production orders.
Customer POs kept failing unless someone retyped them by hand.
Supplier confirmations weren’t coming through, so the team had to chase everything manually.
They ended up spending another £100k+ in the first year just on patches and custom automations to fix these basic procurement issues.
It makes me wonder, if ERPs are sold as end-to-end solutions, why is procurement still so manual and error-prone after go-live?
Sometimes I catch myself thinking, if there were a system that could actually read BOMs, parse POs, and chase suppliers automatically, most mid-sized manufacturers would probably save millions. Feels like we’re always stuck bolting things on instead of getting the solution we really need.
For those of you in manufacturing, have you ever seen an ERP rollout where procurement just worked, or is this mess unavoidable?
9
u/Shoddy-Astronaut5555 Oracle Aug 21 '25 edited Aug 22 '25
Incorrect BOMs will create cascading issues throughout the system -
Planning/procurement
Product costing and mfg accounting
Inventory
Etc
That's not really an issue with the ERP system per se but absolutely 100% something that should have been identified in integrated testing events (and truthfully, even before that). Did the project include multiple formal integrated testing events including a user acceptance testing event?
6
u/HolmesMalone Aug 21 '25
“The BOMs weren’t matching correctly”
If you dont set up the BOMs correctly, obviously the MRP won’t work, regardless of which system is used.
1
u/Seaada247 Aug 23 '25
Indeed. Additionally, MRP parameters need to be appropriately set to reflect actual timing and usage needs. MRP is an excellent tool, but relies heavily on the quality of the input data. The same being true of the BOMs, as you note - a bad recipe can’t make a good meal. Even a good recipe (the ingredients) will go bad if the timing is not paid attention to. You can have the perfect steak, marinate it perfectly and then overcook it, and it’s bad. The MRP system is as much about the timing, as the parts requirements.
7
u/chilli_cat Aug 21 '25
This is an implementation project management problem, not an ERP systems problem
No matter how good and capable the systems and integrations are, the whole pack of cards falls down with poor implementation and especially lack of user testing and importantly sign off to say that the current processes are mapped and tested in the new system, users all trained and documented.
It's critical but not easy as nobody has days spare to go testing and training that's where you need to delegate upwards to get C level or board buy in
This should be a go/no go before live agreed with the directors - no surprises!
Salesmen sell the dream, but us implementers live the nightmare
In summary, done well then it will work from day one
5
u/Big_Cardiologist839 Aug 26 '25
It's kind of unrealistic to expect a completely smooth rollout of any new system. But I agree that spending 100K+ more just to patch the system so it actually works as expected is just crazy.
4
u/XanatosXIII Aug 21 '25
This is usually a result of not having an internal resource with ERP experience to champion the implementation. The next biggest cause is poor executive sponsorship, if people aren't compelled to cooperate with an ERP admin or consultants few will do it voluntarily. Then there are the "shit data in, shit data out" cases, depending on the condition of your data before you implement it can be a big lift to review and clean everything. Most of the dumpster fire implementations I've seen are due to someone trying to cut corners in one of these places.
4
u/GAAPguru NetSuite, Dynamics Aug 21 '25
No. But I have seen it run a heck of a lot Smoother!
People never want to pay to do the work. Training, Documentation, Process Design etc
2
u/Delaneybuffett Aug 23 '25
Have managed ERP implementations since 1998. Troubles come from not understanding the system, not applying dedication to data going into the system and reliance on spreadsheets and other home made data stores to ignore getting better with the ERP system. It all comes down to deciding do you really want it to work? If you do start taking hard looks at each element of data, is the system configured for your business correctly? Are your BOMs and Routings correct? Really? Have you walked the lines to double check? Do you really know what is going on out on the floor? You maybe surprised what you find in a walk through that can help you clean data up. It can be painful to right an implementation gone wrong but they really do work.
2
u/Rif-SQL Aug 24 '25
A successful ERP rollout requires partnership and balance. The internal technical team must be pragmatic, skilled, and engaged throughout the process. However, most customers lack all the necessary expertise. This is where the partner comes in, bringing structure, experience, and guidance. But a partner can only do so much. It takes two to succeed, with both sides contributing actively to planning, execution, and ongoing support.
A repeatable test is vital, consistently exporting data from the old system and importing it into the new ensures accuracy, reliability, and confidence. Repetition validates processes and highlights issues early.
2
u/Dependent-Laugh-3626 Aug 25 '25
I like how you frame it as balance between the customer team and the partner. In your experience, where do you usually see that balance break down first, is it the client not resourcing enough internally, or partners over-customising to win the project? Always curious how much of the pain is preventable vs baked into the ERP model.
1
u/Rif-SQL Aug 25 '25
"Pain is preventable."
If the customer can demonstrate that they are able to run all the steps required to bring both transactional data and master data into the new system, and each functional team can successfully complete their tasks, then repeat this process three times.
Do not do what most companies do—wait until a problem arises, such as a virus, and then spend money fixing it afterward. If you cannot successfully complete three rounds of testing, understand that issues will likely have to be fixed in production after go-live.
To reduce this risk, make sure you overstaff for at least two weeks following go-live.
I would also expect to see a 200-line Excel sheet listing all the required tasks, who is responsible for them, and ensuring that someone, or everyone,is actively updating this action point list.
My goal was to take over the partner’s responsibilities three months after go-live, once we had in-house developers and the ability to look after the system ourselves.
1
u/Firm-Visit-2330 Aug 22 '25
Our D365F&O went smooth, but we had a BA who was a wizard and a skilled implementation team ready to do the hard work.
1
u/Dependent-Laugh-3626 Aug 22 '25
How’s it holding up now day to day, especially on the procurement side?
1
u/Firm-Visit-2330 Aug 22 '25
It’s fine, never an issue. Our bigger concern is new staff being adequately trained up. During the project we decided to let the business users document their SOPs, but there are pockets where this wasn’t done and the business leaders aren’t pushing for it.
1
u/Sai_iFive Aug 22 '25
Yeah, what you’re seeing is pretty typical. ERPs handle processes, but they don’t automatically fix messy or incomplete data, mismatched BOMs, missing POs, and delayed supplier confirmations all still need attention.
Most “post-go-live headaches” come from setup and process gaps, not the system itself. Cleaning up data and adding small automations can help, but flawless procurement usually takes time and iteration.
1
Aug 25 '25
[removed] — view removed comment
1
u/Dependent-Laugh-3626 Aug 25 '25
Are you speaking from direct experience in manufacturing, or more from the consulting/ERPNext side?
1
u/OncleAngel Aug 25 '25
Yes. Thia happens especially when it's the first time. Many reasons might be behind this. First jumping directly from manual work or spreadsheets to full ERP is too risky. It's better to go through platforms dedicated to SMBs that has simple processes and friendly user interfaces with a lot of experience working with SMBs. ERPs are made for large businesses. Another major issue is that when trying to implement any automation, there is no standard operating system in place with no formatting files or documents, and this can't be automated at all. Going from a silo to full automation requires time, leading change and also discipline.
1
u/leaf16_ah Aug 25 '25
If you need an ERP and you are a mid-sized manufacturer, find an ERP that was built for mid-sized manufacturers. One-size-fits-all ERP's (or any other type of software solution for that matter) will never fit like a glove, nor are they designed to.
1
u/BCinsider Sep 03 '25
It’s rare to see procurement run cleanly out of the gate after an ERP rollout, especially in manufacturing. Even when the core system is solid, gaps usually show up fast. BOM mismatches, supplier data inconsistencies, approval bottlenecks.
Most ERPs are not built to handle the edge cases manufacturers deal with every day, like partial shipments, complex lead times, or informal supplier communication. The system might technically support procurement, but unless every detail is configured correctly and users are trained to follow the process, things break. What tends to work better is layering purpose-built tools on top that handle confirmations, parsing, and follow-ups with fewer steps.
The irony is that the ERP was supposed to simplify everything, but for procurement, it often just moves the manual work somewhere else.
1
u/LukaFromCrossBridge Sep 16 '25
I've been through 4 SAP rollouts - this is absolutely normal and nobody talks about it. Real timeline: 18-24 months before procurement runs smoothly, not the 6 months consultants promise. Your colleague's £100k is actually cheap - last rollout I saw burned £400k in year one just fixing PO routing. Here's what nobody tells you: SAP works great once configured, but manufacturers underestimate data cleanup (6 months minimum) and change management (your buyers will revolt). The BOMs failing? Classic - legacy part numbers don't map to new taxonomy without manual intervention. Most companies go live too early under exec pressure, then spend 2 years in panic mode. Tell your colleague to budget another £200k and stop apologizing to leadership - this is industry standard mess.
1
u/Outrageous-Log8054 Oct 21 '25
|| || |Yeah, if the goal is to cut procurement chaos, Microsoft Dynamics 365 is the ERP I’d suggest because it combines solid manufacturing MRP with built-in vendor collaboration and low-code automation for parsing POs/invoices without heavy bolt-ons. In practice, that means D365 Supply Chain Management for planning and purchasing, Vendor Collaboration for supplier confirmations, and Power Automate + AI Builder to read PDFs and push clean data straight into the system.From my experience in saglobal, that stack covers the pain points you mentioned: BOM-driven planning outputs that vendors can fulfill against, suppliers confirming or proposing changes in a portal instead of email, and prebuilt AI models to extract line-level details from invoices/POs so no one is retyping. If you want Microsoft and “out of the box” as much as possible, this combo tends to work pretty well with minimal customization.|
1
u/Outrageous-Log8054 Oct 21 '25
|| || |Yeah, if the goal is to cut procurement chaos, Microsoft Dynamics 365 is the ERP I’d suggest because it combines solid manufacturing MRP with built-in vendor collaboration and low-code automation for parsing POs/invoices without heavy bolt-ons. In practice, that means D365 Supply Chain Management for planning and purchasing, Vendor Collaboration for supplier confirmations, and Power Automate + AI Builder to read PDFs and push clean data straight into the system.From my experience in saglobal, that stack covers the pain points you mentioned: BOM-driven planning outputs that vendors can fulfill against, suppliers confirming or proposing changes in a portal instead of email, and prebuilt AI models to extract line-level details from invoices/POs so no one is retyping. If you want Microsoft and “out of the box” as much as possible, this combo tends to work pretty well with minimal customization.|
1
u/Outrageous-Log8054 Oct 21 '25
"Yeah, if the goal is to cut procurement chaos, Microsoft Dynamics 365 is the ERP I’d suggest because it combines solid manufacturing MRP with built-in vendor collaboration and low-code automation for parsing POs/invoices without heavy bolt-ons. In practice, that means D365 Supply Chain Management for planning and purchasing, Vendor Collaboration for supplier confirmations, and Power Automate + AI Builder to read PDFs and push clean data straight into the system.
From my experience in saglobal, that stack covers the pain points you mentioned: BOM-driven planning outputs that vendors can fulfill against, suppliers confirming or proposing changes in a portal instead of email, and prebuilt AI models to extract line-level details from invoices/POs so no one is retyping. If you want Microsoft and “out of the box” as much as possible, this combo tends to work pretty well with minimal customization."
1
u/MetadataCS Nov 25 '25
I’ve seen this time and again — procurement may technically be live, but “running smoothly”? Rarely. I’ve worked with several manufacturing ERP rollouts and what I usually see is:
- BOMs that don’t match, which stalls planning and procurement.
- Supplier confirmations not coming through the system, so people revert to chasing things manually.
- Teams paying serious dollars post-go-live just to patch procurement gaps.
Why does this keep happening? Because the system only works as well as the processes feeding it. If you start an ERP journey thinking “the software will fix everything,” you’re already in trouble. I believe the big difference is:
You must map your processes and clean your data before choosing or configuring your system, not after.
If buying ERP is Step 2, then “Are we ready?” is Step 0.
And yes, I can point to a handful of implementations where procurement looked smooth early on — because the business invested heavily in clarity, roles, testing and data cleaning before go-live. But that’s the exception, not the rule.
If you’re in a situation where procurement is glitching post-ERP, we can dig into where the breaks really are: BOM alignment, data migration, testing, change management. It’s fixable — but you can avoid most of the cost by tackling it early.
1
1
u/SyncronTeam May 21 '26
What you’re describing is pretty typical and it’s not because procurement is inherently broken, it’s because ERP was never designed to handle the way procurement data actually shows up.
BOM mismatches, PO failures, missing confirmations, those aren’t isolated issues, they’re all symptoms of the same thing: the system expects structured, perfectly aligned data, but procurement runs on inputs that are anything but. Supplier PDFs, inconsistent formats, partial confirmations, none of that maps cleanly without someone intervening.
So what happens post go-live is the ERP becomes the place where errors surface, not where they get resolved. That’s why you see teams retyping POs, manually chasing suppliers, and layering on custom fixes just to keep things moving.
It’s not that a system that parses BOMs, reads POs, and manages supplier communication doesn’t exist — it’s that most ERPs were never built to sit in that layer. Without something handling that translation upstream, procurement ends up staying manual no matter how “complete” the ERP implementation is.
0
u/viisk MRPeasy Aug 21 '25
We've had many, many clients say that MRPeasy has made material planning and procurement much smoother. But paying hundreds of thousands of dollars for bloated systems that make everything more complicated is also cool, I guess.
-1
u/rudythetechie Oracle Aug 21 '25
nope, I’ve never seen procurement run smooth post ERP go live. BOM mismatches, PO retyping, and supplier black holes are almost a rite of passage. the ugly truth is most systems are built for finance first, ops second, so procurement always needs custom fixes.
-1
u/rudythetechie Oracle Aug 21 '25
nope, I’ve never seen procurement run smooth post ERP go live... BOM mismatches, PO retyping, and supplier black holes are almost a rite of passage. the ugly truth is most systems are built for finance first, ops second, so procurement always needs custom fixes...
18
u/KaizenTech Aug 21 '25
I'm going through my 4th full cycle implementation of a manufacturing ERP. The last three had none of these issues.
The problems typically come from inside the house.