Agility of enterprise information systems: A conceptual model, design principles and quantitative measurement Текст научной статьи по специальности «Компьютерные и информационные науки»

Agility of enterprise information systems: A conceptual model, design principles and quantitative measurement

Yuri A. Zelenkov

Professor, Department of Information Systems and Digital Infrastructure Management National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: [email protected]

Abstract

A modern enterprise has to react to permanent changes in the business environment by transformation of its own behavior, operational practices and business processes. Such transformations may range from changes of business processes to changes of information systems used to support the business processes, changes in the underlying IT infrastructures and even in the enterprise information system as a whole. The main characteristic of changes in a turbulent business environment and, consequently, in the enterprise information system is unpredictability. Therefore, an enterprise information system should support the operational efficiency of the current business model, as well as provide the necessary level of agility to implement future unpredictable changes of requirements.

This article aims to propose a conceptual model of an agile enterprise information system, which is defined as a working system that should eliminate the largest possible number of gaps caused by external events through incremental changes of its own components. A conceptual model developed according to the socio-technical approach includes structural properties of an agile enterprise information system (actors, tasks, technology, and structure). Structural properties define its operational characteristics, i.e. measurable indicators of agility - time, costs, scope and robustness of process of change. Different ways to build such an agile system are discussed on the basis of axiomatic design theory. We propose an approach to measurement of time, cost, scope and robustness of changes which helps to make quantitative estimation of the achieved level of agility.

Key words: enterprise information system, enterprise agility, agility measurement, enterprise system services, enterprise system platform.

Citation: Zelenkov Y.A. (2018) Agility of enterprise information systems: A conceptual model, design principles and quantitative measurement. Business Informatics, no. 2 (44), pp. 30—44. DOI: 10.17323/1998-0663.2018.2.30.44.

Introduction

Modern organizations operate in a highly turbulent environment, so they must have a high level of agility. Organizational agility is often defined as the ability to sense environmental change and respond efficiently to that change [1]. An organization is an open system and cannot be considered and analysed in isolation from the environment. Thus, to maintain effectiveness, the organization must adapt over time to changing contingencies. The environment, organizational size, and organizational strategy are considered as the main contingencies that shape the organization [2].

Ciborra [3] has suggested a similar concept for enterprise information systems (EIS). He described this approach, which he called bricolage or improvisation — the gradual improvement of the existing systems, involvement of employees at the operating level, learning by doing, and by trial and error. This creates unique operating practices that cannot be easily decoded and reproduced by competitors. Another characteristic of this operating mode is that it has an uncertain status, always at the boundary between highly competent behaviour and incompetence. This approach is contrary to the more traditional view on innovation through the implementation of EIS as a radical change of existing competencies through preliminary analysis and planning [4].

Thus, implementation of a new EIS aimed at improving the efficiency of existing business processes should not prevent a change of these processes in the future. Modern organizations are increasingly dependent on IT to remain agile and competitive in a rapidly changing market, but there remain gaps in understanding how IT resources support IT agility [5]. In practice, development of the EIS increases its functionality, complexity, business value and reduces its agility [6]. Therefore, it is very important to have EIS, which allows you to change the processes in the organization without significant costs.

Ideally this should be done by reconfiguring the EIS, or, in extreme cases, with partial replacement of some older modules with new ones. It is desirable to avoid a situation where complete replacement of the EIS is needed due to its incompatibility with the new principles of work, since this leads to significant costs.

Thus, the research question can be formulated as 'how to combine a continuous increase of business value with a sufficient level of agility in the process of EIS development'. To solve this problem, it is necessary to build a model of an agile enterprise information system, and investigate ways how EIS agility can be provided. A very important research topic and practical issue also is the quantitative measurement of the level of EIS agility. Such measurement is necessary to assess the achieved level of agility, and secondly, for planning activities to improve the agility and thus the business value of the EIS.

1. Review of the literature

Prior research concerning IT business value has established a link between firm-level IT investment and tangible returns such as output productivity [7, 8]. Kleis et al. [9] and Saunders and Brynjolfsson [10] also showed that IT is vital to produce intangible output. Mithas, Ramasubbu and Sambamurthy [11] found that information management capability plays an important role in developing other capabilities of the firm for customer management, process management and performance management. In turn, these capabilities favorably influence customer, financial, human resources and organizational effectiveness measures of the firm's performance. According Dos Santos et al. [12], demand for IT products has not become less sensitive to changes in economic conditions, and investments in new IT applications are not diminishing. Moreover, IT products that provided opportunities for firms to create value at one point in time, later become necessities for staying in business.

Pavlou and El Sawy [13] showed that the strategic effect of IT leveraging of competence is more pronounced in higher levels of environmental turbulence. In the context of a turbulent business environment, the most important challenge is the need to keep track of coming changes and update EIS accordingly. This problem can be viewed as yet another objective of Business and IT alignment: the rate of change of the EIS should correspond to the rate of change of the organization itself and it environment [14].

An overview of the general concepts and models related to agility is given in [15]. Today, significant progress has been achieved in studies of agile manufacturing systems that consider the ability to adjust without significant costs the volume and nomenclature of manufactured products in response to changing demand [16]. Yusuf, Sarhadi and Gunasekaran [17] and Jackson and Johansson [18] identified foundations of agility and the main dimensions for its measurement. Sharifi and Zhang [19] proposed a holistic framework of an agile manufacturing system which identifies four core concepts:

