PERSPECTIVES ON PROCESS DOCUMENTATION

A Case Study

Jörg Becker, Christian Janiesch, Patrick Delfmann

European Research Center for Information Systems, University of Münster, Leonardo-Campus 3, Münster, Germany

Wolfgang Fuhr

Bayer Business Services GmbH, Leverkusen, Germany

Keywords: Process Documentation, Process Modeling, Confi

guration, Conceptual Modeling, Multi-Perspective Infor-

mation Modeling, Case Study

Abstract: The documentation of IT projects is of paramount importance for the lasting benefit of a project’s outcome.

However, different forms of documentation are needed to comply with the diverse needs of users. In order

to avoid the maintenance of numerous versions of the same documentation, an integrated method from the

field of reference modeling creating perspectives on configurable models is presented and evaluated against

a case in the field of health care. The proposal of a holistic to-be model for process documentation provides

useful hints towards the need of presenting a model that relates to a specific user’s perspective. Moreover, it

helps to evaluate the applicability of configurable, company-specific models concerning the relative operat-

ing efficiency.

1 RESEARCH APPROACH AND

CASE SCENARIO

The documentation of IT projects, e. g. software

development or process reengineering, is of para-

mount importance for the lasting benefit of a pro-

ject’s outcome. But different forms of documenta-

tion are needed to comply with the diverse needs of

users who use information model for different pur-

poses. A system engineer for instance is in need of

different information than a manager or a trainee.

These problems are similar to those from the

field of

reference modeling where large overall

process models have to be adapted to company-

specific contexts. To assist this model adjustment

several model customization techniques have been

discussed that allow the adaptation for various pur-

poses. However, the applicability to large company-

specific models has not been further investigated.

Thus, these configuration techniques are discussed

mainly in the field of reference modeling. Their

applicability to company-specific models in terms of

process documentation for process management

purposes seems to be promising nonetheless.

In the year 1996 the Baye

r AG, a Germany-

based global enterprise in the fields of health care,

nutrition, and innovative materials, settled on a

comprehensive framework for a corporate-wide roll-

out of the standard software SAP R/3. In the run-up

all major processes were analyzed and documented.

This provided an ideal basis for a thorough ex-post

analysis and allowed meaningful propositions for a

future appearance of the process documentation that

allow the utilization of the information for different

purposes. The Bayer Business Services GmbH as-

sisted us greatly in the analysis of their documenta-

tion and provided us with any input requested. We

thankfully acknowledge their support in this project.

Thus, the research questions for the following

are in d

etail:

• Wh

ich possibilities exist to allow a context-

oriented preparation of process documenta-

tions or process models?

• In

which way can they be applied at the Bayer

AG?

• Is th

e utilization of context-oriented process

documentations beneficial for the Bayer AG?

If so, does the concept sound promising for

other companies as well?

Becker J., Janiesch C., Delfmann P. and Fuhr W. (2005).

PERSPECTIVES ON PROCESS DOCUMENTATION - A Case Study.

In Proceedings of the Seventh International Conference on Enterpr ise Information Systems, pages 46-56

DOI: 10.5220/0002543900460056

 SciTePress

The structure of the paper mirrors this. At first,

the idea of configurative modeling and its related

work is elaborated upon. Then a comprehensive as-

is analysis is conducted whose findings result in the

proposition of a holistic to-be model. Hereon the

need for configurable models at the Bayer AG is

identified as well as the application of possible oc-

currences is presented and discussed in detail.

2 CONFIGURATIVE MODELING

AND RELATED WORK

2.1 Perspectives on Process Models

According to the Total Quality Management (TQM)

approach, the quality of a product is determined by

its fitness-for-use for the consumer and his require-

ments (Ishikawa, 1985). When transferred to process

models, their quality depends on the fitness-for-use

concerning the requirements of particular users or

user groups. User requirements result from their

different perspectives on business processes

(Rosemann et al., 2005), (Nissen et al., 1996),

(Rosemann and Green, 2000). A perspective is de-

termined by the deliberate and specific use of a

business process model, the organizational role of a

user as well as individual preferences on the concep-

tual and representational design of business process

models (Becker et al., 2002). See Figure 1 for an

