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
43
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
Copyright
c
2013 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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
44
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
45
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
46
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
47
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
48
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
49
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
50
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
51
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
52
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
53