PACT Analysis of Fleet Control System

1 Introduction
In this report we are going to analyze a Fleet Control System for small to large companies deployed at Shell
Denmark. The main goal is to present and focus on the two most important roles - the administrator, who
manages and controls the system and uses it from time to time as a tool, and subcontractors who are the
primary users of the system. Throughout this report a user will refer to anyone using the system - either
an administrator or a subcontractor in our cases. We have chosen two dierent subcontractors - Fjellerad
and Hoyer - to have better understanding of dierent needs and to be able to compare their usage of the
system, since they use the system for dierent things.

Shell is one of the biggest petrochemical companies that distributes gas and oil, and it is them we have
made contact with. From them and their contractors we will get information about how they currently use
the system, which are then going to analyze and suggest improvements on.

Before we describe the system that is used by the Shell and its subcontractors, we should explain what
the Fleet Control System is. Basically it is a system that allows the tracking of vehicles currently on the
road, as well as some ways to interact with these. However, the system we're going to look at is already in
production, and is called Mobile Workforce System (MWS). One of the most important things is the fact
that it includes a system to dene Black Spots as places in Denmark where the road is dangerous. Black
Spot system allows you to dene dangerous places and warn the drivers either to be even more careful on
these parts of the road. The road can be dangerous because of the temporary reasons like the bad weather
conditions, construction on the road, car accidents and so on, or because of permanent reasons, like extraor-
dinarily sharp turns. Furthermore, only drivers can decide on which one part of the road should be marked
as a black spot. The system also includes a close to real time map of the positions of all the individual
vehicles in the controlled eet, and it displays the most relevant information about a vehicle (for instance
speed) if it is needed. Mobile Workforce System is used in typical oce environments, and is used now
and again to complete certain tasks. One could imagine it being open all the time simply so as to easily
have an overview of ones eet, however. We shall also be looking into how to add a tie-in with an adminis-
trative system, and how to display relevant information from this in a structured and non-overwhelming way.
2 PACT Analysis
The following is a preliminary PACT analysis of a Fleet Control System used by Shell.
We will describe how the PACT points look today, and at the end of each of these subsections, we will give
a short description of possible changes.

Shell is a multinational company dealing in oil for dierent applications. Using the system is a multi-
tude of user groups: secretary's, costumer service center (CSC) sta, department heads, administrators,
subcontractors and more. We've focused on 2 user-groups: the administrator and the subcontractors.
The administrator group is a very small group currently only consisting of 2 people who can be considered
to be expert-users of the system. They stress that for them the system is simply a tool to be brought out
whenever they need to complete certain tasks. The subcontractors also use it as a tool, though with dierent
aims in mind: Their chief concern with regards to the system, is to create, maintain and delete Black Spots.
For the administrators, all of these tasks are invoked by some outside occurrence - for instance someone
complaining a shell-truck hit their car, or a very large costumer needing to know when their deliveries will
arrive.

Following is a list of the tasks an administrator may be asked to do:

• In case of someone calling CSC complaining a Shell-truck damaged their car, an administrator may
use the system to check if any trucks were near the site at the time in question

• In case of a audit of a subcontractor an administrator may be asked to export an excel-sheet containing

relevant information about one or more drivers. (Speed, position and so forth).

• Add users to the system

• Check if any of the users in the system have outstayed their welcome

• Send reminder of user passwords to a user

• Help investigation team retrieve data for investigating a large accident

• A large costumer asks for the estimated time of arrival (ETA) of their supplies

The subcontractors mainly just maintain and use the Black Spot system. That means:

• Create new Black Spot when drivers report one

• Create new Black Spot where there's roadwork

• Update Black Spot if it does not do what intended. (i.e make it bigger to ensure a truck will get the
message, and not just drive through)

• Delete Black Spot if it's no longer needed. (i.e, when road work has been completed)

2.1 People
The users we will be considering are administrators and contractors.
The administrators are likely well-educated or self-taught to a high degree, but contractors cannot be ex-
pected to have a high knowledge of computer systems in general. The contractors are very much like the
administrators in this respect, however it's safe to assume the contractors will only have a good knowledge
about the exact part of the system they're working with. It should also be noted that even though the
contractors chiey use the system to create and maintain Black Spots, this is perhaps a monthly occurrence,
and should thus be considered infrequent. To this end, one should realize there are a great many dierences
between people using this system, but also the great many things they have in common - for example the
context in which they use the system, namely in an oce. An oce is in many ways a very benign environ-
ment, and so few issues need to be considered about the people involved. Colour-blindness obviously needs
to be considered, however there are no other special needs to be considered, that should not be considered in
any other system meant for a desktop computer. The system is to a large extent a tool with which to solve
certain tasks on demand, which means it won't be constantly in use like, say, an administrative system, so
the system needs to support non-regular users. We have observed that the administrators using the system
to a very high degree use a priori knowledge when completing certain tasks - for instance they usually know
that if a member of the public complains a Shell truck hit their car and dented it, which trucks are possible
candidates without referring to any sort of database. Though this can naturally be exploited, we should
be careful about assuming this goes in other environments as well - with a larger eet this may not be possible.

