30 Years of Consulting and Developing for Food Processing

Coen Suurmond

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

csuurmond@rbk.nl

Keywords: Business Processes, Business Practices, Information Systems.

Abstract: The paper gives an overview of the company I have been working at and the practical work I have been doing

for some 30 years, as well as the impact of the practical work on my theoretical positions. The company is

rather exceptional in its application of a broad scope of knowledge areas in a specialised market. At RBK we

both design production facilities & technical installations, and develop and implement information systems

for the food processing industry. Short descriptions illustrate some characteristics of our projects and systems,

the problems we attacked and the solutions we found. The impact of the practical experiences on my

theoretical insights is discussed in the last part.

1 INTRODUCTION

For the past thirty years I have been working at the

RBK Group in Deventer in the development of

information systems for the food industry. I have

combined my work as a practitioner with research

into the functioning of information systems in

enterprises. In this paper I will give an overview of

my experiences in practice through the years and

what its influence has been on my theoretical insights.

The always recurring confrontation with the physical

reality of the shop floor and the wide range of

perspectives (from process technology, technical

processes, management sciences and information

technology) have always provided a rich feeding

ground to experience how people handle information

in business processes. The cooperation with all kinds

of departments at our customers (production, quality

control, commerce, logistics and controlling) has also

been an ongoing exercise in doing justice to various

interpretations of ‘the same reality’, and an ongoing

warning against reducing reality to a single

perspective.

Below I will first provide a brief overview of the

history of the company and the main characteristics

of our customers and their products. This is followed

by paragraphs exemplifying characteristics of our

projects and systems over time. It will be concluded

by an overview of how these projects and systems

have contributed to a number of specific theoretical

insights.

2 THE COMPANY AND ITS

CUSTOMERS

2.1 Hans Kortenbach and RBK

The company RBK (“Raadgevend Bureau

Kortenbach” = Kortenbach Consultancy) was

founded in 1979 by Hans Kortenbach, a visionary and

driven man. Kortenbach started out young as a

refrigeration technician in the middle of the 1950s.

About ten years later his employer tasked him with

setting up a site in Emmeloord, which led to intensive

contacts with fish processing companies in the pre-

eminent and innovative fishing port of Urk. Here,

Kortenbach gained management experience, both as

director of the site and with the ways the customers

conducted their business. In the second half of the

1970s this led to a management function in a meat

processing company.

However, managing a production company is

very different from the project-dominated

environment of an installation company. Kortenbach

decided in 1979 to set himself up as an independent

139

Suurmond C.

30 Years of Consulting and Developing for Food Processing.

DOI: 10.5220/0005886301390146

In Proceedings of the Fifth International Symposium on Business Modeling and Software Design (BMSD 2015), pages 139-146

ISBN: 978-989-758-111-3

consultant to apply his technical expertise, process

knowledge and business knowledge to the fish and

meat processing industries. The next year he hired an

electro-technical engineer, because he saw

opportunities in linking (semi-)electronic scales to

computers (we are talking about a time in which

Kraftwerk used a synthesizer and a soldering iron).

The inventiveness and the results achieved by the new

employee led to a long cooperation with the then pre-

eminent supplier of scales in The Netherlands for the

development of weighing/registration systems.

The 35-year history of RBK essentially shows the

expansion of the knowledge areas mentioned above

for food processing companies and for cold stores.

Part of our company is about consultancy and design,

part is about providing information systems for its

business processes. Throughout these years we have

wanted to contribute through our practice-oriented

approach based on the integration of very different

knowledge areas. We are specialised in terms of our

market, but we are very broadly oriented in terms of

our disciplines. The [added] value of our approach is

illustrated by our approach to building and

construction. New development projects tend to start

with the architect and the general design of the

building. However, at RBK we start with the design

of the primary processes and their required large

technical facilities (of which the refrigeration system

in terms of complexity, of investment and of weight

is often the main one) and then our building engineers

‘construct a building around it’ (and our architects

ensure that it will be a nice-looking and well-designed

building).

2.2 IT Systems in the Early Years

From the first years our computers would be

connected to the outside world with peripheral

devices (especially: electronic weighing scales), with

product detectors, and with transport systems.

Besides regular parallel and serial interfaces we had

to find solutions for dealing with digital inputs and

outputs. That is why we started with the ITT3030

