
Why Enterprise Software Sucks - luccastera
http://www.37signals.com/svn/posts/669-why-enterprise-software-sucks
======
edw519
I remember leading the test drive of a popular ERP system for one of my
enterprise clients. The salesman had never had a prospect force him into a
"test drive". My number one rule was "Nobody touches the keyboard except me."

As I entered an order, I asked, "How do I find my Customer Number?"

As I entered a part number, I asked, "How do I see how many are in stock?"

As I scheduled the order, I asked, "How do I see the current factory schedule
for this item?"

It drove the salesman nuts. He couldn't explain how to do anything without
grabbing the keyboard.

I asked, "What good is this system if I can't even enter one order?"

His response..."Are you going to train your people or not?"

That's pretty much their attitude. He was so upset with me, he went directly
to the CEO, who asked me what was wrong. I handed him one of our orders and
said, "If you can enter this order into that system, we oughta buy it." He
couldn't. We ended up buying another system that people could use.

The dinosaur is big, but it is dying. Hack on, and let the one who delivers
the value win.

------
DanielBMarkham
I think this is shallow and thin, although I agree part of the problem is that
the buyers are not the users.

The bigger problem is that the buyers have already spent god-knows how much
other money on dozens of software solutions that all were supposed to walk on
water. Now the poor schmuck writing some simple app has to take into account
leveraging all that other previous investment by the organization.

Ever buy Enterprise Software? Every vendor loads that stuff up with so much
junk that it's a wonder they can fit it all on a stack of DVDs. Most of them
can do everything but the laundry. And for each of those purchases, there's
some executive somewhere wondering "why aren't they just implementing that
software we bought last year?" -- it quickly becomes a political process where
nobody wins. It's not a simple users-aren't-the-buyers situation. Even if the
users were the buyers, you'd still have the same situation. EDIT FOR CLARITY:
That's because there is no single user with a single set of needs. Such
situations rarely exist. It's more complicated than that.

~~~
jkush
I think you are partially right as well. The deeper issue is that _because_
buyers aren't the users, makers of enterprise software have make stupid things
like feature comparison checklists.

Because buyers aren't the users, enterprise software companies must stuff in
every possible feature they can. We all know that more features != better
system.

We're still stuck with the question of why stupid things like comparison
charts exist though. It all comes down to accountability. Buyers need to have
something to cover their asses if the system doesn't work out. "See, look at
this comparison chart - I bought the best system out there. Just look how many
more features it has."

~~~
DanielBMarkham
Yes. These systems gravitate towards comparison charts and cost-per-seat
discussions, when they should gravitate towards ROI discussions. But ROI is
notoriously difficult to compute on large enterprise systems.

And let's not forget that even if you make the buyers the users, even a really
small number of users will have conflicting requests for features. You could
give everybody in the organization fifty bucks to spend. That would make the
buyers the users. But what would happen? Everybody would be happy that they'd
solved the 3 or 4 things that were most important to them in the simplest way
possible. The remaining situation would be lethal for the larger organization:
loss of reporting, command-and-control, re-use of data, standardized products
to train newcomers on, etc.

In the end, it's a choice. You can make "solve the simple problem" programs
and sell them to lots of users who will then create chaos in the organization
(because they fix only the perceived immediate needs of a subset of users) or
you create feature-rich, bloated software that does everything for everybody
and that's hard to use (and possibly impossible to adapt) but is attractive to
the larger organization. Companies have been making lots of money on both of
those options.

Put a different way: users in an organization have immediate, day-to-day needs
that only reflect a very small part of the greater needs of the organization.
So somebody has to compromise. There's no free lunch.

~~~
jkush
Or, you can get really good at convincing buyers that your simple-to-the-point
solution IS what they need. That's so much harder to do though.

~~~
DanielBMarkham
I think this is one of those big wars that will go on forever. You see great
products, like IM, making inroads into the Enterprise Software space. I think
you could make a great go at it selling simple software that does simple stuff
directly to the users, bypassing the CIO guys.

But that's not going to make you a lot of friends. :)

~~~
jkush
Bah. Friends are overrated anyway! :)

