THE JANUS FACE OF LEAN ENTERPRISE
INFORMATION SYSTEMS
An Analysis of Signs, Systems and Practices
Coen Suurmond
RBK Automatisering, Deventer, Netherlands
Keywords: Semiotics in Computing, System Development, Lean Information System.
Abstract: The term “Enterprise Information System” can be used in two ways: (1) to denote the comprehensive
structure of information flows in an Enterprise, or (2) to denote the computer system supporting the business
processes. In this paper I will argue that we always should take the first meaning as our starting point, and
that in analysing the use of information and information flows we should recognise the different kinds of
sign systems that are appropriate to different kinds of use of information in business processes. In system
development we should carefully analyse the way a specific company is operating, and design a
comprehensive information system according to the principles of Lean Thinking and according to the
conversational maxims of Grice.
1 INTRODUCTION
The central question is: How to handle a project, as a
sector specialist, with standard software for a
customer with its own distinctive capabilities? The
extremes between which the project moves represent
on one side the Standard (Best Practices, Me Too,
“everyone can work with our solution; so can you”)
and on the other side a customer specific solution for
a specific customer. On top of this it is common
practice for the standard solution to be developed
further partly as a result of customer projects.
Unfortunately it is also common practice for the
dividing line between standard and customer
specific not to be drawn distinctively enough. In the
case of new developments within the sector this is
complicated further because the first, second and
third customers turn out to have set the de facto
standard implicitly.
In this paper I will argue that (1) information
supply is distinct from information technology; (2)
in the development of an information system a clear
distinction must be made between the “bare”
software, the configuration, and the conventions and
working procedures regarding the use; (3) when all
information requirements are indiscriminately
committed to information technology, the result will
be a malfunctioning and burdensome system; (4) the
concept of Lean IT can be used as guidance to
prevent these negative consequences.
This paper is written based on 25 years of
experience at a supplier of industry specific standard
solutions, paired with a theoretical background in
business economics, organisational studies, and
language philosophy.
In this paper I will use insights from the general
science of sign use; semiotics. An important part of
the problems we encounter in IT projects can be
traced back to the properties of the different sign
systems, and our inclination to disregard these
properties in the analysis, development and
implementation of systems.
This paper will first look into the use of the term
“Enterprise Information System”. The theoretical
groundwork will be done in the subsequent sections
about semiotics, sign systems, business processes,
the relations between system and reality, and the
general requirements which an information system
should satisfy. By analysing several cases it will be
shown how these issues can affect practice. The
paper will be concluded by suggesting a layered
model for system development and by stating the
conclusions.
460
Suurmond C. (2010).
THE JANUS FACE OF LEAN ENTERPRISE INFORMATION SYSTEMS - An Analysis of Signs, Systems and Practices.
In Proceedings of the 12th International Conference on Enterprise Information Systems - Information Systems Analysis and Specification, pages
460-469
DOI: 10.5220/0002902104600469
Copyright
c
 SciTePress

