I claimed that this happens because enterprise software vendors don't set goals for the learnability and usability of their systems, and because the enterprises themselves don’t hold vendors to high enough standards of application learnability, usability, and efficiency.
In this entry I'll relate some case studies where negative outcomes could have been prevented. I'll also discuss why the factors that contribute to these poor outcomes seem to be persistent.
In the next post, I'll provide examples of how to justify usability for enterprise software, and discuss a model for creating and deploying enterprise software that will result in more positive outcomes.
In the last entry I argued that enterprise software often falls short of the mark when enterprise vendors don’t pay sufficient attention to the specific wants needs of intended users.
I claimed that this happens because enterprise software vendors don't set goals for the learnability and usability of their systems, and because the enterprises themselves don’t hold vendors to high enough standards of application learnability, usability, and efficiency.
I this post I relate case studies where negative outcomes could have been prevented. I also discuss why the factors that contribute to these poor outcomes seem to be persistent. Finally, I relate a model for creating and deploying enterprise software that will result in more positive outcomes.
Case 1: The “Business Intelligence” System
The technical support group for a major financial software application was responsible for generating weekly and monthly reports on calls to the help desk. Statistics on call burden, call reasons, call resolution time, hold time, post-call work time, and other statistics tracking cost and rep productivity were summarized for management. The process of producing the reports was mostly manual – the data resided in three separate systems, data was extracted via complex (though mostly repetitive) queries, and reports were generated and formatted in a spreadsheet application.
Other groups within the organization – product management, development, user-centered design, and quality assurance - frequently requested custom reports and raw data from the amalgam of systems. Individuals within technical support and the IT group were sometimes overwhelmed trying to deliver their regular reports and comply with “outside” requests.
The business decided to deploy an enterprise-level application enabling support to centralize the data, automate data retrieval and report production, and provide outside groups with the ability to self-service their data and reporting needs.
Upon deploying the application the business discovered that, even after support and IT staff trained to proficiency, it took 5 to 10 times as long for staff to extract data and produce reports. What these groups discovered was that the application’s user interface, which was presented via a Web browser, only allowed users to “drag and drop” date ranges, field names, and other delimiters into a “reporting wizard” form. Complex queries that previously took 5 – 10 seconds to type now took 2 or 3 minutes to drag, drop, delimit, and run.
These users, with considerable technical abilities and expert-level knowledge, were essentially forced to interact with the system as if they were neophytes).
Furthermore, the reports were formatted into static HTML. Once produced, users were unable to reformat, rotate, or otherwise adjust the output. Although the simplistic process of query-building proved easier for occasional users from outside groups, the inability to manipulate the output proved frustrating. As a result, support and IT staff were again forced into a bottleneck role, laboriously creating reports to comply with outside requests for reports.
Within six months, the technical support group had brought their old systems back on-line, and reverted to their previous process.
Case 2: The Expense Reporting System
A large telecommunications equipment manufacturer decided to move from spreadsheet-based expense reporting to a system that enabled users to input expense information directly into the company’s accounting system.
The application promised to eliminate manual steps, including double entry of data, remove data entry bottlenecks, and streamline the accounting process.
Employees at this company had an inkling that the new system might pose difficulties when, two weeks prior to the system rollout date, HR disseminated a 50-slide training presentation to all employees. This was followed up by a mandatory, all-employee desktop video training session in the use of the new system. The training session, developed jointly by HR and IT, was 1.5 hours long.
The productivity lost to training for the new system was a significant expense, as was the projects related to producing training. These expenses were dwarfed by the time and expense lost when the system went live.
Everything about the application’s user experience was a mess. The process employees followed to enter, describe and categorize expenses was confusing, long, and ill-thought out. The screens to capture the data were poorly designed. The terminology used throughout the application, while familiar to finance and accounting professionals, was opaque and unclear to most other employees. Information was presented in illogical formats; users were forced to scroll through 200-item drop down lists with nonsensical ordering.
Successfully submitting an expense report, which had previously taken only a few minutes, was now a half-hour undertaking fraught with error and frustration. As a result, productivity and morale suffered. Worse, compliance waned and systemic errors were propagated through the accounting system: some employees simply stopped expensing small purchases, or assigned expenses to accounts that appeared near the top of long account lists.
The Vendor’s Lament: If You Build It, They Will Complain