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

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, 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.“

11. 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].

12. 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].”

13. 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.”

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 system’s 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 don’t 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 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]

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 what’s 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!