2 WHAT DO WE MEAN BY
“ENTERPRISE INFORMATION
SYSTEM”?
By definition a system is the total of a number of
mutually connected parts. When we talk of an
Enterprise Information System, about which total do
we speak? Two views are important for the scope of
this paper: (1) the operational computer system,
including configuration and operational data, (2) the
total of conventions and procedures regarding the
information supply within a company. It should be
clear which view takes precedence: the information
system of the second view contains the information
system of the first view. In other, and stronger,
words: An information system of the first view
which is not properly embedded in an information
system of the second view, cannot fulfil its role and
in many cases will work counterproductively: efforts
will be inefficient and it will result in a distorted
representation of reality.
The “real” Enterprise Information System is the
structure of all information flows through an
organisation. The structuring of these information
flows should be founded on three pillars: (1)
responsibilities per part of the organisation, (2)
conventions regarding the meaning of data that are
made available to other parts of the organisation, and
(3) conventions regarding the correctness,
timeliness, and completeness of the information
made available. Of course computer systems
nowadays play a decisive role in information supply
within organisations, and increasingly in between
organisations as well (Supply Chain, EDI). If,
however, there is a lack of embedding in the real
information system, this decisive role can also turn
out negatively (expenses can be made unnecessarily,
decisions might be made on a basis of false
information, the company under performs regarding
customers and other stakeholders).
Lacking a definition of the comprehensive
Enterprise Information System, the computer system
itself will often be considered as the Enterprise
Information System in both meanings of the word.
When an idealised view of the organisation and its
processes is dominant, failure will be ensured. When
the users and practice take centre stage, the “real”
information system will at least implicitly be
present. This results in problems being brought to
light, but at the same time the comprehensive
framework is lacking to usefully discuss them and,
finally, to make well-founded decisions regarding
them (a well-founded decision is better to maintain
than a compromise that everyone can agree upon
eventually, but which is clearly a result of
negotiation instead of logic).
The concept of “Lean IT” could provide
guidance here. Analogous to the concept of “Lean
Production”, the question of information should be
analysed in terms of value added. The concept could
be summarised as: Provide information where it
adds value, do not waste resources in providing
superfluous information, and provide information in
the right way. The rest of the paper will focus in
particular on the questions of “the right way”, and
analyse sign systems, business processes, and the
frequent misfit between computer systems and
business reality.
3 SEMIOTICS AND TYPES OF
SIGN SYSTEMS
3.1 Sign Processing and Sign Systems
A comprehensive Enterprise Information System
provides for the obtaining, processing, storing and
supply of data for the execution of tasks within an
organisation. In principle the employees of the
organisation as information users are an integral part
of the Enterprise Information System, because they
continuously obtain, process, store and supply data,
just like the computer systems do it in their own
way. It is clear that such an information system
consists of very heterogeneous types of use and
types of users, and that information can be stored
and used in very different ways.
It is therefore essential to consider the way in
which all those different kinds of sign users and all
those different kinds of sign systems cooperate with
each other. It is also important to analyse how
different types of sign systems function, and what
happens when one kind of sign system is replaced by
another kind. It goes without saying that an essential
part in establishing an comprehensive Enterprise
Information System is assigning fitting kinds of sign
systems to the different parts of the system.
3.2 Transactions between Sign Systems
Another semiotic aspect of information systems is
the analysis of the transitions between sign systems.
What happens when someone codifies an
observation to input it into the computer, what
happens when someone interprets some output of a
computer to make a decision? Some trivial examples
THE JANUS FACE OF LEAN ENTERPRISE INFORMATION SYSTEMS - An Analysis of Signs, Systems and Practices
461

are: the transition between writing systems (e.g.
Cyrillic or Chinese script to Latin script, the
example becomes less trivial when it concerns
practical consequences like a no-fly list) or the
transition between languages (the German term
“Disposition” does not have a proper translation in
either English or Dutch). A good example of the
problem of identity in different sign systems is
provided by de Saussure: “the 8:25 train from
Geneva to Paris” (Saussure, 1966, p108). For the
timetable the train is the same each day, for the train
spotter or railway engineer it is not. Please note:
these examples are still entirely unrelated to
computers.
Within a language these transitions happen as
well. Think of the jargon within a profession for
example. A more subtle form, however, we find
between the different departments of an
organisation, think of communication between the
commerce and production departments, but also
between the hierarchical layers within an
organisation.
3.3 Sign Systems and their Properties
A fundamental distinction can be made between sign
processing within formal systems and sign
processing by humans. The most important property
of sign processing by a formal system is the closed
nature of it: pre-encoded data is processed by pre-
encoded software. Opposed to this there is the ability
of humans to interpret data according to context. In
other words: the perception of the environment plays
an important part in human sign processing. The
importance of this attribute is shown by an important
means of protest for public officials: the punctuality
protest. In this protest they act as a formal system
would; they adhere strictly to the rules as rational
actors and are not perceptible to reason.
3.4 Ruthrof
In his work “Pandora and Occam” Horst Ruthrof
names three categories of a fundamental lack of
clarity in our use of natural language, namely: (1)
modal opacity, (2) propositional opacity, and (3)
semiotic opacity (Ruthrof, 1992, p 4f).
Modal opacity concerns the intention of what we
say; when a customer asks a supplier whether he can
deliver 300 kg of steel tomorrow, it really is an
order. Depending on the backgrounds and
expectations, a delivery of 265 kg can be seen as
fulfilling the request, or a delivery of 298 kg can be
considered a deviation by the customer (see also
Searle’s discussion of locution, illocution and
perlocution in his theory of Speech Acts) (Searle,
1969).
Propositional opacity concerns the contents, or
the references, of our communications; in the
Frequently Asked Questions on his website Andrew
Tanenbaum addresses the question of which
countries he has visited. There he names the
example of visiting the USSR, but never Russia.
Now suppose he went to Moscow while in the
USSR; he then would have visited the capital of
Russia, without ever having been in Russia itself.
Semiotic opacity concerns the problem of the
transition between sign systems, and is in part a
result of the other two opacities; in the transition
between sign systems part of the context, and with it
part of the meaning, of the possibilities of
interpretation is lost. See also the movie “Lost in
Translation”.
3.5 Boisot, Van Heusden & Jorna
Max Boisot in his analysis of knowledge assets has
developed an instrument for the assessment of the
different aspects of knowledge and information; the
concept of Information Space or I-Space. The
respective axes of the I-Space represent the degree
of codification, the degree of abstraction, and the
degree of diffusion. “The process of codification
creates perceptual and conceptual categories that
facilitate the classification of phenomena” (Boisot,
1998, p42). Abstraction generalises and searches for
underlying structures. Abstraction is often based on
codification, but not necessarily. The abstract
processes according to which a craftsman plies his
trade are not usually codified, but they are certainly
present. Or consider the pattern-industry in Software
Engineering; the work of Gamma and his co-authors
was able to gain popularity in such a small amount
of time, because it appealed to already present
abstractions of software engineers. Using their
codification these were made accessible for a much
more efficient transfer and further analysis. Thus we
have arrived at the third axis: the spread of
information, or diffusion. Both technical and social
systems are required to make information available
to others through time and space.
From the point of view of sign systems it is
important to understand that the different technical
and social systems each place their own demands on
the way in which the information is encoded and
abstracted. Also, in the production process the
abstract and codified information of a product
specification must eventually be converted into
ICEIS 2010 - 12th International Conference on Enterprise Information Systems
462