We believe the system could be redesigned when it comes to exploiting the a priori knowledge of the ad-
ministrator. You cannot assume that it will be possible to remember specics about trucks in a larger
setting.

2.2 Activities
An administrator may have to perform the following activities:

• Finding out if any trucks have been in a specic area at a specic time

• Export information about a specic truck, such as speed and position over a period of time

• Manage users

• Check when a truck will arrive at a costumer

Finding out if any trucks have been in a specic area at a specic time is temporally ([Benyon et al], p.
33, point 1. From now on referred to as 2.3.1) infrequent, but usually a continuous task. However if the
administrator needs to check many truck, this can take quite a while, and so he may be interrupted by other
duties (2.3.3), as with all the activities.
The response time (2.3.4) needs to be relatively short as the administrator may need to check several
trucks, and is, like other activities, undertaken alone (2.3.5). This task is very well-dened to the point of
being alogrithmicable (2.3.6), and like the other tasks is not safety-critical. (2.3.7). Exporting information
about a truck are again infrequent, and like all the other activities time pressure and such is largely irrelevant.
A higher response time than other parts of the system can be allowed here due to the activity being infrequent,
and not requiring a lot of interaction. The task may be vague or well-dened, depending on what kind of
information the administrator receives. The more specic information he gets in regard to timing and
location, the more well-dened the task becomes. This is also the only of the administrators activities that
can be considered somewhat safety-critical - since these exports are used to determine the causes of accidents,
studying them may prevent accidents from occurring in the future.
We won't discuss user management further in this report, There are other tasks which are managed by
other user classes - for instance subcontractors are responsible for maintaining the Black Spot system, and
only drivers can dene black spots by phoning in or using their On-Truck Computer (OTC). and so won't
go into details about managing users.
Checking when a truck will arrive at a costumer is hard to classify as either often or infrequent, but
suers greatly from peaks and time pressure. (2.3.2) Especially, in case of a snowstorm many requests for
information like this will be received, and the answer needs to be found within 10-15 minutes at most in
order to be relevant to the costumer calling. In order to avoid requests such as these piling up in a worst-
case scenario, the response time of the system should be low enough to not cause any problems. However,
currently the work-ow is a greater problem than response time is this concrete scenario. This is also the
one task in which the administrator needs to cooperate with someone else: in order to check what delivery
a truck is currently making, he'll have to contact a scheduler in order to receive information about which
truck might be on it's way.

For the contractors the whole thing is somewhat simpler. Their chief activities - adding and deleting Black
Spots - are infrequent, and not under any great time constraint, though a Black Spot should of course be
added as fast as possible. Black Spots are safety-critical in a certain sense, though, as they in the long run
prevent many accidents, however it cannot be said that a mistake in the process will necessarily lead to any
sort of injury or other serious repercussions.

Though the system currently supports most of the activities very well, there are some critical aspect that
should be improved on. For instance, if the current work ow for nding trucks that have been in a specic
area at a specic time is maintained, the response time of the system needs to be signicantly lowered.
However, a better choice would be to create a better work ow for solving this task - for instance a sort of
Black Spot system could be used to dene an area of interest, and some dialog to dene a time of interest,
and the relevant trucks could be found almost immediately.
The system should also be more focused on feedback and errors. Specically, when entering the the time
and date for retrieving the positions of a truck, there is no error if the format is wrong, nor any feedback
that the system is working when the format is right! And because of the infrequent nature on creating Black
Spots, this process seems to be somewhat counter-intuitive to some users, as well as quite cumbersome. In
addition, the system does not currently support time-limiting Black Spots, or auto-importing Black Spots
from pages listing them on the web. It would be obvious to add these possibilities to the system, however
their inclusion may be a matter of company policy (as is the case at Shell). With regards to delivery time,
there should be no large technical problems in having this information present and available in the MWS,
thus cutting signicantly down on the complexity of the task, as well as the time needed to complete it. The
dependency on other people in this respect seems unnecessary.

2.3 Contexts
Physically, the context of this system is a typical oce environment, thus there are no exceptional require-
ments for the system.
Socially, there is again little to say. The users we're considering are the closest to experts on the system
that the company has, and so needs little help. The contractors, if in trouble, will call the administrators
and have them help them, so support is never too far away.
Organizationally there are more points to make. First of all, there is a clear power structure in Shell
which is exploited when implementing the security measures of the MWS. Security is a prime concern to
Shell, and the restriction of access to condential data is based very much on the hierarchy within Shell.
There's no mentality towards basing security on trust, thus making the security of the system very tight,
but also fairly rigid.

Though the focus on sharp distinction between user-classes in the shell power structure is excellent se-
curity, it does limit the exibility. For instance, there's no way a Call Center employee would get access to
the data needed to perform the task of checking trucks positions at a certain time in the past, though they
could probably do in order to alleviate the administrators.

