Business Processes, Process Logic and Information Architecture

A Tentative Case Study

Coen Suurmond

RBK Group, Keulenstraat 18, 7418 EP Deventer, The Netherlands

csuurmond@rbk.nl

Keywords: Process Logic, Information Architecture, Organisational Semiotics, Business Processes.

Abstract: Subject of this paper is modelling the process logic of the business processes of an enterprise, taking into

account both the formal and the informal aspects of the organisation, but disregarding how the business

processes have developed over time in operational practice. The aim is to arrive at a stable information

architecture that has sufficient flexibility to absorb developments in the environment and in the enterprise

itself in the presentation layer and business rules, without affecting the information architecture itself.

1 INTRODUCTION

Subject of this paper is the modelling of the process

logic of the business processes of an enterprise (here

named AYS), taking into account both the formal

and the informal aspects of the organisation, but

independent of how the business processes have

developed over time in operational practice. The aim

is to arrive at a stable information architecture that

has sufficient flexibility to absorb developments in

the environment and in the enterprise itself in the

application software that will be built upon it. Parts

of this approach have been described in earlier

ICEIS and BMSD papers, in particular, papers

presented at ICEIS 2010, BMSD 2011, and BMSD

2012. This paper will present the preliminary results

of the application of this approach to a practical

case.

After this introduction, the second part of the

paper describes the problem and the backgrounds to

the issue. After a short explanation about the theory

of the firm and the role of semiotics in the case study

the role of the analysis and modelling of business

processes as foundation for the development of an

enterprise information system is explored.

The third part describes the backgrounds of the

enterprise where the study was carried out as well as

the most significant characteristics of the enterprise

itself. This is followed by a short description of how

the study was carried out and in particular of the

interaction between analyst and practitioners in such

a project.

The last part of the paper is the evaluation of the

results of the case study against several aspects.

Especially the process logic for the internal structure

of the business processes and the concept of lean IT

for the efficiency of the business processes are

important here.

2 MANUSCRIPT PREPARATION

2.1 Problem

The problem in this case study is the design of a

solid foundation for a newly to be developed

information system for the enterprise concerned. The

main aims for the enterprise are (1) to be able to

replace the current software package in the short

term without loss of essential functionality, (2) to

expand the new system in the slightly longer term to

provide the desired support for the enterprise’s

business processes and (3) to be capable of

supporting possible strategic scenarios (of which it

cannot be determined in advance if and when they

will occur) at some later date.

At first, the problem demands an information

architecture based on both the actual processes and

on the new processes envisioned in the strategic

scenarios. Meanwhile the architecture must allow

the implementation of just a number of key

functions at first to allow full decommissioning of

the current system. An essential feature of the

information architecture must be the maintainability

of the business rules in a number of areas because

the rules imposed by external stake holders are

subject to sudden and rapid change. Complying with

Suurmond C.

Business Processes, Process Logic and Information ArchitectureA Tentative Case Study.

DOI: 10.5220/0004773900430053

In Proceedings of the Third International Symposium on Business Modeling and Software Design (BMSD 2013), pages 43-53

ISBN: 978-989-8565-56-3

these rules is required to operate in this line of

business.

The main idea behind the case study is that the

stability of the desired information architecture is

determined by its autonomy from chance factors and

passing circumstances. In other words, the main idea

is that the essential and durable structure of the

business processes should form the foundation of the

information architecture. This introduces the

question how this stability can best be found. This

approach presumes that the characteristics of

markets and products determine the essential

structure of the business processes for an enterprise.

To be active in a certain market, the enterprise has to

follow a number of social conventions that are

associated with the market and that place norms on

the behaviour of the individual enterprise in the

market. The same holds for the products of an

enterprise, for both material and immaterial

products. Of course, for material products a number

of physical rules and constraints apply as well, such

as food safety requirements in case of food products.

The idea is that hard statements can be made

regarding the structure of the business processes and

the associated information flows based on

knowledge of the norms that apply for markets and

products.

An additional motive to start the analysis of the

structure of business processes with the markets and

products is that this provides a better foundation for

the collaboration between analyst and practitioners

than the analysis of the current business processes of

the enterprise. This will be explored further in a later

paragraph.

2.2 Earlier Work

For the case study, we will rely on earlier theoretical

work, as presented at ICEIS 2010 and also at two

editions of BMSD, namely BMSD 2011 and BMSD

2012 (Suurmond, 2012; Suurmond 2013), and we

will also rely on a long-term involvement with the

Organisational Semiotics Community as well as on

extensive experience in the design of information

systems for the food processing industry. However,

this case concerns an electro-technical reparation

enterprise and thus presents an interesting case for

the transfer of practical experience between two very

different lines of business.

2.3 Theory

2.3.1 Theory of the Firm

An enterprise derives its existence from successfully

delivering products to its markets. The two basic

requirements for sustainable business are market

demand and efficiency of production. Every

