Applying Business Process Modeling Tools in Enterprise Resource
Planning System Replacements
A Case Study
Stephan Groß
1
and Justus Holler
2
1
Prof. Becker GmbH, Luetke Berg 4-6, 48341 Altenberge, Germany
2
University of Muenster – ERCIS, Leonardo-Campus 3, 48149 Muenster, Germany
Keywords: Change Management, Business Process Modeling Tool, Enterprise Resource Planning.
Abstract: Enterprise resource planning systems are the IT backbone of companies in the IT markets and in all those
where efficient and integrated business processes are a necessity to stay competitive. As the markets change
also the IT requirements do and the need for an Enterprise resource planning system replacement rises. This
article argues that business process modeling tools can be used to document and communicate changes in
the operational and organizational structure related to the replacement. The suitability of a tool with typical
modeling features is evaluated within a project. The findings regarding semantics, structure, documentation,
and re-usability are discussed and an outlook for future research is given.
1 MOTIVATION
In order to meet the constantly rising market
expectations information technology (IT) does
matter (Carr, 2003). Especially for large companies
with complex and interleaved processes a well-
designed Enterprise resource planning system (ERP
system) supporting all business processes
(Davenport, 1998) is of particular importance.
During ERP system usage a point will be reached
where the individual adaptation (in case of
individual software) or the updates (in case of a
standard ERP system e. g. SAP AG's ERP Central
Component, SAP ECC) are not satisfying the
customer needs anymore or are too costly. At this
point in time the replacement of the complete ERP
system is required. The migration from the old
system to the new one is a complex and time-
consuming project (Huang, Hung, Chen & Ku,
2004; Peslak, Subramanian & Clayton, 2008). This
project and its subprojects are nearly always
supported by external consultants because the
required ERP system knowledge is not present and
the human resources are missing.
In such projects tools like Microsoft Project or
more sophisticated tools are often used. In this
article we focus on business process modeling tools
(BPM tools) supporting the change management
subproject. Literature states, that these tools have a
positive influence on critical success factors like
understanding the current and new business
processes including their IT and organizational
interrelations (as-is and to-be models) (Holland &
Light, 1999; Nah, Lau & Kuang, 2001). Hence, we
argue that BPM tools are particularly well suited in
documenting and communicating the changes.
But often the usage of the BPM tool is a project
in its own. A full grown tool like the Architecture of
Integrated Information Systems Toolset (ARIS
Toolset) (Scheer & Nüttgens, 2000) is too complex
for simply supporting the external consultants with
their documentation. In contrast, tools like Microsoft
Visio or Microsoft PowerPoint are too limited
regarding their modeling functionalities. Therefore,
the research questions of this article are:
 RQ1: Are BPM tools well suited for
documenting and communicating changes
related to ERP replacements?
 RQ2: Which features are especially relevant
for a BPM tool in order to efficiently support
the documentation and communication of
changes in the context of an ERP
replacement?
The remaining article is structured as follows: in
the next section the case and research method is
202
Groç S. and Holler J.
Applying Business Process Modeling Tools in Enterprise Resource Planning System ReplacementsA Case Study.
DOI: 10.5220/0005426102020208
In Proceedings of the Fourth International Symposium on Business Modeling and Software Design (BMSD 2014), pages 202-208
ISBN: 978-989-758-032-1
Copyright
c
 2014 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

