Socio - Technical Co-Construction Process

We have explained the Engineering as Collaborative Negotiation (ECN) paradigm as the theoretical foundation of our collaborative engineering research , and presented the Socio-Technical Framework as a conceptual architecture based on this ECN research foundation. The STF framework moved the ECN paradigm one major step forward in our research, opening the possibility of realizing this new theoretical approach in collaborative engineering practice. The Webster dictionary defines "framework" as "a basic conceptual structure of ideas". STF represents our intellectual efforts of originating, forming, elaborating, or understanding the key ideas of the ECN paradigm. However, a framework by itself is still quite conceptual, and it must be further specified in terms of a particular process , which takes the core concepts from the upstream foundation/framework to match the downstream real-world application requirements, to support its realization.

According to our research strategy (see Research Roadmap), after proposing a foundation (ECN) and a framework (STF), the next step is to develop a specific process through which this conceptual framework can be further detailed and made "operational" for computer implementations and engineering applications. Specifying this process is a very critical step in our collaborative engineering research, because the process logically and systematically connects our conceptual propositions in the abstract space with actionable research tasks and software developments.

Like STF, the specific process that we proposed in our collaborative engineering research is also originated from the sociology of knowledge research, represented by Peter Berger and Thomas Luckmann's work in the social construction of reality [18]. In this pioneer social science research, it was suggested that the "reality", especially those that are considered facts mainly by human agreement, rather than the brute reality that is independent of human opinions [20], is "socially constructed", and that the sociology of knowledge must analyze the "process" in which this occurs. They proposed a social construction of reality theory to address not only the empirical variety of knowledge in human societies, but also the process by which any body of knowledge comes to be socially established as reality.

However, like many other social science researches, this theory, although has a strong descriptive foundation, fell short of needed prescriptive details to guide the implementation and operation of such a social construction theory in practice. This is where our research departs from the social science study. Based on this social construction theory, we:

• Extended the original social "construction" idea to become the social " co -construction" concept. From the viewpoint of stakeholders, co-construction represents a bi- (or multi-) directional operation where everyone's perspectives are being constructed by everyone else simultaneously. It also means that two things can result from a collaborative engineering activity, namely a consensual agreement for the whole group (also called a shared reality) and newly co-constructed perspectives for each participating stakeholder.

• Proposed a prescriptive process with detail steps and operations to realize the above extended social co-construction concept. This process, which we called the Socio-Technical Co-constriction (STC) process, addresses the three key components of the Socio-Technical Framework and specifies eight steps with sufficient operational details as shown in Figure 4.

Figure 4: The Socio-Technical Co-Construction Process (STC)

The Eight Steps of the Socio-Technical co-construction (STC) Process

As shown in Figure 4, we define eight steps in the socio-technical co-construction (STC) process:

1. Define a starting "baseline process" for the chosen application domain. For example, the baseline process can be a QFD process or other design methodologies, such as the axiomatic design, systematic design, etc., if the application domain is collaborative product development. This baseline process can be seen as commonly accepted "workflows [1]" suggested by practitioners. It is needed because the co-construction operation, which generates the actual dynamic ¡°knowledge flows¡± among interacting stakeholders, must operate on some specific steps to begin the process. It is important to point out that this starting baseline process can be con-constructed (i.e., changed) later, upon the agreement by all involved stakeholders, as a means to resolve conflicts. The defined baseline process can be further broken down into a series of tasks and states.

2. Identify a group of "stakeholders" who have an interest in the outcomes of, and will directly or indirectly participate in, the co-constriction process of a particular collaborative design campaign. This stakeholder definition extends the traditional scope that only includes designers with different disciplines and life-cycle concerns to also include concerned parties, such as customers and regulatory agents, as full participants of a design campaign. Stakeholder is a key concept in our STF, and plays a key role in STC. For example, a stakeholder carries out tasks to change the states of the baseline process. He/she proposes a conceptual structure of the design campaign (see Step 3) and expresses his/her perspectives toward those concepts within the concept structure.

3. Propose an initial " concept structure" for the particular design campaign. This, for example, can be an "initial proposal" based on past experiences or standard solutions that will be dynamically modified and continuously enhanced by all stakeholders once the co-construction process begins. In order words, the initial concept structure (CS) gets progressively more complex over time as new concepts are added or existing concepts are modified. Figure 4 illustrates this fact using the increase and decrease of various colored circular states and its branching states as time t progresses from T1 to T4. Ideally, all interested stakeholders should jointly specify this initial CS; but in practice, one stakeholder, e.g., the project leader, can initiate a CS for the whole group to co-construct.