♦ agility drivers (turbulence and unpredictability of the environment, including changes in consumer demand, political and social factors, technological innovation, the actions of competitors, and market regulators);

♦ strategic abilities (responsiveness, competence, and flexibility — the main attributes of an agile organization);

♦ agility capabilities that could be achieved by means of agility providers;

♦ agility providers (organization, technology, people, innovation) and their implementation in the form of practices, methods and tools.

A review of the research topics of EIS agility is presented in [20]. It includes discussion of the impact of modern information and communication technologies (ICT) on enterprise agility. Often the implementation of different compo-

nents of ICT is understood as a specific case of technology-based organizational change [21]. This point of view caused a number of different supporting mechanisms and frameworks for the support of business agility via ICT agility. Hewlett-Packard's Adaptive Enterprise Strategy [22] is good example of such an approach. However, Galliers [23] highlighted one of key problems of the EIS impact on business agility. Enterprise systems are often promoted as a means of transferring "best-practice" knowledge. By advocating copying of best practices to improve efficiency, organizations are potentially running the risk of reducing their ability to create the new knowledge needed to innovate and respond creatively to changing imperatives. ICT such as the EIS can then be seen as a force for standardization, thus speeding competitive convergence, given that the technology is more or less common — and increasingly commoditized — irrespective of the organization implementing it.

Such highly 'standardized' EIS can negatively impact enterprise performance, especially in the case of 'non-standard' events which are produced in a turbulent environment. Once a business event occurs, the value-added of reacting to that event decreases over time [24]. If the EIS does not provide a handler for such events, the time of their detection, decision-making and decision implementation can grow extremely and that leads to declining performance [25]. Lee et al. [26] showed that IT ambidexterity, namely, the dual capacity to explore and exploit IT resources and practices, enhances organizational agility.

It should be noted that there is another problem with the use of EIS as a tool for the transfer of "best practices." EIS is closely related with other intangible assets of the organization, and it is complementary to the competence of the personnel, models of business processes, etc. As Brynjolfsson and Saundes [27] stated, two practices are complementary if the returns from adopting one practice are greater when the sec-

ond practice is present. Milgrom and Roberts [28] argued that it is important to adopt systems of complementary activities, rather than adopting one individual "best practice." When practices in an established system are closely related and they conflict with practices of new system, then it is likely that the transition will be difficult. Because of the complementarities, change of only one practice, or a small subset of complementary practices, likely will reduce overall performance. The natural conclusion is that the organization should change all the practices in the new system simultaneously [7].

The presence of complementary relations with other assets explains the effect of permanent changes of the EIS. Changes in the complementary assets cause changes in the EIS, which in turn lead to changes in other practices and ways of working. In fact, the co-invention of EIS usage is going on permanently. It is the process that Ciborra [3] called bricolage.

Thus, agility should be a major feature of the EIS. Peppard and Ward [29] in their empirical research showed that organization performance is more dependent on the capabilities of EIS to effect agility than on IT investments. This raises the question of how the quality of design influences the agility of the EIS.

Maurer and Goodhue [30] noticed what in an early stage of the life-cycle EIS exhibits a "clean" design and has a high level of agility. On the following stages including run-time, EIS deals with unpredictable variability of user needs and the external environment. Continuous changes of the system make it more difficult to respond to new agility challenges, and the system exhibits limited agility characteristics. Thus, despite the benefits that EIS provide, it can constrain choice for an organization which faces agility challenges. Tight integration between different parts of the business that enables many EIS benefits also increases the difficulty of changing systems when business needs change. Goodhue et al. [31] suggested that organizations are able to address a

high percentage of their challenges with four options that avoid the difficulties associated with changing the complex core system:

implementing capabilities already built-in to the package but not previously used;

leveraging globally consistent integrated data already available;

using "add-on" systems available on the market that easily interfaced with the existing enterprise system;

using vendor-provided "patches" that automatically update code.

Recent results of Claybaugh, Ramamurthy and Haseman [32] confirm this point of view, that firms with a greater propensity to assimilate the new enterprise resource planning (ERP) version have a higher assessment of relative advantage and IS technical competence and a strategic role of IS relative to those firms with a lower propensity to assimilate a new ERP version. But it is desirable to avoid a situation when a complete transformation of the EIS is needed due to its incompatibility with the new principles of work, since this leads to significant problems [33].

Sedighi, et al. [34] proposed a model of organization agility in every phase of the ERP system lifecycle. This model suggests that knowledge gained after completing each phase should be transferred to the next phase. Hobbs and Scheepers [35] presented model of agility which describes two main capabilities: (1) the sense of current use of the existing information system and (2) future needs from the environment.

The EIS can be viewed generally as a collection of problem-oriented subsystems (i.e. ERP, CRM, etc.) that work together to form a coherent whole. In accordance with the enterprise architecture approach, a few layers can be identified: business process architecture, data architecture, application architecture and technical infrastructure [36]. All the subsystems are connected to the environmental resources and other

