Just as the mass market has demanded and is receiving more usable products, so should businesses demand that their technology vendors make their software easier to learn, more efficient to use, and easy to remember. But for a variety of reasons, many organizations don’t even know how to make this demand.
Consider this column a call to action to organizations that buy enterprise-level software. Here’s what I have to say to them:
Your technology selection processes are incomplete. You’re not assessing the usability of the technology you buy. You’re not only incurring huge hidden costs because of this failure to assess usability, you’re letting enterprise technology vendors get away with building products with poor usability.
The rest of this column explains why this happens and what enterprise technology purchasers can do about it.
Enterprise Software
Enterprise software products are complex, powerful tools. Their complexity is one of the reasons businesses sometimes fail to fully realize the expected return on investment from these products.
For enterprise employees, who must use these enterprise applications, this complexity poses a considerable challenge. When an organization deploys an application, it expects users to learn the new system, integrate it into their existing work processes, and become proficient enough to allow the organization to realize the system’s full benefits. Far too often, however, enterprise employees find these new systems hard to learn, hard to master, and difficult to integrate into existing processes.
Enterprise software, which broadly encompasses functions such as enterprise resource planning and management, customer relationship management, supply chain management, network management, project portfolio management, and business intelligence, is a multi-billion-dollar-per-year industry. Well-known vendors include BMC, Oracle, SAP, Siebel, and telecommunications equipment manufacturers such as Nortel and Cisco, to name a few.
Most Fortune 500 companies have multiple enterprise software products installed, and many mid-sized business are either actively considering or have implemented enterprise solutions. As the market has matured and vendors have searched for new growth opportunities, enterprise software developers have made solutions available to even small businesses with fewer than 100 people.
To a growing company, enterprise software promises to convey benefits in a variety of areas, for example:
- Centralizing customer information from sales, marketing, customer service, and support to improve customer service and enable better prospect identification.
- Identifying and managing enterprise-wide resources an organization needs to receive, process, and track orders.
- Gathering, storing, analyzing, and providing access to enterprise data that lets users make better business decisions.
- Consolidating information relating to project planning, tracking, and resource management for multiple projects, enabling an enterprise-wide view of project scope, resource allocation, risk, cost, and performance.
- Configuring and maintaining the performance of network resources, managing and recovering from network faults, managing network traffic for billing and accounting purposes, and ensuring the security of the network.
This is complex stuff.
Consequences of Poor Usability
From the CTO’s and IT Director’s perspectives, these promises assume the internal user groups can and will learn the new systems and incorporate them into their work processes. But these outcomes are far from assured. Some of the problems and pitfalls businesses encounter include the following:
- Some businesses find that their employees’ productivity actually decreases, because common or critical processes take longer using the new application.
- Others fail to realize an application’s benefits, because users vote with their fingers and don’t adopt the new system.
Businesses can also experience reduced employee morale and increased turnover as a result of the imposition of new systems and processes. There will always be some employees who resist change in any form. However, if a business mandates process changes and deploys systems users perceive as difficult to learn, use, and remember, the user population will see it as a change for the worse and resist. In such a situation, employee morale declines, and those who are sufficiently disgruntled may even leave if other opportunities present themselves.
IT (Information Technology) organizations responsible for supporting an enterprise application can find themselves overwhelmed as they struggle under the unexpectedly high numbers of support requests that often accompany an application rollout. As anyone who has worked a help desk knows, rollout day for a complex application often seems like a perfect storm for level-one support staff.
Why do such scenarios play out in organization after organization? I argue that two factors drive these kinds of outcomes:
- Enterprise software developers don’t pay sufficient attention to the specific wants and needs of their internal user groups.
- Enterprises don’t hold their vendors to high enough standards for application learnability, usability, and efficiency.
To illustrate the real-world costs of these two failures, I’ll relate two case studies. These are true stories. They happened in organizations I’ve worked for—though I’ve obscured their identities to protect the guilty.
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 their help desk. The reports summarized statistics for management, including call burden, call reasons, call resolution time, hold time, post-call work time, and other statistics that let them track costs and the productivity of support representatives. The process of producing the reports was mostly manual. The data resided in three separate systems, requiring data extraction through complex—though usually repetitive—queries, and they generated and formatted reports using a spreadsheet application.
Other groups within the organization—including Product Management, Development, User-Centered Design, and Quality Assurance—frequently requested custom reports and raw data from this amalgam of systems. Trying to deliver their periodic reports and comply with outside requests sometimes overwhelmed the people in the Technical Support and IT groups.
The business decided to deploy an enterprise-level application that would enable Technical Support to centralize the data, automate data retrieval and report production, and provide outside groups with self-service capabilities that would let them meet their own data and reporting needs.
Upon deploying the application, the business discovered that it took five to ten times as long for the Support and IT staffs to extract the data and produce the reports—even after training had made them proficient in the application’s use. Both groups discovered that the Web application’s user interface comprised a reporting wizard that required users to drag and drop date ranges, field names, and other delimiters into a form. Complex queries that had previously taken five to ten seconds to type now took two or three minutes to drag, drop, delimit, and run. The application forced users—who had considerable technical abilities and expert-level knowledge—to interact with the system as if they were neophytes.
Furthermore, the application output the reports as static HTML that users could not reformat, rotate, or otherwise adjust. Although the simplistic process of query-building proved easier for occasional users from outside groups, their inability to manipulate the output proved frustrating. As a result, the Support and IT staffs were again forced into a bottleneck role, even more laboriously creating reports to comply with outside requests. Within six months, the Technical Support group had brought their old systems back online 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 let users 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 (Human Resources) disseminated a 50-slide training presentation to all employees. Next, all employees found out they must complete a mandatory hour-and-a-half-long desktop-video training session in the use of the new system that HR and IT had developed jointly.
The productivity lost to training employees to use the new system was a significant expense, as were the projects that were necessary to produce the training materials. However, the loss in productivity and expense the organization suffered when the system actually went live dwarfed the up-front training costs.
Everything about the application’s user experience was problematic. The process employees followed to enter, describe, and categorize expenses was confusing, unnecessarily long, and ill thought out. The data-entry screens were poorly designed. The terminology the application used, while familiar to finance and accounting professionals, was opaque and unclear to most other employees. The application presented information in illogical formats. For example, it forced users to scroll through 200-item drop-down lists of accounting categories and cost centers, whose order made sense only to those in the Finance department. Users could not resort lists in the user interface into alphabetical or numerical order.
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 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.
I’m sure my experiences are not unique, and these types of fiascos occur in enterprises worldwide. Why? Let’s explore the dynamics of technology selection.
