Socio-technical systems are enterprise systems that are intended to help deliver some
organisational or business goal. This might be to increase sales, reduce material used
in manufacturing, collect taxes, maintain a safe airspace, etc. Because they are
embed-ded in an organisational environment, the procurement, development and use of these
system is influenced by the organisation's policies and procedures and by its
work-ing culture. The users of the system are people who are influenced by the way the
2.3 • Organisations, people and computer systems 35
organisation is managed and by their interactions with other people inside and out-side of the organisation.
Therefore, when you are trying to urlderstand the requirements for a socio-technical system yOIl need to understand its organisational environment.Ifyou don't, the systems may not meet business needs, and users and their managers may reject the system.
Human and organisational factors from the system's environment that affect the system design include:
I. Process changes Does the system require changes to the work processes in the environment?Ifso, training will certainly be required. Ifchanges are signifi-cant, or if they involve people lo_ing their jobs, there is a danger that the users will resist the introduction of the system.
2. Job dwnges Does the system de-!;kill the users in an environment or cause them to chlUlge the way they work? If so, they may actively resist the introduction of the system into the organisation. Designs that involve managers having to change their way of working to fit the computer system are often resented. The managers may feel that their status in the organisation is being reduced by the system.
3. Orgal1isational changes Does the system change the political power structure in an organisation? For example, if
lm
organisation is dependent on a complex sys-tem, 1hose who know how to operate the system have a great deal of political power.These human, social and organisational factors are often criticalindetennining whether or not a system successfully meets its objectives. Unfortunately, predicting their effects on systems is very difficult for engineers who have little experience of social or cul-turalstudif:s. To help understand the effects of systems on organisations, various method-ologies have developed such as Mumford's socio-technics (Mumford, 1989) and Checkland's Soft Systems Methodology (Checkland and Scholes, 1990; Checkland, 1981). There have also been extensive sociological studies of the effects of computer-based systems on work (Ackroyd, et aI., 1992).
Ideally, all relevant organisational knowledge should be included in the system spec-ification so that the system designers may take it into account. In reality, this is impos-sible. System designers have to make assumptions based on other comparable systems and on common sense.Ifthey get these wrong, the system may malfunction in unpre-dictable \\-ays. For example, if the designers of a system do not understand that dif-ferent parts of an organisation may actually have conflicting objectives, then any organisation-wide system that is developed will inevitably have some dissatisfied users.
2.3.1 Organi~ational
processes
[n Section 2.2, 1introduced a system engineering process model that showed the sub-proce_ses involved in system de,elopment. However, the development process is not th(! only process involved in systems engineering. It interacts with the
36 Chapter 2 • Socio-technical systems
Figure 2.9 Procurement, development and operational processes
system procurement process and with the process of using and operating the sys-tem. This is illustrated in Figure 2.9.
The procurement process is nonnally embedded within the organisation that will buy and use the system (the client organisation). The process of system procure-ment is concemed with making decisions about the best way for an organisation to acquire a system and deciding on the best suppliers of that system.
Large complex systems usually consist of a mixture of off-the-shelf and specially built components. One reason why more and more software is included in systems is that it allows more use of existing hardware components, with the software act-ing as a 'glue' to make these hardware components work together effectively. The need to develop this 'glueware' is one reason why the savings from using off-the-shelf components are sometimes not as great as anticipated. I discuss COTS sys-tems in more detail in Chapter 18.
Figure 2.10 shows the procurement process for both existing systems and sys-tems that have to be specially designed. Some important points about the process shown in this diagram are:
1. Off-the-shelf components do not usually match requirements exactly, unless the requirements have been written with these componentsinmind. Therefore, choos-ing a system means that you have to find the closest match between the sys-tem requirements and the facilities offered by off-the-shelf syssys-tems. You may then have to modify the requirements and this can have knock-on effects on other sub-systems.
2. When a system is to be built specially, the specification of requirements acts as the basis of a contract for the system procurement.Itis therefore a legal, as well as a technical, document.
3. After a contractor to build a system has been selected, there is a contract nego-tiation period where you may have to negotiate further changes to the require-ments and discuss issues such as the cost of changes to the system.
I have already outlined the main phases of the system development process.
Complex systems are usually developed by a different organization (the supplier) from the organization that is procuring the system. The reason for this is that the procurer's business is rarely system development so its employees do not have the
2.3 It Organi~,ationspeople and computer systems 37
skills needed to develop complex systems themselves. In fact, very few single organ-isations ha.ve the capabilities to design, manufacture and test all the components of a large, complex system.
This supplier, who is usually called the principal contractor, may contract out the development of different sub-systems to a number of sub-contractors. For large 5,ystems, such as air traffic control systems, a group of suppliers may form a con-sortium to bid for the contract. The concon-sortium should include all of the capabili-ties required for this type of system, such as computer hardware suppliers, software developen., peripheral suppliers and suppliers of specialist equipment such as radars.
The prccurer deals with the contracmr rather than the sub-contractors so that there is a single procurer/supplier interface. The sub-contractors design and build parts of the system to a specification that is produced by the principal contractor. Once completed, the principal contractor integrates these different components and deliv-ers them to the customer buying the system. Depending on the contract, the pro-curer may allow the principal contractor a free choice of sub-contractors or may require the principal contractor to choose sub-contractors from an approved list.
Operational processes are the processes that are involved in using the system for its defined purpose. For example, operators of an air traffic control system fol-low specific processes when aircraft enter and leave airspace, when they have to change height or speed, when aneffil~rgency occurs and so on. For new systems, these operational processes have to h~defined and documented during the system development process. Operators may have to be trained and other work processes adapted to make effective use of the new system. Undetected problems may arise at this stage because the system specification may contain errors or omissions. While the system may perform to specification, its functions may not meet the real oper-ational needs. Consequently, the operators may not use the system as its design-ers intended.
The key benefit of having people in a system is that people have a unique capa-bility of being able to respond effectively to unexpected situations even when they have never had direct experience of these situations. Therefore, when things go wrong,
38 Chapter 2 • Socio-technical systems