overview of specific purposes of process models.

The more effective the process model meets the

requirements of a particular perspective, the higher

is its quality. Ideally, each identified perspective

should be provided with a tailor-made version of a

process model. This approach is called multi-

perspective process modeling (Darke and Shanks,

1996), (Rosemann, 1998), (Becker et al., 2002).

Cf. (Rosemann et al., 2005).

Figure 1: Specific Purposes of Process Models

2.2 Related Work on Model Adapta-

tion

In order to enable multi-perspective information

modeling, different approaches of model adaptation

have been developed in the past. Some approaches

focus on model transformation, as they are pro-

claimed by the Model Driven Architecture (MDA)

(Soley and OMG Staff Strategy Group, 2000)).

Implementations of model transformation mecha-

nisms can be found in the form of so-called Meta

CASE Tools like the Generic Modeling Environ-

ment (GME) (Agrawal et al., 2002), (Ledeczi et al.,

2001) and Metaview (Findeisen, 1994). Model trans-

formation aims at generating a destination model out

of an original model, whereas the languages of both

models can diverge extensively. Structural patterns

are identified in the model of the initial modeling

language via an algorithmic search and they are

transformed into equivalent patterns of a model of

the targeted modeling language. Transformations are

performed by using transformation rules that are

defined for each combination of the original and

destination language (Engels et al., 1997). Model

transformation approaches are characterized by a

high universality of the operators used for the defini-

tion of transformation rules (e. g. Create New, Re-

PERSPECTIVES ON PROCESS DOCUMENTATION - A Case Study

place, Same, Create Reference, Create Link, Delete,

Refer else Create, Create inside, Refer to) which

makes high user competencies necessary.

Transformations are usually employed in the

software industry to adapt software to different op-

erating systems or computer platforms. In the field

of process modeling it is not necessarily required to

transform models.

Other types of approaches focus on building

views onto a model system. These views are then

considered as perspectives which result from user

requirements. Exemplary approaches of this type are

the Semantic Object Model (SOM) (Ferstl and Sinz,

1998), the Architecture of Integrated Information

Systems (ARIS) (Scheer, 2000), the Zachman

Framework (Zachman, 1987), the Open Systems

Architecture for Computer Integrated Manufacturing

(CIM-OSA) (ESPRIT Consortium AMICE, 1989),

MEMO (Frank, 1994), and Viewpoints (Finkelstein

et al., 1992). A common characteristic of these ap-

proaches is that the realization of multiple perspec-

tives is restricted to providing different modeling

views which result in different model types. In the

case of ARIS, these views are e. g. the data, the

functional, the organizational and the process view

which are represented by Entity-Relationship Mod-

els (ERM) (Chen, 1976), Function Trees, Organiza-

tional Charts, and Event-driven Process Chains

(EPC) (Scheer, 2000).

The approach which will be adopted here is

based on the latter of the approaches mentioned, but

provides extended configuration mechanisms instead

that are not restricted to modeling views.

2.3 Configuration Techniques for In-

formation Models

The most significant problem that results from a

multiplicity of perspective specific, tailor-made

models is the need to manage possible redundancies

inside the model itself. This leads to increased mod-

eling and maintenance cost and the danger of incon-

sistencies within the model base.

In order to enable an efficient multi-perspective

process modeling, redundancies have to be over-

come. A modeling methodology which enables the

user to avoid redundancies and to consider multiple

perspectives within the model base is called configu-

rative process modeling (for the following refer to

(Becker et al., 2004), (Becker et al., 2002)). The

approach is based on the concept of model projec-

tion. A configurable information model that provides

all relevant information for each perspective con-

tains constraints that determine to which perspective

each model element belongs. By this means redun-

dancies are avoided and, simultaneously, multi-

perspective modeling is made possible. When a

configuration is performed, each element is hidden

that does not belong to the selected perspective. This

implies that the core modeling is conducted using

the model base and as such can only be performed

by modeling experts that are properly trained. Thus,

the distributed modeling of the base model still

causes problems since inconsistencies may occur.

In order to reduce modeling complexity for the

individual user, it makes sense to provide configura-

tion mechanisms with different effectiveness. First,

coarse granular configuration mechanisms that oper-

