4 Framework for measuring the degree of customization (DOC) 25
4.2 Developing the DOC measurement framework 26
4.2.2 Findings from ROC case study 27
Taking the development time as a metric to quantify the DOC, we now need to know how we can measure this in practice. To find this out, the findings from the case study research at ROC Eindhoven is used. The following research questions were formulated:
13.How do organizations keep track of the number and type of customizations in their ERP package?
14.How can one gather data on the degree of customization of an ERP package used in an organization?
28
To find the answers on the above stated questions, the following three people were interviewed within ROC Eindhoven:
- Change manager
- PeopleSoft developer/ technical application manager - PeopleSoft functional application manager
All three were asked whether ROC keeps track of:
- the customizations in their PeopleSoft HRMS package, and
- the amount of effort spent on the development of those customizations.
The answer to both questions was no. There were no configuration databases or any other records of any kind, in which we could find what exactly was customized and how much effort that has cost ROC. This lack of documentation resulted into the decision to design the framework in such way that the DOC can be quantified based on the judgment of the people within the organization who are responsible for maintaining the specific ERP package, which was in our case PeopleSoft HRMS.
At ROC Eindhoven, the people who are responsible for maintaining the PeopleSoft HRMS package are the same people as the ones we have interviewed. To make clear what was meant by customizations, the taxonomy which is used within Accenture Methodology for ERP customization, as presented in Table 7, was discussed with the interviewees.
Table 7: Accenture’s ERP customization taxonomy
Customization type Definition
Reports A listing or output of information in the system. Although there are
typically standard reports delivered that come with the packaged software, the term report is used in this methodology to refer to custom developed reports. These reports are custom designed and built to fulfill specific requirements.
Interfaces An interface defines the data and operations of an application or
component that uses it to interact with internal or external applications/components.
Conversions The conversion of data from the current format to the structure required
by the new application. A conversion can be performed via an automated program or can be completed manually.
Extensions A modification to the functionality of the packaged software application,
29
modifying the code of the packaged software.
Forms A customized output that is developed to meet a specific requirement. An
example of a Form is a customized purchase order form that will be printed.
Workflow The sequential flow of tasks and information in a business process.
When customizing the PeopleSoft HRMS package, specific PeopleSoft object types are modified (Landres et al. 2000). Thus next to the ERP customization types of Table 7, also an overview of all specific PeopleSoft object types, as presented in Figure 13, was discussed with the interviewees to find out whether they are able to estimate the DOC by assessing for each PeopleSoft object types whether there are any which are customized. For the exact definition of each object type and how these are modified, specific literature on modifying PeopleSoft objects were consulted (Landres et al. 2000).
Figure 13: PeopleSoft objects
Table 8 summarizes the important findings from the case study analysis. In the table we can see how the respondents were able to estimate the DOC using Table 7 and Figure 13.
30
Table 8: Findings from the ROC case study
Respondent Assessment based on ERP customization types (Table 7)
Assessment based on PeopleSoft object types (Figure 13)
Change manager Was able to mention whether there are any customizations in the system of a specific type but not exactly how much effort it has cost to built it
Was able to recognize some of the PS object types but could not tell which ones were modified to realize the customizations
PeopleSoft developer Was able to mention whether there are any customizations in the system of a specific type but not exactly how much effort it has cost to built it
Was able to recognize all the PS object types and mention how complex the modifications were in terms of simple, medium, complex and very complex
PeopleSoft functional application manager
Was able to mention whether there are any customizations in the system of a specific type and could also make an estimation of the development times
Was able to recognize some of the PS object types but could not tell which ones were modified to realize the customizations
Based on the findings as presented in Table 8, we can draw the following conclusions from the case study research at ROC Eindhoven:
- The PeopleSoft technical application manager has extensive knowledge of which PeopleSoft objects are modified and how complex those modifications are in terms of simple, medium, complex and very complex.
- The change manager and the PeopleSoft functional application manager can both assess the degree of customization by evaluating the customization types as mentioned in Table 7. However, they could not precisely determine the development time of each customization but were able to provide a good estimation of it.
The above stated conclusions are used in the next section, where the design process of the DOC measurement framework is discussed in more detail.