In this interview, I’ve asked Jon to focus primarily on back office enterprise application software, more commonly known as Enterprise Resource Planning (ERP) software. This is typically complex software that enables companies to “run the business” and covers major functions such as: accounting, billing, invoicing, order management, etc. Due to the complexity of these applications, UI/UX is especially critical but has traditionally taken a distant back seat to functionality.

Q. Jon, ERP applications are typically “mandatory” applications. That is, if you are an AP clerk or call center agent or a member of the Purchasing department you must use an ERP application to perform your function – you spend your entire day sitting at a keyboard staring at a monitor feeding data into an ERP system.  As a result, you would think that companies would be extremely focused on ensuring that workers were as productive as possible and that the UI/UX of the ERP software was as easy to use as possible. Why, then, is ERP UI/UX so challenging?

A. Actually Bruce, your question hints at the answer. “Mandatory” applications don’t have the same feedback loops of consumer products. The AP clerk is unlikely to be involved in selecting the system and has little input into the requirements and design process.

This is historically one of the key challenges in enterprise software. There are so many stakeholders involved compared to consumer products and each of them tends to have conflicting agendas. This is the real reason ERP systems are known for having poor UIs. It is not the UX professionals involved, or the lack of resources, but the nature of the problem itself. Think of all the different stakeholders associated with ERP systems and their influence on the design and purchase of ERP software:

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.

Unfortunately, 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 (thanks granny, that’s lovely…)

Other Stakeholders

The other stakeholders include customers, business partners, and analysts that “guide” the customers of ERP systems. 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.

Q. What are the other challenges beyond the feedback loop?

A. Another big 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.

These screens are designed to be used in just a part of a company, such as the call center, accounting, or human resources department. As one would expect, the design 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.

Q. What key techniques to making things easy-to-use apply to ERP UI design?

A. One key factor is just simple iteration in the design process. The iterative design process for a package of soap at Proctor and Gamble is subject to much more user feedback than most ERP modules. However, the problem is also in reaching the end-user. 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, at least for streamlining existing work. Unfortunately, these users face the conflict that they are under pressure to get their primary job 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 any 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 becomes outdated and or 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 any customers they do try to engage with directly.

• 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. Rarely do they track objective metrics on UX related quality so tradeoffs go unnoticed at most companies.

• 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.

Q. Ok, so you’ve done a good job explaining how various stakeholders can negatively influence the ultimate UI/UX of ERP. But irrespective of stakeholder influence, why can’t ERP vendors make their applications look a lot more like a consumer application “out of the box” or in the case of a SaaS-based system, “out of the cloud”?

A. Well I think the good news is that SaaS solves part of the feedback loop problem. At least now the vendor of the ERP solution can tell if users are actually using it. In the past lots of money was spent on ERP that really didn’t get fully used. Kind of like that funky sweater or tie grandma bought you for Christmas. Now it’s like grandma lives next door, and she knows you never really wear those presents. That is of course if she’s paying any attention which brings me to my next point.

The other half of the problem is mindset. You’d be surprised at how much the old “through it over the wall” attitude still exists at many SaaS ERP providers. For the most part they still don’t have the kind of user-centered design process or UX metrics that folks at Apple, Yahoo or Google take for granted.

One of my clients who is a midsize SaaS provider in the ERP space has not run a single A/B (user research) test in almost 8 years of business. They have over 150 engineers and no full time UX staff. That would be unheard of in a consumer website company. Now days most early stage startups focused on consumer offerings hire dedicated UX staff and run tests like A/B studies long before they get series A funding or hire more than a dozen engineers.

Q. What are some things that companies can do to overcome the issues you’ve identified with poor UI/UX associated with ERP applications?

A. Test the usability of their products and fix the problems. According to research by Jeff Sauros (a former Intuit UX guy now at Oracle) “usability problems are almost ten-times more common on business applications than on websites. The ratio is around 2 to 1 for business applications and consumer software.” His tests use what we call CIF-style summative metrics in UX.

Ten years ago, the Common Industry Format (CIF) for usability tests was defined after corporations like Boeing and Allstate realized the hidden costs of unusable IT. However, almost ten years after CIF was ”adopted” as a standard, most IT organizations and industry analysts remain largely ignorant about CIF and related UX research methods, which can objectively measure if a product or service is easy to use. Salesforce.com probably does the best with this stuff, but even their level of effort lags behind a company like known for ease of use like Intuit.

This isn’t surprising. According to the Standish Group, only 40 percent of IT organizations measure the success of the systems they deploy in any way! ERP customers should be asking for usability data like CIF metrics, and analysts should be publishing reports discussing usability test data not just opinions. Executives in CTO/CIO roles should be asking vendors about data on the usability of the latest updates to their offerings. Industry analysts should start asking about this kind of data too, rather than acting as extensions of ERP marketing departments to push further investments in IT, ignoring the high failure rate of ERP projects.

Another step in the right direction, some vendors have started focusing more on ethnographic studies of enterprises that specifically focus on workgroup and enterprise level factors in addition to end-user ease of use. These have long been recognized in consumer product companies as key to creating usable products. Studies of this type take time and planning, but they provide especially valuable data for designing useful, usable ERP systems where they highlight designs that don’t support group or companywide collaboration well. I helped introduce these at Oracle as a designer in the ‘90s but upper management didn’t’ understand the value they provided.

Success looks something like this: CIOs start asking vendors why they haven’t seen data on the ease of use of systems at their company. CEOs of ERP vendors start paying more than lip service to ease of use and UX. Finally, VC’s should probably be asking for UX metrics when they start considering writing term sheets for ERP startups. Dave McClure and some of new UX savvy wave of early stage investors already do this when funding ventures like Mint.

« Hide It