systems via network connections. These connections lead to complex systems-of-systems architectures for providing behaviors and qualities, so there are identifiable networks across all layers [37]. Physical networks provide connections of equipment and support the transmission of data among system platforms. Software networks provide the middleware layers and protocols that transform the transmitted data into information that is shared among the information processing systems. Social networks provide a means of interaction and community among the human participants of the complex system [38]. Changes in any network that are caused by external reasons should be accompanied with changes in other layers. Herewith the survey by Tallon [39] showed that managerial IT capabilities (business and IT vision, delivery of IT services, and design of IT architecture as defined by Feeny and Willcocks [40]) are more effective for firms in a turbulent environment, while technical IT capabilities (diverse set of resources around physical IT infrastructure and human expertise) are more effective for firms in a stable setting.

Very important research and a practical issue is the measurement of overall enterprise agility and, in particular, EIS agility. The assessment of the company's agility level is very difficult because the widely used definition of agility ("to sense change and respond to it" [41]) is imprecise and vague. Thus, approaches based on linguistic expressions and fuzzy logic are widely used (see for example [42]). Sometimes it is combined with another technique like Quality Function Deployment (QFD) [43, 44]. Arteta and Giachetti [45] used the complexity of the enterprise system as a surrogate measure of agility. Overby et al. [46] suggested that enterprise agility could be measured as a function of an organization's individual sensing and responding capabilities. In other words, enterprise agility should not be measured directly; instead, the components of sensing and responding should be measured individually to

create an overall measure of enterprise agility. Maurer [47] constructed an EIS agility metric which consists of three dimensions: technical infrastructure agility, information system process agility and human characteristics. Fausc-ette and Perry [48] introduced the IT complexity index, which also can be used for agility measurement (in this case the complexity and agility are viewed as opposite properties).

EIS researches that are based on socio-tech-nical theory [49—51] should be mentioned at the conclusion of our review of the literature. EIS are socio-technical networks where components, usually considered as social or technological, are linked together into networks as discussed above. Acknowledgment of the importance of the installed base implies that our traditional notions of design as performed by humans only must be rejected [3]. The idea of cultivation as the outcome of development, something carried out by multiple agents (one of which can be the installed base or the infrastructure standards) captures quite effectively the interactive role of both humans and technology [52, 53]. Lyytinen and Newman [54] proposed a punctuated change model for information systems on the basis of socio-technical theory; it will be reviewed in greater detail in Section 2.

2. A model of agile EIS

According to Giachetti et al. [55], the properties of any system can be divided into structural and operational. Structural properties are determined by the system architecture and technologies used. They are defined in the design stage, do not depend on external conditions, and it is extremely difficult to change them at run-time. An example of these properties is the number and volume of cylinders of the car engine. The operational properties (e.g. vehicle speed and fuel consumption) depend not only on internal parameters, but also on external conditions, and they can be changed in a short time. It should be noted that operating properties can be easily measured, while

the measurement of structural properties often cannot be done without destroying the system.

To investigate the structural properties of the EIS, a process of its change should be identified. In the context of agility, the EIS should be analysed as a work system — an existing system in which human participants and/or computers perform work using information to produce products and services for internal or external customers [56].

Alter [56] also noted that the work system life cycle is fundamentally different from the frequently cited system development life cycle. System development is basically a project model, but the work system evolves over time through multiple iterations. Ciborra [3] argued that an existing system could constrain the ability of an organization to evolve. In such circumstances employees are trying to adapt to the new requirements; they are looking for ways to perform new tasks with the help of old existing tools, using the "trial and error" approach. This is the method of adapting existing information systems (installed base) to new challenges, which Ciborra [3] calls bricolage, — the creation of new tools from the what is at hand. Thus, a company loses a control of the EIS, its architecture is divided into uncoordinated fragments, a problem of integration appears, and the overall level of agility is reduced [14]. When the new approach to implement new requirements becomes clear, the spontaneous adaptation strategy is replaced by purposeful actions. This is the path to the manageable evolution of information systems which can increase their functionality together with agility.

The model of EIS changes that is proposed by Lyytinen and Newman [54] is based on socio-technical theory. According to the model of organization change, any socio-technical system, including EIS, should be seen as a combination of four interacting coordinated components [57]:

♦ structure (normative and behavioral aspects of the system — communication, management, and business processes);

♦ actors (members of the organization and all stakeholders who can influence it);

♦ technologies (tools used to solve problems);

♦ tasks (goals and the ways in which they are achieved).

This point of view is confirmed by the results of recent empirical research. Employees' system exploration behaviour can be affected by factors related to three major components: the task, the system, and the organizational environment [58]. Moreover, organizations often face resistance behavior from employees who avoid or under-utilize the system [59], because work routines become an object of resistance during information system implementation. Regarding technology, IT complexity creates challenges both for IT and for the business as a whole [48]. Key business challenges include reduced flexibility, decreased ability to support innovation and missed opportunities together with competitive disadvantage.

