=Paper=
{{Paper
|id=None
|storemode=property
|title=Enterprise Modeling in Complex ERP Adoptions: Learning from the Experience of an IT Company
|pdfUrl=https://ceur-ws.org/Vol-1023/paper9.pdf
|volume=Vol-1023
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/TrabkaS13
}}
==Enterprise Modeling in Complex ERP Adoptions: Learning from the Experience of an IT Company==
https://ceur-ws.org/Vol-1023/paper9.pdf
Enterprise Modeling in Complex ERP Adoptions:
Learning from the Experience of an IT Company
Jan Trąbka1, Piotr Soja1
1
Cracow University of Economics, Department of Computer Science,
Rakowicka 27, 31-510 Kraków, Poland
{Jan.Trabka, Piotr.Soja}@uek.krakow.pl
Abstract. This study reports on the experience of enterprise modeling within
the ERP (Enterprise Resource Planning) system implementation project in an IT
company in Poland. The project was complex due to project-intensive company
organization and resulting information requirements, comprehensive logistic
and service processes, and the necessity of ERP integration with specialized
service applications. The study seeks to analyze the role of enterprise process
modeling during the initial phases of large-scale implementation projects. It
discusses modeling process from the perspective of human resources, tools
employed, and process organization. Conclusions highlight both mistakes and
best practices observed in the modeling process. Main findings indicate that the
strategic significance and risk of modeling process increase along the scale of
company’s activities and complexity of processes and environment.
Keywords: ERP, implementation, modeling, pre-implementation analysis.
1 Introduction
ERP system adoptions run the risk of failure which grows with the complexity of a
company’s business processes and scale of operations. Among critical success factors
for this kind of projects, the significant roles are played by an adequate definition of
requirements, project team experience, and involvement of the adopting company
resources [4]. Considering model approaches to the ERP lifecycle, it appears that the
pre-implementation analysis is the main stage which ends in the agreement and
definition of the requirements for the target system [10, 14]. In consequence, we may
conclude that a good pre-implementation analysis is a critical precondition for a
successful ERP adoption project.
During pre-implementation analysis, the modeling of enterprise and its business
processes is performed [1, 3]. The importance of these activities grows along the level
of changeability of a company’s economic setting. This particularly refers to
transition economies, i.e. economies in transition from communist style central
planning system to free market system [11]. The fast changing business environment
in transition economies results in the necessity to treat enterprise modeling as a
separate project with a separate contract and agreements [15].
The goal of this study is to report on the experiences in enterprise modeling and
pre-implementation analysis performed within the ERP adoption project conducted in
a company from IT industry in Poland, a transition economy. The focal company is
characterized by a project-oriented management approach, complex internal
processes, and extensive range of internal IT systems. This study provides details on
the modeling process and discusses observed best practices and mistakes. This report
concludes with the discussion of the effectiveness of the whole adoption project and
possibilities of its improvement through good practices applied during the modeling
and analysis stage.
2 The Case Company and ERP Implementation Background
A company from IT industry, named “IT Firm” in this report, is the focal organization
in this study. A company providing implementation services in the considered ERP
adoption project in named “ERP Supplier”. IT Firm specializes in computer system
integration and company activities include the following:
System integration – IT Firm is a nationwide integrator of computer systems and
its activities and services include analysis of customer needs and resources,
systems design, pilot project implementations, final project implementations,
acceptance tests, and post-implementation maintenance.
Building automation systems – IT Firm offers a majority of currently available
systems used in modern buildings and provides technical consultancy, integrated
design, and project implementation and maintenance.
IT services and outsourcing – implementation and maintenance of the ICT
infrastructure of the company’s clients, on a both standard and outsourced basis.
The company has 18 branches scattered over the whole country and offers its
services to companies and institutions operating in public administration, banking
and financial sector, telecommunication, manufacturing, trade, and service. The
company employs 400 people.
IT Firm is a project-driven organization and its activities are divided into projects
conducted for the company’s clients and governed by the signed contracts. The key
information required by the company’s management refers to the projects
profitability, which requires the granular and multidimensional cost and profit
accounting. For the purpose of this study we will call various dimensions of cost and
profit accounting (i.e. projects, organizational units, product and service types etc.)
controlling cross-sections. The data gathered within an organization (payroll,
purchase and sale invoices, etc.) have to be classified (recorded) simultaneously into
all controlling cross-sections that are important from the perspective of managerial
analysis. The company needed the reporting mechanism able to present the
aggregated data in multidimensional controlling cross-sections. IT Firm, before
making a decision on the implementation of a new software solution, was using an
ERP system which did not have any dedicated module for project management or
analytical tool satisfying the requirements of a project-driven approach. As a result,
improvement in project reporting became the first goal of the new system
implementation.
The second goal included the optimization and integration of business processes
within the whole organization. The most difficult area involved services, with a
special focus on so called service logistics. The company employed a dedicated portal
to manage service requests, accessible by both customers and company’s employees
from various departments such as service, logistics, and call center. Using service
portal, a client registers its service requests and then is able to track their status. The
service portal was not integrated with the ERP system which resulted in process
discontinuity and excessive workload required in order to meet service deadlines. In
consequence, optimization and integration of IT processes and systems became the
second goal of the new system implementation.
3 Enterprise Modeling Process in IT Firm
3.1 Implementation Methodology
The implementation methodology, adopted in the project conducted in IT Firm with
the support of ERP Supplier, is based on three pillars:
international project management standard PRINCE 2 [2, 8],
agile project management methodologies such as SCRUM [12, 13],
flexible architecture of the system being implemented and the provider’s extensive
experience gained during a few hundred implementation projects in various
industries.
The implementation methodology hinges upon three basic rules:
phased approach to project planning and control,
project tasks progress monitoring on the basis of project products,
prototyping during the phase of user requirements implementation.
The whole implementation project cycle is depicted in Fig. 1. Next sections shortly
describe two aspects of the methodology: main stages of the project run (Pre-
implementation analysis and Requirements implementation) and project task
verification rules.
Pre-implementation analysis – involves specification of processes, with a map of
top-level processes as a starting point for creating a hierarchical list of processes.
Next, the processes are being decomposed into the elementary processes.
Requirements implementation – is the longest stage of the project and is
conducted together with trainings, which is imposed by the prototype approach.
This approach involves creating prototypes of elementary processes defined at the
analysis stage. The prototype is delivered to the Key Users for testing. Then, after
introducing corrections to the prototype, repeated testing takes place and such an
iteration repeats until the final acceptance of the prototype, which becomes part of
the new final solution.
The project stages and methods of progress verification illustrate the key role of
pre-implementation analysis, which should include appropriate definitions of
processes being implemented in the new solution. Processes become project products
that, in the next stages, form a framework for the project schedule and control
mechanism.
End
Stages Go-life
Stabilization
Go life
Integration tests
Pre-
implementation
analysis Training
System
installation Implementation
Initiation
Time
Fig. 1. Implementation project stages in IT Firm
3.2 Implementation Project Run
ERP system selection process in IT Firm started in 2006. In May 2007, a decision on
enterprise system implementation had been made. The chosen system has been
produced and implemented by the ERP Supplier. Two elements determined the
system choice: (1) an extended project management module integrated with the other
modules and (2) the overall system flexibility caused by its multi-layer architecture
and a range of software tools enabling system customization. The general project
schedule covered a one year time period with a productive start scheduled for
January 1, 2008.
The general project schedule was divided into the following stages:
Project preparation (PP)
Analysis of business requirements (ABR)
Implementation, divided into functional areas
Logistics and sales
System adaptation
System testing
Productive start
Stabilization
CRM (with similar sub phases as in the case of logistics and sales)
Finance and accounting, fixed assets, HRM
The analytical works started in June 2007. In practice, phases PP and ABR have
been merged. During the first meeting, project managers from both sides agreed the
rules of project team composition, methods of communication and control, and the
schedule for the first month of analytical works. A project initiation document (PID)
has been prepared, which was presented during the first meeting of the analytical
team (kick-off meeting).
3.3 Analytical Team
The project team involved the following stakeholders:
Steering committee – a body of top management representatives from both
companies delegated to the project supervision. In the analyzed project, the
committee has been lead by a vice-president of IT Firm, who also served as a
project sponsor. The supplier’s side was also represented by a person from top
management – a director of operations in ERP Supplier.
Project manager – was responsible for supervision and coordination of activities
conducted by units involved in the project from the IT Firm’s side. Project
manager was responsible for communication in the project team and with the
steering committee. Project manager, together with project coordinator, made
operational decisions in the project. In the analyzed project, project manager role
was played by a director of IT department in IT Firm.
Project coordinator – was responsible for supervision and coordination of
activities conducted by units involved in the project from the ERP Supplier’s side.
In the analyzed project, project coordinator role was played by a director of
implementation department in ERP Supplier.
Key users – a team of specialists from various areas of IT Firm involved in all
stages of the project and responsible for verification of all solutions being
implemented (project products). In the analyzed project, key users were recruited
among managers of departments and teams working in the areas affected by the
implementation project.
Key developers – employees of ERP Supplier with broad implementation
experience in individual functional areas. Responsible for creating and delivering
project products. A team for analytical support was involved among ERP
Supplier’s representatives. Its members were responsible for implementation
methodology, analytical tools, and documentation.
3.3 Analytical Tools
A document named Pre-implementation Analysis (PA) was the main product of the
analysis stage. It was a model of information system in the organization managed
with the help of the new IT system. In the analyzed case, PA also included
organization- and project-related elements (e.g. schedule). The adopted approach to
enterprise’s information system was based on the structural analysis and design [16]
where models of data and processes were the most important elements of the system.
PA document was divided into the following parts: Analysis organization,
Organizational characteristics, Map of processes with proposed solutions, Project
organization, and Schedule.
Process model. Process model included Data Flow Diagrams (DFD) and process
specification.
Data Flow Diagrams (DFD) – depicts the system as a grid of information processes
connected by data flows and data repositories. In the analyzed project, the
modeling process started at the topmost level (level 0) which illustrates all main
information processes of the organization (see Fig. 2). Next, each main process is
decomposed and detailed until the elementary process.
Client
contracts
Diagnostician
services goods
Sale
Sale
diagnosis of
of building
building
automation
automation
Sale
Sale of
of maintenance
maintenance Sale
Sale
services
services of
of goods
goods
goods
orders
Technician
goods goods
equipment
Manage
Manage goods
goods and
and equipment
equipment procurement Vendor
equipment
Manage
Manage Human
Human
Resources
Resources
accounting
salary
documents
Employee accounting
documents
Board Bank
decisions transfer
Manage
Manage finances
finances
reports
Financial
Institutions
Fig. 2. IT Firm’s DFD 0
Process specification – each elementary process was defined with the help of a so
called process card. Specifications were created in natural language; however,
thanks to a formalized layout of the process card, they were unambiguous and
precise. On the whole, IT Firm’s model included 82 processes specified in this
way.
Data model. The most important tools in data model included data dictionaries.
Data dictionaries – included: element name, description, type, necessity, and
default value. The field “description” was especially important as it defined and
clarified the understanding of attributes in the analyzed organization.
3.4 Analysis Run
During the preparatory stage of the project, the project team was divided into domain
teams created for the following areas: service, logistics, sales/CRM, finance, and IT.
The adopted division turned out to be not adequate as, from the very beginning,
people from service and logistics areas worked together. The schedule assumed
meetings of teams at the same time and place so that mutual experience could be
exchanged. However, in time, such a discipline disappeared and in consequence area
teams worked according to their individual schedules and often in distant regions of
the country.
Activities in the area of service and logistics. The team met on a regular basis
and adopted the most detailed analytical perspective. The IT Firm’s logistic team had
a previous experience in business process modeling gained in past projects, when they
used MS Visio and created process diagrams similar to BPMN notation [9]. This
experience was very useful during the analysis and definition of company processes
using DFD and process cards. The logistic team was very involved and motivated
which resulted from the large scale of the team activity, as they had to handle a few
thousand of service requests per month. In fact, a very difficult aspect of service-
logistic activities was connected with the necessity of using two separate software
tools. Customers, servicemen, call-center workers used the service portal for
registering and handling requests. Logisticians, in turn, were handling materials and
service equipment in the ERP system. In consequence of the analysis, the required
interface was defined.
Activities in the area of finance. The financial team adopted an assumption that
only processes relevant for the activities of financial department have to be modeled,
such as cash register, bank transfers, and chart of accounts. The logistic team adopted
an opposite assumption and presumed that the financial team is responsible for the
definition of accounting schema and business rules binding logistic and accounting
operations. In consequence, these connections were defined just during the project
run, which was sometimes connected with changes in processes. Overall, the
requirements overlooked origin of data and impact of other areas’ requirements on
controlling processes. It was assumed that members of other teams would handle
controlling-related issues in their processes. Overall, processes were defined at a very
general level and did not reach elementary level.
Activities in the area of sales/CRM. The sales/CRM team worked separately
from other groups due to its distinct location. Before the project start, this area
employed the largest number of nonintegrated software solutions, mainly desktop
applications. In consequence, the vision of a uniform, integrated solution was very
difficult to develop. The team did not put any effort into a detailed modeling of the
client acquisition process and preparation of offers or contracts depending on a
client’s business background. The process definition was restricted to a text-based
description linked to the abovementioned sales procedure and other official
regulations. The data structure analysis nor process decomposition was not
performed.
4 Discussion and Lessons Learned
The discussion of findings has been conducted using an approach similar to the
perspectives employed in the previous section, i.e. human resources, tools, and
analytical process run. We arrived at this decision considering the three main
components of information systems: organization, management, and technology [5]
and also drawing from product development and operations management area [6].
4.1 Human Resources
Project management staff empowerment. In the analyzed project, the
empowerment of the chief of the steering committee, who was also the project
sponsor, played a very significant role. The appointed person was a member of the
company board, which assured access to company’s resources. The project manager,
who was an IT director, assured an effective project organization and good
communication with the ERP Supplier’s team. Nonetheless, the key users’
empowerment raises doubts because, despite having adequate knowledge, they did
not have a crucial influence on organizational changes or team members’ availability.
Knowledge exchange between the analytical and implementation teams. The
key determinant of the overall ERP implementation success is connected with
transferring knowledge about the organization from the analysis stage to further
stages. This transfer may refer to explicit knowledge (e.g. analytical documents) and
tacit knowledge (e.g. gathered in the analysts’ minds) [7]. The applied
implementation methodology, proposed by ERP Supplier, assumed that the key
developers were also leaders of the area teams. Such a solution turned out very
beneficial during the later phases as the key developers started to get to know people,
organization and their problems right from the beginning of the project.
Coordinating the effects of analytical works. The role of the project manager
was to manage the organizational aspects of the project. She was not responsible for
the quality of the final product, which was the PA document in the investigated case.
Building on the experience of the analyzed project, the suggested recommendation is
to empower the project manager with authority to control the final effect of conducted
works.
4.2 Tools
Modeling organizational and system structure. The formal organizational structure
was missing in the PA document. Such a structure is a basis for developing roles and
user rights in the system. Skipping roles in process modeling prevents the analysts
from discovering possible organizational responsibilities and interdependencies which
may result from differences between allocated and actually performed organizational
duties.
Process modeling. In the applied process modeling, the context level was missing,
where the organization should be modeled as a black box with emphasis put on
objects from the environment handled by the information system. The most
convenient tool for illustrating and negotiating system behavior, used by many system
analysis and design frameworks, are context diagrams [16]. In practice, lack of this
perspective leads to overlooking major system stakeholders. In the analyzed case,
missing context level resulted in lack of answer to a fundamental question: for whom
the system is being built?
Modeling inter-system interfaces. Interfaces between information systems are
usually difficult and risky elements; therefore, they should be carefully modeled
during the analysis stage. In the investigated case, the modeling was restricted to the
textual description what the resulting changes were in the service system when a
particular process activity occurred in the ERP system. A data exchange mechanism
useful for software developers was not modeled, although the system was supposed to
work in an on-line mode. Building on the experiences of the analyzed study, the
authors suggest to develop a prototype of a partial interface in order to verify if the
project assumption were satisfied.
4.3 Analysis Run
Phased approach and budget. In the investigated project the pre-implementation
analysis was a separated stage; however, its results could not have had impact on the
project budget and time. The authors’ suggestion therefore is to keep an
implementation contract not signed until the analysis stage is finished, even with the
possibility of canceling the whole project.
Domain-based analytical works. The division of the analytical team on the basis
of business areas might not match the developed process model. It is difficult to
prevent such a situation; however, it is beneficial to be aware that the initial division
might be subject to change. Learning from the investigated project, it is suggested to
delegate “inspectors” of the analysis integrity. In the discussed case, such inspectors
might have been recruited from the controlling or project management departments.
5 Conclusion
This study investigated experiences of enterprise modeling gained during the complex
implementation of an ERP system in a company operating in IT industry in Poland.
Such projects bear significant risk of failure which increases with growing complexity
of a company’s business processes and scale of operations. The performed analysis
indicates that the risk of failure is inversely proportional to the quality of a developed
enterprise model and this relationship is influenced not only by technical factors, but
also by human-related and organizational elements. The investigated case illustrates
that the following factors had the most significant influence on the modeling quality:
too general level of process definition,
unclear definition of interfaces between the ERP system and legacy systems,
lack of consistency in the application of the adopted methodology,
lack of supervision over the whole modeling process.
In general, this study’s findings suggest that the properly conducted pre-
implementation analysis is a very significant instrument in minimizing risk of
implementation project failure. Therefore, increased resources invested in a high
quality analysis are strategically justified and should pay off.
References
1. Berio, G., Vernadat, F.: Enterprise modelling with CIMOSA: functional and organizational
aspects. Production Planning & Control, 12(2), 128--136 (2001)
2. Bradley, K.: Understanding Prince 2. Spoce Project Management Limited, Dorset (1997)
3. Dalal, N.P., Kamath, M., Kolarik, W.J., Sivaraman, E.: Toward an Integrated Framework
for Modeling Enterprise Processes. Communications of the ACM, 47(3), 83--87 (2004)
4. Finney, S., Corbett, M.: ERP implementation: A compilation and analysis of critical success
factors. Business Process Management Journal, 13(3), 329--347 (2007)
5. Laudon, K., Laudon, J.: Essentials of Management Information Systems. 10th Edition,
Prentice Hall, Upper Saddle River, New Jersey (2012)
6. Morgan, J.M., Liker, J.K.: The Toyota Product Development System: Integrating People,
Process and Technology. Productivity Press, New York, USA (2006)
7. Nonaka, I., Takeuchi, H.: The Knowledge-Creating Company: How Japanese Companies
Create the Dynamics of Innovation, Oxford University Press, Inc., New York (1995)
8. OGC: Managing Successful Projects with PRINCE2® 2009 Edition. The Stationery Office,
London (2009)
9. Panagacos, T.: The Ultimate Guide to Business Process Management: Everything you need
to know and how to apply it to your organization. Theodore Panagacos (2012)
10.Ross, J.W., Vitale, M.R.: The ERP Revolution: Surviving vs. Thriving. Information Systems
Frontiers, 2(2), 233--241 (2000)
11.Roztocki, N., Weistroffer, H.R.: From the special issue editors: Information technology in
transition economies. Information Systems Management, 28(3), 188--191 (2011)
12.Schwaber, K.: Agile project management with Scrum. Microsoft Press, Washington, USA
(2004)
13.Schwaber, K., Sutherland, J.: Scrum Guide, Scrum Org, http://www.scrum.org/Scrum-
Guides (2011)
14.Somers, T., Nelson, K.: A taxonomy of players and activities across the ERP project life
cycle. Information & Management, 41, 257--278 (2004)
15.Themistocleous, M., Soja, P., Cunha, P.R.: The Same, but Different: Enterprise Systems
Adoption Lifecycles in Transition Economies. Information Systems Management, 28(3),
223--239 (2011)
16.Yourdon, E.: Modern Structured Analysis. Prentice Hall (1989)