Collaborative Design of Organizational Systems
1997
Abstract
AI
AI
Collaborative design of organizational systems involves empowering members of an organization to collectively make decisions regarding systems that impact them. This process becomes increasingly crucial as teams rise in importance amidst complex political and technical environments, a trend amplified in inter-organizational scenarios where partnerships are essential for mutual benefit. With the advent of groupware facilitating collaborative work, the design of organizational systems can now better leverage stakeholder involvement through an iterative process. The paper also identifies the need for facilitators to adapt their skills to support modeling in collaborative contexts, indicating an evolving landscape in collaborative systems design.
References (17)
- Conceptual Modeling The purpose of a conceptual model is to highlight the structure of the problem situation, i.e. the organizational system in its context. The conceptual model defines the boundaries of this situation. The following activities are carried out (in a non-linear fashion):
- Identify Building Concepts. To construct the conceptual model, the relevant concepts of the problem situation are identified and expressed in a specific modeling language. For example, actors, resources, items, item stores, tasks/activities, and events [Vreede 1995].
- Create Aspect Models. A conceptual model consists of a set of aspect models that each represent certain building concepts in order to highlight specific characteristics of the modeled situation. Aspect models can, for example, focus on flow (like IDEF3, flow charts), functional decomposition (like IDEF0), communication (like speech/act models), or process dynamics (like simulation, animation).
- Reduce Complexity. A determination must be made as to what details will be taken into account versus which will be abstracted or ignored. This has to do both with the breadth (horizontal scope) and the depth (amount of vertical detail) included in the aspect models.
- Review Aspect Models. Intermediate and final versions of aspect models are reviewed to correct incorrect representations of the situation and to create a shared understanding of this situation. Collaborative experiences with conceptual modeling include Functional/Activity Modeling and Data Modeling using IDEF0 and IDEF1x group modeling tools [Dean 1994, 1995, 1994-95, 1996, 1997, Lee 1995, 1997, Vogel 1993], Process Modeling using TeamGraphics, a group drawing tool, and animation [Vreede 1996, 1997], and Object-Oriented Analysis [Katic 1996].
- Empirical Specification An empirical specification of the problem situation is a more detailed derivative of the conceptual model, so that it can be used to analyze and diagnose the situation. To this end, the following sub-activities can be distinguished:
- Collect empirical data on building blocks. Empirical data is collected on each of the conceptual building blocks, describing their characteristics in more detail. E.g. the occurrence and duration of certain events, or the capacity and working schedules of actors.
- Reduce Complexity. As the goal of the empirical specification activities is to build a model that is adequate for analysis and diagnosis rather than having a perfectly detailed model, the complexity of the real situation is reduced, e.g. by omitting non-key building blocks, by narrowing the scope of the process being considered, or by abstracting away from unimportant detail.
- Build specification. Combine the data collected and simplify the operators to produce an empirical model based upon the conceptual model.
- Check Correspondence between model and real world. Determine whether the model corresponds to key aspects of the real world process. This can be done, for example, with structured walk throughs, expert reviews, and collecting additional, independent data through observation. Collaborative experiences with the construction of empirical specifications include Systems evaluations [Orwig 1995], and using animated simulations to facilitate group discussions aiming (1) to collect empirical data and expert estimations, and (2) validate models [Meel 1994, Vreede 1995].
- Identify potential solutions. Identify ways to handle the causes underlying the problems in the current situation. Use theories, reference models or situations, creativity exercises, and improvement walk throughs where each step is scrutinized for possible improvements.
- Conceptualize solutions. For a description see Section 1.
- Empirically specify solutions. For a description see Section 2.
- Analyze solution models. Evaluation of individual solutions. Collaborative experiences in this area include the participative identification of potential solutions [Dennis 1994; Eijck 1996; Vreede 1997], the evaluation of prototypes of organizational systems [Vreede 1995], and the testing of working procedures in GroupSystems sessions [Vreede et al. 1994]. 1. Implement Solutions The final activity in the design of organizational systems comprises of the roll out of one or more To-Be models into an actual system implementation. The following activities are carried out: 1. Perform comparative analysis of system alternatives. Determine which (set of) system alternatives (solutions) satisfies the solution requirements best.
- Select alternative(s) to be implemented. Based on the comparative analysis of the alternatives, a selection has to be made which solutions are going to be implemented in the current situation.
- Prepare implementation. To prepare the implementation of the selected solutions, the necessary training, change scenarios, and implementation plans are set up.
- Enact Change. Finally, the actual implementation of the organizational system is enacted. Our collaborative experiences in this area include the collaborative writing of policy documents [Mittleman 1996], and groupware (GroupSystems/Lotus Notes ) support for gaming [Smit 1996, Vreede and Vogel 1997]. References A full list of references can be obtained from the authors.