successful enterprise also has a form of ‘uniqueness’

that distinguishes it from its competitors and that

cannot be copied (Kay, 1993). This unique and

idiosyncratic character of an enterprise determines

its place on the market and can be found in partly

intangible factors such as company culture, history

and market trust or reputation. These factors can

indirectly be found in the company culture and

directly in the way in which individual employees

are dealing with individual cases in the business

processes. The latter is subject to acculturation

processes, with conscious and unconscious, designed

and historically grown mechanisms by which

individuals learn “how things are done here”.

This approach to the enterprise indicates that

how an enterprise operates and the operations within

an enterprise always have to be evaluated in light of

its position in the market. This does not mean that

the contribution to the market position is the only

norm; there are inescapable human and societal

norms after all. It does highlight that it is essential

for the continuity of the enterprise that the market is

the ultimate standard against which it is evaluated.

This holds for operational actions and it holds as

well for the actions taken by its management and for

its strategic choices. Therefore, in analysing

business processes and in designing an enterprise

information system to support those business

processes the orientation on the markets and

products of the enterprise should be the first

criterion.

From the above considerations it follows that the

metaphor of the enterprise as an organism is more

appropriate than the rationalistic and mechanistic

approach of the enterprise (De Geus, 1997). After

all, an enterprise is a social phenomenon in which

the actions are determined by social norms and by

interpretation processes. This means that modelling

business processes and information flows from a

purely rationalistic-mechanistic view or weakening

the strengths of an enterprise by reducing the

number of possible solutions in the business

processes have to be avoided in the development of

an enterprise information system.

2.3.2 Semiotics

Social communication happens through sign systems

and the interpretation of signs is partly determined

by history (the way in which signs were interpreted

in the past) and partly by context (and sometimes by

the way in which they are uttered as well, a certain

Third International Symposium on Business Modeling and Software Design

inflexion of the voice for example).

Within business processes the efficiency requires

that much of the information can be processed by

systems. The sign systems created to this end are of

a formal nature: the meaning of variables and of

possibly of value ranges is recorded in the systems

in advance.

Within an organisation all kinds of capacities in

which information can appear can be distinguished.

Part of the information can be found in computer

based systems, part is ‘between the ears’ by training,

knowledge and experience and part is exchanged

through all manners of ad hoc communication. The

nature of the sign system determines the possible

interpretations of the information given. In part

because of the degree of formalisation.

Although semiotics remains in the background in

the case study, semiotic insights certainly play their

part in the analysis and modelling. This is especially

evident in the meaning of sign systems and of

interpretation processes in both the analyses and in

the business processes. It is also visible in the

prominent role played by social norms, in particular

in understanding business processes against the

background of the normative function of the markets

and products of the enterprise (Stamper, 2000; Liu,

2000).

2.3.3 Process Modelling and Information

System Development

Modelling business processes with the associated

information flows, and validating the resulting

model, is a communal activity of two different kinds

of actors, each with a completely different

background. On the one hand there is the analyst

with communicative, analytic and modelling

competencies (accustomed to formalised sign

systems), on the other there is the practitioner with a

detailed knowledge of what happens in practice, of

organisational structures and procedures and

equipped with lots of tacit knowledge.

The difference in perception and background of

the different actors cannot be bridged by the analyst

transforming himself into a practitioner (or vice

versa). As well as the time such a transformation

would cost, it would mean a fundamental lack of

recognition for the difference between the role of the

analyst and the role of the practitioner. It might seem

tempting to unite all of the required knowledge and

experience in one person, but it would imply a major

risk of consigning the process of modelling and

analysis to the realm of tacit knowledge, with

pernicious consequences for validation and

maintenance of the model. In effect it would be a

one man show.

The model that is to be constructed of the

business processes and the accompanying

information flows should represent the essential

structure, thus forming a stable basis for the

information system that is to be developed. As a

model it is an abstraction and not ‘true’ or ‘false’,

but suitable to a greater or lesser degree for the

purposes for which it was developed. A basic

condition is stability: it should be possible to support

all kinds of variations of the business processes by

one single model. A second condition is the

reduction of complexity: the model should enable

insight into the complex reality of concrete business

processes by omitting all kinds of details that are

irrelevant to the structure and by naming the

separate elements of the processes.

An abstract example of one aspect of modelling:

say that a certain production process moves through

three different steps and that these steps are

modelled as they are observed in practice:

Later, the process is changed and the model with it:

However, if the process elements had been analysed

further, the following model could have been the

outcome:

In this last model with stages A through G both

process variants could have been represented. Before

the changes to the process stages A, B and C form

the first sub-process, D and E the second and finally

F and G the third sub-process. After the changes the

sub-processes encompass different stages (A, B

through F, G), but the basic model remains the same.

The major challenge is to distil those elements A

through G from the concrete business processes with

all of their details. It is not unusual to start from

interviews with practitioners from different layers of