ate on whole model sections, second, mechanisms

that operate on single model elements should be

provided. Hence, we distinguish configuration

mechanisms that are based on meta model projection

or model projection respectively. Using meta model

projection on the one hand, the user is enabled to

create perspective-specific models that differ in the

expressive power of the underlying modeling

method (e. g. by hiding model elements of a specific

object type). On the other hand, using model projec-

tion, particular model elements can be hidden (e. g.

process branches that are of no relevance for the

regarded perspective). Model projections are lan-

guage extensions in the sense of Domain-Specific

Modeling (Nordstrom et al., 1999), which are par-

ticularly adapted to the requirements of multi-

perspective information modeling.

3 THE BAYER CASE

3.1 Initial Situation

Since 1983 the Bayer AG used SAP R/2 systems in

several parts of the company. In the year 1996 a

comprehensive framework for a corporate-wide roll-

out of the ERP software SAP R/3 was resolved

upon. In the run-up all major processes were ana-

lyzed and if necessary redesigned. The original idea

was to conduct a complete redesign utilizing the

concept of business reengineering (Hammer and

Champy, 1993). However, the idea had to be ne-

glected later on for several reasons; mainly the size

of the project in connection with established struc-

tures disallowed the necessary changes. See chapter

3.2 for further factors that hindered the project’s

development and documentation.

Whenever possible, two perspectives were used

in the process: one with a more managerial and one

with a more technical focus. A large number of

external consultants were part of the project teams.

The documentation of the processes was con-

ducted with several plug-ins of a Lotus Notes

groupware environment, the so-called Electronic

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

Project Notebook (EPN). The documentation is

structured in three perspectives: a function-oriented

view, a process-oriented view and a technical view.

The function view’s elements are detailed in Proc-

ess, Subprocess and Activity Profile, the process-

oriented view that spans multiple organizational

units is arranged in Business Scenario Cluster

(BSC), Business Scenario and Business Scenario

Flow (BSF) (see Figure 2, all other perspectives are

modeled similarly). The technical view which is of

minor importance to the overall documentation is

arranged in IT Solution Design Document, Configu-

ration Document and Activity Script as well as the

Repository Objects which contain application source

code. Connected to every node in every hierarchy

level there is a document that is detailed in the level

below. All three hierarchy levels as well as the three

views have to be matched manually against each

other whenever there is a change.

Process View

Business Scenario Flow (BSF)

Business Scenario

Business Scenario Cluster (BSC)

Figure 2: Structure of the Process View

Parallel to the reengineering project a quality

management system was developed that documents

process-design processes. It combines several in-

formation sources in one portal and its core idea is to

describe those meta processes. Again, the arrange-

ment is function-oriented and the matching has to be

conducted manually.

The EPN and the quality management system,

both have next to no support with information mod-

els at all; for the most part they only contain textual

descriptions. Solely several PowerPoint slides exist

that depict some aspects of the system in forms of

processes and application dependence diagrams

using informal models. The models only serve to

present a minimal overview and – since they have

not been developed with an integrated modeling tool

– have to be matched manually against change in the

three views to persist in a consistent state.

Since the maintenance of this form of documen-

tation over time exceeds any sensible IT budget, a

more integrated approach is favorable. In order to

depict most of the scenarios attributes the Direct

Business process was chosen since it is relevant as

well for the applications system as organizational

design. In addition to that, four variants of the proc-

ess exist that contain special functions for external

customers and for internal use. The process is lo-

cated in the BSC Direktgeschäft (Direct Business) of

the EPN.

3.2 As-Is-Analysis of the Case Process

As indicated above, the original intention of the

modeling was to assist a process-oriented reorgani-

zation of the corporation focusing the software cus-

tomizing for an ERP implementation. Now, the main

focus is a continuous process management to moni-

tor and improve the current processes. In addition to

that, options for the utilization of the documentation

for workflows and for training purposes is explored.

In the near future, further use in the field of quality

management is desirable. These different purposes

also require different perspectives for the users in-

volved since a modeling expert does have other

requirements than the process owner.

The Direct Business process deals with the direct

sales to customers or other Bayer AG companies.

Two general variants exist: Intercompany and Ex-