presented. In Section three the main features of the
BPM tool within the running project are discussed.
The last section concludes the findings and outlines
future research potential.
2 RESEARCH METHOD IN THE
PROJECT
One of the main discounters operating across Europe
is replacing its individual piece of ERP software by
SAP ECC for Retail. This happens because the old
software did not meet the clients’ expectations
anymore regarding integrated processes, centralized
data management, and performance. An agile
method for ERP replacement is chosen in order to
have a runnable prototype at an early stage in the
project. The prototype is developed continuously
with all involved stakeholders. The main
characteristics of the project and company are
depicted in Table 1.
Table 1: Project and company overview.
Dimension Description
Purpose ERP replacement
Method Agile
Duration Summer 2012 – approx. summer 2014
Domain International Warehousing
Articles Food and Non-Food
Employees Approx. 80 (only employees involved)
Customers Business-to-business customers
Budget Approx. 3,000,000 euro
The project has several subprojects like
migration, test management, support, training, and
change management. Within the latter subproject
one goal is to determine and manage the changes
related to the system replacement. This is done in
the three phases identification, documentation and
communication as depicted in Figure 1 and
described in the following subsections.
Figure 1: Research steps.
2.1 Identification Phase
In the first phase of the research 9 interviews are
conducted in order to learn about the as-is processes.
The external consultants also have the opportunity to
observe the daily business and to take notes. The
results of this phase are the as-is processes including
descriptions regarding IT systems and
responsibilities. Furthermore, the interviewees are
asked for possible improvements from their point of
view. This feedback is incorporated in the to-be
processes directly. It is also explicitly addressed in
the communication phase in order to improve the
acceptance of the new to-be processes.
2.2 Documentation Phase
On the one hand the changes were anticipated within
the business processes (gap analysis between as-is
and to-be processes) and on the other hand within
the organizational structure. The findings of the
analysis and the input of the interviewees and
workshops help to optimize the business processes,
determine staff requirements (new positions or
changed position descriptions within the
organizational hierarchy) and support the key- and
end-user trainings for the new ERP system
(communication phase).
Due to constraints in the project there is no time
for implementing a project specific tool supporting
the process analysis. Hence, a BPM tool is selected
which is suitable for the purpose of describing the
operational and organizational structure changes.
The selection of the tool is based on the following
key features:
 Business processes modeling on multiple
levels
 Support of organizational and IT structures
 Central glossary for project terms and model
elements
 Modeling conventions enforced
 Re-usable (reference) models
 Easy access for stakeholder
After a tool (Becker, Clever, Holler & Shitkova,
2013) satisfying all the above features is selected the
collected data in phase 1 is documented with the
tool. The findings regarding the suitability of such a
BPM tool in the context of an ERP replacement is
discussed in section 3.
2.3 Communication Phase
In the last phase the outcome is presented and
discussed in workshops and the process models are
adjusted were necessary. Also the final
documentation is created including all
1. Identification
Interviews an d
workshops
2. Documentation
Analysis and
modeling
3. Communication
Workshops
Operational and organizational
data
Models
Documentation
A
B.1 B.2
C
A
B.1 B.2
C
E
G
Applying Business Process Modeling Tools in Enterprise Resource Planning System Replacements - A Case Study
203

