In this section four different systems will be described. The first is a conventional information system and the remaining three, routine manual systems. The nature of data processing and feedback in traditional systems will be examined after the first system is described and again for the three routine, manual systems after they are described.
The literature records many traditional systems, both computerised and manual (or a combination of both), that are universally considered to be information systems. One such system, used to process cash received from credit sales (Gelinas and Sutton, 2002), is described in detail below. This system typifies a widely used process for recording cash receipts:
Customers send checks (sic) and remittance advice to Causeway. The mailroom clerk at Causeway endorses the checks and writes the amount paid and the check number on the remittance advice. Periodically, the mail room clerk prepares a batch total of the remittance advices and sends the batch of remittance advices to accounts receivable, along with a copy of the batch total. At the same time, the clerk sends the corresponding batch of checks to the cashier.
In accounts receivable, the clerk enters the batch into an online terminal by keying the batch total, the customer number, the invoice number, the amount paid and the check number. After verifying that the invoice is open and the correct amount is being paid, the computer updates the accounts receivable master data. If there are any discrepancies, the clerk is notified. At the end of each batch (or at the end of the day) the computer prints a deposit slip in duplicate on the terminal in the cashier’s office. The cashier compares the deposit slip to the corresponding batch of checks and then takes the deposit to the bank.
As they are entered, the check number and the amount paid for each receipt are logged on disk. The event data is used to create a cash receipts listing at the end of each day. A summary of customer accounts paid that day is also printed at this time. The accounts receivable clerk compares these reports to the remittance advices and batch totals and sends the total of the cash receipts to the general ledger office (Gelinas and Sutton, 2002).
The common, defining characteristics of systems such as the one above have been distilled from observation and presented in previous work (Lederman et al., 2003). The features of such systems are those that clearly exhibit the hallmarks of the classical definitions of information systems listed earlier: systems that collect data and process it in conventional ways. Data in these systems has the following qualities:
Firstly, in such systems data is represented in symbol/object form, where symbols stored in a table correspond to objects in the real world, generally shown as records within fields, and indicate or signal potential manipulations that can be done in the real world. In a system such as Causeway, a table of customers would exist where a customer number and description of a customer forms a symbolic representation of a real customer that exists in the world and that can, for example, be given a new credit rating or a new account balance.
The representation of data is persistent. That is, such systems display stable data structures. This is seen in Causeway where there are fixed fields with stable meanings, and multiple tables each with fixed record structures. This leads to data being processed in a conventional way where records are transformed but a stable structure remains.
A third feature relates to the nature of processing. Users in such systems use these stable representations to determine the state of the world and then select the appropriate action. In Causeway, for example, a user might find a credit limit in a table and make a decision about allowing a customer credit. Change then occurs in the customer record as it is transformed to a new state.
Processing proceeds without significant consideration of the physical and social environment outside of the system but rather results from feedback within the system. The environment is not considered important for action. Nonetheless, action clearly proceeds and is significant to the rationale for the system.
The depiction of an information system presented in the Causeway example contains the idea that information is produced by the processing of data through set, planned methods and that the data will have the qualities noted above. In this sense the Causeway system is clearly an information system in accordance with traditional definitions that look for data, processing and feedback.
However, in presenting this case, our aim is to consider whether it exhibits universal qualities that allow it to be compared to routine, manual systems and whether there are common characteristics to be found in both types of systems. Can what appears in Causeway as data being processed to produce output and the resultant feedback leading to activity, be found to have some shared qualities with the features of routine, manual systems?
A description of three routine, manual systems is presented below.
An Emergency dispatch system for ambulances is described by Wong and Blandford (Wong, 2000; Wong and Blandford, 2001; Wong and Blandford, 2004). Emergency dispatch occurs in a difficult and changing context where it is essential to the process that operators are aware of the goings-on in and around the area being covered by the ambulances and are aware of the capabilities of ambulance control to respond to possible eventualities. The system is divided into two functional areas: call taking and prioritisation; and command and control of emergency ambulances. There is a single control room where radio operators sit on one side and dispatchers on the other. The call takers (allocators) sit in the middle.
The activity begins when calls for ambulances are received by a call taker and are keyed into a Computer Assisted Design system. This system produces a printed ticket that includes details such as the type of emergency, address of the emergency, the priority of the condition (e.g. a heart attack has priority over a broken leg) and a map reference. From this point, the system becomes manual as tickets are first handed to a telephone dispatcher who contacts an ambulance crew at the station and dispatches it, and then to a radio operator who stays in touch with the ambulances on the road.
Once the ticket is printed any status changes, such as whether or not the ambulance is on the way or has arrived, are recorded by hand on the ticket. However, these can also be indicated by where the ticket is placed on the allocator’s desk or by how the ticket is placed in the allocator’s box since:
management of tickets centres around the ‘allocator’s box’. This is a slotted metal box with each slot corresponding to a vehicle in the sector. The ticket assigned to a vehicle, representing the job to which it is currently assigned, is kept in the relevant slot. The ticket faces forward while the vehicle is on the call, and is reversed when the vehicle is returning to the station but available for dispatch. The box sits between the allocator and radio operator, where either may easily access it (Blandford et al., 2002).
In deciding which ambulance to dispatch, allocators often use cues from the placement and positioning of the tickets rather than the written information contained thereon.
Airports have traditionally used a largely manual system for air traffic control (Mackay, et al., 1998). The system is still respected and used in many places, and has longevity despite the drive for high-tech solutions in many airports.
The activity of landing a flight begins with a printed, paper flight strip containing a small area to record basic flight plan information. This includes ‘airline, flight number and type of aircraft as well as the requested and authorised flight plan (speed, level, route, with expected times for particular cross points)’ ( Mackay et al., 1998). The system is routine and has an air traffic controller seated in front of a table of such strips. The strips are generated either by computer or can be hand-written in the absence of a working computer system.
Each airport has several air traffic controllers controlling different parts of the air space around the airport. The controller’s first task in the system is to remove the flight strip from the printer and insert it into a strip holder. Strips are continually picked up and put down, reordered, grouped, moved into columns, arranged and rearranged on the controller’s table to denote different traffic conditions. Strips are often offset. Offsetting provides a fast way of ‘indicating conflicts or setting reminders’ (Mackay, 1999). The placement of the strips in various configurations in relation to each other provides the controllers with information regarding action additional to what is written on the strips.
Once a controller takes control of a flight strip the controller gradually adds markings to the typed strip. The markings allow controllers to look at a group of flight strips and quickly select the ones coming under their control as well as giving other information about how the activity is progressing. The layout of strips also gives a controller an immediate appreciation of the control situation (involving many flights), thus helping the controller to select the next action. For example, a controller can see at a glance that a strip holder is full, and can also see the strip holders of adjacent controllers and monitor their activities without interrupting them. As the landing progresses the flight strip passes from one controller to another by physical handover that by its nature is palpable for both controllers. Often controllers are side-by-side, thus facilitating handover to another sector by structuring the area to help the activity.
Our third routine manual system is in the intensive care unit (ICU) of a 360–390-bed acute tertiary referral hospital. The intensive care unit has 24 beds, including 20 Intensive Care beds and four High Dependency beds
The system is a resource allocation system that monitors the movement in and out of the ward, and condition, of ICU patients. The goal of the system is to allocate beds as well as to manage movement in and out of beds in the short term.
The utilisation of beds is recorded on a whiteboard, which operates in the highly dynamic environment of a busy public hospital with a constantly operating admissions procedure presenting patients to the system. The whiteboard displays a picture of the bed cubicles, some or all of which may be occupied by patients, and a set of artifacts including magnets and stickers that indicate and describe bed usage. The board is located in a central position in full view of the beds that it depicts. It is positioned in such a way that it can be viewed simultaneously by a number of staff.
The board is designed with a large rectangle in the middle representing the nurses’ station and with blank rectangles drawn around it corresponding to the position of each bed relative to the nurses station. There are 24 positions on the board, each representing one cubicle, and a set of magnetic name cards that can have patient names written on them. These name cards are erasable and re-usable. The name written on a magnetic card placed on rectangle 21, for example, corresponds to the patient in bed 21. Patient names are written on the name cards with coloured markers. A name written in blue marker is a cardiac patient and a name written in black marker can be any other non-cardiac patient.
In addition to the name labels there are coloured plastic magnets in groups at the top of the board. These can be taken and placed on particular bed cubicles on the whiteboard. An orange magnet means possible discharge from ICU, a green magnet means definite discharge, a red magnet means incoming patient, and yellow means the patient will receive no further treatment. Patients with red magnets may not have yet been allocated a bed but may be placed on a name sticker set to the side of the board. If a bed is allocated, the name sticker may be half on and half off the designated cubicle.
Users of the board, having different functions such as doctor, nurse, physiotherapist or chaplain within the ward, gather around the board to respond, both collectively and individually, to what it displays. Colours such as the blue for a cardiac patient allow a cardio-thoracic physiotherapist, for example, to instantly carve off her/his list of patients; many green magnets, designating patients ready for discharge from ICU, tells the managing nurse to start finding beds in the general wards; many yellow magnets for palliating patients tells the chaplain to prepare for many families requiring support. The ease with which the magnets can be picked up and swapped around facilitates formulating the solutions to many of the problems being addressed and redesigning patient discharge scenarios.
In these routine, manual systems elements manifest themselves in a very different way to that described in conventional information systems such as Causeway. In these systems the following qualities, which have been previously attributed to ‘situated’ systems (Lederman, et al., 2003), are evident where participants focus on ‘situations’ that only include features of the world that relate to the participants’ purposes (Agre, 1997). For example, a system participant might be interested in how much stock they could see on a shelf at this moment and the specific meaning that conveys to the participant concerned.
In routine, manual systems:
Representations depend on the situation in which they are used. So, for example, a card in an ambulance dispatch system may have a different meaning when placed one way in a dispatch box than when placed another way. These different meanings signal the need to manipulate other system elements and generate a response from the system that tells participants how to act.
Situations relevant to goal attainment can be represented temporarily when they are transitory. So, for example, a whiteboard for bed management in a hospital ward may use coloured magnets to express a situation where a patient ‘may’ be discharged. We see this in the ICU ward with an orange magnet, or sometimes two orange magnets to say, ‘maybe, maybe’. The data expressed is not binary — where a patient is either ready for discharge or not — but an aspect of a changing and transitory situation. The data is not crisp or permanent but is instead fuzzy. Yet it has a valuable place in indicating a need for some development, such as a bed re-allocation, to take place that transforms the state of the system.
Situations are triggers for reactive rule-like responses. In such systems, situations can be perceived directly. This direct perception can be considered akin to processing, but does not require reading or significant cognitive activity where rules have previously been learnt. Consequently, a development in the system occurs where actors respond automatically to the positioning of items, such as tickets laid out on a desk or different coloured magnets placed on a whiteboard. This leads to further changes in the situation at hand, with such changes being part of the rationale for such systems. That is, these triggers manifest themselves to inform action, to tell participants what to do next.
The structuring of the social and physical environment of the system is important. In typical information systems all the data required is contained within databases or files that form predefined components of the system and the outside environment is of minimal importance. In these systems, however, aspects of the environment contain cues that are instrumental in triggering activity leading to consequent transformation within the system. So, for example, in the air traffic system a number of controllers grouped together talking intently can tell another controller that there is a problem requiring action. What leads to a response or action is separate from the actual information written on the flight strips. Rather, situations such as the placement of the strips, the arrangement of people in the room, or the number of strips in the strip board is significant for action. Because of this, these systems have evolved in ways that facilitate the inclusion of such factors — with rooms designed, for example, in ways that system participants can see and take advantage of available cues.
These three systems, while very different to the Causeway system contain many situations that signal the need for action. These situations occur and are developed in some way through the manipulations of system participants, with these new developments promoting further responses. The term development is used here to refer to a stage of growth or advancement (Australian Oxford Dictionary) where a practice is made active by successive changes (Webster’s Dictionary). Whereas processing is present in traditional systems, in these systems situation development is observed directly and leads to a subsequent response from system participants. So, for example, where an extra magnet is added to the ICU whiteboard there is a growth in the information value of the board in the same way that processing traditional data in a spreadsheet is said to produce information. Such changes, or developments, activate the new situation in a way that encourages response. However, while these systems are characterised by ‘situation, development of situation, new situation, response’ whereas in traditional systems it is ‘data, processing of data, output, feedback’ we suggest that these differences may be superficial. In the next sections we consider whether there are qualities in both types of systems that are universal and make it possible to unite all systems under a common definition.