ternal Customer each with one special case; i. e. for

Intercompany the Bayer AG to Bayer Distribution

Company via IDOC process and for external cus-

tomers the Direct Business via Letter of Credit (LC)

process.

The process always starts with a customer order

and ends with the managing of accounts receivable.

If planning software is utilized for internal use, it

generates the respective customer order at the deliv-

ering company.

See Table 1 for the original process documenta-

tion of the BSF Direct Sales (External Customer).

The table is an excerpt of the respective BSF. Some

columns of lesser interest are omitted: SAP Transac-

tion/ Script (Optional), Information Object Charac-

teristics (Optional), Processed by Partner (Op-

tional) as well as Remarks. The other content is still

in its original format except for minor anonymiza-

tion of numbers and codes. The other three process

variant descriptions are of similar build and not

depicted here in detail.

The analysis of the process was complicated in

particular by the following factors:

• The storage in the processes in the EPN is

not consistent.

• The sequence of process functions can only

be determined when BSF and Business Sce-

nario, both are explored.

• The matching of documentation techniques

does not only consist of documents from the

three hierarchy levels but also their attached

documents.

• The documentation language is not uniform

on any level of documentation.

PERSPECTIVES ON PROCESS DOCUMENTATION - A Case Study

Table 1: BSF Direct Sales (External Customer)

Decisive criteria for BS Flow: xxx

Nr. Short Description of Task Activity Work-

field

Input/Output Information

Objects (Optional)

1 Kundenauftrag anlegen Life

Science

O: Create/Change Order 8 --Order type

--Sales organization

--Distribution channel

--Division

--Sold-to-party

--Purchase Order no.

--Material number

--Quantity

2 Auftragsfertigung Life

Science

BS Auftragsfertigung 7

3 Lieferung anlegen Life

Science

MM: Process Delivery of Line

Items

8 Versandstelle

4 Dispoliste drucken Life

Science

MM: Pack orders for shipment &

Plan packing material

8 Shipping point and

output type

5 Etikettendruck Life

Science

MM: Label Goods for Shipping 8 -- Delivery no.

-- Delivery item

-- Batch no.

6 Warenausgang zur Lieferung Life

Science

BS Auslieferung abwickeln 6

7 Rechnung erstellen Support O: Process invoice 8

8 Legal Services Support BSF Declaration to authorities

und BSF Zollabwicklung

9 FI/CO

Zahlungseingang

Support Subprocess FA Manage Account

Receivables

Consistency problems: All four variants of the

process are attached to the same BSC but there are

two names used simultaneously in different areas of

the corporation: BSC Direct Business and BSC Di-

rect Sales/ Direktgeschäft. An automated synchroni-

zation of names or an integrated system could take

care of this.

Sequence problems: Apart from the tabular proc-

ess documentation in the BSF some more aggregated

information in forms of PowerPoint slides is saved

in the superordinated Business Scenario. The slides

depict the sequence on a very rough granular scale in

forms of column-oriented informal process models.

They represent the only hints on the sequence of

process functions, in particular whether they are

executed alternatively or in a parallel fashion.

Attached document problems: Not only the

above mentioned PowerPoint slides but also Excel

Documents that aggregate the content of the tables

in the Lotus Notes documentation have to be

matched manually (against all levels and views).

This led to minor inconsistencies in the past that will

aggravate in the future when more views are to be

implemented.

Language problems: The documentation is com-

posed in English and German interchangeably. This

led to a non-uniform naming of hierarchy levels and

processes as well as their functions. Textual descrip-

tions are partly composed in English and German,

too. On the one hand English naming facilitates the

identification of the SAP transactions involved. On

the other hand this leads to naming inconsistencies

and problems with the matching of abbreviations. In

addition to that it disrupts the general train of read-

ing.

However, when criticizing the systems layout,

the factors that led to the current state of operations

have to be considered. They do not excuse the cur-

rent state but explain the development of the as-is

system design. Time, cost and size of the project led

to the decision that an integrated modeling tool was

not commissioned. It was regarded as too big a cost

factor and too time-consuming to train all involved

personnel, especially since there was a considerable

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

amount of external consultants involved. After start-

ing the documentation in English the unequal educa-

