Monday, September 21, 2009

Whose problem is it anyway?

One of our corporate departments is implementing a SaaS application across the company. The application requires that every employee register independently. This is not going well: despite a tremendous effort by the project manager and each location manager, the task deadline is blown and still not complete. The implementation team asked me to pitch in to get this task over the line, something I have been happy to support. And yet, I realize that the only reason we are throwing so many hours at what seemingly was a simple task in the project plan is that the vendor designed an extremely poor process. The application's functionality depends on the independent registration of all employees, using a method that has an overly-complex opt-in design. Just how wrong is that?

Well, the vendor, who only recently minted this application, is committed to the design and has taken the position that it's a 'user problem.' This takes me back to the bad old days of vendor arrogance. Engineers would dictate business processes to all of their clients, even though those engineers had no working experience in the industries or markets of their clients. That didn't work especially well, so technology companies started offering customization services. The end result was essentially unchanged: the business could only contribute to the user requirements documentation, using the vendor's consultants as a conduit. The vendor still retained complete control over the design and specifications. The attitude was: we'll tell you how to run your business. Errors that resulted because the client's employees failed to use the (increasingly complex) system correctly (that is, the way an engineer thought it should be used) were the responsibility of the client. If the client asked for changes to make it easier for their employees to use the system, the client had to foot the bill and increase their risk of process failures due to the introduction of new code.

This may be the world that your business operates in, still. For many, the only opt-out option has been to bring design and modification in-house, so that development can respond to the actual needs of the business and its users. Truly opting out has not been possible for businesses using ERP systems: the cost and time involved in system replacement, and the disruption to the business, are great.

But in this decade, a new model has arisen from consumer-driven technology, which has flipped design on its head. If a web page, or a cell phone, or a mobile app, doesn't work the way the consumer wants to use it, the consumer can easily abandon it. Exit barriers are almost nonexistent in consumer technology. Consumers expect plug and play. They expect to be able to cut and paste from one application to another. They expect the software to be very forgiving, and to let them interact with the software many ways. Consumer technology companies do not expect the consumer to read a user manual, or follow work instructions to use the software. And you know what? These expectations are increasingly met, consistently.


Maybe the signal difference is that the consumer technology business's customers are the users of their technology. Business technology providers still think that their customers are the company execs who sign the contracts (and may never use the technology), not the employees who use the software. If your current ERP provider had to pitch to your front-line employees, would they keep your company's business?