organizational, operational and IT system changes
related to the ERP replacement. The features the
BPM tool provided regarding communication are
discussed in the next section, e. g. stakeholder tool
access or reporting and export functionalities.
3 KEY FEATURES OF A
BUSINESS PROCESS
MODELING TOOL WITHIN
SYSTEM REPLACEMENTS
The following section discusses the suitability of the
above mentioned and further features (Table 2) for
supporting the change management within an ERP
replacement clustered in the following sub-sections.
Table 2: Key features in the project.
Feature Cluster
Syntax checker Semantic standardization
Integration of semantics Semantic standardization
Inclusion of modeling
conventions
Semantic standardization
Integration of a glossary Semantic standardization
Harmonized layers of
abstraction in processes
Structured models
Organization charts Structured models
IT system charts Structured models
Attribution Integrated documentation
Export and reporting Integrated documentation
Reference process
elements
Re-use of knowledge
Best-practice models Re-use of knowledge
3.1 Supporting Model Quality by
Semantic Standardization
An often mentioned tool feature is the possibility to
support the user in checking the model syntax. This
is definitely a nice feature to enhance the model
quality. In this context it is questionable if and how
model quality can be measured by means of
syntactical correctness. Although many metrics are
defined in literature for model quality (Moody,
2005) the most important quality aspect of a
syntactically and semantically correct model is its
“fitness for use” with respect to its purpose (Becker,
Rosemann & von Uthmann, 2000; Rittgen, 2009). A
model as abstract representation of reality should
exclude not relevant details and focus on the main
aspects regarding the purpose of the model (Dean,
Orwig, Lee & Vogel, 1994). Typical purposes of
process models are to cope with the process
complexity, to document it, and to support
conceptualization, analysis and communication
(Dean, Orwig & Vogel, 2000; Ould, 1995; Van Hee,
1994; Becker, Kugeler & Rosemann, 2011). For
satisfying these purposes a process model has to take
the semantics of the process into account. Hence, the
tool should foster semantic correctness by increasing
the clarity, comparability, readability, and
manageability of the models by implicit inclusion of
modeling conventions (Mendling, Reijers & van der
Aalst, 2008; Becker, Rosemann & Schütte, 1995;
Becker, Clever, Holler, Püster & Shitkova, 2013a).
A further aspect of semantic standardization is
the usage of a glossary. All business objects,
activities, and allowed relations between them are
defined within it. In the best case only the content of
the glossary is (re-)used for describing the process
element identifier by using activity-object phrase
structures. For example, there is a glossary in which
the business object “delivery plan” and the activity
“create” are included. In addition, the business
object “delivery plan” is associated with the activity
“create”. Hence, the element identifier “create
delivery plan” is valid based on this glossary (Figure
2). By this means, uniform terms are used and
misleading synonyms and homonyms are avoided
(Becker, Richter & El-Hawari, 2010; Becker,
Clever, Holler, Püster & Shitkova, 2013b; Breuker,
Pfeiffer & Becker, 2009).
Figure 2: Glossary and element identifier.
In terms of change management the glossary is
particularly helpful because it contains all terms
used within the as-is and to-be processes in one
central index. It also includes definitions of new
ERP specific terms, e. g. the SAP info record as
Glossary
ActivityBusiness object
Delivery Plan Book
Business object – activity – relations
Delivery Plan Create
PrintDelivery Plan
Create
Print
...
...
......
Element identifier
Create Delivery Plan
Fourth International Symposium on Business Modeling and Software Design
204

master data for the connection between suppliers and
articles. By this means the tool can help to
standardize the used vocabulary within the models
and therefore in the project.
3.2 Clear Structured Models
In order to communicate changes it is common sense
that the content is presented in a clear and structured
way. One main issue is the granularity of the
business process models. On the one hand detailed
descriptions of the process flow are necessary in
order to understand the processes. On the other hand
too detailed descriptions and therefore too complex
processes are hardly understandable. The usage of
different layers of abstraction is a commonly used
method to cope with the complexity. With respect to
communicating changes it is beneficial that all
process models should follow the same levels of
abstraction. Based on literature a four level structure
is a good compromise regarding fast navigation,
clarity, and overview. It should consist of an
organizational framework (process landscape or
process overview), main processes, detailed
processes, and process building blocks (Becker et
al., 2010; Becker et al., 2013; Harrington, 1991).
Through the upper layers an executive summary for
managers is given. The lower levels in the structure
provide a detailed description for employees
working in the departments.
These different layers are implicit within
organizational charts and of IT system hierarchies,
which are relevant for a full representation of all
changes within the company. Organizational charts
are very helpful to display all employees within the
project and future working environment. Comparing
the old hierarchy to the new designed one helps to
communicate changes regarding the amount of
positions and job descriptions. For Example park
invoices will no longer be necessary because of
using optical character recognition for invoices. The
differences within the IT systems diagrams are of
great value while estimating the need for new hard-
and software.
3.3 Integrated Documentation
A full documentation of all changes is the main
deliverable in change management projects. Hence,
the tool has to support the user in creating the
documentation. The basis for a documentation
covering all relevant aspects (the scope of these has
to be defined at the start of the project) are attributes
within all process layers. It turned out to be
beneficial, that attributes were available on all
process levels and also within the organizational
charts and IT systems hierarchies. Typical attributes
are: generally description of process blocks, support
by IT systems, or process responsibilities. The
relevant position from the organizational chart or the
documented IT system could be attached to process
blocks directly. In the context of change
management this allows a mapping of the old
process responsibilities or necessary IT systems to
the new ones. Also more sophisticated and ERP
specific attributes like uniform resource locators
(URLs) to documents stored in the SAP solution
manager, direct links to the user interface, and
interactive training videos add value for users.
Beside the documentation of the changes within
the tool also export functionalities to office
applications like Microsoft Word or Visio are
Figure 3: Attributes for process blocks.
Value
SAP ERP
MM
Process owner Smith
IT system component(s) SAP ERP - MM
IT documentation https://.../itdoc/page15.html
Training documentation https://.../traindoc/page11.html
Training video https://.../wpb/video03.mpg
Main risk Supplier Master Data is transferred
incorrectly from the central SAP FI.
Control description After recording of new data from the
central SAP FI random check by key
users. Helpful transaction: MKVZ
(Supplier Directory).
... ...
SD
Attribute
Miller
Smith Owen
...
FI
...
Process description Supplier Master Data includes the
base data as well as purchase and
accounting data (e. g. minimum order
values , bank accounts, payment
methods). ...
Process block Maintain Supplier Master Data
Maintain Supplier Master Data
Maintain Article Master Data
Maintain Supplier Conditions
Maintain Supplier Contracts
...
Applying Business Process Modeling Tools in Enterprise Resource Planning System Replacements - A Case Study
205