concrete individual products by machines and
humans.
Van Heusden and Jorna have generalised the
model of Information Space to a model for the
Semiotic Space, with the following three axes: (1)
level of detailing of sensory (perceptual) knowledge,
(2) degree of codification, (3) degree of abstraction
(Van Heusden, 2001).
3.6 Organisational Semiotics (Stamper/
Liu)
The Organisational Semiotics approach takes a
similar interest of the role of semiotics in
information systems engineering (Liu, 2000). The
concept of affordances (Gibson, 1986) and the basic
notions of human responsibility and norm-based
actions could prove very useful for the development
of lean information systems. However, it seems to
me that this approach has difficulties in case of
vague, evolving or conflicting norms, and that it has
a rather “static” semantic stance. In analysis it tries
first to establish the meaning of all terms concerned,
and will then define the norms involved (“A Norm
Analysis is normally carried out on the basis of the
result of the Semantic Analysis”, Liu, 2000, p102).
The pragmatic and the social components of this
approach are in the current state not sufficient to
deal with the problems that are discussed in this
paper. Especially dealing with the questions related
to the different kinds of information, or to
conflicting norms in business practice is problematic
using the available methods of organisational
semiotics.
4 TYPES OF PROCESSES
WITHIN A COMPANY
There are a number of frequently used classifications
of processes within companies. Important is the
distinction between primary processes, control
processes, and supporting processes. The primary
processes directly concern the creation of products
for the markets, control processes concern the
planning, direct control, coordination, and
accountability of the primary processes, and the
supporting processes facilitate the first two types of
processes (and themselves).
For our purpose this classification is important,
but another classification is even more important.
Some processes have a clearly defined beginning
and ending; once they are started they go through
pre-defined stadia to reach their point of termination.
Consider for example the handling of a customer
order for standard products: from the order itself, via
order pick, dispatch, delivery, billing, and payment.
Other processes are iterative, production planning
for example. It is iterative because the same activity
is repeated on different points in time (for one
particular production week a year in advance, three
months in advance, one month in advance, the week
preceding it). Another example is the one-off sale of
capital goods through negotiations: this is very much
an iterative process. There are also processes that are
permanently active, like production monitoring; as
long as the production is active, the monitoring will
be active. Certain registration functions are of this
nature as well; think of the weighing process in a
slaughter line, or a porter or a receptionist.
Another criterion to classify processes by is the
nature of the information that is being processed. In
terms of Boisot / Van Heusden & Jorna: To what
degree is the nature of the information sensory,
codified or abstract?. One could also say: is the
information hard or soft? In the two examples
mentioned above the customer order for standard
products is very much codified, while the one-off
sale of capital has a strong sensory component (that
is the nature of negotiations: a constant gauging of
the limits of the opposing party). The discussion on
SigInt (Signal Intelligence, the automatic monitoring
of telecommunications by systems of intelligence
services) and HumInt (Human Intelligence by agents
in the field) is closely related to this classification
(Keegan, 2003, p22ff).
A fourth criterion is the degree to which
processes are determined. At first this criterion
seems to be a derivative of the preceding criteria;
terminating processes are determined to a greater
extent than iterative processes, and processes based
on hard information are determined more than
processes based on soft information. However it
essentially is a question of the responsibility for the
execution of processes: the responsibility for a
determined process can be located higher up in the
organisation, and the one executing it is responsible
for handling it in accordance with requirements. In
the case of non-determined processes the
responsibility is located more within the primary
process: decisions in the case of unforeseen
circumstances must be taken there. Particularly in
production planning determination is often assumed,
thus having the planner decide what should happen
in the production (this image strongly appeals to
hierarchical bosses). Consequence is that the
production manager executes orders without having
THE JANUS FACE OF LEAN ENTERPRISE INFORMATION SYSTEMS - An Analysis of Signs, Systems and Practices
463

