institut national polytechnique de grenobletollenam/...i would like to express my special thanks to...

INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE

N° attribué par la bibliothèque |__|__|__|__|__|__|__|__|__|__|

T H E S E

pour obtenir le grade de

DOCTEUR DE L’INP Grenoble

Spécialité : « Génie Industriel »

préparée au laboratoire GILCO (Gestion Industrielle, Logistique et COnception)

dans le cadre de l’Ecole Doctorale « OISP (Organisation Industrielle et Systèmes de Production »

présentée et soutenue publiquement

par

Hendrik BUSCH

Le 24/11/2006

Towards the re-use of knowledge in dynamic industrialization processes: Case study in the microelectronic domain

DIRECTEUR DE THESE : Michel TOLLENAERE CO-DIRECTEUR DE THESE : Mickaël GARDONI

JURY

M. Chris MCMAHON (University of Bath, Great Britain) Président M. Benoit WEIL (Ecole des Mines de Paris, France) Rapporteur M. Sandor VAJNA (Universität Magdeburg, Germany) Rapporteur M. Michel TOLLENAERE (INPG, France) Directeur de thèse M. Mickael GARDONI (INSA Strasbourg, France) Co-encadrant M. Patrick COGEZ (STMicroelectronics, France) Examinateur M. Franck DUPONT (STMicroelectronics, France) Examinateur

1

ACKNOWLEDGMENTS This thesis is the result of my work as a PhD student at the Advanced Research & Development – High Performance Logic & Derivates department of STMicroelectronics (Advanced R&D STM, Crolles-France) in collaboration with the laboratory GILCO (Gestion Industrielle, Logistique et COnception (engl: Economics engineering, logistic and conception)) at the INPG (Institut National Polytechnique de Grenoble, France). Many people supported me during the last 3 years and made the successful completion of this thesis possible. First of all, I would like to express my gratitude to the members of the dissertation committee for having agreed to evaluate this research work:

I would like to express my sincere thanks to Prof. Dr. Chris McMahon, Professor of Engineering Design in the Department of Mechanical Engineering at the University of Bath, England, who was not only willing to preside over the dissertation committee, but who previously also gave very interesting and stimulating feedback on my work during conferences.

I would like to express my special thanks to Prof. Dr. Benoît Weil,

Professor at ecole des mines de Paris, France, and researcher at “Centre de gestion scientifique”, France, for having agreed to review this work and to be a part of the dissertation committee.

I would also like to express my deep thanks to Prof. Dr. Sandor Vajna from the

University of Magdeburg, Germany, at “Lehrstuhl für Maschinenbauinformatik” (Chair of Information Technology in Mechanical Engineering) for having agreed to examine this work and to be a part of my dissertation committee.

Secondly, I would like to thank my supervisors for their scientific and industrial comments, supports and discussions:

I would like to express my gratitude to my advisor, Prof. Dr. Michel Tollenaere. His trust in my abilities greatly enhanced my performance in the projects we were working on.

I would also like to express my deep thanks to my second advisor, Prof. Dr. Mickael

Gardoni. His motivation and his patience gave me strong support. Even through the geographic distances between France and China, he always found the time to give me feedback and to discuss my work.

I would also like to thank Dr. Patrick Cogez (director of universities and external

relations at STMicroelectronics), industrial supervisor and initiator of this PhD thesis. He gave me a great view of relations, problems, behaviors and work methods at STMicroelectronics. Our discussions allowed me to develop a vision about

2

Knowledge Management and its implementation at STM, and also gave me the basis for this work.

I would also like to express my thanks to Olivier Demeure and especially to his

successor Franck Dupont (responsible for the IT department at STM Crolles). A very special thank you for their support, their ideas and for attributing the necessary resources as well as giving me the liberty to realize and validate the scientific concept with a software tool. Even if we have different opinions about change management and the conception of IT tools, our discussions were always very fruitful and stimulating and helped to improve the scientific and industrial part of this work.

I would also like to thank Prof. Dr. Yannick FREIN (Professor at the Institut National Polytechnique de Grenoble and director of the GILCO laboratory) for having accepted me on his team and for supporting me in my research project. A special thank you to all members of the EMA project. This project was a perfect training ground for my personal communication and, of course, networking skills. Thanks to all 300 actors involved, for their collaboration and support. I would like to specially thank those responsible of each of the 9 concerned different organizations for their support in validating my propositions and encouraging me to go further: Michel Varrot (Device and Yield Engineering director (DYE)), his deputy Anne Laffont and each manager of the technology generations in this organization for their support and belief: Stephane Hardillier, Loic Rolland, Jean-Francois Revel. A special thank you to their teams for using EMA and giving me a feedback.

Furthermore, Dominique Malgouyres (area director) and his deputy Christine Gombar and each manager of the area teams: Bruno Perrin (Photo), Sandra Lis (Metal), Olivier Renault (Implant), Romain Payet (CMP), as well as the section managers Mickael Troumelin (Implant and CMP), Caroline Archambeault (TT-WET) and Patrick-Jaques Martin (GSEC). Also special thanks to their teams, especially Photo, for using EMA and giving me feedback.

I would also like to thank Eric Moro, production manager and the manager of each production team of the 24/7 production shift: Equipe 1: Yves Abolafia, Equipe 2: Jean-Marie Hugonnard-Roche, Equipe 3: Pierre Ilinares, Equipe 4: Sandra Levasseur and Equipe 5: Vincent Bernard. Furthermore, I would like to express my gratitude to other involved actors who supported the work: Bruno Baylac (Process Control), Philippe Plunian (Quality), Martial Baudrier (Statistic). Also, I would like to thank Richard Fournel (R&D technology line manager) and Annie Tissier (technology program manager) and each manager of the technology generations in this organization for using EMA. And also a very special thank you to Bruno Gilles, Natacha Petter and Guillaume Brialon for their engagement and the development of the IT tool EMA.

Also a very special thanks to Thierry Rodriguez and Laurence Ginhac – key users for the EMA tool. Thanks for all their time, their tests, their motivation and their engagement to

3

motivate other team members and colleagues to use EMA. Their engagement allowed producing and implementing EMA at STMicroelectronics. EMA will hopefully be used at all ST sites all over the world in the future. Numerous other people supported my work. Particularly, I would also like to thank the members of the IT team: Pierre Beaufils, Anna Bisch, Julien Cognet, Antoine Dell-Accio, David Amar, Martial Fonti, and Guillaume Chezaud. Furthermore, I would also like to thank very motivated users who supported me with suggestions and clarification of problems and work practices (some of them very resistant against IT tools but very open for discussions and problem identification): Sebastien Desmaison, Baptiste Walgenwitz, Laurence Boissonnet, Veronique Rhetore, and Claire Guillon. Nathalie Gautier and Karen Pusceddu were always helpful in minimizing my administrative work. My parents, Gabriele and Rainer, and my sister, Mareike, receive my deepest gratitude for the many years of support and especially for always believing in me. Last, but not least, I thank my partner, Eglantine, for her love and understanding that strongly encouraged me and, in the end, made this thesis possible. September 2006, Grenoble Hendrik Busch

5

Knowledge is power. Sir Francis Bacon

(1561 - 1626) translation from

“Scientia est potentia” in “Novum Organum”, 1620

You can know the name of a bird in all the languages of the world, but when you're finished,

you'll know absolutely nothing whatever about the bird... So let's look at the bird and see what it's

doing -- that's what counts. I learned very early the difference

between knowing the name of something and knowing

something. Richard Feynman

(1918 - 1988)

7

CONTRIBUTIONS In the context of the microelectronic circuits’ fabrication, the objective of this work was the improvement of knowledge reuse. Therefore, the related knowledge management activities to the fabrication processes are analyzed and improved. First of all, an overview about Knowledge Management and its related problems and domains is given. In particular, the relation between Knowledge Management to humans and the context (i.e., work methods, environment, organization) IT is discussed. Implementation problems of Knowledge Management activities and systems into enterprises that need a human effort for the capitalization are discussed. Based on knowledge management and business process management concepts, a general knowledge management oriented analyzing approach, called PIFA (Process Information Functionality Analysis), is proposed to understand and formalize the knowledge and information flow related to business processes in the context of STMicroelectronics (STM) and its business rules, as well as the functionalities done by employees involved in these processes. The analysis approach delivers a knowledge and business process management framework for the conception and implementation of IT-tools supporting the knowledge, information and process flow. The PIFA-approach consists of three layers:

The general basic layer of a Process flow delivers a process model of the analyzed domain to build and formalize the dependencies between activities.

The Information layer delivers an information flow model of the analyzed domain and

allows constructing a domain ontology. Furthermore, the analyzed information flow will discover the information flow between tools AND people, between people AND people and between tools AND tools. Additionally, the goal of the information flow is to identify the three main phases of different knowledge management models (Create, Diffuse and (Re-) use and to associate it with the process flow.

The third layer analyzes the Functionalities done by an employee involved in the

business process. The goal is to identify these associated functions to the process and the information flow, analyze current problems and propose improvement possibilities. These improvement possibilities are important to overcome the possible human resistance against knowledge capitalization.

Even if these layers of analysis seem to be separated, the basis is the employee and his or her work related to these three levels (process-, information and function layer). Furthermore, the use of ontologies could be applied. Today, a domain ontology represents a specific point of view of one domain. In transversal processes (analyzed by PIFA), different domain ontologies could be used, depending on the involved organizations in the process. Therefore, current ontologies could be re-used and integrated in one process ontology, describing the relations between the information in a process. By integrating current ontologies into a unique ontology, the specific domain knowledge will be conserved and could be re-used to minimize the annotation efforts, as well as to minimize the effort of ontology maintenance, as changes in the origin ontology will also impact the new built process ontology.

8

The PIFA three-layer framework architecture allowed the analysis of the existing knowledge and process flow for the experiment processes at STM and also formalized needs and requirements for a better process, information and knowledge management support. Based on the analyzed requirements via PIFA, an IT tool is proposed, called EMA (Experiment Management Application), for better management and exploitation of processes and its associated written information content in teams, within processes (over-organizational-barriers sharing) and between processes (over organizational barriers). Indeed, actors need further support to exploit written information content to produce new knowledge in a more effective way and with higher quality. Current applications at STM, used in the domain of experiment management, don’t capitalize enough information related to the fabrication process and a reuse isn’t easily possible. They capture only positive results used to make an official change requests and track these changes of the fabrication process. With the EMA tool, information structuring and its association to processes and actions are supported via IT. The capitalized knowledge must respond to an identified user need, formalized by PIFA. The integration of capitalization is incorporated into daily work activities with the aim of obtaining intermediate results and therefore an intermediate return. The produced knowledge is therefore available for immediate use in the same process as well as in different processes. Furthermore, it is also available for future processes. In order to support the process flow and the reuse of knowledge, four modules are proposed:

A modularization and aggregation of information where the information visualization is adapted to a type of use instead of visualizing all produced information. Furthermore, a user has the possibility of access to all capitalized information during the process. A user has also the possibility of storing information related to his functions and annotates its work via predefined concepts or free-text annotations. In addition, information is stored and saved for further use.

A dynamic retrieval and visualization module where the user has the possibility of access to the produced information. The retrieval interfaces are built dynamically according to the already stored and used information for annotation.

A process-flow follow-up interface that could be adapted by each user to follow-up on different processes of his or her team, project members or interesting project.

A reuse functionality where the user has the possibility of assembling existing information and new information to do a similar experiment based on already done experiments.

The PIFA approach, applied to the context of experiment management at STM, delivers a model for the experiment process execution that is supported by the EMA tool. This tool, currently used by 300 employees, could be considered as one of the proofs that PIFA detected the needs and requirements for the experiment management. In conclusion, a framework approach for the combination of knowledge management and business process management is proposed in this thesis, as well as its implementation in a given context. The PIFA approach structures the process and information flow and their associated functions, and therefore helps to capture the practices, needs and requirements of a specific context. Furthermore, it supports the definition of a tool for a better process and information management as well as a better information exploitation of written information content.

9

READING PLAN Often, scientific work is done according to the following schema: Literature acquisition, Case study, Solution Proposition, Test & Validation, Generalization and Perspectives. Nevertheless, an industrial thesis starts with an industrial need for a given industrial context that can’t be solved with traditional approaches. Therefore, the TRIZ [Altshuller, 1999] approach to solving technical problems seems to be appropriated to be applied on the context of industrial problem solving with scientific approaches: Genrich S. Altshuller, the father of TRIZ, characterizes its approach as follows:

1. Problem identification and formulation 2. Concept generation and comparison 3. General solution 4. Specific solution embodiment

Furthermore, he gives suggestion for the application of TRIZ:

be a systematic, step-by-step procedure be a guide through a broad solution space to direct to the ideal solution be repeatable and reliable and not dependent on psychological tools be able to access the body of inventive knowledge be able to add to the body of inventive knowledge be familiar enough to inventors by following the general approach to problem solving

as illustrated in the following figure:

Figure 1: The TRIZ approach for technical problem solving (cf. 4 phases) [Altshuller, 1999]

10

According to the TRIZ approach, this work is structured in 6 main chapters:

1. Introduction 2. Context, problem, needs and current solution analysis 3. Literature acquisition and comparison of existing concepts and scientific solutions 4. General solutions: PIFA approach 5. Applied industrial solution : EMA 6. Conclusion and Perspectives

In the first chapter, a brief introduction about information and knowledge management, their importance and difficulties is given. In the second chapter (“Context, problem, needs and current solution analysis”), the context and industrial needs at STMicroelectronics for the experiment processes of lot fabrication are explained. Furthermore, current methodologies to support knowledge management activities during the experiment process are observed and evaluated. In addition, a closer look at existing tools supporting and handling written information content and sharing is done. This analysis confirms that the exploitation of written information content plays a significant role in the execution of processes; however, a successful combination and implementation could hardly be done with standard industrial approaches and solutions. This analysis leads to the description of the problem and its associated needs. In the third chapter (“Literature acquisition and comparison of existing concepts and scientific solutions”), a closer look at existing concepts and specific characteristics of the domains “Business Process Management (BPM)” and “Knowledge Management (KM)” is analyzed. The relationship between Knowledge Management (KM), Information Technology (IT) and humans, as well as human resistance and change management are discussed. Furthermore, types and characteristics of business process management are presented and the problems of handling dynamic processes. In particular, existing concepts and analysis methods and approaches for “knowledge intensive business processes” are discussed and evaluated and allowed expressing the general and abstract problematic of this work. In the fourth chapter (“General solutions: PIFA approach”), the PIFA approach is discussed to analyze and formalize needs and establish a work methodology for daily work activities by combining knowledge and process management activities. To this end, the PIFA approach proposes three different levels:

The process level that supports the formalization, analysis and generation of a generic process flow model.

The information level that observes how information is used in order to merge the right information to the right actions, and to establish a process domain ontology for the annotation of produced process information in order to facilitate the re-use backwards and between processes.

The functionality level that analyzes the requirements for the execution of employees functions and gives improving possibilities.

In the fifth chapter (“EMA: Applied industrial solution”), the conception of the Experiment Management Application (EMA) based on the PIFA approach is discussed. EMA is a tool that supports the process and information management of the experiment processes. The

11

implemented work methodology integrates the Knowledge Management activities in daily process work activities. The EMA tool, supporting this new work methodology, is therefore integrated into the current IT structure and can be considered as a “Meta-Crawler” by retrieving information from existing tools. Furthermore, problems of the change management and implementation, as well as a return of experience, are discussed. This tool is currently used by 300 employees. After a test phase, the tool was fully deployed in June 2006. Between June and October, 216 experiments were launched and impacted 533 lots for 484 concerned operations. 1280 different manipulations were managed through this tool. In the sixth chapter, a general conclusion completes this work and discusses limits and perspectives of PIFA and EMA: PIFA is an approach to analyze processes and related knowledge flows and should be applicable on different domains and contexts. EMA is a tool that is based on the PIFA results applied on the context of STM and covers therefore especially these specific needs.

To sum up, the following figure gives a synthetic overview of the different chapters. The TRIZ-structure (according to the TRIZ approach in figure 1) of the following figure represents the structure of this work.

On the left side (chapter 1, 2, 3), a context analysis and explication is given as to why direct industrial solutions are not completely successful. Based on this analysis, a problem literature acquisition and discussion followed that helped to clarify the problematic problem and define abstract general needs.

On the right side (chapter 4, 5, 6), the solutions are proposed. First of all, the PIFA solution is discussed. In order to deepen the identified and proposed concepts with a real case study, the EMA tool and its conception supported by PIFA is discussed.

Figure 2: Reading plan based on the TRIZ approach

The application and industrial context is the microelectronic domain where a specific vocabulary is used. Italic, underlined words in this work are explained in the glossary.

13

CONTENT

1 GENERAL INTRODUCTION ......................................................................................21

2 CONTEXT AND PROBLEM ANALYSIS ..................................................................23 2.1 Introduction......................................................................................................................23 2.2 Specifics of the microelectronic domain..................................................................23

2.2.1 Specific organization aspects of the R&D and the conception process............................. 24 2.2.2 Specifics of the conception process ........................................................................................ 26

2.3 The experiment conception control process: Special Work Request (SWR) .28 2.3.1 SWR description......................................................................................................................... 28 2.3.2 SWR process execution description ....................................................................................... 30

2.3.2.1 Experiment Request......................................................................................................... 30 2.3.2.2 Experiment Execution ...................................................................................................... 31 2.3.2.3 Experiment Analysis......................................................................................................... 32

2.3.3 Existing tools to support the process management and information sharing.................... 33 2.3.4 Current practices of SWR process and information management ..................................... 34

2.3.4.1 Current knowledge management practices .................................................................. 34 2.3.4.1.1 Capitalize and structure information ......................................................................... 35 2.3.4.1.2 Diffuse and reuse information .................................................................................... 36

2.3.4.2 Process Management practices ..................................................................................... 37 2.3.4.3 Processes managed as information objects................................................................. 38

2.4 Analysis of problems, needs and current solutions .............................................39 2.4.1 Problem observation.................................................................................................................. 39 2.4.2 Limits of current knowledge management practices............................................................. 42

2.4.2.1 Current knowledge management practices and problems ......................................... 42 2.4.2.2 Current process management solutions and problems .............................................. 42

2.4.3 Problem and failure synthesis of current solutions ............................................................... 43 2.5 Analysis of information flow in the experiment processes.................................44

2.5.1 The knowledge exchange between technologies for major and minor problems ............ 44 2.5.2 Places for knowledge management improvement possibilities........................................... 44

2.6 Goals of this work ..........................................................................................................46 2.6.1 Objectives.................................................................................................................................... 46 2.6.2 The Research Methodology ..................................................................................................... 47 2.6.3 Hypotheses and Industrial Problem ........................................................................................ 48

2.7 Conclusion .......................................................................................................................49

3 LITERATURE ACQUISITION .....................................................................................51 3.1 Introduction......................................................................................................................51 3.2 Knowledge Management Concepts ...........................................................................52

3.2.1 Knowledge and its different dimensions ................................................................................. 52 3.2.1.1 What is knowledge? ......................................................................................................... 52 3.2.1.2 What is Knowledge Management? ................................................................................ 55 3.2.1.3 Knowledge Management vs. Information Management ............................................. 57 3.2.1.4 History and future of Knowledge Management ............................................................ 58

3.2.2 Knowledge typologies................................................................................................................ 60 3.2.2.1 The nature type................................................................................................................. 61 3.2.2.2 The application type ......................................................................................................... 62 3.2.2.3 The source type ................................................................................................................ 63

14

3.2.3 Knowledge Management models ............................................................................................ 64 3.2.4 Knowledge Capitalization.......................................................................................................... 65

3.2.4.1 Knowledge capitalization aspects .................................................................................. 66 3.2.4.2 The importance of context............................................................................................... 66 3.2.4.3 Which knowledge to capitalize? ..................................................................................... 68 3.2.4.4 Annotate information ........................................................................................................ 70 3.2.4.5 The use of ontologies for annotation ............................................................................. 72

3.3 Practical aspects of Knowledge Management........................................................74 3.3.1 Knowledge retrieval aspects and the role of ontologies ....................................................... 74

3.3.1.1 Knowledge Retrieval aspects ......................................................................................... 74 3.3.1.2 Ontologies and Knowledge Retrieval ............................................................................ 75

3.3.2 Knowledge capitalization, human resistance and change management........................... 76 3.3.2.1 Human resistance............................................................................................................. 76 3.3.2.2 Different types of changes............................................................................................... 78 3.3.2.3 An approach for overcoming human resistance against change .............................. 80

3.3.3 Knowledge Management Systems supported by IT ............................................................. 81 3.3.3.1 Goals of Knowledge Management Systems (KMS) .................................................... 81 3.3.3.2 Use of Information Technology....................................................................................... 82 3.3.3.3 The implementation of Knowledge Management Systems ........................................ 83

3.4 Synthesis of Knowledge Management aspects and the need for integration in other domains...............................................................................................................................85 3.5 Business Process Management concepts...............................................................86

3.5.1 What is a Business Process?................................................................................................... 86 3.5.2 What is Business Process Management? .............................................................................. 88 3.5.3 History and future of Business Process Management ......................................................... 89 3.5.4 Characteristics of Business Process Management............................................................... 90 3.5.5 Types of Business Process Management Systems.............................................................. 92 3.5.6 Dynamic Business Process Management (DBPM)............................................................... 94

3.6 Practical aspects of Business Process Management...........................................96 3.6.1 Business Process Re-engineering .......................................................................................... 96 3.6.2 Business Analysis approach: Method H ................................................................................. 97 3.6.3 Workflow Management Systems ............................................................................................. 98

3.7 The current Knowledge Management practices implemented in Business Processes ....................................................................................................................................100

3.7.1 Observations of relations between changes in processes and information .................... 101 3.7.2 Relation of knowledge to business processes..................................................................... 102 3.7.3 KDML: Modeling knowledge in business processes........................................................... 102 3.7.4 Needs for the implementation of knowledge management practices in Business Process Management ........................................................................................................................................... 104

3.8 Proposition of the problematic .................................................................................106 3.9 Conclusion .....................................................................................................................108

4 GENERAL SOLUTION: PIFA approach to analyze knowledge intensive Business Processes.........................................................................................................109

4.1 Introduction....................................................................................................................109 4.2 A Knowledge Management Implementation Approach ......................................110 4.3 The PIFA approach - an analyzing methodology .................................................112

4.3.1 The different entities of PIFA .................................................................................................. 112 4.3.1.1 Core (Input, Functionality, Output):.............................................................................. 114 4.3.1.2 The return of experience ............................................................................................... 115 4.3.1.3 Context ............................................................................................................................. 115

4.3.2 The process and action level.................................................................................................. 117

15

4.3.3 The information level ............................................................................................................... 119 4.3.4 The functionality level .............................................................................................................. 122 4.3.5 The application of PIFA ........................................................................................................... 123

4.4 The application field and gain of PIFA ....................................................................125 4.4.1 Identification of different knowledge flow types by PIFA .................................................... 125 4.4.2 Using PIFA: Identifying the process dynamism based on information changes............. 126 4.4.3 Application field of PIFA .......................................................................................................... 127 4.4.4 Performance measurement of Knowledge Management activities .................................. 128

4.4.4.1 Suitable Performance Indicators for process treatment............................................ 129 4.4.4.2 Performance Measurement and analyzes of knowledge retrieval interfaces ........ 130

4.5 Using PIFA to construct an IT tool...........................................................................132 4.5.1 Application of PIFA for the IT domain ................................................................................... 132 4.5.2 IT infrastructure analyzed by PIFA ........................................................................................ 133 4.5.3 Functional and scenario analysis results for an IT tool ...................................................... 134

4.5.3.1 Functional and relation analysis ................................................................................... 135 4.5.3.1.1 Definition of the functions and relations ................................................................. 136

4.6 PIFA abstraction and application framework........................................................138 4.6.1 Entities ....................................................................................................................................... 138 4.6.2 Framework ................................................................................................................................ 139

4.7 Conclusion .....................................................................................................................142

5 INDUSTRIAL SOLUTION: EMA – an IT tool for managing the knowledge intensive experiment processes ...................................................................................143

5.1 Introduction....................................................................................................................143 5.2 PIFA application on experiment processes at STM ............................................143

5.2.1 Examples for three PIFA results for the experiment process analysis............................. 145 5.2.1.1 Process Level.................................................................................................................. 145

5.2.1.1.1 Abstraction of the three examples........................................................................... 146 5.2.1.2 Information Level ............................................................................................................ 147 5.2.1.3 Functionality Level.......................................................................................................... 149 5.2.1.4 Abstraction and synthesis of the SWR process analysis by PIFA .......................... 150

5.3 Specifications of Experiment Management Application (EMA) .......................151 5.3.1 Solution principle ...................................................................................................................... 151 5.3.2 UML model ................................................................................................................................ 154 5.3.3 Technical specifications and realization ............................................................................... 155

5.3.3.1 General features and re-use of an existing Workflow Tool ...................................... 155 5.3.3.2 Evolution of the existing workflow tool and developed architecture........................ 159

5.3.4 Technical infrastructure ........................................................................................................... 160 5.4 Use cases EMA..............................................................................................................161

5.4.1 Use cases for an experiment process execution................................................................. 161 5.4.2 Example for dependencies between actions (information flow and process flow) ......... 165 5.4.3 Knowledge Retrieval functionalities....................................................................................... 166

5.4.3.1 Reporting ......................................................................................................................... 166 5.4.3.2 Retrieval ........................................................................................................................... 166

5.4.3.2.1 Simple key-word search............................................................................................ 167 5.4.3.2.2 Experiment context search ....................................................................................... 167 5.4.3.2.3 Experiment detail search .......................................................................................... 168

5.5 Change management...................................................................................................169 5.5.1 Advantage of PIFA for change management....................................................................... 169 5.5.2 Opportunity Changes............................................................................................................... 169 5.5.3 Deployment and change monitoring ..................................................................................... 170

5.5.3.1 User resistance, management support and surplus value ....................................... 171 5.6 Measurement of gain and return of experiences .................................................172

16

5.6.1 Use of EMA ............................................................................................................................... 172 5.6.2 Return and gain of needed information flow management ................................................ 173 5.6.3 Return and gain of desired information flow management ................................................ 173

5.7 Conclusion .....................................................................................................................175

6 GENERAL CONCLUSION ........................................................................................177 6.1 Synthesis ........................................................................................................................177 6.2 Limits of PIFA and EMA ..............................................................................................179 6.3 Conclusion .....................................................................................................................181 6.4 Perspectives ..................................................................................................................183

7 APPENDIX ...................................................................................................................185 7.1 The microelectronic domain ......................................................................................185

7.1.1 STMicroelectronics: company and strategy presentation .................................................. 186 7.2 Organization Presentation: context of this work .................................................187

7.2.1 Device and Yield Engineering (DYE) - industrial product improvement .......................... 188 7.2.2 Area Engineering (Area) - Cleanroom engineering support .............................................. 188 7.2.3 R&D Engineering – R&D technology development............................................................. 188 7.2.4 Cleanroom – Production ....................................................................................................... 188 7.2.5 Computer Aided Manufacturing – IT support for cleanroom production .......................... 189

7.3 Characterization of Knowledge Management factors at STM...........................189 7.3.1 Organization.............................................................................................................................. 190 7.3.2 Technology................................................................................................................................ 191 7.3.3 Human factor ............................................................................................................................ 191 7.3.4 Culture ....................................................................................................................................... 192

7.4 Handling of Dynamic Business Processes............................................................193 7.5 The KDML language.....................................................................................................194 7.6 Knowledge Management models .............................................................................195 7.7 SWR process flow ........................................................................................................196 7.8 Use cases........................................................................................................................197 7.9 Additional screenshots of EMA ................................................................................199 7.10 Additional Statistics of EMA ......................................................................................202

8 Summary in FRENCH: Vers la réutilisation des connaissances dans les processus d’industrialisation: le cas de la microélectronique ............................203

8.1 Introduction....................................................................................................................204 8.2 L’analyse du contexte .................................................................................................205

8.2.1 L’ingénierie simultanée dans le domaine microélectronique : plus coopératif que collaboratif ............................................................................................................................................... 205 8.2.2 Le processus industriel de control de conception: Special Work Request (SWR)......... 206 8.2.3 Analyse de problèmes, besoins et des solutions existantes ............................................. 207 8.2.4 L’objective de travail ................................................................................................................ 207

8.3 L’acquisition de littérature .........................................................................................208 8.3.1 Le management des connaissances : concepts et définitions .......................................... 208 8.3.2 Les concepts de gestion de processus industriels.............................................................. 210

17

8.3.3 Les aspects de connaissance actuellement intégrés dans la gestion de processus industriels................................................................................................................................................. 211

8.4 L’approche PIFA – une méthodologie d’analyse .................................................212 8.4.1 Les différents entités de PIFA ................................................................................................ 212 8.4.2 Les trois parties de PIFA : Processus, Information et fonctionnalité ................................ 215 8.4.3 Le but de ces trois parties différentes de PIFA.................................................................... 216

8.5 Abstraction et synthèse de l'analyse de processus de SWR par PIFA ..........217 8.5.1 L’exemple pour des dépendances entre le flux d’information et le flux de processus dans l’outil EMA supportant les SWRs ......................................................................................................... 218 8.5.2 Fonctionnalités de recherche d’information ......................................................................... 219

8.6 CONCLUSION ................................................................................................................220

Bibliography .......................................................................................................................223

Glossary ..............................................................................................................................245

18

LIST OF FIGURES FIGURE 1: THE TRIZ APPROACH FOR TECHNICAL PROBLEM SOLVING (CF. 4 PHASES) [ALTSHULLER, 1999]..... 9 FIGURE 2: READING PLAN BASED ON THE TRIZ APPROACH ............................................................................... 11 FIGURE 3: CAUSES OF IT PROJECT FAILURES [BOEHM, 1981] CONFIRMED BY [INTERCHANGEGROUP, 2002] 22 FIGURE 4: IMPACTS OF CONCURRENT ENGINEERING FOR THE TECHNOLOGY DEVELOPMENT PROCESS ........... 25 FIGURE 5: WAFER, PHOTO FABRICATION PROCESS AND MICROCHIP.................................................................. 27 FIGURE 6: CROSS-SECTION OF A MICROCHIP...................................................................................................... 27 FIGURE 7: SPECIAL WORK REQUEST (SWR) - EXPERIMENT PROCESS ............................................................. 28 FIGURE 8: SPECIAL WORK REQUEST (SWR) REQUEST DOCUMENT .................................................................. 29 FIGURE 9: INFORMATION SYNTHESIZES BASED ON DIFFERENT POINT OF VIEWS ................................................ 31 FIGURE 10: INFORMATION TRANSFER FROM THE SWR DOCUMENT TO THE EXPERIMENT EXECUTOR .............. 32 FIGURE 11: EXISTING AND USED TOOLS TO SUPPORT THE EXPERIMENT PROCESS ........................................... 33 FIGURE 12: DIFFERENT USED INFORMATION STRUCTURES ................................................................................ 36 FIGURE 13: PROCESS FLEXIBILITY....................................................................................................................... 38 FIGURE 14: CURRENT PROCESS FOLLOW-UP BY A DOCUMENT MANAGEMENT................................................... 39 FIGURE 15: PROBLEM ANALYSIS.......................................................................................................................... 40 FIGURE 16: ANALYSIS OF KNOWLEDGE FLOW IMPROVEMENTS POSSIBILITIES .................................................. 45 FIGURE 17: DEFINITION COMPARISON OF DATA, INFORMATION AND KNOWLEDGE FROM [STUDER, 2003] ....... 54 FIGURE 18: COMPARISON BETWEEN INFORMATION AND KNOWLEDGE MANAGEMENT [GARTNERGROUP, 2002]

.................................................................................................................................................................... 58 FIGURE 19: SOURCE OF KNOWLEDGE IN ITS USAGE AND ITS FORM.................................................................... 62 FIGURE 20: “CYNEFIN” MODEL ACCORDING TO DAVE SNOWDEN [SNOWDEN, 2004], [SCHÜTT, 2004]............ 65 FIGURE 21: KNOWLEDGE DIFFUSION PROCESS [BUSCH ET AL., 2004A] ............................................................ 67 FIGURE 22: PRINCIPLE OF INFORMATION TRANSFORMATION VIA TOOLS [PMI, 2002] ....................................... 68 FIGURE 23: COMPARISON OF NEEDED CONTEXT FOR KNOWLEDGE OBJECTS INTERNALIZATION....................... 70 FIGURE 24: PRINCIPLE OF AN ONTOLOGY: THE MEANING TRIANGLE [ODGEN ET AL., 1923].............................. 73 FIGURE 25: EXAMPLE OF AN ONTOLOGY AND ITS POSSIBLE INSTANCE .............................................................. 73 FIGURE 26: SYSTEM OF KNOWLEDGE RETRIEVAL .............................................................................................. 75 FIGURE 27: MATRIX OF CHANGE MANAGEMENT .................................................................................................. 79 FIGURE 28: BALANCE BETWEEN RESISTANCE, MANAGEMENT SUPPORT AND SURPLUS VALUE DURING THE

TRANSITION CHANGE PHASE ....................................................................................................................... 80 FIGURE 29: KM TOOLS FOR DIFFERENT KNOWLEDGE SHARING ENVIRONMENTS [JOHANSEN, 1991] ............... 82 FIGURE 30: KNOWLEDGE META PROCESS FOR KMS IMPLEMENTATIONS [SURE ET AL., 2002], [SURE, 2003]84 FIGURE 31: FOUR PERSPECTIVES OF A BUSINESS PROCESS MANAGEMENT MODEL FRAMEWORK [ZHAO, 1998]

.................................................................................................................................................................... 90 FIGURE 32: A ROUGH CLASSIFICATION OF BUSINESS PROCESS MANAGEMENT SYSTEM [ALONSO, 1997] ...... 92 FIGURE 33: METHOD H TEMPLATE (INPUT, TRANSFORM, OUTPUT) [TURBIT, 2005] .......................................... 97 FIGURE 34: KNOWLEDGE RELATED TO BUSINESS PROCESS [MATA ET AL., 1999]........................................... 102 FIGURE 35: EXAMPLE FOR A KDML MODELING OF A SWR PROCESS.............................................................. 103 FIGURE 36: NEEDS FOR IMPLEMENTING KNOWLEDGE MANAGEMENT IN BUSINESS PROCESS ....................... 105 FIGURE 37: OUR METHODOLOGY TO IMPLEMENT KM ACTIVITIES [BUSCH, 2005B]......................................... 110 FIGURE 38: PRINCIPLE OF THE PIFA ANALYSIS [BUSCH ET AL., 2006B].......................................................... 112 FIGURE 39: PIFA TEMPLATE – PROCESS INFORMATION AND FUNCTIONALITY ANALYSIS [BUSCH ET AL.,

2006A], [BUSCH ET AL., 2006C]............................................................................................................... 114 FIGURE 40: EXAMPLE OF A PIFA RESULT ......................................................................................................... 117 FIGURE 41: EXAMPLE 1 FOR A GENERIC PROCESS MODEL CREATION.............................................................. 118 FIGURE 42: EXAMPLE 2 FOR A GENERIC PROCESS MODEL CREATION.............................................................. 118 FIGURE 43: EXAMPLE OF A PIFA RESULT AND THE DYNAMISMS BASED ON INFORMATION .............................. 120 FIGURE 44: EXAMPLE FOR AN ONTOLOGY: HIERARCHY BETWEEN CONCEPTS ................................................. 121 FIGURE 45: EXAMPLE FOR A COMBINATION OF ONTOLOGIES............................................................................ 122 FIGURE 46: EXAMPLE FOR A FUNCTIONALITY REQUIREMENT LIST .................................................................... 123 FIGURE 47: APPLICATION SCHEME OF PIFA ..................................................................................................... 124 FIGURE 48: APPLICATION OF PIFA.................................................................................................................... 124 FIGURE 49: INFORMATION FLOW IN BUSINESS PROCESSES .............................................................................. 125 FIGURE 50: INFORMATION MEASUREMENT FORMULA........................................................................................ 128 FIGURE 51: KNOWLEDGE MEASUREMENT FORMULA ......................................................................................... 129

19

FIGURE 52: RECALL FORMULA ........................................................................................................................... 130 FIGURE 53: PRECISION FORMULA...................................................................................................................... 131 FIGURE 54: NUMBER OF RELEVANT AND FOUND DOCUMENTS .......................................................................... 131 FIGURE 55: EXAMPLE FOR A PIFA RESULT: CURRENT INFRASTRUCTURE RELATED TO PROCESSES AND

INFORMATION FLOWS ................................................................................................................................ 133 FIGURE 56: SCENARIOS OF PIFA CONTEXT OF KNOWLEDGE INTENSIVE PROCESSES ..................................... 135 FIGURE 57: FUNCTIONALITY SCHEMA ................................................................................................................ 136 FIGURE 58: THE PIFA APPLICATION FIELD FRAMEWORK .................................................................................. 141 FIGURE 59: EXAMPLE FOR A PIFA APPLICATION: EXPERIMENT INSTRUCTION PREPARATION ......................... 144 FIGURE 60: IDENTIFIED ACTION TYPES OF THE SWR PROCESS ....................................................................... 144 FIGURE 61: EXAMPLE 1 OF AN ANALYZED SWR ............................................................................................... 145 FIGURE 62: EXAMPLE 2 OF AN ANALYZED SWR ............................................................................................... 145 FIGURE 63: EXAMPLE 3 OF AN ANALYZED SWR ............................................................................................... 146 FIGURE 64: GENERIC PROCESS MODEL FOR THE EXPERIMENT PROCESSES BASED ON PIFA RESULTS ......... 146 FIGURE 65: ANALYZED SWR INFORMATION FLOW............................................................................................ 148 FIGURE 66: INTEGRATION OF THE THREE LEVELS INTO ONE MODEL ................................................................. 151 FIGURE 67: PRINCIPLE OF TRANSFORMING THE SWR DOCUMENT .................................................................. 152 FIGURE 68: DESCRIPTION OF THE SOLUTION PRINCIPLE FOR EMA.................................................................. 153 FIGURE 69: SIMPLIFIED UML MODEL OF EMA .................................................................................................. 154 FIGURE 70: PRINCIPLE OF THE REUSED WORKFLOW TOOL APOLLO................................................................. 155 FIGURE 71: PROCESS VISUALIZATION FUNCTIONALITY ..................................................................................... 156 FIGURE 72: ACTION FORM STRUCTURED IN INFORMATION COMPONENTS ........................................................ 157 FIGURE 73: PRINCIPLE OF PROCESS MODEL AND GENERATED INSTANCES...................................................... 157 FIGURE 74: CONTENT REPORT SCREEN: SWR PROCESS AS INFORMATION OBJECT....................................... 158 FIGURE 75: ARCHITECTURE OF THE EMA TOOL ............................................................................................... 159 FIGURE 76: ACTION A1A: EXPERIMENT DEFINITION: EXPERIMENT DESCRIPTION AND ANNOTATIONS ............. 161 FIGURE 77: ACTION A1B: EXPERIMENT DEFINITION: SPLIT MATRIX DEFINITION AND ANNOTATIONS............... 162 FIGURE 78: ACTION A2 LOT ATTRIBUTION FOR THE EXPERIMENT .................................................................... 162 FIGURE 79: ACTION A3 & A4: EXPERIMENT INSTRUCTION PREPARATION AND VALIDATION FOR AN OPERATION

.................................................................................................................................................................. 163 FIGURE 80: ACTION A5: EXPERIMENT LOT TREATMENT FOR A PREPARED INSTRUCTION ............................... 164 FIGURE 81: ACTION A6: EXPERIMENT ANALYSIS .............................................................................................. 164 FIGURE 82: INFORMATION SEPARATED IN ENTITIES AND MERGE THEM TO THE RIGHT ACTION ........................ 165 FIGURE 83: REPORTING OF CURRENT SWR PROCESSES ................................................................................ 166 FIGURE 84: SIMPLE KEYWORD SEARCH............................................................................................................. 167 FIGURE 85: EXPERIMENT CONTEXT SEARCH ..................................................................................................... 168 FIGURE 86: EXPERIMENT DETAIL SEARCH ......................................................................................................... 168 FIGURE 87: USER STATISTIC: NUMBER OF VISITS AND HITS ON EMA ............................................................... 172 FIGURE 88: RELATION OF MICROELECTRONIC SIZES TO EARTH........................................................................ 185 FIGURE 89: MARKET CYCLE, TOTAL SEMICONDUCTOR 1986-2006, $ GROWTH RATE ................................... 186 FIGURE 90: STM SALES FIGURES, QI 2006...................................................................................................... 187 FIGURE 92: KNOWLEDGE FLOW IN PROCESSES ................................................................................................ 194 FIGURE 93: LEGEND OF THE KDML LANGUAGE................................................................................................ 194 FIGURE 94: COMPARISON OF KNOWLEDGE MANAGEMENT MODELS ACCORDING [FRANK, 2003] .................. 195 FIGURE 95: SWR PROCESS AT STM IN CROLLES AT ADVANCED R&D ........................................................... 196 FIGURE 96: ACTOR'S USE CASES....................................................................................................................... 197 FIGURE 97: ADMINISTRATOR’S USE CASES ....................................................................................................... 198 FIGURE 99: MAIN MENU OF EMA....................................................................................................................... 200 FIGURE 100: EXAMPLE FOR MY ACTION LIST IN EMA ...................................................................................... 200 FIGURE 101: ACCESS TO SPLIT INSTRUCTIONS VIA LOT NUMBER AND OPERATION FOR THE CLEANROOM ..... 201 FIGURE 102: DAILY USAGE STATISTIC OF EMA ................................................................................................ 202 FIGURE 103: HOURLY USAGE STATISTIC OF EMA ............................................................................................ 202 FIGURE 106: PRINCIPE D’ANALYSE PIFA [BUSCH ET AL., 2006B].................................................................... 213

21

1 GENERAL INTRODUCTION

This chapter gives a general introduction about this work. Knowledge Management is related to Information Technology (IT) and Knowledge Management approaches should improve, manage and filter the information overload.

Our society changed from being an industrial society to being an information society. Knowledge became the key economic resource, as Drucker points out: “The basic economic resource - the means of production - is no longer capital, nor natural resources, nor labor. It is and will be knowledge.” [Drucker, 1993]

Particularly in the semi-conductor domain, a very fast changing environment, where products change and could quickly become obsolete, resource knowledge plays an important role: The percentage of classical raw material decreases more and more as compared to the used knowledge as a resource for the production. Moreover, according to Bullinger [Bullinger, 2004], the production costs in the microelectronic domain are correlated with the resource knowledge up to 70 % (due to R&D activities), compared to 12% with the classical factor “man power”.

Knowledge is based on information (cf. section 3.2.1) and information production has grown faster and faster in the last few years. Berkeley studies in 2000 and 2003 (“how much information?”) [Berkeley, 2000], [Berkeley, 2003] detected a

“heavy information overload and fast growing: the world's total yearly production of print, film, optical, and magnetic content would require roughly 1.5 billion gigabytes of storage in 2000 (Equivalent of 250 MB per person for each man, woman, and child on earth) […]. The latest study into information growth estimates that 5 exabytes of recorded information were created worldwide in 2002 (equivalent to 800 MB for each person on the planet). […] Printed documents of all kinds comprise only .003% of the total. Magnetic storage is by far the largest medium for storing information and is the most rapidly growing, with shipped hard drive capacity doubling every year. […] It is clear that we are all drowning in a sea of information. The challenge is to learn to swim in that sea, rather than drown in it. Better understanding and better tools are desperately needed if we are to take full advantage of the ever-increasing supply of information….”

New tools are needed, but at the same time, the failure rate of IT projects is astounding. A study in the USA found that 31 per cent of software projects will be canceled before completion, and more than half the projects will cost an average of 189 per cent of their original estimates [StandishGroup, 1995]. According to Boehm [Boehm, 1981], the causes of

22

the failure are related at 56% to the need analysis. Latest studies [InterchangeGroup, 2002] confirmed these figures: “Unclear or incomplete definition of the business requirements is the greatest contributor to project failures. Moreover, these same figures were also heading the polls in surveys 20 years ago”.

Figure 3: Causes of IT project failures [Boehm, 1981] confirmed by [InterchangeGroup, 2002]

Furthermore, Business Process Management and its support by workflow tools have become increasingly important. During the execution of business process, knowledge is produced and used in order to build a final product or service. Processes are executed in parallel. These parallel processes could profit from knowledge management approaches in order to share and reuse knowledge.

Consequently, this thesis combines the aspects of knowledge and business process management according to the characteristics of the microelectronic domain. The experiment control processes at STMicroelectronics (STM) are analyzed, as well as existing methodologies and tools (chapter II). The goal of the work is the re-use of knowledge produced during the execution of these processes. Therefore, a closer look is taken at current knowledge management practices and concepts, as well as at current Business Process Management practices and the combination of both domains (chapter III). These current needs and requirements descriptions allowed the development of an analysis approach (PIFA) to formalize the requirements and needs for a more successful analysis of knowledge and process activities (chapter IV). The application of this analysis on the experiment processes SWR at STM allowed the formalization of the necessary aspects of designing an IT-tool (EMA) supporting the knowledge-intensive experiment process at STM. This tool was implemented and has currently been in use by 300 employees for 4 months (chapter V). This implementation allowed the detecting and finding of further research possibilities for the improvement of PIFA (chapter VI).

Needs analysis

56%Conception

27%

Others10%

Coding7%

23

2 CONTEXT AND PROBLEM ANALYSIS

This chapter gives a context and problem analysis of the industrialization processes at STMicroelectronics. These processes relate the conception with the production and are transversal and produce new fabrication information.

2.1 Introduction The industrial application of this work’s knowledge management approaches was made in a case study at STMicroelectronics (STM) (cf. a presentation of STM in appendix 7.1 and a presentation of involved departments in this work in appendix 7.2. In fact, the work was initiated by STM to improve knowledge management1 (KM) activities and the objective is to increase the reuse of existing knowledge during the conception process of new technologies. The first approach was therefore to find an application environment where knowledge management activities could be improved. Context analysis and observations led to the experiment control process (SWR – Special Work Request), which is one of the core processes to validate the conception of new technologies. Theoretical ideas are immediately tested in the microelectronic domain by a practical experiment. New knowledge about the fabrication is therefore produced, examined and validated via a practical experiment. In this chapter, the microelectronic industrial context and its characteristics are analyzed. Furthermore, the fabrication process of microchips is briefly explained and in particular the SWR process is detailed and analyzed. Additionally, current solutions (work methods, practices and tools) designed to optimize knowledge management activities and process management practices, their related needs and problems are characterized. Based on these characterizations, the relations between the produced and used information and its associated processes are examined. This primary analysis abstraction led to a reflection about identifying the places of knowledge management improvements. Based on the described facts, the industrial problem is explained, which should be solved via the TRIZ approach in this work and which initiated a deeper reflection on scientific concepts and works. 2.2 Specifics of the microelectronic domain The microelectronic domain is a rapidly changing domain where technologies become more and more complex and could soon be obsolete as new technologies appear. In the following sections, the microelectronic domain is explained.

1 Before discussing “Knowledge Management” in chapter 3.2, the “wikipedia” definition is used: KM refers to the range of practices and techniques used by organizations to identify, represent and distribute knowledge, know-how, expertise, intellectual capital and other forms of knowledge for leverage, reuse and transfer of knowledge and learning across organization.

24

2.2.1 Specific organization aspects of the R&D and the conception process One of the specificities of the microelectronic domain is that the products become increasingly complex and require the integration of diversified functions on the same chip, causing more and more options for design and manufacturing. This complexity extends the development time of the technological platform and implies the development of new manufacturing methods as well as design tools to take advantage of these new capacities. A technological platform - often called “technology” - represents the core fabrication process to produce microchips that contain basic components such as transistors or memories with a specific size. The innovation rhythm in the semiconductor industry demands a new technology every 2 years, meaning that a new development process is therefore launched every 2 years [Jovanovic et al., 2002]. The elementary components (transistors, memories, etc.) are 30% smaller than those of the preceding technology generation. The transistor size changed from 180 nm to 120 nm, then to 90 nm, and has now decreased to 65 nm. At the same time, the design of a technology is more time consuming, implying that an N+1 technology has to be launched before technology N has been finalized. A technology platform is therefore composed in the fabrication process (called route) and the specific design that represents the number of transistors or memories on a chip to produce a specific microelectronic product. Due to the increasing complexity of the technology, three major aspects changed in the last few years to limit a deadline drift for the platform development as illustrated in figure 4:

• Continuous time compression of the technology platform development process

As technologies become increasingly complex and the variety of technology options becomes larger, in order to cover the specific client needs, the development of the conception process takes more time or needs more resources. To guarantee the launch of a new technology every 2 years, the conception processes will be analyzed and optimized in permanence. The conception process also includes the development of a fabrication process for the new technology. Therefore, fabrication processes are permanently analyzed and optimized. An optimization could be the use of a more efficient machine (less time consuming, higher capacity, etc.), a new raw material (new cheaper material, less consuming material, etc.) or a new fabrication recipe (new fabrication process step).

• From a sequential engineering towards a concurrent engineering Even if the previous technology hasn’t been finalized yet, the following technology development will be launched. As the fabrication processes of the two technologies have some aspects in common, changes that will be made for one technology could also impact the other technology. Therefore it is necessary to exchange information in this concurrent engineering environment between the different technology generations during their development.

• Dependencies between resources and development problems and gains As different technologies will be produced at the same production line, they will be produced on the same machines and production capacities will be shared: Additionally, as some technologies have common aspects as functions, memories, etc., some fabrication conditions on a machine (called operation) could be similar or even the same. The result of the concurrent engineering is therefore that changes for technologies (an operation or a machine) could impact the fabrication of more than one technology.

25

Therefore, generation development must be agile in order to adapt and learn from experiments of other technology generations [Busch et al., 2005a]. Specific machines and fabrication methods are only used for a short time. During the lifecycle of a technology, the fabrication process can be changed and adapted to the new conditions, meaning that even a “stable” industrialized technology fabrication process for industrial products will be changed. Validated new fabrication conditions for a technology can also be beneficial for an older one. Changing conditions could affect different technology generations. Therefore, it could be beneficial to initiate and improve the information sharing between technology generations.

Figure 4: Impacts of concurrent engineering for the technology development process

The conception process to develop a final industrial technology (technology platform and technology fabrication process) takes an average of 5 years. As shown in the figure above, technologies are launched in parallel and a technology generation is sub-divided into three teams:

R&D2 process development team that designs a new fabrication process CAD3 development team that designs the logical and memory functions of the chips DYE4 engineering team that industrializes the products

The indicated three teams (R&D process development, CAD development, DYE Engineering) interact with each other to guarantee the profitable development and industrialization feasibility concerning the following points: 2 R&D: Research and Development 3 CAD: Computer aided design: in STM context: design tools and development 4 DYE: Device and Yield Engineering

26

• Reliability in determining product characteristics (R&D process development) • Feasibility of technology’s realization (R&D process development) • Design tools and development (CAD development) • Industrialization of a technology, ever-increasing quality and improvement of

manufacturing processes (DYE Engineering) As technology generations are developed in parallel, the given fabrication context concerns all current technologies as explained below:

o Operation - a fabrication process (fabrication route) determines the way a technology and its products are fabricated. A route is therefore structured in a specific execution of operations. Each operation determines the conditions for a process on a specific machine of an area. The routes for different technologies and products aren’t completely disjunctive. Therefore, the same operation could concern different technology fabrication processes, even if a fabrication route is specified for each product of a technology and contains the sequence of operations to produce this specific technology product.

o Machine - a microchip is produced on different machines. Therefore, the same

machine can also be used to produce different products and technologies. Changes on a machine can also impact different technologies.

o Technology - two different technologies can have common aspects as the same

operations and machines used can be used for different technology fabrication processes. Changes for one technology could therefore concern other technologies.

In the clean room – the fabrication chain- the microchips are produced on silicon wafers. 25 wafers are batched in a lot5 – a box that circulates between the different machines.

2.2.2 Specifics of the conception process One of the microelectronic specificities is the number of interactions between the conception and the fabrication process during the development: Once a new concept idea is determined by mathematic models or theoretical reflections, it will immediately be tested to validate the idea and verify the industrialization capability. Therefore one or more wafers will be used to test the new fabrication process conditions depending on these new ideas. The results will determine the following steps in the conception progress and show capability limits for the technology platform development. The following figure shows a silicon wafer (on the left side) used to produce the microelectronic circuits (on the right figure) on it. The fabrication process is composed of different operations; i.e., the operation “photo mask” during the process (figured in the middle) consists in “burning” a picture of the desired connections between different transistors (functions) of a microelectronic circuit layer on the silicon wafer for each circuit. A distinction is important between design conditions (i.e., the type of mask or layer image to burn on the silicon wafer) and process conditions (duration, light intensity, etc., to guarantee an optimal image on the wafer). 5 English: Batch, A number of wafers processed as a group. The French word “Lot” is used even in English expressions at STM.

27

Figure 5: Wafer, photo fabrication process and microchip

Several technology fabrications need up to 214 different operations to build up the final product and the fabrication can take up to 7 weeks. The basis layer of a circuit contains the different transistors to guarantee a certain performance of the chip: memory, speed, etc. The upper layers contain the connections between the transistors to connect different transistors to guarantee the logic functionalities of a circuit. This principle is illustrated in the following picture (see figure 6), showing a microchip in a cross-section representing the different layers of a microelectronic circuit:

Figure 6: Cross-section of a microchip

As shown, the layers are very similar, but the connections are different for each layer. This implies that the process conditions of an operation are the same or very similar, and only the design conditions (type of mask) change for each layer. Infact, in the cleanroom, there are only 6 different fabrication areas. Each area executes a specific process operation. The lots circulate in the cleanroom between the different areas. There is no fixed physical fabrication chain to coordinate the lots’ way. Two lots in the same area, physically waiting to be processed on the same machine, could be on the 100th fabrication operation, representing

28

the 2nd layer, and another lot could be on the 180th operation to produce the 5th layer. The circulation between the different areas is coordinated via a manufacturing execution system (MES). This system contains and coordinates the fabrication route for each lot. The operation used in a route is unique and valid for all routes. The operation numbers vary from 1000 to 9000. To validate new ideas and test new fabrication conditions, experiments called SWRs (Special Work Requests) are carried out. 2.3 The experiment conception control process: Special Work

Request (SWR)

2.3.1 SWR description As already mentioned, in the microelectronic domain theoretic conception ideas are immediately tested through an experiment. Therefore, an experiment request will be written and executed to test the new fabrication conditions. The request for a fabrication process experiment is called a Special Work Request (SWR). Once the involved people have discussed and validated their ideas (in formal and informal exchanges like meetings, email, presentations, etc.), they determine the process fabrication conditions that will be tested on the machines. No formalization of the SWR process exists. It seems that the process is a very short process with only a few actions and therefore no formalization is needed. It can be considered as shared implicit knowledge about the process execution. To clarify the process, interviews were done with involved process actors to formalize the process and to understand the responsibility of each actor, as well as the work method used to execute the process. The interviews were done with 5 engineers (SWR process owner) and each took between 30 to 60 minutes. The analysis showed that the experiment request produces a SWR document. Based on this document, the experiment is executed with specified conditions for the operations. At each requested operation, a manipulation of the fabrication process is done. Intermediate results, such as measurements, are produced and written down in results documents. The third action is the analysis of the experiment. The result and the analysis is written down and stored within the SWR document.

Figure 7: Special Work Request (SWR) - experiment process

1. Action: Request document: request document, actor: DYE, R&D 2. Action: Experience document: results documents, actor: Area, Production 3. Action: Analyze document: final SWR document, actor: DYE, R&D

29

The first process analysis showed that the process has three main phases. As the experiment process is related to the production process, the process could change due to occurred problems. Therefore, the process or some actions have to be executed again as shown in the figure above. Therefore,

following actions, process duration, or the number of concerned operations and involved persons

could change during the process execution and depend on the obtained intermediate results and on the related production process. These experiments could be considered as agile and dynamic processes that have to be adapted to local and current process environments. Nevertheless, the experiment process can be considered as linear as there is always the same action flow that will be executed; but “back loops” are possible to redo the same work with other conditions. On the other hand, the action “experiment execution” has a lot of process branches in parallel, depending on the number of concerned experiment operations, and therefore also on the number of involved persons (same action for different actors). The illustrated SWR process on figure 7 flow is the 4th part of the context description (see figure 4) and explains the manufacturing part of the technology fabrication. Changes of the fabrication process could be initiated by a R&D or a DYE engineer, an area engineer will configure and prepare the machines for the experiment and the cleanroom operator will execute it. The SWR document is based on a template that could be divided into three different parts as described and illustrated below:

Figure 8: Special Work Request (SWR) request document

The first part (categorization) can be considered as a standardized description where the SWR process will be characterized by predefined categories and values, such as i.e. “nature” or “purpose” classification. Additionally, free text descriptions help to refine the goal of the experiments as well as expected problems, etc.

30

The second part (experiment information and process) contains the “Split Matrix”. The concerned operations of a fabrication process are listed in this matrix with their conditions that are tested. The matrix represents on one hand the physical experiment condition for each operation (experiment information), as well as the experiment process, as it determines how many people are involved in this experiment, as one area engineer is responsible for one operation. The third part (experiment results) of this document represents the result of an experiment such as measurements, yield analysis, etc., to approve or disapprove the tested fabrication conditions. The experiment process and the number of involved actors depend on the number of concerned operations. This is between 2 and 15. If problems occur, such as a lot scrap6 or bad intermediate results as particles on the wafer, or significant differences between measurement and expected results, etc., the experiment will be executed again. Therefore, cycles in the process execution exist. The duration of an experiment can’t be determined. In the best case scenario, it takes as long as the lot fabrication of 7 weeks and the time for the analysis of one week. But if problems occur, experiments could take more than 1.5 years as processes could have different cycles. The management of the SWR experiments is described in the following section.

2.3.2 SWR process execution description The completed interviews allowed understanding and following-up the practices done to execute the SWR process. The current process practices are described in relation to the three action types (Request, execution, analysis) identified in the previous section. 2.3.2.1 Experiment Request The experiment requests are discussed during meetings and sometimes have to be validated by the management and other organizational procedures before they will be executed. The SWR document will be written as a work document based on the SWR template, where the goal of the experiment, the split matrix, etc., are defined. Then information from the MES about current lot in the cleanroom will be consulted and lots will be reserved for the experiment. To reserve a lot for an experiment, on one hand, the lot will be held at the concerned operation for the experiment in order to treat the lot with the experiment conditions instead of the standard operations conditions of the associated route. Secondly, an Excel table is used to fill in all used lots. Before attributing a lot to an experiment, the lot number has to be compared with the existing lot numbers in the table. Another excel table is used to obtain an incremental SWR number for the new experiment. In this table, some keywords, the involved areas and the purpose must be explained. Furthermore, each actor has a Word document or excel table to manage a process’ follow-ups about current lot positions, executed actions, etc. This document is also updated and the written SWR document is

6 A decision statement that a product that does not comply with the legal, statutory, contractual, technical requirement etc., cannot be used or recovered after reworking and must be destroyed.

31

distributed by email to all involved actors who are directly concerned and who might be interested, and the actors who will interpret the requested experiment. 2.3.2.2 Experiment Execution Each actor is interested to view the information concerning his work: i.e., each area engineer is responsible for one operation and needs the information about experiment conditions for this operation. This can be considered as filtering the non-useful information or as an information access according to a specific point of view, as illustrated in the following figure:

Figure 9: Information synthesizes based on different point of views

As shown in the figure above, an actor may only be interested, for example, in information parts I7 and I2 and will ignore the other information. In large documents, it will be difficult to access the pertinent information. Based on this information, experiment instructions are prepared. The requested experiment conditions are complemented with recipes and machine information for the concerned operation. For each lot and each operation, instructions are generated. Some areas use spreadsheets to re-create a split-matrix concerning only one operation and one lot. Therefore, the same information is copied several times into different spreadsheets as illustrated in the figure below (figure 10). Other areas don’t use standards or templates: the information is copied in one excel document that contains all experiments with the associated instructions and concerned operations. Some areas transfer the instructions directly by email or over the phone. The generation of one instruction document per lot and operation is illustrated on the following figure:

32

Figure 10: Information transfer from the SWR document to the experiment executor

Furthermore, the hold positions for the lot in the MES are verified. Once the lot has been treated and the experiment is executed, results reports are written and will be sent to the DYE engineer. The produced information can be written in a new document as well as written in the received SWR document, which will be updated with the new information. To sum up, every actor has a different competence and a different perspective in the process flow and therefore on the process and the process information. Actors base their work on the SWR document, but will apply or reuse only the information concerning their action. 2.3.2.3 Experiment Analysis The results on lot treatment will be collected by the DYE engineer. He will interpret the several different results in order to determine if the experiment was positive or negative. If the results were positive, a final document about this positive conclusion will be written. Then the results are distributed by email to the involved actors, and stored on the shared file server or intranet portal. Furthermore, to adapt the technology route to the new fabrication conditions, a procedure will have to be completed in order to change the fabrication process definitely for the concerned technology. Therefore, an ECN (Engineering Change Notice) tool will be used. Information (redundant to the SWR document, like purpose, technology, operation) is filled in to initiate a change request. These three phases are supported by IT tools as described in the following section.

33

2.3.3 Existing tools to support the process management and information sharing

The execution of an experiment process is supported by different tools to prepare and execute the experiment and changing the process flow fabrication of a lot as described in the previous section. Different tools are used, but no direct link exists between them. Information will be copied by a process actor from one tool to another. Therefore, information will be redundant in other tools. The following figure illustrates the previously explained experiment process – divided in 3 parts: Request, execution, analysis (cf. section 2.3.1) and the used tools in each part as described in section 2.3.3:

Figure 11: Existing and used tools to support the experiment process

To sum up, the following tools are used to support the execution of the process: Collaborative work is supported by:

Tools to exchange information - Telephone - Email - MES - ECN - Intranet portal

Tools used in a collaborative work

- Microsoft Word - Excel - PowerPoint - Shared network file server

34

- Project.net - 8D

Process follow-up is realized manually, supported by:

- Microsoft Word (reporting document, analysis, conclusion, etc.) - Excel (follow-up, used lots overview, launched processes overview, etc.) - PowerPoint (short synthesis of a lot) - Windows Explorer (to structure the information per process) - MES

Different tools are available to support the execution of the experiment processes, but no centralization and support is available to connect the information. Furthermore, even if tools offer functionalities and request certain information to fulfill, the way tools are used depends on each user. This is especially true for collaborative tools as groupware. These tools already support first approaches of process and information management as explained in the following sections.

2.3.4 Current practices of SWR process and information management The activities surrounding an experiment process invoke different competencies of people. The first model of an experiment process shows that the process is executed in a predefined order. The process has collaborative aspects as people have to exchange information and validate the experiment that will be executed. The goal of this work is to improve the knowledge management activities for the experiment processes. Therefore, during the executed interviews, the current solutions to improve the knowledge management and the process management, as well as common aspects and its problems, in particular were analyzed:

Current knowledge management solutions Current process management solutions Aspects of processes managed as information object

2.3.4.1 Current knowledge management practices Current applied knowledge management practices based on information management are explained in this chapter7. In the Information Management and Knowledge Management domains exists a variety of different Management Models, adapted to different domains and to different utilization goals (cf. section 3.2.3, cf. appendix 7.6). The following analysis is limited to the main aspects and goal of this work:

Capitalize and structure information Diffuse and reuse information

7 The notions Information and Knowledge management and their common aspects and differences are explained in section 3.2. At this time, a distinction isn’t necessary as it is part of this work to understand the use of these notions in a given context.

35

2.3.4.1.1 Capitalize and structure information An actor may be involved in different process executions at the same time. Therefore, he has to change between the different processes and keep the right information context to apply it to the right process and to do its work. He interprets information, produces new ones or modifies existing ones. Depending on the priority and difficulty as well as the formalization request from the management for an experiment, new produced information could be implicit, a short note or presentation, up to a complete document. Currently, the experiment request should be written as the split matrix and the experiment results should be written, but there is no rule in which format information has to be produced. However, in approximately for 80% of the SWR, the template is used. The interviews and observation showed that employees do not formalize the information during the experiment. Once the work is finished and the results are interpreted, the final conclusion will be written. Actors involved in a process will handle and structure received information for immediate or later use and reuse. Information will be structured within documents, within folders, or within a shared network. This implies that the information has a digital material form. The information is structured if there is an interest to keep it for the future (judged by employees). Three different structure types are currently used to structure information related to the SWR:

Individual structure: each process actor structures the information that he needs for its work or that represent an interest for him on a personal structure. He will therefore structure the information on his point of view to retrieve them quickly for later (re-) use.

Collective structure: each actor depends on an organization and works in a team. To

share information between organizations, a collective structure, which everybody is used to, could help to share information. This is especially important if employees leave the organization before their work is finished and their produced information isn’t easily accessible to their colleagues.

Process structure: with a transversal collective structure - in our case, of an

experiment process, - three different types of actors depending on three different organizations are involved. As each organization has a different collective structure, a process structure will be used to share process information between actors.

These different structures are separated and employees will store the same information in different structures as illustrated by the following picture:

36

Figure 12: Different used information structures

These information structures are physically separated, but the values used to describe the information seem to be similar in the different structure types. 2.3.4.1.2 Diffuse and reuse information The information produced during the SWR process, such as intermediate results, as well as the final SWR document will be diffused between process actors and be used within the same process. The goal of this work is for this information to be reused for other processes. Therefore, information must be retrieved not only within the processes but also across the organizational barriers (between different processes and different departments). An actor uses his or her accessible information resources (tools, organizational network, and personal network) for information diffusion and retrieval, which can be done in different ways:

An actor can use and reuse new information by receiving it. Currently, the newly launched experiments will also be diffused by email to people who might be interested. An actor gets information from a colleague by email or during meetings at the coffee machine, etc. The information is therefore pushed to the actor, but the retrieval of the information might be occasional.

An actor can also reuse information by search and retrieval. Currently he asks a

colleague or searches in the shared information structures (described collective structure (see previous section)). He pulls information from different tools or persons.

An actor can get or transfer information in a written form. He writes documents

about experiment requests, in-line measurements, expected behavior or results. These documents are in the classical Microsoft office formats (Word, PowerPoint, Excel and Outlook), which support the formalization and formatting of the information.

An actor could also share information in an oral form. For example, he discusses

information during meetings, at the coffee-machine or over the telephone. As STMicroelectronics has installed a DECT8 system, a lot of information is discussed and shared over the telephone. This system allows contacting people at any time, even

8 DECT – Digital Cordless European Telephon – internal Telefone mobil System within an Organisation.

37

during meetings. The advantage is that people are always available, especially for an emergency. The disadvantage is that information is often exchanged only in an implicit way and could therefore not be reused as such information is difficult to access.

As information is always sent by email and no synthesis is supported, restarting work on an experiment takes 30 minutes to look for already received and produced information as well as to understand the context. There is no effective way to reuse the already produced reports of previous years or experiments. The reutilization rate could be up 5-15% of produced experiments according an engineer’s opinions: An engineer knows that a problem could be similar to a problem that already occurred in the past. He could probably reuse his results, but the current experiment management approaches don’t support a reuse and collecting information for a possible reuse is too time-intensive. 2.3.4.2 Process Management practices An involved actor executes actions to continue the process flow. No process management tool is used to support the execution of these experiment processes. Each actor shares action-to-do-lists and has to make sure that actions are executed and has to respect the defined due dates during meetings, by email or over the phone. However, the process flow can change at any moment as problems can occur. Therefore, the process owner has to define the new process flow and inform the actors about changes and redefine their work. The process management is based on information where the information explains the experiment execution. The analysis of the SWR process flow (cf. section 2.3.1) showed that the number of involved actors depends on each experiment’s context and conditions. An area employee is responsible for preparing the experiment conditions for one operation. Therefore, the process actions and process structure depend on the content of the defined experiment:

Number of concerned operations = number of parallel process branches

The SWR process has no fixed common structure as each process instance can be different and concern a different number of experiment operations.

Additionally, problems which occur might also influence the process flow, as the flow has to be modified or parts of the processes must be executed again. The process flow is among other items based on information:

Changed information causes a repetitive execution of actions The information related to an action can change The changes could occur at any time as they are related to the production process

(MES)

This first process management analysis showed two different important aspects of the management practices:

The process management has process flexibility during its execution: Occurring problems can initiate a re-execution or change in the process flow

38

A process instance depends on the executed experiment. The process instance flow

will therefore be different for each experiment process as illustrated in the figure below.

Common aspects are:

Each process has a different structure, No unique, fixed, common, predefined process structure can be built for these

processes as the process depends on the real data used for the processes (number of operations), and

Changes can occur at any moment, before or during the process execution, as illustrated in the following figure:

Figure 13: Process flexibility

2.3.4.3 Processes managed as information objects The combination of Process Management and Information Management implies handling processes as information objects. Processes are used to execute different actions in a predefined order. During the execution, information is produced in each action. The collection of all produced information can be considered as one process information object that has different parts. In a process flow, employees work on the same process to produce a good or service. Therefore, they will base their work on the work of previous actions in the process flow, and also on previously produced information and knowledge. In this context, the SWR document could be considered as an information object as it is changed and updated according to results from different SWR process actors. Each actor wants to access the information concerning his or her work. These different kinds of view points to access and to visualize the process information aren’t only necessary for content information (cf. section 2.3.1), but also for contextual information describing the kind

39

of process and the follow-up for already completed actions, due dates, missing information, occurred problems, etc. Currently, a simple process management is realized by email or telephone and no supporting tool is available. A follow-up isn’t possible, as only the experiment request is formalized and the final document containing the results is diffused later. Therefore, it is difficult to follow-up the process flow, especially in a time period from 7 weeks to 1.5 years. Currently, process follow-up could be considered as a black box, as there is no transparent information accessible for every process actor, as illustrated in the figure below. To get this information, a process actor has to call the process owner or other involved process actors.

Figure 14: Current process follow-up by a document management

Actors would like to know how the process has evolved and if it is already finished. Typical information types used for a process follow-up are: i.e. short description, due date, priority, involved actors, recent problems, etc. The process follow-up can be considered as shared information: Every process actor needs it to be able to organize his or her work. The problems related to the current practices of knowledge and process management are explained in the following sections. 2.4 Analysis of problems, needs and current solutions

2.4.1 Problem observation Based on the process and information analysis of the previous sections, the observed problems are summarized in this section. Many different tools are used to communicate, write down the experiment request, follow-up the process flow and secure the process execution. Currently, there is no link between these applications. A lot of functions could be improved and supported via better IT functions. This causes obsolete data, and makes a follow-up very time intensive to update data collected from the different application. Often, theses updates aren’t done, so processes aren’t followed up. For urgent projects, a delay is recognized by the concerned employees, but it cannot be anticipated. For non-urgent projects, a delay is often not recognized. Furthermore, as a process follow-up isn’t available, employees will call the experiment analyzer to ask about project evolution because no information centralization is currently accessible for all involved process actors. As data aren’t updated, the update must be done by retrieving the information in different tools. This action is time intensive. Another problem is the redundancy of information. As everyone is informed by email with an attached document about experiments coming due, the same document is used as a basis for daily work and it evolves accordingly. Therefore, different versions of documents exist and circulate between the involved persons. The project owner is in charge of analyzing the different versions and trying to extract a current valid version.

40

There is a network file server to share documents, but because of access right problems, employees prefer to send documents by email. Furthermore, the process seems to have only a few actions, but a lot of functionalities are done within each action. Since it is not clarified as to which functionalities have to be done and who has the responsibility for which action, some work is either executed twice or never done at all. As there is no coherent information flow or implemented process flow between the employees, judgments are made by each actor and failures or problems are often only recognized at the end of a process. These described problems are synthesized in the following list:

FACT: PROBLEM: Information stored in different tools (redundant information)

Information incoherence Missing links between information Missing overview / synthesis Collecting information for a process can

take 30 min No access to experiment Information retrieval isn’t easy

Neither content nor follow-up No access to different points of view

Process isn’t formalized No common process structure Actions are forgotten Responsibility isn’t clarified Actions are executed twice No process knowledge about dependencies,

action order No synthesis of actions to do, no action plan

Actions are forgotten and not executed

No process synthesis is available, process execution isn’t controlled

Experiments are executed and prevent executing other experiments even if the expected gain is not very high

No clean-room visibility Time lost by connecting to the MES and checking lot positions one after one.

No visibility about problems of the lots No visibility about wafers scrap of a lot

during the fabrication process Missing automation of functions Time lost to set administrative information

in the different tools Produced information is sent to employees who might be interested

Information overflow for non-concerned people

Information missed by people not chosen as recipient

Figure 15: Problem analysis

41

During the observations and interviews, needs were also defined by the employees for a better process management and its related information:

• Needs : capitalize, centralize, structure, share

o Centralize the information To have all “important” information Have an efficient information retrieval method Structure the information To improve the visibility about completed work (follow-up) To improve the exchange of intermediate information Project management: resource allocation, priority planning

o Different degrees of information synthesis (different point of views)

Global vision, per person, per week, per organization Action information to execute a action in a process Process information as informative follow-up

o Better information management

Collect the information easily Know the right interlocutor for an operation or technology Know the dependencies between operations of experiments

(fabrication constraints/influences) Deliver the right information and the right synthesis to the right

employee at the right time as well as reuse the existing information Support the daily work, not a better document sharing process Notify about information changes Get results and intermediate results Information access by different viewpoints (technology, area,

operation, etc)

o Better information sharing Better and faster reuse (access) to existing information Have a better synthesis

o Better process management

Have a personalized action plan Clarify and secure the process flow execution Better process management related to a better information management

as the processes are very knowledge intensive Better process follow-up Support the process flexibility

o Better information management about process information

Have a follow-up Different reports Manage the dynamic aspects Project planning, priorities and workflow

42

These problems and needs reflect the limits of the current knowledge management solutions that are explained in the following section. The heterogeneous use of different applications in the context of the experiment management context causes some limits for knowledge management solutions as explained in the following section.

2.4.2 Limits of current knowledge management practices Different solutions and approaches exist already to optimize the SWR process management and the associated knowledge management aspects, and were explained in the previous section. In the following, these aspects are summarized: 2.4.2.1 Current knowledge management practices and problems Different tools have already been developed to support the information sharing and validation between teams. The intranet portal should contain all produced information and facilitate the information exchange between teams and within the company. In the past, only one department used this tool to share the SWR documents over this tool. Furthermore, the content structure of the document as well as given contextual information depends on the author of the SWR document and there is no obligation to fill in all requested information. The access and information retrieval to these documents offers two different methods: access within a navigation tree by a predefined navigation structure or a keyword search within the document. The use of the intranet tool is a first step in the knowledge management activities, but only the SWR document is stored, if the document is finalized. Furthermore, the SWR document is only produced for positive results. The knowledge capitalization of all produced knowledge is still missing and the knowledge retrieval possibilities are insufficient. Furthermore, the tool ECN is used to initiate new changes of fabrication routes. Therefore, the final SWR documents will be stored in this tool and different values from predefined categories will be selected to characterize the content. The management validates the stored documents and the change request. After validation, the changes will take place and will be implemented in the production chain (technology routes). The predefined categories of the ECN tool are also used for information retrieval. Therefore, this tool is also a good step into the experiment knowledge sharing. However, the use of the tool has shown that employees often don’t correctly complete the document. The categories aren’t obligatory and the full text explications of the experiment goal are often barely explained. Therefore, the management refuses change requests because of misunderstanding problems. Additionally, the information retrieval isn’t effective, as the categories are often not fulfilled. Furthermore, the ECN tool only capitalizes the positive experiment results and the implemented changes. 2.4.2.2 Current process management solutions and problems The current experiment process management practices are based on information exchanges via email or over the phone. First approaches to improve the process management and the information centralization of all information related to the experiment were done by an IT tool (called project.net). This tool allowed an online-sharing of project plans, assigned actions to employees and produced information centralization. Furthermore, project plan templates can be used to pre-structure a project. The tool was not accepted by the user and the implementation was stopped after a trial period of 2 months. The experience showed that the actions of a SWR project are not complex or long enough to plan them. The time spent for

43

establishing a plan and updating it compared to the time spent for the action execution is inefficient. The project plan also does not represent the “real world” as changes occur permanently, and the knowledge capitalization is not guaranteed for all knowledge related to the experiment projects. Furthermore, no retrieval interfaces are available to retrieve information from different projects. The 8D9 principle is also used, but the application is limited to crisis management in order to improve the quality of products. Major problems are corrected and solved. A capitalization is not done. The problem or crisis is quickly distributed within the organization as it often concerns different departments. To support the crisis management and information sharing between different fabrication sites, a tool is used to share problems and solution approaches. Therefore, knowledge is only capitalized if information about crises is shared over this tool.

2.4.3 Problem and failure synthesis of current solutions The goal of the current implemented solutions is oriented toward the information sharing and standardization of process and information management. However, a reuse of information is not currently included in these approaches. The methodologies and tools used do not support the whole process, but only parts of it. No support is available to represent the process. The centralized information is produced information, but it represents neither the current state of a process, nor the follow-up. Currently, only parts of the process are supported by IT tools. The whole process and its related context are not taken into account.

9 Eight disciplines Problem Solving – 8D Problem Solving Process is used to identify, correct and eliminate the recurrence of quality problems.

44

2.5 Analysis of information flow in the experiment processes The analysis of current process and information management practices helped to identify the current problems and application fields for a better information sharing, as explained in the following section.

2.5.1 The knowledge exchange between technologies for major and minor problems

Experiments are carried out during the development of the technological platform in order to improve the yield and the fabrication process and to industrialize the product. Often major problems encountered during the manufacturing process are solved and discussed in a transverse way across all technology generations. Major problems require fast reaction. They are diffused quickly across organizations (such as crisis, etc.). On the other hand, minor problems (as well as improvement ideas and failed experiments) are neither shared in a formalized way, nor accessible by all concerned employees who might have an interest in the results. Only positive results, in particular the resolutions of the minor problems and the executed changes, are communicated to the other generations. The risk is that other generations conduct similar experiments and have similar ideas without knowing that these results already exist. To allow a knowledge reuse between technology generations, it would be necessary to develop an exchange method to support and improve the collaborative aspects:

Knowledge capitalization related to experiments (positive and negative results) Initiate a reuse of the capitalized knowledge for new experiments

In the following section, the identified industrial application field of the experiment processes is explained where the principle of capitalization and reuse initiation should be applied.

2.5.2 Places for knowledge management improvement possibilities In section 2.4, the analysis of the SWR process flow is described. Different organizational departments are involved in the SWR process. Although these parts are organizationally independent, they work together in this transversal SWR process to produce new technologies. The process is difficult to manage as the experiments are related to the production process where problems can occur due to fabrication problems (i.e., bottleneck, errors, failures, changes, etc.). Therefore, information changes and influences the process flow between the involved actors (experiment owner, preparer (area owner) and cleanroom). First of all, the immediate use of knowledge between these involved actors could be improved. Furthermore, the reuse of produced knowledge could be reused for different technology generations. Experiments are carried out during the conception phase (R&D) as well as during the entire life cycle, meaning even for industrialized and stable products (Industrial DYE engineering). Therefore, 4 different areas for knowledge management improvement possibilities were identified, which are illustrated on the following figure:

45

1. Exchange between the R&D and the area engineering as well as between the DYE

and the area engineering o Knowledge exchange within a process

2. Exchange between area engineering and the clean-room o Knowledge exchange within a process

3. Exchange between technology generations (DYE-DYE and R&D-R&D) o Knowledge exchange between processes

4. Exchange between the DYE and the R&D o Knowledge flow backwards the process (experience return)

Figure 16: Analysis of knowledge flow improvements possibilities

These interaction types of these four areas could be characterized as follows:

• Informal interactions – interactions set up to solve a specific problem over the phone, in discussion with colleagues from other technology generations.

• Semi-formal interactions – joining a formalized web based community of practice to solve a problem; ask colleagues all over the world about the problem.

• Formal interactions – daily interactions with workshops and divisions to support and solve problems as a part of their work.

Indeed, the information exchange during an experiment is an “informal exchange,” as no formalization of the process exists and produced information is not accessible. Information is exchanged in an implicit way and on demand. The goal of improving knowledge management activities for these four areas is explained in the following section.

46

2.6 Goals of this work

2.6.1 Objectives The goal of an exchange method in this context is to improve the knowledge sharing around experiments and/or problems that might otherwise not be shared with other organizations within the same company, especially other technology generations. Normally this information is not shared, since it does not have a high importance for other technology generations as compared to the daily information flow, manufacturing problems and crisis management. This information category is more qualitative than quantitative. Only the positive results concerning a modification in the manufacturing process are communicated. Our work concentrates on this informational aspect. Sharing and reusing qualitative information associated with experiment processes with

a low importance as compared to the major daily problems Gathering information on minor problems, such as discovered problems, is the main focus of this work. This information changes and evolves during various stages of experiments (request, execution, analysis). The goal of an information exchange method can be expressed by the three following aspects:

The capitalization of knowledge in the form of information, not only to preserve the knowledge and know-how but especially to accelerate the innovation,

The development of information sharing inter/intra technology generations to benefit

from the last improvements and to avoid committing the same errors,

Faster feedback loops between generations and manufacturing, engineering and R&D to improve and guarantee the agility of the system.

Therefore, it is important to put the information at the actors’ disposal in the experiment domain, as well as push the information to the employees who are concerned. This objective, particularly within the framework of re-use, makes it possible to benefit more from the experiments of other generations.

In the last few years, STM changed from a sequential organization of technologies to a simultaneous, concurrent organization of technologies where generation of technologies and their options (different products) are developed in parallel (cf. section 2.2). As the organization is structured by technology generation, the coordination of exchange between these generations is difficult, since organizational barriers exist and the exchange methods are often concentrated on crisis and current problems.

Important problems are discussed in transversal meetings. Less important problems are solved by each organizational branch and are often not shared. However, sharing these

results and reusing them could create synergies between the different organizational parts - from already executed or currently running experiments

47

Problems encountered during development could relate to several methods as well as provide improvements which should be beneficial for other generations as they use the same machine, fabrication conditions or raw materials (section 2.2.1). Information exchange and its related management are difficult, as more and more information circulates and is pushed to employees. It is therefore difficult to retrieve important information within the whole information volume. On the other hand, neither is all information formalized, nor is the knowledge producer known. Even if the information is formalized and stored, no efficient method exists to retrieve it from within the mass of information. To improve the information sharing between technology generations, it would be necessary to develop an exchange method which helps to retrieve specific information from the mass of total information. Furthermore, this method has to be accepted by the employees.

The method should not increase the time used to exchange collaborative work in solving a problem, but should increase the reuse of experimental results.

The cooperative aspect is even more important: reuse the experiment preparation and/or its theoretical ideas in a way that they are understandable for experts from other technology generations.

Information exchange should be improved between various process generations. This allows each generation to benefit from the experiments of other generations. Knowledge sharing over organizational barriers is often realized by written information and supported by Information Technology (IT). Therefore, the following aspects in particular are analyzed:

Improvement of information sharing and existing information sharing methods Improvement of process management and existing process management methods Methods and difficulties for implementation The role of Information Technologies in these contexts.

2.6.2 The Research Methodology This research began with a field study in order to understand the practices and problems

encountered in the execution of the experiment processes and to identify the aspects and needs of handling the information and the dynamic of a process. Furthermore, in order to better analyze and understand the interactions and current methodologies, the implementation of the project management tool project.net was part of this endeavor to understand the work of the departments.

Fieldwork: The aim of this phase - described in this section - is to understand the practices and problems by executing the experiment process as well as to understand which role knowledge management can play for handling such a knowledge intensive process where information changes rapidly and influences the execution of the process. The process was studied in two different ways:

• Firstly, the working methods of employees were analyzed, as well as the teamwork. This provided an understanding of the different work and different processes employees are involved in, as well as the ability to analyze how the information is used and produced

48

• Secondly, the aim was to understand where functionalities of classic tools do not

respond to the specific user needs as well as do not handle the information aspects.

During the interviews and observation, it was quite difficult to obtain information about the knowledge production and diffusion methods. An engineer does not differentiate between his work, the produced information and the retrieval. Therefore, it was difficult to abstract the information flow around the experiment processes.

The context analysis gave a first impression, but this analysis has to be improved in order to detail more precisely the experiment process, as well as to relate the analysis to

scientific concepts and techniques to optimize knowledge management activities.

2.6.3 Hypotheses and Industrial Problem Some approaches (as explained in section 2.3.4) were already implemented in order to optimize the capitalization and reutilization, but some tool implementation failed. Currently, resistance against knowledge capitalization exists and capitalized knowledge is only done for positive results. Negative propositions and problem solving are not capitalized.

Based on these explained approaches, the explained framework and characteristics of STM and the SWR process in the microelectronic domain, three hypotheses could be formulated based on the current solutions and problems:

1) The SWR process could profit from a reutilization of produced knowledge within, backwards and between processes.

2) Knowledge capitalization must be integrated in daily work activities to capture all

produced knowledge and to keep current knowledge about real executed work and to overcome the human resistance.

3) It is more important to develop a work methodology that integrates knowledge and

process management aspects than to develop an IT tool.

These three hypotheses led to the industrial problem formulated as follows:

How can one overcome the human resistance against knowledge capitalization of positive and negative experiments (results and follow-up), capitalize theoretical and

practical experiment preparations, problems and results, keep it in time and initiate a knowledge reutilization of these information within, backwards and between

experiments processes with the goal to increase the productivity of the experiment processes?

49

The produced knowledge should be available within the same process in the actions where it will be used. Furthermore, the knowledge should be accessible for actors involved in the same experiment process to inform actors about results. In addition, this knowledge should also be reused for new experiments in order to avoid doing the same process again.

2.7 Conclusion The analysis of the context of the conception control experiment process showed that the process has three main actions. Furthermore, the dynamic aspect is important to be managed. The context analysis allowed us to formalize the process: An initialization action to request an experiment, an execution action to do the experiment, and an analysis action to prepare the results of an experiment. The complexity and dynamic of the process is introduced by two facts:

The number of concerned operations influences the number of process branches in parallel

Changing and obsolete information related to problems, changing fabrication contexts, etc., could re-induce a process execution

These dynamic and flexible aspects must be supported in order to improve the process and information management in this environment of knowledge intensive dynamic business processes. This also develops an integration of information management into the process management in order to improve the collaborative aspects as information is produced by one actor and reused and/or modified by another actor during the process. Additionally, problems related to the experiment process were mentioned. Most of these problems are related to information, as information must be retrieved in different tools and be copied in other tools. This fact confirms an analysis of the Gartner institute that discovered that firm internal information retrieval represents 60% of an employee’s daily activities [Barkat, 2002]. This context analysis therefore provided an industrial framework of common aspects of experiment processes and associated information. Information management is separated from the process management even if these activities are related. Furthermore, the need for a combination of these two domains reflected a deeper scientific investigation to profit from process and knowledge management in order to combine them. These reflections are detailed in the following chapter.

51

3 LITERATURE ACQUISITION

This chapter gives a scientific overview of Knowledge Management, Change Management, Business Process Management and the existing combinations of these domains. Furthermore, the problematic is explained.

3.1 Introduction

The previous chapter explained the context of this work and summarized some current problems in the experiment process management which are related to information. This analysis caused a deep reflection about scientific work as existing solutions did not satisfy the goal of integrating Knowledge Management in daily work activities to execute business processes. Therefore, this chapter will present current methods and problems of Knowledge Management - a recent domain that is concentrated in the treatment of information and knowledge in order to reuse it and build new knowledge, and in aiming to enhance industrial activities.

Therefore, this chapter gives definitions about what Knowledge and Knowledge Management is and explains its differences in relation to information and information management. It will also give an overview about the problems and difficulties of Knowledge Management application. The following aspects especially will be detailed:

The history and future of Knowledge Management (KM) Aspects of Knowledge Capitalization Aspects of Knowledge Retrieval Aspects of change management: human reaction and resistance

Therefore, an overview about the evolution of Knowledge Management is given and the

current existing definitions and models are discussed. This state of the art analysis leads to a definition of Knowledge Management that is used in this work.

The described knowledge management problems of the experiments are related to the SWR process (cf. chapter1). Consequently, the following sections of the literature acquisition discuss the current business processes management concepts. An overview about the history of this domain and current application difficulties is also given. The following aspects in particular will be detailed:

History and return of experience of Business Process Management (BPM) Characteristics of Business Process Management Dynamic Business Process Management Business Process Management and Information technology (workflow tools)

In addition, the focus is also to characterize the current implementations of Knowledge

Management in Business Process Management; and the current limits and needs for further evolution are discussed.

52

The important aspects of integrating Knowledge Management into business process management are summarized, as well as the needs and requirements for a better analysis for implementing Knowledge Management activities in companies. This abstracted scientific approach allowed the formalization of a general problematic that will conclude this literature acquisition chapter.

3.2 Knowledge Management Concepts Organizations increasingly focus on Knowledge Management. However, different definitions and interpretations of Knowledge Management exist. In the following, different aspects are discussed in order to give an overview about the diversity of different definitions and the evolution in the last years.

3.2.1 Knowledge and its different dimensions 3.2.1.1 What is knowledge? The notion of “knowledge” is part of a group of different terms that are related to the human “competence”. In this group of terms, the following notions can be found: data, information, knowledge, and competence, which will be defined in the following: Data is a real fact that could be the acquisition result or a measurement in an instance of time [Prax, 2000]. It can be qualitative (i.e., gray) or quantitative (i.e., the number 25); and it can be associated with events. Data has neither intention nor signification.

Information is well-organized and structured data collection transmission. The collection could be the selection of the most useful data [Gardoni, 1999]. The utility implies that the selection is realized based on different criteria or based on different combinations of criteria. The information has a subjective character, as the choice of criteria depends on the information’s sender. In the scientific point of view, information is a vague and incoherent subject. In fact, the word “information” has different multiples and ambiguous definitions. Information could also be qualitative (the sky is gray) or quantitative (the water temperature is 25° C). Information therefore has a sense of character.

[Prax, 2000] defines competence as a “unit of knowledge”, action capacity and behavior structures in function with a goal and a given situation. Thus, it is possible to relate the competence to the capacity of persons and “apply this competence and knowledge in different restricted work conditions” [Barthes et al., 2000].

“The definition of knowledge is still a live debate for philosophers. In order to be knowledge, according to most thinkers, at least three criteria must be fulfilled. A thought must be justified, true, and believed.” [Wikipedia, 2006a]. Knowledge, due to its nature, is a multidimensional phenomenon [Mira-Bonnardel, 2000]. Although Knowledge Management has existed for several years, there are many different definitions of “knowledge” in the scientific field. On one hand, in many definitions “knowledge” is considered as subjective, in particular as a personal interpretation of information by a human, so knowledge exists only inside individuals. On the other hand, knowledge is often modeled as an object for science activities to focus on the knowledge creation and diffusion. Some definitions are given in this

53

section that also shows the development of the significance of the notion of “knowledge” within the last 10 years:

Knowledge is an object, a sign that could be considered as carrying information, a

sense and a context [Cantzler, 1996], [Ermine, 1999]. Knowledge can be defined as the right collection of information at the right time

[Becker, 1999]. Knowledge is organized information applicable to problem solving [Beckman, 1999]. Knowledge refers to an activity of treatment of information, activity in which

interpretative filters take part. Each individual interprets the information he receives through a "vision of the world" that is particular for him [Sena et al., 1999]

Knowledge could be produced based on data and/or information. The link between data/information and knowledge could be interpreted based on the definitions of Larousse [Larousse, 2000]. The encyclopedia composed the notion of “information” on different sub-criteria as action, state, knowledge, content, and container. Information is therefore a multidimensional notion that is on one hand a real object and on the other hand also has intangible characteristics related to the use of information by humans. In contrast to information, knowledge needs a receptor. The receptor acquires and analyzes the information and integrates the transferred values in its system and interprets them to produce new knowledge.

The given information examples (the sky is gray) and (the water temperature is 25° C) could be interpreted by a user who knows the word “sky” and the measurement scale of Celsius degrees. Therefore, the information is interpreted and applied to a situation, i.e., “I know that the water is warm, because I consider 25°C to be warm, but for preparing coffee, the water is not hot enough.”

[Barthes et al., 2000] noticed that information becomes knowledge when intelligence - human or machine - uses the information as intention. This intention can then be part of a context or a specific situation that provokes the use and transformation of information into knowledge. This distinction can also be found in the following definitions of knowledge:

“Knowledge is a fluid mix of framed experience, values, contextual information,

expert insight and grounded intuition that provides an environment and framework for evaluating and incorporating new experiences and information. It originates and is applied in the minds of knowers. In organizations, it often becomes embedded not only in documents or repositories but also in organizational routines, processes, practices and norms.” [Davenport et al., 1998]

“Knowledge is a temporally stabilized comprehension resulting from interpretations

of information, human experience and reflections based on a set of beliefs, which resides as fictive objects in people’s minds and is suitable for transformation into actions.” [Jaime, 2005a], [Busch, 2005a]

Therefore, knowledge is related to data and to real and existing information, as well as to the intellectual capacity of a person. This intellectual capacity is difficult to explain and to formalize, in contrast to the data and information that could be captured or be formalized.

54

In the theories, there exists also a variety of definitions of these three terms:

Author Data Information Knowledge [Wiing, 1993]

- Facts organized to describe a situation

or condition

Truths, beliefs, perspectives, judgments,

know-how and methodologies

[Spek et al., 1997]

Not yet interpreted symbols Data with meaning

The ability to assign meaning

[Davenport et al., 1998]

A set of discrete facts

A message meant to change the receiver's

perception

Experience, values, insights, and contextual

information [Quigley et al., 1999]

Text that does not answer questions

to particular problem

Test that answers the question who, when,

what or where Text that answers the

questions why and how Figure 17: Definition comparison of data, information and knowledge from [Studer, 2003]

[Gardoni, 1999] proposes a distinction of these three aspects according to their utilization: Data: simple state Information: Function, i.e., communicate Knowledge: sense, treatment

[Vance, 1997] distinguishes them according their creation: “Information is data put in a significant framework. Knowledge is considered as authentic and right information. Knowledge is subjective and exists only inside humans.” The important aspects of the notion of “knowledge”, which the Knowledge Management (KM) has to deal with, are:

Subjective Temporally Created (Re-)used Interpreted Based on information Context specific Inside humans

55

For this work, based on the definition of [Jaime et al., 2005b]: knowledge is therefore considered as an immaterial object that is a temporally stabilized comprehension resulting from interpretations of information, human experience and reflections based on a set of beliefs in a specific context. The formalization of this immaterial object becomes information in a material form that could be reused to build up the initial knowledge. Therefore, the notion of “knowledge object” is used to refer to these characteristics. 3.2.1.2 What is Knowledge Management?

“Knowledge Management (KM) may refer to the ways organizations gather, manage, and use the knowledge that they acquire. The term also designates an approach to improve organizational outcomes and organizational learning by introducing into an organization a range of specific processes and practices for identifying and capturing knowledge, know-how, expertise and other intellectual capital, and for making such knowledge assets available for transfer and reuse across the organization.“ [Wikipedia, 2006b]

In the scientific field, a wide variety of Knowledge Management (KM) definitions have arisen in the last few years and in different countries. Some of these include:

“KM is providing the right knowledge to the right persons at the right moment, in order that they can reuse it and profit from existing knowledge” [Petrash, 1996]. This citation became the most famous and a commercialization phrase for advertising for Knowledge Management activities and products.

KM is a practice that allows people—when possible—to estimate the experience capacities of everyone in his or her preferred place, to ensure the circulation of useful information and to help find the information that is really needed at the right moment [Ballay, 1997].

“KM is a process in which an actor captures the collective competence of an enterprise where it exists – in databases, documents, papers, presentations, etc. – and broadcasts it to different places where it can be done with maximal benefit.”[Hibbard, 1997]

Prax [Prax, 2000] structures Knowledge Management in three sub-categories:

o “KM is an approach that tries to manage different items as thinking, ideas, intuitions, practices, experiences done by different actors by executing their profession.”

o KM is a process of creation, enrichment, capitalization and diffusion of know-how and knowledge that involves all actors in an organization as consumers and producers.

56

o KM supposes that knowledge is captured where it is created, shared by humans and finally applied to an enterprise process.

“KM is management actions with the goal to apply the knowledge capitalization cycle, meaning to locate, preserve, develop, transfer and share the enterprise crucial knowledge. This understands also the strategy, the decision making and all key processes of the enterprise.” [Barthes, 2000]

Prudhomme developed a different point of view of the previous vision. He defines knowledge as a product of a cognitive activity produced by an individual. Knowledge is individual, personal and contextual and therefore it is difficult to formalize and represent. He proposes the notion of a “knowledge object” to explain that an individual will build knowledge based on a formalized “knowledge object” [Prudhomme et al., 2001]

KM is the systematic and organized use of knowledge held in an enterprise in order to help reach the objectives. It aims at improving the enterprise’s performance and obtaining a global vision of the competences and knowledge within the enterprise [Balmisse, 2002].

KM caters to the critical issues of organization adaptation, survival and competence in the face of increasingly discontinuous environmental change. Essentially, it embodies an organizational process that seeks a synergistic combination of data and information processing of information technologies, and the creative and innovative capacity of humans [Longueville et a., 2003a].

KM is the systematic process of finding, selecting, organizing, distilling and presenting information in a way that improves an employee's comprehension in a specific area of interest [Bus, 2005].

In other definitions, knowledge is often modeled as objects in scientific research, so the research can be concentrated and focalized on the management of knowledge as abstract objects.

“Obviously, a holistic Knowledge Management (KM) approach is a major issue for human resource management, enterprise organization and enterprise culture; nevertheless, information technology (IT) plays the crucial enabler for many aspects of KM. As a consequence, KM is an inherently interdisciplinary subject. This is i.e. reflected by KM conferences that address numerous aspects of KM” [Schnurr, 2001], [Reimer et al., 2003].

57

According to [Studer, 2003], [Albrecht, 1993], [Schneider, 1996] the main building blocks of Knowledge Management are (cf. appendix 7.3 for an analysis of these factors at STM environment):

culture organization technology and people

A similar point of view can also be found in [Jaime et al., 2005b] who classified different KM definitions according four different visions (1. IT, 2. Strategy, 3.Diffusion, 4. Reuse):

1. Those that see KM as a matter of information technology 2. Those that see KM as a strategic matter 3. Those that see KM as a process that facilitates knowledge sharing 4. Those that see KM as a process to create and increase the use of knowledge

These definitions show that Knowledge Management consists of a set of activities and it has many different aspects and application possibilities. The scientific domain of “Knowledge Management” is NOT an independent, stand-alone discipline. Compared to the scientific domain of “business economics” or “business management”, which use results and scientific concepts from different domains, such as “operational research”, “mathematic” or “IT”, “Knowledge Management” is also a discipline that reuses results of its related and similar domains like “Information management”, “Information Technology management”, “change management”, “data base management”, etc. KM could not exist without these disciplines and evolutes with new techniques and models in these domains.

Based on the given definitions, Knowledge Management activities should help to capture and to spread the existing knowledge in order to keep the information current and to optimize the enterprise and individual performance by a reutilization. Therefore, the creation, diffusion and reuse process is a transversal activity integrated in people’s daily work activities and decisions.

3.2.1.3 Knowledge Management vs. Information Management Knowledge is based on information. Therefore, the question of differences between Knowledge Management and information management is justifiable. [Eppler, 2004] wrote that “Knowledge Management” is more than a simple information transfer. He lists different distinctions that we resume and interpret:

Information management answers questions such as “What?”, “Where?”, “From whom?”, “From where?” and “How much?”. Knowledge Management answers more likely questions such as “How?”, “Why?”, “What happens when?” (cf. section 3.2.1: Definition Information and knowledge from [Quigley et al., 1999])

58

Information management could be independent from person or context. Knowledge Management needs a clarification of the context and the perspective (see section 3.2.4.2)

The success of Knowledge Management is more uncertain than that of information

management. Besides finding the right interpretation of the communicated content, this content must also be applied in the right way to create a real “action knowledge”.

This distinction is coherent with the distinction between the given definition of information and knowledge (cf. section 3.2.1 and 3.2.1.3). Knowledge will be applied, used or reused in order to support an activity, and compared to information that transfers a fact, but the use of the reception is not guaranteed. Knowledge Management activities are often reduced to the management of explicit knowledge in the same context. Therefore, in many scientific works, the words “knowledge” and “information” are used similarly and could be replaced without changing the sense of the work; but even if this replacement is possible, it sometimes causes confusions. The Gartner Research group characterizes the difference between Information Management and Knowledge Management as follows:

Figure 18: Comparison between Information and Knowledge Management [GartnerGroup, 2002]

Information Management defines the guidelines for the treatment of information (i.e., security levels, classification, access, etc.). Knowledge Management sensitizes the employees on how the information should be treated (strategic aspects, Knowledge culture, collaborative environment, etc.). 3.2.1.4 History and future of Knowledge Management Knowledge Management has gained popularity in recent years and became almost a buzzword after 1995, where a lot of work was based on the research results from Nonaka [Nonaka et al, 1995]. This domain was born as significant corporate strategy to meet new challenges. The history and the current status of KM are sketched by Kay: “Knowledge Management as an approach to business management has had a tumultuous history. It was born as a hip buzzword, was shunned as a second cousin to business process

59

reengineering, and was for a time hijacked by software vendors. Despite this circuitous path, Knowledge Management is now well on the way to becoming a necessary component of every bottomline-oriented company's long-term business strategy.” [Kay, 2003]

The research activity on “Knowledge Management” is a field that includes many subdomains such as knowledge capitalization, knowledge discovery, knowledge retrieval or knowledge representation. The subdomains, in particular modeling and managing knowledge as objects in a specific context, have successfully delivered different methods in the past: Extracting knowledge from humans or from data, structuring it in a knowledge base, giving retrieval methods for the search and representing it in an ergonomic way for the users are techniques that become better and better as experiences and research go on. The application of Knowledge Management is often related to information technology (IT), as information is the basis of knowledge and can be treated quickly by IT tools. But according to a study of the Gartner Institute [Barkat, 2002], 40% of IT projects fail, due to different factors such as a lack in the identification of user needs, resource problems, acceptance problems, etc. (cf. Chapter 1). The average IT organization annually ties up to 10% of its IT staff on work that contributes no value to the business. In many cases, the problem stems from the way online information is managed and exchanged. The initiation of IT projects to organize and secure information often failed in the past and did not satisfy the needs of the organization. Enterprises tried often to build up a new Knowledge Management system (KMS) as a stand-alone tool, or as a separate activity. This KM activity as project end phase was often considered as an additional workload by the user with no “surplus value” [Creß, 2004]. The first Knowledge Management tools - produced in the occidental context based on the model of Nonaka [Nonaka et al., 1995] - were destined to capture the knowledge in the form of information and store it in a data base, but often these tools did not satisfy the knowledge needs of the employees, because of missing context or inefficient knowledge retrieval possibilities. In some cases, the capitalized knowledge was useless. KM projects implemented in large firms did not succeed because KM has been commonly understood as a support function whose goal has been to deliver a tool. Even if it is well known that Knowledge Management should have a strategic element, no methodology for KM application exists currently. However, different KM models exist (cf. section 3.2.3), although the implementation or guidelines for an application and implementation are often missing. This is why practical management activities of KM have not yet reached a satisfactory level in occidental companies, and some big firms are convinced that KM is dead or has no surplus value [Bullinger, 2004]. [Rheinhardt, 2004] describes the current state of Knowledge Management as follows, according to the misunderstanding of the application of Knowledge Management in recent years:10

No internalization support: The “nature” of knowledge and communication is considered as a mechanical aspect. The sender’s perspective is often more important than the recipient’s perspective.

10 These four remarks flowed into the development of the PIFA approach explained in chapter 4: This analyzing approach identifies and improves functionalities related to knowledge production and gives incentives to the employees. This is the most important aspect to initiate Knowledge Management activities in this work.

60

Technology centered: IT systems are still considered a central prerequisite for Knowledge Management, even if the quantitative diffusion of data is different from the qualitative diffusion of knowledge.

No human involvement: Propositions of context factors to apply KM and motivate the employees to participate are still missing.

No measurement indicators: Obscurities exist in the measurement of KM success and also on the layer of measured quality or quantity, as well as on the layer of actor or enterprise.

In recent years, authors like Nonaka have changed their models and integrated the aspect of context. For example, Nonaka [Nonaka et al., 2001a] added the “ba”-factor to his model to describe the importance of the context during the knowledge communication. Knowledge Management activities came back with the goal of supporting the innovation management. For the “2nd generation of Knowledge Management” [Snowden, 2004], [Rheinhardt, 2004], the Knowledge Management activities are no longer seen as technology processes, even if Knowledge Management is still often related to or supported by information technology. The main aspect is the human aspect and its behavior according to the creation, diffusion and (re-)use process of knowledge, especially on the internalization and application of produced knowledge.

3.2.2 Knowledge typologies A distinction of three different kinds of typologies is proposed and explained as the following:

The nature type

The application type

The source type

The “nature type” describes the different types of knowledge. The “application type” describes “how” it is used and applied. The third type explains “where” the knowledge can be found. But another distinction of knowledge typologies also exists as given by Barthes [Barthes, 2000], who distinguishes between the juridical knowledge, the technical knowledge, the economic knowledge and the organizational knowledge that represent the domain of application.

Two facts concerning knowledge typologies are retained for this work:

The knowledge typology depends on the context where the knowledge is created and used.

The knowledge therefore could have different sources that should be interrelated.

61

3.2.2.1 The nature type One of the most widely used typologies of knowledge is the one that distinguishes between tacit and explicit knowledge. [Barthes, 2000], Nonaka [Nonaka et al., 1995] and [Reix, 1995], based on [Polanyi, 1967], distinguished two different kinds of knowledge:

Explicit knowledge can be expressed in formal and systematic language and shared in the form of data, scientific formulas, specifications, manuals, etc. i.e.: Documents, papers, books and presentations are formalized knowledge that could be reused.

Implicit Knowledge is the knowledge that is held by each individual, but elicitable

and transferable. This knowledge resides in human minds and is transferable by formations, meetings, conversations, courses, presentations, etc. i.e.: The order of ingredients of a hamburger (bread, salad, meat, etc.) product is implicit knowledge held by each employee in a hamburger restaurant. This knowledge can be formalized and sent to other restaurants, so that the employees in these restaurants know how to produce the same product.

Vinck [Vinck, 1997] insists on the unavoidable coexistence of explicit and implicit knowledge within the enterprise, from the point of view of an individual. He illustrates two concepts by using a metaphor of an iceberg to illustrate the immerged (implicit) and emerged (explicit) parts of knowledge. [Bès et al., 1997] mentions that the implicit knowledge is inseparable from the organizational context and therefore is called knowledge context. Unfortunately, these notions involve believes that all knowledge could be formalized and cause misunderstandings of the goal to formalize knowledge as a priority procedure of Knowledge Management (see section 3.2.1.4). In fact, not all knowledge can be explicit. Even if the definition of knowledge objects (cf. section 3.2.1) is used, knowledge cannot be completely decomposed into different parts. Therefore, knowledge is, first and foremost, implicit (compare the used definition for this work (cf. section 3.2.1) and the decomposition in formalized information cannot represent the full initial implicit knowledge, but could support the transfer and internalization for another person. This statement is reflected by the definition of Polanyi: the concept of tacit knowledge: “We know more than we know how to say” [Polanyi, 1958], [Polanyi, 1974]. This citation was enlarged by [Snowden, 2004]: “I know more than I can say and I can say more than I can write down”. Knowledge is difficult to communicate and to formalize; it is “stored in the heads of persons” and therefore known as embodied or tacit knowledge according to [Nonaka, 2001b].

Embodied knowledge is highly personal and difficult to formalize. Subjective insights, intuitions and hunches fall into this category of knowledge. i.e.: A kitchen chef has a lot of experience in cooking. He has the tacit knowledge of how to cook a steak. Even if he could formalize a recipe explaining how to cook a steak, not everyone is able to so, as experience and tacit knowledge are missing.

62

However, these three types are related to each other and the nature of “knowledge” depends on the transfer and communication mode.

3.2.2.2 The application type The nature typology discussed in the previous section distinguishes between only the

different status, source or characteristics of the “content”. The typologies do not represent the degree of reutilization, but the humans’ needs and use of knowledge are the key for an efficient Knowledge Management. Therefore, a new notion of knowledge typology is introduced that distinguishes two different kinds of knowledge reutilization: [Busch, 2006a]

Needed and Desired knowledge:

• Knowledge that is needed (required) for work activities. Without it, the activities cannot be done. The importance is that it has to be produced and (re-)used in order to get work activities completed. A network for exchanging needed knowledge is often well established in companies. People work together on the same project or on the same team and share their knowledge along these axes.

• Knowledge that is desirable to improve the quality of work activities. This

knowledge is not necessary to be re-used as it does not directly influence the work activities. But the (re-)use of this knowledge could improve the results, save time or prevent the same errors from recurring. The network is often not clearly identified and the knowledge producer is often not known. This knowledge is produced on similar projects or teams that are separated organizationally.

Needed and desired knowledge could be transferred in an implicit or explicit way. In the following figure, examples for the diffusion of needed or and desired knowledge in an explicit and implicit format are illustrated:

regular informal exchange regular formal exchange

Needed

-on the telephone -in trainings - in meetings

-by documents -by papers

-by presentations -by contracts

irregular informal exchange irregular formal exchange

Desired

- coincidental exchange, i.e., at the coffee machine

-in meetings - on the telephone

-by documents -by papers

-by presentations -by contracts

Implicit explicit Figure 19: Source of knowledge in its usage and its form

63

The exchanged source of knowledge could be the same or similar. Furthermore, the source is independent of the usage type. It is therefore the significance interpreted by a human that gives the usage type to knowledge. On one hand, knowledge could be primordial to do a project or to continue a process. On the other hand, the same knowledge could be a surplus value for another employee that he could profit from, in order to avoid making the same errors or doing the same work over again.

Globally, knowledge that is directly necessary for the daily work will be organized in an adaptive way to its specific context, meaning that knowledge finds its own way to get used by an intended receiver. This statement refers to implicit processes that were established over time and that employees are used to. They know which information has to be sent to which person to continue the process. The way knowledge finds its way is not optimal and could take time and some work probably has to be executed twice, but generally an informal network is established to support the implicit processes. Desired knowledge is often badly shared and diffused. Knowledge sharing is done by humans during daily work by talking, discussing with colleagues, giving advice, or writing and sending documents. The manner in which knowledge finds its way to its intended receiver depends on the methods used in a context.

Additionally, knowledge that is neither easily interpretable nor accessible for an employee and represents a desired knowledge will not be shared, as the effort to share this knowledge is estimated too highly.

This induces the reflection that a knowledge sharing method should especially improve the diffusion and reuse of desired knowledge by capturing it as needed knowledge.

The difference between desired and needed knowledge seems to be simple. In fact, there might also be an example to prove the opposite - that desired knowledge was successfully shared without capitalizing it as needed knowledge. The distinction between needed and desired knowledge has the objective and implies the statement that knowledge management activities should first of all improve the exchange of needed knowledge and then reuse this knowledge for a desired knowledge exchange. The notion of “needed” implies an importance and therefore a utility for the concerned employees. Even if the distinction of these two types might sometimes not be obvious, the use depends on the context and the possible application. 3.2.2.3 The source type Within the knowledge of the company, a distinction can also be made between individual and collective knowledge:

The individual knowledge is often tacit knowledge of persons. This knowledge, with an explicit character or not, can be shared with the other persons or with the groups of persons. The notion of sharing is essential.

The collective knowledge is mostly constituted by explicit knowledge. This

mechanism of sharing is a transformation of the individual knowledge into collective knowledge [Dieng-Kuntz, 2002]. The constitution of collective knowledge is then

64

made by a series of interactions between the tacit and the explicit and between individual knowledge. The collective knowledge is called by certain authors [Nonaka et al., 1995] “organizational knowledge”.

The notion of “collective” knowledge was enlarged by [Gardoni, 1999], who introduced the notion of “project knowledge” as different from the technical domain knowledge. It consists in keeping information in a certain context (a solution responding to a problem, a problem descending from an error). This notion is applied not only to projects, but also to the whole company by different authors and known as “organization’s memory” or “enterprise’s memory”: Tarondeau [Tarondeau, 1998] defines organization’s memory as a knowledge bearing and a structured withholding or process composed in three phases (acquisition, storage and retrieval). [Dieng et al., 1998], [Dieng, 1999], [Dieng et al., 2000] and also [Matta et al., 1999] give definitions for this subject as follows: “The enterprise’s memory is a knowledge engineering approach sustained on the knowledge capitalization in order to construct an enterprise’s memory. The goal of the construction of an enterprise’s memory is to keep information in time as a memory of produced knowledge within the company”. The management of these characteristics in order to initiate a knowledge reuse is implemented in some Knowledge Management models. Characteristics and development of Knowledge Management models are explained in the following section.

3.2.3 Knowledge Management models In the section of Knowledge Management, many different models are also known. Frank [Frank, 2003] wrote, “There is not a common standard way of characterizing knowledge manipulation activities. This is also due to the different knowledge concepts and levels“. (cf. appendix 7.6). He and [Jaime, 2005b] compared different KM models and activities for each model. As a conclusion, they determined that a wide variety of activities exist in each model. The produced models are often adapted to a specific application situation of Knowledge Management aspects and therefore are more or less concentrated on one of the three aspects (Creation, Diffuse, (Re-)use). Some authors are more focused on the capitalization aspects, others on the retrieval aspects and others on the direct communication or diffusion of knowledge.

One of the major critical points on the famous models from, i.e., Nonaka [Nonaka et al., 1995], Romhardt [Romhardt, 1998] or Grundstein [Grundstein, 2000] is that they are linear. In actuality, knowledge flow does not follow a certain direction. Knowledge is quickly obsolete and only temporally stabilized, as explained in the given knowledge definitions. Knowledge Management models have to take into account the changing nature of knowledge. Dave Snowden [Snowden, 2004], [Schütt, 2004] therefore proposes a Knowledge Management model that characterizes knowledge based on its context and its perspective of change:

Chaos: fast changes, quickly obsolete act, use

Complex: unclear, confusing dependencies probe, use

Knowable: improve, share analyze, reuse

Known: standardized, share categorize, reuse

65

This is illustrated in the following figure:

Figure 20: “Cynefin” model according to Dave Snowden [Snowden, 2004], [Schütt, 2004]

Applied Knowledge Management activities should be adapted to each of the given typologies in the model (chaos, complex, knowable, known). But each domain has to deal with changes, and therefore the nature type of identified knowledge and knowledge creation processes could change. Standard Knowledge Management models and their related activities of capitalization, diffusion and retrieval could then become obsolete and would need to be adapted to the changing environment. Best Practices of Knowledge Management activities are important, but they should not be applied without respecting and analyzing the context. Knowledge Management activities that improve the knowledge capitalization in order to keep it current will probably be badly adapted to a chaos or complex environment, as in this environment knowledge exchange will be shared in an implicit way. Therefore, it is important to respect the context and application field of knowledge management activities in order to introduce a knowledge sharing.

3.2.4 Knowledge Capitalization The main goal of typical current Knowledge Management initiatives is to enable a better knowledge sharing. Drivers for the introduction of Knowledge Management included the potential for reduction of

(i) Costs for duplication (ii) Loss of knowledge when key people leave a company (iii) Time needed to find correct answers

This has led to many efforts for capturing, storing and making knowledge accessible. But knowledge is not an object in the real world. It is related to humans and “people can’t share knowledge if they don't speak a common language” [Davenport et al., 1998]. It could therefore be beneficial to find ways to profit from the knowledge produced. However,

66

Wunram [Wunram et al., 2002] indicates that “the approaches that start with the goal of capturing all the knowledge of the employees are predetermined to fail,” as only knowledge is capitalized and the reuse is not supported. The constructed knowledge in an organizational memory is therefore useless as it is not accessible or internalization is not supported.

Therefore, two major aspects have to be combined and are in interaction with each other for an efficient knowledge sharing:

Knowledge capitalization aspects Knowledge retrieval aspects and the importance of context

In the following sections, these two aspects are characterized. Additionally, the use of ontologies is explained to support the capitalization and the retrieval by keeping enough contexts to the information, structuring them and defining relations in order to help internalizing the information to build knowledge.

3.2.4.1 Knowledge capitalization aspects A mechanism of formalizing knowledge is called “knowledge capitalization” [Fouet, 1997]. The knowledge capitalization allows reusing the given domain knowledge, previously stored and modeled, to re-use it in new tasks [Simon, 1997]. Le Cardinal [Le Cardinal et al., 1997], finds the interest in productive capital in the word “capitalization”. Barthès [Barthes, 1997] has the same point of view: “The capitalization is to constitute a capital that will be valorized. The engineering approaches for the conception domain are based on the principle of capitalization”. Grundstein [Grundstein, 2000] wrote, “One has to insist on the fact that knowledge capitalization is a permanent problematic, always present in the activities of each individual that should more and more influence the management functions”. Associated with this first definition, he proposes also a precise definition of the notion “knowledge capitalization”: “to capitalize knowledge, it means to judge some produced and used knowledge as enterprise richness and to profit from it by contributing to increment the capital value” [Grundstein, 1995].

The capitalization is oriented on a surplus value by formalizing and keeping the capital knowledge within an organization in order to apply and to use it. But to reuse this capitalized knowledge, it is also important to understand and know the context in which the knowledge was capitalized. This importance of context is detailed in the following section.

3.2.4.2 The importance of context Even if the knowledge is already written down, it is not guaranteed that knowledge is also easily diffused and reused. A Knowledge Management approach should first of all identify and respond to the knowledge needs of an employee, as already mentioned in this work. Furthermore, the goal of knowledge sharing, also called knowledge communication [Schraubner, 2004], is to guarantee a correct knowledge transfer, meaning re-building the initial knowledge held by the sender for the recipient. The objective is to create a collective knowledge. The process of knowledge creation by internalizing explicit knowledge can result in different knowledge, depending on the context of the internalizing human, because the real element that is transferred is not the knowledge, but information: Implicit knowledge could be formalized and be explicit, conserved, and in consequence shared and cycled between different persons. The possibility to represent and distribute the explicit and formalized

67

knowledge allows access to this knowledge. This access allows for elaboration of new knowledge. The consequence is that knowledge could be “reinvested” and thereby produces more knowledge. But explicit knowledge is diffused in the form of information and could be interpreted differently by employees to build knowledge [Busch et al., 2003]. The knowledge creation depends on the context. If an employee is able to create knowledge based on transferred information, it is necessary to give enough context to the information to be able to reconstruct the initial formalized knowledge [Busch et al., 2004a] [Reinhardt, 2004]. Knowledge is manipulable and transferable, but it depends on the context used for the internalization: “Context is the idea that a declaration or an idea has a signification in a relation with its form. The context refers to necessary information to do a significant declaration. The information allows reconstructing the declaration sense are called context” [Landauer, 2001]. Two types of context in relation to the defined notions of knowledge are distinguished: information and data (see section 3.2.1): On one hand, the notion “contextual data” transforms data to information by adding a signification. On the other hand, the notion of “contextual information” allows reconstructing the initial sense of the information without knowing it, meaning building the initial knowledge based on information and contextual information. This is important to understand information and the art of creating knowledge. Related to the given example in section 3.2.1, a contextual data could therefore be “°C”, by adding these symbols to the number 25, information is created (“25 °C”). Furthermore, the information “the water temperature is 25 °C” could have a different sense by adding contextual information such as “in the winter” or “in Sweden”.

Figure 21: Knowledge diffusion process [Busch et al., 2004a]

Often the transfer process is not examined and Knowledge Management models do not detail this fact like the models from [Nonaka et al., 1995], [Romhardt, 2002], [Snowden, 2004]. It is sometime a misleading hypothesis that everyone interprets the information in the same way, as everyone could be able to internalize the information and rebuild the initial knowledge of the author. Currently, in the literature, especially the occidental literature, the knowledge diffusion is based on the explicit aspect. The knowledge is considered as a formalized object and perfectly internalizable. Knowledge is not directly transferable and there is no way to control the knowledge internalization of a user. This implies that knowledge cannot be explicit and cannot directly be measured by explicit numbers or statistics (cf. section 4.4.4).

68

Context is therefore important for the capitalization. The degree of context needed depends on the type of knowledge object that will be capitalized, as explained in the following section.

3.2.4.3 Which knowledge to capitalize? As in occidental countries, information exchange is often executed through formalization; some produced knowledge is already capitalized. However, a great amount of the knowledge produced during processes remains barely capitalized. Furthermore, even if the knowledge is already capitalized, it is not guaranteed that it is also easily accessible and easily shared. Today, in the concurrent engineering environment, it is important to share knowledge as soon as possible: The capitalization and sharing of knowledge at the end of a project could be too late. Problems that have occurred during the project are either not capitalized at all or are capitalized very late with this approach. Furthermore, during the whole project, a similar project could not profit from it. Therefore, a capitalization during daily work activities is important. In daily work activities, information represents an input for an employee and it is transformed into new information that represents the output. This process is supported and executed by different tools as shown in the following figure [PMI, 2002]:

Figure 22: Principle of information transformation via tools [PMI, 2002]

According to the PMI figure above, information is transferred to new information based on used tools. This represents the treatment of information in daily work: An employee receives information. Supported by tools, he will transform the information to an output. The information is therefore transformed and manipulated to new information. In the following, an overview of some typologies of knowledge objects that should be taken into account for a knowledge sharing approach is distinguished:

Final objects Final objects represent the end result of an information creation process. Final objects are produced to be diffused and should be contextual enough to be understood by the receiver, who is probably not familiar with the subject. [Dieng et al., 2000] distinguishes globally different sources as textual documents, physiques elements, meetings and discussions:

• Textual documents constitute a large source part of knowledge in an enterprise. They could be represented in electronic form or paper. It is important to define an access method for this knowledge to diffuse it.

• Physical elements could be prototypes. It is important, in certain cases, to

keep a trace of these elements and of the development.

• Meetings and discussions are characterized by an information and knowledge exchange. It is interesting to keep the context of these events in

69

the form of reports because they represent an elaborating source of new knowledge.

• There are also other information sources as graphical information. The

different information sources and knowledge also depend on activities of the enterprise.

Intermediate objects [Jaime, 2005a] wrote that “the sociologists Star, Jeantet and Vinck identified the role of objects during the modeling and design of future products. They describe these objects as communication vectors between different actors and different conception phases and call them “intermediate or border objects”. Independent of their form (planning, functional diagrams, language, etc.), their origin or their destination, these objects are interconnected to the reality of the process. In fact, the intermediate objects cannot be isolated from the process and vice versa. As communication vectors, intermediate objects structure the conception network relations and as a model of future products, they represent the conception evolution”.

However, all objects do not have the same characteristics during the design. The characteristics depend one the properties of the objects and the action situation where they are used [Vinck, 1995]. Therefore, intermediate objects represent a partial result of a process and are destined to be diffused and reused by other actors working on the same or similar project.

Knowledge artifacts Different studies describe the fact that collaborative activities are guided and “supported” by artifacts along the conception process. [Groleau, 2002] says that “artifacts are repositories of knowledge constructed in durable material form”. During the execution of processes, a great number of artifacts are produced. [Jaime, 2005a] defines that an artifact is an “element having a material form (or a virtual form, as it can also exist only on a computer system) which can convey a part of the knowledge held by its author, provided that its receiver knows the context in which it was conceived and has the necessary knowledge for its interpretation”. In this sense, artifacts are ways of translating a part of their authors’ knowledge in order to give a representation that can be stored and potentially shared and re-used. Artifacts represent therefore a part of the initial or global knowledge, but they are not destined to be diffused in the sense of representing results, project milestones or similar information. Artifacts are more likely diffused within the same team, working with the same objectives on the same project. However, to exchange and diffuse artifacts, context becomes primordial to guarantee that the receiver will be able to internalize it. Even then, the receiver should also know the sender’s context such as, for example, competence, current projects, previous results, etc.

To share each of these knowledge objects, the difficulty is to store these objects with enough contexts in order to allow knowledge internalization for different users [Rheinhardt, 2004], [Probst, 2002], [Nonaka et al., 2001b]. The importance of context for the three types is illustrated in the following figure:

70

Figure 23: Comparison of needed context for knowledge objects internalization

As illustrated in the figure above, the exchange of final objects does not need a lot of context, as final objects represent a good, a service, know-how (such as fabrication processes, etc.), and the object should contain enough context so that it is “self-explanatory”. During the development of a final object, intermediate objects are created to represent project milestones, first results, etc. Therefore, the diffusion often concerns the same team members with different competencies. The diffusion of intermediate objects should therefore contain more contextual information. The artifact is a “result” that is exchanged within the same team in daily work, so the context must be known and understandable in order for employees to be able to internalize these knowledge artifacts. Contextual information could be found within the information object. A more appropriate method that is also used for the knowledge retrieval is the annotation, as explained in the following section, to identify the “used” knowledge objects. 3.2.4.4 Annotate information It is difficult to harmonize the individual information storage structure of every member of an organization to combine them into one unique structure. Although each work is in a similar context (same company, project, department, etc.), the way the member works could be completely different. This fact is expressed by different document structures and causes difficulty concerning the harmonization of the document structures [Busch et al., 2003], [Busch et al., 2004b]. To create a knowledge base containing documents, it seems to be necessary to abandon the classic hierarchy. Document classification should not depend any more on a tree-structure. In fact, they are annotated by attributes belonging to categories which can be used for the creation of a hierarchy, ex post. In other words, predefined values “annotate” documents and these values are used for tree-building. The core concern of IT-supported knowledge sharing is the computer-assisted capitalization of knowledge and its context [Abecker et al., 1998]. Because information technology may only deal with digital, preferably highly-structured, knowledge, the typical KM approach distinguishes between computer-based encoding in an organizational memory and direct transfer that is done by humans. Structuring the knowledge (formalized as information) can be done in different ways. A very appropriate way is to use annotations to describe the

71

information to classify; three different types of annotation possibilities based on [Gardoni, 1999] are explained thus:

Structured annotation supported through a classification of information: Information could be described by a predefined list of symbol values. These values are used to annotate information and are predefined. Only values among the predefined ones can be used for the information classification. This type of annotation is often found in internet portals or in forms where the user can choose values among a list.

Semi-structured annotation realized as free description: Information could be described by a free annotation. These values are used to annotate information and are not predefined. Furthermore, they depend on the user and his or her ability to clearly describe the information. The description can contain values of the predefined information. This type of annotation is often found on support question forms to express a problem or remark. This category is called “semi-structured” as the concept is predefined, but its values and symbols in use could be different for each user.

Unstructured annotation as free description without any structure Information could be described by a free annotation of symbol values. These values are used to annotate information and are not predefined. Furthermore, they depend on the user and his or her ability to clearly describe the information. The description can contain values of the predefined information, but the concept for the used values is not defined, and neither are their values. This annotation is often found in internet blogs and forums, etc., as information can be posted by every user to discuss a topic, document, tool, etc. This category is called “unstructured” as the used concepts are not predefined, and neither are the used values or used symbols. They could be different for each user.

Additionally, there exist also three types of annotation processes: Automatic annotation

Information could be annotated and fully automated by an intelligent agent, based on, for example, Self-Organizing maps11, decision trees12 or ontologies13 based on rules and data analysis. An intelligent agent annotates the information on a predefined reference list. These techniques are especially used by search engines in the worldwide web and the newer generation of search engines in the semantic web.

Semi-automatic annotation (realized by reusing existing data-structures)

11 The self-organising map (SOM) is a method for unsupervised learning, based on a grid of artificial neurons whose weights are adapted to match input vectors in a training set. It was first described by the Finnish professor Teuvo Kohonen and is thus sometimes referred to as a Kohonen map. 12 A graphical representation of all possible outcomes and the paths by which they may be reached; often used in classification tasks. The top layer consists of input nodes (e.g., meteorological observations and data). Decision nodes determine the order of progression through the graph. The leaves of the tree are all possible outcomes or classifications, while the root is the final outcome (for example, a weather prediction or climate classification). 13 For the definition of “ontology”, please refer to section 3.3.1 ff.

72

Information could be annotated semi-automatically by a user and fulfilled or completed by an IT-tool. A user could therefore annotate information among predefined categories. An IT tool could accomplish this annotation based on pre-defined structures. These relations could help to describe the content more precisely.

No automation Each annotation is independent. The work is done by a user who cannot profit from predefined structures. Furthermore, the way annotations are done is completely free and has no restrictions.

Actually, even if the document is structured, annotated and information is provided in a certain order, it remains difficult to retrieve a document and to understand its context. A machine interpretation of an indexation of documents compares only the syntax of words, but does not understand the signification. To improve this dilemma, recently the use of semantics14 (description of the nature and the contents of objects) developed in the field of the Knowledge Retrieval became more and more important, i.e., semantic web15 16. An implementation of semantics is often supported by the use of ontologies, describing the vocabulary and their relations of a certain domain supported by IT as explained in the following sections. 3.2.4.5 The use of ontologies for annotation Ontologies were exploited in Computer Science to enhance knowledge sharing and re-use [Gruber, 1995], [Fensel et al., 2002]. Firstly, they provide a shared and common understanding of knowledge in a domain of interest. Secondly, they capture and formalize knowledge by connecting human understanding of symbols with machine processability. In this way, ontologies act as a common language between agents (human-human, human-machine, machine-machine). The use of ontologies for Knowledge Management offers great advantages. Numerous applications already exist [Sure et al., 2002], [Handschuh et al., 2003]. [Sure, 2003], Dieng et al., 2000] give the following definition: “An ontology is an explicit, formal specification of a shared conceptualization of a domain of interest.” [Fortier et al, 2002] defines an ontology as “a hierarchy of concepts, relations between concepts and rules and constraints”.

“A concept represents the relation of an expression to its context. The meaning triangle (cf. [Odgen et al., 1923], in the tradition of Frege, cf., e.g., [Frege, 1994]) is used to define the interaction between symbols or words, concepts and things of the world (see figure 24). The meaning triangle illustrates the fact that although words cannot completely capture the essence of a reference (= concept) or of a referent (= thing), there is a correspondence between them. The relationship between a word and a thing is indirect. The correct linkage can only be accomplished when an interpreter processes the word invoking a

14 Represent the "sense" contained in the "sign", in an IT point of view; Information contained in Data. The first step in datamining process is to emphasize the meaning of information drowned in the fuzzy mass of data. 15 The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in co-operation [Berners, 2001] 16 "Of or pertaining to meaning, [especially] in language," from semainein, which is "to signify or mean." During the past few years, there has been much talk about the emergence of a "semantic Web," a concept championed by none other than Tim Berners-Lee. Semantic Web applications are intelligent systems where computers can effectively understand the meaning of the information transmitted, unlike HTML-based systems that are mostly concerned with how information is displayed.

73

corresponding concept and establishing the proper linkage between the concept and the appropriate thing in the world (= object)” [Sure, 2003].

Figure 24: Principle of an ontology: the meaning triangle [Odgen et al., 1923]

The construction of an ontology represents a formalization of a domain-specific vocabulary (group of symbols) where each symbol is associated to a meaningful reference (concept) interpretable by a human to associate the symbol to an object in the real world. Haase [Haase et al., 2004] writes, “Ontologies by nature make implicit knowledge explicit, they describe relevant parts of the world and make them machine understandable and processable”. In the following figure, an ontology and one of its possible instances and relations are illustrated. The ontology has three concepts: “firm”, “employee” and “job”. Each concept can evoke different symbols and refer to different object. In this example, the concept employee refers to the symbol “Hendrik BUSCH” and also to the person “Hendrik BUSCH” in the real world.

Figure 25: Example of an ontology and its possible instance

This example might be trivial, as the symbol and the referred objects are the same for the lecture. But the use of the symbol “jaguar” can represent a car or an animal. The reader is able to recognize the referred object based on the context of the sentence, but a machine cannot. In this case, an ontology can help machines to better “understand” the symbol and associate it to the object in the real word. Furthermore, it can be used to standardize and clarify the vocabulary used in a domain. Based on the concepts and the values of an ontology, information can be annotated by contextual ontology knowledge. This annotation can be done according to different points of view. The user can annotate the capitalized information according to his personal point of view in a specific context and also annotate the document with common and shared categories. Two major difficulties from using ontologies could appear (cf. section 3.3.3):

74

The first difficulty is to build up a common ontology for a domain to allow annotating the information among this ontology. These descriptive concepts of an ontology are meta-data17.

Therefore, an analysis must be done to formalize the domain ontology and to

understand which data are used for the classification. An analysis proceeding could include the analysis of employees’ tree structures to classify documents, the analysis of currently used IT-Tools and the categories or data structures to store and structure data, current navigation menus or intranet web-pages, etc.

The second difficulty is the maintenance and evolution of an established ontology.

Concepts could change and have to be added, removed or renamed. Symbols belonging to a concept could also evolve and new symbols have to be added, older symbols have to be removed and existing symbols have to be changed. Depending on the context of the use, the ontology could be changed and adapted by each user or only by responsible ones.

Therefore, the analysis must be repeated in periodically to update the existing and

constructed ontology by adding new values for each category, erase existing ones and add or erase concepts and the relations between them.

Ontologies are not only used for the knowledge capitalization, but especially for the knowledge retrieval as explained in the following sections. 3.3 Practical aspects of Knowledge Management Increasingly Knowledge Management activities are implemented in companies with new techniques of Knowledge capitalization and retrieval. Therefore, current techniques of knowledge retrieval supported by ontologies and by Information Technology are presented. However, knowledge capitalization needs a human effort and is therefore sensitive to resistance. Consequently, human resistance and change management aspects against Knowledge capitalization are discussed. These two aspects has to be taken into account to design and deploy a Knowledge Management System as explained in the last section of this chapter.

3.3.1 Knowledge retrieval aspects and the role of ontologies 3.3.1.1 Knowledge Retrieval aspects A Knowledge Retrieval system is defined as a set of programs which interpret the questions, search for the information and return the information found to the person who asked the question [Boyce, 1994]. Furthermore, [Boyce, 1994] suggests that the following components must be analyzed in a process of evaluation: 17 Metadata (Greek: meta-+data "information") means data about data. While this definition is commonly offered, it is also commonly not helpful. An example is a library catalog card, which contains data about the nature and location of a book: It is data about the data in the book referred to by the card. http://en.wikipedia.org/wiki/Meta-data

75

The database, The description language of the data, The system of Knowledge retrieval, The language of communication between the system and the user.

Tague-Sutcliff [Tague-Sutcliff, 1995] defines a Knowledge Retrieval System according to four functions:

The collection or the database; its contents, its dispersal, its area; Its description, that is the modeling of documents, The type of possible search, the means of access, the indexation, the extraction of

documents, analysis and synthesis of the information of the document to answer the questions

The presentation The computer system is no longer the centre of the system. It is rather a question of analyzing the entire chain of this system, from the need to the result. Starting with the user needs, it is necessary to support the verbalization of these needs to adapt a search request to a system that represents its need. Recent studies confirm [Sevcik, 2002] that today, the users make 3 clicks and wait 8 seconds on average to make and obtain the results of a search. This shows a dilemma for the design of retrieval systems. On one hand, a system which supports at best the need should be developed, but on the other hand, the same system should not have too complex interfaces to verbalize the user need. In the following figure, the verbalization as the main difficulty of this system is illustrated.

Figure 26: System of Knowledge Retrieval

To be able to verbalize and respond to a user need, the systems are often constructed in a way to respond to a specific domain or kind of search. Therefore, the use of domain ontology could help to improve the efficiency of a knowledge retrieval system. 3.3.1.2 Ontologies and Knowledge Retrieval The use of meta-data offers a partial solution of this described dilemma about the design of a retrieval system. The use of contextual knowledge in form of annotation provided by a domain ontology subsists on the construction of a knowledge base where information is stored and structured by ontology knowledge. The use of the domain ontology for knowledge retrieval allows the integration of the re-use aspects to this knowledge base. Ontologies could help to support the knowledge retrieval as follows:

76

The ontology concepts could be used to search one specific value of the concept

representing an important contextual information. The ontology hierarchy between concepts allows refining the search and increasing

the precision and the quality of the retrieved results.

The ontology relations between concepts allow navigating and elaborating links between information that were not known before. These links and navigation possibilities could be used to discover new knowledge.

Even though knowledge capitalization and retrieval techniques become increasingly efficient, the deployment of such techniques is confronted to human resistance as explained in the following sections.

3.3.2 Knowledge capitalization, human resistance and change management 3.3.2.1 Human resistance The source of knowledge is human, and while knowledge is a competitive advantage for the company, it is also a personal advantage for a human within a team, for teams within transversal projects, within the production site, within the company, etc. Knowledge can be considered as “power” and it can be a personal power or a company’s power. However, one individual may not be concentrating on the gain of the company, but on personal interests.

Knowledge is often considered as power in a context where it could be applied personally and/or for the company: an individual may be less focused on the enterprise’s profit maximization than on personal objectives, such as:

Maintaining his employment Continuing his career Improving his competencies

Therefore, an employee could be in a contradictory situation: He could evaluate that knowledge sharing is a loss of power and consider that knowledge capitalization in the form of documents to be wasted time, as it does not bring him an immediate surplus value. But at the same time, an employee wishing to benefit from others by gaining a personal profit and knowledge formalization allows this knowledge to deepen and clarify. An optimal Knowledge Management (KM) implementation has to respect this contradiction and develop a KM method in the following way:

Knowledge sharing should be part of the personal objectives of each employee Knowledge Management activities should be decided and supported by the

management.

Even if the KM is introduced by the management, the knowledge sharing must take into account the human resistance phenomenon: profit from others without sharing.

77

The knowledge sharing in occidental companies is often based on IT tools where users can store their information [Wenger et al., 2004]. In this case, the “free-rider” problem (benefiting from others without bringing something) is well known: users want to benefit from this base without contributing their own results. This aspect is especially critical for the deployment of such a database, and depends on balance between the time taken for storage and the profit derived from the retrieval. Even if the database completion doesn’t take a long time, it is not always guaranteed that it will be accepted and used.

An empirical study [Creß, 2004] has shown that people do not share their knowledge in a formalized way, even if they have a significant personal benefit in the future. The reason for this is that capitalization and formalization takes time as compared to the importance of daily work activities. Contrarily, a tacit knowledge sharing (meetings, phone, observations, etc.) between employees in a synchronized way is easier to realize and often the preferred method for an employee. To guarantee an acceptance of such a database, it should immediately bring a personal profit to the daily working methods for the employees [Kräkel, 1999].

Without methods and techniques to motivate potential users to accept KM methods in the two axes (capitalization and reuse), the acceptance of such a method could fail. The resistance problem cannot easily be solved, but the deployment of a KM culture can be a leverage action. Knowledge exists only in humans, not in technology, and KM therefore needs a human effort. For the KM success, KM methods either must be integrated in the daily work of people and give them an immediate personal advantage by using them, or incentives must be given that motivate employees to initiate knowledge sharing.

Particularly in transverse projects between different employees and organization levels, the KM activities are precarious because they concern different teams with different objectives. Moreover, these objectives could be in competition. From a global point of view, the KM can bring a synergy effect for the total project, but perhaps not for each of the teams. In this case, the employees are not interested in the KM activities because they do not bring a personal profit.

Kräkel [Kräkel, 1999] has shown that employee’s working activities are concentrated on activities that are recognized by their supervisors. Other activities, even if they are more important for the company, are not carried out if their supervisors do not recognize their efforts. Objectives of each team involved in the transversal project are often different and this makes the application of KM difficult.

To sum up, the management engagement is important motivation to involve the employees in KM activities, as well as to provide a personal profit or incentives for each involved employee.

Additionally, KM approaches are often combined with Information Technology (IT) that implies changes. IT tools offer certain functionalities and will never cover or replace used functionalities in a free usage. Therefore, a natural human resistance that could be related to skepticism of IT technology, age, etc., could be expected. These facts have to be taken into account to implement a KM method and to manage the change (the phase of implementation and deployment):

“Getting and accepting improved functionalities by giving up flexibility and

accepting a stronger knowledge capitalization”

78

should be the key sentence to a successful implementation. Nevertheless, managerial support is important. But even if the management imposes a new work methodology, it will only be correctly used if the employees understand the gain and accept the changes. One aspect could be the improved functionalities. However, different types of changes exist that have to be taken into account. The different types of changes are explained in the following section. 3.3.2.2 Different types of changes

The change of a situation is not only a short fixed point in time. Moreover, changes take time to be prepared and implemented. Therefore, depending on the concerned context, different types of changes exist. In this section, the distinction of Mintzberg [Mintzberg, 1987] is explained, which distinguishes three different types of change:

Anticipated - changes that are planned ahead of time and occur as intended. Emergent - changes that arise spontaneously out of local innovation and which are

not originally anticipated, intended or planned for the implementation. Opportunity-based - changes that are not anticipated ahead of time but are

introduced purposefully and intentionally during the change process in response to an unexpected opportunity, event, or breakdown.

Different ways are known for managing the change. Here, two rather different kinds of change management are distinguished, and they are put in relation with the three types of change (anticipated, emergent, and opportunity-based):

Classical way of change management: managing the change in one fast change Modern way of change: Accompanying the change and reacting to different

situations that occur

Classic ways of thinking about technological change have their roots in Lewin’s three-stage change model [Lewin, 1952] of "unfreezing," "change," and "refreezing" [Kwon et al., 1987]. This model considers that organizations prepare for change, implements the change, and then strives to regain stability as soon as possible.

Pettigrew [Pettigrew, 1985] mentioned that this model is only appropriated for relatively stable organizations.

The classical way implies that all change and human behavior could be anticipated and planned, and the change management could be executed as previewed. Today, however, enterprises change their organizations permanently, and they are confronted with more turbulent, flexible, uncertain organizational and environmental conditions. In this context, such a model is becoming less appropriate, especially regarding the new open-ended and customizable information technologies supporting the human interaction as Knowledge Management tools, including groupware tools in particular, as explained below.

The discrepancy of using a classical method of change management

“is also evident when organizations are using information technologies to attempt unprecedented and complex changes such as global integration or distributed

79

Knowledge Management. A primary example of this is the current attempt by many companies to redefine and integrate global value chain activities which were previously managed independently. While there is typically some understanding up front of the magnitude of such a change, the depth and complexity of the interactions among these activities is only fully understood as the changes are implemented.” [Wanda et al., 1997].

In particular, the use of groupware tools providing electronic networks for human interaction to support communication, coordination, and collaboration between humans cannot be completely anticipated. During the change and implementation of using such tools, the way employees use this technology could be different from the initial goal. Additionally, opportunities could appear to use the technology differently as initially defined:

“Interactive human information technologies are typically designed with an open architecture that is adaptable by end users, allowing them to customize existing features and create new applications” [DeJean, 1991], [Malone et al., 1992]. These tools are often used in different ways across various organizational activities and contexts. As their use cannot be completely anticipated, organizations need the experience of using these technologies in particular ways and in particular contexts to better understand how they may be most useful in practice.

This theory is also confirmed by [Autissier, 2003] who proposes a four field matrix to classify different changes. He distinguishes between four different kinds of changes—prescribed, constructed, crisis and adaptive—and separates two different axes of change— the degree of change (progressive or brutal) and the voluntary of the change (imposed or voluntary)—as illustrated in the following figure:

prescribed change constructed change

Progressive

- response to the environmental constraints (rules, technology) - 12-36 months

- organization evolution that changes the way employees represent their enterprises - 1-10 years - culture, client, quality, process

crisis change adapted change

Sudden, brutal

- dysfunction solution - 1-3 months - accident, burden, client's complaints

- transformation of practices and of organization - 6-18 months - new information tool - commercial competences

imposed voluntary Figure 27: Matrix of change management

As shown in figure 27, information technology is part of an adaptive change. Even if the supported work methodologies change rapidly, the use of this new tool is often voluntary and depends on the user. Therefore, the behavior of the user cannot be completely anticipated. Some employees are early adopters; others need time and are more critical about changes. These described facts confirm that changes should first of all bring a surplus value for the

80

employee. Based on these facts, a change management model is proposed in the following section, respecting these two aspects:

Giving incentives to motivate the employees involved in the change Accompanying and adapting the change and its management techniques

The change (and all different types) could be considered as transition phases that have to be managed. Therefore, a monitoring model is proposed in the following section based on the discussed characteristics in this chapter.

3.3.2.3 An approach for overcoming human resistance against change

All changes move from the current state, through a transition phase, into the desired defined improvement state. The attainability of the desired state depends first of all on the definition of the state. If the state is defined as too radical and abstract, it will not be attained. A realistic definition is therefore also the base of a change management. Furthermore, difficulties and opportunities could appear during the change that will influence the initial defined desired state [Wanda et al, 1997]. It is essential to initiate a change by having a balance between the human resistance (degree of change), the management support and the immediate surplus value as described in the previous sections of this chapter. The change is done over a certain time period (transitions phase). The change has to be monitored and change strategies and management techniques have to be adapted in order to envision the initial defined state, as well as taking into account the appearing emergent and opportunity-based aspects. The change management has to be seen more as an ongoing improvisation than a short event or point in time. A monitoring model for the change that takes into account the discussed aspects in this chapter is proposed:

Figure 28: Balance between resistance, management support and surplus value during the transition change phase

[Argyris et al., 1978] wrote, “People end up responding to conditions as they arise, often in an ad hoc fashion, doing whatever is necessary to implement change. […] There is a discrepancy between how people think about technological change and how they do it.”

81

In many situations, predefining the technological changes to be implemented and the organizational impact is not feasible, meaning that models of planned change that often refer to implementations of new technologies are less than effective. It would be more appropriate to think about change that reflects the unprecedented, uncertain, open-ended, complex, and flexible nature of the interactive human information technologies and organizational initiatives involved, as shown in figure 28. This is suggested as a monitoring model applicable periodically during the transition phase of the change.

These discussed aspects18 have to be taken into account to design and implement knowledge management systems.

3.3.3 Knowledge Management Systems supported by IT 3.3.3.1 Goals of Knowledge Management Systems (KMS)

Knowledge Management Systems (KMS) refer to a class of information systems applied to managing organizational knowledge. They are IT-based systems developed to support and enhance the organizational processes of knowledge creation, storage, retrieval, transfer and application [Alavi et al., 2001]. Currently, the technology relative to the "handling" of information has become more and more successful and should no longer present major technical problems concerning the realization. Nevertheless, it is still difficult to adapt the system to the human needs and behavior. The most crucial aspect is therefore to adapt information technologies supporting Knowledge Management activities to a context, especially to the organization and humans. The goal of a Knowledge Management System is therefore to improve the knowledge exchange between different organizational barriers.

18 The application of the change management principle can be found in section 4.2 for a scientific solution and in section 5.5 for an industrial application

82

In the following table the different contexts of knowledge sharing concerning place and time are compared:

need: face-to-face

meetings need: administrative,

filling, filtering

same place

Copy boards PC Projectors Facilitation Services Group Decision RoomsPolling Systems

Shared Files Shift Work Kiosks Team Rooms Group Displays

need: cross-distance

meetings need: ongoing coordination

different place

Conference Call Graphic and Audio Screen Sharing Video Teleconferencing Spontaneous Meetings

Group Writing Computer Conferencing Conversational Structuring Forms Management Group Voice Mail

same time different time

Figure 29: KM tools for different knowledge sharing environments [Johansen, 1991]

Knowledge sharing aspects with the goal to optimize a reutilization should especially concentrate on this context of delocalized and asynchronous environments. Therefore, information technology could especially support these activities. 3.3.3.2 Use of Information Technology

Technology cannot solve organizational or cultural problems, but it can help to initiate and support knowledge management activities. Most corporate communication systems are built around Enterprise Information Portals that are ideal for aggregating information and managing content, but they do not guarantee usage or ensure that important information gets to the people who need it. By another study of the McKinsey Company [Bartlett, 1996], 80% of IT projects do not influence the return of investment (ROI) of a company. According these studies, IT is often used to manage and organize information without supporting the information used to build up knowledge. Information is structured, stored and conserved in time, but the way employees retrieve and reuse information to build up knowledge is not supported. However, the knowledge requirement should be the initial driving force for IT projects to improve the quality, reduce cost, etc., to create synergies and surplus values supported by IT projects. The difficulty of introducing a Knowledge Management System (KMS) is to introduce in the system pertinent information, as well as to change the culture of employees to use such a system. The satisfied employee’s need is a key factor to guarantee success (acceptance by the users), as explained in the previous sections. The barrier of the introduction of such a system is already high enough, because it is not only a question of changing the working method, but

83

also of changing the culture and motivating the employees to re-use the results of their colleagues.

Tiwana [Tiwana, 2002] proposes a list of some relevant Knowledge Management technologies which can contribute to the construction of a Knowledge Management platform.

Intranet: distribution, connectivity, publishing. Groupware Web / Video conferencing: dialog. Business intelligence Data Warehousing: knowledge discovery. Expertise pointers Expert systems Document management

In practice, there are often many obstacles that prevent the collective knowledge building:

A variety of information systems exist without interfaces between them. Users do not know where to store or to look for information. User rights are often restricted, so that users cannot get all the information they are

looking for. Projects are often classified as highly confidential, and intermediate results are not

communicated. Companies operate in many different countries and need to deal with significant

culture and language barriers. Knowledge is not always formalized and it is difficult to identify people with a

specific knowledge. Subcontractors and partners must access some pieces of information, but this

information is protected. These facts are also a proof that IT is often implemented in order to capitalize knowledge, but the knowledge reutilization process is not supported. Quite the contrary, the diffusion is more restricted because of access rights. The importance is therefore the knowledge production and reutilization, and secondly, IT should be adapted to the given context that will be supported by IT. 3.3.3.3 The implementation of Knowledge Management Systems There exist various proposals for methodologies that support the systematic introduction of KM applications into enterprises [Sure, 2003]. [Staab et al., 2003] mentions that these methodologies include two different aspects as shown on the left side of figure 30:

The “Knowledge Meta Process” addresses aspects of introducing a new KM application into an enterprise as well as maintaining it.

The “Knowledge Process” addresses the handling of the already set-up KM solution. The Knowledge Meta Process should have its focus on knowledge identification. The Knowledge Process should rather stress the knowledge creation. The implementation of a KMS is therefore a combination of these two processes: “Two orthogonal processes with

84

feedback loops” describing an implementation of KMS in enterprise and adapting the proceedings based on past experience. This process takes into account the explained facts on “change management” in section 3.3.2. A KMS-IT solution will be adapted according to the knowledge Meta Process, but it must also take into account the human aspects and the software engineering aspects. A KMS system is NOT a software tool. A KMS describes the permanent interactions between human behaviors, software engineering and the knowledge meta process as shown on the right side of the following figure (see figure 30).

Figure 30: Knowledge Meta Process for KMS implementations [Sure et al., 2002], [Sure, 2003]

Only a permanent adaptation and survey of the knowledge and the knowledge Meta processes, as well as a combination of human behavior, technology and these changing knowledge processes, can guarantee a KMS adapted to an organization’s context. The knowledge process, meaning the knowledge that is managed through the system can evolve; therefore the knowledge Meta process will also evolve and change. The change of the Knowledge meta process could change the way knowledge is managed through the system. Therefore, a monitoring of both knowledge process types and their interfaces should be done. Furthermore, the software engineering approaches could also change by using new technologies that could impact human behavior. The IT application supporting the KMS must also be monitored and compared to the analyzed knowledge Meta and knowledge process.

85

3.4 Synthesis of Knowledge Management aspects and the need for integration in other domains

In the previous sections of the literature acquisition chapter, a wide overview of different dimensions and terms related to knowledge management was given. Currently, no common consensus of knowledge management exists. The definitions and models that are used often depend on the applied context. However, all knowledge management approaches concentrate on filtering the pertinent facts within the mass of information and supporting knowledge sharing within an organization. Therefore, it is often important to create an organization’s memory to support the knowledge diffusion in order to transform individual knowledge into collective knowledge. However, no standards are defined for these transformations, and knowledge could be transferred into an implicit or explicit means supported by a variety of methods and tools. In the last years, the application of ontologies to capitalize, annotate, and share knowledge has become increasingly important for explicit knowledge sharing. Even though knowledge management techniques have become more mature, however, models or guidelines for the application of knowledge management are still lacking. Especially, a possible human resistance against knowledge capitalization is not often taken into account. Therefore, the distinction of needed and desired knowledge was proposed. The application of knowledge management should, therefore, concentrate on supporting the needed knowledge exchange that could be reused later as desired knowledge. Managing this type of knowledge, combined with surplus value, facilitates the integration and will minimize resistance against changes. Companies have often introduced knowledge management as a stand-alone discipline with dedicated tools for knowledge sharing. The goal, however, is to capitalize the maximum amount of useful knowledge. This knowledge is produced during different activities in daily work. Consequently, knowledge management activities should be integrated into each activity of daily work. In this work the produced knowledge that is analyzed is related to the experimental processes. Employees are involved in different processes, and their daily work represents activities in these processes. Therefore, the source of knowledge production is in these processes. In order to apply knowledge management to this context, a deeper theoretical reflection about the characteristics of these processes is required. Consequently, aspects of business process management and the current solution for applying knowledge management to business process management are discussed in the following sections.

86

3.5 Business Process Management concepts Organizations increasingly automate their business operations. Such business processes are typically of long duration, involve coordination across many manual and automated actions, and require access to several different databases and the installation of several application systems. A typical business process may consist of many different transactions. Coordinating the entire process correctly and efficiently places demands on the organization’s IT. Therefore, an overview about Business Process and Business Process Management is first given. An implementation of business process management via IT is also discussed, as well as current solutions of combining knowledge and business process management.

3.5.1 What is a Business Process? There are many different kinds of procedures used to describe the way work is done in an organization. Some of the procedures are inherently vague (since no individual really understands how the work is accomplished), while others are highly refined and highly specified to ensure rigid and predictable execution of the procedure. [Nutt, 1996]. Before giving and discussing other definitions of Business Processes, it seems interesting to explain the notion of “project”. [Kerzner, 2003] defines a project as “a temporary endeavor undertaken to create a unique product or service. It can also comprise an ambitious plan to define and constrain a future by limiting it to set goals and parameters. The planning, execution and monitoring of major projects sometimes involves setting up a special temporary organization, consisting of a project team and one or more work teams. A project usually needs resources”. He mentions that projects are described by the following characteristics:

Have a specific objective to be completed within certain specifications Have defined starting and ending dates Having funding limits (if applicable) Consume human & non-human limits (i.e., money, people, equipment) Are multifunctional (i.e., cut across several functional lines)”

The notion of a project is more focused on the planning and resource aspects of how the work is organized. A business process is more focused on the dependencies and structures of actions and the procedure of how work is done as explained in the following. However, they have common aspects and sometimes a distinction can be difficult. In the literature, different definitions exist. Here, an overview of current business process definitions is given. The process notion is oriented to applied procedure, rules and specifics that define the nature of the process:

“A business process is a collection of related structural activities that produce something of value to the organization, its stake holders or its customers. It is, for example, the process through which an organization realizes its services to its customers. It is therefore a recipe for achieving a commercial result. Each business process has inputs, method and outputs. The inputs are a pre-requisite that must be in

87

place before the method can be put into practice. When the method is applied to the inputs, then certain outputs will be created.” [Wikipedia, 2006c].

“A business process is a procedure where documents, information or tasks are passed

between participants according to defined19 sets of rules to achieve, or contribute to, an overall business goal. A business process is represented as a process with a name, version number, start and termination conditions and additional data for security, audit and control. A process consists of activities and relevant data. Each step within a process is an activity, which has a name, a type, pre- and post-conditions, scheduling constraints and a role. The role determines who will execute the activity.” [Hollinsworth, 1994].

Jacobson [Jacobsen, 1995], on the other hand, describes a business process as “the set

of internal activities performed to serve a customer.”

[Hollinsworth, 1994] defines a process as a “set of partially ordered activities intended to reach a goal” and “a business process is a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer. A business process has a goal and is affected by events occurring in the external world or in other processes”.

This contradicts slightly a later definition given by Eriksson and Penker [Eriksson et

al., 2000], who say that a business process emphasizes how work is performed rather than describing products or services that are a result of a process. A business process entails the execution of a sequence of one or more process steps. It has a clearly defined deliverable or outcome.

These definitions are very similar. In this work, the notion “Business Processes” is used for a procedure that defines the exchange of information in a predefined work order, executed by humans, with the goal to optimize the productivity to produce a good or a service for each activity of an employee related to the business process. Two different notions are related to the notion “business process”: A business process model is a formal description of a business process or procedure. A process instance is one execution of a process model. That is the major difference between the specification and the tools for BPM. The instances are therefore different as different employees could be involved and the produced good or service could change, but the way the process instance is executed is pre-defined by the process model.

19 Author’s Remark: the exchange of information in business process is not always defined. This definition refers therefore to a procedure how information should be exchanged in the best way in a repetitive context.

88

3.5.2 What is Business Process Management? Different definitions of business process management (BPM) exist in the literature. The term Business Process Management is still not well defined and depends on the application context and has different significations. Probably for these reasons, most of the existing classifications are based on the intended use, meaning on the point of view of the author in applying BPM. Some authors include the analysis (Business Process Analysis or Re-Engineering (cf. section 3.6.1)) of a context in the activities of business process management. Other authors consider only the technical aspects by IT as BPM. Following are some different citations to explain approaches and understandings of Business Process Management:

Business Process Management (BPM) is the practice of improving the efficiency and effectiveness of any organization by automating the organization's business processes. BPM used to be also known as Business Process Reengineering (BPR) [Anupindi et al., 1999].

Business Processes are market-centered descriptions of an organization’s activities, implemented as information processes (create, process, manage, and provide information) and/or material processes (assemble physical components and deliver physical product). A business process is triggered to fulfill a business contract or satisfy a specific customer need. [Media-Mora et al., 1992]

A Business Process Management System is a collection of activities organized to accomplish a business process. A task can be performed by one or more software systems, one human or a team of humans, or a combination of these. Human tasks include interacting with computers closely. A process is composed as a predefined order of tasks. Each task is assigned to a role. A role can be assigned to a group of persons or to only one person. Georgakopoulos [Georgakopoulos et al, 1995]

“An organization has a purpose. In order to achieve this goal as efficiently as possible, the work is broken down into a number of discrete functions. All functions work together to contribute towards the purpose of the organization. Each of these functions will have its own purpose and responsibilities, which contribute to the overall goals. In order to fulfill those responsibilities they create a number of processes, or ‘way of doing things in a repeatable manner’.”[Eriksson et al., 2000]

In this work, the notion “business process management” covers the whole domain of business processes, including the “theoretic, strategic part” of optimizing and re-designing processes “process analysis or business process (re-)engineering” and also including the “practical, operational part” of managing and executing processes often supported by IT systems. Furthermore, these two aspects are explained in section 3.6.1 and section 3.6.2.

89

3.5.3 History and future of Business Process Management Business Process management is one of the areas that, in recent years, have attracted the attention of researchers, developers and users. [Tersine, 2005] gives an overview of the development and evolution of the domain of business process management:

in the 1960s, the industry concentrated on how to produce more (quantity), in the 1970s, how to produce it cheaper (cost) in the 1980s, how to produce it better (quality) in the 1990s, how to produce it quicker (lead time) in the 21st century, how to offer more (service)

The term “workflow” began to be widely used in the mid 1980s. The technology evolved from work in the 1970s on office information systems [Nutt, 1996].

Although modeling was used in the 1990s in connection with business process engineering, the software tools were limited and not able to use real-world data as input, nor could the models be converted to production systems. The beginning of BPM was focused on the goal of automating processes by machines. The first experiences showed that in these processes, a human activity is still necessary and that the processes could not completely be automated, as changes occurred and the humans were the flexible element in changing the processes. Therefore, the business process research domain changed to support a human interaction in the execution of business processes. As a human interface is still necessary for the process execution, it is therefore more appropriate to improve the interface between full automation and human interaction, as well as research the support of flexibility in business process automation. Today, there exist two main, opposite approaches:

The approach of a Business process workflow system that supports the execution of processes by integrating different existing software tools to one and providing the needed functionalities for a process actor.

The second approach could be considered as the Business Process activity piloting where workflow systems manage the flow of a process without providing either needed functionalities or needed input information. The piloting provides only the place where information could be retrieved or which functions have to be done, but a support of the information treatment is not given. (for further information refer to [Estublier et al., 2003]).

The first approach should be applied to processes that need a simple treatment of information that could be provided through the action forms and treated through the application. The important part is a centralization and treatment of information. The second approach concentrates more on the execution of the process. The process context is very complex and different sub-processes exist and heterogeneous IT tools are used. It is important therefore to coordinate the process execution to avoid forgetting the execution of actions. The control of the complex process is more important than the centralization: Business process systems could be complex and heterogeneous and the integration in existing systems is too time- and cost-intensive. Furthermore, it is considered that the actors know where and how the necessary information could be retrieved. The problem and complexity that should be solved with this kind of process is the high number of complex processes in parallel. The piloting of the processes is more difficult than the retrieval of needed information.

90

Furthermore, in today’s concurrent engineering, processes are redesigned permanently and more and more exceptions occur during the process execution. Therefore, today’s applications are confronted by the need to handle these dynamic aspects of process execution in order to present and support the real executed processes.

3.5.4 Characteristics of Business Process Management The fieldwork, together with the study of the literature about the functioning and handling

of business processes, has allowed the highlighting of some important characteristics of such processes: Most business process management systems are represented according to four different, but related, perspectives: functional, behavioral, organizational, and informational [Van der Aalst et al., 2000], [Media-Mora, 1992], [Curtis et al., 1992], [Bussler et al., 1994], [WfMC, 1996].

The following diagram illustrates this relationship between the four perspectives. This diagram is essentially a meta-model for business process management systems and could be enriched depending on the specific context needs:

Figure 31: Four perspectives of a Business Process Management model framework [Zhao, 1998]

The entities of the figure above are explained in the following:

• Actors: An entity (human or computer) that can assume a role. An actor may take on multiple roles and a role may be assigned to multiple actors.

• Roles: A placeholder for an actor that is associated with the execution of a task.

• Action & Processes: a unit of work. In some models, actions are atomic. In other models, actions are decomposable. In this work, an action in a process can be decomposable in different functionalities.

91

• Data & Documents (Information Object): Data or Documents are the information objects manipulated in an action.

• Routes & Rules (Procedures): conditions for starting actions for the functionalities to be executed. Routes & rules combine data & documents, roles, tasks & processes and actors. They give rules on how these entities are related and how they are treated by a business process management system.

• Process: A partial or total ordering of a predefined set of activities in combination with procedures and rules.

• Tools: The dependencies between the different described elements (actors, roles, tasks and processes, information object and procedures) gave a process model built up with a well defined objective. This model is the basis for a tool managing business processes.

[Zhao, 1998] describes the four perspectives as follows:

• The functional perspective indicates that BPM needs to specify the actions and the underlying rationale of a process by decomposing high level functions into actions that can be allocated to human or software agents.

• The behavioral perspective refers to the need for specifying when and how the

tasks are performed; these can be specified using process logic in Petri-nets20, or other process models like UML [Larmann, 1999].

• The organizational perspective seeks to answer the question of who performs

what action and with what tools. In BPM systems, the organizational perspective involves actors, roles, resources, and resource management rules that can be modeled with organization charts and object hierarchies.

• The informational perspective relates to the business data and documents that are

the subjects of BP activities. In BPM systems, information is usually organized in object hierarchies or networks and stored in databases or file systems.

The figure above (figure 31) illustrates the different components and perspectives of a

business process model. Nevertheless, Business Process Management Systems generally employ models that are action-centered. The base of such system is the action related to humans, the process and the produced information.

Many companies have business processes that are unique to their own business model. Since these processes tend to evolve over time as the business reacts to market conditions, the BPM solution must be easily adaptable to the new conditions and requirements and continue to be a

20 Petri nets were invented by Carl Adam Petri to model concurrent systems and the network protocols used with these systems. The Petri nets are directed bipartite graphs with nodes representing either "places" (graphically circles) or "transitions" (graphically rectangles). When all the places with arcs to a transition (its input places) have a token, the transition "fires", removing a token from each input place and adding a token to each place pointed to by the transition (its output places).

92

perfect fit for the company. Furthermore, a business model is also context specific and has probably to respect local conditions within the business process even if the business process is globally defined for the whole company. Therefore, the processes within the same company could be different.

3.5.5 Types of Business Process Management Systems There are many parameters involved in a Business Process. A widely accepted taxonomy [Alonso et al., 1997] distinguishes between administrative, ad hoc, collaborative, and production processes. This classification is often based on the similarity that exists between different processes. Another way to organize and compare processes is also according to their task complexity and their task structure. These aspects are illustrated in the following figure:

Figure 32: A rough classification of Business Process Management system [Alonso, 1997]

In general, administrative processes refer to simple bureaucratic processes where the steps to follow are well established and there is a set of rules known by everyone involved. One example is a vacation request by an employee. The process could be very short as a request is initiated by an employee, validated by a manager and registered by the human resource. Typically, these processes are very short and always identical, but the number of executed process per year in companies could be very high. Ad Hoc processes are similar to administrative processes except for the fact that they tend to be created to deal with exceptions or unique situations. This depends on the involved users. For example, simple processes are often structured in the “plan-build-run” schema. This type of project could be considered as a process. For each process phase, the structure and tasks of a phase depends on the project manager and project team and current problems. Therefore, the execution of processes are differently structured and decided “ad hoc” for each process, even if they are similar. Therefore, the notion of “ad hoc” processes refers more to the notion of “project” (cf. 3.5.1) than to the notion of “process”, as changes occur and no unique process model exists that is valid for all process instances. The third class of processes, collaborative, is mainly characterized by the “big” number of participants involved and the interactions between them. Unlike other types of processes,

93

which are based on the premise that there is always forward progress, a collaborative processes may involve several iterations over the same step until some form of agreement has been reached, or it may even involve going back to an earlier stage. Therefore, the “ad hoc” process refers to the notion of “project” (cf. section 3.5.1). Differences between them may sometimes be difficult to explain. A good example is the resolving of occurred problems. Each process depends on the problem, its source and its involved participants. Depending on the importance and urgency of the problem, the resolving process is different and depends on the participant context. It could be compared to a workgroup resolving a problem. Production processes are the high end of these different Business Processes. They can be characterized as the implementation of critical business processes—that is, those that are directly related to the function of the organization. Production processes could concern the fabrication of products in a high volume, as well as the production of a prototype. Furthermore, a standard production process to produce a good or a service, as well as production process to produce a specific client’s product, could be distinguished. The goal and context of the production process might vary, but the procedure on how they are executed is the same. Credit and loan applications and insurance claims are the typical examples, but note that the difference between administrative and production processes is sometimes a matter of perspective. For example, in credit and loan applications the process of treating a new request is the process (production process). Each actor involved in the process has his or her own tool (custom relation management, risk calculation, context analysis, etc). Therefore, the request treating process could be considered in terms of production processes. However, the process is not very complex and is always the same, so a consideration as an administrative process could also be possible. Usually, when talking about production processes, the main points to consider are the large scale, the complexity and heterogeneity of the environment where they are executed, the variety of people and organizations involved, and the nature of the tasks. In particular, production processes tend to be executed over heterogeneous systems, frequently legacy applications, and it is very important to have monitoring tools to allow the statistical analysis of the execution of these processes. A good example could be the context of this work: the SWR Process at STMicroelectronic. The production of microelectronic products involves a lot of different steps and actors. Therefore, the production could be considered as a process. As different tools and actors are involved, it can be considered as a production process. The most commonly used types are the production processes as well as the administrative processes. Production processes represent one of the core domain activities of a company and will be optimized in permanence. On the other hand, administrative processes are easy to implement, as they are repeatable and not very complex. The implementation of ad hoc or collaborative processes becomes increasingly important, but companies don’t spend a lot of resources on the development and implementation for these processes, and the analysis of requirements is more important to propose a methodology covering a lot of possible cases of this type of process. Unfortunately, enterprises don’t spend a lot of money on the analysis of requirements and therefore the main source of failure is related to a bad requirement analysis as explained in the introduction of this work (cf. chapter I). However, the process type doesn’t depend on the result of the process. The process type represents the work methodology and interactions that are independent from the type of product or service to produce, as well as from their volume and from their importance.

94

Business Processes are profit-oriented procedures within the company, but they don’t evaluate the results. Changes could appear in the defined process for all types of different processes. Therefore, the aspect of flexibility and dynamism is discussed in the next section.

3.5.6 Dynamic Business Process Management (DBPM) Dynamic Business Process Management (DBPM) has to deal with the paradigm that, on the one hand, making business functions repeatable has several advantages [Turbit, 2005]:

By doing it the same way each time it becomes more efficient. It is easier to train people if the process is consistent. There is a smaller chance of mistakes if it is done the same way every time. Experience allows refining of the process to take into account situations that may be

slightly outside the normal range.

On the other hand, repeatable functions and process executions cannot be implemented, due to frequent and complex changes that make a standardization impossible.

“BPM not only involves managing business processes within the enterprise but also involves real-time integration of the processes of a company with those of its suppliers, business partners, and customers. Furthermore, real life work processes are much richer in variations and more dynamic than is delineated in a typical process model” [Suchmann, 1983]. This means that users need to be able to adjust workloads and modify Business Process models on the fly. In addition, data collected by a BPMS, mainly with process analysis/simulation tools, about process executions are analyzed to evaluate design alternatives during business process redesign [Palmer, 1996].

These facts pose at least three challenges for the implementation of dynamic processes: The structure of the business process model must be flexible enough to describe

variety in a process design and accommodate exceptions during enactment The process modeling facility must be expressive enough to allow analysts as well as

end-users to specify process relatively quickly and easily

The model must be structured to facilitate process analysis However, the goal of a business process is to identify repeatable flows in process and propose models based on these identifications. This gives a very high flexibility as independent actions that will be structures for each process refer to the notion of ad hoc processes or “projects” (cf. begin of this chapter). In this work, the flexibility of processes will be respected, but the goal is to support processes that are repeatable or that have repeatable parts. However, Bachimont [Bachimont, 2004] already emphasized that “models don’t model the reality, but propose instruments to explore the sources that humans put in relation with its

95

situation of use. A contextual, unpredictable interpretation and use can’t be modeled”. Nevertheless, the requirement of supporting the real process can only be satisfied by having a model approaching the real world process. Therefore, the process model should represent the real process (in a very detailed way or an abstracted way, depending on the use and goal of the business process) and changes in the process instances should help to adapt each process to its context. Van der Aalst [Van der Aalst, 2000] distinguishes especially between two different types of changes that have to be supported:

• “Predictable changes”: context changes for a process: “handling modifications of

specifications due to changing conditions”, i.e., duration, actors, data o Re-execution of the process or action o Decisive process execution (not all actions have to be executed) o Tracking of changes and re-execution of actions to allow to keep

information about the changes • “Unpredictable changes” for the process execution: “dealing with unanticipated

events resulting from an incomplete process flow model.

o Changes in the business process model – changes will impact new launched business processes

o Changes in the business process instances – all current instances will be modified. These changes are still an unsolved research problem, as the risk of data incoherence in the business process system is very high and the decision to re-execute a part of or the whole process has to take into account the changes of the process flow.

Therefore, business process models must include these changes to get a business process model that represents the “real” world (identical to the executed processes) as closely as possible. Furthermore, for a complex process, it might be more successful to use a business process at an abstracted level in order not to deal with every dynamic aspect as explained in section 3.5.6. The precision of the business process to the real executed process depends on the goal of the use of business process. Therefore, three different approaches of business process management are known [Godart et al., 1999], [Georgakopoulos, 1999]:

1. Considering the process as action source: adding a flexibility by changing the process structure. The process is a guide to construct the specific action plans. The user is free in the order of execution of these actions.

2. Use the process as constraint: a process is defined and cannot be changed. The process flow (action order) has to be adapted dynamically during its execution.

3. Consider the evolution of the process model: The flexibility has to be modeled and anticipated. All changes will impact new process’ instances.

These three types are especially important for the application of BPM systems as they impact the user behavior and should respond to the need of the users. For a brief explanation of existing projects in handling the dynamism of business processes, refer to appendix 7.4.

96

3.6 Practical aspects of Business Process Management The application of the domain of Business Process Management to an industrial context is divided into two different parts:

Creation: Business Process Analysis or Business Process Re-engineering to design or re-design a process model

Application: Business Process Management System, also called Workflow Management Systems, to support and control the execution of a process via IT

These domains interact with each other with the goal of defining a generic process model that could be used to manage process instances via IT. Interactions are especially necessary to adapt the process model and IT functionalities if the process and user needs evolve, as this could impact not only the process model, but also the current existing process instances. In order to clarify these distinctions, the BPR and workflow are explained in the following sections.

3.6.1 Business Process Re-engineering

Before implementing a business process management system (BPMS), organizations generally develop a model that provides a visual representation of the system to make sure all the parts of the process are logically connected and work together well. Therefore, Business Process Analyzing (BPA), better known as Business Process Reengineering (BPR) has become increasingly important. BPR is defined as “Fundamental rethinking and radical redesign of business processes to bring about dramatic improvements in performance” [Hammer et al., 1993]. BPA or BPR is often considered as restructuring, reorganization or automation. In fact, changes initiated by BPA or BPR activities impact the enterprise processes, the technology, the organization and the culture. “Reengineering became very popular in the early 1990s, however, the methodology and approach was not fully understood nor appreciated. Many times, improvement projects labeled with the title "BPR" were poorly planned and executed. Despite this abuse of the practice, the practice of redesigning business processes and the associated technology and organizational structure is more popular today than ever.” [Prosci, 2005].

Different approaches exist for Business Process Re-Engineering as well as different software tools supporting the process formalization and analysis. Various approaches to BP modeling can be found in the literature [Reichert et al., 1998], [Sadiq et al., 1999], [Carlsen, 1997], [Casati et al., 1995], [Kuo et al., 1996], [Rajapakse, 1996]. Today, there is no generally accepted methodology for modeling business processes. Petri nets are traditionally used to describe and analyze concurrent systems, but different approaches exist to model the process and system. As there is no current method to represent and model business processes, there is also no common method for analyzing business processes, because analysis results include the way analyses are done. One of the analysis approaches that helps in analyzing the processes and structures and the interviews conducted with involved actors in order to generate a process model is the method H, which is presented in the following section.

97

3.6.2 Business Analysis approach: Method H The method H is an analysis approach to formalizing business processes. Its author, Turbit, [Turbit, 2005] pointed out the problems and suggestions for applying the method H:

“Many Business Analysts start a conversation with employees by asking what they do. The conversation tends to drift in no particular direction until a thread is sighted, then the BA follows that thread to the end. The next thread is fleshed out and a similar process followed. Hopefully, by taking enough random walks around the person’s job, sufficient information will be collected to come up with a requirement. […] By applying the method H, the discussion will start on inputs and outputs but quickly expand to functionality. As data and business rules emerge, they can be noted. The interviewed person should understand how to record information into the ‘Model H’ and the type of information that will go into each box.” Analysis could therefore go according the following H-structure:

Figure 33: Method H template (Input, transform, output) [Turbit, 2005]

- The left and the right cases, “Input and Output”, formalize the used and produced information. This can define the scope of a user involvement goal at this process level and answer the questions “What do other people give you?” and “What do you give other people?”

- The middle case, “Functionality, business rules, data”, will capture the function of how input information is transformed, based on business rules and data, into an output. This analysis should answer the questions “What do you do?”, “What rules apply?” and “What do you need to keep track of?”

The H-method was applied in order to characterize the experiment processes at STM. It was not directly applied during interviews, but represented the basis for a structured process analysis during interviews. However, even if the process and the information are analyzed though this approach, this approach is not very well adapted to complex processes with a complex infrastructure or context as production processes21, as the source of information is not characterized and analyzed. Furthermore, knowledge management aspects are not implemented in this approach. The goal is to analyze only the process flow and identify which information is related to each action in the process. A deeper analysis or relation are not provided, nor are aspects of change management or user resistance respected.

21 For characteristics about production processes refer to section 3.7.5.

98

3.6.3 Workflow Management Systems Business Processes are often supported and managed by IT tools called workflow management systems. The commercial activities in this area have increased dramatically in the last few years since the start of the Workflow Management Coalition in 1993 [WfMC, 1996], and are implemented in many organizations. The goal is to support business process enactment and analysis via an IT tool. To this end, the notion of “workflow management systems” has been established in the recent years. A workflow management system (WFMS) is a software component that takes as input a formal description of business processes and maintains the state of processes executions, thereby delegating actions amongst people and applications. In this case, the management emphasizes the ability of workflow engines to control process flows, automatically measure processes, and to change process flows from a computer terminal [WfMC, 1996]. The workflow management coalition defines workflow management as “the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules” [WfMC, 2005]. Workflow management systems could be characterized as follows:

A collection of tasks organized to accomplish some business process Performed by software systems and/or humans Composed as a predefined order of tasks A task is assigned to a role A role can be assigned to a group of person or to only one person.

In general, workflow management systems (WFMS) are used to coordinate and streamline business processes. These business processes are represented as workflows, i.e., computerized models of the business process, which specify the individual action steps, the order and the conditions in which the activities must be executed: the flow of data between activities, the users responsible for the execution of the activities, the tools to use with each activity, etc. A WFMS is the set of tools that allows the design and definition of workflows, their installation and controlled execution, and the coordination and integration of heterogeneous applications within the same workflow [Hollingsworth, 1994]. Users interact with the WFMS by accessing their individual worklists, where they can find the activities for which they are responsible without necessarily being aware of the higher level process to which the activities belong. Galler, Hagemeyer and Scheer [Galler et al, 1995] describe the life cycle of workflows as follows: “The development of a workflow application starts with analyzing and modeling the business process. The business process model is the input for the workflow system development which results in a workflow model, typically implemented in a workflow language. The transformation of business concepts (expressed in Business Process Models) into information systems (for example WMS) is not a simple derivation but a creative process which includes many feedback loops between organizational experts (business analyst) and technical experts.“ The state of the art in workflow management has been determined so far by the functionality provided in commercial systems. Paradoxically, this has been a major source of limitations. Many products were developed without a clear understanding of the user requirements and, as any serious workflow practitioner can testify, these products were quite unprepared to meet the demands placed upon them by eager users. To understand this, it is necessary to understand the background of workflow management.

99

In the following, major functionalities of workflow management tools are presented:

Key Components of Workflow Management: supporting the classical relation and parts of a BPM model (cf. section 3.5.4: tools, actors, roles, rules, action and process and data&documents)

Graphical Process Building, Modeling and Execution: a graphical user interface for the modeling, but also for the process instances to allow the user to position his or her work in the process context (the need of the functionality depends on the goal of the business process management system) (cf. section 3.5.5).

Customizable User Interface: each user has different actions to do and, for each action, different functionalities to execute. Therefore, each action interface within a process should be customizable to show the user the information he or she needs.

Real-Time Process Monitoring and Reporting: WMS manage a lot of processes at the same time. Therefore, it is important to provide real-time reporting to give a synthesized view to the users (action owner and managers of such a system).

Integration Tools for Linking Existing Business Systems: As explained in chapter 3.5.5, business process could consist of different heterogeneous IT tools. Therefore, it is important to combine a WMS with current existing WMS and other IT systems in order to provide the needed information and functionalities through one user interface in one IT tool. Therefore, the use of ontologies has become more and more important. In sections 3.2.4.4 and 3.3.1, ontologies were explained and the use of ontologies was illustrated. [Korhonen et al., 2002] transferred the application of ontologies to the workflow domain to combine different heterogeneous workflow systems. The goal is to execute one process over different workflow systems by combining the parts of the different workflows per system to one process via ontologies. The ontology’s key concepts are the identified process and the identified task. By completing a task or a process in a system, a task or process could be opened in another system supported by the ontology relation. The different processes of different system are linked with each other over an ontology.

These functionalities should be integrated into a tool that supports the workflow management.

100

3.7 The current Knowledge Management practices implemented in Business Processes

The produced knowledge during each action (artifacts) or the intermediate knowledge produced in each action, as well as the final knowledge, presents the surplus value in terms of Intellectual Property for the company (cf. 3.2.4.3). The produced knowledge within a process is used directly in the same process in order to produce a good or a service. In today’s context of concurrent engineering, the cooperation, expressed through information sharing across organizational barriers, becomes more and more important. Two different types of such systems were previously discussed in this work. The first type (cf. 3.3.3.2) is the unstructured knowledge sharing practices via groupware, intranet, and document management. Knowledge itself could be structured within these applications, but the knowledge diffusion is often unstructured. The second type discussed is workflow systems (cf. section 3.6.3), in which knowledge diffusion is structured uni-directionally during the process execution. Groupware systems provide too little structure and guidance, whereas current workflow techniques are not flexible enough to support virtual corporations, except in a very limited way. To initiate and improve knowledge management activities in business processes, it is important to concentrate on both of these factors. According to [Georgakopoulos et al., 1995], the major differences between process types are:

Information process complexity Access to multiple information systems to perform work and retrieve data for making

decisions (administrative processes rely on humans for most of the decisions and work performed)

Therefore, the integration of different information sources with the business process to merge them into the right task, as well as to initiate a re-use for later processes, is important. In the following, current frameworks of existing combinations are discussed.

Plesums [Plesums, 2002] emphasizes that the “rendez-vous” aspect (automatic matching of incoming information to the work that is suspended) of workflow management system becomes increasingly important as today’s information is produced with a large number of different tools. The importance of integrating knowledge management into process management has already been discussed by different researchers: Zhao [Zhao, 1998] defines a knowledge management model in business process management systems while concentrating in particular on three different types of knowledge:

• Process knowledge that contains the description of tasks, roles, rules, and routes. • Institutional knowledge that describes the roles, the actors, and business

procedures and regulations. • Environmental knowledge that describes the business environmental factors such

as governmental regulations, industrial associations, competitors, and customers. Knowledge retrieval is frequently only concentrated on the three described types of knowledge (process, institutional and environmental), often to understand the context or to get a synthesized view (process state, due date, actors, etc.). During the execution of a process, a huge amount of knowledge is produced and consumed in later tasks. It is difficult for an employee to match the incoming information to the right process as well as to check

101

each time whether all needed information for a task already exists to start its execution. [Zhao, 1998] calls this a just-in-time knowledge delivery. It is important to enlarge these perspectives with another one as our field study suggested that the added value of a process is also the produced result, as these results formalized as documents contain the Intellectual Property of the microelectronic fabrication processes. These categories also match the defined perspectives in section 3.5.4: functional process knowledge, organizational institutional knowledge and behavioral environmental knowledge. These perspectives are enlarged with another one as the field study suggested that the added value of a process is particularly the produced result:

• Information perspective Content knowledge that represents all data and documents produced during the execution of a business process as well as contextual information to describe and structure the context of a process and its produced information

3.7.1 Observations of relations between changes in processes and information

For each action it will be determined where the information comes from, and which actions have to be finished in order to open the following actions(s). This analysis helped to formalize conditions for the opening or re-execution of actions. The obtained results are the conditions for opening an action.

A task can be opened if:

all required previous tasks are finished all needed information is available

Information changes could cause a re-execution of the process or of a part of the process. The workflow execution depends not only on the task order and the process flow, but especially on the information and its changes.

This information dependency does not only exist within a process. It could also exist between processes, as in a concurrent engineering environment, parallel processes could profit from the results of similar processes by avoiding the same errors again or improving the competence of employees, as well as improving the quality of the process.

This fact implies there are different needs to profit from knowledge management approaches implemented in the Process Management, as the process execution depends on the treatment of information. This is especially true for the context of knowledge intensive business processes. Different models already exist to combine process and knowledge management. In the following, two models are discussed which seem to be important, as their uses match the goal of this work in combining knowledge and processes:

Relation of knowledge to business processes

102

KDML (Knowledge Description Modeling Language): an approach to model knowledge in business processes

3.7.2 Relation of knowledge to business processes “Corporate memory” (cf. 3.2.2.3) should allow keeping and diffusing knowledge within an organization, especially over organizational barriers (barriers that are, i.e., due to different departments, or due to different transversal processes). Mata [Mata et al., 1999] already mentioned that the produced and constructed “corporate memory” knowledge will be used as know-how in industrial business processes, as illustrated in the following figure:

Figure 34: Knowledge related to business process [Mata et al., 1999]

The used knowledge in industrial business processes produces “experiences” that will be analyzed. The analysis result will be distributed as experience feedback and also capitalized as “corporate memory”. It is then available for a re-use in different processes. This model points out the relation between knowledge and business processes. In addition, the knowledge Creation-Diffusion-Re-utilization-process is analyzed and illustrated separately in order to demonstrate the construction of the “corporate memory”. The relations between the knowledge capitalization and the diffusion to the business processes are not illustrated. The model represents the relation between knowledge and process, but does not deliver an approach on how this relation is structured and how it should be implemented in organizations. One method to represent the relation of processes and knowledge in a structured way is the KDML language presented in the following section.

3.7.3 KDML: Modeling knowledge in business processes The Knowledge Description Modeling Language (KDML [Gronau et al., 2004]) is an approach to illustrate the places in business processes where knowledge is produced and could be reused in order to detect improvement possibilities for knowledge management activities. Therefore, the language modeled the processes, the knowledge and the knowledge flow as well as barriers that prevent an efficient knowledge execution. A deeper explication of the KDML and the figure below, as well as a legend for the KDML, is given in appendix 7.5. An analysis of needed knowledge and available knowledge could result in a gap analysis,

103

illustrated by a KDML picture to see “knowledge” flow within a process as well as problems or optimization possibilities for the knowledge flow. This approach relates knowledge and process flows. The distinction between these two flows allows the identification of the barriers of knowledge flow within a process. This approach was applied to the domain of experiment processes to identify the knowledge flow. Based on the previous analysis results from the H-method (cf. section 3.6.2), and due to the problems discovered in interviews (cf. section 2.4), the process and related knowledge flow could be represented as illustrated in the following picture:

Figure 35: Example for a KDML modeling of a SWR process

The process is modeled as a relation between tasks. Each task produces an output representing the knowledge. In the experiment process domain, the SWR document is produced and sent to the area engineer. He will prepare and execute the experiment based on the received information. After the experiment is executed, the final analysis is done. (This process structure was previously discussed in section 2.3.1). However, before producing the document, different knowledge is needed as illustrated in the figure above (i.e., responsibility for an operation, information produced, etc.). In the figure above, the Knowledge flow is represented around the process. Implicit and explicit knowledge flows are discussed and highlighted. The model is appropriated to formalize process and knowledge flow within a process. Its results deliver a gap analysis and places where knowledge exchange should be improved as related to the execution of the process. Therefore, the model is only concentrated on improving the process flow, meaning the knowledge flow in order to produce a good or service. A backwards analysis of the process or between processes is not provided explicitly by this language. Furthermore, the analyzing approach is still missing: even if the KDML result is structured and clarifies the understanding of a context, the approach of how this result is produced is not implemented in the KDML language.

104

3.7.4 Needs for the implementation of knowledge management practices in Business Process Management

The traditional workflow systems provide an “action inbox” giving an overview of open tasks for each user. The process structure, process state or intermediate results of processes is often a “black box” for the user. Currently, it becomes increasingly important to introduce knowledge retrieval into current processes (i.e., actual state, problems, implicated actors, etc.) as an increasing number of processes are executed in parallel and the goal of these processes, treated information, could be similar and therefore be reused between processes. These processes could be similar and profit from intermediate results (cf. section 2.2). More and more processes are executed in parallel and more and more information is produced in different tools. For each task type in a process, a specific information type will be needed and produced. The dynamic aspect of these business processes is difficult to take into account (cf. section 3.5.6). Context is essential to understand and to internalize the knowledge correctly (cf. section 3.2.4.2). It is very knowledge intensive and important for the understanding of the knowledge. As the business process is dynamic—meaning that often changes occur—it is first of all difficult to manage the process correctly. On the other hand, it is difficult to provide the right context information to describe the produced knowledge correctly, as the knowledge depends on the context used for its internalization. It is therefore important not only to merge information to the right task, but also to give enough context to this information to support the immediate use as well as a later reuse (cf. section 3.2.4, cf. section 3.2.4.4).

Assuming the acceptance of Workflow Management Systems (WfMS) in the industrial field, knowledge management activities could be implemented in Workflow Management Systems. Workflow management systems represent the real processes. An Integration of knowledge management activities in the business process management supported by workflow management systems allows capitalizing the knowledge at its source and therefore in “real”22 time (cf. section 3.3.2) . The information flow is part of the process, but it may be different from the workflow. The workflow is a predefined work order, but the information could circulate within, backwards or between processes to anticipate work coming due, reuse information or have a return of results. The focus of current implemented knowledge management activities is on the process execution and process improvement. Presently, the research in Business Process Management is neither concentrated on an implementation of “cross-over” knowledge management sharing activities between processes, nor is an implementation of a “backwards” knowledge flow within the process one of the main goals (cf. section 2.6). However, knowledge management approaches could enrich the approach of business process management. It is difficult for process actors to retrieve knowledge from different processes. Capturing this knowledge at its source by integrating knowledge management aspects in workflow management systems could be one of the best practices to capture a maximum of “useful knowledge” as well as to introduce a knowledge sharing and utilization within, backwards and between processes. Additionally, the contextual information of the processes, as well as of the related and produced information, are used as annotations and could be used for a better knowledge retrieval as well as for a better internalization of the information to build up the initial knowledge. Therefore, the annotations of information with contextual information (cf. section

22 The notion “real” is probably not well appropriated, as the capitalization is done not during the knowledge creation, but during the formalization and storing in a workflow tool.

105

3.2.4.4) supported by ontologies (cf. section 3.3.1) should be integrated in a Workflow Management System (WFMS) that provides not only information merging, but also knowledge retrieval based on the capitalized contextual information in particular. [Zhao, 1998] wrote that the functions of organizational memory and organizational learning are now generally missing in commercial workflow management systems: integrating the internal and external information and knowledge resources (as discussed in the last section) so that knowledge retrieval becomes more efficient. The discussed needs in the previous sections are summarized in the following table:

Need for an analyzing approach of the process flow Need for an action center-based /actor-based approach Need for an analyzing approach of the knowledge flow within, backwards and cross-

over processes and analyzing the produced knowledge and its contextual information Need for an analyzing approach of functionalities done by involved actors Need for a respecting of characteristics of change management Need for an analyzing approach of different existing information systems Need for an implementation approach for a method improving the management of

knowledge intensive business processes Need for a guideline to implement a new system regarding the context (based on the

analysis results)

Figure 36: Needs for implementing Knowledge Management in Business Process

106

3.8 Proposition of the problematic Based on the explained industrial and scientific framework in the previous sections, capitalization, diffusion and re-using of pertinent information within processes by managing and structuring the information flow could optimize the process execution (cf. section 2.6.3). Therefore, the knowledge must be capitalized at its source not only for an immediate re-use within the process by merging it to the right tasks, but especially for a later re-use in different processes. The difficulties and the industrial problems in improving the experiment processes and characteristics were described in the previous sections as, for example, knowledge structuring by ontologies, user resistance, and dynamic business process management. The most important aspect is therefore that a new methodology (including Knowledge Management aspects) has to be integrated and support the daily work activities for an employee. Furthermore, the implementation of the methodology must be supported by the management. The main problem is still therefore to analyze the employees’ needs and combine a solution with the knowledge and process flow.

The problematic could be formalized as follows:

How can the knowledge creation activities related to business process be analyzed with the goal to support and implement “real-time” knowledge capitalization into business

processes? How to implement and improve knowledge creation activities that focuses especially on keeping the produced knowledge in time and on initiating a knowledge sharing across

organizational and process boundaries?

The problematic is to develop an analysis approach to capitalize produced knowledge during the execution of business processes as early as possible to guarantee a real time follow up and update. At the same time, not all produced knowledge could be capitalized as informal and implicit interaction always exists. Furthermore, it is not efficient to capitalize all knowledge as the capitalization will take more time and could retard the process. Therefore, an analysis approach of knowledge intensive business process should also take into account which knowledge must be capitalized and correspond to an identified user need. Therefore, it is not only important to capitalize the knowledge to support the execution of the process. The produced and capitalized knowledge should also be re-used backwards through the process and between processes. A backwards flow should allow improvement in the quality of an employee’s work, as he will be informed about the final result of the process he was involved in. Furthermore, the produced knowledge can be reused for new processes and improve the quality as previous results or ideas could be reused. Additionally, the reuse could also avoid making the same error again.

The captured information should be available for consultation for every user. The difficulty is in supporting the process by structuring and optimizing it as well as in capitalizing enough knowledge and contextual information, but not too much knowledge for an immediate and later reuse. These facts could be considered negatively as knowledge capitalization demands a higher workload for the employees. The improved process management must compensate for this higher workload, and this compensation needs to be accepted by the employees.

107

Structuring and capturing this information should not only permit comparing of information to existing or previous work, but especially capturing problems in an early state before any steps are taken to resolve it. The problem resolving process should be captured and shared from the beginning to the end.

The capitalization of this information and its follow-up by its integration and combination with process management techniques should guarantee a dynamic real-time information base.

Even if the real-time information base contains only the most recent update of validated information, it will be difficult to anticipate the knowledge retrieval possibilities or employees’ behavior when confronted with the changed context.

This kind of “real-time” capitalization of information by its integration and combination with process management techniques should guarantee a dynamic real-time information base.

Some major organizational problems are listed below:

Organization Problems:

How to harmonize the different established work methodologies to only one? How to understand and analyze the problems and needs of employees related to

knowledge intensive processes? How to analyze the produced knowledge, its source and its role to the business

process? How analyze the process and its dynamic aspects? How to support the knowledge capitalization and the merging to a correct reuse

situation? How to characterize and estimate a user resistance?

To sum up, the problematic is to capitalize the experiment information and its context as early as possible in order to guarantee a real time follow up and update. The captured information should be available for consultation for every user. The difficulty is supporting the process by structuring and optimizing it as well as capitalizing enough knowledge with its context for an immediate and later reuse. These facts could be considered contrarily as knowledge capitalization demands a higher workload for the employees. The improved process management must therefore compensate for this higher workload.

108

3.9 Conclusion This work is concentrated on finding ways to benefit from the knowledge produced throughout the execution of processes in order to improve the knowledge flow within a process and between processes. Therefore, knowledge management activities must be integrated into business process management. Although the scientific and industrial interest of Knowledge Management (KM) has been established only in recent years, many Knowledge Management activities exist and many experiments also have been done, showing that concrete application methods of implementing knowledge management are still lacking, and a concrete return of experience is difficult to measure. The important aspects of the needs and characteristics of implementing KM activities include: A combination and balance between IT, humans and context are primordial; Knowledge exist in humans and a Knowledge Management System is not only a software tool, but have to take into account the human system and the human knowledge creation process: Software, humans and knowledge are part of this system and all components have to be taken into account. Due to human behavior, knowledge capitalization is often considered as overload. Therefore, knowledge capitalization activities have to overcome the human resistance by giving high surplus values or other incentives to the potential user. Furthermore, the creation of knowledge is a dynamic process and the knowledge sharing process cannot be considered as a linear process. Therefore, linear models of knowledge diffusion seem to be less appropriate. KM activities should also take into account the changing environment where knowledge could change and quickly become obsolete. KM can be supported by IT, where much experience exists. The last few years have especially shown that these tools are complex and their use cannot be completely anticipated. The use of information sharing tools could be different from the initially defined goal. Furthermore, other opportunities could appear by using this tool. The implementation needs a survey of human behavior as well as a survey of the knowledge shared by this system and a permanent adaptation. Even if some experiences of IT and KM have not been successful in the last years, both terms are still related. In order to guarantee a successful implementation, knowledge must be captured at its source, as it is produced during daily work. Different types of Business processes were discussed. The type of business process is often characterized by the complexity of task and process structure, the number of involved actors and the used infrastructure of heterogeneous information systems. The type also depends on the goal of the business process and the objective of the process structure and its flexibility. Knowledge management activities in business processes should combine knowledge capitalization, diffusion and re-using activities during the executed actions. Currently, approaches to the combination of both of these domains are concentrated in merging knowledge to the right task. A knowledge flow backwards or cross-over through processes is not supported. Analyzed approaches and implementation methods exist, but are not concentrated on the knowledge sharing factors across organizational and process boundaries.

109

4 GENERAL SOLUTION: PIFA approach to analyze knowledge intensive Business Processes

This chapter explains the abstract solution PIFA, an analytical approach to integrating knowledge management approaches into business processes. This approach distinguishes between the Process, Information and Functionality levels.

4.1 Introduction

The previous chapter described how knowledge is produced and used in business processes in order to produce a good or service. The hypothesis of this work, that knowledge management activities have to be integrated in daily work to capitalize all produced knowledge (positive and negative experiences, etc.), was therefore explained. Introducing knowledge management aspects in Business Process Management can provide the necessary information to the right people as well as reuse information from existing and already executed processes. Therefore, the information flow must also be established between different processes, forwards and backwards within the processes.

According to a study by [Van der Aalst, 2000], there is no general tool responding to all requirements. Therefore, it is primordial to understand and capture the requirements concerning knowledge management and business process management for a specific context. Different approaches [PMI, 2000], [Turbit, 2005] and modeling techniques [Gronau et al., 2004] already exist to analyze and formalize the knowledge flow and its associated business process.

Furthermore, these approaches are insufficient, as they are concentrated on producing a new tool, either a KMS or a workflow tool. These aspects have to be combined and an IT tool should also be a KMS and Workflow system at the same time. In usual daily work, more and more information tools are used and implemented in order to make actions easier and improve the working conditions. These changes also impact the business processes as information needed for the process is not delivered with the action description, but has to be retrieved from different sources as humans and IT tools. Furthermore, the focus is not the production of an IT tool, but the understanding of the current situation in order to understand, act and re-act concerning the knowledge flow, its associated business processes and in its given context. Therefore, organizations should stop focusing exclusively on data and data management, and adopt a process-oriented approach of process, information and knowledge management. The PIFA approach was developed to capture and combine these requirements of the different domains and of the different involved actors and managers in these knowledge and business processes. The idea of PIFA is to bring processes, people and knowledge together.

In the following chapter, different aspects discussed in the previous chapter are first put

into one model that groups the requirements of introducing knowledge management activities

110

in organization. Based on these requirements, the PIFA approach that helps to capture these different requirements is discussed and illustrated. The focus is especially on the three levels of PIFA (Process, Information and Functionality) in helping to capture

a process flow that represents the “real world”, the produced information types and how to structure them, and the required functionalities to give an immediate surplus value to the actors.

4.2 A Knowledge Management Implementation Approach Based on the facts and requirements described in the previous chapters (surplus values, change management, resistance and problems of knowledge management and its associated support by IT-tools), these facts (cf. chapter 3.2 and 3.3) are summarized in the following four guiding ideas to introduce Knowledge Management (KM) activities responding to a knowledge need:

• Capitalized knowledge should respond to an identified need. • Capitalization activities should be combined with an immediate surplus value and

be integrated in the daily work in order to break down the barriers of knowledge capitalization.

• Knowledge management activities should be adapted to changing context conditions.

• Knowledge management activities should be supported by the management.

These four guiding ideas are the basis for the following figure:

Figure 37: Our Methodology to implement KM activities [Busch, 2005b]

A KM methodology should be developed on the basis of current work methodology to take into account the employee’s behavior and functions, as well as the need to give him or her an

111

immediate surplus value. The observation of the current work methodology to understand current practices and problems help to identify improvement possibilities. On the other hand, a KM methodology should be developed on the basis of defined KM goals that characterize the objectives of the information sharing and represent the initial motivation for the changes. It is important for a sophisticated analysis to concentrate on the information sharing aspect in order to identify a surplus value for the user. The defined KM goals could therefore be the desired surplus value for the company as defined by the management, as well as based on the analyzed and proposed surplus value defined by the users (identified user’s knowledge need). Thirdly, the KM methodology will be developed for a specific context. “Best KM-practices” are useful and could be reused, but have to be adapted to the context, as working methods, organization, culture, etc., differ from case to case. Therefore, the formalization of the working methods allows understanding the context in a better way. Based on these three described factors (working methodology, context and KM goals), a new KM methodology is developed that will be integrated in the daily work and should change the current working methodology by the integration of Knowledge Management activities into the existing work methodology. As employees could resist changes, the implementation of a knowledge management method has to take into account aspects of the change management. The change could be efficient if the new work methodology has a balance between three factors:

implications of the management deploying the new method

motivation due to a high surplus value

resistance due to the changing work method

It is difficult to deploy a knowledge management that is integrated in a new work methodology only by formation of the employees or by diffusing new processes. Therefore, IT-tools are often used. The new working methods will be supported by a tool to be deployed. However, the availability of a tool does not guarantee its acceptance and its deployment—neither the deployment of the tool nor the deployment of the new methodology. To sum up, in this chapter the requirements to be taken into account to develop a new work methodology that contains KM activities are summarized. Different models already exist to structure Knowledge Management activities, but a model approach of how to implement Knowledge Management activities is still missing. In the following, the PIFA approach is presented, which helps to capture these requirements, especially the working methodology (process flow and functionalities) and the knowledge needs (information flow). This approach should especially be considered as an aid in how Knowledge Management could be implemented in the context of knowledge intensive business processes as it is based on the process flow, the produced knowledge and the actor’s behavior and culture.

112

4.3 The PIFA approach - an analyzing methodology

4.3.1 The different entities of PIFA Our method, PIFA, has been developed in order to formalize a process and capture the related information flow and executed functions. The distinction especially allows the formalization of which information is needed and desired (cf. section 3.2.2.2) to execute an action. The basis of the analysis is therefore the action of a process, which could include different functionalities:

Figure 38: Principle of the PIFA analysis [Busch et al., 2006b]

Processes are the structured execution of actions. An action (central circle in the schema above) can be executed if all opening conditions (oc) are met. These conditions are distinguished as workflow conditions (W) and information conditions (I). Information could be transferred in implicit (Impl.) or explicit (Expl.) form. Once all conditions are met, the action can be executed by a person having the competence to execute the functionalities. After completing the action, the following process flow from the information flow (explicit/ implicit and sent to whom/saved in which tool) is also distinguished. These are considered as finishing conditions (fc). Each action can be composed of the three following parts:

The Input: (opening conditions for an action): All dependencies of previous actions, as well as all needed information to start its actions are identified, as well as its format and its source. The source of this information can be human or an IT tool and it is transferred in an explicit or implicit way by pushing or pulling methods23.

o Which information is needed? (“How?”, “Why?”) o Which information is desired? (“How?”, “Why?”) o Where do they come from? (“How?”, “Why?”) o Which action has to be finished? (“How?”, “Why?”) o Which information nature is used (implicit/explicit)? (“How?”, “Why?”)

23 The information treated in the process flow will be analyzed especially in terms of knowledge management activities in order to improve the knowledge flow. Therefore, the questions (How? and Why?) are important as discussed in section 3.2.

113

The Functionalities: Most of the needed functionalities that are part of the action are

identified based on information and on business rules. For each action, a group of persons is identified who have the competence to execute the action. This group will be characterized by a name as well as the role that identifies the analyzed action with a person or a group of people. Therefore, we will establish the relation of a BPM model described in section 3.5.4.

o Which business rules have to be applied to transform the input in new

information? o What are current problems? o How can they be improved?

The Output represents the produced information during the execution of an action: following actions depending on the results of the actions will be identified as well as all produced information and where it is stored or send to. Therefore, the relation between actions is formalized as well as the information flow.

o Which information is produced? o Where is it or can it be reused (needed and desired)? o Where is it stored? o What is the following action?

This characterization is explained in more detail in the following: Figure 39 proposes the PIFA approach in a complementary and more detailed way than figure 38. Each action is composed of three entity parts:

The core of the analysis (the Input, the Functional and the Output) has already been described in figure 38 above.

Each action is related to a process and has a specific context.

A process is unidirectional to produce a good or a service, but it might be necessary or “convenient” to introduce an information flow backwards through the process to give a return of experience (REX) to all involved actors as well as to introduce a cross-over knowledge sharing between processes.

114

Figure 39: PIFA template – Process Information and Functionality Analysis [Busch et al., 2006a], [Busch et al., 2006c]

The three main entity parts (heart, context, REX) are detailed in the following sections.

4.3.1.1 Core (Input, Functionality, Output): These three parts are the core of each action and their structured order of execution defines the process flow. For each action, it is described which functionality is required and on which data the functionalities are based. Additionally, the produced output is the result of the functionalities. The capitalized knowledge in a process is considered as needed knowledge (cf 3.2.2.2), as it is produced and used within the same process immediately. Furthermore, knowledge sharing activities should envisage reusing existing knowledge as desirable knowledge (cf. the notions of “needed” and “desired” knowledge in section 3.2.2.2).

The source of this information can be human or an IT tool and information is transferred in an explicit or implicit way (cf. the notions of “implicit” and “explicit” in section 3.2.2.1). The identified categories for Input/Output information are the following:

• Name (free text) • Context description (free text and categories) • Source (Person (Role)/Tool) • Information Type (Necessary/Desirable) • Transfer Type (Explicit/Implicit) • Transfer Method (Push/Pull) • Transfer Support (email, phone, tool) • Starting Conditions for activities

115

Starting conditions are very important for the process flow to determine when an action can begin to be executed. Additionally, information and context can change. Therefore, some actions probably have to be executed again. A categorization by each of the items on the list could help to identify and structure the produced information and classify the process.

The core of an action is the work to do and requires that different functionalities be executed by the user. These functionalities are based on the input and on different business rules that define how the input will be transformed to an output supported by the functionalities.

By applying PIFA, it is also important to keep in mind two additional aspects of a process analysis: The information flow backwards through the process (feedback or return of experience) and the context characterization of the process and its produced information as described in the following. The return of experience in particular is important to inform involved process actors if the final results are positive or not. 4.3.1.2 The return of experience

A process is unidirectional to produce a good or a service, but it might be convenient to introduce an information flow backwards through the process to give a Return of EXperience (REX) to all involved actors as well as to introduce a cross-over knowledge sharing between processes. Therefore, part of the analysis should be to identify all desired return of experience about a process, type of process or an action. Furthermore, all or part of the capitalized information of a process could have an interest for any actor involved in the same or similar processes. Therefore, it is beneficial to define the return of experience they want to have on their actions: desired information regarding to future processes and results in order to verify if their work had positive results. This return of experience could help to improve the personal competence of an employee by putting already completed work in the context of the process and comparing it to the result of the process. Therefore, a global analysis of the process must be performed to identify which information employees require and desire as a return of experience, based on synthesized process information. The process flow is often mono-directional, but the information flow can be bidirectional for a summary view, feedback, etc. As the actors have different needs, the specifications of information filters are necessary and are part of the identification of the REX flow (for further details, see the use of ontology for Knowledge Retrieval in section 3.3.1).

4.3.1.3 Context A process has a certain context. It is necessary to describe the process and the associated information. Each action is related to a process and has a specific action and process context. A part of the context can be formalized as information - contextual information. This contextual information could already be produced at the process initialization or otherwise during its execution. The context could help to better classify the process, the action and the produced information in order to support the internalization of information into knowledge. A category process description type (process family name) identifies different groups of processes. The process family name is used as the main category to characterize and distinguish process instances and types. In order to describe the process more explicitly, other categorization data could be used such as “client’s name”, “process cycle time”, “involved

116

employees”, “roles”, “description”, etc. The used categories should be determined and adapted to each context. In order to allow better information sharing and retrieval, the process should be categorized in the most detailed way possible and supported manually by the actors. The best practice is to characterize the process context of each action and all produced information. To this end, three types of categories can be distinguished:

• Process family name: to describe process types and helps to distinguish the

different processes • Action family name: to describe action types in the process and help to distinguish

the different actions • Fixed Process/information characterization: process annotation by predefined

categories • Free Process/information characterization: process annotation by free text

annotation

A good process and action description helps the user to understand the goal of the process and the action that has to be executed.

PIFA is a help in formalizing complex processes, especially organizational transversal ones. This formalization should, in a second time, be used to optimize the process and knowledge activities related to the formalized context. It captures an executed process’ instances and could therefore especially be used for a dynamic environment analysis where process structure changes. The PIFA figure (Figure 38+39) can be considered as a template to do interviews with the process actors and managers to understand and formalize the process. The idea is to follow-up different process’ executions and formalize them. The goal is to capture and formalize the different flowcharts of the different processes, their actions and their associated produced information in these real executed processes and to understand the relations to their context (infrastructure, tools, behavior, etc) and the executed functionalities. In the following, these three levels of PIFA are illustrated:

The Process / Action level:

o The process level constructs the process model

The Information, context, Return of experience (REX) level: o The information level constructs a knowledge capitalization, sharing and

retrieval model supported by ontologies for an information sharing via IT The Functionality level

o The functionality level guarantees the inclusion of all necessary functionalities and gives a surplus value to facilitate the user acceptance

These three perspectives are explained in the following sections and illustrated by examples.

117

4.3.2 The process and action level The Process level represents the business analysis or business re-engineering nature. The formalization of dependencies between actions of a process results in designing a process flow. It is primordial to analyze the process flow and formalize the possible changes that could occur in a process.

Therefore, an action is analyzed and put in a certain context. Dependencies between actions will be captured and formalized as well as conditions for the process flow for opening and finishing actions (cf. principle of PIFA analysis in sections 4.3.1.1). PIFA could be applied to follow-up different process as shown in figure 40. Based on theses captured processes, a process flow model could be built up as illustrated in the following figure:

Figure 40: Example of a PIFA result

In the figure above, two PIFA analyses have been applied. The two analyses have delivered a process model. Secondly, conditions for the process flow have been captured:

A1 has to be finished before opening A2 The completion of A2 can re-open A1 or open A3 A4 has to be finished before opening A3 The completion of A4 opens A3

PIFA should especially represent the dynamism of process flows. Therefore, it is important to describe the action type to distinguish different process action types in order to identify action type families that help to find easier a process model. When applying PIFA to a dynamic process domain where processes change permanently, it could be difficult to construct a generalized process model. Therefore, an intermediate step is added to analyze the process actions types in order to recognize all involved action types and possible “dynamic” repetitions between these action types in processes. In the following, two different analyses of the PIFA application on dynamic changing processes are illustrated and a process model is established based on the results.

118

Figure 41: Example 1 for a generic process model creation

In figure 41, two possible PIFA results are illustrated. The analyzed process instance on the left starts with a process flow between actions A1 and A2 and the process is then divided in three parallel branches before re-assembling the process flow in action A6. The action type A3 exists in all parallel branches. The second analyzed process instance on the right starts with the same process flow between actions A1 and A2 and has also three branches in parallel, but it is different from the first analyzed process as the same couple of actions, A3 and A4, exist in two different branches. Therefore, a hypothetical generic process model is proposed that anticipates these discussed process flow possibilities in one generic valid process model where action A3 is a multiple action and could be used n times in n different process branches. The action flow A3 to A4 are multiple in this model and can be used n times for n different process branches. This process model could be enlarged or validated by applying PIFA to another process instances.

Figure 42: Example 2 for a generic process model creation

119

In figure 42, two possible PIFA results are illustrated. The analyzed process instance on the left starts with a process flow between actions A1 and A2 and the process is then divided in three parallel branches before re-assembling the process flow in action A6. No action type is used twice in a process branch. The second analyzed process instance on the right starts with a different process flow between actions A2 and A6 and has three branches in parallel that are different from the first analyzed process. A repetitive aspect is that the couple of actions A3 and A4 exist in two different branches. Based on this analysis, a complete anticipated process model cannot be built, as the analyzed processes are completely different. A hypothesis of a dependency between action A3 and A4 is done, but no complete process flow could be established. However, a process model of different action types that are not related is established. This process model is considered as an “ad hoc” process type (cf. 3.5.5), as the process flow is built during the execution. This process model could be enlarged or validated by applying PIFA on another process instances. The process level output is a generalized process model containing actions and dependencies between actions as well as opening and finishing conditions, meaning to establish different rules for the action and its associated process flow. The PIFA-process level covers the described Input and Output parts in the previous chapter in terms of process conditions for opening and finishing actions.

4.3.3 The information level The Information level represents the information nature of a process. Two different natures are distinguished:

The produced information (knowledge about the final product or service) The contextual information (knowledge about the context)

The abstraction of the input and output analysis allows formalizing the produced and used information (the information flow). Based on this analysis, the requirements for better information sharing, meaning to identify which information is easily accessible and how the information sharing can be improved, are formalized. The problem of information access and sharing and their improvement possibilities has to be analyzed. It is important to take into account the actor’s point of view, who might have problems in doing his work, as well as the manager’s point of view. A manager has a more global view and sees the lack of information sharing. The involved actors see which information is missing to do their work. This requirement analysis represents the added value in terms of knowledge management.

The produced information is one of the action’s outputs in forms of documents, presentations, etc. However, information could also be contextual and necessary to describe the process or produced information of an action. The analyzed process is therefore seen as an information object that changes during the process execution. Contextual information annotates the process. The goal of the information level is a formalization and capitalization of used information in form of documents, presentations, etc., to understand

120

where it is produced, where it is stored, and where it is reused in the process.

Therefore, the different produced information has to be merged to the actions where they are used. In a knowledge intensive environment, the role of information is very important for the process. Information could change and become obsolete. In this case, the already executed work is no longer valid as it was based on information that became obsolete, and the process has to be executed again. The dynamism of a process can also be not only the action structure of the action, but also the change of information.

Figure 43: Example of a PIFA result and the dynamisms based on information

In the example above (figure 43), the produced information (illustrated as a document) is reused in actions A2 and A3. If the action has been completed, the workflow will continue and open A2 and A4. Once both actions have been completed, action A3 is executed. In the case that the produced information in action A1 becomes obsolete, the process has to be re-executed. New information will be produced in action A1 and will impact the work in A2 and A3. Therefore, the process flow depends on the maturity of information and information could be obsolete in a changing environment. For a process model, not only are the dependencies between actions important to analyze, but also the impacts of information and changes in information according the process flow. As explained, the merging of produced information with actions improves the reuse within a process direction. But it is also envisaged to improve an information reuse between processes. Therefore, the process and the produced information within a process must have enough contextual information. (cf. 3.2.4.2). The goal is to capture all necessary contextual information to better annotate the information, not only for an immediate reuse within the process, but also for a later reuse in other processes. It is primordial to annotate the process with enough contextual information in order to introduce efficient information retrieval and information internalization into knowledge. In section 3.3.1.2, it was explained that ontologies could help in the domain of KM to capture and manage contextual information. Contextual Information used to classify the process has to be formalized and structured. This allows standardizing the annotations and defining an information context for all involved actors in different processes, but in the same process domain context. Based on the fact that the processes could be categorized by a finite word-list, the context of a process could possibly be described in a standardized way. Therefore, an ontology for each of the involved actors and processes could be established to capture the different categories and their values. In a second step, the different “ontologies” are overlapped to determine a common vocabulary (shared ontology) that will be understandable to each employee within the different domains, and that will be used for a

121

common annotation of the processes. Furthermore, the specialized vocabulary of each domain is maintained to annotate the experiment more precisely for each of them. This principle is illustrated in the following figure: the combination of these ontologies to a unique ontology containing the “shared” vocabulary and the domain-specific parts.

Figure 44: Example for an ontology: hierarchy between concepts

In figure 44, the possible combination of different ontologies into one unique ontology is illustrated. In this example, all ontologies (A, B, C, D) have one key concept in common. Related through this key concept, the different ontologies exist therefore also in a specific domain vocabulary, as showed in the figure as parts A+D, B and C. This concept could be applied to ontologies discovered through a PIFA analysis. The reuse and combination of existing ontologies could especially help to reuse them for structured and semi-automated annotation of the process information (cf. section 3.3.1). The knowledge capitalization activities are done by humans, but semi-automated approaches could support the manual annotation and save time for humans by annotating or proposing annotations for a capitalization. Employees give contextual information to the produced information during an action execution in the form of annotations. This annotation belongs to the constructed ontology and could choose a defined category with predefined values. The employee should therefore choose a value within this category. The defined category of the used ontology could already exist in a different domain that is related to the analyzed domain by PIFA. Therefore, it could be interesting to reuse the different information relations of different ontologies to annotate and complete the contextual information. This principle is explained in the following figure:

122

Figure 45: Example for a combination of ontologies

By using contextual information of the category “concept3”, the relations between concept3, concept4 and concept5 could be reused. For the construction of an ontology, it is important to analyze whether a part of this ontology does not already exist. First approaches are already done as PIFA captures which tools are consulted to retrieve information and which information is used for the functionality level. A deeper analysis should confirm that the ontology could (partially) be reused. The information level output is an optimized process model merging information to the right actions. The information flow within a process is formalized separately as it allows identification of which information is produced and where and which part is reused. Additionally, an ontology is established allowing the annotation of the process with symbols of concepts belonging to an ontology. The PIFA-information level covers the Input and Output parts described in the previous chapter in terms of information needed and produced within an action. Additionally, it represents the context and the return of experience parts as the ontology can be built and additional process information flows could be introduced by responding to an information flow backwards through the process as well as between processes.

4.3.4 The functionality level The Functionality level of the analysis helps to identify the functionalities of an action

within a process (considered as daily work activities within processes). It is especially important to understand the current problems of these activities in order to improve them. These optimization possibilities represent the surplus value for the user and guarantee that the new captured and analyzed methodology improves current work conditions.

These functionalities describe which input information is used and how it is transformed into new information based on information and business rules as well as which products or services are produced. Functionalities executed by humans allow for great liberty as everyone can determine the order and the specific way in which they are executed. Functionalities supported and executed by IT are more restrictive and fixed. The way things are done is therefore always the same and must respond and cover all humans’ “different” ways of executing functionalities.

A process execution always has human interactions. Every employee has his or her habits and resists changes (cf. section 3.3.2.1). Satisfying and improving current functionalities of process action will guarantee user acceptance and, secondly, provide the deployment of the defined process as well as introducing knowledge management functionalities in daily work

123

and promoting a knowledge sharing culture in the enterprise. Therefore the employee’s behavior and functionality has to be analyzed to guarantee an immediate surplus value to the employee.

It is therefore important to capture the explicit functions—the functions well known by the actors—as well as the implicit functions by observing the actors during their activities. This should complete the functionality (requirement) analysis as actors are not always able to formalize their requirements. Therefore, an observation of their daily work activities based on PIFA is important.

In the following list, an example of functionalities (requirements) captured during a PIFA analysis is illustrated. These functionalities could belong to one or more actions in a process:

Functionalities Improvement: Validate the information (A1, A3) Validate and notify actors Store a document in a tool (A1) Store and notify actors, give a synthesis Assign a person to a action (A1, A3) Check Resource planning, anticipate

work Set information to a tool (A4) Meta-Crawler-Information for centralization Calculate statistic results of given numbers, etc. Integrate calculation

functions

Figure 46: Example for a functionality requirement list

The functionality level output is an optimized process model merging functionalities to each action. These functionalities could be improved and give a surplus value to the actor. This helps to minimize the resistance of the users to accept a new tool on the one hand, and on the other hand it also reduces the resistance against knowledge capitalization. This PIFA-functionality level covers the described functionality part in the previous chapter. It analyzes which functionalities are executed, based on which business rules and with which information.

4.3.5 The application of PIFA PIFA should be applied in the objective to improve the current situation and the treatment of knowledge intensive business processes. Therefore, it is important first of all to understand the employees’ and management needs for a context to which PIFA is applied. The three described levels cannot be applied separately as they are related to each other. The application of PIFA should concern three different phases in order to replace the existing methodology with a new one: The Analyze phase of PIFA consists in doing interviews and observing current work methods by using the PIFA template. Current behavior and infrastructure as well as relations between actors are analyzed for each process instance PIFA is applied to.

124

The Formalize phase of PIFA consists in formalizing and abstracting the current work practices in order to build a knowledge-process model that is valid for a large number of analyzed processes. The Improve phase of PIFA consists in improving the constructed knowledge-process model. This phase is based on the analyzed results concerning the three levels (improved process flow, improved information flow, improved functionalities related to the treatment of information of the process).

Figure 47: Application scheme of PIFA

A three-step model seems appropriate to be applied. The relation between the explained PIFA template, levels and the three-phase model to apply PIFA is presented in the figure below (figure 47). The “Analyze” phase consists of doing interviews with the management and the process actors. The “Formalize” phase consists of analyzing the interview results and characterizing the three different levels of PIFA: the process, the information and the functionality level. The “Improve” phase improves the formalized and analyzed model and applies it to the existing model in order to improve the current situation.

Figure 48: Application of PIFA

125

4.4 The application field and gain of PIFA

4.4.1 Identification of different knowledge flow types by PIFA The separation of information and process has the advantages of, on one hand, formalizing the process and giving a basic process structure. On the other hand it allows analyzing the information flow independent from the process to understand where the produced information is consumed. It is important to mention that capturing the needed information allows, first of all, an understanding of where the produced knowledge is needed and consumed to increase directly the productivity during a process. Additionally, it also allows formalizing the desired knowledge flow, which indirectly enhances the productivity by optimizing the competence of a person or by improving the process execution and/or results. This desired information could be a feedback from a similar process or activity about previous work or about similar processes to see if the process produced positive results and also to avoid making the same errors again. This information is a flow backwards or cross-over through processes. The identified knowledge flow types are illustrated in the following figure:

Figure 49: Information flow in business processes

1) The combination of process flow and information flow (dependencies) Merging of produced information into the right action:

The information also represents conditions to (re)execute a action The information is associated with the right time, place and person where

it is consumed 2) Anticipation by separate information from process Independent information flow from the process to anticipate actions coming due:

Information used for project and resource planning 3) Feedback about work Information flow backwards through the process:

Information about intermediate or final results of a process to improve the competence.

126

4) Information-Aggregation This information will be used by the employees as well as by the management:

Aggregating information to do process reporting, etc.

5) Reutilization Information flow cross-over through processes consisting in reutilization of documents and data produced. The reutilization of the intellectual property improves the quality of the processes as errors hopefully will not be repeated, or similar results will be reused to improve the future results of the current process:

Reuse information flow by an efficient information retrieval These information flow types could be abstracted through the application of PIFA. Other types could also exist for different domains. The already discovered information flows should be supported to increase the knowledge management activities and satisfy the knowledge needs of employees for needed and desired knowledge.

4.4.2 Using PIFA: Identifying the process dynamism based on information changes The PIFA approach analysis could be considered as a gap analysis as it discovers

information flow improvement, functionality improvements and process flow improvement possibilities and its dysfunctions.

In a knowledge-intensive environment the execution and re-execution of a action depends on the information and how it changes. Therefore, PIFA helps first of all to formalize and understand this knowledge flow and its related process in order to improve it during the second time. In particular, this method shows the places where the information flow should be supported and improved. The objective of PIFA is therefore not only to model and understand the context, but also to identify possibilities for knowledge improvement.

Additionally, the interpretation of PIFA results helps to understand the dynamism of processes by comparing the analyzed process instances (cf. 4.3.2). All information consumed within a process could potentially be reused in different processes. The analysis also allows identifying the competence of a person who could do an action and formalizing the organizations of the transversal processes and its involved teams. In the following list, the advantages of PIFA are summarized:

• Process modeling (cf. section 4.3.2) • Process contextual information identification (cf. section 4.3.3) • Identification of produced information (cf. section 4.3.3) • Merging of information to actions (cf. section 4.333) • Identification of functionalities and their relations to information (cf. section 4.3.4)

Furthermore, the following aspects are discovered by PIFA:

127

• Gap analysis: improvement possibilities of the process, information, and functionality o Process flow improvement o Information capitalization (missing information) o Functionality improvement

During interviews, problems are also explained as they are recognized by the employees. Therefore the questions “How?” and “Why?” are also important (cf. section 3.2.1.3)).

• People’s competence and process organization clarification Due to the formalization and tracking of actors involved in a process, an organization

chart of employees and their competencies could be built.

The PIFA approach shows the places where the information flow should be supported and improved. The objective of PIFA is not only to model and understand the context, but also to identify knowledge improvement possibilities. In this work, some approaches were previously discussed, such as the H-method (cf. section 3.6.2) or the KDML (cf. section 3.7.3), to relate knowledge to business processes. However, neither method takes into account the cross-over knowledge flow between processes or a backwards knowledge flow within a process. Therefore, the PIFA approach was constructed in order to especially support the different types of knowledge flows related to the domain of process management as identified (cf. section 4.4.1).

Furthermore, the discussed analysis methods are limited by the uni-directional process flow and represent only the process model. PIFA is additionally concentrated on the context to which it was applied, and it analyzes the IT infrastructures used for a process execution. Furthermore, change management approaches influenced the design of PIFA. Therefore, the PIFA approach and its results are primarily a user-driven approach to optimize the current situation and implement Knowledge Management activities. The application field of PIFA is discussed in the following section.

4.4.3 Application field of PIFA PIFA can be applied to all types of processes, especially dynamic knowledge intensive ones, as it formalizes the work and the associated information flow of a process. We previously explained the principle of constructing a generic model for anticipated process flows and semi-anticipated process flows (ad hoc) (cf. section 4.3.2), but in fact, PIFA could be applied to all discussed business process types (cf. section 3.5.5).

On administrative processes it can formalize simple bureaucratic processes (simple action and information links)

On ad hoc processes it can observe different process instances and can therefore

formalize the different exceptions or unique situations On collaborative processes it can detect the large number of participants involved

and clarify the transversal relation between involved organizations On production processes it can also formalize the complexity and heterogeneity

of the environment concerning different used IT tools, the variety of people and organizations involved, and the nature of the actions (different action types)

128

Additionally, PIFA could be applied especially on knowledge intensive business processes as it captures the discussed knowledge objects types (cf. section 3.2.4.3):

Final objects: it detects the final knowledge object product produced and its place of storage as well as its recipients.

Intermediate objects: it also formalizes the intermediate objects produced and re-

used within a process to construct the final object. Artifacts: it also takes into account this type of knowledge as it combines the

knowledge flow with the daily work activities (functions). Furthermore, the PIFA approach also analyzes the contextual information that is very important for each of these three types to guarantee an internalization to rebuild the initial knowledge (cf. section 3.2.4.2).

A shared ontology is constructed to describe the context of the three different knowledge types for a business process type.

This ontology has been generated and discovered through the application of PIFA. Applying PIFA is considered to be done on different instances of the same process type. This allows for different process schemes of the same process type and will allow comparing and merging the different schemes to complete and capture all main work and information flows to generate one process model. Therefore, PIFA could support the conception of a tool combining a KMS and a WMS.

4.4.4 Performance measurement of Knowledge Management activities One of the difficulties previously mentioned in this work is the ability to measure the return of knowledge management activities. The capitalized information through the process execution should be reused for different processes in order to improve the quality of a product and in order to avoid making the same errors again. But it is difficult to measure the quality improvement based on knowledge management activities. As explained in section 3.2.1, knowledge is not material, and quantity measurement approaches cannot be applied. [Studer, 2003] formalizes the following approaches for an information I and the obtained knowledge from this information K(I):

i) I 1+ I2 = 2I ii) K1 = K(I1)

iii) K2(I1+I2) ≠ K(I1)+K(I2)

Figure 50: Information measurement formula

Two pieces of information are two different elementary information (i). Knowledge K1 is the knowledge internalized from the information I1. However, this is not a linear function and

129

therefore the knowledge K2 internalized from these two different pieces of information (I1+I2) will depend on the existing knowledge built from information I1 and therefore, the redundancy and complementary of the information. The growth of information volume is linear, while that of knowledge is a function which depends on the quantity of new information and existing knowledge as illustrated below according to [Studer, 2003]:

K' = K + f(K,K(I)), but f(K,K(I)) unknown and not describable

Figure 51: Knowledge measurement formula

The industrial goal of management activities for the experiment process is, as explained, achieving a higher quality and avoiding errors. These goals could be transformed into the objective of reducing the number of lots used for an experiment as well as improving the yield of a produced lot. These factors are not only related to knowledge management activities, and the influence of knowledge management activities on these aspects cannot be isolated. An improvement of the yield or a reducing of the number of used lots could also be related to other factors and projects. However, knowledge cannot be measured directly. Therefore, two different approaches can be taken to measure approximately the performance of a Knowledge Management System (KMS):

The identification of suitable indicators to measure the improvement of process treatment related to the process flow, the process information and the functionalities.

The performance analysis of the knowledge retrieval interfaces in relation to the

initial need.

4.4.4.1 Suitable Performance Indicators for process treatment It is difficult to identify suitable performance measurement indicators as they are domain specific and depend on the domain and especially on the identified problems to improve. Therefore, first of all, a description of the characteristics of “suitable” performance measurement indicators is given: “Key Performance Indicators are quantifiable measurements, agreed to beforehand, that reflect the critical success factors of an organization. They will differ depending on the organization. A business may have as one of its Key Performance Indicators the percentage of its income that comes from return customers. The goals for a particular Key Performance Indicator may change as the organizations goals change, or as it get closer to achieving a goal” [Reh, 2006].

130

Even if the indicators depend on the industry and applied domain, in the following, some indicators are given that seems to be “adequate Best Practices” to measure the performance of a new methodology for knowledge intensive business processes:

Number of actors (the number of employees following the new process compared to the number of employees resisting against the new methodology)

Time for a process execution (the time needed for a process execution and statistical

values as best/worst value, average 25%, 50% and 75%-quantile24 time)

Time for an action execution (time to complete the associated functionalities and time needed for an information retrieval compared to previous time)

Number of positive changes compared to related problems (based on requirement

analysis): less problem occurrences, less discussions, less administrative work, etc.

Number of related problems due to the change: new problems related to the new work methodology, number of problems, number of actors concerned, etc.

The list above gives a first impression of factors that are always related to knowledge intensive business processes. As explained, performance indicators should be quantitative and measurable. The adaptation of the listed indicators depends therefore on the domain. However, the measurement of knowledge reuse is interesting in the context of knowledge intensive business processes. An approach of measurement is given in the following section. 4.4.4.2 Performance Measurement and analyzes of knowledge retrieval

interfaces For more than 30 years, the performance of an Information Retrieval system has often been measured by two factors: recall and precision (as explained below) [Salton, 1992]. These parameters can help to evaluate the success and efficiency of a system. The Recall (R), which is the proportion of relevant found information compared to the amount of relevant information R(I)—more exact needs of information I and a demand q—would be given for a user. The value of the Recall is therefore between 0 and 1. It is not easy to calculate this factor, as for a given search question all information must be classified by a user as relevant or not relevant to be able to calculate the recall factor. The Recall is then calculated by

Figure 52: Recall formula

24 X% quantile: Quantiles are essentially points taken at regular vertical intervals from the cumulative distribution function of a random variable. Dividing ordered data into q essentially equal-sized data subsets is the motivation for q-quantiles; the quantiles are the data values marking the boundaries between consecutive subsets.; i.e., an ordered value chain (2,2,2,3,4,5), the value 2 represents the 50% quantile as 2,2,2 represents 50% of the value chain.

131

The Precision (P) is defined as the number of relevant found information compared to all retrieved information from a search. The value of the Precision is therefore between 0 and 1 and calculated by

Figure 53: Precision formula

The relation of these two performance measurement factors is illustrated in the following figure:

Figure 54: Number of relevant and found documents

The factors are complementary and cannot be optimized easily at the same time. The goal is to approach a value of 1, meaning retrieving all pertinent documents that are relevant. It is necessary to take into account both of these two factors because the recall as a unique factor does not take into account the non-relevant number of documents and could easily be maximized by retrieving all the documents of the base. In that case, the value of the precision would be very low. Also, the unique use of the factor “precision” does not measure the performance as the precision could be maximized by distributing only few documents, but in this case the recall factor would be very low. It is therefore important to optimize both factors at the same time. Furthermore, the performance of such a system cannot be analyzed only by these factors. As explained in section 3.3.1.1, is also important to support the verbalization of a search question. Therefore, PIFA has already helped to identify the most pertinent and relevant search categories and allow the user to better express his or her search results. By using search categories that represent a certain context and that are understandable for the user, the precision and recall factors can be increased. However, the use of search interfaces must be supervised and adapted to the changing context and user needs.

132

4.5 Using PIFA to construct an IT tool Section 3.3.3 already explained that it is difficult to deploy a new work methodology

containing KM aspects without an IT support. KM and IT are related and the result of the PIFA approach could especially be used to construct an IT tool. Therefore, a proceeding is proposed to build IT tools that integrate PIFA [BUSCH, 2005a].

4.5.1 Application of PIFA for the IT domain Indeed, the computerization of a business process as a workflow tool would have a

positive benefit and give personal improvement to the employees. Also, this system should be built in a way to capitalize all necessary information needed for a knowledge reuse in a structured way. This would make it possible to carry out synergies by introducing a knowledge capitalization in business process management and initiate a knowledge sharing within, between and backwards through processes. This approach is based on the discussed approach of implementing Knowledge Management activities (cf. section 4.2) and the PIFA approach (cf. section 4.3).

1. Definition of objectives of KM activities and determination of attended

synergies and improvements (KM project initiation): The objectives definition should be the result of the needs formalization, and deliver a first impression of where and why changes are necessary. This step should take into account the manager’s and the potential user’s points of view.

2. The analysis of actual working methods and user needs for better information

sharing (Application of PIFA – Apply, Formalize, Improve (cf. section 4.6)): The analysis of working methods should result in the identification of where a new method for knowledge sharing has to be implemented.

3. Proposition of a tool intended to facilitate and support the daily work business

processes and integrate a KMS (Based on PIFA results): This phase should deliver a tool that combines the business process management aspects (workflow) and the knowledge management aspects. The workflow tool enriched by KM functionalities (advanced search functionalities, notification of users, diffusion of information to a predefined group of users, access and more qualitative searches by meta-data categories, etc.) could be possible. The difficulty is in transforming the different PIFA results of the observed processes into one generic process model.

4. Deployment of this system and change Management; contribute to the re-use

of existing information during the use of the tool: Even if PIFA delivered a good understanding of the context of a knowledge intensive process and helped to construct a tool, it is not guaranteed that the tool will be accepted by the user. Natural resistance (due to habits, age, etc.) exists (cf. 3.3.2): The initial goal or analyzed objectives by PIFA could change regarding new IT functionalities that provoke a user behavior that is neither analyzed nor anticipated. Opportunity-based occasions could tempt the organization to change the initial goal and analyzed model by PIFA. Therefore, it is important to re-do the PIFA analysis in order to analyze the deviation of the proposed PIFA working method and the real working method changed by the introduction of an IT tool.

133

This methodology should be used to design and implement a new IT tool. Furthermore, the existing infrastructure should be analyzed and the new tool should be integrated into the current infrastructure as explained in the following section.

4.5.2 IT infrastructure analyzed by PIFA During the PIFA analysis, the existing infrastructure (“where” the information is coming from) is also very important. In particular, a distinction between persons and IT-tools is made. Furthermore, one of the production process characteristics is the use of heterogeneous IT-tools (cf. section 3.5.5). This fact is also traced by the PIFA application as the PIFA approach analyzes the source and the transfer methods of information (cf. section 4.3.3 and 4.3.4). This principle is illustrated in the following figure:

Figure 55: Example for a PIFA result: current infrastructure related to processes and information flows

However, PIFA does not analyze the technical aspects of the IT infrastructure, but the functional aspects perceived by the IT users as PIFA is only applied during interviews and observation and not on technical infrastructures. In the figure above, an example of a PIFA analysis is shown and the related IT tools and used ontologies already used for this process execution are illustrated. Each of these tools already has its specific structure (data structure and domain ontologies), as a tool is often designed to respond to a specific need and a specific context or application type. As explained in section 3.5.5, especially for production processes many heterogeneous tools are used. The constructed ontology based on the analysis has relations to the existing ontologies in the IT-tool as shown in the figure above (cf. the principle of ontologies in section 3.3.1). The new IT-Tool should support the daily work activities in order to guarantee the deployment of the supported KM work methodology. The integration of the existing ontologies is also valid for the integration into the current IT infrastructure. Therefore, the theoretically built ontology could practically become a meta-crawler25 by combining the

25 A meta crawler is the component of a search engine that gathers listings by automatically „crawling“ the meta-data (annotations). Crawlers are also called spiders or robots.

134

information stored in different tools in order to create a centralized, exhaustive view of involved process information. The discussed methodology to design an IT-tool and analyze the existing infrastructure should deliver a functional and scenario characteristics. In the context of knowledge intensive business processes, the characteristics of an IT tool are similar and an abstracted view is explained in the following sections.

4.5.3 Functional and scenario analysis results for an IT tool The functional and scenario analysis should discover the IT functionalities needed to

support the experiment process SWR and the explained solution principle. It is therefore primarily important to support the “classic” workflow functionalities, discussed in section 3.6.3, and the discussed “rendez-vous” functionality of merging information to the right action in the process flow direction. Additionally, the unstructured information flow (retrieval, pull information functionalities) is also supported.

The following 11 scenarios could be abstracted from a PIFA analysis and be proposed for an IT tool:

Searching for contextual process information

Searching for documents related to processes by contextual process information

Reading documents related to processes

Storing documents related to the process

Storing information to the MES system

Consulting aggregated information about different processes

Manual process annotation

Semi-automated process annotation based on the manual annotation and existing information in the MES

Searching for employees’ competencies

Searching for dependencies in experiments

Acting on a process (Classical workflow functions):

o Searching for current open actions related to a role and the user it is assigned to

o Consult, execute and complete actions

o Store documents during action execution

o Manipulate information during a action

135

Figure 56: Scenarios of PIFA context of knowledge intensive processes

To support the described information sharing and workflow management scenario, seven main entities of the system and nine related key functionalities, presented in the following section, were analyzed in a functional analysis.

4.5.3.1 Functional and relation analysis A functional analysis could also be established from the PIFA analysis approach, especially based on the functionality level. The objective is to clarify the needs for potential functions of a system supporting the knowledge intensive business processes and the sharing of knowledge produced during their execution. The first part of the analysis is to determine the environment (actors and interfaces of a potential system). The second part determines the desired functions of the system. The functions link the different identified actors, processes and information through the interfaces provided throughout the system. The system should help the experiment processes, actors and their managers to improve the processes’ management and their related information in order to improve the knowledge sharing and reutilization. The interfaces of the system should support the work to handle the experiment. Therefore, the environment should handle the processes, their actions, their defined roles, their actors and their produced information. A PIFA approach used to construct an IT tool should especially detect and support the following functions in the context of knowledge intensive business processes:

Process: This entity represents all executed processes Information: This entity represents all information produced during the execution of a

process

136

Actions: This entity represents all actions concerning the executed processes. Role: This entity represents all roles. A role is the owner of a action. An actor related

to a role can execute actions related to this role. Workflow actors: This entity represents all actors involved actively in the processes. Other actors: This entity represents all actors involved passively in the processes.

4.5.3.1.1 Definition of the functions and relations The functions are represented in the following figure and described below:

Figure 57: Functionality schema26

Function F1: Processes related to actions: A process is a structured order of actions.

The system should help to link actions to processes and allow management of a process execution. Therefore, the systems should be able to relate different actions for processes and handle the dependencies of actions in order to build up a process structure—a predefined order of action execution. The objective is to structure a process by a action order. A visualization of this structure, as well as a visualization of the action state, should explain the process to the actor and give a process follow-up. Additionally, an overview about current processes and current open actions is possible by linking actions to processes.

Function F2: Actions related to roles: All actions defined in a process should be

assigned to a role. Only this role can execute and change the state of the action. Responsibilities of actions are well defined by this relation and should aid in not forgetting a action in a process and to clearly identify the role assigned to a action. The system should therefore be able to associate a role to a action in order to ensure that a action can only be executed by a defined role.

26 In the context of experiment processes at STM, the actors DYE, R&D, area or production could be directly involved in the processes (process actors) or only have an interest of following-up the experiment processes (other actors).

137

Function F3: Roles related to workflow actors: By assigning a role to an actor, a person or group of persons is designated to be in charge of executing a action related to a role, which is related to an actor. Actions are therefore associated with actors. An actor should find all the actions he or she has to work on, identify actions coming due and delegate actions to his colleagues. The system should be able to manage the associated users as actors to a role.

Function F4: Information related to actions: The system should help to relate

information to actions. All information existing in the system for the current or already executed processes should be related to the action where they are needed. Secondly, information produced and the contextual information during the action execution should be capitalized on the action interface as well as structured and stored within the system.

Function F5: Information related to processes: As information is related to actions

and actions are related to processes, information is also related to processes. The goal is to give an overview about the produced information within a process.

Function F6: Information related to workflow actors: As information is related to

actions, actions are related to roles, and roles are related to workflow actors, information is also related to workflow actors. The goal is to give them the necessary information for the action as well as to capitalize the produced information on a action.

Function F7: Workflow actors related to processes: As actors (R&D, DYE, Area or

clean-room) are related to roles, which are related to actions, which are related to processes, workflow actors are also related to processes. The goal is that workflow actors always have a synthesis about the current processes (follow-up) and also access to the information produced in the processes they are involved in. Additionally, notifications are useful to inform actors of new information.

Function F8: Other actors to processes: All actors working in the context of

experiment processes, but not involved in a process, should also have access to the system. Especially for the management, the follow-up aspects and statistical functionalities are important.

Furthermore, to realize these functionalities, technical functionalities must be provided by the system as identified and explained in the following:

Process visualization as a process comprehension guideline: As the users have difficulties to position their work in a changing environment.

Process visualization as an execution guideline, but flexibility in the process execution: As help for the users to recommend a process execution in the changing environment.

Action form structure:

As the information must be displayed to an actor of an action and the needed information is different in each action.

138

Process modeling: fast model changes to adapt to changing requirements:

As the unpredictable changes of action type must be handled.

Process follow-up and project management synthesis of current processes (process as information object view): As help for the users to follow-up the different state of process executions they are involved in.

Knowledge retrieval interfaces to search information of processes according multiple

points of view: As help for the users to retrieve and compare information from previous and current processes to avoid making the same errors again or redoing the same work.

4.6 PIFA abstraction and application framework In the previous sections, the PIFA approach was explained and its application was illustrated by different figures. Furthermore, the application field and especially the application in the objective to build a new methodology supported by an IT tool was discussed, integrating a Knowledge Management System (KMS) and a workflow management system (WMS). In this section, an abstraction of these discussed facts and goals is given and the global characteristics of PIFA are summarized. Therefore, an explication of entities related to PIFA and its framework seems to be particularly necessary:

4.6.1 Entities The explication and illustration of PIFA in section 4.3 and the application of PIFA to build an IT-tool in section 4.5 already discussed different characteristics and entities that are related to the context of knowledge intensive business processes. In this section, these entities are classified according their use. The PIFA approach concerns three levels as explained in section 4.3.1. The process level:

Process model Process instances Actions Role Human

The information level:

Content information (documents, presentations, drafts, notes, etc. final or intermediate knowledge objects)

Contextual information (process domain ontology, process description) The functionality level:

Functionalities related to the treatment of the process and information

139

In section 3.5.3, it was mentioned that the full automation of processes and information treatment failed in the past and therefore new research projects are more concentrated on the Human-Machine-Interfaces. According to the important aspects of a balance between humans, technology and organization in a specific context for successful Knowledge Management activity (cf. section 3.3), the application and results of PIFA are also related to a context: The context and environment: IT infrastructure, the organization’s culture, methods, behavior Even if the three PIFA levels already include the context’s aspects, it has to be clarified that the PIFA results are domain specific and could not be applied and easily transferred to other domains.

4.6.2 Framework Different aspects of Knowledge Management and Business Process Management were discussed in the Literature acquisition chapter (chapter 3). Furthermore, the application field section (cf. section 4.4) already explained how PIFA could be applied to different business process types. In this section, a summary of the different framework layers and characteristics is given and positioned to the application in this work. Therefore, a distinction between the context, the knowledge management, the change management and the business process management layers of the framework is important, as explained in the following. The Context layer:

Organization (cf. section 2.2.1): o Concurrent engineering o Sequential engineering

Organizational interaction (cf. section 2.2.2): o Within the same department, within the same process o Within different departments, within the same process o Within different departments, between different processes (organizational

barriers)

Communication environment (cf. section 3.3.3.1) o Same place, same time o Different place, same time o Same place, different time o Different place, different time

Business Value (cf. section 3.5.5): o High o Low

140

The Knowledge Management layer: The knowledge nature (cf. section 3.2.2.1):

o Implicit o Explicit o Embodied or tacit

The knowledge application (cf. section 3.2.2.2):

o Needed o Desired

The knowledge source type (cf. section 3.2.2.3):

o Individual o Collective

The knowledge type (cf. section 3.2.3):

o Chaos o Complex o Knowable o Known

The Change Management layer:

The change nature (cf. section 3.3.2): o Prescribed o Constructured o Crisis o Adapted

The Business Process Management layer:

The process types (cf. section 3.7.5): o Administrative o Ad hoc o Collaborative o Production

The process nature (cf. section 3.5.5):

o Repetitive o Repetitive with dynamic changes o Unique

The action complexity (cf. section 3.5.5):

o High o Low

The action structure (cf. section 3.5.5):

o High o Low

141

The PIFA approach to analyzing knowledge intensive business processes was developed in the context of experiment management at STMicroelectronics. Even if PIFA should be applicable to the whole framework, the industrial goal of this work in particular (“not to intensify the collaborative work, but to increase the knowledge exchange over organizational barriers in an asynchronous, delocalized environment” (cf. section 3.3.3.1)) restricts the framework. Due to the industrial goal and the context of experiment management (cf. chapter II), the application of PIFA is especially valid for the following highlighted characteristics in the following figure:

Figure 58: The PIFA application field framework

This successful application of PIFA to the context of the experiment processes (cf. chapter V) could be considered a validation of PIFA for the highlighted framework. Other framework contexts must still be investigated in order to validate and improve PIFA (cf. section 4.3). To sum up, the application of knowledge management to business process management should especially concentrate on the desired knowledge sharing between processes with a high business value in order to transform individual knowledge into collective knowledge. Surplus value of introducing knowledge management is especially given for complex production processes with a high characteristic of collaboration having a high task complexity. This is especially important in a concurrent engineering environment where processes are launched in parallel. The knowledge could be more easily capitalized by supporting the needed knowledge exchange within processes. In order to facilitate the comprehension of defined knowledge management activities in business processes, the process should be standardized. This is only possible for “known” process and knowledge processes that are repeatable. The critical factor is the potential “user” of the new methodology. Therefore, the change is adapted and conducted by this user. An organization’s management, however, could also prescribe a new work methodology. In the framework described here, PIFA helps develop a new work methodology in order to integrate knowledge management in business process management.

142

4.7 Conclusion PIFA captures and formalizes the flowchart of the different actions and the associated produced information in a real executed process. It is an aid in formalizing complex processes, especially organizational transversal ones. The idea is to follow-up different processes’ executions to formalize them as well as to formalize more precisely the different actions of one actor in order to establish dependencies. This method is only an aid and does not guarantee that all related functions are discovered through the analysis, as exceptions could appear and some functions remain implicit, as they are also considered as implicit by the interviewer. The goal is to generate a process model of work and information flows and the associated required functionalities. Often Processes are modeled in a fixed way and do not represent the real process, or exceptions cannot be handled by the defined process. Therefore, the abstracted process model does not represent the work of actors, nor in the real world, neither in an abstracted view. The application of PIFA is completely adaptable as it is an interview approach that could be used to observe and understand one specific process instance. It could especially be used for a dynamic environment where processes change by observing different executed processes of the same process type. Therefore, the formalized process will be different as it analyzes and follows concrete processes by combining different activities with the different work and information flows.

The results of PIFA show and help to understand the importance of introducing knowledge management in daily activities instead of introducing KM activities as a stand-alone discipline. Therefore, the hypothesis that knowledge management activities have to be integrated into daily work activities could be considered as a proof by the conception and application of PIFA. In the context of a large number of projects, organizational project barriers prevent delocalized, asynchronous knowledge sharing by direct contact. Therefore, it is important to focus on improving and reducing the organizational barriers, often supported by information technology. The analysis results give an overview of which knowledge is produced and used for the process and which knowledge could be of interest and used for similar processes.

The PIFA-method should give a sufficient model of the domain to analyze the daily work activities, as well as their related knowledge activities. As the generated model is always based on a limited number of executions, it can never cover all the needs. It is therefore important to keep in mind that implicit knowledge sharing between users always exists and these activities are difficult to understand and to formalize.

143

5 INDUSTRIAL SOLUTION: EMA – an IT tool for managing the knowledge intensive experiment processes

This chapter illustrates the practical application of PIFA and gives an overview about the industrial realized solution (EMA) based on the PIFA results. EMA is a tool that supports the developed methodology of capitalizing knowledge during daily work activities at STM.

5.1 Introduction The PIFA method (described in chapter 4) was applied on the context of experiment processes at STMircoelectronics. The objective was to understand the knowledge flow related to the experiment processes. This analysis allowed the conception of an IT tool (EMA) supporting the management of the described knowledge intensive experiment processes (cf. chapter 2.3). In this chapter, the application of PIFA on the context of experiment processes is illustrated and described and its results are discussed and evaluated. Based on these analyses, a generic process model is constructed and the needed knowledge flow and functionalities are discussed. Furthermore, the knowledge capitalization of experiments and their context allows initiating a re-use of this information as desired knowledge. These results helped to complete the technical conception of EMA. The tool was deployed and the change management aspects as well as the return of experience are also discussed. 5.2 PIFA application on experiment processes at STM In order to construct a sophisticated generic process model, different PIFA applications were completed. The transversal experiment process SWR involves 20 different organizational departments and 300 employees. Therefore, for 8 main departments, an interlocutor (key user) was defined to apply the PIFA approach during interviews, validate the results and generate a global point of view about the experiment processes and the supporting IT tool. It was also important to conduct different meetings and interviews with the management to validate the results and guarantee the management support for the tool. To this end, 3 SWR processes were followed and analyzed by PIFA and their results discussed with the involved actors and managers. The following example is presented to illustrate the application of PIFA. The following PIFA-template was applied on the action “Experiment Instruction Preparation” in the SWR process:

144

Figure 59: Example for a PIFA application: Experiment instruction preparation

For an action of an employee, the information according to the PIFA approach (cf. section 4.3.1) and template (cf. section 4.3.1.1) is fulfilled during an interview and observation as illustrated above. This principle was applied to the context of experiment processes at STM. In the following, the different results of the 3 followed and analyzed SWR processes are presented and discussed. In all analyzed processes, the action types are the same, but the number of actions and the process flow changes. In general, 6 different action types were identified as in the following table:

A1 : Experiment Definition A2 : Lot attribution for the experiment A3 : Experiment instruction preparation for an operation A4 : Experiment instruction preparation validation at an operation A5 : Experiment Lot Treatment for a prepared instruction A6 : Experiment analysis

Figure 60: Identified action types of the SWR process

These action types were identified during the observation and follow-up of 3 SWRs through the PIFA approach.

145

5.2.1 Examples for three PIFA results for the experiment process analysis 5.2.1.1 Process Level The first analyzed SWR process starts with the “experiment definition” (A1), followed by the “Lot attribution” (A2). The defined experiment impacts three different operations (cf. chapter 2). Therefore in the model below, one process branch concerns one operation. The first branch starts with an “Experiment instruction preparation” (A3), followed by an “Experiment instruction preparation validation” (A4). Once the experiment for an operation is prepared, it will be executed at the arrival of the attributed lot at the concerned operation: “Experiment Lot Treatment” (A5). The two other branches are identical to the first branch, but concern operations different from the first one. The three parallel described branches will end in the final action “Experiment analysis” (A6). In this example, a problem occurred during the experiment analysis (A6) and the process was re-executed from the “lot attribution” (A2).

Figure 61: Example 1 of an analyzed SWR

The second analyzed SWR process also starts with the “experiment definition” (A1), followed by the “Lot attribution” (A2). The defined experiment impacts two different operations. The first branch starts with an “Experiment instruction preparation” (A3) followed by the experiment execution at the arrival of the attributed lot at the concerned operation “Experiment Lot Treatment” (A5). The second branch starts with an “Experiment instruction preparation” (A3) followed by an “Experiment instruction preparation validation” (A4). The experiment will be executed at the arrival of the attributed lot at the concerned operation “Experiment Lot Treatment”. (A5). The two parallel described branches will also end in the final action “Experiment analysis” (A6). In this example, a problem occurred during the lot treatment (A6) and the process was re-executed from the “lot attribution” (A2).


The third analyzed SWR process starts also with the “experiment definition” (A1), followed by the “Lot attribution” (A2). The defined experiment impacts five different operations. The first branch starts with an “Experiment instruction preparation” (A3), followed by the experiment execution at the arrival of the attributed lot at the concerned operation “Experiment Lot Treatment” (A5). The second branch starts with an “Experiment instruction preparation” (A3) followed by an “Experiment instruction preparation validation” (A4). The experiment will be executed at the arrival of the attributed lot at the concerned operation

146

“Experiment Lot Treatment”. (A5). The action flow in the fourth and fifth branches is identical to the first branch. Furthermore, these branches were added by returning from the experiment preparation (A3) back to the “lot attribution” (A2). The third branch is identical to the second one. These five parallel described branches will also finish in the final action “Experiment analysis” (A6).


5.2.1.1.1 Abstraction of the three examples The analyzed examples showed two different discussed aspects of dynamic business process management (cf. section 3.5.6). The process instances are very different and cannot be easily superposed to create a generic process model. Even if the process has dynamic aspects and the process instances seem to be similar, they cannot be anticipated before creating a process, because the number of different process branches cannot be determined. Nevertheless, the process flow within a branch could be anticipated. A generic model has to support this aspect. Therefore, the number of branches could be determined during the process execution and could also be modified. This abstraction of the three PIFA results is based on the two following facts:

- The number and names of predefined actions types is fixed. - The number of actions for an action type in a process can be changed.

This analysis statement confirms the first context analysis in chapter 2. A generic process model is proposed in the following figure:

Figure 64: Generic process model for the experiment processes based on PIFA results

147

This model is a predefined model where changes are anticipated and predictable. The order of actions (process flow) is also predefined, but the number of actions belonging to a certain action type is unpredictable as the number of process branches is unpredictable. The action “experiment definition” (A1), followed by the “Lot attribution” action (A2), are the starting actions of the process. According to the objective of the experiment process defined in these actions, a different number of process branches is created. A process branch contains the “Experiment instruction preparation” (A3) followed by an “Experiment instruction preparation validation” (A4). The action A4 is optional and the necessity of its execution will be defined in action A3. The experiment will be executed at the arrival of the attributed lot at the concerned operation “Experiment Lot Treatment” (A5). The process ends in the final action “Experiment analysis” (A6). Furthermore, the process is not only uni-directional, because problems could occur. Therefore, from each action a possibility to modify the process must be given as shown by the arrows back to actions A1 and A2. Based on this generic process model, the information flow could be analyzed and associated to this generic process model, as explained in the following section. 5.2.1.2 Information Level The abstraction of the three analyzed processes discovered that there are 6 different action types as explained above. The information flow should be analyzed and formalized to the generic process model. Therefore, the information flows from the different analyzed examples are not presented separately; only the generated information flow model is presented. The results of requested and discussed information flows for the three analyzed SWR are detailed in the following: A1 : Experiment Definition Input: Information: (needed: ---, desired: similar executed SWR intermediate or final results) Output: Experiment definition (SWR doc) for all concerned operations, send by email, stored on a shared file server. A2 : Lot attribution for the experiment Input: (needed: experiment definition (SWR doc), already used lots, desired: experiment synthesis for already used lots) Output: Attributed lot numbers to the experiment (SWR doc), sent by email, stored on a file server, set information to the MES A3 : Experiment instruction preparation for an operation Input: (SWR document, needed: experiment definition for one concerned operation, current position (operation number in the fabrication chain) of attributed lots in the cleanroom, desired: already existing recipes on the machines) Output: One document for each lot at the concerned operation. Desired: existing recipes at the machines in the cleanroom, sent by email, stored on a file server. A4 : Experiment instruction preparation validation at an operation Input: (one document for each lot/operation; needed: one document for each lot at the concerned operation, desired: ---) Output: Validation of the documents A5 : Experiment Lot Treatment for a prepared instruction

148

Input: (one document for each lot/operation; needed: One document per lot, desired: existing request recipes on machines) Output: Intermediate results (synthesis, comments, measurements per lot per operation) A6 : Experiment analysis Input: (needed: all intermediate results, desired: similar results or problems from other experiments) Output: analysis result of an experiment This described information flow is illustrated in the following figure:

Figure 65: Analyzed SWR information flow

Information is stored and retrieved from the Manufacturing Execution System (MES). Therefore, the information structure in the MES already influences the way process actors search for information and how they do their work. The PIFA approach showed that there are essentially two different existing applications that are used for managing the SWR process: the LDAP directory and the MES. The existing information structures are integrated into the global experiment process ontologies. Therefore, changes of information structures, values of different categories, etc., will automatically be updated. The maintenance is therefore less time intensive, the coherency between different tools is validated, the used vocabulary is coherent and the information structure is re-used for a semi-automated annotation. A part of the identified categories by PIFA and the existing ontologies in the LDAP and MES system as well as the proposition of combining both domains is detailed. The used categories and free text annotations and their sources (explained in clamps) as discovered by PIFA (cf. Information level of PIFA in section 4.3.3) are as follows: Established Ontology:

Experiment keywords Experiment description (old SWR) Operation number (MES) (old SWR) Operation description (MES) (depends on the operation number) Area (MES) (depends on the operation number) Conditions for the experiment at an operation (old SWR) Lot numbers (MES) (old SWR) Technology (MES) (depends on the lot number) (old SWR) Route (MES) (depends on the lot number)

149

Product (MES) (depends on the lot number) Involved actor (LDAP) (old SWR) Involved actor’s email address (LDAP) (depends on actor’s name) Involved actor’s telephone number (LDAP) (depends on actor’s name) Used recipes for the experiment at an operation Used equipment for the experiment at an operation (MES) (depends on the operation

number) Therefore, by re-using and integrating the LDAP ontology (an actor – has an email and a telephone number) and the MES ontology (lot – has a route, a technology, a product and an operation – has a description, depends on an area, could be produced on different machines) could improve the knowledge management activities. Furthermore, the discussed information flow transfer methods (email or shared file server) could generate some functionality problems as explained in the following chapter. 5.2.1.3 Functionality Level For the 6 discovered different action types the executed functions are analyzed and improvement possibilities are proposed. The analysis groups the functionalities analyzed in the three different examples and gives an overview in the following: A1 : Experiment Definition: Functions: Experiment Description, Matrix creation (operations, conditions) Problem: Different experiment matrices, matrix templates Improvement: Standardize the matrix, propose best templates Proposed KM functions: Retrieval possibilities based on executed experiments (search categories: keywords, operation, operation description, lot, machine, recipe) and supplement semi-automated experiment annotation based on chosen operation (operation description, area; source: MES) and on involved actors (telephone number; source: LDAP), and harmonize the vocabulary for annotation in order to provide better information retrieval A2 : Lot attribution for the experiment: Functions: Choose lot for an experiment Problem: Time intensive to check whether a lot is already used for an experiment (two different Excel tables to compare) and to check current position in cleanroom (MES) for attributed lots Improvement: Standardize the matrix, propose best matrix templates, and integrate the comparison and potential lot proposition Proposed KM functions: Supplement semi-automated experiment annotation based on attributed lots (current lot position, route, technology, product; fabrication due date (source: MES)) A3: Experiment instruction preparation for an operation: Functions: Generate instruction document per lot / operation Problem: Copy information from SWR document to lot-operation-instruction document is very time intensive and redundant Improvement: Automate creation of different documents based on the same input information Proposed KM functions: For each experiment condition, check whether the requested recipe was previously used and should therefore already exist on machines, and integrate this

150

information in the instruction document, supplement annotation of the experiment by experiment conditions, machine, and recipe. Harmonize the vocabulary for annotation (provide a list of validated equipments for the concerned operation) in order to provide a better information retrieval A4 : Experiment instruction preparation validation for an operation Functions: Validate the information Problem: Validate different redundant instruction documents for the same SWR document Improvement: Group the validation for all instruction documents for the same SWR Proposed KM functions: Capitalize the name of the person who validated the experiment for an operation A5 : Experiment Lot Treatment for a prepared instruction Functions: Execute the experiment based on the instruction information Problem: Different source and templates for the lot instruction document (email, telephone, document) Improvement: Harmonize the instruction document structure and format Proposed KM functions: Centralize the intermediate results, provide commentaries on the intermediate results (problems, remarks, etc.), track time for lot treatment (source: MES) A6 : Experiment analysis Functions: Analysis based on intermediate results Problem: Find all different intermediate results Improvement: Centralized information Proposed KM functions: Store analysis results, associate information to the experiment definition, diffuse results to all involved and potential interested actors (actors who already did experiments at this operation in the same or similar context (other technology, other experiment structure).

5.2.1.4 Abstraction and synthesis of the SWR process analysis by PIFA Even if the three levels of PIFA are formalized separately in order to analyze and apply methods of each domain (Information and Knowledge Management techniques, Business Process Management techniques, Requirement Engineering techniques), the results have to be combined into one generic model that represents the current knowledge and process activities as well as improved functionalities. Based on this model, a new work methodology extended with Knowledge Management functionalities and improved work functionalities could be deployed (cf. chapter 4).

151

Figure 66: Integration of the three levels into one model27

As described in chapters 3 and 4, the deployment of a new methodology without any concrete support to motivate and initiate a change is not easy. Furthermore, the context analysis of the experiment process (chapter 2) already showed that even existing tools could not satisfy globally the defined KM goal of knowledge capitalization related to experiment processes (especially negative results and intermediate results and comments). Therefore, a tool, called Experiment Management Application (EMA), was designed based on the established generic process model with improved functionalities, as illustrated in the figure above (figure 66). In the following section, the solution principle and its associated specifications are presented and discussed. 5.3 Specifications of Experiment Management Application

(EMA) The specifications are divided into three different parts. At first, the solution principle is discussed based on the PIFA approach. Furthermore, the functional specifications are discussed and detailed by UML diagrams. Thirdly, the technical specifications and the system’s architecture are briefly explained to point out the technical framework of the solution. A detailed discussion seems not to be necessary as the technical framework depends especially on the given technical infrastructure, meaning that EMA could also be realized with different technologies. The essential are the functional specifications to respond to the employees needs.

5.3.1 Solution principle The abstracted analysis of the SWR process (cf. chapter 2.3 and 2.4) showed that the SWR document contains all information to initiate a new experiment process and is updated with intermediate results and a final analysis to validate the experiment. Furthermore, each actor involved in the process receives the document and takes the information concerning his or her work to prepare the experiment. 27 For a more convivial presentation of this model, please refer to appendix 7.7

152

The information in the SWR document represents the categorization, the process information and the produced knowledge (measurements, results, conclusion, etc.) (cf. chapter 2.4). It is therefore important to centralize this information and notify people about information changes and process evolution. Therefore, the classical document structure has to be aborted and a part of the document can be considered as annotation and process information and will be directly, manually entered in the system, instead of writing a document. This principle is illustrated in the following figure:

Figure 67: Principle of transforming the SWR document

The first part of the SWR document could be re-used as process categorization description. The user can enter free textual annotation and predefined categories of the established ontology. Therefore, the process will be annotated. These annotations represent a part of the context that help to improve the information retrieval and the internalization of the produced process information to new knowledge (cf. Information level of PIFA in section 4.3.3). Furthermore the second part of the SWR document could be considered as the process and experiment information. The number of concerned operations determines the number of parallel branches in the generic process model analyzed by PIFA and the involved actors. By filling in this information, on one hand the process gets more contextual information as annotations, and on the other hand the process instance is constructed as the number of parallel branches depends on the selected operations. Furthermore, the information is redundant with the information in the MES and could therefore be reused from this existing tool (cf. Process level of PIFA in section 4.3.2). The third part of the SWR document represents the results and conclusion of the experiment. Depending on the experiment, different measurements or explications are necessary for the

153

experiment analysis and result explanations. Therefore, the content represents the produced knowledge in the form of a document. To sum up, the produced document SWR results will be stored in EMA. The information stored to prepare the experiment represents the experiment process information as well as contextual information to annotate the experiment process. These annotations could be re-used for a better knowledge retrieval. The selected operation numbers for the experiment as well as the chosen lots represent the core information of the experiment. As an experiment impacts the standard fabrication route of a technology managed by the MES, the information about technologies, lots, operations, etc., exists already in the MES system and the selected operations and chosen lots depend already on the described context, structured by an ontology. This ontology could be re-used and complementary information for the annotation of the experiment could be re-used and retrieved from the MES. This principle is illustrated in the following figure:

Figure 68: Description of the solution principle for EMA

A manual description and annotation of the process and its future stored documents are requested. This annotation is automated based on the given information in the MES. This information will be used, on one hand, to execute and manage the experiment process. To this end, EMA integrates a Workflow management System. On the other hand, this information will be used for better information diffusion by knowledge retrieval interfaces. EMA therefore integrates a knowledge retrieval system. Furthermore, the stored information could be re-used for different objectives:

An existing experiment could be retrieved to avoid making the same errors again A similar existing experiment could be retrieved to improve ideas and the quality of

the experiment A retrieval of involved actors for a process or an operation number could visualize

the competence and knowledge of actors within the process organization By retrieving and analyzing the different operations selected for an experiment,

dependencies could be established and be re-used for further experiments In the following this solution principle will be more detailed by a UML diagram.

154

5.3.2 UML model UML (Unified Modeling Language) is a language that is used to specify technical and functional aspects of an IT application independent from the technical infrastructure [Eriksson et al., 2000]. Based on the PIFA analysis abstraction, use case models could be built for each actor involved in the process (cf. appendix 7.8). Furthermore, the PIFA analysis and also the used case models helped to establish the classes and their relations for the EMA tool. In the following, a simplified UML class diagram is presented. The intention is to present the principle of interactions and relations between the process and information based on the functional and scenario analysis. The real class diagram used for the EMA tool is much more complex, as there are also cardinalities between the contextual information such as a lot, its operations, route, (i.e., a route contains n operations, a route could be affected by m lots, etc.), etc. The identified classes are as follows:

Actor: the actor and his or her information such as name, email, telephone number Role: a role characterized by its name LDAP directory: directory that provides the information and updates about actor

information. Information is redundant with the Actorclass information, but this class is part of another system

ProcessModel: contains process structures about modeled processes Process: contains the process instances created based on the process model

information Action: contains the action, created based on the process model Document: the created and stored documents in the system Descriptive / contextual information: this class represents all information capitalized

during the process execution in actions. It represents descriptive information that can be used during the process and/or contextual information

MES information: The MES information is redundant with a part of the descriptive or contextual information, but this class is part of another IT system.

Figure 69: Simplified UML model of EMA

LDAP directoryPersonID : st ringname : st ringphone number : stringemail : st ringgeneral info : stringname2 : type = initval

MES informationlotID : stringcurrent operation : stringroute : stringtechnology : s tringproduct : string

DocumentDocumentID : s tringdate : datename : st ringtype : stringcontent : byte

Descriptif / contextual Information (Annotation)operation : Integeroperation description : stringexperiment conditions : stringrecipe : stringmachine : stringlotID : StringLot technology : StringLot route : Stringgeneral descriptions : string

1..1

1..1

1..1

1..1

ProcessModelTaskModelIDname : st ringprevious task : TaskModellIDfollowing task : TaskModellID

ProcessProcessID : stringname : stringname : type = initval

0..11..*

0..11..*

1..10..1

1..10..1

ActorActorID : stringname : stringphone number : stringemail : string

1..1 1..11..1 1..1

RoleRoleID : St ringRolename : StringTaskID : StringActorID : String

1..*

1..*

TaskTaskID : stringname : stringprevious tasks : taskIDsfollowing tasks : taskIDs

0..1

0..1

0..1

0..1

0..1

0..1

0..1

0..1

0..*1..10..*1..1

1..1

0..1

1..1

0..11..1

1..*1..1

1..*

1..1

1..1

1..1

1..1

1..*

1..*

155

This simplified UML model represents the relation between information and the process for the analyzed experiment processes. This is the basis for building a tool supporting the knowledge capitalization as information at its source in “real time” and supporting the process management by combining the functionalities of both domains, integrated into one environment.

The functions manage the process flow and support the transfer of knowledge to involved actors.

5.3.3 Technical specifications and realization 5.3.3.1 General features and re-use of an existing Workflow Tool The technical specifications were completed based on an existing generic workflow tool “Apollo” that was reused because of efficiency reason. Therefore, the tool had to be adapted to respond to the functional needs of EMA. The tool was already able to manage complex processes as processes with branches in parallel and related sub-processes and provides a graphical process visualization and access. For each action in a process, the action form (visualized to the user), is structured by components. A component represents a functionality such as completing a data form, selecting a predefined value from a category, etc. Each action form can therefore be modeled with different component structures. A action form, accessed by its owner, allows manipulation of the form (editable form). A action form accessed by another user shows the action form in read-only mode. In order to re-use this technical infrastructure, the generic workflow tool had to be adapted to be able to manage the information flow and the specific functionalities to realize EMA.

Figure 70: Principle of the reused workflow tool Apollo

Requirement: Process visualization as a process comprehension guideline Solution: For each process instance, a visualization of the process is accessible for the users. This visualization shows action dependencies. Actions, where the connected user is the action owner, will be displayed with a bold border. The user can identify the context and relations of his actions in a workflow, as well as estimate the work coming due for current processes. By clicking on the action, he can access the action form. If he is the action owner, the action form can be modified; otherwise, the form will be displayed, but cannot be modified. In this way, the user can more precisely understand the goal of each action or access specific action information.

156

Requirement: Process visualization as an execution guideline, but flexibility in the process execution Solution: The process is predefined. This predefined and visualized process is used to give a guideline to the users of the preferred order of the process execution. As process models often do not represent the “real world”, the predefined order of actions does not have to be respected. Therefore, the notion of “action state” is introduced. The process does not have a state, but each action has an action state. At each action closure, an action state will be attributed. At any time, the users can go back to a completed action and modify it, as well as start any actions in a process without respecting the order.

Figure 71: Process visualization functionality

Requirement: Process instances changes for actions Technical solution: Process instances have to be changed as new actions will be added that are part of the process. Therefore, the notion of a multiple action is introduced. A multiple action is an action having a specific factor. A factor type has n factor-values for a process instance. The factor-values are determined during the process execution and can be changed at any moment. For each added factor-value, an instance of this action is created. Therefore, the number of actions can be changed for each process and the process instance is changed dynamically. For an action having a factor, but no defined factor-values, the action is aborted and ignored in the process flow. Requirement: Process instances changes for process parts and better process overview Technical solution: The notion of a sub-process is used. A process has different actions representing a sub-process. Large processes can be structured more easily and give a better overview about the process, as it can be detailed in different process levels. Key actions and milestones in the process can be better represented. The action state of the process can be better synthesized as the action state of an action representing a sub-process synthesizes all action states in the sub-process.

157

Additionally, by using a factor for an action representing a sub-process, process branches can be added for each process instance as needed. Requirement: Action forms structured by information component Technical solution: The action form displays all necessary information to execute the action and request to fill in text fields, tables or store documents as results of the action. The notion of action “information components” is used. A component displays the component information or text fields, tables, etc. An action form is defined by an order of different components. For each action, the components and their rankings are defined, but can be changed at any moment. The changes impact the process model, and current and future process instances. Therefore, information components could also be used for different actions. Changes in the information requirement can therefore easily be adapted.

Figure 72: Action form structured in information components

Requirement: Process modeling: fast model changes to adapt to changing requirements Technical solution: The notion of process model and process instance are distinguished. A model represents the predefined process flow. A process instance represents an executed process, based on the model. The process model can be changed at any moment. Changes in the process structure will impact new processes launched after the changes have been made.

Figure 73: Principle of process model and generated instances

158

Requirement: Follow-up and project management synthesis of current processes (process object view) Technical solution: The follow-up of processes is very important as processes have also to be managed like projects. Therefore, the process follow-up as process-information objects is introduced, meaning that a process follow-up synthesis is composed as a mix of actions states and information components. A “process content” page is available for each process displaying all information components (chosen as reported) for all levels and actions of the process.

Figure 74: Content report screen: SWR process as information object

The explained reused workflow tool already includes many functionalities and entities discussed in section 4.5.3. Therefore, the abstracted scenario and functionality analysis could be considered as validated. However, the tool did not match all functionalities. No knowledge management functionalities were available (neither category capitalization nor retrieval). Furthermore, the specific domain functionalities analyzed by PIFA had to be developed as explained in the following sections.

159

5.3.3.2 Evolution of the existing workflow tool and developed architecture Even if the basic architecture of a workflow management system already existed, the architecture had to be extended with the Knowledge Management System (KMS), as illustrated in the following figure:

Figure 75: Architecture of the EMA tool

1. User interface of action: the user is involved through actions in a process. He fulfills

the needed information for the experiment process trough the action forms. A action form is structured by information components that could be modified by its owner. Therefore an information flow (information merging to the right action) could be initiated and modeled. All experiment definition information will be fulfilled through these action forms. Additional information as documents could also be stored through these interfaces. As the executed process is a real-time process, knowledge capitalization is also in real-time at its source.

2. Action completion and workflow: Once the action form is fulfilled and completed by the user, the workflow management system manages the process. The completed action will be closed and following actions will be opened. Action owners will be notified about actions they need to do, and they can access the action forms related to these new open actions.

3. Knowledge capitalization through action form: The completion of a action form by a user stores the fulfilled information and documents into the knowledge management system. Therefore, the fulfilled information has a double character: information needed for the process as well as annotation of the stored document and treated process.

160

4. Semi-automated annotation of fulfilled information: The completion of a action form stores the information considered as annotation into the KMS. By re-using the existing ontology in the Manufacturing Execution System (MES), the manually fulfilled annotation will be completed by an automated annotation: a stored document or executed process concerning a certain operation of a technology route. The document and process will be automatically annotated with the operation description and the concerned area. For a selected lot for an experiment, information about the technology family, its route, and its final product will be automatically retrieved and will annotate the process and its associated documents.

5. Knowledge Retrieval: The information stored in the application could be retrieved through user interfaces allowing multiple points of view: the used categories for annotation could be used in any desired order to retrieve interesting processes and associated documents and limit the search results. The retrieved information should help to build new knowledge. Furthermore, the knowledge retrieval could also be a report about current processes (process follow-ups or process synthesis).

6. Re-use existing: The retrieved information should be re-used in order to improve the quality of an experiment as well as to avoid making the same errors again. Therefore, based on existing experiment processes, new processes could be initiated.

The information management, semi-automatic annotation and workflow management are transparent to the user as he sees only the unique user interfaces of the system. Even if they could be considered as different modules, there are dependencies between these modules, as illustrated in the architecture figure.

5.3.4 Technical infrastructure The technical realization depends on the given infrastructure for a project. A functional need could be realized with different technologies. As in this work, a basic generic workflow tool was re-used and had to be adapted; the technical background was not analyzed or evaluated. Today it seems more and more important to minimize the technical support and provide maximal access to applications. Therefore, it is important for applications to be web-based and that they can be accessed via a web navigator program such as Netscape, Mozilla, or Internet Explorer, through the organization’s Intranet. Furthermore, to provide a possible portability to other servers or different fabrication sites, the applications should have maximum independence. These two requirements were fulfilled, as the application was developed with the java technologies (J2EE, JSP) and can be accessed via Internet Explorer.

161

5.4 Use cases EMA In the following, use cases for the EMA tool are presented and explained. First, the support of the process management (workflow aspect) is explained as well as the integrated knowledge capitalization functionalities (manual and semi-automatic). In the second part of the chapter, additional knowledge retrieval functionalities are explained that could help to re-use the existing information.

5.4.1 Use cases for an experiment process execution For the identified six actions types (cf. section 5.2.1), screenshot examples are given and explained in the following section.

Figure 76: Action A1a: Experiment definition: experiment description and annotations

Action A1a: Experiment definition: The user has to fill in information about the goal of the experiment. Information could be free text as well as predefined from a value list of a category.

162

Figure 77: Action A1b: Experiment definition: Split Matrix definition and annotations

Action A1b: Experiment definition: The user defines the Split Matrix that is the core of the experiment. The number of used lots will be selected and the impacted operations of a route for a technology will be detailed. For each operation number, the different experiment conditions will be explained and the number of wafers that will be used for these conditions are selected through a checkbox. Once the Split Matrix is saved, the experiment will also be annotated with additional information existing in the MES system: the operation number will be completed by an operation description and the responsible area section.

Figure 78: Action A2 Lot attribution for the experiment

163

Action A2: The actor is in charge of attributing the lot. The button “Show Lots” retrieves all current lots for the selected technology before the first operation in the matrix that are currently declared in the MES system. Furthermore, previously used lots for different SWRs will be marked as used. The selection of a lot number will import the lot number to the experiment. Furthermore, the lot number is determined by its current operation in the clean room, its technology, its route, its product, its quantity. Additionally, this information is verified every 15 minutes for verified technology routes changes, quantity changes (scrap of wafers) and its current operation in the clean room.

Figure 79: Action A3 & A4: Experiment instruction preparation and validation for an operation

Action A3 and A4: The experiment instructions are prepared and validated in the second form. A user retakes the current fulfilled information, and could modify them and validate them, so the information is transferred to the MES system. Furthermore, in the EMA tool, for each operation a new process branch is initiated. These action forms above therefore concern only one operation. The previously fulfilled information will be shown for an operation and the user can complement this information by choosing a recipe or equipment and give instructions for the lot treatment.

164

Figure 80: Action A5: Experiment Lot Treatment for a prepared instruction

Action A5: After preparing the experiment, the lot is treated in the clean room. A document in PDF format is available that shows the lot number, the concerned operation number and the information needed at this experiment step (figure above). For all treated lots, a return about measurement or split experiment will be entered by an operator who split the lot and executed the experiment (non-standard lot fabrication). For each lot, he can type comments about problems, observations, etc. Furthermore, he can store documents about measurements. A text form “Measurement Conclusion” will request a synthesis of the measurement results. The stored documents through this action form will therefore be annotated with the conclusion annotation, as well as all completed annotation in this process (i.e., cf. action A1 & A2, operation number, lot number, technology, etc). For screenshots of this action form, please refer to appendix 7.9.

Figure 81: Action A6: Experiment analysis

165

Action A6 : The final analysis is done based on the experiment description. All entered information during the experiment process will be retrieved (by the functionality process-object-view (cf. section 2.3.4.3) and used to produce a final document containing the most important aspects of the different experiment results at each operation and the interpretation of these results and measurement. The final SWR document, which does not contain the experiment conditions, but only the interpretation and results, will be stored through this action form and it will be annotated by the text form “conclusion summary”, as well as all fulfilled information through the process execution.

5.4.2 Example for dependencies between actions (information flow and process flow)

The following picture illustrates the described principle of separating the SWR document in different information entities and reusing it in different actions (merge information to the right actions). The experiment will be defined in the action “experiment definition” and the action form of this action is structured in information components. All concerned operations and their experiment conditions will be defined. Furthermore, the wafer used for an experiment condition can be selected. This information will be reused in different actions and complemented with recipes and equipment information as described by PIFA. Therefore, the experiment information will be divided into different information entities (one entity per operation) and the information entities can be re-used according to the user needs.

Figure 82: Information separated in entities and merge them to the right action

The presented use cases are necessary to manage the process flow. However, the capitalized knowledge through the execution of processes should be reused. Therefore, knowledge retrieval interfaces are provided as explained in the following sections.

166

5.4.3 Knowledge Retrieval functionalities The knowledge retrieval interfaces are necessary to introduce a cross-over knowledge

sharing between processes. Therefore, two different types are provided: reporting and retrieval interfaces.

5.4.3.1 Reporting Reporting Interfaces help the user to see current experiment processes that are not yet finalized. A synthesized experiment view is provided for the connected user and explains the impacted operations of an experiment, the involved actors, the goal and the attributed lots and its current position in the clean room, and its previewed sorting date. An analysis can be done once a lot is sorted and the fabrication is finished. This screen helps the user to organize and anticipate work coming due. Furthermore, a filter is provided to change this information and display experiment information from different users (a colleague or another process actor as well as for a group). The experiment process graph can be accessed from this reporting screen. Therefore, simple knowledge retrieval is provided as the user has an information report to know about the current work of their colleagues.

Figure 83: Reporting of current SWR processes

5.4.3.2 Retrieval Retrieval Interfaces are provided to allow the users to search for similar SWR experiment processes. However, the goal and need of a search could be different and more or less precise. Therefore, three different retrieval interfaces are available that provide more or fewer possibilities to express their needs. This fact also impacts the number of results retrieved from EMA: a detailed search will retrieve less results than a simple keyword search. Therefore, the results are also configured according to the search interfaces. In particular, the technical aspects of information components are reused for providing different results

167

interfaces. Related to the retrieval interfaces, more or fewer information components are shown.

5.4.3.2.1 Simple key-word search This interface allows searching for one or more keywords contained in an experiment process. As the keyword could be used for many different experiments, only the experiment title, the start and end date are shown to the user.

Figure 84: Simple keyword search

5.4.3.2.2 Experiment context search This interface allows searching in one or more categories describing the context of the experiment: (lot, technology, route, product, operation, operation description, area, actor name). As the search need can be better verbalized and more detailed, the found results will be fewer than a simple keyword search. Therefore, the result interfaces provide an experiment synthesis about impacted operation numbers, involved actors and attributed lot. Furthermore, the component “Split Matrix” is displayed for each experiment in order to detail the experiment by giving the experiment conditions and the selected wafer for each condition. The categories of each search category are automatically updated, as the values that can be selected for a search are only the values that have already been chosen for a process annotation. Therefore, only values can be searched that exist as annotation in the KMS. By searching for a technology, route or product, employee’s names are displayed that already worked on existing experiments. This information retrieval could also be used to identify actors with a specific product, route or technology knowledge.

168

Figure 85: Experiment context search

5.4.3.2.3 Experiment detail search This interface allows searching in one or more categories also describing the context of the experiment, but in order to look for very precise and specific information (operation, operation description, area, actor name, recipe, machine). As the search need can be better verbalized and more detailed and the objective is to find specific information, the result interfaces provide the experiment keywords and the component “PartSplitMatrix” to detail the specific searched experiment conditions such as operation number, description, area, recipes and machine.

Figure 86: Experiment detail search

169

By searching for a recipe, lot or equipment, employee’s names are displayed that already worked on existing experiments. This information retrieval could also be used to identify actors with a specific recipe, equipment or lot knowledge. 5.5 Change management

5.5.1 Advantage of PIFA for change management The benefit of using PIFA according to the change management is, as explained (cf. section 4.3.4), that surplus value is identified, which motivates the user to use the tool. On the other hand, a natural resistance against changes could be expected. By using PIFA, the potential users are involved in the formalization of the process and the conception of the tool. They helped to fill out the PIFA templates in order to identify the most important aspects of the process. Therefore, the interviewed potential users will be the key users for the system and support the deployment. The first version is tested and validated by these key users, and they will also be involved in the deployment. As they were involved in the conception, they are familiar with the functionalities of the tool and the current problems that will be resolved by the tool. Furthermore, they explain to and motivate their colleagues to use the tool. This fact also facilitates the training of the tool. During training, problems of using a tool often cannot be completely anticipated and FAQ’s and user guides are not complete. Therefore, current problems occurred in a department could directly be resolved by the key users as the question are addresses directly to a person who is familiar with the tool and is also a team member.

5.5.2 Opportunity Changes As illustrated in the previous chapter, the experiment process analyzed by PIFA discovered a process flow containing 6 different actions. PIFA analyzes the current process and the business process re-engineering approaches generates a generic process model and helps to optimize current functionalities based on the actor’s point of view. The involvement of the management in the EMA tool is very important, as a natural resistance against changes exists (cf. section 3.3.3.1). Therefore, the supported process must be validated before the tool can be deployed. The difficulty of the experiment context is (cf. section 2.3.2) the involvement of three different organizational departments that have different points of view and especially different objectives. The management decided that the proposed SWR process by PIFA needs to be enriched by integrating the experiment instruction validation (A4) as obligatory and adding two additional management validations: one after the experiment definition (A1) and the second after the analysis of the experiment to validate the results. These additional actions were not accepted by the users. Experiments could be launched urgently and concern a lot arriving within the next 24 hours. A validation process that concerns 4 different actors who are not immediately available could take from 1 to 3 days. It is unacceptable that a lot in the clean room will not continue its fabrication route for 3 days while a management validation is requested. For this reason, the additional validation actions were deleted from the generic process model before the deployment of EMA. The optional Action (A4) “Experiment instruction validation” was kept as mandatory within the process, but flexibility was given to the user by having the possibility of choosing a colleague for this control action instead of pre-defined management users.

170

Furthermore, in section 3.3.2.2 it was explained that opportunity changes could appear. In the context of the SWR process, and according to the fact that it is not acceptable to wait for a validation to treat the lot at an operation, the production manager insisted on erasing the functionality of “holding a lot” at an operation during the lot attribution phase. A lot should not be in a stand-by mode waiting for an instruction preparation and validation in order to be treated. He considered that in the past, many lots were held for several days before being treated. By holding the lots until the instructions are validated, the risk that the production time increases because of lost tine for validation is high. On the other hand, the experiments are sometimes executed on a specific lot requested by different organizational parts. Therefore, it is primordial that the experiment is done for this specific lot. Another lot cannot be chosen and if the initial selected lot will continue its fabrication route without being held at the concerned experiment operation, the experiment time will increase and quality improvement will take more time (time-to-market increase). An argument for erasing the functionality of lot holding during the lot attribution action was that in the case of a specific requested lot, the holding could be done in the “classical” way, meaning through the MES system. This change could be considered as a threat, according to the change management, as the use of an IT tool is often voluntary (cf. section 3.3.2.2). If the surplus value of holding a lot through EMA is removed, no incentives are given to the user, as it is considered only as an information tool to fulfill completed work and it no longer represents the real processes and executed work. Therefore, the functionality was kept to be integrated in EMA. Furthermore, alert notifications were implemented to inform all actors involved in an experiment process of a lot approaching a concerned experiment operation 3 days before arrival (1 email per day) if the instructions are not yet validated. The experience of using EMA showed that only 4 times was a lot held without validated instructions compared through 380 experiment operations, representing 1,05 %.

5.5.3 Deployment and change monitoring In section 3.3.2.3, a change monitoring model was proposed to supervise and analyze the deployment. To evaluate the user resistance, the support of the management and the surplus value, an initial test phase was launched on 20 users. In fact, three DYE engineers were identified who launch experiments and who were involved and interested from the beginning in supporting the experiment process management by an IT tool. They launched their experiments through the pilot version of EMA and, depending on the experiment content, different area engineers were involved. This test phase allowed for the discovery of functional misunderstanding and technical problems. Especially as different types of area engineers were involved; employees who were not involved in the conception phase were invited to use the tool. This fact particularly allowed an analysis of the reaction of resistant employees and to have a return of experience and a different point of view than the point of view of employees who were already involved in the conception. After correcting some problems, the tool was deployed to 300 users in different phases. All DYE engineers and areas were trained and two areas in the cleanroom were trained to slowly deploy the tool to avoid disturbing the production and also to anticipate and analyze the return of employees and potential problems. Finally, only minor problems occurred and the tool was deployed for all areas in the cleanroom. According to the advantages of centralizing the information flow, reducing the number of lots held without instructions and standardizing the process and harmonizing the work methods, the management declared the tool as a reference to prepare and execute the experiments.

171

Supported and motivated by the management, all DYE employees prepared their experiments through the EMA application. The deployment for the R&D engineers started at the end of September 2006. Even if the deployment was positive and has not encountered major problems, some problems occurred and several employees were resistant to the changes, as explained in the following sections. 5.5.3.1 User resistance, management support and surplus value As all users previously prepared their experiments through EMA and every user had his or her personal work behavior, some aspects of EMA were too fixed and inflexible, and some users had problems adapting to the new way and the structure of actions and functionalities: some users initiated an experiment in twelve minutes, other took up to 3 hours to do the same work. This large time difference is first of all related to the IT functionalities: some functionalities were not clearly understood and were different from the previous habits for the users who have a different point of view. Secondly, the new developed work methodology was not respected by all users. The experiment should have been discussed in advance with the involved actors before launching the experiment through EMA. Nevertheless, some users launched the experiment without preparing and verifying the impacted operations. Some operations numbers were not correctly entered and had to be corrected. As the one of the secondary goals was to force the actors to better prepare the experiment, functionalities of changing the entered operations were not provided and had to be corrected manually through the system administrator. Furthermore, even if EMA provides a lot of surplus value and minimizes the time for an experiment preparation (in most cases), the tool takes between 10 sec and 1min30 to change from one screen to another. The waiting time is considered as inefficient and lost time by the users, and even if a gain is provided, the waiting time is the most perturbing aspect. Nevertheless, EMA is still the reference for launching an experiment and the technical infrastructure will be optimized to increase the performance of the software tool. As the management agrees to the formalization and clarification of the SWR process and its execution through an IT tool to increase the visibility, the responsibility and the knowledge reuse, they supported the deployment of the tool. Furthermore, the opportunity change possibilities referred to a higher productivity (faster lot fabrication, decrease the number of lots in hold) and gave another incentive for supporting the deployment of EMA. Most of the users agreed to the conception and functionalities of the tools and motivated their colleagues to use it. Special appointments by the management or formation through persons in a management position were not necessary to integrate EMA in the daily work activities.

172

5.6 Measurement of gain and return of experiences

5.6.1 Use of EMA As explained in the previous section, EMA is currently used at the Front-End Technology and Manufacturing R&D Site in Crolles (France) by 300 different users and will hopefully be selected as a corporate tool and be deployed to different ST production sites worldwide. PIFA therefore helped to capture the requirements of a dynamic environment. This tool has been adapted to a specific context (organization, process, responsibility). As the tool is developed in order to be flexible and generic, the process model can be changed easily by an integrated modeling tool. Changes could therefore be done very quickly and the tool could be adapted to a changing context or to a different context on other fabrication sites as the cultural aspects, organization and responsibilities could be different. The return of some users is very positive, as the visualization in particular allows following up the process and all information is centralized, and redundancy or incoherence in information do not exist. Furthermore, the flexibility of returning to an action during the process makes it easier to represent the “real world” process and does not present a constraint for the utilization. On the other hand, other users do not agree with the EMA tool. A surplus value especially exists for the enterprise and for each user, even if it is not recognized by all users. Therefore, the involvement of the management was very important in maintaining the deployment and use of EMA to all concerned organization departments. EMA is a tool that runs on two different servers to guarantee a high availability of 99.9 %. The actual use of EMA on these two servers is represented in the following figure:

Figure 87: User statistic: number of visits and hits on EMA28

1180 different users visited EMA in September with a daily average of 40 visits per day. Within the application, 380 experiments were launched since the beginning of the deployment. Since the official deployment of EMA in June, 216 experiments were managed by EMA, representing 484 different operations impacted at these experiments. For these experiments, 533 lots were attributed and represent therefore a total of 1280 different experiment manipulations supported by EMA. 28 For more statistic reports, please refer to appendix 7.8

173

The goal of EMA, designed through a support by PIFA, is to improve current process management activities and knowledge management activities. A return to these two aspects has to be analyzed.

Process Management: immediate return (needed knowledge) Knowledge management: return in time (desired knowledge)

5.6.2 Return and gain of needed information flow management Prior to the implementation and use of EMA, an engineer doing an analysis estimated that “it takes 30-40 minutes to search for information concerning an analysis and doing a synthesis to start the analysis”. In the EMA tool, the information is real-time information about lot position in the clean-room, scraps on lot and all concerned information is centralized. Therefore, by merging the right information about experiment conditions and lot information into a action form, the time of searching for information could be reduced to 10-15 minutes in order to navigate within the process and understand the capitalized process information. Even each process actor, instead of retrieving and verifying information in different tools or requesting complementary information from process actors, profits from merging these information to the right action and can gain 5 minutes by saving time in retrieving information from different tools (as Outlook E-Mail, MES information, telephone). Furthermore, the preparation of a SWR took from 20 minutes (an experiment concerning one operation and one lot) up to 1h20 (an experiment concerning 5 operation and 10 lots). The time needed for preparation in EMA takes 15-25 minutes for these experiments. The opportunity change also reduced the number of lots in hold without validated instructions. Furthermore, by a harmonization of working methods, information sources and their transfer modes (ergonomic, access, etc.), an employee can change the organizational department without having to adapt to new methods and standards. In particular, an operator who is having a transversal activity by treating lots in different areas no longer has to adapt to each standard of each area. This harmonization could be considered an advantage, but it is difficult to measure this gain. In addition, the capitalization of contextual information and annotation for an experiment and the semi-automatic annotation based on the manual annotation through the MES system all help to better understand the experiment and allow generating reports such as process-follow-up. Furthermore, the integration of the needed information to a action form centralizes all concerned information for the user. Therefore, the needed information is merged into the right action and represents knowledge management activities in the mono-direction of the process.

5.6.3 Return and gain of desired information flow management EMA provides three different search interfaces as analyzed by PIFA. Unfortunately, these interfaces were only realized at the time of writing this chapter. Therefore, only an estimation and first user feedback can be given.

174

The provided retrieval interfaces are sufficient, according to some interviews with 3 actors. The search possibilities in particular with the possibility according to detail and display of different search results by showing specific information are considered as interesting. However, technical problems still occur as a search can take up to three minutes. Technical improvement efforts are also currently under development. The behavior of users in searching for information is first of all concentrated on information about processes launched in the last few weeks to obtain a process follow-up, modifying information or consulting the intermediate and final results. Currently, the search interfaces retrieve the information in a very efficient way, but this positive result is first of all related to the fact that there are not many experiments managed by EMA at this time. The way users search for information will change over time, as searching by one category will no longer be efficient. Therefore, the interfaces probably also need to be adapted. Furthermore, for the first retrieval interface (simple keyword search), 2.500 existing SWR documents were migrated to EMA to allow the user search in it. A complete migration and annotation of the existing 2.500 SWR documents with the SplitMatrix, Operations, Experiment condition, recipe and machine was not possible. Even if a SWR template existed, it was often not completely fulfilled or the structure was not respected. Complementary information about the experiment was managed by other applications and is no longer accessible. Therefore, only a keyword search exists, which is not efficient as a category search. According to the user feedback, however, it is a gain to be able to search in the existing SWR documents. The declaration of EMA as the official reference for launching an experiment occurred just 2 months before writing this report. Therefore, misunderstandings on using the tool still exist as some users still refer to their old behavior and aren’t used to the new work methodology and the new tool. Furthermore, users who launched experiment processes in EMA still remember the goal and the results (as a process takes a minimum of 7 weeks): As direct and personal contact is preferred, the users will ask therefore their colleagues before searching for information in EMA. The goal of the knowledge management is to share experiment knowledge (positive and negative results) that would not be shared normally. Therefore, a positive result could be estimated at the moment, but an analysis and observation of the use of retrieval interfaces must be done in 3-6 months, and should be done periodically in the future to adapt and capture the changing environment. Knowledge is also changed in a tacit way. The goal of knowledge management of EMA is the knowledge reuse in an asynchronous and delocalized environment. Therefore, the use of knowledge capitalized through EMA is important in time. A knowledge reuse activity in a synchronous and localized environment still exists in the form of meetings, phone and email. The knowledge management gain of EMA can therefore only be analyzed in the future.

175

5.7 Conclusion In this chapter, the application of PIFA in the context of experiment processes was discussed. PIFA allowed formalizing the experiment process flow, the associated information flow and understanding the needed functionalities for an experiment process management. Furthermore, the PIFA approach allowed the formalization of the different used ontologies and generated a domain ontology for the experiment process domain. Based on the analysis, the conception of the EMA tool was explained. The tool was deployed and is currently used by 300 users. Even though some difficulties related to user resistance occurred, the tool is generally accepted and used. The tool primarily supports the execution of experiment processes and the capitalization of knowledge during the process execution. An immediate use of this knowledge is realized by merging the right information to the right action (saving 20 minutes), and therefore to the right user. Furthermore, a later reuse should be supported in order to avoid errors and improve the quality of a process result. The designed knowledge retrieval interfaces are used, but a positive influence on the process experiment processes can only be analyzed in the future.

177

6 GENERAL CONCLUSION

This chapter gives a general conclusion and perspective of the work. The successful conception of EMA based on PIFA could be considered as a validation of PIFA. Nevertheless, PIFA should be tested on other domains.

6.1 Synthesis Knowledge Management has gained in popularity in recent years, but concrete application models are still missing. Implementation approaches of Knowledge Management (KM) are often concentrated on the capitalization of produced knowledge and deliver an IT tool in order to keep knowledge in time. However, knowledge is not a stand-alone discipline. It is produced during daily work and capitalization activities should therefore also be related to and integrated into daily work activities. Knowledge is also consumed within daily work. Therefore, a distinction between

“needed and desired knowledge”

is made as needed knowledge is already shared (even if shared methods are not optimal and could be improved). KM activities should especially concentrate on the sharing of desired knowledge. As it is not needed for daily work activities, the sharing is often blocked by organizational barriers, thereby missing context (by missing access and internalization problems). But this desired knowledge presents a surplus value by improving the quality of work or avoiding errors. Furthermore, knowledge capitalization activities should be concentrated on the knowledge needs. The implementation of new working methods containing knowledge management aspects are difficult to deploy without any support. Therefore, it could be helpful to deploy a new methodology with an IT tool. However, natural user resistance exists and should be anticipated. Furthermore, the use of knowledge management activities through an IT tool cannot be completely anticipated, as IT offers diverse possibilities of sharing information. Therefore, the change should be accompanied to detect and adapt a change management strategy for opportunity changes, user resistance and other problems in order to guarantee the success of the KM work methodology implementation. The most important objective is to detect how the knowledge flow is and could be integrated into daily work activities. Therefore, the Process Information Functionality Analysis (PIFA) helps to formalize the context of process flow, its associated information and the needed functionalities.

178

For each action, the previous action, input information, and functionalities to transform input into output are analyzed. Therefore, three different levels of PIFA are established:

The process level: Formalize the process flow of each analyzed process and try to build a generic process model supported via Business Process Analysis or Business Process Re-engineering approaches. The generated model should also be very flexible to support dynamic changes within process instances or in the process model. By being as flexible as possible, the process model will represent the “real world”—the real executed process—as precisely as possible.

The information level: Formalize the information flow associated to the process. In

particular, the current used type (implicit/explicit) and the used tools are analyzed to understand and formalize the current context and used infrastructure. The discovered information flows help to merge information to the right action and therefore at the right time and to the right people. The information flow should not be supported only in the direction of the process, but especially backwards through the process (a return of experience information flow) and cross-over (between) processes. Therefore, the needed and desired knowledge especially is analyzed. The knowledge produced within a process should be capitalized as needed knowledge to give an immediate surplus value to the employees and be reused as desired in the future. Therefore, the contextual information annotation of processes and its produced information is primordial. Knowledge management techniques such as ontology, annotation and semantic approaches could support this level.

The functionality level: Formalize the functionalities executed within an action in

order to transform the input information to output information. Functionalities are formalized by interviews based on the PIFA template as well as on observations of the analyzed process actions. In discussions with the interviewees and based on the formalization of these functionalities, problems are analyzed and improvement possibilities are detected. This optimization represents additional surplus values for the companies and for the users and gives the necessary incentives and motivations to the users to accept a new work methodology. This methodology is enriched by an extended knowledge capitalization and contextual information annotation and an improved desired knowledge sharing.

Furthermore, the implementation and deployment of a new work methodology can be supported by an IT tool. Therefore, the application of PIFA on the context of experiment processes allowed specifying and designing the Experiment Management Application (EMA)—a tool to support the experiment process and its associated and produced knowledge. EMA integrates the generic experiment process model in order to manage the execution of process experiment instances. The action form (user interfaces of an action) will, on the one hand, support the execution of the functionalities of an action and allow the continuation of the process by completing an action. On the other hand, knowledge capitalization methods are also provided through these action forms. These knowledge capitalization methods are based on the principle of annotation and semantic approaches supported by a domain ontology. The practical integration in EMA is based on the analyzed and formalized experiment domain ontology. Furthermore, a relation between EMA and the Manufacturing Execution System (MES) is realized in order to integrate necessary information into the actions and push information to the MES (one of the major needed functionalities/surplus values). The capitalized knowledge through these processes will be used as contextual

179

information in order to initiate a knowledge re-use by integrating an information flow backwards through and cross-over between processes. The EMA tool, based on the scientific framework of knowledge management and business process management, supports in particular certain activities for written information content (artifact, intermediate and final objects) produced and associated with business processes:

The creation and management of experiment processes through actions assigned to users

The capitalization of experiment details representing important experiment

information as well as contextual information annotation of the process and its associated and stored documents

The semi-automatic annotation of experiments based on manual annotation and

completed by information from the MES

The knowledge retrieval supporting the research in categories identified as desired knowledge

To sum up, PIFA can be considered as an approach to detect the needed and desired knowledge flow associated with business process. Desired knowledge flow is often limited because of organizational barriers. Knowledge Management techniques such as ontologies, semantics or annotation, used for a capitalization and retrieval, could support and improve this desired knowledge flow. To integrate and deploy this desired knowledge flow, the functionalities detected by PIFA and associated with the process have to be improved to give incentives and motivate the user to accept the new work methodology by integrating KM aspects of the desired knowledge sharing. 6.2 Limits of PIFA and EMA PIFA is considered to be applied as an interview template to analyze knowledge intensive dynamic business processes. It is therefore the basis for an analysis and an improvement. PIFA can be applied in a context of one of the described types of the discussed knowledge environment (Chaos, Complex, Knowable, Known) (cf. 3.2.3). Furthermore, the application field also includes the different process types (especially dynamic ones), as described in section 3.5.5: Production, collaboration, administrative and ad hoc processes.

However, the goal is to harmonize and standardize the different PIFA results to define a methodology in order to support knowledge management activities associated with business processes. Therefore, a repetitive character must be added to the goal of the PIFA approach and also to the type of treated processes and the knowledge environment.

As explained in section 4.4.3, PIFA can be applied on all different process types, but, for example, in the case of “ad hoc” and “collaborative” processes it will not be easy to find a generic process model or to identify the repetitive action family types involved in different process structures.

Furthermore, the proposed generic process model by PIFA is a process model that represents the current executed business process in a context and therefore is adapted to a context. Business Process Re-engineering is considered as an opportunity for change and should be applied after a deployment and an acceptance by the users. The goal is primarily to motivate

180

the potential users in accepting a lower flexibility by using an IT tool, as well as accepting a higher knowledge capitalization by receiving improved functionalities that represent a high surplus value and compensate for these changes.

The PIFA approach is primarily a user approach and concerns the involved actors in a process. The improvement of business processes and related functionalities are therefore based on an actor’s point of view and are local improvements are not the ideal improvement for the whole process. PIFA initiates the transformation of practices and of organizations, probably supported by an IT tool. These changes are brutal, but they are voluntarily accepted by the employees. Therefore, PIFA is a good approach for initiating adaptive changes; however, for example, in crisis changes, PIFA does not deliver a model. PIFA could therefore help to clarify the context, but other methods from Business Process Re-engineering should be applied to change the process more radically than proposed by PIFA.

EMA was constructed in order to support knowledge intensive experiment processes. The experiment processes could, as described, be considered as a production process that is characterized by a large number of involved people and several concerned heterogeneous systems. The goal was to capitalize a large number of different produced knowledge objects related to these processes (cf. section 2.6, section 3.2.4.3): final, intermediate or artifacts in order to initiate a re-use. The return of experience showed that this problem was successfully solved. However, not all produced knowledge during these experiment processes is, capitalized as the employees still have other support methods and habits in sharing needed knowledge immediately for an experiment process, such as by email, over the phone, in meetings, etc. Artifacts or intermediate objects in particular, even if they are formalized, can still be saved on a local disk or shared network. EMA is a good approach to increase the knowledge capitalization, but not all tacit knowledge can be formalized; even if it is formalized, it could be difficult to make accessible. Furthermore, the context (capitalized manually or automatically for the experiment processes) and the associated documents help the involved actors to retrieve previous information. This context information depends on the characteristics of the used machine, raw materials and recipe. If the context changes, i.e., using a new machine (and the way the involved actors construct the recipes changes, but the signification is still the same), EMA will not recognize that the two different symbols concern the same object in the real world. Therefore, the ontology must be restructured again. Furthermore, the used context depends on the partially reused Manufacturing Execution System (MES) ontology. Transferring EMA to other manufacturing sites will necessarily invoke an analysis of the local, existing ontology and update EMA accordingly. Furthermore, the ontology built through interviews is the vocabulary used by involved process actors. This ontology contains common elements that are understandable by all involved actors (such as lot number, technology, area), and also, for each involved organizational department, a specific part that is not understandable for all process actors (such as recipes, machine). Therefore, a new employee who does not yet know this specific organizational department vocabulary will have difficulties in retrieving needed knowledge. Therefore, EMA responds first of all to the problem of preserving and reusing knowledge for experiment actors.

181

6.3 Conclusion This work was initiated in response to an industrial problem of improving the knowledge capitalization, sharing and reuse associated with the experiment processes in the microelectronic domain. Knowledge Management can support various activities in industrial organizations, but they are sometimes badly implemented via IT or are often considered as a stand-alone discipline. In fact, Knowledge Management activities are part of daily work activities, especially part of business process. In order to produce a good or a service, knowledge is produced and immediately used in the execution of these processes. Furthermore, knowledge could be reused backwards within a process as well as between processes. The main problematic is therefore to analyze the process and the associated knowledge flow in order to support the capitalization, sharing and reuse of knowledge. Furthermore, new implemented methodologies are confronted by a natural user resistance that depends on the new surplus value and the management support. Current knowledge management models often explain what to do and model the abstract transfer of knowledge “object” exchange, but do not detail how to do it. To respond to the problematic, the PIFA (Process Information Functionality Analysis) approach was developed to analyze knowledge intensive business processes. PIFA analyzed the actor’s point of view involved in a process. For each action it analyzes three different levels:

The Process level: dependencies for previous and next actions, possible actor or

group of actors assigned to this action in order to clarify responsibilities and structure the process

The Information level: information produced and used in process actions in order

to merge the right information to the right action and increase the knowledge capitalization through information formalization. Contextualized information capitalization in order to construct a process domain ontology and reused existing ontologies for the annotation of the related process and associated produced information

The Functionality level: functionalities necessary to transform the input

information into output information in order to propose functionality improvement to decrease the natural user resistance against changes and give incentives and motivation to accept the new formalized work methodology enriched by KM activities

The distinction between needed and desired knowledge allows an understanding of which knowledge is reused immediately in the process (needed knowledge) and which knowledge could be reused, but the exchange is inhibited because of organizational barriers and missing context (desired knowledge). Knowledge capitalization activities should especially concern the capitalization, sharing and reuse of this desired knowledge. Therefore, PIFA helped to identify where this knowledge is produced and used as needed knowledge and how it could be capitalized in order to re-use as desired knowledge. PIFA was applied on the microelectronic experiment processes. Based on a designed generic process model, EMA (Experiment Management Application) was designed to support the experiment process and its associated knowledge flow. Three major principles can be found in EMA:

182

User interfaces to manage the actions within a process. These interfaces integrate

improved daily work functionalities to decrease the user resistance and give incentives to use the tool, as well as integrating knowledge capitalization functionalities. For example, it is obligatorily to store documents and annotate the process and the stored document through predefined categories.

A link to the MES (manufacturing execution system) allows avoiding information

incoherence as information fulfilled in EMA is automatically transferred and updated in the MES. Furthermore, the used ontology and existing information structure in the MES can be reused for a semi-automatic information annotation by completing the manually annotated documents and processes.

Knowledge retrieval interfaces based on the constructed experiment domain ontology

and the identified contextual information in order to optimize the efficiency of a system and offer a multiple viewpoint access for the user either through the common vocabulary or the specific domain vocabulary for each involved organizational department

Furthermore, the PIFA approach and the resulting EMA tool were constructed in the microelectronic environment. Even if PIFA was constructed to cover the maximum number of potential application fields and contexts, and if during the design of EMA it was anticipated for a deployment on different fabrication sites worldwide, some characteristics are context specific and could be improved in scientific and industrial work, as explained in the following chapter.

183

6.4 Perspectives The goal of the PIFA approach is primarily the integration of knowledge management into business processes. Therefore, the main focus of this work is on the characteristics and specifics of knowledge management and its integration into business processes where the main focus emphasizes the knowledge capitalization through the execution of business processes. Furthermore, the way Knowledge Management System (KMS) are implemented in an organization is discussed and principles of change management are integrated into the PIFA approach to guarantee a successful deployment. The approach of the PIFA results in this work is only used for a Knowledge Retrieval (Pull) solution. Furthermore, it could also be interesting to integrate Push approaches to reuse the capitalized process information, such as using approaches from case-based reasoning in order to apply the PIFA results. In addition, the process level could be enriched by a deeper analysis and integration of business process re-engineering methods and the functionality level could profit from a deeper look on sociology and requirement engineering approaches. Furthermore, the information level could also profit from approaches and techniques of related knowledge management domains, such as knowledge discovery. The current state of the PIFA approach was applied on a complex, but repetitive process environment with predictable, dynamic characteristics. Even if PIFA was designed to be applied on a dynamic process environment (such as ad hoc or collaborative processes), it would still need to be applied and tested whether the received results could be reused in order to develop a new KM work methodology. Therefore, PIFA should be tested in different contexts and industries as well as scientific application fields, such as research projects. Furthermore, the PIFA approach is only concentrated on its three levels (process, information and functionality). However, a risk analysis or risk management isn’t implemented in this approach and should also be taken into account to manage the risk associated to these changes and related to the nature of analyzed business processes. The PIFA results were used in order to build an IT tool to support the experiment processes. The conception of the IT tool was based on the current infrastructure and information standards. Ergonomic style sheets were re-used in order to provide the usual navigation possibilities to the users. The transfer of the PIFA result to a conception of an IT tool could profit from reflections of ergonomic approaches or other similar approaches. Therefore, best practices to transfer these results in informatics conception and languages could be interesting. The goal of EMA was to improve the experiment process management, giving a surplus value to the user by using the tool and integrating a knowledge capitalization into the process execution in order to build a knowledge base and motivate the user to reuse existing experiments. Even though EMA was declared as the official tool to manage the experiments and it is currently used by 300 people, the transition phase is not yet finished. EMA is still in concurrence to the previous used tools (cf. section 2.3.3). As it is a new tool and as it has interaction with the MES and LDAP directory, unanticipated informatics bugs still appear and need to be corrected. The first objective should be to stabilize the application. Secondly, the deployment of EMA on different fabrication sites worldwide could produce informatics difficulties as they use different structures of the MES and therefore different used domain ontologies. Furthermore, the experiment processes in EMA represent the organization in the Advanced R&D, but especially could be confronted by organizational problems with different responsibility structures and culture differences. Therefore, the analyzed processes could be different. In this case, PIFA should be applied to each site and the process model in EMA should be adapted to each site.

184

Furthermore, EMA is primarily a tool to help the involved actors to execute the process. Nevertheless, the capitalized knowledge could also be reused by the management and be part of a decision making process in strategic questions to obtain a global goal and the gain of the experiments. Furthermore, the capitalized knowledge could be explored in different ways; i.e., the competence of each system user could be retrieved (involved in different technologies, products, and operation experiments). Furthermore, the dependencies of operations could be better explored and integrated in EMA. Nevertheless, PIFA is an approach to build up a best practice for combining knowledge and process flows in a specific context. Best practices are important, but should not be applied without knowing the context. Each methodology should take into account the context specifics. Therefore, PIFA should also be critically analyzed before applying it to a context in order to see limits and to develop PIFA. EMA supports the formalized knowledge as information flow and the experiment processes. Even if the tool is a “real-time” process and actively used to represent the real process, knowledge is still exchanged in tacit and implicit ways.

185

7 APPENDIX 7.1 The microelectronic domain In the following picture, the comparison of the size of a transistor on a microchip is explained: a transistor on a 300 mm wafer is as big as a table tennis board on earth; additionally France on earth is as big as a microchip on a 300 mm wafer:

Figure 88: Relation of microelectronic sizes to earth

The fabrication of these increasingly smaller technologies has to be increasingly precisely. At the same time, fabrication machines become more and more expensive. Market growth evolution is related to end-product technology the microchip will be used for, as Computers, DVD players, mobile phone technology, etc. New technologies or consume goods appear on the market with a certain time distance. This time distance is necessary to sell and make profit with the current products. Therefore, microchips are ordered in a high volume at the beginning of the fabrication phase and lower volumes will be ordered after market entrance. Therefore, the microelectronic domain grows in a periodic cycle. This fluctuation is shown in the following figure:

Ø 13500

Ø 300 23 mm

1000 km 4 m

90 nm

186

Figure 89: Market cycle, Total semiconductor 1986-2006, $ Growth Rate

ST tries to anticipate this regular fluctuation by doing investments in low peaks as well as to anticipate future client needs.

7.1.1 STMicroelectronics: company and strategy presentation ST is one of the leaders in the microelectronic domain. STMicroelectronics (STM - name created in 1998) is a French-Italian fusion between the microelectronic branch of Thompson and the SGS Microelectronica in 1987. The Advanced R&D sites are the sites of Crolles – France and the site of Agrate – Italy. Additional R&D and fabrication sites are constructed in USA, France, Italy, Morocco, Malta, China, Malaysia, and Singapore. STM founded an alliance with Philips semiconductors and freescale (previous Motorola semiconductors) to develop new technologies and to set up worldwide development standards. A worldwide present is necessary to respond to worldwide customer needs as shown in the following picture:

187

Figure 90: STM sales figures, QI 2006

ST´s mission could be described as follows:

“To offer strategic independence to our partners worldwide, as a profitable and viable broad range semiconductor supplier.”

7.2 Organization Presentation: context of this work This work is based on the observation of working methods, of information sharing practices and of the participation and integration in industrial projects in different teams. There are different teams involved in the described conception process as described in section 2.3.1. :

Device and Yield Engineering (DYE) – industrial product improvement R&D Engineering – R&D technology development Area Engineering –Cleanroom engineering support Cleanroom – Production Computer aided Manufacturing (CAM)– IT support for cleanroom production

The mission of these groups can be described as follow: “Maximize performances and electrical yields for products fabricated at Crolles, guaranteeing high quality levels at an optimum cost. Provide the necessary support to our external and internal customers during the development and industrialization of new products.”

188

7.2.1 Device and Yield Engineering (DYE) - industrial product improvement

A DYE engineer is the technology platform owner and is in charge to industrialize technologies as well to improve products during its life cycle. He analyzes the changes in a final product, correct failures to improve the quality and the yield of the production. He takes the decision if a new fabrication method is used or not or which methods will be tested. The DYE team is organizationally subdivided by technologies (called “filière”) and a tandem of a process engineer and a device engineer work on a specific technology product and its fabrication process. Each “filière” has around 8 team members. The objective of their work is to support cleanroom’s production process and to improve the quality of technology fabrication process during technology’s life.

7.2.2 Area Engineering (Area) - Cleanroom engineering support The area team is in charge to support the production in the cleanroom. A lot manipulation is prepared by this team as they have the competence to change the machines conditions in the clean room. He creates the requested conditions by a DYE or R&D engineer to machine conditions (called fabrication recipes for a machine). Therefore, they configure machines, observe the lots produced and correct mistakes. They take the decision if a requested condition for a machine is realizable and validate these requests concerning cycle time, production dependencies between operations and capacity. The area team is subdivided in the areas, depending on the type of production (implantation, defectivity, metal, photo, engraving, etc…) Its engineers are specialized for a group of operations of an area’s machine type and are responsible to solve problems of the daily production as well as to configure the machines in the cleanroom with the new process conditions (temperature, duration, etc.)

7.2.3 R&D Engineering – R&D technology development A R&D engineer is the technology platform owner and is in charge to develop technologies. He analyzes the produced prototypes, correct failures to improve the quality and the yield of the prototypes to guarantee an industrializable technology. He takes the decision if a new fabrication method is used or not or which methods will be tested. R&D and DYE engineer have the similar daily work, but the concerned technologies are in different life cycle phases. (R&D at the beginning of the life cycle, DYE at the end of the lifecycle). The R&D is subdivided by technologies (called “R&D filière”) and each engineer works either on special functionality for new products or on a new technology fabrication process for a technology. The objective of their work is to support cleanroom’s production process for new technologies and to improve the quality of R&D technologies during its development phase.

7.2.4 Cleanroom – Production An operator in the cleanroom charges the lot in a machine and surveys its processing. Concerning the described experiment request for new fabrication process, he is in charge of processing the lot with the requested conditions and not to follow the standard fabrication

189

route under automation: meaning that he is in charge to configure manually how the lot will be processed be using the re-configured conditions (called recipes) by an area engineer. The cleanroom is organized like the area team. It is subdivided in the areas, depending on the type of production (implantation, defectivity, metal, engraving, …). Its operators are specialized for a group of operations of area’s machine types and are involved in the production by surveying, charging and de-charging machines. An operator works closely with the area engineers, but on different difficult levels (an operator start charge and decharge the lot in the machine, an area engineer controls the conditions and configuration of machines for the lot production)

7.2.5 Computer Aided Manufacturing – IT support for cleanroom production

A CAM engineer is a technician and is in charge to design, develop and support IT Tools supporting the fabrication activities. First of all, the Manufacturing Execution System (MES) that contains all the fabrication processes (routes, operation and recipes (operation conditions) and is connected to all machines in the cleanroom allowing processing the lot under automation. Secondly, he is in charge to develop and support IT tool supporting activities around the production process. The CAM is subdivided by different IT tools responsibilities The objective of their work is to support user requests about IT tools, improving the existing tools and capturing user need for evaluation or development of new IT products. 7.3 Characterization of Knowledge Management factors at STM Knowledge Management shouldn’t only be a support function to deliver a management method linked with a technology where management forces employees to use this technology to share knowledge. This might be work, but resistance of technologies is high and motivation to follow this method is low and information quality could also be low and not complete. Managers have to support Knowledge Management activities, but the engine of KM is the voluntary of each employee. An efficient Knowledge Management should take into account:

• Human • Technology • Organization

with regard to the environment of these aspects: employee’s culture. These four aspects are related. Changing one aspect may have an influence to another one.

190

In the following, these factors are characterized at STM context:

7.3.1 Organization The R&D centre in Crolles has a “classic hierarchical” organization structure with a lot of transversal projects. We use “classic hierarchical” in brackets because the organization has as described different departments with subdepartments and interactions between the different functional departments, but business processes require strong interaction between these departments, which gives birth to a parallel organization which is not documented in the classical organization charts. The advantage of this structure is that a lot of formal and informal interactions are built quicker and decisions can be done faster. On the other hand, a visibility of interactions and/or projects is not always guaranteed; especially the informal interactions aren’t visible for the company. It is difficult to identify a person with certain skills, and results from different projects aren’t stored in a common data base. Transversal projects working on similar technologies or issues my therefore duplicate efforts or even reiterate mistakes done previously. Another consequence is that employees are involved in different projects, the visibility isn’t even guaranteed for employees and the management. Departments, especially their managers, have to deal with multi-projects and multi-resource prioring management, without having the required overall visibility. In addition, due to the rapidly changing business environment, priorities are subject to frequent changes, which makes their management even more difficult. A lot of different small teams with 8-10 members exist. As there is no visibility of the competence of other teams and/or due to other teams are computing priorities, teams have to do action, initially dedicated to other teams, of their own. A new organizational aspect is the alliance with Freescale and Philips, called “Crolles2alliance”, to share knowledge and set up a fabrication standard for future technologies. Information sharing, in particular access rights management, is an important factor in this context of the alliance between different companies.

Figure 91: KM is based on human, technology and organization [Studer, 2003]

191

7.3.2 Technology IT Infrastructure at Crolles is constrained by investment cost considerations. While core business applications benefit from good infrastructures, non-critical applications run often on servers with a less performance. This is considered as a critical fact by users. On the other hand, teams need more often tools to support their work becoming more and more complex. This is why a lot of tools are developed or are bought for the teams. The use of the tool is often limited on one team and transversal activities are often not supported: Each team has a specific action to do and to define the interfaces with other teams involved in the transversal workflow. As the action is very specific, specific tools are needed to support team activities. Interfaces between teams are made by e-mail, but there is often no tool supporting team activities over organizational barriers. Tools dedicated on the business activities have special characteristics and there aren’t a lot of market leader, so choosing a tool for microelectronic technical activities is probably easier than choosing a tool for information management, in particular as there are a lot of different tools and investments on such tools is restricted. Another fact is that each interaction between team could be different and isn’t formalized yet. Additionally, the user’s need-analysis-phase doesn’t often take place or stops after capturing a first impression of user needs. This is why tools respond sometimes to a management need but not the user need. Technologies are often set up for one team, but often with no regard to other team. That means that technology is set up for one team, but this technology doesn’t support teams interaction. STM use MS Outlook as e-mail-program. Furthermore, as business constraints exist concerning the treatment of a lot, some decisions have to give quickly a ruling. ST has set up an intern mobile phone system. Each employee is reachable at every time everywhere in the company.

7.3.3 Human factor A lot of technologies are set up (as described in section 2.2.2) and impact the human behavior, in particular their work method with IT technology. The facts that a lot of different tools are set up and humans are overloaded, humans are also resistant to new technology, because they think that they have no time to habituate on technologies. Additionally, the classic “resistance factors” like age and habituates exist also. Even, if there are activities on Knowledge Sharing (KS) as described in chapter 2.3, these are always coupled with IT. The resistances against IT and the fact that KS don’t often give an immediate personal return, KS activities aren’t their priorities. The information used to build knowledge is often not accessible to others because it is stored on personal email programs or on the personal computer. The final information is often stored on the shared network file server, but there are no qualified methods to retrieve information. That means that people have to know where to search for information initially stored. People have to remember where and what information they stored. Generally, formalized knowledge sharing is not a well developed aspect of Crolles’ culture. Knowledge sharing is informal and implicit – over the mobile phone – because it is the fastest way to get or validate information. Employees call different colleagues to validate the correctness of information or to get some additional explanations. People get this information from the personal network they built over the years, but it is difficult for them to find an expert to get an answer to a specific question. Additionally, as the alliance with Freescale and NXP is set up in the last years, increasingly, employees from ST

192

are transferred to the alliance. As they are still physically present at Crolles and therefore joinable, previous colleagues continue to call them to ask for information. In this case, the transferred people are responsible to decide whether they have still the rights to transfer knowledge or not. Based on human relations, there is still a trend to call employees even when these “experts” has changed their jobs and they are no longer in the same domain.

7.3.4 Culture The three described factors influence the Crolles culture: Prioritiesare subject to frequent changes; knowledge sharing is often based on implicit synchronic localized knowledge exchange (i.e. over the mobile phone). So, activities are often informal and not visible for the whole company. As employees discuss often over the phone, information could be transferred quicker to someone else (as they have the possibility to discuss aspects in a synchronic exchange). The disadvantage is that this knowledge is a personal interpretation from a person based on informal information, so employees call 2 or 3 colleagues to confirm the information. On the other hand, official information (like analysis, preliminary or final presentations) is sent by email to users. As there is no method or tool to structure and support the information flow, these results are emailed to a lot of different people who aren’t probably concerned about this problem, not even interested to follow up the evolution. People are faced on an information overflow that they can’t manage or influence because information is pushed to them by e-mail. Certainly, they could define filters on the email program, but the best effective filter is the human analysis: Actually, the way to handle information is to select information by filtering concerning the subject and the sender of an email or the persons who calls. Information with unknown senders that don’t have a significant title, aren’t probably read. A lot of “formalized” documents are simple analysis graphs or presentations with graphics, photos or tables, understandable only for domain’s expert. For this case, each team or employee do have to take the decision of the grad of details for his reports to know for whom the reports might be interesting. Domain experts can interpret analysis results, but flavored people mightn’t be possible to understand. Formalization takes time and reports are often only exist in this “brief version” with few commentaries, but a lot of visual elements in a PowerPoint-presentation. Additionally, over the years, a Crolles vocabulary is built that is understandable for old employees, but new employees have integration problems. Actually, there aren’t strong commitments to formalize and explain this vocabulary.

193

7.4 Handling of Dynamic Business Processes Today, more and more processes are executed in parallel (concurrent engineering). For each action in a process, specific information will be needed and produced. Enterprises in a concurrent engineering are confronted to a changing environment where the defined processes are re-designed permanently. Grigori [Grigori et al., 2000] wrote about the objective of business process management that “the goal is to reconciliate the need of freedom required by users during the execution of a process and the need of control of project managers that are accountable for the correct execution of the process”. This goal is valid for simple administration process, ad hoc or collaborative as well as for complex interactive production processes. Therefore, it is primordial to analyze the requirements of the process managers and process actors in order to identify and cover a maximum of functionalities and process execution possibilities of the real executed processes. Within business process management research, many publications emphasize the importance of flexible business process modeling and enactment. Unfortunately, concrete solution approaches to the above problems are rarely described [Douglas et al., 1995], [Deiters et al., 1995], [Florijn et al., 1996], [Jablonski, 1994], [Oberweis, 1994], and lack an integration of dependency management mechanisms. The handling of dynamics in process management is still an unsolved problem, but it exist already lot of projects dealing with these aspects as the projects ADEPTFlex [Reichert et al., 1998], Chautauqua [Maltzahn, 1997], WASA [Rinderle et al., 2004] and WIDE [Casati et al., 1998].

194

7.5 The KDML language The experiment-processes could be modeled as already shown in section 3.7.3 via the Knowledge Description Modeling Language (KDML) [Gronau, 2004]:

Figure 92: Knowledge flow in processes

This figure could be interpreted supported by the following legend:

Figure 93: Legend of the KDML language

The KDML language can help to formalize the knowledge flow in process. At the same time, it can help to reveal knowledge flow problems by describing where knowledge is needed and where it exists already. Responsibilities, competence and positions of involved employees is formalized and could be used to improve the situation.

195

7.6 Knowledge Management models In this work, the new generation of Knowledge Management approaches was explained (cf. 3.2.1.4) and the critics according some authors [Reinhardt, 2004], [Snowden, 2002] on current Knowledge Management models is explained. It is criticized that KM models are often only linear and don’t reflect the dynamism of knowledge changes. A non-exhaustive list of Knowledge Management models was already established by [Frank, 2003]. This list shows the different phases in a KM model. All models are linear transitions between the phases and even if cycles exist in the model, the changes of the knowledge nature aren’t represented in these models. Frank’s list is presented in the following table:

Figure 94: Comparison of Knowledge Management Models according [Frank, 2003]

196

7.7 SWR process flow The following picture represents a more convivial synthesis of the formalized SWR process through PIFA. This picture was used in trainings and meetings:

Figure 95: SWR process at STM in Crolles at advanced R&D

197

7.8 Use cases

Define experiment, split matrix, and involved actors

Acess to an action

Read-only (if not owner)

Initiate process define Split matrix

attribute lots

prepare instruction

Control instruction

store comments about lot execution

Modify (if owner)Actor

Keyword search

experimet search (DYE)

recipes search (area)

Knowledge retrieval

experiment follow-up

Experiment analysis

notify actors

Figure 96: Actor's use cases

The actor use cases are presented in the figure above. An actor could initiate a process, access to an action in a process or use knowledge retrieval functionalities. To initiate a process, he has to define global information about the experiment and detailed information about the experiment as the Split Matrix and involved actors (assign actions to an actor). Ac actor that access to an action can modify the information of an action if he is the assigned owner of this action (define, modify the split matrix, attribute lots to an experiment, prepare instructions, control the instruction, store comments about lot execution or do the experiment analysis and notify involved actors about experiment results. If an actor use the knowledge retrieval functionalities, he could use a keyword search, a advanced search about lot, technologies (DYE search) or an advanced search about machines, recipes (Area search).

198

Define and manage groupe

manage data structures (modifyontology)Administrator

create, modify, delete action

create, modify, delete edges

define and modify experiment process model

configure used information component for each action

Figure 97: Administrator’s use cases

An administrator of the system can define and manage a group of actors, manage data structures (create, modify, delete categories and values (maintain the process domain ontology) and define and modify the generic process model used for the creation of instances for the experiment processes. To define or modify a process model, the administrator has to create, modify or delete an action; create, modify or delete edges between action to establish a process flow and to configure used information components for each action (configure the information that will be displayed for each action).

199

7.9 Additional screenshots of EMA For all treated lots, a return about measurement or split experiment will be entered by an operator who split the lot and executed the experiment (non-standard lot fabrication). For each lot, he can type comments about problems, observations, etc. Furthermore, he can store documents about measurements. A text form “Measurement Conclusion” will request a synthesis of the measurement results. The stored documents through this action form will therefore be annotated with the conclusion annotation, as well as all completed annotation in this process (i.e., cf. action A1 & A2, operation number, lot number, technology, etc). For screenshots of this action form, please refer to appendix.

Figure 98: Action A5: Experiment Lot Treatment for a prepared instruction

200

Figure 99: Main menu of EMA

In the figure above, the main menu of EMA is illustrated. Shortcut link guide the user to the different navigation spaces within the application. The main navigation menu is structured in 4 parts: EMA, Process, Reporting/Search and Administration. The process and Reporting/Search functionalities was explained in chapter 5. The EMA menu offers the personal space of a user like “My action list”, “my groups”, etc. An example of my action list is illustrated in the following figure:

Figure 100: Example for My action List in EMA

However, the access of operators in the cleanroom is different. They aren’t interested in knowing the number attributed to the experiment. In the production line environment, the

201

number of lot an the split operation is more important. Therefore, a different access exists: by lot and operation as illustrated in the following figure:

Figure 101: Access to Split instructions via lot number and operation for the cleanroom

In the figure above, an operator can access to a PDF document and print it to put it physically on the lot box.

202

7.10 Additional Statistics of EMA

Figure 102: Daily usage statistic of EMA

Figure 103: Hourly usage statistic of EMA

203

8 Summary in FRENCH: Vers la réutilisation des connaissances dans les processus d’industrialisation: le cas de la microélectronique

Résumé : L’industrie microélectronique fait face aujourd’hui à des défis considérables pour renouveler ses gammes de produits et fiabiliser les rendements de sa production. À ce titre, les essais de nouveaux processus de fabrication sont incontournables compte tenu de la sensibilité des procédés utilisés. Les connaissances issues des essais constituent donc de précieux éléments de productivité. Or, la gestion des connaissances et des processus d’essais eux-mêmes pêche par son absence de formalisme. En particulier, un retour d’expérience des essais, un échange entre des processus et une capitalisation des connaissances dans le temps pour initier une réutilisation ultérieure sont des facteurs primordiaux de succès pour augmenter la productivité des essais, mais sont souvent mal compris et peu soutenus : la gestion d’information n’est pas intégrée dans la gestion des essais et par conséquent une réutilisation de l’existant ainsi qu’une centralisation des informations pour un processus d’essai est difficilement possible. Cette thèse propose une nouvelle méthode d’analyse, appelée PIFA (Processus, Information, Fonctionnalité, Analyse), pour analyser et combiner les besoins de la gestion de connaissances et de processus dans le but de l’optimiser. Cette méthode se compose de trois parties : La partie Processus aide à capturer les dépendances entre des actions. La partie Information permet de détecter et d’améliorer le flux d’information intra et inter processus. Enfin, la partie Fonctionnalité analyse le besoin des acteurs impliqués et garantit qu’ils aient une valeur ajoutée immédiate. Ceci facilite la conduite des changements causés par l’introduction d’une nouvelle méthode de travail, comme par exemple une capitalisation plus élevée de l'information. Dans ce travail, l'approche PIFA a été appliquée aux processus d'essais chez STMicroelectronics. Basé sur ses résultats, un outil informatique (EMA – Experiment Management Application) a été conçu afin de soutenir et optimiser l'exécution de ces processus : capitaliser les connaissances produites pendant l'exécution et initier ses réutilisations. Après une phase d’essai, l'outil a été déployé en juin 2006, il est actuellement utilisé par 300 employés.

Mots-clés : Management de connaissances, gestion de processus, conduite de changement, recherche d’information

204

8.1 Introduction Notre société a changé d'une société industrielle en être une société d'information. La connaissance est devenue la ressource économique principale, comme Drucker précise :

« La ressource économique de base - les moyens de production - n'est plus la capital, ni les ressources naturelles, ni du travail. C'est et sera la connaissance. » [Drucker, 1993]

En particulier dans le domaine de semi-conducteur, un environnement en cours d'évolution et très rapide, où les produits changent et pourraient rapidement devenir obsolètes, la ressource « connaissances » joue un rôle très important : Le pourcentage de la matière première classique diminue de plus en plus par rapport à l’importance de la connaissance utilisée comme ressource pour la production. Selon Bullinger [Bullinger, 2004], les coûts de production dans le domaine microélectronique sont corrélés avec la ressource « connaissances » jusqu'à 70 % (en raison des activités de R&D), comparé à 12% au facteur classique « main d'œuvre ». La connaissance est basée sur l'information.

En outre, la gestion de processus industriel et son soutien par des outils de « workflow » sont devenus de plus en plus importants. Pendant l'exécution des processus, la connaissance est produite et utilisée afin de produire un produit ou un service final. Des processus sont exécutés en parallèle. Ces processus parallèles pourraient profiter des approches de gestion de connaissances afin de partager et réutiliser les connaissances produites lors de leurs exécutions. Par conséquent, cette thèse combine les aspects de la gestion de connaissances et des processus industriels selon les caractéristiques du domaine microélectronique. Le processus d’essai (Special Work Request - SWR) chez STMicroelectronics (STM) est analysé et ses problèmes de gestion de connaissances reliés sont formalisés. Le but de ce travail est la réutilisation des connaissances produites pendant l'exécution de ces processus d’essais. Par conséquent, une analyse plus profonde de concepts existantes de gestion des connaissances, aussi bien qu'à des pratiques existants de contrôle de processus industriel et la combinaison de ces deux domaines est effectuée. Cet état de l’art des concepts existants ainsi que les problèmes de gestion de connaissances détectés ont permis de développer une approche d'analyse (PIFA – Process Information Functionality Analysis) pour formaliser les les besoins des activités des connaissances et de processus afin de les soutenir et les optimiser. L'application de cette analyse aux processus d’essais (SWR) chez STM a permis la formalisation des aspects nécessaires de concevoir un outil informatique (EMA – Experiment Management Application) soutenant le processus d'essai et ses connaissances liées chez STMicroelectronics. Cet outil a été mis en application et est actuellement utilisé par 300 employés depuis juin 2006 (4 mois). Cette application a permis de détecter et d’avoir un retour pour l'amélioration de PIFA.

205

8.2 L’analyse du contexte

8.2.1 L’ingénierie simultanée dans le domaine microélectronique : plus coopératif que collaboratif

Dans le domaine des technologies microélectroniques, le progrès technologique est rythmé par l’apparition tous les 2 ans de composants élémentaires en moyenne 30% plus petits que ceux de la génération précédente, pour une même fonctionnalité : La longueur électrique du transistor (la taille de la grille) est ainsi passé de 0,18 µm à 0,12 µm, puis à 90 nm, en arrivant à 65 nm pour la génération développée en parallèle pour exploiter ces capacités croissantes d’intégration.

Les produits deviennent de plus en plus complexes et nécessitent d’intégrer sur une même puce des fonctions de plus en plus diversifiées, faisant appel à des options de conception et de fabrication toujours plus nombreuses. Cette complexité allonge la durée de développement, de ce qu’on appelle la plateforme technologique, qui comprend pour une génération donnée la méthode de fabrication des composants de cette génération et les outils de conception. Malgré les nouvelles capacités de fabrication le cycle de mise sur le marché s’en trouve donc rallongé. Or, le rythme d’innovation dans l’industrie du semi-conducteur correspond au développement d’une nouvelle technologie tous les 2 ans. Un nouveau processus de développement d’une plateforme technologique est donc lancé tous les 2 ans. Cependant la conception d’une technologie prend de plus en plus de temps : une technologie N+1 est déjà lancée, alors que la technologie N n’est pas encore finalisée. Pour limiter cette dérive des délais, deux aspects primordiaux ont évolué ces dernières années :

• D’une ingénierie séquentielle vers une ingénierie simultanée

• Engagement vers une compression du temps de développement

Figure 104: Ingénierie concurrentielle dans le processus de développement des circuits intégrés

Les développements d’une plateforme technologique sont lancés à des séquences plus en plus rapprochées. Actuellement elles sont développées en parallèle avec un décalage de 2 ans. Chaque génération de technologie a son responsable et les générations sont indépendantes et séparées organisationnellement: les problèmes rencontrés lors d’un développement peuvent concerner plusieurs technologies et ainsi apporter une amélioration dont devrait pouvoir être bénéficiée les autres générations. Dans un cadre d’ingénierie simultanée, que nous comprenons comme une méthode pour raccourcir le cycle d’ingénierie par la gestion de

206

processus en parallèle à la place d’une gestion séquentielle, nous avons l’intention d’améliorer l’échange d’informations entre différentes générations en cours, notamment pour permettre à chaque génération de profiter des expériences sur les essais des autres générations.

8.2.2 Le processus industriel de control de conception: Special Work Request (SWR)

La thèse a été effectuée en collaboration avec l’entreprise STMicroelectronics dans l’objectif d’améliorer la gestion de connaissances. Dans un marché très concurrentiel, les entreprises du secteur microélectronique doivent sans cesse évoluer afin de livrer au client un produit de la meilleure qualité possible, dans les meilleurs délais et au meilleur prix. C’est pourquoi un des spécificités du domaine microélectronique est que des idées théoriques de conception sont immédiatement testées par un essai. Par conséquent, une demande d'essai sera écrite et un lot de 25 plaques de silicium sera pris en cours de fabrication. Il sera consacré à tester et examiner les nouvelles conditions de fabrication spécifiées dans la demande d’essai. Le processus de fabrication des lots est structuré dans différentes opérations qui doivent être exécutées pour produire le produit final. La demande d’un essai de processus de fabrication s'appelle une demande spéciale de travail (SWR – Special Work Request). Une fois que les personnes impliquées ont discuté et ont validé leurs idées (lors des échanges formels et informels comme les réunions, l'email, les présentations, etc.), elles déterminent les conditions de processus de fabrication qui seront testées sur les machines. Aucune formalisation du processus de SWR n'existe. Il semble que le processus soit un processus très court avec seulement quelques actions ; et donc aucune formalisation ne semble être nécessaire. L’exécution de processus peut être considérée comme connaissance implicite partagée. Des entretiens ont été menés avec les acteurs du processus pour le formaliser et pour comprendre la responsabilité de chacun. Cinq ingénieurs, initiateurs du processus de SWR, ont été interviewés. L'analyse a montré que la demande d'essai produit un document de SWR. Ensuite, chaque opération de l'essai est exécutée dans des conditions spécifiées dans le document SWR. À chaque opération demandée correspond une manipulation du processus de fabrication. Des résultats intermédiaires, tels que des mesures, sont produits et notés dans des documents de résultats. Enfin l'essai est analysé. Le résultat de cette analyse est stocké dans le document de SWR.

Figure 105: Special Work Request (SWR) - processus d’essai

4. Action: Demande d’essai document: document de demande SWR 5. Action: Exécution d’essai document: results documents 6. Action: Analyse d’essai document: document SWR final

207

La première analyse du processus a montré qu’il est articulé autour de trois actions principales. Comme le processus d'essai est lié à la production, il pourrait donc être modifié selon les problèmes rencontrés. Le processus ou certaines actions devraient donc être ré-exécutés, suivant la figure ci-dessus. Par conséquent,

L’enchaînement des actions, La durée d’un processus, Le nombre d’opérations concernées et Le nombre d’employés impliqués

peuvent changer pendant l'exécution du processus. Le flux de processus dépend des résultats intermédiaires obtenus et du processus de production lié. Ces essais pourraient être considérés comme processus flexible et dynamiques qui doivent être adaptés aux environnements locaux et dynamiques. Néanmoins, le processus d'essai peut être considéré aussi comme linéaire parce que les actions du flux sont toujours les mêmes, seuls leurs enchaînement peuvent différer. Le processus SWR illustré explique la relation entre la conception et la production. Ces processus d’essai pourraient être lancés par un service de « R&D » ou un département de « rendement d’ingénierie» responsable d’amélioration des produits industrialisés. Un ingénieur de la production configure et prépare les machines pour l'essai et un opérateur en salle blanche exécute l’essai.

8.2.3 Analyse de problèmes, besoins et des solutions existantes Différents outils sont utilisés pour la gestion d'essai et son exécution. Actuellement, il n'y a aucun lien entre ces applications. Il est donc très difficile de mettre à jour, les données de ces différentes applications, certaines données sont donc périmées. Souvent les processus d’essais sont en retard car ces données ne sont pas mises à jour régulièrement. A cela s’ajoute le problème de la redondance d'information : pendant que chacun est informé des prochains essais par email avec un document joint, le même document est utilisé comme base de travail quotidien et il évolue en conséquence. Par conséquent, différentes versions des documents existent et circulent entre les personnes impliquées. Le chef de l’essai est responsable d'analyser les différentes versions et d'extraire une version valide. Parce qu’il n'y a aucune structuration de l'information ou du processus, chaque acteur décide seul d’utiliser la version du document de son choix ce qui peut entraîner des échecs ou des problèmes souvent identifiés qu’à la fin d'un processus. Cependant, beaucoup de fonctions pourraient être améliorées et soutenues par de meilleures fonctionnalités supportées par la technologie d’information.

8.2.4 L’objective de travail Le but d'une méthode d'échange dans ce contexte est d'améliorer la diffusion des connaissances produites qui ne sont actuellement pas partagés avec d'autres équipes d'essai au sein de la même compagnie. Cette connaissance n’est à ce jour pas partagée, car elle n’est pas considérée comme importante comparée aux problèmes quotidiens de fabrication et de gestion de crise. Cette connaissance est plus qualitative que quantitative. Actuellement, seuls les résultats positifs d'une modification dans le processus de fabrication sont communiqués ; aucune communication n’est faite sur les résultats négatives et intermédiaires. Ce travail

208

présenté se concentre sur le partage de l’ensemble des résultats : positifs, négatifs et intermédiaires.

8.3 L’acquisition de littérature

8.3.1 Le management des connaissances : concepts et définitions Les organisations focalisent de plus en plus sur la gestion de connaissances. Cependant, de différentes définitions et interprétations de la gestion de connaissances existent. Dans ce travail, nous définissons, basé sur la définition de Jaime [Jaime, 2006], la connaissance comme « un objet immatérielle qui est une compréhension temporellement stabilisée résultant des interprétations d'information, d'expérience humaine et de réflexions basées sur un ensemble de croyance dans un contexte spécifique ». La formalisation de cet objet immatérielle devient l'information sous une forme matérielle qui pourrait être réutilisée pour accumuler et construire la connaissance initiale. Par conséquent, la notion de « l’objet de connaissance » est utilisée pour se rapporter à ces caractéristiques. Cependant, les notions de connaissance implicite et explicite sont souvent utilisées dans ce contexte. La connaissance implicite réside à l'intérieur des humains. La connaissance explicite est la connaissance implicite formalisée.

La « gestion de la connaissance peut se référer de la manière que les organismes recueillent, contrôlent, et emploient la connaissance qu'ils acquièrent. La notion indique également une approche pour améliorer des résultats d'organisation et étude d'organisation en présentant dans une organisation une gamme des procédés et des pratiques spécifiques pour identifier et capturer la connaissance, le savoir-faire, l’expertise et tout autre capital intellectuel. Ceci se fait dans l’objectif de rendre de tels capitaux de la connaissance disponibles pour une diffusion et une réutilisation à travers l'organisation. » [Wikipedia, 2006b]. Basé sur ces définitions données, les activités de gestion de connaissances devraient aider à capturer et diffuser la connaissance existante afin de tenir l'information à jour et optimiser son réutilisation. Par conséquent, la création, la diffusion et la réutilisation sont des activités transversales intégrées dans les activités et les décisions quotidiennes du travail des employées. La gestion de connaissances a gagné dans la popularité ces dernières années, mais des modèles concrets d'application manquent toujours. Des approches d'exécution de la gestion de connaissances sont souvent concentrées sur la capitalisation de la connaissance produite et fournissent des outils afin de garder la connaissance dans le temps.

Cependant, la connaissance n'est pas une discipline autonome. Elle est produite pendant le travail quotidien et des méthodes de capitalisation devraient donc également être intégrées et liées aux activités quotidiennes de travail.

La connaissance est également consommée dans le travail quotidien. Par conséquent, une distinction entre

« la connaissance nécessaire et désiré»

209

semble être nécessaire. La connaissance nécessaire est la connaissance qui est immédiatement utilisée et consommée pendant des activités quotidiennes de travail, c.-à-d. dans le même processus. Par conséquent, la connaissance nécessaire est déjà partagée (même si les méthodes partagées ne sont pas optimales et pourraient être améliorées). La connaissance désirée pourrait améliorer les activités en réutilisant la connaissance existante, par exemple pour l'éviter de faire les mêmes erreurs à nouveau ou pour réduire la durée de temps de cycle. Les activités de gestion de connaissances devraient particulièrement se concentrer sur le partage de la connaissance désirée. Comme elle n'est pas nécessaire pour des activités quotidiennes de travail, le partage est souvent bloqué par les barrières organisationnelles, notamment par des problèmes d’absence d'accès et d'internalisation. Mais cette connaissance désirée présente une valeur ajoutée par son mise en œuvre. En outre, des activités de capitalisation de la connaissance devraient être concentrées sur ces besoins de la connaissance désirée.

Par conséquent, les notions de la connaissance individuelle et la connaissance collective sont employées fréquemment. Le but est donc de profiter de la connaissance et de la répandre à travers des barrières organisationnelles. Ce type de connaissance ou plutôt le processus de partage s'appelle « la mémoire d'organisation ».

Il est difficile de déployer une nouvelle méthode de travail contenant des aspects de gestion de connaissances sans aucun appui à cause de résistance des utilisateurs. Par conséquent, il pourrait être utile de déployer une nouvelle méthodologie supportée par des outils informatiques. Cependant, une résistance des utilisateurs existe et devrait être anticipée et prise en compte pour le déploiement. La source de connaissance est humaine, et tandis que la connaissance est un avantage concurrentiel pour la compagnie, elle est également un avantage personnel pour un humain au sein d’une équipe, pour des équipes au sein des projets transversaux, etc.

La connaissance peut être considérée comme la « puissance » et elle peut être une puissance personnelle ou la puissance d'une compagnie. Cependant, un individu ne va toujours pas se concentrer sur le gain de la compagnie, mais sur ses intérêts personnels. Un individu sera moins concentré sur la maximisation de bénéfice de l'entreprise que sur des objectifs personnels.

En outre, l'utilisation des activités de gestion de connaissances supportées par l’IT ne peut pas être complètement anticipée, car l’IT offre des possibilités diverses de partage d’information. Par conséquent, le changement devrait être accompagné et la stratégie de gestion de changement doit être adaptée aux changements imprévus, à la résistance des utilisateurs et à d'autres problèmes afin de garantir le succès du déploiement de la nouvelle méthodologie de travail. L'objectif le plus important est de détecter comment le flux de connaissances pourrait être intégré dans des activités quotidiennes de travail. Wunram [Wunram et autres., 2002] indiquait que « les approches qui commencent par le but de capitaliser toutes connaissances des employés sont prédéterminées pour échouer, » car uniquement la connaissance est capitalisée et mise à disposition, mais aucune réutilisation n’est initiée. La connaissance construite dans une mémoire d'organisation est donc tout inutile si elle est ni accessible et ni internalisable.

210

La capitalisation de la connaissance et de son contexte associé pourront être soutenue par des ontologies. Les ontologies ont été exploitées en informatique pour augmenter le partage de la connaissance et sa réutilisation [Gruber, 1995], [Fensel et autres., 2002]. Premièrement, ils fournissent une compréhension partagée et commune de la connaissance dans un domaine d'intérêt. Deuxièmement, ils capturent et formalisent la connaissance en reliant la compréhension humaine des symboles au traitement par des machine. De cette façon, les ontologies agissent en tant que langage commun entre les agents (humain-humain, homme-machine, machine-machine). La construction d'une ontologie représente une formalisation d'un vocabulaire spécifique pour un domaine (groupe de symboles) où chaque symbole est associé à une référence significative (concept) et interprétable par un humain pour associer le symbole à un objet dans le monde réel. Haase [Haase et autres., 2004] écrit, « Ontologies rendent la connaissance implicite explicite, ils décrivent les parties pertinents du monde et les rendent compréhensible et traitable par des machines». Néanmoins, le besoin de connaissances reste la source de succès pour une initiation d’une réutilisation de connaissances.

Dans ce travail, la connaissance analysée est liée aux processus d'essai. Des employés sont impliqués dans différents processus et leur travail quotidien représente des activités dans ces processus. Par conséquent, la source de production des connaissances est le processus d’essai. Afin d'appliquer la gestion de connaissances à ce contexte, une réflexion théorique plus profonde de ces processus est exigée. Par conséquent, des aspects de gestion de processus industriel et des solutions courantes pour appliquer la gestion de connaissances à la gestion de processus industriel sont discutés dans les sections suivantes.

8.3.2 Les concepts de gestion de processus industriels Les organismes automatisent de plus en plus leurs opérations industrielles. Tels processus sont typiques pour une longue durée, impliquent la coordination à travers des beaucoup d’actions manuelles et automatisées. De plus, ils exigent l'accès à plusieurs différentes bases de données et l'installation de plusieurs systèmes d'application. Un processus industriel typique peut se composer de beaucoup de différentes transactions. La coordination du processus entier et efficace demande des outils informatiques.

« Un processus industriel est un procédé où des documents ou l'information sont échangés entre les participants selon les ensembles de règles définis pour réaliser, ou contribuer à un but global industriel. Un processus industriel est représenté par un nom, un nombre de version, des conditions de début et d'arrêt et des données additionnelles pour la sécurité, audite et commande. Un processus se compose des activités et des données appropriées. Chaque étape dans un processus est une activité, qui a un nom, un type, pré- et des post-conditions, des contraintes d’exécution et un rôle. Le rôle détermine qui exécutera l'activité. » [Hollinsworth, 1994].

« Un système de gestion de processus industriel est une collection d'activités organisées pour accomplir un processus industriel. Une activité peut être accomplie par un ou plusieurs systèmes logiciels, un humain ou une équipe d'humains, ou une combinaison de ces derniers. Les activités humaines nécessitent une interaction forte avec des ordinateurs. Un processus se

211

compose comme ordre prédéfini des activités. Chaque activité est assignée à un rôle. Un rôle peut être assigné à un groupe de personnes ou à seulement une personne » [Georgakopoulos et autres, 1995].

La notion de « gestion de processus industriel » est parfois divisée dans le domaine d'analyste, également connue sous le nom de « re-engineering », et le domaine d'application, la gestion du processus industriel soutenue par un outil informatique, également connu comme outil de « workflow ».

Dans ce travail, la notion « gestion de processus industriel » couvre le domaine entier des processus industriel, y compris « la partie théorétique et stratégique » de l’analyse de processus et la gestion d’exécution des processus.

[Zhao, 1998] décrit quatre perspectives des systèmes de processus industriel : fonctionnel (processus, actions), comportemental (règles, environnement), organisationnel (responsabilités, rôles), informationnelle (documents, information). Ces quatre perspectives aident à distinguer les différents parties d'un système de gestion de processus industriel afin de mieux analyser et/ou formaliser ces différents domaines liés au processus. Néanmoins, les systèmes de gestion de processus industriel utilisent généralement les modèles qui sont basés sur l’action comme centre. La base d'un tel système est l'action liée aux humains, au processus et à l'information produite. Beaucoup de compagnies ont des processus industriel qui sont uniques à leur propre modèle industriel. Puisque ces processus tendent à évoluer avec le temps, la solution de gestion de processus utilisée doit être facilement adaptable à de nouvelles conditions. En outre, un modèle de processus industriel est également spécifique au contexte et doit probablement respecter des conditions locales des processus industriels même si le processus industriel est globalement défini pour la compagnie entière. Par conséquent, les processus au sein de la même compagnie pourraient être différents. Il y a beaucoup de paramètres impliqués dans un processus industriel. Une taxonomie largement admise [Alonso et autres., 1997] distingue les processus administratifs (structure simple), ad hoc (spontané), de collaboration (beaucoup d'acteurs impliqués), et de production (structure complexe et beaucoup de différents systèmes hétérogènes). Cette classification est souvent basée sur la similitude qui existe entre différents processus. Une autre manière d'organiser et comparer des processus est également selon leur complexité et leur structure.

8.3.3 Les aspects de connaissance actuellement intégrés dans la gestion de processus industriels

Les différentes approches existent déjà pour combiner la gestion de connaissance avec la gestion de processus industriel. [Mata et al., 1999] a déjà mentionné que la connaissance produite pendant l'exécution du processus industriel représente la mémoire d'organisation.

En outre, des méthodes existent pour modeler le flux de connaissances dans le processus industriel. Le KDML (Knowledge Description Modeling Language) [Gronau et autres., 2004]

212

permet de modeler le flux, le besoin et la production de la connaissance pendant les processus.

Cependant, bien que différentes approches existent, elles répondent uniquement au besoin d’analyser et gérer la connaissance nécessaire à l’exécution des processus. Par contre, des connaissances désirées pour améliorer la qualité du travail, mais non indispensable à léxécution des processus, ne sont souvent pas partagés entre les différents processus. Par conséquent, la problématique pourrait être formalisée comme suit:

Comment les activités de création des connaissances liées au processus industriel peuvent-elles être analysées avec le but de soutenir et mettre en application la capitalisation des

connaissances « en temps réel » dans des processus industriel ?

Comment mettre en application et améliorer des activités de création des connaissances qui se concentrent particulièrement sur le maintien de la connaissance produite dans le temps et sur l’initiation d’un partage des connaissances à travers des barrières organisationnelles et de

processus?

Afin de répondre à cette problématique, l’approche de PIFA (Process Information Functionality Analysis) a été développée, basée sur la gestion de processus industriel et de connaissances et le contexte des processus d'essai décrit précédemment.

8.4 L’approche PIFA – une méthodologie d’analyse

8.4.1 Les différents entités de PIFA Notre méthode, PIFA, a été développée pour permettre dánalyser une action selon trois étapes :

Formaliser un processus auquel láction appartient

Capter le flux dínformation de ce processus

Analyser les fonctionnalités exécutées lors cette action

Ces trois étapes permettent la formalisation de l'information nécessaire et désirée pour exécuter une action. La base de l'analyse est donc l'action d'un processus, qui pourrait inclure différentes fonctionnalités :

213

Figure 104: Principe d’analyse PIFA [Busch et al., 2006b]

Les processus sont des exécutions structurées des actions. Une action (cercle central dans le schéma ci-dessus) peut être exécutée si toutes les conditions d'ouverture (oc) sont remplies. Ces conditions sont distinguées parmi les conditions de flux de travail « workflow » (w) et d'information (i). L'information pourrait être transférée sous forme explicite (expl.) ou implicite (impl.). Une fois toutes les conditions remplies, l'action peut être exécutée par une personne ayant la compétence pour exécuter les fonctionnalités associées à l’action. Après exécution de l'action, le processus continue et l'information produite (implicite ou explicite) est envoyée à une personne ou stockée dans un outil. Ceci est considéré comme conditions de fermeture (fc).

Chaque action est composée des trois parties suivantes :

• Input (flux entrants) : (condition d’ouverture pour une action) : Toutes les dépendances des actions précédentes et toute l'information nécessaire pour démarrer l’exécution d’une action sont identifiées, ainsi que son format et sa source. La source de cette information peut être humaine ou un outil informatique. Elle est transférée d'une manière explicite ou implicite par des fonctionnalités « Push » ou « Pull ».

• Fonctionnalités : les fonctionnalités nécessaires pour exécuter une action sont basées sur l'information et sur des règles du domaine. Pour chaque action, un groupe de personnes est identifié qui a la compétence pour exécuter l'action concernée. Ce groupe sera caractérisé par un nom aussi bien que par un rôle qui relie l'action analysée avec une personne ou un groupe de personnes.

• Output (flux sortants) : représente l'information produite pendant l'exécution d'une action : des actions suivantes dépendent des résultats. De plus, toute l'information produite est identifiée par son destinataire et son lieu de stockage. Par conséquent, la relation entre les actions est formalisée ainsi que le flux d’information entre des actions.

214

Cette caractérisation est expliquée plus en détail dans la figure 3 qui propose l'approche de PIFA d'une manière complémentaire et plus détaillée que le schéma 2 :

Figure 107: PIFA Template – Process Information and Functionality Analysis [Busch et al., 2006a], [Busch et al., 2006c]

Ces trois parties décrites sont le cœur de chaque action qui compose un processus. En appliquant PIFA, il est également important de prendre en compte deux aspects supplémentaires :

il pourrait être utile de créer un flux d’information vers des actions antérieures pour créer un retour d'expérience (REX) destinés à tous les acteurs impliqués. Par conséquent, PIFA doit également analyser le flux de retour d’expérience désiré.

Un processus a un certain contexte. Chaque action est liée à un processus et a donc un contexte spécifique d'action et de processus. Une partie du contexte peut être formalisée comme information - l'information contextuelle. L'information peut exister depuis l'initialisation du processus ou a pu être produite pendant l'exécution du processus. Elle aide à mieux classifier le processus et l'action aussi bien que soutenir l'internalisation d'information.

PIFA est une aide pour formaliser des processus complexes, particulièrement des processus transversaux intense des connaissances produite lors de l’exécution. La figure PIFA (figure 3) peut être considéré comme « Template » pour faire des entretiens avec les acteurs et le management pour comprendre et formaliser le processus. L'idée est de l’appliquer à

215

différentes exécutions de processus pour les formaliser. Le but est de saisir et formaliser le flux des différentes actions et l'information produite associée dans de vrais processus exécutés. Par conséquent, PIFA s´articule autour de trois parties d'analyse :

A. La partie « Analyse de Processus » B. La partie « Analyse de Information » C. La partie « Analyse de Fonctionnalité »

8.4.2 Les trois parties de PIFA : Processus, Information et fonctionnalité Pour chaque action, l'action précédente, l'information entrant et sortant et les fonctionnalités pour traiter les informations sont analysées.

A. La partie « Analyse de Processus » Cette partie formaliser le flux de processus de chaque processus analysé pour établir un modèle de processus générique soutenu par des approches de « business analysis » et « business process re-engineering » : le modèle généré devrait également être très flexible pour soutenir les changements dynamiques dans des instances ou dans des modèles de processus. En étant aussi flexible que possible, le modèle de processus représentera le « monde réel » - le vrai processus exécuté - avec des précisions aussi exactes que possible. Nous illustrons dans la figure suivante un exemple d'une analyse de processus par PIFA :

Figure 108: Exemple d’un résultat de PIFA

L’output de la partie « processus » est un modèle de processus optimisé contenant des actions et des dépendances entre les actions aussi bien que les conditions d’ouverture et de fermeture, ainsi que de différentes règles pour l’exécution des actions et le déroulement de processus associé.

La partie de processus de PIFA couvre les partie Input et Output décrites en termes de conditions d’ouverture et de fermeture d’une action.

B. La partie « Analyse d’Information » Cette partie formalise le flux d’information associé au processus. En particulier, le type de transfert utilisé (implicite/explicite) et les outils utilisés sont analysés pour comprendre et formaliser le contexte et l'infrastructure utilisée. Les flux d’information découverts aident à fusionner l'information aux bonnes actions ; donc au bon moment et aux bonnes personnes. Le flux d’information ne devrait pas être soutenu seulement dans la direction du processus, mais spécialement vers les actions en moment de l’action courante (un flux d’information de

216

retour d'expérience) et entre des processus. Par conséquent, la connaissance nécessaire et désirée est particulièrement analysée. La connaissance produite dans un processus devrait être capitalisée en tant que connaissances nécessaires pour donner une valeur ajoutée immédiate aux employés. Elle pourrait être réutilisée comme connaissance désirée dans l'avenir. Par conséquent, l'annotation de cette connaissance par des informations contextuelles est primordiale. Les techniques de gestion de connaissances telles que les ontologies et des approches sémantiques pourraient soutenir cette partie. En particulier, une ontologie de domaine de processus devrait être construite. Cette ontologie sera employée pour la gestion de processus industriel pour annoter l'information produite pendant son exécution. Le but est de capter la connaissance individuelle et de la répandre à travers des barrières organisationnelles afin d'accumuler une connaissance collective (la mémoire d'organisation).

La partie d’information de PIFA couvre les partie Input et Output décrites, c’est-à-dire le flux des informations nécessaires et désirées pour l'ouverture et la fermeture d’une action. De plus, elle analyse le contexte et le retour d'expérience.

C. La partie « Analyse de Fonctionnalité » Cette partie formalise les fonctionnalités exécutées dans une action afin de transformer et manipuler les informations entrantes et utilisées. Des fonctionnalités sont formalisées grâce à des entretiens basés sur le « Template PIFA » utilisé et grâce à des observations faites pendant l’analyse. Pendant des discussions avec les interviewés et basées sur la formalisation de ces fonctionnalités, des problèmes sont analysés et des possibilités d'amélioration sont détectées. Cette optimisation représente la valeur ajoutée supplémentaire par rapport à l’existant pour les compagnies et pour les utilisateurs. De plus, cette valeur ajoutée donne assez d’incitations et la motivation nécessaire aux utilisateurs pour accepter un changement et cette nouvelle méthodologie de travail formalisée et optimisée. Cette méthodologie est enrichie par une capitalisation supplémentaire des connaissances, une annotation contextuelle de l'information et un partage amélioré de la connaissance désirée. Une exécution de processus a toujours des interactions humaines. Nous considérons que chaque employé a ses habitudes et résiste aux changements. Il est bien connu qu’on devrait prêter attention sur aux barrières potentielles de l'acceptation. Les études empiriques ont déjà prouvé que les utilisateurs de systèmes informatiques ne les utilisent pas pour stocker l'information même si ils ont un gain personnel à l'avenir.

La partie de fonctionnalités de PIFA est un modèle de processus optimisé fondrant des fonctionnalités à chaque action. Ces fonctionnalités pourraient être améliorées et représentent la valeur ajoutée pour l'acteur. Ceci aide à réduire la résistance des utilisateurs pour accepter un nouvel outil. De plus, il réduit également la résistance à la capitalisation des connaissances. Cette partie de PIFA couvre la partie décrite de fonctionnalité. Il analyse quelles fonctionnalités sont exécutées, basé sur quels règles industriels et avec quelle information.

8.4.3 Le but de ces trois parties différentes de PIFA PIFA peut être appliqué sur tous les types de processus, particulièrement sur ceux dans lesquels beaucoup de connaissances est produites. Il formalise le flux de processus et le

217

distingue du flux d’information. Les trois parties de l’approche PIFA garantit un modèle de processus représentant le processus exécuté réellement. Ce processus sera lié aux informations produites et aux informations contextuelles. De plus, cette approche aide à formaliser les besoins et les possibilités d'amélioration des fonctionnalités ; ceci se fait en visant l’optimisation de l’existant et la réduction de la résistance des utilisateurs à des changements, comme par exemple de nouvelles méthodes de travail et de la capitalisation des connaissances, souvent considérés comme surcharge.

PIFA pourrait aider donc à construire un système de gestion de connaissances qui combine des activités de gestion des connaissances et de gestion de processus industriel.

• La partie « analyse de processus » construit un modèle de processus générique pour un outil de gestion de « workflow ».

• La partie « analyse d’information » construit un modèle de capitalisation, de partage et de recherche des connaissances. Ce modèle est soutenu par une ontologie

• La partie « analyse de fonctionnalité » garantit d’inclure toutes les fonctionnalités nécessaires et donner une valeur ajoutée pour faciliter l'acceptation de la nouvelle méthodologie de travail par les utilisateurs

Le respect de ces trois parties améliore la probabilité qu'un système de gestion des connaissances soit accepté par des utilisateurs. De plus, il intègre des activités de gestion de connaissances dans le travail quotidien. 8.5 Abstraction et synthèse de l'analyse de processus de SWR

par PIFA Même si les trois parties de PIFA sont formalisées séparément afin d'analyser et appliquer des méthodes de chaque domaine (des techniques de gestion d’information et des connaissances, des techniques de gestion de processus industriel et des techniques de l’analyse de besoin), les résultats doivent être intégrés dans le modèle générique. Basé sur ce modèle, une nouvelle méthodologie de travail est développée et complété par des fonctionnalités de gestion des connaissances et des fonctionnalités améliorées.

Ce principe a été appliqué au contexte des processus d'essais chez STMicroelectronics. Les résultats sont présentés et discutés. Six types d'action ont été identifiés comme illustrés dans le tableau suivant :

218

A1 : Définition de l’essai A2 : L’attribution de lots pour un essai A3 : Préparation des instructions d’une opération pour l’essai A4 : Validation des préparations des instructions pour l’essai A5 : Traitement de lot pour un essai à une opération A6 : L’analyse de l’essai

Figure 109: Les 6 types d’action identifiés du processus SWR

Ces types d'action ont été identifiés pendant l'observation et le suivi de trois processus d’essai grâce à l'approche PIFA. Le déploiement d'une nouvelle méthodologie sans aucun appui concret pour motiver et lancer un changement n'est pas facile. En outre, l'analyse de contexte du processus a déjà prouvé que même les outils existants ne pourraient pas satisfaire globalement le but défini d’une meilleure réutilisation des connaissances produites pendant aux processus d'essais (particulièrement concernant des résultats négatifs et des résultats intermédiaires). Par conséquent, un outil, appelé « Experiment Management Application (EMA) », a été conçu, basé sur le modèle de processus générique établi avec des fonctionnalités améliorées à l’aide de PIFA, comme illustré dans la figure ci-dessous.

Figure 110: Intégration des trois parties de PIFA dans un modèle générique

Ces caractéristiques identifiées ont été analysées et formalisées, soutenu par l'approche PIFA. L’outil informatique réalisé (EMA), soutenant le processus d'essai basé sur ces caractéristiques découverts par PIFA, est expliquée dans la section suivante.

8.5.1 L’exemple pour des dépendances entre le flux d’information et le flux de processus dans l’outil EMA supportant les SWRs

La figure suivante illustre le principe décrit de séparer le document de demande d’essai (SWR) dans différentes entités de l'information afin de les réutiliser dans différentes actions (la fusion des informations aux bonnes actions). L'essai sera décrit dans l'action « définition de l’essai/Experiment Definition» et l’interface d’une action pour un utilisateur est structuré

219

dans des composants de l'information afin de réutiliser ces composants dans un ordre différent pour d’autres actions. Toutes les opérations concernées et leurs conditions d'essais seront définies. En outre, la plaque utilisée pour une condition d’essai peut être sélectionné. Cette information sera réutilisée dans différentes actions comme illustrées si dessous. Par conséquent, l'information d’essai sera divisée en différentes entités de l'information (une entité par opération) et les entités de l'information peuvent être réutilisées selon les besoins d'utilisateur.

Figure 111: Les informations séparées dans des entités et fusion aux bonnes actions

Cependant, la connaissance capitalisée pendant l’exécution de processus devrait être réutilisée dans différents processus. Par conséquent, des interfaces de recherche d’information sont proposées comme expliqué dans les sections suivantes.

8.5.2 Fonctionnalités de recherche d’information Les interfaces de recherche d’information sont nécessaires pour introduire un partage des connaissances entre des différent processus d’essai. Par conséquent, deux types différents sont fournis : une interface de reportage et une interface de recherche. Dans le suivant, un exemple des interfaces développées est expliqué. Cette interface permet de rechercher dans une ou plusieurs catégories décrivant le contexte de l'essai. Afin de rechercher l'information très précise et spécifique (p.ex. opération, description d'opération, secteur, nom d'acteur, recette, et machine), le besoin de recherche peut mieux être exprimé et plus détaillé. L'objectif est de trouver l'information spécifique ; de plus, les résultats de recherche détaillent les mots-clés et les conditions d'essais.

220

Figure 112: Recherche des informations détaillées des essais

En recherchant une recette, un lot ou un équipement, les noms des employés qui ont déjà travaillé aux essais existants sont affichés. Cette recherche d’information pourrait également être utilisée pour identifier des acteurs avec une connaissance spécifique de recette ou d'équipement.

8.6 CONCLUSION Ce travail a analysé le processus d'essai chez STMicroelectronics avec le but de capitaliser la connaissance produite et pour initier sa réutilisation. Beaucoup de redondance d’information a été détectée pendant une première analyse de processus d’essai. La gestion des connaissances fournit des techniques pour capitaliser et diffuser la connaissance. Cependant, le domaine doit prendre en compte une résistance des utilisateurs à des changements et à la capitalisation. La gestion de processus industriel a été initiée pour automatiser l'exécution des processus. Cependant, l'interaction humaine et les aspects dynamiques du processus industriel sont devenus de plus en plus importants. L'intégration de gestion des connaissances dans la gestion de processus industriel pourrait renforcer une capitalisation et une réutilisation, spécialement dans des actions en amont et dans des actions d’autres processus. L'exécution et le déploiement d'une nouvelle méthodologie de travail peuvent être soutenus par un outil informatique. Par conséquent, l'approche PIFA appliquée au contexte de processus d’essais a permis de concevoir EMA - Experiment Management Application- un outil pour soutenir le processus d'essai et sa connaissance produite. PIFA peut être considérée comme une approche pour détecter le flux des connaissances nécessaires et désirées liées au processus industriel. Le flux des connaissances désirées est souvent limité à cause de barrières organisationnelles. Les techniques de gestion des connaissances telles que des ontologies, des approches sémantiques ou les annotations utilisées pour une capitalisation et une recherche d’information pourraient soutenir et améliorer la gestion des connaissances désirées. Pour intégrer et déployer cette gestion, les fonctionnalités détectées par PIFA et liées au processus doivent être améliorées pour donner des incitations aux utilisateurs afin qu’ils acceptent la nouvelle méthodologie de travail supplémentaire par des aspects degestion de connaissances.

221

EMA intègre le modèle générique de processus d'essai afin de gérer et supporter l'exécution de ses instances. L’interface d’utilisateur pour exécuter une action soutiendra d’une part l'exécution des fonctionnalités d'une action ainsi que la continuation de processus. D'autre part, des méthodes de capitalisation des connaissances y sont également intégrées. Ces méthodes de capitalisation de connaissances sont basées sur le principe de l'annotation et des approches sémantiques soutenues par une ontologie de domaine. La connaissance capitalisée à travers l’exécution de processus sera réutilisée en tant qu'information contextuelle afin d’initier une réutilisation des connaissances. L'outil d'EMA, basé sur le framework scientifique de la gestion des connaissances et de gestion de processus industriel soutient en particulier des activités pour la gestion de contenu écrit produit et lié aux processus industriels.

223

Bibliography

A [Abecker et al., 1998] Abecker, A., Bernardi, A., Hinkelmann, K., Kuehn, O., &

Sintek, M.: “Toward a technology for organizational memories”, IEEE Intelligent Systems, no. 3: p. 40-48, 1998.

[Alavi, 1999] Alavi, M.: “Knowledge Management Systems: Emerging

Views and Practices from the field”, 32nd Hawaii International Conference on System Sciences, 1999.

[Alavi et al., 2001] Alavi M. and Leidner D.: “Review: Knowledge

management and knowledge management systems: Conceptual foundations and research issues”, MIS Quarterly, no 25( vol. 1):106-136, 2001.

[Albrecht, 1993] Albrecht, F.: “Strategisches Wissensmanagement der

Unternehmensressource Wissen”, Verlag Peter Lang, Frankfurt am Main, 1993

[Alonso et al., 1997] Alonso, Agrawal, El Abbadi, Mohan: “Functionality and

Limitations of Current Workflow Management Systems”, IEEE-Expert, 1997.

[Altshuller, 1999] Altshuller, G.: “The Innovation Algorithm: TRIZ,

Systematic Innovation, and Technical Creativity”, Worcester, MA: Technical Innovation Center, Inc., 1999

[Anupindi et al., 1999] Anupindi, R., Deshmukh, SD., Chopra, S., van Mieghem,

J.: “Managing Business Process Flows”, Prentice-Hall, Inc. Upper Saddle River, NJ, USA, 1999.

[APQC, 1996] American Productivity and Quality Center (APQC) and

Arthur Andersen: “The knowledge management assessment tool: external benchmarking version”, 1996.

[Argyris et al., 1978] Argyris, C., Schon, D.A.: “Organizational Learning,

Reading”, MA: Addison Wesley, 1978. [Autissier, 2003] Autissier, D. and Moutot, J.-M.: “Pratiques de la conduite

du changement - comment passer du discours à l’action”, DUNOD, 2003.

224

B [Bachimont, 2004] Bachimont, B.: “Pourquoi n’y a-t-il pas d’expériences en

ingénierie des connaissances ?”, 15ème journées francophones d’Ingénierie des Connaissances, Lyon, 2004.

[Ballay, 1997] Ballay, J.F.: “Capitaliser et transmettre les savoir-faire de

l’entreprise”, Collection de la direction des Etudes et Recherche d’Electricité de France, 1997.

[Balmisse, 2002] Balmisse, G.: “Gestion des connaissances - Outils et

applications du knowledge management”, Entreprendre Informatique, Edition Vuibert, 2002.

[Barkat, 2002] Barkat, E. : “When Business Communication is critical”,

KM World Magazine (Special supplement), Specialty Publishing Group, May 2002.

[Barthès, 1997] Barthes, J.P.: “Capitalisation des connaissances et

intelligence articielle”, in Journées Franco-Finlandaises de Tampere., Compiègne, cf. pages: 77-80, 1997.

[Barthès, 2000] Barthes, J.P.: “Livret d’introduction au knowledge

management”, edition 2000, Paris: IIIA Groupe de Travail Méthodologie, 2000.

[Bartlett, 1996] Bartlett, C. (McKinsey & Company): “Managing

Knowledge and Learning”, Harvard Business School, Case 9-396-357, 1996.

[Becker, 1999] Becker, G.: “Knowledge Discovery”, in: Jay Liebowitz:

“Knowledge Management Handbook”, CRC Press, 1999. [Beckman, 1999] Beckman, T.J.: “The Current State of Knowledge

Management”, in: Liebowitz “Knowledge Management Handbook”, CRC Press, USA, 1999.

[Berkeley, 2000] http://www2.sims.berkeley.edu/research/projects/how-

much-info/ [Berkeley, 2003] http://www2.sims.berkeley.edu/research/projects/how-

much-info-2003/ [Berners et al., 2001] Berners-Lee, T., Hendler, J., and Lassila, O.: “The

semantic web”, Scientific American, 2001,

225

http://www.sciam.com/2001/0501issue/0501bernerslee.html

[Berners-Lee, 1993] Berners-Lee: “Naming and addressing: URIs, URLs, ...”,

W3C, Overview http://www.w3.org/Addressing/ [Berners-Lee, 1998] Berners-Lee: “Cool URIs don't change”, W3C Style,

http://www.w3.org/Provider/Style/URI.html [Bès et al., 1997] Bès J.L and Bouillon M.-P.: “Retour d’expérience et

mémoire technique : vers la notion de qualité mémoire”, in Deuxième Congrès Franco-Québécois de Génie Industriel, Albi, 1997.

[Bider, 2002] Bider: “Goal-Oriented Patterns for Business Processes”,

GBPM’02, London, 2002 [Boehm, 1981] Boehm, B. W. : “Software Engineering Economics,

Advances in Computing Science & Technology Series”, Prentice Hall PTR, 1981, ISBN: 0138221227

[Bourgeon, 2002] Bourgeon L.: “Time and organizational learning in new

product development projects”, in OKCL 2002 - The third European Conference on Organizational Knowledge, Learning and Capabilities, Athens, Greece, 2002.

[Boyce, 1994] Boyce, B.R., Meadow, C.T., Kraft, D.H.: “Measurement

in information science“, Academic Press, 1994 [Bullinger, 2004] Bullinger: Preface in “Wissen vernetzen”, Springer Verlag

Berlin Heidelberg New York, 2004, ISBN 3-540-21349-X. [Bus, 2005] http://www.bus.utexas.edu/kman/ [Busch et al., 2003] Busch, H., Gardoni, M., Tollenaere, M.: “Recherche

d'Information selon des points de vue multiples basée sur des metadonnées”, Coopération Innovation et Technologies - CITE, Troyes, France, 2003.

[Busch et al., 2004a] Busch, H., Gardoni, M., Tollenaere, M.: “Difficultés et

propositions pour la construction et le deploiement des systemes de connaissances”, 2eme Modélisation et pilotage des systèmes de Connaissances et de Compétences dans les Entreprises Industrielles - C2EI, Nancy, France, 2004.

[Busch et al., 2004b] Busch, H., Gardoni, M., Tollenaere, M.: “Partage de

documents au sein d’une equipe a partir d’une

226

caracterisation de leurs contenus selon des points de vues multiples”, 2 Colloque IPI - IPI, Autrans, France, 2004.

[Busch et al., 2005a] Busch, H., Gardoni, M., Tollenaere, M.: “Experience

Management reflections for an agile manufacturing environment: a proposition for an information exchange across organizational boundaries”, ICAM2005 The International Conference on Agile Manufacturing - ICAM, Helsinki, Finnlande, 2005.

[Busch, 2005b] Busch, H.: “WM-Systeme gekonnt einsetzen”,

Wissensmanagemt - das Magazin fuer Führungskräfte, online edition, n° 12, 2005.

[Busch et al., 2006a] Busch, H., Gardoni, M., Tollenaere, M.: “Knowledge

Management Aspects for Business Process Management: An approach through the information management within and between processes – case study at STMicroelectronics”, 6th International Conference on Integrated Design and Manufacturing in Mechanical Engineering - IDMME, Grenoble, France, 2006.

[Busch et al., 2006b] Busch, H., Gardoni, M., Tollenaere, M.: “The conception

of a human-machine interface for a Manufacturing Knowledge Retrieval System: case study at STMicroelectronics”, 15th International Association of Management of Technology - IAMOT, Bejing/Peking, Chine, 2006.

[Busch et al., 2006c] Busch, H., Gardoni, M., Tollenaere, M.: “Supporting the

conception of a Knowledge Management System by the PIFA approach: case study STMicroelectronics”, International Multi Conference of Engineers and Computer Scientists – IMECS, Hong Kong, Chine, 2006.

[Bussler et al., 1994] Bussler, C. and Jablonski, S.: “An approach to integrate

workflow modeling and organization modeling in an enterprise”, in proceedings of the 3rd Workshop on Enabling Technologies, 1994.

C [Cantzler, 1996] Cantzler, O.: “Une architecture conceptuelle pour la

pérennisation d’historiques globaux de conception de produits industriels complexes”, PhD thesis, Ecole

227

Centrale Paris, Laboratoire productique logistique, Paris, 1996.

[Carlsen, 1997] Carlsen: “Conceptual modeling and composition of

flexible workflow models”, PhD Thesis, Department of Computer Science and Information Science, Norwegian University of Science and Technology, Norway, 1997.

[Casati et al., 1995] Casati, F., Ceri, S., Pernici, B. and Pozzi, G. “Conceptual

modeling of workflows”, in proceedings of the 14th International Object-Oriented and Entity-Relationship Modeling Conference, Gold Coast, Australia, volume 1021 of Lecture Notes in Computer Science, pp. 341-354. Springer-Verlag, 1995.

[Casati et al, 1998] Casati, Grefen, Pernici, Pozzi and Sanchez : “WIDE

Workow Model and Architecture”, Technical Report 96-19, University of Twente, 1998.

[Choo, 1996] Choo, C.: “Managing Information for the Competitive

Edge”, Neal-Schuman, Protland, 1996. [Corbel, 1997] Corbel J.C.: “Méthodologie de retour d’expérience :

démarche MEREX de RENAULT”, chapitre 4 dans [Fouet, 1997], 1997.

[Creß, 2004] Creß, U.: “Von der Schwierigkeit, Wissen zu teilen – eine

psychologische Sichtweise”, Revue Wissensmanagement, Büro für Medien Verlag, Augsburg, vol 03, 2004.

[Curtis et al., 1992] Curtis, B., Kellner, M.I. and Over, J.: “Process modeling”,

CACM, vol.35, no. 9, p75-90, 1992

D [Damaskopoulos, 2002] Damaskopoulos P.: “Passages from organisational

knowledge to innovation : New economy dynamics, intangible assets and organisational design”, in OKCL 2002, The third European Conference on Organizational Knowledge, Learning and Capabilities, Athens, Greece, 2002.

[Davenport et al., 1998] Davenport, T. H. & Prusak, L.: “Working Knowledge -

How organizations manage what they know”, Havard Business School Press, Boston, Massachusetts, 1998.

228

[Deiters et al., 1995] Deiters, W., Gruhn, V., Striemer, R.: “Der FUNSOFT-Ansatz zum integrierten Geschäftsprozeflmanagement”, in: Wirtschaftsinformatik, 37, 1995.

[DeJean et al., 1991] DeJean, D. and DeJean, S.B.: “Lotus Notes at Work”,

New York: Lotus Books: 1991. [Dellen et al., 1997] Dellen, B., Pews, G. and Maurer, F.: “Knowledge Based

Techniques to Increase the Flexibility of Workflow Management”, Data & Knowledge Engineering Journal, NorthHolland, 1997. http://citeseer.ist.psu.edu/dellen97knowledge.html

[Dieng. et al., 1998] Dieng R., Corby O., Giboin A., Rybière, M.: “Methods

and tools for corporate knowledge management”, rapport technique, INRIA, Projet ACCACIA, 1998

[Dieng, 1999] Dieng, R.: “Projet Accacia. Rapport d’activité”, rapport

technique, INRIA, Project Accacia, Sophia, 1999. [Dieng. et al., 2000] Dieng, R. Corby, O., Giboin, A., Golebiowska J., Matta,

N., Ribière, M.: “Méthodes et outils pour la gestion des connaissances”, chapter “Mémoire de projet, Stratégies et système d’information”. Paris, Dunod édition, 2000.

[Dieng-Kuntz, 2002] Dieng-Kuntz R.: “Méthodes et modèles pour la mémoire

d’entreprise”, Projet ACACIA, rapport d’activités, 2002. [Douglas et al., 1995] Douglas. P., Bogia, F., Simon, M., Kaplan: “Flexibility

and Control for Dynamic Workflows in the wOrlds Environment”, in proceedings of the Conference on Organizational Computing Systems, 1995.

[Drucker, 1993] Drucker, P. A.: “A Post Capitalist Society”. HarperCollins,

New York, 1993.

E [Eppler et al., 2001] Eppler, M., Sukowski, O., “Fallstudien im

Wissensmanagement: Loesungen aus der Praxis”, St. Gallen, NetAcademy Press, 2001.

229

[Eppler, 2004] Eppler: Preface in “Wissenskommunikation in Organisationen – Methoden, Instrumente, Theorien“, Springer Verlag Berlin Heidelberg New York, 2004, ISBN 3-540-20350-8.

[Eriksson et al., 2000] Eriksson, H., Penker, M.: “Business Modeling with UML”,

John Wiley & Sons, 2000, ISBN 0-471-29551-5 [Ermine et al., 1996] Ermine J.L., Chaillot M., Bigeon P., Charreton B.,

Malavieille D.: “MKSM : Méthode pour la gestion des connaissances”, Ingénierie des systèmes d’information, AFCET-Hermès, vol. 4, n°4, pp. 541-575, 1996.

[Ermine, 1999] Ermine J.-L.: “Traité IC2 (Information, Communication,

Commande)”, volume Capitalisation des Connaissances, chapter “Capitaliser et partager les connaissances avec la méthode MKSM”, Paris, hermès édition, 1999.

[Ermine, 2001] Ermine J.L.: “Capitaliser et partager les connaissances

avec la méthode MASK”, chapitre 4 dans [Zacklad, 2001], 2001.

[Estublier et al., 2003] Estublier, J., Le, A-T., Villalobos, J.: “Using Federations

for flexible SCM Systems”, in proceedings of the 11th International Workshop on Software Configuration Management (SCM-11), USA, 2003.

F [Fensel et al., 2002] Fensel, D., van Harmelen, F., Ding, Y., Klein, M.,

Akkermans, H., Broekstra, J., Kampman, A., van der Meer, J., Studer, R., Sure, Y., Davies, J., Duke, A., Engels, R., Iosif, V., Kiryakov, A., Lau, T., Reimer, U., & Horrocks, I.: “Final project report. On-To-Knowledge deliverable”, Vrije Universiteit Amsterdam, 2002.

[Florijn et al., 1996] Florijn, G., Besamusca, T., Greefhorst, D.: “Ariadne and

HOPLa: Flexible coordination of collaborative processes”, in proceedings of Coordination’96, Springer Verlag, 1996.

[Fortier, 2002] Fortier, J.Y. and G. Kassel.: “Génération de documents

virtuels personnalisées à partir de moèles de connaissances”, in Documenst Virtuels Personnables 2002.

230

[Fouet, 1997] Fouet, J.M.: “Connaissance et savoir-faire en entreprise,

intégration et capitalization”, Hermès Science Publications, 1997.

[Frank, 2003] Frank, C.: “Knowledge Management for an Industrial

Research Center – case study EADS”, PhD Dissertation, INPG France, 2003.

[Frege, 1994] Frege, G.: “Funktion, Begründung, Bedeutung. Fünf

logische Studien”. Kleine Vandenhoeck-Reihe. Vandenhoeck & Ruprecht, Göttingen, 1994.

G [Galler et al., 1995] Galler, J., Hagemeyer, J., Scheer, A.-W.: “The

Coordination of Interdisciplinary Teams in Workflow Projects”, in proceedings IDIMT-95, 1995.

[Gardoni, 1999] Gardoni M.: “Maitrise de l’information non structurée et

capitalisation de savoir et savoir-faire en ingénierie intégrée”, cas d’étude aerospatiale. PhD thesis, Université de Metz, Metz, 1999.

[GartnerGroup, 2002] Gartner Group (R. Vales, D. Gootzit, G. Phifer)

Management Update: “Six Ways That Portal Projects Can Fail or Succeed”, IGG-10092002-03, 2002.

[Georgakopoulos, 1999] Georgakopoulos : “Collaboration process management

for advanced application” , presented at international process technology workshop, 1999.

[Georgakopoulos et al., 1995] Georgakopoulos, D. and Hornick, M.: “An overview of

Workflow Management: From Process Modeling to Workflow Automation Infrastructure, Distributed and Parallel Databases”, Kluwer Academic Publishers, Boston, 1995.

[Godart et al., 1999] Godart, C., Perrin, O., Skaf, H.: “COO: a workflow

operator to improve cooperation modeling in virtual processes”, presented at 9th Int. Workshop on research issue on data engineering information technology for virtual enterprises, 1999.

[Grigori et al., 2000] Grigori D., Skaf-Molli H, and Charoy F. 2000 ‘Adding

Flexibility in a Cooperative Workflow Execution Engine’.

231

High Performance Computing and Networking, HPCN Europe.

[Groleau, 2002] Groleau C.: “Structuration, Situated Action and

Distributed Cognition: Rethinking the Computerization of Organizations”, Systèmes d’Information et Management, Vol. 7, n° 2, pp. 13-36, 2002.

[Gronau et al., 2004] Gronau, N., Weber, E: “KDML – Knowledge Description

Modelling Language, Modeling of knowledge intensive business processes with the declaration language KDML”, in Mehdi Khosrow-Pour, Hrsg., in proceedings of the IRMA International Conference 2004, IDEA Group Press, 2004.

[Gruber, 1995] Gruber, T. R.: “Towards principles for the design of

ontologies used for knowledge sharing”, International Journal of Human-Computer Studies, 1995.

[Grundstein, 1995] Grundstein M.. “La capitalisation des connaissances de

l’entreprise, système de production de connaissances”, Actes du colloque L’Entreprise Apprenante et les Sciences de la Complexité, Aix en Provence, France, 22-24 Mai, 1995.

[Grundstein, 2000] Grundstein M.: “Repérer et mettre en valeur les

connaissances cruciales pour l’entreprise”, Actes du 10ème Congrès International de l’AFAV, Paris, novembre, 2000.

H [Haase et al., 2004] Haase, P., Sure, Y. and Vrandecic, D.: “Ontology

Management and Evolution: Survey, Methods and Prototypes”, SEKT Deliverable D3.1.1, December 2004.

[Hammer et al., 1993] Hammer, M., Champy, J.: “Re-engineering the

Corporation; A Manifesto for Business Revolution”, Harper Business, New York., 1993.

[Handschuh et al., 2003] Handschuh, S., Lechner, U., Lincke, D.-M., Schmid, B.,

Schubert, P., Selz, D. and Stanoevska-Slabeva, K.: “NetAcademy - A New Concept for Online Publishing and Knowledge Management”, Lecture Notes in Computer Science, Volume 1385 / 1998, 312 In: T. Margaria, B. Steffen, R. Rückert, J. Posegga (Eds.), Services and

232

Visualization: Towards User-Friendly Design: ACoS’98, VISUAL’98, AIN’97. Selected Papers, Chapter: p. 29, Online Date: May 2003.

[Herrmann, 2004] Herrmann, T.: “Kontextberücksichtigung als Kernaufgabe

der Wissenskommunikation”, in Wissens-kommunikationen in Organisationen, Springer Verlag, 2004

[Hibbard, 1997] Hibbard, J.: “Knowing what we know”. Information Week,

1997. [Hollinsworth, 1994] Hollinsworth: “The Workflow Reference Model”,

Workflow Management Coalition, TC00-1003, December 1994.

[Hong et al., 2002] Hong P., Doll W. J., Nahm A., Xiao L.: “Sharing

knowledge in integrated product development”, in OKCL 2002, the third European Conference on Organizational Knowledge, Learning and Capabilities, Athens, Greece, 2002.

[Horrocks et al., 2002] Horrocks, I., Hendler, J.: Proceedings of the First

International Semantic Web Conference: The Semantic Web (ISWC 2002), volume 2342 of Lecture Notes in Computer Science (LNCS), Springer, Sardinia, Italy, 2002.

[Huang et al., 2002] Huang J.-C., Wang, S.F.: “Knowledge conversion abilities

and knowledge creation and innovation : A new perspective on team composition”, in OKCL 2002, The third European Conference on Organizational Knowledge, Learning and Capabilities, Athens, Greece, 2002

I [InterchangeGroup, 2002] Interchange Group: “White Paper. Understanding

business needs, Laying the foundation of success”, 2002. http://www.interchangegroup.com/pdf/undbusneeds.pdf

J [Jablonski, 1994] Jablonski, S.: “MOBILE: a Modular Workflow Model and

Architecture”, in proceedings of the Fourth International

233

Working Conference on Dynamic Modelling and Information Systems, 1994.

[Jacobson, 1995] Jacobson: “The Object Advantage”, Addison-Wesley,

1995, ISBN 0-201-42289-1. [Jaime, 2005a] Jaime, A. “From Quality Management to Knowledge

Management in Research Projects: An Approach though the Management of Contents in Bibliographical Research”, PhD Dissertation, INPG France, 2003.

[Jaime et al., 2005b] Jaime, A., Gardoni, M., Mosca, J., Vinck, D.: “Knowledge

Management in Research Organizations: an approach through the management of scientific concepts”, Journal of Knowledge Management, vol 9, n° 6, p. 53 - 66, 2005.

[Johannessen et al., 1999] Johannessen J.-A., Olsen B., Olaisen J.: “Aspects of

innovation theory based on knowledge-management”, in International Journal of Information Management, 19 :121-139, 1999.

[Johansen et al., 1991] Johansen R.: “Groupware: Future Directions and Wild Cards”, in International Journal of Organizational Computing, 1991.

[Jovanovic et al., 2002] Jovanovic B., Rousseau PL.: “Moore’s Law and Learning

by Doing”, Review of Economic Dynamics, 2002, http://www.utdt.edu/congresos/economia/pdfs/Jovanovic.pdf

K [Kay, 2003] Kay, A. S.: “The Curious Success of Knowledge

Management”, pages 679-687, 2003. [Kerzner, 2003] Kerzner, H. “Project Management: A Systems Approach

to Planning, Scheduling, and Controlling“, John Wiley & Sons; 8th edition, 2003, ISBN: 0471225770.

[Korhonen et al., 2002] Korhonen, J., Pajunen, L., Puustjäravi, “Using

Transactional Workflow Ontology in Agent Cooperation”, EurAsian Workshop on Agents for Information Management, 2002

http://koti.mbnet.fi/jarmoko/papers/

234

[Kuo et al., 1996] Kuo, D. Lawley, M., Liu, C. and Orlowska, M.E.: “A general model for nested transactional workflow”, in proceedings of the International Workshop on Advanced Transaction Models and Architecture (ATMA’96), Bombay, India, pp.18-35, 1996.

[Kräkel, 1999] Kräkel, M. : “Organisation und Management”, Mohr

Siebeck verlag, 1999. [Kwon et al., 1987] Kwon, T.K. and Zmud, R.W. “Unifying the Fragmented

Models of Information Systems Implementation” in R.J. Boland Jr. and R.A. Hirschheim (Eds.) Critical Issues in Information Systems Research, New York: John Wiley and Sons, 1987.

L [Landauer, 2001] Landauer, J. “Definition of Contexte”, 2001

http://www.importanceofphilosophy.com/Epistemology_Context.html

[Larman, 1999] Larman, C. “Applying UML and patterns: An introduction

to object-oriented analysis and design”, Pearson Higher Education, 1999.

[Larousse, 2000] http://www.encyclopedie-larousse.fr/ [Le Cardinal et al., 1997] Le Cardinal J. et Mekhilef M.: “Capitalisation des

processus de conception en vue de réutilisation : etat de l’art”. CER 97-06 laboratoire Productique Logistique, Ecole Centrale Paris, 1997.

[Leonard-Barton, 1995] Leonrad-Barton, D.: “Wellsprings of knowledge”. Boston:

Harvard Business School Press, 1995. [Lewin, 1952] Lewin, K.: “Group Decision and Social Change”, in

Newcombe, E. and Harley, R. (Eds.) Readings in Social Psychology, New York: Henry Holt, 1952.

[Leymann et al., 1994] Leymann, F., Altenhuber, W.: “Managing Business

Processes as an Information Resource”, IBM Systems Journal, 1994

[Longueville et al., 2003a] Longueville B., Dudézert A.: “Mysmac, une méthode

d’analyse et de suivi des systèmes de gestion des

235

connaissances”. in 5ieme Congrèe International de Génie Industriel, Laval, Canada, 2003.

[Longueville et al., 2003b] Longueville B., Gardoni M.: “A survey of context

modelling : approaches, theories and use for engineering design researches”, in ICED 2003, 14th International Conference on Engineering Design, Stockholm, Sweden, 2003.

M [Malone et al, 1992] Malone, T.W., Lai, K.Y. and Fry, C.: “Experiments with

OVAL: A Radically Tailorable Tool for Cooperative Work”, in proceedings of the Third Conference on Computer Supported Cooperative Work, Toronto, Canada, 1992.

[Maltzahn, 1997] Maltzahn, E.: “The Chautauqua workflow system”, in

proceedings of the International Conference on System Science, Maui, HI, 1997.

[Matta et al., 1999] Matta N., Corby O., Ribière M.: “Définition d’un modèle

de mémoire de projet”. Rapport technique, INRIA, Sofia Antipolis, 1999.

[Media-Mora et al., 1992] Medina-Mora, R., Wong, H., Flores, P.: “The action

workflow approach to workflow management”, in proceedings of the 4th conference on computer-supported cooperative work, 1992.

[Mille, 2002] Mille A.: “Gestion des connaissances: problématiques

actuelles”, chapter 7 in [Soënen et al. 2002], 2002. [Mintzberg, 1987] Mintzberg, H. “The Fall and Rise of Strategic Planning”,

Harvard Business Review, 1994. [Mira-Bonnardel, 2000] Mira-Bonnardel, S.: “Pour un managment conjoint des

connaissances et des competences”. in IXième Conférence de l’Association Internationale de Management Stratégique, Montpellier, 2000.

236

N [Nonaka et al., 1995] Nonaka, I., Takeuchi, H.: “The Knowledge Creating

Company”, Oxford University Press, 1995. [Nonaka et al., 2001a] Nonaka, Toyama, Byosière: “A theory of organizational

knowledge creation – Understanding the dynamic process of creating knowledge”. in Dierkes: Organizational Learning and Knowledge, Oxford University Press, 2001.

[Nonaka, 2001b] Nonaka, I.: “Emergence of „Ba“ – a conceptual

framework for the continuous and self-transcending process of knowledge creation”, in: Nonaka, Nishiguchi: “Knowledge Emergence – Social, Rechnical and Evolutionary Dimensions of Knowledge creation”, Oxford University Press, 2001.

[Nutt, 1996] Nutt, G.: “The evolution towards flexible workflow

systems”, Distributed Systems Engineering Journal, Special Issue On Workflow Systems, 1996.

O [Oberweis, 1994] Oberweis. A.: “Modellierung und Ausführung von

Workflows mit Petri-Netzen”, Teubner-Reihe. Wirtschaftinformatik (Teubner Verlag), 1994.

[Odgen et al., 1923] Odgen, C.K., Richards, I.A.: “The Meaning of Meaning:

A Study of the Influence of Language upon Thought and of Science of Symbolism”, Routledge & Kegan Paul Ltd., London, 1923.

[OMG, 2000] Object Management Group (OMG): “Unifed modeling

language specification”, version 1.4, 2000.

P [Palmer, 1996] Palmer, N.: “Business process simulation and modeling:

An introduction and survey of tools”, Enterprise Reengineering, 1996.

237

[Petrash, 1996] Petrash, G.: “Managing Knowledge Assets for Value”, in Knowledge-Based Leadership Conference, Boston, 1996.

[Pettigrew, 1985] Pettigrew, A.M.: “The Awakening Giant”, Blackwell

Publishers, Oxford, UK, 1985. [Plesums, 2002] Plesums, C.: “Introduction to Workflow”, Computer

Sciences Corporation, Financial Services Group, Workflow Management Coalition, WfMC, 2002.

[Polanyi, 1958] Polanyi, M.: “Personal knowledge – towards a post-

critical philosophy”, London, 1958. [Polanyi, 1967] Polanyi, M.: “The tacit dimension”, New York, 1967. [Polanyi, 1974] Polanyi, M.: “Personal Knowledge”, University of

Chicago Press, Chicago, 1974. [Prax, 2000] Prax J.Y.: “Le guide du Knowledge management :

concepts et pratiques du management de la connaissance”, Edition Dunod, 2000.

[Prosci, 2005] http://www.prosci.com/reengineering.htm [PMI, 2000] PMI, Project Management Institute: “A Guide to the

Project Management Body Of Knowledge”, Project Management Institute, USA, 2000.

[Probst, 1998] Probst, G.: “Practical Knowledge Management”, in:

Prism, Arthur D Little, Second Quarter http://know.unige.ch/publications/Prismartikel.pdf

[Prudhomme et al., 2001] Prudhomme G., Boujut J.F., Pourroy F.: “Activités de

conception et instrumentation de la dynamique des connaissances locales”, Ingénierie des Connaissances, Plate-forme AFIA, Presses Universitaires de Grenoble, pp. 41-60, 2001.

Q [Quigley et al., 1999] Quigley, E.J., Debons, A.: “Interrogative theory of

information and knowledge”, in proceedings of SIGCPR '99. New Orleans: ACM Press, 1999

238

R [Rajapakse, 1996] Rajapakse: “On Conceptual Workflow Specification and

Verification”, PhD Thesis, Department of Computer Science, The University of Queensland, Australia, 1996.

[Reh, 2006] Reh, F.J.: “Key Performance Indicators (KPI)”, online

magazine About, The New York Times Company, 2006. http://management.about.com/cs/generalmanagement/a/ke

yperfindic.htm [Reichert et al., 1998] Reichert, Dadam: “ADEPTflex - Supporting dynamic

changes of workflow without loosing control”, in Journal of Intelligent Information Systems (JIIS), Special Issue on Workflow and Process Management, volume 10, number 2, pp. 93-129, 1998.

[Reix, 1995] Reix R.: “Savoir tacites et savoir formalisés dans

l’entreprise”, in revue francaise de gestion, les sciences de gestion et les savoir de l’entreprise, 1995.

[Rheinhardt, 2004] Rheinhardt: “Wissenskommunikation in Organisationen –

Methoden, Instrumente, Theorien“, Springer Verlag Berlin Heidelberg New York, 2004, ISBN 3-540-20350-8

[Rinderle et al, 2004] Rinderle, Reichert, Dadam: “Flexible support of team

processes by adaptive workflow systems”, in Distributed and Parallel Databases 16, 2004.

[Reimer et al., 2003] Reimer, U., Abecker, A., Staab, S., Stumme, G.:

“Professionelles Wissensmanagement - Erfahrungen und Visionen”, volume 28 of GI-Edition Lecture Notes in Informatics (LNI), Luzern, Switzerland, Gesellschaft fuer Informatik (GI), 2003.

[Romhardt, 1998] Romhardt, K.: “Die Organisation aus der

Wissensperspektive – Möglichkeiten und Grenzen der Intervention”, Gabler, 1998.

[Ryan, 2005] Ryan, D.P.: “Content Document and Knowledge

Management”, Volume 14, Number 1, 2005. http://www.kmworld.com/publications/magazine/index.cfm?action=readarticle&Article_ID=1979&Publication_ID=125

239

S [Sadiq et al., 1997] Sadiq, W., Orlowska, M.E.: “On correctness issues in

conceptual modeling of workflows”, in proceedings of the 5th European Conference on Information Systems (ECIS ‘97), Cork, Ireland, 1997.

[Sadiq et al., 1999] Sadiq, W. and Orlowska, M.E: “On capturing process

requirements of workflow based information systems”, in Proceedings of the 3rd International Conference on Business Information Systems (BIS ‘99), Poznan, Poland, pp. 281-294. Springer-Verlag, 1999.

[Salton, 1992] Salton, G.: “The state of retrieval system evaluation”, in

Information Processing and Management, vol 28, 1992. [Schnauffer, 2004] Schnauffer: Preface in „Wissen vernetzen“, Springer

Verlag Berlin Heidelberg New York, 2004, ISBN 3-540-21349-X

[Schneider, 1996] Schneider, U.: “Management in der wissensbasierten

Unternehmung”, pages 13-48, 1996. [Schnurr, 2001] Schnurr, H.-P., Staab, S., Studer, R., Stumme, G., Sure,

Y.: “Die Bedeutung von Ontologien für das Wissensmanagement”, in proceedings of the 1st National Conference “Professionelles Wissensmanagement - Erfahrungen und Visionen (WM2001)”, Berichte aus der Informatik, Aachen. Shaker Verlag, 2001.

[Schütt, 2004] Schütt, P.: “Wie das Cynefin-Modll entstand”, Revue

Wissensmanagement, Büro für Medien Verlag, Augsburg, vol. 02, 2004.

[Schreiber, 1999] Schreiber, G., Akkermans, H., Anjewierden, A., de Hoog, R., Shadbolt, N., van de Velde, W., Wielinga, B.: “Knowledge Engineering and Management, the CommonKADS Methodology”, the MIT Press, Cambridge, Massachusetts; London, England, 1999.

[Sena et al., 1999] Sena, J. A., Shani, A.B.: “Intellectual Capital and

Knowledge Creation: Towards an Alternative Framework”, in: Jay Liebowitz. (Edited by). Knowledge Management Handbook. CRC Press, 1999.

[Sevcik, 2002] Sevick, P.: from the July 2002 issue of Business

Communications Review, Westmont, Illinois, 2002.

240

[Simon, 1997] Simon, G.: “Modèles et méthodes pour la conception des mémoires d’entreprise. Le système DOLMEN: une application en métallurgie”, thèse de Doctorat, 1997.

[Snowden, 2004] Snowden, D. The cynefin Model,

http://www.gurteen.com/ [Soënen et al., 2002] Soënen, R., Perrin, J.: “Coopération et Connaissances

dans les systèmes industriels”, Hermès Science Publications, 2002.

[Spek et al., 1997] Spek, Spijkevert: “Entwicklung und Technologie”,

Spektrum der Wissenschaft, 1997. [Staab et al., 2003] Staab, S., Studer, R., Sure, Y.: “Knowledge Processes and

Meta Processes in Ontology-based Knowledge Management”, in C. Holsapple (ed.), Handbook on Knowledge Management. International Handbooks on Information Systems, pp. 47-68. Springer Verlag, 2003.

[Standish Group, 1995] Standish Group: “Chaos (Application Project Failure and

Success)”, The Standish Group International, 1995. [Studer, 2003] Studer R.: “Wissensmanagement - support of knowledge

management by the information technology” study cours at Universität Karlsruhe (TH), 1997-2003.

[Suchman, 1983] Suchman L. A.: “Office procedure as practical action:

models of work and system design”, ACM TOIS, 1983. [Suchman, 1987] Suchman, L.A.: ”Plans and Situated Actions: The Problem

of Human Machine Communication”, Cambridge University Press, 1987.

[Szulanski, 1996] Szulanski, G.: “Exploring Internal Stickiness:

Impediments to the transfer of Best Practice within the Firm”, Strategic Management Journal, 1996.

[Sure et al., 2002] Sure, Y., Erdmann, M., Angele, J., Staab, S., Studer, R.,

Wenke, D.: “OntoEdit: Collaborative ontology development for the semantic web”, in [Horrocks et al., 2002].

[Sure, 2003] Sure, Y.: “Methodology, Tools & Case Studies for

ontology based Knowledge Management”, PhD Dissertation, Universität Karlsruhe, 2003.

241

T [Tague-Sutcliffe, 1995] Tague-Sutcliffe, J.: “Measuring information: an

information services perspectives”, Academic Press, 1995. [Tarondeau, 1998] Tarondeau, J.-C.: “Le management des saviors”, puf

édition, Paris, 1998. [Tersine, 2005] Tersine, R., Open University,

http://www.ou.edu/class/tersine [Tiwana, 2002] Tiwana, A.: “The Knowledge management toolkit:

orchestrating IT, Strategy, and knowledge platforms”, 2nd ed., 2002.

[Turbit, 2005] Turbit, N.: “Business Analysis using “Method H”, white-

paper”, 2005, http://www.projectperfect.com.au/downloads/info_method_h.pdf

V [Vance, 1997] Vance, D. M.: “Information, Knowledge and Wisdom: The

Epistemic Hierarchy and Computer-Based Information System”, in proceedings of the 1997 America’s Conference on Information Systems, 1997.

[Van der Aalst et al., 2000] Van der Aalst, W.M.P., Jablonski, S.: “Dealing with

wokflow change: identification of issues and solutions”, in Computer System Science and Engineering pages 267-276, CRL Publishing Ltd, 2000.

[Vinck, 1995] Vinck, D.: “Sociologie des Sciences”, Armand Colin

Editeur, Paris, 1995. [Vinck et al., 1996] Vinck, D., Jeantet, A. and Laureillard, P.: “Objects and

Other Intermediaries in the Sociotechnical Process of Product Design: an exploratory approach”, pp. 297-320. In: J. Perrin and D. Vinck (Eds.), “The role of design in the shaping of technology”, vol. 5, COST A4 Social Sciences, Bruxelles: EC Directorate General Science R&D, 1996.

242

[Vinck, 1997] Vinck D.: “La connaissance : ses objets et ses institutions”, chapitre 3 dans [Fouet, 1997], 1997.

W [Wainer et al., 1996] Wainer, J., Weske, M., Vossen, G.M., Bauzer Medeiros,

C.M.: “Scientific workflow systems”, in proceedings of NSF Workshop on Workflow and Process Automation, 1996. http://wwwmath.uni-muenster.de/~dbis/Weske/papers/wwvm96.html

[Wanda et al., 1997] Wanda J., Orlikowski, K. and Hofman, J.D.: “An

Improvisational Model of Change Management: The Case of Groupware Technologies”, Sloan Management Review, 1997.

[Wenger et al., 2002] Wenger, E., McDermott, R., Snyder, W.M.: “Cultivating

Communities of Practice”, Harvard Business School Press, Cambridge, MA, 2002.

[Wiig, 1993] Wiig, K.M.: “Knowledge Management Foundations”,

Schema Press, Arlington, 1993. [Wiig, 1997] Wiig, K., “Knowledge Management: Where Did It Come

Form and Where Will It Go?”, Expert Systems with Applications, vol. 14, Pergamom Press/Elsevier, 1997.

[Wikipedia, 2006a] http://en.wikipedia.org/wiki/Knowledge, july 2006. [Wikipedia, 2006b] http://en.wikipedia.org/wiki/Knowledge_management,

july 2006. [Wikipedia, 2006c] http://en.wikipedia.org/wiki/Business_process, july 2006. [WfMC, 1996] Workflow Management Coalition: “A Workflow

Management Coalition Specification”, November, 1994. http://www.wfmc.org/

[WfMC, 2005] Workflow Management Coalition: “Terminology &

Glossary”, 2005 http://www.aiai.ed.ac.uk/WfMC/DOCS/glossary/glossary.html

243

[Wunram et al., 2002] Wunram, M., Weber, F., Pawar, K S., Gupta, A.: “Proposition of a Human-centred Solution Framework for KM in the Concurrent Enterprise”, in Pawar, K., Weber, F., Thoben, K.-D., (Eds.). in proceedings of the 8th International Conference on Concurrent Enterprising - Ubiquitous Engineering in the Collaborative Economy, Rome, Italy, pp. 151 – 158, 2002.

Z [Zacklad et al., 2001] Zacklad, M., Grundstein, M.: “Ingénierie et capitalisation

des connaissances”, Collection Informatique et systèmes d’information, Hermès Science Publications, 2001.

[Zhao, 1998] Zhao: “Knowledge management and organizational

learning in workflow systems” in proceedings of the fourth Americas conference on information systems, pages 647-649. Association for Information Systems, 1998.

Please note: The cited URLs were provided by the author in all conscience. However, even though “cool URIs don't change” (cf. [Berners-Lee, 1998]), URIs in the dynamic surrounding of the WWW (typically referred to as URLs [Berners-Lee, 1993]) and the content they represent are subject to change. In future they might differ from the cited sources in this work.

245

Glossary

A Action A package of functions within a procedure or process is

considered as action. Area Engineering area: department at STM that is in charge to

configure the machines for the production process, especially for new innovative production conditions.

B BPM Business Process management, notion used as signification

for a software tool or the process analyzing. In this work, the notion does reference on the tool and on the conception process. See definitions chapter III.

Business Process A collection of related, structured actions -a chain of

actions- that produce a specific service or product for a particular customer or customers. See definitions chapter III

C CAD Computer Aided Design - Software and hardware tools that

allow graphic design. It assists in the design of a product and in the verification of its performance by simulation.

Chip Electronic equipment consisting of a small crystal of a

silicon semiconductor fabricated to carry out a number of electronic functions in an integrated circuit.

Circuit An electrical device that provides a path for electrical

current to flow integrated circuit. Clean room Controlled environment where integrated circuits are

fabricated. This place is specially constructed to control the air flow, temperature, and humidity in such a way that

246

constant filtration keeps contamination below some predetermined level and temperature and humidity within predetermined limits.

Concurrent Engineering The development through cross-functional teams; also

called Simultaneous Engineering.

D DECT Digital European Cordless Telecommunications. European

standard for digital cordless connection to the telecommunications network (intern cordless telephone system at STM).

Decision Tree A graphical representation of all possible outcomes and the

paths by which they may be reached; often used in classification actions. The top layer consists of input nodes (e.g., meteorological observations and data). Decision nodes determine the order of progression through the graph. The leaves of the tree are all possible outcomes or classifications, while the root is the final outcome (for example, a weather prediction or climate classification).

DER Defectivity Experiment Request – experiment process in

order to investigate for problem analyzing of defaults occurred during the fabrication process.

DYE Device and Yield Engineering – department at STM to

industrialize and optimize the technology fabrication processes.

E ECN Engineering Change Notice – software Tool at STM to

initiate changes of fabrication processes and set it as new standard. (an engineer describes the change to implement and proof its validity. Different manager of concerned departments have to validate the impacts of this change to their responsible parts of the fabrication process).

247

Eight disciplines-8D Eight disciplines Problem Solving – 8D Problem Solving Process is used to identify, correct and eliminate the recurrence of quality problems.

EMA Experiment Management Application – tool to manage the

experiment processes. This tool is the industrial result of this work, based on the PIFA approach, chapter V.

Experiment Non-standard fabrication of a lot. During the fabrication of

a lot according to its fabrication route, the lot will be processed differently from its defined route. Therefore, at a specific operation, the fabrication condition like machine, recipes will change and the lot is processed manually.

Experiment Process also called SWR - Special Work Request – Experiment

Process at STM consisting in preparing and executing a Split to industrialize technology fabrication processes.

F Fabrication condition Configuration parameters for the fabrication process (like

i.e. temperature, pressure, etc.) often formalized as condition for a recipe of an operation for a specific machine.

Fabrication process In semiconductor manufacturing, fabrication process

usually refers to the manufacturing of making devices in semiconductor wafers, but usually does not include the package assembly stages.

Fabrication recipe A recipe is a set of instructions that show how to prepare or

make something, i.e. a culinary dish. In the microelectronic domain, a recipe refers to the specific configuration for a machine for a specific context (lot, technology, etc.).

Fabrication route Defined execution of the fabrication process. A route

contains the sequence of operations. The sequence could contain up to 214 different operations. The fabrication takes in average 7 weeks.

Functionality Notion referring to the execution of functions in order to

execute an action. An action can group different functionalities for the same owner in a business process, see chapter III & IV.

248

H Hold A temporary stoppage at an operation during the fabrication.

The lot will stopped at a defined operation and the fabrication won’t continue until further notice.

I Integrated circuit Formal name for a die, or a chip. Its name resulted from the

integration of previously separate transistors, resistors and capacitors, all on a single chip.

Intranet portal A private computer network that uses the same technology

as the Internet. IT Information Technology: the branch of engineering that

deals with the use of computers and telecommunications to retrieve and store and transmit information.

K Knowledge Management Knowledge Management: approaches to improve the

capitalization, diffusion and reuse of knowledge. See definitions Chapter III.

KMS Knowledge Management System: system that supports

Knowledge Management activities. IT is often part of the system, but employees culture and work methodologies are also very important as well as the knowledge that’s should be managed through the system. See definitions Chapter III.

L LDAP LDAP is a protocol that provides an online, fully indexed,

fast-access white pages directory service developed and freely distributed by the University of Michigan. It is

249

especially used for accessing information directories such as addresses, phone numbers, etc.

Lot English: Batch, A number of wafers processed as a group.

The French translation is used even in English expressions at STM.

Lot fabrication processing of a lot on a machine in order to produce

microelectronic circuits. Lot scrap A decision statement that a product that does not comply

with the legal, statutory, contractual, technical requirement etc., cannot be used or recovered after reworking and must be destroyed.

M Machine A human-made system that performs actions. In this

context, physical actions in the microelectronic fabrication production chain. The machines are physically located in the clean room. The MES contains the information of positions of the lots, their fabrication route and manage the fabrication.

Memory A general term for computer hardware that holds

information in electrical or magnetic form. Meta-Crawler A meta crawler is a component of a search engine that

gathers listings by automatically “crawling“ the meta-data (annotations). Crawlers are also called spider or robot.

MES Manufacturing Execution System; the system for execution

management. Microchip Electronic equipment consisting of a small crystal of a

silicon semiconductor fabricated to carry out a number of electronic functions in an integrated circuit.

Microelectronic Miniature electronic components. Microelectronic circuit An electrical device that provides a path for electrical

current to flow integrated circuit. Microelectronic product A specific integrated circuit corresponding to specific

client’ need.

250

O Operation In this context: An operation is an elementary action in the

manufacturing process associated with one or more machines, recipes, fabrication routes. A fabrication route contains 214 operations.

Operator In this context, an operator is an employee in the clean

room who is in charge to treat the lot at an operation. He is specialized for a specific machines and area.

P PIFA Process Information Functionality Analysis. Scientific

result of this work: An approach to integrate Knowledge Management into Business Processes, see chapter IV.

Process A structured order of actions; distinguish definitions of

Business Process in chapter III and fabrication process. Process conditions Configuration for the fabrication process that refers to

specific recipes, a machine and an operation. Process route Defined execution of the fabrication process. A route


Project.net Web-based project management tool to design project plans

and associate actions to person, real-time monitoring of process execution.

R R&D Research and Development. Raw material A good that has not been transformed by production; a

primary product used in the fabrication process to build an integrated circuit.

Recipe A set of instructions that shows how to prepare or make

something, i.e. a culinary dish. In the microelectronic

251

domain, a recipe refers to the specific configuration for a machine for a specific context (lot, technology, etc).

Role A role or social role (in sociology) is a set of connected

behaviors, rights and obligations as conceptualized by actors in a social situation. It is mostly defined as an expected behavior in a given individual social status and social position. In this context, the notion role is used as requirement of competences to execute a action in a workflow.

Route Defined execution of the fabrication process. A route


S Scrap A decision statement that a product that does not comply

with the legal, statutory, contractual, technical requirement etc., cannot be used or recovered after reworking and must be destroyed.

Self-organizing map (SOM) is a method for unsupervised learning, based on a grid of

artificial neurons whose weights are adapted to match input vectors in a training set. It was first described by the Finnish professor Teuvo Kohonen and is thus sometimes referred to as a Kohonen map.

Semi-conductor The type of material such as silicon whose electrical

conductivity is between that of a conductor and that of an insulator - in being nearly as great as that of a metal at high temperatures and nearly absent at low temperatures. These unusual properties are exploited to produce transistors and electronic devices.

Speed The rate of motion, or equivalently the rate of change of

position, expressed as distance d moved per unit of time t. In this context, used a microelectronic speed: Time at which the integrated circuit operates.

Split A term used in the semiconductor production to break up or

divide a lot (batch). Split Matrix Matrix to define how the lot (batch) will be splitted.

252

STM STMicroelectronics – leading microelectronic company –

fusion between SGS Microelectronica and Thompson Microelectronics, founded in 1987.

SWR Special Work Request – Experiment Process at STM

consisting in preparing and executing a Split.

T Technology In STM’s context, it means manufacturing process. Technology generation A technology fabrication core process referring to the

transistor size that represents the basis of the development for clients’ specific products and similar technology processes.

Technological platform Notion referring to the technology generation and all

existing similar fabrication processes and associated products. The notion Technology generation includes the core process (technology platform) and designs of the different products based on the core fabrication process.

Transistor An active semiconductor device with three electrodes that

may be either an amplifier or a switch. TRIZ Methodology to use complex technical problems (see

reading plan).

W Wafer A wafer of virgin silicon sliced from a 4, 5, 6, 8 or 12 inch

diameter silicon bar (2.54 cm is equal to 1 inch), which is used as the foundation to build semiconductor products on.

WMS Workflow Management System: IT tool to support the

execution of business processes.

Abstract: Today, the microelectronic industry is faced with considerable challenges to renew its products and to make production outputs more reliable. For this reason, experiments in new manufacturing processes are essential and must take into account the vulnerability of used procedures. Knowledge produced during the execution of experiments constitutes an invaluable element of productivity. However, formalism is missing for the process and knowledge management of these successive experiments. In particular, an experiment’s return of experience, an exchange between processes and a capitalization of knowledge in time to initiate a later reuse are all primary success factors to increase the experiment productivity, but are often badly understood and insufficiently supported. Knowledge Management is not integrated into the experiment process management, and a reuse of existing experiments or an information centralization for a process is difficult to achieve. Consequently, this thesis proposes a new analysis method, called PIFA (Process, Information, Functionality, Analyze), for the management of knowledge and processes. This method is composed of three levels: The Process level helps to capture the process flow (dependencies between actions), the Information level helps in capturing the information flow to improve the information sharing within a process and between processes, and the Functionality level guarantees that the involved actor has an immediate surplus value and will accept the changes implemented in the introduction of a new work methodology, such as higher information capitalization. In this work, the PIFA approach was applied in the context of experiment processes at STMicroelectronics. Based on the results, an IT-Tool (EMA – Experiment Management Application) was designed in order to support the execution of these processes, capitalize produced knowledge during the execution, and initiate knowledge reuse. After a test phase, the tool was deployed in June and it is currently used by 300 employees.

Keywords : Knowledge Management, Business Process Management, Change Management, Information Retrieval

Résumé : L’industrie microélectronique fait face aujourd’hui à des défis considérables pour renouveler ses gammes de produits et fiabiliser les rendements de sa production. À ce titre, les essais de nouveaux processus de fabrication sont incontournables compte tenu de la sensibilité des procédés utilisés. Les connaissances issues des essais constituent donc de précieux éléments de productivité. Or, la gestion des connaissances et des processus d’essais eux-mêmes pêche par son absence de formalisme. En particulier, un retour d’expérience des essais, un échange entre des processus et une capitalisation des connaissances dans le temps pour initier une réutilisation ultérieure sont des facteurs primordiaux de succès pour augmenter la productivité des essais, mais sont souvent mal compris et peu soutenus : la gestion d’information n’est pas intégrée dans la gestion des essais et par conséquence une réutilisation de l’existant ainsi qu’une centralisation des informations pour un processus d’essai est difficilement possible. Cette thèse propose une nouvelle méthode d’analyse, appelée PIFA (Processus, Information, Fonctionnalité, Analyse), pour analyser et combiner les besoins de la gestion de connaissances et de processus dans le but de l’optimiser. Cette méthode se compose de trois parties : La partie Processus aide à capturer les dépendances entre des actions. La partie Information permet de détecter et d’améliorer le flux d’information intra et inter processus. Enfin, la partie Fonctionnalité analyse le besoin des acteurs impliqués et garantit qu’ils aient une valeur ajoutée immédiate. Ceci facilite la conduite des changements causés par l’introduction d’une nouvelle méthode de travail, comme par exemple une capitalisation plus élevée de l'information. Dans ce travail, l'approche PIFA a été appliquée aux processus d'essais chez STMicroelectronics. Basé sur ses résultats, un outil informatique (EMA – Experiment Management Application) a été conçu afin de soutenir et optimiser l'exécution de ces processus : capitaliser les connaissances produites pendant l'exécution et initier ses réutilisations. Après une phase d’essai, l'outil a été déployé en juin 2006, il est actuellement utilisé par 300 employés. Mots-clés : Management de connaissances, gestion de processus, conduite de changement, recherche d’information

Laboratoire GILCO (Gestion Industrielle, Logistique et COnception)

46, avenue Félix Viallet, F-38000 Grenoble, France