Hacker News Reader

Comment by tempaway64457 | Hacker News Reader

So actually top level planning/reporting is done by everything flowing into one big spreadsheet - as crappy as that is, thats pretty common. Thats not the same as "managed finances with single Excel spreadsheet". Like, they do have other systems.

View on HN

25 years ago a small Norwegian company in oil industri replaced a big Excel that it were using to manage its inventory with Access database and discovered that they have like extra 200K USD in equipment.

The reason for the saving was enforcement of constrains in various Access tables so a subtle entry error in Excel was discovered.

The transition to DB file was done by a single person in a month who had not worked previously with DB (however he was young and talented programmer I must admit).

And the Access DB in a single file with its UI was quite similar to Excel so guys maintaining it quickly learned it and really liked it.

So it is still puzzles me why such single file DB with nice UI are not more popular? Why it is always Excel?

Someone builds an access database and it works for a bit but then they leave and no-one else knows how it works so they start exporting the data to excel instead. Access is all about restrictions (the form has these fields; the data is structured like so; input will be validated by these rules) ... Restrictions deliver some value but are brittle - its about as hard to maintain as any other custom built app would be.

Access was much easier to get started with than any other similarly capable database product, last time I checked in 2017.

Its easy to get started, but modifying one made by someone else? You've got to really think like a programmer.

as an anecdote, my own mother, who studied french in university and works in education, has built access DBs for places she's worked before. It seems its a very approachable and beginner friendly UI for non-programmers, somehow.

Because Microsoft decided to kill/neglect access and Visual Basic... for reasons?

> why such single file DB with nice UI are not more popular?

Because it needs skills that often aren't immediately available whereas a lot of people have enough Excel experience to lash up even a moderately complex spreadsheet.

At many places there's also some nasty politics around siloing where a database is an IT System so it has to be owned by the centralized IT organization, operated by a DBA team, have a budget, be audited by security, etc. and half of those groups look down on Access and want to architect for job security by picking some Oracle/SAP product where even if you have an unlimited budget you are looking at years of guaranteed delay before you can use it with a significant risk of failure.

In a fair number of places that I've worked the finance and IT departments have a fairly substantial level of enmity which also discourages use of anything which involves them. Meanwhile, everyone still needs to do their jobs and there's a business analyst with decent Excel chops who will have something you can use “temporarily”. A few years pass, then a few more, and now everything lives in Excel as the calcified scar tissue of broken official processes…

> At many places there's also some nasty politics around siloing where a database is an IT System so it has to be owned by the centralized IT organization, operated by a DBA team, have a budget, be audited by security, etc. and half of those groups look down on Access and want to architect for job security by picking some Oracle/SAP product where even if you have an unlimited budget you are looking at years of guaranteed delay before you can use it with a significant risk of failure.

A space seemingly ripe for Line Of Business Applications As A Service: LOBAAAS :-)

TBH, the whole SaaS took off because of the ability for individual departments to just get their resources using nothing but a company credit card.

Excel is really easy to use for smaller data collection and manipulation. There's no input validation, signing and other complicated design decisions needed to start an excel spreadsheet. There's alot of tools out there for easy integration. So its not something you need to switch away from once you have rather static requirements. Billions are just numbers that fit inside a cell just fine until someone complains.

And then once you need actual calling Access lags far behind even MySQL.

FWIW, having a human regularly count the equipment would have also uncovered the error. As well as other interesting reasons that discrepancies arise, such as theft. Always important remember that these systems are tools, not the truth, and have to be reconciled to the truth on a regular basis.

Simple counting would not uncover the error. The company was required by support contracts to have some equipment in store in case of failures to quickly replace what failed. And the error was related to not updating in one Excel sheet information that a particular long-term contract was replaced with different one requiring less equipment on storage after updating another sheet. The Access DB with the support of enforcing complex cross-table constrains detected that.

> The transition to DB file was done by a single person in a month

If Deloitte is going to do this it will take 3 years, take about 20 people and cost tens of millions.

