A formal approach to model changeability of Enterprise Resource Planning Systems

Transcription

1 A formal approach to model changeability of Enterprise Resource Planning Systems Laura Maruster University of Groningen, Faculty of Economics and Business PO Box 800, 9700 AV Groningen, The Netherlands J.C. (Hans) Wortmann University of Groningen, Faculty of Economics and Business PO Box 800, 9700 AV Groningen, The Netherlands Abstract Since they appeared, s attempted to solve many problems, and to bring considerable benefits. Despite the relevancy of the changeability topic in the context of s, changeability is poorly understood and a systematic conceptualization of ERP changeability notion is missing in the literature. Based on a literature search, the categories of the most prevalent changeability-related terms are included in a Finite State Machine model. This formalism is used to estimate the effort necessary for ERP change. Keywords: changeability, ERP implementation, Finite State Machine Introduction Since they appeared, s attempted to solve many problems, and to bring considerable benefits. On the one hand, vendors of s and other ICT professionals claim that these systems can be implemented without substantial changes, to a wide spectrum of organizations. There is much evidence to support these claims, because successful implementations of the same software can be identified in completely different organizations. On the other hand, changing s after their initial implementation requires huge effort (Brehm et al., 2001). Despite the relevancy of the changeability topic in the context of s, changeability is poorly understood and a systematic conceptualization of ERP changeability notion is missing in the literature. The research questions we aim to respond are: a) How is changeability of s reflected in the literature? b) Which of these aspects can be included in a model to formalize the changeability of s? c) How can such a formal model be used to operationalize change efforts? Methodology An inventory of all relevant changeability-related terms is created to conduct the literature review. Relevant articles were selected using terms from a keyword list containing the 1

2 items changeability, flexibility, adaptability, customization, modification, configuration, implementation, parameter, personalization, adoption. Next, the categories of the most prevalent changeability-related terms are included in a Finite State Machine model. This formalism is used to estimate the effort necessary for ERP change. Changeability related aspects By executing the literature search, a number of changeability-related aspects are found. The aspects mostly referred to in the context of ERP implementation and change are configuration, customization and modification. According to (Brehm et al., 2001) the first step in the implementation of the a standard software package for a particular customer, is configuration The configuration implies that software parameters have to be set in such a way to accurately support all business activities. In the configuration phase the types of users and their rights to use or modify information need to be distinguished and implemented accordingly. Also it has to be configured the functionality that users can access during the ERP sessions or transactions, and what logic is executed during these sessions. Often, after the initial configuration, the standard software packages are modified (Brehm et al., 2001). In general modifications alter the functionality of the software, but often, as a consequence, the set of parameters of the standard software will not heavily be affected. As a matter of fact we can conclude that configuration and modification may occur in parallel with minimum interactional effects. In conclusion, the terms configuration and modification can be summarized as following: configuration does not change the software, whereas modification does change the software. If in order to obtain an implemented it is necessary to execute a configuration, it is generally agreed to avoid modification whenever possible (Wagner et al., 2011). The third changeability-related term found in the literature is customization. Customization is used to denominate modification, but it refers also to notion of adding new software to the system which has been already implemented. Unfortunately a terminological confusion appears due to the fact that in SAP parlance the term customization is used with the meaning of configuration. Authors such as (Davenport, 1998) use also the term customization referring not only to code modification, but also to the selection and configuration of the package module. Because the term customization is prone to confusion, we will not use it in this paper. The following step following implementation, the configured standard software is populated with data. The data model structure (schema, metamodel) of this data is determined by the release of the standard software deployed and in some cases also by the scope. Data is essential for enterprises due to business reasons, and also they have to be available for many years. When a new implementation of a standard software package need to be executed, it is always a big problem to migrate the data. The deployed standard software packages undertake regularly updates to new service packs and releases. It is usual to have weekly or monthly migrations to new service packs. Also, new releases may be adopted once per one or two years. These upgrades 2