the power of decision-making (which after all lies
with the planner). When practice turns out to be less
deterministic, and creativity is demanded on the
floor to deliver the products to the customers, such
an organisation will not be able to function well.
5 RELATION BETWEEN
SYSTEM AND REALITY
The relation between the computer system and
reality can be diverse. In some cases it is very clear
what the representations in the computer correspond
to in reality. In other cases this seems only to be the
case at first sight and on closer inspection it turns
out that the representations are not bounded
properly, that they overlap, that they are too rigid, et
cetera.
The relation between the computer system and
reality is not a problem when the computer system is
seen as an integral part of it. Whether it is seen
positively or negatively is of no consequence,
because the system is embedded in some artefact or
other and inseparable from it. A computer based
control system of a technical installation for
automated transport is an example of such a system,
as is the automatisation within an everyday object
like a car or a coffee maker.
The relation with reality is also not a problem
when the processes are formalised to a large extent,
as is the case with financial administration or trade.
The representations in the computer have, over the
last few decades, become normative, thus allowing
for an increasingly paperless manner of working
(electronic transactions and electronic commerce).
In most cases however the “real” processes take
place outside of the computer, and the computer
system operates based on a model of reality. In such
cases it is also possible for the user to perceive a
large discrepancy between “his” reality and what the
computer makes of it.
An example of such a choice in modelling is the
way in which railway companies model the
departure tracks on a station; nowadays that largely
happens through the departure track number, in the
past it was common to do so through the platform
number along with some additional coding (east /
west for example). The second model better fits the
traveller looking for the stairs to the correct platform
while on his way to the train, but complicates
matters on the platform itself. The first model can
cause confusion in finding the right platform (in
Koblenz track 104 is accessible from the same
platform as tracks 2 and 3).
6 SIGN SYSTEMS, PROCESSES
AND COMPUTER SYSTEMS
The above shows that the formal and closed sign
system is a good fit for a technical system, or in
cases where reality itself is “pre-formalised”. The
transition between sign systems is then smallest.
With “open” systems, based on a human practice of
everyday routines, this transition is much bigger. It
is not unusual for this to lead to the conclusion that
“the computer system does not fit”, and also that a
computer system cannot fit. In that case the
challenge is to show that it can be done, and how it
can be done, taking into account its possibilities and
restrictions.
This challenge has a variety of possible
responses; there is (of course) a category of system
fundamentalists who hold that the system should be
normative. The problem of transition is at first
denied, and once it is recognised, the burden is on
the practices to adjust themselves to the system
(which, after all, has been thought through so well
and so rationally). The computer fundamentalist is
basically a subspecies of the system fundamentalist.
At the start of the nineteenth century the German
philosopher Hegel attempted to systematise history.
Prompted with the question how he would react if
the facts did not match his theory he is supposed to
have retorted: “um so schlimmer für die Fakten”
(“too bad for the facts”).
A different response is the attempt to eliminate
the differences between modelled and actual
practices by an increasing amount of detail. The
underlying idea is that whenever a difference is
observed, that difference can be described and
analysed, before modifying the system. Of course
the system will then first be tested by means of a set
of realistic use cases. In this way the system will
always be lagging behind (there will always be new
differences to be found), but for now that is of
secondary importance. Of more importance is that
the idea of the system containing a model of actual
practices has been abandoned in this view. Consider
the idea that a map models a landscape, but a map
that contains all the details will necessarily coincide
with the landscape itself. Why do we make a map?
In other words: the computer system contains a
model of reality, it must support reality and must not
rule reality from some supposed system rationality,
ICEIS 2010 - 12th International Conference on Enterprise Information Systems
464