the organisation combined with the analyst’s own

observations of the processes and information

products. Often, documents regarding the

organisation and those of the processes regarding

quality control are important sources in arriving at

an understanding of the processes. However, in

practice this springs a number of problems. The first

issue is the degree to which the formal

documentation of the organisation and its processes

Business Processes, Process Logic and Information Architecture - A Tentative Case Study

agrees with the organisational reality. Giving

prominence to these documents implies taking a

position regarding the value of these documents,

either negatively (‘worthless paper truths of the

managers’) or positively (‘we are trying to act in this

way, but it was not possible just now’). In both cases

the formal documentation is the leading norm in

taking stock of and evaluating the processes.

The second issue is the effectiveness and

efficiency of the Interviews with practitioners. On

the one hand the analyst can drown in details; on the

other essential elements of the business processes

might remain undiscussed. The analyst does not

know they are there, while to the practitioner they

are so obvious that it does not occur to him to

mention them. The same holds for looking into the

information products. How does the analyst find out

what is not there, what is left out because it is

supposed to be known or because the information is

obtained by other means?

Another approach is working from the

underlying norms of the enterprise. This begins with

an orientation on the markets and products of the

enterprise. After all, the enterprise exists because it

creates products for customers and this is given

shape in the business processes. The organisation

(and quality control) has to structure and stabilise

the business processes, but that should happen to

serve the higher purpose: to effectively serve

customers in an efficient manner. Needless to say,

other essential norms apply that lie outside of the

enterprise. Those are in part societal norms and in

part norms from specific stakeholders such as

regulations by the government (requirements for the

financial accounts are a striking example).

The norms that are based on markets, products

and external stakeholders are in general more stable

and accessible than all the ins and outs of the

business processes (especially when the analyst has

to work his way through lots of details before

isolating what is structural from what is irrelevant

for his purpose). On top of this, possible

developments in those norms are essential for the

internal structure of an enterprise. Those can be

developments as a consequence of strategic

decisions by the enterprise or external developments

that the enterprise has to follow if it wants to remain

in the market. The model of the business processes

should be capable of following those developments

without major structural changes.

2.3.4 Ontology and Ideal Type

Through the process logic the essential and stable

elements of business processes and information

flows should be mapped. This aim can also be

distinguished in several ontological approaches.

Essentially, the process logic is used to define a

small and specific universe of discourse along with

the associated operations. Using a classification of

Poli the process logic could be placed under the term

formalized ontology: “...to find the proper formal

codification for the constructs descriptively

acquired...” (Poli, 2010), with the essential

difference however, that the intended constructs are

not obtained by means of “collection of such prima

facie information on types of items either in some

specific domain of analysis or in general” (Poli, p2),

but by a normative and critical analysis of the

enterprise against its background of its products and

markets.

The use by Dietz of the term ontology points in

the same direction: “Our goal is to understand the

essence of the construction and operation of

complete systems, more specifically, of enterprises”

(Dietz, 2006). In a very different time and against a

very different background Max Weber was

searching for a precise and consistent description of

social patterns and their backgrounds in his main

work Economy and Society: “In order to give a

precise meaning to these terms, it is necessary for

the sociologist to formulate pure ideal types of the

corresponding forms of actions which in each case

involve the highest possible degree of logical

integration by virtue of their complete adequacy on

the level of meaning” (Weber, 1968).

A marked difference between the ontology

approach as used in ICT and the use of the concept

of an ideal type of Weber is the way in which the

resulting model is viewed. Is it a basic design to

engineer the social world towards what it should be

or is it an instrument to understand patterns of rule-

based human action in a specific context? The

thinking behind the former idea is formulated clearly

by Dietz: “Contrary to many dissenting theories that

have been advanced in the past century,

organizations are artifacts. They are systems that are,

and have to be, designed and engineered, like any

other artifact” (Dietz, 2006). The latter is expressed

by Weber in two ways, directly following the earlier

quote: “…it is probably seldom if ever that a real

phenomenon can be found that corresponds exactly

to one of these ideally constructed pure types.”

(Weber, 1968) and “The more sharply and precisely

the ideal type has been constructed, thus the more

abstract and unrealistic in this sense it is, the better it

is able to perform its functions in formulating

terminology, classifications, and hypotheses”

(Weber, 1968).

Third International Symposium on Business Modeling and Software Design

The approach of using the process logic as a

means to arrive at an information architecture shares

characteristics with both of the above approaches.

The concept of process logic is based on a Weberian

idealisation and it is based on an analysis of the

underlying norms of human action. The information

architecture that is based on process logic is an

especially good example of organisational

engineering: a formal and consistent model of the

essence of the business processes in an organisation.

However, since the organisation as a social

phenomenon is anything but an engineered system,

but rather an emergent system that is continuously

changing itself, the information architecture is not a

prescription to how the organisation ought to

behave. It works in the reverse direction: when the

