Risk Management in Project of Information Systems Integration

During Merger of Companies

E. Abakumov

, D. Agulova

and A. Volgin

Department of Information Technologies, All-Russia Research Institute of Automatics, Moscow, Russia

Rosatom, Moscow, Russia

Keywords: Integration of Information Systems, Integration of Businesses, Risk Management, Risk Analysis.

Abstract: As of today, reorganization of companies is one of the challenges that require close attention of

administrators. Integration of businesses cannot be accomplished without integration of information

systems. Project management is a tool needed to implement such integration efforts. Risk management is

one of the components of project management. A risk event occurs at a random nature, so estimating the

probability of change in potential timeframe of project completion taking into account the estimated

probability of various risk events is an important task. This paper gives an overview of the standard list of

risks for integration of information systems of merged companies. Note that this list of risks has been

developed for the Russian research-and-production instrument-making enterprises under government

ownership and can be viewed as an example of implementing risk-oriented approach to information

management. Besides, the list can be used to assess integration risks and elaborate ways to eliminate

(minimize) losses related to implementation of these risks.

1 PROBLEM STATEMENT

Current condition of information systems and their

application environment at the Russian research-

and-production enterprises can be described using

the following statements:

- Comprehensive coverage of business-processes

with insufficient modification speed according to the

requirements of business;

- Non-homogeneous information media from the

standpoint of both platforms, and age of

implemented systems;

-Insufficient readiness to changes of staff and

low level of understanding the advantages of

information systems at different levels of

management;

-Different degree of vendor systems

implementation, wide application of in-house design

systems;

-Need to resolve information security missions

and provide for the functioning of critical

infrastructure.

Current publications, indexable in notorious

databases, contain almost no information on

techniques and projects in the area of integrating

large information systems of different nature during

merger of companies. Publications in this area

mostly deal with either technical aspects of

integration (Shumsky, 2014), or international

mergers and takeovers involving the need for cross-

cultural interaction (Trienekens, 2014). We think

this is due to a large extent of monopolization of the

IT-systems market in the developed counties, and

the mission of integration, staff training and

installation of systems is almost a trivial one. In

Russia, the companies a priori have different

information systems with different settings, software

platforms, data managers that provide for

information support of business-processes with a

low extent of unification.

The infrastructure of information systems is also

non-homogeneous and has a different level of

application due to both lack of unified IT-policy, and

insufficient funding.

If we look at the classes of systems used by the

companies, we can see they are also quite different.

Instrument-making enterprises in general use ERP,

MES, PDM, PLM, CRM and other types of systems,

however, the technique and application practice can

be significantly different. Standardization in the area

of business-processes supported by the systems is

also insignificant, e.g., product lifecycle

221

Abakumov E., Agulova D. and Volgin A..

Risk Management in Project of Information Systems Integration During Merger of Companies.

DOI: 10.5220/0005333302210227

In Proceedings of the 17th International Conference on Enterprise Information Systems (ICEIS-2015), pages 221-227

ISBN: 978-989-758-096-3

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

management systems are used without the major

changes of basic standards for product design rules,

generated by the national authorities.

In general, the maturity of different information

systems (Romanov, 2013) is different throughout

the Russian instrument-making enterprises, as well

as the maturity of organizations.

The issue of estimating the timeframe of project

implementation is covered in much detail in

publications (Shikin, 2002), however the estimate of

risk impact on timeframe of project implementation

from the standpoint of probabilistic approach is

interesting and, in our opinion, not reflected in

publications in sufficient detail.

2 INFORMATION SYSTEMS

INTEGRATION PROJECT.

RISK ANALYSIS AND

ESTIMATE OF PROJECT

IMPLEMENTATION

TIMEFRAME

In case of affiliation of instrument-making

enterprises, the mission of interaction and system

integration becomes the most urgent. Operational

systems, such as ERP, MES, PLM, HRM, should

undoubtedly be integrated in the first turn, together