the model cannot coincide with reality, and the
model has its own sign system with its own
possibilities and limitations.
The difference between reality and computer
system is just as natural as the difference between
the landscape and a map. In designing a computer
system the designers have to be aware of the
possibilities and limitations of the sign system of the
computer, together with an awareness of the nature
of both the use and the users (and their sign
systems). When the user perceives the computer
system as distorting “his” reality he can either accept
it (the computer rules) or he looks for his own way
of finding solutions, independent of the computer
system. In the latter case the computer system will
have to be satisfied to allow other processes to
continue, which will run parallel with new processes
in which the actual work happens. It is the power of
human inventiveness that allows the discovery of
ever new ways to adapt the primary business
processes in response to external disturbances (like a
computer system that does not function properly).
But this also creates imaginary worlds because
elsewhere in the organisation other employees will
assume that the computer system realistically
represents the primary processes, and will thus base
their management decisions on it. Put another way, a
good manager is aware of the double difference
when looking at the numbers: (1) the difference
between his view of reality and the model in the
computer, and (2) the possible differences between
the model and the real handling of primary
processes.
7 LEAN IT (MAXIMS OF GRICE)
In 2003 a small booklet appeared, titled “IT doesn’t
matter, business processes do”. This is, as the title
indicates, a plea to consider the “business use of
technology for competitive advantage” (Smith,
2003, p25). In other words: technology can be used
as a tool to achieve a competitive advantage. Further
down their plea the authors state that “the future of
IT is about the management of the business
processes that companies use to coordinate internal
work across functional stovepipes and to collaborate,
compute and transact with customers and trading
partners with transparency and accountability”
(Smith, 2003, p58).
The transparency and accountability can only be
achieved if the IT systems are realised in such a way
that people are, and that they remain, responsible.
This in turn supposes the operation of the systems to
be understandable, based on fitting structures.
For production and other business processes
Lean Thinking offers a way to analyse processes for
their added value, based on pull principles, the
avoidance of waste of hours and material, and doing
it right on the first attempt.
Based on the same concepts Lean Information
Supply can be developed: assuming transparent
processes, with clear boundaries and clearly
assigned responsibilities it can be determined for the
different tasks of the process based on what
information the task can be executed, and what
information products must be delivered to the next
step in the primary process and to the monitoring
processes (information can of course be interpreted
in a broad sense here, not just the input and output of
computer processes). Johannes Cottyn presented on
this theme at the WBF of 2008, naming, among
others, “providing data in the wrong format in the
wrong time” and “incorrect data or too much
checking for change” as examples of waste in
information systems (Cottyn, 2008).
Fortuitously, the English ordinary language
philosopher Paul Grice has formulated four
conversational maxims which excellently state the
general requirements for an arbitrary information
system (Grice, 1989, p28):
• Maxim of Quality
o Only say what you believe to be true
o Only say what you have evidence for
• Maxim of Quantity
o Make your contribution as informative
as is required for the current purposes of
the exchange
o Do not make your contribution more
informative than is required
• Maxim of Relation
o Make your contribution relevant to the
interaction.
o Indicate any way that it is not
• Maxim of Manner
o Avoid unnecessary prolixity
o Avoid ambiguity
o Be brief
o Be orderly
In other words: information should be brief,
correct, relevant, understandable and reliable. It is
self-evident that the meeting of these requirements is
a condition for avoiding waste in the use of
information; for one thing because the user needs
extra time to interpret and verify the information
offered, for another because the user opts for
incorrect actions because of incompetently supplied
THE JANUS FACE OF LEAN ENTERPRISE INFORMATION SYSTEMS - An Analysis of Signs, Systems and Practices
465