------
davidw
I guess "not being a big enterprise" is one answer to the enterprise problem
(one that I'm inclined to agree with), but it leaves me with nagging doubts.
Those companies most likely exist because in one way or the other, at that
size, they are the most efficient for whatever market they are in. If you
decide that software for those companies sucks, throwing up your hands and
walking the other way is one answer, but it doesn't really address the problem
in a meaningful way.

------
webwright
I think one of the big problems is that the buyers don't know how to buy
software. Users like new versions with long bullet lists of features-- and
they buy 'em.

On the plus side, if you actually create simple to-the-point software, your
users are probably a smarter breed of cat (read: less support costs?).

------
auferstehung
Enterprise software sucks because it is a hard, extremely complex problem
space. Enterprise software is hard in the same way that it is hard to create
and maintain an effective and useful quality system. Each individual
(successful) business is uniquely organized and operates in a manner peculiar
to itself. The unique qualities of a business is what gives it a competitive
advantage. A successful businees is not going to adapt its business practices
to some generalized, abstracted ERP system. To do so would risk the loss of
its competitive advantage. All the ERP systems I have seen suck at the ability
to be easily adapted to the unique and peculiar qualities of a specific
business. Many businesses spend a lot of money on services or consultants in
attempts to adapt general ERP systems to their business without much success.

I wonder if this dissonance between what businesses want from an ERP system
and the capabilites of ERP systems is due to programmers desire to elegantly
abstract and generalize software. Businesses want ERP software to be specific
to their business. Motorola, Nokia, GE, Sam's Muffler Shop do not want to be
generalized into MyAbstractBusinessClass.

~~~
jkush
>Enterprise software sucks because it is a hard, extremely complex problem
space.

I couldn't disagree more. I don't know how many enterprise systems I've worked
on that are _unnecessarily_ complex.

~~~
DanielBMarkham
Solving multiple, overlapping problems for thousands of users all over the
world is non-trivial. Pick any solution space, and I can give you a dozen
things you haven't thought about. 95% of them aren't important to one or
another subset of users, and probably actually get in the way of their work.
The problem is that the 95% of feature bloat isn't the same for all the users!

The trick is not to deny complexity or embrace it. The trick is to make
rational compromises. Start with something simple and add just enough bells
and whistles to get most of what's needed done. But that's a much more painful
and difficult process than just buying some big product off the shelf.

~~~
jkush
Great points. What I mean by unnecessarily complex is: I've seen to many
enterprise systems that are simply electronic versions of manual processes.

The problems that enterprise software system really try to solve are masked by
trying to genericize them for every situation and everyone. It still comes
down to solving one specific problem and solving it well.

~~~
DanielBMarkham
We are very close to agreement. There's hard work in picking the best and most
competitive business processes, and it's going to be different for every
organization.

That's why "project management software" isn't the same as "software to help
us plan and control building and deploying industrial power transformers in a
union environment where we have high governmental reporting obligations" or
some such. Companies either want to sell generic products with feature bloat
all over the place, or home-grown shops try to take fragile systems and glue
them together with more and more code. Either way you end up with a lot more
complexity than the organization needs.

But it still might not be a simple answer. And nobody wants to do the work of
figuring out what the minimum amount of complexity is for each situation.
(Even though there's probably more money in that than anything else)

------
umjames
As someone who still works in an IT department at a large company, I think
37signals has a valid point. It's not the only point (and there are many), but
it is a good one.

As much as most enterprise software sucks, it's at least 3 times as bad trying
to install or upgrade it.

Enterprise software companies know their customers have deep pockets, which is
what support contracts are all about. They purposely make the documentation
too confusing or too sparse so they can push the "value" of their yearly
support contract. Once you've bought the basic support contract, they tend not
to have many more answers than what you can get from the documentation. Of
course, you can buy higher levels of support where they'll send someone to be
onsite to work on your problems (which means even more money).

By this time, you've already spent so much time and your manager has spent so
much money on this stuff, that it's too embarrassing for your manager to admit
to his bosses that he's made a mistake and your stuck with the crappy
software.

------
hello_moto
People like 37signals and web designers should stop talking which software
sucks. Especially Enterprise software.

This group of people have no idea or whatsoever the requirements of an
enterprise software. All they know is how to create a beautiful websites. I'm
not saying that sarcastically, I like beautiful websites.

But this group of people judge the quality of the software from the UI
perspective; if UI == sucks then software sucks. They believe that a wonderful
UI == best quality software. That may be true but it's a wrong generalization.

Not to mention that web-designers and 37signals NEVER work on any enterprise
software. They simply work on small projects because it's their specialty.

~~~
rglullis
It is not about the UI. It is a matter of usability and _general_ design.

A friend of mine works in a company that develops airport traffic control
software. More than one time I heard him say how the features that are pumped
into the software are not features that are wanted by the users, but by
managers that are responsible for buying the software.

In telecommunications, where I have a little more experience, it is similar.
Things that we were supposed to work on are not the things that people
required. I spent a whole year on a team of 15 SDEs developing a bunch of
"features" that would never be seen or used, but that _had_ to be developed if
you want to have a Class-5 Phone Switch that complies with Brazilian
regulations.

~~~
akkartik
Useability suffers with scale. When the designer caters to the needs of many
it is hard to please everyone. But it's more than that: when he caters to the
needs of many it becomes less important to please any of them. Instead he can
focus on bureaucracies that 'represent' them.

Of course, when I refer to 'him' I am completely ignoring the tragedy of the
commons dragging down every any large-scale enterprise[1] over time.

Enterprise software is just an extreme example of these two phenomena.

[1] no pun intended.