3 are subject of the normal maintenance contracts and mirror the best practices adopted in the industry. An essential difference between service packs and releases arises when the data model changes between subsequent versions. For illustrative purposes, let us label the standard software of an with an S; a new service pack does normally not change the data model of S, while a new release of S does. When S has not been modified, a change (upgrade) is relatively easy from the ICT perspective. The vendor provides software tools to migrate the software from version n to version n+1. Especially if the data model does not change (as with service packs), such changes are from an ICT perspective relatively straightforward. When the data model changes (in general this does not happen with service packs but it may happen with new releases), the data base also needs migration. Although vendors may offer data migration tools and services, this project will deem a lot of effort. After each new version released by the vendor, it is expected that a modification has to be re-done. A change makes data migration risky and expensive, if the modification has changed the data model. Eventually the change has to be undone, the upgrade has to take place and the change has to be redone again. State, state change and FSM formalization Our framework considers an as being subject of state changes, where the initial state is given by the first ERP implementation. Further, the state of an implemented is determined by five dimensions: configuration of parameters, modification applied to the software package, identification of the standard software package (by version and service pack), and the scope of the implementation (see the UML diagram from Figure 1). Implemented 1. Configuration 2. Version 4. Modification 3. Service Pack 5. Scope Vanilla Modified Single-Site Multi-Site Figure 1 UML representation of s. We denote a state of an implemented as a tuple of three dimensions . The first element of the tuple identifies the Configuration, Version and Service Pack; an implemented I will be configured k times, with a certain Version i and Service Pack j. The second element of the tuple states whether the ERP system is in a vanilla (V) or modified state (M), and the third item refers to the scope of implementation (Single-Site SS or Multi-Site MS). The state dimensions can vary as following: 3

4 A (re-)configuration increases the Implementation counter (k); A version upgrade increases the Implementation version counter (i); A service pack upgrade increases the Implementation service pack counter (j); A vanilla software (V) can be modified into (M), and vice-versa, a modified software M can be de-modified into a vanilla software V; The scope of the can be single-site (SS) or multi-site (MS). The default state of an implemented is denoted by . The initial implementation (k =1) is executed with a software version i 0 and service pack j 0 available in the market and provided by the vendor. The scope is single-site (SS). To represent formally state changes, we employ the notion of finite state machine (or finite automaton) (Anderson et al. 2006). The definition of a finite automaton is given below: Definition 1: A finite automaton A is defined by a 5-tuple (, Q, q 0, F, ), where: - is the set of symbols representing input to A - Q is the set of states of A; Q = { q = , k, i, j N, m {V, M}, d {O, A, S}, s {SS, MS} }; - q 1 Q is the start state of A; - F Q is the set of final states of A; - : Q P(Q) is the transition function, (q, x) P(Q), Q Q An implemented can be defined as a non-determinist finite automaton (Anderson et al. 2006). The set of input symbols is described by = { C, SP, V, VA, M, SS, MS }, where C stands for Configure, V for Version upgrade, SP for Service Pack upgrade, VA for Vanilla, M for Modify, SS for Single-Site scope restriction and MS for Multi-Site scope expansion. The set of states Q is provided by the set { q1, q2, q3, q4, q5, q6, q7 }. The initial state is q1, and stands for configured, q2 for with SP upgraded, q3 for with Version upgraded, q4 for Vanilla, q5 for Modified, q6 for Single-Site and q7 for Multi-Site ERP system. The set of final states F is {q1, q2, q3, q4, q5, q6, q7}. To model the transition function, rules are formulated for every symbol read. For example, a reconfiguration of an is modeled by reading the symbol C and employing the rule: read C ( Configure ) : This rule states that when a configuration took place, the implementation counter I is incremented to k+1 ( software version is i and service pack j). Note that modification m and scope s dimensions remain unchanged. For example, I 12 (3.H) means that 12 configurations took place and the current implementation is done with version 3, and service pack H. 1. q 1 is the start state, thus q 1 = ; 2. (q m, x) = q n, x Σ, m, n {1, 2, 3, 4, 5, 6, 7}, m, n N ; 4