information. The pull principle also ensures that
only information which is actually in demand will be
produced (and in the required form), and that in the
design of the information system the legitimacy of
the demand can be verified in advance (does the user
indeed require the information demanded in his tasks
and responsibilities?).
Finally, the resulting comprehensive Enterprise
Information System should recognise and support
the distinctive capabilities of the company, as
analysed by John Kay (Kay, 1993).
8 CASE 1: TRADING
A company is involved in the international trade of
large quantities of raw materials for livestock feeds.
One part of the activities is handling already closed
deals, one part of the activities is the trading itself
where buying and selling happen simultaneously,
and a part of the activities consists of buying and
selling independently of each other.
All activities are related to the handling of sales
contracts, buying contracts, and services in the
physical flow of products (transportation, customs,
transshipment, and storage). In other words: all
activities could be represented in the information
system within the usual functionalities for buying,
selling, et cetera. Moreover, because of legal and
administrative aspects the usual contracts have to be
represented. Buying, supply, control and acceptance
(transfer of ownership), and so on, those aspects are
all present.
At the same time it affects very different kinds of
trade, which each have their own way of control and
assessment. The common element is that all kinds of
trade are tracked by means of calculation. This
calculation is made known at the conclusion of a
deal, and checked during the handling of it. When
buying and selling are executed independently, the
usual “one-sided” calculation for buying and selling
will do. During the real trading however the trade
itself is what it is about, where buying and selling
are involved simultaneously. When deviating from
the most simple form of trade (for every purchase
there is exactly one sale), the trader will
continuously keep an evaluation of the market in
mind. He will buy long or sell short when he expects
to be able to sell the quantity bought for the right
price in an acceptable period of time or when he
expects to be able to buy the sold amount for the
right price.
How is the information system in such a
company designed for the traders and their
management, and how is the trade represented in the
computer system? It is clear that the supplier
contracts for the supply of goods and services and
the customer contracts for their supply of goods and
services must be represented according to the usual
rules. The challenge is in representing the trade; it is
impossible to represent the trade in the way it
happens in the mind of the trader. But because of
monitoring and accountability the right buys and
sales must be connected with each other, including
additional costs for services by third parties. The
information system must also enable both the trader
and the management to closely monitor and assess
events, in order to be able to act quickly when
necessary.
9 CASE 2: PRODUCTION
CONTROL
A company produces a large range of salads in
consumer packaging. The salads have a shelf life of
a couple of weeks, the standard for the amount of
time a finished product stays in storage is one week
or shorter. Sales are relatively variable and for some
of the products they are strongly dependent on the
weather and on advertising activities by the retailers.
The steps in the process are (from the finished
product backwards): filling/packaging/labelling;
mixing of intermediate products; preparation of
intermediate products; preparation of raw materials.
The production lead time is several days. There are
about 6 filling lines, 8 mixers, and there is a large
number of specific activities on specific intermediate
products and raw materials.
The control of the filling lines of the production
itself is a different story. The recipes are sometimes
dependent on the season and sometimes on the
individual batch of raw materials. The variation of
activities in a relatively small area is very large. The
filling plans are adjusted several times a week
because of unforeseen developments in the sales,
and sometimes because of internal malfunctions.
How should the information system for the
production of such a company be designed, such that
the information system is still well operable for the
users (maxims of Grice), while the costs for setting
up and using the system are not exorbitantly high?
The modelling of all activities is much too
complicated. Registration of production and stocks
for each step in the process comes with too high a
ICEIS 2010 - 12th International Conference on Enterprise Information Systems
466