organisation behaves and develops itself as

described by Taylor and Van Every (Taylor, 2000)

and when the actions of the organisations are at the

same time determined by a number of inescapable

rules, then it has to be possible to represent those

matters within the capricious daily organisation

reality that are essential to the business in the

information architecture.

3 DESCRIPTION OF THE CASE

3.1 Introduction

AYS is a leading service and repair business for

mainly audio-visual equipment of major brands

operating nationwide. The enterprise carries out both

on-site and carry-in repairs and has a network of six

branches for the on-site and smaller carry-in repairs

that service the different regions of the country.

Larger carry-in repairs are performed centrally in

Arnhem. The main contract partner is a leading

brand (represented by its national importer), AYS is

a certified partner and carries out all repairs in The

Netherlands for audio-visual equipment of this

brand. AYS is also active on a smaller scale in the

repairs of other brands and of other kinds of

electrical consumer products.

The key elements of AYS are:

• Both on-site repairs and carry-in repairs of

audio-visual consumer products

• National coverage with six regional branches

• Strong affiliation with a strong brand

• About 100 employees

3.2 Structure of AYS

The legal structure and the structure of the business

processes are rather different at first sight. AYS

presents itself to the outside world as one

homogeneous company with a specific service

package. There is also a strong centralisation in

terms of management and strategy; the head office

defines the corporate identity and determines how

the business is done. Legally there are a number of

different entities (each a separate legal person) on

three levels:

• Level 0: The holding

• Level 1: The main office and multiple entities

that are not involved in the servicing and repairs

and that will not be discussed here

• Level 2: The regional branches

The main office encompasses a number of central

services, the main workshop with reception desk for

carry in service and it provides the on-site service in

its region. The regional branches provide the on-site

service in their regions and they have a limited

workshop facility with a limited reception desk

service. The regional branches are either full

subsidiary companies or fully owned by an

independent entrepreneur.

3.3 Contracts, Agreements,

Commitments

Curiously, there is only a very limited use of formal

SLA’s. The affiliation between the importer and

AYS has much more the nature of a relational

contract in which the details of the mutual

obligations are not described as much as it is based

on trust, established practice and, especially, on the

binding effect of the settlement of financial claims

of work carried out by AYS that are accepted or

declined by the importer depending on the

circumstances (circumstances that are not always

known to AYS). Here, it is clear that this is not a

symmetrical relationship; it is the importer who

leads the way, who determines how matters must be

handled both materially and financially. In practice,

there are a multitude of agreements and expectations

regarding the handling of repairs (turnaround times,

success rates) and regarding the handling of the

financial side. Current practice is mainly based on

the knowledge and experience of a number of key

figures in the AYS organization (which is both a

weakness and a strength; a weakness because of the

dependence on individuals, a strength because it is

hard to reproduce and thus cannot easily be adopted

Business Processes, Process Logic and Information Architecture - A Tentative Case Study

by others outside of AYS).

For other products groups and brands the same

pattern holds and the size of the contract partner is

there too defining for the (a)symmetry of the

relationship between AYS and its contract partner.

3.4 Strategy

AYS has a growing strategy in two directions. The

first direction is diversifying the brands. Because

there is a strong current dependence on one brand,

AYS is investigating the possibilities to apply the

current competencies for audio-visual consumer

products to different brands. Potential new activities

are not foreseen to demand new processes. However,

it is possible that agreements and interactions with

new parties will take on new forms (but that also

holds true with regard to the current clients).

The second direction is to use the competencies

and the nationwide network for new activities, in

particular services to professional users. Potential

such activities are the servicing of permanent audio-

visual installations, both for companies to whom that

is the core process (informing and/or advertising to

its customers) and for companies where it concerns

more internal presentation capabilities. A different

possibility is to provide the entire handling of defect

equipment for larger retailers (logistics service

partner). Another possibility is to provide

installations of new audio-visual equipment to

professional users. Currently, there are some small-

scale activities in these directions and growth

towards full scale services is a real possibility.

3.5 Stakeholders

In principle AYS is dealing with one, two or three

external parties and with one or two internal parties

for one repair job. The external parties are the end

user (usually a consumer but it can be a company),

the direct supplier (big chains of nationwide

operating retailers), and the importer as

representative of the brand. The client of AYS is one

of these three parties and the details of the

‘preceding parties often have to be registered as well

(the consumer has two preceding parties and the

importer has none). The contractor is one of the

AYS branches which can subcontract the work in

whole or in part to another branch of AYS.

Each stakeholder has its own way of providing

and requesting (or demanding) information and of

tracking the work and handling the financial side.

Moreover, these patterns are subject to unpredictable

change. The use of references by the stakeholders is

also erratic. Standards for dealing with warranty

conditions and for the execution of work differ per

stakeholder. Market and power relations determine

who is in charge, and as a smaller party AYS usually

has to comply with the demands and expectations of