It should be noted that the boundaries between the components of EIS are fuzzy, but all components are linked to each other. These links can be linear "cause — effect" (these connections are usually designed in advance), and non-linear, spontaneously arising, often unpredictable. Therefore, it is impossible to optimize only one aspect of the system — the social or technical. External events related to changes in the environment continuously affect the EIS and violate the consistency of the system components. These events may include the emergence of new technologies, optimization of business processes, changes in the number of users, and even a change in the development and support teams, etc. Events lead to a mismatch between the systems components. When such a mismatch arises, the system acts to eliminate it. Note that not all actions lead to success. In general, there are four possible outcomes: (1) the gap is eliminated by incremental changes in the other components; (2) the gap persists; (3) the gap is eliminated by revolutionary transformation of the EIS to a new system; (4) the attempt to correct the mismatch

between the two components leads to its spread to other parts of the system.

Thus, according the model of Lyytinen and Newman [54] the system evolution evolves most of the time with incremental changes of its components under the influence of the flow of external events. Long periods of evolutionary development are interrupted by revolutionary transformations, when the system radically changes its organization and rules binding components in a short period. In general, the behavior of the system is chaotic.

Based on the Lyytinen and Newman model [54], the definition of an agile system can be formulated more exactly: agile enterprise information system should eliminate largest possible number of gaps caused by external events through incremental changes. These properties are structural and should be supported by the system design. Types of such a kind of design will be discussed in the next section.

Dove [60] determined the operational properties of an agile enterprise that include:

❖ the time that is needed to react to change;

❖ the cost of change;

the possible scope of change; the quality of the change process, which is defined as its robustness.

He also proposed change in proficiency metrics to measure all these properties for manufacturing systems. That classification of properties of an agile system is general enough and can be used also for the EIS.

Therefore, based on the results of the above-cited works [19, 54, 60], we propose a model of an agile enterprise information system shown in Figure 1. It includes the following core concepts:

♦ agility drivers (turbulence and unpredictability of the environment, including unpredictable and permanent changes in requirements, the appearance of new technologies, new business models, etc.);

♦ agile strategy: responsiveness, competence, and flexibility — the main attributes of an agile organization [19];

♦ structural properties of the EIS (i.e. composition of its socio-technical components [54]) that define agility capabilities;

♦ agility providers, which should help achieve agility capabilities and their implementation in the form of practices, methods, and tools [19]. In our opinion, the main attention should be directed to design principles of the EIS, which should provide structural properties. This issue is discussed below in Section 3;

f \

Agility drivers

Turbulent external environment

\_J

+

Structural properties of EIS

Structure

Technology

1 •

-

Tasks

Actors

+

Agile strategy

Agility providers

Axiomatic design of all social and technical components of the EIS

Fig. 1. The model of agile EIS

f

Operational properties of EIS

Properties of process of change:

• Time

• Costs

• Scope

• Quality / robustness

♦ operational properties of the EIS [60] which can be measured to confirm the level of EIS agility. This issue is discussed below in Section 4.

3. Design of agile EIS

The general principles of system design are identified in axiomatic design [61]. The axiomatic approach recognizes the existence of four design domains: customer domain, functional domain, physical domain and process domain. Each domain is described by a characteristic vector (i.e. customer attributes, functional requirements, design parameters and process variables), which can be decomposed to establish a hierarchical tree. The design process requires mapping between these domains. Finally, there are two design axioms which the mapping process must satisfy to create an acceptable system. The Independence Axiom maintains the independence of functional requirements; the Information Axiom minimizes the information content.

The first axiom provides the criterion for acceptable design during the mapping process. The "product" design, which is the mapping process between the functional domain and the physical domain, can be represented by a design equation as

fr = A dp,

where fr is a vector which describes the functional requirements of the product; A is a product design matrix; dp is a vector describing the design parameters that define the product in terms of its effect on fr. In the case of the EIS, design parameters can present its decomposition on services, software modules, objects, etc. To satisfy the Independence Axiom, A must be a diagonal or triangular matrix. A design that has a diagonal matrix is called an uncoupled design; in this case, each functional requirement affects only one design parameter. When the matrix A is triangular, it is a decoupled design, which also satisfies the Independence Axiom — each functional requirement

affects multiple design solutions, but there is no reverse effect. All other designs are coupled designs — one design solution may implement a few functional requirements; this leads to the mutual influence of functional requirements.

The Information Axiom requires minimizing the amount of information in the design process or, without going into details, increasing the probability to satisfy the functional requirements.

The principles of axiomatic design are applicable both to static systems, which are created once, and to systems that evolve over time. However, in the second case, there is the fundamental differences between standard requirements engineering and requirements engineering for an evolvable system [62]. Such a system should detect deviations between its runtime behaviour and new requirements. Compliance with the axiomatic design principles should help create systems with a high level of modularity.

This discussion has significant practical implications. For example, the choice of the ERP system as the foundation of the enterprise information system should be considered in the context of modularity. Most of the ERP systems positioned today on the market do not satisfy this requirement. These systems have a significant number of cross-links between modules, and even minor changes in one module lead to great difficulties, because they can impact on the setup parameters of other modules. Therefore, it can be stated that the design of almost all modern ERP does not meet the Independence Axiom. In fact, these systems are a rigidly fixed business processes model existing at the time of their implementation, and very expensive resources should be attracted to change that model. In addition to the technological issues, there may be social barriers to modularity, for example incompatible process interfaces, lack of IT and business process expertise, short-term decision criteria for IT investment, etc. [63].

