Those feelings are nice, but Excel in most context is just a liability. The intersection where a spreadsheet is the right tool for the job, and the job is performed by someone who doesn't have many options is pretty small.
In business cases, the risk with home grown spreadsheet 'workflows' is pretty big, and in home usage cases you don't really need more than just a basic spreadsheet. The intersection is perhaps where you have some offline data, cannot write a program as fast as you can use a spreadsheet and there is no risk associated with taking the data and workflow out of a guarded environment.
The same can be said for things like word processing, when you need a book or a paper, you might be in need of typesetting rather than a program that tries to do everything but at a level a novice can use it. You're not going to get a paper or an offset printed book from a text editor. Perhaps if you self-publish a PDF that doesn't need to meet any requirements you can get away with an all-in-one DIY solution. But the time period where that was relevant (around the late 90's) has come and gone.
Let's not stop there, the same can be applied to someone doing some Apps Script, Python notebooks or other solo yolo work, because it felt faster or more productive to them. Surprise! Your cowboy behaviour doesn't actually work at scale, doesn't fit in a shared system and doesn't work in production. But you wanted to be quick and 'get it done'. Instead you waste your own time and everyone else's time, and didn't deliver something that works. (at work; and that includes "but I have done it this way for 1000 years! - doing it wrong a lot doesn't make it less wrong)
But say you want to do some budgeting at home, and all you need is some boxes to type numbers in, then yes, why not use a spreadsheet. But that's not what people celebrate. People celebrate running a company with 100's of jobs on a single spreadsheet, and probably only because it hasn't gone horribly wrong yet. And then there's the real bad scenario, a specialised system (say, an ERP or PIM or CMS) where you pull the data out, do the thing in excel because you didn't want to learn how to use the system and you happen to have written some lists of numbers in excel once and therefore it is now your universal hammer. Good for you, bad for your department or entire business unit because you just broke out of a shared workflow because you thought you knew better which tends to have universally bad consequences.
Excel specifically is an example of "they just don't know any better", just like the everything-is-a-nail example (where Excel is the hammer and every problem looks like a spreadsheet). You could replace Excel with something else and it would still be the same problem (i.e. replacing Excel with Word in scenarios where people want to send someone an image that is on their clipboard - they know they can paste it in Word, so that is what they do and you on the receiving end get a grainy compressed image in a word document). It's not that the sending and receiving didn't work at all, or that the software or the people are bad, it's just a really shitty "solution" that shouldn't be glorified and be seen as the failure to educate that it is.
You can enjoy it as much as you want on your own time. That doesn't make it the great universal fit you think it is.
I think you misunderstand 'workflows' in business. This is not a case of ingesting a large amount of data, transform, analyse etc.
A normal finance team gets constant one off requests for information. Download something from the ERP, lookup against something else, pivot it by department. Then you get a follow up for the same but with x excluded, but they need it in 10 minutes before a meeting. Excel is great for that.
Then there are the dozens of files behind accounting records. Take a Fixed Asset Register (since it is at the top of the balance sheet), a list of your assets and their depreciation schedule. Maybe your ERP doesn't have one, or your company didn't buy that module, or you have a special class off asset that doesn't fit in it. Maybe they coded it for one country, but in your country the rules are different, so it ends up in Excel.
Then maybe you have a bank account and you have cheques that are posted to your ledger but have not cleared the actual bank yet. Then you have items on your real account that you couldn't post yet, maybe someone paid you with no reference. So you keep a little Excel reconciliation to check.
Then inventory, maybe the ERP didn't split it in the way your consolidation needs it, so you transform the data in Excel and reconcile it back
Then you have all the things that belong in this accounting period but haven't been billed yet, so you have a running list of accruals and when they will reverse. Then you have all the things that are posted in this period but relate to later periods, so you keep a prepayments file. Maybe both of these spit out a journal to upload back to the ERP and reconcile the balance.
Then you get a download of the payroll for the month, but you need to rearrange it into net pay, gross pay, taxes paid by the employee, taxes paid by the employer, pension contributions... then you have to split it by cost centre too. This could be coded, but it is different in every country... and the cost centres keep changing, and the analysis head office wants keeps changing... so it goes in Excel.
Then I want to verify that the system posted the correct absorption to inventory, so I paste in an inventory report and a TB and last month's reconciliation updates.
I can code, but I can't maintain 100 pieces of software that change all the time. I also need all the people in the chain to be able to follow it....
And yes, finance people know how to apply the famous 'checks and balances' to keep out most classes of mistakes....and to detect the same mistakes made by the engineered 'proper software' we have to work with.
I doubt I misunderstand it since this is what I get paid for. I'm also not suggesting this is a case of large data, ETL or anything like that. (what I'm writing about is people using it for that anyway which is what we have other systems for and they should not be doing that)
Our finance teams use excel too, but not as the 'do everything' tool that the article and plenty of comments here makes it out to be. They use it as a scratchpad, and it works well. But it doesn't contain ground truth, ever.
This one perhaps matches with 99% of the rant I wrote:
> Then inventory, maybe the ERP didn't split it in the way your consolidation needs it, so you transform the data in Excel and reconcile it back
While we primarily deal with Dynamics (AX and 365), pretty much everything fits in there. In some cases the clunky UI makes it slow to do some transformations, even if just to check something to (as you wrote, verify the software did what it was supposed to do), and then you dump a couple of thousand rows out, do your work, and either are happy with what was verified or load some transformed data back in (this hasn't really been needed as we revised our rules as to data locations a few years ago, not in terms of "do this or you get fired" but in terms of "please make sure that when external systems outside of your team streams data in or out of the ERP, the chance of it not being correct is as low as you can get it").
As I wrote in some other reply (which some people appear to disagree with as if it's something I made up), my issue is with the horror cases of people building their own mini-ERP in a set of excel workbooks, or not using shared systems for data sharing and governance but instead emailing files around. Maybe it's the little learning being a dangerous thing, or feeling confident in a tool also giving people false confidence to perform actions that really should not be done that way.
> While we primarily deal with Dynamics (AX and 365), pretty much everything fits in there
I don't have much experience with Dynamics. My experience is mostly Oracle, SAP and Netsuite plus some bespoke.
I agree modern systems are very flexible. Everything could fit in there eventually if you are willing to pay, and willing to wait. But reporting can't wait.
The company I work for has 1000 factories, many sales offices. They use many different ERPs. I heard our division has 23! We were all acquired at different times,
. My unit was acquired by a group that subsequently sold a part of itself. They are constantly trying to standardise on one system, but then acquire something else with more different systems. We get around this by using a consolidation system. Export, transform, load of only top line metrics..All via Excel, which is fully integrated into the consolidation system. The consolidation doesn't preserve line level data, so if someone needs it they have to ask for a spreadsheet. The IT just never catches up with the business.
The last mega Corp I worked for was simpler and more standardised, but still used different ERPs in different divisions. We were acquired by a group that was acquired by mega Corp, because they wanted a product a different division made. We were shoehorned in. We were on SAP already, but had to move to theirs...took 18 months to get to us. In the mean time...we used a consolidation system... via Excel
We also consolidated from multiple systems but we never had that many in parallel, we always were finished in time before adding/splitting the next set.
The previous setup was all SAP, but that was too slow and we couldn't get the change rate we wanted. That was over 10 years ago, and AX had different issues but at least nothing the end-users have to deal with.
Besides AX and 365 we have 3 more, as well as some legacy processes still using MSBI, but all of the data going in and data going out is captured (either in Databricks or in our integration systems) which means that reporting and things like invoicing, banking, purchasing etc doesn't really care much about the underlying ERP. The ERP core team of course does, but the days where most of the work was serving direct business day-to-day needs are long gone, it's mostly edge cases and keeping the ERP in line with business changes.
All the metrics are processed in spark and exposed to both Tableau (together with an SQL Warehouse that lets you access all the individual data as well), and Thanos. So if a technical team wants to do some deeper analysis side-by-side with technical data that's possible too (which is great since they tend to be more comfortable with that vs. tableau). It's pretty nice to have financial data, WSSI data, GTM data and service deployment data overlaid so you can see the direct impact of everything on everything. (even if the resolution for some data is not the same - zoom out enough and you get very actionable insights)
Perhaps one of the differences is what we are mainly in retail, warehousing and logistics, when we buy a product or services business we tend to ditch everything except the data and the people. Our data engineering team takes care of the capture and transformation and the respective specialised process teams (CRM, ERP, PIM, fulfilment etc) coordinate from the business, legal and operational perspective. There will be a cutoff date and depending on the size we'll either have had a realtime streaming period (CDC style mainly) or do a one-off snapshot of the business and do it in one go.
For our business users it means they won't need to go to a secondary system to get the 'other' data; instead, the data comes to them.
I'm not sure why this method has not failed yet, I suspect it's because some M&A strategy components outline the cost/benefit clear enough to not have us integrate something that is not integrate-able.
>Perhaps one of the differences is what we are mainly in retail, warehousing and logistics
You nailed it. At a previous firm (when I was in charge of ERP as well) we took over these kind of firms and moved them into our ERP either immediately or after a few weeks.
Manufacturing is orders of magnitude more complex. BOMS, Routings, all the raw and intermediate level skus, interfacing with the shop floor equipment. The much more complex accounts, many more people to train in more specialisms. MRP is so much more complex, planning is more complex.
Then with our 1000s of business units... the Politics is so much more complex too
Excel is king of cancer that you’ll implore to cut out once you realize it slowly kills your business. A perfect trap for novice entrepreneurs.
30% of my jobs when I was in integration was unfucking folders of folders of irregular xls built by users, and sometimes we just failed due to the sheer amount of crap which was in motion and had to be transitioned atomically. It never worked first and second time, so we had to do waves of complex transitions with parallel accounting (double workload on an already suffocating business), until things failed rarely enough to be scheduled as regular bug fixing tasks.
I don’t think it’s fixable. Excel enables chaotic “development” and it just happens. In the end we either left them with a system they ordered or bailed out cause it wasn’t worth it.
Edit: to clear misunderstandings, I didn’t fix their spreadsheets. I extracted knowledge and processes from there and from users and built a new system after discussing how it all and their ideas check together.
And I'd bet that after you left, your system was ignored or fell apart while those "chaotic" employees with their spreadsheets just kept chugging along fine.
a) because you yourself wrote "sometimes we just failed" and "I don't think it's fixable", and
b) because in many years of corporate experience, the vast majority of systems built with the intention of replacing Excel processes fail to achieve that goal.
It is true that knowledge workers are often disorganized and messy - in large part, because actual business is also messy and changes very quickly. When you start with the attitude of "unfucking" and "sheer amount of crap", it's obvious that you actually aren't respectful and aware of the actual day-to-day demands of business, their bosses, presentation requirements, messy input sources, etc. Pure, testable code may be more elegant but it simply is not as flexible and UI-friendly as Excel, which is a large part of why these types of projects fail at such a high rate.
I am not respectful of excel at all, true. I could see your perspective, if it wasn’t a client who comes by itself(!) begging to do something with their spreadsheets cause key roles spend all day maintaining these, blocking further growth or mergers. Maybe I should not have called it crap out if respect to a client, but that’s what it was from the design pov, no reason to spare a word. I didn’t like it cause no one likes to dig in such sort of legacy. You treat the failure rate as an excel good indicator, well that may seem true until you get yet another call for help. It’s a failure rate of excel. I agree that we should have just bailed out by default and left them to sales sharks. At some point that’s what I did basically, said no to yet another “project”, cause these were crappy low hanging fruits that no one else wanted to deal with, not interesting jobs. Idk how it all assembles into “excel good” in some minds. As if companies just called integrators out of boredom because everything they’ve built in excel works.
You're saying Excel failed, when the work was mostly getting done, if inefficiently.
You showed up, unburdened by Excel, and soon quit ("bailed out" -- your words) because the projects were "crappy", "not interesting", "no one wanted to deal with". Yea, boring, crappy projects are a big, but essential part of business!
Lets be clear, YOU failed. Processes built upon Excel are often messy and inefficient, that's well-established, but just like in this example, attempting to replicate the processes without using Excel often implodes entirely.
My success rate was around 2/3. That after I finished they returned to excel is your unfounded assumption (also demonstratively ignorant of what it takes).
Anyway, if you advise your clients to build on excel, I wish them luck, and wish you, when they fail to grow or simply sustain, to be successful in explaining them that it’s alright and integrators bad and they must just continue. Cause clearly this strategy works for you somehow. Make it work for them with the same energy as here and it’s done.
Which 'opinion' would that be. The one where I write about anecdotes from the real world?
We have software that does what is needed. An ERP, a CRM, a HMI, a case management system for legal etc. No need to have everyone on every team rebuild that in excel.
You make it sound like their job is development (it's not).
If your job is to manage legal cases, you have no business writing case management software. That includes writing it in excel.
The same goes for collaborating with 100 people outside of your team, they are not going to keep tracking your personal DIY projects, they work with a common infrastructure so it's actually feasible to work instead of being busy playing engineer all day.
Except without a way to get the computer to behave the way they want they have an arm strung behind their back in the modern economy.
EDIT: I think my experience could likely be in a situation very different to yours. Thinking about it more deeply I am describing an org up to its neck in tech debt and in a changing market where regulation is tighter than ever.
So, I think the pathologies are definitely more specific than universal.
>If your job is to manage legal cases, you have no business writing case management software. That includes writing it in excel.
So true, but not everybody runs a company like it was a business :\
You may have to turn over every rock, but you just might find some bureaucracy "occasionally".
If your job is to manage X cases which have traditionally been done without a computer, you have the greatest advantage if you can outperform your peers when they don't have a computer either.
If X case management software is then adopted, there will once again be a level playing field, the traditional leader maintains their traditional leadership as long as that is something that is effectively leveraged by the software.
Otherwise, less-naturally-outperforming leadership may prevail once software comes on the scene, and it could very well be impossible for the previously-leading professional to compare with a peer who is also capable of writing the software themselves. Especially when there is good commercial or open-source software already. That way the domain expert having the programming ability doesn't have to spend time programming, but the insight into procuring software and creating workflows can't be matched after a certain point. Just because they actually are capable of programming it themselves if they really had to.
> Excel specifically is an example of "they just don't know any better", just like the everything-is-a-nail example (where Excel is the hammer and every problem looks like a spreadsheet). ... It's not that the sending and receiving didn't work at all, or that the software or the people are bad, it's just a really shitty "solution" that shouldn't be glorified and be seen as the failure to educate that it is.
This is an elitist software engineer's take.
People building on Excel isn't a result of failure to educate, it's humans doing what humans do best—automating their own workload. It's people using general-purpose computers as general-purpose computers. It's the closest to the personal computing dream that we've come, and likely the closest we ever will.
The alternative in the real world isn't "everyone learns Python", it's "we lock normal business people out of computing and keep it in the hands of the trained and very expensive software engineers". That's not going to happen, and it's frankly not something we should want to happen.
I think this kind of Excel denigration comes up so often in software forums because we're usually called in to rescue a business when their Excel workflow gets completely unmanageable. We miss the decades that the company ran very successfully without any software engineers on the payroll and see the giant spaghetti mess that made them finally decide it was worth the cost. But it's important to remember that these same businesses reached the point where they could afford to pay us to build something custom by building a successful business on top of Excel.
> I think this kind of Excel denigration comes up so often in software forums because we're usually called in to rescue a business when their Excel workflow gets completely unmanageable.
I my uninformed opinion it is because SOP (spreadsheet oriented programming) is as different from other paradigms as Forth is from Java. Decades of tribal fights have sort of culminated in a vague "all Software Engineering is Software Engineering" where most people understand that there are benefits even in the paradigms/languages they do not like.
In another world Excel would be just another one of those paradigms/languages but in this world it did not partecipate in the "Sotware Civil Wars" and so it was left out of the respectability plateau.
In short it is not that excel is bad but rather that the cultural link between it and what we usually call programming is very weak
No it isn't. This is MY take and I'm not an elitist software engineer.
> People building on Excel isn't a result of failure to educate, it's humans doing what humans do best—automating their own workload.
No, it isn't. It is human behaviour alright, but it's cutting corners because it feels better to do what you already know instead of doing what was instructed. This is what we see in businesses from 100 to 1000 people happening time after time.
Example: if you need to visualise your data from multiple sources company-wide, we'd have Tableau (and training, access, templates, portals etc) for example. That means you do it there as per instruction, and you don't go trying to setup some home-brew graph in excel that you manually regenerate every day and forget to generate when you are on vacation.
> It's people using general-purpose computers as general-purpose computers. It's the closest to the personal computing dream that we've come, and likely the closest we ever will.
Sure, do whatever you want at home, no discussion there. But since I already specifically wrote that, I suppose we don't need to keep repeating that.
> The alternative in the real world isn't "everyone learns Python", it's "we lock normal business people out of computing and keep it in the hands of the trained and very expensive software engineers".
No, it's not. The alternative is follow the workflows your teams and BUs have established and don't go off on your own. It works, it's proven, it's highly effective and attracts talent as a bonus.
> That's not going to happen, and it's frankly not something we should want to happen.
Maybe not where you are, but it's definitely happening here. And we want it to happen because the amount of data and the types of data don't work with excel. And the way people have tried to work around it by doing sampling and then saying "but it works on my machine" when it inevitably fails is a waste of time.
> I think this kind of Excel denigration comes up so often in software forums because we're usually called in to rescue a business when their Excel workflow gets completely unmanageable.
Perhaps, but what I wrote isn't Excel denigration, or denigration in general, it's real world scenarios where Excel wasn't the solution and people found out too late because they didn't know any better and they thought they were doing the right thing. Heck, replace excel with spreadsheet or 'workstation-based' and you have the same issue.
> We miss the decades that the company ran very successfully without any software engineers on the payroll and see the giant spaghetti mess that made them finally decide it was worth the cost.
You must have forgotten mainframes along the way, that's where the actual money was made, not spreadsheets. And if you create a 'spaghetti mess', that is something you can do perfectly fine with Excel, Access or just plain pen and paper. Creating a mess is at the core of end-user deficiencies when it comes to using a spreadsheet for non-spreadsheet problems.
> But it's important to remember that these same businesses reached the point where they could afford to pay us to build something custom by building a successful business on top of Excel.
No, it's not. It's important to remember that older software was written to emulate the physical world, but that was also what created boundaries and limitations. Desktops, folders, spreadsheets, word processors, rolodexes, telephones, paper mail etc. are not the 'best' solution, it just happened to be what was used when software was written. The software emulated the processes that existed to make it easier to understand what it means and how to use it for the people of that era. Practically everything has evolved beyond that, to the point where you have to educate new hires on what a file and folder structure is about if you're using those at work. Just like you have to educate older people that the way they used to do things is no longer how we do it today.
In some ways, Excel is the COBOL of our generation. And that is not a good thing.
>Example: if you need to visualise your data from multiple sources company-wide, we'd have Tableau (and training, access, templates, portals etc) for example. That means you do it there as per instruction, and you don't go trying to setup some home-brew graph in excel that you manually regenerate every day and forget to generate when you are on vacation.
Then your CFO calls up and says, 'I have a meeting in 30 minutes, can you tell me the total cost of pensions for people who work out of the Singapore office on sales admin' and the BI developer never pulled the measures through for that, because nobody asked for it before... so you export it to Excel, do an xlookup, a sumif and a filter and keep your job...or put a request into IT to have it added, wait 3 weeks, and get fired.
In the real world there are measures repeated week after week, and there are many more ad-hoc requests. Your mental model of the information required to run a business is way off.
Exactly. When a process is important enough and repeated often enough, it will move into a more formal system. But most of the time spent running a business is at the fringes of what has been automated and formalized, and this isn't an accident—the automated processes are there precisely because they reduce or eliminate the human time. That means most of the humans (outside of front-line customer support or similar) tend to be working on stuff that is substantially less well-defined than what OP is imagining.
Which again gets to my point about the weird perspective on business that we have as software developers. We're called in exclusively to work on those parts of the business that are deemed sufficiently repetitive to be worth automating. That dramatically skews our perception of what running the business should look like.
That's great, but has little to do with the 'excel is my hammer, therefore everything is an excel-shaped nail' problem.
Sure, like I wrote (twice already), you might need to have some malleable rows in front of you on your local workstation for some ephemeral work. But the actual workflow happens in the ERP system. Or the CRM. Or the PIM system. Or in Tableau. Or Databricks. And my beef is with people who think their personal flavour of alternate software should bypass that, even when they have been explicitly told not to. When someone needs to stream the truth (data-wise), that comes out of those systems, not some kludgy sheet on someone's network share. Those are the rules that we set up.
I don't understand why this is so difficult for everyone to understand (on HN of all places). These are general staff functions we practically have entire schools for, to make people work this way.
I love that you mentioned PIM systems. I've worked with product information systems from small 3-man companies all the way to Fortune 500 companies, and without exception, their PIM systems have been total dogshit: slow, extremely unintuitive, limited in functionality and borderline unusable. When I need a list of product names, barcodes, weight and dimensions, nothing beats a simple Excel table that can be quickly transformed into whatever format I need at the moment. With the intensity of a thousand suns, I hate the "workflows" of having to create an account, sign in, browse products, put them into a cart, submit an order, and then wait for an email with a download link to some non-standard XML dump or broken CSV that their multi-million dollar PIM system produces. These systems have wasted entire lifetimes worth of their users' time. When it comes to sharing product information, nothing beats the ease of use and flexibility of a plain Excel table.
Our live PIM database is over 2TB, we're not going to copy that to excel. On top of that, we're also not going to have everyone do a little bit of PIM here and there, we stream 80 to 90 PIM mutations per second across various systems. You get a PIM frontend with appropriate access and that's it. Technically, the only real PIM work the teams do is corrections, there is practically no manual entry.
Luckily for us, we put request-response time in the requirements documents, so our PIM users get sub-50ms responses for everything.
As for sharing data, our manufacturers and subcontractors use APIs (with the exception of some wanting JSON uploads via SFTP), most of them stream directly into their PIM or ERP (yes, some don't have dedicated PIM systems and just use their ERP for that).
Even if we could have the data flow through individual workstations, we'd still not do that as we don't want to legal and repetitional risk associated with that, especially since it is completely avoidable.
As written in a different reply, sometimes people want to do some local fiddling around and they will export some data. But that data is considered expired, and not part of the normal data flow. Which was my point: spreadsheets are never part of the main loop. And anyone who wants to build a system where it is, is not working for us.
I do notice a trend here, lots of people having bad systems (slow PIM, outdated ERP, missing CRM), which is probably something that should be fixed, rather than taking the shadow route. Escaping to a spreadsheet is just that: escaping.
Our PIM team disagrees with that take. They enjoy the PIM interface and Excel doesn't come close to the data hierarchy and relationships our systems provide. And that includes reporting, vendor exchange and internal integrations.
But perhaps you're missing the point here (like plenty of others): it is not about handling a few offline rows, it's about re-inventing established systems that have proven their value and risk mitigations. We don't want someone to setup a collection files to build a homebrew PIM or ERP or CRM because they feel like it, disconnecting themselves from the organisation and teams they work with. In most cases, single player data silos are bad.
No, they don't. Our finance teams, accounting, B&S, purchasing etc. also all disagree with your take.
There also is no "fireable offence" structure here, we aren't a US-company and we have strong labour protections here. They themselves chose how they want their processes to work, and none of them ended up with Excel in the main process loop, anywhere.
Perhaps this is something you cannot imagine, but over here, this has been the standard for years. And it pays dividends.
This does not mean excel doesn't exist or isn't used outside of the main processes/loops/flows. But that is what I wrote in my first comment here, which people seem to skip over.
In the real world (which is where my example comes from) the CFO expects it in Tableau, all day, every day and isn't going to waste time on the phone with some random people who were assigned to put it in tableau. Perhaps you don't like this example, but that doesn't make it less real.
Ok. My real world counterpoint. I work for a CFO at a multinational. A really big one. I have been the finance lead at a multinational myself, a smaller one.
Our business changes so rapidly that we are forever adding business units, acquiring, divesting, resizing. The ERP people are years behind us all of the time.
What should we do in the mean time with our new group of companies we just acquired? Wait for the IT people?
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.
In business cases, the risk with home grown spreadsheet 'workflows' is pretty big, and in home usage cases you don't really need more than just a basic spreadsheet. The intersection is perhaps where you have some offline data, cannot write a program as fast as you can use a spreadsheet and there is no risk associated with taking the data and workflow out of a guarded environment.
The same can be said for things like word processing, when you need a book or a paper, you might be in need of typesetting rather than a program that tries to do everything but at a level a novice can use it. You're not going to get a paper or an offset printed book from a text editor. Perhaps if you self-publish a PDF that doesn't need to meet any requirements you can get away with an all-in-one DIY solution. But the time period where that was relevant (around the late 90's) has come and gone.
Let's not stop there, the same can be applied to someone doing some Apps Script, Python notebooks or other solo yolo work, because it felt faster or more productive to them. Surprise! Your cowboy behaviour doesn't actually work at scale, doesn't fit in a shared system and doesn't work in production. But you wanted to be quick and 'get it done'. Instead you waste your own time and everyone else's time, and didn't deliver something that works. (at work; and that includes "but I have done it this way for 1000 years! - doing it wrong a lot doesn't make it less wrong)
But say you want to do some budgeting at home, and all you need is some boxes to type numbers in, then yes, why not use a spreadsheet. But that's not what people celebrate. People celebrate running a company with 100's of jobs on a single spreadsheet, and probably only because it hasn't gone horribly wrong yet. And then there's the real bad scenario, a specialised system (say, an ERP or PIM or CMS) where you pull the data out, do the thing in excel because you didn't want to learn how to use the system and you happen to have written some lists of numbers in excel once and therefore it is now your universal hammer. Good for you, bad for your department or entire business unit because you just broke out of a shared workflow because you thought you knew better which tends to have universally bad consequences.
Excel specifically is an example of "they just don't know any better", just like the everything-is-a-nail example (where Excel is the hammer and every problem looks like a spreadsheet). You could replace Excel with something else and it would still be the same problem (i.e. replacing Excel with Word in scenarios where people want to send someone an image that is on their clipboard - they know they can paste it in Word, so that is what they do and you on the receiving end get a grainy compressed image in a word document). It's not that the sending and receiving didn't work at all, or that the software or the people are bad, it's just a really shitty "solution" that shouldn't be glorified and be seen as the failure to educate that it is.
You can enjoy it as much as you want on your own time. That doesn't make it the great universal fit you think it is.