the (much) bigger clients. Here, logic and facts can

sometimes be set aside. The flexibility with which

AYS deals with these complex and rapidly changing

practices is an essential factor for the internal costs

and for successfully getting the remuneration for the

performed work.

NB: The term ‘customer’ is difficult to apply in

the case of AYS, because there are so many kinds.

Because of this, the term will be avoided as much as

possible.

4 SOME PRACTICAL ISSUES IN

THIS CASE STUDY

4.1 Creating Common Background

between Analyst and Practitioner

The analysis and modelling took place in a series of

open conversations and presentations with

discussions with two of the three executive

managers / owners. As indicated the aim was to

arrive at a stable information architecture for the

enterprise. The stability of the architecture requires

that it is based on the underlying lasting patterns of

the business processes, as well as on an

understanding of the markets and products, trends

and strategic scenarios. At the same time

practitioners will take a perspective based on their

everyday work and will mainly be focused on their

current operational obstructions. To them, the

benchmark for the description and model of the

business processes is their daily practice, as it should

be. However, at the end of the process of analysis

and modelling the analyst should have a sufficient

grasp on the operational processes and the company

culture, while the practitioners should have a

sufficient grasp of the abstracted view of their

processes. Without this resulting communal basis it

will not be possible to discuss and evaluate the result

of the modelling in a fruitful manner.

The background to all of this work is formed by

the norms imposed by the external stakeholders, the

norms imposed by the nature of the products and the

norms that originate from the enterprise itself. It is

up to the practitioners to indicate these norms and it

is up to the analyst to formulate these norms in a

precise manner and to continuously test these norms

Third International Symposium on Business Modeling and Software Design

against the background of the business environment.

Here, it will often prove necessary to adjust the way

in which the norms are formulated; either by

adjusting the norm itself or by adjusting the

circumstances under which the norm applies. One of

the results of the analysis of the norms is that it

becomes clear which norms are hard with hard

conditions and context (and thus suitable for

machine interpretation) and which norms are either

‘soft’ or significantly subject to circumstances (and

which thus involve direct human interpretation and

responsibility in applying the norm to a concrete

case).

4.2 Rigid Principles Bring Practical

Solutions

The purpose of this phase of analysis and modelling

was not to solve current problems (other than the

problem of replacing the current software package

which could not be maintained), neither was it to

evaluate and to take stock of the demands and

wishes of AYS regarding the new information

system. Because of this it was remarkable to see the

following pattern emerge at a number of times

(especially in the latter stages):

• Within the process logic a sharp distinction is

drawn between two processes

• The practitioners react at first by projecting their

view of current practice onto the model. This can

result in an initial negative reaction: we do not

recognise our processes!

• Next, a discussion emerges about the correctness

of the formulated model against the background

of the norms within the organisation (mainly in

the area of responsibilities for the end result and

for the costs) and those outside of the

organisation (what do the external stakeholders

demand)

• Sometimes the discussion results in adjustments

to the norms and/or to the model (but not in most

cases)

• Finally, the practitioners conclude that by

working according to the formulated model a

number of current practical problems will be

solved, because those problems are the result of a

muddying of the boundaries between two

processes

An important example of this pattern is the

introduction of the concept of transfers combined

with the concept of a process step and the

assignment of a service order to a single branch. One

of the principal norms in the enterprise is that of

turnaround time. External stakeholders link the

remuneration for a repair to the meeting of the

agreed upon turnaround time. Thus, the monitoring

of turnaround times is a crucial component to the

internal monitoring of the service orders. Because of

the current out-dated information system, but also

because of how the work floor is organised, this

monitoring is at present a cumbersome and

vulnerable process. Building software that supports

the current practice would likely be a major task,

with lots of maintenance afterwards.

By making the current practice explicit by

modelling a number of successive process steps

(receipt – administrative screening – technical

screening – actual repair – preparation for shipping –

shipping) and by explicitly naming the transition

between process steps as a transfer, it becomes a

trivial job to evaluate both internal and external

turnaround times per process step in the new

information system. The explicit transfer between

process steps also improves organisational clarity:

who is responsible for the service order? If desired,

it is also possible to split the transfer in two: making

it available to the next process step and the

acceptance by the next process step. This system

also allows for easy monitoring in such a way that

internally accumulated delays can be compensated

for by adjusting the turnaround time for the next

process step for the particular case.

An accompanying concept to this concept of

transfers is that of “on-hold” situations. When a

service order is waiting for activities outside of the

control of the relevant process step, the order will be

on-hold. Here, it is recorded why it is on-hold, by

whose actions the on-hold situation will be lifted,

when this is expected to be the case and if the on-

hold situation causes the turnaround time to be

suspended.

And while this model was completely new to the

practitioners, it cannot be called an invention by the

modeller either. It was just giving shape to and

formalising something that was very close to the

surface of the business processes, but which was not