The single way to ensure agility of the EIS covers all components of the socio-technical model of the enterprise. It assumes the provision of business services instead of the concentration on functions of EIS or even the support of business processes. The process-oriented approach concentrates on process output and internal metrics of the supplier are used for measurement of results. The service-oriented approach, in contrast, involves the measurement of results using the metrics the customer

[64]. In this case, the EIS is just one of the tools to provide the service.

Therefore, both technical and social components of EIS should be designed in accordance with the Independence Axiom. In general, this approach follows socio-technical theory, which does not recommend increasing the internal complexity of the organization in response to the unpredictability of the environment, because it leads to an increased amount of EIS functions and corresponding investments, and as a result reduces EIS agility. Decrease of internal control and coordination is advised as alternative (the so-called strategy of 'simple organizations and complex jobs',

[65]). This approach leads to the replacement

of the traditional hierarchy on semi-autonomous groups that are solely responsible for all operations within a particular service.

In accordance with the above, we can propose a framework for evaluation of the maturity of EIS services (Table 1).

4. Measurement of EIS agility

Measuring performance is a precondition for analyzing and subsequently improving all types of activities. It has been stated above that only the operational properties of a system can be measured and for an agile system those have been determined by Dove [60] in terms of the process of change properties: time, cost, scope and robustness of changes.

We consider the case when an organization has a mature EIS. In this case, a significant investment in development is not necessary, but enough small changes caused by events external to the system occur constantly. We assume the flow of changes is relatively uniform. This means that there are no major changes which require significant resources in comparison with regular requests. Implementation of such major changes should be considered as sepa-

Table 1.

Framework for evaluation of EIS services maturity

Maturity level Description Service users Who is responsible

0 Operability of IT - infrastructure and enterprise system is provided without a formal service level agreement (SLA). Not formally defined CIO

1 Basic infrastructure services (email, file management, printing, etc.) are provided. Internal users CIO

2 Business application support services are provided. Internal users Application owners

3 Business processes support services are provided for users inside the organization Internal users Process owners

4 Business processes support services are provided inside and outside the organization. Customers, suppliers and partners have access to the enterprise system. Internal and external users (partners, suppliers, customers) Process owners

rate projects. The department responsible for the EIS change will be recognized as a kind of queuing system. Note that no specific information about the structure of this department is needed. Furthermore, an external service provider or even a few providers can perform this activity. It is important only to estimate how predictable processes of EIS change.

To implement the measures that are proposed here, an organization must have a special system to manage change requests (CR). Each request is stored with the following attributes: the date of its receipt, the expected date and the actual date of request closing. Then the drawing of a few relatively simple graphs allows us to estimate the time, volume and robustness of changes in visual form.

The first graph is shown in Figure 2. Two curves are presented here — one corresponds to the number of open CRs (note that the initial value of this parameter is greater than zero, and this value is equal to the number of open CRs at the initial time). The second is the number of closed CRs. The horizontal distance between these curves corresponds to the average request execution time. This value can be interpreted as the time at which all the requests that are avail-

able at time A, can be performed if new CRs will not be generated. Note that for manufacturing systems this value corresponds to the cycle time.

The vertical distance between the curves determines the number of requests that are in process. In manufacturing systems, this corresponds to the work in process (WIP). In our case this distance determines the amount of changes executed at each time.

If both curves evolve approximately parallel, this means that the situation is stable; the users generate a predictable amount of change requests that can be executed in a predictable time. Thus, a simple glance at the chart makes it possible to estimate the scope and time of the change.

Note that the information presented in Figure 2 can also be used for an indirect estimation of the robustness of the process of change (clearly, for a robust process these two curves are parallel), but for the measurement of this parameter we offer here a more advanced technique. As mentioned above, each CR is characterized by expected and actual dates of execution. The expected date can be defined as an agreement between the initiator of changes and the department responsible for implementing

Number of change requests 1600

1400

1200

1000

800

600

400

200

0

1 ................. ........... —' s *

✓ **

...................................................................................................................... Time (cycle) jf Scope (WIP)

r *

....................................................................j / ----- ____ •

r "* r — •> ^ J A

01.03.14 08.03.14 15.03.14 22.03.14 29.03.14 05.04.14 12.04.14 19.04.14 26.04.14

Open change requests ---Closed change requests

Fig. 2. Time and scope of changes

Time

the changes, or it is pre-determined by a service level agreement (SLA).

Various unpredictable events can occur while change is processed. That affects the time of its implementation, and thus the actual date may differ from the expected date. We can consider this deviation as a random variable which can be characterized by the information entropy. Usually the information entropy is defined as follows. Suppose that the system reacts to some event with action x with n possible outcomes of xi, then the information entropy is

n 1=1

where p() — a function of probability,