with resolving the infrastructure tasks of building a

unified information space. The first stage of

information system integration should be completed

before the legal merger, and it is worthwhile to

single out the project of such activities as a stand-

alone management unit. The second stage of

integration missions can be resolved after the

merger, but they will relate to strategic information

systems, or to the systems that have not used by one

of the companies at all. The impact of management

models and information systems on one another

should be noted: both the capabilities of the

information system determine the management

model of the combined structure, and the

management system dictates the requirements to the

information system. In the second case, the need to

quickly adapt the information system to the new

requirements of the management becomes the most

urgent.

The projects of integrating heterogeneous

information systems should use the project

management methods (Rassel, 2004), (Heldman,

2005), (Lapigin, 2008), and while implementing

them the risks emerge related both to the specifics of

this heterogeneity, and indefinite management

model of enterprise that cannot always be

determined at earlier stages. The project risks must

be managed, and this paper contains the list of risks

together with the estimate of unwanted

consequences and potential ways for their

prevention by the example of one integration

project.

The suggested integration project envisioned

affiliation of an enterprise with about 500 employees

(Enterprise 2) to an enterprise with 5,000 employees

(Enterprise 1). The status of information systems at

Enterprise 1 can be described as follows: mostly in-

house design information systems on a unified

platform with the support of the basic and auxiliary

activities with the maturity corresponding to the

maturity of the organization and a large coverage of

employees (about 1,000). At the time of merger,

Enterprise 2 had local historic systems capable of

covering a part of business-processes without broad

involvement of potential consumers. The integration

project was implemented in the following sequence:

- Analysis of business-processes including

determining requirements to the information system,

and no other requirements than the need for data

migration were determined;

- Design of the necessary interaction

infrastructure via secure communication channels;

- Installation, training, and setup of management

systems (ERP, HRM, BI, etc.);

- Preparation of data and migration;

- Commissioning and maintenance.

The major risk events together with the reasons

and consequences are found in Table 1.

In general, the following features of the project

can be mentioned: about 100 activities,

implementation timeframe of 8 months, deadline for

implementation – January 1, 2015.

Note that the project has been completed

successfully within the set timeframe, bringing the

desired results and staying within the given budget.

The results of project implementation demonstrated

in general the adequacy of assessment of risks found

in the register. For example, the risk of low

qualification of users and IT-staff of Enterprise 2

(items 4 and 5 of Table 1) turned real and demanded

not just to extend the training program, but also

reducing the number of system users at the new site,

as well as reducing the number of fist line

automation systems to complete within the deadline.

However, risk of employee resignation had not been

foreseen and had the effect on the project objectives:

a large number of employees of the new site decided

to resign being reluctant to bear extra load of the

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

222

transition period and to learn operating the new

software and methodological base (about 20% of

system users resigned; the overall resignation

percentage at Enterprise 2 was 15%). The

assessment of infrastructure risks impact can be

reduced by virtue of using the available

infrastructure and extra funding spent on hardware.

Brainstorm within a group of experts was the

methodological base for determining the list of risks.

Assessment of risk effect and probability was

determined by expert evaluation; a survey was

conducted among IT-experts 5 working on this

project, medians of individual sampling were taken

as assessments. The participating experts took part

in other integration projects related to merger of

enterprises and harmonization of their IT-systems in

the past (Enterprise 1 had merged several smaller

enterprises with the number of staff about 20%, 5%,

and 10% from the number of staff of Enterprise 1 in

the past three years), the list of risks was developed

in the course of these activities. Impacts and

probabilities of risks had not been quantified before;

nevertheless the experts had the understanding of

practical appearance of risks, other conditions were

identical. The list below summarizes the expertise of

the past projects in this area, performed within this

industry in Russia. Indeed, risks not always can be

precisely quantified, however they can be evaluated.

For example, risk # 3, obsolete computers at

enterprise, clearly has evaluative nature: if we can

