CUSTOM Socio-Technical Modeling in Human Computer Interaction

Editor's Notes

• #1: Introduce the topic and its relevance in today’s technology-driven world.Define socio-technical systems as the integration of people, technology, and their interactions.
• #5: Thus, any organisation employs people with capabilities, who work towards goals, follow processes, use technology, operate within a physical infrastructure, and share certain cultural assumptions and norms. https://business.leeds.ac.uk/research-stc/doc/socio-technical-systems-theory
• #8: the focus is entirely on technology as the dominant force driving systems, with little to no consideration for human or social factors. Workers are expected to adapt to rigid technical frameworks, often leading to dissatisfaction and inefficiencies. A socio-technical system is a framework or approach that integrates both the social and technical aspects of an organization or process. It recognizes that human behavior, organizational culture, and technical systems (like machines, tools, and IT infrastructure) are interconnected and must work together harmoniously for optimal performance. This theory emphasizes the balance between social needs and technological efficiency.
• #11: At university, in requirement gathering our main focus is on the system, what features should It have, what functional requirements, what should be the non-functional requirements. But socio-technical modeling emphasizes on both social and technical aspect of a system. For example, you’re assigned to develop a new system for higher education. If you follow the regular requirement gathering process, your main focus will be on the system. But if you imply a socio-technical modeling first, you’ll focus on both the technical side as well as the social side.
• #22: Stakeholder needs can be both complex and conflicting. we need to understand how the introduction of the system might actually change the organizational and work practices that are currently in place and what the impact of this might be. Requirements capture is an important part of all software engineering methodo- logies but often this activity focusses primarily on the functional requirements of the system – what the system must be able to do – with less emphasis on non-functional human issues such as usability and acceptability. Even where such matters are considered, they may reflect only the management’s view of the user’s needs rather than gathering information from the users themselves.
• #23: lexibility in specification, local focus in design, user-centered design, and system evolution will help overcome these.
• #24: In this section, we shall look at some of the organizational issues that affect the acceptance and relevance of information and communication systems. these factors often sit ‘outside’ the system as such, and may involve individuals who never use it. Yet it is often these factors more than any other that determine the success or failure of computer systems.
• #25: The term ‘computer-supported cooperative work’ (CSCW) seems to assume that groups will be acting in a cooperative manner. This is obviously true to some extent; even opposing football teams cooperate to the extent that they keep (largely) within the rules of the game, but their cooperation only goes so far. People in organiza- tions and groups have conflicting goals, and systems that ignore this are likely to failspectacularly. Imagine that an organization is already highly computerized, the different depart- ments all have their own systems and the board decides that an integrated informa- tion system is needed. The production manager can now look directly at stocks when planning the week’s work, and the marketing department can consult the sales department’s contact list to send out marketing questionnaires. All is rosy and the company will clearly run more efficiently – or will it? Before installing a new computer system, whether explicitly ‘cooperative’ or not, one must identify the stakeholders who will be affected by it. These are not just the immediate users, but anyone whose jobs will be altered, who supplies or gains infor- mation from it, or whose power or influence within the organization will increase or decrease. It will frequently be the case that the formal ‘client’ who orders the system falls very low on the list of those affected. Be very wary of changes that take power, influence or control from some stakeholders without returning something tangible in their place.
• #26: The identification of stakeholders will uncover information transfer and power rela- tionships that cut across the organizational structure. Indeed, all organizations have these informal networks that support both social and functional contacts. However, the official lines of authority and information tend to flow up and down through line management. New communications media may challenge and disrupt these formal managerial structures. Technology can be an important vector of social change, but if violent reaction is to be avoided, the impact of the technology must be assessed before it is introduced. In the short term, solutions must be carefully matched to the existing social and organizational structures.
• #27: The lesson is that information systems should aim for some level of symmetry. If you have to do work for the system, you should obtain some benefit from it.
• #30: The major task in many organizations is moving pieces of paper around. Organizations have many such processes, and workflow systems aim to automate much of the process using electronic forms, which are forwarded to the relevant person based on pre-coded rules. A more radical approach to organizational processes is found in business process re-engineering (BPR). Traditionally, organizations have been structured around functions: sales, accounts, stores, manufacturing. However, the purpose of an organ- ization can be seen in terms of key business processes. Finally, and most radically, the whole structure of the organization may be modified to reflect and support the key processes more closely. Typically, this involves stripping layers of middle management. Lotus Notes
• #31: We have seen several problems that can arise from the mismatch between informa- tion systems and organizational and social factors. Let us assume that we have a sys- tem in place – and it has not fallen apart at the seams. Everyone seems happy with it and there are no secret resentments. Now it is time to count the cost – it was an expensive system to buy and install, but was it worth it? This is an almost impossible question to answer. The benefits are difficult to quantify, but, over time, it has become clear that the competitive edge of information technology is necessary for survival in the modern world.
• #32: As we have already seen, problems can arise when a system is introduced without a full understanding of all the people who will be affected by it. But how can we better understand and support complex organizational structures, workgroups and potentially conflicting stakeholder needs? We begin by capturing and analyzing requirements, but we need to do this within the work context, taking account of the complex mix of concerns felt by different stakeholders and the structures and pro- cesses operating in the workgroups. socio-technical modeling, soft systems methodology, participatory design, ethnographic methods and contextual inquiry.
• #34: As a general rule, the priority of stakeholder needs diminishes as you go down the categories. So primary stakeholders usually take priority over the others. However, this is not always the case. Imagine designing the control panel of a hospital life sup- port machine. The primary stakeholders will be medical staff monitoring a patient’s condition. But who, in fact, has the greatest interest in this system working? Surely it is the patient, whose life is dependent on the system’s success? In this case the tertiary stakeholder is of vital importance.
• #36: Early in the twentieth century, studies of work focussed on how humans needed to adapt to technical innovations. Technological determinism, the view that social change is primarily dictated by technology, with human and social factors being secondary concerns, was prevalent.
• #37: The socio-technical systems view came about to counter this technology-centric position, by stressing that work systems were composed of both human and machine elements and that it was the interrelation- ship between these that should be central. Socio-technical models for interactive systems are therefore concerned with tech- nical, social, organizational and human aspects of design. They recognize the fact that technology is not developed in isolation but as part of a wider organizational environment. It is important to consider social and technical issues side by side so that human issues are not overruled by technical considerations.
• #38: Methods vary but most attempt to capture certain common elements: Information is gathered using methods such as interviews, observation, focus groups and document analysis. The methods guide this information-gathering process and help the analyst to make sense of what is discovered. By attempting to understand these issues, socio-technical approaches aim to provide a detailed view of the role technology will play and the requirements of successful deployment. We will compare two approaches to illustrate how this may work in practice.
• #48: Stages 2 to 4 are described in terms of the current situation (before the new technology is introduced) and the proposed situation (after deployment). takeholders are asked to express their views not only of their current role and position but of their expectations in the light of the changes that will be made. In this way, stakeholder concerns and goals are elaborated. In addition, the impact of the technology on working practices is considered (Stage 3) and the transformations that will be sup- ported by the system specified (Stage 4).