ERP BUSINESS MODELLING:

MISSING LINK IN ERP IMPLEMENTATION

Henk Akkermans, Kees van Helden and Mario Derks
Origin Nederland B.V., Breda, The Netherlands

ABSTRACT
In the field of operations management, ERP implementation projects
abound these days as many firms prepare for Y2000, Euro, internationalisation and supply chain management. Such comprehensive IT
projects often require redesign, or at least mapping, of the business
processes to be supported by the ERP-software. This modelling of the
key business processes is in practice often problematic. The paper describes a swift and highly interactive approach for ERP business modelling. It shows its application in an exploratory case study and presents evaluations findings from it.
INTRODUCTION
Successful operations performance crucially depends upon a smooth and effective flow
of information between organisational units and functions: from sales to engineering to
production to distribution to F&A, from production to human resources to F&A etcetera. Luckily enough, these days software is available which can deal with such complicated information flows in an integrated manner, at least in theory: Enterprise Resource Planning (ERP) systems have taken the floor in an impressive manner. It often
seems that there is hardly any company of some size left not involved in either a fullblown ERP implementation, a hardly more modest upgrade from a mainframe MRP
system to a more recent (read: ERP) version on the basis of client-server technology
or, most challenging of all, a simultaneous tackling of Year 2000 and/or Euro issues in
the current legacy systems together with an ERP implementation. ERP has become
big business for the IT industry.
Unfortunately but hardly surprising in the face of such a boom in ERP implementations, all is not well. Let us leave aside the fact that the software is still very
much in development, with only the latest version typically able to satisfy clients needs
(or so the software vendor would like to make one think). Let us forget about the fact
that few implementation partners can keep up with growth rates of over 40% percent
year by year and have trouble facing ever more complex implementation projects with
experienced staff often spread very thin indeed. And let us not speak indeed of the time
pressures which almost all ERP projects are under in the late 1990s, with Y2000 risks
often becoming very threatening well over a year before Jan 1, 2000 and the Euro
quickly under way in becoming a reality as well.
Let us focus on the companies themselves and their need for organisational redesign. There the adagium used to be: organise before you automate. In the business
process redesign (BPR) movement that swept through the business world in the first

half of this decade, that had become dont automate, obliterate (Hammer 1990). But
these days, fed up with seemingly endless BPR projects with fairly intangible results
and very tangible consulting fees, the new adagium has become automate and thereby
reorganise or even automate and then optimise. Todays ERP vendors propose an
altogether different approach, which is first to support the currently existing processes
and then later, after the swift implementation of the ERP software, to optimise these
processes and reconfigure the software accordingly (Van Es, 1998).
But here things start going wrong because companies typically dont want
their current, As Is processes supported by the latest software for the next 5-10
years; they want their future, To Be processes cast in silicium. Or some of these,
anyway, although they are not really sure what parts. Moreover, there often is no
agreement on what the current processes really look like after the umpteenth reorganisation, and opinions regarding what the desired processes should look like vary widely.
In these cases we get an organisation that is embarking on a wide-reaching and costly
project under serious time pressure with several immature technologies while it does
not really know what processes it is going to support with the new information technology: a recipe for disaster, which indeed often happens.
What is missing in these cases is an explicit, comprehensive, systematic and
agreed upon link between the companys business strategy and the intended functionality of the ERP system. It is here that an approach like ERP business modelling can
help. In this approach, an organisation is assisted in achieving consensus regarding the
nature of the business processes it wants to be supported without resorting to an extensive BPR project. Hard deliverables are the clearly, fully specified organisational
processes, procedures, roles and responsibilities that ERP application consultants typically need before they can start their programming. Soft deliverables are a clear understanding within the organisation of the nature of these processes, consensus regarding
them and commitment towards their support with IT.
ERP BUSINESS MODELLING
ERP Business Modelling is a consulting approach aimed at arriving at full, wellspecified descriptions of the business processes that are to be supported with the new
ERP package. Just like many BPR approaches, it spans the distance from a companys
strategy to the detailed organisational procedures. Like many, but not all (cf. Archer
and Bowker 1996) BPR approaches, ERP Business Modelling places strong emphasis
on managing the group decision-making process of developing the required process
descriptions and on employing a systems, modelling-oriented perspective to look at
different functions as one integrated whole. This is not surprising, since the particular
method used has borrowed heavily from Participative Business Modelling (Akkermans
1993, 1995a, 1995b), a more generic consulting method that has systems thinking and
process facilitation as its cornerstones.
Since ERP Business Modelling is a process facilitation approach rather than an
expert approach, the role of the client is very important: the client plays a leading role
in the whole business modelling process. It is assumed that the client has an in-depth
knowledge of his or her own business and details of the business processes, but lacks
the overall view and the relationships between the business processes. External expertise will only be used if explicitly desired by the client. The major role of the consultants is to facilitate the clients project team in gathering that information which is
needed to construct a consistent and well-understood model of the business processes
2

