Work System Theory and Work System Method: A Bridge between Business and IT Views of IT-Reliant Systems in Organizations Steven Alter University of San Francisco School of Management San Francisco, CA, USA +1 (415) 945-9481
[email protected] ABSTRACT This tutorial explains the most current version of work system theory (WST) and shows how WST and several direct extensions can be applied in the work system method (WSM), a systems analysis method developed over several decades for use by business professionals and to support communication and collaboration between business and IT professionals.
Categories and Subject Descriptors D.2.1 [Software Engineering]: Requirements – elicitation methods, methodologies, tools.
General Terms Management, Design, Theory
Keywords Work system, systems analysis and design, requirements engineering
1. BACKGROUND AND MOTIVATION Widely cited difficulties in communication and collaboration between business and IT professionals are related to living and working in different communities of practice. Those difficulties are often directly related to misguided requirements and systems that do not fit the work practices or needs of users. The initial impetus for developing the work system approach came from experience in a manufacturing software company where some of those issues were observed. This tutorial’s goals related to software engineering include: 1) Acquaintance with readily usable and easily teachable concepts, frameworks, tools, and methods that bridge the gap between the peopleand business-oriented sociotechnical world of business professionals and the abstract, technology-centric world of IT professionals and IS/IT researchers. 2) Greater appreciation of the strengths and limitations of existing software engineering approaches related to requirements engineering and systems analysis and design. 3) Reinforcement of conceptual learning through active practice in using selected tools from WSM to describe differences between three development approaches: agile development, waterfall development, and tailoring of commercial application software.
2. A WORK SYSTEM PERSPECTIVE With a work system perspective, the system of primary interest is not a configuration of hardware and software. Instead, the system of primary interest is a work system, by default a system in which people perform work activities using IT and possibly other technologies. Placing primary focus on a work system instead of an IT artifact that supports that work system makes sense if the goal is to produce software that will help people accomplish goals in work and/or social environments. This
tutorial introduces the basic ideas and work system perspective by discussing the following: 1) Basic concepts in work system theory (WST), including the definition of work system, work system framework, and work system life cycle model [1,3,5]. 2) Application of WST and its extensions in the work system method (WSM), which treats the “as is” and “to be” systems as sociotechnical work systems rather than IT artifacts. Focusing on work systems rather than IT per se provides a unit of analysis that business and IT professionals can discuss meaningfully. 3) Extensions of WST including work system principles, work system design spaces, a work system metamodel whose detailed reinterpretation of basic work system ideas is more directly useful for IT-related analysis and design, and a theory of workarounds that is usable within systems analysis and design efforts. The rigorous but readily understandable nature of WST and WSM provides a path toward the mutual understanding required for successful collaboration between business and IT professionals who are trying to improve an IT-reliant work system. Joint attention to WSM topics and issues addresses longstanding difficulties in communication and collaboration between business and IT professionals. The innovation in using WST/WSM involves providing a workspace where business and IT professionals can describe their understandings of the work system’s structure and performance along with related problems and opportunities.
3. WORK SYSTEM DEFINITION AND SPECIAL CASES The central idea in work system theory (WST) is that “work system” is a natural unit of analysis for thinking about systems in organizations. In organizational settings, work is the application of human, informational, physical, and other resources to produce product/services. Definition. A work system is a system in which human participants and/or machines perform work (processes and activities) using information, technology, and other resources to produce specific product/services for specific internal and/or external customers. An enterprise can be viewed as a set of interacting work systems. Typical business organizations contain work systems that procure materials from suppliers, produce products, deliver products to customers, find customers, create financial reports, hire employees, coordinate work across departments, and perform many other functions. Special cases. The work system concept is like a common denominator for many of the types of systems that operate within or across organizations [3]. Special cases of the general category work system include information system, service system, project, supply chain, selfservice work system, and totally automated work systems.
An information system is a work system whose processes and activities are devoted to processing information through activities including capturing, transmitting, storing, retrieving, deleting, manipulating, and displaying information. Many information systems, such as accounting systems, include human participants who perform important activities. Other information systems, such as search engines, are totally automated. A service system is a work system that produces services for its customers. In typical business situations service systems are assumed to be sociotechnical systems with human participants. Direct customer participation in sociotechnical service systems is often called coproduction. Other service systems, such as search engines or GPS tools may be totally automated. This definition of service system includes totally automated systems but does not assume that those systems consist of encapsulated services in an SOA-like environment.
•
•
Customers and products/services may be partially inside and partially outside because customers often participate in the processes and activities within the work system and because produc/services take shape within the work system. Environment, infrastructure, and strategies are viewed as largely outside the work system even though they have direct and indirect effects within the work system.
A project is a temporary work system designed to produce a set of products/ services, after which it ceases to exist. A supply chain is an inter-organizational work system devoted to procuring materials and other inputs required by an enterprise to perform its work and to produce its product/services for its customers. A self-service work system positions customers as primary participants involved in activities such as selecting and purchasing product/services using an ecommerce web site. In self-service work systems, customers perform processes and activities by applying resources provided for their use to obtain information, make purchases, or achieve other goals. A totally automated work system is a work system in which all of the processes and activities are performed by computer programs, physical machines, and other devices. People who create and maintain those programs, machines, and other devices are not participants in those automated work systems. Rather, they are participants in other work systems that create or maintain automated work systems. The relationship between work systems in general and the special cases implies that many of the same basic concepts apply to all of the special cases, which also have their own specialized vocabulary. In turn, this implies that much of the body of knowledge for the current information systems discipline can be organized around a work system core.
4. WORK SYSTEM THEORY As a complete perspective on work systems, WST needs to cover both a static view of a work system during a period when it is relatively stable and a dynamic view of how a work system changes over time. WST includes three things [3,5]: 1) The definition of work system provided above) 2) The work system framework, a representation of a work system in terms of nine elements of a basic understanding of the work system’s form, function, and environment during a period when it is relatively stable, even though incremental changes may occur during that period. 3) The work system life cycle model, a representation of the iterative process whereby work systems evolve over time through a combination of planned change (formal projects) and emergent (unplanned) change involving adaptations, workarounds, and experimentation.
4.1 Work System Framework The work system framework is a useful basis for describing and analyzing an IT-reliant work system in an organization because its nine elements are part of a basic understanding of a work system. The framework outlines a work system’s form, function, and environment. It emphasizes business rather than IT concerns. It covers situations that might or might not have a tightly defined business process and might or might not be IT-intensive. [11] reported used of a minor variation on Figure 1 while refurbishing a mission-critical data warehouse Of the nine elements in the work system framework: •
Processes and activities, participants, information, and technologies are viewed as completely within the work system.
Figure 1. Work system framework. The definitions of the 9 elements of a work system are as follows: Processes and activities include everything that happens within the work system. The term processes and activities is used instead of the term business process because many work systems do not contain highly structured business processes involving a prescribed sequence of steps, each of which is triggered in a pre-defined manner. Rather, the sequence and details of work in some work systems depend on the skills, experience, and judgment of the work system participants, as happens during medical diagnosis and agile software development. In effect, “business process” is but one of several perspectives for analyzing the activities within a work system. Other perspectives with their own valuable concepts and terminology include decision-making, communication, coordination, control, and information processing. Participants are people who perform the work. Some may use computers and IT extensively, whereas others may use little or no technology. When analyzing a work system, the more encompassing role of work system participant is more important than the more limited role of technology user (whether or not particular participants happen to be technology users). Customers are participants in many work systems, e.g., patients in a medical exam, students in an educational setting, and clients in a consulting engagement. Information includes codified and non-codified information that is used, created, captured, transmitted, stored, retrieved, manipulated, updated, displayed, and/or deleted by processes and activities. Typical informational entities include orders, invoices, warranties, schedules, income statements, reservations, medical histories, resumes, job descriptions, and job offers. The distinction between data and information is not important for understanding a work system since the only data/ information that is mentioned is information that is created, used, or processed by the work system. Information within a work system includes information that is processed by computers and other information that is never computerized, such as the content of conversations, verbal commitments, and other unrecorded information/ knowledge that work system participants use as they perform processes and activities within the work system. Technologies include tools (such as cell phones, projectors, spreadsheet software, automobiles) and automated services (i.e., hardware/software configurations that perform totally automated activities). This distinction is crucial as work systems are decomposed into successively smaller subsystems, some of which are totally automated.
Product/services consist of information, physical things, social products such as agreements, intangibles such as entertainment or peace of mind, and/or actions produced by a work system for the benefit and use of its customers. The term “product/service” is used because the controversial distinction between products and services in marketing and service science is not important for WST even though product-like vs. servicelike is the basis of a series of valuable design dimensions for characterizing and designing the things that a work system produces. Customers are recipients of a work system’s product/services for purposes other than performing work activities within the work system. Since work systems exist to produce product/services for their customers, an analysis of a work system should consider who the customers are, what they want, and how they use whatever the work system produces. External customers are work system customers who are the enterprise’s customers; internal customers are work system customers who are employed by the enterprise, such as customers of a payroll work system. Environment includes the organizational, cultural, competitive, technical, regulatory, and demographic environment within which the work system operates, and that affects the work system’s effectiveness and efficiency. Organizational aspects of the environment include stakeholders, policies and procedures, and organizational history and politics, all of which are relevant to the operational efficiency and effectiveness of many work systems. Factors in a work system’s environment may have direct or indirect impacts on its performance results, aspiration levels, goals, and requirements for change. Analysis, design, evaluation, and/or research efforts that ignore important factors in the environment may overlook issues that degrade work system performance or even cause system failure.
•
and eliminating or minimizing them through fixes, adaptations, or workarounds. On-going improvement of processes and activities through analysis, experimentation, and adaptation
The initiation phase includes: • • • •
Vision for the new or revised work system Operational goals Allocation of resources and clarification of time frames Economic, organizational, and technical feasibility of planned changes
The development phase includes: • • •
Detailed requirements for the new or revised work system and requirements for information systems that support it To the extent necessary, creation, acquisition, configuration, and modification of procedures, documentation, training material, software, and hardware Debugging and testing of hardware, software, and documentation
The implementation phase includes: • • • • •
Implementation plan (pilot? phased? big bang?) Change management efforts about the rationale and positive or negative impacts of changes Training on details of the new or revised information system and work system Conversion to the new or revised work system Acceptance testing
Infrastructure includes relevant human, informational, and technical resources that are used by the work system but are managed outside of it and are shared with other work systems. From an organizational viewpoint, rather than a purely technical viewpoint, infrastructure includes human infrastructure, informational infrastructure, and technical infrastructure, all of which can be essential to a work system’s operation. Strategies that are relevant to a work system include enterprise strategy, department strategy, and work system strategy. In general, strategies at the three levels should be in alignment, and work system strategies should support department and enterprise strategies. Unfortunately, strategies at any of the three levels may not be articulated or may be inconsistent with reality or with beliefs and understandings of important stakeholders.
4.2 Work System Life Cycle Model The work system life cycle (WSLC) model describes how a work system may evolve through multiple iterations of four phases: operation and maintenance, initiation, development, and implementation. The names of the phases were chosen to describe both computerized and noncomputerized systems, and to apply regardless of whether application software is acquired, built from scratch, or not used at all. This model encompasses both planned and unplanned change. Planned change occurs through a full iteration encompassing the four phases, i.e., starting with an operation and maintenance phase, flowing through initiation, development, and implementation, and arriving at a new operation and maintenance phase. Unplanned change occurs through fixes, adaptations, workarounds, and experimentation that can occur within any phase. The inward facing arrow denote unanticipated opportunities and unanticipated adaptations. The pictorial representation of the work system life cycle model places the four phases at the vertices of rectangle. Forward and backward arrows between each successive pair of phases indicate the planned sequence of phrase and allow the possibility of returning to a previous phase if necessary. The phases can be summarized as follows: The operation and maintenance phase includes: • •
Operation and monitoring of the work system’s performance Maintenance of the work system (which often includes at least part of the information systems that support it) by identifying small flaws
Figure 2. Work system life cycle model. The work system life cycle model is fundamentally different from the frequently cited system development life cycle (SDLC), which actually describes projects that attempt to produce or modify software. Current versions of the SDLC may contain iterations but they are basically iterations within a project. More important, the system in the SDLC is a basically a technical artifact that is being programmed. In contrast, the system in the WSLC is a work system that evolves over time through multiple iterations. That evolution occurs through a combination of defined projects and incremental changes resulting from small adaptations and experimentation. In contrast with control-oriented versions of the SDLC, the WSLC treats unplanned changes as part of a work system’s natural evolution. Agile development, waterfall development, and tailoring of commercial application software all can be described using the WSLC. Waterfall assumes that software is produced in stages during the development phase and that each stage follows from the completion of the previous stage. Agile assumes that software development is divided into a set of
sprints that occur during the development phase but with active participation of users who help in designing and evaluating each intermediate software product. With commercial application software, the development phase in the WSLC is assumed to use existing application software, which is then tailored to local needs. The WSLC emphasizes a major issue for all three approaches, the fact that these are software development approaches rather than work system improvement approaches. In all three cases, the WSLC implementation phase involves implementation in the organization rather than just technical implementation of software. In each, implementation in the organization may take longer and may cost more than the development phase.
5. WORK SYSTEM METHOD The work system method (WSM) was developed as a semi-formal systems analysis and design method that business professionals (and/or IT professionals) can use for understanding and analyzing a work system at whatever level of depth is appropriate for their particular concerns. WSM evolved iteratively starting in around 1997. During each iteration, the then current version was tested by evaluating success and difficulty experienced by MBA and EMBA students trying to use that version to produce a management briefing and tentative recommendation about a work system an enterprise that employed one of the teammates. At this point, many versions of a work system analysis template have been used by universities as part of the basic explanation of systems in organizations, to help students focus on business issues, and to help student teams communicate [3, 5, 12]. Results from analyses of real world systems by typical employed MBA and EMBA students indicate that a systems analysis method for business professionals should be somewhat prescriptive, but less complex than high-precision notations and diagramming tools for IT professionals. While not a straitjacket, it must be at least somewhat procedural and must provide vocabulary and analysis concepts. At the same time, it should encourage performing the analysis at whatever level of detail is appropriate for the task at hand. A problem solving approach. WSM is organized around a general problem-solving outline that includes the following: • • • • • • • •
Identify the problem or opportunity Identify the work system that has that problem or opportunity (plus relevant constraints and other considerations) Use the work system framework to summarize the work system Gather relevant data. Analyze the situation using factors such as measures of performance, key incidents, root cause analysis, implications of structural characteristics, work system principles. Identify possibilities for improvement. Decide what to recommend Justify the recommendation by using metrics, principles, structures, and other factors to explain how and why work system performance should improve.
Focus on work systems, not IT. In contrast to systems analysis and design methods for IT professionals who need to produce a rigorous, totally consistent definition of a computerized system, WSM has the following characteristics: • • •
WSM encourages the user to decide how deep to go in the analysis. It is unnecessary to specify everything needed to produce software because those details will be filled in by IT professionals. WSM makes explicit use of the work system framework and work system life cycle model, thereby providing an organized vocabulary for describing and analyzing a work system. WSM treats the “as is” and “to be” systems as work systems, not IT systems, thereby providing more of a management and business focus than typical IT-oriented methods. Recommended changes and requirements are changes and requirements for the work system, not just the IT system.
• • • • •
WSM treats work system participants as part of the work system (not just users of the software). WSM makes explicit use of characteristics and metrics for the work system and its elements. WSM includes codified and non-codified information. WSM includes IT and non-IT technologies. WSM suggests that recommendations specify which work system improvements rely on IS changes, which recommended work system changes don’t rely on IS changes, and which recommended IS changes won’t affect the work system’s operational form.
Work system snapshot. One of WSM’s central tools is the “work system snapshot,” which provides a one-page, formatted summary of the “as is” or “to be” work system. It uses the six central elements of the work system framework. (See example in Table 1.) A reasonable level of rigor is enforced by consistency rules such as the requirement that all participants need to participate in at least one activity, all information mentioned needs to be used or produced by at least one activity, and so on. More detailed modeling is supported by a metamodel mentioned in the next section. The requirement of not exceeding one page helps focus attention on the scope of the system and prevents getting overwhelmed at the outset in details that subsequent analysis will reveal. The other three elements of the work system framework (environment, infrastructure, and strategies) are not included in the work system snapshot for the sake of simplicity when focusing on the appropriate scope for the work system in relation to the problems and opportunities at hand. These three elements are considered as the analysis goes into more depth. Table 1. Sample work system snapshot. Customers
Producs/ Services
Hiring manager Applications (which may be Larger organization (which will used for subsequent analysis) employ the new hire) Job offers HR manager (who will analyze Rejection letters the nature of applications) Hiring of an applicant Major Activities and Processes Hiring manager submits request for new hire within existing budget Staffing coordinator defines the parameters of the new position. Staffing coordinator publicizes the position. Applicants submit job applications. Staffing coordinator selects shortlisted applicants. Hiring manager identifies applicants to interview. Staffing coordinator sets up interviews. Hiring manager and other interviewers perform interviews. Hiring manager and other interviewers provide feedback from the interviews. Hiring manager makes hiring decisions. Staffing assistant sends offer letters or rejections. Successful applicant accepts or rejects job offer or negotiates further. Participants Information Technologies Hiring managers Staffing coordinator Applicants Staffing assistant Other employees who perform interviews
Job requisition Job description Advertisements Job applications Cover letters Applicant resumes Short list of applicants Information and impressions from the interviews Job offers Rejection letters
New HR portal that is being built Word processor Telephones Email
6. EXTENSIONS OF WORK SYSTEM THEORY This section presents four extensions of WST that were developed to address limitations observed in uses of WSM: a work system metamodel, work system principles, work system design spaces, and a theory of workarounds. Other extensions are not mentioned for lack of space.
6.1 Work System Metamodel The work system framework (Figure 1) is useful for summarizing a work system while attaining agreement about the nature and scope of the work system that has problems or opportunities that launched the analysis. Deeper, more detailed analysis calls for reinterpreting the elements of the work system framework using more specific terminology and relationships that are nonetheless understandable to most business professionals, i.e., not technical concepts such objects and classes that often seem impenetrable. In the metamodel, information becomes informational entity, technology becomes technological entity and is divided into tools and automated services, activities are performed by one of three types of actor roles, and so on. Whereas the work system framework does not include the term user, the metamodel includes "uses" as a relationship between the entity type participant and the entity type tool (which along with automated service represents two distinct guises of technology). Specific relationships the sixth version of the metamodel [6,7,8] include the following, among many others: • • •
•
Enterprises and value constellations (value streams that cross enterprises) consist of work systems. Work systems always contain at least one activity. They may contain one or more business processes if a set of activities is sufficiently interrelated and sequential to qualify as a process. Activities use resources to produce one or more product/service from activity that may be used as a resource for subsequent activities and/or may contribute to a product/service offering for a customer. A product/service offering may combine multiple product/services from activities. Resources used by an activity may include participants, informational resources, technological resources, and other resources. The metamodel includes specific types within each resource type to minimize the likelihood of omissions in an analysis.
Attributes of entity types, such as goals, characteristics, metrics are relevant but are not shown in the metamodel diagram to keep it understandable. The metamodel diagram is not included here because it takes up a full page. (See [6, 7, 8] or www.stevenalter.com )
reported in [9] individual students rated each principle for "correctness," the extent to which most work systems in their organizations should conform to the principle, and "conformance," the extent to which most existing work systems conform to the principle. The uniform response was that the individual principles seemed valid (correctness average of around 6 out of 7) but were not followed closely by operational systems (conformance of average of around 4.5 out of 7) in the work systems the EMBA students were familiar with. Table 2. 24 work system principles [ 9] Customers
Product/Services
#1: Please the customers. #2: Balance priorities of different customers. Processes and Activities #3: Match process flexibility with product variability #4: Perform the work efficiently. #5: Encourage appropriate use of judgment. #6: Control problems at their source. #7: Monitor the quality and timing of both inputs and outputs. #8: Boundaries between steps should facilitate control. #9: Match the work practices with the participants. Participants Information Technologies #10: Serve the #13: Provide #15. Use participants. information where cost/effective #11: Align participant it will affect action. technology. #14: Protect #16: Minimize incentives with system goals. information from effort consumed by #12: Operate with inappropriate use. technology. clear roles and responsibilities. Infrastructure #17: Take full advantage of infrastructure. Environment #18: Minimize unnecessary conflict with the external environment Strategies #19: Support the firm’s strategy Work System as a #20: Maintain compatibility and coordination Whole with other work systems. #21: Incorporate goals, measurement, evaluation, and feedback. #22: Minimize unnecessary risks. #23: Maintain balance between work system elements. #24: Maintain the ability to adapt, change, and grow.
6.2 Work System Principles The idea of defining work system principles and incorporating them within WSM was motivated by difficulties encountered by MBA and Executive MBA teams in accomplishing more than describing a work system and identifying several readily apparent weaknesses. The elements of the work system framework provided a good outline for summarizing a work system using a work system snapshot (Table 1), but many teams had difficulty searching for improvements other than relatively obvious changes such as recording data that wasn’t being recorded or sharing data that wasn’t being shared. They seemed to need guidelines for thinking about the various types of improvements that might be considered. Introducing a general set of work system principles seemed a plausible way to make sure that the teams would think about each element and would have a basis for comparing the current status and possible modifications to a set of ideals. Table 2 uses the format of a work system snapshot (Table 1) to display 24 work system principles that six small cohorts of EMBA students believed to be meaningful and potentially useful for thinking about systems [9]. The principles in bold are basically restatements (for understandability) of nine sociotechnical principles proposed by [10]. Between 2005 and 2009 six small cohorts of Executive MBA students at the University of San Francisco were asked to rate each principle. As
6.3 Work System Design Spaces The work system principles were developed to provide more guidance in searching for potential improvements. A subsequent step was to specify a set of "design spaces" identifying generic types of changes or directions for change, thereby helping analysts consider improvement paths that they might not otherwise imagine or recognize as relevant. A work system design space is a set of things that might change or whose problematic nature might impel change in relation to any work system element, any subsystem of a work system, or the work system as a whole. To date, seven such design spaces have been described [2]. Most have been used informally but there is no data about whether those design spaces influenced decisions. The design spaces described to date include: 1)
2)
Work system principles (above) have implications for design because they can be used as a checklist or point of comparison by thinking about the extent to which the "as is" or "to be" work system conforms to each principle. In each case, gaps between "as is," "to be,” and "should be" provide potential directions for improvement. Generic types of changes occur frequently for each of the six elements in a work system snapshot. Some are in the spirit of engineering, such as adding, combining, or eliminating steps in a process, or upgrading hardware and software. Others are more in the
3)
4)
5)
6)
7)
spirit of service, such as improving customer relationships or the customer experience. Scanning a checklist of these generic changes can help in identifying directions for improvement, e.g., Should we add or eliminate steps? Should we change business rules? Should we change the nature of the customer relationship? and so on. Design characteristics for each element in a work system snapshot (plus “work system as a whole”) represent big picture choices that should be considered before determining a work system’s details. Each characteristic can be treated as a design dimension, such as from simple to complex, from unstructured to totally structured, and from manual to automated. The related questions include: How structured should this process be? How complex should it be? What is the right amount of variety in the work? and so on. Typical SA&D texts say little or nothing about these design characteristics. Product/services along a series of design dimensions. When describing, analyzing, designing, or evaluating offerings for internal and/or external customers, definitive classification of that offering as either a product or service is rarely important. To the contrary, a large percentage of offerings to internal and/or external customers combine some characteristics that are often associated with products and others that are often associated with services. Frequently an improvement in a particular offering may make some aspects of it more product-like in an everyday sense (e.g., more tangible, more commoditized) and other aspects of it more service-like (e.g., less tangible, more customized). These and other design dimensions for product/services affect work system operation in various ways.. Common risks and obstacles are often associated with each element of the work system framework and with the work system as a whole [1, p. 66]. Analysts and designers can use this design space to identify common risks and obstacles that may apply to the work system but that may not be named yet or fully visualized in the analysis. They can assess the significance of each common risk or obstacle and can try to devise ways to avoid related problems. Alternative locations of information and knowledge are relevant because information and knowledge can reside within any of the work system elements. Where knowledge should reside, and in what form, can be viewed as a design choice. For example, knowledge might be tacit knowledge in the heads of work system participants, might be built into the overall logic of processes and activities, might be codified in expert systems, or might be built into hardware or software technologies. Direct and indirect interactions with other work systems. Those interactions may be essential for a work system's successful operation (e.g., interactions with suppliers or customers) or may degrade performance or even cause catastrophic failures. The basis of this design space is a set of concepts and taxonomies for understanding, analyzing, and designing interactions between ITreliant work systems.
6.4 Theory of Workarounds The inward facing arrows in WST’s work system life cycle model (Figure 2) represent ongoing adaptations that occur endogenously from within the work system without external interventions or formal projects. Many of these adaptations are workarounds or are based on learning from workarounds. Curiosity about the nature of those adaptations led to developing a theory of workarounds [4] based on hundreds of descriptions of workarounds found through secondary sources. Examples include workarounds to deal with unexpected obstacles to completing work steps or transactions, workarounds to avoid logging in with passwords, workarounds to bypass process aspects of business processes that seem cumbersome, over-constrained, or no longer aligned with the realities in hand, and workarounds to evade organizational controls in order to achieve the organization’s goals or for personal considerations.
The theory assumes that workarounds might affect any part of a work system. The theory starts with initial intentions in a designing a work system and the current structure, including performance goals, the monitoring system, and the reward system. A perceived need for a workaround leads to identifying possible workarounds, selecting a workaround to pursue, and developing the workaround. Relevant factors at each step are treated as inputs, such as situational constraints, participant goals related to the work system, knowledge available for designing workarounds, and so on. The related idea of a “workaround design system” suggests identifying and codifying common workarounds and using that knowledge. An organized process for doing that involves identifying foreseeable workarounds near the end of a work system design process and identifying circumstances under which specific types of workarounds would be helpful or harmful for a proposed work system. Ideally that process would lead to improvements in the design to prevent harmful workarounds and implementation training that include awareness of possible workarounds and their beneficial and/or harmful consequences.
7. REFERENCES . [1] Alter, S. 2006. The Work System Method: Connecting People, Processes, and IT for Business Results, Larkspur, CA: Work System Press [2] Alter, S. 2010. Work Systems as the Core of the Design Space for Organizational Design and Engineering,” International Journal of Organisational Design and Engineering, 1(1/2), 5-28. [3] Alter, S. 2013. Work System Theory: Overview of Core Concepts, Extensions, and Challenges for the Future, Journal of the Association for Information Systems, 14, 2, 2013, 72-121. [4] Alter, S. 2014 Theory of Workarounds, Communications of the Association for Information Systems, 34, 55, 1041-1066 [5] Alter, S. 2015. Work System Theory as a Platform: Response to a Research Perspective Article by Niederman and March, Journal of the Association for Information Systems, 16,6, 483-514. [6] Alter, S. 2016. Degree of Encapsulation as a Key Concern in Analysis and Design for Service Systems, Proceedings of the 22nd Americas Conference on Information Systems. [7] Alter, S. and Bolloju, N.. 2016. A Work System Front End for Object-Oriented Analysis and Design, International Journal of Information Technologies and Systems Approach, 9,1, 1-18. [8] Alter, S. and Recker, J. 2017. Using a Work System Perspective to Expand BPM Use Cases for Research, Journal of Information Technology and Technology Applications, 18. 1:2, in press. [9] Alter, S. and Wright, R. 2010. Validating Work System Principles for Use in Systems Analysis and Design, Proceedings of ICIS 2010, the 31st International Conference on Information Systems. [10] Cherns, A., 1976. The principles of sociotechnical design. Human Relations, 29, 8, 783-792. [11] Koehler, T. and Alter, S. 2016. Using Enterprise Architecture to Attain Full Benefits from Corporate Big Data while Refurbishing Legacy Work Systems, Case Report, IEEE Conference on Business Informatics, Paris, France. [12] Truex, D., Alter, S. Long, C. 2010. Systems Analysis for Everyone Else: Empowering Business Professionals through a Systems Analysis Method that Fits Their Needs," Proceedings of ECIS 2010, 18th European Conference on Information System.
