=Paper=
{{Paper
|id=Vol-2408/paper6
|storemode=property
|title=Cause-and-Effect Analysis in the Organizational Engineering Processes of the G.O.D. Organization
|pdfUrl=https://ceur-ws.org/Vol-2408/paper6.pdf
|volume=Vol-2408
|authors=Dulce Pacheco,David Aveiro
|dblpUrl=https://dblp.org/rec/conf/eewc/PachecoA19
}}
==Cause-and-Effect Analysis in the Organizational Engineering Processes of the G.O.D. Organization==
https://ceur-ws.org/Vol-2408/paper6.pdf
Cause-and-Effect Analysis in the Organizational
Engineering Processes of the G.O.D. Organization
Dulce Pacheco1,2 [0000-0002-3983-434X] and David Aveiro1,2 [0000-0001-6453-3648]
1 Madeira Interactive Technologies Institute, Funchal, Portugal
2 Faculty Exact Sciences Engineering, University of Madeira, Funchal, Portugal
dulce@uma.pt, daveiro@uma.pt
Abstract. Nowadays, enterprises are an intricate web and this complexity
frequently originates inefficiencies that commonly turn into the loss of resources
and might even compromise organizations’ viability. Change is a recurrent
necessity, but enterprises have reported to struggle and often fail when
implementing the needed organizational change processes. Change processes
under the G.O.D. Organization often reveal to fail to eliminate or circumvent the
cause of the exception. Based in the seven guidelines for Information System
Research in the design-science paradigm, we argue that the organizational
engineering process should be complemented with a more systematic and broader
investigation of causes, namely by using the Ishikawa approach of cause-and-
effect analysis. The main contribution of this paper is in the improvement of the
organizational engineering processes for the handling of unexpected exceptions
in reactive change dynamics, which should help to reduce recurrent dysfunctions
and keep updated the organizational self and the organization’s ontological
model.
Keywords: Dysfunction, Enterprise engineering, G.O.D. Organization,
Unexpected exception, Organizational engineering.
1 Introduction & Related work
There is a constant demand to have more effective enterprises [1], as workers spend a
significant amount of time handling unexpected exceptions (problems) that cause
dysfunctions (incidents) [2, 3]. The handling of and recovering from exceptions are
pricey processes [3, 4] and may even compromise enterprise’s viability if there is a lack
of a timely and adequate response [2, 5, 6]. Organizations try to minimize the
occurrence of exceptions by better structuring their internal procedures. If the
organization misses to capture the reactive change dynamics and insert it in its reality
and ontological model, the organization will be less aware of itself and less prepared to
deal with change over time [5], leading to organizational inefficiencies.
DEMO (Design & Engineering Methodology for Organizations) is a recent tool that
helps to harness the intricate knot that organizations have become to easily fix
design/analysis mistakes [2, 6]. The Control Organization (CO) [2] and the G.O.D.
2
Organization (GO; generation, operationalization and discontinuation organization) [2]
handle the dynamics of reactive change and allow the modeling of the function
perspective of an organization as a DEMO based design artifact [2, 5, 6]. The GO
implements microgenesis strategies by initiating organizational engineering processes
(OEP) [2, 5] which acts in the case of an unexpected exception, by monitoring,
diagnosing and defining recovery actions [2]. To accurately detect the root cause, actors
need to do a detailed assessment of the dysfunction and exception [7], in the diagnosis
phase of the OEP. Once the cause is identified and the actions are defined, the GO will
generate, operationalize and/or discontinue a certain bundle of organization artifacts
(OA) to eliminate or circumvent the unexpected exception [2], which preserves an
updated organizational self and ontological model [2]. However, the methodology to
detect the exception kind is not defined in the published work [2]. Other researchers
have focused solely on promptly identifying recovery actions to eliminate or
circumvent the dysfunction, not its cause [7]. In the GO, the choice of cause and the
choice of solution are qualitatively evaluated in the Dysfunctions Diagnosis and
Actions Table, but the criteria for this evaluation is also not clear in the model.
Determining why a system is performing poorly is a key task, but is also one of the
major challenges posed by unstructured systems [8]. The complexity to detect the cause
might be related to the fact that a single cause can have multiple effects and an effect
can also have various causes [9]. Discovering the root cause is to identify where
effective action can be taken to prevent dysfunction recurrence [8]. The literature
presents different frameworks to analyze root causes of exceptions [8–10], but the
cause-and-effect methodology (CEM) by Ishikawa is one of the most popular ones [10].
CEM is a problem-solving tool that helps to systematically investigate all the potential
or real causes that result in an exception [9, 10]. CEM clusters causes by categories,
contributing to a more structured and broader analysis [10]. However, CEM does not
conveniently represent the interrelations among different causes and does not
differentiate the strength of various origins [10]. The CEM is usually pictured with four
to six main categories of causes [10] (see Fig. 1). CEM starts by identifying the problem
[10] and then suggests to do a brainstorm to find the exception kind. At this stage is
important to keep asking, in a string of questions and answers, “why did this happen”
until identifying where effective action can be taken to prevent that exception to occur
again [8]. After determining the main causes, actors need to cluster them into categories
and plan the deployment of the necessary actions to eliminate or circumvent the
exception [8].
3
Fig. 1. Example of a cause-and-effect diagram
We believe that considerable benefits may arise from the addition of a systematic
and broader investigation of causes, including the reduction of organizational
dysfunctions and inefficiencies. This approach should reduce the reoccurrence of past
malfunctions and, by dealing with a wider array of causes, should also prevent new
dysfunctions from occurring. In this paper, we present a proposal to include CEM in
the OEP in the GO, for handling unexpected exceptions in reactive change dynamics.
In the development of this model, we applied the seven guidelines for Information
System Research in the design-science paradigm by Hevner [11].
2 Addition of the CEM to the OEP in the GO
Considering previous works, our approach sets the procedure for the exception kind
detection as an iterative process, where different actors can collaborate and actively
contribute with their expertise and competencies [7, 10]. In this stage, the experience
and records play important roles in the accurate understanding of the situation and in
the detection of causes. As singular causality can be utopic [9], our approach entices
actors to look for different causes (that can be real or potential) and then cluster those
causes. We aim to have a model that is accessible by any enterprise and, therefore, our
approach does not establish standard categories, we leave the categories to be defined
within each organization. Our model can be applied either to reactive change or to
proactive change processes.
We have updated the model of the GO to reflect our approach (see Fig. 2 and 3). In
the Object Fact Diagram (OFD) from the Fact Model [adapted from 2, p. 115], we
added the new object class EXCEPTION CATEGORY to store the category of each
cause, as well as the consequent binary fact type ([exception category] created in
[exception kind]) and result ([exception category] has been created) (see Fig. 2). In the
Actor Transaction Diagram (ATD) from the Construction Model [adapted from 2, p.
120], connected to the new result kind specified in the OFD, we added a new transaction
kind called “categorization” and a new actor role, the “categorizer” (see Fig. 3).
4
Fig. 2. Proposal of new partial OFD of the GO [adapted from 2]
Fig. 3. Proposal of new partial ATD of the GO [adapted from 2]
Data associated with the unexpected exception is gathered in the Monitoring,
Diagnosis, Exception and Recovery Table (MDERT), to which we propose some
modifications. We used the example of the MDERT for the case of the library [adapted
from 2, p. 117] to apply our model (see Table 1). To better understand the content of
the MDERT, we added the information about each dysfunction from the Dysfunctions
Table in the column “viability norm” [adapted from 2, p. 106] (see Table 1). The
column “OE process” has a sequential number to identify each OEP and the column
“dysfunction” mentions the number of the associated dysfunction (see Table 1). The
columns “monitoring”, “diagnosis”, and “recovery” include the actions developed
during the corresponding phases of the OEP (see Table 1). The column “exception
kind” specifies the identified cause of the dysfunction (see Table 1).
5
Table 1. Proposal of a new Monitoring, Diagnosis, Exception and Recovery Table (MDERT)
of a library [adapted from 2]
The column “recovery” presents the recovery strategies that are usually defined
based on a quick analysis of the dysfunction and without the analysis of causes.
Therefore, to improve the readability of the MDERT, we argue that the column
“recovery” should be moved to the left, to be just before the column “monitoring” (see
Table 1).
To include the CEM in the GO and register the causes clusters, we propose to add a
column “exception category” (see Table 1). In this column, it should be registered the
category of each exception kind (see Table 1). We argue that each dysfunction can have
more than one cause and, therefore, we modified the MDERT to include more than one
exception kind for each OEP (see Table 1).
3 Conclusions and further work
In this paper, we proposed to add the Ishikawa’s cause-and-effect methodology to the
organizational processes in the G.O.D. Organization. Including a more systematic and
broader analysis of causes will benefit the process of causes’ analysis and,
consequently, contribute to the definition of more accurate actions to eliminate or
circumvent the unexpected exceptions. This approach may reduce organizational
inefficiency and strengthen its viability, as it should reduce the reoccurrence of past
dysfunctions and, by dealing with a wider array of causes, should also prevent new
dysfunctions from occurring. The cause-and-effect analysis may be also applied to the
organizational engineering processes that aim to detect opportunities for improvement
(proactive change). This work contributes to the primary purpose of the G.O.D.
Organization, namely, to preserve an updated organizational self and an updated
ontological model.
As the main limitation, authors identify the lack of empirical proof of the proposed
approach. Consequently, a test pilot with this new model should be conducted, and its
6
results evaluated in terms of choice of causes, selection of solutions, and general
performance of the G.O.D. Organization.
References
1. Dietz, J.L.G.: Enterprise ontology: Theory and methodology. Springer, Leipzig,
Germany (2006)
2. Aveiro, D.S.A.: G.O.D. (Generation, Operationalization & Discontinuation) and
Control (sub)organizations: A DEMO-based approach for continuous real-time
management of organizational change caused by exceptions, (2010)
3. Saastamoinen, H., White, G.M.: On Handling Exceptions. In: Comstock, N. and Ellis,
C. (eds.) Proceedings of Conference on Organizational Computing Systems. pp. 302–
310. ACM, New York, NY, USA (1995)
4. March, J.G.: The pursuit of organizational intelligence: Decisions and Learning in
Organizations. Blackwell Business, Cambridge, MA, USA (1999)
5. Aveiro, D., Silva, A.R., Tribolet, J.: Control organization: A DEMO based specification
and extension. In: Albani, A. and Dietz, J.L.G. (eds.) Lecture Notes in Business
Information Processing. pp. 16–30. Springer Berlin Heidelberg (2011)
6. Aveiro, D., Silva, A.R., Tribolet, J.: Towards a G.O.D. Organization for Organizational
Self-Awareness. In: Albani, A. and Dietz, J.L.G. (eds.) Lecture Notes in Business
Information Processing. pp. 16–30. Springer Berlin Heidelberg (2010)
7. Mourão, H., Antunes, P.: Supporting effective unexpected exceptions handling in
workflow management systems. Proc. 22nd Annu. ACM Symp. Appl. Comput. 1242–
1249 (2007). doi:10.1145/1244002.1244271
8. Smith, G.F.: Quality Problem Solving. ASQ Quality Press, Milwaukee, Wisconsin
(1998)
9. Ishikawa, K.: Guide to Quality Control. Asian Productivity Organization, Tokyo, Japan
(1986)
10. Bilsel, R.U., Lin, D.K.J.: Ishikawa cause and effect diagrams using capture recapture
techniques. Qual. Technol. Quant. Manag. 9, 137–152 (2012).
doi:10.1080/16843703.2012.11673282
11. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design science in information systems
research. MIS Q. 28, 75–105 (2004)