If your ERP can't keep up, then that is an ERP-shaped problem. Escalate with the CFO and CTO since the latter probably signed the responsibility/ownership (albeit probably indirectly) for delivery. In the mean time (since the real world is imperfect) you would of course rather kludge it than do nothing. But you would probably not rebuild the entire ERP in excel, forever, which is what I will fight against.

We don't have that problem, our ERP team can keep up. Perhaps that is because our rate of acquiring and divesting is maybe 2 or 3 cases per year. We are only active in a couple of countries per BU in the cases I write about, so that makes it easier as well.

On the other hand, if the ERP team isn't capable of producing the rate of change needed to support the business requirements, I really hope that you get that sorted since that is practically the entire reason an ERP team exists.

We do deploy changes (technical changes) about 200 times each day, of which the teams dealing directly with business workflows do about 60 (including some stock, pricing and WSSI teams). It's not a lot, but it allows us to have nearly no lag time between business needs and implementation delivery. It did take a while to get to that rate, and a 2-week feature freeze one time to shift all processes to a model that allows for this change rate. But it works well for us. (and reporting, visualisation, ETL, and ML are all done without spreadsheets for about 3 years now)

As for why we did that (in case that was a question you'd be asking since it is obviously not a change that costs nothing): we no longer wanted to accept the risk of doing it the old way, we also didn't want to have as much onboarding friction due to having many diverse sub-workflows inside teams, because even if you did learn about what someone DIY'ed in your local team, you will still run into the same problem ad-hoc when dealing with other teams, usually at the worst possible time. Same goes for off-boarding, we don't want to spend months trying to figure out what custom stuff someone put in place, especially since you get non-engineering solutions to engineering problems (the excel shaped one) but also engineering solutions to non-engineering problems (the python notebook one). We want our people to be able to spend as much of their time on the actual work instead of side quests that don't add the value we are looking for. It doesn't mean exploration or experiments are banned, but it does mean we want to facilitate as much as we can so you don't have to do anything extra by default.

See my other comment, we have over 1000 factories in many countries. 23 different ERPs in my division alone apparently. They are constantly trying to standardise, but acquisitions happen faster than factory ERP implementations. When you acquire a group that isn't standardised itself you have even more systems. That is one reason why complex groups use consolidation systems.

I'm guessing your company is somewhat more homogeneous than us conglomerates?

Edit: no it is not an ERP problem. It is a people problem. The team simply can't scope out the new factories quickly enough before the business changes something. Often the newly acquired factory has a different costing method for instance, and lots of data has to be collected before they can go on the master ERP. This may involve, for instance, timing every products build, collating and verifying it (in Excel probably), before the implementation can progress. This can take months. Especially when.... three main priority is selling stuff, rather than having neat BI

At the end of the day, everything is a people problem. I tried checking the other comment but I couldn't find it (I thought I replied to it actually but it seems it was a different one about non-integrated ERPs).

We are not a conglomerate of 10+ nation size (slightly below that; also not the best measure but trying to toe the line with sharing but not naming gets harder with detail) but I suppose since we had to pivot from financial services to CPG a while ago and B2C retail in our segment at that time really demanded extremely low lag&lead-times for user changes and onboarding of products and services (well, VAS.. but who's counting), we engineered our way out of it, including logistics, SCADA, web, mobile apps, people-onboarding and M&A onboarding.

Having neat BI is more a side-effect than a primary goal. That goal came much later since it was the last remaining driver of shadow processes as it lead to many opportunities of bad engineering, even if it was seen as valuable in the short term (it never was worth it in the long run). It wasn't even about spreadsheets (or excel specifically), it became a real-time streaming issue where you couldn't have a fully manual process in the loop any more and we couldn't hire extra people fast enough to keep the existing processes running at the rate we needed. We don't have data entry positions anymore for the same reason; it's not that we don't receive new data, it's just that we had all B2B contacts agree that they will not send or receive files between humans if it's regarding an automated streaming process.

Having our data architecture being based on real time streaming (and some periodic sanity checks and shadow reconciliation as that is mandated by some record keeping laws) means we beat practically everyone in the same market segment on speed and delivery.

But perhaps this ties in to us being more homogeneous than some other conglomerates. We're not doing more than 5 countries and don't have our acquisitions result in extra divisions as we tend to aim for competitors in the segments we want to grow in (we want the data, the people and the customers, not the systems). This means that the people that operate the business (be it the business processes or the actual product processes) don't really get 'extra' software as a result.