price. Yet the responsible production managers need
to be supplied with the information needed to do
their job properly, and changes in the filling plans
have to be adequately dealt with. This can only be
achieved by a good combination of a simple model
of production and a well thought through
information system on the production floor itself.
10 ANALYSIS OF CASES
In the earlier reflections three interrelated basic
elements have been addressed: Enterprise
Information System both in a broad and in a narrow
sense, the nature of processes and sign systems, and
Lean IT. Both cases present some interesting
examples of the importance of these elements in
practice. Both cases deal with a mixture of
structured processing of encoded information (the
handling of contracts in trading, finished product
planning in production) paired with essential
uncoded information within the primary processes.
In designing a comprehensive Enterprise
Information System (in a broad sense) a number of
key questions have to be answered, including the
essential issue of bounding the role of the computer
system in the whole. Subsequently it is the question
how processes must be represented in the computer
system.
In the first case it is clear that at least the
handling of contracts will be part of the computer
system. We have noted already that, with respect to
the sign system, there is a large discrepancy between
the actual trading process and how computer
systems function. The question is what role the
computer system must be assigned for supporting
the trade itself. From the point of view of business
processes there are three main areas besides the
formal handling of contracts: (1) the monitoring of
the physical flow of goods; (2) the monitoring of
long and short positions; and (3) the monitoring of
trade calculations. The artefacts used in modelling
these areas (in conjunction with each other) will
have to be carefully construed; they are not pre-
determined in reality. The concepts of “trade”,
“item”, and “batch” must be defined in such a way
that they, while guaranteeing their recognisability
for the traders, can support the clear and simple
modelling of business processes in the computer
system. And through these concepts the connection
with the information system in a broad sense (such
as by telephone, mail, Excel) must also be
guaranteed.
In the second case other challenges are present.
The classical approach would lead to a detailed
production model, with labour intensive and not
very reliable product registrations. In practice this
will often lead to eroding the position of the
production manager as well, because the planner
seems to be controlling the production directly: each
change has consequences for the plans (because of
the high level of detail) and should thus be decided
by the planner. And if the production manager keeps
making his own decisions within his own world
(forced to do so, the customers must get their
products in time after all), that leads to the planning
being a farce. The basic principle of the division of
tasks between general and more detailed decisions
has, back in 1965, been well described by Robert
Anthony: “...the middle managers can in fact make
better decisions under certain circumstances; to deny
this possibility is implicitly to assume that top
management is either clairvoyant, or omniscient, or
both, which is not so” (Anthony, 1965).
Unfortunately computer systems help sustain the
illusion that the planner is “clairvoyant” and
“omniscient”, which can be detrimental to the results
of the company.
The information system (in a broad sense) must
be based on: (1) clearly distinct responsibilities for
planning and production management, and (2) a
clear distinction between the sign systems of
planning and production. This should lead to a
solution in which the planning model is coupled
“loosely” with production. The production manager
has his own information system in his own area, in
which the central computer system plays an
essential, but limited, part. The central computer
system is essential for the current filling plans and
feedback from production about the use of raw
materials and output of finished products. Within the
production itself the central computer system has a
minor role. The information system within the
department matches the physical circumstances and
the manner of working. Quantities are often
indicative and not exact. Regarding traceability strict
rules apply, which fit the nature of the process
without involving too many registrations.
11 PHASES IN SYSTEM
DEVELOPMENT
In designing an information system along the lines
described above four main phases can be
distinguished:
THE JANUS FACE OF LEAN ENTERPRISE INFORMATION SYSTEMS - An Analysis of Signs, Systems and Practices
467

• Description of customer processes in
“customer language”
• Analysis and definition of the underlying
process logic
• Design of the information architecture
• Representation of the underlying process
logic in the software
• Setting up the system in a broad sense
o Making agreements with respect to the
set-up and procedures detailed and
particular
o Making tasks and responsibilities of the
employees in the information supply
detailed and particular
o Setting up the computer system with
terminology, screens and workflows
based on the represented process logic
and the specific form of customer
processes
In the first phase the processes of the customer
are described in a way recognisable for the
customer, in his own language. Here it is mainly
about mapping the different sub processes with tasks
and responsibilities and information flows, and the
nature of the information flows.
In the second phase “customer independent”
process logic is mapped. In each industry patterns
can be distinguished, which are determined by the
nature of the industry and by the markets and
products of this specific company. Sales and
logistics of daily fresh products have a number of
process characteristics, which will necessarily be
found in each company in this industry, and
depending on the location and specific raw material
and product markets a company can also have its
own characteristics. The three central questions in
this part are: (1) what should be controlled? (2) what
must be known? and (3) what information can be
made available? The first question deals with
process control, the second with accountability for
both internal and external stakeholders (e.g. taxation,
product safety), and the third question deals with the
non-trivial but often neglected question what
information about business processes can be
determined in a reliable and cost-effective way. In
other words: what are the value-adding information
processes?
In the third phase the information architecture is
designed, in accordance with the existing process
architecture and the formal organisation (sometimes
the process architecture and the formal organisation
will be taken as fixed, sometimes they might be
adapted). For each process it is determined what
information is required to fulfil the tasks in the
process, what the information output of the process
will be, and what kinds of information are involved.
In this way the information flows between business
processes are determined. Subsequently it can be
determined what information tasks will be fulfilled
in what way: what computer systems are used, what
the required interactions between humans are, and
what the human responsibilities are.
In the fourth phase it is determined how the
process logic should be represented in the software.
Here the possibilities of the software package are of
course decisive to some extent. Because it is the
underlying process logic that is being represented,
this representation should be relatively stable.
In the last phase the information system in a
broad sense is set up for operational use. Based on
the underlying process architecture and on the
representation of the process logic in the software
the particular tasks within the information system
are further specified and assigned to the responsible
employees and the computer systems. Special
attention should be paid to the information flows
between the main components and assuring the
correctness, timeliness and completeness of the
information to be supplied (see also the remark
above on the importance of the organisation). The
computer systems involved are set up for the user;
by means of terminology, setting up the screens, and
workflows the software package is made specific for
the customer.
In designing the information architecture and
setting up the information system for operational use
the guidelines of Lean IT and the maxims of Grice
are followed throughout. The information supply is
analysed from the need in the processes. If this need
is unclear then that is analysed first. The fixing of
data which is not made use of in a defined and
legitimate way is not allowed. The information is
brief and understandable for the user; his work will
not unnecessarily be burdened by the use of systems
and forms.
By separating the “process logic” in the second
step and the business processes in the subsequent
steps it should lead to multiple advantages. It helps
the supplier to stabilise the branch-specific software
solution by identifying the customer-specific
features apart from the customer-independent
process-logic. It helps the customer by providing a
real Enterprise Information System where all factors
are analysed in context, and where the computer
system is considered a pragmatic tool and nothing
more.
ICEIS 2010 - 12th International Conference on Enterprise Information Systems
468