which are to be supported by the new ERP package. Extensive use is made of workshops and group facilitation techniques.
Typical ERP implementation projects start with a mapping phase. In that phase
the ERP functionality is mapped on the clients business processes. In these projects,
the assumption is made that these processes are already well described, which normally
is not the case. ERP Business Modelling can be seen as the activity preceding the ERP
mapping phase and is focused primarily on arriving at the required specs for the ERP
implementation, rather than process redesign as a goal in itself. This keeps the effort
short and focused.
Phases ERP Business Modelling
4.4.Business
Business
modelling
modelling
workshop
workshop

1.Project
1.Project
Startup
Startup

2.2.Kick-off
Kick-off
workshop
workshop

3. Brown
paper
workshop

5.5.Business
Business
Process
Process
Modelling
Modelling

Strategic Issues
for
Top Management

7.7.Go/no-go
Go/no-go
meeting
meeting

6.6.
Acceptance
Acceptance

THE
M ID D L E O U T
APPROACH

Signed off
Business Processes
for
ERP Implement.

F igure 1: Phases ERP Business M odelling and M iddle O ut A p p r o a c h

ERP Business Modelling is a middle-out approach, rather than a top-down effort. This
implies that the project team, consisting of middle management, redirects strategic issues to top management and well-thought out processes are quickly implemented in
ERP front-end tools like DEM or ARIS Toolset (van Es 1998 and Kuitems et al.
1997). The project team defines its own project scope and goals, within the preliminary
determined constraints by senior management. Drawing the first outline of the business
processes is normally done in a relatively short time, but making a consistent model at
all levels requires a significant effort. ERP Business Modelling deals with this subject
by using a convergence procedure. This means that the effort is divided into a number
of submodels. Each submodel has to be signed off by a process owner from the company and by an ERP application specialist. By signing off, the former indicates that the
model does indeed describe the business process as the process owner wants them to
be supported. Signing off by the ERP specialist means that the process can be supported by the current version of the ERP package, and more specifically by which
module.
In this way, ERP Business modelling results in three main deliverables;
1. a well-specified description of the business processes to be supported by the ERP
package.
2. a business control model which describes the way the business processes are controlled.
3. a specification of the support level of the ERP package for each business process
described.
These three documents then are intended as a solid basis for the start of the implementation of the ERP package.

THE CASE STUDY: ERP BUSINESS MODELLING TO HEAD OFF AN ERP