microcomputer with a 4MHz Z80A processor, 16KB

internal memory, two 560KB floppy disks for ‘mass

storage’ and transferring data; operating system

CP/M and BASIC as programming language. The

modular architecture of the ITT3030 provided a good

basis for connecting peripheral devices. An example

from this period was a weighing system that could be

wireless controlled by the driver on a forklift (this was

in 1983).

From 1985 we used the IBM compatible PCs with

MsDos as operating system and Pascal as

programming language. For digital inputs and outputs

these computers were much less suitable than the

ITT3030, but we created our own solution via relay

boxes (controlled via the parallel port) and via

creative use of the control lines of the serial

interfaces. From 1989 the system landscape for our

shop floor control systems consisted typically of a

Novell file server, a number of PCs connected in a

local area network, and an AS/400 based system for

purchasing, ordering and invoicing software (in 1989

we incorporated a software company with AS/400

software).

For process control we have used single-board

computers in combination with in-house developed

PCBs for about ten years starting from 1983. The

single-board computers where initially bought from a

supplier until a creative genius designed and built a

single-board computer for us in 1987. A compiler

compatible with Borland Pascal was also developed

for this single-board computer. This had the large

advantage of being able to perform a large part of

software development and testing in a regular PC

environment. The last of these systems still run at our

customers today. However, this development for this

system was discontinued in the early 90’s in favour of

the application of industrial standard equipment for

process control (PLCs). Now we use a very small

model PLC controlled over Ethernet for controlling

small scale digital inputs and outputs connected to our

shop floor systems.

In a nutshell: from the beginning we have always

been dealing with the connections to the physical

world. In early times we had to create our own arts-

and-crafts solutions, and later on we moved to the

application of industrial standards.

2.3 Our Customers

The customers of RBK are chiefly production

companies of fresh and perishable meat and fish

products and cold stores for logistic services. The

variability of the raw materials is an important

property, at the same time the customers ask for

standardised finished product with consistent

characteristics. Both on the supply side and on the

distribution side the typical lead times are one or two

days. Due to these characteristics and due to often

volatile demand, production schedules are often

revised.

It has always been demanded of suppliers of fresh

food products to deliver daily for a sometimes

strongly varying demand. The phenomenon

backorder is not applicable; a shortage one day cannot

be compensated for by an extra delivery on the next.

At a number of our customers the full supply of raw

materials is processed to end products and delivered

to their customers within 36 hours after arrival (at a

Fifth International Symposium on Business Modeling and Software Design

140

daily capacity of 600 tonnes of raw materials, against

‘just’ 200 tonnes 25 years ago).

In general our customers have a flat organisation

with a small number of experienced practitioners in

key positions. This is necessary because of the

complexity of the processes, because of the short lead

times and because of the uncertainties both in the

supply of raw materials and in the demand for

finished products. Through the years the

organisations have become larger and more formal,

with a larger intake of higher and more broadly

educated people.

2.4 Registration on the Shop Floor

The basic principle for the registration system and the

databases it feeds has always been that it must be

possible to register what actually happened,

regardless of planning or norms. Of course systems

must warn in case of deviations, but if an authority

indicates that it should still happen then it must be

registered. This is also the only reliable basis for

traceability, a theme that has become increasingly

dominant over the last few years.

From the early years our systems have had a real-

time nature in two different senses. Firstly, the

systems provide a view into the progress and actual

yields in the production at any time, the essential

basis for monitoring and adjusting production.

Secondly, our systems are partly synchronised with

events in the production lines and transport systems.

‘Real time’ in the first sense requires a typical cycle

time of about one to five minutes, ‘real time’ in the

second sense requires a typical cycle time of 0,2 – 1,5

sec. The interval between two consecutive

registrations can be 5 seconds or less.

3 PROJECTS THROUGH THE

YEARS

3.1 1980 – 1990: Realisation of the

Vision of Hans Kortenbach

In the first decade of RBK’s existence there were two

kinds of projects. Through the collaboration with a

weighing scales supplier came orders for weighing

registration systems for production companies, and

later also for weighbridges. In short these were orders

according to the specification of a customer,

variations on a theme. The second stream of projects

resulted from the innovative work of Kortenbach in

the design of companies along with their technical

installations. In Kortenbach’s vision large gains could

be made by breaking through the traditional approach

of fragmentary design per installation part. In the