12 CONCLUSIONS
The question central to this paper is how the
implementation of standard solutions in a company
should be prepared to make successful operational
use possible. The answer can be formulated in a
short and simple way: by taking the user seriously
(do not bother him unnecessarily, and supply him
with what he needs to do his job), by taking the sign
systems involved seriously (which information can
be codified); and especially: by taking the transitions
between sign systems seriously (in what way are
processes modelled and what are the rules for the
use of these models).
Bringing these answers in practice however, is
considerably more difficult. The practices and sign
systems within a company are often very hard to
track down. Asking the users is of limited value.
Formulating the process logic in the business
processes results in better entry points, especially for
a supplier of standard solutions in an industry; as an
industry specialist it is well acquainted with the
processes and developments within the industry, and
through projection of the industry specific process
logic it can track down the specific characteristics
and peculiarities of the company involved.
The realisation that an information system
concerns the whole of the structured information
supply, including all organisational responsibilities
and practical rules and conventions, should prevent
the designing of a paper solution that cannot
function in practice. For an important part it can be
tested through Use Cases whether the solution
thought up holds in practice, and where any
additional conventions are needed to warrant the
proper functioning. Guidance can be found in the
concept of Lean IT. By analysing the value of
information in the business processes, and by
avoiding waste both as a consequence of
overproduction of information and as a consequence
of a lack of reliable information in the right form, in
the right time and at the right place, our Enterprise
Information Systems will be improved.
Finally: the issues discussed here are part of
Information Science, a field that deserves its place
alongside Computer Science.
REFERENCES
Kay, J., Foundations of Corporate Success, Oxford
University Press, 1993
Saussure, F. de, Course in General Linguistics, McGraw-
Hill, 1966
Ruthrof, H., Pandora and Occam, Indiana University
Press, 1992
Searle, J.R.., Speech Acts, Cambridge University Press,
1969
Boisot, M., Knowledge Assets, Oxford University Press,
1998
Van Heusden, B., Jorna, R., Toward a semiotic theory of
cognitive dynamics in organisations. In: Information,
Organisation and Technology, Kluwer Academic
Publishers, 2001
Liu, K., Semiotics in Information Systems Engineering,
Cambridge University Press, 2000
Gibson, J.J., The Ecological Approach to Visual
Perception, Lawrence Erlbaum Associates, 1986
Keegan, J., Intelligence in War, Alfred A. Knopf, 2003
Smith, H., Fingar, P., IT Doesn’t Matter – Business
Processes Do, Meghan-Kiffer Press, 2003
Cottyn, J., Stockman, K., Van Landeghem, H., The
Complementarity of Lean Thinking and the ISA95
Standard, Paper presented at the WBF European
Conference in Barcelona, Spain, 10-12 November
2008
Grice, P., Studies in the way of words, Harvard University
Press, 1989 (originally: Logic and Conversation,
1967)
Anthony, R., Planning and Control Systems, A
Framework for Analysis, Division of Research,
Harvard Business School, 1965
THE JANUS FACE OF LEAN ENTERPRISE INFORMATION SYSTEMS - An Analysis of Signs, Systems and Practices
469