tional background impeded a proper completion of

the documentation in a foreign language. It was

decided to continue in German in an easy-to-use

Lotus Notes environment to at least maintain a cer-

tain set of documentation guidelines. However, these

very same factors led to the fact the current system

is neither able to provide proper perspectives for

different uses nor is cost-efficient. It foremost pur-

pose at this point is to be a legal lifeline that com-

plies with German law for the documentation of

health care company software.

3.3 To-Be Model Proposition

For the construction of a to-be model all four proc-

ess variants are integrated into one process with

alternative paths. It is modeled with the EPC tech-

nique to show the benefits of a well structured

graphical representation that allows the integration

of further techniques like for instance the ERM.

See Figure 3 for the complete to-be model

proposition. The use of events is abstained from as

far as possible to improve the readability of the

model. This does not interfere with its semantics

since events have not been documented in the first

place. The omission does also apply for the follow-

ing figures.

The integration of all four variants into one

model allows an easier maintenance of the process

documentation since no matching has to take place

to adapt changes to other documents. However, the

combination of four variants into one integrated

model leads to a graphical representation with lots of

XOR-connectors. This can be difficult to compre-

hend by the casual user, especially when he or she is

not familiar with the configuration techniques at the

connectors. Since they describe under which circum-

stances which process alternative has to be followed,

it is essential to understand their working in order to

execute a process variant. Exemplarily four XOR-

connectors have been equipped with configuration

rules to allow process variant execution. Moreover,

the enrichment of the model with further elements

like organizational roles or application systems

would most certainly not enhance the readability but

have a contrary effect. That is why they have not

been included in Figure 3.

Therefore it is necessary to use perspectives or

views on this integrated model so that it can be used

even by the casual user to serve his purpose. These

perspectives allow the enhancement of the model

and the meta model with additional elements and

omit non relevant process variants by a further

model configuration. These mechanisms permit the

use even by a casual user who has at least a minimal

understanding of graphical process modeling. Since

all configurations are solely projections of the inte-

grated original model, its consistency is not in ques-

tion. The definition of these configuration points

however has to be done by a method expert since

their complexity exceeds the casual user’s abilities.

3.4 Configurable To-Be Models

A configuration for the organizational design of the

variant direct sales (external customer) is shown in

Figure 4.

Regarding model projection all non relevant

process threads have been masked so that only rele-

vant functions are displayed. In this way, an easy-to-

read process model is displayed that only shows the

desired variant. Apart from this model configuration

a meta model projection was applied to integrate

relevant further model types into the model, i. e. an

Organizational Chart and a Technical Term Model.

The utilization of their model elements assists the

organizational design and enriches the model so that

additional information becomes explicitly available.

Exemplarily, elements of each modeling technique

have been linked with a dotted line to show that it is

indeed the same object.

A corresponding configuration for the applica-

tion system design of the same variant is shown in

Figure 5.

In this case as well, the model is configured so

that only the relevant process thread is displayed.

Further model types that are employed via meta

model projection are the ERM and an Application

System Model. By using element types of both mod-

eling techniques the application system design can

be assisted since the explanatory power of the model

is increased by this enrichment, e. g. by displaying

abundant SAP modules. For system engineering it is

more relevant when conducting a process analysis

which modules of an ERP system are linked to cer-

tain functions than the role of a person that executes

them. As a next step the accordant SAP transaction

and the program data of the technical documentation

can be added to the model to let the system engineer

go further into the documentation. Another interest-

ing option is the linking of process elements for the

administration of test cases. The tests conducted can

be directly associated with the corresponding func-

tion, thus allowing a simple but powerful manage-

ment of test cases. Through configuration mecha-

nisms critical test runs can be separated from routine

tests. In this way testing for processes can be clus-

tered with the process model. In addition to that,

results could be clustered as well to single out devia-

tions that exceed defined safety limits.

PERSPECTIVES ON PROCESS DOCUMENTATION - A Case Study

Stock

production

Sales AG to

distribution

(legacy)

Create/

change order

Made-to-order

production

Pack orders

for shipment &

plan packing

material

Label goods

for shipping

Goods issue

to delivery

Process

invoice

Declaration to

authorities and