IMPLEMENTATION CRISIS IN THE AVIATION INDUSTRY
The aviation industry is characterised by a few major global players and many small
ones, which all develop and manufacture aeroplanes and helicopters. A major part of
the design and production has been contracted out by suppliers. The clients company
is one of these smaller European suppliers in the aviation industry, developing, producing and delivering aero-structures for the civilian and military market. The company is
a subdivision of the aviation division of a multinational engine building company. At
the clients company about 700 people are working on the realisation of the products.
The aviation division decided to implement an ERP package for the four subdivisions. During the initial project phase, one of the operating companies encountered a
number of problems. Firstly the clients company had to make use of a combination of
reference models to support the different manufacturing and logistical processes effectively. This variance in processes was caused by different product-market combinations. Secondly, years ago the clients company was only a manufacturing plant, within
a much larger company. In their new role as an independent company a sales department was set up to sell their own products and to acquire orders, the role of the financial department was expanded to include controlling and invoicing and programme
management was introduced to offer dedicated service for specific customers. Thirdly,
time constraints began to weigh heavily on the project, caused by a Year 2000 problem
of initially unclear magnitude. Finally, all this was aggregated by conflicts with the implementation partner and a virtual standstill for the project, because of an initial underestimation on both sides of the necessity for mutual involvement in the stages preceding the actual ERP implementation, i.e. the business modelling stage, for which top
management of the client felt no expensive BPR project was required.
To break out of the deadlock which was thus achieved a different approach
was proposed, i.e. ERP-Business Modelling. As the next section will illustrate, this approach was instrumental in overcoming these difficulties. In this approach, the bulk of
the work in this highly interactive process was done by the project team , consisting of
some 10-12 key members of the functional areas within the scope of the ERP implementation, managed by the internal ERP project manager. This project team was assisted by a team of dedicated outside consultants, in which the authors participated.
Total duration of the ERP Business Modelling project was three months. It
took three weeks to prepare the project and to conduct interviews with senior management and the key-members of the ERP project team. One week was needed to prepare and conduct the formal kick-off of the project and to conduct a Brown-paper
workshop. In a period of six weeks, eight workshops were used to make a consistent
business process model and business control model. In parallel with the other activities
two workshops were conducted to address and solve the MT-issues. Selection of the
best way to support the modelled processes with the ERP package functionality took
five weeks. These activities were started in parallel with the modelling process. Then
two weeks were needed for the evaluation and approval of the processes by the process owners. And the final step consisted of evaluation of the ERP business modelling
project and hand-over of the project results to the ERP implementation team. The ERP
implementation team could start immediately after this hand-over and has met its deadlines and goals ever since.

THE RESEARCH SETTING: AN EXPLORATORY SINGLE-CASE STUDY

BASED UPON EXISTING CONSULTING AND RESEARCH FRAMEWORKS

ORGANISATIONAL
CONTINGENCIES

The current abundance of ERP implementations is a very novel phenomenon, and the
use of business modelling to facilitate these even more so. Therefore, explanatory research seems appropriate and justified. Hence the choice for an explanatory initially
study (Yin 1989). However, business modelling in the broader sense has been around
for a much longer time (Archer and Bowker 1996) This makes it possible to use existing business modelling methods and existing research frameworks. For this research
project, an existing and well tested approach to generic business modelling was used
and also an existing research model and evaluation procedure were employed to establish its effectiveness in this particular domain (Akkermans 1995a, Akkermans and Vennix 1996, Akkermans and Bertrand 1997).
This model assumes that for effective
implementations of an
ERP system two requirePROBLEM CONTINGENCIES
ments have to be met.
Firstly, that the business
Organisational
model which is developed
Platform
for this implementation is
ImplementaBusiness
Process
of good quality. In this
tion Results
Performance
Effectiveness
research good model
Model
Quality
quality is measured by the
thoroughness and completeness of the analyses.
PROJECT DESIGN
Secondly, that this model
is strongly supported by all
Figure 2: Overall research model of effective business modelling
relevant stakeholders in
the organisation. This organisational platform was measured in this study by looking at the indicators commitment, consensus and insight. (For a more detailed description of the research
model constructs and indicators see Akkermans 1995a, Akkermans and Vennix 1997).
So model quality and organisational platform jointly determine the implementation results. However, these two should be reached in an effective decision making
process, which brings us to the third variable which tells us about effectiveness of the
business modelling approach chosen, i.e. process effectiveness. This variable is operationalised into quality of communication, focus of discussions and willingness
to cooperate with participants.
All these indicators were measured on a five point scale in semi-structured post-project
interviews conducted by two outside researchers. The findings from this evaluation
process are described further in this paper.