express its quantitative assessment through the

number of computers (servers, other devices) that

has to be procured so that the required number of

workstations satisfies the minimum configuration of

the implemented system, then it can be clearly

quantified. Triggers that reflect manifestation of risk

and enable measuring it are included into the list of

risks for clarity purposes.

Note that the risks can be divided into the

following basic types (Lelchuk, 2014), (Madera,

2014):

- Risks related to procurement procedures (the

procurement system in Russia has recently been

made much more complicated, leading to the

increase of potential risks in the area of violating the

delivery dates of subcontract);

- Infrastructure risks related to the technical

features of the systems and potential equipment

failures, as well as the risks of infrastructure

incompliance with the requirements of implemented

systems;

- Risks related to organizational behavior of the

staff;

- Finance and international risks.

Risks related to estimate of change readiness are

described using DVF>X (Dissatisfaction, Vision,

First steps, Expenses) model (Dannemiller Tyson

Associates, 2000) and can be assessed as high in the

projects of integrating information systems during

the merger of different legal entities.

Table 1: List of risks.

No. Risk event

Consequen

Reason Trigger Effect

Proba

bility

Measure Method

Risk

preventi

on plan

Risk

response

plan

Lack of

supply

contract

within the

set

timeframe

Delay of

the project

implement

ation

Long time

to prepare

for tender

Supply

contract not

signed

0.425 0.3 0.1275 Minimize

Slack

time for

procure

ment

Transfer of

equipment

available on

other

projects

Violation

delivery

date under

supply

contract

Delay of

the project

implement

ation

Supplier’s

unconscien

tiousness

Equipment

not supplied

0.475 0.1 0.0475 Minimize

Slack

time for

procure

ment

Transfer of

equipment

available on

other

projects

Obsolete

computers

Enterprise

Replaceme

nt of

equipment

Inaccurate

survey

prior to the

project

New user

with

computerize

workstation

below the

minimum

requirement

0.45 0.7 0.315 Accept

Procurement

of surplus

equipment

RiskManagementinProjectofInformationSystemsIntegrationDuringMergerofCompanies

223

Table 1: List of risks (cont.).

No. Risk event

Consequen

Reason Trigger Effect

Proba

bility

Measure Method

Risk

preventi

on plan

Risk

response

plan

Low

qualificati

on of

users

Delay of

training

Insufficient

training in

the past

User cannot

cope with

the training

program

0.45 0.7 0.315 Accept

Prepare

extended

training

program

Low

qualificati

on of IT-

departmen

t at

Enterprise

Delay of

software

installation

and

infrastruct

ure setup

Insufficient

training

and labor

remunerati

IT-

department

cannot setup

new

software

0.6 0.5 0.3 Accept

Start

training

earlier

Delay in

establishin

communic

ation

channel

Incapabilit

y to

complete

activities

in all areas

Technical

issues at

the service

provider

Channel not

functioning

0.65 0.5 0.325 Avoid

Slack

time

Deploy

system with

replication

via the

Internet

Increase

in the

number of

potential

users

Greater

labor

intensivene

ss of

training,

extra costs

for

equipment

and

licensing

Poorly

prepared

project

Application

for

additional

users

0.4 0.7 0.28 Minimize

Appoint

the task

to the

functio

nal

services

for

determi

ning

needs

Larger

number of

employees

working on

the project

Additional

requireme

nts to the

systems

during

implement

ation

Greater

labor

intensivene

Specifics

administrat

ive

arrangemen

ts at

Enterprise

Additional

functional

requirement

0.45 0.9 0.405 Accept

Allocating

additional

resource

Absence

of key IT-

experts on

the project

(illness)

Longer

duration of

activities

Incident Sick leave 0.5 0.3 0.15 Accept

Allocating

other

experts

Lack of

interest of

customers

in the

system

implement

ation

Longer

duration of

activities

Customer

does not

understand

advantages

of IT

Managers of

