Tackling the 'Excel Problem' in small businesses | Hacker News Reader

Tackling the 'Excel Problem' in small businesses

insightsquared.com

28 pointsmkmk22 comments

> In 2008, University of Hawai’i professor Raymond Panko published a summary of 13 field audits that checked spreadsheets used in ‘real-world’ environments. His analysis found that a whopping 88% of the spreadsheets had errors.

This isn't the entire crux of the authors reason to transition away from excel but this stat doesn't exactly seem that damning of excel.

What if the author audited custom written software used in ‘real-world’ environments, I'm pretty sure he'd find that 100% of programs have bugs in them:)

In this regard excel seems to be an improvement over custom written software.

I guess he was talking about logic mistakes, not bugs as in "under certains conditions this fails". Logic mistakes are really hard to find because they don't make Excel crash.

We're not producing custom written software for a single customer, rather cost-effective software product used across many many clients. So yes, as our bug queue will attest, our software is not perfect. Each report has had and will have bugs. But the number of defects each customer must find and resolve themselves is likely lower than alternative approaches.

First off have an upvote for trying to sovle a difficult problem...

> Each report has had and will have bugs. But the number of defects each customer must find and resolve themselves is likely lower than alternative approaches.

Sure, the down side is that the customer loses teh flexibility of a system(excel sheet) tailored to their own needs.

What you've described isn't the difference between excel and your one size fits all software, its the difference between each client writing their own vs buying off the shelf software.

I could replace excel with Oracle DB or custom reporting website or any other piece of software and the statements would still be equally true.

"Custom software provides flexibility over general software, the downside is that bug fixes are shared across general software and not custom built software."

'Excel' is a problem or a solution depending on the size of the business.

For SMB, it is an enabler and quickly gets things done.

For big businessess, "System of records", "single source truth","SOX", regulations, compliance etc don't mix well with Excel approaches.

-- http://www.infocaptor.com/bubble_viz/insightsquaredcom201302...

Exactly this. Sometimes you need to get something done quickly, and getting sign off for a "proper system" just takes too long, or there are too many budgetary constraints, or the dev team is working flat out on higher priority projects that means your will project will never likely see the light of day.

And sometimes you just need something which is much more flexible than what a pre-programmed computer churns out. It's the reason that so many bank still use Excel for financial modelling. They can change a few parameters and instantly see the output of the bottom line.

Totally agree with your second point, the trick is to get a proper system in place before the Excel gets too mammoth.

It sounds like using Excel correctly is as a prototyping tool or a means of doing one-offs. If that's the case, then Excel is to a proper business intelligence system as shell scripting is to a real programming language. Each has their place.

Yes, I think that's a good way of putting it. I think it's data manipulation and reporting capabilities are excellent. In previous jobs where I used to work with a lot of data it was often easier just to output to Excel to allow the teams to manipulate and create whatever reports they needed.

Indeed. As a product manager at the company authoring the post, I frequently prototype a new report in this manner.

This is why the business (intelligence/systems) analyst role was invented. If you have a business team that is making decisions based on data, you really need a dedicated person who is competent with databases, statistics, reporting, and visualization. Otherwise you will be doomed to drown in e-mails of Excel spreadsheets with manually copy-pasted data and broken formulas. This is how most businesses operate, and I'd go as far as to say it's a major reason why we have been in an economic recession.

I think SalesForce has the potential to be the new spreadsheet. I know this sounds curmudgeonly, but SF makes it so easy to change the system that you end up with the primary maintainers of SF being people who don't understand how to design a 'system', or how to structure a solution in a sustainable way.

I'd guess less than 1 in 10,000 companies have SF (probably more like 1 in 100,000) ... whereas I'd guess 1 in 10 companies have Excel. But yeah, who needs programmers, right?

I'd guess that 99 out of 100 companies have excel, it's built into MS office and every accountant and finance person uses it.

I am assuming that there is a reason that you are hiding the prices? I failed to find them anywhere on your site.

I am a bit curious about that as well. I am speculating that they are trying to price discriminate between various customers.

very perceptive. We are currently running a pricing experiment with our sales team. We operate with an inside sales model so not publishing the prices (currently) provides latitude for our sales team to run the experiment.

I understand this, but for better or worse, I can't have a serious conversation in my organization without pricing information. There is no, "Check this out, it's cool, should we consider it?" without an immediate, "But what does it cost?" Without having the answers to the latter, I can't even really initiate the conversation in any meaningful way. Am I expected to bookmark your site and repeatedly check back until the information I need is actually available?

A fair point and it is a cost associated to the experiment we're running.

If you have a sincere interest in the software, you can convert on one of our forms on the website and you'll hear from a sales person. You can get pricing relatively easily in that fashion.

Or you can go to the wayback machine: http://web.archive.org/web/20121017002050/http://www.insight...

Thanks for sharing. The way you are going about things currently I feel is the right course of action. As those prices stand in that link, if you do deliver what on what you promise, you looked to have been undervaluing your services.

Reminds me very much of what I refer to as the Microsoft Access problem.

Somebody with no database design background hacks out an app in Access, which works. Ten years later, the dude has long sinced left the company, you have a horrid, non-resilient and unmaintainable application, which nobody understands, but is utterly critical to the business.

It can get even worse, when Access applications connect to the enterprise database. I've seen pure horrors with such scenarios, ranging from queries that bog down the entire system up to ghost locks, which wouldn't go away without recycling the data server.

The problems are somewhat different, but the root cause is the same: Trying to scale something, which is clearly designed for the desktop, to enterprise level.

The article fails to explain in what use case does excel fail. It problem when people make sweeping generalizations blaming a product. Especially one like excel that works.

From what it looks like they're trying to provide "sales reports." It one thing to say that they can simplify and save time generating these reports.

Its any other thing entirely to blame excel. Human error is prevalent on every level, so unless you can completely remove human interaction from the process or do it for them, then you're still open to the same risks.

I wonder if you say that SDK was a mess (implying it isn't so any longer), what minimum Android version do you target?

[edit] this was a sincere question. I can elaborate on it a bit more. Based on the previous submission I reasoned OP is behind the blogpost. If not, my question doesn't make sense.

Why this question? Recently I have the experience, for Android, that developing in a 4.1 world while supporting at least 3.2 is a tricky thing (and since there's quite some version fragmentation on Android, this supporting at least 3.2 is still more than reasonable). For instance, you should/want to use Fragments, but 3.2 doesn't know them. Compatibility library helps of course, but there's gaps in it and if these gaps pose a problem, you're bound to write it yourself or revert to using deprecated code (and not leveraging the 4.1 benefits there). So, no disasters there, but still tradeoffs to be made and I simply wondered what tradeoff was made here (or what part I have been overlooking, of course :). [/edit]

Reply on news.ycombinator.com