PROJECT RESULTS
After three months the project team delivered four tangible product categories to the
organisation:
Six main processes have been defined, which together describe the main process
flow from request for proposal to delivery and invoicing of the products. Each of
these main processes has been decomposed into at least two levels of subprocesses.
Half of these subprocesses have been decomposed into a third level. This resulted in
a total number of 102 processes. Each main process, including its underlying subprocessses, has been approved by the relevant process-owner and the outside ERP
expert.
A so called business control model (van Es 1998) for each of four identified product-market combinations, with different order decoupling point locations for each of
them.
A process model for each of the identified processes and the way it can be supported by the new ERP system, including the consequences for the current working
method.
The vision and decisions on specific strategic issues, worked out by senior management.
RESEARCH FINDINGS
The scores that were obtained from the evaluation interviews with key project participants some two months after the business modelling effort were very positive indeed.
They are summarised in Table 1.
Model Quality
Completeness
Thoroughness

Organisational Platform
Process Effectiveness
4.3 Commitment
4.5
Communications
4.4
3.3 Consensus
4.3
Focus
3.8
Insight
4.5
Willingness to Cooperate
4.5
Table 1: Scores on indicators for business modelling in aviation case (N = 4, scale 1-5)

These figures show very strong support indeed for the model, which now has
resulted, according to the interviews, in a strong and broadened base of supporters of
the implementation effort, one of the main drives for the current succes of that effort.
Lower scores were obtained on thoroughness, i.e. the somewhat degree in which participants felt all the required analyses had been conducted, and on focus, i.e. the degree
in which sessions were felt to be kept directed towards the main issues. Both can be
understood from the early stage of this effort in the overall ERP implementation process. In this project many analyses will doubtlessly still have to be conducted, and initially it could not be completely clear what will turn out to be the main issues and
what the minor ones.

CONCLUSION
BPR before ERP takes too long for many companies. ERP vendors suggest instead to
start with implementation of their packages, which already contain the best practices in
terms of business processes of many earlier companies, and optimise operations later.
A missing link in doing so in practice turns out to lie between the business strategy of
the client and the detailed process descriptions, which ERP systems require. The approach described here, ERP Business Modelling, provides one promising alternative to
forge this link. Evaluation findings from an exploratory case study in the aviation industry indicate strongly positive results in terms of perceived quality of this business
model, in organisational support for this model and in effectiveness of the group process leading up to the delivery of that model to the organisation.
However, it is early days yet. The client company from this case study has at
the time of writing not even completed her ERP implementation. BPR-less ERP implementations are a novel phenomenon anyway. Surely, more focused, longitudinal
field research over broader range of companies will be required to shed more light on
these important novel developments.
REFERENCES
Akkermans, H.A. (1993), "Participative Business Modelling to Support Strategic Decision Making in Operations - A Case Study", International Journal of Operations &
Production Management Vol. 13, No. 10, pp. 34-48.
Akkermans, H.A. (1995a), Modelling with Managers. Participative Business Modelling for Effective Strategic Decision-Making, Ph.D. Thesis, Eindhoven University of
Technology.
Akkermans, H.A. (1995b), Developing A Logistics Strategy Through Participative
Business Modelling, International Journal of Operations & Production Management
Vol. 15, No. 11, pp. 100-112.
Akkermans, H.A., Bertrand, J.W.M. (1997), On the Usability of Quantitative Modelling in Operations Strategy Decision Making, International Journal of Operations &
Production Management Vol. 17 Nr. 10, pp. 953-966.
Akkermans, H.A., Vennix, J.A.M. (1997), Clients Opinions on Group ModelBuilding: An Exploratory Study, System Dynamics Review Vol. 13, No. 1, pp. 3-31.
Archer, R., Bowker, P. (1995), BPR consulting: an evaluation of the methods employed, Business Process Re-engineering & Management Journal Vol. 1 No. 2, pp.
28-46.
van Es, R. (ed, 1998), Dynamic Enterprise Innovation, Baan Business Innovation
BV, Barneveld.
Hammer, M. (1990), Reengineering Work: Dont Automate, Obliterate, Harvard
Business Review July-August 1990, pp. 104-112.
Kuitems, F., de Lepper, E., Roos, E., Streng, R-J., (1997), Tools for Business Process
Redesign. An Overview, Origin, Utrecht.
Yin, R.K. (1989), Case Study Research: Design and Methods, Sage, London.