departments

show no

interest in

the project

0.55 0.1 0.055 Avoid

The

project

should

include

only the

subsyst

ems,

demand

ed by

the

custom

Meeting

with the

manager of

the involved

department

in order to

change the

project

Resistance

of the

users

Longer

duration of

activities

Users do

not

understand

the urgency

for new

system

No active

(daily) use

of the

systems

0.4 0.7 0.28 Accept

Use

methods of

change

management

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

224

Table 1: List of risks (cont.).

No. Risk event

Consequen

Reason Trigger Effect

Proba

bility

Measure Method

Risk

preventi

on plan

Risk

response

plan

Embargo

for supply

of foreign

software

Incapabilit

y to use the

document

circulation

system

Global

political

situation

Additional

licenses are

blocked

0.35 0.1 0.035 Accept

Change the

project goals

Increase

equipment

cost due

currency

exchange

rate

Extra

costs,

smaller

number of

users

Exchange

rate

fluctuations

The final

price is

larger than

expected

0.3 0.3 0.09 Accept

Request to

increase

budget

Funding

cut on the

project

(sequestra

tion)

Smaller

number of

users

General

economic

situation at

the

enterprise

Decision on

sequestratio

0.325 0.1 0.0325 Avoid

Provide

reserve

at the

start

Readiness

for

sequestratio

Additional

requireme

nts to the

systems

from the

external

organizati

ons

Higher

burden on

key experts

outside the

frames of

the project

Requireme

nts of

external

regulators

Legal

changes

0.3 0.5 0.15 Accept

Demand

additional

resource for

the project,

if the

available

experts are

distracted

The aforesaid risks can have impact on

implementation timeframe of both individual

activities, and the project as a whole at various

stages of implementation. One of the characteristics

of a risk is the probability of its occurrence that

determines the probabilistic nature of time estimate

of the project implementation as a whole. Besides,

the risk prevention measures require increasing the

planned implementation time and extra costs. After

implementing the risk reduction measures, the

probability either becomes 0, or goes down (takes a

new value), and this probability depends on the cost

(the nature of function is non-linear, however we can

assume the monotonous nature of the function: the

bigger the costs, the smaller the probability). Thus,

one of the objectives of the project management can

be to minimize the costs for achieving the target

probability of guaranteed implementation of

activities before the deadline. Note that estimating

the nature of the project implementation timeframe

distribution is a stand-alone mission and is not the

topic of this paper.

Let

- multiplicity of project stages;

- number of project stages on the critical

path;

- i

number of project, i=1..N;

- implementation time of i

project stage,

i=1..N;

- multiplicity of risks;

- number of risks;

- j

risk, j=1..M;

- probability of j

risk occurrence, j=1..M;

- association matrix of j

risk with i

stage;













otherwise 0,

stage, iat occur can risk j ,1

thth

(1)

Since all the project activities on the critical path

(Shikin, 2002) are executed one after another, then

the overall time of project implementation equals:

RiskManagementinProjectofInformationSystemsIntegrationDuringMergerofCompanies

225





(2)