viewed as such up to now. Rigorous modelling of

the process steps, transfers and on holds led to

clearly definable administrations and

responsibilities, and less complex business

processes.

Business Processes, Process Logic and Information Architecture - A Tentative Case Study

5 EVALUATION

5.1 Process Logic

In this paper the term process logic has been used to

distinguish it from the idiosyncratic characteristics

of the enterprise. Usage of this term was founded in

a number of considerations. First, it deals with a

schematic representation of the inevitable structures

within a certain line of business, valid within a

specific social environment. One might say that

these are the structures a student should be taught,

while he does not yet know which specific company

will employ him. Second, norms for completeness

and consistency hold for this schematic

representation. On the level of abstraction chosen, it

should be capable of representing every scenario that

arises in practice (a tall order and a real challenge!)

and there should be no inconsistencies or

ambiguities. This demands definitions of the

elementary terms and a precise formulation of the

underlying norms.

In applying a concrete model of process logic it

is essential to realise that it is an instrument to

represent situations and processes (description, and

an instrument for analysis) and that it not intended to

be used to dictate how processes and situations

ought to be (prescription). At its core, the process

logic is a formalised sign system to (1) gain an

understanding of the processes in the analysis, (2)

precisely formulate terms and rules and (3) describe

an information architecture that because of its

character forms the basis for later system

development. At the same time, process logic has to

help the enterprise avoid inconsistencies (for

example by preventing the use of key terms such as

“service order” to mean various things) and leave

the enterprise to choose how it sets up and executes

its processes. An enterprise with five experienced

employees will have to organise itself very

differently from an enterprise with 5 offices, each

with 20 employees and 10 flex workers!

In the case at hand the attempt to uncover the

process logic has worked well, both to establish a

common background between the analyst and the

practitioner and to arrive at precise definitions, rules

and demarcations.

Process logic is an important element for a

common background, because it is a shared search

for the underlying structures. For the analyst a

general orientation on the specific markets and

products of the enterprise with its peculiarities

combined with a general background and common

sense is sufficient to play his part in the discussions.

All kinds of details that are hard to understand for an

outsider can be isolated in this stage and assigned to

specific places in the structure, without first needing

to be fully explored or understood. This approach

also forces the practitioners to be explicit about what

really matters.

The approach also clarified what actually

happens in the current business processes, as the

examples regarding the concepts of process steps

and service order have shown above. This

conceptualisation of current practice allows for a

very precise and fitting way of modelling and

monitoring the business processes and leads to a

better understanding by the practitioners of their

own processes.

5.2 Administrations, Identities and

References

One of the pillars of process logic is the concept of

an administration. The definition of an

administration given by Starreveld is: The

systematic collection, recording, processing and

supplying of information for purposes of the

managing and functioning of a household and for

purposes of the accountability thereof". When we

combine this definition with the idea that an

administration concerns one specific domain, it

seems obvious to directly name the required

administrations when process logic is specified.

Here, it is important to note that administrations

concern product data and not master data.

The first criterion to arrive at an administration is

a high degree of homogeneity and autonomy. It must

be possible to view the data that are collected in one

administration as a single coherent whole. Also, the

direct interactions with and dependencies on other

administrations have to be as few as possible. A

second criterion is the responsibility for its

management; each administration in an organisation

should have a single person who carries the

responsibility for the correctness, timeliness en

completeness of the data in it. This responsibility

should ideally be located close to the primary

process, to ensure that those responsible are in touch

with the reality represented in the administration.

In the case at hand this mainly means that each

branch has its own administration and carries full

responsibility for it. For example, there is no central

registration of orders and stocks, but each branch

maintains its own administration in these areas.

Incidentally, in this concrete case it does not mean

that they are free to choose their own systems.

Everyone uses the same system, but within it every

Third International Symposium on Business Modeling and Software Design

branch has its own administration. Of course, in the

presentation layer connections can be made across

the different administrations to enable central

monitoring of the processes. And the serial number

administration in which the service history of

individual devices is registered is an example of an

administration that must necessarily be kept

centrally because of the nature of the data and the

interaction of these data with external systems.

For the development of the new information

system the specified administrations are composed

of two parts. First, there is a basic structure with

entities with their internal and external identities. Of

course, within the database a single entity has a

single unique identity, but inside and outside of the

organisation an entity might have many alternative

identities. Think of the number of a service order for

example: internal and external stakeholders can use

all kinds of references for themselves and use their

own reference to request or provide data. Another

example of this mechanism is the serial number: at

first viewing this is a unique number. In practice,

this number is unique number within a specific

brand, product group or model. Thus, a serial

number does not uniquely specify a single device or

part while it is required to do so. The enterprise also

has a need at times to refer uniquely to a part that

does not have a serial number, which can be met by

assigning it a particular number generated for this

purpose. When the part is gone, the number is as

well. Based on these considerations, it is prudent to

primarily assign unique numbers generated by the

