During the last twenty years, enterprise resource planning (ERP) software has become a standard fixture of the daily work environment of many professionals who work in large companies. While there are other types of “enterprise” software, this article will focus on ERP systems, a $6 billion a year industry. Many Fortune 1,000 companies have deployed ERP systems to support all types of transaction-oriented work, from accounting to sales functions. Smaller companies are now adopting this technology due to the efficiencies of the Software as a Service (SaaS) model that make it more affordable. This means that increasingly, workers spend their days sitting at keyboards and staring at monitors feeding data into some variant of an ERP system.
ERP’s Influence
Today’s ERP systems are extremely complex. One could argue they act as the central nervous system in our modern economy. Global multinationals are dependent on them. Without ERP, managers of corporate workers who are increasingly spread across the globe would be unable to coordinate the activities that are responsible for billions of dollars of commerce.
The spread of the Internet has enabled transactions between these systems, allowing the tentacles of these monster programs to reach into even the smallest companies and the daily lives of consumers. It is ERP systems that ultimately capture the transactions initiated by consumers as they click on e-commerce web pages, Kindles, iPhones, and the pervasive point-of-sale systems that have replaced cash registers.
Consider what it must be like to work day-after-day in front of a screen produced by an ERP vendor that occasionally spits out incomprehensible errors, or worse yet, loses your work. It’s definitely not an experience comparable to using an iPhone. Enlightened members of the analyst community have long known this, but the IT industry is finally maturing to the point where key stakeholders (not users) are starting to take notice.
Why is This so Hard?
As professionals, we know that framing the design problem—getting a shared vision of the design goals and constraints with all the project stakeholders, including the users—is one of the most important aspects of user-centered design. This is where designing enterprise software becomes more complex than designing consumer software.
Historically, one of the key challenges in enterprise software has been the number of stakeholders involved and their conflicting agendas. This is the major barrier to improving the usability of ERP systems. It is not the UX professionals involved, or the lack of resources, but the nature of the problem itself. Let’s review the different stakeholders for ERP systems:
Individual Users
The individual users are the accountants, call center representatives, sales personnel, and countless others who record transaction-oriented data into ERP systems. In cases of self-service-oriented purchasing or expense reporting software, it could include anyone who is required to do those tasks in the company, not just the individuals in the purchasing or procurement functions. Unlike consumer software end users, they don’t have a say in purchase of ERP systems. They also don’t have a way of providing feedback to the vendors about user experience problems.
Functional Managers
The functional managers on the team perform specialized functions in the organization. Examples include managers of sales divisions and customer support organizations. It’s important to consider managers’ goals for ERP systems during design, such as providing consistent ways of combining sales forecasts or tracking support issues. This extends beyond what the individuals do with the UI to how that work is coordinated and measured. Functional managers occasionally have limited input into purchase decisions at companies. Unfortunately they almost never have a direct line of communication with vendors to discuss product enhancements.
Enterprise Executives
As the “E” in ERP implies, the systems are designed to serve enterprises and their executive management. Examples include aligning sales predictions with manufacturing plans or the related staffing and support budgets. ERP systems are designed to meet the needs of the executives who are the ultimate customers and decision makers regarding ERP purchasing. They have significant influence on ERP vendors, but typically this is channeled through individuals with IT responsibility, such as the CIO or CTO. One problem is that the enterprise executives rarely, if ever, actually use ERP systems. So while they hold the purse strings, letting executives select an ERP system is much like having your grandmother select your clothes for you.
Other Stakeholders
The other stakeholders include customers, business partners, and analysts that “guide” the customers of ERP systems. Since most of today’s ERP systems incorporate what is known as business-to-business (B2B) and business to customer (B2C) functionality, this also needs to be considered. Most modern ERP systems are used by both customers and business partners. For example, Amazon can tell you when your shipment will arrive, and how much shipping will cost using ERP. Ecosystem members have limited-to-no input in ERP purchase decisions. Analysts can significantly influence the decision makers, but rarely focus on user experience aspects of ERP.
Other Factors
Another factor contributing to poor ERP user experience is sheer complexity. ERP suites, which contain a broad range of functions, might have tens of thousands (if not hundreds of thousands), of pages or screens. Similar to the large corporations they serve, ERP systems are typically composed of loosely coupled functionally specialized modules. These specialized modules are only designed to be used in a part of a company, such as the call center, accounting, or human resources department.
As one would expect, the design of these modules reflect the philosophies of modern corporations. As such, ERP systems inherit both the strengths and weaknesses of this way of conducting business. One key weakness in both corporations and ERP suites is that their modularity makes them resistant to change.
ERP is software for corporations, designed by corporations. While this might sound like a good thing, consider that most large corporations suffer from poor cross-functional communications. This presents many barriers to good design.
User-centered design depends on regular, rich interaction with users throughout the development process. Better feedback loops result in better designs. Unfortunately, insufficient feedback from the user (note the use of “user” and not “customer”) is the norm in enterprise software today. Frequent interaction with users required for design iterations are rare compared to that in more consumer-oriented companies. The iterative design process for a package of soap at Proctor and Gamble is subject to much more user feedback than most ERP modules.
The ERP ecosystem is fertile ground for what former Microsoft COO Robert J. Herbold calls “the fiefdom syndrome.” Many players in the ecosystem are solving for their own short-term interests. Here are some of the classic maladaptive behaviors:
- Most of us recognize that the end users of ERP systems would be the best source for many UI requirements. Unfortunately, these users face the conflict that they are under pressure to get their primary work done. This makes them hard to engage in the design process, even if you can navigate the organizational barriers necessary to reach them at all.
- Managers of functional areas in large corporations often have limited recent hands-on experience with day-to-day transactional work. They are rarely the best source of information on how to design systems for their staff, but often they don’t realize this. These managers also don’t want day to day productivity of their teams impacted by IT initiatives like providing feedback on the design of ERP systems. Nor do they have the time or motivation to get involved in IT projects like ERP deployments; they simply aren’t rewarded for doing so.
- IT departments in companies typically want to own the requirements for their ERP systems. Unless they have training and experience conducting user-centric research methods, they may not have the skills to do this work, at least at the level of sophistication found in consumer product companies. Making it worse, they are often discouraged by managers of functional areas when they do attempt to conduct any requirements analyses with end users. All too often, IT staff gets rewarded for introducing new technology, but not evaluated based on the impact this technology has on worker productivity. The net result is that corporate IT departments can become more of a barrier than a facilitator in efforts to gather user feedback to refine ERP systems.
- IT consulting and professional services firms want to position themselves as experts to their customers. Often this means they fail to fully analyze the needs of each customer in detail, relying instead on their expertise. Rarely do they admit the need to conduct any type of user-centered requirements analysis. Doing so would require billing the customer for learning requirements for the ERP system, something they want to claim expertise in. Even if they do propose a detailed requirements analysis effort incorporating usability feedback, and have a staff skilled in doing so, this adds to the cost of the “scoping phase” of the engagement, which means it rarely gets approved. When requirements applicable across customers are discovered, this is often seen as an opportunity to create “custom solutions” for which each new customer is billed, rather than suggesting these enhancements to vendors.
- Sales people at ERP vendors are rarely motivated to assist in engaging the customer in any deep level of requirements discussions. They are primarily motivated to close each deal quickly. Any ongoing discussions with customers are typically viewed as conflicting with sales goals. Sales people may also want to avoid any possibility that customers perceive the current product as deficient, because it may impact short term sales efforts.
- Professional Services teams that are part of ERP vendor organizations are typically motivated on a project-by-project basis to gather requirements. Unfortunately, they may also be motivated to keep this information to themselves since this knowledge makes them more valuable. They may also develop “custom solutions” which they reuse unknown to the customer or the product teams.
- Support organizations often have plenty of insight into what is not working with deployed products. Rarely are they consulted before a customer actually deploys the product. Typically, they are rewarded for “closing” an issue as quickly as possible. This often results in them not having time to participate in requirements gathering efforts. When they do identify product improvements, they often struggle to get improvements implemented, as these are typically seen by product management as less strategic than new functionality driven by marketing considerations.
- Product management often has limited customer interaction due to the influence of the previously mentioned organizations. Even if they have significant domain knowledge, it often quickly becomes outdated and is limited to experience at a single company which may or may not represent the market as a whole. All too often, product management is incented to focus on feature enhancements rather than usability and simplification. Another problem that occasionally arises is that product management may want to “own” requirement decisions so much that they fail to facilitate an ongoing dialog between user experience specialists or product teams and the customers and end users. Even when motivated to do the right things, they may struggle to overcome the organizational barriers within both their own company and those of customers they try to engage with.
- Development teams may not work closely with any of the above organizations. They are typically incented to deliver new functionality as quickly as possible and have little say in extending deadlines to address quality or user experience issues. In some cases they may not even work closely with product management, due to pressure to focus on completing development tasks on current projects.
- Another contributing factor is the lack of shared vision on user experience or other best practices within vendor organizations. Due to the size of ERP projects, many vendors have specialized product teams focused on each functional module, working with limited oversight. This means modules created by teams often fail to integrate well, creating usability issues that impair efficient collaboration among a customer’s functional divisions and even design problems at the enterprise level. It also results in a new twist on the “it’s not my department” problem when it comes to the UI design.
- When a product team member in a vendor organization, a user experience advocate in the partner or customer ecosystem, or an industry analyst tries to work with others to resolve user experience issues, the functional separation makes this difficult. The end result is that ERP systems often look like they were designed by developers using different requirements, instead of a consistent, unified system. Efforts within vendor companies, customers, and the ecosystem as a whole are often uncoordinated. Interacting with other stakeholders requires navigating an ecosystem filled with individuals and organizations that have conflicting priorities.
Recognizing Enterprise Software Is Different
Jeff Conklin recently wrote an article in Rotman Magazine advocating a “design approach” to solve so called “wicked problems.” Wicked problems:
- Are complex problems that lack a clear definition agreed upon among the multiple stakeholders
- Lack a binary-like state of success for any given point in time (only some type of optimal state)
- Are unique enough to be unsolvable by commonly known methods
- Require experimentation on many dimensions in order to make progress.
This sounds a lot like enterprise software to most of us who have worked on it.
What can we do?
We need to recognize that designing usable enterprise software is different. In the past, most enterprise companies have been attempting to apply methods derived from consumer product design without much modification. Just testing representative individual users in a usability lab is not sufficient.
As Jakob Nielsen mentioned in his November 2005 Alertbox newsletter column (www.useit.com/alertbox) “Enterprise Usability,” there are at actually three dimensions to cover:
- Individual users
- Groups of users
- The enterprise
Standard lab testing misses group- and enterprise-level usability issues, as well as the impact of test data versus real data in these studies. User experience professionals working on ERP systems need to explore methods that overcome these problems.
Some Promising Directions
The Common Industry Format (CIF) effort was a significant step forward. It started a dialog among vendors and enterprises. However, almost ten years after it was proposed, most IT organizations and industry analysts remain largely ignorant about user research methods, including summative testing. According to the Standish Group, only 40 percent of IT organizations measure the success of the systems they deploy. ERP customers should be asking for CIF data, and analysts should be publishing reports discussing CIF study findings. Customers should be asking why vendors have not sent someone out to discuss studies measuring the usability of the latest updates to their ERP systems. Industry analysts should start asking about this kind of data, rather than acting as extensions of ERP marketing departments to push further investments in IT.
Another step in the right direction, vendors have started focusing more on ethnographic studies of enterprises that specifically focus on workgroup and enterprise level factors in addition to end-users. Studies of this type take time and planning, but they provide valuable data for designing ERP systems. Even more important than any particular design improvements identified in these studies is the shared context they help develop among stakeholders. Progress is being made, but until everyone in the ERP ecosystem is familiar and supportive of this type of work, there remains significant room for improvement. Success looks something like this: CIOs start asking vendors why they haven’t seen someone studying ERP use at their company, and asking about the findings of those studies.
The most promising trend is the increasing use of customer advisory programs. Such efforts address the lack of alignment among the stakeholders in the enterprise ecosystem, a key barrier to improving designs. Any increase in dialog will help create shared vision of both the problem and how to make progress. While these efforts are often restricted to a small vocal set of customers, it is certainly a step in the right direction. Ideally these programs would be run as working groups, focusing on resolving issues identified by other methods including, but not limited to, low user satisfaction scores, low scores on CIF defined measures of deployed ERP systems, and usage data collected from large numbers of customers.
What can usability professionals—many of whom work in customer and vendor organizations—do to make a difference? One way to help would be to prioritize the discussion of enterprise user experience within our profession. We can also highlight the efforts of vendors as well as user experience professionals who work for forward-thinking ERP customers.
Usability professionals might also consider starting an outreach program targeting executives who make IT purchasing decisions with the goal of educating them in regards to the impact of poor usability on worker satisfaction, organizational efficiency, and more importantly, corporate profit margins. If we can convince them that user experience knowledge can impact their business, they will listen.