important. They facilitate the creation of tests,
trainings and system documentations. In the context
of the project several reports like “which processes
are assigned to specific IT system components” or
“which contact persons are responsible for which
process steps” are especially useful. These reports
are easy to create within a tool providing flexible
attribute definition and reporting functionality using
these attributes. The attributes are also used for the
implementation of risk management. For each
process step specific attributes are defined
describing the risk, its’ severity and its’ possible
coverage (e. g. usage of SAP transactions for
Intermediate Document (IDoc) monitoring to control
communication risks with suppliers). Another
application area in the context of change
management is creating reports with reference to
specific business objects taken from the glossary, e.
g. during ERP replacement the communication with
suppliers is switched to electronic data interchange
(EDI) protocol. Hence, looking for any old process
blocks containing the activities “print” or “send” is a
good starting point for managing the change.
Figure 3
depicts an example where the attributes are used for
connecting the operational and organizational
structures.
3.4 Re-use of Knowledge
The employees from the departments provide the
external consultants with all necessary knowledge in
order to model the as-is and to-be processes. The re-
use of single process steps with a special
highlighting of those remaining identical has turned
out as a driver for the acceptance of the designed
process models. Therefore, it is beneficial if the
BPM tool is able to use references rather than simply
copying process blocks. By this means, there is no
redundant data. The same information can be edited
and stored in one spot and is used in potentially
several process models. Figure 4 shows a referenced
process block “Archive Document” used in the two
processes invoicing and billing. In both cases the
used archive system and all other attributes were
identical and can be edited consistently.
A further facilitator for eliciting the process
knowledge is the usage of reference models. During
the workshops and interviews in the identification
phase the external consultants proposed “best-
practice” process models and organizational forms
including position descriptions. It is important to
propose these reference models not in the beginning
but after some time of discussion in order to
consolidate the knowledge. Furthermore, it is easier
for all participants to adopt the existing reference
models to their needs than to start from scratch.
From a change management perspective the usage of
the reference models yielded high quality models
and allow to a certain amount benchmarking with
reference companies. This is an important driver for
acceptance in the communication phase.
Figure 4: Process references.
Also the architecture of the tool as a web-based
platform is beneficial because a quick access via
web browser is possible instead of an installation
hurdle. Changes could be entered during workshops
directly and the user trainings could be supported by
the tool since everybody was able to view the
processes with additional information while using
the new ERP system. Just alike, future employees
will be able to use the process documentation to
view and understand not only the processes they
work in but also the previous and following
processes.
4 CONCLUSION AND FUTURE
WORK
For supporting the change management in the
described project the usage of a business process
modeling tool is a very promising approach. After
having collected the information regarding the
organizational and operational structure in the
identification phase we documented and analyzed it
with the BPM tool. Regarding our first research
question, we conclude that a BPM tool is well suited
in the context of an ERP replacement. In order to
answer the second research questions, we clustered
the key features in standardization of semantics,
structured models, integrated documentation, and the
re-usability of knowledge (Table 2).
Invoicing process
(supplier side)
Billing process
(customer side)
Transmit Billing Document
Archive Document
Handle Invoice
Select OrderReceive Invoice
Create Billing Document
Book Invoice
Archive Document
Fourth International Symposium on Business Modeling and Software Design
206