project of a factory for the production of dry sausages

this approach was expressed in the design of the

maturing and drying processes in climate chambers.

Instead of a system with a closed air treatment unit

for regulating temperature and humidity a system was

used here that mixed in outside air, significantly

reducing energy expenses. The control system is here

tasked with regulating the intake of outside air based

on the conditions in the climate chamber and the

temperature and humidity of the outside air. Another

aim of Kortenbach at the realisation of the new

factory was the centralisation of all process

installations (a number of cooking/smoking

chambers, a number of climate chambers for

maturing/drying, eight different process installations

in total) to allow control and monitoring from a single

point.

This vision was realised using a Compaq 286 PC

(placed in a technical area) combined with a single-

board computer for I/O processing (in-house

developed) and a screen with a 4x4 keyboard in the

(wet) production environment for control and

monitoring of the processes. In our Borland

development environment we made use of in-house

developed multitasking on the application level:

within a single application a number of different

autonomous processes could be maintained in real-

time (with a cycle time of at most 1 or 2 seconds). A

conventional DOS-application waits for user input or

it may be busy for an extended amount of time

executing a procedure. In our DOS-applications the

program never waits for anything, but is always

cycling through a number of processes in an infinite

loop which may or may not have events to be handled.

A number of these applications are still in operation

at our customers today, sometimes with more than 25

years of service.

A special challenge in this project was the user

interface in the production area. How do you provide

the user with insight into the current state of affairs in

eight process installations (temperature, humidity,

processing step, possible alerts) on a screen of 25

lines of 80 characters with a single glance and how do

you organise the control of these installations on a

keyboard of 4x4 keys? These limitations led to two

views; one with an overview of all process

installations with process parameters and the primary

controls (starting/stopping a process, selection of

process recipe in the foreground and a second view

with the process data of the technical installations in

the background. Everything was solved neatly in a

controllable and clear system. I only realised the

specialness of this approach years later when I visited

another factory of sausages and I saw a tangled mess

30 Years of Consulting and Developing for Food Processing

141

of local control panels and dial controls for all kinds

of settings!

For the execution of the control system the

customer was involved at only two points: before the

start, when Hans Kortenbach had to persuade the

customer of the value and feasibility of this approach,

and nearly at the end to explain and check the control

functions. Everything in between consisted of

realising the views of Kortenbach based on: (1) the

analysis of both the processes in the product itself

(drying, maturing, cooking, smoking), (2) the

analysis of the physical principles of climate control

and of the relationships between pressure,

temperature and humidity, (3) the analysis of the

technical processes of the different components of the

process installations, and (4) the mutual relationships

between product, process installation and physical

principles. For the development of the application

with all process controls it was necessary to gain a lot

of knowledge of the underlying principles (primarily

based on the knowledge of Hans Kortenbach,

supplemented by literature about the different

subjects), and very little was written down (which

was uncommon with automation projects within RBK

at any rate).

3.2 1989 – 1995 Foundation for Shop

Floor Control Systems

In early 1989 we realised our first weighing systems

for shipping fresh meat. The first system with one

weighing station in April, the second system with

three independent weighing stations in a few months

later, and the third system as a network solution at the

end of that year. Each of these systems were

connected via data transfer to a sales / invoicing

system written in RPG on the IBM AS/400 platform.

These systems were the start of a long and successful

development with several offshoots. The variety of

the offshoots eventually also led to major problems in

the maintenance of the software, hurting both the

customer (unexpected surprises with new versions)

and for us as its supplier (more and more effort spent

in maintenance, at the cost of new developments).

The first weighing systems for shipping were

quickly followed by a variant system for the

registration of production data and the calculation of

deboning yields. This added an entirely new

dimension to the package and to our expertise.

Registration of shipping weights is relatively

straightforward (registering the weights as basis for

invoicing the customer), although the circumstances

are rather special (time pressure, cold and wet

environment, ensuring that everything is weighed

exactly once). At the weighing for production the

main process is also straightforward: weighing

incoming and outgoing streams per production order,

but there are a lot more dimensions than just the

weights. Product coding and product recognition is an

important issue, as well as quality control. An

example is registering a product with some quality

defect, no longer suitable for the continuation in the

main process. For the evaluation of the production

yields this product has to count as the main product

that it should be, for the financial result it has to be

valued at a reduced rate. Different stakeholders such

as production management, external deboning crews

(working at piece-rate), quality control, sales, and

controllers may have very different views on the same

products and the same calculations.

The development of this calculation system was

accepted against a fixed-price (which was certainly

not on the high side) but had eventually a turn-around

time of over one year, due to all the additional aspects.

The results of this system for the customer were good

at first and eventually they became very good. The

company was able to achieve significant

improvements in process efficiency and product

quality because the system gave detailed insight into

the production results and into deviations from

production norms. In this development I personally

spend a lot of time near the production and with the

production people, and I gained a lot of experience

with the ins and outs of production itself, production

registration and production accounting. The recurring

themes in this process were: (1) how do the different

departments of the production company look at the

information and what do they do with it? (2) how do

we achieve a reliable registration in such a production

environment? (3) how can we explain the system to

the weighers on the shop floor and to the users in the

offices? In this project we had to learn the hard way

how to deal with the physical production reality, the

no-nonsense approach of dedicated production

people and the multiformity of reality observed from

different perspectives. As a ‘by-product’ we learned

to act as a kind of intermediary between different

stakeholders at our customers.

This lengthy project taught me something

essential: the importance of a few people at key

positions and the importance of an organisation that

asks questions in the use of an information system.

The physical position of the main user at the entrance

of the production area was pivotal. He was in a

position to have a good overview of the area with its

various production lines, he could monitor the supply

and availability of raw materials behind him, and he

had an overview of the actual production yields in in

real time on his screen and in case of deviations he

could immediately enquire after them. On top of this

he had the experience and knowledge to judge

situations and he was an important information

channel from production management to the shop

Fifth International Symposium on Business Modeling and Software Design

142

floor. All of this was not based on some formal

structure, but rather on a well-oiled organisation with

a natural distribution of roles.

The large value of this was not immediately clear

to me, but became clear years later when I saw how

our system functioned a lot worse at other sites of the

same company with identical production processes.

This difference was mainly due to the quality of the

local organisation, in which our system was just used

as a machine to perform some specific task. When an

information system is not used to evaluate situations

and to ask questions, then it quickly degenerates to

just an expense. On this second site office workers

checked production yields once a week, while at the

first site the yield of each and every production order

was checked immediately upon completion of the

order. The difference: a lot of money won or lost

because of production yields.

3.3 2000 – 2010 Years of Renewal

During the period 1995-2010 the systems whose

initial developments were described above were

expanded upon, and a number of times they were

drastically technically revised (e.g. the transition

from DOS to Windows, a transition that will not be

discussed further here).

For the process controls of refrigeration

equipment there was an essential shift of emphasis

from technical perfectionism towards orienting on the

interests of all stakeholders. A quality inspector wants

to see whether the temperatures remained within the

agreed upon specifications, a general manager wants

to see what his energy consumption has been, the

technical service wants to quickly see what is going

on in case of malfunctions, the same goes for the

refrigeration technician, and our own consultants

want to see how well the installation performs as a

whole and where the settings may possibly be

improved. This shift of focus at the same time

reduced the complexity of our control systems and

improved the performance for the stakeholders. An

interesting instrument for the technical stakeholders

is the so-called video recorder, which allows

processes from the past to be viewed along with all

logged process parameters and control actions.

Because in case of trouble shooting ‘looking’ is often

a much cheaper and a more efficient process than

‘thinking’, this is a highly valuable instrument for the

technicians. This shift from complexity and

perfectionism towards intelligibility and visibility of

the behaviour of our control systems had much to do

with internal personnel changes within RBK, where

one of our refrigeration consultants was placed in

charge of the software development for our process

control systems.

For the weighing/registration systems there also

was an essential change in how our systems were

oriented (coinciding with the change from DOS to

Windows). Traditionally our systems were based on

production orders with input of raw materials or semi-

finished products and output of (semi-)finished

products. A conventional approach to stocks would

mean that stocks are consumed on input to a process;

and that stocks are created on output from a process.

The disadvantage of the conventional approach,

however, is that between input and output the goods

are “absent”. Moreover, the modelling of some curing

processes that last for days or weeks can be a burden.

In these cases, the product is transformed (so it is an

order) and the product is in storage (so it is a stock).

As we are opposed to unwarranted reduction of

reality, and we did not want to choose between

production order and stock, we decided to have it both

ways. Our new system was designed in such a way

that everything can be considered as stock, all

transactions are modelled as stock movements.

Production orders are just a way of registration of

inputs to a process stock and outputs from a process

stock.

As a bonus, this approach also provided a neat

foundation for another difficult issue: how to deal

with the concept of “lot”. Lot management is an

essential part of tracking and tracing. The problem,

however, is that different stakeholders tend to have

different ideas about what defines a lot. This is

consistent with the OED definition of a “lot”: “A

number of persons or things of the same kind, or

associated in some way; a quantity or collection (of

things); a party, set, or ‘crew’ (of persons); also, a

quantity (of anything)”. This is a good definition and

explains the multiformity of reality: different

stakeholders will have different views on what

qualifies as a lot. In our new system we dealt with this

problem by using a system-defined concept of base-

lot, and by having provisions for all kinds of external

lot designations as extra references. Keep the internal

world of your system consistent, and allow for

multiformity of the external world(s)!

3.4 2010 – 2015 Architecture and

Integration

Some years ago the need arose to modernise a third

group of systems at our customers. We have had

registration systems for individual products in a line

process and control systems for internal transport of

products for over 25 years at RBK. These systems had

been the almost exclusive area of expertise of a single

employee during this time. This held true both with

regard to his process knowledge (what happens on the

line?), to his mechanical-technical knowledge (how

30 Years of Consulting and Developing for Food Processing

143

do the transport systems behave?), and also to his

software and his IT toolbox for dealing with the real-

time aspects, for handling the inputs and outputs, for

data management, for visualisation, and for all kinds

of communication with peripheral equipment and

with other systems. Over the years, this employee has

been assigned to different departments in our RBK

organisation. In each department, however, the

differences with its main activities were so great that

in practice the development and support of these

systems has effectively been a one-man department

within RBK for 25 years.

As regards the contents of this kind of systems, an

important issue is that across customers the same

terms can have different meanings (homonyms), that

the same thing can be referred to by different terms

(synonyms), that this terminological ambiguity also

regularly exists across departments within a single

customer organisation. This phenomenon does not

contribute to the entrance of newcomers to the field,

and makes the transfer of knowledge difficult.

A further challenge in these kinds of systems is

the coexistence of multiple methods to identify one

individual product (tracking number from the

supplier, tracking number from the process, RFID in

the product carrier, RFID in the product itself), and

that none of these methods is completely reliable in

practice. The system has to be able to handle the

various identifications concurrently and to use

different identifications as a reference in the

communication with other systems, also when

identification may be missing or when some

identification numbers are not unique. Incidentally,

this problem of multiple and not fully reliable

references is becoming an increasingly big problem

in the external and internal supply chain. The supply

chain seems increasingly to be a kind of dumping

ground for uncoordinated identification systems of all

kinds of partners in the chain.

We thus had a system issue to solve (a

heterogeneous system landscape with our system

containing elements of process control combined

with elements from production systems, and to be

integrated to several third party systems), a pre-

existing issue to allow the employees of our various

department to cooperate in a meaningful way, and,

especially, to enlarge the group of people that could

contribute to the development and maintenance of

this kind of systems. Last but not least: RBK had to

be able to apply the same standardised system to other

customers with different configurations and

terminology.

We found our solution for the system architecture

and information architecture by an essential

separation between the following system

components: (1) a component for tracking the product

during transport (‘tracking system’), (2) a component

for recording data of the individual product (‘data

system’), (3) a component to relate the physical and

data system (‘synchronisation system’), and (4)

configurable control terminals for registrations in the

production line. The tracking system is the first to

detect the individual product, assigns to it a unique

system token, and tracks this token throughout all

transport movements. The terminals of the data

system are configured to record certain characteristics

with the individual product at their position on the

line. The synchronisation system ensures that the

characteristics are recorded with the correct

individual and that actions on the individual are

triggered at the right time. The work stations are

configurable thin clients in the production line with a

number of buttons on the touchscreen to record

characteristics and a mechanism to show the

movement of the product during registration. The

work stations are connected to the synchronisation

system. The individual system components would be

developed by different software groups (the tracking

system by process control group, and the data

components and user interfaces by the shop floor

group, and the synchronisation system with its

messaging as a joint effort).

With this set-up we can fully meet the system

requirements. Through the use of a unique system-

generated token for identification we have

disconnected ourselves from the dependence on

existing external identifications and we are free to

extend this for future identification methods. The

physical tracking of the individual product is

independent of the registration and management of

the characteristics of the individual product. Because

of the configurability of the terminals the terminology

can be independent of the meaning of the data (which

also forms a risk!). By the application of services in

the data system a response time of at most 200 ms can

be guaranteed in internal messaging. By using a

monitoring tool for the messaging traffic (current

traffic and traffic history) the system behaviour can

be analysed both by the employees of the customer as

by the employees of RBK.

To solve the organisational issue of “dividing

labor and achieving coordination among them” (the

terminology of Mintzberg) one aspect was crucial:

mutual understanding and mutual trust as the

foundation for mutual adjustment. Our past had

taught us that a lack of cooperation often was due to

a sense of ownership and responsibility of individual

developers, and as a consequence a strong striving for

independency. Someone wants to be able to solve

problems in ‘his’ system and he does not want to

depend on things of which he does not have a good

grasp. This is exactly where the problem lies between

different departments: they represent separate

knowledge domains that do not sufficiently

Fifth International Symposium on Business Modeling and Software Design

144

understand one another. This problem cannot be

solved by integrating everything. This problem can

however be solved by (1) clearly delineating the

systems and responsibilities, (2) giving all parties

sufficient overview of the system as a whole and the

interactions between the components, and (3) giving

all parties sufficient confidence that everything will

work in practice even though there is no single person

with an in-depth knowledge of all the details.

The preparation together with the customer was

part of the process of building trust. This was a taxing

process with an exhaustive analysis from all the

information products (interfaces, screens, control

actions, reports) back to the origin of the data and

especially to the internal encodings of our subsystems

that were to be created. After this analysis we had the

system fully specified and testable on paper; and we

were able to answer all questions from the

practitioners at the customer and from within RBK.

N.b.: a happy circumstance for this kind of system is

that full analysis was indeed feasible, which is

normally not the case.

A second part in the building of trust was an

extended period of testing in the office, followed by a

period of five weeks of pilot running in the actual

production line along the operational system. During

the pilot running, differences between the existing

and the new system were subject to daily analysis.

Eventually, the new system was put into operation a

few days before the scheduled date, and needed very

little aftercare.

4 THEORY & PRACTICE

The question how systems function has always

interested me. For organisations, the assumption

during my studies and the first years afterwards was

that organisation theory should be the entry point to

understand its inner workings. A definition like

“organizations are (1) social entities that (2) are goal

directed, (3) are designed as deliberately structured

and coordinated activity systems, and (4) are linked

to the external environment” (Daft, 2001) supports

this assumption. However, I was unable to reconcile

this theory with my practical observations in a

satisfactory manner. The organisation of quite a few

of our most successful customers are characterised by

a flat, informal organisation, much more evolved over

time than designed. Mintzberg’s work The

Structuring of Organizations” (Mintzberg, 1979) shed

some more light on the understanding of real-world

organisations (“the structure of an organization can be

defined simply as the sum total of the ways it divides

its labor into distinct tasks and then achieves

coordination among them”). In comparison to the

definition of Daft this definition leaves out the

‘design’ element; and it leaves much more room for

developing patterns of specialisation and

coordination.

The major shift came with the insight that the

approach should be reversed. Instead of starting an

analysis with the organisation of an enterprise, using

the organisation as a basis to look at the business

processes and finally looking at the environment, I

had to start off with the environment. The rationale of

an enterprise is after all the successful production and

selling of products on its markets. Does it fail to do

so, then the enterprise ceases to exist. This is why the

analysis of an enterprise ought to start with its

markets and products. The business processes then

represent the actual behaviour of the enterprise in

which the products are marketed and produced.

Finally, the formal and informal organisation serves

to stabilise the business processes in order to warrant

the effectiveness and efficiency in the short term and

the continuity in the long term. This last approach

also combines much more easily with the mixture of

societal norms and the informal development of

patterns that characterises the social world. This

reversed approach is warranted in various ways by

economists like Coase (Coase, 1937), Kay (Kay,

1993), and De Geus (De Geus, 1997).

For the approach of enterprise information

systems I needed a similar break with conventional

modes of thought. No longer do I consider the

computer-based information system as the starting

point and goal of information analysis. The

information system of an organisation in a broad

sense encompasses all information to and from

business processes and the computer-based

information system is no more than a part of it.

Computer systems should be viewed as just an

instrument to support the effectiveness and efficiency

of the business processes, and not as the only way of

processing information in an organisation. This

approach regularly clashes with the dominant view

that has as its ideal that the information system within

the computer should be a single whole in which all

information is recorded in a centrally organised

manner and where information has the same meaning

to each of its users. In the majority of cases it is

possible to demonstrate to the customer that this is an

illusion, preferably by using examples from practice

using their own processes. The bottom line of an

information system is that the people and systems in

the organisation (1) must have the information needed

for their role in the business processes, (2) must

generate information from their work for the

subsequent business processes. It is a practical matter

which information channels are best suited to record

and communicate which kind of information.

30 Years of Consulting and Developing for Food Processing

145

Over the years I have started to pay increasing

attention to the way in which people handle

information. The basis for this lies in the research by

De Groot into the thinking of chess players (De

Groot, 1965). De Groot shows in his study Thought

and Choice in Chess that a major part of the strength

of the expert is found in his perception of the

situation. An expert does not see anything that a

novice does not see, but he sees it differently.

Research by Weiskrantz (Weiskrantz, 1997) shows

that an essential part of our perceptual processes are

unconscious. This agreed with my experience in

practice that experienced people react to sometimes

seemingly small and insignificant deviations from

habitual patterns and that it is at times hard to indicate

why and based on what they react. For the design of

information systems this means to me in practice that

the adequate recording and presenting of the events

on the shop floor to this kind of people is an important

challenge. The goal of our information systems

should be that the perceptive field of our users is

enlarged, and not narrowed down by irrelevant and

rigid categorisation of data that so often comes with

computer systems.

In information system projects lots of translation

issues are involved. As a specialist in our market we

have learned which questions to ask, how to interpret

the answers, and we have learned how to translate

patterns into models and solutions. At the same time,

we have learned to search for the specific details

which make a company unique and which represent

its competitive power on its market. One of the

greatest risks as an external adviser is to reduce the

situation of the customer to nothing more than an

example of a predefined pattern. For information

systems, heterogeneity and not homogeneity should

be the norm, as is specified in the Reference Model

for Open Distributed Processing (ISO/IEC1998).

In a project, the customer is transferred from an

existing situation to a new situation. In the

implementation of a new information system the

individual employees should be guided by showing

them how the same underlying processes are handled

in new ways. Continuity and change must be shown.

Last year, I discussed these matters a little with a

researcher in Translation Studies, a field which might

contain some useful theoretical views about this

subject (Marais, 2014).

5 CONCLUSION

The combination of practical and theoretical work has

always been a fruitful way of working for me. The

problem of research in business is always how to get

access, and how to evaluate situations. With my

background at RBK I was in the very fortunate

position to be able to observe and participate in many

business situations.

Part of my theoretical background is in semiotics

and in the philosophy of language. Talking about

these theories does not in itself help in business

analysis, but it certainly contributes to a sensitivity for

meaning and interpretation issues. That sensitivity

has greatly helped me in analysing processes and in

looking for solutions. Respect for the heterogeneity

of reality and avoiding reductive solutions is a result

of both my practical work and my theoretical studies.

REFERENCES

Daft, R.L., 2001. Organization Theory and Design, South-

Western College Publishing, Cincinatti, 7

edition.

Mintzberg, H., 1979. The Structuring of Organizations,

Prentice Hall, Englewood Cliffs.

Coase, R.H., 1937. The Nature of the Firm. In Williamson

O.E., Winter S.G. (Eds), 1993 The Nature of the Firm,

Oxford University Press, Oxford.

Kay J., 1993. Foundations of Corporate Success. Oxford

University Press, Oxford.

De Geus, A., 1997. The Living Company. Nicholas Brealy

Publishing, London.

De Groot, A.D., 1965. Thought and Choice in Chess.

Mouton Publishers, The Hague, 2

edition.

Weiskrantz, L., 1997. Conciousness Lost and Found.

Oxford University Press, Oxford.

ISO/IEC, 1998. IS 10746-1 Open Distributed Processing –

Reference Model: Overview.

Marais, K., 2014. Translation Theory and Development

Studies. Routledge, New York.

Fifth International Symposium on Business Modeling and Software Design

146