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.
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.
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."
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.
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. :)
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.
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?).
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.
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.
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.
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)
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.
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.
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.
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.
Project tracking IS enterprise software kind of stuff. 37Signals does it very, very well. They make it look just another "small project", because that's what enterprise stuff should be like.
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.