> (Ex. manufacturing moving back to home from China, and maybe lights out manufacturing).
Badly chosen example, though. Looks like a case which can be handled through configuration alone in SAP ;-) In general, automated physical processes of all kinds usually can easily be automated in software, too. Problems are often because in most companies, especially in procurement and production prioritization, lots of of manual, ad hoc decision making is at work without formalized processes.
The actual problems with ERPs are usually more a "devil in the details" thing.
To give a real life example where people run into problems with standard ERPs: (it is pretty boring actually, but boring stuff like that can make or break a company)
I for example once had a customer running SAP. Hope I still get all the details right, it was a while ago. Customer was mostly a home decor trading company which sold to chains. It manufactured parts of its products in a subsidiary in another country and also bought various products in China. I was drawn into the project to "translate" between the company's management and their SAP consultant/developer, as there were, uh, problems there.
Problems started when, after a takeover of the company, they wanted to move to a more just-in-time process for their own manufacturing to reduce warehouse sizes while at the same time their eager sales team committed for some large customers to delivery times which were impossible to fulfill if the ordered product is lying somewhere for more than a day, so they had the problem that they had like 5000 different products, were not allowed to stock them anymore, but had to deliver orders after 7 days while the product was "on the street" for at least 4 and half of these days.
Basically that meant, if an order was somewhere stuck in the process for over half a day after they accepted it, they were fucked and had to pay damages to the customer.
So, task was to tighten the schedules so everything goes smoothly, while at the same time manufacturing capacities where limited, the physical process itself also had limitations (like, even if a customer ordered 1 product of a certain kind, at least 8 of that kind had to be produced, so sometimes it was a good choice to produce something a day too early and stock it for a day to optimally use the production capacities), so it was important that an order was denied right at the start and that the estimates if it can be fulfilled at all were correct from the beginning.
Now, SAP has mechanisms for all of this. Just not the way the company needed (at least not with the ERP alone. Additional components, like SAP APO, might have improved this, but those were not licensed and implemented). Basically, there were two types of sales orders in the system, both did about 80% of what the company needed, you could either produce for stock and sell from stock like they used do when they still had their larger warehouse, but this caused problems as manufactured product sometimes was not packed optimally, so stuff had to be taken apart and repacked for final delivery (because from the manufacturing plants point of view, only an order for e.g. 50 units of product X came in for that way), or express orders came in for identical goods and because not enough could be produced in time, the less important customer got the delivery when both where overpromised.
Alternatively, as would have been the better choice, they could have used make-to-order production in the manufacturing plant and directly associate sales orders and manufacturing orders. This would have been the natural way to do it, but there were "reasons", again routed in the way labor was organized at that plant, that this could not be done.
Oh, and of course, even after solving the production orders, there was still the problem that the sales orders also contained trading goods from China, so that also had to be integrated into the final delivery to the customer at an optimal point in time.
So the company basically needed a custom cross of both methods, which the ERP naturally did and could not support, as the special circumstances could never have been foreseen (Actually, to this day, I would say this was a typical case of politics and company inertia at work. The labor processes actually would better have been reorganized in a way to make a standard process work. I warned the customer, the SAP consultancy warned the customer, but "nothing can be done about this").
So this was unfortunately the time where we had to heavily make changes to the system - custom reports for availability planning, some custom user exits to modify the production start times when orders where transferred between sales and production, lots of small detail stuff like that to make the process go flawlessly at least in software.
The software project actually was successful, mainly because the SAP consultancy was not as bad as my customer believed, they just needed someone who could actually properly describe the problem, so we got away with about 100 development hours, which is not much in an SAP context, simply because the system is so darn huge, you will probably spend 10 hours alone to find the proper location in the business process to apply your change to.
Sadly, customer still went bankrupt. Because the physical process was suboptimal still. But at least the software could model it in the end ;-)