We need to change this definition for our purposes. To enable comparison of the volatility of the various processes, the value of entropy should be normalized. Let N be the number of process instances performed for a period t, and each of them has the output value of from the set of n possible outcomes F.e (F{, F2, ..., Fn). It is known that the uniformly distributed random variable has a maximum entropy value H(x) = In n and the constant has a minimum entropy value H(x) = 0. Then, the proposed metric will look like this:

where p(F) — the frequency of processes executed with result F. in the total number of processes within the period t. Thus, the state of full uncertainty about the process, when all possible outcomes have equal probability, corresponds to the value H(t) = 1. The state of full certainty, when only one outcome is possible, corresponds to the value H(t) = 0.

To demonstrate use of the proposed measure, let us assume that for some time N= 100 CRs have been processed, and the values of their deviations from the target dates were of /■ = {—1; 0; 1; 2; 3; 5}, so the number of outcomes n = 6. A negative value in set F means

that the request was completed ahead of schedule. Assume also that the number of CRs that have been processed with the specified results, respectively, k = {2; 50; 25; 10; 8; 5}. Accordingly, the frequencies of these results in the total number of executed requests are calculated as p(F) =k. /N and respectively form a set of p = {0.02; 0.50; 0.25; 0.10; 0.08; 0.05}. Multiplying all elements of set p on the values of their natural logarithms and summing up the results, we obtain the negative value of H(x). Dividing it by the logarithm of n, we obtain the H(i)=H(x)/\n.n. For the example proposed above H(x) = 1.353; H(t) = 0.755.

The indicator we have introduced measures the spread of the results of the process. The greater the number of CRs processed with the same deviation from the expected date, the smaller the H(i). However, it should be noted that the prevailing value of the deviation is not necessarily equal to zero. Note that in the above formulas the values of the deviations are not used, but only their frequencies. It is possible that most of the queries are processed with the same non-zero deviation. This means that the expected date is estimated with systematic error, and it is necessary to adjust in the planning process.

Thus, by observing the change of H(J) in different time periods t, we can estimate the dynamics of robustness of the process. An example of such a graph is presented in Figure 3 (data presented on Figures 2 and 3 were obtained from NPO Saturn, a large Russian manufacturing company).

As for the average cost of the change process, it can be estimated as the ratio of the overall cost of supporting the EIS C(tv i2) to the amount of changes processed during the period (/, t2).

Based on the considerations outlined above, this ratio must also change slightly over time for an agile EIS.

cost(tl,t2) = -C(tl,t2).

0.90 0.85 0.80 0.75 0.70 0.65 0.60 0.55 0.50 0.45 0,40

trend line

01.03.14 01.04.11 01.05.11 01.06.11 01.07.11 01.08.11 01.09.11 01.10.11 01.11.11 01.12.11 01.01.12 01.02.14 01.03.12 01.04.12

Fig. 3. Example of dynamics of robustness of changes process (less is better)

Time

Conclusion

The enterprise information system significantly impacts the level of agility of the organization. Rigid EIS can limit the enterprise's ability to transform itself, so it is important to maintain a high level of agility of EIS too. In this case, the EIS should be considered as a socio-technical system; concentration on maintaining agility of only technological components would not lead to the expected results. Therefore, the most effective way to ensure the agility of the EIS is its decomposition into loosely coupled components that are linked with business services. The platform-based approach combined with agile methods can be

used to develop such a system. But in any case, the most flexible part of the system is people — users, programmers, technical architects, business analysts, support specialists, and of course other stakeholders. They carry out all changes, so the firm should pay special attention to the organizational structure that facilitates the effective functioning of the development and support teams in accordance with the principles of axiomatic design. The metrics proposed here can serve both as a measure for the agility of the change process (time, scope, robustness, and cost) and as an evaluation of the efficiency of the organization in the social part of the EIS. ■

References

1. Haeckel S.H. (1999) Adaptive enterprise: Creating and leading sense-and-respond organizations. Boston: Harvard Business School Press.

2. Donaldson L. (2001) The contingency theory of organization. London: Sage Publications.

3. Ciborra C. (2002) The labyrinths of information: Challenging the wisdom of systems. Oxford: Oxford University Press.

4. Elbanna A. (2009) Rigid technology and improvised implementation: The case of ERP systems. Bricolage, care and information: Claudio Ciborra's legacy in information systems research (eds. C. Avgerou, G.F. Lanzara, L.P. Willcocks). New York: Palgrave Macmillan, pp. 327—347.

5. Lowry P.B., Wilson D. (2016) Creating agile organizations through IT: The influence of internal IT service perceptions on IT service quality and IT agility. Journal ofStrategic Information Systems, vol. 25, no. 3, pp. 211—226.

6. Murer S., Bonati B., Furrer F.G. (2011) Managed evolution: A strategy for very large information systems. Berlin: Springer.

7. Brynjolfsson E., Milgrom P. (2013) Complementarity in organizations. The handbook of organizational economics (eds. R. Gibbons, J. Roberts). Princeton: Princeton University Press, pp. 11—55.

8. Tambe P., Hitt L.M. (2012) The productivity of information technology investments: New evidence from IT labor data. Information Systems Research, vol. 23, no. 3—1, pp. 599—617.

9. Kleis L., Chwelos P., Ramirez R.V., Cockburn I. (2012) Information technology and intangible output: The impact of IT investment on innovation productivity. Information Systems Research, vol. 23, no. 1, pp. 42-59.

10. Saunders A., Brynjolfsson E. (2016) Valuing information technology related intangible assets. MIS Quarterly, vol. 40, no. 1, pp. 83-110.

11. Mithas S., Ramasubbu N., Sambamurthy V. (2011) How information management capability influences firm performance. MIS Quarterly, vol. 35, no. 1, pp. 237-256.

12. Dos Santos B.L., Zheng Z., Mookerjee V.S., Chen H. (2012) Are new IT-enabled investment opportunities diminishing for firms? Information Systems Research, vol. 23, no. 2, pp. 287-305.

13. Pavlou P.A., El Sawy O.A. (2006) From IT leveraging competence to competitive advantage in turbulent environments: The case of new product development. Information Systems Research, vol. 17, no. 3, pp. 198-227.

14. Zelenkov Y. (2015) Business and IT alignment in turbulent business environment. Lecture Notes in Business Information Processing, no. 228, pp. 101-112.

15. Sherehiy B., Karwowsky W., Layer J.K. (2007) A review of enterprise agility: Concepts, frameworks, and attributes. International Journal ofIndustrial Ergonomics, no. 37, pp. 445-460.

16. Cunha M.M., Putnik G.D. (2006) Agile virtual enterprises: Implementation and management support. Hershey: Idea Group Publishing.

17. Yusuf Y., Sarhadi M., Gunasekaran A. (1999) Agile manufacturing: The drivers, concepts and attributes.

International Journal ofProduction Economics, vol. 62, no. 1-2, pp. 33-43.

18. Jackson M. Johansson C. (2003) Agility analysis from a production system perspective. Integrated Manufacturing Systems, vol. 14, no. 6, pp. 482-488.

19. Sharifi H., Zhang Z. (1999) A methodology to achieving agility in manufacturing organizations: An introduction. International Journal ofProduction Economics, vol. 62, no. 1-2, pp. 7-22.

20. Desouza K.C., ed. (2007) Agile information systems: Conceptualization, construction, and management. Amsterdam: Butterworth-Heinemann.

21. Orlikowski W.J. (1993) CASE tools as organizational change: Investigating incremental and radical changes in systems development. MIS Quarterly, vol. 17, no. 3, pp. 309-340.

22. Wilkinson M. (2006) Designing an "adaptive" enterprise architecture. BT Technology Journal, vol. 24, no. 4, pp. 81-92.

23. Galliers R.D. (2007) Strategizing for agility: Confronting information systems inflexibility in dynamic environments. Agile information systems: Conceptualization, construction, and management (ed. K.C. Desouza). Amsterdam: Butterworth-Heinemann, pp. 11-15.

24. Bonham S.S. (2008) Actionable strategies through integrated performance, process, project, and risk management. Boston: Artech House.

25. Zelenkov Y. (2017) Decision making in cloud computing: A method that combines costs, risks and intangible benefits. Communications in Computer and Information Science, vol. 731, pp. 273-285.

26. Lee O.K., Sambamurthy V., Lim K.H., Wei K.K. (2015) How does IT ambidexterity impact organizational agility? Information Systems Research, vol. 26, no. 2, pp. 398-417.

27. Brynjolfsson E., Saunders A. (2010) Wiredfor innovation:How information technology is reshaping the economy. Cambridge, MA: MIT Press.

28. Milgrom P., Roberts J. (1995) Complementarities and fit: Strategy, structure, and organizational change in manufacturing. Journal ofAccounting and Economics, vol. 19, no. 2-3, pp. 179-208.

29. Peppard J., Ward J. (2004) Beyond strategic information systems: Towards an IS capability. Journal of Strategic Information Systems, vol. 13, no. 2, pp. 167—194.

30. Maurer C., Goodhue D. (2010) A theoretical model of the enterprise system agility life-cycle. Proceedings of the 16th Americas Conference on Information Systems (AMCIS 2010), Lima, Peru, 12—15 August 2010, paper 231.

31. Goodhue D.L., Chen D.Q., Boudreau M.C., Cochran J. (2009) Addressing business agility challenges with enterprise systems. MIS Quarterly Executive, vol. 8, no. 2, pp. 73—87.

32. Claybaugh C.C., Ramamurthy K., Haseman W.D. (2017) Assimilation of enterprise technology upgrades: A factor-based study. Enterprise Information Systems, vol. 11, no. 2, pp. 250—283.

33. Gregory R.W., Keil M., Muntermann J., Mahring M. (2015) Paradoxes and the nature of ambidexterity in IT transformation programs. Information Systems Research, vol. 26, no. 1, pp. 57—80.

34. Sedighi M.M., Torabi G., Shojaie M., Mokif T. (2012) Studying agility during ERP lifecycle:

A conceptual model for ERP implementation and agility assessment. Proceedings of the International Conference on Emerging Trends in Computer and Electronics Engineering (ICETCEE 2012), Dubai, 24—25 March 2012, pp. 44-48.

35. Hobbs G., Scheepers R. (2011) Agility in information systems: Enabling capabilities for the IT functions.

Pacific Asia Journal of the Association for Information Systems, vol. 2, no. 4, article 2.

36. Giachetti R.E. (2010) Design of enterprise systems: Theory, architecture, and methods. Boca Raton: CRC Press.

37. Hevner A., Chatterjee S. (2010) Design research in information systems theory andpractice. New York: Springer.

38. Fiadeiro J. (2007) Designing for software's social complexity. IEEE Computer, vol. 40, no. 1, pp. 34-39.

39. Tallon P.P. (2008) Inside the adaptive enterprise: An information technology capabilities perspective on business process agility. Information Technology and Management, vol. 9, no. 1, pp. 21-36.

40. Feeny D.F., Willcocks L.P. (1998) Core IS capabilities for exploiting information technology. Sloan Management Review, vol. 39, no. 3, pp. 9-21.

41. Newman D., Logan D. (2006) Achieving agility: How enterprise information management overcomes information silos. Gartner Research, G00137817.

42. Tseng Y.H., Lin C.T. (2011) Enhancing enterprise agility by deploying agile drivers, capabilities and providers. Information Science, vol. 181, no. 17, pp. 3693-3708.

43. Vinodh S., Devadasan S.R. (2011) Twenty criteria based agility assessment using fuzzy logic approach.

International Journal of Advanced Manufacturing Technologies, vol. 54, no. 9-12, pp. 1219-1231.

44. Bottani E. (2009) A fuzzy QFD approach to achieve agility. International Journal ofProduction Economics, vol. 119, no. 2, pp. 380-391.

45. Arteta B.M., Giachetti R.E. (2004) A measure of agility and the complexity of the enterprise system. Robotics and Computer-Integrated Manufacturing, no. 20, pp. 495-503.

46. Overby E., Bharadwaj A., Sambamurthy V. (2006) Enterprise agility and the enabling role of information technology. European Journal of Information Systems, vol. 15, no. 2, pp. 120-131.

47. Maurer C. (2010) Measuring information systems agility: Construct definition and scale development. Proceedings of the Southern Association for Information Systems Conference (SAIS 2010), Atlanta, USA, 26—27 March 2010, pp. 155-160.

48. Fauscette M., Perry P. (2014) Simplifying ITto drive better business outcomes and improved ROI: Introducing the IT complexity index. IDC, White Paper #249440.

49. Bostrom R., Heinen J.S. (1977) MIS problems and failures: A socio-technical perspective. Part I: The causes. MIS Quarterly, vol. 1, no. 3, pp. 17-32.

50. Bostrom R., Heinen J.S. (1977) MIS problems and failures: A socio-technical perspective. Part II: The application of socio-technical theory. MIS Quarterly, vol. 1, no. 4, pp. 11-28.

51. Avgerou C., Ciborra C., Land F.F. (2004) The social study of information and communication technology: Innovation, actors and context. Oxford: Oxford University Press.

52. Kelly K. (1995) Out of control: The new biology of machines, social systems, and the economic world. Reading: Addison-Wesley.

53. Latour B. (2005) Reassembling the social: An introduction to actor-network-theory. Oxford: Oxford University Press.

54. Lyytinen K., Newman M. (2008) Explaining information systems change: A punctuated socio-technical change model. European Journal of Information Systems, vol. 17, no. 6, pp. 589-613.

55. Giachetti R.E., Martinez L.D., Saenz O.A., Chen C.S. (2003) Analysis of the structural measures of flexibility and agility using a measurement theoretical framework. International Journal ofProduction Economics, vol. 86, no. 1, pp. 47-62.

56 Alter S. (2008) Service system fundamentals: Work system, value chain, and life cycle. IBM Systems Journal, vol. 47, no. 1, pp. 71-85.

57. Leavitt H.J. (1964) Applied organization change in industry: structural, technical, and human approaches. New perspectives in organizational research (eds. S. Cooper, H. Leavitt, K. Shelly). Chichester: Wiley.

58. Liang H., Peng Z., Xue Y., Guo X., Wang N. (2015) Employees' exploration of complex systems: An integrative view. JournalofManagementInformation Systems, vol. 32, no. 1, pp. 322-357.

59. Laumer S., Maier C., Eckhardt A., Weitzel T. (2016) Work routines as an object of resistance during information systems implementations: Theoretical foundation and empirical evidence. European Journal ofInformation Systems, vol. 25, no. 4, pp. 317-343.

60. Dove R. (2001) Response ability: The language, structure, and culture of the agile enterprise. New York: Wiley.

61. Suh N.P. (2001) Axiomatic design. New York: Oxford University Press.

62. Jureta I.J., Borgida A., Ernst N.A., Mylopoulos J. (2015) The requirements problem for adaptive systems. ACM Transactions on Management Information Systems, vol. 5, no. 3, article 17.

63. Rai A., Venkatesh V., Bala H., Lewis M. (2010) Transitioning to a modular enterprise architecture: Drivers, constraints, and actions. MIS Quarterly Executive, vol. 9, no. 2, pp. 83-94.

64. Uram M., Stephenson B. (2005) Services are the language and building blocks of an agile enterprise.

The agile enterprise: Reinventing your organization for success in an on-demand world (eds. N. Pal, D.C. Pantaleo). New York: Springer, pp. 49-86.

65. Sitter L.U., Hertog J.F., Dankbaar B. (1997) From complex organizations with simple jobs to simple organizations with complex jobs. Human Relations, vol. 50, no. 5, pp. 497-534.