Although the feedback within the project is
positive (we are in the communication phase while
writing this article), there are several potentials
regarding integration, collaboration, and
visualization we would like to address. We believe
these do not only apply to the specific combination
of used BPM tool and SAP ECC in our case. They
are also relevant in comparable projects and for
future BPM tool developments and research.
Integration: A strong link between the BPM tool
and the new ERP system would probably increase
the acceptance of the tool, e. g. a single sign on
functionality.
Collaboration: Automatic version management
was missing. We believe from our practical work
during the project that the possibility to have a full
version control of the models similar to a text
document in a SharePoint environment is of great
value. The version management would allow to trace
the modified parts of a model, e. g. before and after
a change request is implemented. Furthermore, some
sort of social media integration would have been
beneficial. Either to comment the different versions
of the models in the review process or to interact
with the process owner e. g. via chat directly. The
web-based version of the tool was great for
distributing the process models via a simple link.
Nevertheless, in few situations during more informal
meetings a mobile application would have enhanced
the acceptance and would have further simplified the
communication. For both solutions – the web-based
and a possible mobile application – a more
sophisticated user access control is needed, e. g. a
guest access for a supplier. The authorization rules
have to ensure that the supplier can only access the
relevant and maybe new processes (e. g.
transmission of shipping notifications). Similar user
access control mechanisms would be relevant for the
approval and monitoring of (new) process versions.
E. g. processes are initially stored with the status
“wait for approval”. After the new version is
reviewed and released, the processes will be
unlocked for all authorized employees.
Visualization: In several situations one model or
different models were compared. A supporting
function for a comparison of two versions of one
model (e. g. as-is and the to-be) or for two IT system
charts is missing but would have simplified the work
for the consultant. A further aspect of the
visualization is the tool visualization itself in
different web browsers. Partly the tool behaved
differently what definitely has to be considered
when using a web-based tool in a company.
Beside the above mentioned potentials and open
issues we want to continue with our evaluation until
the ERP replacement is over. We are looking
forward to use the BPM tool in future ERP
replacements or implementations.
REFERENCES
Becker, J., Clever, N., Holler, J. & Shitkova, M., 2013.
icebricks: Business Process Modeling on the Basis of
Semantic Standardization. In Proceedings of the
Design Science Research in Information Systems and
Technologies (DESRIST). Helsinki, Finland, pp. 394–
399.
Becker, J., Clever, N., Holler, J., Püster, J. & Shitkova,
M., 2013a. Integrating Process Modeling
Methodology, Language and Tool – A Design Science
Approach. In Practice of Enterprise Modeling 2013
(PoEM 2013). Riga, Latvia: IFIP International
Federation for Information Processing, pp. 221–235.
Becker, J., Clever, N., Holler, J., Püster, J. & Shitkova,
M., 2013b. Semantically Standardized and
Transparent Process Model Collections via Process
Building Blocks. In Proceedings of the 5th
International Conference on Information, Process,
and Knowledge Management (eKNOW). Nice, France,
pp. 172–177.
Becker, J., Kugeler, M. & Rosemann, M., 2011. Process
Management: A Guide for the Design of Business
Processes 2nd ed., Berlin, Germany: Springer.
Becker, J., Richter, O. & El-Hawari, T., 2010.
Vertriebsinformationssysteme zwischen
Standardisierung und Flexibilisierung:
Referenzmodelle für die Prozesse im Vertrieb. In J.
Becker et al., eds. Vertriebsinformationssysteme:
Standardisierung, Individualisierung, Hybridisierung
und Internetisierung. Berlin, Heidelberg, Germany:
Springer, pp. 3–18.
Becker, J., Rosemann, M. & Schütte, R., 1995. Grundsätze
ordnungsmäßiger Modellierung.
Wirtschaftsinformatik, 37(5), pp. 435–445.
Becker, J., Rosemann, M. & von Uthmann, C., 2000.
Guidelines of Business Process Modeling. In W. Van
Der Aalst, J. Desel & A. Oberweis, eds. Business
Process Management: Models, Techniques and
Empirical Studies. Berlin, Germany: Springer, pp. 30–
49.
Breuker, D., Pfeiffer, D. & Becker, J., 2009. Reducing the
variations in intra- and interorganizational business
process modeling – An empirical evaluation. In
Wirtschaftsinformatik Proceedings 2009., pp. 203–
212.
Carr, N.G., 2003. IT Doesn’t Matter. Educause Review,
38, pp. 24–38.
Davenport, T.H., 1998. Putting the Enterprise into the
Enterprise System. Harvard Business Review, 76(4),
pp. 121–131.
Applying Business Process Modeling Tools in Enterprise Resource Planning System Replacements - A Case Study
207