and the probability of project completion (Ventcel,

2005) before the deadline equals:







)1(

(3)

For the aforesaid project, the probability of

completion on time was 0.0000098, i.e. a negligible

quantity. A number of measures could increase this

value, but that would require extra costs, and the

timeframe of executing the project stage could

increase as well.

Let us denote:

t

- time, by which the project implementation

increases thus reducing the probability of j

risk

occurrence by 0.1;

- costs required to reduce the probability of j

risk occurrence by 0.1;

- probability of j

risk occurrence after the

measures aimed at its reduction,

then the overall time of project implementation

equals:









jjjji

xptKtT

))1.0/)((max(

(4)

the probability of project completion on time equals:







)1(

(5)

extra costs for the project equal







jjj

xpdD

)1.0/)((

(6)

In practice, it is important to estimate the project

completion timeframe at probability at least 90%

and minimum costs. This estimate can be performed

according to expression (6) by resolving the

optimization task (7)-(9)

min)1.0/)((







jjj

xpd

(7)

9.0)1(







(8)

px 0

(9)

It is often required to estimate the probability of

project completion on time at minimum costs as

well. This estimate can be performed according to

expression (6) by resolving the optimization task

(10)-(12)

min)1.0/)((







jjj

xpd

(10)

TzxptKt

jjjji









))1.0/)((max(

(11)



(12)

Estimate of costs for project implementation at

probability at least 90% and minimum

implementation time is also urgent. This estimate

can be performed according to expression (4) by

resolving the optimization task (13)-(15)

min))1.0/)((max(









jjjji

xptKt

(13)

9.0)1(







(14)



(15)

For resolving these tasks, the linear programming

methods can be used (Tomas, 2006).

Using the above model, the timeframe of

implementing the project of merger of Enterprise 1

and Enterprise 2 was estimated and the optimal

relationship between the costs and the

implementation timeframe was found.

Note that this model does not take into account

the non-linear nature of function of project

implementation time vs. costs of risk reduction

measures, the nature of impact of various risks at

individual stages, and change of the impact

throughout the project implementation, as well as

the risk distribution law.

3 CONCLUSIONS

Thus, use of the described approach enabled

performing the integration of information systems of

two industrial enterprises with different IT-

infrastructure while complying with the cost and

quality parameters implementing the project

objectives. Risk-oriented approach gave grounds to

increase the transparency of managing the

integration project, which implemented the business

requirements to unify the business-models of

enterprises.

There is no doubt that the list of risks can be

revised for specific conditions of the project,

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

226

including location, political and other factors,

however, the authors believe that due to insignificant

number of activities at the current stage of

information science in the area of risk management,

the outlined list will serve as a guide for the IT-

managers when integrating information systems.

Further investigation of this subject by the

authors includes collection of statistical data

throughout integration projects while merger or

reorganization of instrument-making enterprises in

order to refine the realistic probabilities of risk

events and to update their effect when needed, as

well as practical use of the suggested approach in

realistic integration projects. Besides, studying

features of organizational behavior of employees at

merged enterprises relative to information systems

as a factor affecting the success of the project

deserves a dedicated investigation in future.

REFERENCES

Dannemiller Tyson Associates, 2000. Whole-Scale

Change, Berrett-Koehler Publishers.

Heldman, K., 2005. Профессиональное управление

проектами, Binom. Moscow.

Lelchuk, A., 2014. Актуарный риск-менеджмент,

Ankil. Moscow.

Lapigin, Yu., 2008. Управление проектами: от

планирования до оценки эффективности, Omega-

L. Moscow.

Madera, A., 2014. Риски и шансы: неопределенность,

прогнозирование и оценка, URSS. Moscow.

Rassel, D., 2004. Managing High Technology Programs

and Projects, Academia IT. Moscow.

Romanov, O., 2013. Комплексная автоматизация

приборостроительных предприятий. Пример

внедрения на ЗАО «Орбита». CADMaster, 5, p.44-

51.

Shikin, E., 2002. Математические методы и модели в

управлении, Delo. Moscow.

Shumsky, L., Roslovtsev V., 2014. Processes

Constructions and π-calculus-based Executions and

Tracing, Proceedings of the 16th International

Conference on Enterprise Information Systems.

SCITEPRESS.

Tomas, H., 2006. Линейное программированиe.

Алгоритмы: построение и анализ, Wiliams.

Moscow.

Trienekens, J., Kusters R., 2014. Structuring Software

Measurement - Metrication in the Context of Feedback

Loops, Proceedings of the 16th International

Conference on Enterprise Information Systems.

SCITEPRESS.

Ventcel, E., 2005. Теория вероятностей, Academia.

Moscow.

RiskManagementinProjectofInformationSystemsIntegrationDuringMergerofCompanies

227