customs

Manage

accounts

receivable

Book goods

issue

Batch input to

SAP BV

Dispatch

notification via

IDOC

Quote

Process

proforma

invoice

Process

finance

document

Adapt order to

export

requirements

Monitor order

and financial

document

Process

predated

invoice

Create export

documents

Accounts

receivable

done

Legal

Services

done

Batch input

to SAP BV

done

Process

delivery of

line items

Order via LC

received

Customer

order

received

Order

received from

distribution

XOR

Customer

order

received

Regular

product is

ordered

Product is

ordered that is

made-to-order

Product via LC

is ordered that

is made-to-

order

Product is

ordered via LC

Product is not

ordered via LC

Product is not

ordered via

IDOC

Product is

ordered via

IDOC

Product is not

ordered via LC

Product is

ordered via LC

Product is

ordered via

IDOC

Product is not

ordered via LC

Product is

ordered via LC

variant (external

customer + external

customer via LC +

intercompany +

intercompany via

IDOC)

variant (external

customer + external

customer via LC +

intercompany) AND

product (made-to-

order)

variant (external

customer via LC)

AND product

(made-to-order)

variant (external

customer via LC) AND

product (made-to-

order)

Figure 3: To-be Model Proposition

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

Create/

change order

Goods issue

to delivery

Delivery of line

items

Process

invoice

Declaration to

authorities and

customs

Manage

account

receivables

Pack orders

for shipment &

plan packing

material

Label goods

for shipping

Distribution

and Logistics

(8)

Sales and

Production

Planning (7)

Distribution

and Logistics

(8)

Distribution

and Logistics

(8)

Local Systems

(6)

Distribution

and Logistics

(8)

Local Systems

(6)

Distribution

and Logistics

(8)

Transport

Logistics (12)

Accounting (9)

Customer

Order

Invoice

Customer

Order

Invoice

Time

is multiple characteristic of

is characteristic of

Sales and

Production

Planning (7)

Distribution

and Logistics

(8)

Local Systems

(6)

Transport

Logistics (12)

Accounting (9)

Workfield local

Workfield

regional

Human

Resources

(10)

Made-to-order

production

Workfields

Technical Terms

Account

receivables

done

Legal

services

done

Customer order

received

XOR

Product is

ordered that is

made-to-order

Regular

product is

ordered

Distribution

and Logistics

(8)

Figure 4: Model Projection for Organizational Design

PERSPECTIVES ON PROCESS DOCUMENTATION - A Case Study

Create/

Change Order

Goods issue

to delivery

Delivery of line

items

Process

Invoice

Customer

Order

Invoice

Made-to-order

Production

Declaration to

authorities and

customs

Manage

account

receivables

Pack orders

for shipment &

plan packing

material

Label goods

for shipping

FA Financial Accounting

MM Material Management

O Order Management

SD Sales & Distribution

Customer

Time

Order

(1,n)

(1,1)

(1,n)

(0,n)

SAP R/3

Data Model

SAP Modules

SAP MMSAP FA SAP SD

SAP O

SAP FA

100

SAP O

220-01

SAP MM

240-060

SAP MM

240-030

SAP MM

240-010

SAP MM

220-010

Invoice

(1,1)

Invoice-

Order-

Relation

Customer

Order Received

Account

receivables

done

Legal

services

done

XOR

Regular

product is

ordered

Product is

ordered that is

made-to-order

Figure 5: Model Projection for Application System Design

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

A projection of processes for communication sup-

port, like presentations or training uses, seemingly

needs to provide colorful and pictographic, yet sim-

ple built element types – or rather just icons. The

projection of the model is preferably directly usable

with presentation software so that no further con-

verting has to be carried out.

The design and layout might have to vary con-

siderably from the representation of the other two

configurations discussed above since a communica-

tion model’s main contribution is to present a simple

and understandable figure. The unambiguity of the

process model and thus the complying with a given

syntax is of minor importance as long as the simpli-

fication does not lead to inconsistencies in the un-

derstanding. Depending on the context, different

graphical designs can and should be chosen to assist

the specific purpose. In this way the original Bayer

AG documentation models that are ordered in col-

umns, could even be recreated. The model projected

