Solutions - Systems Analysis

Introduction

There are many reasons why scientists, engineers, operational analysts and others need to describe the operations of systems of combinations of users and equipments.  During organisational studies it may be to understand better the impact of organisational options while during equipment upgrade studies it may be to understand the impact of equipment change. The example provided is based on original work by Mike Tainsh into task descriptions in the context of operational systems. It will serve not only to demonstrate the systems approach but also some of the benefits of TaskArchitect 2.  The analysis can be reviewed as a TaskArchitect file by downloading the example file at the bottom of this page and installing TaskArchitect 2, Viewer Edition.

In this example, users is taken to mean any participant or groups of participants who will be carrying out any operations (job, task or activity, and equipment means anything from a hand held device (or smaller) to large scale plant, or remote system. The users and equipment in this context are both categorised as system components. Whatever the reason for generating a description, the work will start typically from a high level or partial description. This will be expanded in scope or detail in accordance with the demands of the project. These demands may include operational importance or safety requirements.

The operations associated with each of the participants is described so that the characteristics of the whole system can be considered from a variety of points of view. The aim may be to optimise the performance of the system by means of assessments and evaluations. Alternatively, it may be to characterise the system as part of a procurement programme.

The timelines are vital when considering the design and performance of many contemporary systems. Issues of control or automation may be raised, particularly for networked systems where optimised performance many be critical to success. In this context it may be vital in many applications to consider both the flow of communication along a time line and the communications between participants.

The Systems approach

It is clear from experience in systems engineering and operational analysis over the past thirty years that systems descriptions need to have at least the following important characteristics:
1. they need to be comprehensive, to cover the total scope of the system components and its operation;
2. the functional characteristics can be described in a number of levels of detail;
3. the process characteristics can be charted to show sequence and influence with respect to the endpoints/goals of the system;
4. the interactions (including control loops) between the process components e.g. tasks or activities can be charted;

The descriptive technique must apply equally to all systems components: users and equipments. Further it must be able to cover all operations. The hierarchical characteristics are essential in helping to understand the relationships between levels of operations i.e. low level activities and higher level tasks or jobs. The chart of the process characteristics will enable links to be made from start conditions to goals. The interactions are vital as they may include communications, speech, information and knowledge transfer. At a low level i.e. when describing activities they may include cognitive processes which at a higher level they may include management arrangements, and further on they may include strategic issues and policy decision-making.

Human Factors and a multidisciplinary approach

The systems approach is essentially multidisciplinary. Work in this area has been developed to help bring together the contribution of the various disciplines that may be brought to bear on a problem. Human factors/ergonomics is a discipline that is often used with the systems context and hence would both contribute to the development of diagrams, and work from them e.g. using time, error or workload considerations.

The use of TaskArchitect 2

This hypothetical example is constructed to show how a systems description might be addressed. It will demonstrate the use and some of the benefits of TaskArchitect 2.

Search and rescue example

The example provided is entirely hypothetical. The components, the operations and their characteristics are chosen for ease of demonstration. The search and rescue includes seven participants/groups of participants with a variety of equipment or other items that will influence the final outcome:

1. Local radio
2. Coastguard
3. Ambulance
4. Rescue craft
5. Accident and Emergency hospital
6. Survivor on damaged craft
7. Survivor’s family/home
8. Friends, neighbours and others

The search and rescue scenario involves one holiday maker who goes from his family home, to the shore and onto the open ocean in a sailing dinghy where he gets into difficulties as a result of poor weather. He makes distress call on a mobile phone to the local coastguard and a rescue vessel is tasked to bring him to shore where a waiting ambulance takes him to hospital. The local radio is informed so that the local community is made aware of the situation.

The purpose of describing the incident is to ensure that any lessons can be learned to improve the response of the emergency services and others involved.

The Use of TaskArchitect 2 for initial work on the search and rescue scenario

Stage 1- Generating the list of participants

The first stage for generating the description is to list the participants who will be operating at the highest levels. Allowance should be made for consideration of others who will be placed with the diagrams in due course. These should be created as values of the property ‘Role’ and entered on the Tabular View so that a list can be understood and agreed. Figure 1 provides a typical Tabular View for the set of participants associated with this scenario.

Stage 2 – Generating the list of processes

Then the list of major processes that each participant will experience/undertake should be generated on the Tabular View. At the very highest level the process may be written down as operations for all participants. Even at this early stage it is necessary to be aware that decomposition of high level processes is taking place and may be continued to additional levels of detail. Figure 1 proves an initial statement of operations for two levels of decomposition.  As the system is further understood these descriptions can be edited or dragged to the correct location in the analysis – the data is moved automatically and all diagrams are refreshed at once.

Stage 3 - Properties

The list of properties (description of further information about things in the system) for participants and equipments needs to be developed, and the properties assigned. This needs to be carried out with care as it will directly influence the timeline. Illustration One includes durations and sequencing information in addition to the properties of the communications (role, communicates, type of process). Up to 100 properties can be rapidly defined then entered using point and click in the spreadsheet like Tabular View or Task Details window.

Stage 4- The timeline

Part of the timeline is shown in Figure 2. This may be enhanced with the use of Task Highlighting to enable greater understanding during the assessment and evaluation.  Task Highlighting automatically colours or changes the shape of tasks if they fit the definition of the data assigned to the highlight.  This means that the data drives the diagrams and doesn’t have to be manually redrawn or checked as aspects change.

Stage – 5 Assessment

The assessment of the system characteristics in this example may include:

1.effectiveness with emphasis on decision making and time to complete important tasks;
2.safety issues associated with critical tasks such as moving the holiday maker from his dinghy to the rescue vessel and from the vessel to the ambulance;
3. wider issues might include the availability of ambulances and the time taken to reach the shore.

Stage 6 - Evaluation

The assessments may be compared against policy or operational guidelines to infer whether the organisation has met performance or other requirements. Typically operational effectiveness issues may focus on the Coastguard planning and decision processes along with the assignment or resources, whereas safety issues may reflect on the hazards and patient safety issues associated with the ambulance and hospital. In all cases the use of TaskArchitect will support, enhance and speed these evaluations and provide a “Systems Approach”.

Benefits of TaskArchitect 2

In the past there have been two main techniques for supporting this class of task description: pencil and paper, and general purpose drawing packages such as Visio. The range of TaskArchitect editions, from a free Viewer application through the Standard size and up to Pro means that each person in the team can view TaskArchitect files as required and create analyses appropriate to their role.

Five main lessons can be demonstrated through the use of this example:

1. TaskArchitect Pro supports the description of up to 4000 tasks and 100 properties in a single file multiple files can be linked together. These characteristics supported the example well.
2. TaskArchitect makes it easy to manage and display many levels of data. This a substantial advantage for other current techniques.
3. Task hierarchy, timelines and link analysis in TaskArchitect provide the means of showing these processes relationships and interactions. These were essential during the assessment stages as was the ability to seamlessly switch between them.
4. Communications, temporal relationships and links between task information are all easily captured and displayed in TaskArchitect. Once again, these were essential during the assessment stages.
4.The assessment and evaluation stages are vital within a context of learning lessons. The timeline in particular with the use of task highlighting can make this easier.

The clarity of the diagrams automatically produced by TaskArchitect saves time, enables very large amounts of data to be absorbed and manipulated and takes much of the low level work out of generating a variety of descriptions of large systems. This leaves the User of TaskArchitect greater opportunity to concentrate on the higher level issues such as assessment and evaluation.

Further Reading

Task/Process/Timeline descriptions

M. A. Tainsh (1985) Job process charts and man-computer interaction within Naval command systems. Ergonomics.

Task Description and Analysis from a general perspective

B. Kirwan and L. K. Ainsworth (1992) A Guide To Task Analysis, Taylor and Francis.

The Systems Approach

C. Sandom and R. Harvey (2004) Human Factors for Engineers. Institution of Engineering and Technology.

M. A. Tainsh (1988) The Concept of an Information Management System and its use within design studies. Behaviour and Information Technology.

Contact Details

Mike Tainsh may be contacted directly at mike.tainsh@kromeonline.info