Infovark

Khoi Vinh very elegantly points out what’s wrong with enterprise software:

“Enterprise software, it can hardly be debated, is pretty bad stuff. The high-dollar applications that businesses use to run their internal operations … are some of the least friendly, most difficult systems ever committed to code.”

I don’t think that a truer word was ever spoken.

Jason Fried at 37 Signals chimes in with the notion that it’s because the buyers and the users are different people. I agree, but it’s more than having different user communities involved. Enterprise software is broken because of the way it is purchased. Having just come from the world of enterprise software, I know that most enterprise software is not designed to be used, it’s designed to be bought.

The sales cycle and sales model for enterprise software are among the most ridiculous ways I have ever seen anyone purchase anything, ever. Just to clarify, let’s try a Google experiment. I’m going to sneak over to Google right now, and search for some kind of RFT document (which is the primary purchasing vehicle for enterprise software.) Hang on…

Okay! A quick Google search for “RFT software solution filetype:doc” led me to this document detailing an enterprise software solution for the Irish Customs Service. Like most tenders, it’s a very long and very boring document. There are many, many, extraneous words in the interests of sounding official. Seasoned RFT response guys know that the real meat and potatoes of the document are usually buried at the very end in small print. In this case, it’s Appendix 9, the Requirements Response Table. It’s a giant table of things that the solution has to do. Let’s pick one of these things at random…

“Use the standard ITP Transaction Review (TR) workflow component to meet TR functionality. Please state how the solution will integrate with ITP TR, and what, if any, additional TR functionality is proposed, and how this will interface with existing ITP TR”

There are 128 requirements in this RFT just like this. What is the purpose of this requirement? What are the goals of the system? How will success be measured? There’s not a single comment anywhere in the document about usability, or how users might interact with the system.

It’s clear this RFT wasn’t written by or for users. (They don’t have purchasing authority.) Yet this is the primary buying document. In order to win the business, a vendor will need to answer every question as best they can.

So the whole process quickly becomes little more than a box-checking exercise. The vendors that win are not selected on their ability to understand or improve the business process or help the user community, but rather the ones that have a huge array of “features” that nobody ever uses. And the ugly truth is that these features exist only so that they can be written about in these responses.

At some point, some poor worker in an enterprise will actually try to use one of these “features” and discover this tragic fact. But by then, the vendor is usually long gone. It’s skipped off in a cloud of money into the next RFT process… And the completed RFT remains filed away as protection against criticism of the buying decision.

And after a few years of frustration, the purchasing cycle begins again.