UNIVERSITY OF AMSTERDAM
BACHELOR THESIS INFORMATION SCIENCE FACULTY OF
SCIENCE
18 ECTS
A checklist for ERP System implementations
Author: Supervisor: Second Reader:
Armand de Waard Dr. Frank Nack Dr. Jacobijn Sandberg
Student ID 6217206 / 10001851 Informatics Institute Informatics Institute
armanddewaard@me.com f.m.nack@uva.nl j.a.c.sandberg@uva.nl
1. Introduction
Inherently linked to large organizations are the so-called Enterprise Resource Planning (ERP) Systems. ERP systems are software systems containing multiple smaller subsystems such as Customer Relationship Management (CRM), Human Resource Management (HRM) or Accountancy (Chang et al., 2008).
Most companies start out using these CRM, HRM and other systems as separate systems, usually developed by a number of different software providers. At a certain point in the growth of an organization, it can be desirable to switch to one system, containing all mentioned functionalities in one location, one central database (Sanchez and Yagüe, 2010). Software systems such as AFAS1 or SAP2 can do this. This brings a number of advantages, mostly linked to efficiency and quality assurance of procedures (Sanchez and Yagüe, 2010).
Another important gain, or maybe a loss, when implementing ERP systems is a change in user experience. This paper focuses on a section of user experience: usability (Nielsen, 2012), especially a checklist that should result in the minimization of usability issues in ERP systems after the implementation is completed. Most studies that research usability in ERP systems are carried out after the implementation (Singh and Wesson, 2009). However, in our experience, derived from doing our own implementations, decisions made during the development process and the way the actual implementation is tackled can lead to the outcome being different in many ways. Badly thought out processes might lead to workarounds being needed, eventually making users having to take extra steps to complete certain scenarios. Possible scenarios could be from any part of the system, such as creating customers, processing customer discounts in the orders they place or sending out invoices. This also leads to bad usability, even though making decisions about how the ERP system is going to be implemented is a step that takes place during the implementation, not after the ERP system is operational.
In this study we aimed to provide a better understanding of the problem of ERP system development in the context of merging already existing systems into one. This study consisted of three separate phases. The first phase was to research ERP systems, usability and specifically checklists for usability in ERP systems. For this, a number of literary articles were researched and a proper base was formed to continue on with phase two. In phase two, a checklist was developed. This checklist was based on issues that came up during and after the implementation of an ERP system, derived from a use case. Generalizing these issues and comparing with an existing checklist from literature created the modified list. Our contributed checklist aimed to prevent critical issues that might come up during an implementation by making customer and consultant alike think about these issues. The last phase addressed the evaluation of our modified checklist developed in the previous phase. Interviewing a number of ERP system consultants and asking them to compare the issues in the checklist to their own experience did this. This paper presents all 3 phases and concludes with a discussion of our contribution, i.e. this study resulted in a checklist that can be used before and during ERP system implementations, based on which efficiency can be increased and time needed for ERP system implementations can be decreased, which eventually saves money and prevents usability issues. We also outline some future work, e.g., by recommending using larger pools of interviewees and use cases, an even better tailored list could be created.
2. Literature Review and Research Question
In order to understand the link between ERP systems and user experience, in particular usability, we first have to find out what the definition of an ERP system is. We can define an ERP system as an integration of multiple small systems and processes into a large singular system, containing all the information to perform organizational processes top to bottom (Boudreau, 2003 and Yeh, 2006). ERP System infrastructure is built upon
1
AFAS Software http://afas.nl
a common database, allowing for easy access to data, keeping all information in one centralized location (Hawking and McCarthy, 2000, p.129).
Even though ERP Systems bring huge benefits to the ways organizations can operate with regard to process management as researched by Sanchez and Yagüe, they have been known to have poor user experience, in particular a poor usability (Matthews, 2008). There is not a lot of data available that zooms in on the usability problems encountered by users, the main focus of this paper.
2.1 Defining Usability
According to the Nielsen Norman Group “User experience encompasses all aspects of the end-user's interaction
with the company, its services, and its products” (Nielsen and Norman), this is the broader concept that includes
quality attributes such as usability. Usability was the main focus of the study, but other quality attributes such as utility, how useful something is, were also very important. We used Nielsen for a definition of usability:
“Usability is a quality attribute that assesses how easy user interfaces are to use
.
The word "usability" also refers to methods for improving ease-of-use during the design process” (Nielsen, 2012).2.2 Usability in ERP systems
In their article Evaluation Criteria for Assessing the Usability of ERP Systems, Singh and Wesson (2009) explain that there is a need to improve the overall usability in regard to ERP systems. However, Singh and Wesson state there is no fixed set of methods that can be used to assess ERP system usability. They used existing heuristics, namely those of Nielsen (Nielsen and Mack, 1994) and those of Shneiderman (1998)
Singh and Wesson define usability heuristics as “Guidelines or general principles that can guide a UI design
decision or that can be used to evaluate a decision that has already been made” (Singh and Wesson, 2009).
Research in the past (Singh and Wesson, 2009; ISO, 1998) has led to a number of usability issues that came forward with ERP systems. This led Singh and Wesson to a list of six base criteria for evaluating the usability in ERP Systems: performance and stability of the ERP system, navigation capabilities of the ERP system, degree of learnability of the ERP system, ability of the ERP system to provide effective task support, presentation capabilities of the ERP system and the ability of the ERP system to customize to a particular organization and an individual user. They then stated that these usability issues mostly occur within the following usability criteria, which were proposed as a set of usability heuristics specific to ERP systems:
• Navigation and Access to Information: Aims to determine accessing of information and navigation through different menu items;
• Presentation of Screen and Output: Focuses on the layout of the screen, available information and the output of information;
• Appropriateness of Task Support: Aims to determine if business processes have correctly been aligned with the ERP system to assure efficiency and correct task completion;
• Intuitive Nature of System: Determine whether a user needs more or less effort to understand the system and learn to use it efficiently;
• Ability to customize: The ease of customization to suit the organizations need.
Singh and Wesson developed the list by conducting a task-based approach with two scenarios: adding a customer and processing a sales order. These two scenarios, which were selected after interviewing 21 SAP users, led to the surfacing of the usability issues mentioned in Table 1 (on the following page). These issues were the base of our study and were used in comparison against our own use case to see if they lined up.
Table 1 - Singh and Wesson Heuristics and Potential Usability Issues Usability Criteria Potential Usability Issues
Navigation
Information is not easy to find.
There is insufficient help for finding the correct information and transaction screens.
There is no form of guidance within the system to aid the user when completing a business process. There is no search functionality.
Navigation does not support the different types of users. Next sequence of steps is not indicated.
Presentation
Visual layout is too complex.
Output is not easy to understand and interpret. Output is too complex.
The UI of the system is not very intuitive.
Task Support
Terminology used is not consistent with that of the user. System does not enable efficient completion of tasks. System does not improve productivity for novices. System is not easy for novices to use.
Learnability
Long introduction needed to learn how to use the system.
Not easy to become skillful with the system within a short period of time. Some aspects of the system make it intimidating and complex to use.
Customization Limited customization.
The problem with the work by Singh and Wesson is that their heuristics are based on previously researched usability issues in ERP systems. These issues primarily surfaced after the actual implementation, when the implemented system was already operational. There was no mentioning of issues that arose during the implementation and why they might lead to the described usability issues afterwards such as the system not enabling efficient completion of tasks. Furthermore, Singh and Wesson did not describe what kind of SAP implementation was used. Since these can be very different depending on the domain, it could be that different issues come up in different installations. A company just using CRM might experience different usability issues than a company using both CRM and order processing. The lack of explanation makes it difficult to interpret were the results are applicable and therefore decrease their effectiveness.
Scholtz et al. (2010) researched if qualitative research methods would allow the evaluation of ERP system user interfaces. They found that collecting just quantitative data based on existing usability criteria does not give enough qualitative information when interacting with users. During their research they used a variety of research methods and were able to confirm that using qualitative techniques to validate quantitative data provided additional and more detailed information. We used a similar approach to evaluate our list and the Singh and Wesson list during the interviews with experts.
2.3 Research Question
As the literature on ERP development and especially the work of Singh and Wesson are unclear about how to best check the development process we developed the following research question (RQ1):
How can a checklist be devised to properly prepare for and perform an ERP system implementation to minimalize usability problems?
To answer the research a number of sub questions had to be answered: 1. Which current usability research in ERP systems is there? 2. Are there any checklists in usability for ERP systems? 3. How would experts evaluate the new checklist?
The remainder of this thesis describes the approach to answer those questions. 3. Use Case
The literature described indicated a lot of usability issues surfacing when evaluating an ERP system after its implementation. Singh and Wesson created their own list of potential usability issues that surfaced during their research. Because Singh and Wesson did not mention the domain of their use case and also did not do any research in the implementation section of the ERP system, a new use case was necessary to test if any new issues might surface. In order to studyhow usable thechecklist devised by Singh and Wesson was, it was necessary to look at a different use case. In this use case the outcome of the study done by Singh and Wesson could be compared to test their outcome. This allowed us to show the incompleteness of their checklist and illustrate the improvements that might be made, allowing for a more complete guideline to implement ERP systems within companies while minimizing the number of usability issues.
The new use case was chosen based on the fact that it was documented from start to end and a lot of information about the actual implementation was available. The goal was to see where the Singh and Wesson list (see Table 1) might work in this use case and where it might not work.
3.1.1 Domain of the use case
Our specific use case was based on an ERP implementation at a company doing Online Backup and Disaster Recovery. The company employed 10 persons, all in separate positions such as marketing, sales, IT and customer support. All sales were almost exclusively done on a subscription basis. A customer could buy a subscription of a certain type with any amount of storage that is then billed every month, year or similar period. Several systems were used to make this possible, operating mostly as a stand-alone system and not cooperating with one another in any way. In order to overcome the challenges mentioned before, such as having to enter data multiple times and having to deal with inconsistencies, the step towards an ERP system was made. The software picked as a solution was AFAS, which hosted all the systems needed such as CRM, HRM and even a customer portal in one solution.
The systems that were going to be replaced by the ERP system were a CRM system, an administrative system, the customer portal from the website and the backend of the website were all the subscriptions for resellers and customers were managed.
3.1.2 Functionalities of the old systems before ERP implementation
The functionalities before the ERP system was implemented were essential for almost all employees. They were being used by the financial controller, the customer support employees who took support calls and managed order statuses, and also by the sales department who entered new orders, took care of all order related questions and who managed CRM data. Therefore the systems had to be either the same in the chosen ERP system or offer similar ways of tackling the proceedings at hand so that the implementation was an actual step forwards instead of backwards.
CRM System
The CRM system was the simplest system, offering basic functionalities that can be expected from such a system. Apart from being able to create companies, it was also possible to add persons to the system and link these to the corresponding company. This made it possible to have contacts for each customer, even describing their function, private phone numbers and so on. Furthermore, it was possible to create numerous so-called free fields, allowing for extra information to be added. This could be the reseller type, the corresponding account manager or any other information to be added in an instant. The second important functionality was registration of chances and expected revenues. Each company would be assigned an estimated chance of them becoming a reseller and generating a certain amount of revenue. These chances were all logged on an organizational level. Tasks assigned to employees were also linked to the different companies. This allowed the employees to see a list of all the tasks at hand, such as returning calls of customers, sending them some information and managing when the assigned tasks had to be completed.
Administrative System
The administrative system was one of the most important systems before the ERP implementation. This was where all the customer subscriptions were managed and invoiced, along with limited CRM functionality. Similar to the CRM system, companies that were billable and had subscriptions were registered. These companies just had their name, e-mail and in some cases bank account number registered. Even though the information within these instances was limited, it had to be entered manually. This allowed for errors in data similarity, which frequently happened.
In order to make sure all invoices were generated correctly, each product that had to be billed was present in the system. So not only customers, but also each and every product had to be in the system in order to be billed. In addition to this, there had to be products for each billing cycle, e.g. a product for billing by month, a product for billing by year and so on. Again, these products were already present in a different system.
The last and most important functionality was subscription management and automated billing of these subscriptions. Each customer present in the administrative system had to have at least one subscription, based on 1 or more products. Depending on the billing cycle set for the customer in question, e.g. 14 days in advance, a concept invoice would be generated. The Financial Manager would check these invoices, edit them where necessary and make them permanent. Editing invoices could be necessary for subscriptions with variable amounts, such as storage space in use. After they were made permanent an email would be sent to the customer with the invoice and all the necessary information such as company bank account numbers. As soon as a customer paid the invoice, it would automatically be matched by a link between the administrative system and the bank, eliminating manual work.
Customer Portal
The portal used by customers was their central environment. The website contained a login button where customers could login using their login credentials, which were sent to them as soon as their customer account was created in the backend. After logging in they could view the customer dashboard, which contained a number of their most recent orders. Also, important related information such as order status, date of ordering and the type of subscription was displayed. Furthermore, they had the opportunity to navigate to different sections within the portal such as an overview of all their orders, an address management view and a custom page that linked to all of the individual server backends of the different types of software the company carried. Logging in also gave them access to a second functionality: the webshop. This allowed customers to quickly put in orders for subscriptions without the need to call or email the company, increasing efficiency and reducing time needed to process orders.
Website backend
The last item was the website backend, only accessible to employees. The backend contained everything related to the processing of the customer subscriptions. All products and categories were managed, containing all the information needed to give the support department enough information when taking care of the software side. The same customers present in the administrative and CRM system had to be created here as well, creating even more room for potential mistakes when copying data manually. Each subscription order was registered to a customer and contained all related information such as products, special prices and optional remarks. Each order could have one of 30 statuses, mostly used for internal procedures. However, some statuses also sent emails to customers to notify them of certain events. For example, login credentials for the online backup software were communicated by first entering them in custom fields in the order. Putting the order on a certain status would then send out the email to notify the customer his account was active and he could login with the credentials communicated in the email.
3.1.3 Issues that came up during implementation of the new ERP system
During the implementation of the ERP System several issues came up. Some of these had already been predicted by looking at company processes and systems present beforehand and could be acted upon accordingly, but others only arose during the implementation itself. This took time and in some cases money to fix. Before the actual implementation started, extensive research was done with regard to the ERP system. The possibilities were checked and compared to the current systems and even a number of courses were followed. This was all done to obtain maximum knowledge about the future system and to be able to predict issues that might come up during the implementation, as described above. Changing the implementation process accordingly allowed solving some of the issues before the system went into operation, increasing its usefulness. In Table 2 (on the following page) all the issues that came up are listed, sorted into the area of the ERP system they occurred in or were predicted to be in.
Table 2 - Issues encountered in Use Case ERP
Subsection Issue description
General
Number sequences could only contain 8 characters instead of 9 No possibility for HTML emails, only basic layout
Depending on which email being sent out no possibility for variables
No autocomplete, making selecting customers or other information quite extensive
A lot of fields and screen when creating companies or customers that cannot be hidden. Makes the process a lot slower No field level authorization, way too much information available depending on employee role
CRM
No possibility for task import No possibility for document import
Very basic detecting for double entries, so it was very possible to have two similar company or person names with just a capital character difference
Very cumbersome procedure for adding contacts to companies, having to first create a person in CRM and then linking them to the company
Lots of unnecessary steps involved in creating CRM instances, making it tedious
Address changes have to be made by giving in a change of location and a date. Mistaken are easily made
3 types of instances for companies. Can be just CRM, can be a company that has subscriptions and a company that has been billed. Again, makes it tedious and easy to forget which type you have to use when creating a company
Finance / Subscriptions
Multiple types of discounts, with one overruling another and the other eliminating organization level discount. This allows for easy errors and is quite difficult to use
Due to above issue inflation correction is made difficult and discounts in percentages instead of set amounts have to be used. This costs the company several thousands of euro’s depending on the subscription
Importing subscriptions almost impossible due to naming of products. More than 100 had to be invested in entering all subscriptions and checking them for inconsistencies
Invoices did not display a lot of information. A lot of custom fields and calculations had to be thought out and inserted into invoice reports
Issues with rounding off totals on the invoice. Lack of good explanation in the application Price related information cannot be shown on the subscription overview
Changes product prices requires navigating up to 4 screens, making it a slow and tedious process Dates are not automatically calculated when creating subscriptions, allowing for easy errors No possibility to send subscription confirmation (similar to order confirmation)
Customer Portal
Limited editing capabilities, so customer have to conform to what can be offered instead of being able to add in functionalities at the customer request
Layout can also not be edited, making for quite standard and not very good looking page layouts Non-responsive portal, using on a tablet of smartphone is not very customer friendly
Adding new information to the customer overviews for subscriptions, products herein etcetera not possible on field level. New pages had to be created, making navigation not very customer friendly
3.2 Analyzing the Singh and Wesson list
Using a modified checklist, based in the issues described above, an evaluation of the checklist was done. This modified checklist was created by comparing the issues that came up in the use case again the ‘general’ list of issues described by Singh and Wesson. These general issues came up by using the list of Nielsen’s ten heuristics (Nielsen and Mack, 1994). The issues that Singh and Wesson encountered when they used Nielsen’s heuristic are shown in Table 3 below.
Table 3 - General issues based on Nielsen's Heuristics
Heuristic Potential Usability Issues
Visibility of System Status
Error messages do not indicate in which field the errors occurred. There is no indication of the next group or step of actions. Users cannot see the current state of the system.
Match between System and Real World Terminology is very general but not specific enough to the user’s tasks.
Field prompts are indicated at the bottom of the screen and are very cryptic.
User Control There is no undo functionality.
No functionality to reverse current action.
Error Recovery
Error messages left experts feeling intimidated. Error messages did not convey the severity of the error. Error messages vaguely conveyed the cause of the error. Error messages included too much technical detail.
Error messages did not indicate how the errors could be corrected. Error Prevention System did not prevent the user from making the error.
There are no default values contained in the fields.
Memory Load There is no logical grouping of items.
Optional fields are not clearly indicated.
System Flexibility
The system did not support multiple level of users.
The system did not cater for novice users entering simple commands.
The system did not support the creation of short cuts for frequently performed commands.
There is no search functionality. Minimalist Design Screens are too cluttered with fields. Help and Documentation Help is not concise and clear.
Help navigation is different from system navigation.
To get the final version of the modified list, the issues that came up in the use case (see Table 2) were compared with the list of general issues (see Table 3). Some of the general issues were an addition to the issues from the use case and were embedded into the generalized list, which was based on the use case as described earlier. These issues have been marked in bold. The other issues, which either were too similar to one another or which were already in the issues derived from the use case were disregarded. After this, the issues derived from the use case were compared against each other and generalized, to increase their general usability for ERP implementations. Using a different use case revealed more additional issues with ERP implementations. The complete modified list is listed in Table 4 (on the following page).
Table 4 - Modified list based on comparison Heuristic Potential Usability Issues
Data structure Old and new datastructure has not been compared sufficiently Complex datastructures are present in the system
Task Support
Not all data from the old system can be imported into the new system
Processes not analyzed well enough, not enabling efficient completion of tasks Large amount of cross referential relations in the system
Some calculations are problematic, requiring extensive workarounds
Mismatch between functionality in old system and new system, not improving productivity Learnability Interface complexity makes it difficult to remember
Customization Screens are too cluttered with fields and steps Limited customization for customer frontend
Responsiveness
System did not prevent the user from making the error.
Error messages did not indicate how the errors could be corrected.
No autocomplete functions present to ease selection of information such as customers or products Presentation Visual layout does not contain all essential information
Visual layout is not adapted to mobile devices
4. Evaluation of the modified list
During the interviews, the modified list from Table 4 was compared with the list Singh and Wesson came up with after creating their ‘ERP specific heuristics’, shown earlier in Table 1.
4.1 Evaluation set-up
Evaluation of the modified checklist took place by interviewing four ERP consultants from the AFAS Software Consultancy Team in Leusden, The Netherlands (see section 4.2.1 for detailed information). The interview was set up in a semi-structured way. By having a fixed set of questions about the issues we wanted to discuss and get ratings for, we could steer the interview in a logical order but give interviewees freedom to motivate their ratings.
4.1.1 Method and setup
By giving the interviewees the opportunity to compare their own implementations against the issues, it was possible for them to motivate the ratings and arrive at new ideas. During the interview, the interviewees were asked to think about their last projects implementing an ERP system and rate the issues according to their usefulness when compared with these projects.
Because the consultants do tens of implementations each year, these ratings were not limited to one type of implementation such as in the use case (described in section 3). Each implementation they do can be in a different domain, from IT to retail, giving them much more experience across domains and giving results across this larger set of domains as opposed to Singh and Wesson.
Before the actual rating and discussion of the issues began, a small introduction was done where the participants explained something about themselves and we explained the study and way the interview would take place. This has not been taken into the results. We also discussed that the whole research was set up because we experienced
the lack of a good checklist during our own implementation of an ERP system.
They were asked to walk through both lists and compare each potential usability issue against their own last projects. By doing this they could shed light on each issue, if it was relevant and how it might help them, predicting and thinking about potential problems. After each heuristic, a conclusion was be made if they missed anything or had any items that are superfluous and could be taken of the list. At the end of the interview they made their conclusion and elaborated on which list might be the better, or perhaps a combination of the two lists. All ratings were given on a Likert-type scale (1 = Not important; 5 = Very important).
4.1.2 Population
All interviewees (I1 to I4) were AFAS Consultants or Project Managers. Two of the interviewees (I1 and I4, both 25 years old) both had about 2 years of experience in ERP implementations with I1 also having about a year of experience as a process consultant. The other two interviewees (I2, 41 years old, and I3, 35 years old) both had over a decade of experience in ERP implementations and consultancy. I2, with 10 years in ERP consultancy and another 5 years in software consultancy for a previous employer had the most experience. I3 had almost 8 years of experience in ERP consultancy as a consultant and project manager. He also had over 5 years of experience in sales and support, giving him the knowledge to interpret and lead ERP system implementations even better. Because they were all consultants in ERP systems, they had extensive experience in different projects and domains. The systems they could use when comparing the issues of both the modified and the Singh and Wesson list to what they encounter during their work were varying enough to judge the issues correctly on their importance across all different domains they encounter. The interviewees mentioned implementations at large companies that do transport by trucks and have over 800 employees to smaller companies who build software with 10 employees. Even large healthcare facilities employing hundreds of employees, who have board meetings about each and every minute detail of the implementation, were discussed. This supports the claim of these consultants having knowledge on a broad range of domains and cases.
4.2 Results
The results from the ratings of both heuristics and issues have been put in table 5 (on the following page and also visible in Appendix A). Next to each issue and heuristic not only the rating per interviewee (I), but also the average, mean and median have been calculated and listed.
Table 2 - Interview results AV
G MD Std. Dev I1 I2 I3 I4 Heuristic Potential Usability Issues Modified checklist I1 I2 I3 I4 AVG MD Std. Dev
3,75 4,00 0,50 3 4 4 4 Data structure
Old and new data structure has not been compared sufficiently
3 5 4 4 4 4 0,82
Complex data structures are present in the system
4 4 4 3 3,75 4 0,50
4,13 4,00 0,25 4 4 4,5 4 Task Support
Not all data from the old system can be imported into the new system
4 4 3 4 3,75 4 0,50
Processes not analyzed well enough, not enabling efficient completion of tasks
5 5 5 5 5 5 0,00
Large amount of cross referential relations in the system
2 3 5 3 3,25 3 1,26
Some calculations are problematic, requiring extensive workarounds
5 3 3 3 3,5 3 1,00
Mismatch between functionality in old system and new system, not improving
productivity 4 4 4 4 4 4 0,00
3,25 3,00 1,26 2 5 3 3 Learnability Interface complexity makes it difficult to remember
2 5 3 4 3,5 3,5 1,29
3,25 3,00 0,50 3 3 4 3 Customization
Screens are too cluttered with fields and steps
3 3 4 2 3 3 0,82
Limited customization for customer frontend 3 3 4 4 3,5 3,5 0,58
3,45 3,00 0,90 3 3 4,8 3 Responsiveness
System did not prevent the user from making the error.
2 3 4 5 3,5 3,5 1,29
Error messages did not indicate how the errors could be corrected.
5 3 5 4 4,25 4,5 0,96 No autocomplete functions present to easen selection of information such as
customers or products 2 3 5 4 3,5 3,5 1,29
3,00 3,00 0,82 3 2 4 3 Presentation
Visual layout does not contain all essential information
2 3 4 3 3 3 0,82
Visual layout is not adapted to mobile devices
5 2 4 3 3,5 3,5 1,29 AV G M D Std. Dev I 1 I 2 I3 I
4 Heuristic Potential Usability Issues Singh and Wesson
I 1 I 2 I 3 I 4 AV G M D Std. Dev 2,94 3,00 0,13 3 3 2,75 3 Task Support
Terminology used is not consistent with that of the user.
2 3 2 3 2,5 2,5 0,58
System does not enable efficient completion of tasks.
2 2 3 2 2,25 2 0,50
System does not improve productivity for novices.
4 3 2 3 3 3 0,82
System is not easy for novices to use.
4 3 3 3 3,25 3 0,50
3,20 3,00 0,54 4 3 2,8 3 Learnability
Long introduction needed to learn how to use the system. 3 2 3 3 2,75 3 0,50
Not easy to become skillful with the system within a short period of time.
3 3 3 2 2,75 3 0,50
Some aspects of the system make it intimidating and complex to use.
4 3 2 2 2,75 2,5 0,96
1,63 1,5
0 0,75 2 1 2,5 1 Navigation
Information is not easy to find.
1 1 3 1 1,5 1 1,00
There is insufficient help for finding the correct information and transaction
screens. 2 1 2 1 1,5 1,5 0,58
There is no form of guidance within the system to aid the user when completing
a business process. 2 2 2 1 1,75 2 0,50
There is no search functionality.
1 1 4 1 1,75 1 1,50
Navigation does not support the different types of users.
1 1 2 1 1,25 1 0,50
Next sequence of steps is not indicated.
3 1 1 2 1,75 1,5 0,96 1,50 1,00 1,00 3 1 1 1 Customization Limited customization.
3 1 1 1 1,5 1 1,00
2,19 1,88 1,28 4 1 1,75 2 Presentation
Visual layout is too complex.
3 1 2 2 2 2 0,82
Output is not easy to understand and interpret.
3 1 1 1 1,5 1 1,00
Output is too complex. 4 2 2 2 2,5 2 1,00
The UI of the system is not very intuitive.
Results from the interviews when speaking about the lists were overwhelmingly positive as can be seen in Table 5 on the previous page. For each question the rating was noted per participant (n = 4) and the average rating (A), median (MD) and standard deviation (SD) per question were calculated. For each heuristic A, MD and SD were also calculated to give a good indication about the heuristic as a whole, which was rated individually.
When asked to rate the modified list as a whole, both I1 and I2 recognize the added value for their proceedings as ERP Consultant. I1 stated, “I would really like it if customers started thinking about some items beforehand, such as data structure and their processes. It would really help them streamline the preparation and the implementation itself”. She also mentioned, “Some customers really need this” and “It would really help to have a checklist which we can go through with the customer. Then we will know where they are in the process and what they came across at a glance. I2 also endorsed the list and said, “These are the things I worry about most, it is a very recognizable thing. It is not just your own experience that is the reason I rated so high”.
After being asked about the entire Singh and Wesson list a number of interviewees make a clear distinction between the two. I2 said “I think they are both important. Your list at the beginning of the implementation, and this list after the implementation”. However, purely looking at grades he said the modified list was the most important.
I3 stated, “The top list is the most interesting of the two. The top list requires thinking about things in advance. The second list seems to indicate that you have ‘no-no’s in your company. And the question is if you should want that or if you have to take your employees to the next level”. Lastly he very clearly stated “I will definitely be using elements from this interview in my next implementations”.
I4 started off by saying “The generic list is very, very generic. You can interpret it in many ways. The modified, specific list is something you can really use. Although some items are, as we discussed, dependent on the customer and person sitting opposite you”. He also mentioned they need to use this if they want to make the most out of their consultancy days, finally choosing the modified list as best and stating “I see many similarities to things I already do with my newer projects, derived from experience”.
4.3 Interpretation of results
To support the ratings given by interviewees, all the heuristics and issues were discussed. The ratings were organized per heuristic so both individual issues and the entire heuristic could be rated. The ratings were motivated and discussed in the sections below. The transcriptions of the interviews, which can be found in Appendix B, were used to evaluate and interpret the absolute ratings. The interview was coded in the exact same way as the lists were set up. The introduction and final answer about lists were marked so they could be used to support anything said in the entire interview. Each heuristic was coded as a section so the heuristics could be compared across lists. Finally, each rating was also marked so these could be compared to the ratings and the statements made by interviewees.
4.3.1. Ratings Data Structure
Data Structure was rated second highest among all heuristics (A = 3,75; MD = 4; SD = 0,5). When asked about the comparison of old data structures to the new data structures in the system not being done sufficiently, all four participants agreed that this was an issue that occurs quite often (A = 4; MD = 4; SD = 0,82). I1 said, “A lot of companies do not think about this” and “They need a good view of what is in the system to do this”. Both I2 and I3 confirm this as well, as does I4 who agrees that, “Companies need to start thinking about this after an intake”. However, I1 did only rate the issue a 3 out 5, where as the other interviewees rated a 4 or even a 5. As a consultant it is partly her job to make sure implementations are done correctly. So even if the customer does not think about old and new data structures, she can steer them into the right direction and make sure some thought is given to it, even though this is not as efficient as the customer doing the majority of the work. But it did result
in a lower rating.
Complex data structures being present in the system is also one of the highest rated issues on the list (A = 3,75; MD = 4, SD = 0,5). I2 agrees that similar to the issue above, thinking about the consequences is very important and not always done.
4.3.2 Ratings Task Support
Task Support was the absolute highest rated heuristic (A = 4,125; MD = 4; SD = 0,25). The first issue in this heuristic ‘Not all data from the old system can be imported into the new system’, was rated a 4 by three of the interviewees (A = 3,75; MD = 4, SD = 0,5). I1 stated, “If the customer is not aware of this, this may become a really big issue” but she also said it is dependent on the type of company. I2 said, “Even if it is not always seen as a big problem, we discuss it anyway”. Both other interviewees discuss that it has to work in the new system, so it is worth taking the time to fill import sheets and make sure all information is clean and present.
The second issue in Task Support, ‘Processed not analyzed well enough, not enabling efficient completion of tasks’ was the issue rated highest amongst both lists. With all participants rating this 5 out of 5 (A = 5; MD = 5, SD = 0) it is by far the most important issue of all. I2 explains that the processes are the basis for the entire implementation. “This is the most critical item to the whole implementation. We want the customer to work within the standards of the system, but we try to think alike”. Both I1 and I3 elaborate on the fact that an ERP implementation is a good opportunity to improve processes and increase efficiency if they are thought about well enough, even though it might be a step that could result in an employee making himself superfluous. The last interviewee I4 also agrees that it is important for the customer to think about the new system and how he will shape his processes. “You don’t want workarounds”.
The issue on cross-referential relationships was rated a fair bit lower with varying ratings (A = 3,25; MD = 3; SD = 1,26). I1 said, “It is my job to overcome this and explain how it works in the system”. Similar to comparing old and new data structures she felt it is largely her job, which it of course is, giving lower ratings than the other interviewees. I2 also said “I try to find this out during the intake, a customer cannot know everything immediately, especially about these complicated issues”. I3 does not agree and rates this issue a 5, especially because it is important to know about these relations to prevent mistakes. Such a mistake could be “giving away large discounts because there are different ways discounts work in the system.” I3 said. “If you have a product you usually sell for €200, you now sell for €120 and also give quantity discounts on”, he mentioned.
When asked about problematic calculations, ratings were again on the low side (A = 3,5; MD = 3; SD = 1). However, I1 rated the issue a 5. She states, “I rate this a 5, not because of the issue itself but because of the processes that revolve around it. You have to adapt your processes to get the result you want”. During her work as a consultant for Oracle, which we spoke of during the introduction, she was working on processes as opposed to functionality. This gave her the insights to see that some calculations might be an integral part of a process, having dire consequences if carried out wrongly. But I2 and I3 rate the issue lower, 3 out 5, and only said, “You need to be aware of what goes on in the system, but that is all”.
The last issue in the Task Support heuristic, ‘mismatch between functionality in the old system and new system, not improving productivity’ was unanimously rated a 4. I1 said, “Depending on the size of the business this can really be an issue”. Both I2 and 3 just stated, “It is very important”. I4 was more descriptive and elaborated that it is very important that this be looked at before the implementation so no issues arise during an implementation, causing loss in time and therefore money.
Similar to our modified list, the Singh and Wesson list also contains a heuristic for Task Support, which was rated second highest in this list (A = 2,94; MD = 3; SD = 0,125). For efficient completion of tasks knowledge was the only variable mentioned during the interview. The same goes for the next three issues on the list too. For
every issue the only item mentioned by the interviewees is the fact that knowledge is required, as discussed during the introduction. I1 clearly stated, “Without knowledge you are in very big trouble” where I2 mentioned the system “Not being idiot-proof” during the review of the issue ‘System is not easy for novices to use’. I3 even compared it to a driver’s license. You are allowed to drive a car because you have a license. “This means you have sat next to an instructor at least a few times” he stated.
4.3.3 Ratings Learnability
Learnability consisted of only one issue, interface complexity being difficult to remember, and was rated low on both the issue and heuristic as a whole (A = 3,25; MD = 3, SD = 1,26). I1 explained, “Even though everyone has done something else, from pilot to student, the system is very easy to use and to get to know. You just need the knowledge of workings and then even after a month of vacation you will be at your old level within a week”. I2 did mention “It is important that there are not too many steps because we want the customer to do it themselves”, but both I3 and I4 said “Once you know the system it is not relevant because everything becomes so easy and straight-forward to do”. The ratings of this issue were varying amongst the interviewees. All of the interviewees deal and dealt with different companies and different domains. Where some users might think the system is easy to use, others might think it is very difficult to use. This explains the varying ratings and corresponds with what was discussed with the interviewees.
The Learnability heuristic is the highest rated heuristic in the Singh and Wesson list (A = 3,2; MD = 3; SD = 0,54). Similar to Task Support being very sensitive to the knowledge of the person, Learnability is also mostly dependent on the person himself as is the case with the modified list ratings on Learnability. When reviewing the issue ‘long introduction needed to use the system’ (A = 2,75; MD = 3; SD = 0,5), I1 said, “This really depends on the customer”. I3 did criticize the system a bit by saying that “The system might not be set up properly in this case”.
4.3.4 Ratings customization
The Customization heuristic in the modified list contains only two issues which are both rated similar (A = 3,25; MD = 3; SD = 0,5). I1 agreed that customization is limited but also said “This will become less of an issue when the new features are released beginning of 2015”. This goes for I3 too. All interviewees agree that field level authorization is not possible but that there are enough options to make this less of an issue, rating it on the low side (A = 3; MD = 3; SD = 0,81). Both I2 and I4 disagree with the limited customization and state that they are quite proud that they can do this level of customization in a standard package, which suffices for most customers.
When speaking about the Singh and Wesson Customization heuristic (A = 1,5; MD = 1; SD = 1), it is hardly discussed. I3 is the only interviewee who elaborates saying “It is a bit limited, but most customers are happy with what they can do”, still rating 1 out of 5.
4.3.5 Ratings Responsiveness
The heuristic Responsiveness, the manner in which the system gives feedback to the user, was rated third across all heuristics (A = 3,45; MD = 3; SD = 0,9). With the results per issue being spread, with error message indication being the exception (A = 4,25; MD = 4,5; SD = 0,96), there is variation between the interviewees. Just like it occurred with the learnability heuristic, responsiveness also is a very user dependent heuristic. I1 indicated, “No one has ever mentioned no prevention of errors being weird”, but I4 agreed that if the amount of messages is limited to certain functionalities it could prevent data pollution.
All interviewees but one agree that ‘error messages did not indicate how the errors could be corrected’ is a large issue with I1 even stating “It is a huge one” and “99% of users do not understand the error messages”. Both I3
and I4 talked about the level of detail in the error messages that are currently present and said, “You get a large piece of system error which no one understands, we would rather see a nice error messages that indicate where the problem is”.
Although their actual ratings on the autocomplete function not being present are not very uniform (A = 3,5; MD = 3,5; SD = 1,29), all interviewees agree it is good to have but “it is not a showstopper”. I4 said, “I wonder how much you miss not having it”. With the interviewees having different experiences and different visions on certain parts of the ERP system, it is logical they might feel that autocompleting is more or less important.
4.3.6 Ratings Presentation
The presentation heuristic is the lowest rated heuristic (A = 3; MD = 3; SD = 0,82) in the modified list. Both I1 and I3 said “Views can be adapted” when views in the ERP system not containing all information was discussed and I3 even stated, “I don’t really know if this is important”. All interviewees also mentioned that “There are some possibilities for mobile devices layout”, but they all also get remarks that real responsive layouts are yet to be added on the customer frontend. Their ratings on this are diverse, but with the responsive functionality coming within a few months some of the interviewees feel that the issue is not really an issue anymore.
Presentation (A = 2,19; MD = 1,88; SD = 1,28) from Singh and Wesson starts with the visual layout being too complex. Both I1 and I2 said exactly the opposite: “Most people say it is very simple”. I3 did agree that some people think it is too complex, but still rated it a 2. I1 did rate a 3, saying “The average user might think it is complex, but that also is related to terminology”.
The issues related to output being not easy to understand and being complex I2, I3 and I4 all refer to the analysis functionality within the system. “You can make your own output” I2 said. I3 stated, “Some output is very difficult, others are very easy”. However, he did say “I never come across output being not easy to understand”. The last issue ‘The UI of the system is not very intuitive” is clearly not right when speaking to this population of consultants. Both I2 and I3 just said: “Yes it is!”
4.3.7 Ratings Navigation
Navigation, solely present in the Singh and Wesson list, was rated second lowest (A = 1,63; MD = 1,5; SD = 0,75). The two issues related to finding information were both rated low with an average of 1,5. I1 mentioned that “This is what we have a Knowledgebase for” in both the issues. I2 and I4 said the exact same thing, again referring to the online Knowledgebase where I3 just said, “I hardly see this issue”, still rating it a 3 out 5 as opposed to the other interviewees who gave a 1 out 5. He also mentioned the knowledgebase and having to show customers description of issues and configurations are in there before they use it, giving some explanation about his deviating rating.
‘There is no form of guidance within the system to aid the user when completing a business process’ was rated highest among all Navigation issues (A = 1,75; MD = 2; SD = 0,5). I1 said “This is true, but most of the processes can be found in the Knowledgebase”, rating the issue a 2. I2 seconds this and gives the same remark and rating. Again, I3 mentions the Knowledgebase with a real life example he used to answer a customers question when they did not know how to set up a certain process. The answer was literally in the Knowledgebase step by step.
When asked about the search functionality I1, I2 and I4 just say “This is most certainly there”, rating it a 1. I3 however, said, “It is there, but I still will give this a 4. It is not a good functionality and it needs improvement. It can be much more efficient”.
The same goes for supporting different types of users (A = 1,25; MD = 1; SD = 0,5). All interviewees agree that the system is built specifically to support more than one type of user.
5. Discussion
This study examined an existing usability checklist and how to improve this list, creating a better checklist that can be used to do ERP system implementation in a more effective way. The study was carried out by creating a new list with issues, which were derived from an existing use case. We took an existing research as an example and tried to improve on this, making it more specific and usable during the actual implementation. Interviewees were asked to compare the existing list to this new list and make a comparison based on their own experience. We found that the modified list contained a lot of similarities to the actual issues ERP consultants experience during their work and that this new list can really help them and especially their customers to prevent some of these issues from happening.
Considering the number of interviews and the single use case, it would have been possible to improve the list even further by exploring different use cases from different domains. In the interviews it was discussed that some implementations, such as the ones at healthcare institutions, are done in a very different way where the consultant has to do all the thinking as well. Using more of these use cases and domains could have resulted in a larger set of issues, allowing us to create an even more ERP specific list.
Another point of discussion is whether using two different sets of interviews could have made a difference. When used in combination with more use cases it could be of value. After receiving the feedback and ratings we could improve the list further and then re-evaluate it to see if we get the same results. However, this would only work if there were enough issues that can be changed or added, hence the combination.
6. Conclusion and future work
This study investigated the possibility to create a newer, better checklist that would allow ERP Consultants and customers alike to carry out the implementation of an ERP system in a more effective and thought out way so the number of usability issues can be minimized. The results of this study showed that the issues that occurred during a use case can be generalized to contain most of the issues a consultant encounters during his projects. Even though the answer might not be entirely applicable for all implementations and domains due to the limited amount of use cases, it showed to be a great addition to the work a consultant does and the progression of an ERP system implementation.
Future continuation of this study should tackle the items mentioned during the discussion. A larger pool of interviewees and use cases can be used to ascertain the modified list contributes even more to successful ERP implementations, giving customer and consultant alike an opportunity to save time and money and to succeed in implementing an even more user-friendly system.
Eventually, future work should lead to the customer doing the majority of the work in the ERP implementation, allowing the consultant to assist even better and give companies a much greater return on investment.
8. Acknowledgements
Many thanks go out to everyone who has supported me in achieving my wish of contributing the work ERP consultants do with their customers. Firstly, I would like to thank Dr. Frank Nack for all his help and his watchful eye during the progression of this thesis. His guidance and vision have been of the highest value and allowed me to create a complete document from start to end. Furthermore Drs. Hans Dekker, who acted as intermediary supervisor during the start of the thesis and Dr. Jacobijn Sandberg have my appreciation for their insights and critical vision. Also, I would like to thank my interviewees and their colleagues from AFAS
Software for their participation, insights and advice during the evaluation of the lists. Lastly, my thanks go out to colleagues, family and friends for always supporting me, encouraging me and giving their opinion on matters throughout the progression of this thesis.
9. References
Boudreau, M.-C. “Learning to Use ERP Technology: a Causal Model”. 36th Hawaii International Conference on System Sciences, p. 235-242. IEEE Computer Society, 2003.
Dix, A., Finlay, J., Abowd, G.D. and Beale, R. “Human-Computer Interaction Third Edition Edn”, Pearson Education Limited, 2004.
Hawking, P. and Mccarthy, B. “Industry Collaboration: A Practical Approach for ERP Education”. In Proceedings of ACE2000. Melbourne, Australia, 2000.
Hedegaard, S. and Simonsen, J.G. "Extracting Usability and User Experience Information from Online User Reviews". Proceedings of the ACM SIGCHI Conference on Human Factors in Computing Systems (CHI '13), p. 2089-2098. The ACM Press, 2013.
Iso. “Ergonomic Requirements for Office Work with Visual Display Terminals. Part 11: Guidance on Usability” 9241-11, International Standards Organization (ISO). 9241(11), 1998.
Lew, P., Olsina, L., Zhang, L. “Quality, quality in use, actual usability and user experience as key drivers for web application evaluation”. Proceedings of the 10th international conference on Web engineering (ICWE'10), p. 218-232. 2010.
Magal, S.R. and Word, J. “Essentials of Business Processes and Information Systems”. Wiley Publishing, 2008. Matthews, D. “Usability as an ERP Selection Criteria”. IFS, 2008. Retrieved from
http://ifs.datahost.com/shop/images/wp-usability.pdf. Last accessed on 09-03-2015. Nielsen, J. (2012). “Usability 101: Introduction to Usability”. Retrieved from
http://www.nngroup.com/articles/usability-101-introduction-to-usability. Last accessed on 09-03-2015. Nielsen, J. and Mack, R.L. “Usability Inspection Methods”. John Wiley and Sons Inc., 1994.
Nielsen, J., Norman, D. “The definition of User Experience”. Retrieved from
http://www.nngroup.com/articles/definition-user-experience. Last accessed on 09-03-2015.
Rogers, Y. and Sharp, H. “Interaction Design: beyond human-computer interaction” (2nd ed.). Chicester, West
Sussex: John Wiley and Sons Ltd, 2009.
Sanchez, J.L., Yagüe, A. “Competitive advantages of the ERP: new perspectives”. In Proceedings of the 11th International Conference on Product Focused Software (PROFES '10), p. 108-109. The ACM Press, 2010.
Scholtz, B., Cilliers, C., Calitz, A. “Qualitative techniques for evaluating enterprise resource planning (ERP) user interfaces”. Proceedings of the 2010 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists (SAICSIT '10 ), p. 283-294. The ACM Press, 2010.
Shneiderman, B. “Designing the user interface: strategies for effective human-computer interaction. Third Edition Edn”. Addison Wesley Longman Inc., 1998.
Singh, A. and Wesson, J. “Improving the usability of ERP systems through the application of adaptive user interfaces”. In Proceedings of 11th International Conference on Enterprise Information Systems (ICEIS), Milan, Italy. CORDEIRO, J. and J., F., 2009.
Singh, A. and Wesson, J. “Evaluation criteria for assessing the usability of ERP systems,” Proceedings of the 2009 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists (SAICSIT ’09), p. 87–95. The ACM Press, 2013.
Topi, H., Lucas, W. and Babaian, T. “Identifying Usability Issues with an ERP Implementation”. In Proceedings of International Conference on Enterprise Information Systems, p. 128-133. Miami, USA, 2005
Yeh, J.-Y. “Evaluating ERP Performance from User Perspective”. IEEE Asia-Pacific Conference on Services Computing (APSCC'06), p. 311-314. IEEE Computer Society, 2006.
Appendix A – Interview Results
AVG MD Std. Dev I1 I2 I3 I4 Heuristic Potential Usability Issues Modified checklist I1 I2 I3 I4 AVG MD Std. Dev
3,75 4,00 0,50 3 4 4 4 Data structure
Old and new data structure has not been compared sufficiently
3 5 4 4 4 4 0,82
Complex data structures are present in the system
4 4 4 3 3,75 4 0,50
4,13 4,00 0,25 4 4 4,5 4 Task Support
Not all data from the old system can be imported into the new system
4 4 3 4 3,75 4 0,50
Processes not analyzed well enough, not enabling efficient completion of tasks
5 5 5 5 5 5 0,00
Large amount of cross referential relations in the system
2 3 5 3 3,25 3 1,26
Some calculations are problematic, requiring extensive workarounds
5 3 3 3 3,5 3 1,00
Mismatch between functionality in old system and new system, not improving
productivity 4 4 4 4 4 4 0,00
3,25 3,00 1,26 2 5 3 3 Learnability Interface complexity makes it difficult to remember
2 5 3 4 3,5 3,5 1,29
3,25 3,00 0,50 3 3 4 3 Customization
Screens are too cluttered with fields and steps
3 3 4 2 3 3 0,82
Limited customization for customer frontend
3 3 4 4 3,5 3,5 0,58
3,45 3,00 0,90 3 3 4,8 3 Responsiveness
System did not prevent the user from making the error.
2 3 4 5 3,5 3,5 1,29
Error messages did not indicate how the errors could be corrected.
5 3 5 4 4,25 4,5 0,96 No autocomplete functions present to easen selection of information such as
customers or products 2 3 5 4 3,5 3,5 1,29
3,00 3,00 0,82 3 2 4 3 Presentation
Visual layout does not contain all essential information
2 3 4 3 3 3 0,82
Visual layout is not adapted to mobile devices
5 2 4 3 3,5 3,5 1,29
AV
G MD Std. Dev I1 I2 I3 I4 Heuristic Potential Usability Issues Singh and Wesson I1 I2 I3 I4 AVG MD Std. Dev
2,94 3,0 0 0,13 3 3 2,7 5 3 Task Support
Terminology used is not consistent with that of the user.
2 3 2 3 2,5 2,5 0,58
System does not enable efficient completion of tasks.
2 2 3 2 2,25 2 0,50
System does not improve productivity for novices.
4 3 2 3 3 3 0,82
System is not easy for novices to use.
4 3 3 3 3,25 3 0,50
3,20 3,00 0,54 4 3 2,8 3 Learnability
Long introduction needed to learn how to use the system.
3 2 3 3 2,75 3 0,50
Not easy to become skillful with the system within a short period of time.
3 3 3 2 2,75 3 0,50
Some aspects of the system make it intimidating and complex to use.
4 3 2 2 2,75 2,5 0,96
1,63 1,50 0,75 2 1 2,5 1 Navigation
Information is not easy to find.
1 1 3 1 1,5 1 1,00
There is insufficient help for finding the correct information and transaction
screens. 2 1 2 1 1,5 1,5 0,58
There is no form of guidance within the system to aid the user when completing
a business process. 2 2 2 1 1,75 2 0,50
There is no search functionality.
1 1 4 1 1,75 1 1,50
Navigation does not support the different types of users.
1 1 2 1 1,25 1 0,50
Next sequence of steps is not indicated.
3 1 1 2 1,75 1,5 0,96 1,50 1,00 1,00 3 1 1 1 Customization Limited customization.
3 1 1 1 1,5 1 1,00
2,19 1,88 1,28 4 1 1,75 2 Presentation
Visual layout is too complex.
3 1 2 2 2 2 0,82
Output is not easy to understand and interpret.
3 1 1 1 1,5 1 1,00
Output is too complex.
4 2 2 2 2,5 2 1,00
The UI of the system is not very intuitive.
Appendix B – Interview Transcription
Interview Marlies (I1)
Armand: Kan je wat vertellen over wat je doet en je laatste projecten?
Marlies: Halfjaar consultant bij Afas. Hiervoor Support en daarvoor Oracle in Ierland. Ook consultant, maar business, ging er anders aan toe. Nooit functionaliteit maar over processen waar klant tegenaan loopt. Nu heel veel gelijkwaardige werkzaamheden maar ook bezig met oplossingen. Momenteel heel veel net startende projecten en ook al een aantal optimalisatie trajecten. Bestaande implementaties, door iemand anders, zorgen dat alles gestroomlijnd wordt.
Armand: Dus dingen die nu niet goed zijn oplossen en zorgen dat alles goed gaat lopen?
Marlies: Ja dingen die nu niet goed zijn bekijken met processen en doorvoeren in de software. 1 van de redenen om dit werk te gaan doen. Het is leuk dat je nu met mij praat omdat de rest al veel langer consultant is en langer meedraait en ik nu met een andere blik binnenkom omdat ik bij een ander bedrijf heb gewerkt wat hetzelfde aanbiedt. Dus ik snap de verschillen.
Armand: Je weet wat er nog meer in de markt speelt en dat je die processen meer snapt en begrijpt dat dat cruciaal is.
Marlies: Ja dat doet het zeker. Gaan we ongetwijfeld op uitkomen.
Armand: Laten we maar beginnen met het eerste punt. Old and new datastructure not compared sufficiently. Kan een potentiele issue zijn. Liepen we tegen met bijvoorbeeld abo nummers bij koppeling met emails uitsturen. Datastructuur kan niet overeen omdat nummers 9 karakters waren terwijl deze 8 karakters moesten zijn. Die applicatie ging over zijn nek en werkte niet. Hadden we niet over nagedacht.
Marlies: Kleine dingetjes waar je overheen kijken.
Armand: Precies, net als in AFAS waar je meerdere instanties hebt zoals organisatie, verkooprelatie en debiteur. 3 keer hetzelfde, maar toch ook weer anders en net een stapje extra. Dat ene vinkje is het verschil tussen iets wel of niet kunnen vinden als je een abonnement aanmaakt. Toch een stuk datastructuur waarvan ik zeg je hebt je oude datastructuur die je in beeld moet brengen, dus je organisaties, abo, producten en al die zaken. En dan kijken wat kan ik meenemen naar dat nieuwe systeem en hoe gaat dat dan vorm krijgen.
Marlies: Ik denk dat dat een groter issue is bij grotere trajecten, want kleine bedrijven zijn eits flexibeler. En waar wij heel erg tegenaanlopen is dat veel bedrijven er niet over nadenken. Dat soort dingen kom je echt pas tijdens een implementatie achter en dan vooral direct in het begin. Inderdaad, wij zien veel dat de beslissing voor ERP implementatie word genomen op directieniveau en de mensen die met ons aan tafel zitten zijn gebruikers. Die hebben het hele traject niet meegemaakt en moeten gewoon starten. Ik zou zeker zeggen dat het een issue is, want waar wij tegenaan lopen is dat heel veel mensen denk Ok, maar hoe zit dat dan. En dat we dat dan moeten bespreken terwijl we al bezig zijn. Hoe meer je bespreekt hoe meer ze er over na moeten denken en hoe korter de implementatietijd.
Armand: Je hebt een vaste hoeveelheid dagen die je benut in theorie, dus je zou willen dat ze van tevoren zelf nadenken.