2.4 Technologies
Small to medium amounts of information needs to be entered by the users - addresses, names and so on -
which indicates a keyboard as a necessary tool. Also, in order to select vehicles and navigate, some sort of
menu-structure will be required. For this, a mouse-keyboard combination is again the natural thing to use.
Communication happens via either an internet connection, or through phone or suchlike.
The content of the system is updated every 30 seconds on the server, and is both well-presented and
up-to-date. This goes for the current data represented on the oce workstations as well but when requesting
data going back - e.g. tracking for a truck - this puts a lot of strain on the communications and results in a
very long response time.

One could of course consider other options - for instance touch-screens or some form of PDA access but
this would be more interesting for the truck drivers and they bare not the focus of our assignment. If we
were to suggest improvements in the input output section we might mention things such as projectors or
large touch screens for easy overview of the status for the administrators. One might also consider voice
recognition for comfortable and fast access to the system, but this is still not at a stage where anyone would
gain anything from using it without rst training it for hours and hours, not to mention that the system is
used too infrequently for this to pay of. With respect to the subcontractors, the economy might set rm re-
strictions on the technologies involved, and it seems more realistic to assume the keyboard-screen interaction
for a while to come.

3 Contextual Inquiry
In the following section we will analyze the tasks undertaken in this system, using the dierent models from
Benyon et. al sec 18.4-18.8 in order to gain a better understanding of the work ow involved and a better
framework for improving the system.
We were not always able to perform the traditional type of Contextual Inquiry described in Benyon et.
al., section 18.2. This is due to the fact that the system mostly used after outside prompting - it's simply
only used on demand. Since we did not have the luxury of waiting for this to happen, we instead created as
real scenarios as possible for the administrator to work on. These scenarios was then undertaken like a real
task, and we observed, took notes, and asked questions in the manner prescribed by Benyon. In the case of
forks in the scenario, these were explored fully.

3.1 User Stories

3.1.1 Story 1 - Collision

Claus gets called up by Anders from the Shell CSC. They've just talked to an angry man who claims a Shell
truck dented his car. Claus wants to check if it's possible by looking at the positions of the Shell trucks
within the timeframe given to him by the angry man, through Anders. Claus opens Internet Explorer on his
computer, and goes to the website the MWS is accessible from. Waiting until the system is fully loaded, he
uses the menu-system to the left, to select Medlemmer and scroll down the long list until he nds the rst
truck he believes could be responsible. He then drags the trucks icon in the menu onto the map in order
to show only that specic truck - it takes him a few tries to manage, though, since the system not always
captures the mouse-event. Once only this one truck is shown on the map, he right-clicks the trucks icon on
the left, selects egenskaber from the menu, and from the pop-up window that appears, he chooses Spor.
He then chooses the option Use my settings, and inputs begin/end date and time he got from Anders,
in two more or less free-text input-elds. He presses OK to save his choices, and the pop-up disappears.
After a while, a series of dots will appear on the map indicating where the truck has been, and by hovering
over these dots Claus can see the time the truck was at that specic position. Claus determines this truck
could not have been responsible, and starts all over with dragging a new truck onto the map and repeating
all the other steps to get the positioning data from the truck. After having checked 4 trucks, Claus can say
for certain it could not have been a Shell truck who caused the problem, and calls Anders back to tell him this.
This scenario is illustrated in Sequence Model 1 - Collision.

3.1.2 Story 2 - Creating a Black Spot

Jakob gets an OTC report of a Black Spot near Nakskov. He prints the report, and starts the MWS.
Because he does this fairly rarely, he's not sure where to press in order to start making a Black Spot. He
nally right-clicks on the Zones icon in the left menu, and chooses New Black Spot. The screen changes -
a Black Spot lling half the currently visible map appears, as well as a small toolbar in the top-right corner
of the map. The toolbar contains 2 buttons - accept and delete Black Spot. At this point, Jakob realizes
he's just placed a Black Spot covering half of Jutland on the map. It's not active yet, luckily. He gradually
zooms in on the spot he wants to create the Black Spot at, but slowly, a bit at a time, so he can drag the
Black Spot smaller at each step. Having zoomed in suciently, Jakob starts to manipulate the Black Spot
into covering exactly what he wants. Due to the infrequency of creating Black Spots, he does not remember
how to break the sides and thus creating new edges to drag. The Black Spot ends up being larger than
necessary, and rectangular.

3.1.3 Story 3 - Cleaning up Black Spots

It's the end of the month, and Jakob is going through all the Black Spots he recently created (in the last
few months) by memory. He's looking for Black Spots that are no longer relevant - maybe there's no more
construction on the road, or maybe the road's only dangerous in the winter. Though he can get a list of all
Black Spots, he prefers to do it by memory, since there are so many. He's slightly irritated that Black Spots
for which he knows the duration (as in the case of roadwork) still needs to be removed manually, rather than
automatically. He would also like to be able to import Black Spots from publicly available lists rather than
make them himself. Instead, he creates them one by one.