can be generally classified as an informal representa-

tion of the model base. Its applicability is strictly

limited to communication uses since the model does

not allow the derivation of any formal specification.

3.5 Case Evaluation

This case study proves exemplarily that there is a

multitude of practical circumstances which benefit

from configurable information models and that they

are virtually indispensable when an integrated ap-

proach is followed.

In comparison to the textual descriptions of the

original documentation the advantages of a graphical

representation clearly show. Through the use of

graphical elements the depiction of the real world is

structured and intuitively accessible; textual descrip-

tion with a similar level of abstraction cannot com-

pete. Especially the initial training on the documen-

tation and the work with the processes, both become

easier. Even though the process models discussed in

the previous chapter do not contain all the informa-

tion of the textual description, it is quite obvious that

a consistent representation proves to be beneficial.

However, without further thoughts about the con-

figuration of models, no real benefit in terms of

clarity can be achieved as Figure 3 shows.

Regarding configurable models more achieve-

ments, e. g. concerning the ease of use and usability

of models for different purposes can be made. This

does apply to the example of the direct business

process as well as to other contexts. For example, an

adaptation of the granularity could allow the mana-

gerial as well as the technical process owner to work

with the same model because only the relevant

model elements and element types are displayed

through recipient-specific model and meta model

projection. The integration of other modeling tech-

niques like ERM or Organizational Charts provides

an overview with additional information that was not

possible before.

It is not only of interest for the Bayer AG to re-

place the old system with such an integrated ap-

proach of perspectives on process documentation but

also any new system could benefit therefrom. Criti-

cal success factors that have to be kept in mind

though, are the initial costs for the procurement, roll-

out, model creation and pre-configuration, training,

and the maintenance of such an integrated model. In

contrast to this, the current maintenance costs to

keep the documentation consistent have to taken into

consideration as well as the benefit in productivity

the users have when working with integrated and

configurable models. In the ideal case – after defin-

ing his or her perspective – anyone can work with

the system and it almost does explain itself for train-

ing purposes. However these advantages are hard to

quantify since factors like non-productive time due

to inconsistent, incorrect documentation in connec-

tion with prolonged retrieval time have to be in-

cluded in the calculation. Therefore, a decision has

to be taken on both, the current and the intended

purposes of utilization, the expected useful life, and

the employee’s potential engagement of system use.

4 CONCLUSION AND OUTLOOK

In this case study we show how the approach of

configurative modeling from the domain of refer-

ence modeling can be applied to company-specific

process documentation.

The integration of different process variants into

one holistic model does not prove to be beneficial at

first since the sheer amount of elements and

branches hinders the understanding of the model.

However, superior clarity is achieved through the

projection and configuration of the respective model

and meta model. This adaptation of the model allows

the application to various uses that can be roughly

categorized into application system design, organ-

izational design, and communication design.

In other respects, the economic evaluation stays

on a relative level since only a thorough quantitative

analysis can produce meaningful results that – how-

ever – have to be reviewed against qualitative fac-

tors that are to be explored yet. Questions to be ad-

dressed include but are not limited to sustainability

metrics for information models, flexibility vs. ro-

bustness metrics and maintainability issues. All

these consideration are, of course, to be made in

combination with the model’s economic efficiency.

PERSPECTIVES ON PROCESS DOCUMENTATION - A Case Study

During the last years Bayer has developed and

improved its process engineering framework, having

been investigated by this work, in its specification

and documentation parts. Further on, Bayer has

researched techniques in collaboration with scien-

tific institutes to proceed with the automation of the

process development life cycle. The main topics are

UML specification, UML-based automated testing,

and tool-based process analysis.

REFERENCES

Agrawal, A., Levendovszky, T., Sprinkle, J., Shi, F. and

Karsai, G., 2002. Generative Programming via Graph

Transformations in the Model-Driven Architecture. In

Workshop on Generative Techniques in the Context of

Model Driven Architecture (OOPSLA). Seattle, pp. 1-

11.

Becker, J., Delfmann, P., Dreiling, A., Knackstedt, R. and

Kuropka, D., 2004. Configurative Process Modeling -

Outlining an Approach to Increased Business Process

Model Usability. In Information Resources Manage-