Dean, D., Orwig, R., Lee, J. & Vogel, D., 1994. Modeling
with a group modeling tool: group support, model
quality, and validation. In Twenty-Seventh Hawaii
International Conference. Wailea, HI, USA: IEEE, pp.
214–223.
Dean, D., Orwig, R. & Vogel, D., 2000. Facilitation
methods for collaborative modeling tools. Group
Decision and Negotiation, 9(2), pp. 109–128.
Harrington, H.J., 1991. Business Process Improvement:
The Breakthrough Strategy for Total Quality,
Productivity, and Competitiveness, New York, USA:
McGraw-Hill.
Holland, C.P. & Light, B., 2002. A Critical Success
Factors Model For ERP Implementation. IEEE
software, 16(3), pp. 30–36.
Huang, S.-M., Hung, Y.-C., Chen, H.-G. & Ku, C.-Y.,
2004. Transplanting the Best Practice for
Implementation of an ERP System: A Structured
Inductive Study of an International Company.
Computer Information Systems, 44(4), pp. 101–110.
Mendling, J., Reijers, H. & van der Aalst, W.M.P., 2008.
Seven Process Modeling Guidelines (7PMG).
Information and Software Technology, 52(2), pp. 127–
136.
Moody, D.L., 2005. Theoretical and practical issues in
evaluating the quality of conceptual models: current
state and future directions. Data & Knowledge
Engineering, 55(3), pp. 243–276.
Nah, F.F.-H., Lau, J.L.-S. & Kuang, J., 2001. Critical
factors for successful implementation of enterprise
systems. Business Process Management Journal, 7(3),
pp. 285–296.
Ould, M.A., 1995. Business Processes: Modelling and
analysis for re-engineering and improvement, New
York, USA: Wiley Chichester.
Peslak, A.R., Subramanian, G.H. & Clayton, G.E., 2008.
The Phases of ERP Software Implementation and
Maintenance: A Model for Predicting Preferred ERP
Use. Journal of Computer Information Systems, 48(2),
pp. 25–33.
Rittgen, P., 2009. Collaborative modeling of business
processes: a comparative case study. In Proceedings of
the 2009 ACM symposium on Applied Computing.
Honolulu, Hawaii, USA: ACM, pp. 225–230.
Scheer, A. & Nüttgens, M., 2000. ARIS Architecture and
Reference Models for Business Process Management,
Berlin Heidelberg, Germany: Springer.
Van Hee, K.M., 1994. Information systems engineering: a
formal approach, New York, USA: Cambridge
University Press.
Fourth International Symposium on Business Modeling and Software Design
208