towards organizational self-awareness - ulisboa · this thesis proposes an approach towards...
TRANSCRIPT
Towards Organizational Self-awareness
A Methodological Approach to Capture and Represent
Individual and Inter-Personal Work Practices
David Miguel Rolo Vicente
Dissertação para Obtenção de Grau de Mestre em
Engenharia Informática e de Computadores
Júri
Presidente: Professor Doutor Pedro Sousa
Orientador: Professor Doutor José Manuel Nunes Salvador Tribolet
Vogais: Professora Doutora Helena Sofia Pinto
Novembro 2007
i
ii
ACKNOWLEDGMENTS
“Behind every successful man is a woman…”, Groucho Marx
Special thanks to Professor José Tribolet for trusting me this work. Without his confidence it was
impossible to reach the maturity stage required to develop a study of this type. His abilities to
teach, discuss, and hold your interests are innumerous and impossible not to admire. More than
gratitude for all his dedication and availability that were crucial to sustain this thesis
development.
Thankfulness to Professor Marielba Zacarias for all assistance provided. Her extraordinary
availability and dedication were key issues that successfully direct this thesis. There is any
possible way to thanks her for all her indispensable advices, persistence, and comprehension.
To Dr. Luis Fialho, director of Moviflor sales department, for giving me the opportunity to
perform one of this thesis case studies in his department. Thanks to all the exceptional central
sales unit people, for their devotion and interest by my work, who were crucial to reach this
study results, and by the superb work environment provided during all time spent in Moviflor‟s
office.
To INATEL for the opportunity to implement the Portal developed during the thesis, supporting
the second case study. Thanks to change management team, and all organization people
involved, for their remarkable contribution to this project. For the friendship, support, and
advices given during INATEL case study, a special gratefulness to Eng. Carla Pereira.
My entire career has been supported by a very special person, my Mother. Considering her as a
reference has been the followed recipe to achieve many of my personal and professional
successes. For all this, tanks mom. Special thanks also to my family, particularly to my brother
and my father.
All this work would have been much more difficult without my friends. They were the ones with
who I relieve and discuss. Between them, I have to do a special gratefulness to a person who I
can‟t live without, my best friend Joana. Her honesty and amazing skills to understand and defy
me have been crucial factors for my ongoing success.
iii
To the most important women of my life, my Mother and Joana
iv
v
ABSTRACT
Nowadays organizations are subject to constant changes. Most of these are imposed by the
need to adequate their way of managing the business to market demands. Examples of these
changes are business processes optimizations or organizational restructures. To plan and
perform them it is necessary to understand organization‟s current state, only by perceiving it
become possible to correctly analyze its needs. A significant part of this knowledge is in every
single person that belongs to organization.
Each person knows what they need to work. Amongst them, documents, tools (including
computer related ones), other people and organizational departments are fundamental to
achieve goals defined for each diary task. Thus, to correctly work people must be aware of their
role in organization, as well as the role performed by others. This awareness is described as
Organizational Self-Awareness and it is studied by Organizational Engineering discipline. The
objective of this engineer field is to provide organization instruments that allow capturing and
representing people‟s knowledge of its parts, in order to synchronize the image that they have
of the whole.
This thesis proposes an approach towards organizational self-awareness through, semi-
automatic and real time, capture and analysis of individual and inter-personal work practices, as
well as their representation using enterprise models easily perceived by organizational people.
Further, these models can also be used to facilitate the investigation of possible optimizations
and consequently manage their implementation.
Keywords: Organizational Engineering, Organizational Self-awareness, Enterprise Modeling,
People, Individual and Inter-Personal Work Practices
vi
vii
RESUMO
Actualmente as organizações estão sujeitas a constantes mudanças. Estas são em grande
parte ditadas pela necessidade de adequarem a forma como gerem o seu negócio às
exigências do mercado. Constituem exemplo destas mudanças as optimizações dos seus
processos de negócio ou as alterações da sua estrutura organizacional. Para planear e realizar
aquelas mudanças é necessário conhecer e compreender o estado actual da organização,
apenas assim se torna possível analisar correctamente as suas necessidades. Parte relevante
deste conhecimento encontra-se em cada uma das suas pessoas que compõem a
organização.
Cada pessoa sabe o que necessita para realizar o seu trabalho. Documentos, ferramentas
(entre elas informáticas), outras pessoas e departamentos da organização são fundamentais
para atingir os objectivos delimitados para cada tarefa realizada diariamente. Deste modo, as
pessoas devem estar conscientes do seu papel na organização, assim como do
desempenhado pelos outros com que se relacionam. Esta consciência é designada como
Consciência Organizacional e é estudada pela Engenharia Organizacional. O objectivo deste
ramo da Engenharia é fornecer à organização instrumentos que permitam capturar e
representar o conhecimento que cada pessoa possui das suas partes, de moda a, sincronizar a
imagem que têm do todo.
Esta dissertação propõe uma abordagem que motiva a Consciência Organizacional, através da
captura e análise, semi-automática e em tempo real, de práticas de trabalho individuais e inter-
pessoais, bem como a sua representação mediante modelos facilmente perceptíveis pelas
pessoas da organização. Estes modelos pretendem igualmente facilitar o estudo de possíveis
optimizações e, posteriormente, gerir a sua implementação.
Palavras-chave: Engenharia Organizacional, Consciência Organizacional, Modelação de
Organizações, Pessoas, Práticas de Trabalho Individuais e Inter-Pessoais
viii
ix
INDEX
ACKNOWLEDGMENTS ............................................................................................................................ II
ABSTRACT ............................................................................................................................................. V
RESUMO ............................................................................................................................................. VII
INDEX....................................................................................................................................................IX
LIST OF TABLES......................................................................................................................................XI
LIST OF FIGURES ...................................................................................................................................XII
ACRONYMS ......................................................................................................................................... XV
INTRODUCING THE STUDY ..................................................................................................................... 1
1 INTRODUCTION ............................................................................................................................... 1
1.1 Research Objectives ............................................................................................................. 3
1.2 Thesis Methodology ............................................................................................................. 3
1.3 Thesis Outline ...................................................................................................................... 4
RELATED WORK IN ORGANIZATIONAL ENGINEERING ............................................................................ 5
2 ORGANIZATIONAL ENGINEERING DEFINITION .......................................................................................... 5
3 ORGANIZATION SELF-AWARENESS ....................................................................................................... 6
3.1 Modeling to Organizational Self-awareness ......................................................................... 6
3.2 A Framework Towards Organizational Self-Awareness ......................................................... 8
3.3 Model Acquisition Approach .............................................................................................. 15
3.4 Conclusion ......................................................................................................................... 19
4 BUSINESS PROCESS MANAGEMENT .................................................................................................... 20
4.1 Brief History Contextualization ........................................................................................... 20
4.2 Business Process Definition ................................................................................................ 21
4.3 Defining Business Process Management............................................................................. 22
4.4 Modeling the Organization ................................................................................................ 24
4.5 Implementing BPM ............................................................................................................ 31
4.6 Conclusion ......................................................................................................................... 34
5 INFORMATION GATHERING TECHNIQUES ............................................................................................. 34
5.1 Interviews .......................................................................................................................... 34
5.2 Ethnography ...................................................................................................................... 36
5.3 Conclusion ......................................................................................................................... 39
x
PROBLEM DECLARATION ..................................................................................................................... 41
6 PROBLEM STATEMENT .................................................................................................................... 41
7 RESEARCH APPROACH ..................................................................................................................... 42
A STEP TOWARDS ORGANIZATIONAL SELF-AWARENESS: CASE STUDIES .............................................. 44
8 OPTIMIZING MOVIFLOR PERSONAL AND INTERPERSONAL TASKS ................................................................ 44
8.1 Defining Objectives ............................................................................................................ 45
8.2 Delineating a Strategy ....................................................................................................... 46
8.3 Instantiating Model Acquisition Approach .......................................................................... 46
8.4 Visualizing and Validating Diagrams .................................................................................. 60
8.5 Providing a Way to Define IS Requirements: Importations Survey ....................................... 61
8.6 The Granularity Dilemma ................................................................................................... 63
8.7 Best Practices .................................................................................................................... 63
8.8 Conclusion ......................................................................................................................... 64
9 SUPPORTING INATEL CHANGE MANAGEMENT ....................................................................................... 66
9.1 Modeling Inatel ‘As Is’........................................................................................................ 67
9.2 Providing a Way to Wonder about ‘To Be’ .......................................................................... 75
9.3 Conclusion ......................................................................................................................... 76
CONCLUSIONS...................................................................................................................................... 78
10 PROPOSING A NEW APPROACH ..................................................................................................... 78
10.1 Relevant Contributions of the Developed Work .................................................................. 79
11 CONCLUSION ............................................................................................................................ 80
12 DISCUSSION AND FUTURE WORK ................................................................................................... 81
REFERENCES ......................................................................................................................................... 82
ANNEX A MOVIFLOR INQUIRIES ........................................................................................................... 85
1 SALES CENTRAL PEOPLE INQUIRER...................................................................................................... 85
2 SALES DIRECTOR INQUIRER ............................................................................................................... 87
2.1 Usefulness of Achieved Results ........................................................................................... 87
2.2 Usage of Context-based Analysis Results ............................................................................ 89
xi
LIST OF TABLES
Table 1. Some Personal Contexts obtained during the case study. (Zacarias, et al. b, 2007) ... 18
Table 2. UML 2.0 versus BPMN 2 process representation. ...................................................... 31
Table 3. Draft organizational sentences registered during observation. .................................... 49
Table 4. Sample of registered actions by Pedro Cabrita for “new order creation” context. ........ 53
Table 5. More complete sample of registered actions by Pedro Cabrita. .................................. 55
xii
LIST OF FIGURES
Figure 1. Thesis Methodology. .................................................................................................. 3
Figure 2. OE Meta-Plane (Tribolet, 2006) .................................................................................. 7
Figure 3. Zacarias, et al., (2007) framework fundamental concepts. ......................................... 10
Figure 4. Agent Basic Role Set. (Zacarias, et al. c, 2007) ........................................................ 11
Figure 5. Agent Architecture. (Zacarias, et al. c, 2007) ............................................................ 11
Figure 6. Relation between Agent Architecture‟s layers. (Zacarias, et al. c, 2007) .................... 12
Figure 7. Model basic architecture and ontology of each layer. (Zacarias, et al. c, 2007) .......... 13
Figure 8. Ontology details for the first two layers. (Zacarias, et al. b, 2007) .............................. 14
Figure 9. Basic architecture and concepts at different levels of detail. (Zacarias, et al. a, 2007)
............................................................................................................................................... 15
Figure 10. The context-based approach proposed. (Zacarias, et al. b, 2007) ........................... 16
Figure 11. The structure of actions. (Zacarias, et al. b, 2007)................................................... 17
Figure 12. Context switches of the agent Mariana during the case study. (Zacarias, et al. b,
2007) ...................................................................................................................................... 18
Figure 13. A context-based interaction network obtained from case study. (Zacarias, et al. b,
2007) ...................................................................................................................................... 19
Figure 14. The DSE proposed view of the enterprise as a system (BPMG, 2005 p. 74). ........... 23
Figure 15. Zachman‟s Framework, “The Framework for Enterprise Architecture” (ZIFA, 2006). 26
Figure 16. CEO architectural views, its components, and the relationships between them
(Sousa, et al., 2007). ............................................................................................................... 28
Figure 17. Relationships between activity, role and entity (Sousa, et al., 2007). ....................... 28
Figure 18. Example of business processes modeled using UML. ............................................. 30
Figure 19. Example of business process modeled using BPMN. .............................................. 30
xiii
Figure 20. Central Repository proposed by Jorge Coelho‟s Methodology. ................................ 33
Figure 21. Relation between OE concepts and the Approach proposed. .................................. 43
Figure 22. Moviflor sales department organizational structure. ................................................. 45
Figure 23. Action form available in the Activity Register Portal developed. ............................... 50
Figure 24. Portal functionality that displayed each person daily actions.................................... 52
Figure 25. Part of Pedro Cabrita “create new order” tasks representation. ............................... 54
Figure 26.Tasks performed by Pedro Cabrita to create a new order......................................... 56
Figure 27. Moviflor records distribution by context. .................................................................. 57
Figure 28. Most registered actions for “order state” subject/context. ......................................... 58
Figure 29. Sales central communications. ............................................................................... 59
Figure 30. Portal diagram validating form. ............................................................................... 60
Figure 31. Tasks performed by importations to manage containers deliver. ............................. 62
Figure 32. Main steps of the applied approach in Moviflor‟s case study. ................................... 64
Figure 33. Moviflor‟s case study approach. .............................................................................. 65
Figure 34. INATEL Portal action web form. .............................................................................. 69
Figure 35. Portal actions check functionality. ........................................................................... 70
Figure 36. Portal activity register developed web form. ............................................................ 72
Figure 37. “Create new excursion” process diagram. ............................................................... 73
Figure 38. INATEL Portal diagram validation functionality. ....................................................... 74
Figure 39. Relation between „as is‟ and „to be‟ process presented in Portal. ............................. 75
Figure 40. Procedure list displayed for each „to-be‟ activity in Portal. ....................................... 76
Figure 41. Brief representation of INATEL approach. ............................................................... 77
Figure 42. Approach proposed by merging Moviflor and Inatel case study results. ................... 79
xiv
xv
ACRONYMS
BPM Business Process Management
BPMN Business Process Modeling Notation
EA Enterprise Architectures
IS Information Systems
OE Organizational Engineering
OSA Organizational Self-Awareness
UML Unified Modeling Language
1
INTRODUCING THE STUDY
“Processes don't work; people do", Peter Fingar
In the previous quote Peter Fingar, considered one of the Business Process Management
gurus, states that are organizational people that makes processes work. This study focus the
capture and representation of personal and interpersonal work practices as important
information that each organization person should be aware of in order to improve their
conscientious about the organization that they work for.
In this section we will introduce the thesis, describe its objectives, explain the methodology
followed, and present an overview of document structure.
1 Introduction
During the last decades many approaches came out proposing ways to improve the efficiency
and effectiveness of organizations (BPMG, 2005 pp. 8-12). Amongst them we distinguish
process reengineering, suggesting the reorganization of enterprise along its workflow, and
Business Process Management (BPM), concerning the alignment between business processes
and organizations goals. Their ambition was similar and process oriented. However, in both
approaches people were left to second plane, as a result problems such as misalignments
between business processes and Information Systems (IS) and resistance to change, just to
name a few, came out leading to unsuccessful results.
It is true that organizations should be managed considering their wider processes, instead of
each department functions, like BPM suggest. However, most of the activities that constitute
their processes are performed by people, which play specific roles in these. Thus, people‟s work
should also be considered as an important issue. In addiction, and consistent with BPM
proposes, people must have a common idea of the organization as a whole, and of their
importance in it, in order to improve their efficiency. After all, when people don‟t understand the
usage of what they are doing, their interest in it decreases and this affects negatively the quality
of their work.
Organizational Engineering (OE) emerged in order to find a solution to solve the previously
stated problems. This discipline aims to reduce the existing gap between soft and hard
sciences, being the soft related to social and management concerns, and the hard regarding the
technical aspects of the organization. As part of OE, the concept of Organization Self-
awareness (OSA) has been proposed (Zacarias, et al. a, 2007). This states that, in the same
2
way people know „who they are’ and „what, and how, are they doing‟, they should be aware of
„who they (and others) are in an organization‟ and „what, and how, they (and the others) are
doing‟.
Answering to the previous questions can influence organization people to become more aware
about their, and others, roles in organization. Enterprise modeling represents an efficient way to
achieve OSA goals (Zacarias, et al., 2007). This is justified by the fact that through models
people can easily understand the organization, promoting their awareness about it. Enterprise
Architectures are examples of these models, however usually they only illustrate organization‟s
processes widely, identifying their activities by department, instead of the roles played by each
person in them.
Every single person has distinct ways of working. This means that, in order to achieve the same
goals, each person can perform different tasks and use dissimilar resources. Thus, it becomes
important to capture and represent personal and interpersonal actions, providing through this a
real and consistent base to wonder about organization‟s actual state, commonly named „as is‟.
Another important concern in nowadays organizations is to have most of the previously
described information in real time. The speed of change imposes a real time way of managing
the business in order to easily react to changes. Thus, new approaches to provide this
information should consider real time as an important requirement while producing it. By real
time, we intend to refer to the right time, which mean the specific moment when the information
is needed by the organization e.g. to do management decisions.
In this study we propose an approach to capture, analyze, and represent personal actions using
concepts such as contexts, enterprise ontology, business processes, enterprise modeling, and
real time business. In addition, we also consider the representation of enterprise future state,
usually described as „to be‟, as an important information to avoid common change problems,
such as misalignment between processes and business (e.g. incomplete functionalities in new
ERPs), and resistance to change played by organization people directly affected by the
alterations. The approach suggested and discussed was developed during two case studies
performed in distinct organizations, in different situations.
The first case study occurred in the sales department of a furniture retail company, Moviflor,
with the aim of optimize employees work practices through their standardization. In order to
reach this, every single person registered most of their diary actions using a web form
developed to this propose. Each of the form fields, and its contents, were initially defined during
a bootstrapping phase where every person was involved and contributed. Once registers were
analyzed, personal tasks diagrams were created and presented to each person using a web
portal, where she was asked to validate if they correspond to the reality. This case study
3
reached successful results, justified by the fact that, once finished, sales department people
conducted, by their own, a reengineering of their work practices.
The second case study was done on a social services provider, INATEL, that was performing a
drastic organizational restructure and an IS renewal. The developed work focused the
presentation of organization business processes diagrams using a web portal, similar to the one
created in Moviflor case study, and their further validation by every person involved in them. In
addiction was also included the possibility to visualize the „to be‟ state of each „as is‟ diagram.
By involving every single person in the organizational change, capturing and representing their
roles in each business process, this case study have resulted in the successful development of
organizational self awareness of INATEL employees.
1.1 Research Objectives
As the title of this thesis suggests, providing a way to enhance the accomplishment of OSA
goals is our main objective. However, in order to reach it, this was divided into the following
ones: (1) find a way to capture personal and interpersonal work practices in real time; (2)
represent each person work practices in a way that most of the people easily can understand
them; and (3) using the previous models, suggest a way to support organizational changes in
order to reduce the common difficulties associated with them, which means preparing the „to
be‟.
1.2 Thesis Methodology
The methodology defined for this thesis is based on four main steps: (1) define study goals; (2)
research related work; (3) plan and execute case studies; and (4) achieve an discuss
conclusions considering the achieved results (Figure 1). Each step is further described.
Figure 1. Thesis Methodology.
Goals were initially defined, however while researching some issues have been identified and
added to primary objectives. The reason for this change is that, before starting the research, our
initial knowledge about the state of the art was insufficient to correctly define precisely every
specific need.
Define
Goals
Research
of Related
Work
Plan and
Execute
Case
Studies
Conclude
about
Thesis
Results
4
The research of related work was done using subjects related to OE discipline, our research
context. Initially only BPM was considered, however in order to find a way to capture personal
and interpersonal work practices other important references have been studied. These were
enterprise ontology, context-based approaches, and information gathering techniques, which
have proved to be indispensable instruments to achieving our goals.
While executing case studies, most of the previously researched concepts and approaches
have been applied. Still, a constant need to go back to research stage was required. The last
step was performed along the execution of case studies. It was during them that most of the
conclusions have been achieved and described. However, when analyzing the results,
conclusions attained iteratively influenced the work that was being done.
1.3 Thesis Outline
The relevant value-added features of this thesis are the activities and results achieved during
case studies. Thus, this document structure follows each of these along their execution. It is
divided in five main parts, each separated in a set of related sections.
1. Introduction. In this part we introduce the study, describe its goals, the methodology,
and outline document structure.
2. Related Work in Organizational Engineering. This part states OE references used
during this thesis. It is composed by: (1) definition of OE, describing its goals; (2)
explanation of OSA related work, where a recent proposed framework and an approach
to apply it based on enterprise ontology and contexts are described; (3) state of BPM
art, providing a brief contextualization in this subject, including enterprise modeling and
methodologies proposed to implement BPM; and (4) analysis of some Information
Gathering Techniques, interviews and observations, these last ones based on
ethnography.
3. Problem Declaration. Here we summarize the major contributions of related work and
identify relationships and gaps between them. This is done in order to specify our
problem, and to explain the approach followed to solve it.
4. A Step Towards Organizational Self-awareness. In this part we describe each case
study. The first was performed in Moviflor, a furniture retail company, and the second in
INATEL, a social services provider.
5. Conclusions. The last part is where the new approach is proposed, and where
conclusions and issues are described.
6. Annex A – Moviflor Inquiries. In this annex we present Moviflor inquiries, used to
obtain people‟s opinion about the work developed during Moviflor case study. There are
two distinct inquiries, one answered by Moviflor sales central team, and the other filled
by sales department director.
5
RELATED WORK IN
ORGANIZATIONAL
ENGINEERING
"You can engineer the enterprise just like you can engineer anything else", John Zachman
Despite the fact that Organizational Engineering is a recent discipline, whose major growth
occurred during the last decade, there are many important references that can‟t be despaired.
This section describes the related work in Organizational Engineering used to perform this
study, focusing concepts such as organizational self-awareness, business process
management and enterprise modeling, emphasizing a context-based approach based on recent
researches. In addition to these, a brief description of information collection techniques is done.
2 Organizational Engineering Definition
Organizations are facing increasing complexity as result of the speed of change and growth of
effective and aggressive competition (Eriksson, et al., 2000). Methods and tools, to align
business processes with organization‟s strategic goals represent a new form of knowledge,
which is a needed instrument to manage these changes and improve real-time management
abilities. This knowledge is structured in the Organizational Engineering (OE) discipline, also
known as Enterprise Engineer.
Regarding organizations as complex entities that deal with contrasting concepts such as
people, value chains, business processes, information systems and technology (Sousa, et al.,
2007), OE aims to enhance the alignment between these notions in order to (1) achieve better
understanding of the enterprise, (2) grant more flexibility in organizational design, (3) provide a
solid foundation for reorganizing the business, and (4) support information systems‟
development.
People‟s knowledge about the organization and how it influences their behavior has been
concern of recent studies (Zacarias, et al. a, 2007). These focus the importance of people‟s
organizational awareness and how it can be used to optimize individual and inter-personal work
practices. As a result, the concept of organizational self-awareness (OSA) has been proposed.
6
Implementing it represents an essential pre-requisite for organizational effective action, decision
making and learning processes (Zacarias, et al. a, 2007).
3 Organization Self-Awareness
Human beings are by nature, self-awareness beings. This capacity lets us know who we are,
how we do things and what are we (and others) doing at any particular moment (Zacarias, et al.
a, 2007). Whereas this ability is innate in individuals, OSA must be built and maintained by
continuous interactions among members in order to apply it to all organization.
The reason why people‟s knowledge is the basic concern of this concept is justified by the fact
that they are the only ones capable of sense making in the organization (Zacarias, et al. b,
2007). Sense making is defined as structuring unknown contexts and/or actions and assigning
them with meaning. It is distinguished from other explanatory processes such as understanding
or interpreting by the following characteristics: the process of sense making is social, grounded
in identity construction, retrospective, focused on extracted cues, ongoing, driven by plausibility
rather than accuracy and enactive (Zacarias, et al. b, 2007). Therefore, we can describe sense
making as the consciousness that people develop of the organization as a whole and of their
place in it (Zacarias, et al. b, 2007).
The concept of OSA is characterized in two dimensions, the individual and the organizational
one. The individual dimension refers to the capacity that individual members have answering
the questions such as; who am I in this organization?, how are things done here?, what is the
organization - as a whole - doing now?. The organizational dimension refers to the combination
of human or automated agents, resources and procedures that provides organizations with the
necessary intelligence for dealing with questions such as; who are my members?, how do they
do things?, what are they doing now? (Zacarias, et al. a, 2007). An organization is self-aware
when these two dimensions are aligned.
3.1 Modeling to Organizational Self-awareness
In order to apply OSA, enterprise models are suggested (Zacarias, et al. c, 2007). Models
represent an important tool to describe the enterprise from different points of view, such as
functional, process, data, and economic (Sousa, et al., 2007). Amongst the several definitions to
describe a model, we have considered “model as a theoretical construct that represents
physical, biological or social processes, with a set of variables and a set of logical and
quantitative relationships between them” (Sousa, et al., 2007).
Enterprise modeling has been studied by Information Systems (IS) and Artificial Intelligence (AI)
fields. These models are commonly referred as Enterprise Architectures (EA) or Enterprise
7
Ontologies, respectively. They are described using more formal syntax and semantics, enabling
its processing by automated agents and reducing inconsistent interpretations (Zacarias, et al. c,
2007). EA and enterprise modeling languages are analyzed further (section 4).
As a result of recent research (Tribolet, 2006) a new meta-plane representation was defined
with the aim to clarify the relationship between OSA and enterprise models (Figure 2). This
meta-plan is represented by an agent that (1) creates and develops a model of the world, (2)
influences this world, and by other side, (3) its decisions are influenced by the world. Through
this emerge the concept of OSA as a continuous process of construction, maintenance and
change of shared images about: (i) the way the organization and its agents act between them,
(ii) the organization and agent role played in each instant, and (iii) how to control and remodel
the organization in real-time.
Figure 2. OE Meta-Plane (Tribolet, 2006)
OSA can also be related with the concept of mental models. Proposed as one of the five
disciplines described by the learning organization1 concept, mental models are assumptions,
generalizations, or even images that influence how people understand the world and react in
them.
1 The learning organization emerged during the 1980s based on a Donald Schon‟s idea that describes an organization that learns as its workers improve their knowledge, aiming to survive to the speed of change and competitive markets. This concept have been target of recent studies and become more popular with the book “The fifth discipline” (Senge, 1990).
8
Enterprise models represent an essential communication tool in supporting and enhancing
OSA. These are illustrated in the models‟ “circle”, highlighted in Figure 2, and are useful to
provide ways of thinking about the organization in order to support management principles.
Effective supports to OSA require generic models of agents‟ activities, resources, and their
relationships, but it is not enough. There is a need to know how specific agents accomplish their
work and what they are doing at particular moments, and to provide ways of evaluating how
work practices change in time. More specifically, it is necessary to answer to the following
questions (Zacarias, et al. a, 2007):
Which roles plays agent X?
How does agent X perform activity Y? Which rules follows?
Which agents interact more frequently?
How does agent X interact with agent Y? Which interaction rules govern group G?
At a particular time interval t:
o What role plays agent X? Which activity(ies) performs? Which resources use?
o With which agents interacts?
o Which event(s) trigger agent X's role?
o Which rules govern how agent X manages his different roles, activities and
resources?
In order to answer to the previous quoted questions, and to provide a way to represent,
communicate and discuss organizational conditions through appropriate enterprise models,
Zacarias et al. b (2007) propose a framework composed by an agent architecture and ontology.
3.2 A Framework Towards Organizational Self-Awareness
OSA should be considered simultaneously as an individual and collective phenomenons that
must be supported by a continuous communication among organizational agents. In order to
develop it, organizations need to improve capabilities of continuous sensing, learning and
adjusting to the dynamics of their environment.
Zacarias, et al. a (2007) suggest an architecture and ontology, departing from an ontological
position where organizations are regarded as complex and adaptive socio-technical systems.
The challenge is to model the organization for its self-awareness, using as background
organizational and IS field‟s approaches, in order to capture: (1) organizational structural and
dynamic aspects, (2) routines and decision-making processes, and (3) its formal and informal
sides. Furthermore, another important concern is to consider organization development, and
consequently motivate the continuous reverse engineering of the organization. (Zacarias, et al.
a, 2007)
9
3.2.1 Fundamental Concepts
The framework proposed is based on some fundamental concepts of the CEO framework
(Sousa, et al., 2007). This is further described in section 4.4.1.2, even though a brief
introduction is provided subsequently. CEO framework distinguishes three main concepts that
mostly contributed to the approach proposed, these are: (1) activities, (2) entities, and (3) roles.
Entities can be classified in two different kinds: resources and agents.
Activities describe what organizations do, and are identified with verbs (e.g. buy, create, and
hire). Entities (resources) are the things relevant for organization operations and are identified
with nouns. In this framework, entities are synonym of organizational resources. Resources can
be persons, machines, places, concepts or capabilities. They may be physical or abstract,
inanimate or animate, technical or social (e.g. furniture, order, employee, and programming
skill). (Zacarias, et al. a, 2007)
Joining organizational verbs (activities) and nouns (resources) form organizational predicates
(e.g. buy furniture, create tour, and hire employee). Organizational predicates provide a more
complete specification of what the organization does (Zacarias, et al. b, 2007).
Another important concept is the notion of Agents. They are regarded as physical and animate
resources with special capabilities that enable them to: (1) perform, coordinate and change
activities; (2) provide, consume, manage and change resources; and (3) monitor, coordinate
and change their own activity and the activity of their agents. The agents can be characterized
as human (persons, dyads, groups and whole organization), automated or semi-automated.
Automated and semi-automated agents are machines or human-machine combinations
(Zacarias, et al. c, 2007).
Agents are autonomous, interactive, adaptive, proactive, rational, unpredictable (capable of
non-deterministic behavior) and coordinative (agent are capable of coordinating themselves, as
well as other agents). In this ontology, agents are identified with nouns (e.g. Sales Department,
Susana, and Sales Manager) and they are the subject of organizational predicates. Agents
possess a set of capabilities, enabled by skills (know-how) or knowledge (know-what).
Linking agents (nouns), activities (verbs) and resources (nouns) we form organizational
sentences, i.e. we define what the organization does and who does it (e.g. Sales Department
buys furniture, Susana creates an order, and Sales Manager hires Susana).
Considering agents as a special kind of resources lead into the agent-resource duality. Entities,
such as the agents described before (i.e. Prof Sales Department, Susana, and Sales Manager),
may be also operate as resources. In this case, they are not the subject of the sentence.
10
Rather, they are part of the predicate. For example, in the sentence “Sales Manager hire
Susana”, the agent is the Sales Manager and Susana represents a passive resource.
Role defines the observable behavior of an entity in the scope of particular interaction contexts.
Agents play several roles and interact with other agents through these roles. (Zacarias, et al. c,
2007)
The definition of context remains dependent on its application area (Zacarias, et al. c, 2007). In
Engineering, and particularly in AI, context is viewed as a collection of things (sentences,
propositions, assumptions, properties, procedures, rules, facts, concepts, constraints, etc)
associated to some specific situation (environment, domain, task, agents, interactions,
conversations, etc). Analyzed in the Cognitive Sciences filed, context represents the set of all
entities that influence human (or system's) behavior on a particular situation. Although,
departing from Social Approaches, context is regarded as networks of interacting entities
(people, actors/agents and artifacts).
The considered definition in this approach defines contexts as a network of interacting agents
playing specific activities and resources. It also reflects the state of participating agents, their
interactions, and the set of rules governing these interactions.
Figure 3 illustrates the fundamental concepts of the framework and the existing
interrelationships between them. The agent plays specific roles in specific contexts. These roles
are related to some activity or resource.
Figure 3. Zacarias, et al., (2007) framework fundamental concepts.
Considering the relationship between the fundamental concepts, organizational agents can be
described by the set of roles played when related to the other concepts. The agent, by itself,
can be characterized by its ability to learn, self-coordinate and act. When related to resources,
the agent is capable to produce/consume, manage and assume a (re)design role. The capacity
11
to perform, coordinate and also (re)design activities characterizes the role played by the agent
when related to the activity concept. These relations are depicted in Figure 4.
Figure 4. Agent Basic Role Set. (Zacarias, et al. c, 2007)
3.2.2 Agent Architecture
The agent architecture proposed is based on three interdependent layers; (1) action, (2)
decision making and (3) change/learn (Figure 5). Each one of these layers describes different
faculties that the agent performs.
Figure 5. Agent Architecture. (Zacarias, et al. c, 2007)
The Action Layer aims to capture agent interaction strategies. These strategies are considered
as behavior patterns describing the guided way an agent react according to different situations.
As an example, when a person sees a cup falling, he will try to hold it because she is used to do
it.
12
The measurement of agent reflection, when facing unknown situations, is concern of the
Decision-making layer. Providing an agent dynamic representation, based on the events that
trigger state changes, this layer captures rules that define the utilization of specific interaction
strategies. These are agent activation strategies. Continuing the previous example, the reason
why the person will try to hold the cup, it‟s because once in the past she saw it falling and
braked up. In that time a bad performance measure was associated to that action.
Focusing the agent reflexive behavior, the change/learn layer aims to process the way
interaction and activation strategies change trough the time. This practice is based on strategies
performance measures defined in the previous layer. Learning only occurs when new or
redesigned strategies improve the performance of previous ones. Finishing the example stated
above, after the cup broken the person learned that letting it fall was wrong and learn to don‟t
repeat the same action again.
The relation between the three layers is illustrated in Figure 6. When acting, agents decide what
to do according to activation strategies given by its deliberation capabilities, and interaction
strategies defined by his reflexive and learning capabilities. The change of agents‟ strategies
occurs when they analyze their performance. This analysis is mainly based on subjective and
tacit performance measures, although they could be inferred through propagation, reduction
and elimination of strategies (Zacarias, et al. c, 2007).
Figure 6. Relation between Agent Architecture‟s layers. (Zacarias, et al. c, 2007)
3.2.3 Model Basic Architecture and Ontology
Organizations can be modeled as a network of interactions between autonomous resource and
activity-related agents (Zacarias, et al. c, 2007). Resource and activity-related agents, as well
13
as the interactions between them, are modeled on the basis of the agent three-layered
architecture depicted in Figure 7.
Figure 7. Model basic architecture and ontology of each layer. (Zacarias, et al. c, 2007)
The relation between agent roles and the agent architecture layers depicted in the figure above
states that in the action layer agent provide and/or consume resources and interacts according
to different contexts, while performing its activities. In terms of OSA, the action layer
representations describe how the organizations and its agents do things. (Zacarias, et al. c,
2007)
In the decision making layer the agent acts as a resource manager and activity coordinator.
These activities are performed when activation strategies, previously described also as rules,
are invoked in a particular context. This layer captures processes such as planning or
scheduling, triggered by activation rules that may cause agents to decide the activation of a
different context.
After performing the roles described in the previous layers, agent realizes change/learn roles.
Therefore he selects activities and resources according to the performance measures
previously defined for the interaction and activation strategies. Thus, the change/learn layer
aims to capture the re(design) of these strategies. The modeling of this layer has not been
address yet, currently the authors‟ concern is in the detection of changes in the previous layers.
Figure 8 depicts the ontology resulting for the two first layers, action and decision-making,
illustrating the difference between the agent strategy employed and how that influences its
14
relation with other concepts. Mediating artifacts are defined as resources that support and
constrain agent interactions. (Zacarias, et al. c, 2007)
Figure 8. Ontology details for the first two layers. (Zacarias, et al. b, 2007)
3.2.4 Applying the Framework in Different Organizational Levels
Human agents are typically studied at individual, inter-personal, group and organizational levels.
However, when considering business processes approaches they are typically related to
organizations or organizational units. As consequence, the concept of activity is related to
groups and the concept of task is associated with individual or interpersonal levels.
15
Figure 9. Basic architecture and concepts at different levels of detail. (Zacarias, et al. a, 2007)
Even considering different levels, the previously described ontology can be applied. The main
difference on the usage in each level remains on the universe of discourse i.e. a different set of
nouns, verbs, attributes, state variables and rules (Zacarias, et al. a, 2007). Verbs and nouns
used in different processes, resources and their corresponding contexts (e.g. order furniture)
are different for those defining activities (e.g. develop orders‟ application) or tasks (e.g.
elaborate order report).
Interactions at all levels are mediated by contexts that differ from layer to layer i.e. commitments
within personal action contexts obligations refer to to-do lists; in inter-personal contexts, they
mean inter-personal commitments; in group-level contexts, they signify formal or informal
agreements; finally, in organization-level contexts, commitments refer to inter-organizational
contracts. (Zacarias, et al. a, 2007)
3.3 Model Acquisition Approach
The application of the previous described conceptual framework (Architecture and Ontology of
Organizational Agents) is sustained by the Model Acquisition Approach, recently proposed by
Zacarias, et al. b (2007). This approach has already been applied in two documented case
studies (Zacarias, et al. b, 2007).
Classified as bottom-up and context-based approach, it is based on three main steps: (1) collect
action of a group of subjects, (2) identify and analyze action-layer behavior i.e. predominant
actions and resources of personal and inter-personal contexts, and (3) infer decision making
layer behavior i.e. find personal and inter-personal context activation patterns.
16
The approach is composed by five different types of activities, which are: (1) bootstrapping, (2)
action capture, (3) context discovery, (4) context analysis and (5) context integration. In addition
to these steps, the acknowledgment of the change/learn layer behavior is given by a cyclical or
continuous usage of this approach. As illustrated in Figure 10, there isn‟t any specific order
recommended to perform most of the activities involved.
Figure 10. The context-based approach proposed. (Zacarias, et al. b, 2007)
3.3.1 Bootstrapping
Started with an observation period, whose result is the definition of the different action and
resource types for each agent, this phase produces a set of actions and resources. This set is
discussed further, requiring activities such as the presentation of the set obtained to subjects,
followed by its validation. The subjects referred are agents that can be individuals or teams.
The action set is composed by verbs such as inform, read, calculate, refresh, change, and
create. Resource repository includes information items such as documents and notebooks, and
also refers to software/hardware components used to perform each action, e.g. calculator,
Microsoft Excel, SAP R/3.
At the end of this phase, the normalization of the action and resource set are done. This is a
needed step in order to support their migration into a database and facilitate future analysis.
Bootstrapping can be described bootstrapping in three main steps: (1) define the action and
resource set for each agent; (2) discuss and validate the set proposed with the subjects
involved; and (3) analyze the set of actions and resources, normalizing the items list.
3.3.2 Capturing and Structuring Actions
Traditional modeling approaches describe tasks, activities or processes with predicates
composed by a verb followed by an object (Zacarias, et al. b, 2007), e.g. create request, print
17
invoice, solve claim. These approaches belong to BPM and are further detailed (section 4.4).
The main issue of these descriptions is the lack of subject, not including the agent.
The Model Acquisition Approach captures actions using the structure of organizational
sentences previously described (section 3.2.1). These sentences are composed by triples
subject-verb-object, where subject identifies the agent, the verb identifies the action type, and
the object identifies the resources used or produced while performing the action (Zacarias, et al.
b, 2007) e.g. Susana create order in SAP R/3 M21 menu. The structure of the actions captured
is depicted in Figure 11.
Figure 11. The structure of actions. (Zacarias, et al. b, 2007)
Each sentence is registered considering it chronological order and using the action and
resource items normalized during bootstrapping. This allows the creation of an agent action
structured and ordered repository. However, communicative actions can further be structured
using speech theory, meaning that actions can be written using a subject-verb-action form
(Zacarias, et al. b, 2007) e.g. Maria request (Susana create order in SAP R/3 M21 menu).
3.3.3 Context Identification and Display
Once analyzed the different actions and resource types registered for each agent, it is possible
to group them according to their contexts. However, constructing this sets require some
knowledge about the organization analyzed. Otherwise the contexts‟ set won‟t make any sense.
After creating the groups, they are presented to subjects that validate (and may regroup) them.
It‟s also subjects‟ responsibility to label each group according to their knowledge about the
actions contemplated. An example of this phase results is illustrated in Table 1. Some Personal
Contexts obtained during the case study. (Zacarias, et al. b, 2007)Table 1.
18
Table 1. Some Personal Contexts obtained during the case study. (Zacarias, et al. b, 2007)
3.3.4 Context-based Analysis
Identifying, characterizing and labeling contexts permit their usage as unit of analysis. The
identification of personal contexts allows a variety of context-based depictions (Zacarias, et al.
b, 2007).
Contexts are considered as networks of interacting agents playing related specific activities and
resources. Thus, analyzing the repository created with the set of agent‟s actions and resources,
labeled as contexts, allows discovering of information such as context switches (Figure 12) or
the number of actions for each context.
Figure 12. Context switches of the agent Mariana during the case study. (Zacarias, et al. b, 2007)
3.3.5 Context Integration
This phase is characterized by the production of models that facilitate the comprehension of
agents‟ tasks. The context integration is a human process whose result can be used as a tool to
actualize existing enterprise models.
19
One of the main problems of current modeling approaches (section 4.4) is the constant need for
its updating. Models that result from the context integration facilitate the construction of task
models and assist updating other existing enterprise representations, such as the ones further
described (section 4.4). Figure 13 illustrates a context-based interaction network obtained from
the analysis of a context repository.
Figure 13. A context-based interaction network obtained from case study. (Zacarias, et al. b, 2007)
3.4 Conclusion
Despite the fact that OSA is a recent area of OE, its importance demands an urgent concern
and appliance by organizations. This could be a possible way to follow in order to facilitate
organizations reaction to the constantly changing of the market. Once every single person in
organization is aware about his work, and how that influences the whole company, processes
will become more flexible and will easily adapt to changes.
However, the model acquisition approach proposed requires human intervention in most part of
the activities, making hard the achievement of real time concerns. Thus, its appliance becomes
expensive in a personal and temporal way. This represents one of the goals defined for this
study.
Enterprise ontology is an important concept described in this section, providing a way to
describe it using a common language. It will be using this ontology that we will further define a
manner to capture personal and interpersonal actions.
Justified by the fact that it is out of this study scope, there isn‟t any section dedicated to the
research advances in the automated context discovery field. Though, there are already some
studies with successful results (Zacarias, et al. b, 2007).
20
4 Business Process Management
During the last decade some approaches came out to facilitate the accomplishment of OE
goals. An important one is Business Process Management (BPM) including methods,
techniques and tools to support the design, enactment, management, and analysis of business
processes (Fingar, et al., 2003 pp. 73-97). This concepts and manners focus mainly
organization‟s business process, considering the organization as a whole and proposing the
definition of enterprise wide processes.
4.1 Brief History Contextualization
Since the eighties, process reengineering changed the way organizations manage their
processes. Connected with it, emerged the concept of Business Process Re-engineering (BPR),
defined as the re-organization of an enterprise along the flow of work, generating value sought
by the costumer (Frost, et al., 1996). Its focus are the analysis of business process
requirements, with a little transformation or rework as possible, and the description of business
process modeling techniques, which give a basis for assembling business solutions. Industrial
organizations used this method to improve their business processes‟ performance, but these
efforts were unsuccessful, failing to spot agility concerns in order to support the ongoing
change. Nowadays, reengineer is associated with drastic short term changes in processes, not
concerned with the way people react to it. This non collaborative reengineer can justify its
previous failure in many organizations.
In the last decade, Enterprise Resource Planning (ERP) systems were developed and adopted
by many organizations. Their intent was to provide everything that an organization needed to
manage its business, including the complete support of its business process. The problem was
that these systems were inflexible and most of the time obligated the change of organization‟s
business process in order to adapt to them, when what was expected, and needed, was the
reverse. The concept and usage of workflows also emerged during this decade. Their main goal
to represent all the business processes was very ambitious and important to the development of
a process-centric way of manage. One of the main issues here were the gap between what the
languages provided and what were needed to represent organizational requirements.
Recently successful efforts are being made in order to align processes with organization goals.
Process mapping tools capture and manage enterprise processes in an editable form, for more
flexible manipulation and subsequent analysis. However, these tools can't carry process models
to executions, being this one of the main ambitions proposed by the BPM.
21
4.2 Business Process Definition
In order to realize the ideas suggested by BPM, the concept of business process should be
clearly described. Business process can be defined based on several definitions, some of them
are:
Series of inter-related activities that cross functional boundaries with individual inputs
and outputs (Llewellyn, et al., 1999);
Groups of activities performed in response to a set of related business events (Frost, et
al., 1996);
A collection of activities that takes one or more kinds of inputs and creates an output
that is of value to the costumer (Hammer, et al., 2001);
The manner in which work is organized, coordinated, and focused to produce a
valuable product or service (Laudon, et al., 2006);
A collection of applications, workflows and associated IT resources that are required to
perform a set of related tasks that are major importance to a business (Associates,
2000).
The value added to customer and the help provided in order to accomplish organization‟s
business goals are common issues in these definitions. Merging both definitions, we can define
a business process as a coordinated set of activities that add value to the costumer and support
achievement of organization business goals (Sousa, et al., 2007).
Business processes importance to the organization is justified by the fact that they literally
define it, representing its critical source of competitive advantage and market differentiation
(Fingar, et al., 2003 p. 71). BPM suggests methodologies and frameworks with the aim of
helping organizations to improve the way they deal with their business processes. Examples of
these goals are the real time management capability and the alignment between organization‟s
business units.
By analyzing the concepts directly related with business process, it‟s easy to achieve a very
relevant one, the notion of business rule. To avoid misunderstandings, it‟s important to
distinguish business rules from business process: “business rules are the know and business
processes are the flow” (BPMG, 2005 p. 98). Every organized business process has its
business rules. In a practical approach, a business rule is what guides the business in running
its day-to-day operations, in order to achieve the right balance between business processes and
business goals.
Here, the concept of entity is also important. An entity is a stakeholder that plays a role in an
activity, according to several rules. This role is the observable behavior of an entity in the scope
22
of a specific collaboration context. It aims to separate the different concept that arises from the
collaborations between the entities fulfilling an activity.
Summarizing, and always considering that we are describing the business process in a wide
perspective, it‟s possible to define a business process as a set of activities, where one or more
entities plays a role (Sousa, et al., 2007), according to several rules, in order to reach business
goals.
4.3 Defining Business Process Management
BPM paradigm aims to provide the ability to use the information gathered through advanced
management techniques. This concept proposes a model to predict the impact of IT changes on
business, and by other hand, the impact of business process changes on IT environment.
Through this, BPM can be defined as a synthesis of process representation and collaboration
technologies that removes the obstacles blocking the execution of management intentions. This
concept emerged from the convergence of management theory - total quality management, Six
Sigma, business engineering and general systems thinking - with modern technologies -
application development, systems integration, computation, service-oriented architecture,
workflow, transaction management, XML and Web services (Fingar, et al., 2003 p. 71).
Briefly, it can be said that BPM strategically aims to:
Represent and align supply chain processes, project planning processes, learning
processes and product-data management processes, and manage all alike, in real-time;
Support the answer to „what if‟ questions and allows specification of the new „to-be‟
processes;
Reorients Information's Technology (IT) activities to the trajectory of the business
process, preventing the overtime projects and decrease its rate of failure.
A suggested approach to represent BPM value is the Dynamically-Stable Enterprise (DSE) from
Vasile Bucioman-Coman and Adrian Sahlean (BPMG, 2005 pp. 52-78). The DSE is a unifying
enterprise model that integrates all the enterprise elements, from the simple to the highly
sophisticated. In this model, the enterprise is seen as an abstract entity, composed by business
entities (knowledge, product2 and costumer), business processes (operations and process
management), value chain (product and information flows), decision-chain (drives change), and
2 It‟s important to refer that the product described as a business entity can be also seen as a service. The reason for this designation results from the fact that this view is based on Porter‟s value chain, which considers product development as organization‟s main interest.
23
the technology that enables processes to be effective and flexible. This value chain is driven by
the business plan model, the available resources and the technology lifecycle.
As its name suggests, the change is an important feature in DSE. In order to deal with it,
flexibility and efficiency are considered its main drivers. The flexibility challenge is to engineer
the enterprise for change. The efficiency is used as economic progress‟ main indicator. The
more stable an enterprise is, the more efficient are its operations, but the more difficult is to deal
with change. This, justify the needed alignment between these drivers, easily achieved through
BPM principles.
In order to correctly represent the importance of change and the value of BPM in the
organization, it‟s suggested to represent the enterprise as a system. This system is divided in
two dimensions, dynamic and static, revolved around three main business entities: knowledge,
product and costumer (Figure 14). The dynamic dimension is given by the behavior of the
enterprise processes, covering mainly the transformations of knowledge into product, and of
product into costumer value. The static dimension is given by the structure of processes,
including the static processes of knowledge lifecycle, product lifecycle and costumer lifecycle.
Figure 14. The DSE proposed view of the enterprise as a system (BPMG, 2005 p. 74).
Considering aspects like organizational knowledge, as a result of operations, and time, through
a cyclic representation, the DSE proposed view it‟s directly related to the concept of OSA
previously described (section 3). However, in opposite to OSA framework (section 3.2), in this
view is given more emphasis to end-to-end organizational business process instead of people
roles while performing them.
24
To put BPM into practice two main steps should be taken: process-centered organizational
design and process-centric business information systems. Thus, the design of organizational
processes can only be reached through modeling techniques. The models resulting from this
exercise are used as a pre-requisite to implement the information systems.
4.4 Modeling the Organization
Models are the basic requirement to develop the important BPM process of modeling. It refers
to the process of generating a model as a conceptual representation of some phenomenon.
Enterprise Modeling applies the previous concepts to take an enterprise-wide view of an
organization, which can be used as a basis for taking decisions. In order to achieve, use, and
maintain such view, integration, communication, flexibility and support are required (Uschold, et
al., 1998). There are two categories to classify the enterprise modeling actions (Breton, et al.,
2000): descriptive modeling, as the pure act of modeling organizational behavior, and active
modeling, as the act of constructing executable systems, business process systems (BPS), from
these models. However, descriptive modeling is always a prerequisite to active modeling. BPM
focus both, with special emphasis on the last one as it is the future of it.
In the context of the DSE concept mentioned before, enterprise can be viewed as a system
where the IS are part of it. To deal with organization‟s complexity, modeling practices suggest
the simplification of the reality. This means that, as prerequisite, some information will have to
be dismissed. To deal with this loss, the correct level of abstraction should be chosen, and to do
it correctly, meta-planes, and meta-models, are becoming a common practice in OE. These new
modeling practices also emerged in order to fix the previous known disappointment of modeling
in organizations. The failures can be summarized in a Gartner Group research (1997) that
identified "Nine Reasons Why IS Organizations Do Not DO BPM3":
Business units will not make the effort
We tried CASE and it did not like it
We do not have the time
Business units tell us what to build; we do not question them
We cannot keep business and IT models in synch
Business changes too quickly to model it
Is applications development modeling not enough?
Is prototyping not enough?
Business modeling is more trouble than it is worth
3 In this context BPM means Business Process Modelling. This is a common practice in modelling approaches, easily justified by the fact that the BPM pragmatic, defined as Business Process Management, is very recent.
25
In order to avoid the reasons pointed above, the usage of meta-models has been proposed.
Enterprise Architectures (EAs) are part of them. An EA results from the continuous process of
representing and keeping aligned the elements that are required for managing the organization.
This is used to describe business structures and processes that connect them (Sousa, et al.,
2007). Process meta-models define process fundamental concepts and their relationships,
integrating static and dynamic aspects, and organizing the various models of processes. These
are also used to state who is doing what, when, how and why.
4.4.1 Enterprise Architectures
EAs aim to allow a holistic view of the organization through its decomposition in different
dimensions, and to guarantee that technologies are the ones that support the business. In order
to apply an EA many frameworks have been proposed. Each EA Framework is divided in
different levels layers, which describe the enterprise in an explicit and semiformal way from
different points of view. The different existing frameworks differ from the level of abstraction they
use, and the industry‟s branch defined as target. Only two of them are then described, focusing
the view where organization‟s business processes are located, and how they are represented.
The reason for selecting the following EAs is because they were the ones that mostly
contributed for this study. We suggest (Telematica Instituut, 2002) as a good source for others
EA descriptions.
4.4.1.1 Zachman’s Framework
The framework proposed by John Zachman, also known as “The Framework for Enterprise
Architecture” derives from equivalent structures used in other disciplines to design complex
physical products (e.g. buildings or airplanes). This framework applies to the enterprise a logical
structure for classifying and organizing its management and to develop its systems. The
generalization of the process analysis done by this framework allows its appliance to every
business area.
26
Figure 15. Zachman‟s Framework, “The Framework for Enterprise Architecture” (ZIFA, 2006).
The model proposed is based on six simple questions: “what”, “how”, “where”, “who”, “when”
and “why”. These questions are answered by five distinct perspectives: visionaries, executive
leaders, architects, engineers, implementers and workers (Figure 15). Each representation (and
each perspective) presents a different set of constraints (Goethals, 2003).
Several lines and cells should be filled in order to reply to the previous six questions and as a
guide to the tasks and activities that should be performed to employ Zachman‟s Framework. At
the end of each task, documents and artifacts should be prepared, describing the analyses
done in the best way. Models are examples of these artifacts. However, the models described in
each cells are generally more hypothetical than empirical (Telematica Instituut, 2002). The
reason for this can be justified by the fact that the main ambition of this framework is to allow its
application to a wide range of enterprise‟s areas. The absence of a common modeling
language, that can be applied to all business areas, justifies the not suggestion of one in this
framework. This would restrict its range.
Business processes can be found in the “how” column, filled with its description, model and the
IT resources that supported them. The first three cells of this column contain the list of the
enterprise processes, the model of its business processes and the application architecture that
supports the processes (Lemos, et al., 2006).
In a succinct way, this is a simple, comprehensive and neutral framework (Telematica Instituut,
2002). It‟s simple because it is a non technical and purely logic approach. Addressing the entire
enterprise makes it comprehensive, and finally, because it is totally defined apart of tools or
methodologies, it‟s neutral. This means that it does not define a meta-model to integrate the
27
information within each cell. An important issue is the fact that it doesn‟t describe how to trace
the information between cells, nor the model that should be used to describe each cell.
4.4.1.2 Organizational Enterprise Centre Framework
The Organizational Enterprise Centre (CEO) framework provides an architectural model for
process-oriented organizations. This framework uses as references some others such as
Zachman‟s framework and TOGAF. A distinct feature from the other ones is the fact that this
one uses a specific modeling language to represent the EA, i.e. UML. The EA proposed is
divided in five architecture views, represented using UML packages, which separately address
different concerns related to the organization. These architecture views are organizational,
business, information, application and technology (Sousa, et al., 2007).
The organizational architecture deals with the aspects directly related with the organization,
including concepts such as the enterprise mission, vision and strategy, and the definition of
organizational units. The business architecture defines the business processes of the
organization.
The information architecture describes what organization needs to know to run its processes
and operations as described in the business architecture. It defines a view on the business
information that is totally independent from system and technology.
The application architecture fulfils two major goals: supporting the business requirements and
allowing efficient management of the organization‟s entities. Finally, the technological
architecture represents the technologies behind application implementation, as well as the
infrastructure and environment required for the deployment of the business process support
systems.
The ambition of the previous architectural views is to describe and relate the fundamental
concepts that, as a whole, describe the enterprise architecture. Each architectural view is
composed by different parts. For example, the technological encompasses three parts: IT
infrastructure block, IT platform block and IT application block. The different architectural views
and its components are represented in Figure 16.
28
Figure 16. CEO architectural views, its components, and the relationships between them (Sousa, et al., 2007).
As mentioned before, the core concept of the business architecture is the business process. In
this architecture business process is defined as a set of activities that adds value to some
costumer, whether internal or external to the organization. The representation of the process,
using UML, is also described.
To represent the process, the framework uses the concepts of activity, role and entity. The
activity describes business roles required that are played by the organization entities, these
roles are: actor, resource, and observable state (Figure 17). Depending on the purpose, several
UML diagrams are used. Just to name a few, to represent activity done in a process, an activity
diagram it‟s used, to represent the relationships between the different roles, a package diagram
it‟s chosen, and the relation between role types it‟s done through class diagrams.
Figure 17. Relationships between activity, role and entity (Sousa, et al., 2007).
Beside all the architectures views and the way to represent its components, an important
subject is also considered, the alignment between them. This alignment is accomplished
through integrity rules defined between sets of EA concepts. The business case alignment is
motivated by the following causes: (1) business and information architecture are aligned when
29
people have information they need to run the business; (2) business and application
architectures must be aligned in order to enable the information systems to provide services to
the business.
This framework can be summarized by the fact that it emphasizes the traceability, alignment,
and assessment between enterprise concepts, facilitating their reuse and independent co
development. However, it defines no methodology to implement it, although, with the language
to model and the alignment proposed, this last issue should be chosen according to
organization‟s realities.
4.4.2 Business Process Modeling Languages
The missing aspect to describe in this modeling section is the business process modeling
languages. Modeling languages aim to represent the real process components and its behavior,
providing various concepts that, when combined, result in its representation. This representation
should be easily understood by those who are involved in the process and by those who will use
the model to improve it. Examples of these are IT people, whose main goal is to provide
efficient support to enterprise‟s business processes.
In nowadays, the goal is to create/use a language that can be applied to every type of business
reality and understood by all people involved in them. Only two languages of a huge available
list will be described. Besides technical reasons that have influenced this choice, an important
characteristic is the fact that they are implemented in accessible software, which proves their
present wide usage.
Unified Modeling Language and Business Process Management Notation
These languages are presented together because they use similar representations and, at this
time, they also belong to the same developer, OMG. The language names are Unified Modeling
Language (UML) and Business Process Modeling Notation (BPMN).
UML, as its name suggest, is a language that allows the representation of a wide range of
concepts in many different subjects. This is done through different available diagrams and
supported by the fact that it can be extended, allowing the definition of missing aspects. UML is
able to represent the different process views proposed by process meta-models, such as:
requirements, structure, content, behavior, information, stakeholder, and instance (Table 2).
Currently this language is in version 2.1.1. An example of a UML business process modeling is
depicted in Figure 18.
30
Figure 18. Example of business processes modeled using UML.
BPMN was created with the specific goal to represent business processes, allowing the
representation of activities‟ lifecycle (Figure 19). Its main limitation is associated with the restrict
process views that can be represented with it: behavior and instance. An important usage of
BPMN is the fact that it has an execution language associated with it, Business Process
Execution Language (BPEL), allowing its automatic conversion into code standards and
motivating its usage in business process systems.
Figure 19. Example of business process modeled using BPMN.
The existing relation between these two languages, its diagrams, and artifacts is represented in
Table 2 using the behavior process view proposed by Jon Holt (2005). It‟s clear that actually
these modeling languages are very similar, using the same objects to represent related objects.
Even so, in this study the chosen language was BPMN, not only justified by the fact that it‟s
specifically oriented to business process modeling, but also because it uses a cleaner
representation, easier to understand by non IS people.
Analyze Needs Create Order Send Order Receive Order
Process Order
Inform Client
Create Order
Client Company Supplier
available
not availableC
lien
t C
om
pan
yS
up
plie
r
available
Analyze
NeedsCreate Order Send Order
Receive Order
Process Order
Inform Client
Create Order
31
Table 2. UML 2.0 versus BPMN 2 process representation.
Process View
UML Activity Diagram BPMN Diagram
Behavior Activity. Stakeholders shown as swim lanes, activities as activity invocations, artifacts as objects.
Business Process Diagram. Stakeholders shown as lanes (pools and lanes), activities as activities, artifacts as data objects.
4.5 Implementing BPM
After answering BPM „what‟ question, this section aims to explain the methodologies proposed
in order to answer the „how‟ question. Implementing BPM is itself a definable business process,
one that has steps, order, importance, key elements, conditional routing, common objects,
known resources and business rules (BPMG, 2005 p. 111). It‟s basically a business process
that enforces empirical requirements while providing the flexibility to adapt to the specificity and
nuance of each organization's needs and situation. Depending on the author‟s base studies,
methodologies can be more IT or management oriented. However, there are some best
practices that should be considered by both (BPMG, 2005 pp. 24-26):
Start with the end in mind: a clear and a shared vision are required when starting.
Performance driven: every process, in order to be manageable, must be measurable
and driven towards the attainment of agreed performance objectives. „What you
measure is what you get'.
Stakeholder-driven: processes should focus on the stakeholders and their
requirements. The criteria for process performance must start and end both with their
needs and desires.
Criteria before decisions: early process steps in every process must be built in to get
acceptance of criteria to be applied in later ones.
First things first: after thoughtful design, all the steps should be done not skipping
conduction good planning and preparation work. When designing process the
methodology must have an adequate consideration for whole process design, not just
the visible part at the end.
4.5.1 LEARN Method (Jorge Coelho)
Jorge Coelho recommends some requirements for an effective methodology to implement BPM,
introducing concepts such as Organizational Therapy and Business Object approach (BPMG,
2005 pp. 119-130). The idea is to implement a new management business model that ensures
better performance from a learning organization perspective. This methodology concerns OSA
as an important issue to reach successfully its goals. The requirements proposed are:
Focus on the strategy and the organizational as a whole;
Use an Organizational Therapy approach;
32
Pay attention to the management of knowledge;
Model the Process-Centric Enterprise Architecture in a systematic and Business Object
Oriented way;
Deploy the strategy using a Process-Centric Enterprise Architecture;
Define a Continuous Improvement Management Model and the respective
implementation team;
Use interactive and real time techniques.
The methodology states that firstly, and before initiating any project, is necessary to understand
organization‟s strategy and its business improvement objectives. After this, these processes
should be placed in the enterprise architecture. In the case that there isn‟t any enterprise
architecture yet, two steps could be followed, a top-down approach or a middle down one.
Top-down approach would define firstly the context of the processes to improve, and later start
the modeling exercise. The middle down approach will define the first level of processes and
then drill down to find all the processes to be aligned and improved. Using this approach will
avoid the development of organizational improvements by function or department, which usually
results in the “isles of management” problem.
The point here is to avoid the identification of the „as is‟ situation to model processes and then
to analyze them. Proposing the identification primarily of the the target processes in enterprise
architecture and improve them in order to reach the project objectives defined initially.
Organizational Therapy requirement stresses the importance of the convergence between the
different views that each person have of the organization. To avoid the misalignment between
the different pictures that each person has, Jorge Coelho proposal starts with workshops where
each person do an „as is‟ analysis of the organization in order to, with all the information
obtained, fulfill the enterprise architecture.
To implement BPM, knowledge management should be considered as an important issue. It
should deal with explicit and tacit knowledge. However a big slice of this knowledge is tacit. In
order to correctly create a knowledge repository, where it‟s possible to store and manage
Human Capital, several important practices should be considered. These practices include an
important one, the creation of interactive models during workshops and interviews with the aim
to validate the knowledge that is being transmitted, and to align it with the one already existent
in this repository (Figure 20).
33
Figure 20. Central Repository proposed by Jorge Coelho‟s Methodology.
Reached the previously requirements, it‟s now time to define the processes in terms of status of
Business Objects. A Business Object is an entity that gathers all the information needed to
support to a stimulus. Basically, when a stimulus is received it‟s created a process to respond to
it, the Business Object is associated with the stimulus received and it‟s given the same name to
it. The stimuli from stakeholders give the first level of processes, which decompose the process
according to the number of business objects. When a level it‟s reached, where a process has
only one business object, this phase stops. After this the process should be decomposed into
activities, being these a set of tasks needed to manage a control point in a process.
The deployment of the strategy using a Process-Centric Enterprise Architecture has as pre-
requisite the consensus about organization actual situation, the „as is‟. This will be used to help
reaching the „to be‟ state, corresponding to the initial proposed goals. The strategy should be
obtained using the decision levels of architecture in an objective way. In this phase each
manager gets the objectives and goals associated with the processes that have been put under
his responsibility. Through this the strategy should be defined, in an objective way, where its
measures should be based on Business Object status, as they represent control points in the
processes.
Finally, it‟s important to refer that all the results provided by the previous requirements
described before must be supported by a common repository. This repository should be
available to all the intervenient to store information about the organization, therefore to support
the communication, and to reinforce a unique organization view.
The methodology proposed by Jorge Coelho is a very complete one, including a whole
description of which steps that should be taken, who should be involved in them, and how they
should be supported. Although, the enterprise architectures mentioned are not the same as the
ones previously described (section 4.4.1). Instead, the models produced by this methodology
34
only represent processes in a broad view. Thus, individual and interpersonal work practices are
not concerned, restricting its appliance in an OSA perspective.
4.6 Conclusion
BPM is a process-centric approach to the organization that aims to align important concepts,
such as supply chain processes, project planning processes, learning processes and IT. In
addiction to this, BPM propose a way to manage all the processes alike, and in real-time,
supporting the answer to „what-if‟ process and allowing the specification of the new to-be
processes.
By the concepts and definitions stated along this section, it is possible to assert that BPM came
to stay. The concerns about (i) real time management, (ii) the suggestion of organizational end-
to-end business processes definition, and (iii) processes representation using models to
facilitate its comprehension, are some of important features provided by BPM.
Gathering all notions back together, in order to fulfill some of the existing misalignment between
them, and always considering OSA as a key point, will contribute for the effective and
successful application of BPM in today‟s organizations.
5 Information Gathering Techniques
The constant need to reach the alignment between the IS and the organizational needs
contributed for the development of many techniques in order optimize requirements gathering
process. When concerning analysis of agent activities or even defining organizational business
processes, these techniques can be very useful. Nevertheless, they have in common the fact
that they all want to produce something based on the information acquired from the
organization.
Amongst all the available techniques, two were chosen. The first is a much known one and it is
used in many subjects apart from IS development, such as human resources or strategic
consultancy, usually it is named as interview. The second one, less famous and not so broad, is
entitled ethnography.
5.1 Interviews
Despite the fact that the interview technique is broadly used in many different subjects, the
reference considered, and consequently the description stated, is based on a software
requirements approach (Kotonya, et al., 1998).
35
Interviewing is a personal technique and requires the minimum presence of two people, the
interviewer and the interviewed. There are two main kinds of interviews, structured, previously
planned and strictly followed, and none structured, that is very similar to an informal
conversation. Both of these can be used in order to obtain the needed information, the choice
should be done considering aspects such as the time available, the number of persons
involved, the complexity of the information wanted, amongst others.
5.1.1 Preparing the Interview
Before starting an interview, a previous preparation phase is suggested. As an interviewer, this
should be used to (1) contextualize yourself about the your proposals through the reading of
related material; (2) establish interview goals; (3) decide who to interview; (4) prepare the
interviewed person/people; and (5) decide the type of questions and their structure.
There are two major different kinds of questions, open and closed. Open questions are
characterized by the fact that there isn‟t any predefined schedule. In closed questions the
number of answers is initially restricted, these are appropriate when precise information is
required.
The main advantages of open questions are: the interviewed gets more comfortable, uses the
vocabulary of the interviewed, generates new questions, provides more detail, and is more
interesting for the interviewed. On the other hand, this choice can result in problems, such as:
many details without relevance, losing the control of the interview, the answers taking too long,
and look like it wasn‟t prepared.
Closed questions can be good because they save time, go straight to the point, grant the control
of the interview, and allows the coverage of many relevant subjects. However, they can be
painful to the interviewed; and miss some important details.
As mentioned before, structuring the interview should also be done before starting the interview.
There are three different ways to structure an interview, pyramid, funnel, and diamond. The
pyramid starts with a specific question and ends with a generic one. The funnel is the inverse,
begins with a generic question and ends with a specific one. Finally, the diamond combines
both of the previous, consuming more time than the others.
5.1.2 Best Practices During the Interview
Once the interview started, there are some things that should be taken in consideration, such as
how to register the information gathered, how to conduct the interview, and how to behave
during the meeting.
36
There are several ways suggested to register an interview, for example an audio recorder or a
note book. When recording the conversation, the interviewed should be informed previously.
In order to collect all the needed information, there are some best practices that should be
followed by the interviewer. Before the interview he should (1) confirm the appointment; (2)
dress in an appropriate way, preferentially using the same style of the interviewed
person/people; and (3) arrive on time. Start the interview (1) acknowledging the interviewed, (2)
remembering the defined goals, and (3) informing interviewed how it will be registered. At the
end of the interview, (1) make a summary, (2) ask for doubts, and (3) acknowledge for the spent
time.
5.2 Ethnography
Genzuk (2004) presents an introduction and overview of ethnography and its applications in the
fields of social sciences. It states that “ethnography is a social science research method”, from
the fields of anthropology and sociology. Typical ethnographic research employs three kinds of
data collection: interviews, observation, and documents. These in turn produces three kinds of
data: quotations, descriptions, and excerpts of documents, having as result one product:
narrative description. (Genzuk, 2004)
Besides this definition, ethnography can be stated as having the objective of capturing customs,
beliefs, and behaviors of a group of individuals. The ethnographer spends a reasonable amount
of time (sometimes years, in case of anthropologists) with the individuals, taking detailed notes
of their actions and practices. That information is processed later on to reveal the “structure,
organization and practices” of the group studied (Sommerville, et al., 1993).
5.2.1 The ethnographic method
According to Genzuk (2004)the ethnographic method is characterized by the following features:
Individual‟s behavior and actions are studied in his natural context, without need for
virtual or simulated environments. This will be further discussed, as the “naturalism
principle” that ethnography must comply to.
The main source of information comes from observations and informal conversations
with the individuals under study.
There is no pre-formed plan and assumptions about the data collected. Data is
collected in raw. Only afterwards it will be mined and information can be processed out
of it. This is strongly related to another fundamental principle, “discover”, which will also
be discussed further on.
The group being studied is typically small and restrict to a particular setting.
37
The analysis of the data produced, implies the interpretation of the meanings and
intentions of the actions observed. In conformity with the third principle,
“Understanding”, that will be presented later on.
Apart from the previous described features, there are two different types of roles that can be
performed by the observer: participant or onlooker observer. This is a major decision that
influences the whole process of ethnography. Besides the two extremes, being a participant or
a mere spectator, all the other values of the spectrum are possible. Being a participant observer
implies sharing the life and activities of the people under study. The researcher gains a much
more profound insight of what‟s happening.
Nevertheless, to accomplish a good ethnography practice, the researcher must be able to keep
up with the task of observing and taking note of those observations. So, it is quite
understandable that becoming a participant deeply compromises the whole process and it will
be very difficult for an ethnographer to cope with both, the observations and his activities as a
participant. Some believe that it is neither necessary nor convenient to become a participant. In
fact, they say that the ethnographer must become as distant of the practices as possible, even if
they seem familiar. One must always rationalize and remain aware during the whole process.
5.2.2 Fundamental Principles
Ethnography thinking is rooted in three fundamental principles: naturalism, understanding and
discovery. (Genzuk, 2004)
Naturalism “is the view that the aim of social research is to capture the character of naturally
occurring human behavior”. This implies that no virtual or simulated environment is suitable to
achieve the purpose that ethnography aims to reach. Contrary to interviews and experiments,
only ethnography can show us the actual actions and behaviors of the group under study. To
accomplish, the researcher must be aware that his presence may affect the environment in
study. The ideal observation is the one where the subjects will not know that they are being
observed, though this may raise ethnic issues, such as the right to privacy. As not all
occurrences can be observed, an ethnographer must try to document enough situations to
extrapolate, later on, the fundamental patterns, key actions and procedures.
Another principle, which we will state as the ability to produce valid explanations for the
behavior of its members, is the principle of “Understanding”. In order to produce “valid
explanations”, one must gain knowledge of the cultural aspects that can influence the actions
observed. In this situation being participant at some degree clearly helps to develop cultural
insight, but as discussed before, participation may also blur the capacity of true objectivity. This
is also true when the observer is already naturally emerged in the culture of the observed.
38
Indeed, the behaviors may seem familiar and the danger of misunderstanding is particularly
great.
The “Discover” principle, that should be respected, states that the researcher should approach
the study with a clean mind instead of “being limited to the testing of explicit hypotheses”. In
fact, this erroneous attitude, will most certainly lead to the formulation of pre-assumptions that
could blind and misguide the researcher through the whole ethnography process.
5.2.3 Ethnography and Information Systems Design
Narrative descriptions, the classic output of the ethnographic method, lack the objectivity and
formalisms necessary for the engineering process (Genzuk, 2004). This technique has proven
to be useful before in the fields of Information System Design as we‟ll describe following.
Through years, as more research and experiments were made, the problems of integrating
ethnography with software methodologies became well defined. Viller, et al. (1999) identifies
and summarizes those issues:
Time: Ethnography, when applied to social research, usually takes a long time, months
or even years. The Requirements Engineering process needs to be much faster.
Results: The output of the ethnographical method, long textual descriptions, is difficult
to integrate in the existent methodology of system design.
Culture: As a result of sociologist‟s and requirements engineer‟s different backgrounds,
communication between the two groups can become a complex issue.
Abstraction: Abstraction does not suit ethnography very well. Ethnographic outputs are
too much directed to the details of a particular situation.
Skill: Because ethnography lacks a fixed step-based methodology, the results are
greatly dependent on the ethnographer‟s skill.
To address these issues, three different approaches on managing the integration of both
techniques were proposed by Button, et al. (1996): Concurrent ethnography, Informed by the
ethnographic account, and ethnographically informed method.
In concurrent ethnography the ethnographer goes to field, the work place of the group under
study, and undertakes the ethnographic process. Although an account may result, it is not the
account that will serve as input for the rest of the design process, but the ethnographer himself.
The idea is for the ethnographer to work as proxy between the group under study and the
requirements engineers.
39
The informed by the ethnographic account technique is characterized by the ethnographer
production of an account as a result of its study. This time, however, it is the account that will be
passed to the design process, instead of the interaction between the design engineers and the
ethnographer.
Finally, the ethnographically informed method, initially proposed by Button, et al. (1996), is
described under the category of the Coherence methodology (Viller, et al., 1999). In this case,
the design process is informed by the ethnographic methodology itself. The idea is to create a
new process which is influenced by ethnography and integrates ethnographic principles. This
way, instead of having two distinct methodologies working together, ethnography and the
design process, the purpose is to have only one process, which merges ethnography into the
design process.
5.2.3.1 Presentation Framework
Amongst others, the presentation framework structures ethnographic data in terms of three
dimensions of work: distributed coordination”, plans and procedures” and awareness of work”.
Distributed Coordination is concerned with how the tasks are performed within the broader
context of the organization (Viller, et al., 1999). It basically defines ‟who does what‟. It‟s
extremely useful for defining the roles played by each individual as they interact with each other.
Plans and procedures focuses on how the organization describes its processes and structure.
This information is usually described in documents and basically reflects how organizations see
themselves.
The third dimension, awareness of work refers to how individuals perform their tasks so that
what they are doing is made ‟visible‟ or ‟available‟ to others (Viller, et al., 1999).
As a result, it‟s possible to state that the presentation framework demonstrated a great potential
in structuring fieldwork notes and making them available and more accessible to the design
process.
The reason why this framework was chosen is justified by its special concern about work
practices, being through this aligned with the concept of OSA, and easily related with the agent
architecture and ontology previously described (section 3.2).
5.3 Conclusion
The success of interview techniques appliance in many different subjects contributed for their
broad usage of this famous method. Concerning a conversation between, at least, two people,
where one of them is asking questions, this procedure requires a previous preparation and the
40
follow of important best practices. However, being a technique that demands people presence
its success does also dependent on the interviewers‟ personality and ability to get what he
wants.
As main disadvantages, interviews usually take too long, requiring many resources and
representing an expensive method. In addition to it, they can lead into wrong interpretations or
even information omissions.
Ethnography is a social sciences technique. Though, lately software development fields have
also applied this method to requirements gathering. There are several ways proposed to
observe and register. They state how the ethnographer should behave and what should he
register, amongst other things.
This technique has the main advantage of preventing information omission, stated as one of the
interview disadvantages. However, the presence of the observer can influence the way people
behave, resulting in the gathering of wrong information. The time is a common disadvantage is
both methods.
41
PROBLEM DECLARATION
“There is nothing so easy to learn as experience and nothing so hard to apply”, Josh Billings
The fundamental theoretical bases used in this study are OE discipline notions, frameworks,
methods and approaches stated in the previous sections. In addition, a guideline has been
defined, OSA through enterprise modeling, concerning the capture of each person way of
working and real-time issues.
This section relates the theories previously described, states thesis‟ problem, and describes the
research approach followed to achieve our goals, and as a result solve the problem defined.
6 Problem Statement
The importance of people‟s awareness about organization and how that knowledge influences
their way of working, and consequently assist the optimization of organization processes, is one
of our major concerns.
Enterprise models have demonstrated their effectiveness in acquiring OSA (section 3.1 and
4.4). However, the framework and approach stated (section 3) only suggest a way to capture,
structure actions, and identify contexts. It doesn‟t mention how this information can be
represented using action-based models, which are important instruments to communicate. On
the other hand, BPM modeling proposals and Jorge Coelho‟s LEARN method (section 4) don‟t
consider people‟s work practices as relevant information, by considering mostly organization‟s
macro processes.
In this study we aim to find a way to use enterprise models that represent each organizational
person tasks, illustrating their personal and interpersonal work practices. The motivation to do
this it is justified by the importance that these models have in synchronizing the image that
people have of organization. Capturing and representing this information in real time is also one
of our ambitions, in order to speed up the achievement of OSA goals and provide people within
organizations instruments that allow them to wonder in real time about possible optimizations
and support its further implementations.
To summarize, this study concerns finding a way to answer the following OSA questions:
In a „as is‟ based approach:
o Which tasks perform agent X?
42
o How does agent X performs each task?
o What resources are used by agent X to perform these tasks?
Regarding the „to be‟, after the reengineering of work practices:
o Which tasks will be performed by agent X?
o How will agent X tasks be performed in the future?
o What resources will be used by agent X to perform these tasks in the future?
In addiction, and as already stated before, the inexistence of a method that allows real-time
capturing of the information needed to answer these questions, and its further representation in
a way that organizational people can understand them, is the problem addressed.
The results attained by solving this problem will allow the synchronization of representations
(models) that people have about organizations. Thus, this will become an efficient way to
perform management actions, support change management, and plan IS, amongst others.
7 Research Approach
In order to solve the problem stated above, an approach that encloses all OE described
concepts has been proposed. This is based on the relationship and gaps existing between
these.
All the previously described subjects are connected. In the framework proposed towards OSA
(section 3.2) enterprise models are referred as a key instrument. These models are also
mentioned by BPM (section 4), which proposes their design using EA and business process
modeling languages.
To put the OSA framework into practice, using Model Acquisition Approach (section 3.3), or to
apply BPM to organizations, with LEARN method (section 4.5.1), it becomes necessary to
gather information about the organization concerned. This can be done through specific
techniques, described in section 5, where it is possible to distinguish interviews and
ethnography.
Joining all the existing relationships between the three stated areas, OSA, BPM, and
information gathering techniques was the approach followed to reach the objectives of this
study. It can be summarized as an approach that merges the different concerns of these areas,
validating its benefits and efficiency in reaching OSA goals (Figure 21), and fulfill the existing
gaps between them in order to promote organizational people awareness about it.
43
Figure 21. Relation between OE concepts and the Approach proposed.
The approach proposed has been defined along time. Representing case studies a major part
of the developed work, each one will be described further. Here all the important decisions will
be explained, as well as the approach formulation, as a result of a reflection over the developed
work.
44
A STEP
TOWARDS ORGANIZATIONAL
SELF-AWARENESS:
CASE STUDIES
"If you hold a cat by the tail you learn things you cannot learn any other way." Mark Twain
Most of the developed work during this study was performed in real organizations. This allowed
us to put into practice many concepts, theories, and approaches stated before, validating their
appliance in real case studies. This practical effort has also contributed for the development of
new tools and to state a new approach that motivates OSA, allow the reverse engineering of
individual and interpersonal work practices, and provide a knowledge base to support „to be‟
analysis.
In this section two case studies are described. Despite the fact that both of these cases are
based on the research objective, spread the “virus” of OSA along organizations and motivate
with this the optimization of organization‟s processes, approaches followed differ from one case
study to the other. This difference is justified by each organization‟ goals defined for the work
developed and by the universe of organizational agents involved during the case studies. Each
case is further described, chronologically ordered.
8 Optimizing Moviflor Personal and Interpersonal Tasks
The first case study was developed in a furniture retail company, Moviflor. This is a Portuguese
and familiar organization, in the market along the last 30 years selling home products, from
furniture to decoration and illumination, carpets, textiles, amongst others. Nowadays Moviflor
employs more than 1000 workers in 20 stores and 5 warehouses distributed all along
Portuguese continental district and both islands, Madeira and Azores.
In 2001, Moviflor carried out a huge reform that consisted in intern reorganizations and on the
adoption of a new IS. This restructuring aimed to enforce and refresh organization‟s market
identity and redefine its missions and strategic goals. The main IS change was the
implementation of the ERP SAP R/3, whose objective was to provide a way to support widely
45
organization‟s business processes. After a first trembled period, SAP is correctly working in
most of Moviflor‟s organizational units. Their business is also running well, justified by the
constant grow of their sales during the last years.
This case study was centered in Moviflor sales department. This is composed by three main
groups (Figure 22): (1) category managers, responsible for product management and suppliers‟
agreements; (2) sales central, in charge of buying products, acquiring services from suppliers,
and manage the relation with suppliers after the product/service acquisition; and (3)
importations, responsible for buying and managing the orders provided by suppliers from other
continents whose merchandise is transported by containers. Firstly, the project started in sales
central, and once finished, a second study was performed in importations business unit.
Figure 22. Moviflor sales department organizational structure.
8.1 Defining Objectives
In order to start the work, it becomes necessary to identify main goals that would drive it.
Basically, in this phase there was a need to recognize project guidelines and understand
organization expectations. Similar as in LEARN method proposed by Jorge Coelho (section
4.5.1), the objectives were defined during a meeting where the sales department director point
out which were his priority issues.
The initially defined goals were based on sales central business unit. The objective was
optimize communication procedures with suppliers in order to (1) reduce the deficient
accomplishment of contracted points, such as late deliveries; (2) decrease the number of
incomplete or damaged products stored in warehouses; and (3) optimize employees work
practices through their standardization.
To accelerate the project, as suggested by LEARN method (section 4.5.1), an initial
contextualization in organization business and history was also obtained. This was done
Sales Manager
Category Managers
Sales Central
Importations
46
through informal visits to Moviflor stores and by reading organization documentation, e.g.
previous studies and company training information.
8.2 Delineating a Strategy
Once goals were clarified, it was time to define a strategy to reach them. This step is also part of
LEARN method (section 4.5.1), aiming to answer questions such as: (i) which people and when
will be involved in the project?; (ii) how long will it takes to provide results?; and (iii) how long
will the project takes?. As answer to these questions, initially was proposed a short observation
and interviews phase, followed by a group meeting where the subsequent steps would be
defined. This means that the answer to the last questions was rescheduled to the next reunion.
Being the sales central composed by 6 people, who work hardly diary, the participation of each
one in the project was gradual. The project started with only one person, a key user that was
already working in Moviflor for about five years. This person organizational awareness facilitates
a rapid contextualization in Moviflor‟s business and processes. After this first stage, other
people had gradually joined the project.
8.3 Instantiating Model Acquisition Approach
The following described performed steps are related to the ones proposed by the model
acquisition approach described in section 3.3. Thus, the subsequent phases can be expressed
as an instantiation of this approach.
Instead of using the term „agent‟, we will use the word „people‟. Being the following steps based
on each people actions, its comprehension becomes clear switching these terms. However,
when referring to other organizational levels, such as organizational units, the term agent is
applied.
8.3.1 Bootstrapping
Bootstrapping begins with an observation period that aims to define different action and
resource types for each person. This took about one week and consisted on interviews and
observations.
8.3.1.1 Interviews
Using the principles and methods previously referred about interviewing (section 5.1), some
questions were done to the chosen key user. These questions intended to realize, in a generic
way, which different tasks were performed diary in sales central and how they were
accomplished.
47
Generally, the used questions can be characterized as open ones, such as “What are your diary
main subjects?” or “Tell me about your work”. However, along the interview process there was a
need to funneling, changing to more specific questions, e.g. “How do you create an order?”.
This interview structure is usually classified as pyramid. As suggested in interviews best
practices, each took about 1 hour and was done in an informal way, like an ordinary
conversation, habitually while the interviewed person was working.
During the interview course, some methods were used to confirm that the interviewer correctly
understood what has been told him. As examples of these, two main practices were performed.
A typical way to validate something was to repeat. Another way was to design what people had
said using simple representations, e.g. connected boxes, to represent flows, hierarchical
graphics to represent relations, etc.
8.3.1.2 Observations
Observations of people‟s work were performed using some principles of information gathering
ethnography technique (section 5.2). Ethnographic principles realize aspects such as the
observer behavior, the register support and the results presentation.
Observer behavior was more transparent as possible, in order to avoid influencing people‟s
work. While observing the ethnographer was quiet, in silence, and only writing what he was
seeing.
Given this case ambition, the main concern was to register people‟s actions, and resources
used to perform them. This was done by writing this information in a notebook. It‟s important to
refer that while observing and registering, the ethnographer didn‟t filter which important tasks to
note. This process should only be done after, when analyzing the information gathered. The
way how actions were written and how the results were presented is detailed further.
Before observing, an initially clarification of the work proposes were described to each person.
This helped them to be more comfortable, and performing their working naturally.
8.3.1.3 How People React to Ethnography
Even not being a recent technique, it is not frequently applied in organizations. Thus, it
becomes interesting to state the way observed person react, and also how observer feels while
performing it.
Initially, after a brief explanation to observer about we were about to do, usually he reacted
saying that there was no problem to him, and that he will be comfortable while is being
observed. However, it was easy to notice that during the first instants the observed person got a
little bit constrained by the fact that someone is sited behind him noting everything that he was
48
doing. Normally, this constraint only happened during the first hour. After it, observer “forgot”
that was being examined. A good way to optimize the relation with the observer was to show
him the notes written and clarify the aim of the work proposed.
The constraint is also part of the observer feeling while performing this practice. However,
similar to observed person, after a short period of time observer becomes more comfortable.
Stated feelings and behaviors can depend from person to person. However the described
impressions were based on the observations of six different people, whose reactions didn‟t
differ radically.
A curious fact was that for Moviflor people the observing technique was one of the preferred
ones (Annex A). When informally questioning people about this unexpected result, they
answered that it was the only method that required less effort for them, “we only have to work
normally…while you register what you want without disturbing”.
8.3.2 Registering Personal Actions
The observed actions were registered in an organizational sentence format (section 3.2.1).
However, in this phase they weren‟t normalized yet. During observation people‟s actions were
described in a draft form, e.g. Pedro confirm order by email, Susana create order in SAP ME21
menu, João updates warehouse delivers in excel file.
After each observation day, actions registered were analyzed and normalized in order to
complete the following fields: time, actor, action, description, subject or keywords, and
resources. Apart for the subject, all the other fields are part of the organizational sentences
format.
Subject field, also described as key words, was used to group actions according to the context
definition, a network of interacting agents playing related specific activities and resources
(Zacarias, et al. b, 2007). Each action was contextualized, grouping it according to its keywords.
Table 3 exemplifies each field contents, except for the time.
49
Table 3. Draft organizational sentences registered during observation.
Sentence Actor Action Description Subject or keywords
Resources
Pedro confirm order by email
Pedro Confirm Confirmation of
previously created order with supplier
Order Confirmation Email
Susana create order in SAP ME21 menu
Susana Create New order creation
Order Creation SAP (ME21)
João updates warehouse
delivers in excel file
João Update
Update of warehouse list
where are saved all the delivers
Order Deliver Excel (delivers.xls)
After the observation period a set of actions, resources, and subjects normalized were defined.
As suggested in bootstrapping phase, the set was presented to the agents involved in order to
validate them. Moviflor sales director was also present during validation, using his wide
knowledge about the department work to support this validation. The validated set for each field
is further provided.
It was during the validation meeting that were defined the next work steps. The proposal was to
capture personal actions and represent them in order to, after this, recommend optimizations.
The followed approach is described next.
8.3.3 Capturing and Structuring Actions
This phase, as it names suggest, aims to capture and structure actions. The proposal is to
obtain actions through organizational sentences composed by triples subject-verb-object
(section 3.2.1).
Being the team constituted by six people, each one with different work practices, but only with
slightly different responsibilities, it becomes necessary to develop a tool in order to support, and
speed up, the project. This tool was a web application, named “Activity Register Portal”4, and
initially came out only to with the ambition of providing a semi-automatic way to get structured
and normalized organizational sentences.
Basically, the application developed was a web form where people register each action after
perform it (Figure 23). The form was composed by the following fields: subject, action,
technological resources, personal resources, other resources, delegation and other information,
as a free text field. Except for the free text, all the others fields were inserted by choosing one of
the presented options. However, there was also a free input associated to each field.
4 The chosen name for the Portal doesn‟t illustrate correctly its proposal in a technical way. However, the name is justified because it facilitates the explanation of applications objectives to ordinary people.
50
Figure 23. Action form available in the Activity Register Portal developed.
Subject was used to select the context of the action performed. When introducing Portal to
people, the instructions for fulfilling this field were explained using the email message analogy
i.e. imagine that you have to send an email message to your director explaining an action that
you have done; which subject will you choose for it?.
The options available in subject filed were: calculate products needs (provisions), products
codes, catalog product, suppliers‟ contacts, containers, new order creation, order devolution,
order state, damaged products, incomplete products, pendent orders, publicity, and client claim.
Each of these was presented and validated during bootstrapping phase before making part of
the set.
The notion of action is similar to the one considered by model acquisition approach
organizational sentences (section 3.3.2). They are the verbs that identify the action type.
Available options in the set action were: analyze, ask, calculate, change/update, confirm,
create, inform, lock, modify, note, print, reconfirm, request, search, and unlock.
Resources, defined as things relevant for organization operations, were divided in three
different categories. These were technological, personal and others. Technological resources
were the ones related to software components, mainly IS e.g. SAP menus and Excel files.
Personal resources refer to people involved in the action as a resource. These are justified by
their knowledge or exclusive ability to perform a required task. The options presented here were
from individual agents to organizational units, contemplating different organizational levels,
according to architecture levels proposal described in section 3.2.4. Examples of these
resources are distributors, suppliers, sales director, and financial department.
51
Other resources describe objects used to perform the action but don‟t belong to the previous
types, e.g. fax, email, phone, paper, pencil, and calculator.
Lastly, the delegation field was only used when the registered action was transmitted to other
agent. This could correspond to any organizational level, i.e. person, dyads, group, or even
business unit.
Examples of common registered sentences were the ones describing orders update actions.
These were usually triggered by an email received from the supplier, informing the change of
order deliver date (e.g. Subject: Order State; Action: Inform; Human Resources: Supplier; Other
Resources: email). Once received, the employee changed that information in SAP LA menu
(e.g. Subject: Order State; Action: Update; Technological Resources: SAP LA).
One of the disadvantages related to the usage of this web form, was that there wasn‟t any way
to know if the human resources mentioned were acting as receivers or as senders. In the
previous example, the action was reading an email that informed a change in order deliver date.
However, the action registered didn‟t reveal if it was the supplier who sent the email, acting as
sender instead of receiver, as perceived by the record analysis. For this specific project, it didn‟t
have an important influence. Though, it can be easily fix by adding an option to the human
resources field indicating the role performed (sender or receiver).
As a cyclic approach, the set described above already contains all the normalized action,
resource, and subject types collected at the end of the task register period, three weeks. During
this period, the ethnography technique previously described was also applied in order to
increase the number of records. At the end of task observation/registration time, the repository
contained a total of 711 entries (226 observed and 485 registered).
8.3.4 Context Identification and Display
The application used to capture people‟s actions already included the context identification in an
explicit way. As mentioned before, the first field of the form was the subject, whose intention
was to capture context of the action performed. Consequently, it is possible to state that the
Portal developed provided a way to skip this step.
The context display was one of the other available functions in the application developed, but
this wasn‟t presented in a clear way. What the Portal offered was a menu where each person
could check all the registered tasks, grouped by day and sorted by the time (Figure 24). The
records were shown in a table whose columns were the corresponding field. Through this, the
diary contexts of each person were available in the Portal.
52
Figure 24. Portal functionality that displayed each person daily actions.
8.3.5 Context-based Analysis
The previous steps provided a structured and normalized action repository, labeled by contexts.
As mentioned before, the records included ethnography results, totalizing 711. This facilitated a
context based analysis of the registered actions, several have been done. These can be
categorized in three main groups: context rules, context switches, context-action diagrams, and
context-based optimizations. Each one is described further.
As mention before, normally people didn‟t register their actions after performing them. Thus, a
valid context switch analysis was not possible to do base on records. However, given the
initially defined goals for this project, this wasn‟t the type of analysis more relevant to acquire.
8.3.5.1 Context Rules
In order to accelerate the fulfillment of Portal‟s form, a semi-automatic mechanism was
developed. This was based on a context analysis that counted the most registered fields
sequence for each context. For example, when analyzed the “order state” context registry, the
most common fields were “update”, as the action, and “SAP (LA)”, as the technological
resource. Thus, after selecting in the form “order state” as subject, the field action change
automatically to “update”, the technological resource to “SAP (LA)”, and the others stayed
unfilled.
The sequence previously described was characterized as rules and were updated daily. When
correct, they simplify action register in two single steps: choose the subject, and press the
53
submit button. This took about 10 seconds. At the end of the register period there were 13 rules,
one for each context.
8.3.5.2 Actions Context-based Diagrams
Enterprise models are an efficient way to achieve OSA goals (section 3.1). These models only
provide a way to support generic agents‟ activities, resources and their relationship (Zacarias, et
al. b, 2007). However, this is not enough, there is still the need to represent some features,
such as: how each person does his work?, and what resources does he use to do it?.
Consequently, it will become easier to understand personal and inter-personal work practices,
and consequently use them for organization analysis, training, amongst many other
applications.
Motivated by the need of models to illustrate the registered information in order to answer the
previously stated questions, an effort has been done to represent each person tasks using
diagrams. This was a human process, and most of the steps required more awareness about
people‟s work than the provided by tasks‟ repository. However, action repository was used as
basis to create diagrams. The diagram creation process is detailed next.
The analysis started by creating a set with context actions registered by the same person. Table
4 illustrates a sample of Pedro Cabrita time ordered records for “new order creation” context.
The “new order creation” context, or subject, refers to all the tasks performed before an order is
created, and ends with sending the new order to supplier. Only a short set of actions is used in
order to facilitate the explanation.
Table 4. Sample of registered actions by Pedro Cabrita for “new order creation” context.
Id Subject (Context) Action Technological
Resources Human Resources Other Resources
a1 new order creation Print SAP (ZM30) None None
a2 new order creation Analyze SAP (ZM30) None None
a3 new order creation Create SAP (ME21) None None
a4 new order creation Inform None Supplier Email
Action set was precisely examined, in order to find relationships between the registered actions,
e.g. the sample of Table 4 starts with a “print” followed by an “analyze” action. After, resources
are considered. In the first two actions, Pedro Cabrita used only technological resources, and
they all refer to SAP menus. By using the same resource, and being a “print” action followed by
an “analyze”, these can be grouped as a “check needs” task.
Next action, a3, referred to a “create” verb using a SAP menu as technological resource. This
can relates to the creation of the “order” in the IS. So, we described the action as a “create new
order” task.
54
The last action, a4, states an “inform” action by “email”, concerning a “supplier” as human
resource. Even not knowing if the supplier acts as a sender or a receiver, through previous
actions it is possible to infer that he acts as receiver and this referred to a “send new order”
task.
As result of the previous analysis to Table 4, we proposed three different tasks: “check needs”,
“create new order”, and “send new order”. Once actions were correctly analyzed and associated
to tasks, a diagram was created. Figure 25 illustrates the existing flow between tasks, and the
associated resources to each one.
Pe
dro
Ca
brita
(Sa
les C
en
tra
l) Check Needs
Order Needed?Yes
No
SAP
(ZM30)
Send New
Order
Create New
Order
1 2 3
SAP
(ME21)
Create new order
Figure 25. Part of Pedro Cabrita “create new order” tasks representation.
Explaining the diagram above, the representation begins and ends with two circles, being the
more highlighted the final event. Each task is connected by directional arrows. These indicate
the direction of the flow, whose meaning is that “create new order” task is performed before
“send new order”. Usually, after analyzing needs there are two possible situations: or there is
the necessity to create an order, or there isn‟t, and nothing more is done in this context. This is
represented by a rhombus with the question “order needed?” between first and second tasks.
Resources are illustrated using small icons in their tasks, e.g. “send new order” uses “email”
that is demonstrated by an envelope. The author of the represented tasks is illustrated by a
horizontal pool with his name on the top.
Created diagrams were based on BPMN (section 4.4.2), however they present some slightly
differences. BPMN is a process oriented notation that, in a very succinct description, represents
business processes as a flow of connected activities, or sub processes. One of the main
reasons for choosing this language was the fact that it allows the representation of a task flow,
substituting BPMN activities by tasks. Another advantage of BPMN is the similar appearance
with flowcharts, usually familiar to business people.
The previous described example can be completed with more Pedro Cabrita‟s records in order
to provide a full representation of tasks performed to create a new order. New registers include
different contexts actions and are represented bolder than other ones.
55
Table 5. More complete sample of registered actions by Pedro Cabrita.
Id Subject (Context) Action Technological
Resources Human Resources Other Resources
a1 new order creation Print SAP (ZM30) None None
a2 new order creation Analyze SAP (ZM30) None None
a3 new order creation Print SAP (ZM26) None None
a4 new order creation Analyze SAP (ZM26) None None
a5 calculate products needs (provisions)
Calculate SAP (ZM26/ZM30)
Printed None
Rule, Pencil, Calculator
a6 products codes Unlock None Susana Pauleta None
a7 new order creation Create SAP (ME21) None None
a8 Product codes Lock None Susana Pauleta None
a9 supplier’s contacts Check None Excel (contacts.xls) None
a10 new order creation Inform None Supplier Email
The first two new records, a3 and a4, are similar to others previously analyzed, a1 and a3. The
only difference is the technological resources used, although they also refer to SAP menus,
“ZM26”. Thus, they can be related with the same task, “check needs”.
The next new register, a5, as its context name suggest, consists in the calculation of products
needs. This is done using the two previous printed SAP menus. We can name the task resulted
from this action as “calculate needs”.
A new context is also presented in activities a6 and a8, “product codes”. Here, the actions
registered, “unlock” and “lock”, makes its comprehension easier. In Moviflor‟s ERP SAP there
are some locked products, which mean that they cannot be ordered. Although, special
occasions occur and there are only two persons who can unlock these products. From the
record analysis it is possible to infer that Susana Pauleta is one of these persons, because she
is used a human resource in the lock action. The task proposed here is “lock/unlock product”.
Before informing supplier, in a10, Pedro Cabrita check his contacts in a Microsoft Excel © file
named “contacts.xls”. This is the last new action and was named “check supplier‟s contacts”.
The diagram that has resulted from the previous analysis is depicted in Figure 26. The
resources represented in Susana Pauleta‟s tasks were also result of her registered actions.
56
Ped
ro C
abri
ta Check Needs Calculate Needs
Susa
na
Pau
leta
SAP(ZM26/30)
Create New Order
Send New Order
Check Supplier’s Contacts
SAP(ME21)
Ruler, Pencil
Lock Product
SAP(ZM171)
Product Locked?
Product Locked?
No
Unlock Product
SAP(ZM171)Yes Yes
No
contacts.xls
SAP
(ZM26/30)
Create New Order
Figure 26.Tasks performed by Pedro Cabrita to create a new order.
Normally, during the case study it wasn‟t so easy to design diagrams from action records as
described before. Sometimes people didn‟t register actions in the right order, or try to put two
activities in only one form. Thus, in this stage all the previous tasks were hypothesis. That‟s the
reason why along the explanation when defining personal tasks it was done as a possibility. As
we will describe further, all created diagrams were presented and validated by each person.
8.3.5.3 Context-based Optimizations
The previously suggested diagrams, created through the context-based analysis of personal
actions provide an efficient way to reflect about personal and inter-personal tasks optimizations.
They illustrate people way of working using a simple representation can be easily understood by
people related to the business. However, these are not the only results that can be gathered
from action records. This section describes other analysis results used by Moviflor to
hypothesize optimizations. The following examples illustrate only a few of the optimizations
analysis done. The choice was based on the influence that they had when presented to Moviflor
sales department people.
One of the most important results analyzed was the records distribution by context (Figure 27).
Besides showings that mostly of the performed tasks were related to orders management,
which is a normal phenomenon in a sales department, a relevant fact was proven. The analysis
showed that, in average, confirming each order required at least the double of tasks needed to
creating it.
57
Figure 27. Moviflor records distribution by context.
When this chart was presented to Moviflor sales director, he was surprised: “this proof that we
need to find a way to optimize order confirmation process”. To understand the reason why so
many tasks were registered with this subject, a new analysis only based “order state” subject
was done. This aimed to present which were the most listed actions (Figure 28).
58
Figure 28. Most registered actions for “order state” subject/context.
Analyzing the chart above, it is possible to notice that “inform” and “update” actions have a
similar number of records, 27 percent and 28 percent, respectively. After them, “confirmation”
action is the third more registered action, distant from the other ones. Thus, it is possible to
conclude that “order state” actions are mostly associated with: (1) informing someone about the
state of an order; (2) updating order‟s state; and (3) confirm a pendent order. The optimization
proposal based on this analysis was to create a sales management web application allowing the
automatic change and check of order state by Moviflor people and suppliers.
The web application suggested was validated by the following analysis that illustrates sales
central communications (Figure 29). It showed that more than half of the communications done
were to suppliers (57%), and that most of them were done by email (47%). Confirming through
this supplier‟s ability to access sales management web application proposed.
Analyze8%
Update28%
Confirm22%
Inform27%
Ask15%
Most Registered Actions for "Order State" Subject
59
Warehouse
Suppliers
Sales CentralShopCategory Managers
69 %
3 %
28 %
43 %
17 %
40 %
70 %
30 %
23%
6%
57%
13%
Figure 29. Sales central communications.
Despite the fact that each record submitted had an associated hour, it wasn‟t possible to do
time based analysis. Usually people registered their tasks at the end of work periods, like before
coffee-break or lunch, instead of doing it after finishing them.
An important issue of the previously described analysis is that, like in any other study, the
validity of the results obtained depends mainly on the correctness of basis references. Thus, if
people register wrong tasks, or play a different role while observed, the results obtained are not
correct. Although, all the achieved results were presented to Moviflor project team and
successfully validated.
8.3.6 Context Integration
The context integration phase is described as a human process where are created enterprise
models that can be useful to the organization (section 3.3.5). These models can be used as a
tool to update other existing representations, to support the suggestion of changes, etc.
In this case study, Moviflor sales central performed this step by their own. Once all the
previously described diagrams were provided, describing personal personal and inter-personal
tasks, an internal meeting has occurred. This aimed to find a way to normalize the way people
work, in order to optimize their tasks. Unfortunately there wasn‟t an opportunity to capture and
represent the result. The only known fact is that people are making efforts to integrate their way
of working, using as reference the diagrams provided.
However, the simple fact that sales central team has performed this change, by their own, using
the diagrams validates their effectiveness in supporting context integration.
60
8.4 Visualizing and Validating Diagrams
During the description of the diagram creation process, some of the decisions taken were based
on hypothesis. Thus, anyone is able to validate the diagrams better than the person that it is
related to. In LEARN method (section 4.5.1) proposed by Jorge Coelho, there is a constant
concern in presenting the created models to people, in order to validate them. This is done
through meetings. Inspired in this method, a validation procedure was also applied during
Moviflor‟s case study.
As mention before, people used a web application to register their actions. Thus, instead of
using meetings to validate each diagram with every project person, a new functionality with this
purpose was developed.
Next to the “Check registers” menu option, a new one was added, “Diagrams”. Once chosen, it
presented a list with all the diagrams designed for that person. After selecting one, a brief
description and its diagram image was presented. Below the figure, a validation form was also
available (Figure 30).
Figure 30. Portal diagram validating form.
Each of the tasks represented in diagram had an associated number, allowing through this its
identification. The form was composed by a first “general observations” part, where each person
could point out generic errors associated with issues such as: missing tasks, wrong order,
wrong pool names, etc. This was followed by a section dedicated to each diagram task,
identified by its number and name, presenting two options: “Confirm” and “Modify”. These
indicated that task was correctly or wrongly represented, respectively. When selected the
“modify” option, there was an available free text field to write the reason why the representation
wasn‟t correct.
61
Every time each person validated a diagram, a new version was designed based on the
changes proposed in the form. This was an interactive phase until all tasks become confirmed.
The average number of versions created for each diagram was one (Annex A
Moviflor Inquiries).
One of the main advantages of this method was that it didn‟t require the participation of
diagrams‟ author. The validation usually occurred in the same day that they were published and
took only about 5 minutes to be done. This speeded up the process, and one week after the
registers stopped all the diagrams were validated and results presented to sales director.
Having all personal and inter-personal tasks illustrated by validated diagrams in a single place,
represented in a language understood by almost everyone, provides an important instrument to
enhance OSA. Some of the advantages of diagrams visualization are: (1) people become
elucidated about the roles they perform in the organization; (2) they facilitate understanding of
existing relations between the roles daily played by each person; and (3) they provide an easy
way to question unusualness, but disregarded, tasks performed every day.
8.5 Providing a Way to Define IS Requirements: Importations Survey
Once concluded the previous described study of Moviflor sales central individual and inter-
personal work practices, a new project have started. This aimed to capture importation‟s tasks
in order to further support them in Moviflor main IS, SAP R/3.
Importations organizational unit is responsible for the management of all transactions related
with out of Europe suppliers. This is composed by only two persons, a main responsible and an
order manager. Being such a small department, and completely work overloaded, the previous
applied approach wasn‟t appropriate. Thus, only interviews and ethnography were performed.
This project took about three weeks. The collected information can be divided in two main
groups: tasks and informational entities. Informational entities represent all the information that
is used along tasks execution, contributing though this to reach organizational business goals
(Sousa, et al., 2007).
Even not categorized as informational entities, when registering the used resources to perform
an action, sales central people were also providing this information. Although, being most part
of the tasks (aprox. 60%) already performed using SAP menus, the information used by each
task can be easily obtained analyzing these menus. In importations only 10 percent of the tasks
were already using SAP as a resource.
Tasks were once again registered in an organizational sentence way (section 3.2.1). They were
further manually analyzed and personal and inter-personal tasks diagrams were created (Figure
31). These used the same representation of the ones resulted from the context-based analysis
62
of sales central project (section 8.3.5.2). However, the diagrams created during this project
illustrate more relations with other organizational units than sales central ones. This was due to
more available information provided by a single and exhaustive interview and ethnography
approach.
Figure 31. Tasks performed by importations to manage containers deliver.
Validation process was also present in this study. Although, instead of using the Portal it have
been done through two one hour meetings. These consisted in presenting the printed diagrams
to both persons so they can confirm all the designed tasks and information by used them. At the
end, five diagrams have been produced and validated.
The report produced with the result of the studied tasks was very detailed. Being the main
propose to provide references for requirements definition purpose, every single pattern actions
performed by importations people were documented, e.g. “the verification of an invoice consists
in confirming each of its fields with Moviflor information about them stored in the initial order and
in supplier file”. An exhaustive description of each information used to perform each action was
also provided, e.g. all the columns names and descriptions of the Microsoft Excel © file used to
manage unconfirmed orders. This report was also read and validated by importations people.
The effectiveness of documented information can be confirmed by importations responsible
quote after reading the report, “…it‟s like our bible!”.
In order to create such a detailed document, EA principles have been applied. For its easy
appliance to every type of business, and its rastreability concerns, Zachman framework was
used as reference (section 4.4.1.1). The document created fulfilled almost every column of the
first two lines and provided matrixes relating cells, e.g. tasks x business goals; tasks x
informational entities.
63
In a research perspective this small project allowed to validate the utility of the performed
analysis and the created diagrams to support IS requirements definition. By referencing EA, it
also certifies Zachman framework proposals as an efficient way to describe an organization.
8.6 The Granularity Dilemma
During this case study many actions were collected and represented as what we have defined
as tasks. The conceptual difference between action and task can lead into a granularity
dilemma. In this study, task was considered as a group of one or more actions, generally
associated with the same context. An example, the actions “analyze needs using printed SAP
menus” and “create new order in SAP” represent the “create new order” task.
During the training period, a brief explanation of was given about what to register to people. The
advice given was for them to provide enough information that could allow the creation of tasks‟
models based on these. Another important suggestion was to never take more time registering
an action than performing it. Thus, what we needed weren‟t every single “click” in SAP
application, just the menu being used at that time and the context of its utilization.
As stated in section 3.2.4, the agent architecture can be applied in different levels, such as
individual, inter-personal, group and organization. Thus, using the context integration phase of
the previously described approach, diagrams can also be represented using these different
levels. Typically, these illustrations refer to process diagrams that are based in BPM concepts
described in section 4.
8.7 Best Practices
The success of this case study didn‟t depend only on the practice of the previously described
steps. It was also important to apply some best practices that contributed for people‟s
motivation. Concerning people as its main information resource, their enthusiastic participation
is a crucial factor when applying this approach.
The first step should always be clarifying project goals. In this project, the fact that it required
observing and registering daily actions, some people thought that it was an evaluation. After
correctly elucidated about our proposals, their dedication had changed radically.
Another important issue is to speak, as much as possible, people‟s language. Usually,
specialists have an inclination to use technical language. This should be avoided, an effort
should be done to use the same terms as the ones used by organization‟s people. This practice
is also valid when naming the designed diagrams.
As a last key best practice, we point out the rapid and constant publish of project analysis
results. Huge efforts have been done in order to update the information available in the Portal
64
used, almost daily. This could be some new context rules, new diagrams, or just an email with
average utilization records of each person. People‟s work is motivated by its results. Thus,
every time something was updated, number of registers increases drastically.
8.8 Conclusion
In this case study, we describe the approach followed in order to optimize Moviflor‟s personal
and inter-personal work practices. By modeling organization tasks using diagrams, and
involving people in their validation, it also proves to be an effective way to achieve OSA
ambitions.
The applied method combine concepts from different references described in Related Work in
Organizational Engineering section. However, the main contribution results from the
combination of: (1) information gathering techniques, providing a way to collect organization‟s
knowledge; (2) agent architecture and ontology, structuring organizational sentences (section
3.2); (3) the context based approach, suggesting steps to get and analyze agent‟s actions
(section 3.3), ; and (4) Jorge Coelho‟s LEARN method, by motivating the construction of
diagrams and validate them with people, even referring different types of diagrams (section
4.5.1).
Figure 32. Main steps of the applied approach in Moviflor‟s case study.
We can summarize the Moviflor‟s case study approach in five main steps: (1) interviews and
observations, (2) activity register, (3) context-based analysis, (4) creation of personal and inter-
personal task diagrams, and (5) diagrams validation. These steps and their relationship are
depicted in Figure 32. However, the previous steps were also supported by a constant Portal
update activity.
Interviews and
Observations
Action Register
Context-based
Analysis
Personal and Inter-personal
Task Diagrams Creation
Diagrams Validation
1Portal Update(New field’s options / Context rules)
Bootstrapping
65
Once all the context-based analysis diagrams have been done, and the resulting diagrams
validated, optimizations based on these were proposed. Some of the improvements were
suggested by us, others were proposed by Moviflor sales department people. This redesign can
be described as the reverse engineering of individual and inter-personal work practices
(Zacarias, et al. b, 2007). The whole methodology, including the redesign step is illustrated in
Figure 33.
Figure 33. Moviflor‟s case study approach.
The approach implemented can be also considered as a cyclic one. After redesigning
organizations models, new created diagrams can be used to explain people how they will do
their tasks in the future. This means that we perform the first cycle on organization „as is‟ state,
and after it, we can support the change for the „to be‟ state through the produced results before.
Once redesign is already functional, „to be‟ state will be the new „as is‟ and the approach can be
applied once again. This pragmatic will be broadly explored in the next case study (section 9).
When people see their tasks represented in the created diagrams they become more self-aware
about their role in the organization. More than once, people said “I would never remember this if
I have to describe my work” while analyzing diagrams. Usually these were so common tasks for
them that they will forget to refer them. A similar case happened when sales director were
analyzing diagrams, discovering unknown performed roles by sales central people. Thus, these
diagrams represent an important instrument to assist the achievement of OSA for every people.
Interviews and
Observations
Action Register
Context-based
Analysis
Personal and Inter-personal
Task Diagrams Creation
Diagrams Validation
Redesign
Proposal
1Portal Update(New field’s options / Context rules)
Bootstrapping
66
In what concerns Moviflor people‟s reaction to this approach, the inquiries speak for
themselves. Every person found the register form easy to use, and for 83% of them fill it only
took little time. Half prefer the action register manner of provide information, and the others
choose observations. Validated diagrams illustrate daily tasks in sales central for 67% of the
people, and in an optimization point of view, 67% classified our proposals as very useful, and
the others 33% as useful. Thus, we can conclude that from involved people perspective, this
approach represent an efficient way to capture their actions and further reengineer their tasks.
9 Supporting Inatel Change Management
The second case study was developed in INATEL, also named as National Foundation for
Happiness at Work. INATEL is a social services provider in the following areas: social and
senior tourism and thermals, free time occupation, culture, and sport. It is present in all
Portuguese continent territory and islands, with a network of 21 delegations and sub
delegations. The organization has about 250 thousand individual associates and 3500 collective
associates. Their social hotel network has 14 summer camps, three camping parks, three rural
touristic homes and two thermals, totalizing a global offer of 4 200 beds and many others
organizational, cultural and sportive infrastructures.
Currently INATEL is performing a drastic organizational restructure, which will result in the
change of almost all organization statutes. Consequently, this will also result in many business
processes transformations, affecting the organization widely. Additionally, administration use to
advantage this opportunity to carry out an IS renewal, consisting in the implementation of SAP
ERP.
The previously described changes will cause a significant impact on the way people are used to
work. Resistance to change is one of the phenomenons that tend to occur in this kind of
situations. Usually, these are associated with prejudicial errors triggered by processes collapse
that can lead organization into a delicate situation. In order to support change and avoid the
occurrence of uncomfortable stated situations, a change management department has been
created.
This case study objective was to provide a way to support this change management, using
some methods and tools successfully applied in Moviflor case. However, when the study
started, another related approach was already being applied for a few months. This was an
INOV project, administered by Professor José Tribolet and supervised by Eng. Carla Pereira, a
PhD researcher. Thus, some of the following described methods were already defined before
case study starts. These will be evidenced along the description.
67
More than produce reports with results, the major goal of this work was to transmit our
knowledge and experience to INATEL people. Thus, this was a deep project of OSA, aiming to
spread its principles to all organization so that in the future they can easily manage these kinds
of projects by their own.
The approach followed can be classified as a process-oriented one. This means that it was
mostly based on BPM principles (section 4). This project can be divided in two different main
parts, (1) modeling „as is‟, concerning the design of organization‟ current business processes,
and (2) provide a way to wonder about „to be‟, intending to provide a way to design the future of
previous modeled processes.
9.1 Modeling Inatel ‘As Is’
The process applied to represent INATEL‟s business processes „as is‟ was divided in three
different phases: (1) capturing personal actions, (2) defining business processes and its
activities, and (3) designing and validating business process diagrams. Each of these is detailed
next.
9.1.1 Capturing Personal Actions
The first step in INATEL approach was also capture personal actions. This was done similarly to
Moviflor case, using an action registering form. However, this form had some different fields, the
available ones were: date and time, action, subject, tools, documents, delegation. All these
were free text type. The reason for this was the number of completely different types of actions
concerned by this case. By being applied gradually to all organization, it was very difficult to
define a set of normalized contents for each field. However, this was considered as a future
possibility.
“Date and time” field was used to avoid the impossibility of analyzing actions based on this
information, when people didn‟t register actions immediately after performing them. Thus, in
these cases people indicated date and time when they had performed the action.
The description of personal actions, describing what each person was doing, was described in
the action field. Its purpose was to capture single actions, similar to Moviflor ones, with the
slightly difference of allowing more descriptive information, e.g. make a call to airline office. In
most part of cases, people wrote their actions in organizational predicates format (section
3.2.1), using a verb followed by a noun (e.g. contact administration, send approval).
The intention of subject field was to contextualize the action performed to a process. This can
seem a little bit confusing comparing this option objective to the one proposed by Moviflor form,
capture contexts, but it was very different. Briefly, a process is a set of actions that usually are
performed all along the organization units in order to reach business goals (more detailed on
68
section 4.2), e.g. “create new excursion” process intends to provide associates a wide variety of
available excursions. Process names are normally composed by an action verb followed by a
name, e.g. “contract animator”.
Tool field was where people described all the tools used as resources to perform action. These
could refer to technological (e.g. IS, Microsoft Excel ©) and non technological resources (e.g.
fax, phone, mail).
In order to facilitate the usage of the resource registered information, and to sustain another
parallel documental management project, action documents were registered in a different field.
As example, in the document field people mentioned minutes used, important internal approved
papers, and reports created.
Similar to Moviflor, a delegation field was used to indicate the name of people/organizational
units that gave continuation to the registered action, when that was the case. An example of this
field usage can be described supposing the action of “receiving a supplier purpose” by tourism
department. Once analyzed, there was a need send it to juridical department, in order to
validate juridical statements. The registered delegation noun was “Judicial Department”, which
could be completed with the name of responsible person to do it when available.
This form was already being used before this case study started, however this was done
through a formatted Microsoft Excel © worksheet. Thus, in order to accelerate and better
organize registering actions, a similar web application to the developed for Moviflor case study
was implemented. All previous registered actions were also migrated to Portal repository.
Figure 34 depicts the Portal web form implemented to register personal actions.
69
Figure 34. INATEL Portal action web form.
Currently, about 7400 personal actions have been registered using this Portal form, organized
by organizational unit. These actions analysis process was performed by people from the same
department and it‟s described next.
9.1.2 Defining Business Processes and its Activities
Once registered a substantial amount of actions, which depend on organizational unit
dimension, these were analyzed in order to define processes and its activities. This was done
by one or two elected people from each department. In order to assist this procedure, special
training was given to these people.
The first suggested step was to group actions by processes. To do this, there was only the need
to normalize process field, and sort activities by it (e.g. standardize action‟s processes names
“create new excursion” and “create new tour” to the same, “create new excursion”). After, each
action should be individually analyzed and ordered. The sort was done considering precedent
and proceeded actions, e.g. “send excursion to approval” should be after “define excursion
destiny”.
The previous action organization was a human process that could be supported by some
computer software tools. However, to do it, specific knowledge about each organization unit
actions and tasks flow was needed. This justifies one of the reasons why this procedure was
performed by INATEL people, instead of by external consultants‟ teams. The other motive was
70
the fact that this project goals were to expand OSA through all the organization, which was
inexplicitly done while people analyze and reflect about others person actions.
In order to facilitate personal actions analyzes, a check option was included in the actions
visualization menu. This allows the person, responsible for analyzing, to classify an action as
“read” or “not read”, and consequently filter their display by these criterions. An example of this
functionality is depicted in Figure 35.
Figure 35. Portal actions check functionality.
After actions were grouped by processes, activities were defined. The concept of activity used
was based on Sousa, et al. (2007), where activities are a set of actions, where entities perform
different roles, in order to reach goals, consuming and producing informational entities while its
execution. Activities were also registered using a form, initially in Microsoft Excel © format, but
furthermore they were migrated to the web Portal developed.
The available fields to describe an activity were: process, activity, description, documents,
intervenient or function, place or department, support tool, and periodicity. All these fields were
already defined before this study have started. It is also important to mention that some of them
were defined in order to answer Zachman‟s framework columns (section 4.4.1.1) relative to
“business model” row: “what”, “how”, “where”, “who”, “when” and “why”. The relation between
each field and columns is further depicted.
The first field, process, was used to write the name of the process analyzed. Examples of these
can be “create new excursion”, “sell excursion”, “create new book”, “sell book”, “organize sport
new challenge”, amongst other.
71
In the activity field was indicated the name chosen for registered activity. Example of these can
be “check hotels availability”, “check flights availability”, and “approve excursion”. The activity
was detailed in the description field, where more information about it was written. As example,
for the “check hotels availability” a possible description could be “contact hotels in Lisbon in
order to obtain their availability for the previously defined dates and correspondingly rates”.
Alike action form, all documents used to perform each activity were mentioned. In document
field people describe all documented information need during this activity. Examples of these,
for the “check hotels availability” activity can be: catalog of Lisbon hotels, minute used to ask for
hotels availability and rates, list of available hotels and practiced rates. The concept of
information entity was very important here, in the previous examples it‟s possible to group
documents as inputs or outputs. Inputs examples are “minute” and “list of available hotels”,
used to prepare a request and send it. Outputs are the results produced by the activity, in this
example the “list of available hotels with rates”. The answered Zachman‟s column by this field
was “what”.
Intervenient or function field was used to describe which people perform the activity and the role
played by them while doing it. As example, using the “check hotels availability” activity, the
intervenient people were “Ana Gomes” and “Isabel Saboia”. The role played by them was “hotel
responsible”. In order to define activities independent from people, because they can change by
several reasons, the most important information that should be provided here was the role
played, described as function. This field answered to “who” Zachman‟s column.
The place and department where the activity was developed was also indicated. This was done
in the field with this name, providing an answer to “where” Zachman‟s column. Examples of
these can be “tourism department of central office”, “financial department of camping park”, and
“reservations department of S. Pedro do Sul thermals”.
Technological resources, such as IS and Microsoft Office © software, were described in support
tools field. In INATEL there were plenty different IS specific to each department. As example,
tourism excursions were registered in “SCG”, accounting was done in “Baan”, among many
others.
The last field, periodicity, was used to state the frequency of the registered activity. As a way to
provide an answer to Zachman‟s “when” column, its analysis provide a way to understand if
they were frequent or irregular activities. Examples of its contents can be “weekly”, “monthly”,
and “yearly”.
The web form developed to support this form is illustrated in Figure 36.
72
Figure 36. Portal activity register developed web form.
9.1.3 Designing and Validating Business Process diagrams
The last step of the „as is‟ approach was to design and validate business process diagrams
using the previously defined processes. This was done using a representation proposed by
Eng. Carla Pereira in the aim of her research study and, as in Moviflor case study, this was
based on BPMN enterprise modeling language (section 4.4.2). In order to facilitate the
management of already represented activities, the check mechanism previously described for
action analysis was also provided in INATEL Portal. Currently, there are about 650 different
activities registered grouped in 70 different processes.
73
Tourism
Depart
ment
Create New Excursion
Check Hotels Availability
Approve Excursion
Send Excursion for
Approval
Create Excursion Proposal
Available Hotels?
Yes
No
Receive Excursion Approval
Approved?
Publish Excursion
Yes
Hotels
catalogMinute
Available
Hotels List
Excursion
Proposal
Excursion
Proposal
Approval
Letter
Excursion
Evaluated
Proposal
Available
Hotels List
SCG
Excursion
Proposal
Excursion
Proposal
Approval
Letter
Excursion
Evaluated
Proposal
President
Ana Gomes
(Hotel Responsible)Excursion Manager Excursion Manager Excursion Manager Excursion Assistant
No
Adm
inis
tration
Weekly
Figure 37. “Create new excursion” process diagram.
Business Processes were illustrated as a set of their activities, sequentially related by their flow.
Figure 37 depicts part of the previously mentioned “create new excursion” process. Process
name was indicated in the top of the figure. Each activity was represented by an individual box,
labeled with his name, e.g. “Check Hotels Availability”. Intervenient and function was shown
with a person figure tagged with person name, e.g. “Ana Gomes”, and its role “Hotel
Responsible”. The department where activities were performed can be understood by the
horizontal pool names, e.g. “Tourism Department”. Informational entities are divided in inputs
and outputs. Inputs are consumed information and were exposed above activity box, e.g.
“Hotels catalog”. Outputs are produced information and were displayed below, e.g. “Available
Hotels List”. The IS used was illustrated in “Publish Excursion” activity using a server image,
e.g. “SCG”. Periodicity was presented as a clock, exemplified in “Send Excursion for Approval”
activity. Decision points, such as “Available hotels”, are shown as rhombus.
Diagrams created illustrated organizational business processes. However, these weren‟t
utilizable until each person referred by them had validated this representation. So, similar to
what have been done in Moviflor, every diagram was available in the Portal for validation. Each
activity was identified by a number and displayed below the diagram with two options, confirm
or correct, this last one followed by a text field to write rectifications (Figure 38).
In this version of the Portal were provided more information about the diagram, such as its
current version, state (validated, or in validation), author, and history of revisions. In addition to
this, the „to be‟ design was also illustrated. This will be discussed in the next part of this section.
74
Figure 38. INATEL Portal diagram validation functionality.
As the considered concept of process suggests, they refer to organizational wide activities.
Thus, the previously described validation had to be done by all the different departments
illustrated in diagram. Initially, before the Portal became fully functional, this validation was done
in meetings, where people from both departments were present. The validation procedure was
to present the diagram and let people confirm the information represented. An interesting
phenomenon was noticed, people start to discuss „who does what?‟ and it was very difficult to
get an agreement.
The last quoted experience validates the need of OSA, and the importance of diagrams to
achieve it. The discussions occurred to decide in which department activities were done, denote
an incomplete awareness of each person role in organization.
75
9.2 Providing a Way to Wonder about ‘To Be’
Being this case study orientated to support change management, it becomes very important to
find a way to illustrate organizational processes „to be‟ state. One of the organizational change
problems is that people have difficulty to understand „what they will do in future?‟, and „how they
will do it?‟. Providing the answer to these questions was part of our goals.
Implementing a new ERP, as SAP, requires many process reengineering. This is caused by IS
restrictions that exist to maintain the integrity of information managed by them. Thus, SAP
documentation was used as a reference to design „to be‟ processes.
In order to represent „how processes will be‟, the representation used was similar to the
previously described to model „as is‟. However, activities that will change were highlighted. As
mentioned before, this information was also in the web Portal, available to everyone (Figure 39).
Figure 39. Relation between „as is‟ and „to be‟ process presented in Portal.
The figure above displays how the „to be‟ representation was accessed from „as is‟ process
diagram, and the relations between the activities order in different states. Curiously, the „as is‟
activity highlighted, and performed lastly, will be the first to do in „to be‟.
76
In addition to this, future procedures for each „to be‟ activity were also available in Portal, and
are depicted in Figure 40. The representation used is similar to flowcharts, but with every single
action illustrated.
Figure 40. Procedure list displayed for each „to-be‟ activity in Portal.
The real time access to this „to be‟ information, provided by developed Portal, allows
organization‟s people an answer their questions about „to be‟, avoiding through this a tool to
prepare themselves for the change.
9.3 Conclusion
In this case study many of the OE concepts have been applied to support INATEL change
management. By the fact that, contrarily to common projects, this aimed to teach people how to
develop and maintain an approach that could be managed by INATEL by their own, most of
OSA goals are correctly addressed.
The implemented approach concerned two main parts, an initial based on organization current
state, „as is‟, and a final based on the how organization will work in the future, „to be‟, after
performing the change. However, the objective is to apply it in a cyclic way. This can be
77
accomplished by switching „to be‟ state to „as is‟, and then start wondering about the new „to be‟.
As example, in this case study this is what will happen when change will be totally performed
and organization begins a new change, possibly towards process optimizations. Approach main
steps are depicted in Figure 41.
Figure 41. Brief representation of INATEL approach.
The effectiveness of the Portal developed to support this case study approach was also an
important achievement. Currently, it is being used in 5 departments, totalizing about 70 people
using it daily. Thus it is possible to state that we have created a way to store organizational
knowledge, and that INATEL is becoming a real time learning organization (Senge, 1990),
developing their people OSA and constructing a based foundation to easily managed current
and further changes.
Action Register Process and
Activities Definition based on
Action Analysis
Business Process Diagrams
Creation
Diagrams Validation
To Be analysis
based on documentation
Business Process Diagrams
CreationTo Be PresentationProcedures
Definition
As Is Presentation
New Cycle
Organization As Is
Organization To Be
78
CONCLUSIONS
“The more you learn the more aware you become of your ignorance”, Socrates
In this section we describe the conclusions achieved by this study. Firstly we present a brief
analysis of both approaches. After that, we analyze each of the initially defined goals and their
correct achievement is validated. In addition to this, we refer issues that were not considered,
and propose future work based on the attained results.
10 Proposing a New Approach
The main differences between INATEL and Moviflor case study are: (1) dismissal of a context-
based analysis; (2) non-creation of individual and inter-personal tasks diagrams; and contrarily
to Moviflor, (3) definition and design of organization processes and their activities; and (4)
design of organization „to be‟ state. Thus, it is possible to join both, providing through this a
complete bottom-up approach towards OSA.
Adding to the INATEL case study the context-based analysis of each person registered actions,
and the further creation of diagrams illustrating their individual and interpersonal work practices
based on them, will result on the desired approach (Figure 42). Applying it to an organization
will provide a way to capture and represent individual and interpersonal work practices, as well
as organization „as is‟ business processes. In addition to this, there are provided instruments
that allow organizations to prepare their change to future states, „to be‟, in order to decrease
some of the unpleasant incidents that are usually associated with these changes.
The proposed approach requires the involvement of organizational people since the beginning.
They are the only ones that are able to provide all the necessary information to make this
approach applicable. The facility that people had to validate task or process diagrams prove that
the representation used is easily understood. It is also while doing this that OSA is being
encouraged, by the fact that they see how their work is related to others and how it influences
the functioning of whole organization.
In order to accomplish real time issues and to easily share the organizational knowledge used
and produced during this approach a similar application to the one developed should be used.
The Portal had an important influence on the both case studies‟ successes. If we aim to supply
organizations with instruments that motivate their people awareness, cooperative tools like the
one used must be also provided. Only in this way can every single person can easily access
information in order to improve organizational self-awareness on their own.
79
As main disadvantage, we point out the resources needed to develop it. Each of the previously
defined steps requires human and time resources that usually are difficult to obtain in an
organization daily. However, it is possible to optimize some of the proposed steps through
recent research work that has been developed in this subject by the Center for Organizational
Engineering (CEO) of INESC-ID.
Figure 42. Approach proposed by merging Moviflor and Inatel case study results.
10.1 Relevant Contributions of the Developed Work
Apart from the methodological approach, the real value of this thesis is the fact that it demands
the involvement of organizational people. Commonly, during process surveys people are only
required to answer a few questions during interviews, and after results are published, to validate
them. In the developed work, people were constantly participating, by registering their diary
tasks and validating the created diagrams.
Another relevant feature of this approach is the fact that it demands people to synchronize the
model that they have about the organization that they work for, as well as, to start using a
normalized language to describe it. It is during the bootstrapping phase, when people discuss in
order to get an agreement about what subjects, actions and resources are important to include,
that our approach starts promoting OSA, obligating people to be conscientious about what they
do and how they do it.
Action Register Process and
Activities Definition based on
Action Analysis
Business Process Diagrams
Creation
Diagrams Validation
To Be analysis
based on documentation
and optimizations
Business Process Diagrams
CreationTo Be PresentationProcedures
Definition
As Is Presentation
New Cycle
Organization As Is
Organization To Be
Context-based
Analysis
Personal and Inter-personal
Task Diagrams Creation
80
The diagram validation phase was also an important step of the developed approach. Firstly, by
creating diagrams we had to define a fixed level of granularity, in order to create a coherent and
comprehensive representation of people‟s way of working. Then, by requiring people to validate
the represented tasks, including the ones were they are related with other people or
department, the developed approach gives people the responsibility about the results produced
with this work.
By requiring people to be involved since the beginning of the developed approach, and for being
a method created to be implemented by organization people by their own, without demanding
the presence of outside people like consultants, we can classify this methodological approach
as an approach for organizations to improve their people self-awareness by their own.
11 Conclusion
The capture of personal and interpersonal work practices in real time was done through the
usage of a context-based approach, supported by web forms, where each person registers their
actions in an organizational sentence format. Thus, in order to accomplish this objective,
concepts such as contexts and enterprise ontologies played a very important role. The
representation of the previously described work practices, in a way that every person in the
organization could easily understand, was also acquired through the usage of defined
enterprise models. These were all validated by each person represented in them, motivating
through this the spread of OSA by all organization units. In order to create these models BPM
related concepts have been used, namely enterprise modeling and Jorge Coelho‟s LEARN
method. Finally, in order to support organizational changes we propose the creation of models
illustrating its future state, „to be‟, and its relationship with the current one, „as is‟. In addition to
this, and to provide a usable enterprise knowledge repository, all the previously described
information was stored and available for every one by a collaborative developed application, a
web Portal.
Besides every single achieved goal mentioned above, our main ambition was to propose an
approach that could be used to improve people‟s awareness about the organization where they
work. By involving each individual person since the beginning, and requiring their intervention
on the validation of the produced results, OSA was correctly achieved. An example of this was
when Moviflor sales department people outlined a way to normalize their tasks on their own
accord, or when INATEL people sit to discuss which department was doing which activity.
81
12 Discussion and Future Work
Even with some successfully achieved results there is still a lot of work to do in this field.
Enterprise ontologies haven‟t been widely studied during this thesis. However, their importance
in describing what organization people do is clearly demonstrated, thus a deeper analysis of this
thematic should be addressed in order to optimize the capture of organizational sentences. Still
related with personal action capturing, developing a way to do it in an automatic way would be a
relevant advance to optimize the proposed approach. A possible solution could be the
development of an application that automatically proposes organizational sentences describing
the action that a person is doing in her computer. In the inquiry presented in Annex A we asked
people their opinion about the utility of this kind of application and the answers were extremely
positive.
In the modeling field some advances can also be achieved. Merging this approach with some
recently developed works by INESC-ID would allow the automatic creation of enterprise models
based on actions or activity descriptions. The same could be done to facilitate the analysis of
the „to be‟ organizational state. Recent theses analyze these concerns and provide ways to
easily relate „as is‟ and „to be‟ states.
The web applications developed for each case study were functional prototypes. Thus, a new
one should be created based on software engineering concepts in order to create an abstract
application able to easily adapt to different organizations realities.
Basically, there are many possible improvements that could be done in order to decrease the
number of manual activities that are part of the proposed approach. Once realized it will be
possible to apply it with little effort to organizations, promoting OSA and the creation of learning
organizations flexible to changes.
82
REFERENCES
Amaral, Luis, et al. 2005. Sistemas de Informação Organizacionais. Lisboa : Edições Sílabo,
2005.
Associates, Enterprise Management. 2000. Business Process Management: Managing IT to
Empower Business. 2000.
Blythin, S., Rouncefield, M. and Hughes, J. 1997. Never mind the ethno’stuff, what does all
this mean and what do we do now: ethnography in the commercial world. s.l. : interactions 4,
1997. pp. 38–47.
BPMG. 2005. In Search of BPM Excellence. Tampa, Florida, USA : Meghan-Kiffer Press, 2005.
Breton, Erwan and Bézivin, Jean. 2000. An Overview of Industrial Process Meta-Models. s.l. :
ICSSEA, 2000.
Button, G. and Dourish, P. 1996. Technomethodology: paradoxes and possibilities. s.l. :
Proceedings of the SIGCHI conference on Human factors in computing systems: common
ground, 1996. pp. 19-26.
Dewalt, Craig. 1999. Business Process Modeling with UML. UK : Johns Hopkins University,
1999.
EMA. 2000. Business Process Management: Managing IT To Empower Business. Boulder, CO,
US : Enterprise Management Associates, 2000.
Eriksson, Hans-Erik and Penker, Magnus. 2000. Business Modelling with UML: Business
Patterns at Work. s.l. : OMG Press, Wiley, 2000.
Fingar, Peter and Smith, Howard. 2003. Business Process Management: The Thrid Wave.
Tampa, Florida, USA : Meghan-Kiffer Press, 2003.
Frost, Stuart and Allen, Paul. 1996. Business Process Modeling. s.l. : Select Software Tools,
1996.
Genzuk, M. 2004. A synthesis of ethnographic research. s.l. : University of Southern California-
Center for Multilingual, Multicultural Research, 2004.
Goethals, Frank. 2003. An Overview of Enterprise Architecture Framework Deliverable.
Leuven : SAP-leerstoel, 2003.
83
Hammer, M. and Champy, J. 2001. Reengineering the Corporation: A Manifesto for Business
Revolution. s.l. : Allen and Unwin, 2001.
Harrison-Broninski, Keith. 2005. Human Interactions: How people really work and how they
can be helped to work better. Tampa, Florida, USA : Meghan-Kiffer Press, 2005.
Havey, Michael. 2005. Essential Business Process Modeling. Sebastopol, CA, USA : O'Reilly,
2005.
Holt, Jon. 2005. A Pragmatic Guide to Business Process Modelling. Wiltshire, UK : The British
Computer Society, 2005.
Hughes, J., et al. 1997. Designing with ethnography: a presentation framework for design. s.l. :
Proceedings of the conference on Designing interactive systems: processes, practices,
methods, and techniques, 1997. pp. 147–158.
Hughes, J., et al. 1995. Presenting ethnography in the requirements process. s.l. : 2nd IEEE
International Symposium on Requirements Engineering, 1995. pp. 27–34.
Hughes, J., et al. 1995. The role of ethnography in interactive systems design. s.l. : interactions
2, 1995. pp. 56–65.
Kotonya, Gerald and Sommerville, Ian. 1998. Requirements Engineering: Processes and
Techniques. s.l. : John Wiley & Sons, 1998.
Kuhn, Harald, Murzek, Marion and Bayer, Franz. Business Model Interoperability using
Enterprise Model Integration. Vienna, Austria : BOC Information Systems GmbH.
Laudon, K. and Laudon, J. 2006. Management Information Systems, 9/E. NJ : Prentice Hall,
2006.
Lemos, Vasco and Mesquita, Tiago Dá. 2006. UML 2.0, BPMN e Arquitecturas Empresariais.
Lisbon, PT: Instituto Superior Técnico, 2006.
Llewellyn, Nick and Armistead, Colin. 1999. Business Process Management: Exploring social
capital within processes. Bournemouth, UK : The Business School, Bournemouth University,
1999.
Malone, Thomas W., Crowston, Kevin and Herman, George A. 2003. Organizing Business
Knowledge: The MIT Process Handbook. Massachusetts, US : The MIT Press, 2003.
Marshall, Chris. 1999. Enterprise Modeling with UML: Designing Successful Software through
Business Analysis. s.l. : Addison-Wesley, 1999.
84
Rittgen, Peter. 2006. Enterprise Modeling and Computing with UML. Hershey, USA : Idea
Group, 2006.
Senge, Peter. 1990. The Fifth Discipline: The Art and Practice of the Learning Organization.
New York : Currency, 1990.
Sommerville, I., et al. 1993. Integrating ethnography into the requirements engineering
process. s.l. : Requirements Engineering; Proceedings of IEEE International Symposium on
1993, 1993. pp. 165–173.
Sousa, Pedro, et al. 2007. Enterprise Architecture Modeling with UML. Lisbon, PT : Idea Group
Inc, 2006, Chapter IV, pp. 67-94.
Telematica Instituut. 2002. State of the Art in Architecture Concepts and Description.
Archimate. [Online] 2002. http://www.telin.nl/NetworkedBusiness/Archimate/ART/index.html.
Tribolet, José. 2006. The end of two cultures: bridging the gap between "hard" sciences and
"soft" humanities. s.l. : IDC, 2006.
Uschold, Mike, et al. 1998. The Enterprise ontology: The Knowledge Engineering Review.
Cambridge University Press, Volume 13, 1998.
Viller, S. and Sommerville, I. 1999. Coherence: An Approach to Representing Ethnographic
Analyses in Systems Design. Human-Computer Interaction. 1999, pp. 9–41.
Zacarias, Marielba, et al. 2007 a. Towards Organizational Self-Awareness: An Initial
Architecture and Ontology. Berlin, DE: Lecture Notes in Computer Science: Springer, 2007.
Zacarias, Marielba, Pinto, H. Sofia and Tribolet, José. 2007 b. Reverse-engineering of
Individual and Inter-Personal Work Practices: A Context-based Approach. Context 2007, pp. ,
2007.
Zacarias, Marielba, Pinto, H. Sofia and Tribolet, José. 2007 c. Integrating Engineering,
Cognitive and Social Approaches for a Comprehensive Modeling of Organizational Agents and
their Contexts. s.I. : Context 2007, pp. 517-530, 2007.
Zacarias, Marielba, Rolo, David and Tribolet, José. 2007. A vez do Real Time Business. [ed.]
Inovar-te. Já Riu hoje. 5, pp. 56-59, 2007.
ZIFA. 2006. Framework Overview. The Zachman Institute for Framework Advancement.
[Online] 2006. http://www.zifa.com/.
85
ANNEX A
MOVIFLOR INQUIRIES
It is important to validate the usage of the proposed approach in real organizations. Thus, after
presented the results of the first case study, Moviflor people were asked to fill an anonymous
inquiry in order to provide their opinion about the developed work and its results. In addition,
Moviflor sales director, Dr. Luis Fialho, was also invited to answer some questions about the
results acquired by this study. Both results are described in this annex.
1 Sales Central People Inquirer
The following presented inquiry was answered by Moviflor sales central team, composed by 6
people. They were the ones that register their activities using the web Portal developed during
this thesis, and validate personal and interpersonal task diagrams created. For each question
are presented the list of available choices and answers.
Question 1: The introduction of registers in the Portal was:
a) Very Easy (100%)
b) Easy
c) Dificult
d) Very Dificul
Question 2: The introduction of registers took:
a) Less Time (83%)
b) Some time (17%)
c) Much time
d) Too much time
86
Question 3: The diagrams produced needed, in average:
a) Any validation (50%)
b) One validation (17%)
c) Two validations (33%)
d) More than two validations
Question 4: Order the information gathering techniques used, by preferred your ones:
a) Register
b) Interviews
c) Observations
Question 5: The results of this approach, represented by validated diagrams, illustrate the
reality of sales central diary activities:
a) Yes, completely (17%)
b) Yes, however in an incomplete way (49%)
c) No, only a few of the diary activities (17%)
d) No, it‟s too far from our reality (17%)
Question 6: How do you describe, generally, the optimizations proposed:
a) Very useful (34%)
b) Useful (66%)
c) Reasonable
d) Useless
Question 7: What is your opinion relating to the utilization of a program that, once installed in
your computer, proposes automatically the task performed and its subject:
e) Very useful (50%)
f) Useful (50%)
g) Reasonable
h) Useless
87
2 Sales Director Inquirer
In order to obtain a documented opinion of Moviflor sales director about the efficacy of the work
developed, special inquiries were prepared to him. The first one aims to evaluate the utility of
the achieved results. The second ambition was to obtain an opinion about the usage of some
context-based analysis results, represented by charts or diagrams. For each question the
available choices and the chosen answer are presented, in addition the second inquiry also
includes some comments done by Dr. Luis Fialho while seeing the presented results.
2.1 Usefulness of Achieved Results
Question 1: Having the numerical volume of actions related with subjects or specific resources
(e.g. order state) was:
a) Very useful
b) Useful
c) Reasonable
d) Useless
Answer: c
Question 2: Having the numerical interactions of sales central was:
a) Very useful
b) Useful
c) Reasonable
d) Useless
Answer: d
Question 3: The exploitation of individual work practices was:
a) Very useful
b) Useful
c) Reasonable
d) Useless
Answer: c
88
Question 4: The possibility to estimate the time spent in each subject would be:
a) Very useful
b) Useful
c) Reasonable
d) Useless
Answer: c
Question 5: The results of this approach, represented by validated diagrams, illustrate the
reality of sales central diary activities:
a) Yes, completely
b) Yes, however in an incomplete way
c) No, only a few of the diary activities
d) No, it‟s too far from our reality
Answer: a
Comment: a
Question 6: How do you describe, generally, the optimizations proposed:
a) Very useful
b) Useful
c) Reasonable
d) Useless
Answers: d
89
2.2 Usage of Context-based Analysis Results
In this inquiry an evaluation from 1 to 5 was requested, 1 means useless and 5 represents very
useful.
Personal Tasks Diagrams
Description: This diagram describes the existing flow of actions, illustrating the tools used by
each person while executing them.
Answer: 5
Observations: This diagram was extremely important to understand how each group element
perfom the same tasks using different resources.
90
Actions versus Subjects Diagram
Description: This diagram allows the representation of the predominant type of actions for
each subject.
Answer: 4
Observations: Through this diagram, once detected a huge volume of actions associated with
the “order state” subject, it was possible to understand the specific actions of this subject (e.g.
inform)
91
Subjects by Person Diagram
Description: This type of diagram shows the volume of actions related with each subject,
grouped by person.
Answer: 5
Observations: The huge importance of this diagram was because it allowed the detection of an
unusual situation i.e. the number of “order state” actions were the triple of the “new order
creation” ones. Being discriminated by person let me discover unknown aspects such as that
was Susana Pauleta that was responsible for update the publicity.
92
Resources by Person Diagram
Description: This type of diagram shows the communication resources used by each person.
Answer: 5
Observations: It was through this diagram that I understood that most of the existing
communications with suppliers are already done by email. However, there are still a
considerable number using the phone that I will try to reduce.