5 3. read C ( Configure ) : ; 4. read SP ( ServicePack ): ; 5. read V ( Version ): ; 6. read M ( Modify ): ; 7. read VA ( Vanilla ): ; 8. read SS ( Scope Single-Site ): 9. read MS ( Scope Multi-Site ): We notice that transitions involving changes of type Version, Modify and Scope will always imply a (re-) configuration (and therefore the counter k is incremented). The transition function is given by the following set of transitions: { (q1,c) = q1, (q1,c) = q3, (q1,c) = q4, (q1,c) = q5, (q1,sp) = q2, (q1,v) = {q3, q1}, (q1,va) = {q4,q1}, (q1,m) = {q5,q1}, (q1,ss) = {q6,q1}, (q1,ms) = {q7,q1}, (q2,c) = q1, (q2,sp) = q2, (q2,v) = {q3,q1}, (q2,va) = {q4,q1}, (q2,m) = {q5,q1}, (q2,ss) = {q6,q1}, (q2,ms) = {q7,q1}, (q3,c) = q1, (q3,sp) = q2, (q3,v) = {q3,q1}, (q3,va) = {q4,q1}, (q3,m) = {q5,q1}, (q3,ss) = {q6,q1}, (q3,ms) = {q7,q1}, (q4,c) = q1, (q4,sp) = q2, (q4,v) = {q4,q1}, (q4,va) = {q4,q1}, (q4,m) = {q4,q1}, (q4,ss) = {q6,q1}, (q4,ms) = {q7,q1}, (q5,c) = q1, (q5,sp) = q2, (q5,v) = {q5,q1}, (q5,va) = {q4,q1}, (q5,m) = {q5,q1}, (q5,ss) = {q6,q1}, (q5,ms) = {q7,q1}, (q6,c) = q1, (q6,sp) = q2, (q6,v) = {q3,q1}, (q6,va) = {q4,q1}, (q6,m) = {q5,q1}, (q6,ss) = {q6,q1}, (q6,ms) = {q7,q1}, (q7,c) = q1, (q7,sp) = q2, (q7,v) = {q3,q1}, (q7,va) = {q4,q1}, (q7,m) = {q5,q1}, (q7,ss) = {q6,q1}, (q7,ms) = {q7,q1}, } Remark1: Transitions (q1,c) = q1, (q1,v) = q4, are superfluous as by default an implemented is always configured, with vanilla software and single-site. Remark2: The reading of symbols V, M, VA, SS, and MS, implies also reading a symbol C; in other words a version change, modification (de-modification) and scope change imply a reconfiguration. Illustration To illustrate how the finite automaton works let us consider a sequence of input symbols C M V MS V. Then the automaton trajectory recognizing this sequence is described by the following diagram in shown in Figure 2. 5

6 C1 M2 M2 V3 C3 q1 C4 MS4 C5 q5 q3 q7 V3 MS4 Figure 2. Example of an input sequence C M V MS V read by the finite automaton A. The numbers associated with symbols (on arcs) denote the step number. The automaton trajectory formed by transitions can be described by employing rules: Step1: (q1,c) = q1 Step2: (q1,m) = {q5,q1} Step3: (q5,v) = {q3,q1} Step4: (q3,ms) = {q7,q1} Step5: (q7,v) = {q3,q1} We notice that the initial input sequence C M V MS V has expanded into the trajectory C M C V C MS C V C. Looking to the state description is possible to explicitly identify the sequence of changes. This result can be also used to estimate the effort needed to perform the sequence of changes. For example we can estimate the effort by assigning to every state change a cost (represented as complexity index). We can formalize this as a function t : Q N, which assign to a state change a natural number representing the cost (complexity) associated with that type of change. For illustration purposes, we consider that transitions are associated with costs as following: a C (configuration) yields 2 units of complexity, an M (modification) yields 3 units, a V (vanilla) yields 1 unit and MS (multi-site) yields 1 unit. Then in case above we get a total of 16 units of complexity: Step1: t(q1,c) = q1 = 2 Step2: t(q1,m) = {q5,q1} = Step3: t(q5,v) = {q3,q1} = Step4: t(q3,ms) = {q7, q1} = Step5: t(q7,v) = {q3,q1} = 1+2 Let us now illustrate a realistic situation of state changes for an implemented ERP system. Example: Consider a manufacturing company ABC who has installed the Version release i of standard software package S i (for simplicity reasons, we do not refer to the service pack subscript j, since service pack version is not relevant in this context). However, ABC wants to improve its warehousing functionality. The vendor of S 6 V5