ment Association Conference (IRMA). New Orleans,

pp. 615-619.

Becker, J., Delfmann, P., Knackstedt, R. and Kuropka, D.,

2002. Konfigurative Referenzmodellierung. In Wis-

sensmanagement mit Referenzmodellen, (Eds, Becker,

J. and Knackstedt, R.) Physica-Verlag, Heidelberg, pp.

25-144.

Chen, P. P.-S., 1976. The Entity-Relationship Model.

Toward a Unified View of Data. ACM Transactions

on Database-Systems, 1, pp. 9-36.

Darke, P. and Shanks, G., 1996. Stakeholder Viewpoints

in Requirements Definition. Requirements Engineer-

ing, 1, pp. 88-105.

Engels, G., Heckel, R., Taentzer, G. and Ehrig, H., 1997.

A View-Oriented Approach to System Modelling

Based on Graph Transformation. ACM SIGSOFT

Software Engineering Notes, 22, pp. 327-343.

ESPRIT Consortium AMICE, 1989. CIM-OSA. Open

System Architecture for CIM, Springer-Verlag, Berlin

et. al.

Ferstl, O. K. and Sinz, E. J., 1998. SOM Modeling of

Information Systems. In Handbook on Architectures of

Information Systems, Vol. I (Eds, Bernus, P., Mertins,

K. and Schmidt, G.) Springer-Verlag, pp. 339-358.

Findeisen, P., 1994. The Metaview System, Alberta.

Finkelstein, A., Kramer, J., Nuseibeh, B., Finkelstein, L.

and Goedicke, M., 1992. Viewpoints: a framework for

integrating multiple perspectives in system develop-

ment. International Journal of Software Engineering

and Knowledge Engineering, 2, pp. 31-57.

Frank, U., 1994. Multiperspektivische Unternehmensmod-

ellierung. Theoretischer Hintergrund und Entwurf

einer objektorientierten Entwicklungsumgebung,

Oldenbourg, München, Wien.

Hammer, M. and Champy, J., 1993. Reengineering the

Corporation. A Manifesto for Business Revolution,

HarperBusiness, New York.

Ishikawa, K., 1985. What is Total Quality Control? The

Japanese Way, Prentice Hall, Englewood Cliffs.

Ledeczi, A., Maroti, M., Bakay, A., Karsai, G., Garrett, J.,

Thomason, C., Nordstrom, G., Sprinkle, J. and Vol-

gyesi, P., 2001. The Generic Modeling Environment.

In Workshop on Intelligent Signal Processing. Buda-

pest, pp. 19-25.

Nissen, H. W., Jeusfeld, M., Jarke, M., Zemanek, G. V.

and Huber, H., 1996. Managing Multiple Require-

ments Perspectives with Metamodels. IEEE Software,

13, pp. 37-48.

Nordstrom, G., Sztipanovits, J., Karsai, G. and Ledeczi,

A., 1999. Metamodeling - Rapid Design and Evolution

of Domain-Specific Modeling Environments. In IEEE

ECBS Conference. Nashville, pp. 68-74.

Rosemann, M., 1998. Managing the Complexity of Multi-

perspective Information Models using the Guidelines

of Modeling. In 3rd Australian Conference on Re-

quirements Engineering. Geelong, pp. 101-118.

Rosemann, M. and Green, P., 2000. Integrating multi-

perspective views into ontological analysis. In 21st In-

ternational Conference on Information Systems. Bris-

bane, pp. 618-627.

Rosemann, M., Schwegmann, A. and Delfmann, P., 2005.

Preparation of Process Modeling. Appears in Process

Management. A Guide for the Design of Business

Processes, (Eds, Becker, J., Kugeler, M. and Rose-

mann, M.) Springer-Verlag, Berlin et al., 2

Edition.

Scheer, A.-W., 2000. ARIS - Business Process Modeling,

Springer-Verlag, Berlin, 3

Edition.

Soley, R. and OMG Staff Strategy Group, 2000. Model

Driven Architecture (White Paper), Object Manage-

ment Group, Needham.

Zachman, J. A., 1987. A Framework for Information

Systems Architecture. IBM Systems Journal, 26, pp.

277-293.

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION