Upload
duongque
View
228
Download
0
Embed Size (px)
Citation preview
User oriented implementation of an enterprise system component Per Magnusson
Master’s Thesis Human-Computer Interaction
User oriented implementation of an enterprise system component- Sociological, organisational and human-computer interaction aspects
Mars-Augusti 2002, KTH / Renault Trucks
Student: Per Magnusson, [email protected]
School of Engineering (Software Design) and Business Management
Academic Supervisor and Examiner: Professor Yngve Sundblad
Supervisor Renault Trucks: Gilles Bayon
User oriented implementation of an enterprise system component Per Magnusson
User oriented implementation of an enterprise system component - Sociological,organisational and human-computer interaction apects
The master’s project took place at the spare parts division of Renault Trucks in Lyon,
France. The mission was to the help the financial controlling services in verifying IT
procedures and implementing an enterprise system component. The phases of the mission
were:
1) To verify, correct, simplify and document the procedure of separating the income for
the companies that used the services of the spare parts division
2) To configure and to do the final, user-oriented implementation of an enterprise system
component
3) To investigate future issues concerning the integration between different enterprise
systems
The project gave insight to sociological, organisational and human-computer interaction
aspects of enterprise systems. To get a more theoretical approach to the thesis, these issues
became the focus of the analysis. The main conclusions were that enterprise systems seem to
be a way of life, which means that they continuously have to be configured and modified.
They take a very important role in the organisation and they may create frustration for the
users who do not master them. Furthermore, the human-computer interaction could be
largely improved for enterprise systems by using established design guidelines. Finally,
Norman’s model (described in the text) could be applicable to enterprise systems, if it
recognised the importance of the organisation as a major influence when the user is forming
her conceptual model of the system.
User oriented implementation of an enterprise system component Per Magnusson
Användarorienterad implementering av en affärssystemskomponent – med
människa-datorinteraktion-perspektiv, sociologiska perspektiv och organisatoriska
perspektiv
Examensarbetet ägde rum på Renault Trucks reservdelsdivision i Lyon, Frankrike.
Uppdraget bestod i att hjälpa ekonomistyrningsavdelningen att verifiera deras IT-procedurer
och att implemetera en affärssystemskomponent. Uppdragets faser var:
1) Att verifiera, korrigera, förenkla och dokumentera proceduren för att separera
resultatet för företagen som använde sig av reservdelsdivisionens tjänster.
2) Att konfigurera och göra den slutliga, användar-orienterade implementeringen av en
affärssystem-komponent
3) Att utreda framtida frågeställningar angående integrationen mellan olika affärssystem
Examensarbetet åskådliggjorde människa-datorinteraktion-perspektiv, sociologiska perspek-
tiv och organisatoriska perspektiv för affärssystem. För att åstadkomma en mer teoretisk
vinkling på rapporten, så fokuserades analysen på dessa aspekter. De huvudsakliga
lärdomarna var att affärssystem skall ses som en livsstil, vilket innebär att de ständigt måste
konfigureras och modifieras. Systemen har en mycket betydelsefull roll i organisationen och
de kan skapa frustration bland användare som inte behärskar dem till fullo. Vidare, så kan
människa-datorinteraktionen för affärssystem förbättras avsevärt genom att använda
väletablerade designregler. Slutligen skulle Normans modell (beskrivs i texten) kunna
tillämpas på affärssystem om hänsyn togs till organisationens inverkan på användarens
konceptuella modell av systemet.
User oriented implementation of an enterprise system component Per Magnusson
Foreword
This report describes my master’s project at Renault Trucks in year 2002. It is written for
the Swedish master’s project course (examensarbete) in Human-Computer Interaction, at
the Department of Numerical Analysis and Computer Science (NADA) at the Royal
Institute of Technology (KTH). I also chose to do the project as a French Master’s Project,
with a separate report, for the technical university where I did an exchange prior to the
project, Institut National Polytechnique de Grenoble (INPG). Large parts of the reports are
common, and I therefore chose to write both reports in English.
I would like to thank Yngve Sundblad (supervising professor KTH), Gilbert Leconte and
Jean-Luc Guffond (supervising professors INPG), the enterprise system research group at
INPG, Gilles Bayon (industrial supervisor Renault Trucks) and Christine Logmo (Renault
Trucks) for valuable support during my Master’s project.
Per Magnusson
Candidate for M.Sc. in Engineering (Software Design) and Business Management
September 2002, Stockholm
User oriented implementation of an enterprise system component Per Magnusson
Table of contents
1. Project description and analysis____________________________________________ 1
1.1 Renault Trucks and the Financial Controlling Services (FC) __________________ 1
1.2 The mission and its context_____________________________________________ 2
1.3 Introduction to the subject and areas of analysis ____________________________ 7
2. Phase 1: Familiarisation with the IT environment, ongoing operations and incomeseparation of different companies using the services__________________________ 14
2.1 Mission and methods ________________________________________________ 14
2.2 Results ___________________________________________________________ 20
3. Phase 2: Final user oriented implementation of an enterprise system component ___ 21
3.1 Mission and methods ________________________________________________ 21
3.2 Results ___________________________________________________________ 26
4. Phase 3!: Small study on future issues _____________________________________ 27
4.1 Mission and methods ________________________________________________ 27
4.2 Results ___________________________________________________________ 27
5. Observations and analysis _______________________________________________ 28
5.1 Observations ______________________________________________________ 28
5.2 Sociological and organisational aspects of enterprise systems _________________ 30
5.3 Human-computer interaction aspects of enterprise systems ___________________ 32
6. Conclusions and recommendations________________________________________ 37
6.1 Conclusions _______________________________________________________ 37
6.2 Recommendations __________________________________________________ 38
7. References____________________________________________________________ 39
User oriented implementation of an enterprise system component Per Magnusson
1
Project description and analysis
1.1 Renault Trucks and the Financial Controlling Services (FC)
The master’s project took place between March and August 2002 at Renault Trucks. Renault
Trucks was formerly known as Renault Véhicule Industriel (V.I.) and is a part of the Volvo
group since 2001. Renault Trucks manufactures a broad range of heavyweight vehicles and
employs around 15 000 people. Of the 60 000 vehicles that are produced each year, 45 % are
sold in France, 50 % in the rest of Europe and 5 % in the rest of the world. The market
share for France was 35 % in year 2001 and for the rest of Europe 12 % (source: internal
documents and supervisor Gilles Bayon).
The project was carried out for the financial controlling services (FC) of the spare parts
division management. The spare parts division management is located at the headquarter of
Renault Trucks outside Lyon, France. The division is one of the most profitable at Renault
Trucks, with a gross profit margin of more than 40 % (source: supervisor Gilles Bayon). It
has a market share of 60% for the accessible market, but due to an upcoming market
deregulation, this large share will be difficult to defend. Apart from new spare parts, the
division also sells renovated and used spare parts.
The financial controlling services (FC) has several assigned duties. The FC does financial
reporting, budgeting and several types of analyses. The analyses are often done in
collaboration with the marketing services, and they could for example concern the
profitability of certain product types or clients. An analogy of financial controlling is that of
the thermostat. When the temperature is dropping, i.e. the profit, this is noted by the
thermostat who raises the temperature, which in financial controlling means analysing why
the profit is dropping and taking corrective actions. During the last years, emphasis has
however moved from corrective actions to pro-active actions based on anticipation of the
future (Cooper et al., 1998).
User oriented implementation of an enterprise system component Per Magnusson
2
1.2 The mission and its context
The project involved assisting the financial controlling services (FC) in verifying the
function and usage of the newly installed enterprise system and to suggest or implement
improvements. Practically all data that the FC is using originates from the enterprise system.
It is therefore imperative that the FC masters the system and is certain of the data accuracy,
so that its analysis becomes reliable and serves as good support for decisions.
One year before the beginning of the project, the spare parts division replaced a large part of
its information systems and programs with SAP R/31. A reason for the change was that the
organisation wanted to integrate its information and thus support a change in its operations.
Previously, each country branch and its country specific warehouse made the deliveries
within each country. The organisation wanted to change this by having the central
warehouse in France take care of the major parts of the deliveries. The number of national
smaller warehouses was to be reduced (see figure 1.1). To co-ordinate the change and to
integrate the activities the organisation chose SAP and specifically its sales and distribution
module as the information backbone.
DistributionwithCDIPRDistributionwithCDIPR
Distributionw. branches
CDI R
CDIPR
Figure 1.1: The starting point of the change project is to the left: a large number of deliverieswere made from smaller country-specific warehouses. The goal of the IT system was to supportthe change is illustrated to the right, where one warehouse, CDIPR, makes most deliveries.
1 For more information on SAP, see next chapter
User oriented implementation of an enterprise system component Per Magnusson
3
As a result of the SAP implementation, the old mainframe system that the FC used for its
analyses did not function as before, due to a less detailed data interface. During a transitional
year, when the masters project took place, the FC was mining their data from a data
warehouse connected to SAP. However, the year following the project, the FC was
planning to start using an SAP controlling component for a large part of their analyses. The
mission of the master’s project had to do with these evolutions. Specifically, the mission was
divided into the following three, more or less consecutive, phases.
1) Familiarisation with IT environment, ongoing operations and income separation of
different companies using the services
This phase involved learning the IT environment and more specifically the query
tool of SAP Business Operations Warehouse (BW). BW is a data warehouse where
transaction and client data are being stored and updated daily. My mission was to
verify, correct, simplify and document several different queries to determine the
monthly result of a separate company that was using the spare parts distribution
centre’s services. Furthermore, the mission was extended to involve several problems
with the retrieval of the daily revenue. The phase was an introduction to the tasks
performed by the FC and it served as a springboard to the next phase.
2) Final, user-oriented implementation of an enterprise system component
This phase included learning and analysing an SAP controlling profitability analysis
component. The controlling component had already been installed and the goal was
to make it fully functional, so that it could be used for accurate analyses. This meant
introducing provisions of costs that were not given by the invoicing component of
the SAP’s sales and distribution module. Furthermore, the income statement in the
controlling component, and especially the provisions were compared to the ones
present in the accounting system and errors were corrected. The specific
requirements of the FC for the controlling component were analysed and
adjustments were made or communicated to the IT department.
User oriented implementation of an enterprise system component Per Magnusson
4
3) Small study on future issues
A small study was to be done during the mission, to see how the relation between the
controlling component and the accounting system that was about to be replaced,
would be in the future. It was also intended that the roll-out of the controlling
component to other countries would start. However there was not enough time to
fully pursue this objective.
On the next page, the general development of the enterprise systems for the FC is described
in figure 1.2. The relation between the general development and the specific phases of the
master’s project is also described.
User oriented implementation of an enterprise system component Per Magnusson
5
ControllingFrance
AccountingFrance
ControllingFrance
AccountingFrance
Less detailed interface
Old system for France- Inventory management- Ordering & invoicing
SAPControllingFrance
ControllingFrance
AccountingFrance
Mainframe
SAP R/3
Interface
SAP for Europe- Inventory management- Ordering & invoicing
ControllingFrance
AccountingFrance
SAP BusinessOperationsWarehouse (BW)
Less detailed interface
SAP for Europe- Inventory management- Ordering & invoicing
SAPControllingFrance
SAP for Europe- Inventory management- Ordering & invoicing
SAPControllingEurope
SAP Accounting Europe andintegration with Volvo
Figure 1.2: The ongoing change in the IT environment for the Financial controlling services
The first picture shows the old mainframesystem, where inventory, ordering andinvoicing were handled by mainframe systems.These mainframe systems communicated datato the accounting and controlling system withan interface. In each country there were specificsystems (Franch system is shown here).
The second picture is the next step, where SAPhad been implemented to handle the inventory,ordering and invoicing. The interface thatconnected SAP with the accounting andcontrolling was less detailed, which meant thatsome data had to be mined by the financialcontrolling services from a separate datawarehouse connected to SAP. The mission of thefirst phase was to verify the queries that weremade with SAP Business Operation Warehouseto separate the income between the companiesthat were using the spare parts service. Prior toSAP, it was not possible to do this separationat all in the accounting system.
The third picture shows when the controllingmainframe system is replaced by an SAPcontrolling profitability analysis component.The second and largest phase of the master’sproject was to make the final, user orientedimplementation of this component, by makingit fully functional and adapting it to user needs.
The last picture is illustrating the future, wherethe accounting system will be replaced and SAPcontrolling will be rolled out in Europe. Thelast third phase in the master’s project was toconduct small studies on these issues. However,there was not much time in the end for thisphase
User oriented implementation of an enterprise system component Per Magnusson
6
The project had a cross-disciplinary character with computer scientific, sociological and
business perspectives. In the field of computer science, a general understanding of databases,
query languages and how enterprise systems work was beneficial. From a sociological or
organisational perspective, it was important to understand the organisation, its practices, its
operations and the role of the FC within it. To understand the daily operations of the FC
and the business logic behind the programs, knowledge of management accounting and
controlling was essential.
The project work was to be guided by interviews with different users of the systems and by
reading manuals and documentation. The method was to interrogate IT professionals, co-
workers of the FC and other employees to obtain information and in that way understand
the function of the systems and the data interfaces. After this, several tests would be done to
understand how the systems were functioning and how the configuration affected them. By
doing tests errors were to be discovered and corrected by changing the configuration. A
"secondary method" was to observe the role of the enterprise system in the organisation. I
conducted a small "field study" to get a more theoretical approach to the project, trying to
analyse enterprise systems and their sociological, organisational and human-computer
interaction aspects. These areas of analysis are described in the subject introduction in the
next chapter.
The equipment that was used during the project was a personal computer with access to the
different systems. A time plan was established during the first week of the project. The
duration of the different phases was difficult to estimate and the plan therefore became a bit
arbitrary. Because of the prolonged first phase, the time plan was continuously modified
during the project.
User oriented implementation of an enterprise system component Per Magnusson
7
1.3 Introduction to the subject and areas of analysis
As stated, the Master’s Project had computer scientific, sociological and business perspectives.
Due to this cross-disciplinary character, the project was undertaken in the wide field of
human-computer interaction. Another description of the project subject could be software
design – business – leadership, which is the project student’s specialisation. It was early
decided with the academic supervisor that the analysis and the resulting thesis would not just
be based on the actual project work and its methods, but also on the project student’s
observations during the project. This was made to allow a more theoretical analysis of the
organisational, sociological and human-computer interaction aspects of enterprise systems.
This theoretical analysis would serve as a basis for a conclusion and a recommendation.
First, enterprise systems and the related research field, information systems research, are
introduced. The contemporary leading paradigm seems to be to consider the information
system as a part of a larger social system. To understand the role of the information system
within this larger social system, different cognitive and sociological theories are described.
This is followed by some general human-computer interaction theories. To my knowledge,
there have been few attempts to describe the human-computer interaction for enterprise
systems. Finally, the areas and questions of analysis are presented.
The very kernel of the project is the enterprise system, a sort of advanced information
system. Enterprise systems are also known as enterprise resource planning (ERP) systems.
The enterprise system in this project, SAP, is the most common with a world market share
in year 2000 of just under 30 % (Davenport p.304, 2000). Like most enterprise systems, SAP
has modules for most functions in an enterprise. The latest version, SAP R/3, has twelve
modules. Three of these modules, the sales amd distribution, the financial accounting and the
controlling modules were involved in the Master’s project. SAP runs on a client/server
computing architecture, which means that some part of the processing is done on a server,
and some on the clients, i.e. the desktops. It has a central database and communication
between the modules is either direct or indirect with the help of the database (Doane, 2001).
User oriented implementation of an enterprise system component Per Magnusson
8
Davenport (2000) believes that enterprise systems change ways of doing business. They
should be justified in business terms instead of just technological terms and if properly
employed, they can even be a source of competitive advantage. An implementation of an
enterprise system has of course a large impact on the organisation. It often calls for a
reengineering of the organisation and its processes, to comply with the ’best practices’ of a
process, defined by the enterprise systems. By having the best practices, more efficient and
less costly operations are achieved, and the implementation is thus justified in business terms.
Furthermore, enterprise systems are in some sectors according to Davenport even a pre-
requisite for being able to compete. This seems very much to be the case of the spare parts
industry. Rubython (2002) describes what happened to MG Rover’s spare parts business a
few years after the BMW takeover. BMW management decided to change the subcontractor
and this also meant that the previous mainframe system was replaced by SAP, which was
installed by the new subcontractor. The implementation was very unsuccessful and largely
due to this, the availability of spare parts dropped from 98 % to 76 % and the profitability
was destroyed. For MG Rover, a working enterprise system was imperative to compete
successfully. Although SAP appears to be more advanced than the previous system,
Rubython claims that SAP is complicated and that it takes a long time to have it properly
functioning.
Enterprise systems do not only function as support for the everyday operations, such as
production control. Enterprise systems can also be seen as decision support systems. The data
are mined from the central database and then analysed and presented so that it can serve as a
good basis for decisions. This is the case for financial controlling, where the goal is to turn
"raw" data into knowledge. The vision of this field called ’knowledge management’ is, as
presented by Davenport (p. 275), that ’the interaction between systems and humans
becomes more collaborative; while the system itself can have some decision-making
capability programmed into it, the system also acts as an extension of the human ability to
store and process knowledge.’ It is basically about letting the systems do the complex analysis
and leave the decision-making to the humans.
The academic field that enterprise systems belong to is information systems research. The
field used to be very focused on actual technology but in the later years it has taken a more
User oriented implementation of an enterprise system component Per Magnusson
9
wide approach, recognising that the information system is a part of a larger real-world
system where human actors, organisations and the information systems interplay (Zhu et
al., 2000 ; Lundeberg, 1995). Jan et al. (2002) describe the development in the field since the
1950’s as having had three stages: a mechanical stage, an organismic stage and a social stage.
’In the mechanical stage, the information system role is to support organisations as a
machine and information system missions are to support transaction processing systems and
operational control. In the organismic stage, the information system role is to support
organisations as an organism and information system missions are to support transaction
processing systems and all levels of management. In the social stage, the information system
role is to support organisations as a social system and information system missions should
take account of the organisation, its components and other organisations of its larger
systems.’
To try to explain the role of the information system in these larger social systems, there are
several cognitive, sociological and even biological theories that could be used. Suzi et al.
(2001) described some of these, when they tried to explain the specific role of information
technology as a ’mediator of collaborative activities’. These theories were activity theory,
situated action, distributed cognition and stigmergy. They are described in the following
paragraphs and I believe that they also could serve as frameworks when describing the
general role of information systems.
Activity theory is a sociological theory that seeks to model activity systems for the interaction
between subjects (humans) and objects (artefacts). It recognises that subjects transform
objects and vice-versa. Focus is on practice, to understand everyday practice in the real
world. The principle behind activity theory is that ’human mind comes to exist, develops,
and can only be understood within the context of meaningful, goal-oriented, and socially
determined interaction between human beings and their material environment’.
Situated action is more of a cognitive theory that recognises that there is no planned action,
but rather situated, circumstantial action that does not follow a plan. Situated action
considers the agent as an opportunistic improviser responding to environmental conditions
in an unfolding situation. Suzi et al. relate situated action to collaborative activity by stating
User oriented implementation of an enterprise system component Per Magnusson
10
that ’the context of an action is extremely important and artefacts must therefore be
considered having an important role in any action, being part of environmental conditions’.
The primary unit of analysis in the framework of distributed cognition is a distributed,
socio-technical system. The cognitive system consists of people working together, and the
artefacts they use. Distributed cognition studies the representation of knowledge inside the
heads of individuals and in the world. It has been criticised for equalling artefacts and
humans.
After describing these theories, Suzi et al. suggested that a complement to the described
theories to explain ’artefact-mediated collaborated activity’ is the biological theory of
stigmergy. Stigmergy explains the co-ordination paradox, i.e. the connection between the
individual and the societal level: looking at the behaviour of a group of social insects, they
seem to be co-operating in an organised, co-ordinated way, but looking at each individual,
they seem to be working as they were alone and not involved in any collective behaviour. As
an example, stigmergy seeks to explain how ants communicate indirectly through objects,
i.e. building materials and chemical traces.
Human-computer interaction is a large field and there are several interesting theories and
guidelines. Schneiderman (1998) defined the classical eight golden rules of interface design in
the following way:
o Strive for consistency
o Enable frequent users to use shortcuts
o Offer informative feedback
o Design dialogs to yield closure
o Offer error prevention and simple error handling
o Permit easy retrieval of actions
o Support internal locus of control
o Reduce short-term memory load
Normans theories have like Schneidermann’s eight golden rules had a large impact on
human-computer interaction. He defined in his book ’The Design of Everyday Things’ the
fundamental principles of designing for people as
o provide a good conceptual model
User oriented implementation of an enterprise system component Per Magnusson
11
o make things visible
o give feed back
There are different kinds of conceptual models (see figure on next page). ’The design model
is the designer’s conceptual model. The user’s model is the mental model developed through
interaction with the system. The system image is the result of the physical structure that has
been built (including documentation, instructions and labels). The designer expects the user’s
model to be identical to the design model. But the designer does not talk directly with the
user – all communication takes place through the system image. If the system image does not
make the design model clear and consistent, then the user will end up with the wrong
mental model.’ If the user ends up with the wrong mental model, it can lead to possible
errors made by the user and slow learning. To achieve a mental model that is fairly coherent
with the real system it is important that the system image is well designed and thus makes
efficient usage possible. I believe that it is important to recognise that the mental image of
the user, does not only depend on the system image but also on the user’s former
experiences, for example from other programs (see figure 1.3 on next page).
To make things visible includes, according to Norman, to visualise the conceptual model of
the system, the alternative actions, and the results of actions. Finally, Norman stresses the
importance of feedback, to be able to see the result of what you have done and make possible
corrections.
User oriented implementation of an enterprise system component Per Magnusson
12
Figure 1.3: The conceptual models according to Norman, slightly modified by adding formerexperiences for the user.
As stated, to my knowledge, there have been few studies that have treated the human-
computer interaction with enterprise systems. One interesting study was made by Howie et
al. (2001). The focus of the study was not the human-computer interaction of enterprise
systems but how to model an underlying complex system with a computer program. Howie
et al. claimed that dynamic decision-making in complex systems can be improved by
designing human-computer interfaces according to well-accepted human factors design
guidelines. The article is based on the work of Sterman, a Canadian management scholar,
who formulated the misperceptions of feedback (MOF) hypothesis. From Sterman’s
perspective, ’people’s poor performance in dynamic decision-making tasks in complex
systems can be attributed to the fact that the information needed for high performance is
available but not heeded.’
System Image• Documentation• Education• Graphical
Interface• Manipulation
Possible differencesbetween conceptual
models
User• Former experiences
Mental Image(User’s
ConceptualModel)
Designer• Communicates system
functioning throughsystem image
Real System(Designer’sConceptual
Model)
User oriented implementation of an enterprise system component Per Magnusson
13
Howie et al. suggested the following hypothesis. ’People do not do well because their
knowledge of system structure is less than perfect. In this case, poor performance is caused
by lack of knowledge rather than some fundamental psychological limitation. On this
reading, improved performance could perhaps be achieved through training by helping
people to develop more accurate mental models of the system they are controlling.’ The
thesis was demonstrated with experiments conducted with two programs. Both programs
simulate a supply chain and the goal is to optimise the system by reducing costly high
inventory levels as well as back-logs. One program had a ’main-frame’-like, primitive
graphical interface, whereas the other program was designed with the following
acknowledged human-computer interaction guidelines:
o Wherever possible, take advantage of people’s natural tendencies (e.g. reading from
left to right and from top to bottom)
o Wherever possible, take advantage of people’s existing knowledge (e.g. through the
use of metaphors)
o Present information in a graphical, rather than just a text-based, fashion to exploit
people’s powerful pattern-recognition capabilities.
o Show, not just data, but also relationships between data so that people can develop a
more accurate mental model of the simulation.
The experiments showed that the users of the second program achieved a better result.
These guidelines could therefore be useful to consider when designing enterprise systems.
As demonstrated, there are several aspects of enterprise systems. With the help of my
observations during the project, the areas of analysis will be
1) Sociological and organisational aspects
How do my observations relate to the theories presented by Suzi? What is the role of
the enterprise system in the organisation?
2) Human-computer interaction aspects
Do enterprise systems (or rather SAP R/3) follow interface design guidelines like the
ones of Schneidermann and Howie. How applicable is the theory of Norman?
After having analysed these areas, the conclusions or the theses will be made. This will lead
to general recommendations of how enterprise systems can be managed.
User oriented implementation of an enterprise system component Per Magnusson
14
2. Phase 1: Familiarisation with the IT environment, ongoing
operations and income separation of different companies using
the services
2.1 Mission and methods
The first phase of the project lasted eight weeks. Primarily, the mission was to verify,
correct, simplify and document the income separation between different companies that
were using the services of the spare parts division (see figure 2.1). To do this the activities
performed by the financial controlling services (FC), the IT environment and the query tool
of SAP Business Operations Warehouse (BW), which was to be used for the separation, had
to be learned. By providing this familiarisation with the IT environment and the
organisation, the phase served as a spring-board to the ’real’ mission in the next phase of the
project, that is the full system deployment of a profitability analysis component. During the
phase, problems arose with the retrieval of the daily results. The mission was therefore
extended to help the FC resolve the problems. As a result, the first phase took eight weeks
instead of the five weeks initially planned.
Figure 2.1: The first phase was not directly related to the ongoing change in the ITenvironment. With the newly installed SAP it had become possible to separate the incomebetween the different companies that were using the services of the spare parts division. Theprimary mission of the phase was to verify, correct, simplify and document the queries thatwere being used.
The first week of the phase was used to read system manuals, to formulate the mission and
to make a time-plan. It was quite difficult to understand what the master project was about
and, as stated, the time plan therefore became a bit arbitrary. The manuals and documents
used for the orientation of the IT environment were mostly Renault Trucks’ own material.
SAP for Europe- Inventory management- Ordering & invoicing
Controlling
France
Accounting
France
SAP Bus ine s sOperationsWarehouse (BW)
No possibilities to separatethe income in the old mainframe accounting system
?Several queriesdesigned to separatethe income
User oriented implementation of an enterprise system component Per Magnusson
15
They were quite simple and served as fairly good introductions to the systems. As an
introduction to SAP Business Operations Warehouse (BW), a meeting was held with a
Master’s project student whose mission was to secure the BW user environment. The
meeting provided a theoretical foundation and the student provided system manuals and
documentation.
BW is a data warehouse provided by SAP to use for data mining. ’Data warehouse’ is simply
signifying a large database. In this case, the database was separate from SAP’s central
database. The BW database stores SAP client and transaction data and it is updated with daily
intervals. A major advantage of having a separate database instead of using SAP’s database is
that it reduces internal traffic within SAP. The system performance is thus improved for
SAP. Furthermore, the performance of BW is improved by having special pre-defined states
with accumulated transaction data. This reduces the response time for the queries. Finally,
performance is perhaps improved by the client user interface. It is specific for BW and I
found it more user-friendly and flexible than the query tools in actual SAP that I used later
in the project. The BW client user interface is an Excel macro, in which the user can define
and store specific queries for each pre-defined state (see picture 2.1 on next page). There are
for example states to retrieve the monthly revenue, the stock level and to list invoices. Each
state has numerous attributes that can be selected or excluded. This makes it possibly to do
very specific queries, for example to retrieve the revenue for a certain client, on a specific day
and for a specific spare part. The response of a query is on the form of an excel-sheet.
With basic comprehension of BW, the first mission was initiated. At the time of the project,
Irisbus had started to use the services (i.e. the storage and distribution of their spare parts) of
the spare parts division. Irisbus, a bus manufacturer, was originally a joint venture between
Renault Trucks and the Italian-based Iveco Trucks, and became later fully owned by the
latter. It was not possible to separate the income between Renault and Irisbus in the
accounting system, the mainframe system that depended on data from SAP. Therefore, the
separation of income had to been done once a month with the help of BW. A former FC
employee had designed the separation queries about half a year prior to the beginning of the
project. He had done this by asking different users of the system and the BW administrators,
which attributes to use in the queries. The same employee gave me a short introduction and
User oriented implementation of an enterprise system component Per Magnusson
16
showed the queries. In a sense, he had done the initial work, and the mission was to verify
and correct the queries, as well as to simplify and document the process.
There were four queries, and for Irisbus they determined the revenue, the provision of joint
product type revenue, the stock level and the stock movement respectively. The basis for the
separation was a special attribute that was assigned to each product type. The attribute,
which was called the ’analysis code’, determined if the product was specific for Renault
Trucks, Irisbus or both companies. With this being the basis for the separation, the actual
queries might not seem too complicated; it was just a question of assigning certain attribute
to the queries. However, there were several specific attributes in the queries, which needed
explanation. They needed explanation since they were describing the underlying real-world
system and its particularities. Moreover, though the queries had been executed each month,
they had not been properly verified and updated.
Picture 2.1: The BW client user interface. The user designs the queries and launches them. Theresult appears on an excel sheet (in the background).Source: screen dump from my personalcomputer.
User oriented implementation of an enterprise system component Per Magnusson
17
The queries were studied by doing tests to see the impact of different attributes. The former
FC employee helped by either explaining the reasons for the attributes or referring to
professionals that knew about, or had even made, the queries. The queries were gradually
verified, updated and corrected during two weeks. As an example, there was a client list in
one query, which should contain all specific clients for Irisbus. The work consisted first of
finding out why the list was there. Second, clients were added to the list after asking the
sales department, if there had been any new specific clients for Irisbus since the last update.
Finally, there had to be a less complicated way, than to manually add clients every month.
Apparently, there was a list for specific Irisbus clients in SAP, which was also present as a
possible query attribute in BW. The problem was that this list was not complete, and it could
not be, since some clients were not able to order the common product types, if they were
classified as specific Irisbus client. Therefore, it was concluded that there was no less
complicated way of having the list updated.
There seemed to be confusion about the conditions that were used in BW. Different
departments used different constraints and no one really seemed to know why to use them.
When investigating the explanations of the logic behind the constraints, I often had to
consult several people to get an explanation. After two weeks, when it was time to do the
monthly closure, the overall picture was however fairly clear. The monthly closure was done
by me. The modified queries were successful, except the fact that there seemed to be an
unexplainable difference between the stock level query and the stock movement query. It
seemed as if stock was disappearing and it called for further investigation. Besides this
problem the focus of the mission changed from verifying and correcting to simplifying and
documenting.
Simplifying meant that when the responsibility for the monthly closure would be handed
over to an FC employee, she would find the process simple. Furthermore, to make the
process easy to understand, a manual and process documentation was to be written. The first
step in the simplifying process was to have all query references on different sheets in one
instead of several Excel files. This meant that instead of launching five consecutive queries,
the requests could be launched all at once. Furthermore, on one sheet, there was a
description of the steps of the monthly process to execute (see picture 2.2 on next page). To
determine the different revenues from different organisational units, an Excel table with all
User oriented implementation of an enterprise system component Per Magnusson
18
the clients and their origin was used. A look-up was made with an Excel formula for each
invoice to verify the organisational unit. The process was simplified and more automated by
integrating the lookup formulas in the Excel file with the result of the queries. Finally, each
month the data from the queries were consolidated in one income sheet table. By writing an
excel macro, and by integrating the table in the excel sheet together with the queries, this
process was also simplified.
Lancer requêtes BW
1. Actualiser les requêtes
1. Copiez une version actuelle de RecapCP.xls à O:\DCAV_CG\Per\SéparationIRISBUS
2. Actualiser les requêtes en cliquant sur les fleches tournant (sur outil SAP Business Explorer)
3. Repondez oui à question et choisissez les dates
4. Sauvegardez et sauvegardez sous O:\DCAV_CG\Per\SéparationIRISBUS\mois
2. Actualiser les tableaux pour Irisbus
1. Ouvrez , les chiffres sont directement copiées
2. Dans le fichier xxxxxx; Ouvrez le feuil le mois actuel. C opiez et mettez special - valeurs' les valeurs avec 'collageau feuil recap vue irisbus
3. Sauvegardez et sauvegardez le fichier sous O:\DCAV_CG\?????
?
CAIris.xls
Picture 2.2: A description of the steps to execute was on one sheet in the excel file with thequeries. The first large step, was to refresh the queries by performing four consecutive actions.The second large step, was to update income statement tables by performing three actions.
By interrogating professionals that worked with the stock ledgers, the problem with the
difference between the stock level query and the stock movement query was solved.
Apparently, there were certain movements that were not taken into account with the stock
movement query. These movements were either scraps or ’other inventory differences’.
Two queries were designed, so that the data could be introduced in the income statement.
The unexplained difference in the income statement had thus been resolved.
User oriented implementation of an enterprise system component Per Magnusson
19
Though the project focus changed from the separation of revenue to the mission described
in the next paragraph, the next month’s closure was still performed by me. This gave me the
opportunity to verify that the simplification had been done accurately. For the closure the
following month, and the months after, responsibility was handed over to a collaborator in
the FC. With the help of the documentation and the manual she seemed to manage the
simplified process and the closure was made successfully.
As previously stated, my mission was partially extended, to involve an important part of
daily operations. Everyday, an extraction of the revenue was done with the help of BW. A
few queries were used to extract the revenue and another query was used to verify it. For
long, there had been a small difference between the result of the queries and the verification
query. In April, the was a major difference and the mission became to analyse why this large
difference was there, and second, to verify and correct the queries so that even the small
differences would be eliminated.
Isolating the major difference was fairly simple. By using excel and its pivot-tables the results
of the different queries were compared. When looking at the result for each day it was
found that there had been an error in the BW database one day when the data had been
accumulated. The data in one state, originated in fact from the state that was used for the
verification. When data was accumulated to the former, it was accumulated twice during one
day, which explained the major difference. The IT department was notified of the problem
and it was corrected.
To understand and correct the small difference between the daily revenue query and its
verification turned out to be more difficult. There were several attributes in the queries and
they all had to be verified. This time, the work was doing closer with the IT department
Eventually, after a few weeks and a few changed attributes the queries had been verified, and
the small difference had been eliminated.
User oriented implementation of an enterprise system component Per Magnusson
20
2.2 Results
The major accomplishment of the first phase was that the separation process was verified
and documented. The FC employees have a fairly intense workload; they have enough work
by just performing the daily activities. The solution was someone from the outside, with IT
skills, who could do this verification without spending time on the daily activities. The
verification meant that the information and data accuracy improved, and hence the
accounting became more accurate. Furthermore, the process was made easier, which meant
that when responsibility for its execution was handed over, time was saved. At the time of
the project, every BW user could access each saved query and make changes to it. Though
this problem was being corrected (by another project student), its was still valuable to have
documentation that explained why the attributes in the queries were there. Finally, by
helping the FC to analyse the retrieval of the daily revenue, the differences that existed
between the queries were eliminated, and the retrieval became more reliable.
There was also an indirect result obtained from the first phase. I had learned Renault
Trucks’ activities and its organisation, as well as the particularities that were related to SAP
and its transaction flows. Without this introduction, the next phase would probably have
taken much more time. In this sense, the phase served as a stepping stone to the next one.
The decision, that the phase would be extended to involve the daily retrieval of the revenue,
had an impact on the rest of the project. It took time from the next phase. On the other
hand, the daily retrieval was essential for the FC’s analysis and the extension of the phase
therefore added value.
Apparently, there was no special method used in the first phase. It was mainly a question of
organising and working in a structured way to fully analyse the problem. By interrogating
and testing I got a clear picture, and this knowledge was capitalised by writing documen-
tation
User oriented implementation of an enterprise system component Per Magnusson
21
3. Phase 2: Final user oriented implementation of an enterprise
system component
3.1 Mission and methods
The mission of the second phase was to do to the final user oriented implementation of a
controlling component to be used for profitability analysis (see figure 3.1). The controlling
component had already been installed and the goal was to make it fully functioning, so that
it could be used for accurate analyses. This involved introducing provisions of costs, by
applying a certain percentage to the revenue or the product cost. The phase took around
twelve weeks.
More specifically, the mission was to adjust the percentages and their application criteria so
that the provisions in the controlling component would be a rough reflection of the
provisions in the accounting system. In the accounting system the provisions were processed
manually. They were determined by doing a more refined analysis. For example, to
determine the transport provision, weight and country were considered to be the cost
drivers. A large part of the mission became to verify the correlation between the two
systems. Furthermore, a study of the user needs and functions in controlling component was
done and the required adjustments were made or escalated to the IT department.
Figure 3.1 The second phase of the mission was to do the final user oriented implementation ofthe SAP controlling component.
As an introduction to the phase, a meeting was held with the IT professionals that had
installed the component and were in charge of its maintenance. A short overview of the
SAPControllingFrance
Less detailed interface
SAP for Europe- Inventory management
- Ordering & invoicing
Controlling
France
Accounting
France
Do the final user orientedimplementation of the SAPcontrolling component:
- Comparing data betweenaccounting and SAP contr.- Introducing Provisions- Investigating user needs and
implementing/escalating
User oriented implementation of an enterprise system component Per Magnusson
22
controlling component and a general plan for the mission was made. It included stating the
mission and planning a relevant SAP education for me on the controlling component.
Documentation and user manuals were provided and it consisted of Renault Truck’s own
material or material provided by external consultants. To learn more about the accounting
system an experienced user in the FC was interrogated. By asking the person that had
written the interface between SAP and the accounting system, a documentation of the
information flows was obtained.
The controlling component is a component in SAP’s controlling module. It is used to
analyse the profitability and it had several possibilities to do detailed analysis. The data in the
component originate from SAP’s sales & distribution module, the module that was installed
to support the change in infrastructure where one central warehouse in France would do
the major parts of the deliveries, and the number of national smaller warehouses was to be
reduced (see introduction). In the controlling component, it is possible to analyse the
margins for specific product types, type of commands and geographical zones. The analyses
are made by creating a state. This state is fairly general and contains several attributes. An
income statement is generated, and by narrowing the selection criteria (the attributes), it is
possible to perform a very detailed analysis.
The accounting system, with which the comparison of data would be done, was an old
mainframe system (see picture 3.1 and 3.2 for a comparison between the graphical
interfaces). Previously, the data to the system was interfaced from the sales system in place
before SAP. After the implementation of SAP an interface was written between SAP and
the accounting system. The interface was less detailed than the previous one, and attributes
such as type of commands were no longer present to use in the analyses. The analysis in
2002 were done by taking some data from BW and some data, mainly the provisions, from
the accounting system and consolidate these in a large Excel list. With the controlling
component, the same kind of monthly analysis would be less complicated to perform, by not
requiring this copying and reshaping of data.
As I was about to find out, the controlling component and the SAP environment were quite
complicated to manage. Just like BW, it took time to learn and to understand what the
mission was about. Unfortunately, the IT professionals that knew SAP had little time to
User oriented implementation of an enterprise system component Per Magnusson
23
help me with SAP and the mission, and the progress was therefore quite slow. In the
beginning of the phase, I believed that an applied percentage also would apply to historical
transactions. Eventually, it was found out, that this was not the case, which meant that the
verification, that I had done between the income statement in the controlling component
and the accounting system, had been fairly useless. Furthermore, since the percentages were
applied in the sales and distribution module, and the statement was generated by the
controlling module, communication was done with one controlling module specialist and
one sales and distribution specialist. Small incidents with the system had to be reported to a
maintenance hotline, which meant that another IT professional would be involved. This
meant that there was a problem with co-ordination and that a large amount of time was used
for communication instead of action. An old demand from FC to raise the system
performance of the controlling component was also being processed. It took time to boost
the performance and some essential states of the controlling component could not be
generated during this time, which meant that valuable time was lost.
User oriented implementation of an enterprise system component Per Magnusson
24
Picture 3.1: The picture is a created state in the controlling component profitabilitycomponent. . With the controlling component, the income statement, in this case for Belgiumin April 2002, was possible to analyse in detail, for example by product type or by client.
Picture 3.2:The picture is a screen dump of the old mainframe accounting system With theaccounting system, the income statement for Belgium was just one generated screen with nopossibilities for further analysis.
User oriented implementation of an enterprise system component Per Magnusson
25
The analysis was done for each country. By starting to regard the income statement of the
chosen country in the accounting system, and by interrogating the FC employees, the
provisions that had to be in the controlling component were identified. By dividing the total
provision with the revenue and the product cost for the start of the year 2002, the
percentages that would be applied in the controlling component were established. The
provisions in the controlling component would, when generated by these historical
percentages, serve as a rough reflection of the ones in the accounting system.
The next step in the analysis was to generate the controlling component income statement
that corresponded to the one in the accounting system. This was not always so easy since the
organisational units in the accounting system did not perfectly correspond to the
organisational units in the controlling component (the same as in SAP). This was caused by
the interface between SAP and the accounting system, where a determining attribute for
the organisation was something called ’distribution mode’. This criterion was not present
when launching the controlling component states, which meant that the organisational
units could not be constituted in the same way. The verification was made by observing if
the provisions were present in the controlling component. Furthermore, the application
criteria for the percentages that would give the provisions, had to be verified. The
application criteria consisted of a determination if the percentage was applied to the revenue,
the product cost or some other value that originated from SAP’s sales and distribution
module. The application criteria also stated for which attributes the percentage would be
applied. Such an attribute was for example a specific country or product type. The
percentages applied were for each country and adjustments to make the controlling
component fully usable was communicated to the IT department. These adjustments
included for example introducing new lines in the income statement or correction of data
irregularities.
User oriented implementation of an enterprise system component Per Magnusson
26
3.2 Results
Not all data irregularities were identified during my project. However, several countries had
been verified and their percentages in the controlling component had been applied. Changes
required in the controlling component, to fulfil user needs and to facilitate a correct
function, had either been done by me or escalated to the IT department. For example, I had
updated lists, that were necessary to retrieve correct data. Many of the adjustments, that I
wanted the IT department to do, had not been done. The final weeks of the mission
consisted therefore of clearly documenting what I had done and requested. This way, even if
the adjustment had not been done when I left, the evolution of the controlling component
could be controlled by the FC. My mission did not, however, require immediate result. The
controlling component was not to be fully used until 2003. Hopefully, after the finish of the
project, there was only fine-tuning left to do.
Just like the first phase, there was no specific method that was employed. Instead of
verifying for each country, one could of course have done the verification for each type of
provision. This would probably have taken more time, since the COPA states used for
verification were country-specific and not provision-specific.
User oriented implementation of an enterprise system component Per Magnusson
27
4. Phase 3 : Small study on future issues
4.1 Mission and methods
This final, third, phase of the project was a bit separate from the other parts. The goal was to
see how the relation between the controlling component and the accounting system that
was about to be replaced, would be in the future. It was also intended that the roll-out of the
controlling component to other countries would start. However, there was not enough time
to fully pursue this second objective. The phase was done parallel to the second phase during
the last weeks
Just like the two previous phases, the method was to study the problem by reading
documentation and asking IT professionals and other employees. At this time I had started
to become more of an expert of the systems that were being used. I therefore more quickly
grasped the problem, which basically was that the accounting system would use other
organisational units than the controlling system.
4.2 Results
The study resulted in a request to introduce a possibility to analyse the same organisational
units in the controlling component and the accounting. A detailed description of how to
constitute the organisational units were given to the IT department. I tried to do some
documentation so that the next project student, that would pick up where I left, would more
easily understand the problem.
User oriented implementation of an enterprise system component Per Magnusson
28
5. Observations and analysis
5.1 Observations
During the project, the world of enterprise systems became a bit clearer to me. Instead of
just being a researcher, coming from the outside to observe, I was involved in a real world
project. I did not have prior experience of enterprise systems which meant that I had to
learn the systems from scratch. On the other hand, my engineering major in software
design was probably an advantage for understanding the systems more easily.
Significant to my project, was that the actual implementation had already been done. The
focus of my project was to configure the controlling component and adapt it to user needs. It
seemed like an implementation of an enterprise system never finishes. Renault Trucks
probably had more people doing smaller and larger maintenance, than people doing new
implementations.
The enterprise system is very inter-connected with the real world. The processes in the real
world should function in accordance with the processes in the system. One of the classical
questions of Enterprise Systems is in fact: is the system adaptable to the organisation or is the
organisation adapting itself to the system (Guffond et. al). This question is too advanced to
be included in this thesis. I observed however, that as a newcomer, I neither understood how
the organisation worked nor the enterprise system. It struck me, that the enterprise system
was a complex system that was hard to understand and to put in a relation with the real-
world organisation. The enterprise system felt like a database client, that had been design
with small concerns on usability. If the graphical interface were to be better designed, I
believe that it would be easier to 1) understand how the organisation functions with the help
of the system, and 2) understand the actual system itself. This issue is further analysed in
2.5.3.
Apparently, it was difficult to promote change in a large organisation like Renault Trucks.
The organisation of the IT department was not efficient in handling the requests of the FC.
User oriented implementation of an enterprise system component Per Magnusson
29
This meant that time was lost. If this time is added to the additional time of the extended
first phase, it is understandable why there was never much time for the third phase.
I cannot claim that it helped to be a foreigner either. I did not speak a fully fluent French
and did not fully blend in to Renault Trucks’ and the French culture. In the end of the
project however, my French had become much better and I had a much more varied and
fluent language. I never really got used to French culture though, where conflicts were just
as natural in everyday life as drinking coffee. I felt that there was a lot of talking behind
people’s backs and I did not really enjoy the working environment. I think that this had a
negative effect on my performance.
As a final observation, it was obvious that BW and SAP were creating frustration among
users. Instead of being the masters of the system, they were rather mastered by the system
and had to adapt to it. The users had to follow the development of the system and the
rigidity of the enterprise system made it difficult to change, even to understand. The
employees in the FC were no IT professionals or even expert users. Their traditional
professional role was to analyse the profitability, not to design queries. The question that
arose was: is it possible to simplify the enterprise systems and make them more
understandable? Or is the professional role of the employees changing, to become much
more oriented on the usage and management of information systems?
User oriented implementation of an enterprise system component Per Magnusson
30
5.2 Sociological and organisational aspects of enterprise systems
As observed, it seems like an implementation of an enterprise never finishes. Davenport
(2000, p.132) supports this when he claims that the enterprise systems should be seen as a
way of life. This means, that after the actual implementation, most firms will continuously
have to make changes to the system, to make it fit organisational changes and to bring new
business units into the use of the Enterprise Systems. Davenport also writes about the need
for prototyping and piloting when installing enterprise systems. Just as important as getting
the system installed and having accessible data is to assure the daily use of the system. A part
of my project could have been avoided if there had been more prototyping. On the other
hand, as Davenport points out, prototyping takes time and consumes resources. He also
reflects on information needs. When organisations put in ES they rarely reflect on which
information they want to extract from the system. They often use the same information as
they did with their old mainframe/legacy systems. In this sense, there is little value adding
caused by better decisions made with new and more proactive knowledge from the
enterprise system. The business logic for implementing SAP was however that of a project
of integration. It was never intended that SAP’s capabilities as an advanced decision support
system would add value. Renault Trucks seems to have been fairly successful in their
implementation of SAP. They have not experienced a failure like that of MG Rover
described in the subject introduction.
It is obvious that enterprise systems take a very important role in many businesses, especially
the spare parts business. Take the case of MG Rover once more; the failure of an SAP
implementation was the major reason for the destroyed profitability. Suzi et al. who
suggested that the biological theory of stigmergy could explain ’artefact-mediated
collaborative activity’, seemed to have a point (see introduction to subject). The co-
ordination paradox was apparent, i.e. the connection between the individual and the societal
level: looking at the behaviour of a group of social insects, they seem to be co-operating in an
organised, co-ordinated way, but looking at each individual, they seem to be working as they
were alone and not involved in any collective behaviour. The normal user was sitting in
front of a computer screen and had no idea where the data came from. The enterprise
system on the other hand was at the very heart of the company, and appeared to be the hub,
User oriented implementation of an enterprise system component Per Magnusson
31
around which everything evolved. The framework of distributed cognition also seemed to
be applicable to the first phase. It appeared to be a cognitive system in the organisation that
consisted of people and computer systems. The representation of knowledge was definitely
not just inside the heads of individuals; the knowledge was rather a collective representation
that was created with the help of the enterprise system. This relates to the vision of
knowledge management by Davenport (see introduction to subject). Davenport meant that
in the future, the interaction between systems and humans become more collaborative and
the system acts as an extension of the human ability to store and process knowledge. It is
basically about letting the systems do the complex analysis and leave the decision-making to
the humans.
User oriented implementation of an enterprise system component Per Magnusson
32
5.3 Human-computer interaction aspects of enterprise systems
Because of the importance of the enterprise systems, users are frustrated when they do not
understand the systems. This became very obvious during the project. The systems were
complicated and the question is: is it possible to simplify the systems and make them more
understandable by improving the graphical interface. This will be the first point of analysis.
The second will be to ask how applicable the theory of Norman are to enterprise systems.
Is it possible to improve to make the systems more understandable by improving the
graphical interface? I believe that a system becomes more understandable if it follows
established design guidelines. Such established guidelines are Schneidermann’s eight golden
rules. To me, it seems natural, to deduct, that basic things such as striving for consistency
and other rules will simplify the system usage and make them easier to use. The following
paragraphs will describe how well SAP R/3 follows each of Schneidermann’s eight rules.
o Strive for consistency
The SAP R/3 graphical interface is fairly consistent. There is the feel of having a
static interface, which you can use to connect to the central database in several ways.
o Enable frequent users to use shortcuts
There are shortcuts in SAP, so called transactions. By knowing a certain code, for
example SM37 you can directly access a certain mode, without doing the usual four
or five commands in the menu. It is however a bit hard to remember these shortcuts.
o Offer informative feedback
The feedback was fairly poor. This could be due to a certain level of customisation of
SAP, and that this issue was not handled when the specific implementation was done.
o Design dialogs to yield closure
It is not always very clear that there is any processing going on as a result of user
commands. This area can therefore be improved.
User oriented implementation of an enterprise system component Per Magnusson
33
o Offer error prevention and simple error handling
I believe that there are some basic error handling in SAP but did not work so much
with these issues.
o Permit easy reversal of actions
Actions seemed to be fairly reversable for the user. However, previous states were
not always saved, which meant that the reversal of time-consuming processes was
slow.
o Support internal locus of control
To support internal locus of control means that the experienced operators sense that
they are in charge of the system and that it responds to their actions. After working
with SAP for 6 months I cannot say that this was the case. It is a complex system,
and to really master it, one probably has to learn more about it. On the other hand,
it was difficult to learn or to figure out the required sequence of actions to perform a
task. I therefore believe that this point could be improved.
o Reduce short-term memory load
As stated, the user often had to execute a sequence of five actions in the menu bar to
accomplish a desired state. This means that the user has to keep track of where she is
during this sequence, which is not always easy.
As examplified above, there are many possible improvements for SAP R/3 in order to be
consistent with Schneidermann’s eight design rules. Howie et al. provided guidelines that
were more applicable to software that tried to show real-world systems. The results of their
testing of these guidelines were perhaps not a big surprise. Certainly, a well-designed
interface improves learning and understanding. The interesting thing is that with the help
of the interface, it is possible for people to make a more accurate mental model of the
underlying system that you’re trying to manipulate and analyse with the help of the
program. I believe, that this applies to enterprise systems. The graphical interface should be
designed to help people develop a more accurate mental model of the underlying real-world
system. Each point of the framework applied to SAP R/3 is described below. As shown,
there are numerous points that can be improved.
User oriented implementation of an enterprise system component Per Magnusson
34
o Wherever possible, take advantage of people’s natural tendencies (e.g. reading from left
to right and from top to bottom)
As stated, SAP is fairly consistent and there are perhaps not so many points to
improve in this area.
o Present information in a graphical, rather than just a text-based, fashion to exploit
people’s powerful pattern-recognition capabilities.
SAP R/3 is not so supported by graphics. It would probably be easier to understand
the system if the information was presented in a graphical way, for example to
described how the organisation functioned. One essential process in most companies,
the invoicing process, could for example be described by the graphical interface
o Show, not just data, but also relationships between data so that people can develop a
more accurate mental model of the simulation.
This would be desirable in a decision support system, like the controlling component
that I helped to configure. In the actual system it was fairly vague where the data
came from, and how it had been accumulated. It was possible to list the invoice
numbers that constituted the total sums. It was however difficult to understand how
to do this.
After having analysed SAP R/3 with Schneidermann’s and Howie’s rules, I conclude that
there are several improvements that can be made with the goal make the systems more user-
friendly. It is of course hard to prove that the systems will be more simplified and
understandable if the design guidelines by Schneidermann and Howie were followed, but it
seems natural to assume that.
The second point of analysis is how applicable Norman’s model is to enterprise systems.
Norman recognised in his model that the system image is more than the graphical interface
and the uses’s manipulation. Education and documentation also set the system image.
During my project, I realised that the enterprise system, the organisation and its actors
interplay. Norman’s model does not currently consider the organisation as a variable. I
therefore believe that Norman’s model has to be adapted for enterprise system, by
User oriented implementation of an enterprise system component Per Magnusson
35
recognising the importance of the environment that surrounds them (see figure 5.1). When
I came to Renault Trucks for example, I did not know the systems or the organisation. One
way for me to learn more rapidly was to learn about the organisation through the system
and vice versa. Of course, there has to be some resemblance between the system and the
organisation. If the organisation is very different from the system, the user can perhaps be
mislead by how the organisation functions. The organisation becomes in a way therefore a
part of the system image. If the system and the organisation function in different ways, it
may very well lead to inefficient usage.
The reasoning above relates to the question wether the system adapts to the organisation, or
the organisation adapts to the system. So far in the history of enterprise systems, it appears
as if it is more common that the organisation has been ’re-engineered’to fit the systems
(Davenport 2001). However, enterprise systems can be configured to a certain level to fit
each organisation (Guffond et al. 2002). It may seem difficult to adapt the graphical interface
to each configuration of the system. One easier way could be to adapt the documentation
and the education to the organisation. This was more the case for Renault Trucks. The
company had specific documentation for their implementation.
User oriented implementation of an enterprise system component Per Magnusson
36
Figure 5.1 The organisation should be introduced in Norman’s model when it is applied toenterprise systems. If the system and the organisation function in different ways, it may leadto inefficient usage.
Organisation
System Image• Documentation• Education• Graphical
Interface• Manipulation
Possible differencesbetween conceptual
models
User• Former experiences
Mental Image(User’s
ConceptualModel)
Designer• Communicates system
functioning throughsystem image
Real System(Designer’sConceptual
Model)
Possible differences between organisation and conceptual models
User oriented implementation of an enterprise system component Per Magnusson
37
6. Conclusions and recommendations
6.1 Conclusions
Enterprise systems seems to be a way of life, which means that they continuously have to be
configured and modified. They take a very important role in the organisation and they may
create frustration for the users who do not master them. The human-computer interaction
could be largely improved for enterprise systems, for example by applying Schneidermanns
and Howies recommendation for how to design the graphical interface. Normans model
could be applicable to enterprise systems, if it recognises the importance of the organisation
as a major influence when the user is forming her conceptual model of the system.
User oriented implementation of an enterprise system component Per Magnusson
38
6.2 Recommendations
Based on the conclusion, one recommendation to SAP is of course to improve the weak
issues in the graphical user interface. I must mention that I did not work with the very latest
interface. It is possible that SAP has begun to take the human-computer interactiom more
seriously.
It is of course important to recognise that the graphical interface is not the only way to
communicate the system image. System designers should not just follow established interface
design guidelines, but realise that documentation and training can help the user to get a
more correct conceptual model. Moreover, the organisation must be taken into
consideration when designing the systems and the system images. If there is a big difference
between the organisation and the system, it may lead to inefficient usage.
Finally, for Renault Trucks, I felt that there was a need for more documentation. A
substantial amount of knowledge was just inside peoples’ heads. This made it sometimes hard
to know, who to ask.
User oriented implementation of an enterprise system component Per Magnusson
39
7. References
Cooper R. & Kaplan M. (1998) The Design of Cost Management Systems, New Jersey, McGraw-HillPublishing Company
Davenport T. (2000) Mission Critical: Realizing the promise of Enterprise Systems, Boston, Harvard BusinessSchool Press
Dix A., Finlay J., Abowd G. & Beale R. (1999) Human-Computer Interaction, 2nd edition, London,Prentice-Hall
Doane M. (2001) The SAP blue book: a concise business guide to the world of SAP, London, Prentice-Hall
Guffond J.-L., Leconte G., Segrestin D. (2002) L’implantation d’un ERP ’Travaille’- L’Organisation (FR),Les actes du colloque Concevoir et organiser la performance industrielle, 193-202 English translation:Implementation of an ERP Work - Organisation
Jan T.-S. & Tsai F.-L. (2002) A Systems View of the Evolution in Information Systems Development.Systems Research and Behavioral Science vol. 19, 61-75
Howie E., Sy S., Ford L. & Vicente K. (2001) Human-computer interface design can reduce misperceptionsof feedback. System Dynamics Review vol. 16, 151-171
Lundeberg Mats (1995) A Multilevel Approach to Information Management, in: Dahlbom, Bo (ed.). TheInfological Equation: Essays in Honour of Börje Langefors, Festschrift, Gothenburg Studies in InformationSystems, Dept. of Information Systems, University of Göteborg
Norman D. (1998), The design of Everyday Things, London, MIT Publishing
Rubython T. (2002), Rover on the edge with caterpillar, Eurobusiness September 2002
Schneiderman B. (1998) Designing the user interface, New Jersey, Prentice-Hall
Susi, T. & Ziemke T. (2001). Social cognition, artefacts, and stigmergy!: A comparative analysis oftheoretical frameworks for the understanding of artefact-mediated collaborative activity. Journal of CognitiveSystems Research vol. 2, 273-290
Zhu Z. (2000) WSR: A systems approach for Information Systems Development. Systems Research andBehavioral Science vol.17, 183-203
Castelfranchi C. (2001) The theory of social functions: challenges for computational social science andmulti-agent learning. Journal of Cognitive Systems Research vol. 2, 5-38
Lane D. (2001) Rerum cognoscere causas: Part I - How do the ideas of system dynamics relate to traditionalsocial theories and the voluntarism/determinism debate? System Dynamics Review vol. 17, 97-118
Margerin J., (1992) Comptabilité Analytique (FR), Paris, Rigert, English tramslation: ManagementAccounting
Scott B. (2001) Cybernetics and the Social Sciences. Systems Research and Behavioral Science vol. 18, 411-420
User oriented implementation of an enterprise system component Per Magnusson
40
Thuderoz T. (1997) Sociologie des entreprises (FR), Paris, GUP, English translation: Enterprise Sociology
Xu D. (2000) The contribution of Systems Science to Information Systems Research. Systems Research andBehavioral Science vol. 17, 105-116