7 announces, that improved warehousing functionality will become partially available in release i+1 and fully in release i+2. Because the release cycle is bi-annually, it will take four years before the desired release R n+2 is available. Accordingly, the company ABC has a number of options, corresponding to a series of state changes: Option 1: (1) Apply a modification M to S i, extending the standard software with the full required functionality; (2) Migrate S from modified S i to S i+2 when S i+2 becomes available. Formally, Option 2: (1) Wait until S i+1 becomes available and then migrate S i to S i+1 ; (2) Apply a modification M to S i+1 extending it with the remaining required functionality; (3) Migrate from the modified S i+1 to S i+2 when S i+2 becomes available; Option 3: (1) Wait until S i+1 becomes available and then migrate S to S i+1 ; (2) Migrate S from S i+1 to S i+2 when the new version becomes available; Option 4: Migrate S from S i to S i+2 when S i+2 becomes available In the example above, there are more options possible. For illustration purpose, these options are sufficient to show the concept of state change (each of the above steps) and the concept of change path (each sequence of steps, or option). Conclusions In order to answer the first research question, we reviewed the implementation options mostly used in literature to denominate a change of the, such as configuration, customization and modification. We proposed a state-based changeability conceptualization using the finite state formalism. The proposed formalization enables to trace explicitly the sequence of changes. In this way, it is possible to have an estimation of effort needed when following a certain change path. The amount and sequences of configuration and/or modification of the ERP implemented software, combined with other components influencing a state change, will impact technology performance measures. Let us consider flexibility as an example, which can defined as the ability of a system to react to external changes (Pui Ng et al., 2002). According to (Shang&Seddon, 2002) framework, we learn that flexibility is a capability of the IT infrastructure, when systems are customizable and configurable, but the exact relations among these concepts are unclear. Using the proposed state-based formalization the relations 7

8 between changeability-related aspects are more precisely depicted. Our formalization enables to trace explicitly the sequence of changes. Therefore it can be used by practitioners as an instrument to understand better what ERP changeability is. Our approach can be used to estimate the effort needed for planned changes, and decisions can be made regarding the choice of the most appropriate change path. In this paper we provided a synthetic measure of complexity for effort of change or costs. In further research we aim to determine the costs more realistically based on empirical grounds. Moreover, we intend to assess the usefulness of the approach by considering a number of ERP implementation projects. References Brehm, L., Heinzl, A., Markus, M. (2001), "Tailoring ERP Systems: A Spectrum of choices and their Implications", 1-9. Davenport, T.H. (1998), "Putting the enterprise into the enterprise system", Harvard Business Review. July-August, C. Pui Ng, C., Gable, G.G., Chan, T. (2002), " An ERP-client benefit-oriented maintenance taxonomy", Journal of Systems and Software, 64, Anderson, J.A., Head, T.J., Automata theory with modern applications. Cambridge University Press. Shang, S., Seddon P.B., (2002), "Assessing and managing the benefits of enterprise systems: the business manager s perspective", Information Systems Journal, 12, Wagner, E.L., Moll, J., Newell, S. (201), "Accounting logics, reconfiguration of s and the emergence of new accounting practices: A sociomaterial perspective", Management Accounting Research, 22,