"It blew my mind how many business critical processes were managed with excel spreadsheets being shared via email chains." - this also blows my mind, given how many problems there are with Excel (e.g. formatting).
That being said, if it works, it works.
If it doesn't work, make a case for why and develop a _holistic_ understanding of the costs and benefits of changing the current process. Maybe you can change it, or maybe you learn why it doesn't change.
If it works, but it offends your sensibilities, perhaps this is an opportunity for self-growth.
Version - date changed - who edited.
Add in the universal flexibility (both function and who can use it).
You can hand an excel file off to admin temp staff all the way to the top 3 folks in the org in one file and they can all interact with it successfully in most cases.
This makes this very powerful.
I don't work with spreadsheets much but I completely understand why they're loved so much. They're data, code, presentation, versioning, etc. all in one file that has _very_ good support.
Excel is for the people who want to actually get stuff done and find all tooling a distraction from what actually adds value to the company.
Same with google. Paid plans you can make sure a copy of all sent messages is kept, set retention rules etc. So if folks use email for all their approval / business flows that can be helpful (ie, some orgs CEO might send an email say I approve - go ahead and sign it on big deals rather than shuffling paper or doing a proper e-signature. If so, you might want to keep an archive org level of your email flows
I get what you mean but...
The email thing happens because that's how people who use Excel handle versioning. They'll end up with nested folders of emailed spreadsheets they can refer to or import into their personal approach. This works well for them, especially since they might work offline frequently.
So you mean Excel 365, not desktop Excel?
I've had to learn this lesson. We have an internal microservice whose name is obsolete and no longer makes any sense whatsoever. Everyone is confused by the name until the original reasoning is explained, and they come to understand the original purpose of the service, now long since changed. It drives me up the wall.
I have time and time again made a case for renaming it to accurately represent its modern purpose, which would take an engineer about a week of work - there's a lot of code and config that has to be switched over.
The person running my division has shut me down on this over and over. It goes like this:
Manager: Why do you feel this is a priority?
Me: It confuses people and makes the code less self-explanatory.
Manager: How much time is this costing engineers?
Me: Well, about a minute every time I have to explain it to someone once a week.
Manager: And it would take a week to update? This doesn't seem like a good trade.
Me, mentally spluttering: But the name makes no sense!! It's the wrong name!! It's completely unrelated and has no meaning!
Manager: Do you think you can work with it anyway?
Me: sadly sighs.
I think the manager is right, as much as it offends my sensibilities.
I once named a function
findGreatestCommonDenominatorGCDOfFraction(numerator: int, denominator: int) -> int
Even so, the majority of programmers will have a tendency to react to this as emotionally wrong. Then they attempt to rationalize this explanation with some form of reasoning. Try to catch this in yourself as it could be happening Right now as you read this.
You feel it's wrong but not from the composition of logical explanations. The feeling of wrongness forms first than you try to search for facts to rationalize your feeling.
Let me be clear. There is nothing logically harmful with that name but most programmers feel there is. This type of OCD tendency accounts for about 50% requests in code reviews. Ultimately useless changes to satisfy some OCD tendency.
I do occasionally blow things in to Postgres for my own sanity, but it usually isn't worth it, and even when it is, data goes back out to other people in CSV.
As just one example, if your secops department uses Qualys (and they probably do), that forces your secops department to use it, which means everyone who has to interact with them does.
Everything about internal budgeting is a pile of spreadsheets that gets thrown around.
Hell, when I moved one of our data centers recently, that process with the new DC was all all Excel sheets, despite the fact that we have DCIMs on both ends.
There is just no escape.
excel via email might (unfortunately) very well be the more robust and reliable way to go here
SMEs are going to be way more likely to throw together a spreadsheet to accomplish some immediate goal than they are to sit down with an internal software project manager and spend hours educating them on the problem to be solved and writing "user stories"