Identifying ERP Usability Issues

1
Identifying ERP Usability Issues

• ERP Research Workshop
• Bentley College
• October 15, 2004
• Wendy Lucas
• Tamara Babaian
• Heikki Topi

2
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

3
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?

4
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

5
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

6
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

7
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

8
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 dont 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.

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

10
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, theyre used to just
  going and getting the part and manually doing
  the paperwork and just taking the part and just
  telling the buyer-planner later about it.

11
System Output Limitations

• Inability to get required output
• It the ERP doesn't give you the information
  you need, and it just makes your 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.

12
Support in Error Situations

• Incorrect or insufficient error messages
• Youve got to go see somebody about how come
  its red. But thats 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.

13
Terminology Problems

• Unfamiliar system language
• The Help is worthless because it's definitely
  programmers 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.

14
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

15
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 systems potential

16
Other Observations

• 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

17
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

18
Viewing the System As a Partner
I dont understand what you mean by January 23,
2005 Date period is not valid. Try again
I need those supplies by January 23, 2005
19
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 youre 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
20
Example Purchase Requisition

• Task Create a Purchase Requisition (PR) for a
  new part.
• Problems encountered by Pat, the user
• Start new PR -part not in Material Master scrap
  the PR, add part
• Menu path for adding a new part is hard to
  locate if used only occasionally
• Start new PR enter the plant, but forgot the
  part number
• Look up the part number screen changes
  completely - about 12 different lookup options
  displayed which to choose?
• Finally entered all data she has but many PR
  form fields are still empty is she done?

21
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

22
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 whats the next step
• versus
• System guiding the user through the steps of the
  business process

23
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

24
Using Principles of Collaboration in Interface
Design a Prototype
25
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.

26
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

27
Thank you!