

Tackling the 'Excel Problem' in small businesses - mkmk
http://www.insightsquared.com/2013/02/tackling-the-excel-problem/

======
chollida1
> 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.

~~~
joshuapayne
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.

~~~
chollida1
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."

------
njx
'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...](http://www.infocaptor.com/bubble_viz/insightsquaredcom201302tacklingtheexcelproblem.html)

~~~
kamjam
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.

~~~
witten
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.

~~~
kamjam
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.

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

------
jbattle
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.

~~~
ra
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?

~~~
johnrgrace
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.

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

~~~
joshuapayne
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.

~~~
binxbolling
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?

~~~
joshuapayne
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...](http://web.archive.org/web/20121017002050/http://www.insightsquared.com/pricing/)

~~~
dkroy
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.

------
CaptainZapp
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.

------
camz
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.

------
icoder
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]

