Evaluation und Evaluationsforschung in der Wirtschaftsinformatik: Handbuch für Praxis, Lehre und Forschung [Reprint 2018 ed.] 9783486801101, 9783486251753

Citation preview

Evaluation und Evaluationsforschung in der Wirtschaftsinformatik Handbuch für Praxis, Lehre und Forschung

Herausgegeben von

Lutz J. Heinrich und

Irene Häntschel Mit-Herausgeber: Ulrich Frank Markus Gappmaier Werner Mellis Anton J. van Reeken Mohsen Rezagholi Gerhard A. Wührer

R. Oldenbourg Verlag München Wien

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Evaluation und Evaluationsforschung in der Wirtschaftsinformatik : Handbuch fìir Praxis, Lehre und Forschung / hrsg. von Lutz J. Heinrich und Irene Häntschel. Mit-Hrsg.: Ulrich Frank ... - München ; Wien : Oldenbourg, 2000 ISBN 3-486-25175-9

© 2000 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 145, D-81671 München Telefon: (089)45051-0, Internet: http://www.oldenbourg.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Gedruckt auf säure- und chlorfreiem Papier Gesamtherstellung: Druckhaus „Thomas Müntzer" GmbH, Bad Langensalza ISBN 3-486-25175-9

Vorwort Das Handbuch richtet sich an Praktiker, an Lehrende und Lernende und an Forscher an Universitäten und Fachhochschulen. Gemeinsamer Nenner der Adressaten in Praxis, Lehre und Forschung ist ihr Interesse an verwertbaren Erkenntnissen zur systematischen Ermittlung des Wertes von Konzepten, Entwürfen, Produkten, Prozessen, Dienstleistungen usw., kurz gesagt ihr Interesse an der Evaluation oder Evaluierung von prinzipiell beliebigen, der Wirtschaftsinformatik zuzurechnenden Objekten. Die Erarbeitung derartiger Erkenntnisse ist primäre Aufgabe der Evaluationsforschung in der Wirtschaftsinformatik. Art und Umfang der Evaluationsaufgaben nehmen in der Praxis aus verschiedenen Gründen zu. Der Informatik-Markt ist durch eine große Vielfalt an Produkten und Dienstleistungen gekennzeichnet, so daß rationales Auswählen von Alternativen und Entscheiden über Alternativen erforderlich sind. Rationales Auswählen und Entscheiden erfordern Evaluation. Der Druck auf die in den Unternehmen für den Technologieeinsatz Verantwortlichen, bei Technologieeinsatz-Entscheidungen systematisch vorzugehen, wird auch deshalb zunehmen, weil die Bedeutung des Technologieeinsatzes für den Unternehmenserfolg weiter wächst. Wirtschaftsinformatik ist eine relativ junge, praxisorientierte Wissenschaft. Zu ihren vordringlichen Aufgaben gehört es, der Praxis bei der Lösung von Evaluationsproblemen behilflich zu sein. Dies kann in erster Linie dadurch erfolgen, daß sie der Praxis Verfahren (Vorgehensmodelle, Methoden, Techniken usw.) und Werkzeuge zum Evaluieren zur Verfügung stellt. Das Entwickeln und Erproben dieser Verfahren und Werkzeuge gehört zur Gestaltungsaufgabe der Wirtschaftsinformatik. Langfristig gesehen erfordert die Bewältigung der Gestaltungsaufgabe auch Beiträge der Wirtschaftsinformatik zur Bewältigung ihrer Erklärungsaufgabe, d.h. der Modell- und Theorieentwicklung. Ohne theoretische Aussagen über die Objekte, für die ein Evaluationsbedarf besteht, kann die Wirtschaftsinformatik ihre Gestaltungsaufgabe nicht nachhaltig lösen. Wirtschaftsinformatik als Wissenschaft ist aber auch selbst Evaluationsobjekt, wobei nicht nur Forschungsergebnisse und Zwischenergebnisse, sondern auch der wirtschaftsinformatorische Forschungsprozeß von Interesse ist. Neben Wirtschaftsinformatik-Praxis und -Forschung gewinnt die wissenschaftliche Lehre als Evaluationsobjekt zunehmend an Bedeutung (z.B. in Österreich gem. § 18 Abs. (4) Universitätsorganisationsgesetz 1993, seit dem Studienjahr 1997/98 verbindlich). Bei der Evaluation der Wirtschaftsinformatik-Lehre sind nicht nur einzelne Lehrveranstaltungen von Interesse, sondern auch Lehrprogramme und Studiengänge (wie das Diplomstudium der Wirtschaftsinformatik). Die Besonderheiten der Evaluation von Wirtschaftsinformatik-Lehre ergeben sich vor allem aus der Unterschiedlichkeit der Lehrmethoden gegenüber anderen Studiengängen an Sozial- und Wirtschaftswissenschaftlichen Fakultäten und einschlägigen Studiengängen an Fachhochschulen.

2

Vorwort

Evaluationsforschung gilt in den USA seit Jahrzehnten als wissenschaftliche Disziplin mit großer praktischer Bedeutung, die sich insbesondere im Zusammenhang mit der Notwendigkeit der Beurteilung sozialer Programme entwickelt hat. In Europa beginnt sie sich erst jetzt zu etablieren. Es ist wenig wahrscheinlich, daß der Entwicklungsprozeß top-down verlaufen wird, also von einer disziplinübergreifenden Evaluationsforschung in die verschiedenen Wissenschaftsbereiche und von dort in Forschung, Lehre und Praxis vordringt. Treiber der Ausbreitung der Evaluationsforschung werden vielmehr die Evaluationsprobleme der Praxis sein, wenn sie von den einzelnen wissenschaftlichen Disziplinen aufgegriffen werden und so die disziplinspezifische Evaluationsforschung stimulieren. Von den Einzeldisziplinen ausgehend kann sich eine disziplinübergreifende Evaluationsforschung entwickeln. Die Wirtschaftsinformatik sollte dabei eine Vorreiterrolle übernehmen, was mit der erwähnten Bedeutung von Evaluation zur Lösung praktischer Wirtschaftsinformatik-Probleme und der Häufigkeit dieser Probleme begründet ist. Dieses Handbuch stellt Praktikern, Lehrenden und Lernenden und Forschern umfangreiches Material zur Verfügung, nicht nur durch die einzelnen Beiträge, sondern auch durch umfassende Literaturverweise. Praktiker finden Hilfe bei der Lösung von konkreten Evaluationsproblemen in ihren Unternehmen. Lehrenden und Lernenden wird erstmals eine einschlägige Stoffsammlung zur Verfügung gestellt, die als Textbuch im Lehrbetrieb verwendet werden kann. Forscher können sich über den Stand der Evaluationsforschung informieren, erhalten Anregungen zur Entwicklung von Evaluationsverfahren und finden Hilfen zur Evaluation ihrer Forschungsprozesse und Forschungsergebnisse. Die beiden Herausgeber danken den Mit-Herausgebern und den Autoren f ü r die gute Zusammenarbeit. Sie danken dem Verlag für sein Interesse an dieser ersten einschlägigen Publikation im deutschsprachigen Raum. Dank gilt auch den Teilnehmern des Workshops „Evaluation und Evaluationsforschung in der Wirtschaftsinformatik", der am 5. Juni 1998 auf unsere Einladung hin an der Universität Linz stattfand. Sie haben der an diesem Tag entstandenen Idee, ein Handbuch gleichen Titels herauszugeben, die ersten Konturen gegeben. Nicht zuletzt gilt ihr Dank Frau Dr. Erika Heinrich und Frau Sigrid Schenk, die durch aufwendige Detailarbeit allen Beiträgen und dem Gesamtwerk den letzten Schliff gegeben haben. Lutz J. Heinrich, Irene Häntschel

Inhaltsverzeichnis Kapitel I Anspruch und Stand der Forschung Lutz J. Heinrich (Universität Linz) Bedeutung von Evaluation und Evaluationsforschung in der Wirtschaftsinformatik

7

Harald Schmidt / Irene Häntschel (Universität Linz / ADMETΆ GmbH, Linz) Verbreitung von Evaluation und Evaluationsforschung in der Wirtschaftsinformatik 23 Ulrich Frank (Universität Koblenz-Landau) Evaluation von Artefakten in der Wirtschaftsinformatik Kapitel II Informationssysteme

als

Anton J. van Reeken (Universität Einführung und Grundlegung

35

Evaluationsobjekt Maastricht) 49

Lutz J. Heinrich / Irene Häntschel / Gustav Pomberger (Universität Linz / ADMETA GmbH, Linz / Universität Diagnose der Informationsverarbeitung

Linz) 59

Alexander Teubner / Jahn Rentmeister / Stefan Klein (Universität Münster) IT-Fitness für das 21. Jahrhundert Konzeption eines Evaluationsinstruments

75

Anton J. van Reeken (Universität Maastricht) WITIG - Eine Methode zur Evaluation von Informationssystemen

93

Kapitel III Geschäfts-

und Managementprozesse

als

Markus Gappmaier (Brigham Young University, Einführung und Grundlegung

Evaluationsobjekt Provo/Utah) 107

Thomas Müllner (Universität Linz) Methoden und Metriken für die Evaluation von Geschäftsprozessen

117

Alfred Gerstmayr (Steyr Daimler Puch AG Antriebstechnik, Entwicklung von Erfolgskenngrößen für Geschäftsprozesse

133

Ernest Wallmüller (Qualität & Informatik, Evaluation von Managementprozessen

Steyr)

Zürich) 145

4

Inhaltsverzeichnis

Kapitel IV Software-Entwicklungsprozesse als Evaluationsobjekt Mohsen Rezagholi (Siemens AG München) Einführung und Grundlegung

159

Karl Lebsanft (Siemens AG München) Das Siemens Process Assessment

175

Gerhard Chroust / Paul Grünbacher / Fritz Stallinger (Universität Linz) Christian Steinmann (HM&S GmbH, Graz) Evaluation des Software-Entwicklungsprozesses in kleinen SoftwareUnternehmen 189 Lutz J• Heinrich / Gustav Pomberger (Universität Linz) Prototypingbasierte Evaluation von Software-Angeboten Kapitel V Technologien

als

201

Evaluationsobjekt

Gerhard A. Wührer (Universität Einführung und Grundlegung

Linz) 213

Mohsen Rezagholi /Michael Frey (Siemens AG München) Evaluation der Technologieanwendung und des Technologiemanagements

221

Gustav Pomberger (Universität Linz) / Mohsen Rezagholi / Christine Stobbe (Siemens AG München) Evaluation und Verbesserung wiederverwendungsorientierter Software-Entwicklung

233

Christiane Gresse von Wangenheim / Barbara Hoisl/ H. Dieter Rombach / Günther Ruhe (Fraunhofer-Einrichtung für Experimentelles Software Engineering, Kaiserslautern) Zielorientiertes Messen und Bewerten zur Software-Qualitätsverbesserung - Eine Kosten/Nutzen-Analyse

253

Kapitel VI Produkte und Dienstleistungen

als

Evaluationsobjekt

Lutz J. Heinrich (Universität Linz) Einführung und Grundlegung

267

Franz Schweiggert (Universität Ulm) Qualitätsbezogene Evaluation von Software-Produkten

283

Markus Schallaböck (Rosenbauer International AG, Leonding) Evaluation von Standardsoftware-Produkten

299

Henrik Lewe (IBM Deutschland Informationssysteme Evaluation computerunterstützter Teamarbeit

GmbH,

Heidelberg) 313

Inhaltsverzeichnis

5

Lutz J. Heinrich / Irene Häntschel ( Universität Linz / ADMET A GmbH, Linz) Messen des Erfolgs des Benutzer-Service 323 Kapitel VII Modelle als Evaluationsobjekt Ulrich Frank (Universität Koblenz-Landau) Einführung und Grundlegung

339

Danielle C. Fowler (Swinburne University, Hawthorn)/ Paul A. Swatman (Deakin University, Burwood) Evaluation von Methoden des Requirements Engineering

353

Reinhard Schütte (Universität Essen) Evaluation von Informationsmodellen

367

Kapitel Vili Lehre als Evaluationsobjekt Werner Mellis (Universität zu Köln) Einführung und Grundlegung

383

Georg Herzwurm (Universität zu Köln) Messung der Studierendenzufriedenheit

395

Christian Stary (Universität Linz) Evaluation von Bildungsveranstaltungen im universitären Lehrbetrieb....411 Manfred Butz (Deutsche Telekom AG, Bonn) Evaluationsverfahren in der betrieblichen Weiterbildung im IT- und TK-Bereich

423

Herausgeber, Mit-Herausgeber und Autoren

439

Schlagwortverzeichnis

443

Bedeutung von Evaluation und Evaluationsforschung in der Wirtschaftsinformatik Lutz J. Heinrich [email protected]

Institut für Wirtschaftsinformatik der Universität Linz www.winie.uni-linz.ac.at

„Denn was man messen kann, das existiert auch. " M a x Planck

Inhalt 1 2 3 4 5

Problem Evaluation und Wirtschaftsinformatik-Praxis Evaluation in der Wirtschaftsinformatik-Forschung Evaluationsforschung in der Wirtschaftsinformatik Evaluation und Wirtschaftsinformatik-Lehre

Zusammenfassung Es wird zunächst das Problem dargestellt, um dessen Bearbeitung es in diesem Beitrag geht. Es wird dann die Frage beantwortet, wie Bedeutung im vorliegenden Zusammenhang zu interpretieren, insbesondere wie diese Bezeichnung zu präzisieren ist. Anschließend wird die Frage beantwortet, welche Bedeutung Evaluation in der Wirtschaftsinformatik-Praxis hat. Davon ausgehend wird ihre Bedeutung für die Wirtschaftsinformatik-Forschung herausgearbeitet, wobei zwischen Evaluation in der Wirtschaftsinformatik-Forschung und Evaluationsforschung in der Wirtschaftsinformatik unterschieden wird. Ersteres meint Evaluation als Forschungsaufgabe, das zweite meint Beschreibung, Erklärung, Prognose und Gestaltung von Evaluationsprozessen, um Evaluation in Forschung und Praxis durchführen zu können. Abschließend wird auf die Bedeutung der Evaluation für die Wirtschaftsinformatik-Lehre eingegangen.

Abstract This article treats some questions concerning the importance of evaluation in IS practice, research and teaching. In IS practice, the importance can be expressed as the contribution of IS decision making quality to business success. This contribution is considerable with an improving tendency. For Business Informatics (BI) as a real science, this statement leads to the conclusion that scientific contributions which help to solve evaluation problems in practice are necessary to achieve the research objectives of this discipline. To meet the increasing requirements of the labor market, BI students' qualification profile should be added by evaluation know-how.

8

Lutz J.

Heinrich

1 Problem Wenn in diesem Beitrag von der Bedeutung von Evaluation und Evaluationsforschung in der Wirtschaftschaftsinformatik gesprochen wird, dann ist damit deren Wichtigkeit, Stellenwert oder Beitrag zur Erreichung des Forschungsziels bzw. - angesichts des Charakters der Wirtschaftsinformatik als Interdisziplin - der Forschungsziele der Wirtschaftsinformatik gemeint. Das aus den Sozial- und Wirtschaftswissenschaften stammende Forschungsziel der Wirtschaftsinformatik ist es, Wirklichkeit zu beschreiben und zu erklären, um auf der Grundlage der Erklärung Prognosen über Veränderungen der Wirklichkeit machen zu können. Das aus den Technikwissenschaften (insbesondere aus der Praktischen Informatik) stammende Forschungsziel der Wirtschaftsinformatik ist es, Wirklichkeit durch Gestalten, d.h. durch Schaffen neuer realer Dinge, zu verändern (vgl. [Hein93,74f.]). Aus Sicht der Wirtschaftsinformatik als Wissenschaft bezeichnet Wirklichkeit Informationssysteme und Informationsinfrastrukturen in (Unternehmen der) Wirtschaft und Verwaltung, mit anderen Worten: Gegenstand der Wirtschaftsinformatik sind real existierende Informationssysteme und Informationsinfrastrukturen in Wirtschaft und Verwaltung. Wirtschaftsinformatik wird also primär als Realwissenschaft oder empirische Wissenschaft angesehen, die sich mit den Phänomenen der Wirklichkeit in Wirtschaft und Verwaltung befaßt, die als Informationssystem und Informationsinfrastruktur bezeichnet werden (vgl. [Hein93,171f.]). „Primär als Realwissenschaft" soll heißen, daß andere Einflüsse (z.B. formalwissenschaftliche Einflüsse aus der Mathematik, verhaltenswissenschaftliche Einflüsse aus der Soziologie) nicht ausgeschlossen, aber nicht von gleich großer Bedeutung sind. Wirtschaftsinformatik ist aber nicht nur primär Realwissenschaft, sie ist auch explizit praxisorientiert. Das heißt, sie befaßt sich mit den Phänomenen von Informationssystemen und Informationsinfrastrukturen, deren Lösung f ü r die Erreichung der Unternehmensziele (kurz: für den Unternehmenserfolg) wesentlich ist. Von diesen Überlegungen ausgehend, werden in Bezug auf Evaluation und Evaluationsforschung drei Fragen formuliert: 1. Welche Bedeutung hat Evaluation für die Wirtschaftsinformatik-Praxis? Mit anderen Worten: Welchen Stellenwert nach Art und Umfang hat die Lösung von Evaluationsproblemen für den Unternehmenserfolg? 2. Welche Bedeutung hat Evaluation für die Wirtschaftsinformatik-Forschung und welche Bedeutung hat Evaluationsforschung in der Wirtschaftsinformatik? Mit anderen Worten: Welchen Stellenwert nach Art und Umfang haben Evaluation und Evaluationsforschung zur Erreichung der Forschungsziele der Wirtschaftsinformatik? 3. Welche Bedeutung hat Evaluation für die Wirtschaftsinformatik-Lehre? Anders ausgedrückt: Welchen Stellenwert haben Lehrveranstaltungen mit einschlägigen Lehrinhalten in Wirtschaftsinformatik-Studienplänen, um eine angemessene Berufsqualifikation zu erreichen?

Bedeutung von Evaluation und Evaluationsforschung

9

Bei der Interpretation und Beantwortung dieser Fragen wird Evaluation als die Aufgabe verstanden, zur Lösung eines bestimmten Problems definierte Objekte auf der Grundlage eines Systems von Kriterien zielbezogen zu beurteilen. Genereller drückt dies [Albe87,161] wie folgt aus: Zweck von Evaluation ist es, in einer bestimmten „Problemsituation auf der Grundlage sachlicher Merkmale im Hinblick auf die in der betreffenden Praxis angestrebten Ziele ... die in Betracht kommenden Alternativen entsprechend zu ordnen und so eine Stellungnahme zu ermöglichen, die zu einer Entscheidung führt. Sie sind ein wesentlicher Bestandteil der Willensbildung." Evaluation soll methodisch erfolgen, auf einem System von Regeln aufbauen und intersubjektiv nachvollziehbar sein. Dies heißt, daß beim Evaluieren nach einem Arbeitplan vorgegangen wird, nach dem - von einer bestimmten Problemsituation ausgehend - folgende Teilaufgaben zu bearbeiten sind: • • • • • • • •

Festlegen der Evaluationsobjekte Formulieren des Evaluationsziels Ableiten der Evaluationskriterien Gewichten der Evaluationskriterien Abbilden der Evaluationskriterien in Metriken Auswählen von Meßmethoden Durchführen der Messungen Auswerten der Meßdaten

Evaluationsobjekte sind Prozesse (z.B. Geschäftsprozeß, Konstruktionsprozeß für Informationssysteme, Software-Entwicklungsprozeß) und Ergebnisse von Prozessen (z.B. Technologien, Produkte, Dienstleistungen). Zweck der Evaluation von Prozessen ist primär Qualitätsverbesserung als Aufgabe des Prozeßmanagements; das Evaluationsproblem heißt also Qualitätsmangel oder vermuteter Qualitätsmangel. Wird beispielsweise Evaluation in den Konstruktionsprozeß für Informationssysteme eingebunden, kann die Erfolgswahrscheinlichkeit des Projekts erhöht werden, weil aufgrund der Evaluationsergebnisse Kurskorrekturen möglich sind. Evaluation ist dann eine konstruktive Maßnahmen des Qualitätsmanagements. (Wegen Einzelheiten zum Qualitätsmangement und seinen Aufgaben vgl. [Hein99,141f.].) Zweck der Evaluation von Prozeßergebnissen ist primär Informationsgewinnung für Technologieeinsatz-Entscheidungen (und damit für Investitionsentscheidungen) bzw. zur Überprüfung von Investitionsentscheidungen. Beides ist Aufgabe des Technologiemanagements, das ex ante Entscheidungsunsicherheit reduzieren, ex post Entscheidungen rechtfertigen bzw. die Ursachen für Fehlentscheidungen transparent machen soll. (Wegen Einzelheiten zum Technologiemangement und seinen Aufgaben vgl. [Hein99,155f.].)

2 Evaluation und Wirtschaftsinformatik-Praxis Die Evaluation von Prozessen und Prozeßergebnissen ist wesentlicher Bestandteil zahlreicher Aufgaben des Informationsmanagements. In der Wirtschaftsinformatik-Praxis wird bei diesen Aufgaben nur selten von Eva-

10

Lutz J. Heinrich

luation gesprochen; diese Bezeichnung beginnt sich erst seit den 90er Jahren durchzusetzen. Was manche Wirtschaftsinformatiker nicht sehen oder übersehen ist, daß Handeln in der Wirtschaftsinformatik-Praxis zu einem erheblichen Teil darin besteht, zu evaluieren. Wenn beispielsweise ein Informationsmanager versucht, einem Linienmanager die Funktionsweise einer Technologie zu erklären, dieser aber einwendet, daß die Erklärung unbefriedigend sei, dann wird die Erklärung anhand bestimmter Kriterien beurteilt. Oder: Es wird ein Experiment durchgeführt, und der Auftraggeber wendet bei Präsentation der Ergebnisse ein, daß die verwendeten Meßmethoden nicht valid seien; dann wird das Experiment anhand von Kriterien für ein gutes Experiment beurteilt. Kriterium kann hier mit Evaluationskriterium und beurteilt mit evaluiert gleichgesetzt werden. Diese Feststellung beantwortet noch nicht die Frage, ob Evaluation für die Wirtschaftsinformatik-Praxis eine der Voraussetzungen dafür ist, daß Unternehmensziele besser erreicht werden als ohne Evaluation. Realistisch erscheinende Annahmen dafür, daß eine solche Aussage zutreffend ist, sind: • Die Durchdringung der Unternehmen mit IuK-Technologie setzt sich fort. • Es besteht eine unmittelbare Verbindung („link") zwischen IuK-Technologie und Unternehmenserfolg. • Der Einfluß der IuK-Technologie auf die Erreichung der Unternehmensziele nimmt zu. • Fehler bei Technologieeinsatz-Entscheidungen wirken sich zunehmend negativ auf die Erreichung der Unternehmensziele aus. • Investitionen in IuK-Technologien konkurrieren mit anderen Investitionsvorhaben, so daß präzisere Nachweise über die Auswirkung von IuKInvestitionen verlangt werden. Aus diesen Gründen kann geschlossen werden, daß die Bedeutung von Evaluation für den Unternehmenserfolg in Zukunft eher zunehmen als abnehmen wird, denn nichts deutet beispielsweise darauf hin, daß die Durchdringung der Unternehmen mit IuK-Technologie abnehmen wird; das Gegenteil wird der Fall sein. Eine präzisere Vorstellung über die bestehende und die zunehmende Abhängigkeit zwischen Evaluation und Unternehmenserfolg kann an typischen Evaluationsproblemen bzw. Evaluationsobjekten abgelesen werden, beispielsweise: • Beim Prototyping müssen Zwischenprodukte im Konstruktionsprozeß f ü r Informationssysteme (Prototypen) zuverlässig beurteilt werden. • Im Konstruktionsprozeß verwendete Methoden, Techniken und Werkzeuge müssen bestimmten Qualitätsforderungen entsprechen. • Bei zunehmender Alternativenmenge muß zwischen verfügbaren bzw. angebotenen Produkten und Dienstleistungen ausgewählt werden.

Bedeutung von Evaluation und Evaluationsforschung

1¡

3 Evaluation in der Wirtschaftsinformatik-Forschung Mit Wirtschaftsinformatik-Forschung werden zwei Aufgaben angesprochen, und zwar die Aufgabe der Wirtschaftsinformatik, eigene Forschungsprozesse und Forschungsergebnisse zu evaluieren, und die Aufgabe, durch Evaluation Information für Technologieeinsatz-Entscheidungen zu erarbeiten. Die erste Aufgabe wird an anderer Stelle in diesem Handbuch bearbeitet (vgl. Kapitel VII), so daß im folgenden nur auf die zweite Aufgabe eingegangen wird. Dabei sind zwei Aktionsfelder zu berücksichtigen, nämlich Auftragsforschung und auftragsfreie Forschung. Sie unterscheiden sich im wesentlichen durch den Umfang der Fremdbestimmung der Forschungsarbeit. Auftragsforschung meint, daß Anbieter oder (meist potentielle) Anwender einem Forschungsinstitut den Auftrag erteilen, bestimmte Objekte zu evaluieren. Der Auftraggeber hat ein Evaluationsproblem, er benennt die Evaluationsobjekte (und stellt sie gegebenenfalls dem Auftragnehmer zur Verfügung) und formuliert (gegebenenfalls gemeinsam mit dem Auftragnehmer) das Evaluationsziel. Gegebenenfalls nimmt der Auftraggeber auch auf die Evaluationskriterien Einfluß. Die Evaluationsergebnisse werden dem Auftraggeber präsentiert und honoriert. Ihre Verwertung für wissenschaftliche Veröffentlichungen - eventuell in anonymisierter Form - ist dabei häufig vereinbart. Auftragsfreie Forschung meint, daß sich die Forscher für ein Evaluationsproblem entscheiden, das in der Wirtschaftsinformatik meist ein wesentliches Praxisproblem sein wird. Sie führen die gesamte Evaluationsstudie ohne jeden externen Einfluß durch. Evaluation im Wissenschaftsbetrieb erfordert - mehr noch als Evaluation in der Praxis - die Verfügbarkeit von Evaluationsverfahren, die zielorientiertes, systematisches Evaluieren ermöglichen. Evaluation ist daher auf Ergebnisse der Evaluationsforschung (vgl. weiter unten) angewiesen; solange Ergebnisse nicht oder nicht ausreichend zur Verfügung stehen, muß in jedem einzelnen Evaluationsprojekt aufwendige . Entwicklungsarbeit für Evaluationsverfahren geleistet werden. Wenn dies unterbleibt, muß der Forschungsprozeß als nicht-wissenschaftlich, möglicherweise als unwisssenschaftlich bezeichnet werden; die Arbeitsergebnisse sind dann wissenschaftlich wertlos. Welche Forschungsmethode für wissenschaftliche Evaluationsprojekte gewählt wird, hängt von mehreren Einflußfaktoren ab, in erster Linie von der Zugänglichkeit der Evaluationsobjekte. Da Informationsgewinnung für Technologieeinsatz-Entscheidungen zur Verbesserung von Prozeß- und/oder Produktqualität primärer Zweck von Evaluation ist, kommt Feldforschung meist nicht in Betracht. Nur wenige, meist - bezüglich Zeitbedarf und Kosten sehr aufwendige Projekte sind bekannt geworden, in denen Anbieter und Anwender Feldversuche mit wissenschaftlicher Begleituntersuchung vereinbart und durchgeführt haben (z.B. bei Workflow-Management-Systemen). Aufgrund dieser Situation eröffnet sich für Laborforschung ein weites Anwendungsfeld, das bislang von der Wirtschaftsinformatik kaum genutzt wird.

Ì2

Lutz J.

Heinrich

4 Evaluationsforschung in der Wirtschaftsinformatik Mit Evaluationsforschung wird eine - in Ansätzen - seit den 30er Jahren bekannte, seit den 70er Jahren (insbesondere in den USA) etablierte wissenschaftliche Disziplin bezeichnet, die durch explizite Verwendung wissenschaftlicher Forschungsmethoden mit dem Zweck der Evaluation beliebiger Objekte gekennzeichnet ist (nach [Such67], zur Entwicklung der Evaluationsforschung vgl. [Daum93,703]). Evaluationsforschung betont die Möglichkeit des Beweises anstelle der Behauptung bezüglich des Wertes eines bestimmten Objekts (Handlung, Prozeß, Projekt, Produkt usw.)· Die Objekte sind dadurch charakterisiert, daß sie ein hohes Maß an Veränderung bewirken können (z.B. Neue Technologien). Die Besonderheiten der Evaluationsforschung werden bislang nicht disziplinübergreifend mit dem Ziel diskutiert, Evaluationsverfahren zu entwickeln, die in verschiedenen Disziplinen gleichermaßen genutzt werden können. So kann die Wirtschaftsinformatik, was Evaluation betrifft, von Vorhandenem nur geringen Gebrauch machen. Was Evaluationsforschung in der Wirtschaftsinformatik ist bzw. sein sollte, kann mit den Wissenschaftsaufgaben Beschreibung, Erklärung, Prognose und Gestaltung erläutert werden (nach [Hein85,26f.], vgl. auch [Hein93,73f.]). • Beschreibungsaufgabe meint das Erfassen, Systematisieren und Dokumentieren von Evaluationsprozessen so, wie sie in der Praxis beobachtet, und so, wie sie von Forschern konstruiert werden. • Erklärungsaufgabe meint das Untersuchen von Evaluationsprozessen mit dem Ziel, Aussagen darüber zu machen, warum ein Sachverhalt so ist, wie er aufgetreten ist und wie er beobachtet bzw. konstruiert wurde. • Prognoseaufgabe meint, mit vorhandenen Erklärungen über Evaluationsprozesse Aussagen darüber zu machen, wie sich ein Sachverhalt verändern wird, wenn bestimmte Handlungen erfolgen oder unterlassen werden. • Gestaltungsaufgabe meint, auf Grundlage der verfügbaren Kenntnisse über Evaluationsprozesse Evaluationsverfahren zu entwickeln und zu erproben, mit denen die Abwicklung von Evaluationsprozessen in der Praxis unterstützt bzw. ermöglicht wird. Obwohl systematische Wirtschaftsinformatik-Forschung in der genannten Reihenfolge vorgehen sollte, weil Nichtbeschriebenes nicht oder schlechter als Beschriebenes erklärt, Nichterklärtes nicht oder nur ungenau prognostiziert sowie Nichterklärtes und Nichtprognostiziertes nicht oder nur unvollkommen gestaltet werden kann, steht heute (noch) die Gestaltungsaufgabe im Vordergrund des wissenschaftlichen Interesses. Im folgenden wird daher auf alle wissenschaftlichen Aufgaben der Evaluationsforschung eingegangen.

Bedeutung von Evaluation

und Evaluationsforschung

13

4 . 1 Beschreibungsaufgabe In einer empirischen Wissenschaft heißt Beschreibung, daß in der Wirklichkeit Beobachtetes systematisiert und dokumentiert wird. Ergebnis dieser Tätigkeit sind Beschreibungsmodelle, d.h. vereinfachte Abbilder der Wirklichkeit, wobei Wirklichkeit die in der Praxis beobachtbaren Evaluationsprozesse sind. Wirtschaftsinformatik ist aber nicht nur empirische Wissenschaft, so daß auch Vorbilder für Evaluationsprozesse Gegenstand der Beschreibungsaufgabe sind. Beide, Abbilder und Vorbilder, sind Modelle von Evaluationsprozessen. Modelle sind für die Bewältigung der wissenschaftlichen Aufgaben umso wichtiger, je weniger die Wirklichkeit für die Forschung unmittelbar zugänglich ist (z.B. weil Evaluationsprozesse nicht beobachtbar, nur aus Dokumenten rekonstruierbar oder nicht vorhanden sind). Beispiele für Beschreibungsmodelle der Evaluationsforschung sind Ex-ante-Evaluation / Ex-post-Evaluation und formale Evaluation / informale Evaluation. Ex-ante-Evaluation beschreibt Evaluationsprozesse zur Informationsgewinnung für zu fällende Technologieeinsatz-Entscheidungen. Die besondere Problematik dieser Evaluationsprozesse besteht darin, daß häufig Technologien evaluiert werden müssen, über deren Eigenschaften erst relativ wenig bekannt ist. Ex-post-Evaluation beschreibt Evaluationsprozesse, mit denen Information zur Überprüfung von Technologieeinsatz-Entscheidungen erarbeitet wird, insbesondere zur Beantwortung der Frage, in welchem Ausmaß die bei der Ex-ante-Evaluation verwendeten Ziele erreicht wurden und was die Ursachen für Zielabweichungen sind. Information über Abweichungsursachen geht in die Bedarfsplanung ein. Ex-post-Evaluation soll nach einem angemessenen Zeitraum, in der Regel mehrere Monate nach Nutzungsbeginn, erfolgen. Ex-ante- und Ex-post-Evaluation sind keine Alternativen, sie ergänzen sich. [MiDu97] haben mit einer in Großbritannien durchgeführten Feldstudie (schriftliche Befragung, Ν = 150, Rücklaufquote 22%, Befragungszeitraum 2+3/1996) festgestellt, daß Ex-post-Evaluation weniger Bedeutung beigemessen wird als Ex-ante-Evaluation. 61% der Befragten sagten, daß das Ausmaß, in dem Ex-post-Evaluation in ihren Unternehmen durchgeführt wird, zu gering ist. Formale Evaluation beschreibt Evaluationsprozesse, die nach vorgegebenen Regeln aus bestimmten Anlässen bestimmte Objekte evaluieren, und zwar nach einem vorgegebenen Evaluationsverfahren. Im allgemeinen regelt ein Vorgehensmodell für Informatik-Projekte das Vorgehen bei der Evaluation, einschließlich Evaluationsverfahren. Unter Beachtung der Regeln des Vorgehensmodells legt die Projektplanung im einzelnen fest, daß an bestimmten Terminen bestimmte Objekte zu evaluieren sind. Das Vorgehensmodell sollte explizit vorsehen, daß eine Situation entstehen kann, in der vom Evaluationsverfahren mit dokumentierter Begründung abgewichen werden kann.

14

Lutz. J.

Heinrich

Mit informaler Evaluation ist das gemeint, was Informationsmanager, Projektleiter, Projektmitarbeiter usw. laufend und ohne Plan tun, nämlich Entscheidungen zwischen Alternativen auf Grund von (subjektiven) Urteilen über den Wert dieser Alternativen zu fällen. Meist handelt es sich um operative Evaluationsprobleme, die situativ zu lösen sind, so daß die Vorgabe von Evaluationsverfahren - wenn überhaupt möglich - nicht zweckmäßig ist. 4.2 Erklärungsaufgabe Beschreibungsmodelle sind für die Wirtschaftsinformatik kein Selbstzweck, sondern Mittel zum Zweck, nämlich zur Erklärung. Aus dem durch Beschreibung an Erkenntnis Vorhandenen werden Hypothesen formuliert, d.h. auf wissenschaftlicher Erkenntnis beruhende Annahmen über die Beziehungen zwischen zwei oder mehreren Variablen. Zur Erklärung und Begründung bestehender Erkenntnis und/oder zur Gewinnung neuer Erkenntnis wird versucht, Hypothesen durch wissenschaftliche Untersuchungen zu verwerfen (Falsifizierung). Durch Falsifizierungsversuche bestätigte Hypothesen führen zu Erklärungsmodellen oder Theorien bzw. ergänzen Theorien. Eine Hypothese lautet beispielsweise: Wenn formale Evaluation als konstruktive QM-Maßnahme verwendet wird, dann erhöht sich die Wahrscheinlichkeit des Projekterfolgs bzw. verringert sich die Wahrscheinlichkeit eines Projektnotstands. So einsichtig diese Hypothese auch ist, zur Erklärung kann sie nur wenig beitragen, wie Fragen der folgenden Art zeigen: In welchem Ausmaß ist formale Evaluation erforderlich? Mit welchem Aufwand soll sie betrieben werden? Unter welchen Voraussetzungen besteht zwischen Evaluationsaufwand und Projektnutzen ein Gleichgewicht? Um Fragen dieser Art zu beantworten, müssen Evaluationsprozesse wissenschaftlich untersucht werden. Das Untersuchen kann anhand der in der Praxis beobachtbaren Evaluationsprozesse durch Feldforschung und anhand „künstlicher" Evaluationsprozesse durch Laborforschung erfolgen. Da Evaluationsprozesse in der Praxis kaum direkt zu beobachten sind, ist Feldforschung in erster Linie auf Befragung und - falls Dokumente vorhanden sind - auf Dokumentenanalyse angewiesen. Dies sind sehr schwache, insbesondere unzuverlässige Instrumente, so daß einiges für Laborforschung spricht, vor allem für die Verwendung von Simulationsmodellen. 4.3 Prognoseaufgabe Bei Prognosen werden unabhängige Variable eines Erklärungsmodells durch konkrete, in der Praxis ausführbare Maßnahmen ersetzt, und abhängige Variable werden zu bestimmten, für die Praxis relevanten Eigenschaften eines Systems. Wenn beispielsweise auf Grund vorhandener Erklärung behauptet wird, daß die Verwendung formaler Evaluation die Wahrscheinlichkeit des Projekterfolgs erhöht, dann kann eine praktische Maßnahme darin bestehen, in das Vorgehensmodell für Informatik-Projekte Evaluationsverfahren einzubauen, die dafür sorgen, daß bestimmte Entscheidungen

Bedeutung von Evaluation und Evaluationsforschung

15

nur unter der Voraussetzung definierter Ergebnisse der Evaluation gefällt werden dürfen. Das Beispiel zeigt, daß die Prognose primär wissenschaftliche Aufgabe in der Weise ist, die Verwendbarkeit von Erklärungsmodellen und Theorien in der Praxis nachzuweisen und damit wissenschaftliche Erklärungen für praktisches Handeln nutzbar zu machen. Prognosen sind aber auch Voraussetzung dafür, Evaluationsverfahren zu entwickeln. Für das praktische Handeln an Informationssystemen ist die Genauigkeit der Vorhersagen von entscheidender Bedeutung. Die Praxis muß sich darauf verlassen können, daß die Prognosen (im wesentlichen) zutreffen. Dies kann nur zugesichert werden, wenn die Prognosen empirisch überprüft werden. Manche Wirtschaftsinformatiker sind der Meinung, daß empirische Uberprüfung überflüssig ist. [Snel98] vermutet, daß die Verweigerer empirischer Überprüfung weniger die Theoretiker, sondern mehr die praxisorientierten Wissenschaftler sind (genauer gesagt: die Nicht-Wissenschaftler), die Theorie ignorieren und sich der empirischen Überprüfung entziehen („Macher"). Da experimentelle Falsifizierungsversuche sehr lange dauern können (eventuell Jahre, wenn sie im Feld erfolgen), kann nicht verlangt werden, daß mit jeder Prognose der Falsifizierungsversuch gleich „mitgeliefert" wird. Zum Zwecke von Prognosen müssen aber bestimmte Annahmen, aus denen die Prognosen abgeleitet werden, als begründet akzeptiert sein. Diese Annahmen können aber noch ungeprüft sein, einer empirischen Überprüfungen also noch bedürfen. Es kann aber auch sein, daß eine Überprüfung deshalb überflüssig ist, weil sie zum allgemein akzeptierten Hintergrundwissen gehört, die Prognosen also so einsichtig sind, daß sie „jedermann" nachvollziehen kann 4 . 4 Gestaltungsaufgabe Gestaltung heißt, Evaluationsverfahren entwickeln und erproben, mit denen die Abwicklung von Evaluationsprozessen in der Praxis unterstützt oder erst ermöglicht wird. (Die Bezeichnungen Evaluationsverfahren und Evaluationsmethode werden synonym verwendet.) Man kann auch sagen: Ein Evaluationsverfahren ist ein Vorgehensmodell zur Lösung von Evaluationsproblemen, mit dem die Frage „Wie wird evaluiert?" konkret beantwortet wird. Die in der Fachliteratur angebotenen Evaluationsverfahren sind meist objektspezifisch (z.B. für Workflow-Management-Systeme, für Kommunikationssysteme wie Intranets, für Entscheidungsunterstützungssysteme). Autoren behaupten oft, eine „Methodologie der Evaluation" anzubieten, meinen damit jedoch lediglich objektspezifische Evaluationsverfahren (z.B. [MaBr98,80p.] mit einer so genannten Intranet Evaluation Methodology). Von einer Methodologie oder Methodik im wissenschaftstheoretischen Sinn als Lehre von den Methoden (der Evaluation in der Wirtschaftsinformatik) und ihrer planmäßigen Anwendung kann dabei nicht die Rede sein. Auch sind bislang keine erkennbaren Versuche unternommen worden, die zahlreichen Methoden zu einer Methodik zusammenzuführen. (Vgl. zu den Methoden z.B. [BrRe98]

16

Lutz J.

Heinrich

und die Proceedings der vier vorangegangenen Konferenzen.) [Bann98,l] zitiert zwei Autoren, die 60 bzw. 160 verschiedene Evaluationsmethoden identifiziert haben wollen! Dies scheint ein Hinweis darauf zu sein, daß sich Wirtschaftsinformatik-Forschung primär mit der Gestaltungsaufgabe befaßt, und zwar ohne über ausreichende Kenntnisse über Evaluationsprozesse zu verfügen. Im folgenden wird der Konstruktionsprozeß für Evaluationsverfahren anhand der in Abschnitt 1 angegebenen Struktur der Aufgabe, Evaluationsprobleme zu lösen, gezeigt. Jede der genannten Tätigkeiten ist - in unterschiedlich starkem Ausmaß - Gegenstand wirtschaftsinformatorischer Evaluationsforschung. (Die Tätigkeiten „Durchführen der Messungen" und „Auswerten der Meßdaten" werden deshalb nicht behandelt.) Es wird unterstellt, daß ein Evaluationsproblem gegeben ist, das für Prozesse mit „Verbesserung von Prozeßqualität" und für Produkte mit „Reduzierung von Entscheidungsunsicherheit" für Technologieeinsatz-Entscheidungen bezeichnet wird. Festlegen der Evaluationsobjekte Dabei handelt es sich primär um eine praktische Frage, da prinzipiell jedes Phänomen der Wirtschaftsinformatik Evaluationsobjekt sein kann („alles ist evaluierbar"). Gegenstand wissenschaftlicher Überlegungen ist aber die Frage, welcher Zusammenhang zwischen dem Evaluationsproblem und den zur Lösung dieses Problems erforderlichen Evaluationsobjekten besteht. Eine wissenschaftlich begründete Antwort darauf - etwa in Form einer Vorgehensweise zum Identifizieren von den Evaluationsobjekten, die zur Lösung eines bestimmten Evaluationsproblems erforderlich sind - ist bisher nicht gegeben worden. Für eine bestimmte Evaluationsstudie kann das Festlegen der Evaluationsobjekte problemlos sein oder nicht als Problem empfunden werden (vor allem dann, wenn der Auftraggeber dem Evaluator die Evaluationsobjekte vorgibt). Für den Auftraggeber besteht dann ein Risiko, wenn das Evaluationsproblem in der Ermittlung der optimalen Alternative besteht und diese außerhalb der untersuchten Alternativenmenge liegt. (So wie bei der Nutzwertanalyse, vgl. [Zang76].) Erkenntnisse der Wirtschaftsinformatik-Forschung, die zur Reduzierung dieses Risikos beitragen, sind daher erwünscht. Festlegen des Evaluationsziels Für das Festlegen des Evaluationsziels ist prinzipiell der Auftraggeber einer Evaluationsstudie zuständig. Er bestimmt, warum evaluiert wird, und er leitet dies in der Regel daraus ab, welches Problem das Evaluationsergebnis lösen oder zu lösen helfen soll. Das Evaluationsziel gibt zusammenfassend an, welche Information der Auftraggeber erwartet bzw. welche der Evaluator erarbeiten soll. Die Bezeichnung Evaluation weist darauf hin, daß es generelles Ziel jeder Evaluationsstudie ist, den Wert (value) eines Objekts oder einer Menge von Objekten zu ermitteln. Was „Wert" zur Lösung eines bestimmten Evaluationsproblems bedeutet, muß durch das Evalutionsziel präzisiert werden. Für die Wirtschaftsinfor-

Bedeutung von Evaluation

und Evaluationsforschung

17

matik-Forschung mit ihrem spezifischen Erkenntnisobjekt Informationssysteme und Informationsinfrastrukturen muß „Wert" wohl generell als die Fähigkeit eines Objekts definiert werden, Unternehmenserfolg zu verbessern (so z.B. [Park89]), m.a.W. der Beitrag des Objekts zur Erreichung der Unternehmensziele. [Wise92] unterscheidet ausdrücklich zwischen „value" und „benefits" (auch im Original im Plural) und behauptet, daß value umfassender und wichtiger sei. [Keen91,162] stellt resignierend fest: „Many ... has tried to devise a reliable approach to measuring the business value of IT at the level of the firm, non has succeeded." [Bann98,4] faßt die zahlreichen Definitionsversuche für value mit den Worten zusammen: „It is clear ... that the definition of value is far from universally agreed." Einen Eindruck über die Intensität, mit der an der Frage gearbeitet wurde und vermutlich noch immer wird, vermitteln die Ergebnisse einer von [Yola98] durchgeführten Literaturanalyse. Danach befassen sich 17% der Artikel der Stichprobe der Zeitschrift Information Systems Research mit „IT value directly or indirectly". Es gibt Evaluationsverfahren (z.B. das der ITSEF 1 ), die explizit auf ein bestimmtes Evaluationsziel (im Beispiel Sicherheit) an bestimmten Objekten (im Beispiel Systeme der Informationstechnik) ausgerichtet sind. Das Evaluationsproblem besteht dann beispielsweise darin, die Voraussetzung für eine Zertifizierung von bestimmten Systemen zu schaffen. In mehreren vom Autor et al. durchgeführten Evaluationsstudien, die zur Deckung des Informationsbedarfs des Top-Managements über den Zustand der Informationsverarbeitung durchgeführt wurden, bestand des Evaluationsproblem in der Bestimmung der strategischen Schlagkraft der Informationsverarbeitung (vgl. den Beitrag „Diagnose der Informationsverarbeitung"). Ableiten der Evaluationskriterien Evaluationskriterien sind Eigenschaften eines Evaluationsobjekts, die unter Berücksichtigung des Evaluationsziels aus diesem abgeleitet werden. Mit ihnen wird im einzelnen festgelegt, was evaluiert wird. Der direkte Zusammenhang („link") zwischen Evaluationsziel und Untemehmenserfolg, der weiter oben gefordert wurde, besteht daher auch zwischen jedem einzelnen Evaluationskriterium und dem Untemehmenserfolg. Sind mehrere alternative Objekte zu evaluieren, werden nur Eigenschaften als Evaluationskriterien verwendet, deren Ausprägungen (Kriterienerträge) als signifikant voneinander abweichend eingeschätzt werden, da Eigenschaften etwa gleicher Kriterienerträge zur Optimumbestimmung nicht beitragen. Aus methodischer Sicht unterscheiden sich Evaluationskriterien vor allem nach dem Ermittlungsaufwand für die Kriterienerträge. Bei einer Evaluationsstudie liegen in der Regel Evaluationskriterien vor,

1 I T S E F ist ein A k r o n y m f ü r I n f o r m a t i o n T e c h n o l o g y S e c u r i t y E v a l u a t i o n F a c i l i t y , e i n e akkreditierte S t e l l e f ü r die E v a l u a t i o n d e r S i c h e r h e i t von S y s t e m e n der I n f o r m a t i o n s t e c h n i k .

18

Lutz J-

Heinrich

• für die das Ermitteln der Kriterienerträge unproblematisch ist, sowie Evaluationskriterien, • für die das Ermitteln der Kriterienerträge die Entwicklung und Anwendung aufwendiger Meßmethoden erfordert. Beim Ableiten der Evaluationskriterien ist auch zu berücksichtigen, welche Personen bzw. Personengruppen Nachfrager nach Evaluationsinformation sind bzw. Evaluationsinformation nachfragen sollten (z.B. der InformatikLenkungsausschuß, die Projektleitung oder das Linienmanagement). Bei gleichem Evaluationsproblem und gleichen Evaluationsobjekten können diese Gruppen unterschiedliche Evaluationsinteressen haben, so daß Evaluationsinformation unterschiedlich sein muß. Dies erfordert im allgemeinen unterschiedliche Evaluationskriterien. [Adel92,7] drückt dies so aus: „What one user might consider to be a critical criterion, another might fail to mention. ... As a result, the identification of evaluation criteria is often a forgotten step early in the ... development process. This can be disastrous, for the development team would be without its guide posts for defining success." Daß in wissenschaftlichen Veröffentlichungen relativ häufig über Evaluationskriterien berichtet wird, deutet darauf hin, daß diese Aufgabe nicht nur von praktischem Interesse ist, sondern auch wissenschaftlich ertragreich sein kann. Meist wird darüber im Zusammenhang mit bestimmten Evaluationsprojekten, nicht aber über das Ableiten von Evaluationskriterien als wissenschaftliche Aufgabe an sich berichtet, wie folgende Beispiele zeigen. • [Lust89] entwickelte einen Katalog von Evaluationskriterien für das Evaluationsobjekt Datenbanksysteme. • [BeHe92] entwickelten einen Katalog von Evaluationskriterien für das Evaluationsobjekt PC-gestützte Software-Entwicklungsumgebungen. • [OpRe92] entwickelten einen Katalog von Evaluationskriterien für die Evaluation der ergonomischen Qualität von Benutzerschnittstellen und ein darauf aufbauendes Werkzeug. Es gibt aber Ausnahmen, über die insbesondere in der angelsächsichen Literatur berichtet wird (z.B. bei [Park89]). Die vorgeschlagenen Evaluationskriterien, mit denen primär strategische Informatik-Projekte evaluiert werden, können prinzipiell zur Evaluation jeder Art von IuK-Technologie verwendet werden; der „link" zwischen Projekt und Unternehmenserfolg wird durch die verwendeten Evaluationskriterien explizit hergestellt. Gewichten der Evaluationskriterien Evaluationskriterien haben für die Ermittlung des Wertes eines Evaluationsobjekts in der Regel eine unterschiedlich große Bedeutung. Deshalb werden sie mit Kriteriengewichten belegt, mit anderen Worten: es wird eine Präferenzordnung der Evaluationskriterien hergestellt. Deren Anwendung bewirkt, daß im Objektwert die Kriterienerträge mit unterschiedlichem Gewicht berücksichtigt werden. Verfahren zur Herstellung der Präferenzordnung sind bekannt; Forschungsbedarf der Wirtschaftsinformatik besteht hier nicht. Häufig wird die Methode der sukzessiven Vergleiche (auch als Methode der paarweisen Vergleiche bezeichnet) zur Lösung des Gewich-

Bedeutung von Evaluation

und Evaluationsforschung

19

tungsproblems verwendet. Ihre Anwendbarkeit hängt von der Anzahl der Evaluationskriterien ab; mächtige Kriterienmengen müssen in Teilmengen zerlegt werden (vgl. [BloLü93,180f.]). Abbilden der Evaluationskriterien in Metriken Häufig bilden Evaluationskriterien keine meßbaren Eigenschaften der Evaluationsobjekte ab, so daß sie durch systematisches Top-down-Zerlegen so weit präzisiert werden müssen, bis Meßbarkeit gegeben ist. Das Ergebnis der Präzisierung wird als Metrik bezeichnet, was also immer „meßbare Eigenschaft eines Objekts" heißt. Für Hardware/Systemsoftware-Systeme als Evaluationsobjekt sind beispielsweise folgende Metriken typisch (im Sinn von allgemein anwendbar): • Durchsatzzeit (Zeiteinheiten/Arbeitslast) ist der Zeitraum, der zum Abarbeiten der Arbeitslast erforderlich ist, gemessen vom Beginn der Dateneingabe bis zum Ende der Datenausgabe. • Antwortzeit (Zeiteinheiten/Transaktion) ist der Zeitraum, der zum Ausführen einer Transaktion erforderlich ist, gemessen vom Ende der Dateneingabe bis zum Ende der Datenausgabe. • Antwortzeitverhalten (Antwortzeiten/Zeiteinheit) ist die Streuung der Antwortzeiten für eine Menge gleicher oder gleichartiger Transaktionen. • Verfügbarkeit (%) ist das das Verhältnis zwischen dem Zeitraum, in dem Funktionen fehlerfrei ausgeführt werden, und dem Zeitraum, in dem diese Funktionen von der Arbeitslast gefordert werden. • Wiederanlauf (Zeiteinheiten) ist der Zeitraum zwischen dem Beginn eines Systemabbruchs und dem Zeitpunkt, zu dem sich das System wieder in dem Zustand befindet, der zum Zeitpunkt des Systemabbruchs bestanden hat. Die Beispiele zeigen, daß es möglich ist, für bestimmte Objekte oder sogar für Objektklassen Metriken zu entwickeln, die zur Lösung gleicher oder gleichartiger Evaluationsprobleme verwendet werden können. Was die Wirtschaftsinformatik-Forschung dazu bisher geleistet hat, ist im Vergleich mit anderen Disziplinen bescheiden. Einschlägige Publikationen sind nicht bekannt. (Im Unterschied dazu z.B. [Boyce94] und [Tague95] für die Informationswissenschaft.) Wenn der Reifegrad einer Wissenschaft (auch) danach beurteilt wird, in welchem Umfang sie sich mit der Messung der für diese Wissenschaft typischen Phänomene befaßt bzw. Arbeitsergebnisse dazu vorgelegt hat, dann muß der Reifegrad der Wirtschaftsinformatik als relativ gering bezeichnet werden. Auswählen von Meßmethoden Metrik wurde als meßbare Eigenschaft eines Objekts definiert, so daß die Frage der Verfügbarkeit von Meßmethoden prinzipiell dann beantwortet ist, wenn Metriken vorliegen. Unbeantwortet ist, welche Meßmethode - bei Verfügbarkeit mehrerer Meßmethoden - verwendet werden soll, also die Beantwortung der Frage, welche Meßmethode zu welchem Kriterium paßt. [Adel92,7] überläßt es dem Evaluator, diese Frage zu beantworten, wenn er sagt: „The evaluator must know how to implement different methods in order to provide the required information on different criteria." Qualitäts-

20

Lutz J.

Heinrich

forderungen an die Meßmethoden wie Präzision, Validität und Réhabilitât sind zu beachten (vgl. z.B. [Stapf93], [Grac93]). Es besteht daher ein unmittelbarer Zusammenhang zwischen dem Abbilden der Evaluationskriterien in Metriken und der Verfügbarkeit von geeigneten Meßmethoden. Grundsätzlich stehen als Meßmethoden alle Methoden zur Verfügung, mit denen Daten über Objekte direkt oder indirekt erfaßt werden können (sog. Erfassungsmethoden und Erhebungstechniken). Ihre Eignung als Meßmethode zur Lösung eines bestimmten Evaluationsproblems ist f ü r jede Evaluationsstudie zu überprüfen. Praktische Erfahrungen zeigen, daß ein Mangel an geeigneten Meßmethoden besteht. Eine zentrale Forderung an die Wirtschaftsinformatik-Forschung ist daher die Entwicklung von Meßmethoden, die für wirtschaftsinformatorisch typische Evaluationsobjekte, d.h. für jede Art von Informatik-Mittel, geeignet sind, bzw. verfügbare Meßmethoden so anzupassen und weiter zu entwickeln, daß Eignung gegeben ist. Beispiele für diese Art von Methodenentwicklung sind Benchmarking, Testen und Fehlerbaumanalyse. • Das Benchmarking ist eine spezifische Form des Experiments, die explizit auf das Ermitteln der Kriterienerträge für Evaluationskriterien ausgerichtet ist. Die Benchmarks bilden wesentliche Eigenschaften der Evaluationsobjekte und der Arbeitslast ab (vgl. [Hein99,445f.] und die dort angegebene Literatur). • Beim Testen ist das Evaluationsobjekt oder sind Teile des Evaluationsobjekts das Testobjekt. Testmethoden eignen sich dazu, Fehler im Testobjekt aufzudecken bzw. nachzuweisen, daß angenommene Fehler nicht vorhanden sind. Das heißt, daß zum Testen Fehlervorgaben erforderlich sind, die aus den Evaluationskriterien abgeleitet werden müssen, und das heißt auch, daß durch Testen nicht alle in einem Testobjekt vorhandenen Fehler aufgedeckt werden können (vgl. [Hein97,408f.] und die dort angegebene Literatur). • Mit der Fehlerbaum-Analyse (FBA) kann die Zuverlässigkeit bzw. die Ausfallwahrscheinlichkeit großer und komplexer Systeme (Produkte und Prozesse) aller Art ermittelt werden. Die FBA ist ein deduktives Analyseverfahren, womit eine Vorgehensweise gekennzeichnet ist, die, von einem unerwünschten Top-Ereignis ausgehend, top-down die Ereignis-Kombinationen als Eingangsereignisse betrachtet, die bottom-up zu diesem TopEreignis führen (vgl. [Hein99,491f.] und die dort angegebene Literatur).

5 Evaluation und Wirtschaftsinformatik-Lehre Welche Bedeutung Evaluation in der Lehre hat, kann zunächst daraus abgeleitet werden, welche Bedeutung ihr in der Praxis zukommt, denn wissenschaftliche Lehre ist auch Berufsvorbildung. Aus der Tatsache, daß die Lösung von Evaluationsproblemen der Praxis eine zunehmende Bedeutung für die Erreichung der Unternehmensziele hat, kann geschlossen werden, daß der Bedarf an einschlägiger Qualifikation zunehmen wird. Die Analyse des Stellenmarkts überregionaler Tageszeitungen (z.B. Frankfurter Allgemeine

Bedeutung von Evaluation

und Evaluationsforschung

21

Zeitung) zeigt, daß einschlägige Qualifikationsforderungen häufig genannt werden. Wissenschaftliche Lehre als Berufsvorbildung heißt aber nicht nur, den von der Praxis artikulierten Qualifikationsforderungen zu entsprechen, sondern auch, für die Zukunft erwartete Qualifikationsforderungen zu erkennen und die zu ihrer Abdeckung erforderliche Qualifikation zu vermitteln. Da Evaluationsprobleme in der Praxis heute eher unterbewertet werden, nicht erkannt und/oder nicht oder nur schlecht gelöst werden, kann diese Qualifikation auch zur Verbesserung des Problembewußtseins beitragen. Evaluation und Evaluationsforschung sind Forschungsgebiete, deren erfolgreiche Bearbeitung für die Erreichung der Forschungsziele der Wirtschaftsinformatik nicht unerheblich ist. Feldforschung und Laborforschung sind gefragt, erstere insbesondere zur Beschreibung und explorativen Erklärung von Evaluationsprozessen, letztere vor allem zur experimentellen Erklärung und zur Entwicklung von Evaluationsverfahren. Hierbei ist die Mitwirkung der Wirtschaftsinformatik-Studierenden aus mehreren Gründen erforderlich; einige davon seien genannt (vgl. auch [Hein93,47f.]). Wirtschaftsinformatik-Lehre erfordert - neben den klassischen Lehrveranstaltungen (wie Vorlesungen und Übungen) - projekt- und teamorientierte Lehrveranstaltungen, um Problemlösungsfähigkeit und soziale Kompetenz zu entwickeln. Die Studierenden befinden sich in einer Handlungssituation, die durch ein Defizit an Wissen gekennzeichnet ist, und sie lösen unter wissenschaftlicher Anleitung das Problem. Wenn es sich um ein wissenschaftliches Problem handelt, ist die Lehrveranstaltung ein Theorie-Seminar, handelt es sich um ein praktisches Problem, ist die Lehrveranstaltung ein Projektseminar. Häufig überwiegt die eine oder die andere Orientierung; es handelt sich also nicht immer um Alternativen. Beide Seminartypen fördern daher theoriegeleitete Praxisorientierung, sind aber auch Mittel zur Einübung sozialer Kompetenz durch Teamarbeit. Die Notwendigkeit, Arbeitsergebnisse der Gruppen zu präsentieren und zu verteidigen, fördert Durchsetzungsvermögen und sicheres Auftreten einschließlich eher technischer Fähigkeiten und Fertigkeiten (z.B. Beherrschung von Präsentationstechniken). Manche Aufgaben des Forschungsbetriebs können in Aufgaben des Lehrbetriebs integriert werden, vice versa. Angesichts mangelhafter Personalausstattung und begrenzter Möglichkeit der Einwerbung von Drittmitteln können nicht nur, sondern müssen Studierenden bestimmte Forschungsaufgaben übertragen werden können. Manche Laborstudie hätte ohne die Mitwirkung der Studierenden nicht durchgeführt werden können. Danksagung: Der Autor dankt Herrn Professor Dr. Volker Gadenne, Ordinarius für Philosophie und Wissenschaftstheorie an der Universität Linz, für Anregungen, die zur Entstehung und Verbesserung dieses Beitrags geführt haben.

22

Lutz J. Heinrich

Literatur [Adel92] Adelman, L.: Evaluating Decision Support and Expert Systems. New York et al. 1992 [Albe87] Albert, H.: Kritik der reinen Erkenntnislehre. Das Erkenntnisproblem in realistischer Perspektive. Tübingen 1987 [Bann98] Bannister, F.: In Defence of Instinct: IT Value and Investment Decisions. In: Proc. of the 5th European Conf. on The Evaluation of Information Technology. Reading 1998, 1 -9 [BeHe92] Berkau, D. / Herzwurm, G.: Kriterien für die Auswahl PC-gestützter SoftwareEntwicklungsumgebungen. In: Information Management 1/1992, 42 - 55 [BloLü95] Blohm, H. / Lüder, K.: Investition. München 1995 [Boyce94] Boyce, B. R. et al.: Measurement in Information Science. London et al. 1994 [BrRe98] Brown, A. / Remenyi, D. (eds): Proc. of the 5th European Conf. on The Evaluation of Information Technology. Reading 1998 [Daum93] Daumenlang, K. et al.: Evaluation. In: Roth, E. (Hrsg.): Sozialwissenschaftliche Methoden. München/Wien 1 9 9 3 , 7 0 2 - 7 1 3 [Grac93] Grachowetz, H.: Feldforschung. In: Roth, E. (Hrsg.): Sozialwissenschaftliche Methoden. München/Wien 1993,245 - 266 [Hein85] Heinen, E.: Einführung in die Betriebswirtschaftslehre. Wiesbaden 1985 [Hein93] Heinrich, L. J.: Wirtschaftsinformatik - Einführung und Grundlegung. München/ Wien 1993 [Hein99] Heinrich, L. J.: Informationsmanagement. München/Wien 1999, insbes. Kapitel Evaluationsmethoden [HePo97] Heinrich, L. J. / Pomberger, G.: Prototyping-orientierte Evaluation von SoftwareAngeboten. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 197/1997, 112 124 [HeRo98] Heinrich, L. J. / Roithmayr, F.: Wirtschaftsinformatik-Lexikon. München/Wien 1998, insbes. Sachgebiet Evaluierungsmethode [Lust89] Lusti, M.: Dateien und Datenbanken - Eine anwendungsorientierte Einführung. Berlin et al. 1989 [MaBr98] Magrill, H. / Brown, Α.: Evaluating Intranet Applications. In: Proc. of the 5th European Conf. on The Evaluation of Information Technology, Reading 1998, 77 - 109 [MiDu97] Miller, Κ. / Dunn, D.: Post-implementation evaluation of information systems/ technology: a survey of UK practice. In: Berghout, E. W. / Remenyi, D. S. J. (eds): Evaluation of Information Technology. Delft 1997,47 - 55 [OpRe92] Oppermann, R. / Reiterer, H.: Evaluation von Benutzerschnittstellen. In: WOÎTSCHAFTSINFORMATIK 3/1992, 283 - 293 [Park89] Parker, M. M. et al.: Information Strategy and Economics. Linking Information Systems Strategy to Business Performance. Englewood Cliffs/NJ 1989 [Snel98] Snelting, G.: Paul Feyerabend und die Softwaretechnologie. In: InformatikSpektrum 1 9 9 8 , 2 7 3 - 2 7 6 [Stapf93] Stapf, Κ. Η.: Laboruntersuchungen. In: Roth, E. (Hrsg.): Sozialwissenschaftliche Methoden. München/Wien 1993, 228 - 244 [Such67]) Suchman, Ε. Α.: Evaluative Research. New York 1967 [Symo90] Symonds, V.: Evaluation of Information Systems. In: Journal of Information Technology 5/1990, 194 - 204 [Tague95] Tague-Sutcliffe, J.: Measuring Information. An Information Services Perspective. London et. al 1995 [Wise92] Wiseman, D.: Information Economics: a practical approach to valuing information systems. In: Journal of Information Technology 7/1992, 169 - 176 [Zang76] Zangemeister, Ch.: Nutzwertanalyse in der Systemtechnik. München 1976 [Yola98] Yolande, E. Ch.: IT Value - The Great Divide between Qualitative and Quantitative, and Individual and Organizational, Measures. In: Proc. of the 5th European Conf. on The Evaluation of Information Technology, Reading 1998, 35 - 54

Verbreitung von Evaluation und Evaluationsforschung in der Wirtschaftsinformatik Harald Schmidt / Irene Häntschel [email protected] / [email protected]

Institut für Wirtschaftsinformatik der Universität Linz / A D M E T A Unternehmensberatung und Informationsmanagement GmbH, Linz www.winie.uni-linz.ac.at / www.admeta.com

Inhalt 1 2 3 4

Untersuchungsziel State of the Art Untersuchungsdesign und Befunde Interpretation und Schlußfolgerungen

Zusammenfassung Es wird über eine Untersuchung berichtet, deren Ziel es war, Aussagen über die Verbreitung von Evaluation und Evaluationsforschung in der Wirtschaftsinformatik zu machen. Die methodisch unterschiedlichen Vorgehensweisen bei der Untersuchung der Teilbereiche Evaluation in der Praxis, in der Forschung und in der Lehre bzw. Evaluationsforschung in der Wirtschaftsinformatik werden dargestellt. Die Autoren berichten über Befunde zu Art und Umfang der Verbreitung von Evaluation und Evaluationsforschung. Das Ergebnis zeigt vor allem die geringe Verbreitung in allen Teilbereichen und die spärliche Verwendung formaler Methoden und Werkzeuge in der Praxis. Abschließend werden Anregungen zur weiteren Beschäftigung mit Evaluation und Evaluationsforschung in der Wirtschaftsinformatik gegeben.

Abstract This paper reports on an analysis of the dissemination of evaluation and evaluation research in the different fields of information systems research. The authors present the examination of practice, teaching and research in this discipline. Findings about the nature and currency of evaluation and evaluation research are shown. The results point out the actual fact that there is poor dissemination of evaluation and evaluation research in all the analyzed fields and that formal methods and tools are rarely used in practical life. Finally, suggestions are made for further treatment of evaluation and evaluation research in the information systems research field.

24

Harald Schmidt /Irene

Häntschel

1 Untersuchungsziel Ziel der Untersuchung, über die hier berichtet wird, war es, Aussagen über die Verbreitung von Evaluation und Evaluationsforschung in der Wirtschaftsinformatik in Praxis, Forschung und Lehre zu machen. Dabei wurde von folgendem Begriffsverständnis ausgegangen (vgl [HeRo98,198]): • Evaluation ist die zielbezogene Beurteilung von beliebigen Objekten (z.B. Prozeß, Produkt, Handlung) auf der Grundlage eines Systems von Beurteilungskriterien im Feld oder im Labor. • Evaluationsforschung ist der Prozeß der Gewinnung wissenschaftlicher Erkenntnisse, deren Gegenstand das Problem der Ermittlung des Wertes beliebiger, der Wirtschaftsinformatik zuzurechnender Objekte sowie die Anwendung einschlägiger wissenschaftlicher Erkenntnisse in der Praxis ist, einschließlich der Folgen, die sich aus der Anwendung ergeben können. Wenn in diesem Beitrag Aussagen zur Verbreitung gemacht werden, so sind diese nicht für alle Teilbereiche der Wirtschaftsinformatik gültig. Deshalb wird zwischen der Verbreitung von Evaluation in der Praxis, in der Forschung und in der Lehre bzw. der Verbreitung von Evaluationsforschung unterschieden, die in getrennten Abschnitten dargestellt werden. Die der Untersuchung zugrundeliegenden Thesen lauten: • Evaluation und Evaluationsforschung sind in der Wirtschaftsinformatik wenig verbreitet. • Es bestehen deutliche Unterschiede in der Verbreitung zwischen dem deutschsprachigen und dem englischsprachigen Raum. • Die Verbreitung von Evaluation und Evaluationsforschung hat in den letzten Jahren zugenommen. • Evaluation ist meist technikzentriert. Mensch und Aufgabe als weitere Bestandteile von Informationssystemen sind selten Objekte der Evaluation. • Evaluation wird vorwiegend ex-ante durchgeführt und hat als solche häufig den Charakter einer Entscheidungshilfe. Aus den Thesen ist ersichtlich, daß sowohl der Umfang der Verbreitung als auch die Art der Evaluation und Evaluationsforschung Gegenstand dieser Untersuchung waren.

2 State of the Art Evaluation und Evaluationsforschung haben ihre Wurzeln im pädagogischen Bereich. Joseph Rice führte in den USA 1887 bis 1889 eine Untersuchung durch, mit der er an ca. 33.000 Schülern nachwies, daß die zur damaligen Zeit überaus starke Betonung des Buchstabierens beim Erlernen des Lesens nicht den erwarteten Erfolg hat. Nach [Roth95,703] wird diese Arbeit als die erste Evaluationsstudie angesehen. Später wurde in den USA Evaluationsforschung integraler Bestandteil der Sozialpolitik. Auch im deutschsprachigen

Verbreitung von Evaluation und Evaluationsforschung

25

Raum ist die Evaluationsforschung vor allem in der Bildungsforschung, Psychotherapieforschung, Arbeitspsychologie sowie in der Politikforschung etabliert. In der Wirtschaftsinformatik sind Evaluation und Evaluationsforschung ein recht junges Thema. Eine Metaforschungsarbeit wie diese Untersuchung ist den Autoren nicht bekannt geworden.

3 Untersuchungsdesign und Befunde Um zunächst einen generellen Eindruck über die Verbreitung von Evaluation und Evaluationsforschung in der Wirtschaftsinformatik zu erhalten, wurde im World Wide Web mit Hilfe von Suchmaschinen nach diesen Begriffen gesucht. Diese Suche beschränkte sich auf die deutschsprachigen Seiten des World Wide Web (Deutschland, Österreich und Schweiz), da es im englischsprachigen Raum keine einheitliche Bezeichnung für die im Deutschen als Wirtschaftsinformatik bezeichnete Disziplin gibt und eine inhaltliche Abgrenzung zu anderen Disziplinen durch Suchbegriffe kaum möglich ist. Mit vier der größten und bekanntesten Suchmaschinen im WWW [Sull99] wurden durch eine Suche nach dem Stichwort „Wirtschaftsinformatik" die relevanten Untersuchungsobjekte identifiziert (vgl. Tabelle 1). Suchmaschine Yahoo (http://www.yahoo.com/)

Zeitpunkt der Suche Gefundene Links 28.10.98, 20.58 2089 Uhr AltaVista (http://altavista.digital.com/) 28.10.98, 21.03 31703 Uhr HotBot (http://www.hotbot.com/) 28.10.98, 21.13 5821 Uhr Excite (http://www.excite.com/) 5240 5.11.98, 10.49 Uhr Tab. 1 : Ergebnis der Suche nach d e m Begriff „Wirtschaftsinformatik"

In jeder der vier Suchmaschinen wurde eine Suche nach jenen Web-Seiten gestartet, die sowohl den Begriff „Wirtschaftsinformatik", als auch einen der in Tabelle 2 angeführten Begriffe enthalten. Die Anzahl der Links, die dabei gefunden wurden, wurde der Gesamtanzahl der Untersuchungsobjekte gegenübergestellt. Tabelle 2 enthält die Ergebnisse dieser Analyse. Das Ergebnis zeigt die geringe Verbreitung des Begriffs „Evaluation" in der Wirtschaftsinformatik so deutlich, daß die Verwendung des Terminus „wenig verbreitet" gerechtfertigt ist. Selbst bei der Suche nach so allgemeinen Begriffen wie „Analyse" oder „Auswahl" auf den WWW-Seiten jener Institutionen, die der Wirtschaftsinformatik zuzurechnen sind, betrug die maximale Häufigkeit nur knapp über 15%.

26

Harald Schmidt / Irene

Häntschel

Suchbegriff Treffer % Treffer % Treffer % Treffer % Wirtschafts2089 100% 31703 100% 5821 100% 5240 100% informatik WirtschaftsKombinierte Suche informatik + ... + Evaluation 95 4,6% 547 1,7% 349 6,0% 4,5% 235 + Evaluation 37 1,8% 232 0,7% 98 1,7% 54 1,0% + Evaluations2 0,1% 25 0,1% 8 0,1% 5 0,1% forschung + Bewertung 504 163 7,8% 1088 3,4% 8,7% 272 5,2 % + Messung 1,4% 184 0,6% 95 47 29 1,6% 0,9% 674 11,6% 328 + Auswahl 221 10,6% 1419 4,5% 6,3% + Beurteilung 3,4% 597 1,9% 324 5,6% 0 0,0% 70 + Analyse 305 14,6% 2254 7,1% 993 17,1% 529 10,1% Tab. 2: Ergebnis der Suche nach den Begriffen „Wirtschaftsinformatik" und „NN"

Die Suche nach den Begriffen „Evaluation" (zwischen 1,7% und 6% aller gefundenen Wirtschaftsinformatik-Links enthalten diesen Begriff) und „Evaluationsforschung" (etwa 0,1% aller gefundenen WirtschaftsinformatikLinks enthalten diesen Begriff) lieferte noch konkretere Hinweise auf die Größenordnung der zu erwartenden Ergebnisse bei den in der Folge dargestellten, detaillierteren Untersuchungen zur Verbreitung von Evaluation und Evaluationsforschung in der Wirtschaftsinformatik. Diese Darstellung erfolgt einzeln für die Bereiche Praxis, Forschung, Lehre bzw. Evaluationsforschung. 3 . 1 Evaluation in der Wirtschaftsinformatik-Praxis 3 . 1 . 1 Untersuchungsdesign Um Aussagen über die Verbreitung von Evaluation in der Wirtschaftsinformatik-Praxis machen zu können, sind Feldstudien erforderlich. Dafür wurde die Methode der strukturierten mündlichen Expertenbefragung (vgl. [Bortz84,164f.]) gewählt; Experten sind solche Praktiker, die für Wirtschaftsinformatiker typische Aufgaben wahrnehmen (IV-Bereich). Die Expertengruppe umfaßte 24 Personen aus dem IV-Bereich, vorwiegend aus Klein- und Mittelbetrieben des oberösterreichischen Wirtschaftsraums. Die Experten wurden aufgefordert, über Informatik-Projekte zu berichten, die in ihrem Unternehmen durchgeführt wurden. Die Interviewer hatten zunächst die Aufgabe, Projekte zu identifizieren, in denen evaluiert wurde. Auf diese Projekte und die dabei durchgeführte Evaluation wurde dann durch weitere Fragen näher eingegangen. Auf dem Interviewleitfaden, den die Interviewer verwendeten, wurden während des Interviews die Aussagen der Experten in zusammengefaßter und strukturierter Form festgehalten. Die Verwendung des Interviewleitfadens sicherte auch die Vollständigkeit der erhobenen Daten, da die Interviewer

Verbreitimg

vrn Evaluation

und Evaluationsforschung

27

das Interview erst beendeten, wenn sie alle gewünschten Aussagen erhalten hatten. Bei jedem zweiten Unternehmen, das kontaktiert wurde, erklärte man sich bereit, in einem Interview Auskunft über Informatik-Projekte und dabei durchgeführte Evaluationen zu geben. Bei 24 von 48 kontaktierten Unternehmen kam aus unterschiedlichen Gründen kein Interview zustande: In 14 Fällen erhielten die Interviewer auf ihre Anfrage gar keine Rückmeldung, 7 Ansprechpartner erklärten, keine Zeit für ein Interview zu diesem Thema zu haben, zwei Kontaktpersonen sahen sich außerstande, kompetent Auskunft zu geben und konnten auch keine andere Person aus ihrem Unternehmen nennen, die als Experte geeignet gewesen wäre. In einem Fall erhielten die Interviewer die Auskunft, daß im Unternehmen keine Evaluationen durchgeführt werden. Die Stichprobe umfaßte Unternehmen verschiedener Branchen und unterschiedlicher Größen. Abbildung 1 zeigt die Zusammensetzung der Stichprobe nach der Unternehmensgröße gemessen in Anzahl Mitarbeiter.

Anzahl der Beschäftigten: Ξ1-50 • 51-250 0251-1000 α>1000

Abb. 1 : Zusammensetzung der Stichprobe nach Unternehmensgröße

Die Befragten waren vor allem Projektverantwortliche aus dem Unternehmensbereich Informationsverarbeitung (58,3%). Aber auch Verantwortliche aus dem Controlling (8,3%), aus Fachabteilungen (12,5%) und aus der Unternehmensleitung (12,5%) waren über diverse Evaluationstätigkeiten vollständig informiert und standen als Experten zur Verfügung. 83,3% der Befragten erklärten, der Informationsverarbeitung käme in ihrem Unternehmen „große" oder sogar „extrem große" Bedeutung zu, und nur 4 Experten gaben an, im IV-Bereich über weniger als ATS 1 Mio. (€ 72672,-) Budget zu verfügen.

3.1.2 Befunde Die Bedeutung der Projekte, in denen evaluiert wurde, wurde für den Unternehmenserfolg als „hoch" oder sogar „sehr hoch" eingestuft. Der Annahme von der geringen Bedeutung der Evaluation in der Praxis entsprechend kam es in nur einem Fall auf Grund des Evaluationsergebnisses zu einem Projektabbruch. Dem Ergebnis der Evaluation wurde also in allen Fällen geringe Bedeutung beigemessen, unabhängig davon, ob das Ziel der Evaluation erreicht wurde oder nicht.

28

Harald Schmidt /Irene

Häntschel

keine Angabe Folgeprojekt 3 8 8 M H Projekt bbruch

Projekt) jrtführung

1

Abb. 2: Wirkung des Evaluationsergebnisses

Betrachtet man die Objekte, die Gegenstand der Evaluation bei den befragten Unternehmen waren, zeigt sich eine starke Technikzentrierung. In allen Fällen standen Techniksysteme (Hardware bzw. Software, siehe Tabelle 3) als Evaluationsobjekt im Mittelpunkt. Dieser Befund ist vermutlich nicht allein darauf zurückzuführen, daß der Großteil der Experten im Unternehmensbereich Informationsverarbeitung tätig ist, sondern läßt auch darauf schließen, daß die Praxis die Evaluation als systematische, zielbezogene Beurteilung für andere Objekte als noch weniger geeignet einstuft. Branche Handel Andere Industrie Gewerbe Sonstige Gesamt Evaluationsobjekt DL absolute Häufigkeit Software 2 1 21 5 8 5 1 1 Hardware 0 1 2 5 Summe 2 7 3 6 8 26 relative Häufigkeit Software 66,7 % 83,3% 100,0% 50,0% 71,4% 80,8% Hardware 16,7% 33,3% 0,0% 50,0% 28,6% 19,2% Tab. 3: Evaluationsobjekte in unterschiedlichen Branchen (DL = Dienstleister)

Die am häufigsten verwendeten Methoden sind in Tabelle 4 angeführt; es besteht eine starke Präferenz für die Nutzwertanalyse. Methode Nutzwertanalyse Wirtschaftlichkeitsrechnungen Testen/Prototyping Interviews Matrixanalyse Vergleich der Funktionen Soll/Ist-Vergleich Sonstige Keine Angabe Summe

absolute Häufigkeit 10 6 5 2 2 2 2 10 3 42

Tab. 4: Verwendete Evaluationsmethoden

relative Häufigkeit 23,8% 14,3% 11,9% 4,8% 4,8% 4,8% 4,8% 23,7% 7,1% 100,0%

Verbreitung von Evaluation und Evaluationsforschung

29

In direktem Zusammenhang mit der starken Verbreitung der Nutzwertanalyse ist der Befund zu sehen, daß die Kriteriengewichtung als häufigstes Problem im Evaluationsprozeß genannt wird. Als besonders problematisch wird dieser Arbeitsschritt der Nutzwertanalyse deshalb angesehen, weil der Diskussionsprozeß auf Grund mangelnder Vorgaben der Auftraggeber der Projekte meist sehr lang dauert. 10% der Befragten berichten von Schwierigkeiten bei der Erfassung und Beurteilung qualitativer Eigenschaften der Untersuchungsobjekte, aber auch Kostenschätzungen und adäquate Benutzereinbindung bildeten erwähnenswerte Problembereiche. Als weiteres Indiz für die geringe Bedeutung der systematischen und zielbezogenen Beurteilung von Objekten in der Praxis kann die spärliche Verwendung von Werkzeugen für die Evaluation angesehen werden. Beinahe die Hälfte der Befragten gibt an, keine Werkzeuge eingesetzt zu haben, mehr als 20% verwenden mit MS Excel eine Standardsoftware, die lediglich „Papier und Bleistift" ersetzen kann. In nur zwei Fällen wurde speziell f ü r diesen Anwendungsbereich geschaffene Software, ein Simulationswerkzeug bzw. eine Benchmarking-Software, eingesetzt. Werkzeug Keine Excel Benchmarking-Software Simulationswerkzeug CASE-Tool Sonstige Keine Angabe Summe

absolute Häufigkeit 13 6 1 1 1 5 2 29

relative Häufigkeit 44,8% 20,7% 3,5% 3,5% 3,5 % 17,1% 6,9% 100,00%

Tab. 5: Werkzeuge für die Evaluation

Als Evaluationsziel wird von 17 der 24 Befragten „Entscheidungsvorbereitung" genannt. In 14 von diesen 17 Fällen wurde die Evaluation daher ex-ante durchgeführt, bei den anderen wurde projektbegleitend evaluiert. 3 . 2 Evaluation in der Wirtschaftsinformatik-Forschung 3 . 2 . 1 Untersuchungsdesign Um Aussagen zur Verbreitung von Evaluation in der WirtschaftsinformatikForschung machen zu können, wurde folgendes Untersuchungsdesign verwendet: • Zeitschriftenanalyse • Internet-Analyse der deutschsprachigen Wirtschaftsinformatik-Lehrstühle • schriftliche Expertenbefragung

30

Harald Schmidt/Irene

Häntschel

Die Stichprobe für die Zeitschriftenanalyse bestand aus drei englischsprachigen und drei deutschsprachigen Zeitschriften, die der Wirtschaftsinformatik zuzuordnen sind (in Klammern die verwendeten Akronyme): • • • • • •

HMD - Theorie und Praxis der Wirtschaftsinformatik (HMD) 1 Information Management (IM) WIRTSCHAFTSINFORMATIK (WIN) Decision Sciences Journal (DSJ) Information & Management (I&M) Information Systems Research (ISR)

Es wurden die Jahrgänge 1990 bis 1997 dieser Zeitschriften herangezogen. Tabelle 6 gibt einen Uberblick über die Anzahl der Publikationen („Artikel") je Zeitschrift für diesen Zeitraum Zeitschrift HMD IM WIN DSJ I&M ISR

'91 68 43 54 61 53 0*

'91 59 42 61 78 55 0*

'92 60 50 57 85 54 16

'93 58 48 54 0* 61 13

'94 59 53 52 45 60 20

'95 62 68 68 35 61 17

* Jahrgänge nicht verfügbar

'96 54 65 56 35 48 28

'97 ges. dt./engl. gesamt 45 1354 465 67 436 51 453 39 906 378 42 434 94 0* 2260

Tab. 6: Stichprobe der Zeitschriftenanalyse

Die Untersuchung der Stichprobe erfolgte in zwei Arbeitsschritten. 1. Bei der Zeichenketten-Suche wurden sowohl Stichwortverzeichnisse und Inhaltsverzeichnisse der Zeitschriften als auch Abstracts bzw. Zusammenfassungen der Artikel hinsichtlich des Auftretens der in Tabelle 7 genannten Begriffe durchsucht (diese Begriffe werden in einschlägigen Lexika, z.B. [HeRo98,198], meist zur Erklärung des Begriffs Evaluation herangezogen). Begriffe mit gleichem Wortstamm wurden als gleichwertig angesehen. deutsch Evaluation Evaluationsforschung Messung Bewertung Auswahl Analyse

englisch evaluation evaluation research measurement assessment selection, choice analysis

Tab. 7: Suchbegriffe für die Zeitschriftenanalyse

1

Seit A u g u s t 1998 „ H M D - Praxis der Wirtschaftsinformatik"

Verbreitung von Evaluation und Evaluationsforschung

31

2. Für die Inhaltsanalyse und Kategorisierung wurden die bei der Zeichenketten-Suche gefundenen Artikel herangezogen. Sie wurden zwei Kategorien zugeordnet: • Kategorie A: Artikel, die sich mit „Evaluation" beschäftigen (nach der Definition in [HeRo98],Stichwort Evaluation). • Kategorie B: Artikel, die der Evaluationsforschung (nach der Definition in [HeRo98], Stichwort Evaluationsforschung) zuzuordnen sind. Die Artikel der Kategorie A (zur Analyse der Publikationen der Kategorie Β siehe Abschnitt 3.3.2) wurden mit Hilfe eines Erhebungsbogens hinsichtlich weiterer interessanter Kriterien untersucht. Im deutschsprachigen Raum wurden die Ergebnisse der Zeitschriftenanalyse durch eine Internet-Analyse der Wirtschaftsinformatik-Lehrstühle überprüft. Mit der Referenzseite

wurde versucht, die Wirtschaftsinformatik-Lehrstühle zu identifizieren, die sich im WWW präsentieren. Die gefundenen 107 Lehrstühle (Stichtag: 24. 10. 1998) sind die Stichprobe. Die WWW-Seiten der Stichprobe wurden, so wie weiter oben bereits beschrieben, einer zweistufigen Analyse (Zeichenketten-Suche und Inhaltsanalyse) unterzogen. Dies erfolgte mit dem Ziel, die Anzahl der angeführten Forschungsschwerpunkte, Projekte, Mitarbeiter und Publikationen zu identifizieren bzw. festzustellen, wie viele davon sich mit Evaluation oder Evaluationsforschung beschäftigen. Durch eine zusätzliche schriftliche Befragung wurde versucht, auch von den Lehrstühlen Daten zu erhalten, deren WWW-Seiten keine Auskunft über Projekte, Mitarbeiter und Publikationen geben. Über die Mailingliste der Wissenschaftlichen Kommission Wirtschaftsinformatik (WKWI) im Verband der Hochschullehrer für Betriebswirtschaft e.V. wurde ein Fragebogen zum Thema „Evaluation in der Wirtschaftsinformatik-Forschung" versendet. 3 . 2 . 2 Befunde Die Ergebnisse der drei durchgeführten Untersuchungen bestätigen die eingangs formulierte These der geringen Verbreitung von Evaluation in der Wirtschaftsinformatik-Forschung. Nur 66 der 2.260 Artikel (0,029%) konnten bei der Zeitschriftenanalyse der Kategorie A zugeordnet werden, beschäftigen sich also mit Evaluation. Ein noch deutlicheres Ergebnis lieferte die Lehrstuhlanalyse. 6 von 385 Forschungsschwerpunkten (0,016%), 8 von 489 Forschungsprojekten (0,016%), 12 von 696 wissenschaftlichen Mitarbeitern (0,017%) und 47 von 4.265 Publikationen (0,011%) an den deutschsprachigen Wirtschaftsinformatik-Lehrstühlen beschäftigen sich explizit mit Evaluation. Die schriftliche Befragung per E-Mail brachte bei einer Rücklaufquote von 32,1% (27 Antworten von 84 verschiedenen Institutionen) folgendes Ergeb-

32

Harald Schmidt /Irene Häntschel

nis: 11,9% der Befragten berichten von (Forschungs-) Projekten, bei denen evaluiert wird. Alle fehlenden Rückmeldungen wurden dabei als negative Antworten interpretiert. Dies scheint auf Grund folgender Tatsache gerechtfertigt: Durch die Art der Fragestellung wurde ein positives Ergebnis intendiert. Institutionen, die sich mit Evaluation beschäftigen, sollten daher ausreichend motiviert gewesen sein, die E-Mail zu beantworten. Selbst die Berücksichtigung weniger Fälle, in denen andere Gründe für die fehlende Reaktion auf die Befragung vorgelegen haben können, vermag die Aussage nicht zu verändern, daß Evaluation in der Wirtschaftsinformatik-Forschung kaum verbreitet ist. Bezüglich der unterschiedlichen Verbreitung von Evaluation im deutschsprachigen und im englischsprachigen Raum läßt das Ergebnis der Zeitschriftenanalyse folgende Aussage zu: Von den gefundenen Artikeln, die sich mit Evaluation beschäftigen, war nur ein Drittel in Deutsch verfaßt. Evaluation spielt also im englischsprachigen Raum eine wesentlich größere Rolle. Ein Zeitvergleich innerhalb der Stichprobe ergab, daß zwischen 1990 und 1997 weder im deutschsprachigen noch im englischsprachigen Raum eine Zunahme der Verbreitung von Evaluation stattgefunen hat. Die Inhaltsanalyse zeigt auch, daß Techniksysteme häufig im Mittelpunkt der Evaluation in der Wirtschaftsinformatik-Forschung stehen. Nur bei 21 der 66 gefundenen Artikel (32%) sind entweder der Mensch oder die Aufgabe primärer Evaluationsgegenstand. Keine Aussagen können hingegen zur These gemacht werden, daß Evaluation vorwiegend ex-ante und zum Zwecke der Entscheidungsvorbereitung durchgeführt wird. 3 . 3 Evaluationsforschung in der Wirtschaftsinformatik 3 . 3 . 1 Untersuchungsdesign Die bei der Zeichenketten-Suche im Rahmen der Zeitschriftenanalyse zur Verbreitung von Evaluation in der Wirtschaftsinformatik-Forschung gefundenen und der Evaluationsforschung zugeordneten Artikel wurden in einem zweiten Arbeitsschritt einer Inhaltsanalyse unterzogen. Dies erfolgte unter Verwendung eines Erhebungsbogens, auf dem wesentliche inhaltliche Merkmale der Artikel festgehalten wurden. Die Ergebnisse der Inhaltsanalyse wurden mit der in Abschnitt 3.2.1 erwähnten schriftlichen Befragung zu bestätigen versucht. Die Adressaten wurden gebeten anzugeben, ob und unter welchen Bedingungen Evaluationsforschung an ihrem Lehrstuhl durchgeführt wird. 3 . 3 . 2 Befunde Die Zeitschriftenanalyse bestätigt auch bezüglich der Evaluationsforschung die These von einer geringen Verbreitung. Nur 49 der 2.260 analysierten Artikel (0,02%) beschäftigen sich mit Evaluationsforschung, wobei mehr als zwei Drittel (69%) davon von Autoren aus dem englischsprachigen Raum stammen. Eine Zunahme der Verbreitung in den letzten Jahren läßt sich aus den vorhandenen Erhebungsdaten nicht feststellen. Bei der schriftlichen

Verbreitung von Evaluation und Evaluationsforschung

33

Befragung gaben 8,3% der Befragten an, sich mit Evaluationsforschung in irgendeiner Form zu beschäftigen. Dieses Ergebnis, dem die in Abschnitt 3.2.2 genannten Annahmen zugrundeliegen, bestätigt auch die relativ geringe Verbreitung der Evaluationsforschung in der Wirtschaftsinformatik. 3 . 4 Evaluation in der Wirtschaftsinformatik-Lehre 3 . 4 . 1 Untersuchungsdesign Da eine Analyse des internationalen Studienführers Wirtschaftsinformatik [Mert96] keine Hinweise auf Evaluation als Lehrinhalt ergab, wurde auch f ü r diesen Bereich eine schriftliche Befragung der Adressaten der WKWIMailingliste durchgeführt. Gefragt wurde, ob und in welcher Weise Evaluation Gegenstand der Lehre ist und welche Literatur- bzw. Lehrunterlagen verwendet werden. 3 . 4 . 2 Befunde Legt man den Ergebnissen der Untersuchung in Abschnitt 3.2.2 erläuterten Annahmen zugrunde, waren die Antworten auf die Befragung per E-Mail in 8 von 84 Fällen (9,5%) positiv. Nur 10% der Befragten bejahten die Frage, ob Evaluation Gegenstand der Lehre ist und nannten verwendete Literatur bzw. Lehrunterlagen.

4 Interpretation und Schlußfolgerungen Die Befunde können die im Abschnitt 1 formulierten Thesen nicht widerlegen. Die Befunde der schriftlichen Befragung und der mündlichen Expertenbefragung ausgenommen 2 , zeigt sich die geringe Verbreitung von Evaluation und Evaluationsforschung in Praxis, Lehre und Forschung eindeutig. Soweit wegen des verwendeten Untersuchungsdesigns Aussagen über Art und Verbreitung von Evaluation im deutschsprachigen bzw. englischsprachigen Raum gemacht werden können, ist auch eine Widerlegung der anderen Thesen nicht möglich. Nur die Zunahme der Verbreitung von Evaluation und Evaluationsforschung in den letzten Jahren läßt sich aus den vorliegenden Erhebungsdaten nicht ableiten. Allerdings wären ergänzende Untersuchungen zur Widerlegung dieser These notwendig, da auch eine Abnahme der Verbreitung nicht festgestellt werden konnte. Die formulierten Thesen bedürfen weiterer Bestätigung, wobei insbesondere folgende Fragen zu überprüfen sind: • Sind die festgestellten Unterschiede bei der Verbreitung von Evaluation und Evaluationsforschung im deutschen und englischen Sprachraum auf Unterschiede im Evaluationsbegriff zurückzuführen?

2

Ziel dieser beiden Untersuchungen war es vor allem, Art und Vorgehensweise bei der Evaluation festzustellen. In der Stichprobe waren daher Evaluationsinhalte überrepräsentiert.

34

Harald Schmidt /Irene

Häntschel

• Führt die Verwendung einer anderen Stichprobe für die Zeitschriftenanalyse zu wesentlich anderen Befunden? Da besonders im anglo-amerikanischen Sprachraum eine eindeutige Zuordnung der Zeitschriften zur Wirtschaftsinformatik nicht möglich ist, kann sich durch Unterschiede in der Orientierung der ausgewählten Zeitschriften (z.B. betriebswirtschaftlich, sozialwissenschaftlich oder technisch orientiert) ein anderes Bild ergeben. Weitere Untersuchungen können eine Bestätigung für Thesen liefern, die sich auf Grund der Befunde dieser Untersuchung formulieren lassen. Solche Thesen können wie folgt formuliert werden: • In der Praxis wird ausschließlich zum Zweck der Auswahl von Techniksystemen evaluiert. • Die Verwendung formaler Methoden reduziert die Anzahl der auftretenden Probleme beim Evaluationsprozeß. • Formale Methoden der Evaluierung sind wenig verbreitet. • Für die Evaluierung spezifische Werkzeuge werden in der Praxis kaum verwendet. Der Wirtschaftsinformatik als Wissenschaft und als wissenschaftliche Lehre kommt eine entscheidende Rolle dabei zu, Evaluation und Evaluationsforschung zu verbreiten. Die Wirtschaftsinformatik-Praxis wird von der Zweckmäßigkeit und Notwendigkeit von Evaluationen wohl erst dann zu überzeugen sein, wenn Evaluation in der Wirtschaftsinformatik-Forschung und Lehre selbstverständlich geworden sind. Literatur [Bortz84] Bortz, J.: Lehrbuch der empirischen Forschung. Berlin et al. 1984 [HeRo98] Heinrich, L. J. / Roithmayr, F.: Wirtschaftsinformatik-Lexikon. München/Wien 1998 [Mert96] Mertens, P. et al. (Hrsg.): Studienführer Wirtschaftsinformatik. Braunschweig/ Wiesbaden 1996 [Roth95] Roth, E. (Hrsg.): Sozial wissenschaftliche Methoden. München/Wien 1995 [Sull99] Sullivan, D.: Search Engine Watch, http://searchenginewatch.internet.com/ facts/major.html, Abruf am 1999-03-12

Evaluation von Artefakten in der Wirtschaftsinformatik Ulrich Frank [email protected]

Institut für Wirtschaftsinformatik der Universität Koblenz-Landau www.uni-koblenz.de/-iwi

„ There are potentially at least as many ways of dividing up the world into object systems as there are scientists to undertake the task. " Clyde H. C o o m b s , H o w a r d Raiffa, Robert M . Thrall

Inhalt 1 2 3 4 5

Evaluation - ein vielschichtiges Phänomen Die Bedeutung von Artefakten in der Wirtschaftsinformatik Zur Evaluation von Artefakten in der betrieblichen Praxis Evaluation als inhärenter Bestandteil wissenschaftlicher Forschung Abschließende Bemerkungen

Zusammenfassung Der Gegenstand der Wirtschaftsinformatik ist wesentlich durch Artefakte geprägt. Das gilt einerseits für den Anwendungsbereich der Disziplin, andererseits ist die Forschung selbst auf die Konstruktion und Beurteilung von Artefakten, wie von Modellen und Prototypen, gerichtet. Dieser Beitrag untersucht die spezifischen Schwierigkeiten, die mit einer wissenschaftlichen Beurteilung informationstechnologischer Artefakte verbunden sind. Ausgehend von einem Uberblick über das Phänomen Evaluation und die Bedeutung von Artefakten in der Wirtschaftsinformatik werden verschiedene Ansätze zur Evaluation von Artefakten betrachtet, wie der Entwurf von Bezugsrahmen oder empirische Untersuchungen. Dabei werden die Rahmenbedingungen betriebswirtschaftlich motivierter Evaluationen in der Praxis berücksichtigt. Daneben werden die Bedeutung und die eigentümlichen Schwierigkeiten thematisiert, die eine Evaluation solcher Artefakte mit sich bringt, die Ergebnisse einschlägiger Forschung in der Wirtschaftsinformatik sind. Dabei zeigt sich, daß Maßstäbe, wie sie von der Wissenschaftstheorie zur Beurteilung von Forschungsergebnissen vorgeschlagen werden, allenfalls teilweise verwendet werden können.

Abstract Artefacts are of pivotal importance for the information systems discipline. On the one hand, they constitute a major part of the domain that is the subject of information systems research. On the other hand, research itself is producing artefacts such as models and prototypes. This paper provides an investigation of the specific problems that are related to a rational evaluation of information technology artefacts. After an overview of evaluation and the

36

Ulrich Frank

role of artefacts in information systems research, selected approaches to evaluating artefacts are discussed. This includes both the economic evaluation of artefacts that are part of business information systems, and the evaluation of those artefacts that are produced in information systems research. It will be shown that general epistemological criteria to evaluate research results are of limited help.

1 Evaluation - ein vielschichtiges Phänomen Evaluation wird gemeinhin verstanden als die gezielte Ermittlung des Wertes von materiellen oder immateriellen Gegenständen unter Rückgriff auf Kriterien und Verfahren, deren Angemessenheit erläutert oder begründet werden sollte (vgl. [Hou93,l]). In dieser ersten Begriffsabgrenzung deuten sich schon die Schwierigkeiten an, die mit der Durchführung von Evaluationen verbunden sind. Gleichzeitig ist es offensichtlich, daß Evaluationen - auch wenn der Begriff eher selten verwendet wird - in vielfältiger Form nahezu alle Bereiche moderner Industriegesellschaften durchdringen. Sie sind typischerweise auf facettenreiche Sachverhalte gerichtet, also solche, die sich gegen eine einfache Erfassung wesentlicher Merkmale sperren. Sie reduzieren damit, jedenfalls vordergründig, Komplexität. Evaluationen dienen der Vorbereitung und nicht zuletzt der Legitimation von Entscheidungen. Es ist deshalb wenig überraschend, daß sie auch zur Instrumentalisierung von Interessen verwendet werden. Evaluation ist - jedenfalls dem Anschein nach - durch das Bemühen um Objektivität gekennzeichnet. Schon bei oberflächlicher Betrachtung liegt es auf der Hand, daß die Chance, Evaluationen durchzuführen, die gemeinhin als objektiv bezeichnet würden, wesentlich von der Art des zu bewertenden Sachverhalts abhängen. Offensichtlich ist dies für die Kulturpolitik eines Landes schwieriger als für ein Medikament zur Behandlung von Schnupfen. Evaluation setzt Wahrnehmung und Urteilsvermögen voraus. Seit den Anfangszeiten abendländischer Wissenschaften wurden immer wieder die Möglichkeiten und Beschränkungen dieser menschlichen Fähigkeiten thematisiert. Dabei ist einerseits an erkenntnistheoretische Fragen nach den grundlegenden Grenzen unseres Urteilsvermögens zu denken. Beispielhaft dafür sind die Arbeiten Kants zur „Kritik der reinen Vernunft" sowie zur „Kritik der Urteilskraft". Daneben sind Arbeiten in der kognitiven Psychologie zu nennen, die auf die Erfassung von Verzerrungen und Anomalien der Urteilsfähigkeit gerichtet sind. Hier ist u.a. an umfangreiche Untersuchungen zu denken, die das Entscheidungsverhalten unter Unsicherheit zum Gegenstand haben. Dabei hat sich u.a. die verbreitete Disposition gezeigt, in komplexen Entscheidungssituationen zu selektiver Wahrnehmung zu neigen, wobei vor allem die leicht verfügbaren Informationen berücksichtigt werden („availability", [TvKa82]). Wenn Gegenstand und Zielsetzung einer Evaluation festgelegt sind, ist damit nicht notwendigerweise gesagt, welche Merkmale bzw. Indikatoren betrachtet und wie ihre Ausprägungen erfaßt werden sollen. Diese Anfor-

Evaluation

von Artefakten

37

derung an die für eine Evaluation ausgewählten Indikatoren ist vergleichbar mit gängigen Anforderungen an die Erhebung von Merkmalen im Rahmen empirischer Forschung, wie Reliabilität und Validität. So läßt sich eine Vielzahl von Merkmalen denken, um die Qualität von Forschung und Lehre an einer Universitätseinrichtung zu beurteilen. Dieser Umstand hat subtile Konsequenzen. Mit der Auswahl von Merkmalen ist der Anspruch verbunden, eine angemessene Bewertung des betrachteten Sachverhalts zu realisieren. Die Merkmale haben danach einen instrumenteilen Charakter. Tatsächlich hat aber die Auswahl der Merkmale einen erheblichen, wenn auch latenten Einfluß auf das Ergebnis der Evaluation. Überzeichnend formuliert: Nicht das Ziel der Evaluation bestimmt die auszuwählenden Merkmale, sondern die ausgewählten Merkmale legen das Ziel der Evaluation fest und mögen damit letztlich den zu beurteilenden Gegenstand beeinflussen, indem die Gestaltung des Gegenstands an den Indikatoren ausgerichtet wird. Die damit verbundenen, mehr oder weniger deutlichen Verzerrungen des eigentlichen Gegenstands der Evaluation erinnern an eine traditionsreiche Diskussion in der Ökonomie: die Frage nach der Wertneutralität von Mitteln bei gegebenen Zielen. Schon früh hat Myrdal darauf verwiesen, daß eine solche Trennung nicht möglich ist: „Die Wertsetzung bezieht sich jeweils auf einen ganzen Verlauf ...", [Myr33,310]. In diesem Zusammenhang ist auch der „instrumentalistische Trugschluß" [Alb60,217] zu nennen. In angelsächsischen Ländern gibt es seit langem eine rege Evaluationsforschung. Sie ist vor allem auf Evaluationsverfahren gerichtet, die im weitesten Sinne der Politikberatung dienen. Eine besondere Rolle spielen dabei das Bildungs- und das Gesundheitswesen (ein Überblick findet sich in [Hou93]). Die erhebliche Bedeutung, die derartige Evaluationen in den USA erlangt haben, spiegelt sich u.a. in dem Umstand, daß mit der „American Evaluation Association" eine Art Standesorganisation für diejenigen entstanden ist, die professionell Evaluationen durchführen. Die Ziele, denen sich dieser Verband mit mehreren tausend Mitgliedern [Hou93,vii] verschrieben hat, sind bemerkenswert. So wird u.a. angestrebt, „evaluation as a profession" zu etablieren und einen Beitrag zur „generation of theory and knowledge about effective human action" (http://www.eval.org/) zu leisten. Ein weiteres Indiz für die Professionalisierung von Evaluationen ist in der Existenz einer dedizierten Fachzeitschrift (American Journal of Evaluation) und einer beachtlichen Anzahl einschlägiger Monographien (z.B. [Hou93], [PaTi97], [Scr80]) zu sehen. Auch im deutschsprachigen Raum spielen aufwendige Evaluationsverfahren eine wichtige Rolle - nicht zuletzt in der Politikberatung. Dabei wird allerdings zumeist der Begriff „Gutachten" verwendet. Der Terminus Evaluationsforschung ist vor allem mit einem Teilgebiet der Psychologie verbunden (allgemein: Gesundheitswesen - ein Überblick findet sich in [Koc90]). Daneben gibt es in den Sozial- und Wirtschaftswissenschaften eine Fülle ähnlich ausgerichteter Forschung. Dazu zählen u.a. Untersuchungen der vielfältigen Folgewirkungen des Technologie-Einsatzes wie auch solche, die auf eine Bewertung wirtschaftspolitischer Maßnahmen zielen. In jüngerer

38

Ulrich Frank

Zeit hat auch im deutschsprachigen Raum die explizite Verwendung des Begriffs Evaluation deutlich zugenommen. Dabei ist vor allem an die Beurteilung der Forschung und Lehre an Hochschulen bzw. an die Beurteilung von Hochschullehrern und Hochschulen zu denken. Jenseits dedizierter Forschungsprojekte und institutioneller Rahmenbedingungen ist Evaluation gleichsam inhärenter Bestandteil wissenschaftlicher Forschung. Forschung impliziert nach gängigem Verständnis das Bemühen um Erkenntnisfortschritt. Das wiederum erfordert die vergleichende Bewertung alternativer Angebote zur Beschreibung bzw. Erklärung der interessierenden Phänomene. In der Wirtschaftsinformatik spielt Evaluation, neben dieser grundsätzlichen Bedeutung, auch im Anwendungsbereich eine wichtige Rolle: Entscheidungen im Informationsmanagement erfolgen in einem Umfeld von Systemen und Verfahrensweisen, deren Beurteilung in technischer wie auch in wirtschaftlicher Hinsicht erhebliche Herausforderungen mit sich bringt. Die Wirtschaftsinformatik erbt dabei gleichsam die spezifischen Evaluationsprobleme der Informatik und der Ökonomie (Aufwand, Nutzen!). Daneben sieht sich die Forschung in der Wirtschaftsinformatik einigen eigentümlichen Evaluationsproblemen gegenüber, die sich einerseits aus ihrem interdisziplinären Standort zwischen den Wirtschaftswissenschaften und der Informatik ergeben, andererseits eine Folge der Besonderheiten des Fortschritts im Bereich der Informationstechnologie darstellen. Dieser Beitrag analysiert ein spezifisches Evaluationsproblem der Wirtschaftsinformatik, nämlich die Beurteilung informationstechnischer Artefakte wie Software, Architekturen von Informationssystemen und Datenmodelle. Nach einem Uberblick über die Besonderheiten, die mit informationstechnischen Artefakten einhergehen, werden zunächst die Anforderungen und Rahmenbedingungen der Evaluation solcher Artefakte in der betrieblichen Praxis betrachtet. Anschließend wird die Evaluation der Artefakte betrachtet, die Gegenstand und Resultat einschlägiger Forschung in der Wirtschaftsinformatik sind.

2 Die Bedeutung von Artefakten in der Wirtschaftsinformatik Der Gegenstand der Wirtschaftsinformatik ist wesentlich durch Artefakte geprägt, um nicht zu sagen konstituiert: Informationsbestände in unterschiedlichen Ausprägungen, Informationssysteme, Architekturen, SoftwareWerkzeuge, Standards, Informationsmodelle, wie auch Modellierungssprachen und diverse Analyse- und Entwurfsmethoden. Auch andere Disziplinen, wie die Betriebswirtschaftslehre, die Rechtswissenschaften und vor allem die Ingenieurwissenschaften, sind zu einem erheblichen Teil durch die Auseinandersetzung mit Artefakten geprägt. Die Artefakte, denen sich die Wirtschaftsinformatik gegenübersieht, sind allerdings durch einige Besonderheiten gekennzeichnet. So wird die Erfassung existierender Artefakte durch die häufig erhebliche Komplexität informationstechnologischer Systeme bzw. Konzepte erschwert, ein Problem, das

Evaluation von Artefakten

39

durch den raschen technologischen Wandel noch verschärft wird. Dabei ist auch zu berücksichtigen, daß marktgängige Technologien häufig eine spezielle Begrifflichkeit prägen, die einerseits den Nachvollzug der wesentlichen Zusammenhänge behindert und andererseits zu der verwirrenden Begriffsvielfalt in der Informationstechnologie beiträgt. Zudem ist daran zu denken, daß häufig verwendete Artefakte, wie Texteditoren und Datenbanken, Wahrnehmung und Urteilsvermögen auch der beteiligten Wissenschaftler nachhaltig beeinflussen: Sie konstruieren eine bestimmte Realität, die nach einer gewissen Zeit als selbstverständlich angesehen wird, obgleich grundsätzlich auch andere Ausprägungen denkbar wären. Aus der Sicht der Unternehmen führt diese Komplexität zu einem hohen Maß an Unsicherheit und damit zu einem erheblichen Beratungsbedarf. Die seriöse Beschreibung einzelner Produkte mag deshalb eine sinnvolle Aufgabe von Wissenschaft sein. Gleichzeitig ist allerdings zu berücksichtigen, daß die Auseinandersetzung mit solch singulären, allerdings eben ausgesprochen komplexen Facetten des Gegenstandsbereichs geeignet ist, den Blick f ü r wesentlichere Zusammenhänge zu verstellen. Beispiele für diese Gefahr finden sich in erheblicher Anzahl (z.B. objektorientierte Technologien, betriebswirtschaftliche „Standardanwendungen" oder Internet-Technologien). Die Wirtschaftsinformatik als anwendungsorientierte Disziplin befindet sich hier in einer schwierigen Situation. Einerseits kann sie sich nicht auf ein Abstraktionsniveau zurückziehen, wie es in weiten Teilen der Informatik üblich ist, da sie sich sonst zu weit von ihrer Praxis entfernt. Andererseits opfert sie den Anspruch auf Wissenschaftlichkeit, der ja wesentlich durch das Bemühen um Abstraktion und eine sorgsam entwickelte Terminologie gekennzeichnet ist, wenn sie sich allein darauf beschränkt, faktische Erscheinungsformen von Informationstechnologie zu untersuchen. Das skizzierte Problem erhält dadurch zusätzliches Gewicht, daß seit einiger Zeit die Durchführung von Projekten mit Beratungscharakter durch politische Vorgaben gefördert wird, die Drittmittelerwerb zu einem Wert eo ipso erheben. In solchen Projekten wird häufig, mit gutem Grund, die Praxis die Randbedingungen der Kooperation wesentlich prägen, also etwa die zu verwendenden Werkzeuge und damit auch die Begrifflichkeit, die diesen Werkzeugen zugrunde liegt.

3 Zur Evaluation von Artefakten in der betrieblichen Praxis Aus betriebswirtschaftlicher Sicht stellen Informationssysteme, Werkzeuge, Entwurfsmethoden etc. keinen Selbstzweck dar. Sie dienen vielmehr der Erreichung jener - gegebenenfalls konfligierenden - Ziele, auf die die Handlungskomplexe ausgerichtet sind, in die sie eingebettet sind. Die Evaluation von Artefakten spielt einerseits bei Auswahlentscheidungen eine Rolle, andererseits empfiehlt die betriebliche Kosten- und Leistungsrechnung eine regelmäßige Bewertung nach Maßgabe relevanter Kriterien. Insofern kommt der Erfassung der für einen Bewertungszweck als wichtig angesehenen Alternativen sowie deren angemessener Beurteilung eine erhebliche Bedeu-

40

Ulrich Frank

tung zu. Gleichzeitig ist der mit einem solchen Evaluationsverfahren verbundene Aufwand häufig so hoch, daß er von einem Unternehmen allein nicht vollständig erbracht werden kann. Daraus ergibt sich ein Bedarf an externer Unterstützung. Während am Markt eine Vielzahl von Unternehmen, wie Marktinformationsdienste oder einschlägige Beratungsfirmen, entsprechende Hilfen anbieten, werden im folgenden die Möglichkeiten einer wissenschaftlichen Unterstützung des dargestellten Bewertungsproblems betrachtet. з . 1 Bezugsrahmen zur Unterstützung von Evaluationen Eine systematische Evaluation empfiehlt zunächst die Festlegung der Anforderungen, die das zu bewertende Artefakt erfüllen soll. Anschließend sind Kriterien zu ermitteln, die im Hinblick auf die Erfüllung der Anforderungen bedeutsam sind. Entsprechende Kriterienlisten, zusammen mit mehr oder weniger gehaltvollen Erläuterungen zu ihrer Anwendung, werden i.d.R. Bezugsrahmen genannt. Solche Bezugsrahmen zur Unterstützung der Evaluation informationstechnischer Artefakte existieren in großer Zahl. Sie sind и.a. auf die vergleichende Bewertung von Anwendungssoftware (z.B. [Rae95]), Werkzeugen der Software-Erstellung (z.B. [Her94], [Sch91]), Benutzungsschnittstellen (z.B. [OpRe92]) oder auf die Evaluation von Modellierungssprachen und Modellierungsmethoden (z.B. [HoGo93], [MoPu92], [MoSh94]) gerichtet. Die in einem Bezugsrahmen angegebenen Kriterien sind auf verschiedenen Abstraktions- und Detaillierungsstufen denkbar. Während einige Kriterien mit gut nachvollziehbaren Meßvorschriften einhergehen (z.B. Benchmarks), sperren sich andere Kriterien gegen eine objektivierte Erfassung (z.B. „Verständlichkeit der Dokumentation"). Gleichzeitig ist zu berücksichtigen, daß auch solche Kriterien, deren Ausprägung in eindeutiger Weise erfaßt werden kann, im Hinblick auf ihre Beziehung zu den jeweiligen Evaluationsanforderungen erhebliche Interpretationsspielräume offenlassen können (z.B. Metriken zur Ermittlung von Software-Qualität). Die direkte Unterstützung einer Auswahlentscheidung durch einen Bezugsrahmen wird zudem häufig dadurch erschwert, daß ein Artefakt u.U. verschiedenen Zwecken dienen soll, die unterschiedliche Bewertungskriterien nahelegen. Dabei sind auch die Besonderheiten der Handlungskomplexe, innerhalb derer die Artefakte genutzt werden, zu beachten. Hier ist beispielsweise an die Kompatibilität mit existierenden Artefakten oder an Konflikte bei der Nutzung knapper Ressourcen zu denken. Nicht zuletzt sind es die Fähigkeiten, Präferenzen und Dispositionen, oder allgemeiner die Perspektiven der verschiedenen Benutzer, die für eine differenzierte Bewertung zu berücksichtigen sind. Auswahlentscheidungen erfordern eine Aggregation der zunächst an mehreren Kriterien orientierten Bewertung. Nicht selten werden solche Aggregationen durch das Berechnen von Mittelwerten durchgeführt. Mitunter werden zusätzlich Gewichte für die verschiedenen Kriterien eingeführt. Oft sind die Skalenniveaus der verfügbaren Daten für die verwendeten Opera-

Evaluation von Artefakten

41

tionen aber nicht hinreichend, etwa wenn Mittelwerte ordinalskalierter Daten berechnet werden. Auch ist die verwendete Gewichtung häufig nicht hinreichend zu begründen. Dennoch dürfte ein gewisses Maß an Verdichtung vielen, die eine Entscheidungsunterstützung wünschen, entgegenkommen, auch um den Preis damit einhergehender Verzerrungen. Dieser Umstand weist auf ein gewisses Dilemma der Evaluation hin: Einerseits ist das Bemühen um Objektivität eine wesentliche Orientierung für Evaluationsvorhaben, andererseits gibt es die Erwartung, daß Evaluationsergebnisse möglichst eindeutig sein sollen. Anders gesagt: Je seriöser, differenzierter und damit zurückhaltender eine Evaluation ausfällt, desto schlechter mag sie geeignet sein, die von manchem Entscheidungsträger gewünschte Unterstützung zu bieten. Der Entwurf solcher Bezugsrahmen stellt sicher eine wichtige Aufgabe f ü r die Wirtschaftsinformatik dar. Nicht nur, daß Artefakte einen wesentlichen Teil des Gegenstands der Disziplin konstituieren, darüber hinaus gibt es in der Praxis eine deutliche Nachfrage nach einer entsprechenden Unterstützung. Gleichzeitig kann nicht übersehen werden, daß der Entwurf von Bezugsrahmen mit erheblichen Herausforderungen verbunden ist. Informationstechnische Artefakte durchdringen die Praxis der wissenschaftlichen Wirtschaftsinformatik in subtiler Weise: Wir sind an den Umgang mit gewissen Geräten und Software so sehr gewöhnt, daß es mitunter schwerfällt, von den täglich erfahrenen Ausprägungsformen dieser Artefakte zu abstrahieren. Zudem wird es häufig kaum möglich sein, objektiv nachzuweisen, daß eine vorgeschlagene Kriterienliste vollständig ist. Daneben mag es als wichtig erachtete Kriterien geben, deren nachvollziehbare Erfassung am Evaluationsobjekt kaum zu beschreiben ist. Hier ist an Kriterien wie Benutzerfreundlichkeit oder Anschaulichkeit zu denken. Während in solchen Fällen in weniger anspruchsvollen Bezugsrahmen ordinalskalierte Schätzungen als Maß dienen, werden in wissenschaftlich ausgerichteten Bezugsrahmen einzelne Kriterien mitunter durch Operationalisierung in meßbare Größen überführt. Ein Beispiel dafür liefern die bereits erwähnten Metriken zur „Messung" von Software-Qualität. Dabei ist allerdings nicht zu übersehen, daß möglicherweise die gemessenen Größen nicht mehr das repräsentieren, was eigentlich erfaßt werden sollte. Die Erstellung wissenschaftlich akzeptabler Bezugsrahmen sollte eine Reihe von Kriterien berücksichtigen, insbesondere: • Zielorientierung. Die Evaluationsziele sollten explizit gemacht und gegebenenfalls erläutert werden. • Begründung. Die vorgeschlagenen Kriterien sollten grundsätzlich in nachvollziehbarer Weise begründet werden. • Seriosität. Auch wenn es das Bemühen um Praxisorientierung nahelegt, den Erwartungen an möglichst eindeutige Evaluationsverfahren nachzugeben, sollte auf keinen Fall ein wissenschaftlicher Anspruch geopfert werden. Er empfiehlt einen zurückhaltenden Umgang mit Operationalisierungen und verbietet arithmetische Operationen, die das verwendete

42

Ulrich Frank

Skalenniveau nicht zuläßt. Dazu gehört auch der explizite Hinweis auf Grenzen bzw. Schwächen eines Bezugsrahmens. Die Anwendung von Bezugsrahmen auf konkrete Artefakte (z.B. zum Zweck eines Produktvergleichs) kann auch Gegenstand einer wissenschaftlichen Untersuchung sein. Dabei ist allerdings Zurückhaltung geboten. Die Dynamik der einschlägigen Märkte führt dazu, daß auch seriös durchgeführte Evaluationen rasch obsolet werden. 3.2 Empirische

Untersuchungen

Da Artefakte in betriebswirtschaftlichen Kontexten i.d.R. keinen Selbstzweck darstellen und ihre wissenschaftliche Bewertung überdies mit erheblichen Problemen behaftet ist, scheint eine indirekte, ex post durchgeführte Evaluation sinnvoll. Dabei kann von spezifischen Eigenschaften, wie softwaretechnischen Konzepten, weitgehend abstrahiert werden. Statt dessen wird untersucht, welchen Erfolgsbeitrag Artefakte in bestimmten Nutzungskontexten aufweisen. Entsprechende empirische Untersuchungen basieren auf der Hypothese, daß sich der praxisrelevante Wert eines informationstechnischen Artefakts erst bei einer Nutzung unter realen Bedingungen offenbart. Vor allem im Information Systems Research angelsächsischer Prägung gibt es zahlreiche empirische Untersuchungen, die auf eine Evaluation in diesem Sinne gerichtet sind, häufig verbunden mit dem Schlagwort „IS effectiveness" (vgl. z.B. [Sed98]). Die Bandbreite der einschlägigen Forschung ist beachtlich. Sie zielt u.a. auf den Einfluß bestimmter Software-Arten auf individuelle Arbeitsstile und Kreativität (vgl. [Mas96]), die Auswirkungen der konzeptionellen Modellierung auf die Problemlösungsfähigkeit verschiedener Interessengruppen (vgl. [Web98]) und - immer wieder - die Wirkung des Einsatzes von Artefakten auf die Produktivität (vgl. [Wie92]). Auch wenn derartige Untersuchungen wichtige Aufschlüsse darüber liefern, wie bestimmte Artefakte genutzt werden, haftet ihnen doch ein gewichtiges Problem an: jenseits statistisch meßbarer Korrelationen festzustellen, ob eine erfaßte Variable tatsächlich kausal vom Einsatz eines Artefakts abhängt (vgl. [DeMc92]). Aus der Sicht eines Unternehmens, das vor einer Investitionsentscheidung steht, ist es interessant, einen Hinweis auf die beste Option zu erhalten. Da in diesem Zusammenhang die Vermeidung größerer Risiken häufig eine erhebliche Rolle spielt, kommt der Bewährung in der Praxis eine große Bedeutung zu. Es geht also nicht vorrangig um die - wie auch immer zu ermittelnden - besten Konzepte oder Technologien, sondern um den Rückgriff auf solche Lösungen, die sich bereits als besonders erfolgreich erwiesen haben. Seit einiger Zeit wird in der Forschungsförderung häufig auf best practice als Bewertungsgrundlage hingewiesen. Auch in der Wirtschaftsinformatik wird dieses Kriterium in Erwägung gezogen (vgl. [Buh97], [ReWi97], [Mer97]). Darin drückt sich auch die Betonung einer anwenderorientierten bzw. marktorientierten Sicht aus. In diesem Sinn unterstreicht die EU-

Evaluation von Artefakten

43

Kommission in einer Ausschreibung für die Entwicklung von Entwurfswerkzeugen die Bedeutung von best practice [Eur97]: „Best practice in the use of appropriate design tools and methods is a key factor for the efficient, reliable and rapid realisation of fault-free systems which reach the market ahead of the competition and at the right price." Es mag interessant sein, zu untersuchen, welche Technologien unter den Randbedingungen der Praxis zu herausragenden Resultaten führen. Dabei ist allerdings - wie grundsätzlich bei empirischen ex post Untersuchungen - zu berücksichtigen, daß auch bei statistisch signifikanten Zusammenhängen eine Kausalität zwischen dem Einsatz eines Artefakts und einem betriebswirtschaftlich relevanten Erfolgskriterium kaum unterstellt werden kann, da das Gefüge weiterer Einflußfaktoren zu komplex ist. Unabhängig von solchen methodischen Schwierigkeiten bleibt eine grundsätzliche Kritik am best practice Kriterium: Da es sich um eine Bewertung nach einem längeren Praxiseinsatz handelt, eignet es sich nicht für die frühzeitige Beurteilung neuer Artefakte, denen angesichts der hohen Dynamik in der Informations- und Kommunikationstechnologie eine besondere Bedeutung zukommt.

4 Evaluation als inhärenter Bestandteil wissenschaftlicher Forschung Es sind nicht nur Produkte oder am Markt vorherrschende Konzepte, die den Umgang der Wirtschaftsinformatik mit Artefakten prägen. Daneben ist die Forschung in der Wirtschaftsinformatik durch eine Fülle selbst geschaffener Artefakte, wie Modelle und Prototypen, gekennzeichnet. Die Konstruktion solcher Artefakte ist m.E. ein zentraler Bestandteil der Forschung in unserem Fach. Die Erkenntnisse, die dabei gewonnen werden können, fördern ein tieferes Verständnis von Informationssystemen und liefern einen Beitrag zu einer elaborierten Entwurfslehre. Tatsächlich ist der Entwurf von Artefakten in der Wirtschaftsinformatik (ähnliches gilt für die Angewandte Informatik) auch von weniger erfreulichen Erscheinungen begleitet. So sind viele wissenschaftliche Arbeiten und auch Lehrbücher auf die - zumeist nur rudimentäre - Darstellung solcher Entwürfe gerichtet. Eine kritische Auseinandersetzung oder gar ein detaillierter Vergleich einzelner Arbeiten bleibt allerdings i.d.R. aus. Besonders augenfällig wird dieser Umstand auf einschlägigen Konferenzen: Nacheinander werden grobe Zusammenfassungen einzelner Modelle oder Prototypen präsentiert. Auf diese Weise entsteht mitunter der Eindruck (und dies ist die (selbst-) kritische Feststellung eines Betroffenen), daß die Forschung einer Spielwiese für die Schaffung von Artefakten gleicht, die vor allem der Befriedigung der Konstrukteure dient. Man könnte die Auffassung vertreten, daß die in der Wirtschaftsinformatik als Ergebnisse einschlägiger Forschung geschaffenen Artefakte in gleicher Weise zu evaluieren seien wie jene, die in der betrieblichen Praxis eingesetzt werden. Ein solcher Ansatz sieht sich allerdings zwei schwerwiegenden

44

Ulrich Frank

Einwänden ausgesetzt. So werden die meisten Forschungsartefakte den Weg in die Anwendung entweder gar nicht oder allenfalls mit erheblicher zeitlicher Verzögerung und zudem in modifizierter Form finden. Daneben - und dies ist m.E. der wichtigere Einwand - sollte sich auch eine anwendungsorientierte Wissenschaft um Kriterien zur Evaluation ihrer Forschungsergebnisse bemühen, die nicht allein die praktische Verwertung umfassen. Die Bewertung der Ergebnisse wissenschaftlicher Forschung ist zentraler Bestandteil der Wissenschaftstheorie. Bevor auf die spezifischen Herausforderungen eingegangen wird, die sich durch die Evaluation von Artefakten ergeben, werden deshalb zunächst Orientierungen betrachtet, die von der Wissenschaftstheorie zur Beurteilung wissenschaftlicher Aussagen angeboten werden. 4 . 1 Zur Beurteilung wissenschaftlicher Aussagen Die Anwendung angemessener Kriterien zur Beurteilung von Forschungsergebnissen ist ein wesentliches, wenn auch mitunter implizites Kennzeichen von Wissenschaft. Das gilt in zweifacher Hinsicht. So sind einerseits Abgrenzungskriterien erforderlich: Was sind wesentliche Merkmale wissenschaftlicher Erkenntnis, was unterscheidet sie von den „Träumereien eines Geistersehers" (Kant). Daneben - und damit zusammenhängend - impliziert das Bemühen um Erkenntnisfortschritt die vergleichende Beurteilung konkurrierender Erkenntnisangebote. Bei der Untersuchung dieser Frage sind einige miteinander verwobene Aspekte zu berücksichtigen (vgl. [Ham82]). So ist zu klären, welche Sachverhalte überhaupt als Gegenstand wissenschaftlicher Untersuchungen zu akzeptieren sind. Anders ausgedrückt: Welche Sachverhalte sind prinzipiell einer Beurteilung durch wissenschaftliche Verfahren zugänglich, welche nicht? Wodurch wird subjektives Wissen zu wissenschaftlicher Erkenntnis? Welches ist die angemessene sprachliche Form der Darstellung und Vermittlung wissenschaftlicher Erkenntnisse? Jenseits der in der Vergangenheit mitunter heftig geführten Grabenkämpfe zwischen den verschiedenen wissenschaftstheoretischen Schulen' lassen sich m.E. deutliche Gemeinsamkeiten im Hinblick auf grundsätzliche Anforderungen an realwissenschaftliche Aussagen rekonstruieren 2 - die Unterschiede zeichnen sich eher in der Umsetzung ab. Danach sollte eine sprachliche Darstellung von Erkenntnissen in den Realwissenschaften folgende Merkmale aufweisen: • Es sollten generelle Aussagen, also Aussagen über Klassen von realen Sachverhalten, enthalten sein.

1 Hier ist im deutschsprachigen R a u m vor allem an den Kritischen Rationalismus, die Kritische Theorie und den Konstruktivismus zu denken. 2 Diese Annahme beruht darauf, daß meines Wissens die im folgenden dargestellten Anforderungen in den wissenschaftstheoretischen Auseinandersetzungen im wesentlichen von keiner Partei in Frage gestellt wurden.

Evaluation von Artefakten

45

• Die beschriebenen Merkmale bzw. Eigenschaften dieser Sachverhalte sollten in ihrem Verhältnis zu Zeit und räumlicher Verteilung möglichst stabil, also invariant sein. • Eine - wie auch immer geartete - intersubjektive Überprüfung der Aussagen sollte möglich sein. • Es sollte neues und möglichst informatives Wissen enthalten sein, wobei die Vorstellungen darüber, was informativ bedeutet, divergieren. Nach der vom Kritischen Rationalismus vertretenen Ansicht nimmt der Informationsgehalt einer Aussage mit der Anzahl der durch sie ausgeschlossenen denkmöglichen Konstellationen zu. • Die Aussagen sollten bewährt sein, d.h. eine Reihe von Überprüfungsversuchen erfolgreich überstanden haben. Im Hinblick auf die Überprüfung wissenschaftlicher Aussagen gibt es eine Reihe unterschiedlicher Auffassungen. Häufig wird auf den Ansatz des Kritischen Rationalismus verwiesen, wonach eine Überprüfung durch die Konfrontation mit der Realität als objektiver Instanz zu erfolgen hat („Fallibilismus"). Das setzt geeignete Abbildungs- bzw. Meßvorschriften voraus, um die Korrespondenz der Hypothesen mit der Wirklichkeit in einem intersubjektiv nachvollziehbaren Verfahren feststellen zu können. Daneben wird in den Wirtschafts- und Sozialwissenschaften mitunter auf diskursive Überprüfungs- bzw. Begründungsverfahren, auf die im nächsten Abschnitt eingegangen wird, verwiesen. Die skizzierten Anforderungen sind hilfreich für die Abgrenzung wissenschaftlicher Aussagen. Zudem liefern sie eine Orientierung für deren Bewertung, denn die einzelnen Kriterien sind in unterschiedlichen Intensitäten denkbar. Gleichzeitig ist ihre Anwendbarkeit eingeschränkt. So ist die vergleichende Beurteilung des Informationsgehalts oder der intersubjektiven Überprüfbarkeit von Aussagen in den Wirtschafts- und Sozialwissenschaften ausgesprochen problematisch. Darüber hinaus begrenzt sie den Zuständigkeitsbereich von Wissenschaft auf solche Urteile, die auf eine Beschreibung faktischer Realität zielen. Es wird sich zeigen, daß gerade in der Wirtschaftsinformatik eine solche Einschränkung häufig nicht praktikabel ist. 4 . 2 Diskursive

Urteilsfindung

Im Unterschied zur oben skizzierten Wissenschaftsauffassung des Kritischen Rationalismus gehen die Vertreter hermeneutischer Ansätze davon aus, daß sich soziale Realität allenfalls oberflächlich durch Messung im Sinne der Naturwissenschaften beschreiben läßt. Statt dessen sei es erforderlich, sich um angemessene Interpretationen der betrachteten Sachverhalte zu bemühen. Angemessenheit wird dabei in einem diskursiven Prozeß sachkundiger Wissenschaftler beurteilt. Um solche Prozesse dem Ideal rationaler Urteilsfindung anzunähern, nennen sowohl die Kritische Theorie („herrschaftsfreie Kommunikation") wie auch der Konstruktivismus („vernünftige Beratung") eine Reihe von Bedingungen (vgl. [Hab81], [Lor74]):

46

Ulrich Frank

• Die Teilnehmer sollten bemüht sein, in gemeinsamer Beratung einen Konsens zu erzielen. • Es sollten keine Aussagen wider besseres Wissen gemacht werden (sie sollten nicht persuasiv sein). • Die Teilnehmer sollten bemüht sein, eigene Interessen zu transzendieren und die Sichtweisen anderer Teilnehmer nachzuvollziehen. • Die Teilnehmer sollten sachkundig sein. • Die Diskurse sollten herrschaftsfrei sein. Lediglich der „eigentümlich zwanglosen Zwang des besseren Arguments" [Hab81,52f.] ist zugelassen. Im Unterschied zu den vom Kritischen Rationalismus vorgeschlagenen Prüfungsverfahren ist der Gegenstand wissenschaftlicher Urteilsfindung nicht auf falsifizierbare Aussagen über die Wirklichkeit eingeschränkt. Prinzipiell können danach auch Werturteile vernünftig begründet werden. Damit sind solche Ansätze diskursiver Begründung grundsätzlich gut geeignet, eine wenn auch abstrakte - Methode für Evaluationen zu liefern. Gleichzeitig ist ihre Unzulänglichkeit kaum zu übersehen. Im wesentlichen münden sie in die Frage, wie entschieden werden soll, daß die Teilnehmer die geforderten Voraussetzungen erfüllen.

5 Abschließende Bemerkungen Die dominierende Rolle, die Artefakten im Gegenstandsbereich der Wirtschaftsinformatik zukommt, macht eine Evaluation konkurrierender Angebote unvermeidlich. Das gilt für Entscheidungssituationen in der Praxis wie für die Forschung in einer Disziplin, zu deren wesentlichen Gegenständen die Untersuchung von Gestaltungs- und Einsatzbedingungen solcher Artefakte zählt. Es wäre jedoch Ausdruck eines naiven Positivismus, würde man eine vollständige und dabei objektive Evaluation für möglich halten. Die Möglichkeiten der Wirtschaftsinformatik sind hier ausgesprochen bescheiden. Dennoch - oder gerade deshalb - sollte die Evaluation von Artefakten in der Wirtschaftsinformatik mit großem Nachdruck und der nötigen kritischen Distanz betrieben werden. Nur so kann einer Forschungspraxis entgegengewirkt werden, in der der Entwurf von Artefakten zum Selbstzweck wird, ohne daß nach Erkenntnisfortschritt gefragt wird. Während der Rekurs auf Bewährung in der Praxis (best practice) oder die Befragung von Orakeln (Ergebnisse sogenannter Expertenbefragungen) wichtige Randbedingungen für den erfolgreichen Einsatz von Artefakten in Unternehmen aufzeigen mögen, sind solche Ansätze für die Bewertung von Forschungsergebnissen nicht zu akzeptieren, da sie zur Preisgabe eines wissenschaftlichen Anspruchs führen. Die in der hermeneutischen Wissenschaftstheorie skizzierten Verfahren diskursiver Urteilsfindung liefern eine Orientierung auch für die Evaluation von Artefakten, die im Rahmen der Forschung entstanden sind. Ihre Anwendung ist allerdings mit einem erheblichen Aufwand verbunden und zudem nicht frei von Schwächen.

Evaluation

von Artefakten

47

Literatur [Alb60] Albert, H.: Wissenschaft und Politik. Zum Problem der Anwendbarkeit einer wertfreien Sozialwissenschaft. In: Topitsch, E. v. (Hrsg.): Probleme der Wissenschaftstheorie. Wien 1960,201 - 2 3 2 [Buh97] Buhl, H. U.: Best practices vs. common practices bei der Softwareentwicklung. In: WRTSOi^FISINFCRMAnK 6/1997, 639 - 640 [DeMc92] DeLone, W . H. / McLean, E. R.: Information Systems Success: T h e Quest for the Dependent Variable. In: Information Systems Research 1/1992, 60 - 95 [Eur97] European Commission: ESPRIT E S D Best Practice. Technologies for Components and Subsystems (TCS). „Broadening the Use of Design Technologies". Brüssel, Sept. 1997 (http://www.cordis.lu/esprit/src/esd-best.htm) [Hab81] Habermas, J.: Theorie des kommunikativen Handelns. Bd. 1: Handlungsrationalität und gesellschaftliche Rationalisierung. Frankfurt/M. 1981 [Ham82] Hamminga, B.: Neoclassical Theory Structure and Theory Development: The Ohlin Samuelson Programme in the Theory of International Trade. In: Stegmüller, W . et al. (eds): Philosophy of Economics. Berlin et al. 1982, 1 - 15 [Her94] Herzwurm, G. (Hrsg.): CASE-Technologie in Deutschland: Orientierungshilfe und Marktüberblick für Anbieter und Anwender. Universität zu Köln 1994 [HoGo93] Hong, S. / Goor, G.: A Forma! Approach to the Comparison of Object-Oriented Analysis and Design Methodologies. In: Nunamaker, J. F. / Sprague, R. H. (eds): Information Systems: Collaboration Technology, Organizational Systems, and Technology. Proc. of the 26th Hawaii International Conference on System Sciences. Los Alamitos 1993, 6 8 9 - 6 9 8 [Hou93] House, E. R.: Professional Evaluation: Social Impact and Political Consequences. Newbury Park/CA 1993 [Koc90] Koch, U. (Hrsg.): Evaluationsforschung. Bewertungsgrundlage von Sozial- und Gesundheitsprogrammen. Berlin et al. 1990 [Lor74] Lorenzen, P.: Konstruktive Wissenschaftstheorie. Frankfurt/M. 1974 [Mai96] Maier, R.: Qualität von Datenmodellen. Wiesbaden 1996 [Mas96] Massetti, Β.: An Empirical Examination of the Value of Creativity Support Systems on Idea Generation. In: MIS Quarterly 1/1996, 83 - 98 [Mer97] Mertens, P.: Best practice. In: WIRTSCHAFISINFCRMAriK 6/1997, 641 [MoPu92] Monarchi, D. E. / Puhr, G.: A Research Typology for Object-Oriented Analysis and Design. In: Communications of the A C M 9/1992, 35 - 4 7 [MoSh94] Moody, D. L. / Shanks, S.: What Makes a Good Data Model? Evaluating the Quality of Entity Relationship Models. In: Loucopoulos, P. (ed): Entity-Relationship Approach - ER '94. Business Modelling and Re-Engineering. 13th International Conference on the Entity-Relationship Approach. Berlin et al. 1994, 94 - 111 [Myr33] Myrdal, G.: Das Zweck-Mittel-Denken in der Nationalökonomie. In: Zeitschrift für Nationalökonomie 1933, 305 - 329 [OpRe92] Oppermann, R. / Reiterer, H.: Evaluation von Benutzerschnittstellen. In: WRTSCHi^FBINFORMATIK 3/1992, 283 - 293 [PaTi97] Pawson, R. /Tilley, N.: Realistic Evaluation. London 1997 [Rae95] Rae, A. K. et al.: Software Evaluation for Certification: Principles, Practice and Legal Liability. London 1995 [ReWi97] Reitwieser, N. / Will, Α.: Best practice oder common practice: Eine Frage der Wirtschaftlichkeit. In: WIRTSCHAFISINFCRMÄnK 6/1997, 640 f. [Sch91] Schmidt, H. W.: CASE Products 1990: A Survery of CASE Products from U S Vendors. Arbeitspapiere der G M D , Nr. 518, Sankt Augustin 1991 [Scr80] Scriven, M. S.: The Logic of Evaluation. Inverness/CA 1980 [Sed98] Seddon, P. B. et al.: The IS Effectiveness Matrix: The Importance of Stakeholder and System in Measuring IS Success. In: Hirschheim, R. et al. (eds): Proceedings of the Nineteenth International Conference on Information Systems. Helsinki 1998, 165 - 176 [Tim95] Timmreck, T. C : Planning, Program Development, and Evaluation. A H a n d b o o k for Health Promotion, Aging and Health Services. Boston et al. 1995 [TvKa82] Tversky, A. / Kahnemann, D.: Judgement under Uncertainty: Heuristics and Biases. In: Kahnemann, D. et. al. (eds): Judgement under Uncertainty: Heuristics and Biases. Cambridge 1982

48

Ulrich Frank

[Wei92] Weill, P.: The Relationship between Investment in Information Technology and Firm Performance: A Study of the Valve Manufacturing Sector. In: Information Systems Research 4/1992, 307 - 333 [Web98] Weber, R. et al.: Stakeholder Experiences with Conceptual Modeling: An Empirical Investigation. In: Hirschheim, R. et al. (eds): Proceedings of the Nineteenth International Conference on Information Systems. Helsinki 1998, 370 - 375 [WeWi97] Wernick, P. / Winder, R. L.: Software Engineering as a Kuhnian Discipline. In: Winder, R. L. et al. (eds): Philosophical Aspects of Information Systems. London 1997, 1 1 7 - 129

Informationssysteme als Evaluationsobjekt Einführung und Grundlegung Anton J. van Reeken

[email protected] Fachgruppe Rechnungswesen und Finanzierung der Universität Maastricht www-fdewb.unimaas.nl/berichtgeving/staff/index.html

Inhalt 1 2 3 4 5 6

Evaluationsobjekt Evaluation im Managementzyklus Legitimierung Priorisierung Monitoring Auditing

Zusammenfassung Dieser Beitrag beschreibt die Evaluation von Informationssystemen und führt in die nachfolgenden Beiträge ein. Evaluation wird als Teil des Managementzyklus, bestehend aus Planung, Realisierung, Betrieb und Kontrolle, positioniert. Es wird zwischen Ex-ante-Evaluation und Ex-post-Evaluation unterschieden. Beide können auf Projektebene und auf Organisationsebene angewendet werden. Daraus ergeben sich die vier Evaluationsarten Legitimierung, Priorisierung, Monitoring und Auditing, deren State of the Art anhand der verfügbaren Evaluationsmethoden beschrieben wird.

Abstract This paper describes the evaluation of business information systems and should serve as an introduction to the following three papers. Evaluation is regarded as part of the management cycle of planning, implementation, exploitation and control. A distinction is made between an ex-ante and an expost evaluation. Both can be applied to projects and at the strategic business level. The state of the art of the four resulting evaluation types - justification, prioritization, monitoring and auditing - is described and illustrated by some evaluation methods.

50

Anton J. van Reeken

1 Evaluationsobjekt „Wir sehen Computers überall, aber leider nicht in den Produktivitätsstatistiken", sagte Nobelpreisträger Robert Solow schon 1987. Diese Bemerkung wird heute als Produktivitätsparadoxon bezeichnet. Führungskräfte sind oft der Meinung, daß der Nutzen der Informationsverarbeitung in keinem angemessenen Verhältnis zu den von ihr verursachten Kosten steht. Es geht daher um die Beurteilung von Investitionsvorhaben für Informationssysteme einerseits und um die Beurteilung bestehender Informationssysteme (Diagnose) andererseits. Evaluationsobjekt sind einzelne oder mehrere Investitionsvorhaben bzw. Informationssysteme oder alle Informationssysteme einer Organisation, das heißt ihre Informationsinfrastruktur. Wenn von Informationssystemen gesprochen wird, dann sind immer soziotechnische Systeme (Mensch/Aufgabe/Technik-Systeme) gemeint, bei denen „Technik" identisch ist mit Informations- und Kommunikationstechnologien (IuK-Technologien). Einsatz von IuK-Technologien ist gleichbedeutend mit Schaffung neuer oder Veränderung bestehender Informationssysteme. Eine Entscheidung über den Einsatz von IuK-Technologien erfordert eine Reihe von Nebenentscheidungen, damit der Einsatz auch zufriedenstellend ist: Pläne machen, Personen anweisen, Schulung organisieren, Personal einsetzen, Aufbau- und Ablauforganisation strukturieren, Kontrolle einrichten usw. Man könnte beliebig alles, was mit dem Einsatz von IuK-Technologien zusammenhängt, „in die Tiefe" verfolgen und bei der Evaluation einbeziehen oder aber früher eine Grenze ziehen und weniger miteinbeziehen. Auch könnte man mehrere solcher Entscheidungen „in der Breite" gemeinsam evaluieren, bis hin zur gesamten Informationsverarbeitung der Organisation. In diesem Beitrag wird nur besprochen, was in Bezug auf den Einsatz von IuK-Technologien spezifisch ist. Das bedeutet nicht, daß alle anderen Aspekte bei einer Evaluation von IuK-Technologien außer Betracht bleiben könnten.

2 Evaluation im Managementzyklus Informationssysteme unterliegen dem aus Planung, Realisierung, Betrieb und Kontrolle bestehenden Managementzyklus. Die Evaluation von Informationssystemen wird deshalb innerhalb des Managementzyklus positioniert, wie Abbildung 1 zeigt. Theoretisch ist Evaluation Teil aller Aktivitäten des Managementzyklus. In der Praxis gibt es während der Realisierung und des Betriebs von Informationssystemen kaum so etwas wie eine Evaluation, meistens aber eine Ex-ante-Evaluation und häufig auch eine Ex-postEvaluation. Von Ex-ante-Evaluation wird gesprochen, wenn Informationssysteme erst im Entwurf bestehen, also während der Planung. Von Ex-postEvaluation wird gesprochen, wenn Informationssysteme bereits im Einsatz sind, also während der Kontrolle. Daß Ex-ante-Evaluation und Ex-postEvaluation auch gemeinsam eine Rolle spielen können, illustriert das strategische Raster nach [MFMK83]. Dabei werden den heutigen Informations-

Evaluation

von Informationssystemen

51

systemen die erwarteten (zukünftigen) Informationssysteme gegenübergestellt. Eine Ex-ante-Evaluation ist Teil der Planung, die in eine Aktivität Identifizierung und eine Aktivität Legitimierung zerlegt werden kann. Die Ex-ante-Evaluation ist Teil der Aktivität Legitimierung. Eine Ex-post-Evaluation ist Teil der Kontrolle. Beide Arten der Evaluation werden im folgenden erläutert.

Abb. 1 : Evaluation im Managementzyklus (nach [Swin97])

Jede Ex-ante-Evaluation bedarf eigentlich einer früheren Ex-post-Evaluation. Weil eine Entscheidung zum Einsatz von IuK-Technologie möglichst gut zur bestehenden Organisation „passen" soll (auf Englisch wird dafür die Bezeichnung „fit" verwendet), ist eine Ex-post-Evaluation der beste Ausgangspunkt für eine derartige Entscheidung und liefert diese damit (wenn gut gemacht) auch die besten Evaluationskriterien für die Ex-ante-Evaluation. Jede Ex-post-Evaluation bedarf einer früheren Ex-ante-Evaluation. Eine Expost-Evaluation ohne frühere Ex-ante-Evaluation ist viel problematischer als eine, die sich auf eine Ex-ante-Evaluation beziehen kann. Im zweiten Fall können die Evaluationskriterien der Ex-ante-Evaluation für die Ex-post-Evaluation verwendet und müssen nicht erneut festgelegt werden. Eine Ex-anteEvaluation weckt zumindest Erwartungen und macht vielleicht sogar Versprechungen und Commitments, die dafür sorgen, daß anschließend auch Werte für die Evaluationskriterien vorhanden sind und kontrolliert werden kann, ob die erwarteten Werte der Evaluationskriterien erreicht wurden. Die Beziehungen zwischen Ex-ante Evaluation und Ex-post-Evaluation werden durch die Kreisform von Abbildung 1 visualisiert. Eine weitere, eher praktische Unterscheidung ist die zwischen der Evaluation eines Investitionsvorhabens (Projektebene) und der Evaluation auf der Ebene einer strategischen Geschäftseinheit (Strategie Business Unit, SBU). In Tabelle 1 sind die vier sich daraus ergebenden Evaluationsarten dargestellt. Ex-ante Projcktebene

1. Legitimierung

SBU-Ebene

2. Priorisierung

Ex-post 3.

Monitoring 4. Auditing

Tab. 1 : Vier Evaluationsarten (nach [Irse91 ])

52

Anton J. van Reeken

Idealerweise wird in der Praxis wie folgt vorgegangen: Erstens wird bei der Legitimierung die Wirtschaftlichkeit eines Investitionsvorhabens ermittelt. Vorhaben, deren Wirtschaftlichkeit für ausreichend gehalten wird, werden auf SBU-Ebene priorisiert. Während der Realisierung und des Betriebs werden Daten erfaßt, die eine Ex-post-Evaluation ermöglichen, das heißt ein Monitoring auf Projektebene und - mit allen Ergebnissen des Monitoring zusammen - ein Auditing auf SBU-Ebene. Veröffentlichungen über Evaluation behandeln meist die Legitimierung, d.h. Ex-ante-Evaluation auf Projektebene. Auch mit Auditing befassen sich einige Beiträge. Beiträge über Priorisierung und über Monitoring sind relativ selten. Idealerweise sollten mit einer Evaluationsmethode alle vier Evaluationsarten bearbeitet werden können. Im folgenden werden die vier Evaluationsarten im einzelnen erläutert.

3 Legitimierung Legitimierung ist die organisatorische und wirtschaftliche Rechtfertigung eines Investitionsvorhabens. Auch Investitionen, deren Gegenstand nicht IuKTechnologien sind, werden im allgemeinen legitimiert. Für eine Legitimierung bedarf es einer Beurteilung der Wirtschaftlichkeit der geplanten Investition (also einer Evaluation) und Normen, mit denen überprüft werden kann, ob die Investition legitim ist oder abgelehnt werden sollte. Eine Legitimierung ist also teilweise eine rationale, teilweise aber auch eine nichtrationale Aktivität. Bei der Normstellung und bei der Entscheidung gibt es immer auch „politische" Einflüsse. In der Praxis wird versucht, so rational wie möglich vorzugehen. Es gibt mehrere Methoden, mit denen eine Legitimierung durchgeführt werden kann. Im folgenden werden einige erläutert; weitere sind aus [Farb93], [ApPr97], [Reme95], [Schu92], [Schu93] und [WÌ1194] zu entnehmen. 3 . 1 Die

Information-Economics-Methode

[Park88] beschreiben eine Methode (Information Economics) zur Evaluation, mit der eine Verbindung („link") zwischen Investitionen in IuK-Technologien und Organisationserfolg hergestellt wird. Diese Methode verwendet Evaluationskriterien aus den Bereichen Business Domain (ROI, strategic match, competitive advantage, management information, competitive response, project organizational risk) und Technology Domain (strategic IS architecture, definitional uncertainty, technical uncertainty, IS infrastructure risk). Alle Evaluationskriterien werden auf ihre Wichtigkeit für die Organisation hin untersucht. Die verwendete Skala unterscheidet Werte zwischen -5 bis +5 (jeweils ganzzahlig), wobei Risiken negativ und Vorteile positiv skaliert werden. Jedes Investitionsvorhaben wird mit diesen Evaluationskriterien beurteilt. Wenn kein Beitrag zum Organisationserfolg erwartet wird, wird mit 0 bewertet, wenn ein maximaler Beitrag zum Organisationserfolg erwartet wird, wird mit 5 bewertet. Die Multiplikation dieser Bewer-

Evaluation

von Informationssystemen

53

tungen mit dem jeweiligen Skalenwert liefert eine Ergebnisziffer pro Investitionsvorhaben. Weil die Evaluation nur eine Ergebnisziffer pro Vorhaben liefert, ergibt sie auch eine Rangfolge der Vorhaben. Damit leistet die Methode auch die Priorisierung. Allerdings braucht man einen Cut-off-Wert zur Entscheidung zwischen legitimierten und nicht legitimierten Vorhaben. Bei der Anwendung der Methode entstehen einige Fragen; die wichtigsten sind folgende: • • • •

Warum werden finanzielle Vorteile auch auf diese Art bewertet? Warum wird die Beurteilung nach technischen und organisatorischen Evaluationskriterien zusammengefaßt und nicht für sich betrachtet? Warum werden Risiken und Vorteile saldiert? Wie können die Ergebnisse dieser Methode mit einem Monitoring verbunden werden?

Zu diesen Fragen sind verschiedene Antworten gegeben worden. So ist zum Beispiel die Risikodiagnose bei Automatisierungsvorhaben entwickelt worden (vgl. [MFMK83], [Boeh89], [RDF90], [NAT093]). Eine Integration dieser Methoden in die Legitimierung liegt daher auf der Hand, insbesondere f ü r Risiken, die durch Maßnahmen reduziert und kontrolliert werden können. Die Information-Economics-Methode birgt die Gefahr in sich, daß viele verschiedene Aspekte mitgewogen werden, die nach der Legitimierung aus dem Auge verloren werden. Deshalb wäre eine explizite Verbindung mit dem Managementzyklus herzustellen (vgl. [Farb93], [Reme95], [Swin97]). 3 . 2 Das

Portfolio-Verfahren

Obwohl eine Evaluation, ausgedrückt in einer Ergebnisziffer je Investitionsvorhaben, ein Vorteil bei der Priorisierung ist, wird auch die Meinung vertreten, daß die verschiedenen Klassen von Evaluationskriterien so lange wie möglich separat gehalten werden sollten. Diese Forderung führt zum Portfolio-Verfahren, bei dem nach [Berg97] vier Kriterienklassen unterschieden werden: das finanzielle Kriterium (F), die übrigen organisatorischen Kriterien (B), die technischen Kriterien (T), und die Risiken (R). Die Risiken (R) werden zuerst identifiziert. Dann werden Maßnahmen entwickelt, mit denen die Risiken auf einen akzeptierbaren Umfang reduziert werden können. Wenn das nicht gelingt, wird das Investitionsvorhaben als risikovoll eingestuft. Jedes Vorhaben wird auch mit den anderen Klassen von Evaluationskriterien (B, T, F) getrennt beurteilt und im BTF-Portfolio dargestellt (vgl. Abbildung 2, BTF steht für Betrieb, Technik und Finanzen). Die Größe des Kreises stellt den F-Wert (entsprechend NPV = Net Present Value) dar. Im BTF-Portfolio können die Normgrenzen angegeben werden, die hier in der Mitte der B-Achse (horizontal) und der T-Achse (vertikal) gezeichnet sind.

Anton J. van hoch

54

Reeken

Vorsicht!

Go!

χΟ

0) o o

ώ

Y© toû Ό OJ

Stop!

Warte!

' c

niedrig

T-score

3.3 Typologie von

hoch

Abb. 2: Das BTF-Portfolio mit einigen Beispielen X und Y (nach [Berg97])

Informationssystem-Investitionen

Bei Investitionen in Informationssysteme werden sechs Typen unterschieden. Sie werden kurz erläutert (für eine detaillierte Darstellung siehe [Reek97]), um zu zeigen, daß jeder Typ aus Sicht des Managements (und also der Legitimierung) spezifische Evaluationskriterien erfordert und daß eine Verbindung mit einem späteren Ergebnismonitoring hergestellt werden kann. Manche Evaluationskriterien werden auch in den beiden bereits besprochenen Methoden benutzt. Es gibt allerdings weitere Evaluationskriterien wie Qualität und Flexibilität. • Typ Automatisieren Die Kosten der Informationssysteme können damit gerechtfertigt werden, daß Arbeitskosten reduziert werden. Das könnte mit dem Net Present Value (NPV) nachgewiesen werden, wie es im Portfolio-Verfahren geschieht. Die Information-Economics-Methode benutzt dazu das Return-on-lnvestment (ROI). Die Verbesserung der Wirtschaftlichkeit ist also der Zweck des Typs Automatisieren. Projekte mit einen positiven NPV sind immer legitimiert. • Typ Informatisieren Informatisieren heißt, durch Anwendung von IuK-Technologien etwas tun, was bis dahin nicht möglich war. Das bringt keine Reduzierung von Kosten, sondern eine Erhöhung des Nutzens, indem bestimmte Funktionen verbessert werden. Beispielsweise werden Daten schneller geliefert, oder es werden weniger Fehler gemacht. Man muß aber darauf achten, daß die Ansprüche nicht so weit gehen, daß die Kosten den Nutzen übersteigen. (Dann wäre das erwähnte Produktivitätsparadox erklärt.) Während der Legitimierungsphase muß festgestellt werden, ob die Erhöhung des Nutzens die zusätzlichen Kosten rechtfertigen kann. Meistens hat ein Projekt sowohl Auswirkungen vom Typ Automatisieren als auch vom Typ Informatisieren. Für diesen und den Typ Ausrichten sind Evaluationsmethoden entwickelt worden (vgl. [Bede85], [Park88], [Berg97], [Farb93], [Reme95], [Reek94], [Reek96]).

Evaluation von Informationssystemen

55

• Typ (strategisch) Ausrichten (Strategisch) Ausrichten heißt, durch Anwendung von IuK-Technologien die Erreichung der Organisationsziele zu unterstützen oder erst zu ermöglichen. Für diesen Typ gilt zunächst dasselbe wie für den Typ Informatisieren. Im Bezug auf die Kosten kommt aber noch hinzu, daß als Kosten die totalen Kosten der Strategieausübung berücksichtigt werden sollen. Diese Kosten sind es, die den erwarteten strategischen Vorteilen gegenübergestellt werden müssen. Wenn die Strategie zum Beispiel verlangt, daß innerhalb von 24 Stunden geliefert wird (um einen höheren Marktanteil zu erzielen), dann muß festgestellt werden, ob die totalen Kosten dieser Strategie (also inklusive die einer Reorganisation) die erwarteten höheren Erträge rechtfertigen. •

Typ Transformieren

Transformieren heißt, durch Anwendung von IuK-Technologien eine neue Ablauforganisation zu schaffen. Bei den bisher genannten Typen ist eine Reorganisation eine Folge der Technologieanwendung. Beim Typ Transformieren ist die Veränderung der Ablauforganisation Ziel der Technologieanwendung. Im Unterschied zu den bisher genannten Typen handelt es sich außerdem nicht um die Verbesserung der Funktionen, sondern um das Beseitigen von Aktivitäten und Puffern, die nicht wertschöpfend sind und die einen flotten Durchfluß von Produkten und Dienstleistungen behindern. Diesen Erwartungen müssen die Kosten der Technologieanwendung (inklusive die der Reorganisation) gegenübergestellt werden. Die meisten Methoden können eine solche Organisationsveränderung nicht gut erfassen und evaluieren (vgl. [WeWi92], [ApPr97]). • Typ Antizipieren Antizipieren heißt, durch Anwendung von IuK-Technologien die Flexibilität der Informationsinfrastruktur zu erhöhen. Ist bei den bisher genannten Typen die Veränderung der Informationsinfrastruktur eine Folge der Technologieanwendung, wird das hier umgedreht. Beim Typ Antizipieren sieht man zuerst die Investition in die Informationsinfrastruktur und dann erst Entscheidungen über ihre Nutzung. Den Kosten dieser Investition steht ein zukünftiger Nutzen gegenüber, was die Investitionsentscheidung erschwert. (In [Hein99,24f.] wird in diesem Sinn zwischen Informationssystemplanung und Infrastrukturplanung unterschieden.) • Typ Unternehmen Unternehmen heißt, durch IuK-Technologien eine neue Produkt/Markt-Kombination (PMK) zu schaffen. Mit Investitionen dieses Typs werden unmittelbar Erträge geschaffen, was mit den bisher genannten Typen nicht erfolgt; neue PMK werden damit nicht geschaffen. Hier stehen also die Kosten einer PMK den Erträgen gegenüber, der klassische Fall der Betriebswirtschaft. Alle genannten Typen von Investitionen sind Idealtypen. Investitionsvorhaben in der Praxis haben meist Merkmale mehrerer Typen. Diese Merkmale sollten identifiziert werden, weil mit den verschiedenen Typen unterschiedliche Zwecke verfolgt und Vorteile erzielt werden können. Die

56

Anton J. van Reeken

Z w e c k e u n d Vorteile sollten ausreichend detailliert d o k u m e n t i e r t w e r d e n , u m als G r u n d l a g e f ü r das Management der Realisierung, des Betriebs und d e s M o n i t o r i n g verwendet werden zu können (vgl. Abschnitt 5).

3.4 Die Bedell'sche Methode In [Bede85] wird eine Methode beschrieben, mit der ein Audit mit nachf o l g e n d e r P l a n u n g einschließlich L e g i t i m i e r u n g und Priorisierung unterstützt wird. Die Investitionsvorhaben werden nach ihrer Wichtigkeit f ü r die O r g a nisation u n d nach ihrem Qualitätsbeitrag beurteilt.

3.5 Die WITIG-Methode 1 D i e W I T I G - M e t h o d e [Reek96] baut auf der Bedell'sehen M e t h o d e u n d ist die einzige M e t h o d e , die alle vier Evaluationsarten berücksichtigt (siehe dazu d e n Beitrag „ W I T I G - Eine Methode zur Evaluation von I n f o r m a t i o n s systemen").

4 Priorisierung D i e multikriterielle I n f o r m a t i o n - E c o n o m i c s - M e t h o d e liefert eine E r g e b n i s z i f f e r p r o Investitionsvorhaben. D a m i t kann eine eindeutige R a n g f o l g e d e r V o r h a b e n hergestellt werden. In d e r Praxis spielen aber weitere Einflüsse eine Rolle (z.B. logische Abhängigkeit zwischen mehreren V o r h a b e n ; Vorhab e n , f ü r die die erforderlichen Kapazitäten noch nicht v e r f ü g b a r sind; V o r h a b e n , f ü r die die erforderliche I n f r a s t r u k t u r nicht rechtzeitig v o r h a n d e n sein wird), die z u s a m m e n mit der E r g e b n i s z i f f e r die Priorität b e s t i m m e n . Projektrisiko hoch

niedrig Projektnutzen

niedrig

niedrige Priorität

Projekt abweisen

hoch

hohe Priorität

Vorsicht!

Tab. 2: Nutzen/RisikoPortfolio

Es gibt in einem P o r t f o l i o (also mit mindestens zwei Evaluationskriterien, siehe A b b i l d u n g 2) bestimmbare u n d nicht b e s t i m m b a r e Prioritäten (vgl. [Berg97]). Je m e h r ein Investitionsvorhaben nach rechts und nach oben positioniert u n d j e größer der Kreis ist, u m s o attraktiver ist es. W e n n bei zwei Investitionsvorhaben eins der Evaluationskriterien niedriger bewertet w i r d und die anderen höher bewertet werden, ist die Priorität vorerst nicht b e s t i m m b a r . Soll f ü r diese Fälle eine Priorisierung erfolgen, d a n n ist es e r f o r d e r l i c h , die Evaluationskriterien zu gewichten, allerdings nur die, w e l c h e die U n b e s t i m m b a r k e i t verursacht haben. Es gibt aber i m m e r Tatsac h e n , die nicht einfach gewichtet w e r d e n können (z.B. V e r f ü g b a r k e i t von

1 W I T I G ist (in niederländischer Sprache) ein Akronym von „Waarde van IT-Investeringen voor j e Geld", was bedeutet: „Wert für Ihr Geld von IT-Investitionen".

Evaluation

von Informationssystemen

57

Kapazitäten, Risiko). Auch beim Portfolio-Verfahren können attraktiv positionierte Investitionsvorhaben risikovoll sein. Zur Priorisierung kann folgendes Nutzen/Risiko-Portfolio verwendet werden, das vier Klassen von Investitionsvorhaben unterscheidet (vgl. Tabelle 2). Schließlich kommen noch Probleme hinzu, die sich nicht auf diese einfache Art lösen lassen. In vielen Fällen kann über Investitionen in die Informationsinfrastruktur erst entschieden werden, wenn bestimmte Vorhaben zur Entwicklung von Informationssystemen legitimiert sind. Umgekehrt kann die Legitimierung bestimmter Entwicklungen von Informationssystemen erst erfolgen, wenn die dafür erforderlichen infrastrukturellen Investitionen legitimiert sind. Damit haben wir einen sogenannten Deadlock. Manchmal kommt es noch schlimmer! Es gibt nicht nur Vorhaben zur Entwicklung neuer Informationssysteme, sondern auch Vorhaben zur Wartung von Informationssystemen. Zwischen diesen Vorhaben können Abhängigkeiten bestehen, die nicht algorithmisch zu lösen sind.

5 Monitoring Manchmal werden die Kosten zu niedrig und die Erträge zu hoch eingeschätzt. Nicht deshalb, weil sich das Management nach der Legitimierung nicht um die Folgen seiner Entscheidung kümmert. Wenn die Wirtschaftlichkeit dieser Entscheidungen tatsächlich erfaßt werden soll, ist es notwendig, ein Ertragsmanagement (Benefit Management) zu implementieren, wobei Monitoring als Hilfsmittel zur Ex-post-Evaluation benützt wird (vgl. [Farb93], [Reme95], [Swin97]). Wenn bereits bei der Legitimierung der erwartete Nutzen detailliert dokumentiert worden ist, dann besteht Monitoring erstens darin, daß während des Betriebs der Nutzen registriert wird, und zweitens darin, daß regelmäßig überwacht und über unerwartete Abweichungen berichtet wird. Viele Evaluationsmethoden beschränken sich auf die Ex-ante-Evaluation (siehe z.B. [Park88]) und bieten keine Möglichkeiten zum Monitoring. Bei der WITIGMethode ist ein einfaches Monitoring auf Grundlage des erreichten Beitrags zur Verbesserung der Qualität der Unterstützung durch Informationssysteme vorgesehen.

6 Auditing Wirtschaftsprüfer haben eine Reihe von Hilfsmitteln und Methoden entwickelt, mit denen eine Aussage über die Wirtschaftlichkeit (also Effektivität, Effizienz und Risiken) der Informationsverarbeitung ermöglicht wird (vgl. [Webe99,Kap. 16-24]). Damit wird nicht immer eine Brücke zur nächsten Ex-ante-Evaluation geschlagen, was allerdings auch nicht oft versucht worden ist. [Swin97] hat einen Versuch gemacht, diese Kluft zu überbrücken. Er hat das „Benefits & Burdens"-Modell entwickelt, in dem er alle Nutzenarten und Aufwendungen eines Informationssystems in einer Ubersicht unterbringt.

58

Anton J. van

Reeken

In [Park88] werden zwei Bilanzen der Informationsverarbeitung unterschieden, Nachfrage- und Angebotsseite. Die Nachfrageseite bezahlt für Dienstleistungen der Angebotsseite. Der Wert der Bezahlung soll nicht größer sein als der Wert der Dienstleistungen für die Organisation. Die Angebotsseite verrechnet Kosten für Dienstleistungen an die Nachfrageseite. Die verrechneten Kosten sollen die entstandenen Kosten decken. Diese Ex-postEvaluation ist also auf das Finanzielle beschränkt. In [Stra90] wird gefordert daß die Wirtschaftlichkeit von Informationssystemen an der Kennzahl „Managementmehrwert dividiert durch die Managementkosten" gemessen werden soll. In der Praxis wird dieses interessante Konzept bisher nicht verwendet.

Literatur [ApPr97] Apostolopoulos, T. K. / Pramataris, K. C.: Information Technology Investment Evaluation: Investments in Telecommunication Infrastructure. In: Int. Journ. of Information Management 4/1997, 287 - 296 [Bede85] Bedell, E. F.: The Computer Solution - Strategies for Success in the Information Age. Homewood/Ill. 1985 [Berg97] Berghout, E. W.: Evaluation of information system proposals: design of a decision support method. Doctoral Dissertation, Delft 1997 [Boeh89] Boehm, B. W.: Software Risk Management. IEEE Comp. Soc. Press 1989 [Farb93] Farbey, B. et al.: How to Assess Your IT Investment - a Study of Methods and Practice. Oxford 1993 [Hein99] Heinrich, L. J.: Informationsmanagement. München/Wien 1999 [Irse91] van Irsel, H.: Introductie Information Economics. Seminarunterlage, T i l b u r g l 9 9 1 [ M F M K 8 3 ] McFarlan, W . F. / McKenney, J. L.: Corporate Information Systems - The Issues Facing Senior Executives. Homewood/Ill. 1983 [ N A T 0 9 3 ] N A T O RSG.3: Workshop on Software Engineering for large systems (Sessions on Software Quality & Sessions on Risk Management). The Hague (NL), Oct. 1993 [Park88] Parker, M. M. et al.: Information Economics: Linking Business Performance to Information Technology. Cambridge 1988 [Reek94] van Reeken, A. J.: Experience Using Bedell's Information Economics Method for IT/IS Investment Selection. In: Proc. of the 2nd SISnet Conf.. Barcelonal994 [Reek96] van Reeken, A. J.: WITIG, a Method for the Evaluation of Information Systems in an Organizational Context. In: Proc. IS Stream - OR'38 Conf., Warwick 1996 [Reek97] van Reeken, A. J.: A Typology of Information and Communication Applications from a Management Perspective. In: Berghout, E. W . / Remenyi, D. S. J. (eds): Evaluation of Information Technology. Delft 1997 [RDF90] Riksdataförbundet: Sârbarhets Analys [SBA; Security By Analysis], RDF, Oslo 1990 [Reme95] Remenyi, D. et al.: Effective Measurement & Management of IT Costs & Benefits. O x f o r d 1995 [Schu92] Schumann, M.: Betriebliche Nutzeffekte und Strategiebeiträge der Großintegrierten Informationsverarbeitung. Berlin et al. 1992 [Schu93] Schumann, M.: Wirtschaftlichkeitsbeurteilung für IV-Systeme. In: WIRTS C H A F T S I N F O R M A T I K 2/1993, 1 6 7 - 178 [Stra90] Strassmann, Ρ. Α.: The Business Value of Computers. New Canaan/CT. 1990 [Swin97] Swinkels, G. J. P.: Managing the life cycle of Information and Communication Technology investments for added value. In: Berghout, E. W . / Remenyi, D. S. J. (eds): Evaluation of Information Technology. Delft 1997 [Webe99] Weber, R.: Information Systems Control and Audit. Cambridge 1999 [WeWi92] Weitzendorf, T. / Wigand, R. T.: Informationstechnologie im Einklang mit Erfolgsfaktoren - Eine Fallstudie in einem US-amerikanischen Produktionsuntemehmen. In: Information Management 3/1992, 46 - 5 0 [WÌ1194] Willcocks, L.: Information Management. The evaluation of information systems investments. London 1994

Diagnose der Informationsverarbeitung1 Lutz J. Heinrich / Irene Häntschel 2 / Gustav Pomberger [email protected] / [email protected] / [email protected]

Institut f ü r W i r t s c h a f t s i n f o r m a t i k d e r Universität L i n z www.winie.uni-linz.ac.at / www.swe.uni-linz.ac.at

Inhalt 1 2 3 4

Problem Methodik der IV-Diagnose Fallstudie Befunde

Zusammenfassung Die Autoren berichten über eine Methodik zur Diagnose der Informationsverarbeitung (IV-Diagnose), die sie im Zeitraum von sechs Jahren anhand von zehn Projekten prototypisch entwickelt, erprobt und weiterentwickelt haben. Kern der Methodik sind ein Metrik-Konzept und ein Vorgehensmodell. Die Anwendung der Methodik wird an einigen Metriken und Ergebnissen des letzten der zehn Projekte, das Ende 1997 / Anfang 1998 durchgeführt wurde, beispielhaft gezeigt. Abschließend werden Befunde der wissenschaftlichen Begleitbeobachtung der Diagnoseprojekte referiert.

Abstract The authors report on a methodology for diagnosing the state of corporate information processing, which has been developed over a period of six years on the basis of ten projects conducted using prototypes in practice. The core of this methodology is a metrics concept and an activity model. Using selected results from a recently conducted project (end of 1997 to beginning of 1998) this paper demonstrates the application of the methodology. Finally, findings from observation of the diagnosis projects are presented.

1

A k t u a l i s i e r t e F a s s u n g d e s B e i t r a g s „ I n f o r m a t i o n S y s t e m s D i a g n o s i s " in: Z u p a n c i c , J. et al. (eds): E v o l u t i o n

a n d C h a l l e n g e s in S y s t e m D e v e l o p m e n t . K l u w e r A c a d e m i c / P l e n u m P u b l i s h e r s , N e w Y o r k et al. 1999, 187 197. 2

A D M E T A U n t e r n e h m e n s b e r a t u n g und I n f o r m a t i o n s m a n a g e m e n t G m b H . Linz, w w w . a d m e t a . c o m

60

Lutz J. Heinrich /Irene

Häntschel / Gustav

Pomberger

1 Problem Seit der Veröffentlichung von „The Productivity Paradox of Information Technology" [Bryn93] sind in der Literatur häufig Aussagen zu finden, die behaupten, daß die zunehmende Durchdringung der Unternehmen mit Informations· und Kommunikationstechnologien nicht zur Steigerung der Produktivität geführt hat (Produktivitätsparadox). Daher wird eine grundlegende Veränderung der Informationsverarbeitung (IV) mit dem Ziel ihrer expliziten Ausrichtung an den strategischen Unternehmenszielen gefordert. Voraussetzung für eine grundlegende Veränderung der IV ist die Erfassung und Analyse ihres Istzustands, die hier als Diagnose bezeichnet wird. Umgangssprachlich meint Diagnose „genaue Untersuchung, Feststellung" (von griech. diagnoskein = genau untersuchen, unterscheiden). Fachsprachlich meint Diagnose „das Erkennen, Feststellen oder Bezeichnen von Abweichungen der tatsächlichen Funktionsweise eines Systems von einer geplanten Funktionsweise, einschließlich der für diese Abweichungen verantwortlichen Ursachen" (vgl. Stichwort Diagnose in [HeRo98]). „System" ist dabei Informationssystem bzw. - im Sprachgebrauch der Praxis - die IV. Ziel der IVDiagnose ist es, Aussagen darüber zu machen, welchen Beitrag die IV im Istzustand zur Erreichung der strategischen Unternehmensziele leistet, um daraus Maßnahmen zur Verbesserung des Istzustands ableiten zu können. Primäre Anforderung an eine IV-Diagnose ist die Verfügbarkeit eines wissenschaftlich begründeten und in der Praxis verwendbaren Maßzahlensystems, im allgemeinen als Metriken bezeichnet. Manche Autoren (z.B. [ScFi96,358f]) sind der Auffassung, daß das Fehlen von Metriken nicht nur die Diagnose verhindert, sondern „die weitere Entwicklung gefährden kann", wobei mit „Entwicklung" die Durchdringung der Unternehmen mit Informations- und Kommunikationstechnologien gemeint ist. Eine Methodik der IV-Diagnose muß ein Metrik-Konzept und ein Vorgehensmodell zur Verfügung zu stellen, mit denen die Durchführung von Diagnoseprojekten in der Praxis ermöglicht wird. Neuere Publikationen, die sich explizit mit diesem Problem befassen und in Form einer Methodik eine wissenschaftlich begründete und praktisch erprobte Problemlösung anbieten, sind den Autoren nicht bekannt. Bei der Entwicklung unserer Methodik haben wir uns an den Grundsätzen und Prinzipien der Evaluationsforschung orientiert (vgl. [RoFr93]).

2 Methodik der IV-Diagnose Ausgehend vom Ziel der IV-Diagnose wird ein für die IV-Diagnose geeignetes Metrik-Konzept konstruiert. Daran anschließend wird das Modell entwickelt, nach dem bei der IV-Diagnose vorgegangen wird (Vorgehensmodell).

Diagnose der Informationsverarbeitung

61

2.1 Ziel der IV-Diagnose In Übereinstimmung mit der im Controlling herrschenden Meinung verwenden wir Wirksamkeit und Wirtschaftlichkeit als strategische Ziele der IV, die in ihrem Zusammenwirken als strategische Schlagkraft der IV bezeichnet werden (vgl. [Hein99,95f.]). Wirksamkeit ist die Verfügbarkeit von Funktionen und Leistungen der IV zur Unterstützung der Management- und Geschäftsprozesse, unabhängig vom dafür erforderlichen Mitteleinsatz, seinen Kosten und dem erzielten Nutzen. Wirksamkeit meint auch, in welchem Ausmaß die IV die Abwicklung der Management- und Geschäftsprozesse unterstützt, wie groß also ihr Erfolgspotential ist. Funktionen und Leistungen, die erforderlich, aber nicht vorhanden sind, reduzieren die Wirksamkeit. Maximale Wirksamkeit ist dann gegeben, wenn die von den Management- und Geschäftsprozessen geforderten Funktionen und Leistungen den von der IV angebotenen Funktionen und Leistungen entsprechen („balanced system"). Wirtschaftlichkeit ist das Verhältnis der Kosten zu einer Bezugsgröße (z.B. der günstigsten Kostensituation) oder des Nutzens zu einer Bezugsgröße (z.B. den Kosten). Vorhandene Funktionen und Leistungen, die nicht erforderlich sind, reduzieren die Wirtschaftlichkeit. Wirtschaftlichkeit setzt das Vorhandensein eines Mindestmaßes an Wirksamkeit voraus; was nicht wirksam ist, kann nicht nach Wirtschaftlichkeit beurteilt werden. Abbildung 1 zeigt ein Beispiel der Positionierung der IV auf Basis ihrer strategischen Schlagkraft unter Verwendung der Dimensionen Wirksamkeit

Wirksamkeit

Abb. 1 : Ist-, Ideal- und Sollzustand der IV

Istzustand ist der gegenwärtige Zustand der IV; er soll durch die IVDiagnose ermittelt werden. Idealzustand ist der Zustand, der unter bestmöglichen Voraussetzungen erreicht werden kann. Sollzustand bezeichnet den Zustand, der aufgrund der Ergebnisse der IV-Diagnose als Zielvorgabe empfohlen wird. Ziel der IV-Diagnose ist es nicht, Aussagen über den Zeithorizont und über die Maßnahmen zu machen, in dem bzw. mit denen

62

Lutz J. Heinrich /Irene Häntschel/ Gustav

Pomberger

der Sollzustand erreicht werden kann. (Im allgemeinen verlangt der Auftraggeber Maßnahmenempfehlungen, die dann auf Grundlage der Diagnoseergebnisse und in Ergänzung dazu gegeben werden.) Für Zwecke der IV-Diagnose werden die strategischen Ziele der IV, Wirksamkeit und Wirtschaftlichkeit, zunächst in die Ziele Durchdringung, Sicherheit, Produktivität und Flexibilität zerlegt. Da die direkte Messung der Ausprägungen dieser Ziele nicht möglich ist, werden sie solange in Teilziele heruntergebrochen bis Meßbarkeit erreicht ist. Dies führt zum Begriff Metrik, der im Zusammenhang mit der IV-Diagnose wie folgt definiert ist (vgl. [HeRo98]): Metrik ist die Eigenschaft einer Komponente der IV, die für die Ermittlung des Istzustands relevant ist und deren Ausprägung mit einer Meßmethode ermittelt werden kann. Nicht meßbare Eigenschaften werden ausdrücklich nicht als Metrik bezeichnet. 2 . 2 Metrik-Konzept Das Metrik-Konzept umfaßt drei Elemente, die zu untersuchenden IV-Komponenten (Diagnoseobjekte), ihre Eigenschaften (Objekteigenschaften) und die Methoden, mit denen untersucht bzw. gemessen wird (Meßmethoden): • Diagnoseobjekte sind alle materiellen und immateriellen Komponenten der IV (z.B. Hardware, Software, Personal, Prozesse, Verfahren). • Objekteigenschaften sind alle Merkmale der Diagnoseobjekte, die einen wesentlichen Einfluß auf die Erreichung der strategischen Ziele der IV haben (z.B. Antwortzeit, Akzeptanz, Übertragbarkeit, Wartbarkeit). • Meßmethoden sind alle wissenschaftlich anerkannten Verfahren, mit denen in der Wirklichkeit gemessen werden kann (z.B. schriftliche und mündliche Befragung; aktive/passive und direkte/indirekte Beobachtung, Videobeobachtung, Benchmarking). Bei den Ausprägungen der Metriken wird zwischen gewollten und tatsächlichen Ausprägungen unterschieden: • Gewollte Ausprägungen sind gesetzte Sollwerte oder Planwerte oder wenn diese nicht vorhanden oder nicht realistisch gesetzt sind - Werte, die sich aus Normen oder Standards ergeben; sie werden zusammenfassend als Standardwerte bezeichnet. • Tatsächliche Ausprägungen sind gemessene Istwerte, wobei „gemessen" je nach Eigenschaft - in einem sozialwissenschaftlichen Sinn (z.B. f ü r Akzeptanz) oder in einem technischen Sinn (z.B. für Antwortzeit) zu verstehen ist (vgl. [Kerl86], [Fent91]). Die Metriken der IV-Diagnose können in Form von Diagnosematrizen formalisiert werden. Sie enthalten in den Zeilen Diagnoseobjekte und in den Spalten Eigenschaften. Je nach Art der Eintragungen sprechen wir von Diagnosematrix S (S = Standardwert) und Diagnosematrix I (I = Istwert); die Elemente der beiden Matrizen sind sjk bzw. ijk. Aus den Matrizen S und I ergibt sich Diagnosematrix A (A = Abweichung) als „Differenz" zwischen Standardwerten und Istwerten.

Diagnose der Informationsverarbeitung

63

Diagnosematrix S (Standardwert) Diagnosematrix I (tatsächlicher Wert)

I Diagnosematrix A (Abweichung) *« Eigen_ . ^ ~ - scnaften Eigen- j Diagnose* » schaft 1 : Objekte Diagnoseobjekt 1

sJk

: Eigen- : ! schaft k j

: Eigen: schaft η

>

ι

!

i

Γ : ajk

! Γ :

¡

¡

ί

J

1

·

¡

¡

;

j

Λ

Diagnoseobjekt j

y _ V

Diagnoseobjekt m

ι

i

i

1

j

Abb. 2: Formale Darstellung der IV-Diagnose

Ob ein Phänomen der IV Diagnoseobjekt oder ob es Eigenschaft ist, hängt von dessen potentiellem Beitrag zur Erreichung des Diagnoseziels ab: Je größer der Beitrag, umso eher ist es Objekt, vice versa. Die Regeln, die f ü r diese Entscheidung verwendet werden, ähneln jenen der Datenmodellierung (vgl. z.B. [Rumb91]). Beim Identifizieren der Eigenschaften sollten nur die berücksichtigt werden, für die gilt, daß eine Ursache-AVirkung-Beziehung zwischen der Ausprägung der Eigenschaft und einem den Unternehmenserfolg wesentlich bestimmenden Wettbewerbsfaktor besteht. Bei der Auswahl der Meßmethoden ist zu beachten, daß jede Meßmethode unterschiedliche Ausschnitte der Wirklichkeit erfaßt. So können Art und Häufigkeit von Interaktionen zwischen Menschen und Sachmitteln nur mit Videobeobachtung zuverlässig gemessen werden (vgl. [JoHe94]). Wir legen entscheidend Wert auf die Verwendung von direkten Meßmethoden (z.B. direkte Beobachtung durch die Diagnostiker) bei weitgehender Vermeidung von indirekten Meßmethoden (z.B. Befragung von Benutzern). Bei der Auswahl der Meßmethoden sind aber auch Einflußfaktoren wie Zeitbedarf, Kosten und Genauigkeit zu berücksichtigen. 2 . 3 Vorgehensmodell Typisch für unser Metrik-Konzept ist das am Diagnoseziel ausgerichtete Identifizieren der Objekte und der Eigenschaften der Objekte, die einen hohen Beitrag zur Erreichung des Diagnoseziels liefern, sowie die an den Objekten und Eigenschaften orientierte Auswahl der Meßmethoden. Je weniger Objekte und Eigenschaften zur Erreichung des Diagnoseziels erforderlich und je objektiver die Meßmethoden sind, desto zweckmäßiger ist das Diagnosemodell. Abbildung 3 zeigt das Vorgehensmodell für die IV-Diagnose, das dem erläuterten Metrik-Konzept entspricht (in Anlehnung an [Hick89]).

64

Lutz J. Heinrich ίIrene

Häntschel / Gustav

Pomberger

2 . 3 . 1 Identifizieren von Objekten, Eigenschaften und Meßmethoden Das Identifizieren der Diagnoseobjekte erfolgt durch eine Analyse der Wettbewerbsfaktoren und der Erfolgsfaktoren. Wettbewerbsfaktoren sind Produkt- und Prozeßeigenschaften (z.B. Preis, Lieferzeit, Qualität), die für die erfolgreiche Teilnahme des Unternehmens am Wettbewerb erforderlich sind. Erfolgsfaktoren sind Eigenschaften der Management- und Geschäftsprozesse (z.B. Automatisierungsgrad) und Ressourcen (z.B. Hardware, Software, Personal), die den Unternehmenserfolg nachhaltig beeinflussen. Für die IV-Diagnose sind nur solche Erfolgsfaktoren von Interesse, die wesentlich durch die IV bestimmt sind. Diese Erfolgsfaktoren beeinflussen den Unternehmenserfolg entweder unmittelbar (z.B. eine geringe Produktivität der Software-Entwicklung und deshalb hohe Entwicklungskosten) oder mittelbar über die Wettbewerbsfaktoren (z.B. mangelhafte Funktionalität einzelner Informationssysteme und dadurch lange Lieferzeiten). Als Ergebnis der Analyse sind die Erfolgsfaktoren identifiziert, die die Wettbewerbsfaktoren beeinflussen und die durch IV unterstützt werden können; sie sind potentielle Diagnoseobjekte (z.B. bestimmte Informationssysteme) und Eigenschaften (z.B. Funktionalität der Informationssysteme).

Diagnose der Informationsverarbeitung

65

Zur Verringerung der Anzahl der Diagnoseobjekte und Eigenschaften wird eine Analyse der Interdepenzen zwischen den Diagnoseobjekten mit Hilfe einer Vernetzungsmatrix empfohlen (vgl. [IBM88]). Man schreibt dazu die Diagnoseobjekte in die Zeilen und Spalten einer Matrix und skaliert die Interdependenzen (z.B. 0 = kein oder geringer Einfluß, 1 = mittlerer Einfluß, 2 = starker Einfluß). Man bildet dann die Aktivsummen als Zeilensummen und die Passivsummen als Spaltensummen und berechnet deren Mittelwert. Abbildung 4 zeigt die Vernetzungsmatrix beispielhaft für fünf Diagnoseobjekte. Anschließend wird ein Systemdiagramm konstruiert, dessen Dimensionen die Aktivsummen und Passivsummen aus der Vernetzungsmatrix sind (vgl. Abbildung 5). Die vier Felder des Systemdiagramms werden durch deren Mittelwert gebildet. Man kann nun jedes Diagnoseobjekt in eines der vier Felder eintragen. Feld I sind die aktiven Diagnoseobjekte; sie sind durch hohe Aktivität und niedrige Passivität gekennzeichnet. Feld II sind die labilen Diagnoseobjekte; sie sind durch hohe Aktivität und hohe Passivität gekennzeichnet. Für die IV-Diagnose werden nur die Diagnoseobjekte verwendet, die einem dieser beiden Felder zugeordnet sind A

A Β

\ 0

Β

C

D

E

AS

1

2

I

2

6

1

0

0

1

2

2

7

2

5

\ 2

\

C

1

D

0

2

1

E

0

2

1

PS

1

7

5

AS = Aktive Summe PS = Passive Summe

\ 0

3

\ 6

3 4,4»

A to E = Erfolgsfaktoren * = Mittelwert

Abb. 4: V e r n e t z u n g s m a t r i x der D i a g n o s e o b j e k t e

2.3.2 Festlegen der Standardwerte Die Standardwerte sjk werden von den Diagnostikern oder von diesen gemeinsam mit dem Auftraggeber festgelegt. Als Ergebnis liegt formal gesehen Diagnosematrix S vor. Zusätzlich zur numerischen Erfassung der Standardwerte (bei kardinalen Werten) oder alternativ dazu erfolgt ihre verbale Beschreibung.

2.3.3 Messen der Istwerte Die Istwerte ijk der Metriken werden mit geeigneten Meßmethoden ermittelt. Das Ergebnis ist formal gesehen Diagnosematrix I. Es werden nur Metriken verwendet, deren Istwerte auf einer ordinalen oder kardinalen Skala gemessen werden können. Kann nur auf einer nominalen Skala gemessen werden, so ist das ein Hinweis darauf, daß es sich bei dem betrachteten Phänomen eher um ein Diagnoseobjekt als um eine Objekteigenschaft handelt. Bei einer

66

Lutz J. Heinrich/Irene

Häntschel / Gustav

Pomberger

ordinalen Skala werden in Anlehnung an die Erfolgsfaktoren-Analyse die Werte 1, 3, 5 und 7 verwendet (vgl. [Rock82], [Hein99,375f.]). aktiv

II.

• c #A ®D •E ®B

IV. 0

2

4

6

III. 8

10

Abb. 5: Systemdiagramm der Diagnoseobjekte

2 . 3 . 4 Vergleichen Standardwerte mit Istwerten Liegen die Standardwerte sjk und die Istwerte iJk vor, werden durch Vergleich die ajk ermittelt. Vergleich bedeutet bei ordinal skalierten Ausprägungen, daß nur die Aussagen (1) ijk ist etwa gleich s , (2) i ist größer als s oder (3) i ist kleiner als sjk zulässig sind. Bei kardinal skalierten Ausprägungen kann die Abweichung rechnerisch ermittelt werden. 2 . 3 . 5 Interpretieren Da auf verschiedenen Skalen mit verschiedenen Einheiten gemessen wird, ist es für die Interpretation der Istwerte und der Abweichungen der Istwerte von den Standardwerten erforderlich, sie auf eine gemeinsame Skala zu transformieren. Dafür wird eine Ordinalskala mit den Rangzahlen 1, 3, 5 und 7 verwendet. Zu jedem Istwert oder zu jeder Abweichung wird eine verbale Interpretation gegeben. Die Aggregation der Beurteilungen zu den Metriken zu einem Gesamturteil je Objekteigenschaft erfolgt durch deduktives Schließen (vgl. [Kerl86]), nicht durch algorithmische Verfahren.

3 Fallstudie 3 . 1 Diagnoseobjekte/Objekteigenschaften Im folgenden werden die Diagnoseobjekte und Objekteigenschaften sowie einige Metriken gezeigt, die in einem Diagnoseprojekt in einem großen Nonprofit-Unternehmen verwendet wurden (Durchführungszeitraum Ende 1997 / Anfang 1998). Von den Diagnostikern wurden 9 Objekte mit zusammen 36 Objekteigenschaften identifiziert. 7 Objekte (A bis G) mit insgesamt 27 Objekteigenschaften wurden gemeinsam mit dem Auftraggeber für die Diagnose ausgewählt; sie werden im folgenden genannt.

Diagnose der Informationsverarbeitung

A. Benutzerarbeitsplatz

B. Datenhaltung

Α. 1 Informationsbedarfsdeckung A.2 Funktionalität A.3 Benutzerverhalten A.4 Adäquatheit Betriebsmittel

B.l B.2 B.3 B.4 B.5

C. Kommunikationssystem

D. Software

C.l Prozeßorientierung C.2 Technologieorientierung C.3 Adäquatheit Architektur

D.l D.2 D.3 D.4 D.5

Datenmehrfacherfassung Datensicherheit Datenzugriff Datenredundanz Datenhaltungstechnologie

Prozeßorientierung Integrationsgrad Wartbarkeit und Erweiterbarkeit Benutzbarkeit Entwicklungskompetenz

E. Dokumentation

F. Rechenzentrumsbetrieb

Ε. 1 Aktualität E.2 Verfügbarkeit

F.l Schutz und Sicherheit F.2 Schnittstellenangebot F.3 Benutzerservice

G. Informationsmanagement

G.3 Sicherheitsmanagement G.4 Katastrophenmanagement G.5 Auslagerungsgrad

G. 1 Strategische Planung G.2 Technologiemanagement

67

3.2 Metriken An den Beispielen (Objekt/Objekteigenschaft) Datenhaltung/Datenzugriff und Software/Entwicklungskompetenz wird gezeigt, wie Objekteigenschaften zu Metriken verfeinert werden, indem jede Objekteigenschaft durch mehrere Fragen präzisiert wird, deren Ausprägung meßbar ist. Die Präzisierung erfordert eine Erklärung der für Objekte und Objekteigenschaften verwendeten Bezeichnungen, zumindest in Form einer Nominaldefinition. B. Datenhaltung Die Verbindung der Management- und Geschäftsprozesse mit den Informationssystemen und daher insbesondere die Abbildung der Daten der Management- und Geschäftsprozesse und ihrer Beziehungen in Datenmodellen. Dies schließt Datenerfassung, Datensicherheit, Datenzugriff, Datenredundanz und die zugrundeliegende Datenhaltungstechnologie ein. B.3 Datenzugriff Das Ausmaß, in dem durch technische und organisatorische Maßnahmen dafür gesorgt ist, daß Benutzer bedarfsabhängig auf die Daten zugreifen können, die zur Aufgabenerfüllung erforderlich sind. Meßmethoden:

Beobachtung und Befragung von Benutzern, Experimente am Benutzerarbeitsplatz, Dokumentenanalyse (insbes. technische und organisatorische Guidelines zur Datenverwaltung)

Metriken: •

Adäquatheit: Können die an der Aufgabenerftillung beteiligten Personen auf die von ihnen benötigten Daten bequem und schnell zugreifen?

68

Lutz J. Heinrich / Irene Häntschel / Gustav

Pomberger

• Aktualität: Stehen die benötigten Daten rechtzeitig zur Verfügung und sind sie auf dem letzten Stand? • Weiterverarbeitbarkeit: Liegen die benötigten Daten in Papierform und/oder elektronischer Form vor (Datenträger, Datenformate, Layout) und entspricht die Form den Benutzeranforderungen? • Anpaßbarkeit: Kann der Benutzer selbst Outputs mit Hilfe computerbasierten Hilfsmittel seinen Bedürfnissen entsprechend anpassen? • Archivierungsgrad: Werden die Benutzeranforderungen nach einer bedarfsorientierten Archivierung (Versionsführung) erfüllt? • Werkzeugunterstützung: Können Informationen „ad hoc" aus Datenbeständen mit Hilfe von Werkzeugen (Abfragesprachen, Datenbrowser, Reportgeneratoren) gewonnen werden? Können selektierte Daten ohne Medienbruch von anderen Werkzeugen weiterverarbeitet werden (Text/Datenintegration mit Textverarbeitungs- und Tabellenkalkulationswerkzeugen)?

D. Software Alle verwendeten Softwareprodukte bzw. computerbasierten Hilfsmittel, die von den für die Informationsverarbeitung im Unternehmen zuständigen Organisationseinheiten oder anderen Institutionen oder Personen entwickelt, bereitgestellt oder zumindest verwaltet werden. D.5 Entwicklungskompetenz Das Ausmaß, in dem bei Eigenentwicklung von Programmen die softwaretechnischen Erkenntnisse und Werkzeuge verwendet werden, die einen produktiven und qualitativ den Anforderungen der Management- und Geschäftsprozesse entsprechenden Entwicklungsprozeß ermöglichen. Meßmethoden:

Beobachtung des Werkzeugeinsatzes, Befragung der Entwickler, Inspektion von Quelltexten, Analyse von Richtliniendokumenten

Metriken: •

•

•

•

•

Methodik: Welche Entwicklungsmethoden sind den Entwicklern bekannt? Welche Entwicklungsmethoden werden eingesetzt? Ist der Methodeneinsatz institutionalisiert? Findet Selbst- oder Fremdkontrolle statt? Technik: Wird top-down oder bottom-up entwickelt? Welche Modularisierungstechniken werden verwendet? Mit welchen Mitteln werden Programme strukturiert? Dokumentationsgrad: Sind die Entwicklungsschritte nachvollziehbar? In welchem Ausmaß werden Kommentierung und externe Dokumentation betrieben? Durch welche Maßnahmen wird die Konsistenz von Quelltext und Dokumentation gesichert? Werkzeugeinsatz: Welche Entwicklungswerkzeuge werden eingesetzt? Welche Entwicklungsphasen werden von den Werkzeugen abgedeckt? Werden die Werkzeuge konsequent eingesetzt? Welche weiteren Werkzeuge sind den Entwicklungsrechnern verfügbar? Entsprechen die Werkzeuge den Anforderungen der Softwaretechnik? Aus- und Weiterbildung: Welche softwaretechnische Ausbildung haben die Entwickler? Sind die Entwickler mit den betrieblichen Aufgaben und den Benutzeranforderungen vertraut? Ist das Wissen und Können der Entwickler allgemein oder für die Entwicklungsumgebung spezifisch?

Diagnose der Informationsverarbeitung

69

Welche Weiterbildungswege stehen den Entwicklern offen und wie werden sie genutzt?

3 . 3 Ergebnisse Im folgenden werden die Ergebnisse der Diagnose zu den Beispielen Datenhaltung/Datenzugriff und Software/Entwicklungskompetenz, die jeweils mit einer Beurteilung auf der genannten ordinalen Skala sowie einer verbalen Erläuterung dazu abgeschlossen werden, wiedergegeben. 3 . 3 . 1 Ergebnisse zu Datenhaltung/Datenzugriff • Adäquatheit: Die Zugriffsmöglichkeiten auf die zur Aufgabenerfüllung benötigten Daten entsprechen bei den meisten Aufgaben nicht dem Stand der Technik. Die textbasierte, zeichenorientierte Benutzungsschnittstelle auf den Hostsystemen beeinträchtigt die Arbeitsweise, weil wegen der Unmöglichkeit, verschiedene Datenbestände gleichzeitig auf dem Bildschirm anzuzeigen bzw. zu bearbeiten, Bildschirminhalte auf Papier notiert werden müssen. Dies hat eine Verminderung der Produktivität sowie eine Erhöhung der Fehleranfälligkeit zur Folge und führt auch zu Frustration der Mitarbeiter. Die hostbasierten Informationssysteme sind stark zustandsbehaftet. Meist sind viele Einzelschritte zur Navigation in einem hierarchisch aufgebauten Zustandsraum erforderlich. Abgesehen von den Routinetätigkeiten zeigten die Experimente, daß das Auffinden bestimmter Informationen abseits der Routinepfade wegen fehlender Navigationshilfe mühsam und schwerfällig ist. Verstärkt wird dies dadurch, daß nur wenige Benutzer die Benutzerdokumentation als Hilfe verwenden oder verwenden können. Die Such-, Sortier- und Ordnungskriterien sind teilweise inadäquat; dies ist auf die Mängel in der Datenorganisation (fehlende Datenmodelle) zurückzuführen. Für Dateneingaben in den Eingabefeldern ist keine Cursorpositionierung möglich, so daß bei Eingabefehlern stets das ganze Feld nochmals bearbeitet werden muß. Die Stammdatensätze erfüllen nicht alle Benutzeranforderungen (z.B. können mehrere Telefonnummernfelder für Dienstapparat, Handy, Privatanschluß nicht erfaßt werden). Benutzergesteuerte Sortierfunktionen und ausgereifte Mechanismen für Ad-hocAbfragen fehlen. Dies ist auch eine Folge der Mängel in der Datenorganisation. Die mangelnde bis nicht vorhandene interne und exteme Vernetzung der Arbeitsplätze wirkt sich ebenfalls negativ auf die Prozeßabwicklung und den Datenzugriff aus. Der interne Datenaustausch erfolgt nicht selten durch Diskettenaustausch. Daten, die via Internet von Externen übermittelt wurden, werden manuell nochmals erfaßt. Die mangelnde Integration von Host- und PC-Systemen wirkt sich ebenfalls negativ auf den Datenzugriff aus. Der Datenzugriff wird auch dadurch beeinträchtigt, daß bei gemeinsamer Benutzung eines lokalen Druckers eine Blockierung des Arbeitsflusses entsteht, weil Spooling nicht unterstützt wird. Die Benutzer beurteilen die Adäquatheit des Datenzugriffs unterschiedlich. Für die meisten von ihnen ist sie zufriedenstellend. Auch die Unterstützung durch die für die Informationsverarbeitung Verantwortlichen wird unterschiedlich beurteilt, die meisten Benutzer bezeichnen sie als ausgezeichnet. • Aktualität: Die zur Bewältigung der Arbeitsaufgaben benötigten Daten stehen, von wenigen Ausnahmen abgesehen, rechtzeitig zur Verfügung und sind auf dem letzten Stand.

70

Lutz J. Heinrich / Irene Häntschel / Gustav Pomberger Durch Redundanzen, die infolge der inadäquaten Datenorganisation und von Mehrfacherfassungen entstehen, kommt es zu Inkonsistenzen. Kundenstammdaten sind nicht auf dem letzten Stand bzw. inkonsistent zu den bereichsspezifischen Datenbeständen. In den Stammsätzen der Mitgliederdaten wird zwar das Datum der letzen Änderung angezeigt, aber es ist nicht ersichtlich, auf welche Änderung sich dieses Datum bezieht. Das Änderungsprotokoll ist lückenlos und gut aufgebaut. Die Geschichte eines Kundenstammsatzes ist nur für spezielle Benutzergruppen nachvollziehbar (was, wer, wann, wie geändert hat). • Weiterverarbeitbarkeit: Die Weiterverarbeitbarkeit von Daten wird von den meisten Benutzern als zufriedenstellend empfunden, durchgeführte Experimente zeigen aber ein anderes Bild. Die Text/Daten-Integration zwischen Host- und PC-Systemen ist unterentwickelt; darunter leidet die Weiterverarbeitbarkeit von Daten. Cut-Copy-Paste-Möglichkeiten existieren auf den Hostsystemen nicht; die Übernahme von Daten von einem Bestand/Dokument in ein anderes ist dadurch erschwert. • Anpaßbarkeit: Eine benutzergesteuerte Anpassung von Ausdrucken, Reports, Listen usw. gibt es im Bereich der Hostsysteme nicht. Es existieren keine Werkzeuge zur Reportgestaltung. Das Fehlen solcher Werkzeuge wird von den Benutzern aber nicht als Schwachstelle empfunden. Die Notwendigkeit der benutzergesteuerten Anpassung von Ausdrucken ist offensichtlich nicht gegeben. • Archivierungsgrad: Die Anforderungen der Benutzer im Hinblick auf eine bedarfsorientierte Archivierung (Generationsführung) werden weitgehend erfüllt. Experimente zeigten, daß problemlos Datenbestände über mehrere Jahre hinweg zurückverfolgt werden können. Bei der Aktenverwaltung (jährlich ca. 4500 Akten mit einer Aufbewahrungspflicht von 7 Jahren) werden alle Akten in Papierform archiviert. Mikroverfilmung oder Scannen der Akten und elektronische Archivierung erfolgen nicht. • Werkzeugunterstützung: Werkzeuge wie Abfragesprachen, Reportgeneratoren oder Datenbrowser sind nicht vorhanden. Die Funktionalität der Informationssysteme reicht im wesentlichen aus, um die Kernanforderungen der Benutzer zu erfüllen. Ein Teil der ausschließlich mit einem Hostsystemarbeitsplatz ausgestatteten Benutzer beklagte allerdings das Fehlen von entsprechenden PC-Werkzeugen (wie Textverarbeitungs- und Tabellenkalkulationsprogrammen, Graphikprogrammen). Es gibt Benutzer, die wegen der fehlenden Werkzeuge einen Teil ihrer Dokumente auf ihrem privaten PC zu Hause erstellen. Die mangelnde Unterstützung der PC-Host-Kommunikation und der Möglichkeiten zur wechselseitigen Datenübernahme wirkt sich an den meisten Arbeitsplätzen produktivitätsmindernd aus. Die fehlende Möglichkeit, ein Fax über Computer zu senden bzw. zu empfangen und weiterzuverarbeiten, wirkt ebenfalls produktivitätsmindernd.

Beurteilung:

noch

akzeptabel

(3)

Das Ausmaß, in dem durch technische und organisatorische Maßnahmen dafür gesorgt ist, daß Benutzer bedarfsabhängig und bequem auf die Daten zugreifen können, die zur Aufgabenerfüllung erforderlich sind, ist noch akzeptabel, im Vergleich zu den Möglichkeiten, die sich aus dem Stand der Technik ergeben, aber mangelhaft. Die

Diagnose der Informationsverarbeitung Folgen davon sind nicht genutzte Potentiale zur Steigerung Störungen in der Prozeßabwicklung.

der Produktivität

71 und

3.3.2 Ergebnisse zu Software/Entwicklungskompetenz • Methodik: Die einzige von den Entwicklern eingesetzte Entwicklungsmethode ist die schrittweise Verfeinerung zur Top-down-Zerlegung großer Aufgaben in MUMPS-Programme. Der Methodeneinsatz obliegt jedem einzelnen Entwickler; er ist nicht institutionalisiert; Kontrollen der Methodenverwendung finden nicht statt. • Technik: Die Software-Entwicklung erfolgt top-down nach der schrittweisen Verfeinerung. Große Aufgaben werden so zerlegt, daß sie mit Hilfe von Einzelprogrammen (sog. Routinen mit einer Maximalgröße von 255 Zeilen) gelöst werden können. Darüber hinaus ist keine Strukturierung erkennbar. Die „Routinen" sind nicht strukturiert. • Dokumentationsgrad: Es gibt kaum externe Dokumentation der Programme (Projekt-, System- oder Benutzerdokumentation). Die Quellprogramme sind nur spärlich kommentiert; die Kommentierung beschränkt sich auf gelegentliche Überschriften einzelner Programmabschnitte. Durchschnittlich enthalten die untersuchten Quellprogramme nur etwa eine Kommentarzeile pro Programmseite. Oft ist über zehn und mehr Seiten kein Kommentar zu finden. Die einzelnen Entwicklungsschritte und die beim Entwurf getroffenen Entscheidungen sind nicht nachvollziehbar. • Werkzeugeinsatz: Außer Editor und Debugger werden keine Werkzeuge eingesetzt. Den Entwicklern ist nicht bekannt, ob weitere Werkzeuge für die Entwicklung von MUMPS-Programmen existieren. Die vorhandenen Werkzeuge unterstützen nur die Codierung und die Fehlerlokalisierung; sie entsprechen nicht dem Stand der Technik. • Aus- und Weiterbildung: Die Entwickler verfügen über eine spezifische Programmierausbildung; darüber hinausgehendes Wissen haben sie im Selbststudium erworben. Ihr Wissen ist für die Implementierungssprache und -plattform spezifisch und nicht ohne weiteres auf andere Entwicklungsumgebungen übertragbar. Durch ihre hohe Spezialisierung und wegen ihrer langen Betriebszugehörigkeit sind die Entwickler sehr gut mit den betrieblichen Aufgaben und den Benuitzeranforderungen vertraut. Darüber hinaus wird den Entwicklern ein hohes Maß an Einsatzbereitschaft bescheinigt. Es existiert ein Weiterbildungsplan, der für neben Messe- und Konferenzbesuchen softwaretechnische Kurse und Weiterbildung im PC-Bereich vorsieht. Beurteilung:

noch

akzeptabel

(3)

Das Ausmaß, in dem bei Eigenentwicklung von Programmen die softwaretechnischen Erkenntnisse und Werkzeuge verwendet werden, die einen produktiven und qualitativ den Anforderungen der Management- und Geschäftsprozesse entsprechenden Entwicklungsprozeß ermöglichen, ist gerade noch akzeptabel. Die Implementierungssprache steht einer Umsetzung softwaretechnischer Erkenntnisse im Weg. Werkzeuge zur Steigerung von Produktivität und Qualität der Software fehlen. Daß trotz dieser Mängel bisher Software mit Erfolg entwickelt wurde und gewartet wird, ist der Kontinuität und dem Engagement der Entwickler und ihrem Spezialwissen zuzuschreiben.

72

Lutz J. Heinrich / Irene Häntschel/

Gustav

Pomberger

3 . 3 . 3 Gesamtergebnis Abbildung 6 zeigt die Häufigkeit der Beurteilungen nach den Urteilskategorien 1, 3, 5 und 7 für das in der Fallstudie verwendete Unternehmen sowie für zwei weitere Unternehmen, in denen eine IV-Diagnose durchgeführt wurde. Der Vergleich der Beurteilungen erlaubt für das in der Fallstudie verwendete Unternehmen die Aussage, daß der Zustand der IV zwar nicht befriedigen kann und deutlich verbesserungsfähig ist, im Vergleich mit den beiden anderen Unternehmen aber relativ gut entwickelt ist.

• Verteilung der Beurteilungen untersuchtes Unternehmen β Verteilung der Beurteilungen Vergleichsunternehmen A β Verteilung der Beurteilungen Vergleichsunternehmen Β

1

3

g

7

Abb. 6: Häufigkeit der Beurteilungen

Aufgrund dieser Beurteilungen wird der Istzustand der IV mit ihrer strategischen Schlagkraft wie in Abbildung 7 dargestellt positioniert. Der Vergleich mit Positionierungen von Branchen (I = Industrie; H/G = Handel und Gewerbe; B/V = Banken und Versicherungen, vgl. [Hein99,399]) zeigt gewisse Vorteile bezüglich Wirtschaftlichkeit, aber eine Lücke bezüglich Wirksamkeit. Man kann also sagen: Die strategische Schlagkraft der IV des diagnostizierten Unternehmens ist durch überdurchschnittliche Wirtschaftlichkeit bei unterentwickelter Wirksamkeit gekennzeichnet.

Positionierung geplant

Positionierung Istzustand

2002/3

1997/98

Δ Γ

gering

Q W H/G

Wiiksamket

groß Abb. 7: Strategische Schlagkraft der IV

Diagnose der Informationsverarbeitung

73

In Abbildung 7 wird auch die Position angegeben, die in fünf Jahren unter der Voraussetzung erreicht werden kann, daß die aufgrund der IV-Diagnose gegebenen Empfehlungen (hier nicht wiedergegeben) im wesentlichen realisiert werden. Die Entwicklungsrichtung zeigt keine Dominanz von Wirtschaftlichkeit oder Wirksamkeit. Das bedeutet, daß die Maßnahmen zur Veränderung der IV in ihrer Gesamtheit die Verfolgung der beiden strategischen Ziele der IV gleichermaßen berücksichtigen sollen.

4 Befunde Der verwendete forschungsmethodische Ansatz für eine IV-Diagnose hat sich erneut bewährt. Gegenüber dem unmittelbaren Vorgängerprojekt konnte die Methodik weiter verbessert werden. Die Verbesserung besteht in einer Erhöhung der Genauigkeit der Diagnose-Ergebnisse bei gleichzeitiger Verringerung des Aufwands für die Diagnose. Da Metriken zur Beurteilung der Genauigkeit der IV-Diagnose nicht zur Verfügung stehen, orientieren wir uns bei ihrer Einschätzung an der Zufriedenheit des Auftraggebers (Top-Management und IV-Management) und der Diagnostiker mit der Diagnose. Erstere verwenden unserer Erfahrung nach primär die Art der aufgrund der Diagnoseergebnisse gegebenen Empfehlungen zur Veränderung der IV, aus denen konkrete Maßnahmen abgeleitet werden, zur Beurteilung (kurz gesagt: je präziser die Empfehlungen, desto höher die Zufriedenheit). Die Diagnostiker verwenden primär die Anzahl der erforderlichen Objekteigenschaften zur Erreichung des Diagnoseziels (kurz gesagt: je geringer die Anzahl der Objekteigenschaften, desto höher die Zufriedenheit). Die Messung des Aufwands für die IV-Diagnose ist unproblematisch; e r besteht im wesentlichen aus Personalaufwand beim Auftragnehmer und beim Auftraggeber. Der Aufwand für die Erarbeitung des Diagnosemodells betrug beim Auftragnehmer rd. 8, beim Auftraggeber rd. 4 Personentage. Wir konstatieren hier gegenüber dem Vorgängerprojekt eine Verringerung um rd. 20%. Der Aufwand für die Durchführung der IV-Diagnose betrug beim Auftragnehmer rd. 30, beim Auftraggeber rd. 15 Personentage. Daraus ergibt sich - bei 27 Objekteigenschaften - ein Aufwand von rd. 1,7 Personentagen je Objekteigenschaft (im Vorgängerprojekt 3,5), was einer Halbierung entspricht. Mehrere, nicht zu vernachlässigende Einflüsse aus den Randbedingungen des Projekts sind bei der Interpretation dieses Befunds zu berücksichtigen, insbesondere ein extrem enges Budget, das zu hoher Zeitökonomie zwang, und die Tatsache, daß nahezu alle Untersuchungen mit minimaler Wegezeit erfolgen konnten. Aus dem genannten Aufwand können die Personalkosten unter Verwendung der üblichen Tagessätze für Externe und für Mitarbeiter ermittelt werden. Mit einem Zuschlag von etwa 20% können alle Nebenkosten (insbesondere Unterstützungspersonal und Sachkosten) erfaßt werden. Für eine Vorkalkulation zur Abschätzung der Zweckmäßigkeit einer IV-Diagnose wird ein

74

Lutz J. Heinrich /Irene Häntschel/ Gustav Pomberger

Auftragswert von € 1500 je Objekteigenschaft empfohlen; Reisekosten sind darin nicht berücksichtigt. Trotz der beobachtbaren Weiterentwicklung der Methodik der IV-Diagnose besteht weiterhin eine Diskrepanz zwischen dem, was gemessen werden soll, und dem, was in der Wirklichkeit gemessen werden kann. Dies ist vor allem auf die unzureichende Leistungsfähigkeit der verfügbaren Meßmethoden zurückzuführen und wirkt sich negativ sowohl auf die Genauigkeit als auch auf den Aufwand aus. Die Weiterentwicklung der Methodik setzt daher primär bei der Verbesserung der Meßmethoden an. Wir erwarten davon eine Erhöhung der Genauigkeit der Diagnoseergebnisse bei gleichzeitiger Verringerung der Diagnosekosten. Literatur [Bryn93] Brynjolfsson, E.: The Productivity Paradox of Information Technology. In: Communications of the ACM 12/1993, 67 - 77 [Fent91] Fenton, Ν. E.: Software Metrics. A Rigorous Approach. London 1991 [Hein99] Heinrich, L. J.: Informationsmanagement. MiinchenAVien 1999 [HeRo98] Heinrich, L. J. / Roithmayr, F.: Wirtschaftsinformatik-Lexikon. München/Wien 1998 [Hick89] Hickman, F. R. et al.: Analysis for Knowledge-Based Systems. A Practical Guide to KADS Methodology. New York 1989 [JoHe94] Jordan, B. / Henderson, Α.: Interaction Analysis. Foundations and Practice. IRL Report 94-0027, Palo Alto 1994 [Kerl86] Kerlinger, F. Ν.: Foundations of Behavioral Research. Fort Worth et al. 1986 [Rock82] Rockart, J. F.: The Changing Role of Information Systems Executive. Sloan Management Review, Fall 1982, 3 - 13 [RoFr93] Rossi, P. H. / Freeman Η. E.: Evaluation. A systematic approach. Newbury Park et al. 1993 [Rumb91] Rumbaugh, J. et al.: Object-Oriented Modeling and Design. Englewood Cliffs/NJ 1991 [ScFi96] Schwärtzel, H. G. / Fischer, R.: Auf der Suche nach Metriken für das Information Engineering. In: Heilmann, H. et al. (Hrsg.): Information Engineering. MiinchenAVien 1996, 353 - 368

IT-Fitness für das 21. Jahrhundert Konzeption eines Evaluationsinstruments Alexander Teubner / Jahn Rentmeister / Stefan Klein [email protected] / [email protected] / [email protected] Institut für W i r t s c h a f t s i n f o r m a t i k u n d I n t e r o r g a n i s a t i o n s s y s t e m e d e r Universität M ü n s t e r www.wi.uni-muenster.de/wi

Inhalt 1 2 3 4 5 6

Einführung Ziele des IT21-Instrumentariums Das IT21-Modell zur Messung des Erfolgsbeitrags von IT Das IT21-Instrumentarium: Messung, Auswertung, Ergebnisanalyse Validität des Erhebungsinstrumentariums Fazit und Ausblick

Zusammenfassung Der Beitrag analysiert die Befunde des Produktivitätsparadoxons und stellt Hypothesen zum Zusammenhang zwischen dem Einsatz der Informationstechnologie (IT) und dem Unternehmenserfolg auf. Ergebnis ist ein - gegenüber den Annahmen des Produktivitätsparadoxons - erweiterter Bezugsrahmen zur Messung des Erfolgsbeitrags der IT. Der Bezugsrahmen berücksichtigt nicht nur die im Unternehmen eingesetzte IT-Infrastruktur, sondern auch die auf die Infrastruktur bezogenen Führungs- und Verwaltungsprozesse (Informationsmanagement). Die Überlegungen zum Bezugsrahmen werden dann in ein konkretes Evaluationsinstrument umgesetzt. Die verwendeten Datenerhebungstechniken, die Skalenkonstruktion, die Datenauswertung und die Analysemöglichkeiten des Instruments werden erläutert und an Beispielen veranschaulicht. Der Beitrag schließt mit einer Reflexion über Gültigkeit und Aussagekraft des Instruments unter Bezugnahme auf die Erfahrungen, die in mehr als 400 durchgeführten Evaluationen gemacht wurden.

Abstract Despite massive investments in information technology in the developed economies, there is no clear evidence for the impact of IT on productivity and business performance. This phenomenon is known as the IT productivity paradox. On a business level the evaluation of the IT contribution to business success is a major problem, too: IT evaluation is still a thorny problem. In this paper, the productivity paradox is revisited and hypotheses about the relationship between IT application and business success are set up. The result is a framework that is extended compared to the assumptions underlying the productivity paradox. The framework not only takes into consideration the

76

Alexander Teubner / Jahn Rentmeister/Stefan

Klein

impact of IT deployed in the enterprise, i. e. the technical infrastructure and the information systems, but also comprises the processes and means of planning and administrating IT applications, i. e. the information management. A concrete evaluation instrument is then derived from the framework. Item and scale construction and methods of data analysis and interpretation are described and illustrated with examples. The paper closes with a reflection on the validity of the instrument based on the experience gained in over 400 evaluation cases up to now.

1 Einführung Trotz hoher IT-Investitionen ist der Beitrag der IT für Produktivität und Unternehmenserfolg von Unternehmen ungeklärt. Das Produktivitätsparadoxon der IT besagt, daß sich - in einer makroökonomischen Betrachtung bezogen auf die Industrienationen - kein signifikanter Zusammenhang zwischen dem Umfang der IT-Investitionen und dem Unternehmenserfolg nachweisen läßt (vgl. [Bryn93]). Auch auf Unternehmensebene stellen sich bei der Bewertung der IT erhebliche Meß- und Zuordnungsprobleme (vgl. [SmHi98,161f.], [Ball95]). Vor diesem Hintergund ergibt sich für viele Unternehmen das Problem, den Einsatz von IT in seinen ökonomischen Wirkungen zu beurteilen. Die Einschätzung der Wirtschaftlichkeit der IT und ihres Beitrags zum Unternehmenserfolg ist Voraussetzung für gezielte Maßnahmen für den IT-Einsatz. Die Bewertungsproblematik ist in der jüngsten Vergangenheit zunehmend in den Fokus des Top-Managements gerückt, da IT-Investitionen in den Industrieländern bei 1 bis 3% des Umsatzes liegen, vergleichbar mit den Investitionen für Forschung und Entwicklung. Der Trend läßt auf weiter steigende IT-Investitionen in den nächsten Jahren schließen (vgl. [Ball98,241], [WiLe97,70f.]). IT-Evaluation ist Voraussetzung für die Überprüfung der Zielerreichung im Rahmen des IT-Controlling sowie für das Setzen anspruchsvoller und realistischer Leistungsziele der IT und damit Grundlage für Verbesserungen. IT-Evaluationen werden in der Praxis vor allem durchgeführt, um Investitionsbudgets zu begründen, um den Erfolg von IT-Investitionen zu überprüfen und um zwischen konkurrierenden Projekten zu entscheiden. Trotz dieser Bedeutung erfolgen IT-Evaluationen oft nicht systematisch. Dies gilt insbesondere für kleine und mittelgroße Unternehmen (vgl. [Ball98,247]). Als Gründe werden vor allem ein Mangel an Wissen über Prozeß und Werkzeuge der Evaluation sowie eine begrenzte Bereitschaft, Ressourcen für die Evaluation bereitzustellen, festgestellt. Die Problematik der IT-Evaluation in mittelgroßen Unternehmen wurde mit dem Projekt „Informationstechnologie im 21. Jahrhundert - IT21" aufgegriffen, das vom Institut für Wirtschaftsinformatik der Universität Münster, Lehrstuhl für Wirtschaftsinformatik und Interorganisationssysteme, in Zusammenarbeit mit der IBM Unternehmensberatung und dem IBM Geschäftsbereich Mittelstand durchgeführt wurde.

Evaluation der IT-Fitness

77

2 Ziele des IT21-Instrumentariums Ziel des Projekts IT21 war die Entwicklung eines auf die Bedürfnisse mittelgroßer Unternehmen zugeschnittenen Instruments zur Einschätzung der Leistungsfähigkeit und des Erfolgsbeitrags der IT. Dabei sollte sich die Betrachtung der IT nicht - im Sinne einer Momentaufnahme - auf die zum Erhebungszeitpunkt vorhandene Infrastruktur an Netzwerkkomponenten und Informationssystemen (IS) beschränken, sondern auch die auf die Nutzung und Weiterentwicklung der Infrastruktur bezogenen Weichenstellungen und Managementprozesse (Informationsmanagement, vgl. [Hein99]) einbeziehen. So wie die vom Informationsmanagement getroffenen Entscheidungen in der Vergangenheit die Ausgestaltung und Leistungsfähigkeit der Infrastruktur bestimmt haben, werden nachfolgende Entscheidungen deren zukünftigen Zustand bestimmen. Gemäß der Intention des Projekts, eine Einschätzung der IT-Fitness für das 21 Jahrhundert zu ermöglichen, wird der Validierung des Informationsmanagements großes Gewicht beigemessen. Das Instrument ist auf Unternehmen zwischen 50 und maximal 2000 Mitarbeiter zugeschnitten; die Besonderheiten von Kleinunternehmen und internationalen Großkonzernen werden nicht berücksichtigt. Die Zielgruppe ist durch eine ausgeprägte Informationsinfrastruktur gekennzeichnet, das heißt durch ein breites Spektrum von Informationssystemen in unterschiedlichen Unternehmensbereichen. Sie verfügt über ein institutionalisiertes Informationsmanagement, das einen Bedarf an Evaluationsinstrumenten hat. Dies sind aus Sicht der Zielgruppe direkt einsetzbare, standardisierte Instrumente, die dem Anwender einen strukturierten Einblick in die eigene Situation geben und Anregungen für vertiefte Analysen vermitteln. Die Standardisierung des Evaluationsinstruments bedeutet, daß von den Besonderheiten einzelner Unternehmen abstrahiert werden muß, obwohl für Unternehmen in unterschiedlichen Situationen bestimmte Leistungsmerkmale der IT unterschiedliche Bedeutung haben können. Für ein Bankunternehmen bedeutet „Sicherheit der IT" etwas anderes als für einen Baustoffhandel. Daraus könnte sich die Anforderung ergeben, Sicherheit in beiden Unternehmen verschiedenartig und unterschiedlich genau zu messen. Dies ist mit einem standardisierten Instrument nur bedingt möglich. Um diesem Problem Rechnung zu tragen, wird mit IT21 zusätzlich eine auf dem Instrument basierende Struktur von Kennzahlen angeboten, über die es einem Unternehmen möglich ist, sich anonym nach Branche und bestimmten Unternehmensmerkmalen mit ausgewählten anderen Unternehmen zu vergleichen 1 . Eine weitere Forderung an das IT21-Instrumentarium war, daß Hinweise gegeben werden, die von den Unternehmen in konkrete Verbesserungsmaßnahmen umgesetzt werden können. Dieser Forderung wird durch Benchmarking Rechnung getragen. Ziel des Benchmarking ist es, auf der Basis von Richtwerten oder Vergleichswerten führender Unternehmen, sogenannten 1

Vgl. [K]an90], der ein System von Betriebsvergleichskennzahlen für Software- und Systemhäuser angibt.

78

Alexander

Teubner

/ Jahn

Rentmeister

/ Stefan

Klein

Benchmarks, eine nachhaltige Verbesserung der eigenen Leistungsfähigkeit zu erzielen. Im Benchmarking geht es nicht nur darum festzustellen, wie gut andere Unternehmen sind, sondern vor allem, wie sie in diesen Bereichen eine solche Leistung zustandebringen (vgl. [Töpf97,34]). Abbildung 1 zeigt die Forderungen, die sich aus der Zielsetzung von IT21 an das Instrumentarium für die einzelnen Phasen des IT-Controlling ergeben. Die Abbildung verdeutlicht die Forderung, ein Instrumentarium anzubieten, das den IT-Controllingprozeß durchgängig unterstützt. Prozeß des IT-Controlling

IT21 -Instrumentarium

1

1 1

* Operationalisierung der Zielgrüßen * Messung der Istgrüßen

| |

j |

* Meß- und Auswertungsvorschriften

* Soll-Ist-Vergleich

1

|

* Vergleichswerte/Kennzahlen für Performances und Practices

* Festlegen der Kontrollobjekte

Kontrolle

I

|

Abweichungsanalyse

ι

¡ j

Entwicklung von Korrekturmaßnahmen Korrekturentscheidung (Planung)

* Vorgabe möglicher Kontrollobjekte

* Stärken-Schwächen-Analyse —• * Problemanalyse

*

J

* Betriebsvergleich

A b b . 1: I T - C o n t r o l l i n g m i t d e m I T 2 1 - I n s t r u m e n t a r i u m ( v g l . [ W e l g 8 8 , 2 ] , [ H e i n 9 9 , 1 7 1 f . ] )

Kernfunktion des IT-Controlling ist die Kontrolle der IT-Objekte. Das IT21Instrumentarium schlägt dazu einen Katalog von Kontrollbereichen und -objekten vor und bietet standardisierte Meß- und Auswertungsvorschriften für die relevanten Leistungsmerkmale dieser Objekte an. Der Abgleich von gemessenen Ist-Werten und angestrebten Soll-Werten (Ziele) wird vor allem durch Verdichtung der Meßergebnise zu Praktik- und Performance-Kennzahlen erleichtert, welche die Leistungsfähigkeit in kritischen Erfolgsfaktoren der IT komprimiert und griffig charakterisieren. Über die Kontrollfunktion hinaus hat das IT-Controlling die Aufgabe, Differenzen zwischen angestrebter und gemessener Leistungsfähigkeit der IT auf ihre Ursachen hin zu analysieren. Dies geschieht im Rahmen der Abweichungsanalyse. Die Abweichungsanalyse wird durch Stärken/Schwächen-Analysen unterstützt, die Hinweise auf Schwachstellen bei den kritischen Erfolgsfaktoren und auf Ursachen dafür geben. Die Identifikation von Stärken und Schwächen erfolgt durch einen Vergleich mit der Leistungsfähigkeit anderer Unternehmen (Betriebsvergleich). Die Entwicklung von Korrekturmaßnahmen schließt den Controllingzyklus und bildet den Übergang zum nächsten Planungszyklus, in dem Maßnahmen zur Überwindung von Ziellücken definiert und gegebenenfalls neue Ziele gesetzt werden. Das Finden von Korrekturmaßnahmen ist durch die Analyse von Praktiken in Bereichen mit schwacher Performance möglich. Idealerweise sollen gute Praktiken (Best Practices) zu guten Leistungswerten (Best Performances) führen. Das bedeutet, daß da, wo die aktuellen Leistungswerte

Evaluation der IT-Fitness

79

unter den Zielwerten liegen, die Praktiken potentielle M a ß n a h m e n zur Überwindung der Ziellücken sind. Für die Analyse von Problemen und Problemursachen werden darüber hinaus automatisierte sachlogische Auswertungen durchgeführt, die Hinweise auf besonders kritische Problemfelder und Problemursachen und deren Lösungsmöglichkeiten liefern. Durch Benchmarking wird auch die Definition neuer Ziele unterstützt. Unternehmen dürfen nicht nur die Leistungsfähigkeit der eigenen IT relativ zu den gesetzten Zielen sehen, sondern müssen diese auch über einen Betriebsvergleich relativ zur Leistungsfähigkeit anderer Unternehmen einschätzen. Erst durch diesen Vergleich ist es möglich, das eigene Anspruchsniveau an die IT zu kalibrieren. Ohne den Blick über die Unternehmensgrenzen hinaus könnten Unternehmen, die mit ihrer IT subjektiv zufrieden sind, dazu verleitet werden, Ziele zu setzen, die zu leicht erreichbar sind.

3 Das IT21-Modell zur Messung des Erfolgsbeitrags von IT Kern des IT21-Instrumentariums ist das Meß- und Bewertungsinstrument. Bei der E n t w i c k l u n g dieses Instruments stellten sich die Fragen, w e l c h e Eigenschaften der IT für den Unternehmenserfolg entscheidend sind und in welcher Weise sie zum Unternehmenserfolg beitragen. Diese Fragen sind schwierig zu beantworten, weil die Hypothese, daß ein direkter Zusammenhang zwischen dem Einsatz von IT und dem Unternehmenserfolg besteht, bisher nicht bestätigt werden konnte. 3.1 Ansätze zur Erklärung des Beitrags von IT zum Unternehmenserfolg Eine Reihe von High-level-Studien auf der Ebene von Volkswirtschaften und ausgewählten Branchen, vor allem in den USA, kommt zu dem Ergebnis, daß IT-Investitionen nicht signifikant mit dem Unternehmenserfolg in Zusammenhang stehen. Dieser Befund wurde unter dem Begriff „ProduktivitätsValue

IT ^enables Business Process

V-

Business Strategy

J

ï Abb. 2: Bezugsrahmen zur IT-Produktivität [Wiga98,159]

paradoxon der IT" dahingehend interpretiert, daß - sofern der IT-Einsatz zum Unternehmenserfolg überhaupt beiträgt - der nachweisbare Erfolgsbeitrag so gering ist, daß er die IT-Investitionen nicht rechtfertigt. Befund und Interpretation werden allerdings kontrovers diskutiert. Neben methodischer Kritik an

80

Alexander

Teubner

/ Jahn

Rentmeister

/ Stefan

Klein

den verwendeten Meßverfahren wird inhaltliche Kritik an dem unterstellten einfachen und direkten Zusammenhang von IT-Investition und Unternehmenserfolg geübt (vgl. [Wiga98,151], [WiLe97,67f.]). Eine Reihe von Autoren betont, daß nicht die IT an sich die Produktivität steigert, sondern die Art und Weise, in der sie eingesetzt, betrieben und verwaltet wird 2 . [Wiga98,151,158f.] argumentieren in diesem Sinn (vgl. Abbildung 2). Sie gehen davon aus, daß die Abstimmung zwischen IT einerseits und Geschäftsstrategie und Geschäftsprozessen andererseits für Effektivität und Effizienz der IT, das heißt für die Schaffung von Mehrwert, ausschlaggebend ist. Die Aussage, daß sich der Erfolg von IT nur über die Geschäftsprozesse einstellt und die IT deshalb auf diese abgestimmt werden muß, wurde von [HeVe 93] weiter ausgeführt. Die Autoren differenzieren insbesondere die Variable IT des Bezugsrahmens aus Abbildung 2; sie wird in die IT-Strategie und die IS-Infrastruktur aufgelöst.

BUSINESS

INFORMATION TECHNOLOGY

A b b . 3: S t r a t e g i e A l i g n m e n t M o d e l [ H e V e 9 3 , 8 ]

Die IT-Strategie beschreibt die Ziele, die mit der IT verfolgt werden, und die zur ihrer Umsetzung erforderlichen Verhaltensweisen. Die IS-Infrastruktur

2 Vgl. [WiLe97,68f.], vgl. auch [HaCh93] und [Dave93]); hier wird die Annahme vertreten, daß IT erst bei einer Reorganisation der Geschäftsprozesse zu merklichen Produktivitätssteigerungen führt.

Evaluation der IT-Fitness

81

bezeichnet die im Unternehmen eingesetzten technischen Infrastrukturen, die zur Abwicklung der Geschäftsprozesse verwendeten Informationssysteme und die für den produktiven Einsatz der IT/IS erforderlichen Fertigkeiten 3 . [HeVe 93] stellen ihre Überlegungen im sogenannten „Strategie Alignment Model" dar (vgl. Abbildung 3). Im Mittelpunkt des Modells steht die Forderung nach Integration der Bereiche „Information Technology" und „Business". Die Integration erfolgt auf zwei Ebenen. Auf der strategischen Ebene wird die Abstimmung von Geschäftsund IT-Strategie gefordert (strategic integration). Auf der operativen Ebene, die den Vorgaben der strategischen Ebene folgt, muß die Abstimmung der internen Organisations- und IS-Infrastruktur gewährleistet sein (operational integration). Zentrale These des Modells ist, daß der Unternehmenserfolg von der Integration aller vier Quadranten des Modells abhängt (vgl. [HeVe93,9]). 3.2 Der IT21-Bezugsrahmen Die Arbeiten von [Wiga98] und [HeVe93] liefern die wesentlichen Bausteine zur Erklärung von IT-Produktivität. Diese wurden, wie in Abbildung 4 dargestellt, zu einem Bezugsrahmen verknüpft, der hilft, den Gegenstandsbereich der Evaluation zu erschließen. Der Bezugsrahmen hat folgende Bedeutung für die Beurteilung der IT-Leistungsfähigkeit mit dem IT21-Instrumentarium: • Der Gegenstandsbereich der Evaluation, die IT, wird in die Informationsinfrastruktur (IIS) und das darauf bezogene Informationsmanagement (IM) zerlegt. Die IIS umfaßt die technischen Infrastrukturen und Informationssysteme, das IM die Mittel und Maßnahmen, die ein Unternehmen für Planung, Entwicklung und Betrieb der IIS einsetzt4. • Es wird angenommen, daß ein gutes IM eine leistungsfähige IIS zum Ergebnis hat und die IIS das Anspruchsniveau an das IM mitbestimmt. Insbesondere impliziert diese Wirkung des IM auf die IIS, daß eine gute Abstimmung (alignment) zwischen IM und Geschäftsmanagement Voraussetzung für die Abstimmung zwischen Geschäftsprozessen und den Informationssystemen ist. • IM und IIS müssen vor dem Hintergrund des technischen Umfelds betrachtet werden. Hier ist zu beurteilen, inwieweit technische Potentiale systematisch untersucht, erkannt und effektiv in die IIS umgesetzt werden. • Der Unternehmenserfolg wird als Zielgröße betrachtet, auch wenn die genaue Wirkungsweise von Maßnahmen und Performancemaßen auf den Unternehmenserfolg unbekannt ist. Dadurch ergibt sich die Möglichkeit, den angenommenen und im Bezugsrahmen dokumentierten Zusammenhang empirisch zu überprüfen (vgl. Abschnitt 5.1.2). • Bei der Beurteilung des Geschäftserfolgs ist die Markt- und Wettbewerbssituation zu berücksichtigen. Sie beeinflußt den Erfolg als externe

1 Vgl. [HeVe93], [Hend96]. Die Strategie ist insbesondere nach außen auf Absatz- und B e s c h a f f u n g s m ä r k t e gerichtet, die Infrastrukturen beschreiben dagegen die internen Potentiale und deren Strukturierung. 4 Vgl. [ H e i n 9 9 , 1 9 f . ] ; vgl. auch [Bren94,109], der v o m Controlling des I n f o r m a t i o n s s y s t e m s und d e m Controlling der Informatik spricht.

82

Alexander

Teubner / Jahn Rentmeister / Stefan Klein

Determinante und definiert Anforderungen an Geschäftsmanagement und Geschäftsprozesse.

tí

Markt- und Wettbewerbsumfeld

"CT

Abb. 4: ΓΓ21- Bezugsrahmen

Das IT21-Instrumentarium ist als situativer Benchmark ausgelegt. Neben Performancevariablen und Praktikvariablen werden Strukturvariablen erfaßt, die sich in ihren Ausprägungen nicht als gut oder schlecht bezeichnen lassen, sondern die über den situativen Kontext der IT wertfrei Aufschluß geben. Beispielsweise könnte festgestellt werden, daß in einem Unternehmen nur wenige Anfragen über das User Help Desk zufriedenstellend beantwortet werden (schlechte Performance). Daraus könnte geschlossen werden, daß die Help Desk-Mitarbeiter überlastet oder unzureichend geschult sind (schlechte Praktik). Eine andere Interpretation ist, daß die Informationssysteme sehr komplex und Fehler deshalb schwer zu diagnostizieren sind. Je nachdem, welche Ursache vorliegt, sind unterschiedliche Maßnahmen einzuleiten (Schulung der Mitarbeiter vs. Reduktion der Systemkomplexität). Strukturvariablen wie „Anzahl der IT-Mitarbeiter", „Ausbildungsniveau der IT-Mitarbeiter" und „Komplexität der Informationssysteme" können Aufschluß über die problemadäquaten Verbesserungsmaßnahmen geben.

4 Das IT21-Instrumentarium: Messung, Auswertung, Ergebnisanalyse 4.1 Auswahl der Meßobjekte und Merkmale Der Breite und Komplexität der IT und den unterschiedlichen Schwerpunkten der Unternehmen bei der Evaluierung der IT kann ein standardisiertes Instrument nur begrenzt Rechnung tragen. Deshalb war zu entscheiden, welche

Evaluation der IT-Fitness

83

Phänomene im Bereich der IIS und des IM mit dem Instrumentarium untersucht werden sollen. Zur Klärung dieser Frage wurde eine Expertengruppe aus je drei bis vier Wissenschaftlern und Beratern eingesetzt, die in einem Brainstorming relevante Themen zusammentrug. Der Ansatz war zum Teil induktiv, zum Teil deduktiv. Zum einen wurden Probleme der Praxis zum Ausgangspunkt genommen und auf ihre Ursachen, Folgen und Lösungsmöglichkeiten hin diskutiert. Zum anderen wurden Thesen aus der Fachliteratur herangezogen und auf ihre praktische Relevanz hin untersucht. Auf diese Weise entstand ein umfangreicher Themenkatalog, der in einem Konsolidierungsprozeß systematisiert und auf ca. 70 Themen verdichtet wurde. Diese Themen wurden in ca. 140 Fragen zu bestimmten Peformance-, Praktik- und Strukturmerkmalen aufgelöst. Für die Umsetzung der Themen in Fragen wurden die Fachliteratur zum Informationsmanagement und der State of the Art der Informationstechnologie herangezogen. Die Fachliteratur war vor allem Grundlage für die Definition guter und schlechter Praktiken, aber auch für die Identifikation relevanter Strukturmerkmale. Beispielsweise orientiert sich die Erfassung der Anwendungslandschaft an einer Klassifikationen von Anwendungssystemen, wie von [Stein94,26] und [Bren94,68f.] vorgeschlagen. Die relevanten Performancemerkmale wurden, je nach Frage, entweder anhand des Stands der verfügbaren IT oder anhand von Problemen, mit denen Unternehmen typischerweise zu kämpfen haben, bestimmt. Im zweiten Fall wurden auch Erfahrungen der IBM Unternehmensberatung herangezogen. 4.2 Meßvorschriften Als Datenerhebungstechnik wurde die schriftliche Befragung gewählt. Obwohl einige Merkmale direkt erfaßbar sind und auch mit Beobachtung und Dokumentenanalyse erhoben werden könnten, wurde zwecks Minimierung des Erhebungsaufwands darauf verzichtet. Der Fragenkatalog ist nicht nur umfangreich, sondern inhaltlich auch sehr breit: Er umfaßt technische Fragen ebenso wie Fragen zur Unternehmensplanung, -organisation und -kultur. Daraus ergab sich das Problem, geeignete Interviewpartner zu finden. Bei der Auswahl mußten zwei konfliktäre Ziele berücksichtigt werden: 1. Um möglichst genau messen zu können, sollten - je nach Themenstellung Interviewpartner mit dem notwendigen Informationsstand ausgewählt werden (vgl. [MüK193,34]). 2. Aus erhebungsökonomischen Gründen ist es ideal, wenn alle Fragen von einem Probanden beantwortet werden. Als Zielkompromiß wurden Mitglieder von Geschäftsführung und DV-/ITLeitung als Interviewpartner ausgewählt. Ein Teil des Fragebogens ist an ein Mitglied der Geschäftsführung (Chief Executive Officer, CEO) gerichtet, ein Teil an den DV/IT-Leiter (Chief Information Officer, CIO). Durch Zuordnung der strategischen und betriebswirtschaftlichen Fragen auf den CEO und der administrativen und informationstechnischen Fragen auf den CIO kann ein relativ hoher Informationsstand erreicht werden.

84

Alexander Teubner / Jahn Rentmeister / Stefan Klein

4.2.1 Skalen Aufgrund des Umfangs und der Komplexität des Gegenstandsbereichs ergibt sich auch bei Teilung des Fragebogens ein erheblicher Bearbeitungsaufwand. Um ihn möglichst gering zu halten, wurden nur geschlossene Fragen verwendet. Eine weitere Voraussetzung für eine leichte Beantwortbarkeit ist, daß die Fragen schnell erfaßt werden können. Diese Voraussetzung betrifft sowohl die Granularität der Skala als auch die Überschaubarkeit der angebotenen Merkmalsausprägungen. Dies muß mit der meßtheoretischen Forderung nach ausreichender Diskriminierungsfähigkeit und Eindeutigkeit der Skala abgewogen werden. Es wurde eine Ordinalskala mit Stufen von 1 bis 5 gewählt, die zur Erfassung der Praktik- und Performancemerkmale verwendet wird 5 . Für jede Praktik bzw. Performance entspricht 1 der worst practice bzw. worst performance und 5 der best practice bzw. best performance. Die Forderung nach Überschaubarkeit der Frage vs. Zuverlässigkeit der Messung konkretisiert sich in der Frage, ob im Extremfall zu keinem oder zu jedem Skalenwert (numerisches Relativ) die konkreten Merkmalsausprägungen (empirisches Relativ) angegeben werden. Bei vollständigem Verzicht auf die explizite Angabe von Merkmalsausprägungen (etwa „Werden Informationen allen Mitarbeitern bekanntgemacht?", 1 = gar nicht, 5 = vollständig) bestehen große Interpretationsspielräume, so daß die Werte bei wiederholtem Messen stark schwanken können6. Auch wenn die Merkmalsausprägungen für die Skalenwerte 1 und 5 angegeben sind, ergeben sich Schwankungen im Mittelfeld der Skala. Vergleichsweise zuverlässige Messungen werden erzielt, wenn die Ausprägungen 1, 3 und 5 eines Merkmals ausformuliert sind. In diesem Fall ist anhand der angegebenen Ausprägungen zu 1 und 3 bzw. 3 und 5 eine Zuordnung zu den nicht explizierten Merkmalsausprägungen 2 und 4 möglich. Abbildung 5 zeigt beispielhaft zwei Fragen dieser Art. Der Interviewte kann eine der drei angegebenen Ausprägungen oder eine Zwischenausprägung wählen. Die Zuordnung zum Zwischenbereich ist richtig, wenn alle Merkmale der jeweils niedrigeren Ausprägung und eines der i.d.R. zwei zusätzlichen Merkmale der nächst höheren Ausprägung erfüllt sind.

5 E i n e 5 e r - S k a l i e r u n g liegt auch der verbreiteten L i k e r t - S k a l a z u g r u n d e . Z u r L i k e r t - S k a l a vgl. [Schne99,181f.] oder [Fried84,175f.]. 6 Die Eigenschaft eines Erhebungsinstruments, bei wiederholtem Messen gleiche Ergebnisse zu erzielen, wird auch als Retest-Reliabilität bezeichnet, vgl. [Schne99,145].

Evaluation der IT-Fitness Bitte eintragen (1-5, 0 für keine Angabe)

1

2

3

4

85

5

Wie regelmäßig stimmt sich die ITLeitung mit den Leitungen der Fachabteilungen ab?

Abstimmungen so gut wie nie

Regelmäßige Treffen fest eingeplant

Regelmäßige Treffen; fest eingeplant; Inhalte protokolliert; Zielerreichung verfolgt

Inwieweit wird bei DV-Arbeits plätzen auf Ergonomie geachtet?

Ergonomie an DVArbeitsp(ätzen spielt untergeordnete Rolle

Ergonomie ist Kriterium bei Beschaffung und Neugestaltung; Beschwerden und Verbesserungsvorschlägen wird nachgegangen

Regelmäßige Überprüfung aller DV-Arbeitsplätze; benutzerindividuelle Arbeitsplatzgestaltung (ζ. B. bzgl. Körpergröße, Rückenbeschwerden, Sehhilfen)

Abb. 5: Rating-Fragen [IBM98,3f ]

Metrische Werte (ζ. B. Mitarbeiteranzahl) werden direkt erfragt. Für die oft nur nominalen Strukturmerkmale und einige ordinale Merkmale werden andere Frageformen (z.B. Multiple-Choice-Fragen) verwendet. Abbildung 6 zeigt ein Beispiel. Welcher Anteil der Mitarbeiter kann nicht mehr arbeiten, wenn die IT vollständig ausfällt? (Dauer über einen halben Tag)

Angabe in Prozent

Welche Medien werden für die Kommunikation mit Geschäftspartnern genutzt? (Bitte ankreuzen) Fax

•

Telefon

•

Brief

•

E-Mail

•

EDI

•

Dateitransfer

•

Datenbankzugriff

Interprozeßkommunikation zwischen Anwendungen

•

•

Abb. 6: Wert- und Multiple-Choice-Fragen [IBM98,5f.]

4.2.2 Fragenanordnung Die Fragen wurden im Fragebogen nicht unter Auswertungsaspekten, sondern thematisch geordnet (vgl. Tabelle 1). Da Fragen erfahrungsgemäß in Abhängigkeit vom Kontext der vorangehenden Fragen interpretiert werden, kann eine sinnvolle thematische Anordnung zu einem leichten und exakten Verständnis der Fragen und damit zu einer schnellen und richtigen Beantwortung entscheidend beitragen (vgl. [MüK193,33], [Schne99,320]). Innerhalb der Themenfelder wurde bei der Anordnung der Fragen vor allem darauf geachtet, daß unerwünschte Ausstrahlungseffekte vermieden werden (vgl. [Schne99,320]). So werden beispielsweise Fragen nach der Schwere der Folgen eines Systemausfalls nicht vor Fragen nach den Praktiken zur Ausfallsicherheit gestellt. Ob die Fragen sowie die dazu angegebenen Merkmalsausprägungen von den Befragten dem intendierten Verständnis nach verstanden werden, wurde in Pretests überprüft. Fragen, bei denen Mehrdeutigkeiten oder Mißverständnisse auftraten, wurden - gegebenenfalls mehrmals - umformuliert, bis keine Verständnisprobleme mehr identifiziert wurden. Für ausgewählte Unternehmen wurden die Antworten mit der Einschätzung von IBM-Beratern verglichen, die die Unternehmen gut genug kennen, um einen großen Teil der Fragen aus eigener Einschätzung beantworten zu können. In anderen Fällen wurden die Probanden gebeten, die Situation in

86

Alexander Teubner / Jahn Rentmeister /Stefan Klein

ihrem Unternehmen mit eigenen Worten zu schildern, so daß die Befragungsergebnisse mit diesen Ausführungen abgeglichen werden konnten. Wenn beim Abgleich Differenzen auftraten, wurden die Fragen überarbeitet. Aufbau des CEO-Questionnaires

Aufbau des CIO-Questionnäires

>

Allgemeine Fragen zum Unternehmen >

Meßgrößen zur IT-Situation

>

Rolle und Einbindung der IT im Unternehmen

>

Strategie

>

Projektmanagement

>

Anwender- und Benutzerorientierung

>

Information und Kommunikation

>

Anwenderorientierung

>

Sicherheit und Verletzlichkeit

>

Innovative Lösungen

>

Systemverwaltung

>

IT-Durchdringung der Geschäftsprozesse

>

IT-Strategie

>

Sicherheit und Verletzlichkeit

>

Meßgrößen zur Geschäftssituation

>

Flexibilität und Innovationsfähigkeit

>

Anwendungslandschaft

>

Systemumgebung

>

Hersteller

Tab. 1 : Thematischer Aufbau des Fragebogens

Durch die Pretests nicht ausgeschlossen wurden mögliche Antworttendenzen, die daraus resultieren, daß für den überwiegenden Teil der Fragen die Ausprägungen von schlecht nach gut geordnet sind (zum Problem der Anwortverzerrung vgl. [Schne99,331]). Dieser Gefahr kann durch eine häufigere Umkehrung der Ausprägungen entgegengewirkt werden. Darauf w u r d e aus zwei Gründen verzichtet. Erstens gehen häufige Wechsel auf Kosten der schnellen Lesbarkeit und Beantwoitbarkeit der Fragen. Zweitens hat die Fragenanordnung auch didaktischen Wert, das heißt einen vermittelnden Charakter, indem sie die Sensibilisierung für Probleme (worst p e r f o r m a n c e b z w . practice) fördert und neue A n f o r d e r u n g e n (best performance) und Verbesserungsmöglichkeiten (best practice) aufzeigt.

43.3 Durchführungsvorschriften Die Durchführung der Befragung erfolgt schriftlich mit dem standardisierten Fragebogen. Da sich der Fragebogen an Führungskräfte wendet (CEO, CIO), die wenig Zeit haben, wird die Befragung durch einen IBM-Mitarbeiter unterstützt, der Erklärungshilfen zu den einzelnen Fragen geben kann. Die Interviewer werden im Umgang mit dem Meßinstrument geschult und kennen die intendierte Interpretation der Fragen. Um persönliche Einflüsse möglichst gering zu halten, sind sie gehalten, sich mit ihren Auskünften eng an den schriftlich ausformulierten Leitfaden zu halten, in dem alle Fragen ausführlich erläutert sind (zum Einfluß des Interviewers auf die Befragungsergebnisse vgl. [MüK193,38]).

Evaluation der IT-Fitness

87

43 Auswertungsvorschriften Um zu prägnanten Aussagen über die Leistungsfähigkeit der IT zu kommen, werden die Leistungsgrößen zu Kennzahlen verdichtet, die kritische Erfolgsfaktoren der IT repräsentieren. Die Kennzahlen werden durch Verdichtung mehrerer Merkmale (Items) zu Indizes gebildet 7 . Analog zur Aufteilung der Fragen in Praktik-, Performance- und Strukturitems werden die Indizes nach Praktik, Performance und Struktur unterschieden. Tabelle 2 zeigt die für die Auswertung gebildeten Indizes und ihre Interpretation. Bewertete Indizes (Praktik-und Performancevariablen)

Wertneutrale Indizes (Strukturvariablen)

•

Innovationsfähigkeit: Vorhandensein von Voraus- • setzungen, um innovative Lösungen implementieren zu können

Abhängigkeit von IT: Unverzichtbarkeit der IT für d e n reibungslosen Geschäftsablauf

•

Hebelwirkung: Einsatz von IT zur Umgestaltung organi- • satorischer A b l ä u f e des Unternehmens

Stellenwert der IT: Wertschätzung der IT im Unternehmen

•

S e r v i c e u m f a n g IT: U m f a n g und Vielfalt der von der IT • angebotenen Unterstützung (für Benutzer und Kunden)

Innovation: U m f a n g der innovativen Lösungen im Unternehmen

•

Anpassungsfähigkeit: Methoden und Vorgehensweisen, • u m auf geänderte A n f o r d e r u n g e n reagieren zu können; D o k u m e n t a t i o n als G r u n d l a g e f ü r W a r t b a r k e i t / • Änderbarkeit der IT

Standardisierung: Anteil der standardisierten Anwendungslösungen

•

Sicherheitspraktiken: S c h u t z m a ß n a h m e n gegen potentielle Gefährdung der IT

•

Kommunikationsfähigkeit: Einsatz, Unterstützung, Gestaltung und Kultur der Kommunikation

•

P l a n u n g und S t e u e r u n g : Einsatz von M e t h o d e n zur Planung und Steuerung und Durchgängigkeit der Planung und Steuerung der IT

•

Servicegrad IT: G ü t e der von der IT angebotenen Unterstützung (für Benutzer und Kunden)

•

A n p a s s u n g s f ä h i g k e i t : R e a k t i o n s f ä h i g k e i t d e r IT auf geänderte Anforderungen

•

G e s c h ä f t s e r f o l g ( P e r f o r m a n c e ) : Grad der E r r e i c h u n g betriebswirtschaftlicher Ziele (des Gesamtunternehmens)

•

Abstimmung: Zusammenspiel von Geschäftsmanagement und IM, IS und Geschäftsprozessen

Integration: Integration von A n w e n d u n g e n und Systemen untereinander

•

Heterogenität: Verschiedenartigkeit der eingesetzten IT-Systeme

•

Externe Dienstleister: A u s m a ß des E i n s a t z e s von e x t e r n e n D i e n s t leistungen im IT-Bereich

Tab. 2: Indizes der IT21-Analyse

Fast alle Praktik- und Performancemerkmale sowie ein großer Teil der Strukturmerkmale wird mit der in Abschnitt 4.2.1 beschriebenen Ordinalskala erhoben. Die Verdichtung zu Indizes erfolgt analog zur Likert-Skalierung über die Methode der summierten Ratings (vgl. [Schnell99,181f.], [Frie84,175f.]). Die Summe der Ratings wird auf eine Skala von 0 bis 100 transformiert; die 0

7

Unter einem Index wird die Zusammenfassung mehrerer Einzelindikatoren (Items) zu einer neuen Variable verstanden (vgl. [Schne99,I60f.] und [Fried84,165f.]).

88

Alexander Teubner/ Jahn Rentmeister /Stefan

Klein

entspricht der durchgängig geringsten Wertung (alle Bewertungen 1), die 100 der durchgängig höchsten Wertung (alle Bewertungen 5)8. Einige Merkmale werden nicht direkt auf einer Skala von 1 bis 5 gemessen, sondern darauf transformiert. Beispielhaft sei die Auswertung der Frage nach den zur Kommunikation mit Geschäftspartnern eingesetzten Medien aus Abbildung 6 angeführt. Jedem Feld der Frage ist - wie in Tabelle 3 dargestellt - ein Wert zugeordnet, der die „Innovativität" der Technik kennzeichnet; die Bewertung der Frage geht in den Index „Innovativität" ein. Als Bewertung wird der maximale Wert verwendet, der einem angekreuzten Feld zugeordnet ist. Feld Wert

Fax 1

Telefon 1

Brief 1

E-Mail 2

EDI 3

Dateitransfer 3

Datenbankzugriff

Interprozeßkommunikation zwischen Anwendungen

4

5

Tab. 3: Bewertungsschema zu Kommunikationsmedien

4.4 Abweichungsanalyse und Entwicklung von Korrekturmaßnahmen 4.4.1 Unternehmensvergleich Die Indizes geben den Unternehmen nur bedingt eine Orientierung: Die einzigen Größen, mit denen der durch die Indizes (Kennzahlen) beschriebene Ist-Zustand verglichen werden könnte, sind die Zielsetzungen des Unternehmens. Deshalb werden als weiterere, externe Größen Vergleichszahlen anderer Unternehmen angeboten. Es werden vier Vergleichsgruppen gebildet: • alle befragten Unternehmen; • die „Gewinner", das sind die 5% der Unternehmen, die bezüglich Praktiken und Performances am besten bewertet wurden; • die „Verlierer", das sind die 5% der Unternehmen, die bezüglich Praktiken und Performances am schlechtesten bewertet wurden; • die Unternehmen, die der gleichen Branche wie das betrachtete Unternehmen angehören. Für die vier Vergleichsgruppen werden die durchschnittlichen Indexwerte berechnet und denen des betrachteten Unternehmens gegenübergestellt. Dadurch soll es dem Unternehmen ermöglicht werden, sich ein differenziertes Bild der eigenen Position zu verschaffen und Defizite oder Vorsprünge gegenüber der Konkurrenz zu identifizieren. 4.4.2 Stärken-/Schwächen-Profil Indizes, die im Vergleich zu anderen Unternehmen verhältnismäßig stark abweichen, geben Anlaß für eine nähere Untersuchung der Abweichungen. Das Stärken-/Schwächen-Profil listet dazu die Stärken und Schwächen des UnterH

O b w o h l d i e E r m i t t l u n g z. T. sogar gewichteter a d d i t i v e r I n d i z e s ü b e r die M e t h o d e s u m m i e r t e r R a t i n g s

ü b l i c h ist ( v g l . [ S c h n e 9 9 , 1 6 5 f . ] , [Fried84,168]), ist die A d d i t i o n von W e r t e n u n t e r s c h i e d l i c h e r o r d i n a l e r S k a l e n s t r e n g g e n o m m e n nicht zulässig. A u s statistischer Sicht ist der M e d i a n die g e e i g n e t e M a ß z a h l , der a l l e r d i n g s e i n e g e r i n g e r e A u s s a g e k r a f t besitzt. E i n e e i n g e h e n d e r e D i s k u s s i o n d e r P r o b l e m a t i k a d d i t i v e r I n d i z e s findet sich in [Fried84,167f.].

Evaluation der IT-Fitness

89

nehmens in bezug auf den betroffenen Index auf, das heißt die Items mit der höchsten und niedrigsten Bewertung, die in den Index eingehen. Auf diese Weise ist es einem Unternehmen möglich, Schwachstellen aufzudecken und mögliche Ursachen dafür festzustellen. 4.43 Sachlogische Problemanalyse Neben der Auswertung über die Indizes gibt es eine begrenzte sachlogische Auswertung. Wichtige Datengrundlage für die Problemanalyse sind die erhobenen Strukturvariablen (vgl. Abschnitt 3.2), die eine situative Interpretation von Praktik- und Performancewerten ermöglichen. Ausgehend von der Beobachtung der IT-Situation werden anhand einfacher sachlogischer Regeln Hinweise auf mögliche Probleme des IM oder der IIS sowie Vorschläge für Verbesserungsmaßnahmen gegeben. Die Regeln sind in einfacher Wenn-Dann-Form gehalten, in deren Bedingungsteil (Wenn-Teil) Indikatoren verknüpft werden, die zu einer bestimmten Konklusion führen (Dann-Teil). Die Auswertung der Regeln erfolgt automatisch über eine Auswertungssoftware. Beispielsweise könnte festgestellt werden, daß in einem Unternehmen weniger als die Hälfte der Aufträge von der DV/IT-Abteilung im vereinbarten Zeitrahmen erledigt werden. Ein Verbesserungsvorschlag wäre der Einsatz externer Dienstleister für bestimmte Teilaufgaben, um die IT-Mitarbeiter zu entlasten. Wenn nach eigenen Angaben ausreichend Kapazität zur Verfügung steht, können auch Schwächen im Projektmanagement für das Problem verantwortlich sein.

5 Validität des Erhebungsinstrumentariums 5.1 Expertenvalidität Eine Möglichkeit, Hinweise über die Validität eines empirischen Instruments zu erhalten, ist es, die Aussagen des Instruments mit den Einschätzungen von Fachleuten zu vergleichen (vgl. [Fürt81,89f.]). Im Falle des IT21-Instrumentariums kommen als Fachleute zum einen die Berater der Firma IBM in Betracht, zum anderen die Geschäftsführer und IT-Leiter der befragten Unternehmen. Eine Beurteilung durch Mitarbeiter der IBM UBG (Unternehmensberatung) kommt bei den Unternehmen in Frage, die den Beratern aus Beratungsprojekten gut bekannt und deren Probleme ihnen vertraut sind. Drei Berater, welche die Entwicklung des Instruments verfolgt haben und in diese eingebunden waren, haben das Instrument bei ihren Kunden eingesetzt. Sie bestätigen, daß die Ergebnisse der Analyse mit den persönlichen Beratungserfahrungen übereinstimmen. Besonders hervorgehoben wird, daß das Instrument die Kernprobleme überblicksartig darstellt und gleichzeitig einzelne Teilprobleme in besonderer Weise akzentuiert.

90

Alexander Teubner / Jahn Rentmeister / Stefan Klein

Die Beurteilung durch die Geschäftsführer bzw. IT-Leiter findet bei der Präsentation der Ergebnisse statt, die typischerweise durch Mitarbeiter der IBM SMB (Geschäftsbereich Mittelstand) erfolgt. Die Rückmeldungen der Unternehmen bzw. der Mitarbeiter der IBM SMB sind positiv. Grobe Fehleinschätzungen wurden nicht berichtet, die meisten Unternehmen betrachten die mit dem Instrument ermittelten Bewertungen als zutreffende und aufschlußreiche Beschreibung ihrer IT-Situation. 5.2 Konstruktvalidität Eine weitere Möglichkeit, die Validität des Instruments zu prüfen, besteht im Vergleich der Meßergebnisse mit theoretischen Konstrukten (vgl. [Schne99,150f.]). Verhalten sich die Meßergebnisse so, wie die theoretischen Konstrukte es vermuten lassen, kann dies als Indiz dafür gewertet werden, daß das Instrument die Phänomene richtig erfaßt. Als Theoriegrundlage für die Prüfung der Konstruktvalidität bieten sich die in Abschnitt 3 thematisierten Erklärungsansätze an, die im IT21-Bezugsrahmen zusammengefaßt sind. Die wichtigsten Konstrukte sind: 1. die Hypothese, daß die Qualität des IM entscheidend für die Qualität der IIS ist; 2. die Hypothese, daß eine Abstimmung zwischen IM und Geschäftsmanagement zur Integration von IIS und Geschäftsprozessen beiträgt; 3. die Hypothese, daß sich die Qualität der IIS und deren Abstimmung mit den Geschäftsprozessen auf Produktivität und Unternehmenserfolg auswirkt. Ein Plot der Praktik- und Performancewerte des IM gegen die Werte der IIS bestätigt die erste Hypothese. Der Plot zeigt einen monotonen, positiven Zusammenhang, der durch den Spearmann'sehen Rangkorrelationskoeffizient rs beschrieben werden kann. Dieser nimmt einen Wert von 0,69 an. Der Zusammenhang ist hoch signifikant auf einem Niveau von 0,1%. Bezieht man zusätzlich die Abstimmung des IM mit dem Geschäftsmanagement bzw. der IIS mit den Geschäftsprozessen in die Untersuchung ein, erhöht sich rs auf 0,72. Der Zusammenhang ist ebenfalls signifikant auf dem 0,1%-Niveau. Mit Bezug auf die dritte Hypothese wurden die Mediane der IIS-Qualität in den Klassen der Produktivität abgetragen. Die Produktivität des Unternehmens wird in IT21 durch Selbsteinstufung im Vergleich zu den direkten Konkurrenten (1 = niedriger als Konkurrenz bis 5 = höher als Konkurrenz) erhoben. Der Plot zeigt deutlich einen Zusammenhang, der durch rs = 0,22 bestätigt wird und ebenfalls signifikant auf dem 0,1%-Niveau ist.

Evaluation der IT-Fitness

91

6 Fazit und Ausblick A n g e s i c h t s s t e i g e n d e r I n v e s t i t i o n e n in I T u n d verbreiteter U n s i c h e r h e i t ü b e r den dadurch erzielbaren Beitrag zum Unternehmenserfolg wurde mit d e m I T 2 1 - I n s t r u m e n t a r i u m e i n l e i s t u n g s f ä h i g e s Instrument zur strukturierten Erfass u n g u n d B e w e r t u n g der IT in k l e i n e n u n d m i t t e l g r o ß e n U n t e r n e h m e n e n t wickelt. W e g e n der o f f e n s i c h t l i c h e n P r o b l e m e , e i n s o k o m p l e x e s u n d h e t e r o g e n e s G e b i e t a n g e m e s s e n z u e r h e b e n , und a u c h i m H i n b l i c k a u f d e n Z u g a n g z u m Feld und eine möglichst hohe Zahl von Fällen wurden z u m Teil pragmatische Entscheidungen getroffen. D i e vorliegenden Ergebnisse bestätigen dieses Vorg e h e n i n s o f e r n , als s o w o h l für d i e b e f r a g t e n U n t e r n e h m e n a l s a u c h i m H i n blick auf die wissenschaftliche Analyse aussagefähiges Material erhoben werden konnte. In Z u k u n f t k a n n der n o c h a n w a c h s e n d e D a t e n b e s t a n d für w e i t e r g e h e n d e P r ü f u n g e n z u r A u s s a g e k r a f t d e s I n s t r u m e n t s u n d zur G e w i n n u n g n e u e r E r f a h r u n g e n u n d E r k e n n t n i s s e über M ö g l i c h k e i t e n u n d G r e n z e n d e r I T Evaluation genutzt werden.

Literatur [Ball95] Ballantine, J. A. et al.: The use and importance of financial appraisal techniques in the IS/IT investment decision-making process. Project Appraisal 4/1995, 233 - 241 [Ball98] Ballantine, J. et al.: Evaluating information systems in small and medium-sized enterprises: issues and evidence. In: European Journal of Information Systems 7/1998, 241 - 2 5 1 [Bryn93] Bryjolfson, E.: The productivity paradox of information technology. In: Communications of the ACM 12/1993, 67 - 77 [Bren94] Brenner, W.: Grundzüge des Informationsmanagements. Berlin/Heidelberg 1994 [Dave93] Davenport, T. H.: Process Innovation: Reengineering Work Through Information Technology. Boston 1993 [Frie84] Friedrichs, J.: Methoden empirischer Sozialforschung. Opladen 1984 [Fürt81] Fürtjes, H.-T.: Das Gestaltungspotential von Instrumenten der empirischen Wirtschafts- und Sozialforschung. Berlin 1981 [HaCh93] Hammer, M. / Champy, J.: Reengineering the Corporation. A Manifesto for Business Revolution. New York 1993 [Hein99] Heinrich, L. J.: Informationsmanagement. München/Wien 1999 [HeVe93] Henderson, J. C. / Venkatraman, N.: Strategic alignment: Leveraging information technology for transforming organizations. In: IBM Systems Journal 1 / 1 9 9 3 , 4 - 16 [Hend96] Henderson, J. C. et al.: Aligning Business and IT Strategies. In: Lufman, J. M. (ed): Competing in the Information Age: Strategic Alignment in Practice. New York et al. 1996,21 - 4 2 [IBM98] IBM Deutschland GmbH: IT21 Analyse für den Mittelstand. Fragebögen. IBM Form GM 12-6111-0 (6/98) und GM 12-6115-0 (6/98). Stuttgart 1998 [Klan90] Klandt, H.: Empirische Exploration zur Entwicklung einer Struktur von Vertriebsvergleichskennzahlen für Software und Systemhäuser unter Berücksichtigung der Unternehmens-Lebensphasen. Arbeitspapiere der GMD 444, St. Augustin 1990 [MÜK193] Müller-Böling, D. / Klandt, H.: Methoden der empirischen Wirtschafts- und Sozialforschung. Köln/Dortmund 1993 [Schne99] Schnell, R. et al.: Methoden der empirischen Sozialforschung. München/Wien 1999

92

Alexander Teubner / Jahn Rentmeister /Stefan

Klein

[SmHi98] Smithson, S. / Hirschheim, R.: Analysing information systems evaluation: another look at an old problem. In: European Journal of Information Systems 7/1998, 158- 174 [Stein94] Steinbock, H.-J.: Potentiale der Informationstechnik - State of the Art und Trends aus Anwendersicht. Stuttgart 1994 [Welg88] Welge, M. K.: Unternehmensführung. Band 3: Controlling. Stuttgart 1988 [Wiga98] Wigand, R. et al.: Information, Organization and Management: Expanding Markets and Corporate Boundaries. Chichester 1998 [WiLe97] Willcocks, L. / Lester, S.: Assessing IT Productivity: Any Way Out of the Labyrinth? In: Willcocks, L. et al. (eds): Managing ΓΓ as a Strategic Resource. London et al. 1997,64-93

WITIG1 - Eine Methode zur Evaluation von Informationssystemen Anton J. van Reeken [email protected] F a c h g r u p p e R e c h n u n g s w e s e n und F i n a n z i e r u n g der Universität Maastricht www-fdewb.unimaas.nl/berichtgeving/staff/index.html

Inhalt 1 2 3 4 5

Problemstellung Arbeitsschritte der WITIG-Methode A n w e n d u n g der WITIG-Methode Vorteile der WITIG-Methode Anwendungserfahrungen

Zusammenfassung WITIG ist eine Weiterentwicklung der Evaluierungsmethode von Eugene Bedell (vgl. [Bede85,19f.]). Dieser Beitrag beschreibt die Methode und erläutert ihre Anwendung. Wesentliches Merkmal der Methode ist, daß mit ihr relativ schnell Investitionsentscheidungen, die zur Verbesserung bzw. Neuentwicklung von Informationssystemen erforderlich sind, vorbereitet und gefällt werden können. Es erfolgt zunächst eine Analyse der bestehenden Informationssysteme, bei der unter anderem die Qualität der Informationssysteme und die Wichtigkeit der betrieblichen Aufgaben bzw. Geschäftsprozesse (in der Terminologie der WITIG-Methode als Aktivitäten und ihre Funktionen bezeichnet) evaluiert werden. Ist die Qualität der Informationssysteme im Vergleich zur Wichtigkeit der Aktivitäten und Funktionen zu gering, werden Investitionsempfehlungen gegeben.

Abstract WITIG is a further development of Eugene Bedell's Evaluation Method (see [Bede85,19p.]). This paper describes WITIG and demonstrates how to apply it. Characteristic of the method are the relatively quick investment decisions to improve or renew information systems. The decisions are based upon an analysis of all operational information systems. The quality of which and the importance of the supported business activities and functions are charted. If the quality of an information system in relation to the importance of the supported business activities and functions is too low, suggestions f o r improvement of the information system are given.

1

W I T I G ist (in n i e d e r l ä n d i s c h e r S p r a c h e ) ein A k r o n y m v o n „Waarde van I T - I n v e s t e r i n g e n v o o r j e G e l d " , w a s

b e d e u t e t : „ W e r t f ü r Ihr G e l d von IT-Investitionen".

94

Anton J. van Reeken

1 Problemstellung Organisatorische Verbesserungen sind häufig nur mit Hilfe von Informations- und Kommunikationstechnologien (im folgenden mit IuK-Technologien oder IKT bezeichnet) möglich, das heißt durch Schaffung neuer oder wesentlich veränderter Informationssysteme. Geplante Verbesserungen erfordern Investitionsvorschläge, die sowohl einzeln als auch im Wettbewerb mit anderen evaluiert werden müssen. Dabei muß davon ausgegangen werden, daß der Nutzen des Technologieeinsatzes nicht vollständig quantifiziert werden kann. Dies überwindet die WITIG-Methode durch Evaluation der Wichtigkeit der Investitionsvorhaben durch die Mitarbeiter, die an der Entstehung der Kosten und an der Realisierung des Nutzens beteiligt sind. Auch die Qualität der bestehenden Informationssysteme wird mit der WITIG-Methode evaluiert, und zwar durch die Mitarbeiter, die für die Realisierung der Qualitätsforderungen verantwortlich sind. Aufgrund der Ergebnisse dieser Evaluationen können folgende Fragen beantwortet werden: • Stimmt die Qualität der Informationssysteme mit ihrer Wichtigkeit überein? • Wenn nein, für welche betrieblichen Aufgaben bzw. Geschäftsprozesse ist die Qualität zu gering? • Wenn ja, welche Informationssysteme dieser betrieblichen Aufgaben bzw. Geschäftsprozesse haben eine zu niedrige Qualität im Vergleich zu ihrer Wichtigkeit? Aufgrund der Antworten zu diesen Fragen werden mit Hilfe der WITIGMethode Informatik-Projekte definiert, deren Zweck es ist, die Qualitätsmängel der Informationssysteme zu beseitigen bzw. neue oder wesentlich veränderte Informationssysteme zu schaffen. In beiden Fällen verlangt die WITIG-Methode eine Schätzung der Entwicklungskosten. Weil die Qualitätsforderungen an die Informationssysteme bekannt sind, können vor der Projektverwirklichung die drei genannten Fragen beantwortet werden. Folgende Arbeitsschritte sind dabei erforderlich: 1. Ermitteln der Wichtigkeit der betrieblichen Aufgaben bzw. Geschäftsprozesse für die Erreichung der Unternehmensziele; 2. Ermitteln der Wichtigkeit jeder einzelnen Funktion der betrieblichen Aufgaben bzw. Geschäftsprozesse für die Erreichung der Unternehmensziele, 3. Ermitteln der Wichtigkeit von IuK-Technologien generell für solche betrieblichen Aufgaben bzw. Geschäftsprozesse; 4. Ermitteln der Qualität der Informationssysteme für eine oder mehrere Funktionen; 5. Analysieren des Istzustands; 6. Erstellen der „Short List". In der WITIG-Methode nimmt die Wichtigkeit eines Informationssystems mit der Wichtigkeit der von diesem Informationssystem unterstützten Funk-

WITIG - Eine Methode

zur Evaluation

von Informationssystemen

95

tion, mit der Wichtigkeit der von der betreffenden Funktion unterstützten Aktivität und mit der Wichtigkeit der IKT überhaupt für solche Aktivitäten zu. Der Einfluß eines Informationssystems auf Effektivität und Effizienz betrieblicher Aufgaben bzw. Geschäftsprozesse steigt mit der Qualität des Informationssystems und mit der Wichtigkeit der vom betreffenden Informationssystem unterstützten Funktionen und Aktivitäten für diese betrieblichen Aufgaben bzw. Geschäftsprozesse. Im folgenden werden die sechs Arbeitsschritte der WITIG-Methode erläutert. Zur Demonstration wird ein kleines Unternehmen der Fertigungsindustrie verwendet (vgl. [Bede85,41f.]), in dem vier betriebliche Aufgaben bzw. Geschäftsprozesse unterschieden werden: Produktentwicklung, Fertigung, Vertrieb und Finanzen. Jede dieser Aufgaben hat mehrere Funktionen, für deren Bearbeitung Informationssysteme erforderlich sind (vgl. Tabelle 2). Die WITIG-Methode wird in Abschnitt 2 anhand ihrer Arbeitsschritte dargestellt. Ihre Anwendung wird in Abschnitt 3 erläutert. Abschnitte 4 und 5 zeigen die Vorteile der WITIG-Methode und referieren über Anwendungserfahrungen.

2 Arbeitsschritte der WITIG-Methode Arbeitsschritt 1: Ermitteln der Wichtigkeit Geschäftsprozesse für die Erreichung der

der betrieblichen Aufgaben Unternehmensziele.

bzw.

Die betrieblichen Aufgaben bzw. Geschäftsprozesse eines Unternehmens (im folgenden als Aktivitäten bezeichnet) können am besten mit Hilfe der Wertkette (vgl. [PoMi85,151]) erfaßt werden. Danach gibt es primäre Aktivitäten und unterstützende Aktivitäten. Primäre Aktivitäten sind solche, die nicht nur Kosten verursachen, sondern dem Produkt oder der Dienstleistung aus der Sicht des Kunden auch Wert zufügen und deswegen mit 6, 8 oder 10 bewertet werden. Den Wert 10 erhalten schwierig zu realisierende Aktivitäten, die für die Erreichung der Unternehmensziele sehr wichtig sind, mit anderen Worten: Ohne diese Aktivitäten können die Unternehmensziele auf keinen Fall erreicht werden. Schwierig zu realisierende, aber weniger wichtige Aktivitäten werden mit 8 bewertet. Wenn mit diesen Aktivitäten etwas schief geht, können die Unternehmensziele noch erreicht werden. Die übrigen Aktivitäten sind zwar notwendig, aber nicht schwierig zu realisieren oder kritisch; sie erhalten den Wert 6. Unterstützende Aktivitäten sind Aktivitäten, die Kosten verursachen und aus der Sicht des Kunden keinen Wert erzeugen (z.B. Werksschutz); sie werden mit 4 bewertet. Den Wert 2 erhalten Führungsaktivitäten, die in der Wertkette aber nicht explizit genannt sind. Aktivitäten, auf die verzichtet werden kann, werden mit 0 bewertet. Die verwendete Ordinalskala kennt nur die Werte 0, 2, 4, 6, 8 und 10; Zwischenwerte sind nicht zulässig (obwohl viele neue Anwender der WITIG-

96

Anton

J. van

Reeken

Methode dies immer wieder versuchen). Die Bewertung erfolgt durch das Top-Management; sie wird als WAU (das heißt Wichtigkeit der Aktivität f ü r das Unternehmen) bezeichnet. Tabelle 1 zeigt in Spalte WAU die Werte f ü r die vier Aktivitäten des Demonstrationsbeispiels. (Die anderen Spalten werden weiter unten erläutert.) Aktivitäten Produktentwicklung Fertigung

WAU

WIA

ÄFF

10

10

100

8

10

80

Vertrieb

8

5

40

Finanzen

2

5

10

28

WIU = 230/28 = 8,2

230

T a b . 1 : W A U , W I A und Ä F F für das Demonstrationsbeispiel

Arbeitsschritt 2: Ermitteln der Wichtigkeit jeder einzelnen Funktion betrieblichen Aufgaben bzw. Geschäftsprozesse für die Erreichung Unternehmensziele.

der der

Ebenso werden die Funktionen jeder einzelnen Aktivität bewertet. Die Funktionen einer Aktivität können in der gleichen Weise erfaßt werden wie die Aktivitäten. Jede Aktivität enthält primäre Funktionen, unterstützende Funktionen und Führungsfunktionen. Die Bewertung der Funktionen wird mit WFA (das heißt Wichtigkeit der Funktion für die Aktivität) bezeichnet. Eine Funktion, die kritisch ist, wird mit 10 bewertet. Andere Funktionen werden mit 5 oder mit 1 bewertet. Wenn eine Funktion nützlich, aber nicht kritisch für die Aktivität ist (weil Alternativen möglich sind), wird sie mit 1 bewertet. Der Wert 5 wird verwendet, wenn weder 10 noch 1 angemessen sind (z.B. wenn eine Funktion nicht kritisch, aber operativ notwendig ist). Wenn eine Funktion keinen Beitrag zu der Aktivität leistet, wird sie mit 0 bewertet. (Man fragt sich immer, warum es solche Funktionen überhaupt gibt, aber es gibt sie erfahrungsgemäß immer wieder.) Diese Werte werden vom Abteilungsmanagement bzw. Geschäftsprozeßmanagement vergeben. Die Wichtigkeit einer Funktion für das Unternehmen WFU wird nach Formel ( 1 ) bestimmt: (1) WFU = WFA χ WAU Tabelle 2 zeigt WFA für alle Funktionen des Demonstrationsbeispiels.

WITIG - Eine Methode zur Evaluation von Informationssystemen Aktivität

Funktion/System

WFA

Produktentwicklung

Strukturelle Analyse

10

Numerische Steuerung

10

10

5

50

5

0

0

Lagerbewirtschaftung

10

10

100

Beschaffung

10

5

50

Kostenrechnung

Vertrieb

Finanzen

ESA 1

Zeichnen Fertigung

QSF

97

5

10

50

Stückliste

10

10

100

Bedarfsvorhersage

10

0

0

Auftragsbearbeitung

5

1

5

Absatzstatistik

1

0

0

Finanzbuchhaltung

1

5

5

Löhne und Gehälter

5

10

50

Kreditoren

5

5

25

Anlagenbuchhaltung

1

0

0

Tab. 2: W F A , Q S F und E S A der Aktivitäten und Funktionen

Arbeitsschritt 3: Ermitteln der Wichtigkeit von IuK-Technologien für solche betrieblichen Aufgaben bzw. Geschäftsprozesse.

generell

Da das Ermitteln der Wichtigkeit von IKT nicht unproblematisch ist, wird häufig vom Top-Management externe Beratung eingeholt. Bei Durchführung dieses Arbeitsschritts besteht daher die Gefahr, daß ein gewisser „LemmingEffekt" eintritt (das heißt, wenn viele es so gemacht haben, dann wird es wohl vernünftig sein, es auch zu tun; aber wenn viele sich geirrt haben, kann man sich auch irren). Auch hier gibt es nur die Werte 10, 5, 1 und 0. Der Wert 10 wird vergeben, wenn die Aktivität ohne von IKT unterstützte Informationssysteme nicht wettbewerbsfähig ist. Der Wert 0 wird vergeben, wenn die Aktivität ohne von IKT unterstützte Informationssysteme wettbewerbsfähig wäre. Der Wert 1 wird vergeben, wenn es zwar denkbar wäre, ohne von IKT unterstützte Informationssysteme auszukommen, diese aber sehr nützlich wären. Wenn ohne von IKT unterstützte Informationssysteme ein operationeller Faktor geworden sind, wird mit 5 bewertet. Die potentielle Wichtigkeit von IuK-Technologien für die Aktivität WIA ist zeitabhängig, weil sie darauf basiert, was Stand der Technik ist und was die Mitbewerber tun. Für jede Aktivität kann nun ein Fokus-Faktor gemäß Formel (2) ermittelt werden: (2) ÄFF = WIA χ WAU

98

Anton J. van Reeken

AFT7 zeigt die potentielle Wichtigkeit der Unterstützung einer Aktivität durch IuK-Technologien für die Erreichung der Unternehmensziele. Dividiert man den Aktivitäts-Fokus-Faktor durch Summe (WAU), so ergibt sich der WIUWert nach Formel (3): (3) WIU = Summe (ÄFF) / Summe (WAU) WIU bringt die potentielle Wichtigkeit von IuK-Technologien für das Unternehmen zum Ausdruck. Tabelle 1 zeigt WIA für die vier Aktivitäten des Demonstrationsbeispiels sowie ÄFF und WIU. Arbeitsschritt oder mehrere

4: Ermitteln Funktionen.

der Qualität der Informationssysteme

für

eine

Wenn eine Liste der Aktivitäten und deren Funktionen vorhanden ist, kann neben jeder Funktion auch das sie unterstützende Informationssystem (das braucht kein IKT-unterstütztes System zu sein) bezeichnet werden. Wenn f ü r eine Funktion kein Informationssystem angegeben werden kann, hat es keinen Zweck, diese Funktion weiter zu berücksichtigen. Das hätte bereits bei der Bewertung der Funktionen (vgl. Arbeitsschritt 2) geschehen können, aber hier ist es sicherer. Durch den QSF-Wert, das heißt die Qualität des Systems für die Funktion, wird für jedes Informationssystem ermittelt, wie die betreffende Funktion unterstützt wird. Der QSF-Wert ist 10, 5, 1 oder 0. Der Wert 10 bedeutet, daß das Informationssystem ideal ist. Der Wert 0 bedeutet, daß ein Informationssystem fehlt oder unnütz ist. Die Werte 5 und 1 werden wie folgt vergeben: Es werden drei Eigenschaften von Informationssystemen beurteilt, nämlich Funktionalität, technische Adäquatheit und Wirtschaftlichkeit. Merkmale der technischen Adäquatheit sind unter anderem Zuverlässigkeit, Wartbarkeit und Erweiterbarkeit. Ein Informationssystem kann funktionell und technisch geeignet, mit anderer IuK-Technologie aber wirtschaftlicher sein. Wenn alle drei Eigenschaften unzureichend sind, dann wird QSF mit 0 bewertet. Wenn zwei Eigenschaften unzureichend sind, dann wird QSF mit 1 bewertet. Wenn eine Eigenschaft unzureichend ist, wird QSF mit 5 bewertet. Wenn keine Eigenschaft unzureichend ist, wird QSF mit 10 bewertet. Die QSF-Werte werden von Benutzern, Systembetreuern und Abteilungsmanagern bzw. Geschäftsprozeßmanagern gemeinsam erarbeitet. Tabelle 2 zeigt den QSF für alle Informationssysteme (Funktion/System) des Demonstrationsbeispiels. Angenommen, jedes Informationssystem unterstützt nur eine Funktion. Dann kann der Einfluß eines Informationssystems auf die Aktivität (ESA) nach Formel (4) berechnet werden (vgl. auch Tabelle 2): (4) ESA = QSF χ WFA Der Einfluß eines Informationssystems auf das Unternehmen wird nach Formel (5) berechnet:

WITIG - Eine Methode zur Evaluation von Informationssystemen

99

(5) ESU = QSF χ WFA χ WAU Wird der Einfluß aller Informationssysteme einer Aktivität zusammengezählt, dann wird die Summe aller ESA gebildet. Dividiert man diese Summe durch die Summe aller WFA, so erhält man eine Art durchschnittlichen Einflusses der Informationssysteme einer Aktivität, also: (6) EIA = Summe (ESA) / Summe (WFA) EIA kann für jede Aktivität ermittelt werden. Man kann auch sagen, EIA ist der mit WFA gewogene Mittelwert der diese Aktivität betreffenden QSF. Ebenso folgt: (7) EIU = Summe (ESU) / Summe (WFU) EIU ergibt eine Art durchschnittlichen Einflusses der Informationssysteme eines Unternehmens. Das heißt, EIU ist der mit WFU gewogene Mittelwert der dieses Unternehmen betreffenden QSF. Tabelle 3 zeigt EIA und EIU f ü r das Demonstrationsbeispiel. Aktivitäten

Produktentwicklung

Summe

Summe

Summe

Summe

(ESA)

(ESU)

(WFA)

(WFU)

EIA

60

600

25

250

2,4

300

2400

45

360

6,7

Vertrieb

5

40

6

48

0,8

Finanzen

80

160

12

24

6,7

682

EIU = 3200/682 = 4,7

Fertigung

3200

Tab. 3: Einfluß der I u K - T e c h n o l o g i e auf j e d e Aktivität und auf das Unternehmen

Wenn ein Informationssystem mehrere Funktionen unterstützt, trifft das oben Erörterte in gleicher Weise zu. Nur die Qualität des betreffenden Informationssystems soll nicht als QSF, sondern als QSU, das heißt als Summe (ESU) / Summe (WFU) über die vom betreffenden Informationssystem unterstützten Funktionen berechnet werden. Die QSF-Werte sind ja immer per Funktion gegeben; also können ESA und ESU und deswegen auch EIA und EIU berechnet werden. Arbeitsschritt

5: Analysieren des

Istzustands.

Nach Durchführung der Arbeitsschritte 1 bis 4 liegen die Daten vor, die zur Beantwortung der drei Fragen aus Abschnitt 1 notwendig sind. Frage 1 lautet: • Stimmt die Qualität der Informationssysteme mit ihrer Wichtigkeit überein?

100 Anton J. van Reeken

Die (mittlere) Wichtigkeit der Informationssysteme ist in Arbeitsschritt 3 mit WIU berechnet worden. Die (mittlere) Qualität der Informationssysteme ist in Arbeitsschritt 4 mit EIU berechnet worden. Eine Grafik kann dazu benutzt werden, zu zeigen, wie sich WIU und EIU zueinander verhalten. Eine Investitionsempfehlung wird dann gegeben, wenn WIU/EIU>1. Abbildung 1 zeigt WIU versus EIU für das Demonstrationsbeispiel. 10

aggressiv investieren

selektiv investieren

0 5

0

desinvestieren

/stabilisieren J

EIU-Wert

'

Abb. 1 : WIU versus EIU für das Demonstrationsbeispiel

Frage 2 lautet: • Wenn nein, für welche betrieblichen Aufgaben bzw. Geschäftsprozesse ist die Qualität zu gering? Wenn WIU/EIU>1 (was für das Demonstrationsbeispiel zutrifft), dann wird für jede Aktivität die Wichtigkeit, ausgedrückt im Aktivitäts-Fokus-Faktor ÄFF, mit der (mittleren) Qualität der Informationssysteme dieser Aktivität EIA verglichen. Dafür kann die Grafik wie in Abbildung 1 benutzt werden, in der alle Aktivitäten zugleich gezeigt werden. Eine Investitionsempfehlung wird dann gegeben, wenn (AFF/10)/EIA>1. Abbildung 2 zeigt ÄFF versus EIA für die Aktivitäten des Demonstrationsbeispiels. Frage 3 lautet: • Wenn ja, welche Informationssysteme dieser betrieblichen Aufgaben bzw. Geschäftsprozesse haben eine zu niedrige Qualität im Vergleich zu ihrer Wichtigkeit? Für Aktivitäten mit (AFF/10)/EIA>1 kann die Wichtigkeit aller Funktionen für das Unternehmen (WFU) mit der Qualität der unterstützenden Informationssysteme (QSF) verglichen werden. Es kann wieder die Grafik wie in Abbildung 1 benutzt werden. Eine Investitionsempfehlung wird dann gegeben, wenn (WFU/10)/QSF>1. Abbildung 3 zeigt WFU versus QSF für die Fertigungssysteme des Demonstrationsbeispiels.

WITIG - Eine Methode

zur Evaluation

Fe Fi Ρ V

von Informationssystemen

101

Fertigung Finanzen Produktentwicklung Vertrieb

0

desinvestieren Abb. 2: Ä F F versus EIA für die Aktivitäten des Demonstrationsbeispiels

EIA-Wert 100 hohe Priorität

Effektivität behalten,

Bd

0

/

i

a> 1 u. £

5 0

[1

0

Bd Bs Κ L S

Bedarfsvorhersage Beschaffung Kostenrechnung Lagerbewirtschaftung Stückliste

niedrige Priorität

Bruch vermeiden

10 QSF/QSU-Wert

Abb. 3: WFO versus QSF für die Fertigungssysteme des Demonstrationsbeispiels

Jetzt kann eine Liste der Informationssysteme erteilt werden, für die gilt, daß (WFU/10)/QSF>1, mit den Funktionen, die dadurch unterstützt werden. Damit können die verantwortlichen Abteilungsmanager bzw. Geschäftsprozeßmanager Investitionsvorschläge machen, mit denen Q S F erhöht wird. QSF braucht nicht höher als WFU/10 zu sein. Damit wird also das Anspruchsniveau beschränkt. WIA wird durch die Priorität der Aktivitäten, nicht durch die ihrer Funktionen beeinflußt; WIA ist in WFTJ also nicht enthalten. Arbeitsschritt

6: Erstellen der „Short List".

Die Abteilungsmanager bzw. Geschäftsprozeßmanager bringen ihre Investitionsvorschläge ein. Wichtig ist dabei die neu zu erzielende Qualität QSF' und eine Schätzung der Entwicklungskosten K, verringert durch die bei Realisierung der Vorschläge entfallenden Kosten. Hiermit können folgende Kennziffern berechnet und der Sollzustand kann analysiert werden: • Für jeden Investitionsvorschlag kann WFU im Vergleich zu QSF gezeigt werden. • Für jede Aktivität kann Ä F F im Vergleich zu EIA gezeigt werden.

102 Anton J. van Reeken

• Für das Unternehmen kann WIU im Vergleich zu EIU gezeigt werden. • Die projektierten Beiträge zu EIU jedes einzelnen Investitionsvorschlags können berechnet werden. Diese sind proportional mit BEI = (QSF'QSF)xWFU, und BEI reicht für die Priorisierung. Die Prioritäten für die Ausführung der Investitionsvorschläge können der Größe dieser Beiträge entsprechend festgelegt werden. Tabelle 4 zeigt die Investitionsvorschläge für das Demonstrationsbeispiel. Aktivität

Funktion7Systcm

Produktentwicklung

Strukturelle Analyse

1

10

Numerische Steuerung

5

Zeichnen

0 10

10

-

Fertigung

Lagerbewirtschaftung

BEI

150

900

10

80

500

5

150

250

5

10

85

10

10

-

Stückliste

10

10

0

10

Bedarfsvorhersage

Finanzen

Kosten/1000

QSF'

Kostenrechnung

Beschaffung

Vertrieb

QSF

-

-

400 -

200

800

Auftragsbearbeitung

1

5

55

160

Absatzstatistik

0

10

70

80

Finanzbuchhaltung

5

10

40

10

Löhne und Gehälter

10

10

-

-

Kreditoren

5

10

12

50

Anlagenbuchhaltung

0

5

50

10

Tab. 4: Investitionsvorschläge mit QSF, Q S F ,

Kostenschätzung und BEI

Voneinander abhängige (Teil)Systeme eignen sich für die „Short List" als sich ausschließende Kombinationen mit summierten BEI-Werten und mit den Gesamtkosten der an einer Kombination beteiligten (Teil)Systeme. Sind beispielsweise Β und C abhängig von A, dann gibt es die sich ausschließenden Kombinationen Α, Α + Β, A + C und A + Β + C. Es hat keinen Zweck, die Projekte Α, Β und C zu priorisieren, weil dann möglicherweise C eine hohe und A eine niedrigere Priorität bekommen könnten. Gesamtkosten bedeutet beispielsweise, daß A + Β + C billiger ist als (Α + Β) + ( A + C) - Α. Daraus könnte folgen, daß A + C gemäß BEI auf die „Short List" kommt und Β weder in Kombination mit A noch mit A und C. Priorisieren der von den Abteilungsmanagern erwünschten QSF' (mit dazu gehöriger Schätzung der K) ist nicht die einzige Möglichkeit. Es könnten auch sich ausschließende Alternativen, beispielsweise eine mit kleinerer und eine konkurrierende mit größerer QSF' und mit unterschiedlichem K, priorisiert werden. Oder es könnte eine Lösung mit Standardsoftware, wodurch QSF' und Κ gegeben sind, vorgeschlagen und priorisiert werden.

WITIG - Eine Methode zur Evaluation von Informationssystemen

103

Auch könnten als sich ausschließende Alternativen eine Lösung mit Standardsoftware und eine konkurrierende Lösung mit Eigenentwicklung bevorzugt werden. Es ist nicht immer klar, welche Alternative besser ist. Die Höhe der verfügbaren Investitionsmittel begrenzt die Anzahl der Vorschläge, die auf die „Short List" kommen. Die Vorschläge werden weiter analysiert und auf Richtigkeit der Spezifikation und Kostenschätzung, Kapazitätsbedarf, Risiko usw. überprüft. Dies ist jedoch nicht Gegenstand der WITIG-Methode.

3 Anwendung der WITIG-Methode Angefangen wird mit einer Erklärung der Methode für alle an der Anwendung Beteiligte. Diese Erklärung kann nur von Personen erfolgen, die mit der Methode vertraut sind. Relativ viele Mitarbeiter können bei der Anwendung beteiligt sein, wie später gezeigt wird. Zur Ermittlung des WAU wird das Top-Management und werden die Abteilungsmanager bzw. Geschäftsprozeßmanager gebraucht. Zur Ermittlung der WFA ist die Mitwirkung jedes einzelnen Abteilungsmanagers bzw. Geschäftsprozeßmanagers mit deren Mitarbeitern erforderlich. Zur Ermittlung der WIA muß jeder Abteilungsmanager bzw. Geschäftsprozeßmanager und der Informationsmanager herangezogen werden. Zur Ermittlung der QSF werden die Benutzer und die Mitarbeiter der Informatik-Abteilung, die das betreffende Informationssystem betreuen und warten, benötigt. Die Mitwirkung einiger Systemanalytiker ist zweckmäßig. Folgende Vorgehensweise bei der Anwendung der WITIG-Methode wird empfohlen: 1. Es wird eine Arbeitsgruppe mit mindestens drei Pesonen, zwei Systemanalytikern und einem Teamleiter (der Controller wäre eine gute Wahl, der Informationsmanager wäre eine schlechte Wahl) gebildet. 2. Diese Arbeitsgruppe beginnt damit, die Aktivitäten zu definieren; die Aktivitätenliste wird vom Teamleiter mit dem Top-Management besprochen und schließlich akzeptiert. Dann ermitteln das Top-Management und die zuständigen Abteilungsmanager bzw. Geschäftsprozeßmanager den WAU-Wert. 3. Davon ausgehend definiert die Arbeitsgruppe die Funktionen. Die Funktionslisten werden vom zuständigen Abteilungsmanager bzw. Geschäftsprozeßmanager akzeptiert, wonach sie gemeinsam mit den Team-Mitgliedern der Abteilung bzw. des Geschäftsprozesses den WFA-Wert ermitteln. 4. Die Arbeitsgruppe weist anschließend jedem Informationssystem Funktionen zu. Dies erfolgt im Gespräch mit den Benutzern und den zuständigen Mitarbeitern der Informatik-Abteilung. Es sind mehrere Gesprächsrunden erforderlich, um die System-Funktions-Matrix in einer von den Beteiligten akzeptierten Beschreibung zu erarbeiten. Dann können alle QSF-Werte ermittelt werden. Es hat sich bewährt, zuerst eine schriftliche qualitative Bewertung der Funktionalität und Wirtschaftlichkeit durch die Benutzer und der technischen Adäquatheit und Wirtschaftlichkeit durch

104

Anton J. van Reeken

die Mitarbeiter der Informatik-Abteilung durchzuführen und die Ergebnisse den Bewertern vorzulegen. Nur wenn Uneinigkeit besteht, sollte darüber mit den Beteiligten diskutiert werden. 5. Inzwischen kann sich der Teamleiter mit einzelnen Abteilungsmanagern bzw. Geschäftsprozeßmanagern um eine Bewertung der WIA kümmern. 6. Die Übersichten WIU versus EIU, ÄFF versus EIA und WFU versus QSF werden allen Beteiligten präsentiert. Wenn dazu Anlaß besteht, beauftragt das Top-Management die betreffenden Abteilungsmanager bzw. Geschäftsprozeßmanager, Vorschläge zur Verbesserung der EIU zu machen. 7. Diese Vorschläge werden von der Arbeitsgruppe in Übersichten, wie in Arbeitsschritt 6 beschrieben, dokumentiert und dem Top-Management sowie den Abteilungsmanagern bzw. Geschäftsprozeßmanagern übergeben. Es ist zu empfehlen, alle Dokumente aufzubewahren, weil sie möglicherweise wieder benutzt und weiterverarbeitet werden können. Erforderliche Hilfsmittel beschränken sich auf die verschiedenen Listen wie beschrieben (insbesondere die System-Funktions-Matrix) und ein Tabellenkalkulationsprogramm zur Berechnung von WFU, WIU, ÄFF, EIA, EIU, BEI.

4 Vorteile der WITIG-Methode Die WITIG-Methode gibt dem Top-Management die Möglichkeit, über einen Vergleich von WIU und EIU festzustellen, ob in IuK-Technologien investiert werden soll und welches Budget dafür erforderlich wäre. Viele Methoden der Ex-ante-Evaluation, Rockart's CSF-Methode (vgl. [Rock79]) ausgenommen, gehen von bereits bestehenden Projektvorschlägen aus, die evaluiert werden. Die WITIG-Methode ergibt priorisierte Investitionsvorschläge, ohne daß Projektvorschläge vorliegen müssen. Die strategische Informatik-Planung, insbesondere die strategische Maßnahmenplanung (vgl. [Hein99,127f.]), hat in den Unternehmen zu zahlreichen Projektvorschlägen geführt, die jedoch nur selten verwirklicht wurden. Die WITIG-Methode beschränkt sich zunächst auf die betrieblichen Aufgaben bzw. Geschäftsprozesse (Aktivitäten), für die (AFF/10)/EIA>1, und konzentriert sich dann auf die Funktionen, für die (WFU/10)/QSF>1. Eine „Short List" der realisierbaren Investitionsvorschläge kann in kurzer Zeit und mit geringem Aufwand erarbeitet werden. Eine Kosten/Nutzen-Analyse durchzuführen, die alle Nutzenargumente berücksichtigt, ist kaum möglich. Die Nutzenargumente sind oft kaum schärfer als „es ist wichtig, daß wir das jetzt tun" zu formulieren, ohne den Grad der Wichtigkeit angeben zu können. Die WITIG-Methode operationalisiert „Wichtigkeit", macht sie zum Gegenstand der Diskussion zwischen den Beteiligten und damit kollektiv tragbar. Eine Wichtigkeit der Informationssysteme gibt es nicht; es gibt nur die Wichtigkeit der betrieblichen Aufgaben bzw. Geschäftsprozesse (Aktivitäten und Funktionen), die unterstützt werden.

WITIG - Eine Methode zur Evaluation von Informationssystemen

105

Es ist schwierig, Projektvorschläge für die Wartung bestehender Informationssysteme und für neue Informationssysteme in ihrem Zusammenhang zu beurteilen. Die WITIG-Methode berücksichtigt mit QSF diese Tatsache und zeigt damit, wo mehr Qualität möglich ist. Wartung und Neuentwicklung werden nicht getrennt evaluiert; sie sind für die WITIG-Methode nicht wesentlich verschieden. Wenn Wartungs- und Entwicklungsprojekte getrennt evaluiert werden, gibt es Schwierigkeiten bei der Wartung der Funktionalität. Die in Arbeitsschritt 5 dargestellte Analyse des Istzustands und die sich anschließende Projektplanung vermeiden diese Schwierigkeiten. Methoden der Priorisierung berücksichtigen meist nicht den organisatorischsozialen Kontext für die spätere Verwirklichung, ausgenommen die von [Rock79] und die von [Park88] vorgeschlagenen Methoden. Daher ist nicht gesichert, daß alle Beteiligten (z.B. alle Abteilungsmanager) mit der Priorisierung einverstanden sind. Daraus können Schwierigkeiten bei der Realisierung der Projektvorschläge resultieren. Die WITIG-Methode schafft eine tragbare Basis für die spätere Verwirklichung. Der fehlende organisatorisch-soziale Kontext hat auch zur Folge, daß die Planung von der Realisierung und diese von der Kontrolle getrennt sind. Dies erfordert oft außergewöhnliche Interventionen des Managements, weil sonst der erwartete Nutzen nicht realisiert werden kann. Meistens kümmert sich das Top-Management auch nicht um die Realisierung des Nutzens, nachdem das Projekt freigegeben wurde. Weil die WITIG-Methode die erforderliche organisatorisch-soziale Basis schafft, ist es leichter, den erwarteten Nutzen zu realisieren. Kontrolle durch das Top-Management ist trotzdem erforderlich.

5 Anwendungserfahrungen Es liegen Erfahrungen mit der WITIG-Methode aus 17 Anwendungen vor; sie können wie folgt zusammengefaßt werden: • Das Engagement des Top-Managements und des Linienmanagements ist erforderlich. • Vor einer geplanten Anwendung die bestehende Struktur- und Ablauforganisation in Frage zu stellen, ist nicht zweckmäßig. • Während der Anwendung (insbesondere beim Ermitteln der Aktivitäten und Funktionen) erkannte Reorganisationsvorhaben sollten nicht verwirklicht werden, weil dadurch die Ergebnisse der Methodenanwendung wertlos würden. • Da zum Zeitpunkt der Präsentation der WITIG-Methode meist nicht bekannt ist, wer welche Informationssysteme benutzt, können nicht alle an der Anwendung Beteiligte von Beginn an einbezogen werden. Für die Evaluation von Investitionsvorschlägen zur Anwendung von IuKTechnologien gibt es keine voll befriedigende Methode. Die WITIG-Methode stellt jedenfalls eine Verbesserung der Methodensituation dar.

106

Anton J. van Reeken

Verzeichnis der verwendeten Abkürzungen AFF

=

Aktivitäts-Fokus-Faktor

CSF

=

Critical Success Factor

ESA

=

Einfluß des (Informations)Systems auf die Aktivität

ESU

=

Einfluß des (Informations)Systems auf das Unternehmen

EIA

=

Einfluß aller (Informations)Systeme auf die Aktivität

EIU

=

Einfluß aller (Informations)Systeme auf das Unternehmen

IKT

=

Informations- und Kommunikationstechnologie

QSF

=

Qualität des (Informations)Systems für die Funktion

QSU

=

Qualität des (Informations)Systems für das Unternehmen

WAU =

Wichtigkeit der Aktivität für das Unternehmen

WFA =

Wichtigkeit der Funktion für die Aktivität

WFU =

Wichtigkeit der Funktion für das Unternehmen

WIA

=

(potentielle) Wichtigkeit der IKT für die Aktivität

WIU

=

(potentielle) Wichtigkeit der IKT für das Unternehmen

Literatur [Bede85] Bedell, E. F.: The Computer Solution - Strategies for Success in the Information Age. Homewood/Ill. 1985 [Hein99] Heinrich, L. J.: Informationsmanagement. München/Wien 1999, insbes. Kapitel Strategie-Entwicklung [Park88] Parker, M. M. et al.: Information Economics. Linking Business Performance to Information Technology. Englewood Cliffs/NI 1988 [PoMi85] Porter, M. / Millar, V.: How Information Gives You Competitive Advantage. Harvard Business Review, July/August 1985, 15lp. [Rock79] Rockart, J.: Chief Executives Define Their Own Data Needs. Harvard Business Review, March/April 1979, 81 - 9 2

Geschäfts- und Managementprozesse als Evaluationsobjekt Einführung und Grundlegung Markus Gappmaier [email protected] Marriott S c h o o l o f M a n a g e m e n t / S c h o o l o f A c c o u n t a n c y and Information S y s t e m s Brigham Y o u n g University, Provo/Utah msm.byu.edu/emp/mg/

Inhalt 1 2 3 4 5

Geschäftsprozesse Geschäftsprozeßmanagement Evaluation von Geschäftsprozessen Evaluation durch Methoden des Geschäftsprozeßmanagements Charakteristika der Evaluation von Geschäftsprozessen

Zusammenfassung Die zunehmende Verbreitung der Prozeßorientierung in Wirtschaft und Verwaltung führt zu steigender Bedeutung von Geschäftsprozessen als Evaluationsobjekt. Geschäftsprozeßmanagement unterstützt mit Hilfe der Evaluation der Geschäftsprozesse die Sicherung der Wettbewerbsfähigkeit von Unternehmen 1 . Dieser Beitrag erläutert wesentliche Merkmale von Geschäftsprozessen, ein Stufenmodell des Geschäftsprozeßmanagements (GPM) sowie ein Prozeß-Reifegradmodell. Auf den Stellenwert der Prozeßevaluation bei den Methoden des GPM wird eingegangen. Charakteristika der Evaluation von Geschäftsprozessen werden analysiert.

Abstract Business processes are rising in importance as objects of evaluation as process orientation increasingly implemented in industry and administrative institutions. Business Process Management (BPM) helps organizations to increase their competitiveness by means of the evaluation of the processes which are responsible for the satisfaction of costumer demands. This paper introduces to business processes, depicts a five-step-model of BPM, and proposes a model for the evaluation of process maturity. After presenting an example of the great importance of process evaluation in BPM methods, the paper concludes with an analysis of characteristics of the evaluation of business processes.

'Die Begriffe Unternehmen, Institution und Organisation werden als Synonyma behandelt, da die wesentlichen Inhalte dieses Beitrags auf privatwirtschaftliche und gemeinwirtschaftliche Unternehmen sowie auf Einrichtungen der öffentlichen Verwaltung und auf soziale Institutionen gleichermaßen zutreffen.

108

Markus

Gappmaier

1 Geschäftsprozesse Prozeßorientierung ist ein bedeutendes Organisationskonzept zur Stärkung der Wettbewerbsfähigkeit von Unternehmen. Im Unterschied zur Funktionsorientierung, bei der Unternehmensfunktionen (wie Beschaffung, Produktion und Absatz) Hauptbestandteile der Unternehmensstruktur sind, sind dies bei der Prozeßorientierung die Geschäftsprozesse. Geschäftsprozesse bestehen aus einer Menge logisch miteinander verbundener, meßbarer Tätigkeiten, die für die Schaffung eines spezifischen Ergebnisses für einen bestimmten Kunden oder Markt durchgeführt werden und die für den Unternehmenserfolg von wesentlicher Bedeutung sind (vgl. [HeRo,233f.]). Ein Geschäftsprozeß ist ein Mensch/Aufgabe/Technik-System (kurz: M/A/T-System, vgl. [Hein93,13f.]); für den Prozeßerfolg sind die drei Systemkomponenten gleichermaßen erforderlich. Geschäftsprozesse, die direkt der Erreichung der Unternehmensziele dienen und die Nutzung unternehmensspezifischer Kompetenzen erfordern, werden als Kern-Geschäftsprozesse bezeichnet. Geschäftsprozesse, die Leistungen erbringen, die ohne den Verlust von Wettbewerbsfähigkeit auch zugekauft werden können, werden Unterstützungsprozesse genannt. Geschäftsprozesse mit sich wiederholenden Aktivitäten von Führungskräften und deren Ergebnissen werden als Managementprozesse bezeichnet. Managementprozesse können wie Kern- und Unterstützungsprozesse definiert, geführt und verbessert werden. Ein typischer Kern-Geschäftsprozeß ist die Auftragsfertigung. Ein typischer Unterstützungsprozeß eines Auftragsfertigers ist die Personalbeschaffung. Ein Managementprozeß zeichnet sich durch einen hohen Anteil an Planungsarbeit aus (vgl. [Lega94,78]), die einen starken Einfluß auf die Qualität und Excellence des Unternehmens hat. Aufgabenerledigung, die mit Fachwissen verbunden ist, die durch jeweils unterschiedliches Vorgehen erfolgt und in unregelmäßigen Abständen zur Unterstützung der Kern-Geschäftsprozesse und Unterstützungsprozesse benötigt wird, kann durch interne oder externe Servicezentren erfolgen; interne Servicezentren werden auch funktionale Schulen genannt (vgl. [OsFr98]). Auf dem Weg von der Funktionsorientierung zur Prozeßorientierung müssen die Geschäftsprozesse identifiziert und den genannten Prozeßtypen zugeordnet werden. Die Identifikation der Kern-Geschäftsprozesse kann durch Beantwortung folgender Fragen erreicht werden: • Welchen klar abgrenzbaren Nutzen erwarten die Kunden regelmäßig vom Unternehmen wirklich? • Wann findet der erste Kundenkontakt statt, der zur Nutzenstiftung führt? • Welche Aktivitäten müssen zwischen Nutzenstiftung und erstem Kundenkontakt durchgeführt werden?

Geschäfts- und Managementprozesse

als Evaluationsobjekt

109

Unterstützungsprozesse werden ähnlich ermittelt. Ausgangspunkt der Identifikation ist der Nutzen interner Kunden. (Zur Identifikation von Managementprozesen vgl. den Beitrag „Evaluation von Managementprozessen"). Abhängig vom einzelnen Geschäftsprozeß kann dessen Know-how schwerpunktmäßig entweder in einer einzelnen Systemkomponente verankert sein, also im Ablauf der Leistungserstellung, in der eingesetzten Technologie oder im Personal (z.B. bei kreativer Leistungserstellung durch Fachkräfte) oder ausgewogen auf alle Systemkomponenten verteilt sein (z.B. bei der Sachbearbeitung). Bedarfe und Möglichkeiten der Evaluation werden von der Verteilung des Know-how auf die Systemkomponenten des M/A/TSystems Geschäftsprozeß beeinflußt.

2 Geschäftsprozeßmanagement Tätigkeiten der Geschäftsprozesse werden mit einer bestimmten Regelmäßigkeit durchgeführt, wofür eine oder mehrere typische Formen der Erledigung angewendet werden. Aufgrund dieser Regelmäßigkeit und wegen der Bedeutung der Geschäftsprozesse für den Unternehmenserfolg ist ein institutionalisiertes Geschäftsprozeßmanagement (GPM) im Unternehmen erforderlich. Geschäftsprozeßmanagement ist Planung, Überwachung und Steuerung von Geschäftsprozessen (vgl. [GaHe98]). Die Aufgaben des Geschäftsprozeßmanagements beginnen mit dem die Geschäftsprozesse auslösenden internen oder externen Kundenkontakt und betreffen die Aktivitäten der Leistungserstellung über alle zu durchlaufenden Funktionsbereiche und Instanzen bis zum erbrachten Kundennutzen und der damit verbundenen Nachbearbeitung. Geschäftsprozeßmanagement umfaßt Aufgaben mit Projektcharakter, die im allgemeinen zu einer grundlegenden Veränderung der Geschäftsprozesse führen, und Aufgaben mit dauerhaftem Charakter. Dazu gehören Prozeßführung, Prozeßsteuerung/-unterstützung und kontinuierliche Verbesserung der Geschäftsprozesse. Kontinuierliche Verbesserung ist nicht notwendigerweise mit einer Veränderung der Technologieunterstützung verbunden. Die mit einem GPM-Projekt verfolgte grundlegende Veränderung ist ohne Veränderung der Technologieunterstützung aber nicht möglich. GPM kann durch ein Stufenmodell beschrieben werden, das den Weg zu einer kontinuierlichen Prozeßverbesserung aufzeigt; es verwendet nach [Klei94] folgende Stufen (vgl. auch Abbildung 1): Stufe 1 Prozeßverantwortung: Für jeden Prozeß wird ein Prozeßverantwortlicher bestimmt. Es ist seine Aufgabe, Prozeßorientierung zu fördern, den Prozeß zu beschreiben, zu messen, zu steuern und ihn fortlaufend zu verbessern. Um diesen Aufgaben gerecht zu werden, muß er die Kompetenz besitzen, um die nötigen Maßnahmen ergreifen zu können. Stufe 2 Prozeßbeschreibung: Der Prozeßverantwortliche dokumentiert den Prozeß mit Hilfe von Kriterien wie Input, Output, Tätigkeiten, Ablauf,

110

Markus

Gappmaier

Prozeßgrenzen und Schnittstellen sowie Kundenvereinbarungen und Zulieferanforderungen. Stufe 3 Prozeßmessung: Die Übereinstimmung des Prozeßzustands mit den Anforderungen an den Prozeß wird nur dann sichtbar und nachvollziehbar, wenn er gemessen wird. Messen ist auch Voraussetzung dafür, einen Prozeß beherrschen, steuern und schließlich verbessern zu können. Meßobjekte im Prozeß sind der Input, der Output und der Ablauf des Prozesses. Stufe 4 Prozeßbeherrschung: Der Prozeß wird mit Hilfe von Meßparametern dauerhaft beobachtet, so daß • die Kundenanforderungen permanent erreicht werden, • es keine signifikanten Prozeßabweichungen gibt, • die Identifizierung von möglichen Prozeßschwankungen erfolgt, bevor Fehler entstehen und • die Konsistenz des Inputs gegeben ist. Als notwendig erkannte Korrekturmaßnahmen zielen sowohl auf den Entstehungsprozeß als auch auf die Produkt-/Dienstleistungsschwächen ab. Stufe 5 Prozeßverbesserung: Der Prozeß wird auf das nächsthöhere Qualitätsniveau gebracht, immer mit dem Ziel vor Augen, einen fehlerfreien

Abb. 1 : Elemente der Prozeßbeschreibung (nach [Klei94])

Da auf Stufe 5 das erneute Beschreiben des Prozesses und die Adaptierung des Meßsystems zum Zweck der Prozeßbeherrschung folgt, schließt das Stufenmodell kontinuierliche Verbesserung ein. Verschiedene Geschäftsprozesse eines Unternehmens können sich auf unterschiedlichen Stufen befinden. Es kann vorkommen, daß ein Geschäftsprozeß bereits in beschriebener Form vorliegt, aber noch nicht gemessen wurde. Ein anderer Geschäftsprozeß kann sich auf der Stufe Beherrschung befinden, jedoch noch nicht verbessert worden sein. Folglich kann für jeden Geschäftsprozeß das Vorgehen in einem GPM-Projekt unterschiedlich sein.

Geschäfts- und Managementprozesse

als Evaluationsobjekt

III

3 Evaluation von Geschäftsprozessen Abhängig davon, welche Stufen ein Geschäftsprozeß bereits durchlaufen hat, kann ihm ein Reifegrad zugeordnet werden. Durch Kategorisierung in Reifegrade können Geschäftsprozesse miteinander verglichen und Ziele für Prozeßverbesserung gesetzt werden. • Kategorie 5: Geschäftsprozesse dieser Kategorie laufen ab und liefern Ergebnisse, sind aber noch nicht beschrieben. Die Prozeßverantwortung ist nicht eindeutig geklärt. Dies ist die typische Ausgangssituation in einem Unternehmen vor Einführung des Geschäftsprozeßmanagements. • Kategorie 4: Geschäftsprozesse dieser Kategorie liegen in definierter, beschriebener Form vor; die Prozeßverantwortung ist festgelegt. Die Kundenanforderungen sind definiert, den Lieferanten sind die Prozeßanforderungen bekannt, und es besteht ein Meßsystem für Input, Output und wichtige Prozeßeigenschaften. • Kategorie 3: Geschäftsprozesse dieser Kategorie sind beherrschte Prozesse, deren Output konstant den Kundenanforderungen entspricht, deren Lieferanten konstant den erforderlichen Input bringen und die innerhalb vorgegebener Grenzen ablaufen. • Kategorie 2: Geschäftsprozesse dieser Kategorie sind verbesserte Prozesse, die sich gegenüber denen der Kategorie 3 durch höhere Prozeßqualität auszeichnen. • Kategorie 1: Geschäftsprozesse dieser Kategorie gleichen unterschiedliche Inputs selbständig aus und richten ihre Aktivitäten automatisch so ein, daß fehlerfreie Produkte und Dienstleistungen erzeugt werden. Durch Anwendung des Stufenmodells kann der Reifegrad eines Geschäftsprozesses erhöht werden. Da Produktivität und Wirtschaftlichkeit von Geschäftsprozessen durch Partizipation gefördert werden können, sollen die von einem Geschäftsprozeß betroffenen Mitarbeiter auf allen Stufen einbezogen werden.

4 Evaluation durch Methoden des Geschäftsprozeßmanagements Zweck der Methoden des Geschäftsprozeßmanagements (GPM-Methoden) ist es, produktive, wirtschaftliche und akzeptierte Geschäftsprozesse zu schaffen, die den Unternehmenszielen entsprechende Outputs liefern; sie können unterschiedliche Schwerpunkte haben, beispielsweise folgende: Radikale Neugestaltung, schrittweise Verbesserung, Automatisierung bzw. Unterstützung durch Informationstechnologien und Referenzmodelle. GPM-Methoden unterstützen auch das Messen von Geschäftsprozessen. Dies wird beispielhaft mit der Methode nach [Dave95] gezeigt (vgl. Tabelle 1, siehe auch [HeBr96]).

112

Markus

Gappmaier

Aktivität

Subaktivität

Identifying Processes for Innovation

Enumerate major processes Determine process boundaries Assess strategic relevance of each process Render high-level judgements of the "health" of each process Select processes for innovation Identifying Change Levers Identify potential technological and human opportunities for change Identify potentially constraining technological and human factors Research opportunities in terms of application to specific processes Determine which constraints will be accepted Assess existing business strategy for process Developing a Process Vision direction Consult with process customers for performance objectives Benchmark for process performance and examples of innovation Formulate process performance objectives Develop specific process attributes Understanding and Improving Existing Describe the current process flow Measure the process in terms of the new Processes process attributes Assess the process in terms of the new process attributes Identify problems with the process or shortcoming of the process Identify short-term improvements in the process Assess current information technology and organisation Designing and Prototyping the New Brainstorming design alternatives Assess feasibility, risk, and benefit of design Process alternatives and select the preferred process design Prototype the new process design Develop a migration strategy Implement new organisational structures and systems Tab. 1 : Vorgehensmodell Process Innovation (nach [Dave95])

Die Methode sieht ein Vorgehen mit fünf Aktivitäten vor. Zuerst werden die für eine Verbesserung relevanten Geschäftsprozesse und danach die Ansatzpunkte zur Neugestaltung dieser Prozesse identifiziert. Anschließend wird durch Überprüfung und Abstimmung mit der Unternehmensstrategie sowie einem überbetrieblichen Prozeßvergleich eine Vision der zu verbessernden Geschäftsprozesse entwickelt. Schließlich werden die Geschäftsprozesse nach einer groben Erhebung des Istzustands und einem Vergleich mit der Vision - entworfen und mit Prototyping auf die Implementierung vorbereitet. Aktivitäten und Subaktivitäten, die einen starken und direkten Bezug zum Messen von Geschäftsprozessen aufweisen, sind in Tabelle 1 durch Fettdruck hervorgehoben.

Geschäfts- und Managementprozesse

als Evaluationsobjekt

113

5 Charakteristika der Evaluation von Geschäftsprozessen Durch zunehmende Prozeßorientierung in Wirtschaft und Verwaltung entwickeln sich Geschäftsprozesse zu einem wichtigen Evaluationsobjekt. Evaluation von Geschäftsprozessen bedeutet, Soll-/Ist-Vergleiche durchzuführen, um Prozeßmängel früher als die Prozeßkunden feststellen und rechtzeitig Korrekturmaßnahmen durchführen zu können. Kontinuierliche Evaluation von Geschäftsprozessen im Rahmen eines dauerhaft eingeführten Geschäftsprozeßmanagements ermöglicht vorausschauendes Nutzen von Verbesserungspotentialen, nicht nur auf Notsituationen reagierendes Verändern von Geschäftsprozessen. Zur Charakterisierung der Evaluation von Geschäftsprozessen aus verschiedenen Blickwickeln tragen folgende Kriterien bei: Ziele der Evaluation; Aufgaben der Evaluation; Ansätze der Evaluation; Hilfsmittel der Evaluation; Akteure der Evaluation; Situationen der Evaluation; zeitliche Kopplung der Evaluation unf für die Evaluation relevante Prozeßbestandteile. 5.1 Ziele der Evaluation Die Evaluation von Geschäftsprozessen dient im wesentlichen drei Zielen: • Vorbereitung von Prozeßverbesserungen, z.B. durch Messen der Produktivität des Geschäftsprozesses (vgl. Stufen 2 und 3 des GPM-Stufenmodells); • Überprüfung des Erfolgs von Verbesserungsmaßnahmen, indem ein Vergleich der Zielerreichung und der Planungsziele eines GPM-Projekts durchgeführt wird, gewöhnlich durch Vergleich der Werte des Ist-Prozesses mit denen des implementierten Soll-Prozesses (neuer Ist-Prozeß); • Aufrechterhaltung eines bestimmten Qualitätsniveaus des Prozesses (vgl. Stufe 4 des GPM-Stufenmodells), z.B. durch einen Soll-/Ist-Vergleich beim Echtbetrieb eines Prozesses. Das Ermitteln von Erfolgskenngrößen (Stufe 2 des GPM-Stufenmodells) ist Voraussetzung für das Erreichen aller drei Evaluationsziele. 5 . 2 Aufgaben der Evaluation Die Evaluation von Geschäftsprozessen umfaßt folgende Aufgaben: • Ermitteln von Erfolgskenngrößen des Geschäftsprozesses, die seine Wirksamkeit und Wirtschaftlichkeit beurteilbar machen; • Festlegen von Meßgrößen für die Erfolgskenngrößen; • Ermitteln und Festlegen von Soll-Werten für die Erfolgskenngrößen (auf der Grundlage von Wirtschaftlichkeitsanalysen, best practices, Benchmarks sowie Anforderungen an Lieferanten bzw. von Kunden); • Ermitteln von Ist-Werten der Erfolgskenngrößen; • Feststellen von Abweichungen zwischen Soll- und Ist-Werten.

J14

Markus

Gappmaier

Beispiele für Erfolgskenngrößen und für Meßgrößen sind die Durchlaufzeit eines Prozesses mit der Meßgröße „Stunden" und die Fehleranzahl des Ergebnisses von Geschäftsprozessen mit der Meßgröße „Fehleranzahl pro Ergebnisanzahl". Je nach eingesetztem Meßverfahren und angewendeter Meßtechnik sind weitere, spezifische Aufgaben zu bearbeiten. 5.3 Evaluationsansätze Folgende Evaluationsansätze können unterschieden werden: • Prozeßevaluation anhand eines Prozeßmodells; • Evaluation eines Geschäftsprozesses. Prozeßmodelle als vereinfachte Abbildungen von Geschäftsprozessen können mit speziellen Werkzeugen, die als BPR-, GPO- oder ProzeßmodellierungsTools (kurz: Modellierungs-Tools) bezeichnet werden, nach bestimmten Kriterien evaluiert werden. Ausgewählte Merkmale von Ist- und Soll-Prozessen wie Durchlaufzeit eines Prozesses, dessen Ressourcenauslastung oder Engpaßanfälligkeit, können im Rahmen einer toolbasierten Simulation evaluiert werden. Der Ansatz der Prozeßevaluation anhand eines Prozeßmodells unterscheidet sich deutlich von der Evaluation realer Geschäftsprozesse, wie sie mit verschiedenen Methoden (z.B. Multimoment-Häufigkeitszählverfahren, vgl. [Hall69]) und Werkzeugen (z.B. SAP im Rahmen automatisierter Betriebsdatenerfassung bei der Abarbeitung von Geschäftsprozessen) durchgeführt werden kann. Beim zuletzt genannten Ansatz sind die Geschäftsprozesse mit ihrer reichen Merkmalsvielfalt während der Prozeßausführung die Evaluationsobjekte. Eine Vermischung der beiden Messansätze erfolgt, wenn nach der Messung von Betriebsdaten des Geschäftsprozesses eine Auswahl dieser Betriebsdaten für die Simulation des Geschäftsprozeßmodells verwendet wird. Die Simulation wird mit Hilfe eines Modellierungs-Tools durchgeführt, es gibt aber auch spezielle Simulations-Tools für diesen Zweck. Die Selektion von Betriebsdaten für die Simulation und damit die Vereinfachung des Prozeßmodells vor der Prozeßsimulation ist häufig technisch bedingt durch die Schnittstellen zur strukturierten Datenübertragung zwischen den Systemen zur Prozeßausführung und den Tools zur Prozeßsimulation. 5 . 4 Hilfsmittel der Evaluation Hilfsmittel für die Evaluation von Geschäftsprozessen sind Methoden und Werkzeuge. Vertreter der Evaluationsmethoden sind Erhebungsmethoden (z.B. Multimoment-Häufigkeitszählverfahren zur Feststellung von Häufigkeiten und Zeitdauern) und Analysemethoden (z.B. Kennzahlensysteme zur Analyse von Prozeßschwachstellen und deren Auswirkungen). Werkzeuge für die Evaluation von Geschäftsprozessen können auch in die Kategorien Erhebungs- und Analysewerkzeuge eingeteilt werden. Sie sind so

Geschäfts-

und Managementprozesse

als Evaluationsobjekt

115

vielfältig wie die Anzahl aussagekräftiger Meßgrößen von Erfolgskenngrößen groß ist. Ein bereits erwähntes Beispiel für Analysewerkzeuge sind Modellierungs-Tools. Sie dienen z.B. der Analyse der Auslastung von Prozeßressourcen. Ein Beispiel für Erhebungswerkzeuge sind Software-Produkte, die durch die automatische Erfassung prozeßbezogener Betriebsdaten die Grundlage für die Evaluation von Geschäftsprozessen schaffen. (In diesem Sinn stellt SAP auch Funktionen eines Erhebungswerkzeugs f ü r Prozeßevaluation zur Verfügung.) Prozeßevaluation mit Hilfe automatisiert erfaßter Betriebsdaten führt zu besseren Ergebnissen als Prozeßevaluation auf der Grundlage von Prozeßdaten, die mit Interviews erhoben oder geschätzt wurden. Meßwerkzeuge arbeiten nur mit einem Ausschnitt der Merkmalsvielfalt von Geschäftsprozessen. Es ist daher wichtig, solche Prozeßmerkmale zu wählen (z.B. solche Erfolgskenngrößen für die Evaluation zu definieren), die den Erfolg von Geschäftsprozessen nachweislich bestimmen, und solche Meßgrößen zu wählen, die zuverlässige Aussagen über die Erfolgskenngrößen ermöglichen. 5.5 Akteure der Evaluation Bei der Evaluation von Geschäftsprozessen können interne und externe Akteure (Evaluatoren) tätig sein. Interne Evaluatoren sind Prozeßverantwortliche, Prozeßcontroller, Prozeßrevisoren und Bearbeiter der Geschäftsprozesse. Externe Evaluatoren sind Berater für GPM-Projekte sowie Auditoren (z.B. im Rahmen von Qualitätsmanagement-Audits). 5.6

Situationen der Evaluation

Die Evaluation von Geschäftsprozessen ist eine Aufgabe des Geschäftsprozeßmanagements, wie die Vielfalt an Evaluationssituationen deutlich macht. Evaluation von Geschäftsprozessen ist vor (Ex-ante-Evaluation), während und nach GPM-Projekten (Ex-post-Evaluation) sowie im Rahmen kontinuierlicher Prozeßverbesserung erforderlich. Ex-ante-Evaluation beinhaltet z.B den Vergleich der Soll- und Ist-Werte von Erfolgskenngrößen eines Gechäftsprozesses. Während eines GPM-Projekts werden z.B. mit Prozeß-Benchmarking best practices ermittelt. Ex-postEvaluation dient der Überprüfung des Projekterfolgs, indem ein Vergleich der Werte des alten Ist-Prozesses mit denen des implementieren Soll-Prozesses, also des neuen Ist-Prozesses, durchgeführt wird. Evaluation im Rahmen kontinuierlicher Prozeßverbesserung bedeutet Monitoring von Geschäftsprozessen mit dem Ziel, Prozeßschwächen und Verbesserungspotentiale (die z.B. durch die Verfügbarkeit neuer Technologien entstehen) festzustellen. Auf dieser Grundlage werden einfach realisierbare und kurzfristig wirksame Maßnahmen zur Prozeßverbesserung durchgeführt.

¡16 Markus Gappmaier

5.7 Zeitliche Kopplung der Evaluation Die Evaluation von Geschäftsprozessen kann in unterschiedlicher zeitlicher Kopplung mit der Ausführung von Geschäftsprozessen stattfinden, und zwar: • vor der Prozeßausführung, z.B. bei der Geschäftsprozeßsimulation mit Hilfe von Modellierungs-Tools mit dem Ziel der Ermittlung potentieller Engpässe in Soll-Prozessen mit geschätzten Prozeßdaten; • während der Prozeßausführung, z.B. durch auomatisierte Betriebsdatenerfassung; • nach der Prozeßausführung, z.B. mit Hilfe qualitativer Werte der Erfolgskenngrößen eines Geschäftsprozesses (z.B. bzgl. der Abstimmung zwischen den beteiligten Aufgabenträgern) oder des Prozeß-Outputs (z.B. die Fehleranzahl eines Produkts oder einer Dienstleistung). In Abhängigkeit von der zeitlichen Kopplung der Evaluation von Geschäftsprozessen mit deren Ausführung können die Methoden und Werkzeuge unterschiedlich zweckmäßig angewendet werden und sind unterschiedliche Bestandteile eines Geschäftsprozesses für die Evaluation verwendbar (vgl. obiges Beispiel der Messung nach der Prozeßausführung). 5.8 Für die Evaluation relevante Prozeßbestandteile Schließlich können - je nach Evaluationskriterium (wie Ziel, Situation oder Ansatz der Evaluation) und Evaluationsansatz - unterschiedliche Prozeßbestandteile zur Evaluation verwendet werden. Dazu gehören der ProzeßInput und der Prozeß-Output (z.B. die Qualität der im Prozeß verarbeiteten materiellen und immateriellen Güter und Dienstleistungen), der ProzeßBearbeiter (z.B. deren Kooperations-, Koordinations- und Kommunikationsfähigkeit), der Bearbeitungsvorgang (z.B. dessen Zeit- und Mengengerüst) sowie die verwendeten Hilfsmittel (z.B. deren Präzision und Fehleranfälligkeit). Literatur [Dave95] Davenport, T. H.: Process Innovation: Reengineering Work through Information T e c h n o l o g y . Boston 1995 [ G a H e 9 8 ] G a p p m a i e r , M . / Heinrich, L. J. (Hrsg.): Geschäftsprozesse mit menschlichem Antlitz: M e t h o d e n des organisationalen Lernens anwenden. Linz 1998 [Hall69] Haller-Wedel, E: Das Multimomentverfahren in Theorie und Praxis. München 1969 [HeBr96] Hess, T. / Brecht L.: State of the Art d e s Business Process Redesign: Darstellung und Vergleich bestehender Methoden. Wiesbaden 1996 [Hein93] Heinrich, L. J.: Wirtschaftsinformatik - Einführung und Grundlegung. München/ Wien 1993 [HeRo98] Heinrich, L. J. / Roithmayr, F.: Wirtschaftsinformatik-Lexikon. München/Wien 1998 [Klei94] Kleinsorge, P.: Geschäftsprozesse. In: Masing, W. (Hrsg.): Handbuch Qualitätsmanagement. M ü n c h e n / W i e n 1994,49 - 64 [Lega94] Legat, D.: Hewlett Packard. Total Quality im Managementprozeß. In Zink, K. J.: Business Excellece durch T Q M . München 1994, 78 - 92 [OsFr98] Osterloh, M. / Frost, J.: Prozeßmanagement als Kernkompetenz - Wie Sie Business Reengineering strategisch nutzen können. Wiesbaden 1998

Methoden und Metriken für die Evaluation von Geschäftsprozessen Thomas Müllner [email protected]

Institut für Wirtschaftsinformatik der Universität Linz www.winie.uni-linz.ac.at

Inhalt 1 2 3 4 5

Problem Geschäftsprozeßmanagement Methoden für die Evaluation von Geschäftsprozessen Metriken für die Evaluation von Geschäftsprozessen Forschungsbedarfe

Zusammenfassung In der Literatur werden zwar viele Methoden und Metriken für die Evaluation von Geschäftsprozessen vorgeschlagen, ihre Eignung wird aber meist nicht ausreichend überprüft. [Haus96,126] beurteilt die Eignung einiger Methoden anhand der Anforderungen an das Rechnungswesen. Es ist jedoch zu bezweifeln, ob dadurch auch die Anforderungen des Geschäftsprozeßmanagements abgedeckt werden. Daher werden im vorliegenden Beitrag zunächst die Anforderungen des Geschäftsprozeßmanagements hergeleitet und gängige Methoden diesen Anforderungen gegenübergestellt. Auf diesem deduktivem Weg wird eine Systematik zur Ermittlung und Beurteilung der Erfüllung von Anforderungen an Methoden und Metriken für die Evaluation Geschäftsprozessen erstellt. Ausgewählte Methoden und Metriken werden vorgestellt, in die Systematik eingeordnet und beurteilt. Daraus werden Forschungsbedarfe abgeleitet.

Abstract In the scientific literature many methods and metrics for the evaluation of business processes are recommended without examining their suitability. An attempt of [Haus96,126] uses demands derived from accounting to evaluate the suitability of evaluation methods for business processes; however, it is questionable whether he thereby covers business process management. This article uses a deductive approach to build a systematic scheme for the generation of requirements for methods for the evaluation of business processes. Selected methods and metrics for business processes are presented, fitted into this scheme, and evaluated. The need for further research is derived.

/18 Thomas Milliner

1 Problem Geschäftsprozeßmanagement wurde in den letzten Jahren - beginnend mit dem Schlagwort „Business Reengineering" [HaCh94] - zu einem auch in der Praxis weit verbreiteten Managementkonzept. In einer Befragung unter 23 mittleren und großen Unternehmen 1 im oberösterreichischen Zentralraum war Geschäftsprozeßmanagement das meistgenannte in Anwendung befindliche Managementkonzept (52% der Befragten). Aus der zunehmenden Verbreitung in der Praxis und der im Einführungsbeitrag dargestellten steigenden Notwendigkeit von Evaluation im Geschäftsprozeßmanagement läßt sich ein steigender Bedarf an Evaluationsmethoden ableiten. In derselben Erhebung wurde daher auch untersucht, ob - und wenn ja welche - Methoden verwendet werden. Das Ergebnis läßt auf einen starken Methodenmangel schließen. Obwohl 78% der Befragten angaben, Zeit, Kosten und Qualität zu messen und zu bewerten, wurden bei weniger als der Hälfte der Unternehmen Methoden zur Messung und Bewertung eingesetzt. Es stellt sich die Frage, wodurch dieser Methodenmangel begründet ist, da in der einschlägigen Literatur Evaluationsmethoden für Geschäftsprozesse angeboten werden. Vielfach wird aber in der Grundlagenliteratur zum Geschäftsprozeßmanagement lediglich die Forderung nach Evaluation der Geschäftsprozesse gestellt, ohne weiter auf Vorgehen oder Methodologie einzugehen (z.B. [Klei94]), so daß für die Praxis der Zugang zu Methoden erschwert wird. Eine andere Erklärung über die Ursache des Methodenmangels ist, daß die angebotenen Methoden den Anforderungen nicht entsprechen und daher keine Verbreitung finden. [Haus96,126f.] kommt zu dem Schluß, daß „bestehende Verfahren noch nicht die für die Prozeßbewertung notwendigen Informationen" liefern. Andere Autoren, wie [Mend95] und [Völk98], die ebenfalls bestehende Methoden im Rahmen des Geschäftsprozeßmanagements vorstellen und neue vorschlagen, machen keine Aussagen über die Eignung. Die Frage der Eignung der Methoden soll hier weiterverfolgt werden, denn neben der Darstellung gängiger prozeßspezifischer Evaluationsmethoden und Metriken für Geschäftsprozesse wird eine Systematik zur Ermittlung und Beurteilung der Erfüllung der Anforderungen vorgestellt.

2 Geschäftsprozeßmanagement Ausgangspunkt dieser Systematik ist eine Definition von Geschäftsprozeßmanagement 2 . Viele Autoren, die zu verwandten Themen wie Geschäftsprozeßeinführung oder -Optimierung publizieren, verzichten auf eine explizite Definition. Explizite Definitionen geben beispielsweise [HeRo98] und

1 9 5 % der befragten Unternehmen gaben einen Jahresumsatz von über A T S 100 Mio (β 7,27 Mio) an, 95% hatten einen Mitarbeiterstand von über 50, 57% von über 250. 2 Erläuterungen zur Definition von Geschäftsprozeß und Geschäftsprozeßmanagement sowie Evaluation von G e s c h ä f t p r o z e s s e n finden sich im Einführungsbeitrag. An dieser Stelle werden nur die für die folgenden Schritte notwendigen Definitionen gegeben.

Methoden und Metriken für die Evaluation von Geschäftsprozessen

119

[Schm97], Egal, ob explizit oder implizit definiert wird, meist werden unter Geschäftsprozeßmanagement - dem allgemeinen Managementbegriff folgend - Planungs-, Steuerungs- und Überwachungstätigkeiten in bezug auf Geschäftsprozesse verstanden; manche Autoren klammern die Planung aus (z.B. [HaFr91]). Die zentralen Begriffe der verwendeten Definition - Planung, Steuerung und Kontrolle - werden wegen ihrer Bedeutung in diesem Kontext wie folgt definiert. Unter Planung wird das Setzen von Zielen und das Festlegen von Maßnahmen zur Erreichung der Ziele verstanden [HeRo98], Die Phasen der Planung sind Zielsetzung, Problemerkenntnis, Alternativensuche, Prognose, Bewertung und Entscheidung [Grol86]. Unter Steuerung werden Maßnahmen verstanden, welche die Einhaltung eines systemextern definierten Zustands durch systemexterne Eingriffe ermöglichen. Kontrolle ist die Beobachtung des tatsächlichen Verhaltens und seine Beurteilung anhand von Verhaltenserwartungen [HeRo98], Auf die übliche Unterscheidung der Kontrolltätigkeiten in Überwachung und Kontrolle anhand des Kriteriums der durchführenden Personen (systemintern oder systemextern) wird verzichtet, weil hier die Tätigkeit relevant ist und nicht die durchführende Person. Für die Strukturierung der abzuleitenden Systematik muß ein zusätzliches Merkmal in die Definition von Geschäftsprozeßmanagement explizit aufgenommen werden, nämlich die Unterscheidung zwischen strategischer, administrativer und operativer Ebene. Die drei Ebenen unterscheiden sich im Geschäftsprozeßmanagement durch Zeitpunkt und -räum, Tragweite und Objekt. • Zeitpunkt und -räum: Strategische Tätigkeiten sind seltener als administrative und operative Tätigkeiten und betreffen größere Zeiträume. • Tragweite: Strategische Tätigkeiten dienen direkt der Überlebenssicherung des Unternehmens, administrative, insbesondere operative Tätigkeiten dienen vor allem der Sicherstellung der Durchführung konkreter Aufträge. • Objekt: Strategische Tätigkeiten haben im Geschäftsprozeßmanagement mit Prozeßtypen zu tun, operative mit Prozeßausprägungen und administrative mit beiden, wobei unter Prozeßtyp die generische Beschreibung des Prozesses und unter Prozeßausprägung die Realisierung (Durchführung, Auftrag) verstanden wird (vgl. [Schm97,l,4]). Geschäftsprozeßmanagement umfaßt also die Planung, Steuerung und Kontrolle von Geschäftsprozessen auf strategischer, administrativer und operativer Ebene. Evaluation wird im Geschäftsprozeßmanagement für unterschiedliche Evaluationsprobleme durchgeführt (vgl. den Einführungsbeitrag). Der für jedes Evaluationsproblem gleiche Evaluationsprozeß ist in Abbildung 1 dargestellt. Der Evaluationsprozeß ist in die drei Phasen Messung, Bewertung und Beurteilung unterteilt. 1. Aus einer Aufgabe des Geschäftsprozeßmanagements ergibt sich ein Evaluationsproblem.

120

Thomas

Milliner

2. Die entsprechenden Eigenschaften von Geschäftsprozessen werden durch Messung auf Skalen abgebildet (z.B. „3"). 3. Diese Zahlen bekommen bei der Bewertung einen kontextabhängigen Wert für den Empfänger (z.B. „gut"). 4. Diese Werte bilden die Grundlage für die Beurteilung, die ein Evaluationsergebnis (z.B. „kein Optimierungspotential") liefert.

Abb. 1 : Der Evaluationsprozeß für Geschäftsprozesse

3 Methoden für die Evaluation von Geschäftsprozessen 3.1 State of the Art Ein Gruppierung der im weitesten Sinn der Evaluation von Geschäftsprozessen zuzurechnenden Methoden kann anhand verschiedener Kriterien vorgenommen werden. [Kuen99] teilt die Methoden nach den Kriterien Blickwinkel (quantitative Aspekte vs. quantitative und qualitative Aspekte) und Sichtweise (Geschäftseinheiten vs. Geschäftsprozesse) ein. [Haus96,82f., 93f.] unterscheidet zwischen „Verfahren zur Basisdatengewinnung" und „Bewertungsverfahren". Letztere unterteilt er in „prozeßspezifische, marktorientierte und generell anwendbare Verfahren". Orientiert man sich am Evaluationsprozeß aus Abbildung 1, kann eine Unterteilung in Meß-, Bewertungs- und Beurteilungsmethoden vorgenommen werden. Manche Methoden - z.B. das Organisationsgesundheitsbild [Gapp99] oder das Prozeßportfolio [Haus96,103f.] - können, je nach Art der Ergebnisverwendung, sowohl als Bewertungs-, als auch als Beurteilungsmethoden eingesetzt werden. Das Organisationsgesundheitsbild stellt darüber hinaus auch eine Meßmethode dar (vgl. Abschnitt 3.1.5).

Methoden und Metriken für die Evaluation von Geschäftsprozessen

121

Untersucht man diese Methodengruppen nach dem Merkmal Prozeßspezifität, d.h. danach, ob die Methode für die Anwendung auf Geschäftsprozesse zugeschnitten ist (vgl. [Haus96,93]), zeigt sich, daß meist nur Bewertungsmethoden Prozeßspezifität aufweisen. Die Erklärung dafür ist, daß für die Messung ausschließlich bewährte Methoden der Sozial- oder Wirtschaftswissenschaften eingesetzt werden (z.B. Interview, Fragebogen, Beobachtung, Laufzettel, Multimomentstudie). Für die Beurteilung werden - wenn überhaupt - nur auswahlunterstützende Methoden wie die Nutzwertanalyse verwendet, da eine Beurteilung ein kreativer Vorgang ist. Im Unterschied zu dieser Anwendung nicht-prozeßspezifischer Methoden für die Messung und Beurteilung ist für die Bewertung nur der Einsatz prozeßspezifischer Methoden sinnvoll. Dies geht sowohl aus der Beurteilung von [Haus96] als auch aus der weiter unten beschriebenen Systematik hervor. Im folgenden werden daher nur Methoden behandelt, die eine hohe Prozeßspezifität aufweisen, also vorwiegend Bewertungsmethoden und Methoden, die als Bewertungsmethoden verwendet werden können. 3.1.1 Prozeßkostenrechnung Die Prozeßkostenrechnung ist - neben Kennzahlensystemen - die am weitesten verbreitete Bewertungsmethode für Geschäftsprozesse, mit der eine ausschließlich kostenorientierte Bewertung erfolgt, ausgehend von einer Kostenstellenrechnung. Durch eine Aufgabenanalyse werden zunächst die ablaufenden Teil- und Hauptprozesse ermittelt, wobei ein Teilprozeß immer in einer Kostenstelle durchgeführt wird und die Gesamtheit aller Teilprozesse die Hauptprozesse ergibt. Es wird zwischen leistungsmengen-induzierten (Imi) Teilprozessen (z.B. „Ware verpacken") und leistungsmengen-neutralen (lmn) Teilprozessen (z.B. „Abteilung leiten") unterschieden. Die Gesamtkosten der einzelnen Kostenstellen werden auf die jeweiligen Teilprozesse - meist nach der Arbeitszeit - und die lmn-Kosten nach demselben Schlüssel auf die lmiTeilprozesse verteilt. Man erhält die Prozeßkosten für jeden Teilprozeß, die dann zu den Hauptprozessen aufgerechnet werden können (vgl. [HoGa94]). Die Nachteile der Prozeßkostenrechnung, die auch zu heftigen Diskussionen in der Fachwelt geführt haben, sind der Vollkostenrechnungscharakter, die mehrfach durchzuführende Kostenverteilung mit Hilfe von Schlüsseln und die Übernahme sämtlicher inhaltlicher Fehler der zugrundeliegenden Kostenstellenrechnung. Dem steht gegenüber, daß es mit der Prozeßkostenrechnung mit relativ geringem Aufwand (weil auf der bestehenden Kostenstellenrechnung aufgesetzt wird) möglich ist, die Größenordnung der Kosten für einen Hauptprozeßdurchlauf zu bestimmen. 3.1.2 Kennzahlensysteme Kennzahlen und Kennzahlensysteme gehören seit langer Zeit zum Instrumentarium der Betriebswirtschaftslehre; so beruht jede Bilanzanalyse auf Kennzahlen, und das Du-Pont-Schema (mit der Spitzenkennzahl Return on

122

Thomas Müllner

Investment - ROI) ist nach [Grol86,33] „wohl das älteste und bekannteste" Steuerungsinstrument. Der Versuch, diese Kennzahlensysteme auf Geschäftsprozesse anzuwenden und etwa den ROI eines Geschäftsprozesses zu ermitteln, muß scheitern, da Umsatz, Gewinn und Kapitaleinsatz nicht auf einzelne Geschäftsprozesse zugerechnet werden können. Vielleicht gelingen solche Versuche für KernGeschäftsprozesse, jedoch sicher nicht für Unterstützungsprozesse. Es wurden daher relativ früh (z.B. bereits 1991 von [HaFr91] und 1992 von [Mela92]) Überlegungen zur Bildung von Kennzahlensystemen für Geschäftsprozesse angestellt, wobei sich drei Herangehensweisen herauskristallisiert haben: • Es wird ein umfassendes Kennzahlensystem vorgegeben, und es bleibt dem Anwender überlassen, die passenden auszuwählen (z.B. [Aich96]). • Es wird ein relativ kleines Kennzahlensystem (Netzwerk oder Hierarchie) vorgegeben, und es wird dem Anwender überlassen, dieses um situationsspezifische Kennzahlen zu ergänzen (z.B. [ScVr94], [Oste95], [Mend95]). • Es werden nur beispielhafte Kennzahlen angegeben und in erster Linie Vorgehensweisen zur Identifikation situationsspezifischer Kennzahlen vorgeschlagen (z.B. [HaFr91], [FrSe94]). Die Kennzahlen, die für die Evaluation von Geschäftsprozessen eingesetzt werden (vgl. auch Abschnitt 4), sind - unabhängig von der Vorgehensweise zur Bestimmung - meist Zeit-, Kosten- und/oder Qualitätskennzahlen, wobei Qualität meist durch die aufgetretenen Fehler im Prozeß gemessen wird. [ScVr94] berücksichtigen explizit auch die Kundenzufriedenheit. Erst neuere Ansätze bieten auch Kennzahlen zur Messung der Mitarbeiterzufriedenheit (vgl. [Hoff98]). 3.13 Balanced Scorecard Die Balanced Scorecard, die 1992 von [KaNo92] vorgestellt wurde, ist eigentlich ein Rahmenkonzept für die Entwicklung eines Kennzahlensystems. Vorgegeben werden vier Sichten auf das Unternehmen, nämlich Finanzsicht, Kundensicht, interne Sicht und Innovationssicht, die durch unternehmensspezifische Ziele und Metriken beschrieben werden müssen. Durch Vorgabe der Sichten soll verhindert werden, daß eine einseitige Betrachtung des Unternehmens erfolgt. Die Balanced Scorecard ist ursprünglich eine bereichsbezogene (und keine prozeßbezogene) Methode, kann jedoch bei entsprechender Gestaltung der vier Sichten (insbesondere der internen Sicht) auch zu einer Bewertungs- oder Beurteilungsmethode für Geschäftsprozesse gemacht werden. 3.1.4 Statistical Process Control (SPC) SPC wurde ursprünglich für die Produktion entwickelt, läßt sich jedoch nicht nur auf Fertigungsprozesse, sondern auch auf Geschäftsprozesse anwenden. SPC sieht vor, daß qualitätsbestimmende Eigenschaften des untersuchten Objekts regelmäßig gemessen und die Meßergebnisse in sogenannte Qualitätsregelkarten eingetragen werden (vergleichbar mit einer Fieberkurve). Eine Qualitätsregelkarte weist obere und untere Warn- und Eingreifgrenzen auf; ein Über- bzw. Unterschreiten dieser Grenzen kann ein sofortiges Eingreifen

Methoden

und Metriken für die Evaluation

von Geschäftsprozessen

123

bewirken. Eine Beurteilung der Prozesse erfolgt durch Analyse des Verlaufs der Kurve (vgl. [HaFr91,204f.]). 3.1.5 Organisationsgesundheitsbild Das Organisationsgesundheitsbild [Gapp99] ist eine relativ neue Methode. Sie baut auf einer in der Psychologie mit Erfolg eingesetzten Methode auf, nämlich dem Persönlichen Gesundheitsbild nach [Merl93]. Die Methode versucht, dem Patienten ein „gesundes Selbst" vor Augen zu führen, um unbewußt den ersten Schritt in diese Richtung zu ermöglichen. Dabei wird mit Assoziationen zu realen Gegenständen - wie verschiedenfarbige und unterschiedlich geformte Kärtchen oder persönliche Gegenstände, die das einmal aufgebaute Gesundheitsbild des Patienten schnell wieder abrufbar machen gearbeitet. Mit dem Organisationsgesundheitsbild werden diese Prinzipien auf Personengruppen angewendet, um beispielsweise kollektive Vorstellungen des „gesunden Prozesses" abzufragen und durch ähnliche Symbole (beschriftete Kärtchen) abrufbar zu machen. Die Evaluation der Prozesse erfolgt durch das Sichtbarmachen des Istzustands und eines Sollzustands. Das Organisationsgesundheitsbild kann auch als Meßmethode verstanden werden, da sämtliche Informationen, die zur Bewertung und Beurteilung herangezogen werden, durch Einsatz der Methode gewonnen werden. Die Wirkungsweise der Methode beruht auf einer Reihe von Annahmen, deren Gültigkeit aufgrund der Neuheit der Methode noch nicht wissenschaftlich untersucht worden ist. Es können daher auch andere Faktoren den Wirkungsgrad der Methode beeinflussen (z.B. gesteigerte Motivation durch Teamarbeit). In mehreren Fallstudien [Gapp99] konnten positive Ergebnisse mit dieser Methode erzielt werden. 3.1.6 Sonstige Methoden In der Literatur finden sich weitere Methoden (z.B. das Kunden/ShareholderValue-Prozeßportfolio von Talwar, das Kunden/Potential-Prozeßportfolio von Harrington, die Marktorientierte Bewertung, alle bei [Haus96] erläutert) oder die von [Schm97] beschriebenen Methoden zur operativen Prozeßplanung. Die Zielsetzung dieser Methoden ist sehr speziell und ihre Anwendung zur Evaluation von Geschäftsprozessen daher sehr begrenzt, so daß auf ihre Darstellung und Beurteilung verzichtet werden kann. 3.2 Anforderungen an die Methoden Die Anforderungen, anhand derer die im Geschäftsprozeßmanagement eingesetzten Bewertungsmethoden beurteilt werden sollen (vgl. Abschnitt 3.3), ergeben sich aus dem in Abbildung 1 dargestellten Evaluationsprozeß für Geschäftsprozesse. Aus dem Zusammenhang zwischen Beurteilung, Bewertung und Messung können - ausgehend vom Evaluationsproblem - zunächst die Anforderungen an die Bewertungsmethoden und in weiterer Folge an die Meßmethoden abgeleitet werden.

124

Thomas

Müllner

Im ersten Schritt werden die Aufgaben des Geschäftsprozeßmanagements entsprechend der Definition in einer Matrix eingeordnet (vgl. Tabelle 1), um anschließend die Evaluationsprobleme festzustellen (vgl. Tabelle 2). Strategisch

Administrativ

Operativ Planung einer Prozeßausprägung

Planung

Planung der Prozeßorganisation Mittelfristige Planung der Prozeßausprägungen (Prozeßtypen und deren Adaptionen der Prozeßtypen Interaktion)

Beispiele

BPR-Projekte, GP-Einfiihrung, GP- Optimierung, Dokumentation der GP

Kurzfristige GP-Optimierung, Mittelfr. Ressourceneinsatzplanung

Ressourceneinsatzplanung

Steuerung

Anpassung der Prozeßorganisation

Anpassungen der mittelfristigen Planungen

Ablaufsteuerung einer Prozeßausprägung

Beispiele

GP- Optimierung, Kaizen

Kurzfristige

Objektsteuerung

Kontrolle

Überwachung der Einhaltung Überwachung der auf Prozeßtypebene gesetzten Ziele der mittelfristigen Planungen

Beispiele

Strategische Abweichungsanalyse, Erfolgskontrolle bei GP-Einfiihrung oder GPOptimierung

Erfolgskontrolle Optimierungen

GP-Optimierung

für GP-

(WfM)

Überwachung der Einhaltung der Durchführung einer Prozeßausprägung Workflow

Management

Tab. 1 : Aufgaben im Geschäftsprozeßmanagement

Aus diesen Aufgaben werden die Evaluationsprobleme abgeleitet, die sich - je nach Aufgabe - in Art und Anzahl unterscheiden. Außerdem werden sie durch charakteristische Merkmale näher beschrieben (siehe Tabelle 2). Aus diesen M e r k m a l e n der Evaluationsprobleme ergeben sich die f o l g e n d e n , anlaßabhängigen Anforderungen an die Bewertungsmethoden: • Bewertungszeitpunkt. Je nach Evaluationsproblem müssen die Bewertungsmethoden für Ex-ante- bzw. Ex-post-Bewertung geeignet sein. • Bewertungszeitraum. Je nach Evaluationsproblem kann eine langfristige, mittelfristige oder kurzfristige Sichtweise bei der Bewertung erforderlich sein. • Objektadäquanz. Je nach Evaluationsproblem müssen entweder prozeßtypbezogene oder prozeßausprägungsbezogene Bewertungen durchgeführt werden können. • Objektumfang. Je nach Evaluationsproblem ist es notwendig, einzelne, mehrere oder das Zusammenwirken aller Prozesse zu beurteilen. • Verwertbarkeit. Die Verwertbarkeit eines Ergebnisses einer Bewertungsmethode ist um so höher, je höher der Grad der Sachzielerfüllung ist. • Wirtschaftlichkeit. Die Wirtschaftlichkeit wird durch das Verhältnis von Aufwand zu Ertrag der Anwendung einer Bewertungsmethode ausgedrückt. Durch den nur schwer meßbaren Ertrag kann eine Beschränkung auf den Aufwand vorgenommen oder Ertrag mit Bedeutung gleichgesetzt werden. Demnach ist für Bewertungen bei strategischen Aufgaben ein höherer Aufwand gerechtfertigt als für operative Bewertungen.

Methoden und Metriken fur die Evaluation von Geschäftsprozessen

125

Neben diesen anlaßabhängigen Anforderungen, die je nach Evaluationsproblem unterschiedlich beurteilt werden, sind folgende methodenabhängige Anforderungen zu berücksichtigen: Aufgaben

Evaluationsprobleme

Merkmale

1

Ist-Zustand beurteilen (Prozeßtyp)

prozeßübergreifend, prozeßtypbezogen, ex-postBetrachtung, Soll/Ist-Vergleich, unternehmenszielbezogen, großer Zeithorizont

2

Soll-Konzepte beurteilen zur Auswahl eines Soll-Konzepts auf Prozeßtyp-Ebene

prozeßübergreifend, prozeßtypbezogen, ex-anteBetrachtung, Vergleichbarkeit, Ganzheitlichkeit, großer Zeithorizont

3

Alternative Soll-Konzepte beurteilen prozeßübergreifend, prozeßtypbezogen, ex-anteBetrachtung, Varianten-Vergleichbarkeit, großer (Variationen aufgrund von Zeithorizont Abweichungen)

4

Op tim i eru η gs po te ntial e identifizieren

prozeßübergreifend, ex-post-Betrachtung, prozeßtypbezogen, Vergleichbarkeit, großer Zeithorizont

Strategische Kontrolle

5

Ist-Zustand beurteilen

prozeßübergreifend, ex-post-Betrachtung, Sollest-Vergleich, prozeßtypbezogen

Administrative Planung

6

Ist-Zustand beurteilen (für mittelfristige Planung)

haupts. prozeßbezogen, prozeßtyp- und ausprägungsbezogen, ex-post-Betrachtung, Soll/Ist-Vergleich, mittlerer Zeithorizont

7

Anpassungen des Ist-Zustands beurteilen

haupts. prozeßbezogen, prozeßtyp- und -ausprägungsbezogen, ex-ante-Betrachtung, mittlerer Zeithorizont

8

Mittelfristige Ressourceneinsatzplanung (Beurteilung der optimalen Prozeßausprägungen)

haupts. prozeßbezogen, prozeßtyp- und -ausprägungsbezogen, ex-ante-Betrachtung, mittlerer Zeithorizont

9

Alternative Optimierungsprojekte beurteilen

haupts. prozeßbezogen, prozeßtyp- und -ausprägungsbezogen, ex-ante-Betrachtung, mittlerer Zeithorizont

10

Mittelfristige Optimierungspotentiale identifizieren

haupts. prozeßbezogen, prozeßtyp- und -ausprägungsbezogen, ex-post-Betrachtung, mittlerer Zeithorizont

Administrative Kontrolle

11

Ist-Zustand mittelfristig beurteilen

haupts. prozeßbezogen, prozeßtyp- und -ausprägungsbezogen, ex-post-Betrachtung, Soll/Ist-Vergleich, mittlerer Zeithorizont

Operative Planung

12

Ressourceneinsatzplanung (Beurteilung der optimalen Prozeßausprägung)

prozeßbezogen, ex-ante-Betachtung, kurzer Zeithorizont, Operational i tat, hohe Wirtschaftlichkeit

Operative Steuerung

13

Optimalen Ressourceneinsatz bei Abweichungen ermitteln

prozeßbezogen, ex-ante-Betrachtung, kurzer Zeithorizont, hohe Wirtschaftlichkeit

Operative Kontrolle

14

Beurteilung der Prozeßausführung

prozeßbezogen, ex-post-Betrachtung, kurzer Zeithorizont, Operationalität, hohe Wirtschaftlichkeit

Strategische Planung

Strategische Steuerung

Administrative Steuerung

Tab. 2: Evaluationsprobleme und -merkmale der Aufgaben

• Aussagekraft. Die Aussagekraft des Bewertungsergebnisses ist um so höher, je geringer der Interpretationsbedarf bei der Beurteilung und somit die Wahrscheinlichkeit eines Interpretationsfehlers ist.

126

Thomas

Müllner

• Flexibilität. Die Flexibilität einer Bewertungsmethode ist um so höher, je einfacher und rascher Änderungen im Bewertungsobjekt bzw. im Umfeld (z.B. Unternehmensziele) berücksichtigt werden können. • Ganzheitlichkeit. Da Geschäftsprozesse auch als ein Konstrukt aus den Komponenten Mensch, Aufgabe und Technik zu verstehen sind (vgl. Einführungsbeitrag), sollten die Bewertungsmethoden auch das Einfließen „weicher Kriterien" zulassen. • Zuverlässigkeit. Die Zuverlässigkeit einer Bewertungsmethode ist um so höher, je öfter die Ergebnisse der Realität entsprechen. 3 3 Beurteilung der Bewertungsmethoden Die Tabellen 3 bis 6 zeigen den vom Autor eingeschätzten Erfüllungsgrad der Anforderungen (++ = sehr gut, + = gut, - = weniger gut, - = schlecht) für die Methoden. Zwar handelt es sich um wohlüberlegte Bewertungen, dennoch steht eine empirische Überprüfung der Einschätzung (z.B. durch Expertenbefragung) aus. Methoden, deren Verwertbarkeit bei einem Bewertungsanlaß als schlecht eingeschätzt wurden, werden für diesen Anlaß nicht weiter bewertet. Für eine Gesamtbewertung der Methoden (etwa mit Hilfe einer Nutzwertanalyse) sollten anforderungsadäquate Skalen sowie eine Gewichtung der Anforderungen eingefühlt werden. ^ N A n l a ß (vgl. Tab 2)

Anforderung

s

Ρ 1

2

3

-

-

0 perath /e

Admini strati ve

Stt ategische

Κ

s

Ρ

4

5

6

7

8

9

10

Κ

Ρ

S

Κ

11

12

13

14

Bewertungszeitpunkt

++

++

++

++

-

-

++

++

++

Bewertungszeitraum

+

-

-

+

+

++

+

-

++

++

++

Objektadäquanz

++

++

++

++

++

+

+

+

+

+

++

Objektumfang

++

++

++

++

++

+

+

+

++

+

Verwertbarkeit

+

-

+

++

+

+

-

+

+

++

Wirtschaftlichkeit

+

+

+

+

+

++

+

-

++

++

Aussagekraft Flexibilität Ganzheitlichkeit Zuverlässigkeit

-

++ -

-

+ ++

+ -

--

Tab. 3: Prozeßkostenrechnung

Die Prozeßkostenrechnung kann, wie aus Tabelle 3 ablesbar, in erster Linie bei Kontrollaufgaben und Ex-post-Bewertungen eingesetzt werden. Nachteile sind die mangelnde Ganzheitlichkeit durch Beschränkung auf Kostenaspekte und die mangelnde Zuverlässigkeit durch die oftmalige Schlüsselung. Die sehr gute Bewertung der Kennzahlensysteme (Tabelle 4) resultiert aus ihrer großen Flexibilität und Gestaltungsfreiheit. Das heißt, daß die Methode bei entsprechender Gestaltung die Möglichkeit bietet, für jede Anforderung

Methoden

und Metriken für die Evaluation

von Geschäftsprozessen

Ì27

eine sehr gute Bewertung zu erreichen. Für die Balanced Scorecard gilt dies ebenfalls, da sie - wie oben beschrieben - nur das Rahmenwerk für ein Kennzahlensystem darstellt und daher fast die gleiche Flexibilität und Gestaltungsfreiheit aufweist. ^ N A n l a ß (vgl. Tab 2)

Anforderung

Sil ategische

\

Ρ 1

Admini strative

S 2

Κ 4

3

5

Ρ 6

0 peratii /e

S

7

8

9

10

Κ

Ρ

S

Κ

11

12

13

14

Bewertungszeitpunkt

++

++

++

++

++

++

++

++

++

++

++

++

++

++

Bewertungszeitraum

++

++

++

++

++

++

++

++

++

++

++

++

++

++

Objektadäquanz

++

++

++

++

++

++

++

++

++

++

++

++

++

++

Objektumfang

++

++

++

++

++

++

++

++

++

++

++

++

++

++

Verwertbarkeit

++

++

++

++

++

++

++

++

++

++

++

++

++

++

Wirtschaftlichkeit

+

+

+

+

+

+

+

+

+

+

+

+

+

+

Aussagekraft

++

Flexibilität

++

Ganzheitlichkeit

++ ++

Zuverlässigkeit

Tab. 4: Kennzahlensysteme/Balanced Scorecard

V>

Strategische

N A n l a ß (vgl. T a b 2)

Anforderung

x

Ρ

s

1

Administrative

S 2

3

Κ

Operative

Ρ

4

5

6

7

g

9

Κ

Ρ

S

Κ

10

11

12

13

14

Bewertungszeitpunkt

++

++

++

++

--

+

++

+

Bewertungszeitraum

++

++

++

++

-

+

++

+

Objektadäquanz

++

+

++

++

+

++

++

+

Objektumfang

+

+

+

+

+

++

++

++

++

++

++

+

++

++

++

++

++

++

++

++

Verwertbarkeit

+

Wirtschaftlichkeit

++

Aussagekraft

-

--

--

-

-

--

++ ++

++

Flexibilität

+

Ganzheitlichkeit

+

Zuverlässigkeil

+

Tab. 5: Statistical Process Control

Aus dieser Bewertung kann abgeleitet werden, daß Statistical Process Control eine sehr geeignete Methode zur Ex-post-Evaluation von Geschäftsprozessen ist. Einschränkend muß angemerkt werden, daß die Eignung - wie bei den

128

Thomas Müllner

Kennzahlensystemen - von der konkreten Gestaltung (in diesem Fall von der Auswahl der beobachteten Größen) stark beeinflußt wird. Vs

St ategische

s A n l a ß (vgl. T a b 2)

Anforderung

s

Ρ 1

2

3

o peratp /e

Admini strative

Κ 4

5

S

κ

Ρ

s

Κ

9

10

11

12

13

14

Ρ 6

7

8

Bewertungszeitpunkt

++

++

++

++

++

+

-

++

++

++

+

Bewertungszeitraum

++

++

++

++

++

+

+

+

+

+

-

Objektadäquanz

++

++

++

++

++

+

+

+

+

+

-

Objektumfang

++

++

++

++

++

++

++

++

++

++

+

Verwertbarkeit

++

+

+

++

++

+

+

Wirtschaftlichkeit

++

++

++

++

++

+

+

Aussagekraft

-

+

+

+

+

+

+

-

-

-

--

Flexibilität

++

Ganzheitlichkeit

++

Zuverlässigkeit

+

Tab. 6: Organisationsgesundheitsbild

Das Organisationsgesundheitsbild kann, wie aus Tabelle 6 abzulesen ist, als sehr gute Bewertungsmethode bezeichnet werden. Hier muß allerdings einschränkend bemerkt werden, daß diese Methode hohe Anforderungen an die Durchführenden stellt, ein sehr hoher Interpretationsbedarf des Ergebnisses besteht und - wie bereits erwähnt - wissenschaftlich nicht ausreichend untersucht ist.

4 Metriken für die Evaluation von Geschäftsprozessen Den nächsten Schritt nach der Beurteilung der Bewertungsmethoden bildet die Ableitung und die Beurteilung der Erfüllung der Anforderungen an die Meßmethoden. Wegen der fehlenden Prozeßspezifität für Meßmethoden (vgl. Abschnitt 3.1) wird nicht auf Meßmethoden, sondern auf Metriken eingegangen. Nach [HeRo98] ist in diesem Zusammenhang eine Metrik eine Eigenschaft eines Geschäftsprozesses, die mit geeigneten Meßmethoden gemessen werden kann, d.h. durch Hinzunahme von Prozeßeigenschaften auf dieser Ebene entsteht wiederum Prozeßspezifität. 4.1 State of the Art Im folgenden werden gängige Metriken bzw. Metrikgruppen für Geschäftsprozesse kurz erläutert, anschließend werden (wie schon in Abschnitt 3.2) die Anforderungen an sie abgeleitet; eine exemplarische Beurteilung wird vorgenommen.

Methoden und Metriken für die Evaluation von Geschäftsprozessen

129

Zeit: Zeitgrößen wie Durchlaufzeit, Bearbeitungszeit, Liegezeit usw. sind in der Literatur und in der Praxis die am häufigsten verwendeten Metriken für Geschäftsprozesse. So gaben 78% der Unternehmen in der eingangs erwähnten Untersuchung an, Zeit als Steuerungsgröße für Geschäftsprozesse zu verwenden. Sowohl die Messung als auch die Bewertung werden durch eine Reihe von Methoden unterstützt. Zeitgrößen sind außerdem in GPMWerkzeugen die primäre Größe für Simulationen. Kosten: Kosten für Geschäftsprozesse werden zwar ebenfalls von 78% der befragten Unternehmen als Steuerungsgröße herangezogen, jedoch ist die methodische Unterstützung seitens der Theorie und seitens der Werkzeuge eher unzureichend (mit Ausnahme der Prozeßkostenrechnung), da meist nur die benötigte Zeit mit einem Stundensatz multipliziert wird. Daraus läßt sich ein großer Praxisbedarf nach Methoden und Werkzeugen zur Erhebung der realen Prozeßkosten ableiten Qualität: Qualität im Sinne der einschlägigen Normen ist die realisierte Beschaffenheit bzgl. der Qualitätsforderungen [HeRo98]. Die Qualität eines Geschäftsprozesses wird daher meist durch die Anzahl und Art der aufgetretenen Fehler oder Reklamationen gemessen (z.B. [Mend95], [HaFr91]). Mitarbeiter- und Kundenzufriedenheit: Kundenzufriedenheit (bezogen auf externe Kunden) als Metrik für Geschäftsprozesse wurde bereits von [ScVr94] gefordert und durch die „marktorientierte Bewertung" der Prozesse von [Haus96] fokussiert. Manche Autoren (z.B. [Öste95]) verstehen Kundenzufriedenheit auch als Qualitätsmerkmal. Trotz der theoretischen Forderung der Bewertung der Zufriedenheit der Kunden findet diese Metrik in der Praxis nur langsam Verbreitung (nur 52% der befragten Unternehmen geben Kundenzufriedenheit als eine Steuerungsgröße an). Mitarbeiterzufriedenheit (interne Kunden) findet in der Praxis nur in 17% als Steuerungsgröße Verwendung, und auch in der Theorie werden erst in jüngerer Zeit entsprechende Konzepte berücksichtigt (z.B. [Hoff98], [Gapp97]). Sonstige Metriken: Überlegungen zu den Metriken Zeit, Kosten und Qualität finden sich bei [ScVr94] und [Mend95]. Weitere Metriken wie Flexibilität, Know-how und viele andere sind prozeßspezifisch. Anregungen für prozeßspezifische Kennzahlen geben [Aich96] und [Mend95], (Beispiele finden sich auch im Beitrag „Entwicklung von Erfolgskenngrößen für Geschäftsprozesse".) 4.2 Anforderungen an Metriken Die folgenden Anforderungen an Metriken werden aus den in Tabelle 3 genannten Evaluationsproblemen abgeleitet. • Zeitpunkt: Je nach Bewertungsmethode und Evaluationsproblem müssen die Metriken für ex-ante- bzw. ex-post Messungen der Objekte geeignet sein.

130 Thomas Müllner

• Zeitraum: Je nach Bewertungsmethode und Evaluationsproblem kann eine langfristige, mittelfristige und kurzfristige Sichtweise bei der Messung erforderlich sein. • Objektadäquanz: Je nach Bewertungsmethode und Evaluationsproblem müssen entweder prozeßtypbezogene oder prozeßausprägungsbezogene Messungen durchgeführt werden können. • Verwertbarkeit: Die Verwertbarkeit einer Metrik ist um so größer, j e präziser gemessen werden kann; damit steigt der Grad der Sachzielerfüllung der Bewertungsmethode. • Wirtschaftlichkeit: Die Wirtschaftlichkeit einer Metrik wird mangels meßbarem Ertrag durch den Meßaufwand ausgedrückt. Zu einer umfassenden Beurteilung müssen weitere, und zwar methodenspezifische Anforderungen berücksichtigt werden, die z.B. für Kennzahlensysteme von [FrSe94] formuliert wurden (z.B. Präzision, Sensitivität): 4 3 Beurteilung der Metriken Tabelle 7 zeigt exemplarisch den Erfüllungsgrad der Anforderungen für die Metrikgruppe Kosten. Da die Bewertung von der Art der Implementierung der Metriken abhängig ist, sollte der Leser für diese und für die anderen Metrikgruppen für die konkrete Implementierung eine Bewertung vornehmen. Die sehr positive Bewertung beruht auf der Annahme, daß die Kosten exakt gemessen werden. Trifft diese Annahme zu, sind Kostenmetriken insbesondere für Ex-post-Evaluationen - eine sehr gute Grundlage für Prozeßbewertungen. >v

X A n l a ß (vgl. T a b 2)

Anforderung

Κ

Ρ

S

Κ

2

3

4

5

6

7

8

9

10

11

12

13

14

++

++

++

-

-

+

++

++

-

-

++

++

+

+

+

+

+

+

+

+

Ρ 1

o peratiì /e

Admini strati ve

Stt ategische

Κ

S

Zeitpunkt

++

-

-

Zeitraum

++

-

-

++

Ρ

+

S

Objektadäquanz

+

+

+

++

+

+

+

+

+

+

+

+

+

+

Verwertbarkeit

+

+

+

++

+

+

+

+

++

++

++

-

-

+

Wirtschaftlichkeit

+

+

+

+

+

+

+

+

++

+

+

-

-

+

Tab. 7: Kostenmetriken

5 Forschungsbedarfe Die dargestellte Systematik ermöglicht die Ermittlung und Beurteilung der Erfüllung der Anforderungen an Methoden und Metriken im Geschäftsprozeßmanagement. Im Unterschied zu anderen Beurteilungsverfahren geht sie von einer Definition des Begriffes Geschäftsprozeßmanagement aus und ist keine Adaption von Beurteilungsverfahren anderer Managementkonzepte.

Methoden

und Metriken für die Evaluation

von Geschäftsprozessen

131

Für eine einfache Verwendbarkeit der Untersuchungsergebnisse sollten die Bewertungsergebnisse je Methode zu einem Gesamtbefund aggregiert und die Beurteilung der Methoden durch eine empirische Untersuchung (z.B. eine Expertenbefragung) überprüft werden. Unabhängig davon können aus der Beurteilung einiger Methoden und Metriken konkrete Forschungsbedarfe abgeleitet werden. Auf Grundlage der Befunde, über in diesem Beitrag berichtet wurde, kann die eingangs geäußerte These über die mangelnde Eignung der Methoden als Ursache für die unzureichende Methodenverwendung in der Praxis nicht bestätigt werden. Mögliche Ursachen für die unzureichende Methodenverwendung in der Praxis sind: • die Methoden sind nur unzureichend für eine Ex-ante-Evaluation geeignet; • die Schwächen der Methoden können deren Stärken nicht ausgleichen; • die Stärken der Methoden (z.B. der Kennzahlensysteme) können nur mit erheblichem Aufwand bei der Einführung oder bei der Anwendung realisiert werden; • jede Methode hat bei einigen Kriterien Schwächen, und es ist keine Methode verfügbar, die alle Anforderungen erfüllen kann; • die Methoden liefern unter Fallstudien- oder Laborbedingungen gute Ergebnisse, im praktischen Einsatz aber nicht. Daraus werden folgende Forschungsbedarfe abgeleitet: • Entwicklung eines allgemein anwendbaren Kennzahlensystems. Aufgrund der hohen Eignung von Kennzahlensystemen sollten Kennzahlensysteme entwickelt werden, die ohne großen Aufwand angepaßt und eingeführt werden können. • Weiterentwicklung und Zusammenführung. Methoden wie die Prozeßkostenrechnung und das Organisationsgesundheitsbild sollten weiterentwickelt werden, um - zusammen mit Kennzahlensystemen - zu einer Methodologie kombiniert werden zu können, die der geforderten Ganzheitlichkeit im Geschäftsprozeßmanagement gerecht wird. • Untersuchung der Einsatzfähigkeit in der Praxis. Es sollte untersucht werden, inwieweit die in der Praxis herrschenden Bedingungen (z.B. Einschränkungen bei den zur Verfügung stehenden Meßmethoden, der erreichbaren Meßgenauigkeit oder Meßhäufigkeit) den Einsatz der Methoden verhindern. In weiterer Folge können die Bedingungen beschrieben werden, unter denen ein effektiver und effizienter Methodeneinsatz gewährleistet ist. • Eignung zur Ex-ante-Evaluation. Methodenentwicklung und Weiterentwicklung von Methoden sollten auf die Notwendigkeit der Ex-ante-Evaluation Rücksicht nehmen.

I32

Thomas

Müllner

Literatur [Aich96] Aichele, C.: Kennzahlenbasierte Geschäftsprozeßanalyse. Wiesbaden 1997 [FrSe94] Fries, S. / Seghezzi, H. D.: Entwicklung von Meßgrößen für Geschäftsprozesse. In: Controlling 6/1994, 338 - 345 [Gapp99] Gappmaier, M. et al.: Das Organisationsgesundheitsbild. Institutsbericht 99.02 des Instituts für Wirtschaftsinformatik/Information Engineering der Universität Linz, Linz 1999 [Gapp97] Gappmaier, M.: Process Prototyping - A Methodology for Participatory Business Process Design. In: Hofer, S. / Doucek, P. (Hrsg.): I D I M T ' 9 7 - 5th Interdiciplinary Information Management Talks. München/Wien 1997 [Grol86] Groll, Κ.: Erfolgssicherung durch Kennzahlensysteme. Freiburg 1986 [HaCh94] Hammer, M. / Champy, J.: Business Reengineering. Die Radikalkur für das Unternehmen. Frankfurt/New York 1994 [HaFr91] Haist, F. / Fromm, H.: Qualität im Unternehmen: Prinzipien - Methoden Techniken. München/Wien 1991 [Haus96] Hauser, C.: Marktorientierte Bewertung von Untemehmensprozessen. Köln 1996 [HeRo98] Heinrich, L. J. / Roithmayr, F.: Wirtschafsinformatik-Lexikon. München/Wien 1998 [HoGa94] Horváth, P. / Gaiser, P.: Aufgaben und Einsatz der Prozeßkostenrechnung. In: Seicht, G. (Hrsg.): Jahrbuch für Controlling und Rechnungwesen. Wien 1994,49 - 63 [Hoff98] Hoffman, M. et al.: Erhebung von Geschäftsprozessen bei der Einführung von Workflow Management. In: Herrmann, T. et al. (Hrsg.) Verbesserung von Geschäftsprozessen mit flexiblen Workflow-Management-Systemen 1. Heidelberg 1998, 15 - 72 [KaNo92] Kaplan, R. / Norton, D.: The Balanced Scorecard - Measures That Drive Performance. In: Harvard Business Review 1/1992, 71 - 7 9 [Klei94] Kleinsorge, P.: Geschäftsprozesse. In: Masing, W . (Hrsg.): H a n d b u c h Qualitätsmanagement. München/Wien 1994, 4 9 - 6 4 [Kuen99] Kueng, P.: Process Performance Measurement System: a tool to support processbased organizations. Unveröffentlichtes Manuskript vom 26. 7. 1999. Erscheint in: Total Quality Management 1/2000 [Mela92] Melan, E. H.: Process Management. Methods for Improving and Service. New York et al. 1992 [Mend95] Mende, M.: Ein Führungssystem für Geschäftsprozesse. Bamberg 1995 [Merl93] Merl, H.: Das Gesundheitsbild - ein (neues?) Psychotherapeutikum. In: Praxis der Psychotherapie und Psychosomatik. Zeitschrift f ü r Fort- und Weiterbildung. Linz 1993,310-322 [Öste95] Osterie, H.: Business Engineering. Prozeß- und Systementwicklung, Band 1. Berlin et al. 1995 [Schm97] Schmidt, G.: Prozeßmanagement: Modelle und Methoden. Berlin et al. 1997 [ScVr94] Scholz, R. / Vrohling, Α.: Prozeß-Leistungs-Transparenz. In: Gaitanides, M.: Prozeßmanagement: Konzepte, Umsetzungen und Erfahrungen des Reengineering. München/Wien 1994, 5 7 - 9 8 [Völk98] Völkner, P.: Modellbasierte Planung von Geschäftsprozeßabläufen: Entwicklung eines E n d s c h e i d u n g s u n t e r s t ü t z u n g s s y s t e m s auf Grundlage objektorientierter Simulation. Wiesbaden 1998

Entwicklung von Erfolgskenngrößen für Geschäftsprozesse Alfred Gerstmayr [email protected]

Steyr-Daimler-Puch AG Antriebstechnik, Steyr www.sat.steyr.com

Inhalt 1 2 3 4

Das Unternehmen SAT Geschäftsprozeßmanagement-Projekt Projektphasen Resümee

Zusammenfassung Im Rahmen eines Geschäftsprozeßmanagement-Projekts bei der Steyr-Daimler-Puch AG Antriebstechnik (SAT) wurden Erfolgskenngrößen entwickelt. In einer Start- und Orientierungsphase wurden die Hauptgeschäftsprozesse identifiziert und zugehörige Erfolgskenngrößen definiert. Anschließend wurde der Istzustand erhoben und in Prozeßform dargestellt. Arbeitsschwerpunkt waren die Analyse von Subprozessen, deren Erfolgskenngrößen und die Bewertung der Subprozesse. In der Konzeptphase wurden ideale Prozeßabläufe und deren Merkmale identifiziert. Die Merkmale wurden hinsichtlich ihrer Wirkung auf die Ausprägungen der Erfolgskenngrößen untersucht. Von dieser Bewertung ausgehend wurden machbare Sollversionen entwickelt. In der Realisierungsphase wurden kurzfristig realisierbare Maßnahmen umgesetzt und längerfristige Maßnahmen zu Projekten zusammengefaßt, die an die zuständigen Steuerungsgremien übergeben wurden.

Abstract Success factors were developed within the scope of a business process management project in the Steyr-Daimler-Puch AG Antriebstechnik (SAT). At the beginning, core business processes and their success factors were defined. Afterwards the present status of the processes was examined and modeled in a process form. The tasks in this phase were the analysis of subprocesses and their success factors and the evaluation of the subprocesses. In the concept phase ideal process flows and relevant attributes were identified. Those attributes were evaluated concerning their effects on the success factors. This was taken as a starting point for the development of feasible target processes. In the final phase, short-term measures were realised and longer-term measures organised as projects and handed over to the responsible control committees.

¡34 Alfred Gerstmayr

1 Das Unternehmen SAT Die Steyr-Antriebstechnik (SAT) ist eine Geschäftseinheit der SteyrDaimler-Puch AG, a Company of Magna, in der das Know-How auf den Gebieten der Getriebe-, Antriebs- und Nutzfahrzeugtechnik zusammengefaßt wurde. Durch die Zusammenführung spezialisierter Bereiche besteht eine flexible Organisationsstruktur, deren drei Sparten Komponenten, Engineering und Technologie-Zentrum eine Kombination aus wissenschaftlicher Dienstleistung, maßgeschneidertem Engineering und moderner Produktion sind, um gezielt und rasch auf wechselnde Anforderungen des Marktes reagieren zu können. Produkte der Sparte Komponenten sind u.a. STEYR-Verteilergetriebe f ü r Allrad-Nutzfahrzeuge, STEYR-Traktortriebwerke, Sonderfahrzeug-Getriebe, Präzisions-Verzahnungsteile und Getriebekomponenten, Auftragsentwicklung. Produkte der Sparte Engineering sind u.a. Entwicklungen f ü r Nutzfahrzeuge aller Art und Fahrzeugantriebe. Produkte der Sparte Technologie-Zentrum sind u.a. Dienstleistungen im Bereich Festigkeit, Technische Berechnung, CAD/CAM, Akustik und Schwingungstechnik. Die SAT erwirtschaftete 1998 mit ca. 870 Mitarbeitern in allen Sparten einen Jahresumsatz von ca. € 103,2 Millionen.

2 Geschäftsprozeßmanagement-Projekt 2 . 1 Ziele und Erwartungen Erklärtes Projektziel der Geschäftsführung war es, durch Schaffung einer effizienten und kundenorientierten Prozeßorganisation (vgl. z.B. [GaHe98]) eine Optimierung der Prozesse und Projekte herbeizuführen und dadurch • Kostenreduktion, • mehr Wettbewerbsfähigkeit und • stärkere Gewinnorientierung zu erreichen. 2 . 2 A u f t r a g und Auftragsinhalt Mit der Leitung des Projekts wurde ein externer Berater betraut. Die Aufgabenstellung lautete: • konsequente Ausrichtung der Unternehmensstruktur auf für den Kunden relevante Schlüsselprozesse; • Beurteilung der Kundenerwartung und Kundenzufriedenheit über Erfolgskenngrößen; • Aufbau von Regelkreisen zur Sicherstellung des Kundennutzens.

Entwicklung

von Erfolgskenngrößen

135

3 Projektphasen Das Projekt bestand aus mehreren aufeinanderfolgenden Phasen. Einer Startund Orientierungsphase auf Bereichsleiterebene folgten die Phasen E r h e b u n g des Istzustands (Istzustandsbeschreibung), Definition des Sollzustands (Konzeptphase) und Realisierung. Hauptgeschäftsprozesse

Erfolgskenngrößen

Akquisitionsprozeß: beim Kunden Sympathie für das UnterGewinnung von neuen Kunden nehmen wecken; Finding potentieller Kunden; Bereitschaft der Kunden, mit SAT zu arbeiten; Qualität der Kundenbesuche Angebotsbearbeitungsprozeß: Erstellung von Angeboten an Kunden Verkaufsprozeß: Ausverhandeln von Verträgen (Rahmenverträge) mit Kunden als Basis f ü r spätere Produktlieferungen Auftragsbearbeitungsprozeß: Abwicklung von Kundenbestellungen für Standardprodukte Entwicklungsprozeß: Entwicklung von neuen Produkten

Response Time; Treffen wünsche; Verständlichkeit

der

Kunden-

neuer Umsatz

Response Time; Zeit bis zur Auftragsbestätigung; Zeit vom Auftragseingang bis Auslieferung; Termintreue; Reaktionszeit; Verhältnis Auftragseingang zu Angebotslegung Kundenvorstellung; Auftragsdefinition Qualität der OEM-Information; Time to Market; Verhältnis von need/nice to have; Technisches Konzept; Innovative Lösung; Aufzeigen von Alternativen; Systemkompetenz (Fähigkeit Kundenanforderungen zu erkennen); Anzahl der Änderungen nach Projektfreigabe / Übergabe (Zeichnung, Stückliste etc.); Qualitätsfähigkeit Liefertreue (Termine, Stückzahl); Produktqualität (Gutteile zu Gesamtmenge); 0 - k m Reklamationen); Zuverlässigkeit; L i e f e r qualität (Verpackung, Qualität etc.)

Leistungserbringungsprozeß / Fertigung: Fertigung von Standardprodukten für konkrete Kundenaufträge After-Sales-Prozeß: Reaktionszeit (Problemlösung, Betreuung von Kunden nach dung); Wiederholhäufigkeit dem Verkauf von Standardprodukten Abwicklung von Kundenreklamationen Tab. 1 : Erfolgskenngrößen der Hauptgeschaftsprozesse

Rückmel-

136

Alfred

Gerstmayr

3.1 Start- und Orientierungsphase Die erste Aktivität war eine Startveranstaltung, an der alle Bereichsleiter (oberste Führungsebene am Standort Steyr und die Leiter der Abteilungen Qualitätsmanagement, Unternehmensplanung und Informatik) teilnahmen. Ziel Startveranstaltung war es, die Hauptgeschäftsprozesse zu definieren und deren Erfolgskenngrößen zu ermitteln (vgl. [Öste95,17]). Die Definition der Hauptgeschäftsprozesse wurde durch den Berater moderiert und im Rahmen einer Gruppendiskussion abgewickelt. Als Zwischenergebnis einigte man sich auf die in Tabelle 1 aufgelisteten Hauptgeschäftsprozesse. Nach Aufteilung in Kleingruppen nach fachlicher Zuständigkeit wurde eine Verfeinerung der Hauptgeschäftsprozesse in die wichtigsten Teilprozesse durchgeführt. Die Ergebnisse der Kleingruppen wurden von diesen präsentiert und im Plenum diskutiert. Danach wurden den Hauptgeschäftsprozessen die in den Gruppen erarbeiteten Erfolgskenngrößen zugeordnet. Dies geschah im Rahmen einer Gruppendiskussion, bei der die Erfolgskenngrößen auf ihren Kundennutzen hin kritisch hinterfragt wurden. Wie aus Tabelle 1 zu erkennen ist, waren zu diesem Zeitpunkt die Erfolgskenngrößen teilweise noch sehr vage formuliert. Wichtigste Erkenntnisse der Startveranstaltung waren: • Übergänge zwischen verschiedenen Organisationseinheiten stellten sich als Problempotential dar. Aufgrund der Ausdehnung von Prozessen über mehrere organisatorische Einheiten hinweg ergaben sich bei ihrer Beschreibung Probleme. Dies zeigte sich beispielsweise daran, daß manche Übergänge zwischen Organisationseinheiten weder von der einen, noch von der anderen Gruppe definiert werden konnten. Dies machte ein Problempotential beim Ablauf der Prozesse sichtbar. • Hierarchische Strukturen und Denkweisen können Prozesse nicht optimal begleiten. Die Frage, wer an welcher Stelle im Prozeß Durchführender und wer Entscheider sein soll, wird stark durch hierarchische Strukturen und Denkweisen geprägt. Die Notwendigkeit von Prozeß verantwortlichen wurde bewußt. • Begriffsdefinition ist erforderlich. Um eine eindeutige Prozeßbeschreibung zu erreichen, war es notwendig eine Abgrenzung der verschiedenen Prozesse vorzunehmen, deren Beginn und Ende zu definieren und zwischen Geschäftsprozessen und Organisationseinheiten klar zu unterscheiden. Eines der hartnäckigsten Probleme war es, eine klare begriffliche Trennung des Hauptgeschäftsprozesses von der Organisationseinheit zu erreichen. (z.B. Vertriebsprozeß versus Vertrieb als Organisationseinheit). • Visualisierung erleichtert Prozeßbeschreibung. Nach einem Brainstorming wurden Meta-Plankarten zur Prozeßvisualisierung verwendet, was sich als sehr effektiv erwies. In einer weiteren Sitzung - zwei Wochen später - wurden die ersten Arbeitsergebnisse noch einmal kritisch diskutiert und überarbeitet. Es ging dabei vor allem um eine Reduzierung der Anzahl der Hauptgeschäftsprozesse. Als

Entwicklung

von Erfolgskenngrößen

137

Ergebnis, das wiederum in Gruppen vorbereitet und anschließend gemeinsam im Plenum erarbeitet wurde, wurde das in Abbildung 1 gezeigte Prozeßnetzwerk verabschiedet. Kunde

Kunde

Unterstützungsprozesse

Abb. 1 : Prozeßnetzwerk

Eines der wesentlichen Kriterien zur Definition als Hauptgeschäftsprozeß war die Forderung, sowohl beim Input als auch beim Output Kundenkontakt aufzuweisen. Ein Ergebnis dieser frühen Projektphase war die Erkenntnis, daß die Kundenauftragsabwicklung von Standardprodukten nicht Subprozeß des Vertriebsprozesses, sondern Subprozeß des Fertigungsprozesses ist. Diese Erkenntnis bestätigte sich in den nachfolgenden Phasen. Für jeden Hauptgeschäftsprozeß des Prozeßnetzwerks wurde ein Kernteam und ein erweitertes Team nominiert. Aufgabe der Kernteams war es, in Form von Gruppensitzungen unter der Moderation des Beraters eine möglichst vollständige Istaufnahme der bestehenden Geschäftsprozesse durchzuführen und die Erfolgskenngrößen der Subprozesse sowie deren derzeitige Ausprägungen zu erheben. Die zusätzlichen Mitglieder des erweiterten Teams wurden zur Beantwortung spezieller Fragen herangezogen. 3 . 2 Istzustandsbeschreibung Ziel dieser Phase war die Erhebung und Analyse des Istzustands. Weiters sollte die Darstellung der Prozesse so erfolgen, daß sich daraus mögliche Sollprozesse einfach ableiten lassen.

138

Alfred

Gerstmayr

Methodische Vorbereitung Um den Kernteams eine wirkungsvolle Arbeitsweise zu ermöglichen, war es notwendig, diese über die Ziele, Grundlagen und Vorgehensweisen des P r o jekts zu informieren. Dies erfolgte in zweitägigen Schulungen für alle Mitglieder der Kernteams. Schwerpunkte der Schulungen waren: • • • •

Hauptgeschäftsprozesse, Subprozesse (soweit bereits definiert), Erfolgskenngrößen, Erhebungs- und Darstellungsmethoden.

Die Weitergabe dieses Wissens an die Mitglieder der erweiterten erfolgte nach dem Schneeballsystem.

Teams

Istzustandserhebung Bei der Erhebung des Istzustands wurde die vorhandene Dokumentation über die bisherige Ablauforganisation analysiert und mit Hilfe von Mitarbeiterbefragungen auf ihre Aktualität hin überprüft.

Analyse und Darstellung des Istzustands Die bestehende Ablauforganisation sollte prozeßorientiert in Form von Ablaufplänen und Prozeßprofilen erfolgen. Die Kernteams hatten dabei folgende Aufgaben: • • • • •

Benennen der Aktivitäten der Hauptgeschäftsprozesse; Clustern in Subprozesse; Erstellen eines Prozeßprofils je Subprozeß; Abstimmen der möglichen Erfolgskenngrößen; Darstellen der Subprozesse in Ablaufplänen.

In der Folge beziehen sich alle Beispiele auf den Fertigungsprozeß (Leistungserbringungssprozeß / Fertigung nach Tabelle 1). Benennen der Aktivitäten der Hauptgeschäftsprozesse: Diese Aufgabe wurde im Rahmen von Brainstormings und mit Hilfe der Metaplan-Technik durchgeführt. Jeder Teilnehmer schrieb die bekannten Aktivitäten auf Metaplan-Karten. Zur Visualisierung wurden diese auf Flipcharts geklebt. Anschließend wurden alle Aktivitäten im Team in Diskussionsform hinterfragt, präzisiert oder umformuliert, so daß ein gemeinsames Begriffsverständnis entstand. Clustern in Subprozesse: Die ermittelten Aktivitäten wurden durch Gruppieren der Metaplan-Karten zu Subprozessen zusammengefaßt; Doppelnennungen wurden entfernt. Als Ergebnis entstanden Subprozesse mit ihren Aktivitäten. Erstellen eines Prozeßprofils: Die Prozeßprofile sollten aus den möglichen Erfolgskenngrößen eines Subprozesses, dessen Meßdaten und einer Bewertungsskala gebildet und anschließend einer Bewertung anhand der Bewertungsskala unterzogen werden. Daraus ergaben sich folgende Aufgaben für die Kernteams:

Entwicklung

von Erfolgskenngrößen

139

• Benennen der möglichen Erfolgskenngrößen eines Subprozesses: Für den Fertigungsprozeß wurden Kriterien wie Zeit, Kosten, Qualität sowie Art und Anzahl von Aktivitäten benutzt, um die möglichen E r f o l g s kenngrößen der Subprozesse zu identifizieren. Für den Subprozeß Montage wurden folgende mögliche Erfolgskenngrößen ermittelt: -

Terminabweichungen (zu früher / zu später Lagerzugang) Deckung der Arbeitseinsatzrechnung Starre-Zone-Montageeinteilung Anzahl Fehlteile Kosten Nachmontagen Anzahl Null-Kilometer-Reklamationen Verfügbarkeit der Prüfstände Prüfqualität Durchlaufzeit

• Definieren einer Bewertungsskala: Mit Hilfe der Bewertungsskala für die Erfolgskenngrößen sollten Verbesserungspotentiale der Subprozesse leichter erkennbar werden. Die Bewertungsskala wurde folgendermaßen definiert (vgl. Tabelle 2): Bewertung Bedeutung kein Verbesserungspotential; Benchmarks bekannt 0 kein Verbesserungspotential sichtbar; Benchmarks 1 nicht bekannt Verbesserungspotential sichtbar 2 mittleres Verbesserungspotential; Aufwand/Nutzen3 Relation überprüfenswert 4 hohes Verbesserungspotential; Nutzen offensichtlich 5 sehr hohes Verbesserungspotential; offensichtliche Probleme; hoher Ist-Aufwand Tab. 2: Bewertungsskala für Erfolgskenngrößen

• Bewerten der Subprozesse: Anhand der Bewertungsskala und der für den Subprozeß identifizierten möglichen Erfolgskenngrößen wurden alle Subprozesse einer Bewertung unterzogen (vgl. Tabelle 3). Für jede Erfolgskenngröße wurde eine gemeinsame Einschätzung vorgenommen oder es wurden Echtdaten verwendet. • Abstimmen der möglichen Erfolgskenngrößen: Die Prozeßprofile der Subprozesse wurden auf ihren Zusammenhang mit den Erfolgskenngrößen des jeweiligen Hauptgeschäftsprozesses untersucht. Erfolgskenngrößen eines Subprozesses, die auf keine Erfolgskenngrößen des Hauptgeschäftsprozesses wirken, sind keine echten Erfolgskenngrößen oder wurden noch nicht als Erfolgskenngrößen eines Hauptgeschäftsprozesses definiert. Auf diese Weise wurden die bisher definierten E r f o l g s kenngrößen, die top-down definiert worden waren, bottom-up plausibilisiert.

140

Alfred

Gerstmayr

^\^Rewertungsskala

0 1 2 3 4 5 Meßgröße

Erfolgskenn-^^. großen (vgl. Tabelle

Liefertreue • Anlieferung Zukauf • Freigabe WE-Kontrolle Flexibilität • Auftragsmengen • Bestände

X

Gepl. Zugang-Istzugang (Tage) X Anzahl Werktage

X X

Anzahl Ausnahmemeldungen Reichweite, Umschlagshäufigkeit

Produktqualität • Anlieferqualität

X

Anzahl Prüfberichte Nacharbeitskosten, Verschrottungen zul. Lieferant Lieferantenbewertung

Kosten • Überlieferungen • Ladenhüter

X X

Anzahl Prüfberichte Wert K4-Materialbestand

Tab. 3: Prozeßprofil des Beschaffungsprozesses

Im Zuge dieser Abstimmung wurden alle für Subprozesse erarbeiteten Erfolgskenngrößen neu gegliedert und die Erfolgskenngrößen des Hauptgeschäftsprozesses endgültig bestimmt. Auf diese Weise wurden für den Fertigungsprozeß folgende Erfolgskenngrößen - inklusive dazugehöriger Meßgröße - bestimmt: Lieferfähigkeit. Anzahl der abgelehnten Kundenaufträge im Verhältnis zu den gesamten Kundenaufträgen bezogen auf den Kundenwunschtermin; Liefertreue. Anzahl der zum Kundenliefertermin gelieferten Aufträge im Verhältnis zu allen gelieferten Aufträgen zum zugesagten/bestätigten Liefertermin; Flexibilität. Zeit zwischen geplantem Bandauflagezeitpunkt laut Montageprogramm und dem letztmöglichen Zeitpunkt einer Kundenauftragsänderung- oder Erfassung; Produktqualität. Anzahl der reklamierten Produkte (Null-Kilometer-Reklamationen) im Verhältnis zur Anzahl der ausgelieferten Produkte; Kundenauftragsbestätigung. Zeit zwischen Bestelleingang und Auftragsbestätigung; Null-Kilometer-Reklamationen. Zeit zwischen Eintreffen der Reklamation und der Problemlösung. • Darstellen der Subprozesse in Ablaufplänen: Abschließend wurden alle Subprozesse mit Hilfe von Ablaufplänen dargestellt. Als Beispiel zeigt Abbildung 2 den Ablaufplan des Subprozesses Montage.

Entwicklung

von Erfolgskenngrößen

¡41

MONTAGE

f

1 ) /

Montageprogramm erstellen

Î

BA

einteilung

\ \ MI

\Montagopap |

/

erstellen

j

Ê I

Reihenfolgeerstellung

Papiere

1

Mitarb.

bereitsl.

M

einteilen

\ \ # /

\

M

1 N05955

\ 1j

Teilebereitstellung

Lager-

Ii

Tran»-

abruf

I /

port

\

\

"1

-¡^

ΓΊι

Montieren

Vor-

1

End-

m I montage • montage

ïaswQ*

i

Lackieren

^

1

I

Abb. 2: Ablaufplan des Subprozesses Montage

3 . 3 Konzeptphase Nach der Beschreibung des Istzustands wurde nach Möglichkeiten zur Ablaufverbesserung gesucht. Dies lief in folgenden Schritten ab: • Finden einer Idealversion und e Ermitteln einer machbaren Sollversion. Finden einer Idealversion In dieser Phase wurde bei der Ideenfindung versucht, auch unkonventionelle Ansätze der Prozeßverbesserung zu entwickeln. Erarbeiten von idealen Prozessen (Idealversion): Mit Hilfe von Brainstorming und Gruppendiskussion wurden in den Kernteams Merkmale für den idealen Ablauf der Subprozesse ermittelt (vgl. Tabelle 4). Dabei orientierten sich die Ideen auch an den Erfolgskenngrößen der Subprozesse. Damit konnte sichergestellt werden, daß die Wirkung auf die Erfolgskenngrößen des Hauptgeschäftsprozesses gegeben war. Wirkung von Merkmalen des idealen Prozesses auf Erfolgskenngrößen: Anhand einer Bewertungsskala wurde die Wirkung jedes Merkmals der Idealversion eines Prozesses auf die definierten Erfolgskenngrößen des Hauptgeschäftsprozesses ermittelt (vgl. Tabelle 4). Bewertungsmatrix: Da die Erfolgskenngrößen des Fertigungsprozesses unterschiedliche Wirkung und für den Kunden unterschiedliche Bedeutung haben, wurde eine Gewichtung der Erfolgskenngrößen vorgenommen (vgl. Tabelle 5). Die Reihung der Merkmale innerhalb der Bewertungsmatrix nach der Summe der erreichten Punkte sollte die Möglichkeit schaffen, Maßnahmen zu identifizieren und zu priorisieren.

Entfall der Mitarbeitereinteilung (Selbstorganisation anstelle Administration)

X

X

automatische Teilebereitstellung kein Lager

Kosten

X

Betreuung

Merkmale

Produktqualität

Erfolgskenngrößen

Flexibilität

Gerstmayr Liefertreue

Alfred

Lieferfähigkeit

142

X -

-

DLZ < 1 Arbeitstag

X

X

X

X

X

qualitativ einwandfreie Teile

X

X

X

X

X

X

keine Fehlteile

X

X

X

X

X

X

fehlerfreie Doku (Stüh, FPläne)

X

X

X

X

bestgeschultes Personal

X

X

X

X

reduzierte Montageinhalte (Systemlieferanten intern & extern)

X

X

X

X

X

kein Prüfstand (weil exzellente Qualität)

X

X

X

X

fehlerfreie Montage

X

X

X

X X

X

X

X

Tab. 4: Wirkung der Merkmale des idealen Montageprozesses auf die Erfolgskenngrößen des Fertigungsprozesses

Ermitteln einer machbaren Sollversion In dieser Phase wurden für Merkmale der Idealversion, die nach dem Kriterium der Machbarkeit ausgewählt wurden, Veränderungensaktivitäten zu Maßnahmenpaketen gebündelt. Zuerst wurden die Merkmale aller Subprozesse gemäß ihrer Wirkung auf den Hauptgeschäftsprozeß gereiht (vgl. Tabelle 5). Für die Merkmale mit den meisten Punkten (dem höchsten Verbesserungspotential) wurden in den erweiterten Teams Maßnahmen gesucht, die sich positiv auf die Ausprägung der Erfolgskenngrößen des Hauptgeschäftsprozesse auswirken. Auf diese Weise entstand - je ausgewähltem Merkmal der Idealversion eines Subprozesses - ein Maßnahmenbündel, das Basis für die weitere Ausarbeitung darstellte.

Summe

Kosten

Zwischensummen

143

J*· , =, < verwendet. Die Zweckmäßigkeit dieser Skala ergibt sich aus der Tatsache, daß mit jeder Metrik die Ausprägungen von genau zwei

208

Lutz J. Heinrich / Gustav

Pomberger

Alternativen zu skalieren sind, wenn - wie in unserer Fallstudie - zwei Anbieter am Prototyping teilnehmen. Da die Ausprägungen von mehreren Beobachtern erfaßt werden (z.B. mehrere Benutzer, Benutzer und externe Projektbegleiter, mehrere externe Projektbegleiter), müssen je Metrik mehrere ordinale Skalenwerte aggregiert werden. Die Aggregation erfolgt mit der Häufigkeits-ZVorzugsregel. Ist bei einer geraden Anzahl von Beurteilern kein Vorzug gegeben, erfolgt solange eine Diskussion der Beurteilungen im Kreis der Beurteiler, bis die Pattsituation aufgelöst ist. Eine Gewichtung der Skalenwerte ist nur bei in Summe geringem Vorzug vorgesehen; mit verschiedenen Gewichtungen werden dann Sensitivitätsanalysen durchgeführt, um die Optimum zu bestimmen.

5 Vorgehensweise Die Vorgehensweise nach dieser Methodik wird exemplarisch an einer Fallstudie gezeigt, die in einem Dienstleistungsunternehmen des Finanzsektors Ende 1996 / Anfang 1997 durchgefühlt wurde. Die Ausschreibung verlangte ein Software-System zur Unterstützung der Kern-Geschäftsprozesse. Das für die Ausschreibung verwendete Lastenheft hatte einen Umfang von rd. 17 Seiten DIN-A4. Es enthielt die Beschreibung des Istzustands der fünf Kern-Geschäftsprozesse (7 Seiten), die Rahmenbedingungen für den Auftragnehmer mit Projektmeilensteinen (1 Seite), die Informatik-Strategie des Auftraggebers (2 Seiten), die Organisationsziele einschließlich Gestaltungsziele für die Struktur- und Ablauforganisation sowie für die Informationssysteme (2 Seiten), die prototypingbasierte Projektmethodik (1 Seite), die vorhandene Hardware- und Software-Plattform (1 Seite), die Auftragsbedingungen (1 Seite) sowie den Angebotskatalog (2 Seiten; alle Seitenangaben aufgerundet). Die Anbieter wurden eingeladen, sich bei Bedarf durch Beobachtung und Befragung „vor Ort" weitere, zur Angebotslegung erforderliche Informationen zu beschaffen. Es erfolgte eine geschlossene Ausschreibung mit vier Anbietern, die als Vertreter deutlich unterschiedlicher Ausprägungen mehrerer Eigenschaften (insbesondere Unternehmensgröße, verwendete Software-Technologie, Knowhow-Schwerpunkt, Referenzen) ausgewählt wurden. Unter den vier Angeboten erfolgte eine Vorauswahl anhand weniger, auch den Anbietern bekannter Kriterien. Durch die Vorauswahl wurden zwei Anbieter bestimmt, die anschließend prototypingbasiert evaluiert wurden. Die Evaluation erfolgte metrik-basiert (vgl. Tabelle 1). Für das Prototyping wurden Teile des f ü r den Unternehmenserfolg wichtigsten Kern-Geschäftsprozesses verwendet, die anwenderseitig mit dem Ziel festgelegt wurden, daß alle in den ProduktMetriken abgebildeten Eigenschaften gemessen werden können. Die Anforderungen an die Beobachtung des Prototyping anhand der Metriken wurden in einem halbtägigen Workshop allen beteiligten Benutzern und dem TopManagement präsentiert und diskutiert.

Prototypingbasierte

Evaluation von Software-Angeboten

209

Nach Abschluß des Prototyping wurden in einem zweiten halbtägigen Workshop die dokumentierten Beobachtungen je Beobachter und Metrik skaliert. Es wurde eine Beurteilung über alle Metriken erarbeitet und dem Top-Management eine Empfehlung für den Anbieter mit der größeren Leistungsfähigkeit gegeben. Die Entscheidung über die Auftragsvergabe durch das Top-Management erfolgte unter Berücksichtigung einer Reihe unternehmerischer Kriterien wie Investitionshöhe und Projektrisiko sowie Marktbedeutung und Innovationspotential der Anbieter. Dies änderte am Ergebnis der Evaluation nichts; die Auftragserteilung erfolgte an den Anbieter, der aufgrund der prototypingbasierten und metrikbasierten Evaluation als Bestbieter identifiziert worden war. Unverzüglich nach Auftragserteilung wurde der in der Angebotsphase mit Prototyping begonnene Herstellungsprozeß fortgesetzt. Das Projekt wurde mit 6 Wochen Vorlauf, planmäßig per 31. 12. 1997 abgeschlossen; der Echtbetrieb wurde planmäßig am 2. 1. 1998 aufgenommen.

6 Befunde Wir referieren kurz das Ergebnis des Evaluationsprozesses und wenden uns dann den Befunden im Sinn von Ergebnissen wissenschaftlicher Begleitbeobachtung des Ausschreibungsprozesses, des Evaluationsprozesses sowie des Herstellungsprozesses zu. Von den 10 Produkt-Metriken konnten acht mit ausreichender Zuverlässigkeit beurteilt werden, zwei nicht (Zeitverhalten, Benutzbarkeit). Von den 8 Prozeß-Metriken konnten 7 beurteilt werden; die Ausprägungen zu den Metriken Entwicklungszeit und Reaktionszeit konnten nicht klar genug getrennt werden, so daß Reaktionszeit als Teil von Entwicklungszeit beurteilt wurde. Alle 6 Personen-Metriken konnten beurteilt werden. Im Ergebnis erhielt Angebot A zehnmal den Vorzug, Angebot Β einmal den Vorzug, zehnmal erhielt weder A noch Β den Vorzug. Das Ergebnis war damit eindeutig (A>B), also A leistungsfähiger als B. Aufgrund der Beobachtung des Ausschreibungsprozesses folgende Befunde:

formulieren wir

• Arbeitsaufwand, Zeitbedarf und Kosten (im wesentlichen Personalkosten) waren auf Seiten des Auftraggebers (einschließlich externer Begleitung) gering. Die Ausschreibungsdokumentation konnte innerhalb 11 Wochen mit 24 Personentagen erarbeitet werden, weil das Lastenheft knapp gehalten war (vgl. weiter oben) und ein Pflichtenheft im Sinn einer Anforderungsspezifikation für den Systementwurf nicht erarbeitet wurde. • Im gescheiterten Vorgängerprojekt, das konventionell mit der Erstellung eines umfangreichen Pflichtenhefts und ohne Prototyping bearbeitet wurde, waren 16 Wochen für die Erstellung der Ausschreibungsdokumentation mit 60 Personentagen Arbeitsaufwand auf Seiten des Auftraggebers (ohne externe Begleitung) erforderlich. Für die externe Begleitung (nicht durch uns), insbesondere für die Erstellung des Pflichtenhefts, wurden dem Auftraggeber 50 Personentage in Rechnung gestellt.

210

Lutz J. Heinrich / Gustav

Pomberger

Die prototypingbasierte Methodik führte also beim Ausschreibungsprozeß zu einer drastischen Verringerung des Arbeitsaufwands beim Auftrageber (24 statt 110 Personentage). Zwar verfügen wir nicht über Daten über den Arbeitsaufwand auf Anbieterseite, schließen aber aus den Angeboten darauf, daß die prototypingbasierte Methodik anbieterseitig keinen Mehraufwand erfordert hat. Aufgrund der Beobachtung des Evaluationsprozesses folgende Befunde:

formulieren

wir

• Für die meisten Metriken können die Ausprägungen nur mit direkter Beobachtung, ohne Verwendung irgendwelcher Hilfsmittel zur Messung und lediglich verbalsprachlich erfaßt werden. Nur selten ist es möglich, quantitativ zu messen. Die Beobachter müssen daher möglichst nachvollziehbar (das heißt schriftlich) dokumentieren, was sie beobachtet haben. • Die Zeitdauer für den Evaluationsprozeß betrug planmäßig 5, tatsächlich 4 Kalenderwochen, also einen Zeitraum von 20 Arbeitstagen. • Der Arbeitsaufwand für den Evaluationsprozeß betrug anwenderseitig rd. 15 Personentage, davon 12 für Benutzer und Management und 3 f ü r externe Begleitung. Die geplante und erforderliche Benutzerbeteiligung war realisierbar. • Der anbieterseitig geleistete Arbeitsaufwand für das Prototyping wurde uns von einem der Anbieter mit 40 Personentagen angegeben, für den anderen Anbieter wird er aufgrund von Beobachtungen mit 55 Personentagen geschätzt. Für vergleichbare Projekte, in denen auf der Grundlage von Pflichtenheften angeboten wird, ist der Arbeitsaufwand erfahrungsgemäß wesentlich geringer; Aufwandszahlen liegen uns aber nicht vor. • Der Auftragnehmer konnte den in der Angebotsphase entwickelten Prototypen in einem Umfang von rd. 90% gemessen am Arbeitsaufwand (d.h. im Umfang von rd. 36 Personentagen) im Herstellungsprozeß wiederverwenden. Der Arbeitsaufwand für das Prototyping betrug für diesen Anbieter also nur rd. 4 Personentage. Die 55 Personentage, die der zweite Anbieter aufgewendet hat, wurden vom Auftraggeber mit einen Pauschalpreis für den Prototypen teilweise abgegolten. • Es gibt Metriken, deren Ausprägung nicht in dem Umfang und mit der Genauigkeit gemessen werden kann, die für eine zuverlässige Beurteilung erforderlich ist (insbesondere die Produkt-Metriken Zeitverhalten und Benutzbarkeit). Die beabsichtigte Verwendung des Zeitverhaltens als Produkt-Metrik erwies sich als unzweckmäßig, da die Erfassung der dafür erforderlichen Daten zu aufwendig war. Die nicht ausreichende Beurteilbarkeit der Benutzbarkeit ist darauf zurückzuführen, daß die Benutzer davor zurückschreckten, verbindliche Urteile abzugeben. Wir führen dies darauf zurück, daß die Benutzer über keine Erfahrung mit prototypingbasierter Entwicklung verfügten. • Es gibt Metriken, deren Ausprägung nicht scharf getrennt werden kann, so daß die Ausprägungen mehrerer Metriken zu einer Beurteilung zusammengefaßt werden müssen (insbesondere die Prozeß-Metriken Entwicklungszeit und Reaktionszeit). Durch den engen Zeitrahmen für das Prototyping (5 Wochen geplant) war die Erreichung des erforderlichen Proto-

Prototypingbasierte

Evaluation von Software-Angeboten

211

typing-Fortschritts vor allem davon abhängig, wie kurz die Reaktionszeit der Anbieter nach jeder Erprobung durch die Benutzer war. Aufgrund der Beobachtung des Herstellungsprozesses formulieren folgende Befunde (soweit dies die eingangs formulierte These betrifft):

wir

• Der Prototyp hat im Evaluationsprozeß einen Zustand erreicht, der etwa 5% der vom Endprodukt geforderten Funktionalität umfaßt. • Das Fach Verständnis des Anbieterpersonals hat im Evaluationsprozeß ein Niveau erreicht, das über etwa 80% der gesamten Geschäftstätigkeit ausreichend Klarheit gibt; die verbleibenden 20% wurden als für den Projekterfolg nicht kritisch eingeschätzt. • Die durch das gescheiterte Vorgängerprojekt verursachte Verunsicherung der Benutzer im Hinblick auf den Projekterfolg war mit der Auftragserteilung beseitigt, weil sie durch das Erproben der Prototypen gelernt hatten, wie Produktqualität und Leistungsfähigkeit potentieller Auftragnehmer zu beurteilen sind. • Der Stand der Implementierung hat 6 Monate nach Auftragserteilung einen Umfang erreicht, der dem des gescheiterten Vorgängerprojekts nach 24 Monaten entsprach. Nach diesen 6 Monaten (von insgesamt 12 Monaten geplanter Projektdauer) wurden 2/3 des Produktumfangs implementiert.

7 Interpretation In der Fachliteratur ist über Jahre hinweg ausgiebig das Verhältnis von Phasenmodell und Prototyping diskutiert worden. Im Ergebnis kann als herrschende Meinung angesehen werden, daß die beiden Methodikansätze keine Alternativen sind, sondern sich sinnvoll ergänzen. Auch bezüglich Lastenheft/Pflichtenheft einerseits und Prototyping andererseits vertreten wir den Standpunkt, daß beide Ansätze miteinander verträglich sind. Wir plädieren jedoch für eine deutliche Zurücknahme der Bedeutung des Lastenhefts (bzw. nach herrschendem Sprachgebrauch des Pflichtenhefts) in der Ausschreibung und für die Evaluation von Software-Angeboten mittels Prototyping, das heißt für die Ausdehnung des Prototyping-Ansatzes vom Software-Entwicklungsprozeß auf Software-Angebote. Aufgrund der referierten Befunde kann gesagt werden, daß die Qualität des Evaluationsprozesses, gemessen an den Kriterien Aufwand (Arbeitsaufwand und Zeitbedarf), Kosten und Zuverlässigkeit der Ergebnisse, durch Prototyping deutlich verbessert wird. Positive Auswirkungen auf den Ausschreibungsprozeß und auf den Herstellungsprozeß konnten beobachtet werden. Die Erwartung, daß weder bei der Einführung, noch bei der Nutzung des Produkts mit Akzeptanzproblemen gerechnet werden muß, hat sich bis zum Ende des Beobachtungszeitraums (Frühjahr 1998) bestätigt. Eine Verbesserung von Wirksamkeit und Wirtschaftlichkeit durch Prototyping kann daher nicht nur für den Ausschreibungsprozeß und den Evaluationsprozeß

212

Lutz J. Heinrich / Gustav

Pomberger

als nachgewiesen gelten und im Herstellungsprozeß beobachtet werden, sondern auch für den Nutzungsprozeß behauptet werden. Zum Zeitpunkt der Aktualisierung dieses Beitrags begleiten die Autoren ein zweites, wesentlich größeres Projekt mit prototypingbasierter Evaluation von Software-Angeboten in einem Unternehmen des Bank- und Versicherungssektors. Sie werden zu gegebener Zeit darüber berichten, ob und in welchem Umfang die hier referierten Befunde bestätigt wurden (vgl. [HePo99]). Literatur [Curt90] Curth, Μ. Α.: Pflichtenheft. In: Mertens, P. et al. (Hrsg.): Lexikon der Wirtschaftsinformatik. Berlin et al. 1990, 324 - 326 [Hein94] Heinrich, L. J.: Systemplanung Bd. 1. München/Wien 1994 [Hein97a] Heinrich, L. J.: Management von Informatik-Projekten. München/Wien 1997 [Hein97b] Heinrich, L. J. et al.: Diagnose der Informationsverarbeitung - Konzept und Fallstudie. In: C O N T R O L L I N G 3/1997, 196 - 203 [Hein99J Heinrich, L. J.: Informationsmanagement. München/Wien 1999 [HePo99] Heinrich, L. J. / Pomberger, G.: Prototypingbasiertes Software-Management. In: Oberweis, A. / Sneed, Η. M. (Hrsg.): Software-Management. Leipzig/Stuttgart 1999, 206 - 224 [Kurb93] Kurbel, K.: Produktionsplanung und -Steuerung. München/Wien 1993 [Mert95] Mertens, P. et al.: Grundzüge der Wirtschaftsinformatik. Berlin et al. 1995 [Mitt90] Mittermair, R.: Requirements Engineering. In: Kurbel, K. / Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik. Stuttgart 1990,237 - 256 [PlSc86] Platz, J. / Schmelzer, H. J.: Projektmanagement in der industriellen Forschung und Entwicklung. Berlin et al. 1986 [PoB196] Pomberger, G. / Blaschek, G.: Software Engineering. Prototyping und objektorientierte Software-Entwicklung. MiinchenAVien 1996 [Pomb90] Pomberger, G.: Methodik der Softwareentwicklung. In: Kurbel, K. / Strunz, H . (Hrsg.): Handbuch Wirtschaftsinformatik. Stuttgart 1990, 2 1 5 - 2 3 6 [PoWe97] Pomberger, G. / Weinreich, R.: Qualitative und quantitative Aspekte prototypingorientierter Softwareentwicklung - Ein Erfahrungsbericht. In: Informatik-Spektrum 1/1997,33 - 3 7 [Stah95] Stahlknecht, P.: Einführung in die Wirtschaftsinformatik. Berlin et al. 1995 [VDI91] VDI/VDE (Hrsg.): VDI/VDE-Richtlinie Nr. 3694: Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen. 1991

Technologien als Evaluationsobjekt Einführung und Grundlegung Gerhard A. Wührer [email protected]

Institut f ü r H a n d e l , A b s a t z u n d M a r k e t i n g d e r U n i v e r s i t ä t L i n z www.market.uni-linz.ac.at

Inhalt 1 Begriffliche Abgrenzungen und Fassungen zu Evaluation 2 Evaluation im Rahmen des strategischen und operativen Managements 3 Evaluation und F&E-Projektauswahl 4 Anforderungen und Gütekriterien von Evaluationsverfahren

Zusammenfassung Evaluationsverfahren und Evaluationsprozesse sind wesentlicher Bestandteil des Managementwissens und der Managementpraxis. Die Ursachen und Gründe für die Durchführung von systematischen Evaluationen mittels wissenschaftlicher Methoden sind vielfältig. Häufig werden mit Technolgieevaluation oder Technologieassessment die Erfassung und Gewichtung der direkten und indirekten, intendierten und nicht-intendierten, kurz- und langfristigen Effekte der Einführung und Anwendung neuer Technologien auf Umwelt, Gesellschaft und Unternehmen verstanden. Technologieevaluation hat sowohl strategische als auch operative Dimensionen, die im Ziel-MittelKontext von Organisationen und ihrem Umfeld zu verstehen sind. Die Qualität der Evaluationsergebnisse hängt davon ab, ob sie den Forderungen nach Validität, Réhabilitât und Repräsentativität entsprechen.

Abstract Evaluation procedures in technology management are themselves subject to meeting standards and criteria. The question is which criteria should be applied. As procedures and models used in evaluation of technology, standards of empirical research, whether quantitative or qualitative, should be met. Criteria domains are validity, reliability, and generalisation of the findings. Evaluation procedures are of different potency, according to the fulfilment of criteria. It is understandable that the development of evaluation procedures is based on the dynamics and developments of methodology in social theory.

214 Gerhard A. Wiihrer

1 Begriffliche Abgrenzungen und Fassungen zu Evaluation Die begriffliche Fassung des Verständnisses von Technologieevaluation setzt bei verschiedenen Ebenen an. In synonymer Verwendung stehen die Bezeichnungen wie Assessment oder Bewertung, wobei sich der Verein Deutscher Ingenieure (VDI) in seiner Richtlinie 3780 von der begrifflichen Fassung „Technologiefolgenabschätzung" (TA) getrennt und f ü r Technology Assessment den übergeordneten Begriff „Technikbewertung" (TB) gewählt hat. Im Sinn dieser Richtlinie bedeutet Technologiebewertung nach [Bull94] ein planmäßiges, systematisches und organisiertes Vorgehen, das den • Technologiestand und Entwicklungsmöglichkeiten analysiert, • unmittelbare und mittelbare technische, wirtschaftliche, gesundheitliche, ökologische, humane, soziale und andere Auswirkungen und Folgen dieser Technologien und mögliche Alternativen abschätzt, • diese Technologien aufgrund offengelegter Ziele und Werte hinsichtlich ihrer Folgen beurteilt und weitere wünschenswerte Entwicklungen f o r d e r t und darüber hinaus • Handlungs- und Gestaltungsmöglichkeiten herleitet und ausarbeitet. Es geht darum, möglichst alle - positiven und negativen Technologiefolgen (vgl. [KeSch77], [Bull94]) zu erfassen und zu beurteilen. Nach diesem umfassenden Verständnis von Evaluation bleibt der Prozeß nicht auf einen einzelnen Entscheidungsträger beschränkt, sondern wird von einem Netzwerk gesellschaftlicher Einrichtungen vorbereitet, unterstützt und begleitet. In einer engeren begrifflichen Fassung kann sich das Evaluationsverständnis auf nur unmittelbare und mittelbare, positive und negative, kurz- und langfristige Folgen von Technologien auf Zielerreichungsgrade eines Unternehmens beziehen. Zusammenfassend kann unbeschadet des engen oder weiteren Verständnisses von Evaluation diese als dynamischer Verfahrensprozeß bezeichnet werden, dessen Erkenntnisinteresse jeweils kausale Beziehungen zwischen Technologie als wirkende Größe und Systemveränderungen sind. Er dient zur Unterstützung der Entscheidungsfindung im (Unternehmens-) politischen Kontext und bedient sich verschiedener Mittel und Instrumente. Nicht gefolgt wird hier einem engen begrifflichen Verständnis, das unter Technologiebewertung die ausschließlich kostenorientierte Abschätzung von alternativen Technologien und deren Auswirkungen berücksichtigt. Technologische Vorhersagen (technological forecasting) sind im b e g r i f f lichen Umfeld von Technologieevaluation zu sehen. Unter ihnen kann jede Aussage über zukünftige Entwicklungen von Wissenschaft und Technik verstanden werden. Der Vielfalt solcher Aussagen sind kaum Grenzen gesetzt. Beispielhaft handelt es sich dabei um solche wie „Die beliebige Ubertragbarkeit von Software-Produkten und Teilen von Software-Produkten von einem Betriebssystem auf ein anderes wird spätestens in fünf Jahren möglich sein." Oder: „Die Höchstgeschwindigkeit von Flugzeugen der Zivilluftfahrt wird im Jahre 2010 standardmäßig die dreifache Schallgeschwindigtkeit überschreiten." Noch besitzen technologiche Vorhersagen nicht die Qualität

Technologien

als Evaluationsobjekt

215

von Prognosen im Sinn von Popper [Popp72] oder Albert [Albe64], da eine empirisch fundierte Theorie erst in Ansätzen vorhanden ist und Gesetzmäßigkeiten, die eine Bestimmung der zukünftigen Entwicklung von Technik, Wissenschaft und Gesellschaft zulassen würden, fehlen. Aus diesen und anderen Gründen konzentriert man sich auf Unternehmensebene auf Konzepte der strategischen Früherkennung (vgl. [Anso81]), mittels derer langfristige technologische Veränderungen, die sich durch „schwache Signale" ankündigen, identifiziert werden sollen. Verschiedene Instrumente (vgl. [ElKr94]), auf die hier nicht näher eingegangen werden kann, stehen für diese Aufgabe zur Verfügung.

2 Evaluation im Rahmen des strategischen und operativen Managements Technologieevaluation kann als Teil des umfassenderen Planungs- und Beurteilungsprozesses im Rahmen des strategischen Managements verstanden werden. Bleibt man in der Diskussion auf dieser Ebene, zielt Technologieevaluation auf folgendes ab: • die Erfassung und Bewertung der Quellen des Wettbewerbsvorteils; • die Auseinandersetzung mit der Eruierung der Wettbewerbsposition eines Unternehmens; • die Erfassung der Zielerreichungsgrade, etwa im Sinn von Kundenzufriedenheit und -loyalität, Marktanteil und Profitabilität. Focus

Contents

Competitor centred

Analysis of strength and weakness Relative size of resources

Customer focused

Value chain Customer choice criteria Segment differences in benefits

Management Outcome Judgements Comparison of value chains of firms versus target Points of competitor; superiority configuration and total costs

Comparison of attribute ratings of Points of firm versus superiority competitors Customer ments

Judge-

Tab. I : Wesentliche Entscheidungsfelder zur Beurteilung der Wettbwerbsposition (Quelle: [DaWe95,138])

216

Gerhard Α. Wahrer

Die Systematisierung der Felder zur mittel- und langfristigen Evaluation der Wettbewerbsposition beinhaltet zum einen solche, die sich auf die Mitbewerberseite beziehen, zum anderen solche, die zur Bewertung der kundenorientierten Position führen. Diese Fragen sind Kernaufgaben der Planung und Entscheidungsfindung im strategischen Management (zur Bedeutung im Industriegütermarketing vgl. [Back97]). Integrierte Konzepte [DaWe95] beinhalten sowohl die Kunden- als auch die Mitbewerberdimension (vgl. Tabelle 1). Der strategische Wettbewerbsvorteil eines Unternehmens auf dem Markt und vis-à-vis Mitbewerbern kann sich demnach ausschließlich auf den Erfolgsfaktor und die Ressource Technologie begründen oder in Zusammenwirken mit anderen Faktoren verstanden werden. Unter Marketinggesichtspunkten geht es darum, festzustellen, welchen Beitrag der Erfolgsfaktor Technologie zur nachhaltigen Stiftung eines komparativen Konkurrenzvorteils [Back97] liefern kann. Evaluation im Rahmen des strategischen Technologiemanagements als interdisziplinärer Teil des strategischen Managements (vgl. [Hein99,155f.]) beinhaltet verschiedene Aufgaben und Fragestellungen. Ihr vorgeschaltet ist die Früherkennung, die sich mit der Identifikation relevanter Technologieentwicklungen und strategisch wichtiger Geschäftsfelder auseinandersetzt (siehe Abbildung 1). Die strategische Analyse befaßt sich vor allem mit der Evaluation von Technologietendenzen und deren rechtzeitiger Risikoerkennung und -abschätzung. Hier findet auch die schon erwähnte unternehmensbezogene Bewertung von Stärken-ZSchwächen-Profilen in einzelnen Technologiefeldern statt.

Abb. 1 : Prozeß des strategischen Technologiemanagements

Technologien als Evaluationsobjekt

217

Beispielhafte Programmfragen in diesem Abschnitt des Entscheidungsprozesses sind [Bull94] : Wo zeichnen sich aufgrund neuer Technologien Chancen und Risiken ab? Welche Technologien, die wir gegenwärtig einsetzen, werden in den nächsten Jahren veralten oder substituiert werden? In der Auswahl der zu bearbeitenden Technologiefelder und der dazu notwendigen F&E-Projekte [Gerp99] werden wiederum Evaluationen durchgeführt. Die Felder der Strategieformulierung, das der Programmplanung und -evaluation, die Strategiedurchsetzung bzw. -Implementierung und die strategische Kontrolle schließen den Zyklus des strategischen Managements ab. Zu überlegen ist, welche Evaluationsprozesse im Rahmen des operativen Technologiemanagements stattfinden. Hauptziel des operativen Technologiemanagements ist die Ausrichtung und Koordination der operativen Projekte und Systeme auf die gewählten Strategien. Diese Evaluationsverfahren beinhalten Methoden und Techniken, die sich mit strukturellen, personellen und technokratischen Fragestellungen [Ewal89] beschäftigen. Üblicherweise laufen deshalb Evaluationprozesse auf der operativen Ebene im Rahmen von Technologieprojekten ab [Arch92], Ziele sind: • die Übersicht über die Entwicklung von Kosten, Zeitplänen, technischem Stand und deren Zusammenhängen zu behalten; • antizipierend mögliche Risiken und Probleme, ζ. B. bei der Nützlichkeit zu identifizieren, um sie zu vermeiden oder in ihren Auswirkungen zu minimieren; • Chancen aufzuspüren, die eine Beschleunigung von Projekten erlauben, Kostenreduktionen zulassen und technologische Vorteile realisierbar machen, bevor diese Möglichkeiten im Laufe der Projektentwicklung unwiderruflich verloren gehen.

3 Evaluation und F&E-Projektauswahl Das Problem der F&E-Projektauswahl ist ein wesentlicher Entscheidungstatbestand im strategischen Technologiemanagement, da typischerweise der Finanzmittelbedarf die zur Verfügung stehenden Finanzmittel übersteigt, um alle „erfolgsträchtigen Projekte" zu bearbeiten. Die zur Auswahl eingesetzten Verfahren lassen sich nach folgenden Kriterien ordnen (vgl. [Gerp99], [PoC92]): • Art der Ziele (wirtschaftliche vs. nichtwirtschaftliche), • Zahl der Ziele (eindimensionale vs. mehrdimensionale), • Skalierung der Informationen (qualitativ vs. quantitativ). Verfahren aus drei Klassen kommen in der Praxis zur Anwendung: qualitative, semi-quantitative und quantitative. Zur Gruppe der qualitativen Verfahren zählen ganzheitlich gebildete Projekteinschätzungen auf der Basis von intuitiven Projektgesamtbildern anhand weniger Kriterien oder nicht-konsolidierte Einschätzungen mittels Checklisten oder Stärken-Schwächen-Projektprofilen. Semi-quantitative Verfahren wie Nutzwert-Scoring-Analysen, analytische/mehrdimensionale Projektrangreihen mittels Analytical Hierar-

218

Gerhard Α. Wahrer

chy Processing (ΑΗΡ) führen zu einer differenzierteren Auswahlentscheidung [Gerp99]. Quantitative Methoden stellen hauptsächlich auf statische und dynamische Verfahren der Investitionsrechnung ab, deren Nachteile durch Methoden der Kosten-Nutzen-Analysen zu überwinden versucht werden. Der praktische Einsatz der Verfahren hängt im wesentlichen von der Verfügbarkeit brauchbarer Schätzwerte und Daten für die Inputgrößen ab. Aus diesem Grund haben die formal eleganten, quantitativ-finanzwirtschaftlichen Verfahren nur geringe praktische Bedeutung.

4 Anforderungen und Gütekriterien von Evaluationsverfahren Die in Evaluationsverfahren eingesetzten Methoden und Techniken haben eine Ähnlichkeit mit den Verfahren der empirischen Sozial- und Unternehmensforschung (vgl. z.B. [o.V.99]). Daher ist es naheliegend, die für diese Verfahren geforderten wissenschaftlichen Standards als verbindlich für die Konzeption und die Anwendung anzusehen. Da sowohl quantitativ-orientierte Evaluationsverfahren als auch solche qualitativer Art zur Abschätzung von Technologien und ihren Wirkungen herangezogen werden, ist die Argumentation im Kontext der wissenschaftstheoretischen Auseinandersetzung „subjektive vs. objektive Forschung" (vgl. [Müll99]) zu verstehen. Gemeinsame Anspruchsniveaus an beide Klassen von Evaluationsverfahren beziehen sich auf Validität, Réhabilitât und Repräsentativität (siehe Tabelle 2). Qualitative • • • • • •

• •

Quantitative

Validität • Inhaltsvalidität • Augenscheinvalidität • Expertenvalidität • Kriteriums- bzw. empirische Validität • Übereinstimmungsvalidität • Vorhersagevalität • Konstruktvalidität • Kreuzvalidität Reliabilität Vergleichbare Kriterien • Paralleltest-Reliabilität • Intercoder-Reliabillität • Test-Retest-Reliabilität • Intracoder-Reliabilität (Stabilität) Alternative Kriterien • Interne Konsistenz • Stimmigkeit: Vereinbarkeit von Zielen und Methoden der Forschungsarbeit • Transparenz (Datenerhebung) Offenheit/Nachvollziehbarkeit (Datenauswertung) durch multipersonalen Diskurs Ökologische Validität Kommunikative Validität Argumentative Validität Kumulative Validität Validierung an der Praxis Authentizität

Technologien als Evaluationsobjekt

219

Repräsentativität • •

• •

Sicherung der Generalisierbarkeit • durch rekonstruktive Verfahren • Theoretisch-systematische Auswahl • (fortlaufende Erweiterung des Samples gemäß der für die Theoriebildung wichtigen Überlegungen) Typenbildung im Sinne von Repräsentanz (d.h. typische Vertreter, nicht Repräsentativität) Auffinden des Allgemeinen im Besonderen Exemplarische Verallgemeinerung durch Abstraktion (Wesentliches und Unwesentliches trennen)

Statistische Repräsentativität Zufallsauswahl Bedinger Rückschluß vom Teil (Stichprobe) auf das Ganze (Grundgesamtheit), unter der Voraussetzung von Objektivität, Validität und intersubjektiver Überprüfbarkeit

Tab. 2: Gütekriterien an Evaluationsverfahren (in Anlehnung an [MÜI199], [MiHu94])

Damit den Gütekriterien entsprochen werden kann, empfehlen [MiHu94] und [Poul90] bei der Anwendung von qualitativen Evaluationsverfahren die Beantwortung von Fragen, die über die Einhaltung dieser Kriterien Auskunft geben, beispielsweise was Objektivität und Nachvollziehbarkeit betrifft: • Wurden die in der Evaluationsstudie eingesetzten Verfahren und Methoden explizit und im Detail dokumentiert? • Kann nachvollzogen werden, wie die Daten gesammelt, verarbeitet, zusammengefaßt, transformiert, „verrechnet" und zur Entscheidungsfindung aufbereitet wurden? • Können die Schlußolgerungen explizit aus den dargestellten Daten ableitet werden? • Sind rivalisierende Hypothesen und Schlußolgerungen entsprechend gewürdigt worden? Die Einhaltung der Reliabilität läßt sich beispielhaft mit folgenden Fragen kontrollieren: • Sind die Evaluationsfragen eindeutig formuliert und stimmen die Struktur und der Ablauf der Evaluationsstudie mit diesen Fragen überein? • Sind die Rollen der evaluierenden Personen, der Forscher, die in diesem Prozeß auftreten, eindeutig festgelegt und beschrieben? • Sind die grundsätzlichen Paradigmen und analytischen Konstrukte, die dem Evaluationsproblem zugrunde liegen (z.B. Benutzbarkeit bei Software-Produkten) eindeutig gekennzeichnet und lassen sie sich in ausreichender Weise theoretisch begründen? • Stimmen die Aussagen verschiedener Beobachter (z.B. bei Szenariobasierten Checklisten im Rahmen von Usability-Tests bei der SoftwareEntwicklung) überein?

220

Gerhard A, Wiihrer

Zweifellos kann die konsequente Orientierung an Kriterien zur Beurteilung von qualitativen und quantitativen Evaluationsverfahren die Bewertungs- und Prognosequalität in solchen Abläufen steigern. D i e in den folgenden Beiträgen gezeigten Beispiele zur Evaluation von Software-Technologien bestätigen dies. Allerdings muß darauf hingewiesen werden, daß die Anwendung solcher Methoden auch unter den Zielen von Effektivität und Effizienz zu erfolgen hat. Bestrebungen zur Evaluation von Technologien müssen aber und dies ist nicht überraschend - generell vor dem Hintergrund der Entwicklung der Strukturen und der Anwendung sozialwissenschaftlicher Theorien gesehen werden (vgl. [Albe64]).

Literatur [Albe64] Albert, H.: Probleme der Theoriebildung - Entwicklung von Struktur und A n w e n d u n g sozial wissenschaftlicher Theorien. In: Albert, H. (Hrsg.): Theorie und Realität. Tübingen 1964, 3 - 7 9 [Arch92] Archibald, R. D.: Managing High-Technology Programs and Projects. Chichester 1992 [ A n s o 8 1 ] A n s o f f , H. J.: Die Bewältigung von Überraschungen und Diskontinuitäten durch die U n t e r n e h m e n s f ü h r u n g . Strategische Reaktionen auf schwache Signale. In: S t e i n m a n n , H. (Hrsg.): Planung und Kontrolle. M ü n c h e n 1981, 233 - 264 [Back97] Backhaus, K.: Industriegütermarketing. München 1997 [Bull94] Bullinger, H.-J.: Einführung in das Technologiemanagement. Modelle, Methoden, Praxisbeispiele. Stuttgart 1994 [DaWe95] D a y , G. S. / W e n s l e y , R.: Assessing advantage: a f r a m e w o r k of diagnosing competitive superiority. In: Littler, D. / Wilson D. (eds): Marketing Strategy. Oxford 1995, 125 - 158 [ElKr94] Elbling, O. / Kreuzer, Ch.: Handbuch der strategischen Instrumente. W i e n 1994 [ E w a l 8 9 ] Ewald, A. / Ewald, Α.: Organisation des strategischen Technologie-Managements. Stufenkonzept zur Implementierung einer integrierten Technologie- und Marktplanung. Bielefeld 1989 [ G e r p 9 9 ] Gerpott, T . J.: Innovations- und Technologiemanagement. In: Bitz, M. et al. (Hrsg.): Vahlens K o m p e n d i u m der Betriebswirtschaftslehre. M ü n c h e n 1999, 289 - 338 [Hein99] Heinrich, L. J.: Informationsmanagement. München/Wien 1999 [ K e S c h 7 7 ] Kern, W . / Schröder, H.-H.: Forschung und Entwicklung in der U n t e r n e h m u n g . H a m b u r g 1977 [ M i H u 9 4 ] Miles, Μ. Β. / H u b e r m a n , Μ. Α.: Qualitative Data Analysis. An Expanded S o u r c e b o o k . London et al. 1994 [MÜ1199] Müller, St.: Grundlagen der Qualitativen Marktforschung. In: H e r r m a n n , A. / H o m b u r g , Ch. (Hrsg.): Marktforschung - Methoden - A n w e n d u n g e n - Praxisbeispiele. W i e s b a d e n 1999, 1 2 8 - 157 [o.V.99] O.V.: Usability Evaluation Methods

[ P o p p 7 2 ] Popper, K. R.: Naturgesetze und theoretische Systeme. In: Albert, H. (Hrsg.): Theorie und Realität. Tübingen 1972, 4 3 - 58 [Poul90] Poulton, M. C.: A Land Use Evaluation Technique for Decision Makers. In: D y s o n , R. G.: Strategic Planning: Models and Analytical Techniques. Chichester/New York 1990, 2 6 9 - 2 8 5

Evaluation der Technologieanwendung und des Technologiemanagements Mohsen Rezagholi / Michael Frey [email protected] / [email protected]

Zentralabteilung Technik, Software und Engineering, Siemens AG München www.siemens.de/de

Inhalt 1 2 3 4 5

Zielsetzung und Motivation Verfahrensüberblick Technologie-Evaluierung Verwendung der Evaluierungsergebnisse Einsatzerfahrungen

Zusammenfassung Erfolgreiche Projekte in Zeiten raschen technologischen Wandels erfordern die konsequente Ausrichtung von Produkt- und Prozeßtechnologien auf Marktbedürfnisse und Wirtschaftlichkeit. Das Verfahren MEPT (Managing Engineering and Product Technology) unterstützt diese Fokussierung durch Ermittlung des technologischen Handlungsbedarfs auf der Grundlage einer systematischen Analyse und Bewertung der technologischen Position und des gelebten Technologiemanagements. MEPT wurde von der Zentralabteilung Technik der Siemens AG entwickelt. Der Beitrag erläutert das Verfahren und seinen Einsatz zur Evaluation der Technologieanwendung und des Technologiemanagements.

Abstract In times of rapid technological changes, successful projects require product and engineering technologies to be strictly focussed on efficiency and market needs. MEPT (Managing Engineering and Product Technology) supports this focus by analyzing and assessing an organization's technological position as well as its applied technology management process. MEPT was developed by Corporate Technology of Siemens AG. This article gives a survey of MEPT and its application for technology assessment.

222

Mohsen Rezagholi / Michael Frey

1 Zielsetzung und Motivation Unternehmen, in denen Technologieanwendung und Technologiemanagement den Unternehmenserfolg entscheidend beeinflussen, müssen adäquate Antworten auf Fragen folgender Art geben: • Welche Technologien werden wann benötigt, um erfolgreiche Produkte definieren und entwickeln zu können? • Welche Technologien sind selbst zu beherrschen, welche können zugekauft werden? • Welche Technologien müssen substituiert bzw. „ausgephast" werden? • Wie sollen die (F&E-)Ressourcen ausgerichtet werden? • Wie kann der organisationsspezifische Prozeß des Technologiemanagements optimiert werden, um technologische Innovationen langfristig sicherzustellen? Um derartige Fragen beantworten zu können, bedarf es eines Verfahrens, mit dem die Fähigkeit einer Organisationseinheit verbessert wird, ihren künftigen Technologiebedarf konsequent zu ermitteln, entsprechende Technologien zu beschaffen und kontrolliert einzusetzen. Ein solches Verfahren ist Managing Engineering and Product Technology (MEPT). Im Unterschied zu vergleichbaren Verfahren zeichnet sich MEPT besonders dadurch aus, daß es eine detaillierte Bewertung der Technologieanwendung anhand von Faktoren ermöglicht, die einen direkten Bezug zu den Erfolgsfaktoren der betrachteten Organisationseinheit haben. Zudem erlaubt MEPT eine kombinierte Evaluierung der Technologieanwendung und des Technologiemanagements, wodurch die Effektivität und Effizienz der Technologieanwendung im Licht der Qualität des Technologiemanagements betrachtet werden kann und umgekehrt. Der besondere Nutzen des MEPT-Einsatzes für eine Organisationseinheit kann folgendermaßen zusammengefaßt werden: • Steigerung der Wettbewerbsfähigkeit durch Fokussierung von Produkttechnologien und Prozeßtechnologien (Engineering-Technologien) auf Kundennutzen und Wirtschaftlichkeit. • Rechtzeitiger Einsatz neuer Technologien bzw. rechtzeitiges „Ausphasen" unwirtschaftlicher bzw. obsoleter Technologien durch Aufzeigen des technologischen Entwicklungs- und Substitutionspotentials. • Effiziente Verwendung von Ressourcen durch Konzentration auf Kerntechnologien.

2 Verfahrensüberblick Kernstück des Verfahrens ist die Technologie-Evaluierung. Die notwendigen Informationen für die Evaluierung liefert eine Analyse der Anwendungsdomäne. Diese dient der systematischen Erfassung angewandter und für die jeweilige Domäne verfügbarer Technologien, der Erfassung von technolo-

Evaluation der Technologieanwendung

und des Technologiemanagements

223

gisch relevanten Zielen und Strategien sowie der Erfassung und Analyse technologischer Trends und Anforderungen des Marktes (vgl. Abbildung 1).

Γ

Markt

Anforderungen

Γ

Verfügbare Technologien

Technologie-Evaluierung

Stärken- / Schwächen-Profil

Ä W

Produkte, Architekturen und Entwicklungsprozeß

Abb. 1 : MEPT im Überblick Die Technologie-Evaluierung setzt sich wie folgt zusammen: 1. Evaluierung der Technologieanwendung, in deren Rahmen die Bedeutung einzelner Prozeß- und Produkttechnologien für die betrachtete Organisationseinheit und ihre Kunden ermittelt wird. 2. Evaluierung des gelebten Technologiemanagement-Prozesses hinsichtlich Qualität und Effektivität. Die Bewertungsergebnisse ergeben das Stärken-ZSchwächen-Profil der Organisationseinheit hinsichtlich der Technologieanwendung und des Technologiemanagements und sind Grundlage für die Ableitung von Verbesserungsmaßnahmen. Im folgenden werden die Verfahrensschritte von MEPT dargestellt.

3 Technologie-Evaluierung 3.1 Analyse der Anwendungsdomäne Die Analyse der Anwendungsdomäne zielt auf die Ermittlung von Produktund Prozeßtechnologien sowie die Ermittlung technologisch relevanter Geschäftsstrategien, Marktanforderungen und Trends ab. Sie legt damit den Umfang der Evaluierung der Technologieanwendung in einer Organisationseinheit fest (vgl. Abbildung 2). Die angewandten Produkt- und Prozeßtechnologien werden durch Befragung von Technologieexperten der Organisationseinheit ermittelt. Gegebenenfalls

224

Mohsen Rezagholi / Michael Frey

kann auf Produktdekomposition als methodische Unterstützung zurückgegriffen werden. Zunächst werden die Produkte der Organisationseinheit mit dem höchsten Ergebnisbeitrag ausgewählt (z.B. mit einer ABC-Analyse) und in ihre Hardware- und Software-Bestandteile zerlegt. Anschließend wird f ü r die einzelnen Bestandteile ermittelt, welche Technologien sie enthalten (Produkttechnologien) oder durch Anwendung welcher Technologien sie entwickelt wurden (Prozeßtechnologien) [Pfei83,80]. Ermittlung ProduktTechnologien

Ermittlung ProzeßTechnologien

Erfassung technologischer Trends

Produkte

Angewandte Technologien

Engineering-Aktivitäten Markt-Informationen

Analyse der Anwendungsdomäne

Verfügbare Technologien Technologie-Trends, Anforderungen

Ziele und Strategien

Ο Management

Experten der Anwendungsdomäne

Abb. 2: Analyse der Anwendungsdomäne: Inputs, Analyse-Aktivitäten, Beteiligte, Outputs

Zur Erfassung von am Markt verfügbaren Technologien sowie zur Erfassung technologischer Trends werden neben internen auch externe Experten der Anwendungsdomäne befragt. Unterstützend findet eine Analyse einschlägiger Dokumente, insbesondere von Untersuchungsberichten, statt. Die identifizierten Produkt- und Prozeßtechnologien werden einzeln beschrieben. Jede Technologiebeschreibung gibt genaue Auskunft über die spezifische Anwendung und Ausprägung der Technologie in der Organisationseinheit, über Alternativ- und Komplementärtechnologien, über Ziele und Strategien hinsichtlich der Technologieanwendung und gegebenenfalls über Kooperationen mit Technologielieferanten (vgl. Abbildung 3). Beispielsweise wurden bei einer konkreten Anwendung des Verfahrens folgende Technologien identifiziert und beschrieben: 2D-Image Processing, Volume Visualization, Networked Image Processing, Hardware Acceleration, Componentware, Framework und Design Patterns. Im Rahmen der Analyse der Anwendungsdomäne werden ferner die Geschäftsstrategien hinsichtlich der Vermarktung der Produkte und des Aufbzw. Ausbaus technologischen Know-hows erfaßt. Diese zusätzlichen Informationen werden durch Interviews mit dem oberen Management der Organisationseinheit ermittelt; sie sind unabdingbare Voraussetzung zur Beurteilung der Bedeutung der identifizierten Technologien.

Evaluation der Technologieanwendung

und des Technologiemanagements

SIEMENS

225

^ . „_

Analysis of Application Domain

Technology: < Name > Description: < Detailed description

of Technology's

application

Range of application: < Actual and potential fields of application

>

Goals & strategy: < Future development of technology in general; goals A strategies according to technology roadmap

Cooperation partners: < Actual &. planned cooperations

>

>

for the use and development

Substitutive technologies: < Alternative technologies; technologies (according to trends) >

of the technology

>

which might replace the applied technology

Joint technologies < Technologies affected by decisions concerning the applied technology. technologies which might support the applied technology in future (according

in future

to trends) >

© Siemens AG, 1999 confidential ZTSE

Abb. 3: Vorlage für die Technologiebeschreibung

3 . 2 Evaluierung der Technologieanwendung Bei der Evaluierung der Technologieanwendung wird die Bedeutung der identifizierten Technologien für die Organisationseinheit ermittelt. Ziel ist es, die Entscheidung für den Einsatz neuer oder die Substitution veralteter Technologien sowie die Zuordnung von Ressourcen zum Auf- bzw. Ausbau technologischen Know-hows in der Organisationseinheit zu unterstützen. Um die Evaluierung nicht auf eine Momentaufnahme zu reduzieren, sondern eine Beurteilung der Technologien im Zeitverlauf zu ermöglichen, wird ein Prognosehorizont festgelegt, der sich insbesondere am Lebenszyklus der Produkte und untersuchten Technologien orientiert. Für die Evaluierung der im Beispiel genannten Technologien wurde ein Prognosehorizont von drei Jahren festgelegt. Die Evaluierung erfolgt dann für den aktuellen Zeitpunkt und den festgelegten Prognosehorizont - im genannten Beispiel also für die Zeitpunkte 1998 und 2001. Die Evaluierung der Technologieanwendung beinhaltet zwei interdependente Einzelanalysen: Die Technologieanalyse bezieht sich auf einzelne Technolo-

226

Mohsen Rezagholi / Michael Frey

gien und wird im Rahmen von Workshops unter Beteiligung von Technologieexperten aus der Organisationseinheit und deren Umfeld durchgeführt. Bei Bedarf werden externe Wissensträger der Anwendungsdomäne einbezogen. Mit der Marktanalyse wird die Kundensicht auf Produkte, in denen die Technologien enthalten sind, eingeholt. Wenn eine direkte Beteiligung von ausgewählten Kunden nicht möglich ist, werden die Funktionsträger der Organisationseinheit, welche die Kundensicht einnehmen können (Personen aus Marketing oder Vertrieb) in die Untersuchung einbezogen. Technologieanalyse Im Rahmen der Technologieanalyse werden die identifizierten Technologien einzeln hinsichtlich ihrer Attraktivität, d.h. hinsichtlich ihres Beitrags zur Erzielung von Wettbewerbsvorteilen, bewertet. Ferner wird die Position der Organisationseinheit bezüglich der betrachteten Technologien bewertet. Die Bewertung erfolgt anhand von Kriterien, die im Vorfeld der Untersuchung im Hinblick auf die speziellen Erfordernisse der Anwendungsdomäne und der Organisationseinheit festgelegt werden. Beispiele für Kriterien zur Bewertung der Technologieattraktivität sind (vgl. [Grad92], [IEEE92], [Jone91,253-301], [Sage95,176-398]): • Beitrag der Technologie zur Kostensenkung, Qualitätsverbesserung und Reduktion der Entwicklungszeit (Herstellernutzen) sowie Beitrag der Technologie zum Preis-/Leistungsverhältnis (Kundennutzen); • Gefahr des Auftretens substituierender Technologien sowie Verfügbarkeit komplementärer Technologien; • Technologisches Entwicklungspotential: Verhältnis Wertzuwachs zu Mittelaufwand, Position der Technologie im Technologielebenszyklus, Möglichkeit zur Steigerung der Leistungsfähigkeit der Technologie; • Technologieakzeptanz auf dem Markt (Zeitraum seit Markteintritt, Verbreitungsgrad der Technologie, Konformität mit bestehenden Standards); • Beitrag der Technologie zur Verbesserung der Zuverlässigkeit, Wiederverwendung, Offenheit oder Konfigurierbarkeit. Die technologische Position der Organisationseinheit wird durch deren Ressourcenstärke hinsichtlich der betrachteten Technologien determiniert. Die Ressourcenstärke leitet sich aus der Verfügbarkeit und Stabilität des Know-hows, des Personals und der Finanzen im Vergleich zum stärksten Mitbewerber (nicht notwendigerweise Marktführer) ab. Jede Technologie wird hinsichtlich der festgelegten Kriterien auf einer Ordinalskala von 1 (gering) bis 4 (hoch) sowohl aus aktueller Sicht als auch für den festgelegten Zeithorizont bewertet. Die Technologieexperten müssen jede Bewertung im Konsens begründen (vgl. Abbildung 4). Zur Visualisierung der Ergebnisse werden die Bewertungen in einem Portfolio zusammengefaßt, das durch die Dimensionen Technologieattraktivität und relative Technologieposition aufgespannt wird ([Pfei83,85-92], [PfWe95], vgl. Abbildung 5). Die Position einzelner Technologien im Portfolio errechnet sich als gewichteter Mittelwert der Einzelbewertungen. Das Portfolio zeigt die Entwicklung jeder Technologie vom aktuellen Zeitpunkt bis zum festgelegten Prognosehorizont.

Evaluation der Technologieanwendimg

und des Technologiemanagements

227

SIEMENS

Analysis of Application Domain

Evaluation factors D e v e l o p m e n t potential

Attractivity (Contribution tu competitive advantage) weight Evaluation* Motivation high (1 to 5) low 1 2 3 4

C o n t r i b u t i o n to quality (testability, r e d u c t i o n of defects)

1 1

2

3

4 1

C o n t r i b u t i o n to cost reduction

1 1

2

3

4 i

Availability of j o i n t technologies

1 1

2

3

4 I

Customer acceptance

1 1

2

3

4 1

< additional

1 1

2

3

4 1

factors

>

Evaluation factors Know-how

Technological Position (Compared to main competitor) weight Evaluation* leads (1-5) lags 1 2 3 4 1 1

H u m a n resources

1 1

2

3

4

Financial r e s o u r c e s

1 1

2

3

4 1

1 1

2

3

4 1

< additional

factors

>

Motivation

1

* Please use • to evaluate the actual position of the technology according to the specified factors • to prognosticate the position of the technology according to the specified factors on the appointed evaluation horizon • if the actual position corresponds to the future position ® Siemens AG, 1999 confidential ZTSE3

Abb. 4: Vorlage für die Technologieanalyse

Aus der Gegenüberstellung der Bewertungen mit der beschriebenen Technologieanwendung (siehe Abschnitt 3.1) werden erste Erkenntnisse darüber gewonnen, ob die entsprechende Technologie zielführend konkretisiert wurde. Gegebenenfalls werden Maßnahmen zur Verbesserung der Technologieanwendung definiert. Anhand der aktuellen und der für den Prognosehorizont ermittelten Position der Technologien im Portfolio können spezifische Technologiestrategien der Organisationseinheit überprüft und weitere technologiebezogene Maßnahmen abgeleitet werden. Insbesondere können der geplante Ressourceneinsatz sowie die technologische Ausrichtung der Organisationseinheit analysiert werden (siehe das vereinfachte fiktive Beispiel in Abbildung 5).

228

Mohsen Rezagholi / Michael Frey

Die Technologieanalyse dient damit der produktunabhängigen Bewertung von Technologien. Da das Geschäftsergebnis aber vom Erfolg der Produkte, als Ergebnis der Technologieanwendung, abhängig ist, erfolgt im nächsten Schritt eine produktabhängige Technologiebewertung - die Marktanalyse. ι

hoch

-:"τ""ν Ύ Ξ>

(Ξ

ë'Ê 1E

1

i

H l

> ^

Ο E; Κ

©

ÉM k

• •

t:;; Η

Vorsprung Relative Technologieposition

•

Halten des Technologischen Vorsprungs; da es sich i.d.R. um Technologien mit starkem Bezug zu Kernkompetenzen handelt. Selektive Entscheidung je nach TrendsAussagen, ζ. B.: - Verbesserung der eigenen Technologieposition bezüglich T1 durch Ressourcenkonzentration - Nutzung des technologischen Vorsprungs bezüglich T3; keine Investitionen mehr, sondern Freisetzung von Ressourcen - Ressourcenfreisetzung bezüglich T4, falls keine Basistechnologie Ausstieg, falls keine positive Entwicklung der Technologieattraktivität zu erwarten. Hierbei sind interdependenzen mit anderen Technologien zu beachten.

Legende: (^J^)

aktuelle Position einer Technologie

ν Τ ..

eingeschätzte Position einer Technologie am Ende des Prognosezeitraums Technologieposition bleibt im Prognosezeitraum unverändert

Abb. 5: Zusammenfassende Darstellung der Ergebnisse der Technologieanalyse im Portfolio

Marktanalyse In der Marktanalyse werden die bei der Analyse der Anwendungsdomäne ausgewählten Produkte hinsichtlich ihrer Marktattraktivität bewertet und ihrem relativen Marktanteil gegenübergestellt. Die Marktanalyse vervollständigt die Ergebnisse der Technologieanalyse (vgl. auch [Wolf94,228-231]). Die im Rahmen der Technologieanalyse abgeleiteten Maßnahmen können nun im Spannungsfeld von Technology-Push und Market-Pull überprüft und es können gegebenenfalls neue technologiebezogene Strategien definiert werden. Zusätzlich können anhand der Position der Produkte Empfehlungen hinsichtlich der Produktstrategie abgegeben werden. Die Bewertung erfolgt anhand von Kriterien, die vor jeder Untersuchung an die Gegebenheiten der Organisationseinheit und des Marktes angepaßt werden. Kriterien zur Bewertung der Marktattraktivität sind beispielsweise (vgl. [Grad92], [IS091], [Jone91,253-301], [Sage95,176-398]): • Position des Produkts im Lebenszyklus und Dauer des Produktlebenszyklus, • Robustheit, Erweiterbarkeit und Flexibilität, • Performance hinsichtlich Zeit und Ressourcen,

Evaluation der Technologieanwendung

und des Technologiemanagements

229

• Benutzbarkeit, • Liefertreue, • Kosten/Nutzen-Verhältnis. Der relative Marktanteil bezieht sich auf den Anteil am Gesamtmarktumsatz im Vergleich zum stärksten Konkurrenten (nicht notwendigerweise Marktführer). Der ΒewertungsVorgang entspricht dem der Technologieanalyse. Das Ergebnis der Marktanalyse wird ebenfalls in einem Portfolio visualisiert. Das Portfolio wird durch die Dimensionen Marktattraktivität und relativer Marktanteil aufgespannt. Im Portfolio der Marktanalyse wird analog zur Technologieanalyse neben der aktuellen Position jedes Produkts auch die erwartete Position des Produkts am Prognosehorizont aufgezeichnet. Diese Position ergibt sich aus dem angestrebten Marktanteil und der prognostizierter Marktattraktivität für einzelne Produkte. Abbildung 6 zeigt anhand eines vereinfachten fiktiven Beispiels die Spiegelung der technologiebezogenen Maßnahmen an der Marktposition der Produkte.

igHBi lñ ZÜ7

2.S

Ü7

•

•

Ë 7-

Relativer Marktanteil

Legende:

Ξ

aktuelle Position eines Produkts

/"p7 /....„/

eingeschätzte Position eines Produkts am Ende des Prognosezeitraums

iFiqi i^J

Produktposition bleibt im Prognosezeitraum unverändert

•

Aus technologischer Sicht kein Handlungsbedarf bei P1, insbesondere wenn die eingesetzten Technologien beherrscht werden. Überwachung von Trends hinsichtlich Substitutionstechnologien für den rechtzeitigen Umstieg notwendig Selektive Entscheidung je nach TrendsAussagen, ζ. B.: - Technologie-Investitionen bei P3 sinnvoll, um von der positiv prognostizierten Entwicklung zu profitieren. - Keine zusätzlichen Aufwände für den Technologieeinsatz bei P4, da keine positive Entwicklung der Marktattraktivität und -anteil erkennbar. Vorhandenes Marktpotential abschöpfen, danach Übergang in Ausphase Es ist anhand der Position der eingesetzten Technologien zu überprüfen, ob die Position des Produkts technologisch bedingt ist oder der Handlungsbedarf eher auf Produktseite liegt.

Abb. 6: Zusammenfassende Darstellung der Ergebnisse der Marktanalyse im Portfolio

3.3 Evaluierung des Technologiemanagements Die Evaluierung des Technologiemanagements dient der Ermittlung des Beherrschungsgrads und damit der Qualität des gelebten Technologiemanagements. Ziel der Evaluierung ist es, die kontinuierliche Ausrichtung der Technologiekompetenz der Organisationseinheit an neue Technologieentwicklungen und Marktanforderungen sicherzustellen.

230 Mohsen Rezagholi / Michael Frey

Die Evaluierung des Technologiemanagements entspricht einem Benchmarking. Die notwendigen Informationen über den gelebten Prozeß werden durch Interviews mit dem Management und Technologie-Experten der Organisationseinheit gewonnen. Grundlage der Interviews ist ein Fragenkatalog, der auf Basis von best practices erstellt wurde. Der Fragenkatalog enthält ca. 35 Fragen mit Bewertungskriterien zu folgenden Schlüsselaktivitäten (vgl. [Hump89], [Korn95], [Lowe95], [Paul93], [Tril94]): • Technologiebezogene Geschäftsfeldsteuerung: Bereitschaft des Managements zur technologischen Innovation, Definition und Kommunikation der Geschäftsstrategien und deren Auswirkung auf die Produkt- und Technologie Roadmap; • Prozeßdefinition: Definition und Pflege eines Prozesses für das Technologiemanagement (Prozeßschritte, Verantwortlichkeiten, Methoden und Standards); • Know-how-Transfer: Allokation technologischen Know-hows innerhalb der Organisationseinheit, Know-how-Transfer zwischen der Organisationseinheit und deren Technologielieferanten und Kunden, Sicherung von Kemkompetenzen; • Identifikation von Technologien: Systematik bei der Identifikation eingesetzter bzw. verfügbarer Technologien, Markt- und Konkurrenzbetrachtung, Analyse von Technologie-Trends; • Bewertung und Auswahl von Technologien: Methodik der Bewertung von Technologien, Nutzenbetrachtung von Technologien, Vorgehen bei der Technologieauswahl ; • Beschaffung und Implementierung von Technologien: Systematik zur Make or Buy-Entscheidungsfindung, Management von Technologielieferanten, Aufbereitung von Technologien für die Integration (Erprobung vor Breiteneinführung); • Technologie-Controlling: Review der Aktivitäten durch das Management, Verfolgung der Umsetzung von Review-Ergebnissen, Evaluierung der Technologieanwendung und des Technologiemanagements, Messen von Qualitäts- und Produktivitätsauswirkungen neuer Technologien, Prämissenkontrolle. Die Festlegung des Beherrschungsgrads bezüglich einzelner Aktivitäten erfolgt in Anlehnung an das vom European Quality Award (EQA) verwendete Schema. Der höchste Beherrschungsgrad liegt vor, wenn sichergestellt ist, daß die Organisationseinheit ihre technologische Erfolgsposition kontinuierlich verbessern kann. Sämtliche Aktivitäten des Technologiemanagements werden systematisch und methodengestützt vollzogen. Erfüllt das gelebte Technologiemanagement diese Anforderungen nicht, hat dies eine entsprechende Abstufung des Beherrschungsgrads zur Folge. In einem Cobweb-Diagramm wird der Erfüllungsgrad der einzelnen Themen aufgezeichnet (vgl. Abbildung 7). Auf Basis der aus den Interviews gewonnenen Erkenntnisse werden Maßnahmen zur Verbesserung des Technologiemanagements abgeleitet.

Evaluation

der Technologieanwendung

Technologiebezogene Geschäftsfeldsteuei

100

und des Technologiemanagements

231

Identifikation von Technologien

Bewertung und Auswahl von Technologien

Prozeßdefinition Beschaffung und Implementierung von Technologien Know-how-Transfer Technologie-Controlling Abb. 7: Technologiemanagement-Profil

Die Ergebnisse der Evaluierung des Technologiemanagements werden den Ergebnissen der Evaluierung der Technologieanwendung gegenübergestellt, um zu überprüfen, ob Prozeßreife und Technologieposition miteinander korrespondieren.

4 Verwendung der Evaluierungsergebnisse Die Technologie-Evaluierung liefert zusammen mit dem Stärken-ZSchwächen-Profil einen Katalog von Maßnahmen zur Verbesserung der Technologieanwendung und des Technologiemanagements. Die Maßnahmen beziehen sich insbesondere auf folgende Sachverhalte: • Anpassung angewandter Technologien an organisatorische Erfordernisse und Marktbedingungen; • Einsatz zielkonformer Technologien; • Ersatz unwirtschaftlicher oder veralteter Technologien; • Neuausrichtung von (F&E-) Ressourcen; • Strukturierung des Technologiemanagements und des Innovationsprozesses. Die Maßnahmen sind Grundlage für die Definition eines Verbesserungsprogramms, das die Reihenfolge der Umsetzung der Maßnahmen festlegt und - neben einer genauen Termin- und Ressourcenplanung - Metriken zur Kontrolle der Zielerreichung enthält. Die Portfolios und das Cobweb-Diagramm im Stärken-/Schwächen-Profil können zur Darstellung der Technologiebeherrschung einer Organisationseinheit herangezogen werden. Die Evaluierungsergebnisse können ferner f ü r Benchmarking mit anderen Anwendungsdomänen bzw. Organisationseinheiten verwendet werden, sinnvollerweise für ein Benchmarking unter verschiedenen Organisationseinheiten eines Bereiches oder einer Domäne.

232

Mohsen Rezagholi / Michael Frey

5 Einsatzerfahrungen Die Erfahrungen aus dem bisherigen Einsatz des Verfahrens MEPT können folgendermaßen zusammengefaßt werden: •

•

•

•

MEPT ist für die Anwendung in der Praxis geeignet. Die abgeleiteten Maßnahmen sind durch die Orientierung der Evaluierung an den Erfolgsfaktoren der Organisationseinheit und die integrierte Betrachtung der Technologieanwendung und des zugrundeliegenden Prozesses abgesichert und werden von der evaluierten Organisationseinheit positiv aufgenommen. Die Vorgabe an die Technologieexperten, die Bewertungskriterien nicht nur mit einer Note von 1 bis 4 zu versehen, sondern die Benotung auch zu begründen, führt zu einer intensiven Betrachtung der einzelnen Technologien, bringt neue Erkenntnisse für die Organisationseinheit und liefert eine gute Basis für die Ableitung von Maßnahmen. Der Aufwand für die Evaluierung der Technologieanwendung korreliert stark mit der Anzahl der Bewertungskriterien. Es ist daher sinnvoll, die Anzahl der Bewertungskriterien auf maximal 20 zu begrenzen. Eine Verfälschung der Ergebnisse ist dadurch nicht zu erwarten. Die Portfolios und das Cobweb-Diagramm sind ein geeignetes Mittel zur Visualisierung des technologischen Profils einer Organisationseinheit.

Literatur [Grad92] Grady, R. B.: Practical Software Metrics for Project Management and Process Improvement. Englewood Cliffs/NJ 1992 [Hump89] Humphrey, W. S.: Managing the Software Process. Reading 1989 [IEEE92] IEEE Recommended Practice for the Evaluation and Selection of CASE Tools. I E E E S t d 1209-1992 [IS091] Information Technology - Software Product Evaluation - Quality Characteristics and Guidelines for their Use. ISO/IEC 9126-1991 [Jone91] Jones, C.: Applied Software Measurement - Assuring Productivity and Quality. New York et al. 1991 [Korn95] Kornwachs, Κ.: Identifikation, Analyse und Bewertung technologischer Entwicklungen In: Zahn, E. (Hrsg.): Handbuch Technologiemanagement. Stuttgart 1995 [Lowe95] Lowe, P.: The Management of Technology - Perception and Opportunities. London 1995 [Paul93] Paulk, M. C. et al.: Key Practices of the Capability Maturity Model, Version 1.1, CMU/SEI-93-TR-25, February 1993 [Pfei83] Pfeiffer, W. et al.: Technologie-Portfolio zum Management strategischer Zukunftsgeschäftsfelder. Göttingen 1983 [PfWe95] Pfeiffer, W. / Weiß, E.: Methoden zur Analyse und Bewertung technologischer Alternativen. In: Zahn, E. (Hrsg.): Handbuch Technologiemanagement. Stuttgart 1995 [Sage95] Sage, A. P.: Systems Management for Information Technology and Software Engineering. New York et al. 1995 [Tril94] Trillium - Model for Telecom Product Development & Support Process Capability. Bell Canada, 1994 [Wolf94] Wolfrum, B.: Strategisches Technologiemanagement. Wiesbaden 1994

Evaluation und Verbesserung wiederverwendungsorientierter Software-Entwicklung Gustav Pomberger [email protected]

Institut für Wirtschaftsinformatik der Universität Linz www.swe.uni-linz.ac.at

Mohsen Rezagholi / Christine Stobbe [email protected] / [email protected]

Zentralabteilung Technik, Software und Engineering, Siemens AG München

Inhalt 1 2 3 4 5

Einführung Ziele wiederverwendungsorientierter Software-Entwicklung Reifegradmodell für Wiederverwendung Assessment-Vorgehensmodell Anwendungserfahrungen

Zusammenfassung Der Beitrag beschreibt ein als Reuse Capability Maturity Model (RCMM) bezeichnetes Modell für den schrittweisen Wandel zu wiederverwendungsorientierter Software-Entwicklung. Das Modell geht von der in der Praxis üblichen Ad-hoc-Wiederverwendung von Software bzw. Software-Komponenten aus und definiert drei Phasen zur Integration der Wiederverwendung von Komponenten in den Software-Entwicklungsprozeß: (1) Systematisierung der Wiederverwendung verfügbarer Software, (2) Ausrichtung der Software-Entwicklung auf Anwendungsdomänen und (3) wiederverwendungsorientierte Produktentwicklung als Unternehmensstrategie. RCMM zeigt nicht nur einen Weg zur schrittweisen Verbesserung der Wiederverwendung, sondern ist auch Grundlage zur Identifikation und Bewertung des nicht ausgeschöpften Potentials zur Verbesserung der Produktivität und Qualität der Software-Entwicklung (Standortbestimmung). Neben der Beschreibung des RCMM wird daher ein Vorgehensmodell zur Durchführung der Standortbestimmung dargestellt, das als Reuse Capability Assessment Model (RCAM) bezeichnet wird. Abschließend wird ein Erfahrungsbericht über den Einsatz der Modelle gegeben.

Abstract This paper describes a model for stepwise transition to reuse-oriented software development. This Reuse Capability Maturity Model (RCMM) begins with the ad hoc reuse of software components, as we see in practice, and

234

Gustav Pomberger / Mohsen Rezagholi / Christine Stobbe

defines three phases for the integration of component reuse into the software process: (i) systematization of the reuse of available software, (ii) directing of software development to application domains, and (iii) Reuse-oriented product development as the enterprise strategy. RCMM not only shows a way for stepwise improvement of reuse, it also provides a basis for identifying and assessing the available potential for enhancing productivity and quality in software development. In addition to the description of RCMM, the paper contains an activity model, Reuse Capability Assessment Model (RCAM), f o r determining the actual reuse maturity. A report on experience in the use of the models rounds out the paper.

1 Einführung Daß die systematische Wiederverwendung einzelner, mehrfach getesteter Komponenten, Halbfabrikate oder Subsysteme im Software-Entwicklungsprozeß zur Verbesserung der Produktivität und Qualität führt und hilft, die Entwicklungszeit zu verkürzen und die Entwicklungskosten zu senken, ist unbestritten (vgl. u.a. [Lim94], [MaWe93]). Wegen des erwarteten Nutzenpotentials sind seit Beginn der 80er Jahre technologische und organisatorische Fragen zu wiederverwendungsorientierter Software-Entwicklung in den Mittelpunkt von Forschung und Entwicklung im Software Engineering gerückt. Die Ergebnisse liefern eine umfangreiche technologische Basis f ü r wiederverwendungsorientierte Software-Entwicklung, weisen aber im organisatorischen Bereich Lücken auf. Das Ausschöpfen des Nutzenpotentials wiederverwendungsorientierter Software-Entwicklung kann nur gelingen, wenn der Vielschichtigkeit des Wiederverwendungsprozesses Rechnung getragen wird. Die Etablierung eines wiederverwendungsorientierten Entwicklungsprozesses hängt primär davon ab, ob es gelingt, sowohl einen technologischen, als auch einen organisatorischen Wandel zu vollziehen. Voraussetzung dafür ist, daß technische, ökonomische und kulturelle Aspekte gemeinsam berücksichtigt werden. Wiederverwendungsorientierung muß Teil der Unternehmensstrategie sein, damit sie auf alle für die Software-Entwicklung relevanten Entscheidungen einen richtungsweisenden Einfluß ausüben kann (vgl. [CaCo94]). Die in diesem Beitrag beschriebenen Modelle basieren auf theoretischen Ansätzen zur Erhöhung der Wiederverwendbarkeit von Software und auf Erkenntnissen, die im Rahmen der industriellen Software-Wiederverwendung gewonnen wurden (vgl. [Beck92], [Isod92], [Paulk93], [Scha94], [IEEE94], [Brei94], [Same97]). Die Modelle sollen einsetzbar sein, • um den Reifegrad einer Organisation im Hinblick auf die Ausschöpfung des Nutzenpotentials wiederverwendungsorientierter Software-Entwicklung zu bestimmen, und • um den erforderlichen technologischen und organisatorischen Wandel zur wiederverwendungsorientierten Software-Entwicklung systematisch zu vollziehen.

Wiederverwendungsorientierte

Software-Entwicklung

235

2 Ziele wiederverwendungsorientierter Software-Entwicklung Ausgehend davon, daß Software-Entwicklungsprozesse nach dem Stand der Technik schwerer beherrschbar sind als Herstellungsprozesse für andere technische Produkte und davon, daß Software-Produkte im allgemeinen eine geringere Qualität als andere Produkte aufweisen, werden die Ziele, die durch wiederverwendungsorientierte Software-Entwicklung angestrebt werden, wie folgt festgelegt: • Produktivitätssteigerung. Durch verstärkte Verwendung zugekaufter oder eigenentwickelter Halbfabrikate oder fertiger Komponenten und durch Konzentration auf ein „Komponenten-Assembling" soll die Produktivität des Entwicklungsprozesses gesteigert werden. • Qualitätsverbesserung. Durch Verwendung bereits mehrfach getesteter, von Spezialisten entwickelter Komponenten soll die Qualität des SoftwareProdukts verbessert werden. • Kostensenkung. Durch Verkürzung der Entwicklungszeit und Verteilung der Komponentenkosten auf mehrere Produkte sollen die Herstellungskosten gesenkt werden. • Risikominderung. Durch Verringerung des Anteils an neu entwickeltem Programmcode sollen das Qualitäts-, Termin- und Kostenrisiko verringert werden. • Make&Buy-Balance. Durch Konzentration auf die Kernkompetenzen und Auslagerung der Entwicklung von Systemteilen, die nicht in den Bereich der Kernkompetenzen des Produktherstellers fallen, soll ein ausgewogenes Verhältnis zwischen Eigenentwicklung und Komponentenzukauf erreicht werden. Durch Kostensenkung und Verkürzung der time to market soll die Wettbewerbsfähigkeit erhalten bzw. gesteigert werden. • Anpaßbarkeit und Modularität. Durch Austauschbarkeit und inkrementelle Anpaßbarkeit von Komponenten sollen technologiegetriebene oder anforderungsbedingte Produktänderungen schneller und einfacher realisiert werden. Voraussetzung dafür ist eine modulare Software-Architektur. Um diese Ziele zu erreichen, genügt es nicht, den Programmcode (Objektcode oder Quellcode) wiederzuverwenden. Grundsätzlich eignet sich nahezu alles, was im Software-Entwicklungsprozeß entsteht, zur Wiederverwendung (im folgenden als Software-Artefakte oder Software-Komponenten bezeichnet). Mittel zur Zielerreichung sind daher die Wiederverwendung von Objektcode (z.B. Komponenten, Applets in Maschinen- oder Bytecode), Quellcode (z.B. Prozedur-, Modul-, Klassenbibliotheken, Frameworks), Mustern (z.B. Prozeß-, Design-Pattern, Referenzarchitekturen), Dokumenten (z.B. Spezifikationen, Entwurfs-, Produktdokumentationen) sowie Wissen, Erfahrung und speziellen Fähigkeiten der Entwickler. Unter erfolgreicher wiederverwendungsorientierter Software-Entwicklung wird die Ausschöpfung des Nutzenpotentials, das sich aus der Wiederverwendung von möglichst vielen Software-Artefakten ergibt, verstanden.

236

Gustav Pomberger/

Mohsen Rezagholi

/Christine

Stobbe

3 Reifegradmodell für Wiederverwendung Das Reuse Capability Maturity Model (RCMM) geht von der in der Praxis üblichen Ad-hoc-Wiederverwendung von Software-Komponenten aus und definiert drei Phasen zur Integration der Wiederverwendung von SoftwareArtefakten in den Software-Entwicklungsprozeß: (0) Ad-hoc-Wiederverwendung (1) Systematisierte Wiederverwendung verfügbarer SoftwareArtefakte (2) Domänenspezifische wiederverwendungsorientierte Software-Entwicklung (3) Wiederverwendungsorientierte Produktentwicklung als Unternehmensstrategie In Anlehnung an das Capability Maturity Model (CMM, vgl. z.B. [Hump89], [Paulk93]) stellen die Phasennummern auch die Reifegradstufe eines Unternehmens (bzw. einer Organisationseinheit oder eines Projekts) auf dem Weg zu wiederverwendungsorientierter Software-Entwicklung dar. Ebenfalls in Anlehnung an das CMM enthält die Modellbeschreibung für jede Phase bzw. Reifegradstufe folgende Abschnitte: Characteristics, Goals, Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, Verifying Implementation. Daraus resultieren sogenannte Reuse Key Practices (RKPs), die erfüllt sein müssen, um eine bestimmte Reifegradbestätigung zu erhalten. Die RKPs, deren Erfüllungsgrad beim Assessment ermittelt wird, sind in einem Fragenkatalog, der zu den Erhebungsformularen gehört, dokumentiert (vgl. Abschnitt 4.4). Aus Platz- und Wettbewerbsgründen kann keine vollständige Modellbeschreibung wiedergegeben werden (vgl. dazu [Reza95], [Hahn97]). Die Abschnitte 3.1 bis 3.4 beschreiben die durch das RCMM definierten Phasen so, daß die Modellkonzeption und die mit ihr verfolgten Ziele erkennbar sind. 3.1

Ad-hoc-Wiederverwendung

Seit Software professionell hergestellt wird, werden - wenn möglich - vorhandene Codeteile, Algorithmen oder Subsysteme zur Entwicklung neuer Software-Produkte verwendet. Ad-hoc-Wiederverwendung findet in jedem Unternehmen, das Software herstellt, und praktisch in jedem größeren Software-Projekt statt. Allerdings werden in der Regel keine Maßnahmen gesetzt, um die Art und den Prozeß der Wiederverwendung zu systematisieren. Wiederverwendung findet nur gelegentlich und in Abhängigkeit von der Arbeitsweise und der Erfahrung der Projektmitarbeiter unkoordiniert und meist undokumentiert statt. Auswirkungen der Wiederverwendungsaktivitäten werden weder quantitativ noch qualitativ so erfaßt, daß darauf aufbauend die Projektplanungs-, Projektsteuerungs- und Projektkontrollinstrumente gezielt weiterentwickelt werden können.

Wiederverwendungsorientierte

Software-Entwicklung

237

3 . 2 Phase 1: Systematisierte Wiederverwendung verfügbarer Software-Artefakte Sowohl zur Standortbestimmung als auch zur Einleitung des Übergangs von konventioneller zu wiederverwendungsorientierter Software-Entwicklung ist eine Reihe von Aktivitäten erforderlich. Die wichtigsten Aktivitäten in Phase 1 sind: • Erheben des Ausmaßes und der Art der Ad-hoc-Wiederverwendung, d.h. feststellen, wer, was, wann und wie wiederverwendet. • Identifizieren der Gründe, warum bestimmte Software-Artefakte neu entwickelt werden. • Feststellen, welches Know-how über Wiederverwendungstechnologien und mögliche Einsatzbereiche vorhanden ist. • Katalogisieren vorhandener wiederverwendbarer Software-Artefakte. • Beseitigen von Know-how-Defiziten im Bereich von Wiederverwendungstechnologien. • Bereitstellen eines Prozeßmodells für einen wiederverwendungsorientierten Software-Entwicklungsprozeß. • Bereitstellen einer Make-or-Buy-Prozedur zur Entscheidung über Eigenfertigung oder Fremdbezug von Software-Komponenten und Bereitstellung einer Beschaffungsprozedur für den Fremdbezug von Komponenten. • Identifizieren und abwickeln von Pilotprojekten mit Ex-ante- und Ex-postEvaluation der Zielerreichung. Von besonderer Bedeutung ist, daß das Prozeßmodell für die Software-Entwicklung so konstruiert ist, daß das Identifizieren von Komponenten, die fremdbezogen werden können, und ihre Verwendung in das Prozeßmodell integriert sind. Abbildung 1 zeigt ein solches Prozeßmodell, das durch Erweiterung des Spiralmodells nach [Boehm88] entstanden ist. Flankierende Maßnahmen in Phase 1 sind die Schaffung modularer Software-Architekturen, der Einsatz von Systembasen, die Einhaltung von Standards, die Institutionalisierung der Administration von Komponentenarchiven und das Schaffen eines Komponentenvorrats. Modulare Software-Architekturen Modulare Software-Architekturen zeichnen sich dadurch aus, daß die funktionalen Eigenschaften der Moduln, die ein Software-Produkt bilden, ausschließlich durch die Modulschnittstellen definiert sind, d.h. daß die Modulimplementierungen austauschbar sind und damit die Wiederverwendbarkeit und Austauschbarkeit einzelner Komponenten gefördert werden. Dazu müssen die Moduln bestimmte Kriterien erfüllen, insbesondere: Trennung von Schnittstelle und Implementierung, Einhaltung vorgegebener Modularisierungsrichtlinien (z.B. Interferenzfreiheit), Datenabstraktion (Information Hiding) und Eignung zum Black-Box-Test. Die Bildung modularer SoftwareArchitekturen und damit die wiederverwendungsorientierte Software-Entwicklung wird vor allem durch die Methodik objektorientierter SoftwareKonstruktion unterstützt (vgl. u.a. [Rumb93], [Wirfs93], [PoB196]).

238

Gustav Pomberger / Mohsen Rezagholi / Christine Stobbe Festlegung von Zielen, Nebenbedingungen und Einschränkungen

Kumulative Kosten

il

Erarbeitung und Evaluation von Lösungsvorschlägen,Identifikation Reuse-Potential, Erkennen und Beseitigen von Risiken

Abb. 1 : Prozeßmodell für wiederverwendungsorientierte Software-Entwicklung

Einsatz von Systembasen Eine Systembasis ist ein grundlegender Bestandteil eines Software-Systems, der Komponenten (z.B. Schnittstellen-Komponenten für verschiedene Betriebssysteme) umfaßt, die wegen ihrer Komplexität einen längeren Lebenszyklus haben sollen als andere, einfachere Komponenten. Auf solchen Systembasen setzt die Entwicklung verschiedener Produktvarianten auf. Systembasen sollen solange wie möglich vor Änderungen geschützt werden und müssen daher eine besonders hohe Qualität aufweisen. Neben der Entwicklung erleichtert die Verwendung von Systembasen die Wartung der Produktvarianten, da die Wartung gezielt auf variantenspezifischen oder gemeinsamen Teilen vorgenommen werden kann. Einhaltung von Standards Die Einhaltung von Standards (z.B. Interaktionsprotokolle, Schnittstellen, Programmiersprachen, Datenbankanbindung, Netzwerke) gewährleistet sowohl auf Komponenten- als auch auf Architekturebene die Austauschbarkeit von Komponenten, ermöglicht den Fremdbezug von Komponenten und begünstigt damit eine wiederverwendungsorientierte Software-Entwicklung. Neben der verstärkten Verwendung von Standards, die in Normen festgelegt sind (z.B. OSI-Referenzmodell), begünstigt die Verwendung von De-facto-

Wiederverwendungsorientierte

Software-Entwicklung

239

Standards (z.B. Java Application Programming Interface, API) und unternehmenspezifische Standards (z.B. Namenskonventionen) eine wiederverwendungsorientierte Software-Entwicklung. Institutionalisierung der Administration von Komponentenarchiven Das Komponentenarchiv nimmt bei wiederverwendungsorientierter Software-Entwicklung eine so zentrale Stellung ein, daß eine institutionalisierte Verwaltung angebracht ist. Sie regelt z.B. die Art der Archivierung, die Komponentenbereitstellung, das Konfigurations- und Dokumentationsmanagement von Komponenten und gibt Auskunft darüber, welche Komponente in welcher Version/Variante in welchem Produkt verwendet wurde (vgl. Abbildung 2).

Neuentwicklung

Testergebnisse, Fehlerkorrekturen

Test

— I Verwendung

Stabilisierungszyklus

Bereitstellung Zukauf

Qualitätsprüfung Reifeerklärung

S

Archivierung

Abb. 2: Administration des Komponentenarchivs

Schaffen eines Komponentenvorrats Die mögliche Verbesserung der Produktivität und Qualität hängt von der Art und Anzahl der für die Wiederverwendung verfügbaren Komponenten ab. Der Übergang zu einer wiederverwendungsorientierten Software-Entwicklung erfordert daher einen Komponentenvorrat. Es wird empfohlen, mit der Beschaffung von Komponenten zu beginnen, die von speziellen Anwendungsdomänen unabhängig sind (sog. Off the Shelf-Bibliotheken) und die daher unternehmensweit eingesetzt werden können. Der Beschaffungsprozeß erfordert die Beobachtung des Software-Marktes bzw. die Etablierung einer eigenen Komponentenfertigung. Darüber hinaus ist im Rahmen der Verwaltung des Komponentenarchivs ein Mechanismus zur Qualitätssicherung vorzusehen. Das Feststellen, ob für bestimmte funktionale Anforderungen Komponenten vorhanden sind, hängt von der Qualität der Komponenten-Dokumentation und den verfügbaren Suchwerkzeugen ab. Das Schaffen eines Komponentenvorrats impliziert daher auch die Bereitstellung eines Komponentenkatalogs und dazu gehörender Such- und Browsingmöglichkeiten.

240

Gustav Pomberger

/ Mohsen Rezagholi

3.3 Phase 2: Domänenspezifische Software-Entwicklung

/ Christine

Stobbe

wiederverwendungsorientierte

In Phase 1 werden - unabhängig von der Produktpalette, die entwickelt werden soll - die technischen und organisatorischen Voraussetzungen für eine wiederverwendungsorientierte Software-Entwicklung geschaffen. Pilotprojekte, die nach dem neuen Prozeßmodell abgewickelt werden, dienen dazu, das Mindestnutzenpotential wiederverwendungsorientierter Software-Entwicklung nachzuweisen und die Motivationsbasis für den Wandel zu liefern bzw. zu verstärken. In Phase 2 geht es darum, zusätzlich zum Mindestnutzenpotential das domänenabhängige Nutzenpotential auszuschöpfen und den Wandel weiter voranzutreiben. Ziel ist es, bei der Entwicklung von Software-Produkten in einer bestimmten Anwendungsdomäne (z.B. Software für Prozeßautomatisierung, Data Warehouse Systeme, Medizintechnik, Bankensoftware) zur Verbesserung der Produktivität und Qualität nicht nur einzelne „kleine" domänenunabhängige Komponenten (z.B. Benutzungsschnittstellen-Elemente, Datenhaltungskomponenten, Visualisierungskomponenten, Komponenten f ü r Betriebssystemschnittstellen) wiederzuverwenden, sondern darüber hinaus den Vorrat an wiederverwendbaren Komponenten auf domänenspezifische Bauteile (z.B. spezielle mathematische Modelle), Halbfabrikate (z.B. Frameworks für Prozeßsteuerung oder Finanzdienstleistungsprodukte) und/oder parametrierbare Standardsysteme auszudehnen. Unter der Voraussetzung, daß Phase 1 des RCMM abgeschlossen ist, sind die wichtigsten Aktivitäten zur Erreichnug dieses Ziels folgende: • Etablierung einer domänenspezifischen Komponentenentwicklung zur projektübergreifenden Unterstützung der Produktentwicklung. • Einrichtung eines Lenkungsausschusses, der für die strategische Ausrichtung der Komponentenfertigung und -Verwendung verantwortlich ist. (Mitglieder des Lenkungsausschusses sind in der Regel die Produktmanager und die für die Komponentenentwicklung Verantwortlichen.) • Erfassung des Aufwands für Komponentenbereitstellung (z.B. Entwicklungs-, Vertriebs-, Beratungs-, Pflege- und Verwaltungsaufwand) und Erfassung der Komponenten Verwendung. • Erweiterung der Aufgaben der für die Verwaltung des Komponentenarchivs zuständigen Institution (z.B. innerbetriebliche Vermarktung des Komponentenvorrats, Beratung der Produktentwickler-Teams, Verwendung von Verrechnungspreisen für Komponenten und Dienstleistungen, sammeln der von den Komponentennutzern kommenden Kritik, Wünsche und Anregungen und Weiterleitung an den Lenkungsausschuß). • Analyse projektspezifischer Software-Artefakte im Hinblick auf ihre Eignung zur Transformation in domänenspezifische oder domänenunabhängige wiederverwendbare Software-Artefakte. • Ausrichtung der Auftragsakquisition und der Produktvermarktung am domänenspezifischen Bestand an Halbfabrikaten und Komponenten. Der durch das Modell implizierten Vorgehensweise liegt die Annahme zugrunde, daß durch eine ausschließlich projektorientierte Organisations-

Wiederverwendungsorientierte

Software-Entwicklung

241

form das in einem Software herstellenden Unternehmen vorhandene Potential zur Verbesserung der Produktivität und Qualität nicht in vollem Umfang ausgeschöpft werden kann. Eine projektübergreifende Sichtweise zur Beseitigung produktivitäts- und qualitätsmindernder Prozeß- und Komponentenredundanz ist daher angebracht; sie findet im RCMM besondere Beachtung. Neben den flankierenden Maßnahmen der Phase 1 sind die kontinuierliche Durchführung von Domänenanalysen, der Einsatz von geeigneten Halbfabrikattechnologien, die Verwendung domänenspezifischer Styleguides und Wiederverwendungsanleitungen und die Schaffung einer geeigneten Kommunikationsinfrastruktur wichtige flankierende Maßnahmen der Phase 2. Domänenanalysen Eine systematische und in regelmäßigen Abständen wiederholte Untersuchung eines abgegrenzten Bereichs soll Hinweise darüber liefern, welche Komponenten (Produktteile, Teilsysteme) der verschiedenen Produkte (d.h. der Produktfamilie einer Anwendungsdomäne) gleich oder ähnlich sind und damit für eine Entwicklung als wiederverwendbare Komponenten in Frage kommen. Die wichtigste Aufgabe der Domänenanalyse besteht darin, ein Domänenmodell zu erarbeiten, das die Basis für eine verallgemeinerte und damit wiederverwendbare Systemarchitektur für die Produkte der untersuchten Anwendungsdomäne bildet. Einsatz geeigneter Halbfabrikattechnologien Halbfabrikate sind inkrementell erweiterbare oder parametrierbare Software-Komponenten, deren Funktionalität ohne Veränderung des Halbfabrikat-Quellcodes erweitert bzw. spezialsiert werden kann. Halbfabrikate können für elementare Komponenten, für Subsysteme und für ganze Systemarchitekturen (z.B. zur Implementierung eines Domänenmodells) entwickelt werden. Parametrierbare Komponenten sind mit konventionellen Programmiertechniken (z.B. prozedur- oder modulorientierte Programmierung) realisierbar. Sie haben den Nachteil, daß Funktionserweiterung und Funktionsspezialisierung nur in beschränktem Ausmaß (nämlich nur in dem Ausmaß, das der Komponentenentwickler festgelegt hat) möglich sind. Hingegen erlaubt die Realisierung der Halbfabrikate/Komponenten in objektorientierter SoftwareTechnologie eine inkrementelle Erweiterung bzw. Spezialisierung, ohne den bestehenden Quellcode ändern zu müssen. Vorteil der Anwendung dieser Technologie ist, daß die Flexibilität bezüglich Änderbarkeit und Erweiterbarkeit der Komponenten drastisch gesteigert werden kann und der bereits getestete Quellcode vor Fehlern, die bei Änderungen auftreten können, geschützt ist. Dies fördert die Wiederverwendbarkeit von Komponenten. Halbfabrikate im eigentlichen Sinn sind durch den Einsatz objektorientierter Software-Technologie möglich. Domänenmodelle mit hohem Wiederverwendungspotential werden am besten als Application Frameworks implementiert. Ein hohes Wiederverwendungspotential wird durch Einsatz objektorientierter, generischer und parametrierbarer Komponententechnologie erreicht.

242

Gustav Pomberger

/ Mohsen Rezagholi

/ Christine

Stobbe

Einsatz domänenspezifischer Styleguides und Wiederverwendungsanleitungen Styleguides geben Richtlinien und Konventionen vor, die bei der Entwicklung, Wartung und Dokumentation von Software zu beachten sind. Sie beruhen auf Erfahrungen aus Software-Projekten sowie auf wissenschaftlichen Erkenntnissen und berücksichtigen domänenspezifische Erfordernisse. Es ist zweckmäßig, zwischen Vorschriften und Empfehlungen in den Styleguides zu unterscheiden. Der Einsatz von Styleguides ist nicht nur eine konstruktive Maßnahme zur Qualitätssicherung, sondern erhöht auch die Wiederverwendbarkeit von Software-Artefakten, weil neben der Qualität die Verständlichkeit (Lesbarkeit) verbessert wird. Die Styleguides betreffen sowohl den Bereich der Komponentenentwicklung als auch den der Produktentwicklung. Neben dem Rückgriff auf externe Entwicklungen sollen bei der Definition der Styleguides die betroffenen Software-Ingenieure einbezogen werden. Dies sichert die an den Erfordernissen und Rahmenbedingungen der Anwendungsdomäne orientierte Zweckmäßigkeit der Styleguides und erhöht ihre Akzeptanz. Die Einhaltung der in den Styleguides festgelegten Vorschriften ist zu prüfen. Die Styleguides müssen in definierten Zeitintervallen aktualisiert werden. Wiederverwendungsanleitungen beschreiben, was Komponenten leisten und wie Komponenten verwendet werden sollen (Vorgehensweise, Einsatzbereiche). Im Idealfall existiert für jede Komponente eine Wiederverwendungsanleitung, die Beispiele für die Wiederverwendung enthält und hilft, eine fehlerhafte oder unprofessionelle Verwendung zu vermeiden. Ein einheitliches Dokumentationsschema sowie eine hypertext-basierte Dokumentation und entsprechende Werkzeuge unterstützen die Herstellung und Nutzung von Wiederverwendungsanleitungen. Wiederverwendungsanleitungen erleichtern den Einsatz wiederverwendbarer Software-Artefakte und ermöglichen eine bessere Ausschöpfung des Potentials zur Verbesserung der Produktivität, aber auch des Software-Vermögens eines Unternehmens, weil vorhandene Komponenten vielfach nur dann wiederverwendet werden, wenn ohne großen Aufwand feststellbar ist, ob und wie eine Komponente verwendbar ist. Schaffung einer geeigneten Kommunikationsinfrastruktur Das Ausmaß, in dem durch Wiederverwendung von Software-Artefakten das vorhandene Potential zur Verbesserung der Produktivität und Qualität ausgeschöpft werden kann, hängt auch von der Möglichkeit zur Bekanntmachung, Verteilung und Wartung des Komponentenvorrats ab. Es ist daher wichtig, daß zwischen Komponentenanwendern, Komponentenentwicklern und Komponentenvertreibern Erfahrung und Wissen ausgetauscht, FrageAntwort-Dialoge geführt und neue Qualitätsforderungen bzw. Qualitätsmängel erfaßt und an die zuständigen Instanzen weitergeleitet werden. Die Qualität der Kommunikationsinfrastruktur hat daher entscheidenden Einfluß

Wiederverwendungsorientierte

Software-Entwicklung

243

auf die Ausschöpfung des Erfolgspotentials wiederverwendungsorientierter Software-Entwicklung. Eine geeignete Kommunikationsinfrastruktur ist gegeben, wenn ausreichend viele und in ihrer Leistungsfähigkeit angemessene Informationskanäle (z.B. bezüglich Übertragungsgeschwindigkeit und Protokollierung), File Server zur Datenhaltung, Kommunikations- und Informationsdienste (z.B. E-MailSystem, Bulletin Boards, News-Dienste), Koordinations- und Kooperationsmechanismen (z.B. Cooperation Assistents, vgl. [AlPo99]) vorhanden sind. 3 . 4 Phase 3: Wiederverwendungsorientierte als Unternehmensstrategie

Produktentwicklung

In Phase 3 erfolgt die strategische Ausrichtung des Unternehmens auf wiederverwendungsorientierte (Software-)Produktentwicklung. Die auftragsspezifische Entwicklung von Software-Produkten und die Entwicklung neuer Produkte erfolgen primär durch Kombination von vorhandenen Komponenten, d.h. daß der Anteil individuell entwickelter Komponenten ist deutlich geringer als der vorgefertigter Komponenten. Wenn die Phasen 1 und 2 des RCMM abgeschlossen sind, dann sind zur strategischen Ausrichtung des Unternehmens auf wiederverwendungsorientierte Produktentwicklung folgende Aktivitäten am wichtigsten: • Erweiterung der Unternehmensstrategie. Die Unternehmensstrategie enthält Aussagen über die Ziele, die durch wiederverwendungsorientierte Software-Entwicklung errreicht werden sollen, und schreibt vor, welche Grundsätze zur Erreichung der Ziele eingehalten werden müssen. • Reorganisation der Marketing- und Vertriebsform. Alle Marketing-, Auftragsakquisitions-, Angebots- und sonstigen Vertriebsaktivitäten orientieren sich an den durch den Komponentenvorrat gegebenen Möglichkeiten zur Realisierung von Produktvarianten. • Etablierung von Bestands- und Lebenszyklusmanagement für Komponenten. Für jede Komponente wird die wirtschaftliche Lebensdauer geplant, die in die Phasen Einführung und Stabilisierung, Nutzung und Weiterentwicklung, Ablöse und Ersatz gegliedert ist. Die Bestandsführung enthält je Bestandsobjekt Anschaffungs- bzw. Herstellungszeitpunkt, Anschaffungs- bzw. Herstellungskosten, geplante Lebensdauer und Dauer der Phasen, Lebenszykluskosten geplant und tatsächlich. Die Informationen aus der Bestandsführung werden zur Steuerung der Auftragsakquisition und der Produktentwicklung verwendet. • Etablierung von Entwicklungs- und Beschajfungsmanagement für Komponenten. Die Entscheidung zwischen Eigenfertigung oder Fremdbezug wird auf Grund der Ergebnisse der Anwendung einer Make-or-Buy-Prozedur gefällt. Bei Eigenfertigung von Komponenten wird nach einem Vorgehensmodell, bei Fremdbezug wird nach einer Beschaffungsprozedur vorgegangen. Diese berücksichtigt, daß Komponenten verschiedener Lieferanten kombiniert werden können (sog. Cafeteria-Prinzip). • Etablierung eines Architekturmanagements für Referenzarchitekturen. Als Basis für die Produktentwicklung werden domänenspezifische Referenz-

244

Gustav Pomberger / Mohsen Rezagholi / Christine Stobbe

architekturen herangezogen, die zur Know-how-Sicherung und zum Erhalt der Wettbewerbsfähigkeit in Eigenfertigung hergestellt werden. Referenzarchitekturen sind generische Modelle von Produktfamilien, die zur Herstellung eines bestimmten Produkts inkrementell durch Hinzufügen anderer Komponenten und/oder durch Parametrierung spezialisiert werden können. Die Referenzarchitekturen unterliegen - wie alle anderen Komponenten - dem Bestands- und Lebenszyklusmanagement. • Ausbau des Qualitätsmanagements im Hinblick auf wiederverwendungsorientierte Software-Entwicklung. Zur Planung, Überwachung und Steuerung der Qualität im Produktentwicklungsprozeß einschließlich der vorgelagerten Entwicklungs- und Beschaffungsprozesse für Komponenten wird ein Qualitätsmodell verwendet, das die wichtigsten Prozeßeigenschaften beschreibt und angibt, wie sie gemessen werden. Das Qualitätsmodell berücksichtigt insbesondere Qualitätsmerkmale, die die Wiederverwendbarkeit von Software-Artefakten betreffen. • Einsatz von Kennzahlen zur Planung und Steuerung der Produktentwicklung und Komponentenbeschaffung. Durch Einführung und Anwendung von Controlling-Instrumenten werden Metriken (z.B. Wiederverwendungshäufigkeit, Anzahl Wiederverwendungen zur Erzielung eines bestimmten Deckungsbeitrags bei gegebenen Nutzungskosten, ReuseFaktor bezogen auf bestimmte Produktfamilien, Komponentenrestwert) gebildet, die eine kennzahlen-basierte Budgetierung, Planung und Steuerung der Produktentwicklungs- und Komponentenbeschaffungsprozesse ermöglichen. Die Metriken werden auch als Planungsinstrumente für die Festlegung der Lebensdauer und Lebenszyklusphasen von Komponenten sowie zur Ex-ante- und Ex-post-Evaluation von Technologieeinsatz-Entscheidungen und von Kosten/Nutzen-Relationen eingesetzter Komponenten herangezogen.

4 Assessment-Vorgehensmodell Das Assessment-Vorgehensmodell (RCAM) dient zur Steuerung und Standardisierung des Assessment-Prozesses mit dem Ziel, mit möglichst geringem Aufwand ein ausreichend klares Bild (Standort-/Reifegradbestimmung) über das vorhandene Potential zur Verbesserung der Produktivität und Qualität sowie zur Senkung der Kosten des untersuchten Software-Entwicklungsprozesses zu erhalten. Darüber hinaus sollen durch das Vorgehensmodell Assessment-Prozeß und Assessment-Ergebnis nachvollziehbar und ein möglichst objektiver Befund gewährleistet sein. Zwecke des Assessment-Vorgehensmodell sind also: • Regelung des Assessment-Prozesses durch Strukturierung in die Phasen Planung, Erhebung, Auswertung, Dokumentation und Definition der phasenspezifischen Arbeitspakete. • Beschreibung der Aufgaben der Assessoren und der an sie zu stellenden Qualifikationsanforderungen. • Beschreibung des Ablaufs der Erhebungsrunden. • Information zur Auswahl der Erhebungsdokumente und Interviewpartner.

Wiederverwendungsorientierte

Software-Entwicklung

245

• Vorgabe eines Erhebungs- und Bewertungssystems und Erläuterung der Erhebungs- und Auswertungsmethodik. Die vollständige Modellbeschreibung kann aus Platzgründen nicht wiedergegeben werden. Das RCAM ist aber so beschrieben, daß die Modellkozeption, die damit verfolgten Ziele und die Ergebnisse erkennbar sind. 4.1 Assessment-Struktur und Assessment-Prozeß Das Assessment wird in die Phasen Planung, Erhebung, Auswertung und Dokumentation der Ergebnisse strukturiert. Die Phasen sind in Arbeitspakete gegliedert, die sequentiell abgearbeitet werden. Die Inhalte der Arbeitspakete werden im folgenden durch Erläuterung ihrer Ziele beschrieben. Die Arbeitspakete der Planungsphase sind Grobplanung, Einarbeitung und Detailplanung. Ziel der Grobplanung ist es, den Zeitrahmen für den Assessment-Prozeß abzustecken, einen internen Assessor (vgl. Abschnitt 4.2) zu nominieren und ein, im Hinblick auf die Assessment-Ziele, repräsentatives Projekt-Sample (Untersuchungsobjekte) festzulegen. Das Arbeitspaket wird in einem Workshop abgearbeitet und beginnt mit einer Präsentation der externen Assessoren (vgl. Abschnitt 4.2), mit der der Unternehmensleitung und den nachgeordneten Instanzen Ziele, Grenzen und Potential sowie die Voraussetzungen und der erwartete Aufwand und Nutzen des Assessments erläutert werden. Ziel der Einarbeitung ist es, die externen Assesssoren mit unternehmensspezifischen Rahmenbedingungen vertraut zu machen, dem internen Assessor das RCMM vorzustellen, ihn mit der Assessment-Methodik vertraut zu machen und das Kickoff-Meeting (siehe weiter unten) vorzubereiten. Ziel der Detailplanung ist es, den auf Grund der Ergebnisse der Grobplanung vom Assessment betroffenen Personenkreis die vom Assessorenteam erwartete Mitarbeit und den erforderlichen Zeitaufwand (z.B. für die Bereitstellung von Dokumenten und die Verfügbarkeit für Interviews) und die Termine (z.B. für Kickoff-Meeting, Interviews und Ergebnispräsentation) abzustimmen bzw. festzulegen. Die Arbeitspakete der Erhebungsphase sind Kickoff-Meeting, Senior Management Interviews, Site Assessment und Project Assessments. Ziel des Kickoff-Meeting ist es, der Unternehmensleitung, den am Assessment Beteiligten und einem ausgewählten Kreis von Mitarbeitern, die von den Ergebnissen des Assessments direkt oder indirekt betroffen sein werden (z.B. Marketing-Verantwortliche, Produktmanager und Programmierer) das RCMM und die Assessment-Methodik vorzustellen, Konsens über die Vorgehensweise und die Untersuchungsobjekte zu erzielen, alle Beteiligten von der Sinnhaftigkeit des Assessments zu überzeugen und zur konstruktiven Mitarbeit zu motivieren. Darüber hinaus sollen die Beteiligten Gelegenheit haben, die externen Assessoren kennenzulernen.

246

Gustav Pomberger / Mohsen Rezagholi / Christine Stobbe

Ziel des Senior Management Interviews ist es, alle erforderlichen Informationen über die strategischen Untemehmensziele, die Struktur- und Ablauforganisation des Unternehmens und die Gründe für ihre Ausprägung, die Produktstrategie sowie andere, die Software-Entwicklung beeinflussende Faktoren (z.B. Qualitätspolitik, Technologiemanagement, Plattformmanagement) zu beschaffen und den Dokumentationsstatus dazu zu erheben. Ziel des Site Assessment ist es, den Status der Wiederverwendung von Software-Artefakten auf Unternehmensebene zu erheben. Mit einem standardisierten, in Erhebungscluster gegliederten Fragenkatalog (vgl. Abschnitt 4.4) werden Gruppeninterviews durchgeführt, um die für den Bewertungsprozeß erforderlichen Informationen und Dokumente zu beschaffen. Anschließende Einzelinterviews dienen dazu, bei den Gruppeninterviews zurückgestellte Fragen abzuhandeln, die in den Gruppeninterviews erhaltenen Informationen einem Plausibilitätstest zu unterziehen, die Relevanz der für die Dokumentenanalyse identifizierten Dokumente zu überprüfen und durch ein offenes Interview subjektive Einschätzungen von Stärken und Schwächen des untersuchten Unternehmens, seinen Mitarbeitern, Prozessen, Produkten und Projekten zu erhalten. Ziel der Project Assessments ist es, den Status der Wiederverwendung von Software-Artefakten auf Projektebene, d.h. für unterschiedliche Projekte, zu erheben, da die Praxis zeigt, daß der Reifegrad auf Projektebene oft sehr unterschiedlich ist. (Die zu untersuchenden Projekte wurden im Arbeitspaket Grobplanung identifiziert und im Kickoff-Meeting festgelegt.) Der Ablauf eines Project Assessment ist mit dem des Site Assessment identisch, d.h. es werden auch hier die standardisierten Interviews durchgeführt. Abbildung 3 zeigt den Erhebungsablauf beim Site Assessment und bei einem Project Assessment. Die Arbeitspakete der Auswertungsphase sind Beurteilung und Reifegradbestimmung, Draftversion Assessmentbericht, Feedback-Runden und Maßnahmenfortschreibung. Die Beurteilung und Reifegradbestimmung (vgl. Abschnitt 4.4) erfolgt auf Grund der Analyse der im Site Assessment und in den Project Assessments angefordeten Dokumente und der durch standardisierte und offene Interviews gewonnenen Informationen. Ziel ist es, eine Draftversion des Assessmentberichts mit folgendem Inhalt zu erstellen: Ausgangssituation, Untersuchungsumfang, Gesamteindruck, Befunde aus dem Site Assessment, Befunde aus den Project Assessments, Gesamtbeurteilung, identifiziertes Entwicklungspotential, empfohlene Maßnahmen, Anhänge zur Sicherung der Nachvollziehbarkeit der Befunde (z.B. Angabe der verwendeten Dokumente, anonymisierte Fragebogendaten).

Wiederverwendungsorientierte Site Assessment Kickoff Meeting

I

Software-Entwicklung

Project Ass. 1

Grp. Interview

Grp. Interview Funkt. Verantw.

Einzel-lnterv.

Einzel-lnterv.

Dokumenten Analyse

Grp. Interview Bearbeiter

Vorläufige Bewertung

Dokumenten Analyse

247

Project Ass. 2

ιr Senior Mgt. Interview

!-

Vorläufige Bewertung

Abb. 3: Erhebungsablauf

Ziel der Feedback-Runden ist es, die Assessment-Ergebnisse den Vertretern der Organisationseinheiten (insbesondere der untersuchten Projekte) zu erläutern, eventuelle Diagnosefehler oder Mißverständnisse zu diskutieren und zu beseitigen und über die Befunde und das identifizierte Entwicklungspotential Konsens zu erzielen. Ziel der Maßnahmenfortschreibung ist es, auf Grund der Ergebnisse der Feedback-Runden das identifizierte Entwicklungspotential zur Verbesserung der Produktivität und Qualität und zur Senkung der Kosten und die Maßnahmenempfehlung zu deren Ausschöpfung zu komplettieren. Ziel der Dokumentationsphase (Arbeitspakete Finalisierung und Ergebnispräsentation) ist es, die Ergebnisdokumentation zu komplettieren und in eine angemessene Form zu bringen sowie den Teilnehmern des Kickoff-Meetings das Assessment-Ergebnis zu präsentieren. Idealerweise endet die Ergebnispräsentation mit einer Stellungnahme der Unternehmensleitung über den nächsten Schritt zum Wandel zur wiederverwendungsorientierten SoftwareEntwicklung. 4 . 2 Assessorenteam und Aufgaben der Assessoren Als Assessorenteam sind vier Personen vorgesehen, ein Moderator, zwei externe und ein interner Assessor. Ihre Aufgaben sowie die erforderliche Qualifikation werden im folgenden beschrieben. Der Moderator soll ein mit Assessment-Techniken vertrauter, erfahrener Software-Techniker sein. Ob er Mitarbeiter des Unternehmens ist oder von außerhalb des Unternehmens kommt, ist nicht von Bedeutung. Zu seinen

248

Gustav Pomberger / Mohsen Rezagholi / Christine Stobbe

Aufgaben gehören die Terminkoordination, die Moderation der Gruppeninterviews anhand des Fragenkatalogs, die Diskussionsleitung in den Feedback-Runden und die Präsentation der Assessment-Ergebnisse. Die externen Assessoren sollen mit Assessment-Techniken vertraute Software-Techniker sein, die über gute Kenntnisse im Bereich wiederverwendungsorientierter Software-Entwicklung verfügen (z.B. Technologiewissen, Prozeßwissen, Projekterfahrung, Überblick über Marktsituation für Komponenten). Die Ausbildung von Software-Technikern, die das geforderte Qualifikationsprofil erfüllen, aber keine Erfahrung mit Assessments haben, zu Assessoren, ist wegen des hohen Formalisierungsgrads der Assessment-Aktivitäten durch das RCMM und das RCAM in drei bis fünf Tagen möglich. Zu den Aufgaben der externen Assessoren gehören die Durchführung der Interviews und Protokollführung, die Fragebogenauswertung, die Dokumentenanalyse, die ergänzende Informationsbeschaffung, wenn die Ergebnisse der Dokumentenanalyse und der Fragebogenauswertung Erhebungslücken erkennen lassen, die Beurteilung und Reifegradermittlung, die Darstellung des Stärken-/Schwächen-ProfiIs und des identifizierten Verbesserungspotentials sowie die Ausarbeitung von Maßnahmenempfehlungen zur Ausschöpfung des Verbesserungspotentials. Der interne Assessor soll ebenfalls ein erfahrener Software-Techniker sein und idealerweise aus dem Bereich des Software-Qualitätsmanagements kommen. Er hat dieselben Aufgaben wie die externen Assessoren. Daneben gehören zu seinen Aufgaben das Herstellen der Kontakte zwischen den am Assessment Beteiligten und den externen Assessoren, die Herstellung eines angemessenen Gesprächsklimas und die Bereitstellung der notwendigen Infrastruktur (z.B. Raum für Gruppeninterviews), sofern dies nicht vom Moderator erledigt werden kann (z.B. wenn der Moderator von außerhalb des Unternehmens kommt). Er soll, gestützt auf sein Wissen über unternehmensspezifische, organisatorische und personenbezogene Details helfen, Unklarheiten oder Mißverständnisse zu vermeiden. Er soll auch Garant dafür sein, daß alle Mitarbeiter über die Ziele und Ergebnisse des Assessments auf dem laufenden gehalten werden. Vom gesamten Assesssment-Team wird hohe soziale Kompetenz, Kommunikationsfähigkeit, Fähigkeit zu analytischem Denken und zu Objektivität verlangt. 4 . 3 Auswahl der Interviewpartner und der Erhebungsdokumente Das Identifizieren und Ausschöpfen des Nutzenpotentials wiederverwendungsorientierter Software-Entwicklung setzt voraus, daß nicht nur die technischen Details der Software-Entwicklung, sondern auch die strategischen und organisatorischen Details berücksichtigt werden. Deshalb werden Vertreter folgender Personenkreise in den Assessment-Prozeß einbezogen (in Klammern Beispiele für die ihnen zugeordneten Dokumenttypen, die

Wiederverwendungsorientierte

Software-Entwicklung

249

zusammen mit den Interviews zur Informationsgewinnung herangezogen werden): • Senior Management: Top-Management, Mitglieder von Lenkungsausschüssen (Unternehmens-, Informatik-, Software Engineering-Strategie); Auftraggeber des Assessments (Controlling-Berichte, Unternehmenskennzahlen); Sponsoren von Innovations- und Improvement-Aktionen • Site Management: Mittleres Management wie Bereichs- und Abteilungsleiter, Produktmanager (Produktentwicklungsstrategien, Stellenbeschreibungen, Produktkennzahlen); Qualitätsmanager (Qualitätsmodelle, Qualitätssicherungsmaßnahmen, Qualitätskennzahlen); Verantwortliche für den Software-Entwicklungsprozeß (Vorgehensmodelle, Prozeßkennzahlen, Aufwandskennzahlen) • Funktionalitätsverantwortliche: Projektleiter bzw. Teilprojektleiter mit Verantwortung für spezifische Funktionsblöcke (Produkt[teile]spezifikationen, Komponentenbibliotheken, Produktdokumentationen, Aufwandskennzahlen) • Sachbearbeiter: Experten für spezielle Themengebiete (Methoden-Handbücher, Entwurfsmuster, Aufwands- und Qualitätskennzahlen); Mitarbeiter mit guten Kenntnissen des Entwicklungsprozesses (persönliche Aufzeichnungen) 4 . 4 Erhebungs- und Bewertungssystem Das Erhebungssystem wird durch die vom RCAM vorgegebene AssessmentStruktur und den vorgegebenen Assessment-Prozeß, den vorgegebenen Erhebungsablauf (vgl. Abbildung 3) und die aus dem RCMM abgeleiteten Erhebungsformulare in Form eines Fragenkatalogs gebildet. Der Fragenkatalog ist in vier Erhebungscluster, die Erhebungscluster sind in Schwerpunktthemen gegliedert, deren Ausprägung durch eine Reihe von Fragen und dazu geforderter Dokumente erhoben wird. Die Erhebungscluster sind (in Klammern Beispiele für Schwerpunktthemen): 1. Rahmenbedingungen (strategische Vorgaben, struktur- und ablauforganisatorische Ausgangsbasis); 2. Software-Entwicklungsprozeß (eingesetzte Technologien, verwendete Prozeßmodelle, Komponentenverwendung); 3. Support (verfügbare Vorschriften und Standards, bereitgestellte Infrastruktur, Technologiemanagement, Komponentenmanagement); 4. Meß- und Kontrollinstrumente (Qualitätsmessung und -kontrolle, Produktivitätsmessung und -kontrolle, Projekt-Reviews). Das Bewertungsystem baut auf dem Erhebungssystem auf. Es existiert ein standardisiertes Auswertungsformular, in dem die durch das Erhebungssystem vorgegebenen Untersuchungobjekte, gegliedert nach ihrer Zuordnung zu Reifegradstufen durch das RCMM, wiedergegeben sind. Einen Ausschnitt aus dem Auswertungsformular zeigt Abbildung 4. Den durch den standardisierten Fragenkatalog zur Erhebung der Ausprägung eines bestimmten Sachverhalts (Reuse Key Practice aus dem RCMM) vorgegebenen Erfüllungsgraden (nicht erfüllt, teilweise erfüllt, im wesentlichen erfüllt, voll-

250

Gustav

Pomberger

ständig erfüllt)

/ Mohsen

wird

Rezagholi

e i n e Ordinalskala

ordnet. D e r Erreichungsgrad und wie folgt

Stobbe

mit den Werten

£ Reifegrad

oder Projekt)

des

erreichte

Bewertungen

höchstmögliche

untersuchten

1, 2 ,

in

der

(bzw.

^

der

Bewertung des Aspekts

\rkp

Katalog über vorhandene wiederverwendbare Softwareartefakte ist vorhanden

L I . AB .4

BewerErreib u n g chungsgrad

\

122 Verwendung eines Prozeßmodells in dem L I . AB .6 Wiederverwendungsaktivitäten integriert sind Aufwand für Komponentenbereitstellung L2.AB.4 ist erfaßt und die Komponentenverwendung ist lückenlos dokumentiert 2 2 4 Auftragsakquisition und Produktvermarktung sind auf domänenspezifischen Halbfabrikats- L2.AC.1 u. Komponentenbestand ausgerichtet. 325

Architekurmanagement für Referezarchitekturen ist etabliert

83 % 3

223

2

50%

1 0%

0

L3.AB.4

1,3

Reifegrad "Orgnaisatoinseinheit x "

Erreichungsgrad derStufe[%] y Σ

einzelnen

Dem untersuchten Aspekt zugeordnete Reuse Key Practice (Verweis in das Reifegradmodell)

^^/Áspekt

121

Reifegrad 3

zuge-

Organisationseinheit

Erreichungsgrade

Beschreibung des untersuchent Aspekts

grad 2

3>

angegeben

gebildet.

Nummer des untersuchten Aspekts im Fragenkatalog

Reife-

[%]

χ 100

Bewertung

Unternehmens

wird durch Kumulation

Reifegradstufen

Reifegrad 1