To be fair, you can define value constraints in Excel as well.

Yea exactly my take. This seems like exactly what Excel is good at doing.

You are mistaking "being commonly used for this task" with "good at doing"

Replacing this excel sheet with a 'proper' system would cost between $5million and $20million probably, depending on what sort of consultancy delivered it

And would be inflexible, and maybe still wrong, and not necessarily more transparent... So it may mean several extra million dollars per year in ongoing maintenance if things turn out typically...

Excel has many issues, but the cost of replacing it is surprisingly high.

>And would be inflexible, and maybe still wrong, and not necessarily more transparent...

I'm going through this right now. Not anywhere in this scale, but just in terms of deciding whether to move an order-tracking/accounting system I've built in Excel to a "real" database.

The database I am considering (Panorama X for Mac) is quite inexpensive, I've heard very good things about it, and has a spreadsheet-like UI. However, I've used Excel enough to know that I haven't tapped more than a small fraction of its ability, especially things like Power Query. As much as I loathe VBA, what if the cost of moving to a "real" database isn't the up-front cost, but the longer-term inflexibility of Panorama (and, pretty much, anything else in my price range) compared to the beast that is Excel?

Probably why the consultancy who produced the report referenced here was delighted to point it out.

Anything commonly used for a task it’s good enough for that task even if “much better” options exist.

Nail guns have a lot of downsides vs using screws, but being much faster and cheap offsets quite a lot.

Just bad enough

Excel isn't 'good' at anything. It is passable at a great many things.

Quantity has a quality all its own.

It really does.

Just the massive, massive ecosystem of online tutorials and answers and YouTube videos for every conceivable question [1] is incomparable.

[1] Except the one you want the answer to at a given moment, amirite fellas?

>[1] Except the one you want the answer to at a given moment, amirite fellas?

Everytime I relearn how to do a vlookup, none of the examples online do what I want. It's like they are trying to do something completely opposite of what I want. It's super weird, because what I want to do is always a pretty common thing to need done.

Never use vlookup . Always use match/index.

>Always use match/index.

I'm not sure how that'd help in any of the cases where I use vlookup.

Sounds like a certain LLM I've read about

>So actually top level planning/reporting is done by everything flowing into one big spreadsheet - as crappy as that is, thats pretty common.

Yeah, everywhere I've worked that's common, even when the underlying data is managed much more successfully, the top folks really want everything on a spreadsheet.

> This spreadsheet was the primary data file

>> - as crappy as that is, thats pretty common.

No. This is not a common practice. An Accounting / ERP system with full audit trails and data entry compliance is. Exporting data from such a system into Excel for analysis is. But Excel as the [re-reads] Primary data file is not a practice at all.

I've worked on dozens of Excel to ERP migrations. Excel is way more common as the primary data source including financial data. If you only look at financial data by volume (and not count) maybe ERP win, but I wouldn't be sure.

> and was used for “consolidation, journals, business-critical reporting, and analysis.”

Not sure what 'journals' is supposed to mean here but “consolidation, business-critical reporting, and analysis.” does not mean operations day to day use, it means high level management reporting

My position is that the article (or the consultants who are trying to sell the ERP) are exaggerating the role of the spreadsheet.

In accounting, a "journal" is a chronological record of financial transactions.

Ok going back to the report

https://www.tewhatuora.govt.nz/assets/Uploads/HNZ-Financial-...

The phrase “consolidation, journals, business-critical reporting, and analysis.” is in the actual report referring to multiple spreadsheets (p60). But the Register has reported that as referring to the main spreadsheet. There's no way a top-level consolidated spreadsheet would also be journal entries for low level accounting.

And I note the report is by Deloitte who I trust about as far as I can throw them, although the organisation in question undoubtedly messed up here, Deloitte are angling for a nice juicy government ERP implenmentation lasting years and costing tens of millions

Ok yeah that’s a good point! Probably not an accounting journal then.

"primary", I hope as a commenter out here you understand what that means.

Reply on news.ycombinator.com