4. Establish the initial "perspective model" for all participating stakeholders for each concept in the concept structure. Once the initial concept structure is proposed, interested stakeholders can express their initial opinions, represented as a perspective model in STC, toward some specific concepts in this concept structure that they have interests in or expertise of. As soon as the co-construction process begins, these perspective models will be changed, and they will evolve with time, as does their associated concept structure. This is shown in Figure 4, where all perspectives are generated from the concepts in the CS for that particular time from T1 through T4. Additionally, we can see that the number of perspectives, illustrated by the red and yellow stars, also varies with time.

5. Build the "perspective model state diagram" (PMSD) for each concept in the concept structure. Having obtained a well-organized CS in step 3 and stakeholders perspectives in step 4, the next step is to build the PMSDs at any given time t. A PMSD attempts to depict the explicit relationships among stakeholders' concepts (including both shared and individual concepts) in addition to their purpose and context information. The concepts that relate to content in the PMSD can simply be thought of as categories of the various perspective contents relating to the stakeholder in question, rather than all of the information regarding the stakeholders' perspectives. Using a CS to precede the PMSD provides a structured way for us to systematically compare and examine the perspective differences among stakeholders (see next step).

6. Perform the "perspective analysis" on the current PMSD. Since PMSDs link the CS with perspectives and has references to the baseline process, it provides integrated information to conveniently analyze the closeness of, or distance among, different stakeholders' perspectives at that particular moment. Predefined (or co-constructed) thresholds are used during these analyses to cluster different stakeholders based on their perspective distances. If these distances are larger than the thresholds, then the involved stakeholders are said to be in conflicts, and the conflict management step will take place to reduce the distances. In fact, the convergence of distances during perspective analysis is an important goal to drive the progression of the co-construction process to ensure that the stakeholders will end up with some consensual agreements.

7. Conduct the "conflict management" tasks according to the results perspective analysis. Two stakeholders are said to be in conflict, when their perspective distance is found to be larger than the predefined threshold during the analysis of PMSDs. Information contained in PMSDs is used to determine if this conflict is at the content, context or purpose level. Various domain independent and dependent conflict management strategies are employed to attempt to reduce the perspective distances until they are below the threshold. Conflict management strategies can suggest changes to the stakeholders' perspectives, concepts in the CS, and/or steps in the baseline process. After these suggestions are implemented, a new co-construction process begins with this new information until no further conflicts are detected from perspective analyses.

8. Obtain a "shared reality" as a result of the co-construction process. The final product of STC process is a shared reality, which is a broader concept than that from traditional approaches (e.g., a finished design in terms of a product model). In addition to an agreed upon product model, a shared reality also includes a set of co-constructed concepts and stakeholders' perspectives, which can be very useful for future collaborations among the same group of stakeholders on similar problems. While the shared reality resulted from a STC process is for the specific design campaign in the near term, the accumulative effects of these increasingly larger shared perspectives and concepts can have major benefits to the organizations in the middle term and the whole enterprise in the long term.

Further details are needed in order to make the above eight STC steps fully operational in practice and implementable on computers. This section gives a background to understand other research areas, such as the Process Modeling, Perspective Analysis and Modeling, and Conflict Management. We provide more explanations on how we model the baseline decision process, how we construct the concept structure for a design campaign, how stakeholder perspectives and PMSDs are modeled, how we perform the perspective analyses, and how we detect and resolve conflicts in the corresponding parts.

[1] It must be noted that workflows and knowledge flows mean very different things in our collaborative engineering research. Workflows define the standard and/or typical operational procedures and necessary steps through which problems are to be solved. They come from company policies and/or domain experiences, and are stakeholder independent. In contrast, knowledge flows are stakeholder dependent, and represent the actual exchanging paths of knowledge among involved stakeholders. In other words, different group of stakeholders can end up with different knowledge flows even when they work on the same workflow. This distinction is important because the STC process starts with an initial workflow to generate the knowledge flows dynamically, and then use these generated knowledge flows to modify (or co-construct) the initial workflow, if necessary, as a means to resolve conflicts.

Home | About STF | Research | Development | Discussion | Resource | Contact