enterprise itself to parts and devices and to consider

the serial number on a device or part as an alias to

arrive at the generated number. This system is

always applicable and avoids the complicated

composite identification that results from accepting

the serial number as identifier.

From the very beginning, the structure of the

administrations has to be erected along with the

associated references inside and outside of the

enterprise. Further dressing up and setting up of the

administration with data relevant to the contents,

further status information, et cetera, can be done

afterwards, in parallel to the development of the

applications that use these data.

5.3 Lean IT

The lean approach places a number of demands on

the set-up of an enterprise information system.

Positively formulated, the information system must

contribute to the effectiveness and efficiency of the

business processes and use the most appropriate

means to do so. Negatively formulated, the system is

not allowed to cause waste (e.g.: excess production

of information), to place undesired limits upon the

business processes and it may promote the autonomy

of processes as long as this does not harm overall

efficiency and effectiveness. Information from the

system has to be reliable and relevant.

Put otherwise: employees have to keep being

presented with information in the right way and feed

back information themselves and they must have the

freedom to make their own decisions within their

domain. Two examples illustrate the application of

these criteria: First, the registration of direct hours

on service orders. From the management there was a

strong desire to gain a detailed view of the usage of

hours in the primary process. In computer systems

nothing is simpler than granting this wish:

registration per service order, per department, per

activity of time used. In everyday reality however,

such a system leads to unusable information. First,

because there is a mismatch with the way in which

the work is actually done. Second, because it results

in an excess of registrations. Either the categories

are too general and the registrations limited, or the

categories are specific and the registrations time-

consuming. In both cases the registrations will

provide an unreliable view of reality. That is why we

opted to start with registration per service order in

just the repair department, where it is registered for

each employee when he begins and ends with a

service order and which activities he performed

during this time (which does not provide the time

per activity). In this way, insight is provided into the

ratio of time spend on service orders to time spend

on other activities. Insight is also provided into the

cases in which a service order has been handled

repeatedly, by whom and to perform which

activities. These data provide the foreman with a

measuring stick to monitor the performance of his

crew and to pay additional attention to activities that

seem to take up too much time.

A second example is insight in what tasks must

be done and which tasks might be done. The

turnaround time of service orders is one of the most

important parameters for the performance of the

enterprise with regard to the various stakeholders.

When norms are created for the turnaround time as a

whole and for the turnaround time of each individual

process step, it is possible for the system to directly

show which service orders have to be handled on a

particular day in a particular team and which other

work remains to be done with what time remaining

according to the norms. This allows the team to

make optimal use of its capacity by handling the

Business Processes, Process Logic and Information Architecture - A Tentative Case Study

service orders that are the best fit at that moment for

the current activities and available resources. Self-

control instead of central control should result in a

significant advance in efficiency here.

5.4 Protecting and Strengthening the

Distinctiveness of the Company

The strength of the enterprise is two-fold:

nationwide coverage and a strong bond to a strong

brand with strong partners. The downside of this

bond to market heavyweights is that they determine

to a large extent what the service conditions will be,

both regarding the fees and regarding the mutual

information supply. In this sense we are dealing with

strongly asymmetric relationships. On the other

hand, AYS is able to relieve large market parties of

work that those parties are much less well equipped

to handle and to carry out this work to a high

standard. In other words, the enterprise has a clear

place in the market.

Current legacy information systems of AYS have

been built or adapted based on concrete

developments in and requests by the market

partners. Because of the aging core system solutions

have been added to applications that were not

originally meant for such. The new system should

improve the ability of the enterprise to react to

market developments through improved insight into

the actual course of the processes by sharply

demarcating the various administrations. This

improved information position should result in an

improved bargaining position with both existing and

new contract partners.

A second contribution to the strategic position of

the enterprise is also based on pulling apart the core

administrations. In this way the enterprise is enabled

to develop activities other than just service orders

for defective equipment. The potential of nationwide

coverage with service vehicles can be utilised for

other activities as well. The information architecture

allows both developments to be introduced gradually

to expand into new markets, without major, risky,

investment.

Finally, the flexible legal and financial structure

is a major advantage. The current diversity with both

fully-owned branches and branches exploited by

independent entrepreneurs allows for rapid change

both in acquiring work and in subcontracting it.

AYS can profile itself as a strong market party

because it presents a unified face to the client (in

corporate identity and in home visits) and

orchestrates the orders, while the work may be

carried out elsewhere. Separating the diversity of the

legal and financial structures from the unity of AYS

as a business actor is an important requirement for

the information architecture.

6 CONCLUSIONS

At the time of writing this paper the analysis was not

fully completed yet. The manner in which the

project went and the structures that have been

identified as process logic are already sufficient to

consider the project successful for the client AYS.

Here, it is relevant to note that AYS commissioned

an analysis of the business processes by a potential

supplier and industry specialist about a year before

this case study, thus supplying AYS with a

