3.7. Plan de Análisis de Datos:
4.1.1. Características de la muestra EDAD DE LA MUESTRA
Now that the skeleton of the system is defined, it is time to concentrate on the functional modules. This organization does not reveal any information about what the receive, sell, and hub processes should look like. Their process models are to be introduced next. Even if such models were existent, the hierarchy will still help in their integration and related fine-tuning. Figure 7 depicts the process for the receive side of the organization.
Following the regular flow of the operation, incoming documents are directed by the hub process. Figure 8 presents a model for the hub operations. Here, documents are sorted, assigned IDs, and dispatched to proofreading groups and then to the customers.
Finally, the sell side is where the edited docu- ment is directed to the customer. Figure 9 depicts a process model for the sell side.
Figure 6. Hierarchy diagram for English Text Doctor
English Text Doctor
Customer Interactions Production
84
Now it is time to integrate the identified component processes. Some modification to the individual processes is possible, hence distorting the isolated views of the component processes in the hierarchy diagram. Still, the hierarchy view will remind us about where the components came from. Actually, the abstract versions of the com-
ponent processes are where the integration should start. The connection for these processes is more important than the internals of the processes. Such connections can be superimposed on the hierar- chy diagram also. Next, the black-box views for the component processes will be considered and their abstracted versions and connections will be Figure 7. A process model for the buy-side process of the English Text Doctor organization (Tanik, 2001)
documents from customer
corrected documents from proof reader
documents sent to interface categorize documents customer distribution of documents pilot interface
determined. Once all the processes are integrated through connections, it is also possible to present a combined process model for the system in detail. For the complex processes that are the focus of this chapter, such a combined model will rarely be used. The hierarchy diagram will be used as a map to direct the designers to the point of interest, and that special area can be studied in detail in the process models for the components. An intermediate model, that is, the black-box processes and their connections, can also be re- ferred to. Figure 10 presents the black-box view for the three actual processes. Here, details are hidden, but the context of a process is presented: Input, output, and related resources are shown with the process.
The integration can be represented on the hier- archy diagram with less detail on the connections as shown in Figure 11. One point can be observed in Figure 11 about the different concerns between the hierarchy diagram and the actual integrated
process. The logical organization of the hierar- chy, which assumes proximities for the processes that are related to the customer, does not provide the best layout in terms of the flow sequence of operations. Positioning the hub between those processes would have resulted in a better picture. It should be remembered here that the hierarchy diagram did its contribution in the determining of the component processes. It is natural to have different views in any modeling for visualizing different concerns.
It is also possible to draw connections among the abstract processes in the hierarchy. This is use- ful if an early idea is desired about the integration before proceeding toward details. Again, it all depends on what needs to be studied on the model. Different copies of the hierarchy diagram can be maintained that present different views, even with partial views. A diagram that only contains the abstract levels, for example, is possible.
Figure 9. The sell-side process model for English Text Doctor
Figure 10. Actual processes and their connections
Customer Documents from customer Documents to hub Final Document Documents to sell Documents from proofreading Documents from receive Customer receive sell hub
Figure 11. Integration through connections in the hierarchy diagram
English Text Doctor
Customer Interactions Production
Receive Sell Hub
This much work seems to be sufficient in the design of an integrated process. However, the actual process model is also required due to the detailed modifications that will appear neither in the hierarchy diagram nor in the black-box inte- gration diagram. The black-box concept means
hiding the details of a unit if its connections are enough to study a system of boxes. In this case, a box corresponds to a process. An integration view that ignores where the processes came from (hi- erarchy diagram) and the internal details (process model for the component processes) is presented
Figure 12. Integration of component processes
Figure 13. Integrated super process in detail Customer Documents from customer Documents to hub receive hub
sell Documents to sell Final
in Figure 12. This view can be constructed by studying the component processes in their ab- stract or black-box forms and their connections as shown in Figure 12.
One point can quickly catch the eye: The cus- tomer icon represented twice in Figure 10 is only drawn once in Figure 12. This is an example of the general statement that an integrated process is not simply a gathering of component processes; some modification may be necessary. Finally, the combined process model for the integrated processes is shown in detail in Figure 13.
integration grounDWork
It is advantageous to support a graphical integra- tion environment with further tools for inves- tigating various concerns. A process engineer can decompose a complex process logically, but then locating existing processes and integrating them will have peculiar difficulties. There maybe technical or theoretical hurdles in composing the super process. Verification tools can detect such problems. Also, the preservation of some attributes of the processes is investigated for the integration. Given the component processes with their existing attributes, a forecasting capability will indicate the attributes for the super process to construct.
For a more instrumental analysis of such issues in integration, more formal representations will be required (Havey, 2005). This section proposes modeling processes and their attributes in task systems (Delcambre & Tanik, 1998) that have also historically provided a theoretical basis for operating systems. The preservation of some process attributes can be investigated through this formal representation (Manzer, 2002). The selected demonstrative set of process attributes comprises efficiency, repeatability, manageability, and improvability. These attributes are indirectly mapped to task features such as determinacy, deadlocks, mutual exclusion, and improvability.
Figure 14. Mapping process attributes to task features
Mapping Process
Attributes Features Task
Efficiency Repeatability Manageability Improvability Determinacy Mutual Exclusion Synchronization Deadlock Mapping
Figure 14 depicts the mapping of process attributes to task features where a process corresponds to one task in the formal system. Such a tool, while being more adept for rigorous analysis, can be utilized for higher level concerns with more subjective evaluation. These decision-supporting measures for integration can be a starting point for the otherwise totally unsupported task of integra- tion. Based on the decisions, specific component processes will be acquired, or it will be possible to assess the infeasibility of the goal.
In the following sections, some process param- eters are investigated and an assessment of their variance due to integration is discussed. It should be reminded that a mapping from the listed process attributes to the addressed task features cannot be a perfect one, nor can the interpretations of the model for high-level process attributes be perfect. This approach equips the decision maker with a tool that will gain efficiency with experience.
task systems
According to Coffman and Denning (1973), concurrently executing processes can interact in a number of undesirable ways if resources are improperly shared or if there is a faulty commu- nication of results (signals) between processes. Generally, the problem is one of timing.
To provide a better understanding of processes, task systems were introduced that model a pro- cess as C = (τ, <·), where τ is a set of tasks and <· represents the partial order (precedence relation) of the tasks. If T is a task, the initiation of T is denoted by T¯ and the termination of T is T_. A superscript bar is used to denote starting up, and a subscript bar denotes closing down. A task with no successor is a terminal task, and one with no predecessor is an initial task. If task T is neither a successor nor a predecessor of T’, then T and T’ are independent. This section will not provide a description of task systems in depth. Some of its constituents will be included in the example process for an analysis of its composition.
The following sections contain discussions about the task features (determinacy, deadlock, mutual exclusion, and synchronization). Since the ordering relations among the tasks in the ex- ample are known, together with the input-output resources, articulation can easily be developed. Also, comments are made about the process at- tributes for the integrated organization based on the task-features discussions.
Determinacy
The super task system is determinate according to the following definition (Coffman & Denning, 1973): “Task system C is determinate if for any given initial state s0, the resource-value sequences depend uniquely on the initial values in s0.”
In our example, the resource-value sequences depend uniquely on the initial values in the initial state. Every task in the super system is noninter- fering as each task is either a predecessor or a successor of another task. Consequently, the super system is determinate. In the super system, the tasks of dispatching to groups and the proofreader interface are indeterminate as the dispatching task depends on the completion of the proofreading. It is stated that repeatability is partially dependent on determinacy (Manzer, 2002). It can be stated that this process is repeatable.
Deadlocks
In the super system, the threat of a deadlock is prevented by preventing circular wait: The circu- lar-wait condition is avoided for the proofreading task. There is a timer connection between the tasks of dispatching to groups and the proofreader interface. After the dispatcher sends the docu- ments to the groups of proofreaders, 48 hours are allowed: If a proofreader does not return a docu- ment by that time, then the document is passed to the next proofreader in the same group. Since resource usage is known in advance, deadlock can be avoided. Still, there is a risk of deadlock if the
0
number of incoming documents (that is, requested resources) is larger than the resources held (that is, the number of proofreaders in a specific group). In order to avoid deadlocks, the number of people in various groups must be greater than the number of incoming documents from customers. There is a high risk of experiencing an unsafe state if the number of documents becomes greater than the number of proofreaders. In order to manage the process, the manager must know the resources used in the process (Coffman & Denning, 1973). Since the number of used resources is known in advance, this process is manageable.