Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
Modeling enterprise operations and organizations for productivity improvement
(USC Thesis Other)
Modeling enterprise operations and organizations for productivity improvement
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
MODELING ENTERPRISE OPERATIONS AND ORGANIZATIONS FOR
PRODUCTIVITY IMPROVEMENT
by
Majid Yahyaei
A Dissertation Presented to the
FACULTY OF THE USC GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
DOCTOR OF PHILOSOPHY
(MECHANICAL ENGINEERING)
May 2010
Copyright 2010 Majid Yahyaei
ii
Acknowledgments
First and foremost, I would like to thank my Ph.D. adviser Dr. Yan Jin, whose
continuing guidance helped me in achieving my goal. Yan has been an outstanding
mentor and taught me a great deal through long hours spent in his office arguing and
refining concepts, ideas and views on research matters. Aside from being an excellent
teacher, Yan is a good friend and mentor who thought me how to do research and how
to deal with intellectual challenges of graduate school.
I would like to acknowledge the members of my committee: Dr. Geoffrey R. Shiflett,
Dr. Yong Chen, Dr. Eva Kanso and Dr. Henrick Flashner. Their constructive
comments and criticisms during my qualifying proposal and on other occasions proved
invaluable and helped me perfect my work and keep it on track.
Next, I would like to thank the USC Mechanical Engineering School staffs. I am
thankful for the great availability and diligence of Samantha Graves and Silvana
Martinez-Vargas who enabled me to carry out the experiments described in this work
in the best conditions possible.
Next, I would like to acknowledge my colleagues from the Impact Laboratory as well,
who through formal and informal discussions have helped me refine this work, and
whose company I have enjoyed over the years. Special thanks go to Ning Kai for his
iii
invaluable contribution in programming some part of the research’s simulation
software.
Next, I would like to acknowledge the great contribution and support from Japan
Marine Science (JMS). Specially, I would like to express my deepest gratitude to Mr.
Yoichiro Suzuki who from early stage of this research helped us in developing the
PMT software. His great effort in helping report bugs and perform case studies has
accelerated the processes of model verification and validation.
Finally, I would like to thank all my family for their support and the fact that they
never stopped believing in me. My parents, Gholamali and Behnaz, and my brother
Mehdi were here for me every step of the way despite the distance. Without their
support and love, perusing PhD would have not been possible for me. I also want to
thank my dear friend, Ilghar, whose love, care and attention helped me surpass the
goals I had set for myself and make me a better person.
iv
Table of Contents
Acknowledgments ......................................................................................................... ii
List of Figures .............................................................................................................. vii
List of Tables .................................................................................................................xi
Abstract ........................................................................................................................ xii
Chapter 1: Introduction ................................................................................................... 1
1.1 Background and motivations ............................................................................... 1
1.2 Research Questions and Approach ...................................................................... 4
1.3 Research Objectives ............................................................................................. 7
1.4 Thesis Overview .................................................................................................. 8
Chapter 2: Related work ............................................................................................... 10
2.1 Introduction ........................................................................................................ 10
2.2 Coordination Research ....................................................................................... 10
2.2.1 Collaborative Engineering ........................................................................ 11
2.2.2 Data Sharing .............................................................................................. 12
2.2.3 Coordination Support ................................................................................ 16
2.2.4 Negotiation and Conflict Mitigation ......................................................... 17
2.2.5 Distributed Artificial Intelligence (DAI) .................................................. 18
2.3 Organizational Science ...................................................................................... 21
2.3.1 Bounded Rationality ................................................................................. 22
2.3.2 Contingency Theory .................................................................................. 24
2.3.3 Task environment and adaption of organization structure ........................ 27
2.3.4 Information Processing View of Organizations ........................................ 31
2.3.5 Task Interdependency and Coordination Policy ....................................... 36
2.3.6 Computational Organizational Science ..................................................... 39
2.4 Business Process Reengineering ........................................................................ 40
2.4.1 Business Process and Business Process reengineering ............................. 40
2.4.2 Workflow Management and Process Modeling ........................................ 42
2.4.3 Activity Based Methodologies .................................................................. 43
2.4.4 Communication Based Methodologies ..................................................... 47
2.5 The Need for a New Approach .......................................................................... 49
Chapter 3: PMT: A Model of Enterprise Operations and Organizations ..................... 54
3.1 Introduction ........................................................................................................ 54
3.2 Assumptions about Enterprise Environment...................................................... 57
3.3 Integrated VS Non-Integrated Models ............................................................... 59
3.4 A Client and Service Model of Enterprise ......................................................... 60
v
3.5 Enterprise Elements ........................................................................................... 66
3.5.1 Extended Information Processing View of Enterprise Organization ........ 69
3.5.2 Enterprise Client ....................................................................................... 75
3.5.2.1 Trend .............................................................................................. 78
3.5.2.2 Milestones ...................................................................................... 79
3.5.2.3 Randomness ................................................................................... 82
3.5.3 Enterprise Process ..................................................................................... 83
3.5.3.1 Interdependence of Activities ........................................................ 85
3.5.3.2 Complexity .................................................................................... 89
3.5.3.3 Uncertainty .................................................................................... 91
3.5.4 Enterprise organization ............................................................................. 92
3.5.4.1 Types of information ..................................................................... 92
3.5.4.2 Attention Allocation of Actors ...................................................... 97
3.5.4.3 Organization Characteristics .......................................................... 99
3.5.5 Enterprise Resources ............................................................................... 103
3.6 Using PMT to Predict Enterprise Performance................................................ 105
3.6.1 Organization performance Quality .......................................................... 109
Chapter 4: System Implementation ............................................................................. 117
4.1 Introduction ...................................................................................................... 117
4.2 System Architecture ......................................................................................... 117
4.3 Enterprise Model .............................................................................................. 121
4.3.1 Client and Service Architecture .............................................................. 121
4.3.2 Client Model ........................................................................................... 122
4.3.2.1 Client Operation .......................................................................... 123
4.3.3 Service Model ......................................................................................... 125
4.3.3.1 Service Operation ........................................................................ 127
4.3.3.2 Decision ....................................................................................... 128
4.3.3.3 Branching (Br) ............................................................................. 129
4.3.3.4 Merging (Mg) .............................................................................. 129
4.3.3.5 Entry/Exit ..................................................................................... 130
4.3.4 Organization Model ................................................................................ 130
4.4 Organization Behavior Matrices ................................................................ 132
4.4.1 Processing Behavior Matrix .................................................................... 132
4.4.2 Exception Behavior Matrix ..................................................................... 133
4.4.3 Decision Behavior Matrix ....................................................................... 134
4.4.4 Communication Behavior Matrix ........................................................... 135
4.5 Human Resource Model ................................................................................... 136
4.6 Simulation Results ..................................................................................... 138
4.7 Computational Issues ................................................................................. 140
Chapter 5: Validation .................................................................................................. 142
5.1 Introduction ...................................................................................................... 142
5.2 Validation Approach ........................................................................................ 142
5.3 Modeling and Analysis Methodology .............................................................. 146
vi
5.4 Truthfulness and Availability of Data .............................................................. 151
5.5 Case Study 1..................................................................................................... 152
5.5.1 Problem Description and Foci of Study .................................................. 153
5.5.2 Modeling ................................................................................................. 154
5.5.2.1 Clients and Services ..................................................................... 155
5.5.2.2 Client Model ................................................................................ 157
5.5.2.3 Organization Model ..................................................................... 161
5.5.2.4 Process Model .............................................................................. 162
5.5.3 Simulation Scenarios............................................................................... 166
5.5.4 Simulation Results and Analysis ............................................................. 167
5.5.5 Case Validity ........................................................................................... 170
5.6 Case Study 2..................................................................................................... 171
5.6.1 Problem Definition and Foci of Case Study ........................................... 172
5.6.2 Modeling ................................................................................................. 173
5.6.2.1 Client and Service Architecture ................................................... 173
5.6.2.2 Client Model ................................................................................ 174
5.6.2.3 Organization Model ..................................................................... 175
5.6.2.4 Process Model .............................................................................. 176
5.6.3 Simulation Scenarios............................................................................... 177
5.6.4 Simulation Results and Analysis ............................................................. 178
5.6.5 Case Validity ........................................................................................... 180
5.7 Case Study 3..................................................................................................... 182
5.7.1 Problem Definition and Foci of Study .................................................... 182
5.7.2 Modeling ................................................................................................. 183
5.7.2.1 Client and Service Architecture ................................................... 184
5.7.2.1 Organization Model ..................................................................... 185
5.7.2.2 Process Model .............................................................................. 186
5.7.3 Simulation Scenarios............................................................................... 188
5.7.4 Simulation Results and Analysis ............................................................. 190
5.7.5 Case Validity ........................................................................................... 195
Chapter 6: Contributions and Future Directions ......................................................... 196
6.1 Contributions .................................................................................................... 196
6.2 Future Direction ............................................................................................... 198
Bibliography ............................................................................................................... 200
vii
List of Figures
Figure 2-1: Research area ............................................................................................. 10
Figure 2-2: PACT experiment [17] ............................................................................... 16
Figure 2-3: Characterization of task and organization structure [61] ........................... 30
Figure 2-4: An engineering model of the communication process [14] ....................... 31
Figure 2-5: Galbraith alternatives for organization adaption [14] ................................ 35
Figure 2-6: Comparison of different terms in BPR [13] ............................................... 41
Figure 2-7: A digraph example ..................................................................................... 43
Figure 2-8: An example of pert/CPM ........................................................................... 44
Figure 2-9: An example of IDEF3 [81] ........................................................................ 45
Figure 2-10: Design structure matrix example ............................................................. 46
Figure 2-11: Petri-Net example [81] ............................................................................. 47
Figure 2-12: Conditions of satisfaction in cction workflow ......................................... 49
Figure 3-1: Different systems within enterprise ........................................................... 56
Figure 3-2: Conditions of satisfaction in action workflow ........................................... 62
Figure 3-3: Mapping of action work flow paradigm to PMT business system ............ 65
Figure 3-4: Client and service architecture of PMT ..................................................... 66
Figure 3-5: Elements of enterprise ................................................................................ 68
Figure 3-7: A market with decreasing demand trend ................................................... 78
Figure 3-8: A simple client with three client operations .............................................. 80
Figure 3-9: Operational client with sequential client operations .................................. 81
Figure 3-10: Operational client with parallel client operations .................................... 81
viii
Figure 3-11: Operational client with cyclic client operations ....................................... 82
Figure 3-12: Randomness in demand function ............................................................. 83
Figure 3-13: PMT sample of process model ................................................................. 85
Figure 3-15: SOP2 is sequentially dependent of SOP1 ................................................ 87
Figure 3-16: SOP1 and SOP2 are reciprocally interdependent .................................... 89
Figure 3-17: Exception reporting and exception handling in organization .................. 95
Figure 3-18: Pseudocode for human daily action cycle .......................................... 98-99
Figure 3-19: Input and outputs to PMT computational model ................................... 106
Figure 3-20: Quality and Delivery Time of Service/Product ..................................... 108
Figure 3-21: Fitness of task environment and organization structure ....................... 110
Figure 3-22: Efficiency and Centralization in a routine task environment ................. 111
Figure 3-23: Quality and centralization in a complex task environment .................... 112
Figure 3-24: Formalization and Organization Matrix Strength .................................. 114
Figure 3-25: Efficiency, Quality and On-time ratio ................................................... 116
Figure 4-1: PMT component diagram ........................................................................ 118
Figure 4-2: Use-Case diagram .................................................................................... 119
Figure 4-3: PMT GUI ................................................................................................. 120
Figure 4-4: Report mode of PMT .............................................................................. 121
Figure 4-5: Clients and services and the relationship among them ........................... 122
Figure 4-6: Simple and operational client .................................................................. 123
Figure 4-7: Simple and operational client .................................................................. 124
Figure 4-8: Uniform distribution with mean μ and variance σ ............................. 125
ix
Figure 4-9: Service model .......................................................................................... 126
Figure 4-10: Precedence and communication link .................................................... 126
Figure 4-11: A simple service model .......................................................................... 127
Figure 4-12: Regular decision ..................................................................................... 128
Figure 4-13: Client based decision ............................................................................. 129
Figure 4-14: Branching and merging .......................................................................... 130
Figure 4-15: Sample organization model .................................................................... 131
Figure 4-16: Skill Level and complexity effects on processing speed ....................... 132
Figure 4-17: Resource effect on processing speed ..................................................... 133
Figure 4-18: Pick up strategy ...................................................................................... 133
Figure 4-19: Exception behavior ................................................................................ 134
Figure 4-20: Decision making and decision maker behavior ..................................... 135
Figure 4-21: Communication behavior ....................................................................... 136
Figure 4-22: Create person dialog for creating new personals ................................... 137
Figure 4-23: Assign persons for each staffs/managers ............................................... 138
Figure 4-24: Service work-breakdown ....................................................................... 139
Figure 4-25: On-time ratio .......................................................................................... 140
Figure 4-26: Simulation performance ......................................................................... 141
Figure 5-1: Client and service architecture ................................................................ 157
Figure 5-2: Client model for direct customer ............................................................. 158
Figure 5-3: COPs for PPMAC .................................................................................... 160
Figure 5-4: COPs for old products .............................................................................. 160
x
Figure 5-5: Organization hierarchy ............................................................................. 161
Figure 5-6: Engineering department organization ...................................................... 162
Figure 5-7: Software department organization ........................................................... 162
Figure 5-8: Process model for application engineering department ........................... 163
Figure 5-10: Bottleneck of processes .......................................................................... 168
Figure 5-11: Number of completed SRIs .................................................................... 169
Figure 5-12: Quality of service ................................................................................... 170
Figure 5-13: Client and service model ........................................................................ 174
Figure 5-14: Project tasks as client operations ........................................................... 175
Figure 5-15: Enterprise and service organization ....................................................... 176
Figure 5-16: Service operations and organizations ..................................................... 177
Figure 5-17: Work breakdown chart of PMT ............................................................ 179
Figure 5-18: Communication quality for different positions ...................................... 180
Figure 5-19: (a) Function based process (b) Product based process ........................... 184
Figure 5-20: Client and service model ........................................................................ 185
Figure 5-21: Task complexity in different design stages of stamping dies ................ 186
Figure 5-22: Product based service model .................................................................. 187
Figure 5-23: Function based service model ................................................................ 188
Figure 5-24: Human resource allocation for simulation scenarios ............................ 189
Figure 5-25: Product based and process based process throughput............................ 190
Figure 5-26: Communication quality of product and function based process ............ 192
xi
List of Tables
Table 5-1: Input parameters for Direct Customer ....................................................... 158
Table 5-2: Input parameters for Customer Service ..................................................... 159
Table 5-3: Input parameters for PPMAC .................................................................... 160
Table 5-4: Input parameters for old products ............................................................. 161
Table 5-5: Input parameters for Application Engineering service operations ............ 164
Table 5-6: Communication table for Application Engineering operations ................. 165
Table 5-7: Input parameters for software development operations ............................ 165
Table 5-8: Communication table for Software Engineering operations ..................... 166
Table 5-9: The project types and required project tasks ............................................. 174
Table 5-10: Skills of designers for different design phases of stamping dies ............ 186
Table 5-11: Skills of designers for different design phases of stamping dies ............ 189
xii
Abstract
Enterprise environments are complex and multidisciplinary. As the market
competition becomes more and more relentless, many business companies have to
keep adapting their current and usual processes to new market needs. Almost
everywhere organizations are undergoing rapid and significant changes driven by such
pressures as customer expectations, new technologies, and growing global
competition. When adaptation is needed, enterprises may or may not have any
experience with the new business needs, leading to high level risks associated with the
adaptation process. There is a strong demand for a comprehensive framework and
methodology which can provide consistent support for practitioners to response the
rapidly changing environments for finding and keeping their “best practices”.
Enterprise models play a critical role in integrating business processes, enabling better
designs for enterprises, analysis of their performance, and management of their
operations. In this research, we introduce a unique framework for enterprise modeling
accompanied by an event driven simulation capability. The overall goal of this
research is to provide a comprehensive framework to systematically support modern
enterprises in adaption of their business practices according to new market needs as
well as new technological changes. To achieve this goal, we firstly identify what kind
of problems enterprise managers may face when carrying out their adaption processes.
We view this problem in a general term as unfamiliarity of managers with the new
enterprise operations, organization design and resource arrangement during and after
xiii
the adaption process. This unfamiliarity causes high uncertainty and anxiety of the
business managers in designing and changing to new processes. We propose a unique
enterprise model, called PMT (Process Management Technology), to provide a
computational and systematic support for industrial or business managers to reduce
their unfamiliarity. Our enterprise model is composed of four sub-models, namely,
Client Model, Organization Model, Process Model, and Resource Model. While
research exists in each of these four areas, little has been done to synthesize the
approaches and apply them in a single enterprise model. In this research, we take an
integrative approach to enterprise modeling by introducing novel concepts and
methods to synthesize the four sub models. We view enterprise business as client and
service interactions, where clients send their requests to an enterprise’s services for
fulfillment. The Client Model represents who the clients are, what they require, and
how they request the services of the enterprise. The Organization Model is built based
on well known organizational theories in which an organization is modeled as an
information processing and communication system structured to achieve a specific set
of tasks with limited capacity and bounded rationality”. The Process Model is defined
by a set of operations, conditional activities, and their successive relations and
interdependencies, and finally the Resource Model is developed to represent enterprise
non-human resources needed for performing operations. Three in-depth case studies
are carried out to demonstrate the effectiveness and utility of the PMT model.
1
Chapter 1: Introduction
1.1 Background and motivations
Enterprise environments are complex and multidisciplinary. Almost everywhere
organizations are undergoing rapid and significant changes driven by such pressures as
customer expectations, new technologies, and growing global competition. As a result,
many business processes within organizations are dynamic and constantly changing.
In order to survive in such environments, practitioners are forced to continually revise
their business processes as well as their organizations to respond quickly to changes.
Typically three kinds of scenario can happen in an enterprise.
1) An enterprise may look into achieving drastic improvement of its current
performance in terms of cost, service quality and response speed. If the
business environmental change is drastic, then they need to develop completely
new processes to deal with the change. Lack of experience with the new
environment forces them to adopt a trial-and-error approach, which can be
highly risky and costly. In the middle of 1990s, Business Process
Reengineering (BPR) [35] was introduced as a solution to manage enterprises
in competitive and changing environments. BPR helps enterprises link their
strategic goals to their key processes and targets drastic changes [35] in
business processes by focusing on process arrangement to improve efficiency,
product quality and to reduce cost. Methods and tools have been developed to
2
help enterprises improve their processes with BPR techniques; however, none
of these adequately support practitioners through all stages of enterprise
evaluation and reengineering. Especially, the current BPR practice pays little
attention to the market and client environment in which the enterprise operates.
In our research, we attempt to help enterprises make drastic moves in the
changing market environment based on organizational theories and computer
simulations instead of merely "experience" and "luck". We also attempt to
eventually provide sophisticated process knowledge base and library to help
enterprises adopt well-established processes and organization forms known to
be effective.
2) The business environment change can be local and dynamic instead of drastic.
There are always bottle necks in different parts of enterprises and detecting
these bottlenecks is of high importance. Usually managers left with no support
in analyzing processes and detecting bottlenecks and they completely rely on
their own experience. In these cases, managers need to make local changes and
they need to predict the change and factor in the impact of the change in the
original process planning phase. A computational enterprise model can provide
effective support for managers by providing quantitative and qualitative
evaluation of enterprise operations. Furthermore, enterprise managers also
need to do quick "fire fighting". That is, once an environment change or
problem is identified, managers must quickly find ways to respond to the
3
problem, such as re-allocating resources, re-routing certain activities or flows,
or adding new process components. Computational tools are needed to
provide computer support for these activities. In addition such tools can be
further developed to provide process monitoring capabilities for tracking
processes and providing guidance to react to potential problems.
3) The business environment change can also manifest itself as shrinking profit
margin and higher labor and technology costs. In these cases, while business
remains the same, companies still have to strive for higher efficiency and
effectiveness by upgrading their current practice to a higher level. Again an
enterprise management tool is needed to provide process design and
management guidelines for managers to analyze the reasons behind shrinking
profit margin and react to them.
Our research addresses the above mentioned problems through enterprise modeling
and simulation. It also creates a potential for enterprise integration to make possible
true information exchange inside and outside a enterprise. In this research, after
identifying critical problems and issues involved in enterprise management and a
critical review of the literatures of organization theory, computational organization
modeling, and business reengineering, we introduce a novel model of enterprise
operations, implement the model as a computational enterprise management support
tool, called PMT (a Process Management Technology), and validate the model and the
4
tool through case studies. New organizational and managerial insights and theories
are expected to evolve through such case studies.
1.2 Research Questions and Approach
In the previous section we described practical problems we face in enterprise
modeling and integration. In this section, we will present our perspectives to view
these practical problems and clarify research questions that need to be addressed in
this research in order to provide effective solutions for these problems.
Research Question 1: What are the key concepts and relations in modern enterprises?
What are the intra- and inter-relationships in modern enterprises? How can we
maintain a balance between generality and powerfulness of an enterprise model when
developing such a model?
One key theoretical issue we must address in this research is the lack of sound and
complete foundation for modeling and analyzing enterprises. In this research, we view
an enterprise model as a computational representation of the structure, activities,
processes, information, resources, people, behavior, goals, and constraints of a
business, government, or other enterprises [27]. This model should be general enough
to cover a wide range of different enterprises and also powerful enough to capture real
case scenarios and provide specific and useful management guidance.
5
Research Question 2: How can we embed a modern enterprise in social, political and
technological changing environment?
With the power of internet, our world is changing every day. Adapting to this
continuously changing environment is very important for today’s enterprises.
Enterprises should adapt their business according to new political situations, social
trends and technological advances. For an enterprise model to be effective and
reliable, it should take all these dimensions into consideration.
Research Question 3: How to model enterprise operations and their relationship with
enterprise organization and resources? What are the dependencies among operations,
organizational actors, and resources and how they should be represented in an
enterprise model?
The core of every enterprise is its operations. To compete in today’s market, a modern
enterprise should have a clear picture of its operations. Capturing how an enterprise
operates in real world and representing it in a conceptual as well as computational
model is a major task for this research. Workflow management systems usually consist
of a process model and an organizational model. Although research in process
modeling has been relatively matured, organization modeling and simulation is still
new in the literature. Existing systems usually fail to provide a model for integrating
both human actors and non-human resources (e.g., data base systems and CNC
6
machines) into the system [5]. Our enterprise model should correctly represent task
dependencies and relationships of human actors and non-human resources to
enterprise operations.
Research Question 4: How to validate the model and simulation results? What are the
validation steps? How real case studies should be performed?
For a computational model to be reliable, it is not enough to be built based on well
approved theories. It should be tested and validated with real world case scenarios.
The testing and validation activities will go from testing simple scenarios to very
complicated real world cases in order to make sure the emergent behavior of the
model based simulation matches the real world enterprise behavioral results.
Research Question 5: How can a manager do analysis, planning and designing of his
or her enterprise with the help of an enterprise model such as PMT?
To remain competitive in today’s market, enterprises need to be agile. Agility implies
the ability to “continuously monitor market demand; quickly respond by providing
new products, services, and information; quickly introduce new technologies; and
quickly modify business methods” [56]. Enterprises need a reliable model of their
operations and a computer support to improve their agility. Furthermore, they need
7
methodologies and guidelines for modeling, analyzing, planning, and designing their
enterprise operations and organizations as well as allocating their resources.
1.3 Research Objectives
Overall, the purpose of this research is to understand the nature of enterprise modeling
and integration and develop a new approach to improve the effectiveness and
reliability of enterprise models based on well approved theories. The result of this
research is a solid framework for systematically supporting enterprise modeling,
analysis, and design. Furthermore, the framework serves as a conceptual basis for
building a computer and network based system for process execution and
management. To address the research questions described above, we set up the
following research objectives.
Research Objective 1: Define and validate the top level Client-Service paradigm of
enterprises in doing their business transactions.
Research Objective 2: Identify different parts of modern enterprises and develop an
activity based enterprise model to represent both internal and external elements of an
enterprise.
Research Objective 3: Define micro-level behavior of organizational actors based on
well accepted organization theories.
8
Research Objective 4: Elaborate conceptual, mathematical and graphical
representation techniques to meet the needs of enterprise process description.
Research Objective 5: Develop analytical measurements to evaluate customer
satisfaction, service quality and efficiency as enterprise performance.
Research Objective 6: Implement the enterprise model and make it a useful tool for
case studies, model validation and theory generation.
Research Objective 7: Evaluate the impacts of the proposed approach by testing and
validating it with realistic industrial case scenarios.
1.4 Thesis Overview
This thesis is composed of seven chapters including this chapter. The content of the
rest of the chapters are briefly described as follows:
Chapter 2: Related Work - An extensive review of the literatures related to this
research is presented in this chapter. We will review the relevant research results in
coordination research, business process reengineering, and organization science.
9
Chapter 3: PMT: A model of enterprise operations and organization – The overall
framework is presented in this chapter. The four sub models, namely, client model,
organization model, process model, and resources model are described.
Chapter 4: System Implementation – This section describes the JAVA based
software that is written based on the model described in chapter 3.
Chapter 4: Validation – This section describes the real world case studies using the
PMT modeling tool and discusses the results of the case studies for validating our
proposed enterprise model and modeling methodology.
Chapter 5: Contributions and future directions – The contributions of this research
to the fields of enterprise modeling and computational organization theory are
described, and future directions of this research are presented.
Bibliography – The references cited in the thesis are listed in this section.
10
Chapter 2: Related work
2.1 Introduction
Our research aims at building a framework for enterprise modeling and integration
through object-oriented modeling and computational simulation. Our approach
integrates well established theories from different research areas and identifies the
relations between them. This research departs from three fields of research, namely,
coordination research, business process reengineering and organizational science as
shown in Figure 2-1.
Figure 2-1: Research area
2.2 Coordination Research
Coordination research in general deals with how people work together. Social
scientists focus on organizational behaviors and developed organization theories to
11
explain these behaviors. Computer scientists attempt to facilitate human working
together by developing communication and planning support tools. In addition, they
are also developing theories and technologies to allow multiple computer systems or
agents to work together. Research in collaborative engineering are more focused on
providing coordination solutions for solving collaborative engineering problems and
tasks. In this section, the relevant research in these areas is briefly reviewed.
2.2.1 Collaborative Engineering
Computers have a great role in today’s engineering activities. While growing use of
computer tools has expedited individual tasks, it has also exacerbated coordination
difficulties as information tends to get dispersed and embedded in multiple, non-
interoperable systems [58]. There are three basic issues involved providing computer
support for collaborative engineering design as following [44]:
Task Decomposition and Representation: is concerned with identifying the subtasks
that can be divided in the way that minimizes interactions among the subtasks.
Through the life cycle of a product, tasks and the interaction between subtasks need to
be represented in an efficient way to be handled easily by designers and computers.
Communication Infrastructure: to facilitate communications among designers.
Since in most cases complete task decomposition, i.e., no interaction exist among
subtasks, is impossible, a sophisticated communication infrastructure is needed to
12
facilitate flow of information among designers. This perspective looks into
communication technology need to be developed for an efficient engineering
collaboration.
Coordination Support: Coordination is the activity to resolve dependencies among
sub-tasks. From a designer’s point of view, coordination means to take other
designers’ decisions into consideration in making local decisions as well as to provide
information for other designers as needed. Active coordination support should help
designers identify needs for coordination, create contents of communication to address
the needs, select relevant parties to send the communication and resolve conflicts
among the coordinating parties if any.
In recent years researchers explored different methods to address one or many of the
above issues in engineering collaboration. They took different approaches which can
be categorized as below.
2.2.2 Data Sharing
Data sharing mostly falls into the second problem mentioned above about computer
supported collaborative design. The data sharing approach allows designers to share
product model. Designers can timely retrieve design results of other designers and
pass his or her results to other s through the product model [17].
13
There has been a lot of research in this area, and a big part of it is focused on
collaborative CAD design. Chen et al [11] proposed a co-assembly representation
including Master Assembly Model (MAM) and Slave Assembly Model (SAM). Kim
et al [47] introduced a design formalism to capture the non-geometric perspective of
designer’s intention in a co-assembly design environment. On the collaborative side,
Lu et al proposed a frame work to capture and represent design modification in a
collaborative assembly design environment and Bidarra et al [7] proposed a
collaborative framework for integrated part and assembly modeling. in this
framework, the team members can discuss the assembly design issues through a
collaborative validity maintenance scheme including phone, chat channel, shared
camera, etc. All of the above approaches have been effective for design information
exchange and avoidance of design inconsistencies. But they lack to provide any
guidance for designers to coordinate with each other.
Cutkosky et al [17] investigated data sharing and interoperability between different
engineering subsystems and disciplines. The Palo Alto Collaborative Testbed (PACT)
is a concurrent engineering infrastructure that encompasses multiple sites, subsystems,
and disciplines [17]. PACT was developed by the research groups at Stanford
University, Lochheed, Hewlett-Packard, and Enterprise Integration Technologies. The
PACT integrates the following four preexisting concurrent engineering systems into a
framework:
14
• 5Visage: A distributed knowledge-based integration environment for design
tools developed by the Lockheed Information and Computing Sciences Group
[78]
• Device Modeling Environment: A model formulation and simulation
environment from the Stanford Knowledge Systems Laboratory [42].
• 5ext-Cut: A mechanical design and process planning system from the Stanford
Center for Design Research [18].
• Design world: A digital electronics design, simulation, assembly, and testing
system from the Stanford Computer Science Department and Hewlett-Packard
[32].
The PACT architecture is based on interacting agents. The agent interaction relies on
three things [17]: 1) shared concepts and terminology for communicating knowledge
across disciplines, 2) an Interlingua for transferring knowledge among agents, and 3) a
communication and control language that enables agents to request information and
services.
The interactions are standardized by defining message content at three levels:
• Messages are expressions in a common agent communication language that
supports knowledge-based operations. They used Knowledge Query and
Representation proposed by finin [26].
15
• Message contents of knowledge-based operations are expressed in a common
knowledge-interchange format that provides an implementation-independent
encoding of information. Knowledge Interchange Format (KIF) was proposed
for this purpose [32].
• Expressions stated in the interchange format use a standard vocabulary from
common ontologies that are defined for the shared application domain.
Application of PACT was demonstrated by a robotic device example. In this
experiment, each system modeled different aspects of this robotic device and reasoned
about each aspect from a specific engineering discipline. The different elements of the
systems then cooperated to produce a distributed device simulation and synchronize a
subsequent design modification. Fig 2.2 shows the PACT’s manipulator system and
division of the responsibilities for each section.
16
Figure 2-2: PACT experiment [17]
2.2.3 Coordination Support
Collaborative Engineering Environments necessitate a powerful and flexible
transaction management framework to temporally coordinate the concurrent activities
of multiple users. The key requirements for supporting coordination in a collaborative
engineering environment are [69] :
• The transaction framework should be dynamic, so as to support highly
interactive, iterative, and interleaved engineering transactions.
• Locking mechanisms, including appropriate security controls, must be
interactive and flexible enough to allow multiple transactions to proceed
17
concurrently without having to wait indefinitely for other transactions to
complete.
• Extensive records of the clients/ agents and their activities must be maintained,
to include the data used, dependencies between clients and data, and time-
stamping of data and operations.
• Design decision-making assignments and records must be implicitly captured
within the transaction management framework.
2.2.4 5egotiation and Conflict Mitigation
Negotiation and conflict mitigation can be viewed as a part of Coordination support.
Conflicts are usually caused because of different perspectives among designers during
product life cycle. These conflicts are the main reasons behind expensive designs and
delays in delivery of products. One reason for conflicts is that designers do not have
enough information about other designers’ or stakeholders’ objectives. Designers
cannot bring sufficient reasons for rejecting or accepting other designer’s alternatives.
Therefore, effective negotiation and conflict management techniques are critical for
mitigating conflicts. Taxonomies of design conflicts and design rationale encoding can
significantly facilitate conflict mitigation strategies [69]. Additionally, techniques
developed in economics, mathematics, and political science can provide knowledge to
be used to enhance the effectiveness of negotiation approaches [69].
18
The optimization Community has approached this subject as a multi-objective
optimization problem [48] where weighting factors are assigned to various
stakeholders in order to search for a set of Pareto Optimal solutions for the group. This
approach, although mathematically rigorous, requires significant prior knowledge of
the stakeholders and assumes their prospective remain static during the collaborative
process [50]. Researchers in the group decision-making community view collaborative
engineering as a multi-player interaction task and model it using game theoretic
approaches in order to find various optimal game playing strategies [57]. While these
models have sound theoretical bases, they often lack close relevance to practical
situations due to the strong requirement of pre specified penalty functions [51].
Constraint network is another approach towards collaborative conflict mitigation
problem. Researchers in this community model concurrent design problem as the
recognition, formulation and satisfaction of constraint according to different product
life cycle. There different sets of constraints, such as a set of mathematical equations,
symbolic predicates, rules, objects, rational databases, tree, and graphs. A review of
constraint modeling and problem solving can be found in [63].
2.2.5 Distributed Artificial Intelligence (DAI)
Distributed artificial intelligent (DAI) aim to solve problems using the knowledge
provided in different computers through computer networks. Advances in research of
distributed artificial intelligence break into concurrent engineering and enterprise
19
modeling and integration as well. Enterprise integration is a very important topic for
modern enterprises. An enterprise computational model with a capability of analysis
and reengineering is not enough for today’s enterprises. Multi agent system
application is a very promising approach as a foundation for enterprises to build
computer and network based system framework for processes execution and
management on top of it. DAI systems have promising advantages as follow:
• System modularity: Because different knowledge based systems are developed
as independent modules, these systems can be easily maintained.
• Efficiency: A problem can be solved using the power of a number of networked
computers faster than single computer.
• Multiple Perspectives: Diverse people build their models using different
components from different perspective.
• Distributed Problems: The data and knowledge are inherently distributed on
distinct physical locations for the problem solving.
• Reliability: Because of the computer network, when one system fails, it is still
possible to achieve the solution using other systems.
DAI systems use various protocols for communication of intelligent agents. The key to
developing multi agent systems is to design collaboration mechanism among agents.
There have been various mechanisms introduced as follow:
20
Contract 5et: A contract net mechanism is used to identify the agent that can best
solve the problem [21].In a contract net mechanism; agents are classified into two
categories: manager agents and contractor agents. The procedure of communication is
as follow. Firstly a manager agent announces the problem to be solved to all potential
contractor agents. Secondly, each contractor agent evaluates the task with respect to its
own capability. If it can solve the problem, then it makes a bid to the manager agent.
Finally, the manager agent chooses the contractor agent that provides the best bid
condition.
Blackboard System: A blackboard system mechanism provides a shared database,
called a blackboard that can be accessed by different knowledge sources. Three types
of elements usually exist within a blackboard system:
• A set of knowledge sources to describe domain specific knowledge.
• A blackboard to preserve the shared data through which the knowledge sources
communicate with each other.
• A control system to decide when and which knowledge source should be used.
The blackboard system approach was first introduced in the context of the
HEARSAY-II speech-understanding project [23].In this system, knowledge sources
correspond to the recognition of speech elements at different levels: syllables, words,
phrases, sentences, and so on. Cougaar [40] as a java-based, open source Darpa project
uses Blackboard system for agent communication. This multi agent platform is very
21
suitable for our computational enterprise model, to be used as a computer and network
based system framework for processes execution and management.
Message-Passing: A message-passing mechanism is similar to the message passing in
object oriented systems. Each agent has an extensive knowledge of other agents’
capabilities. When and agent cannot solve a certain problem, it request other agents
who are capable of doing the problem to solve it. Upon receiving the message, the
receiver agent starts problem solving using its knowledge and sends the solution back
to the sender.
2.3 Organizational Science
In this chapter we describe fundamental organizational theories that are used in our
computational organization model. We have mainly inspired by the fundamental work
of simon [66][67] in artificial intelligence, Thompson [74] and Galbraith [29][30] in
contingency theory. We first introduce bounded rationality and contingency theory as
two important theories behind our computational model. Later, we describe task
environment and the relationship between the environment and organization structure.
Then we describe Galbraith information processing view of organization which is
inspired by the above two theories. Later in the chapter, I review Thompson
categorization of activity interdependence. Finally we introduce some well known
computational organization models in literature.
22
2.3.1 Bounded Rationality
Models of bounded rationality [68] introduced by Professor Herbert A. Simon has
been a key foundation for many theories in organizational science, computer science,
political science, psychology, economics and other fields. Simon has pioneered the
research on bounded rationality and intellectual effects of his work made lots of
contribution in understanding of humans about organization, computers and
psychology. His model aims to represent how limited rational humans make decisions
and solve problems under different environments. He views human beings as bounded
rational entities where there are computational and informational limits to human
rationality. These natural human’s limits affects human’s decisions and Simon used
cognitive and psychology science to study how human beings make decisions under
the influence of bounded rationality. March [52] summarized Simon’s idea as:
It started from the proposition that all intendedly rational behavior is behavior within
constraints. Simon added the idea that the list of technical constraints on choice
should include some properties of human beings as processors of information and as
problem solvers. The limitations were limitations of computational capability, the
organization and utilization of memory, and the like. He suggested that human
beings develop decision procedures that are sensible, given the constraint, even
though they might not be sensible if the constraint were removed. As a short-hand
label for such procedures, he coined the term satisfying.
Simon describes human beings as “satisfying” rather than complete, meaning that in
dealing with problems, they tend to satisfy the constraints according to their
informational and computational capacity. Simon brings this idea into organizational
theories and with collaboration of March [53], they made lots of contribution in
understanding of decision making in organizations. Most of the models in
organizational theory assume humans as “rational” entities. They assume human
23
beings never do any action to violate their preferences (rational choice of
humans).Simons’ idea breaks through this area by revising “rational” models to
“boundedly rational” model of human beings adding the informational and
computational limits. When dealing with organizational behavior of humans, Simon
sometimes use the term “procedural rationality” interchangeably with bounded
rationality. He views human mind with limited capacity of attention and information
processing in dealing with organizational work. This idea has been a fundamental
foundation for our computational model organization, where human actors are entities
capable of allocating their attention to various work items and focus on each item as
an information processing activity.
Simon’s model of bounded rationality also had a tremendous contribution in artificial
intelligence. He has introduced “boundedly rational agent” as intelligent agent with
limited computational and informational capacity. His model of intelligent agent takes
into consideration that utility functions agents poses might have some limitation which
make agent not to behave completely rational. This model recognizes that gathering
information by communication or exploration is associated with some computational
costs and agents do not always tend to accomplish optimal solutions. Based on this
model many bounded rational agents have been introduced and applied to practical
problems.
24
2.3.2 Contingency Theory
The main proposition of contingency theory is that there is no best way of organizing
an organization. A successful organization design in one situation might not be
successful in different situation. Therefore the design of the organization and its sub-
systems should be performed according to the type of environment. There have been
many versions of contingency theory in literature, but we take Galbraith [29][30] and
Thompson [74] version of contingency theory because of their clarification about the
relation of organization and the surrounding environment. Galbraith also particularly
studies human’s activity as a part of his contingency theory which leads to his model
of information processing of organizations.
The main objective in Thompson’s version of contingency theory is to describe how
organizations “strive to be rational although they are natural and open system” [61].
Therefore he strive to answer the question of “how and organization can function as a
rational system, given that and organization is open to the uncertainties of
environment” [61].
Parson [53] defines three major levels of organizational structures namely as the
technical, managerial and institutional. According to his work, Thompson [29]
describes how different models of organization should be adjusted to fit to these
different levels of the organizations. At technical level, it is expected that the operation
of the core technology conform to a rational systems. While in institutional level, the
25
uncertainty of the surrounding environment has a tremendous effect and the system
behaves as an open system. Lastly, the purpose of the managerial level is to mediate
institutional and technical levels. Therefore, Thompson stated that:
We will conceive complex organizations as open systems, hence indeterminate and
face with uncertainty, but at the same time as subject to criteria of rationality and
hence needing determinateness and certainty.
Thompson defines the environment in terms of two dimensions, homogenous vs
heterogeneous and stable vs. dynamic. He describes these dimensions as [74]:
The more heterogeneous the task environment, the greater the constraints presented
to the organization. The more dynamic the task environment, the greater the
contingencies presented to the organization. Under either condition, the organization
seeking to be rational must put boundaries around the amount and scope of adaption
necessary, and it does this by establishing structural units specialized to face a
limited range of contingencies within a limited range of constraints.
Thompson [74] proposed a set of proposition about actions organizations need to take
under norms or rationality as follow:
• Complexity leads to differentiation (Proposition 6.1 [74]): organizations seek
to identify homogenous segments and establish structural units to deal with
each segment, when they are facing heterogeneous task environments under
norms of rationality
• Simplicity allows standardizing, and creating new units based only on
capacity constraints (Proposition 6.2 [74]): Under norms of rationality, cross
boundaries components facing homogenous segments of the task environment
are further subdivided to match surveillance capacity
• A stable task environment leads to further formalization (Proposition 6.2a
[74]): To Adapt to a stable task environment organizations rely on rules.
26
• Certainty leads to formalization (Proposition 6.2b [74]): In the situations
where the range of variation of the task environment is well known, the
organization component adapt to this environment by standardizing sets of
rules.
• Unpredictability leads to decentralization (Proposition 6.2c [74]): In the
situations where the range of variation of task environment is relatively high
and unpredictable, the organization component adapts by monitoring its
environment and planning responses. This type of action requires the call for
localized units.
• Sequential interdependency is dealt with by hierarchical planning and
supervision (Proposition 6.3 [74]): Under norms of rationality, if the
technical and boundary spanning activities can be isolated, organizations adapt
by becoming centralized providing different managerial levels of hierarchies.
Galbraith [29][30] summarized the main idea of contingency theory with two
assumption as “There is no best way to organize (1), but not all ways of organizing are
equally effective (2)”. Scott [61] added the third assumption which completes the
contingency theory:
There is no best way to organize, but not all ways of organizing are equally effective,
and the best way to organize depends on the nature of environment to which the
organization relates
27
2.3.3 Task environment and adaption of organization structure
Discussing Thompson and Galbraith’s version of contingency theory, in this section
we describe the basic characteristics of task environment and how organization adapt
itself according to the above discussion. Although many researchers investigated
different dimensions of task environment, but there is no unique agreement about it.
The most well approved categorization of task environment comes from Thompson
and Scott [74][61]. Thompson [74] describes the basic characteristics of the task
environment as its uncertainty and complexity. He also separately addresses the
relationships of tasks within organization as activity interdependence. In a similar
approach, Scott [61] describes the task characteristics as three underlying basic
dimensions namely complexity, unpredictability and interdependence. He describes
these terms as follow:
• Complexity: the number of elements and sub-elements in the task environment
that must be simultaneously dealt with by organization.
• Unpredictability: to what extend the variability of task elements and sub-
elements are predictable. This term is named uncertainty in Thompson’s work.
• Interdependence: To what extend tasks are dependent with each other, so a
change in one affects other tasks.
Recognizing the basic dimension of task environment, scott [61] identified important
dimensions of organization structure and related them to these basic task’s
28
dimensions. He identified three important dimensions for organization structure as
differentiation, decentralization, and formalization. He distinguishes these terms as:
• Differentiation: the degree to which the organizational tasks are divided into
different sub-units.
• Decentralization: the degree to which authority is given to lower managerial
levels in organizational hierarchy.
• Formalization: the degree to which organization performs by rules, standards
and procedure.
Scott [61] then proposes sets of propositions as alternatives available to organization
in dealing with different types of task environment. He describes the relation between
task environment and organization structure from natural and rational system
perspective [61]:
• Rational systems overcome increased complexity with structural
differentiation: Contingency theory says the complexity in the environment
will lead to a more elaborate organization structure. In facing increased level of
complexity in the task environment, organization as rational system should
seek structural differentiation.
• 5atural systems overcome increased complexity with professionalization:
Complexity of the task environment can be overcome by professionalization. It
means that natural systems respond to increase complexity of task, by
increasing the complexity of performer. Organization structure remains
29
unchanged but only the actors gain more knowledge through training or hiring
more professional performers.
• Rational systems overcome increased unpredictability with
decentralization: Decentralization of decision making activity is the rational
response of a rational system under increased level of unpredictability. In the
face of increased unpredictability number of decisions increases and many re-
planning is required, hence organization seeks to overcome this task
environment by involving lover level actors in decision making and relief
higher level managers.
• 5atural systems overcome increased unpredictability by deformalization:
In the face of increased unpredictability, deformalizing the decision making
and communication is preferred by a natural system. The rules and standards
require a predictable task environments and decision making in deformalized
way is a natural response of an organization in dealing with increased
unpredictability.
• Rational systems overcome increased interdependence by formalization:
using formalized coordination is preferred by a rational system in the face of
increased interdependence between tasks. Formalizing the coordination
increases the communication bandwidth, lead to more coordinated activity.
30
• 5atural systems overcome increased interdependence by increasing
responsibility of actors: In the face of increased interdependence between
tasks, actors are required to take more individual responsibility.
Task Characteristics Rational System Response 5atur al System Response
Complexity Differentiation Professionalization
Unpredictability Decentralization Deformalization
Interdependence Formal Coordination Increased Autonomy
Figure 2-3: Characterization of task and organization structure [61]
The summary of above discussion is shown in figure 2-3. There have been many other
researches in characterizing task environment and organization structure. Mintzberg
[55] described four dimensions for task environment as stability, complexity, market
diversity and hostility and relates them to various organization structures. He
categorized coordination into standardization of work process, standardization of
outputs, direct supervision and mutual adjustment and studied each coordination
strategy in different task environment. Duncan [22] described task environment with
two dimensions as simple-complex and static-dynamic. He showed in his work that as
the environment of task moves toward a complex and dynamic environment, subunits
face experience the greater amount of uncertainty in decision making [22]. In our
computational model, we have mainly adapted fox’s characterization of task
environments and organization structure and modeled them correspondly. The full
description of organization behavioral matrix and relations with human actor’s
behavior can be found in Appendix.
31
2.3.4 Information Processing View of Organizations
In a cybernetic model of communication [64], information processing is represented at
the signal level in terms of nodes and communication channels [14]. In this model
receiver and sender on two sides of communication channel pass messages together,
and “encoding changes this message into the signal which is actually sent over the
communication channel from the transmitter to the receiver’s decoder” [64]. This
communication model is illustrated in figure 2-4 .
Figure 2-4: An engineering model of the communication process [14]
A meaning of communication channel within the organization context is
conceptualized by [14] as:
The tools, relations and behaviors relevant for describing the structure and
characteristics of communication taking place in the organization. The fact that
information is regularly communicated between actors focuses the organization on
communication. The act of communication occupies the time and attention of the
organization, which necessarily restricts the time and attention devoted elsewhere.
Thus communication, in a very real sense, is an important factor in determining
organizational performance.
32
Galbraith [29][72] views organizations as information processing nodes linked by
communication channels. He developed an information processing model of
organization based on contingency theory. His model has a main proposition as [29]:
The greater the task uncertainty, the greater the amount of information that must be
processed among decision makers during task execution, in order to achieve a given
level of performance.
In developing his model, Galbraith characterized the task environment in terms of
diversity, variability and difficulty. He separately defined complexity as an important
issue where tasks are involved with reciprocal interdependence and are not well
understood. Therefore, in the case of complex interdependence, coordination and
mutual problem-solving load increases correspondingly [29]. On the other hand,
routine tasks with less level of interdependence can be preplanned, and require less
amount of information processing. He integrates the three dimensions of task
environment (diversity, variability and difficulty) into a single characteristic and calls
it uncertainty. Thus, the amount of diversity, variability and difficulty determines the
amount of uncertainty associated with task environment. This integration, lead to his
uniform representation of tasks in terms of information processing requires for
execution. He [29] stated his idea as “Difference between the amounts of information
required to perform the task and the amount of information already possessed by the
organization.”
Adapting fox [61] characterization of task environment the relationship between
various characteristics of the environment and the information processing
33
requirements can be thought of in terms of the product of complexity; uncertainty and
interdependence, therefore the effect of environmental factors are multiplicative [14].
By unifying the representation of tasks, Galbraith described organization design
problem as creation of adequate information processing to permit coordinated action
across integrated roles [31]. He identified three mechanisms for coordination namely
called “coordination by rules and programs”, “coordination in the hierarchy”, and
“coordination by targets and goals”. Coordination by rules and programs is used to
coordinate routine tasks. Coordination in the hierarchy is used when an organization is
facing higher level of uncertainty. Finally, coordination by goals and targets is used to
reduce the information processing in the hierarchy and allows more decision making
in lower levels. Most of the organization combine these mechanism in doing their
coordination and portion of each mechanism depends on the type of task environment.
Galbraith defined a term “exception” which determines the portion of the above
coordination mechanism. If the information required for solving a task is not available
at the processing node, an exception is generated [72]. This lack of information should
be required by human actors via communicating with other actors which usually are at
higher levels in organizational hierarchy. This action then, puts some communication
load on higher level managers and also occupies communication channels between the
actors. Two possible scenarios in the case of increased exceptions are first overloading
the actors with communication request and second clogging of communication
channel which lead to poor organization performance. Galbraith describes this
behavior as [72]:
34
As the uncertainty goes up, the number of exceptions rises, and thus leads to an
overload on managers. Subordinates spend increasing amounts of their time waiting
for managerial decisions and thus poor performance results.
As the task uncertainty increase beyond the capacity of the hierarchy, organization
design action must be taken to either reduce the amount of information to be processed
or to increase the information processing capacity [14]. Galbraith introduced four
actions that organization may take to overcome increased uncertainty.
• Introduction of Slack resources: In order to keep the amount of information
processing load within the organization capacity, organizations may use slack
resources [31]. This can be achieved by reducing the number of exceptions that
need to be handled. This will reduce the required level of performance and the
amount of interdependence between subunits [53].
• Creation of Self Contained Tasks: The main purpose is to change task
grouping from functional based to product based and give each task the
resources it needs to supply its product [31]. Uniform representation of output
and reduction of the labor diversity, reduces the information processing load.
Then it is expected that fewer exception should be generated and less
coordination will be needed for the task environment.
• Investment in the Vertical Information System: Move the organization to
more centralization and increase the volume of communication within the
hierarchical channels. This requires increasing of the bandwidth of
communication channels and information processing speed of human actors.
35
This option usually involves building specialized languages and computer
systems for decision making and re-planning.
• Creation of Lateral Relationships: involves moving decision making down in
the organization where information exist [31]. This requires joint decision by
decision maker in same level of organizational hierarchy and therefore
increasing of information processing capacity of the organization. Some
alternatives to create lateral relationships in ascending order of cost and
complexity are direct contact, liaison roles, task forces, teams, dual reporting
relationships and matrix structures [29].
The first two alternatives discussed above aim to reduce the information processing
load and the last two aim to increase information processing capacity. Figure 2-5
shows these alternatives in organization hierarchy (adapted from [14]).
Figure 2-5: Galbraith alternatives for organization adaption [14]
36
Given increasing information processing load, a corporation may choose one or
several of the above alternatives to either increase its information processing capacity
or decrease the information processing load. Galbraith makes a conclusion about the
above alternatives as [31] “The organization must adopt at least one of these strategies
when faced with greater uncertainty. If it does not choose one, then slack, reduced
performance standards will happen automatically.”
2.3.5 Task Interdependency and Coordination Policy
Tasks in an organization are not isolated and they are dependent on each other.
Thompson’s work [74] in characterizing interdependence of tasks has been the most
well approved study in organizational science. He categorizes the interdependence of
tasks into “pooled interdependence”, “sequential interdependence” and “reciprocal
interdependence”. In the order introduced, these three types of interdependence are
increasingly difficult to coordinate because they contain increasing degrees of
contingency [74]. He describes the pooled interdependency the situation as [74]
“Each part renders a discrete contribution to the whole and each is supported by the
whole. We will call this pooled interdependence.”
This type of dependency happens when one branch of an organization does not
interact at all with other branch. But they may be interdependent in the sense that
unless each performs adequately, the total organization is jeopardized; failure of any
one can threaten the whole and thus the other parts [74].
37
The second form of interdependence is referred as sequential interdependence,
referring to situation where in addition to pooled interdependence direct
interdependence can be pinpointed between tasks. . If activity A should start only
after completion of activity B, then they have sequential interdependency. This type of
interdependency is directional and not symmetrical.
The third form of interdependence if referred to reciprocal interdependence to the
situation where the outputs of each tasks become the inputs for the other task.
Thompson describes this interdependence as [74]:
Under conditions of reciprocal interdependence, each unit involved is penetrated by
the other. There is, of course, a pooled aspect to this, and there is also a serial aspect.
But the distinguishing aspect is the reciprocity, of the interdependence, with each
unit posing contingency for the other.
Defining all types of interdependency, Thompson stated that all organizations have
pooled interference, as they get more complicated sequential interdependency will be
added, the most complex organizations have all three interdependencies. Hence
knowing that an organization contains reciprocal interdependence automatically tells
us that it also contains sequential and pooled interdependence [74]. Finally Thompson
summarizes these categorizations as [74]:
With pooled interdependence, action in each position can proceed without regard to
action in other positions so long as the overall organization remains viable. With
sequential interdependence, each position in the set must be readjusted if any one of
them acts improperly or fails to meet expectations. There is always an element of
potential contingency with sequential interdependence. With reciprocal
interdependence, contingency is not merely potential, for the actions of each position
in the set must be adjusted to the actions of the one or more others in the set. Because
38
the three types of interdependence are, in the order indicated, more difficult to
coordinate, we will say they are more costly to coordinate.
These different types of interdependence require different types of coordination
policies. Thompson suggested three types of coordination “standardization”, “by
plan”, and “mutual adjustment”, each suitable for one interdependency introduced
above. With pooled interdependence, coordination by standardization is appropriate.
Coordination by standardization involves [74]:
The establishment of routines or rules which constrain action of each unit or position
into paths consistent with those taken by others in the interdependent relationship.
An important assumption in coordination by standardization is that the set of rules be
internally consistent, and this requires that the situations to which they apply be
relatively stable, repetitive and few enough to permit matching of situations with
appropriate rules.
For sequential interdependence, coordination by plan is appropriate which involves:
The establishment of schedules for the interdependent units by which their actions
may then be governed.
For reciprocal interdependence, coordination by mutual adjustment is appropriate
which involves [74] “The transmission of new information during the process of
action. The more variable and unpredictable the situation, the greater the reliance on
coordination by mutual adjustment.”
Thompson associates each of the above coordination policies by coordination cost and
in the order introduced they place heavy burden and on communications and decisions
[74]. He describes these coordination costs as [74]:
Standardization requires less frequent decisions and a smaller volume of
communication during a specific period of operations than does planning, and
39
planning calls for less decision and communication activity than does mutual
adjustment.
2.3.6 Computational Organizational Science
While computational models have evolved into a major discipline in traditional
domains like mechanical engineering practices, it is still infant in the area of enterprise
modeling. Enterprise as a socio-technical system is complex and versatile which make
computational approaches promising and at the same time difficult and challenging.
The difficulty is caused mainly by informality of the interaction among social
individuals while performing their tasks. Therefore qualitative approaches based on
descriptive and artistic qualities have been dominated in this area [4]. Research in
computational organizational science has attracted some interests in recent decades
[9][43][80][10]. Organizational analysis tools such as the Virtual Design Team (VDT)
have been developed. VDT models participants as information-processing entities
with skill sets and experience and explicitly model lateral interdependencies between
activities [43]. VDT attempts to develop a computational model of project
organizations to analyze how activity interdependencies raise coordination needs and
how organization design and introduction of communication tools may change the
coordination capacity of project teams, with resulting impacts on project performance
[43]. The VDT model is built based on organizational contingency theory [72], and
real world observations about collaborative and multidisciplinary work in large
complex projects [43].
40
The VDT research was initiated in the late 1980s with a long term goal to develop new
theory and tools that could extend the reach of both organizational contingency theory
and network based management tools like CPM, to provide reliable answers to key
questions for project organizations engaged in complex, but relatively routine tasks
[43]. In VDT, the organization’s tasks, its actors, and aspects of the organization’s
structure are explicitly represented. For a given task and organization setting, VDT
can generate emergent organizational performance through simulating micro-level
actions of, and interactions [43].
2.4 Business Process Reengineering
2.4.1 Business Process and Business Process reengineering
Davenport and Short [19] describe a business process as: “The logical organization of
people, materials, energy, equipment and procedures into work activities designed to
produce a specified end result.” They identify two important features for a business
process, firstly they must have customers, and secondly they are across organization’s
boundaries and independent of organizational structure. Hickman similarly defines a
business process as: “A logical series of dependent activities which use the resources
of the organization to create, or result in, and observable or measurable outcome, such
as product or service.” In his view human and non human actors are both identified as
resources of organization. Business process reengineering has been loosely used by
many researchers and sometimes other names such as business process reengineering;
business process redesign; business process management; business process
41
improvement and core process re-design have been used interchangeably. Their
approaches have different characteristics in terms of the degree of change (radical or
incremental), the scope of the exercise (internal or external), the potential risks and the
potential benefits [13]. Figure 2-6 differentiates these terms (adapted from [13]).
Figure 2-6: Comparison of different terms in BPR [13]
Business process reengineering (BPR) [35] has got lots of attention as a method for
management of change [49][39][24], yielding potential benefits such as increasing
productivity through reduced process time and cost, improved quality, and greater
customer satisfaction[8]. Childe [13] summarized the goals of business process
reengineering as:
• Define business processes and their internal or external customers
• Model and analyze the processes that support these products and services
42
• highlight opportunities for both radical and incremental business improvements
through the identification and removal of waste and inefficiency
• implement improvements through a combination of IT and good working
practices
• Establish mechanisms to ensure continuous improvement of the redesigned
processes.
Many approaches has been adapted for improvement of corporations through BPR
[49][39][24], but many of them has been failed [8]. Clarke in his holistic review of
business process reengineering states that almost 70% percent of BPR activities have
been reported as failure. We believe many of these failure is due to the poor
understanding of organization structure and how it is related to business processes. I
propose that a computational enterprise model based on sound organizational theories
such as contingency theory improves the current practice in BPR. Workflow
management is the current practice where the operation of a human or machines are
depicted as workflow item. In the next section I shall describe different techniques
used for workflow management.
2.4.2 Workflow Management and Process Modeling
In this section, we will review some techniques researchers used in workflow
management and process modeling area. There are two main workflow management
43
methodologies namely called “activity-based methodology”, and “communication-
based methodology”. In this section I describe each of methodologies and their pros
and cons from our computational point of view.
2.4.3 Activity Based Methodologies
Traditionally researchers look at processes as an “Information Factory” with a focus
on flow of information content. They tend to neglect human actors and their action and
co-action within organization. This type of process modeling has been referred as
activity-based process modeling and there are several techniques in this area. In this
section I have reviewed Digrph, IDEF3, PERT/CPM, DSM and Petri-Net.
Digraph: or sometime called bigraph is the simplest way to represent a process. It
consists of set of nodes linked with directed arrows. The way it can be viewed as a
process representation is that the directed edges represent the information flow, or
knowledge needs to be transferred and nodes contain process activities. Figure 2.7 is a
Digraph example.
Figure 2-7: A digraph example
44
Digraph is very useful for abstract and uniform representation of processes, but
because of its simplicity it cannot contain various forms of information and therefore
does not provide much help in analyzing the processes.
PERT/CPM: PERT (Program Evaluation and Review Technique) / CPM (Critical
Path Method) was developed by the United States Department of Defense. It was
initially developed as a management tool for complex military projects and later was
adapted for being used in educational research and evaluation. The fundamental
feature of PERT/CPM is milestone, where make these method suitable for planning.
In this model, the arcs represent process activities and nodes represent the milestones
for the processes to be accomplished. Another feature of PERT/CPM is the length of
an arc which express the time duration to reach a corresponding milestone. Figure 2.8
is a PERT/CPM example.
Figure 2-8: An example of pert/CPM
IDEF3: The IDEF3 Process Description has been used as a mechanism for collecting
and documenting processes. It captures precedence and causality relations between
situations and events in a form natural to domain experts by providing a structured
45
method for expressing knowledge about how a system, process, or organization works
by two types of schematics: Process Flow Schematics and Object State Transition
Schematics [81]. A Process Flow Schematics captures knowledge of “how things
work” in a process, while an Object State Transition Schematics summaries the
allowable transitions an object may undergo throughout a particular process [81].
Figure 2.9 is an example of Process Flow.
1.1.8
Submit signed
Purchase
Request
1.1.10
Prepare
Purchase
Request
1.1.7
Obtain Account
Manager's
approval
1.1.9
Obtain
authorization
signature
requested
Identify
current
supplier
3
Identify
potential
suppliers
2
X X
6
4
Request
bids
5
Evaluate
bids
1
Order
material
J1 J2
Request
material
Figure 2-9: An example of IDEF3 [81]
Design Structure Matrix: Steward proposed Design Structure Matrix [70] to
represent the dependencies between tasks. In Design Structure Matrix tasks are
represented in rows and columns and the cell corresponding to each two task
represents the relationship between them. For example the cell[i,j] indicates that
task[i] depends on task[j]. Figure 2.10 is a DSM example.
46
Figure 2-10: Design structure matrix example
This method is very useful for its concise representation of tasks dependencies. It also
provides matrix-based analysis for managers to improve their project planning. But it
does not represent the sequence of processes and information flow between the tasks.
Petri-5et: A Petri-Net is a graphical oriented language for design, specification,
simulation and verification of a system [81]. It is a directed graph that consists of two
kinds of nodes: places and transitions. A petri-net has five features as place, transition,
arcs, weight function, and marking. Graphically, places are shown by circles and
transitions are shown by bars. Transitions and places are linked to each other through
arcs. A transition can represent an event, an action, a computation step, etc. and a
place can be a buffer storing precondition, needed resource, or input data if it is a input
place, or a buffer storing post condition, released resource, and output data if it is an
output place [81]. Arcs can be associated with Weight functions to illustrate the
conditions need to be satisfied before firing a transition and the generated results after
firing a transition. Information are stored in each place through tokens denoted by
47
dots. Finally, marking is A vector combining the number of tokes in all places. So, a
Petri-Net can be represented as:
P = {p1, p2, …, pm} is a finite set of places,
T = {t1, t2, …, tn} is a finite set of transitions,
A ⊆ ( P × T ) ∪ (T × P) is a finite set of arcs,
W: A → {1,2,…} is the weight function attached to the arcs,
M0: P → {0,1,2,…} is the initial marking.
t
1
p
1
t
2
p
2
.
.
.
2
t
1
p
1
t
2
p
2
.
.
2
t
1
p
1
t
2
p
2
.
.
2
t
1
p
1
t
2
p
2
.
.
2
t
1
p
1
t
2
p
2
.
2
(a) (c) (d) (e) (b)
t
1
p
1
t
2
p
2
.
2
(f)
Figure 2-11: Petri-5et example [81]
2.4.4 Communication Based Methodologies
Traditionally, researchers look at enterprises as an “Information Factory” with a focus
on flow of information content. They tend to neglect human actors and their action and
co-action within organization. Theories of speech acts and communicative action
[3][62] inspired researchers toward a method with a focus on human actor. The
fundamental idea of speech act theory is that an statement consists of both a
“propositional content” (describing the world) and an “illocutionary force” (action
48
mode). The illocution used expresses the action performed through speech and thus
the type of relationship established between speaker and hearer [34].
Many researchers and practitioners recognized data flow and its control in the process
of redesigning organizations do not suffice for a workflow management system [34].
Having inspired from speech act and communicative action theories, researchers
developed frameworks to translate communicative action theories into workflow
management systems. Action workflow [79] was the most well recognized
communicative action framework used for workflow management and information
system design. A communicative action framework puts human actors and action in
the center when looking at organizations and information systems. Such a framework
emphasizes that information does not only have content (words, numbers and other
symbols) but also an action aspect [34].
Although Action workflow was first introduced to address information systems, but
the idea also breaks through the area of Business Process Reengineering. Action
workflow has been used for developing software tools such as Action Technologies as
a process modeling tool. The main focus of this approach is on “Customer
Satisfaction” and the commitment of the performer for delivery of products. Action
workflow claims that any workflow consists of two actors and four phases. Two actors
are “Customer” and “Performer” and four phases are:
• Request
49
• Commitment
• Performance
• Evaluation
Figure 2-12 shows the four phases of Action workflow cycle. The first phase of the
cycle is that customer requests a work from performer. It can be in opposite direction
meaning that performer offer a work to the customer. In the second phase performers
agrees to perform the job. In this phase customer and performer may go into a
negotiation process. In the third phase which is the main phase of the cycle, performer
performs the actual job. Finally in the last phase, perform delivers the result of the job
to customer for evaluation.
Figure 2-12: Conditions of satisfaction in cction workflow
2.5 The 5eed for a 5ew Approach
The above existing research and many other related works in the literature focused on
various aspects of EIM (Enterprise Integration and Modeling), significantly
50
contributed to understanding the characteristics of enterprise operations, and provided
useful technologies to improve them. However, all of them have their own limitations
in building a reliable enterprise model.
A framework is needed to bridge fundamental theories from different research
areas into a single enterprise model. Researchers from different research areas have
their own perspective to the problem. In the process modeling area, traditional
workflow management and process modeling techniques have their weaknesses. They
focus on process as the only important parameter in enterprise modeling and few of
them take organizational structure into account. They have different views including
market-driven (economics), operation-driven (workflow management), organization-
driven (social science). A new paradigm is needed to bridge all these views and put all
of them together in a single model by clarifying the relations between the key concepts
in these areas. The relations between market trend (e.g., how the clients request
service from enterprise), business process (e.g., how the managers should organize the
processes to fulfill client’s request) and organizational structure (e.g., how staffs and
managers should work together) are a very important topic that is not addressed in
previous researches. Traditional enterprise model consists of a process model and, in
some cases, an organizational model. Although research in process modeling is almost
saturated, organizational modeling of the current research is at a very preliminary
level. Also, these systems usually fail to provide a model to integrate non-human
actors (e.g., data base systems, CNC machines) and client model into the system [5].
51
A reliable computational model is needed for analysis and design of enterprise
organization and operations. While computational models have evolved into a major
discipline in traditional domains like mechanics and fluid dynamics, it is still in its
infancy in the area of enterprise modeling. Enterprise as a socio-technical system is
complex and versatile which make computational approaches promising and, at the
same time, difficult and challenging. The difficulty is caused mainly by informality of
the interaction among social individuals while performing their tasks. Therefore
qualitative approaches based on descriptive and artistic qualities have been dominated
in this area [4].
As discussed above, there have been researches in computational modeling of
organizations for studying organizational behaviors. VDT[43] particularly uses
computational models and simulation to analyze engineering projects in which
engineers work in teams in a limited period of time. There is a need for a
computational approach for enterprise modeling. Our approach can be differentiated
from VDT and other similar approaches [9][80][10] in several ways.
• We focus on modeling enterprises that have perpetual organizations and
operations to serve continuous requests from clients, rather than project
teams that are only temporal with clear start and finish times.
• Organizational structures are likely to be more complicated in enterprises
than in project teams.
52
• The concept of market and client are not present in project organizations
because tasks are predefined and stay the same during the project lifetime.
In enterprise modeling, explicitly capture the concept of market and client
is essential since all enterprises must deal with changing market situations.
• Internal resources (e.g., manufacturing tools and cranes) and external
resources (e.g., suppliers) play an important role in enterprise performance.
In order to have a reliable enterprise model, these resources need to be
modeled and their interactions with human actors and enterprise operations
need to be clarified.
Managers are looking for quantitative answers to key management questions. In
engineering collaboration and CSCW (computer supported cooperation work) research
areas, there have been efforts to improve coordination, cooperation and collaboration
among engineers. There is a strong need for the developed theories to be tested and
analyzed with a reliable computational model. It has been difficulty for researchers to
answer critical questions like how much coordination is improved in a team by
applying a specific communication strategy? How organizational structures affect
communication channels and as a result coordination and collaboration among
engineers? Extant research provides little help for quantitative analysis and a gap
exists in current practices in enabling enterprises with quantitative answers to
management questions. A reliable computational model of enterprise is needed to
provide analysis capabilities and quantitative answers. For a model to be reliable
53
enough, it should be theoretically sound and validated by extensive real world case
scenarios. Such a model can serve as a reliable test bed for generate coordination and
collaboration insights and theories for enterprise operations.
Multi-agent system is a promising approach as an enterprise execution and
management system. Distributed artificial intelligence (DAI) provides strong
theoretical and technical basis for building distributed systems. However, there is no
direct mapping from the distributed artificial intelligent based problem solving
methods using computer agents to the enterprise modeling and integration problems
involving human beings. Modern enterprises are highly complex and involve
traditional scientific and engineering fundamentals, specific domain knowledge, and
general organizational and business aspects. In addition, actors (e.g., human beings) of
an enterprise organization have their social roles, psychological features and biological
characteristics which are not considered in computer agents. Applying distributed
artificial intelligence directly to enterprise model for the purpose of process execution
and management is a challenging task. Multi agent approach provides a computer and
network based system framework for processes execution and management.
To summarize, in order to systematically, coherently, efficiently and effectively
support enterprise modeling and integration, a more comprehensive framework is
required to overcome the limitation of existing technologies and address the research
issues discussed in the first chapter.
54
Chapter 3: PMT: A Model of Enterprise Operations and
Organizations
3.1 Introduction
To survive and compete in today’s market enterprises must become increasingly agile
and integrated across their functions [27]. To do so, an enterprise must be able to
understand its capabilities and predict what needs to be done to deal with possible
changes in the market and technologies. A key to acquire this capability is to have a
comprehensive enterprise model that can be used to represent, analyze and design
enterprise organization, operations, and resource allocations. In this chapter, we
introduce our approach towards a computational enterprise model for supporting
enterprise management which addresses important issues that are not addressed in
previous researches. There are several requirements for our proposed model, as
described below.
Enterprises benefit from enterprise models in three different categories, namely,
design, analysis and operation [27]. An enterprise model should be capable of
providing support for each of these categories. From a design perspective, an
enterprise model should provide essential representation concepts to define the whole
enterprise. Enterprise designer should be able to reason about different designs of the
enterprise by exploring alternative models. From an analysis point of view, an
enterprise model should provide the essential means for enterprise analyzers to predict
55
the effect of particular changes on all parts of the enterprise. Finally from an operation
perspective, the enterprise model must be able to represent what is planned, what
might happen, and what has happened. It must provide the information and knowledge
necessary to support the operations of the enterprise.
To address the above issues, we have developed a computational enterprise model
built upon well accepted organization theories and workflow management theories.
There are three main perspectives toward modeling enterprises, e.g., market-driven
(economics), organization driven (social) and operation driven. As discussed in
section 2, enterprise modeling approaches in these perspectives provided a powerful
insight into enterprise modeling, but they can barely answer the above potential
questions. While the power of computational organization models has been proven
[9][43][80][10], they are very suitable to be used for enterprise modeling. Our
proposed computational enterprise model simulates the micro-level behavior of the
enterprise’s entities and computes the emergent macro-level behavior of enterprise.
Although the computational model should be developed on top of well approved
theories, but extensive real world case scenarios should be performed before industry
usage.
To explore a new framework for enterprise modeling, we propose a work paradigm
including 4 systems namely called “Business System”, “Organizational System”,
“Operational System” and “Technological System”. We view every activity in an
56
enterprise within these systems. Figure 3-1 shows these systems within an enterprise.
We view client and service (provided by enterprise) on two sides of an enterprise
business system. Enterprise business processes and client/service interaction which
lead to the delivery of product or service to client, construct the enterprise business
system. Organizational system includes the activities of human actors together with
their assigned job responsibilities. Operational system includes enterprise operations
and the dependencies between them. Finally technological system is about activities
that use available resources within the enterprise.
Figure 3-1: Different systems within enterprise
57
In the following section we will discuss different concepts in our proposed enterprise
model called PMT (Process Management Technology) and the relationship between
entities. Section 3.2 discuss about the valid assumption we have made in building our
enterprise model. Section 3.3 describes our Client Service perspective to enterprise
business transactions and comparison of our view to action work flow [79] and other
approaches. Section 3.4 introduces different parts of enterprise that are represented in
enterprise model and extended information processing view of organizations built on
Galbraith information processing view [29]. Finally, in section 3.5 we describe how
PMT simulation can be used to predict enterprise performance.
3.2 Assumptions about Enterprise Environment
In this section we describe the valid assumptions that have been made in our modeling
built on fundamental theories. Our assumptions have been inspired mainly from two
organizational science theories namely called: Bounded Rationality, Contingency
theory and our observations about collaborative, multidisciplinary work in modern
enterprises.
Enterprise organization is a “Boundedly Rational System”: As discussed in
section 2.3.1 a boundedly rational system is a system that strives to make rational
decisions but is limited due to the finite computational resources available for making
them [66]. We view enterprise organization as a unit structured to perform a specific
set of tasks, but with a limited capacity “Boundedly Rational System”. Organizational
58
actors have clearly defined goals and consensus on the “the most efficient means to
achieve these goals” [72], therefore the appropriate description of organizational
action will be one of the purposeful and goal-oriented search for solutions [67], rather
than stochastic matching of incoming problems with available solution alternatives
[16]. Although we assume enterprise organization as a rational system, but the natural
complexity and uncertainty of their tasks limits their rationality. There is always a
tradeoff for actors in an organization for exploring more and obtain more optimality
and the cost of time they spend. Therefore, most of the time actors should limit
themselves to be “satisfying” rather than maximizing search [67].
Most of the tasks in an enterprise organization are routine and repeated:
Enterprise operations are dominated by conservatism and incremental improvement.
Therefore, the nature of tasks in enterprises does not involve intrinsic innovation and
creativity, but rather consist of routinized and repeated daily problem solving.
Uncertainty and dependence come about not because of the difficulty or newness of
the task, but rather because of increasing demands for more efficiency. According to
this fact we assume the time each actor spends on certain task can be estimated. In
PMT, we assume organizational tasks are divided into two main categories, namely
called: primary service work that directly adds value to service quality and customer
satisfaction, and communication work that facilitates the service works.
59
Enterprise organization adapts and responds to external environment as an open
system (Contingency Theory): We view organizations as open systems [61] which
their performance is highly dependent of external forces in the environment. As
discussed in section 2.3.2 Thompson version of Contingency Theory deals with the
relations of organizational structure and surrounding environment. Thompson stated
that “we will conceive of complex organizations as open systems, hence indeterminate
and faced with uncertainty, but at the same time as subject to criteria of rationality and
hence needing determinateness and certainty”. According to this view, we have
adopted Thompson contingency theory as a suitable framework for organizational
analysis. Thompson presented contingency theory in the set of proposition for how
organizations behave “Under Norms of Rationality” (See section 2.3.2). In PMT we
have built organization behavioral matrices according to Thompson theory, and
therefore developed a quantitative version of Thompson contingency theory for
analysis of organizational structure. We also divide external forces in enterprise
environment into social and technical [14] and address them in two sub models
respectively Client model and Resource Model.
3.3 Integrated VS 5on-Integrated Models
Non-integrated Enterprise models can be divided into three types. These types are
market-driven (economics), operation-driven (workflow management), organization-
driven (social science). Each of these non-integrated models has their own weakness
mainly because of ignoring other aspects of the enterprise. In market-driven models,
the focus is on how market is fluctuating over the time. Market analysis to attract more
60
customers usually plays the most important role in these types of models, while in our
integrated model; we see market as an independent variable. In operation-driven
models or traditionally called business process reengineering, processes are the only
important parameter in enterprise modeling and few of them take organizational
structure and client into account. This approach was very popular in early 90s, but the
attraction has been diminished because of lots of reported failures in using these
models. Organization-driven models such as VDT have been used for project teams,
but such a model does not exist in the area of enterprise modeling. In our enterprise
model we bridge all these views and put all of them together in a single model by
clarifying the relations between the key concepts in these areas. The relations between
market trend (e.g., how the clients request service from enterprise), business process
(e.g., how the managers should organize the processes to fulfill client’s request) and
organizational structure (e.g., how staffs and managers should work together) are a
very important topic that is not addressed in previous non-integrated models.
3.4 A Client and Service Model of Enterprise
In this section we discuss the client and service architecture of our proposed enterprise
model inspired from the work of Medina-Mora, Winograd et al [79] called “Action
Workflow”. We first discuss the advantages and disadvantages of this framework and
represent our solutions for improvement. Secondly we describe how we have adapted
this idea to represent the enterprise “business system”.
61
Action workflow was first introduced to address information systems, but the idea also
breaks through the area of Business Process Reengineering. As discussed in chapter
2.4.4 Action workflow has been used for developing software tools such as Action
Technologies as a process modeling tool. The main focus of this approach is on
“Customer Satisfaction” and the commitment of the performer for delivery of
products. Action workflow claims that any workflow consists of two actors and four
phases. Two actors are “Customer” and “Performer” and four phases are:
• Request
• Commitment
• Performance
• Evaluation
Figure 3-2 shows the four phases of Action workflow cycle. The main idea of this
framework is that upon customer request, performer makes a commitment to perform
the work. The first phase of the cycle is that customer requests a work from performer.
It can be in opposite direction meaning that performer offer a work to the customer. In
the second phase performers agrees to perform the job. In this phase customer and
performer may go into a negotiation process. In the third phase which is the main
phase of the cycle, performer performs the actual job. Finally in the last phase,
perform delivers the result of the job to customer for evaluation.
62
Figure 3-2: Conditions of satisfaction in action workflow
Action workflow reduces each workflow into 4 phases based on the communication of
actors and therefore provides more insight into each workflow item. This approach
provides a fundamental framework for modeling business processes, but when applied
to enterprises with its main focus on customer satisfaction it overlook other important
enterprise’s issues. Keen [45] has argued that it is important to embed the new
thinking of "total quality", "customer satisfaction" and "business process" in
methodologies; otherwise these notions will just be clichés. Our proposed approach
towards enterprise modeling (PMT) has been inspired by idea of Action workflow, but
takes a broader view towards enterprise modeling. We believe communicative action
based methodologies are too rigid for modeling complex enterprises with several
departments and employees. Providing the full cycle with 4 phases for each workflow
item of enterprise is often impractical and limits modelers in representing complex
enterprise operations. We have adopted activity based methodology (see section 2.4.3)
for workflow modeling, but that does not mean the human action has been ignored. To
bring human action into the picture, we have modeled human actors behavior (policy)
63
according our extended information processing view of organizations (See section
3.4.1).
Also this approach by itself does not provide much help in analyzing existing
processes or creating new processes. Activity based methodology gives more freedom
to users to model different scenarios of enterprises and provides more analysis ability
to enterprises. In addition our complex organization model with its relationship to
enterprise processes provides the key measurements required for process analysis. The
key activities within each workflow are collected and the emergent result is
interpreted.
Having human within the enterprise and the decision making adds a social dimension
to the enterprise. Another deficit of action workflow is its lack to address social
aspect of modern enterprises. With its focus on four phases of human interactions, it
overlooks the effect of human social behavior on workflow cycle. We view enterprises
as socio-technical systems which human characteristics play an important role in the
overall enterprise performance. Through the purposeful actions and reactions of
human actors, while performing certain tasks, workflows are generated and processed.
In modern enterprises, these interactions are enabled via some information
infrastructure which we call communication channels. We have modeled micro level
human social behavior and information infrastructure being used in enterprise
according to [15] and our observation from case scenarios (See section 3.4).
64
In contrary to current trend in using action workflow at workflow level, we have
adapted the idea in a bigger picture. We view client and service (provided by
enterprise) on two sides of enterprise “business system”. Enterprise business processes
and client/service interaction which lead to the delivery of product or service to client,
construct the enterprise “business system”. In modern enterprises, clients and
enterprises are involved in everyday’s “business transaction”. We call an activity
business transaction if it generates revenue for enterprise. We define four phases for
our framework same as action workflow cycle for enterprise “business transactions”.
Our frame work starts with client modeling. In this phase, all the inputs from
client/customer side to the enterprise are modeled. We represent Client as number of
Client Operations (COP) that sends Service Request Items (SRI) with some
probabilistic functions (See section 3.4.2). In the second phase, within the simulation,
requests are generated and being sent to corresponding services of enterprise. Service
fulfills the requests according to its capacity and provides a report for the client in the
third phase. Finally in the last phase, the enterprise performance is evaluated and if not
satisfactory, client may resent its request to service provider. Figure 3.3 shows
different phases of our framework and action workflow and the mapping between
them.
65
Figure 3-3: Mapping of action work flow paradigm to PMT business system
We view enterprise as an entity which provides service in response to clients’
requests. Top level view of our enterprise model is represented in figure 3.4 . Different
clients may request different services from the enterprise. Enterprise has its own
operations, organizations and technology to fulfill the clients’ requests.
66
Figure 3-4: Client and service architecture of PMT
3.5 Enterprise Elements
An enterprise is a system that can be viewed as “large set of concurrent processes
executed by communicating agents” [76] with set of goals, objectives and deliverables
like product or service. From System theory point of view any system has three
aspects namely called structure, behavior and hierarchy [41]. In this section we
describe the structural and hierarchical aspect of our proposed enterprise model and
then steps into the behavioral aspect of each element. The structural aspect is based on
the principle that elements of the systems are not isolated but have multiple
67
interdependencies with each other and therefore the whole system exhibits properties
different from properties of its elements. The hierarchy aspect is based on the principle
that an element of a system can itself be regarded as a system, which is then called
subsystem. The behavioral aspect describes the variables and their functional or other
relationships [41].
We look at enterprise as an “operating system” where there are some applications
running to serve user requests and these applications use available resources. This
view gives a suitable structure for our computational enterprise model. According to
this view, we have divided enterprise into 4 main elements namely called: Client,
Process, Organization, Resources. Each element is isolated and has its own boundary,
but has multiple interdependencies with other elements within the enterprise. Figure
3.5 shows these major elements of our proposed model and the interaction between
each element.
68
Figure 3-5: Elements of enterprise
In the following section we describe each element and the abstract representation of
real world into the model. In section 3.4.1 we first describe our theoretical view of
enterprise organization which extends Galbraith’s information processing view of
organization. Our client modeling approach is described in section 3.4.2. Section
3.4.3 describes how we view and model enterprise operations. Section 3.4.4 describes
our enterprise organization model based on our extended information processing view
of organizations. Finally in section 3.4.4 enterprise resource model is discussed.
69
3.5.1 Extended Information Processing View of Enterprise
Organization
In this section we review Galbraith information processing view of organizations [30].
Then we describe our extension to this view that provides a strong abstraction for our
organization model. We describe how the term “information” in Galbraith’s model is
mapped to “work volume” for our computational model. Finally we discuss how
organization design problem is viewed in our model.
Our view of enterprise organization originated from Galbraith’ s information
processing view of organizations [30], but we further extended this model to make it
suitable for our computational enterprise model. As discussed in section 2.3.4 the main
proposition of this model is that [30] “The greater the task uncertainty, the greater the
amount of information that must be processed among decision makers during task
execution, in order to achieve a given level of performance.”
In Galbraith’s information processing view of organization, an organization is an
information processing, communication and control system, representing a
“boundedly rational system” structured to achieve a specific set of tasks, and
comprised of limited capacity. Each task is associated with certain amount of
uncertainty which is defined as “the difference between the amount of information
required to perform the task and the amount of information already possessed by the
organization [30]”.
70
Once uncertainty as a general term in Galbraith’ model defines the amount of
information needed for processing the task, structure, skill and behavior of
organizational actors define the performance of organization. If an actor does not
possess the required information needed for a certain task, an “exception” is generated
and he uses organizational communication and control system to obtain the required
information. Exception generation relieves the actor from exploring the required
information and puts information processing load on others who should provide the
information. It also leads to congestion of communication channels of organization. In
organization, usually exception handling is the responsibility of managers and
therefore more exception lead to more information processing for managers.
Exception generation is necessary for organization to maintain the performance, but
on the other hand overwhelming the actors with exception handling and clogging of
communication channels make an organization inefficient and unproductive. Galbraith
views this trade off as [29]:
As uncertainty goes up, the number of exceptions rises, and thus leads to an overload
on managers. Subordinates spend increasing amounts of their time waiting for
managerial decisions, and thus poor performance results.
According to Galbraith information processing view, organization design problem is
How to create adequate information processing capacity to achieve fluent
“coordinated action across integrated roles” [29]. Inspired by Galbraith’s view we
have modeled enterprise organization as an information processing network consisting
of “nodes” (human actors) and “links” (communication and control channels).
Organization design problem for an enterprise then becomes the design of such a
71
network for fluent processing of incoming requests. Source load of this network
originated from clients’ requests that are stored in service container. Organizational
network then is further expanded with “assignment channel” (see section 3.4.4) to
receive work item for process. This view provides a suitable framework for building
our computational enterprise model and discrete event simulation associated with it.
Figure 3.6 shows our extended information processing view of enterprise organization.
Figure 3-6: Extended information processing view of enterprise’s organization
The main load of organization comes from Service request Items (SRIs) being sent by
clients. Organization structure, communication and control channels, and skills of
human actors define the organization capacity for processing client requests. If the
enterprise receives Service Request Items more than its capacity, the organization
cannot deliver a satisfactory delivery of service to the clients. Overloading the
organization leads to the congestion of communication channels and overwhelming of
72
actors input queue. This causes a delay in delivery of service and incomplete work
items.
Human actors within an organization are involved with two types of activities:
“primary service work” and “coordination work” [43]. Information processing view of
organizations implies that both these activities can be modeled as information
processing activity. Primary service work is a type of work that actors do individually
to add value to the quality of service and is associated with a “work volume”. The
amount of information needed for a certain work item in Galbraith’s model is mapped
to work volume of that item in our model. Work volume in our model is associated
with volume of request item from client, task property (complexity, uncertainty …)
and human required skill sets. The unit of work volume is man-hour which represents
the nominal time taken by one person with a medium level of the needed skill set to
complete the work. The basic idea for our discrete event simulation is that each
processing node (Human actor) spends some simulation time to process a work item
according to its work volume.
Coordination work is a type of work that does not directly add value to the quality of
service, but rather provide the essential information for actors to support them in their
primary service work. The amount of primary service work is usually defined by
nature of service and the amount of service requested from clients, therefore design of
the organization does not have much effect. Design of the organization in our
73
extended information processing means how to design organization hierarchies and
communication channels and how to adjust organization structure variables such as
formalization, centralization, differentiation and organization matrix strength (See
section 2.3.3). On the other hand the amount of coordination work depends mainly on
how human actors interact with each other.
In studying one service of an enterprise let total work requested from clients is TW.
Then TW can be divided to service work SW, and coordination work CW.
(1) TW = SW + CW
SW represent the total amount of service work if no failure exception happens and
every piece of work is done ideally which rarely happens in real world. In real world
there is some amount of rework to maintain the quality of service. Therefore, SW can
be further divided to:
(2) SW = SWo + SWr
Where SWo represents original service work and SWr represents service rework.
From (1) and (2) we have:
(3) TW = SWo + SWr + CW
In PMT we define two main coordination activities (See section 4.4.2) namely called
information exchange (communication) and decision making. Decision making
represents what PMT actors do in the occurrence of failure exception and is further
categorized to “exception-reporting” and “exception-handling”. Also in every
74
enterprise, there are some times that an actor has to wait for service request items or
being asked for information exchange. She/he may also wait to receive a decision
from her/his supervisor for a particular work item. Therefore we will have:
(4)
idle d com
CW CW CW CW + + =
Where
com
CW and
d
CW
are the amount of work for communication and decision
making activity and
idle
CW is the amount of time that actors are idle to receive new
request item. From (4) and (3), we have:
(5)
idle d com
CW CW CW SWr SWo TW + + + + =
SWo is the initial load to the service and is defined according to nature of service and
the amount of service requested from clients. On the other hand, SWr and CW may
vary according to design of the organization. We define organizational effectiveness
measure for a given service as the ratio of:
(6)
TW
CW SWr
Rc
+
=
Rc represent the ratio of coordination load and originally planned service work.
Coordination load can be close to zero that makes Rc equal to zero, if service tasks are
“perfectly simple” or human actors are “perfect” with high set of skills relative to task
complexity [29]. On the other hand Rc can be close to 1 which means that the actors
are not capable to deliver the service and there is an endless rework and coordination.
All enterprises operate somewhere between these two extremes. Now in our extended
information processing view of enterprise organization, we map Galbraith’s problem
into:
75
Galbraith Organization design problem:
How to create adequate information processing capacity to achieve fluent
coordinated action across integrated roles?
PMT Organization design problem:
How enterprise should adjust organization design variables to achieve the minimum
Rc and also maintain the service quality?
We have addressed this problem, by building a computational model of enterprise. We
take client model (section 3.4.2), service process properties (section 3.4.3), and
organizational settings (3.4.4) and resource description (3.4.5) as the input to the
model and simulate the emergent behavior of enterprise. The simulation provides the
results to analyze the performance of different organization designs to achieve the best
efficiency or minimum Rc.
3.5.2 Enterprise Client
Main input to our computational enterprise model originates from outside clients
(market). Now the question is how real world clients request for enterprise services?
How the client demand (request) can be represented in an abstract computational
model? In this chapter we answer the above questions by first introducing different
perspective towards modeling market demand and then discuss demand modeling
from enterprise point of view. We identify important variables in modeling market
demand and then describe how they are addressed in our computational enterprise
model.
76
There are several reasons behind modeling of the market demand. The way market
demand is modeled depends on the purpose of the modeling. We categorize demand
modeling into two main perspectives namely called “client point of view” and
“enterprise point of view”. From client’s point of view the main purpose is to study
client’s need and behavior (client analysis) in order to customize enterprise’s service
or product. The main question here is how to change the service or product to attract
more customers and increase the profit margin, therefore the main focus is on client
analysis. On the other hand, from enterprise point of view the main purpose is to
adjust enterprise operations (enterprise analysis) to meet market demand. Therefore,
from this point of view the size of the market and the pattern of requesting
service/product from client as the independent variable play a significant role.
Similar view from Keys [46] categorized market demand models for enterprise
business simulations into two types namely called “demand dependent across firms”
and “demand independent across firms”. In the models that are demand dependent
across the firms, the competition among the enterprises in the same business plays an
important role and is modeled. Essentially in these models the focus is on client’s
analysis in order to obtain a greater share of the market. On the other hand, in demand
independent modeling, competing firms business does not affect the model. In this
type of enterprise, the quantities demanded from the market depend only on decision
being made within the boundary of the enterprise. These types of simulations are
77
referred to as Monte-Carlo approach [12]. Chiesl [12] stated that these types of
simulations have several advantages. He pointed out that they reduce time delays,
eliminate system hardware problems and improve the authenticity of the simulation.
These types of simulations are also particularly powerful because, they tend to isolate
the problem and therefore the results of enterprise’s decisions can be calculated with
less ambiguity.
Our computational model of market demand falls into the second type of the above
discussed models. According to our extended information processing view, we look
particularly into the relation of “market demand” and “enterprise capacity”. The
question that is quantitatively being answered by our computational model is how
enterprise should adjust its business system (enterprise capacity) in order to meet
market demand. In other word, if there is a jump in market demand how enterprise
should respond (Hiring more people, reengineering business processes, buying more
resources …) or on the other direction if market demand decreases what enterprise
should do to maintain its profit margin (firing people, reduce working hours,
reengineering business processes …).
We define a “demand function” for each client that request service from the enterprise.
X-axis in a demand function represents time and Y-axis represents quantity of demand
or the amount of the “service request items (SRIs)”. A SRI in our computational
enterprise model represents an event that is generated from clients and is being sent to
78
enterprise’s services to be processed. Because usually enterprise has several clients,
therefore several demand functions need to be defined to accurately represent clients’
demand. Adapting Monte Carlo method for simulation [12][60][73], we describe three
important concepts in defining demand function namely called “trend”, “randomness”
and “milestone”.
3.5.2.1 Trend
Market trend defines the deterministic pattern of demand function. A demand might be
increasing, increasing or constant over the time. A linear demand function of a client
can be formulated as follow:
t quests of um β α+ = Re _ _
Figure 3-7: A market with decreasing demand trend
This is a very simple representation of demand function where the number of requests
is deterministic and no change is being made in the trend over the time. A trend
79
function can be more complicated when it is combined with randomness and
milestones. Milestones and randomness are two concepts that enable us to model more
complicated market behavior.
3.5.2.2 Milestones
Market with a constant demand trend rarely exists in real world. Social, economical
and political changes of environment changes the behavior of client in terms of their
pattern in sending service requests. In addition, clients might request different services
in different time and therefore different demand functions for those services are
required. In order to address these types of demand functions, we have defined a set of
“client operations” (COP) for each client. Each client operation is associated with a
demand function that represents the pattern of service request generation. A client in
PMT is mathematically defined as:
Client := {COP, SV, R
CS
,R
CC
}
Where:
COP = {cop1, cop2, cop3, …} : Client Operations
SV= {sv1, sv2, sv3, …} : Services
R
CS
={r
CS
1
, r
CS
2
, r
CS
3
,…} : Relationships between Client operations and services
R
CC
={r
CC
1
r
CC
2
, r
CC
3
,…} : Relationships between Client operations
According to this definition we have divided clients into two types namely called
“simple clients” and “operational clients”. A simple client consists of set of
disconnected client operations and is associated with one or more demand functions
80
and can generate one or more types of service requests. In another word, a simple
client does not have any milestones in its trend functions.
Figure 3-8: A simple client with three client operations
An Operational client is a kind of client in which client’s demand function changes
over the time. For example in ship management a client (ship) may have sequence of
demands like loading, navigation and unloading which have a cyclic sequence. These
types of clients are composed of sequence of client operations. The sequence of client
operation can be in three ways namely called “sequential”, “parallel” and “cyclic”.
81
Sequential: Client operations are sequentially dependent on each other and they may
request different services within the enterprise. The end of one client operation is the
start for the dependent client operations.
Figure 3-9: Operational client with sequential client operations
Parallel: Client operations can be arranged in parallel. In this case two or more client
operations send service request items into services at the same time.
Figure 3-10: Operational client with parallel client operations
82
Cyclic: Client operations can be arranged in a cyclic way. The end of last client
operation is the start of the first client operation.
Figure 3-11: Operational client with cyclic client operations
3.5.2.3 Randomness
Monte Carlo method which is based on repeated sample modeling is often used for the
type of problems where deriving deterministic function is infeasible [6]. Demand
functions are always associated with lots of uncertainty and ambiguity of client’s
behavior. People working in marketing departments strive to estimate client’s behavior
and they usually come up with some probabilistic functions. In this case, the
randomness associated with demand function can be represented as:
ε + =
o
quests of um quests of um ) Re _ _ ( Re _ _
83
Where
o
quests of um ) Re _ _ ( is the original number of requests without randomness
and ε represent a random variable of zero mean.
Figure 3-12: Randomness in demand function
In PMT we have used some well-know probabilistic distribution functions in order to
address the instinct randomness of demand functions. Some of these distributions are:
Normal, Uniform, Poisson, Cauchy, and Erlang.
3.5.3 Enterprise Process
In this section we describe the activity based method we have taken to model
enterprise processes. We review Thompson’ categorization of activity dependencies
84
and then describe how we have adjusted our enterprise process model to address these
dependencies.
There two methods for modeling workflow system namely called “communication
based” and “action based”. In communication based methods a workflow consists of
some actions of humans, but in activity based methods the focus is on flow of the
information. As discussed in section 3.3 for the purpose of modeling a complex
system like enterprise we have adapted activity based method. In section 2.4.3
different methods of process modeling has been described and their advantages and
disadvantages have been discussed. From these methods Digraph, IDEF3, Pert/CPM
and Petri-net are good methods for activity based workflow management systems.
IDEF3 and Petri-net methods are particularly useful for process monitoring and
execution. Pert/CPM is a good method for planning application because of milestones
as the nodes of the graph. We have adapted Digraph to represent enterprise process
model. Nodes in this model represent activities and arcs are used for information
passing. This model is particularly useful for our computational model because of our
uniform representation of activities as information containers. The relation between
activities is called “interdependence of activities” and can be categorized as “pooled,
sequential” and “reciprocal interdependence” [74]. Also each activity generates set of
tasks for responsible human actors. According to Thompson [74], we associate each
task with two features “complexity” and “uncertainty”. In the following sections we
85
describe above concepts and how they are represented in our computational enterprise
model.
Figure 3-13: PMT sample of process model
3.5.3.1 Interdependence of Activities
Enterprise for fulfilling client’s request should perform series of activities. We call
these activities as “service operations” (SOP). Thompson [74] defines three types of
activity interdependencies, “pooled”, “sequential” and “reciprocal” to describe how
different parts of an organization might be dependent of actions of each other. These
types of interdependencies, in the order introduced are increasingly difficult to
coordinate because they contain increasing degrees of contingency [74]. Thompson
stated that all organizations have pooled interdependence, more complicated
organizations have sequential as well as pooled, and the most complex have
reciprocal, sequential and pooled. Following his categorization of activity
interdependency we model these dependencies as follow:
Pooled Interdependency: According to Thompson‘s fundamental work [74], pooled
interdependency is a kind of dependency that each activity makes a “discrete”
86
contribution to a pool of activities and each is supported by this pool. The progress of
one activity does not depend on the progress of other activities and therefore the
amount of coordination is minimal. If activities A and B have only pooled
interdependence, the only effect of activity A’s failure for activity B is through
possible violations of overall service quality. We have addressed this type of
interdependency by defining two pools of interdependence namely called “enterprise
level” and “service level”. Therefore we assume all activities within a service have
pooled interdependencies meaning that a change in each of them can propagate to the
whole service and also a change in the nature of service can affect individual activity.
In some other situations there might be an enterprise level pooled interdependence in
an enterprise which involve less coordination that the service level. The final service
or product delivered by enterprise depends on each activity of the service, but each
activity is not necessarily dependent on other activities.
Figure 3-14: Pooled interdependence in PMT model
87
This type of interdependency is coordinated by rules and standards within a service or
enterprise [74]. We define this type of interdependency with a very low coordination
among human actors. Therefore we assume there is no communication between
human actors for coordinating these dependencies. From simulation point of view, no
event is generated to coordinate, but rather enterprise level or service level attributes
are defined to address this issue.
Sequential Interdependency: Enterprises with only pooled interdependent activities
rarely exist in real world [74], and there are always some activities that are directly
dependent of each other. If activity A should start only after completion of activity B,
then they have sequential interdependency. We model this interdependence in Digraph
by representing two activities linked with a directed arc. The amount of coordination
for this type of interdependence is relatively low.
Figure 3-15: SOP2 is sequentially dependent of SOP1
There is a direct communication involved to coordinate this type of dependency. If
activity A is processed in error, then its actor may need to send information to activity
88
B’s actor about the error. This type of interdependence is addressed in our model
through “exception-reporting”, “exception handling” and “meetings”. If two activities
are sequentially interdependent, then in the occurrence of a failure, they generate
exception items that are passed between their actors. Also actors involved in these
activities may need to attend daily, weekly or monthly meetings to coordinate their
work.
Reciprocal Interdependency: The third type of interdependence, Reciprocal
Interdependence, is referred to the situation where the outputs of each activity become
inputs for the others [74]. This type of interdependence is coordinated by “mutual
adjustments” and involves the transmission of new information during the process of
activity [74]. This means that coordination load is very high and as a result requires
intense communication. We have modeled this type of dependency in digraph by bi-
directional arc namely called “communication link”. This type of interdependency is
addressed in our model through direct communication between the actors involved
with reciprocal interdependency. Communication events are generated according to a
probability function, and these items are processed by actors for the coordination
purpose. Note that according to Thompson theory, interdependencies in the order
introduced, are defined with increased coordination load, therefore if an activity has a
reciprocal dependency that mean it already has pooled and sequential.
89
Figure 3-16: SOP1 and SOP2 are reciprocally interdependent
3.5.3.2 Complexity
Thompson [74] describes complexity as the number of constraints on the actions of
human actors within an organization. As the number of constraints increases, actors
should act more rational, hence fox [28] defines complexity as excessive demands on
rationality [28] and distinguish between complexity of information (Knowledge of
actors does not satisfy required knowledge for performing the task), task (number of
actions exceeds actors allocated time) and coordination ( requiring many
communication that exceeds communication capacity). Our extended information
processing view gives us the ability to represent the above complexities in a uniform
way of information processing. We associate each activity with a work volume and a
level of complexity which represents the number of actions (amount of work). Also
actors are associated with set of skills (ex. Mechanical, Electrical …) and skill level
(ex. Low, medium, high) assigned to activities that require some skill sets. Good
matching of actors to activities can decrease the information complexity. Also
complexity of coordination is being addressed by communication channels and
90
information exchange activities through them. For each service enterprise provides to
clients, we have defined a level of complexity which consists of two types of
complexity :
• Service Operation’s Complexity: relates to the number of requirements a
service operation has to satisfy. A service operation can be as simple as
“signing a paper by manager” or can be as complicated as a design problem.
• Requirement’s Complexity of SRI (service request item): relates to the
number of service operations that contributes to the satisfaction of the
requirement. Each SRI is associated with set of requirements that need to be
satisfied by service operations. SRI may only require achieving one service
operation or may need to travel several service operations for full satisfaction.
The effect of complexity in our computational model is through delaying the
information processing and generating exception and communication items. As the
complexity increases, actors need to spend more simulation time for information
processing and the probability of exception failure or communication increases.
Complexity can be raised, because of any of the above scenarios. In PMT, We have
addressed complexity comprehensively by direct (service operation’s complexity,
requirement’s complexity) and indirect factors (information complexity, coordination
complexity). The interaction of the above concepts in our event driven simulation,
computationally models complexity in enterprise environment. The full description of
91
complexity representation and the effect on information processing of actors can be
found in the appendix.
3.5.3.3 Uncertainty
Thompson defines uncertainty as the number of contingencies facing the organization
[74]. Also Galbraith in a similar way defines uncertainty as the difference between
information available and the information required to make the best decision [30]. Our
view of uncertainty in PMT can be stated as “As the level of contingency increases
actors are more uncertain about what to do next, therefore they cannot allocate their
time efficiently.”.
In order to represent this inefficiency raised from uncertainty, we have defined “noise
items” (see section 3.4.4) to be processed in actors’ allocation cycle. According to the
model of bounded rationality [67], we have implicitly modeled uncertainty of
environment through its affect on actor’s attention cycle.
Another effect of uncertainty is its effect on the frequency with which human actors
need to communicate. The necessary participants are determined from
interdependence between actors, and level of uncertainty give rise to a range of
communication requests, for each of which actors must reason about. Hence, actors
should choose a communication policy which is characterized by formalization. (see
section 3.4.4)
92
3.5.4 Enterprise organization
Scott [61] summarized contingency theory as “there is no best way to organize, but for
a given organization and organizational context, not all ways to organize are equally
good”. Organizational design is context dependent (types of activity and environment)
and the performance of an organization depends on its structure and activities. In PMT
we have a simulation based approach to predict how changes of organizational
variables affect the performance of organization. We have modeled organization as a
network of processing nodes and communication/control links (extended information
processing view). In this section we describe different important organizational
properties (macro-level properties) and human actors’ behavior (micro-level
behavior). We first describe what kind of information individual actors may process
during the simulation time. Then we describe the attention cycle of each actor in its
daily operation. Finally, we describe some important organizational characteristics
and the effect of them on actors’ behavior.
3.5.4.1 Types of information
We view the process of client’s request fulfillment as a set of discrete events to do the
work (service work), control the work (exception handling) and communication
between actors who do the work (communication). The main load of the organization
is to fulfill the clients’ requests, but while processing these items failure exceptions
93
may occur which require the control of managers and also there are some activities
(reciprocal interdependence) which requires communication between their actors.
According to this information processing view, three types of information are defined:
Service Work: Primary service work is a type of work that actors do individually to
add value to the quality of service and is associated with a work volume. The amount
of information needed for a certain work item in Galbraith’s model is mapped to work
volume of that item in our model. Work volume in our model is associated with
volume of request item from client, task property (complexity, uncertainty …) and
human required skill sets. The unit of work volume is man-hour which represents the
nominal time taken by one person with a medium level of the needed skill set to
complete the work. This type of information is the main load to the organization, but
once finishing a service work and actor checks stochastically for the possibility of
failure exception.
Exception Reporting and Handling: An actor may not have the required capability
to fulfill the request item, so he needs to contact his supervisor or other people who
have higher skill. Failure exception can happen stochastically when processing service
work. Actor checks the failure according to a stochastic function, at the end of
processing a request item. The probability of failure exception depends on the nature
of the service activity (uncertainty, domain) and the skills of the actor (skill level,
domain of expertise). If an activity has a high level of uncertainty and assigned to an
94
actor with low skill and different domain of expertise from the activity domain
(mechanical engineer assigned to electrical job), then the probability of failure
exception is high. When a failure exception occurs, an actor reports the exception to
his higher hierarchy manager in the organization structure. This scenario involves two
types of information processing: “exception reporting” and “exception handling”.
Exception reporting is the primary actor’s activity where he spends some simulation
time (process information) to make the report and decide who to send the exception.
Therefore in addition to the original service work, the actor has to spend some
simulation time to report the exception. On the other side, the supervising actor once
receiving the exception item, he spends some simulation time to make the decision
(exception handling). Exception handling is the act of ensuring the quality of activities
(service operations). There are two scenarios for the supervising actor. The first
scenario is that the supervising actor may not have the enough processing capacity to
make the decision for the supervised actor, therefore he acts in the same way as the
primary actor. In this case the actor acts as a bridge between the primary actor and the
actor in the two level higher hierarchies in the organization hierarchy. The second
scenario is that, the supervising actor does poses the enough information capacity and
therefore makes the decision for the exception item and sends it back to the primary
actor. Figure 3.17 shows the exception reporting and handling in organization
structure. Probability of two scenarios depends on “enterprise centralization” (see
section 3.4). In organizations with higher level of centralization, high ranking actors in
95
the organization structure are more involved with decision making and therefore the
probability of exception propagation to high level managers is higher. The primary
actor once receiving the exception back may have three options: “redo”, “half do” or
“ignore”. Primary actor may have to redo the service work because his manager
proposed a complete new solution for fulfillment of the request or may have to do a
part of the service work again because of the new information being provided from the
manager or he may completely ignore the service work because the supervisors could
not provide the required information capacity for him. Probability of these options is
again dependent of skills of actors and organizational structure. Enterprises where
more decisions are being made in managerial level, tend to posses more information
capacity and therefore less amount of ignored service work.
Figure 3-17: Exception reporting and exception handling in organization
96
Communication: Activities with reciprocal interdependence require high level of
coordination which is achieved by communication in our PMT model. In the process
of communications actors exchange information to each other and therefore improve
each other information processing capacity. We divide communication within the
organization into two types namely called “informal communication” and “formal
communication”. Informal communication is a type of communication in which actors
use communication channels (face-face, telephones, email …) to exchange
information. In this case actors generate communication events and send them to other
actors through the “communication links”. Formal communication is the type of
communication in which actors attend formal meeting to exchange information.
Actors have to drop any item they have in process if they have to attend a meeting.
Therefore meetings are represented as a preplanned simulation times in which actors
have to allocate their time to the meeting. The ratio of formal and informal
communication within an organization depends on level of formalization in an
organization [20]. Actors in organizations with low level of formalization tend to
interact more in a daily basis rather than attending weekly/monthly meeting.
5oise Processing: Actors in their daily working hours do not always allocate their
attention to work items. There might be several distracting factors that leads to the lost
of attention. As the level of contingency increases in an enterprise, uncertainty of the
environment increases. Thus, actors may lose their attention during the work. We have
defined a type of information that stochastically is generated according to the level of
97
uncertainty (see section 3.4.3.3). When the uncertainty of the enterprise is high, more
number of noise items are generated which consumes the attention and time of actors.
3.5.4.2 Attention Allocation of Actors
Although our extended information processing view of information does not
differentiate among the information being processed by actors, but when the actors
overloaded they prioritize the information. All information is not equally important to
achieve efficiency and performance, therefore actors has to choose which information
to process next. In order to model this information selection we have define an “input
queue” and “output queue" for each human actor. Receiving items are stored in actor’s
input queue and wait for the actor’s attention. Then actors choose a strategy to choose
which information to process. Based on this strategy, they may choose the item that
arrived first in the queue, with higher priority or randomly. We have defined this
strategy based on [15] which describes how managers allocate their attention into their
work.
Each actor has a daily base attention allocation cycle. In the beginning of the day
human actor starts to look into their queue and pick up some items to process, or they
may have some uncompleted work from previous day. They first detect what kind of
item they have picked up, and then make the appropriate action accordingly. The
pseudo code of PMT actor is:
98
if (actor is in its working hours and is not the meeting time) then
check the type of item;
Case item type of
Service Work:
Process(time=f(work volume, actor’s processing speed));
Send item to the next service operation();
If (failure exception occurs) then
Make exception report (time=exception reporting time);
Send exception to supervisor();
Endif
Exception reported item:
If (make decision himself ==true) then
Make Decision (time=decision making time);
Send the item back to supervised actor();
Else
Make exception report (time=exception reporting time)
Send exception to supervisor();
Endif
Exception handled item (decision has been made):
If (decision == Redo) then
Process(time=f(work volume, actor’s processing speed));
Elseif (decision == HalfDo) then
Process(time=1/2f(work volume, actor’s processing speed));
Elseif(decision==ignore) then
Process(time=0)
Endif
Send the item to the next service operations();
Communication item:
Process communication( time=communication time);
99
Noise Item:
Wait (time = noise time);
EndCase
Endif
Figure 3-18: Pseudocode for human daily action cycle
Note that in the above pseudo code, if processing time of an item exceeds the working
hour of actor, the actor leaves the item at the end of the day and starts working on it at
the start of the next day.
3.5.4.3 Organization Characteristics
In the above section we have described micro-level behavior of human actors within
enterprise’s organization from which the emergent behavior of enterprise is derived.
As contingency theory stated “there is no best way to design an organization”,
enterprise environment and the nature of service or product being delivered highly
affects how an organization should be designed. The micro level behavior of actors
highly depends on what kind of organization they work within. For instance, if
organization is very formal, actors prefer to attend formal meeting for exchanging
information rather than casually communicate with others. For these types of
organizations, meetings play an important role, while in an informal organization
actors may ignore meetings. In some organization namely called “flat organization”,
decisions are mostly made by workers and there are not many levels of management.
On the other hand, in centralized organizations workers tend to receive the decision
from managers. In this type of organization, there might be number of managerial
100
levels. In this section we discuss important variables in designing organization and
describe how they affect micro-level behavior of human actors.
Organization Structure and Centralization: Organization structure is defined by
hierarchical relations (Supervise/Report-to) of human actors of different
organizational roles. In PMT, we have defined infinite levels of supervision, but
usually large organizations do not have more than 5 levels of management. Typically,
they may include super level manager, middle-level manager, low-level manager, sub-
team leader and worker. There is no clear definition of Responsibilities for these roles,
and they are different across organizations. Depends on design of the organization, the
amount of decision being made in the organization is different in each level. This
organization design variable is referred to “organization centralization level”.
Centralization is defined by the ratio of decision actors cannot handle and have to
report to their supervisor, to decisions actors make locally by themselves. According
to level of centralization, we categorize organizations into three types: “centralized”,
“decentralized” and medium-level. In a centralized organization, actors tend to get
authorization for most of their jobs, and decision whether to rework or ignore a request
is being made by actors in higher level of management. On the other hand in a
decentralized organization, majority of problems are being resolved by workers and
the decisions are being made locally by actors. Between these two extremes there are
some organizations as medium level centralized where some portion of decisions are
being made locally and some others are reported to higher levels of management.
101
Our experience from working with management companies shows that managers
usually tend to decide on the rework of a request. Because typically managers do not
work directly on the requests and their primary issue is the quality of service which is
achieved by rework of excepted requests. On the other hand workers and sub-team
leaders favor “quick-fix” or ignorance of failures, therefore their decision usually lead
to “half-do” or “ignoring” of exceptions [14]. From the discussion above, we expect
that in the case of constant task complexity and uncertainty, as the level of
centralization in an enterprise increases, the quality and delivery time of service
increases.
Organization’s Level of Formalization: As discussed in section 2.3.3, formalization
is defined by the ratio of information exchange that is formally preplanned to informal
information exchange between actors upon needed. Organizations that are very formal
have clear rules for communication of their actors. They hold predetermined meetings
with a list of participants and require all listed actors for participation. If a meeting is
held with full participation then the quality of information exchange rises and actors
obtains more information capacity for performing their jobs. Conversely, if actors tend
to drop the meetings, the communication quality drops and it leads to less coordinated
activities by human actors. Not participating in a formal meeting has more
consequences in terms of communication lost than an informal communication,
because there are more communication items in meetings and usually the
102
communication items are exchanged once. In an informal organization, on the other
hand there are less preplanned meetings and actors communicate casually through
communication channels. In PMT, these communication channels are represented as
“communication links”, when two actor’s activities have reciprocal interdependency.
Communication channels define which actors are able to exchange information and
formalization level of organization identifies how much actors prefer sending
communication items through these channel rather than participating in formal
meetings. In an informal organization, communication channels are more frequently
used and therefore actors process more communication items in their daily work.
Organization Matrix Strength: While level of formalization defines the frequency of
using communication channels and meetings within an organization, actors may have
a preference between them. Although an organization may hold several monthly and
weekly meeting, but actors may have a tendency to ignore formal meeting and use
casual communication methods. In these types of organizations, actors find meetings
unnecessary and unproductive. Davis and Lawrence [20] stated that the actors’
attention to communication depends on the type of organizational environment
(culture) in which they are imbedded. He described this cultural property of
organization as “organization’s matrix strength” which determines the tendency of
actors for informal and formal communication. In an organization with strong matrix
strength, actors tend to pay more attention to informal communication among the
actors than formal communications. In these types of organization, actors are usually
103
co-located and have an immediate access to each other. On the other hand in an
organization with weak matrix strength, actors are not co-located and therefore prefer
to attend formal meetings for information exchange.
3.5.5 Enterprise Resources
In this section I review current approaches towards enterprise resource modeling and
describe their pros and cons. Then I describe our perspective towards enterprise
resource modeling.
Workflow management systems usually consist of a process model and an
organizational model. These systems usually fail to provide a model to integrate non-
human actors (ex. Data base systems, CNC machines …) into the system [5]. While
many systems may include enterprise resources as a part of their process model, we
draw a line between them. There are three main reasons for separating between
resource model and process model [5]. Firstly, the life cycle of enterprise processes is
different from the life cycle of technical resources. Secondly, the isolation of each
model leads to evolution of each model independent of the other adding to their
robustness. Thirdly, isolated resource model can be shared by several enterprise
services which reduce redundancies and increases the quality of the data maintained.
From our extended information processing view, we define “resource” as an entity that
is assigned to an activity and is consumed to facilitate the information processing for
the assigned activity. Note that in PMT, we have a clear distinction between human
104
actor and non-human actors. We have represented human actors comprehensively
through our extended information processing view of organization and we treat non-
human actors as resources of an enterprise which is addressed in the resource model.
In our computational model this means that a resource affects the speed of actors in
processing a task’s work volume. The resource model then is defined as the
description of resource arrangement and their assignment to process model. There are
some requirements for this resource model. According to Muehlen’s work [5] we
categorize these requirements as:
• Robustness: Enterprise resource model should be isolated from process model
so that a change in process model does not affect a resource model.
• Flexibility: Enterprise resource model should be flexible to allow the transfer of
organization model between services without changing of the organization
structure.
• Scalable: Enterprise resource model should be scalable by providing different
levels of hierarchy and abstractions.
• Domain-Independent: Enterprise resource model should be general and
powerful enough to be able to model enterprise resources of different domains.
In order to satisfy these requirements we define four attributes for a resource:
• Type: A resource may be software, hardware, or a supplier. Depends on the type
of service operation (SOP), different types of resource is required.
105
• Availability: During the 24 hours daily cycle of enterprise, a resource may or
may not be available. Therefore a good match of resource availability and
service operation execution results in a better performance and efficiency for
the enterprise.
• Consumability: A resource can be consumable and diminishing over time, or
non-consumable. Consumable resources need to be supplied as time passes.
• Maintenance: Different resources may require maintenance with different
frequencies.
Resource allocation is a very important issue for enterprises. A good resource
allocation in PMT model results in lower cost, better performance and efficiency.
3.6 Using PMT to Predict Enterprise Performance
Our research on the PMT attempts to develop a computational enterprise model for
quantitative analysis of enterprise performance in a changing environment. Extended
information processing view of enterprise’s organization enabled us to develop an
abstract and powerful model of enterprises. In the above chapters, we have discussed
our modeling approach and event driven simulation associated with it. In this chapter
we discuss how the simulation result can be used to predict enterprise performance
issues. The input and outputs to our computational enterprise model is illustrated in
figure 3.18.
106
Figure 3-19: Input and outputs to PMT computational model
As discussed above, there are four major inputs to our computational enterprise model:
Organization: Human resources in terms of teams, staff leaders and staff members;
organization Structure (Hierarchy within the organization) Communication Channels
(Information exchange paths, Flow of Exceptions) Behavioral Matrices (Work
Processing Behavior, Exception Handling Behavior, Communication Processing
Behavior, Decision Making Behavior)
Clients (Description of client requests): Who are the clients and what is the pattern
of request generation?
Processes (Description of service operations and dependencies among them):
How the service operations are arranged within a service unit? What kinds of
dependencies exist among service operations?
Resource (Description of resources within the enterprise): What kind of resources
is available within the enterprise? How they affect the speed of service operations?
PMT
Simulation
Clients
Structure
Customer Satisfaction
Revenue
(Service Quality)
Organization (HR & Structures)
Resources
Description
Service Processes
Description
Human Behavioral Matrices
Cost
107
The output of PMT simulation is quantitative measurement of “enterprise
performance”. Enterprises are always seeking for increasing their profit by increasing
their sales or decreasing the costs. As enterprises attract more clients, they have to
increase their capacity; otherwise the quality of their service will substantially drop.
This is particularly true for the management companies where there are many human
based activities. A careless increasing of clients may result in severe customer
dissatisfaction and damage of enterprise reputation. Dealing with this trade off to
maximize enterprise profit is a big challenge for today’s enterprises and usually
managers are left with only their self experience. The ultimate goal of PMT
framework is to support managers in their high level decision making about different
aspects of enterprise (clients, organization, processes, and resources). The extended
information processing view enabled us to have a uniform view of enterprise elements
and therefore provided an abstract and powerful analysis framework for enterprise
performance.
108
Figure 3-20: Quality and delivery time of service/product
Client dissatisfaction results mainly because of a bad quality of service/product or a
delay in delivery time. Fergusson [25] in his extensive case studies investigated the
correlation between product/service quality and process quality, and showed how the
integration of facility can improve the quality of product. His study shows a strong
relationship between organization work processes and ultimate product quality. In
PMT, we take this view that bad quality of service/product is primary caused by bad
enterprise process and organization design. Therefore in dealing with customer
dissatisfaction in terms of quality of service/product, we strive to measure
“organization performance” in a quantitative way. We identify quality (effectiveness)
and efficiency as two important dimensions of organization performance. Below we
will describe how these two dimensions are affected as a dependent variable of task
environment, organizational structure and market demand.
109
3.6.1 Organization performance Quality
From contingency theory, we expect that the characteristics of task environment or in
another word nature of service will influence the specific characteristics of
organization structure. These organizational characteristics will influence the outcome
of decision making as a central piece of organization activities. Human actors in
organization hierarchy have different roles identified above as processing service
work, exception reporting-handling, communication and noises. The characteristics of
organization structure affect the allocation cycle of human actors and their policy for
coordination. Thus in PMT, we expect the fit between the characteristics of
organization structure and nature of service will be important for determining the
performance of the organization. Figure 3.20 shows the relationship between task
environment, organization structure and performance.
Our PMT model expected to represent the fitness between task environment and
organization structure in several ways. Following Thompson [74] characterization of
task environment into complexity here I describe two emergent behaviors we expect
from PMT model.
110
Figure 3-21: Fitness of task environment and organization structure
As the complexity of task environment increases, the exception rate increases as well.
This requires more decision making in higher managerial levels of centralized
organization. In a centralized organization, managers will be overloaded by exception
load and lower level actors have to wait for managerial decisions leading degrade of
organization performance. On the other hand for decentralized organizations,
exception will be handled locally in lower level hierarchy leading to less waiting time
and improvement of efficiency. Therefore decentralization leads to more efficiency.
For a routine task the number of exceptions is expected to be low, and therefore
organizations seek to move towards more centralization [74]. Decisions made by
higher level managers are expected to have higher quality. Three options have been
defined in PMT in handling an exception. An actor may decide for rework, half work
111
or ignorance of a work item, and managers tend to decide more for rework. So we can
see a trade-off here between the quality and efficiency of decision making when
centralization is tuned and complexity is fixed. There is always a threshold for the
quality and efficiency that organizations strive to avoid. PMT by simulating the micro-
level behavior of human actors provide a qualitative analysis of the above issue. It is
expected that the emergent behavior will be as figure 3.21 and 3.22 .
Figure 3-22: Efficiency and centralization in a routine task environment
112
Figure 3-23: Quality and centralization in a complex task environment
Uncertainty as the second dimension of task environment determines the frequency of
communication between human actors. As uncertainty of task environment increases,
more communication items will be generated. The behavior of human actors towards
generated communication items is determined by formalization and organization
matrix strength. In a formal organization actors are required to attend pre-scheduled
meetings, while in an informal organization, there are less preplanned meetings and
actors communicate casually through communication channels. Formalization is
defined by the ratio of communication that is formally preplanned to informal
information exchange among the actors on a “need to talk” basis. While an
organization may require formal or informal communication, actors may or may not
choose these communication strategies. Organization matrix strength determines the
tendency of actors for informal and formal communication. In an organization with
113
strong matrix strength, actors tend to pay more attention to informal communication
among the actors than formal communications. In these types of organization, actors
are usually co-located and have an immediate access to each other. On the other hand
in an organization with weak matrix strength, actors are not co-located and therefore
prefer to attend formal meetings for information exchange. It is expected that the
fitness between level of formalization and organization matrix strength lead to the
quality improvement of organization performance. If there is a non-match, many
communication items and meeting will be ignored leading to poor coordination among
human actors. Actors cannot acquire the necessary information capacity for
performing job and as a result many work items will be partially performed or totally
ignored.
Communication takes time and requires actors to allocate their attention. Thus, it can
be seen again that, there is a trade-off between effectiveness (quality) and efficiency.
As actors spend more time for communication, they have to delay the service work
leading to poor efficiency. PMT simulation can provide a qualitative analysis for
managers to achieve the best efficiency and effectiveness from this trade-off. Figure
3.23 shows the expected efficiency and quality of organization as a dependent variable
of formalization and organization matrix strength.
114
Figure 3-24: Formalization and organization matrix strength
It is expected that as the number of clients’ request increases, the quality and
efficiency of organization drops as well. We describe the prediction of PMT model in
the face of increased request items as:
When clients send more service request items (SRI) to the enterprise, input queue of
human actors will be overloaded. This will apparently causes a delay for human actors
to allocate their attention to SRIs. Actors may choose to either select an item that
arrived first in the queue, with higher priority or randomly. Either strategy leads to the
average delay in delivery time of request item and therefore poor efficiency. Time is a
115
very important issue in enterprises’ business transactions. Enterprises do not have
infinite time to fulfill client’s requests and they are obligated to provide the service by
some deadlines. In PMT, we estimate the ability of enterprise to meet the deadlines by
collecting the preplanned delivery time of SRIs (service request items) and the actual
simulation delivery time. We have defined a term “on-time ratio” which represents the
ability of enterprise in meeting deadlines. It is expected that increased number of
requests causes degrade of on-time ratio. Also it is expected that increased number of
requests cause a drop in quality of organization and as a result a drop of service
quality. Communication items are tagged with the time of generation and the
expiration time. If a communication item is processed when simulation time passed
the expiration time of the item, then the communication item will be ignored.
Increased ignorance of communication items result in a poor coordination between
actors and higher probability of exception generation. Hence, when actors’ input
queue is overloaded, more communication is expected to be dropped causing degrade
of organizational effectiveness. Figure 3.24 shows the above emergent behavior we
expect from PMT model.
On-time Ratio = (Number of items delivered on time)/ (Total number of requests)
116
Figure 3-25: Efficiency, quality and on-time ratio
117
Chapter 4: System Implementation
4.1 Introduction
This section describes the system implementation of PMT framework in JAVA. PMT
tool has been developed on top of eclipse RCP (Rich Client Platform) for modeling
and SimJava for simulation engine. In this chapter we first describe the system
architecture of PMT. Secondly, we describe the enterprise model which starts from the
top level view where user has to define who are the clients and services and then
modeling of each of the four building blocks of PMT as client, service, organization
and resources. Thirdly, different organization behavioral matrices will be described as
processing behavior, exception behavior, decision behavior and communication
behavior. Fourtly human resource modeling in PMT will be described. Fifthly,
simulation setting and results will be described as well. At the end of this chapter,
computational issues, such as memory issues, are discussed to show the limitation of
PMT system.
4.2 System Architecture
PMT system consists of four components namely called:
• Application Modeler: consist of GUI that enables the modeler to create his
model and edit it.
• Application Model Manager: Consist of APIs that enables loading and saving
different types of PMT models.
• Simulator: This is the core of PMT where the simulation is executed.
118
• Reporter: The results of simulation is gathered and represented here.
Figure 4-1: PMT component diagram
The interaction of PMT system with outside world is described in use-case diagram.
Either a PMT model can be created from scratch by client or modeler, or a saved
model can be loaded into PMT. For each of these scenarios different steps are required
which are represented in use-case diagram as follow.
119
Figure 4-2: Use-Case diagram
When PMT is executed a blank PMT GUI will be pop up. GUI has three parts as:
• Model Editor: Where user can create and edit his model
• Tree Viewer: For each element that is created in model editor, there will be one
tree element. Tree viewer is used to give an overview of the model in tree
structure and enable users to navigate through the model easily.
• Property Editor: Attributes of each entity in model editor can be changed by
first selecting the entity in model editor and then using this window.
120
Figure 4-3: PMT GUI
At the end of simulation report mode will be selected where the results of simulation
will be reported. This mode has two sections as follow:
• Tree Viewer: Where user can select the entities for viewing simulation results.
• Simulation Results: Simulation results are represented in this section.
Model Editor
Tree
Viewer
Property Editor
121
Figure 4-4: Report mode of PMT
4.3 Enterprise Model
PMT enterprise model starts with client and service architecture, where user has to
define who the clients are and which services the clients are requesting from. Then
each of the four building blocks for the enterprise model as client, service,
organization, and resource should be modeled consecutively.
4.3.1 Client and Service Architecture
Figure 4-2 shows a sample client and service architecture model namely called case
editor. An enterprise may have different cases to study.
Simulation Results
Tree
Viewer
122
Figure 4-5: Clients and services and the relationship among them
Definition 1 (Enterprise):
Ent := {Case1, Case2, Case3, …}
Each case represents clients (CL) and services (SV) within the enterprise and the
relationship between them. Each client entity can request service from more than one
service entities and each service entity can respond to more than one clients.
Definition 2 (Case):
Case := {CL, SV, R
CS
}
Where:
CL = {cl1, cl2, cl3, …} : Clients
SV= {sv1, sv2, sv3, …} : Services
R
CS
={r
CS
1
, r
CS
2
, r
CS
3
,…} : Relationships between Clients and services
4.3.2 Client Model
Client is defined as a source of service requests. A client can be a company, a unit of a
company, a government unit or an individual. We have defined two kinds of clients,
one is called simple client and the other is called operational client. A simple Client
can generate one or more types of service requests periodically or randomly according
to certain distributions. On the other hand operational clients consist of sequence of
COPs (Client Operations). COP will be discussed in detail later in this chapter.
123
Figure 4-6: Simple and operational client
In the case of simple client, only one COP represents the client behavior. In this case,
client has one client operation which sends request to desirable services within the
enterprise. COPs of a client can be sequentially ordered, cyclic or parallel. With series
of investigation and interviews with people in industry, we found out operational
COPs can very well represent the inputs to enterprises for different scenarios. We have
done several real case scenarios which will be discuss in the Case Study chapter. Each
COP in client model may or may not send request to services that have relationship
with corresponding client. Therefore, within client model the services which respond
to requests of the COPs are also modeled.
Definition 3 (Client) :
Client := {COP, SV, R
CS
,R
CC
}
Where:
COP = {cop1, cop2, cop3, …} : Client Operations
SV= {sv1, sv2, sv3, …} : Services
R
CS
={r
CS
1
, r
CS
2
, r
CS
3
,…} : Relationships between Client operations and services
R
CC
={r
CC
1
r
CC
2
, r
CC
3
,…} : Relationships between Client operations
4.3.2.1 Client Operation
From client’s perspective, client operation is a task of its business operations. From an
Enterprise’s business perspective, a Client Operation is a convenient group of service
Requests. Client operation is a unique source of generating Service Request Items
124
(SRI). Service Request Item is the unit of event in our discrete event simulation
system. Each client operation sends SRIs corresponding to its specific distribution
plan. PMT tool provide several distribution functions for modeler to model their real
world request generation.
COPs of a client can be sequentially ordered, cyclic or parallel. Therefore, COPs can
send request to other COPs or the corresponding services within the client model.
Figure 6.4 is a snap shot of a cyclic client model in a ship management enterprise.
Figure 4-7: Simple and operational client
Definition 4 (Client Operation):
Client Operation := {SRI}
Where:
SRI = {sr1, sr2, sr3, …} : Service Request Items
Client operation can be active or inactive. An active COP generates SRIs when the
simulation starts, but inactive COP waits for some events in order to get started. Each
COP has a time table for generating SRIs. This time table is defined by setting the
working hours e.g. generating SRI from 8pm to 9pm, and distribution variable.
Distribution function e.g. normal, uniform, poisson, pareto defines the frequency of
SRI generation within the working hour period.
125
Figure 4-8: Uniform distribution with mean μ and variance σ
As discussed above service request items are generated at client operations and are
sent to services. SRIs carry various information from client side to the service side.
Some examples of the information are: Work Volume, Client/COP from which they
have been generated and priority. The flow of information within an enterprise is
modeled through the flow of SRIs in different services and personals. A SRI is
generated at a COP within a client model and is sent to a service, and then a staff or
manager fulfills its requirement. If the requirement of SRI is not fulfilled by the
service, the SRI is called unsatisfied. The ideal function of services within the
enterprise is to fulfill all generated SRIs within an appropriate amount of time.
4.3.3 Service Model
A Service is provided by Enterprise to Clients and can be chosen by Clients to send
Service Requests. Service has 3 main inputs namely called: Request, Resource and
provider and one output as a result. A service has a single entry/queue to receive SRIs
(Requests). A person or group or the enterprise provide service to incoming SRIs
126
through the usage of available resources within the service. At the end the results of
the service is measured for feedback and analysis.
Figure 4-9: Service model
The main entity within the service model is Service Operation (SOP). SOP is the place
that SRI requirements are satisfied. All SOPs have some staff or managers responsible
for providing their services. A service can have several SOPs ordered sequentially or
in parallel. Two relationships exist between two SOPs namely called: precedence and
communication. If SOP A precedes SOP B, SRIs should first get served by SOP A
before going through SOP B. Communication link will be discussed in detail later in
this chapter. Other than these two relationship, Assignment relationship exist for
associating organization and resources to SOPs.
Figure 4-10: Precedence and communication link
A SRI may go through different SOPs in order to satisfy its requirement. SOPs are
also associated with resources they use for their operations. Branching, Decision, and
Merging entities which will be discussed later in this chapter are used to customize the
127
paths SRIs travel in a service. Figure 4.7 shows the simplest service model that can
exist in PMT.
Figure 4-11: A simple service model
Definition 5 (Service) :
Service := {SOP, Dec, Br, Mg, RS, P, Ent, Ext, R
Pr
,R
COM
, R
Assign
}
Where:
SOP = {cop1, cop2, cop3, …} : Service Operations
Dec= {D1, D2, D3, …, CBD1, CBD2, …} : Regular and Client Based Decisions
Br= {br1, br2, br3, …} : Branching entities
Mg= {mg1, mg2, mg3, …} : Merging entities
RS= {rs1, rs2, rs3, …} : Resources
P= {p1, p2, p3, …} : Personals : Staff and Managers
Ent : Entry of Service
Ext : Exit of Service
R
Pr
={r
Pr
1
, r
Pr
2
, r
Pr
3
,…} : Precedence Relationship among SOPs, Decisions, Branchings,
Mergings, Entry, Exit
R
COM
={r
COM
1
, r
COM
2
, r
COM
3
,…} : Communication Relationship between two SOPs
R
Assign
={r
Assign
1
, r
Assign
2
, r
Assign
3
,…} : Assignment Relationship between Staff/Manager and SOP or
SOP and Resource
4.3.3.1 Service Operation
Service operation (SOP) is a unit of service that performs particular operation on
incoming SRIs. From simulation point of view, the role of SOP is to attach some
information (available resources, skills required ...) to incoming SRIs and send them to
a person or group of people who are responsible for the SOP. Upon receiving
128
completed/uncompleted SRIs from organization level, SOP sends SRIs to downstream
SOPs.
4.3.3.2 Decision
In real world industrial processes, requests do not follow a unique path. Depends on
situation and people decisions SRIs may go to different path within a service. We
introduced two types of decisions to model this issue. From the feedback of our users
in industry, we found out the introduced decisions can very well model real world
scenarios.
Regular Decision: Figure 4.8 shows a simple regular decision with two outputs. In
the simplest case, Regular Decision distributes the SRIs to outputs according to
predefined percentages. Managers can also make decisions for SRIs and define which
path they should go. In that case manager should spend some time to make the
decision.
Figure 4-12: Regular decision
Client Based Decision (CBD): Usually different clients require different operations
for fulfillment of their request. In this case, CBD (Client based Decision) is
129
introduced. This entity checks the clients from which the SRI is coming and sends it to
a particular path depends on its policy.
Figure 4-13: Client based decision
4.3.3.3 Branching (Br)
Parallel works is very common in enterprise operations. Service upon receiving a
request may perform several operations at the same time to fulfill the requirement.
Branching (BR) split the SRIs to sub SRIs and send them to the output ports. These
sub SRIs merge at Merging (Mg) entity, which should be located in downstream.
4.3.3.4 Merging (Mg)
Whenever there is a Decision or Branching, there should be a Merging (Mg) in the
downstream. If Merging is used after Branching, Merging (Mg) does not send any SRI
unless all sub SRIs are available in the queue. Then it merges all sub SRIs to one SRI
and send it. But if it is used after Decision, it simply works as a gateway and for each
SRI, it sends SRI to the next entity.
130
Figure 4-14: Branching and merging
4.3.3.5 Entry/Exit
Each service has an entry from which SRIs enter the service and an exit which is the
end of a service. Exit of one service can be linked to entry of anther service in Client
model. At the Exit of Service, service performance can be measured and analyzed.
4.3.4 Organization Model
We have defined two types of human actors in PMT as staff and manager. Staffs are
type of actors that are responsible to work directly on SOPs, and Managers are located
at higher levels of supervision. Managers and staffs are linked to each other by
“report-to” arcs. Also those who are working directly on SOPs are linked to
appropriate SOP through “assignment” arcs. Therefore the organization model
mathematically can be represented as:
Definition 6 (Organization):
Organization := {Staff, Mgr, R
rep
}
Where:
Mgr= {mgr1, mgr2, mgr3, …} : Managers
Staff= {staff1, staff2, staff3, …} : Staffs
R
rep
={r
rep
1
, r
rep
2
, r
rep
3
,…} : Assignment Relationship among staffs and managers
131
The human actor is associated with set of properties that affect its behavior in the
simulation. These properties are:
• Personal List: Staff/Manager can represent a group of real world employees. So
if a person is involved with more than one group, it can be listed under
different Staff/Manager. A person has a certain amount of availability that can
be shared among different Staff/Manager.
• Skill Set: Set of skills that Staff/Managers can posses (ex. Mechanical, Civil,
Electrical …).
• Skill Level: level of each skill set (low, medium and high).
The behavior of staff/Managers also changes with respect to organization
characteristics. We have defined four behavioral matrices to represent these micro-
level behaviors of Staff/Managers which will be discussed later in this chapter.
Figure 4-15: Sample organization model
132
4.4 Organization Behavior Matrices
Four organization behavior matrices have been defined as “processing behavior”,
“exception behavior”, “decision behavior”, communication behavior”. These four
matrices are to be customized by users for different types of organizations.
4.4.1 Processing Behavior Matrix
The speed of Staff/Manager in processing items is determined according to the
complexity of SOP and skill level of Staff/Manager. Two matrices exist for the
situations where required skill set of SOP matches the skill set of Staff/Manager, and
where required skill set of SOP does not matches the skill set of Staff/Manager.
Apparently if the roles are matched the processing speed increases. As the complexity
decreases and staff skill increases, the speed of Staff/Manager increases and SRIs will
be processed quicker.
Figure 4-16: Skill Level and complexity effects on processing speed
133
We have a very simple resource model at this time which affects the processing speed
of Staff/Manager. As better resources are associated with SOPs, the processing speed
of corresponding Staff/Manager increases.
Figure 4-17: Resource effect on processing speed
Four strategies with different probability can be chosen by actors for picking up items
in their queues. The probability of these strategies can be changed by user from the
following table.
Figure 4-18: Pick up strategy
4.4.2 Exception Behavior Matrix
Complexity and skill level affects the probability of exception generation. As the
complexity increases and skill level gets down, the probability of exception generation
134
increases. Not matching the role of Staff/Manager and SOP will increase the
probability of exception generation as shown in figure 6.13. Communication
ignorance also affects the probability of exception. Each time that a communication
item is ignored by staff/Manager the probability of exception generation increases for
the ignoring Staff/Manager.
Figure 4-19: Exception behavior
4.4.3 Decision Behavior Matrix
For any exception that is generated a decision should be made. Decision Maker Matrix
determines who will make the decision. As the level of centralization increases more
decision will be made more by managers as shown in figure 4.16. There are three
options for decision about excepted SRIs. Staff/Manager can decide for redo, half do
or ignorance. Managers tend to have more redo decisions than staffs. Decision
Making Policy determines the portion of each decision type.
135
Figure 4-20: Decision making and decision maker behavior
4.4.4 Communication Behavior Matrix
Formalization determines the frequency of using communication channels. As the
organization gets more informal, the communication channels will be used more often
as shown in figure 4.17. On the other hand organization matrix strength determines the
behavior of Staff/Managers regarding the communications. For strong organization
matrix strength, more communication items are ignored, and more meeting will be
attended.
136
Figure 4-21: Communication behavior
4.5 Human Resource Model
Each staff or manager in PMT model can be filled by real personals. Personals are real
world individuals in an organization who have to be fitted in different positions in
organization model. To achieve this purpose, a “create person” dialog has been made
as follow:
137
Figure 4-22: Create person dialog for creating new personals
When all personals are created using “create person” dialog, then each staff or
manager should be filled by these personals. For each staff or manager “assign
person” dialog can be used. A personal can work for more than one position; hence for
each personal1.0 “availability” has been defined. For example, a person may spend
0.75 of its availability in one position and 0.25 of its availability on other position.
138
Figure 4-23: Assign persons for each staffs/managers
4.6 Simulation Results
When the model is made, simulation period should be selected in simulation setting
and simulation should be run. Depends on the size of the model and the number of
events generated it may take few minutes for a simulation to be completed. After
completion of the simulation, “report menu” should be selected for viewing different
simulation results. Many graphs and tables are generated for analysis of enterprise
performance such as “efficiency”, “quality”, “work break down”, “bottleneck”,
“working in process”, and “on-time ratio”. Each entity such as staffs/managers, client,
139
service and SOP have its own graphs and tables. Here two sample graphs as “service
work break down” and “on-time ratio” have been shown for illustration purpose.
Figure 4-24: Service work-breakdown
140
Figure 4-25: On-time ratio
4.7 Computational Issues
Our simulation falls into the category of event driven simulation. The events are
generated at client operations and once they are transferred to other entities, new
events will be generated at targeted entities. Each event is an object created in JAVA,
and once the number of these objects exceeds the available memory, memory leakage
can slow down or even freezes the simulation. The simulation has been done using a
DELL laptop with 2.4 GHz CPU and 3 MB RAM. A simple model having one COP,
SOP, staff, and manager has been selected and the number of generated item from
COP is changed consecutively to increase the computational load. The result of the
study is represented in figure . JAVA heap space is occurred when number of events at
141
COP is increased to 10000, which indicated the limitation of current system
implementation.
Figure 4-26: Simulation performance
142
Chapter 5: Validation
5.1 Introduction
Validation is a crucial step in computational organization modeling. Validity of a
computational organization model is a relative term and associated with a degree of
confidence to the results coming from model-based simulations [34]. The question
here is not whether a model is valid or invalid but rather is how reliable the results are.
Levitt et al [34] provided a trajectory for validating emulation computational
organization models, building serious of scenarios for step by step validation. He
identified three levels of validity for computational organization models as reasoning,
representation and usefulness. He also suggested different type of experiments for step
by step improvement of the levels of validity. These experiment types include toy
problem-based, intellective, authenticity, generalizability, reproducibility,
retrospective, natural, and prospective with intervention experiments. Success in each
of these experiments builds more level of confidence in using a model’s results.
5.2 Validation Approach
We have defined following three steps to systematically validate our computational
model. Each step is supposed to build our level of confidence in using the model.
143
• Step 1: Internal Validation. The following 2 questions are supposed to be
answered for internal validation of our computational model:
o Is the implemented system free of bugs?
o Is the emergent behavior valid corresponding to fundamental theories?
In the last 3 years, series of tests have been done for internal validation of PMT model
to make sure the system is bug free. From the beginning of the system development
with the help of our team members from industry, the system has been tested and the
bugs are reported in a timely manner. Therefore, our system is approximately bug free
and being used by people from industry with no clue of system development.
As described in this thesis, our computational model is based on fundamental
qualitative theories in organization in the area of contingency theory. In order, to
confirm that the emergent behavior is valid according to contingency theory, we have
used “Toy Problems”. Simple toy problems are modeled and each aspect of
contingency theory (Task characteristics and organization characteristics) has been
modeled. As it has been shown is section 3.5.1, the emergent behavior of organization
matches contingency theory.
• Step 2: Conceptual Validation. The following 2 questions are supposed to be
answered for conceptual validation of our computational model:
144
o Can the system model real world scenarios appropriately? (Abstraction
and Powerfulness)
o Are the output results of the model valuable for enterprise analysis?
For conceptual validation of model, we used the system to model real world cases.
Abstraction and powerfulness of the model are evaluated in this step. Because of the
complexity of real word, we are obliged to some level of abstraction. If a model is not
abstract enough in capturing real word, modeling becomes a cumbersome activity. On
the other hand, if the model is too abstract many important inputs might be missed.
This will reduce the powerfulness of the model. A conceptually validated model
should be powerful enough to capture all important details which are affecting the real
world. In the following sections where the case studies are discussed, a considerable
confidence has been built on conceptual validity of the model.
While the model needs to represent the real world in a good level of abstraction and
powerfulness, it also needs to collect simulation data and provide useful measurements
to evaluate enterprise. Some of these useful measurements that are uniquely defined in
our model as results of simulations are work breakdown, quality of service, quality of
communication, bottleneck and throughput. These measurements have been evaluated
by practitioners and the usefulness of them has been confirmed. In the following
sections where the case studies are discussed, it will be shown how they are used as
measurements for enterprise evaluation.
145
• Step 3: External (Data) Validation. The following 2 questions are supposed to
be answered for conceptual validation of our computational model:
o Does the prediction of model match the current real world data?
o Can the model predict the future real world data?
External Validation of emulation based models is very hard and time consuming. The
main reason behind this hardness is the existence of human being in the model.
Human behavior involves lots of complexity and uncertainty which make the
abstraction very hard. It is very important for any emulation based model to be tested
in real world for external validity, otherwise the model by itself cannot be reliable.
External validation can be done either for past scenarios or future scenarios. In
simulating past scenarios, the simulation results are compared to currently available
data. But, in future scenarios, the simulation results are compared to future data when
they are available. Therefore, the second type of scenario is supposed to provide
stronger validation because the model tends to be unbiased. For validation of
emulation based organization models managers’ expectation and satisfaction are
usually used as real world data for comparison. Therefore, in our case studies the
simulation results are shown to managers and their feedback have been used as our
criteria for system validation.
146
We performed multiple case studies for external validation from which three are
described in detail in this thesis. The first two scenarios are simulation in the past and
the third case study includes a simulation for future. The cases were chosen from
actual business processes of existing enterprises. These case studies are not selected
randomly, but rather selected to represent and validate various potentials of the model.
As suggested by literature [34][77], case studies are performed by people from
industry with no clue of system development, in collaboration with modelers. Series of
interviews have been done with industries to gather necessary input data for model
validation. In these case studies, the simulation results were confirmed by the
practitioners and the usefulness of the insights derived from the analysis of simulation
results was also verified. Considerable confidence in the PMT model and its
simulation results have been built through the case studies.
5.3 Modeling and Analysis Methodology
Through the course of case studies, we have developed a methodology for modeling
and analyzing business cases using PMT. Following is a list of the steps of this
method:
• Step 1: Define Problem. A modeling or case study starts from interviewing
people who are managers of the concerned enterprise or business processes.
Through interviews, the target problem should be defined by identifying
problematic issues and their scope as well as foci of study. Furthermore,
147
enterprise performance should be discussed and translated into measurable
quantities. It is important to notice that in many cases interviewees may not
clearly understand their problems. Therefore, it usually takes multiple
iterations of interviews and modeling cycles to finalize the definition of a
problem.
• Step 2: Collect Information. Again through interviews, modeling relevant
information pertaining to the target enterprise and business processes is
collected. Information collection should be carried out in four categories:
o Organization information: Organization structures; personnel (i.e., human
resource) and their roles in the organization structures; decision-making
and communication policies; observed decision-making and
communication behaviors; and potential organizational concerns.
o Process information: Number and types of services; operations and
decision-making points including their relations within each services;
assignments of the operations and decision responsibilities to the
organizational positions; resource requirements for the operations and
decision points; and potential service process related concerns.
o Resource information: Number and types of resources involved in
enterprise operations; mappings between the service operations and
available resources; and resource related concerns.
o Client information: Types and number of clients that request services from
the target enterprise and business processes; mappings between clients and
148
their corresponding services; possible range of changes of client situations;
and potential concerns with the client situations.
It is important to note that the above information usually is not readily or
directly available from interviewees. Extracting needed information described
in the above four categories from available and raw information obtained from
interviews is an important step of model. Furthermore, not all information is
needed. Only the information that is related to the scope and foci of modeling
as set in Step1 is useful for modeling and analysis.
• Step 3: Design Case Scenarios. Based on the problem scope, foci of study and
potential concerns in all four areas of organization, service processes, resource
and clients, a number of case scenarios should designed. Scenario design
means to create groups of independent variables shown in Figure 3-18 by
choosing different value ranges for these variables. The four areas mentioned
above constitute a four dimensional space {client, organization, service
process, resource} for creating case scenarios and each scenario represents a
single point in the space. Depending on the problem scope and foci of analysis,
different areas in the space can be explored through well designed scenarios.
• Step 4: Build Models. Building each of the four sub models, namely,
organization model, service process model, resource model, and client model,
is a major step in PMT based modeling and case studies. Before adding all the
details into the model, it is always a good practice to start from one service, a
simple organization, and a small number of clients. Once the “rough” and
149
“small” more is built and its simulation run tested, more details can be added
gradually. The “rough-to-details” and “small-to-large” approach is not only
important for making sure that the model be built more efficiently, but also a
process that allows better understanding of the target enterprise and business
process be achieved. Modeling should be scenario based, i.e., one scenario
should be completed before the start of modeling the next scenario.
Furthermore, the first case scenario should be the “baseline” scenario which is
usually an “as-is” scenario, meaning that the scenario captures what is
currently going on at the target enterprise. Additional case scenarios can be
designed as “to-be” scenarios to device possible and potentially desirable
interventions or changes made in either one, some, or all of the four
dimensions, i.e., organization, service process, resource, and client.
Comparison studies between “to-be” scenarios and “as-is” or “baseline”
scenario provide opportunities to identify best strategies adapt the target
enterprise to new situations.
• Step 5: Perform Simulation and Result Analysis. After the models are built
and tested for each case scenario, simulations are carried out. There are four
stages of simulation and result analysis.
o Stage 1 - Ideal baseline scenario analysis: The goal of this stage of analysis
is to generate simulation results in ideal situations, i.e., no noise and no
exceptions, so that the basic behavior and properties of the target enterprise
and their processes can be understood.
150
o Stage 2 - Real world baseline scenario analysis: At this stage, noise and
exceptions are added into the simulation model so that the risk tolerance
properties of the target enterprise can be studied and the results can be
evaluated against the real data or by enterprise managers to validate the
baseline model. Simple “what-if” studies that do not involve scenario
changes can be carried out within the baseline scenario by iteratively
changing certain parameters of the model. This “sensitivity analysis” is
crucial for understanding the dynamical characteristics of the target
enterprise and its business processes. This understanding serves as a basis
for cross scenario interventions studies.
o Stage 3 - Cross scenario analysis: After potential problems have been
identified and confirmed in the stage of baseline analysis, cross scenario
analysis is carried out by systematically simulating and analyzing other
scenarios and comparing the results of these scenarios designed in Step 3
with those of the baseline scenario. Cross scenario comparison of
simulation results leads to insights of what is the best intervention strategy
to solve the identified problems. By altering clients and enterprise
parameters—i.e., organization, processes, and resources—one may arrive
into the conclusions of what enterprise changes are effective to deal with
changing market demands modeled as types and number of clients.
• Step 6: Iterate and Refine Models and Analysis: It is important to note that
Steps 1 through 5 described above need to be iterated for understanding the
151
problem in hand, designing suitable case scenarios, creating more adequate
models, and generating more valid predictions and intervention strategies. Both
models and analysis results will be refined through the process of iteration
until satisfactory results with sufficient level of confidence are obtained.
5.4 Truthfulness and Availability of Data
As it has been discussed, many data need to be acquired as the necessary inputs to
PMT model. Availability and truthfulness of these data play an important role
consecutively in our ability to model real world cases (conceptual validity) and
accuracy of simulation results (external validity). Acquiring the necessary input data
such as amount of client’s request, skills of employees, and characteristics of tasks
requires the modeler to have a very good knowledge of enterprise environment and at
the same time be familiar with our modeling framework. Therefore high skill
managers have been selected as the main source of acquiring input data to PMT
model. PMT framework has been introduced to them, so that the modeler and
managers at industry could reach a mutual understanding of the case. In some cases
such as organization characteristics, some organizational theories needed to be taught
to managers for acquiring input data.
Because the input data such as skill of employees are subjective to the understanding
of managers, the simulation results are sensitive to correct understanding of managers
152
about the enterprise environment. The assumption here is that, because managers are
interested in realistic simulation result, their input data are tend to be unbiased. The
truthfulness of input data is not only dependent on honesty of managers, but also
depends on knowledge of managers about the input data. Therefore, the input data
always has some amount of uncertainty which is unavoidable in these types of models.
5.5 Case Study 1
Following the methodology described above, we have performed a number of case
studies by working with real industrial enterprises and solving their practical
problems. DT Company with around 140 employees worldwide has been selected for
PMT case study. DT is one of the world leaders for high-performance machine control
solutions. The company provides solutions for complex applications including general
automation, robotics, semiconductor manufacturing, machine tools, medical and
packaging equipment, and many more. Because of the relatively big size of the
company, we have focused on its main branch located in USA. In a big picture the
company is divided into three Departments:
• Production Department: The Company’s products are manufactured and
assembled in this department. These products include circuit boards,
amplifiers, CNCs and specific systems.
• Engineering and Software Department: R & D is very active in the company.
Almost every year there is a new product in the pipeline. Engineering and
153
software developers are continuously involved in design and development of
new products and also provide customer services for old products to outside
customers and inside employees.
• Sales and Marketing Department: As a new product is released, it needs to be
advertised by Sales and Marketing Department. They also need to provide
customer support to outside customers with the help of Engineering and
Software Department.
To validate the effectiveness of PMT framework, Engineering and Software
Department was selected for analysis. This department includes more than 20
engineers located at one place working collaboratively satisfying customer requests
and developing new generation of products. By interviewing the top level and middle
level managers the following initial model of enterprise was developed.
5.5.1 Problem Description and Foci of Study
By interviewing top-level and mid-level managers of the company, the following
problems have been found and from those the foci of case study have been identified.
Because of the technical nature of the company, managers are involved with lots of
service request items (SRIs) and in addition to their managerial activities. Certain
technical tasks can only be performed by certain managers who are expert in the area.
As a result, managers has less time to play their managerial roles, leading to less than
required management activities in the company. In the time of releasing of a new
154
product, an increased amount of works are loaded on experienced and skillful
managers, which make them very busy. This situation is accompanied by the bad
economical climate and extreme lack of man power. The result is a strong demand for
ever higher level of efficiency for the enterprise to survive. With the current settings of
enterprise many tasks are delayed because of the bottlenecks that are caused by some
busy managers. Therefore, it is highly crucial for the enterprise to detect the
bottlenecks of their processes and then plan and execute effective interventions to
eliminate these bottlenecks.
According to the above discussion the foci of study have been identified as:
• Detecting the operations and staffs assigned to them that are causing bottleneck
in service processes.
• Increasing the information processing capacity of organization by extending
the working hours of overloaded staffs.
5.5.2 Modeling
The enterprise is modeled and simulated for a period of three months from beginning
of February 2009 to end of April 2009. The input data is collected by series of
interviews with top level and middle level managers. During this targeted period a big
part of engineers’ times are spent on a new product which is supposed to be released
soon after the case study. At the same time engineers still need to do their regular jobs
such as customer support. In the next sections, sub models of the company are
155
described. These sub models are derived based on the information collected from
managers at the company, according to our “rough to detail” and “small to big”
approach.
5.5.2.1 Clients and Services
The clients and services are modeled general enough that allows managers to change
the data and make it suitable for other times of the year by only changing the input
data not the model itself. Engineering department and software department interact
with other departments, such as Sales and Marketing Department and Production
Department, within the company and also outside customers. 4 major clients are
distinguished as the main demands. These clients are:
• Direct customers: Customers who buy products or system from the company
and require engineering support. Depends on the type of the request different
processes and engineers are involved.
• Customer service: Outside customer may also indirectly get engineering
support through the employees working in sales and marketing department.
The employees provide customer service to outside customer by the
engineering support of the engineering and software department. Same as
Direct customer the following COPs are recognized:
o Application solution
o C5C Application
o General Engineering Support
156
o Software Support
• 5ew Product (PPMAC): The new product of the company called PPMAC
(Power PMAC) has put a huge load on the organization at the time of this case
study. Because the company is continuously involved with new product
engineers always spend part of their time dealing with development of these
products. A new product involves the engineering design (Mechanical and
electrical design) and software design as two major COPs:
o Engineering Design
o Software Development
• Old Product: Upon a failure or some other circumstances about old products
employees at production department may request engineering support from
engineering and software department. The rate of inquiries is usually less than
new products and they mostly interact with engineering department. One COP
has been recognized as :
o Engineering Support
The two departments have been modeled as the two services in the model. Therefore
the client and service architecture of the model will be as follow:
157
Figure 5-1: Client and service architecture
5.5.2.2 Client Model
According to our definition, clients consist of any entities that request services from
Engineering and Software Department. It can be categorized as:
• Direct Customer: The type of requests that is generated by direct customers
(COPs) can be categorized as :
o Application solution: This service is provided by the company when a
system is requested by customers that involves the company products.
o C5C Application: CNC systems provided by the company falls into this
category
o General Engineering Support: Maintenance and general Q&A support
falls into this category
o Software Support: Software related customer support falls into this
category
158
COP Period(Month) Distribution
Mean
(Hour)
Variance
Scale
Factor
Application
Solution
3 Normal 24 5.0 1
CNC Application 3 Normal 12 1.0 1
General Support 3 Normal 1 0.1 1
Software Support 3 Normal 16 1.0 1
Table 5-1: Input parameters for direct customer
Figure 5-2: Client model for direct customer
• Customer Service: Client model for customer service section of the
enterprise is the same as direct customer but with fewer requests.
159
COP Period(Month) Distribution
Mean
(Hour)
Variance
Scale
Factor
Application
Solution
3 Normal 42 5.0 1
CNC Application 3 Normal 24 1.0 1
General Support 3 Normal 2 0.1 1
Software Support 3 Normal 32 1.0 1
Table 5-2: Input parameters for customer service
• PPMAC (5ew Product): This is a new generation of the company’s motion
controller which took 4 years of design and development. At the time of this
simulation the product is about to be released to the market and therefore a hug
part of engineers is spent on the product. The kind of request (COP) that is
generated by this project can be categorized as :
o Engineering Design: This involves all the requirements which should be
integrated to enable the board functionalities. Lots of major tasks need
to be done in parallel in order to satisfy this requirement.
o Software Development: The product is associated with a user friendly
software. Software development has lots of major task which fulfills
the requirements of the software.
160
Figure 5-3: COPs for PPMAC
COP Period(Month) Distribution
Mean
(Hour)
Variance
Scale
Factor
Engineering Design 3 Normal 4 5.0 1
Software
Development
3 Normal 2 1.0 1
Table 5-3: Input parameters for PPMAC
• Old Product: The people work in production, sometimes require engineering
support in the production line for old products. This Client only send requests
to engineering department and it only consist of one COP:
o Engineering Support: Any type of engineering support that is requested
from engineering department.
Figure 5-4: COPs for old products
161
COP Period(Month) Distribution
Mean
(Hour)
Variance
Scale
Factor
Engineering
Support
3 Normal 32 5.0 1
Table 5-4: Input parameters for old products
5.5.2.3 Organization Model
The enterprise‘s organization has 4 levels of hierarchy as president, vice president,
manager and engineering staff. In this case study we have focused on engineering and
software department and therefore the president of the company has been excluded
from the organization hierarchy.
Figure 5-5: Organization hierarchy
The complete organization model according to this organizational hierarchy is as
follow:
162
Figure 5-6: Engineering department organization
Figure 5-7: Software department organization
5.5.2.4 Process Model
Based on the interview the following top level process model has been derived for the
engineering department. Depends on the type of client different processes are
performed by the organization.
163
Figure 5-8: Process model for application engineering department
Figure 5-9: Process model for software department
The following table illustrates the major tasks that each engineer is involved with and
its associated properties in the application Department:
164
# Task Assigned Personnel
Work
Volume
Complexity Uncertainty
1 Manager Support
Application Engineering
Manager
1.0 low low
2 Engineer Support Application Engineer 3.0 Medium Medium
3
Engineering Manager
Solution
Application Engineering
Manager
1.0 Medium Medium
4
Project Manager
Solution
Senior Project Engineer 3.0 Medium Medium
5 CNC Manager Support CNC Manager 3.0 Low Low
6
CNC Technician
Support
CNC Technician 3.0 High High
7 PPMAC Firmware1 Firmware Developer 2.0 high high
8 PPMAC Firmware2 Senior Firmware Developer 2.0 Low Medium
9 PPMAC Firmware3 Senior Software Developer 0.5 low medium
10 PPMAC Application
Application Engineering
Manager
0.5 medium medium
11
PPMAC Overall
Design
Vice President of
Engineering
1.0 medium medium
12 PPMAC Software1 Senior Software Developer 0.5 medium medium
13 PPMAC Software2 Senior Project Engineer 3.0 medium high
14 PPMAC Electronics Electrical Engineer 3.0 medium medium
15 PPMAC Database Firmware Developer 2.0 low low
16
PPMAC Feature
Development
Application Engineering
Manager
0.5 medium medium
17
PPMAC Product
Design Test
Test Engineering Manager 3.0 high high
18 PPMAC Fixture Test Test Engineering Manager 3.0 high high
19 PPMAC Function Test Test Engineer 5.0 high high
20
PPMAC Application
Testing 1
Application Engineer 1.0 medium medium
21
PPMAC Application
Testing2
Application Engineering
Manager
1.0 medium medium
22 Power Product Support Power Product Engineer 5.0 medium medium
23
Power product Manager
Support
Power Product Manager 5.0 medium medium
24 Production-Software Senior Software Developer 1.0 low low
25 Production-Application
Application Engineering
Manager
1.0 medium medium
Table 5-5: Input parameters for application engineering service operations
165
Table 5-6: Communication table for application engineering operations
# Task Assigned Personnel
Work
Volume
Complexity Uncertainty
1
PPMAC Compile &
Debug Software
Software Engineer1
1.0 medium medium
2 PPMAC GUI Software Engineer1 1.0 medium medium
3
PPMAC Software
Communication
Software Engineer2
1.0 medium medium
4 PPMAC Drivers Software Engineer2 1.0 medium high
5 PPMAC .Net Software Engineer3 1.0 medium medium
6 PPMAC User Interface Software Engineer3 1.0 medium medium
7 PPMAC Tuning Software Engineer4 1.0 medium medium
8 PPMAC Data Gathering Software Engineer4 1.0 medium medium
9
PPMAC Software
Installation
Software Engineer5
1.0 medium high
10 PPMAC Debug Software Engineer5 1.0 medium medium
11
PPMAC Software
Coordination
Senior Software
Developer
1.0 high high
12 PPMAC Overview Vice President 1.0 medium medium
13
PPMAC Quality Control Software Development
Manager
1.0 medium medium
14
Software Support Senior Software
Developer
1.0 medium medium
Table 5-7: Input parameters for software development operations
Communication
#
Task1 Task2 Personal1 Personal2
Expiration
Period
1
PPMAC
Firmware2
PPMAC
Firmware3
Senior
Firmware
Developer
Senior
Software
Developer
48
2
PPMAC
Firmware1
PPMAC
Firmware3
Firmware
Developer
Senior
Software
Developer
48
3
PPMAC
Software1
PPMAC
Software
Feature
Senior Software
Developer
Application
Engineering
Manager
48
4
PPMAC
Software2
PPMAC
Application
Senior Project
Engineer
Application
Engineering
Manager
48
5
PPMAC
Firmware1
PPMAC
Application
Senior
Firmware
Developer
Application
Engineering
Manager
48
166
Communication
#
Task1 Task2 Personal1 Personal2
Expiration
Period
1
PPMAC
Software
Installation
PPMAC .Net
Software
Engineer5
Software
Engineer3
24
2
PPMAC
Software
Installation
PPMAC
Compile and
Debug
Software
Engineer5
Software
Engineer1
24
3
PPMAC
Software
Communication
PPMAC .Net
Software
Engineer2
Software
Engineer3
24
4
PPMAC
Overview
PPMAC GUI Vice President
Software
Engineer1
24
5
PPMAC
Overview
PPMAC
Communication
Vice President
Software
Engineer2
24
6
PPMAC
Overview
PPMAC
Tuning
Vice President
Software
Engineer4
24
7
PPMAC
Overview
PPMAC Data
Gathering
Vice President
Software
Engineer4
24
8
PPMAC
Overview
PPMAC
Software
Installation
Vice President
Software
Engineer5
24
9
PPMAC
Overview
PPMAC
Software
Coordination
Vice President
Senior Software
Developer
24
10
PPMAC
Overview
PPMAC
Quality Control
Vice President
Software
Engineering
Manager
24
11
PPMAC
Software
Coordination
PPMAC
Software
Installation
Senior
Software
Developer
Software
Engineer5
24
12
PPMAC
Software
Coordination
PPMAC
Software
Communication
Senior
Software
Developer
Software
Engineer2
24
13
PPMAC
Software
Coordination
PPMAC
Quality Control
Senior
Software
Developer
Software
Engineer
Manager
24
Table 5-8: Communication table for software engineering operations
5.5.3 Simulation Scenarios
Five simulation scenarios have been defined in which the working hours of managers
assigned to bottleneck process are changed consequently. The initial simulation
represents “As-Is” organization under current work load. By analyzing the results of
167
this simulation bottleneck processes and the key staffs assigned to them are identified.
By detecting theses key staffs which are found to be all managers, the following
simulation scenarios have been defined.
• “As-Is” Scenario: This scenario simulates the current working hours of staffs
at the time of this case study which are 4 days a week and 8 hours a day.
• Extended 1 hour in a day: This scenario adds 1 hour to working hours of
managers who are detected to cause bottleneck.
• Extended 2 hours in a day: This scenario adds 2 hours to working hours of
managers who are detected to cause bottleneck.
• Extended 1 day in a week: This scenario adds 1 day to working days of
managers who are detected to cause bottleneck.
• Extended 2 hours in a day and 1 day in a week: This scenario adds 2 hour to
working hours and 1 day to working days of managers who are detected to
cause bottleneck.
5.5.4 Simulation Results and Analysis
The initial simulation represents “As-Is” organization under current work load.
Through the data gathered during the simulation the bottleneck processes and
corresponding staffs are detected. Bottlenecks are calculated as follow:
SOP’s Bottleneck = Avg (WIP during simulation) =
Time Simulation
WIP of Period i
WIP i
i
i
_
_ _ *
max_
1
∑
=
=
168
WIP = Number of SRIs waiting to be processed
According to this definition processes with highest bottleneck have been identified and
shown in figure 4-10.
Figure 5-10: Bottleneck of processes
As illustrated in the tables above, these processes are assigned to some managers. This
has been implicitly acknowledged by the managers at the company. These personals
are the people at the center of communication and decisions making with many critical
tasks, therefore they usually have many items in their queues to be processed. Here we
simulate the organization with extended working hours for these personals and show
the reduction of bottleneck for SOPs. Figure 4-8 shows the bottleneck for each of the
169
cases. From this figure it has been shown that case 5 will result in bottleneck of less
than 20 for all processes.
By detecting of bottle neck processes, the quality of service for these processes of 5
cases described above has been analyzed. The number of completed SRIs as the
criteria for the quality of service has been selected and shown in figure 4-11. Figure
4-12 shows the normalized value by dividing the number of completed SRIs by total
number of SRIs generated by clients for each SOP.
Figure 5-11: 5umber of completed SRIs
170
Figure 5-12: Quality of service
By increasing the capacity of organization through extended hours and day, the quality
of more than 80% can be achieved for all critical SOPs. The extension of hours is
associated by extra cost but is necessary to maintain the quality of service and is
suggested to the company.
5.5.5 Case Validity
This case study built considerable confidence over conceptual validity and external
validity of PMT model. Client service architecture helped us isolate a department
inside an enterprise and define the outside partners as clients. It also provided the
means to define the boundary of that department and the paths from which requests
are sent to. Client model has been found to be generic enough to model different types
171
of clients such as outside customers, new product, sales and production department. It
also captured demand functions of these different client types with some level of
uncertainty.
Our process model and task representation using work volume, complexity,
uncertainty and interdependence has enabled us to capture the engineers’ real tasks
with good level of abstraction. Through the interviews, we received positive feedbacks
from the managers at the company regarding our generic way of process modeling and
task representation. Also the organization model based on Galbraith’s information
processing view, has been found to be strong enough to model the real world
organization with its levels of hierarchy and communication channels. Work
breakdown of each employee has been represented to managers at the company and
found out to be close to what they expected. Simulation detected the managers with
bottleneck and the results have been confirmed by managers at the company. Further,
the alternative scenarios show a sound nonlinear increase of organization capacity
through extended working hours. This built our confidence on the stability of the
organization model as a network of processing nodes and its ability to represent
organization capacity in a uniform way.
5.6 Case Study 2
This section describes a case study of J Co, a marine consulting enterprise. J Co has 40
projects for consulting which are modeled as outside clients. There are 10 people
172
working at the company who are assigned simultaneously to different projects at the
same time. By interviewing the top level and middle level managers the following
initial model of enterprise was developed. In contrast to Case Study 1, where full
detail of models is described, in this case study only one example is represented and
discussed because of the large size of the sub models.
5.6.1 Problem Definition and Foci of Case Study
Through a series of interviews with managers at the company it has been found that
recently labor cost has dramatically increased due to staff members working over time.
Managers at the company believe that bad decision making from managers may have
caused lots of rework for the organization. Therefore, they highly suspect bad
communication is the cause of poor process performance. Organization hierarchy has
three levels including program manager, project manager and staff. They believe
program manager does not make good decisions for his subordinate staffs and
therefore lots of rework have to be done to maintain the service quality. We have
defined our foci of case study according to the concerns of the manager as follow:
• Examining the communication performance of the company in carrying out its
business processes.
• Identifying the communication bottlenecks and providing alternative solutions for
that.
173
5.6.2 Modeling
The enterprise is modeled and simulated for 1 year. In the next sections, sub models of
the company are described. These sub models are derived based on the information
collected from managers at the company, according to our “rough to detail” and
“small to big” approach.
5.6.2.1 Client and Service Architecture
According to the case scenario, all projects processed by J Co. are categorized into 9
types of projects. Depending on the type of the project, its required tasks differ, as
shown in Table 4-9. For example, Project 1 is composed of “Inquiring” and
“Document Study” tasks. Each type of the projects was modeled as a Client, and the
tasks listed in Table 4-9 were modeled as a set of Service. Figure 4-13 shows the
Clients and Services relations based on Table 4-9. In the figure, the sky blue bubbles
are Clients and orange rectangles are Services.
174
Required Project Tasks as Services
Inquiring
Documen
t Study 1
Documen
t Study 2
Field
Survey
Traffic
Simulatio
n
Maneuve
ring
Simulatio
n
Anchorin
g
Simulatio
n
Project Types as Client
Project 1 X X
Project 2 X X X X
Project 3 X X X X X
Project 4 X X X X X X
Project 5 X X X X
Project 6 X X X
Project 7 X X X
Project 8 X X X
Project 9 X X X X
Table 5-9: The project types and required project tasks
Figure 5-13: Client and service model
5.6.2.2 Client Model
Each project modeled as a Client has a set of required project tasks. Each project task
requires its corresponding services from the J Co. The project tasks, therefore, can be
defined as COPs (Client Operation), which are the generators of SRIs (service request
175
items). Figure 4-14 shows the client description for Project 4. The green and blue
colored rectangles are the project tasks or COPs. They are defined by execution
duration, frequency of request generation, and its variance. Each task is linked to its
corresponding service shown as orange rectangles. After a task is completed during
the defined execution duration, its successor task is initiated.
Figure 5-14: Project tasks as client operations
5.6.2.3 Organization Model
The enterprise organization has 3 levels of hierarchy as general manager, project
manager, and junior staff. Depends on the type of service, these managers and staff are
assigned to service organization with three levels of hierarchy as program manager,
project manager and staff. Figure 4-15 shows this assignment from enterprise
organization to service organization.
10 Months
176
Figure 5-15: Enterprise and service organization
5.6.2.4 Process Model
Figure 4-16 is a model of a service provided by J Co. The green objects are the
positions of the service organization, which are Program Manager, Project Manager,
and Project Staff. The yellow rectangles are the SOPs (service operations) for the
service. In this case, three types of SOPs were modeled, which are Practical Operation,
Customer Coordination, and Program Management. Practical Operation directly
contributes to completing the client’s requests. Customer Coordination is the
coordination with the customer regarding the project. Program Management is the
control and governance operation to align all projects and enterprise policies. Practical
Operation and Customer Coordination, and Customer Coordination and Program
Management are linked by Communication links, which indicate the communication
177
dependency. In this case, communication is the most crucial focus. By defining the
management operations for Project Manager and Program Manager with their
communication dependencies, the focus was appropriately modeled.
Figure 5-16: Service operations and organizations
5.6.3 Simulation Scenarios
In this case study, we performed simulations only for the market environment captured
by Table 4-9 and Figure 4-13 for as-is analysis. Various to-be analyses can be
performed by designing possible to-be market situations, such as changing number or
the types of annual projects and varying available HRs. Simulation scenarios that are
analyzed in the next section are defined by changing the number of projects assigned
to the organization. At the time of the case study 40 projects exist, but it can be
changed from 10 to 50 depends on the time of a year and economical situation.
Managers at the company are very interested to know about the communication
178
performance of organization when 50 projects are assigned. Therefore the simulation
scenarios are defined for 10, 20, 30, 40, 50 number of projects as clients.
5.6.4 Simulation Results and Analysis
In this case study, the simulation was performed for one year. In our system,
efficiency, cost/profit, work breakdown, Number of work items in process, and
processing time are measured.
As an example, Figure 4-17 shows the Work Breakdown Chart of an entire service,
which reveals how much human resource is spent for the works, such as “direct
work”, “rework”, “communication”, “decision-making”, and “idle”, respectively.
In the case scenario, the communication issue is considered as the most crucial focus.
The communication quality of each position, therefore, was measured and examined.
Figure 4-18 shows a set of simulation results. The communication quality plotted with
respect to the number of annual projects. The communication quality is defined as
follows.
ions Communicat Generated of umber
ions Communicat ocessed of umber
Quality ion Communicat
Pr
=
179
According to the definition above, if a position cannot process the communication
within the appropriate time, the communication quality will be decreased.
Figure 5-17: Work breakdown chart of PMT
From Figure 4-18, the following conclusions can be obtained:
• J Co initially considered the Program Manager to be the cause of
communication problems. The simulation, however, indicated that the Program
Manager was not the bottleneck but the Project Manager was.
• The insufficient communication from the Project Manager may have been the
cause for the poor decisions of the Program Manager.
180
• Insufficient communication from the Project Manager might have also
negatively influenced the Project Staff’s operation quality, which depends on
the Project Manager’s timely responses.
Figure 5-18: Communication quality for different positions
We discussed these findings with the managers of J Co. Most of them shared these
views. After reviewing the simulation results, they recognized that the problem was
with the Project Manager who had been extremely busy with real consulting and
customer relation work, leaving too little time for his managerial duties.
5.6.5 Case Validity
This case study built considerable confidence over conceptual validity and external
validity of PMT model. Client service architecture helped us to model projects as
outside clients and to simulate the input load coming from clients. Cyclic client model
has found to be strong to model clients with different stages of operations. It also
181
could capture demand functions of these client operations with some level of
uncertainty which yield to a strong representation of real clients.
Our process model and task representation using work volume, complexity,
uncertainty and interdependence has enabled us to capture real world processes with
good level of abstraction. Through the interviews, good feedbacks have been received
by managers at the company regarding our generic way of process modeling and task
representation. Also the organization model based on Galbraith’s information
processing view, has been found to be strong enough to model the real world
organization with its levels of hierarchy and communication channels. This case study
has been particularly suitable for our organization model because of issue of
exceptions and reworks in organization. As this has been the main concern of the
managers, our organization model provided powerful insides for them. Work
breakdown of each employee has been represented to managers at the company and
found out to be close to what they expected. Communication quality provided a good
measurement for analysis of communication in the organization and the results from
different scenarios have been confirmed by the managers. The simulation results made
managers to think twice over their judgment about poor communication, which shows
the usefulness of the model for practitioners.
182
5.7 Case Study 3
X Co, automotive company’s branch with around 1400 employees, has been selected
for our third case study. Because of the big size of the company only stamping dies
design section of the company with 50 employees has been modeled and analyzed. By
interviewing the top level and middle level managers, the following initial model of
enterprise was developed.
5.7.1 Problem Definition and Foci of Study
Currently, the company is operating in a product based manner, meaning for each
product a group of designers are assigned. The current product based approach does
not yield a satisfactory performance and efficiency for the company. Also 20% of the
designers are unskilled fresh designers and managers are undecided about how to
position them in the organization. Therefore, managers are looking to switch their
product based approach to process based approach. For this purpose, because of their
unfamiliarity to the new process, they need to increase their level of confidence in
making the decision. PMT has been used to simulate both product based and process
based model and the result is delivered to the company to support the manager’s
decision making.
Our case study is focused on fundamental questions and ambiguity that managers have
in their minds in changing from product based process to function based process.
These questions can be categorized as follow:
183
• Is the product based process tolerant to overloaded situation? As the market
grows and the number of request for stamping dies increases, the organization
will be overloaded. Is the product based organization tolerant to this situation,
meaning to maintain a reasonable throughput even when overloaded.
• Is it difficult for product based organization to provide OJT (On Job Training) to
a large number of unskilled fresh designers?
• If the function based (process based) organization is employed, will it be
tolerant to overloaded situation?
• If function based (process based) organization is employed, where should the
unskilled designers be allocated?
We have used PMT to simulate and predict the enterprise behavior for product
based and function based process to answer these four questions. PMT predictions
have been delivered to managers to build their level of confidence in changing
their design of organization.
5.7.2 Modeling
Figure 4-19 shows the difference between product based and function based process.
In product based process, a team of designers are assigned to one product from start to
end. So each designer should work on different stages of a product design. In contrary,
in function based process, a group of designers are assigned to one function for all
184
products of the company. So, each person deals with different products, but just one
stage of the design.
Figure 5-19: (a) Function based process (b) Product based process
5.7.2.1 Client and Service Architecture
Figure 4-20 shows the client and service PMT model of X co. Stamping dies are
designed for 6 product models. In PMT we have modeled them as the clients. The
clients have been modeled with only one COP which is generating requests. One
service has been modeled which includes all the necessary operations to prepared a
clay model for mass production. In this case study each client only includes a simple
client operation; therefore the client model section has been overlooked.
185
Figure 5-20: Client and service model
5.7.2.1 Organization Model
Organization in X Co has three levels of hierarchy as general manager, project
manager and staff. These three levels of hierarchy has been shown in figure 4-22 and
4-22. Table 4-10 shows the skill of each designer according to the operations. In
earlier stages there are fewer high skilled designers than the later stages because of the
higher complexity.
186
Table 5-10: Skills of designers for different design phases of stamping dies
5.7.2.2 Process Model
Stamping dies has four major stages which prepare clay model for mass production.
These stages are namely called: 1- Prototype test 2- Prototype try 3- Prototype Design
4- Product try. From ending to beginning, the operations get more complex. Beginning
one is the most complex and ending one complex is most simple (Figure 4-21).
Figure 5-21: Task complexity in different design stages of stamping dies
187
Two models for product based and function based process have been created. Figure
4-22 and 4-23 show these models:
Figure 5-22: Product based service model
188
Figure 5-23: Function based service model
5.7.3 Simulation Scenarios
Five Scenarios were simulated for product based and function based process. Human
resource allocation is different for each scenario. Number of labors in each team and
skill levels of labors cause different teams to have different work processing
capability. For each scenario, 6 cases varying the load level (50% to 100%) to the
Designing Process were simulated. Table 4-11 and Figure 4-24 show the different
simulation scenarios and human resource allocation for each scenario.
189
Table 5-11: Skills of designers for different design phases of stamping dies
Figure 5-24: Human resource allocation for simulation scenarios
190
5.7.4 Simulation Results and Analysis
Two criteria have been chosen to evaluate the performance of enterprise in the
mentioned simulation scenarios. These criteria are:
• Processing Capability: The throughput of each simulation (number of
completed SRIs) under different load cases has been measured. This has been
used to address the first managers’ question. The load is increased and the
throughput has been measured to see how tolerant the organization is in
overloaded situations.
• Communication Quality: The ratio of processed communication requests to
the generated communication requests has been used to evaluate the
communication quality of organization. The communication quality indirectly
affects the performance quality of organization. The load is increased and the
communication quality is measured for different load situations.
Figure 4-25 shows the throughput of product based and function based process when
load is increased from 50% to 100%.
Figure 5-25: Product based and process based process throughput
191
From this figure, we can make the following conclusion:
• Product based process is not tolerant to overloaded situations: When load
is increased (>80%), throughput is dramatically dropped. Different assignment
of team members has a high impact when organization is normally load
(~80%), but in overloaded situation it does not have much effect. This makes
the organization vulnerable in situations where the amount of requests exceeds
the capacity of organization. Therefore, product based process is not
recommended for the enterprise, if the probability of overloaded situations is
high.
• Function based process is tolerant to overloaded situations: When load is
increased throughput is maintained. A good assignment of team members can
highly increase the work capacity of organization in overloaded situations.
Therefore, it is suggested for the company to adapt this type of organization to
increase its performance and efficiency when overloaded.
Figure 4-26 shows the communication quality for the most complex and the simplest
design stages of stamping dies. Product based process and function based
communication quality for different loading situations have been analyzed.
192
Figure 5-26: Communication quality of product and function based process
From this figure the following conclusion can be made:
• In product based process, it is quite hard for unskilled designers to obtain
enough information in highly loaded situation. From Figure 4-26, we can
see that for both simple and complex design phases, the communication quality
is dropped in overloaded situations. When communication quality is dropped
the fresh unskilled designers will have less opportunity to be trained.
• In Function Based Process, unskilled designers should be allocated to the
downstream operation. From Figure 4-26, we can see that in product try
phase (the most simple), the communication quality is maintained even in
overloaded situation for function based process. Therefore, the unskilled fresh
designers are better to be allocated to the downstream operations, because of
the higher opportunity of communication. The experienced designers have
more free time to spend for communications, and therefore the learning curve
of fresh designers has higher increase. They can be relocated after gaining
enough knowledge to the upstream design processes.
193
Table 4-12 shows the prediction of PMT model for managers ‘questions. The
quantitative results of PMT provide a good picture of the new process for the
managers and build some confidence for them.
Table 5-12: PMT prediction of managers’ fundamental questions
In this case study the tolerance of X co organization has been tested and simulated
using PMT model. It has been shown that function based process model provides
better tolerance in overloaded situation. In this type of process, because the overload
of one person only affects the throughput of one operation, therefore the throughput
can be maintained by a good assignment of members to the teams. The case study also
shows that the tolerance of function based process improves the communication
quality. Therefore it is suggested that the fresh designers be allocated to the simpler
operations where there is a better opportunity for communication. Communication in
194
an organization is modeled through communication items in PMT which has an
expiration period. If the communication items are not processed during the expiration
period, the communication item will be dropped which causes the poor
communication. In process based organization, by a good assignment of team
members the load can be uniformly distributed to team member. This releases the
stress from the organization and provides opportunity for communication items to be
processed. Generally from this case study the following conclusions can be made:
• The tolerance of function based process makes it suitable in situation where
operations have their own required skills and there is a low interference
between them. This will maintain the throughput of process even in overloaded
situations.
• If the possibility of overloaded situation is not high and tolerance is not an issue
for an organization. Product based process may have some advantage over
function based process, because it can better integrate the information for all
operations of product.
• For most of engineering areas, fresh workers require some time for learning in
order to perform their jobs. Therefore it is suggested that the fresh workers be
placed in part of the organization which is not overloaded. This causes a higher
learning for fresh workers.
195
5.7.5 Case Validity
This comprehensive case study further built our confidence over conceptual validity
and external validity of PMT model. Generic client service architecture helped us to
model design products as outside clients and to simulate the input load coming from
each product. The demand functions for each product have been captured effectively
by client model with some level of uncertainty.
Current business process is modeled effectively and saturation of organization in
overloaded situation has been understood through the simulation. This provided
powerful insights for managers to understand the reasons behind poor performance of
organization in overloaded situation. Our organization model as a network of
processing nodes with limited capacity, has shown a sound nonlinear behavior when
the load is increased. An alternative business process (function based) is suggested and
simulated, which increase the organization capacity suitable for overloaded situation.
The results of simulation for new business process were delivered to managers and
tremendously reduced unfamiliarity of managers with new business process.
Currently, this company is adapting the new business process suggested by PMT. It is
expected that thousands of dollars be saved by adaption of new business process
through increased productivity and communication quality. Future data will be
reported and compared with simulation results for further validation.
196
Chapter 6: Contributions and Future Directions
Concluding this dissertation, we provide a detailed list of contributions and future
directions which we hope to take this research in.
6.1 Contributions
Our research made contributions to the areas of organization research, enterprise
modeling and integration, and engineering collaboration. Following is a list of our
contributions:
(1) Developed a framework to integrate different aspects of an enterprise.
Researchers from different research areas have their own perspective to the
problem. In Process modeling area, traditional workflow management and
process modeling techniques have their different weak points. They focus on
process as the only important parameter in enterprise modeling and few of
them take organizational structure into account. They have different views
namely called market-driven (economics), operation-driven (workflow
management), organization-driven (social science). PMT framework bridges
all these views and put all of them together in a single model and identifies the
relation between the key concepts of these areas. The relationship between
market trend (how the clients request service from enterprise), business
process (How the managers should organize the processes to fulfill client’s
request) and organizational structure (How staffs and managers should work
together) is a very important topic that is addressed in PMT. Traditional
197
enterprise model consists of a process model and an organizational model.
Although research in process modeling is saturated, but organizational model
provided by current research is at a very elementary level. Also, these systems
usually fail to provide a model to integrate non-human actors (ex. Data base
systems, CNC machines …) and client model into the system [5]. PMT as a
unique framework puts all different elements of enterprise (Organization,
Process, and Resource) into a one model and integrates these concepts through
extended information processing view.
(2) Developed a reliable computational model for enterprise design and analysis.
While computational models have evolved into a major discipline in
traditional domains like mechanical engineering practices, it is still infant in
the area of enterprise modeling. Enterprise as a socio-technical system is
complex and versatile which make computational approaches promising and
at the same time difficult and challenging. The difficulty is caused mainly by
informality of the interaction among social individuals while performing their
tasks. Therefore qualitative approaches based on descriptive and artistic
qualities have been dominated in this area. It is expected that PMT provides a
reliable computational model for enterprise analysis, based on sound
organizational theories and comprehensive real world case studies.
(3) Developed a unique client model to address the quantity of requests generated
by clients. With the wide range of real word clients and their operations, the
PMT client model aim at modeling client efficiently and accurately.
198
(4) Developed a unique organization model based on fundamental organizational
science theories. Qualified organization theories have been quantified in PMT
model to build a computational organization model. The model has been
validated by real word case studies and the effectiveness of the model has
been shown.
6.2 Future Direction
The future extensions of this research are as follows:
(1) PMT can be used as a test-bed for validation of engineering collaboration
theories. In engineering collaboration and CSCW (computer supported
cooperation work) research area, there has been a lot of effort to improve
coordination, cooperation and collaboration among engineers. There is a server
need for the developed theories to be tested and analyzed with a reliable
computational model. Researchers have a hard time to answer critical
questions like how much coordination is improved in a team by applying a
specific communication strategy. How organizational structure affects the
communication channels and as a result coordination and collaboration among
engineers? None of the previous researches provide a quantitative analysis of
above issues and a gap exists in current practices to enables enterprises with
quantitative answers to management questions. PMT as a reliable
computational model of enterprise provides quantitative answer for these
199
questions. PMT can provide a reliable test bed for analyzing coordination and
collaboration theories within an organization.
(2) The result of this research is to provide a solid framework to systematically
support enterprise modeling and introduce essential steps towards building a
computer and network based system framework for process execution and
management. Any multi agent frame work can be used to associate each entity
in PMT model with an agent to enable managers for online monitoring and
executing of processes.
200
Bibliography
[1] Adesola S. and Baines T. “Developing and evaluating a methodology for
business process improvement”
[2] Agerfalk PJ, Goldkuhl G, Cronholm S. “Information systems actability
engineering: Integrating analysis of business processesand usability
requirements”. In: 4th International Workshop on the Language Action
Perspective on Communication Modelling, Copenhagen, 12th–13th September,
1999.
[3] Austin JL (1962) “How to do things with words”, Oxford University press.
[4] Barjis, Joseph (2008), “Enterprise, Organization, Modeling, Simulation: Putting
pieces Together”, Proceeding of EOMAS 2008.
[5] Becker, zur Muhlen and Rosemann, E, M. 1999a. “Resource modeling in
workflow applications”. Proc. 1999 Workflow Management Conf. November
9th, Munster, Germany 137–153.
[6] Bernd A. Berg, “Markov Chain Monte Carlo Simulations and Their Statistical
Analysis (With Web-Based Fortran Code)”, World Scientific 2004, ISBN 981-
238-935-0.
[7] Bidarra, R., Kranendonk, N., Noort, A., and Bronsvoort, W. F., 2002, "A
Collaborative Framework for Integrated Part and Assembly Modeling," ASME J.
Comput. Inf. Sci. Eng., 2(4), pp. 256–264.
[8] Cao G, Clarke S, Lehaney B. 2001. “A critique of BPR from a holistic
perspective”. Business Process Management Journal 7(4): 332-339.
[9] Carley, K.M. and Z. Lin (1995), “Organizational Designs Suited to High
Performance Under Stress,” IEEE Transactions on Systems, Man, and
Cybernetics, 25(2), 221–230.
[10] Carroll, T. and R.M. Burton (2000), “Organizations and Complexity: Searching
for the Edge of Chaos,” Computational & Mathematical Organization Theory,
6(4), 319–337.
[11] Chen, L., Song, Z., and Feng, L., 2004, "Internet-enabled Real-time
Collaborative Assembly Modeling via an E-assembly System: Status and
Promise," CAD, 36(9), pp. 835–847.
201
[12] Chiesl, N (1985) “A Monte-Carlo approach to interactive gaming”
Developments in business simulation & experiential exercises 12: 78-81
[13] Childe, S.J, Maull R.S. and Bennett J. “Frameworks for Understanding Business
Process Re-engineering”
[14] Christiansen, T. R (1993), “Modeling Efficiency and Effectiveness of
Coordination in Engineering Design Teams”, PhD. Thesis, Stanford University,
Palo Alto, CA
[15] Cohen, G. P (1992), “The Virtual Design Team: An Information Processing
Model of the Design Team Management”, PhD. Thesis, Stanford University, Palo
Alto, CA
[16] Cohen, M. D., March. J. G & Olsen, J. P. “A garbage can model of
organizational choice”, Administrative Science Quarterly, Vol. 17, No. 1, pp. 1-
25, 1972
[17] Cutkosky, M., Engelmore, R. S., Fikes, R. E., Gruber, T. R., Genesereth, M. R.,
Mark, W. S., Tenenbaum, J. M., & Weber, J. C. (1993). “PACT: An experiment
in integrating concurrent engineering systems”
[18] Cutkosky, M.R and J.M. Tenenbaum, "Toward a Framework for Concurrent
Design,"
Int'l J. Systems Automation: Research and Applications
, Vol. 1,
No. 3, pp. 239-261, 1992.
[19] Davenport, T.H. and Short, J.E., “The New Industrial Engineering: Information
Technology and Business Process Redesign”, Sloane Management Review,
Summer 1990, pp. 11-27.
[20] Davis, S M., and P. R. Lawrence (1977), “Matrix”, Addison-Wesley, Reading,
Massachusetts.
[21] Davis, R., and Smith, R. G. “Negotiation as a Metaphor for Distributed Problem
Solving”, in Artificial Intelligence 20, 1(1983), 63-109.
[22] Duncan, R.B, “Characteristics of organizational environments and perceived
organizational uncertainty”. Administrative Science Quarterly, 17, pp. 313-27
[23] Erman, L.D., Frederick Hayes-Roth, Victor R. Lesser, D. Raj Reddy. “The
Hearsay-II Speech Understanding System: Integrating Knowledge to Resolve
Uncertainty”. ACM Computing Survey 12:213 - 253, June, 1980.
202
[24] Fowler, A. (1998), “Operations management and systemic modeling as
framework for BPR”, International Hournal of Operations and production
Management, Vol. 18 Nos 9/10, pp. 1028-56
[25] Fergusson, K.J “Impact of integration on industrial facility quality”, PhD thesis,
Stanford University, 1993.
[26] Finin, T., Weber, J., Wiederhold, G., Genesereth, M., Fritzson, R., McKay, D.,
McGuire, J., Pelavin, P., Shapiro, S., & Beck, C. (1992). “Specification of the
KQML Agent-Communication Language”. Technical Report EIT TR 92-04,
Enterprise Integration Technologies, Palo Alto, CA.
[27] Fox M.S and M. Gruninger, "Enterprise Modeling," AI Magazine, vol. 19, no. 3,
1998, pp. 109-121.
[28] Fox (1988), “An organizational view of distributed systems”, Distributed
readings in artificial intelligence, Morgan Kaufmann, San Mateo, Ca, 1988
[29] Galbraith, J.R.(1977), Organization Design, Addison-Wesley, Reading,
Massachusetts.
[30] Galbraith, J. (1973) “Designing complex organizations” Reading, Mass,
Addison-Wesley
[31] Galbraith, J. “Organization design, An information processing view”. Harvard
Business Review, May 74, pp. 28-36
[32] Genesereth M.R. and R.E. Fikes, eds "Knowledge Interchange Format, Version
3.0 Reference Manual," Tech. Report Logic-92-1, Computer Science Dept.,
Stanford Univ., Palo Alto, Calif., 1992.
[33] Georgakopoulos, D, M. Homick, A. Sheth, “An overview of workflow
management: from process modeling to workflow automation infrastructure,
Distributed Parallel Databases” 3 (2) (1995) 119–153.
[34] Goldkuhl, G. “Generic business frameworks and action modeling”, Proceedings
of Conference Language/Action Perspective ‘96, Springer, Berlin (1996).
[35] Hammer, M and Champy, J (1993), “Reengineering the Corporation: A
manifesto for business Revolution”, Harper Business, New York.
[36] Hammer, M. and Champy, J. (1993) “A critique of BPR from a holistic
perspective”.
203
[37] Harker, P. T. and Ungar, L. H. 1996. “A Market-Based Approach to Workflow
Automation” , In Proc. NSF Workshop on Workflow and Process Automation in
Information Systems, Athens, GA.
[38] Hickman, L.J., “Technology and Business Process Re-engineering: Identifying
Opportunities for Competitive Advantage”, British Computer Society CASE
Seminar onBusiness Process Engineering, London, 29 June 1993.
[39] Hill, F.M., Collins, L.K. (1998), "The positioning of BPR and TQM in long-
term organisational change strategies", The TQM Magazine, Vol. 10 No.6,
pp.438-46.
[40] http://cougaar.org/
[41] ISO14258 (1999). “International Organization for Standardization. Concepts
and rules for enterprise models. International Standard”. 1999.
[42] Iwasaki Y. and C. Low, "Model Generation and Simulation of Device Behavior
with Continuous and Discrete Changes," Tech. Report KSL-91-69, Knowledge
Systems Laboratory, Stanford University, 1991.
[43] Jin, Y. and R.E. Levitt (1996), “The Virtual Design Team: A Computational
Model of Project Organizations,” Computational and Mathematical
Organizational Theory, 2(3), 171–196.
[44] Jin Y. and S.C.-Y. Lu, “An Agent-Supported Approach to Collaborative
Design”, Annals of the CIRP 47 (1998) (1), pp. 107–110.
[45] Keen P (1991) “Shaping the future. Business design through information
technology”, Harvard Business School Press
[46] Keys, J. B (1987) “Total enterprise business games” Simulations & Games18:
225-241.
[47] Kim, K. Y., Wang, Y., Muogboh, O. S., and Nnaji, B. O., 2004, "Design
Formalism for Collaborative Assembly Design," CAD, 36(9), pp. 849–871.
[48] Li, H. L. and Papalambros, P., "An Interior Linear Programming Algorithm
Using Local And Global Knowledge", ASME Design Engineering Technical
Conference., Boston, MA, 1987, 87-DET-4. Also, ASME Journal of Mechanical
Design, Vol. 110, No. 1, 1988, pp. 58-64.
204
[49] Love, P. E. D., Gunasekaran, A. and Li, H., 1998, “Putting an engine into re-
engineering: toward a process-oriented organization”, International Journal of
Operations & Production Management, 18(9), 937±949.
[50] Lu, S.C-Y. and W. Elmaraghy, G. Schuh and R. Wilhelm. “A Scientific
Foundation of Collaborative Engineering”.CIRP Annals – Manufacturing
Technology Volume 56, Issue 2, 2007, Pages 605-634
[51] Lu Stephen C.-Y., Qingfeng Li, Michael Case. “A sociotechnical framework for
collaborative product development. Journal of computing and information
science in engineering”, 2006, vol 6, 161~169.
[52] March, J. G. (1978). “Bounded rationality, ambiguity, and the engineering
ofchoice”. Bell journal of economics,9,587-608
[53] March, J. G. & Simon, H. A (1958). “Organizations”. New York: John Wiey
[54] Makey P. (Ed.), “Workflow: integrating the enterprise”, Butler Group Report,
Hessle, 1996
[55] Minzberg, H (1972). “The Structuring of Organizations”. Prentice-Hall,
Englewood Cliffs, New Jersey
[56] Nagel, R. N., and Dove, R. 1991. “Twenty-First Century Manufacturing
Enterprise Strategy: An Industry-Led View, Technical report, Iacocca Institute,
Lehigh Univ. Pinto, J., and Reiter, R. 1993. Temporal Reasoning in Logic
Programming: A Case for the Situation Calculus”. In Proceedings of the Tenth
International Conference on Logic Programming, 21–28 June, Budapest,
Hungary.
[57] Nash, John (1950) "Equilibrium points in n-person games" Proceedings of the
National Academy of Sciences 36(1):48-49.
[58] Park, H. and Cutkosky, M.R. "Framework for Modeling Dependencies in
Collaborative Engineering Processes", Research in Engineering Design, vol. 11,
pp. 84-102,1999.
[59] Parson, T (1951). “The social system”. Glencoe, III., Free Press
[60] Robert, C.P. and G. Casella. "Monte Carlo Statistical Methods" (second edition).
New York: Springer-Verlag, 2004, ISBN 0-387-21239-6
[61] Scott, W. R. “Organizations: Rational, Natural and Open System”. Englewood
Cliffs, NJ, Prentice-Hall Inc., 1987
205
[62] Searle J.R. (1979) “Expression and meaning. Studies in the theory of speech
acts”, Cambridge University Press, London.
[63] Serrano, D. “Automatic dimensioning in design for manufacturing”. In J.
Rossignac and J. Turner, editors, Symposium on Solid Modeling Foundations
and CAD/CAM Applications, pages 379{386, Austin, TX, June 5-7 1991. ACM
Press.
[64] Shannon, C. & Weaver, W. “The mathematical theory of communication”.
University of Illinois Press, Urbana, III.
[65] Siegal, W et al. (1996). “Understanding the management of change: an overview
of managers’ perspectives and assumptions in the 1990’s”. Journal of
organizational change management
[66] Simon, Herbert (1957). "A Behavioral Model of Rational Choice", in Models of
Man, Social and Rational: Mathematical Essays on Rational Human Behavior in
a Social Setting. New York: Wiley.
[67] Simon, H.A. (1958) “Administrative behavior”. New York, Macmillan
[68] Simon, H. (1982). “Models of bounded rationality” (2 vols). Cambridge: MIT
Press
[69] Sriram R.D, Simon Szykman, Delcie Durham. “Special Issue on Collaborative
Engineering” J. Comput. Inf. Sci. Eng. -- June 2006 -- Volume 6, Issue 2, 93 (3
pages) DOI:10.1115/1.2201728
[70] Steward, D.V (1981), "The Design Structure System: A Method for Managing
the Design of Complex Systems," IEEE Transaction on Engineering
Managaement, EM-28(3), 71-74.
[71] Strebel, P. “Why do employees resist change?” Harvard business review, 74, 86
- 92.
[72] Taylor, F. (1911) “The principle of scientific management”. New York, Harper
[73] Thavikulwat, P (1989) “Modeling Market Demand in a Demand-Independent
Business Simulation” Simulations & Games 20: 439-458.
[74] Thompson, J. “Organizations in Action: Social Sciences Bases in Administrative
Theory” New York, McGraw-Hill, 1967
206
[75] Thomsen, J., R. E. Levitt, J. C. Kunz, C. I. Nass, and D. B. Fridsma. (1999). “A
Trajectory for Validating Computational Emulation Models of Organizations.”
Journal of Computational & Mathematical Organization Theory. 5, (4), Dec, 385-
401
[76] Vernadat, F.B. (1996). “Enterprise Modeling and Integration: Principles and
Applications”. UK, Chapman & Hall.
[77] Victor E. van Reijswoud, Hans B. F. Mulder* and Jan L. G. Dietz
“Communicative action-based business process and information systems
modelling with DEMO”
[78] Weber, J.C , Brian K. Livezey , James G. McGuire , Richard N. Pelavin,
“Spreadsheet-like design through knowledge-based tool integration”,
International Journal of Expert Systems, v.5 n.1, p.83-103, 1992
[79] Winograd T, Raul Medina-Mora , Rodrigo Flores , Fernando Flores, “The action
workflow approach to workflow management technology”, Proceedings of the
1992 ACM conference on Computer-supported cooperative work, p.281-288,
November 01-04, 1992, Toronto, Ontario, Canada
[80] Wong, S.S. and R.M. Burton (2000), “Virtual Teams: What are their
Characteristics, and Impact on Team Performance?” Computational &
Mathematical Organization Theory, 6(4), 339–360.
[81] Zhao, Li. “ActiveProcess: A Process-Driven Approach to Supporting
Collaborative Engineering Design” PhD Proposal, USC. 2001
Abstract (if available)
Abstract
Enterprise environments are complex and multidisciplinary. As the market competition becomes more and more relentless, many business companies have to keep adapting their current and usual processes to new market needs. Almost everywhere organizations are undergoing rapid and significant changes driven by such pressures as customer expectations, new technologies, and growing global competition. When adaptation is needed, enterprises may or may not have any experience with the new business needs, leading to high level risks associated with theadaptation process. There is a strong demand for a comprehensive framework and methodology which can provide consistent support for practitioners to response the rapidly changing environments for finding and keeping their “best practices”.
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
Building cellular self-organizing system (CSO): a behavior regulation based approach
PDF
A meta-interaction model for designing cellular self-organizing systems
PDF
A biologically inspired DNA-based cellular approach to developing complex adaptive systems
PDF
Behavioral modeling and computational synthesis of self-organizing systems
PDF
Design, modeling and analysis of piezoelectric forceps actuator
PDF
Managing functional coupling sequences to reduce complexity and increase modularity in conceptual design
PDF
Dynamic social structuring in cellular self-organizing systems
PDF
Using organized objectives to structure arguments for collaborative negotiation of group decisions in software design
PDF
Transfer reinforcement learning for autonomous collision avoidance
PDF
Improved size and effort estimation models for software maintenance
PDF
Physics-based and data-driven models for bio-inspired flow sensing and motion planning
PDF
The incremental commitment spiral model process patterns for rapid-fielding projects
PDF
Large-scale path planning and maneuvering with local information for autonomous systems
PDF
Analytical and experimental studies in system identification and modeling for structural control and health monitoring
PDF
Novel soft and micro transducers for biologically-inspired robots
PDF
A social-cognitive approach to modeling design thinking styles
PDF
Mathematical model and numerical analysis of a shape memory polymer composite cantilever beam for space applications
PDF
Reward shaping and social learning in self- organizing systems through multi-agent reinforcement learning
PDF
Modeling the learner's attention and learning goals using Bayesian network
PDF
Evaluating sensing and control in underwater animal behaviors
Asset Metadata
Creator
Yahyaei, Majid
(author)
Core Title
Modeling enterprise operations and organizations for productivity improvement
School
Viterbi School of Engineering
Degree
Doctor of Philosophy
Degree Program
Mechanical Engineering
Publication Date
02/08/2010
Defense Date
12/03/2009
Publisher
University of Southern California
(original),
University of Southern California. Libraries
(digital)
Tag
enterprise,Modeling,OAI-PMH Harvest,organization,process
Language
English
Contributor
Electronically uploaded by the author
(provenance)
Advisor
Jin, Yan (
committee chair
), Chen, Yong (
committee member
), Flashner, Henryk (
committee member
), Kanso, Eva (
committee member
), Shiflett, Geoffrey R. (
committee member
)
Creator Email
majid2140@gmail.com,yahyaei@usc.edu
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-m2840
Unique identifier
UC1157291
Identifier
etd-yahyaei-3421 (filename),usctheses-m40 (legacy collection record id),usctheses-c127-302623 (legacy record id),usctheses-m2840 (legacy record id)
Legacy Identifier
etd-yahyaei-3421.pdf
Dmrecord
302623
Document Type
Dissertation
Rights
Yahyaei, Majid
Type
texts
Source
University of Southern California
(contributing entity),
University of Southern California Dissertations and Theses
(collection)
Repository Name
Libraries, University of Southern California
Repository Location
Los Angeles, California
Repository Email
cisadmin@lib.usc.edu
Tags
enterprise
organization