Identifying ERP Usability Issues

ERP Research WorkshopBentley College

October 15, 2004

Wendy LucasTamara Babaian

Heikki Topi

Identifying Usability Issues Anecdotal evidence

• Hard to get data into ERP system– Mismatch between ERP terminology and

business practices• Even harder to get information out!

– Export data to Excel, Access to perform analysis

Forrester Research evaluation* • Tasks require inordinate patience and expertise to

complete• Users should demand better usability

*[Chew, Orlov, & Herbert, 2003]

Research Questions

Which characteristics of large-scale enterprise systems have a negative impact on their usability? • How should these characteristics be

categorized? Can collaboration theory be used as a

framework for identifying ERP usability problems and designing systems with improved usability?

Multi-Method Study

Field study to identify usability problems

Development of a theoretical model to provide a strong foundation for enterprise system usability design and evaluation

Development of a prototype Experimental analysis

Organizational Context for Field Study

Division of a very large diversified Fortune 500 corporation

Business: maintenance of complex engineering artifacts

All data collected from a single facility

Method and Informants

Data collection through semi-structured interviews

At this stage, 10 interviews lasting on average an hour each

A large variety of organizational roles representing shop floor technicians up through upper middle management

All informants (except one) users of the same large-scale integrated ERP system

Identified Problem Categories

Identification of and access to the correct functionality

Transaction execution support System output limitations Support in error situations Terminology problems Overall system complexity

Identifying and Finding Correct Functionality

Navigation problems• “Or maybe we have some menus, but presently it

may take us four, five or six routes to get us to basically one screen. I don’t always see the links.”

Difficulties in understanding the dependencies between the modules• “They're [warehouse, inventory] two separate

modules that don't talk to one another. So, that creates that very situation, where somebody can go on the warehousing side, and cancel a transfer order, but they don't know to go look on the materials side of the module, to see what that resulted in.”

Lacking Transaction Execution Support

Unduly complex transactions Need to enter data

repetitively• “…why do I have to keep entering the same data

over and over?”

Inconsistent behavior• “Well, I mean, we're so used to copying and

pasting. … In some cases, it remembers and will carry over to some of the screens, but not in all cases.”

Lacking Transaction Execution Support

Poor support for exception situations leads to system avoidance • “Like [a specific task], nobody wants to do

[it] in the system. … You know, they’re used to just going and get[ting] the part and manually doing the paperwork and just taking the part and just telling the buyer-planner later about it.“

System Output Limitations

Inability to get required output• “It [the ERP] doesn't give you the information you

need, and it just makes you[r] work more difficult – I found it not easy to use, not the right information, didn't update correctly, didn't have a lot of flexibility.”

Need to use external tools to process the data further• “And unless I export that down into [an] Excel file

or something, the system [is not] capable of compressing that [data], to minimize it, reduce it.”

Cognitive complexity of query tools• It's just that you need to be a brain surgeon to

actually go out and …… produce your own [queries].

Support in Error Situations

Incorrect or insufficient error messages• “You’ve got to go see somebody about how come it’s

red. But that’s after your transaction is completed. … It just says transaction failed or something like that.”

Lack of specificity• “We have a screen where we try and return parts to the

warehouse and if that's already been done, the transaction has already been done, it says ‘1045 error’ on the bottom of the screen. What [expletive] does that mean to anybody?”

Missing error messages• “We had the customized front-end and we had to hit two

buttons to execute a transaction. But the system will allow you just to hit one. So the guys would hit one and everything would be green, hey, I must be okay, but they never created the other requirements that were necessary to [complete the transaction].”

Terminology Problems

Unfamiliar system language• “The ‘Help’ is worthless because it's definitely

programmer’s language based. So having the ‘Help’ customized for business processes would be [an] important piece.“

• “Well, it was like the spaceship had landed, and these outer space creatures [trainers] got off, and started talking to us about how we were going to do our job, because nobody understood what they were saying.”

Need for a glossary• “I put together a glossary of how the vocabulary

changed from pre-[ERP] to post, because people didn't understand the terms.”

Overall System Complexity

General feeling of overwhelming complexity leading to feelings of fear• “It's a very intimidating system. “• “…he was like a deer; it was like he got so

upset because it was so out of his kingdom, so out of his normal -- he shutdown on me. “ [reaction when explaining how to enter a well-understood process to the ERP system]

Other Observations

Having resources to customize is vitally important

Significant amount of time and effort spent on the development of informal documentation

• Formal documentation is seldom used Power users play a very significant role Non-power users are much less likely

to explore the system’s potential

Learning to perform a new task is a difficult process based on trial and error, even for experienced and motivated users

Despite these difficulties, given enough time and effort, users do learn how to complete their required tasks

Major benefits come from integrated, consistent data

Other Observations

Approach Based on Collaboration Theory

All usability problems discussed are examples of non-collaborative behavior by the system

Recognizes the joint nature of the

activity

Views system as a partner in collaboration

Viewing the System As a Partner

I need those supplies by January 23, 2005

I don’t understand what you mean by January 23, 2005Date period is not valid.Try again…

Collaboration Theory*

Commitment to mutual support requires• Recognition of the context in which the activity

occurs• Communication to create coordinated, although

independent, subplans for the activity

Mutual responsiveness requires both parties to share relevant knowledge and adapt their behavior for mutual support

• If you’re having a problem with a subtask, and I can help by providing information or performing an action, I must offer help.

*[Bratman, 1992; Grosz & Kraus, 1996]

Example: Purchase Requisition

Task: Create a Purchase Requisition (PR) for a new part.

Problems encountered by Pat, the user:1. Start new PR -part not in Material Master – scrap the PR, add

part

2. Menu path for adding a new part is hard to locate if used only occasionally

3. Start new PR – enter the plant, but forgot the part number

4. Look up the part number – screen changes completely - about 12 different lookup options displayed – which to choose?

5. Finally entered all data she has– but many PR form fields are still empty – is she done?

Collaborative Critique

Instead of having to scrap purchase order due to missing part• Link to the Add New Part option is readily available from the

same screen

• Problems 1 and 2 are prevented

Instead of requiring Pat to remember the part number• System remembers the number of the newly added part

• Provides an option of entering it automatically

• Also provides access to all parts for that plant

To let Pat know when the process is complete• Optional fields are clearly distinguishable from the required ones

Using Collaboration Theory

Framework for design and evaluation for usability

Realigns responsibilities between the user and the system according to their roles and natural strengths, e.g.

• User required to know what’s the next stepversus

• System guiding the user through the steps of the business process

Collaborative approach to ERP design

Adjustable/business-based system vocabulary

Guidance through steps of business process Visible access to related tasks Communication of progress made after

performing an action Information on important ramifications of

user actions beyond the obvious Support for user in error situation: offer a

diagnosis/fix and/or an alternative course of action in terms familiar to the user

Using Principles of Collaboration in Interface Design: a Prototype

Benefits of Using Collaboration Theory Isolated examples of collaborative behavior

already exist in some form

Collaboration cannot be “patched on” in the end of system development

Principles of collaboration can and should be used to systematically address system requirements for a successful collaboration from the start.

Collaboration theory provides a framework for designing and evaluating ERP system usability.

Work-in-Progress

ERP usability design and evaluation • Development of design and evaluation guidelines for ERP

systems based on collaboration• Complete development of prototype• Usability experiments with the prototype

Field studies• Continue further interviews and surveys of ERP system users• Seek additional corporate partners for collaboration on ERP

usability

Combine results of experimental testing with field studies • Increase awareness of ERP usability issues and identify ways

to address them to enhance productivity

Thank you!