Information Technology Reference
In-Depth Information
Engineering) in Kaiserslautern and Fraunhofer AIS (Autonomous Intelligent Systems)
in Sankt Augustin.
The indiGo methods and tools add value through the speed-up of innovation cycles
by involving a greater number of people and recording more information on processes
in the form of discourses. In addition, they improve the construction of organizational
knowledge through the preparation, moderation, and analysis of discourses supported
by text mining and case-based reasoning. Current approaches to experience
management are reinforced by providing a solution to integrate results of discourses
into the experience base, a repository for business experiences.
The final indiGo technical infrastructure will consist of the Zeno® groupware tool
of AIS, IESE's experience management environment INTERESTS, IESE's tool for
process modeling and publishing Spearmint, as well as tools for text mining of
discourses from AIS.
Both the developed methods and the indiGo architecture will be evaluated mid
2002 within a case study on process learning carried out at IESE. First results will be
available in fall 2002.
In Chapters 3 and 4 we introduce the indiGo methodology and platform,
respectively. Chapter 3 also includes a detailed process-learning example to
exemplify the indiGo approach. Chapter 4 is also concerned with putting indiGo into
context. For this, a terminological framework is presented in Chapter 2 and, based on
this, the relevant state of the art is described. We then classify indiGo according to the
framework. Finally, we give a short outlook on planned activities.
2
indiGo - The Framework
indiGo's key objective is to create and sustain living process models, that is, process
models that are accepted by the organizations members, adapted to organizational
changes on demand, and continuously enriched with experience from the operating
business of the organization. Process learning requires at least four different kinds of
knowledge in an organization: Process models (with their associated templates),
experiences from instantiating process models in concrete projects, discussions about
processes in closed or open groups, and private annotations of process models.
For example, assume Ms. Legrelle, a team leader in the organization, has to
compose an offer for a subcontract from a small start-up. The process model for the
acquisition of industrial projects has a subprocess devoted to the contract. It suggests
that the payment scheme should not be too fine-grained in order to minimize
administrative overhead. Ms. Legrelle feels uncomfortable with this guideline. The
year before she had had a subcontract with another start-up, Hydra, which got
bankrupt, so that the last payment was lost for her team although they had completed
the work. Ms. Legrelle prefers to design the new offer with a frequent payment
schedule, at the cost of more overhead in the administrative unit.
Clearly, Ms. Legrelle would not like to modify the organization's process model
(1) for industrial project acquisition on her own - it is not her job and her view may be
too subjective. She would probably agree that her experience with the Hydra project
be recorded as a lesson to be learned, but even so, she would hardly take the trouble to
