Systems Analysis

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 organizational studies it may be to better understand the impact of organizational 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 serves not only to demonstrate the systems approach, but also some of the benefits of TaskArchitect. The analysis can be reviewed as a TaskArchitect file by downloading the example file at the bottom of this page and installing TaskArchitect Free 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 handheld device (or smaller) to a large scale plant or remote system. The users and equipment in this context are both categorized 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 optimize the performance of the system by means of assessments and evaluations. Alternatively, it may be to characterize the system as part of a procurement program.

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 optimized performance may be critical to success. In this context it may be vital in many applications to consider both the flow of communication along a timeline 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:

  • They need to be comprehensive, to cover the total scope of the system components and its operation.
  • The functional characteristics can be described in a number of levels of detail.
  • The process characteristics can be charted to show sequence and influence with respect to the endpoints and goals of the system.
  • The interactions (including control loops) between the process components can be charted

The descriptive technique must apply equally to all systems component, such as users and equipment. Furthermore, it must be able to cover all operations. The hierarchical characteristics are essential in helping to understand the relationships between levels of operations, such as 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, for instance when describing activities, they may include cognitive processes, while 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, or ergonomics, is a discipline that is often used within the systems context and so both contributes to the development of diagrams and works from them, for instance using time, error or workload considerations.

The use of TaskArchitect

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

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 participants with a variety of equipment or other items that will influence the final outcome:

  • Local radio
  • Coastguard
  • Ambulance
  • Rescue craft
  • Accident and Emergency hospital
  • Survivor on damaged craft
  • Survivor’s family/home
  • Friends, neighbours and others

The search and rescue scenario involves one holidaymaker 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 a 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 station is informed so that the 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.

Use of TaskArchitect 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.

Stage 2 – Generating the list of processes

The list of major processes that each participant will experience or 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. 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. Up to 100 properties can be rapidly defined then entered using point-and-click in the spreadsheet-like Tabular View or Task Details windows.

Stage 4 - Timeline

The timeline 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:

  • Effectiveness with emphasis on decision making and time to complete important tasks
  • 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
  • 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 organization has met performance or other requirements. Typically, operational effectiveness issues may focus on the coastguard planning and decision processes along with the assignment of 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

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 VisioTM. The range of TaskArchitect editions, from a free Viewer application through to the Standard and Pro versions, means that each person in the team can view TaskArchitect files as required and can create analyses appropriate to their role.

Five main lessons that can be demonstrated through the use of these examples are:

  • /i>TaskArchitect Pro supports the description of up to 4,000 tasks and 100 properties in a single file, and multiple files can be linked together. These characteristics support the examples well.
  • /i>TaskArchitect makes it easy to manage and display many levels of data. This a substantial advantage over other current techniques.
  • /i>Task hierarchy, timelines and link analysis in TaskArchitect provide the means to show these processes’ relationships and interactions. These were essential during the assessment stages in the examples, as was the ability to seamlessly switch between them.
  • /i>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 of the examples.
  • /i>The assessment and evaluation stages are vital within a context of learning lessons. In particular, the timeline 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 with 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.

Ready to try TaskArchitect?

Get Your Free TaskArchitect Today