comparison. This earlier analysis did not lead to new

insights into their processes since it was fully based

on inquiring after factual details of the business

processes of AYS to prepare for the implementation

of the package. Terms were mostly left undefined

and the information gap between supplier and

customer was never bridged.

In contrast, the approach in this case study

encompassed a critical analysis of the business

processes and resulted in many new insights for

AYS into its own practice. Furthermore, the

structure described is suitable to accommodate

future developments.

Thus, the method of analysis of the process logic

has withstood the test of practice. However, the form

for the final product, the description of the process

logic, has not yet been found. The description as a

list of definitions, a specification of the

administrations and a specification of references

certainly forms a useful and testable foundation, but

a more formalised form of core entities and their

transitions would be desirable.

To conclude, to make the transition between

daily actions by employees in the business processes

on the one hand and the process logic and

information architecture on the other, a number of

layers will have to be distinguished in the enterprise

information system:

• A core system with administrations and

operations

• A number of rulebooks (sets of business rules

that determine the behaviour of the operations)

• Application software

• Setup of the application software

• Agreements and procedures regarding

information flows and use of the computer

systems

Third International Symposium on Business Modeling and Software Design

• Actual information flows within and outside of

the pre-determined paths for doing so (computer

systems, forms, structured consultations) within

the daily business processes

The core system as a stable basic structure and the

more changeable rulebooks on top of it should be

specified rigidly in an abstract and formalised

manner. The actual information flows are a

constituent part of the organisation as a socially

emergent phenomenon and ultimately it is

impossible to fully capture their dynamics and

wealth of detail. The elements in between are a

mixture of social conventions and logical modelling

in practice. IT people and bureaucrats (in its

Weberian meaning) prefer to work here with formal

sign system, while the practitioners who need to deal

with nuance and to weigh heterogeneous norms

against one another in practice are much more

inclined to non-formal sign systems such as free

text, oral explanations and face-to-face discussions

with colleagues.

A major recurring problem in the development of

an enterprise information system is the balancing of

model with reality, of System with Lifeworld

(Habermas, 1986). Acknowledging the formal nature

of the core system and the surrounding rulebooks

and acknowledging the dynamics, the capriciousness

and the intangibility of the daily organisational

reality can help in developing applications in a more

efficient way. On the one hand, these applications

are supported out of necessity by the stringent core

system, on the other they themselves have to support

daily practice. The conscious decision to limit

computer systems to those operations for which they

truly add value to operational practice is an essential

step. Too often requirements and wishes are drafted

from the perspective of managers located too far

from daily practice and too often slogans such as

‘paperless office’ or ‘everything inside the system,

no dependence on people’ are adhered to. In the end,

it is about the criteria of the Lean approach: add

value, avoid waste and always use the appropriate

means to the task (the latter is a translation to

practice of the avoidance of waste).

This case study had a tentative character, trying

out several ideas regarding both the theoretical

background and regarding the application of the

ideas in a real world project. As such, it succeeded;

in a short time good results were obtained

(especially in comparison to a previous analysis of

the same company carried out by a potential

software supplier).

REFERENCES

De Geus, A. (1997). The Living Company. London:

Nicholas Brealey

Dietz, J.L.G. (2006). Enterprise Ontology. Berlin:

Springer.

Habermas, J. (1986). The Theory of Communicative

Action. Cambridge: Polity Press.

Kay, J. (1993). Foundations of Corporate Success. New

York: Oxford University Press.

Liu, K. (2000). Semiotics in Information Systems

Engineering. Cambridge, Cambridge University Press.

Poli, R. (2010). Ontology: The Categorical Stance. In Poli,

R. and Seibt, J. (Eds.), Theory and Appications of

Ontology – Philosophical Perspectives (pp 1-22).

Berlin: Springer.

Stamper, R. (2000). Information Systems as a Social

Science: An Alternative to the FRISCO Formalism. In

Falkenberg, E.D., Lyytinen, K. and Verrijn-Stuart,

A.A. (Eds.), Information System Concepts: An

Integrated Discipline Emerging. Dordrecht: Kluwer

Academic Publishers.

Suurmond, C.P. (2012). Administrations as Instruments

for Dealing with Organizational Complexity. In

Shishkov, B. (Ed.), Business Modelling and Software

Design – First International Symposium BMSD 2011

(pp 130-146). Berlin: Springer.

Suurmond, C.P. (2013). Sign Systems, Information

Systems, and Engineering. In Shishkov, B. (Ed.),

Business Modelling and Software Design – Second

International Symposium BMSD 2012 (pp 82-101).

Berlin: Springer.

Taylor, J.R. and Van Every, E. (2000). The Emergent

Organization. Mahwah: Lawrence Erlbaum

Associates.

Weber, M. (1968). Economy and Society. Berkeley:

University of California Press.

Business Processes, Process Logic and Information Architecture - A Tentative Case Study