Informationsmanagement: Grundlagen, Aufgaben, Methoden [10., vollständig überarb. Aufl.] 9783486714593

Citation preview

Informationsmanagement Grundlagen, Aufgaben, Methoden

von

Prof. em. Dr. Lutz J. Heinrich

Universität Linz und

Prof. Dr. Dirk Stelzer

Technische Universität Ilmenau

10., vollständig überarbeitete Auflage

Oldenbourg Verlag München

Lutz J. Heinrich, o. Univ.-Prof. em. Dr., lehrte Betriebswirtschaftslehre und Wirtschaftsinformatik an der Johannes Kepler Universität Linz. Dirk Stelzer, o. Univ.-Prof. Dr., ist Professor für Informations- und Wissensmanagement und Leiter des Instituts für Wirtschaftsinformatik der TU Ilmenau. Die Webseite http://www.informationsmanagement-buch.org enthält umfangreiches Zusatzmaterial und gibt Studierenden sowie Praktikern die Möglichkeit, Hinweise zur Ergänzung und Verbesserung des Buches zu geben, sowie über aktuelle Fragen des Informationsmanagements zu diskutieren.

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © 2011 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0 www.oldenbourg-verlag.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. Lektorat: Christiane Engel-Haas Herstellung: Constanze Müller Titelbild: thinkstockphotos.de Einbandgestaltung: hauser lacour Gesamtherstellung: Beltz Bad Langensalza GmbH, Bad Langensalza Dieses Papier ist alterungsbeständig nach DIN/ISO 9706. ISBN 978-3-486-70253-8

Vorwort Die 10. Auflage 2011 des Lehr- und Handbuchs Informationsmanagement unterscheidet sich von der 9. Auflage 2009 nicht nur dadurch, dass alle Lerneinheiten überarbeitet wurden, sondern auch durch zusätzliche oder wesentlich erweiterte Lerneinheiten. Zusätzliche Lerneinheiten sind Informationsverhalten (INVER) und Szenariotechnik (SZENA). Bisherige Publikationen zum Informationsmanagement, so auch das vorliegende Lehr- und Handbuch, orientieren sich auf die Analyseebenen Organisationen und Organisationsteile, Individuen und Gruppen spielen bisher nur eine Nebenrolle. Mit der Lerneinheit INVER machen die Autoren einen ersten Schritt zur Erweiterung der Analyseebenen des Gegenstandsbereichs Informationsmanagement. Die seit der ersten Auflage 1987 bis zur achten Auflage 2005 publizierte Lerneinheit Szenariotechnik (SZENA) wurde wieder in den Bestand aufgenommen. Dafür war sowohl die Erkenntnis ausschlaggebend, dass für mehr IM-Aufgaben als bisher angenommen, insbesondere für strategische Aufgaben, die Szenariotechnik sehr hilfreich sein kann, als auch die Tatsache, dass neuere Entwicklungen und insbesondere die Verfügbarkeit von Werkzeugen den Zeitaufwand für Szenarioanalysen, eine Anwendungsbarriere der Szenariotechnik in der Praxis, verringern können. Zudem finden sich in Lehrund Fachbüchern der Wirtschaftsinformatik nach Kenntnis der Autoren keine Darstellungen, die explizit die Informationsinfrastruktur zum Untersuchungsgegenstand haben. Die Lerneinheit Erklärungsmodell (ERMOD) entstand durch Zusammenfassung der beiden Lerneinheiten Modell (MODIM) sowie Ziele, Aufgaben und Methoden des Informationsmanagements (ZAMIM). Damit wurde die Absicht verfolgt, die theoretischen Grundlagen des Informationsmanagements besser als bisher zu verdeutlichen und Redundanz zu vermeiden. Die Lerneinheit Infrastrukturmanagement (INMAN) entstand durch Erweiterung der Lerneinheit Rechenzentrumsmanagement (RZMAN), womit auch beabsichtigt war, Cloud Computing an geeigneter Stelle darzustellen. Eine der vier Fallstudien wurde durch die Fallstudie Dokumentenmanagement (FSDOK) ersetzt. Etliche Lerneinheiten wurden besser strukturiert, in fast alle wurde neues Material eingearbeitet, die Literaturangaben wurden aktualisiert, Abbildungen verbessert und neue eingefügt. Die Forschungsbefunde wurden ergänzt, ältere wurden herausgenommen, um den Umfang der Lerneinheiten im Rahmen zu halten. Alle Forschungsbefunde der bisherigen neun Auflagen werden auf der Website des Buches http//www.informationsmanagement-buch.org gesammelt. Wie im Vorwort zur 9. Auflage begründet, wird auf die Darstellung der operativen Aufgaben und Methoden verzichtet. Die 10. Auflage umfasst, so wie die 9. Auflage, 44 Lerneinheiten, davon wie bisher vier Fallstudien. Der Seitenumfang mehrerer Lerneinheiten wurde geringfügig erweitert, der Stoffumfang entspricht nach wie vor etwa dem Lehrinhalt einer vierstündigen Lehrveranstaltung mit je zwei Stunden Vorlesung und Übung. Mit den Ergänzungen der Website wird allerdings deutlich mehr Lernstoff angeboten. Ergänzende Dokumente (z. B. Demonstrationsbeispiele), das fortgeschriebene Glossar Informationsmanagement sowie ältere Forschungsbefunde werden zur Verfügung gestellt. Studierende und andere Benutzer haben die Möglichkeit,

VI

Vorwort

Hinweise zu Inhalten des Buches zu geben und Fragen zu stellen. Die Website wird ständig weiter entwickelt und ergänzt. Das in Wissenschaft und Praxis weit verbreitete Präfix IT wird pragmatisch verwendet. Wenn im Text keine besondere Erklärung zu finden ist (um z. B. Mehrdeutigkeiten zu vermeiden), ist es umfassend gemeint, bezeichnet also Informationssysteme, Technologien, Infrastruktur, Methoden und Werkzeuge usw.; beispielsweise beschränkt sich IT-Planung nicht auf Technologien, sondern meint Planung in diesem weit gefassten Sinne. Da das Buch insgesamt auf den IT-Bereich von Unternehmen in Wirtschaft und Verwaltung fokussiert ist, konnte an vielen Stellen auf das Präfix verzichtet werden, beispielsweise und insbesondere bei der Bezeichnung der Lerneinheiten. Die Autoren verwenden das herkömmliche Maskulinum und verzichten auf die meist umständlichen Konstruktionen einer beide Geschlechter explizit ansprechenden Formulierung. Wo immer möglich, wird eine Formulierung verwendet, die einen Geschlechterbezug vermeidet. Den Autoren ist es ein Anliegen zu betonen, dass damit keinerlei geschlechtsspezifische Absicht verbunden ist. Leserinnen und Leser sind gleichermaßen angesprochen. Das Manuskript der Lerneinheit Infrastrukturmanagement (INMAN) erarbeitete in Weiterentwicklung der Lerneinheit Rechenzentrumsmanagement der 9. Auflage (RZMAN) Hon.-Prof. Dr. Hermann Sikora, Geschäftsführer der Unternehmen der GRZ IT Gruppe (http://www.grz.at). Das Manuskript der neuen Lerneinheit Informationsverhalten (INVER) lieferte Assoc.Univ.-Prof. Dr. René Riedl, Institut für Wirtschaftsinformatik – Information Engineering der Johannes Kepler Universität Linz (http://www.ie.jku.at/); er überarbeitete auch die von ihm für die 9. Auflage zur Verfügung gestellte Fallstudie Erfolgsfaktorenanalyse (FSERF). Von Mag. Dr. Katharina Steininger und Mag. David Rückel, ebenfalls Institut für Wirtschaftsinformatik – Information Engineering der Johannes Kepler Universität Linz, stammt das Manuskript der Fallstudie Dokumentenmanagementsystem (FSDOK). Kirsten Oßmann hat die Daten für die Lerneinheit Fallstudie Lebenszyklusmanagement (FSLEM) zusammengestellt. Das Manuskript für die Fallstudie Geschäftsprozessmanagement (FSGPM) erarbeitete Dr. Daniel Fischer, Fachgebiet Informations- und Wissensmanagement der TU Ilmenau (http://www.tu-ilmenau.de/informationsmanagement). Der Dank der Autoren gilt auch Elisabeth Schmidt, Marion Wyzgol und Dr. Daniel Fischer für ihre Hilfe bei der Erstellung der Abbildungen und des druckfertigen Manuskriptes und Dr. Daniel Fischer für seine unermüdliche Arbeit an der Website. Hinweise auf Fehler und sachkritische Anmerkungen, die zur Verbesserung des vorliegenden Textes führen können, sind den Autoren willkommen. Linz und Ilmenau im Juni 2011 [email protected] – http://www.jku.at/winie/content/e66243 [email protected] – http://www.tu-ilmenau.de/informationsmanagement

Inhaltsverzeichnis Vorwort ...................................................................................................................................V Inhaltsverzeichnis................................................................................................................. VII Alphabetisches Verzeichnis der Lerneinheiten ......................................................................IX EINFÜHRUNG UND GRUNDLEGUNG ............................................................................1 A. GRUNDLAGEN DES INFORMATIONSMANAGEMENTS.....................................15 Erklärungsmodell (ERMOD) .................................................................................................17 Stellenbilder (STELL) ............................................................................................................31 Architektur der Informationsinfrastruktur (ARCHI) ..............................................................43 Governance (GOVER) ...........................................................................................................55 Informationsrecht (RECHT)...................................................................................................67 Informationsverhalten (INVER).............................................................................................79 B. STRATEGISCHE AUFGABEN DES INFORMATIONSMANAGEMENTS...........89 Situationsanalyse (SITAN).....................................................................................................91 Zielplanung (SZIEL) ............................................................................................................103 Strategieentwicklung (STRAT)............................................................................................113 Maßnahmenplanung (SPLAN).............................................................................................125 Strukturmanagement (STRUK)............................................................................................137 Qualitätsmanagement (QUALM) .........................................................................................149 Technologiemanagement (TECHM) ....................................................................................161 Sicherheitsmanagement (SICHM)........................................................................................175 Notfallmanagement (NOMAN)............................................................................................187 Controlling (CONTR) ..........................................................................................................199 Revision (REVIS).................................................................................................................211 Outsourcing (OUTSO) .........................................................................................................223 C. ADMINISTRATIVE AUFGABEN DES INFORMATIONSMANAGEMENTS ....235 Personalmanagement (PERSM) ...........................................................................................237 Datenmanagement (DATEM) ..............................................................................................249 Lebenszyklusmanagement (LEMAN)..................................................................................261 Geschäftsprozessmanagement (GPMAN) ............................................................................273 Wissensmanagement (WIMAN) ..........................................................................................285 Vertragsmanagement (VERMA)..........................................................................................297 Servicemanagement (SEMAN) ............................................................................................309 Infrastrukturmanagement (INMAN) ....................................................................................321

VIII

Inhaltsverzeichnis

D. METHODEN DES STRATEGISCHEN INFORMATIONSMANAGEMENTS .... 335 Erfolgsfaktorenanalyse (ERFAN) ........................................................................................ 337 Kennzahlensysteme (KENNZ)............................................................................................. 349 Wirtschaftlichkeitsanalyse (WIRTA)................................................................................... 361 Nutzwertanalyse (NUTZW)................................................................................................. 373 Evaluierungsmethoden (EVALU)........................................................................................ 385 Vorgehensmodelle (VOMOD)............................................................................................. 397 Szenariotechnik (SZENA).................................................................................................... 409 E. METHODEN DES ADMINISTRATIVEN INFORMATIONSMANAGEMENTS 421 Informationsbedarfsanalyse (INBAN) ................................................................................. 423 Methoden des Geschäftsprozessmanagements (MEGPM)................................................... 435 Methoden des Wissensmanagements (MEWIM)................................................................. 447 Kosten- und Leistungsrechnung (KOLER) .......................................................................... 459 Sicherheitskonzepte (SIKON).............................................................................................. 471 Methoden des Qualitätsmanagements (MEQUA)................................................................ 483 Serviceebenen-Vereinbarungen (SEVER) ........................................................................... 495 F. FALLSTUDIEN DES INFORMATIONSMANAGEMENTS ................................... 507 Fallstudie Dokumentenmanagement (FSDOK) ................................................................... 509 Fallstudie Erfolgsfaktorenanalyse (FSERF)......................................................................... 521 Fallstudie Lebenszyklusmanagement (FSLEM) .................................................................. 533 Fallstudie Geschäftsprozessmanagement (FSGPM) ............................................................ 545 Literaturverzeichnis.............................................................................................................. 557 Schlagwortverzeichnis ......................................................................................................... 577

Alphabetisches Verzeichnis der Lerneinheiten Erklärungsmodell (ERMOD) .................................................................................................17 Architektur der Informationsinfrastruktur (ARCHI) ..............................................................43 Controlling (CONTR) ..........................................................................................................199 Datenmanagement (DATEM) ..............................................................................................249 Erfolgsfaktorenanalyse (ERFAN) ........................................................................................337 Evaluierungsmethoden (EVALU) ........................................................................................385 Fallstudie Dokumentenmanagement (FSDOK)....................................................................509 Fallstudie Erfolgsfaktorenanalyse (FSERF) .........................................................................521 Fallstudie Geschäftsprozessmanagement (FSGPM).............................................................545 Fallstudie Lebenszyklusmanagement (FSLEM)...................................................................533 Geschäftsprozessmanagement (GPMAN) ............................................................................273 Governance (GOVER) ...........................................................................................................55 Informationsbedarfsanalyse (INBAN) .................................................................................423 Informationsrecht (RECHT)...................................................................................................67 Informationsverhalten (INVER).............................................................................................79 Infrastrukturmanagement (INMAN) ....................................................................................321 Kennzahlensysteme (KENNZ) .............................................................................................349 Kosten- und Leistungsrechnung (KOLER) ..........................................................................459 Lebenszyklusmanagement (LEMAN)..................................................................................261 Maßnahmenplanung (SPLAN).............................................................................................125 Methoden des Geschäftsprozessmanagements (MEGPM)...................................................435 Methoden des Qualitätsmanagements (MEQUA) ................................................................483 Methoden des Wissensmanagements (MEWIM) .................................................................447 Notfallmanagement (NOMAN)............................................................................................187 Nutzwertanalyse (NUTZW) .................................................................................................373 Outsourcing (OUTSO) .........................................................................................................223 Personalmanagement (PERSM) ...........................................................................................237 Qualitätsmanagement (QUALM) .........................................................................................149 Revision (REVIS).................................................................................................................211 Serviceebenen-Vereinbarungen (SEVER)............................................................................495 Servicemanagement (SEMAN) ............................................................................................309 Sicherheitskonzepte (SIKON) ..............................................................................................471 Sicherheitsmanagement (SICHM)........................................................................................175 Situationsanalyse (SITAN).....................................................................................................91 Stellenbilder (STELL) ............................................................................................................31 Strategieentwicklung (STRAT)............................................................................................113 Strukturmanagement (STRUK)............................................................................................137 Szenariotechnik (SZENA)....................................................................................................409 Technologiemanagement (TECHM) ....................................................................................161

X

Alphabetisches Verzeichnis der Lerneinheiten

Vertragsmanagement (VERMA).......................................................................................... 297 Vorgehensmodelle (VOMOD)............................................................................................. 397 Wirtschaftlichkeitsanalyse (WIRTA)................................................................................... 361 Wissensmanagement (WIMAN) .......................................................................................... 285 Zielplanung (SZIEL)............................................................................................................ 103

Einführung und Grundlegung Es werden zunächst die für das Informationsmanagement grundlegenden Begriffe Wissen, Information, Daten und Management sowie das aus Information und Management gebildete Konstrukt Informationsmanagement erläutert und es wird in die Grundbegriffe Informationsfunktion und Informationsinfrastruktur eingeführt. Anschließend wird der in diesem Lehrund Handbuch vertretene so genannte leitungsorientierte Ansatz des Informationsmanagements erklärt und es werden andere IM-Ansätze erläutert und hinsichtlich ihrer Unterschiede und Gemeinsamkeiten beurteilt. Schließlich wird die Struktur beschrieben, in welcher der Lernstoff aufbereitet wurde und dokumentiert ist.

Grundlegende Begriffe Im Allgemeinen wird unter Information eine Auskunft, Aufklärung oder Belehrung verstanden. In der Betriebswirtschaftslehre wird Information als zweckorientiertes Wissen definiert, wobei der Zweck in der Vorbereitung betriebswirtschaftlichen Handelns liegt (nach Wittmann). Wissen wird nach Probst/Raub/Romhardt als Gesamtheit der Kenntnisse und Fähigkeiten zur Lösung von Problemen definiert. Wissen kann implizit oder explizit sein. Kuhlen definiert implizites Wissen als kognitive Strukturen und mentale Repräsentationen von Sachverhalten. Implizites Wissen steht ausschließlich dem jeweiligen Wissensträger zur Verfügung. Soll dieses Wissen auch von anderen Personen genutzt oder personenunabhängig aufbewahrt werden, muss es expliziert bzw. in eine mitteilbare Form gebracht werden. Dieser Vorgang wird lateinisch mit informare (= bilden, eine Gestalt geben) bezeichnet. Information ist demnach explizites Wissen. Für die Wirtschaftsinformatik wird dies so präzisiert: Information ist Handlung bestimmendes, explizites Wissen über historische, gegenwärtige und zukünftige Zustände der und Vorgänge in der Wirklichkeit, mit anderen Worten: Information ist Reduktion von Ungewissheit. Um Daten handelt es sich, wenn Phänomene der Wirklichkeit zum Zweck der Erfassung, Speicherung und Verarbeitung als eine Folge von Bits formalisiert dargestellt werden. Sie sind nicht unmittelbar zweckorientiert, sondern der (immaterielle) Rohstoff für die Produktion von Information, die wiederum zum Zweck der Verarbeitung formalisiert dargestellt werden kann und aus der andere Informationen generiert werden können. 1950 veröffentlichten Shannon/Weaver ihr Werk „Mathematical Theory of Communication“, mit dem die Informationstheorie als Wissenschaft etabliert wurde. Shannon hatte 1937 mit seiner Master Thesis über Schaltalgebra die Grundlagen geschaffen. Wiener trug mit seinem mathematischen Modell über die Brown´sche Molekularbewegung viel zu den Grundlagen der Informationstheorie bei. Roszak macht dieses Werk für die Art und Weise verantwortlich, in der seither Praktiker, häufig aber auch Wissenschaftler „Information“ gebrauchen (27): „In der Vergangenheit hatte das Wort stets eine vernünftige Aussage bezeichnet, die eine erkennbare, sprachliche Bedeutung vermittelte, im Allgemeinen das, was wir eine Tatsache nennen. Aber nun gab[en] Shannon [und Weaver] dem Wort eine technische Bedeutung, die es von seiner alltagssprachlichen Verwendung absonderte.“ Information in seiner technischen Bedeutung bezeichnet das, was codiert werden kann, völlig unabhängig vom semantischen Gehalt, also das, was in der Wirtschaftsinformatik als Daten bezeichnet wird.

2

Einführung und Grundlegung

Die Verwendung des Wortes Information im Zusammenhang mit Technik oder Technologie, also Informationstechnik bzw. Informationstechnologie, suggeriert, dass das Vorhandensein und die Verwendung von Technik bzw. Technologie prinzipiell etwas mit dem zu tun hat, was im Sinne der Wirtschaftsinformatik „Information“ ist. Diese Begriffsauffassung hat zur Einführung weiterer Begriffskonstrukte geführt (z. B. Information Lifecycle Management), denen die begriffliche Klarheit der Unterscheidung von Daten und Information fehlt. Da es nicht Aufgabe dieses Lehr- und Handbuchs ist, Fachsprache der Wirtschaftsinformatik zu entwickeln, werden solche Begriffskonstrukte, wenn sie in Wissenschaft und Praxis verbreitet sind, übernommen bzw. wird auf diese grundsätzliche Erklärung verwiesen. Information und Kommunikation sind zwei Aspekte ein und desselben Phänomens: ohne Information keine Kommunikation, und ohne Kommunikation keine Information. Szyperski hat dies sinngemäß als siamesischen Zwillingscharakter von Information und Kommunikation oder als die beiden Seiten ein und derselben Münze bezeichnet. Diese Tatsache erfordert es, bei jeder Art von Analyse, Entwicklung, Implementierung usw. von Informationssystemen immer beide zu betrachten. In den letzten Jahren hat sich das Akronym IT für Informations- und Kommunikationstechnik bzw. -technologie sowie das Akronym IS für Informationssystem durchgesetzt; Kommunikation wird nicht explizit genannt, ist aber immer (auch) gemeint. Kommunikation wird auch im Akronym IM für Informationsmanagement nicht explizit genannt, obwohl sich IM ausdrücklich auf Information und Kommunikation bezieht. Da IT auch als Akronym verwendet wird, um die für Information und Kommunikation in Organisationen zuständigen Institutionen, Funktionen und Personen sowie die einschlägigen Methoden, Arbeitsgebiete usw. zu bezeichnen (z. B. IT-Abteilung, IT-Controlling, ITPersonal, schließlich alles dies umfassend: IT-Bereich), wird zur Bezeichnung der Technik bzw. der Technologie das Akronym IKT verwendet, wenn nicht aus dem Kontext auf das zutreffende Objekt eindeutig geschlossen werden kann. Synonym verwendet werden auch die Bezeichnungen Organisation (als Institution, nicht als Prozess) und Unternehmen. Unter Management wird das Führen einer Organisation oder von Organisationsteilen (z. B. Struktureinheiten wie Fachabteilungen oder die IT-Abteilung, vgl. Lerneinheit STRUK) verstanden, oder es wird damit die Personengruppe bezeichnet, die Organisationen oder Teile davon führen. In der Betriebswirtschaftslehre meint Management das Leitungshandeln in einer Organisation, mit dem sich insbesondere der betriebswirtschaftliche Wissenschaftsbereich der Managementlehre befasst. Die Notwendigkeit zum Leitungshandeln besteht in jeder arbeitsteiligen Organisation. Arbeitsschwerpunkte der Managementlehre sind Managementtechnik und Menschenführung (Personalführung, vgl. Lerneinheit PERSM). Unter den verschiedenen Denk- und Erklärungsansätzen der Managementlehre ist der systemtheoretisch-kybernetisch orientierte Ansatz von besonderem Interesse. Er macht die begrifflichen und die forschungsmethodischen Instrumente der Systemtheorie und der Kybernetik für das Management – und somit auch für das Informationsmanagement – nutzbar. Mit dem Konstrukt Informationsmanagement ist also das auf Information und Kommunikation bezogene Leitungshandeln (das Management) in einer Organisation gemeint, folglich alle Führungsaufgaben, die sich mit Information und Kommunikation befassen. Werden alle Aufgaben einer Organisation bezüglich Information und Kommunikation zu einer betrieblichen Funktion zusammengefasst, wird von der Informationsfunktion (als verkürzte

Einführung und Grundlegung

3

Querschnittsfunktionen

Bezeichnung für Informations- und KommuniGrundfunktionen kationsfunktion) gesprochen. Dies erfolgt in Analogie zu anderen betrieblichen Funktionen wie Beschaffung, Produktion und Vertrieb (als Grundfunktionen) sowie Personal, Finanzierung und Logistik (als Querschnittsfunktionen). Die Informationsfunktion ist also eine besondere Querschnittsfunktion, weil sie nicht nur die Grundfunktionen, sondern auch die klassischen Querschnittsfunktionen durchdringt. Abbildung EINGR-1 visualisiert diesen Charakter der Informationsfunktion. Da sie die anderen betrieblichen Funktionen durchdringt, gibt es mit Information und Kommunikation befasste Führungsaufgaben in allen Teilen des Aufgabensystems eines Unternehmens. InforInformationsfunktion mationsmanagement ist daher grundsätzlich ständige Aufgabe jeder Führungskraft. Füh- Abb. EINGR-1: Informationsfunktion als besondere Querschnittsfunktion rungsaufgaben der Informationsfunktion sind bei einer engen Interpretation des Gegenstandsbereichs der Wirtschaftsinformatik die Aufgaben der Schaffung, Nutzung und Weiterentwicklung sowie des Betriebs der Informations- und Kommunikationsinfrastruktur, kurz gesagt der Informationsinfrastruktur, im Folgenden zur Vereinfachung häufig weiter abgekürzt als Infrastruktur bezeichnet. Der in der Praxis verwendete Begriff IT-Infrastruktur erfasst nur die technische Infrastruktur. Sie ist Teil der IT-Ressourcen, zu denen bei CobiT (Control Objectives for Information and Related Technology), ein Framework für die IT-Governance (vgl. Lerneinheit GOVER) und die Gestaltung von IT-Prozessen, außerdem Anwendungssysteme (Programme und Daten) und IT-Personal gehören. Das ITSMF (IT Service Management Forum, auch itSMF geschrieben) definiert IT-Infrastruktur als die Gesamtheit der Hardware, Software, Netzwerke, Anlagen etc., die für die Entwicklung und Tests, die Bereitstellung, das Monitoring, die Steuerung oder den Support von IT Services erforderlich sind. Der Begriff umfasst die gesamte Informationstechnologie, nicht jedoch die zugehörigen Mitarbeiter, Prozesse und Dokumentationen. IT-Infrastruktur ist der engere, Informationsinfrastruktur der weitere Begriff. Bei einer weiten Interpretation des Gegenstandsbereichs der Wirtschaftsinformatik, wie sie bei Heinrich/Heinzl/Riedl (11 ff.) postuliert wird, ist auch die Gestaltung der Informationsfunktion eine Aufgabe des Informationsmanagements (z. B. Modellierung und Implementierung von Geschäftsprozessen). Letztlich geht es beim Informationsmanagement darum, durch Wahrnehmung von Führungsaufgaben eine der Informationsfunktion adäquate Informationsinfrastruktur zu schaffen respektive die Informationsfunktion so zu gestalten, dass ihr Leistungspotenzial und das Erfolgspotenzial der Informationsinfrastruktur unter definierten strategischen Zielen auf möglichst hohem Niveau im Gleichgewicht sind. Das kann durch folgende Hypothesenformulierung verdeutlicht werden:

4

Einführung und Grundlegung



Je größer das Leistungspotenzial ist, desto mehr Erfolgspotenzial muss geschaffen werden, um das Leistungspotenzial auszuschöpfen. Anders ausgedrückt: Je mächtiger die Informationsfunktion ist, desto schlagkräftiger muss die Informationsinfrastruktur sein, um das Leistungspotenzial auszuschöpfen.



Darnton/Giacoletto haben die strategische Bedeutung dieser Aufgaben bereits 1992 in einen gesamtwirtschaftlichen Zusammenhang gebracht (zitiert nach Renkema 41): „The previous major paradigm shift to an industrial economy required the development of massive manufacturing infrastructure. Similarly, a paradigm shift to an information economy requires the development of a massive information infrastructure which must be designed and constructed, that is architected, carefully.” Informationsmanagement in diesem Sinne, seit dem Jahre 1987 als Lehr- und Handbuch publiziert, wird in der einschlägigen Literatur und auch als Kommentierung zu den bisherigen Auflagen dieses Buches (so von König/Ludwig) als leitungszentrierter IM-Ansatz bezeichnet. Dieser kann, ganz kurz gesagt, mit der Forderung erklärt werden, dass jede Führungskraft bei allen Entscheidungen in Betracht ziehen soll, ob die Unternehmensziele durch den Einsatz von Informations- und Kommunikationstechnologien besser erreicht werden können. Wenn ja, muss der Technologieeinsatz durch Managemententscheidungen herbeigeführt und gefördert werden. Eine Besonderheit dieses Ansatzes besteht in der vergleichsweise expliziten Betonung und Behandlung des Information Engineering, also der Methoden und Techniken zur Unterstützung der Aufgabenerfüllung des Informationsmanagements. Sie orientiert sich an den von Finkelstein und Martin am Ende der 1980er Jahre entwickelten Konzepten.

Andere IM-Ansätze Ansatz bedeutet in der Wirtschaftsinformatik meist nicht viel mehr als Auffassung, manchmal auch Konzept oder Modell im Sinne eines generischen Rahmenwerks. Die folgende Darstellung verwendet die Zeit als Ordnungsmerkmal, um einen Eindruck darüber zu vermitteln, wie sich Informationsmanagement im Laufe von rd. 25 Jahren entwickelt hat. 1985 berichtet Wilder über den aus den USA bekannten IRM-Ansatz (IRM = Information Resource Management), in dessen Mittelpunkt die These steht, dass Information ein Produktionsfaktor ist. Da es Aufgabe des Managements ist, die Verfügbarkeit der Produktionsfaktoren für Leistungserstellung und Leistungsverwertung sicherzustellen, muss auch die Verfügbarkeit der Betriebsmittel, die zur Deckung der aufgabenbedingten Informationsnachfrage erforderlich sind, eine Managementaufgabe sein. Schaffung, Nutzung und Weiterentwicklung der innerbetrieblichen und außerbetrieblichen Einrichtungen zur Informationsversorgung stehen daher im Mittelpunkt der Aufgaben des Informationsmanagements. Unterschiede zum leitungszentrierten Ansatz bestehen vor allem bezüglich der Betonung der außerbetrieblichen Einrichtungen sowie der Nichtbeachtung strategischer Aufgaben und damit der Möglichkeit des Einflusses des Informationsmanagements beim Setzen der Unternehmensziele und Entwickeln der Unternehmensstrategie. Ein 1989 von Earl herausgegebenes Fachbuch erklärt u. a. den PIM-Ansatz (PIM = Personal Information Management bzw. Persönliches Informationsmanagement), mit dem die Auffassung vertreten wird, dass Informationsmanagement im Wesentlichen identisch ist mit dem

Einführung und Grundlegung

5

Wissen und Können im persönlichen Umgang mit Information. Management wird nicht als Leitungshandeln verstanden, sondern mit information handling gleichgesetzt, also damit, wie mit Information am Arbeitsplatz persönlich umgegangen werden soll. Dass dieser Ansatz nur einen Teil des leitungszentrierten Ansatzes erfasst, geht bereits aus dem Wort „persönlich“ hervor. Der PIM-Ansatz berücksichtigt nur den Teil der Informationsinfrastruktur, welcher der „Individuellen Informationsverarbeitung“ dient. Sie wird beim leitungszentrierten Ansatz mit der Begründung nicht verfolgt, dass es sich nicht um Führungsaufgaben handelt. Der von Seibt seit 1990 für den Lehrbetrieb entwickelte, 1993 publizierte Vier-SäulenAnsatz rückt Objekte in den Vordergrund, die von Informationsmanagern zu gestalten sind, das sind (1) Netze und Rechner-Ressourcen, (2) System-Lebenszyklen, (3) Informationsund Wissensversorgung sowie (4) Erfolgssteigerung und Potenzialvergrößerung durch den Einsatz von Informations- und Kommunikationstechnologien. In jeder dieser Säulen müssen strategische, administrativ-taktische und operative Managementaktivitäten wahrgenommen werden. Gleiches gilt für das Controlling, das objektspezifisch ausgeprägt werden muss, wenn es wirksam sein soll. Biethahn/Muksch/Ruf waren 1990 die ersten Wirtschaftsinformatiker, die ihr IM-Konzept mit einem Adjektiv kennzeichneten, nämlich mit „ganzheitlich“. „Ziel eines ganzheitlichen Informationsmanagements“, so wird unter Hinweis auf einen praxisorientierten Beitrag von Schmidt-Reindl formuliert (1), „…soll [sic!] eine Integration der bisher meist isolierten Bereiche der Organisation, der Informationstechnik, der Informationsverarbeitung und der Kommunikation sein, um so zu einer allen Informationsbedürfnissen gerecht werdenden Informationsverarbeitung zu gelangen.“ Bild 1-1 dieser Quelle visualisiert diese Aussage nur teilweise, indem „Informationsmanagement als Schnittstelle zwischen Informationstechnik, Organisation und Informationsbeziehungen“ dargestellt wird. Kommunikation erscheint hier nicht, und die Anordnung von „Informationsmanagement“ als Zentrum interaktiver Beziehungen zu den drei anderen Phänomenen gibt keine zusätzliche Erklärung. Die Besonderheit des 1990 von Österle/Brenner/Hilbers publizierten Führungsansatzes besteht in der ausdrücklichen Forderung nach „informationsbewusster Unternehmensführung“, was mit dem Erkennen des durch IT-Einsatz möglichen Veränderungspotenzials und dessen Umsetzung in neue Produkte, Geschäftsfelder usw. identisch ist. Weitere Aufgaben des Informationsmanagements sind Informationssystem-Management und Management der Informatik. Dies meint Folgendes: Die Informationsverarbeitung wird aus logischkonzeptioneller Sicht gesehen; das Informationssystem-Management konzentriert sich auf Entwicklung, Betrieb und Nutzung von Informationssystemen. Das Management der Informatik betrachtet Informationssysteme aus Sicht der personellen und technischen Infrastruktur zur Entwicklung, zum Betrieb und zur Nutzung von Informationssystemen. Mit diesen Erklärungen werden keine Aufgaben angesprochen, die nicht auch Gegenstand des leitungszentrierten Ansatzes sind. Schwarzer/Krcmar machten 1995 mit dem prozessorientierten Ansatz auf eine notwendige Erweiterung der Denkweisen des Informationsmanagements aufmerksam. Früher, so argumentierten sie, war die Architektur der Informationsinfrastruktur der funktional gegliederten Organisation angepasst. Die heute vorherrschende strategische Ausrichtung der Unternehmensziele an den Geschäftsprozessen muss sich in einer entsprechenden Ausrichtung der

6

Einführung und Grundlegung

Informationsinfrastruktur niederschlagen, da ohne sie eine geschäftsprozessorientierte Organisation nicht möglich ist. Die Informationsinfrastruktur muss auf die konsequente Unterstützung der Geschäftsprozesse ausgerichtet sein. Auf diese Weise erfolgt die Integration der Funktionsbereiche durch Informationsverarbeitung. Informationssysteme müssen nicht nur die entscheidungsrelevanten Informationen an jedem Arbeitsplatz entlang der Prozesskette zur Verfügung stellen, sondern darüber hinaus Prozesse, die mehrere Arbeitsplätze umfassen, unterstützen, steuern und koordinieren. Für das Informationsmanagement werden daraus folgende Gestaltungsempfehlungen abgeleitet:   

Konsequent prozessorientierte Organisation der dezentralen IT-Einheiten unter Beibehaltung einer zentralen IT-Einheit; die Vorteile der prozessbezogenen Spezialisierung werden mit denen der unternehmensweit einheitlichen Infrastruktur verbunden. Kombination von kontinuierlicher Verbesserung und tief greifender Veränderung im Rahmen von Projekten des Business Process Reengineering. Kooperation zwischen Fachbereichen und IT-Einheiten, um den Know-how-Transfer sicherzustellen und zu gemeinsamen Problemlösungen zu gelangen.

Seit 1996 publiziert Krcmar in Lehrbuchform „Informationsmanagement“. Er systematisiert IM-Ansätze so (nach der 5. Auflage, 31 ff.): problemorientierte im amerikanischen Sprachraum, aufgabenorientierte und prozessorientierte im deutschen Sprachraum sowie das sogenannte Ebenenmodell von Wollnik und verschiedene Architekturmodelle (z. B. ARIS von Scheer). Eine Systematik dieser Art kann dem Zweck dienen, einen Überblick über IMAnsätze zu geben, die es, wie der Autor meint, „in Hülle und Fülle“ gibt. Den Mangel der Ansätze sieht er in der fehlenden Ganzheitlichkeit (z. B. die unzureichende Orientierung von aufgabenorientierten Modellen an Prozessen). Diesen Mangel und andere Mängel will der Autor mit einem aus drei Ebenen bestehenden Referenzmodell des Informationsmanagements vermeiden (Abbildung 2-19 in der angegebenen Quelle mit Erläuterungen, 50 ff.). „Auf der einen Seite stellt sich das IM als eine auf drei Ebenen verteilte Managementaufgabe dar, die sich auf die Information selbst auf der obersten Ebene, die Anwendungen in der Mitte und die Technik als Basis auf der untersten Ebene bezieht. … Es existieren aber auch Aufgaben, die auf jeder Ebene anfallen oder nicht ausschließlich auf eine Ebene zu beziehen sind. Als generelle Aufgaben des IM gehören sie zur Gruppe der Führungsaufgaben des Informationsmanagements. … Als Ergebnis dieser Modellierung lassen sich nun die vielen einzelnen Aufgaben des IM identifizieren und zuordnen.“ Informationsmanagement wird als „Management der Informationswirtschaft, der Informationssysteme, der Informations- und Kommunikationstechnik sowie der übergreifenden Führungsaufgaben“ definiert (52). Ein nennenswerter Unterschied zur kritisierten Aufgabenorientierung ist nicht zu erkennen. Zwanzig Jahre nach Biethahn/Muksch/Ruf setzt eine inflationär wirkende Verwendung von ergänzenden Bezeichnungen publizierter IM-Konzepte ein: produktorientiert, integriert, industrialisiert, dienstleistungsorientiert und nachhaltig sind Beispiele. Manche Autoren verwenden diese und andere Bezeichnungen für gleiche oder nur unwesentlich voneinander abweichende Konzepte. Es entsteht der Eindruck, durch aufmerksamkeitsstarke Ansprache die Marketing-Wirkung der Publikationen vergrößern zu wollen. Dass Wirtschaftsinformatiker eine Vorliebe für Moden haben, was ihre Lehr-, Forschungs- und Entwicklungsgegen-

Einführung und Grundlegung

7

stände betrifft, ist seit Jahrzehnten bekannt (siehe Mertens). Sie neigen aber auch zu Moden in der Begrifflichkeit, auch wenn es sich „um alten Wein in neuen Schläuchen“ handelt. Zarnekow charakterisierte 2004 den produktorientierten Ansatz so: IT-Abteilung und Fachabteilungen stehen in einem Kunden-Lieferanten-Verhältnis. Die IT-Abteilung fasst die angebotenen Leistungen in Form von IT-Produkten in einem Angebotsportfolio, die Fachabteilungen stellen ihren Bedarf in einem Nachfrageportfolio zusammen. Es werden vier Klassen von IT-Produkten unterschieden: ressourcenorientierte (z. B. 1000 Blatt Druckeroutput), lösungsorientierte (z. B. Entwicklung, Betrieb und Wartung einer CAD-Lösung für die Konstruktion), prozessorientierte (z. B. Erstellung und Versand einer Rechnung) und geschäftsproduktorientierte IT-Produkte (z. B. ein digitalisiertes Finanzdienstleistungsprodukt). Verhandlungen zwischen Leistungserbringern und -abnehmern konzentrieren sich im Wesentlichen auf die Spezifikation der Produkteigenschaften, Lieferzeiten, Preise und Konditionen. IT-Produkte, die von der IT-Abteilung nicht oder nicht zu einem angemessenen PreisLeistungs-Verhältnis angeboten werden, werden von externen Lieferanten bezogen. Zarnekow/Brenner/Pilgram publizierten 2005 das von ihnen vertretene IM-Konzept mit der Bezeichnung integriertes Informationsmanagement (IIM), die aus der Forderung nach einer stärkeren Integration des Managements aller Produktionsmittel für IT-Dienstleistungen abgeleitet wird (7), „um die Forderungen der Geschäftsprozesse nach Funktonalität, Qualität, Mengen und Kosten nachhaltig optimiert erfüllen zu können“. Dies erinnert an das bereits um 1990 von Biethahn/Muksch/Ruf explizit formulierte Ziel eines ganzheitlichen Informationsmanagements. Im Mittelpunkt des Managementinteresses steht beim IIM die LieferantenKunden-Beziehung, dem durch Verfolgung des Source-Make-Deliver-Prinzips bei Herstellung und Vertrieb von IT-Dienstleistungen entsprochen werden soll. Daher ist es nicht überraschend, dass auch die Bezeichnung dienstleistungsorientiertes Informationsmanagement verwendet wird (11). Schließlich werden zusammenfassend die Vorteile des bereits erwähnten produktorientierten Ansatzes genannt. In der Legende zur Abbildung 1 heißt es – ohne weitere Erklärung – „Modell des industrialisierten Informationsmanagements“, vermutlich ein weiteres, allerdings unverständliches Synonym für IIM. Als Nachhaltigkeit zum weit verbreiteten Schlagwort wurde, war zu erwarten, dass Wirtschaftsinformatiker auch ein „nachhaltiges Informationsmanagement“ entdecken würden. Im wissenschaftlichen Schrifttum wird darüber seit 2009 berichtet. Autoren wie Schmidt et al. stellen fest (464), dass die bekannten IM-Konzepte „…bereits viele Aspekte eines nachhaltigen Informationsmanagements [beinhalten], ohne sie jedoch explizit herauszustellen.“ Beide Anmerkungen sind zweifellos zutreffend, eine dritte Anmerkung fehlt jedoch: Da Nachhaltigkeit – wie die gleichen Autoren in Erek et al. (ohne Seitenangabe) mitteilen – „als übergreifendes Ziel“ verstanden wird, „das für sämtliche Ressourcen eines Unternehmens gilt“, ist Informationsmanagement als Teil des Unternehmensmanagements ex definitionem nachhaltig, wenn Nachhaltigkeit strategisches Unternehmensziel und Gegenstand der Unternehmensstrategie ist. Ein spezifisches Modell oder Konzept des nachhaltigen Informationsmanagements ist nicht erforderlich. Unter Bezugnahme auf Hochstein et al. behaupten Erek et al., dass sich „traditionelle Ansätze im Informationsmanagement auf das Management der Entwicklung von IT-Lösungen beschränken“ (keine Seitenangabe). Dies ist eine ganz unzutreffende Beobachtung, wie die

8

Einführung und Grundlegung

kurze Erläuterung der IM-Ansätze zeigt. Beispielsweise ist das in diesem Lehr- und Handbuch verwendete IM-Modell weder ein (nur) ganzheitliches, integriertes oder nachhaltiges, es ist auch nicht (nur) produktions-, prozess- oder aufgabenorientiert, sondern erfasst dies und alles weitere durch Anpassung und Erweiterung von Denkweisen (vgl. Lerneinheit ERMOD), Zielen und Strategie-Inhalten bzw. Teilstrategien (vgl. Lerneinheiten SZIEL und STRAT) in Abstimmung mit den strategischen Unternehmenszielen und der Unternehmensstrategie. Es ist daher auch unzutreffend, von einem „Konzept der Nachhaltigkeit“, Prozessoder Dienstleistungsorientierung und insbesondere der Aufgabenorientierung zu sprechen. IM-Modelle sind zwangsläufig „aufgabenorientiert“, denn es geht in jedem von ihnen um die Erfüllung von Managementaufgaben des IT-Bereichs. Ein offensichtlicher Mangel aller Ansätze – außer dem PIM-Ansatz – ist deren explizite Orientierung auf die Analyseebenen Organisation (z. B. Unternehmen) und Organisationsteile (z. B. nach Funktionen oder Prozessen gegliederte Unternehmensteile). Nur eine Nebenrolle spielen bisher Individuen (z. B. Benutzer) und Gruppen (z. B. Projektteams) sowie die Gesellschaft. Die explizite Berücksichtigung des Informationsbedürfnisses bzw. der Nachhaltigkeit können als Anzeichen der Erweiterung des Gegenstandsbereichs des Informationsmanagements angesehen werden. Befasst sich Wirtschaftsinformatik mit Informationssystemen, findet Forschung primär auf den Analyseebenen Individuum und Gruppe statt. Sind Informationsinfrastrukturen Untersuchungsgegenstand, findet Forschung primär auf der Analyseebene Organisation oder Organisationsteil statt. Ist die Informationsfunktion Untersuchungsgegenstand, findet Forschung auf den Ebenen vom Individuum bis zur Organisation statt (nach Heinrich/Heinzl/Riedl, 21). Dies alles zeigt: Zur Erfassung des komplexen Gesamtgebiets „Informationsmanagement“ reicht keines der vorliegenden Lehr-, Fach- und Handbücher allein aus, und auch alle zusammen lassen noch Lücken erkennen. Forschungsbedarf ist nach rd. 25 Jahren wissenschaftlicher Beschäftigung mit Informationsmanagement noch vorhanden.

Zur Einordnung in Wissenschaftsdisziplinen Führungsaufgaben der Informationsfunktion gibt es, seit es organisierte Zweckgebilde – wie Unternehmen und Behörden – gibt. So betrachtet ist Informationsmanagement nichts Neues. Was rechtfertigt es, derartige Führungsaufgaben explizit herauszuheben? Eine Antwort lautet: Während die Führungsaufgaben der Informationsfunktion zuerst auf der operativen Ebene, zur Zeit der „klassischen Datenverarbeitung“ weitgehend auf der administrativen Ebene angesiedelt waren und gelöst werden konnten, haben sie heute einen Umfang und eine Komplexität erreicht, die ihnen auch eine strategische Bedeutung für eine Organisation als Ganzes geben. Zur Begründung sind folgende Beobachtungen hilfreich: 

Der von der IT ausgehende Entwicklungsdruck ermöglicht eine Assimilation im Sinne eines evolutionären Prozesses nur auf der Grundlage bewusster, planmäßiger Vorgehensweisen. Damit verlagert sich die Betrachtung von der Vielfalt der Technologien, also von der physischen Sicht auf die Informationsinfrastruktur, auf die logische Ebene der Strukturen und Abläufe für Information und Kommunikation, also auf die Informationsfunktion.

Einführung und Grundlegung







9

Die Budgets, die vom Top-Management für die IT zur Verfügung gestellt werden oder deren Verfügbarkeit vom IT-Management gefordert wird, haben sich in vielen Organisationen zu einem beachtlichen Kostenfaktor entwickelt. Den Kosten steht – nach Auffassung mancher Top-Manager – ein entsprechender Nutzen nicht gegenüber, oder er kann nicht überzeugend nachgewiesen werden. Carr weist darauf hin, dass mit dem Herauswachsen der Organisationen aus dem „Zeitalter der Datenverarbeitung“ häufig progressiv steigende Kosten für die IT einhergingen. Information wird als Produktionsfaktor begriffen, der nicht nur neben die bekannten Produktionsfaktoren tritt, sondern diese in einem erheblichen Umfang ersetzt, was insbesondere auf die Entwicklung der Kosten der klassischen Produktionsfaktoren zurückzuführen ist, wie Abbildung EINGR-2 schematisch zeigt. Informationsmanagement ist nicht Stückkosten mehr nur auf die Gestaltung der Geschäftsprozesse bestehender GeschäftsInformation modelle (Prozessunterstützung) ausgeBetriebsgerichtet, sondern auch auf die Gemittel staltung von Produkten (materielle Güter und Dienstleistungen). Dies erfolgt, Material indem Produkte durch IT-unterstützte (Werkstoffe) Funktionen angereichert und modifiziert werden, sowie durch EntwickArbeit lung, Herstellung und Vermarktung neuer Produkte und deren WeiterentZeit wicklung (Produktunterstützung). InAbb. EINGR-2: Tendenzieller Stückkostenverlauf formationsmanagement und Produktder Produktionsfaktoren (Quelle: nach Pfohl) management als betriebliche Funktionen wachsen zusammen; beide streben danach, durch IKT-Einsatz Leistungspotenzial und Erfolgspotenzial zu schaffen, auszuschöpfen und in Nutzen umzusetzen.

Auf der Grundlage dieser Erläuterung wird die Frage nach der Einordnung des Informationsmanagements in Wissenschaftsdisziplinen wie folgt beantwortet: Da der Aufgabenschwerpunkt nicht im Management der Organisation, sondern im Management der Informationsfunktion und ihrer Informationsinfrastruktur als Objektbereich liegt, bietet sich eine Einordnung in die Managementlehre und damit in die Betriebswirtschaftslehre nicht an. Das schließt nicht aus, dass die Managementlehre Beiträge zur Erklärung des Informationsmanagements und zur Gestaltung ihres Objektbereichs liefern und insbesondere Managementtechniken zur Unterstützung der IM-Führungsaufgaben für die Praxis zur Verfügung stellen kann. Da Informationsfunktion und Informationsinfrastruktur Erkenntnisobjekte der Wirtschaftsinformatik sind, besteht ein so enger sachlicher Zusammenhang, dass Informationsmanagement als Teilgebiet der Wirtschaftsinformatik anzusehen ist, das von steigender praktischer Bedeutung und hohem wissenschaftlichen Interesse ist. Die von Peterhans (8) vertretene Auffassung, Informationsmanagement sei eine „eigenständige wissenschaftliche Disziplin“, kann nicht geteilt werden. Vom Informationsmanagement zu unterscheiden ist Informationswissenschaft, ursprünglich eine Disziplin, die sich mit Information im Zusammenhang mit Dokumentation sowie

10

Einführung und Grundlegung

mit der Klassifikation von Wissensgebieten befasst hat. Mit der Ausbreitung der Informations- und Kommunikationstechnik in Wirtschaft und Verwaltung hat sich ihr Interesse auf Informationssysteme verlagert (vgl. z. B. die bereits 1968 erfolgte Umbenennung des American Documentation Institute in American Society of Information Science). Damit ist Information in den Mittelpunkt der Informationswissenschaft gerückt. Ziel der Informationswissenschaft ist es, den Informations- und Kommunikationsprozess zu erklären und zu gestalten, und zwar unabhängig von der Art des Aufgabensystems. Die Wirtschaftsinformatik weist im Bereich der Allgemeinen Wirtschaftsinformatik eine gewisse Deckungsgleichheit mit dieser Art von Informationswissenschaft auf. Die Unterschiede zwischen Informationsmanagement im Sinne der Informationswissenschaft und als Teildisziplin der Wirtschaftsinformatik sind dagegen grundsätzlicher Art (vgl. die Forschungsbefunde). Im Unterschied dazu entspricht Informationswirtschaft weitgehend dem Informationsmanagement, allerdings nur dann, wenn darunter „Information Engineering and Management“ verstanden wird.

Zur Gliederung des Lernstoffs Der Lernstoff ist zunächst wie folgt in Kapitel gegliedert:      

Grundlagen des Informationsmanagements Strategische Aufgaben des Informationsmanagements Administrative Aufgaben des Informationsmanagements Methoden des strategischen Informationsmanagements Methoden des administrativen Informationsmanagements Fallstudien Informationsmanagement

Die vor jedem Kapitel eingefügte grafische Darstellung verwendet diese Struktur und visualisiert durch graue Unterlegung der entsprechenden Kapitelbezeichnung den „Standort“ des Benutzers. Die in der Praxis ausgefeilte Handhabung und gute Sachkenntnis und daraus folgend die geringe Bedeutung des operativen Managementhandelns für die akademische Lehre sind der Grund dafür, seit der neunten Auflage dieses Lehr- und Handbuchs operative Aufgaben und Methoden nicht mehr darzustellen. Dafür spricht auch, dass operative Aufgaben zunehmend automatisiert werden, indem sie Anwendungssystemen als Aufgabenträgern zugeordnet werden (z. B. die Arbeitsvorbereitung im Rechenzentrum). Auf der zweiten Ebene erfolgt eine Gliederung in Lerneinheiten. Jede Lerneinheit (außer den vier „Fallstudien Informationsmanagement“) hat auf der dritten Ebene folgende Struktur:      

Abschnitt 1: Lernziele, die beim Durcharbeiten der Lerneinheit erreicht werden sollen. Abschnitt 2: Definitionen und Abkürzungen, die in der Lerneinheit verwendet werden; dabei wird auch die Übersetzung ins Englische angegeben. Abschnitt 3: Stoffinhalt der Lerneinheit (Lernstoff), der in Teilabschnitte gliedert ist. Abschnitt 4: Forschungsbefunde zum Lernstoff. Anmerkung: Die in älteren Befunden verwendeten Bezeichnungen DV = Datenverarbeitung und IV = Informationsverarbeitung wurden durch das heute überwiegend verwendete Kürzel IT ersetzt. Abschnitt 5: Aus der Praxis mit Hinweisen auf Probleme und Problemlösungen. Abschnitt 6: Methodenverweise zur Aufgabe bzw. Aufgabenverweise zur Methode mit Verweisen auf die Fallstudien.

Einführung und Grundlegung

    

11

Abschnitt 7: Kontrollfragen zum Lernstoff. Abschnitt 8: Quellen, aus denen Lernstoff entnommen wurde, soweit es sich um zitierwürdige Aussagen handelt. Auch Domain-Namen werden genannt. Abschnitt 9: Vertiefungsliteratur, die ein weitergehendes Selbststudium lenken soll. Abschnitt 10: Informationsmaterial (z. B. graue Literatur wie Institutsberichte, Zeitungsmeldungen, soweit sie nicht zitiert wurden). Abschnitt 11: Normen.

Abschnitt 2 mit den Definitionen der in einer Lerneinheit verwendeten Kernbegriffe und die Erklärung der Abkürzungen sind ganz bewusst vor dem Lernstoff angeordnet. Dies soll die Lernenden dazu anregen, sich mit der in der Lerneinheit verwendeten Fachsprache vertraut zu machen, bevor sie sich mit dem Lernstoff selbst auseinander setzen; die Hinzuziehung eines Wirtschaftsinformatik-Lexikons wird empfohlen. Diese Struktur hat auch den Vorteil, den Lernstoff von definitorischen Ausführungen weitgehend freizuhalten und damit seine Verständlichkeit zu erleichtern. Was in jeder Lerneinheit nach dem Abschnitt Definitionen und Abkürzungen steht, ist Inhalt zur Lerneinheit und nicht Erklärung von Fachsprache. Die Definitionen beziehen sich explizit auf den Lernstoff und sind daher häufig lernstoffspezifisch; es kann daher für einen Begriff (z. B. für Erfolgsfaktor) mehrere Bedeutungen geben, und es gibt Definitionen, die in einem anderen Kontext als dem des Lernstoffs einer Lerneinheit nicht zutreffend, zumeist nicht allgemein genug formuliert sind (z. B. Abweichung). Alle in diesem Lehr- und Handbuch verwendeten Definitionen und Abkürzungen finden sich auf der Website http://www.informationsmanagement-buch.org. In Abschnitt 4 wird besonderer Wert auf empirische Forschungsbefunde gelegt. Ihre Anzahl und Qualität sind bei den meisten Themen aber nicht so umfangreich, dass in allen Lerneinheiten Forschungsbefunde angegeben werden können. Als Forschungsbefunde werden nur solche Aussagen in wissenschaftlichen Publikationen bezeichnet, die auf Grund einer erkennbaren und anerkannten, wenn auch nicht immer explizit angegebenen wissenschaftlichen Untersuchungsmethode erarbeitet wurden (z. B. Befragung, Feldstudie, Laborexperiment, mehr dazu bei Heinrich/Heinzl/Riedl, 97–109). Damit soll vor allem jede Art von persönlicher Meinung oder persönlicher praktischer Erfahrung als „Forschungsbefund“ ausgeschlossen werden, über die gegebenenfalls in Abschnitt 5 berichtet wird. Die Abschnitte 4, 5 und 6 sowie 10 und 11 sind nicht in allen Lerneinheiten besetzt. Etliche Lerneinheiten enthalten Abbildungen, die entweder aus kenntlich gemachten Quellen stammen (deren bibliografische Angaben sich im Abschnitt Quellen befinden) oder Originalabbildungen der Autoren sind. Auf die in wissenschaftlichen Veröffentlichungen notwendige und übliche Zitierweise wird wegen des Lehr- und Handbuchcharakters dieser Veröffentlichung verzichtet, doch werden bei wörtlichen oder sinngemäßen Übernahmen aus fremden Quellen die Namen der Autoren angegeben; die bibliografischen Daten sind dem Abschnitt Quellen zu entnehmen. Hervorhebungen im Druck sind fett, Eigennamen sind, wenn sie Quellen betreffen, kursiv gedruckt. Fettdruck wird für die Überschriften der Lerneinheiten und ihrer Abschnitte sowie für die Kernbegriffe verwendet; von wenigen Ausnahmen abgesehen (z. B. Bezeichnung der Abschnitte Lernziele, Definitionen und Abkürzungen) erscheinen fett gedruckte Begriffe im Schlagwortverzeichnis.

12

Einführung und Grundlegung

Forschungsbefunde Herzwurm/Stelzer haben die Forschungsinhalte der im deutschen Sprachraum verbreiteten Wirtschaftsinformatik denen des Information Systems, der im anglo-amerikanischen Raum verbreiteten Wissenschaftsdisziplin bzw. Teildisziplin des Business Administration, gegenübergestellt, u. a. mit folgenden Ergebnissen (Literaturanalyse anhand der nach Wissenschaftskriterien ausgewählten Zeitschriften WIRTSCHAFTSINFORMATIK und HMD – Praxis der Wirtschaftsinformatik bzw. MIS Quarterly und Communications of the ACM, 2410 zwischen 1994 und 2001 publizierte Beiträge): Eines der beiden Top-Forschungsthemen der Wirtschaftsinformatik ist Informationsmanagement. Und: In der IS-Forschung nimmt Informationsmanagement eine alle anderen Themen überragende Stellung ein. Schlögl berichtet als Befund einer szientometrischen Studie (quantitative Analyse der IMKernpublikationen, Titelwortsuche, Untersuchungszeitraum 1999) über ein sprunghaftes Ansteigen des Publikationsvolumens zu Beginn der 1980er Jahre. „Man kann also davon ausgehen, dass es sich bei Informationsmanagement um kein Modethema handelt.“ (5) Mit der Autoren-Kozitationsanalyse wurden Informationswissenschaft und Wirtschaftsinformatik bzw. Information Systems (IS) als Referenzdisziplinen identifiziert. Informationswissenschaft konzentriert sich auf die Informationsinhalte; der Fokus von Wirtschaftsinformatik bzw. IS „liegt im effektiven Einsatz von computerbasierten Informationssystemen in Organisationen (technologieorientiertes Informationsmanagement)“. Im Ergebnis wird u. a. festgestellt, dass die meisten Autoren aus dem Bereich Wirtschaftsinformatik bzw. IS die Auffassung vertreten, dass Informationsmanagement die Planung, Organisation und Kontrolle der IT-Infrastruktur umfasst. Teubner/Klein (25) formulieren folgenden Befund einer Bestandsaufnahme zum Informationsmanagement (Literaturanalyse, fünf deutschsprachige Lehrbücher mit Erscheinungsjahr 2000 bis 2002): „Ein Konsens darüber, was eigentlich Informationsmanagement ist und welche Rolle ihm im Rahmen der Wirtschaftsinformatik zukommen sollte, ist nicht erkennbar.“ Das vorliegende Lehr- und Handbuch wird in seiner 7. Aufl. 2002 als „das erste deutschsprachige Lehrbuch zum Informationsmanagement und zudem wohl auch das am stärksten rezipierte Werk“ bezeichnet (3). Krcmar hatte 1991 unter Bezugnahme auf die 1. Aufl. 1987 des nun in 10. Aufl. vorliegenden Lehr- und Handbuchs festgestellt (178): Die Autoren „greifen als erste in umfassender Lehrbuchform das Informationsmanagement auf“. Seibt stellt in einer vergleichenden Beurteilung der IM-Ansätze fest, dass sich der PIMAnsatz wesentlich vom IRM-Ansatz und vom leitungszentrierten Ansatz unterscheidet. Daraus wird folgende Schlussfolgerung gezogen (13): „Die Aspekte der auf das Individuum ausgerichteten Optimierung von Informationsverarbeitungs- und Kommunikationsprozessen, denen der PIM-Ansatz gewidmet ist, werden in Zukunft zweifellos an Bedeutung gewinnen. Es bietet sich an, den PIM-Ansatz als Ergänzung zum IRM-Ansatz und zum leitungszentrierten IM-Ansatz zu verwenden.“ Dieser Befund entspricht der weiter oben geäußerten Beobachtung, dass Informationsmanagement-Forschung bisher primär auf der Analyseebene Organisation oder Organisationsteil stattgefunden hat.

Einführung und Grundlegung

13

Aus der Praxis Das Beratungsunternehmen Hosenfeld Consulting demonstriert mit folgender Erklärung die Wirkung der vom Marketing geprägten IT-Begriffe in der Praxis: „Informationssysteme sind häufig die Voraussetzung für ein nachhaltiges Informationsmanagement größerer Informationsmengen. … Was verstehen wir unter Nachhaltigem Informationsmanagement? Ganz kurz: Unter diesem Begriff fassen wir die möglichst effektive Ausnutzung von Informationen. Informationen, die einmal erhoben, ermittelt oder erarbeitet wurden, sollen möglichst vielseitig eingesetzt werden. Sie müssen sowohl in größeren Gesamtkontexten betrachtet werden können als auch problemlos wiedergefunden werden können.“ Die IT-Beauftragte der Bundesregierung zitiert in ihrem 1. Newsletter zu Green-IT die Staatssekretärin im Bundesministerium des Innern, die beim ersten Green-IT-Tag der Bundesverwaltung betont hat: Der Nachhaltigkeitsgedanke in der IKT und insbesondere der energieeffiziente Einsatz von Produkten der IKT muss in jeder Organisation eine bedeutendere Rolle als bisher spielen. In allen Ressorts der Bundesverwaltung soll bis zum Jahre 2013 der Energieverbrauch um 40 % gesenkt werden. Das Forschungsinteresse der Praxis am Informationsmanagement zeigt folgendes Beispiel: Im Jahre 2011 verleiht die INTARGIA Managementberatung zum dritten Mal den mit 10.000.- Euro dotierten TARGION Wissenschaftspreis für eine herausragende, an einer deutschsprachigen wissenschaftlichen Hochschule abgeschlossene Dissertation im Bereich des strategischen Informationsmanagements. Kontrollfragen 1. Welche Phänomene werden mit Information, Wissen und Daten sowie mit Management bezeichnet? 2. Wie kann das Konstrukt Informationsmanagement erklärt werden? 3. Welche Gemeinsamkeiten und welche Unterschiede bestehen zwischen der Informationsfunktion und anderen betrieblichen Funktionen? 4. Welche IM-Ansätze gibt es neben dem leitungszentrierten Ansatz und wodurch unterscheiden sie sich? 5. Welche Bedeutung haben die sogenannten Analyseebenen für die Beurteilung des Erklärungsbedarfs eines Wissenschaftsgebiets und damit des Informationsmanagements? Quellen Biethahn, J. / Mucksch, H. / Ruf, W.: Ganzheitliches Informationsmanagement. München 1990 Carr, N. G.: IT Doesn't Matter. In: Harvard Business Review 5/ 2003, 41–49 Earl, M. (Ed.): Information Management – The Strategic Dimension. Oxford 1989 Erek, K. / Schmidt, N.-H. / Zarnekow, R. / Kolbe, L. M.: Nachhaltiges Informationsmanagement – Strategische Optionen und Vorgehensmodell zur Umsetzung. http://subs.emis.de/LNI/Proceedings/Proceedings154/gi-proc154-312.pdf2; Abruf 2.5.2011 Finkelstein, C.: Information Engineering. Strategic Systems Development. Reading/MA 1992 Heinrich, L. J. / Heinzl, A. / Riedl, R.: Wirtschaftsinformatik – Einführung und Grundlegung. 4. Aufl., Springer, Berlin et al. 2011 Herzwurm, G. / Stelzer, D.: Wirtschaftsinformatik versus Information Systems – Eine Gegenüberstellung. Ilmenauer Beiträge zur Wirtschaftsinformatik Nr. 2008-01 zugleich Stuttgarter Schriften zur Unternehmenssoftware – Arbeitsbericht Nr. 2. Ilmenau, Stuttgart 2008 Hosenfeld Consulting: http://www.ho-con.de/infoman.htm; Abruf 2.5.2011 INTARGIA Managementberatung: www.intargia.com/deutsch/veranstaltungen/targion/index.php; Abruf 5.5.2011 IT-Beauftragte der Bundesregierung (BfIT): 1. Newsletter zu Green-IT: http://www.umweltbundesamt.de/produkte/dokumente/newsletter_bfit_intelligente_vergabe.pdf; Abruf 2.5.2011 König, W. / Ludwig, J.-Ch.: Vergleichende Buchbesprechung „Informationsmanagement“. In: WIRTSCHAFTSINFORMATIK 4/1993, 405–410 Krcmar, H.: Informationsmanagement. 5. A., Berlin et al. 2010

14

Einführung und Grundlegung

Kuhlen, R.: Informationsmarkt. Chancen und Risiken der Kommerzialisierung von Wissen. Konstanz 1995 Martin, J.: Information Engineering. Book I Introduction. Englewood Cliffs/NJ 1989, Book II Planning & Analysis. Englewood Cliffs/NJ 1990, Book III Design & Construction. Englewood Cliffs/NJ 1990 Mertens, P., Wirtschaftsinformatik – Von den Moden zum Trend. In: König, W. (Hrsg.), Wirtschaftsinformatik '95, Wettbewerbsfähigkeit – Innovation – Wirtschaftlichkeit. Heidelberg 1995, 25–64 Österle, H. / Brenner, W. / Hilbers, K.: Unternehmensführung und Informationssystem. Der Ansatz des St. Galler Informationssystem-Management. 2. A., Stuttgart 1992 Pfohl, H.-Chr.: Produktionsfaktor „Information“ in der Logistik. In: Institut für Logistik der Deutschen Gesellschaft für Logistik (Hrsg.): Informationssysteme in der Logistik. Dortmund 1985 Probst, G. J. B. / Raub, S. / Romhardt, K.: Wissen managen. Wie Unternehmen ihre wertvollste Ressource optimal nutzen. 5. A., Wiesbaden 2006 Renkema, T. J. W.: The IT Value Quest. How to Capture the Business Value of IT-Based Infrastructure. Chichester et al. 1999 Roszak, T.: Der Verlust des Denkens. Über die Mythen des Computer-Zeitalters. München 1986 Schmidt, N.-H. / Erek, K. / Kolbe, L. M. / Zarnekow, R.: Nachhaltiges Informationsmanagement. In: WIRTSCHAFTSINFORMATIK 5/2009, 463-466 (WI – SCHLAGWORT) Schmidt-Reindl, K. M.: Informationsmanagement erobert Unternehmen und Behörden. In: GMD-Spiegel 1988, 67– 72 Schwarzer, B. / Krcmar, H.: Zur Prozessorientierung des Informationsmanagements. In: WIRTSCHAFTSINFORMATIK 1/1995, 33–39 Seibt, D.: Begriff und Aufgaben des Informationsmanagements – ein Überblick. In: Preßmar, B. (Hrsg.): Informationsmanagement. Wiesbaden 1993, 3–30 Shannon, C. E. / Weaver, W.: Mathematical Theory of Communication. 4. Ed., Urbana/Ill. 1968 Szyperski , N.: Gesamtbetriebliche Perspektiven des Informationsmanagements. In: Strunz, H. (Hrsg.): Planung in der Datenverarbeitung. Von der DV-Planung zum Informations-Management. Berlin et al. 1985, 6–20 Teubner, A. / Klein, St.: Bestandsaufnahme aktueller deutschsprachiger Lehrbücher zum Informationsmanagement. Arbeitsbericht Nr. 86 des Instituts für Wirtschaftsinformatik der Universität Münster, März 2002 Wiener, N.: Cybernetics or Control and Communication in the Animal and the Machine. Boston 1948 Wilder, R. P.: The Continuing Revolution of Information Systems Planning. In: Strunz, H. (Hrsg.): Planung in der Datenverarbeitung. Von der DV-Planung zum Informations-Management. Berlin et al. 1985, 21–37 Wittmann, W.: Information. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Stuttgart 1980, 894– 904 Zarnekow, R.: Produktorientiertes Informationsmanagement. In: Zarnekow, R. / Brenner, W. / Grohmann, H. (Hrsg.): Informationsmanagement. Konzepte und Strategien für die Praxis. Heidelberg 2004, 41–56 Zarnekow, R. / Brenner, W. / Pilgram, U.: Integriertes Informationsmanagement. Berlin/Heidelberg 2005 Vertiefungsliteratur Beier, D.: Informationsmanagement aus Sicht der Betriebswirtschaftslehre. Frankfurt a. M. et al. 2002 Hochstein, A. / Brenner, W. / Uebernickel, F.: Operations Management and IS. In: Proceedings oft he Twelfth Ammericas Conference on Information Systems. Acapulco, Mexiko, August 2006 Leimstoll, U.: Informationsmanagement in mittelständischen Unternehmen. Frankfurt a. M. et al. 2001 Peterhans, M.: Informationsmanagement – Theoretische Grundlagen und Führungskonzept. Zürich 1996 Pietsch, T. / Martiny, L. / Klotz, M.: Strategisches Informationsmanagement. Bedeutung und organisatorische Umsetzung. 4. A., Berlin 2004 Voß, St. / Gutenschwager, K.: Informationsmanagement. Berlin et al. 2001 Schlögl, C.: Bestandsaufnahme Informationsmanagement. Wiesbaden 2001 Stickel, E.: Informationsmanagement. München/Wien 2001 Teubner, A. / Klein, St.: Vergleichende Buchbesprechung „Informationsmanagement“. In: WIRTSCHAFTSINFORMATIK 4/2002, 285–299 Wall, F.: Informationsmanagement – Eine ökonomische Integration von Controlling und Wirtschaftsinformatik. München 2006

A. GRUNDLAGEN DES INFORMATIONSMANAGEMENTS

strategische Ebene

administrative Ebene

operative Ebene

Grundlagen des Informationsmanagements

Methoden des Informationsmanagements

Aufgaben des Informationsmanagements

Fallstudien Informationsmanagement

16

Grundlagen des Informationsmanagements

Gegenstand dieses Kapitels sind die Grundlagen des Informationsmanagements. Zunächst wird das Modell des Informationsmanagements entwickelt, das die systematische Ordnung der Aufgaben und Methoden des Informationsmanagements erlaubt und an dem sich deren Darstellung und Erläuterung im weiteren Verlauf des Buches orientieren. Anschließend wird das Stellenbild des Informationsmanagers und anderer dem Informationsmanagement zugehörender Rollen dargestellt. Mit der Erläuterung der Architektur der Informationsinfrastruktur werden die Grundlagen für die strategische IT-Planung entwickelt. Anschließend werden IT-Governance und deren Beziehung zum sowie Bedeutung für das Informationsmanagement geklärt. Außerdem werden die rechtlichen Rahmenbedingungen erörtert, die für das Informationsmanagement von Bedeutung sind, und es werden Grundlagen des menschlichen Informations- und Kommunikationsverhaltens dargestellt. Erklärungsmodell (ERMOD) ................................................................................................. 17 Stellenbilder (STELL)............................................................................................................ 31 Architektur der Informationsinfrastruktur (ARCHI).............................................................. 43 Governance (GOVER) ........................................................................................................... 55 Informationsrecht (RECHT) .................................................................................................. 67 Informationsverhalten (INVER) ............................................................................................ 79

Erklärungsmodell (ERMOD) Lernziele Sie kennen den Zweck und die Struktur des Informationsmanagement-Modells (IM-Modell) und können für jede der drei Managementebenen typische Aufgaben und Methoden nennen. Sie können die Denkweisen und Ziele des Informationsmanagements erläutern und kennen den Unterschied zwischen Sachzielen und Formalzielen. Sie erkennen, dass ein unternehmensspezifisches Konzept des Informationsmanagements (IM-Konzept) auf Grundlage eines IM-Modells entwickelt werden muss. Sie können den Entwicklungsprozess für IM-Konzepte beschreiben und erkennen die Zweckmäßigkeit der Verwendung von Referenzmodellen.

Definitionen und Abkürzungen Aufgabenträger (task bearer) = Mensch (Person oder Gruppe) oder Mensch/TechnikSystem, dem eine Aufgabe zur Aufgabenerfüllung übertragen ist. Entwurfsmuster (design pattern) = wiederverwendbare Vorlage zur Lösung eines Entwurfsproblems, die in einem spezifischen Kontext genutzt werden kann. Erfolgspotenzial (success potential) = durch Art und Umfang verwendeter Technologien bestimmte Fähigkeit der Informationsinfrastruktur, Leistungspotenzial der Informationsfunktion in Unternehmenserfolg umzusetzen. Geschäftsmodell (business model) = Modell, das Aussagen darüber macht, durch welche Kombination von Produktionsfaktoren die Unternehmensstrategie verfolgt wird, wie Erlöse erzielt werden und welche Rolle die daran beteiligten Akteure spielen. Handlungsspielraum (action scope) = mehrdimensionaler Begriff, der Entscheidungsspielraum, Tätigkeitsspielraum und Freiheitsspielraum umfasst. Information Engineering = Methodik des Informationsmanagements im Sinne einer Lehre von den Methoden und ihrer planmäßigen, wissenschaftlichen Anwendung. Informationsfunktion (information function) = Teilmenge des betrieblichen Aufgabensystems, dessen Zwecke Information und Kommunikation sind. Informationsinfrastruktur (information infrastructure) = Einrichtungen, Mittel und Maßnahmen zur Beschaffung, Verteilung und Nutzung von Information und Ermöglichung von Kommunikation. kritischer Wettbewerbsfaktor (critical competitive factor) = Wettbewerbsfaktor, der für den Erfolg oder Misserfolg des Unternehmens maßgeblich bestimmend ist. Leistungspotenzial (performance potential) = durch Art und Umfang der Informations- und Kommunikationsaufgaben möglicher Beitrag der Informationsfunktion zum Unternehmenserfolg. Rationalisierung (rationalization) = Vorgehensweise, ein System so zu gestalten, dass es gesetzten Zielen besser entspricht (von lat. ratio = Vernunft). Referenzmodell (reference model) = eine zweckorientierte Spezifikation des generellen Modellbegriffs, die als Vorlage für das Gestalten von Artefakten dient.

18

Grundlagen des Informationsmanagements

Zweck des IM-Modells Modell (nach dem aus lat. modellus [Diminutiv, d. h. Verkleinerung von Modus, Maß] gebildeten ital. modello) ist ein in der Umgangssprache und in der Fachsprache vieler Wissenschaften häufig verwendeter Begriff. Seine Bedeutung lässt sich allgemein als die konkrete, fassliche und leicht realisierbare Darstellung unübersichtlicher Gegenstände und Phänomene umschreiben. Im vorliegenden Zusammenhang bedeutet Modell die Konstruktion eines Vorbilds für die Wirklichkeit, nämlich eines Vorbilds für die Entwicklung eines IM-Konzepts. In der Fachsprache wird neben vielen anderen Unterscheidungen zwischen Erklärungsmodell und Gestaltungsmodell unterschieden. Das Modell des Informationsmanagements (IMModell) ist ein Erklärungsmodell, das IM-Konzept ist Gestaltungsmodell. Eine Informationsinfrastruktur – im Folgenden auch kurz als Infrastruktur bezeichnet – als physische Realisierung eines IM-Konzepts ist ein soziotechnisches Artefakt, das menschliche Aufgabenträger bei der Aufgabenerfüllung unterstützt, insbesondere – aber nicht nur – mit Hilfe von Informations- und Kommunikationstechnologien. Um ein Erklärungsmodell im Sinne einer Theorie des Informationsmanagements handelt es sich, wenn ein Explanans bzw. wenn Ursache-Wirkungs-Beziehungen vorhanden sind. In der Wirklichkeit an Informationsfunktionen und Informationsinfrastrukturen beobachtete Ereignisse oder Vorgänge können auf ihre Ursachen zurückgeführt werden. Es sind, mit anderen Worten, Variable und mit Variablen formulierte und geprüfte Hypothesen, welche Erklärungsmodelle und damit die Entwicklung von Theorien konstituieren. Darauf wurde bereits in „Einführung und Grundlegung“ hingewiesen. In dieser Lerneinheit wird dies mehrmals exemplarisch gezeigt, wobei meist die Formulierung der Art „Wenn Ursache a, dann Wirkung b“ verwendet wird. Das IM-Modell erfasst die nach einem Drei-EbenenModell systematisierten Aufgaben des Informationsmanagements und die Methoden & Techniken zur Unterstützung der Aufgabendurchführung sowie die innerhalb dieser beiden Komponenten sowie zwischen ihnen bestehenden Beziehungen. Von den Aussagen des IMModells ausgehend, werden unternehmensspezifische IM-Konzepte entwickelt, welche die Aufgaben und Methoden und deren Beziehungen als einen logischen Systementwurf beschreiben, der Grundlage für die Implementierung ist und deren Ergebnisse in eine bestehende Struktur- und Ablauforganisation eingefügt werden. Um zu einem IM-Modell im Sinne eines Erklärungsmodells zu gelangen, sind folgende Fragen zu beantworten:   

Was heißt „Informationsfunktion“ und was „Informationsinfrastruktur“ und in welchem Verhältnis stehen beide zueinander? Von welchen Denkweisen sollten sich Aufgabenträger des Informationsmanagements leiten lassen (Methodik des Informationsmanagements)? Welche Sach- und Formalziele des Informationsmanagements sind für die Modellentwicklung relevant?

Erklärungsmodell (ERMOD)

19

Informationsfunktion und Informationsinfrastruktur Ausgangspunkt für die Konstruktion des IM-Modells ist die Tatsache, dass in jedem Unternehmen Aufgaben erfüllt werden, deren Zweck das Beschaffen, Verteilen und Verwenden von Information und damit auch Kommunikation ist, kurz: Informations- und Kommunikationsaufgaben. Jede dieser Aufgaben wird durch eine Anzahl von Tätigkeiten erfüllt. Die Gesamtheit der Aufgaben ist eine betriebliche Funktion, die als Informationsfunktion bezeichnet wird (vgl. die Erklärungen zu Abbildung EINGR-1). In jeder betrieblichen Funktion gibt es Aufgaben, deren Zweck das Beschaffen, Verteilen und Verwenden von Information und Kommunikation ist. Der durch Art und Umfang dieser Aufgaben mögliche Beitrag der Informationsfunktion zum Unternehmenserfolg (mit anderen Worten zur Wertschöpfung) ist ihr Leistungspotenzial. Mit Mächtigkeit der Informationsfunktion ist der relative Anteil der Informations- und Kommunikationsaufgaben an den Aufgaben des Unternehmens gemeint, und Art der Informations- und Kommunikationsaufgaben meint deren charakteristische Merkmale wie Strukturiertheit und Veränderlichkeit, die in ordinalen Kategorien (wie gering / mittel / hoch) gemessen und bei der Abschätzung des Leistungspotenzials verwendet werden. (Zum Bestimmen des Leistungspotenzials vgl. Lerneinheit SITAN.) Zweck der Informationsinfrastruktur ist die unternehmensweite Deckung der Informationsnachfrage für alle in einem Unternehmen auftretenden internen und externen Verwendungszwecke zur Erfüllung der Informations- und Kommunikationsaufgaben. Sie besteht aus einem „System von Informationssystemen“ und weiteren materiellen und immateriellen Komponenten, die über Informationssysteme hinausgehende Aktionen zur Entwicklung, Einführung und Nutzung erfordern. Die Informationsinfrastruktur soll sicherstellen, dass Information unternehmensweit bedarfsgerecht und wirtschaftlich produziert, angeboten und verteilt und wie andere Produktionsfaktoren zur Aufgabenerfüllung beschafft und verwendet wird. Das Erfolgspotenzial der Informationsinfrastruktur ist das Ausmaß, in dem das Leistungspotenzial der Informationsfunktion als Unternehmenserfolg ausgeschöpft werden kann, mit anderen Worten der Beitrag der IT zur Wertschöpfung. Informationsinfrastruktur umfasst alle Ressourcen zur Produktion, Verteilung und Nutzung von Information und zur Kommunikation. Ihre Komponenten sind (vgl. Heinrich/Heinzl/Riedl, 283 ff.):        

personelle Infrastruktur (IT-Personal und IT-Unterstützer), organisatorische Infrastruktur (Aufbau- und Ablauforganisation), technische Infrastruktur (Technikinfrastruktur, IT-Infrastruktur), räumliche Infrastruktur wie Standorte und Architektur von Rechenzentren, Entwicklungsmethoden wie Phasen- und Vorgehensmodelle oder methodische Bausteine dafür wie Modellierung, Prototyping und Simulation, Managementsysteme wie Projektmanagement, Qualitätsmanagement, Kosten- und Leistungsrechnung, IT-Revision und IT-Controlling, informationsrechtliche Infrastruktur (Infrastrukturrecht) sowie sonstige Infrastruktur wie Standards, Normen, Leitfäden, Referenzmodelle für einzelne oder alle Infrastrukturkomponenten.

Jedes Unternehmen hat eine spezifische Informationsinfrastruktur, so wie es eine spezifische Informationsfunktion hat. Carr prognostiziert deren Verschwinden, insbesondere das der

20

Grundlagen des Informationsmanagements

Technikinfrastruktur, womit andere Komponenten teilweise oder ganz überflüssig werden. So wie im 20. Jahrhundert die unternehmenseigene Infrastruktur zur Energieversorgung durch „Elektrizität aus der Steckdose“ aus ökonomischen Gründen verdrängt wurde, werde im 21. Jahrhundert die unternehmenseigene IT-Infrastruktur verschwinden. „Informationsfabriken“ werden dann jedem Unternehmen Cloud Computing (Computerleistung aus der Steckdose) ermöglichen, so wie Energieversorgungsunternehmen elektrische Energie zur Verfügung stellen – unternehmenseigene „Informationsfabriken“ wird es kaum noch geben. Dieser Prognose wird zwar entschieden widersprochen, sicher ist aber, dass Cloud Computing die Informationsinfrastruktur wesentlich verändern wird. Viele IT-Aufgaben werden durch „infrastructure-as-a-service“ ersetzt werden (vgl. Lerneinheit INMAN). Daraus folgen einige Hypothesen für das IM-Modell, beispielsweise folgende: Wenn das Leistungspotenzial der Informationsfunktion gegenwärtig gering ist und für einen bestimmten Planungszeitraum als gering prognostiziert wird, dann ist das durch die Informationsinfrastruktur aufzubauende Erfolgspotenzial ebenfalls gering. Investitionen in die Informationsinfrastruktur zum Aufbau von Erfolgspotenzial, das wegen des geringeren Leistungspotenzials der Informationsfunktion nicht genutzt werden kann, sind ökonomisch sinnlos. Und weiter: Wenn das Leistungspotenzial der Informationsfunktion und das Erfolgspotenzial der Informationsinfrastruktur gering sind, ist der Umfang der Aufgaben des Informationsmanagements ebenfalls gering, vor allem auf der strategischen Managementebene (z. B. wird weder ein CIO noch ein Lenkungsausschuss gebraucht, vgl. Lerneinheit STRUK). Ziele und Aufgaben des Informationsmanagements sind also letztlich dem Leistungspotenzial der Informationsfunktion entsprechend zu definieren.

Methodik des Informationsmanagements Methodik meint erstens die Anweisung zur folgerichtigen und zweckmäßigen Lösung eines in der Regel komplexen und/oder komplizierten praktischen oder wissenschaftlichen Problems und zweitens die Lehre von den Methoden und ihrer planmäßigen, praktischen oder wissenschaftlichen Anwendung. Im Sinne der Logik soll eine Methodik sicherstellen, dass bei der Ableitung neuer Aussagen ausschließlich auf bereits begründete Aussagen zurückgegriffen wird. Im vorliegenden Zusammenhang der Entwicklung des IM-Modells nach dem hier verfolgten leitungszentrierten IM-Ansatz (vgl. Kapitel Einführung und Grundlegung) und der darauf fußenden Entwicklung von IM-Konzepten wird Methodik durch Denkweisen im Sinne von Ansichten, Einstellungen, Grundhaltungen und Überzeugungen bestimmt, welche für Aufgabenträger des Informationsmanagements kennzeichnend und für ihr Handeln bestimmend sind. Theoretische Grundlagen dazu liefern Systemtheorie und Kybernetik. Im Vordergrund der Denkweisen steht Ganzheitlichkeit oder Systemdenken, was hier Folgendes heißt: Informationsfunktion und Informationsinfrastruktur werden unternehmensweit in ihrem Zusammenwirken und damit im Zusammenhang mit allen betrieblichen Aufgaben gesehen, die Objekte von Geschäftsprozessen sind. Für die Erklärung des Gesamtsystems reicht die Erklärung seiner Teilsysteme (wie Informationsfunktion, Informationsinfrastruktur, Geschäftsprozesse oder Komponenten dieser Teilsysteme) nicht aus, sondern ist auch die Erklärung der Beziehungen zwischen den Teilsystemen bzw. Komponenten erforderlich.

Erklärungsmodell (ERMOD)

21

Ganzheitlichkeit oder Systemdenken werden durch weitere Denkweisen präzisiert, insbesondere durch:     

Wirtschaftlichkeitsdenken (Kostendenken und Nutzendenken) heißt, dass das Managementhandeln darauf ausgerichtet ist, bei gegebenem Nutzen die Kosten zu minimieren bzw. mit gegebenen Kosten den Nutzen zu maximieren. Prozessdenken heißt, dass das Managementhandeln darauf ausgerichtet ist, Prozesse statt Funktionen zu gestalten und die Verbesserung der Geschäftsprozesse Mittelpunkt aller Gestaltungsmaßnahmen ist. Qualitätsdenken heißt, dass das Managementhandeln darauf ausgerichtet ist, die Informationsversorgung in inhaltlicher, zeitlicher und örtlicher Hinsicht kontinuierlich zu verbessern („die richtige Information zum richtigen Zeitpunkt am richtigen Ort“). Innovationsdenken heißt, dass das Managementhandeln darauf ausgerichtet ist, auf neuen Erkenntnissen beruhende Änderungen zu bewirken, die zu neuartigen Realisierungen führen. Nachhaltigkeitsdenken heißt, dass das Managementhandeln darauf ausgerichtet ist, bei der Beschaffung, Nutzung und Verwertung von IT-Betriebsmitteln Ressourcen zu schonen und Umweltschäden zu vermeiden. Dieses Denken charakterisierende Bezeichnungen sind Öko-IT oder Green IT.

Die Denkweisen zeigen die Wirkung der Methodik des Informationsmanagements auf die Erreichung seines generellen Sachziels, nämlich dem Streben nach Gleichgewicht zwischen Informationsfunktion mit ihrem Leistungspotenzial und Informationsinfrastruktur mit ihrem Erfolgspotenzial, und zwar bei Erfüllung der für dieses Streben gesetzten Formalziele. Die Denkweisen sind von grundsätzlicher, langfristig geltender und wirkender Art, bedürfen aber der Fortschreibung und Anpassung sowie der Ergänzung und Vertiefung (z. B. heißt Systemdenken heute auch, Komplexität zu beherrschen bzw. wenn möglich zu vermeiden). Es entwickeln sich auch neue Denkweisen wie das Nachhaltigkeitsdenken, das erst im letzten Jahrzehnt durch gesellschaftliche Entwicklungen (Umweltbewusstsein) für die IT relevant geworden ist.

Ziele des Informationsmanagements Ziele sind angestrebte Endpunkte menschlicher Handlungsprozesse. Ziele des Informationsmanagements werden in jedem Unternehmen in Abhängigkeit vom Stellenwert des Informationsmanagements unter Beachtung der Aussagen des Unternehmensleitbildes bzw. des daraus abgeleiteten IT-Leitbildes definiert. Diese Ziele sind nicht identisch mit den IT-Zielen (vgl. Lerneinheit SZIEL). In beiden Zielsystemen kann es aber ähnliche oder auch gleiche Zielinhalte geben (z. B. Wirtschaftlichkeit), und in beiden Zielsystemen gibt es Sachziele und Formalziele. Sachziele beschreiben den Zweck eines Handlungsfeldes, hier den Zweck der Gestaltung von Informationsfunktion und Informationsinfrastruktur. Formalziele beschreiben, mit welcher Qualität oder Güte die Sachziele verfolgt bzw. erreicht werden sollen, wobei formale Prozessziele von formalen Ergebnis- oder Produktzielen unterschieden werden (vgl. Heinrich/Heinzl/Riedl, 240 ff.).

22

Grundlagen des Informationsmanagements

Sachziele Primäres Sachziel des Informationsmanagements ist es, eine der Informationsfunktion adäquate, ihren spezifischen Eigenschaften entsprechende Informationsinfrastruktur zu schaffen respektive die Informationsfunktion in Abhängigkeit von bestehenden oder zu schaffenden Eigenschaften der Informationsinfrastruktur so zu gestalten, dass Leistungspotenzial und Erfolgspotenzial unter ökonomischen Zielen auf möglichst hohem Niveau im Gleichgewicht sind und vorhandenes oder zu schaffendes Leistungspotenzial in Unternehmenserfolg umgesetzt wird. In einem hierarchischen Zielsystem ist dieses Ziel oberstes Knotenziel. Informationsmanagement zielt also nicht nur auf die Schaffung, Aufrechterhaltung und Weiterentwicklung von Erfolgspotenzial ab (IT als Unterstützer der Aufgabenerfüllung), sondern ist auch auf die Identifikation und Schaffung von Leistungspotenzial ausgerichtet (IT als Enabler von Prozessen und Produkten). In Fachliteratur und Praxis wird dieses Streben nach Gleichgewicht und seine Beziehung zum Unternehmenserfolg als „IT and business alignment“ (von engl. adjusting a line), kurz mit Business-IT-Alignment bezeichnet. Nicht ausgeschöpftes Leistungspotenzial ist ebenso zu vermeiden wie überflüssiges Erfolgspotenzial; beides wirkt sich negativ auf den Unternehmenserfolg aus. Kurzfristig gesehen meint Business-IT-Alignment die ständige Anpassung der Informationsinfrastruktur an sich ändernde Geschäftsanforderungen, langfristig gesehen deren konsequente Ausrichtung an grundlegenden, den Geschäftserfolg bestimmenden Instrumenten (z. B. IT-Governance, Entwicklung von Fähigkeitsprofilen der IT-Mitarbeiter, Beschaffungsstrategien für IT-Mittel). Kurz gesagt meint Business-IT-Alignment den an den strategischen Unternehmenszielen ausgerichteten IT-Einsatz, kann aber auch als Anpassung der betrieblichen Aufgaben an das Innovationspotenzial der IT interpretiert werden. Eine Präzisierung der Sachziele erfolgt bei der Entwicklung des IM-Konzepts oder wird als Voraussetzung dafür festgelegt (z. B. im IT-Leitbild). Beispiele für Sachziele dieser zweiten Ebene der Zielhierarchie sind Innovation, Optimierung, Rekonstruktion, Sanierung, Serviceorientierung, Standardisierung und Virtualisierung sowie – neben Business-ITAlignment – weitere der von Luftman/McLean als „concerns“ bezeichneten Objekte (z. B. IT strategic planning, creating an information architecture, complexity reduction). Das Verfolgen der Sachziele ist ein permanenter Prozess, da Leistungspotenzial und Erfolgspotenzial dynamische Größen sind, die sich ständig verändern. Jede Änderung des Geschäftsmodells führt zu einer meist gravierenden Veränderung der Informationsfunktion und damit des Leistungspotenzials, und jede Änderung des Technologieangebots schafft neuen Handlungsspielraum für Erfolgspotenzial. Letzteres kann auch Auslöser für Änderungen des Geschäftsmodells sein. Cloud Computing ist dafür ein aktuelles Beispiel. Es ermöglicht jedem Unternehmen, sein Geschäftsmodell im Internet mit allen Funktionen abzubilden, ohne sich um technische Details kümmern zu müssen. Je mehr das Rationalisierungspotenzial durch Prozessunterstützung ausgeschöpft ist, desto stärker orientiert sich Informationsmanagement am Innovationspotenzial (z. B. mit dem Zweck der Umsatzgenerierung durch neue Produkte und Dienstleistungen). Dies ist eine weitere, für das IM-Modell typische Hypothese.

Erklärungsmodell (ERMOD)

23

Formalziele Primäres Formalziel des Informationsmanagements ist Streben nach Wirtschaftlichkeit. In einem Zielsystem formaler Ziele ist Wirtschaftlichkeit oberstes Ziel. Das Verfolgen der Sachziele soll so erfolgen, dass bei gegebenen Kosten der realisierte Nutzen maximal ist bzw. dass bei einem gegebenen Nutzen die Kosten minimal sind. Wirtschaftlichkeit kann kurz- bis mittelfristig durch Wirksamkeit ersetzt, langfristig aber nur ergänzt werden. Wirksamkeit ist die Eigenschaft eines Objekts, unabhängig von den erforderlichen Kosten und dem realisierbaren Nutzen Funktionen und Leistungen zu bieten. Ersteres ist insbesondere dann der Fall, wenn für die Beurteilung von IT-Investitionen zwar ausreichend Informationen über die entstehenden Kosten, nicht aber über den zu erwartenden Nutzen zur Verfügung stehen. Dies ist meist dann der Fall, wenn mit neuen Technologien innovative Veränderungen ermöglicht und den Aufgabenträgern Nutzungsangebote gemacht werden (vgl. Lerneinheit TECHM). In jedem Falle gilt: ohne Wirksamkeit keine Wirtschaftlichkeit; ein nicht wirksames Objekt kann ex definitionem keinen Nutzen generieren. Die Bedeutung der Wirtschaftlichkeit für die Schaffung und Aufrechterhaltung des Erfolgspotenzials erfordert es, das Wirtschaftlichkeitsdenken systematisch zu entwickeln und zur Wirkung zu bringen.

Managementebenen

IMTeilgebiet

Managementaufgaben

Methoden & Techniken

Abb. ERMOD-1: Dimensionen des IM-Modells

Aus den Erläuterungen zu Informationsfunktion und Informationsinfrastruktur, den Denkweisen oder der Methodik des Informationsmanagements sowie der Sach- und Formalziele wird das in drei Dimensionen gegliederte IM-Modell konstruiert (vgl. Abbildung ERMOD-1). Die Abbildung zeigt auch, dass es Aufgaben und Methoden & Techniken gibt, die für alle Managementebenen relevant sind. Als Grundlagen des Informationsmanagements bezeichnet, sind sie Gegenstand eines jeden IM-Konzepts, bei der auf dem IM-Modell als Referenzmodell basierenden Konzeptentwicklung stehen sie nicht zur Disposition. Mit der Abbildung wird auch die Bildung von Teilgebieten des Informationsmanagements (z. B. Geschäftsprozess-, Wissens- oder Sicherheitsmanagement) oder die von Forschungs- und Lehrgegenständen (z. B. strategische IT-Planung) veranschaulicht. Dafür können auch mehrere der Würfel, horizontal und/oder vertikal zusammengefasst, relevant sein.

24

Grundlagen des Informationsmanagements

Managementaufgaben IM-Aufgaben sind die aus dem Leistungsprogramm des Unternehmens abgeleiteten Teilleistungen seiner Struktureinheiten bzw. der in diesen tätigen Aufgabenträger bezüglich Information und Kommunikation im Sinne von Aufforderungen, an bestimmten materiellen oder immateriellen Objekten (Aktionsobjekte) bestimmte körperliche oder geistige Verrichtungen (Aktionsarten) durchzuführen, um definierte Ziele zu erreichen. Die Systematik des Aufgabensystems orientiert sich in erster Linie an den drei Managementebenen strategisch, administrativ oder taktisch und operativ (mehr dazu in Abschnitt Managementebenen). Als sekundäre Merkmale der Aufgabengliederung können Unternehmensbereiche wie Geschäftsfelder oder Typen von Geschäftsprozessen sein (vgl. Lerneinheit GPMAN). Der Konstruktionsprozess des IM-Modells ist bezüglich des Aufgabensystems durch den Top-down-Ansatz gekennzeichnet, der vom obersten Ziel der strategischen Ebene – in der Regel ist das Wirtschaftlichkeit – bis zu einzelnen operativen Tätigkeiten reicht. Diese Vorgehensweise entspricht mehreren von Ulich definierten Prinzipien zum Gestalten der Arbeitsorganisation. Entscheidungen zu strategischen Aufgaben determinieren einen Handlungsspielraum, in dem administrative Aufgaben erfüllt werden. Entscheidungen auf administrativer Ebene determinieren den Handlungsspielraum, in dem operative Aufgaben erfüllt werden. Darüber hinaus bewirken die drei Managementebenen eine Ordnung und Systematisierung aller Aufgaben so, dass die Aufgabenebenen – bottom-up betrachtet – innerhalb des Handlungsspielraums entkoppelt sind. Das heißt Folgendes: Aufgabenträger auf operativer Ebene agieren bei der Aufgabenerfüllung unabhängig von Aufgabenträgern der administrativen und der strategischen Ebene, Aufgabenträger auf administrativer Ebene agieren unabhängig von Aufgabenträgern der strategischen Ebene, immer vorausgesetzt, sie bewegen sich innerhalb des Handlungsspielraums.

Managementebenen Der Zuordnung der Aufgaben zu den drei Ebenen liegt folgende Annahme zu Grunde: Betrifft die Aufgabe wesentliche Eigenschaften der Informationsfunktion (z. B. Geschäftsmodell, Prozessorientierung) oder der Informationsinfrastruktur (z. B. Outsourcing, Integration, Verteilung), insbesondere Eigenschaften mit Zielcharakter (z. B. Sicherheit, Qualität), wird sie der strategischen Ebene zugeordnet. Wesentlich sind Eigenschaften dann, wenn das die Aufgabe betreffende Managementhandeln bzw. Nichthandeln einen nachhaltigen positiven oder negativen Einfluss auf den IT-Erfolg und damit auf den Unternehmenserfolg hat. Betrifft die Aufgabe – unabhängig von Eigenschaften und Zielen – einzelne Komponenten der Informationsfunktion (z. B. Geschäftsprozesse, Produkte) oder der Informationsinfrastruktur (z. B. Datensystem, Anwendungssystem), wird sie der administrativen Ebene zugeordnet. Das sie betreffende Managementhandeln bzw. Nichthandeln hat – verglichen mit strategischen IM-Aufgaben – einen deutlich geringeren positiven oder negativen Einfluss auf den IT-Erfolg und damit auf den Unternehmenserfolg. Der operativen Ebene wird eine Aufgabe dann zugeordnet, wenn sie den Betrieb oder die Nutzung der mit Zielen gestalteten und mit entsprechenden Eigenschaften ausgestatteten Komponenten der Informationsfunktion (z. B. Datenerfassung, Wissensgenerierung) oder der Infrastruktur betrifft (z. B. Benutzerservice,

Erklärungsmodell (ERMOD)

25

Problemmanagement); der Einfluss des sie betreffenden Managementhandelns bzw. Nichthandelns ist im Einzelfall vergleichsweise gering. Diese Beschreibung zeigt, welche Überlegungen beim Entwickeln des IM-Konzepts relevant sind und dass die spezifische Unternehmenssituation und das Technologieangebot bezüglich des potenziellen Wertbeitrags der IT bei der Zuordnung der Aufgaben auf Ebenen zu berücksichtigen ist. Eine grundsätzliche und eindeutige Abgrenzung zwischen den Ebenen und damit eine langfristig gültige Aufgabenzuordnung gibt es nicht. Diese orientiert sich vielmehr am Wertbeitrag der IT, der sich erfahrungsgemäß ändert (z. B. bei wesentlicher Änderung des Geschäftsmodells oder bei Veränderung der Innovationsfähigkeit). Das DreiEbenen-Modell unterstützt auch die Zuordnung von Aufgaben auf Institutionen. Hier gilt grundsätzlich, dass strategische Aufgaben dem Top Management (z. B. CIO, Lenkungsausschuss), administrative Aufgaben dem Middle Management (hier dem IT-Management, z. B. Leitung IT-Abteilung, Leitung IT-Projekte) und operative Aufgaben dem Lower Management (z. B. Operator, Helpdesk-Manager) zugeordnet sind.

Strategische Managementebene Die Begründung für die explizite Formulierung strategischer Aufgaben ist die Möglichkeit oder sogar die Notwendigkeit, Information und Kommunikation als strategischen Erfolgsfaktor zur Beeinflussung kritischer Wettbewerbsfaktoren einzusetzen. Daraus folgt die bewusste, das Unternehmen als Ganzes umfassende Planung, Überwachung und Steuerung der Informationsfunktion und der Informationsinfrastruktur. Im Folgenden wird „Informationsfunktion“ aus zwei Gründen nicht immer explizit genannt. Erstens, weil mit „Informationsinfrastruktur“ auch alle Aufgaben gemeint sind, die für die Erklärung und Gestaltung der zugrunde liegenden Informationsfunktion relevant sind, und zweitens auch deshalb, weil es bezüglich der IM-Aufgaben, welche explizit und primär die Informationsfunktion betreffen, kaum Erkenntnisse gibt, die für ein Erklärungsmodell verwendet werden könnten. Folgende Aufgabenkomplexe des strategischen Informationsmanagements werden unterschieden:  

Strategische IT-Planung von Informationsfunktion und Informationsinfrastruktur mit den Teilaufgaben Situationsanalyse, Zielplanung, Strategieentwicklung und Maßnahmenplanung. Informationsbeschaffung für die Planung, Überwachung und Steuerung aller Strukturen und Prozesse, die zur wirksamen und wirtschaftlichen Schaffung, Aufrechterhaltung und Nutzung von Informationsfunktion und Informationsinfrastruktur erforderlich sind wie Strukturmanagement, Qualitätsmanagement, Technologiemanagement, Sicherheitsmanagement, Katastrophenmanagement, Controlling, Revision und Outsourcing.

Administrative Managementebene Die strategische IT-Planung führt im Ergebnis zum strategischen IT-Plan, der inhaltlich durch Projekte auf der administrativen Managementebene in Komponenten umgesetzt wird (insbesondere in Informationssysteme). Die Entwicklung und Einführung von Informationssystemen umfasst Aufgaben (z. B. Softwareentwicklung), die wesentlicher Bestandteil eines IM-Modells sind, in ein IM-Konzept eingehen und institutionalisiert werden. Darüber hinaus

26

Grundlagen des Informationsmanagements

sind Aufgaben des administrativen Informationsmanagements Bestandteil des IM-Modells, welche die Informationsfunktion und Informationsinfrastruktur insgesamt oder einzelne ihrer Komponenten zum Gegenstand haben, sich also nicht auf eine projektbezogene Betrachtung beschränken. Objekte derartiger ganzheitlicher administrativer Aufgaben sind Personal, Datensystem, Geschäftsprozesse, Wissensgenerierung und -verteilung sowie Verhandeln und Verwalten von Verträgen. Administratives Informationsmanagement führt im Ergebnis zu einer Informationsinfrastruktur, die für die Benutzer durch die Verfügbarkeit produktiv verwendbarer Komponenten (insbesondere produktiver Informationssysteme) gekennzeichnet ist, die also Systemnutzung und damit die Durchführung der operativen IM-Aufgaben ermöglicht.

Operative Managementebene Operatives Informationsmanagement befasst sich damit, wie Information für und durch die Benutzer beschafft, kommuniziert und genutzt wird. Je mehr eine Informationsinfrastruktur dezentralisiert wird, desto mehr verlagern sich die operativen Aufgaben von Struktureinheiten des IT-Bereichs (z. B. der IT-Abteilung) in die Fachabteilungen und damit zum Linienmanagement und letztlich zu den Benutzern (Informationsmanagement am Arbeitsplatz, PIM – Persönliches Informationsmanagement, vgl. Kapitel Einführung und Grundlegung). Operative IM-Aufgaben werden zunehmend automatisiert (z. B. die Arbeitsvorbereitung im Rechenzentrum, vgl. Lerneinheit INMAN). Die Aufgaben sind trotzdem Teil des IMModells und damit jedes auf dessen Grundlage entwickelten IM-Konzepts. Seit der 9. Auflage dieses Lehr- und Handbuch werden sie nicht mehr dargestellt (zur weiteren Begründung vgl. Kapitel Einführung und Grundlegung).

Methoden & Techniken In der Enzyklopädie der Wissenschaftstheorie findet sich zum Methodenbegriff folgende Erklärung: Methode (von griech. methodos aus meta [nach ... hin] und odos [der Weg]), das (einem Gegenstand) Nachgehen, der Weg zu etwas hin (von lat. methodus), ein nach Mittel und Zweck planmäßiges (methodisches) Verfahren, das zu technischer Fertigkeit bei der Lösung theoretischer und praktischer Probleme führt (technische Methode, Arbeitsmethode, wissenschaftliche Methode oder Forschungsmethode). Der Brockhaus/Wahrig äußert sich pragmatischer, wenn festgestellt wird, dass Methode ein auf einem System von Regeln aufbauendes Verfahren ist, das zur Erlangung von Erkenntnissen oder praktischen Ergebnissen dienen soll, ein planmäßiges, folgerichtiges Vorgehen oder Handeln. Für manche dieser Vorgehensweisen wird in Wissenschaft und Praxis synonym mit oder alternativ zu Methode „Technik“ (engl. technique) verwendet (z. B. Erhebungsmethode oder Erhebungstechnik, aber Szenariotechnik und nicht Szenariomethode). Häufig wird statt Methode oder Technik die Bezeichnung „Verfahren“ verwendet. Wenn es im Folgenden „Methoden“ heißt, ist dies immer in diesem umfassenden Sinne zu verstehen. Durch den Einsatz von Methoden soll die Aufgabenerfüllung wirkungsvoll und wirtschaftlich unterstützt werden. Das Methodenangebot für die Unterstützung administrativer Aufgaben ist umfangreich, was insbesondere für die Systementwicklung gilt (z. B. Methoden des

Erklärungsmodell (ERMOD)

27

Projektmanagements und Softwareentwicklungsmethoden). Solche Methoden werden in diesem Lehr- und Handbuch nicht behandelt, weil es einschlägige Fachliteratur dazu gibt und weil Projektmanagement und Software Engineering in der Regel nicht als Teilgebiete des Informationsmanagements eingeordnet werden. Aus dem Top-down-Ansatz beim Gestalten des Aufgabensystems folgt, dass auch bei den Methoden die strategische Ebene das charakteristische Merkmal des IM-Modells ist. Wenn die besondere Sichtweise des Informationsmanagements in der Betonung der strategischen Ebene besteht, kann sich ein IM-Modell nicht auf die Aufgaben beschränken, sondern muss auch Methoden zur Unterstützung der Aufgabenerfüllung anbieten. Eine Systematik für Methoden kann nach verschiedenen Merkmalen gebildet werden. Für die Wirtschaftsinformatik typisch ist es, nach der Art der Verrichtung, die an einem Objekt ausgeführt und durch Methodenanwendung unterstützt wird, zu systematisieren. Verrichtungsarten sind das Erheben oder Erfassen, das Darstellen, Beschreiben oder Dokumentieren, das Analysieren oder Diagnostizieren, das Modellieren, Entwerfen und Entwickeln, das Implementieren, das Testen, das Installieren, das Einführen und das Integrieren, das Sanieren und das Migrieren usw. Alle Verrichtungsarten erfordern verrichtungsspezifische Methoden, so dass es Erhebungs- oder Erfassungsmethoden, Beschreibungs- oder Dokumentationsmethoden, Analyse- oder Diagnosemethoden usw. gibt. Meist gibt diese Bezeichnung den Wirkungsschwerpunkt der Methoden an. Beispielsweise meint Analysemethode in erster Linie eine Methode zum Untersuchen eines Ganzen durch Zerlegen in seine Teile und das genaue Untersuchen der Teile sowie das kritische Beurteilen des durch Untersuchen Festgestellten, also primär das Analysieren. Andere Funktionen wie das Darstellen mit methodenspezifischen grafischen Hilfsmitteln sind aber zum Erreichen des Analysezwecks erforderlich (z. B. Portfolios und Profildiagramme bei der Erfolgsfaktorenanalyse). Methoden des Informationsmanagements unterstützen die Durchführung einzelner strategischer, administrativer oder operativer Aufgaben, mehrerer Aufgaben auf einer Managementebene oder mehrerer Aufgaben auf verschiedenen Ebenen. Manche Methoden machen die Aufgabendurchführung überhaupt erst möglich, jedenfalls in angemessener Zeit und mit vertretbarem Aufwand (z. B. die Erfolgsfaktorenanalyse zur IT-Diagnose, vgl. Lerneinheit ERFAN). Eine eindeutige Zuordnung von Aufgaben zu Methoden bzw. Methoden zu Aufgaben ist nicht möglich, doch lassen sich Gruppen von Methoden bilden, die vorwiegend zur Unterstützung entweder strategischer oder administrativer oder operativer Aufgaben geeignet sind. Die Methoden des Informationsmanagements werden daher – wie die IM-Aufgaben – nach dem Drei-Ebenen-Modell systematisiert. Manche Methoden ergänzen sich, beispielsweise Kennzahlensysteme und Methoden der Kosten- und Leistungsrechnung für die Querschnittsaufgabe Controlling auf allen drei Managementebenen. Manche Methoden sind (auch) Teil anderer Methoden bzw. werden so verwendet, beispielsweise ergänzen sich Methoden der Wirtschaftlichkeitsanalyse und Methoden der Kosten- und Leistungsrechnung bei der Lösung von Evaluierungsaufgaben. Die Wirtschaftlichkeitsanalyse liefert dem Technologiemanagement für die Ex-ante-Evaluierung das erforderliche Datenmaterial, die Kosten- und Leistungsrechnung bewirkt dies für die Expost-Evaluierung.

28

Grundlagen des Informationsmanagements

Die komplexen und komplizierten Zusammenhänge zwischen den Methoden können ohne Methodenkenntnisse nicht erklärt werden. Nach dem Durcharbeiten der entsprechenden Lerneinheiten wird deutlich, welche Ergebnisse sie liefern und welche Methoden auf welchen Ergebnissen anderer Methoden aufbauen. Viele Zusammenhänge sind allerdings noch nicht untersucht und ausreichend geklärt worden, so dass ein „Methoden- und Werkzeugkasten des Informationsmanagements“ im Sinne des Information Engineering nicht verfügbar ist. Die Beurteilung der Methoden, ihre Auswahl und in der Regel ihre Anpassung bleiben dem Anwender in seiner Rolle als Entwickler eines IM-Konzepts überlassen. Regeln dazu sollte die IT-Strategie enthalten (vgl. Lerneinheit STRAT). Information Engineering muss für die praktische Anwendung auf der Grundlage eines IM-Modells zum IM-Konzept konfiguriert werden; „Rezepte“ gibt es nicht. Die Bezeichnung Information Engineering (IE) wurde von Martin, nach anderer Ansicht erstmals von Finkelstein eingeführt, und als Entwicklung einer Methodik des Informationsmanagements publiziert, wobei Finkelstein darauf hinweist, dass (VIII) „…the initial concepts of Information Engineering were first developed in 1972, and were refined over the period 1976-1981.“ Beide Autoren verstehen unter IE die Anwendung formaler Methoden für die Planung (planning), die Analyse (analysis), den Entwurf (design) und die Realisierung (construction) von Informationssystemen auf unternehmensweiter Basis oder in wesentlichen Unternehmensbereichen. Die Methoden bauen aufeinander auf und sind in gewisser Weise voneinander abhängig. Martin (I,1) formuliert das als „… application of an interlocking set of formal techniques for the planning, analysis, design, and construction of information systems, applied on an enterprise-wide basis or across a major sector of an enterprise.“ Finkelstein betont den personalen Aspekt von IE, wenn er feststellt (11): „The availability of managers and users with an expert knowledge of their business ... is an essential requirement.“ Weiter fordert er Partnerschaft zwischen Managern und Benutzern einerseits sowie zwischen professionellen Entwicklern und Benutzern andererseits.

Entwickeln des IM-Konzepts Da jedes Unternehmen eine spezifische Informationsfunktion hat, muss ein unternehmensspezifisches IM-Konzept, das sich am IM-Modell und ergänzend dazu an anderen Referenzmodellen orientiert (vgl. den nächsten Abschnitt), entwickelt und implementiert werden, und die Implementierungsergebnisse müssen in die bestehende Struktur- und Ablauforganisation eingefügt werden. Das Entwickeln des IM-Konzepts ist ein Prozess, der mit seinen Voraussetzungen und Bedingungen nicht umfassend beschrieben werden kann; das ist Gegenstand einer Projektplanung mit dem Projektgegenstand IM-Konzept. Es ist auch nicht möglich, das Ergebnis dieses Prozesses allgemeingültig zu formulieren und darzustellen; die situativen Bedingungen sind in jedem Unternehmen zu komplex und zu unterschiedlich. Beispielsweise muss Sicherheitsmanagement in Unternehmen A (z. B. einer Bank) der strategischen, in Unternehmen B (z. B. einem Hotelbetrieb) kann es der administrativen und in Unternehmen C (z. B. einer Sand- und Kiesgrube) auch der operativen Managementebene zugeordnet werden.

Erklärungsmodell (ERMOD)

29

Aufgaben der Entwicklung des IM-Konzepts sind das Gestalten des Aufgabensystems, des Methodensystems und der Struktur- und Ablauforganisation des IT-Bereichs, das heißt:    

Identifizieren der relevanten IM-Aufgaben und Zuordnen zu Aufgabenebenen (Gestalten des Aufgabensystems), Identifizieren der zur Unterstützung der Aufgabenerfüllung relevanten Methoden & Techniken (Gestalten des Methodensystems), Zuordnen von Aufgaben auf Aufgabenträger (Gestalten der Strukturorganisation) und zeitlich-sachlogisches Strukturieren der zur Aufgabenerfüllung erforderlichen Arbeitsprozesse (Gestalten der Ablauforganisation).

Rahmenbedingungen für das Entwickeln des IM-Konzepts sollten im IT-Leitbild zu finden sein (vgl. Lerneinheit SZIEL). Wenn noch nicht vorhanden, sollte das IT-Leitbild parallel zum Entwickeln des IM-Konzepts erstellt werden, was aber nur dann möglich ist, wenn ein Unternehmensleitbild bereits existiert.

Weitere Referenzmodelle Referenzmodelle sind Entwurfsmuster, die als idealtypisch für die Klasse der zu modellierenden Phänomene angesehen werden. Mit anderen Worten handelt es sich um generische Rahmenwerke (Frameworks), die an spezifische Situationen angepasst werden. Durch Verwendung von Referenzmodellen kann der Aufwand für die Modellentwicklung, ihre Implementierung und Einfügung in die bestehende Struktur- und Ablauforganisation bzw. deren Anpassung verringert werden. Die Bezeichnung Referenzmodell leitet sich aus dem Wort Referenzieren ab (eingedeutscht von engl. referencing = Verweisen auf Etwas). Beispiele für Referenzmodelle, an denen sich – in Ergänzung zu dem hier hergeleiteten und beschriebenen IM-Modell – das Entwickeln von IM-Konzepten orientieren kann, sind ITIL und CobiT. ITIL = Information Technology Infrastructure Library, ein seit 1989 eingetragenes Warenzeichen des OGC = Office of Government Commerce, war zunächst nur eine Sammlung von best practices und ist heute ein De-facto-Standard zur Planung, Erbringung und Unterstützung von IT-Dienstleistungen (vgl. Lerneinheit SEMAN). CobiT ist ein 1996 von der ISACA = Information Systems Audit and Control Association (USA) entwickeltes Framework für die Gestaltung und Beurteilung der IT-Governance (vgl. Lerneinheit GOVER). Beide Modelle umfassen Maßnahmen, die sicherstellen sollen, dass die IT die Erreichung der Unternehmensziele unterstützt, Ressourcen verantwortungsvoll eingesetzt und die Risiken angemessen überwacht werden. Die Zweckmäßigkeit der Entwicklung von Referenzmodellen wird vor allem mit der These begründet, dass ihre Verwendung den Entwicklungsaufwand unternehmensspezifischer Modelle bezüglich Zeit und Kosten deutlich reduziere. Auf welche empirische Basis sich diese These stützt und wie sie begründet wird, bleibt offen. Thomas stellt dazu fest (7): „Die Begründung, warum die in der Literatur vorgeschlagenen Modelle das Referenzattribut ‚verdienen‘, wird häufig vernachlässigt.“ In der Literatur, so wird weiter festgestellt, seien seit Ende der 1980er Jahre, als sich „Referenzmodell“ als terminus technicus etablierte, viele „Referenzmodelldeklarationen“ zu finden.

30

Grundlagen des Informationsmanagements

Forschungsbefunde Baumöl beschreibt ein als Changed Method Engineering (CME) bezeichnetes Vorgehensmodell, das einen Prozess zur Methodenkonstruktion unterstützt, mit dem das Veränderungsprojekt „Vernetzung Business und IT“ gesteuert wird. Mit dem Projekt wird die Grundlage für den Prozess geschaffen, mit dem Business-IT-Alignment im Unternehmen fortlaufend zu betreiben ist. Ergebnis des Konstruktionsprozesses ist eine individuelle Methode, die eine situativ angepasste Kombination von standardisierten Methodenfragmenten in einer definierten Sequenz bereitstellt. Die Modellentwicklung erfolgte auf Basis der Ergebnisse einer empirischen Studie zu Methoden, die in Veränderungsprojekten zum Einsatz kamen. Luftman/McLean haben die Daten einer empirischen Untersuchung über Management Concerns (Delphistudie mit 301 Teilnehmern, Untersuchungszeitraum 2003) u. a. „by job title“ analysiert und festgestellt (92 f.): 97 Teilnehmer bezeichneten sich als CIO, 173 als „other IT Executives“ (die übrigen gaben die Bezeichnung ihrer Stelle nicht an). Die deutlichste Abweichung im Ranking der Management Concerns war, dass CIOs „business process reengineering“ an 5. Stelle und dass andere IT Executives dies an 13. Stelle reihten. Nur „IT and business alignment“ wurde von beiden Gruppen gleich gereiht, nämlich an erster Stelle.

Aus der Praxis „Das Bewusstsein für Umweltfragen beim IT-Betrieb ist hoch“ berichtet Forrester-Analyst Mines nach einer Befragung von 130 IT Professionals. 94 % der Befragten halten Umweltaspekte für wichtig oder sehr wichtig. Dabei geht es den Unternehmen aber nicht primär und uneigennützig um den Umweltschutz, sondern darum, die Energieeffizienz zu steigern und weitere operative Kosten zu drücken. (Zitiert nach Computer Zeitung vom 14.1.2008, 4.) Kontrollfragen 1. Wodurch unterscheidet sich ein Erklärungsmodell von anderen Modellarten? 2. Welchem Zweck dient das IM-Modell und worin besteht der Unterschied zum IM-Konzept? 3. Welche Denkweisen und Ziele sind für das Informationsmanagement typisch? 4. Welche Phänomene werden durch die drei Dimensionen des IM-Modells abgebildet? 5. Wie wirkt sich der Referenzcharakter des IM-Modells beim Entwickeln eines IM-Konzepts aus? Quellen Baumöl, U.: Methodenkonstruktion für das Business/IT-Alignment. In: WIRTSCHAFTSINFORMATIK 5/2006, 314–322 Carr, N. G.: The Big Switch – Rewiring the World, from Edison to Google. Hüthig, Heidelberg 2009 Finkelstein, C.: Information Engineering. Strategic Systems Development. Reading/MA 1992 Heinrich, L. J. / Heinzl, A. / Riedl, R.: Wirtschaftsinformatik – Einführung und Grundlegung. 4. A., Berlin/ Heidelberg 2011 Luftman, J. / McLean, E. R.: Key Issues for IT Executives. In: MIS Quarterly Executive 3/2004, 89–104 Martin, J.: Information Engineering. Book I Introduction. Englewood Cliffs/NJ 1989, Book II Planning & Analysis. Englewood Cliffs/NJ 1990, Book III Design & Construction. Englewood Cliffs/NJ 1990 Thomas, O.: Das Referenzmodellverständnis in der Wirtschaftsinformatik. In: IWi – Veröffentlichungen des Instituts für Wirtschaftsinformatik im Deutschen Forschungszentrum für Künstliche Intelligenz 187/2006, 1–35 Ulich, E.: Differentielle Arbeitsgestaltung. In: Zeitschrift für Arbeitswissenschaft 1983, 12–15 Wade, M. / Hulland, J.: The resource-based view and information systems research. In: MIS Quarterly 1/2004, 107– 142 Rohloff, M.: Ein Referenzmodell für die Prozesse der IT-Organisation. In: HMD – Theorie und Praxis der Wirtschaftsinformatik 256/2007, 27–36

Stellenbilder (STELL) Lernziele Sie wissen, was Stellenbild heißt und kennen den Unterschied zum Berufsbild. Sie kennen verschiedene, sich im Wesentlichen ergänzende Meinungen zu den Aufgaben und zur Qualifikation von Informationsmanagern. Sie erkennen den Unterschied zwischen Informationsmanagern als Innovator und IT-Managern als Dienstleister. Sie kennen weitere, für das Informationsmanagement typische Stellenbilder. Sie erkennen anhand der verwendeten Quellen, dass die vor zwei bis drei Jahrzehnten formulierten, grundsätzlichen Aussagen zum Stellenbild von Informationsmanagern im Wesentlichen auch heute noch Gültigkeit haben.

Definitionen und Abkürzungen Anforderungsprofil (requirements profile) = aus dem Aufgabenprofil einer Stelle zur Aufgabenerfüllung abgeleitete Qualifikation (Wissen, Können, Fähigkeiten, Fertigkeiten). Aufgabenprofil (task profile) = aus dem Leistungsprogramm abgeleitete Teilleistung einer Stelle bzw. eines Aufgabenträgers im Sinne von Aufforderungen, an bestimmten Objekten (Aktionsobjekte) bestimmte körperliche oder geistige Verrichtungen (Aktionsarten) durchzuführen, um definierte Ziele zu erreichen. CEO = Chief Executive Officer. CFO = Chief Financial Officer. CIO = Chief Information Officer. CISO = Corporate Information Security Officer. CKO = Chief Knowledge Officer. Führungsaufgabe (management task) = betriebliche Aufgabe, die der Entwicklung, Gestaltung und Lenkung eines Unternehmens, seiner Teileinheiten oder Teilbereiche (z. B. ITBereich) oder Struktureinheiten (z. B. IT-Abteilung) dient. Humanvermögen (human recource) = auf Erziehung, Ausbildung Erfahrung usw. beruhendes, für den Unternehmenserfolg relevantes Leistungsvermögen der Mitarbeiter (Arbeitsvermögen). Synonym: Humankapital IT-Manager (IT manager) = überwiegend informationstechnisch ausgerichtete Führungskraft, die primär administrative Führungsaufgaben wahrnimmt (z. B. RZ-Leiter). Kompetenz (competence) = Handlungsspielraum eines Aufgabenträgers, der zur ordnungsgemäßen Aufgabenerfüllung erforderlich ist. Projektorganisation (project organization) = Art und Weise, in der die Projektleitung eine Projektgruppe führt und die projektbezogenen Aufgaben in den am Projekt beteiligten Unternehmensbereichen beeinflussen kann. Rolle (role) = Menge von Erwartungen, die das Verhalten von Individuen mit bestimmten Positionen beschreiben. Stabstelle (staff position) = Struktureinheit (Abteilung oder Stelle) zur spezialisierten Aufgabenerfüllung mit einer unterstützenden Funktion für Führungs- oder Leitungsstellen. Stelle (position) = kleinste Einheit der Strukturorganisation, der bestimmte Aufgaben, Kompetenzen, Sachmittel und Aufgabenträger zugeordnet sind.

32

Grundlagen des Informationsmanagements

Ausgangssituation Mit zunehmender Bedeutung der IT für den Unternehmenserfolg haben sich Stellenbilder entwickelt, die dem Informationsmanagement deshalb zugeordnet werden, weil es sich um Stellen handelt, denen die Wahrnehmung von Führungsaufgaben des IT-Bereichs übertragen sind, kurz gesagt: IM-Aufgaben (vgl. Kapitel Einführung und Grundlegung). Die Bezeichnung Stellenbild wird verwendet, weil die Aufgabenerfüllung in Struktureinheiten erfolgt, die im Allgemeinen als Stellen bezeichnet werden (vgl. Lerneinheit STRUK). Dabei handelt es sich zwar in erster Linie um Stellen, die strukturorganisatorisch zum IT-Bereich gehören (insbesondere die IT-Abteilung), aber auch um Stellen anderer Struktureinheiten (z. B. eine Stelle der Abteilung Controlling, die für das IT-Controlling zuständig ist). Die Aufgaben können auch von Stabsstellen der Linienorganisation wahrgenommen werden (z. B. von der Einkaufsabteilung zur Unterstützung bei der Beschaffung von IT-Betriebsmitteln). Stellenbeschreibungen in Stellenanzeigen zeigen häufig Überschneidungen im Aufgabenprofil und damit meist auch im Anforderungsprofil (z. B. wird das Projektcontrolling in einem Fall als Aufgabe des Projektleiters, in einem anderen als Aufgabe des IT-Controllers genannt). IM-Aufgaben werden auch temporären Strukturen zugeordnet, die insbesondere in den verschiedenen Formen der Projektorganisation ihren Ausdruck finden (vgl. Lerneinheit STRUK). Ein für das Informationsmanagement typisches Stellenbild der Projektorganisation ist das der Projektleitung (z. B. für Projekte der Systementwicklung). Die Häufigkeit von Stellenbildern der Projektorganisation beruht darauf, dass es im IT-Bereich zahlreiche Aufgaben gibt, die aus dem üblichen betrieblichen Geschehen herausragen, so dass die Aufgabenerfüllung als Projekt organisiert ist. Projekt wird dabei als zielgerichtetes, klar definiertes, zeitlich begrenztes, durch Größe, Bedeutung, Komplexität, Neuartigkeit, Einmaligkeit, Kosten und Risiko gekennzeichnetes Vorhaben verstanden (vgl. DIN 69901). Stellenbilder haben sich auch für IM-Aufgaben entwickelt, deren Fokus die strategische Aufgabenebene ist. Die Aufgaben sind Struktureinheiten der Linienorganisation auf TopManagement-Ebene zugeordnet, also der Unternehmensleitung, bei dezentralisiert organisierten Unternehmen im Allgemeinen teilweise der Unternehmensleitung der Geschäftseinheiten und der des Gesamtunternehmens (z. B. bezüglich Strategieentwicklung, vgl. Lerneinheit STRAT). Mit dem Erkennen und Wahrnehmen der primär strategischen Führungsaufgaben entstand die Stellenbezeichnung Informationsmanager, heute häufig und treffender als Chief Information Officer (CIO) bezeichnet. Dies ist deshalb treffender, weil damit explizit zum Ausdruck gebracht wird, dass es sich um eine Stelle im Top-Management handelt; ein CIO kann ex definitionem nicht auf der administrativen Ebene (z. B. als Leiter einer IT-Abteilung) angesiedelt sein. Im Folgenden wird die Bezeichnung Informationsmanager verwendet, wenn aus Quellen zitiert wird, welche die Bezeichnung CIO noch nicht verwendet haben. Diese Bezeichnung kann auch als Oberbegriff verstanden werden, also CIO und IT-Manager umfassend. Schließlich können IM-Aufgaben von dauerhaft oder zeitlich begrenzt eingerichteten Arbeitskreisen und Ausschüssen wahrgenommen werden (z. B. Lenkungsausschuss, vgl. Lerneinheit STRUK). Hier von Stellenbildern zu sprechen, ist jedoch im Allgemeinen nicht an-

Stellenbilder (STELL)

33

gebracht, weil es sich um Aufgaben handelt, die von bestimmten Personen neben den Aufgaben einer Stelle erfüllt werden (z. B. neben der Stelle IT-Leitung). Diese Überlegungen zeigen, dass die Bezeichnung Berufsbild meist nicht zutreffend wäre. Berufsbild heißt Beschreibung der Elemente eines Berufes (Vorbildung, Ausbildung, Tätigkeiten, Aufstiegschancen, Weiterbildungsformen, Verdienstmöglichkeiten usw.), besonders eines Ausbildungsberufes (Lerninhalte, Prüfungen usw.). Typische Stellenbilder des Informationsmanagements können sich zu Berufsbildern entwickeln (z. B. IT-Architekt) bzw. haben sich dazu entwickelt (z. B. IT-Controller). Die meisten Berufsbilder im IT-Bereich betreffen operative IM-Aufgaben (z. B. Softwareentwickler), soweit es sich dabei überhaupt um IM-Aufgaben, also um Führungsaufgaben handelt.

Informationsmanager Skubsch hat bereits vor mehr als zwei Jahrzehnten die Frage „Wie sieht die zukünftige Rolle des Informationsmanagers aus?“ treffend wie folgt beantwortet: Der Informationsmanager zeichnet sich durch ein hervorragendes fachliches Wissen im methodischen und technologischen Bereich aus, gepaart mit den klassischen Managerqualitäten, die es ermöglichen, das Leistungspotenzial der Ressource Information systematisch zu erschließen. Die Rolle des Informationsmanagers als „integrierende Persönlichkeit“ wurde so beschrieben:   



Er begreift seine Aufgabe als eine interdisziplinäre Herausforderung. Er fördert die Diskussion über das Norm-/Wertesystem des Unternehmens (d. h. über die Regeln für das Zusammenleben und Zusammenwirken der Unternehmensmitarbeiter). Er unterstützt die Entwicklung der Selbstorganisation (d. h. des konzeptionellen Denkrahmens für den Umgang mit sozialen Systemen, bei dem davon ausgegangen wird, dass es nicht möglich ist, ein eindeutiges Ordnungskonzept für das Unternehmen zu entwerfen und zu verwirklichen). Er fördert die Symbiose von Mensch und Technologie und nicht die Substitution des Menschen durch die Technologie.

Zusammenfassend stellt Skubsch fest: Als Ergebnis der Tätigkeit des Informationsmanagers basiert das Unternehmen „auf einem Netz kleiner, miteinander kommunizierender Organisationseinheiten, in denen selbst bestimmende Menschen wirken“. Von weitsichtigen Führungskräften auf oberster Leitungsebene (z. B. Hofmann, damals Vorstandsvorsitzender der R+V Versicherungen AG Wiesbaden) wurde die Auffassung vertreten, dass der Informationsmanager durch seine zentrale Planungs- und Steuerungsverantwortung für die IT eine ähnliche unternehmerische Bedeutung gewinnen müsse, wie sie der Controller für finanzielle Mittel oder der Personalleiter für personelle Ressourcen im Top-Management haben. Seine Aufgabe sei es, „den Rohstoff Information“ so einzusetzen, dass die Wettbewerbsfähigkeit des Unternehmens nicht nur erhalten bleibt, sondern verbessert wird. Dabei muss er Koordinator für alle Informationsanbieter, -benutzer und -verarbeiter sowie Katalysator für den Einsatz neuer Technologien sein. Aus der gleichen Zeit stammend und weiterhin zutreffend sind die Aussagen von Mertens/ Plattfaut über die personellen Konsequenzen des Einsatzes der „Informationstechnik als strategische Waffe“ (vgl. Lerneinheit SITAN). Sie weisen auf die Unterschiedlichkeit der

34

Grundlagen des Informationsmanagements

Rolle des DV-Managers (heute IT-Manager) und der des Informationsmanagers hin, sinngemäß wie folgt: Es versteht sich von selbst, dass ein hoch spezialisierter Rechenzentrumsleiter nur schwer die Voraussetzungen für die Beurteilung der Möglichkeiten und Grenzen des Einsatzes der Informationstechnik als strategische Waffe erwerben kann. Es geht auch nicht nur darum, dem DV-Leiter, der aus der Informatik kommt, mehr Verständnis für die Belange der Fachabteilungen bzw. Benutzer zu vermitteln. Vielmehr wird es darauf ankommen, Fachleuten mit soliden Kenntnissen der Informationstechnik Wissen und Gefühl für die Notwendigkeit strategischer Unternehmensführung zu geben. Litke/Voegele beschreiben das Anforderungsprofil des Informationsmanagers so: Im Idealfall ist er Organisator, Technokrat, Ausbilder, Unternehmensstratege und Führungspersönlichkeit zugleich. Für ihn sind sowohl technischer Sachverstand als auch innerorganisatorisches Problemverständnis kardinale Voraussetzungen. Dabei beschränkt sich „technisch“ nicht auf die Datenverarbeitung, sondern umfasst alle Informations- und Kommunikationstechnologien. Der Informationsmanager muss ein „strategisches Gespür“ dafür haben, welche informationstechnologischen Entwicklungen für sein Unternehmen von Bedeutung sind bzw. sein werden. Dabei ist nicht die Frage von besonderem Interesse, ob eine Technologie zum Einsatz kommt, sondern wie diese organisatorisch eingebettet wird. Da die Kooperation und der Dialog mit Menschen sowie deren Führung einen Großteil der Arbeit des Informationsmanagers ausmachen, benötigt er neben Sachverstand und Führungsqualität eine außergewöhnliche Kommunikationsfähigkeit. Er sollte daher betriebswirtschaftliche und organisatorische Denkweisen beherrschen, um den IT-Bereich professionell führen zu können.

Stellenbild Informationsmanager Im Unterschied zum informationstechnisch ausgerichteten IT-Manager wird der Informationsmanager als Persönlichkeit mit breiter Perspektive angesehen, der auf strategischer Ebene die Führungsaufgaben der IT wahrnimmt. Als CIO ist der Informationsmanager Mitglied der obersten Führungsebene. Der IT-Manager berichtet an den CIO, wenn nicht institutionalisiert berichtet er an den CEO, häufig alternativ dazu an den CFO. Wesentliche fachliche Eigenschaften und Führungseigenschaften des CIO sind:       

Er sieht die IT als wesentlich für den Erfolg oder Misserfolg des Unternehmens an. Er geht bei seinen strategischen Überlegungen von den kritischen Wettbewerbsfaktoren aus sowie davon, welchen Beitrag die IT zu deren Beeinflussung leisten kann. Sein Blick ist vom Markt her auf die IT gerichtet; diese ist für ihn nicht Selbstzweck, sondern Mittel zum Zweck. Er sieht in der Technologie nicht nur die Möglichkeit, bestehende Arbeitsplätze überflüssig zu machen, sondern auch die Chance, neue Arbeitsplätze zu schaffen. Er hat eine klare Vorstellung von seinen eigenen kritischen Erfolgsfaktoren. Er ist primär Innovator, nicht Dienstleister. Er ersetzt nicht den IT-Manager, sondern ergänzt ihn.

Die erforderlichen Kenntnisse, Fähigkeiten und Fertigkeiten können weder durch ein Universitätsstudium, noch durch praktische Tätigkeit allein erworben werden. Sie erfordern ein

Stellenbilder (STELL)

35

einschlägiges Universitätsstudium sowie eine mehrjährige Berufserfahrung. Von der Ausbildung her ist der CIO eher Wirtschaftswissenschaftler als Techniker, wobei Wirtschaftsinformatiker und Wirtschaftsingenieure die besten Voraussetzungen mitbringen (nach Ganzer). Busch formuliert folgendes Anforderungsprofil für den Informationsmanager: 

 

Beherrschung der Informations- und Kommunikationstechnologien, der Methoden zur Gestaltung der Struktur- und Ablauforganisation, der Methoden zur Koordination von Entwicklungsvorhaben, der Methoden zur Ermittlung der Wirtschaftlichkeit von Entwicklungsvorhaben, der Methoden zur Überzeugung aller Stakeholder (insbesondere Auftraggeber, Benutzer und Kunden) und der Methoden zur Führung von Mitarbeitern. Fähigkeit, sich mit Problemen der Benutzer zu identifizieren, vorhandene Strukturen und Abläufe in Frage zu stellen, interdisziplinäres Know-how einzusetzen und auch unkonventionelle Lösungen durchzusetzen. Bereitschaft zu ausgeprägtem Sozialverhalten, Ziele mit Verhandlungsgeschick, aber auch mit Hartnäckigkeit durchzusetzen, geduldig und tolerant zu sein, sich diplomatisch zu verhalten, sich überdurchschnittlich persönlich einzusetzen und langfristig zu denken und zu handeln.

Diese Aufzählung mit teilweise konkurrierenden Anforderungen zeigt, dass das Stellenbild nur vage beschrieben ist. Neben dem Mangel an praktischen Erfahrungen fehlt es noch an der theoretischen Auseinandersetzung mit dieser Thematik; Ansätze dazu finden sich im Modell CIO von Earl. Danach interagieren zunächst vier Rollen des CIO miteinander, nämlich Vision builder, Relationship builder, Politician und Deliverer. Die Rollen werden in der sich schnell verändernden IT-Welt zu acht Rollen ergänzt: Vision builder / Change master, Relationship builder / Alliance manager, Politician / Reformer und Deliverer / Re-architect.

Informationsmanager vs. IT-Manager Die bisherigen grundsätzlichen Aussagen werden beispielhaft durch Anforderungsprofile und/oder Aufgabenprofile aus Stellenanzeigen ergänzt; die Profile sind nicht immer klar getrennt und benannt (z. B. wenn Anforderungsprofile als Voraussetzungen, Aufgabenprofile als Perspektiven bezeichnet werden). Sie zeigen, dass die Praxis der Personalbeschaffung (vgl. Lerneinheit PERSM) neben der klaren Trennung von Innovator (erst selten explizit als CIO bezeichnet) und Dienstleister (meist als IT-Leiter oder ähnlich bezeichnet) auch die Zusammenfassung beider Rollen in einer Stelle kennt. Dabei steht entweder die Rolle als Innovator oder die als Dienstleister im Vordergrund; beide Rollen mit gleicher Intensität von einer Person wahrzunehmen, muss als illusorisch angesehen werden. Ursachen für die Rolle „Innovator und Dienstleister“, in der Praxis häufig zu beobachten, sind u. a. eine geringe Unternehmensgröße (KMU) oder die geringe Bedeutung des IT-Bereichs für den Unternehmenserfolg. Kennzeichnend für die Rolle Innovator ist, dass die Stelle zur ersten Berichtsebene gehört, also eine Top-Management-Position ist, während die Rolle Dienstleister einer Stelle der zweiten Berichtsebene zugeordnet ist. Beispiel Innovator: Die Sick AG Waldkirch hat 2005 die Position eines Informationsmanagers, als „Division-Leiter IT“ bezeichnet, neu eingerichtet, wobei von folgenden Herausforderungen an den zukünftigen Stelleninhaber ausgegangen wurde (F.A.Z. vom 20.1.2008,

36

Grundlagen des Informationsmanagements

C41): Wie unterstützt die IT das Geschäft optimal? Welche Grundlagen müssen heute gelegt werden, um die Anforderungen von morgen zu erfüllen? Wie wird man dabei den Besonderheiten einer stark wachsenden dezentralen, internationalen Struktur mit einer starken Konzernzentrale gerecht? Gesucht wurde ein interdisziplinärer IT-Generalist, der die IT im Konzern gestaltet und im Dialog mit dem Linienmanagement IT-Lösungen initiiert. Themen, welche die vielfältige Gestaltungsaufgabe prägen, sind: Weiterentwicklung der IT-Strategie und deren Umsetzung, der IT-Managementprozesse, des IT-Controllings, der Organisationsentwicklung, des Aufbaus und Managements von Governance-Strukturen. Als Gesamtverantwortlicher für die IT ist der Stelleninhaber Mitglied der Geschäftsführung. Beispiel Dienstleister: Die Lebkuchen-Schmidt GmbH & Co. KG Nürnberg beschreibt die Aufgabe des gesuchten „IT-Leiters (m/w)“ wie folgt (F.A.Z. vom 27.1.2008, C50): Steuerung der Umsetzung unternehmerischer IT-Projekte von der Anforderungsanalyse bis zur Fertigstellung, Serveradministration, fachliche IT-Beratung der einzelnen Abteilungen, Einkauf/Beschaffung von Software und Hardware sowie IT-Dienstleistungen, Überprüfung und Optimierung der mit individuell entwickelter Software gesteuerten Arbeitsprozesse. Das Profil verlangt ein abgeschlossenes Informatikstudium oder vergleichbare Qualifikation. Beispiel Dienstleister und Innovator: Die Mylan dura GmbH Darmstadt beschreibt die Aufgaben des gesuchten „Leiter/in IT“ so (F.A.Z. vom 13.1.2008, C47): Fachliche und disziplinarische Leitung der IT-Abteilung und Sicherstellung eines reibungslosen IT-Betriebs, lokale Koordination, Implementierung und Weiterentwicklung globaler Strategien, Mitwirkung an internationalen IT-Projekten unter Repräsentanz des lokalen IT-Umfelds, Harmonisierung und Standardisierung unterschiedlicher nationaler IT-Landschaften, Anpassung und Weiterentwicklung der Systemarchitektur und der Netzwerkstrukturen, Erarbeitung und Einhaltung des IT-Investitionsbudgets, Verhandlungs- und Ansprechpartner/in für externe Anbieter und Dienstleister, Verantwortung für Datenintegrität, Konsistenz und die notwendigen ITSecurity-Maßnahmen. Das Profil verlangt ein abgeschlossenes Studium der Wirtschaftsinformatik, BWL mit Nebenfach Informatik oder vergleichbare, in der Praxis erworbene Qualifikation.

Weitere Stellenbilder Mit der zunehmenden Technologiedurchdringung entstehen neue Rollen und entwickeln sich entsprechende Stellenbilder, wie nachfolgend an Beispielen gezeigt wird. Zunehmende fachliche Spezialisierung des IT-Bereichs und damit der Aufgabenprofile ist für große Unternehmen sowie für Anbieter und Berater eher typisch als für Klein- und Mittelunternehmen (KMU), die u. a. durch eine flache Organisationsstruktur gekennzeichnet sind und deren Budget für IT-Personal relativ klein ist. Die Rolle des CIO – wenn sie überhaupt ausreichend besetzt ist – wird vom CEO oder CFO wahrgenommen. CEO entspricht im deutschsprachigen Raum der Bezeichnung Geschäftsführer (z. B. einer GmbH) oder Vorstandsvorsitzender (z. B. einer AG), CFO ist das für Finanzen zuständige Mitglied der Geschäftsführung bzw. des Vorstands. Dies kann als Grund für die empirische Feststellung gelten, dass die Technologiedurchdringung der KMU geringer ist als die großer Unternehmen. Da es in KMU häufig auch keine IT-Abteilung gibt, wird externes Know-how durch Anbieter und Berater intensiver genutzt als in großen Unternehmen (vgl. Lerneinheit OUTSO).

Stellenbilder (STELL)

37

Die Gesamtheit der Stellenbilder, der diesen entsprechenden Aufgabenprofile und der daraus abgeleiteten Anforderungsprofile an die Stelleninhaber ist die personelle Infrastruktur, eine der Komponenten der Informationsinfrastruktur (vgl. Lerneinheit ERMOD). Sie findet ihren Ausdruck in der Anzahl und im Wissen und Können sowie den Fähigkeiten und Fertigkeiten aller an der betrieblichen Informationsproduktion, -verteilung und -nutzung beteiligten Personen, von dem für die IT zuständigen Mitglied der Unternehmensleitung (z. B. dem CIO) über das IT-Management (z. B. IT-Leiter) und den Mitarbeitern der IT-Abteilung (z. B. Helpdesk-Personal) sowie dem Linienmanagement (z. B. Prozesseigner) bis zu den Benutzern. Linienmanagement und Benutzer agieren dabei in bestimmten Rollen (z. B. das Linienmanagement in der Rolle des Innovators durch IT-Einsatz in Kooperation mit dem ITManagement, vgl. Lerneinheit TECHM). Zur personellen Infrastruktur gehören auch die Menschen, die Entwicklungsmethoden anwenden (z. B. Softwareentwickler) oder in Managementsystemen tätig sind (z. B. IT-Controller). Es besteht ein enger Zusammenhang zwischen personeller Infrastruktur und Humanvermögen bzw. Humankapital – dem 2004 mit der Begründung zum Unwort des Jahres gewählten Begriff, er degradiere Menschen zu ökonomisch interessanten Größen –, für dessen Höhe neben dem Bildungsniveau und der beruflichen Erfahrung persönliche Eigenschaften wie Motivationsbereitschaft und Flexibilität relevant sind. Unternehmen können schwer nachahmbare Wettbewerbsvorteile primär aus ihrem Humankapital generieren (verglichen mit dem Sachkapital und dem Finanzkapital); dies gilt in besonderem Maße für das Humankapital des IT-Bereichs. Die Erfahrung zeigt die Tendenz von Individuen und Unternehmen zur Unterinvestition in Humankapital und verdeutlicht die Rolle der Personalentwicklung im IT-Bereich, solche Investitionen zu fördern (vgl. Lerneinheiten STRAT und PERSM). IT-Controller sind Aufgabenträger für die Aufgabe, dem Linienmanagement und dem ITManagement die Informationen sowie die Grundsätze, Methoden und Instrumente zur Verfügung zu stellen, die für die Planung, Überwachung und Steuerung der IT erforderlich sind (vgl. Lerneinheit CONTR). In einer Stellenanzeige wird folgendes Anforderungsprofil genannt (F.A.Z vom 4.4.1998, V14): „Banking hat uns zu einem international bedeutenden Haus gemacht. Zur Verstärkung unseres Bereichs Organisation und Informatik suchen wir ab sofort Controller/innen für die Stabsstelle DV-Controlling. Die Koordination und Abwicklung der Leistungsverrechnung (Service-Center-Rechnung) und die Erstellung von Analysen und Kennzahlen bilden den Schwerpunkt Ihrer Aufgabenstellung. Dazu gehören die Abstimmung der Budget- und Informatikplanung des Konzerns sowie das Berichtswesen und die Überwachung des Personalbestands. Die Betreuung und Beratung der DV-Abteilungen bei der Planung und dem Reporting ist ein zusätzlicher wesentlicher Bestandteil Ihrer Tätigkeit. Basierend auf einem Wirtschafts-/Informatikstudium oder vergleichbarer Qualifikation bringen Sie Berufserfahrung im Rechnungswesen/Controlling von Kreditinstituten mit und verfügen über fundierte PC-Kenntnisse.“ IT-Revisor (IT-Auditor, IT- und Business Auditor, IT-Prüfer) sind Aufgabenträger für die Aufgabe, die Einhaltung anwendungsspezifischer unternehmensexterner (z. B. gesetzlicher) und unternehmensinterner (z. B. organisatorischer) Regeln der IT sowie die Qualität der informationstechnischen Realisierung und Abwicklung von Anwendungen des Finanz- und Rechnungswesens einschließlich der diesen vorgelagerten Anwendungen zu prüfen (vgl. Lerneinheit REVIS). In einer Stellenanzeige wird folgendes Anforderungsprofil für die Stelle

38

Grundlagen des Informationsmanagements

„Projektleiter/in IT-Audit“ angegeben (F.A.Z. vom 30.6.2007, C23): Abgeschlossenes Studium (z. B. Wirtschaftsinformatik), Kenntnisse in Enterprise Resource Planning, Internal Audit bzw. IT-Prozessen oder IT-Controlling, Erfahrung in der Durchführung komplexer Projekte, u. a. zur Prozessoptimierung, Identifizierung und Bewertung IT-technischer Risiken, Analyse von Verträgen auf Effizienz und Rechtmäßigkeit, Beratung der geprüften Einheiten sowie Einleitung und Überwachung geeigneter Maßnahmen zur Zielerreichung. Produktmanager sind Aufgabenträger für die Aufgabe, Fragen der Fachbereiche in Bezug auf Produktinhalte, Kostenbestandteile, Verrechnungspreise, aber auch Technologien und Weiterentwicklungen der IT-Produkte zu beantworten und auftretende Probleme zu lösen. Für jedes definierte Produkt (vgl. Lerneinheit KOLER) wird ein Produktmanager bestellt, der alleiniger Ansprechpartner für die Fachbereiche ist. Ist die Aufgabe Produktmanagement nicht dem IT-Bereich, sondern den Fachabteilungen zugeordnet, werden Produktmanager als IT-Koordinatoren, auch als IT-Referenten oder Anwendungsbetreuer bezeichnet. In einer Stellenanzeige wird folgendes Aufgabenprofil für „Referenten (m/w) IT-Strategie“ genannt (F.A.Z. vom 29.3.2008, C27): Unterstützung der Fachbereiche/Tochterunternehmen bei der IT-spezifischen Dokumentation der Geschäftsprozesse und Beratung bzgl. der Umsetzung der IT-Anforderungen; Koordination des Abgleichs von Geschäftsprozessanforderungen mit der IT-Applikationsstrategie sowie der Formulierung/Umsetzung der ITStrategie; Mitarbeit bei der IT-Planung, der Festlegung/Umsetzung zentraler IT-Projekte sowie der Erarbeitung/Einhaltung von IT-Standards; Vorbereitung und Mitgestaltung der Sitzungen der IT-Kommission als bereichsübergreifendes Gremium mit direkter Berichterstattung an die Geschäftsführung. Projektmanager (Projektleiter bzw. Projektkoordinator) sind Aufgabenträger für die Aufgabe, IT-Projekte den vorgegebenen Planungszielen entsprechend zu gestalten und abzuwickeln, wobei Kompetenz und Verantwortung im Wesentlichen durch die Projektorganisation und das Projektcontrolling bestimmt werden. In einer Stellenanzeige „Projektleiter/in“ wird folgendes Anforderungsprofil genannt (C.Z. vom 3.12.2007, 22): Abgeschlossenes Hochschulstudium, fundierte Methoden- und IT-Kenntnisse, Persönlichkeit und Kommunikationsstärke, ausgeprägte Teamfähigkeit und hohe Belastbarkeit, hohe Kundenorientierung. Rollout-Manager (von engl. rollout, wörtlich: auswalzen, ausrollen) sind Aufgabenträger für die Leitung der unternehmensweiten, systematischen Umstellung von bestehenden Technologien auf neue Technologien (z. B. Umstellung von proprietären Systemen auf ERPSysteme). In einer Stellenanzeige wird folgendes Aufgabenprofil genannt (F.A.Z. vom 2./3.8.2008, C15): Koordination der Weiterentwicklung des SAP-Templates und der ServiceAnwendung sowie Planung und Leitung des entsprechenden Rollouts in Konzern- und Beteiligungsgesellschaften weltweit. Betreuung und Beratung der beteiligten Fachbereiche und des Managements vor Ort. Wahrnehmung aller projektbegleitenden Managementaufgaben sowie Scope-, Change- und Communication-Management. Steuerung der externen Berater. Weitere Bezeichnungen für Stellenbilder des Informationsmanagements sind Infrastrukturmanager, IT-Consultant, Leiter/in Anwendungsentwicklung, Leiter/in IT-Architektur sowie – explizit im IT-Bereich – Produktionsmanager, Qualitätsmanager, Sicherheitsmanager, Telekommunikationsmanager, Vertragsmanager. Einen starken Einfluss auf die Entwicklung der Stellenbilder wird die Ausbreitung des Cloud Computing haben (vgl. Lerneinheit INMAN).

Stellenbilder (STELL)

39

Forschungsbefunde Rockart hat bereits 1982 über empirische Befunde berichtet, die zeigen, wie zur Rolle des Dienstleisters die des Innovators tritt und dass es notwendig ist, diese Rollen verschiedenen Personen zuzuordnen (Tiefeninterviews in neun Unternehmen verschiedener Branchen). Das Profil des I/S Executive wird so beschrieben: „ …an aggressive, proactive, communicationoriented executive, …who is focusing heavily on helping his organization to adapt to a changing technical environment …Increasingly, he must give away day-to-day responsibility to local I/S managers. …only through this shift will he have the time to focus on the more ´staff´ oriented tasks of I/S strategy, planning, standard-setting, and the management of research into both technology directions and the current application of the new technology…he is a disseminator and ´salesman´ of ideas and techniques rather the direct implementator. …Operating responsibility for local I/S units is increasingly being transferred to local line management.” Bassellier/Benbasat beschreiben ein Framework for Business Competence, das mit dem Fokus entwickelt wurde „…the set of knowledge and skills that forms business competence which, in turn, enables IT professionals to develop better collaboration with their business partners” zu identifizieren (676). Das Messsystem verwendet acht Dimensionen (z. B. Organizational Responsibility, IT-business Integration, Knowledge Networking) mit 47 Variablen, deren Ausprägungen auf einer 5-Punkte-Likert-Skala gemessen wurden (schriftliche Befragung in zwei Unternehmen der Versicherungswirtschaft in den USA, 326 befragte „IT professionals at all hierarchical levels“, 166 auswertbare Antworten). Befunde sind (691): „The nature of work for IT professionals is changing; interaction with people from other functional areas is now part of their work. IT professionals need to apply their technical knowledge in a way that is beneficial to the organization, and act cooperatively with their business partners. To succeed in this endeavour, IT professionals need a growing range of non-IT skills. The conclusion we draw from this study stands out clearly: the knowledge that IT professionals have in the general business domain, and in the interpersonal and management domain, does matter in the development of partnerships with their business clients.” Kelm/Heinzl identifizierten zwei Einflussfaktoren, welche die Verbreitung des CIO im Vorstand begründen (qualitative Divergenzanalyse auf Basis von je zwei Fallstudien in deutschen Unternehmen der Branchen Banken, Verkehr und Fahrzeugbau, je eines davon mit und ohne CIO im Vorstand): Starke unternehmensexterne Nutzung der IT zum Aufbau von Wettbewerbsvorteilen sowie Verwendung der IT als Mittel zur Integration und Transformation von Geschäftsprozessen. Enns/MacFarlin/Huff erklären Einflussverhaltensweisen (influence behaviors) und deren angemessene Geltendmachung durch CIOs anhand von elf Einflussfaktoren: rational persuasion (logical arguments), apprising (emphasizing expected benefits), inspirational appeal consultation, collaboration, personal appeal, ingratiation, exchange, legitimating (connected to precedent), coalition (asking others to persuade), pressure. Sie untersuchen dann anhand von vier Szenarien, in denen CIOs handeln, welche der elf am wirksamsten sind. Im Ergebnis wird festgestellt (38): „…research shows, that rational persuasion is more likely to lead to commitment in many contexts than the other 10 influence behaviours. Consequently,

40

Grundlagen des Informationsmanagements

CIOs often may need to argue a compelling and rational case for how their proposal will benefit the organization.…Depending on the nature of the initiative (strategic vs. incremental) and how the CIO is viewed by the top management team (true peer vs. subordinate), other influence behaviors may also prove effective – sometimes in combination with rational persuasion.” Riedl/Kobler/Roithmayr berichten zur personellen Verankerung der IT-Funktion im Vorstand u. a. (Inhaltsanalyse von 679 Geschäftsberichten börsennotierter Unternehmen des Geschäftsjahrs 2005 in Deutschland, Österreich und der Schweiz): In 173 Geschäftsberichten wurde die Variable mit „ja“ kodiert; die IT ist in 25 % der Unternehmen personell auf Vorstandsebene verankert. Einheitliche Titel (z. B. CIO), Ressortbezeichnungen (z. B. Ressortleiter IT / Operations) und Aufgabenbeschreibungen (z. B. Finanzen und Informatik) werden nicht verwendet. In den 173 Geschäftsberichten wurden 88 unterschiedliche Bezeichnungen gefunden; die Bezeichnung CIO wurde nur in 13 Geschäftsberichten verwendet. Die Unternehmensgröße (gemessen am Umsatz und an der Mitarbeiterzahl) und die personelle Verankerung der IT auf Vorstandsebene zeigen einen starken positiven Zusammenhang. Köbler et al. (363) ermittelten bei der Typologisierung der zukünftigen obersten IT-Entscheider in deutschen Krankenhäusern zwei dominante Entscheidertypen (schriftliche Befragung von 207 „eingeladenen Personen aus dem IT-Bereich“, Rücklaufquote 9,88 %, PreTest durch Experteninterviews): „IT-Leiter großer Krankenhäuser unterscheiden sich in ihrer Rolle als Ideengeber für die Optimierung administrativer und medizinischer Abläufe, dem Grad ihrer Mitwirkung bei der Krankenhausstrategie und Einbindung in Entscheidungen der der Krankenhausführung, zu IT-Leitern kleiner Krankenhäuser. Interessanterweise konnte kein Unterschied zwischen Krankenhäusern unterschiedlicher Träger festgestellt werden.“

Aus der Praxis In der Praxis hat sich noch keine begriffliche Unterscheidung zwischen CIO und IT-Manager durchgesetzt, vielmehr werden häufig IT-Manager als CIO bezeichnet, wie folgendes Zitat zeigt: „Immer mehr amerikanische IT-Leiter berichten direkt an ihre CFOs: Waren es vor drei Jahren noch 11 % aller IT-Chefs, so sind es inzwischen 30 %. Die Veränderung fällt vor allem in der Fertigungsindustrie ins Gewicht, wo aufgrund geringer Gewinnmargen für ITInnovationen wenig Raum bleibt. Im Gegensatz dazu berichten nur 16 % der CIOs im Finanzwesen und bei Versicherungsgesellschaften direkt an ihre Finanzchefs.“ (Quelle: http://www.cio.de/strategien/802322/; Abruf 27.1.2008.) Ein umfassenderes Bild dieser Praxis zeigt beispielsweise http://www.cio.de. Zwar nennt sich die Website „CIO ITStrategie für Manager“, wendet sich aber an die IT-Verantwortlichen in Deutschland, der Schweiz und Österreich, unabhängig davon, in welchem Umfang und auf welcher Berichtsebene IT-Verantwortung zu ihrem Stellenbild gehört. KARRIERE – Markt für Führungskräfte berichtet (ohne Angabe des Autors und Angaben über Art und Zeitraum der Erhebung): Basis der Ausbildung für ORG/DV-Manager ist zu zwei Dritteln der Abschluss eines Universitäts- oder eines Fachhochschulstudiums. Fast 50 % der ORG/DV-Manager, die studiert haben, geben als Fachrichtung eine wirtschaftlichkaufmännische Ausbildung an, 20 % haben ein Ingenieurfach studiert, 15 % haben eine na-

Stellenbilder (STELL)

41

turwissenschaftlich-mathematische Ausbildung; die Informatik-Ausbildung liegt unter 10 %. Fast zwei Drittel der Stelleninhaber wurden von außen direkt in diese Position eingestellt. Ihr Aufgabenschwerpunkt ist es, „den neuen Produktionsfaktor Information zu organisieren“. Harvard-Professor McAfee berichtet: Der CIO der Modekette Zara, „einer der brillantesten Technologieanwender, verbringt die meiste Zeit damit, neue Technologie aus der Organisation herauszuhalten“. (DER STANDARD vom 12./13.11.2005, 24). Gartner-Analyst Fulton rät IT-Managern dazu, den „business aspect“ auf Kosten der Technologieorientierung in den Vordergrund zu rücken, um ihre Chance zu wahren, in die Top-Führungspositionen CIO aufzurücken. (C.Z. vom 12.11.2007, 20) Als Ergebnis einer Erörterung der Frage „IT-Manager – Dienstleister oder Innovator?“ zwischen IT-Managern und Wissenschaftlern in einem Workshop des ipo wurden folgende Thesen zum Stellenbild des Informationsmanagers formuliert: 1. 2. 3. 4.

5.

Dienstleister und Innovator sind Rollen, die jede Organisation braucht; sie können einzelnen oder mehreren Personen, Internen (Mitarbeiter) und/oder Externen (Berater) zugeordnet sein. Für Entscheidungen über Ausmaß und Intensität der Bedeutung und Wahrnehmung der Rollen sind interne sowie externe Einflussfaktoren relevant (z. B. Innovationsfähigkeit, Technologieverfügbarkeit, Höhe des IT-Budgets). Ausmaß und Intensität der Bedeutung und Wahrnehmung der Rollen unterliegen Veränderungen im Zeitverlauf bzw. werden durch Planungsentscheidungen verändert (z. B. Budgethöhe bei jährlicher Fortschreibung der IT-Strategie). Metriken zum Messen und damit zum Planen, Überwachen und Steuern von Bedeutung bzw. Wahrnehmung der Rollen sind nicht bekannt; Messgrößen wie „Anteil am ITBudget“ sind nicht sehr valide, die Zuordnung der Budgetverwendung auf die Rollen ist schwierig. Für das Erkennen von Innovationspotenzial und das Beurteilen des Nutzens von Innovationen sind die Prozesseigner verantwortlich, nicht das IT-Management; dieses sollte beraten, nicht entscheiden.

Capgemini bezeichnet die beiden Rollen Verwalter bzw. Dienstleister und Gestalter bzw. Innovator als Bereitsteller von Technologie bzw. als Geschäftsgestalter. Welche Rolle der CIO in seinem Unternehmen stärker wahrnimmt, hänge einerseits maßgeblich vom eigenen Qualifikationsprofil, dem Erfahrungsspektrum und seinen Managementinteressen, andererseits vom Stellenwert der IT in der Wertschöpfung des Unternehmens ab. Kontrollfragen 1. Wodurch unterscheiden sich Stellenbilder von Berufsbildern und wie entwickeln sie die einen aus den anderen? 2. Wie wird die Rolle des Informationsmanagers als integrierende Persönlichkeit begründet? 3. Warum müssen Informationsmanager Koordinator und Katalysator sein? 4. Wie sind das Aufgaben- und das Anforderungsprofil eines CIO zu formulieren, um als Stellenanzeige geeignet zu sein? 5. Sind Informationsmanager Innovatoren und/oder Dienstleister und was spricht für oder gegen die Zuordnung beider Rollen auf eine Person? Quellen Bassellier, G. / Benbasat, I.: Business Competence of Information Technology Professionals: Conceptual Development and Influence on IT-Business Partnerships. In: MIS Quarterly 4/2004, 673–694

42

Grundlagen des Informationsmanagements

Busch, U.: Org.-DV-Leiter vs. Kommunikationsmanager – Die neue Führungsposition im Unternehmen. In: Krallmann, H. (Hrsg.): Informationsmanagement auf der Basis integrierter Bürosysteme. Berlin 1986, 41–58 Capgemini (Hrsg.): Der CIO – Verwalter oder Gestalter? http://www.ecin.de/strategie/rolle-cio; Abruf 19.12.2005 Earl, M. J.: Change isn’t optional for today’s CIO. In: FINANCIAL TIMES, Supplement „Mastering Information Management“, 15.2.1999, 2–3 Enns, H. G. / MacFarlin, D. B. / Huff, S. L.: How CIOs can effectively use Influence Behaviors. In: MIS Quarterly 1/2007, 29–38 Ganzer, K.: Schlüsselfaktor Informationsmanagement. In: F.A.Z., Beilage Technik, Computer, Kommunikation vom 27.10.1986, B19 Heinzl, A.: Die Rolle des CIO in der Unternehmung. In: WIRTSCHAFTSINFORMATIK 4/2001, 408–420 Hofmann, R.: Führungskraft und Schiedsrichter. In: Computerwoche vom 18.7.1986, 27 ipo: Stellenbild des Informationsmanagers. http://www.ipo.jku.at/index.php?menuid=103; Abruf 19.5.2008 KARRIERE – Markt für Führungskräfte: Aufgaben des Org.-DV-Leiters ändern sich mit der Technik. In: Beilage Handelsblatt vom 23.1.1987, K12 Kelm, P. / Heinzl, A.: Der Chief Information Officer im Vorstand von Unternehmen des deutschsprachigen Raumes. Working Papers in Information Systems Nr. 04/2003, Mannheim 2003 Köbler, F. / Fähling, J. / Krcmar, H. / Leinmeister, J. M.: IT-Governance und IT-Entscheidertypen in deutschen Krankenhäusern – Eine empirische Untersuchung unter Krankenhaus-IT-Leitern. In: WIRTSCHAFTSINFORMATIK 6/2010, 353–365 Litke, H. D. / Voegele, A. A.: Informationsmanagement als Führungsaufgabe, In: Fraunhofer-Gesellschaft (Hrsg.): Information als Produktionsfaktor. FhG-Bericht 1/1986, 12–16 Mertens, P. / Plattfaut, E.: Informationstechnik als strategische Waffe. In: Information Management 2/1986, 6–17 Riedl, R. / Kobler, M. / Roithmayr, F.: Zur personellen Verankerung der IT-Funktion im Vorstand börsennotierter Unternehmen. In: WIRTSCHAFTSINFORMATIK 2/2008, 111–128 Rockart, J. F.: The Changing Role of the Information Systems Executive. A Critical Success Factors Perspective. In: Sloan Management Review 1/1982, 3–13 Skubsch, H.: Der Informations-Manager – ein Manager wie jeder andere? In: Computerwoche vom 4.7.1986, 8 Vertiefungsliteratur Chamoni, P.: Berufsbilder, Tätigkeitsfelder und Arbeitsmarkt für Wirtschaftsinformatiker. In: Mertens, P. et al. (Hrsg.): Studienführer Wirtschaftsinformatik. 3. A., Braunschweig/Wiesbaden 2002, 19–24 Dietrich, L.: Die ersten 100 Tage des CIO – Quick Wins und Weichenstellungen. In: Dietrich, L. / Schirra, W. (Hrsg.): IT im Unternehmen. Berlin et al. 2004, 45–81 Gaus, W.: Berufe im Informationswesen. 5. A., Berlin et al. 2002 Glohr, C.: Der CIO als Kostenmanager. In: Informatik Spektrum 2/2003, 134–139 Pawloski, S. D. / Robey, D.: Bridging User Organizations: Knowledge Brokering and the Work of Information Technology Professionals. In: MIS Quarterly 4/2004, 645–672 Stannat, A. / Petri, C.: Trends in der Unternehmens-IT. In: Informatik Spektrum 3/2004, 227–237 SwissICT – Schweizerischer Verband der Informations- und Kommunikationstechnologie (Hrsg.): Berufe der ICT – Informations- und Kommunikationstechnologien. 6. A., Zürich 2004 Vdf (Hrsg.): Berufe der Wirtschaftsinformatik in der Schweiz. 5. A., Zürich 2000 Informationsmaterial Earl, M.: The role of the chief knowledge officer. In: FINANCIAL TIMES, Supplement „Mastering Information Management“, 8.3.1999, 7–8 Feraud, G.: What makes IT professionals tick? In: FINANCIAL TIMES: Supplement „Mastering Information Management“, 15.2.1999, 10

Architektur der Informationsinfrastruktur (ARCHI) Lernziele Sie können die Rolle der Architektur für das Informationsmanagement erläutern. Sie kennen verschiedene Teilarchitekturen der Informationsinfrastruktur und können Gemeinsamkeiten und Unterschiede aufzeigen. Sie kennen Metamodelle für Architekturen und können deren typische Eigenschaften beschreiben. Sie haben einen Überblick über Teilaufgaben der Entwicklung von sowie über Gestaltungsziele und Konstruktionsregeln für Architekturen.

Definitionen und Abkürzungen Anwendungsarchitektur (application architecture) = Modell der Funktionalität und des Zusammenhangs der Anwendungssysteme eines Unternehmens oder Aufgabengebiets. Architektur (architecture) = Organisation eines Systems, die sich in seinen Komponenten und deren Beziehungen zueinander sowie zum Systemumfeld manifestiert. Architekturprinzip (architecture principle) = grundlegende Aussage zur Konstruktion, Beschreibung und Evaluierung von Architekturen. ARIS = Architektur integrierter Informationssysteme; Metamodell zur Modellierung computergestützter Informationssysteme vom Fachkonzept bis zur Implementierung. Datenarchitektur (data architecture) = Modell der für das Unternehmen wesentlichen Datenbestände, insbesondere der Datenbanken und Data-Warehouse-Systeme, und ihrer strukturellen Beziehungen. Geschäftsarchitektur (business architecture) = Modell der Organisation eines Unternehmens, der wesentlichen Komponenten, Ressourcen und deren Beziehungen sowie der Austauschbeziehungen des Unternehmens mit seiner Umwelt. Informationssystemarchitektur (information systems architecture) = Modell der informationstechnischen Infrastruktur, der Daten und Anwendungsprogramme, der von dem Informationssystem unterstützten Aufgaben sowie der dazu benötigten Aufbau- und Ablauforganisation des entsprechenden Unternehmensteils. Softwarearchitektur (software architecture) = Modell der Komponenten eines Softwaresystems sowie deren Schnittstellen und Beziehungen untereinander sowie zum Systemumfeld. TOGAF = The Open Group Architecture Framework; Metamodell, Vorgehensmodell und unterstützende Werkzeuge zur Entwicklung von Unternehmensarchitekturen. technische Infrastrukturarchitektur (infrastructure/platform architecture) = Modell der Struktur und der Beziehungen der technischen Komponenten, welche für den Betrieb der Anwendungssysteme notwendig sind. Unternehmensarchitektur (enterprise architecture) = Modell der Struktur eines Unternehmens aus betriebswirtschaftlicher Sicht, der strategischen Ziele sowie der Verfahren und Ressourcen zur Realisierung dieser Ziele.

44

Grundlagen des Informationsmanagements

Zweck der Architektur der Informationsinfrastruktur In vielen Unternehmen sind weder Informationssysteme noch die Informationsinfrastruktur nach einem einheitlichen Bauplan entwickelt worden. Vielmehr wurden sie – oft im Verlauf von Jahrzehnten – mit unterschiedlichen Zielen und Prioritäten, unter verschiedenen technischen, fachlichen und ökonomischen Rahmenbedingungen geplant, realisiert und weiter entwickelt. Teile der Informationsinfrastruktur wurden häufig zunächst als Insellösungen geplant und implementiert sowie später nach und nach integriert. Die Folge sind komplexe und nur wenig transparente Strukturen. Die Integration von Insellösungen verursacht hohe Kosten. Es kommt zu ungewollten Redundanzen und anderen Qualitätsproblemen. Außerdem müssen sowohl einzelne Informationssysteme als auch große Teile der Informationsinfrastruktur den sich schnell ändernden Anforderungen der Informationsnachfrager, den Wettbewerbsbedingungen und dem technischen Fortschritt angepasst werden. Unternehmen ändern ihre Geschäftsmodelle, Teile der betrieblichen Leistungserstellung werden in andere Unternehmen ausgelagert (vgl. Lerneinheit OUTSO), Geschäftsprozesse werden verändert (vgl. Lerneinheit GPMAN). Im Idealfall werden diese Änderungen in den unterstützenden Informationssystemen nachvollzogen. Zahlreiche Informationsinfrastrukturen scheinen diesen Anforderungen aber nicht gewachsen zu sein. Das hat dazu geführt, dass Informationssysteme in vielen Unternehmen nicht angemessen auf die strategischen Ziele des Unternehmens ausgerichtet sind und dass die Informationssysteme die an sie gestellten fachlichen und wirtschaftlichen Anforderungen oft nicht erfüllen. Diese Probleme haben zu der Forderung nach einem Management der IT-Architekturen bzw. nach dem Management der Architektur der Informationsinfrastruktur geführt (vgl. z. B. Kappelman).

Funktionen von Architekturen Architekturen können verschiedene Funktionen übernehmen und unterschiedlichen Verwendungszwecken dienen. Es lassen sich drei grundlegende Funktionen unterscheiden: die Beschreibungs-, die Kommunikations- und die Gestaltungsfunktion von Architekturen. Im Rahmen der Beschreibungsfunktion dienen Architekturen dazu, die Ist-Situation abzubilden. Architekturen sollen die Gesamtzusammenhänge der Informationsinfrastruktur eines Unternehmens möglichst ganzheitlich, das heißt auf einem hohen Abstraktionsniveau repräsentieren. Angesichts oft komplexer und über Jahrzehnte gewachsener, in der Regel nicht zentral koordinierter Informationsinfrastrukturen ist diese Art der Beschreibung notwendig, um Transparenz zu schaffen und einen Überblick zu gewinnen. Leitungsaufgaben im Zusammenhang mit der Informationsinfrastruktur werden von unterschiedlichen Personengruppen wahrgenommen, z. B. Mitgliedern der Unternehmensleitung, Verantwortlichen für das IT-Controlling, Informationsmanagern oder Projektleitern. Problematisch ist, dass diese Personengruppen oft unterschiedliche Arbeits- und Denkweisen haben und selbst innerhalb eines Unternehmens häufig verschiedene Begriffe für dieselben Sachverhalte verwenden. Das erschwert die Kommunikation erheblich. Architekturen können eine wichtige Kommunikationsfunktion übernehmen und einen gemeinsamen Bezugspunkt sowie Sprachmittel zur Verfügung stellen.

Architektur der Informationsinfrastruktur (ARCHI)

45

Die Informationsinfrastruktur wird in fast allen Unternehmen kontinuierlich verändert. Soll sich dieser Wandel nicht unkoordiniert vollziehen, ist eine gemeinsame Basis für den Entwurf der Soll-Situation, oder anders formuliert, für die Gestaltung der Informationsinfrastruktur notwendig. Im Rahmen der Gestaltungsfunktion übernimmt die Architektur dabei die Rolle eines konzeptionellen Planungs- und Gestaltungsansatzes. Krcmar bezeichnet die Architektur daher auch als „Generalbebauungsplan“. Dieser definiert den Rahmen für die Gestaltung von Elementen der Informationsinfrastruktur, z. B. für die Planung neuer Informationssysteme oder die Integration bestehender Anwendungen. Die in einem der folgenden Abschnitte beschriebenen Architekturprinzipien haben für die Gestaltungsfunktion eine wichtige Bedeutung. Die Architektur ist eine Grundlage für viele Aufgaben, die einen Überblick über die Informationsinfrastruktur benötigen. Dazu gehören das strategische Informationsmanagement (z. B. für Investitions- oder Outsourcing-Entscheidungen, vgl. Lerneinheit OUTSO), das Geschäftsprozessmanagement (vgl. Lerneinheit GPMAN), die inner- und überbetriebliche Integration von Informationssystemen (z. B. im Rahmen der Enterprise Application Integration oder des Supply Chain Managements), die Gestaltung betrieblicher Querschnittsfunktionen (z. B. Qualitäts-, Sicherheits- oder Wissensmanagement, vgl. Lerneinheiten QUALM, SICHM und WIMAN), die Ermittlung des Informationsbedarfs (vgl. Lerneinheit INBAN) oder andere Teilaufgaben des Informationsmanagements (z. B. Governance und Servicemanagement, vgl. Lerneinheiten GOVER und SEMAN). Architekturen sind außerdem eine wichtige Informationsquelle für Entwicklungsprojekte. Die Darstellung des Gesamtzusammenhangs der Informationsinfrastruktur erlaubt es, Teilarchitekturen abzuleiten (z. B. von logischen Datenmodellen aus der Datenarchitektur), die einerseits auf das jeweilige Projekt bzw. das zu entwickelnde System zugeschnitten sind und andererseits den Gesamtzusammenhang nicht vernachlässigen.

Architekturbegriff Unter der Architektur eines Systems wird dessen Organisation verstanden, welche sich in den Komponenten und deren Beziehungen zueinander sowie zum Systemumfeld manifestiert. Häufig werden auch Gestaltungsprinzipien und Konstruktionsregeln zur Architektur gezählt (vgl. z. B. IEEE 1471-2000, ISO/IEC 42010:2007 und TOGAF). Jedes System hat eine Architektur, aber nicht jede Architektur ist explizit dargelegt. Man muss also unterscheiden zwischen dem impliziten Bauplan eines Systems und der expliziten Repräsentation dieses Bauplans, der Architekturbeschreibung. Wenn nicht anders vermerkt, wird der Ausdruck Architektur in dieser Lerneinheit im Sinne einer expliziten Beschreibung verwendet. Aus Vereinfachungsgründen wird die Bezeichnung Architektur der Informationsinfrastruktur mit Architektur abgekürzt. Eine Architektur kann den tatsächlichen oder den geplanten Zustand eines Systems beschreiben. Der erste Fall wird in TOGAF als Ist-Architektur, der zweite als Ziel-Architektur bezeichnet. In den meisten Empfehlungen zur Beschreibung von Architekturen werden zwei Gestaltungsmittel verwendet. Erstens wird eine Architektur in der Regel nicht in ihrer Gesamtheit

46

Grundlagen des Informationsmanagements

betrachtet, sondern es werden Teilarchitekturen unterschieden (z. B. Daten- oder Softwarearchitekturen), um diese detaillierter behandeln zu können. Zweitens werden verschiedene Perspektiven bzw. Sichten gebildet, um den Schwerpunktsetzungen der verschiedenen Interessengruppen (z. B. der Unternehmensleitung oder den Systemanalysten) besser gerecht werden zu können. Dementsprechend kann es für jedes System unterschiedliche Teilarchitekturen geben, welche die spezifischen Erfordernisse der jeweiligen Verwendungszwecke bzw. Interessengruppen betonen. In den Normen IEEE 1471-2000 und ISO/IEC 42010:2007 werden weitere Gestaltungsmittel zur Beschreibung von Architekturen softwareintensiver Systeme vorgestellt.

Teilarchitekturen Sowohl in der wissenschaftlichen Literatur als auch in der Unternehmenspraxis werden verschiedene Teilarchitekturen verwendet. Abbildung ARCHI-1 stellt den Versuch dar, die verschiedenen Teilarchitekturen im Zusammenhang darzustellen. In den Rechtecken im linken Teil der Abbildung sind wesentliche Inhalte dargestellt. Die Ovale im rechten Teil stellen die verschiedenen Teilarchitekturen dar. Die horizontale Anordnung der Ovale soll andeuten, welche Architekturen welche Inhalte umfassen. Einige Inhalte sind in verschiedenen Architekturen enthalten. Dies wird durch die Überlappung der Architekturen veranschaulicht. Die gestrichelten Umrisse der Ovale weisen darauf hin, dass die Einordnung und Abgrenzung der Architekturen nicht eindeutig ist, da diese in der Literatur unterschiedlich definiert werden.

Geschäftsmodell Betriebliche Aufgaben Aufbau- und Ablauforganisation Anwendungsprogramme & Daten Technische Infrastruktur

Unternehmensarchitektur

Unternehmensstrategie Geschäftsarchitektur

Informationssystemarchitektur

Anwendungsarchitektur Softwarearchitektur

Datenarchitektur

techn. Infrastrukturarchitektur

Abb. ARCHI-1: Überblick über verschiedene Teilarchitekturen

Unternehmensarchitektur ist das umfassendste Modell. Nach Sinz beschreibt die Unternehmensarchitektur die Struktur eines Unternehmens aus betriebswirtschaftlicher Sicht, die strategischen Ziele sowie die Verfahren und Ressourcen zur Realisierung dieser Ziele (vgl. Lerneinheiten SZIEL, STRAT und SPLAN). Die Unternehmensarchitektur kann in verschiedene Teilarchitekturen differenziert werden. Diese werden im Folgenden erörtert. Eine Geschäftsarchitektur ist ein Modell der Organisation eines Unternehmens, ihrer wesentlichen Komponenten, Ressourcen und deren Beziehungen sowie der Austauschbeziehungen des Unternehmens mit seiner Umwelt. Dazu gehört eine Beschreibung der zentralen Kundengruppen und der Leistungen, die das Unternehmen anbietet, die betrieblichen Aufga-

Architektur der Informationsinfrastruktur (ARCHI)

47

ben und Aufgabenträger, wesentliche Lieferanten, Wettbewerber und Kooperationspartner sowie die Informationsflüsse und Leitungsstrukturen des Unternehmens. Eine Anwendungsarchitektur bildet die Funktionalität und den Zusammenhang der Anwendungssysteme in einem Unternehmen ab. Abhängig vom Verwendungszweck können auch Architekturen für einzelne Aufgabengebiete (z. B. Finanz- oder Personalwesen) gebildet werden. Eine Informationssystemarchitektur ist ein Modell der informationstechnischen Infrastruktur, der Daten und Anwendungsprogramme, der von dem Informationssystem unterstützten Aufgaben sowie der dazu benötigten Aufbau- und Ablauforganisation des entsprechenden Unternehmensteils. Eine Softwarearchitektur umfasst die Komponenten eines Softwaresystems sowie deren Schnittstellen und Beziehungen untereinander sowie zum Systemumfeld. Zu einer Datenarchitektur gehören die für das betrachtete Aufgabengebiet wesentlichen Datenbestände und ihre strukturellen Beziehungen. Hierzu zählen insbesondere die für das Unternehmen wesentlichen Datenbanken und Data-Warehouse-Systeme (vgl. Lerneinheit DATEM). Die technische Infrastrukturarchitektur umfasst die technischen Komponenten (z. B. Hardware, Betriebssysteme, Middleware, Kommunikationseinrichtungen), welche für den Betrieb der Anwendungssysteme notwendig sind, sowie ihre Beziehungen zueinander. Die technischen Komponenten werden auch als Systemplattform bezeichnet.

Metamodelle für Architekturen Es sind zahlreiche Metamodelle (im englischen auch als architecture frameworks bezeichnet) für die Entwicklung von Architekturen publiziert worden. Sie unterscheiden sich darin, auf welche Teilarchitektur der Schwerpunkt gelegt wird, im Hinblick auf die berücksichtigten Inhalte und Perspektiven sowie den Detaillierungsgrad. In den folgenden Abschnitten werden drei dieser Metamodelle beispielhaft dargestellt (vgl. zu einem Überblick über weitere Metamodelle Schekkerman).

Framework for Information Systems Architecture 1987 publizierte Zachman das Framework for Information Systems Architecture. 1992 veröffentlichte er zusammen mit Sowa ein erweitertes Metamodell, welches in der Folge mehrfach überarbeitet wurde und zurzeit als Zachman Enterprise Framework 2 vorliegt. Dieses ist in Abbildung ARCHI-2 dargestellt.

48

Grundlagen des Informationsmanagements

Inventory (What?)

Process (How?)

Network Organization Timing (Where?) (Who?) (When?)

Motivation (Why?)

Scope (Strategists) Business (Executive Leaders) System (Architects) Technology (Engineers) Component (Technicians) Operations (Workers) Abb. ARCHI-2: Zachman Enterprise Framework 2 (Quelle: nach Zachman 2009)

In den Zeilen der Matrix sind Perspektiven unterschiedlicher Rollen abgebildet. Diese werden im Folgenden stichwortartig beschrieben.      

Scope (Geltungsbereich): Sicht der Strategieverantwortlichen; geschäftsrelevante Gegenstände, Geschäftsprozesse, Organisationseinheiten und Unternehmensziele. Business (Unternehmens- bzw. Geschäftsmodell): Sicht der Führungskräfte; Darstellung und Erklärung geschäftsrelevanter Gegenstände, Prozesse und Organisationseinheiten im Zusammenhang. System (Fachentwurf): Sicht der Systemarchitekten; Datenmodelle, Anwendungen und Verteilung von Systemkomponenten. Technology (technischer Entwurf): Sicht der Techniker; Entwicklungsoptionen, technische Rahmenbedingungen und Restriktionen. Component (Systemkomponenten): Sicht der Entwickler; Detailentwürfe für einzelne Systemkomponenten. Operations (Aufgaben): Sicht der Aufgabenträger; Gestalt und Verhalten des Systems aus Sicht der Nutzer.

Die Spalten enthalten unterschiedliche Fragen: Welche Daten verarbeitet das System? (Was?); Wie werden die Daten verarbeitet? (Wie?); Wie sind die Systemkomponenten verteilt? (Wo?); Welche Organisationseinheiten bzw. Aufgabenträger sind für welche Teilaufgaben verantwortlich? (Wer?); Welche Funktionen werden bei welchen Ereignissen ausgelöst? (Wann?); Welche Ziele sollen mit welchen Mitteln erreicht werden? (Warum?) Für die einzelnen Zellen der Matrix werden verschiedene Beschreibungsmittel vorgeschlagen, mit deren Hilfe die Bestandteile einer Architektur modelliert werden können. Außerdem werden Regeln zur Anwendung des Metamodells formuliert.

Architektur integrierter Informationssysteme (ARIS) ARIS ist ein Metamodell zur Modellierung computergestützter Informationssysteme vom Fachkonzept bis zur Implementierung. Dabei steht die Unterstützung betriebswirtschaftlicher Geschäftsprozesse durch integrierte Informationssysteme im Vordergrund. Das Metamodell wird häufig in Form eines Hauses abgebildet. Dieses ist in Abbildung ARCHI-3 dargestellt. Das so genannte ARIS-Haus besteht aus fünf Sichten. Die Funktionssicht beschreibt betriebliche Aufgaben, damit verfolgte Ziele sowie entsprechende Anwendungssoftware. Die Orga-

Architektur der Informationsinfrastruktur (ARCHI)

49

nisationssicht umfasst die Aufbauorganisation sowie Aufgabenträger. Die Datensicht beschreibt die Umfelddaten der Vorgangsbearbeitung sowie Nachrichten, die Funktionen auslösen bzw. von ihnen erzeugt werden. Die Leistungssicht enthält alle materiellen und immateriellen Leistungen incl. der Geldflüsse. Die Steuerungs- oder Prozesssicht verbindet die anderen Sichten. Sie bildet den Rahmen für die Beschreibung der Geschäftsprozesse (vgl. Lerneinheit GPMAN). Jede Sicht ist im ARIS-Phasenmodell in die Entwicklungsphasen Fachkonzept, DV-Konzept und Implementierung unterteilt. In den einzelnen Phasen werden Teilaufgaben beschrieben, die zur Entwicklung von Elementen der Informationsinfrastruktur hilfreich sind. Scheer empfiehlt unterschiedliche Beschreibungsmittel, mit deren Hilfe Sichten bzw. Teilarchitekturen modelliert werden können. Außerdem beschreibt er Modellierungsprinzipien, welche die Bildung von Architekturen leiten können. Unter der Bezeichnung ARIS wird auch eine Sammlung von Softwarewerkzeugen angeboten, welche die Modellierung von Geschäftsprozessen bis hin zu Unternehmensarchitekturen unterstützen können.

Organisationssicht

MaschinenRessource

Organisationseinheit

Computer Hardware

Datensicht Ereignis

Menschliche Arbeitsleistung

Steuerungssicht MaschinenRessource

Organisationseinheit

Computer Hardware

Funktionssicht Menschliche Arbeitsleistung

Ziel

Ziel Funktion

Nachricht

Umfelddaten

StartEreignis

Umfelddaten

Ergebnis Ereignis

Funktion

InputLeistung

OutputLeistung

Software

Software

Leistungssicht Leistung

Abb. ARCHI-3: ARIS-Haus (Quelle: Scheer)

Ganzheitliche Informationssystem-Architektur Die ganzheitliche Informationssystem-Architektur von Krcmar spannt einen Bogen von der Unternehmensstrategie bis zur technischen Infrastruktur. Das Metamodell wird in Form eines Kreisels abgebildet. Dieser soll verdeutlichen, dass bei der Entwicklung einer Architektur alle Elemente berücksichtigt werden müssen, da sonst die Gefahr besteht, dass das System „aus dem Gleichgewicht“ gerät, d. h. seinen Zweck nicht mehr erfüllt.

50

Die Strategie des Unternehmens zieht sich durch den gesamten Kreisel. Damit soll ausgedrückt werden, dass die Strategie einerseits prägenden Einfluss auf die Gestaltung von Architekturen hat, andererseits aber auch von den Möglichkeiten und Grenzen der Informationsinfrastruktur geprägt wird. Auf der zweiten Ebene sind die Aufbau- und Ablauforganisation dargestellt, auf der dritten Ebene die Anwendungssysteme. Diese werden weiter in die Anwendungs-, die Daten- und die Kommunikationsarchitektur differenziert. Die Infrastruktur bildet die Basis des Kreisels. Sie bezeichnet die technischen Hard- und Softwarekomponenten. Der Vorschlag von Krcmar berücksichtigt die Unternehmensstrategie im Gegensatz zu den Metamodellen von Zachman und Scheer explizit. Das Metamodell von Krcmar ist aber nicht weiter differenziert oder näher beschrieben worden.

Grundlagen des Informationsmanagements

Strategie

ProzeßArchitektur

AnwendungsArchitektur

DatenArchi-

Infra-

AufbauorganisationsArchitektur

tektur

KommunikationsArchitektur

struktur

Abb. ARCHI-4: Ganzheitliche InformationssystemArchitektur (Quelle: Krcmar)

Entwicklung von Architekturen Es gibt verschiedene Vorgehensmodelle (vgl. Lerneinheit VOMOD) zur Entwicklung von Architekturen. Das international bekannteste Vorgehensmodell ist die TOGAF Architecture Development Method. Es wird von der Open Group entwickelt, einem internationalen Verband von IT-Anbietern und -Anwendern. Abbildung ARCHI-5 zeigt das Vorgehensmodell. In der einführenden Phase „Preliminary“ werden an der Architekturentwicklung Beteiligte und davon Betroffene zur konstruktiven Mitarbeit bewegt, Geltungsbereich und Rahmenbedingungen der zu entwickelnden Architektur definiert sowie Methoden und Werkzeuge für die Entwicklung ausgewählt. Im Zentrum des Vorgehensmodells steht das Management der Anforderungen. Die zentrale Stellung soll verdeutlichen, dass Anforderungen an die Architektur während der gesamten Entwicklung erhoben und überprüft werden sowie ggf. in die Entwicklung Eingang finden müssen. Das Ziel der Phase A „Architecture Vision“ besteht darin, die Unterstützung relevanter Führungskräfte zu gewinnen, genaue Ziele zu definieren, welche mit der Architekturentwicklung erreicht werden sollen, Bestandteile der Architektur zu definieren und zu priorisieren, Genehmigungen und Ressourcen für die Architekturentwicklung einzuholen sowie eventuelle Schnittstellen mit anderen Architekturentwicklungsvorhaben zu definieren. In Phase B „Business Architecture“ geht es darum, Ist- und Sollzustand der Geschäftsarchitektur und sich daraus ergebende Diskrepanzen zu beschreiben sowie Perspektiven auszuwählen, die geeignet sind, die mit der Architektur angestrebten Problemlösungsbeiträge zu verdeutlichen. Phase C „Information Systems Architectures“ hat zum Ziel, Ziel-Architekturen für Daten und Anwendungssysteme zu entwickeln, welche die sich

Architektur der Informationsinfrastruktur (ARCHI)

51

aus der Geschäftsarchitektur ergebenden Anforderungen erfüllen können. Phase D „Technology Architecture“ definiert die systemnahe Software sowie ggf. die Hardwaregrundlagen, die notwendig sind, um die Anwendungssysteme entwickeln und betreiben zu können. In Phase E „Opportunities and Solutions“ geht es darum, unterschiedliche Implementierungsoptionen zu beschreiben und auszuwählen, einen ersten Plan für die Implementierung der Architektur zu entwickeln sowie daraus abgeleitete Teilprojekte zu Preliminary definieren. Ziel der Phase F „Migration Planning“ ist, die verschiedenen Teilprojekte in eine sinnvolle Reihenfolge zu bringen, A Architecture Interdependenzen zu klären sowie Vision H Ziele zu definieren und RessourB Architecture Business Change cen zuzuweisen. In Phase G „ImArchitecture Management plementation Governance“ geht es darum, die Leitungsstrukturen für die verschiedenen Teilprojekte zur G C Requirements Implementation Information Management Architekturentwicklung aufzuGovernance Systems Architectures bauen. Phase H „Architecture Change Management“ etabliert Strukturen zur Identifizierung und F D Migration Technology Verfolgung von technologischen Planning Architecture E Entwicklungen sowie VerändeOpportunities and Solutions rungen im geschäftlichen Umfeld des Unternehmens und leitet darAbb. ARCHI-5: TOGAF Architecture Development Method aus Anforderungen an die Verän(Quelle: TOGAF) derung der Architektur ab. Die Darstellung des Vorgehensmodells als Kreislauf deutet an, dass die Architekturentwicklung ein kontinuierlicher Prozess ist. Hafner/Winter geben einen Überblick über weitere Vorgehensmodelle zur Entwicklung von Architekturen.

Architekturprinzipien Nach Stelzer sind Architekturprinzipien grundlegende Aussagen zur Konstruktion, Beschreibung und Evaluierung von Architekturen. Vitruvius hat im ersten Jahrhundert vor Christus für die Baukunst drei Prinzipien der Architekturgestaltung formuliert: (1) Venustas (Anmut, Schönheit, Reiz), (2) Utilitas (Nützlichkeit) und (3) Firmitas (Stabilität). Laut Foegen/ Battenfeld kann die Einhaltung dieser Prinzipien bei der Anwendungsentwicklung mit folgenden Fragen überprüft werden. Utilitas: Erfüllt das System die Anforderungen? Firmitas: Ist das System robust gegenüber Änderungen? Venustas: Ist das System klar und verständlich? Veranschaulicht die Struktur einem Sachkundigen die Funktionalität des Systems? Gestaltungsziele und Konstruktionsregeln sind für Softwarearchitekturen publiziert worden. Vogel et al. sehen die Reduktion der Komplexität und die Erhöhung der Flexibilität (oder Änderbarkeit) einer Architektur als Hauptprobleme, die mit Hilfe der folgenden Gestaltungs-

52

Grundlagen des Informationsmanagements

prinzipien gelöst werden sollen. Das Prinzip der losen Kopplung besagt, dass die Kopplung zwischen den Komponenten einer Architektur möglichst niedrig sein soll, wobei Kopplung die Stärke der Verbindungen zwischen bzw. den Grad der Abhängigkeit der Komponenten voneinander charakterisiert. Das Prinzip der hohen Kohäsion fordert, dass der Zusammenhang der Elemente innerhalb einer Komponente möglichst hoch ist. Das Prinzip des Entwurfs für Veränderungen verlangt, dass die Architektur so entworfen wird, dass vorhersehbare Änderungen leicht realisiert werden können. Das Separation-of-Concerns-Prinzip (Prinzip der Trennung von Zuständigkeiten) empfiehlt, dass verschiedene Aspekte eines Problems oder einer Aufgabe voneinander getrennt und jedes Teilproblem für sich behandelt wird. Das Information-Hiding-Prinzip (Prinzip des Verbergens von Informationen) legt nahe, dass einem Aufgabenträger nur der Teil der Information offenbart wird, der für die jeweilige Aufgabe benötigt wird. Das Abstraktionsprinzip verlangt, dass eine Architektur nur die für den jeweiligen Verwendungszweck relevanten Aspekte des Systems enthält und von irrelevanten Aspekten abstrahiert. Das Modularitätsprinzip fordert, dass eine Architektur aus wohl definierten Komponenten besteht, deren Aufgabenbereiche klar abgegrenzt sind. Das Rückverfolgbarkeitsprinzip besagt, dass erkennbar sein sollte, welche Anforderungen an das System durch welche Komponenten der Architektur realisiert werden. Außerdem sollten Elemente eines implementierten Systems einzelnen Komponenten der Architektur zugeordnet und verschiedene Sichten der Architektur aufeinander abgebildet werden können. Das Selbstdokumentationsprinzip empfiehlt, jede Information über eine Komponente zum Bestandteil dieser Komponente selbst zu machen. Das Inkrementalitätsprinzip legt nahe, eine Architektur inkrementell, d. h. Schritt für Schritt zu entwickeln. Diese Prinzipien sind weder überschneidungsfrei noch unabhängig voneinander. Vielmehr weisen sie vielfältige Überlappungen und Interdependenzen auf. Die Prinzipien haben sich im Software Engineering bewährt und können auch bei der Entwicklung von Architekturen für die Informationsinfrastruktur sinnvolle Unterstützung leisten. Als weitere Leitlinien für die Gestaltung von Architekturen eignen sich die von Becker/Rosemann/Schütte beschriebenen Grundsätze ordnungsmäßiger Modellierung.

Forschungsbefunde Aier/Riege/Winter berichten über Anwendungsszenarien und Objekte von Unternehmensarchitekturen (schriftliche Befragung von 219 Teilnehmern von zwei deutschsprachigen Konferenzen zu Unternehmensarchitekturen und Integrationsmanagement 2007, Rücklaufquote 27,8%). Die zehn am häufigsten genannten Anwendungsszenarien für Unternehmensarchitekturen sind: Management des Anwendungsportfolios, Planung IT-Strategie, Security Management, Standardsoftware-Einführung, IT-Konsolidierung, Business-IT-Alignment, Architekturkonformität von Projekten, Prozessoptimierung, Business-Continuity-Planning und Qualitätsmanagement. Auf die Frage „Welche Gestaltungsobjekte werden in der Unternehmensarchitektur berücksichtigt?“, wurden folgende zehn Objekte am häufigsten genannt: Applikationen, Hardwarekomponenten, Netzwerkkomponenten, Schnittstellen, strategische Vorhaben/Projekte, Applikationsdomänen, Software-Plattformen, Datenstrukturen, Geschäftsprozesse und Software-Komponenten.

Architektur der Informationsinfrastruktur (ARCHI)

53

Kappelman et al. haben das Management von Unternehmensarchitekturen in nordamerikanischen Unternehmen analysiert (Online-Befragung von 2863 Mitgliedern der Enterprise Architecture Working Group der Society for Information Management, Rücklaufquote 13 %, Untersuchungszeitraum 2007). Die fünf am häufigsten genannten Ziele und Funktionen von Unternehmensarchitekturen sin „provides a blueprint of organization’s business, data, applications, and technology“, „a planning tool“, „facilitates systematic change”, „a tool for decision making“ und „an alignment tool”. Die fünf meist genannten Nutzeneffekte von Unternehmensarchitekturen sind „improved interoperability among information systems“, „improved utilization of IT“, „aligning business objectives with IT“, „more effective use of IT resources“ und „better situational awareness“.

Aus der Praxis Unter der Bezeichnung Enterprise Architecture Management werden Softwarewerkzeuge angeboten, welche die Entwicklung von Architekturen unterstützen. Zu diesen Werkzeugen gehören der ARIS IT Architect der Software AG und planningIT der alfabet AG. Das Institute for Enterprise Architecture Developments (IFEAD) betreibt eine Website, auf der unter anderem eine Übersicht über verschiedene Softwarewerkzeuge zur Entwicklung von Architekturen gegeben wird (http://www.enterprise-architecture.info). Zeitler berichtet über Ergebnisse eines Workshops der Gartner Group zu „worst practices“ der Unternehmensarchitektur, bei dem u. a. folgende Fallstricke identifiziert wurden, die „sich niemand zum Vorbild nehmen sollte“ (1): Keine Verbindung der Architekturentwicklung mit Strategieplanung und Budgetierung; striktes Befolgen der Vorgaben von Frameworks und Vernachlässigung der Spezifika des Unternehmens; zu strikte Standardisierung der Architekturelemente und mangelnde Berücksichtigung der Anforderungen der Unternehmensbereiche; Lähmung der Architekturentwicklung durch schlechte Führung, insbesondere unkoordinierte Aktivitäten; mangelnder Fokus auf den Geschäftszielen und zu starke „Technikverliebtheit“; nicht ausreichende Kommunikation mit und Partizipation der Mitarbeiter in den Fachbereichen; zu starke Beschäftigung mit Softwarewerkzeugen bei gleichzeitiger Vernachlässigung von Mitarbeitermotivation; ausschließliche Dokumentation des IstZustands statt Entwicklung des Soll-Zustands der Informationsinfrastruktur; Auslegung von Unternehmensarchitektur als einmaliges Projekt statt als kontinuierlicher Prozess. Kontrollfragen 1. Welchen Beitrag leistet eine Architektur zur (Weiter-)Entwicklung der Informationsinfrastruktur? 2. Welche Teilaufgaben des Informationsmanagements können wie durch eine Architektur der Informationsinfrastruktur unterstützt werden? 3. Wie beurteilen Sie folgende These: „Eine Architektur bildet den Status quo der Informationsinfrastruktur ab“? 4. Welche Bedeutung haben lose Kopplung und hohe Kohäsion für die Informationssystemarchitektur? 5. Aus welchen Teilaufgaben besteht Architekturmanagement? Quellen Aier, S. / Riege, C. / Winter, R.: Unternehmensarchitektur – Literaturüberblick und Stand der Praxis. In: WIRTSCHAFTSINFORMATIK 4/2008, 292–304 Becker, J. / Rosemann, M. / Schütte, R.: Grundsätze ordnungsmäßiger Modellierung. In: WIRTSCHAFTSINFORMATIK 5/1995, 435–445 Foegen, M. / Battenfeld, J.: Die Rolle der Architektur in der Anwendungsentwicklung. In: Informatik Spektrum 5/2001, 290–301

54

Grundlagen des Informationsmanagements

Hafner, M. / Winter, R.: Vorgehensmodell für das Management der unternehmensweiten Applikationsarchitektur. In: Ferstl, O. K. et al. (Hrsg.): Wirtschaftsinformatik 2005. eEconomy, eGovernment, eSociety. Heidelberg 2005, 627–646 Kappelman, L. A. (Hrsg.): The SIM Guide to Enterprise Architecture. New York 2010 Kappelman, L. A. et al.: Enterprise Architecture: Charting the Territory for Academic Research. In: Kappelman, L. A. (Hrsg.): The SIM Guide to Enterprise Architecture. New York 2010, 96–110 Krcmar, H: Bedeutung und Ziele von Informationssystem-Architekturen. In: WIRTSCHAFTSINFORMATIK 5/1990, 395–402 Schekkerman, J.: How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. 3. A., Victoria, Canada 2006 Scheer, A.-W.: ARIS - Vom Geschäftsprozess zum Anwendungssystem. 4. A., Berlin 2002 Sinz, E. J.: Unternehmensarchitekturen in der Praxis - Architekturdesign am Reißbrett vs. situationsbedingte Realisierung von Informationssystemen. In: WIRTSCHAFTSINFORMATIK 4/2004, 315–316 Sowa, J. F. / Zachmann, J. A.: Extending and Formalizing the Framework for Information Systems Architecture. In: IBM Systems Journal 3/1992, 590–616 Stelzer, D.: Enterprise Architecture Principles: Literature Review and Research Directions. In: Dan, A. / Gittler, F. / Toumani, F. (Hrsg.): Service-Oriented Computing. ICSOC/ServiceWave 2009. Lecture Notes in Computer Science, Vol. 6275. Berlin 2010, 12–21 The Open Group (Hrsg.): TOGAF (The Open Group Architecture Framework) Version 9 "Enterprise Edition". http://www.opengroup.org/togaf; Abruf 16. Mai 2011 Vitruvius, M. P.: De Architectura Libri Decem. Zehn Bücher über Architektur. Wiesbaden 2004 Vogel, O. et al.: Software-Architektur. Grundlagen - Konzepte - Praxis. München 2005 Zachmann, J. A.: A Framework for Information Systems Architecture. In: IBM Systems Journal 3/1987, 276–292 Zachmann, J. A.: Zachman Enterprise Framework 2. http://www.zachmaninternational.com; Abruf 16. Mai 2011 Zeitler, N.: Die 13 "Worst Practices" der Enterprise Architecture. o.O. 18.03.2009, http://www.cio.de/873689; Abruf 18. Mai 2011 Vertiefungsliteratur Bass, L. / Clements, P. / Kazman, R.: Software Architecture in Practice. 2. A., Reading et al. 2003 Dern, G.: Management von IT-Architekturen. Leitlinien für die Ausrichtung, Planung und Gestaltung von Informationssystemen. 2. A., Wiesbaden 2006 Hanschke, I.: Strategisches Management der IT-Landschaft. Ein praktischer Leitfaden für das Enterprise Architecture Management. 2. A., München 2010. Lankhorst, M. et al.: Enterprise Architecture at Work. Modelling, Communication, and Analysis. 2. A., Berlin et al. 2009 Schekkerman, J.: Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice. Victoria, Canada 2008 Informationsmaterial Arbeitskreis Enterprise Architecture der Gesellschaft für Informatik http://akea.iwi.unisg.ch BITKOM Leitfaden Enterprise Architecture Management http://www.bitkom.org Enterprise Architecture Links http://www.bredemeyer.com Fachgruppe Informationssystem-Architekturen: Modellierung betrieblicher Informationssysteme (MobIS) der Gesellschaft für Informatik http://www.wi-inf.uni-duisburg-essen.de/MobisPortal/ Framework for Information Systems Architecture von Zachman http://www.zachmaninternational.com Institute for Enterprise Architecture Developments (IFEAD) http://www.enterprise-architecture.info Society for Information Management Enterprise Architecture Working Group SIMEAWG http://www.simnet.org The Open Group Architecture Framework http://www.togaf.org Website zu ANSI/IEEE Std 1471und ISO/IEC 42010 http://www.iso-architecture.org/ieee-1471 Normen IEEE 1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems – Description ISO/IEC 42010:2007 Systems and software engineering – Recommended practice for architectural description of software-intensive systems

Governance (GOVER) Lernziele Sie können Zweck, Ziele und Aufgaben von IT-Governance erklären. Sie kennen den Zusammenhang sowohl von IT-Governance und Corporate Governance als auch von ITGovernance und IT-Servicemanagement. Sie können Ziele und Inhalte von ISO/IEC 38500, CobiT und Val IT erörtern.

Definitionen und Abkürzungen Basel II = vom Basler Ausschuss für Bankenaufsicht formulierte Vorschriften, die u. a. darauf ausgerichtet sind, das Eigenkapital von Banken am tatsächlichen Risiko auszurichten. Business-IT-Alignment = Abstimmung bzw. gegenseitige Ausrichtung von Unternehmensstrategie und IT-Einsatz; zum Teil abgekürzt als IT-Alignment oder Alignment (von engl. adjusting a line). CobiT = Control Objectives for Information and Related Technology; Leitlinien zur Gestaltung der IT-Governance. Compliance = Einhaltung von Gesetzen, rechtlichen Bestimmungen, vertraglichen Vereinbarungen und unternehmensinternen Vorschriften. Corporate Governance = Gesamtheit der Leitungs-, Kontroll- und Steuerungsmechanismen, Regeln für die Verteilung von Rechten und Pflichten sowie der Rechenschaftspflicht und Haftung in einem Unternehmen. ISACA = Information Systems Audit and Control Association; internationaler Berufsverband für IT-Prüfungswesen, -Revision und -Sicherheit. ITGI = IT Governance Institute; Institut, das Hilfsmittel für IT-Governance – insbesondere CobiT – entwickelt und pflegt. IT-Governance = Teil der Corporate Governance, der auf die IT bezogen ist. KonTraG = Gesetz zur Kontrolle und Transparenz im Unternehmensbereich; es erweitert die Haftung der Unternehmensleitung und zwingt diese, ein Risikofrüherkennungssystem einzuführen sowie Aussagen zur Risikostruktur des Unternehmens zu publizieren. OECD = Organisation for Economic Co-operation and Development; Organisation für wirtschaftliche Zusammenarbeit und Entwicklung. operationelles Risiko (operational risk) = Risiko, das sich aus der betrieblichen Tätigkeit ergibt. Synonyme: operationales oder operatives Risiko. RACI = Responsible, Accountable, Consulted and Informed; Kurzbezeichnung von Rollen im Zusammenhang mit IT-Governance-Aufgaben. Sarbanes-Oxley Act = Gesetz, mit dem die Corporate Governance von Unternehmen verbessert werden soll, die an US-Börsen notiert sind; zum Teil abgekürzt als SOX. Solvency II = Vorhaben der Kommission der Europäischen Gemeinschaften, mit dem Vorschriften zur Eigenkapitalausstattung von Versicherungsunternehmen geregelt werden. Val IT = Enterprise Value: Governance of IT Investments; Leitfaden des ITGI zur Steigerung des Erfolgs von IT-Investitionen.

56

Grundlagen des Informationsmanagements

Zweck der IT-Governance IT-Governance ist der Teil der Corporate Governance, der auf die IT bezogen ist. In ISO/IEC 38500 wird das zum Ausdruck gebracht, indem dieser Aufgabenbereich als Corporate Governance of IT bezeichnet wird. Im Folgenden wird die Kurzbezeichnung IT-Governance verwendet. Corporate Governance umfasst die Gesamtheit der Leitungs-, Kontroll- und Steuerungsmechanismen für ein Unternehmen, Regeln für die Verteilung von Rechten und Pflichten sowie der Rechenschaftspflicht und Haftung. Corporate Governance verpflichtet die Unternehmensleitung zu einer verantwortungsvollen Unternehmensführung. Die OECD formuliert: „Corporate governance deals with the rights and responsibilities of a company’s management, its board, shareholders and various stakeholders.“ (11) Zahlreiche Regelungen, Vorschriften und Gesetze beeinflussen direkt oder indirekt ITEntscheidungen (vgl. Lerneinheit RECHT). Dazu gehören die erweiterte persönliche Haftung des Managements im Schadensfall (z. B. aufgrund von Verstößen gegen gesetzliche Bestimmungen wie Sarbanes-Oxley Act in den USA oder KonTraG in Deutschland), Schadenersatzansprüche und strafrechtliche Haftung (z. B. aufgrund von Verstößen gegen Datenschutzgesetze), Offenlegung operationaler Risiken bei Kreditaufnahme und Versicherungsabschlüssen (z. B. Basel II und Solvency II) sowie die im Schadensfall drohende Beweislastumkehr (d. h., dass nicht der Kläger die Schuld, sondern der Beschuldigte seine Unschuld beweisen muss) erfordern erweiterte Kontroll- und Steuerungsmaßnahmen. IT-Governance beschreibt Rahmenbedingungen für Einsatz, Steuerung und Kontrolle der IT aus Sicht der Unternehmensführung. Damit soll sichergestellt werden, dass definierte Unternehmensziele erreicht und rechtliche Rahmenbedingungen eingehalten werden. Der Zusammenhang zwischen IT-Governance und IT-Management lässt sich wie folgt beschreiben. ITGovernance gibt einen Handlungsspielraum in Form von Zielen, Rechten und Pflichten vor, den das IT-Management durch Leitungshandeln ausfüllen muss. In ISO/IEC 38500 wird Corporate Governance of IT definiert als: „The system by which the current and future use of IT is directed and controlled. Corporate governance of IT involves evaluating and directing the use of IT to support the organization and monitoring this use to achieve plans. It includes the strategy and policies for using IT within an organization.“ Weill/Woodham definieren ITGovernance als „…specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.“ (1) IT-Governance und Servicemanagement (vgl. Lerneinheit SEMAN) hängen eng miteinander zusammen. Daher weisen die Leitfäden für IT-Governance (z. B. CobiT) und Servicemanagement (z. B. ITIL) viele Überschneidungen auf. IT-Governance bildet die Schnittstelle zwischen Unternehmensführung und Informationsmanagement. Servicemanagement gestaltet die spezifischen Aufgaben des IT-Bereichs sowie der Schnittstellen zu den Fachbereichen.

Aufgaben der IT-Governance Die Hauptaufgaben (focus areas) der IT-Governance lassen sich nach ITGI (2007) und ITGI/KPMG wie folgt beschreiben (Begriffe in Klammern = Bezeichnungen in CobiT):

Governance (GOVER)



   



57

Verfolgung der Ziele der Stakeholder (stakeholder value drivers): IT-Governance soll gewährleisten, dass die Ziele der Stakeholder, d. h. der Eigentümer, Kreditgeber, Kunden, Lieferanten, Arbeitnehmer und des Staates, verfolgt bzw. deren Interessen gewahrt werden. Ausrichtung der IT an den Unternehmenszielen (strategic alignment): IT-Governance soll sicherstellen, dass die IT die Erreichung der Unternehmensziele unterstützt. Wertschöpfung (value delivery): Die IT soll so gestaltet werden, dass versprochener Nutzen in einem vereinbarten Zeitraum zu angemessenen Kosten geschaffen wird. Management der Ressourcen (resource management): Vorhandene Ressourcen (z. B. Informationssysteme, Infrastruktur, Wissen) sollen effizient eingesetzt werden. Risikomanagement (risk management): IT-Governance fördert das Risikobewusstsein der Unternehmensleitung und legt es nahe, ein System zum Risikomanagement einzuführen. Dies bezieht sich nicht ausschließlich auf Risiken der IT-Sicherheit (vgl. Lerneinheit SICHM), sondern auch auf Risiken, die sich aus Verträgen mit Kunden oder aus einer Abhängigkeit von einzelnen Technologien, Lieferanten oder Mitarbeitern ergeben. Leistungsmessung (performance measurement) prüft die Erreichung der strategischen IT-Ziele, der Ziele von IT-Projekten, die Leistungsfähigkeit von IT-Prozessen, die Wirtschaftlichkeit der IT-Services (vgl. Lerneinheit SEMAN) sowie die Effektivität und Effizienz der Ressourcennutzung im IT-Bereich.

Die Hauptaufgaben der IT-Governance sind in Abbildung GOVER-1 dargestellt. Wertschöpfung (value delivery)

Abstimmung der IT mit den Unternehmenszielen (strategic alignment)

Verfolgung der Ziele der Stakeholder (stakeholder value drivers)

Management der Ressourcen (resource management)

Risikomanagement (risk management) Leistungsmessung (performance measurement) Abb. GOVER-1: Hauptaufgaben der IT-Governance (Quelle: nach ITGI/KPMG)

Daraus lassen sich folgende Aufgaben ableiten:  

Abstimmung der IT-Ziele und -Strategie mit den Unternehmenszielen und der Unternehmensstrategie, d. h. Business-IT-Alignment) (vgl. Lerneinheiten SZIEL und STRAT), Sicherstellung der Wirtschaftlichkeit der IT (vgl. Lerneinheiten WIRTA und CONTR),

58

    

Grundlagen des Informationsmanagements

Gewährleistung der Compliance: Einhaltung gesetzlicher Regelungen, vertraglicher Vereinbarungen sowie unternehmensinterner Bestimmungen (vgl. Lerneinheiten RECHT und REVIS), Klärung von Entscheidungsbefugnissen und Verantwortungsbereichen sowie Einrichtung und Anpassung einer angemessenen Strukturorganisation für die IT (vgl. Lerneinheiten STELL und STRUK), Schaffung von Transparenz über die IT-Infrastruktur und die IT-Aufgaben (vgl. Lerneinheiten ARCHI und CONTR), Sicherheitsmanagement (vgl. Lerneinheit SICHM und NOMAN) sowie Qualitätsmanagement (vgl. Lerneinheit QUALM).

ISO/IEC 38500 ISO/IEC 38500 Corporate Governance of Information Technology formuliert Leitlinien für Mitglieder der Unternehmensleitung zur Gestaltung der IT-Governance. Die Anwendung der Norm soll Vertrauen schaffen, dass die IT effektiv, effizient und für alle Stakeholder akzeptabel eingesetzt wird. Zu diesem Zweck werden in der Norm sechs Prinzipien formuliert:      

Verantwortung (responsibility): Einrichtung von Verantwortungsbereichen für die IT. Strategie (strategy): Ausrichtung der IT auf die Unternehmensstrategie. Beschaffung (acquisition): Etablierung nachvollziehbarer Entscheidungsprozesse für ITInvestitionen. Leistung (performance): Sicherstellung der Leistungsfähigkeit der IT. Konformität (conformance): Einhaltung relevanter Bestimmungen. Menschlichkeit (human behaviour): Beachtung der Bedürfnisse derjenigen, die vom ITEinsatz betroffen sind. business pressures

business needs

Corporate Governance of IT evaluate

monitor

direct

performance, conformance

proposals

plans, policies

business processes IT projects

IT operations

Abb. GOVER-2: Modell der IT-Governance (Quelle: ISO/IEC 38500)

In Abbildung GOVER-2 ist das Modell dargestellt, mit dem in der ISO/IEC 38500 die Aufgaben der IT-Governance und deren Zusammenhang zum IT-Servicemanagement umrissen werden. Demnach bestehen die Hauptaufgaben der IT-Governance darin, für Entwicklung (IT projects) und Betrieb (IT operations) von Informationssystemen Grundsätze (policies) und Pläne (plans) vorzugeben (direct), Vorschläge (proposals) des IT-Bereichs zu evaluieren (evaluate) sowie die Leistung der IT (performance) und die Einhaltung aller relevanten Bestimmungen (conformance) zu überwachen (monitor).

Governance (GOVER)

59

CobiT Control Objectives for Information and Related Technology (CobiT) sind Leitlinien, die 1993 zunächst von der ISACA und seit 2000 vom ITGI zur Gestaltung der IT-Governance entwickelt werden. Die folgenden Ausführungen beschreiben die Version 4.1 aus dem Jahr 2007. CobiT stellt control objectives dar, ein Begriff, der häufig mit Kontrollziele übersetzt wird; zutreffender ist die Bezeichnung Vorgaben zur Steuerung der IT.

Aufgabenbereiche und Aufgaben CobiT gliedert IT-Governance in vier Aufgabenbereiche (domains), die sich laut ITGI (2007) an der in der Praxis verbreiteten Einteilung von IT-Aufgaben in Planung (plan), Entwicklung (build), Betrieb (run) und Überwachung (monitor) orientieren:    

Planung und Organisation (PO – plan and organise) formuliert Ziele und schafft Voraussetzungen für die beiden folgenden Aufgabenbereiche. Beschaffung und Implementierung (AI – acquire and implement) stellt Lösungen (im Wesentlichen Informationssysteme) zur Verfügung. Betrieb und Unterstützung (DS – deliver and support) betreibt Informationssysteme und unterstützt deren Benutzer. Überwachung und Evaluierung (ME – monitor and evaluate) prüft, in welchem Ausmaß die im ersten Aufgabenbereich formulierten Ziele erreicht werden.

Die vier Aufgabenbereiche werden in 34 Aufgaben und mehr als 200 Aktivitäten gegliedert. Jede der 34 Aufgaben wird in CobiT mit folgender Struktur beschrieben:     



Input beschreibt, welche Informationen zur Durchführung der Aufgabe benötigt werden. Steuerungsvorgaben (control objectives) beschreiben, über welche Eigenschaften der Aufgabe und der Ergebnisse der dafür verantwortliche Mitarbeiter informiert sein muss. Output beschreibt, welche Ergebnisse mit der Aufgabe erreicht werden sollen. Ziele und Kennzahlen beschreiben, mit welchen Mitteln die Aufgabe evaluiert werden kann. RACI-Diagramme zeigen für jede Aktivität, wer für die Ausführung zuständig ist (responsible), wer rechenschaftspflichtig ist (accountable), wer um Rat gefragt werden kann (consulted) und wer über die Ergebnisse der Aktivität zu informieren ist (informed). Reifegradmodelle (vgl. Lerneinheit MEQUA) dienen zur Bestimmung der Reife einer Aufgabe und geben Hinweise für deren Weiterentwicklung.

Abbildung GOVER-3 zeigt die Aufgabenbereiche, deren Elemente und Interdependenzen. Die gestrichelten Linien stellen den Zusammenhang zwischen den vier Aufgabenbereichen und den 34 IT-Governance-Aufgaben dar. Da die einzelnen Aufgaben in anderen Lerneinheiten behandelt werden (vgl. Methodenverweise), werden diese hier nicht näher erläutert.

60

Grundlagen des Informationsmanagements

business objectives governance objectives CobiT

ME1 Monitor and evaluate IT performance ME2 Monitor and evaluate internal control ME3 Ensure regulatory compliance ME4 Provide IT governance

information criteria

PO1 Define a strategic IT plan PO2 Define the information architecture PO3 Determine technological direction PO4 Define the IT processes, organisation and relationships PO5 Manage the IT investment PO6 Communication management aims and direction PO7 Manage IT human resources PO8 Manage quality PO9 Assess and manage IT risks PO10 Manage projects

monitor and evaluate

plan and organise IT resources

deliver and support

DS1 Define and manage services levels DS2 Manage third-party services DS3 Manage performance and capacity DS4 Ensure continuous service DS5 Ensure system security DS6 Identify and allocate costs DS7 Educate and train users DS8 Manage service desk and incidents DS9 Manage the configuration DS10 Manage problems DS11 Manage data DS12 Manage the physical environment DS13 Manage operations

acquire and implement

AI1 Identify automated solutions AI2 Acquire and maintain application software AI3 Acquire and maintain technology infrastructure AI4 Enable operation and use AI5 Procure IT resources AI6 Manage change AI7 Install and accredit solutions and changes

Abb. GOVER-3: Aufgabenbereiche der IT-Governance nach CobiT (Quelle: nach ITGI 2007)

Governance (GOVER)

61

Control objectives CobiT spezifiziert für jede der 34 Aufgaben folgende Vorgaben zur Steuerung der IT:   

 



Ziele (process goals and objectives): Für jede Aufgabe werden Ziele definiert, die einen möglichst engen Bezug zu den Unternehmenszielen haben sollen. Die Zielerreichung soll mit Kennzahlen überprüft werden. Verantwortung (process ownership): Für jede Aufgabe werden eine verantwortliche Person ernannt sowie deren Rolle und Verantwortungsbereich definiert (z. B. für Entwurf, Zielerreichung und Verbesserung der Aufgabe). Reproduzierbarkeit (process repeatability): Jede Aufgabe soll so gestaltet werden, dass bei wiederholter Ausführung unter ähnlichen Rahmenbedingungen die erwünschten Ergebnisse produziert werden können. Gleichzeitig soll die Aufgabe so flexibel sein, dass auf Änderungen von Rahmenbedingungen angemessen reagiert werden kann. Verantwortung für Aktivitäten, Zwischenergebnisse und Produkte (roles and responsibilities): Die wichtigsten Aktivitäten, Zwischenergebnisse und Produkte jeder Aufgabe werden definiert. Dafür wird jeweils ein Verantwortlicher festgelegt. Grundsätze, Pläne und Verfahren (policy, plans and procedures). Für jede Aufgabe wird definiert und bekannt gegeben, mit welchen Grundsätzen, Plänen und Verfahren die Aufgabe geplant und entworfen, dokumentiert und überprüft sowie aufrechterhalten und verbessert wird. Leistungsverbesserung (process performance improvement): Für jede Aufgabe werden Kennzahlen definiert, mit denen die Leistung evaluiert werden kann. Das Ausmaß der Zielerreichung wird überprüft; bei signifikanten Soll/Ist-Abweichungen werden Verbesserungsmaßnahmen eingeleitet.

Qualitätsmerkmale für Information In CobiT werden folgende Qualitätsmerkmale für Information (information criteria bzw. business requirements for information) genannt (vgl. zu Qualitätsmerkmalen für Daten die Lerneinheit DATEM):       

Effektivität (effectiveness): Informationen sind relevant und angemessen für die betrieblichen Aufgaben; sie sind rechtzeitig verfügbar, korrekt, konsistent und benutzbar. Effizienz (efficiency): Informationen werden mit möglichst geringem Ressourceneinsatz zur Verfügung gestellt. Vertraulichkeit (confidentiality): Vertrauliche Informationen werden vor Veröffentlichung und unbefugter Nutzung geschützt. Integrität (integrity): Informationen sind fehlerfrei, vollständig und aussagekräftig. Verfügbarkeit (availability): Benötigte Informationen stehen für betriebliche Aufgaben zur Verfügung. Compliance: Bei der Informationsverarbeitung werden Gesetze, rechtliche Bestimmungen, vertragliche Vereinbarungen und unternehmensinterne Vorschriften eingehalten. Zuverlässigkeit (reliability): Informationen werden in geeigneter Weise bereitgestellt, damit Führungskräfte das Unternehmen steuern und ihre gesetzlich geforderte oder vertraglich vereinbarte Verantwortung wahrnehmen können.

62

Grundlagen des Informationsmanagements

Die Merkmale beziehen sich auf alle betrieblichen Informationen, sowohl auf die, welche zur Ausübung der Aufgaben der Unternehmensleitung (z. B. Governance) erforderlich sind, als auch auf die, welche Fachkräfte zur Bewältigung ihrer Aufgaben benötigen.

Reifegradmodell für IT-Governance-Aufgaben Jede Aufgabe kann mit einem Reifegradmodell evaluiert werden. Dieses Reifegradmodell ist nach dem Vorbild des Capability Maturity Model for software (CMM) des Software Engineering Institute (SEI) gestaltet (vgl. Lerneinheit MEQUA). Das Reifegradmodell hilft dem IT-Management, die Reife der Aufgaben zu bestimmen und gibt Hinweise für deren Verbesserung. Jede Aufgabe (bei detaillierter Betrachtung jede Aktivität) kann anhand folgender Skala mit einem von sechs Reifegraden bewertet werden:   

 



0 nicht existent (non-existent): Die Aufgabe wird nicht ausgeführt. 1 unorganisiert (initial/ad hoc): Bestimmte Probleme sind bekannt, es gibt aber keinen einheitlichen Prozess, mit dem diese bekämpft werden. Probleme werden ad hoc von einzelnen Personen gelöst. 2 wiederholbar (repeatable but intuitive): Ähnliche Probleme werden von verschiedenen Personen mit ähnlichen Mitteln bewältigt. Es gibt keinen einheitlichen und dokumentierten Prozess. Die Verantwortung für die Lösung von Problemen liegt bei einzelnen Personen. 3 definiert (defined): Die Aufgabe ist standardisiert und dokumentiert. Die Mitarbeiter befolgen im Wesentlichen die Vorgaben für die Durchführung der Aufgabe, aber es wird nicht jede Abweichung entdeckt. 4 gesteuert und messbar (managed and measurable): Das Management überprüft, ob die Vorgaben eingehalten werden; wenn das nicht der Fall ist, werden Gegenmaßnahmen ergriffen. Die Durchführung der Aufgabe wird kontinuierlich verbessert, einige Aktivitäten werden automatisch ausgeführt. 5 optimiert (optimised): Die Durchführung der Aufgabe ist über längere Zeit kontinuierlich verbessert worden; wichtige Aktivitäten werden automatisch ausgeführt.

Val IT Val IT ist ein vom ITGI herausgegebener Leitfaden, der Unternehmen helfen soll, den Erfolgsbeitrag von IT-Investitionen zu bewerten, zu überwachen und zu verbessern. Val IT ist kompatibel mit und komplementär zu CobiT. Die folgenden Ausführungen beziehen sich auf die Version 2.0 aus dem Jahr 2008. Val IT beschreibt sieben Prinzipien, mit denen die Wirtschaftlichkeit von IT-Investitionen (vgl. Lerneinheit WIRTA) sichergestellt werden soll. 



Alle IT-Investitionsvorhaben werden als Portfolio betrachtet (vgl. Lerneinheit SPLAN). Verschiedene Investitionsmöglichkeiten werden im Hinblick auf Kosten und Nutzen miteinander verglichen und es werden diejenigen realisiert, die den höchsten Erfolgsbeitrag versprechen. Bei der Evaluierung von Investitionsvorhaben (vgl. Lerneinheit EVALU) werden alle Aspekte berücksichtigt, die Einfluss auf die Wirtschaftlichkeit haben (z. B. Kenntnisse

Governance (GOVER)

  





63

und Fähigkeiten der Mitarbeiter, positive und negative Auswirkungen auf die Geschäftsprozesse sowie auf die Struktur- und Ablauforganisation des Unternehmens). Investitionsvorhaben werden über den gesamten Lebenszyklus (vgl. Lerneinheit LEMAN) hinweg geplant, gesteuert und kontrolliert, von der Planung bis zur Außerdienststellung. Da es verschiedene Typen von IT-Investitionen gibt (z. B. im Hinblick auf Kosten, Risiken und Nutzen), werden diese mit jeweils geeigneten Methoden evaluiert, geplant, gesteuert und kontrolliert. Zur Evaluierung des Erfolgs von IT-Investitionen werden Kennzahlen für das gesamte IT-Portfolio, einzelne IT-Investitionen, für IT-Dienstleistungen und IT-Ressourcen definiert und deren Werte regelmäßig geprüft (vgl. Lerneinheit KENNZ). Bei signifikanten Abweichungen von Planwerten werden korrigierende Maßnahmen eingeleitet. In Maßnahmen zur Erfolgssteigerung (value delivery practices) von IT-Investitionen werden Stakeholder aus dem IT-Bereich und den Fachbereichen einbezogen. Allen Beteiligten werden klar definierte Aufgaben, Verantwortungsbereiche und Rechenschaftspflichten für den Erfolg der Investitionen zugewiesen. Die Wirtschaftlichkeit von Investitionen wird überprüft und bewertet; die dafür verwendeten Methoden werden kontinuierlich verbessert.

Zur Anwendung dieser Prinzipien werden drei Aufgabenbereiche (domains) vorgeschlagen, die in Val IT mit Aufgaben (processes) und Aktivitäten (key management practices) beschrieben werden. Ähnlich wie in CobiT werden Reifegrade definiert, mit denen die Reife der Aufgaben zur Steuerung der Wirtschaftlichkeit beurteilt werden kann. Die drei Aufgabenbereiche in Val IT sind: Steuerung der Wirtschaftlichkeit (value governance) umfasst folgende Aufgaben:    

Gewährleistung, dass Maßnahmen zur Steuerung der Wirtschaftlichkeit von Investitionen in die Corporate Governance und in die strategische Unternehmensführung eingebettet sind. Abstimmung der IT-Investitionen mit dem Finanzmanagement. Vorgabe von Zielen und Rahmenbedingungen, welche die Portfolios aus Investitionsvorhaben, IT-Dienstleistungen und IT-Ressourcen erfüllen sollen. Kontinuierliche Weiterentwicklung der Maßnahmen zur Analyse und Verbesserung der Wirtschaftlichkeit.

Portfoliomanagement (portfolio management) umfasst folgende Aufgaben:    

Optimierung des Portfolios der Investitionsvorhaben, um einen möglichst großen Beitrag der IT zum Unternehmenserfolg zu leisten. Definition von Entscheidungskriterien und Bereitstellung von Budgets für IT-Investitionen. Evaluierung, Priorisierung, Genehmigung, Zurückstellung oder Ablehnung von Investitionsvorhaben. Überwachung des Erfolgs von IT-Investitionen.

64

Grundlagen des Informationsmanagements

Investitionsmanagement (investment management) umfasst folgende Aufgaben:     

Steuerung von Investitionsprogrammen, d. h. Kombinationen aus einzelnen Investitionsvorhaben, die in einem fachlichen Zusammenhang stehen. Identifizierung fachlicher Anforderungen an und Definition wirtschaftlicher Ziele für Investitionsprogramme. Bewertung alternativer Möglichkeiten zur Realisierung der Investitionsprogramme. Regelung der Verantwortung und Rechenschaftspflicht für den Erfolg der Investitionsprogramme. Evaluierung der Wirtschaftlichkeit von Investitionsprogrammen über deren gesamten Lebenszyklus.

Forschungsbefunde Robb/Parent untersuchen, wie unterschiedliche Rechtssysteme und regulatorische Anforderungen sich auf die Gestaltung von IT-Governance auswirken (Fallstudien auf der Grundlage von Interviews mit Führungskräften ergänzt um teilnehmende Beobachtung und Dokumentenanalyse in je einer genossenschaftlichen Bank in Australien und Kanada, keine Angabe zum Untersuchungszeitraum). Die Bank in Kanada orientiert sich am Sarbanes-Oxley Act (SOX) und entsprechenden kanadischen Regelungen. IT-Governance ist in diesem Institut gemäß CobiT strukturiert, in erster Linie um eventuelle Strafen durch die US-amerikanische Börsenaufsicht (SEC) zu vermeiden. Robb/Parent betonen, dass selbst Einzelheiten der ITGovernance in der kanadischen Bank durch die SEC diktiert zu werden scheinen, wogegen IT-Governance in der australischen Bank sehr dezentral und individuell strukturiert ist. Die australische Bank muss sich nationalen Regelungen für die Finanzbranche unterwerfen, die im Vergleich zu SOX deutlich weniger detaillierte Vorgaben machen. Der Schwerpunkt der Governance-Maßnahmen ist in der australischen Bank auf die Erzielung angemessener Ergebnisse ausgerichtet und weniger auf die Art und Weise, wie diese verfolgt werden. Während die kanadische Bank bemüht ist, die Buchstaben relevanter Gesetze (insbesondere SOX) zu erfüllen, scheint sich die australische Bank eher am Geist der Regelungen zu orientieren. Die Verantwortung für die Einhaltung relevanter Vorschriften liegt in der australischen Bank bei den einzelnen Führungskräften, wogegen in der kanadischen Bank eher das Managementsystem insgesamt verantwortlich gemacht wird.

Aus der Praxis Laut einer Studie von Pricewaterhouse Coopers (PwC) halten 80% von 50 befragten ITFührungskräften internationaler Unternehmen IT-Governance in ihren Unternehmen für verbesserungsbedürftig. Der Grund dafür ist, dass die meisten keinen ganzheitlichen Ansatz verfolgen, sondern IT-Governance häufig nur auf Kontrollfragen zu operativen IT-Aufgaben einengen. In der Studie werden sechs Erfolgsfaktoren für eine funktionierende ITGovernance identifiziert. „Dazu zählt die aktive Unterstützung des Managements, eine kontinuierliche Informationspolitik gegenüber den betroffenen Anwendern, Konsequenz bei der Umsetzung und ein exakt definiertes Ziel- und Anreizsystem. Außerdem spielt ein evolutionärer Ansatz bei notwendigen Veränderungen sowie eine möglichst schlanke Organisations-

Governance (GOVER)

65

struktur eine wichtige Rolle.“ (Quelle: Tanja Wolf: IT-Governance in der Praxis. In: CIO. 26.02.2007. http://www.cio.de/strategien/methoden/833118; Abruf 10. Juni 2011) Dinter et al. beschreiben Rollen der auf die Informationslogistik (Informationsversorgung zur Entscheidungsunterstützung) bezogenen IT-Governance bei dem Energieversorgungsunternehmen E.ON. Ein Governance-Board übernimmt die Koordination der IT-Governance als Teil der Corporate Governance, die Verabschiedung der IT-Strategie sowie die Durchsetzung der daraus abgeleiteten Richtlinien. Die funktionale Verankerung der IT-Governance erfolgt in Centers-of-Excellence. Ein Corporate Center erarbeitet konzernweit gültige Architekturprinzipien, Richtlinien und Standards, die vom Governance-Board genehmigt werden müssen. Für die Kerngeschäftsprozesse existieren virtuelle Centers-of-Excellence, d. h. Arbeitsgruppen, die sich aus Vertretern des IT-Bereichs und der Fachbereiche zusammensetzen. Werden für einen Geschäftsprozess Anforderungen definiert, die auch andere Geschäftsprozesse betreffen, so wird das Center-of-Excellence zum Koordinator der verschiedenen Interessen und Anforderungen. Auf diese Weise wird eine geschäftsprozessübergreifende Abstimmung und Umsetzung der Anforderungen gewährleistet. In einer von ITGI (2011) in Auftrag gegebenen Studie (Web-basierte und telefonische Befragung von insgesamt 834 Führungskräften, davon 384 CEOs, CFOs und COOs sowie 450 ITLeitern von Unternehmen und Behörden in 21 Ländern, Untersuchungszeitraum Juni bis August 2010) wurden folgende Erkenntnisse erzielt: Wesentliche Ziele für GovernanceMaßnahmen sind: „ensuring that IT functionality is aligned with current business needs“ (von 37,9 % der Befragten an erster Stelle genannt), „managing costs“ (20,1 %), „increasing agility to support future changes in the business“ (11,6 %), „avoiding negative incidents“ (10,3 %), „achieving better balance between innovation and risk avoidance to improve return“ (9,5 %) sowie „complying with industry and/or governmental regulations“ (8,5 %). Die wichtigsten Hilfsmittel für Governance („enabler“) sind: „framework/standards related to governance of IT“ (284 von 450 IT-Führungskräften), „other IT best practice framework/standards“ (295) sowie „tool kits to support the implementation or improvement of the governance of IT“ (193). Die Governance-Systeme in den Unternehmen basieren u. a. auf folgenden Frameworks und Standards: „ITIL or ISO 20000“ (28 % der Unternehmen, Mehrfachnennungen möglich), „ISO 17799, ISO 27000, Information Security Framework or other security standards“ (21 %), „Six Sigma“ (15 %), „CobiT“ (13 %). Nur 5 % gaben an, Val IT zu verwenden. Folgende Einflussfaktoren sind für die Implementierung von Governance-Maßnahmen wesentlich: „business objectives or strategy“ (57 % der Befragten, Mehrfachnennungen möglich), „culture of the organization, its ways of working and human factors“ (50 %), „regulatory environment and specific compliance requirements“ (34 %) sowie „industy or market forces“ (24 %). Die wesentlichen Nutzeneffekte von Governance-Maßnahmen sind „improved management of IT-related risk“ (42 % der Befragten, Mehrfachnennungen möglich), „improved communication and relationships between business and IT“ (40 %), „lower IT costs“ (38 %), „improved IT delivery of business objectives“ (37 %), „improved tracking and monitoring of IT

66

Grundlagen des Informationsmanagements

performance“ (29 %), „improved business competitiveness“ (28 %), „improved return on IT investments“ (27 %) sowie „improved IT innovation“ (22 %). Methodenverweise Kennzahlensysteme (Lerneinheit KENNZ); Wirtschaftlichkeitsanalyse (Lerneinheit WIRTA); Nutzwertanalyse (Lerneinheit NUTZW); Evaluierungsmethoden (Lerneinheit EVALU); Kosten- und Leistungsrechnung (Lerneinheit KOLER); Sicherheitskonzepte (Lerneinheit SIKON); Methoden des Qualitätsmanagements (Lerneinheit MEQUA); Serviceebenen-Vereinbarungen (Lerneinheit SEVER). Kontrollfragen 1. Wie kann Governance im IT-Bereich implementiert werden? 2. Welche Argumente sind für Projekte zur Implementierung von IT-Governance relevant? 3. In welcher Beziehung stehen IT-Governance und IT-Servicemanagement? 4. Welche Aufgaben des Informationsmanagements werden durch IT-Governance beeinflusst? 5. Welche Inhalte werden in CobiT mit control objectives bezeichnet? Quellen Dinter, B. et al.: Governance in der Informationslogistik am Beispiel eines Energieversorgers. In: Dinter, B. et al. (Hrsg.): DW2008. Synergien durch Integration und Informationslogistik. Lecture Notes in Informatics (LNI) Proceedings. Bonn 2008, 249–266 ITGI (Hrsg.): CobiT 4.1: Framework, Control Objectives, Management Guidelines, Maturity Models. Rolling Meadows 2007 ITGI (Hrsg.): Enterprise Value: Governance of IT Investments. The Val IT Framework 2.0. Rolling Meadows 2008 ITGI (Hrsg.): Global Status Report on the Governance of Enterprise IT (GEIT). Rolling Meadows 2011 ITGI / KPMG (Hrsg.): IT Governance für Geschäftsführer und Vorstände. 2. A. 2003. http://www.isaca.org; Abruf 01. Juni 2011 Robb, A. / Parent, M.: Understanding IT Governance: A Case of Two Financial Mutuals. In: Journal of Global Information Management (JGIM) 3/2009, 59-77 Weill, P. / Woodham, R.: Don't Just Lead, Govern: Implementing Effective IT Governance. MIT Sloan Working Paper No. 4237–02. Cambridge 2002. http://cisr.mit.edu; Abruf 01. Juni 2011 Vertiefungsliteratur IT Governance Institute / Office of Government Commerce / IT Service Management Forum (Hrsg.): Aligning CobiT, ITIL and ISO 17799 for Business Benefit: Management Summary. Rolling Meadows 2005. http://www.itsmf.com; Abruf 01. Juni 2011 Johannsen, W. / Goeken, M.: Referenzmodelle für IT-Governance. Strategische Effektivität und Effizienz mit COBIT, ITIL & Co. Heidelberg 2007 Kozlova, E.: WI – Vergleichende Literaturstudie. IT-Governance. In: WIRTSCHAFTSINFORMATIK 5/2008, 418425 Teubner, A. / Feller, T.: Informationstechnologie, Governance und Compliance. In: WIRTSCHAFTSINFORMATIK 5/2008, 400–407 Weill, P. / Ross, J. W.: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Boston 2004 Weill, P. / Ross, J. W.: A Matrixed Approach to Designing IT Governance. In: MIT Sloan Management Review 2/2005, 26–34 Informationsmaterial Arbeitsberichte zu IT-Governance des Center for Information Systems Research (CISR) der MIT Sloan School of Management http://mitsloan.mit.edu/cisr/r-papers.php CobiT 5 – Informationen zur Version 5 von CobiT, die im Herbst 2011 erscheinen soll http://www.isaca.org European Corporate Governance Forum http://ec.europa.eu/internal_market/company/ecgforum/index_en.htm Information Systems Audit and Control Association (ISACA) http://www.isaca.org oder http://www.isaca.de IT Governance Institute http://www.itgi.org OECD (Hrsg.): OECD-Grundsätze der Corpoprate Governance. Neufassung 2004. Paris 2004 http://www.oecd.org/dataoecd/57/19/32159487.pdf; Abruf 01. Juni 2011 Normen ISO/IEC 38500:2008 Corporate Governance of Information Technology

Informationsrecht (RECHT) Lernziele Sie kennen die Wirkungen der rechtlichen Rahmenbedingungen auf das Handeln von Informationsmanagern und einen Ansatz zur Handlungsanalyse. Sie kennen rechtliche Vorschriften bezüglich Datenschutz, Softwareschutz, Produkthaftung, Vertragsrecht, Telekommunikationsrecht, E-Commerce-Recht und Mitbestimmung, die für das Handeln von Informationsmanagern von wesentlicher Bedeutung sind.

Definitionen und Abkürzungen ABGB = Allgemeines Bürgerliches Gesetzbuch (Österreich). BDSG = Bundesdatenschutzgesetz; amtliche Abkürzung für das Gesetz zur Fortentwicklung der Datenverarbeitung und des Datenschutzes der Bundesrepublik Deutschland. BGB = Bürgerliches Gesetzbuch (Deutschland). BITKOM = Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. (Deutschland). Datenoase (data oasis) = ein Staat, in dem es kein oder ein weniger strenges Datenschutzrecht gibt als in dem Staat, in dem sich der Unternehmensstandort befindet. DSG = Datenschutzgesetz; amtliche Abkürzung für das österreichische Bundesgesetz über den Schutz personenbezogener Daten und für das Schweizerische Bundesgesetz über den Datenschutz. DOS = Denial of Service. EDI = Electronic Data Interchange. GDPdU = Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (Deutschland). Haftung (liability) = Verpflichtung, für einen Mangel und dessen Folgen einzustehen. HGB = Handelsgesetzbuch (Deutschland, Österreich). ITIL = Information Technology Infrastructure Library. Mangel (defect) = Fehler, der den Wert oder die Tauglichkeit zum gewöhnlichen oder vertraglich vereinbarten Gebrauch mindert oder aufhebt. Nutzungsrecht (usufructuary right) = Recht, das den Inhaber einer Nutzungsbewilligung berechtigt, ein urheberrechtlich geschütztes Werk im vereinbarten Umfang zu nutzen. OR = Obligationenrecht (Schweiz) PHG = Produkthaftungsgesetz (Deutschland, Österreich). SigG = Signaturgesetz (Deutschland) und Bundesgesetz über elektronische Signaturen (Österreich). UGB = Unternehmensgesetzbuch (Österreich). Urheberrecht (copyright) = Recht, das geistige Werke schützt und nicht übertragbare Persönlichkeitsrechte und übertragbare Verwertungsrechte (Nutzungsrechte) umfasst. URG = Urheberrechtsgesetz (Schweiz). UrhG = Urheberrechtsgesetz (Deutschland, Österreich). ZGB = Zivilgesetzbuch (Schweiz).

68

Grundlagen des Informationsmanagements

Wirkung des Informationsrechts Mit Informationsrecht werden die verfassungs-, verwaltungs-, privat- und handelsrechtlichen Rechtsnormen bezeichnet, die im Zusammenhang mit der IT von Bedeutung sind, einschließlich der Rechtsprechung dazu. Synonyme sind IT-Recht, Rechtsinformatik und – vor allem in der Schweiz – (Daten- und) Informatikrecht, meist mit der unpassenden Formaldefinition „Rechtliche Aspekte der Informatik“. Informationsrecht ist eine typische juristische Querschnittsdisziplin; Gräwe hat dazu eine wissenschaftliche Analyse vorgelegt. Informationsmanagement ist primär Leitungshandeln, das unter Beachtung relevanter rechtlicher, zumeist gar nicht IT-spezifischer Regelungen (Gesetze und Rechtsprechung) erfolgt wie gewerblicher Rechtsschutz, Urheber- und Wettbewerbsrecht sowie auch Strafrecht (z. B. Ausspähen oder rechtswidriges Ändern von Daten, in der Rechtsprechung als Datendiebstahl, umgangssprachlich als Datenklau bezeichnet). Diese Lerneinheit erklärt Rechtsvorschriften, die für das Handeln von Informationsmanagern maßgeblich sind. Sie können in negativer Weise wirken, also ein bestimmtes Handeln oder eine Handlungsabsicht als unerwünscht, gegebenenfalls als nicht zulässig einordnen. Ihr positiver Einfluss besteht darin, ein bestimmtes Handeln zu unterstützten. Bei einzelnen Aufgaben sind Wirkungen in beide Richtungen denkbar (z. B. auf der strategischen Aufgabenebene besonders deutlich beim Sicherheits- und Katastrophenmanagement, vgl. Lerneinheiten SICHM und NOMAN, auf der administrativen Aufgabenebene beim Personal- und Vertragsmanagement, vgl. Lerneinheiten PERSM und VERMA). Die Einhaltung der Rechtsvorschriften – de facto der Zwang zu ihrer Erfüllung – sowie von Regeln (z. B. ITIL), Grundsätzen (z. B. GDPdU), Normen und Standards (z. B. ISO 9000) und unternehmensspezifischen Richtlinien (zusammen Compliance-Regeln genannt) mit Hilfe angemessener Instrumente wird als Compliance Management bezeichnet (compliance = zu Deutsch etwa Einhaltung von Regularien). Compliance-Anforderungen betreffen das gesamte Unternehmen, nur teilweise sind sie typisch für die IT, beispielsweise deshalb, weil Dokumente digitalisiert sind, die den Anforderungen entsprechend erstellt, archiviert, versendet usw. werden müssen (z. B. sicherer Austausch digitaler Dokumente über das Internet durch Verschlüsselung und digitale Signatur). Die Compliance-Regeln haben nach Art und Anzahl einen Umfang erreicht, der manuelles Management kaum noch ermöglicht; allein die bloße Verwaltung der Compliance-Regeln einschließlich ihrer Aktualisierung ist schwierig und aufwendig. Das Gegenüberstellen und Vergleichen, noch mehr aber das Erkennen der vielfältigen Zusammenhänge und Querverbindungen zwischen den Compliance-Regeln, ist ohne werkzeuggestützte Hilfsmittel kaum noch möglich. Diese müssen u. a. transparent machen, welche Compliance-Anforderungen durch eine geplante Maßnahme verletzt werden. Gefordert sind daher Werkzeuge mit umfassender Funktionalität für ein unternehmensweites, somit auch den IT-Bereich umfassendes Compliance Management. Für das Handeln von Informationsmanagern ist die Unterscheidung zwischen Privatrecht und öffentlichem Recht von Bedeutung. Privatrecht regelt alle Rechtsvorgänge zwischen Rechtssubjekten (Private), die nicht mit Hoheitsgewalt ausgestattet sind. Auch mit Hoheitsgewalt ausgestattete Rechtssubjekte (z. B. Bund, Länder und Gemeinden) können als Privatrechtssubjekte agieren (z. B. IT-Mittel einkaufen) und unterliegen dann dem Privatrecht

Informationsrecht (RECHT)

69

(z. B. dem Vertragsrecht). Rechtssubjekt ist, wer im Prinzip in der Lage ist, Träger von Rechten und Pflichten zu sein. Im Privatrecht gilt der Grundsatz der Privatautonomie, der dort seine Grenzen hat, wo die „guten Sitten“ verletzt werden. Nach der ständigen Rechtsprechung des deutschen Bundesverfassungsgerichts ist die Privatautonomie Teil der allgemeinen Handlungsfreiheit; sie genießt implizit Verfassungsschutz. Im Privatrecht gibt es nur wenige Rechtsvorschriften mit einer größeren Anzahl von Verboten (z. B. das Arbeitsrecht). Privatrechtliche Vorschriften haben einen geringeren Einfluss auf das Handeln von Informationsmanagern als Vorschriften des öffentlichen Rechts. Diese Vorschriften regeln alle Rechtsvorgänge, an denen ein mit Hoheitsgewalt ausgestattetes Rechtssubjekt in Ausübung der Hoheitsgewalt beteiligt ist. Die folgende Darstellung konzentriert sich daher auf das öffentliche Recht, und zwar auf jene Rechtsvorschriften, die für die IT von besonderer Relevanz sind.

Handlungsanalyse Bei dieser Analyse wird davon ausgegangen, dass ein bestimmtes Handeln geplant und dann auf Übereinstimmung mit den einschlägigen Rechtsvorschriften, im weiteren Sinne mit den Compliance-Regeln, überprüft wird. Im Fall der positiven Einflussnahme ist dieses Handeln eine Reaktion auf Rechtsvorschriften. Das erleichtert zwar die rechtliche Beurteilung, ändert jedoch nichts an der grundsätzlichen Vorgehensweise, mit der die technisch-wirtschaftliche Planung mit einer rechtlichen Planung koordiniert wird. Diese koordinierte Planung kann wie folgt gegliedert werden:    

Erster Arbeitsschritt: Operationale Formulierung des geplanten Handelns. Zweiter Arbeitsschritt: Informationsbeschaffung über alle Rechtsvorschriften, die das geplante Handeln einschränken könnten. Dritter Arbeitsschritt: Untersuchung des geplanten Handelns daraufhin, ob es durch die erfassten Rechtsvorschriften tatsächlich beeinflusst wird. Vierter Arbeitsschritt: Für den Fall, dass eine Beeinflussung festgestellt wird, Rückkopplung zum ersten Arbeitsschritt und Umformulierung des geplanten Handelns.

Koordinierungsprobleme zwischen Informationsmanagement und Recht können bei Einführung neuer Technologien entstehen, deren Rahmenbedingungen noch unklar sind. Beispielsweise konnte zu Beginn der Nutzung von EDI nur auf allgemeine Rechtsvorschriften (wie BGB bzw. ABGB und HGB bzw. UGB) zurückgegriffen werden (z. B. was die Schriftform von Verträgen und die Namensunterschrift betraf). Mit der Ausbreitung der Nutzung des Internets werden neue Rechtslücken erkennbar, die internationale, zumindest EU-weite gesetzliche Regelungen gegen Internetangriffe erfordern (z. B. gegen DOS-Attacken).

Datenschutzrecht Schutzobjekt ist das Persönlichkeitsrecht der informationellen Selbstbestimmung von Individuen (natürliche und juristische Personen), das mit anderen privaten Interessen (z. B. der Personalisierung als Marketinginstrument) und öffentlichen Interessen (z. B. der Videoüberwachung als Instrument zur Aufklärung von Straftaten) kollidieren kann. Die Bezeichnung Datenschutz für diesen Sachverhalt ist sprachlich unzutreffend, hat sich aber in Fachund Umgangssprache durchgesetzt. Datenschutzgesetze sind das Ergebnis gegenseitiger

70

Grundlagen des Informationsmanagements

Abwägung zwischen privaten und öffentlichen Interessen des Datenschutzes. Sie schränken in bestimmten Bereichen die Zulässigkeit der Erfassung (z. B. durch Videoeinsatz im öffentlichen Raum), Speicherung (z. B. von IP-Nummern durch Internetprovider) und Verarbeitung (z. B. Prognose der beruflichen Leistungsfähigkeit oder der Kreditwürdigkeit mit Hilfe eines Scoringsystems) personenbezogener Daten ein und normieren dort, wo ihre Verarbeitung zulässig ist, einen Standard. Daher gehören Maßnahmen zum Schutz personenbezogener Daten (Datensicherungsmaßnahmen) zu den gesetzlichen Anforderungen an den ITBetrieb (vgl. Lerneinheit SICHM). Dem Individuum werden Rechte eingeräumt, die es ihm ermöglichen, die Einhaltung des Standards zu kontrollieren, so dass es zur Wahrung seiner Rechte persönlich beitragen kann. Die Realisierung informationeller Selbstbestimmung erfordert neben dem rechtlichen Schutz also auch eine aktive Rolle der Betroffenen. Datenschutz bedeutet also nicht Datenverwendungsverbot, sondern Datenverwendungskontrolle. Personenbezogene Daten sind Daten, die Eigenschaften von Individuen abbilden, aus denen Information generiert werden kann. Gemäß § 3 Abs. 1 BDSG sind personenbezogene Daten Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person (Betroffener), im Sinne des österreichischen DSG § 4 Z. 1 sind auch juristische Personen Betroffene. Hierzu zählen Namen, Titel, Geburtsdaten, Anschriften, Rufnummern, Geschäftsbezeichnungen; dazu gehören auch Daten, die für eine Beurteilung der Einkommens- und Vermögensverhältnisse von Bedeutung sind, insbesondere Kreditdaten sowie Daten mit Werturteilen (z. B. Zeugnisse). Das Recht informationeller Selbstbestimmung umfasst nach höchster deutscher Rechtsprechung auch, „grundsätzlich selbst zu entscheiden, wann und innerhalb welcher Grenzen persönliche Lebenssachverhalte offenbart werden“ (Az. 1 BvR 2368/06). Das schweizerische DSG bezeichnet als Betroffene „natürliche oder juristische Personen, über die Daten bearbeitet werden“ und als Daten „alle Angaben, die sich auf eine bestimmte oder bestimmbare Person beziehen“. In Deutschland haben sowohl der Bund als auch die Bundesländer Datenschutzgesetze erlassen (BDSG bzw. Landesdatenschutzgesetze, z. B. BayDSG für Bayern). Dem gemeinsamen Schutzobjekt – dem Recht auf informationelle Selbstbestimmung – entsprechend, stimmen Begriffsbestimmungen und Erlaubnisvorschriften im Wesentlichen überein. Der Datenschutz im privaten Bereich ist im BDSG bundeseinheitlich geregelt. Zur Harmonisierung der Datenschutzgesetze hat der Europarat 1981 ein Datenschutzübereinkommen verabschiedet, das in den einzelnen Vertragsstaaten unterschiedlich umgesetzt wurde. Das Fehlen EU-weiter, einheitlicher Regelungen zum Datenschutz – zumindest in Form von Mindestanforderungen – beeinträchtigt den sicheren Datenverkehr in der EU; Kommunikationspartner können sich nicht auf einheitlicher Rechtsgrundlage bewegen. Das zwischen den Staaten bestehende Schutzgefälle kann Anlass dafür sein, Datenoasen zu nutzen.

Softwareschutzrecht Softwareschutz ist Gegenstand mehrerer Rechtsvorschriften, die für jeden, der Software entwickelt, Nutzungsrechte an Software vergibt oder erwirbt, von Bedeutung sind. Dabei wird unter Software nicht nur das Programm, sondern auch die dazu gehörende Dokumentation verstanden. Softwareschutz wird in erster Linie durch vertragliche Vereinbarungen bewirkt (Weitergabeverbot); es gilt das Vertragsrecht (vgl. Lerneinheit VERMA). Wird Soft-

Informationsrecht (RECHT)

71

ware vertragswidrig vervielfältigt und weitergegeben, kann nur gegen den Vertragspartner, nicht aber gegen den vorgegangen werden, an den die Software weitergegeben wurde. Software wird in der Regel von angestellten Mitarbeitern auf dienstvertraglicher Grundlage oder von freiberuflich Tätigen auf werkvertraglicher Grundlage entwickelt. Ist die Software urheberrechtsschutzfähig, stellt sich beim Dienstvertrag die Frage, wem die Nutzungsrechte zustehen. Die Rechtsprechung gesteht dem Arbeitgeber ein ausschließliches Nutzungsrecht ohne besonderes Entgelt an den Urheber zu. An der Softwareentwicklung beteiligte Mitarbeiter sind daher arbeitsrechtlich verpflichtet, das Nutzungsrecht an ihre Arbeitgeber zu übertragen. Zur Klarstellung empfiehlt sich eine arbeitsvertragliche Regelung, mit der die Übertragung der möglicherweise entstehenden Nutzungsrechte vereinbart wird. Beim Werkvertrag vereinbaren Auftragnehmer und Auftraggeber, ob und in welchem Umfang vom Auftragnehmer erworbene Nutzungsrechte an den Auftraggeber übertragen werden; es gilt weitgehend Vertragsfreiheit. Wenn Individualsoftware im Auftrag entwickelt wurde, deren strategischer Zweck die Erhaltung bestehender bzw. Schaffung neuer Wettbewerbsvorteile ist, sollte der Auftraggeber ein ausschließliches Nutzungsrecht werkvertraglich vereinbaren. Im Unterschied zum Vertragsrecht verschafft das Urheberrecht dem Softwareentwickler ein absolutes Recht und damit die Möglichkeit seiner Durchsetzung gegenüber jedem Dritten. Es besteht ein zivilrechtlicher Schutz (z. B. Anspruch auf Unterlassung) und bei Vorsatz auch ein strafrechtlicher Schutz durch das Urheberrecht. Neben Geld- und Gefängnisstrafen können „die Einziehung des Tatgegenstands, der Tatwerkzeuge und Erträge aus den Straftaten oder von Vermögensgegenständen, die im Wert diesen Erträgen entsprechen“, strafrechtliche Maßnahmen sein (so die EU-Richtlinie über strafrechtliche Maßnahmen zur Durchsetzung des geistigen Eigentums). Für Urheberrechtsfähigkeit von Software gelten die gleichen Anforderungen wie für Werke der Literatur und Kunst, nämlich das Vorliegen einer eigentümlichen geistigen Leistung. Sie liegt dann vor, wenn die Software in ihrer Architektur, Funktionalität oder Implementierung individuell ist, das heißt erkennbar andere Merkmale aufweist als andere Software. Der Urheberrechtsschutz erstreckt sich auch auf Schnittstellen. Urheberrechtlich geschützte Software verliert den Rechtsschutz nicht, wenn sie durch Reengineering (vgl. Lerneinheit LEMAN) verändert wird. Reengineering an urheberrechtlich geschützter Software wird allerdings nur dann als zulässig angesehen, wenn sie zur Herstellung der Interoperabilität dient. Ein über die Restrukturierung hinausgehendes Reverse Engineering ist rechtlich problematisch. Auch ist offen, welche rechtlichen Verpflichtungen die Entwickler bzw. Anbieter von Werkzeugen für das Reverse Engineering habrn. Eine wesentlich veränderte Software ist ein neues Werk, wenn die Bearbeitung eine eigentümliche geistige Schöpfung des Bearbeiters ist, vorausgesetzt, der Bearbeiter ist Urheber der zu ändernden Software oder hat der Bearbeitung zugestimmt. Haben mehrere Personen eine urheberrechtsfähige Software geschaffen, besteht eine Miturheberschaft aller Beteiligten. Datenbanken sind urheberrechtlich geschützt, wenn sie als Folge der Auswahl und Anordnung ihres Inhalts eine eigentümliche geistige Schöpfung sind (so genanntes Datenbankwerk). Wenn für Beschaffung, Bearbeitung oder Darstellung des Inhalts einer Datenbank eine nach Art und Umfang wesentliche Investition erforderlich war, genießt sie auch dann Urheberrechtsschutz, wenn sie kein Datenbankwerk ist.

72

Grundlagen des Informationsmanagements

In engem Zusammenhang mit dem Urheberrechtsschutz stehen Regelungen zur Kontrolle der Verbreitung digitaler Medien (insbesondere Film- und Tonaufnahmen, aber auch Software und elektronische Dokumente). Digital Rights Management (DRM) bezieht sich nicht nur auf Rechte im Sinne des Privatrechts oder des öffentlichen Rechts, weil „rights“ hier primär die Berechtigungen zur Benutzung digitaler Dokumente bedeutet, daher auch als Digital Restrictions Management bezeichnet. Digitale Rechteverwaltung in diesem Sinne geht über Zugriffskontrolle weit hinaus, weil nicht nur der Zugriff (wer darf welches Dokument öffnen?), sondern weil auch geregelt und protokolliert wird, was ein Zugriffsberechtigter mit dem Dokument tun darf bzw. getan hat (Lesen, Verteilen, Bearbeiten, Drucken usw.). Neben Vertragsrecht und Urheberrecht haben Patentrecht und Warenzeichenrecht für den Softwareschutz Bedeutung. Das Patentrecht schützt nicht Software als solche. Wenn aber ein Programm eine Erfindung im technischen Sinne enthält, die den Stand der Technik verändert, dann ist sie patentierbar. Deshalb wird diese Art von Erfindung als softwarebezogene Erfindung bezeichnet. Der Name eines Softwareprodukts kann durch das Warenzeichenrecht als Marke geschützt werden; dazu ist eine Anmeldung beim Patentamt erforderlich. Das Patentamt prüft, ob die angemeldete Marke die gesetzlichen Anforderungen erfüllt (z. B. ob sie zur Unterscheidung von anderen Softwareprodukten geeignet ist). Eine geschützte Marke darf für andere Softwareprodukte nicht verwendet werden.

Produkthaftungsrecht Das Produkthaftungsrecht stellt einen Zusammenhang zwischen Qualitätsmanagement (vgl. Lerneinheit QUALM) und Recht her. Er ist durch folgende Feststellung gekennzeichnet: Eine Qualitätsforderung zu erfüllen, ist eine Rechtspflicht, und aus dem Risiko, eine Qualitätsforderung nicht zu erfüllen, ergibt sich eine Rechtspflicht. Daher sind alle angemessenen und zumutbaren Maßnahmen der Qualitätssicherung zur Erfüllung der Qualitätsforderung zu ergreifen. Qualität ist zwar kein Rechtsbegriff, ist aber von erheblicher rechtlicher Bedeutung. Die Haftung für Qualität hat zwei rechtliche Grundlagen, das Vertragsrecht und das Deliktsrecht. Das auf Grundlage der EG-Produkthaftungsrichtlinie von 1985 harmonisierte Produkthaftungsrecht der EU hat in einigen EU-Staaten (so in Deutschland und in Österreich) zu einer Verschärfung der Produkthaftung durch die Produkthaftungsgesetze (PHG) und die Rechtsprechung dazu geführt. Sie besteht vor allem darin, dass Haftung kein Verschulden mehr voraussetzt; es genügt der Nachweis, dass ein Schaden durch einen Fehler des Produkts verursacht wurde. Daher haftet der Lieferant einer beweglichen Sache auch für Fehler, die einer seiner Vorlieferanten verursacht hat. Herrschende Meinung ist, dass Software im Sinne der PHG eine bewegliche Sache ist. Strittig ist, ob dies für jede Art von Software gilt. Beispielsweise ist strittig, ob Individualsoftware eine bewegliche Sache ist, für Standardsoftware ist dies unstrittig. Rechtlich problematisch ist auch die Tatsache, dass Software praktisch nie fehlerfrei ist bzw. sein kann, was insbesondere für Individualsoftware gilt, und dass in Überlassungsverträgen für Software meist ausdrücklich auf diese Tatsache hingewiesen wird. Für den Softwarelieferanten gelten daher besondere Anforderungen an die Instruktionspflicht. Der Kunde muss darin unterwiesen werden, wie er sich bei Auftreten eines Fehlers zu verhalten hat, um dessen Auswirkungen zu mindern oder sogar zu verhindern.

Informationsrecht (RECHT)

73

Vertragsrecht Die Bedeutung des Vertragsrechts für das Informationsmanagement ergibt sich aus dem Umfang der Budgets, die für die Beschaffung der IT-Mittel (insbesondere Hardware und Software) bereitgestellt werden müssen. Darüber hinaus ist es dann für das Handeln von Informationsmanagern relevant, wenn das Unternehmen auch Lieferant von IT-Mitteln ist. Schließlich entstehen im Zusammenhang mit der Auslagerung von IT-Funktionen (vgl. Lerneinheit OUTSO) vertragsrechtlich relevante Beziehungen. Das Vertragsrecht regelt die zwischen Privatpersonen oder juristischen Personen frei verhandelten und vereinbarten Rechtsbeziehungen. Gesetzliche Regelungen bieten oft nur eine grobe Struktur und nennen rechtliche Mindestforderungen. Durch Vertragsgestaltung können Vorstellungen und Bedürfnisse der Vertragsparteien verwirklicht werden. Die individuelle Gestaltung der Rechtsbeziehungen ist ein Ausfluss der Privatautonomie und damit der Freiheit des Individuums. Das Vertragsrecht ist in Deutschland im BGB, in Österreich im ABGB und in der Schweiz im OR und im ZGB kodifiziert. IT-Mittel sind im Sinne des Vertragsrechts bewegliche Sachen, so dass alle Regelungen des Vertragsrechts darauf anwendbar sind. Im Folgenden wird auf einige Besonderheiten eingegangen, und zwar auf Mängelhaftung für Software, Vertragskopplung, Softwarehinterlegung und elektronischer Datenaustausch (EDI).

Mängelhaftung für Software Da Software grundsätzlich nicht fehlerfrei entwickelt werden kann und geliefert wird, sind die üblichen Gewährleistungsregeln nicht anwendbar. Für die Gewährleistung entscheidend ist, um welche Art von Softwarefehler und damit – im rechtlichen Sinne – um welche Art von Mangel es sich handelt, wie folgende Beispiele zeigen:    

Eine vertraglich vereinbarte Funktion ist nicht vorhanden (Funktionsdefizit). Eine vorhandene Funktion wird nicht richtig ausgeführt (Funktionsmangel). Eine richtig ausgeführte Funktion arbeitet zu langsam (Leistungsmangel). Eine vertraglich vereinbarte Hardwarekomponente hat nicht die erforderliche Kapazität (Kapazitätsmangel).

Nicht in jedem Fall der Feststellung eines Mangels ist klar, ob er auch gerügt, also ob Mängelbeseitigung vom Lieferanten gefordert werden kann. Wenn eine erforderliche Funktion nicht „Stand der Technik“ ist und nicht vertraglich vereinbart wurde, kann sich der Softwarelieferant unter Berufung auf diese fehlende Definiertheit einer Mängelrüge widersetzen. Mangel im rechtlichen Sinne setzt Abweichung vom vereinbarten Soll oder von dem voraus, was dem gewöhnlichen Gebrauch entspricht. Wenn es sich um Standardsoftware handelt, lässt sich der gewöhnliche Gebrauch leicht feststellen, bei Individualsoftware ist das ex definitionem nicht möglich. Es empfiehlt sich daher, den Vertragsgegenstand in einem Lastenheft möglichst genau zu beschreiben und zum Vertragsbestandteil zu machen.

Vertragskopplung Es kommt in der Praxis häufig vor, dass die Hardware wie vertraglich vereinbart geliefert wird, die Software aber mangelhaft ist, nicht rechtzeitig oder nur teilweise geliefert wird. Ist die Hardware allein für den Käufer wertlos, was bei kleineren Computersystemen meist der

74

Grundlagen des Informationsmanagements

Fall ist, besteht ein rechtliches Interesse an der einheitlichen Behandlung beider Systemkomponenten auch dann, wenn darüber getrennte Verträge abgeschlossen wurden. Wird beispielsweise die Software nicht rechtzeitig geliefert, so dass ein Rücktrittsrecht vom Softwarevertrag besteht, soll der Käufer auch zum Rücktritt vom Hardwarevertrag berechtigt sein. Wenn Anbieter auf getrennten Verträgen bestehen sollten, reicht nach herrschender Rechtsmeinung ein Anschreiben des Käufers aus, in dem ausdrücklich auf das einheitliche Beschaffungsprojekt aller Systemkomponenten hingewiesen wird. Vertragskopplung ist auch bei mehreren Lieferanten eines Beschaffungsprojekts möglich (z. B. Generalunternehmerschaft, Konsortium). Ob über die Systemkomponenten hinaus weitere Verträge (z. B. Wartungsverträge) von der Vertragskopplung erfasst sind, ist strittig. Eine nicht nur wirtschaftliche, sondern auch rechtliche Bindung zwischen Verträgen über Systemkomponenten und deren Wartung kann über die Geschäftsgrundlage hergestellt werden. Beispielsweise ist die Kündigung des Wartungsvertrags „aus wichtigem Grund“ dann anzunehmen, wenn vom Hardwarevertrag zurückgetreten werden kann.

Softwarehinterlegung Nutzungsrechte an Software berechtigen im Allgemeinen nicht zur Herausgabe des Quellcodes. Zweck der Softwarehinterlegung ist es, im Fall der Insolvenz oder eines sonstigen Unvermögen des Verkäufers, die für den Käufer zeitraubende Auseinandersetzung mit einem Vergleichs- oder Konkursverwalter bzw. dem Verkäufer zu vermeiden. Die vereinbarte Leistung (Fertigstellung oder Wartung der Software) soll auch bei Unvermögen des Verkäufers erbracht werden können. Softwarehinterlegung erfolgt meist durch Übergabe des Quellcodes einschließlich Dokumentation an eine Hinterlegungsstelle (z. B. Rechtsanwalt oder Notar). Sie wird vom Verkäufer unwiderruflich angewiesen, Quellcode und Dokumentation bei Eintritt bestimmter Ereignisse (z. B. Eröffnung des Konkursverfahrens über das Vermögen des Verkäufers) an den Käufer herauszugeben und nutzen zu dürfen. Die Vereinbarung für die Hinterlegung ist Teil des Softwarevertrags, dem ein Hinterlegungsschein beigefügt wird.

Elektronischer Datenaustausch Bestellung und Auftragsbestätigung sind Willenserklärungen, die juristisch als nach außen erkennbare Willensäußerungen von Menschen definiert sind. Elektronische Bestellung und Auftragsbestätigung werden dann als solche Willenserklärungen angesehen, wenn sich die Beteiligten außerhalb der elektronischen Kommunikation darauf geeinigt haben, bestimmte computerisierte Operationen an Daten und an Datenflüssen als Willenserklärungen gegen sich gelten zu lasen. Der elektronische Datenaustausch stößt dort an Grenzen, wo rechtliche Formvorschriften bestehen (z. B. Schriftform bestimmter Verträge und Namensunterschrift).

Telekommunikationsrecht Die Verbreitung von Telediensten wie Telebanking und Teleshopping und deren Nutzung erfordern spezielle Regelungen, um die Rahmenbedingungen zu schaffen, unter denen sich Informations- und Kommunikationsdienste rechtlich gesichert ausbreiten können. In Deutschland wurde dafür das Informations- und Kommunikationsdienste-Gesetz geschaffen, das am 1.8.1997 in Kraft trat. Es umfasst das Gesetz über die Nutzung von Telediensten

Informationsrecht (RECHT)

75

(Teledienstegesetz), das Gesetz über den Datenschutz bei Telediensten (TelediensteDatenschutzgesetz) und das Gesetz zur digitalen Signatur (Signaturgesetz) sowie eine Reihe von Änderungen bestehender Gesetze (z. B. des Urheberrechtsgesetzes). Das am 26.2.2007 in Kraft getretene Telemediengesetz (TMG) fasst die Bestimmungen des Teledienstegesetzes und des Teledienste-Datenschutzgesetzes zusammen und enthält umfassendere und verschärfende Bestimmungen (z. B. Pflichtangaben im Impressum von Webseiten gem. § 5 TMG). In Österreich wurde mit dem Telekommunikationsgesetz, das am 20.8.2003 in Kraft trat und am 1.3.2006 verschärft wurde, der europäische Rechtsrahmen zum Kommunikationsrecht umgesetzt. Seit 1.3.2006 ist die TKG-Novelle 2005 in Kraft. Die für EU-Staaten spezifischen telekommunikationsrechtlichen Bestimmungen sind wesentlich von gemeinschaftsrechtlichen Vorgaben geprägt. Insbesondere auf Grundlage der wettbewerbsrechtlichen Bestimmungen des EG-Vertrages (Artikel 81 [vormals Art 85], 82 [vormals Art 86] und 86 [vormals Art 90]) haben die EU-Kommission bzw. das Europäische Parlament und der Rat der EU verschiedene Richtlinien und Verordnungen erlassen, die der Verwirklichung des Gemeinsamen Marktes für Telekommunikationsdienste dienen.

E-Commerce-Recht Mit E-Commerce wird die Abwicklung von Handelsfunktionen mit Hilfe des Internets bezeichnet, auf die alle typischen, außerhalb des Internets geltenden Rechtsvorschriften anwendbar sind (z. B. BGB bzw. ABG, HGB bzw. UGB). Für die Online-Abwicklung gibt es Besonderheiten, die durch das E-Commerce-Recht geregelt sind, dessen Bestimmungen sowohl Erleichterungen zur Förderung des E-Commerce als auch Schutz für Verbraucher vor den Risiken elektronischer Geschäftsabwicklung bieten. Mit der E-Commerce-Richtlinie 2000/31/EG hat die EU einen einheitlichen Rechtsrahmen für Dienste der Informationsgesellschaft, speziell des elektronischen Geschäftsverkehrs, geschaffen. Zentraler Inhalt der Richtlinie ist, dass die EU-Staaten die Möglichkeit zum elektronischen Vertragsabschluss in ihren Rechtsordnungen sicherstellen müssen. Die Umsetzung der Vorgaben durch das österreichische E-Commerce-Gesetz (ECG) regelt unter anderem die Impressumspflicht für Webseiten mit Gewinnerzielungsabsicht, Voraussetzungen beim elektronischen Vertragsabschluss, Bestimmungen über Providerhaftung, Haftungsbeschränkungen bei Suchmaschinen und Hyperlinks sowie anwendbares Recht. In diesem Zusammenhang relevant ist die EU-Richtlinie 98/84/EG über den rechtlichen Schutz von zugangskontrollierten Diensten und von Zugangskontrolldiensten vom 28.11.1998 (Zugangskontrollrichtlinie). Beispielsweise setzt das in Österreich im Juli 2000 in Kraft getretene Zugangskontrollgesetz (ZuKG) diese Richtlinie in nationales Recht um. Das ZuKG enthält – in Anlehnung an das UrhG – zivil- und strafrechtliche Tatbestände zum Schutz von Diensteanbietern. Es räumt ihnen das ausschließliche Recht ein, den Zugang zu einem von ihnen bereitgestellten Dienst in verständlicher Form von seiner vorherigen individuellen Erlaubnis abhängig zu machen. Es auch will verhindern, dass Vorrichtungen, die einen unbefugten Zugang zu geschützten Diensten ermöglichen (z. B. nicht autorisierte Decoder, Smartcards oder Programme, mit denen Passwörter oder sonstige Autorisierungscodes „geknackt“ werden können) gewerbsmäßig hergestellt, vertrieben oder beworben werden (Umgehungsvorrichtungen).

76

Grundlagen des Informationsmanagements

Mitbestimmungsrecht Schutzobjekt ist die Mitbestimmung von Arbeitnehmern bei wesentlichen organisatorischen Veränderungen, die durch Technologieeinsatz verursacht werden. Die im österreichischen Arbeitsverfassungsgesetz (für den privaten Bereich) bzw. Personalvertretungsgesetz (für den öffentlichen Bereich) und die im deutschen Betriebsverfassungsgesetz niedergelegten Rechtsvorschriften sind daher nicht spezifisch für den IT-Einsatz. Nach der Rechtsprechung in Deutschland ist beispielsweise die Einführung von Bildschirmarbeitsplätzen und von Personalinformationssystemen mitbestimmungspflichtig, und zwar nicht nur deren erstmalige Einführung, sondern auch jede maßgebliche Veränderung. Einrichtungen, die zur Messung und Überwachung der Leistung von Betriebsmitteln dienen (z. B. Log-Datei für Transaktionen), dürfen nicht zur Messung und Überwachung der Leistung von Mitarbeitern verwendet werden. Aus der Rechtsprechung lässt sich beispielsweise ableiten, dass Systeme der Betriebsdatenerfassung, welche die Daten der Mitarbeiter nicht anonymisieren, mitbestimmungspflichtig sind. Aus verschiedenen Rechtsvorschriften wird von Arbeitnehmerseite die Notwendigkeit, zumindest aber die Zweckmäßigkeit einer „Mitwirkung von Anfang an“ abgeleitet. Zur Vermeidung von Konflikten empfiehlt sich daher als Regel für das strategische Projektmanagement, bei Erreichen eines bestimmten Projektstatus den Betriebsrat zu unterrichten und zur Stellungnahme aufzufordern. Bei mitbestimmungspflichtigen Vorhaben ist der Abschluss einer entsprechenden Betriebsvereinbarung empfehlenswert. Jedenfalls muss verhindert werden, dass der Betriebsrat, berechtigt oder nicht, per Einstweiliger Verfügung den geplanten Zeitpunkt der Einführung bzw. Veränderung hinauszögern kann.

Forschungsbefunde Roßnagel stellt zum Verhältnis zwischen informationeller Selbstbestimmung und personenbezogener Personalisierung u. a. fest:    

Personalisierung kann mit dem Grundrecht auf informationelle Selbstbestimmung in Widerspruch geraten. Für individuelle Konflikte enthält das Datenschutzrecht einen angemessenen Interessenausgleich, der Personalisierung überwiegend dann zulässt, wenn sie mit Wissen und Zustimmung des Betroffenen erfolgt. Für die gesellschaftlichen Auswirkungen „allgegenwärtiger Personalisierung“ gibt es wenig Erkenntnisse und kaum Gestaltungsinstrumente. Eine integrierte technische und rechtliche Gestaltung muss den Unterstützungsleistungen von Personalisierung gerecht werden und versuchen, Kontrollpotenzial zu entkoppeln.

Der Befund zeigt beispielhaft die Notwendigkeit der Handlungsanalyse (z. B. im Rahmen der strategischen Maßnahmenplanung, vgl. Lerneinheit SPLAN). Amberg/Mossanen haben zur Frage der Compliance-Erfüllung u. a. festgestellt (Literaturanalyse, qualitativ-explorative Experteninterviews, Anzahl nicht angegeben, Untersuchungszeitraum 1.2007 bis 6.2007): „Im Laufe der Studie hat sich gezeigt, dass die Meinungen bezüglich des positiven Nutzens [sic!] von Compliance sehr stark differieren, jedoch über-

Informationsrecht (RECHT)

77

wiegend Bedarf an Compliance gesehen wird. Dieser kann mit softwarebasierten Tools zur Erfüllung von Compliance-Anforderungen teilweise gedeckt werden.“ Weiter wird festgestellt, dass „…Unternehmen zumeist nicht bereit sind, mehr Personal für die Erfüllung von Compliance-Anforderungen einzusetzen.“

Aus der Praxis Die Notwendigkeit der Prüfung der Mitbestimmungspflicht bei der Handlungsanalyse zeigt folgender Fall: Ein Unternehmen lässt in den Fahrzeugen der Außendienstmitarbeiter Sender installieren, die über Satellit Standortdaten an die Zentrale melden, um den Mitarbeitereinsatz zu koordinieren und zu optimieren (z. B. zwecks Minimierung der zurückgelegten Wegstrecken). Die Installation ist mitbestimmungspflichtig, gegebenenfalls von Anfang an, weil angenommen werden kann, dass sie auch zur Überwachung der Mitarbeiter verwendet wird. Das deutsche Bundesverfassungsgericht hat der Beschwerde eines Bürgers gegen eine in Regensburg geplante Videoüberwachung stattgegeben (Az. 1 BvR 2368/06). Mit dieser Entscheidung wird die in der Rechtsprechung überwiegend praktizierte ausdrückliche Betonung des Rechts der informationellen Selbstbestimmung, ein Grundrecht der Informationsgesellschaft zu sein (neben der Informationsfreiheit), bestätigt. Dies muss beispielsweise bei der Handlungsanalyse zur rechtlichen Beurteilung eines Systems gegen den Bücherschwund in Universitätsbibliotheken zur Generierung anderer technischer Lösungen führen (z. B. Einsatz der RFID-Technik). Videoüberwachung ist damit nicht grundsätzlich verboten, erfordert aber klare Gesetze über deren Zweck und Grenzen. Die Bestimmungen des BayDSG reichten im genannten Beispiel nicht aus. Angst vor Phishing ist der wichtigste Grund, auf Online-Banking zu verzichten. Hinzu kommen ungeklärte Haftungsfragen bei Online-Betrug sowie die Furcht vor Viren, Würmern und Trojanern. BITKOM fordert daher ein Gesetz gegen Phishing; bislang ist der Kontodatendiebstahl nicht eindeutig verboten. Die Polizei kann daher nur aktiv werden, wenn bereits ein Schaden entstanden ist; der Versuch ist nicht strafbar. (F.A.Z. vom 30.8.2007, 11.) Der GRC Manager (GRC = Governance, Risk and Compliance) von Computer Associates ist ein Werkzeug für das Compliance Management. Er basiert auf dem Unified Compliance Framework, einem Repository, das mehr als 4.000 Regeln und rund 280 Standards wie CobiT, COSO, NIST, ISO17799:2005, SOX, HIPAA, PCI und NERC umfassen soll und mit anderen (z. B. unternehmensspezifischen) GRC-Regelwerken konfigurierbar und erweiterbar sei. Der GRC Manager beschleunige den Prozess, GRC-Regelwerke zu erstellen und zu pflegen. IT-Abteilungen würden damit ihre Regelwerke an sich ändernde regulative Vorgaben leicht anpassen können. Im Unterschied zu anderen GRC-Lösungen werde das Compliance Management nicht tabellarisch mit Reports und Excel Sheets unterstützt, sondern verwende einen portfoliobasierten Ansatz. Eine grafische Auswertung erleichtere die Realisierung von Compliance-Anforderungen und kann bei der Beurteilung von Risiken helfen. Neue Technologien können mit bestehenden Rechtsnormen unvereinbar sein. Nach Auffassung von Alexander Dix, Beauftragter für Datenschutz und Informationsfreiheit des Landes Berlin, verstößt ortsunabhängiges Cloud Computing gegen das Datenschutzrecht und ist „nicht zulässig“. Dies gilt vor allem dann, wenn die Verarbeitung personenbezogener Daten außerhalb der EU stattfindet.

78

Grundlagen des Informationsmanagements

Kontrollfragen 1. Aus welchen Arbeitsschritten besteht die Handlungsanalyse und was soll sie bewirken? 2. Welches Recht wird durch Datenschutzgesetze geschützt? 3. Was soll eine vertraglich vereinbarte Softwarehinterlegung bewirken? 4. Womit kann „Mitwirkung von Anfang an“ begründet werden? 5. Warum entstehen Koordinierungsprobleme zwischen Informationsmanagement und Recht, wenn neue Technologien eingeführt und genutzt werden? Quellen Amberg, M. / Mossanen, K.: Forschungsbericht „Vorteile und Herausforderungen IT-gestützter Compliance-Erfüllung“. http://www.wi3.uni-erlangen.de/fileadmin/Dateien/Forschung/WI3_FB_2007.pdf; Abruf 12.11.2008 Brenn, C.: Zugangskontrollgesetz. Wien 2001 Heusler, B. / Roland, M.: IT-Vertragsrecht. Zürich 2004 Jahnel, D. / Schramm, A. / Staudegger, E. (Hrsg.): Informatikrecht. 2. A., Wien/New York 2003 Roßnagel, A.: Personalisierung in der E-Welt. In: WIRTSCHAFTSINFORMATIK 1/2007, 8–18 Roßnagel, A. (Hrsg.): Handbuch Datenschutzrecht. München 2003 Schulte, M. / Schröder, R. (Hrsg.): Handbuch des Technikrechts. Berlin et al. 2003 Zahrnt, C.: Richtiges Vorgehen bei Verträgen über IT-Leistungen. 2. A., Heidelberg 2005 Vertiefungsliteratur Becker, E. et al. (Hrsg.): Digital Rights Management – Technological, Economic, Legal and Political Aspects. Lecture Notes in Computer Science 2770. Berlin/Heidelberg 2003 Computer und Recht – Zeitschrift für die Praxis des Rechts der Informationstechnologien. http://www.computerundrecht.de Gräwe, S. L.: Die Entstehung der Rechtsinformatik – Wissenschaftshistorische und -theoretische Analyse einer Querschnittsdisziplin. Hamburg 2011 jusIT – Zeitschrift für IT-Recht. http://global.lexisnexis.com/at Moriz, H.-W. / Dreier, T.: Rechtshandbuch zum E-Commerce. 2. A., Köln 2005 Studiengesellschaft für Wirtschaft und Recht (Hrsg.): Internet und Recht – Rechtsfragen von E-Commerce und EGovernment. Wien 2004 Informationsmaterial Portal zur Informationsgesellschaft http://europa.eu.int/information_society/index_en.htm Softwareunternehmen CA: GRC Manager http://ca.com.de/ Übersicht über die Rechtsgrundlagen (neuer Rechtsrahmen, Liberalisierungsrichtlinien, Empfehlungen, Verordnungen, einschlägige EU-Rechtsakte) für den Telekommunikationssektor http://europa.eu.int/eur-lex/ Gesetze und Richtlinien Bundesgesetz über den Schutz zugangskontrollierter Dienste (Zugangskontrollgesetz – ZuKG, Österreich) Datenschutzgesetze: Gesetz zur Fortentwicklung der Datenverarbeitung und des Datenschutzes (Bundesdatenschutzgesetz – BDSG i. d. F. vom 14.1.2003, Deutschland); Bundesgesetz über den Schutz personenbezogener Daten (Datenschutzgesetz – DSG 2000, Österreich); Bundesgesetz über den Datenschutz (Datenschutzgesetz – DSG i. d. F. vom 12.12.2006, Schweiz). Signaturgesetze: Bundesgesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz – SigG i. d. F. vom 16.5.2001, Deutschland); Bundesgesetz über elektronische Signaturen (Signaturgesetz – SigG i. d. F. vom 1.1.2008, Österreich); Bundesgesetz über Zertifizierungsdienste im Bereich der elektronischen Signatur (ZertES i. d. F. vom 1.8.2008, Schweiz) EG- und EU-Richtlinien: Richtlinie über den Rechtsschutz von Computer-Programmen 91/250/EWG vom 14.5.1991 (Softwarerichtlinie); Richtlinien 95/46/EG vom 24.10.1995 (Datenschutzrichtlinie) und 2002/58/EG vom 12.7.2002 (Datenschutzrichtlinie für elektronische Kommunikation); Richtlinie über den elektronischen Geschäftsverkehr 2000/31/EG vom 8.6.2000 (e-commerce Richtlinie)

Informationsverhalten (INVER) Lernziele Sie erkennen die Notwendigkeit, sich mit dem menschlichen Informations- und Kommunikationsverhalten, kurz Informationsverhalten, auseinanderzusetzen. Sie wissen, dass es drei Formen des Informationsverhaltens gibt: intrapersonelles, interpersonelles sowie das die Mensch-Computer-Interaktion betreffende. Sie werden mit den ersten beiden Formen vertraut gemacht, weil sie für die Durchführung von strategischen, administrativen und operativen Aufgaben des Informationsmanagements sowie für die Methoden zur Aufgabenerfüllung von Bedeutung sind. Sie wissen, dass diese Lerneinheit mit den Grundlagen des Informationsverhaltens nur soweit vertraut macht, um dessen Bedeutung für das Informationsmanagement beurteilen zu können.

Definitionen und Abkürzungen ASP = Application Service Provider. Benutzungsschnittstelle (usage interface) = Hardware und Software, mit denen Kommunikation zwischen Menschen und Techniksystemen stattfindet. Gatekeeping = Prozess zum Kontrollieren eines Informationsflusses, um sich einen persönlichen Vorteil, in der Regel auf Kosten anderer, zu verschaffen. Informationsangebot (information supply) = Art, Qualität und Menge der Information, die zur Aufgabenerfüllung zur Verfügung steht. Informationsaufnahme (information reception) = Registrierung von Reizen über Zustände und Vorgänge durch Sinnesorgane mit der Folge der Erweiterung des Wissensbestands. Informationsbedürfnis (information need) = Art, Qualität und Menge der Information, die subjektiv zur Aufgabenerfüllung für erforderlich gehalten wird. Informationsdefizit (information deficit) = tatsächlicher oder wahrgenommener Mangel an Information in einer bestimmten Handlungssituation. Informationsüberflutung (information overload) = tatsächliches oder wahrgenommenes Zuviel an Information in einer bestimmten Handlungssituation. Informationsverhalten (information behavior) = auf Information gerichtetes Tun oder Unterlassen von Menschen. interpersonelles Informationsverhalten (interpersonal information behavior) = auf Kommunikation gerichtetes Tun oder Unterlassen von Menschen. intrapersonelles Informationsverhalten (intrapersonal information behavior) = mentaler, in einer Person ablaufender Prozess und daraus resultierende Verhaltensformen in Bezug auf Information. Kognition (cognition) = von einer Person ausgeführtes Verändern von Information, zu deren Erfolg eine Reihe von Fähigkeiten wie Wahrnehmung, Emotion, Aufmerksamkeit, Denken oder Gedächtnis beitragen. Mensch-Computer-Informationsverhalten (human-computer information behavior) = den Menschen betreffende Teile der Mensch-Maschine-Interaktion, die sich auf Information beziehen. Principle of Least Effort = theoretischer Ansatz zur Erklärung der Informationsaufnahme.

80

Grundlagen des Informationsmanagements

Bedeutung des Informationsverhaltens Das gesamte auf Information gerichtete Tun oder Unterlassen von Menschen wird von Gemünden als Informationsverhalten bezeichnet. Es umfasst intrapersonelles und interpersonelles Informationsverhalten sowie Mensch-Computer-Informationsverhalten. Verarbeitungsund Übertragungsprozesse, die in und zwischen maschinellen Systemen ablaufen, sind nicht Informationsverhalten, da es sich nicht um Information, sondern um Daten handelt. Informationsverhalten ist vor allem in den Informations-, Kommunikations- und Bibliothekswissenschaften Gegenstand von Forschung und Lehre. Die dort entwickelten Beschreibungs- und Erklärungsmodelle basieren meist auf kognitions- und sozialpsychologischen Erkenntnissen. Die Kognitionspsychologie ist primär Referenzdisziplin für intrapersonelles Informationsverhalten, das von Wahrnehmung, Emotion, Aufmerksamkeit, Denken sowie Gedächtnis abhängt. Referenzdisziplin für interpersonelles Informationsverhalten ist die Sozialpsychologie, die Phänomene von Information und Kommunikation in Gruppen bis hin zu größeren sozialen Systemen untersucht (z. B. selektive Weitergabe von Informationen, um persönliche Interessen zu verfolgen). Erkenntnisse zum Mensch-Computer-Informationsverhalten stammen aus der Psychologie, Ergonomie und der Angewandten Informatik sowie der Information Systems Discipline (z. B. Informationsverhalten als Funktion verwendeter Ein- und Ausgabegeräte sowie Formate der Informationsdarstellung wie Text und Bild). Bisherige Publikationen zum Informationsmanagement im deutschsprachigen Raum, so auch das vorliegende Lehr- und Handbuch, orientieren sich auf die Analyseebenen Organisationen (z. B. Unternehmen) und Organisationsteile (z. B. nach Funktionen oder Prozessen gegliederte Unternehmensteile). Nur eine Nebenrolle spielen bisher Individuen (z. B. Benutzer) und Gruppen (z. B. Projektteams). Für die Erklärung des Informationsmanagements als Teildisziplin der Wirtschaftsinformatik und insbesondere für die Gestaltung ihrer Erkenntnisobjekte Informationsfunktion und Informationsinfrastruktur spielt Informationsverhalten eine entscheidende Rolle. Dies und somit die Bedeutung des Informationsverhaltens anhand grundsätzlicher Überlegungen und exemplarischer Erläuterungen an Teilgebieten des Informationsmanagements (z. B. Wissensmanagement) oder spezifischen Methoden (z. B. Serviceebenen-Vereinbarungen) zu zeigen, ist primärer Zweck dieser Lerneinheit.

Formen des Informationsverhaltens Es werden die zwei Formen des Informationsverhaltens erklärt, welche für die Durchführung von strategischen, administrativen und operativen IM-Aufgaben sowie für die Anwendung dafür relevanter Methoden von Bedeutung sind, und zwar intrapersonelles Informationsverhalten und interpersonelles Informationsverhalten. Die den Menschen betreffenden Teile der Mensch-Maschine-Interaktion, die sich auf Information beziehen, das so genannte MenschComputer Informationsverhalten, werden hier nicht behandelt. Der Grund für den Fokus auf intra- und interpersonelles Informationsverhalten ist, dass das in diesem Lehr- und Handbuch verwendete Erklärungsmodell des Informationsmanagements (vgl. Lerneinheit ERMOD) nicht explizit die Benutzungsschnittstelle erfasst, für deren Gestaltung das Mensch-Computer Informationsverhalten von Relevanz ist.

Informationsverhalten (INVER)

81

Intrapersonelles Informationsverhalten Intrapersonelles Informationsverhalten bezeichnet mental, in einer Person ablaufende Prozesse sowie daraus resultierende Verhaltensformen in Bezug auf Information. Ausgangspunkt ist das von einer Person (z. B. von einem Aufgabenträger) subjektiv empfundene Informationsdefizit, das die Entstehung eines Informationsbedürfnisses zur Folge hat (vgl. Abbildung INVER-1) und durch die Merkmale eines Aufgabenträgers beeinflusst wird. Neben den Elementen der Kognition (z. B. Wahrnehmung, Emotion, Aufmerksamkeit, Denken und Gedächtnis) sind soziodemographische Eigenschaften (z. B. Geschlecht, Alter, Ausbildung, Familienstand, Einkommen, sozialer Status und ethnischer Hintergrund), kognitive Verhaltenstendenzen (z. B. Introversion versus Extraversion, analytisches versus heuristisches Problemlösen) sowie Persönlichkeitsvariable (z. B. Selbstsicherheit, Risikobereitschaft, Neugierde und Sicherheitsstreben) Merkmale eines Aufgabenträgers. Merkmale der Aufgabe

Informationsquellen

Merkmale des Aufgabenträgers

Merkmale der Information Informationsbedarf

Informationsdefizit

Informationsbedürfnis

Informationsnachfrage

Informationsangebot

Informationssuche

Informationsaufnahme

Informationsselektion

Informationsorganisation

Informationsverwendung

Elemente des intrapersonellen Informationsverhaltens im engeren Sinn

Antezedenzien

Elemente des intrapersonellen Informationsverhaltens im weiteren Sinn

Elemente der Kognition Wahrnehmung

Emotion

Aufmerksamkeit

Denken

Gedächtnis

Urheber: René Riedl (2011)

Reflexion

Abb. INVER-1: Erklärungsmodell des intrapersonellen Informationsverhaltens (Urheber: René Riedl, 2011)

Das Informationsbedürfnis ist eine Determinante der Informationsnachfrage, die auch vom Informationsbedarf abhängt, der durch Aufgabenanalyse ermittelt wird (vgl. Lerneinheit INBAN). Wie einfach bzw. schwierig die Ermittlung dieses Bedarfs ist, hängt in erster Linie von den Merkmalen einer Aufgabe ab. Mit zunehmender Strukturiertheit und abnehmender Veränderlichkeit von Aufgaben steigt die Einfachheit der Ermittlung des Bedarfs (vgl. Heinrich/Heinzl/Riedl 177 ff.).

82

Grundlagen des Informationsmanagements

Die Informationsnachfrage ist Ausgangspunkt des intrapersonellen Informationsverhaltens im engeren Sinne. Informationssuche, -aufnahme, -selektion, -organisation und -verwendung sind Verhaltensformen, die sich auf Information beziehen. Im Unterschied dazu sind ein vom Aufgabenträger gefühltes Informationsdefizit sowie das daraus entstehende Informationsbedürfnis und die Informationsnachfrage keine Verhaltensformen, sondern dem Verhalten vorgelagerte kognitive oder affektive Prozesse, also Antezedenzien des Informationsverhaltens im engeren Sinne. Die drei Antezedenzien und die fünf Verhaltensformen werden zum intrapersonellen Informationsverhalten im weiteren Sinn zusammengefasst (vgl. Abbildung INVER-1). Die Elemente des intrapersonellen Informationsverhaltens im engeren Sinne werden von mehreren Faktoren beeinflusst. So beeinflusst das Informationsangebot die Informationssuche, wobei das Angebot von den verfügbaren Informationsquellen (z. B. Webseiten, Bücher, andere Menschen) abhängt. Ein großes Informationsangebot führt in der Regel dazu, dass Aufgabenträger die Informationssuche einschränken. Sie tun dies, weil Aufgaben typischerweise innerhalb eines bestimmten Zeitrahmens und/oder Budgets zu erledigen sind und somit zu wenig Zeit bzw. zu geringe Budgets verfügbar sind, um alle Informationen zu berücksichtigen. Die Informationssuche wird auch wegen kognitiver Beschränkungen limitiert, um Informationsüberflutung zu vermeiden. Die Informationsaufnahme ist daher im Falle eines großen Informationsangebots selektiv. Zur Erklärung der Informationsaufnahme gibt es mehrere theoretische Ansätze, von denen einer der bedeutsamsten das Principle of Least Effort ist. Dieses Prinzip hat bislang vielen empirischen Falsifikationsversuchen standgehalten, hat folglich ein großes Erklärungspotenzial. Es sagt aus, dass Menschen bei der Informationsaufnahme gerade so viel Information berücksichtigen, dass ein bestimmtes Ziel (z. B. die Erledigung einer Aufgabe) erreicht werden kann. Dabei ist die zufriedenstellende Zielerreichung die Maxime, nicht der in einer Situation theoretisch erreichbare und somit höchste Zielerreichungsgrad. Der Sozialwissenschaftler Herbert Simon hat dieses Prinzip als „Satisficing“ bezeichnet und damit zum Ausdruck gebracht, dass Menschen in der Regel nach zufriedenstellenden, nicht nach optimalen Lösungen suchen. In dem in Abbildung INVER-1 dargestellten Erklärungsmodell folgt nach der Informationsaufnahme und -selektion die Informationsorganisation. Dabei werden im Gedächtnis gespeicherte Informationen strukturiert und in bestehende Wissensstrukturen integriert. Informationen werden in existierende mentale Modelle eingebunden. Solche Modelle können entweder die Form von Episoden (raum-zeitliche Ereignisse) oder Bedeutungen (Begriffe und Begriffsbeziehungen) haben. Informationsorganisation ist Grundlage der Informationsverwendung, die von Informationsmerkmalen beeinflusst wird, die Berthel (874) wie folgt angibt:      

Aufgabenrelevanz, d. h. sachliche Zugehörigkeit zur betrachteten Aufgabe, Genauigkeit, d. h. Präzision und Detailliertheit, Aktualität oder Neuigkeitsgrad, Bestätigungsgrad, d. h. Glaubwürdigkeit aufgrund vorhandenen Erfahrungswissens, Wahrscheinlichkeit, d. h. Grad der Sicherheit, wahr zu sein, und Überprüfbarkeit, d. h. Möglichkeit, einen Wahrheitsbeweis zu führen.

Informationsverhalten (INVER)

83

Die Aufgabenrelevanz ist eine notwendige, jedoch keine hinreichende Bedingung für die Verwendung von Information. Für den Fall, dass alle sechs Merkmale die Ausprägung „hoch“ annehmen, ist mit Sicherheit davon auszugehen, dass die Information für die Planung, Durchführung und/oder Kontrolle einer Aufgabe tatsächlich verwendet wird. In Abhängigkeit von der Aufgabe, die von einem Individuum in einer bestimmten Situation abzuarbeiten ist, können unterschiedliche Kombinationen der Ausprägungen der sechs Merkmale zu unterschiedlich hohen Verwendungsgraden der Information führen. Nachdem Informationsverwendung in einer konkreten Handlungssituation stattgefunden hat (z. B. eine Entscheidung gefällt wurde), wird der Erfolg der Handlung vor dem Hintergrund des zugrunde liegenden Informationsverhaltens reflektiert. Dabei gewonnene Einsichten repräsentieren neues Wissen, das ein in zukünftigen Situationen empfundenes Informationsdefizit beeinflusst. Damit schließt sich der in Abbildung INVER-1 dargestellte Kreislauf. Das Modell des intrapersonellen Informationsverhaltens nach Abbildung INVER-1 basiert auf der Handlungstheorie der Wahrnehmung (vgl. Schönpflug/Schönpflug). Diese besagt, dass die Motivation für die Informationssuche und -aufnahme die Gewinnung von Information ist, um den erfolgreichen Vollzug von Handlungen sicherzustellen, die zur Erreichung eines angestrebten Ziels beitragen. Zwei weitere theoretische Ansätze können die Informationssuche und -aufnahme erklären, die Theorie von der Existenz eines eigenen Erkenntnismotivs und die Theorie der optimalen Stimulierung. Die erstgenannte Theorie behauptet, dass die Suche nach und die Aufnahme von Information durch ein eigenständiges Bedürfnis von Neugier und Wissbegier motiviert wird, ohne damit den Vollzug von zielführenden Handlungen sicherzustellen. Nach der zweitgenannten Theorie ist der Mensch als biologisches System auf eine bestimmte Auslastung eingestellt. Wenn die Auslastung unter einen Grenzwert sinkt, dann sinkt auch die Körpererregung. Um diese wieder zu erhöhen, setzt sich der Mensch neuen Situationen aus, die mit einer Informationssuche und -aufnahme und somit einer Erhöhung der Körpererregung einhergehen.

Beispiele für intrapersonelles Informationsverhalten Im Folgenden werden für das intrapersonelle Informationsverhalten Beispiele erläutert, die der strategischen oder administrativen Ebene des IM-Modells zugeordnet sind (vgl. Lerneinheit ERMOD). Die Ausführungen beziehen sich auf die Elemente des intrapersonellen Informationsverhaltens im engeren Sinne (vgl. Abbildung INVER-1).

Outsourcing Eine Entscheidung beim Outsourcing ist, ob IT-Funktionen an einen externen Dienstleister ausgelagert werden sollen, und wenn ja, an welchen Anbieter. Einen wirksamen Beitrag zur Beantwortung dieser Frage leistet die Transaktionskostentheorie. Diese Theorie betrachtet die Unternehmung als alternative Allokationsform zum Markt. Auf der Basis einer vergleichenden Analyse zwischen innerbetrieblicher Organisation (Hierarchie) und Fremdbezug (Markt) wird erklärt, warum bestimmte Transaktionen in bestimmten Koordinationsstrukturen mehr oder weniger effizient abgewickelt werden können. Den Maßstab für die Vorteilhaftigkeit einer bestimmten Koordinationsstruktur für eine Transaktion bildet ein Kostenvergleich, der die Produktions- und Transaktionskosten berücksichtigt (vgl. Lerneinheit

84

Grundlagen des Informationsmanagements

OUTSO). In Abhängigkeit von den Phasen der Abwicklung einer Transaktion werden fünf Kostenarten unterschieden, und zwar:     

Kosten für Anbahnung, d. h. Suche nach potenziellen Dienstleistern und Feststellung ihrer Konditionen, Kosten für Vereinbarung, d. h. Verhandlung und Vertragsformulierung, Kosten für Abwicklung, d. h. Steuerung der Leistungserstellung, Kosten für Kontrolle, d. h. Überwachung vereinbarter Qualitäten, Mengen, Termine, Preise, Geheimhaltung und Kosten für Anpassung, d. h. Durchsetzung von Termin-, Mengen-, Qualitäts-, Preis- und Geheimhaltungsänderungen aufgrund veränderter Bedingungen während der Vertragslaufzeit.

Die Anwendung der Transaktionskostentheorie zur Beantwortung der gestellten Frage setzt voraus, dass Entscheidungsträger Recherchen und Berechnungen über die zu erwartenden Transaktionskosten anstellen, also nach einer großen Informationsmenge suchen und diese aufnehmen. Eine solche Annahme ist jedoch bei Berücksichtigung des Informationsverhaltens, insbesondere des Principle of Least Effort, nicht realistisch.

Serviceebenen-Vereinbarungen Serviceebenen-Vereinbarungen sind Vertragsvereinbarungen zwischen Dienstleistungsnehmer und -geber, in denen die Parameter der Dienstleistung und deren Qualitätsniveau festgelegt sind, einschließlich aller Nebenabreden (vgl. Lerneinheit SEVER). Ein von Heinrich/ Riedl entwickeltes Modell zur Entwicklung von SLAs unterscheidet fünf Phasen, darunter die Implementierungsphase. Ziel dieser Phase ist es, die Serviceebenen der SLAs, die für ihre Messung erforderlichen Messgrößen und die zur Messung geeigneten Messmethoden und Werkzeuge festzulegen sowie die zu ihrer Einführung und Nutzung erforderlichen Serviceebenen-Managementprozesse zu definieren. Bei der Auswahl der Werkzeuge zur Überwachung von Kennzahlen (z. B. Systemverfügbarkeit) ist darauf zu achten, dass die von den Werkzeugen erstellten Berichte den Anforderungen der menschlichen Kognition entsprechen. Beispielsweise haben Werkzeuge, die visualisierte Berichte über Kennzahlen erstellen können (vgl. Lerneinheit KENNZ), den Vorteil, dass sie die Wahrnehmung, Aufmerksamkeit sowie das Gedächtnis der Verwender dieser Berichte günstig beeinflussen, was sich positiv auf die Beziehung zwischen Dienstleistungsnehmer und -geber auswirken kann.

Wissensmanagement Ein Baustein des Wissensmanagements ist Wissensverteilung, die nach zwei Prinzipien erfolgen kann, dem Pull-Prinzip oder dem Push-Prinzip (vgl. Lerneinheit WIMAN). Bei der Wissensverteilung sollte besonders darauf geachtet werden, dass die angebotenen Informationen aufgabenrelevant sind, weil ein hoher Grad an Aufgabenrelevanz mit einer stark ausgeprägten Informationsverwendung einhergeht, und umgekehrt. Weitere Merkmale der Information wie Genauigkeit, Aktualität, Bestätigungsgrad, Wahrscheinlichkeit und Überprüfbarkeit beeinflussen das Ausmaß der Informationsverwendung ebenfalls; sie sind daher auch bei der Wissensverteilung zu berücksichtigen.

Informationsverhalten (INVER)

85

Interpersonelles Informationsverhalten Zwischenmenschliche Kommunikation kann ohne Hilfsmittel stattfinden, wenn sich Sender und Empfänger am gleichen Ort befinden und von Angesicht zu Angesicht kommunizieren. Technische Hilfsmittel als Kommunikationskanal zwischen Menschen haben die Funktion, Raum und/oder Zeit zu überbrücken. Kommunikation erfolgt nicht zwecklos, sondern mit der Absicht, beim Empfänger einer Nachricht oder Botschaft Information zu erzeugen, das zur Durchführung oder Unterlassung von Handlungen führt. Kommunikation ist daher Mittel zum Zweck der Information. Kommunikation ist ein sozialer Prozess, der sowohl Informationsfähigkeit und -absicht des Senders als auch Interpretationsfähigkeit und -absicht des Empfängers voraussetzt. Das in Abb. INVER-2 dargestellte Kommunikationsmodell nach Grimm zeigt die Beziehung zwischen Sender und Empfänger. Der Sender übermittelt über einen Kanal eine Botschaft an den Empfänger, wobei im Modell vier Eigenschaften von Medien der Kommunikation unterschieden werden, technisch/materiell, symbolisch, organisatorisch und inhaltlich.

Empfänger

Sender

Botschaft

technisch / materiell: Luft Wärme/Licht Druck Magnetismus Strom

symbolisch: Zeichensystem Gestik, Berührung Gesprochene Sprache Schriftsprache Standbild Bewegtbild Ton

Medium

Kanal

organisatorisch: Zeitung Radio/TV-Sendung Film Musik Web-Portal Vortrag

inhaltlich: Befehl Versprechen Ankündigung Nachricht Unterhaltung Kommentar

Abb. INVER-2: Kommunikationsmodell (Quelle: nach Grimm, 96)

Die Nützlichkeit dieses Kommunikationsmodells für das Informationsmanagement besteht darin, Kombinationsmöglichkeiten der Ausprägungen der vier Eigenschaften transparent zu machen. Jede Kombinationsmöglichkeit kann die durch eine Botschaft an den Empfänger generierte Information beeinflussen, so dass ein Sender die unterschiedlichen Wirkungen einer Botschaft in Abhängigkeit verschiedener Kombinationsmöglichkeiten zu antizipieren versucht (Wirksamkeit). Die Kombinationsmöglichkeiten geben auch Aufschluss über die Kosten des Kommunikationsprozesses, dem wesentlichen Faktor für die Bestimmung seiner Wirtschaftlichkeit. Eine Form des interpersonellen Informationsverhaltens ist das Gatekeeping, ein Begriff, der vom Sozialpsychologen Kurt Lewin geprägt wurde und später als Grundlage der Network Gatekeeping Theory diente. Gatekeeping bezeichnet einen Prozess, der das Ziel hat, einen Informationsfluss zu kontrollieren, um sich persönliche Vorteile – in der Regel auf Kosten

86

Grundlagen des Informationsmanagements

anderer – zu verschaffen. Nach Barzilai-Nahon gibt es zahlreiche Gatekeeping-Aktivitäten, einige davon sind Manipulation, Vorenthaltung, Umformung, Missachtung und Veröffentlichung von Information.

Beispiele für interpersonelles Informationsverhalten Im Folgenden werden für das interpersonelle Informationsverhalten Beispiele erläutert, die der strategischen oder administrativen Ebene des IM-Modells zugeordnet sind (vgl. Lerneinheit ERMOD). Die Ausführungen beziehen sich auf die Gatekeeping-Aktivitäten Manipulation, Vorenthaltung, Umformung, Missachtung und Veröffentlichung von Information.

Outsourcing Lagert ein Unternehmen IT-Funktionen aus, besteht eine Situation mit asymmetrischer Informationsverteilung, bei der einer der Vertragspartner, meist der Dienstleister, besser informiert ist als der andere, meist das auslagernde Unternehmen. Eine Ursache für das Entstehen von Informationsasymmetrien ist Verhaltensunsicherheit. Jeder Vertragspartner kennt seine eigenen Verhaltensmerkmale besser als die der Vertragspartner, woraus für ihn ein Informationsvorsprung resultiert. Ein Dienstleister wird, sofern andere Anbieter am Markt ihm überlegen sind, potenziellen Kunden manipulierte Daten zur eigenen Kompetenz sowie zu weiteren entscheidungsrelevanten Eigenschaften (z. B. Anstrengungsniveau) vermitteln (z. B. in Beratungsgesprächen). Zudem kann ein Dienstleister dem potenziellen Vertragspartner für einen Vertragsabschluss relevante Daten vorenthalten (z. B. fehlendes Wissen, Zahlungsschwierigkeiten) und damit Manipulation und Vorenthaltung von Information bewirken. Auslagernde Unternehmen können dem durch geeignetes Vertragsdesign entgegenwirken, indem beispielsweise Vertragsstrafen bei verminderter Leistungserfüllung definiert sowie Anreize für den Dienstleister festgelegt werden, die eine hohe Dienstleistungsqualität sichern helfen (vgl. Lerneinheit VERMA).

Projektmanagement Kommunikationsprozesse können sich sowohl auf die Interaktion zwischen Individuen (z. B. IT-Manager, Benutzer oder Helpdesk-Mitarbeiter) als auch Organisationseinheiten (z. B. ITAbteilung und Fachabteilung, IT-Abteilung und Outsourcing-Dienstleister) beziehen. Die Berücksichtigung von Gatekeeping-Aktivitäten bei der Planung, Steuerung und Kontrolle der Informationsfunktion ist daher unerlässlich. Informationsmanager müssen zu antizipieren versuchen, welche Individuen bzw. Organisationseinheiten aus welchen GatekeepingAktivitäten Vorteile erzielen könnten, die zu Lasten anderer Individuen bzw. Organisationseinheiten gehen. Eine solche Antizipation ist Grundlage für organisatorische Maßnahmen, um die negativen Effekte des Gatekeeping zu vermeiden oder zumindest abzuschwächen. So kann beispielsweise vereinbart werden, dass beim Austausch von E-Mail-Nachrichten zwischen zwei Personen im Rahmen eines IT-Projekts eine dritte Person immer eine Kopie erhalten muss. Damit kann der Vorenthaltung von Information teilweise vorgebeugt werden. Dies kann zur Reduktion von Informationsasymmetrien zwischen Projektmitarbeitern einen wirksamen Beitrag leisten.

Informationsverhalten (INVER)

87

Nutzwertanalyse Ein Arbeitsschritt der Nutzwertanalyse ist das Ermitteln der Zielwerte durch Transformation der Zielerträge der Kriterien auf ein einheitliches Skalenniveau mit Hilfe von Transformationsregeln (vgl. Lerneinheit NUTZW). Beispielsweise spielt das Kriterium „Verfügbarkeit“ bei der Auswahl eines ASP eine Rolle (vgl. Lerneinheit OUTSO), dessen Dimension in Prozenten angegeben wird (z. B. Zielertrag bei ASP1 95 %, bei ASP2 80 %). Eine Transformationsregel könnte besagen, dass 80 % Verfügbarkeit auf einer Ordinalskala von 0 bis 10 drei Punkte, 95 %, Verfügbarkeit neun Punkte zugeordnet werden. Aus der Definition einer solchen Transformationsregel folgt, dass der Zusammenhang zwischen Zielertrag und Zielwert nicht-linear ist. Die Informationsumformung beim Ermitteln der Zielwerte kann von Entscheidungsträgern bei Anwendung der Nutzwertanalyse dazu verwendet werden, aus persönlichem Interesse präferierte Alternativen gegenüber anderen zu bevorzugen. Ein Entscheidungsträger, der aus persönlichem Interesse ASP1 präferiert, würde daher argumentieren, bis zur Verfügbarkeit von 80 % möglichst wenige Punkte, ab einer Verfügbarkeit >80 % möglichst viele Punkte zu vergeben. Bei jenen Kriterien, bei denen für ASP1 niedrigere Zielerträge gemessen wurden als für ASP2, würde der Entscheidungsträger die Informationsumformung so gestalten, dass ASP1 im Vergleich zu ASP2 einen höheren Nutzwert ergibt. Bei diesen Überlegungen ist zu berücksichtigen, dass das Ermitteln der Zielwerte per Definition ein subjektiver Prozess ist, so dass eine gewisse Objektivierung nur durch nachvollziehbare Argumentation möglich ist. Handelt es sich beim auslagernden Unternehmen um ein Unternehmen mit hohem Erfolgspotenzial der Informationsinfrastruktur (z. B. um ein Kreditinstitut), wäre auch ein exponentieller Zusammenhang zwischen Zielertrag und Zielwert zweckmäßig, weil schon die Nicht-Verfügbarkeit von IT-Systemen (z. B. von Geldausgabeautomaten) ein hohes Schadenspotenzial haben kann.

Forschungsbefunde Ein Ansatz zur Erklärung des Informationsverhaltens ist nach Mon das Face Threat, eine Theorie, die vom US-amerikanischen Soziologen Goffman entwickelt wurde. Sie behauptet, dass das Informationsverhalten eines Individuums zum Ziel hat, sein Selbstverständnis sowie seine Reputation positiv zu beeinflussen. Es geht also darum, in Kommunikationsprozessen durch Gatekeeping-Aktivitäten (z. B. Manipulation oder Vorenthaltung von Information) „impression management“ zu betreiben, das von Mon (149) so beschrieben wird: „…strategic maneuvers to obtain, share, or hide information that is either supportive to or destructive of a desired public self-image or ‚face‘.“ Es wird auch behauptet, dass spezifische Formen der Kommunikation, vor allem Erklärungen und Entschuldigungen, als Indikatoren anzusehen sind, die Gefährdungen des Selbstverständnisses sowie der Reputation anzeigen. Einer der weltweit führenden Wissenschaftler auf dem Gebiet des menschlichen Informationsverhaltens ist Tom D. Wilson. Bereits in den frühen 1980er Jahren entwickelte er ein Modell zur Erklärung des menschlichen Informationsbedürfnisses sowie des Verhaltens bei der Informationssuche (Wilson 1981). Später entwickelte er auf Basis dieser Arbeiten das „General Model of Information-Seeking Behavior“, eines der gehaltvollsten Erklärungsmodelle der Informationsverhaltensforschung (Wilson 2005, 34). Dieses Modell integriert meh-

88

Grundlagen des Informationsmanagements

rere, vorwiegend psychologisch-orientierte Theorien wie beispielsweise Belohnungs-, Lern-, Risiko- und Stresstheorien.

Aus der Praxis Kommunikation erfordert die Informationsfähigkeit und -absicht des Senders als auch die Interpretationsfähigkeit und -absicht des Empfängers. Damit der Sender die Erreichung eines intendierten Informationszwecks überprüfen kann, ist eine Antwort durch den Empfänger, eine Rückmeldung, sinnvoll. Eine vom Verfasser dieser Lerneinheit beobachtete Praxis bei der E-Mail-Kommunikation ist, dass Rückmeldungen durch den Empfänger oft ausbleiben. Eine mögliche Erklärung hierfür ist, dass der Empfänger seinen Kommunikationsaufwand reduzieren will und deshalb nicht antwortet. Eine andere Erklärung lautet, dass der Empfänger durch Rückmeldung den Informationsstand des Senders erhöht, was den eigenen Handlungsspielraum in künftigen Interaktionssituationen reduziert. Methodenverweise Erfolgsfaktorenanalyse (Lerneinheit ERFAN); Kennzahlensysteme (Lerneinheit KENNZ); Nutzwertanalyse (Lerneinheit NUTZW); Serviceebenen-Vereinbarungen (Lerneinheit SEVER). Kontrollfragen 1. Welche Elemente enthält das Modell des intrapersonellen Informationsverhaltens? 2. Wie kann das „Principle of Least Effort“ im Kontext des Informationsverhaltens erklärt werden? 3. Warum sollte sich das Informationsmanagement mit dem „Gatekeeping“ befassen? 4. Wie kann das Informationsverhalten durch das „Face Threat“ erklärt werden? 5. Warum können Erkenntnisse zum Informationsverhalten die Erfüllung von IM-Aufgaben unterstützen? Quellen Barzilai-Nahon, K.: Gatekeepers and gatekeeping mechanisms in networks. Unpublished doctoral dissertation, TelAviv University 2004 Berthel, J.: Informationsbedarf. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Stuttgart 1992, 872– 886 Gemünden, H. G.: Informationsverhalten. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Stuttgart 1992, 1010–1029 Grimm, R.: Digitale Kommunikation. München/Wien 2005 Heinrich, L. J. / Heinzl A. / Riedl, R.: Wirtschaftsinformatik: Einführung und Grundlegung. 4. A., Berlin/Heidelberg 2011 Heinrich, L. J. / Riedl, R.: Phasenmodell zur Entwicklung von Serviceebenen-Vereinbarungen. In: HMD – Praxis der Wirtschaftsinformatik 231/2003, 88–96 Mon, L.: Face threat. In: Fisher, K. E. / Erdelez, S. / McKechnie, L. E. F. (Hrsg.): Theories of information behavior. Medford/New Jersey, 2005, 149–152 Schönpflug, W. / Schönpflug, U.: Psychologie. 4. A., Weinheim 1997 Wilson, T. D.: Evolution in information behavior modeling: Wilson’s model. In: Fisher, K. E. / Erdelez, S. / McKechnie, L. E. F. (Hrsg.): Theories of information behavior. Medford/New Jersey, 2005, 31–36 Wilson, T. D.: On user studies and information needs. In: Journal of Documentation 1/1981, 3–15 Vertiefungsliteratur Fisher, K. E. / Erdelez, S. / McKechnie, L. E. F. (Hrsg.): Theories of information behavior. Medford/New Jersey, 2005 McKinney, E. H. / Yoos, C. J.: Information about information: A taxonomy of views. In: MIS Quarterly 2/2010, 329–344 Wilson, T. D.: Models in information behaviour research. In: Journal of Documentation 3/1999, 249–270 Informationsmaterial http://liswiki.org/wiki/Information_behavior_theories

B. STRATEGISCHE AUFGABEN DES INFORMATIONSMANAGEMENTS

strategische Ebene

administrative Ebene

operative Ebene

Grundlagen des Informationsmanagements

Methoden des Informationsmanagements

Aufgaben des Informationsmanagements

Fallstudien Informationsmanagement

90

Strategische Aufgaben des Informationsmanagements

Gegenstand dieses Kapitels sind die strategischen Aufgaben des Informationsmanagements. Dazu gehört in erster Linie die strategische Planung der Informationsinfrastruktur (kurz als strategische IT-Planung bezeichnet), die in die Aufgaben strategische Situationsanalyse, strategische Zielplanung, Strategieentwicklung und strategische Maßnahmenplanung gegliedert ist. Darüber hinaus werden Aufgaben behandelt, die neben ihrem primär strategischen Charakter auch eine administrative, teilweise sogar eine operative Bedeutung haben, ohne ihre strategische Ausrichtung aber unvollkommen sind oder sogar sinnlos wären. Das sind Strukturmanagement, Qualitätsmanagement, Technologiemanagement, Sicherheitsmanagement, Notfallmanagement, Controlling, Revision und Outsourcing. Bei der Entscheidung über die Einordnung der Aufgaben stand ihr strategischer Charakter im Vordergrund, so dass administrative und operative Gesichtspunkte in die strategischen Aufgaben eingefügt behandelt werden bzw. zu ergänzen sind. Situationsanalyse (SITAN) .................................................................................................... 91 Zielplanung (SZIEL)............................................................................................................ 103 Strategieentwicklung (STRAT)............................................................................................ 113 Maßnahmenplanung (SPLAN)............................................................................................. 125 Strukturmanagement (STRUK)............................................................................................ 137 Qualitätsmanagement (QUALM)......................................................................................... 149 Technologiemanagement (TECHM).................................................................................... 161 Sicherheitsmanagement (SICHM) ....................................................................................... 175 Notfallmanagement (NOMAN) ........................................................................................... 187 Controlling (CONTR) .......................................................................................................... 199 Revision (REVIS) ................................................................................................................ 211 Outsourcing (OUTSO) ......................................................................................................... 223

Situationsanalyse (SITAN) Lernziele Sie kennen die Bedeutung der Informationsfunktion für die Erreichung der Unternehmensziele. Sie können davon ausgehend ihre strategische Rolle bestimmen. Sie erkennen, dass zum Ausschöpfen des Leistungspotenzials durch den Aufbau von Erfolgspotenzial innerund außerbetriebliche Rahmenbedingungen bekannt sein müssen. Sie kennen Vorgehensweisen der Analyse der Wettbewerbssituation, der Analyse der Informationsinfrastruktur und der Umweltanalyse sowie andere Vorgehensweisen zum Erkennen strategischer Lücken.

Definitionen und Abkürzungen Analyse (analysis) = Bestimmung und Charakterisierung von Teilen eines Systems (eines Ganzen) sowie der Beziehungen der Teile untereinander und zum Ganzen mit dem Zweck, das Ganze zu erklären. Istzustand (current system) = Gesamtheit der technischen, organisatorischen, personellen, sozialen und rechtlichen Bedingungen und Regelungen eines bestehenden Systems. Portfolio (portfolio) = grafische Darstellung der Zielerträge mehrerer Objekte mit zwei Merkmalen in einem meist in Quadranten eingeteilten Koordinatensystem. Potenzialfaktor (potential factor) = Eigenschaft einer Technologie, die bei deren Nutzung die Ausschöpfung des Nutzenpotenzials unterstützt (z. B. Erhöhung der Produktivität). Profildiagramm (profile diagram) = grafische Darstellung der Zielerträge mehrerer Objekte zu mehreren Zielkriterien. Schwäche (weakness) = negative Abweichung der Eigenschaft eines Systems von einem definierten Standard (z. B. Sollzustand). Synonym: Schwachstelle. Situationsanalyse (situation analysis) = systematische Untersuchung der für ein System zu einem bestimmten Zeitpunkt oder Zeitraum relevanten Bedingungen. Sollzustand (target system) = Gesamtheit der technischen, organisatorischen, personellen, sozialen und rechtlichen Bedingungen und Regelungen eines zu schaffenden Systems. Stärke (strength) = Entsprechung oder positive Abweichung der Eigenschaft eines Systems von einem definierten Standard (z. B. Sollzustand). strategische Schlagkraft (strategic threat) = durch Wirksamkeit und Wirtschaftlichkeit bestimmte Spitzenkennzahl. Unternehmenstypologie (enterprise typology) = Systematik zum Einschätzen der strategischen Rolle der Informationsfunktion in Abhängigkeit vom Leistungspotenzial. Wettbewerbsfaktor (competitive factor) = Wettbewerb kennzeichnende Eigenschaft des Marktes, in dem ein Unternehmen tätig ist (z. B. Lieferzeit, Qualität, Preis). Wettbewerbsvorteil (competitive advantage) = Eigenschaft des Unternehmen, die es von seinen Mitbewerbern unterscheidet und im Wesentlichen durch den Wert bestimmt ist, den es seinen Kunden durch Kostensenkung und/oder Leistungssteigerung bietet.

92

Strategische Aufgaben des Informationsmanagements

Zweck der strategischen Situationsanalyse Erste Aufgabe der strategischen IT-Planung ist die Durchführung einer Situationsanalyse, um die strategische Rolle der Informationsfunktion zu bestimmen und die inner- und außerbetrieblichen Bedingungen für die Umsetzung ihres Leistungspotenzials in Erfolgspotenzial zu erkunden. (Zur Erklärung der beiden Potenzialbegriffe vgl. Lerneinheit ERMOD.) Als „strategisch“ wird dabei die unternehmensweite, grundsätzliche und langfristig wirksame, den Unternehmenserfolg maßgeblich beeinflussende Handlung oder ein Objekt mit diesen Eigenschaften (z. B. ein Informationssystem), ein Ereignis oder ein Zustand verstanden. Mit der Durchführung einer Situationsanalyse wird die Voraussetzung für die strategische Zielplanung geschaffen, der zweiten Aufgabe der strategischen IT-Planung (vgl. Lerneinheit SZIEL). Maßnahmen zur Veränderung der IT mit dem Ziel einer besseren Ausschöpfung des Leistungspotenzials können nur geplant und erfolgreich realisiert werden, wenn ihr Istzustand bekannt ist, so wie ein Kompass nur dann sinnvoll verwendbar ist, wenn der Benutzer seinen Standort kennt. Die strategische Rolle der Informationsfunktion macht Aussagen darüber, welche Bedeutung die Erfüllung von Informations- und Kommunikationsaufgaben für die Erreichung der strategischen Unternehmensziele hat; sie wird aus ihrem Leistungspotenzial abgeleitet. Jedes Unternehmen hat eine spezifische Informationsfunktion, die sich von der Informationsfunktion anderer Unternehmen sowohl durch ihre Mächtigkeit (d. h. durch den Anteil der Informations- und Kommunikationsaufgaben an den Aufgaben des Unternehmens), als auch durch die Art der Informations- und Kommunikationsaufgaben (d. h. durch ihre Komplexität und Kompliziertheit) unterscheidet. Unternehmen der gleichen Branche haben eine ähnliche Informationsfunktion, wenn sie ein ähnliches Leistungsprogramm (Produkte und Dienstleistungen) haben. So haben Universalbanken, die überregional tätig sind, etwa die gleiche Informationsfunktion, da sie ein ähnliches Leistungsprogramm haben; diese ist von der Informationsfunktion regional tätiger Verkehrsbetriebe ebenso grundlegend verschieden wie von weltweit agierenden Universalbanken.

Strategische Rolle der Informationsfunktion Das Bestimmen der strategischen Rolle der Informationsfunktion erfolgt zunächst durch das Einschätzen ihres Leistungspotenzials. Wird zwischen den Potenzialattributen gegenwärtig und zukünftig (geplant) mit den Ausprägungen geringe und große Bedeutung unterschieden, ergibt sich die in Abbildung SITAN-1 gezeigte Unternehmenstypologie. Da das zukünftige Leistungspotenzial Ergebnis strategischer Entscheidungen ist, wird über den Unternehmenstyp situativ für jedes betrachtete Unternehmen entschieden; die in Klammen angegebenen Beispiele dienen nur dem besseren Verständnis der Typologie. 

Unternehmenstyp I Unterstützung: In Unternehmen dieses Typs hat die Informationsfunktion gegenwärtig und in Zukunft nur eine geringe Bedeutung für die Erreichung der Unternehmensziele. Der Stellenwert des Informationsmanagements ist folglich gering. Sein Aufgabensystem umfasst im Grenzfall nur die operativen Aufgaben der Nutzung

Situationsanalyse (SITAN)





der vorhandenen Infrastruktur (z. B. ein mittelständisches, auf einem regionalen Markt tätiges Kies- und Schotterwerk). Unternehmenstyp II Fabrik: In Unternehmen dieses Typs hat die Informationsfunktion zwar geTyp III Typ IV genwärtig eine große Bedeutung Durchbruch Waffe für die Erreichung der Unternehmensziele, diese nimmt aber in Zukunft ab. Das Informationsmanagement konzentriert sich auf Typ I Typ II administrative Aufgaben, das heißt auf die Pflege und WeiterUnterstützung Fabrik entwicklung der vorhandenen Infrastruktur sowie auf die operativen Aufgaben ihrer Nutzung groß gering (z. B. ein auf einem nationalen gegenwärtiges Leistungspotenzial Markt tätiges Unternehmen der der Informationsfunktion Bauindustrie, dessen Übernahme Abb. SITAN-1: Unternehmenstypologie durch ein global agierendes Un(Quelle: nach MacFarlan/McKenney) ternehmen geplant ist). Unternehmenstyp III Durchbruch: In Unternehmen dieses Typs hat die Informationsfunktion zwar gegenwärtig nur eine geringe Bedeutung für die Erreichung der Unternehmensziele, diese nimmt aber in Zukunft stark zu. Daraus resultiert ein zunehmender Stellenwert des Informationsmanagements, das sich daher vornehmlich mit der Schaffung, Nutzung und Weiterentwicklung einer leistungsfähigen Infrastruktur befasst, also mit strategischen und administrativen Aufgaben (z. B. ein Auktionshaus, das sein Geschäft in Zukunft vornehmlich über das Internet abwickeln, also Online-Auktionen durchführen will). Unternehmenstyp IV Waffe: In Unternehmen dieses Typs hat die Informationsfunktion gegenwärtig und in Zukunft eine große Bedeutung für die Erreichung der Unternehmensziele. Der Stellenwert des Informationsmanagements ist erheblich. Sowohl gegenwärtig als auch in Zukunft ist die Erreichung der Unternehmensziele ohne eine sehr gut entwickelte Infrastruktur nicht möglich. Das Informationsmanagement umfasst strategische, administrative und operative Aufgaben (z. B. ein Unternehmen, das Kapitalmarktprodukte entwickelt und weltweit vertreibt). zukünftiges Leistungspotenzial der Informationsfunktion gering groß



93

Von dieser Einschätzung des Leistungspotenzials und der daraus folgenden Notwendigkeit des Aufbaus eines entsprechenden Erfolgspotenzials ausgehend, werden grundlegende Entscheidungen bezüglich der Gestaltung des Informationsmanagements gefällt (z. B. Interaktion zwischen Unternehmensstrategie und IT-Strategie, Stellenwert der strategischen ITPlanung, Art und Umfang der IM-Aufgaben, Institutionalisierung und organisatorische Gliederung des IT-Bereichs, Anforderungsprofile für Führungskräfte, personelle Besetzung der Leitungsfunktionen). Unternehmen vom Typ IV haben beispielsweise eine intensive Interaktion zwischen Unternehmensstrategie und IT-Strategie, einen großen Aufgabenumfang und hohe Anforderungen an das IT-Personal; für Unternehmen vom Typ I gilt das Gegenteil.

94

Strategische Aufgaben des Informationsmanagements

Strategische Schlagkraft Idealtypisch werden zwei Situationen unterschieden, die das Verhältnis zwischen Informationsfunktion und Informationsinfrastruktur beschreiben. Die erste ist dadurch gekennzeichnet, dass sich Informationsfunktion und Infrastruktur im Gleichgewicht befinden; die zweite ist durch Ungleichgewicht gekennzeichnet. Wirksamkeit und Wirtschaftlichkeit werden für beide Situationen als Parameter verwendet, mit ihnen werden zwei Klassen von möglichen Positionierungen der IT beschrieben. Informationsfunktion und Informationsinfrastruktur befinden sich auf höchstem Niveau im Gleichgewicht, wenn die Infrastruktur mit ihrem Erfolgspotenzial das Leistungspotenzial der Informationsfunktion voll ausschöpft (maximale Wirksamkeit) und wenn diese Wirksamkeit mit minimalen Kosten erreicht wird. Liegt die eine und/oder andere Bedingung nicht vor, befinden sich Informationsfunktion und Informationsinfrastruktur im Ungleichgewicht. Dieser Zustand wird deshalb als strategisch bezeichnet, weil er langfristig wirksam ist und den Unternehmenserfolg maßgeblich beeinflusst. Abbildung SITAN-2 zeigt, dass bei Verwendung dieser Definition neben dem strategischen Gleichgewicht drei Klassen von strategischem Ungleichgewicht zu unterscheiden sind, die grundsätzlich unterschiedliche Handlungen erfordern, um Gleichgewicht (wieder) herzustellen: Strategische Vergeudung, Überdehnung und Verschwendung.





Die Informationsinfrastruktur ist durch strategische Verschwendung gekennzeichnet, wenn Strategische Strategisches Wirksamkeit gegeben ist, WirtGleichgewicht Vergeudung schaftlichkeit aber nicht erreicht wird. Zwar wird das Leistungspotenzial im Wesentlichen ausgeschöpft, dies erfolgt aber nicht so wirtschaftlich wie möglich. Strategische Strategische (You don´t need a Porsche to Überdehnung Verschwendung drive to the supermarket!) Die Informationsinfrastruktur ist durch strategische Vergeudung hoch gering gekennzeichnet, wenn WirtWirksamkeit der schaftlichkeit gegeben ist, WirkInformationsinfrastruktur samkeit aber nicht erreicht wird. Abb. SITAN-2: Informationsfunktion/Informationsinfrastruktur Das Leistungspotenzial wird alim strategischen Gleichgewicht/Ungleichgewicht so nicht ausgeschöpft, mögliche Erfolgsrealisierungen werden nicht genutzt. Soweit das Leistungspotenzial ausgeschöpft wird, erfolgt dies allerdings wirtschaftlich. (Hier passt folgende Metapher: Für einen Smart sollte man sich nicht entscheiden, wenn man Weltreisen unternehmen will.) Die Informationsinfrastruktur ist durch strategische Überdehnung gekennzeichnet, wenn weder Wirksamkeit noch Wirtschaftlichkeit gegeben sind. Weder wird das Leistungspotenzial ausgeschöpft, noch erfolgt die unvollkommene Ausschöpfung wirtschaftlich. Wirtschaftlichkeit der Informationsinfrastruktur gering hoch



Situationsanalyse (SITAN)

95

Im Fall der strategischen Überdehnung befindet sich das Informationsmanagement in einem Dilemma, da weder das vorhandene Leistungspotenzial voll ausgeschöpft wird (es wird also vergeudet), noch die Ausschöpfung, soweit sie erfolgt, wirtschaftlich ist (es wird also zudem verschwendet). Die volle Entfaltung des Leistungspotenzials erfordert es, so viel Wirksamkeit wie nötig und so viel Wirtschaftlichkeit wie möglich zu realisieren. Wie viel nötig bzw. wie viel möglich ist, hängt von unternehmensinternen Einflussgrößen (insbesondere von der Innovationsfähigkeit und der Höhe des IT-Budgets) und von unternehmensexternen Einflussgrößen ab (insbesondere von den verfügbaren Technologien und vom Verhalten der Mitbewerber beim Technologieeinsatz). Das Ausmaß an Wirksamkeit und Wirtschaftlichkeit der Informationsinfrastruktur (geplanter Sollwert oder erreichter Istwert) ist ihre strategische Schlagkraft. Ein Unternehmen kann Wettbewerbsvorteile mit Hilfe der IT nur dann schaffen und erhalten, wenn ihre strategische Schlagkraft größer ist als die der Mitbewerber; ist sie kleiner, besteht eine strategische Lücke, die nicht nur das Schaffen neuer Wettbewerbsvorteile erschwert oder sogar unmöglich macht, sondern auch das Erhalten bestehender Wettbewerbsvorteile gefährden kann. Langfristig gesehen sind überdurchschnittliche Erfolge eines Unternehmens mit Hilfe der IT nur möglich, wenn bestehende Wettbewerbsvorteile erhalten und neue geschaffen werden. Die strategische Schlagkraft muss daher auf Erhaltung und Schaffung von Wettbewerbsvorteilen ausgerichtet sein.

Vorgehensweisen der Situationsanalyse Schwerpunkte der Situationsanalyse sind die Analyse der Wettbewerbssituation, die Analyse der Informationsinfrastruktur und die Umweltanalyse. Im Folgenden wird der Zweck dieser drei Analysen genannt und erklärt, wie bei ihrer Durchführung vorgegangen wird.

Analyse der Wettbewerbssituation Mit der Analyse der Wettbewerbssituation, kurz Wettbewerbsanalyse, wird ermittelt, welche Wettbewerbsfaktoren kritisch sind und welche durch das Leistungspotenzial bzw. ein zu schaffendes Erfolgspotenzial positiv beeinflusst werden können. Welche Wettbewerbsfaktoren relevant und welche davon kritisch sind, ist von mehreren Faktoren abhängig, vor allem von der Art des Unternehmens (z. B. Branche und Unternehmensgröße, Leistungsprogramm und Logistik) und von der spezifischen Marktsituation, in der das Unternehmen agiert (z. B. Marktanteil, Anzahl der Mitbewerber und deren Marktauftritt). Kritisch sind die Wettbewerbsfaktoren, welche den Unternehmenserfolg entscheidend beeinflussen, was letztlich mit quantitativen finanziellen Metriken (z. B. als Rentabilität) zu messen ist. Diese Wettbewerbsfaktoren werden deshalb auch als strategisch bezeichnet bzw. wird nicht von kritischen oder strategischen Wettbewerbsfaktoren, sondern von strategischen Erfolgsfaktoren gesprochen. Welche Wettbewerbsfaktoren relevant und welche davon kritisch sind, ändert sich im Zeitverlauf, muss also systematisch aktualisiert werden (z. B. im Rahmen der unternehmensweiten Jahresplanung). Jedenfalls handelt es sich zumeist um Faktoren, die Zeit, Qualität, Kosten und Agilität (Flexibilität, Anpassbarkeit) bestimmen. Eine Vorgehensweise zur Ermittlung und Beurteilung der Wettbewerbsfaktoren in Bezug auf ihre Kritikalität wird mit den nachfolgend genannten Arbeitsschritten erläutert. Bei allen Arbeitsschritten stehen die Wett-

96

Strategische Aufgaben des Informationsmanagements

bewerbsfaktoren im Vordergrund des Interesses, die durch das Leistungspotenzial der Informationsfunktion positiv beeinflusst werden können, weil es nur dann sinnvoll ist, Erfolgspotenzial durch IT-Investitionen auf- bzw. auszubauen. 1.

2.

3.

4.

Bestimmen der Wettbewerbsfaktoren. Beispiele für Wettbewerbsfaktoren sind: Kosten der Leistungserstellung und -verwertung und damit auch Angebotspreise, Servicezeit und Servicegrad, Lieferbereitschaft und Lieferbereitschaftsgrad, Produkt- und Prozessqualität, Produktentwicklungs- und Auftragsabwicklungszeit, organisatorische und technologische Flexibilität. Erheben des Istzustands. Zu den Wettbewerbsfaktoren werden die aktuellen Werte ermittelt (z. B. die Auftragsabwicklungszeit gemessen in Tagen) und im Vergleich zu den wichtigsten Mitbewerbern beurteilt (z. B. methodisch unterstützt durch Competitive Benchmarking, vgl. Lerneinheit MEGPM). Analysieren des Istzustands. Es werden die Wettbewerbsfaktoren, die kritisch sind (z. B. eine vergleichsweise lange Auftragsabwicklungszeit), und die Möglichkeiten zur Beeinflussung ihrer aktuellen Werte durch IT-Investitionen (z. B. in verbesserte Systeme der Produktionsplanung und -steuerung) identifiziert. Definieren des Sollzustands. Die Sollgrößen für die Werte der kritischen Wettbewerbsfaktoren werden festgelegt (z. B. die vergleichsweise lange Produktentwicklungszeit).

Die Vorgehensweise bei der Abarbeitung der Arbeitsschritte ist nicht IT-spezifisch und in der Marketing-Fachliteratur umfassend beschrieben. Zum Bestimmen der Wettbewerbsfaktoren kann auch eine IT-spezifische Portfolioanalyse verwendet werden (vgl. Lerneinheit PORTA in der 4. bis 8. Auflage dieses Lehr- und Handbuchs).

Analyse der Informationsinfrastruktur Zweck der Infrastrukturanalyse ist es, ihr gegenwärtiges Erfolgspotenzial zu messen, um ihre Stärken und Schwächen im Hinblick auf die Erreichung der strategischen Unternehmensziele und damit auch ihre Fähigkeit festzustellen, das Leistungspotenzial der Informationsfunktion auszuschöpfen (Analyse des Istzustands). Der so ermittelte Istzustand Erfolgspotenzial wird mit einem geplanten Sollzustand Erfolgspotenzial abgeglichen. Abweichungen weisen entweder auf eine Überdimensionierung der IT hin oder zeigen einen Bedarf zur Schaffung von zusätzlichem Erfolgspotenzial. In dem einen wie dem anderen Fall befinden sich die Informationsfunktion mit ihrem Leistungspotenzial und die Informationsinfrastruktur mit ihrem Erfolgspotenzial nicht im Gleichgewicht. Für die Beschreibung von Sollzustand, Istzustand und Abweichungen geeignete Metriken zu finden, ist problematisch, die meisten der sogenannten IT-Kennzahlen (vgl. Lerneinheit KENNZ) sind dafür nicht geeignet. Sehr gut geeignet ist die Metrik Gesamterfolg der Erfolgsfaktorenanalyse (vgl. Lerneinheit ERFAN). Bei der Analyse des Istzustands wird entweder primär nach Infrastrukturkomponenten (Komponentenanalyse) oder nach Eigenschaften von Infrastrukturkomponenten mit oder ohne Zielcharakter (Eigenschaftsanalyse) vorgegangen. „Primär“ meint hier die jeweils im Vordergrund stehende Dimension des Untersuchungsgegenstands, also Komponenten oder Eigenschaften. Wird der Untersuchungsgegenstand zunächst in Komponenten zerlegt, wird anschließend jede Komponente nach Eigenschaften analysiert. Wird der Untersuchungsgegenstand zunächst nach Eigenschaften kategorisiert, werden anschließend je Eigenschaft alle

Situationsanalyse (SITAN)

97

Komponenten analysiert. Theoretisch sollten die Ergebnisse beider Vorgehensweisen nicht wesentlich voneinander abweichen; buchhalterische Genauigkeit ist bei strategischen Analysen nicht gefordert. Erfahrungsgemäß weichen sie deshalb deutlich voneinander ab, weil die primäre Orientierung an den Komponenten mehr Transparenz sichert. Es ist weniger wahrscheinlich, eine Komponente nicht zu beachten, als eine Eigenschaft nicht zu untersuchen. Komponenten sind den Beteiligten im Allgemeinen gut bekannt.

Komponentenanalyse Für die Zerlegung der Informationsinfrastruktur in Komponenten kann die Gliederung verwendet werden, die von Heinrich/Heinzl/Riedl (283 ff.) entwickelt wurde (vgl. deren Nennung in Lerneinheit ERMOD, zur Erklärung der Komponenten vgl. die angegebene Quelle). Zweckmäßig ist die hierarchische Zerlegung in Komponenten, der Komponenten in Subkomponenten, der Subkomponenten in Teile davon usw. In der Regel reichen zwei bis drei Gliederungsebenen aus. Beispielsweise wird auf der ersten Ebene die personelle Infrastruktur in IT-Personal und IT-Unterstützer (vgl. Lerneinheit PERSM), die organisatorische Infrastruktur in Aufbau- und Ablauforganisation zerlegt, und die Aufbauorganisation des ITBereichs auf einer dritten Ebene in seine Struktureinheiten (vgl. Lerneinheit STRUK). Zur Erleichterung der Komponentenanalyse werden Beschreibungsmittel (wie Matrizen, Funktionsdiagramme, Zerlegungsdiagramme, Soziogramme) verwendet, mit denen der Istzustand transparent dargestellt wird. Beispielsweise werden mit Matrizen die Zusammenhänge zwischen den Elementen verschiedener Systeme beschrieben (z. B. die Beziehungen zwischen Funktionalität der Software und kritischen Wettbewerbsfaktoren); sie können mit Matrizenoperationen analysiert werden.

Eigenschaftsanalyse Die Vorgehensweise der Eigenschaftsanalyse entspricht methodisch der Erfolgsfaktorenanalyse (vgl. Lerneinheit ERFAN), die quantitative Messgrößen verwendet (z. B. Erfolg und Leistungsdifferenz) und die über Darstellungsmittel verfügt (insbesondere Portfolio und Profildiagramm), mit denen die Identifizierung von Stärken und Schwächen und deren transparente Darstellung gut unterstützt wird. Die strategisch relevanten Eigenschaften der Informationsinfrastruktur (z. B. Auslagerung, Integration, Verteilung), insbesondere die Eigenschaften mit Zielcharakter (z. B. Sicherheit, Wirtschaftlichkeit, Anpassbarkeit), werden als Erfolgsfaktoren abgebildet. Eigenschaften sind entweder definiert und damit unmittelbar erkennbar (z. B. wenn es sich um Eigenschaften mit Zielcharakter handelt, vgl. Lerneinheiten ERMOD und SZIEL) oder nicht definiert und auch nicht unmittelbar erkennbar, also emergent (von lat. emergere = auftauchen, hervorkommen, sich zeigen). Für diese Feststellung entscheidend ist, dass emergente Eigenschaften nicht nur durch Eigenschaften der Komponentenelemente bestimmt werden, sondern auch durch Eigenschaften der Beziehungen zwischen ihnen, also durch die Systemstruktur. Emergente Eigenschaften lassen sich daher nicht – jedenfalls nicht ohne weiteres – auf Eigenschaften einzelner Elemente zurückführen. Eine bei der Analyseplanung unbekannte Eigenschaft kann bei der Durchführung der Analyse an einer der Komponenten auftauchen, und es ist dann relativ einfach, bereits analysierte Komponenten auf diese Eigenschaft hin nachträglich zu untersuchen.

98

Strategische Aufgaben des Informationsmanagements

Diagnosemodell Grundlage beider Vorgehensweisen ist ein Modell, das die Komponenten und ihre Eigenschaften einschließlich der für die Messung der Eigenschaften relevanten Methoden abbildet. Man kann sich dieses Modell in Form einer Matrix vorstellen, in deren Zeilen die Komponenten und in deren Spalten die Eigenschaften abgebildet sind, der Zielertragsmatrix der Nutzwertanalyse entsprechend (vgl. Lerneinheit NUTZW). Bei der Komponentenanalyse wird die Matrix Zeile für Zeile, bei der Eigenschaftsanalyse Spalte für Spalte abgearbeitet. Die Felder der Matrix repräsentieren die Erträge je Komponente und Eigenschaft. Eine spezifische Vorgehensweise der Situationsanalyse mit dem Schwerpunkt Analyse der Informationsinfrastruktur ist die so genannte IT-Diagnose. (Zur Vorgehensweise vgl. Lerneinheit FSSIT in der 9. Auflage oder auf der Webseite dieses Lehr- und Handbuchs.) Eine IT-Diagnose durchzuführen, ist anspruchsvoll und aufwendig und aus verschiedenen Gründen (z. B. Zeitbedarf, Kosten, Personalbedarf nach Qualifikation und Ausmaß) nicht immer möglich. Heinrich/Pomberger (1995) berichten über Befunde zum Diagnoseaufwand. Der Aufwand wird reduziert, indem für die Komponentenanalyse und/oder die Eigenschaftsanalyse eine geringere Anzahl Metriken als im Idealfall verwendet wird, dass bei der Komponentenanalyse nur Stichproben (z. B. bestimmte Anwendungssysteme oder Teile von Anwendungssystemen – wie Software oder Datenbasen – oder von Benutzerarbeitsplätzen) bzw. dass bei der Eigenschaftsanalyse nur Eigenschaften mit strategischem Zielcharakter untersucht werden (z. B. Wirksamkeit, Wirtschaftlichkeit und Sicherheit). Entscheidungen dazu werden am Untersuchungsziel ausgerichtet und orientieren sich insbesondere daran, für welche Entscheidungen die Befunde Information liefern sollen (z. B. zum Erkennen von Sanierungsbedarf oder zur Beurteilung des Wertbeitrags der IT).

Umweltanalyse Mit der Umweltanalyse sollen die strategisch bedeutsamen Eigenschaften des IT-Marktes ermittelt werden; sie ist primär Technologieanalyse (vgl. Lerneinheit TECHM). Dabei steht das Erkennen von Entwicklungstrends bei Informations- und Kommunikationstechnologien (Hardware und Software, z. B. neue Internettechnologien wie Web 2.0), bei Methoden und Arbeitstechniken (z. B. Modellierungssprachen) und bei Dienstleistungen (z. B. ASP = Application Service Providing, Cloud Computing) im Vordergrund. Beobachtungsobjekte sind einschlägige Messen (insbesondere Cebit Hannover) und Zeitungen (z. B. Computer Zeitung, Computerwoche), Fachliteratur (Fachbücher und Fachzeitschriften), Internet-Recherchen, Präsentationen der Technologieanbieter sowie einschlägige, anbieterunabhängige Seminare. Die Vorgehensweise bei der Technologieanalyse ist nicht dadurch gekennzeichnet, dass für bekannte Probleme nach Lösungsmöglichkeiten mit Hilfe von Technologien gesucht wird. Vielmehr soll erkannt werden, welches Erfolgspotenzial neue Technologien ermöglichen, so dass neue Technologieanwendungen zur besseren Ausschöpfung des Leistungspotenzials realisiert werden. Nicht Rationalisierung steht als Ziel der Technologieanalyse im Vordergrund, sondern Innovation, also nicht nur mehr Wirtschaftlichkeit, sondern mehr Wirtschaftlichkeit und mehr Wirksamkeit, wobei mehr Wirksamkeit häufig Voraussetzung für mehr Wirtschaftlichkeit ist. Technologieanalyse meint also das Erkennen von Innovationspotenzial in Form von Technologieeinsatzpotenzial, anders ausgedrückt von Veränderungspotenzial

Situationsanalyse (SITAN)

99

von Technologien und damit von Erfolgspotenzial. Deshalb ist das Identifizieren der Potenzialfaktoren wichtigste Aufgabe der Technologieanalyse. Hammer/Champy drücken dies sinngemäß so aus: Die wahre Kraft der Technologie liegt nicht in der Verbesserung alter Prozesse, sondern darin, dass sie es Unternehmen möglich macht, bestehende Regeln zu brechen und neue Arbeitsweisen aufzubauen. Potenzialfaktoren sind beispielsweise Automatisierung, Informationszuwachs, Reduzierung örtlicher und zeitlicher Schranken, Parallelisierung und Integration. Gegenstand der Umweltanalyse ist es auch, die Beziehungen zu interagierenden Unternehmen (insbesondere zu Lieferanten, Kunden, Banken und Öffentlichen Verwaltungen) aufzudecken, um daraus resultierendes Leistungspotenzial offen zu legen (z. B. zum Zweck der Unterstützung zwischenbetrieblicher Austauschbeziehungen). Um das identifizierte Leistungspotenzial auszuschöpfen, werden Technologien zum Aufbau von Erfolgspotenzial gesucht.

Andere Vorgehensweisen Im Vergleich zur IT-Diagnose und insbesondere bezüglich der Wettbewerbsanalyse eher einfache Vorgehensweisen der Situationsanalyse sind (nach Mertens/Plattfaut):  







Mitbewerberanalyse: Es werden Informationssysteme von Mitbewerbern oder von Unternehmen anderer Branchen analysiert, von denen bekannt ist, dass sie Wettbewerbsvorteile schaffen. Nutzung von Erfahrungen: Es wird versucht, Technologien, mit deren Anwendung auf operativer Ebene Erfahrungen gesammelt wurden, zur Unterstützung strategischer Unternehmensziele einzusetzen. Das Risiko einer Fehlinvestition ist hier gering, da vor der Planung entsprechender Informationssysteme nicht erst die informationstechnologischen Grundlagen geschaffen werden müssen, da sie – zumindest teilweise – aus Erfahrung bekannt sind. Erfolgspotenzial in Schnittstellen: Es wird von der Erfahrung ausgegangen, dass Möglichkeiten zur Schaffung von Erfolgspotenzial besonders an den Schnittstellen zwischen den Informationssystemen liegen. Man konzentriert sich deshalb darauf, die Schnittstellen zu optimieren, beispielsweise durch die Neugestaltung der innerbetrieblichen Informationsflüsse (innerbetriebliche Integration) und/oder der Informationsflüsse zu Kunden und Lieferanten (zwischenbetriebliche Integration). Planungssystematiken: Es werden Systematiken der strategischen Planung (z. B. die Systematisierung der Wettbewerbskräfte in Faktoren, welche die Wettbewerbsstruktur in einem Markt bestimmen) verwendet. Die Wettbewerbskräfte werden bezüglich ihrer Beeinflussbarkeit durch Technologieeinsatz untersucht. Dabei kann erkannt werden, wie Austrittsbarrieren gegenüber Kunden bzw. von Eintrittsbarrieren gegenüber Mitbewerbern aufgebaut werden. Wertekette: Es wird das von Porter entwickelte Modell verwendet, das die Wert schöpfenden Aktivitäten des Unternehmens (Wertaktivitäten) systematisiert und ihren Beitrag zur Wertschöpfung feststellt. Mit dem Ausbau der Informationsinfrastruktur wird primär bei den Wertaktivitäten angesetzt, in denen ein hohes Wertschöpfungspotenzial liegt, dessen Aktivierung einen deutlichen Beitrag zur Kostensenkung oder Differenzierung ermöglicht.

100





Strategische Aufgaben des Informationsmanagements

Ausgehend vom Modell der Wertekette haben Porter/Millar die Information Intensity Matrix entwickelt, mit der die Abschätzung des Leistungspotenzials der Informationsfunktion zur Schaffung von Wettbewerbsvorteilen in einer bestimmten Branche unterstützt werden kann. Als Dimensionen der Matrix werden Informationsintensität der Wertekette (information intensity of the value chain) und Informationsgehalt des Produkts (information content of/in the product) verwendet. Consumer Resource Life Cycle: Detailliertere Ergebnisse als die bisher genannten Vorgehensweisen ermöglicht der Consumer Resource Life Cycle nach Ives/Learmonth, weil er die Analyse der Wettbewerbssituation auf die Beziehungen des Unternehmens zu seinen Kunden konzentriert.

Forschungsbefunde Strategische Maßnahmen auf Grund der Ergebnisse einer Situationsanalyse, insbesondere der Wettbewerbsanalyse, können zu Veränderungen der Informationsinfrastruktur führen, die den Kunden Vorteile verschafft, welche die Mitbewerber nicht bieten. Dies zwingt sie dazu, nachzuziehen. Daraus kann die These abgeleitet werden, dass sich langfristig die Position der Kunden verbessert und die der Lieferanten verschlechtert. Treacy hat versucht, diese These am Beispiel der Luftverkehrsgesellschaften zu belegen (zitiert nach Mertens/Plattfaut). Im Ergebnis wird festgestellt: Die Einführung von Platzbuchungssystemen bei Reiseveranstaltern hat den Luftverkehrsgesellschaften zunächst Vorteile gebracht. Nachdem alle wichtigen Mitbewerber nachgezogen haben, verschärft sich der Wettbewerb, und die Gewinnsituation der Branche verschlechtert sich. Die Gewinnsituation des Innovators (also der Luftverkehrsgesellschaft, die als erste ein Platzbuchungssystem bei den Reiseveranstaltern eingeführt hat) ist jedoch besser als die seiner Mitbewerber. Lullies/Bollinger/Weltz stellen als Ergebnis einer empirischen Breitenuntersuchung (Experteninterviews in Deutschland und den USA) und drei Einzelfallstudien unter anderem eine Strategielücke zwischen strategischer Geschäftspolitik und Konzepten des Technologieeinsatzes fest. Es gelingt den Unternehmen kaum, „Technik und Geschäftspolitik systematisch zu verbinden, den bestehenden Gestaltungsspielraum auszuloten und ganzheitliche Gestaltungsalternativen zu entwickeln“. Bei der strategischen Planung werden Geschäftspolitik und Technologieeinsatz kaum miteinander verknüpft; die Entwicklung des Einen erfolgt ohne Beziehung zum Anderen. Die Autoren finden im Ergebnis das Produktivitätsparadoxon nach Attewell bestätigt, das behauptet, dass Sektoren, Branchen und Unternehmen mit besonders hohen Technologieinvestitionen eine stagnierende oder sogar rückläufige Produktivitätsentwicklung aufweisen und insgesamt von einer empirischen Evidenz für Produktivitätssteigerung durch Informations- und Kommunikationstechnologie keine Rede sein kann. Henderson/Venkatraman formulieren auf Grund von Forschungsarbeiten und Erfahrungen aus Beratungsprojekten fünf Prinzipien einer effektiven Kapitalisierung des IT-Wertes: 1. Business impact: Value realisation lies in the design of new business models that are enabled by IT and in the design of product/service platforms for the information age. 2. Community of practice: Value realisation requires an organizational architecture that is able to co-ordinate a community of professionals with complementary expertise.

Situationsanalyse (SITAN)

101

3. Selective sourcing: Value realisation is enhanced by assembling the required IT capabilities through a portfolio of relationships that is adapted over time. 4. Knowledge infrastructure: The new economy is likely to reward intellectual assets more than physical assets; value realisation requires the creation of a business platform suited to this environment. 5. Strategic alignment: Value realisation through IT rests on strategic alignment of the four principles discussed above; this is a dynamic process as the changing business environment drives the evolution of new organisational models. Heinrich/Pomberger (1999) leiteten aus Ergebnissen der wissenschaftlichen Begleituntersuchung von Strategieentwicklungsprojekten (vier Fallstudien mit Aktionsforschung, Untersuchungszeitraum 1995-1998) folgende potenzielle Ursachen strategischer Überdehnung ab:  

    

Es besteht keine Klarheit über das Leistungspotenzial, folglich kann Erfolgspotenzial nicht systematisch aufgebaut werden. Es besteht ein Schein-Erfolgspotenzial, da es sich nicht auf Leistungspotenzial stützen kann (z. B. kundennahe Informationssysteme mit einer Funktionalität, die nur einen geringen oder keinen Beitrag zum Unternehmenserfolg liefern, weil vorhandene Funktionen von den Kunden nicht in Anspruch genommen werden). Eine strategische IT-Planung ist nicht vorhanden; es werden weder strategische Ziele gesetzt, noch werden strategische Maßnahmen entwickelt. Es gibt kein Controlling, insbesondere kein Controlling der Leistungen und der Kosten. Leistung verbessernde und Kosten senkende Methoden und Werkzeuge sind den Verantwortlichen nicht ausreichend bekannt und/oder werden nicht eingesetzt. Nicht ausreichendes Niveau von Qualifikation und/oder Motivation der IT-Mitarbeiter. Die Verteilung der Informationsinfrastruktur entspricht nicht den struktur- und ablauforganisatorischen Anforderungen; meist liegt zu viel Zentralisierung vor.

Es spricht einiges dafür, dass die meisten Ursachen durch die Unternehmensgröße bedingt sind. Folgende Hypothese kann zutreffen: „Je kleiner das Unternehmen und je größer das Leistungspotenzial, desto größer die Gefahr der strategischen Überdehnung.“ Das heißt, dass von der Informationsinfrastruktur mehr verlangt wird, als sie bei gegebener Unternehmensgröße und verfügbaren Ressourcen (z. B. Höhe des IT-Budgets, Innovationsfähigkeit) leisten kann. Diese Hypothese kann exemplarisch mit einer Situationsanalyse überprüft werden.

Aus der Praxis Müller-Zantop berichtet aus dem Beratungsgeschäft, dass der Nutzen eines Client/ServerProjekts mit 10 % durch Reduzierung der Kosten und mit 90 % durch einen verbesserten Geschäftsprozess, höhere Produktivität und bessere Synchronisation der IT mit den Unternehmenszielen realisiert wird. In 50 % aller Client/Server-Projekte sind die geplanten Kosten deutlich überschritten worden. Die Notwendigkeit einer Situationsanalyse wird wie folgt begründet: „Ein Unternehmen, das nicht zuerst seinen Bestand ‚aufräumt‘, bevor es die IT enger an die geschäftlichen Ziele der Organisation bindet, muss mit weiteren Produktivitätsverlusten rechnen. Allein durch gutes Bestandsmanagement kann eine Kostenreduzierung beim Enduser Computing zwischen 20 % und 30 % erreicht werden.“

102

Strategische Aufgaben des Informationsmanagements

Methodenverweise Erfolgsfaktorenanalyse (Lerneinheit ERFAN); Kennzahlensysteme (Lerneinheit KENNZ); Szenariotechnik (Lerneinheit SZENA). Fallstudienverweise Lerneinheit FSITA der 8. und FSSIT der 9. Auflage zeigen am praktischen Beispiel die Durchführung einer Situationsanalyse, siehe die Website dieses Buches. Kontrollfragen 1. Welcher Zusammenhang besteht zwischen Leistungspotenzial und Unternehmenserfolg? 2. Was bedeutet „Analyse der Wettbewerbssituation“? 3. Wie wird bei der Analyse der Informationsinfrastruktur vorgegangen? 4. Warum ist die Umweltanalyse primär eine Technologieanalyse? 5. Welche Alternativen zu einer umfassenden IT-Diagnose gibt es? Quellen Hammer, M. / Champy, J.: Business Reengineering: Die Radikalkur für das Unternehmen. 7. A., Frankfurt a. M. 2003 Heinrich, L. J.: Strategische Überdehnung der Informationsinfrastruktur. In: Bartmann, D. (Hrsg.): Lösungsansätze der Wirtschaftsinformatik im Lichte der praktischen Bewältigung. Berlin et al. 1991, 123–135 Heinrich, L. J. / Häntschel, I. / Pomberger, G.: Diagnose der Informationsverarbeitung. Konzept und Fallstudie. In: CONTROLLING 3/1997, 196–203 Heinrich, L. J. / Heinzl, A. / Riedl, R.: Wirtschaftsinformatik – Einführung und Grundlegung. 4. A., Berlin/Heidelberg 2011 Heinrich, L. J. / Pomberger, G.: Entwickeln von Informatik-Strategien. In: Lausen, G. / Oberweis, A. / Schlageter, G. (Hrsg.): Angewandte Informatik und Formale Beschreibungsverfahren. Stuttgart/Leipzig 1999, 108–127 Heinrich, L. J. / Pomberger, G.: Diagnose der Informationsverarbeitung. In: Schweiggert, F. / Stickel, E. (Hrsg.): Informationstechnik und Organisation. Planung, Wirtschaftlichkeit und Qualität. Stuttgart 1995, 23–38 Henderson, J. C. / Venkatraman, D. J.: Five principles for making the most of IT. FINANCIAL TIMES, Supplement „Mastering Information Management“ vom 1.3.1999, 4–5 Ives, B. / Learmonth, G. P.: The Information System as a Competitive Weapon. In: Communications of the ACM 12/1984, 1193–1201 Lullies, V. / Bollinger, H. / Weltz, F.: Konfliktfeld Informationstechnik. Innovation als Managementproblem. Frankfurt a. M. 1990 McFarlan, F. W.: Information Technology Changes the Way You Compete. In: Harvard Business Review 3/1984, 98–103 McFarlan, F. W. / McKenney, J. L.: Corporate Information Systems Management. Homewood/Ill. 1983 Mertens, P. / Plattfaut, E.: Informationstechnik als strategische Waffe. In: Information Management 2/1986, 6–17 Müller-Zantop, S.: Wo liegt der Wert der Informationsverarbeitung? In: F.A.Z. vom 17.3.1998, B 6 Porter, M. E.: Wettbewerbsvorteile. 7. A., Frankfurt a. M. 2000 Porter, M. E. / Millar, V. E.: How Information Gives You Competitive Advantage. In: Harvard Business Review 4/1985, 149–160 Vertiefungsliteratur Brynjolfson, E.: The Productivity Paradox of Information Technology. In: Communications of the ACM 12/1993, 67–77 Enns, H. G. / Huff, S. L. / Higgins, C. A.: CIO Lateral Influence Behaviors: Gaining Peers´ Commitment to strategic Information Systems. In: MIS Quarterly 1/2003, 155–176 Fröschle, H.-P. (Hrsg.): Wettbewerbsvorteile durch IT. Heidelberg 2004 Fröschle, H.-P. (Hrsg.): Wettbewerbsfaktor IT. Heidelberg 2009 Kainz, G. A. / Walpoth, G.: Die Wertschöpfungskette als Instrument der IS-Planung. In: Information Management 4/1992, 48–57 Piccoli, G. / Blake, Ives: IT-dependent Strategic Initiatives and Sustained Competitive Advantage: A Review and Synthesis of the Literature. In: MIS Quarterly 4/2005, 141–116 Rockart, J. F. / Scott, M.: Implications of Changes in Information Technology for Corporate Strategy. In: Interfaces 1/1984, 84–95

Zielplanung (SZIEL) Lernziele Sie kennen den Zweck der strategischen Zielplanung und den Unterschied zwischen strategischen Zielen des Informationsmanagements und strategischen IT-Zielen. Sie können den Zielcharakter und seine Merkmale erläutern. Sie kennen die Quellen strategischer IT-Ziele und können deren Zielinhalt beschreiben. Sie kennen Vorgehensweisen der strategischen Zielplanung und die Probleme beim Festlegen des Zielmaßstabs. Sie kennen die Bedeutung von IT-Leitbildern für die strategische IT-Planung und exemplarisch deren Inhalt.

Definitionen und Abkürzungen Bottom-up-Ansatz (bottom-up approach) = Vorgehensweise bei Analyse, Entwurf, Testen usw., bei der mit den Systemteilen begonnen wird, die sich auf der untersten Ebene des hierarchisch gegliederten Systems befinden. Im Gegensatz dazu: Top-down-Ansatz. Formalziel (goal) = Ziel, dessen Zielinhalt die Qualität oder Güte beschreibt, mit der ein Sachziel verfolgt werden soll (Wie soll ein Zweck erreicht werden?). Handlungsspielraum (action scope) = mehrdimensionaler Begriff, der Entscheidungsspielraum, Tätigkeitsspielraum und Freiheitsspielraum umfasst. KPI = Key Performance Indicator. Leistung (performance) = Fähigkeit eines Systems, eine bestimmte Aufgabe in vorgegebener Zeit erfüllen zu können (Aufgabenerfüllung pro Zeiteinheit). MTBF = Mean Time Between Failures (mittlerer Zeitabstand zwischen zwei Ausfällen); Maßeinheit für Verfügbarkeit (üblicherweise in Tagen oder Monaten). MTTF = Mean Time To Failure (mittlere Zeitdauer bis zu einem Ausfall); Maßeinheit für Verfügbarkeit (üblicherweise in Stunden). Nutzen (benefit) = subjektiv beeinflusster Wert einer Handlungsalternative zur Befriedigung eines definierten Bedarfs. Synonym: Nutzwert. operational (operational) = Eigenschaft einer Handlungsanweisung, so formuliert zu sein, dass sie von den für sie bestimmten Adressaten befolgt werden kann. Sachziel (objective) = Ziel, dessen Zielinhalt einen Zweck definiert (Was soll erreicht werden?). strategisches IT-Ziel (strategic IT objective) = Ziel, das die langfristige, unternehmensweite und den Wettbewerb positiv beeinflussende Veränderung der IT lenkt. Ziel (objective) = angestrebter Endpunkt eines menschlichen Handlungsprozesses. Zielbeziehung (goal relation) = Tatsache, dass die Erfüllung eines Ziels die Erfüllung eines anderen Ziels beeinflusst. Zielhierarchie (goal hierarchy) = stufenmäßig aufgebaute Ordnung der Elemente eines Zielsystems in Form einer Rangordnung mit von oben nach unten abnehmender Bedeutung. Zielplanung (goal setting) = Prozess des Festlegens (Setzens) von Zielen nach Inhalt, Maßstab, Ausmaß der Zielerreichung und zeitlichem Bezug. Zielsystem (goal system) = geordnete Menge von Zielen, zwischen denen Beziehungen bestehen, die idealtypisch gesehen komplementär, konfliktär oder indifferent sind.

104

Strategische Aufgaben des Informationsmanagements

Zweck der strategischen Zielplanung Zweite Aufgabe der strategischen IT-Planung ist es, auf Grundlage der Ergebnisse der strategischen Situationsanalyse (vgl. Lerneinheit SITAN) und/oder – wenn dies implementiert ist – der vom strategischen Controlling gelieferten Daten (vgl. Lerneinheit CONTR) strategische IT-Ziele zu setzen. Diese sind mit Zielen des Informationsmanagements nicht identisch, auch wenn einzelne Elemente der beiden Zielsysteme bezüglich des Zielinhalts ähnlich oder sogar gleich sind (z. B. Wirtschaftlichkeit). Die verschiedenen Denkweisen, welche die Methodik des Informationsmanagements kennzeichnen, sind Leitlinien beim Festlegen des Zielinhalts der strategischen IT-Ziele (vgl. Lerneinheit ERMOD). Ist ein unternehmensweites, nach der Balanced Scorecard konzipiertes Kennzahlensystem implementiert (vgl. Lerneinheit KENNZ), lassen sich die strategischen IT-Ziele daraus ableiten. Mit dem Top-down-Ansatz werden die strategischen Ziele für die administrative Ebene sowie dann die damit gesetzten administrativen Ziele für die operative Ebene abgeleitet („heruntergebrochen“). Im Ergebnis wird mit der strategischen Zielplanung der Handlungsspielraum für die nachfolgenden Aufgaben der strategischen IT-Planung (vgl. Lerneinheiten STRAT und SPLAN), für weitere strategische Aufgaben (z. B. für das Architekturmanagement, vgl. Lerneinheit ARCHI) sowie für die administrativen und operativen Aufgaben des Informationsmanagements geschaffen. Der Handlungsspielraum definiert im Sinne einer Vorsteuerung das Erfolgspotenzial, das durch die strategische Maßnahmenplanung präzisiert und durch die Maßnahmen auf der administrativen und auf der operativen Aufgabenebene umgesetzt werden kann. Strategische Ziele lenken diese Vorsteuerung und sind damit letztlich Hilfsmittel für die Suche, den Aufbau und die Erhaltung von Erfolgspotenzial. Die strategischen IT-Ziele finden Eingang in das Controlling-Konzept, insbesondere in das Konzept des strategischen IT-Controllings (vgl. Lerneinheit CONTR). Strategische IT-Ziele sind damit Ausgangspunkt und Grundlage für die Ableitung von IT-Controlling-Zielen. Die Schwierigkeit, Zielmaßstäbe auf der strategischen Ebene festzulegen, wird durch das Setzen operationaler Ziele auf der administrativen Ebene, vor allem aber auf der operativen Ebene, gemildert. Dabei muss jedoch in Kauf genommen werden:  

Auf der strategischen und auf der administrativen Ebene entstehen Planungs-, Überwachungs- und Steuerungslücken. Ungenauigkeiten bei der Ermittlung der Istwerte der Zielerreichung lassen sich nicht vermeiden, da für die bottom-up erfolgende Transformation von Istwerten von der operativen in die administrative und von dieser in die strategische Ebene keine Algorithmen, sondern nur Heuristiken zur Verfügung stehen.

Zielsystem und Zielhierarchie Ziele sind nicht eine Menge von Zielen, sondern ein Zielsystem, aus dem eine Zielhierarchie entsteht, wenn Oberziele und untergeordnete Ziele komplementär sind. Anforderungen an ein Zielsystem sind Vollständigkeit, Operationalität, Widerspruchsfreiheit, Realisierbarkeit und Identifikation der Betroffenen mit dem Zielsystem bezogen auf das betrachtete Objekt (hier auf Informationsfunktion und Informationsinfrastruktur eines Unternehmens, im

Zielplanung (SZIEL)

105

Folgenden kurz gesagt der IT des Unternehmens). Diesen Anforderungen kann allerdings meist nicht vollständig entsprochen werden.     

Vollständigkeit heißt, dass alle für den Unternehmenserfolg relevanten Objekte und Eigenschaften der IT abgebildet sind. Operationalität heißt, dass jedem Objekt und jeder Eigenschaft eine Metrik zugeordnet ist, mit der das Ausmaß der Zielerreichung vorgegeben und gemessen werden kann. Widerspruchsfreiheit heißt die logische Richtigkeit der Abbildung der Wirklichkeit im Zielsystem; sich widersprechende Ziele sind nicht vorhanden. Realisierbarkeit heißt, dass bei Verfolgung der Ziele die für die Zielerreichung erforderlichen Ressourcen zur Verfügung stehen. Synonyme: Durchführbarkeit, Machbarkeit. Identifikation der Betroffenen heißt, dass sich das Zielsystem nur dann bewähren kann, wenn sich Unternehmensziele und Individualziele in Übereinstimmung befinden.

Zielcharakter Strategische IT-Ziele sind – so wie die Ziele in jedem betriebswirtschaftlichen Zielsystem – Formalziele oder Sachziele (vgl. Lerneinheit ERMOD). Nur Formalziele sind einer von der Unternehmenssituation unabhängigen Analyse bezüglich des Festlegens des Zielinhalts und des Zielmaßstabs sowie der Zielbeziehungen zugänglich. Sachziele sind auch dadurch gekennzeichnet, dass sich die Zielinhalte im Zeitablauf wesentlich häufiger verändern, als dies bei Formalzielen der Fall ist, und auch obsolet werden können. Andererseits werden häufig neue Zielinhalte für Sachziele relevant, insbesondere bedingt durch wesentlich veränderte oder neue Geschäftsmodelle und/oder Technologien. Für die Zielfindung bezüglich der Sachziele ist eine ergänzende Systematik hilfreich, welche die beiden Zielkategorien  

betriebswirtschaftlich orientierte Ziele (business oriented objectives) und technisch orientierte Ziele (technically oriented objectives)

verwendet. Beispiele für betriebswirtschaftlich orientierte Sachziele mit relativ langfristig gültigem Zielinhalt sind Streben nach Prozessorientierung, Virtualisierung oder Wissensorientierung. Beispiele für technisch orientierte Ziele sind Nutzung von Grid Computing, Metadatenmanagement (Enterprise Information Management), Parallelverarbeitung, serviceorientierte Architekturen (SOA) oder Zugangskontrollsysteme (Identity Management). Beispielsweise heißt Prozessorientierung als betriebswirtschaftlich orientiertes Sachziel, Strategien zu entwickeln sowie Maßnahmen zu planen und zu realisieren, um eine an den Funktionalbereichen (wie Beschaffung, Produktion, Absatz) ausgerichtete Strukturorganisation durch eine Ausrichtung an den Geschäftsprozessen zu ersetzen und – wenn diese Ausrichtung erreicht ist – durch Business Process Reengineering die Verbesserung der Geschäftsprozesse ständig zu verfolgen (z. B. zur Verkürzung der Auftragsdurchlaufzeit oder der Prozesskosten). Nutzung von Parallelverarbeitung als technisch orientiertes Sachziel heißt gleichzeitige Verarbeitung an mehreren Stellen eines aus verteilter paralleler Datenbank und speziellen parallelisierten Prozessen bestehenden Systems durch Verwendung einer Multiprozessorarchitektur in Verbindung mit Plattenarrays als Hardwarebasis (z. B. zur Verkürzung der Produktentwicklungszeit).

106

Strategische Aufgaben des Informationsmanagements

Zielinhalte Wirtschaftsinformatik als Wissenschaft hat bisher kaum Beiträge zur Beantwortung der Frage geliefert, welches bezüglich Zielinhalt und Zielmaßstab die Formalziele sind, nach denen die IT auf strategischer Ebene geplant, überwacht und gesteuert werden soll. Ansätze einer systematischen Zielforschung gibt es bezüglich der Ziele der Systementwicklung (d. h. der Planungsziele für IT-Projekte mit dem Zweck der [Re]Konstruktion von Informationssystemen), so dass zunächst mit einem Bottom-up-Ansatz versucht wird, aus empirisch feststellbaren Zielen der Entwicklung von IT-Artefakten auf administrativer Ebene auf strategische IT-Ziele zu schließen (empirische Zielanalyse). Dies reicht zur Bestimmung der Formalziele nicht aus, so dass eine Ergänzung durch eine theoretische Zielanalyse erforderlich ist. Die empirisch feststellbaren Formalziele sind systembezogen oder systemindifferent. Systembezogene Ziele haben Zielinhalte und/oder Zielmaßstäbe, die nur für spezifische ITArtefakte (z. B. für einzelne Informationssysteme) Zielcharakter haben. Systemindifferente Ziele haben Zielinhalte und/oder Zielmaßstäbe, die für die IT insgesamt Zielcharakter haben. Nach der empirischen Zielanalyse sind Sicherheitsstreben, Produktivitätsstreben und Wirtschaftlichkeitsstreben strategische Formalziele. 





Sicherheitsstreben: Sicherheit ist die Eigenschaft der IT, das Entstehen von Gefährdungszuständen vermeiden, entstandene Gefährdungszustände erkennen und ihre Auswirkungen verhindern oder zumindest einschränken zu können (vgl. Lerneinheit SICHM). Produktivitätsstreben: Produktivität ist die Eigenschaft der IT, bezüglich eines geplanten oder des tatsächlichen mengenmäßigen Ertrags zum mengenmäßigen Einsatz von Produktionsfaktoren zur Erwirtschaftung dieses Ertrags in einer bestimmten Beziehung zu stehen. Dieses Ziel steht im Mittelpunkt des Zielsystems eines Leistungsmanagements; Leistungsobjekte sind Prozesse, Struktureinheiten oder Mitarbeiter (Teams). Wirtschaftlichkeitsstreben: Wirtschaftlichkeit (Synonym Effizienz) ist die Eigenschaft der IT, bezüglich einer geplanten oder tatsächlichen Kostensituation in einem bestimmten Verhältnis zu einer Bezugsgröße (z. B. günstigste Kostensituation) oder bezüglich der Leistungssituation (Nutzen) in einem bestimmten Verhältnis zu einer Bezugsgröße (z. B. dem mit Kosten bewerteten Einsatz an Produktionsfaktoren zur Erbringung der Leistung) zu stehen (vgl. Lerneinheit WIRTA).

Dass eine empirische Zielanalyse zur Erklärung der strategischen IT-Ziele nicht mehr Resultate bringt, ist darauf zurückzuführen, dass sich die Praxis primär mit den operativen Aufgaben des Systembetriebs und den administrativen Aufgaben der Systementwicklung befasst. Die Aufgaben der strategischen IT-Planung werden nur in relativ wenigen, meist großen Unternehmen systematisch wahrgenommen. Ein zu geringes Interesse an empirischer Forschung in der Wirtschaftsinformatik kann dafür aber auch verantwortlich gemacht werden. Die theoretische Zielanalyse leitet strategische IT-Ziele aus dem Erklärungsmodell des Informationsmanagements ab (IM-Modell), dessen Anpassung an die unternehmensspezifischen Bedingungen (IM-Konzept, vgl. Lerneinheit ERMOD) Voraussetzung für eine informationsorientierte Unternehmensführung ist. Damit ist die Art der Unternehmensführung gemeint, die das Leistungspotenzial der Informationsfunktion durch Schaffung, Nutzung und

Zielplanung (SZIEL)

107

Weiterentwicklung einer schlagkräftigen IT in Erfolgspotenzial umsetzt und dies zur Verbesserung des Unternehmenserfolgs einsetzt. Nach der theoretischen Zielanalyse sind Anpassungsstreben, Durchdringungsstreben und Wirksamkeitsstreben strategische Formalziele.   

Anpassungsstreben: Anpassung ist die Eigenschaft der IT, ohne grundlegende Veränderungen auf qualitative und quantitative Änderungen der Informationsfunktion reagieren zu können (Flexibilität, neuerdings auch als Agilität bezeichnet). Durchdringungsstreben: Durchdringung ist die Eigenschaft der IT, die Informationsfunktion unternehmensweit zu unterstützen. Wirksamkeitsstreben: Wirksamkeit ist die Eigenschaft der IT, Funktionen und Leistung zur Aufgabenerfüllung zur Verfügung zu stellen, unabhängig von den dafür erforderlichen Kosten und dem dadurch realisierbaren Nutzen (Effektivität).

Wirksamkeit meint auch, in welchem Umfang das Erfolgspotenzial der IT durch die Geschäftsprozesse bzw. letztlich durch die Benutzer tatsächlich ausgeschöpft wird. Angebotene Funktionen und Leistungen, die nicht genutzt werden, reduzieren die Wirksamkeit (und auch die Wirtschaftlichkeit). Im Mittelpunkt der Beurteilung der Wirksamkeit steht daher das Bedarfspotenzial der Geschäftsprozesse. Anzustreben ist nicht nur, dass sich Leistungspotenzial und Erfolgspotenzial im Gleichgewicht befinden, sondern auch deren Übereinstimmung mit dem Bedarfspotenzial der Geschäftsprozesse.

Zielmaßstäbe Mit den aus den beiden Zielanalysen gewonnenen Formalzielen, nämlich Anpassungs-, Durchdringungs-, Produktivitäts-, Sicherheits-, Wirksamkeits- und Wirtschaftlichkeitsstreben, wird die Qualität aller Handlungen zur Umsetzung des Leistungspotenzials in Erfolgspotenzial und dessen Nutzung geplant, überwacht und gesteuert. Damit liegen Zielinhalte vor, für die im nächsten Schritt Zielmaßstäbe festzulegen sind, um Sollwerte für die Zielerreichung vorgeben und Istwerte messen zu können. Das Festlegen der Zielmaßstäbe stößt auf erhebliche praktische Schwierigkeiten, so dass teilweise nur eine verbale Beschreibung, teilweise eine operationale Messvorschrift und nur selten eine Messvorschrift für quantitative Zielmaßstäbe angegeben werden kann. Erst durch das Ableiten von administrativen Zielen aus strategischen Zielen und – noch mehr – durch das Ableiten von operativen Zielen aus administrativen Zielen sind auf der administrativen und besonders auf der operativen Ebene präzisere Zielmaßstäbe möglich (vgl. Lerneinheit CONTR). Ein quantitativer und damit operationaler Zielmaßstab ist die Eigenschaft eines Ziels, dessen Ausprägung mit einer Messmethode ermittelt werden kann (Metrik). Eine für die strategische Planung spezifische Art von Metrik wird als KPI bezeichnet, obwohl nicht nur Leistung abgebildet wird. Ein bestimmter KPI sollte nicht mehreren Zielinhalten zugeordnet sein. Die KPI insgesamt sollten alle Unternehmensbereiche erfassen und alle relevanten Sichten abbilden. Die Auswahl der verwendeten Sichten orientiert sich beispielsweise an den vier Bereichen der Balanced Scorecard (vgl. Lerneinheit KENNZ). Im Folgenden werden Formulierungen für Zielmaßstäbe der strategischen Formalziele angegeben. Soweit dies durch Nennung von Bedingungen erfolgt, ist der Weg von einer nur verbalen Beschreibung des Zielmaßstabs zu einer oder zu mehreren KPI erkennbar. Dies wird beispielhaft angegeben.

108

Strategische Aufgaben des Informationsmanagements

Anpassung: Funktionen und Leistungen der IT werden in der Regel nach bestimmten, zu den Zeitpunkten der Investitionsentscheidung bekannten oder prognostizierten Anforderungen festgelegt, die erfahrungsgemäß nicht in dieser Art und/oder in diesem Umfang eintreten (größer oder geringer sind). Eine flexible Infrastruktur kann sich dem anpassen. Sowohl die Änderung der Anforderungen, als auch die Aufnahmefähigkeit der Infrastruktur für veränderte, erweiterte oder neue Anforderungen, sind nur verbal beschreibbar. Eine präzisere Beschreibung ist für einzelne IT-Komponenten (z. B. Datenbestände, Personal, Werkzeuge) möglich. So kann Flexibilität des Personals durch Qualifikationsprofile mit expliziter Angabe der Fähigkeiten, Fertigkeiten und Kenntnisse der IT-Mitarbeiter beschrieben werden, beispielsweise in Form von Wissenskarten für Wissensträger (vgl. Lerneinheit MEWIM). Durchdringung: Art und Umfang der Informations- und Kommunikationsaufgaben sind in den Struktureinheiten eines Unternehmens sehr verschieden, so dass nicht die Anzahl der Aufgaben als Bezugsgröße für Durchdringung verwendet werden kann; das gilt auch für die verwendeten Technologien. Durchdringung ist also nicht direkt messbar, und Hilfsgrößen sind nicht immer valide (z. B. der Durchdringungsgrad als Verhältnis von Arbeitsplätzen mit einer bestimmten Technologieausstattung zu Arbeitsplätzen insgesamt). Die Entwicklung valider Metriken für Durchdringung muss vom Leistungspotenzial der Informationsfunktion ausgehen und sowohl potenzielle Einsatzfelder von im Unternehmen implementierten Technologien als auch das Marktangebot von Technologien, die für den produktiven Einsatz zur Verfügung stehen, berücksichtigen. Ein so verstandener Zielmaßstab ist nicht bekannt. Produktivität: Die Produktivität der IT wird durch das Verhältnis des mengenmäßigen Ertrags ihrer Nutzung zum mengenmäßigen Einsatz an Produktionsfaktoren zur Erwirtschaftung dieses Ertrags gemessen. Wird beispielsweise für Ertrag „Anzahl Transaktionen“ (in einem bestimmten Zeitabschnitt) und für Einsatz „Anzahl PC-Arbeitsplätze“ (in einem bestimmten Objektbereich) als Metrik verwendet, lässt sich eine so definierte Produktivität planen, überwachen und steuern. Derartige Metriken erfassen jedoch nur einen Teilaspekt der Produktivität der IT, weil nur einzelne Leistungsobjekte erfasst werden. Ein die IT umfassender Zielmaßstab für Produktivität ist nicht bekannt. Sicherheit: Die IT ist sicher, wenn sie folgende Bedingungen erfüllt:     

Sie lässt ein unberechtigtes Verändern nicht zu oder ermöglicht die Identifizierung unberechtigter Veränderungen (Integrität). Sie ermöglicht den Nachweis von Verpflichtungen (Verbindlichkeit). Sie ist für die Benutzer immer verfügbar (Verfügbarkeit). Sie lässt eine unberechtigte Kenntnisnahme und Nutzung nicht zu (Vertraulichkeit). Sie ermöglicht den Nachweis jeder Nutzung (Nichtabstreitbarkeit).

Zusätzlich werden heute Anonymität oder Unbeobachtbarkeit gefordert, insbesondere im Zusammenhang mit elektronischer Kommunikation im Internet (z. B. will der Besucher einer Suchtberatungsstelle anonym bleiben, weil allein aus einem solchen Besuch geschlossen werden könnte, er habe ein Suchtproblem). Zwar können für jede einzelne dieser Bedingungen Zielmaßstäbe formuliert werden (z. B. MTBF und MTTF für Verfügbarkeit), nicht jedoch für Sicherheit insgesamt. Jedenfalls liegen brauchbare Vorschläge dazu nicht vor.

Zielplanung (SZIEL)

109

Wirksamkeit: Die IT ist wirksam, wenn sie folgende Bedingungen erfüllt:   

Es besteht Übereinstimmung zwischen erforderlicher und verfügbarer Funktionalität. Es besteht Übereinstimmung zwischen erforderlicher und erbrachter Leistung. Die verfügbare Funktionalität und die erbrachte Leistung werden von den Benutzern in Anspruch genommen (Akzeptanz des Bedarfspotenzials).

Wirksamkeit fragt nicht nach den Kosten für die Realisierung von Funktionalität und Leistung. Funktionalität kann in der Regel nur verbal beschrieben werden; einzelne Leistungen lassen sich quantifizieren (z. B. Anzahl Transaktionen/Zeiteinheit). Ein Zielmaßstab, der Wirksamkeit insgesamt erfasst, steht nicht zur Verfügung. Wirtschaftlichkeit: Die IT ist wirtschaftlich, wenn sie folgende Bedingungen erfüllt:  

Die tatsächliche Kostensituation entspricht einer geplanten Kostensituation (z. B. der günstigsten Kostensituation). Die in Geldeinheiten bewertete Leistungssituation, also der erbrachte Nutzen, ist höher als oder zumindest gleich hoch wie die verursachten Kosten.

Als Zielmaßstäbe werden verschiedene Verhältniszahlen verwendet, insbesondere: w1 =

K o s ten g ep lan t x 100 (%) K o s ten tats äch lich

w 2 = L eis tu n g en tats äch lich x 100 (%) K o s ten tats äch lich

Andere Kennzahlen für Wirtschaftlichkeit können in das strategische Zielsystem aufgenommen werden, um die Kosten-Leistungs-Betrachtung zu ergänzen, beispielsweise die Verhältniszahlen Ertrag/Investitionssumme, Gewinn/Kapital (Rentabilität) oder die Erweiterung dieser Kennzahl durch Einbeziehung des Umsatzes (ROI = Return on Investment). Dass die Kosten-Leistungs-Betrachtung für die Wirtschaftlichkeit der IT im Vordergrund steht, ist auf die aufwendige und trotzdem oft nicht ausreichend genaue, wenn überhaupt mögliche Erfassung und Zuordnung dieser Größen auf IT-Objekte zurückzuführen (z. B. die Erfassung des Gewinns, der durch eine IT-Investition generiert wurde und dieser zuzurechnen wäre). Beim Setzen und Verfolgen von Wirtschaftlichkeitszielen ist die von Brynjolfsson 1993 berichtete, als Produktivitätsparadoxon bezeichnete empirische Beobachtung zu beachten, dass IT-Investitionen nicht zwangsläufig zu einem nachweisbaren Nutzen wie steigende Produktivität und verbesserte Wettbewerbsfähigkeit und damit zu höherer Rentabilität führen. Es sind auch negative Wirkungsbeziehungen zwischen IT-Investition und Rentabilität beobachtet worden. Mit anderen Worten: Zwischen den genannten Größen besteht nicht immer eine positive, möglicherweise besteht sogar eine negative Korrelation. Das Erreichen von Wirtschaftlichkeitszielen kann durch Beachtung ökologischer Überlegungen bei der Schaffung, Nutzung und Weiterentwicklung der IT unterstützt werden (z. B. Senkung der energiespezifischen Betriebskosten durch Steigerung der Energieeffizienz von Rechenzentren mit moderner Kühlungstechnologie und Abwärmenutzung (vgl. Lerneinheit INMAN).

110

Strategische Aufgaben des Informationsmanagements

Vorgehensweise bei der Zielplanung Das Setzen der strategischen IT-Ziele wird nach den vier Dimensionen betriebswirtschaftlicher Ziele wie folgt in Arbeitsschritte gegliedert:    

Festlegen des Zielinhalts, also aller Eigenschaften oder Merkmale, mit denen die Qualität oder Güte geplant, überwacht und gesteuert werden sollen (Zielsystem). Festlegen des Zielmaßstabs, also der Dimension des Zielinhalts, und wie dieser gemessen werden soll (Metrik, KPI). Festlegen des Ausmaßes der Zielerreichung, also der Quantität des Zielinhalts, die erreicht werden soll (Planwert, Sollwert oder Zielwert). Festlegen des zeitlichen Bezugs der Zielerreichung, also des Zeitraums, in dem das angestrebte Zielausmaß erreicht werden soll (Planungszeitraum).

Strategische IT-Ziele können nur in Abstimmung mit den strategischen Unternehmenszielen gesetzt werden. „Abstimmung“ bedeutet dabei die Anwendung einer der drei Vorgehensweisen, die als reagierende, agierende und interagierende Zielplanung bezeichnet werden.   

Zielplanung ist reagierend, wenn sie von den strategischen Unternehmenszielen ausgeht und sich das Setzen der IT-Ziele vollständig an ihnen orientiert. Zielplanung ist agierend, wenn zunächst die strategischen IT-Ziele gesetzt und damit das Setzen der strategischen Unternehmensziele beeinflusst wird. Zielplanung ist interagierend, wenn die strategischen Unternehmensziele und die strategischen IT-Ziele (mehr oder weniger) parallel gesetzt und dann abgestimmt werden; im Konfliktfall gilt das Primat der Unternehmensziele.

Im Allgemeinen ist interagierende Zielplanung zu bevorzugen. Dazu ist auch eine Analyse der Unternehmensziele erforderlich, bei der folgende Arbeitsschritte durchzuführen sind:    

Bestimmen der strategischen Unternehmensziele, welche die kritischen Wettbewerbsfaktoren beeinflussen. Herausarbeiten der strategischen Unternehmensziele, zu deren Erreichung das Leistungspotenzial der Informationsfunktion beitragen kann. Herausarbeiten des Erfolgspotenzials, das zur Umsetzung des Leistungspotenzials in Unternehmenserfolg erforderlich ist (Sollzustand Erfolgspotenzial). Identifizieren des Bedarfspotenzials der Geschäftsprozesse.

In Unternehmen mit mehreren Geschäftsfeldern und unterschiedlicher IT-Architektur (vgl. Lerneinheit ARCHI) erfolgt die Zielplanung zunächst auf Geschäftsfeldebene, deren Ergebnisse nach dem Bottom-up-Ansatz zu strategischen IT-Zielen des Unternehmens aggregiert werden. Wird der Top-down-Ansatz verfolgt, werden zentral geplante IT-Ziele auf Geschäftsfeldebene heruntergebrochen. Zweckmäßig ist auch hier eine interagierende Vorgehensweise, bei der zentral geplante Ziele mit den dezentral je Geschäftsfeld geplanten Zielen abgestimmt werden. Ergebnis der Zielplanung ist dann in der Regel ein Kompromiss sowohl bezüglich der Zielinhalte als auch und insbesondere bezüglich der Zielerreichungsgrade. Beim Setzen von Zielen ist es zweckmäßig, auf nicht verfolgte Ziele (Nicht-Ziele) ausdrücklich hinzuweisen, sie also als explizit nicht zum Zielsystem gehörend zu kennzeichnen.

Zielplanung (SZIEL)

111

IT-Leitbilder Mit Leitbildern wird die Grundhaltung der Unternehmensleitung zur IT, personifiziert durch den CIO (vgl. Lerneinheit STELL), allen Beteiligten (Mitarbeiter und Unternehmensumwelt, insbesondere Kunden und Lieferanten) vermittelt. Es ist zweckmäßig, spezielle Leitbilder für Benutzer und IT-Personal zu entwickeln, da deren Inhalte – zumindest deren Schwerpunkte – nicht identisch sind. Leitbilder sollen Aussagen zu folgenden Fragen machen, die in kurzen Sätzen, so genannten Leitsätzen, formuliert werden, die bündige Erklärungen geben (internes IT-Marketing zur Imagebildung und -pflege für den IT-Bereich):     

Wie sieht sich das IT-Management selbst, welches Selbstverständnis hat es, welche Werte sind ihm wichtig und was will es in Zukunft erreichen (Zielorientierung)? Wie ist das Verhältnis des IT-Managements zu seinen Kunden, insbesondere zu den Benutzern, wer ist Kunde und was wird für Kunden getan (Benutzerorientierung, Kundenorientierung)? Wie ist das Verhältnis des IT-Managements zu seinen Mitarbeitern, wie geht es mit ihnen um, wie sind sie auf ihre Aufgaben vorbereitet und wie wird für ihre Weiterbildung gesorgt (Mitarbeiterorientierung)? Welche Services bietet der IT-Bereich, was ist das Besondere an diesem Angebot und wie unterscheidet es sich von anderen Angeboten (z. B. von dem externer Dienstleister)? Wie ist das Verhältnis des IT-Bereichs zu seiner Umwelt (Umweltschutz, Datenschutz, Sicherheit)?

Im Unternehmensleitbild sollte die strategische Grundhaltung des Informationsmanagements angemessen berücksichtigt werden. Obwohl in vielen Unternehmen die IT eine strategische Bedeutung für die Erreichung der Unternehmensziele hat, enthält das Unternehmensleitbild selten derartige Aussagen. Was den Umweltschutz als Leitsatz und daraus folgende Maßnahmen betrifft, werden dafür charakterisierende Bezeichnungen wie Öko-IT oder Green IT verwendet. Neben positiven Wirkungen einer vom Unternehmen verfolgten Green IT auf sein Image und seine gesellschaftliche Anerkennung spielt das IT-Ziel Wirtschaftlichkeit eine erhebliche, wenn nicht die entscheidende Rolle (z. B. Senkung der IT-Kosten durch mehr Energieeffizienz im Rechenzentrumsbetrieb, vgl. Lerneinheit INMAN).

Forschungsbefunde Mertens stellt fest, dass Ökonomie in der (kapitalistischen) Marktwirtschaft für das Unternehmen Rentabilitätsmaximierung bedeutet und dass sich Wirtschaftlichkeits- und Rentabilitätsmaximierung nicht decken. So genannte Ingenieurziele (z. B. Kostenminimierung, Maximierung der Kapazitätsauslastung) seien theoretisch nur haltbar, wenn zahlreiche Ceteris-Paribus-Klauseln gelten; bei ihrer Verwendung sei große Vorsicht geboten. Aus der Erfahrung mehrerer Anwendungen der Erfolgsfaktorenanalyse (sieben Fallstudien mit Aktionsforschung, Untersuchungszeitraum 1995-2000) empfehlen Heinrich/Pomberger (2001) die Verwendung des Gesamterfolgs im Sinne der Erfolgsfaktorenanalyse (vgl. Lerneinheit ERFAN) als strategisches IT-Ziel, in das – je nach Untersuchungsziel und Definition der Erfolgsfaktoren – alle relevanten Eigenschaften der IT eingehen. Wesentlicher Vorteil gegenüber anderen Zielinhalten ist die Quantifizierbarkeit des Gesamterfolgs.

112

Strategische Aufgaben des Informationsmanagements

Byrd/Turner haben mit einer empirischen Studie (Fragebogenmethode, 1.000 zufällig ausgewählte „senior IT manager in mainly large companies“, Rücklaufquote 20,7 %, Untersuchungszeitraum nicht angegeben, wahrscheinlich 1999) den Zusammenhang zwischen Flexibilität der Informationsinfrastruktur und Wettbewerbsvorteilen untersucht. Im Ergebnis wird festgestellt, dass eine flexible Infrastruktur (50) „…as measured by integration, modularity, and IT personnel flexibility is positively related to some organizational measures of innovativeness, mass customization, difficulty to duplicate, and market postion.“

Aus der Praxis Nach einer Studie von Ernst & Young (Befragung von 100 IT-Verantwortlichen in Schweizer Unternehmen, je Unternehmen 50 Interviews und ergänzende schriftliche Befragung, Untersuchungszeitraum März/April 2002) wurden als „die wichtigsten strategischen ITZiele“ angegeben: Unterstützung Business Prozesse 53 %, Wirtschaftlichkeit / Kostenreduktion 35 %, Standardisierung 32 %, Verbesserung IT Service Delivery 30 %. Kommentar: Der Befund zeigt die in der Praxis weit verbreitete Vermischung von Sach- und Formalzielen. Als Ergebnis der Studie „IT-Management 2005“ der KPMG wird u. a. berichtet, dass „nur rund ein Viertel der CIOs die Entscheidungskompetenz über strategische IT-Ziele und das IT-Budget“ haben. „Der Auftrag der CIOs liegt mehr in der Umsetzung der vorgegebenen Ziele.“ Kommentar: Der Befund lässt vermuten, dass eher IT-Manager als CIOs befragt wurden bzw. dass sich IT-Manager als CIOs bezeichnet haben oder bezeichnet wurden. Methodenverweise Erfolgsfaktorenanalyse (Lerneinheit ERFAN); Kennzahlensysteme (Lerneinheit KENNZ); Kosten- und Leistungsrechnung (Lerneinheit KOLER). Kontrollfragen 1. Wodurch unterscheiden sich Ziele, Zielsysteme und Zielhierarchien? 2. Durch welche Zielkategorien können IT-Ziele systematisiert werden? 3. Welche strategischen IT-Ziele im Sinne von Formalzielen werden unterschieden? 4. Wie kann der Zielmaßstab für strategische IT-Ziele festgelegt werden? 5. Mit welchen Arbeitsschritten wird bei der strategischen Zielplanung vorgegangen? Quellen Brynjolfsson, E.: Beyond the productivity paradox. In: Communications of the ACM 8/1998, 49–55 Brynjolfsson, E.: The productivity paradox of information technology. In: Communications of the ACM 12/1993, 66–77 Byrd, T. / Turner, D.: An exploratory eximination of the relationship between flexible IT infrastructure and competitive advantage. In: Information & Management, 1/2001, 41–49 Ernst & Young (Hrsg.): IT-Kosten und IT-Performance 2002 – Betriebswirtschaftliche Studie der Schweizer Informatikabteilungen. Bern 2002 Heinrich, L. J. / Pomberger, G.: Erfolgsfaktorenanalyse – Instrument für das strategische IT-Controlling. In: HMD – Praxis der Wirtschaftsinformatik 217/2001, 19–28 KPMG (Hrsg.): IT-Management 2005. Standortbestimmung und Trends in der Schweizer Informatik. http://www.kpmg.ch/RIM; Abruf 14.4.2008 Mertens, P.: Operiert die Wirtschaftsinformatik mit falschen Unternehmenszielen? – 15 Thesen. In: Becker, J. / König, W. / Schütte, R. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie: Bestandsaufnahme und Perspektiven. Wiesbaden 1999, 379–392

Strategieentwicklung (STRAT) Lernziele Sie kennen den Zweck der IT-Strategie als Brücke zwischen strategischer Zielplanung und strategischer Maßnahmenplanung. Sie können die Objekte, den Charakter und die Struktur der IT-Strategie erläutern. Sie kennen Vorgehensweisen zum Entwickeln der IT-Strategie und können als Ergebnis des Entwicklungsprozesses exemplarisch den Inhalt einer ITStrategie angeben. Sie wissen, warum Teilstrategien aus der IT-Strategie abgeleitet werden und können typische Teilstrategien nennen und erläutern.

Definitionen und Abkürzungen Digital Business = jede Art von wirtschaftlichem Handeln, das durch Internettechnologien unterstützt wird. Synonym: Electronic Business, kurz als eBusiness bezeichnet. Einsatzstrategie (operational strategy) = Teilstrategie, die beschreibt, in welche Geschäftsfelder, betrieblichen Aufgaben bzw. Geschäftsprozesse mit welcher zeitlichen Priorität und mit welchen Budgets (Investitionshöhe) wann investiert werden soll. Evaluierung (evaluation) = zielbezogene Beurteilung von Objekten auf Grundlage eines Systems von relevanten Eigenschaften (Evaluierungskriterien). Synonym: Evaluation. Individualziel (individual objective) = Ziel von Personen oder Gruppen, die Mitglieder einer Organisation sind (z. B. ein Erhaltungsziel wie Sicherheit des Arbeitsplatzes). KonTraG = Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (Deutschland). Normstrategie (norm strategy) = Strategie, die bei Vorliegen bestimmter Ausprägungen von Evaluierungskriterien grundsätzlich empfehlenswert ist. Organisationsziel (organizational objective) = Ziel als Element des Zielsystems einer Organisation, das von dem dafür zuständigen Management gesetzt wird. Realisierungsstrategie (realization strategy) = Strategie, die den Weg vom Istzustand zum angestrebten Sollzustand beschreibt. Strategie (strategy) = langfristig und unternehmensweit angelegte Verhaltens- und Verfahrensweise zur Schaffung und Erhaltung von Erfolgspotenzial. Strategieansatz (strategy approach) = systematische, auf Thesen oder Hypothesen beruhende Vorgehensweise bei der Strategieentwicklung. Strategietyp (strategy type) = Positionierung einer Wettbewerbsstrategie bei Verwendung der Dimensionen Wettbewerbsfeld und Art des Wettbewerbsvorteils. Szenariotechnik (scenario technique) = Verfahren zur Gewinnung von Information über zukünftige Entwicklungen offener Systeme für die Formulierung von grundlegenden Konzepten wie Strategien und Teilstrategien (z. B. Sicherheitsstrategie). Teilstrategie (substrategy) = Strategie, die sich auf bestimmte Objekte, Eigenschaften, Ziele, Technologien oder auf Phasen des Technologieeinsatzes bezieht. Unternehmensstrategie (corporate strategy) = Strategie, die auf die Beantwortung der Frage gerichtet ist, was das Unternehmen in Zukunft aus welchen Gründen sein will. Wettbewerbsstrategie (competitive strategy) = Teilstrategie der Unternehmensstrategie, die festlegt, wie bei der Verfolgung strategischer Marktziele vorgegangen werden soll.

114

Strategische Aufgaben des Informationsmanagements

Zweck der IT-Strategie Nach Durchführung der Situationsanalyse (vgl. Lerneinheit SITAN) und der strategischen Zielplanung (vgl. Lerneinheit SZIEL) ist es die dritte Aufgabe der strategischen IT-Planung, die IT-Strategie zu entwickeln und (etwa jährlich) anzupassen bzw. fortzuschreiben und damit die Voraussetzung für eine rollierende strategische Maßnahmenplanung zu schaffen (vgl. Lerneinheit SPLAN). Dabei wird mit IT-Strategie das Konzept, die Perspektive oder die Art und Weise bezeichnet, in der die strategischen IT-Ziele verfolgt, das heißt in strategische Maßnahmen umgesetzt werden sollen. Sie enthält keine Details über diese Maßnahmen, sondern „gibt die Richtung an“, die bei der Verfolgung der Ziele eingeschlagen werden soll. Sie legt damit den Handlungsspielraum für die Entscheidungsträger fest, die für die strategische Maßnahmenplanung verantwortlich sind. Die IT-Strategie ist Teil der Unternehmensstrategie und Grundlage für das Ableiten von IT-Teilstrategien. Das Entwickeln der IT-Strategie wird also weder mit dem Setzen strategischer IT-Ziele, noch mit der Planung strategischer Maßnahmen gleichgesetzt, sondern – bildlich gesprochen – als Brücke oder Bindeglied zwischen beiden verstanden. Dies wirft die Frage nach dem Gegenstand der IT-Strategie auf, das heißt nach ihren Objekten, ihrem Charakter und ihrer Struktur, sowie danach, wie bei der Strategieentwicklung vorgegangen wird. Darüber hinaus stellt sich die Frage, welche formalen Merkmale die IT-Strategie haben soll (z. B. ihr inhaltlicher Umfang und ihre Gültigkeitsdauer). In der Fachliteratur werden für das hier als IT-Strategie bezeichnete Konzept unterschiedliche Bezeichnungen verwendet (z. B. Informationsstrategie, Informatikstrategie, IV-Strategie, IS-Strategie). Eine Diskussion über die Zweckmäßigkeit dieser Bezeichnungen zu führen bringt keinen Wissenszuwachs, so dass darauf verzichtet wird. Zu beachten ist, dass die Konzepte mit diesen Bezeichnungen – soweit sie diese überhaupt verdienen – nicht identisch sind; auch darauf wird nicht eingegangen. Die Bezeichnung IT-Strategie wird hier gewählt, weil sie in Wissenschaft und Praxis weit verbreitet und mit anderen in diesem Lehr- und Handbuch verwendeten Bezeichnungen konsistent ist.

Gegenstand der IT-Strategie IT-Strategien unterscheiden sich durch die Objekte, auf die sie sich beziehen, durch ihren Charakter und/oder durch ihre Struktur. Strategieobjekte sind die Komponenten der Informationsinfrastruktur (z. B. Datenstrukturen, Architekturen, Vorgehensmodelle als logische Komponenten, Hardware, Software, Personal als physische Komponenten) und wesentliche Eigenschaften der Infrastruktur (z. B. Outsourcing-Grad, Integrationsgrad, Verteilung), insbesondere Eigenschaften mit strategischem Zielcharakter (z. B. Wirksamkeit, Wirtschaftlichkeit, Sicherheit). Beim Strategiecharakter wird nach Szyperski zwischen MomentumStrategie, aggressiver Strategie, moderater Strategie und defensiver Strategie unterschieden. Der Charakter kann am Beginn des Prozesses der Strategieentwicklung festgelegt werden (was vorzuziehen ist, um den Entwicklungsprozess zu steuern), oder er wird lediglich zur Kennzeichnung des Entwicklungsergebnisses verwendet.

Strategieentwicklung (STRAT)

   

115

Die Momentum-Strategie ist dadurch gekennzeichnet, dass die bestehende Infrastruktur auch zukünftigen strategischen Zielen genügt. Grundlegende Änderungen des Istzustands sind in naher Zukunft nicht erforderlich; man kann sich abwartend verhalten. Die aggressive Strategie ist durch dadurch gekennzeichnet, als Technologieanwender „an der vordersten Front“ zu operieren und die Technologieentwicklung selbst vorantreiben zu wollen. Die moderate Strategie hat Merkmale der Momentum- und der aggressiven Strategie; sie ist durch Pilotprojekte auf Basis strategischer Situationsanalysen gekennzeichnet. Die defensive Strategie versucht, den Technologieeinfluss im Unternehmen zurückzudrängen; sie kann im Grenzfall destruktiv sein (destruktive Strategie).

Aus dem Strategiecharakter folgt die Notwendigkeit, dass die an der IT-Planung Beteiligten ihre Absichten offen legen, damit eine einheitliche Grundhaltung zur Gestaltung der IT erarbeitet werden kann. Dazu bedarf es der Abstimmung zwischen Organisationszielen (Unternehmensziele und IT-Ziele) und Individualzielen. Der Strategiecharakter kann mit ergänzenden oder alternativen Merkmalen gekennzeichnet werden (z. B. Umsetzbarkeit, Beständigkeit, Verständlichkeit). Die Strategiestruktur kann wie folgt sein: Im Mittelpunkt steht die Einsatzstrategie. Darum herum gruppieren sich Grundsätze in Form von organisatorischen, technischen, sozialen und rechtlichen Leitlinien. Die organisatorischen Leitlinien regeln die Aufgabendurchführung bei der Schaffung, Nutzung und Weiterentwicklung der Infrastruktur. Die technischen Leitlinien beinhalten Standards für die Beschaffung und Verwendung von IT-Mitteln. Die sozialen Leitlinien regeln das Zusammenwirken von Technologie und Mensch (als Individuum und als Gruppe). Die rechtlichen Leitlinien, die sich aus einschlägigen Rechtsnormen und der Rechtsprechung ergeben (z. B. Datenschutzrecht, Urheberrecht, Vertragsrecht, Basel II, KonTraG, vgl. Lerneinheiten GOVER, RECHT und VERMA), legen die rechtlichen Rahmenbedingungen der IT-Strategie fest. Sind die strategischen IT-Ziele gegeben, kann die Einsatzstrategie in eine Realisierungsstrategie umgeformt werden, auf der die strategische Maßnahmenplanung aufbaut (vgl. Lerneinheit SPLAN). Alle diese Überlegungen sind für die Strategieentwicklung unabhängig davon relevant, ob es sich um eine unternehmenseigene Infrastruktur handelt oder ob und für welche Komponenten Dienstleistungen externer Anbieter genutzt werden, insbesondere Infrastructure-as-a-Service (IaaS). Im Folgenden in immer von Infrastruktur die Rede, unabhängig davon, ob sie unternehmensspezifisch ist.

Wirkung der IT-Strategie Wirkung oder Auswirkung der IT-Strategie wird im Sinne von Wirksamkeit und Wirtschaftlichkeit interpretiert (vgl. Lerneinheit SZIEL). Wirksamkeit heißt hier, dass das Vorhandensein und die Beachtung einer IT-Strategie ein bestimmtes Handeln oder Nichthandeln bewirkt. Wirtschaftlichkeit heißt hier, dass der durch Handeln erzielbare Nutzen größer ist als die dadurch verursachten Kosten bzw. der durch Nichthandeln entgangene Nutzen kleiner ist als die vermiedenen Kosten. Im Folgenden werden Wirkungen der IT-Strategie genannt, deren Einfluss auf Wirksamkeit und/oder Wirtschaftlichkeit aus Erfahrung gegeben ist, aber nicht quantifiziert sind. Die verwendete Formulierung ist so zu verstehen, dass die genannten Wirkungen zwar grundsätzlich vorhanden sind, durch IT-Strategien aber verstärkt werden.

116

        

Strategische Aufgaben des Informationsmanagements

Wahrnehmen der strategischen IT-Verantwortung durch das Top-Management, Fokussieren der IT auf die Wettbewerbsfaktoren, die für Erfolg oder Misserfolg des Unternehmens entscheidend sind (kritische Wettbewerbsfaktoren), Schaffen von Erfolgspotenzial dort, wo es zur Erreichung der strategischen Unternehmensziele am wirksamsten genutzt werden kann, Verstärken des Agierens des Top-Managements gegenüber dem Reagieren, Entlasten des Top-Managements von IT-Entscheidungen auf der administrativen und vor allem auf der operativen Aufgabenebene, Bewusstmachen des strategischen Kontextes, in dem das IT-Management handelt, Schaffen der Rahmenbedingungen, unter denen das IT-Management selbstständig und eigenverantwortlich handeln kann (Handlungsspielraum), Vereinfachen von Entscheidungsprozessen und Reduzieren von Reibungsverlusten (insbesondere zwischen Top-Management und IT-Management) und Transparentmachen des Handelns des IT-Managements und Nachvollziehbarmachen seines Handelns für das Linienmanagement und die Benutzer.

Dies führt zu folgender These bezüglich Wirkung oder Auswirkung: Mit IT-Strategien kann das Zusammenwirken von IT-Bereich und Geschäftsprozessen so geregelt werden, dass das Handeln des IT-Managements auf den Unternehmenserfolg hin fokussiert wird und die ITRessourcen bestmöglich zur Erreichung der Unternehmensziele eingesetzt werden (BusinessIT-Alignment, vgl. Lerneinheit ERMOD). Technologien können nicht Wettbewerbsvorteile sichern bzw. schaffen, durch Technologien wird Innovationspotenzial generiert. Das Ausschöpfen dieses Potenzials erfordert Innovationsfähigkeit, insbesondere die Fähigkeit, neue Technologien effektiv und effizient einzusetzen. Dies kann nur durch bewusstes, unternehmensweites Innovationsmanagement erreicht werden. Das durch neue Technologien generierte Innovationspotenzial kann so mächtig sein, dass es die Unternehmensstrategie wesentlich beeinflusst. Dies kann dazu führen, dass nicht die Unternehmensstrategie die ITStrategie treibt, sondern die Unternehmensstrategie technologiegetrieben ist. Die IT-Strategie ist auch für das Top-Management verbindlich. Was das Top-Management mit der IT-Strategie aussagt, gilt als Grundlage für sein Handeln. Das IT-Management kann sich darauf verlassen und gegebenenfalls auch darauf berufen bzw. bestimmte Handlungen einfordern (z. B. die zur Realisierung der Maßnahmenplanung erforderlichen Budgets). Um diese Wirkung zu erzielen, muss die IT-Strategie von allen Beteiligten „verinnerlicht“ sein. Die damit geforderte Grundhaltung entspricht der beim Qualitätsmanagement geforderten Grundhaltung (vgl. Lerneinheit QUALM).

Entwickeln der IT-Strategie Eine systematische Vorgehensweise zum Entwickeln der IT-Strategie wird nach Heinrich/ Pomberger (1999) mit den in Abbildung STRAT-1 gezeigten Arbeitsschritten angegeben. Input für den Entwicklungsprozess sind die strategischen IT-Ziele und das IT-Leitbild. Erster Arbeitsschritt: Beim Generieren alternativer IT-Strategien wird von der Annahme ausgegangen, dass die Art und Weise, in der man von den strategischen Zielen zu den strategischen Maßnahmen gelangt, meist nicht eindeutig ist; es gibt alternative Strategien, mit

Strategieentwicklung (STRAT)

denen der Handlungsspielraum für die strategische Maßnahmenplanung festgelegt werden kann. Methodisch gesehen, handelt es sich bei diesem Arbeitsschritt primär um die Anwendung der Szenariotechnik (vgl. Lerneinheit SZENA), mit der die langfristige Entwicklung der Informationsfunktion und der Technologien sowie die Umsetzung der beiden Entwicklungen in Maßnahmen zur Verbesserung der IT untersucht werden. Alternative IT-Strategien unterscheiden sich nicht durch die verwendeten Attribute und in der Regel auch nicht durch den Grad der Detaillierung, sondern in erster Linie durch stark unterschiedliche Werte zu bestimmten Attributen (vgl. den Abschnitt Inhalt der ITStrategie).

117

Strategische IT-Ziele und IT-Leitbild Generieren alternativer IT-Strategien Evaluieren und Bestimmen der optimalen IT-Strategie Abstimmen mit der Unternehmensstrategie

Ableiten von Teilstrategien Zweiter Arbeitsschritt: Beim Evaluieren der generierten Strategien wird die optimale Strategie methodisch durch eine Nutzwertanalyse bestimmt (vgl. LernIT-Strategie einheit NUTZW). Um sie anwenden zu können, muss die Frage beantwortet werden, welches Zielsystem und welche Kriterien zum Evaluieren der Alternativen Abb. STRAT-1: Vorgehensweise beim Entwickeln der IT-Strategie verwendet werden sollen (vgl. Lerneinheit EVALU). Als Zielsystem bieten sich die strategischen Formalziele an (insbesondere Wirksamkeit und Wirtschaftlichkeit, vgl. Lerneinheit SZIEL), als Kriterien zum Evaluieren solche Messgrößen, die aus den strategischen Formalzielen abgeleitet und auf die Attribute der IT-Strategie bezogen sind (z. B. das Kriterium „Kosten der Systementwicklung“ bei Eigenfertigung oder Fremdbezug von Software oder SaaS = Software-as-a-Service). Der Evaluierungsprozess wird verkürzt, wenn für einzelne oder mehrere Attribute Normstrategien zur Verfügung stehen (z. B. für das Attribut Outsourcing), die bei Vorliegen bestimmter Ausprägungen von Evaluierungskriterien (z. B. hohe Unternehmensspezifität und große strategische Bedeutung der Anwendung) grundsätzlich empfehlenswert ist (z. B. kein Outsourcing, wenn Unternehmensspezifität hoch und strategische Bedeutung der Anwendung groß ist, vgl. Lerneinheit OUTSO).

Dritter Arbeitsschritt: Da die strategischen IT-Ziele mit den strategischen Unternehmenszielen bereits abgestimmt sind (vgl. Lerneinheit SZIEL), besteht grundsätzlich Verträglichkeit zwischen IT-Strategie und Unternehmensstrategie. Ein zusätzlicher Abgleich hat den Vorteil, dass neben den Zielen konkrete inhaltliche Aussagen in den Strategien auf Konsistenz überprüft werden können. Damit wird sichergestellt, dass die gewählte IT-Strategie die Unternehmensstrategie bestmöglich unterstützt und die Fachkonzepte für die Entwicklung neuer bzw. die Weiterentwicklung bestehender Infrastrukturkomponenten den Technologiekonzepten entsprechen. Im Vordergrund steht das Abstimmen der IT-Strategie mit der Wettbewerbsstrategie. Dafür wird das Branchenstrukturmodell nach Porter verwendet, das einen marktorientierten Strategieansatz verfolgt.

118

Strategische Aufgaben des Informationsmanagements

Wettbewerbsfeld enges weites

Grundlage des marktorientierten Strategieansatzes ist die Structure-Conduct-Performance-Hypothese, die behauptet, dass die Branchenstruktur (structure) das strategische Verhalten (conduct) und damit den Unternehmenserfolg (performance) bestimmt. Das danach so benannte Branchenstrukturmodell unterscheidet drei Typen von Wettbewerbsstrategien: Kostenführerschaft, Differenzierung (beides Basisstrategien) und Konzentration auf Schwerpunkte (Konzentrationsstrategie). Die Konzentrationsstrategie hat zwei Varianten, eine mit Schwerpunkt Kosten und eine mit Schwerpunkt Differenzierung. Abbildung STRAT-2 zeigt Typen von Wettbewerbsstrategien (Strategietypen) als Positionierungsmodell mit den Dimensionen Wettbewerbsfeld (oder Marktabdeckung) und Art des Wettbewerbsvorteils.

Typ I Kostenführerschaft

Typ II Differenzierung

Typ III a Kostenschwerpunkt

Typ III b Differenzierungsschwerpunkt

niedrige Kosten Differenzierung Wettbewerbsvorteile Abb. STRAT-2: Typen von Wettbewerbsstrategien (Quelle: nach Porter)

Kostenführerschaft Eine IT-Strategie, die einer Wettbewerbsstrategie vom Typ Kostenführerschaft folgt, muss auf die Förderung von IT-Investitionen ausgerichtet sein. Deren primäre Sachziele sind:   

Sie unterstützen das Identifizieren von Kosten (z. B. durch eine wirkungsvolle Kostenund Leistungsrechnung). Sie unterstützen das Vermeiden oder zumindest das Reduzieren von Kosten (z. B. von Lagerbestandskosten oder Bearbeitungskosten). Sie helfen, Ursachen von bestehenden Kostennachteilen und Quellen von möglichen Kostenvorteilen aufzudecken (z. B. zu lange bzw. kürzere Auftragsdurchlaufzeiten).

Eine IT-Strategie, die mit einer Wettbewerbsstrategie vom Typ Kostenführerschaft abgestimmt ist, zeichnet sich durch hohe Wirksamkeit bei allen Aufgaben aus, welche die Kosten der Produkte und Dienstleistungen des Unternehmens positiv beeinflussen, und sie muss sicherstellen, dass die IT selbst wirtschaftlich ist. Die IT-Strategie kann Kostenführerschaft nur dann unterstützen, wenn sie die Schaffung und Erhaltung einer im strategischen Gleich-

Strategieentwicklung (STRAT)

119

gewicht befindlichen Infrastruktur sicherstellt (vgl. Lerneinheit SITAN). Gerät sie aus dem strategischen Gleichgewicht, wirkt sich strategische Vergeudung (d. h. eine strategische Lücke bei der Wirksamkeit) weniger negativ auf den Unternehmenserfolg aus als strategische Verschwendung (d. h eine strategische Lücke bei der Wirtschaftlichkeit).

Differenzierung Eine IT-Strategie, die einer Wettbewerbsstrategie vom Typ Differenzierung folgt, muss auf die Förderung von IT-Investitionen ausgerichtet sein, deren primäres Sachziel es ist, das Unternehmen in der Branche so einmalig wie möglich zu machen. Ein Unternehmen, das Differenzierung betreibt, muss Differenzierungswege suchen und finden, die mit Differenzierungskosten realisiert werden können, die geringer sind als die erzielbaren Zusatzerlöse. Die Mittel der Differenzierung sind in jeder Branche andere. Differenzierung kann beispielsweise durch Produktionsprogramme bzw. Produkte selbst, aber auch durch Vertriebssysteme, Marketingkonzepte oder den Kundendienst erfolgen. Es gibt viele Ansatzpunkte, um die IT so auszurichten, dass sie die Umsetzung dieser Wettbewerbsstrategie unterstützt. Eine IT-Strategie, die mit einer Wettbewerbsstrategie vom Typ Differenzierung abgestimmt ist, zeichnet sich durch hohe Wirksamkeit bei allen Aufgaben aus, welche die Schaffung und Erhaltung einmaliger Unternehmensmerkmale unterstützen. Dies erfolgt am nachhaltigsten dann, wenn die IT-Strategie dazu beiträgt, eine Infrastruktur zu schaffen bzw. zu erhalten, die sich im strategischen Gleichgewicht befindet (vgl. Lerneinheit SITAN). Gerät sie aus dem strategischen Gleichgewicht, wirkt sich strategische Verschwendung (d. h eine strategische Lücke bei der Wirtschaftlichkeit) weniger negativ auf den Unternehmenserfolg aus als strategische Vergeudung (d. h eine strategische Lücke bei der Wirksamkeit).

Konzentrationsstrategien Konzentrationsstrategien orientieren sich an ausgewählten Marktsegmenten (enges Wettbewerbsfeld). Durch optimale Ausrichtung auf ein Wettbewerbsfeld versucht das Unternehmen, sich Wettbewerbsvorteile zu verschaffen. Beim Kostenschwerpunkt strebt das Unternehmen in seinem Wettbewerbsfeld einen Kostenvorteil an, beim Differenzierungsschwerpunkt ist es in seinem Wettbewerbsfeld darum bemüht, sich von den Mitbewerbern zu unterscheiden. Beide Varianten der Konzentrationsstrategie beruhen auf Unterschieden zwischen den Wettbewerbsfeldern, die von der Konzentrationsstrategie verfolgt werden, und anderen Wettbewerbsfeldern der Branche. In der Regel muss ein Unternehmen zwischen den Strategietypen wählen, oder es gerät „zwischen die Stühle“. Manchmal kann ein Unternehmen zwei weitgehend getrennte Unternehmenseinheiten schaffen, die jeweils einen anderen Strategietyp anwenden. Kostenführerschaft und Differenzierung widersprechen sich in der Regel, da Differenzierung meist kostspielig ist. Umgekehrt veranlasst Kostenführerschaft häufig dazu, durch Standardisierung der Produkte, Senkung der Gemeinkosten und ähnliches auf Differenzierung zu verzichten. Unter bestimmten Voraussetzungen kann ein Unternehmen jedoch Kostenführerschaft und Differenzierung gleichzeitig verfolgen (hybride Strategie). Es kann dann ganz besondere Erfolge verbuchen (z. B. dann, wenn es Bahn brechende technologische Innovationen verwirklicht).

120

Strategische Aufgaben des Informationsmanagements

IT-Teilstrategien Aus der IT-Strategie werden Teilstrategien abgeleitet. Dies ist deshalb zweckmäßig, weil die IT-Strategie die Art und Weise, in der die strategischen IT-Ziele verfolgt werden, in relativ grober Granularität angibt. Als Grundlage für die strategische Maßnahmenplanung reicht dies nicht aus. Zunächst ist die Frage zu klären, für welche Objekte (z. B. Kommunikationswege) bzw. für welche Eigenschaften (z. B. Outsourcing-Grad), zur Verfolgung welcher Ziele (z. B. Sicherheit) oder für welche Phasen des Technologieeinsatzes (z. B. Evaluierung) Teilstrategien entwickelt werden. In der Regel ist dies nicht für alle genannten Phänomene sinnvoll. Die Auswahl orientiert sich an deren strategischer Bedeutung für die Erreichung der Unternehmensziele (z. B. die des Internets als Vertriebsweg). Die Bedeutung verändert sich durch interne und externe Einflüsse (z. B. Veränderung der Produkte und Märkte, der verfügbaren und einsetzbaren Technologien), so dass unternehmensspezifisch und häufig auch situativ zu entscheiden ist, welche Teilstrategien entwickelt werden sollen. Eine typische, zielorientierte und in der Praxis häufig anzutreffende Teilstrategie ist die Sicherheitsstrategie, was auf die strategische Bedeutung der IT-Sicherheit hinweist (vgl. Lerneinheit SICHM). Diese Teilstrategie sollte auch Aussagen darüber enthalten, welcher Stellenwert dem Katastrophenmanagement (vgl. Lerneinheit NOMAN) beigemessen wird; dies kann auch Gegenstand einer Disaster-Recovery-Strategie sein. Beispiel dafür, dass neue Teilstrategien entstehen, ist die Verbreitung des Umweltbewusstseins im IT-Bereich (Green IT, Öko IT oder IT-Ökologie). Eine Umweltstrategie oder Nachhaltigkeitsstrategie macht Aussagen darüber, dass und in welcher grundsätzlichen Art und Weise bei der Nutzung und Veränderung der IT Ressourcen umweltfreundlich vorgegangen werden soll (vgl. Lerneinheit ERMOD). Teilstrategien, die sich an Phasen des Technologieeinsatzes orientieren, sind Innovationsstrategie (vgl. Lerneinheit TECHM), Evaluierungsstrategie (vgl. Lerneinheiten SPLAN und EVALU) oder Einsatzstrategie. Es kann auch zweckmäßig sein, Teilstrategien an innovativen Technologien oder Dienstleistungen auszurichten (z. B. Cloud Computing, vgl. Lerneinheit INMAN). Eine Internetstrategie oder eBusiness-Strategie macht Aussagen darüber, welche der bestehenden Geschäftsfelder an die Bedingungen des Digital Business angepasst bzw. unter Verwendung von Internettechnologien neu aufgebaut werden sollen. Zur Beantwortung der ersten Frage ist zu prüfen, ob bestehende Geschäftsmodelle so verändert werden können und auch sollen, dass durch das Innovationspotenzial von Internettechnologien bestehende Wettbewerbsvorteile gesichert bzw. neue geschaffen werden (business transformation). Beim Aufbau neuer Geschäftsfelder geht es um die Identifikation von vorhandenen Kernkompetenzen und diesen entsprechenden, innovativen Geschäftsmodellen zur Ausschöpfung des Innovationspotenzials (business creation). Bei der Entwicklung digitaler Geschäftsstrategien wird also ein ressourcenorientierter Ansatz verfolgt, der auf der Resources-Conduct-Performance-Hypothese beruht. Diese behauptet, dass für den Unternehmenserfolg primär die Überlegenheit im Vergleich zu den Mitbewerbern in der Verfügbarkeit und Nutzung von Ressourcen beruht (insbesondere, aber nicht nur Technologien). Eine grundsätzliche Ausrichtung der Teilstrategien unterscheidet zwischen Best-of-BreedStrategie und Single-Source-Strategie. Beispielsweise bedeutet bei der Softwarebeschaffung

Strategieentwicklung (STRAT)

121

die Verfolgung der Best-of-Breed-Strategie, die besten am IT-Markt verfügbaren Produkte für Teillösungen zu identifizieren, zu beschaffen und dann zu einer Gesamtlösung zu integrieren. Single-Source-Strategie heißt, die Anzahl der Partner zu minimieren und möglichst alle Softwareprodukte aus einer Hand zu beschaffen. Beide Strategien können für unterschiedliche Geschäftsfelder oder Betriebsmittel parallel verfolgt werden.

Inhalt der IT-Strategie Dieser kann aus ihrer Brückenfunktion zwischen den strategischen IT-Zielen und den strategischen Maßnahmen abgeleitet werden. Da beide Brückenpfeiler im konkreten Fall unterschiedlich ausgeprägt (z. B. mehr oder weniger detailliert) sein können, hängt der Inhalt der IT-Strategie von der Granularität der Formulierung der strategischen Ziele und vom Konzept der strategischen Maßnahmenplanung ab. Je mehr die strategischen Ziele ausgefeilt sind (insbesondere je mehr unterschiedliche Zielinhalte verwendet werden) und je feiner die strategische Maßnahmenplanung sein soll (insbesondere bezüglich der Auswahl und Beschaffung der IT-Komponenten), desto geringer ist der Spielraum für Strategieinhalte. Die im Folgenden genannten Objekte, Eigenschaften und Ziele (Strategieattribute) veranschaulichen die mögliche Vielfalt des Strategieinhalts.                  

Regeln für das Business-IT-Alignment sowie Art und Umfang der Benutzerbeteiligung, Gestaltung der Arbeitsorganisation (funktionsorientiert vs. prozessorientiert, deterministisch vs. individualisiert, Kooperationskonzept vs. Autarkiekonzept), Art und Umfang des Outsourcings (Auslagerung bzw. Ausgliederung) sowie der Nutzung externer IT-Dienstleistungen (wie IaaS, SaaS oder PaaS), Beschaffung und Verwendung von Standardsoftware bzw. Entwicklung und Verwendung von Individualsoftware, zulässige Betriebssysteme und Programmiersprachen, Verteilung der IT-Kompetenzen, IT-Ressourcen und IT-Betriebsmittel (Zentralisierung/Dezentralisierung), Ausmaß der Vernetzung von Hardware- und Softwarekomponenten (Komplexität), Integration (innerbetriebliche und zwischenbetriebliche), Institutionalisierung (zentrale und dezentrale IT-Institutionen) sowie deren Organisation und Führung (Ausschüsse, Arbeitskreise, Abteilungen, Projekte), Vorgehensmodelle, Methoden- und Werkzeugverwendung sowie Verwendung von Standards und Normen, Meta- und Multiprojektmanagement (einschließlich Projektorganisation), Kriterien zur Reihung von Projekten im Projektportfolio (Portfoliomanagement), Abgrenzung strategischer Projekte von sonstigen Projekten, maximaler Projektumfang und maximale Projektdauer, Anforderungen an personelle Aufgabenträger (wie IT-Manager, Produktmanager, Projektleiter, IT-Koordinatoren in den Fachabteilungen, IT-Controller), Zielvorgaben für Dienstleistungen, die für die Abwicklung der Geschäftsprozesse kritisch sind (Serviceebenen-Vereinbarungen), Erfassung von Leistungen und Verrechnung von Kosten, Budgetierung und Finanzplanung,

122

   

Strategische Aufgaben des Informationsmanagements

Revision und Controlling, Qualität und Qualitätsmanagement, Sicherheit und Sicherheitsmanagement sowie Umweltbewusstsein und Nachhaltigkeit.

Der Umfang, in dem der Strategieinhalt dokumentiert wird, ist im Allgemeinen nicht groß; einige Seiten im DIN A4-Format können als Orientierungsgröße angenommen werden. Daraus darf nicht geschlossen werden, dass der Zeitaufwand für die Strategieentwicklung gering ist. Meist ist das Gegenteil der Fall, weil die wenigen Kernaussagen nur auf breiter Grundlage und unter Beteiligung des Top-Managements, repräsentativer Führungskräfte des Linienmanagements und des IT-Managements erarbeitet werden können.

Forschungsbefunde Son/Gladyszewski berichten, dass auf die Frage, ob es im Unternehmen eine schriftlich dokumentierte IT-Strategie gibt (14), „60 % positiv antworteten“. (Zur Quelle und zur Untersuchungsmethode siehe Lerneinheit CONTR.) Heinrich/Pomberger (2001) berichten über Ergebnisse der wissenschaftlichen Begleituntersuchung von Projekten der Strategieentwicklung (sieben Fallstudien mit Aktionsforschung, Untersuchungszeitraum 1995-2000) u. a. Folgendes:    

Personalaufwand zwischen 120 und 283 Personenstunden, davon 45 bis 108 unternehmensintern, 75 bis 175 extern (andere Aufwandsarten vernachlässigbar gering), Anzahl der Strategieobjekte zwischen elf und 22, Dokumentationsumfang je Strategieobjekt rd. eine Seite, insgesamt zwischen 18 und 46 Seiten im Format DIN A4, Entwicklungsdauer zwischen einem Monat und fünf Monaten.

Bezüglich des Strategiecharakters wird eine Differenzierung in aggressive, moderate und defensive Strategie empfohlen: Eine aggressive Strategie ist primär durch Führerschaft beim Technologieeinsatz gekennzeichnet ist (im Wesentlichen mit der nach Szyperski identisch). Eine moderate Strategie ist primär durch Nachahmung gekennzeichnet; man wartet die Erfahrung der Technologienutzung der Mitbewerber ab, wenn sie positiv ist, folgt man so schnell wie möglich. Eine defensive Strategie ist primär durch Anwendung von Standardlösungen gekennzeichnet; auf eine von Mitbewerbern explizit abweichende Strategie wird verzichtet. Heinrich/Pomberger/Thonabauer haben das von Heinrich/Pomberger (1999) entwickelte Vorgehensmodell an die Bedingungen des Digital Business angepasst und erprobt (Fallstudie in einem Unternehmen des Bankensektors, Entwicklungs- und Untersuchungszeitraum 5/2000 bis 9/2000). Dabei wurde von der Annahme ausgegangen, dass im Digital Business Technologien ihre Rolle als Enabler von Geschäftsmodellen verändern und zum Treiber werden. Für die Entwicklung der eBusiness-Strategie folgte daraus, dass strategische Unternehmensziele und Unternehmensstrategie nicht dokumentiert vorliegen können, so dass ein interaktiver Entwicklungsprozess von eBusiness-Strategie und Unternehmensstrategie einschließlich strategischer Zielplanung erforderlich war.

Strategieentwicklung (STRAT)

123

Oh/Pinsonneault haben aus einer empirischen Studie (schriftliche Befragung von 347 KMU der Industrie in Kanada, Rücklaufquote 32 % je Unternehmen vom CEO und CIO beantwortete Fragebögen, Erhebungszeitraum nicht angegeben, vermutlich 2006) folgende „managerial implications“ bezüglich Business-IT-Alignment (IT alignment bzw. business alignment) abgeleitet (259): „The empirical findings indicate that IT alignment with a cost reduction strategy generates more immediate and tangible benefits for firms than IT-strategy alignment that aims to facilitate revenue growth. Our findings also suggest the extracting benefits from strategic IS resources designed to help firms grow is more difficult than extracting benefits from operational IT resources developed to cut costs. Therefore, additional attention is necessary to successfully plan and implement growth-oriented IT systems.” Beimborn/Franke berichten zum Business-IT-Alignment (schriftliche Befragung von 1.020 Prozesseignern von KMU-Kreditprozessen in deutschen Kreditinstituten auf Basis von fünf Fallstudien, Rücklaufquote 23,6 %, Erhebungszeitraum nicht angegeben, vermutlich 2006) folgende Antworten zur Frage „Ist die IT-Strategie mit der Geschäftsstrategie abgestimmt“: trifft voll zu 6,6 %, trifft eher zu 16,2 %, indifferent 27,2 %, trifft eher nicht zu 14,7, trifft nicht zu 8,1 %, weiß nicht 27,2 %. Nach einer Studie der Trigonum Consulting zum gleichen Thema (schriftliche Befragung von 281 „IT-Verantwortlichen“ deutscher Unternehmen, Jahresumsatz größer 100 Mio., Erhebungszeitraum 2008) beantworten nur 31 % die Frage „Wie eng sind Ihrer Ansicht nach die Unternehmens- mit der IT-Strategie verzahnt“ mit sehr eng (13 %) oder eng (18 %), mit mittelmäßig 41 %, gering 21 % und gar nicht 7 %. Die Frage, „Wie angemessen sind die organisatorischen Strukturen für eine enge Zusammenarbeit zwischen Business und IT“? beantworteten 24 % mit sehr funktionsfähig, 39 % begrenzt funktionsfähig und 37 % mit unzureichend. Als ein Fazit der Studie sind „fehlende organisatorische Strukturen“ als zentrale Ursache für das geringe Business-IT-Alignment.

Aus der Praxis Die Schweizerische Mobiliar Versicherungsgesellschaft Bern „... hat eine in die Unternehmensstrategie integrierte Informatikstrategie formuliert; der Umsetzung dieser Strategie dient die Unternehmensarchitektur.“ Für diese Umsetzung wird ein IT-Architekt mit folgendem Aufgabenprofil gesucht: Erarbeiten, Kommunizieren und Umsetzen von Standards; Definieren der Systemarchitektur innerhalb strategischer IT-Projekte; Erarbeiten von Lösungen zur Systemintegration; Mitwirkung bei der Gestaltung der Business-, Applikations- und Technologiearchitektur sowie Initialisieren, Begleiten und Implementieren der Architekturen. (F.A.Z. vom 3.12.2005, V37) Nach einer Studie von Ernst & Young (Befragung von 100 IT-Managern in Schweizer Unternehmen, je Unternehmen 50 Interviews, und schriftliche Befragungen, Erhebungszeitraum März/April 2002) war „ … bei 26 % der Unternehmen keine schriftlich dokumentierte ITStrategie auszumachen.“ Weit über dem Durchschnitt lagen die Branchen Technologie mit 35 % und Handel mit 45 %. Die A. T. Kearney, nach eigenen Angaben „eines der weltweit größten Top-ManagementBeratungsunternehmen“, definiert ihren Beratungsschwerpunkt Entwicklung der IT-Strategie so: „Die IT-Strategie nutzt die neuesten Technologieinnovationen, um die übergreifende Geschäftsstrategie umzusetzen. Unsere IT-Strategie-Expertise reicht von der Entwicklung

124

Strategische Aufgaben des Informationsmanagements

der zukünftigen Anwendungslandschaft, Definition der Infrastrukturarchitektur bis hin zur Festlegung der IT-Kernkompetenzen zur Vorbereitung von Make-or-Buy-Entscheidungen. Wir unterstützen unsere Klienten dabei, grundlegende Verbesserungen der IT zu erzielen, wie beispielsweise die Stärkung der Beziehungen zwischen den Geschäftsführern und der ITOrganisation sowie die Ausbildung und die Führung des IT-Nachwuchses.“ Keines der dazu auf der Website genannten „Projektbeispiele“ ist für Strategieentwicklung einschlägig. Kommentar: Diese Beobachtung stützt die Annahme, dass der Praxis systematische Vorgehensweisen zum Entwickeln der IT-Strategie, die seit Jahrzehnten in der Fachliteratur publiziert werden, nicht bekannt sind. Methodenverweise Evaluierungsmethoden (Lerneinheit EVALU); Nutzwertanalyse (Lerneinheit NUTZW); Vorgehensmodelle (Lerneinheit VOMOD), Szenariotechnik (Lerneinheit SZENA). Fallstudienverweis Lerneinheit FINST der 8. Auflage 2005 dieses Lehr- und Handbuchs zeigt an einem praktischen Beispiel die Vorgehensweise bei der Strategieentwicklung. Kontrollfragen 1. Mit welchen Arbeitsschritten kann der Prozess der Strategieentwicklung erklärt werden? 2. Mit welchen alternativen Merkmalen kann der Charakter einer IT-Strategie beschrieben werden? 3. Was sind typische Inhalte einer IT-Strategie und wie werden sie identifiziert? 4. Wodurch unterscheiden sich Best-of-Breed-Strategie und Single-Source-Strategie? 5. Ist eine eBusiness-Strategie Teilstrategie der IT-Strategie oder ist eine Alternative der IT-Strategie? Quellen A. T. Kearney: http://www.atkearney.de/content/servicekompetenz/sitp_main.php/sub/strategy; Abruf 4.4.2011 Beimborn, D. / Franke, J.: IT-Business Alignment und der Wertbeitrag der IT. In: IM – Information Management & Consulting 1/2007, 74–79 Ernst & Young (Hrsg.): IT-Kosten und IT-Performance 2002 – Betriebswirtschaftliche Studie der Schweizer Informatikabteilungen. Bern 2002 Heinrich, L. J. / Pomberger, G.: Entwickeln von Informatik-Strategien. In: Lausen, G. / Oberweis, A. / Schlageter, G. (Hrsg.): Angewandte Informatik und Formale Beschreibungsverfahren. Stuttgart/Leipzig 1999, 108–127 Heinrich, L. J. / Pomberger, G.: Erfolgsfaktorenanalyse – Instrument für das strategische IT-Controlling. In: HMD – Praxis der Wirtschaftsinformatik 217/2001, 19–28 Heinrich, L. J. / Pomberger, G. / Thonabauer, C.: Entwickeln von EB/EC-Strategien. In: HMD – Praxis der Wirtschaftsinformatik 221/2001, 87–93 Oh, W. / Pinsonneault, A.: The Assessment of the strategic Value of Information Technologies – Conceptual and analytical Approaches. In: MIS Quarterly 2/2007, 239-265 Porter, M. E.: Wettbewerbsstrategie. 10. A., Frankfurt a. M. 1999 Szyperski, N.: Geplante Antwort der Unternehmung auf den informations- und kommunikationstechnischen Wandel. In: Frese, E. / Schmitz, P. / Szyperski, N. (Hrsg.): Organisation, Planung, Informationssysteme. Stuttgart 1981, 177–195 Trigonum Consulting: Unternehmens- und IT-Strategien leben aneinander vorbei. http://www.trigonum.de/artikel; Abruf 12.11.2008 Vertiefungsliteratur Bernhard, M. G. / Blomer, R. / Bonn, J. (Hrsg.): Strategisches IT-Management Bd. 2. Düsseldorf 2003 Leemhuis, J. P.: Using Scenarios to Develop Strategies. In: Long Range Planning 2/1985, 30–37 Melville, N. / Kraemer, K. / Gurbaxani, V.: Information Technology and Organizational Performance – An integrative Model of IT Business Value. In: MIS Quarterly 2/2004, 283–322 Porter, M. E.: Wettbewerbsvorteile. 7. A., Frankfurt a. M. 2000 Informationsmaterial Diebold Management Report 7/1999 und 7+8/2000 BMWi: http://www.bmwi.de/BMWi/Navigation/technologie-und-innovation,did=367546.html

Maßnahmenplanung (SPLAN) Lernziele Sie kennen den Zweck der strategischen Maßnahmenplanung, können ihre Aufgabe in Teilaufgaben gliedern und diese zu einer Vorgehensweise ordnen. Sie können Konzepte zum Evaluieren von Projektideen erläutern und ihre Anwendbarkeit beurteilen. Sie kennen Kriterien, mit denen die Evaluierung erfolgen kann. Sie kennen Randbedingungen, Einflussgrößen und Grundsätze der strategischen Maßnahmenplanung und können die Organisation des Planungsprozesses erläutern.

Definitionen und Abkürzungen Anpassbarkeit (adaptivity) = Eigenschaft eines Systems, auf qualitative und quantitative Änderungen der Anforderungen ohne grundlegende Veränderung reagieren zu können. Bestandsmanagement (inventory management) = Erfassung und bewusste Verwendung der im Unternehmen vorhandenen IT-Ressourcen (insbesondere Betriebsmittel). Entwicklungsrückstau (application backlog) = nicht abgearbeitete Aufgaben der Systementwicklung, deren Erledigung die Anforderungen der Geschäftsprozesse erfordern. Synonym: Anwendungsrückstau. Informationssystemplan (information system plan) = Teil des strategischen IT-Plans, der die Absichten zur Veränderung bestehender und zur Schaffung neuer Informationssysteme beschreibt. Innovationsfähigkeit (innovation ability) = Fähigkeit, Nutzenpotenziale neuer Technologien erkennen und in Kombination mit Änderungen der Informationsfunktion und/oder der Informationsinfrastruktur in Unternehmenserfolg umzusetzen. Kreativitätstechnik (creativity technique) = Heuristik zur Problemdefinition und zum Problemlösen sowie zum Entwerfen von Alternativen in Situationen, die durch schlecht strukturierte Probleme und eine offene Entscheidungssituation gekennzeichnet sind. Leitstrategie (key strategy) = Strategie, die unter den Rahmenbedingungen der betrachteten Szenarien erfolgreich verfolgt werden kann. Risiko (risk) = Kombination aus zu erwartender Häufigkeit bzw. Eintrittswahrscheinlichkeit eines gefährdenden Ereignisses und dem beim Ereigniseintritt zu erwartenden Schadensausmaß. strategische Lücke (strategic gap) = negative Abweichung der Ausprägung einer Eigenschaft der Informationsinfrastruktur oder das Fehlen einer Komponente, wodurch die Erreichung der strategischen IT-Ziele negativ beeinflusst wird. strategischer IT-Plan (strategic IT plan) = Ergebnis der strategischen Maßnahmenplanung. Synonym: strategisches Projektportfolio. strategischer Technologieeinsatzplan (strategic technology action plan) = Teil des strategischen IT-Plans, der die Absichten über Art, Umfang, Zeitpunkte und Zeiträume des Technologieeinsatzes beschreibt.

126

Strategische Aufgaben des Informationsmanagements

Zweck der strategischen Maßnahmenplanung Vierte Aufgabe der strategischen IT-Planung ist es, den strategischen IT-Plan für die unternehmensweite, langfristige und die Wettbewerbsposition positiv beeinflussende Gestaltung der IT zu erarbeiten. Dabei wird vom Ergebnis der strategischen Situationsanalyse (vgl. Lerneinheit SITAN) und der strategischen Zielplanung (vgl. Lerneinheit SZIEL) unter Berücksichtigung der IT-Strategie (vgl. Lerneinheit STRAT) ausgegangen. Die Maßnahmen zur Erreichung der strategischen IT-Ziele im Rahmen der IT-Strategie, also die strategischen Maßnahmen zur Gestaltung der Informationsinfrastruktur, werden entwickelt. Die Maßnahmenplanung geht vom dafür bereitgestellten Budget aus (vgl. Lerneinheit STRAT), das gegebenenfalls in Abhängigkeit vom Ergebnis der Maßnahmenplanung angepasst wird. Mit der strategischen Maßnahmenplanung wird der Aktionsspielraum für die Umsetzung des Leistungspotenzials in Erfolgspotenzial (vgl. Lerneinheit ERMOD) und letztlich in Unternehmenserfolg geschaffen. Leistungspotenzial kann nur dann in Erfolgspotenzial und schließlich in Unternehmenserfolg umgesetzt werden, wenn Innovationsfähigkeit vorhanden ist bzw. entwickelt wird; den Unternehmenserfolg entscheidend bestimmend ist daher eine innovationsfreundliche Unternehmenskultur. Die Umsetzung des Leistungspotenzials in Erfolgspotenzial geschieht durch Handlungen des IT-Managements auf der administrativen Aufgabenebene. Im Zusammenhang mit der Maßnahmenplanung meint strategisch nicht nur einen relativ langen Zeithorizont (etwa drei bis fünf Jahre) und einen großen Aufgabenumfang (das Unternehmen als Ganzes oder zumindest wesentliche Unternehmensteile betreffend), sondern auch eine hohe Wettbewerbswirksamkeit, also die Planung von Maßnahmen, deren Realisierung die IT in die Lage versetzen wird, den Unternehmenserfolg mehr als im Istzustand positiv zu beeinflussen und damit den Wertbeitrag der IT zu erhöhen.

Ergebnis der strategischen Maßnahmenplanung Ergebnis der Maßnahmenplanung ist der strategische IT-Plan, der aus mehreren Teilplänen besteht. Jeder Teilplan nimmt konkreten Bezug auf strategisch bedeutsame Objekte oder Eigenschaften der IT. Als Ergebnis der Analyse der Informationsinfrastruktur (vgl. Lerneinheit SITAN) können strategische Lücken bei bestimmten Objekten und/oder Eigenschaften aufgedeckt worden sein, die zu strategischen Teilplänen im Rahmen der strategischen Maßnahmenplanung führen. Bezüglich der Objekte sollten folgende Teilpläne erarbeitet werden:      

Technologieeinsatzplan / Objekt: Informations- und Kommunikationstechnologien, Informationssystemplan / Objekt: Informationssysteme, Organisationsplan / Objekt: IT-Organisation (Struktur- und Ablauforganisation), Personalplan / Objekt: IT-Personal, Datenplan / Objekt: Datensystem und Methodenplan / Objekt: Methodensystem.

Im Allgemeinen steht die Erarbeitung der beiden zuerst genannten Teilpläne im Vordergrund; die strategischen Pläne der anderen Objekte sind in den Technologieeinsatzplan und den Informationssystemplan eingebettet. Bezüglich der Eigenschaften sind Teilpläne für Auslagerung, Verteilung oder Nachhaltigkeit, bezüglich der Ziele Teilpläne für Sicherheit

Maßnahmenplanung (SPLAN)

127

oder Wirtschaftlichkeit typisch. Zweckmäßigerweise folgt die Systematik der Teilpläne der Gliederung der Strategie in Teilstrategien (vgl. Lerneinheit STRAT). Mit den an Teilstrategien orientierten Teilplänen soll die für die Strategieentwicklung typische ganzheitliche Betrachtung für die strategische Maßnahmenplanung wirksam werden. So kann beispielsweise mit der expliziten Teilplanung der Eigenschaft Nachhaltigkeit vermieden werden, sich auf einzelne Objekte (z. B. Rechenzentrum) und einzelne Ziele (z. B. Energieeffizienz) zu konzentrieren, andere Objekte und Ziele aber zu übersehen (z. B. Feinstaubbelastung durch Tonerpartikel am Benutzerarbeitsplatz, Recycling für Tonerkartuschen). Inhalt des strategischen IT-Plans sind die in geeigneter Weise geordneten Projekte zur langfristigen, unternehmensweit wirksamen, die kritischen Wettbewerbsfaktoren positiv beeinflussenden Veränderung der IT. Diese auf ökonomischen Kriterien beruhende Projektauswahl und Projektordnung wird als Portfoliomanagement bezeichnet. Ergebnis dieser Managementaufgabe ist der strategische IT-Plan bzw. das strategische Projektportfolio. Was „in geeigneter Weise geordnet“ konkret heißt, hängt von den strategischen Unternehmenszielen ab. Grundsätzlich wird davon ausgegangen, dass die Projekte nach ihrem Beitrag zum Unternehmenserfolg (oder andere Bezeichnungen wie Geschäftswert) geordnet werden. Wegen der schwierigen Messbarkeit dieses Projektbeitrags (Wertbegriff) werden Ordnungskriterien mit geringen Messproblemen verwendet (vgl. den Abschnitt Evaluieren der generierten Projektideen). Im Einzelfall reichen der Praxis leicht messbare Ordnungskriterien aus (z. B. Realisierungszeitraum). Methodisch anspruchsvolle Vorgehensweisen wie AHP = Analytic Hierarchy Process (vgl. Lerneinheit NUTZW) werden als zu aufwendig angesehen. Ist die Entwicklung neuer bzw. die wesentliche Veränderung bestehender Informationssysteme Projektgegenstand, erfolgt die Projektabwicklung auf der administrativen Ebene in der bekannten Form der Systementwicklung (Analyse, Entwurf und Implementierung). Ist die Beschaffung von Technologien und anderen Komponenten der Informationsinfrastruktur Projektgegenstand, erfolgt die Veränderung durch Investitionen in die Infrastruktur, ohne zunächst neue Informationssysteme zu entwickeln bzw. bestehende wesentlich zu verändern; dies wird als Infrastrukturentwicklung bezeichnet. Die strategische Maßnahmenplanung besteht also aus den beiden Planungsbereichen Systementwicklung und Infrastrukturentwicklung. Nachfolgend werden ihre Besonderheiten erläutert, die bei der später dargestellten Vorgehensweise der strategischen Maßnahmenplanung zu beachten sind.

Strategische Systementwicklung Aufgaben der strategischen Systementwicklung sind:    

Analysieren und Evaluieren des vorhandenen Bestands an Informationssystemen, Analysieren und Evaluieren des Entwicklungsrückstaus, Identifizieren von Informationssystemen, durch deren Veränderung bzw. Schaffung kritische Wettbewerbsfaktoren positiv beeinflusst werden können, und Analysieren und Evaluieren von Projektideen, Vergeben von Prioritäten für die Projektrealisierung und Controlling der Systementwicklung.

Die beiden zuerst genannten Aufgaben sind Teil des Bestandsmanagements. Das Analysieren und Evaluieren des Entwicklungsrückstaus setzt voraus, dass alle nicht befriedigten Ent-

128

Strategische Aufgaben des Informationsmanagements

wicklungsbedarfe laufend erfasst, mit geeigneten Kriterien beschrieben und dokumentiert werden (z. B. geschätzter Realisierungsaufwand, erwarteter Beitrag zum Unternehmenserfolg, Verweildauer im Entwicklungsrückstau, Gründe für die Nichtfreigabe). Einfache Kriterien (z. B. Anzahl der offenen, noch nicht begonnenen, und Anzahl der angearbeiteten Projekte) reichen zur Beurteilung des Entwicklungsrückstaus nicht aus. In weiter gehenden Analysen können dynamische Kriterien (z. B. Zufluss in das und Abfluss aus dem Projektportfolio nach Art und Umfang der Projekte) im Zeitvergleich zweckmäßig sein.

Strategische Infrastrukturentwicklung Eine schlagkräftige IT lässt sich wegen der isolierten Sichtweise einzelner Informationssysteme über den Weg der Systementwicklung allein nicht realisieren. Schlagkräftig heißt, dass die IT mindestens folgende Eigenschaften hat (vgl. auch Lerneinheit SZIEL):  

Sie kann eine bedarfsgerechte Unterstützung aller betrieblichen Aufgaben bzw. aller Geschäftsprozesse sichern (keine Überversorgung und keine Unterversorgung) und ist effektiv (Wirksamkeit). Sie kann die Aufgabenunterstützung besser sichern als andere Alternativen der Informationsinfrastruktur und ist effizient (Wirtschaftlichkeit).

Die Schaffung bzw. Veränderung der IT im Wege der Systementwicklung geht im Allgemeinen vom nachfrageorientierten Ansatz aus. Nachfrageorientiert heißt, dass ein Unterstützungsbedarf und damit ein Bedarf an Informationssystemen vorhanden ist, der von den Bedarfsträgern (d. h. vom Linienmanagement bzw. von den Benutzern ausgehend und durch das Linienmanagement) artikuliert wird (Bedarfspotenzial). Ist kein Bedarfspotenzial vorhanden und/oder wird von den Bedarfsträgern kein Bedarf artikuliert, kommt es entweder zu keinem Projekt, oder die Projektplanung wird vom Lenkungsausschuss verworfen, weil sie einer projektbezogenen Wirtschaftlichkeitsanalyse nicht standhalten kann. Die strategische Infrastrukturentwicklung geht vom angebotsorientierten Ansatz aus. Angebotsorientiert heißt, einen potenziellen, vom IT-Management möglicherweise nur vermuteten Unterstützungsbedarf zu wecken (IT-Management als Innovator, vgl. Lerneinheit STELL), von dem angenommen wird, dass seine Deckung einen positiven Beitrag zum Unternehmenserfolg liefert. Strategische Systementwicklung und strategische Infrastrukturentwicklung sind keine Alternativen, sondern ergänzen sich. Durch strategische Maßnahmenplanung sollen nachfrageorientierter und angebotsorientierter Ansatz so kombiniert verwendet werden, dass die strategischen IT-Ziele erreicht werden. Dies kann auch zu einer Korrektur der Zielplanung durch Erhöhung der Sollwerte einzelner Ziele führen.

Vorgehensweise bei der Maßnahmenplanung Es ist zweckmäßig, die Gesamtaufgabe der strategischen Maßnahmenplanung – für beide Planungsbereiche – in Teilaufgaben zu gliedern, mit denen eine Vorgehensweise angegeben werden kann. Diese empfiehlt eine bestimmte Reihenfolge bei der Abarbeitung der Teilaufgaben zur Erfüllung der Gesamtaufgabe sowie Methoden zur Unterstützung der Aufgabenerfüllung. Die Empfehlung kann nicht als richtig oder falsch, sondern nur als zweckmäßig beurteilt werden, weil sie erfahrungsgemäß erfolgreich ist.

Maßnahmenplanung (SPLAN)

129

Folgende Teilaufgaben sind zur Erfüllung der Gesamtaufgabe erforderlich:    

Feststellen strategischer Lücken (Lückenanalyse), Generieren von Projektideen zum Schließen strategischer Lücken, Durchführen der Projektplanung (Machbarkeitsstudie) und Evaluieren der generierten Projektideen einschließlich Projektauswahl.

Eine Verfeinerung der Vorgehensweise erfolgt zunächst durch Zerlegung der Teilaufgaben (z. B. Zerlegung der Machbarkeitsstudie in Phasen), weiter durch Auswahl und Zuordnung spezifischer Methoden zu den Aufgaben (z. B. Risikoanalyse zur Entwicklung von Sicherheitskonzepten, vgl. Lerneinheit SIKON). Sind alternative Methoden verfügbar (z. B. für die Wirtschaftlichkeitsanalyse bei der Evaluierung der Projektideen, vgl. Lerneinheit WIRTA), sollten Kriterien angegeben werden, nach denen die Methodenauswahl systematisch erfolgt (z. B. Aufwand, Zeitbedarf, Genauigkeit, vgl. Lerneinheit EVALU). Abbildung SPLAN-1 zeigt die Teilaufgaben der Maßnahmenplanung und ihre Ordnung als Vorgehensweise. 





Zweck der ersten Teilaufgabe ist es, die Ergebnisse IT-Strategie der strategischen Situationsanalyse (vgl. Lerneinheit strategische IT-Ziele SITAN) so aufzuarbeiten, dass strategische Lücken so klar erkannt werden, dass Projektideen zu ihrer Feststellen Schließung generiert werden können. Ein schlagkräfstrategischer Lücken tiges Controlling (vgl. Lerneinheit CONTR) kann zur Identifikation strategischer Lücken beitragen. Generieren von Projektideen Zweck der zweiten Teilaufgabe ist es, Projektideen für strategische Lücken zur Schließung strategischer Lücken zu generieren, und zwar auf breitester Basis unter Mitwirkung des Durchführen Linienmanagements und der Mitarbeiter der Fachabder Projektplanung teilungen bzw. Geschäftsprozesse, deren Aufgaben durch strategische Lücken betroffen sind (vgl. Evaluieren der Lerneinheiten TECHM und PERSM). Dabei ist es generierten Projektideen zweckmäßig, alternative Projektideen für jede Wertschöpfungsaktivität zu formulieren, die einen Einfluss auf kritische Wettbewerbsfaktoren hat. Diese Strategisches Teilaufgabe kann methodisch mit verschiedenen ArProjektportfolio ten der Kreativitätstechnik unterstützt werden (z. B. Mind Mapping, Morphologischer Kasten). Die gene- Abb. SPLAN-1: Vorgehensweise bei der Maßnahmenplanung rierten Projektideen werden daraufhin überprüft, ob sie mit den strategischen IT-Zielen und mit der IT-Strategie vereinbar sind; wenn nein, werden sie nicht weiter verfolgt. Auch zur Bearbeitung der zweiten Teilaufgabe ist das Controlling gefordert. Zweck der dritten Teilaufgabe ist es, die mit der Realisierung der Projektideen verbundenen Konsequenzen bezüglich Zeit (Zeitpunkte und Zeiträume), Budget, Personal, Methoden, Werkzeuge und sonstige Ressourcen zu ermitteln; damit werden die Voraussetzungen für eine realistische Evaluierung geschaffen.

130



Strategische Aufgaben des Informationsmanagements

Zweck der vierten Teilaufgabe ist es, mit einem aussagefähigen, mit den strategischen IT-Zielen abgestimmten System von Ordnungskriterien eine vergleichende Evaluierung der Projektideen durchzuführen, unterlegene alternative Projektideen auszuscheiden, die verbleibenden Projektideen als IT-Projekte in das strategische Projektportfolio einzuordnen (Projektpriorisierung) und ihnen Budgets und Ressourcen zuzuordnen.

Eine in der Praxis bewährte Institution für die strategische Maßnahmenplanung ist der Lenkungsausschuss (vgl. Lerneinheit STRUK).

Evaluieren der Projektideen Im Mittelpunkt der Vorgehensweise steht die Lösung des Evaluierungsproblems. Seine Besonderheit im Kontext der strategischen Maßnahmenplanung besteht in der Beantwortung der Frage, welche Evaluierungskriterien verwendet werden. Dabei besteht im Allgemeinen folgendes methodische Dilemma: Zwar sollen die Projektideen als Voraussetzung für die Evaluierung aus Zeit- und Kostengründen nicht detailliert ausgearbeitet werden, doch erfordert eine seriöse Evaluierung eine gewisse Detailliertheit und Genauigkeit. Bei Projekten der Systementwicklung besteht der Kompromiss darin, eine Machbarkeitsstudie durchzuführen. Bei Direktinvestitionen in die Infrastruktur sind diese aber ebenfalls erforderlich, um eine Evaluierungsgrundlage zu schaffen. Das Durchführen von Machbarkeitsstudien muss in beiden Fällen Teil der strategischen Maßnahmenplanung sein. Bei der Generierung von Evaluierungskriterien wird in Anlehnung an Parker/Benson von der Kosten-Nutzen-Analyse (KNA) ausgegangen, die primär zur Ermittlung der Wirtschaftlichkeit dient (vgl. Lerneinheit WIRTA). Die KNA wird durch eine Evaluierung ergänzt, die neun Kriterien verwendet, mit denen primär die Wirksamkeit der Projektideen und das mit ihrer Realisierung verbundene Risiko erfasst werden. Fünf der neun Evaluierungskriterien sind der Informationsfunktion (Business Domain), vier sind der IT-Infrastruktur (Technology Domain) zugeordnet. Die Evaluierungskriterien der Business Domain (BD) sind: 





BD-Evaluierungskriterium 1: Strategischer Abgleich (strategic match). Es wird der Beitrag der Projektidee zur Erreichung der strategischen Unternehmensziele bzw. Ziele der durch die Projektidee angesprochenen Geschäftsfelder erfasst. Die Anwendung dieses Kriteriums setzt eine strategische Zielplanung voraus, damit alle an der Evaluierung Beteiligten ein gemeinsames Verständnis über die strategischen Ziele. Abweichende Beurteilungen werden so lange verhandelt, bis eine Übereinstimmung der Urteile erreicht ist. BD-Evaluierungskriterium 2: Wettbewerbsvorteil (competitive advantage). Es wird der Beitrag der Projektidee zur Unterstützung der Wettbewerbsstrategie erfasst. Der Beurteilungsmechanismus ist unterschiedlich, je nachdem, welche Wettbewerbsstrategie verfolgt wird (vgl. Lerneinheit STRAT). Wird Kostenführerschaft verfolgt, werden alle Beiträge der Projektidee zur Erkennung, Vermeidung oder Reduzierung von Kosten erfasst. Wird Differenzierung verfolgt, werden alle Beiträge der Projektidee erfasst, welche die Einmaligkeit der Marktleistungen verbessern helfen. Bei der Verfolgung von Konzentrationsstrategien muss jedes strategische Geschäftsfeld die Beiträge der Projektidee zur Unterstützung der jeweils geltenden Wettbewerbsstrategie herausarbeiten. BD-Evaluierungskriterium 3: Führungsinformation (management information). Es wird der Beitrag der Projektidee zur Unterstützung der Unternehmensführung bzw. der Füh-

Maßnahmenplanung (SPLAN)





131

rung einzelner Geschäftsfelder in ihren Kernaufgaben in den Bereichen strategische Planung, Überwachung und Steuerung erfasst. Welches die Kernaufgaben sind, muss von den durch die Projektidee angesprochenen Führungskräften beantwortet werden. BD-Evaluierungskriterium 4: Wettbewerbsschaden (competitive response). Es wird der Schaden erfasst, der durch Mitbewerber droht, wenn die Projektidee nicht realisiert wird. Ein Wettbewerbsschaden kann entstehen, wenn wichtige Mitbewerber bereits die gleiche oder eine ähnliche Projektidee realisiert haben oder in Kürze realisieren werden, oder wenn die Realisierung dieser Idee bereits zum Standard in der Branche gehört. BD-Evaluierungskriterium 5: Projektrisiko (project or organizational risk). Es wird das organisatorische Risiko der Projektrealisierung erfasst. Dabei werden primär Einflussgrößen betrachtet, die im Einflussbereich der zukünftigen Benutzer liegen, wie Fähigkeit und Bereitschaft zu organisatorischem Wandel sowie Unterstützung durch das Management für den organisatorischen Wandel. BD 5 ist ein negativer Einflussfaktor.

Die Evaluierungskriterien der Technology Domain (TD) sind: 







TD-Evaluierungskriterium 1: Strategische IT-Architektur (strategic IS architecture). Es wird erfasst, ob sich die Projektidee in die bestehende IT-Architektur einfügen lässt bzw. inwieweit sie den strategischen Zielen über deren Veränderung (wie sie in der ITStrategie festgelegt sein kann) entspricht (vgl. Lerneinheiten ARCHI und STRAT). TD-Evaluierungskriterium 2: Begriffliche Ungewissheit (definitional uncertainty). Es wird das Risiko erfasst, das mit der Ungewissheit über die Anforderungen und/oder die Spezifikationen der durch die Projektidee angesprochenen Technologien verbunden ist. TD 2 ist (wie BD 5) ein negativer Einflussfaktor. TD-Evaluierungskriterium 3: Technische Ungewissheit (technical uncertainty). Es wird die Fähigkeit und Bereitschaft der IT-Mitarbeiter erfasst, die Projektidee umzusetzen. Beurteilt werden Faktoren wie Qualifikation, Innovationsfähigkeit, Kreativität. TD 3 ist (wie TD 2 und BD 5) ein negativer Einflussfaktor. TD-Evaluierungskriterium 4: Infrastrukturrisiko (IS infrastructure risk). Es wird das Risiko von projektbedingten Veränderungen der bestehenden Infrastruktur erfasst, insbesondere von solchen Veränderungen, die zusätzliche Investitionen erfordern. TD 4 ist (wie TD 2, TD 3 und BD 5) ein negativer Einflussfaktor.

Portfoliomanagement Die Klarheit der Formulierung von Evaluierungskriterien, die dem Objekt Projektideen angemessen sind, darf nicht darüber hinwegtäuschen, dass die Ermittlung der Kriterienerträge, ihre Skalierung und Zusammenfassung zum Gesamtnutzen durch eine brauchbare Entscheidungsregel problematisch sind (vgl. Lerneinheit NUTZW). Wegen der methodischen Schwierigkeit der Nutzenbestimmung werden häufig einfache Evaluierungsverfahren angewendet, bei denen nur die Abschätzung weniger (meist zwei), aber strategisch bedeutsamer Einflussfaktoren erfolgt. Beispiele dafür sind die strategische Bedeutung der Projektidee, das Ausmaß der Unterstützung kritischer Wettbewerbsfaktoren, der Grad der Realisierbarkeit, das Projektrisiko und eine grob geschätzte Wirtschaftlichkeit. Dabei wird nur – wie bei Systemgrids üblich – zwischen zwei oder drei Ausprägungen der beiden Einflussfaktoren unterschieden (vgl. Lerneinheit SZENA). Durch parallele Verwendung mehrerer Paare von Ein-

132

Strategische Aufgaben des Informationsmanagements

stark



A

A

C

mittel



A = Projektideen, die auf jeden Fall realisiert werden sollen (MussProjekte). B = Projektideen, deren Zweckmäßigkeit näher zu untersuchen ist (wobei nach dem Verfahren der Nutzwertanalyse vorgegangen wird). C = Projektideen, die bis zur Verbesserung der Realisierbarkeit aufgeschoben werden.

A

B

C

schwach



Unterstützung kritischer Wettbewerbsfaktoren

flussfaktoren (z. B. Geschäftswert / Projektrisiko und Unterstützung kritischer Wettbewerbsfaktoren / Realisierbarkeit) entstehen verschiedene Sichten auf das Projektportfolio, was zu mehr Information für die Entscheidung zur Ordnung der Projektideen im Projektportfolio führt. Abbildung SPLAN-2 zeigt die Verwendung der Einflussfaktoren „Unterstützung kritischer Wettbewerbsfaktoren“ und „Realisierbarkeit“ zur Einordnung der Projektideen in drei Projektklassen A, B und C wie folgt:

B B C Trotz seiner strategischen Reichweite ist ein Projektportfolio nicht statisch, so dass eine periodische (z. B. jährliche) hoch mittel gering Überarbeitung und Anpassung erforderRealisierba rkeit lich sind. In großen Unternehmen ist eine Abb. SPLAN-2: Strategische Evaluierung der Differenzierung des Portfolios notwendig Projektideen (Quelle: nach IBM) (z. B. nach Geschäftsfeldern). Das auf Unternehmensebene erarbeitete Portfolio und die auf Geschäftsfeldebene erarbeiteten Portfolios lassen sowohl Gemeinsamkeiten als auch Unterschiede erkennen, was Ausgangspunkt für eine unternehmensweite Konzentration der Ressourcen sein kann. Spezifische Portfolios sind auch für Projektideen angebracht, die sehr innovativ sind und deren Realisierung mit einem hohen Risiko verbunden sein kann (vgl. Lerneinheit TECHM).

Serafeimidis/Smithson halten diese und ähnliche Vorgehensweisen der Evaluierung mit ihrem formalen und positivistischen Charakter für nicht ausreichend, da sie den „social and organizational dimensions“ der Information Systems Evaluation nicht entsprechen. Insbesondere wird es als Mangel angesehen, dass die organisatorische Rolle der Schlüsselpersonen (key stakeholders) im Kontext der Evaluation nicht ausreichend berücksichtigt wird (z. B. die der potenziellen Technologienutzer in den Geschäftsprozessen). Die Autoren empfehlen deren personelle und organisatorische Integration in den Prozess der Evaluation und nennen dafür kritische Erfolgsfaktoren. Die in Abbildung SPLAN-3 gezeigten vier Orientierungen der Evaluation, im Sprachgebrauch des Informationsmanagements als Evaluierungsansätze zu bezeichnen, werden definiert. Die in Wissenschaft und Praxis übliche Vorgehensweise entspricht im Wesentlichen der Orientierung Control für den gesamten Evaluationsprozess; andere Orientierungen werden erfahrungsgemäß nicht oder nicht ausreichend wahrgenommen und praktiziert. Dies gilt insbesondere für die Orientierung Social learning (vgl. jedoch den Forschungsbefund der genannten Autoren).

Maßnahmenplanung (SPLAN)

133 Impact on organization of information systems

Perception of Objectives

Consensus/ Clarity Noconsensus/ Ambiguity

Tactical

Strategic

Control

Social learning

Sense-making

Exploratory

Abb. SPLAN-3: Evaluierungsansätze (Quelle: Serafeimidis/Smithson)

Abstimmung mit der Unternehmensplanung Beim Setzen der strategischen IT-Ziele und beim Entwickeln der IT-Strategie (vgl. Lerneinheiten SZIEL und STRAT) erfolgte eine Abstimmung mit den strategischen Unternehmenszielen bzw. mit der Unternehmensstrategie. Es kann daher Vereinbarkeit des Ergebnisses der strategischen IT-Planung mit dem der strategischen Unternehmensplanung angenommen werden. Trotzdem sollte das Projektportfolio daraufhin überprüft werden, ob sich die geplanten strategischen Maßnahmen mit denen anderer Planungsbereiche des Unternehmens (z. B. Produktion, Logistik, Vertrieb) in Übereinstimmung befinden. Wenn nicht, müssen Projekte verändert bzw. muss zur zweiten Teilaufgabe der Maßnahmenplanung (d. h. zum Generieren von Projektideen) zurückgekehrt werden. Wird eine aggressive IT-Strategie verfolgt (vgl. Lerneinheit STRAT), führt dies auch zu Veränderungen in anderen Planungsbereichen. Wird zur Entwicklung oder Überprüfung der IT-Strategie mit der Szenariotechnik gearbeitet (vgl. Lerneinheit SZENA), sollten die strategischen Projekte und ihre Ordnung im Projektportfolio auf Übereinstimmung mit der Leitstrategie überprüft werden. Dazu sind Entscheidungsalternativen herauszuarbeiten (z. B. alternative Projektordnungen im Projektportfolio), deren Konsequenzen in die Leitstrategie projiziert werden. Gesucht wird die Alternative, die unter Berücksichtigung der beiden Szenarien, die der Leitstrategie zugrunde liegen, gleich gut passt und eine relativ geringe Anfälligkeit gegenüber Störereignissen hat. Für alle vier Planungsbereiche der strategischen IT-Planung, in besonderem Maße jedoch für die strategische Maßnahmenplanung, gelten die folgenden Aussagen, welche die Notwendigkeit einer flexiblen Planung begründen, ihre Einflussfaktoren angeben und daraus Grundsätze einer flexiblen Planung ableiten (nach Dernbach).

Flexibilität der strategischen IT-Planung Der Unternehmenserfolg ist vom Zusammenwirken einer Reihe von Faktoren abhängig; die IT ist nur einer dieser Faktoren. Ihr Einfluss auf den Unternehmenserfolg wird nicht durch sie allein bestimmt, sondern auch durch das Vorhandensein bestimmter Ausprägungen anderer Faktoren. Beispielsweise setzt die wirksame und wirtschaftliche Nutzung neuer Technologien bestimmte Qualifikationen und Verhaltensweisen beim Linienmanagement und den Benutzern ebenso voraus wie bestimmte struktur- und ablauforganisatorische Gegebenheiten. Die Abhängigkeit des Unternehmenserfolgs von der Wirksamkeit und Wirtschaftlichkeit der

134

Strategische Aufgaben des Informationsmanagements

IT erfordert deren ständige Anpassung an sich ändernde Marktbedingungen und an die Technologieentwicklung; dies führt zur Forderung nach Anpassbarkeit der strategischen ITPlanung. Das heißt, dass die Planung so ausgerichtet sein muss, dass die erforderliche Infrastruktur zu dem Zeitpunkt zur Verfügung steht, an dem der Bedarf nach veränderten oder neuen Komponenten oder Eigenschaften auftritt. Die rechtzeitige Bedarfserkennung muss von der strategischen Planung geleistet werden, wobei ein Planungsvorlauf von mehreren Jahren erforderlich sein kann. Der relativ lange Planungsvorlauf und der Mangel an geeigneten Vorgehensweisen zur Unterstützung der Bedarfsvorhersage bergen erhebliche Risiken. Ziel einer flexiblen Planung ist die möglichst schnelle Anpassung der IT an veränderte Marktbedingungen und an die Technologieentwicklung, durch die das Erfolgspotenzial positiv beeinflusst werden kann (vgl. dazu die Ausführungen zum strategischen IT-Ziel Anpassungsstreben in Lerneinheit SZIEL). Idealer Weise sollten Änderungen der Marktbedingungen und der Technologien anhand von Indikatoren erkannt werden, bevor sie eingetreten sind (Früherkennung). Flexible Maßnahmenplanung ist durch folgende Faktoren gekennzeichnet:    

Vorliegen der strategischen Unternehmensziele und der Unternehmensstrategie, Kenntnis des Technologie-, Methoden- und Werkzeugangebots zur Implementierung der Maßnahmenplanung sowie deren Weiterentwicklung, Entwicklung und Anwendung eines wirkungsvollen Planungsinstrumentariums und Verfügbarkeit von Vergleichsgrößen zur Beurteilung alternativer strategischer Pläne.

Fehlt eine IT-Strategie als Grundlage der strategischen Maßnahmenplanung, kann sich diese lediglich auf Annahmen stützen, die sich aus der Abschätzung zukünftiger Technologieanwendungen ergeben; der gezielte Aufbau und die Verbesserung der Informationsinfrastruktur sind so nicht möglich. Zu geringe Kenntnis über die Technologieentwicklung kann zu einem übermäßig langen Festhalten an bewährten Technologien führen und das Verlieren bestehender oder das Nichtschaffen neuer Wettbewerbsvorteile zur Folge haben. Zu späte und sprunghafte Anpassungen führen häufig zu teuren Umstellungen (vgl. die Aussagen zum technologischen Korridor in Lerneinheit TECHM). Ein wirkungsvolles Instrumentarium der strategischen Maßnahmenplanung steht nur in Ansätzen zur Verfügung. Damit hängt die Qualität der Planungsergebnisse von der Qualifikation und dem Verhalten einzelner Personen wie CIO und IT-Controller ab, insbesondere von deren Kreativität und Durchsetzungskraft. Vergleichsgrößen sollen die Beurteilung von Planungsalternativen ermöglichen (Competitive Benchmarking, vgl. Lerneinheit MEGPM). Als Kennzahlen formulierte Vergleichsgrößen helfen, Stärken und Schwächen der Planungsergebnisse zu identifizieren und Anpassungen vorzunehmen (vgl. Lerneinheit KENNZ).

Grundsätze flexibler Maßnahmenplanung Die Grundsätze werden aus den Faktoren einer flexiblen Maßnahmenplanung abgeleitet. 

Erster Grundsatz: Einbetten der strategischen IT-Planung in die strategische Unternehmensplanung. So wie die strategischen IT-Ziele und die IT-Strategie nur als integrale Bestandteile der strategischen Unternehmensziele bzw. der Unternehmensstrategie denkbar sind, ist die strategische Maßnahmenplanung nur als integraler Bestandteil der

Maßnahmenplanung (SPLAN)





 



135

strategischen Unternehmensplanung sinnvoll. Die strategischen IT-Ziele sind Teilziele, die IT-Strategie ist Teilstrategie und die strategische Maßnahmenplanung der IT ist Teilplanung der strategischen Unternehmensplanung. Zweiter Grundsatz: Rollierendes Überprüfen und Fortschreiben der strategischen ITPlanung. Die IT-Planung muss sich an ändernde Rahmenbedingungen anpassen. Deshalb ist eine rollierende Planung erforderlich. Sie umfasst die strategische Planung, welche die langfristigen Weichenstellungen permanent aktualisiert, und eine kurz- bis mittelfristige Planung mit einem Planungshorizont von bis zu drei Jahren, die den strategischen IT-Plan in kurz- bis mittelfristige Pläne umsetzt. Dritter Grundsatz: Rechtzeitiges Umsetzen von Technologieentwicklungen. Die strategische IT-Planung muss absehbare Technologieentwicklungen in Pläne umsetzen und für die notwendigen Implementierungen sorgen, bevor ein „Leidensdruck“ bei den Anwendern entsteht. Sie soll also innovativ sein, auch auf die Gefahr hin, dass Widerstände bei den Anwendern überwunden werden müssen (angebotsorientierte Planung). Vierter Grundsatz: Vergleichen der Planungsergebnisse mit Alternativen. Orientierung dafür können andere, in der Technologienutzung erfolgreiche Unternehmen der gleichen Branche oder Vergleichsgrößen in Form überbetrieblicher Kennzahlen sein. Fünfter Grundsatz: Anwenden eines Planungsinstrumentariums. Da ein geschlossenes Planungsinstrumentariums nicht zu Verfügung steht, sollen IT-Management und Linienmanagement Regeln vereinbaren, um den Ablauf des Planungsprozesses zu organisieren und die dafür einzusetzenden Methoden und Werkzeuge festzulegen. Sechster Grundsatz: Berücksichtigen der bestehenden IT-Architektur bzw. ihrer durch strategische Zielplanung und Strategieentwicklung gewollten Veränderung, um Maßnahmen zu vermeiden, die zu Inkonsistenzen oder Redundanzen führen.

Forschungsbefunde Wehrmann/Heinrich/Seifert beschreiben einen ihrer Auffassung nach methodisch fundierten Ansatz des Portfoliomanagements, bei dem besonderer Wert auf die Operationalisierung gelegt wird und der die Schwächen bestehender Ansätze bezüglich Praxistauglichkeit vermeiden soll. Sie verdeutlichen anhand eines Fallbeispiels, dass „das Verfahren“ in der Praxis eingesetzt und die Inputgrößen mit vertretbarem Aufwand erhoben werden können. Serafeimidis/Smithson haben das Auftreten der vier Evaluierungsansätze für das Portfoliomanagement (vgl. Abbildung SPLAN-3) empirisch untersucht (Fallstudie, semistrukturierte, offene Interviews mit Vertretern der Schlüsselpersonen der Evaluation aller Managementebenen, Untersuchungszeitraum Ende der 1990er Jahre). Alle vier Ansätze konnten beobachtet werden, jeder in einem spezifischen Kontext des Evaluationsprozesses.

Aus der Praxis Hagel/Brown sind der Meinung, dass kleinere, „eher kurzfristig orientierte IT-Projekte effektiver sind als groß angelegte „Big-Bang-Initiativen“. Abgesehen vom geringeren Risiko dieser Vorgehensweise führt die engere zeitliche Rückkopplung zu einer Beschleunigung des organisatorischen Lernprozesses und damit zum beschleunigten Aufbau der Innovationsfähigkeit (zitiert nach Bodendorf/Bobra-Bissantz/Bauer).

136

Strategische Aufgaben des Informationsmanagements

Müller-Zantop formuliert auf Grund von Erfahrungen im Beratungsgeschäft folgende These: „Eines ist sicher: Der strategische IT-Fünfjahresplan ist tot.“ Sie relativiert dies mit der Anmerkung, dass erfolgreiche IT-Manager ihr Augenmerk auf einen Planungsprozess legen, mit dem die Pläne regelmäßig fortgeschrieben werden (rollierende Planung). In jeder Phase der Planfortschreibung sollte der Beitrag der Maßnahmen zur Wertschöpfung beurteilt werden. Carr behauptet, dass die Möglichkeit, durch IT strategische Vorteile zu gewinnen, rapide schwindet. Davon ausgehend fasst er eigene Beobachtungen und empirische Befunde, über die in der Literatur berichtet wird, zu der Feststellung zusammen: „… many companies will want to take a hard look at how they invest in IT and manage their systems.“ Um damit zu beginnen, sollten drei Grundsätze, die er als „new rules for IT management“ bezeichnet, beachtet werden: Spend less; follow, don´t lead; focus on vulnerabilities, not opportunities. Methodenverweise Kennzahlensysteme (Lerneinheit KENNZ); Wirtschaftlichkeitsanalyse (Lerneinheit WIRTA); Nutzwertanalyse (Lerneinheit NUTZW); Evaluationsmethoden (Lerneinheit EVALU); Szenariotechnik (Lerneinheit SZENA). Kontrollfragen 1. Welche Aufgabe hat die strategische Maßnahmenplanung und in welche Teilaufgaben wird sie gegliedert? 2. Wie wird bei der strategischen Maßnahmenplanung methodisch vorgegangen? 3. Warum ist die Verwendung von Evaluierungskriterien der Business Domain und der Technology Domain mit den Kernaussagen des IM-Modells konsistent? 4. Welchen Einfluss haben Art und Umfang des Entwicklungsrückstaus auf die Maßnahmenplanung? 5. Wie wird die Forderung nach Flexibilität der Maßnahmenplanung begründet und aus welchen Erkenntnissen werden Planungsgrundsätze abgeleitet? Quellen Bodendorf, F. / Bobra-Bissantz, S. / Bauer, C.: There´s more to IT – vom Innovationspotenzial zur Innovationsfähigkeit. In: HMD – Praxis der Wirtschaftsinformatik 239/2004, 7–17 Carr, N. G.: IT Doesn't Matter. In: Harvard Business Review 5/ 2003, 41–49 Dernbach, W.: Grundsätze einer flexiblen Infrastruktur. In: Strunz, H. (Hrsg.): Planung in der Datenverarbeitung – Von der DV-Planung zum Informations-Management. Berlin et al. 1985, 82–97 IBM Deutschland GmbH (Hrsg.): Der strategische Einsatz von Informationssystemen. In: IBM Nachrichten 290/1987, 66–70 Müller-Zantop, S.: Wo liegt der Wert der Informationsverarbeitung? In: F.A.Z. vom 17.3.1998, B 6 Parker, M. M. / Benson, R.: Information Economics - Linking Business Performance to Information Technology. Englewood Cliffs/NJ 1988 Serafeimidis, V. / Smithson, S.: Information systems evaluation as an organizational institution – experience form a case study. In: Information Systems Journal 2003, 251–274 Wehrmann, A. / Heinrich, B. / Seifert, F.: Quantitatives IT-Portfoliomanagement. In: WIRTSCHAFTSINFORMATIK 4/2006, 234–245 Vertiefungsliteratur Martin, J. with Leben, J.: Strategic Information Planning Methodologies. 2. Ed., Englewood Cliffs/NJ 1989 Reibnitz, U. von: Szenariotechnik. Instrumente für die unternehmerische und persönliche Erfolgsplanung. 2. A., Wiesbaden 1992 Walter, S. G. / Spitta, T.: Approaches to the Ex-ante Evaluation of Investments into Information Systems. In: WIRTSCHAFTSINFORMATIK 3/2004, 171–180 Wehrmann, A. / Zimmermann, St.: Integrierte Ex-ante-Rendite-/Risikobewertung von IT-Investitionen. In: WIRTSCHAFTSINFORMATIK 4/2005, 247–257

Strukturmanagement (STRUK) Lernziele Sie kennen die Notwendigkeit einer ganzheitlichen Betrachtung und Gestaltung der IMAufgaben. Sie kennen Aufgabenanalyse und Aufgabensynthese als Methoden der Gestaltung der Strukturorganisation sowie strukturorganisatorische Gestaltungsprinzipien. Sie können verschiedene strukturorganisatorische Konzepte beurteilen und ihre Weiterentwicklung nachvollziehen. Sie kennen die strukturorganisatorischen Konsequenzen, die mit der Verlagerung von IM-Aufgaben in die Fachabteilungen verbunden sind.

Definitionen und Abkürzungen Abteilung (department) = größere Einheit der Strukturorganisation, in der mehrere Stellen zusammengefasst sind. Aufgabenanalyse (task analysis) = Zerlegen von Aufgaben in Teilaufgaben und dieser in Tätigkeiten zwecks Bestimmung des Möglichkeitsraums der Arbeitsteilung. Aufgabensynthese (task synthesis) = Zusammenfassen von Teilmengen des durch Aufgabenanalyse ermittelten Möglichkeitsraums der Arbeitsteilung zu Aufgaben. CEO = Chief Executive Officer. CIO = Chief Information Officer. Investment Center = ergebnisverantwortliche Struktureinheit, deren Leistungen marktfähig sind und die über IT-Investitionen entscheiden kann. IT-Abteilung (IT department) = Struktureinheit, der administrative und operative Aufgaben des Informationsmanagements zugeordnet sind und die als Kostenstelle, Profit Center oder Investment Center geführt wird. Kompetenz (competence) = Handlungsspielraum eines Aufgabenträgers, der zur ordnungsgemäßen Aufgabenerfüllung erforderlich ist. Koordination (coordination) = Abstimmung der Tätigkeiten mehrerer Aufgabenträger, zwischen denen Interdependenz besteht. Lenkungsausschuss (steering committee) = Gremium, das Aufgaben der strategischen ITPlanung wahrnimmt (z. B. über IT-Investitionen entscheidet). Prinzip (principle) = Regel oder Richtschnur für Denken, Handeln und/oder Verhalten; eine empfehlenswerte, in der Praxis bewährte Handlungsanweisung. Synonym: Grundsatz. Profit Center = ergebnisverantwortliche Struktureinheit, deren Leistungen marktfähig sind. Stab (staff position) = Struktureinheit (Abteilung oder Stelle) zur spezialisierten Aufgabenerfüllung mit einer unterstützenden Funktion für Führungs- oder Leitungsstellen. Stelle (position) = kleinste Einheit der Strukturorganisation, der bestimmte Aufgaben, Kompetenzen, Sachmittel und Aufgabenträger zugeordnet sind. Struktureinheit (organizational unit) = Strukturelement einer Organisation, unabhängig von Aufgabenumfang (z. B. sowohl Stelle als auch Abteilung) und Aufgabenart (z. B. sowohl Leitungs- als auch Ausführungsaufgabe). Synonyme: Organisationseinheit, Instanz. Verteilung (distribution) = Zuordnen von Aufgaben und Sachmitteln auf Struktureinheiten unter besonderer Berücksichtigung ihrer Zentralisierung bzw. Dezentralisierung.

138

Strategische Aufgaben des Informationsmanagements

Zweck des Strukturmanagements Zweck des Strukturmanagements ist, Aufgaben, Kompetenzen und Ressourcen von Informationsfunktion und Informationsinfrastruktur (IT-Aufgaben) im Unternehmen (innerorganisatorisch) und zwischen mehreren Unternehmen (intraorganisatorisch) zu gestalten. Die Gestaltung orientiert sich am Zielsystem (vgl. Lerneinheit SZIEL). Ergebnis ist die Strukturorganisation des IT-Bereichs, die zielkonformes Handeln der an der Aufgabenerfüllung Beteiligten ermöglicht und den Handlungsspielraum für die Gestaltung der Ablauforganisation schafft. Neben allgemeinen strukturorganisatorischen Fragen der Gliederung des IT-Bereichs in Struktureinheiten sind weitere Gestaltungsfragen von Bedeutung, insbesondere:    

Zentralisierung bzw. Dezentralisierung (Verteilung) von Aufgaben, Kompetenzen und Ressourcen zum Erzielen von Synergieeffekten und Autonomievorteilen. Einbindung von Aufgaben, Kompetenzen und Ressourcen in bestehende Struktureinheiten außerhalb des IT-Bereichs (z. B. des Personalmanagements in die Struktureinheit Personalwesen, vgl. Lerneinheit PERSM)). Auslagerung von Aufgaben, Kompetenzen und Ressourcen mit Zwischenformen (z. B. Gründung von Tochtergesellschaften, zwischenbetriebliche Kooperationen) zwecks Ausnutzung zwischenbetrieblicher Spezialisierungsvorteile (vgl. Lerneinheit OUTSO). Errichtung einer Führungsorganisation durch Bestellung eines CIO zwecks ganzheitlicher und strategischer Fokussierung des IT-Bereichs (vgl. Lerneinheit STELL).

Davon abzugrenzen sind temporäre Strukturen, insbesondere die verschiedenen Formen der Projektorganisation, die nach dem Grad der organisatorischen Herauslösung aus dem operativen Tagesgeschäft wie folgt unterschieden werden: (1) Einfluss- oder Stabsprojektorganisation, (2) reine oder unabhängige Projektorganisation, (3) Matrix-Projektorganisation und (4) Projektorganisation in Verbindung mit Linieninstanzen. Bei der Wahl der Projektorganisation spielen eine Reihe spezifischer Evaluierungskriterien eine Rolle wie Umfang und Komplexität der Projektaufgabe, Unsicherheit der Zielerreichung, Termindruck und Relevanz der Projektleiterpersönlichkeit. Die Erfahrung zeigt, dass bei einem großen Projektumfang die Eignung der Einfluss-Projektorganisation gering, die der Matrix-Projektorganisation groß und die der reinen Projektorganisation sehr groß ist. Bei mittleren und großen Unternehmen hat sich die Matrix-Projektorganisation am stärksten durchgesetzt. (Zur Vorgehensweise bei der Wahl der Projektorganisation vgl. Lerneinheit NUTZW.) Temporäre Strukturen tragen zur Verbesserung der Qualität der Aufgabenerfüllung und zur Aktivierung der Beteiligung der Fachbereiche bei. Zukünftige Benutzer werden in die Systementwicklung so einbezogen, dass sie – bei ausreichender Berücksichtigung der von ihnen eingebrachten sozialen Ziele – die Erreichung der technischen und ökonomischen Entwicklungsziele unterstützen. Zweckmäßig ist daher ein partizipatives Vorgehen, welches das wesentliche Merkmal des Führungskonzepts Management by Objectives ist (Führen durch Zielvereinbarung). Im operativen Tagesgeschäft heißt Benutzerbeteiligung insbesondere Mitwirkung bei der Vorbereitung von Beschaffungsentscheidungen sowie bei der Aufarbeitung von Benutzungsproblemen. Benutzerbeteiligung setzt eine aufgabenadäquate Qualifizierung der Benutzer voraus (vgl. Lerneinheit PERSM).

Strukturmanagement (STRUK)

139

Aufgaben des Strukturmanagements Strukturorganisation, auch als Aufbauorganisation bezeichnet, ist das Ergebnis der Bildung funktionsfähiger Teileinheiten eines Unternehmens (Struktureinheiten). Da diese untereinander durch vielfältige Beziehungen zur Aufgabenerfüllung verknüpft sind, ist die Regelung der Koordination zwischen ihnen ebenso Aufgabe des Strukturmanagements wie die Einrichtung und Besetzung von einschlägigen Institutionen (z. B. IT-Lenkungsausschuss, ITAbteilung, Leitung IT-Projekte). Die Gliederung der IT-Abteilung erfolgt meist funktional (z. B. in die Struktureinheiten Leitung, Entwicklung, Produktion, Helpdesk). Statt der funktionalen ist eine objektorientierte Gliederung (z. B. nach Art der Informationssysteme) oder prozessorientierte Gliederung nach den IT-Kernprozessen sinnvoll. Kernprozesse sind u. a. Betrieb und Betreuung von Informationssystemen, Kundenakquisition und Angebotserstellung, auftragsgebundener Projektdienst (z. B. Systementwicklung, Customizing von Standardprodukten) und Infrastrukturdienst (z. B. Bereitstellung von Netzdiensten). In der Organisationslehre ist der gesamte Leistungsprozess eines Unternehmens Gestaltungsgegenstand. Für das Informationsmanagement ist der Teil des Leistungsprozesses Gestaltungsgegenstand, der die Informations- und Kommunikationsaufgaben umfasst, also die Informationsfunktion, sowie die Aufgaben der Produktion, Verbreitung und Nutzung von Information als Produktionsfaktor, also die Informationsinfrastruktur (IM-Aufgaben). Idealtypisch gesehen sind alle Aufgaben der Informationsfunktion und der Informationsinfrastruktur IM-Aufgaben (vgl. Lerneinheit ERMOD). In der Praxis sind sie meist auf die Informationsinfrastruktur begrenzt, umfassen also selten die einschlägigen Aufgaben in den Struktureinheiten des Linienmanagements (z. B. die Aufgaben der Fachabteilungen bei der Ermittlung des Technologiebedarfs, vgl. Lerneinheit TECHM). Strukturmanagement als Aufgabe des Informationsmanagements geht davon aus, dass eine Strukturorganisation des Unternehmens besteht, in die das Ergebnis der Gliederung des ITBereichs so eingefügt wird, dass die Erreichung der strategischen Unternehmensziele bestmöglich unterstützt wird. Dies schließt nicht aus, dass Anpassungen der Unternehmensstruktur an Ergebnisse des Strukturmanagements im IT-Bereich zweckmäßig sein können, insbesondere dann, wenn eine aggressive IT-Strategie verfolgt wird (vgl. Lerneinheit STRAT). Es handelt sich also um einen iterativen und interaktiven Gestaltungsprozess, der – häufig wegen des Entstehens neuer IM-Aufgaben (z. B. die durch Compliance-Anforderungen entstandenen Aufgaben, vgl. Lerneinheit RECHT), seltener wegen des Wegfalls bestehender Aufgaben (z. B. durch Outsourcing, vgl. Lerneinheit OUTSO) – niemals abgeschlossen ist. Beispielsweise wird in neuerer Zeit auch die Meinung vertreten, dass die steigenden Compliance-Anforderungen die Einrichtung einer besonderen Struktureinheit für das Compliance Management erfordere.

Aufgabenanalyse und Aufgabensynthese Die Vorgehensweise der Gestaltung der Strukturorganisation ist primär durch Aufgabenanalyse und Aufgabensynthese gekennzeichnet. Ausgehend von der Gesamtheit der IMAufgaben werden mit der Aufgabenanalyse die zur Erfüllung der Gesamtaufgabe erforderlichen Teilaufgaben durch Zerlegung nach analytischen Merkmalen ermittelt. Dabei werden

140

Strategische Aufgaben des Informationsmanagements

sachlich orientierte analytische Merkmale (Verrichtungen, Objekte und Sachmittel) und formal orientierte analytische Merkmale (Rang, Phase und Zweckbeziehung) verwendet. Die Aufgabensynthese besteht aus Stellenbildung, Stellenbesetzung und Zuordnung von Sachmitteln auf Stellen sowie der Ordnung der Stellen zu übergeordneten Struktureinheiten (z. B. Abteilungen). Bei der Stellenbildung werden die mit der Aufgabenanalyse gewonnenen Teilaufgaben zu Stellen zusammengefasst, aus denen die übergeordneten Struktureinheiten gebildet werden. Die Teilaufgaben sind daraufhin zu untersuchen, ob es zweckmäßiger ist, sie zu übergeordneten Struktureinheiten des IT-Bereichs zusammenzufassen oder aus dem IT-Bereich auszugliedern. Letzteres wird in der Praxis in zunehmendem Maße dann bevorzugt, wenn eine die betreffende Funktion unternehmensweit kompetente Struktureinheit bereits besteht bzw. aus Anlass der Reorganisation der Strukturorganisation des IT-Bereichs geschaffen wird. Typische, im Sinne von häufig anzutreffende strukturorganisatorische Gestaltungsmaßnahmen sind die Zuordnung des IT-Controlling (vgl. Lerneinheit CONTR) zur Struktureinheit Unternehmenscontrolling oder die Zuordnung der Informationssicherheit (vgl. Lerneinheit SICHM) zur Struktureinheit Risikomanagement bzw. einem Sicherheitsausschuss. Die Beurteilung der Zweckmäßigkeit der Zuordnungen orientiert sich an der Erfahrung, dass die fachliche Kompetenz der Aufgabenträger des IT-Bereichs bezüglich spezifischer IM-Aufgaben zur Aufgabenerfüllung nicht ausreicht und eine noch engere Zusammenarbeit zwischen ITBereich und den Fachbereichen erforderlich ist. Beispielweise werden IT-spezifisches Sicherheits- und Risikomanagement und das Sicherheits- und Risikomanagement anderer Unternehmensbereiche zur Führungsaufgabe Corporate Information Security integriert. Die Führungsposition wird als Corporate Information Security Officer (CISO) bezeichnet. Bei der Stellenbesetzung erfolgt eine Zuordnung von Stellen auf Aufgabenträger bzw. von Aufgabenträgern auf Stellen. Die Anforderungen der Stellen und die Eigenschaften der Aufgabenträger so aufeinander abgestimmt, dass sowohl aufgabenorientierte Ziele, also Organisationsziele (z. B. Produktivitätsziele), als auch aufgabenträgerorientierte Ziele, also Individualziele (z. B. Arbeitszufriedenheitsziele) erreicht werden. Bei der Sachmittelzuordnung geht es um die aufgaben- und aufgabenträgeradäquate Ausstattung der Stellen. Stellen, denen strategische Aufgaben zugeordnet werden, sollten zu einer Struktureinheit zusammengefasst werden, die direkt an das Top-Management berichtet, sofern diese Aufgaben vom Top-Management nicht selbst wahrgenommen werden. Letzteres ist in kleinen bis mittleren Unternehmen (KMU) im Allgemeinen zweckmäßig (vgl. Lerneinheit STELL). In der Praxis werden strategische Aufgaben häufig der IT-Abteilung zugeordnet. Dies ist nur dann zweckmäßig, wenn die Abteilungsleitung zur obersten Leitungsebene gehört (was selten der Fall ist). Ist sie der obersten Leitungsebene direkt unterstellt (was meist der Fall ist), können Teile der strategischen Aufgaben der IT-Abteilung zugeordnet werden. Strategische Zielplanung und Strategieentwicklung (vgl. Lerneinheiten SZIEL und STRAT) sollten in jedem Fall Aufgaben des Top-Managements sein.

Strukturmanagement (STRUK)

141

Gestaltungsprinzipien Die Gestaltung der Strukturorganisation orientiert sich an Prinzipien, mit deren Anwendung neben den ökonomischen Zielen (insbesondere Wirtschaftlichkeit und Produktivität) verschiedene andere Ziele verfolgt werden, beispielsweise soziotechnische Gestaltungsziele. Prinzipien, mit denen soziotechnische Gestaltungsziele verfolgt werden, sind: 

 

 

Prinzip der relativen Unabhängigkeit der Struktureinheit: Arbeitsgruppen sollen so gebildet werden, dass Struktureinheiten entstehen, denen in Form der Gruppenzuordnung Aufgaben zugewiesen werden (teilautonome Gruppen). Über die Einzelzuordnung, also wer in der Gruppe welche Aufgaben übernimmt, entscheiden die Gruppenmitglieder. Prinzip der Einheit von Struktureinheit und Produkt: Der technisch-organisatorische Arbeitsablauf soll so gestaltet werden, dass das Arbeitsergebnis (das Produkt) quantitativ und qualitativ auf die Struktureinheit rückführbar und für deren Mitglieder erkennbar ist. Prinzip des Aufgabenzusammenhangs in der Struktureinheit: Die in der Struktureinheit zu verrichtenden Tätigkeiten sollen einen inhaltlichen Zusammenhang aufweisen, der eine gegenseitige Unterstützung der Mitglieder der Struktureinheit bei der Aufgabenerfüllung ermöglicht. Prinzip der Selbstregulation der Struktureinheit: Schwankungen und Störungen der Aufgabenerfüllung sollen in der Struktureinheit, in der sie entstehen, aufgefangen und nicht unkontrolliert an andere Struktureinheiten weiter gegeben werden. Prinzip der Grenzregulation durch den Vorgesetzten: Die Hauptaufgabe des Vorgesetzten soll darin bestehen, die Unabhängigkeit der Struktureinheit zu gewährleisten und die Beziehungen mit anderen Struktureinheiten sicherzustellen.

Meist gelingt es nicht, alle genannten Gestaltungsziele (und weitere) zu erreichen; Zielkompromisse sind also erforderlich.

Zentralisierung / Dezentralisierung Insbesondere im Fall einer divisionalen Unternehmensstruktur mit ergebnisverantwortlichen Geschäftsbereichen ist zu prüfen, ob eine zentrale IT-Abteilung zweckmäßig ist und wie die Koordination zwischen ihr und den Geschäftsbereichen gestaltet sein soll. Werden statt einer zentralen mehrere dezentrale IT-Abteilungen vorgesehen, besteht die Gefahr von Redundanz mit negativer Auswirkung auf die Wirtschaftlichkeit. In der Regel ist ein Kompromiss zweckmäßig. Den dezentralen IT-Abteilungen werden die Aufgaben zugeordnet, die für die jeweiligen Geschäftsbereiche spezifisch sind, der zentralen IT-Abteilung die Aufgaben, die übergreifend für das Gesamtunternehmen von Bedeutung sind. Die Koordination des gesamten IT-Bereichs erfolgt durch die zentrale IT-Abteilung. Abbildung STRUK-1 zeigt die Institutionalisierung der IT in einem divisional organisierten Unternehmen. Die zentrale IT-Abteilung wird als Stabsabteilung der Unternehmensleitung, die dezentralen IT-Abteilungen der Geschäftsbereiche werden als Hauptabteilungen in der Linie geführt. Die gestrichelte Verbindungslinie zwischen der zentralen IT-Abteilung und den drei dezentralen IT-Abteilungen symbolisiert die von der zentralen IT-Abteilung wahrgenommene Koordinierungsaufgabe. Da die Geschäftsbereiche in einem divisional organisierten Unternehmen in der Regel als Profit Center geführt werden, sind die dezentralen IT-

142

Strategische Aufgaben des Informationsmanagements

Abteilungen Teile dieser Profit Center. Als Hilfsmittel zur Koordination der IT-Abteilungen untereinander sowie zwischen den dezentralen IT-Abteilungen und den anderen Instanzen der Geschäftsbereiche sind Verrechnungspreise (vgl. Lerneinheit KOLER) dann ein geeignetes Instrument, wenn die Ressourcen knapp sind und von konkurrierenden Leistungsnehmern beansprucht werden. Unternehmensleitung Zentrale IT-Abteilung

Geschäftsbereich A

Geschäftsbereich B

Geschäftsbereich C

Beschaffung

Beschaffung

Beschaffung

Produktion

Produktion

Produktion

Vertrieb

Vertrieb

Vertrieb

Verwaltung

Verwaltung

Verwaltung

IT-Abteilung

IT-Abteilung

IT-Abteilung

Abb. STRUK-1: Zentrale IT-Abteilung und dezentrale IT-Abteilungen

Es kann zweckmäßig sein, auch die zentrale IT-Abteilung als Profit Center zu führen, was in der Praxis nur selten der Fall ist. Folgende Fragen müssen zur Entscheidung darüber beantwortet werden (nach Kargl):    

Welche Produkte und Dienstleistungen sollen angeboten werden? Welche Produkte und Dienstleistungen sind aus Sicht der potenziellen Kunden besonders wertvoll (Kernkompetenzen)? Welche Märkte sollen bedient werden (Muss-Märkte / Kann-Märkte)? Zu welchen Preisen sollen die Produkte und Dienstleistungen angeboten werden (Preisfindung)?

Stellenbezeichnungen wie Benutzerservice-Zentrum, heute meist als Helpdesk bezeichnet, drücken aus, dass die Serviceaufgaben einer zentralen Stelle zugeordnet werden. Stichhaltige Gründe für die Zentralisierung werden in der Literatur nicht angegeben. Diese könnten sein: (1) „One-face-one-customer“, (2) einheitliche Dokumentation von Fehlern, (3) standardisierte Vorgehensweisen zur Fehlerbehebung und (4) FAQs (vgl. Lerneinheit SEMAN). Es gibt auch Gründe, die gegen eine Zentralisierung sprechen. So nimmt mit zunehmender Zentralisierung der Abstand (z B. was die verwendete Fachsprache betrifft) zwischen den Aufgabenträgern des Benutzerservice als Leistungsgeber und den Benutzern als Leistungsnehmer zu und das gegenseitige Aufgaben- und Problemverständnis entsprechend ab. Die Argumente für verteilte Konzepte gegenüber der Zentralisierung gelten auch für die Aufgaben des Benutzerservice; bestimmte Aufgaben werden zweckmäßigerweise zentralisiert, andere dezentralisiert. Als Aufgabenträger für dezentrale Aufgaben bieten sich die in

Strukturmanagement (STRUK)

143

vielen Unternehmen eingeführten Koordinatoren an. Mit den Benutzern verglichen, sind Koordinatoren Experten bezüglich Systementwicklung und Systemnutzung. Sie sind entweder fachlich und disziplinarisch dem Leiter der Fachabteilung oder dem Leiter der ITAbteilung unterstellt, oder beiden gemeinsam (Matrixorganisation). Aus Sicht der Fachabteilung ist der ersten Variante der Vorzug zu geben. Die zentralen Aufgaben des Benutzerservice werden in die IT-Abteilung eingeordnet. Abbildung STRUK-2 zeigt beispielhaft aus einem Unternehmen der Bauindustrie die Zuordnung der strategischen IM-Aufgaben auf Institutionen. In Ergänzung zum bisher Gesagten wird die Institution Steuerungsgremium eingeführt; die Aufgabe der Überwachung und Steuerung des strategischen Projektportfolios wird vom Lenkungsausschuss an diese Institution ausgelagert. Die Abbildung zeigt auch die Unterscheidung zwischen strategischen und sonstigen IT-Projekten und deren unterschiedliche Zuordnung (IT-Steuerungsgremium bzw. IT-Abteilung). Geschäftsleitung / Top Management

Fachbereiche, Abteilungen, Geschäftsfelder usw.

strategische Maßnahmenplanung

IT-Lenkungsausschuss

ITAbteilung

strategisches Controlling

IT-Steuerungsgremium

strategische Zielplanung Strategieentwicklung

P1 P2 P3 strategische IT-Projekte

P1

P2

sonstige IT-Projekte fachliche Unterstellung Mitglieder-Rekrutierung

Abb. STRUK-2: Institutionen des Informationsmanagements und Zuordnung strategischer Aufgaben

Strukturkonzepte Krüger/Pfeiffer schlagen für die Gliederung der IM-Aufgaben vier Strukturkonzepte vor, deren Zweckmäßigkeit vor dem Hintergrund der verfolgten IT-Strategie (vgl. Lerneinheit STRAT) beurteilt wird. Die Konzepte, die auch kombiniert werden können, werden als Ergänzung, Addition, Fusion und Integration bezeichnet. 

Ergänzung: Vorhandene Struktureinheiten, insbesondere Organisationsabteilung und ITAbteilung, werden um einzelne Stabs- und Ausführungsstellen ergänzt, die sich neuen IM-Aufgaben widmen.

144

  

Strategische Aufgaben des Informationsmanagements

Addition: Neben die vorhandenen Struktureinheiten tritt eine zusätzliche Struktureinheit, der neue IM-Aufgaben zugeordnet werden. Fusion: Alle vorhandenen Struktureinheiten, die für IM-Aufgaben zuständig sind, werden zu einer Struktureinheit Informationsmanagement fusioniert; innerhalb dieser Struktureinheit bleiben die bisherigen Zuständigkeiten bestehen. Integration: Alle IM-Aufgaben werden in einer Struktureinheit Informationsmanagement zusammengefasst, reorganisiert und integriert.

Abbildung STRUK-3 zeigt die Zuordnung der Strukturkonzepte auf IT-Strategien; die Felder der Matrix machen Aussagen über die Zweckmäßigkeit jeder Zuordnung. (Die zitierte Quelle gibt keine Begründung für diese Empfehlungen.) StrukturKonzept

Ergänzung

Addition

Fusion

Integration

defensive Strategie

empfehlenswert

nicht zweckmäßig

nicht nötig

übertrieben

MomentumStrategie

möglich

empfehlenswert

möglich

übertrieben

moderate Strategie

ungeeignet

bedingt möglich

empfehlenswert

möglich

aggressive Strategie

nicht möglich

nicht zweckmäßig

nicht ausreichend

empfehlenswert

Strategie

Abb. STRUK-3: Strategie/Struktur-Matrix (Quelle: nach Krüger/Pfeiffer)

Wegen der Bedeutung des Datensystems für den Unternehmenserfolg (Daten als wirtschaftliches Gut, vgl. Kapitel Einführung und Grundlegung) zeichnen sich strukturorganisatorische Konzepte ab, die auf eine systematische Zerlegung der IM-Aufgaben und deren Zuordnung zu verschiedenen Struktureinheiten der IT-Abteilung (also IT-Stellen) oder auf bestehende bzw. neue Struktureinheiten außerhalb der IT-Abteilung abzielen. Beispiele dafür sind die Aufgaben des Datenmanagements (vgl. Lerneinheit DATEM) einschließlich der Aufgaben, die mit der Schaffung der Datenarchitektur im Zusammenhang stehen (vgl. Lerneinheit ARCHI). Folgende Alternativen bieten sich an:   

Datenmanagement als Stelle der IT-Abteilung, Datenmanagement als Linienabteilung, die direkt an die Unternehmensleitung berichtet (also als Struktureinheit neben der IT-Abteilung besteht), und Datenmanagement als Stabsstelle der Unternehmensleitung.

Es kann angenommen werden, dass es in Zukunft weitere Spezialisierungen der Strukturorganisation im IT-Bereich geben wird, beispielsweise ein Business-Intelligence-Center, das primär der Unterstützung des Controllings dient (vgl. Lerneinheit CONTR). Mit weiterer Dezentralisierung der IT (insbesondere der Verlagerung von IM-Aufgaben in die Fachabtei-

Strukturmanagement (STRUK)

145

lungen) entsteht ein Unterstützungsbedarf, der definiert und in geeigneter Weise strukturorganisatorisch abgesichert werden muss. Mit der Emanzipation der Benutzer steigt auch der Koordinierungsbedarf (insbesondere für die Abstimmung der Entwicklungs- und Beschaffungsaufgaben) zwischen den Benutzern sowie zwischen diesen und der IT-Abteilung. In neuerer Zeit und mit Prognosen über deren Ausbreitung in der Zukunft, insbesondere in großen Unternehmen, wird die sogenannte Demand- und Supply-Organisation als hybride Form der Organisationsstruktur des IT-Bereichs beschrieben. Es wird angenommen, dass diese Struktur das Business-IT-Alignment unterstützt (vgl. Lerneinheit ERMOD).

Lenkungsausschuss Lenkungsausschüsse im IT-Bereich sind in der Praxis weit verbreitet; ihre Zweckmäßigkeit ist nicht unbestritten. Ihre Notwendigkeit wird vor allem damit begründet, dass sie ein geeignetes Instrument zur Abstimmung der strategischen IT-Planung mit der strategischen Unternehmensplanung sind. Ihre Aufgaben, Kompetenzen und Ressourcen können unterschiedlich festgelegt und umfangreich sein. In einem Unternehmen können mehrere Lenkungsausschüsse, auch im IT-Bereich, zweckmäßig sein, in einem divisional organisierten Unternehmen beispielsweise neben einem zentralen Lenkungsausschuss auf Unternehmensebene mehrere dezentrale Lenkungsausschüsse in den Divisionen. Gründe, warum ein Lenkungsausschuss wenig wirksam ist oder auch scheitern kann, sind (nach Earl):     

Die Qualifikation der Ausschussmitglieder entspricht nicht (mehr) den Aufgaben. Die Einordnung des Lenkungsausschusses in die Unternehmenshierarchie ist unpassend; sie ist entweder zu hoch oder (häufiger) zu niedrig. Die Kommunikation zwischen Lenkungsausschuss und Linieninstanzen funktioniert weder nach oben noch nach unten. Der Lenkungsausschuss tritt zu häufig zusammen, so dass sich sein Fokus von den strategischen Aufgaben entfernt und zu stark administrativ und projektorientiert wird. Der Lenkungsausschuss passt sich nicht schnell genug an die Veränderung des Unternehmenszwecks, der Struktur- und Ablauforganisation und der Technologien an. Diese Anpassung ist nicht nur bezüglich seiner strukturellen Merkmale (insbesondere personelle Zusammensetzung), sondern auch bezüglich der Arbeitsorganisation erforderlich.

Personelle Zusammensetzung, Größe und Kompetenz eines Lenkungsausschusses werden primär von Art und Umfang der ihm übertragenen Aufgaben bestimmt. Ein Lenkungsausschuss, dessen primäre Aufgabe die Planung, Überwachung und Steuerung des strategischen Projektportfolios ist und an den die Projektleitungen berichten (vgl. Lerneinheit SPLAN), besteht aus dem CIO bzw. dem für den IT-Bereich zuständigen Mitglied der Unternehmensleitung, dem Leiter der IT-Abteilung und den Leitern der Fachabteilungen (bei funktionaler Unternehmensstruktur) bzw. den Prozesseignern (bei prozessorientierter Unternehmensstruktur). Wegen der sonst ausufernden Größe wird bei großen Unternehmen nur das Linienmanagement der Kernfunktionen bzw. der Kernprozesse im Lenkungsausschuss vertreten sein. Er entscheidet über die Priorität der Projekte und ihre strategisch bedeutsamen Planungsziele bezüglich Leistung, Kosten und Termine (Portfoliomanagement, vgl. Lerneinheit SPLAN).

146

Strategische Aufgaben des Informationsmanagements

Forschungsbefunde Son/Gladyszewsk berichten als Ergebnis einer empirischen Untersuchung zum IT-Controlling (Untersuchungsmerkmale siehe Lerneinheit CONTR) u. a. (15): „Bei der Aufstellung der IT-Organisationen innerhalb der Unternehmung haben sich vor allem profitähnliche Strukturen herausgebildet wie Service Center, Profit Center und IT GmbH (11 %, 16 % und 29 %). Lediglich 9 % arbeiten noch mit einer Hilfskostenstelle und 5 % der Befragten haben ihre IT-Organisation individuell aufgestellt.“ Eine Analyse dieser Daten zeige allerdings, dass zahlreiche „Pseudo-Profit Center“ existieren, die grundlegende Kriterien eines Profit Centers wie Cost-Plus-Pricing (= kostengetriebener Ansatz zur Festsetzung eines Preises; auf die Kosten eines Gutes wird der zu erzielende Gewinn als Aufschlag addiert, um den Verkaufspreis festzulegen), freier Marktzugang oder Ergebnisorientierung nicht erfüllen. Drury untersuchte fünf alternative Zusammensetzungen des Lenkungsausschusses unter Verwendung von dreizehn Erfolgskriterien (explorative Vorstudie mit mündlicher Befragung, Hauptstudie als Stichprobenanalyse mit schriftlicher Befragung, Untersuchungszeitraum nicht angegeben). Die besten Beurteilungen erhielten Lenkungsausschüsse, die nach folgenden Regeln arbeiten: (1) Arbeitssitzungen werden regelmäßig abgehalten, (2) Tagesordnungspunkte von außerhalb der IT-Abteilung werden berücksichtigt und (3) Entscheidungen werden kollegial getroffen. Wenig konsistent sind die Beurteilungen des Vorsitzenden des Lenkungsausschusses und seiner Wirkung bei den Benutzern. So ist die Beurteilung der IT-Abteilung umso besser, je höher der Rang des Vorsitzenden des Lenkungsausschusses ist, andererseits ist das Bewusstsein der Benutzer bezüglich der IT umso ausgeprägter, je geringer der Rang des Vorsitzenden ist. Generell wird festgestellt, dass Lenkungsausschüsse geeignet sind, die Aufmerksamkeit des Top-Managements für die IT ebenso wie die Benutzermitwirkung bei der IT-Gestaltung zu erhöhen. Krüger/Pfeiffer berichten zu den von ihnen vorgeschlagenen Strukturkonzepten Folgendes (Stichprobenanalyse mit schriftlicher Befragung in deutschen Großunternehmen, 176 Befragte, Untersuchungszeitraum 1989): Mehr als 50 % der Befragten bevorzugen das Konzept Integration, etwa 20 % das Konzept Fusion, etwa 15 % das Konzept Ergänzung und nur rd. 7 % das Konzept Addition. Heinzl stellte bezüglich der Institutionalisierung der IT unterschiedliche Beurteilungen der IT-Führungskräfte bzw. der Linienmanager fest (Ergebnis von zwei Delphi-Studien mit 21 bzw. 22 Teilnehmern, Untersuchungszeitraum 1993 bzw. 1994). Während IT-Führungskräfte die strategische Rolle ihrer Funktion als gegeben ansehen, können nach Auffassung der Linienmanager die IT-Mitarbeiter die strategische Relevanz von IT-Projekten nicht selbst beurteilen. Daher geht das Linienmanagement davon aus, dass eine organisatorische Verteilung der IT-Funktion stattfindet, wobei lediglich ein kleiner Funktionsrest zentral verortet bleibt. Robey/Zmud formulierten auf der Basis von Organisationstheorien u. a. folgende Hypothesen bzw. Empfehlungen zur Organisation des Benutzerservice (zitiert nach Knolmayer): 

Mit wachsender Aufgabenunsicherheit werden Information Center (IC) eingerichtet, welche die Beziehungen zwischen den Fachbereichen und dem IT-Bereich koordinieren.

Strukturmanagement (STRUK)

    

147

IC sollten organisatorisch so eingegliedert werden, dass die Unsicherheit hinsichtlich ihrer Politik, Vorgehensweisen, Anwendungsbereiche und Werkzeuge minimiert wird. Wenn die Aufgabenunsicherheit hoch ist, steigen die Kosten der Koordination und die IC werden rascher in die Fachbereiche dezentralisiert. In sehr großen, divisonal organisierten Unternehmen werden IC in den einzelnen Divisionen angesiedelt. IC sollten so spezialisiert operieren, wie dies angesichts der Komplexität der zu unterstützenden Anwendungen angemessen ist. IC werden mit wachsendem Wissen der Benutzer über IT-Vorgehensweisen und ITWerkzeuge und mit wachsender Standardisierung der Endbenutzer-Systeme in der Organisation weniger sichtbar.

Luftman/Ben-Zvi berichten über die Ergebnisse einer Studie der Society for Information Management zur Frage Zentralisierung/Dezentralisierung u. a. (schriftliche Befragung von IT-Führungskräften in 172 Mitgliedsunternehmen in den USA, Untersuchungszeitraum Sommer 2010): 68 % gaben an, ihre IT-Organisation sei zentralisiert, 2 %, sie sei dezentralisiert und 28 % stuften sie als föderal bzw. hybrid organisiert ein.

Aus der Praxis Stolorz, Vorstandsvorsitzender des IT-Beratungsunternehmens CSC Ploenzke, hat ein „Ende des Autarkiedenkens der IT in der deutschen Bankenlandschaft“ ausgemacht (F.A.Z. vom 18.12.2000, 31). Die Zeiten, da jede Bank ihre eigene IT-Abteilung unterhält, gingen zu Ende. Ursachen für „den Sinneswandel“ sind Konkurrenzdruck, Fusionsdiskussion und Kostentransparenz. Außerdem können Finanzdienstleister nicht im Back Office, sondern nur mit besserer Kundenberatung einen Wettbewerbsvorteil erlangen. Anstelle der „isolierten eigenen IT-Lösung“ gehen immer mehr Finanzdienstleister dazu über, sich kostengünstigere Standardanwendungen zuzulegen. Im Unterschied zur Industrie mit an Kundenforderungen angepassten ERP-Systemen (wie SAP), werde im Finanzsektor eine Art Halbfabrikat verkauft. Das in der Industrie übliche Lizenzmodell werde durch ein Partnerschaftsmodell ersetzt: Software-Hersteller, IT-Berater und Kunden investieren gemeinsam in die Softwareentwicklung, deren Produkte in Lizenz an andere Finanzdienstleister vergeben werden. Hoy, Manufacturing Industry Director, Cognos Inc., fordert von der IT-Abteilung, dass sie die Unternehmensbereiche „auf drei Ebenen“ unterstützt (Cognos News 04/04, 7): (1) den autonomen Datenzugriff aller Benutzer sicherstellen und die gemeinsame Datennutzung auf globaler Ebene ermöglichen, (2) Technologien und Lösungen empfehlen, mit denen Berichte generiert werden können, die bei der Umsetzung von Unternehmensstrategien Hilfe leisten, (3) eine Plattform bereitstellen, die einen aktuellen, konsistenten und bedürfnisspezifischen Einblick in den Datenbestand ermöglicht. Nach eine Experton-Umfrage „unter knapp 150 deutschen Unternehmen: Organisation der IT-Security“ fehlt vielen die organisatorische Struktur, die für eine Zuordnung unternehmensweit relevanter Sicherheitsaufgaben erforderlich ist. Auf die Frage „Gibt es in Ihrem Unternehmen einen Sicherheitsausschuss oder ein Security Steering Committee?“ antworteten 28 % ja, 4 % nein, aber geplant, und 68 % nein, auch nicht geplant. Ein Experton Adviser rät: „Für einen regelmäßigen firmenweiten Austausch benötigt man als Koordinator … am

148

Strategische Aufgaben des Informationsmanagements

besten einen CISO, der außerhalb der IT sitzt.“ Und ein „Leiter Informationssicherheit und Datenschutz“ ergänzt: „Der CISO darf nicht an den CIO berichten. Denn dieser kommt häufig in Zielkonflikte mit seinem Budget.“ (Zitiert nach Computer Zeitung vom 6.4.2009.) Nach der Detecon-Studie „IT-Organisation 2015“ wird die IT-Organisation der Zukunft von einem Demand- und Supply-Management mit zunehmendem usiness-Know-how bestimmt und „wesentlich stärker“ proaktiv das Business unterstützen, wobei die ServiceSteuerung gegenüber der Service-Erbringung an Bedeutung gewinnt. Der Schlüssel für eine erfolgreiche IT-Organisation liege, so wird festgestellt, „…in rechtzeitig und konsequent definierten Services und einem optimierten Delivery- und Sourcing-Modell.“ Mark/Rau sind der Ansicht, dass Unternehmen ihre Produktivität durch IT-Investitionen steigern können, wenn sie „demand organizations“ etablieren, deren primäre Aufgabe darin besteht, die Entwicklungsanforderungen zwischen den IT-Anwendern (businesses) und den IT-Anbietern (suppliers) zu koordinieren. Methodenverweise Nutzwertanalyse (Lerneinheit NUTZW). Kontrollfragen 1. Welche Gestaltungsfragen sind für die Strukturierung des IT-Bereichs von Bedeutung? 2. Wie werden Aufgabenanalyse und Aufgabensynthese durchgeführt? 3. Welche Aufgaben hat ein Lenkungsausschuss, wie wird er besetzt und an wen berichtet er? 4. Wie kann ein Demand- und Supply-Management die Erreichung von Business-IT-Alignment unterstützen? 5. Welcher Zusammenhang besteht zwischen Strukturmanagement und IT-Strategien? Quellen Detecon Executive Briefing: IT-Organisation 2015 – Fit für die Zukunft? http://www.detecon.com/de/studies/itorganisation-2015-fit-fur-die-zukunft_2011_04_28_342; Abruf 22.5.2011 Drury, D. H.: An Evaluation of Data Processing Steering Committees. In: MIS Quarterly 12/1984, 257–265 Earl, M. J.: Management Strategies for Information Technology. Hempstead 1989 Heinzl, A.: Die Evolution der betrieblichen DV-Abteilung. Eine lebenszyklustheoretische Analyse. Würzburg 1996 Knolmayer, G.: Benutzersupport – eine Kernkompetenz des IV-Bereichs? In: HMD – Theorie und Praxis der Wirtschaftsinformatik 189/1996, 7–24 Krüger, W. / Pfeiffer, P.: Strategisches Management von Informationen – Formulierung und organisatorische Umsetzung der Informationsstrategie. In: Office Management 10/1987, 28–34 Luftman, J. / Ben-Zvi, T.: Key Issues for IT Executives 2010: Judicious IT Investments Continue Post-Recession. In: MIS Quarterly Executive 4/2010, 263–273 Mark, D. / Rau, D.P.: Splitting demand from supply in IT. In: The McKinsey Quarterly, September 2006, S. 1-4. http://www.mckinseyquarterly.com; Abruf 28. Juni 2011 Pfeiffer, P.: Technologische Grundlage, Strategie und Organisation des Informationsmanagements. Berlin/New York 1990 Son, S. / Gladyszewski, Th.: Return on IT-Controlling 2005 – eine empirische Untersuchung zum Einfluss des ITControllings auf die unternehmensweite IT Performance. Arbeitsbericht, E-Finance Lab Frankfurt a. M., Kontakt: [email protected] Vertiefungsliteratur Enns, H. G. / MacFarlin, D. B. / Huff, S. L.: How CIOs can effectively use Influence Behaviors. In: MIS Quarterly 1/2007, 29–38 Pietsch, T. / Martiny, L. / Klotz, M.: Strategisches Informationsmanagement. Bedeutung und organisatorische Umsetzung. 4. A., Berlin 2004 Rohloff, M.: Ein Referenzmodell für die Prozesse der IT-Organisation. In: HMD – Theorie und Praxis der Wirtschaftsinformatik 256/2007, 27–36 Rockart, J. F.: The Line Takes the Leadership – IS Management in a Wired Society. In: Information Management 4/1988, 6–13

Qualitätsmanagement (QUALM) Lernziele Sie können den Zweck des Qualitätsmanagements (abgekürzt QM), den Qualitätsbegriff sowie verschiedene Sichten und Aufgaben des QM erklären. Sie kennen wichtige Sichten und Prinzipien des QM. Sie wissen, aus welchen Elementen ein QM-System besteht. Sie erkennen die wirtschaftliche Bedeutung der Qualität für IT-Prozesse und für Komponenten der Informationsinfrastruktur.

Definitionen und Abkürzungen Anforderung (requirement) = Erfordernis oder Erwartung, das oder die festgelegt, üblicherweise vorausgesetzt oder verpflichtend ist. Synonym: Qualitätsanforderung. Kunde (customer) = Abnehmer von Leistungen innerhalb oder außerhalb von Unternehmen (interner oder externer Kunde). PDCA = Plan-Do-Check-Act; Zyklus der kontinuierlichen Verbesserung. Produkt (product) = Ergebnis eines Leistungserstellungsprozesses, also nicht nur materielle, sondern auch immaterielle Produkte und Dienstleistungen. Prozess (process) = Menge interdependenter Teilaufgaben, die durch Eingaben (Input), interne Funktionen und Ausgaben (Output) gekennzeichnet ist. QM-Maßnahme (quality management measure) = Maßnahme, deren Zweck es ist, die Realisierung einer definierten Qualitätsanforderung zu gewährleisten. Qualitätsanforderung (quality requirement) = geforderte Ausprägung eines Qualitätsmerkmals eines Objektes. Synonym: Anforderung. Qualitätslenkung (quality control) = Teil des QM, der auf die Erfüllung von Qualitätsanforderungen ausgerichtet ist und dessen wesentliches Element die Qualitätsprüfung ist. Qualitätsmerkmal (quality characteristic) = relevante Eigenschaft eines Objektes, die sich auf eine Anforderung bezieht. Synonym: Qualitätseigenschaft. Qualitätsmodell (quality model) = System aus Qualitätsmerkmalen und deren Beziehungen zur Spezifizierung von Anforderungen und zur Beurteilung der Qualität eines Objektes. Qualitätsplanung (quality planning) = Teil des QM, der Qualitätsziele, notwendige Prozesse sowie Ressourcen zur Erreichung der Qualitätsziele festlegt. Qualitätspolitik (quality policy) = durch das Top-Management formell ausgedrückte Absichten und Ziele des Unternehmens zur Qualität. Qualitätssicherung (quality assurance) = Teil des QM, der darauf ausgerichtet ist, Vertrauen zu erzeugen, dass Qualitätsanforderungen erfüllt werden. Qualitätsverbesserung (quality improvement) = Teil des QM, der darauf ausgerichtet ist, die Fähigkeit zur Erfüllung von Qualitätsanforderungen zu verbessern. Qualitätsziel (quality objective) = Qualität betreffendes, strategisches Formalziel. SPI = Software Process Improvement; Verbesserung von Softwareentwicklungsprozessen. TQM = Total Quality Management; ganzheitliches bzw. umfassendes QM. Zertifizierung (certification) = Bestätigung durch eine autorisierte Prüfstelle, dass ein Objekt definierten Anforderungen entspricht.

150

Strategische Aufgaben des Informationsmanagements

Zweck des Qualitätsmanagements Die Bezeichnung Qualitätsmanagement (abgekürzt QM) soll die Spannweite dieser Managementaufgabe zum Ausdruck bringen, die innerbetrieblich vom Top-Management bis zur operativen Ebene und zwischenbetrieblich von den Kunden bis zu den Lieferanten reicht. In der ISO-9000-Normenfamilie wird QM als aufeinander abgestimmte Tätigkeiten zum Leiten und Lenken einer Organisation bezüglich Qualität bezeichnet. Zwar wird QM vom TopManagement initiiert und geführt, seine Verwirklichung bezieht aber alle Mitarbeiter ein. QM im Zusammenhang mit der Informationsinfrastruktur heißt, strategische Qualitätsziele (das sind die Qualität betreffende strategische Formalziele, vgl. Lerneinheit ERMOD) zu setzen, daraus ein unternehmensweites Rahmenkonzept für alle qualitätsbezogenen Tätigkeiten abzuleiten (Qualitätsstrategie als Teilstrategie der IT-Strategie, vgl. Lerneinheit STRAT) und durch Maßnahmen so durchzusetzen, wie dies zur Erfüllung der strategischen Qualitätsziele erforderlich ist. QM spielt eine wesentliche Rolle in Leitfäden zum Projektmanagement, Vorgehensmodellen (vgl. Lerneinheit VOMOD), Leitfäden zu IT-Governance (vgl. Lerneinheit GOVER) sowie in Serviceebenen-Vereinbarungen (vgl. Lerneinheit SEVER). Datenqualität wird in der Lerneinheit DATEM erörtert.

Qualität, Qualitätsmerkmal, -maß und -modell Qualität wurde in der (inzwischen zurückgezogenen) Norm ISO 8402 definiert als „Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen“. Einheiten können dabei z. B. Softwareprodukte, BPR-Projekte, Geschäftsprozesse, Informationssysteme, IT-Dienstleistungen oder Fachkonzepte sein. Etwas schwerer verständlich, aber inhaltlich deckungsgleich, wird der Begriff in der ISO 9000 definiert als „Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“. Qualität bezieht sich auf bestimmte Eigenschaften bzw. Merkmale von Objekten. Welche Eigenschaften relevant sind, hängt von denjenigen Instanzen ab, welche die Qualität eines Objektes spezifizieren. Das kann bedeuten, dass die Qualität eines Informationssystems von einem Entwickler anders beschrieben wird als von einem Nutzer oder Administrator. Ob Qualität gegeben ist, hängt nicht vom Niveau der Qualitätsanforderungen ab. Qualität ist sowohl bei geringem Niveau als auch bei hohem Niveau gegeben, wenn Qualitätsanforderung und realisierte Beschaffenheit übereinstimmen. Erreicht die realisierte Beschaffenheit eines Objektes die Qualitätsanforderung nicht, liegt ein Qualitätsmangel vor. Um die gewünschte oder geforderte Qualität eines Objektes spezifizieren und überprüfen zu können, ist es notwendig, Qualitätsmerkmale zu definieren und mit Hilfe von Qualitätsmaßen näher zu bezeichnen. Ein Qualitätsmaß beschreibt mögliche Ausprägungen eines Qualitätsmerkmals, die mit einer geeigneten Messmethode ermittelt werden können. ISO/IEC 9126 und ISO/IEC 25010 definieren ein Qualitätsmodell als Satz von Qualitätsmerkmalen und deren Beziehungen, welche die Grundlage für die Spezifizierung von Anforderungen und die Beurteilung der Qualität eines Objektes bilden. Qualitätsmodelle helfen dem Auftraggeber, seine Erwartungen und Bedürfnisse an die Qualität von Objekten zu formulieren. Sie dienen dem Auftragnehmer als Richtlinien für die Entwicklung und bilden eine

Qualitätsmanagement (QUALM)

151

wichtige Grundlage für die Prüfung (vgl. zur Evaluierung von Objekten Lerneinheit EVALU und zur Prüfung von Produkten und Prozessen Lerneinheit MEQUA). Zweck eines Qualitätsmodells ist es auch, die Beziehungen zwischen Qualitätsmerkmalen sichtbar zu machen. Manche Merkmale lassen sich nicht quantifizieren, besonders bei solchen Objekten, die Dienstleistungen sind (vgl. Lerneinheit SEMAN). In diesem Fall sind treffende qualitative Beschreibungen, die intersubjektiv nachvollziehbar sind, besser als die Nichtberücksichtigung der betreffenden Eigenschaften und Merkmale. Bei der Beurteilung von Softwareprodukten trifft dies z. B. auf das Qualitätsmerkmal Benutzerfreundlichkeit zu.

Objekte und Sichten des Qualitätsmanagements Objekte des QM sind die Informationsinfrastruktur mit allen materiellen und immateriellen Komponenten (ISO 9000 bezeichnet Komponenten als Einheiten), die Prozesse zur Entwicklung und Nutzung dieser Komponenten sowie die Zwischenprodukte, die zu ihrer Entstehung führen. Auch vom Markt bezogene Produkte und Dienstleistungen sowie die zum Bezug erforderlichen Prozesse sind Objekte des QM. QM umfasst mehrere Sichten: die produktorientierte, die prozessorientierte und die ganzheitliche bzw. umfassende Sicht.

Produktorientierte Sicht Die produktorientierte Sicht geht davon aus, dass sich Qualität im Wesentlichen in Produkten manifestiert. Ein produktorientiertes QM konzentriert sich demzufolge auf Planung, Steuerung und Kontrolle der Produktqualität, d. h. Qualität der Komponenten der Informationsinfrastruktur, also selbst erstellte oder fremd bezogene Produkte materieller oder immaterieller Art. Produktqualität kann nur entstehen, wenn sie im Prozess der Planung und Realisierung des Produkts durch analytische und konstruktive QM-Maßnahmen hergestellt wird. Produktqualität setzt auch voraus, dass die bei der Herstellung des Produkts verwendeten bzw. in das Produkt eingehenden Vorprodukte (z. B. wiederverwendete Softwaremodule), Methoden (z. B. Vorgehensmodelle) und Werkzeuge (z. B. Softwareentwicklungswerkzeuge) sowie personelle Dienstleistungen bestimmte Qualitätsanforderungen erfüllen. QM-Maßnahmen sind konstruktiver oder analytischer Art. Konstruktive QM-Maßnahmen sind technische (z. B. Verwendung von Prinzipien, Methoden und Werkzeugen), organisatorische (z. B. Verwendung von Vorgehensmodellen und Dokumentationsrichtlinien) und personelle (z. B. Personalschulung). Im Mittelpunkt steht die Personalschulung als konstruktive QM-Maßnahme, da die meisten anderen Maßnahmen ohne ausreichende Qualifikation des Personals wirkungslos bleiben. Durch analytische QM-Maßnahmen wird überprüft und beurteilt, ob Qualitätsanforderungen realisiert wurden; sie führen gegebenenfalls zur Qualitätsverbesserung. Analytische QM-Maßnahmen können statisch (z. B. Qualitätsaudit) oder dynamisch (z. B. Testen) sein (vgl. Lerneinheit MEQUA). Produktqualität kann mit verschiedenen Merkmalen beschrieben werden. ISO/IEC 9126nennt folgende Merkmale für die Spezifizierung von Softwarequalität:

152

     

Strategische Aufgaben des Informationsmanagements

Funktionalität: Fähigkeit eines Softwareproduktes, unter spezifizierten Bedingungen festgelegte und stillschweigend vorausgesetzte Anforderungen an die Funktionen zu erfüllen. Zuverlässigkeit: Fähigkeit eines Softwareproduktes, unter spezifizierten Bedingungen ein bestimmtes Leistungsniveau zu bewahren. Benutzbarkeit bzw. Benutzerfreundlichkeit: Eigenschaft eines Softwareproduktes, unter spezifizierten Bedingungen für Nutzer verständlich, erlernbar, benutzbar und attraktiv zu sein. Effizienz: Fähigkeit eines Softwareproduktes, unter spezifizierten Bedingungen ein im Verhältnis zu den eingesetzten Ressourcen angemessenes Leistungsniveau zu bieten. Änderbarkeit bzw. Wartbarkeit: Eigenschaft eines Softwareproduktes, geändert werden zu können. Änderungen umfassen Fehlerbehebung und Anpassungen an veränderte Rahmenbedingungen und Anforderungen. Übertragbarkeit bzw. Portierbarkeit: Eigenschaft eines Softwareproduktes, in andere Hardware-/Softwareumgebungen übertragen werden zu können.

Diese Qualitätsmerkmale werden in ISO/IEC 9126 mit Teilmerkmalen näher beschrieben.

Prozessorientierte Sicht Die prozessorientierte Sicht des QM basiert auf folgenden grundlegenden Annahmen:  

Qualitativ hochwertige Prozesse bringen mit einer hohen Wahrscheinlichkeit qualitativ hochwertige Produkte hervor. Es ist effizienter, die Qualität von Prozessen zu gewährleisten, als die Qualität von Produkten zu prüfen und nach deren Fertigstellung Abweichungen von den Anforderungen zu beheben.

Ein prozessorientiertes QM konzentriert sich demzufolge auf Planungs-, Steuerungs- und Realisierungsprozesse. Diese Ausrichtung zielt nicht nur auf hohe Produktqualität, sondern auch auf niedrige Entwicklungskosten und hohe Termintreue. Für das Informationsmanagement relevante Prozesse werden in einschlägigen Leitfäden erörtert, z. B. im CMMI (vgl. Lerneinheit MEQUA), in CobiT (vgl. Lerneinheit GOVER) oder in ITIL (vgl. Lerneinheit SEMAN). Qualitätskriterien für Prozesse werden in Reifegradmodellen, wie z. B. im CMMI (vgl. Lerneinheit MEQUA) definiert. Reife wird dort als Ausmaß verstanden, in dem ein Prozess geplant, definiert, dokumentiert, quantitativ kontrolliert und gesteuert sowie kontinuierlich verbessert wird. Diese Prozesseigenschaften sind Voraussetzungen dafür, dass Produktqualitäts-, Kosten- und Terminziele mit hoher Wahrscheinlichkeit erreicht werden.

Ganzheitliche bzw. umfassende Sicht Die ganzheitliche bzw. umfassende Sicht wird auch als Total Quality Management (TQM) bezeichnet. Sie entstand durch Qualitätsprinzipien, die für die Waffenproduktion während des Zweiten Weltkriegs in den USA entwickelt und später u. a. durch Deming in Japan bekannt gemacht und dort weiter entwickelt wurden. TQM lässt sich durch folgende Grundsät-

Qualitätsmanagement (QUALM)

153

ze charakterisieren, welche in ähnlicher Weise z. B. von Mellis/Herzwurm/Stelzer oder in ISO 9000 beschrieben wurden:      

   



Kundenorientierung: Alle Aktivitäten eines Unternehmens sind darauf ausgerichtet, aktuelle und zukünftige Bedürfnisse der Kunden zu verstehen, Anforderungen zu erfüllen und Erwartungen zu übertreffen. Qualitätsorientierung: Qualitätsverbesserung hat Vorrang vor Kostensenkung und Beschleunigung von Prozessen. Qualitätsverbesserung wirkt sich auf die Erreichung anderer Ziele positiv aus. Prozessorientierung: Ein erwünschtes Ergebnis lässt sich effizienter erreichen, wenn Aufgaben in Form von Prozessen geplant, gesteuert und kontrolliert werden. Systemorientierung: Das Verständnis eines Unternehmens als System von miteinander in Wechselbeziehungen stehenden Prozessen trägt dazu bei, Effektivität und Effizienz des Unternehmens zu verbessern. Führung: Führungskräfte schaffen geeignete Rahmenbedingungen, die es den Mitarbeitern ermöglichen, QM-Maßnahmen zu verwirklichen und sich für die Erreichung der Ziele des Unternehmens einzusetzen. Einbeziehung aller Personen: Alle Mitglieder eines Unternehmens sind für Qualität zuständig, aber in unterschiedlicher Weise. Fach- und Führungskräfte werden an Entscheidungs- und Gestaltungsprozessen beteiligt. Ihre unterschiedlichen Fähigkeiten, Interessen und Ziele werden dabei berücksichtigt. Interne Kunden-Lieferanten-Beziehungen: Jede betriebliche Leistung wird für interne oder für externe Kunden erbracht. Kunden definieren Anforderungen und bewerten die Qualität der Leistungen. Kooperationsprinzip: Ein Unternehmen strebt gemeinsam mit seinen Lieferanten und Kooperationspartnern danach, die Leistungsfähigkeit zu erhöhen. Rationalitätsprinzip: Alle Unternehmensaktivitäten verfolgen klar definierte Ziele und werden nachvollziehbar begründet. Entscheidungen werden auf der Grundlage von Zahlen, Daten und Fakten getroffen. Ständige Verbesserung: Ein Unternehmen strebt danach, seine Leistungsfähigkeit kontinuierlich zu verbessern. Jede betriebliche Leistung wird permanent daraufhin untersucht, wie sie verbessert werden kann. Qualität ist demnach ein Ideal, das ständig verfolgt werden muss. Totalitätsprinzip: Alle Mitglieder eines Unternehmens streben danach, dass alle Elemente des Unternehmens (Strukturen und Abläufe, Produkte, Projekte und Prozesse) permanent alle relevanten Anforderungen erfüllen.

Qualitätskosten Slaughter/Harter/Krishnan differenzieren Qualitätskosten in Konformitätskosten und Nonkonformitätskosten. Konformitätskosten sind Kosten, die durch die Gesamtheit der QMMaßnahmen entstehen. Dazu zählen Fehlerverhütungskosten sowie Kosten für Qualitätsprüfung. Nonkonformitätskosten sind Kosten, die als Folge von Fehlern entstehen. Sie werden deshalb auch als Fehlerfolgekosten bezeichnet und können in interne und externe Fehlerfolgekosten unterschieden werden. Interne Fehlerfolgekosten werden durch die Suche nach und Behebung von Fehlern sowie die nach der Fehlerbehebung erneut notwendigen Prüfungen

154

Strategische Aufgaben des Informationsmanagements

verursacht. Externe Fehlerfolgekosten entstehen während des Betriebs bzw. beim Kunden. Hierzu zählen die finanziellen Auswirkungen möglicher, durch Fehler verursachter Schäden sowie Kosten für Fehlerbehebung und erneute Auslieferung des fehlerhaften Produkts, z. B. in Form von Softwarepatches. Eine Annahme des modernen QM ist, dass Nonkonformitätskosten in der Regel deutlich höher sind als Konformitätskosten, wodurch Investitionen in QM auch wirtschaftlich gerechtfertigt sind. Crosby hat dies in dem Buchtitel „Quality is free“ prägnant zusammengefasst.

Qualitätsmanagementsysteme Mit dem Begriff Qualitätsmanagementsystem (QM-System) werden Struktur- und Ablauforganisation einschließlich aller Prinzipien, Methoden, Verfahren und Werkzeuge bezeichnet, die zur Umsetzung der Qualitätspolitik eines Unternehmens notwendig sind. Abbildung QUALM-1 stellt die Elemente eines prozessorientierten QM-Systems nach ISO 9000 dar. Sie veranschaulicht, dass Ausgangs- und Endpunkt des QM die Kunden sind, die sowohl Anforderungen an zu entwickelnde Produkte definieren als auch bewerten, ob diese Anforderungen erfüllt wurden. Ständige Verbesserung des Qualitätsmanagementsystems Kunden (u.a. interessierte Parteien)

Verantwortung der Leitung Kunden (u.a. interessierte Parteien)

Anforderungen

Management von Ressourcen

Eingabe

Messung, Analyse und Verbesserung

Produktrealisierung

Legende:

Zufriedenheit

Produkt

Ergebnis

Wertschöpfung Information

Abb. QUALM-1: Elemente eines QM-Systems (Quelle: nach ISO 9000)

Die Verantwortung der Leitung im Rahmen des QM besteht insbesondere darin, folgende Aufgaben auszuüben:   

Qualitätspolitik und Qualitätsziele formulieren sowie aktualisieren, Qualitätsbewusstsein und Motivation zur Umsetzung des QM fördern, sicherstellen, dass sich das ganze Unternehmen an Kundenanforderungen orientiert,

Qualitätsmanagement (QUALM)

    

155

gewährleisten, dass geeignete Prozesse umgesetzt sind, um Kundenanforderungen und Qualitätsziele erreichen zu können, sicherstellen, dass ein wirksames und effizientes QM-System existiert, erforderliche Ressourcen für das QM zur Verfügung stellen, QM-System regelmäßig bewerten und über Maßnahmen zur Qualitätspolitik und zu den Qualitätszielen sowie zur Verbesserung des QM-Systems entscheiden.

In den Verantwortungsbereich der Leitung fällt auch das Management von Ressourcen, d. h. Ressourcen zu planen und bereitzustellen, die notwendig sind, um ein QM-System zu implementieren, aufrechtzuerhalten und ständig zu verbessern sowie die Kundenzufriedenheit zu erhöhen. Dies erfordert die Bereitstellung von angemessen befähigten, geschulten und motivierten Personen, Infrastruktur (z. B. Hilfsmittel und unterstützende Dienstleistungen), angemessene Arbeitsumgebung (z. B. Räume, Arbeitsbedingungen, Sozialkontakte), Information (Informationsbedarf befriedigen, angemessene IT-Ausstattung), die Zusammenarbeit mit Lieferanten und Kooperationspartnern sowie natürliche und finanzielle Ressourcen. Produktrealisierung im Sinne der ISO 9000 umfasst die gesamte Leistungserstellung einschließlich der Unterstützungsprozesse. Relevante Ziele sind Erhöhung der Produktqualität (Erfüllung von Kundenanforderungen) sowie Senkung von Zeit (Termintreue, Time-tomarket) und Kosten (Entwicklungs- sowie Produktkosten). Dies soll durch folgende Maßnahmen erreicht werden: Kommunikation mit Kunden, um Anforderungen abzustimmen, Planung, Steuerung und Dokumentation von Entwicklungs-, Beschaffungs- und Leistungserstellungsprozessen sowie Überprüfung, ob die Prozesse mit den festgelegten Anforderungen konform sind. Messung, Analyse und Verbesserung soll sicherstellen, dass Beurteilungen von Produkten und Prozessen sowie des QM-Systems nicht nur auf Schätzungen oder Mutmaßungen beruhen, sondern möglichst auf Zahlen, Daten und Fakten. Um eine geeignete Datengrundlage zu erhalten, wird empfohlen, die Kundenzufriedenheit regelmäßig zu messen, interne Audits (vgl. Lerneinheit MEQUA) zu nutzen, um den Reifegrad des QM-Systems zu bestimmen, Finanzkennzahlen zu verwenden, um die Leistungsfähigkeit des Unternehmen zu bewerten sowie mit Hilfe von Produktprüfungen Ursachen für Fehler zu ermitteln, um diese vermeiden zu können. Im Rahmen des umfassenden QM werden alle Objekte der ständigen bzw. kontinuierlichen Verbesserung unterworfen, d. h. Produkte, Projekte, Prozesse, Systeme und das gesamte Unternehmen. Ständige Verbesserung umfasst sowohl revolutionäre, Bahn brechende Innovationen als auch evolutionäre, inkrementelle Veränderungen. Es soll nicht nur auf Fehler reagiert, sondern aktiv nach Verbesserungsmöglichkeiten gesucht werden. Anhaltspunkte dafür geben z. B. Marktanalysen, Kundenzufriedenheitsmessungen, Benchmarking mit Wettbewerbern, das betriebliche Vorschlagswesen sowie Messungen von Produkten und Prozessen.

156

Strategische Aufgaben des Informationsmanagements

Aufgaben des Qualitätsmanagements Abbildung QUALM-2 stellt die Aufgaben des QM gemäß ISO 9000 im Zusammenhang dar: Festlegen der Qualitätspolitik und der Qualitätsziele, Qualitätsplanung, Qualitätslenkung und -prüfung, Qualitätssicherung sowie Qualitätsverbesserung. Unternehmensstrategie umfasst

QM-System

wird implementiert durch

Qualitätspolitik führt zu

wird konkretisiert durch

Qualitätsziele

Qualitätsmanagement besteht aus

Qualitätsplanung

Qualitätslenkung und Qualitätsprüfung

Qualitätssicherung

Qualitätsverbesserung

Abb. QUALM-2: Aufgaben des QM (Quelle: nach ISO 9000)

Qualitätspolitik und Qualitätsziele Die Qualitätspolitik wird durch die Unternehmensleitung aus der Unternehmensstrategie (vgl. Lerneinheit STRAT) abgeleitet. Sie dient dazu, Schwerpunkte für das QM zu setzen und alle QM-Maßnahmen auf die Erreichung der Unternehmensziele auszurichten. Qualitätsziele helfen, die grundsätzlich formulierte Qualitätspolitik für einzelne Unternehmensbereiche, Produkte, Prozesse oder Projekte zu spezifizieren. Das QM-System realisiert die in Qualitätspolitik und Qualitätszielen formulierten Vorgaben.

Qualitätsplanung Die Verantwortung für die Qualitätsplanung liegt bei der Unternehmensleitung. Sie sollte sich auf die Leistungserstellungsprozesse konzentrieren, die für die Erreichung der strategischen Qualitätsziele vordringlich sind. Wesentlicher Bestandteil der Qualitätsplanung ist die Festlegung von Qualitätszielen für alle relevanten Objekte, d. h. Produkte, Prozesse und Systeme. Diese Ziele sollen im Einklang mit der Qualitätspolitik stehen. Die Zielerreichung soll messbar sein. Zur Qualitätsplanung gehört auch die Planung des QM-Systems, welches Voraussetzungen schafft, um die Qualitätsziele erfüllen zu können. Die Unternehmensleitung hat dafür zu sorgen, dass die Funktionsfähigkeit des QM-Systems auch bei Änderungen gewährleistet bleibt. Ferner muss sie Ressourcen zur Verfügung stellen, die zur Erreichung der Qualitätsziele notwendig sind.

Qualitätslenkung und Qualitätsprüfung Mit Qualitätslenkung bezeichnet die ISO 9000 den Teil des QM, der auf die Erfüllung von Qualitätsanforderungen ausgerichtet ist. Wesentliches Element der Qualitätslenkung ist die

Qualitätsmanagement (QUALM)

157

Qualitätsprüfung. Sie ermittelt, ob ein dem QM unterworfenes Objekt Anforderungen erfüllt. Eine der Annahmen des prozessorientierten QM besagt, dass Fehlerverhütung effizienter ist als Fehlerbehebung. Ziel der Qualitätsprüfung ist deshalb nicht nur, Fehler zu finden, um diese beheben zu können, sondern auch, Fehlerursachen zu identifizieren, um weitere Fehler zu verhüten. Für die Objekte des QM sind unterschiedliche Methoden der Qualitätsprüfung entwickelt worden: Testen und Inspektionen für Produkte, Reviews und Reifegradmodelle für Prozesse sowie Audits und Exzellenzmodelle für Organisationen (vgl. Lerneinheit MEQUA).

Qualitätssicherung Qualitätssicherung bezeichnet im üblichen Sprachgebrauch (z. B. auch im V-Modell XT, vgl. Lerneinheit VOMOD) Tätigkeiten, die in einem QM-System verwirklicht sind. In der ISO 9000 wird damit aber der Teil des QM bezeichnet, der darauf ausgerichtet ist, Vertrauen zu erzeugen, dass Qualitätsanforderungen erfüllt werden. Dies kann z. B. durch den Aufbau und die Zertifizierung eines QM-Systems erreicht werden. Für Unternehmen bedeutet das, relevante Prozesse zu dokumentieren, sicherzustellen, dass sich alle Mitarbeiter an die dokumentierten Vorgaben halten und gegenüber einer unabhängigen Instanz nachzuweisen, dass die Vorgaben erstens eingehalten werden und dass sie zweitens wirksam sind.

Qualitätsverbesserung Die ständige Verbesserung des QM-Systems dient dazu, die Fähigkeit des Unternehmens zu erweitern, Qualitätsanforderungen zu erfüllen. Deming beschreibt vier Phasen der kontinuierlichen Verbesserung. Die als Plan-Do-Check-Act-Zyklus bekannten Phasen sind in Abbildung QUALM-3 dargestellt. In der Phase Plan wird ein Prozess oder eine Prozessverbesserung geplant. Die Phase Do beschreibt die Implementierung des Plans. In der Phase Check wird Plan Act geprüft, ob der geänderte Prozess relevante Ziele erreicht. In diesem Zusammenhang werden auch die mit Hilfe des Prozesses erzeugten Produkte evaluiert. Do Check Check umfasst darüber hinaus die Identifikation von Ursachen möglicher Abweichungen. In der Phase Act werden Ursachen für Soll/Ist-Abweichungen abgestellt sowie weitere Verbesserungen eingeleitet, standardisiert und stabilisiert. Abb. QUALM-3: Plan-Do-Check-Act-Zyklus Der Plan-Do-Check-Act-Zyklus ist aus dem in Japan entwickelten Kaizen (Veränderung zum Besseren) abgeleitet. Dementsprechend beschreibt der Zyklus nicht einzelne Projekte, sondern das ständige Streben nach Verbesserung auf allen Ebenen eines Unternehmens. Umfangreiche Verbesserungsvorhaben können in Form von Projekten realisiert werden. ISO 9000 schlägt folgende Maßnahmen für Verbesserungsprojekte vor:   

Analyse der Ist-Situation, um Ansatzpunkte für Verbesserungen zu erkennen, Festlegen von Zielen für Verbesserungen, Suche nach Lösungen, um diese Ziele zu erreichen,

158

   

Strategische Aufgaben des Informationsmanagements

Beurteilen der Lösungen und Auswahl einer Lösung, Implementierung der gewählten Lösung, Evaluierung der Ergebnisse, um zu ermitteln, ob die Ziele der Verbesserung erreicht wurden und Formalisieren der Änderungen.

Dokumentation im Qualitätsmanagement Dokumentation ist laut ISO 9000 kein Selbstzweck, sondern sollte zur Wertschöpfung beitragen. Dokumente sind Kommunikationsinstrumente. Sie helfen, Mitarbeiter zu schulen und sicherzustellen, dass Aufgaben und Prozesse konsistent und transparent ausgeführt werden. Im Rahmen von internen und externen Audits, insbesondere im Zusammenhang mit einer Zertifizierung, ist die Dokumentation eine wichtige Grundlage um nachzuweisen, dass Prozesse und Produkte spezifizierten Anforderungen genügen. Ferner hilft Dokumentation, die Wirksamkeit des QM-Systems zu beurteilen und dieses kontinuierlich zu verbessern. Art und Umfang der Dokumentation hängen von Art, Größe und Komplexität des Unternehmens und der QM-Objekte sowie von Kundenanforderungen und rechtlichen Anforderungen ab. Jedes Unternehmen kann Art, Umfang und geeignete Medien der Dokumentation selbst festlegen. Insbesondere bei häufig zu aktualisierenden Dokumenten, die an verschiedenen Stellen benötigt werQM-Handbuch den, ist es üblich, die DokuQM-Pläne mentation mit Hilfe von InSpezifikationen formationssystemen (z. B. in Leitfäden einem Intranet) zu realisieren. Verfahrensanweisungen und Arbeitsanleitungen Abbildung QUALM-4 gibt Qualitätsaufzeichnungen eine Übersicht über die in der ISO 9000 empfohlenen DokuAbb. QUALM-4: Dokumenttypen (Quelle: nach ISO 9000) menttypen. Das QM-Handbuch stellt das QM-System für Kunden, Mitarbeiter und andere Interessengruppen dar. QM-Pläne beschreiben, wie das QM-System auf ein spezifisches Produkt, ein Projekt, ein System oder einen Vertrag angewendet wird. Spezifikationen enthalten Anforderungen an Objekte des QM. Leitfäden geben Empfehlungen oder Vorschläge für bestimmte Prozesse bzw. Aufgaben. Verfahrensanweisungen und Arbeitsanleitungen beschreiben, wie Tätigkeiten auszuführen sind. Qualitätsaufzeichnungen liefern Nachweise über durchgeführte Tätigkeiten und erreichte Ergebnisse.

Forschungsbefunde Harter/Krishnan/Slaughter analysieren den Zusammenhang zwischen der mit dem CMM (vgl. Lerneinheit MEQUA) gemessenen Reife von Softwareentwicklungsprozessen sowie Softwareentwicklungskosten, -zeit und Softwareproduktqualität (Datenanalyse über 30 Softwareentwicklungsprojekte für ein im Kundenauftrag entwickeltes Material-Require-

Qualitätsmanagement (QUALM)

159

ments-Planning-System eines großen IT-Unternehmens in einem Zeitraum von 1984 bis 1996). Höhere CMM-Reifegrade führten zu geringeren Fehlerzahlen in den entwickelten Softwaresystemen, aber auch zu höheren Implementierungskosten und -zeiten. Die verbesserte Produktqualität ermöglichte eine Reduzierung der für die Systementwicklung insgesamt benötigten Zeit sowie der Gesamtkosten. Das bedeutet, dass die Investitionen in Softwareprozessverbesserung wirtschaftlich gerechtfertigt waren. Allerdings räumen die Autoren ein, dass sich die festgestellten Zusammenhänge nicht ohne weiteres auf andere Projekte und Unternehmen übertragen lassen.

Aus der Praxis Wagner et al. formulieren als Ergebnis eines Workshops zur Software-Qualitätsmodellierung und -bewertung im Rahmen der Software Engineering Konferenz 2008 Empfehlungen zur Entwicklung und Anwendung von Softwarequalitätsmodellen: Messungen von Softwarequalität sollen im Rahmen von Prozessverbesserungen eingeführt werden, um Synergieeffekte zu nutzen. Der Aufbau von Messkompetenz ist in der Regel ein mehrjähriger Prozess; Softwaremessungen sollten deshalb nicht mit zu ambitionierten Zielen starten. Kosten und Nutzen von Softwarequalität und deren Messung sollten explizit dargelegt werden. Dazu gehört die Darstellung der Bedeutung von Softwarequalität für IT- und Geschäftsziele eines Unternehmens. Teilweise können Konsequenzen mangelnder Qualität in Form von Mehrkosten und Haftungsrisiken dargestellt werden. Der mittel- und langfristig positive Einfluss von Qualität auf Kosten und Termine muss explizit dargestellt werden. Auftragnehmer sollten gegenüber ihren Auftraggebern darauf bestehen, dass auch nichtfunktionale Anforderungen frühzeitig und präzise formuliert werden. Laut Wolle/Müller ist das IT-QM bei der DaimlerChrysler AG für die unternehmensweite Bereitstellung von Hilfsmitteln für das QM zuständig und eng mit dem Projektmanagement verzahnt. Eine besondere Herausforderung besteht darin, alle projekt- und betriebsrelevanten IT-Tätigkeiten in allen Geschäftsbereichen und Standorten des Konzerns durchgängig zu planen, zu steuern und zu kontrollieren. Es soll einerseits sichergestellt werden, dass im gesamten Konzern die Qualitätsanforderungen an Produkte und Prozesse durchgängig erfüllt werden, andererseits muss das QM bereichsbezogen praktikabel umgesetzt werden, um auf Besonderheiten von Unternehmensbereichen, Produkten und Prozessen eingehen zu können. Um dies sicherzustellen, wurde ein Rahmenwerk für das Projektmanagement etabliert, welches aus drei Ebenen besteht:   

Governance (vgl. Lerneinheit GOVER) legt Organisationsstrukturen, Rollen, Verantwortungsbereiche und Führungsprinzipien fest. Planung und Berichtswesen regelt Projektinitiierung, Finanzplanung, Risikomanagement und Projektdokumentation. Methoden und Werkzeuge empfiehlt Methoden für die Qualitätsverbesserung, wie das CMM (vgl. Lerneinheit MEQUA), Methoden für die Qualitätsprüfung, Best Practices, Projektmanagement-Werkzeuge und -Datenbanken.

Aus diesem Rahmenwerk können standortbezogene QM-Systeme abgeleitet werden.

160

Strategische Aufgaben des Informationsmanagements

Methodenverweise Evaluierungsmethoden (Lerneinheit EVALU); Methoden des Qualitätsmanagements (Lerneinheit MEQUA). Kontrollfragen 1. Wie ist Qualität im Zusammenhang mit der Informationsinfrastruktur definiert? 2. Welchen Beitrag leistet Qualitätsmanagement zur Erreichung der strategischen IT-Ziele? 3. Welches sind notwendige Elemente eines QM-Systems für den Betrieb der Informationssysteme eines Unternehmens? 4. Wie lassen sich die Prinzipien des umfassenden Qualitätsmanagements für die IT eines mittelständischen Unternehmens konkretisieren? 5. Welcher Zusammenhang besteht zwischen Qualitätsplanung, Qualitätsprüfung, Qualitätslenkung und Qualitätssicherung? Quellen Crosby, P. B.: Quality is Free. The Art of Making Quality Certain. New York 1979 Harter, D. E. / Krishnan, M. S. / Slaughter, S. A.: Effects of Process Maturity on Quality, Cycle Time, and Effort in Software Product Development. In: Management Science 4/2000, 451–466 Deming, W. E.: Out of the Crisis: Quality, Productivity and Competitive Position. Cambridge 1992 Mellis, W. / Herzwurm, G. / Stelzer, D.: TQM der Softwareentwicklung. Mit Prozeßverbesserung, Kundenorientierung und Change Management zu erfolgreicher Software. 2. A., Braunschweig/Wiesbaden 1998 Slaughter, S. A. / Harter, D. E. / Krishnan, M. S.: Evaluating the Cost of Software Quality. In: Communications of the ACM 8/1998, 67–73 Wagner, S. et al.: Softwarequalitätsmodelle. Praxisempfehlungen und Forschungsagenda. In: Informatik-Spektrum 1/2010, 37-44 Wolle, B. / Müller, V.: Prozessorientiertes IT-Qualitätsmanagement. In: HMD - Praxis der Wirtschaftsinformatik 232/2003, 66–78 Vertiefungsliteratur Garvin, D.A.: What Does „Product Quality“ Really Mean? In: Sloan Management Review 1/1984, 25–45 Imai, M.: KAIZEN – Der Schlüssel zum Erfolg im Wettbewerb. 2. A., München 2001 Pfeifer, T. / Schmitt (Hrsg.), R.: Masing. Handbuch Qualitätsmanagement. 5. A., München/Wien 2007 Informationsmaterial American Society for Quality (ASQ) http://asq.org Deutsche Gesellschaft für Qualität (DGQ) http://www.dgq.de European Foundation for Quality Management (EFQM) http://www.efqm.org European Organization for Quality (EOQ) http://www.eoq.org Forschungsgemeinschaft Qualität e.V. (FQS) http://www.dgq.de/forschung/fqs.htm Quality Austria http://www.qualityaustria.com Software Quality Journal (SQJ) http://www.springerlink.com/content/0963-9314 Swiss Association for Quality (SAQ) http://www.saq.ch Normen ISO 8402:1995 Qualitätsmanagement – Begriffe [zurückgezogen] ISO 9000:2005 Qualitätsmanagementsysteme – Grundlagen und Begriffe ISO 9001:2008 Qualitätsmanagementsysteme – Anforderungen ISO 9004:2009 Leiten und Lenken für den nachhaltigen Erfolg einer Organisation – Ein Qualitätsmanagementansatz ISO 10005:2005 Quality management systems - Guidelines for quality plans ISO 10006:2003 Quality management systems - Guidelines for quality management in projects ISO 19011:2002 Leitfaden für Audits von Qualitätsmanagement- und/oder Umweltmanagementsystemen ISO/IEC 9126-1:2001 Software engineering - Product quality -Part 1: Quality model ISO/IEC 14598-1:1999 Software product evaluation -Part 1: General overview ISO/IEC 15504-1:2004 Information technology - Process assessment - Part 1: Concepts and vocabulary ISO/IEC 25000:2005 Software engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Guide to SquaRE ISO/IEC 25010:2011 Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models

Technologiemanagement (TECHM) Lernziele Sie kennen den Zweck des Technologiemanagements und können den Technologiebegriff und die verschiedenen Technologiearten erklären. Sie kennen die Aufgaben des Technologiemanagements und können diese erläutern. Sie erkennen den Zusammenhang zwischen Technologiemanagement und strategischer IT-Planung. Sie kennen Ansätze zur Institutionalisierung des Technologiemanagements und können deren Zweckmäßigkeit beurteilen.

Definitionen und Abkürzungen Angebot (tender) = zeitlich befristeter Vertragsantrag eines potenziellen Auftragnehmers an einen potenziellen Auftraggeber über die Realisierung eines Beschaffungsprojekts. Angebotsanalyse (tender analysis) = Untersuchung und Evaluierung von Angeboten mit dem Ziel, das optimale Angebot zu bestimmen. ASP = Application Service Provider oder Application Service Providing. Ausschreibung (tendering) = Vorgang der Einholung von Angeboten auf Grundlage definierter Anforderungen (z. B. in einem Pflichtenheft). B2B = Business to Business. BITKOM = Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V., Verband der deutschen Informations- und Telekommunikationsbranche, Berlin. Evaluierung (evaluation) = zielbezogene Beurteilung von Objekten auf Grundlage eines Systems von relevanten Eigenschaften (Evaluierungskriterien). Synonym: Evaluation. Innovation (innovation) = auf neuen Erkenntnissen beruhende Änderung eines Systems, die zu neuartigen wirtschaftlichen Realisierungen führt. Lebenszyklus (life cycle) = in sich abgeschlossene Phase der Lebensdauer eines Objekts (z. B. ein Softwareprodukt), aus der es keine Rückkehr in eine frühere Phase gibt. Ontologie (ontology) = formales Modell einer Anwendungsdomäne, das dem Austausch und Verteilen von Wissen zwischen menschlichen und maschinellen Akteuren dient. schlüsselfertiges System (turnkey system) = Informationssystem, das dem Anwender mit allen Komponenten aus einer Hand (z. B. von einem ASP) produktiv nutzbar zur Verfügung gestellt wird. Technologieart (kind of technology) = Ordnung der Technologien nach ihrem Veränderungspotenzial in Basis-, Schlüssel-, Schrittmacher- und Zukunftstechnologie. technologischer Korridor (technological trajectory) = Phänomene, die dafür verantwortlich sind, dass ein Unternehmen aus ökonomischen und/oder technischen Gründen an bestimmten Technologien festhält, obwohl neue Technologien zur Verfügung stehen. Verfahren (procedure) = festgelegte Art und Weise, eine Tätigkeit oder einen Prozess auszuführen (vgl. DIN EN ISO 9000). Wirksamkeitsanalyse (effectiveness analysis) = Untersuchung eines Systems mit dem Zweck der Evaluierung unter dem Formalziel Wirksamkeit. Wirtschaftlichkeitsanalyse (efficiency analysis) = Untersuchung eines Systems mit dem Zweck der Evaluierung unter dem Formalziel Wirtschaftlichkeit.

162

Strategische Aufgaben des Informationsmanagements

Zweck des Technologiemanagements Zweck des Technologiemanagements ist es, den im Unternehmen bestehenden, bekannten und prognostizierten Veränderungsbedarf von Funktionalität und Leistung der Planung, Durchführung und Kontrolle der betrieblichen Aufgaben (z. B. Abwicklung der Geschäftsprozesse) zu bestimmen, der durch die IT befriedigt werden kann. Daraus ergeben sich sowohl strategische als auch administrative Aufgaben. Typische strategische Aufgabe ist die langfristige, unternehmensweite Maßnahmenplanung, deren Ergebnis als strategischer Technologieeinsatzplan vorliegt (vgl. Lerneinheit SPLAN). Administratives Technologiemanagement basiert auf der strategischen IT-Planung, insbesondere der Maßnahmenplanung, welche den Handlungsspielraum für die Aufgabenträger des administrativen Technologiemanagements bestimmt. Typische administrative Aufgabe ist die Technologiebeschaffung auf Grund von Technologieeinsatzentscheidungen, die durch die Evaluierung alternativer Technologien gestützt werden (vgl. Lerneinheit EVALU). Die Erläuterung der Aufgaben des Technologiemanagements erfordert eine Klärung des Technologiebegriffs mit der Unterscheidung zwischen Technologie und Technik, wobei Technik von Menschen erzeugte Gegenstände (Artefakte) sowie deren Herstellung und Benutzung im Rahmen zweckorientierten Handelns bedeutet (vgl. VDI-Richtlinie 3780). Technologie beschreibt die Gesamtheit der anwendbaren und tatsächlich angewendeten Arbeits-, Entwicklungs-, Produktions- und Implementierungsverfahren der Technik. Meist werden unter Technologie sowohl die Technik als auch die Verfahren verstanden. Technologie ist also der weitere, Technik der engere Begriff. Technologie umfasst auch Methoden, Techniken und Werkzeuge für die Entwicklung (Analyse, Entwurf, Implementierung) und Einführung sowie das Management und die Nutzung von Informationssystemen. Veränderungspotenzial Basistechnologien

Schlüsseltechnologien Schrittmachertechnologien

Zukunftstechnologien

Gegenwart

Zeit

Abb. TECHM-1: Zeitliches Zusammenwirken der Technologiearten (Quelle: Batelle-Institut)

Abbildung TECHM-1 zeigt die vier Technologiearten und ihr zeitliches Zusammenwirken. Unterscheidungsmerkmal ist das Veränderungspotenzial oder Innovationspotenzial, über das eine vorhandene Technologie verfügt bzw. das von einer neuen Technologie erwartet wird. Potenzial ist das mit Metriken messbare Ausmaß, in dem Strukturen und Prozesse im

Technologiemanagement (TECHM)

163

Unternehmen verändert werden können (z. B. Reduzierung von Durchlaufzeit, Verbesserung von Qualität) bzw. neue Strukturen (z. B. durch Verringerung der Berichtsebenen) und neue Prozesse (z. B. Geschäftsprozesse im B2B für Electronic Procurement) geschaffen werden können. Die Technologiearten werden wie folgt erläutert:    

Basistechnologie (basic technology) ist eine vorhandene Technologie, deren Veränderungspotenzial weitgehend ausgeschöpft ist. Schlüsseltechnologie (key technology) ist eine vorhandene Technologie, die noch über ein erhebliches Veränderungspotenzial verfügt. Schrittmachertechnologie (pacemaker technology) ist eine im Entwicklungsstadium befindliche Technologie, von der ein erhebliches Veränderungspotenzial erwartet wird. Zukunftstechnologie (future technology) ist eine sich abzeichnende, noch nicht im Entwicklungsstadium befindliche Technologie, von der ein erhebliches Veränderungspotenzial erwartet wird.

Idealtypisch gesehen durchlaufen Technologien einen Lebenszyklus, indem Zukunftstechnologien zu Schrittmachertechnologien, diese zu Schlüsseltechnologien und schließlich diese zu Basistechnologien werden. Was heute Basistechnologie ist (z. B. Client/Server), war einmal Schlüsseltechnologie, was heute Schlüsseltechnologie ist (z. B. neue Internettechnologien), wird morgen Basistechnologie sein usw. Nicht alle Technologien haben diesen Lebenszyklus, da nicht jede Zukunftstechnologie zur Schrittmachertechnologie, dann zur Schlüsseltechnologie und schließlich zur Basistechnologie wird. Beispielsweise wird eine Schlüsseltechnologie nicht zur Basistechnologie, weil sie durch eine andere neue Technologie verdrängt wird (z. B. wurde Bildschirmtext durch das Internet verdrängt, ohne Basistechnologie zu werden). Auch können durch Kombination mehrerer Basistechnologien neue Schlüsseltechnologien entstehen (z. B. entstand Telefax durch Kombination von Telefonie und Kopieren und interaktives Fernsehen entstand durch Kombination von Fernsehen und Personal Computing).

Aufgaben des Technologiemanagements Technologiemanagement wird wie folgt in Aufgaben gegliedert:        

Beobachten der Technologieentwicklung, Beeinflussen der Technologieentwicklung, Bestimmen des Technologiebedarfs (des Unternehmens als Ganzes, einzelner Geschäftsfelder, Struktureinheiten, Geschäftsprozesse und Projekte oder einzelner Benutzer), Vorbereiten und Fällen von Technologieeinsatzentscheidungen (Ex-ante-Evaluierung), Decken des Technologiebedarfs (Technologiebeschaffung und -einsatz), Evaluieren des Technologieeinsatzes (Ex-post-Evaluierung), Verwalten des Technologiebestands (einschließlich Vertragsbestand) und Technologiediffusion im Unternehmen.

Beobachten der Technologieentwicklung Beobachten der Technologieentwicklung ist Marktforschung, deren primäres Objekt der ITMarkt ist. Er umfasst das gesamte Technologieangebot, also IT-Produkte (Hardware, Soft-

164

Strategische Aufgaben des Informationsmanagements

ware und Sonstiges) und IT-Dienstleistungen (z. B. Leistungen von Outsourcing-Gebern, Beratungsdienstleistungen), und reicht bis zur Bereitstellung von Sachmittelgesamtheiten wie Anwendungssoftware durch ASP oder schlüsselfertige Systeme durch Systemhäuser als Leistungsgeber. Umfassendes und systematisches Beobachten der Technologieentwicklung erfasst neben dem IT-Markt auch andere zugängliche Quellen (z. B. Pilotanwender, Messen, Kongresse, Fachliteratur, Internet). Jedes Unternehmen, das Informations- und Kommunikationstechnologien einsetzt, beobachtet die Technologieentwicklung auf dem IT-Markt. Möglichkeiten zur Differenzierung ergeben sich durch eine Form der Marktbeobachtung, die strategisch darauf ausgerichtet, das Entstehen neuer Technologien bereits anhand so genannter schwacher Signale und damit früher, zumindest nicht später als die Mitbewerber zu erkennen. Zeit ist ein Erfolgsfaktor für das Technologiemanagement. Dies gilt besonders dann, wenn eine aggressive IT-Strategie verfolgt wird (vgl. Lerneinheit STRAT) und die Ausschöpfung des Leistungspotenzials der Informationsfunktion für den Unternehmenserfolg bestimmend ist. Hammer/Champy (132) haben das so ausgedrückt: „Wer seine Strategie auf der Grundlage der heute auf dem Markt angebotenen Möglichkeiten aufbaut, wird stets jenen Konkurrenten hinterherlaufen, die bereits die zukünftige Entwicklung vorweggenommen haben. Diese Mitbewerber wissen, wie sie eine Technologie nutzen werden, bevor sie verfügbar ist, so dass sie dann bei der tatsächlichen Markteinführung einsatzbereit sind.“ Die Art der Inanspruchnahme des IT-Markts wird zwar durch strategische Entscheidungen festgelegt, muss aber in jedem Beschaffungsfall präzisiert und begründet werden. So ist die Entscheidung, für Kern-Geschäftsprozesse Individualsoftware einzusetzen, strategischer Art. Für jedes IT-Projekt muss jedoch geprüft werden, ob Individualsoftware mit eigenen Mitarbeitern oder im Auftrag fremd erstellt wird. Wegen der Vielfalt des Technologieangebots und seiner Unübersichtlichkeit ist es hilfreich, Technologien und betriebliche Aufgaben zu Anwendungstypen zu ordnen. Anwendungstypen sind eine Klassifikation informationstechnologischer Anwendungen aus Sicht der Geschäftsprozesse. Sie erleichtern nicht nur die Technologiebeobachtung, sondern helfen auch, Entscheidungen über den Technologieeinsatz ohne detaillierte Technologiekenntnis vorzubereiten. Anwendungstypen verringern durch Abstraktion die Vielzahl der möglichen Technologieanwendungen auf ein beherrschbares Ausmaß. Beispiele für Anwendungstypen sind Internet, Intranet, Workflow-Management-Systeme, Data Warehouses, wissensbasierte Systeme und Entscheidungsunterstützungssysteme.

Beeinflussen der Technologieentwicklung Verfügbares und erwartetes Technologieangebot können in der Regel durch einzelne, tatsächliche oder potenzielle Anwender nicht beeinflusst werden. Dass die Anwender in ihrer Gesamtheit die Technologieentwicklung beeinflussen, liegt auf der Hand, weil sich die Anbieter am aktuellen und am zukünftigen Bedarf der Anwender orientieren. Technologieentwicklung ist erfahrungsgemäß weit stärker angebotsorientiert als nachfrageorientiert. Impulse für die Technologieentwicklung und ihre Durchsetzung gehen primär von den Anbietern aus, die versuchen, für die Produkte dieser Entwicklung einen Bedarf zu wecken. Dies kann auch zu Entwicklungen führen, die – nach einer Periode von Implementierungsversuchen –

Technologiemanagement (TECHM)

165

für die Anwender negative Ergebnisse bringen, weil entweder die erwartete Wirksamkeit nicht erreicht wird oder trotz erreichter Wirksamkeit der Technologieeinsatz unwirtschaftlich ist (z. B. gemessen am ROCE = Return On Capital Employed). Die Möglichkeit des Beeinflussens der Technologieentwicklung durch Anwender nimmt aber tendenziell zu. Handlungsspielraum besteht besonders für große Unternehmen, deren spezifischer Technologiebedarf von einzelnen Anbietern auch wirtschaftlich vertretbar realisiert werden kann. Große Unternehmen haben die Möglichkeit, Entwicklungsdruck auszuüben. Diese Möglichkeit ist besonders dann gegeben, wenn Anwender bei der Planung des Technologiebedarfs im Sinne des strategischen und ganzheitlichen Ansatzes des Informationsmanagements vorgehen. So hat beispielsweise die frühere Chrysler Corp. jahrelang Ausschreibungen für ein Satelliten-Kommunikationssystem zur Unterstützung des Bestandsmanagements in den Teilelagern der Händler versendet, obwohl bekannt war, dass diese Technologie noch nicht am Markt verfügbar, also Schrittmachertechnologie war (zitiert nach Hammer/Champy, 133). Die Autoren fügen dem an: „Clevere Unternehmen können sich selbst ausmalen, wie sie eine Technologie einsetzen werden, selbst wenn die Entwickler noch an ihren Prototypen herumfeilen.“ Mehr Handlungsspielraum ergibt sich auch aus den modularen Architekturen von Hardware und Software, der Verfügbarkeit offener Systeme sowie daraus, dass leistungsfähige Entwicklungswerkzeuge zur Verfügung stehen, mit denen auf einen spezifischen Technologiebedarf (auch für Hardware) flexibel reagiert werden kann (z. B. der Entwurf kundenspezifischer Schaltungen).

Bestimmen des Technologiebedarfs Beim Bestimmen des Technologiebedarfs stehen langfristige, das Unternehmen als Ganzes betreffende Überlegungen im Vordergrund. Diese Aufgabe steht in engem Zusammenhang mit der strategischen IT-Planung (vgl. Lerneinheiten SITAN, SZIEL, STRAT und SPLAN). Der Technologiebedarf für die angebotsorientierte Infrastrukturplanung betrifft in der Regel Schlüsseltechnologien oder sogar Schrittmachertechnologien. Ein Nachfragedruck der Anwender im Unternehmen – dem Linienmanagement der Struktureinheiten und Geschäftsprozesse – auf das IT-Management besteht meist deshalb nicht, weil diese Technologien den Anwendern unbekannt sind. Der Technologiebedarf für die nachfrageorientierte Systementwicklung betrifft dagegen meist die den Anwendern bekannten Basistechnologien, seltener Schlüsseltechnologien. Mit dem Bestimmen des Technologiebedarfs werden Technologieeinsatzentscheidungen vorbereitet. Diese bewirken Veränderungen der Informationsinfrastruktur bezüglich ihrer Technologiekomponente so, dass Erfolgspotenzial geschaffen bzw. aufrechterhalten wird oder dass weiteres Erfolgspotenzial generiert wird, das für die Ausschöpfung des Leistungspotenzials der Informationsfunktion erforderlich ist. Der Aufbau anderer Erfolgspotenziale (z. B. im Personalbereich, vgl. Lerneinheit PERSM) folgt in der Regel als notwendige Ergänzung zum technologiebedingten Erfolgspotenzial und muss damit inhaltlich und zeitlich mit diesem abgestimmt sein, was Aufgabe der strategischen Maßnahmenplanung ist. Am Beispiel des Einsatzes von Collaboration Tools in Funktionsbereichen wie Konstruktion & Entwick-

166

Strategische Aufgaben des Informationsmanagements

lung zur Vermeidung von Sitzungen und Reisen kann dies am einfachen Fall verdeutlicht werden. Das Beispiel zeigt auch, dass dies angebots- oder nachfrageorientiert erfolgen kann. Das Bestimmen des Technologiebedarfs umfasst folgende Teilaufgaben:    

Identifizieren der Aufgaben, die durch Technologien unterstützt bzw. deren Technologieunterstützung verändert werden soll (Innovationspotenzial). Festlegen der Art der einzusetzenden Technologien (Leistungspotenzial). Bestimmen des Umfangs der einzusetzenden Technologien (Investitionshöhe). Bestimmen des Zeitraums für den Technologieeinsatz (Beginn und Ende der Technologienutzung bzw. Zeitpunkte der Investition und Desinvestition).

Beim Identifizieren der relevanten Aufgaben sind sowohl vorhandene Engpässe (so genannter Entwicklungsrückstau) als auch der zukünftige Bedarf an Informationssystemen (strategische Systementwicklung, vgl. Lerneinheit SPLAN) zu berücksichtigen. Der durch den Entwicklungsrückstau verursachte „Leidensdruck“ der Anwender, der mit dem nicht realisierbaren Nutzen bewertet werden muss, ist mit dem Leistungspotenzial zu vergleichen, das neue oder grundlegend veränderte Technologien verfügbar machen. Das Bestimmen des Technologiebedarfs orientiert sich meist an einer relativ eng abgegrenzten, projektbezogenen Wirtschaftlichkeitsanalyse (vgl. Lerneinheit WIRTA). Für ein strategisch ausgerichtetes Technologiemanagement reicht dies nicht aus, insbesondere dann nicht, wenn eine aggressive IT-Strategie verfolgt wird (vgl. Lerneinheit STRAT), keine einschlägigen Erfahrungen vorliegen und damit keine Daten zur Verfügung stehen, die eine fundierte Wirtschaftlichkeitsanalyse erlauben. Technologiemanagement muss daher alternativ oder zumindest ergänzend andere Auswahlkriterien verwenden, insbesondere das der Wirksamkeit (vgl. Lerneinheit SZIEL). So lässt sich beispielsweise ein Bedarf für den Einsatz semantischer Technologien nicht mit Kostenreduzierung und/oder monetärer Nutzensteigerung begründen, weil die Kosten steigen werden (z. B. für die Vernetzung von Ontologien) und der Nutzen (noch) nicht genau genug abgeschätzt werden kann. Mit einer Wirksamkeitsanalyse kann ex ante nachgewiesen werden, dass ein geforderter Veränderungsbedarf durch Funktionalität und Leistung einer neuen Technologie gedeckt werden kann, unabhängig von Kosten und Nutzen (im Beispiel der semantischen Technologien insbesondere bezüglich Aktualisierung der Ontologien als Evaluierungskriterium). Art und Ausmaß des Technologiebedarfs werden vom technologischen Korridor (nach Dosi) entscheidend bestimmt. Gründe für das Entstehen eines engen technologischen Korridors, der Innovation hemmt, sind:    

Vermeidung der mit Innovation verbundenen Unsicherheit, Schutz der getätigten Investitionen in Hardware und Software, Erhaltung des Know-hows, das im Umgang mit vorhandenen Technologien gewonnen wurde, und unzureichende Kenntnis über wesentliche Eigenschaften technologischer Alternativen.

Als Grund zum Ergänzen ist der Mangel an Innovationsfähigkeit, das heißt an der Fähigkeit zum Erkennen des Erfolgspotenzials neuer Technologien, um es in Kombination mit Änderungen der Struktur- und Ablauforganisation in Unternehmenserfolg umzusetzen. Innovati-

Technologiemanagement (TECHM)

167

onsfähigkeit kann nur selten im Zuge der strategischen Maßnahmenplanung geschaffen werden (vgl. Lerneinheit SPLAN), sondern bedarf eines umfassenden, unternehmensweiten Innovationsmanagements.

Technologieeinsatzentscheidungen Die Entscheidungen über die Art der einzusetzenden Technologien werden durch eine vergleichende Beurteilung der Technologieentwicklung und des Technologiebedarfs gesteuert. Bei dieser Beurteilung spielt der Charakter der IT-Strategie eine erhebliche Rolle (vgl. Lerneinheit STRAT). So unterscheiden sich die Art der einzusetzenden Technologien und auch der Zeitpunkt ihres Einsatzes erheblich, je nachdem, ob eine aggressive oder eine defensive Strategie verfolgt wird. Wie der Informationsbedarf für Technologieeinsatzentscheidungen ermittelt und gedeckt werden kann, bedarf einer gründlichen Analyse (Ex-anteEvaluierung), die insbesondere dann schwierig ist, wenn es sich um neue Technologien handelt, über die erst eine geringe Einsatzerfahrung vorliegt, so dass die Kosten nur schwer und der Nutzen kaum prognostiziert werden können (vgl. Lerneinheiten EVALU und WIRTA). Der Charakter der IT-Strategie hat auch Einfluss auf den Umfang der einzusetzenden Technologien. Verfolgt das Unternehmen eine aggressive Strategie, dann investiert es wesentlich mehr in den Technologieeinsatz, als wenn es eine defensive Strategie verfolgt. Das Bestimmen der richtigen Investitionshöhe ist eine kritische Entscheidung. Das Technologiemanagement muss versuchen, die Investitionshöhe so zu bestimmen, dass nicht zu viel, aber auch nicht zu wenig investiert wird. Wird zu viel investiert, kann sich der je Investitionseinheit realisierbare Nutzen drastisch verringern; wird zu wenig investiert, kann das vorhandene Innovationspotenzial nicht ausgeschöpft werden. Auch beim Festlegen des Nutzungsbeginns spielt der Charakter der IT-Strategie eine Rolle. Verfolgt das Unternehmen eine aggressive Strategie, dann investiert es früher in den Technologieeinsatz, als wenn es eine defensive Strategie verfolgt. Hier geht es also um das Bestimmen der richtigen Investitionszeitpunkte. Das Technologiemanagement muss versuchen, die Investitionszeitpunkte so festzulegen, dass nicht zu früh, aber auch nicht zu spät investiert wird. Wird zu früh investiert, entsteht nicht nur das Risiko, in eine nicht ausgereifte Technologie zu investieren, sondern auch das Risiko, das vorhandene Innovationspotenzial noch nicht ausschöpfen zu können. Wird zu spät investiert, bleibt das vorhandene Innovationspotenzial vorläufig ungenutzt. Beim Fällen von Technologieeinsatzentscheidungen sind die zwischen den Technologien bestehenden Abhängigkeiten zu beachten. Angesichts der Verbreitung proprietärer Systeme kann ein Wechsel der Hardwaretechnologie nicht ohne grundlegende Veränderung der Softwaresysteme erfolgen. Werden die Softwaresysteme selbst erstellt, bietet sich der gleichzeitige Übergang auf eine neue Softwaretechnologie an (z. B. von objektorientierten Programmiersprachen zu Webservices). Daraus resultieren erhebliche Anforderungen an das Technologiemanagement, die dadurch verstärkt werden, dass in der Regel mehrere Technologien über einen gewissen Zeitraum hinweg parallel beherrscht werden müssen (z. B. prozessorientierte und objektorientierte Programmiersprachen, vgl. Lerneinheit LEMAN).

168

Strategische Aufgaben des Informationsmanagements

Decken des Technologiebedarfs Das Decken des Technologiebedarfs erfolgt durch einen organisierten Beschaffungsprozess, der in die Teilaufgaben Ausschreibung, Angebotsanalyse, Auswahlentscheidung und Beschaffung gegliedert ist. Zweck der Ausschreibung ist es, alternative und vergleichbare Angebote über einen definierten Technologiebedarf und einen Bedarf an Zusatzleistungen zu erhalten. Die mit den Angeboten verfügbar gemachten und die zusätzlich beschafften und/oder bereits vorhandenen Informationen werden zur Angebotsanalyse und zur Bestimmung des optimalen Angebots verwendet. Die Ausschreibungsunterlagen bestehen bei konventioneller Vorgehensweise (im Unterschied zur prototyp-basierten Vorgehensweise) – neben dem Anschreiben – aus dem allgemeinen Teil, dem Lastenheft bzw. Pflichtenheft und dem Fragenkatalog. Im allgemeinen Teil werden den Anbietern die Rahmenbedingungen bekannt gegeben, unter denen die Ausschreibung durchgeführt wird. Er gibt auch die Struktur der Angebote vor, da sie nur bei gleicher Struktur so evaluiert werden können, dass die Evaluierungsergebnisse vergleichbar sind. Weitere Inhalte des allgemeinen Teils sind:       

Ziel und Zweck der Ausschreibung, Regelung der Zusammenarbeit zwischen Anwender und Anbieter in der Angebotsphase, Art der Behandlung von Rückfragen unter Angabe der zuständigen Kontaktperson(en), Termin und Übergabeort für die Angebote sowie Anzahl der Angebotsexemplare, Folgen, wenn Muss-Kriterien (K.o.-Kriterien) nicht erfüllt werden, Zeitplan für die Angebotsanalyse, für die Verhandlungen zwischen Anwender und Anbietern und für die Auftragserteilung und sonstige Informationen wie Regelungen über Vertraulichkeit, Urheberrecht und Rückgabe der Ausschreibungsunterlagen.

Im technischen Bereich (z. B. bei der Herstellung von Automatisierungssystemen, vgl. VDI/ VDE-Richtlinie 3694) wird zwischen Lastenheft und Pflichtenheft unterschieden. Im Lastenheft sind die Anforderungen aus Anwendersicht einschließlich aller Randbedingungen dokumentiert. Sie sollen, wenn irgend möglich, quantifiziert und prüfbar sein. Mit anderen Worten: Im Lastenheft wird definiert, was und wofür herzustellen oder zu beschaffen ist. Ein Lastenheft wird nur in Ausnahmefällen explizit erstellt, da der Liefer- und Leistungsumfang im Regelfall aus den Vertragsunterlagen hervorgeht. Im Pflichtenheft wird spezifiziert, wie und womit die im Lastenheft dokumentierten Anforderungen zu realisieren sind. Das Pflichtenheft entsteht also auf der Grundlage des vertraglich festgelegten Liefer- und Leistungsumfangs und enthält eine Spezifikation aller Forderungen an die Projektrealisierung mit einem Detaillierungsgrad, der idealer Weise folgenden Bedingungen genügt:  

Der Auftragnehmer ist in der Lage zu prüfen und zu bestätigen, dass bei Verwirklichung aller Forderungen der Vertrag erfüllt ist. Die Projektbearbeiter sind in der Lage, das Projekt ohne Rückfragen beim Auftraggeber und Verwendung weiterer Unterlagen auszuführen, sofern keine Änderungen zwischen Auftraggeber und Auftragnehmer vereinbart werden.

Technologiemanagement (TECHM)

169

Das Pflichtenheft wird nach Auftragserteilung vom Auftragnehmer erstellt, falls erforderlich unter Mitwirkung des Auftraggebers; letzteres ist in der Regel der Fall. Der Auftragnehmer prüft bei der Erstellung des Pflichtenhefts die Widerspruchsfreiheit und Realisierbarkeit der im Lastenheft genannten Anforderungen. Das Pflichtenheft bedarf der Genehmigung durch den Auftraggeber. Nach Genehmigung ist es die verbindliche Vereinbarung für die Abwicklung des Projekts. Das Pflichtenheft hat auch den Zweck, Konflikte zwischen Auftraggeber und Auftragnehmer zu erkennen und zu lösen und – wenn möglich – zu vermeiden (vgl. Lerneinheit VERMA). Bei IT-Projekten wird nicht immer explizit zwischen Lastenheft und Pflichtenheft, jedoch zwischen zwei Dokumenten unterschieden, nämlich einem Dokument als Teil der Ausschreibungsunterlagen, das als Grob-Pflichtenheft, und einem Dokument als Teil der Entwurfsdokumentation, das als Detail-Pflichtenheft bezeichnet werden kann. Das erste ist Grundlage für die Evaluierung von Angeboten bzw. Anbietern, das zweite für die Systementwicklung (Analyse, Entwurf und Implementierung). Der Zweck des Lastenhefts gemäß VDI/VDE-Richtlinie 3694 entspricht also dem des Grob-Pflichtenhefts, der des Pflichtenhefts dem des Detail-Pflichtenhefts. Im Folgenden wird auf das Pflichtenheft eingegangen. Mit der Beantwortung der im Fragenkatalog gestellten Fragen wird der Informationsbedarf des Ausschreibers gedeckt, der zur Evaluierung der Angebote erforderlich ist und der insbesondere Aussagen zu den im Kriterienkatalog genannten Evaluierungskriterien liefert. Die Fragen sollten so gestellt werden, dass sie möglichst mit quantitativen Größen (wie Zeiten, Mengen, Beträgen) oder mit ja/nein beantwortet werden können. Die Ausschreibungsunterlagen sollen nicht wahllos und nicht zu vielen Anbietern zur Verfügung gestellt werden; jedenfalls sind aber mehrere Anbieter zur unentgeltlichen Angebotslegung einzuladen. Für die Ausarbeitung der Angebote muss den Anbietern ein dem Umfang und der Komplexität des ausgeschriebenen Technologiebedarfs angemessener Zeitraum zur Verfügung gestellt werden, damit eine seriöse Angebotslegung möglich ist. Der Ausschreiber sollte erklären, dass er eine völlig freie Wahl unter verschiedenen Angeboten treffen will und dass daher mehrere Anbieter zur Abgabe eines Angebots aufgefordert wurden. Die Angebotsanalyse und -evaluierung bietet viele Ansatzpunkte für nicht kontrollierbare, subjektive Einflüsse. Objektivierung wird durch ein systematisches Auswahlverfahren mit vorher bestimmten Evaluierungskriterien (die im Kriterienkatalog systematisiert dargestellt sind) erreicht. Ziel es ist, das optimale Angebot zu bestimmen. (Wegen der weiteren Vorgehensweise wird auf Lerneinheiten WIRTA, NUTZW und EVALU verwiesen.) Das Ergebnis der Evaluierung muss analysiert und seine Zuverlässigkeit überprüft werden; das kann auf zwei Arten erfolgen:  

Überprüfen der Qualität der Evaluierung in Bezug auf Vollständigkeit des Kriterienkatalogs, Richtigkeit der verwendeten Informationen sowie korrekter Verfahrensanwendung. Durchführen einer Empfindlichkeitsanalyse, um zu prüfen, ob sich die Rangreihung der Angebote ändert, wenn bestimmte Annahmen der Evaluierung geändert werden (z. B. die Gewichtung der Evaluierungskriterien).

Zur Vorbereitung der Entscheidung über die Angebotsauswahl sollen alle Angebote dem Entscheidungsträger so präsentiert werden, dass der Evaluierungsprozess transparent wird

170

Strategische Aufgaben des Informationsmanagements

und das Ergebnis nachvollziehbar ist; dazu sind geeignete Präsentationstechniken erforderlich. Evaluierungsprozess und Evaluierungsergebnis sollten auch grafisch dargestellt werden. Als Darstellungsmethoden eignen sich besonders Leistungsprofile und Nutzenprofile.

Evaluieren des Technologieeinsatzes Dabei geht es um die Ex-post-Evaluierung eingesetzter Technologien (im Unterschied zur Ex-ante-Evaluierung beim Vorbereiten und Fällen von Technologieeinsatzentscheidungen). Ex-post-Evaluierung soll nach einem angemessenen Zeitraum (in der Regel mehrere Monate) nach Nutzungsbeginn erfolgen. Ihr Zweck ist es zu prüfen, ob die geplanten, bei der Exante-Evaluierung verwendeten Kriterienerträge und letztlich die mit dem Technologieeinsatz verfolgten strategischen Ziele (insbesondere Ausmaß der Zielerreichung bei Wirtschaftlichkeit und Wirksamkeit) erreicht wurden bzw. inwieweit dies der Fall ist und welches die Ursachen für Abweichungen sind. Informationen über Abweichungsursachen gehen in die zukünftige Bedarfsplanung ein. In der Praxis erfolgt Ex-post-Evaluierung nur selten, obwohl sie – insbesondere für die Verbesserung zukünftiger Technologieeinsatzentscheidungen – offensichtlich von großem Nutzen ist. (Vgl. die Forschungsbefunde dieser Lerneinheit und der Lerneinheit SPLAN mit weiteren Erläuterungen zur Evaluierungsstrategie sowie Lerneinheit EVALU zu den Evaluierungsmethoden.)

Verwalten des Technologiebestands Art und Menge der im Unternehmen verwendeten Technologien erfordern die systematische Verwaltung des Technologiebestands (Bestandsmanagement, häufig als Asset Management, zu dt. Vermögensmanagement bezeichnet) und der zu diesem Bestand bestehenden Verträge (Vertragsmanagement, vgl. Lerneinheit VERMA). Ziel des Bestandsmanagements ist die optimale Nutzung der Betriebsmittel, die mit Methoden der Kosten- und Leistungsrechnung gesteuert wird (vgl. Lerneinheit KOLER), sowie die Vermeidung nicht erforderlicher Betriebsmittel; durch Kostensenkung soll die Wirtschaftlichkeit verbessert werden. Die Erreichung dieses Ziels setzt u. a. voraus, dass die Lebenszyklen der Technologien geplant werden (Lebenszyklusmanagement, vgl. Lerneinheit LEMAN). Ein so genanntes AsssetManagement-System (AMS) ist ein Informationssystem, das alle Daten, die zu einem Vermögensteil gehören und für das Bestandsmanagement relevant sind, erfasst und verwaltet. Werkzeuge für das Asset Management erfassen Bestandsdaten aus verschiedenen Quellen, beispielsweise Konfigurationsdaten aus dem Inventory, Nutzerdaten aus der digitalen Nutzerverwaltung und Daten zur Kostenstellenbelastung aus der Kosten- und Leistungsrechnung. Typische Fragen des Bestandsmanagements sind:      

Welche Hardware wird wie genutzt? Welche Anwendungen laufen auf welchem Server? Wie ist ein bestimmter Arbeitsplatz konfiguriert? Welche Möglichkeiten des Upgradings gibt es? Welche Kosten hat ein Arbeitsplatz verursacht? Welche Investitionen stehen planmäßig in welchem Zeitraum an?

Durch die Beantwortung derartiger Fragen können IT-Aufgaben aus den Bereichen Planung (z. B. Kapazitätsplanung), Betrieb (z. B. automatische Inventur), Controlling (z. B. Ermitt-

Technologiemanagement (TECHM)

171

lung und Verfolgung der Lizenzkosten) und Helpdesk (z. B. Hilfe für von Störungen betroffene Arbeitsplätze) zielorientiert durchgeführt werden. Aufgaben dieser Art werden auch durch eine Configuration Management Database unterstützt (vgl. Lerneinheit SEMAN).

Technologiediffusion Rogers (5 f.) versteht Technologiediffusion als einen Prozess des sozialen Wandels, durch den Innovation über bestimmte Kanäle dauerhaft zwischen den Mitgliedern eines sozialen Systems kommuniziert wird. Veränderungen in der Struktur und den Funktionen des Systems werden sichtbar, wenn neue Ideen, die bestimmte Konsequenzen haben, gefunden, verbreitet und angenommen oder abgelehnt werden. Primäres Ziel der Technologiediffusion ist es, jedem Mitarbeiter die Qualifikation zu vermitteln, die zum sachgerechten Verwenden der eingesetzten Technologien erforderlich ist. Ein darüber hinausgehender Qualifikationsanspruch verlangt, dass das Linienmanagement, letztlich jeder einzelne Mitarbeiter, in der Lage ist, den Technologiebedarf „ihrer“ bzw. „seiner“ Arbeitsaufgaben erkennen und das Innovationspotenzial verfügbarer Technologien – insbesondere das von Schlüsseltechnologien – auf die eigene Arbeitssituation übertragen und damit Technologiebedarf ableiten zu können. Ein höherer Qualifikationsanspruch ist erforderlich, wenn Linienmanager in der Lage sein sollen, das Bestimmen des Technologiebedarfs und das Vorbereiten von Technologieeinsatzentscheidungen verantwortlich zu übernehmen; dies erfordert auch Fähigkeiten und Fertigkeiten in der Anwendung von Evaluierungsmethoden (vgl. Lerneinheit EVALU). Jede Art von Qualifikationsanspruch muss durch geeignete Qualifizierungsmaßnahmen (insbesondere Schulung und Coaching, vgl. Lerneinheit PERSM) befriedigt werden, für deren Verfügbarkeit das IT-Management zuständig ist. Sie werden als Inhouse-Dienstleistung von der IT-Abteilung, in Zusammenarbeit zwischen IT-Abteilung und externen Dienstleistern oder von externen Dienstleistern angeboten und durchgeführt.

Aufgabenträger des Technologiemanagements Technologiemanagement ist primär Rolle und nicht Institution. Aufgabenträger ist in erster Linie das Linienmanagement, das – gemeinsam mit dem IT-Management – neben anderen Rollen die des Technologiemanagers übernimmt. Als Unterstützungsfunktion im Sinne eines beratenden Requirements Management muss Technologiemanagement in besonderen Institutionen implementiert sein. Dafür bietet sich die IT-Abteilung an (vgl. Lerneinheit STRUK); sie übernimmt auch die Koordination der dezentral durch das Linienmanagement wahrgenommenen Aufgaben sowie deren Abstimmung mit den Technologieeinsatzentscheidungen (vgl. Lerneinheit SPLAN). Die Forderung nach Zuordnung von Aufgaben des Technologiemanagements an das Linienmanagement geht von der Annahme aus, dass Linienmanager – besser als andere Aufgabenträger – Innovationspotenzial erkennen und Technologiebedarf nach Art, Menge und Einsatzzeitpunkt artikulieren können. Sie sind mit ihrem Verantwortungsbereich die Instanzen, die für das Erkennen und die Nutzung des Innovationspotenzials zuständig sind, den Techno-

172

Strategische Aufgaben des Informationsmanagements

logieeinsatz begründen und Misserfolge ebenso vertreten müssen, wie sie an den Erfolgen des Technologieeinsatzes beteiligt sind. Dieser Ansatz ist auch von Müller-Zantop gemeint, wenn sie die „Verteilung von Rollen, die das IT-Personal im Unternehmensprozess übernimmt“ fordert und die Einrichtung eines „Büro für Unternehmens-IT“ vorschlägt. Dieser Institution wird je Geschäftsfeld ein ITManager zugeordnet, der mit einem Verbindungsmanager seines Geschäftsfeldes gemeinsam die Aufgaben des Technologiemanagements des Geschäftsbereichs wahrnimmt. Offensichtlich kann dieser Ansatz nur in großen Unternehmen verfolgt werden. Für Klein- und Mittelunternehmen ist eher typisch, dass der Geschäftsführer bzw. ein Mitglied der Geschäftsführung CEO und CIO (vgl. Lerneinheit STELL) einschließlich Technologiemanager in einer Person ist.

Forschungsbefunde Willcocks/Lester haben zur Ex-post-Evaluierung in der Installierungsphase (post implementation phase) u. a. festgestellt (mündliche explorative Befragung in 50 Unternehmen, schriftliche Befragung in weiteren 50 Unternehmen sowie Follow-up-Befragungen, Untersuchungszeitraum 12/1990 bis 11/1991): Die Zufriedenheit mit den verwendeten Evaluierungsverfahren und ihren Ergebnissen ist beim Linienmanagement und bei den Benutzern deutlich geringer als beim IT-Personal. Die Anzahl der Unternehmen, die evaluieren, nimmt mit dem Projektfortschritt ab; insbesondere wird von wesentlich mehr Unternehmen in der Vorstudie – im Vergleich zur Installierungsphase – evaluiert. Ein Zusammenhang zwischen der Art und der Branche der Unternehmen und der Auffassung über die Wirksamkeit der Evaluierung wurde nicht festgestellt. 20 % der Unternehmen evaluieren nicht in der Installierungsphase. Gründe sind: Nicht erforderlich; zu hohe Kosten; hält von anderer Arbeit ab; Ergebnisse werden in negativer Weise verwendet; zu bürokratisch. Diese und ähnliche Befunde führen zu der These, dass Unternehmen dazu tendieren, die Kosten für IT-Projekte als verlorene Kosten (sunk costs) zu betrachten, so dass Evaluierung nutzlos ist. Folgende Evaluierungsverfahren(bzw. Evaluierungskriterien) wurden verwendet (in Klammern die Häufigkeit der Nennungen): Kostenvergleich mit der Vorstudie (83 %); Kostenwirtschaftlichkeit (63 %); Produktqualität (53 %); Verfügbarkeit (49 %); Produktivität (44 %); Arbeitszufriedenheit (22 %) sowie weitere, seltener verwendete. Häufig verwendet wurde eine Kombination der sechs genannten Verfahren (15 %), der ersten fünf (15 %) und der ersten vier (10 %). Renkema stellt als Ergebnis einer Literaturanalyse zur Frage der Ex-post-Evaluierung bei Investitionen in Informations- und Kommunikationstechnologien u. a. fest (92): „Different studies show, however, that only few organizations pay attention and devote time to evaluations of investments after the implementation phase.” Weltz et al. berichten über Ergebnisse einer empirischen Breitenuntersuchung (Experteninterviews in Deutschland und den USA, Untersuchungszeitraum nicht genannt) und drei Fallstudien zum Verhältnis Technologieeinsatz und Management u. a. (zitiert nach Ortmann): 

Bei der Unternehmensplanung werden Geschäftspolitik und Technologie kaum miteinander verknüpft; die Entwicklung des Einen erfolgt ohne Beziehung zum Anderen.

Technologiemanagement (TECHM)

  

173

Der Gestaltungsspielraum wird auf die Technologie reduziert; organisatorische und personalwirtschaftliche Aspekte werden ausgeklammert. Die Veränderung von Managementfunktionen und Hierarchiestrukturen ist kein Ziel des Technologieeinsatzes. Bestehender Gestaltungsspielraum wird nicht ausgelotet, Gestaltungsalternativen werden nicht systematisch verfolgt.

Dorgan/Dowdy berichten über Befunde empirischer Untersuchungen, die vom McKinsey Global Institute gemeinsam mit Blom und van Reenan vom Center for Economic Performance der London Business School durchgeführt wurden, u. a. (Untersuchungszeitraum 1994 bis 2002, N = 100 Unternehmen in Frankreich, Deutschland, Großbritannien und den USA, Erhebungsmethode nicht genannt): Die Auswirkung der Höhe der IT-Investitionen auf die Produktivität ist deutlich geringer als die der Nutzung der Managementmethoden Lean Manufacturing, Performance Management und Talent Management. Daraus folgt die Handlungsempfehlung, zuerst in die Verbesserung der Nutzung der Managementmethoden (management practices) zu investieren, bevor weitere IT-Investitionen getätigt werden. Dieser Befund stützt das so genannte Produktivitätsparadoxon, die zunächst nur behauptete, später durch empirische Untersuchungen bestätigte These, dass die Zuwachsraten der Budgets für die Schaffung, Nutzung und Weiterentwicklung der IT stärker steigen als die der Produktivität. Es besteht keine positive, möglicherweise besteht eine negative Korrelation zwischen den beiden Größen. Harvard-Professor Andrew McAfee behauptet, dass es noch immer „zu viel IT“ gibt, „die zu wenig genutzt wird“. Ursache dafür sei, dass Technologieeinsatzentscheidungen von ITSpezialisten getroffen werden, „die Manager fühlen sich marginalisiert“. Für das Vorbereiten und Fällen von Technologieeinsatzentscheidungen werden zwei Strategien angeboten: erstens „von außen nach innen“, d. h. alles evaluieren, was es am IT-Markt gibt, und zweitens „von innen nach außen“, d. h. zunächst definieren, was das Unternehmen braucht und erst danach „die technische Landschaft anschauen“. (DER STANDARD, 12./13.11.2005, 24.)

Aus der Praxis Unternehmensberater der A. T. Kearney GmbH berichten, dass sich bei zahlreichen Projekten zur Einführung des Innovationsmanagements „vier wesentliche Säulen als Träger eines umfassenden Innovationsmanagements herauskristallisiert haben“, und zwar (F.A.Z. vom 7.12.2010 Beilage Innovationstreiber IKT, 8):    

Einführung eines zentral gesteuerten Suchprozesses, feste Verankerung von Innovation in der Unternehmenskultur, aktives Management des IT-Service-Portfolios und Abstimmung zwischen Geschäft und IT, was eine enge Zusammenarbeit des IT-Bereichs mit den Anwendern erfordert (Business-IT-Alignment).

Die enge Abstimmung zwischen IT-Bereich und Anwendern wird auch als Voraussetzung dafür angesehen, mit Hilfe von Informationstechnologien das Differenzierungsvermögen gegenüber Mitbewerbern und damit das Geschäftspotenzial zu erhöhen. Nur in jedem zwei-

174

Strategische Aufgaben des Informationsmanagements

ten Unternehmen, so die Erfahrung der Berater, gibt es eine dedizierte Stellenbeschreibung für IT-Innovationsmanagement. Wie die IT-Beauftragte der Bundesregierung berichtet, haben in einem Kooperationsprojekt das Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit, das Umweltbundesamt, das Beschaffungsamt des Bundesministeriums des Innern und der BITKOM Leitfäden für die umweltfreundliche Beschaffung von Desktop-PCs und Notebooks herausgegeben. Die Erweiterung auf weitere Produkte der IKT ist vorgesehen. Methodenverweise Nutzwertanalyse (Lerneinheit NUTZW); Wirtschaftlichkeitsanalyse (Lerneinheit WIRTA); Evaluierungsmethoden (Lerneinheit EVALU); Szenariotechnik (Lerneinheit SZENA). Kontrollfragen 1. Wie ist Technologie und wie sind die Technologiearten definiert? 2. In welche Aufgaben wird Technologiemanagement gegliedert? 3. Worin besteht der Unterschied zwischen Ex-ante-Evaluierung und Ex-post-Evaluierung? 4. Aus welchen Dokumenten bestehen die Ausschreibungsunterlagen? 5. Wie soll Technologiemanagement im Unternehmen institutionalisiert sein? Quellen Bullinger, H. J.: Einführung in das Technologiemanagement. Modelle, Methoden, Praxisbeispiele. Stuttgart 1994 Dorgan, St. J. / Dowdy, J. J.: When IT lifts productivity. In: The McKinsey Quarterly 4/2004, o. S. Dosi, G.: Technological Paradigms and Technological Trajectories. In: Research Policy 3/1982, 147–162 Hammer, M. / Champy, J.: Business Reengineering. Die Radikalkur für das Unternehmen. 7. A., Frankfurt a. M. 2003 IT-Beauftragte der Bundesregierung (BfIT): 1. Newsletter zu Green-IT: http://www.umweltbundesamt.de/produkte/dokumente/newsletter_bfit_intelligente_vergabe.pdf; Abruf 2.5.2011 Müller-Zantop, S.: Wo liegt der Wert der Informationsverarbeitung? In: F.A.Z. vom 17.3.1998, B 6 Ortmann, G.: Unternehmensstrategien und Informationstechniken. In: Zeitschrift für betriebswirtschaftliche Forschung 11/1991, 997–1001 Renkema, T. J. W.: The IT Value Quest. How to Capture the Business Value of IT-Based Infrastructure. Chichester et al. 1999 Rogers, E. M.: Diffusion of Innovations. 4. Ed., New York 1995 Willcocks, L. / Lester, St.: How do Organizations Evaluate and Control Information Systems Investments? Recent Survey Evidence. In: Avison, D. et al. (Eds.): Human, Organizational, and Social Dimensions of Information Systems Development. North-Holland et al. 1993, 15–39 Vertiefungsliteratur Miller, K. / 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 Normen DIN 69901: Projektwirtschaft – Projektmanagement – Begriffe. 2001 DIN EN ISO 9000 bzw. ÖNORM EN ISO 9000: Qualitätsmanagementsysteme. Grundlagen und Begriffe. 2004 ÖNORM A 2050: Vergabe von Aufträgen über Leistungen – Ausschreibung, Angebot und Zuschlag – Verfahrensnorm. 2006 VDI-Richtlinie 3780: Technikbewertung, Begriffe und Grundlagen. Ausgabe Sept. 2000 VDI/VDE-Richtlinie 3694: Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen. 2007

Sicherheitsmanagement (SICHM) Lernziele Sie kennen verschiedene Sicherheitsbegriffe und können den Aufgabenbereich Informationssicherheit sinnvoll strukturieren. Sie können die wichtigsten Sicherheitsziele erörtern und kennen Elemente von Sicherheitsmanagement-Systemen. Sie kennen den Unterschied zwischen einer IT-Grundschutzzertifizierung und einer Zertifizierung von Sicherheitsprodukten.

Definitionen und Abkürzungen Bedrohung (threat) = potenzielles Einwirken einer Gefahr auf Elemente der Informationsinfrastruktur. Synonyme: Gefährdung, sicherheitsgefährdendes Ereignis. BSI = Bundesamt für Sicherheit in der Informationstechnik (Deutschland). CC = Common Criteria for Information Technology Security Evaluation; internationale Kriterien zur Evaluierung von Produkten der IT-Sicherheit. Gefahr (threat) = Einflussfaktor, welcher sicherheitsrelevante Elemente beeinträchtigen und Schäden verursachen kann. ITSEC = Information Technology Security Evaluation Criteria; europäische Kriterien zur Evaluierung von Produkten der IT-Sicherheit. IT-Verbund (information processing facility/ies) = Gesamtheit der infrastrukturellen, organisatorischen, personellen und technischen Komponenten, die der Aufgabenerfüllung in einem bestimmten Anwendungsbereich der IT dienen. Synonym: Informationssystem. Schwachstelle (vulnerability, weakness) = Umstand, der das Eintreten gefährdender Ereignisse begünstigen oder deren negative Folgen verstärken kann. Sicherheit (security, safety) = Zustand, in dem alle schutzwürdigen Belange der Informationsinfrastruktur vor Beeinträchtigungen geschützt sind. Sicherheitsgefährdung (threat) = Synonyme: Bedrohung, sicherheitsgefährdendes Ereignis. Sicherheitskonzept (security concept) = Entwurf des Vorgehens zur Erreichung und Erhaltung des gewünschten oder geforderten Sicherheitsniveaus. Sicherheitskriterien (evaluation criteria) = Kriterien zur Evaluierung von Produkten der ITSicherheit. Sicherheitsleitlinie (information security policy oder IT security policy) = Beschreibung der wichtigsten Aussagen der Sicherheitsstrategie eines Unternehmens. Sicherheitsmanagement (security management) = Gesamtheit der Führungsaufgaben, die sich mit Sicherheit der Informationsinfrastruktur befassen. Sicherheitsmanagement-System (security management system) = Gesamtheit der Hilfsmittel des Sicherheitsmanagements. Sicherheitsniveau (security level) = Ausmaß an geforderter oder vorhandener Sicherheit. Sicherheitsstrategie (security strategy) = grundsätzliche Festlegungen der Unternehmensleitung zum Stellenwert der Informationssicherheit; die wichtigsten Aussagen der Sicherheitsstrategie werden in einer Sicherheitsleitlinie dokumentiert. Sicherungsmaßnahme (security control) = Vorkehrungen, die geeignet sind, die Informationssicherheit zu erhöhen. Synonyme: Sicherheitsmaßnahme, Schutzmaßnahme.

176

Strategische Aufgaben des Informationsmanagements

Zweck des Sicherheitsmanagements Die Funktions- und Leistungsfähigkeit der meisten Unternehmen hängt von der Sicherheit der Informationsinfrastruktur ab. Da es in jedem Unternehmen auch andere sicherheitsrelevante Bereiche gibt, spricht man von Informations- oder IT-Sicherheit. Im Folgenden wird die Kurzbezeichnung Sicherheit verwendet. Zweck des Sicherheitsmanagements ist die Erreichung der Sicherheitsziele (vgl. Lerneinheit SZIEL), was deutlich macht, dass Sicherheit ein subjektiver Begriff ist, der von der Risikobereitschaft der Personen bestimmt wird, die für das Setzen der Sicherheitsziele verantwortlich sind. Mit anderen Worten heißt Sicherheitsmanagement: Abwenden von realen Schäden an der Informationsinfrastruktur und daraus folgenden wirtschaftlichen Schäden für das Unternehmen. Abwenden meint Vermindern, wenn möglich Vermeiden von Schäden durch Sicherungsmaßnahmen, Überwälzen von Schäden durch Versicherungen sowie ggf. auch Selbsttragen von Schäden (Restrisiko). Die Sicherheitsziele werden durch Sicherheitsmanagement und Notfallmanagement (vgl. Lerneinheit NOMAN) – unter Berücksichtigung der Aussagen der IT-Strategie, der rechtlichen Rahmenbedingungen (z. B. KonTraG, Basel II) und der strategischen Maßnahmenplanung – in administrative Ziele für alle Komponenten der Informationsinfrastruktur umgesetzt und bis in die operative Ebene hinein präzisiert und implementiert. Damit wird ein integriertes Sicherheitsmanagement-System geschaffen. Zunehmende Bedeutung erhält Sicherheitsmanagement in vielen Unternehmen durch die Anwendung von IT-Governance (vgl. Lerneinheit GOVER) und IT-Servicemanagement (vgl. Lerneinheit SEMAN). Leitfäden wie CobiT oder ITIL empfehlen, Managementsysteme für IT-Sicherheit zu implementieren.

Sicherheitsbegriff Datenschutz bezeichnet den Schutz natürlicher Personen vor missbräuchlicher Verwendung ihrer personenbezogenen Daten. Im anglo-amerikanischen Sprachraum werden die Worte security (Sicherheit vor beabsichtigten Angriffen), safety (Sicherheit vor unbeabsichtigten Ereignissen) und privacy (Vertraulichkeit von – insbesondere Personen bezogenen – Daten) unterschieden. Das deutsche Wort Sicherheit umfasst alle drei Aspekte. Sicherheit ist ein Zustand, in dem alle schutzwürdigen Belange der Informationsinfrastruktur vor Beeinträchtigungen geschützt sind. Diese Definition weist auf folgende Besonderheiten der Sicherheit hin:   

Sicherheit kann nie vollständig erreicht werden. Besser wäre es deshalb, von Unsicherheit der Informationsinfrastruktur zu sprechen, die mehr oder weniger ausgeprägt ist. Sicherheit ist immer situationsspezifisch zu verstehen. Was als sicher empfunden wird, hängt unter anderem von den konkreten Anforderungen an die Informationsinfrastruktur und von der Bereitschaft der Verantwortlichen ab, Risiken zu tragen. Sicherheit kann nicht durch Implementierung normativ vorgegebener Sicherungsmaßnahmen oder durch Ausschluss bestimmter Risiken oder Gefährdungen erreicht werden.

Sicherheitsmanagement (SICHM)

   

177

Sicherheit bezieht sich nicht nur auf Daten, sondern auf alle Elemente der Informationsinfrastruktur: Daten, Programme, Hardware, Netzwerke, Aufgaben, Organisation etc. Sicherheit kann durch unterschiedliche Gefährdungen beeinträchtigt werden. Gefährdungen der Sicherheit können sehr unterschiedliche Auswirkungen haben – bis hin zur Gefährdung der Existenz eines Unternehmens. Wie stark die Unsicherheit reduziert werden kann, hängt auch von der Bereitschaft der Führungskräfte ab, Sicherheitskonzepte zu entwickeln und in Sicherungsmaßnahmen zu investieren.

Daraus ergeben sich verschiedene Konsequenzen für das Sicherheitsmanagement. Handlungsempfehlungen für die Sicherung können nicht unmittelbar aus publizierten Leitlinien oder Standards abgeleitet werden. Vielmehr müssen die Verantwortlichen zunächst bestimmen, was im konkreten Fall als sicher zu verstehen ist, welche Elemente der Informationsinfrastruktur in welchem Maße geschützt werden sollen und wie hoch der Aufwand ist, den man für die Erstellung eines Sicherheitskonzepts zu tragen bereit ist.

Ebenenmodell der Sicherheit Stelzer verwendet ein Ebenen- und ein Kausalmodell zur Strukturierung der verschiedenen Aspekte der Sicherheit. Das Ebenenmodell dient dazu, Elemente der Informationsinfrastruktur, Gefährdungen der Sicherheit sowie Sicherungsmaßnahmen zu strukturieren. Dazu werden vier Ebenen verwendet: die physische, die logische, die organisatorisch-soziale und die rechtlich-wirtschaftliche. Diese sind in Abbildung SICHM-1 dargestellt. Die physische Ebene beschreibt materielle Elemente der Sicherheit. Zu den sicherheitsrelevanten physischen Elementen der Informationsinfrastruktur zählen z. B. Hardwareeinheiten und Gebäude. Gefährdungen der Sicherheit ergeben sich u. a. durch Naturkatastrophen. Sicherungsmaßnahmen umfassen z. B. bauliche Brandschutzvorkehrungen oder Kameras, mit denen der Zutritt zu bestimmten Räumen überwacht werden kann. Die logische Ebene umfasst immaterielle Elemente der Sicherheit. Beispiele für Elemente der Informationsinfrastruktur auf der logischen Ebene sind Daten, Programme und IT-Prozesse. Gefährdungen der Si-

Elemente Gefährdungen Sicherungsmaßnahmen

rechtlich-wirtschaftliche Ebene Elemente Gefährdungen Sicherungsmaßnahmen

organisatorisch-soziale Ebene Elemente Gefährdungen Sicherungsmaßnahmen

logische Ebene Elemente Gefährdungen Sicherungsmaßnahmen

physische Ebene Abb. SICHM-1: Ebenenmodell der Sicherheit (Quelle: nach Stelzer)

178

Strategische Aufgaben des Informationsmanagements

cherheit ergeben sich z. B. durch Computerviren, durch Ausspähen von Daten durch Unbefugte, im Allgemeinen als Datendiebstahl bezeichnet, oder durch Softwarefehler. Sicherungsmaßnahmen umfassen u. a. Sicherungssoftware, Virenschutzprogramme oder Firewalls. Die organisatorisch-soziale Ebene beschreibt aufbau- und ablauforganisatorische Elemente sowie die soziale Dimension der Sicherheit. Beispiele für Elemente der Informationsinfrastruktur sind Aufgaben, Mitarbeiter sowie organisatorische Regeln. Gefährdungen ergeben sich durch menschliches Fehlverhalten oder durch organisatorische Mängel. Sicherungsmaßnahmen sind z. B. die Zuweisung von Verantwortungsbereichen an Sicherheitsbeauftragte oder das Vier-Augen-Prinzip, welches besagt, dass bestimmte Aufgaben von mindestens zwei Mitarbeitern gemeinsam erledigt werden müssen. Die wirtschaftlich-rechtliche Ebene beschreibt ökonomische und juristische Elemente der Sicherheit. Relevante Elemente der Informationsinfrastruktur sind z. B. Vermögensgegenstände und Rechtsgüter, wie Grundrechte, gesetzliche oder vertragliche Rechte (vgl. Lerneinheit RECHT). Gefährdungen der Sicherheit können sich z. B. aus Veränderungen gesetzlicher oder gesetzesähnlicher Vorschriften ergeben, welche ausschließen, dass bestimmte Sicherungsmaßnahmen umgesetzt werden. Ein Beispiel für Sicherungsmaßnahmen sind Computerversicherungen, mit denen Schäden auf Versicherungsunternehmen überwälzt werden. Nicht in jedem Fall können einzelne Elemente der Informationsinfrastruktur, Sicherheitsgefährdungen oder Sicherungsmaßnahmen exakt einer der Ebenen zugeordnet werden. Die Übergänge zwischen den Ebenen sind vielmehr fließend. Dennoch lässt sich Sicherheit mit Hilfe des Ebenenmodells übersichtlich strukturieren.

Kausalmodell der Sicherheit Im Zentrum des Kausalmodells (vgl. Abbildung SICHM-2) stehen sicherheitsrelevante Elemente. Dies sind Objekte, die notwendig sind, um durch IT unterstützte Aufgaben ausführen zu können. Beispiele für sicherheitsrelevante Elemente sind Hardwarebauteile, Netze, Programme, Datendateien und betriebliche Aufgaben. Diese Elemente der Informationsinfrastruktur können Gefahren ausgesetzt sein. Gefahren sind Einflussfaktoren, die sicherheitsrelevante Elemente beeinträchtigen und in der Folge Schäden verursachen können. Ein sicherheitsgefährdendes Ereignis (oder kurz gefährdendes Ereignis) beschreibt das Einwirken einer Gefahr auf ein sicherheitsrelevantes Element. Beispiele sind die unbeabsichtigte Löschung einer Datendatei durch einen Mitarbeiter, die Veränderung eines Programms durch einen Virus oder die unsachgemäße Ausführung einer betrieblichen Aufgabe durch Fehlbedienung eines Programms. Gefährdende Ereignisse werden auch als Bedrohungen bezeichnet. Gefahrenquellen sind Ursachen und Ausgangspunkte von Gefahren. Beispiele für Gefahrenquellen sind Menschen, Natur, Technik oder Umwelteinflüsse. Das BSI unterscheidet in den IT-Grundschutz-Katalogen folgende Gefahrenquellen: höhere Gewalt, organisatorische Mängel, menschliche Fehlhandlungen, technisches Versagen und vorsätzliche Handlungen.

Sicherheitsmanagement (SICHM)

179

Sicherheitsgefährdende Ereignisse haben unerwünschte Konsequenzen. Diese lassen sich in unmittelbare bzw. primäre und mittelbare bzw. sekundäre Auswirkungen oder Konsequenzen einteilen. Beispiele für primäre Konsequenzen sind Zerstörung, Veränderung, Ausfall, unbefugte Nutzung und unbefugte Kenntnisnahme. Da einzelne Elemente der Informationsinfrastruktur in der Regel anderen Elementen dienen bzw. für deren Funktionieren notwendig sind, haben sicherheitsgefährdende Ereignisse nicht nur negative Auswirkungen für unmittelbar, sondern auch für mittelbar betroffene Elemente der Informationsinfrastruktur. So führt z. B. der Ausfall eines Servers durch einen Stromausfall dazu, dass die darauf betriebenen Anwendungssysteme unterbrochen werden. Dies hat zur Folge, dass betriebliche Aufgaben für den Zeitraum der Unterbrechung nicht oder nicht in der gewohnten Zeit und Qualität ausgeführt werden können. Das führt in der Regel zu wirtschaftlichen Schäden, z. B. Umsatzausfall oder Kostensteigerung. Die Gesamtheit der Folgewirkungen eines gefährdenden Ereignisses wird als sekundäre Konsequenzen bezeichnet. Die Summe aller Konsequenzen eines sicherheitsgefährdenden Ereignisses wird mit dem Wort Schaden zusammengefasst. sicherheitsgefährdendes Ereignis Gefahrenquelle

Gefahr

sicherheitsrelevantes Element

primäre Konsequenzen

sekundäre Konsequenzen

Abb. SICHM-2: Kausalmodell der Sicherheit (Quelle: nach Stelzer)

Sicherungsmaßnahmen sind Vorkehrungen zum Schutz der Informationsinfrastruktur. Ihr Zweck besteht darin, die Wahrscheinlichkeit des Eintretens gefährdender Ereignisse zu reduzieren oder die Eintrittswahrscheinlichkeit und die Höhe von Schäden zu reduzieren. Schwachstellen sind Umstände, die das Eintreten gefährdender Ereignisse begünstigen oder deren negative Folgen verstärken können. Beispiele für Schwachstellen sind Lücken im Brandschutzkonzept, fehlerhafte Einstellungen in Virenschutzprogrammen und fehlende oder nicht eingeübte Notfallpläne (vgl. Lerneinheit NOMAN).

Sicherheitsziele Folgende Ziele sind Grundziele der Sicherheit: Integrität, Verfügbarkeit und Vertraulichkeit. Darüber hinaus sind die Ziele Anonymität, Authentizität und Verbindlichkeit relevant.     

Integrität bezeichnet die Vollständigkeit und Unverfälschtheit der Elemente der Informationsinfrastruktur. Verfügbarkeit bedeutet, dass die Elemente der Informationsinfrastruktur betriebsbereit sind und keine Beeinträchtigung der Funktionalität vorliegt. Vertraulichkeit bezeichnet einen Zustand, in dem die Existenz oder der Inhalt sicherheitsrelevanter Elemente nur befugten Aufgabenträgern bekannt werden. Anonymität beschreibt, dass Nutzer von Informationssystemen, z. B. bei OnlineWahlen, nicht identifiziert werden können. Authentizität ist eine Kombination zweier Ziele im Zusammenhang mit Kommunikationsvorgängen. Sender und Empfänger einer Nachricht können ihre Identität sowie die

180



Strategische Aufgaben des Informationsmanagements

Integrität der übermittelten Nachricht nachweisen oder anders formuliert, keiner der beiden Partner kann behaupten, an der Kommunikation nicht teilgenommen oder eine Nachricht anderen Inhalts gesendet oder empfangen zu haben. Verbindlichkeit bedeutet Rechtssicherheit im Zusammenhang mit der IT.

Sicherheitsmanagement-System Verschiedene Leitfäden geben Hinweise zur Gestaltung von Sicherheitsmanagement-Systemen, z. B. Standard of Good Practice for Information Security des Information Security Forum (ISF), NIST Special Publication 800-100 und die ISO 27000-Normenfamilie. Der BSI-Standard 100-1: Managementsysteme für Informationssicherheit baut auf den zuvor genannten ISO-Normen auf. Die folgenden Ausführungen orientieren sich am BSI-Standard 100-1. Ein Sicherheitsmanagement-System umfasst Prinzipien, Methoden, Verfahren und Werkzeuge für die Gestaltung der Sicherheit der Informationsinfrastruktur. Im BSI-Standard 100-1 werden verschiedene Komponenten eines Sicherheitsmanagement-Systems vorgeschlagen. Diese sind in Abbildung SICHM-3 im Überblick dargestellt.

Sicherheitsmanagement-System umfasst folgende Komponenten

Sicherheitsprozess

Sicherheitsstrategie

bedient sich folgender Hilfsmittel Sicherheitskonzept

Managementprinzipien

Ressourcen

Mitarbeiter

ist dokumentiert in Sicherheitsleitlinie

Sicherheitsorganisation Abb. SICHM-3: Komponenten eines Sicherheitsmanagement-Systems

Sicherheitsprozess Der Sicherheitsprozess beschreibt das Vorgehen zur Planung, Implementierung und Aufrechterhaltung des Sicherheitsmanagement-Systems. Der Sicherheitsprozess besteht aus folgenden Schritten (nach BSI-Standard 100-1). Der Geltungsbereich des Sicherheitsmanagement-Systems umfasst oft die gesamte Institution, kann sich aber auch auf ein oder mehrere Informationssysteme, Geschäftsprozesse oder Organisationseinheiten beziehen. In großen und diversifizierten Unternehmen gibt es häufig mehrere Sicherheitsmanagement-Systeme, um den unterschiedlichen Aufgaben, Rahmenbedingungen und Sicherheitsniveaus besser gerecht werden zu können.

Sicherheitsmanagement (SICHM)

181

Die konkrete Ausgestaltung des Sicherheitsmanagements muss sich an den spezifischen Rahmenbedingungen orientieren. Dazu zählen unter anderem die Ziele des Unternehmens, gesetzliche und vertragliche Anforderungen und Vorschriften (vgl. Lerneinheit RECHT) sowie besondere Bedrohungen der Geschäftstätigkeit durch Sicherheitsgefährdungen. Festlegung des Geltungsbereichs des Sicherheitsmanagement-Systems

Aufbau einer Sicherheitsorganisation

Ermittlung von Rahmenbedingungen

Planung und Umsetzung des Sicherheitskonzepts

Formulierung einer Sicherheitsstrategie in einer Sicherheitsleitlinie

Erfolgskontrolle

Abb. SICHM-4: Elemente des Sicherheitsprozesses

Die Sicherheitsstrategie wird in der Sicherheitsleitlinie dokumentiert. Darin macht die Unternehmensleitung grundlegende Aussagen zum Stellenwert der Sicherheit und klärt die Bedeutung der IT für die Aufgaben des Unternehmens. Es werden Sicherheitsziele für die verschiedenen Geschäftsbereiche und Aufgaben des Unternehmens definiert. Außerdem beschreibt die Sicherheitsleitlinie die Sicherheitsorganisation sowie Maßnahmen zur Planung, Entwicklung, zur Durchsetzung und Kontrolle der verschiedenen Aufgaben des Sicherheitsmanagements. Die Sicherheitsorganisation ist die Aufbauorganisation des Sicherheitsmanagements. Sie definiert Aufgaben, Verantwortungsbereiche und Kompetenzen der für die Sicherheit zuständigen Stellen. Wie die Sicherheitsorganisation genau gestaltet wird, hängt von der Größe des Unternehmens, den Rahmenbedingungen, dem Stellenwert der IT sowie dem gewünschten Sicherheitsniveau ab. Es muss ein für die Informationssicherheit verantwortlicher Manager der obersten Leitungsebene (z. B. ein Mitglied der Geschäftsführung) benannt werden. Ein Sicherheitskonzept ist ein Entwurf zur Erreichung des gewünschten Sicherheitsniveaus. In dem Konzept werden Risiken dargelegt und Maßnahmen zu deren Eindämmung begründet. Das Sicherheitskonzept dient zur Umsetzung der Sicherheitsstrategie und beschreibt die Hilfsmittel, mit denen die Sicherheitsziele erreicht werden sollen. Sicherheitskonzepte können entweder für die gesamte Informationsinfrastruktur eines Unternehmens oder für Teile, z. B. für einzelne Informationssysteme, entworfen werden. Jede Sicherungsmaßnahme soll mit dem Sicherheitskonzept begründet werden können (vgl. Lerneinheit SIKON). Das obere Management eines Unternehmens muss in regelmäßigen Abständen überprüfen, ob das Sicherheitsmanagement die gesetzten Ziele angemessen erreicht; in anderen Worten, es muss eine Erfolgskontrolle durchführen. In diesem Rahmen sind unter anderem folgende Fragen zu beantworten: Haben sich die Rahmenbedingungen so geändert, dass das Sicherheitsmanagement angepasst werden muss? Ist die Sicherheitsstrategie noch angemessen? Sind das (ggf. die) Sicherheitskonzept(e) und die Sicherheitsorganisation noch geeignet, die Sicherheitsziele zu erreichen? Steht der Aufwand in einem sinnvollen Verhältnis zum Nutzen

182

Strategische Aufgaben des Informationsmanagements

des Sicherheitsmanagements? Wird eine der Fragen mit Nein beantwortet, sind entsprechende Korrekturmaßnahmen zu ergreifen.

Sicherheitsstrategie Das zweite Element des Sicherheitsmanagement-Systems ist die Sicherheitsstrategie. Die Sicherheitsstrategie ist eine grundsätzliche, langfristig und unternehmensweit angelegte Verhaltens- und Verfahrensweise zum Aufbau und Erhalt der Sicherheit der Informationsinfrastruktur. Die Sicherheitsstrategie umfasst insbesondere Sicherheitsziele für relevante Unternehmensbereiche und betriebliche Aufgaben sowie Festlegungen zu den für die Sicherheit zu verwendenden Ressourcen. Die Sicherheitsstrategie leitet sich aus der übergeordneten Strategie des Informationsmanagements bzw. der Unternehmensstrategie ab (vgl. Lerneinheiten ZIELP und STRAT). Die Kernaussagen der Sicherheitsstrategie werden in einer Sicherheitsleitlinie dokumentiert. Der Sicherheitsbeauftragte hat die zentrale Rolle im Sicherheitsmanagement (vgl. Lerneinheit STELL). Zu seinen Aufgaben gehört es, den Sicherheitsprozess zu steuern, die Leitungsebene bei der Erstellung der Sicherheitsstrategie bzw. der Sicherheitsleitlinie zu unterstützen, die Erstellung des Sicherheitskonzepts bzw. der Sicherheitskonzepte zu koordinieren, die Realisierung der Sicherungsmaßnahmen zu initiieren und zu überprüfen, der Leitungsebene über den Status quo der Sicherheit zu berichten, sicherheitsrelevante Projekte zu koordinieren, Sicherheitsvorfälle zu untersuchen und Sensibilisierungs- und Schulungsmaßnahmen für Fach- und Führungskräfte zu initiieren und zu koordinieren. Lediglich größere Unternehmen oder solche mit einem sehr hohen Sicherheitsbedarf beschäftigen einen hauptamtlichen Sicherheitsbeauftragten. In kleineren Unternehmen nimmt der Sicherheitsbeauftragte in der Regel auch andere Aufgaben wahr. Bei großen Organisationen kann es erforderlich sein, für einzelne Projekte, Informationssysteme oder Organisationseinheiten eigene Sicherheitsbeauftragte einzusetzen. Diese sind für alle Sicherheitsbelange in ihrem jeweiligen Zuständigkeitsbereich verantwortlich und stimmen sich mit dem zentralen Sicherheitsbeauftragten ab. Dieser wird oft durch ein Sicherheitsmanagement-Team unterstützt. Das Team umfasst Beauftragte für die Sicherheit einzelner Projekte, Informationssysteme oder Organisationseinheiten.

Managementprinzipien Das BSI empfiehlt, bei der Realisierung eines Sicherheitsmanagement-Systems folgende Managementprinzipien zu berücksichtigen. Das obere Management soll die Gesamtverantwortung für die Sicherheit übernehmen. Dadurch wird demonstriert, dass die Aufrechterhaltung und Verbesserung der Sicherheit ein für die gesamte Organisation relevantes Ziel ist. Die Sicherheit soll von Anfang an in alle betrieblichen Aufgaben integriert werden. Das heißt z. B., dass bereits während des Entwurfs neuer Informationssysteme Sicherheitsaspekte mit berücksichtigt werden. Ferner soll das obere Management die Sicherheit initiieren, steuern, überwachen und für deren kontinuierliche Verbesserung sorgen. Dazu gehört die Etablierung, Aufrechterhaltung und Überprüfung der Angemessenheit und Wirksamkeit aller Elemente des Sicherheitsmanagement-Systems. Dies erfordert die regelmäßige Durchführung von internen Audits (vgl. Lerneinheit MEQUA) und Übungen zur Schulung der Fachund Führungskräfte. Die Verabschiedung von realistischen und relevanten Sicherheitszielen,

Sicherheitsmanagement (SICHM)

183

die Formulierung einer Sicherheitsstrategie, die Schaffung angemessener Rahmenbedingungen und die Genehmigung ausreichender Ressourcen für das Sicherheitsmanagement sind weitere Aufgaben der Unternehmensleitung. In den Verantwortungsbereich des oberen Managements gehören auch Analysen der Wirtschaftlichkeit der Sicherungsmaßnahmen. Dabei ist insbesondere festzulegen, welchen Wert die Unternehmensleitung einem bestimmten Sicherheitsniveau beimisst und welche Ressourcen sie dafür zu investieren bereit ist. Auch Kommunikation und Wissensvermittlung über Sicherheit müssen aktiv gestaltet werden. Festzulegen ist unter anderem, in welcher Weise die obere Leitung über Probleme und Verbesserungsmöglichkeiten informiert wird und auf welche Weise sicherheitsgefährdende Ereignisse oder Sicherungsmaßnahmen zu dokumentieren sind. Nicht zuletzt hat die Leitungsebene eine Vorbildfunktion, z. B. bei der Einhaltung von Sicherheitsregeln und der Teilnahme an Sicherheitsschulungen.

Ressourcen und Mitarbeiter Zwei weitere Elemente des Sicherheitsmanagement-Systems betreffen die Bereitstellung von Ressourcen für die Sicherheit und die Einbindung aller Mitarbeiter in den Sicherheitsprozess. Ein akzeptables Sicherheitsniveau kann nur erreicht werden, wenn ausreichende finanzielle, personelle und zeitliche Ressourcen zur Verfügung stehen. Wie bereits erwähnt, gehört es zu den für den Unternehmenserfolg relevanten Aufgaben der Unternehmensleitung festzulegen, welches Sicherheitsniveau wirtschaftlich sinnvoll ist. Dazu gehört auch, abzuwägen, ob die Ressourcen für die Sicherheit oder für andere Aufgaben verwendet werden sollen. Da Sicherheit in einem Unternehmen nicht nur von einigen wenigen Fachleuten implementiert werden kann, müssen alle Mitarbeiter an der Reduzierung von Risiken und der Vermeidung von Schäden mitwirken. Damit dies möglich wird, ist bei allen Fach- und Führungskräften ein Bewusstsein für die Bedeutung der Sicherheit zu schaffen und aufrecht zu erhalten. Schulungen zu Sicherheitsgefährdungen und über den Zweck von Sicherungsmaßnahmen können hierzu beitragen. Hilfreich ist es auch, wenn alle Mitarbeiter Ansprechpartner für Sicherheitsfragen haben und wissen, was bei gefährdenden Ereignissen zu tun ist. Werden Mitarbeiter neu eingestellt oder erhalten neue Aufgaben, ist eine gründliche Ausbildung und Einarbeitung auch in sicherheitsrelevante Aspekte des neuen Arbeitsplatzes notwendig. Scheiden Mitarbeiter aus oder ändern sich ihre Zuständigkeiten, muss dies durch geeignete Sicherungsmaßnahmen begleitet werden (z. B. Entzug oder Anpassung von Berechtigungen).

Zertifizierung nach ISO 27001 sowie IT-Grundschutz Auf der Grundlage der ISO/IEC 27001 können Sicherheitsmanagement-Systeme von akkreditierten Stellen zertifiziert werden. Dabei wird untersucht, ob das SicherheitsmanagementSystem den Anforderungen der ISO/IEC 27001 genügt und ob angemessene, z. B. die in ISO/IEC 27002 beschriebenen Sicherungsmaßnahmen implementiert worden sind. Auf dieser Grundlage hat das BSI die IT-Grundschutz-Vorgehensweise (vgl. Lerneinheit SIKON) entwickelt. Diese ist im BSI-Standard 100-2 dokumentiert und ermöglicht ebenfalls eine Zertifizierung. Das BSI zertifiziert IT-Verbünde, worunter im Sprachgebrauch der Wirtschaftsinformatik Informationssysteme zu verstehen sind. Die BSI-Zertifizierung umfasst eine Prüfung des Sicherheitsmanagement-Systems sowie der implementierten Sicherungs-

184

Strategische Aufgaben des Informationsmanagements

maßnahmen. In Frage kommende Sicherungsmaßnahmen sind in den so genannten ITGrundschutz-Katalogen des BSI dokumentiert. Relevante Kriterienwerke für die Zertifizierung sind die ISO/IEC 27001, die IT-Grundschutz-Vorgehensweise (BSI-Standard 100-2) sowie die IT-Grundschutz-Kataloge in der jeweils aktuellen Fassung.

Sicherheitskriterien und Produktzertifizierung Neben Sicherheitsmanagement-Systemen können auch Sicherheitsprodukte (Systeme oder einzelne Komponenten, z. B. Chipkartenlesegeräte, Firewalls oder Betriebssysteme) zertifiziert werden. Die Zertifizierung wird auf Veranlassung des Herstellers oder des Vertreibers eines Produktes durchgeführt. Bestandteil des Verfahrens ist die Evaluierung (vgl. Lerneinheit EVALU), d. h. die technische Prüfung des Produktes gemäß Sicherheitskriterien. Es gibt verschiedene Kriterienwerke, z. B. ITSEC oder CC, die in ISO/IEC 15408-1 normiert sind. Die Prüfung wird in Deutschland von einer vom BSI anerkannten Prüfstelle durchgeführt. Nach einer erfolgreichen Evaluierung eines Produktes erstellt das BSI einen Zertifizierungsreport, der aus dem Sicherheitszertifikat und einem detaillierten Zertifizierungsbericht besteht. Auf diese Weise können Interessenten und Anwender der Produkte einen detaillierten Einblick in die sicherheitsrelevanten Eigenschaften erhalten. Eine regelmäßig aktualisierte Liste der zertifizierten Sicherheitsprodukte ist auf der Website des BSI zu finden.

Forschungsbefunde Luftman/Ben-Zvi berichten über die größten, von IT-Führungskräften wahrgenommenen Sorgen („concerns“) (schriftliche Befragung von ca. 150 IT-Führungskräften, die jährlich von der Society for Information Management in den USA durchgeführt wird). Demnach gehören IT-Sicherheit und Datenschutz (security and privacy) seit 2003 regelmäßig zu den zehn wichtigsten Herausforderungen für das IT-Management. Ko/Osei-Bryson/Dorantes haben Auswirkungen von öffentlich bekannt gewordenen Sicherheitsverletzungen auf Kapital- und Umsatzrentabilität sowie das Umsatz/Kosten-Verhältnis amerikanischer Unternehmen untersucht (Identifikation von 105 publizierten Berichten über sicherheitsgefährdende Ereignisse in Unternehmen, Analyse von 69 Ereignissen, über die Finanzkennzahlen verfügbar sind, Vergleich der Entwicklung der Kennzahlen der Unternehmen mit dem jeweiligen Branchendurchschnitt jeweils ein Jahr nach der Sicherheitsverletzung, Untersuchungszeitraum 1997 bis 2004). Die Mehrzahl der Sicherheitsverletzungen hat ein Jahr nach dem Ereignis keine statistisch signifikanten Auswirkungen auf die Finanzen der Unternehmen. Verletzungen der Vertraulichkeit und der Verfügbarkeit haben häufiger negative Auswirkungen als Integritätsverletzungen. Die Auswirkungen sicherheitsgefährdender Ereignisse sind umso gravierender, je höher der Stellenwert der IT für die Wettbewerbsfähigkeit der Unternehmen ist.

Aus der Praxis Bei der von Ernst & Young durchgeführten 2010 Global Information Security Survey (Befragung von ca. 1600 IT-Führungskräften in 56 Ländern in Unternehmen des Kundenstamms von Ernst & Young vorwiegend durch Interviews, einige online, keine Angaben zur Rücklaufquote, Untersuchungszeitraum Juni bis August 2010) gaben 60 % der Teilnehmer an,

Sicherheitsmanagement (SICHM)

185

durch Soziale Netzwerke, Cloud Computing und mobile Endgeräte ein erhöhtes Risiko für die IT-Sicherheit wahrzunehmen. 46 % gaben an, dass Investitionen in IT-Sicherheit 2010 gegenüber dem Vorjahr erhöht wurden, bei weiteren 48 % der Unternehmen waren sie konstant. 53 % sahen im nicht ausreichenden Sicherheitsbewusstsein der Mitarbeiter die größte Herausforderung für die IT-Sicherheit. Die kontinuierliche Verfügbarkeit geschäftskritischer IT-Ressourcen und die Vertraulichkeit sensibler Daten wurden zu den Risikobereichen mit der höchsten Kritikalität gezählt. Auf die Frage, welchen Beitrag die IT-Sicherheit zur Unterstützung anderer betrieblicher Aufgaben leistet, antworteten 82 %, IT-Sicherheit leiste einen wichtigen oder sehr wichtigen Beitrag zur Einhaltung regulatorischer Anforderungen (achieving compliance with regulations), 82 % zum Schutz des Rufs des Unternehmens und des Ansehens der Marken sowie 81 % zum Schutz personenbezogener Daten. Bei der von Ernst & Young 2009 durchgeführten Global Information Security Survey (Befragung von ca. 1900 IT-Führungskräften in 60 Ländern, keine Angaben zur Rücklaufquote, Untersuchungszeitraum Juni bis August 2009) gaben 8 % der Teilnehmer an, ein Sicherheitsmanagement-System implementiert zu haben, das zertifiziert worden ist, 19 % hatten ein Sicherheitsmanagement-System implementiert, ohne es zertifizieren zu lassen, 17 % waren zum Zeitpunkt der Befragung mit der Implementierung beschäftigt. 32 % gaben an, noch kein Sicherheitsmanagement-System implementiert zu haben, dies aber zu erwägen. Dagegen zogen 24 % der Befragten dies nicht in Betracht. Rumpel weist darauf hin, dass viele Unternehmen und Behörden weder die Effektivität noch die Effizienz ihrer Sicherheitsmanagement-Systeme beurteilen können. Oft werden keine Ziele für das Sicherheitsmanagement definiert. Nur selten wird die Wirtschaftlichkeit von Sicherungsmaßnahmen beurteilt. Insbesondere der Nutzen von Sicherungsmaßnahmen, d. h. deren Potenzial, Risiken zu reduzieren, ist unbestimmt. Der Erfolg von Sicherheitsmanagement-Systemen wird nur selten ausreichend überwacht, so dass auch keine Verbesserungsmaßnahmen ergriffen werden können. Methodenverweise Vorgehensmodelle (Lerneinheit VOMOD); Evaluierungsmethoden (Lerneinheit EVALU); Sicherheitskonzepte (Lerneinheit SIKON). Kontrollfragen 1. Wie beurteilen Sie folgende Definition? Sicherheit ist gegeben, wenn die in den IT-Grundschutz-Katalogen vorgeschlagenen Sicherungsmaßnahmen implementiert sind. 2. Welche Aufgaben haben Führungskräfte im Hinblick auf IT-Sicherheit? 3. Welchen – neben dem Sicherheitsmanagement – anderen Aufgaben des Informationsmanagements dient ein Sicherheitsmanagement-System? 4. Welche Inhalte sollte eine Sicherheitsleitlinie umfassen und wie lassen sich diese strukturieren? 5. Welche Argumente sprechen für und welche gegen die Zertifizierung eines Sicherheitsmanagement-Systems? Quellen Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz-Kataloge 2009. https://www.bsi.bund.de; Abruf 11. Mai 2011 Bundesamt für Sicherheit in der Informationstechnik (BSI): Zertifizierung nach ISO 27001 auf der Basis von ITGrundschutz. Prüfschema für ISO 27001-Audits. Version 2.1. Stand: 03.03.2008. Bonn 2008 Department of Trade and Industry. Information Technology Security Evaluation Criteria (ITSEC). Version 1.2. London 1991 Ernst & Young (Hrsg.): Outpacing change. Ernst & Young’s 12th annual global information security survey. o. O. 2009, http://www.ey.com; Abruf 18. Mai 2010

186

Strategische Aufgaben des Informationsmanagements

Ernst & Young (Hrsg.): Borderless security. Ernst & Young’s 2010 Global Information Security Survey. o. O. 2010. http://www.ey.com; Abruf 07. April 2011 Information Security Forum: Standard of Good Practice for Information Security. 2007. http://www.isfsecuritystandard.com; Abruf 30. März 2011 Ko, M. / Osei-Bryson, K.-M. / Dorantes, C.: Investigating the Impact of Publicly Announced Information Security Breaches on Three Performance Indicators of the Breached Firms. In: Information Resources Management Journal 2/2009, 1–21 Luftman, J. / Ben-Zvi, T.: Key Issues for IT Executives 2010: Judicious IT Investments Continue Post-Recession. In: MIS Quarterly Executive 4/2010, 263–273 NIST Special Publication 800-100: Information Security Handbook: A Guide for Managers. Washington 2006 Rumpel, R.: Planung und Betrieb von Informationssicherheits-Managementsystemen. Erfahrungen aus der Praxis. In: Datenschutz und Datensicherheit 1/2011, 12–15 Stelzer, D.: Sicherheitsstrategien in der Informationsverarbeitung - Ein wissensbasiertes, objektorientiertes System für die Risikoanalyse. Wiesbaden 1993, 20–46 Vertiefungsliteratur Bishop, M.: Computer Security. Art and Science. Boston 2003 Eckert, C.: IT-Sicherheit. Konzepte - Verfahren - Protokolle. 5. A., München/Wien 2008 Gollmann, D.: Computer Security. 2. A., Chichester 2006 Pfleeger, C. P. / Pfleeger, S. L.: Security in Computing. 4. A., Upper Saddle River 2006 Straub, D. W. / Goodman, S. / Baskerville, R. (Hrsg.): Information Security: Policy, Processes, and Practices. Armonk NY 2008 Informationsmaterial Aktuelle Nachrichten zur Informationssicherheit http://www.heise.de/security Bundesamt für Sicherheit in der Informationstechnik http://www.bsi.de Common Criteria / ISO/IEC 15408-1 http://www.oc.ccn.cni.es/xml Common Criteria Project http://www.commoncriteriaportal.org Computer Emergency Response Team CERT Coordination Center am Software Engineering Institute der Carnegie Mellon University, Pittsburgh (USA) http://www.cert.org Computer Security Resource Center / National Institute of Standards and Technology http://csrc.nist.gov Deutschland sicher im Netz e.V. https://www.sicher-im-netz.de DFN-CERT- Computer Notfallteam im Deutschen Forschungsnetz http://www.cert.dfn.de European Network and Information Security Agency (ENISA) http://www.enisa.europa.eu Gesellschaft für Informatik e. V. Fachbereich Sicherheit – Schutz und Zuverlässigkeit http://www.gi-ev.de Information Security Forum http://www.securityforum.org ISO 27000 Directory http://www.27000.org IT-Security Portal http://www.securitymanager.de Oesterreichische Computer Gesellschaft (OCG) Arbeitskreis IT-Sicherheit http://www.ocg.at Suchmaschinen zur Informationssicherheit http://www.searchsecurity.de und http://searchsecurity.techtarget.com Normen BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS) Version 1.5. 2008 BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise Version 2.0. 2008 BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz Version 2.5. 2008 ISO/IEC 15408-1:2009: Information technology - Security techniques - Evaluation criteria for IT security. – Part 1: Introduction and General Model ISO/IEC 27000:2009: Information technology – Security techniques – Information security management systems – Overview and vocabulary ISO/IEC 27001:2005: Information technology – Security techniques – Information security management systems – Requirements ISO/IEC 27002:2005: Information technology – Security techniques – Code of practice for information security management ISO/IEC 27003:2010: Information technology – Security techniques – Information security management system implementation guidance ISO/IEC 27004:2009: Information technology – Security techniques – Information security management – Measurement ISO/IEC 27005:2008: Information technology – Security techniques – Information security risk management

Notfallmanagement (NOMAN) Lernziele Sie kennen den Zweck des Notfallmanagements sowie Arten und Ursachen von Notfällen. Sie können die Vorgehensweise beim Notfallmanagement beschreiben und kennen Gliederung und Inhalt eines Notfallplans. Sie wissen, welche Arten von Ausweichrechenzentren es gibt und kennen Inhalte von Verträgen zu deren Nutzung.

Definitionen und Abkürzungen Alarmplan (alarm plan) = Teilplan des Notfallplans mit Anweisungen darüber, wer bei einem Notfall Alarm auslöst und welche Maßnahmen unverzüglich durchzuführen sind. Ausweichrechenzentrum (backup computing center) = Rechenzentrum, in das im Notfall Anwendungen verlagert werden, so dass zumindest ein Notbetrieb möglich ist. Synonym: Notfallrechenzentrum. Container-Rechenzentrum (container computing center) = transportables Rechenzentrum mit einem vorbereiteten Standort auf dem Betriebsgelände. Einsatzplan (initiative guide, plan of action) = Teilplan des Notfallplans, der die im Notfall sofort zu ergreifenden Maßnahmen beschreibt. Fluchtplan (escape guide) = Teilplan des Notfallplans mit Anweisungen darüber, auf welchen Wegen Personen den Gefahrenbereich verlassen sollen. Katastrophe (disaster situation, catastrophe) = Notfall, der die Existenz des Unternehmens gefährdet und gravierende Auswirkungen auf das öffentliche Leben hat. Krisenstab (crisis team) = Gruppe von Aufgabenträgern der IT- und der Fachabteilungen, deren Aufgabe die Erstellung und Pflege des Notfallplans ist. Meldeplan (report guide) = Teilplan des Notfallplans mit Anweisungen darüber, wer im Notfall in welcher Abfolge zu verständigen ist. Synonym: Alarmplan. Notfall (case of emergency) = Störung, durch die ein hoher bis sehr hoher Schaden entsteht und deren Bewältigung spezifische Maßnahmen erfordert. Notfallorganisation (emergency case organization) = struktur- und ablauforganisatorische Maßnahmen, die beim Eintritt eines Notfalls die Funktionsfähigkeit kritischer Teile der Informationsinfrastruktur ermöglichen. Notfallplan (business continuity plan, disaster plan) = Dokument, das Vorgehensweise und Maßnahmen im Notfall beschreibt. Rettungsplan (rescue guide) = Teilplan des Notfallplans mit Anweisungen darüber, wer und was wie zu bergen ist. Synonym: Evakuierungsplan. RZ = Rechenzentrum (computing center, data center). Störung (incident) = unerwünschtes Ereignis, das zu einer Beeinträchtigung eines ITServices oder zum Ausfall eines Elements der IT-Infrastruktur führt oder führen kann. Vorsorgeplan (precaution guide) = Teilplan des Notfallplans, der die Vorsorgemaßnahmen für den Notfall beschreibt. Wiederanlaufplan (restart guide) = Teilplan des Notfallplans, der die Maßnahmen enthält, die beim Eintritt des Notfalls zu ergreifen sind.

188

Strategische Aufgaben des Informationsmanagements

Zweck des Notfallmanagements Notfallmanagement zielt auf solche Risiken für die Informationsinfrastruktur ab, deren Eintrittswahrscheinlichkeit niedrig und deren Folgen als Schadenshöhe groß eingeschätzt werden. Notfallmanagement ist Management der Problemfälle, die als Notfall einzuordnen sind. Ein Notfall hat zur Folge, dass die Informationsinfrastruktur ganz oder in wesentlichen Teilen so beeinträchtigt ist, dass ein den Unternehmenszielen entsprechender IT-Betrieb nicht mehr möglich ist. Entscheidend beim Notfallmanagement ist, dass nicht nur die Verfügbarkeit technischer Komponenten der Informationsinfrastruktur wieder hergestellt wird, sondern dass das Unternehmen wesentliche Aufgaben innerhalb einer möglichst kurzen Zeit wieder ausüben kann; eine Anforderung, die in der englischen Bezeichnung Business Continuity Management zum Ausdruck kommt. Die Auswirkungen des Notfalls können in der Regel nicht innerhalb weniger Stunden beseitigt werden. Diese Situation tritt besonders dann ein, wenn zentrale Komponenten (z. B. Hostsysteme und Netze) betroffen sind, was – in Abhängigkeit von der IT-Architektur (vgl. Lerneinheit ARCHI) – zum Ausfall einiger oder aller dezentraler Komponenten führen kann. Von diesen Überlegungen ausgehend, wird der Zweck des Notfallmanagements wie folgt formuliert: Verkürzung des Ausfallzeitraums Ta, der kleiner oder höchstens gleich dem Überlebenszeitraum des Unternehmens Tü sein soll, wobei  

Tü den Überlebenszeitraum des Unternehmens bezeichnet, also den Zeitraum, in dem das Unternehmen ohne funktions- oder leistungsfähige Informationsinfrastruktur überleben kann und Ta den Ausfallzeitraum der Informationsinfrastruktur, also den Zeitraum, in dem die Kerngeschäftsprozesse (z. B. Auftragsbearbeitung in einem Versandhaus, Produktionsplanung und -steuerung in einem Fertigungsbetrieb, Kraftwerkssteuerung in einem Energieversorgungsunternehmen) nach Eintritt eines Notfalls wieder funktions- und leistungsfähig gemacht werden können.

Dies wird in der Regel durch eine Verkürzung von Ta erreicht, insbesondere durch Maßnahmen der Notfallvorsorge (z. B. durch ein beschleunigtes Verfügbarmachen einer Ersatzkonfiguration in einem Ausweichrechenzentrum). Eine gewisse Verlängerung von Tü ist durch eine gute Notfallorganisation möglich. Wirksamkeit und Wirtschaftlichkeit des Notfallmanagements hängen von einer Reihe von Einflussfaktoren ab, insbesondere von Tü, Ta und der Höhe des Schadens, der durch die unmittelbaren und mittelbaren Folgen des Notfalls entstehen. Um Notfallvorsorge ökonomisch sinnvoll betreiben zu können, müssen die Kosten des Notfallmanagements (insbesondere verursacht durch Kosten der Vorsorgemaßnahmen) dem mit Kosten bewerteten potenziellen Schaden von Notfällen gegenübergestellt werden.

Notfallursachen Notfallursachen sind durch menschliches Versagen, technische Mängel, höhere Gewalt, kriminelle Handlungen usw. ausgelöste Ereignisse (z. B. Wassereinbruch oder Brand im

Notfallmanagement (NOMAN)

189

Rechenzentrum). Die Wahrscheinlichkeit des Eintritts eines Notfalls wird von einer Reihe außerbetrieblicher Einflussfaktoren (z. B. Terrorismus oder Naturereignisse) und innerbetrieblicher Einflussfaktoren (z. B. Zugänglichkeit des Rechenzentrums für Unbefugte, Zuverlässigkeit der IT-Mitarbeiter) bestimmt. Im Allgemeinen kann die Eintrittswahrscheinlichkeit nur grob geschätzt werden. Auch die Schätzung des Schadens, der durch einen Notfall verursacht werden kann, ist sehr schwierig; zuverlässige Erfahrungswerte liegen nicht vor.

Arten von Notfällen Welche Arten von Notfällen unterschieden werden, zeigt Abbildung NOMAN-1 in Anlehnung an den BSI-Standard 100-4 Notfallmanagement. 1 = kleinere Störung

unkritisch, niedriger Schaden, Maßnahmen können durch die betroffene Struktureinheit selbst vorgenommen werden

2 = größere Störung

kritisch, normaler Schaden, Sondermaßnahmen im Rahmen des Störungsmanagements zweckmäßig (vgl. Lerneinheit SEMAN)

3 = Notfall

sehr kritisch, hoher Schaden, Maßnahmen sind nach Notfallplan durchzuführen

4 = Katastrophe

extrem kritisch, sehr hoher Schaden, Sondermaßnahmen (wahrscheinlich unternehmensüberschreitend) erforderlich, die über den Notfallplan hinausgehen Abb. NOMAN-1: Arten von Notfällen (Quelle: nach BSI 100-4)

Die Bewertung des aus einem Notfall entstehenden Schadens hängt vor allem von Tü ab sowie davon, in welchem Zeitraum Ta die Funktions- und Leistungsfähigkeit wiederhergestellt werden kann. Da Ta besonders durch den Zeitraum zwischen dem Zeitpunkt der Nachbestellung der zerstörten Komponenten, also im allgemeinen dem Zeitpunkt des Eintritts des Notfalls, und dem Zeitpunkt der Verfügbarkeit der Ersatzkonfiguration bestimmt wird, kommt es bei der Eingrenzung des Schadens darauf an, für die schnelle Verfügbarkeit einer Ersatzkonfiguration vorzusorgen. Je höher der Durchdringungsgrad des Unternehmens mit Informationssystemen ist, desto kürzer ist Tü; auch von der Branche ist Tü stark abhängig.

Vorgehensweise beim Notfallmanagement Diese ist vor allem durch eine umfassende und systematische Notfallplanung gekennzeichnet. Notfallplanung (auch als business continuity planning bezeichnet) ist die zielorientierte und systematische Vorgehensweise bei der Ausarbeitung von Vorsorgemaßnahmen gegen den Eintritt eines Notfalls sowie von Maßnahmen beim und nach dem Eintritt eines Notfalls. Notfallplanung wird sowohl in CobiT (vgl. Lerneinheit GOVER) als auch in ITIL (vgl. Lerneinheit SEMAN) empfohlen. Empfehlungen für die Notfallplanung werden in folgenden Normen und Leitlinien gegeben: BSI-Standard 100-4, BS 25999, Good Practice Guidelines

190

Strategische Aufgaben des Informationsmanagements

des Business Continuity Institutes, ISO/IEC 24762, ISO/IEC 27031 und NIST Special Publication 800-34. Notfallplanung muss, ausgehend von den Ergebnissen der Risikoanalyse (vgl. Lerneinheit SIKON), mindestens alle in Abbildung NOMAN-1 mit 3 und 4 gekennzeichnete Zustände abdecken. Für den nach Funktions- und Leistungsfähigkeit eingeschränkten ITBetrieb ist festzulegen, mit welcher Priorität Anwendungen betrieben werden sollen. Die Notfallplanung sollte sich an konkreten, aus strategischen Sicherheitszielen (vgl. Lerneinheit SZIEL) abgeleiteten Vorgaben orientieren (z. B. Wiederanlauf Notfallbetrieb innerhalb x Tagen, Wiederanlauf Normalbetrieb innerhalb x+y Tagen). Um abzuschätzen, mit welchen Notfällen zu rechnen ist und welche Auswirkungen diese auf die Informationsinfrastruktur haben können, ist es zweckmäßig, mit Hilfe der Szenariotechnik (vgl. Lerneinheit SZENA) verschiedene Szenarien anzuwenden. Ergebnis der Notfallplanung ist der aus mehreren Teilplänen bestehende Notfallplan. Es ist sinnvoll, den Totalausfall der Informationsinfrastruktur zur Grundlage der Notfallplanung zu machen und davon ausgehend Varianten der eingeschränkten Funktions- und Leistungsfähigkeit zu planen und im Notfallplan zu dokumentieren. Eine umfassende und systematische Notfallplanung – und damit die Systematik des daraus entstehenden Notfallplans – kann wie folgt aussehen: 





Planung der Vorsorgemaßnahmen (Vorsorgeplanung). Zweck der Vorsorgeplanung ist es, den Eintritt eines Notfalls zu verhindern (deshalb auch als Notfallabwehr-Planung bezeichnet) sowie Vorsorge für das Verhalten beim Eintritt eines Notfalls und nach Eintritt eines Notfalls zu treffen. Daher befasst sich die Vorsorgeplanung mit vorbeugenden Maßnahmen baulicher, technischer, personeller und organisatorischer Art sowie mit Verhaltensmaßnahmen während des Notfalls. Ergebnis der Vorsorgeplanung ist der Vorsorgeplan. Planung der Maßnahmen beim Eintritt eines Notfalls (Einsatzplanung). Zweck der Einsatzplanung ist es, den Schaden, der durch den Notfall verursacht werden kann, so gering wie möglich zu halten. Die Einsatzplanung befasst sich daher mit den Maßnahmen zur Alarmierung der Verantwortlichen und Beteiligten und mit der Rettung von Menschen und Betriebsmitteln. Ergebnis der Einsatzplanung ist der Einsatzplan. Planung der Maßnahmen nach Eintritt des Notfalls (Wiederanlaufplanung). Zweck der Wiederanlaufplanung ist es, die Funktions- und Leistungsfähigkeit der Informationsinfrastruktur so schnell wie möglich wieder herzustellen. Dabei geht es sowohl um Maßnahmen für einen Notfallbetrieb (z. B. in einem Ausweichrechenzentrum) als auch um Maßnahmen zur Wiederherstellung des Zustands der Informationsinfrastruktur zumindest so, wie er vor Eintritt des Notfalls war (Normalbetrieb). Ergebnis der Wiederanlaufplanung ist der Wiederanlaufplan.

Ein Notfallplan kann ein mangelhaftes Sicherheitsmanagement-System nicht ersetzen (vgl. Lerneinheiten SIKON und SICHM); er ist „nur“ Leitfaden im Notfall. Ein Notfallplan setzt z. B. voraus, dass Kopien des Datenbestands und der Anwendungsprogramme vorhanden, an einen sicheren Ort (Sicherungsarchiv) ausgelagert sind und in vertretbarer Zeit mit angemessenem Aufwand verfügbar gemacht werden können (Backup-Fähigkeit). Die Häufigkeit der Auslagerung soll zu dem Aufwand, der zur Wiederherstellung des Datenbestands und der Anwendungsprogramme notwendig ist, in einem ausgewogenen Verhältnis stehen.

Notfallmanagement (NOMAN)

191

Gliederung des Notfallplans Der Notfallplan muss übersichtlich in Teilpläne gegliedert sein; diese ergeben sich aus der Notfallplanung wie folgt:   

Vorsorgemaßnahmen (Vorsorgeplan), Sofortmaßnahmen, die beim Eintritt des Notfalls zu ergreifen sind (Einsatzplan, gegebenenfalls mehrere Einsatzpläne für alternative Notfälle) und Maßnahmen, die nach Eintritt des Notfalls zu ergreifen sind (Wiederanlaufplan).

Der Notfallplan zeigt auch die Zusammenhänge zwischen den Maßnahmen auf und hilft den Verantwortlichen und Beteiligten, die Funktions- und Leistungsfähigkeit der Informationsinfrastruktur nach Eintritt eines Notfalls so schnell wie möglich wiederherzustellen. Um diese Aufgabe erfüllen zu können, muss der Notfallplan laufend aktualisiert werden. „Laufend“ heißt dabei nicht „in bestimmten Zeitabständen“ (z. B. jährlich), sondern „bei jeder für die wirksame Maßnahmendurchführung relevanten Veränderung“ der Informationsinfrastruktur. Die Erfüllung dieser Forderung setzt klar geregelte Verantwortlichkeiten und die explizite Nominierung eines Aufgabenträgers für die Pflege des Notfallplans voraus (z. B. der Sicherheitsbeauftragte, vgl. Lerneinheit SICHM). Zur Erstellung und Pflege des Notfallplans müssen alle Aufgabenträger des IT-Bereichs (insbesondere die des Rechenzentrums) und die IT-Koordinatoren beitragen. Diese Personen bilden den Krisenstab, der im Notfall tätig wird. Der Sicherheitsbeauftragte und der Datenschutzbeauftragte ergänzen den Krisenstab. Der volle Inhalt des Notfallplans darf nur den Mitgliedern des Krisenstabs bekannt sein und muss von diesen vertraulich behandelt werden, da die Beschreibung von Bedrohungen, Gefahren, Schwachstellen, Risiken und Maßnahmen zu ihrer Verhinderung auch als Anleitung zum Missbrauch dienen kann. Aus diesem Grund müssen besondere Vorkehrungen zur Wahrung der Vertraulichkeit des Notfallplans getroffen werden, wenn dieser im Intranet des Unternehmens publiziert oder auf andere Art digital verfügbar gemacht wird. Die nicht dem Krisenstab angehörenden Mitarbeiter sollen nur jene Teile des Notfallplans kennen, die sie für ihren unmittelbaren Aufgabenbereich im Notfall brauchen. Die Ausgabe des Notfallplans bzw. von Teilen soll nur mit Ausgabenummern erfolgen; der Empfang soll schriftlich bestätigt werden. Alle ausgegebenen Dokumente, die Bestätigungen und das Original sollen gesichert aufbewahrt werden. Bei Änderungen muss überprüft werden, ob alle Empfänger alle geänderten Seiten ausgetauscht haben (es empfiehlt sich daher die Loseblattform). Das Anfertigen von Kopien und die eigenmächtige Weitergabe der Dokumente an Dritte muss ausdrücklich untersagt werden. Beim Ausscheiden von Mitarbeitern muss für die Rückgabe der Dokumente gesorgt sein. Die Unternehmensleitung hat durch Unterschrift den Notfallplan zu bestätigen; sie übernimmt damit die Verantwortung für die Notfallplanung.

Inhalt des Notfallplans Die Teilpläne des Notfallplans müssen, jeder für sich allein, verständlich sein. Inhalte der Teilpläne des Notfallplans sind:

192

Strategische Aufgaben des Informationsmanagements

Vorbemerkung Sie enthält Informationen über Sinn und Zweck des Notfallplans, fordert zu seiner Befolgung auf, motiviert dazu, notwendige Planänderungen an den für den Notfallplan Verantwortlichen zu melden, gibt an, an welchen Orten der Notfallteilplan aufliegt und warnt vor missbräuchlicher Verwendung. Weitere Inhalte der Vorbemerkung sind:   

Gültigkeitsbereich des Notfallplans (zeitlich und räumlich), Mitglieder des Krisenstabs und seine Aufgaben sowie Zuständigkeit für die Erstellung und Pflege des Notfallplans.

Vorsorgeplan Dieser Teilplan beschreibt die Vorsorgemaßnahmen für den Notfall, insbesondere:                  

Name, Telefonnummer(n), Arbeitsgebäude/-raum, Privatanschrift des Verantwortlichen für die Entscheidung über den Eintritt eines Notfalls, die Aktivierung des Alarmplans und die Beendigung des Notfalls (z. B. Sicherheitsbeauftragter und Vertreter), Weisungsbefugnisse im Notfall, interne Anschriften von Hausverwaltung, Erste Hilfe, Haustechnik, Aufzüge usw., externe Anschriften von Polizei, Feuerwehr, Unfall/Rettung, Krankentransporte, Notarzt, nächstgelegene Klinik, Vertragsarzt/Werksarzt, Unfallstation, Gas-, Wasser- und Stromversorgung, Wachdienste, Sicherheitsunternehmen usw., Verzeichnis sämtlicher Sicherheitseinrichtungen (wie Feuerlöscher, Feuermelder, Tragen, Hausapotheke) mit Bezeichnung, Lage und Verantwortlichen, Erklärung der akustischen und optischen Alarmsignale (wo sie auftreten – z. B. Brandmelder, Rauchmelder, Werksalarm – und wie sie sich äußern), im Notfall vorgesehene Lautsprecherdurchsagen, Vorgehen bei der Schadensaufnahme und Schadensbewertung, Verträge mit Ausweichrechenzentren und Herstellern für Ersatz- oder Notkonfiguration, Anschriften wichtiger Lieferanten, Vereinbarungen mit zentralen Versorgungsstellen (z. B. Stromversorgung) und mit Fachabteilungen, Verträge mit den für die Datenübertragungseinrichtungen zuständigen Stellen, Aufbewahrungsorte für Dokumente, Programme und Sicherungsdatenträger (Sicherungsarchiv) sowie Vorgehensweise bei der Sicherung, Gebäude- und Raumpläne mit Lageplänen der Alarmeinrichtungen und Fluchtplänen, Verzeichnis der Mitarbeiter, die im Notfall kurzfristig zur Verfügung stehen können, mit Privatanschriften, Telefonnummern und mit Hinweisen über besondere Kenntnisse und Funktionen (z. B. Erste Hilfe, Feuerwehr), Einweisung der Mitarbeiter in die im Notfall durchzuführenden Maßnahmen, Vorgehensweise bei der Durchführung von Übungen zum Erkennen der Wirkungsweise des Notfallplans und von Fehlern und Mängeln, Liste mit Prioritäten der Anwendungen, z. B. mit folgender Klassifizierung (wobei i. d. R. von der Aufrechterhaltung der wichtigsten Funktionen bei reduzierter Leistungsfähigkeit ausgegangen wird):

Notfallmanagement (NOMAN)

        

193

A = Anwendungen, die zur Aufrechterhaltung der Funktionsfähigkeit des Unternehmens erforderlich sind (kritische Anwendungen) und die innerhalb eines Tages abgewickelt werden müssen (z. B. Produktionsplanung und -steuerung in einem Fertigungsbetrieb), B = Anwendungen, die zur Aufrechterhaltung der Funktionsfähigkeit des Unternehmens nicht zwingend erforderlich sind und die in einem Zeitraum bis zu vierzehn Tagen abgewickelt werden können (z. B. Vorkalkulation) und C = Anwendungen, auf deren Abwicklung bis zu dreißig Tage verzichtet werden kann (z. B. Fakturierung), Grundsätze für das Verhalten im Notfall wie „Rettung von Menschenleben geht vor Rettung von Sachen“ und „Aufzüge im Notfall nicht benutzen“, Alarmplan, Meldeplan, Fluchtplan, Rettungspläne und Wiederanlaufplan, Anfahrtsplan für die Feuerwehr mit Angabe der die Anfahrt behindernden Sicherheitseinrichtungen und Möglichkeiten für ihre Ausschaltung, Beschreibung der Ausweichräume (z. B. Ausweichraum für das Rechenzentrum), die sofort nach Eintritt eines Notfall verfügbar gemacht werden können, Beschreibung der Notfallorganisation, mit der im Notfall ein manueller Notfallbetrieb aufrechterhalten werden kann; die dafür erforderlichen Hilfsmittel (wie Formulare und Geräte) sind bereitzuhalten und Pläne für die Krisenkommunikation, in denen beschrieben ist, wer welche Interessengruppen (z. B. Mitarbeiter, Eigentümer, Kreditgeber, Lieferanten, Kunden, Medien und Behörden) über welche Aspekte des Notfalls informiert.

Einsatzplan Er beschreibt die vorgesehenen Sofortmaßnahmen zum Zeitpunkt des Eintritts eines Notfalls (Verhalten im Notfall). Durch den Dienst habenden Sicherheitsbeauftragten wird Alarm nach dem Alarmplan ausgelöst. Damit werden die Maßnahmen des Notfallplans aktiviert. Im Allgemeinen ist es erforderlich, zwischen generellen, von der Art des Notfalls unabhängigen und speziellen, auf die Art des Notfalls abgestimmten Maßnahmen zu unterscheiden (z. B. Verhalten bei Feuer, Verhalten bei Personenschäden, Verhalten bei Anschlägen, Verhalten bei Drohungen), so dass mehrere Einsatzpläne erforderlich sind. Generelle Sofortmaßnahmen, die bei jeder Art von Notfall Gültigkeit haben, sind:       

Evakuieren des Personals nach dem Rettungsplan, Melden des Notfalls nach dem Meldeplan (Meldeablauf), Bekämpfen der Schadensursache, Retten des Archivs nach dem Rettungsplan Archiv, Retten der Hardware nach dem Rettungsplan Hardware, Benachrichtigen der Benutzer und Bestandsaufnahme des Schadens.

Nach Aktivierung des Alarmplans muss der Krisenstab die Einleitung der vorgesehenen (weiterführenden) Maßnahmen anordnen und in Abhängigkeit von den Auswirkungen des Notfalls die vorläufige Abwicklung des RZ-Betriebs als Notfallbetrieb festlegen (z. B. Benutzung eines Ausweichrechenzentrums) bzw. die Notfallorganisation ohne oder mit eingeschränktem RZ-Betrieb in Kraft setzen.

194

Strategische Aufgaben des Informationsmanagements

Wiederanlaufplan In den meisten Fällen ist der Wiederanlaufplan der umfangreichste Teil des Notfallplans. Er enthält vor allem die Maßnahmen, die zur Wiederaufnahme des Rechenzentrumsbetriebs erforderlich sind (z. B. das Beschaffen und in Betrieb nehmen der Ersatz- oder Notfallkonfiguration, das Neugenerieren des Systems, das Wiederherstellen der Datenbanken, der Programme und der Dokumentation, das Sanieren beschädigter Geräte). Wegen der sehr unterschiedlichen Auswirkungen möglicher Notfälle kann es sich dabei nur um globale Maßnahmen handeln, so dass eine detaillierte Wiederanlaufplanung im Notfall erforderlich ist. Dabei ist davon auszugehen, dass bereits ein Notfallbetrieb läuft und dass nun weitere Maßnahmen zu ergreifen sind, um die volle Funktions- und Leistungsfähigkeit der Informationsinfrastruktur so schnell wie möglich wiederherzustellen. Das Ausweichrechenzentrum bzw. die vom Hersteller verfügbar gemachte Notkonfiguration sollte (vor allem wegen der hohen Kosten) nur so lange wie unbedingt notwendig benutzt werden. Daher muss der Krisenstab, parallel zum Notfallbetrieb, den Wiederanlauf im eigenen Rechenzentrum mit der Ersatzkonfiguration planen und intensiv betreiben. Im Notfallplan sind dokumentiert:     

Aufgaben und Aufgabenträger der Arbeitsgruppen (Notfall-Teams) für den Wiederanlauf, Hilfsmittel für den Wiederanlauf (z. B. in Form von Checklisten), Ersatzbeschaffung von Räumen und Betriebsmitteln, Installation der Ersatzkonfiguration und Umstellung vom Notfallbetrieb auf den Normalbetrieb.

Um die Ersatzbeschaffung zügig abzuwickeln, ist die Verfügbarkeit eines Ersatzbeschaffungsplans als Teil des Wiederanlaufplans zweckmäßig.

Ausweichrechenzentren Die vertragliche Sicherung von Kapazität in einem Ausweichrechenzentrum (Fremdvorsorge) oder die Einrichtung und Unterhaltung eines eigenen Ausweichrechenzentrums (Eigenvorsorge) ist eine Vorsorgemaßnahme, die dem (in der Regel nur teilweisen) Ersatz der durch einen Notfall nicht mehr verfügbaren Kapazität dient, und zwar innerhalb eines bestimmten Zeitraums Tx (vom Eintritt des Notfalls bis zur Verfügbarkeit) und für einen bestimmten Zeitraum Ty (vom Zeitpunkt der Verfügbarkeit an gerechnet). Nach einem Notfall müssen die Informationssysteme für die mit A klassifizierten Anwendungen innerhalb Tx wieder verfügbar sein. Die mit der vertraglichen Anmietung von Kapazität in einem Ausweichrechenzentrum bzw. die mit der Errichtung und Unterhaltung eines eigenen Ausweichrechenzentrums entstehenden Kosten müssen in einem angemessenen Verhältnis zur geplanten Sicherheit stehen; dies muss mit einer Risikoanalyse untersucht werden (vgl. Lerneinheit SIKON). Varianten von Ausweichrechenzentren werden in der Regel nach dem Merkmal der Wiederanlaufzeit wie folgt unterschieden: 

Es wird ein vollständig ausgestattetes und sofort produktiv verwendbares Rechenzentrum in separaten Räumen am gleichen oder an einem anderen Standort eingerichtet; im

Notfallmanagement (NOMAN)



   



195

Routinebetrieb steht es für die Systementwicklung und den Testbetrieb zur Verfügung, im Notfall übernimmt es den Produktionsbetrieb (so genanntes heißes Rechenzentrum; Wiederanlaufzeit max. ein Tag). Es wird ein zweites Rechenzentrum mit einer sofort produktiv verwendbaren Mindestausstattung (Notkonfiguration) ständig parallel zum bestehenden Rechenzentrum verfügbar gehalten (so genanntes warmes Rechenzentrum; Wiederanlaufzeit ein Tag bis vierzehn Tage). Es wird ein so genanntes kaltes Rechenzentrum ständig parallel verfügbar gehalten; es verfügt über eine Grundausstattung, die jedoch noch nicht installiert wurde (Wiederanlaufzeit vierzehn bis dreißig Tage). Ein Ausweichrechenzentrum wird gemeinsam mit anderen Unternehmen als Gemeinschafts-Rechenzentrum verfügbar gehalten (heiß, warm oder kalt). Ein Rechenzentrum eines externen Anbieters wird als Ausweichrechenzentrum verwendet (z. B. ein Service-Rechenzentrum; die Wiederanlaufzeit hängt vom Einzelfall ab, jedenfalls handelt es sich nicht um ein heißes Rechenzentrum). Von darauf spezialisierten Anbietern wird ein transportables Container-Rechenzentrum (auch als mobiles Rechenzentrum bezeichnet) mit einem (oder mehreren) vorbereiteten Standort(en) auf dem Betriebsgelände verwendet, einschließlich aller Anschlüsse für die Stromversorgung und an das inner- und überbetriebliche Kommunikationsnetz (dabei handelt es sich in der Regel um ein warmes Rechenzentrum). Es wird ein Ausweichrechenzentrum von einem externen Anbieter verwendet (dabei handelt es sich in der Regel um ein heißes Rechenzentrum).

Ein Problem aller Ausweichrechenzentren für den Anwender ist, dass die Kapazität von zentralen Rechnersystemen zwar schnell zur Verfügung steht, wegen eventuell zerstörter Datenleitungen davon aber nicht oder nicht schnell genug Gebrauch gemacht werden kann, wenn diese Kapazität nicht in unmittelbarer örtlicher Nähe des Anwenders zur Verfügung gestellt wird. Da dieses Problem beim Container-Rechenzentrum nicht besteht, ist dieses grundsätzlich die zweckmäßige Form eines Ausweichrechenzentrums. Die Kosten für ein heißes Ausweichrechenzentrum (so genannte Vorhaltekosten) betragen rd. das 100-fache der Kosten für ein kaltes Ausweichrechenzentrum. Der Anwender hat eine Form des warmen Ausweichrechenzentrums, wenn er mit seinem Hardware-Lieferanten eine vertragliche Vereinbarung über die Lieferung einer Notkonfiguration getroffen hat, die zumindest für die Abwicklung der mit A gekennzeichneten Anwendungen ausreicht und innerhalb des Überlebenszeitraums Tü nach dem Notfall am Ort des Anwenders verfügbar ist. Cloud Computing (vgl. Lerneinheit INMAN) verspricht, eine kostengünstige Alternative zu herkömmlichen Lösungen zu sein, da Anbieter von Cloud Computing die notwendige Infrastruktur zu geringeren Preisen anbieten als Betreiber von traditionellen Ausweichrechenzentren. Allerdings wird die unzureichende Zuverlässigkeit von Cloud Computing in Notfallsituationen kritisiert (vgl. z. B. Crandell).

196

Strategische Aufgaben des Informationsmanagements

Verträge mit Ausweichrechenzentren Wird für den Notfall die Nutzung eines Ausweichrechenzentrums eines darauf spezialisierten Anbieters vorgesehen, muss bei der Vertragsgestaltung (vgl. Lerneinheit VERMA) Folgendes geregelt werden:      

   

Art und Umfang der im Notfall verfügbaren Hardware (einschließlich Spezialperipherie, z. B. Belegleser) und Systemsoftware sowie Sicherung der Vereinbarkeit mit der eigenen Anwendungssoftware und mit Datenbanken, Art und Umfang der im Notfall verfügbaren Leitungen (z. B. Standleitungen), Bereitstellung von Unterstützungsleistungen für das Operating im Notfall und bei Notfall-Tests, Benutzungsentgelt für die Bereitstellung der Hardware und Systemsoftware sowie aller notwendigen Nebenleistungen (z. B. Benutzung von Büroräumen, Telefon, Kopierer), Anzahl der abgedeckten Notfälle (z. B. ein Notfall pro Kalenderjahr), maximale Zeitdauer eines Notfalls (z. B. 30 aufeinander folgende Kalendertage) und Anzahl der Notfall-Tests pro Kalenderjahr, Beweislast für den Eintritt des Notfalls und notwendige Voraussetzungen, bei deren Vorliegen das Ausweichrechenzentrum benutzt werden kann (z. B. wenn der eigene Rechenzentrumsbetrieb nicht innerhalb von 2 Tagen nach Eintritt des Notfalls wieder aufgenommen werden kann), Meldeverfahren beim Eintritt des Notfalls, maximale Anzahl der Vertragspartner, mit denen das Ausweichrechenzentrum gleichartige Verträge abschließen darf, Haftungsumfang des Ausweichrechenzentrums für Schäden und Regelung der Abstimmung zwischen Ausweichrechenzentrum und Kunden bei einem geplanten Hardware-/Softwarewechsel.

Zweckmäßigkeit und Notwendigkeit von Notfall-Tests werden oft in Frage gestellt bzw. ihre Praktikabilität wird bezweifelt. Dies beruht meist auf der Annahme, der Notfall-Test müsse „physisch“ abgewickelt werden, was zweifellos oft problematisch ist. Meist ist es ausreichend, den Notfall-Test mit geeigneten Methoden zu simulieren, beispielsweise mit der Szenariotechnik (vgl. Lerneinheiten SZENA und SIKON).

Forschungsbefunde Duscha/Hotz berichten über eine Erhebung (Online-Befragung von 303 deutschen KMU, keine Angaben zur Rücklaufquote, Untersuchungszeitraum November 2010) zur Netz- und Informationssicherheit in kleinen und mittelständischen Unternehmen. Nur in ca. 24 % der Unternehmen existieren unternehmensspezifische IT-Notfallpläne. In 29 % der Unternehmen existieren solche Pläne nur für Teilbereiche. 38 % der Unternehmen haben überhaupt keine Notfallpläne, weitere 9 % machten zu diesem Thema keine Angaben. Bei dem von Ernst & Young 2009 durchgeführten Global Information Security Survey (Befragung von ca. 1900 IT-Führungskräften in 60 Ländern, keine Angaben zur Rücklaufquote, Untersuchungszeitraum Juni bis August 2009) gaben 15 % der Teilnehmer an, „disaster

Notfallmanagement (NOMAN)

197

recovery/business continuity“ an externe Dienstleister ausgelagert zu haben. 12 % prüften oder planten diese Möglichkeit. 73 % hatten keine Pläne, Notfallmanagement auszulagern. Im Lagebericht zur Informationssicherheit der /Microsoft-Sicherheitsstudie 2010 (schriftliche Befragung von 135 für IT-Sicherheit verantwortliche Mitarbeiter von Unternehmen und Behörden in Deutschland, Österreich und der Schweiz, Rücklaufquote nicht angegeben; Untersuchungszeitraum Dezember 2009 bis Mai 2010) gaben 80 % der Befragten an, dass ein IT-Notfall-/Wiederanlaufkonzept existiert, allerdings ist dies nur in 89 % der Fälle schriftlich fixiert. Auf die Frage, ob das Notfallkonzept explizit spezielle Anforderungen für folgende Ereignisse berücksichtigt, antworteten von 105 Teilnehmern mit ja: Hardware-Ausfall/-Wiederbeschaffung (92 %), physische Einwirkungen (90 %), Malware/Exploit-Epidemien (66 %), Software-Sicherheitsvorfälle (65 %), Zusammenbruch externer Infrastrukturen (58 %), gezieltes Eindringen durch Einzeltäter (48 %) und Denial-of-ServiceAttacken (39 %). Zu Notfallmaßnahmen für längere Ausfälle von Unternehmens-Servern bzw. Mainframes wurden folgende Angaben gemacht (Werte in Klammern = Anteil der Unternehmen, in denen die Maßnahme realisiert, geplant, nicht vorgesehen war): Versicherung abgeschlossen (55 %, 3 %, 41 %); Virtualisierung mit redundanter Datenhaltung (51 %, 12 %, 36 %); Cluster/Load-Balancing mit Überkapazität (41 %, 3 %, 55 %); Verträge über die schnelle Lieferung von Hardware (38 %, 8 %, 54 %); laufende Systeme („heiße“ Lösung) (38 %, 4 %, 58 %); Räume mit Hardware („warme“ Lösung) (32 %, 10 %, 58 %); Räume („kalte“ Lösung) (23 %, 3 %, 73 %); Verträge über die Nutzung externer Ressourcen (23 %, 4 %, 73 %); konfigurationsidentische Netze (19 %, 5 %, 76 %); Verträge über die Nutzung kurzfristig verfügbarer Container (13 %, 1 %, 86 %); Nutzung von Cloud-/SaaS-Diensten (5 %, 6 %, 89 %).

Aus der Praxis Thiel/Thiel stellen fest, dass bei kleinen und mittelständischen Unternehmen (KMU) „erheblicher Nachholbedarf“ (404) im Notfallmanagement besteht. Bisher publizierte Standards werden von diesen Unternehmen oft als zu komplex und in der Umsetzung als zu aufwendig wahrgenommen. Thiel/Thiel entwickeln einen Leitfaden zum Notfallmanagement, der verständlich und für KMU leicht anzuwenden ist. Die wichtigsten Elemente des Leitfadens sind: Krisenstab; Krisenorganisation mit klaren Zuständigkeits-/Verantwortungsbereichen; Krisensprecher; Kontaktinformationen bzw. Kontaktliste; kritische Bestandsaufnahme des Unternehmens mit SWOT-Analyse; Risikoanalyse zur Identifizierung von Krisenherden; Business-Impact-Analyse mit Auswirkungen auf kritische Geschäftsprozesse; Identifikation, wie lange das Unternehmen im Falle eines Ausfalles überleben kann; Risikoklassifikation (Risiken akzeptieren – keine Veränderung vornehmen; Risiken akzeptieren, jedoch mit einer anderen Firma oder einem Business-Continuity-Partner eine gegenseitige Vereinbarung treffen, um Hilfeleistung nach einem Vorfall sicherzustellen; Risiken reduzieren und Vorkehrungen zur Hilfeleistung nach einem Vorfall treffen; Risiken soweit reduzieren, bis keine externe Hilfestellung mehr erforderlich ist; Risiko vermeiden; Risiko auslagern bzw. versichern); Präventionsmaßnahmen festlegen; Infrastruktur/Logistik (vor allem Brandschutz etc.); Personal (4-Augenprinzip etc.); externe Dienstleister (Zweitlieferanten); Technik (Da-

198

Strategische Aufgaben des Informationsmanagements

tensicherung, Datenspiegelung etc.); Bewältigungsmaßnahmen für High-Risk-Szenarien festlegen; Evakuierungspläne; Zweitstandortpläne; Zweitlieferantenpläne; IT-DisasterRecovery-Pläne; Richtlinien und Checklisten aufgrund erstellter Krisenpläne; Maßnahmen schulen; Pläne testen; Pläne verbessern; Pläne regelmäßig aktualisieren. Methodenverweise Sicherheitskonzepte (Lerneinheit SIKON); Szenariotechnik (Lerneinheit SZENA). Kontrollfragen 1. Worin unterscheidet sich Notfallmanagement von Sicherheitsmanagement? 2. In welcher Beziehung steht Notfallmanagement zum Servicemanagement? 3. Welche Aufgaben hat ein Krisenstab im Notfall und wer ist Mitglied des Krisenstabs? 4. Wodurch unterscheidet sich ein Notfallplan für eine Grippe-Epidemie von einem Notfallplan für einen Denialof-Service-Angriff? 5. Wie lässt sich der Betrieb eines warmen (Ausweich-)Rechenzentrums wirtschaftlich rechtfertigen? Quellen Crandell, M.: How to Ensure Business Continuity in the Cloud. 2011, http://gigaom.com; Abruf 28. Juni 2011 Duscha, A. / Hotz, A.: Netz- und Informationssicherheit im Unternehmen 2010. Ergebnisse einer Online-Befragung von 303 kleinen und mittelständischen Unternehmen in Deutschland. Köln 2010 Ernst & Young (Hrsg.): Outpacing change. Ernst & Young’s 12th annual global information security survey. o. O. 2009, http://www.ey.com; Abruf 18. Mai 2010 o. V.: Lagebericht zur Informationssicherheit (3). /Microsoft-Sicherheitsstudie 2010. In: Die Zeitschrift für Informationssicherheit 6/2010, 14–21 Thiel, C. / Thiel, C.: Business Continuity Management für KMU. In: Datenschutz und Datensicherheit 6/2010, 404– 407 Vertiefungsliteratur Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz-Kataloge 2008. http://www.bsi.de; Abruf 12. Mai 2011 Business Continuity Institute (BCI): Good Practice Guidelines (GPG). Version 2010. http://www.thebci.org/gpg.htm; Abruf 12. Mai 2011 Cerullo, V. / Cerullo, M. J.: Business Continuity Planning: A Comprehensive Approach. In: Information Systems Management 3/2004, 70–78 Hiles, A. (Hrsg.): The Definitive Handbook of Business Continuity Management. 2. A. Chichester 2007 IT Governance Institute (Hrsg.): COBIT 4.1: Framework, Control Objectives, Management Guidelines, Maturity Models. Rolling Meadows 2007, Abschnitt DS 4 Ensure Continuous Service NIST Special Publication 800-34 rev. 1: Contingency Planning Guide for Federal Information Systems. Washington 2010 Rudd, C. / Lloyd, V.: Service Design ITIL, Version 3. London 2007; Abschnitt zu IT Service Continuity Management von Rössing, R. : Betriebliches Kontinuitätsmanagement. Bonn 2005 Wieczorek, M. / Naujoks, U. / Bartlett, B. (Hrsg.): Business Continuity. Notfallplanung für Geschäftsprozesse. Berlin/Heidelberg/New York 2003 Informationsmaterial Business Continuity Institute http://www.thebci.org/ BS25999 World http://www.25999.info Normen BS 25999-1:2006 Business continuity management, Part 1: Code of practice BS 25999-2:2007 Business continuity management. Part 2: Specification BSI-Standard 100-4 Notfallmanagement. Version 1.0 2008 ISO/IEC 24762:2008 Information technology - Security techniques - Guidelines for information and communications technology disaster recovery services ISO/IEC 27031:2011 Information technology – Security techniques – Guidelines for information and communication technology readiness for business continuity

Controlling (CONTR) Lernziele Sie kennen den Zweck des IT-Controllings einschließlich der Prozesse zur Schaffung, Aufrechterhaltung und Nutzung der Informationsinfrastruktur. Sie kennen die Funktionen des Controllings und können sie erläutern. Sie kennen die Gliederung der Grundfunktion in Teilfunktionen. Sie wissen, wie Controlling-Objekte gebildet werden. Sie können alternative Organisationskonzepte des IT-Controllings erläutern und ihre Eignung beurteilen. Sie kennen Unterschiede und Gemeinsamkeiten von Controlling und Revision.

Definitionen und Abkürzungen Abweichung (deviation) = Unterschied zwischen dem Wert eines Attributs im Sollzustand und dem Wert desselben Attributs im Istzustand. IFRS = International Financial Reporting Standards; Sammlung von Regeln für die Rechnungslegung zwecks internationaler Vergleichbarkeit von Jahresabschlüssen. Kontrolle (inspection) = Teil der betrieblichen Aufgabe Überwachung, welcher der Beobachtung des tatsächlichen Verhaltens und seiner Beurteilung anhand von Verhaltenserwartungen durch prozessunabhängige Personen dient. Koordination (coordination) = Abstimmung der Tätigkeiten mehrerer Aufgabenträger, zwischen deren Aufgaben Interdependenz besteht. Messen (measuring) = Zuordnen von Zahlen oder anderen Symbolen zu Eigenschaften von Objekten, Ereignissen oder Situationen nach einem festgelegten Verfahren. Messgröße (measuring figure) = Eigenschaft eines Objekts, deren Ausprägung mit einer Messmethode ermittelt werden kann. Synonym: Metrik. Messgrößentransformation (measuring figure transformation) = Vorschrift zum Überführen von Messgrößen in einen Wert, der mit dem Sollwert des Controlling-Ziels verglichen werden kann. Messinstrument (measuring instrument) = organisatorisches, hardwaremäßiges und/oder softwaremäßiges Werkzeug zum Messen. Messobjekt (measuring entity) = Element des Controlling-Objekts (z. B. IT-Abteilung), das den Zielinhalt des Messziels beschreibt (z. B. Personalkosten). Messpunkt (measuring point) = Stelle eines Messobjekts, an der eine Messgröße erfasst werden kann (z. B. Projekttagebuch). Messmethode (measuring technique) = Verfahren zum Messen (z. B. Messen der Komplexität von Software mit dem Function-Point-Verfahren). Messziel (measuring goal) = operationales und für bestimmte Messzwecke wirtschaftlich verwendbares Ziel (z. B. Wirtschaftlichkeit). Metrik (metric) = Synonym für Messgröße. Steuerung (control) = betriebliche Aufgabe, die mit geeigneten Maßnahmen auf Abweichungen reagiert, um die bei der Planung getroffenen Entscheidungen durchzusetzen. Überwachung (monitoring) = betriebliche Aufgabe der Beobachtung und Beurteilung, die in die Teilaufgaben Revision und Kontrolle gegliedert ist.

200

Strategische Aufgaben des Informationsmanagements

Zweck des Controllings Die Informationsinfrastruktur sowie die Prozesse zu ihrer Schaffung, Aufrechterhaltung und Nutzung erfordern eine an Zielen orientierte Planung, Überwachung und Steuerung. Zweck des IT-Controllings (von engl. to control = lenken, steuern, regeln) ist es, dem Management die zur Planung, Überwachung und Steuerung der IT erforderlichen Informationen sowie Grundsätze, Methoden und Instrumente für die Gestaltung der Planungs-, Überwachungsund Steuerungsprozesse zur Verfügung zu stellen (d. h. Sicherung der Inputrationalität). Nach Horváth obliegt dem Management die Führungsverantwortung (d. h. Entscheidungen fällen und durchsetzen), den Aufgabenträgern des Controllings die Transparenzverantwortung (d. h. die für Entscheidungen erforderlichen Informationen beschaffen und liefern). von Dobschütz vergleicht die beiden Rollen mit denen des Schiffskapitäns (Führungsverantwortung) bzw. des strategische Ziele Schiffslotsen (Transparenzverantwortung). Controlling wird also primär als Informationsversorgungssystem Plan Ist für das Management verstanden. Nur mit seiner Hilfe lässt sich die erfolgreiche Abwicklung der IMadministrative Ziele Aufgaben nachweisen. Controlling muss auf der strategischen Aufgabenebene entwickelt und implemenPlan Ist tiert und top-down durchgängig über die administrative bis in die operative Aufgabenebene so durchgesetzt operative Ziele werden, dass ein geschlossener Wirkungskreislauf entsteht, der den gesamten IT-Bereich mit allen für den Plan Ist Unternehmenserfolg relevanten Objekten und Eigenschaften umfasst (ganzheitliches oder integriertes IT- Abb. CONTR-1: Wirkungskreislauf des Controllings Controlling, vgl. Abbildung CONTR-1). Nach dem Drei-Ebenen-Modell des Informationsmanagements (vgl. Lerneinheit ERMOD) gibt es Führungsaufgaben auf strategischer, administrativer und operativer Ebene. Beispielsweise auf strategischer Ebene in den Rollen des CIO (vgl. Lerneinheit STELL) und des Lenkungsausschusses (vgl. Lerneinheit STRUK), auf administrativer Ebene in den Rollen der Leitung der IT-Abteilung und Leitung der IT-Projekte, auf operativer Ebene in der Rolle der Projektmitarbeiter mit Handlungsspielraum, insbesondere mit Entscheidungsspielraum bei der Projektabwicklung. Während auf strategischer Ebene Führungs- und Transparenzverantwortung im Allgemeinen von verschiedenen Aufgabenträgern wahrgenommen werden (CIO und Lenkungsausschuss werden vom Controlling als Institution mit Informationen versorgt, beschaffen sich diese aber nicht selbst), nehmen Aufgabenträger auf administrativer und operativer Ebene in Bezug auf bestimmte Ziele und/oder Objekte beide Rollen wahr. Beispielsweise erarbeitet die Projektleitung bei der Projektplanung die administrativen Projektziele für die Projektabwicklung, wobei sie sich an den vom Lenkungsausschuss vorgegebenen Planungszielen orientiert, und sie überwacht und steuert die Projektabwicklung. Gegenüber den Projektmitarbeitern nimmt die Projektleitung auch Führungsaufgaben wahr. Projektmitarbeiter leiten aus den administrativen Projektzielen operative Projektziele ab, mit denen sie ihr individuelles Handeln bzw. das Handeln in Arbeitsgruppen steuern; als Leiter von Projektgruppen nehmen sie auch Führungsaufgaben wahr.

Controlling (CONTR)

201

Controlling-Objekte Um die Controlling-Aufgaben (vgl. den nächsten Abschnitt) wahrnehmen zu können, muss die IT systematisch zerlegt werden. Die Zerlegung soll so erfolgen, dass Zusammenhänge im Leistungsprozess des IT-Bereichs so wenig wie möglich zerschnitten werden. Ergebnis der Zerlegung sind Controlling-Objekte (auch als Steuerungsobjekte bezeichnet). Unlogisch ist es, Zielinhalte (z. B. Sicherheit, Innovationsfähigkeit) als Controlling-Objekte zu verwenden. Auf einer ersten Gliederungsebene sind Controlling-Objekte die im Folgenden genannten Artefakte, die weiter zerlegt werden können (wie in Klammern beispielhaft angegeben ist).      

Institutionen (z. B. IT-Abteilung und Stellen der IT-Abteilung) und Anwender (z. B. Geschäftsfelder, Geschäftsprozesse, Fachabteilungen oder Filialen), Projekte und Projektportfolios (z. B. Entwicklungsprojekte, Wartungsprojekte), Informationssysteme (z. B. für ein Geschäftsfeld oder einen Funktionsbereich) oder Anwendungssysteme (z. B. für einen Geschäftsprozess), Betriebsmittel (z. B. zentrale Betriebsmittel wie Hostsysteme und Server, dezentrale Betriebsmittel wie Lokale Netze und PC-Cluster), Leistungsprozesse (d. h. die von den Kunden wahrgenommenen IT-Services) und IT-Prozesse (z. B. Evaluierungsprozesse, Planungsprozesse, Beschaffungsprozesse für Betriebsmittel, Outsourcing-Prozesse, Verrechnung von Kosten auf Leistungen, Personalentwicklungs- und Verhandlungsprozesse).

Moderne IT-Architekturen (vgl. Lerneinheit ARCHI) sind modular aufgebaut (z. B. bezüglich Hardware und Datenbasen) und verteilt (z. B. verteilte Hardware, verteilte Datenbasen). Das Controlling sollte sich bei Festlegung der Controlling-Objekte an der IT-Architektur orientieren und keine Gliederung aus Controlling-Gesichtspunkten allein durchsetzen. Dieser Forderung kann am besten entsprochen werden, wenn die Aufgabenträger des Controllings an Entscheidungen zur Architekturbildung beteiligt werden. Da die IT auch aus Kombinationen und Vernetzungen der genannten Objekte besteht (z. B. in Projekten genutzte Betriebsmittel), können auch diese Controlling-Objekte sein. Welche Metriken zum Controlling geeignet sind, hängt im Wesentlichen vom Controlling-Ziel und Controlling-Objekt ab. Beispielsweise sind für Entwicklungsprojekte folgende Klassen von Metriken geeignet:    

Fortschrittsmetriken (z. B. Termineinhaltung als Verhältnis abgearbeiteter Arbeitspakete zu geplanten Arbeitspaketen), Umfangsmetriken (z. B. Anzahl Anwendungsfälle und grafischer Benutzeroberflächen), Fehlermetriken (z. B. Fehleranzahl) und Testmetriken (z. B. Anzahl Testfälle und Testabdeckungsgrad).

Aus ökonomischen und technischen Metriken dieser Art können Kennzahlen (vgl. Lerneinheit KENNZ) zu Produktivität und Qualität abgeleitet werden (z. B. Produktivität der Softwareentwicklung als Verhältnis „Anzahl Function Points zu Aufwand in Personentagen“ bei Verwendung des Function-Point-Verfahrens für die Aufwandsschätzung). Metriken mit explizitem Leistungsbezug für das Messen von Objekteigenschaften und hoher Bedeutung für die Zielerreichung werden meist als Key Performance Indicators (KPI) bezeichnet.

202

Strategische Aufgaben des Informationsmanagements

Controlling-Aufgaben Controlling-Aufgaben sind Planungs- und Kontrollaufgabe (auch als Grundfunktion des Controllings bezeichnet, die weiter in Teilaufgaben zerlegt wird), Koordinationsaufgabe und Innovationsaufgabe. Eine präzisere Beschreibung kann durch eine am Controlling-Objekt orientierte Aufgabenzerlegung erfolgen. Beispielsweise wird das Controlling-Objekt Outsourcing-Prozesse (vgl. Lerneinheit OUTSO) zunächst phasenorientiert zerlegt (z. B. Prüfung und Vorbereitung, Umsetzung, laufender Betrieb und Beendigung). Die Phasen werden dann weiter zerlegt, beispielsweise die Phase „Prüfung und Vorbereitung“ in die Aufgaben Spezifikation der IT-Leistungen, Identifikation der Outsourcing-Anbieter, Abstimmung mit der IT-Strategie sowie Erarbeitung von Empfehlungen auszulagernder IT-Leistungen. Für die Phase „laufender Outsourcing-Betrieb“ sind Qualitätsmanagement (Identifizieren von Qualitätsforderungen und Lenkung der Einhaltung der Qualitätsforderungen) und Kostenmanagement (Analyse der Kosten der IT-Leistungen) typische Controlling-Aufgaben.

Planungs- und Kontrollaufgabe Die drei Teilaufgaben der Planungs- und Kontrollaufgabe sind: 

 

Unterstützen des Managements beim Setzen von Zielen (Zielinhalte) und Festlegen von Plan- oder Sollwerten (Ausmaß der Zielerreichung) für die gesetzten Ziele, womit normative Aussagen der Entscheidungsträger über den anzustrebenden Zustand des Controlling-Objekts gemacht werden. Unterstützen des Managements beim Überwachen des Zustands des Controlling-Objekts durch Vergleich von gemessenen Istwerten (Messen der Zielerreichung) mit Plan- oder Sollwerten und Feststellen von Abweichungen. Unterstützen des Managements beim Steuern des Controlling-Objekts, indem Abweichungen analysiert und Maßnahmen angeboten werden, um diese zu beseitigen bzw. die gesetzten Ziele anzupassen (z. B. den Zielerreichungsgrad zu verringern).

Abbildung CONTR-2 zeigt den Wirkungskreislauf der Planungsund Kontrollaufgabe, die dazu in weitere Teilaufgaben gegliedert ist. „Projektabwicklung“ steht beispielhaft für jede Art von Controlling-Objekt im Prozess der Aufgabenerfüllung im ITBereich. Im Folgenden werden das Setzen von Zielen und das Messen der Zielerreichung wegen ihrer methodischen und praktischen Bedeutung erläutert und die Rückkopplungen aus der Teilaufgabe „Beseitigen der Abweichungsursachen“ erklärt.

Setzen von Zielen Beseitigen der Abweichungsursachen Festlegen von Planwerten zu den Zielen

Analysieren der Abweichungsursachen

Vorgeben der Ziele und Planwerte

Feststellen von Abweichungen Messen der Zielerreichung Projektabwicklung

Abb. CONTR-2: Wirkungskreislauf Planungs- und Kontrollaufgabe

Controlling (CONTR)

203

Setzen von Zielen Das Setzen von Zielen heißt zunächst, darüber zu entscheiden, welche Zielinhalte verfolgt werden sollen (Zielfindung). Weiter heißt das Setzen von Zielen, das Ausmaß der Zielerreichung und dessen zeitlichen Bezug festzulegen. Die Zielinhalte der strategischen Controlling-Ziele entsprechen denen der strategischen IT-Ziele, wie sie im Prozess der strategischen IT-Planung festgelegt werden (vgl. Lerneinheit SZIEL). Der Prozess der Zielfindung folgt dem Top-down-Ansatz, mit dem die strategischen, für den IT-Bereich als Ganzes geltenden, die kritischen Wettbewerbsfaktoren nachhaltig beeinflussenden und langfristig verfolgten Ziele auf die administrative Ebene heruntergebrochen werden. Dies erfolgt, indem strategischen IT-Ziele auf einzelne Controlling-Objekte (z. B. Rechenzentrumsbetrieb, Entwicklungsprojekte, Beschaffungsprozesse) bezogen werden und/oder die Zielinhalte verfeinert werden (z. B. wird Sicherheit durch Integrität, Verfügbarkeit, Vertraulichkeit und Verbindlichkeit präzisiert). In analoger Weise wird verfahren, um administrative Ziele auf die operative Ebene herunterzubrechen (z. B. Antwortzeitverhalten bei der Systemnutzung, Vertraulichkeit bei der Nutzung von Datenbeständen). Die IT-Komponenten und die zur Schaffung, Aufrechterhaltung und Nutzung der IT erforderlichen Aktivitäten werden als Controlling-Objekte, Kontrollfelder, Koordinationsfelder oder Prüffelder bezeichnet (vgl. den Abschnitt ControllingObjekte).

Messen der Zielerreichung Das Messen der Zielerreichung ist unabdingbare Voraussetzung für Überwachung und damit für Controlling überhaupt. Es erfolgt mit Messmethoden, die für jedes Ziel eine operationale (d. h. intersubjektiv nachprüfbare), im Idealfall eine quantitative Erfassung der Istwerte ermöglichen und die als Controlling-Methoden implementiert werden (z. B. im Kennzahlensystem, vgl. Lerneinheit KENNZ). Bei einem umfassenden, ganzheitlichen Konzept des ITControllings gibt es eine große Anzahl von Zielen, die sich auf zahlreiche Objekte beziehen und damit eine Menge von Controlling-Methoden erfordern. Sie unterstützen insbesondere die Aufgabe des Controllings, Istwerte der Controlling-Ziele so zu erfassen, dass durch Soll/ Ist-Vergleiche Abweichungen erkannt werden können und durch geeignete Maßnahmen steuernd eingegriffen werden kann. Das systematische Vorgehen beim Entwickeln von Messmethoden kann mit fünf Arbeitsschritten beschrieben werden (mit Beispielen für das Controlling-Objekt Entwicklungsprozess): 



Erster Arbeitsschritt: Präzisieren der Controlling-Ziele durch je ein Messziel oder mehrere Messziele, deren Dimension operational formuliert werden kann bzw. können. Diese Präzisierung ist für Controlling-Ziele nicht erforderlich, die bereits operational formuliert sind; diese Controlling-Ziele sind als Messziele verwendbar. Beispiel: ControllingZiel ist Termineinhaltung, Messziele sind Fortschrittstermine gemäß Projektplanung. Zweiter Arbeitsschritt: Bestimmen der Messobjekte für jedes Messziel. Messobjekte werden aus dem Zielinhalt des Messziels abgeleitet; ein Messziel kann durch ein oder mehrere Messobjekte erfasst werden. Beispiel: Arbeitstagebücher der Projektmitarbeiter.

204

   

Strategische Aufgaben des Informationsmanagements

Dritter Arbeitsschritt: Bilden der Messgrößen für jedes Messobjekt, Festlegen des Maßstabs für die Messgrößen und der geforderten Messgenauigkeit. Beispiel: Beginn- und Endezeiten der Projektarbeit je Arbeitspaket; 15-Minuten-Genauigkeit. Vierter Arbeitsschritt: Bestimmen der Messpunkte für jedes Messobjekt zum Erfassen der Messgrößen. Beispiel: Arbeitspakete. Fünfter Arbeitsschritt: Festlegen der Messinstrumente. Die Art der Messinstrumente hängt von der Art der Messobjekte, Messgrößen und Messpunkte ab und wird auch durch die geplante Messgenauigkeit beeinflusst. Beispiel: Zeitmessung mit der Uhr. Sechster Arbeitsschritt: Festlegen der Messgrößentransformation. Der ControllingZyklus vom gemessenen Istwert zum geplanten Sollwert wird damit geschlossen. Beispiel: Messgrößentransformation nicht erforderlich, wenn Sollwert und Istwert von gleicher Dimension sind (z. B. Zeiteinheiten, Geldeinheiten, Stück).

Primäres Controlling-Ziel für alle Controlling-Objekte und die damit im Zusammenhang stehenden Führungsentscheidungen und deren Auswirkungen ist nach herrschender Meinung Wirtschaftlichkeit. Nach von Dobschütz ist dabei sowohl die Sicht des IT-Bereichs als Leistungsgeber (Bereitstellungswirtschaftlichkeit), als auch die der Fachabteilungen bzw. Geschäftsprozesse als Leistungsnehmer (Verwendungswirtschaftlichkeit) zu berücksichtigen. Da Kosten und Nutzen Messobjekte für Wirtschaftlichkeit sind (vgl. Lerneinheit WIRTA) und Kostendenken vorherrscht, sind Kostenanalysen (vgl. Lerneinheit KOLER) bezüglich Kostenhöhe, Kostenstruktur und Kostenverlauf, allgemeiner gesagt sind Abweichungsanalysen (d. h. das Feststellen von Abweichungen und Analysieren von Abweichungsursachen) eine für die Grundfunktion des Controllings typische Teilaufgabe (vgl. Abbildung CONTR2). Maßnahmen zum Beseitigen von Abweichungen sind in erster Linie darauf ausgerichtet, das Controlling-Objekt (z. B. die Projektabwicklung) zielorientierter zu gestalten (z. B. den Projektumfang zu reduzieren). Wenn dies nicht oder nicht allein möglich ist, müssen die Planwerte angepasst werden (z. B. das Projektbudget erweitert werden).

Koordinationsaufgabe Neben Planung und Kontrolle soll das Controlling die Koordination der Führungsaufgaben in den Leistungsprozessen unterstützen, die der Schaffung, Aufrechterhaltung und Nutzung der Informationsinfrastruktur dienen. Dies gilt für die Führungsaufgaben in allen Leistungsprozessen (z. B. Führungsaufgaben der Systementwicklung, der Beschaffung von Betriebsmitteln, der Produktion oder des Outsourcings) und unabhängig von der verwendeten Technologie. Argumente für die Notwendigkeit der Koordination sind (nach Seibt):   

Betriebliche Aufgaben werden durch verschiedene Technologiearten unterstützt; Entscheidungen über den Technologieeinsatz sowie über die Kombination und Integration von Technologien sind von erheblicher Komplexität und wirtschaftlicher Tragweite. Wissen über Voraussetzungen und Konsequenzen des Technologieeinsatzes befindet sich fast ausschließlich in der IT-Abteilung und wird aus einer zu eingeschränkten Sicht genutzt, ohne ausreichende Berücksichtigung der unternehmensweiten Auswirkungen. Wegen der Vielfalt der Technologien und der daraus resultierenden Vielfalt der organisatorisch-technologischen Alternativen müssen diese systematisch erkannt und ihre Wirksamkeit und Wirtschaftlichkeit für das Unternehmen als Ganzes beurteilt werden.

Controlling (CONTR)



205

Die Realisierung von Insellösungen, die für das Unternehmen als Ganzes nur Teiloptima darstellen (während an anderen Stellen gravierende Mängel und Schwachstellen und somit Ungleichgewichte auftreten) soll verhindert werden.

Innovationsaufgabe Über Planung, Kontrolle und Koordination hinaus soll das Controlling Innovation unterstützen, was mit seiner Nähe zu den operativen Einheiten (Fachabteilungen, Geschäftsprozesse) begründet wird. Wesentliche Aspekte der Innovationsaufgabe sind das Erkennen von Stärken und Schwächen der Geschäftsprozesse und damit des Rationalisierungspotenzials (vgl. Lerneinheit GPMAN) sowie das Erkennen des Innovationspotenzials von Technologien (vgl. Lerneinheit TECHM). Im ersten Fall fordern die Geschäftsprozesse die Innovation, im zweiten Fall „treibt“ die Technologie die Innovation. Bei einer Gliederung des IT-Bereichs in Infrastruktur und Dienstleistungen (d. h. Nutzung der Infrastruktur) kann sich Innovation sowohl auf das eine (d. h. innovativer Technologieeinsatz) wie auf das andere (d. h. innovative Technologienutzung) beziehen. Auf derartigen Befunden beruht die Forderung an das Controlling, strategische Lücken zu erkennen (vgl. Lerneinheit SITAN), Projektideen zu generieren, innovative IT-Projekte zu initiieren und Kriterien für die Projektpriorisierung zu empfehlen (vgl. Lerneinheit SPLAN). Dies sollte organisatorisch über den Lenkungsausschuss geregelt werden (vgl. Lerneinheit STRUK). Der damit ausgelöste Innovationsprozess sollte nach der Projektdurchführung beurteilt werden (vgl. Lerneinheit EVALU), was zu Nachbesserungen des Innovationsprozesses oder zu neuen Innovationsprozessen führt.

Organisation des Controllings Das Controlling unterliegt selbst der organisatorischen Gestaltung, so dass die Frage beantwortet werden muss, wie die Controlling-Aufgaben unter Berücksichtigung der ControllingObjekte in Teilaufgaben zerlegt, welchen Stellen sie zugeordnet und wie die Beziehungen dieser Stellen mit den anderen Struktureinheiten geregelt werden sollen. Bei der Zerlegung der Controlling-Aufgaben stellen der Aufgabeninhalt und die Kompetenzart (die von der Antrags- über die Informations- und Mitsprachekompetenz bis zur Anweisungs- oder sogar Ausführungskompetenz reichen kann) zwei verschiedene Dimensionen der Aufgabenzerlegung dar. Eine besondere Behandlung des IT-Controllings ist nicht zweckmäßig; es wird wie jedes Controlling anderer Unternehmensbereiche oder -funktionen behandelt (z. B. wie Beschaffungs-, Produktions-, Vertriebs- und Verwaltungscontrolling). In engem Zusammenhang mit der Kompetenzart steht die Art der Controlling-Stellen. Dabei geht es primär um die Frage, ob Linienstellen oder Stabsstellen zweckmäßiger sind. Im Allgemeinen ist es erforderlich, Controlling-Stellen mit mehr Kompetenz auszustatten, als Stabsstellen üblicherweise haben. Deshalb überwiegen in der Praxis Organisationsformen, bei denen dem Controlling Weisungskompetenz für bestimmte Aufgaben eingeräumt wird. Die Weisungskompetenz erstreckt sich jedoch lediglich darauf, wie bestimmte Aufgaben durchgeführt werden. Je nach Art der Controlling-Aufgabe bzw. des Controlling-Objekts kann die Weisungskompetenz unterschiedlich gestaltet sein.

206

Strategische Aufgaben des Informationsmanagements

Bei der organisatorischen Einordnung des Controllings als Institution geht es darum, zu entscheiden, auf welcher Unternehmensebene sie erfolgen soll. Ergebnisse empirischer Untersuchungen zeigen, dass in der Praxis die Einordnung auf der zweiten Unternehmensebene überwiegt, wobei meist eine Unterstellung unter das Mitglied der Unternehmensleitung erfolgt, welches für das Finanzwesen zuständig ist, also den CFO (vgl. Lerneinheit STELL). Die organisatorische Gliederung des Controllings als Institution wird maßgeblich durch die Unternehmensorganisation bestimmt. Je stärker das Unternehmen dezentralisiert ist, desto eher bietet sich auch eine Dezentralisierung des Controllings als Institution an. Die Form der Dezentralisierung hängt in erster Linie davon ab, ob das Unternehmen funktional oder divisional organisiert ist. Bei funktionaler Organisation bietet sich eine Gliederung des Controllings als Institution an, die IT-Controlling explizit vorsieht (z. B. neben Beschaffungscontrolling). Bei divisionaler Organisation ist eine Controlling-Instanz für jede Division mit entsprechender Gliederung zweckmäßig. In beiden Fällen ist eine zentrale Instanz zur unternehmensweiten Koordination des Controllings – so auch des IT-Controllings – erforderlich. Im Zusammenhang mit der organisatorischen Gestaltung des Controllings ist zu entscheiden, wem die dezentralen Controller fachlich und disziplinarisch unterstellt werden, dem zentralen Controller oder den funktionalen Bereichsleitern bzw. den Eignern der Geschäftsprozesse. Fachliche und disziplinarische Unterstellung der dezentralen Controller unter den zentralen Controller stärkt deren Unabhängigkeit gegenüber dem Fachbereich, erschwert aber ihre Integration in den Fachbereich, et vice versa. Deshalb wird Mehrfachunterstellung empfohlen, wobei bei funktionaler Organisation die fachliche Unterstellung unter den zentralen Controller und die disziplinarische Unterstellung unter den Bereichsleiter bzw. bei divisionaler Organisation die fachliche Unterstellung unter den Bereichsleiter und die disziplinarische Unterstellung unter den zentralen Controller erfahrungsgemäß vorteilhaft ist. In kleinen Unternehmen ohne Controller und ohne CIO (vgl. Lerneinheit STELL) werden Controlling-Aufgaben des IT-Bereichs meist dem Leiter der IT-Abteilung (wenn vorhanden) zugeordnet. Ist eine IT-Abteilung nicht vorhanden, übernimmt ein Mitglied der Geschäftsführung das IT-Controlling wie das gesamte Unternehmenscontrolling. In mittleren Unternehmen, die über einen Controller verfügen, wird diesem auch das IT-Controlling zugeordnet; einzelne Controlling-Aufgaben (z. B. Projektplanung) übernimmt der Leiter der ITAbteilung. Nur für große Unternehmen wird ein IT-Controller vorgeschlagen, der nach Horváth fachlich dem Unternehmenscontroller und disziplinarisch dem CIO unterstellt sein sollte. Projektspezifische Controlling-Aufgaben werden, soweit sie nicht strategischer Art sind, der Projektleitung zugeordnet.

Projektcontrolling und Projektplanung Voraussetzung für ein wirkungsvolles Projektcontrolling ist eine Projektplanung, die für alle erfolgsrelevanten Projektmerkmale die Planungsdaten (Sollwerte) liefert, mit denen die Projektabwicklung überwacht und gesteuert wird. Zu entscheiden, welche Projektmerkmale als Planungsdaten mit welchen Sollwerten verwendet werden, ist Aufgabe des Metaprojektmanagements, ein dem Management eines einzelnen Projekts (Einzel- oder Teilprojektmanagement) übergeordnetes Projektmanagement. Es gibt den Rahmen vor, in dem Projekte geplant und abgewickelt werden. Teilaufgaben des Metaprojektmanagements sind:

Controlling (CONTR)

      

207

Festlegen bzw. Genehmigen der Planungsziele, Freigeben von Projekten bzw. Erteilen von Projektaufträgen, Zuweisen von Ressourcen an Projekte (z. B. Personal, Budget, Betriebsmittel), Festlegen der Form der Projektorganisation (vgl. Lerneinheit STRUK). Ernennen der Projektleitung und Regeln der Vorgesetztenfunktion, Entscheiden über Prioritäten zwischen mehreren offenen Projekten und Fällen von strategischen Projektentscheidungen (z. B. Projektabbruch).

Metaprojektmanagement sollte vom Lenkungsausschuss (vgl. Lerneinheit STRUK) – und damit vom Linienmanagement und IT-Management gemeinsam – wahrgenommen werden. Über die strategische Maßnahmenplanung (vgl. Lerneinheit SPLAN) sind die Projektmerkmale mit der IT-Strategie (vgl. Lerneinheit STRAT) so abgestimmt, dass sie die Erreichung der strategischen IT-Ziele (vgl. Lerneinheit SZIEL) unterstützen. Die Projektmerkmale sind mit den Kennzahlen des verwendeten Kennzahlensystems (z. B. BSC, vgl. Lerneinheit KENNZ) so abzustimmen, dass Sollwerte des Kennzahlensystems die Projektplanung unterstützen und Istwerte der Projektabwicklung Daten für das Kennzahlensystem liefern.

Controlling-Instrumente Damit sind systematische Vorgehensweisen, Methoden, Techniken usw. sowie Werkzeuge (meist Softwarewerkzeuge) gemeint, mit denen die Erfüllung von Controlling-Aufgaben unterstützt, im Grenzfall erst ermöglicht wird. Neben Kosten- und Leistungsrechnung (vgl. Lerneinheit KOLER) und Kennzahlensystemen (vgl. Lerneinheit KENNZ) gehören dazu: Competitive Benchmarking, Chancen-Risiken-Analyse, Lückenanalyse, Portfolioanalyse, Potenzialanalyse, Produktlebenszyklusanalyse, Stärken-Schwächen-Analyse, Szenariotechnik und Wettbewerbsanalyse. Mehrere dieser strategischen Controlling-Instrumente werden in verschiedenen Lerneinheiten erklärt (z. B. Wettbewerbsanalyse in Lerneinheit SITAN, Portfolioanalyse in Lerneinheit SPLAN) sowie Stärken-Schwächen-Analyse und ChancenRisiken-Analyse, zusammen als SWOT-Analyse bezeichnet (SWOT = Strengths, Weaknesses, Opportunities, Threats). Mit der SWOT-Analyse wird der Prozess der Strategiefindung unterstützt (vgl. Lerneinheit STRAT). Produktlebenszyklusanalyse und Competitive Benchmarking werden in Lerneinheit LEMAN bzw. MEGPM erklärt. Die Unterscheidung zwischen den Eigenschaften strategisch und operativ von ControllingInstrumenten orientiert sich an den für das Controlling verwendeten Eigenschaften der Controlling-Objekte, insbesondere daran, ob sie mit quantitativen Größen (z. B. Kosten und Leistungen) oder eher mit qualitativen Größen (z. B. Stärken und Schwächen) erfasst und abgebildet werden. IT-spezifische Controlling-Instrumente haben sich bisher nicht durchsetzen können (z. B. die von Hartwig und Heinrich entwickelte Portfolioanalyse für das Controlling der strategischen Maßnahmenplanung) bzw. sind solche Instrumente nicht entwickelt worden. Dedizierte Instrumente für das IT-Controlling gibt es bislang nicht, hieß es im Call for Papers für das Schwerpunktheft 3/2009 der WIRTSCHAFTSINFORMATIK „ITControlling und IT-Produktivität“ (vgl. den Abschnitt Forschungsbefunde; die IT-spezifische Portfolioanalyse sowie die Szenariotechnik werden in den Lerneinheiten PORTA bzw. SZENA der 8. Auflage dieses Lehr- und Handbuchs erklärt.)

208

Strategische Aufgaben des Informationsmanagements

Controlling und Revision Zwischen Controlling und Revision (vgl. Lerneinheit REVIS) bestehen wesentliche Unterschiede, aber auch Gemeinsamkeiten. Primäre Aufgabe des Controllings ist die Sicherung der Inputrationalität von Managemententscheidungen (Transparenzverantwortung), Zweck der Revision ist es, Fehler aufzudecken und damit das Entstehen von Fehlern in Zukunft vermeiden zu helfen. Sie untersucht realisierte Handlungen, Ergebnisse und Verfahren, führt also primär Ex-post-Beurteilungen (Prüfungen) durch. Die Prüfungen bestehen im Wesentlichen aus einem Vergleich von Istzuständen mit Sollzuständen (wie Grundsätze, Richtlinien und Anweisungen). Primäre Aufgabe der Revision ist die Prüfung der Ordnungsmäßigkeit. In der Regel erbringt sie mit Prüfungen auch Beratungsleistungen und trägt damit zur Sicherung der Outputrationalität von Managemententscheidungen bei. Controlling und Revision sind damit Träger der Rationalitätssicherung. Zwischen Controlling und Revision gibt es daher inhaltliche Schnittstellen, die Potenzial zur Sicherung von Input- und Outputrationalität enthalten (z. B. als Projekt begleitende Revision, vgl. Lerneinheit REVIS). Dies gilt auch und in vielen Fällen insbesondere für die externe Revision (Wirtschaftsprüfung), weil Wirtschaftsprüfer ohne so genannte Betriebsblindheit prüfen und urteilen können. Hirsch et al. nennen aus Erfahrung und auf Grund konzeptioneller Überlegungen eine Reihe von allgemeinen Schnittstellen und von weiteren, bei der Rechnungslegung nach IFRS relevanten Schnittstellen. Alle bieten Potenzial zur Beseitigung von Rationalitätsdefiziten durch Zusammenarbeit zwischen Controlling und Wirtschaftsprüfung. Wirksamkeit und Wirtschaftlichkeit von Managemententscheidungen können damit verbessert werden. Die Zusammenarbeit drückt sich vor allem in der gegenseitigen Datenlieferung aus, womit auch Wirksamkeit und Wirtschaftlichkeit der Revision verbessert werden können.

Forschungsbefunde Im Call for Papers für Heft 3/2009 der WIRTSCHAFTSINFORMATIK mit dem Schwerpunktthema „IT-Controlling und IT-Produktivität“ wurde u. a. festgestellt, dass es trotz der Bedeutung des Themas für Theorie und Praxis der Wirtschaftsinformatik nur relativ wenige einschlägige wissenschaftliche Arbeiten gibt. Mit dem Schwerpunktheft sollte der „aktuelle Stand der akademischen Diskussion“ reflektiert und sollten Perspektiven für die wissenschaftliche Forschung aufgezeigt werden. Im Editorial zum Schwerpunktheft stellen Frank/Hofmann fest (234): „Es zielt darauf, einen Überblick über den Stand der Forschung in diesem Bereich zu geben.“ Mit einem historisch orientierten Beitrag zum IT-Controlling (ohne explizite Nennung einer Forschungsmethodik) und einem Artikel „State-of-the-Art“ werden Art und Ausmaß der offenen Forschungsfragen überzeugend demonstriert. Baumöl berichtet über „Stand und Herausforderungen“ des IT-Controllings und stellt als Fazit fest (ohne forschungsmethodische Präzisierung): „In der Praxis ist noch Nachholbedarf für eine solche integrierte IT-Controllingkonzeption zu verzeichnen, und auch die Forschung hat den entscheidenden Schritt noch nicht getan. So ist also eine gemeinsame Aufgabenstellung zu verzeichnen, die es anzugehen gilt.“ Gemeint ist eine aus der IT-Governance abgeleitete und in das Unternehmenscontrolling „eingebettete“ Konzeption, „die eine ganzheitliche und integrierte Steuerung der Informatik aus allen Sichten ermöglicht“ (654).

Controlling (CONTR)

209

Goeken/Patas berichten über ihr Projekt SemGoRiCo = Semantic Governance, Risk and Compliance, „einen integrierten Lösungsansatz“ von IT-Controlling und IT-Governance, mit dem die Ermittlung des Wertbeitrags der IT möglich sein soll. Die komplexe Struktur von CobiT wird als semantisches Netz abgebildet, so dass mit einer Suchanfrage alle Prozesse adhoc ermittelt werden können, die primär der Domäne Wertbeitrag zugeordnet sind. Son/Gladyszewski entwickelten, basierend auf der Controlling- und Entscheidungstheorie, ein 15 Elemente umfassendes Hypothesensystem zum Einfluss des IT-Controllings auf die IT-Performance und überprüften es empirisch (schriftliche Befragung, 58 verwertbare Antworten, Befragungszeitraum Sommer 2005). Die Ergebnisse konnten neun Hypothesen nicht falsifizieren. Fazit der Autoren ist (6): „Unsere Studie zeigt, dass IT-Controlling einen direkten Einfluss auf die Entscheidungs- und Koordinationsfähigkeit der IT-Organisation ausübt und indirekt die IT-Performance über die effektive Entscheidungsfindung und Koordination von Aktivitäten positiv beeinflusst.“ Als ein Indiz für die Wichtigkeit des ITControllings wird festgestellt (12), „dass 75 % der Unternehmen über einen oder mehrere ITController verfügen und diese mehrheitlich dem CIO oder der Geschäftsführung unterstehen. In 4 von 10 Unternehmen ist der CIO Mitglied der Geschäftsführung.“ Strecker stellt als Ergebnis einer Literaturanalyse fest (517), „dass die diskutierten ITPerformance-Management-Ansätze gegenwärtig von aktuellen Ansätzen des IT-Performance-Measurement und IT-Managements/IT-Controllings anhand spezifischer Ziele, Aufgaben und Instrumente nicht zu differenzieren sind.“ Hirsch et al. sind den drei Forschungsfragen (1) Relevanz der Schnittstellen für die Zusammenarbeit von Controllern und Wirtschaftsprüfern, (2) Ausgestaltung der Zusammenarbeit und (3) Erfolgsfaktoren für die Zusammenarbeit nachgegangen (schriftliche Befragung von 18 zufällig ausgewählten Wirtschaftsprüfern von drei der vier größten Wirtschaftsprüfungsgesellschaften in Deutschland, Befragungszeitraum Mai/Juni 2007). Ergebnisse sind u. a.: Jeder Schnittstelle wurde eine hohe bis fast sehr hohe Relevanz beigemessen. Die Zweckmäßigkeit gemeinsamer Arbeitskreise zur Institutionalisierung der Zusammenarbeit wurde überwiegend verneint; bevorzugt wird die direkte Kommunikation. Von der Zusammenarbeit profitieren derzeit überwiegend die Wirtschaftsprüfer.

Aus der Praxis Frank/Hofmann stellen fest (233), dass in den letzten Jahren die mit IT-Controlling assoziierten Aufgaben zunehmend an Bedeutung gewonnen haben und dass „die Praxis“ auf diese Entwicklung reagiert hat. „In den letzten Jahren ist eine Reihe entsprechender Ansätze entstanden, von denen einige eine beachtliche Verbreitung erreicht haben.“ Als Beispiele werden CobiT und ITIL genannt (vgl. Lerneinheiten GOVER und RECHT bzw. SEMAN), die als Leitlinien, Rahmenwerke, Best Practices oder Referenzmodelle bezeichnet werden. Brun berichtet über ein von der Plaut Business Consulting GmbH (www.plaut.de) entwickeltes so genanntes Referenzmodell für IT-Governance und IT-Controlling, dessen „pragmatische Ansätze“ sich in mehr als 20 Jahren Beratungspraxis bei Plaut entwickelt haben. Es besteht aus den Aufgabengebieten, Portfolio-Management (PFM), Projekt-Controlling (PRC), Produkt- und Infrastruktur-Controlling (PIC), Risiko-Management und Compliance

210

Strategische Aufgaben des Informationsmanagements

(RMC) sowie Balanced Scorecard (BSC). Die Aufgabengebiete des IT-Controlling im Lebenszyklus eines typischen IT-Vorhabens werden anhand einer Abbildung gezeigt. Die im Titel des Beitrags verwendete Formulierung „Planen – Messen – Steuern“ rückt das Messen als eine unabdingbare Voraussetzung für das Controlling in den Mittelpunkt des Interesses. Kütz nennt „typische fachliche Anforderungen“ an IT-Controller, die in Stellenbeschreibungen genannt werden. Abgesehen von der für das IT-Controlling selbstverständlichen „Fachkompetenz Controlling und IT“ enthalten diese Anforderungen nichts Spezifisches, sondern von jeder Führungskraft generell Erwartetes. Dies stützt die These, dass Aufgabenträgern des IT-Managements sowohl Führungs- als auch Transparenzverantwortung zugeordnet sind, die von Horváth behauptete Zuordnung dieser Rollen auf verschiedene Aufgabenträger also nicht grundsätzlich zutrifft. Methodenverweise Kennzahlensysteme (Lerneinheit KENNZ); Kosten- und Leistungsrechnung (Lerneinheit KOLER); ServiceebenenVereinbarungen (Lerneinheit SEVER); Wirtschaftlichkeitsanalyse (Lerneinheit KOLER). Kontrollfragen 1. Welche Überlegungen sind für das Festlegen von Controlling-Objekten relevant? 2. Aus welchen Elementen besteht das Aufgabensystem des Controllings? 3. Welche Arbeitsschritte kennzeichnen das Vorgehen beim Entwickeln von Messmethoden? 4. Welche Anforderungen an die Qualifikation von Controllern stellt die erfolgreiche Wahrnehmung der Innovationsaufgabe des Controllings und über welche Kompetenz müssen sie verfügen? 5. Wie ist der Stand der Forschung zum IT-Controlling zu beurteilen und welche Forschungsfragen oder Forschungsgegenstände sind beispielsweise zu beantworten bzw. zu bearbeiten? Quellen Baumöl, U.: IT-Controlling – Stand und Herausforderungen. In: CONTROLLING 12/2008, 649–654 Brun, R.: Planen – Messen – Steuern: Die Kernprozesse von IT-Governance und ITR-Controlling. In: IM Information Management & Consulting 2/2008, 60–68 Frank, U. / Hofmann, G. R.: IT-Controlling und IT-Produktivität. Editorial zu WIRTSCHAFTSINFORMATIK 3/2009, 233–234 Goeken, M. / Patas, J.: Wertbeitrag der IT als Gegenstand der IT-Governance und des IT-Controllings. In: CONTROLLING12/2009, 650–655 Hirsch, B. / Hammer, D. / Mäder, O. B. / Kauerhoff, M.: Wirtschaftsprüfung und Controlling – Ausgestaltung der institutionellen Zusammenarbeit. In: CONTROLLING 1/2009, 39–47 Horváth, P.: Controlling. 11. A., München 2009 Kütz, M.: IT-Controlling für die Praxis. Konzeption und Methoden. Heidelberg 2005 Seibt, D.: Informationsmanagement und Controlling. In: WIRTSCHAFTSINFORMATIK 2/1990, 116–126 Son, S. / Gladyszewski, Th.: Return on IT-Controlling 2005 – eine empirische Untersuchung zum Einfluss des ITControllings auf die unternehmensweite IT Performance. Arbeitsbericht, E-Finance Lab Frankfurt a. M., Kontakt: [email protected] Strecker, St.: IT-Performance-Management – Zum gegenwärtigen Stand der Diskussion, In: CONTROLLING 10/2008, 513–518 von Dobschütz, L.: IV-Controlling. Theoretische Sicht und praktische Bedeutung. In: CONTROLLING 5/1995, 306–312 Vertiefungsliteratur Gadatsch, A. / Mayer, E.: Masterkurs IT-Controlling. Wiesbaden 2005 Jaspersen, T.: IT-Controlling für Mittel- und Kleinbetriebe. Berlin 2005 Kargl, H. / Kütz, M.: IV-Controlling. 5. A., München 2007 Reichmann, T.: Controlling mit Kennzahlen und Management-Tools. 7. A., München 2006 von Dobschütz, L. et al.: (Hrsg.): IV-Controlling. Wiesbaden 2000 Wall, F.: Informationsmanagement – Eine ökonomische Integration von Controlling und Wirtschaftsinformatik. München 2006

Revision (REVIS) Lernziele Sie können den Zweck der IT-Revision – in Praxis und Fachliteratur auch als DV- oder IVRevision bezeichnet – erläutern und kennen die Vorgehensweise der Revision. Sie kennen Grundsätze der Ordnungsmäßigkeit sowie der ordnungsmäßigen Datenverarbeitung und ihre Bedeutung für die Erreichung des Revisionszwecks. Sie erkennen die Bedeutung der Dokumentation für die Revision. Sie kennen Methoden, Techniken und Werkzeuge der ITRevision sowie die Besonderheiten der Projekt begleitenden Revision.

Definitionen und Abkürzungen AICPA = American Institute of Certified Public Accountants. CA = Continuous Auditing. CICA = Canadian Institute of Chartered Accountants. EAM = Embedded Audit Module. Ereignis (event) = Geschehnis, Vorkommen oder Begebenheit, das bzw. die zeitpunktbezogen und daher nicht Zeit verbrauchend sind. Ereignisaufzeichnung (event logging) = Erfassung sämtlicher oder besonders definierter Ereignisse während eines Verarbeitungsvorgangs auf einer Log-Datei unter der Steuerung des Abrechnungssystems. FAIT = Fachausschuss IT im IDW (ehemals FAMA). FAMA = Fachausschuss für Moderne Abrechnungssysteme im IDW, heute FAIT. FAMA-Gutachten (FAMA expertise) = Grundsätze für die Prüfung von IT-Systemen. GoBS = Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme. Grundsatz (principle) = Richtlinie für das Handeln oder Verhalten. Synonym: Prinzip. HFA = Hauptfachausschuss des IDW. IDW = Institut der Wirtschaftsprüfer in Deutschland e. V. (Düsseldorf). DIIR = Deutsches Institut für Interne Revision e. V. (Frankfurt a. M.). IKS = Internes Kontrollsystem. Kontrollierbarkeit (checkability) = Möglichkeit der Beobachtung des Verhaltens eines Objekts und seiner Beurteilung anhand von Verhaltenserwartungen. Kurzprüfung (rapid audit) = mit einem Arbeitsaufwand von zwei bis drei Mitarbeitertagen einschließlich Auswertung und Dokumentation durchgeführte Prüfung. Ordnungsmäßigkeit (regularity) = zusammenfassende Bezeichnung für Vollständigkeit, Richtigkeit, Zeitgerechtigkeit und Sicherheit einschließlich der Prüfbarkeit dieser Anforderungen durch einen sachkundigen Dritten (Prüfer, Revisor) in angemessener Zeit. Prüfliste (checklist) = Methode zum Überprüfen von Systemeigenschaften mit dem Zweck, Systemmängel aufzudecken. Synonyme: Prüfungsfragebogen, Checkliste. Prüfung (audit) = auf die Vergangenheit gerichtete Untersuchung von Vorgängen und Ereignissen durch prozessunabhängige Personen. Verfahrensdokumentation (procedure documentation) = eine aus System-, Programm- und Benutzerdokumentation bestehende Dokumentation.

212

Strategische Aufgaben des Informationsmanagements

Zweck der Revision Die Revision ist Teilgebiet des betriebswirtschaftlichen Faches Revisions- und Treuhandwesen (häufig kurz als Prüfungswesen bezeichnet). Charakteristisch für die Prüfung ist die Gewinnung eines vertrauenswürdigen Urteils über betriebswirtschaftliche Sachverhalte. Kernstück hierbei ist der Soll/Ist-Vergleich des Prüfungsobjekts (z. B. anhand von Grundsätzen oder Normen) mit anschließender Urteilsbildung. Diese enthält zumindest implizit, kann aber auch explizit Anleitungen darüber enthalten, mit welchen Maßnahmen ein anzustrebender Sollzustand erreicht werden kann. Somit hat Revision nicht nur eine Korrekturfunktion (Fehlerbeseitigung), sondern auch eine Präventivfunktion (Fehlervermeidung). Prüfung wird als Vorgang verstanden, der nicht fest in die betrieblichen Prozesse eingebunden ist, während Kontrolle ständige und prozessgebundene Überwachungsvorgänge meint. Aus Sicht der Unternehmensführung sind Überwachungsaufgaben (d. h. Prüfungs- und Kontrollaufgaben) – neben Planungs- und Realisierungshandlungen – betriebliche Funktionen. Zweck der IT-Revision ist es, die Einhaltung anwendungsspezifischer unternehmensexterner (z. B. gesetzlicher, vgl. Lerneinheiten GOVER und RECHT) und unternehmensinterner Regeln der IT (z. B. Handlungen, die ein Vorgehensmodell vorschreibt, vgl. Lerneinheit VOMOD) sowie Wirtschaftlichkeit, Schutz und Sicherheit der informationstechnischen Realisierung und Abwicklung von Aufgaben des Finanz- und Rechnungswesens zu prüfen, einschließlich der diesen vorgelagerten Anwendungen (z. B. Bestellwesen, Bestandsführung, Auftragsabwicklung). Die Notwendigkeit der Prüfung ergibt sich aus der handelsrechtlichen Prüfungspflicht (z. B. HGB = Handelsgesetzbuch), steuerrechtlichen Bestimmungen (z. B. AO = Abgabenordnung), weiteren nationalen (z. B. BDSG, KonTraG) und internationalen Normen sowie den Gutachten und Stellungnahmen von Kammern und Vereinigungen (z. B. FAMA- bzw. FAIT-Gutachten). Zur Erfüllung ihres Zwecks braucht die Revision Grundsätze, Methoden und Werkzeuge; von zentraler Bedeutung sind die aus Gesetzen und Rechtsprechung abgeleiteten Grundsätze der Ordnungsmäßigkeit, insbesondere die Grundsätze ordnungsmäßiger Datenverarbeitung. Typische Merkmale der IT-Revision sind:     

Es werden wiederkehrende oder einmalig auftretende Objekte des IT-Bereichs geprüft. Die Objekte sind Vorgänge, also Arbeitsabläufe (z. B. Abwicklung eines Auftrags), Ereignisse (z. B. Auslösen von Buchungen) und Prozesse (z. B. Eingabe, Verarbeitung und Ausgabe von Daten). Die Prüfung erfolgt durch natürliche, prozessunabhängige Personen (Prüfer). Die Prüfung erfolgt methodengeleitet (z. B. durch Prüflisten) und werkzeugunterstützt (Prüfsoftware, Audit Informationssysteme). Die Prüfung ist auf die Vergangenheit gerichtet, also rückschauend, und wird in mehr oder weniger regelmäßigen Abständen durchgeführt (vgl. jedoch den Abschnitt Projekt begleitende Revision).

Zu den Prüfungsobjekten gehört auch das Umfeld der IT-Anwendungen wie IT-Strategie, ITÜberwachungssystem, IT-Outsourcing und Internetnutzung. Die Ergebnisse der IT-Revision werden dem Jahresabschlussbericht der Wirtschaftsprüfer in einem „Vermerk" hinzugefügt, der neben der Beurteilung der identifizierten Mängel (Schwachstellen und Risiken) Handlungsempfehlungen enthält, wie die Mängel behoben werden können. Eine Wertigkeit

Revision (REVIS)

213

der Schwachstellen und Risiken im Sinne ihrer Bedeutung für den Unternehmenserfolg wird angegeben. Ein Gütesiegel für eine „revisionsfreundliche IT“ gibt es nicht.

Vorgehensweise der Revision Diese kann aus strukturorganisatorischer Sicht, aus Sicht der Prüfungsobjekte, aus Sicht der Methodik und aus Sicht des Nachweises der korrekten Verarbeitung betrachtet werden. Jeder Ansatz führt zu aussagefähigen Beurteilungen; eine Festlegung auf einen bestimmten Ansatz würde den Handlungsspielraum des Prüfers unnötig einengen. 







Aus strukturorganisatorischer Sicht wird zwischen interner und externer Revision unterschieden. Interne Revision ist eine der Unternehmensleitung unterstellte Funktion, in großen Unternehmen als Struktureinheit institutionalisiert. Externe Revision wird von Prüfern durchgeführt, die im Auftrag anderer Unternehmen (z. B. Wirtschaftsprüfungsgesellschaften, Rechnungshöfe) handeln. Aus Sicht der Prüfungsmethodik, auch als Prüfungstechniken bezeichnet, wird zwischen „Prüfung um das IT-System herum“ (das IT-System wird als Schwarzer Kasten betrachtet, nur Eingaben und Ausgaben werden geprüft) und „Prüfung durch das IT-System hindurch“ (Prüfung der Funktionsweise und Nachvollzug der Verarbeitungsvorgänge) unterschieden. Sind Verarbeitungsregeln die Prüfungsobjekte, handelt es sich um eine regelorientierte Prüfung, sind Datenbasen die Prüfungsobjekte, handelt es sich um eine datenorientierte Prüfung. Aus Sicht des Nachweises der korrekten Verarbeitung wird zwischen Einzelfallprüfung und Systemprüfung unterschieden. Einzelfallprüfung beschränkt sich auf den Nachweis der korrekten Verarbeitung einzelner Geschäftsvorfälle. Systemprüfung ist eine Verfahrensprüfung, bei der die Korrektheit eines IT-Systems, bei einer unternehmensweiten Prüfung die Korrektheit des gesamten IT-Bereichs geprüft wird. Aus Sicht der Prüfungsobjekte wird zwischen den Anwendungen des Finanz- und Rechnungswesens (z. B. Buchführung, Kosten- und Leistungsrechnung) einschließlich der diesen vorgelagerten Anwendungssysteme und den betrieblichen Formalzielen (z. B. Wirtschaftlichkeit, Sicherheit) unterschieden. Eine Zerlegung der Prüfungsobjekte führt zu einer Gliederung in Hardware, Software, Systembetrieb und Systemumgebung (organisatorische, personelle und bauliche Gegebenheiten).

Im Mittelpunkt der IT-Revision stehen die Prüfungsobjekte IT-Systeme (in der Regel Anwendungssysteme) und IT-Organisation. Bei der Prüfung der IT-Systeme sind das Belegwesen, der Datenfluss, die Verarbeitungsregeln, die Aufzeichnung der Verarbeitungsvorgänge und die Dokumentation (z. B. die Verfahrensdokumentation) Prüfungsobjekte. Prüfungspflichtig sind alle IT-Systeme, die direkt oder indirekt Daten für die Rechnungslegung bereitstellen. Die Prüfung der IT-Organisation erfolgt an den Prüfungsobjekten Aufbau- und Ablauforganisation, Systementwicklung, Systembetrieb und Systemumgebung. Vom AICPA und vom CICA wurde die als Continuous Auditing (CA) bezeichnete Vorgehensweise der IT-Revision entwickelt, die so erklärt wird (zitiert nach Groomer 55): „...a methodology that enables independent auditors to provide written assurance on a subject matter using a series of auditors reports issued simultaneously with, or a short period of time after, the occurrence of events underlying the subject matter...“. Die für die Rechnungsle-

214

Strategische Aufgaben des Informationsmanagements

gung relevanten Daten werden nicht nur zu einem Zeitpunkt im Jahr geprüft, sondern mittels anhaltender Tests und Kontrollen kontinuierlich oder zumindest zeitnah überwacht. Damit soll der Anforderung nach aktuellen und über das ganze Jahr verlässlichen Daten entsprochen werden. Kogan et al. bezeichnen CA wegen dieser Eigenschaft als „instant auditing“ (zitiert nach Groß/Vogl). CA wird als eine Art Monitor verstanden, der Daten der Finanzbuchhaltung nach festgelegten Kriterien durchleuchtet, mit kritischen Größen abgleicht und bei Eintreten vordefinierter Ereignisse den Prüfer informiert. CA stellt spezifische technische und organisatorische Anforderungen; Investitionen in Hardund Software sind erforderlich (CA-System). Das CA-System muss so in die bestehende IT integriert werden, dass die Abwicklung der Geschäftsprozesse nicht negativ beeinflusst wird. Zur Wahrung der Unabhängigkeit der Prüfung wird ein System gefordert, das ausschließlich dem Prüfer zur Verfügung steht und dem zu prüfenden IT-Bereich keine Möglichkeit gibt, darauf zuzugreifen bzw. es zu modifizieren oder sogar zu manipulieren.

Prüfungsarten Die Prüfung von IT-Systemen umfasst auch ihr organisatorisches Umfeld (z. B. die Datenerfassung auf Belegen); dies wird als Systemprüfung bezeichnet. Prüfungsobjekt ist die Gesamtheit der regelnden Anweisungen, die einen gewollten IT-Prozess beschreiben. Soweit dieser Prozess computerunterstützt ist, sich also in Software niederschlägt, gehören alle in dieser Software abgebildeten Regeln zum Prüfungsobjekt einer regelorientierten Prüfung. Im Unterschied dazu setzt die datenorientierte Prüfung an den Datenbasen als Prüfungsobjekte an, die von den Anwendungsprogrammen benutzt (gelesen und/oder verändert) werden. Da zwischen diesen Programmen und den Datenbasen ein bestimmter funktionaler Zusammenhang besteht, kann auch anhand der Daten geprüft werden, ob die in jeder Datenbasis enthaltenen Daten den Verarbeitungsregeln entsprechen. Die Prüfung konzentriert sich auf die Suche nach der Ausnahme von der gewollten Verarbeitungsregel. Es wird eine Fehlerbedingung definiert, und es werden die Daten gesucht, die dieser Fehlerbedingung genügen. Anhand der Prüfung auf sachlogische Zusammenhänge kann auch die Wirksamkeit der administrativen Maßnahmen zur Gewährleistung der Datenintegrität geprüft werden. Damit werden Informationen zur Qualität der verwendeten Verarbeitungsregeln gewonnen. Dies gilt auch für die Prüfung der Daten, die vom Abrechnungssystem (vgl. Lerneinheit KOLER) oder auf einer Log-Datei dokumentiert werden (Ereignisaufzeichnung), und zwar im Hinblick auf die durchgeführten Korrekturen oder Wiederholläufe bei einem abnormalen Ende einer Verarbeitung (Systemzusammenbruch oder Programmabbruch). Ansatzpunkte für eine datenorientierte Prüfung sind gegeben, wenn sich das Prüfungsinteresse auf eine bestimmte Datenbasis richtet. Beispiele für derartige Prüfungen sind:   

Prüfung auf Einhaltung der Ausweis-, der Nachweis- und (eingeschränkt) der Bewertungsregeln für den Jahresabschluss, Durchführung und Prüfung von Stichprobeninventuren und Durchführung betriebswirtschaftlicher Analysen und Ordnungsmäßigkeitsprüfungen.

Die GoBS fordern auch, so wie gesetzliche Normen (z. B. Aktiengesetz, GmbH-Gesetz), ein Internes Kontrollsystem (IKS), das alle aufeinander abgestimmten und miteinander ver-

Revision (REVIS)

215

bundenen Kontrollen, Maßnahmen und Regelungen umfasst. Es soll Ordnungsmäßigkeit, Sicherheit und Wirtschaftlichkeit gewährleisten (vgl. Lerneinheit GOVER). Im Rahmen der Prüfung des IKS muss der Prüfer die vorgesehenen Kontrollaktivitäten auf ihre Eignung beurteilen, wesentliche Fehler in der Rechnungslegung verhindern bzw. aufdecken und korrigieren zu können, also festzustellen, ob seine Funktionalität angemessen und dauerhaft ist. Soweit das IKS Maßnahmen zur Überwachung von Existenz gefährdenden Entwicklungen vorsieht, sind diese nach den Grundsätzen einer Systemprüfung stichprobenweise auf ihre Wirksamkeit hin zu untersuchen. Systemprüfungen müssen auch die Frage beantworten, ob das auf die Rechnungslegung bezogene IKS während des gesamten zu prüfenden Zeitraums bestanden hat und wirksam war. Da es sich dabei um einen kontinuierlichen Prozess handelt, ist auch eine kontinuierliche Prüfung erforderlich (z. B. nach dem CA-Ansatz). Sie scheitert meist am Fehlen geeigneter Werkzeuge; der Regelfall ist eine stichtagsbezogene Prüfung.

Initiierung von Revisionsaufträgen Die Forderung, Prüfungen unerwartet und sporadisch durchzuführen, heißt nicht, sie planlos durchzuführen. Gefordert wird ein in regelmäßigen zeitlichen Abständen (z. B. jährlich) erstellter Revisionsplan, der von der mit der IT-Revision beauftragten Institution (z. B. der Revisionsabteilung bei interner Revision) erarbeitet und dem Top-Management zur Genehmigung vorgelegt wird. Der Revisionsbedarf wird aus Sicht der Revision festgelegt, nicht aus Sicht der Prüfungsobjekte (d. h. nicht nach deren Revisionswünschen). Die Erteilung von Revisionsaufträgen erfolgt auf Grund des Revisionsplans. Mit Follow-ups wird festgestellt, ob Veränderungen an den Prüfungsobjekten entsprechend den von der Revision festgestellten Mängeln erfolgt sind. Der zeitliche Abstand zwischen der Prüfung und den Follow-ups wird in Abhängigkeit von der Art der Mängel festgelegt. Im Zusammenhang mit der periodischen Prüfung von Jahresabschlüssen, Bilanzen und anderen der Prüfung unterliegenden Ergebnisrechnungen werden IT-Revisionen auch von Wirtschaftsprüfern vorgenommen (Externe Revision). Bei der Begründung für diese Prüfung wird von der Tatsache ausgegangen, dass die Ordnungsmäßigkeit des Jahresabschlusses nur geprüft und beurteilt werden kann, wenn alle Informationssysteme (insbesondere alle Programme und Datenbasen) in die Prüfung einbezogen werden, welche Daten für den Jahresabschluss liefern. Die Prüfung erfolgt in der Regel als Kurzprüfung. Werden dabei Mängel erkannt, wird der Mandant zu einer Tiefenprüfung verpflichtet. Umfangreiche Prüfungen wie die Jahresabschlussprüfung erfolgen in der Regel durch ein Prüfungsteam, dessen Zusammensetzung und Größe den Anforderungen des Prüfungsauftrags entsprechen muss. Zur Stärkung der Unabhängigkeit sollte ein turnusmäßiger Prüferwechsel bzw. die Änderung der Zusammensetzung des Prüfungsteams eine Selbstverständlichkeit sein (Prüferrotation).

Grundsätze der Ordnungsmäßigkeit Für IT-Systeme des Finanz- und Rechnungswesens – insbesondere für Buchführungssysteme – gibt es Grundsätze, deren Einhaltung durch die Revision geprüft wird. Sie präzisieren von der einzelnen Anwendung unabhängige Ordnungsmäßigkeitskriterien im Sinne von Sollvorstellungen. Die Grundsätze sind nur dann erfüllt, wenn die Einhaltung dieser Kriterien während des gesamten Verarbeitungsprozesses gegeben ist. Grundsätze sind:

216





 

Strategische Aufgaben des Informationsmanagements

Grundsätze ordnungsmäßiger Buchführung (GoB) bzw. die diese spezifizierenden Grundsätze ordnungsmäßiger computergestützter Buchführungssysteme (GoBS) beinhalten die Regeln, nach denen IT-Systeme der Buchführung gestaltet, benutzt und gepflegt werden sollen. Grundsätze ordnungsmäßiger Speicherbuchführung (GoS) beinhalten die Regeln, nach denen IT-Systeme der Buchführung bei Verzicht auf eine Dokumentenausgabe (also bei Verwendung elektronischer Speicher zur Archivierung) gestaltet, benutzt und gepflegt werden sollen. Grundsätze ordnungsmäßiger Datenverarbeitung (GoDV), die aus den Grundsätzen ordnungsmäßiger Buchführung abgeleitet wurden, sollen die Einhaltung der GoB bzw. GoBS auch bei anderen Anwendungen sicherstellen. Grundsätze ordnungsmäßigen Datenschutzes (GoDS) beinhalten Regeln, nach denen personenbezogene Daten behandelt werden sollen.

IT-Systeme bilden Geschäftsprozesse ab; jede Aktion eines Geschäftsprozesses, die zu einer Änderung der Höhe oder Struktur des Unternehmensvermögens und/oder des Kapitals führt, ist im rechtlichen Sinn ein Geschäftsvorfall. Ein Geschäftsprozess ist daher für die Rechnungslegung dann relevant, wenn er mindestens einen so definierten Geschäftsvorfall enthält. Da Geschäftsvorfälle den Bestimmungen des Handels- und Steuerrechts unterliegen, sind die GoB bzw. GoBS auf alle rechnungslegungsrelevanten Geschäftsprozesse anzuwenden. Geschäftsprozesse sind daher auch dann zu prüfen, wenn sie zwar außerhalb der Finanzbuchhaltung liegen, aber buchführungsrelevante Daten erfassen, erzeugen, bearbeiten und/oder übermitteln. Der Anwendungsbereich der GoBS erstreckt sich nicht nur auf den Systembetrieb, sondern auf alle Verfahren der Konzeption, Entwicklung und Implementierung von IT-Systemen einschließlich Programmdokumentation.

Grundsätze ordnungsmäßiger Datenverarbeitung Die GoB direkt auf die Datenverarbeitung anzuwenden, ist wegen der unterschiedlichen Ordnungsproblematik der Finanzbuchhaltung einerseits und der Datenverarbeitung andererseits nicht möglich. Zum Verständnis der Ordnungsproblematik der Datenverarbeitung ist es zweckmäßig, sie in ihre ordnungsbedürftigen Erscheinungsformen zu gliedern, nämlich in das buchhalterische Verfahren sowie dessen Dokumentation, die Arbeitsabwicklung und die Funktionsfähigkeit. Daraus lassen sich zunächst Hauptgrundsätze ordnungsmäßiger Datenverarbeitung formulieren, die in ihrer Gesamtheit der Erfüllung der gesetzlichen Vorschriften dienen. Hauptgrundsätze ordnungsmäßiger Datenverarbeitung – aus denen Nebengrundsätze abgeleitet werden – sind:    

Grundsatz der Auftragsbindung, Grundsatz der Kontrollierbarkeit, Grundsatz der Transparenz und Grundsatz der Funktionssicherheit.

Der Grundsatz der Auftragsbindung besagt, dass die Datenverarbeitung dann Teil der Buchführung ist, wenn sie für Aufgaben der Buchführung eingesetzt wird; sie unterliegt dann den GoB. Die Auftragsbindung verbietet es dem IT-Bereich, mit den ihr anvertrauten Daten eigene Zwecke zu verfolgen oder Zwecke anderer Unternehmensbereiche, wenn diese mit

Revision (REVIS)

217

den für die Buchführung verantwortlichen Stellen nicht abgestimmt sind. Der Grundsatz der Auftragsbindung bildet also eine Klammer zwischen den GoB und den anderen GoDV. Aus dem Grundsatz der Auftragsbindung wird der „Grundsatz der Zulässigkeit“ (z. B. nach den Vorschriften des Datenschutzgesetzes, vgl. Lerneinheit RECHT) abgeleitet. Der Grundsatz der Kontrollierbarkeit besagt, dass eine durchgängige Kontrolle der Verarbeitungsvorgänge, von der Dateneingabe bis zur Datenausgabe, möglich sein muss. Die Kontrolle muss die vollständige, richtige und zeitgerechte Eingabe, Verarbeitung und Ausgabe der Daten gewährleisten, so dass nicht nur die Kontrolle vorgesehen, sondern ihre Durchführung auch sichergestellt sein muss. Daher ist ungeplanten Ereignissen (z. B. Programmabbruch, Programmeingriff während des Programmablaufs) besondere Aufmerksamkeit zu widmen. Aus diesem Hauptgrundsatz werden die „Grundsätze ordnungsmäßiger Arbeitsabwicklung“ sowie die „Grundsätze ordnungsmäßiger Dokumentation“ abgeleitet. Der Grundsatz der Transparenz besagt, dass die Datenverarbeitung durchschaubar sein muss. Jeder sachverständige Dritte muss ohne informationstechnische Kenntnisse und ohne fremde Hilfe in der Lage sein, in angemessener Zeit Folgendes zu erreichen:    

einen Überblick über ein IT-System gewinnen, Daten von der Eingabe bis zur Ausgabe verfolgen und vergleichen können, Funktionen und Abläufe nachvollziehen können und Beziehungen zwischen Teilen des IT-Systems erkennen können.

Der Grundsatz der Funktionssicherheit besagt, dass die IT-Systeme jederzeit betriebsbereit sein müssen und die Daten nach denselben, einmal festgelegten Regeln verarbeitet, vor missbräuchlicher Verwendung geschützt und vor Vernichtung bewahrt werden müssen. Dafür sind Sicherungsmaßnahmen erforderlich, deren Art und Umfang sich nach den bestehenden Risiken richtet und deren Anwendung überwacht werden muss (vgl. Lerneinheiten SIKON und SICHM). Aus diesem Hauptgrundsatz werden die „Grundsätze ordnungsmäßiger Funktionssicherung“ abgeleitet.

Dokumentation und Revision Die Hauptgrundsätze – insbesondere der Grundsatz der Kontrollierbarkeit und der Grundsatz der Transparenz – können nur mit Hilfe einer guten Dokumentation erfüllt werden. Daher werden aus den Hauptgrundsätzen Grundsätze ordnungsmäßiger Dokumentation abgeleitet. Kernproblem der Revision ist, dass sich ihre Aufgabenträger (interne Revisoren, Abschlussprüfer, Betriebsprüfer, Prüfer der Sozialversicherungsträger) in relativ kurzer Zeit (z. B. in zwei bis vier Wochen) in einen von anderen Personen (wie Organisatoren, ITArchitekten oder Systementwickler) geschaffenen, über Jahre gewachsenen IT-Bereich einarbeiten, ihn durchschauen und beurteilen müssen. Dafür sind sie auf eindeutige und vollständige schriftliche Unterlagen angewiesen, was die Bedeutung der Dokumentation für die Revision erklärt. Anforderungen an die Dokumentation sind Übersichtlichkeit, Durchsichtigkeit, Zeitgerechtigkeit und Vollständigkeit. 

Der Grundsatz der Übersichtlichkeit besagt, dass die Dokumente in einer Leitdokumentation systematisch geordnet sein sollen. Das bedeutet, dass Dokumente gleichen

218



 

Strategische Aufgaben des Informationsmanagements

oder ähnlichen Inhalts nur auf einer Hierarchiestufe eingeordnet werden. Querverweise sollen den Zusammenhang zwischen den Dokumenten aufzeigen. Der Grundsatz der Durchsichtigkeit spricht den Inhalt und die Gestaltung der Dokumente an. Der Inhalt soll systematisch gegliedert sein, und die Form der Beschreibung (z. B. verbal und grafisch) soll dem Inhalt in der Weise entsprechen, dass er von einem sachverständigen Dritten leicht erfasst werden kann. Der Grundsatz der Zeitgerechtigkeit besagt, dass Änderungen (z. B. an Programmen) unverzüglich dokumentiert werden müssen und nur auf Grund eines formellen Verfahrens freigegeben werden dürfen. Der Grundsatz der Vollständigkeit besagt, dass alle für die Beurteilung maßgeblichen Tatbestände Gegenstand der Dokumentation sein müssen.

Projekt begleitende Revision Eine Projekt begleitende Revision mit Beratung auf Grund der Prüfungsergebnisse kann helfen, Fehler und Fehlentwicklungen bei IT-Projekten frühzeitig zu erkennen, dadurch Fehlinvestitionen zu vermeiden, zumindest deren Ausmaß zu verringern, und die Prüfbarkeit der Projektergebnisse zu verbessern. Sie darf nicht als Hilfsmittel des Projektmanagements missbraucht, insbesondere nicht zur Durchführung von Projektaufgaben herangezogen werden, weil sie dann Unabhängigkeit und Kontrollwirksamkeit verlieren würde. Sie hat auch die Aufgabe, Projektanforderungen aus Revisionssicht zu definieren und deren Einhaltung zu prüfen. Typische Prüfkriterien sind Funktionsfähigkeit (im Sinne organisatorischer Zweckmäßigkeit), Ordnungsmäßigkeit, Sicherheit und Wirtschaftlichkeit. Voraussetzungen für diese Form der Revision sind:   

Qualifizierte Mitarbeiter müssen ausreichend zur Verfügung stehen, deren Anzahl von der Anzahl offener Projekte und vom Umfang dieser Projekte abhängt. Der Informationsfluss zwischen den Projektmitarbeitern und den Prüfern muss gesichert sein (z. B. durch laufende Einsicht in die aktuelle Projektdokumentation). Beide Interessensgruppen müssen von der Zweckmäßigkeit dieser Revisionsform überzeugt sein.

Werden mehrere Projekte parallel abgewickelt und verfügt die Revision nicht über eine ausreichende Anzahl qualifizierter Mitarbeiter, um alle Projekte begleiten zu können, muss eine Projektauswahl erfolgen. Diese kann durch Beantwortung folgender Fragen, bei deren Bejahung eine Projekt begleitende Revision erfolgen sollte, erleichtert werden:   

Rechtfertigen Projektumfang und geplante Projektkosten sowie der erwartete Projektnutzen diese Revisionsform? Gehören personenbezogene Daten oder andere sensible Daten, bei denen strenge Sicherheitsziele erreicht werden müssen, zum Projektumfang? Ist eine nachträgliche Prüfung aus Zeit- und Kostengründen mit besonderen Schwierigkeiten verbunden?

Grundsätzlich können mehrere Projekte von einem Prüfer betreut werden, da die Mitwirkung im Projekt nur sporadisch erforderlich ist. Die Prüfung kann (als Mindestumfang) an den Projektmeilensteinen ansetzen. Im Grenzfall bedeutet dies nur die Prüfung des Projekter-

Revision (REVIS)

219

folgs anhand der Projektziele und der Projektergebnisse. Eine Wiederholung der Prüfung (z. B. zwei bis sechs Monate nach Übergabe der Projektergebnisse an den Auftraggeber) ist zweckmäßig, weil dann Nutzungserfahrung vorliegt, deren Daten insbesondere zur Beurteilung der Wirtschaftlichkeit und zum Erkennen von Verbesserungspotenzial erforderlich sind. Wenn möglich, sollten auch die Ursachen für Abweichungen zwischen Projektzielen und Projektergebnissen erkundet werden. Berichtsinstanz der Projekt begleitenden Revision ist der Lenkungsausschuss (vgl. Lerneinheit STRUK), wenn nicht eingerichtet ist dies die Unternehmensführung. Projekt begleitende Revision wird vom IDW empfohlen, weil wegen des Umfangs und der Komplexität der IT-Systeme eine Prüfung im zeitlichen Rahmen der Jahresabschlussprüfung nicht mehr möglich ist (vgl. HFA: Stellungnahme 4/1997). Das Urteil des Prüfers soll bereits im Stadium der Planung, Entwicklung, Änderung und Erweiterung komplexer Systeme und nicht erst nach ihrer Einführung eingeholt werden. Die Tätigkeit des Prüfers beschränkt sich ausschließlich auf die von den Systementwicklern gestalteten Lösungen unter Ordnungsmäßigkeits- und Kontrollgesichtspunkten. Diese Rolle schließt nicht aus, dass der Prüfer während der Projekt begleitenden Prüfung Anregungen zur Beachtung von Ordnungsmäßigkeitsgesichtspunkten gibt oder zusätzliche Kontrollen anregt oder für notwendig erklärt. Der Prüfer ist eigenverantwortlich tätig und darf von der Projektleitung keine Weisungen entgegennehmen.

Prüfungsmethoden Weit verbreitet als Prüfungsmethode der Revision ist die Prüfliste. Mit gut aufgebauten Prüflisten können große Prüfungsbereiche relativ schnell und systematisch untersucht werden. Prüflisten führen mit Fragen (Prüffragen) an verschiedenen Stellen in den Prüfungsbereich hinein und liefern durch Antworten zu den Prüffragen Ansatzpunkte zu tiefer gehenden Folgefragen. Im Ergebnis liefern die Antworten eine Menge von Einzelaussagen, die vom Prüfer zu einem Gesamtbild zusammengefasst werden müssen. Prüflisten haben – insbesondere gegenüber einer intuitiven Prüfungsweise – folgende Vorteile:   

Sie befreien den Prüfer weitgehend davon, bei jeder Prüfung erneut überlegen zu müssen, welche Tatbestände des Istzustands für die Urteilsbildung von Bedeutung sind. Sie ermöglichen es dem Prüfer, die Erhebungsdaten schnell und systematisch zu ordnen. Bearbeitete Checklisten sind ein aussagefähiger Nachweis über die vorgenommenen Prüfungshandlungen; Prüfungslücken sind gut erkennbar.

Im Unterschied zu manuellen erlauben IT-gestützte dialogisierte Prüflisten, anhand bereits erfasster Basisdaten irrelevante Fragen von vornherein auszublenden. Checklisten bieten keine Gewähr für die Vollständigkeit einer Prüfung, da keine Checkliste erschöpfend sein kann. Es besteht daher die Gefahr, dass relevante Sachverhalte nicht erfasst werden. Von vorhandenen Checklisten ausgehend obliegt es dem Prüfer, Art und Umfang der Prüfungshandlungen festzulegen (Prüfprogramm). Nachteil der Prüflisten ist, dass sich der Prüfer auf die im Wesentlichen von anderen Personen abgefragten oder aus Dokumenten entnommenen Antworten verlässt, statt sich durch Eigenbeobachtung und durch weiter reichende Methoden (z. B. Competitive Benchmarking, vgl. Lerneinheit MEGPM) selbst ein Bild zu machen.

220

Strategische Aufgaben des Informationsmanagements

Werkzeuge Für kommerzielle Softwaresysteme (z. B. ERP-Systeme) gibt es als Audit Information System (AIS) oder ähnlich bezeichnete Werkzeuge (z. B. AIS in SAP R/3). Unterstützt wird der gesamte Prüfungsprozess, beginnend mit der Prüfungsplanung bis zum Prüfungsbericht. Beim Prüfungsbereich „Hauptbuch“ ermöglicht das AIS den ganzheitlichen Nachweis aller Geschäftsvorfälle und stellt – neben grundlegenden Daten zum Hauptbuch – Auswertungen zur Verfügung (z. B. Bilanz und GuV). Über standardisierte Schnittstellen können die Daten in verarbeitungstechnisch nachgelagerte IT-Systeme überführt werden (z. B. EXCEL). Vom Kanadischen Rechnungshof (CICA) und einem international besetzten Komitee wurde die Prüfsoftware IDEA entwickelt; sie ist heute in über 40 Ländern bei Revisoren, Wirtschaftsprüfern und Controllern im Einsatz. Stärken von IDEA liegen im Import, der Selektion und der Analyse großer Datenmengen. In IDEA hinterlegte Prüfungsalgorithmen stellen dem Prüfer Kennzahlen zur Verfügung (vgl. Lerneinheit KENNZ). Damit können kritische Prüffelder erkannt, eine Prüfstrategie entwickelt und diese in individuelle Prüfprogramme transformiert werden. IDEA ermöglicht damit die gezielte Vorverlagerung von Prüfungshandlungen, reduziert deren Anzahl während der Hauptprüfung, beschleunigt die Durchführung der Prüfung und verkürzt den Zeitraum zwischen Abschluss der Prüfungshandlungen und Vorliegen des Prüfungsergebnisses. IDEA überprüft die internen Verarbeitungsregeln, um eine Aussage über die ordnungsmäßige Verarbeitung der Daten und die Richtigkeit der Ergebnisse machen zu können. Ausnahmen von definierten Regeln sollen Echtzeitwarnungen auslösen, die auf potenzielle Problembereiche aufmerksam machen. Der Prüfer muss auch in die Lage versetzt werden, Ursachen von Anomalien zu erkennen und zu bewerten. Groomer/Murthy beschrieben schon 1989 ein als Embedded Audit Module (EAM) bezeichnetes Echtzeitsystem, das in ein im Unternehmen verwendetes Softwaresystem (z. B. ein ERP-System) eingebettet wird. Einbettung meint dabei, dass ein System (hier der EAM) Teilsystem eines anderen Systems (hier das ERP-System) wird. EAM führt simultan zu den IT-Prozessen Prüfungshandlungen aus und ermöglicht es dem Prüfer, proaktiv auf prüfungsrelevante Sachverhalte einzugehen. EAM überwacht ausgewählte Risikobereiche und dient dem Erkennen von Transaktionsfehlern und Kontrolllücken. Dies erfolgt durch Identifizieren und Erfassen von Soll/IstAbweichungen ausgewählter Transaktionen und deren Kommunikation an den Prüfer. Häufig kommen Trigger zum Einsatz, die automatisch aufgerufen werden, wenn für die Prüfung relevante Datenbankinhalte des ERP-Systems geändert werden. Die Ergebnisse werden in einem Protokoll festgehalten, das nur vom Prüfer eingesehen werden kann. Abweichungen lassen sich auch durch Alarmmeldungen zeitnah an den Prüfer kommunizieren. FAMA-PC ist ein vom IDW entwickeltes Windows-System zur Unterstützung der Systemprüfung. Implementiert ist der durch den FAMA entwickelte Fragebogen, der sich an den Anforderungen der Wirtschaftsprüfung orientiert und Fragen zur Ordnungsmäßigkeit in den Vordergrund stellt. Das Werkzeug unterstützt die Prüfung mit Checklisten, liefert eine grafische Übersicht über den Sicherheitsstandard des geprüften Systems und den Entwurf eines Abschlussberichts. Zur Erstellung eines Prüfprogramms kann FAMA-PC vom Prüfer konfi-

Revision (REVIS)

221

guriert werden (z. B. mit weiteren Fragen, Fragenkatalogen, Erläuterungen zu den Fragen und deren Gewichtung).

Forschungsbefunde Heinrich (528-530) beschreibt den Zweck von Checklisten, ihren formalen Aufbau und verschiedene Arten von Checklisten; damit wird eine Anleitung zur Entwicklung von Checklisten gegeben. Zusammenfassend wird festgestellt (528): „Eine Checkliste enthält Vorstellungen über die gewünschten Eigenschaften des Untersuchungsbereichs (d. h. über seinen Sollzustand). Die Vorstellungen über den Sollzustand stammen meist aus der Erfahrung der Personen, welche die Checkliste formuliert haben. Wegen nicht vorhandener theoretischer Grundlagen ist ihre theoriegeleitete Formulierung nur selten möglich.“ Marten/Quick/Ruhnke (655 ff.) beurteilen den Entwicklungsstand der Prüfungstheorie „eher ernüchternd“. Trotz zahlreicher empirischer Belege ließen sich Zusammenhänge, beispielsweise zwischen dem prüferischen Verhalten und der Erreichung der Prüfungsziele, nicht in einer Weise herstellen, die den Anforderungen einer Theorie entspricht (Ursache-WirkungsBeziehungen). Vielmehr unterliege die Normengebung in nicht wenigen Fällen dem faktischen Zwang zum Handeln (Ziel-Mittel-Beziehungen). Erfolgversprechend erscheint es, die Beiträge der verschiedenen prüfungstheoretischen Ansätze (z. B. messtheoretischer Ansatz, Informationsverarbeitungsansatz, Positive Accounting Theory) in die Herausbildung objektbezogener Bezugsrahmen einzubringen und systematisch in eine Gesamtsicht zu integrieren. Obgleich eine Prüfungslehre seit langem als wissenschaftliche Disziplin anerkannt sei, herrsche keine Einigkeit hinsichtlich des Begriffs und Gegenstands einer Prüfungstheorie.

Aus der Praxis Bei der praktischen Umsetzung der GoBS und deren Kontrolle durch die Revision im Rahmen von Jahresabschlussprüfungen hat sich gezeigt, dass insbesondere in den Bereichen der Erstellung und Pflege einer Verfahrensdokumentation (z. B. zur Beschreibung der Archivierungsprozesse bei elektronischer Archivierung) erheblicher Handlungsbedarf besteht. Geeignete Werkzeuge zur automatisierten Erstellung sind nur in Ansätzen vorhanden. In vielen Unternehmen sind zwar zahlreiche Kontrollen in den Geschäftsprozessen vorgesehen, über deren Konsistenz, Zuverlässigkeit und Lückenlosigkeit aber oft keine Aussagen gemacht werden können. Ursache dafür ist das Fehlen einer geschlossenen Konzeption zur optimalen Gestaltung und zur Prüfung von internen Kontrollsystemen (nach Philipp). Odenthal beschreibt in einem Revisionsleitfaden das Grundsätzliche der Vorgehensweise der IT-Revision sowie ihre Besonderheiten in einer SAP R/3-Umgebung und Client-ServerArchitektur. Es wird gezeigt, dass Ordnungsmäßigkeit, Schutz und Sicherheit in weitgehend offenen, modular aufgebauten und dezentral betriebenen Systemen schwieriger zu realisieren sind als in zentralisierten Systemen. Daraus folgt die Notwendigkeit zusätzlicher Kontrollen durch die Revision, die deshalb auf eine „revisionsfreundliche Gestaltung“ der IT Einfluss nehmen sollte. Dazu zählen folgende Maßnahmen: 

aktuelle Dokumentation der verwendeten Hardware sowie der zugelassenen und lizenzierten Software in Dateiform (Hardwareinventar bzw. Softwareinventar),

222

   

Strategische Aufgaben des Informationsmanagements

Protokollierung aller revisionsrelevanten Vorgänge und Ereignisse sowohl auf Betriebssystem- als auch auf Datenbankapplikationsebene mit Erläuterung zu Auswirkungen und Bedeutung einzelner Fehlerarten, nachweisbares Konzept für die Datensicherung der Server- und Arbeitsplatzrechner, eine abgesicherte Unterbringung der Server und abgestimmtes Konzept für die Zugriffsberechtigungen.

Methodenverweise Evaluierungsmethoden (Lerneinheit EVALU); Kennzahlensysteme (Lerneinheit KENNZ). Kontrollfragen 1. Welchen Zweck verfolgt die IT-Revision? 2. Welche Vorgehensweisen sind für die IT-Revision kennzeichnend? 3. Wodurch unterscheiden sich regelorientierte Prüfung und datenorientierte Prüfung? 4. Welche Bedeutung haben die Grundsätze der Ordnungsmäßigkeit für die IT-Revision? 5. Wie kann die Zweckmäßigkeit einer Projekt begleitenden Revision begründet werden? Quellen Groomer, S. M. / Murthy, U. S.: Continuous Auditing of Database Application – An Embedded Audit Module Approach. In: Journal of Information Systems 4/1989, 53–69 Groß, St. / Vogl, A.: Continuous Auditing – Ein Ansatz zur zeitnahen und kontinuierlichen Prüfung. http://www.elektronische-steuerpruefung.de/loesung/gross_vogl_1.htm; Abruf 29.3.2011 Heinrich, L. J.: Informationsmanagement – Planung, Überwachung und Steuerung der Informationsinfrastruktur. 7. A., München/Wien 2002, Lerneinheit CHECK – Checklisten, 527–542 IDEA: http://www.auditware.co.uk/downloads/180_V8-Highlights-A4-AUDITWARE.pdf; Abruf 11.5.2011 IDW (Hrsg.): Stellungnahme FAMA 1/1987: Grundsätze ordnungsmäßiger Buchführung bei computergestützten Verfahren und deren Prüfung. In: Die Wirtschaftsprüfung 1,2/1988, 1–35 Marten, K.-U. / Quick, R. / Ruhnke, K.: Lexikon der Wirtschaftsprüfung. Stuttgart 2006 Odenthal, R.: Sicherheit und Prüfung von Betriebssystem und Netzwerk in einer SAP R3-Umgebung. http://www.roger-odenthal.de/Mitgliederbereich/downloads/Netz_1.pdf; Abruf 6.3.2008 Philipp, M.: Ordnungsmäßige Informationssysteme im Zeitablauf. In: WIRTSCHAFTSINFORMATIK 4/1998, 312–317 Schuppenhauer, R.: Grundsätze für eine ordnungsmäßige Datenverarbeitung (GoDV). Düsseldorf 1998 Vertiefungsliteratur Amling, Th. / Bantleon, U.: Handbuch der Internen Revision – Grundlagen, Standards, Berufsstand. Berlin 2007 IDW (Hrsg.): Prüfung von IT-gestützten Geschäftsprozessen im Rahmen der Abschlussprüfung. In: IDW Fachnachrichten 1/2009, 39–49 (IDW PH 9.3302) IDW (Hrsg.): Projekt begleitende Prüfung von Informationstechnologie. In: IDW Fachnachrichten 10/2008, 427– 441 (IDW PS 850) Institut für Interne Revision Austria (Hrsg.): Das interne Kontrollsystem aus Sicht der Internen Revision. Wien 2004 Peemöller, C.-Ch. / Volker, H.: Corporate Governance und Interne Revision – Handbuch für die Neuausrichtung des Internal Auditings. Berlin 2007 Schranner, G. / Gläser, D.: Nutzen der IT-Revision. In: Deutsches Institut für Interne Revision (Hrsg): Interne Revision aktuell. Berlin 2008, 39–338 Informationsmaterial EDV-Audit Consult: Information zum AIS SAP R/3 http://www.edv-auditconsult.via.t-online.de/ IDW (Hrsg.): Grundsätze ordnungsmäßiger Durchführung von Abschlussprüfungen. In: Die Wirtschaftsprüfung 1+2/1989, 9–19 IDW (Hrsg.): FAMA-Checkliste „EDV-Systemprüfung“. In: Die Wirtschaftsprüfung 1,2/1988, 17–35 IDW (Hrsg.): FAMA-Fragebogen „DV-Systemprüfung“ – Anlage zur Stellungnahme FAMA 1/1987. In: FN-IDW 11/1993, 462 ff. IDW (Hrsg.): HFA-Stellungnahme 4/1997: Projektbegleitende Prüfung EDV-gestützter Systeme. In: Die Wirtschaftsprüfung 19/1997, 680–682 IT-Audit.de: Bücher und Webseiten zu IT-Revision: http://www.it-audit.de/html/ian_sch_ita_standard.html

Outsourcing (OUTSO) Lernziele Sie wissen, welche Ziele mit Outsourcing verfolgt werden. Sie kennen verschiedene Formen des Outsourcings und wissen, welche Aufgaben des IT-Bereichs in der Regel nicht ausgelagert oder ausgegliedert werden sollten. Sie können erklären, welche Voraussetzungen Outsourcing-Nehmer erfüllen müssen, um erfolgreiches Outsourcing betreiben zu können. Sie kennen ASP und SaaS als Spezialformen des Outsourcings.

Definitionen und Abkürzungen ASP = Application Service Provider oder Application Service Providing. Ausgliederung (outsourcing, spin-off) = Übertragung von Aufgaben an ein mit dem Outsourcing-Nehmer rechtlich verbundenes Unternehmen. Auslagerung (outsourcing) = Übertragung von Aufgaben an ein vom Outsourcing-Nehmer rechtlich unabhängiges Unternehmen. Backsourcing = Übertragung von vorher durch einen Outsourcing-Geber erbrachten Leistungen an einen internen Dienstleister (z. B. die interne IT-Abteilung). CIO = Chief Information Officer. Insourcing = Bezug von Leistungen von einem unternehmensinternen Anbieter, der sich in einem von Marktmechanismen geprägten Auswahlverfahren gegen externe Anbieter durchsetzen konnte. Outsourcing = Kontraktion der Wörter out[side] und [re]sourcing bzw. out[side] [re]sourc[e us]ing; Erfüllung von IT-Aufgaben durch Unternehmensexterne; zusammenfassende Bezeichnung für Auslagerung und Ausgliederung. Outsourcing-Geber (outsourcing provider) = Unternehmen, dem IT-Aufgaben übertragen werden. Synonyme: Outsourcing-Anbieter, Outsourcing-Dienstleister. Outsourcing-Grad (degree of outsourcing) = Maß für den Umfang des Outsourcings. Synonym: Outsourcing-Reichweite. Outsourcing-Nehmer (outsourcing client) = Unternehmen, das einem anderen Unternehmen IT-Aufgaben überträgt. Synonym: Outsourcing-Kunde. Outtasking = Auslagerung einzelner IT-Aufgaben. Synonym: Selektives Outsourcing. SaaS = Software-as-a-Service; Software als Dienstleistung. Software-on-Demand = Spezialform des Outsourcings, bei der ein Dienstleister Kunden die Nutzung von Software über ein Netzwerk gegen Entgelt ermöglicht. Synonyme: ASP, Software-Miete, Software-Outsourcing. SLA = Service Level Agreement; Serviceebenen-Vereinbarung. Sourcing = Beschaffung von Produkten oder Dienstleistungen von unternehmensinternen oder -externen Anbietern. Transaktionskosten (transaction costs) = Informations- und Kommunikationskosten für Anbahnung, Vereinbarung, Abwicklung, Steuerung, Kontrolle und Anpassung der Leistungserstellung.

224

Strategische Aufgaben des Informationsmanagements

Zweck des Outsourcings 1962 wurde das Unternehmen Electronic Data Systems Corporation (EDS) mit dem Geschäftszweck gegründet, IT-Ressourcen für andere Unternehmen zur Verfügung zu stellen. 1984 übernahm General Motors EDS und gliederte die eigene IT in das Tochterunternehmen aus. 1989 lagerte Eastman Kodak Personal und Sachressourcen sowie den Betrieb von vier Rechenzentren an IBM, der Telekommunikationsnetze an Digital Equipment Corporation (DEC) und der PC an Businessland aus. General Motors und Eastman Kodak wurden dadurch zu Vorreitern für andere Unternehmen, die ihre IT vollständig oder teilweise ausgliederten oder auslagerten. Im deutschsprachigen Bereich ist die Übertragung der IT an externe Dienstleister seit den 1960er Jahren als Datenverarbeitung außer Haus (Heinrich) und später als Outsourcing bekannt. Durch den technischen Fortschritt, insbesondere die Verbreitung des Internets, sind heute verschiedene Formen der Übertragung von ITAufgaben an Externe möglich, wie z. B. im Rahmen von ASP oder Cloud Computing (vgl. Lerneinheit INMAN). Outsourcing ist eine Form des Übergangs von der Eigen- zur Fremderstellung von ITLeistungen und damit einer geringeren Fertigungstiefe. Ähnlich wie in anderen betrieblichen Aufgabenbereichen werden damit verschiedene Zwecke verfolgt. Diese lassen sich in wirtschaftliche, strategische, ressourcenorientierte und organisatorische Zwecke gliedern.

Wirtschaftlichkeit Erwartete Kostensenkungen und damit Verbesserung der Wirtschaftlichkeit (vgl. Lerneinheit WIRTA) sind in den meisten Unternehmen das entscheidende Argument für Outsourcing. Dabei spielt die Reduzierung von Personalkosten die größte Rolle, die insbesondere bei Outsourcing von Leistungen in Niedriglohnländer erwartet wird. Eine Flexibilisierung der Entgeltpolitik ist in Unternehmen, in denen die Auslastung der IT stark schwankt, ebenfalls ein wichtiges Argument. Daneben versprechen Outsourcing-Geber Kostensenkungen durch Skaleneffekte und Spezialisierungsvorteile. Dienstleister, die Ressourcen nicht nur für ein, sondern für mehrere Unternehmen bereitstellen und IT-Aufgaben für Kunden übernehmen, sichern zu, effizienter zu arbeiten als interne Dienstleister, die nicht über entsprechend breite Erfahrungen verfügen. Unternehmen, die nicht nur IT-Aufgaben, sondern auch Ressourcen, wie Gebäude oder Hardware, auf den Outsourcing-Dienstleister übertragen, können dadurch ihre Liquidität verbessern. In Phasen, in denen neuartige Aufgaben gleichzeitig zu bewältigen sind, kann Outsourcing dazu beitragen, den Eigenanteil an Investitionen gering zu halten. Dies ist z. B. vor der Jahrtausendwende der Fall gewesen, als interne IT-Bereiche neben den Routineaufgaben die Euro-Einführung, die Softwaresanierung aufgrund des Jahr-2000Problems sowie den Auf- und Ausbau von Webpräsenzen bewältigen mussten.

Strategie Unternehmen, deren Geschäftszweck nicht in der Informationsverarbeitung liegt, können durch Outsourcing Ressourcen für die Hauptaufgaben freisetzen und sich auf ihre Kernkompetenzen konzentrieren. Andere Unternehmen, deren Aufgaben im Wesentlichen durch Informationsverarbeitung geprägt sind (z. B. in den Branchen Finanzdienstleistungen, Medien oder Telekommunikation), wählen Outsourcing, um sich durch die Kooperation mit auf

Outsourcing (OUTSO)

225

IT spezialisierten Dienstleistern Wachstumspotenzial zu erschließen. Einige Unternehmen gliedern den IT-Bereich aus, damit dieser nicht nur innerhalb des ausgliedernden Unternehmens Leistungen erbringt, sondern diese auch für andere Unternehmen anbietet. Dazu ist ein Wandel des IT-Bereichs vom internen Funktionsträger zum wettbewerbsorientierten Anbieter notwendig; ein Wandel, der IT-Bereichen schwer zu fallen scheint (vgl. hierzu den Abschnitt Aus der Praxis). Andere Unternehmen ziehen nicht ernsthaft in Erwägung, die IT vollständig auszulagern, versprechen sich von einem selektiven Outsourcing aber einen stärkeren Konkurrenzdruck für den internen IT-Bereich. Zunehmender Wettbewerbsdruck kann zu einer stärkeren Professionalisierung, zu einer besseren Kundenorientierung und insgesamt zu effizienteren Leistungen führen.

Ressourcen CIOs versprechen sich durch eine Kooperation mit Outsourcing-Gebern einen besseren Zugriff auf notwendige Ressourcen. Dazu gehören insbesondere Know-how, Zugang zu und Erfahrungen mit neuen Technologien sowie entsprechende Personalkapazität bei den Outsourcing-Anbietern. In einigen Unternehmen werden selten oder kurzfristig erforderliche Betriebsmittel (z. B. Ausweichrechenzentren) ausgelagert sowie Ressourcen, deren Auslastung sehr stark schwankt (z. B. benötigen Online-Händler während des Weihnachtsgeschäfts deutlich größere Serverkapazitäten als in den Sommermonaten). Bei umfangreichen notwendigen Investitionen (z. B. für die Nutzung neuer Technologien) kann ein partielles Outsourcing (z. B. durch die Gründung eines gemeinsamen Unternehmens mit einem spezialisierten Dienstleister) zur Risikoteilung bzw. -reduzierung beitragen.

Organisation und Koordination In Unternehmen, in denen die Beziehungen zwischen IT-Bereich und den internen Abnehmern von IT-Leistungen unbefriedigend sind, wird Outsourcing betrieben, um eine einheitliche Steuerung der IT (vgl. Lerneinheit GOVER), eine bessere Kostenkontrolle, klare Verantwortungsbereiche, besser definierte Schnittstellen sowie Konfliktlösungsmechanismen zwischen IT-Bereich und Fachabteilungen zu etablieren. Die letztgenannten Ziele können auch auf andere Weise als durch Outsourcing erreicht werden, in der Regel durch eine Neugestaltung der Beziehungen zwischen IT-Bereich und den internen Kunden, wie es mit ITServicemanagement (vgl. Lerneinheit SEMAN) angestrebt wird.

Reichweite des Outsourcings Die Reichweite des Outsourcings beschreibt, in welchem Umfang Aufgaben und Elemente der Informationsinfrastruktur an Outsourcing-Geber übertragen werden. Es werden vier Reichweiten unterschieden. Beim selektiven Outsourcing – auch partielles Outsourcing oder Outtasking genannt – werden im Gegensatz zum totalen Outsourcing einzelne Aufgaben ausgelagert, z. B.:    

Betrieb eines User-Help-Desks, einzelne Aufgaben der Softwareentwicklung (z. B. Programmierung oder Test), Output-Management (Druck, Kuvertierung und Versand der Geschäftspost) oder IT-Schulung.

226

Strategische Aufgaben des Informationsmanagements

Beim totalen Outsourcing – auch als Full-IT-Outsourcing bezeichnet – wird die gesamte Verantwortung über alle Aufgaben an einen Dienstleister übertragen. Neben Aufgaben können auch Personal, Gebäude und Hardware sowie – sofern rechtlich zulässig – Softwarelizenzen vom Outsourcing-Nehmer auf den -Geber übertragen werden. Transitional Outsourcing wird unterschiedlich interpretiert. Häufig wird darunter die Erweiterung des totalen Outsourcings um die kontinuierliche Erneuerung der IT-Infrastruktur verstanden. Andere Autoren definieren den Begriff als Übertragung der Verantwortung für etablierte Technologien an externe Dienstleister, um interne Ressourcen auf Erprobung und Einführung neuer Technologien konzentrieren zu können. Beim Business Process Outsourcing werden komplette Geschäftsprozesse (genauer: die Ausführung betrieblicher Aufgaben) inklusive der entsprechenden IT-Funktionen und -Ressourcen ausgelagert, z. B.:    

Lohn- und Gehaltsabrechnung, Buchführung bzw. Rechnungswesen, Einkauf bestimmter Güterarten (z. B. Büroartikel) oder Abwicklung des Zahlungsverkehrs in einer Bank.

Verbleibende Aufgaben Zu den Aufgaben, die in der Regel nicht ausgelagert oder ausgegliedert werden, gehören bestimmte Aufgaben der Entwicklung von Informationssystemen, das strategische ITManagement sowie das Management der Outsourcing-Beziehung bzw. der -Beziehungen. Aufgaben der Entwicklung von Informationssystemen (vgl. Lerneinheit VOMOD), die üblicherweise nicht oder nicht vollständig an externe Dienstleister übertragen werden, sind die Anforderungsanalyse und der Abnahmetest. Darüber hinaus benötigt der Auftragnehmer auch während weiterer Phasen der Systementwicklung (z. B. für den fachlichen Entwurf und die Definition von Testfällen) erfahrene Ansprechpartner beim Kunden, um Informationssysteme erfolgreich entwickeln zu können. Aufgaben des strategischen IT-Managements (vgl. Lerneinheiten SITAN, SZIEL, STRAT und SPLAN) verbleiben ebenfalls im Unternehmen. Dazu gehören insbesondere:       

strategische Planung neuer Geschäftsfelder, Geschäftsprozesse und Produkte bzw. Dienstleistungen, für deren erfolgreiche Verwirklichung IT eine wichtige Rolle spielt, Identifikation, Analyse, Bewertung und Auswahl von Kandidaten für Objekte, die auf externe Dienstleister übertragen werden sollen, Spezifikation von (neuen) IT-Leistungsbedarfen, Steuerung des IT-Portfolios (vgl. Lerneinheit SPLAN), Management von IT-Architekturen (vgl. Lerneinheit ARCHI), IT-Governance (vgl. Lerneinheit GOVER), Mitwirkung bei der Budgetierung, d. h. Vereinbarung des für die IT zur Verfügung stehenden Budgets,

Outsourcing (OUTSO)

 

227

Struktur-, Qualitäts-, Technologie-, Sicherheits- und Notfallmanagement sowie ITControlling und -Revision (vgl. die Lerneinheiten STRUK, QUALM, TECHM, SICHM, NOMAN, CONTR und REVIS) sowie Business-IT-Alignment, d. h. Abstimmung bzw. gegenseitige Ausrichtung von Unternehmensstrategie und IT-Einsatz.

Zu den im Unternehmen verbleibenden Aufgaben im Rahmen des Managements der Outsourcing-Beziehung gehören:       

Aushandlung und Prüfung von Outsourcing-Verträgen (vgl. Lerneinheit VERMA), Prüfung, ob vertragliche Vereinbarungen vom Outsourcing-Geber eingehalten werden, insbesondere die Überprüfung der SLA (vgl. Lerneinheit SEVER), Wahrnehmung der Schnittstellen- bzw. Vermittlerfunktion zwischen dem OutsourcingGeber und den Fachabteilungen des Outsourcing-Nehmers, Führung, Kontrolle, Steuerung und Koordination der Outsourcing-Geber, Konfliktbewältigung, Wirtschaftlichkeitsanalysen der bestehenden Outsourcing-Beziehungen und Vorbereitung weiterer Make-or-Buy-Entscheidungen, d. h. von Entscheidungen für In- bzw. Outsourcing sowie Beobachtung und Analyse des Marktes für Outsourcing-Dienstleistungen.

IT-Aufgaben, die in der Regel beim Outsourcing-Nehmer verbleiben, haben folgende, in Form von Hypothesen formulierte und empirisch bestätigte, Eigenschaften (in Anlehnung an Dibbern/Heinzl/Leibbrand und von Jouanne-Diedrich):       

Je geringer die Produktionskostenvorteile eines Outsourcing-Gebers und je höher die mit dem Outsourcing verbundenen Transaktionskosten, je spezifischer die IT-Aufgaben und das zu ihrer Erfüllung notwendige Wissen, je stärker ausgeprägt die Sozialkompetenz der IT-Mitarbeiter, je größer das Vertrauen und je besser die persönlichen Beziehungen zwischen Mitarbeitern der IT-Abteilung und der Fachabteilungen, je neuer die Aufgaben sowie die zu ihrer Bearbeitung eingesetzten Technologien und je weniger Erfahrungen im Unternehmen damit gesammelt wurden, je höher die mit den Aufgaben verbundene wirtschaftliche bzw. fachliche Unsicherheit und je höher die strategische Bedeutung für das Unternehmen,

desto unwahrscheinlicher ist es, dass die betreffenden Aufgaben auf externe Dienstleister übertragen werden.

Standort des Outsourcing-Gebers Ausprägungen des Outsourcings können nach der geografischen Nähe zwischen Outsourcing-Nehmer und -Geber unterschieden werden. 

On Site Outsourcing bezeichnet eine Situation, in der der Outsourcing-Geber seine Leistungen am Standort des Kunden erbringt, z. B. Dienstleistungen von Beratungsun-

228

 



Strategische Aufgaben des Informationsmanagements

ternehmen für die Erstellung und Überprüfung von Sicherheitskonzepten (vgl. Lerneinheit SIKON) oder für die Integration von Anwendungssystemen. On Shore Outsourcing beschreibt die Aufgabenerfüllung in der näheren Umgebung bzw. im gleichen Land, wie es z. B. für Ausweichrechenzentren (vgl. Lerneinheiten NOMAN und INMAN) typisch ist. Beim Near Shore Outsourcing wählt das auslagernde Unternehmen einen Dienstleister im benachbarten Ausland und damit eine ähnliche Kultur, Zeitzone und Sprache. Dies ist z. B. der Fall, wenn ein österreichisches Unternehmen Teile der Softwareentwicklung an Dienstleister in Tschechien oder Ungarn auslagert. Off Shore Outsourcing bezeichnet die Übertragung von Aufgaben an einen Outsourcing-Geber im entfernten Ausland mit einer anderen Kultur, Zeitzone und Sprache, z. B. Abwicklung der Lohn- und Gehaltsabrechnung einer Bank aus der Schweiz durch ein Unternehmen in Indien.

Die Wahl des geeigneten Standorts eines Outsourcing-Dienstleisters hängt von der Personalkostendifferenz und der Spezifität der ausgelagerten oder ausgegliederten Aufgabe sowie dem damit verbundenen notwendigen Wissenstransfer und Kommunikations- und Koordinationsaufwand ab.

Rechtliche Gestaltung Die rechtliche Gestaltung des Outsourcings lässt sich in unternehmens- und vertragsrechtliche Gestaltung unterteilen. Bei der unternehmensrechtlichen Gestaltung ist insbesondere zu klären, inwieweit Outsourcing-Nehmer und –Geber rechtlich und wirtschaftlich voneinander abhängig sind. Folgende Optionen lassen sich unterscheiden:     

vollständige Übertragung des IT-Bereichs an einen rechtlich unabhängigen, externen Dienstleister (Auslagerung, totales Outsourcing), Gründung eines Gemeinschaftsunternehmens durch Outsourcing-Nehmer und -Geber sowie Übertragung aller oder einiger IT-Aufgaben des Outsourcing-Nehmers an dieses Gemeinschaftsunternehmen, Gründung einer 100%igen Tochtergesellschaft (Ausgliederung) und Übertragung aller oder einiger IT-Aufgaben des Outsourcing-Nehmers an dieses Unternehmen, zeitlich befristete Kooperationsverträge zwischen Outsourcing-Geber und -Nehmer sowie Vergabe von inhaltlich abgegrenzten und zeitlich befristeten Projektaufträgen an einen externen Dienstleister.

Bei den beiden erstgenannten Optionen sind die Gestaltungs- und Einflussmöglichkeiten des Outsourcing-Nehmers nach Vertragsabschluss im Vergleich zu den letztgenannten gering. Je größer die Reichweite des Outsourcings, desto wichtiger wird eine sorgfältige und detaillierte Vertragsgestaltung zwischen Outsourcing-Geber und -Nehmer (zur Vertragsgestaltung vgl. Lerneinheit VERMA). Outsourcing-Verträge bestehen aus zwei Komponenten, einem Rahmenvertrag und einem detaillierten Katalog der vom Outsourcing-Dienstleister zu erbringenden Leistungen. Im Rahmenvertrag werden insbesondere Vertragsgegenstand und Vertragsdauer, Preise für Leistungen und Mechanismen zur Ermittlung der Bezugsgrößen, Zahlungsbedingungen, Konfliktlösungsmechanismen, Konventionalstrafen, Kündigungsfris-

Outsourcing (OUTSO)

229

ten, Haftungs- bzw. Gewährleistungsansprüche, Regelungen für unvorhergesehene Ereignisse sowie Maßnahmen zur Sicherstellung der Vertraulichkeit geregelt. Ein detaillierter Leistungskatalog beschreibt, welche Leistungen der Outsourcing-Geber in welchem Umfang zu erbringen hat und welche Qualitätsmerkmale dabei erfüllt werden müssen. Die Vereinbarungen werden in Form von SLA spezifiziert (vgl. Lerneinheit SEVER). von Jouanne-Diedrich (132) nennt als typische Größenordnung für Verträge über große Outsourcing-Vorhaben ca. 30.000 Zeilen Text, über 600 SLAs und über 50 verschiedene Preismechanismen. Das Aushandeln solcher Verträge dauert oft länger als ein Jahr.

Organisatorische Gestaltung Praktische Erfahrungen (vgl. Abschnitt Forschungsbefunde) zeigen, dass der Erfolg des Outsourcings in hohem Maße von der Professionalität abhängt, mit der ein OutsourcingNehmer die Beziehung zum Outsourcing-Geber gestaltet. Dazu gehört insbesondere, wie die Schnittstelle zwischen internen Abnehmern der Leistungen – in der Regel den Fachabteilungen – und dem bzw. den externen Anbietern gestaltet wird. Wenn der Outsourcing-Nehmer über keine oder nur rudimentäre Struktureinheiten verfügt, die IT-Aufgaben übernehmen können, und wenn die Fachbereiche selbstständig Aufträge zur Erbringung von ITLeistungen an externe Anbieter vergeben, kann das verschiedene Nachteile haben:    



Es gibt keine Instanz, die mögliche Redundanzen und Doppellösungen verhindern oder reduzieren kann. Es ist nur schwer möglich, integrierte und konsistente Lösungen zu gewährleisten und unternehmensweit gültige Leitlinien und Standards einzuhalten. Entwicklung, Wartung und Pflege von Architekturen, die über einzelne Informationssysteme hinausgehen (z. B. Geschäfts- und Anwendungsarchitekturen, vgl. Lerneinheit ARCHI), wird schwieriger. Der Outsourcing-Nehmer gerät mit zunehmender Dauer der Outsourcing-Verhältnisse in eine starke Abhängigkeit von den Outsourcing-Gebern, da das interne Know-how zur Kontrolle und Steuerung der Dienstleister sowie die Fähigkeit verloren geht, ITAufgaben mit internen Ressourcen zu bewältigen. Mögliche Rabatte durch Rahmenverträge oder die Bündelung der Nachfrage nach Leistungen werden nicht ausgeschöpft.

Aus diesem Grund übertragen Unternehmen die IT nicht vollständig an externe Dienstleister, sondern erhalten einen Teil des IT-Bereichs, der sowohl als Koordinationsinstanz zwischen den Fachabteilungen und den Outsourcing-Gebern fungiert als auch die im Abschnitt Verbleibende Aufgaben beschriebenen Elemente ganz oder teilweise übernimmt.

Entscheidungsunterstützung Beim Fällen von Outsourcing-Entscheidungen wird im einfachsten Fall von den aus der Erfahrung bekannten, möglichst durch empirische Untersuchungen (vgl. den Abschnitt Forschungsbefunde) nachgewiesenen Argumenten ausgegangen. Diese können in Form einer Argumentebilanz aufbereitet werden, d. h. der systematischen Darstellung der Argumente, die für und die gegen eine untersuchte Alternative sprechen. Für eine besser fundierte Outsourcing-Entscheidung müssen die Kosten der Aufgaben, die ausgelagert werden sollen,

230

Strategische Aufgaben des Informationsmanagements

sowie die durch Auslagerung erzielbaren Nutzenbeiträge ermittelt werden. Was die Kostenermittlung betrifft, kommt dafür methodisch gesehen die Prozesskostenrechnung in Frage (vgl. Lerneinheit KOLER). Für die Ermittlung der Nutzenbeiträge eignen sich die in der Lerneinheit WIRTA beschriebenen Hilfsmittel zur Ermittlung der Nutzenstruktur. Darüber hinaus sollte die Rentabilität von Investitionen als Kriterium für OutsourcingEntscheidungen verwendet werden. Outsourcing-Entscheidungen können auch durch Verwendung von Normstrategien (vgl. Lerneinheit STRAT) unterstützt werden. Ausgehend von der Überlegung, dass der unternehmensspezifische Charakter der Organisationsleistung (Unternehmensspezifität) und ihre strategische Bedeutung die wesentlichen Einflussfaktoren auf die Höhe der Transaktionskosten bei Outsourcing sind, entwickelte Picot die in Abbildung OUTSO-1 gezeigte Beurteilungsmatrix mit neun Feldern und drei Beurteilungsbereichen, die in der Legende zur Abbildung erläutert sind. Bei der Interpretation der Beurteilungsbereiche werden die Kriterien Unsicherheit und Häufigkeit ergänzend herangezogen. Unternehmensspezifität

• reiner Fremdbezug (z. B. Standard-Anwendungssoftware) • Fremdbezug intern unterstützt (z. B. Anpassung von Software)

hoch

• koordinierter Einsatz von internen und externen Aufgabenträgern

mittel

• Eigenentwicklung extern unterstützt • reine Eigenentwicklung

niedrig niedrig

mittel

hoch

strategische Bedeutung

Abb. OUTSO-1: Normstrategien Eigenerstellung oder Fremdbezug (Quelle: nach Picot)

ASP, SaaS und Cloud Computing ASP ist eine Spezialform des Outsourcings, bei der ein Dienstleister (auch Application Service Provider genannt) Kunden gegen Entgelt die Nutzung von Anwendungsprogrammen ermöglicht. Der Dienstleister betreibt die Software in einem Rechenzentrum, sorgt für Lizenzen, Wartung und Aktualisierung und sichert dem Kunden die Einhaltung bestimmter Qualitätsmerkmale in Form von SLA (vgl. Lerneinheit SEVER) zu. Außerdem stellt er Kunden Speicher für Anwendungsdaten, Sicherheitsleistungen und Benutzerservice zur Verfügung. Die Kunden greifen über ein Netzwerk, i. d. R. das Internet, auf die Anwendungsprogramme zu. Endbenutzer benötigen lediglich einen Browser, um mit der Software arbeiten zu können. Der Application Service Provider erhält von seinen Kunden Erlöse, die sich entweder nach der Nutzungsintensität (z. B. Anzahl Transaktionen und in Anspruch genommene Speicherkapazität) oder nach Nutzungszeitraum und Anzahl der Nutzer (z. B. ein festes Entgelt pro Nutzer und Nutzungsmonat) richten. ASP wird auch als Software-Miete, Software-Outsourcing oder Software-on-Demand bezeichnet (Verbrauchsabrechnung, vgl. Lerneinheit VERMA).

Outsourcing (OUTSO)

231

Durch Nutzung von ASP können Kunden lange Einführungszeiten und hohe Investitionen für den Erwerb von Softwarelizenzen sowie für die zum Betrieb der Software notwendigen Hardwareressourcen vermeiden. Sie benötigen kein spezialisiertes Personal für Einführung, Betrieb, Wartung und Aktualisierung der Software sowie der zu ihrem Betrieb notwendigen Infrastruktur. Außerdem können sie die Nutzungskosten für die Software genau kalkulieren. ASP eignet sich insbesondere für Standardsoftware, die     

häufig aktualisiert werden muss, ohne oder nur mit geringen Anpassungen von verschiedenen Unternehmen eingesetzt werden kann, von wenigen Anwendern in einem Unternehmen benötigt wird, nicht oder nur unwesentlich mit anderer Software integriert werden muss oder nur selten genutzt wird.

Typische Beispiele für Anwendungen, die durch ASP unterstützt werden können, sind Buchführung und Lohn- und Gehaltsabrechnung in kleinen und mittelständischen Unternehmen, Erstellung von Rechnungen für Privatpatienten in Arztpraxen, Bearbeitung von Steuererklärungen in Steuerberatungskanzleien, Management von Dienst- bzw. Geschäftsreisen, WebContent-Management sowie Verwaltung und Auswertung von Kundendaten im Rahmen des Customer Relationship Management. Nachdem sich die hohen Erwartungen an ASP nicht erfüllten, wurde das Thema unter der Bezeichnung Software-as-a-Service (SaaS) wieder populärer. Mit Web Services (Erl) steht eine leistungsfähige Technologie zur Verfügung, mit der SaaS implementiert und in unternehmensinterne Software integriert werden kann. Im Zusammenhang mit serviceorientierten Architekturen (vgl. Lerneinheit MEGPM) ist zudem die Bereitschaft von Unternehmen gestiegen, Softwarekomponenten von externen Anbietern in eigene Anwendungen zu integrieren. Anbieter von SaaS erzielen Erlöse nicht ausschließlich direkt von den Kunden, sondern zunehmend auch indirekt durch Werbeeinnahmen. Seit Mitte der 2000er Jahre können Dienste von externen Anbietern auch im Rahmen von Cloud Computing bezogen werden (vgl. Lerneinheit INMAN sowie Eymann und Weinhardt et al.).

Forschungsbefunde von Jouanne-Diedrich leitet aus der Outsourcing-Forschung folgende Erkenntnisse und Empfehlungen ab (Sekundäranalyse von Erfahrungen mit Outsourcing, über die in fünf, zwischen 2001 und 2003 publizierten Quellen berichtet wird):    

Der Erfolg des Outsourcings hängt stark von Professionalität der Outsourcing-Nehmer im Umgang mit dem Outsourcing-Geber ab. Erfolgreiches Outsourcing erfordert einen kontinuierlichen, hohen Aufwand zur Steuerung des Outsourcing-Gebers. Outsourcing-Verträge sollten so detailliert wie möglich gestaltet werden. Langfristige Verträge (> 4 Jahre) sollen eine anfängliche Testphase umfassen; je länger die Laufzeit, desto wichtiger werden Mechanismen für Anpassungen und Änderungen.

232

      

Strategische Aufgaben des Informationsmanagements

Selektives Outsourcing ist erfolgreicher als umfassendere Varianten. Dies liegt insbesondere daran, dass die IT Bereiche umfasst, die sich nur schwer auf Externe übertragen lassen. Gut verstandene Technologien lassen sich in der Regel vertraglich leicht formulieren. Entsprechende Outsourcing-Vereinbarungen sind in den meisten Fällen erfolgreich. Das Auslagern oder Ausgliedern gut beherrschter Technologien setzt beim OutsourcingNehmer Ressourcen frei, die er für die Gestaltung neuer Technologien nutzen kann. Bei hoher geschäftlicher Unsicherheit oder neuen Technologien soll versucht werden, die Aufgaben mit eigenen Kräften (und evtl. externer Unterstützung) zu bewältigen. Folgende Aufgabenbereiche sollten auf keinen Fall auf Externe übertragen werden: ITGovernance, Schnittstellenfunktionen zwischen IT- und Fachabteilungen, Basis-Knowhow über die technische Architektur sowie das Management externer Dienstleister. Bei einer Outsourcing-Ausschreibung sollte die interne IT-Abteilung ein Angebot unterbreiten dürfen, da andernfalls wichtige Teilaufgaben und Vereinbarungen im Outsourcing-Vertrag vergessen werden könnten. Jede Outsourcing-Entscheidung erfordert vollständige Transparenz der Kostenstruktur der zu vergebenden Leistungen. Ohne diese Transparenz kann weder eine fundierte Entscheidung über eine Fremdvergabe noch eine Erfolgskontrolle vorgenommen werden.

Dibbern/Heinzl/Leibbrand führten Fallstudien (Datenerhebung in semi-strukturierten Interviews mit Mitgliedern der Geschäftsleitung oder IT-Führungskräften und Auswertung von Sekundärdaten in elf ausgewählten deutschen Unternehmen des verarbeitenden Gewerbes zwischen November 2000 und Januar 2001) durch, um ein besseres Verständnis der Gründe für Kostenunterschiede zwischen Eigenerstellung und Fremdbezug von IT-Leistungen zu erhalten. Ferner analysierten sie, inwieweit Erfolgswirkungen und Ressourcenunterschiede Sourcing-Entscheidungen beeinflussen. Es wurden folgende Erkenntnisse gewonnen:   



Die Beurteilung der Kosten ist das wichtigste Kriterium bei der Entscheidung über die interne oder externe Verrichtung von IT-Aufgaben. Transaktionskosten werden bei Outsourcing-Entscheidungen vernachlässigt, obwohl sie erhebliche Zusatzkosten während des Outsourcing-Betriebs verursachen können. Bei der Bereitstellung von Informationssystemen, die auf spezifische Prozesse von Unternehmen zugeschnitten sind, können sich interne IT-Mitarbeiter Wissensvorsprünge erarbeiten. Dadurch entstehen bei einer internen Verrichtung dieser Aufgaben anhaltende Kostenvorteile im Vergleich zu einer externen Verrichtung. Eine ausgeprägte Sozialkompetenz erleichtert und fördert den Wissensaustausch zwischen Mitarbeitern eines Unternehmens. Durch positive persönliche Beziehungen zwischen Mitarbeitern des IT-Bereichs und der Fachbereiche sinken die Interaktionskosten. Dies führt zur Beschleunigung von Prozessen, einem effektiveren Austausch von Wissen und zu sinkenden Produktionskosten.

Messerschmidt/Schülein/Murnleitner berichten über eine von PricewaterhouseCoopers in Auftrag gegebene Untersuchung des Wertbeitrags der IT zum Unternehmenserfolg (telefonische Interviews mit IT-Verantwortlichen in der Geschäftsführung von 650 deutschen Unternehmen, Untersuchungszeitraum November 2007 bis Januar 2008, keine Angaben zur Grundgesamtheit). Der durchschnittliche Outsourcing-Anteil (definiert als „Prozentanteil der

Outsourcing (OUTSO)

233

Outsourcing-Kosten an den gesamten IT-Aufwänden“, 74) beträgt 33 %. Er ist in bei Banken mit durchschnittlich 48 % am höchsten und bei Automobilunternehmen mit durchschnittlich 24 % am niedrigsten ausgeprägt. Je höher der Outsourcing-Anteil desto höher die Unzufriedenheit mit der IT. Die Autoren erklären dies mit dem durch IT-Outsourcing einhergehenden Verlust des IT-Know-hows beim Outsourcing-Nehmer. Amberg et al. berichten über eine Studie zum Zusammenhang von IT-Outsourcing und Compliance (schriftliche Befragung von 123 Experten aus den Bereichen Compliance und/oder Outsourcing, Rücklaufquote 56 %, keine Angabe zum Untersuchungszeitraum). Lediglich 41 % der befragten Outsourcing-Nehmer stimmten der Aussage „Compliance spielt bei ITOutsourcing-Entscheidungen eine wichtige Rolle“ zu. Allerdings hatten bei 40 % aller befragten Unternehmen Compliance-Anforderungen bereits einmal negativen Einfluss auf konkrete Outsourcing-Entscheidungen. Insbesondere bei börsennotierten Unternehmen mit mehr als 2000 Mitarbeitern, die als Outsourcing-Nehmer auftreten, ist Compliance ein Hinderungsgrund für Outsourcing, da Führungskräfte Verantwortung für Handlungen übernehmen müssen, die beim Outsourcing-Geber, also außerhalb ihres direkten Einflussbereiches, liegen.

Aus der Praxis Bhagwatwar/Hackney/Desouza berichteten über zwei Fälle von Backsourcing: Die englische Handelskette Sainsbury’s schloss im November 2000 einen Outsourcing-Vertrag mit Accenture über die Auslagerung von IT-Systemen und 470 IT-Mitarbeitern sowie die Implementierung neuer Anwendungssysteme. Der Vertrag hatte eine Laufzeit von sieben Jahren und ein Volumen von 1,7 Mrd. £. Sainsbury’s hatte eine Senkung der IT-Kosten von 35 Mio. £ pro Jahr (bei einem jährlichen IT-Budget von 200 Mio. £) erwartet. 2005 kündigte Sainsbury’s den Vertrag und begann, die an Accenture ausgelagerten Ressourcen und Aufgaben zu übernehmen. Die US-amerikanische Bank JPMorgan Chase hatte Ende 2002 mit IBM einen Vertrag über die Auslagerung von Rechenzentren, Help-Desks, Netzen für Sprach- und Datenkommunikation sowie 4000 IT-Mitarbeitern geschlossen. Der zum Zeitpunkt der Auslagerung weltweit größte IT-Outsourcing-Vertrag hatte ein Volumen von 5 Mrd. US$ und eine Laufzeit von sieben Jahren. 2004 übernahm JPMorgan Chase die sechstgrößte Bank der Vereinigten Staaten, Bank One. Diese hatte in den Jahren vor der Übernahme die IT-Kosten durch Zusammenlegung von Rechenzentren und Integration von Anwendungssystemen stark reduziert. 21 Monate nach Vertragsschluss, im August 2004, kündigte JPMorgan Chase den Outsourcing-Vertrag mit IBM. Obwohl JPMorgan Chase zur Zahlung einer Vertragsstrafe in Höhe von ca. 15 % der Vertragssumme an IBM und Sainsbury’s in Höhe von 65 Mio. Pfund an Accenture verpflichtet war, gingen beide Unternehmen davon aus, die IT ohne Unterstützung der Outsourcing-Geber effizienter betreiben zu können. Veltri/Saunders/Kavan beschreiben weitere Fälle von Backsourcing und berichten über typische Probleme. Laut der Studie Software – Made in Germany 2008 des IMWF (Institut für Managementund Wirtschaftsforschung), für die 217 IT-Entscheider befragt wurden, sind Softwarefehler das größte Problem in der Zusammenarbeit mit externen Softwaredienstleistern. Neben Fehlern und deren zu langsamer Behebung werten Softwareanwender die starke Abhängigkeit von externen Dienstleistern, zu teure Wartung sowie wechselnde Ansprechpartner als Nachteile der Auslagerung der Softwareentwicklung. Zwei Drittel der Befragten hält extern ent-

234

Strategische Aufgaben des Informationsmanagements

wickelte Software aber für sicherer und innovativer als intern entwickelte Programme (zitiert nach Computer Zeitung vom 11. Mai 2009, 11). Methodenverweise Serviceebenen-Vereinbarungen (Lerneinheit SEVER); Kosten- und Leistungsrechnung (Lerneinheit KOLER); Wirtschaftlichkeitsanalyse (Lerneinheit WIRTA). Kontrollfragen 1. Welche Ziele werden mit Outsourcing und welche werden mit Backsourcing verfolgt? 2. Welche Kriterien muss eine IT-Aufgabe erfüllen, um für eine Auslagerung geeignet zu sein? 3. Welche IT-Aufgaben werden in der Regel nicht auf externe Dienstleister übertragen? 4. Welche Voraussetzungen muss ein Outsoucing-Nehmer erfüllen, um Outsourcing erfolgreich betreiben zu können? 5. Worin besteht der Unterschied zwischen Outsourcing, SaaS und Cloud Computing? Quellen Amberg, M. et al.: Compliance im IT-Outsourcing. Theoretische und empirische Ermittlung von Einfluss nehmenden Compliance-Faktoren. Erlangen-Nürnberg 2009. Bhagwatwar, A. / Hackney, R. / Desouza, K. C.: Considerations for Information Systems 'Backsourcing': A Framework for Knowledge Re-integration. In: Information Systems Management 2/2011, 165–173 Dibbern, J. / Heinzl, A. / Leibbrand, S.: Interpretation des Sourcings der Informationsverarbeitung. Hintergründe und Grenzen ökonomischer Einflussgrößen. In: WIRTSCHAFTSINFORMATIK 5/2003, 533–540 Erl, T.: Service-Oriented Architecture. A Field Guide to Integrating XML and Web Services. 2. A., Englewood Cliffs 2004 Eymann, T.: Cloud Computing. In: Kurbel, K. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik - OnlineLexikon. München 4. A. 2010, o. S. http://www.enzyklopaedie-der-wirtschaftsinformatik.de Heinrich, L. J.: Datenverarbeitung außer Haus mit Hilfe der Computertechnik - Zeiterscheinung oder Notwendigkeit. In: Der Betrieb 51-52/1965, 1865–1868 Messerschmidt, M. / Schülein, P. / Murnleitner, M.: Der Wertbeitrag der IT zum Unternehmenserfolg. Stuttgart 2008 Picot, A.: Entscheidungshilfen für den Aufbau und die Organisation von Informationssystemen. In: Dialog 2/1991, 5–9 von Jouanne-Diedrich, H.: 15 Jahre Outsourcing-Forschung: Systematisierung und Lessons Learned. In: Zarnekow, R. / Brenner, W. / Grohmann, H. H. (Hrsg.): Informationsmanagement. Konzepte und Strategien für die Praxis. Heidelberg 2004, 125–133 Veltri, N. F. / Saunders, C. S. / Kavan, C. B.: Information Systems Backsourcing: Correcting Problems and Responding to Opportunities. In: California Management Review 1/2008, 50–76 Weinhardt, C. et al.: Cloud-Computing – Eine Abgrenzung, Geschäftsmodelle und Forschungsgebiete. In: WIRTSCHAFTSINFORMATIK 5/2009, 453–462 Vertiefungsliteratur Hayes, B.: Cloud Computing. In: Communications of the ACM 7/2008, 9–11 Hirschheim, R. / Heinzl, A. / Dibbern, J.: Information Systems Outsourcing. Enduring Themes, New Perspectives and Global Challenges. 2. A., Berlin et al. 2006 Mell, P. / Grance, T.: The NIST Definition of Cloud Computing (Draft). Recommendations of the National Institute of Standards and Technology. Special Publication 800-145. 2011, http://csrc.nist.gov Abruf 25. Juli 2011 Wintergerst, A. / Welker, M.: Die Rolle der Transaktionskosten bei Outsourcingentscheidungen. In: ZfbF - Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 11/2007, 938–954 Informationsmaterial BITKOM-Arbeitskreis Cloud Computing & Outsourcing http://www.bitkom.org/gremien/outsourcing CIO.com Cloud Computing und Outsourcing http://www.cio.com Lünendonk-Listen (Übersicht über IT-Service-Unternehmen, die Dienstleistungen wie Outsourcing, Wartung und Training erbringen) http://www.luenendonk.de

C. ADMINISTRATIVE AUFGABEN DES INFORMATIONSMANAGEMENTS

strategische Ebene

administrative Ebene

operative Ebene

Grundlagen des Informationsmanagements

Methoden des Informationsmanagements

Aufgaben des Informationsmanagements

Fallstudien Informationsmanagement

236

Administrative Aufgaben des Informationsmanagements

Gegenstand dieses Kapitels sind die administrativen Aufgaben des Informationsmanagements. Die Handlungen des administrativen Informationsmanagements vollziehen sich in dem Handlungsspielraum, der durch Entscheidungen und Maßnahmen des strategischen Informationsmanagements gegeben ist. Administrative Aufgaben sind dadurch gekennzeichnet, dass sie sich mit der IT-Infrastruktur insgesamt oder einzelnen, aber wesentlichen Komponenten der Informationsinfrastruktur (z. B. Personal, Datensystem) beschäftigen und über eine projektbezogene Betrachtung hinausgehen. Derartige ganzheitliche administrative Aufgaben des Informationsmanagements sind: Personalmanagement, Datenmanagement, Lebenszyklusmanagement, Geschäftsprozessmanagement, Wissensmanagement, Vertragsmanagement, Servicemanagement und Infrastrukturmanagement.

Personalmanagement (PERSM) ........................................................................................... 237 Datenmanagement (DATEM) .............................................................................................. 249 Lebenszyklusmanagement (LEMAN).................................................................................. 261 Geschäftsprozessmanagement (GPMAN)............................................................................ 273 Wissensmanagement (WIMAN) .......................................................................................... 285 Vertragsmanagement (VERMA).......................................................................................... 297 Servicemanagement (SEMAN)............................................................................................ 309 Infrastrukturmanagement (INMAN) .................................................................................... 321

Personalmanagement (PERSM) Lernziele Sie kennen den Zweck des Personalmanagements und die Bedeutung personalwirtschaftlicher Aufgaben für das Informationsmanagement. Sie kennen die Besonderheiten, die sich aus der Art und der Vielfalt des Personals ergeben und die Vorgehensweise bei der Stellenbildung. Sie können die Aufgabe des Personalmanagements in Teilaufgaben gliedern und jede Teilaufgabe erläutern. Sie wissen, was Personalführung bewirken soll. Sie können Stellenbeschreibungen für Aufgabenträger des Informationsmanagements formulieren.

Definitionen und Abkürzungen Aufgabenanalyse (task analysis) = Zerlegung von Aufgaben in Teilaufgaben und dieser in Tätigkeiten zwecks Bestimmung des Möglichkeitsraums der Arbeitsteilung. Aufgabenträger (task bearer) = Mensch (Person oder Gruppe) oder Mensch/TechnikSystem, dem eine Aufgabe zur Aufgabenerfüllung übertragen ist. Brooks'sches Gesetz (Brook’s law) = Erfahrungsgrundsatz, nach dem das Hinzuziehen weiterer Bearbeiter zu einem in Terminnot geratenen Projekt dieses noch mehr verzögert. (Adding manpower to a late project makes it later.) Coaching = Betreuung von Mitarbeitern durch Experten zur kooperativen Lösung fachlicher und/oder persönlicher Probleme. EFQM = European Foundation for Quality Management. Fähigkeitsmanagement (skill management) = zielorientiertes Verwalten der Fähigkeiten der Mitarbeiter, um sie diesen entsprechend einzusetzen und sie weiterzuentwickeln. Führung (leadership) = im Sinne von Unternehmensführung die zweck- und zielorientierte Koordination arbeitsteiliger Prozesse, im Sinne von Personalführung die Bildung, Durchsetzung und Sicherung eines Führungswillens und die Motivation der Mitarbeiter. Kooperation (cooperation) = sozialer Prozess zwischen mehreren Aufgabenträgern zur Erreichung gemeinsamer Ziele. Koordination (coordination) = Abstimmung der Tätigkeiten mehrerer Aufgabenträger, zwischen deren Aufgaben Interdependenz besteht. Motivation (motivation) = über Fähigkeiten und Fertigkeiten von Individuen und Gruppen hinausgehende Merkmale für erfolgreiches Handeln. Partizipation (participation) = umfassender Begriff zur Bezeichnung der Ansätze der Teilnahme von Betroffenen an gesamt- und einzelwirtschaftlichen Entscheidungen. Qualifikation (qualification) = Wissen und Können (Fähigkeiten und Fertigkeiten) eines Individuums oder einer Gruppe in Bezug auf eine bestimmte Aufgabe. Schulung (training) = Mittel und Maßnahmen, deren Zweck es ist, die Qualifikation der Mitarbeiter so zu gestalten, dass sie die ihnen zugeordneten Aufgaben erfüllen können. Stellenbeschreibung (job description) = schriftliche Aufzeichnung der einer Stelle zugeordneten Aufgaben und Aufgabenträger, der Über- und Unterstellungsbeziehungen, der Kompetenzen sowie der Anforderungen an die Qualifikation des Stelleninhabers.

238

Administrative Aufgaben des Informationsmanagements

Zweck des Personalmanagements IT-Personalmanagement ist der Teil des Informationsmanagements, der die Führungsaufgaben der betriebswirtschaftlichen Funktion Personalwirtschaft (oder Personalwesen, engl. HRM = Human Resource Management) für das Personal umfasst, dem die Aufgaben der Planung, Realisierung, Überwachung und Steuerung der Informationsinfrastruktur (IMAufgaben, vgl. Lerneinheit ERMOD) übertragen sind. Die Bezeichnung Personal weist auf überindividuelle Ordnungen hin, in denen Menschen primär zur Erreichung von Organisationszielen Leistungen erbringen, nicht zur Erreichung von Individualzielen. Personal gibt es in jedem Unternehmen als Folge arbeitsteiliger Leistungsprozesse (insbesondere Geschäftsprozesse, vgl. Lerneinheit GPMAN), und IT-Personal in jedem Unternehmen, das IT-Dienstleistungen erbringt. Durch die ganzheitliche Sichtweise des Informationsmanagements auf die Informationsinfrastruktur eines Unternehmens erweitert sich der Aufgabenumfang des Personalmanagements gegenüber der herkömmlichen Betrachtung, die sich auf die Führungsaufgaben des Personals der IT-Abteilung beschränkte, ganz wesentlich. So wie Betriebsmittel (z. B. Hard- und Software, Netze), Gebäude oder Räume, Datenbanken und Datenarchive usw. Komponenten der Informationsinfrastruktur sind, unabhängig davon, wie sie im Unternehmen verteilt sind, ist das gesamte Personal, das IM-Aufgaben wahrnimmt, IT-Personal und damit Objekt des Informationsmanagements, genauer gesagt: Objekt des Personalmanagements im IT-Bereich. Von der bei Heinrich/Heinzl/Riedl (286) verwendeten Systematik der Informationsinfrastruktur ausgehend, handelt es sich um den als personelle Infrastruktur bezeichneten Teil. Diese Systematik orientiert sich an zwei Merkmalen, am Charakter der IM-Aufgaben nach dem Drei-Ebenen-Modell (vgl. Lerneinheit ERMOD) und daran, ob es sich um Personen handelt, welche ausschließlich oder zumindest überwiegend IM-Aufgaben wahrnehmen und daher permanenten oder temporären Struktureinheiten des IT-Bereichs (vgl. Lerneinheit STRUK) zugeordnet sind, oder ob das Eine oder das Andere nicht der Fall ist. Zum IT-Personal in diesem Sinne gehören also neben den Mitarbeitern der IT-Abteilung (z. B. Organisatoren, Systementwickler, Operator, Helpdesk-Mitarbeiter) die Mitarbeiter der Fachabteilungen, die überwiegend bei der Erfüllung von IM-Aufgaben mitwirken (z. B. als Koordinator oder als Benutzer in ihrer Funktion als Mitarbeiter in IT-Projekten oder als Peerto-Peer-Unterstützer). Dabei handelt es sich überwiegend oder ausschließlich um Ausführungsaufgaben (z. B. Softwareentwicklung oder Benutzerservice). Personen in dieser Rolle werden im Folgenden als IT-Mitarbeiter bezeichnet. Da die Mitarbeiter der Fachabteilungen bei den meisten Formen der Projektorganisation disziplinarisch den Leitern dieser Abteilungen unterstellt bleiben (Matrixorganisation, vgl. Lerneinheit STRUK), sind die personalwirtschaftlichen Aufgaben des Informationsmanagements vor allem fachliche Aufgaben, deren Erfüllung Fachkompetenz voraussetzt und Sozialkompetenz erfordert, die ohne Selbstkompetenz nicht erhalten bzw. erworben werden können.

Personalmanagement (PERSM)







239

Fachkompetenz (Sachkompetenz oder Fachwissen, auch als hard skills bezeichnet) meint die Fähigkeit (Wissen, Kenntnisse und Fertigkeit), berufstypische Aufgaben selbständig und eigenverantwortlich erfüllen sowie fachliche Probleme erkennen und zielorientiert lösen zu können, was in der Regel eine entsprechende Ausbildung erfordert. Sozialkompetenz (auch als soft skills bezeichnet) meint die Fähigkeit und Bereitschaft zur Kooperation, sich mit anderen verantwortungsbewusst auseinanderzusetzen, sich gruppen- und beziehungsorientiert zu verhalten und in diesem Sinne auch Verhalten und Einstellungen von Mitmenschen zu beeinflussen. Selbstkompetenz (auch Human- oder Persönlichkeitskompetenz) meint die Fähigkeit und Bereitschaft sowie die Einstellungen und Verhaltensweisen, sich selbst zu entwickeln, eigene Begabung zu erkennen sowie Motivation und Leistungsbereitschaft zu entfalten, kurz gesagt, eigenes Verhalten von einer individuellen auf eine gemeinschaftliche Handlungsorientierung auszurichten. Der Begriff unterliegt keiner Normierung und kann im jeweiligen Kontext eine andere, aber stets positive Bedeutung haben.

Bei der Planung und Durchführung personalwirtschaftlicher Aufgaben sind die Besonderheiten des IT-Personals und der IM-Aufgaben verglichen mit dem Personal und den Aufgaben anderer Unternehmensbereiche zu beachten. Beispiele für diese Besonderheiten sind (vgl. auch Lerneinheit STELL):       

Ihr Durchschnittsalter ist geringer als das anderer Mitarbeiter. Sie sind innovativer, oft aber auch wertkonservativer. Ihre Arbeitsergebnisse beeinflussen andere Unternehmensbereiche stark. Ihre Arbeitsplätze erfordern erhebliche Investitionen und verursachen hohe Betriebskosten. Sie sind als Leistungsträger nur schwer ersetzbar. Eine Leistungsbeurteilung ist oft nur längerfristig möglich. Personalvermehrung führt nicht zwangsläufig zu Leistungssteigerung (Brooks´sches Gesetz).

Aufgaben des Personalmanagements Personalwirtschaftliche Aufgaben sind entweder primär Führungsaufgaben oder Verwaltungsaufgaben. Wegen der genannten und wegen weiterer spezifischer Eigenschaften des ITPersonals sind für das Personalmanagement im IT-Bereich folgende Aufgaben von Interesse:      

Personalbestandsanalyse zur quantitativen und qualitativen Erfassung des vorhandenen Personalbestands, Personalbedarfsermittlung zur Bestimmung des erforderlichen Personalbestands, Personalentwicklung zur Verbesserung der Qualifikation oder zur Herstellung einer bestimmten Qualifikation, Personalbeschaffung zur Anpassung des Personalbestands an den Personalbedarf, wenn der Bedarf größer als der Bestand ist, Personaleinsatz zur Zuordnung des Personals auf Aufgaben und Stellen, Personalfreisetzung zur Anpassung des Personalbestands, wenn der Bestand größer als der Bedarf ist, und

240



Administrative Aufgaben des Informationsmanagements

Personalführung zur Harmonisierung arbeitsteiliger Prozesse und zur konkreten Ausgestaltung des Verhältnisses zwischen Vorgesetzten und Untergebenen.

Personalbestandsanalyse Zweck der Personalbestandsanalyse ist es, den Personalbestand mit seinen wichtigsten Merkmalen in quantitativer Hinsicht (z. B. Anzahl Personen in definierten Qualifikationsund Verwendungsgruppen) und in qualitativer Hinsicht (z. B. Qualifikationsniveau in definierten Qualifikations- und Verwendungsgruppen) zu erfassen und zu untersuchen. Bezüglich des Personalbestands in qualitativer Hinsicht ist eine enge Abstimmung der Analyseergebnisse und der daraus abgeleiteten Maßnahmen (z. B. Maßnahmen der Personalentwicklung) mit den Anforderungen an die Personalqualifikation erforderlich, wie sie sich aus einem umfassenden Qualitätsmanagement ergibt (vgl. Lerneinheit QUALM). ISO 9004 geht in Teil 2 Abschnitt 5 ausdrücklich darauf ein (vgl. die Elemente 5.3.2.1 Motivation sowie 5.3.2.2. Schulung und Personalentwicklung). Im EFQM Excellence Modell sind zwei der fünf Inputkriterien (Befähigerkriterien), nämlich Führung und Mitarbeiterorientierung (Mitarbeiterentwicklung, Mitarbeiterbeteiligung, kontinuierliches Lernen), und ein Ergebniskriterium mitarbeiterbezogen, nämlich Mitarbeiterzufriedenheit. Auch andere Modelle (z. B. CobiT) stellen einen expliziten Bezug zum Personalmanagement her (z. B. bei CobiT die Prozesse PO 7 Manage IT human resources und DS 7 Educate and train users, vgl. Lerneinheit GOVER). Bei der Personalbestandsanalyse werden auch andere Eigenschaften des Personals, die leistungsbezogen (z. B. Arbeitsproduktivität) oder kostenbezogen sind (z. B. Kosten des Personalbestands, Kosten der Personalentwicklung), berücksichtigt.

Personalbedarfsermittlung Die Personalbedarfsermittlung dient der Bestimmung des langfristig erforderlichen Personalbestands; sie erfolgt in Abstimmung mit den Aussagen der IT-Strategie (vgl. Lerneinheit STRAT) und den geplanten strategischen Maßnahmen (vgl. Lerneinheit SPLAN). Mit dieser Abstimmung wird die Ausrichtung des Personalbedarfs an grundlegenden Entscheidungen über die Entwicklung der IT erreicht (z. B. Art und Umfang des Outsourcings, vgl. Lerneinheit OUTSO). Personalbedarfsermittlung umfasst folgende Teilaufgaben:  

Bestimmen der erforderlichen Positionen (Aufgabenprofil) und Ermitteln der Qualifikation der für diese Positionen benötigten Mitarbeiter (Anforderungsprofil).

Ausgangspunkt für die Durchführung der beiden Teilaufgaben sind Stellenbildung und daraus abgeleitete Stellenbeschreibungen. Ergebnis der Umsetzung der Personalbedarfsermittlung unter Berücksichtigung des Zeithorizonts (z. B. drei bis fünf Jahre) sind Personalbedarfspläne (z. B. jährlich). Das Ergebnis der Personalbedarfsanalyse stößt das gesamte Spektrum personalwirtschaftlicher Maßnahmen an, von der Personalentwicklung bis zur Personalführung. Objektsystem der Stellenbildung ist das Aufgabensystem des gesamten IT-Bereichs einschließlich Informationsmanagement, für das die Fragen zu beantworten sind, wie es in Stellen gegliedert und wie die Stellen koordiniert werden sollen. Ausgehend von der Kenntnis

Personalmanagement (PERSM)

241

des Objektsystems wird zunächst eine Aufgabenanalyse durchgeführt, mit der die zur Erfüllung der Gesamtaufgabe erforderlichen Teilaufgaben durch Gliederung nach analytischen Merkmalen ermittelt werden. In der Organisationslehre werden zur Aufgabenanalyse sachlich orientierte analytische Merkmale (Verrichtung, Objekt, Sachmittel) und formal orientierte analytische Merkmale (Rang, Phase, Zweckbeziehung) verwendet. An die Aufgabenanalyse schließt sich die Aufgabensynthese an, die aus den beiden Stufen Stellenbildung und Stellenbesetzung besteht. (Diese Vorgehensweise wurde bereits erläutert; vgl. Lerneinheit STRUK.) Die Ergebnisse der Stellenbildung werden als Stellenbeschreibungen dokumentiert; sie umfassen Aufgabenprofil und Anforderungsprofil. Für folgende Stellen mit Führungsaufgaben, deren Bezeichnung Stellenanzeigen entnommen wurden, wird IT-Personal gesucht (jeweils männlich/weiblich, nach den Schrägstrichen werden Synonyme angegeben):                

CIO / Leiter IT / Informationsverarbeitung / IT-Operations / Organisation und Informationssysteme Informationsmanager, IT-Manager / Informatik-Manager Rechenzentrumsleiter / Produktionsmanager Projektleiter / Projektmanager IT-Architekt Organisator / Organisationsberater / Systemanalytiker / IT-Analyst Softwareentwickler / Programmierer Entwicklungsadministrator Produktmanager Anwendungsadministrator / System- und Anwendungsbetreuer / IT-Koordinator Datenbankdesigner / -entwickler / Datenadministrator Problemkoordinator / Servicemanager Controller Revisor / Auditor / Prüfer Sicherheitsbeauftragter Call Center Manager

Aufgaben- und damit auch Anforderungsprofile überschneiden sich häufig inhaltlich (z. B. umfasst das Aufgabenprofil der IT-Koordination auch das der Leitung von Entwicklungsprojekten). Die Stellenbezeichnungen sind oft ergänzt durch das Präfix IT und die im Vordergrund stehenden Bearbeitungsobjekte (z. B. IT-Manager/in Operations, Projektleiter/in Data Warehousing). Art und Anzahl der Stellen sowie der Stellenbeschreibungen sind von Umfang und Komplexität der IM-Aufgaben abhängig. Je umfangreicher und vielgestaltiger die Aufgaben sind, desto mehr und differenziertere Stellenbeschreibungen sind erforderlich. Diese Aussage steht im Widerspruch zur häufig anzutreffenden Praxis des Fehlens von Stellenbeschreibungen im IT-Bereich, was meist mit dem hohen Aufwand für ihre Pflege begründet wird. (Lerneinheit STELL zeigt typische Formulierungen von Stellenanzeigen für IT-Führungskräfte.)

Personalentwicklung Personalentwicklung dient der Erhaltung und Verbesserung der Qualifikation oder der Herstellung einer bestimmten Qualifikation (insbesondere im Zusammenhang mit dem Einsatz

242

Administrative Aufgaben des Informationsmanagements

neuer Technologien, vgl. Lerneinheit TECHM). Sie erfolgt auf der Grundlage eines systematisch ermittelten Ausbildungsbedarfs. Der Ausbildungsbedarf wird mit einer Ausbildungsanalyse ermittelt. Diese fußt auf der gegenwärtigen und zukünftigen Arbeitssituation und den sich daraus ergebenden Qualifikationsanforderungen sowie der vorhandenen Qualifikation. Dazu werden Stellenbeschreibungen, Pläne, Vorhaben, Absichten, Fähigkeitsprofile, Leistungsgrenzen und Ergebnisse von Personalbestandsanalyse verwendet. Wesentlicher Einflussfaktor auf den Ausbildungsbedarf sind die Qualifikationsanforderungen, die sich aus dem geplanten Technologieeinsatz ergeben. Beispielsweise muss sich ein geplanter Paradigmenwechsel (z. B. der Systementwicklung vom Wasserfall- oder Spiralmodell zu Extreme Programming, vgl. Lerneinheit VOMOD) im Ausbildungsbedarf niederschlagen, im genannten Beispiel insbesondere bezüglich der Sozialkompetenz (Kommunikations-, Kooperations-, Koordinations-, Team- und Konfliktfähigkeit). Von den Ergebnissen der Ausbildungsanalyse ausgehend werden langfristige Ausbildungsmodelle entwickelt und darauf aufbauend zeitraumbezogene Ausbildungspläne erstellt (z. B. Jahrespläne). Technologieeinsatz bewirkt in Fachabteilungen nicht nur Veränderungen der verwendeten Sachmittel, sondern auch der Aufgaben und des Arbeitsablaufs. Einerseits entfallen Aufgaben, andererseits entstehen neue. Vorhandene Fähigkeiten und Fertigkeiten (Wissen und Können) werden zum Teil überflüssig, neue oder andere werden notwendig. Durch neue oder veränderte Technologien entstehen Tätigkeiten, die höhere Anforderungen an die Qualifikation der Mitarbeiter stellen (z. B. Ausnahmearbeit statt Routinearbeit, Entscheidung statt Ausführung). Zur Erfüllung dieser Anforderungen muss die Qualifikation durch Maßnahmen der Personalentwicklung planmäßig so verändert werden, dass sie zu dem Zeitpunkt, zu dem sie benötigt wird, zur Verfügung steht. Personalentwicklung ist auch notwendig, um Benutzer zur Partizipation und IT-Mitarbeiter zur Zusammenarbeit mit den Mitarbeitern der Fachbereiche zu befähigen. Das Problem der Partizipation und Zusammenarbeit, dessen strategische Bedeutung sich im IT-Leitbild ausdrücken sollte (vgl. Lerneinheit SZIEL), wird seit Jahrzehnten in Wissenschaft und Praxis beobachtet, wenn auch lange nicht ausreichend verfolgt. Klein hat schon 1980 über Befunde empirischer Untersuchungen zum Selbstbild und Fremdbild einer Gruppe von von ITMitarbeitern (damals als DV-Organisatoren bezeichnet) Folgendes berichtet:   

Selbstüberschätzung der IT-Mitarbeiter, negative Erfahrungen der Fachbereichsmitarbeitern mit IT-Mitarbeitern und Vorurteile der Fachbereichsmitarbeiter gegenüber den IT-Mitarbeitern.

Die Ergebnisse zeigen Einstellungen, die auch heute noch weit verbreitet sind. Sie führen zu Integrationsdefiziten zwischen den Entwicklungsergebnissen und den personellen und organisatorischen Bedingungen in den Fachbereichen; sie können nur durch Kooperation und Koordination überwunden werden. Unter der Bezeichnung (inneres) IT-Marketing wird diesem Phänomen heute die notwendige Beachtung geschenkt. Personalentwicklung ist also auch Aufbau von Erfolgspotenzial bei IT-Mitarbeitern und Benutzern, dessen Vorhandensein Voraussetzung für die Nutzung des Erfolgspotenzials veränderter oder neuer Technologien ist (vgl. Lerneinheit TECHM).

Personalmanagement (PERSM)

243

Spezielle Aufgaben der Personalentwicklung ergeben sich im Zusammenhang mit der Durchführung von IT-Projekten. Ziel muss sein, die Projektmitarbeiter zu unternehmerischem Denken und kooperativem Handeln hinzuführen. Führungsreserven (z. B. für Projektleitungsaufgaben) müssen aus dem Unternehmen heraus aktiviert werden, wobei auf die Förderung des Nachwuchses besonderer Wert zu legen ist. In Zusammenarbeit mit der Personalabteilung muss eine Führungskräfteplanung durchgeführt werden. Personalentwicklung muss auch systematisch innerhalb der Projektorganisation erfolgen, das heißt unter anderem, dass ein Projektleiter im Verlauf mehrerer Projekte „wachsen“ soll. Ziel der Personalentwicklung soll nicht sein, Mitarbeiter über die erforderliche Anpassungsqualifikation hinaus zu entwickeln. Die dafür erforderlichen Maßnahmen verursachen nicht nur Kosten, sondern verbrauchen auch Zeit, was zu einer Verminderung der verfügbaren Personalkapazität führt, da Qualifizierungsmaßnahmen zumindest teilweise, meist weitgehend während der Arbeitszeit erfolgen. Zudem besteht die Gefahr, dass überqualifizierte Mitarbeiter das Unternehmen eher verlassen als ausreichend qualifizierte Mitarbeiter, um attraktivere Positionen wahrzunehmen. Wenn Mitarbeiter auf Personalentwicklung in diesem Sinne hohen Wert legen, kann nicht immer darauf verzichtet werden. Ein enger Zusammenhang besteht zwischen Personalentwicklung und Wissensmanagement (vgl. Lerneinheit WIMAN) vor allem dann, wenn eine Personalisierungsstrategie verfolgt wird. Mit ihr werden Maßnahmen der Personalentwicklung explizit auf die Beantwortung der Frage ausgerichtet, wie personengebundenes Wissen in Organisationswissen umgesetzt werden kann. Im Unterschied dazu beruht eine Kodifizierungsstrategie auf der Annahme, dass das für den Unternehmenserfolg relevante Wissen kodifiziert werden kann.

Personalbeschaffung Zweck der Personalbeschaffung ist es, den Personalbedarf durch Rekrutierung von Personal auf dem Arbeitsmarkt zu decken, wenn dies nicht durch Maßnahmen der Personalentwicklung erfolgt. Während im „Zeitalter der Datenverarbeitung“ die Personalbeschaffung oft unternehmensintern erfolgte, also Mitarbeiter aus anderen Abteilungen „für die Datenverarbeitung“ rekrutiert wurden, liegt die Beschaffungsrichtung heute primär von außen nach innen. Der Erfolg von Personalbeschaffungsmaßnahmen auf dem Arbeitsmarkt wird in erster Linie durch die Verfassung des Arbeitsmarkts bestimmt, also durch das bestehende Angebot in quantitativer und qualitativer Hinsicht. Seit Universitäten, Fachhochschulen und weitere Einrichtungen der Erwachsenenbildung Studiengänge in Wirtschaftsinformatik anbieten, hat sich das Angebot zwar verbessert, doch ist die Deckungslücke wegen des stark gestiegenen Bedarfs der Wirtschaft an Wirtschaftsinformatikern im Verlauf der letzten Jahre größer geworden, so dass zur Zeit – und auf längere Zeit – eine Deckungslücke besteht. Die Personalbeschaffung zur Deckung eines bestimmten Bedarfs muss dann abgeschlossen sein, wenn die betreffenden Aufgaben planmäßig in Angriff genommen werden sollen. Voraussetzung für die Erfüllung der Anforderungen an die Personalbeschaffung ist ein Personalbeschaffungsplan, der auf der Grundlage von Personalbedarfsplan und Personalentwicklungsplan (Ausbildungsplan) erarbeitet wird. Personalbedarfsermittlung, Personalentwicklung und Personalbeschaffung bedürfen der engen Abstimmung mit Entscheidungen des Technologiemanagements (vgl. Lerneinheit

244

Administrative Aufgaben des Informationsmanagements

TECHM), um die Diffusion neuer Technologien im Unternehmen zu ermöglichen und um unterschiedliche Technologien parallel zu beherrschen (z. B. musste in den vergangenen Jahren neben der verwendeten prozessorientierten Softwaretechnologie Know-how für objektorientierte Softwaretechnologie aufgebaut werden).

Personaleinsatz Der Personaleinsatz regelt die Zuordnung des Personals auf Aufgaben und Stellen. Dabei kann grundsätzlich zwischen genereller Zuordnung auf Linieninstanzen (insbesondere auf Stellen der IT-Abteilung) und Zuordnung auf IT-Projekte unterschieden werden. Besonderheiten des Personaleinsatzes bestehen bei der Bildung von motivierten und leistungsfähigen Projektgruppen. Was den Zeitfaktor der Zuordnung angeht, bieten typische Aufgaben im IT-Bereich die Möglichkeit, Individualziele besser zu berücksichtigen als in anderen Unternehmensbereichen (z. B. hinsichtlich der Tages- und Wochenarbeitszeit).

Personalfreisetzung Die Personalfreisetzung dient der Anpassung des Personalbestands an den Personalbedarf, wenn der Bestand größer als der Bedarf ist (Personalüberdeckung). Bestandsanpassungen haben entweder unternehmerische Ursachen und sind (meist) Folge von Änderungen der ITStrategie (z. B. wenn Outsourcing verstärkt wird, vgl. Lerneinheiten STRAT und OUTSO), oder sie haben ihre Ursache in der Sphäre der Mitarbeiter (z. B. reduzierte Leistungsfähigkeit, mangelnde Leistungsbereitschaft oder überflüssig gewordene Qualifikation). Im Übrigen ergeben sich hier keine Besonderheiten für das Personalmanagement im IT-Bereich gegenüber anderen Unternehmensbereichen.

Personalführung Personalführung dient der Koordination arbeitsteiliger Prozesse und der konkreten Ausgestaltung des Verhältnisses zwischen Untergebenen und Vorgesetzten; sie ist sowohl aufgabenorientiert als auch personenorientiert. Die Besonderheit der Personalführung in ITProjekten besteht beispielsweise darin, dass die Mischung von Aufgabenorientierung und Personenorientierung von den Projektphasen abhängig ist. In frühen Projektphasen (vor allem in Vorstudie und Feinstudie und bis in den Systementwurf hinein) erfordert erfolgreiche Personalführung mehr Personenorientierung als Aufgabenorientierung verglichen mit späten Projektphasen (Systementwurf und vor allem Implementierung und Installierung). Je mehr sich im Projektverlauf die Forschungsatmosphäre, die im Wesentlichen durch Kreativität und mehrere Lösungsalternativen gekennzeichnet ist, in eine Werkstattatmosphäre verwandelt, die durch Arbeiten nach vorgegebenen Spezifikationen gekennzeichnet ist, desto mehr tritt die Aufgabenorientierung in den Vordergrund. Aufgabe der Personalführung ist auch die Motivation der Mitarbeiter. Dies gilt besonders deshalb für das Informationsmanagement, weil Leistungsträger im IT-Bereich schwer ersetzbar sind, hohe Investitions- und Betriebskosten verursachen und ihre Kreativität und Leistungsbereitschaft erheblichen Einfluss auf den Unternehmenserfolg haben. Fehlende Motivation kann auch auf Schwierigkeiten im Verhältnis zwischen IT-Management und Unternehmensleitung sowie auch zwischen IT-Management und Fachbereichsmanagement bzw. IT-

Personalmanagement (PERSM)

245

Mitarbeitern und Benutzern zurückzuführen sein; dies hat Auswirkungen auf den gesamten IT-Bereich und damit auf das ganze Unternehmen. Gründe für ein Problemverhältnis sind:    

Den IT-Managern fehlen grundlegende Kenntnisse, Fähigkeiten und/oder Fertigkeiten (vgl. Lerneinheit STELL). Zwischen Top-Management und IT-Management bestehen Verständigungsprobleme, weil unterschiedlicher Begriffssysteme verwendet werden. Dem IT-Management fehlen Orientierungen (z. B. in Form eines Leitbildes dokumentiert, vgl. Lerneinheit ZAMIN), an denen es sein Handeln ausrichten kann. Zwischen IT-Management und Top-Management besteht ein nicht zu überbrückender Abstand, so dass Visionen des Top-Managements über die Gestaltung der Informationsinfrastruktur vom IT-Management nicht aufgegriffen oder nicht umgesetzt werden oder aber das Top-Management den Visionen des IT-Managements nicht zugänglich ist.

Forschungsbefunde Lee/Trauth/Farwell fanden mit einer mehrstufigen Feldstudie (offenes Forum mit rd. 50 Personen aus Wirtschaft und Universität, anschließend eine Serie von Joint Sessions mit den Stakeholder-Gruppen IS managers, business/user managers, consultants, dann schriftliche Befragung von 98 Personen aus diesen Gruppen, Untersuchungszeitraum 1994/95) folgende, als kritisch bezeichnete Fähigkeiten, die von IT-Mitarbeitern verlangt werden (332): „Overall, our study suggests that industry will demand a cadre of IS professionals with knowledge and skills in technology, business operations, management, and interpersonal skills to effectively lead organizational integration and process reengineering activities. The lower-level IS jobs are rapidly disappearing, and the requirements for IS professionals are becoming more demanding in multiple dimensions, particularly in the areas of business functional knowledge and interpersonal/management skills. Our results also found some clear pattern in IS staffing and activity trends that point to the shift in emphasis from traditional, central IS organization toward a more decentralized, end-user-focussed business orientation. Aligning IS solutions with business goals and needs as well as building the infrastructure for technological integration are becoming the top priorities for IS activities.“ Feraud konstatiert auf Grund von Beobachtungen von IT-Mitarbeitern bei Weiterbildungsseminaren deren geringes Interaktionsbedürfnis (low need of interaction). Sie zieht daraus u. a. den Schluss, dass IT-Mitarbeiter Schwierigkeiten bei der Personalführung haben werden, falls sie bis in Führungspositionen aufsteigen sollten. Als mögliche Problemlösung wird empfohlen, IT-Mitarbeiter mit wechselnden Aufgaben zu betrauen (job rotation) und ihnen ein hohes Maß an Eigenverantwortlichkeit zuzumuten. Scholz zieht aus einer Reihe empirischer Untersuchungen (keine näheren Angaben zur Untersuchungsmethode) den Schluss, dass wegen der vom IT-Personal intensiv wahrgenommenen Wettbewerbssituation vor allem die Kommunikationszufriedenheit im Unternehmen wichtig ist. Dabei geht es primär um eine subjektiv erlebte Qualität und Quantität von Informationsmedien und -inhalten, die stark von der Unternehmenskultur als kollektivem Werteund Normsystem determiniert wird. Vergleichbare Unternehmen weisen teilweise vollkommen unterschiedlich stark ausgeprägte Bestimmungsfaktoren für Kommunikationszufriedenheit auf. Eine Analyse bei einem IT-Dienstleister zeigte beispielsweise, dass die Kenngröße

246

Administrative Aufgaben des Informationsmanagements

„die obere Ebene hat Erfolg in der Vermittlung der Visionen durch klar definierte Ziele“ mit 27 % den stärksten Einfluss auf die Kommunikationszufriedenheit hat. Trittmann et al. berichten über den Zusammenhang zwischen Motivationsfaktoren und Erfolgsfaktoren von Vorhaben zur Verbesserung der Softwareentwicklung Folgendes (Fallstudie mit zwölf untersuchten Verbesserungsvorhaben mit unterschiedlichen Gegenständen, 36 Tiefeninterviews, Untersuchungszeitraum 1997/1998): Die Motivstruktur der Mitarbeiter zeigt starke intrinsische Faktoren; die Motivationsfaktoren beziehen sich in erster Linie auf die Aufgabe selbst. Erfolgreiche Verbesserungsvorhaben sind daher so gestaltet, dass sie einer intrinsischen Motivation förderlich sind. Dorgan/Dowdy berichten über Befunde empirischer Untersuchungen, die vom McKinsey Global Institute durchgeführt wurden, u. a. Folgendes: Es besteht eine Korrelation von 95 % zwischen gutem Management, wie es von Fachleuten beurteilt wird, und dem als ROCE (Return On Capital Employed) gemessenen Kapitalrückfluss. Sharma/Yetton berichten als Ergebnis einer Literaturanalyse über die Wirkung (effect) der Benutzerschulung (end-user training) auf den Einführungserfolg von Informationssystemen (IS implementation success) u. a. (Meta-Analyse von 27, 1992 bis 2004 publizierten empirischen Studien): „The effect of training on implementation success ist contingent on both technical complexity and task interdependence.“ (227) Wenn beide Variablen sehr schwach ausgeprägt sind, ist die Wirkung auf den Einführungserfolg vernachlässigbar klein; spezifische Maßnahmen der Personalentwicklung sind nicht erforderlich. Aus diesem Befund wird für das Design von Trainingsprogrammen die Empfehlung abgeleitet (230 f.): „We speculate that a two-stage training program may be effective for high technical complexity and high task interdependence contexts. Stage one would focus on individual cognitions, providing technology-related training and developing end-user technical competencies. The second stage would focus on interindividual cognitions, providing task-related training, increasing collaborative task knowledge, and developing transactive memory.” Damien et al. leiten aus den Befunden einer Literaturanalyse zum Phänomen IT turnover folgende Schlussfolgerungen für weitere Forschungsarbeiten ab (narratives Review von 33 Studien, Modellierung und quantitative Analyse): „First, future research should examine the trunover intention to turnover behavior link as quit intentions may not necessarily lead to actual turnover. Second, we hope that with the use of more recent theories and more rigorous research design IT scholars can better inform the research and practice of managing the IT turnover phenomenon. Finally, we call for future research to theorize and test the influence of contextual factors especially those specific to the IT profession, in the turnover processes and decisions of IT professionals.” (566)

Aus der Praxis Die Auswertung der Ergebnisse einer Potenzialanalyse im Bereich Sozialkompetenz bei einem IT-Dienstleister ergab einen hohen Trainingsbedarf bei folgenden Fähigkeiten und Fertigkeiten (zitiert nach Stadtler-Pree): Bewusstheit eigener Körpersprache und Kommunikationsmuster, Feedback geben und nehmen, Beratungskompetenz, Verhandlungsgeschick, Umgang mit Konflikten, Kenntnis eigener Stärken und Schwächen, Einsicht in eigenes Fehl-

Personalmanagement (PERSM)

247

verhalten. Defizite bei diesen Fähigkeiten und Fertigkeiten wirken sich nachhaltig negativ auf die Zusammenarbeit in Gruppen aus, wie sie für IT-Projekte typisch sind. Sie können durch Trainings abgebaut, zumindest reduziert werden, Die Trainings bauen auf vorhandener Fachkompetenz auf, stärken Selbstkompetenz und entwickeln Sozialkompetenz. Zur Rolle des IT-Managements hat Synstar International u. a. festgestellt (Telefoninterviews, 250 IT-Manager in Benelux, Deutschland und Großbritannien, Erhebungszeitraum Februar/März 2001): „The majority of IT Managers/Directors have mainly operational roles (56 %). However, over the last two years a good proportion of IT executives (60 %) claim to be moving towards a more strategic role. Executives in Germany were more likely to progress into a more strategic role (72 %) relative to their counterparts in the UK (51 %).” Nach Feststellung der Managementberatung Compass Deutschland GmbH (Auswertung der Daten von 18 IT-Projekten) lassen sich die Personalkosten von IT-Projekten durch eine anforderungsgerechte Rollenverteilung um durchschnittlich 18,5 % senken. In vielen Entwicklungsprojekten sei der Anteil des Senior-Levels zu hoch. Mehr als 80 % der Unternehmen praktizieren kein umfassendes Skill Management, um die Fähigkeiten ihrer Mitarbeiter zu verwalten und ihnen auch horizontale Karriereperspektiven zu bieten. Mit dem standardisierten Rahmenwerk SFIA (Skills Framework for the Information Age) können Qualifikationen und Erfahrungen überbetrieblich klassifiziert und beschrieben werden. Durch Skill Management ließen sich nicht nur Projektkosten senken, sondern auch die gesamte Organisationsentwicklung könnte systematischer am Personalbedarf ausgerichtet werden. Unternehmen könnten die strategisch benötigten fachlichen Qualifikationen für die nächsten Jahre genau erfassen, mit den vorhandenen Skills abgleichen und gezielt Maßnahmen ergreifen, um Lücken zu schließen. Die Mitarbeiter erhielten bessere Karriereperspektiven und könnten besser motiviert werden. (Zitiert nach Computer Zeitung vom 11.8.2008, 16.) Die Unternehmensberatung TCW hat in einem Pilotprojekt ein Vorgehensmodell zum internen IT-Marketing entwickelt. Im Ergebnis wird Folgendes festgestellt: „Das Vorgehensmodell eröffnet die Möglichkeit, das Image von IT-Abteilungen langfristig zu erhöhen. Die Kommunikationsstrukturen zwischen den Fachabteilungen und der IT können effizienter gestaltet werden und dadurch mehr Transparenz über die IT-Leistungen geschaffen werden. Reibungsverluste werden somit vermindert und die Zufriedenheit interner und externer Kunden wird verbessert, was sich positiv auf den Unternehmenserfolg auswirkt.“ Die Unternehmensberatung Prozept hat für 2011 folgende Trends im Personalmanagement ausgemacht: „Ein Herausforderung, der sich viele IT-Abteilungen heuer stellen müssen, ist das Empowerment [= aktive Förderung von Selbstkompetenz] und die Stärkung der Produktivität ihrer Mitarbeiter. … Auch die Anforderungen an den modernen IT-Mitarbeiter werden sich 2011 zu verschieben beginnen. Waren bisher vor allem technische Fähigkeiten gefragt, werden nun andere Kompetenzen erfolgskritisch. Als interner Dienstleister wird er in Zukunft eine starke Vermittlerrolle zwischen Fachbereichen und IT spielen und auch die Geschäftsprozesse tragend mitgestalten und optimieren. Eine weitere Aufgabe wird die Formulierung der Anforderungen an die IT-Lösungen darstellen.“ Ein Beispiel für klassische, durch IT-Einsatz unterstützte Maßnahmen der Personalentwicklung ist das Planspiel. Bei der Metro Gruppe dient das Planspiel Business Simulation dazu,

248

Administrative Aufgaben des Informationsmanagements

dass Mitarbeiter lernen, Arbeitsabläufe zwischen Abteilungen zu vernetzen und besser zu koordinieren. In der Online-Simulation sind Newsgroups, Online-Chats, Blackboards und eine Funktion zur Unterstützung von Filesharing integriert (zitiert nach Computer Zeitung vom 11.5.2009, 21). Methodenverweise Kosten- und Leistungsrechnung (Lerneinheit KOLER); Kennzahlensysteme (Lerneinheit KENNZ). Kontrollfragen 1. Was ist Zweck des Personalmanagements und wie wird es in Aufgaben gegliedert? 2. Welche Bedeutung haben Sozial- und Selbstkompetenz neben der Fachkompetenz für die Personalentwicklung? 3. Wie führen Technologiedurchdringung und Technologieänderung zum Aus- und Fortbildungsbedarf? 4. Was meint Personalisierungsstrategie im Unterschied zu Kodifizierungsstrategie? 5. Welche Forschungsbedarfe oder Forschungsgegenstände lassen die Forschungsbefunde erkennen? Quellen Damien, J. et al.: Turnover of Information Technology Professionals: A narrative Review, meta-analytic structural Equation Modeling, and Model Development. In: MIS Quarterly 3/2007, 547–577 Dorgan, St. J. / Dowdy, J. J.: How good management raises productivity. In: The McKinsey Quarterly 4/2002, 14– 16 Feraud, G.: What makes IT professionals tick? FINANCIAL TIMES, Supplement „Mastering Information Management“, 15.2.1999, 10 Heinrich, L. J. / Heinzl, A. / Riedl, R.: Wirtschaftsinformatik – Einführung und Grundlegung. 4. A., Heidelberg 2011, insbes. Kapitel Personelle Infrastruktur, 307–318 Klein, H.: Partnerschaft zwischen Fachabteilung und EDV. In: Heilmann, H. (Hrsg.): Zusammenarbeit zwischen Fachabteilung und EDV. Stuttgart/Wiesbaden 1980, 15–63 Lee, D. M. S. / Trauth, E. M. / Farwell, D.: Critical Skills and Knowledge Requirements of IS Professionals. A Joint Academic/Industry Investigation. In: MIS Quarterly 3/1995, 313–340 Prozept: http://www.prozept.com/quo-vadis-it-it-trends-2011Methodenverweise; Abruf 8. Mai 2011 Scholz C.: Personalarbeit im IT-Bereich – Erfolgskritische Aktionsfelder. In: Sonderheft WIRTSCHAFTSINFORMATIK 10/2000, 14–23 Schütt, P.: Wissensmanagement. Niedernhausen 2000 Sharma, R. / Yetton. P.: The contingent effects of training, technical complexity, and task interdependence on successful information systems implementation. In: MIS Quarterly 2/2007, 219–238 Stadtler-Pree, I.: Soziale Kompetenz für IT-Mitarbeiter – Trainingsbedarfsanalyse und Trainingsdesign. Projektarbeit Universitätslehrgang Training und Bildungsmanagement an der Universität Linz, 2006 Synstar Int. (Ed.): Does the board understand the importance of IT yet? http://www.synstar.com/survey1; Abruf 15. Dezember 2004 TCW Unternehmensberatung: Vorgehensmodell IT-Marketing. http://www.tcw.de/news/view/236; Abruf 8. Mai 2011 Trittmann, R. et al.: Managing Motivation bei der Softwareentwicklung – Ein Fallstudie bei der SAP. In: Frey, B. S. / Osterloh, M. (Hrsg.): Managing Motivation. 2. A., Wiesbaden 2002, 279–302 Vertiefungsliteratur Berthel, J. / Becker, F. G.: Personal-Management. 8. A., Stuttgart 2007 Bühner, R.: Personalmanagement. 3. A., München/Wien 2005 Drumm, H. J.: Personalwirtschaft. 5. A., Berlin/Heidelberg 2005 Enns, H. G. / MacFarlin, D. B. / Huff, S. L.: How CIOs can effectively use Influence Behaviors. In: MIS Quarterly 1/2007, 29–38 Jäger, R.: Praxisbuch Coaching – Erfolg durch Business Coaching. Offenbach 2001 Madauss, B. J.: Handbuch Projektmanagement. 7. A., Stuttgart 2006 Peppard, J. / Lambert, R. / Edwards, C.: Whose job is it anyway? Organizational information competencies for value creation. In: Information Systems Journal 10/2000, 291–322 Sonderheft WIRTSCHAFTSINFORMATIK 10/2000: IT & Personal Stock-Homburg, R.: Personalmanagement: Theorien – Konzepte – Instrumente. 2. A., Wiesbaden 2010 Tippins, M. J. / Sohi, R. S.: IT Competency and Firm Performance – Is Organizational Learning a Missing Link? In: Strategic Management Journal 8/2003, 745–761

Datenmanagement (DATEM) Lernziele Sie kennen den Zweck des Datenmanagements und seine Aufgaben. Sie wissen, welche Funktionen ein Data Warehouse für das Business Intelligence übernimmt und wie unstrukturierte Daten für betriebliche Entscheidungen zugänglich gemacht werden können. Sie kennen die Bedeutung von Metadaten für das Datenmanagement. Sie wissen, mit welchen Merkmalen Datenqualität spezifiziert werden kann und kennen Aufgabenträger des Datenmanagements.

Definitionen und Abkürzungen BI = Business Intelligence. Data Dictionary = Datenkatalog; System zur Verwaltung von Metadaten. Daten (data) = Information, die zum Zweck der Verarbeitung formalisiert dargestellt ist und aus der andere Information abgeleitet werden kann. Datenbanksystem (database system) = Kombination aus einem DBMS und einer oder mehreren Datenbanken. Datenmodell (data model) = Beschreibung des Inhalts, der Struktur und der Bedeutung von Daten, in der Regel mit der Entity-Relationship-Notation. Datenqualität (data quality) = Gesamtheit der Anforderungen an Daten. Datensystem (data system) = Abbildung der Wirklichkeit in Daten für die Aufgaben eines Unternehmens. DBMS = Database Management System; Datenbankmanagementsystem. Synonym: Datenbankverwaltungssystem. DW = Data Warehouse; 1993 von Inmon geprägte Bezeichnung für eine von den operativen Datenbeständen getrennte, integrierte Datenbasis zur Entscheidungsunterstützung. FASMI = Fast Analysis of Shared Multidimensional Information; 1995 von Pendse/Creeth geprägter Begriff zur Charakterisierung von OLAP. Metadaten (meta data) = Daten, mit denen Nutzdaten beschrieben werden. OLAP = Online Analytical Processing; 1993 von Codd/Codd/Salley geprägter Begriff zur multidimensionalen Analyse von Daten in DW. OLTP = Online Transaction Processing; transaktionsorientierte Verarbeitung von Daten in operativen Datenbanksystemen. OMG = Object Management Group; Konsortium von IT-Herstellern, das Standards für die herstellerunabhängige Entwicklung von Informationssystemen verfasst. SQL = Structured Query Language; Datenbanksprache für relationale Datenbanken. strukturierte Daten (structured data) = Daten, für deren Elemente eine bestimmte Anordnung bzw. Struktur vorgeschrieben ist (z. B. in operativen Datenbanken oder DW). Synonym: formatierte Daten. unstrukturierte Daten (unstructured data) = Daten, für deren Elemente keine bestimmte Anordnung bzw. Struktur vorgeschrieben ist (z. B. Texte, Grafiken, Präsentationen, Tabellenkalkulationen, Videos, Audios). Synonyme: unformatierte oder formatfreie Daten.

250

Administrative Aufgaben des Informationsmanagements

Zweck des Datenmanagements Die aus den Zielen des Informationsmanagements abgeleitete Forderung, Information und Kommunikation als Produktionsfaktor und Daten als wirtschaftliches Gut zu betrachten, führt dazu, die Informationsfunktion nicht nur als Unterstützungsfunktion für andere betriebliche Funktionen, sondern als gleichberechtigte Aufgabe zu sehen. Ihr Zweck ist es, Daten aus bestehenden Datenquellen zur Verfügung zu stellen und weitere Datenquellen zu erschließen, um neue Möglichkeiten der Informationsproduktion anzubieten. Der Aufgabenschwerpunkt der IT-Abteilung verlagert sich von der Datenverarbeitung zur Datenbereitstellung für die Informationsproduktion, sofern das Datenmanagement nicht über die Zuständigkeit der IT-Abteilung hinauswächst und andere strukturorganisatorische Einordnungen gesucht werden müssen (vgl. dazu weiter unten sowie Lerneinheit STRUK). Aufgabe des Datenmanagements ist es, auf der Grundlage der Datenarchitektur (vgl. Lerneinheit ARCHI) alle im Unternehmen verwendeten Daten zu planen, zu überwachen und zu steuern, und zwar so, dass die zur Informationsversorgung aller Aufgabenträger erforderlichen Daten in angemessener Qualität verfügbar sind. Datenmanagement beschäftigt sich mit strukturierten und unstrukturierten Daten. Datenmanagement ist Voraussetzung dafür, dass Informationsbedarf und insbesondere Informationsnachfrage (vgl. Lerneinheit INBAN) befriedigt werden können. Datenmanagement befasst sich idealtypisch gesehen mit dem gesamten Datensystem des Unternehmens, unabhängig davon, mit welchen Mitteln die Daten verwaltet werden, welche Aufgabenträger sie für welche Aufgaben verwenden und wo sie geführt werden. Die Aufgabe umfasst auch die Wartung und Pflege der Daten.

Ziele und Aufgaben des Datenmanagements Aus dem Ziel des Datenmanagements, Aufgabenträgern unter Berücksichtigung des Wirtschaftlichkeitsprinzips die erforderlichen und gewünschten Daten in angemessener Qualität zur Verfügung zu stellen, lassen sich folgende Kernaufgaben ableiten.

Datenanalyse Die Datenanalyse identifiziert relevante Daten und gibt Aufschluss über ihre Entstehung und Verwendung. Sie hilft, folgende Fragen zu beantworten:     

Welche Daten sind für die Leistungserstellung notwendig bzw. hilfreich? Woher stammen die Daten, wer erfasst und bearbeitet sie? Wer benutzt welche Daten für welche Anwendungen? Wer erhält für welche Zwecke welche Auswertungen der Daten? Welche Qualitätsanforderungen sollen die Daten erfüllen?

Input für die Datenanalyse sind die Datenarchitektur (vgl. Lerneinheit ARCHI) und Ergebnisse von Informationsbedarfsanalysen (vgl. Lerneinheit INBAN).

Datenmodellierung Mit Hilfe der Datenmodellierung werden Inhalt, Struktur und Bedeutung von Daten beschrieben. Datenmodelle werden in der Regel mit der Entity-Relationship-Notation nach

Datenmanagement (DATEM)

251

Chen repräsentiert. Die – auch als semantisch bezeichneten – Datenmodelle können in hierarchische, netzwerkartige oder relationale, so genannte logische Datenbankmodelle überführt werden. Für die multidimensionale Modellierung in DW stehen das Star-Schema und das Snowflake-Schema (Chaudhuri/Dayal) zur Verfügung. Becker/Rosemann/Schütte entwickelten in Anlehnung an die Grundsätze ordnungsmäßiger Buchführung (GoB, vgl. Lerneinheit REVIS) Grundsätze ordnungsmäßiger Modellierung (GOM), die Hinweise zur Anwendung von Modellierungsmethoden beim Gestalten des Datensystems geben können. Werden Datenmodelle für unterschiedliche Anwendungen unabhängig voneinander entwickelt, führt dies in der Regel zu einem Mangel an Konsistenz der Daten in den verschiedenen Anwendungen und zu nicht ausreichender Integrationsfähigkeit der Informationssysteme. Das hat zu der Forderung nach Unternehmensdatenmodellen geführt. Diese stellen den Versuch dar, nicht nur Daten einzelner Anwendungen zu modellieren, sondern wesentliche, für das Unternehmen relevante Daten über die Grenzen einzelner Anwendungen hinweg. Unternehmensdatenmodelle stoßen aber in der praktischen Umsetzung auf Schwierigkeiten. Dippold et al. berichten über folgende typische Probleme von Projekten zur Entwicklung von Unternehmensdatenmodellen: hohe Komplexität, falsch gewählte Modellausschnitte, mangelhafte Antizipierung zukünftiger Entwicklungen und Fehlen von Migrationsszenarien.

Datenbeschaffung Ein wesentlicher Teil der betrieblichen Daten entsteht während der Durchführung betrieblicher Aufgaben und der Nutzung von Anwendungssystemen (z. B. beim Anlegen neuer Kunden, Erstellen von Rechnungen oder Ändern von Produktdaten). Darüber hinaus können Daten aus externen Quellen ergänzt werden (z. B. von Verbänden oder Marktforschungsunternehmen). In diesem Zusammenhang ergibt sich die Notwendigkeit, die organisatorische Verantwortung für die Erfassung, Bearbeitung und Pflege der Daten eindeutig festzulegen. Bei unstrukturierten Daten, z. B. Dokumenten, ergibt sich die zusätzliche Aufgabe, die Daten mit Hilfe von Metadaten zu beschreiben, um diese leicht wiederfinden zu können.

Datenspeicherung Mit der Datenspeicherung zusammenhängende Managementaufgaben umfassen die Auswahl und Bereitstellung geeigneter Speicherorte und -medien. Dabei ist sicherzustellen, dass die Sicherheit der Daten gewährleistet ist (vgl. Lerneinheiten SICHM und NOMAN), dass schnell auf die Daten zugegriffen werden kann und die Kosten für Beschaffung und Betrieb der Speichermedien akzeptabel bleiben. Mit Hilfe von Datenkomprimierung kann der Speicherbedarf reduziert werden. Bei Verwendung der Datenkomprimierung zur Datenarchivierung (insbesondere zur Archivierung historischer Datenbestände über lange Zeiträume hinweg) ist darauf zu achten, dass die zur Komprimierung und Dekomprimierung erforderlichen Plattformen (Hardware und Software) zur Verfügung stehen. Im Bereich kleiner Rechnersysteme (PCs und Workstations) reichen bereits wenige Jahre, um einen so nachhaltigen Plattformwechsel zu vollziehen, dass die zur Dekomprimierung erforderlichen Werkzeuge ohne planmäßige Maßnahmen nicht mehr verfügbar sind.

252

Administrative Aufgaben des Informationsmanagements

Hierarchical Storage Management ist eine in den 1960er Jahren von IBM entwickelte Speichertechnik, mit deren Hilfe selten genutzte Daten automatisch von schnellen, aber teuren (z. B. Magnetplatten) auf preiswertere Speichermedien mit längeren Zugriffszeiten (z. B. Magnetbänder) verschoben werden. Auf diese Weise können Kosten für Speichermedien reduziert werden, ohne dass Nutzer bei regelmäßig benötigten Daten Einbußen im Antwortzeitverhalten hinnehmen müssen. Eine Erweiterung des Hierarchical Storage Management ist das Information Lifecycle Management (vgl. Lerneinheit LEMAN).

Datensicherung Sicherung der Daten ist sowohl Aufgabe des Daten- als auch des Sicherheitsmanagements (vgl. Lerneinheit SICHM). Datensicherung umfasst die Gewährleistung von Verfügbarkeit, Vertraulichkeit und Integrität der Daten. Verfügbarkeit von Daten sicherzustellen bedeutet im Wesentlichen, für die Verfügbarkeit der Daten haltenden Systeme zu sorgen (vgl. Lerneinheit SIKON). Vertraulichkeit der Daten wird mit der Definition von Zugriffsrechten für unterschiedliche Rollen im Rahmen von Berechtigungskonzepten unterstützt. Sicherstellung der Integrität der Daten ist eine zentrale Aufgabe im Rahmen der Verfolgung der Datenqualität (vgl. den Abschnitt zur Datenqualität).

Daten-Reengineering Daten-Reengineering beschreibt den Prozess der Modifikation der Datenarchitektur oder von logischen Datenmodellen, so dass diese aktuellen Anforderungen genügen. Datenmanagement heißt, den Aufgabenträgern die Daten zur Verfügung zu stellen, mit denen ihre Informationsnachfrage gedeckt werden kann, also weder Unterversorgung noch Überversorgung zuzulassen. Im Allgemeinen haben Datenmanager nur die Unterversorgung im Blick und vernachlässigen die durch Überversorgung entstehenden Schwachstellen (z. B. Informationsüberlastung von Aufgabenträgern oder nicht unbedingt notwendige Investitionen in Hardware). Erfahrungsgemäß wächst ein Datensystem auch deshalb, weil Daten, die zur Deckung einer Informationsnachfrage nicht mehr benötigt werden, weiter geführt werden. Daraus folgt die Notwendigkeit einer permanenten Datenanalyse mit folgenden Zielen:  

nicht mehr benötigte Daten zu entfernen, um Überversorgung zu vermeiden, und zusätzlich benötigte Daten zu ergänzen, um Unterversorgung zu vermeiden.

Die Bereinigung und Aktualisierung des Datensystems ist relativ unproblematisch, solange weder die Datenarchitektur noch das logische Datenmodell der betreffenden Anwendung verändert werden muss. Dies ist z. B. der Fall, wenn lediglich einzelne Daten gelöscht werden, der Datentyp und dessen Relationen zu anderen Daten aber erhalten bleiben.

Datenmigration Datenmigration ist immer dann von Bedeutung, wenn wesentliche Komponenten der Informationsinfrastruktur ersetzt werden sollen (insbesondere die Hardwareplattform einschließlich Betriebssystem und das DBMS) bzw. wenn von einem vor-relationalen auf ein relationales Datenbanksystem übergegangen wird. Das Ablösen der Ausgangsplattform ist häufig deshalb erforderlich, weil die Weiterentwicklung und Lieferung ihrer Produkte eingestellt wurden oder weil von einem proprietären auf ein offenes System übergegangen werden soll.

Datenmanagement (DATEM)

253

Formale Migrationsziele sind die Verbesserung der Wirksamkeit und der Wirtschaftlichkeit. Ist die teilweise oder sogar vollständige Änderung der logischen oder physischen Repräsentation der Daten eines Informationssystems erforderlich, spricht man von Datenmigration. Folgende Szenarien der Datenmigration können identifiziert werden: 

 

Zusammenführen von isolierten zu integrierten Informationssystemen. Zur Vermeidung von Inkonsistenz und zur Reduzierung von Redundanz im Datensystem müssen die getrennt entwickelten und implementierten Datenbestände zusammengeführt und mit den relevanten Datenmodellen bzw. der Datenarchitektur abgestimmt werden. Ablösung proprietärer Systeme durch offene Systeme. Dies erfordert gegebenenfalls die Überführung nicht-relationaler in relationale Datenstrukturen. Einführung von Standardanwendungssoftware. Moderne Standardanwendungssoftware basiert auf offenen Systemen. Ihre Eingliederung in bestehende, meist proprietäre Systeme ist ohne Abgleich der verwendeten Datenstrukturen nicht möglich.

Business Intelligence (BI) BI wurde 1989 von der Gartner Group als Prozess definiert, mit dem aus Daten Informationen gewonnen und diese in Wissen überführt werden können. Kemper/Mehanna/Unger definieren BI als integrierten, unternehmensspezifischen, IT-basierten Gesamtansatz zur betrieblichen Entscheidungsunterstützung. Häufig wird zwischen einem engen und einem weiten BI-Begriff unterschieden. Das enge Begriffsverständnis umfasst die Zusammenstellung, Aufbereitung, Auswertung und Darstellung lediglich strukturierter Daten, vornehmlich in DW. Das weite Begriffsverständnis umfasst zusätzlich die Analyse unstrukturierter Daten. Informationssysteme, welche BI unterstützen, werden auch als analytische Informationssysteme bezeichnet, da sie die flexible Analyse von Daten erlauben.

Analyse strukturierter Daten Auf Daten in operativen Datenbanken kann mit Hilfe von Datenbanksprachen, z. B. SQL, zugegriffen werden. Einfache Auswertungen sind bereits auf diese Weise möglich. Sollen Daten flexibel aggregiert und aus unterschiedlichen Blickwinkeln analysiert werden, werden die Daten nicht in operativen Datenbanken belassen, sondern in DW geladen. Das hat verschiedene Gründe:   

Wenn gleichzeitig aus operativen und analytischen Informationssystemen auf Daten zugegriffen würde, wären die Antwortzeiten häufig zu lang. Daten sind in verschiedenen operativen Datenbanken oft unterschiedlich strukturiert, bezeichnet und in vielfältigen Formaten gespeichert. Bevor diese Daten für Analysen genutzt werden können, müssen sie in eine konsistente Form gebracht werden. Operative Datenbestände umfassen in der Regel nur unternehmensinterne Daten. Für Entscheidungen sind häufig aber auch Daten aus externen Quellen nötig.

Ein DW übernimmt zu bestimmten Zeitpunkten (z. B. ein Mal pro Tag, Woche oder Monat) Daten aus operativen und externen Datenbanken. Die Datenübernahme ist ein Schnappschuss des aktuellen Datenbestands; er wird im DW nicht fortgeschrieben, sondern durch den nächsten Schnappschuss aktualisiert. Der Prozess, mit dem Daten aus operativen Datenbanken

254

Administrative Aufgaben des Informationsmanagements

extrahiert, in eine konsistente Form transformiert und in das DW geladen werden, wird als ETL (Extract, Transform, Load) bezeichnet. Zur Informationsgenerierung in DW stehen folgende Optionen zur Verfügung (in Anlehnung an Kemper/Mehanna/Unger):  

 

Bei der freien Datenrecherche nutzen Anwender techniknahe Datenabfrage- oder Datenmanipulationssprachen, um Daten zu analysieren und in der gewünschten Form darzustellen. Ad-hoc-Analysesysteme erlauben flexible, benutzerfreundliche Untersuchungen von mehrdimensionalen Datenräumen. In diesen – auch als Data Cubes oder Hyper Cubes – bezeichneten Strukturen werden Daten in unterschiedlichen Dimensionen dargestellt, z. B. Umsatzzahlen strukturiert nach Produkten, Zeiträumen, Verkaufsregionen und Vertriebswegen. In diesen Datenräumen sind verschiedene Operationen möglich, z. B. das Aggregieren oder Aufschlüsseln von Daten in unterschiedliche Verdichtungsstufen (Roll-Up & Drill-Down) oder das Selektieren von zwei- oder dreidimensionalen Datenräumen (Slicing & Dicing). Für derartige Analysen haben Codd/Codd/Salley die Bezeichnung OLAP und Pendse/Creeth den Begriff FASMI geprägt. Data Mining beschreibt nach Chamoni/Gluchowski Verfahren, mit denen domänenunabhängig nach bisher unbekannten Zusammenhängen (Mustern) gesucht werden kann. Dazu kommen Verfahren der Statistik und der Künstlichen Intelligenz zum Einsatz. Berichtssysteme unterstützen die Zusammenstellung von Daten zu bestimmten entscheidungsrelevanten Themen. Die Daten können in den Berichten in Form von Listen oder Grafiken aufbereitet werden.

Analyse unstrukturierter Daten Der überwiegende Teil des explizit repräsentierten Wissens in einem Unternehmen liegt nicht in strukturierter Form vor, sondern in Textdokumenten, E-Mails, Präsentationen, Grafiken, Tabellenkalkulationen etc., welche in unterschiedlichen Formaten auf diversen Plattformen geführt werden. Verschiedene Untersuchungen (vgl. z. B. Feldman, Feldman et al. oder Hawking) zeigen, dass Mitarbeiter mit wissensintensiven Aufgaben 15 bis 35 % ihrer Arbeitszeit damit verbringen, nach Informationen zu suchen, aber nur in ca. 50 % der Fälle die gewünschte Information finden. Eine große Herausforderung besteht deshalb darin, sowohl strukturierte als auch unstrukturierte Daten für betriebliche Aufgaben zugänglich zu machen. Unter der Bezeichnung Enterprise Search werden Methoden des Information Retrieval genutzt, um Informationen in beliebiger Repräsentationsform zu strukturieren, mit Metadaten zu beschreiben, zu speichern, um sie leicht auffindbar zu machen und den Zugriff auf die Informationen zu organisieren. Information Retrieval unterscheidet sich von der Suche in strukturierten Datenbeständen dadurch, dass die Benutzer ihr Informationsbedürfnis nicht immer präzise formulieren können und dass über Art, Menge und Qualität der Treffer Unsicherheit besteht. Hilfsmittel des Text Mining unterstützen die Extraktion von Informationen aus Textdokumenten. Sie kommen zum Einsatz, um implizite, nicht offensichtliche oder bisher nicht bekannte Zusammenhänge zu entdecken, und daraus Schlussfolgerungen ableiten zu können. Dazu werden Verfahren des Information Retrieval, Data Mining, der Künstlichen Intelligenz, der Statistik und der Computerlinguistik verwendet (vgl. Lerneinheit MEWIM).

Datenmanagement (DATEM)

255

Metadatenmanagement Inkonsistente Daten in Informationssystemen, fehlende Grundlagen für die Erstellung von Datenarchitekturen und hohe Aufwendungen für die Integration von Daten in DW haben zu der Forderung nach Metadatenmanagement geführt. Dippold et al. nennen als Ziele des Metadatenmanagements die Beschreibung, Definition und Standardisierung der Datenobjekte eines Informationssystems bzw. eines Unternehmens. Beispiele für Metadaten zu strukturierten Daten sind Angaben zu Datenstrukturen (Elemente, Anordnung, Feldlängen, Formate etc.), Speicherorten, insbesondere bei verteilten Datenbanken oder bei redundanter Datenhaltung, Angaben zu Herkunft und Verwendung von Daten sowie zu Zugriffsrechten. Beispiele für Metadaten zu unstrukturierten Daten sind Kategorisierung bzw. Themengebiete der Daten, Schlagworte, kalendarische Erstellungs- und Änderungsdaten, Versionsnummern und Angaben zu Urhebern bzw. Bearbeitern. Data Dictionaries sind Hilfsmittel zur Verwaltung von Metadaten. Ursprünglich wurden Data Dictionaries als Kataloge zur Beschreibung von physischen Datenstrukturen und Datenfeldern in Datenbanksystemen entwickelt. Später dienten sie auch der fachlichen Definition von Entities und ihrer Beziehungen, heute werden Verwaltungssysteme für beliebige Metadaten als Data Dictionaries bezeichnet. Die zunehmende Komplexität der Metadaten hat zur Entwicklung von Metadatenmodellen (häufig als Metamodelle abgekürzt) geführt. Metadatenmodelle beschreiben die Struktur und Bedeutung von Metadaten. Viele Sprachmittel für Metadatenmodelle sind von internationalen Gremien standardisiert worden. Zu den wichtigsten Standards zählen:     

Dublin Core, von der Dublin Core Metadata Initiative beschriebene und in ISO 15836 normierte Metadaten zur Beschreibung von Ressourcen im Internet, Common Warehouse Metamodel (CWM), von der OMG beschriebenes Modell für Beschreibung, Zugriff und Austausch von Metadaten in DW, Meta Object Facility (MOF), von der OMG entwickelte Struktur zur plattformunabhängigen Definition und Verwaltung von Metamodellen, Resource Description Framework (RDF), vom World Wide Web Consortium (W3C) entwickelte Sprache zur Bereitstellung von Metadaten über Ressourcen im WWW, und XML Metadata Interchange (XMI), von der OMG entwickelte Spezifikationen für Austauschformate zwischen Softwareentwicklungswerkzeugen.

Datenqualität Mangelhafte Datenqualität kann erhebliche Konsequenzen haben. Dubletten in Kundendaten führen z. B. zu unangemessen hohem Aufwand für den Versand von Produktkatalogen sowie zu verärgerten Kunden. Fehler in Kundenadressen können zu unzustellbaren Rechnungen und zu verzögerten Einnahmen führen. Das Versäumnis, Testdaten aus operativen Datenbanken zu entfernen, verursacht fehlerhafte Kennzahlen in DW und unangemessene Entscheidungen. Kappelman schätzte den Gesamtaufwand für Suche und Korrektur von zweistelligen Jahreszahlen in Softwaresystemen vor der Jahrtausendwende, das so genannte Jahr2000-Problem, auf 375 bis 750 Milliarden US-Dollar weltweit.

256

Administrative Aufgaben des Informationsmanagements

Typische Qualitätsmerkmale für Daten sind (in Anlehnung an Naumann, Rohweder et al. und Wang/Strong):        

Relevanz und Nutzen: Daten sollen den relevanten Ausschnitt der Wirklichkeit so abbilden, dass sie die Aufgaben unterstützen können, für die sie bestimmt sind. Richtigkeit: Daten sollen die Wirklichkeit so genau abbilden, wie dies für die Aufgabenerfüllung notwendig ist. Es sollen keine falschen Daten angeboten werden. Vollständigkeit: Daten sollen die Wirklichkeit so vollständig abbilden, wie dies für die Aufgabenerfüllung notwendig ist. Es sollen keine Datenlücken bestehen. Aktualität: Daten sollen den Veränderungen der Wirklichkeit so schnell folgen, wie dies für die Aufgabendurchführung notwendig ist. Durch Angabe des Zeitbezugs soll eine Zuordnung der Daten zu unterschiedlichen Zeithorizonten möglich sein. Genauigkeit: Daten sollen in einem Detaillierungsgrad und in einer Form vorliegen, die für die relevanten Aufgaben angemessen sind. Konsistenz: Daten sollen einheitlich dargestellt und in sich widerspruchsfrei sein. Verständlichkeit: Daten sollen von den Anwendern leicht verstanden werden können. Sofern dies schwierig ist, soll die Bedeutung der Daten mit Hilfe von Metadaten erläutert werden. Verfügbarkeit: Daten sollen mit einfachen Verfahren, möglichst auf direktem Weg und in angemessener Zeit, für Befugte zugänglich sein.

Maßnahmen zur Verbesserung der Datenqualität sind u. a. Integritätsbedingungen in Datenbanken, Identifikation von Dubletten mit Hilfe von Ähnlichkeitsmaßen und Qualitätsprüfung und Fehlerkorrektur bei der Verwendung der Daten durch die Nutzer.

Aufgabenträger des Datenmanagements Datenmanagement umfasst technische und betriebswirtschaftliche Aufgaben. Von den Aufgabenträgern des Datenmanagements werden also verschiedene Kenntnisse, Fertigkeiten und Fähigkeiten gefordert (vgl. Lerneinheit STELL). Die Abdeckung dieser Anforderungen ist nur in kleinen Unternehmen durch eine Person denkbar. In größeren Unternehmen werden Aufgaben des Datenmanagements mehreren spezialisierten Aufgabenträgern zugeordnet. Folgendes Modell kann als Orientierungshilfe dienen: 





Der Datenadministrator ist für das konzeptionelle Schema des Datensystems verantwortlich (insbesondere für die Beschreibung der Datenobjekte und Datenbeziehungen, für die Abstimmung der Datenarchitektur mit den Teildatenmodellen der Projekte, für die Normalisierung der Daten und für die Methodik der Datenmodellierung). Der Datenbankadministrator ist für das interne Schema des Datensystems verantwortlich, also für alle Fragen der Implementierung von Datenbanken. Er überwacht die Datenbanken bezüglich Speicherbedarf und Zugriffsverhalten (vgl. Lerneinheit LEMAN) und führt die Reorganisation und das Redesign durch. Mehrere Anwendungssystem-Administratoren sind für die externen Schemata verantwortlich (insbesondere für den Aufbau der Dateien einschließlich der Datenkonvertierung, für das Löschen von Daten und für das Bereitstellen von Dateikopien in dem Format, in dem die Daten von Abfragesprachen benutzt werden können).

Datenmanagement (DATEM)





257

Der Datenkatalogsystem-Administrator ist für die Betreuung des Datenkatalogsystems verantwortlich (insbesondere für die technische Produktbetreuung und die Pflege der Komponentenstruktur des Datenkatalogsystems). Er stellt Werkzeuge zur Unterstützung der Nutzung des Datenkatalogsystems zur Verfügung (z. B. für die Datengenerierung, zur Unterstützung der Qualitätsprüfung und für die Datenbereitstellung). Er unterstützt damit die anderen Aufgabenträger des Datenmanagements. Unger/Kemper unterscheiden folgende Aufgabenbereiche von BI-Spezialisten. Die DW-Entwicklung beinhaltet die Entwicklung von Datenarchitekturen und -modellen, von Anwendungs- und Benutzerschnittstellen sowie die Planung und Implementierung von Berechtigungskonzepten. Der technische BI-Betrieb umfasst das Management der technischen Infrastrukturen, wie z. B. Netzwerke, Server, Betriebssysteme, Datenbanken und die Basisadministration der BI-Software. Der fachliche BI-Betrieb beinhaltet die Planung, Steuerung und Überwachung von Extraktions-, Transformations- und Ladeprozessen, die Administration von DW, die Umsetzung fachlicher Änderungen sowie die Daten- und Berichtsproduktion. Der BI-Support umfasst Benutzerschulung und -training, die Unterstützung von Endbenutzern bei Problemlösungen im Umgang mit dem DW sowie die Verwaltung von Zugriffsrechten.

Üblicherweise erfolgt die strukturorganisatorische Einordnung des Datenmanagements in die IT-Abteilung (vgl. Lerneinheit STRUK). Wegen der strategischen Bedeutung des Datensystems kann es zweckmäßig sein, das Datenmanagement aus der IT-Abteilung auszulagern und dafür entweder eine Stabsstelle der Unternehmensleitung oder eine Linienabteilung zu schaffen, die direkt an die Unternehmensleitung berichtet.

Forschungsbefunde Röthlin hat Datenqualitätsmanagement für ERP-Systeme untersucht (Literaturanalyse und zwei explorative, schriftliche Befragungen von ERP-Anbietern und -Anwendern in der Schweiz, 125 auswertbare Antworten von 500 angeschriebenen ERP-Anwendern und 50 Antworten von 111 angeschriebenen ERP-Anbietern, Untersuchungszeitraum September bis November 2003). Mehr als 80 % der Anwender und Anbieter halten Datenqualität für „highly relevant for enterprise data processing“ (159). Die Befragten sind überzeugt, dass die Bedeutung der Datenqualität weiter zunehmen wird, insbesondere wegen der unternehmensinternen Integration von Informationssystemen und dem Datenaustausch mit Kunden, Lieferanten und Kooperationspartnern. Alle Befragten sind der Meinung, dass Datenqualität in operativen Systemen gewährleistet werden muss und nicht durch Qualitätsverbesserungsmaßnahmen in DW erreicht werden kann. ERP-Anbieter und Anwender vertreten gegensätzliche Meinungen zur Bedeutung von Risiken, die sich durch Schnittstellen zu anderen Softwaresystemen (third-party systems) und durch die Nutzung unternehmensexterner Daten in ERP-Systemen ergeben können: Während Anwender die Existenz entsprechender Risiken bestätigen, äußerten sich ERP-Anbieter dazu nicht oder bestritten solche Risiken. Auf die Frage, welche die wichtigsten Aufgaben zur Erreichung einer hohen Datenqualität seien, antworteten die Befragten (geordnet nach Bedeutung, wichtigste Aufgabe zuerst): Benutzerschulung (user training), Benutzerservice (user support) und Dokumentation des ERPSystems (system documentation). Die Qualität von Daten, an denen Führungskräfte und/oder deren Mitarbeiter ein persönliches Interesse haben, oder für deren Handhabung es klar gere-

258

Administrative Aufgaben des Informationsmanagements

gelte Prozesse gibt, ist am höchsten ausgeprägt. Marketingkontaktdaten, die oft verteilt und unkoordiniert erfasst und verwaltet werden, haben die geringste Qualität. Das am häufigsten genannte Instrument zur Sicherung der Datenqualität ist die Verbesserung von Benutzerschnittstellen. Benutzer von ERP-Systemen und Prozessmanager haben den größten Einfluss auf die Datenqualität. Funktionsbereiche mit spezifischer Verantwortung für Datenqualität (z. B. „data quality stewards“) werden als ungeeignet bezeichnet. Anwender, die mehr Maßnahmen zur Verbesserung der Datenqualität ergriffen haben als andere, berichteten nicht über eine deutlich bessere Qualität ihrer Daten.

Aus der Praxis Hill/Ariyachandra/Frolick berichten, dass 50 bis 60 % der Projekte zur Einführung von Data-Warehouse-Systemen nicht zum geplanten Termin fertiggestellt werden, die Plankosten überschreiten und/oder nicht die geforderte Qualität erreichen. Auf der Grundlage von publizierten Erfahrungen mit Projekten formulieren die Autoren zehn Prinzipien, die zum Scheitern von DW-Projekten beitragen: (1) Implementierung eines DW ohne Berücksichtigung der Unternehmensziele sowie ohne Unterstützung durch Führungskräfte. (2) Implementierung eines DW für einen aktuellen, spezifischen BI-Bedarf statt zur Deckung von sich mittel- bis langfristig entwickelnden Informationsbedarfen. (3) Implementierung eines DW ohne Machbarkeitsstudie oder Pilotprojekt. (4) Entwicklung eines DW als umfangreichen, zentralisierten Datenbestand, bei gleichzeitiger Vernachlässigung anwendungsspezifischer Segmente (Data-Marts). (5) Sparsame Kommunikation über Projektziele und Projektfortschritt mit Auftraggebern und DW-Anwendern. (6) Fehlende oder mangelhafte Analyse von Kosten und Nutzen des DW. (7) Ignorieren von Warnzeichen, insbesondere mangelnde Unterstützung durch Führungskräfte und fehlende Akzeptanz der Benutzer. (8) Fällen wichtiger Entscheidungen ausschließlich durch IT-Fachleute statt durch alle an der DW-Implementierung beteiligten Interessengruppen. (9) Unterschätzung des Aufwands für das Extrahieren, Transformieren und Laden (ETL) von Daten aus operativen Systemen in das DW. (10) Beauftragung von preisgünstigen, aber wenig erfahrenen Beratern und Softwarelieferanten sowie Nutzung von unausgereiften Softwareprodukten. Wixom et al. beschreiben Erfahrungen mit dem DW-gestützten BI bei der amerikanischen Fluggesellschaft Continental Airlines. In diesem Unternehmen wird seit 1998 ein DW betrieben, ursprünglich zur Unterstützung der Preisgestaltung und zur Auswertung von Daten aus einem Vielfliegerprogramm, später auch zur Analyse von Lohn- und Gehaltsdaten sowie im Rahmen des Qualitätsmanagements bzw. der Betriebssicherheit. Das DW stellt Daten für 70 Anwendungen und 1400 Anwender in über 75 Niederlassungen weltweit bereit. Ein Team von 15 Mitarbeitern betreibt, wartet und erweitert das DW. Wixom et al. fassen folgende Empfehlungen zusammen, die aus Erfahrungen mit BI im Laufe von zehn Jahren bei Continental Airlines gesammelt wurden: Es sollten standardisierte Namenskonventionen, normalisierte Datenstrukturen und benutzerfreundliche, einfach verständliche Metadaten verwendet werden. Abgesehen von wenigen Ausnahmen (z. B. Lohn- und Gehaltsdaten oder Kreditkartennummern von Passagieren) sollten Nutzer des DW Zugriff auf alle Daten erhalten, um möglichst flexibel Analysen betreiben zu können. Daten sollten als Vermögensgegenstand des Unternehmens betrachtet und entsprechend sorgfältig behandelt werden. Mitarbeiter

Datenmanagement (DATEM)

259

eines DW-Teams sollten sowohl fundierte Datenbankkenntnisse als auch Erfahrungen in den Anwendungsbereichen haben, welche die Daten nutzen. Laut einer Untersuchung von The Data Warehouse Institute (zitiert nach Computer Zeitung 38/2007, 8) ist der Kunde das am häufigsten in Stammdaten definierte Objekt. In der Regel wird der Begriff Kunde von verschiedenen Fachabteilungen eines Unternehmens unterschiedlich verstanden. So definiert der Versand z. B. Personen und Organisationen, an die ein Produkt versendet worden ist, als Kunden, während in der Buchführung nur Rechnungsempfänger als Kunden bezeichnet werden. 13 % der Untersuchungsteilnehmer geben an, dass es in ihrem Unternehmen nur eine Definition von Kunde gibt. 50 % berichten über ca. zehn verschiedene Definitionen, 19 % über 50 oder mehr Definitionen. Eine ähnliche Begriffsvielfalt gibt es bei Stammdaten zu Produkten, Mitarbeitern und Lieferanten. Dies bedingt, dass Stammdatenmanagement in erster Linie als Aufgabe der Fach- und erst in zweiter Linie als Aufgabe der IT-Abteilungen verstanden werden muss. Dumslaff/Lempp berichten über Ergebnisse einer Studie von Capgemini (Online-Befragung von 173 IT-Führungskräften in Deutschland, Österreich und der Schweiz, keine Angaben zur Grundgesamtheit, Untersuchungszeitraum September bis Oktober 2010). Es wurden 33 Themen vorgegeben, deren Wichtigkeit für das Unternehmen in den nächsten beiden Jahren die Teilnehmer auf einer Skala von 1 (völlig unwichtig) bis 6 (sehr wichtig) bewerten sollten. Stammdatenmanagement wurde dabei auf Rang 2 (durchschnittliche Wichtigkeit 4,23) und Management der Datenqualität auf Rang 4 (durchschnittliche Wichtigkeit 4,15) platziert. Methodenverweise Informationsbedarfsanalyse (Lerneinheit INBAN); Methoden des Qualitätsmanagements (Lerneinheit MEQUA). Fallstudienverweise Lerneinheit FSLEM demonstriert die Verlagerung von Daten eines DW-Systems auf verschiedene Speicherebenen. Lerneinheit FSDOK beschreibt eine Einführungsstrategie für ein Content-Management-System. Kontrollfragen 1. Welche Argumente stützen die Behauptung, Daten seien ein wirtschaftliches Gut? 2. Worin besteht der Unterschied zwischen OLAP und Data Mining? 3. Welche Ziele werden mit Business Intelligence verfolgt? 4. Wie lässt sich Metadatenmanagement wirtschaftlich rechtfertigen? 5. Mit welchen QM-Maßnahmen kann der Forderung nach angemessener Datenqualität entsprochen werden? Quellen Becker, J. / Rosemann, M. / Schütte, R.: Grundsätze ordnungsmäßiger Modellierung. In: WIRTSCHAFTSINFORMATIK 5/1995, 435–445 Chamoni, P. / Gluchowski, P.: Analytische Informationssysteme: Business Intelligence-Technologien und -Anwendungen 3. A., Berlin/Heidelberg/New York 2006 Chaudhuri, S. / Dayal, U.: An Overview of Data Warehousing and OLAP Technology. In: ACM SIGMOD Record 1/1997, 65–74 Chen, P. P.-S.: Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned. Lecturing Notes in Computer Sciences. In: Broy, M. / Denert, E. (Hrsg.): Software Pioneers: Contributions to Software Engineering. Berlin 2002, 100–114 Chen, P. P.-S.: The Entity-Relationship Model - Toward a Unified View of Data. In: ACM Transactions on Database Systems 1/1976, 9–36 Codd, E. F. / Codd, S. B. / Salley, C. T.: Providing OLAP to User-Analysts: An IT Mandate. Ann Arbor 1993 Dippold, R. et al.: Unternehmensweites Datenmanagement. Von der Datenbankadministration bis zum Informationsmanagement. 4. A., Braunschweig/Wiesbaden 2005

260

Administrative Aufgaben des Informationsmanagements

Dumslaff, U. / Lempp, P.: Studie IT-Trends 2011. Zukunft sichern in der Krise. Berlin 2011. http://www.de.capgemini.com; Abruf 15. Juni 2011 Feldman, S.: The high cost of not finding information. 2004. http://www.kmworld.com; Abruf 10. Juni 2011 Feldman, S. et al.: The Hidden Costs of Information Work. IDC Whitepaper. Framingham 2005. http://www.interwoven.com; Abruf 10. Juni 2011 Hawking, D.: Challenges in enterprise search. In: Schewe, K.-D. / Williams, H. (Hrsg.): Proceedings of the Fifteenth Australasian Database Conference. Dunedin, New Zealand 2004, 15–24 Hill, A. / Ariyachandra, T. / Frolick, M.: 10 Principles to Ensure Your Data Warehouse Implementation is a Failure. In: International Journal of Business Intelligence Research 2/2011, 37–47 Inmon, W. H.: Building the Data Warehouse. 4. A., Indianapolis 2005 Kappelman, L. A.: Some Strategic Y2K Blessings. In: IEEE Software 2/2000, 42–46 Kemper, H.-G. / Mehanna, W. / Unger, C.: Business Intelligence - Grundlagen und praktische Anwendungen. Eine Einführung in die IT-basierte Managementunterstützung. 2. A., Wiesbaden 2006 Naumann, F.: Datenqualität. In: Informatik Spektrum 1/2007, 27–31 o.V.: Firmen gehen Management von Stammdaten oft falsch an. In: Computer Zeitung 38/2007, 8 Pendse, N. / Creeth, R.: The OLAP Report. New York 1995 Röthlin, M.: Management of Data Quality in Enterprise Resource Planning Systems. Lohmar, Köln 2010 Rohweder, J. P. et al.: Informationsqualität - Definitionen, Dimensionen und Begriffe. 2007. http://www.dgiq.de, Abruf 22. Mai 2008 Unger, C. / Kemper, H.-G.: Organisatorische Rahmenbedingungen der Entwicklung und des Betriebs von Business Intelligence – Ergebnisse einer empirischen Studie. In: Bichler, K. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 141–153 Wang, R. / Strong, D.: Beyond Accuracy: What Data Quality Means to Data Consumers. In: Journal of Management Information Systems 4/1996, 5–34 Wixom, B. H. et al.: Continental Airlines Continues to Soar with Business Intelligence In: Information Systems Management 2/2008, 102–112 Vertiefungsliteratur Baars, H. / Kemper, H.-G.: Management Support with Structured and Unstructured Data - An Integrated Business Intelligence Framework. In: Information Systems Management 2/2008, 132–148 Devlin, B.: Data warehouse: From Architecture to Implementation. 6. A., Reading 2000 Elmasri, R. / Navathe, S. B.: Grundlagen von Datenbanksystemen. 3. A., München 2002 Eppler, M. J.: Managing Information Quality. Increasing the Value of Information in Knowledge-intensive Products and Processes. Berlin, Heidelberg 2003 Loshin, D.: Master Data Management. Amsterdam 2008 Salton, G. / McGill, M. J.: Information Retrieval - Grundlegendes für Informationswissenschaftler. Hamburg et al. 1987 Stock, W. G. / Stock, M.: Wissensrepräsentation. Informationen auswerten und bereitstellen. München 2008 Vetter, M.: Aufbau betrieblicher Informationssysteme mittels pseudo-objektorientierter, konzeptioneller Datenmodellierung. 8. A., Stuttgart 1998 Informationsmaterial Data Warehousing Institute - TDWI Germany e.V. http://www.tdwi.eu Data Warehousing Institute - TDWI (international) http://tdwi.org Deutsche Gesellschaft für Informations- und Datenqualität (DGIQ) http://www.dgiq.de Dublin Core Metadata Initiative (DCMI) http://dublincore.org Information Quality at MIT http://mitiq.mit.edu Inmon, Bill http://www.inmoncif.com Metadata Standards ISO/IEC JTC1 SC32 WG2 http://metadata-stds.org Object Management Group (OMG) http://www.omg.org Storage Networking Industry Association (SNIA) http://www.snia.org Normen ISO 15836:2009 Information and documentation - The Dublin Core metadata element set ISO/IEC 19502:2005 Information technology - Meta Object Facility (MOF) ISO/IEC 19503:2005 Information technology - XML Metadata Interchange (XMI)

Lebenszyklusmanagement (LEMAN) Lernziele Sie kennen den Zweck des Lebenszyklusmanagements und Ursachen für den Veränderungsbedarf am Anwendungssystembestand. Sie können das Lebenszyklusmodell für Produkte auf Anwendungssysteme übertragen und die Varianten der Wartung in ein Lebenszyklusmodell einordnen. Sie erkennen die Bedeutung des Lebenszyklus als Planungsgrundlage für die Wartung und Neuentwicklung von Anwendungssystemen. Sie wissen, was Software Reengineering heißt und können Ziele und Aufgaben des Information Lifecycle Managements erläutern.

Definitionen und Abkürzungen Altsystem (legacy system) = Anwendungssystem, das aus Sicht einer neuen Technologie als nicht mehr dem Stand der Technik entsprechend beurteilt wird. Anwendungssystem (application system) = Teil eines Informationssystems, das zur Unterstützung einer bestimmten Aufgabe eingesetzt wird; Kombination von Anwendungsprogramm oder -programmen und zugehörigen Daten. ILM = Information Lifecycle Management. Jukebox = Speichersystem für optische und magneto-optische Speichermedien. Lebenszyklus (life cycle) = nach Phasen strukturierte Lebensdauer eines Objektes (z. B. eines Produktes oder einer Dienstleistung). Lebenszyklusmodell (life cycle model) = geordnete Menge von Phasen, die ein Produkt oder eine Dienstleistung in bestimmter Anordnung durchläuft. RAID = redundant array of inexpensive disks; redundant array of independent disks; Speichersystem zur Datenspiegelung, das über mehrere Festplatten zur automatischen Datenspeicherung verfügt. Reengineering = zusammenfassende Bezeichnung für Reverse Engineering und Restrukturierung. Reverse Engineering = Umkehrung des Entwurfs- und Entwicklungsprozesses, d. h. Rückführung eines physischen Modells in ein logisches Modell, von dem aus das physische Modell erneuert wird. Technologielücke (technology gap) = Abstand zwischen der technologisch möglichen Qualität und der tatsächlichen Qualität eines Produkts oder einer Dienstleistung, der durch die Technologieentwicklung verursacht wird. Wartbarkeit (maintainability) = Eigenschaft eines Objekts (z. B. eines Anwendungsprogramms), an veränderte Anforderungen anpassbar zu sein. Wartung (maintenance) = Erhaltung oder Wiederherstellung der Funktionsfähigkeit oder der Leistungsfähigkeit von Betriebsmitteln.

262

Administrative Aufgaben des Informationsmanagements

Zweck des Lebenszyklusmanagements Lebenszyklusmanagement befasst sich mit der Planung, Überwachung und Steuerung von Objekten über deren gesamte Lebensdauer hinweg. Während Vorgehensmodelle (vgl. Lerneinheit VOMOD) die Phasen der Produktentwicklung bis zur Installierung bzw. Inbetriebnahme fokussieren, konzentriert sich das Lebenszyklusmanagement auf die Phasen nach der Inbetriebnahme (vgl. den Abschnitt Lebenszyklusmodell). Die Verwendung der Bezeichnung Lebenszyklusmanagement ist in Literatur und Praxis nicht einheitlich. Beispielsweise wird diese Bezeichnung auch für die traditionelle Phasengliederung im Softwareentwicklungsprozess verwendet, die sich von der hier verwendeten Sichtweise wesentlich unterscheidet. Diese geht von einer quasi natürlichen zeitlichen Entwicklung aus (im Unterschied zu den künstlichen Phasen im Softwareentwicklungsprozess) und verfolgt den Zweck einer aktiven Beeinflussung oder Steuerung des betreffenden Objekts (z. B. Produkt oder Dienstleistung) über den Zeitverlauf unter Kosten- und Nutzungsgesichtspunkten. Theoretische Grundlage für Aussagen des Lebenszyklusmanagements bildet die Lebenszyklustheorie. Diese diente zunächst als Instrument zur Analyse des internationalen Handels (vgl. z. B. Posner) und später zur Analyse der dynamischen Entwicklung von Produkten auf Märkten (vgl. z. B. Polli/Cook) und wird im Marketing eingesetzt. Die Lebenszyklustheorie für Produkte wurde von anderen Disziplinen aufgegriffen und auf deren Anwendungsbereiche übertragen. Objekte des Lebenszyklusmanagements können z. B. Hardware, Software, Daten, Technologien oder Organisationsformen sein. In der Wirtschaftsinformatik wurde sie zunächst für die Planung, Überwachung und Steuerung von Informations- und Anwendungssystemen unter Kostengesichtspunkten verwendet. Sie ist eine Alternative zur bzw. Ergänzung der projektorientierten Vorgehensweise, weil Lebenszyklusmanagement im Unterschied zum Projektmanagement nicht zeitlich begrenzt, sondern eine permanente Aufgabe des Informationsmanagements ist. In dieser Lerneinheit wird das Lebenszyklusmanagement für Anwendungssysteme und Daten erläutert.

Veränderungsbedarf am Anwendungssystembestand Anwendungssysteme kommen durch den Abschluss der Installierung und die damit mögliche produktive Nutzung in den Anwendungssystembestand. Sie verlassen den Anwendungssystembestand auf Grund der Entscheidung, sie zu entsorgen, durch eine Neuentwicklung zu ersetzen oder zu sanieren. Zwischen dem Beginn der produktiven Nutzung und der Entsorgung, dem Ersatz oder der Sanierung wird der Anwendungssystembestand durch Wartung verändert. Veränderungsbedarf am Anwendungssystembestand entsteht laufend durch die Weiterentwicklung der Basiskomponenten von Informationssystemen, nämlich I&K-Technologien, Aufgaben und Personal. 

Technologieentwicklung: Anwendungssysteme werden auf einem zum Zeitpunkt ihrer Herstellung bestehenden, häufig bereits zu diesem Zeitpunkt überholten Stand der Technik konstruiert und implementiert. Da sie bestenfalls auf diesem Stand bleiben, sich die Technologien aber weiterentwickeln, entsteht eine über der Zeit größer werdende Technologielücke. Sie macht sich durch mangelnde Qualität – im Vergleich zu der mit neuer

Lebenszyklusmanagement (LEMAN)





263

Technologie erreichbaren Qualität – bemerkbar (z. B. geringere Benutzbarkeit, höhere Transaktionszeiten). Aufgabenentwicklung: Durch betrieblich gewollte oder durch extern bedingte Änderungen der betrieblichen Aufgaben bzw. der Organisation der Aufgaben (z. B. statt funktionaler Orientierung die Orientierung an Geschäftsprozessen) entstehen neue Anforderungen an Funktionalität und Leistung der Technologien (z. B. Unterstützung kooperativen Arbeitens). Personalentwicklung: Neue Anforderungen an Funktionalität und Leistung der Technologien entstehen auch durch Personalveränderungen (z. B. höheres Qualifikationsniveau, größere Ansprüche an die Ergonomie des Arbeitsplatzes) und Änderungen des Informationsverhaltens (vgl. Lerneinheit INVER).

Jede verwendete Technologie war einmal neue Technologie; der Aktualitätscharakter einer Technologie ist grundsätzlich vergänglich. Wenn eine Technologie „besser“ ist oder als besser angesehen wird als eine derzeit verwendete (z. B. bezüglich Wartbarkeit), wird diese als neu, die andere als alt empfunden. Da die Anbieter in neue Technologien erheblich investieren und mit den wirklichen oder behaupteten Schwächen der verwendeten Technologien argumentieren, werden Technologien „künstlich gealtert“ (vgl. Lerneinheit TECHM).

Lebenszyklusmodell Üblicherweise verwenden Lebenszyklusmodelle sieben bis acht oder nur vier Phasen. Werden sieben bis acht Phasen verwendet, wird die Produktentwicklung in den Lebenszyklus einbezogen. Werden vier Phasen verwendet, wird der Lebenszyklus erst ab der Installierung betrachtet. Da es sich bei den Phasen der Produktentwicklung streng genommen nicht um Lebenszyklen handelt, ist die zweite Betrachtung zutreffender und wird hier verwendet. Folgende Phasen werden unterschieden (in Klammern synonyme Kurzbezeichnungen): Systemeinführung (Einführung), zunehmende Systemnutzung (Wachstum), stagnierende Systemnutzung (Sättigung oder Reife) und abnehmende Systemnutzung (Rückgang); Testen und Warten sind in diese vier Phasen eingebunden. 



Systemeinführung: Nach der Installierung steht das Anwendungssystem im Allgemeinen nicht in vollem Umfang für den produktiven Betrieb zur Verfügung. Funktions-, Leistungs- und Integrationstests werden durchgeführt; die Benutzer werden geschult. Wird schrittweise installiert, ergibt sich eine zunächst nur geringe, aber wachsende Nutzung. Das Auftreten und Beseitigen von Fehlern während der Tests und in der ersten Zeit des produktiven Betriebs beeinflussen ebenfalls die Nutzungsintensität. Während Basisanwendungen mit Standardanwendungssoftware die Phase der Systemeinführung relativ schnell durchlaufen, erstreckt sie sich bei innovativen Anwendungen mit Individualsoftware über einen längeren Zeitraum. Zunehmende Systemnutzung: Diese Phase ist dadurch gekennzeichnet, dass alle Tests abgeschlossen und die während der Systemeinführung aufgetretenen Fehler beseitigt sind. Das Anwendungssystem kann mit allen geplanten Funktionen produktiv genutzt werden. Soweit es sich nicht um Basisanwendungen handelt, die im Allgemeinen einen abgeschlossenen Benutzerkreis haben, nimmt durch weitere Benutzer die Nutzung zu. Auch im abgeschlossenen Benutzerkreis kann eine Zunahme der Nutzung dadurch ein-

264





Administrative Aufgaben des Informationsmanagements

treten, dass sich mit dem Erkennen der Zweckmäßigkeit und der Funktionsfähigkeit des Anwendungssystems zusätzliche Nutzungsmöglichkeiten ergeben. Stagnierende Systemnutzung: In dieser Phase erreicht die Nutzung ihr Maximum. Danach können weder weitere Benutzer das Anwendungssystem sinnvoll verwenden, noch können die bisherigen Benutzer zusätzliche Nutzungsmöglichkeiten erkennen. Die nach Erreichen des Maximums einsetzende Stagnation und die nachfolgende Verminderung der Nutzung sind beispielsweise darauf zurückzuführen, dass das Anwendungssystem nicht mehr dem Stand der Technik entspricht, dass neue Anwendungssysteme mit ähnlicher Funktionalität in Betrieb genommen werden oder dass die unterstützten Aufgaben in ihrem Umfang zurückgehen. Abnehmende Systemnutzung: Der Rückgang der Nutzung, der bereits in Phase 3 eingesetzt hat, setzt sich bis zur Außerdienststellung fort.

Abbildung LEMAN-1 zeigt das Lebenszyklusmodell mit den vier Phasen und einem beispielhaften Verlauf der Systemnutzung (z. B. gemessen mit der Anzahl der Transaktionen), des Systemnutzens und der Systemkosten (vgl. dazu die Forschungsbefunde). Die in der Abbildung vorgenommene Trennung zwischen den Phasen bedeutet nicht, dass die Phasen in der Wirklichkeit nicht eine gewisse zeitliche Überlappung und Iterationen haben können.

Einführung Wachstum Sättigung/Reife Rückgang Systemnutzung

Systemnutzen

Systemkosten Abb. LEMAN-1: Lebenszyklusmodell

Wartungsmaßnahmen Abbildung LEMAN-1 zeigt den idealtypischen Verlauf der Systemnutzung, des Systemnutzens und der Systemkosten, wie er bei systematisch geplanten Lebensphasen erwartet werden kann. Dies gilt vor allem für die Systemkosten, bei denen eine den Phasen angepasste Wartung unterstellt wird, etwa wie folgt: 



In der Einführungsphase werden durch Korrekturwartung Fehler beseitigt und Maßnahmen zur Vermeidung von Fehlern durchgeführt. Ziel der Korrekturwartung ist es, die volle Funktions- und Leistungsfähigkeit herzustellen und zu erhalten. Die Korrekturwartung sollte in der Einführungsphase abgeschlossen sein, muss aber in allen Phasen bei Bedarf fortgeführt werden. In der Wachstumsphase wird Anpassungswartung durchgeführt, wenn sich die Anforderungen der Aufgaben oder der Aufgabenträger ändern. Jede Anpassungswartung wird als Projekt organisiert. Die Problematik der Anpassungswartung besteht darin, dass erfahrungsgemäß jede Anpassung zu mehr Komplexität und damit zu einer Verschlechterung der Wartbarkeit führt. Perfektionswartung wird in der Wachstumsphase vermieden.

Lebenszyklusmanagement (LEMAN)

 

265

In der Sättigungs- oder Reifephase werden Funktionen und Leistungen durch Perfektionswartung verbessert, um die Phase der Reife und damit den erzielbaren Nutzen zu erhöhen. Anpassungswartung wird in der Sättigungs- oder Reifephase vermieden. Die Rückgangsphase kann weder durch Anpassungswartung noch durch Perfektionswartung nachhaltig beeinflusst werden. Derartige Wartungsmaßnahmen sollen nicht mehr durchgeführt werden; Korrekturwartung ist erforderlich.

Realtypisch liegt häufig folgende Situation vor: Mit zunehmender Lebensdauer steigen die Wartungskosten, so dass die Systemkosten nicht sinken, sondern sogar steigen und möglicherweise größer als der Systemnutzen sind.

Verwendung des Lebenszyklusmodells Für die Planung, Überwachung und Steuerung des Anwendungssystembestands wird das Lebenszyklusmodell wie folgt verwendet: 

 





Wartung, Sanierung und Entsorgung sind nicht mehr „Anhängsel“ der Entwicklungsprojekte, sondern verlangen selbst methodische Grundlagen zu ihrer Bearbeitung. Entsorgung bedeutet, dass wertvolle, wiederverwendbare Komponenten in das Nachfolgesystem übernommen werden (Wiederverwendung). Jeder Phase wird planmäßig ein bestimmter Zeitraum zugeordnet, in dem sich jedes Anwendungssystem bezüglich Systemnutzung, Systemnutzen und Systemkosten in einem definierten Zustand befindet. Jeder Phase werden bestimmte Tätigkeiten zugeordnet, insbesondere die verschiedenen Wartungsarten. Damit können diese Tätigkeiten geplant werden, und es können Planwerte über die Systemnutzung, den Systemnutzen und die Systemkosten vorgegeben werden. Alle Phänomene, für die Planwerte bestehen, können überwacht und gesteuert werden. Das Phasenkonzept der Systementwicklung (vgl. Lerneinheit VOMOD) wird um das Phasenkonzept der Systemnutzung ergänzt, so dass insgesamt ein Lebenszyklus – von der Produktidee bis zur -entsorgung – besteht. Für die Erreichung der bei der Entwicklung verfolgten Ziele hat dies den Vorteil, dass organisatorische und methodische Maßnahmen eingesetzt werden können, die auch geplante Zustände und Ereignisse während der Systemnutzung explizit berücksichtigen (z. B. solche, welche die Wartbarkeit positiv beeinflussen). Die Verwendung des Lebenszyklusmodells hat eine positive Auswirkung auf das Verantwortungsbewusstsein der Entwickler. Sie gewinnen eine andere Einstellung zum Produkt, wenn sie nicht nur zum Zeitpunkt der Installierung ihre Arbeitsergebnisse verantworten müssen, sondern auch für den Zeitraum der Systemnutzung. Wartbarkeit wird zum Bestandteil des Projektauftrags und liegt nicht mehr „nach der Installierung“. Die Entwickler sind leichter für eine zweckmäßige Einbindung der zukünftigen Benutzer zu gewinnen. Das Verantwortungsbewusstsein der Fachabteilungen kann durch die Planung und Überwachung des Lebenszyklus gesteigert und eine bessere Definition der geforderten Funktionen und Leistungen kann erreicht werden.

Das Lebenszyklusmodell ist vor allem ein Instrument, mit dem das Problem der ausufernden Wartung in den Griff zu bekommen ist. Neuentwicklung oder Sanierung werden in Abhän-

266

Administrative Aufgaben des Informationsmanagements

gigkeit vom Verlauf der Systemkosten geplant. Sind die geplanten Wartungskosten ausgeschöpft, ist dies ein Auslöser für Neuentwicklung oder Sanierung. Bei der Entscheidung über Neuentwicklung oder Sanierung sind gründliche Vergleichsuntersuchungen in jedem Einzelfall erforderlich. Im Folgenden wird auf die Sanierung näher eingegangen.

Software Reengineering Die praktische Bedeutung des Software Reengineerings ergibt sich aus der Tatsache, dass im Anwendungssystembestand erhebliche, oft nicht bezifferbare Investitionen stecken, die möglichst – zumindest teilweise – erhalten bleiben sollen (so genannter Investitionsschutz). Als Investitionsschutz kann entweder ein nur oberflächliches Reengineering in Form der Restrukturierung oder ein umfassendes Reverse Engineering erfolgen. Mit Restrukturierung werden die Maßnahmen bezeichnet, mit denen einem schlecht- oder unstrukturierten Programm eine neue Struktur gegeben wird. Primäres Ziel der Restrukturierung ist es, Lesbarkeit und Verständlichkeit des Programms zu erhöhen und damit die Wartbarkeit zu verbessern und die Wiederverwendung zu ermöglichen. Beispiele für Restrukturierung sind die Zerlegung eines Programms in mehrere Module, die Auslagerung mehrfach auftretender Codeteile in eine Methode oder die Kapselung eines Altsystems mit einer neuen Schnittstelle, so dass die Funktionen des Altsystems auch in einer modernen Softwarearchitektur nutzbar bleiben. Es gibt zahlreiche Werkzeuge, die Restrukturierung unterstützen. Reverse Engineering umfasst alle Maßnahmen, mit denen aus einem gegebenen Programmcode „rückwärts“ eine Dokumentation des Programmentwurfs bzw. der Programmspezifikation erzeugt wird. Von dem wiedergewonnenen Entwurf bzw. der Spezifikation ausgehend, wird „vorwärts“ ein neuer Programmcode erzeugt, wobei alle dem Stand der Technik entsprechenden Methoden und Werkzeuge verwendet werden (Forward Engineering). Welche der beiden Formen des Reengineerings geeigneter ist, hängt primär davon ab, welcher Zweck oder welche Zwecke mit welchen Zielen mit einem Reengineering-Projekt verfolgt werden.

Information Lifecycle Management Nach Angaben von Kanakamedala/Kaplan sinken die Preise für die Beschaffung von Speichermedien kontinuierlich um ca. 30 % jährlich, gleichzeitig steigen die Kosten für die Datenspeicherung in Unternehmen pro Jahr um ca. 15 bis 20 %. Dies liegt an stark wachsenden Datenmengen bedingt durch zunehmende Automatisierung betrieblicher Aufgaben, komplexere Softwaresysteme sowie steigende rechtliche Anforderungen an die Datenhaltung (vgl. Lerneinheit RECHT). Die Kosten der Datenspeicherung umfassen neben den Hard- und Softwarekosten für Speichersysteme auch Kosten für Administration der Datenträger, für Datensicherung und Datenspiegelung sowie für Räume, in denen die Datenträger aufbewahrt werden. Die Vollkosten der Datenhaltung betragen ca. das vier- bis achtfache der Beschaffungskosten der Datenträger. Eine Möglichkeit, Kosten der Datenspeicherung zu senken, ist das Hierarchical Storage Management (vgl. Lerneinheit DATEM). Eine Erweiterung des Hierarchical Storage Management ist das so genannte Information Lifecycle Management (ILM), eine Bezeichnung,

Lebenszyklusmanagement (LEMAN)

267

die unzutreffend ist, da nicht Informationen, sondern Daten Gegenstand dieses Konzepts sind. Da sich der Begriff ILM in Theorie und Praxis aber durchgesetzt hat, wird er hier verwendet. ILM bezeichnet die systematische Verwaltung von Daten über deren gesamten Lebenszyklus hinweg. Das primäre Ziel des ILM ist, möglichst geringe Speicherkosten bei akzeptablen Zugriffszeiten auf die Daten zu realisieren. Welche Zugriffszeiten akzeptabel sind, wird in Serviceebenen-Vereinbarungen (vgl. Lerneinheit SEVER) festgelegt. Darüber hinaus soll gewährleistet werden, dass Sicherheitsanforderungen (z. B. Zugriffsrechte) und rechtliche Bestimmungen (z. B. Aufbewahrungsfristen oder Datenschutzbestimmungen) über den gesamten Lebenszyklus von Daten eingehalten werden. Da die Erfüllung von Sicherheitsanforderungen Gegenstand der Lerneinheit SICHM ist und die Beachtung rechtlicher Anforderungen in den Lerneinheiten GOVER und RECHT behandelt wird, werden diese hier nicht erläutert. Kosten für die Speicherung von Daten können gesenkt werden, indem die Daten auf preisgünstigen Speichermedien gehalten oder – wenn für den produktiven Betrieb nicht mehr erforderlich – gelöscht werden. Im ILM werden drei Ebenen der Datenspeicherung unterschieden, die mit Online, Nearline und Offline bzw. Archiv bezeichnet werden.   

Häufig genutzte Daten werden online oder in RAID-Systemen gehalten (Online-Ebene), weniger häufig genutzte Daten werden komprimiert auf Datenservern oder auf optischen Medien in Jukeboxes gespeichert (Nearline-Ebene), selten benötigte Daten werden auf Magnetbändern oder optischen Medien archiviert (Offline-Ebene).

Während die Zugriffszeiten auf der Online-Ebene im Vergleich zu den beiden anderen Ebenen kurz sind, ist der Beschaffungspreis pro Speichereinheit für die Online-Ebene relativ hoch. Durch Verlagerung der Daten auf Medien der anderen Ebenen können Kosten der Datenspeicherung gesenkt werden und es kommt nur in seltenen Fällen zu Wartezeiten beim Zugriff auf die Daten. Matthesius/Stelzer beschreiben die Aufgaben des ILM mit einem Phasenmodell. Ein auf dieser Grundlage entwickeltes Phasenmodell ist in Abbildung LEMAN-2 dargestellt. Analyse der IS-Architektur: Ziel der ersten Phase ist, Informationen für die Verlagerung von Daten zu erheben, die aus der IS-Architektur (vgl. Lerneinheit ARCHI) ermittelt werden können. In dieser Phase werden Datenbestände identifiziert, die für eine Verlagerung in Frage kommen. Da die Ermittlung akzeptabler Zugriffszeiten auf die Daten nur aus der Perspektive der Anwendungen beurteilt werden kann, die diese Daten nutzen, müssen auch Anwendungssysteme sowie deren Verbindungen untereinander identifiziert und beschrieben werden. Beschreibung relevanter Datenbestände: In der zweiten Phase werden die Datenbestände beschrieben, die auf andere Speichermedien verlagert werden können. Bei kleinen Datenbeständen steht der Aufwand für Klassifizierung und Verlagerung in keinem angemessenen Verhältnis zur Kostensenkung, die durch die Nutzung preisgünstigerer Speichermedien erreicht werden kann. Wirtschaftlich sinnvoll ist die Verlagerung von großen und/oder schnell wachsenden Datenbeständen, z. B.

268

     

Administrative Aufgaben des Informationsmanagements

Verbindungsdaten von Telekommunikationsanbietern, Abrechnungsdaten von Energieversorgern, Transaktionsdaten von Banken, Produktdaten von Automobilzulieferern, Video- und Audiodateien von Anbietern sozialer Netzwerke oder digitale Bilderarchive von Krankenhäusern.

Klassifizierung und Verlagerung von Daten sollen weitgehend automatisiert erfolgen. Da nicht alle dazu notwendigen Informationen in maschinenlesbarer Form vorliegen, werden in dieser Phase Nutzer und Administratoren der Anwendungssysteme als mögliche Interviewpartner ermittelt. Beschreibung relevanter Datenbestände

Klassifizierung der Daten

Ermittlung der Datenbestände

Ermittlung der Größe von Datenbeständen

Festlegung von Klassifizierungskriterien

Verlagerung zur Online-Ebene

Ermittlung der Anwendungssysteme

Ermittlung des Wachstums von Datenbeständen

Festlegung von Messmethoden und -größen

Verlagerung zur Nearline-Ebene

Beschreibung der Verbindungen

Ermittlung der Nutzer und Administratoren

Erhebung von Messwerten

Verlagerung zur Offline-Ebene

Interpretation und Ergänzung der Messwerte

Löschung

Analyse der IS-Architektur

Verlagerung der Daten

Abb. LEMAN-2: Phasenmodell des ILM (Quelle: nach Matthesius/Stelzer)

Klassifizierung der Daten: In der dritten Phase werden Kriterien festgelegt, mit denen die Daten klassifiziert werden. Die Klassifizierung ist Grundlage für die Entscheidung, auf welcher Ebene die Daten gespeichert bzw. ob sie gelöscht werden sollen. Als Klassifizierungskriterium kommt die erwartete Häufigkeit zukünftiger Zugriffe auf die Daten in Frage. Da die erwartete Häufigkeit nicht direkt ermittelt werden kann, können Häufigkeit und Zeitpunkte der Zugriffe auf die Daten in der Vergangenheit als Hilfsgrößen verwendet werden. Dies beruht auf der Annahme, dass sich die bisherige Nutzung der Daten in Zukunft in ähnlicher Form fortsetzen wird. Daten, auf die häufig zugegriffen wird, kommen für die OnlineEbene in Frage; Daten, die selten benötigt werden, sind für die Nearline-Ebene geeignet und Daten, auf die nur in Ausnahmefällen zugegriffen wird, die aber nicht gelöscht werden dürfen, werden auf der Offline-Ebene gespeichert, d. h. archiviert. Die Ermittlung der Zugriffszeitpunkte dient dazu, Daten, auf die früher häufig, in letzter Zeit aber nur noch selten

Lebenszyklusmanagement (LEMAN)

269

zugegriffen wurde, von solchen Daten zu unterscheiden, auf die in jüngster Zeit häufig zugegriffen wurde. Im Anschluss werden Messmethoden und -größen festgelegt (vgl. Lerneinheit KENNZ) und entsprechende Messwerte erhoben. Unter anderem ist festzulegen, mit welchem Gewicht Zugriffshäufigkeiten und -zeitpunkte in die Ermittlung der Kennzahlen zur Verlagerung der Daten eingehen. Viele Standardsoftwaresysteme (z. B. Datenbank-, DataWarehouse-, Dokumenten- und Content-Management- sowie einige Betriebssysteme) protokollieren Zugriffshäufigkeit und -zeitpunkte, so dass diese Werte für die Klassifizierung der Daten zur Verfügung stehen. Allerdings kann die Klassifizierung nicht vollautomatisch erfolgen, da verschiedene für die Verlagerung von Daten notwendige Informationen in der Regel nur von Nutzern oder Administratoren der Datenbestände bzw. Anwendungssysteme erfragt werden können. Dazu gehören   

Serviceebenen-Vereinbarungen (vgl. Lerneinheit SEVER), die es – trotz seltener oder lange zurückliegender Zugriffe – erforderlich machen, Daten online zu halten, rechtliche Anforderungen (vgl. Lerneinheit RECHT), die eine Löschung verbieten, obwohl im Untersuchungszeitraum nicht auf die Daten zugegriffen wurde oder Kenntnisse der Nutzer oder Administratoren über die zukünftige Nutzung von Daten (z. B. Daten, die bisher nicht oder nur selten genutzt wurden, die aber für geplante Aufgaben in naher Zukunft benötigt werden).

Deshalb müssen die automatisch erhobenen Messwerte ergänzt und interpretiert werden, bevor Entscheidungen über die Verlagerung von Daten getroffen werden können. Verlagerung der Daten: In der vierten Phase werden Daten auf verschiedene Speichermedien verlagert. Daten, auf die häufig zugegriffen wird, verbleiben entweder online oder werden dahin zurück verlagert. Daten, auf die in längeren Abständen zugegriffen wird, deren Speicherung auf der Online-Ebene aber wirtschaftlich nicht sinnvoll ist, werden auf Nearline-Storage-Systemen gespeichert. Daten, auf die voraussichtlich für längere Zeit nicht mehr zugegriffen wird, deren Aufbewahrung aber notwendig ist, werden auf Archivierungssysteme verlagert. Nicht mehr benötigte Daten werden gelöscht. Für die Umsetzung des ILM ist das Datenmanagement (vgl. Lerneinheit DATEM) zuständig.

Forschungsbefunde Zarnekow/Scheeg/Brenner berichten über Fallstudien zur Ermittlung der Lebenszykluskosten (Interviews und Workshops zu 30 IT-Anwendungen mit Anwendungsprojektleitern und Systemverantwortlichen sowie Mitarbeitern des IT-Controlling in zwei deutschen Großunternehmen und einem Schweizer Ministerium, Untersuchungszeitraum nicht angegeben). Ziel der Fallstudie war es, zu ermitteln, wie sich die Gesamtkosten von IT-Anwendungen auf die Phasen des Lebenszyklus der Anwendungen verteilen. Die Autoren gliedern den Lebenszyklus von IT-Anwendungen in folgende Phasen und Aufgaben:   

Planung (Projektplanung, Grobkonzept, Prototyp), Erstentwicklung (Fach- und DV-Konzept, Systemdesign, Codierung, Integration, Test, Installation/Einführung), Produktion (Schulung, laufender Betrieb, korrigierende Wartung, Anwendungssupport),

270

 

Administrative Aufgaben des Informationsmanagements

Weiterentwicklung (Fach- und DV-Konzept, Systemdesign, Codierung, Integration, Test, Installation/Einführung) und Außerbetriebnahme (Entsorgung physischer Komponenten, Datensicherung für Folgeverwendung, Datenmigration).

Ermittelt wurden sämtliche einer Anwendung direkt zurechenbare Hardware-, Software- und Personalkosten. Kosten für mehrfach genutzte Infrastrukturkomponenten (z. B. Middleware und Datenbanken) wurden den Anwendungen anteilig zugeordnet. Die Kosten für die Außerbetriebnahme waren in den meisten Fällen nicht bekannt, da sich die Anwendungen zum Untersuchungszeitraum noch in Produktion befanden. Da die absolute Höhe der Kosten für die anteilige Berechnung der Kosten der Phasen an den gesamten Lebenszykluskosten nur bedingt geeignet war, wurden die ermittelten Istkosten für eine angenommene Gesamtproduktionsdauer von fünf Jahren normiert. Es wurden nur die 16 Anwendungen in die Berechnung einbezogen, für die die Istkosten vollständig erhoben werden konnten. Dabei wurden folgende Erkenntnisse gewonnen: 





Kosteninformationen waren meist nur mit vielen Lücken und Annahmen rekonstruierbar. Die Kosten der Erstentwicklung ließen sich in der Regel am exaktesten ermitteln. Die Qualität der verfügbaren Kosteninformationen war insbesondere im Bereich der Produktionskosten gering. Eine Lebenszyklusbetrachtung von IT-Anwendungen existierte in den beteiligten Unternehmen nicht. Der Anteil einmaliger Kosten (Planung und Erstentwicklung) an den gesamten Lebenszykluskosten lag zwischen 4 und 40 % (Durchschnitt 21 %), der Anteil wiederkehrender Kosten (Produktion und Weiterentwicklung) zwischen 60 und 96 % (Durchschnitt 79 %). Bei IT-Anwendungen mit einem geringen Anteil einmaliger Kosten waren die Weiterentwicklungskosten im Vergleich zu den Erstentwicklungskosten sehr hoch. Viele dieser Anwendungen wurden vor dem vollständigen Abschluss der Erstentwicklungsarbeiten oder ohne ausreichenden Test in Produktion genommen. Entwicklungsleistungen und Fehlerbehebungen, die eigentlich Teil der Erstentwicklung sind, fielen erst nach der Inbetriebnahme an und erhöhten die Kosten der Weiterentwicklung und Produktion.

In einer Studie der Lünendonk GmbH zum ILM (Interviews mit IT-Führungskräften in 30 deutschen Unternehmen mit mehr als 1.000 Mitarbeitern, darunter 13 DAX-Unternehmen, Untersuchungszeitraum 2007) gaben 27 Unternehmen an, bereits mit der Einführung von ILM begonnen zu haben; ein Unternehmen plante die Einführung; zwei weitere Unternehmen hatten zwar Interesse daran, ILM einzuführen, aber noch keine konkreten Pläne. Die Teilnehmer wurden gebeten, die drei wichtigsten IT-Projekte zu kategorisieren. Die fünf Kategorien mit den meisten Nennungen waren: ERP und Business-Anwendungskonsolidierung (51,9 %), SAP-Projekte (37 %), Enterprise Content Management, Archivierung und Datenmanagement (29,6 %), Storage- und Datenkonsolidierung (25,9 %) sowie Standardisierung/Vereinheitlichung/Service-Management (25,9 %). Die drei wichtigsten, mit ILM verfolgten Ziele waren Kostenreduktion (1,5), bessere Erfüllung gesetzlicher und regulatorischer Anforderungen (1,9) sowie bessere Unterstützung der Geschäftsprozesse (1,9). Die Angaben in Klammern symbolisieren die durchschnittliche Bewertung der Ziele auf einer Skala von 1 (sehr wichtig) bis 4 (unwichtig). Von den in den Unternehmen eingeführ-

Lebenszyklusmanagement (LEMAN)

271

ten Lösungen für ILM schaffen automatisierte E-Mail-Archivierungs-Systeme, die E-MailAnhänge verwalten, das Datenvolumen reduzieren und Compliance-Anforderungen erfüllen, den größten Nutzen. 45 % der Unternehmen setzten solche Systeme ein.

Aus der Praxis Im Rahmen der Übernahme der Dresdner Bank durch die Commerzbank wurden Daten von drei Millionen früheren Dresdner-Bank-Kunden in zwei Schritten am 9./10. April 2011 und am Osterwochenende vom 22. bis 25. April 2011 auf ein gemeinsames neues Informationssystem der Commerzbank übertragen. Im Anschluss wurden Informationssysteme der Privatkundensparte der Dresdner Bank abgeschaltet. Die Commerzbank gab an, dadurch die ITKosten um 400 Millionen Euro jährlich reduzieren zu können. Als Grund dafür, dass die Commerzbank sich mit der Integration der IT-Systeme seit der Übernahme der Dresdner Bank im Januar 2009 mehr als 15 Monate Zeit ließ, wurde die „Komplexität der Datenübertragung“ angegeben (F.A.Z. vom 20. April 2011, 17). Born et al. verdeutlichen die Komplexität des ILM am Beispiel der E-Mail-Archivierung. Da ein großer Teil der geschäftlichen Kommunikation per E-Mail abgewickelt wird, sind Unternehmen (z. B. auf Grund steuerrechtlicher Regelungen) verpflichtet, E-Mail-Nachrichten lückenlos zu dokumentieren. Dies gilt insbesondere, wenn Rechtsgeschäfte (z. B. Kaufverträge) durch Willenserklärungen per E-Mail zustande kommen. Für diese Nachrichten gelten die gleichen Rechtsvorschriften wie für traditionelle Geschäftspost (vgl. die Lerneinheiten RECHT und VERMA). Allerdings haben nicht alle E-Mails rein geschäftlichen Inhalt, vielmehr werden in vielen Unternehmen E-Mail-Systeme auch für private Kommunikation verwendet. Dafür gelten grundsätzlich die Regeln des Datenschutzes sowie des Fernmeldegeheimnisses, sofern der Arbeitgeber die private Nutzung des E-Mail-Systems gestattet hat. Da für die Archivierung, Sicherung und Löschung von geschäftlichen und privaten von E-Mails unterschiedliche Regeln gelten, müssen E-Mails inhaltlich kategorisiert und gegebenenfalls unterschiedlich behandelt (d. h. archiviert, geschützt bzw. gelöscht) werden. Bei der Anwendung des ILM auf E-Mail-Systeme sind folgende Fragen zu beantworten:        

Welche gesetzlichen Vorschriften, Grundsätze und Normen sind bei der Speicherung und Löschung von E-Mails zu beachten? Gibt es eine Richtlinie für den Umgang mit privaten E-Mails und verhalten sich die Mitarbeiter danach? Wie wird sichergestellt, dass die Regeln zum Umgang mit E-Mails unterschiedlicher Kategorien (z. B. vertragsrechtlich relevante, rechtlich irrelevante und private E-Mails) eingehalten werden? Wie werden Integrität, Verfügbarkeit und Vertraulichkeit von E-Mails gewährleistet? Wie wird die Lesbarkeit der Inhalte während des Aufbewahrungszeitraums sichergestellt? Durch welche Maßnahmen wird ein Lesezugriff für externe Audits möglich? Wie und unter welchen Bedingungen erfolgt die Löschung von E-Mail-Nachrichten? Wie wird sichergestellt, dass im Fall der obligatorischen Löschung von E-Mails auch die für Sicherungszwecke angefertigten Kopien gelöscht werden?

272

Administrative Aufgaben des Informationsmanagements

Methodenverweise Kennzahlensysteme (Lerneinheit KENNZ); Methoden der Kosten- und Leistungsrechnung (Lerneinheit KOLER). Fallstudienverweis Lerneinheit FSLEM zeigt die Durchführung des ILM am Beispiel eines Data-Warehouse-Systems. Kontrollfragen 1. Worin besteht der Unterschied zwischen einem Vorgehensmodell und einem Lebenszyklusmodell? 2. Wie entwickeln sich die Kosten eines Anwendungssystems in den Phasen des Lebenszyklus? 3. Wie sind die verschiedenen Varianten der Wartung in das Lebenszyklusmodell einzuordnen? 4. Welche Zwecke und Ziele des Software Reengineering können unterschieden werden? 5. Welche Herausforderungen stellen sich für IT-Sicherheitsbeauftragte im Rahmen des Information Lifecycle Managements? Quellen Born, S. et al.: Leitfaden zum Thema "Information Lifecycle Management". 2004. http://www.bitkom.org; Abruf 16. Juni 2011 Kanakamedala, K. / Kaplan, J. M. / Srinivasaraghavan, R.: A smarter approach to data storage. In: The McKinsey Quarterly: The Online Journal of McKinsey & Co. March/2007, 1–3 Lünendonk GmbH (Hrsg.): Information Lifecycle Management 2007 – Bedeutung für den Wertbeitrag der IT. Bad Wörishofen 2007 Matthesius, M. / Stelzer, D.: Analyse und Vergleich von Konzepten zur automatisierten Informationsbewertung im Information Lifecycle Management. In: Bichler, K. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 471–482 Polli, R. / Cook, V.: Validity of the Product Life Cycle. In: Journal of Business 4/1969, 385–400 Posner, M. V.: International Trade and Technical Change. In: Oxford Economic Papers 3/1961, 323–341 Zarnekow, R. / Scheeg, J. / Brenner, W.: Untersuchung der Lebenszykluskosten von IT-Anwendungen. In: WIRTSCHAFTSINFORMATIK 3/2004, 181–187 Vertiefungsliteratur Chen, Y.: Information Valuation for Information Lifecycle Management. In: Parashar, M. (Hrsg.): Proceedings of the 2nd International Conference on Autonomic Computing. Seattle, Washington 2005, 135–146 Kaiser, M. G. / Smolnik, S. / Riempp, G.: Konzeption eines Information-Lifecycle-Management-Frameworks im Dokumenten-Management-Kontext. In: Bichler, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 483–494 Kaplan, J. M. / Roy, R. / Srinivasaraghavan, R.: Meeting the demand for data storage In: The McKinsey Quarterly: The Online Journal of McKinsey & Co. June/2008, 1–6 Matys, E.: Praxishandbuch Produktmanagement – Grundlagen und Instrumente. 3. A. Frankfurt a. M. 2005 Petrocelli, T.: Data Protection and Information Lifecycle Management. New York et al. 2005 Philipp, M.: Ordnungsmäßige Informationssysteme im Zeitablauf. In: WIRTSCHAFTSINFORMATIK 4/1998, 312–317 Thome, G. / Sollbach, W.: Grundlagen und Modelle des Information Lifecycle Management. Berlin 2007 Turczyk, L. A. et al.: Eine Methode zur Wertzuweisung von Dateien in ILM. In: Bichler, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 459–470 Informationsmaterial Fachausschuss Management der Anwendungsentwicklung und -wartung der Gesellschaft für Informatik http://www.fa-maw.gi-ev.de/ White Papers der Storage Networking Industry Association http://www.snia.org Normen IEEE 1074-2006: IEEE Standard for Developing a Software Project Life Cycle Process ISO/IEC 12207:2008: Systems and software engineering - Software life cycle processes ISO/IEC 15288: 2008: Systems and software engineering - System life cycle processes

Geschäftsprozessmanagement (GPMAN) Lernziele Sie kennen den Zweck des Geschäftsprozessmanagements und können den Unterschied zwischen Funktions- und Prozessorientierung beschreiben. Sie wissen, wodurch Business Process Reengineering gekennzeichnet ist. Sie können wesentliche Aufgaben des Geschäftsprozessmanagements erörtern. Sie kennen Ziele der Prozessmodellierung und können typische Kennzahlen beschreiben, mit denen Geschäftsprozesse evaluiert werden.

Definitionen und Abkürzungen Aktivität (activity) = in sich geschlossene Folge von Tätigkeiten, deren Unterbrechung kein sinnvolles Ergebnis liefert. Synonyme: Arbeitsschritt, Operation. Bearbeitungszeit (handling time, net process time) = Zeit, die für die Durchführung eines Prozesses erforderlich ist. BPR = Business Process Reengineering. Durchlaufzeit (cycle time, lead time) = Zeit, die ein Objekt zum Durchlaufen eines Systems benötigt (z. B. Zeit zwischen Auftragseingang und -erfüllung); setzt sich zusammen aus Bearbeitungs-, Rüst-, Warte- und Transportzeiten. Geschäftsprozess (business process) = Abfolge von zeitlich und sachlich zusammenhängenden Tätigkeiten zur Erstellung eines betriebswirtschaftlich relevanten Ergebnisses. GPM = Geschäftsprozessmanagement. Modellierungswerkzeug (modeling tool) = Werkzeug zur Abbildung, Analyse und Simulation von Geschäftsprozessen. Operation (operation) = Handlung oder Tätigkeit, die im betrachteten Zusammenhang nicht weiter zerlegt werden soll. Synonyme: Aktivität, Arbeitsschritt. Prozess (process) = Menge von Teilprozessen, Prozess- und Arbeitsschritten, die durch einen Input in ein System, interne Funktionen und einen Output gekennzeichnet ist. Prozesseigner (process owner) = für einen Prozess verantwortlicher Mitarbeiter. Prozesselement (process element) = Teil eines Prozesses; Teilprozess, Prozess- oder Arbeitsschritt. Prozessorientierung (process orientation) = Ausrichtung eines Unternehmens primär an Geschäftsprozessen statt an Funktionalbereichen. Prozessqualität (process quality) = Gesamtheit von Merkmalen und Merkmalswerten eines Prozesses bezüglich seiner Eignung, festgelegte und vorausgesetzte Forderungen zu erfüllen. Referenzmodell (reference model) = Modell, das einen gewollten oder geplanten Zustand eines Systems abbildet, an dem dessen gegenwärtiger Zustand beurteilt werden kann, oder ein Modell, das als Vorbild zur Ableitung eines spezifischen Modells dient. Tätigkeit (work element) = Teilaufgabe, die bei einem gegebenen Untersuchungszweck nicht weiter zerlegt werden kann. Synonyme: Aktivität, Arbeitsschritt, Operation.

274

Administrative Aufgaben des Informationsmanagements

Zweck des Geschäftsprozessmanagements Mit Geschäftsprozessmanagement (GPM) wird das auf Geschäftsprozesse fokussierte Managementhandeln bezeichnet, mit anderen Worten: die ganzheitliche Planung, Überwachung und Steuerung von Geschäftsprozessen, von dem sie auslösenden Ereignis bis zu ihrer Beendigung über alle beteiligten Funktionalbereiche und Instanzen des Unternehmens hinweg. Der Zweck des GPM ist die effektive und effiziente Gestaltung der Prozesse hinsichtlich verschiedener Leistungsdimensionen wie Zeit, Kosten und Qualität. Projekte zur Verbesserung von Geschäftsprozessen sind nicht notwendigerweise mit einer Veränderung der Technologieunterstützung verbunden. In vielen Fällen streben Unternehmen allerdings an, das Veränderungspotenzial der Geschäftsprozesse durch Automatisierung von Prozesselementen auszuschöpfen. Unternehmen, die planen, betriebswirtschaftliche Standardsoftware einzuführen, verbinden dies häufig mit Projekten zur Verbesserung von Geschäftsprozessen. Das hat verschiedene Gründe. Erstens erfordern umfangreiche Softwaresysteme, insbesondere ERP-Systeme, in vielen Fällen eine Anpassung der Ablauforganisation, und zweitens lassen sich viele Tätigkeiten zur Vorbereitung der Anpassung und Einführung von Standardsoftware gut mit Aufgaben des GPM verbinden. Einführung und Zertifizierung von QM-Systemen (vgl. Lerneinheit QUALM) haben den Stellenwert des GPM erhöht, da Prozessorientierung ein wesentliches Merkmal sowohl von Reifegrad- und Exzellenzmodellen (vgl. Lerneinheit MEQUA) als auch der ISO 9000Standardfamilie ist. Zu den Aufgaben des GPM gehören: Prozessidentifizierung, Prozessanalyse, Prozessentwurf, Prozessmodellierung, Prozessimplementierung und -automatisierung, Prozessevaluierung und Prozessverbesserung.

Funktions- versus Prozessorientierung Spezialisierung und Arbeitsteilung haben zu einer starken Zergliederung von Aufgaben geführt. Dies ermöglicht einerseits Effizienzgewinne bei der Ausführung von Teilaufgaben, kann aber andererseits zu Nachteilen für die Gesamtaufgabe führen, d. h. die Leistungserstellung für den Kunden. Typische Probleme, die mit einer starken Funktionsorientierung einhergehen, sind:     

Viele Schnittstellen zwischen Teilaufgaben führen zu Warte- sowie Liegezeiten und dadurch zu unnötig langen Durchlaufzeiten für die Bewältigung von Aufgaben. Informationsverlust zwischen den Teilaufgaben macht häufige Rückfragen nötig; unterbleiben diese, führt das zu Qualitätsminderung und Überarbeitungsaufwand. Aufwendige Prüfungen und Kontrollen (vgl. Lerneinheit REVIS) erhöhen Kosten und Zeitbedarf. Eine starke Spezialisierung von Mitarbeitern auf Teilaufgaben reduziert deren Verantwortung für die Gesamtaufgabe und senkt ihre Motivation, die Unternehmensziele zu verfolgen. Mangelhafte Transparenz des Gesamtprozesses verhindert die Beseitigung redundanter Tätigkeiten und erschwert Prozessverbesserungen.

Geschäftsprozessmanagement (GPMAN)

275

Grundlegendes Konzept des GPM ist die Prozessorientierung. Im Unterschied zur Funktionsorientierung, bei der einzelne Unternehmensfunktionen (wie Einkauf, Produktion, Marketing bzw. Teile davon) im Mittelpunkt des Managementhandelns stehen, sind dies bei der Prozessorientierung Geschäftsprozesse. Wyssusek unterscheidet ein weites und ein enges Begriffsverständnis. 



Das weite Begriffsverständnis kennzeichnet einen Geschäftsprozess als Abfolge von zeitlich und sachlich zusammenhängenden Aufgaben zur Erstellung eines betriebswirtschaftlich relevanten Ergebnisses. Beispiele für solche Prozesse sind die Rechnungserstellung, die Bearbeitung einer Kundenbeschwerde oder die Durchführung einer Lohnund Gehaltsabrechnung. Das enge Begriffsverständnis hat darüber hinaus folgende Merkmale: Die Anforderung für das Prozessergebnis geht vom Kunden aus und wird von ihm abgenommen, außerdem ist der Prozess für das Leistungsprogramm des Unternehmens von zentraler Bedeutung. Beispiele für solche Prozesse in einem mittelständischen Softwareunternehmen sind Individualsoftwareentwicklung, Organisationsberatung, Softwarewartung und Nutzerschulung.

Die stärkste Ausprägung der Prozessorientierung ist das von Davenport und Hammer/ Champy propagierte Reengineering, welches häufig auch als Business Process Reengineering (BPR) bezeichnet wird. BPR ist durch folgende Merkmale gekennzeichnet:       

Abkehr von einer funktionsorientierten Aufbauorganisation und Konzentration auf bereichsübergreifende Prozesse. Verwendung des Kundennutzens als wesentlichen Erfolgsmaßstab für alle Aufgaben und Prozesse. Radikale Neugestaltung wesentlicher Geschäftsprozesse mit dem Ziel, substanzielle Verbesserungen zu erzielen. Kompromisslose Umgestaltung ohne Berücksichtigung des Bestehenden. Verzicht auf Tätigkeiten, die keinen unmittelbaren Beitrag zur Wertschöpfung leisten. Auflösung fragmentierter Verantwortungsbereiche und Bildung von Prozessteams, die Verantwortung für einen Geschäftsprozess haben. Verwendung der I&K-Technik nicht nur als Rationalisierungsinstrument, sondern als „enabler“ für neue Produkte, Dienstleistungen und Geschäftsprozesse.

Erfahrungen zeigen, dass durch BPR beeindruckende Verbesserungen von Qualitäts-, Zeitund Kostenzielen möglich sind, aber auch, dass viele BPR-Projekte scheitern (vgl. z. B. Grover et al.). BPR wird selten in Reinform angewendet; häufiger sind evolutionäre Weiterentwicklungen bestehender Organisationsformen. Kritik wird nicht nur an extremen Formen der Prozessorientierung (wie dem BPR) geübt, sondern auch an weniger radikalen Formen, z. B. wegen der Gefahr der Verschwendung von Ressourcen oder der Vernachlässigung von Produkten (vgl. z. B. Mertens 1996 oder 1999 und die Forschungsbefunde).

276

Administrative Aufgaben des Informationsmanagements

Aufgaben des Geschäftsprozessmanagements Prozessidentifizierung In der Regel können nicht alle Prozesse eines Unternehmens im Sinne des GPM geplant, gesteuert und kontrolliert werden. Das Ziel der Prozessidentifizierung besteht deshalb darin, die Prozesse zu bestimmen und zu beschreiben, die mit hoher Priorität geplant, gesteuert, kontrolliert und verbessert werden sollen. Eine zweckmäßige Systematik unterscheidet zwischen Führungs- bzw. Managementprozessen, Kern- oder Kundenprozessen und Unterstützungs- bzw. Supportprozessen.   

Führungsprozesse dienen der Planung, Steuerung und Kontrolle von Geschäftsprozessen. Dazu zählen Aufgaben der strategischen Planung, des Controllings und des Risikomanagements. Kernprozesse sind die zentralen Wertschöpfungsprozesse eines Unternehmens. Sie lassen sich aus der Unternehmensstrategie ableiten und beeinflussen die Wettbewerbsfähigkeit eines Unternehmens maßgeblich. Unterstützungsprozesse sind Aufgaben, die keinen unmittelbaren Nutzen für Kunden stiften, sondern den Geschäftsprozessen dienen. Unterstützungsprozesse sind ohne strategische Bedeutung für ein Unternehmen und daher Kandidaten für Outsourcing. Beispiele sind Aufgaben im Personalwesen, der Buchführung oder dem Fuhrparkmanagement. Prozesse des Informationsmanagements (kurz IT-Prozesse) zählen in den meisten Unternehmen ebenfalls zu den Unterstützungsprozessen. Diese werden in der Lerneinheit SEMAN behandelt.

Kernprozesse lassen sich aus den strategischen Geschäftsfeldern, der Geschäftsarchitektur (vgl. Lerneinheit ARCHI) und dem QM-System (vgl. Lerneinheit QUALM) ableiten. Kaplan/Norton empfehlen zur strategischen Steuerung von Unternehmen mit der Balanced Scorecard (vgl. Lerneinheit KENNZ), die Prozesse zu identifizieren, die für die Erreichung der Kundenziele und der Ziele der Anteilseigner am kritischsten sind. Nach der Formulierung von Zielen und Kennzahlen für die Finanz- und die Kundenperspektive werden die Prozesse bestimmt, welche maßgeblich dazu beitragen, diese Ziele zu verwirklichen.

Prozessanalyse Bei der Prozessanalyse werden die Elemente eines Prozesses und deren Beziehungen untereinander bestimmt und beschrieben. Die Prozessanalyse dient dem besseren Verständnis von Geschäftsprozessen, um Ansatzpunkte für Verbesserungen aufzudecken. Dabei werden Hauptprozesse durch Dekomposition in Teilprozesse, Prozess- und Arbeitsschritte bzw. Aktivitäten gegliedert. Außerdem werden die Prozessgrenzen sowie deren Schnittstellen zu anderen Prozessen untersucht. Zur Unterstützung der Prozessanalyse eignen sich hierarchische Darstellungen der Prozessstruktur, Wertkettendiagramme und ereignisgesteuerte Prozessketten (vgl. Lerneinheit MEGPM).

Geschäftsprozessmanagement (GPMAN)

277

Prozessentwurf Während bei der Prozessanalyse Ist-Prozesse untersucht werden, zielt der Prozessentwurf auf die Gestaltung von Soll-Prozessen ab. Der Prozessentwurf bedient sich der Prozessmodellierung, bei der mit Hilfe von Modellierungssprachen, Referenzmodellen und Modellierungswerkzeugen relevante Eigenschaften geplanter Prozesse abgebildet werden (vgl. hierzu den nächsten Abschnitt sowie Lerneinheit MEGPM). Während von den Verfechtern des BPR (wie z. B. Hammer/Champy) die radikale Neugestaltung von Geschäftsprozessen empfohlen wird, herrscht in der Praxis der Entwurf von SollProzessen durch inkrementelle Weiterentwicklung von Ist-Prozessen vor. Abbildung GPMAN-1 gibt einen Überblick über wesentliche Maßnahmen zur Steigerung der Prozesseffizienz (nach Schmelzer/Sesselmann). Gestaltungsmaßnahmen

vorher

nachher

1.Weglassen

1

2

3

4

2. Zusammenlegen

1

2

3

4

1

3. Aufteilen

2

3

2

1

1

1

3

2+3

2a

4

4

3

2b 2

4. Parallelisieren

1

2

3

4

1

5. Auslagern

1

2

3

4

1

2

3

4

1

2

3

4

6. Ergänzen

1

2

3

4

3

Abb. GPMAN-1: Maßnahmen zur Steigerung der Prozesseffizienz (Quelle: nach Schmelzer/Sesselmann)

     

Weglassen bedeutet, nicht wertschöpfende oder redundante Teilprozesse, Prozess- oder Arbeitsschritte (z. B. Mehrfacherfassung von Daten) zu eliminieren. Beim Zusammenlegen werden Teilprozesse, Prozess- oder Arbeitsschritte gebündelt. Durch Aufteilen werden einzelne Prozesselemente in kleinere Elemente zerlegt. Durch Parallelisieren wird das zeitgleiche Durchführen von Prozesselementen erreicht. Auslagern bedeutet, Prozesselemente auf andere Prozesse, Lieferanten, Kooperationspartner oder Kunden zu übertragen. Werden Prozesse oder Prozesselemente auf externe Auftragnehmer übertragen, spricht man von Outsourcing (vgl. Lerneinheit OUTSO). Beim Ergänzen werden Teilprozesse, Prozess- oder Arbeitsschritte in einen Prozess eingefügt.

278

Administrative Aufgaben des Informationsmanagements

Weitere Maßnahmen zur Steigerung der Prozesseffizienz sind: Vermeidung von Schleifen und Rücksprüngen, Änderung der Reihenfolge von Prozesselementen, Reduzierung von Schnittstellen, Minimierung von Wartezeiten, Standardisierung sowie Automatisierung von Prozesselementen.

Prozessmodellierung Prozessmodellierung bedeutet, einen Prozess zweckorientiert mit einer – in der Regel semiformalen – Modellierungssprache in einem Modell abzubilden. In Anlehnung an Gaitanides (161 f.) lassen sich folgende Zwecke der Prozessmodellierung unterscheiden: 







 





Erstellung eines Kommunikationsmittels: Ein Prozessmodell erleichtert die Kommunikation, insbesondere in interdisziplinär zusammengesetzten Teams (z. B. aus Modellierungsspezialisten, Softwareentwicklern und Mitarbeitern aus Fachabteilungen). Es stellt eine Informationsgrundlage für Prozessanalyse, -implementierung und -automatisierung, -evaluierung und -verbesserung, für das Qualitätsmanagement (vgl. Lerneinheit QUALM), für Informationsbedarfsanalysen (vgl. Lerneinheit INBAN) und für die Anfertigung von Geschäftsarchitekturen (vgl. Lerneinheit ARCHI) dar. Schaffung von Wertschöpfungstransparenz: Die Darstellung des inhaltlichen und zeitlichen Zusammenhangs der Aktivitäten eines Prozesses, zeigt, welche Tätigkeiten an der Wertschöpfung beteiligt sind und hilft, Schwachstellen und Verbesserungsmöglichkeiten aufzuzeigen. Bestimmung der Prozessverantwortung: Die Abbildung der einzelnen Aktivitäten zeigt, welche Struktureinheiten an der Leistungserstellung beteiligt sind. Es wird empfohlen, die Verantwortung für einen Geschäftsprozess in eine Hand zu legen, um Abweichungen zwischen Struktur- und Ablauforganisation möglichst zu vermeiden. Definition eines Mess- und Steuerungssystems: Für die im Modell abgebildeten Teilprozesse können Kennzahlen definiert werden, welche helfen, die Prozessleistung zu messen, und die Anhaltspunkte für notwendige Prozessverbesserungen liefern (vgl. dazu die Abschnitte Prozessevaluierung und Prozessverbesserung). Ausarbeitung von Leistungsvereinbarungen: Auf der Grundlage eines Prozessmodells lassen sich Vereinbarungen über Qualitätsanforderungen an Teilprozesse treffen, für die Mitarbeiter oder externe Lieferanten Verantwortung haben. Schulung und Einarbeitung von Mitarbeitern: Neue Mitarbeiter können sich mit einem Prozessmodell einen Überblick über wesentliche Teilaufgaben und deren Zusammenhang sowie ihr Arbeitsumfeld verschaffen. Dies fördert das Verständnis des Unternehmensgeschehens und verbessert die abteilungsübergreifende Zusammenarbeit. Erstellung von Richtlinien: In vielen Unternehmen gibt es Verfahrens- und Arbeitsanweisungen, mit denen Mitarbeitern vorgeschrieben wird, wie bestimmte Tätigkeiten auszuführen sind. Prozessdarstellungen sind außerdem wichtige Elemente von QMSystemen (vgl. Lerneinheit QUALM). Prozessmodelle erleichtern die Erstellung dieser Richtlinien. Entwicklung, Anpassung und Einführung von Softwaresystemen: Abbildungen von Geschäftsprozessen sind eine wichtige Informationsgrundlage für die Anforderungsanalyse in der Softwareentwicklung (vgl. Lerneinheit VOMOD). Die Anpassung und Ein-

Geschäftsprozessmanagement (GPMAN)

279

führung von Standardsoftware, insbesondere von ERP-Systemen, wird häufig auf der Basis von Geschäftsprozessmodellen vorgenommen. Für die Prozessmodellierung stehen Modellierungssprachen, Referenzmodelle und Modellierungswerkzeuge zur Verfügung (vgl. Lerneinheit MEGPM).

Prozessimplementierung und -automatisierung Prozessimplementierung bedeutet, Prozesse wie im Prozessentwurf vorgesehen zu realisieren. Dazu gehören folgende Aufgaben:      

Zuweisung von Rollen und Verantwortungsbereichen für Fach- und Führungskräfte, Schulung der Mitarbeiter für neue bzw. veränderte Aufgaben, Bereitstellen erforderlicher Ressourcen, insbesondere von Informationssystemen, Definition von Prozesszielen und Leistungsanforderungen, Einrichtung eines Messsystems, mit dem die Einhaltung der Ziele und Anforderungen überprüft werden kann, sowie ggf. Anpassung der Struktur- an die veränderte Ablauforganisation.

Bestehende Prozesse zu verändern oder neue Prozesse einzuführen, ist in der Regel ohne veränderte Arbeits- und Verhaltensweisen der Mitarbeiter nicht denkbar. Um mögliche Widerstände dagegen zu reduzieren, wird empfohlen, den organisatorischen Wandel durch ein Management von Veränderungsprozessen bzw. Change Management zu unterstützen. Prozessautomatisierung bedeutet, Prozesse durch IT zu unterstützen. Die IT-Unterstützung neuer oder veränderter Prozesse steht im Mittelpunkt des BPR (vgl. Davenport und Hammer/Champy). Hilfsmittel zur Prozessautomatisierung werden in der Lerneinheit MEGPM erörtert.

Prozessevaluierung Ein wesentlicher Zweck der Prozessevaluierung (vgl. Lerneinheit EVALU) besteht darin, zu überprüfen, ob ein Geschäftsprozess gemäß den Vorgaben ausgeführt wird. Relevante Vorgaben können in Prozessentwürfen, Verfahrensanweisungen und Arbeitsanleitungen (vgl. Lerneinheit QUALM) beschrieben sein. Typische Fragen, die im Rahmen der Prozessevaluierung gestellt werden, sind:     

Werden Teilprozesse, Prozess- und Arbeitsschritte so ausgeführt, wie in Prozessmodellen, Verfahrensanweisungen und Arbeitsanleitungen beschrieben? Ist die Verantwortung für Planung, Steuerung, Kontrolle und Verbesserung von Geschäftsprozessen geregelt? Sind die Mitarbeiter geschult, entsprechend qualifiziert und haben ausreichende Ressourcen zur Verfügung, um die Geschäftsprozesse gemäß den Anforderungen ausführen zu können? Sind Ziel- und Leistungsvereinbarungen getroffen worden, mit deren Hilfe die Arbeitsleistung von Mitarbeitern beurteilt werden kann? Ist die IT-Unterstützung spezifiziert und stehen Anwendungssysteme zur Verfügung, mit denen die Geschäftsprozesse unterstützt werden können?

280

    

Administrative Aufgaben des Informationsmanagements

Sind Ziele, Kennzahlen und Messmethoden zur Evaluierung von Geschäftsprozessen festgelegt? Werden Werte relevanter Kennzahlen regelmäßig erhoben und ausgewertet? Welche Maßnahmen werden bei Abweichungen der Kennzahlenwerte von den Vorgaben ergriffen? Ist ein entsprechendes Berichtswesen und sind Eskalationsstufen etabliert? Unterliegen die Geschäftsprozesse der kontinuierlichen Verbesserung?

Zur Beantwortung der Fragen werden Audits und Reviews genutzt (vgl. Lerneinheit MEQUA). Ein Spezialfall der Prozessevaluierung ist die Prozessmessung, d. h. der Vergleich von Merkmalsausprägungen eines Geschäftsprozesses mit den Anforderungen an diesen Prozess. Typische Kennzahlen (vgl. Lerneinheit KENNZ) für das Evaluieren von Geschäftsprozessen sind Zeit-, Kosten- und Qualitätsgrößen. 





Zeitgrößen, die meist in direkter Beziehung zu definierten Anforderungen an Geschäftsprozesse stehen, sind Durchlaufzeit, Bearbeitungszeit, Wartezeit und Transportzeit sowie Verhältniszahlen, bei denen entweder Zeitgrößen zueinander oder Ablauf- bzw. Outputgrößen zu Zeitgrößen in Beziehung gesetzt werden (z. B. Durchsatz = Outputmenge pro Zeiteinheit). Für die Kundenzufriedenheit sind darüber hinaus die Reaktionszeit auf Kundenanfragen und die Termintreue relevant. Kostengrößen werden im Rahmen der Geschäftsprozessevaluierung in der Regel dadurch ermittelt, dass der Zeitverbrauch für einzelne Arbeitsschritte gemessen und mit den Kostensätzen des Personals multipliziert wird, das an der Ausführung der jeweiligen Arbeitsschritte beteiligt ist. Auf diese Weise wird insbesondere das Potenzial zur Einsparung von Personalkosten durch Einführung von Software ermittelt. In vielen Fällen ist die Ermittlung der Personalkosten aber nicht ausreichend. Die tatsächlich entstehenden Prozesskosten zu ermitteln, ist erstrebenswert, aufgrund der komplexen Zurechnung der Gemeinkosten aber problematisch. Die Prozesskostenrechnung (vgl. Lerneinheit KOLER) ist ein Ansatz zur Lösung dieses Problems. Alle anderen Kennzahlen, die in diesem Zusammenhang von Bedeutung sind, können der Qualität (vgl. Lerneinheit QUALM) zugerechnet werden. Beispiele sind Kundenund Mitarbeiterzufriedenheit, Anteil fehlerhafter Produkte und Leistungen (Ausschussquote), Automatisierungs- und Dokumentationsgrad, Einhaltung von ServiceebenenVereinbarungen (vgl. Lerneinheit SEVER), Anzahl von Medienbrüchen sowie Produktivität, Kapazitätsauslastung und Kapitalbindung.

Kritik an typischen Zielen der Prozessorientierung und -evaluierung übt Mertens (1999 und 2005), vgl. dazu den Abschnitt Forschungsbefunde.

Prozessverbesserung Prozessverbesserung bezeichnet die Gesamtheit der Maßnahmen zur Veränderung von Prozessen und deren Management, um Kostensenkung, Verkürzung von Durchlaufzeiten und Qualitätsverbesserung zu erreichen. Weitere Ziele sind die Erhöhung der Flexibilität und der Innovationsfähigkeit eines Unternehmens.

Geschäftsprozessmanagement (GPMAN)

281

Häufig wird zwischen kontinuierlicher, evolutionärer und diskontinuierlicher, revolutionärer Veränderung von Prozessen unterschieden. Kontinuierliche Veränderung strebt eine permanente Verbesserung vieler (im Extremfall aller) Prozesse eines Unternehmens an, wie sie z. B. im Total Quality Management (vgl. Lerneinheit QUALM) empfohlen wird. Diskontinuierliche Veränderung zielt auf eine radikale Neugestaltung einzelner Prozesse, wie z. B. im BPR (vgl. den Abschnitt Funktions- versus Prozessorientierung) propagiert. Solche Veränderungen sind mit einem hohen Risiko verbunden und haben sich in vielen Fällen als nicht erfolgreich erwiesen (vgl. z. B. Grover et al.).

Rollen des Geschäftsprozessmanagements Die Aufgaben des GPM werden durch Aufgabenträger mit folgenden Rollen übernommen (vgl. Hammer/Champy und Schmelzer/Sesselmann). 







 

GPM-Projektleiter leiten Projekte zur Einführung des GPM in einem Unternehmen bzw. Unternehmensbereich. Sie arbeiten eng mit der Leitung des Unternehmens bzw. Unternehmensbereichs, mit Prozessberatern, Prozesseignern und ggf. einem Prozessteam zusammen. Sollen bestehende Prozesse grundlegend verändert werden, empfiehlt es sich, dies ebenfalls in Form von Projekten durchzuführen. Prozessberater sind – häufig unternehmensexterne – Methodenspezialisten, die GPMProjektleiter und Prozesseigner unterstützen. Sie verfügen über Kenntnisse und Erfahrungen der verschiedenen Methoden des GPM (vgl. Lerneinheit MEGPM). Unternehmensinterne Prozessberater bilden eine Schnittstelle zwischen Fachabteilungen bzw. Prozesseignern und IT-Abteilung. Prozesseigner, Prozessmanager oder Prozessverantwortliche sind Führungskräfte, die einen Geschäftsprozess planen, kontrollieren, steuern und verbessern. Sie sind sowohl für die Überwachung und Verbesserung der Effektivität als auch der Effizienz der Prozesse verantwortlich. Bei sehr komplexen Geschäftsprozessen können den Prozesseignern Teilprozessverantwortliche untergeordnet werden. Prozesscontroller überwachen in Abstimmung mit Prozesseignern, dem Unternehmenscontrolling sowie dem Qualitätsmanagement die Merkmalswerte, die für die Steuerung und Verbesserung von Prozessen erhoben werden. Sie unterstützen die Prozesseigner bei der Verbesserung der Prozesse. Bei weniger komplexen Geschäftsprozessen wird das Prozesscontrolling von den Prozesseignern in Abstimmung mit dem Unternehmenscontrolling übernommen. Prozessmitarbeiter sind Fachkräfte, die für die Ausführung von Prozess- oder Arbeitsschritten verantwortlich sind. Prozessteams übernehmen bestimmte Aufgaben des Prozessmanagements, z. B. die Behebung von Qualitätsproblemen oder die Reorganisation einzelner Prozesse. Die Teams sind interdisziplinär zusammengesetzt und werden aufgelöst, sobald ihre Aufgabe erfüllt ist. Unternehmen, die eine funktionale Aufbauorganisation beibehalten, wird empfohlen, Prozessteams als dauerhafte Instanzen einzuführen, in denen Mitarbeiter aus den Unternehmensteilen zusammengefasst werden, die an der Prozessausführung beteiligt sind. Diese Teams unterstützen die Prozesseigner bei der Wahrnehmung ihrer Aufgaben.

282

Administrative Aufgaben des Informationsmanagements

Forschungsbefunde Luftman/Ben-Zvi berichten über die größten, von IT-Führungskräften wahrgenommenen Herausforderungen („IT management concerns“) (schriftliche Befragung von 172 ITFührungskräften im Sommer 2010, keine Angaben zu Grundgesamtheit und Rücklaufquote). Mit „business productivity and cost reduction” (Rang 1), „business agility and speed to market” (Rang 2), „business process re-engineering” (Rang 5) wurden drei Ziele bzw. Aufgaben des Geschäftsprozessmanagements ermittelt, die zu den fünf wichtigsten Herausforderungen für das IT-Management gezählt werden. Schmelzer/Sesselmann (563-576) werten verschiedene Studien zu den Wirkungen des GPM aus (Sekundäranalyse von 32, zwischen 1991 und 2007 publizierten Quellen). GPM-Projekte können bereits nach sechs bis zwölf Monaten kurzfristige Erfolge erreichen. Typische Leistungssteigerungen manifestieren sich in verbesserter Produktqualität, verkürzten Durchlaufzeiten, geringeren Prozesskosten und höherer Kundenzufriedenheit. Durch BPR erreichte „dramatische“ Leistungssteigerungen können dauerhaft aber nur aufrechterhalten werden, wenn sie im Rahmen eines „integrierten“ GPM durch kontinuierliche Verbesserungen stabilisiert und ausgebaut werden. Nur über einen abgestimmten Einsatz verschiedener Methoden werden nachhaltige Verbesserungen erzielt. Eine effektive Verwendung von GPM erfordert einen aufeinander abgestimmten Einsatz verschiedener Methoden und dauert mindestens zwei bis drei Jahre. „Diese lange Anlaufzeit benötigen Management und Mitarbeiter, um die neuen Orientierungen, Verhaltensweisen und Werkzeuge zu verstehen, zu lernen und täglich zu praktizieren.“ (570) Mertens (1996) (Literaturanalyse, Anzahl der ausgewerteten Quellen und Untersuchungszeitraum nicht angegeben) kritisiert die einseitige Ausrichtung der Wirtschaftsinformatik auf die Prozessorientierung bei gleichzeitigem „Verzicht auf jegliches Abwägen zwischen Alternativen IV-gestützter Aufbau- und Ablauforganisation neben dem Prozessfokus.“ Er fasst seine Untersuchungsergebnisse wie folgt zusammen: „Prozessorientierung beeinträchtigt den sparsamen Umgang mit Ressourcen und verstößt damit gegen elementare Ziele des Ökonomen.“ … „Das oft gesteckte Prozeßziel ‚Minimierung der Durchlaufzeit‘ ist nur bedingt mit dem in der Marktwirtschaft gültigen Oberziel ‚maximale Kapitalrentabilität‘ bzw. ‚maximaler Shareholder Value‘ konform.“ … „Generell scheint … die Bedeutung des Produktes sowie der Übereinstimmung von Produktangeboten/Produkteigenschaften und vom Markt signalisierten Bedarfen vernachlässigt zu werden.“ … „Für gefährlich muß man die übertriebene Priorisierung der ‚wertschöpfenden‘ vor den ‚lediglich unterstützenden‘ Prozessen … beurteilen. Wesentliche Krisen sind nicht durch nicht ‚optimierte‘ Geschäftsprozesse entstanden, sondern durch mangelndes Controlling.“ … „Die sukzessive Verbesserung und Automatisierung von (Haupt-)Prozessen gewährleistet nicht, dass nach einigen Jahren eine geschlossene integrierte Lösung erreicht sein wird.“ (446 f.; Hervorhebungen im Original wurden weggelassen.)

Aus der Praxis In Abbildung GPMAN-2 sind Erfolgs- und Misserfolgsfaktoren von Projekten des GPM zusammengefasst (in Anlehnung an Nippa (73) und Schmelzer/Sesselmann (412 f.)).

Geschäftsprozessmanagement (GPMAN)

283

Erfolgsfaktoren

Misserfolgsfaktoren

Wachstum, Expansion und Innovation als treibende Kräfte des GPM Kommunikation von Strategie, Zielen und Vorgehen Abwendung vom Status quo multidimensionale Betrachtung aller Geschäftsaktivitäten Analyse von wettbewerbskritischen Geschäftsprozessen vorrangige Reorganisation von Führungsund Unterstützungsprozessen ausreichendes Budget kompetente, kooperative und verantwortliche Mitarbeiter permanente Sensibilisierung und Integration der betroffenen Mitarbeiter Einbindung der Leistungsabnehmer Umsetzung mit Projektmanagement

reine Kostenreduzierungsziele in einem auf Erhaltung des Status quo bedachten Unternehmensumfeld saturierte Unternehmen ohne „Leidensdruck“ unrealistische Ziele und Erwartungen pessimistische Grundhaltung und Atmosphäre der Angst Vernachlässigung der Mitarbeiterbefürchtungen umfassende Widerstände im Unternehmen mangelnde (Top-)Management-Beteiligung, keine „sichtbare“ Führung unkoordinierte parallele Verbesserungsprogramme kein übergreifender Prozessansatz unzureichende Mittel für Umsetzung technologische anstelle strategischer und organisatorischer Ausrichtung unzureichende Einbindung von IT-Experten fehlende bzw. unzureichende Methoden

Abb. GPMAN-2: Erfolgs- und Misserfolgsfaktoren von GPM-Projekten (Quelle: nach Nippa und Schmelzer/Sesselmann)

Hoch/Laartz berichteten 2006, dass der CIO der Volkswagen AG seit einigen Jahren für die Definition der Geschäftsprozesse mitverantwortlich war. Er organisierte die IT so, dass diese nicht mehr ausschließlich Unterstützungsfunktionen für bestehende Prozesse übernimmt, sondern eine wesentliche Rolle bei der Verbesserung und Neugestaltung von Geschäftsprozessen spielt. Zu diesem Zweck wurden vier Process Integration Officers (PIOs) für konzernweit definierte Kernprozesse ernannt. Sie übernehmen die Abstimmung zwischen der ITAbteilung und den Fachbereichen der Volkswagen AG. Die PIOs sind dafür verantwortlich, dass die Prozesslandschaft und das IT-Systemportfolio aufeinander abgestimmt werden und dass nicht jeder Unternehmensbereich eine eigene IT-Systemwelt entwickelt. Vor der prozessorientierten Reorganisation der IT-Abteilung wurden lediglich 18 % des IT-Budgets für neue Entwicklungsprojekte verwendet, während der Rest Wartungs- und Betriebskosten für bereits bestehende Anwendungen waren. Nach der Reorganisation betrug das Verhältnis 30 zu 70 %.

284

Administrative Aufgaben des Informationsmanagements

Methodenverweise Methoden des Geschäftsprozessmanagements (Lerneinheit MEGPM); Methoden des Wissensmanagements (Lerneinheit MEWIM); Kennzahlensysteme (Lerneinheit KENNZ); Methoden des Qualitätsmanagements (Lerneinheit MEQUA). Fallstudienverweis Lerneinheit FSGPM zeigt ein Beispiel für die Verbesserung eines Geschäftsprozesses. Kontrollfragen 1. Welche Probleme mit der Funktionsorientierung haben zur Prozessorientierung geführt? 2. Welche Ziele werden mit Prozessmodellierung verfolgt? 3. Unter welchen Bedingungen eignet sich BPR und unter welchen Bedingungen eignet sich die evolutionäre Weiterentwicklung eines Geschäftsprozesses? 4. Sind die mit der Prozessorientierung verfolgten Ziele „Verkürzung der Durchlaufzeit“ und „Senkung von Personalkosten“ ökonomisch relevant? 5. Mit welchen Kennzahlen können Prozesse evaluiert werden? Quellen Davenport, T. H.: Process Innovation. Reengineering Work through Information Technology. Boston 1993 Gaitanides, M.: Prozessorganisation. Entwicklung, Ansätze und Programme des Managements von Geschäftsprozessen. München 2007 Grover, V. et al.: The Implementation of Business Process Reengineering. In: Journal of Management Information Systems 1/1995, 109–144 Hammer, M. / Champy, J.: Business Reengineering. Die Radikalkur für das Unternehmen. 7. A., Frankfurt a. M. 2003 Hoch, D. / Laartz, J.: How IT can drive business process reorganization: An Interview with CIO of Volkswagen. In: The McKinsey Quarterly: The Online Journal of McKinsey & Co. September/2006, o. S. Kaplan, R. S. / Norton, D. P.: Balanced Scorecard. Stuttgart 1997 Luftman, J. / Ben-Zvi, T.: Key Issues for IT Executives 2010: Judicious IT Investments Continue Post-Recession. In: MIS Quarterly Executive 4/2010, 263–273 Mertens, P.: Process focus considered harmful? In: WIRTSCHAFTSINFORMATIK 4/1996, 446–447 Mertens, P.: Operiert die Wirtschaftsinformatik mit falschen Unternehmenszielen? - 15 Thesen. In: Becker, J. et al. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie: Bestandsaufnahme und Perspektiven. Wiesbaden 1999, 379–392 Mertens, P.: Gefahren für die Wirtschaftsinformatik - Risikoanalyse eines Faches. In: Ferstl, O. K. et al. (Hrsg.): Wirtschaftsinformatik 2005. eEconomy, eGovernment, eSociety. Heidelberg 2005, 1733–1754 Nippa, M.: Bestandsaufnahme des Reengineering-Konzepts. Leitgedanken für das Management. In: Nippa, M. / Picot, A. (Hrsg.): Prozeßmanagement und Reengineering. Die Praxis im deutschsprachigen Raum 2. A., Frankfurt a. M./New York 1996, 61–77 Schmelzer, H. J. / Sesselmann, W.: Geschäftsprozessmanagement in der Praxis. Kunden zufrieden stellen - Produktivität steigern - Wert erhöhen. 6. A., München 2008 Wyssusek, B.: Geschäftsprozeßmodell, Geschäftsprozeßmodellierung. In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. A., Berlin/Heidelberg/New York 2001, 210–211 Vertiefungsliteratur Allweyer, T.: Geschäftsprozessmanagement: Strategie, Entwurf, Implementierung, Controlling. 2. A., Herdecke et al. 2007 Becker, J. / Kugeler, M. / Rosemann, M.: Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. 6. A., Berlin/Heidelberg 2008 Davenport, T. H. / Short, J. E.: The New Industrial Engineering: Information Technology and Business Process Redesign. In: Sloan Management Review 4/1990, 11–27 Ellringman, H.: Vom Qualitätsmanagement zum strategischen Geschäftsprozessmanagement. In: Pfeifer, T. / Schmitt, R. (Hrsg.): Masing. Handbuch Qualitätsmanagement. 5. A., München 2007, 69–92 Gadatsch, A.: Grundkurs Geschäftsprozess-Management. Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker. 4. A., Wiesbaden 2005 Osterloh, M. / Frost, J.: Prozessmanagement als Kernkompetenz. Wie Sie Business Reengineering strategisch nutzen können. 5. A., Wiesbaden 2006 Scheer, A.-W.: Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse. 7. A., Berlin 1997

Wissensmanagement (WIMAN) Lernziele Sie wissen, wodurch sich Wissensmanagement von Organisationalem Lernen und Künstlicher Intelligenz unterscheidet. Sie können den Wissensbegriff erläutern und Wissen von Information und Daten abgrenzen. Sie kennen die Aufgaben des Wissensmanagements. Sie können darlegen, welche Strategien des Wissensmanagements unter welchen Bedingungen angemessen sind. Sie kennen Aufgabenträger des Wissensmanagements.

Definitionen und Abkürzungen CKO = Chief Knowledge Officer. Communities of Practice = freiwillig und spontan gebildete Gemeinschaften von intrinsisch motivierten Fachleuten, die eine bestimmte Frage erörtern oder ein Problem lösen wollen. Information (information) = explizites, mitteilbares Wissen. Kompetenzzentrum (competence center, center of excellence) = unternehmensinterne Expertengruppe, welche für spezifische Gebiete Wissen entwickelt. Kodifizierung (codification) = dokumentenbasierte Wissensbewahrung und -verteilung. Künstliche Intelligenz (artificial intelligence) = Automatisierung von intelligentem Verhalten; Repräsentation und automatisierte Verarbeitung von Wissen. Organisationales Lernen (organizational learning) = jegliche, d. h. sowohl zufällige als auch bewusst herbeigeführte, Veränderung der Wissensbasis einer Organisation. Personalisierung (personalization) = personenzentrierte Wissensbewahrung und -verteilung. tacit knowledge = implizites Wissen, welches sich nicht oder nur schwer explizieren lässt. Unternehmenskultur (corporate culture) = Muster von Prämissen (z. B. Normen, Werte und Wahrnehmungen), das von den Unternehmensmitgliedern im Umgang mit der externen und internen Umwelt erlernt und durch Sozialisation weitergegeben wird. Wissen (knowledge) = Gesamtheit der Kenntnisse und Fähigkeiten zur Lösung von Problemen. Wissensbasis (knowledge base, organizational memory) = Gesamtheit des in einem Unternehmen verfügbaren relevanten Wissens. Wissensbestand (knowledge asset) = inhaltlich zusammenhängende Teilmenge der Wissensbasis. Wissensobjekt (knowledge object) = Einheit, die Wissen repräsentiert. Synonym: Wissenselement. Wissenslücke (knowledge gap) = benötigtes, aber nicht verfügbares Wissen. Synonym: Wissensdefizit. Wissensmanagement (knowledge management) = Führungsaufgabe, die sich mit der zielorientierten Nutzung und Weiterentwicklung von Wissen befasst. Wissensmanagementstrategie (knowledge management strategy) = grundsätzliche Festlegungen zur Gestaltung des Wissensmanagements. Wissensträger (knowledge bearer) = Aufgabenträger, der über relevantes Wissen verfügt.

286

Administrative Aufgaben des Informationsmanagements

Zweck des Wissensmanagements Vereinfacht ausgedrückt ist Wissensmanagement die Führungsaufgabe, die sich mit der zielorientierten Nutzung und Weiterentwicklung von Wissen befasst. Aus Sicht des Wissensmanagements sind Unternehmen wissensbasierte Handlungssysteme, in denen Manager alle Möglichkeiten der Einflussnahme auf die Nutzung und Weiterentwicklung von Wissen suchen, mit anderen Worten (nach Zahn): Unternehmen sind Wissenssysteme bzw. – auf Grund der dezentralisierten Handlungsstrukturen – verteilte Wissenssysteme. Diese Erkenntnis ist nichts Neues, neu ist jedoch die Bedeutung, die dem Wissensmanagement beigemessen wird.

Organisationales Lernen und Künstliche Intelligenz Wissensmanagement ist von zwei Forschungsgebieten benachbarter Disziplinen wesentlich beeinflusst worden: dem Organisationalen Lernen und der Künstlichen Intelligenz. Aus diesem Grund wird der Zusammenhang der drei Forschungsgebiete kurz erörtert. Organisationales Lernen beschäftigt sich laut von der Oelsnitz/Hahmann mit jeglichen, d. h. zufälligen und bewusst herbeigeführten sowie erwünschten und unerwünschten, Veränderungen der Wissensbasis einer Organisation. Wissensmanagement hingegen hat einen engeren Fokus. Es verfolgt nach Probst/Raub/Romhardt eine Interventionsabsicht. Wie bereits erwähnt, strebt das Wissensmanagement die zielorientierte Nutzung und Entwicklung von Wissen an, welches für den Organisationszweck als notwendig betrachtet wird. Das interdisziplinäre Forschungsgebiet Künstliche Intelligenz beschäftigt sich laut Puppe mit dem Verständnis und der Automatisierung von intelligentem Verhalten. Im Zentrum steht dabei die Repräsentation und automatisierte Verarbeitung von Wissen. Wie später deutlich werden wird, verfolgt das Wissensmanagement weiter gefasste Ziele als die Künstliche Intelligenz. Während die Künstliche Intelligenz hauptsächlich maschinelle Repräsentation von Wissen und Automatisierung von intelligentem Verhalten anstrebt, beschäftigt sich Wissensmanagement mit allen Formen der zielorientierten Nutzung und Weiterentwicklung von Wissen.

Wissensbegriff In der Fachliteratur werden verschiedene Möglichkeiten erörtert, Wissen zu definieren und von Information abzugrenzen (vgl. zu einem Überblick Stelzer). Im Folgenden wird eine dieser Möglichkeiten beschrieben: Probst/Raub/Romhardt verstehen unter Wissen die Gesamtheit der Kenntnisse und Fähigkeiten zur Lösung von Problemen. Wissen kann implizit oder explizit sein. Kuhlen bezeichnet implizites Wissen als kognitive Strukturen und mentale Repräsentationen von Sachverhalten. Implizites Wissen steht ausschließlich dem betreffenden Wissensträger zur Verfügung. Soll dieses Wissen auch von anderen Personen genutzt werden, muss es expliziert bzw. in eine mitteilbare Form gebracht werden. Dieser Vorgang wird lateinisch mit „informare“ (= bilden, eine Gestalt geben) bezeichnet. Information ist demnach explizites Wissen. Verschiedene Autoren vertreten außerdem die Ansicht, dass Information auch zweckorientiert und handlungsrelevant, also zur Lösung betrieblicher Probleme hilfreich, sein muss. Wird Information in Strukturen abgebildet, die maschinell verarbeitet werden können, liegen Daten vor.

Wissensmanagement (WIMAN)

287

Eine besondere Form des impliziten Wissens ist das von Polanyi als tacit knowing bzw. tacit knowledge bezeichnete Wissen. Dieser Begriff lässt sich nur unzureichend ins Deutsche übersetzen. Tacit knowledge ist der Teil des impliziten Wissens, der sich nicht oder nur schwer explizieren lässt. Polanyi vertritt die These, dass tacit knowledge ein integraler Bestandteil jeglichen menschlichen Wissens ist und insbesondere bei Innovationen eine entscheidende Rolle spielt. Die Gesamtheit des in einem Unternehmen verfügbaren relevanten Wissens wird als Wissensbasis, in der englischsprachigen Literatur teilweise auch als organizational memory bezeichnet. Wissensbestände sind in sich inhaltlich zusammenhängende Teilmengen der Wissensbasis. Beispiele sind der Wissensbestand des Rechnungswesens, der Produktion oder der IT-Sicherheit. Ein Wissensobjekt ist eine Einheit, welche Wissen repräsentiert. Beispiele für Wissensobjekte sind strukturierte Daten in Datenbanken, Geschäftsprozessmodelle, EMails, handschriftliche Notizen, mündlich erteilte Arbeitsanweisungen, Ideen einzelner Mitarbeiter oder implizites Wissen von Fachleuten.

Einflussfaktoren und Handlungsfelder Verschiedene Autoren (z. B. Gold/Malhotra/Segars, Riempp und Schütt) haben darauf hingewiesen, dass viele Wissensmanagementvorhaben scheitern, weil lediglich einzelne Elemente des Wissensmanagements (z. B. Informationssysteme) implementiert werden, ohne diese angemessen in den jeweiligen Kontext zu integrieren. Daraus lässt sich ableiten, dass Wissensmanagement erstens verschiedene Handlungsfelder umfasst und zweitens die konkrete Ausgestaltung des Wissensmanagements von vielen Einflussfaktoren abhängt. Abbildung WIMAN-1 stellt wesentliche Einflussfaktoren und Handlungsfelder des Wissensmanagements im Zusammenhang dar. Die einseitig ausgerichteten Pfeile zum Wissensmanagement machen deutlich, welche Einflussfaktoren für das Wissensmanagement in der Regel gegeben und von diesem nicht oder allenfalls langfristig beeinflusst werden können. Die beidseitig ausgerichteten Pfeile verdeutlichen, dass diese Bereiche sowohl Rahmenbedingungen für das Wissensmanagement darstellen als auch vom Wissensmanagement beeinflusst werden können. Die Gestaltung des Wissensmanagements in einem Unternehmen hängt unter anderem von folgenden Einflussfaktoren ab: dem Zielsystem (inkl. der Unternehmensstrategie, dem Leistungsspektrum und den betrieblichen Zielen; vgl. Lerneinheiten SZIEL und STRAT), der Unternehmenskultur, der Aufbauorganisation, der Form der Arbeitsteilung und Abstimmung (vgl. Lerneinheiten STRUK), den betrieblichen Aufgaben und Prozessen (vgl. Lerneinheiten GPMAN und SEMAN), den bereits vorhandenen Informationssystemen, den Kompetenzen (Erfahrungen, Kenntnissen und Fähigkeiten) der Fach- und Führungskräfte sowie den Wettbewerbsbedingungen. Einige dieser Faktoren können durch das Wissensmanagement beeinflusst werden (z. B. Informationssysteme und Kompetenzen der Mitarbeiter), andere sind nur schwer oder nur mittel- bis langfristig veränderbar (z. B. das Zielsystem oder die Unternehmenskultur), wieder andere liegen außerhalb des Wirkungsbereichs des Wissensmanagements (z. B. die Wettbewerbsbedingungen). Alle Rahmenbedingungen müssen beachtet und gegebenenfalls verändert werden, wenn Wissensmanagement gestaltet werden soll.

288

Administrative Aufgaben des Informationsmanagements

Aufbauorganisation, Struktur des Unternehmens

Unternehmenskultur

Zielsystem des Unternehmens

Arbeitsteilung und Abstimmung betriebliche Aufgaben / Prozesse

Wissensmanagement (Strategien, Aufgaben, Aufgabenträger, Methoden, Werkzeuge)

Wettbewerbsbedingungen

Informationssysteme

Kompetenzen der Fach- und Führungskräfte

Abb. WIMAN-1: Einflussfaktoren und Handlungsfelder des Wissensmanagements

Die Handlungsfelder des Wissensmanagements werden wie folgt gegliedert: Strategien, Aufgaben, Aufgabenträger, Methoden und Werkzeuge des Wissensmanagements. Aus didaktischen Gründen werden zuerst die Aufgaben des Wissensmanagements behandelt. Methoden und Werkzeuge sind Gegenstand der Lerneinheit MEWIM.

Aufgaben des Wissensmanagements Aufgaben des Wissensmanagements sind von vielen Autoren publiziert worden. Im deutschsprachigen Raum ist die Einteilung von Probst/Raub/Romhardt am weitesten verbreitet. Sie unterscheiden acht Aufgaben und bezeichnen diese als Bausteine des Wissensmanagements. Die Aufgaben innerhalb des Rechtecks in Abbildung WIMAN-2 sind die Kernaufgaben des Wissensmanagements. Bei den mit Wissensziele und Wissensbewertung bezeichneten Aufgaben geht es darum, Wissensmanagement in der Unternehmensstrategie zu verankern. Die Darstellung als Regelkreislauf soll andeuten, dass Wissensmanagement kein Projekt, sondern eine Daueraufgabe ist. Zunächst müssen Wissensziele, d. h. Ziele für das Wissensmanagement, vorgegeben werden. Diese sind aus den Unternehmenszielen abzuleiten. In der Regel sind Wissensziele darauf ausgerichtet, für das Unternehmen relevante Fähigkeiten, Produkte oder Prozesse zu verbessern. Diese Ziele sind sowohl Leitlinien für die Gestaltung als auch Maßstäbe für die Bewertung des Wissensmanagements.

Wissensmanagement (WIMAN)

Wissensziele

Wissensidentifikation

289

Feedback

Wissensbewertung

Wissensbewahrung

Wissenserwerb

Wissensnutzung

Wissensentwicklung

Wissensverteilung

Abb. WIMAN-2: Bausteine des Wissensmanagements (Quelle: nach Probst/Raub/Romhardt)

Zweck der Wissensidentifikation ist es, Transparenz über die zur Erreichung der Wissensziele notwendigen Wissensbestände zu schaffen. Dazu werden alle relevanten internen und externen Wissensquellen lokalisiert. Innerhalb des Unternehmens sind dies insbesondere die explizit formulierten Bestandteile der Wissensbasis sowie Mitarbeiter, die über Wissen verfügen, welches für das Unternehmen wichtig ist. Im Umfeld des Unternehmens können Berater, Kunden, Lieferanten und Kooperationspartner wichtige Wissensquellen sein. Aus einem Vergleich zwischen den für das Unternehmen relevanten und den bereits verfügbaren Wissensbeständen lassen sich Wissenslücken ermitteln, die mit Hilfe des Wissensmanagements geschlossen werden sollen. Dabei muss jeweils entschieden werden, ob der Entwicklung von Wissen innerhalb des Unternehmens oder der Beschaffung externen Wissens der Vorzug gegeben wird. Eine Möglichkeit zur Reduzierung von Wissenslücken besteht im Wissenserwerb, d. h. der Akquisition externen Wissens. Die Notwendigkeit zum Wissenserwerb ergibt sich aus der Tatsache, dass kein Unternehmen in der Lage ist, das zur Sicherung des Unternehmenserfolgs erforderliche Wissen vollständig selbst zu entwickeln. Beispiele für Formen des Wissenserwerbs sind:     

Zukauf von Wissen bei Wissensbrokern (z. B. Marktstudien) oder Unternehmensberatern (z. B. Erfahrungsberichte, Vorgehensmodelle), Wissenserwerb von Kunden, Lieferanten und Kooperationspartnern (z. B. durch Einbindung von Schlüsselkunden in den Entwicklungsprozess für neue Produkte), Erwerb von Wissen externer Wissensträger (z. B. Rekrutierung von Mitarbeitern mit Spezialwissen), Erwerb von Wissensprodukten (z. B. Standardsoftware oder Patente) oder Akquisition von Unternehmen mit spezifischen Kompetenzfeldern.

290

Administrative Aufgaben des Informationsmanagements

Eine andere Möglichkeit zur Reduzierung von Wissenslücken ist die Wissensentwicklung innerhalb des Unternehmens. Diese Aufgabe geht über klassische Wissensentwicklungsformen (wie Forschung und Entwicklung oder Marktforschung) hinaus und hat zum Ziel, alle betrieblichen Aufgaben als potenzielle Prozesse zur Erzeugung von Wissen zu analysieren und zu verbessern. Ansatzpunkte zur Entwicklung von Wissen innerhalb des Unternehmens ergeben sich aus der Förderung der Kreativität und Problemlösungsfähigkeit der Mitarbeiter sowie der Verbesserung der Teamarbeit in Innovationsprozessen. Bei der Wissensverteilung –auch als Wissenstransfer bezeichnet – geht es darum, vorhandenes Wissen den Aufgabenträgern zur Verfügung zu stellen, die dieses Wissen zur Aufgabenerfüllung benötigen. Wichtige Fragen der Wissensverteilung lauten: Wer benötigt welches Wissen? Wie kann die Wissensverteilung so gestaltet werden, dass das richtige Wissen zur richtigen Zeit in einer angemessenen Form für die relevanten Aufgabenträger verfügbar ist? Besondere Herausforderungen sind hierbei die Weitergabe individuellen und oft impliziten Wissens sowie die Vermeidung eines unangemessen hohen Aufwandes, der z. B. dadurch entstehen kann, dass Wissensobjekte an Aufgabenträger weitergegeben werden, die dieses Wissen nicht benötigen und dadurch unnötig belastet werden. Ein Ziel des Wissensmanagements ist die Wissensnutzung. Wissensidentifikation, -erwerb, -entwicklung und -verteilung sind dafür notwendige, aber nicht immer hinreichende Voraussetzungen. Die Wissensnutzung kann durch verschiedene Barrieren erschwert oder sogar verhindert werden. Hierzu zählen fehlende Kenntnisse über die Existenz relevanten Wissens, nicht ausreichende Motivation der Mitarbeiter zur Nutzung neuen oder unbekannten Wissens, Festhalten an überkommenen Verhaltensweisen (Not-invented-here-Syndrom), fehlende Zeit, sich mit neuem Wissen auseinanderzusetzen, mangelnde Aktualität oder unangemessener Detaillierungsgrad von Wissensobjekten sowie Zweifel an der Vertrauenswürdigkeit unbekannter Wissensobjekte. Eine wichtige Teilaufgabe der Wissensnutzung besteht darin, diese und ähnliche Barrieren zu reduzieren. Wissensbewahrung hat zum Ziel, Verluste von relevantem Wissen zu vermeiden. Diese können durch Ausscheiden von Mitarbeitern, durch Zerstörung, Nichtauffindbarkeit oder Vergessen wichtiger Wissensobjekte sowie durch Veralterung und mangelnde Aktualisierung entstehen. Teilaufgaben der Wissensbewahrung sind Selektion bewahrungswürdigen Wissens, Aufbereitung, Dokumentation und Indizierung, Speicherung, regelmäßige Aktualisierung und kontrollierte Löschung. Eine der größten Herausforderungen ist der rechtzeitige Transfer individuellen Wissens von Mitarbeitern, bevor diese aus dem Unternehmen ausscheiden. Ziele der Wissensbewertung sind die Bewertung einzelner Wissensobjekte (Wie gut sind diese geeignet, Aufgabenträger zu unterstützen?) als auch die Bewertung des Wissensmanagements als Ganzes. Die Bewertung des Wissensmanagements ist umso einfacher, je klarer entsprechende Ziele definiert worden sind. Soll das Wissensmanagement beispielsweise dazu beitragen, Produktinnovationsprozesse zu verkürzen, kann gemessen werden, inwiefern dieses Ziel nach der Einführung von Maßnahmen des Wissensmanagements erreicht wurde. Diesen Verbesserungen werden die Kosten für die Maßnahmen gegenübergestellt, um zu beurteilen, wie effizient das Wissensmanagement ist.

Wissensmanagement (WIMAN)

291

Strategien des Wissensmanagements Strategien des Wissensmanagements sind grundsätzliche Festlegungen zur Gestaltung des Wissensmanagements. Hansen/Nohria/Tierney unterscheiden die Kodifizierungs- und die Personalisierungsstrategie. Von Krogh/Nonaka/Aben beschreiben vier Strategien des Wissensmanagements. Kodifizierung bezeichnet die dokumentenbasierte Wissensbewahrung und -verteilung. Dabei wird Wissen systematisch erfasst und in Dokumenten oder automatisierten Informationssystemen gespeichert. Wissensentwicklung erfolgt im Rahmen der Kodifizierungsstrategie durch Erweiterung der kodifizierten Wissensbasis. Wissensverteilung findet durch Weitergabe oder Publikation von Dokumenten statt. Die Nutzung von Wissen wird durch Kenntnisnahme und Studium des kodifizierten Wissens angeregt. Wissen wird in Dokumenten oder Informationssystemen vor Verlust bewahrt. Informationssysteme spielen in der Kodifizierungsstrategie eine wichtige Rolle. Sie dienen der Identifikation relevanter Wissensobjekte sowie der Bewahrung und Verteilung expliziten Wissens. Die Kodifizierungsstrategie bietet sich an, wenn relevantes Wissen a) mit geringem Aufwand identifiziert, akquiriert, aufbereitet und dokumentiert werden kann, wenn es b) häufig genutzt wird und c) von Mitarbeitern relativ leicht ausgewählt und ohne fremde Hilfe verwendet werden kann. Personalisierung ist personenzentrierte Wissensbewahrung und -verteilung. Dabei verbleibt das Wissen zunächst bei den Wissensträgern und wird erst bei Bedarf durch persönliche Kommunikation weitergegeben. Im Rahmen der Personalisierungsstrategie wird nicht der Versuch unternommen, Wissen formalisiert zu erheben, zu standardisieren und zu dokumentieren. Vielmehr werden Mitarbeiter dabei unterstützt, Träger des für sie relevanten Wissens zu identifizieren. Wissensentwicklung findet in der Personalisierungsstrategie statt, indem das Wissen einzelner oder mehrerer Personen erweitert wird. Wissensverteilung erfolgt durch persönlichen Austausch, die Nutzung von Wissen wird durch Kommunikation angeregt. Relevantes Wissen wird von Mitarbeitern bewahrt. Informationssysteme haben in der Personalisierungsstrategie eine untergeordnete Rolle. Sie dienen dazu, die Identifikation von und die Kommunikation mit Wissensträgern zu unterstützen. Die Personalisierungsstrategie ist empfehlenswert, wenn es a) aufwendig ist, relevantes Wissen zu identifizieren, zu akquirieren, aufzubereiten und zu dokumentieren, wenn das Wissen b) nur selten genutzt wird oder es c) nur mit Hilfe von Experten ausgewählt, verstanden und angewendet werden kann. Auf der Grundlage einer Fallstudie bei Unilever identifizieren von Krogh/Nonaka/Aben vier Wissensmanagementstrategien. Sie kategorisieren diese mit Hilfe von zwei Dimensionen. Erstens unterscheiden sie, ob die Aufgaben Erwerb bzw. Strategie von bereits intern verfügTransfer Entwicklung barem Wissen ausgeht oder auf Wissensart neues Wissen abzielt. Zweitens bereits verfügLeveraging Expanding dienen die Aufgaben Transfer und bares Wissen Strategy Strategy Erwerb bzw. Entwicklung zur Kateneues Appropriating Probing gorisierung. Die vier WissensmanaWissen Strategy Strategy gementstrategien sind in Abbildung Abb. WIMAN-3: Strategien des Wissensmanagements WIMAN-3 dargestellt. (Quelle: nach von Krogh/Nonaka/Aben)

292

Administrative Aufgaben des Informationsmanagements

Die Leveraging Strategy hat die Verbreitung und Nutzung von Wissen zum Ziel, welches in einzelnen Unternehmensbereichen verfügbar und nützlich ist, in anderen aber bisher nicht genutzt wurde. Unilever hat z. B. gute Erfahrungen mit Communities of Practice gemacht, um Know-how über die Entwicklung von Produktionsstätten für Lebensmittel auf andere Konzernbereiche zu übertragen. Die Expanding Strategy geht von bereits verfügbarem Wissen aus und versucht, dieses zu vertiefen, zu erweitern und zu ergänzen. In den Entwicklungszentren von Unilever wurde z. B. eine Common Flavour Language entwickelt, mit deren Hilfe Gerüche unabhängig von regionalen und kulturellen Eigenheiten beschrieben werden können. Im Rahmen der Expanding Strategy wurde diese Sprache erweitert und konzernweit verbreitet. Die Appropriating Strategy zielt darauf ab, neues Wissen aus externen Quellen für das Unternehmen nutzbar zu machen. Hierzu können Akquisitionen, strategische Partnerschaften und Allianzen eingesetzt werden. Unilever ist z. B. Allianzen mit Microsoft und America Online eingegangen, um die Kundenkommunikation mit Online-Medien zu verbessern. Die Probing Strategy ist darauf ausgerichtet, vollkommen neues Wissen zu entwickeln. Zu diesem Zweck werden bei Unilever Gruppen von Mitarbeitern eingesetzt, die bereit und fähig sind, neue Ideen zu entwickeln. Hilfreich war dies für die Marktsegmentierung und Produktentwicklung auf der Grundlage eines besseren Verständnisses der Lebensstile, Gewohnheiten und Einstellungen verschiedener weltweit verteilter Kundengruppen.

Aufgabenträger des Wissensmanagements In der Praxis haben sich verschiedene Tätigkeitsfelder für Aufgabenträger des Wissensmanagements entwickelt (vgl. auch Lerneinheit STELL). Anfang der 1990er Jahre richteten große Wirtschaftsprüfungsgesellschaften bzw. deren Beratungstöchter die Position des Chief Knowledge Officers (CKO) ein; andere Unternehmen folgten. Ein CKO ist verantwortlich für das Wissensmanagement im Unternehmen. Zu seinen Aufgaben gehören      

Abstimmung des Wissensmanagements mit der Unternehmens- sowie der IT-Strategie, Formulierung der Wissensmanagementstrategie, Definition von Zielen für das Wissensmanagement, Bewertung und Steuerung des Wissensmanagements, insbesondere Sicherstellung der Wirtschaftlichkeit, Führung der Aufgabenträger des Wissensmanagements sowie Koordinierung aller Wissensmanagementaktivitäten.

Neben dem CKO gibt es in vielen Unternehmen weitere Aufgabenträger des Wissensmanagements, die für einzelne Aufgaben des Wissensmanagements oder dessen Unterstützung in bestimmten betrieblichen Funktionen oder Organisationseinheiten zuständig sind (vgl. z. B. Maier, 162 ff.). Beispiele für Bezeichnungen solcher Positionen sind Wissensmanager, Wissensanalyst oder Wissensbroker. Im Unterschied zum CKO, der die Gesamtverantwortung für das Wissensmanagement hat, haben die anderen Aufgabenträger enger abgegrenzte Aufgabengebiete, z. B.

Wissensmanagement (WIMAN)

  

293

Entwicklung, Wartung, Betrieb und redaktionelle Betreuung eines Werkzeugs zum Wissensmanagement, z. B. eines Wikis (vgl. Lerneinheit MEWIM), Initiierung, Leitung und Entwicklung einer Community of Practice für spezifische betriebliche Aufgaben oder Problembereiche, z. B. die Sicherheit der IT, oder Herstellung von Verbindungen zwischen Trägern und Nutzern von Wissen.

Für die Zusammenarbeit der Aufgabenträger werden netzwerkartige Strukturen empfohlen, da diese laterale Kommunikation sowie flexible Kooperation begünstigen. Neben den Rollen für einzelne Aufgabenträger des Wissensmanagements sind in vielen Unternehmen Organisationseinheiten gebildet worden, deren wesentliche Aufgabe darin besteht, Wissen zu entwickeln und zu verteilen. Ein Kompetenzzentrum ist eine unternehmensinterne Expertengruppe, welche für spezifische Gebiete Wissen entwickelt; in Beratungsunternehmen z. B. für betriebliche Funktionen, Branchen oder geografische Regionen. In Qualitätszirkeln (vgl. Lerneinheit QUALM) treffen sich Mitarbeiter, in der Regel unterer Hierarchieebenen, um Probleme des Arbeitsalltags zu bearbeiten und dafür Lösungen zu entwickeln. Laut Wenger/Snyder sind Communities of Practice freiwillig und spontan gebildete, in der Regel zeitlich begrenzte Gemeinschaften von intrinsisch motivierten Fachleuten, die eine bestimmte Frage erörtern oder ein Problem lösen wollen.

Forschungsbefunde Kasten hat analysiert, wie sich Wissensmanagementstrategien in Unternehmen manifestieren (semistrukturierte Interviews mit neun für Wissensmanagement verantwortlichen Führungskräften in nordamerikanischen Unternehmen, Untersuchungszeitraum nicht angegeben). Danach sind Wissensmanagementstrategien keine selbstständigen und losgelöst von anderen Strategien beschriebene Konzepte, sondern informelle, implizite und sich organisch entwickelnde Wahrnehmungen, Annahmen und Handlungsmuster der Fach- und Führungskräfte. Der Autor vergleicht Wissensmanagementstrategien mit Unternehmenskulturen, die zwar nicht als eigenständige Strukturen existieren, aber Denkweisen, Entscheidungen und Handlungen im Umgang mit Wissen nachhaltig prägen. Nassim untersuchte die Bedeutung ausgewählter Einflussfaktoren des Wissensmanagements auf die Leistung kalifornischer Softwareunternehmen bei der Entwicklung neuer Produkte (schriftliche Befragung von 225 Vertretern des mittleren Managements in 16 Softwareunternehmen, 46 auswertbare Fragebögen, Untersuchungszeitraum nicht angegeben). Eine Unternehmenskultur, in der Mitarbeiter konstruktiv zusammenarbeiten (Collaboration) und sich gegenseitig vertrauen (Trust), in der die Mitarbeiter sowohl über ausreichend tiefes als auch breites Fachwissen verfügen (T-shaped skills) und Gruppenleiter einen partizipativen Führungsstil pflegen, sowie das Unternehmen die Weiterbildung (Learning) der Softwareentwickler fördert, begünstigt die Wissensentwicklung und eine kurze Time-to-Market. Diese wurde als Maß für die Leistung der Entwicklung neuer Softwareprodukte verwendet. In der Regel wird vermutet, dass Entscheidungsträger unternehmensinternes Wissen höher schätzen als Wissen von Externen. Dieser Sachverhalt wird auch als Not-invented-hereSyndrom bezeichnet. Menon/Tompson/Choi untersuchten (zwei Fallstudien in amerikanischen Unternehmen und Experimente mit über 130 berufserfahrenen Studierenden in weiter-

294

Administrative Aufgaben des Informationsmanagements

bildenden Managementstudiengängen, Untersuchungszeitraum nicht angegeben), ob Wissen aus internen Quellen tatsächlich höher bewertet wird als Wissen aus externen Quellen. Sie fanden heraus, dass Führungskräfte oft eher bereit sind, Wissen von Externen zu verwenden als von Kollegen oder Mitarbeitern. Menon/Tompson/Choi führen dafür drei Gründe an. Erstens werden Kollegen und Mitarbeiter oft als Rivalen im Streben nach Ansehen, Macht, Bezahlung und Aufstiegschancen angesehen. In dem Maße, in dem Ideen und Ratschläge von Kollegen und Mitarbeitern übernommen werden, verschlechtert sich die eigene, betriebsinterne Wettbewerbsposition. Wird hingegen Wissen von konkurrierenden Unternehmen angenommen, kann sich die Wettbewerbsposition des Unternehmens verbessern. Mitarbeiter, die externes Wissen verwenden, tragen damit zur Sicherheit ihres eigenen Arbeitsplatzes bei. Zweitens kann internes Wissens leichter überprüft und bewertet werden als externes Wissen. Internes Wissen wird oft als minderwertig angesehen, weil dessen Schwachstellen leichter erkannt werden können, als die von externem Wissen. Drittens ist Wissen von Externen oft schlechter zugänglich als internes Wissen. Die Akquisition externen Wissens ist mit höheren Kosten verbunden. Dieses Wissen erscheint daher wertvoller. Maier/Hädrich untersuchten eine Methode zur Erfolgsmessung von Wissensmanagementsystemen (Entwicklung einer Methode auf der Grundlage des Modells von DeLone/McLean zur Messung des Erfolgs von Informationssystemen und Anwendung dieser Methode in einer Fallstudie bei einem deutschen Softwareunternehmen, keine Angaben zum Untersuchungszeitraum). Dabei gelangten sie zu folgenden Erkenntnissen: Die Erfolgsmessung von Wissensmanagementsystemen ist ein äußerst komplexes Unterfangen. Der Erfolg solcher Systeme wird neben den im Modell von DeLone/McLean berücksichtigten Faktoren auch von der Kreativität, Ausbildung und dem Erfahrungshintergrund der Mitarbeiter beeinflusst. Wissensmanagementsysteme sind in organisatorische Kommunikationsprozesse eingebunden. Diese Prozesse werden durch den Systemeinsatz beeinflusst. Die Erfolgswirksamkeit ist jedoch nur schwer festzustellen. Ein Problem ist die Messbarkeit impliziten Wissens. Organisationsstruktur und Prozesse beeinflussen die Gestaltung des Wissensmanagements sowie den Erfolg von Wissensmanagementsystemen. Organisations- und Gruppenkultur sind wichtige Einflussfaktoren für den Erfolg solcher Systeme. Ihre Messbarkeit gestaltet sich aber schwierig.

Aus der Praxis Edmundson berichtet über den erfolgreichen Einsatz von Communities of Practice bei Schlumberger, einem international tätigen Unternehmen der Öl- und Gasindustrie. In diesem Unternehmen arbeiten mehr als 5200 Fachkräfte in Communities of Practice zusammen, um eine effizientere Wissensverteilung zu ermöglichen. Solche Gemeinschaften haben sich unter anderem zu den Themen IT, Mathematik und Geophysik gebildet. Die Gemeinschaften nutzen Workshops und Websites für die Wissensverteilung. Laut Birk/Müller besteht die Struktur des Wissensmanagements bei Siemens Medical Solutions aus sechs Pfeilern. Im Rahmen des Top Management Supports wurden Führungskräfte benannt, welche für das Wissensmanagement in den Bereichen Führung, Personal, Strategie, Ressourcen, Forschung und Entwicklung, Produktion/Supply Chain, Marketing, Verkauf und Kundendienst zuständig sind. Zur einfacheren Identifikation relevanten Wissens wurde eine

Wissensmanagement (WIMAN)

295

unternehmensweite aufgabenorientierte Strukturierung des Wissens verwendet, die es den Mitarbeitern erleichtern soll, relevantes Wissen zu finden. Communities of Practice helfen den oft geografisch verteilten Experten, Wissen auszutauschen. Web-basierte, benutzerfreundliche Informationssysteme erleichtern den Zugang zu kodifiziertem Wissen. Zur Unterstützung des Wissensmanagements haben sich folgende Elemente als hilfreich herausgestellt: ein für das weltweite Wissensmanagement zuständiges Team, Ausbildungs- und Trainingsprogramme zum Wissensmanagement für alle Mitarbeiter, Bewertungskriterien für Wissensbestände und –objekte sowie ein Team, das insbesondere für die Qualitätssicherung von Inhalten zuständig ist, die im Intranet zur Verfügung gestellt werden. Um anfängliche Widerstände gegen das Wissensmanagement zu überwinden, wurde ein Anreizsystem etabliert, das insbesondere die Weitergabe individuellen Wissens und die länderübergreifende Zusammenarbeit fördern soll. Methodenverweise Methoden des Wissensmanagements (Lerneinheit MEWIM). Kontrollfragen 1. Worin besteht der Unterschied zwischen implizitem Wissen und tacit knowledge? 2. Inwiefern unterscheidet sich Wissen von Information? 3. Wie kann man die Aufgaben des Wissensmanagements strukturieren? 4. Welches sind typische Aufgaben eines Chief Knowledge Officers? 5. Welche Wissensmanagementstrategie eignet sich unter welchen Rahmenbedingungen? Quellen Birk, D. / Müller, M.: KnowledgeSharing@MED - turning knowledge into business. In: Davenport, T. H. / Probst, G. J. B. (Hrsg.): Knowledge Management Case Book. 2. A., Berlin/München 2002, 177–186 DeLone, W. H. / McLean, E. R.: The DeLone and McLean Model of Information System Success: A Ten-Year Update. In: Journal of Management Information Systems 4/2003, 9–30 Edmundson, H.: Technical Communities of Practice at Schlumberger. In: Knowledge Management Review. 2/2001, 20–23 Gold, A. H. / Malhotra, A. / Segars, A. H.: Knowledge Management: An Organizational Capabilities Perspective. In: Journal of Management Information Systems. 1/2001, 185–214 Hansen, M. T. / Nohria, N. / Tierney, T.: What’s Your Strategy For Managing Knowledge? In: Harvard Business Review. 2/1999, 106–116 Kasten, J. E.: Knowledge Strategy and Its Role in the Organization: An Exploratory Study. In: International Journal of Knowledge Management 3/2009, 38–53 Kuhlen, R.: Informationsmarkt. Chancen und Risiken der Kommerzialisierung von Wissen. Konstanz 1995 Maier, R.: Knowledge Management Systems: Information und Communication Technologies for Knowledge Management. 3. A., Berlin et al. 2007 Maier, R. / Hädrich, T.: Modell für die Erfolgsmessung von Wissensmanagementsystemen. In: WIRTSCHAFTSINFORMATIK 5/2001, 497–510 Menon, T. / Tompson, L. / Choi, H.-S.: Tainted Knowledge vs. Tempting Knowledge: People Avoid Knowledge from Internal Rivals and Seek Knowledge from External Rivals. In: Management Science 8/2006, 1129–1144 Nassim, B.: Investigating the Impact of Knowledge Management Factors on New Product Development Performance. In: International Journal of Knowledge Management 3/2009, 21–37 Polanyi, M.: The Tacit Dimension. Gloucester 1983 Probst, G. J. B. / Raub, S. / Romhardt, K.: Wissen Managen. Wie Unternehmen ihre wertvollste Ressource optimal nutzen. 5. A., Wiesbaden 2006 Puppe, F.: Künstliche Intelligenz. In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. A., Berlin/Heidelberg/New York 2001, 276–278 Riempp, G.: Integriertes Wissensmanagement - Strategie, Prozesse und Systeme wirkungsvoll verbinden. In: HMD Praxis der Wirtschaftsinformatik. 246/2005, 6–19 Schütt, P.: The post-Nonaka Knowledge Management. In: Journal of Universal Computer Science. 6/2003, 451– 462.

296

Administrative Aufgaben des Informationsmanagements

Stelzer, D.: Wissen. In: Kurbel, K. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik - Online-Lexikon. München 2009, o. S.; http://www.enzyklopaedie-der-wirtschaftsinformatik.de von der Oelsnitz, D. / Hahmann, M.: Wissensmanagement. Strategie und Lernen in wissensbasierten Unternehmen. Stuttgart 2003 von Krogh, G. / Nonaka, I. / Aben, M.: Making the Most of Your Company´s Knowledge: A Strategic Framework. In: Long Range Planning 4/2001, 421–439 Zahn, E.: Wissen und Strategie. In: Bürgel, H. D. (Hrsg.): Wissensmanagement. Berlin et al. 1998, 41–52 Vertiefungsliteratur Alavi, M. / Leidner, D. E.: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues. In: MIS Quarterly 1/2001, 107-136 Güldenberg, S.: Wissensmanagement und Wissenscontrolling in lernenden Organisationen - Ein systemtheoretischer Ansatz. 4. A., Braunschweig/Wiesbaden 2003 North, K.: Wissensorientierte Unternehmensführung. Wertschöpfung durch Wissen. 4. A., Wiesbaden 2005 Stelzer, D.: Informations- versus Wissensmanagement - Versuch einer Abgrenzung. In: Kemper, H.-G. / Mülder, W. (Hrsg.): Informationsmanagement. Neue Herausforderungen in Zeiten des E-Business. Lohmar 2003, 25–41 Informationsmaterial BITKOM Arbeitskreis Knowledge Engineering and Management (AK KEM) http://www.bitkom.org Community of Knowledge (Sammlung von Informationen zum betrieblichen Wissensmanagement) http://www.community-of-knowledge.de Europäischer Leitfaden zur erfolgreichen Praxis im Wissensmanagement. (European Guide to Good Practice in Knowledge Management) CEN/ISSS Knowledge Management Workshop. Brüssel, Frühjahr 2004. ftp://cenftp1.cenorm.be Geneva Knowledge Forum (Plattform zum Austausch und zur Diskussion von Themen des Wissensmanagements, Université de Genève) http://genevaknowledgeforum.ch Gesellschaft für Wissensmanagement e. V. http://www.wissensmanagement-gesellschaft.de KnowledgeBoard (von der Kommission der Europäischen Gemeinschaften finanziertes Portal zum Wissensmanagement) http://www.knowledgeboard.com Knowledge Management Network (Sammlung von Online-Ressourcen zum Wissensmanagement von Y. Malhotra) http://www.kmnetwork.com Swiss Knowledge Management Forum http://www.skmf.net Wissensinitiativen des Bundesministerium für Wirtschaft und Technologie (BMWi) http://www.wissenmanagen.net

Vertragsmanagement (VERMA) Lernziele Sie kennen den Zweck des Vertragsmanagements, die Vertragszwecke und die sich daraus ergebenden Aufgaben. Sie wissen, wie diese Aufgaben institutionalisiert werden. Sie kennen Vertragstypen und Vertragsarten und wissen, um welchen Vertragstyp es sich bei welchem Vertragsgegenstand handelt. Sie kennen den Inhalt und die Gliederung von Hardware- und Softwareverträgen sowie den Zweck von Modellverträgen.

Definitionen und Abkürzungen Angebot (tender) = zeitlich befristeter Vertragsantrag eines potenziellen Auftragnehmers an einen potenziellen Auftraggeber über die Realisierung eines Beschaffungsprojekts. Auftrag (order) = Aufforderung zur Erbringung einer definierten Leistung. Auftraggeber (orderer) = natürliche oder juristische Person, die einen Auftrag vergibt. Auftragnehmer (contractor) = natürliche oder juristische Person, die einen Auftrag übernimmt und i. d. R. auch durchführt (Hersteller, Softwarehaus, Systemhaus). CISG = United Nations Convention on Contracts for the International Sale of Goods. Cookie = kleine Datei, die der Betreiber einer Website einem Nutzer beim Aufruf dieser Seite auf dessen Computer kopiert (wörtlich Keks). DRM = Digital Rights Management. ERMS = Enterprise Rights Management System. ITCL = IT Contract Library; eine Moduldatenbank zur Vertragsgestaltung. Lizenz (license) = vertragliche Einräumung eines Rechts zur Nutzung eines Objekts. Mantelvereinbarung (blanket agreement) = Vertrag mit Vertragsinhalten, die längerfristig gültig und daher für mehrere Verträge relevant sind. Synonym: Rahmenvertrag. Nutzungsrecht (usufructuary right) = Recht, das den Inhaber einer Nutzungsbewilligung berechtigt, ein urheberrechtlich geschütztes Werk im vereinbarten Umfang zu nutzen. OCG = Österreichische Computergesellschaft. Produktaktivierung (product activation) = Form des Softwareschutzes zur Verhinderung von Softwarepiraterie. Synonym: Softwareaktivierung. Risiko (risk) = Kombination aus zu erwartender Häufigkeit bzw. Eintrittswahrscheinlichkeit eines gefährdenden Ereignisses und dem beim Ereigniseintritt zu erwartenden Schadensausmaß. Vertrag (contract) = das durch Antrag und Annahme zwischen zwei oder mehreren Personen zum Abschluss gelangende Rechtsgeschäft. Vertragsbestand (contract inventory) = Gesamtheit der im Unternehmen vorhandenen Verträge über die Lieferung und Wartung von Produkten und das zur Verfügung stellen von Dienstleistungen des IT-Markts. Vertragsrecht (contract law) = Recht, das die zwischen Privatpersonen oder juristischen Personen frei verhandelten und vereinbarten Rechtsbeziehungen regelt. Vorgehensmodell = (procedure model) = Prozess zum Lösen eines Problems, der in Modellphasen abgebildet ist.

298

Administrative Aufgaben des Informationsmanagements

Zweck des Vertragsmanagements Zweck des Vertragsmanagements ist die zielorientierte Gestaltung der Rechtsbeziehungen zwischen Auftraggeber (Kunde, Servicenehmer usw., z. B. ein Outsourcing-Nehmer) und Auftragnehmer (Lieferant, Servicegeber usw., z. B. ein Outsourcing-Geber) für Produkte und Dienstleistungen des IT-Markts in Form von Verträgen einschließlich so genannter Mantelvereinbarungen sowie das zielorientierte Verwalten des Vertragsbestands beim Auftraggeber. Zielorientiert bedeutet in diesem Zusammenhang, dass es nicht primär um das Abschließen und Verwalten von Verträgen geht, sondern darum, für die Vertragsparteien dauerhafte positive Geschäftsbeziehungen zu schaffen. Rechtliche Grundlage des Vertragsmanagements ist insbesondere das Vertragsrecht (vgl. Lerneinheit RECHT). Im Sinne des Vertragsmanagements werden zwei Kategorien von Verträgen unterschieden, die jeweils gleichartige Vorgehensweisen (vgl. den Abschnitt Legal Engineering), insbesondere bei der Vertragsgestaltung, ermöglichen: Austauschverträge und Gesellschaftsverträge. Verträge im IT-Bereich sind in der Regel Austauschverträge (z. B. Outsourcing-Vertrag, Softwareüberlassungsvertrag, Kaufvertrag für IT-Betriebsmittel). Aus folgenden Gründen muss der Vertragsbestand bewusst gestaltet und verwaltet werden:     

Die Verträge betreffen erhebliche wirtschaftliche Werte. Störungen bei der Vertragserfüllung bergen erhebliche Risiken, die negative Auswirkungen auf die Abwicklung der Geschäftsprozesse haben können. Die unterschiedlichen Vertragsarten und die verschiedenen Vertragsgegenstände (unterschiedliche Produkte oder Dienstleistungen, mit Produkten verbundene Dienstleistungen und umgekehrt) erschweren die Übersicht. Die Anzahl der Verträge und Vertragspartner ist groß und nimmt weiter zu. Lücken im Vertragsbestand können zu straf- und zivilrechtlichen Konsequenzen führen (z. B. wegen Urheberrechtsverletzung).

Nach DIN 69905 befasst sich Vertragsmanagement – im Rahmen des Projektmanagements, wie es dort heißt – mit der „Steuerung der Gestaltung, des Abschlusses, der Fortschreibung und der Abwicklung von Verträgen zur Erreichung der Projektziele“. Alle die Projektbeteiligten bindenden Vereinbarungen sind demnach Gegenstand des Vertragsmanagements. Für das Vertragsmanagement relevant sind auch gesetzliche Regelungen, die Unternehmen dazu zwingen, aus Vertragsbindungen resultierende Chancen, Risiken und Belastungen transparent zu machen (z. B. KonTraG, Basel II, SOX/SOA, vgl. Lerneinheit GOVER).

Vertragszwecke Ein formal und sachinhaltlich zweckmäßig gestalteter Vertrag regelt die Rechtsbeziehungen zwischen den Beteiligten und macht die Risiken für die Vertragsparteien kalkulierbar. Verträge spiegeln den Inhalt und den Ablauf des Vertragsgegenstands wider; ihre Kernfunktion ist die Minimierung und Verteilung der Risiken. Durch den Abschluss eines Vertrags werden insbesondere folgende Zwecke verfolgt: 

Vermeidung von Unklarheiten durch eindeutige Beschreibung und Dokumentation aller zwischen den Vertragsparteien getroffenen Vereinbarungen.

Vertragsmanagement (VERMA)

       

299

Absicherung gegen mögliche Fehlentwicklungen, die bei Vertragsabschluss nicht vorauszusehen sind (z. B. Konkurs einer Vertragspartei oder Ausscheiden von Mitarbeitern des Auftragnehmers, die für die Vertragserfüllung besonders wichtig sind). Abgrenzung der Verantwortung für Aufgaben zwischen den Vertragsparteien (z. B. bei Lieferung eines Softwareprodukts in der Installationsphase). Genaue Beschreibung von Lieferungen und Leistungen sowie von Lieferungs- und Leistungsbedingungen, damit Mitarbeiter, die später mit der Vertragsdurchführung befasst sind, klare Regelungen vorfinden. Festlegung des Ortes, an dem die Lieferung bzw. Leistung erbracht werden soll (Erfüllungsort). Vereinbarung von Metriken für den Nachweis der Erbringung von Lieferungen und Leistungen und von Preisen je Metrik (z. B. Metriken für die Messung von Serviceebenen bei Serviceebenen-Vereinbarungen, vgl. Lerneinheit SEVER). Vereinbarung von Abrechnungsmodellen zur Ermittlung des Entgelts je Abrechnungszeitraum einschließlich Zahlungsbedingungen (vgl. Abschnitt Abrechnungsmodelle). Vereinbarung einer Schlichtungsstelle, die für den Fall, dass die Beziehung zwischen den Vertragsparteien schwer gestört ist, vermitteln soll. Festlegung von Ersatzansprüchen, wenn die Vertragserfüllung gestört oder unmöglich geworden ist (z. B. Reduzierung des vereinbarten Entgelts).

Aufgaben des Vertragsmanagements Diese umfassen im weiteren Sinne den Prozess vom Erkennen des Bedarfs an einem ITProdukt oder einer IT-Dienstleistung und die Identifikation von potenziellen Vertragspartnern (vgl. Lerneinheit TECHM), den Verhandlungsprozess bis zum Vertragsabschluss (Vertragsgestaltung), die laufende Erfassung der Nutzung des Produkts bzw. der Dienstleistung und deren Verrechnung nach vereinbarten Abrechnungsmodellen, die Vertragspflege und die Vertragsarchivierung sowie auf Grundlage der Archivierung die Vertragsverwaltung mit dem Ziel der Optimierung der Wirksamkeit und Wirtschaftlichkeit des Vertragsbestands (Vertragscontrolling, vgl. Lerneinheit CONTR). Bei der Vertragsgestaltung geht es um die Erarbeitung des Vertragsdesigns. Die Minimierung und Verteilung der Risiken erfordert eine Analyse der Interessenslage der Vertragsparteien und die Ermittlung der Risiken (z. B. für jede Projektphase, wenn der Vertrag ein Projektvertrag ist und der Projektgegenstand nach einem Phasenmodell erstellt wird, vgl. Lerneinheit VOMOD). Da die Risikofaktoren technischer, organisatorischer, wirtschaftlicher und anderer Art sind, ist ein interdisziplinärer Ansatz der Risikoanalyse erforderlich (vgl. Lerneinheit SIKON). Grundsätzlich zweckmäßig ist es, die Vertragsleistungen „von Anfang an“ präzise festzulegen und zu dokumentieren. Erfahrungsgemäß ändern sich jedoch während der Vertragslaufzeit die Anforderungen, so dass es notwendig ist, den Prozess der Vertragspflege im Vertrag zu regeln. Dazu gehören Regelungen zur außergerichtlichen Entscheidungsfindung bei Meinungsverschiedenheiten. Verträge sollten nicht von Aufgabenträgern des Informationsmanagements allein erarbeitet und von Juristen lediglich geprüft werden, sondern gemeinsam erarbeitet werden. Um Konfliktpotenzial zu vermeiden bzw. Konflikte auszuräumen, sollte insbesondere die Vertrags-

300

Administrative Aufgaben des Informationsmanagements

pflege in das Management des jeweiligen Projektgegenstands, beispielsweise in das Projektmanagement, einbezogen werden. Kernaufgaben der Vertragspflege sind:       

Überwachen der Vertragsdauer, um Verträge rechtzeitig zu verlängern bzw. zu kündigen oder an veränderte Bedingungen anpassen zu können. Überwachen der Erfüllung der zu bestimmten Vertragsterminen vereinbarten Lieferungen und Leistungen. Erfassen und Dokumentieren von Lieferungs- und Leistungsstörungen als Grundlage für deren vertragsgerechte Beseitigung bzw. als Nachweis für Schlichtungen bzw. Beweismittel für gerichtliche Auseinandersetzungen. Überprüfen der tatsächlichen Lieferungen und Leistungen auf Übereinstimmung mit den vereinbarten Lieferungen und Leistungen. Überprüfen der Angemessenheit von Preisen im Vergleich zum Wert der Lieferungen und Leistungen und der Korrektheit der Abrechnungen entsprechend den vereinbarten Abrechnungsmodellen. Führen von Vertragsverhandlungen zwecks Anpassung von Preisen bzw. Abrechnungsmodellen. Aktualisieren von Zusatzvereinbarungen und Anlagen (z. B. das Anlagenverzeichnis bei der Computer-Sachversicherung).

Die Durchführung dieser Aufgaben kann zu einer Situation führen, in der Vertragsänderungen zweckmäßig oder sogar erforderlich sind. Dies sollte dem Vertragspartner grundsätzlich umgehend schriftlich angezeigt werden (Änderungsanzeige, Änderungsantrag). Häufig zieht die Änderung zu einem bestimmten Vertragspunkt Änderungen an anderen Vertragspunkten nach sich (z. B. führt die Änderung des Leistungsumfangs zur Änderung von Kosten oder Preisen und/oder Terminen). Änderungsanforderungen können nicht nur vom Auftraggeber, sondern auch vom Auftragnehmer ausgehen (z. B. wenn bei einem Softwareentwicklungsauftrag der zunächst vereinbarte Funktionsumfang erweitert wird). Im Mittelpunkt der Vertragsarchivierung steht die unveränderbare, langfristige und revisionssichere Archivierung (vgl. Lerneinheit REVIS) der Verträge und aller vertragsrelevanten Dokumente in digitaler Form (z. B. Vertragsentwürfe, Bilder, Protokolle, E-Mails mit beigefügten Dokumenten). Die wirkungsvolle und wirtschaftlich akzeptable Bewältigung der Aufgaben des Vertragsmanagements erfordert bei einem größeren Vertragsbestand die Verwendung einschlägiger Werkzeuge (vgl. den gleichnamigen Abschnitt).

Legal Engineering Da die Erarbeitung von Verträgen oft erheblichen Aufwand erfordert, sind Muster- bzw. Modellverträge (vgl. den gleichnamigen Abschnitt) bzw. ist ein methodisches Vorgehen zur Erarbeitung individueller Verträge zweckmäßig, also ein Vorgehensmodell (vgl. Lerneinheit VOMOD). Die zweite Variante ist zu empfehlen. Das erst in Ansätzen vorhandene methodische Vorgehen bei der Vertragsgestaltung, im englischsprachigen Raum als Legal Engineering oder Contract Engineering bezeichnet, ist im IT-Bereich u. a. durch das gemeinsame Vorgehen von Aufgabenträgern des Informationsmanagements und Juristen gekennzeichnet. Obwohl die vertragliche Strukturierung von Rechtsverhältnissen seit Jahrhunderten eine

Vertragsmanagement (VERMA)

301

Aufgabe von Juristen ist, ist die Praxis noch immer durch Checklisten, Musterdokumente und die Abklärung von Einzelfragen geprägt (nach Straub). Einen Ansatz in Richtung Legal Engineering zeigt Heuss. Für alle Vertragskonstellationen wird ein standardisiertes Aufbauschema angeboten, das aus folgenden Teilen besteht: Vertragliche Grundlagen, Inhalt der Leistungen, Sicherung der Leistungen, Vertragsdurchführung, Allgemeine Bestimmungen und Anlagen. Diese Gliederung ist vergleichsweise abstrakt, doch kann mit ihr eine Vorstrukturierung jeder Art von Austauschvertrag gelingen. Entsprechend dem Charakter als Checkliste werden primär nicht konkrete Formulierungen vorgeschlagen, sondern es wird verdeutlicht, was bedacht werden muss. Diese Herangehensweise resultiert aus der Überzeugung, dass zunächst identifiziert werden muss, wo Regelungsbedarf besteht und dass Musterformulierungen das notwendige Durchdenken eher verhindern als fördern. Die Verwendung von Musterdokumenten, aus denen Klauseln ohne ausreichendes Verständnis per „copy and paste” zusammenkopiert werden, wird vermieden.

Lizenzmanagement Spezifisches Objekt des Vertragsmanagements sind Softwarelizenzen, die individuelle Anforderungen stellen, die im Vertragsmanagement nicht grundsätzlich erfüllt werden. Softwarelizenzen verursachen nicht nur Kosten, sondern stellen auch Werte dar, die ohne Transparenz nicht ausreichend genutzt werden können. Lizenzmanagement ist daher auch Teil eines umfassenden IT-Asset-Managements, dessen Ziele die Optimierung von Wirksamkeit und Wirtschaftlichkeit des Softwareeinsatzes sind. Bezüglich Wirtschaftlichkeit schätzen seriöse Werkzeuganbieter das Rationalisierungspotenzial auf 15 % der Softwarekosten. Weitere Zwecke des Lizenzmanagements sind:    

Verringerung des Haftungsrisikos für nicht lizenzierten Softwareeinsatz, Vermeidung so genannter Shelfware (ungenutzte, „im Regal herumliegende“ Software) und der Nutzung unautorisierter Software, verursachungsgerechte Zurechnung der Softwarekosten (vgl. Lerneinheit KOLER) und Erfüllung der Anforderungen internationaler Standards (z. B. ISO/IEC 19770-1) oder des BSI-Grundschutzes (vgl. Lerneinheit SIKON).

Die Einführung von Lizenzmanagement ist vor allem Integrationsaufgabe, insbesondere die Integration mit Prozessen des Servicemanagements (z. B. dem ITIL-Prozess Configuration Management, vgl. Lerneinheit SEMAN). Mit einem werkzeugorientierten „out-of-thetoolbox-Denken“ können die Ziele des Lizenzmanagements nicht erreicht werden. Bei der Prüfung der Softwarelizenzen stehen Ordnungsmäßigkeit und Wirtschaftlichkeit im Mittelpunkt (vgl. Lerneinheit REVIS). Prüfungsziele sind insbesondere, ob       

alle Softwareprodukte bestandsmäßig erfasst sind, sachgerechte, wirtschaftliche und gültige Lizenzverträge vorliegen, die Software über- oder unterlizenziert ist, die Beschaffung regelkonform erfolgte, die Vertragsverwaltung und Rechnungsprüfung/ -bezahlung ordnungsmäßig erfolgt, die Software tatsächlich benötigt und genutzt wird, die Anschaffungskosten ordnungsgemäß gebucht und aktiviert wurden und ungenutztes Wirtschaftlichkeitspotenzial vorhanden ist.

302

Administrative Aufgaben des Informationsmanagements

Es sollen auch die Softwarewartungsverträge, die in Verbindung mit einem Lizenzvertrag eingegangen wurden, geprüft werden.

Institutionalisierung des Vertragsmanagements In vielen Unternehmen sind Kompetenz und Verantwortung für das Vertragsmanagement auf mehrere Instanzen verteilt; es gibt keine Instanz, die einen Überblick über den gesamten Vertragsbestand hat. In Unternehmen, in denen der Vertragsbestand einer Instanz zugeordnet ist, ist dies meist eine Stelle des Finanz- und Rechnungswesens. Bei dieser Zuordnung steht die Aufgabe im Vordergrund, Zahlungen (z. B. Prämien für Versicherungen) termingerecht zu erledigen bzw. bei Zahlungsanforderungen deren Höhe und Fälligkeit zu überprüfen; dabei handelt es sich nur um eine Funktion der Aufgabe Vertragsverwaltung. Aus der Art der genannten Kernaufgaben der Vertragspflege ist erkennbar, dass eine enge Bindung der Aufgabenerfüllung an die Instanzen erforderlich ist, mit denen die Vertragsobjekte erarbeitet bzw. in denen sie genutzt werden; dies ist im Allgemeinen nicht das Finanz- und Rechnungswesen. Da die Erarbeitung und Nutzung der Vertragsobjekte zumeist im Unternehmen verteilt, eine zentrale Instanz für das Vertragsmanagement – zumindest in koordinierender Funktion – aber zweckmäßiger ist als mehrere dezentrale Instanzen, bietet sich die IT-Abteilung dann als Aufgabenträger an, wenn diese auch das IT-Controlling wahrnimmt. Vertragsmanagement zumindest in koordinierender Funktion sollte auch dann Aufgabe der zentralen IT-Abteilung sein, wenn es neben dieser Instanz mehrere dezentrale IT-Abteilungen gibt (z. B. in den Geschäftsfeldern eines divisionalisierten Unternehmens, vgl. Lerneinheit STRUK). Wird das IT-Controlling von einer Struktureinheit Unternehmenscontrolling wahrgenommen, sollte dieser auch das den IT-Bereich betreffende Vertragsmanagement zugeordnet werden. Da wie gezeigt einige Aufgaben oder Aufgabenteile des Vertragsmanagements Controllingcharakter (vgl. Lerneinheit CONTR), andere Revisionscharakter (vgl. Lerneinheit REVIS) haben, ist ein Zusammenwirken der Aufgabenträger des Vertragsmanagements mit denen des Controllings und mit denen der Revision erforderlich.

Vertragstypen und Vertragsarten Vertragstyp ist zwar ein in der Terminologie der Rechtswissenschaften geläufiger, aber in keinem Gesetz definierter Begriff. Seine Verwendung geht auf die Tatsache zurück, dass bereits im Römischen Recht bestimmte Arten von Verträgen (z. B. Kaufvertrag, Werkvertrag, Dienstvertrag) bekannt waren, die immer weiter ausgeformt wurden; diese werden als Vertragstypen bezeichnet. Spätere Gesetze haben die Vertragstypen übernommen (z. B. BGB bzw. AGBG). Wegen der Vertragsfreiheit der Parteien bilden sich immer wieder neue, gesetzlich nicht geregelte, gemischte, kurz gesagt atypische Verträge heraus. Da über deren Behandlung im Einzelfall Rechtsnormen nichts oder nichts Spezielles aussagen, müssen Regelungen aus dem am besten passenden, geregelten Vertragstyp gesucht und angewendet werden (z. B. beim Outsourcing-Vertrag Regelungen des Werkvertrags und des Dienstvertrags, vgl. Lerneinheit OUTSO). Unvermeidlich sind Fälle, bei denen es strittig ist, ob eine bestimmte Vereinbarung (z. B. in einem Outsourcing-Vertrag) eher als Vertragstyp A (z. B. als Werkvertrag) oder als Vertragstyp B (z. B. als Dienstvertrag) anzusehen ist. Dabei

Vertragsmanagement (VERMA)

303

kommt es nicht darauf an, welche Bezeichnung für einen Vertrag verwendet wird, sondern ausschließlich auf den Vertragsinhalt. Werden Nutzungsrechte an Software erworben, werden sie in der Regel im Softwareüberlassungsvertrag konkret beschrieben. Um welchen Vertragstyp es sich bei diesem Vertrag handelt, ist im Schrifttum und in der Rechtsprechung strittig. Herrschende Meinung ist, dass es sich bei Überlassung von Individualsoftware um einen Werkvertrag, bei Überlassung von Standardsoftware um einen Kaufvertrag (oder einen kaufähnlichen Vertrag) handelt. Standardsoftware ist dieser Auffassung nach im rechtlichen Sinn eine bewegliche Sache. Im Schrifttum wird auch häufig die Auffassung vertreten, dass es sich beim Softwareüberlassungsvertrag für Standardsoftware um einen Lizenzvertrag handelt. Nach dem Vertragsgegenstand werden folgende Vertragsarten unterschieden (links vom Doppelpunkt; rechts davon die Vertragstypen):       

Hardwarevertrag: Kaufvertrag, Mietvertrag oder Leasingvertrag für Hardware Softwarevertrag: Kaufvertrag bzw. Lizenzvertrag oder Werkvertrag für Software Hardwarewartungsvertrag: Werkvertrag über die Wartung von Hardware Softwarewartungsvertrag: Werkvertrag über die Wartung von Software Beratungsvertrag: Dienstvertrag über Beratungsdienstleistungen Projektvertrag: Werkvertrag über Projektdienstleistungen Versicherungsvertrag: Vertrag eigenen Typs zur Überwälzung von Risiken auf Versicherer durch Computerversicherungen

Vertragsinhalt und Vertragsgliederung Verträge, deren Vertragsgegenstand die Lieferung von Hardware und/oder Software ist, sollten folgende Gliederung und Inhalt haben (besonders in den mit * gekennzeichneten Vertragsteilen besteht ein spezifischer Regelungsbedarf für IT-Verträge):          

Vertragstyp (Kaufvertrag, Werkvertrag usw. bzw. atypischer Vertrag) Vertragsparteien (Verkäufer/Käufer, Vermieter/Mieter usw.) Präambel (insbesondere Absichten und Vorstellungen der Vertragsparteien) Vertragsgegenstand / Leistungsbeschreibung (Leistungspflichten des Auftragnehmers)* Informations- und Dokumentationsregeln (z. B. Bestandteile und Zeitpunkt der Übergabe der Dokumentation)* Übergabe und Übernahme des Vertragsgegenstands (z. B. Liefertermin, Vorbereitung und Durchführung der Installation, Testzeiten, Abnahme)* Schulungsangebot (z. B. Zeitpunkt, Umfang, Kosten, Mindestqualifikation des zu schulenden Personals) Verwertungsrechte (z. B. Nutzungsrechte wie einfache Nutzung, Nutzung im Konzern, Nutzung in einem Rechenzentrum)* Vertragsdauer und Kündigungsfristen Vereinbartes Entgelt (z. B. über Transportkosten sowie Auf- und Abbaukosten bei Hardware, Installationskosten bei Software, Anrechnung von bezahlten Mieten bei Kauf des Vertragsgegenstands)

304

           

Administrative Aufgaben des Informationsmanagements

mögliche Preisänderungen im Zeitraum bis zur Übergabe des Vertragsgegenstands und während der Vertragslaufzeit Lieferungs- und Zahlungsbedingungen (z. B. Angaben über Eigentumsvorbehalt, Haftungsrückhalt, Vertragsgebühren) Konsequenzen bei Leistungsstörungen sowie zur Mängelbehebung (Gewährleistung) Schadensersatz (z. B. Vertragsstrafen bei nicht rechtzeitiger Lieferung) Vereinbarungen über Zeitraum und Entgelt für die Wartung des Vertragsgegenstands Regelungen über eine angemessene und rechtzeitige Versorgung mit Ersatzteilen durch den Auftragnehmer für einen bestimmten Zeitraum nach Abnahme (bei Hardware) * Regelungen für Erweiterungen (z. B. Ausbau der Hardware, Weiterentwicklung der Software, Änderung von Schnittstellen)* Regelungen zur Geheimhaltung Bedingungen für eine Vertragsbeendigung und deren Konsequenzen Vorgehensweise bei Konkurs oder Liquidation (z. B. Softwarehinterlegung) * Gerichtsstand und eventuell Schiedsgericht Vertragsanhänge (z. B. Lastenheft, Pflichtenheft)*

Mustervertrag bzw. Modellvertrag Die allgemeine Unsicherheit beim Abschließen von Verträgen für Hardware, Software und IT-Dienstleistungen hat eine Reihe von Institutionen veranlasst, Muster- bzw. Modellverträge – auch als IT-Vertragsmuster bezeichnet – sowie allgemeine Bedingungen für den Erwerb oder die Nutzung von Hardware und Software vorzuschlagen. Zweck von Muster- bzw. Modellverträgen ist es, die Interessen beider Vertragspartner angemessen zu berücksichtigen und die Vertragsgestaltung zu erleichtern (z. B. mit Hilfe der ITCL). Beispielsweise hat der „OCG-Arbeitskreis EDV-Leistungsverträge“ Modellverträge erarbeitet, die laufend aktualisiert werden (vgl. Abschnitt Informationsmaterial). Von der Fachgruppe Datenverarbeitung im Bundesverband Deutscher Unternehmensberater BDU e.V. wurden „Allgemeine Nutzungsbedingungen für Software“ formuliert. Über das Internet werden – in der Regel gegen Entgelt – Musterverträge angeboten (z. B. http://www.vorlagen.de). Im Unterschied zu vielen Lieferbedingungen der Anbieter gibt es keinen Zwang, an einem bestimmten Artikel eines Muster- bzw. Modellvertrags festzuhalten, wenn dieser den Wünschen der Vertragsparteien nicht entspricht. Angepasst an die jeweilige Situation können spezielle Klauseln innerhalb des vordefinierten Vertragsrahmens hinzugefügt oder weggelassen werden. Vorteile von Muster- bzw. Modellverträgen sind:    

Verringerung des Aufwands für die Erarbeitung und Formulierung des Vertragsinhalts. Sicherstellung der Vollständigkeit und Rechtmäßigkeit aller Vertragspunkte zum Schutz der Interessen der Vertragsparteien. Hilfe bei der Analyse der kommerziellen Bedingungen von Angeboten. Ausgleich der Verhandlungsstärke der Vertragsparteien, was besonders für Auftraggeber kleiner Unternehmen wichtig ist, die häufig keine ausreichende Verhandlungsstärke gegenüber den Anbietern haben.

Vertragsmanagement (VERMA)

305

Bei der Gestaltung von Verträgen ist das UN-Kaufrechtsübereinkommen (CISG = United Nations Convention on Contracts for the International Sale of Goods) zu berücksichtige. Gem. Artikel 1 Abs. (1) Buchstabe a CISG findet es auf alle Kaufverträge über Waren zwischen Parteien Anwendung, die Niederlassungen in verschiedenen Staaten haben, wenn beide Staaten Vertragsstaaten sind (z. B. Deutschland, Österreich und die Schweiz). Die in diesem Übereinkommen vereinbarten Vertragsbedingungen gelten für alle internationalen Kaufverträge, falls ihre Anwendung nicht ausdrücklich ausgeschlossen wird. Im Geschäftsverkehr zwischen Kunden und Lieferanten ist es üblich, dass der schriftlichen Auftragserteilung die Einkaufsbedingungen des Kunden beigegeben werden. Diese gelten dann meistens unwidersprochen als Vertragsgrundlage für jeden Geschäftsvorgang. Bei Verträgen über die Lieferung von Hardware und die Überlassung von Software ist die Situation häufig anders: Die Lieferanten haben meist den Vertragstext festgesetzt und legen diesen als Lieferbedingungen dem Kunden vor. Diese Art der Vertragsregelung kann beiden Teilen Vorteile bringen (z. B. weitgehend einheitliche Vertragssituation, rechtlich ausgefeilte und auf den Vertragsgegenstand abgestimmte Vertragstexte), aber auch zu Unbeweglichkeit bei Vertragsverhandlungen führen.

Werkzeuge des Vertragsmanagements Werkzeuge des Vertragsmanagements müssen für jeden Vertrag alle für das Vertragsmanagement erforderlichen Daten zur Verfügung stellen, standardisierte Berichte liefern und Erinnerungsfunktionen bieten (z. B. für Kündigungstermine). Werkzeuge unterstützen auch Nachverhandlungen oder Bonusverrechnungen und schaffen Vergleichbarkeit, kurz gesagt ermöglichen sie ein aktives Vertragsmanagement. Die am IT-Markt angebotenen Werkzeuge unterscheiden sich vor allem hinsichtlich Funktionalität und Integrationsfähigkeit in die bestehende IT-Architektur (vgl. Lerneinheit ARCHI). Ein Beispiel ist Spider Contract, das Daten ausgewählter Verträge in einer stabilen Datenbank verwaltet. Der Zugriff erfolgt über das Intranet, kanalisiert durch die integrierte Rechteverwaltung (DRM). Außer der Serverkomponente muss nichts auf den Clients installiert werden. Dadurch ist das Vertragsmanagement an jedem Arbeitsplatz verfügbar. Spider Contract fügt sich in die IT-Bestandsverwaltung Spider Asset nahtlos ein, indem z. B. zur Hardware vereinbarte Leasing- und Mietverträge erfasst werden. Laufzeiten werden optimal genutzt, Upgrades rechtzeitig geplant. Durch die Zuordnung von Serviceebenen-Vereinbarungen (vgl. Lerneinheit SEVER) wird die Kontrolle der Dienstleister wesentlich vereinfacht. Im Zusammenspiel mit dem Lizenzmanagement Spider Licence erfasst Spider Contract die Rahmendaten der Lizenzverträge. Mit Spider Asset wird für alle über das Netzwerk erreichbaren Arbeitsplätze ermittelt, welche Software installiert ist. Das SAP-Add-On CUNO ist ein von der Consono Consult GmbH auf Basis des ERPSystems SAP R/3 entwickeltes Vertragsmanagementsystem. SAP R/3 verfügt zwar in mehreren Modulen über Funktionen zum Vertragsmanagement, diese können jedoch nur modulspezifisch genutzt werden. CUNO aggregiert die Daten der Module und schafft ein Management-Cockpit für den gesamten Vertragsbestand eines Anwenders einschließlich der zugehörigen Dokumente wie Vertragsentwürfe, E-Mails und technische Zeichnungen. Ein Workflow erinnert den Vertragsmanager an Fristen (z. B. Kündigungsfristen).

306

Administrative Aufgaben des Informationsmanagements

Eine spezifische Kategorie dieser Werkzeuge sind Digital-Rights-Management-Systeme (DRMS), deren Zweck es ist es, die Weitergabe und Verbreitung von Daten im Rahmen der durch Lizenzen vereinbarten Verwertungsrechte zu steuern. DRMS können auch zum Schutz kritischer Unternehmensdaten eingesetzt werden (so genannte ERMS, vgl. Lerneinheit RECHT).

Abrechnungsmodelle Mit diesem Begriff werden Vertragsbestandteile bezeichnet, nach denen der Auftragnehmer von Lieferungen und Leistungen die Kosten bzw. Preise je Zeitabschnitt auf transparente, für den Auftraggeber nachvollziehbare Art und Weise ermittelt, auch als Kostenmodelle (aus Sicht des Auftraggebers) oder Preismodelle (aus Sicht des Auftragnehmers) bezeichnet. Grundsätzliche Alternativen sind die Vereinbarung von verbrauchsunabhängigen, so genannten Flatrates (von engl. flat rate = Pauschale, Pauschaltarif, Pauschalgebühr oder Grundgebühr) oder die Vereinbarung von Kosten je gelieferter bzw. verbrauchter Einheit, also eine Verbrauchsabrechnung. Im Allgemeinen sind für den Auftragnehmer Flatrates vorteilhaft, da für den Kunden bereitgestellte Kapazität „abgenommen“, jedenfalls von diesem vergütet werden muss. Zukünftige Erlöse können einfach und mit hoher Wahrscheinlichkeit prognostiziert werden. Für den Auftragnehmer ist im Allgemeinen die vollständige und nach der Art der Lieferung und Leistung mit spezifischen Einheitskosten erfolgende Abrechnung vorteilhaft. In der Regel findet ein Interessensausgleich statt; im Abrechnungsmodell werden sowohl Pauschalen (Grundpreis) als auch Verbrauchsabrechnungen (Preis je Verbrauchseinheit) vereinbart. „Echtes“ Cloud Computing (vgl. Lerneinheit INMAN) erfordert verrechnungstechnisch gesehen eine rein verbrauchsbedingte, fein granulierte Abrechnung. (Zu den Abrechnungsmodellen für Private Clouds vgl. Lerneinheit KOLER.) Es ist anzunehmen, dass sich die Verbrauchsabrechnung für Infrastruktur- und PlattformServices (IaaS = Infrastructur-as-a-Service bzw. PaaS = Platform-as-a-Service) und die Flatrate für Software-Services (SaaS = Software-as-a-Service) durchsetzen werden. Ein weiteres verrechnungstechnisches Problem des Cloud Computing besteht darin, Abrechnungsmodelle Cross Cloud-verträglich zu gestalten, da angenommen werden kann, dass der Kundenbedarf über das Angebot einzelner Anbieter hinausgehen wird. Dafür geeignete Lösungen werden dem Roaming der Mobiltelefonie entsprechen

Aus der Praxis Das von Amazon verwendete Abrechnungsmodell bietet neben Speicherplatz „reines“ Computing in detaillierten Stärkestufen. Die Recheneinheit ist als Stunde eines Prozessors von einem Gigahertz auf 32-Bit-Plattform unter Windows oder Linux mit 1,7 GB Hauptspeicher und 160 GB Plattenspeicher definiert. Bezogen werden kann von einer bis zu 20 Recheneinheiten pro Stunde mit vielen Zwischenstufen. Der Preis pro Stunde skaliert degressiv, maximal um den Faktor acht. Auch der separat buchbare vorgehaltene oder belegte Speicherplatz wird in ähnlich kleinen Inkrementen angeboten, ebenso Datentransfers, Snapshots und I/O-Requests. „Mit dieser feinen Granulierung hat sich Amazon an die Spitze der Anbieter gesetzt.“ (Zitiert nach Computer Zeitung vom 11.5.2009, 12.)

Vertragsmanagement (VERMA)

307

Nach Meinung der Business Software Alliance (BSA) sind weltweit 40 % der verwendeten Software Raubkopien. Softwarepiraterie ist nicht nur illegal, sondern auch eine Gefahr für Daten und Rechner. Die BSA wird vorwiegend von großen Softwareherstellern (z. B. Microsoft) finanziert und soll die Wahrung des Urheberrechts an deren Software mit geeigneten Maßnahmen fördern. Die 2004 aktuellen Maßnahmen nahmen die IT-Verantwortlichen ins Visier und forderten deren Mitarbeiter auf, ihre Vorgesetzten für den Einsatz nicht lizenzierter Software gegebenenfalls anzuzeigen; auch Mitwisserschaft ist strafbar. Wenn erforderlich, bietet die BSA Zeugenschutz. Zur Verhinderung von Softwarepiraterie hat Microsoft 1999 die vom TÜVIT geprüfte Produktaktivierung entwickelt (auch als Softwareaktivierung bezeichnet). Aktivierte Softwareprodukte können nur mit einer bestimmten Anzahl Starts oder über einen bestimmten Zeitraum genutzt werden und stehen danach nicht mehr oder nur mit eingeschränkter Funktionalität zur Verfügung, wenn keine Aktivierung erfolgt ist. Die Produktaktivierung kann über Internet oder Telefon abgewickelt werden und ist anonym, da keine personenbezogenen Daten erforderlich sind und gespeichert werden, es sei denn, es soll mit der Produktaktivierung auch eine Registrierung erfolgen. Der Installationscode, der an Microsoft übermittelt wird, ist ein verschlüsselter Zeichenkettenwert aus der Product-ID und dem Hardware-Code (Hardware-Hash). Mit der Aktivierung wird kein Cookie gesetzt. Nach einer Studie der IDC, dem weltweit führenden IT-Marktbeobachter, zählt Österreich mit 27 % zu den Ländern mit der geringsten Piraterierate in Europa; für Deutschland und die Schweiz werden 30 % angegeben. Die durchschnittliche Piraterierate für Osteuropa beträgt 71 % (z. B. für die Ukraine 91 %, für Russland 87 %). Die von Microsoft eingeführte Produktaktivierung wird als geeignetes Mittel zur Senkung der Piraterierate angesehen. Microsoft hat 2011 die Ergebnisse einer Studie zur Verbreitung illegaler Software in Russland veröffentlicht. Daraus geht hervor, dass sich die Situation seit der letzten Untersuchung im Jahr 2010 deutlich verbessert hat. Untersucht wurden 3229 Einzelhändler und Softwareverkäufer in 94 russischen Städten, von denen 20 % unlizenzierte Software zum Kauf anbieten. Bei 11 % der geprüften Geschäfte sind PCs mit illegal vorinstalliertem Windows erhältlich. (Zitiert nach http://winfuture.de/news,61312.html; Abruf 4.4.2011.) „Spitzenreiter“ bei der Piraterierate 2011 ist Schätzungen zufolge mit rd. 90 % China. Nach einer Studie von Centennial Software Ltd. (Auswertung der schriftlichen Befragung von 60 Teilnehmern) können nur 8 % der Unternehmen nachweisen, dass sie über Lizenzen der eingesetzten Software verfügen. In den meisten Unternehmen sind die IT-Abteilung, die Beschaffungs- und die Finanzabteilung für den Einkauf von Software zuständig, verantwortlich für das Lizenzmanagement ist bei 45 % der Unternehmen die IT-Abteilung. Höchste Priorität hat dabei die Reduzierung der IT-Kosten. 61 % der Befragten wollen in den nächsten zwölf Monaten die Softwarelizenzen besser nutzen statt neue zu kaufen. (Zitiert nach http://www.cio.de/index.cfm?webcode=816917; Abruf 13. Oktober 2008.) Pfarl (7 f.) stellt zum Umfang von Vertragsdokumenten u. a. fest: „Gerade Großunternehmen verwenden oftmals überdimensionierte Vertragskompendien, da sich … das Gerücht hält, dass nur ein langer Vertrag ein guter Vertrag ist. Meist sind kurze, klare und prägnante Bestimmungen besser geeignet als … seitenlange Vertragspunkte, die aufgrund der sprachlichen Unschärfe … zu ungleichen Interpretationen und damit Missverständnissen und Kon-

308

Administrative Aufgaben des Informationsmanagements

flikten führen können. … Die bewusste Reduktion des Vertragswerkes auf die notwendigen Bestandteile kann erheblich zu einem raschen und erfolgreichen Verhandlungsprozess beitragen.“ Diese Quelle enthält auch für den IT-Bereich spezifische Musterverträge (z. B. für Beratungsdienstleistungen, Outsourcing, Internetauftritt und Einkauf von Betriebsmitteln). Methodenverweise Kosten- und Leistungsrechnung (Lerneinheit KOLER); Kennzahlensysteme (Lerneinheit KENNZ); ServiceebenenVereinbarungen (Lerneinheit SEVER). Kontrollfragen 1. Welche Aufgaben hat das Vertragsmanagement? 2. Durch welche Besonderheiten ist Lizenzmanagement als Teil des Vertragsmanagements gekennzeichnet? 3. Wie sollte das Vertragsmanagement institutionalisiert sein? 4. Welche Zwecke werden mit Muster- bzw. Modellverträgen verfolgt? 5. Was sind Abrechnungs-, Kosten- oder Preismodelle als Vertragsbestandteil? Quellen Abrechnungsmodelle für Cloud Services: http://www.cloud-practice.de; Abruf 4.4.2011 CUNO: http://www.consono.de/index.php/de/sapso/clmsams; Abruf 3.4.2011 Heusler, B. / Roland, M.: IT-Vertragsrecht. Zürich 2004 Heussen, B. (Hrsg.): Handbuch Vertragsverhandlung und Vertragsmanagement. 3. A., Köln 2007 IIR-Arbeitskreis DV-Revision: Prüfung der Software-Lizenzen. In: Zeitschrift Interne Revision 1+2/1999, 20–34 Jaburek, W. J.: Handbuch der EDV-Verträge. Musterverträge für Anwender und Anbieter Bd. I. 3. A., Wien 2000 Jaburek, W. J.: Handbuch der EDV-Verträge. Musterverträge für Anwender und Anbieter Bd. II., Wien 2003 Michels, J. K.: http://www.jomi1.com/; Abruf 4.3.2011 Pfarl, W. (Hrsg.): IT-Verträge – Handbuch für Praktiker. Wien 2007 Spider Contract: http://www.brainwaregroup.com/index.php?id=812; Abruf 3.4.2011 Straub, W.: „Legal Engineering“ – Was Juristen und Ingenieure voneinander lernen könnten. Neue Zürcher Zeitung vom 15./16.5.2004, 54 Vertiefungsliteratur Achilles, W.-A. (Hrsg.): Kommentar zum UN-Kaufrecht (CISG). 2. A., München 2011 Becker, E. / Buhse, W. / Günnewig, D. / Rump, N. (Eds.): Digital Rights Management – Technological, Economic, Legal and Political Aspects. Lecture Notes in Computer Science 2770. Berlin/Heidelberg 2003 Groll, T.: 1x1 des Lizenzmanagements. Praxisleitfaden für Lizenzmanager. 2. A., München 2010 Madauss, B. J.: Handbuch Projektmanagement. 7. A., Stuttgart 2006 (insbes. Kapitel XIII Vertragsmanagement im Projekt) Marly, J.: Software-Überlassungsverträge. 4. A., München 2004 Redeker, H.: Handbuch der IT-Verträge. Loseblattwerk, Berlin 2000 ff. Informationsmaterial CICS Table of Contracting States: http://www.cisg.law.pace.edu/cisg/countries/cntries.html; Abruf 8.5.2011 OCG-Arbeitskreis EDV-Leistungsverträge (Hrsg.): Musterverträge für Software Bd. 1 Kauf- und Mietvertrag, Bd. 2 Werkverträge, Bd. 3 Wartungsvertrag. OCG-Schriftenreihe Bde. 38, 63 und 108, Wien 1987, 1997 und 1998 SWICO/SVD (Hrsg.): Vertragsmodelle – Beschaffungsverträge, Dienstleistungsverträge, Projektverträge, Übrige Verträge. 2. A., Zürich 1999 Normen und Standards DIN 69905: Projektabwicklung, Begriffe. 1997 IEEE Standard 729-1983: Glossary of Software Engineering Terminology ISO/IEC 19770-1: Software Asset Management. 2006

Servicemanagement (SEMAN) Lernziele Sie kennen den Zweck des Servicemanagements und Anforderungen, die an das Servicemanagement gestellt werden. Sie können die daraus abgeleiteten Aufgaben nennen und erläutern. Sie kennen wesentliche Inhalte von ITIL und ISO/IEC 20000 und können deren Bedeutung für das Servicemanagement erklären.

Definitionen und Abkürzungen Change Request = Anforderung einer (Ver-)Änderung. Synonym: Request for Change. CI = Configuration Item; IT-Komponente, die vom Konfigurationsmanagement verwaltet wird. CMDB = Configuration Management Database; Datenbank, mit der CIs verwaltet werden. CSI = Continual Service Improvement. IT-Dienstleister (IT service provider) = Struktureinheit, die IT-Dienstleistungen für unternehmensinterne oder -externe Kunden erbringt. IT-Dienstleistung (IT-Service) = Dienstleistung, die für einen oder mehrere unternehmensinterne oder -externe Kunden erbracht wird. Synonym: IT-Service. ITIL = Information Technology Infrastructure Library; Leitfaden für das IT-Servicemanagement. IT-Service = IT-Dienstleistung. IT-Servicemanagementsystem (IT service management system) = Gesamtheit der Hilfsmittel zur Realisierung des IT-Servicemanagements. itSMF; = IT Service Management Forum (GB). Konfiguration (configuration) = Zusammenstellung der Funktionseinheiten eines Systems, die zur Erfüllung einer bestimmten Aufgabe erforderlich sind. MOF = Microsoft Operations Framework; Leitfaden für das IT-Servicemanagement. OGC = Office of Government Commerce (GB). Qualitätsniveau (quality level) = Ausmaß an geforderter oder vorhandener Qualität. Service Desk = Struktureinheit, der operative Aufgaben des Störungsmanagements zugeordnet sind. Synonyme: Helpdesk, User-Help-Desk, Benutzerservice-Zentrum. Servicekatalog (service catalogue) = Beschreibung der von einem IT-Dienstleister angebotenen Services. SLA = Service Level Agreement; Serviceebenen-Vereinbarung; Vereinbarung über vom Kunden gewünschte und vom Dienstleister zugesagte Ausprägungen von Eigenschaften einer IT-Dienstleistung. Synonym: Dienstgütevereinbarung. Störung (incident) = unerwünschtes Ereignis, das zu einer Beeinträchtigung eines ITServices oder zum Ausfall eines Elements der IT-Infrastruktur führt oder führen kann. Unified Messaging System = System, das Nachrichten über verschiedene Medien (z. B. EMail, Fax, SMS) empfangen und weiterleiten und auf das mit Hilfe verschiedener Medien zugegriffen werden kann.

310

Administrative Aufgaben des Informationsmanagements

Zweck des Servicemanagements Das Verhältnis von IT-Bereichen als Anbieter und Fachbereichen als Nutzer von ITDienstleistungen ist in vielen Unternehmen problembehaftet und spannungsgeladen. Gründe dafür sind unterschiedliche Ziele, Arbeitsweisen und Fachbegriffe, mangelndes Verständnis für die Rahmenbedingungen, Aufgaben und Restriktionen der jeweils „anderen Seite“, Überlastung der IT-Bereiche bei gleichzeitig mangelnder Bereitschaft oder Fähigkeit der Fachabteilungen, an IT-Aufgaben mitzuwirken sowie unterschiedliche Vorstellungen von der Machbarkeit und Wirtschaftlichkeit von IT-Vorhaben. In vielen Unternehmen hatte die ITAbteilung über Jahrzehnte eine Monopol ähnliche Stellung als Anbieter von ITDienstleistungen; ein Umstand, der häufig dazu geführt hat, dass Effektivität, Effizienz und Kundenorientierung nicht ausreichend waren oder als nicht ausreichend wahrgenommen wurden. Die IT-Kosten erreichen in vielen Unternehmen ein so hohes Niveau, dass Mitglieder der Unternehmensleitung sich die Frage stellen, ob die Kosten in einem angemessenen Verhältnis zum Nutzen der IT stehen. Außerdem wird diese oft als wenig transparent und damit schlecht planbar, kontrollierbar und steuerbar wahrgenommen. Eine Möglichkeit, mit diesen Problemen umzugehen, besteht darin, IT-Aufgaben auf externe Dienstleister zu übertragen (vgl. Lerneinheit OUTSO). Eine andere Option ist, die Aufgaben des IT-Bereichs und insbesondere die Beziehungen zwischen IT-Bereich und Fachbereichen durch IT-Servicemanagement (im Folgenden kurz: Servicemanagement) neu zu gestalten. Dies hilft sowohl IT-Bereichen, die für Fachabteilungen innerhalb des Unternehmens Dienstleistungen anbieten, als auch Outsourcing-Dienstleistern bei der Planung, Entwicklung, Steuerung, Kontrolle und Verbesserung von IT-Services. Außerdem ermöglicht es Anbietern und Nachfragern von IT-Services, ihre Beziehungen klarer zu strukturieren. Servicemanagement ist zwischen Geschäftsprozessmanagement und IT-Governance einzuordnen. Während Geschäftsprozessmanagement (vgl. Lerneinheit GPMAN) darauf ausgerichtet ist, Geschäftsprozesse zu planen, zu steuern, zu kontrollieren und zu verbessern sowie diese durch IT zu unterstützen, hat Servicemanagement das Ziel, die spezifischen Aufgaben eines IT-Bereichs sowie der Schnittstellen zu den Fachabteilungen und deren Aufgaben bzw. zu den Geschäftsprozessen eines Unternehmens zu gestalten. IT-Governance (vgl. Lerneinheit GOVER) bildet die Schnittstelle zwischen Unternehmensführung und Informationsmanagement. Dabei sind Führungs- und Organisationsstrukturen, Entscheidungsbefugnisse und Verantwortungsbereiche festzulegen. Servicemanagement stellt sicher, dass die für das Unternehmen notwendigen IT-Services effektiv und kostengünstig erbracht werden.

IT-Services OGC (6) definiert einen Service als „a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks“. Ein IT-Service ist eine Dienstleistung, die durch einen IT-Dienstleister für einen oder mehrere unternehmensinterne oder -externe Kunden erbracht wird. In ITIL werden Business und Infrastructure Services unterschieden. Ein Business Service ist ein IT-Service, der unmittelbar Geschäftsprozesse oder betriebliche Aufgaben unterstützt. Beispiele für Business Services sind: Workflowmanagement für die

Servicemanagement (SEMAN)

311

Auftragsbearbeitung, Druck, Kuvertierung und Versand von Rechnungen sowie Betrieb, Wartung und Benutzerbetreuung von E-Mail-Systemen. Ein Infrastructure Service ist ein IT-Service, der nicht unmittelbar Geschäftsprozesse oder betriebliche Aufgaben unterstützt, vom IT-Dienstleister aber beherrscht werden muss, um Business Services erbringen zu können. Beispiele für Infrastructure Services sind: Betrieb und Wartung einer CMDB, Information-Lifecycle-Management (vgl. Lerneinheit LEMAN) oder Kostenrechnung für IT-Services.

Teilaufgaben des Servicemanagements Servicemanagement besteht aus vielen Teilaufgaben, die in Rahmenwerken wie ITIL oder ISO/IEC 20000 (vgl. Abschnitt Rahmenwerke des Servicemanagements) unterschiedlich strukturiert werden. Alle Teilaufgaben werden durch die Beauftragung von Mitarbeitern institutionalisiert, die für Planung, Steuerung, Kontrolle und Verbesserung der Teilaufgaben verantwortlich sind. Die Ausführung der Teilaufgaben wird dokumentiert, und Führungskräfte des Informationsmanagements sind dafür verantwortlich sicherzustellen, dass sich die Mitarbeiter an diese Vorgaben halten. Um dies zu ermöglichen, müssen Ressourcen und Hilfsmittel zur Verfügung gestellt werden. Im Folgenden werden die wichtigsten Teilaufgaben erörtert. Weitere Teilaufgaben werden auf der Website beschrieben.

Strategieentwicklung Im Rahmen des Servicemanagements umfasst Strategieentwicklung (strategy generation) vier Aufgaben (vgl. Lerneinheiten SITAN, SZIEL, STRAT und SPLAN):    

Marktdefinition (Für welche Kundengruppen können welche IT-Services angeboten werden, um welche betrieblichen Aufgaben zu unterstützen?) Angebotsentwicklung (Welche Services sollen angeboten werden, um Kundenbedürfnisse befriedigen zu können?) Ressourcenbereitstellung (Welche Ressourcen und Fertigkeiten sind erforderlich, um ITServices anbieten zu können?) Vorbereitung der Strategieausführung (Welche strategischen Ziele sollen verfolgt werden? Welche Ressourcen und Fertigkeiten sind bereits vorhanden, welche müssen entwickelt werden? Welches sind kritische Erfolgsfaktoren? Welche Prioritäten sollen gesetzt werden? Wie kann die Erreichung der strategischen Ziele gemessen werden?)

Management des Serviceportfolios Ein Serviceportfolio gibt eine Übersicht über die vom IT-Dienstleister angebotenen, geplanten und in Entwicklung befindlichen sowie die von Kunden nachgefragten IT-Services. Das Management des Serviceportfolios (portfolio management) umfasst die Planung, Steuerung und Kontrolle des Serviceportfolios. Dabei sind folgende Fragen zu beantworten:  

Ist das Serviceportfolio geeignet, aktuelle und zukünftige Informationsbedarfe (vgl. Lerneinheit INBAN) der Kunden zu befriedigen? Welche IT-Services werden zurzeit und in Zukunft vom IT-Dienstleister angeboten?

312

 

Administrative Aufgaben des Informationsmanagements

Welche IT-Services werden zwar von den Kunden benötigt, aber nicht vom internen ITDienstleister angeboten und müssen deshalb von einem externen Dienstleister bezogen werden (vgl. Lerneinheit OUTSO)? Wie muss das Portfolio entwickelt werden, um die voraussichtlich zukünftige Nachfrage nach IT-Services befriedigen zu können (vgl. Lerneinheit SPLAN)?

Finanzmanagement Finanzmanagement (financial management) umfasst Budgetierung, Kalkulation, Preisgestaltung sowie Berichtswesen. Budgetierung bezeichnet die Planung der für die IT (z. B. im nächsten Geschäftsjahr) notwendigen finanziellen Ressourcen (vgl. Lerneinheit SPLAN). Kalkulation von IT-Services (vgl. Lerneinheit KOLER) ermittelt auf der Basis erwarteter Kosten für die Inputfaktoren (z. B. Personal, Hardware, Softwarelizenzen, Energie) sowie der erwarteten Inanspruchnahme durch die Kunden Kosten für die IT-Services. Zwischen ITDienstleister und Kunden werden Vereinbarungen zur Preisgestaltung getroffen sowie Preise für IT-Services für die nächste Rechnungsperiode getroffen. Dem Top-Management werden außerdem regelmäßig aktuelle Werte von Kennzahlen zur Kontrolle der Wirtschaftlichkeit der IT zur Verfügung gestellt (vgl. Lerneinheiten CONTR, KENNZ und WIRTA). Typische Beispiele für Kennzahlen sind die IT-Kosten pro Jahr, die Höhe der IT-Kosten pro Mitarbeiter oder die prozentuale Abweichung der Istkosten von den Plankosten für IT-Services oder die gesamte IT.

Bedarfsmanagement Bedarfsmanagement (demand management) hat das Ziel, den Bedarf an IT-Services jederzeit befriedigen zu können. Es bewegt sich in dem Spannungsfeld, IT-Ressourcen einerseits zu möglichst niedrigen Kosten bereitstellen zu müssen, andererseits erforderliche Ressourcen auch bei unerwarteten Bedarfsausweitungen in ausreichender Kapazität und Qualität bereitstellen zu können (vgl. Abschnitt Kapazitätsmanagement).

Management des Servicekatalogs Die vom IT-Dienstleister angebotenen Services werden in einem Servicekatalog beschrieben. Darin werden Ziele, Leistungen, Preise, Ansprechpartner sowie Bestell- bzw. Beauftragungsmodalitäten für jeden IT-Service spezifiziert. Management des Servicekatalogs bezweckt, dass alle Informationen zu den IT-Services verständlich, aktuell und konsistent sind.

Serviceebenenmanagement Aufgabe des Serviceebenenmanagements (service level management) ist die Planung, Steuerung, Kontrolle und kontinuierliche Verbesserung des Qualitätsniveaus von IT-Services. Das für das Serviceebenenmanagement charakteristische Instrument sind SLA (vgl. Lerneinheit SEVER), in denen Anbieter und Kunden von IT-Services geforderte Qualitätsmerkmale (vgl. Lerneinheit QUALM) und deren Ausprägungen festlegen und diese mit einem bestimmten Preis für die Dienstleistung verbinden. Der IT-Dienstleister muss die Voraussetzungen dafür schaffen, dass das von den Partnern vereinbarte Qualitätsniveau zu akzeptablen Preisen erbracht werden kann. Er muss die Qualitätsniveaus der IT-Services kontinuierlich überwa-

Servicemanagement (SEMAN)

313

chen, um Verbesserungsmaßnahmen einleiten zu können, wenn die Qualität unter das mit dem Kunden vereinbarte Niveau sinkt. Zu diesem Zweck nutzt der IT-Dienstleister bestimmte Kennzahlen (vgl. Lerneinheiten KENNZ und SEVER). Deren Werte werden regelmäßig erhoben und dokumentiert, um sowohl dem Kunden als auch dem Dienstleister die Überprüfung der Einhaltung der SLA zu ermöglichen. Um die Verfügbarkeit von IT-Services sicherzustellen, ist eine enge Abstimmung mit Kapazitäts-, Verfügbarkeits-, Störungs- und Problemmanagement nötig (vgl. folgende Abschnitte). Die Abstimmung zwischen Serviceebenen- und Finanzmanagement schafft die Grundlage dafür, IT-Services zu angemessenen Preisen anbieten zu können.

Kapazitätsmanagement Um IT-Services in der vereinbarten Qualität und zu angemessenen Kosten erbringen zu können, sorgt Kapazitätsmanagement (capacity management) dafür, dass Ressourcen der Informationsinfrastruktur in ausreichender Art und Menge zur Verfügung stehen. Dies erfordert Informationen über die derzeitige und zukünftige Nachfrage nach IT-Services, eine umfassende Aufstellung der Ressourcen, die für den Betrieb von IT-Services notwendig sind, eine fortwährende Überprüfung der aktuellen und eine Prognose der zukünftigen Auslastung von Ressourcen sowie eine Anpassung der Ressourcen an Veränderungen oder erwartete Veränderungen der Nutzung von IT-Services.

Verfügbarkeitsmanagement Verfügbarkeit bedeutet, dass Nutzer IT-Services mindestens in der in den SLA vereinbarten Qualität verwenden können. Verfügbarkeitsmanagement (availability management) soll ein auf die Kunden abgestimmtes Verfügbarkeitsniveau gewährleisten. Dies setzt voraus, dass alle zur Erfüllung von IT-Services notwendigen Elemente der Informationsinfrastruktur (z. B. Personal, Hard- und Softwareressourcen sowie von Lieferanten bezogene Dienstleistungen) in der vereinbarten Qualität nutzbar sind. Die Verfügbarkeit der IT-Services muss auch im Notfall (vgl. Lerneinheit NOMAN) und bei Änderungen der Informationsinfrastruktur (vgl. Abschnitt Änderungsmanagement) aufrechterhalten oder zumindest in einem definierten Zeitraum wiederhergestellt werden können. Durch Identifizieren von Sicherheitsrisiken für IT-Komponenten und die Realisierung von Sicherungsmaßnahmen (vgl. Lerneinheit SIKON) soll die Verfügbarkeit der Informationsinfrastruktur erhöht werden. Typische Aufgaben sind die Überwachung und Wartung der Betriebsmittel. Durch Erkennen von potenziellen Fehlerquellen kann die Anzahl der Störungen reduziert werden.

Notfallmanagement Notfallmanagement (continuity management) sorgt für die Wiederherstellung der Verfügbarkeit der IT-Infrastruktur im Falle von schwerwiegenden Störungen. Risiken sollen minimiert und nicht vermeidbare Ausfallzeiten reduziert werden. Notfallmanagement (vgl. Lerneinheit NOMAN), auch als Katastrophenmanagement bezeichnet, umfasst Vorsorge-, Einsatz- und Wiederanlaufplanung sowie die Realisierung von Maßnahmen, die helfen, die Eintrittswahrscheinlichkeit von Notfällen und damit verbundene Schäden zu reduzieren, im Notfall geeignete Maßnahmen zu ergreifen sowie die Verfügbarkeit der IT-Services so schnell wie möglich wieder herzustellen. Zwischen Notfall- und Sicherheitsmanagement

314

Administrative Aufgaben des Informationsmanagements

(vgl. Lerneinheiten NOMAN und SICHM) besteht ein enger Zusammenhang; so muss ein Sicherheitskonzept z. B. einen Notfallplan beinhalten.

Sicherheitsmanagement Ziel des Sicherheitsmanagements (security management) ist es, ein definiertes Niveau an Sicherheit der Informationsinfrastruktur festzulegen, einzuführen und zu erhalten. Sicherheitsmanagement ist die Gesamtheit der Führungsaufgaben, die sich mit der Sicherheit der Informationsinfrastruktur befassen. Das wichtigste Hilfsmittel ist ein Sicherheitsmanagement-System (vgl. Lerneinheit SICHM).

Lieferantenmanagement IT-Bereiche bedienen sich der Hilfe von Lieferanten, z. B. von Hardwareherstellern, Softwarehäusern, Beratern, Telekommunikations- und Energieversorgungsunternehmen. Es ist sicherzustellen, dass die gelieferten Produkte und Dienstleistungen alle Qualitätsanforderungen erfüllen, die notwendig sind, damit der IT-Bereich die mit den Kunden vereinbarten SLA einhalten kann. Lieferantenmanagement (supplier management) umfasst die Gesamtheit der Führungsaufgaben zur Gestaltung der Beziehungen des IT-Bereichs zu seinen Lieferanten. Beschaffungsrichtlinien beschreiben die Grundsätze des Umgangs mit Lieferanten, insbesondere wie diese identifiziert, evaluiert, ausgewählt und im Laufe der Geschäftsbeziehung bewertet werden. An der Schnittstelle zwischen Lieferanten- und Serviceebenenmanagement wird festgelegt, wie der IT-Bereich aus den SLA mit seinen Kunden Qualitätsanforderungen an die von Lieferanten bezogenen Produkte und Dienstleistungen ableitet (vgl. Lerneinheit SEVER) und in Verträgen festhält (vgl. Lerneinheit VERMA). Lieferantenmanagement umfasst außerdem die Benennung von Kontaktpersonen zu den Lieferanten, die Überwachung der Zuverlässigkeit, Pünktlichkeit und des Preisniveaus der Lieferanten im Vergleich zu alternativen Anbietern sowie Mechanismen zur Konfliktlösung.

Konfigurationsmanagement und Asset Management Konfigurationsmanagement (configuration management) soll den Bestand an Configuration Items und deren Verwendung für IT-Dienstleistungen transparent machen und dem ITManagement Informationen zur Verfügung stellen, die für schnelles Problemlösen erforderlich sind. Die oft über Jahre gewachsenen, komplexen IT-Strukturen sollen erfasst und die Beziehungen zwischen den IT-Komponenten identifiziert werden. Die Bestandsverwaltung – ein logisches Abbild dieser IT-Komponenten, ihrer Eigenschaften, Beziehungen und Entwicklung – erfordert den Aufbau und die Pflege einer Configuration Management Database (CMDB). Attribute der Komponenten sind beispielsweise: Name, Kategorie (z. B. Hardware, Software, Dokument), Status (geplant, bestellt, im Test, archiviert usw.), Beziehungen zu anderen Komponenten (z. B. ist Element von, ist gespeichert auf, wird benötigt für etc.) sowie verantwortliche Mitarbeiter. Mit dem Konfigurationsmanagement eng verwandt ist das Asset Management. Während Konfigurationsmanagement in erster Linie den ordnungsmäßigen Betrieb von IT-Services unterstützt, ermöglicht Asset Management die Lenkung von IT-Komponenten aus rechtlicher und finanzieller Perspektive. Asset Management sorgt für die Einhaltung rechtlicher Rah-

Servicemanagement (SEMAN)

315

menbedingungen (in erster Linie von Lizenzvereinbarungen, vgl. Lerneinheit VERMA) und für die Reduzierung der Ausgaben für IT-Komponenten (z. B. indem unnötige Wartungsverträge gekündigt werden). Das Asset Management führt ein Bestandsverzeichnis aller ITKomponenten mit Informationen über Hersteller bzw. Lieferanten, Lizenzbedingungen, Garantien, Wartungsverträgen, Leasingraten, Lizenzgebühren und gegebenenfalls Betriebskosten. Asset Management erstellt Informationsquellen für die IT-Revision (vgl. Lerneinheit REVIS), das Controlling (vgl. Lerneinheit CONTR) sowie für das Finanzmanagement.

Änderungsmanagement Eine Änderung bezeichnet das Modifizieren, Hinzufügen oder Beseitigen von Elementen der Informationsinfrastruktur, unabhängig davon, wie umfangreich die Änderung ist (z. B. Einführung eines ERP-Systems oder Veränderung des Passworts eines Mitarbeiters für ein Anwendungssystem). Änderungsmanagement (change management) stellt sicher, dass Änderungen nach festgelegten Richtlinien ablaufen. Änderungsmanagement hat zum Ziel, Beeinträchtigungen von IT-Services zu reduzieren, die als Folge von geplanten Änderungen der IT-Infrastruktur auftreten können. Wesentliches Formalziel ist die Sicherstellung der Effizienz von Änderungen. Teilaufgaben des Änderungsmanagements sind:        

Festlegung von Methoden, Rollen und Verantwortungsbereichen für Änderungen, Sammlung, Analyse, Bewertung und Priorisierung von Change Requests, Planung von Änderungen (Aufwandsschätzung, Zeit- und Ressourcenplanung), Entscheidung über die Genehmigung und Durchführung von Änderungen, Information der von Änderungen Betroffenen (z. B. Systemadministratoren und Nutzer), Dokumentation von Änderungen, gegebenenfalls Projektmanagement bei umfangreichen Änderungen sowie Prüfung der Qualität und Freigabe durchgeführter Änderungen.

Versions- und Bereitstellungsmanagement Ziel des Versionsmanagements (release management) ist es, die Einhaltung rechtlicher Rahmenbedingungen bei der Softwarenutzung zu gewährleisten und einen möglichst störungsfreien Betrieb von Hardware-Software-Konfigurationen zu unterstützen. Versionsmanagement soll sicherstellen, dass ausschließlich zur Nutzung freigegebene Hard- und Softwareversionen verwendet werden und dass jederzeit nachvollzogen werden kann, welche Softwareversionen auf welchen Hardwaresystemen im Einsatz sind. Insofern gibt es einen engen Zusammenhang zwischen Asset- und Versionsmanagement. Teilaufgaben des Versionsmanagement sind:   

Lenkung des Übergangs von Entwicklung oder Wartung von Software in den Betrieb, Planung, Steuerung und Kontrolle der Einführung, Verteilung und Installation neuer Softwareversionen, d. h. Software-Rollout, sowie Verhinderung, dass illegale oder nicht ausreichend getestete Software eingesetzt wird.

Hilfsmittel des Versionsmanagements sind eine Software-Bibliothek, in der Master-Kopien aller eingesetzten Softwareversionen gespeichert sind, Werkzeuge zur automatischen Distribution und Installation neuer Softwareversionen sowie eine Versionsdatenbank, in der alle

316

Administrative Aufgaben des Informationsmanagements

gültigen Softwareversionen, zugehörige Lizenzvereinbarungen sowie Verwendungszwecke und -orte der Software verzeichnet sind. Diese Datenbank kann Element der CMDB sein. Bereitstellungsmanagement (deployment management) bezweckt, dass neue oder veränderte IT-Services den Nutzern gemäß den spezifizierten Anforderungen zur Verfügung gestellt werden. Um betriebliche Abläufe möglichst wenig zu stören, sollen verschiedene Änderungen an einem Service zu einer Version zusammengefasst werden. Außerdem ist die Bereitstellung mit Nutzern und Wartungspersonal abzustimmen.

Wissensmanagement Wissensmanagement (knowledge management) (vgl. Lerneinheit WIMAN) soll sicherstellen, dass für Servicemanagement nötiges Fachwissen dokumentiert und für die Mitarbeiter zugänglich ist. Dazu dient ein auf der CMDB aufbauendes Service Knowledge Management System.

Störungsmanagement Störungsmanagement (incident management) hat die Aufgabe, den Lebenszyklus (vgl. Lerneinheit LEMAN) von Störungen zu planen, zu steuern und zu kontrollieren. Das primäre Ziel des Störungsmanagements besteht darin, eine beeinträchtigte IT-Dienstleistung so schnell wie möglich wieder herzustellen und negative Auswirkungen auf betriebliche Aufgaben so gering wie möglich zu halten. Störungen werden registriert, klassifiziert, priorisiert, überwacht, behoben, gegebenenfalls eskaliert und abgeschlossen. Ursachen von Störungen, die sich nicht leicht beheben lassen, werden an das Problemmanagement verwiesen. Input für das Störungsmanagement sind Fehlermeldungen oder Anfragen durch Nutzer von ITServices, durch IT-Mitarbeiter oder Meldungen von Überwachungssystemen (z. B. von Brandfrüherkennungsmeldern, vgl. Lerneinheit INMAN). Teilaufgaben des Störungsmanagements sind:      

Erkennung und Erfassung von Störungen, Klassifizierung (Kategorisierung und Priorisierung) von Störungen, Entwicklung erster Lösungsvorschläge für Störungen, die sich leicht beheben lassen, Verfassung von Anträgen auf Diagnose und Behebung komplizierter Störungen an das Problemmanagement, Überwachung der Lösungssuche und Störungsbehebung (inklusive Auskunft über den aktuellen Status der Störungsbehebung an die Nutzer) sowie Behebung von Störungen (inklusive Information der Nutzer von betroffenen IT-Services und Dokumentation der Störungsbehebung).

Die Anlaufstelle für Nutzer gestörter IT-Services ist der Service Desk. Dieser nimmt Störungsmeldungen – in der Regel mit Hilfe eines Call Centers oder eines UMS – entgegen, formuliert Lösungsvorschläge und stellt sicher, dass Störungen innerhalb der in den SLA spezifizierten Reaktionszeit behoben werden. Die Mitarbeiter des Service Desks bedienen sich einer Fehlerdatenbank, in der Symptome von Fehlern und Problemen aufgezeichnet sind sowie Hinweise zur Störungsbehebung gegeben werden.

Servicemanagement (SEMAN)

317

Problemmanagement Ein Problem bezeichnet eine (noch) unbekannte Ursache für eine oder mehrere Störungen. Problemmanagement (problem management) hat die Aufgabe, Ursachen von Störungen zu finden und zu beheben sowie Lösungen zu entwickeln, die helfen, Eintrittswahrscheinlichkeit und unerwünschte Konsequenzen von Störungen zu reduzieren. Das Problemmanagement erarbeitet Problem- und Fehlerbeschreibungen, Möglichkeiten zur Behebung von Störungen (work arounds) sowie Berichte über die Behebung von Störungsursachen und Fehlern. Problemmanagement soll Anzahl und Schwere von Störungen durch strukturelle Verbesserung der IT-Infrastruktur reduzieren. Hilfreich hierfür ist die Analyse von Trends beim Störungsmanagement, um den Störungen zugrunde liegende Ursachen aufzudecken. Der Aufbau einer Datenbank über Störungen und deren Behebung unterstützt die Lösung zukünftiger Probleme, insbesondere von Wiederholungsproblemen. Ein proaktives Problemmanagement führt zu Empfehlungen für die Veränderung der IT-Infrastruktur. Falls zur Lösung aktueller Probleme oder zur Vermeidung potenzieller Störungen Veränderungen der ITInfrastruktur erforderlich sind, erzeugt das Problemmanagement Change Requests, die vom Änderungsmanagement bearbeitet werden.

Rahmenwerke für das Servicemanagement Es gibt verschiedene Rahmenwerke für das Servicemanagement, die zum Teil herstellerspezifisch (z. B. Hewlett-Packard IT-Servicemanagement-Referenzmodell, IBM Process Reference Model for IT oder Microsoft Operations Framework) und zum Teil unabhängig von einzelnen Herstellern sind. Die weltweit bekanntesten und am stärksten verbreiteten Rahmenwerke sind ITIL und ISO/IEC 20000.

ITIL Die Information Technology Infrastructure Library (ITIL) wurde in den 1980er Jahren zunächst von der Central Computer and Telecommunications Agency (CCTA) sowie später vom OGC im Auftrag der britischen Regierung entwickelt. Die folgenden Ausführungen beziehen sich auf die ITIL Version 3, die 2007 publiziert wurde. Disterer (531) beschreibt ITIL als Referenz- oder Rahmenmodell, mit dem IT-Leistungen geplant, überwacht und gesteuert werden können. ITIL gliedert das Servicemanagement in fünf Bereiche: Service Strategy definiert die grundsätzliche Ausrichtung des Servicemanagements. Angebot und Nachfrage nach ITServices werden beschrieben sowie für die Leistungserstellung notwendige Organisationsstrukturen, Aufgaben und Rollen. Service Design umfasst Entwurf und Spezifikation von ITServices. Hier wird festgelegt, auf welche Weise und mit welchen Hilfsmitteln IT-Services entworfen, definiert, implementiert und verändert werden. Service Transition definiert alle Aufgaben, die für die Einführung von IT-Services erforderlich sind. Service Operation fasst alle Aufgaben zusammen, die während der Leistungserstellung, d. h. während des Betriebs von IT-Services, notwendig sind, und die sicherstellen sollen, dass alle relevanten Anforderungen an die IT-Services erfüllt werden. Continual Service Improvement beschreibt, wie Services kontinuierlich verbessert werden können. Für jeden Bereich werden Aufgaben,

318

Administrative Aufgaben des Informationsmanagements

Methoden und Werkzeuge, Struktureinheiten, Verantwortungsbereiche und Rollen beschrieben. Abbildung SEMAN-1 gibt einen Überblick über die Elemente von ITIL. Service Strategy Strategy Generation Service Portfolio Management Financial Management Demand Management Service Design Service Catalogue Management Service Level Management Capacity Management Availability Management Continuity Management Information Security Management Supplier Management

The 7-Step Improvement Process

Service Operation Event Management Incident Management Request Fulfilment Problem Management Access Management

Service Transition Transition Planning and Support Asset and Configuration Management Change Management Release and Deployment Management Service Validation and Testing Evaluation Knowledge Management Continual Service Improvement

Service Reporting

Measurement

Business Questions for CSI

Return on Investment for CSI

Abb. SEMAN-1: Struktur und Elemente von ITIL

Neben sechs Büchern (OGC, Iqbal/Nieves, Rudd/Lloyd, Lacy/MacFarlane, Cannon/Taylor/ Wheeldon, Spalding/Case), in denen ITIL beschrieben ist, werden Beratung, Schulung, Berufsqualifizierung und entsprechende Zertifizierung sowie Softwarewerkzeuge zur Unterstützung des Servicemanagements angeboten. Eine Zertifizierung von Servicemanagementsystemen erfolgt nicht auf der Basis von ITIL, sondern von ISO/IEC 20000.

ISO/IEC 20000 ISO/IEC 20000 wurde 2005 veröffentlicht und ist aus ITIL und dem British Standard 15000 hervorgegangen. ISO/IEC 20000 beschreibt ähnliche Inhalte wie ITIL, allerdings weniger detailliert. Der Zweck der Norm besteht darin, eine Grundlage für die Zertifizierung von IT-Servicemanagementsystemen zu schaffen. Die Norm besteht aus zwei Teilen. Teil 1 formuliert Anforderungen an das Servicemanagement. Teil 2 gibt Empfehlungen zur Umsetzung. Neben der Klärung von Begriffen sowie Ausführungen zum Geltungsbereich, zur Planung und Einführung des Servicemanagements, zu Anforderungen an IT-Servicemanagementsysteme sowie zur Planung und Einführung neuer und geänderter IT-Services gliedert ISO/IEC 20000 das IT-Servicemanagement in fünf Prozessgruppen: Service Delivery Processes beschreiben Aufgaben, die für den Betrieb von IT-Services benötigt werden. Control Processes bezeichnen Konfigurations- und Änderungsmanagement, der Release Process das

Servicemanagement (SEMAN)

319

Versionsmanagement. Resolution Processes beschreiben die Behebung von Störungen und Problemen und Relationship Processes die Gestaltung der Beziehungen zu Kunden und Lieferanten.

Forschungsbefunde Marrone/Kolbe haben Vorteile und Herausforderungen analysiert, die mit IT-Servicemanagement gemäß ITIL verbunden sind (Online-Befragung von mehr als 5000 ITFührungskräften in vorwiegend amerikanischen und britischen Unternehmen, 491 auswertbare Antworten, Untersuchungszeitraum April bis Mai 2009). Die Teilnehmer nannten folgende Vorteile: Erhöhung der Servicequalität (58 % der Teilnehmer), der Standardisierung von IT-Prozessen (52 %) sowie der Kundenzufriedenheit (43 %). Nur wenige Teilnehmer nennen einen erhöhten Return on Investment der IT (13 %), eine bessere Arbeitsmoral des ITPersonals (13 %) und einen größeren finanziellen Beitrag der IT zum Geschäft (11 %) als Vorteile. Die Befragten wurden gebeten, Herausforderungen auf einer Skala von 1 bis 5 einzuordnen, wobei 1 keine und 5 große Herausforderung bedeutet. Große Herausforderungen sind Mangel an Ressourcen, Widerstand der Organisation sowie Erhalt der dynamischen Entwicklung/Fortschritt stagniert. Die geringsten Herausforderungen sind das Fehlen von Wissen und Fähigkeiten, sowie die Unterstützung durch die Geschäftsleitung. Marrone/ Kolbe untersuchten auch den Zusammenhang zwischen der von den Teilnehmern wahrgenommenen Reife (vgl. Lerneinheit MEQUA) des Servicemanagements, der Anzahl der implementierten Teilaufgaben sowie Vorteilen und Herausforderungen. Je mehr ITILTeilaufgaben implementiert sind, desto höher schätzen die Teilnehmer den Reifegrad des Servicemanagements ein. Je höher der Reifegrad, desto umfangreicher die von den Teilnehmern berichteten Vorteile und desto geringer die wahrgenommenen Herausforderungen.

Aus der Praxis Nach Disterer hatten bis Juli 2009 in Europa 145 Unternehmen ihr Servicemanagement nach ISO 20000 zertifizieren lassen, davon 27 in Deutschland. Ende Mai 2011 waren laut itSMF in Europa 230 ISO-20000-Zertifikate erteilt worden, davon in Deutschland 35, in Österreich 11 und in der Schweiz 18. Tan/Cater-Steel/Toleman beschreiben die Servicemanagement-Implementierung bei Queensland Health, einer australischen Gesundheitsbehörde mit insgesamt ca. 50.000 Mitarbeitern, darunter 800 Mitarbeitern im IT-Bereich. 2005 wurden zunächst zwei erfolglose Versuche unternommen, Servicemanagement zu etablieren. Die Autoren identifizieren folgende kritische Erfolgsfaktoren der geglückten Einführung zwischen 2005 und 2007: aktive Mitarbeit von Mitgliedern der Geschäftsleitung an der Einführung des Servicemanagements, ein engagierter Projektleiter („project champion“), ein Änderungsmanagement, welches die Organisationskultur serviceorientiert ausrichtet, enge Beziehungen zu verschiedenen Beratern und Techniklieferanten, wodurch ein Wissenstransfer an die Mitarbeiter sichergestellt wurde, Dokumentation und Kommunikation der Vorteile der einzelnen Teilaufgaben des Servicemanagements bei Queensland Health sowie klare Leitungsstrukturen für die Servicemanagement-Implementierung.

320

Administrative Aufgaben des Informationsmanagements

Methodenverweise Kennzahlensysteme (Lerneinheit KENNZ); Methoden des Geschäftsprozessmanagements (Lerneinheit MEGPM); Kosten- und Leistungsrechnung (Lerneinheit KOLER); Methoden des Qualitätsmanagements (Lerneinheit MEQUA); Serviceebenen-Vereinbarungen (Lerneinheit SEVER). Kontrollfragen 1. Welche Zwecke werden mit IT-Servicemanagement verfolgt? 2. Wodurch unterscheiden sich Geschäftsprozessmanagement, IT-Servicemanagement und IT-Governance? 3. Welcher Zusammenhang besteht zwischen Störungs-, Problem- und Änderungsmanagement? 4. Welches sind typische Business Services, die ein interner IT-Bereich Fachabteilungen anbietet? 5. Welche Bedeutung hat IT-Servicemanagement für die Erreichung der strategischen IT-Ziele? Quellen Cannon, D. / Taylor, S. / Wheeldon, D.: ITIL Service Operation. London 2007 Disterer, G.: Zertifizierung der IT nach ISO 20000. In: WIRTSCHAFTSINFORMATIK 6/2009, 530–534 Iqbal, M. / Nieves, M.: ITIL Service Strategy. London 2007 Lacy, S. / MacFarlane, I.: ITIL Service Transition. London 2007 Marrone, M. / Kolbe, L. M.: Einfluss von IT-Service-Management-Frameworks auf die IT-Organisation. Eine empirische Studie zu Vorteilen, Herausforderungen und Prozessen. In: WIRTSCHAFTSINFORMATIK 1/2011, 5–19 Office of Government Commerce (OGC): The Official Introduction to the ITIL Service Lifecycle. London 2007 Rudd, C. / Lloyd, V.: Service Design (ITIL), Version 3. London 2007 Spalding, G. / Case, G.: ITIL Continual Service Improvement London 2007 Tan, W.-G. / Cater-Steel, A. / Toleman, M.: Implementing IT Service Management: A Case Study Focussing on Critical Success Factors. In: Journal of Computer Information Systems 2/2009, 1–12 Vertiefungsliteratur Beims, M.: IT-Service Management in der Praxis mit ITIL 3: Zielfindung, Methoden, Realisierung 2. A., München 2009 Bernhard, M. G. et al. (Hrsg.): Praxishandbuch Service-Level-Management: Die IT als Dienstleistung organisieren. 2. A., Düsseldorf 2006 Böhmann, T. / Krcmar, H.: Grundlagen und Entwicklungstrends im IT-Servicemanagement. In: HMD – Praxis der Wirtschaftsinformatik 237/2004, 7–21 Böttcher, R.: IT-Servicemanagement mit ITIL V3: Einführung, Zusammenfassung und Übersicht der elementaren Empfehlungen. Hannover 2007 Ebel, N.: ITIL V3 Basis-Zertifizierung: Grundlagenwissen und Zertifizierungsvorbereitung für die ITIL FoundationPrüfung. München 2008 Olbrich, A.: ITIL kompakt und verständlich: Effizientes IT Service Management – Den Standard für IT-Prozesse kennenlernen, verstehen und erfolgreich in der Praxis umsetzen. 4. A., Wiesbaden 2008 Informationsmaterial Hewlett-Packard ITSM reference model http://www.hp.com IBM Process Reference Model for IT (PRM-IT) http://www.ibm.com ISO/IEC 20000 Certification http://www.isoiec20000certification.com ITIL, BS15000 & ISO 20000 User Group http://www.15000.net ITIL Open Guide http://www.itlibrary.org ITIL org http://www.itil.org IT Process Maps http://www.it-processmaps.com IT Service Management Forum (itSMF) http://www.itsmfi.org Microsoft Operations Framework (MOF) http://www.microsoft.com Official ITIL Website http://www.itil-officialsite.com/home/home.asp OGC http://www.ogc.gov.uk OGC: Best Management Practice for Project, Programme, Risk and Service Management http://www.bestmanagement-practice.com Normen ISO/IEC 20000-1:2005. Information Technology - Service Management - Part 1: Specification ISO/IEC 20000-2:2005. Information Technology - Service Management - Part 2: Code of Practice

Infrastrukturmanagement (INMAN) Lernziele Sie kennen den Zweck des Infrastrukturmanagements, können daraus die zugehörigen Aufgaben ableiten sowie deren Umsetzung im Rechenzentrumsmanagement erklären. Sie kennen die Hauptkategorien im Bereich der Infrastruktur und können deren wichtigste Bestandteile sowie Basis-Technologien erklären (z. B. Virtualisierung). Sie kennen Cloud Computing und können die damit verbundenen Aufgaben des Infrastrukturmanagements erklären.

Definitionen und Abkürzungen Arbeitsvorbereitung (job scheduling) = Planung, Überwachung und Steuerung aller für die Durchführung der Produktion erforderlichen Tätigkeiten (abgek. AV). Synonym: Fertigungsvorbereitung. Authentifikation (authentication) = Überprüfen der durch Identifikation behaupteten Identität eines Subjekts oder eines Objekts, das Zugang zu einem System haben will. Synonym: Authentifizierung. BPaaS / IaaS / PaaS / SaaS (Business Process | Infrastructure | Platform | Software-as-aService) = gängige Ausprägungen des Cloud Computings. Betriebsmittel (resource) = zur Abarbeitung von Aufträgen zur Verfügung stehende Hardware und Software, Personal und andere Hilfsmittel. DAS = Direct Attached Storage. Identifikation (identification) = Bestimmen der Identität eines Subjekts (z. B. Benutzer) oder eines Objekts (z. B. Programm), das Zugang zu einem System haben will. Synonym: Identifizierung. Kapazität (capacity) = mengenmäßiges Leistungsvermögen von Betriebsmitteln (z. B. Fassungsvermögen von Speichern). Leitstand (control command) = technische Einrichtung, die Menschen beim Leiten eines Prozesses unterstützt, wobei Leiten nach DIN 19222 die Gesamtheit aller Maßnahmen ist, die den zielkonformen Ablauf des Prozesses bewirken. NAS = Network Attached Storage. NEMP = Nucelar Electromagnetic Pulse. Operator (operator) = Mitarbeiter der Struktureinheit Operating, der ein IT-System von einem Leitstand aus bedient, ganzheitlich überwacht und steuert. RAID = Redundant Array of Independent Disks. Redundanz (redundancy) = Mehrfachauslegung eines Systems mit Systemteilen gleicher Funktion. RZ = Rechenzentrum (computing center, data center). Serviceebene (service level) = Qualitätsniveau einer Dienstleistung (Dienstgüte). SAN = Storage Area Network. USV = unterbrechungsfreie Stromversorgung (uninterruptable power supply/source). Verfügbarkeit (availability) = Fähigkeit eines Systems, seine konstruktionsbedingten Funktionen erfüllen zu können.

322

Administrative Aufgaben des Informationsmanagements

Zweck des Infrastrukturmanagements Alle für Geschäftskunden (business) und Verbraucher (consumer) angebotenen IT-Dienstleistungen – unabhängig, von wem, wie und wo erbracht – erfordern als technisches Fundament eine zugehörige Infrastruktur, die sich aus verschiedenen Hard- und Softwarekomponenten zusammensetzt: Server, Mainframes, Speicher, Netze, Netzverbindungen, Stromversorgung, Systemsoftware, Monitoring- und Steuerungssoftware und anderes mehr. Das Infrastrukturmanagement sorgt dafür, dass diese Komponenten abgestimmt zusammenwirken, um die individuell zu definierenden IT-Dienstleistungen („Produktionsdienstleistungen“) effektiv und effizient erbringen („produzieren“) zu können. Diese „Produktion“ wird aufbauorganisatorisch im Regelfall in einer eigenen IT-Struktureinheit abgebildet (vgl. Lerneinheit STRUK). Üblicherweise werden diese Organisationseinheiten IT-Abteilung, ORG/IT, IT-Center, Data Center oder Rechenzentrum (RZ) genannt, wobei das damit verbundene Dienstleistungsspektrum deutlich variieren kann (z. B. ausschließlich Management/Betrieb von IT-Infrastrukturen oder aber zusätzlich auch Softwareentwicklung und fachlicher Benutzer-Support). Der Umfang und die Komplexität der durch eine solche Organisationseinheit betreuten Infrastruktur haben entscheidenden Einfluss auf die zu erfüllenden Aufgaben: Ein Kleinunternehmen, das einen einzigen logischen Server mit den benötigten Anwendungen selbst betreibt, wird meist keine eigene Organisationseinheit einrichten, sondern einen Mitarbeiter mit der Systembetreuung beauftragen oder diese Dienstleistung extern erwerben. Ein Industriekonzern, eine Bankengruppe oder ähnliche Institutionen hingegen haben höchste Ansprüche an das Infrastrukturmanagement. Ein Rechenzentrum ist eine Struktureinheit, deren Aufgabe die Erbringung definierter Produktionsdienstleistungen von Information und Kommunikation nach Zeit, Menge und Qualität ist. Es kann auch als ein Bereich, eine Einrichtung oder ein Standort einer zentralen IT gesehen werden. Das Rechenzentrum kann als Abteilung eines Unternehmens oder als Stelle der IT-Abteilung ausgelegt sein und als Cost- oder Profit Center geführt werden (vgl. Lerneinheit STRUK). Es stellt dem eigenen oder auch anderen Unternehmen ITDienstleistungen gegen Verrechnung oder Entgelt zur Verfügung (vgl. Lerneinheit KOLER). Der Begriff Rechenzentrum wird weit gefasst und lässt per Definition eine hohe Bandbreite an möglichen Ausprägungen zu, beginnend von einem einzelnen Serverschrank bis hin zu einem Gebäudekomplex, von dem aus mit den darin betriebenen Systemen und Komponenten eine große Anzahl an Kunden mit IT-Dienstleistungen versorgt wird. Im Folgenden wird eine weit verbreitete Mischung aus klassischer und moderner Infrastruktur angenommen, in der neben Großrechnersystemen auf der Basis traditioneller Hardware- und Systemsoftwarearchitekturen auch „moderne“ Server- und Peripheriesysteme eingebunden sind. Die Begriffe „Tradition“ und „Moderne“ sind nicht wertend zu verstehen, sondern werden in einem entwicklungsgeschichtlichen, chronologischen Kontext verwendet. Die zunehmende Bedeutung des Infrastrukturmanagements ist nicht zuletzt an Themen wie Green IT und Cloud Computing zu erkennen. Unabhängig davon, ob diese Begriffe per se dauerhafte Relevanz aufweisen werden, sind die damit verbundenen Aufgaben des Infrastrukturmanagements fest etabliert.

Infrastrukturmanagement (INMAN)

323

Zu beobachten ist, dass durch die zunehmende Komplexität der Infrastruktur die Aufgaben des Infrastrukturmanagements meist nur von großen IT-Abteilungen und Rechenzentren auf breiter Basis und ganzheitlicher Ausprägung geleistet werden können. Die folgenden Erläuterungen zum Infrastrukturmanagement sind primär als Rechenzentrumsmanagement ausgeführt, wobei der Begriff Rechenzentrum auch synonym für „große IT-Abteilung“ zu lesen ist.

Aufgaben des Infrastrukturmanagements Aus dem Zweck von IT-Infrastrukturen, die Erreichung der Ziele der Kunden bestmöglich zu unterstützen, ergeben sich folgende Aufgaben des IT-Infrastruktur-Managements, wobei jede dieser Aufgaben in mehrere Teilaufgaben gegliedert wird:   

Location Management (Standortentscheidung und Gebäudearchitektur), Management der RZ-Ausstattung (mit Nicht-IT, IT und Sonstigem) und Management des RZ-Betriebs (Server- und Mainframe-Management, Netzmanagement, Speichermanagement, Verfügbarkeitsmanagement, Kapazitätsmanagement und Performance Management).

Location Management Die Aufgaben des Location Managements können in zwei Bereiche gegliedert werden. Der erste Bereich beschäftigt sich mit der Entscheidung über einen geeigneten RZ-Standort. Der zweite setzt voraus, dass ein Standort gefunden wurde und geht darauf ein, welche Fragen hinsichtlich der RZ-Architektur zu beantworten sind.

Standortentscheidung Eine wesentliche Anforderung für die Standortentscheidung ist, dass eine bestimmte Entfernung von Einrichtungen oder Gebieten eingehalten werden muss, die als gefährdet zu werten sind, beispielsweise durch Naturgegebenheiten (z. B. Hochwassergefährdung), Nähe zu kritischer Infrastruktur (z. B. Einflugschneisen, Industriekomplexe) oder auch durch Terrorpotenzial. Eine weitere wichtige Anforderung ist, dass eine ausreichend moderne technische Basis-Infrastruktur vorhanden sein muss (z. B. Möglichkeiten zur Anbindung an Stromnetze und an leistungsfähige Datenleitungen).

Gebäudearchitektur Bei der Planung und Errichtung eines Gebäudes sind rechenzentrumsspezifische Anforderungen an die Architektur der Räumlichkeiten zu beachten. Abhängig von den später durchzuführenden Dienstleistungen, den dafür notwendigen IT- und Nicht-IT-Systemen sowie der Peripherie ist festzulegen, welche und wie große, voneinander getrennte (Flächen-) Bereiche einzurichten sind. Bei der Beantwortung dieser Frage ist die Orientierung an der Unternehmensstrategie (vgl. Lerneinheit STRAT) erforderlich, um angestrebte oder nicht vermeidbare Änderungen (z. B. Expansion, Re-Dimensionierung, Umwidmung von Räumen) sowie geplante Erweiterungen des (technischen) Dienstleistungsangebots auf Infrastrukturebene grundsätzlich realisieren zu können. Ein kritischer Blick in die IT-Vergangenheit, die ab-

324

Administrative Aufgaben des Informationsmanagements

wechselnd von Trends zu Systemkompositionen bzw. Systemdekompositionen gekennzeichnet war, ist dabei hilfreich. 



Systemkompositionen treten bei Systemkonsolidierungen auf, wobei physisch und/oder logisch Hard- und Softwaresysteme mit den Zielen zusammengeführt werden, dass eine Verringerung von Platz- und Energiebedarf stattfindet und darüber hinaus weniger separat zu wartende Systeme existieren. Systemdekompositionen werden zumeist durchgeführt, um neue Technologien und Systeme über definierte Schnittstellen an die bestehende Infrastruktur anzubinden, hohe Flexibilität zu erreichen und anschaffungsbedingte Kosten für Standardsysteme niedrig zu halten.

Werden auch Druck- und Kuvertierstraßen zur Infrastruktur gezählt, ergibt sich ein deutlich größerer Raumbedarf. Eine weitere Aufgabe des Location Managements betrifft die physische Objektsicherheit. Die bereits erwähnten, abgetrennten RZ-Bereiche können zugleich Zonen mit unterschiedlichen Zutrittsberechtigungen repräsentieren. Der Zutritt darf ausschließlich autorisierten Personen möglich sein, nachdem eine Authentifikation erfolgt ist. Dies wird beispielsweise durch elektronische Zugangs- und Ausgangskontrollsysteme gewährleistet, bei denen Code-Eingaben, Chipkarten- und/oder biometrische Systeme eingesetzt werden (z. B. Fingerabdruckerkennung). Für besonders sensible Zonen kann es notwendig sein, das gleichzeitige Betreten durch mehrere Personen durch Vereinzelungsschleusensysteme zu verhindern. Location Management hat auch dafür zu sorgen, dass vorgegebene Spezifikationen der zu betreibenden Produktionssysteme (z. B. Plattenspeicher) eingehalten werden können (z. B. maximale Erschütterungsfaktoren). Es muss damit gerechnet werden, dass künftige Bauvorhaben in der RZ-Umgebung Erschütterungen des Untergrunds zur Folge haben, die sich negativ auf die Rechnersysteme und ihre Komponenten auswirken können. Eine wirksame Gegenstrategie ist die Ausführung eines Teils des Kellers des RZ-Gebäudes als Wannenkonstruktion für die Unterbringung besonders sensibler Systeme. Neben Standardbedrohungen wie Feuer, Wasser und Luftverunreinigungen müssen bestimmte RZ-Bereiche auch einem NEMP-Fall standhalten. Dabei handelt es sich um einen durch eine Atomexplosion ausgelösten Impuls, der über weite Strecken hinweg elektronische Systeme, die nicht entsprechend geschützt sind, außer Funktion setzen und zerstören kann. Speziell geschützte Zellen im Rechenzentrum (Raum im Raum) wirken als Faradayscher Käfig und schützen die darin enthaltenen Systeme gegen NEMP-Bedrohungen.

Management der RZ-Ausstattung Die RZ-Ausstattung umfasst die Komponenten der Nicht-IT, die IT-Betriebsmittel selbst und sonstige Ressourcen, die für die Erbringung von Dienstleistungen notwendig sind und die aus historischen Gründen den RZ-Aufgaben zugeordnet werden (z. B. Telefonversorgung).

Ausstattung mit Nicht-IT Unter Nicht-IT werden infrastrukturelle Einrichtungen und Betriebsmittel zusammengefasst, die zwar für den RZ-Betrieb notwendig, aber auf logischer Ebene nicht den betriebenen IT-

Infrastrukturmanagement (INMAN)

325

Systemen zuzuordnen sind. Eine der wichtigsten RZ-Ressourcen ist Energie in Form von Strom, physikalisch gesehen das Stromnetz. Um ausgleichen und gleichzeitig Unter- oder Überspannungen entgegenwirken zu können, werden USV-Geräte eingesetzt. Da dieses Konzept wegen der eingeschränkt speicherbaren Energie in Akkumulatoren nur kurzfristig Hilfe bietet, sind unternehmenskritische Systeme zusätzlich mit Notstromgeneratoren (zumeist auf Basis von Dieselmotoren) zu versorgen. Diese können im Notfall innerhalb kürzester Zeit in Betrieb genommen werden und lösen die USV nahtlos ab. Rechenzentren verfügen daher zumeist über große Dieseltanks zur Versorgung der Notstromgeneratoren. Im Zusammenhang mit dem Energiebedarf wurde in den letzten Jahren Green IT zum wichtigen Thema (vgl. Lerneinheit STRAT). Als Oberbegriff bezieht sich Green IT auf ganzheitliche Ansätze für den Umwelt schonenden Einsatz von Informations- und Kommunikationstechnologien. Green IT im engeren Sinne zielt darauf ab, die Energienutzung (insbesondere den Stromverbrauch für IT-Komponenten und Kühlung) durch spezifische organisatorische und technische Maßnahmen zu verbessern. Im weiteren Sinne betrachtet Green IT die gesamte IT-Supply-Chain (bis zum Recycling von Hardware jeder Art) und hat damit die direkte und indirekte Schonung der Umwelt als oberste Zielsetzung. Das Thema an sich ist nicht neu, da Energieeffizienz schon aus ökonomischen Gründen traditionell ein wichtiges Planungs- und Betriebskriterium für Infrastrukturbetreiber ist und damit Ökonomie und Ökologie sehr gut vereint. Seit dem Jahrtausendwechsel ist das Thema allerdings zunehmend stärker in das allgemeine Bewusstsein gelangt, nicht zuletzt auf Grund der weltweiten energiepolitischen Diskussion. Alle namhaften IT-Hersteller bieten konkrete Lösungen an. Es werden aber auch IT-Standardtechnologien mit dem Thema Green IT in Zusammenhang gebracht (z. B. Virtualisierung, siehe weiter unten) oder das Drucker-Management. Green IT ist jedenfalls eine wichtige Aufgabe des Infrastrukturmanagements, unabhängig davon, wo im konkreten Fall die Grenze zwischen „echten grünen Technologien“ und „grüner Vermarktung“ zu ziehen ist. Neben dem Stromnetz ist das Datennetz erfolgskritisch. Man unterscheidet zwischen den Anbindungen an externe Netze (insbesondere das Internet), der internen Verbindung zwischen den Geräten im Rechenzentrum selbst und der Anbindung der Geräte beim Kunden. Vor allem das erste und das dritte genannte Netz sollten aus Verfügbarkeitsgründen mehrfach redundant ausgelegt sein. Kühlung und Belüftung sind weitere wichtige Nicht-IT-Komponenten. Die Kühlung erfolgt meist durch zentrale Klimaanlagen, wobei die Spezifikationen aller Systeme (Rechner und Peripherie) individuell beachtet werden müssen. Überschüssige warme Abluft muss in entsprechenden Kanälen von den Systemen wegtransportiert, kühle Luft muss zugeführt werden. Belüftete Böden können helfen, die Luftzirkulation zu verstärken. Neben den aufwendigen Kühlinstallationen müssen verschiedene Sensoren platziert und überwacht werden. Beispielsweise ermitteln Erschütterungsmelder Beben in den Systemräumen, die unterschiedliche Ursachen haben können. Genauso helfen Gas- und optische Brandfrüherkennungsmelder, Bedrohungen zu erkennen. Im Falle eines Feuerausbruchs kommen Löschanlagen mit einem umweltverträglichen Argon-Trigon-Gasgemisch, das in einem Tank gelagert wird, zum (automatischen) Einsatz.

326

Administrative Aufgaben des Informationsmanagements

Ausstattung mit IT Zur IT im engeren Sinne zählen alle Komponenten, die unmittelbar auf logischer Ebene dem RZ-Betrieb dienen. Dies sind Server- und Mainframe-Systeme sowie alle Speicher- und Backup-Systeme. Umfang und Qualität der IT-Ausstattung sind allein von den funktionalen Anforderungen abhängig. Das RZ-Management muss entscheiden, welche Dienstleistungen für welche Kunden auf welchen Systemen angeboten und erzeugt werden. Hierbei muss berücksichtigt werden, dass je nach Auslastung oft mehrere IT-Dienstleistungen, die weitgehend unabhängig voneinander sind, auf ein System konsolidiert werden können. Kapazitätsund Leistungsgesichtspunkte sind hierbei zu berücksichtigen (vgl. den Abschnitt Kapazitätsund Performancemanagement).

Sonstige Ausstattung Aus historischen Gründen werden einige Aufgaben dem RZ-Management zugeordnet, obwohl sie nicht unmittelbar IT-bezogen und für den IT-Betrieb auch nicht notwendig sind. Bei der Erstellung und Archivierung von Mikroforms bzw. Mikrofiches werden analoge Daten (z. B. gedruckte Texte, Abbildungen, Tabellen) in verkleinerter Form verfilmt und auf Film zur Verfügung gestellt. Für die Betrachtung werden Lesegeräte benötigt, die die verfilmten Daten physisch vergrößern und auf einem Bildschirm anzeigen können. Das RZManagement muss mit einer Kosten/Nutzen-Analyse (vgl. Lerneinheit WIRTA) darüber entscheiden, ob historische Daten, die verfilmt vorliegen, auf eine digitale Basis konvertiert werden sollen. Rechenzentren bieten meist auch Druck- und Kuvertierdienste an, für deren Erbringung Standarddrucker nicht geeignet sind. In großen Rechenzentren findet man häufig große Druckstraßen, die sowohl eine hohe Druckvolumenleistung haben als auch sehr flexibel hinsichtlich der verwendbaren Papiersorten sind. Häufig wird ein mit (Kunden-)Logos versehenes Papier auf großen Rollen verwendet, das innerhalb der Druckstraße automatisch geschnitten, bedruckt und in korrespondierende Stapel sortiert wird. Der Output kann direkt an eine Kuvertierstraße weitergeleitet werden, die die einzelnen Blätter (z. B. Rechnungen für Kunden der RZ-Kunden), gegebenenfalls mit individuellen (Werbe-)Beilagen, voll- oder teilautomatisch für den Postversand vorbereitet.

Management des RZ-Betriebs Server- und Mainframe-Management Aus historischen Gründen wird zwischen Server- und Mainframe-Systemen unterschieden, obwohl beide Rechnertypen Server sind. Mainframes (Großrechner, Host-Rechner, SuperServer) bieten die beiden Betriebsmodi Online-Betrieb (Dialogbetrieb) und Batch-Betrieb (Stapelverarbeitung), die auch parallel verwendet werden können. Wegen der vergleichsweise hohen Anschaffungskosten, des erforderlichen Know-hows sowie des ressourcenintensiven Betriebs muss die Auslastung eines Mainframes möglichst hoch sein, was durch die Zweiphasennutzung erreicht wird: Tagsüber werden im Dialogbetrieb hauptsächlich Termi-

Infrastrukturmanagement (INMAN)

327

nals (heute Arbeitsplatz-PCs und Peripheriegeräte aller Art) versorgt, in der Nacht findet die Stapelverarbeitung statt (die bei Bedarf aber auch tagsüber stattfinden kann). Im Online-Betrieb übernimmt der Mainframe die Funktion eines Terminalservers, der Benutzern Anwendungen hochverfügbar zur Verfügung stellt (Application Service Providing, vgl. Lerneinheit OUTSO). Die Kommunikation zwischen Terminal und Mainframe erfolgt auf Basis von Standardnetzen und -protokollen. Die größte Herausforderung an das OnlineBetriebsmanagement besteht darin, die Antwortzeiten der Online-Transaktionen (der Anwendungen) möglichst gering zu halten und dabei eine hundertprozentige Transaktionssicherheit und eine möglichst hohe Ausfallsicherheit zu gewährleisten. Fallen Komponenten aus, kann meist (mittels Redundanzlösungen, Ausweichszenarien und Notfalllösungen) ohne große Einschränkungen weitergearbeitet werden (vgl. Lerneinheit NOMAN). Der Modus Batch-Betrieb wird zu gewissen Zeitpunkten entweder automatisiert (z. B. zeitoder ereignisgesteuert) oder manuell vom Operator gestartet. Ein Beispiel für Stapelverarbeitungsaufgaben im Bankensektor ist die Verarbeitung der tagsüber über die verschiedenen Kanäle (Schalter und Selbstbedienungsgeräte in den Banken, Electronic Banking) erfassten und gesammelten Buchungsanweisungen für den Zahlungsverkehr (sofern diese nicht schon tagsüber durchgeführt wurden). Über einen bestimmten Zeitraum werden die Buchungen bis zu einem definierten Schnittzeitpunkt gespeichert und dann gesammelt auf der CPU des Mainframes ausgeführt. In vielen Rechenzentren werden die Durchführung und Überwachung der Stapelverarbeitung von der Struktureinheit Arbeitsvorbereitung mit Hilfe von hoch spezialisierten Softwarewerkzeugen ingenieurmäßig wahrgenommen (z. B. Festlegung des Start-Zeitpunkts, Ressourcenzuteilung, Reihung sowie Koordination der Aufträge). Die Anforderungen an einen Serverbetrieb sind meist weniger umfassend und vollständig von den zu betreibenden Applikationen und Betriebssystemen (z. B. Windows, Linux, Unix) abhängig. Wichtige allgemeine Überlegungen sind das kontrollierte Einspielen von Betriebssystem- und Programmaktualisierungen. Die Weiterentwicklung der Server-Betriebssysteme, insbesondere im Bereich der Virtualisierung (siehe unten), orientiert sich mitunter stark an den Architekturen von Mainframe-Betriebssystemen (z. B. IBM z/OS), die bezüglich Hochverfügbarkeit, Sicherheit und Flexibilität den Server-Betriebssystemen überlegen sind und ständig weiterentwickelt werden.

Netzmanagement Ziel des Netzmanagements ist es, eine hohe Netzverfügbarkeit und hohe Netzauslastung bei vertretbaren Antwortzeiten und gegebenen Netzkosten zu schaffen. Dazu sind Schwellenwerte festzulegen (d. h. Werte für Verfügbarkeit, Auslastung, usw.), bei deren Erreichen eine erkennbare Wirkung ausgelöst wird (z. B. die Behinderung der Abwicklung der Geschäftsprozesse) und bei deren Überschreiten die Netzadministration Maßnahmen ergreifen muss. Zweckmäßig ist es, mehrere Netzgüteklassen (z. B. gut, vermindert, schlecht) zu definieren und darauf abgestimmte Maßnahmen festzulegen. Langzeitanalysen der Netzdaten liefern zusammen mit Lastgrößen zum Verkehrsaufkommen Häufigkeitsverteilungen und Trends. Sie lassen Engpässe und Symptome für sich abzeichnende Mängel erkennen. Diese Daten gehen in das Kapazitätsmanagement ein (vgl. Lerneinheit SEMAN).

328

Administrative Aufgaben des Informationsmanagements

Speichermanagement Typischerweise sind in Rechenzentren mehrere Typen von Datenspeichern vorhanden. Von lokal in Rechnern eingebauten Datenträgern und direkt an Rechner angeschlossenen Speichergeräten (DAS) abgesehen, werden hauptsächlich so genannte NAS- und SAN-Speichersysteme verwendet, da diese eine hohe Flexibilität in der Verwendung und eine gute Abstraktion gegenüber dem eingesetzten Hardware-Festspeicher-Verbund bieten. NAS-Geräte zeichnen sich dadurch aus, dass sie selbst ein autonomes System darstellen und gegenüber den Clients (die den Speicher nutzenden Einheiten) standardisierte Schnittstellen bieten. Sie unterstützen Funktionalitäten zur Authentifizierung und Autorisierung, zentrale Sicherungskonzepte und Flexibilität in der Auf- und Zuteilung von Speicherplatz. Transparente Maßnahmen (z. B. Clustering) können ein bestimmtes Maß an Investitionsschutz bieten, da die Kapazität bei Bedarf erweitert werden kann. SAN-Systeme können Speicherplatz so bereitstellen, dass dieser bei den benutzenden Systemen lokal verbaut erscheint. Datensicherung und Datenarchivierung erfüllen die Aufgabe, von allen Daten (d. h. von Dateien, Datenbanken, Programmen und Protokollen) Kopien auf diversen Speichermedien abzulegen und zu administrieren. Diese Aufgabe ergibt sich einerseits daraus, dass Daten gegen Verlust (z. B. verursacht durch technische Defekte oder Katastrophen, vgl. Lerneinheiten SICHM und NOMAN) und kriminelle Handlungen (z. B. Datendiebstahl) geschützt werden müssen und andererseits aus der Erfüllung spezieller gesetzlicher Vorschriften (z. B. Aufbewahrungspflicht als Bestandteil der Buchführungs- und Aufzeichnungspflicht, nach der innerhalb bestimmter Fristen Buchführungsunterlagen für Prüf- und Beweiszwecke verfügbar sein müssen), generell auf Grund zahlreicher Compliance-Regeln (vgl. Lerneinheiten RECHT und REVIS). Daten der täglichen Produktion (z. B. Log-Files für Transaktionen, Bestände für Druckausgaben, Journal-Dateien) werden laufend gesichert. Eine Kopie wird in kurzen Abständen an zumindest einem anderen Ort, der gegen unbefugten Zutritt und Katastrophen gesichert ist, ausgelagert. Die Steuerung der Datensicherung einschließlich der zugehörigen Jobabläufe erfolgt mit Automatisierungswerkzeugen.

Verfügbarkeitsmanagement Insbesondere in Großunternehmen wird gefordert, dass das komplette Rechenzentrum redundant an verschiedenen Standorten verfügbar sein muss. Backup-Rechenzentren oder Ausweichrechenzentren sind meist eine „Kopie“ des Hauptrechenzentrums mit den gleichen Systemen, Komponenten, Konfigurationen und allen Daten (vgl. Lerneinheit NOMAN). In einem Katastrophenfall können innerhalb weniger Stunden die RZ-Dienstleistungen von dem alternativen Standort aus bezogen werden. Voraussetzung dafür ist, dass die beiden Rechenzentren auch während des Standardbetriebs ständig verbunden sind, um Daten und Konfigurationen abgleichen zu können. Ein weiteres Konzept des Verfügbarkeitsmanagements ist das der Datensicherung und Datenwiederherstellung. Dabei wird nicht „das ganze Rechenzentrum kopiert“, sondern „nur“ die Nutzdaten. Neben plattenspeicherinternen Datensicherungstechniken (wie RAID) sind auch Sicherungen von Daten auf Bändern mit Hilfe von Bandrobotern sowie das Auslagern der Daten zu einem externen Dienstleister gängige Praxis.

Infrastrukturmanagement (INMAN)

329

Kapazitäts- und Performance-Management In vielen Rechenzentren werden Leitstände verwendet, an denen zentral alle Dienste, Systeme und Sensoren konsolidiert überwacht werden können sowie eine zentrale Steuerung durch das Operating erfolgt. Über verschiedene Kontrollmonitore kann ein Operator die Zustände aller Systeme einsehen. Mithilfe von systemtechnisch hinterlegten Regeln und Heuristiken werden zwar Abweichungen von definierten Sollwerten durch die Systeme selbst erkannt und Alarmierungen ausgelöst, die Entscheidung über gegebenenfalls durchzuführende Aktionen (z. B. Abbrechen von Transaktionen, Reorganisation von Datenbanken, Durchführen spezieller Diagnose- und Prüfprogramme) obliegt jedoch meist dem Operator. Das Kapazitätsmanagement hat unter Berücksichtigung von Nebenbedingungen (wie Einhaltung von Kosten und Durchlaufzeiten) für die Abstimmung zwischen der Kapazität der Betriebsmittel und der Arbeitslast (Workload) zu sorgen. Dafür werden Sollwerte und Istwerte zu Kapazität, Arbeitslast, Kosten und Leistungen benötigt. Kapazitätsmanagement ist agierend und/oder reagierend. Der Kapazitätsplan ist das Ergebnis der Aktivitäten des Kapazitätsmanagements. Er wird zum Erkennen von Kapazitätsengpässen und zum Erarbeiten von Alternativen bei der Erweiterung der Betriebsmittel verwendet. Dazu ist eine genaue Kenntnis der Ist-Situation notwendig; insbesondere müssen die Reserven für die wichtigsten Betriebsmittel bekannt sein. In diesem Zusammenhang werden auch zu erwartende Veränderungen der Arbeitslast festgestellt, die sich aus der Übernahme neuer Anwendungen und Datenbestände in den Produktionsbetrieb sowie aus geplanten Veränderungen der Arbeitslast installierter Anwendungen ergeben. Unter Performance Management wird die Managementaufgabe der Überwachung und Analyse der Leistung von Systemen und deren zielgerichtete Beeinflussung verstanden. Eine nachhaltig zu hohe Auslastung kann – genauso wie eine ständig sehr niedrige Auslastung – Handlungsbedarf auslösen, um möglichst wirtschaftlich agieren zu können.

Virtualisierung In vielen Rechenzentren findet man eine Mischung aus verschiedenen Servern mit unterschiedlichen Betriebssystemen, Konfigurationen und angeschlossener Peripherie. Als Betriebssysteme kommen neben Microsoft Windows Servern, diversen Unix- und LinuxDerivaten auch spezielle (aufgabenspezifische) Betriebssysteme zum Einsatz. Dazu zählen insbesondere Systeme für den Betrieb von virtuellen Servern, die als so genannter Hypervisor bzw. Monitor, also als zentrale Koordinationsstelle, fungieren. Einzelne Systeme sind entweder autonom oder über eine Cluster-Technologie mit anderen gekoppelt, damit die Konzepte der Lastverteilung (Load Balancing) und Redundanz realisiert werden können. Das Konzept der Virtualisierung bedeutet, dass durch Abstraktionsschichten bei Hardund/oder Software hinsichtlich der Ressourcen eine größere Nutzungsflexibilität und/oder ein höherer Nutzungsgrad erreicht werden können. Virtualisierung kann auf verschiedenen logischen Ebenen betrieben werden. Auf einer einzigen Hardware können beispielsweise mehrere Betriebssysteme unabhängig voneinander installiert werden, die quasi parallel, jedoch gegeneinander abgeschottet laufen (Sicherheitsanforderung). Über den Hypervisor können den einzelnen virtuellen Systemen dynamisch Ressourcen zugeteilt oder entzogen

330

Administrative Aufgaben des Informationsmanagements

werden, sofern die physischen Ressourcen nicht erschöpft sind. Die Virtualisierung kann so weit gehen, dass eine einzelne Applikation zur Laufzeit inkl. offener Netzwerkverbindungen auf ein anderes System in einem anderen Rechenzentrum „verschoben“ wird, ohne dass der Benutzer davon etwas bemerkt. Bei Mainframe-Systemen werden seit Jahrzehnten Techniken angeboten, die eine Art Clustering mit dynamischer Lastverteilung und einem Ausfallsmanagement bieten. Hersteller von Großrechnersystemen haben meist eigene Konzepte entwickelt, um mehrere ihrer Systeme in einen Verbund zusammenzuschließen, die in Standardsituationen kollaborieren, jedoch bei Ausfällen die Aufgaben des jeweils anderen automatisiert und transparent übernehmen. Moderne Server-Virtualisierungssysteme haben viele Konzepte der Mainframe-Welt übernommen und an ihre eigenen Bedürfnisse angepasst.

Berichtswesen Der Zweck des RZ-Berichtswesens ist die regelmäßige Dokumentation der Einhaltung aller Serviceebenen-Vereinbarungen (vgl. Lerneinheit SEVER). Istwerte können laufend aus den Systemaufzeichnungen und punktuell aus Monitorauswertungen gewonnen werden. Berichte des RZ-Managements an die Leitung der IT-Abteilung – mit nachfolgender Berichtspflicht an andere Instanzen (z. B. den IT-Lenkungsausschuss, die für das IT-Controlling verantwortliche Instanz, ein Beirat) – enthalten Daten insbesondere zu folgenden Themenbereichen (mit vorgegebenen Sollwerten und erreichten Istwerten):          

Anschaltzeit und Verfügbarkeit von Anwendungen / Ressourcen (z. B. Datenbestände), Anzahl, Dauer und Gründe von Systemunterbrechungen, Systembelastung und Systemauslastung (Arbeitslast), Transaktionsaufkommen und Antwortzeiten von Transaktionen, Belastung durch die Benutzer, die die Betriebsmittel am stärksten beanspruchen, verspätete und ungeplante Verarbeitungen, Wiederholung von Aufträgen, Anteil der Inanspruchnahme der Betriebsmittel durch Stapel- und Dialogverarbeitung, Zeitbedarf für Aufgaben der Datensicherung und Datenarchivierung, Übernahmetermine für neue Anwendungen und Datenbestände und Termine und Dauer von Wartungsmaßnahmen.

Abgesehen von erklärenden Kommentaren sollten alle Berichte mit Hilfe von Berichtsgeneratoren möglichst weitgehend automatisiert und in standardisierter Form erstellt werden.

Cloud Computing Cloud Computing ist die Umsetzung eines Betriebsmodells auf Basis einer IT-Cloud. Eine (IT-) Cloud ist eine Menge funktional zusammengehöriger IT-Ressourcen bzw. IT-Dienste, die in Form standardisierter, skalierender („elastischer“) IT-Dienstleistungen (Services) über Internet (-Technologien) mit standardisiertem Zugang nach einem vereinbarten Verbrauchsund Verrechnungsmodell in Echtzeit zur Verfügung gestellt werden. Die Dienstgüte von Cloud-Services (insbesondere Performance und Verfügbarkeit) wird in Service Level Agreements geregelt. Eine Kurzdefinition lautet: Eine IT-Cloud stellt IT-Dienste zur Verfügung, die flexibel und verbrauchsorientiert über Internet genutzt werden können.

Infrastrukturmanagement (INMAN)

331

IT-Clouds können für jeden nutzbar oder mit einem geschlossenen Benutzerkreis ausgeführt sein und werden i. d. R. in größeren Rechenzentren betrieben. Eine Private Cloud wird von einer Organisation/einem Unternehmen in Eigenverantwortung zur Erfüllung eines bestimmtes Zwecks/Aufgabenbündels betrieben. Sie darf nur von einer genau bestimmten Benutzergruppe genutzt werden, was Identifikation bzw. Authentifikation zwingend voraussetzt. Public Clouds werden von Unternehmen betrieben, stehen allen zur Nutzung offen und setzen Identifikation nicht zwingend (z. B. Suchmaschinen, Wissensdatenbanken), aber oft voraus (z. B. Mailing-Dienste, Social Networks). Der Begriff Hybrid Cloud bezieht sich auf Anwendungsszenarien, die sowohl Private als auch Public Clouds umfassen. Für alle CloudArten existieren derzeit vier etablierte Ausprägungsformen, im Folgenden sortiert nach zunehmendem Funktionsumfang und Abstraktionsgrad: 







IaaS: Mit dieser Cloud-Ausprägung bezieht ein Cloud-Kunde Infrastrukturdienste aus dem Internet, ohne sich um deren Installation, Konfiguration etc. (also den physischen Betrieb) kümmern zu müssen. Der Kunde nutzt die Infrastruktur über definierte technische Schnittstellen. Beispiel: Elastischer, virtueller Server mit Cloud-Verrechnungsmodell. PaaS: Diese Cloud-Ausprägung bietet zusätzlich zur Infrastruktur Application Frameworks, mit denen Web-Anwendungen entwickelt werden können. Beispiel: Mit Force.com (des Cloud Computing-Pioniers Salesforce.com) wird eine Plattform zum Aufbau individueller CRM-Software angeboten. Die Grenze zwischen Paas und SaaS kann fließend sein. Weitere Beispiele sind Microsoft Azure und Google App Engine. SaaS: Diese Cloud-Ausprägung beschreibt „Ready-to-use-Software via Web”, also Anwendungen, die vom Nutzer unmittelbar verwendet werden können. Der Nutzer braucht nichts zu installieren oder zu programmieren, lediglich eine Registrierung/Profilanlage sowie eine Parametrierung können erforderlich sein. „Wo und wie“ eine SaaSAnwendung betrieben wird, ist weder bekannt noch relevant und interessiert im Regelfall auch nicht. SaaS-Beispiele für Verbraucher sind Suchmaschinen, Wissensdatenbanken, Web-Mail-, Office- und Collaboration Software, Web-Shops, Auktions- und Maklerplattformen, News- und Blog-Plattformen, Social Networks, Kommunikationsdienste, Online-Spiele etc. Beispiele für Geschäftskunden sind domänenspezifische EnterpriseAnwendungen (z. B. salesforce.com). Die Grenze zwischen SaaS und BPaaS kann fließend sein. BPaaS: Diese Cloud-Ausprägung ist im Vergleich zu den drei bisher erläuterten noch relativ wenig etabliert. Der Begriff beschreibt Ready-to-use-Software zur Unterstützung der Abwicklung kompletter Geschäftsprozesse. Für Verbraucher hat BPaaS noch wenig Relevanz, für Geschäftskunden deutlich mehr. Beispiel: Eine SaaS zur Abwicklung einer Kreditvertragserstellung in einer Bank nach einem exakt definierten Prozess, die über eine Private Cloud der Bank zur Verfügung gestellt wird. Kritiker argumentieren, dass eine BPaaS-Anwendung nur eine spezielle Form einer SaaS-Anwendung ist. Befürworter wenden ein, dass BPaaS jedenfalls noch eine zusätzliche Abstraktionsschicht bietet, nämlich jene der Geschäftsprozesse, die bei einer SaaS nicht vorhanden sein muss.

Vergleichbar mit traditionellen, öffentlich zugänglichen Diensten im Internet beschreiben aus der Sicht des Verbrauchers die Allgemeinen Geschäftsbedingungen bzw. fallweise vor-

332

Administrative Aufgaben des Informationsmanagements

handene Datenschutzerklärungen (Privacy Declarations) den Umgang eines Public CloudAnbieters mit den ihm anvertrauten (privaten) Daten.

Infrastrukturmanagement im Cloud Computing Die wesentliche Eigenschaft aller Cloud-Dienste besteht darin, dass sie in Echtzeit skalieren, d. h. dass sie unabhängig von der Anzahl der in der Cloud aktiven Nutzer die vereinbarte Verfügbarkeit und Leistungsfähigkeit tatsächlich liefern. Dies ist eine große Herausforderung für das Management der zugrunde liegenden Infrastruktur. Um die Skalierungseigenschaft in Echtzeit vor allem unter Hochlast bzw. unter stark schwankenden Lasten sicherstellen zu können, bedarf es umfangreicher Planungs-, Beschaffungs-, Implementierungs- sowie Betriebsüberwachungs- und Steuerungsverfahren, damit die notwendigen Ressourcen „just in time“ in der Cloud zur Verfügung stehen, ohne dass es zu Unterbrechungen der Dienste kommt oder der Nutzer wesentliche Schwankungen der Dienstgüte bemerkt. Die wichtigste Technologie für das Infrastrukturmanagement von Clouds ist die Virtualisierung ihrer Komponenten. Dies bedeutet aber nicht, dass eine IT-Abteilung, die sich der Technologie der Server-Virtualisierung bedient, deswegen bereits ein Cloud-Betreiber ist. Virtualisierung von Servern oder das Anbieten von IT-Diensten mittels Outsourcing ist noch kein Cloud Computing (vgl. Lerneinheit OUTSO). Diese Feststellung ist wichtig, da der Begriff Cloud Computing inflationär benutzt und fälschlicherweise mitunter mit dem des Outsourcing gleichgesetzt wird.

Aus der Praxis Im Positionspapier „The New Enterprise Data Center“ der IBM Corp. (2008) wird die Marktpositionierung eines Rechenzentrums respektive eines Infrastrukturbetreibers in drei Kategorien stufig definiert. Die Stufe „simplified“ beschreibt einen einfachen, effizienten RZ-Betrieb mit physischer (hardwarebezogener) Konsolidierung sowie Virtualisierung einzelner, individueller Systeme als Schwerpunkte. Die nächste Stufe „shared“ ist durch hochgradig virtualisierte IT-Ressourcen-Pools und integriertes IT-Service-Management gekennzeichnet, die es ermöglichen, neue IT-Infrastrukturen und IT-Services sehr rasch produktiv zu setzen. Die höchste Entwicklungsstufe „dynamic“ bezeichnet ein Rechenzentrum, das nicht nur IT-Systeme, sondern IT-Services vollständig virtualisiert anbietet. Diese ITServices orientieren sich nahtlos an den Geschäftsprozessen der Kunden (Business-Driven Service Management). Diese Kategorisierung passt gut zu den (ebenfalls stufigen) Ausprägungen des Cloud Computings (von IaaS zu BPaaS). Als größte Herausforderungen für Rechenzentren wurden im Rahmen einer weltweit durchgeführten Befragung von Chief Executive Officers und Chief Information Officers folgende Bereiche identifiziert:      

Entwicklung der Betriebskosten für Systeme und Netze (Gesamtkostenbetrachtung), steigende Energiekosten und erhöhter Energiebedarf (grüne Informationstechnologie), Management des explosionsartigen Anwachsens von Datenvolumina, starke Zunahme regulatorischer Anforderungen (Compliance), schwierige Prognosen der Workload-Charakteristika für die betriebenen Systeme und steigende Anforderungen an Verfügbarkeit und Skalierbarkeit betriebener Anwendungen sowie an die Flexibilität bei der Inbetriebnahme neuer Anwendungen und Services.

Infrastrukturmanagement (INMAN)

333

In der Marktforschungsstudie „Cloud Computing – Navigation in der Wolke“ von PricewaterhouseCoopers (2010) wurden strategisch (mit-)verantwortliche Führungskräfte in Anbieterunternehmen zu einer Reihe von Cloud Computing-Themen befragt. Zwei Beispiele: „Welche Art von Cloud-Computing-Services erbringt Ihr Unternehmen?“  SaaS: 83 % (der befragten Unternehmensvertreter)  IaaS: 53 %  Beratungsleistungen rund um Cloud Computing: 51 %  PaaS: 39 %  BPaaS: 27 %  andere Cloud-Services (z. B. Desktop-as-a-Service): 21 % „Was sind aus Sicht eines Anbieters momentan die größten Herausforderungen?“  Datenschutz- und Compliance-Anforderungen: 60 % („ist eher große Herausforderung“)  Standardisierung der internen Prozesse: 53 %  Passgenaue Gestaltung von Service Level Agreements: 49 %  Informationssicherheit: 49 %  Kundenzufriedenheit: 47 %  Klärung der Cloud-Definition: 47 %  Rekrutierung qualifizierter Mitarbeiter: 32 %  Identifikation geeigneter Unterauftragnehmer: 31 %  „Abschied vom Lizenzmodell“: 30 %  Sicherung der Servicequalität: 28 %  Reduzierung der Vorbehalte gegenüber Cloud Computing: 28 %  Maintenance und Skalierbarkeit: 26 % Der Microsoft-Mailing-Dienst Hotmail verzeichnete Mitte 2010 1,3 Milliarden Mailboxes mit 155 Petabyte Speicherplatz und einer monatlichen Steigerungsrate von 2 Petabyte. Cloud Computing spielt vor allem bei Klein- und Mittelunternehmen (KMU) bereits eine nicht unerhebliche Rolle. Viele KMU können durch Nutzung einer PaaS rasch und einfach auch komplexe Web-Anwendungen realisieren (z. B. Web Shops oder Workflow-Applikationen), ohne zuvor in Infrastrukturen oder IT-Know-how-Aufbau investieren zu müssen. Alle diese Entwicklungen haben bereits heute große volkswirtschaftliche Bedeutung. Methodenverweise Kosten- und Leistungsrechnung (Lerneinheit KOLER); Serviceebenen-Vereinbarungen (Lerneinheit SEVER). Kontrollfragen 1. Welche Aufgaben folgen aus dem Zweck des Infrastrukturmanagements bzw. des RZ-Managements? 2. Welche Faktoren sind bei Standortentscheidungen zu berücksichtigen? 3. Worin unterscheidet sich der Betrieb von Mainframe-Systemen von dem von Servern? 4. Was ist Virtualisierung und warum ist sie eine wichtige Technologie? 5. Was ist eine IT-Cloud und welche Cloud-Services können unterschieden werden? Quellen BITKOM e. V.: Cloud Computing – Evolution in der Technik, Revolution im Business. Berlin 2009 IBM Corp.: Cloud Computing: http://www-05.ibm.com/de/cloud/resources.html (Portal u.a. mit White Papers und Fallstudien; Abruf 19. April 2011 Louridas, P.: Up in the Air: Moving Your Applications to the Cloud. In: IEEE Software 4/2010, 6–11 PricewaterhouseCoopers: Cloud Computing – Navigation in der Wolke. Frankfurt/M. 2010

334

Administrative Aufgaben des Informationsmanagements

Tirmarche, A.: The New Enterprise Data Center. GUIDE SHARE EUROPE Management Summit. Brüssel 2008 T-Systems: White Paper Cloud Computing II, August 2010 Vertiefungsliteratur Baun, C. / Kunze, M. / Nimis, J. / Tai, S.: Cloud Computing. Web-basierte dynamische IT-Services. 2. A., Heidelberg et al. 2010 Doberitz, D.: IT-Kostenrechnung im Unternehmen – Verursachungsgerechte Leistungsverrechnung für innerbetriebliche IT-Dienstleistungen. Saarbrücken 2008 Furth, B. / Escalante, A. (Eds.): Handbook of Cloud Computing. New York et al. 2010 IEEE Security & Privacy, November/December 2010: Cloud Computing F.A.Z. Institut und Intel Corp.: Energieeffizienz im Rechenzentrum – Chancen, Potenziale, Lösungen. Frankfurt/M. 2007 Osterburg, S.: Das Rechenzentrum als Produktionsstätte für IT-Dienstleistungen – Verfügbarkeitsmangement in virtualisierten Rechenzentren. Göttingen 2010 Weinhardt, C. et al.: Cloud-Computing – Eine Abgrenzung, Geschäftsmodelle und Forschungsgebiete. In: WIRTSCHAFTSINFORMATIK 5/2009, 453–462 Zravy, W.: Serverkonsolidierung in Rechenzentren: Grundlagen, Konzepte und Motive von Virtualisierungstechnologien. Saarbrücken 2009

D. METHODEN DES STRATEGISCHEN INFORMATIONSMANAGEMENTS

strategische Ebene

administrative Ebene

operative Ebene

Grundlagen des Informationsmanagements

Methoden des Informationsmanagements

Aufgaben des Informationsmanagements

Fallstudien Informationsmanagement

336

Methoden des strategischen Informationsmanagements

Gegenstand dieses Kapitels sind die Methoden des strategischen Informationsmanagements, also das strategische Information Engineering. Da sich die Methoden auf Aufgaben des Informationsmanagements beziehen, ist es sinnvoll, zunächst diese – unter Aufgabenverweisen in den einzelnen Lerneinheiten angegebenen – Lerneinheiten zu studieren, bevor mit der Lektüre der Methoden begonnen wird. Die Methoden überschneiden sich teilweise in ihrer Anwendungsdomäne, so dass es wichtig ist, zu erkennen, worin ihre Gemeinsamkeiten bestehen und wodurch sie sich unterscheiden. Es ist daher angebracht, beim Durcharbeiten der Lerneinheiten den jeweils angegebenen Zweck zu durchdenken und Vergleiche zwischen den Methoden anzustellen.

Erfolgsfaktorenanalyse (ERFAN) ........................................................................................ 337 Kennzahlensysteme (KENNZ)............................................................................................. 349 Wirtschaftlichkeitsanalyse (WIRTA)................................................................................... 361 Nutzwertanalyse (NUTZW)................................................................................................. 373 Evaluierungsmethoden (EVALU)........................................................................................ 385 Vorgehensmodelle (VOMOD)............................................................................................. 397 Szenariotechnik (SZENA).................................................................................................... 409

Erfolgsfaktorenanalyse (ERFAN) Lernziele Sie kennen den Zweck der Erfolgsfaktorenanalyse und die Vorgehensweise bei ihrer Anwendung. Sie können ihre Bedeutung für die strategische IT-Planung erklären. Sie sind in der Lage, die für eine strategische Situationsanalyse relevanten Erfolgsfaktoren zu identifizieren und zu beschreiben. Sie wissen, wie der IT-Erfolg gemessen wird und wie er gezielt verbessert werden kann. Sie kennen die Weiterentwicklung der Erfolgsfaktorenanalyse zur Schlüsselfaktorenanalyse und können ihre Zweckmäßigkeit beurteilen.

Definitionen und Abkürzungen Besichtigungsanalyse (inspection analysis) = Form der Istzustandserfassung, deren Zweck durch bloßes Besichtigen erreicht werden kann; Ergebnisse werden meist zur Vorbereitung einer tiefer gehenden Analyse verwendet. Erfolgsfaktor (success factor) = Eigenschaft der IT, deren positive Ausprägung zur Schaffung und Sicherung von Unternehmenserfolg beiträgt. Fragebogenmethode (questionnaire technique) = schriftliche Form der Befragung mit einer geordneten Menge von offenen und/oder geschlossenen Fragen. Interdependenzanalyse (interdependence analysis) = Untersuchung der Beziehungen zwischen zwei Objektmengen, um deren gegenseitige Beeinflussung festzustellen. kritischer Erfolgsfaktor (critical success factor) = Erfolgsfaktor, von dessen Ausprägung der Unternehmenserfolg entscheidend abhängt. Leistung (performance) = von den Befragten geschätzter Beitrag eines Erfolgsfaktors zum Unternehmenserfolg. Leistungsdifferenz (performance gap) = Unterschied zwischen Priorität und Leistung je Erfolgsfaktor. Priorität (priority) = von den Befragten subjektiv eingeschätzte Wichtigkeit eines Erfolgsfaktors bezüglich seines Beitrags zum Unternehmenserfolg. Schlüsselbereich (key domain) = nach den Eigenschaften Service, Kommunikation, Personal und Positionierung geordnete Menge von Erfolgsfaktoren. Schlüsselfaktor (key factor) = Kombination Erfolgsfaktor/Wettbewerbsfaktor, die für den Beitrag der IT zum Unternehmenserfolg von besonderer Bedeutung ist. SERVQUAL = Service Quality; Ansatz zur multiattributiven Messung der Qualität von Dienstleistungen. Stichprobe (sample) = nach einem Auswahlverfahren (z. B. dem der Zufälligkeit) festgelegter Teil der Grundgesamtheit, von dem gefordert wird, dass er repräsentativ ist. Totalerhebung (total survey) = Form der Querschnittsanalyse, bei der Merkmale aller Untersuchungseinheiten einer statistischen Grundgesamtheit erfasst werden. Wettbewerbsfaktor (competitive factor) = den Wettbewerb kennzeichnende Eigenschaft des Marktes, in dem ein Unternehmen tätig ist (z. B. Lieferzeit, Qualität, Preis).

338

Methoden des strategischen Informationsmanagements

Zweck der Erfolgsfaktorenanalyse Die Erfolgsfaktorenanalyse ist Teil des von Alloway entwickelten Verfahrens zur strategischen IT-Planung. Sie basiert auf Arbeiten von Rockart, der durch empirische Untersuchungen festgestellt hat, dass für den IT-Erfolg vier Schlüsselbereiche ausschlaggebend sind und dass ein erfolgreiches IT-Management in jedem dieser Schlüsselbereiche die kritischen Erfolgsfaktoren mit besonderer Intensität bearbeiten muss. Die vier Schlüsselbereiche sind Service, Kommunikation, Personal und Positionierung.    

Service meint die durch die IT erbrachten Leistungen. Kommunikation meint das gegenseitige Verständnis und die gesicherte Zusammenarbeit zwischen Unternehmensleitung, IT-Mitarbeitern, Linienmanagement und Benutzern. Personal meint die Fach- und Sozialkompetenz der IT-Mitarbeiter. Positionierung drückt übergreifende Eigenschaften der IT aus (z. B. Art der Informationssysteme, Organisation des IT-Bereichs, Umfang des Outsourcings).

Alloway hat durch Befragung von über 1000 Führungskräften die vier Schlüsselbereiche durch 26 Erfolgsfaktoren präzisiert. Kein Informationsmanager kann Erfolg verbessernde Maßnahmen durchsetzen, die alle Erfolgsfaktoren gleichzeitig berücksichtigen; in der Regel sind auch nur einige davon kritisch. Zweck der Erfolgsfaktorenanalyse ist es, mit Hilfe von Erfolgsfaktoren eine Datenerhebung durchzuführen und mit einer systematischen Analyse   

den Erfolg der IT zu messen, Stärken und Schwächen der IT festzustellen und aus den Schwächen Maßnahmen zu ihrer Beseitigung, zumindest Minderung, und damit zur Erhöhung des IT-Erfolgs abzuleiten.

Zur Beantwortung der Frage, was Erfolg bedeutet, konkreter gefragt, wie er definiert ist, reichen verbale Erklärungen nicht aus. Es wird auf die in Abschnitt Erhebungstechnik und Messmethoden angegebenen Formeln verwiesen.

Erfolgsfaktoren Die Erfolgsfaktoren müssen für jede Analyse identifiziert werden, da jedes Unternehmen und damit jede IT spezifische Eigenschaften hat. Die im Folgenden genannten und beschriebenen Erfolgsfaktoren wurden von Heinrich/Pomberger in einem Bank- und Versicherungsunternehmen verwendet. (Es wurden einige Anpassungen der in der Quelle verwendeten Terminologie vorgenommen und der Text wurde gestrafft.) Sie erfüllten für die genannte Anwendung die Forderungen nach Vollständigkeit, nämlich alle für den IT-Erfolg relevanten Eigenschaften abbildend, und nach präzisen, für die Befragten verständlichen Erklärungen. Dies ist in Anbetracht der Vorgehensweise bei der Identifikation der Erfolgsfaktoren möglich bzw. wegen der Verwendung der Fragebogenmethode erforderlich. Die Erklärung unterstützend sind Beispiele, die Phänomene benennen, welche den Befragten aus der persönlichen Arbeitssituation bekannt sind. Eine allgemeine, von der einzelnen Anwendung unabhängige Erklärung ist nicht möglich. Die exemplarische Nennung und Erklärung kann die Anwendung der Erfolgsfaktorenanalyse unterstützen; sie kann insbesondere als Input für die Besichtigungsanalyse verwendet werden (vgl. weiter unten).

Erfolgsfaktorenanalyse (ERFAN)

339

Die Erfolgsfaktoren werden mit den 26 Buchstaben A bis Z bezeichnet; es können also maximal 26 Erfolgsfaktoren verwendet werden. Ihre Ordnung folgt nicht dem Alphabet, sondern ist beliebig (z. B. zeitlich nach ihrer Identifikation, Benennung und/oder Beschreibung). Die Bezeichnung mit Ziffern sollte vermieden werden. Die Verwendung von Buchstaben unterstützt bei der Identifikation der Erfolgsfaktoren das Ziel, ihre Anzahl und damit den Umfang des Fragebogens so zu begrenzen, dass die Erhebung mit akzeptablem Aufwand möglich, die Darstellung der Erhebungsergebnisse übersichtlich und deren Interpretation transparent ist.

Schlüsselbereich Service A B

E F G M Q T

U V W

Verfügbarkeit von Betriebsmitteln. Es werden die Ausfallzeiten (z. B. Hardwareausfall, Softwareabsturz, Netzunterbrechung) der Betriebsmittel im Verhältnis zur Nutzungszeit beurteilt. Individuelle Informationsverarbeitung. Es wird die Möglichkeit beurteilt, für arbeitsplatzspezifische Aufgaben selbstständig Problemlösungen durch die Benutzer zu erarbeiten und anzuwenden (z. B. Erfassung und Verwaltung lokaler Daten, Verwendung von Abfragesprachen, Nutzung von PC-Software). Ergebnisverfügbarkeit. Es werden die zeitlichen Aspekte bei der Lieferung von Reports oder beim Zugriff auf Ergebnisse beurteilt (z. B. Verfügbarkeit von aktuellen Daten für Abfragen, Antwortzeitverhalten, Bearbeitungsdauer). Benutzbarkeit. Es wird die Einfachheit, leichte Erlernbarkeit und sichere Handhabung der Informationssysteme beurteilt (z. B. Übersichtlichkeit der Benutzungsoberfläche, Online-Hilfe-Funktionen, Lesbarkeit der Dokumentation). Ergebnisqualität. Es werden die inhaltlichen Aspekte von Auswertungen oder von Ergebnissen beurteilt, die für die Aufgabenerfüllung benötigt werden (z. B. Aktualität, Verfügbarkeit und Vollständigkeit von Berichten). Funktionalität der Software. Es wird die Eigenschaft der Informationssysteme beurteilt, die zur Aufgabenerfüllung erforderlichen Funktionen bereitzustellen. Kundenorientierung. Es wird die Eigenschaft der Informationssysteme beurteilt, den Benutzern ausreichend Zeit für die Bearbeitung ihrer Aufgaben zu geben (z. B. durch wenig administrative Arbeiten, kurze Reaktionszeit auf Kundenanfragen). Sicherheitsmaßnahmen. Es wird die Eigenschaft der Informationssysteme beurteilt, Fehler bei der Benutzung zu verhindern bzw. aufzudecken und anzuzeigen (z. B. logische Prüfungen bei der Datenerfassung, Verbote oder Warnungen bei der Benutzung ungeeigneter Funktionen oder Kombination von Funktionen). Lesbarkeit. Es wird die Eigenschaft der Informationssysteme beurteilt, gut lesbare, leicht verständliche und optisch ansprechende Ausgaben auf Papier bereitzustellen, insbesondere für externe Empfänger (z. B. Ausgangsrechnungen). Datenverwaltung. Es werden die Zugänglichkeit und der Zustand des Datensystems beurteilt (z. B. Vollständigkeit und Richtigkeit der Daten, Verfügbarkeit einer Abfragesprache, individuelle Zugriffsmöglichkeit auf Daten). Änderungsverhalten. Es wird die Eigenschaft der IT-Abteilung beurteilt, auf Änderungsanforderungen angemessen reagieren zu können (z. B. Zeitbedarf für die Realisierung von Änderungsanforderungen).

340

X Y

Methoden des strategischen Informationsmanagements

Nachvollziehbarkeit. Es wird die Möglichkeit beurteilt, Daten zu interpretieren sowie Daten durch wiederholte Programmläufe zu erzeugen (z. B. mit welcher Methode Daten ermittelt wurden und ob sie plausibel sind). Transparenz. Es wird die Kenntnis der Benutzer über unternehmensweit verfügbare Datenbestände, Software und sonstige Betriebsmittel beurteilt, deren Nutzung für sie zweckmäßig ist.

Schlüsselbereich Kommunikation C

D

H I J

K

L

Innerbetriebliche Kommunikation. Es wird die Unterstützung der Benutzer bei der Kommunikation mit anderen, an der Aufgabenerfüllung beteiligten Mitarbeitern beurteilt (z. B. Datenerfassung beim ersten Bearbeitungsvorgang, Vermeidung von Medienbrüchen, Verwendung elektronischer Kommunikationsmittel). Zwischenbetriebliche Kommunikation. Es wird die Unterstützung der Benutzer bei der Kommunikation mit Geschäftspartnern beurteilt (z. B. durch gemeinsame Benutzung von Datenbasen, Vermeidung von Medienbrüchen, Verwendung elektronischen Datenaustausches). Zusammenarbeit Benutzer/IT-Mitarbeiter. Es wird die Kommunikation zwischen den Benutzern und den Mitarbeitern der IT-Abteilung sowie mit Outsourcing-Gebern beurteilt (z. B. Verfügbarkeit, Gesprächsklima, Verhalten). Benutzerschulung. Es werden der Umfang und die Qualität der Schulung und Weiterbildung der Benutzer sowie die dabei verwendeten Methoden beurteilt (z. B. Schulung durch IT-Mitarbeiter, externe Schulung, Simulation von Anwendungen). Benutzerbeteiligung. Es werden die Möglichkeit und der tatsächliche Umfang der Mitwirkung der Benutzer an der Entwicklung neuer und der Veränderung vorhandener Informationssysteme beurteilt (z. B. Einflussnahme auf Projektpläne, Mitarbeit in Projektgruppen, Mitwirken bei der Beschaffung von Betriebsmitteln). Benutzerorientierung. Es werden die Art und Weise und der Umfang beurteilt, in denen bei der Entwicklung neuer und der Veränderung vorhandener Informationssysteme auf Benutzerbedürfnisse Rücksicht genommen wird (z. B. Berücksichtigung arbeitsplatzspezifischer Anforderungen bei der Auswahl von Endgeräten, von Software und bei der Gestaltung von Benutzungsoberflächen). Benutzerunterstützung. Es wird die Fremdhilfe beurteilt, die den Benutzern bei der Benutzung vorhandener Informationssysteme und bei der Entwicklung neuer arbeitsplatzspezifischer Anwendungen zur Verfügung steht (z. B. Unterstützung beim Umgang mit PC-Werkzeugen).

Schlüsselbereich Personal N O

Qualifikation IT-Mitarbeiter. Es werden die Fähigkeiten und Fertigkeiten der Mitarbeiter der IT-Abteilung und der Outsourcing-Geber bei der Entwicklung, Anpassung, Wartung usw. der Informationssysteme einschließlich Technologie-Know-how beurteilt. Anwendungsorientierung IT-Mitarbeiter. Es werden das Wissen und die Kenntnisse der Mitarbeiter der IT-Abteilung und der Outsourcing-Geber über die Aufgaben der Fachabteilungen, für die Informationssysteme bestehen oder entwickelt werden, beurteilt.

Erfolgsfaktorenanalyse (ERFAN)

P

341

Benutzerqualifikation. Es werden die IT-spezifischen Fähigkeiten und Fertigkeiten der Benutzer beurteilt (z. B. im Umgang mit PC-Werkzeugen, bei der Mitwirkung an der Systementwicklung und bei der Nutzung vorhandener Informationssysteme).

Schlüsselbereich Positionierung R S

Individualsoftware. Es wird die Verfügbarkeit von Individualsoftware für die den Wettbewerb bestimmenden Geschäftsprozesse, mit denen eine Differenzierung von Mitbewerbern möglich ist, beurteilt. Verwendung von Standardsoftware. Es wird die Verwendung von Standardsoftware für Geschäftsprozesse, die nicht den Wettbewerb bestimmend sind, und die daraus folgende notwendige Anpassung der Geschäftsprozesse an die Standardsoftware beurteilt. A A B

B

C

D

E

AS

1

2

1

2

6

1

0

0

1

0

C

1

2

D

0

2

1

E

0

2

1

0

PS

1

7

5

3

2

2

7

2

5 3

6

4,4*

AS = Aktivsumme A bis E = Erfolgsfaktoren PS = Passivsumme * = Mittelwert Abb. ERFAN-1: Interdependenz-Matrix

Aktivsumme 10 I. 9 8

II.

7

C

6

A

5 4 3

D E

2 1 0

B

IV. 0

2

4

6

III.

8 10 Passivsumme

Abb. ERFAN-2: Interdependenz-Portfolio

Wenn mehr als 26 Erfolgsfaktoren identifiziert wurden, kann zur Reduzierung ihrer Anzahl mit der Interdependenzanalyse gearbeitet werden. Dazu werden die Erfolgsfaktoren in die Zeilen und Spalten einer Matrix geschrieben und die Interdependenzen skaliert (z. B. mit 0 = kein oder geringer, 1 = mittlerer und 2 = starker Einfluss; vgl. Abbildung ERFAN-1 beispielhaft für die Erfolgsfaktoren A bis E). Man bildet dann die Aktivsummen (Zeilensummen) sowie die Passivsummen (Spaltensummen) und berechnet deren Mittelwert. Anschließend wird ein Portfolio mit den Dimensionen Aktivsumme und Passivsumme aufgebaut; die vier Felder des Portfolios werden durch den berechneten Mittelwert gebildet (vgl. Abbildung ERFAN-2, im Beispiel 4,4). Jeder Erfolgsfaktor wird in eines der vier Felder eingetragen. Feld I ist der Bereich der aktiven Erfolgsfaktoren; sie sind durch hohe Aktivität (im Beispiel Aktivsumme größer rd. 4) und niedrige Passivität (im Beispiel Passivsumme kleiner rd. 4) gekennzeichnet. Feld II ist der Bereich der labilen Erfolgsfaktoren; sie sind durch hohe Aktivität (im Beispiel Aktivsumme größer rd. 4) und hohe Passivität (im Beispiel Passivsumme ebenfalls größer rd. 4) gekennzeichnet. Für die Datenerhebung werden nur die Erfolgsfaktoren dieser beiden Felder verwendet (im Beispiel A, D und C, B und E werden eliminiert).

342

Methoden des strategischen Informationsmanagements

Erhebungstechnik und Messmethoden Es wird die Fragebogenmethode verwendet. Der Fragebogen enthält drei Fragen: 1. 2. 3.

Welche Priorität haben Ihrer Meinung nach die Erfolgsfaktoren? (Im Fragebogen folgen die Prioritätsskala und die Erfolgsfaktoren A bis maximal Z.) Wie beurteilen Sie die Leistung der Erfolgsfaktoren? (Im Fragebogen folgen die Leistungsskala und die Erfolgsfaktoren in einer gegenüber 1. verwürfelten Reihenfolge, um die Beantwortung zu 2. ohne Orientierung an der Beantwortung zu 1. zu unterstützen.) Wie beurteilen Sie den Gesamterfolg der IT? (Im Fragebogen folgt die Leistungsskala.)

Stimmen der aus den Einzelurteilen zu Priorität und Leistung berechnete Erfolg (Antworten zu 1. und 2.) und der pauschal beurteilte Erfolg (Antwort zu 3.) nicht in etwa überein, muss den Ursachen nachgegangen werden; gegebenenfalls müssen die betreffenden Fragebögen für die Analyse unberücksichtigt bleiben. Jeder Erfolgsfaktor K = A...Z wird mit den Attributen Priorität P(K) und Leistung L(K) beschrieben. Für die Beurteilung der Erfolgsfaktoren und des Gesamterfolgs werden folgende Skalen verwendet (nur ganzzahlige Werte sind zugelassen): Prioritätsskala P(K) = 1: irrelevant P(K) = 3: eventuell nützlich P(K) = 5: wichtig P(K) = 7: sehr entscheidend

Leistungsskala L(K) = 1: sehr schlecht L(K) = 3: ausreichend L(K) = 5: gut L(K) = 7: ausgezeichnet

Der Erfolg E(K) für Erfolgsfaktor K wird über die Urteile der Befragten T = 1...t nach Formel (1) berechnet. t

1

E K  

 PK , T   LK , T 

T 1

t

 PK , T 

T 1

Formel (1) zeigt, dass E(K) umso größer ist, je höher Priorität und Leistung beurteilt werden und die Beurteilung von Priorität und Leistung ausgeglichen ist (bzw. Priorität nicht höher als Leistung beurteilt wird). Der Erfolg E(T) für Teilnehmer T und alle Erfolgsfaktoren wird nach Formel (2) berechnet. Der Erfolg ergibt sich auch unmittelbar aus den Antworten zu Frage 3. des Fragebogens, die mit der Leistungsskala beurteilt werden (Gesamterfolg). Erfolgsorientiert handelnde Informationsmanager versuchen, bei allen Erfolgsfaktoren eine Leistung zu erbringen, die ihrer Priorität entspricht. Die Notwendigkeit einer Leistungsverbesserung und die Reihung der die Leistung verbessernden Maßnahmen in einem Prioritätenkatalog werden durch die Leistungsdifferenz D(K) ausgedrückt. D(K) wird nach Formel (3) berechnet.

Erfolgsfaktorenanalyse (ERFAN)

343 Z

2 

E T  

 P K , T   LK , T 

K A

Z

 PK , T 

K A

3

DK  

1 t 1 t PK, T    LK, T   t T 1 t T 1

D(K) liegt theoretisch zwischen -6 und +6; in der Praxis liegen die Werte erfahrungsgemäß zwischen -3 und +3. Bei Minuswerten wird die Zurücknahme des Ressourceneinsatzes (Desinvestieren), bei Pluswerten werden die Leistung verbessernde Maßnahmen (Investieren) empfohlen. Die Skala D(K) für die Leistungsdifferenz ist:    

D(K) = - 3: Desinvestieren dringend erforderlich D(K) = - 1: Desinvestieren empfohlen D(K) = + 1: Investieren empfohlen D(K) = + 3: Investieren dringend erforderlich

Vorgehensweise bei der Erfolgsfaktorenanalyse Für die Durchführung einer Erfolgsfaktorenanalyse wird eine Arbeitsgruppe mit Mitarbeitern des IT-Bereichs und Mitgliedern des Linien- bzw. des Geschäftsprozessmanagements sowie mit Benutzern (so genannte key user) gebildet. Sie wird von einem in der Regel externen Projektbegleiter moderiert, der das Fachwissen der Methodenanwendung einbringt und die Gruppenarbeit steuert. Er ist auch für die Auswertung der Fragebögen und die Interpretation und Präsentation der Ergebnisse zuständig. Arbeitsschritte der Erfolgsfaktorenanalyse sind:       

Identifikation der Erfolgsfaktoren, Festlegen der Teilnehmer an der Befragung, Formulieren des Fragebogens, Durchführen der Datenerhebung, Auswerten der Erhebungsdaten und Darstellen der Erhebungsergebnisse, Interpretieren der Erhebungsergebnisse und Präsentieren der Befunde (Erhebungsergebnisse und deren Interpretation).

1. Identifikation der Erfolgsfaktoren. Der Projektbegleiter präsentiert in der Arbeitsgruppe Erfolgsfaktoren (Benennung und Erklärung), die sich in anderen Projekten bewährt haben und die – in der Regel auf Grund der Ergebnisse einer Besichtigungsanalyse – an die Untersuchungssituation angepasst wurden. Die Diskussion in der Arbeitsgruppe erfolgt mit dem Ziel der weiteren Anpassung durch Beantwortung folgender Fragen: 

Beschreiben die Erfolgsfaktoren alle Eigenschaften der IT, die für den Unternehmenserfolg von wesentlicher Bedeutung sind? Welche Eigenschaften sind von nur geringer Bedeutung und sollten nicht Erfolgsfaktor sein? Welche Eigenschaften von erheblicher Bedeutung fehlen und müssen als Erfolgsfaktor ergänzt werden?

344

 

Methoden des strategischen Informationsmanagements

Verwenden die Erklärungen der Erfolgsfaktoren fachsprachliche Ausdrücke, die im Unternehmen nicht verbreitet und bekannt sind? Kann von jedem Befragten ein vergleichbares Verständnis erwartet werden? Können alle wesentlichen Eigenschaften mit A bis maximal Z bezeichnet werden? Wenn nein, können mehrere Eigenschaften zusammengefasst werden? Sollten Eigenschaften durch Zerlegung präzisiert werden?

2. Festlegen der Teilnehmer an der Befragung. Zur Erzielung einer ausreichenden Ergebnisgenauigkeit sollte möglichst eine Totalerhebung durchgeführt werden, in die alle Benutzer und alle IT-Mitarbeiter einbezogen werden. Dies ist in kleinen bis mittelgroßen Unternehmen (etwa bis 200 Benutzer und IT-Mitarbeiter) mit vertretbarem Erhebungsaufwand möglich. In größeren Unternehmen wird eine Stichprobe mit einer Teilnehmeranzahl von etwa maximal 200 verwendet. Häufig ist eine weitere Differenzierung von Teilnehmergruppen (außer der Differenzierung in Benutzer und IT-Mitarbeiter) zweckmäßig oder sogar erforderlich. Letzteres ist der Fall, wenn Priorität und/oder Leistung in unterschiedlichen Funktionsbereichen oder Geschäftsfeldern oder an verschiedenen Standorten des Unternehmens signifikant verschieden beurteilt werden könnten (z. B. dann, wenn nicht die gleichen Informationssysteme verwendet werden). Dies kann durch die Ergebnisse der Besichtigungsanalyse eingeschätzt werden. 3. Formulieren des Fragebogens. Der Fragebogen besteht aus den drei Teilen Priorität, Leistung und Gesamterfolg; jeder Teil wird mit den im Abschnitt Erhebungstechnik und Messmethoden formulierten Fragen eingeleitet. Auf die Anordnung der Erfolgsfaktoren und Skalen wurde im gleichen Abschnitt hingewiesen. Die Verwendung von drei deutlich unterscheidbaren Farben beim Fragebogenmaterial ist zweckmäßig. Auf dem Deckblatt wird die Teilnehmergruppe angegeben. Die Zweckmäßigkeit eines Online-Fragebogens ist zu prüfen. 4. Durchführen der Datenerhebung. Eine Schulung der Teilnehmer ist nicht erforderlich, eine gezielte Information über den Erhebungszweck und eine Anleitung für die Beantwortung des Fragebogens aber notwendig. Dies erfolgt durch Mitglieder der Arbeitsgruppe, bei kleiner Arbeitsgruppe und großer Teilnehmerzahl gegebenenfalls nach dem Schneeballprinzip. Die Beantwortung des Fragebogens sollte durch alle Teilnehmer etwa zum gleichen Zeitpunkt (in der Regel am gleichen Arbeitstag) erfolgen, um Absprachen möglichst auszuschließen. 5. Auswerten der Fragebögen und Darstellen der Erhebungsergebnisse. Die Auswertung erfolgt nach Teilnehmergruppen. Die Berechnungen, die für die Ermittlung des Erfolgs je Erfolgsfaktor, des Gesamterfolgs und der Leistungsdifferenzen notwendig sind, ergeben sich aus den im Abschnitt Erhebungstechnik und Messmethoden genannten Formeln. Zur Absicherung der Ergebnisse ist es zweckmäßig, einige statistische Größen (z. B. Standardabweichung) zu berechnen. Die Auswertung kann mit einem Tabellenkalkulationsprogramm durchgeführt werden. Bei großen Datenmengen, wie sie bei einer großen Anzahl von Teilnehmern gegeben ist, sind Statistikprogramme geeigneter. Ergebnisse der Auswertung sind:   

Gesamterfolg und Erfolg je Erfolgsfaktor, differenziert nach Teilnehmergruppen, Klassifizierung der Erfolgsfaktoren auf Grund von Priorität und Leistung, differenziert nach Teilnehmergruppen (vgl. Abbildung ERFAN-3) und den vier Schlüsselbereichen. wichtige Erfolgsfaktoren mit guter Leistung (Erfolg),

Erfolgsfaktorenanalyse (ERFAN)

ausgezeichnet

5

sehr schlecht

7

unzureichend gut

wichtige Erfolgsfaktoren mit schlechter Leistung (Killer), unwichtige Erfolgsfaktoren mit guter Leistung (Verschwendung), unwichtige Erfolgsfaktoren mit schlechter Leistung (o.k.) und Ordnung der Erfolgsfaktoren nach Leistungsdifferenzen (vgl. die Isolinien in Abbildung ERFAN-4) und als Prioritätenkatalog.

Leistung

   

345

Erfolg

Verschwendung

6 G

4,43

J

R

4 3

OK

K

F C AW E B UY ST O QV X P Z N L D M Killer

2 1

4,88 1 3 4 6 7 2 5 irrelevant eventuell nützlich wichtig sehr entscheidend Priorität

Abb. ERFAN-3: Klassifizierung der Erfolgsfaktoren (Quelle: Bayer)

Zur Visualisierung der Ergebnisse werden neben Portfolios zur Darstellung von Priorität und Leistung und von Leistungsdifferenzen von zwei Teilnehmergruppen (z. B. Benutzer und ITMitarbeiter) Profildiagramme verwendet. Bei der Visualisierung der Ergebnisse sollten die Beurteilungen der Leistungsgeber (IT-Bereich) und Leistungsnehmer (Fachbereiche), vertreten durch die Teilnehmergruppen IT-Mitarbeiter und Benutzer, herausgearbeitet und gegenüber gestellt werden (wie Abbildung ERFAN-4 beispielhaft zeigt) und den Ursachen deutlich voneinander abweichender Ergebnisse nachgegangen werden. 6. Interpretieren der Erhebungsergebnisse. Die Interpretation der Erhebungsergebnisse wird durch Verwendung von Portfolios und Profildiagrammen unterstützt. 7. Präsentieren der Befunde (Erhebungsergebnisse und Interpretation). Auch die Präsentation wird durch Verwendung von Portfolios und Profildiagrammen unterstützt. Die Befunde werden durch die Empfehlung von Veränderungsmaßnahmen ergänzt, die in der Arbeitsgruppe diskutiert und dann dem Auftraggeber als Input für die strategische Maßnahmenplanung (vgl. Lerneinheit SPLAN) vorgeschlagen werden.

Methoden des strategischen Informationsmanagements

Leistungsdifferenz – Angaben der IT-Mitarbeiter

346

+3 M +2 +1

G

0 K

N P FT U A Q H

V

Z

EX

W

B

-1 R

J

-2 -3

C

O D I S Y

L

-3

-2

-1

0

+1

+2

+3

Leistungsdifferenz – Angaben der Benutzer Abb. ERFAN-4: Leistungsdifferenzen der Erfolgsfaktoren (Quelle: Bayer)

Beurteilung der Erfolgsfaktorenanalyse Die Erfolgsfaktorenanalyse macht die Mehrdimensionalität des IT-Erfolgs bewusst und leitet eine systematische Diskussion über den Erfolg verbessernde Maßnahmen ein. Sie zeigt, wo Maßnahmen am dringlichsten sind. Dies ist erfahrungsgemäß selten dort, wo es aus der Problemsicht der Tagesarbeit vermutet wird, sondern dort, wo ein langfristig wirksamer Bedarf aus Benutzersicht besteht. Die Erfolgsfaktorenanalyse misst daher auch Benutzerzufriedenheit und kann helfen, Vorurteile über die Leistung der IT-Abteilung zu entkräften. Bei regelmäßiger Wiederholung der Analyse lässt sich feststellen, ob und inwieweit den Erfolg verbessernde Wirkungen der Maßnahmen eingetreten sind. Empfohlen wird eine periodische Erfolgsfaktorenanalyse im Abstand von zwei bis drei Jahren. Die Erfolgsfaktorenanalyse lässt sich an unternehmensspezifische Situationen leicht anpassen (andere Erfolgsfaktoren), lässt sich erweitern oder reduzieren (mehr oder weniger Erfolgsfaktoren und/oder mehr oder weniger Teilnehmer bzw. Teilnehmergruppen). Das Bearbeiten des Fragebogens ist problemlos, wenn die Erfolgsfaktoren prägnant bezeichnet und gut erklärt sind und wenn Rückfragen gestellt werden können, die umgehend beantwortet werden. Je größer die Anzahl der Teilnehmer (bei gegebener Mitarbeiteranzahl), desto wichtiger wird die Erklärung der Erfolgsfaktoren, weil zunehmend Teilnehmer einbezogen werden, die nur arbeitsplatzspezifische Eigenschaften einzelner IT-Objekte beurteilen können. Durch Befragung der Führungskräfte und Erhebung ihrer Beurteilung von Priorität und Leistung wird eine bessere Ausrichtung der IT auf die strategischen Unternehmensziele erreicht. Die Vorgehensweise bei der Erfolgsfaktorenanalyse ist einfach und verständlich, und die Akzeptanz der Ergebnisse ist gut, wenn sie den Beteiligten wirkungsvoll präsentiert und mit

Erfolgsfaktorenanalyse (ERFAN)

347

ihnen gemeinsam aufgearbeitet werden. Dies fördert die Verständigung zwischen Unternehmensleitung, Fachabteilungen und IT-Bereich und begünstigt Veränderungsmaßnahmen, die gemeinsam getragen werden. So gesehen ist die Erfolgsfaktorenanalyse auch ein Instrument zur Aktivierung der Benutzerbeteiligung (vgl. Lerneinheit PERSM).

Weiterentwicklung der Erfolgsfaktorenanalyse Die Erfolgsfaktorenanalyse nimmt nicht explizit Bezug auf den Markt des Unternehmens (insbesondere auf seinen Absatzmarkt); nur mit einzelnen Erfolgsfaktoren kann ein solcher Bezug mittelbar hergestellt werden (vgl. dazu die Erfolgsfaktoren D, Q und S in der obigen Aufzählung). Mit der Schlüsselfaktorenanalyse wird die Erfolgsfaktorenanalyse so erweitert, dass eine explizite Beziehung zwischen Eigenschaften der IT (als Erfolgsfaktoren definiert) und Eigenschaften des Marktes (als Wettbewerbsfaktoren) hergestellt wird. Schlüsselfaktoren entstehen durch Kombination von Erfolgsfaktoren (gemäß Erfolgsfaktorenanalyse) mit Wettbewerbsfaktoren. Dazu wird eine Matrix verwendet, in deren Zeilen (oder Spalten) die Erfolgsfaktoren, in deren Spalten (oder Zeilen) die Wettbewerbsfaktoren stehen. Jede Kombination Erfolgsfaktor/Wettbewerbsfaktor wird geprüft, ob sie Schlüsselfaktor ist. (In einer konkreten Anwendung lagen 26 Erfolgsfaktoren und 8 Wettbewerbsfaktoren vor, das sind 208 Kombinationen. Davon wurden 45 als Schlüsselfaktoren identifiziert, vgl. Abbildung ERFAN-3 in der 5. Auflage dieses Lehr- und Handbuchs.) Das Vorgehen bei der Schlüsselfaktorenanalyse entspricht ansonsten dem bei der Erfolgsfaktorenanalyse.

Forschungsbefunde Heinrich/Pomberger berichten über Ergebnisse der wissenschaftlichen Begleitbeobachtung von acht im Verlauf von zehn Jahren durchgeführten Projekten der IT-Diagnose, in denen die Erfolgsfaktorenanalyse verwendet wurde, u. a. Folgendes: 







Anzahl der Erfolgsfaktoren: Zusammenfassungen zunächst identifizierter Erfolgsfaktoren sind problemloser als Weglassungen. Das Maximum von 26 Erfolgsfaktoren kann durch Zerlegung immer ausgeschöpft werden. Auf Zeitaufwand und Kosten einer Analyse hat die Anzahl der Erfolgsfaktoren keinen erkennbaren Einfluss. Beurteilbarkeit: Als Metrik wird die Anzahl missing items im Fragebogen verwendet. Mit 2 % missing items ist die Beurteilbarkeit sehr hoch. Die Befragten sind ausdrücklich angehalten, die Beurteilung eines Erfolgsfaktors nur dann vorzunehmen, wenn die Erklärung verständlich ist und wenn sie sich als Beurteiler nicht überfordert fühlen. Messgenauigkeit: Ein quantitatives Maß steht nicht zur Verfügung; der Befund orientiert sich daher an der Zufriedenheit. Hohe Zufriedenheit der Auftraggeber wird angenommen, weil die Empfehlungen zur strategischen Maßnahmenplanung akzeptiert und weitgehend umgesetzt wurden. Hohe Zufriedenheit der Befragten wird aus der erkennbaren Zustimmung der Mitglieder der Arbeitsgruppe zu den Befunden abgeleitet. Durchführungszeitraum: Dieser wird als Differenz zwischen dem Tag, an dem die Identifikation der Erfolgsfaktoren beginnt, und dem Tag, an dem die Ergebnisse präsentiert werden, gemessen. Das Minimum beträgt etwa vier Arbeitswochen; es wird wegen der erforderlichen Terminabstimmung zwischen den Beteiligten nur selten erreicht. Ein Zeitraum von acht Arbeitswochen ist realistisch.

348





Methoden des strategischen Informationsmanagements

Zeitaufwand: Er beträgt für die Projektbegleitung zehn bis zwölf Arbeitstage (ohne Zeitaufwand für Reisen), für die Arbeitsgruppe hängt er von deren Größe und Zusammensetzung ab; pro Gruppenmitglied beträgt er vier Arbeitstage. Der Zeitaufwand für die Befragung ergibt sich aus der Anzahl der Befragten und der Zeit für die Beantwortung des Fragebogens einschließlich Vorinformation, die 30 bis 60 Minuten beträgt. Durchführungskosten: Die Kosten für die Projektbegleitung ergeben sich aus dem Zeitaufwand bewertet mit dem vereinbarten Honorarsatz. Die internen Kosten ergeben sich aus dem mit Opportunitätskosten bewerteten Zeitaufwand.

Kang/Bradley berichten über die Messung des Erfolgs der von der IT-Abteilung angebotenen Dienstleistungen (performance measurement of IT department) in einer Fallstudie mit einem modifizierten SERVQUAL-Ansatz. Dieser verwendet zwei „IT service dimension factors“ (entsprechen den Schlüsselbereichen der Erfolgsfaktorenanalyse), und zwar personal attributes und service attributes (im Unterschied zu vier Faktoren bei SERVQUAL). Trotz mancher Einschränkung kommen die Autoren zu dem Schluss, dass dieser Ansatz gut geeignet ist, um die Qualität von internen IT-Dienstleistungen zu messen. Aufgabenverweise Controlling (Lerneinheit CONTR); Situationsanalyse (Lerneinheit SITAN); Zielplanung (Lerneinheit SZIEL); Maßnahmenplanung (Lerneinheit SPLAN). Fallstudienverweise Lerneinheit FSERF zeigt ein Beispiel der Anpassung der Erfolgsfaktorenanalyse an eine spezifische Entscheidungssituation (Messung der ASP-Qualität). Lerneinheit FERFA der 8. Auflage zeigt am praktischen Beispiel die Verwendung der Erfolgsfaktorenanalyse für eine IT-Diagnose. Kontrollfragen 1. Welcher Zweck wird mit der Anwendung der Erfolgsfaktorenanalyse verfolgt? 2. Mit welchen Arbeitsschritten wird bei der Erfolgsfaktorenanalyse vorgegangen? 3. Welche Fragen umfasst der Fragebogen für die Datenerhebung? 4. Warum wird der IT-Erfolg sowohl aus Einzelurteilen berechnet als auch durch Befragung direkt erfasst? 5. Wodurch unterscheiden sich Erfolgsfaktorenanalyse und Schlüsselfaktorenanalyse? Quellen Alloway, R. M.: Strategic Planning for Data Processing. Seminarunterlage des M.I.T. Industrial Liasion Program, Cambridge/Mass. 1985 Bayer, B.: Kann man Benutzerzufriedenheit messen? Erfahrungen bei der Anwendung der Erfolgsfaktorenanalyse. In: Information Management 3/1987, 6–11 Heinrich, L. J. / Pomberger, G.: Erfolgsfaktorenanalyse – Instrument für das strategische IT-Controlling. In: HMD – Praxis der Wirtschaftsinformatik 217/2001, 19–28 Kang, H. / Bradley, G.: Measuring the Performance of Internal Services: Is SERVQUAL the Answer? In: Neely, A. (Ed.): Performance Measurement 2000. Proc. of the 2. Int. Conf. on Performance Measurement, University of Cambridge, 19.-21. July 2000, 283–290 Rockart, J. F.: The Changing Role of the Information Systems Executive. A Critical Success Factors Perspective. In: Sloan Management Review 1/1982, 3–13 Vertiefungsliteratur Heinrich, L. J. / Häntschel, I.: Messen der Benutzerzufriedenheit – Instrument und Anwendungserfahrungen. In: Schweiggert, F. / Stickel, E. (Hrsg.): Informationstechnik und Organisation. Stuttgart 1995, 39–54 Heinrich, L. J. / Häntschel, I.: Messen des Erfolgs des Benutzer-Service. In: HMD – Theorie und Praxis der Wirtschaftsinformatik 189/1996, 75–97 Heinrich, L. J. / Häntschel, I. / Pomberger, G.: Information Systems Diagnosis. In: Zupancic, J. (Ed.): Evolution and Challenges in System Development. New York et al. 1999, 187–197

Kennzahlensysteme (KENNZ) Lernziele Sie kennen den Zweck eines Kennzahlensystems zur Planung, Überwachung und Steuerung der Informationsinfrastruktur und die Anforderungen, die an ein Kennzahlensystem gestellt werden. Sie können Kennzahlen in geeigneter Weise systematisieren. Sie kennen den Aufbau von Kennzahlensystemen und das Vorgehen beim Entwerfen eines Kennzahlensystems. Sie kennen die Konzeption eines Kennzahlensystems, das auf die spezifischen Bedingungen des strategischen Controllings ausgerichtet ist.

Definitionen und Abkürzungen Betriebsvergleich (interfactory comparison) = systematische Gegenüberstellung von Kennzahlen eines Unternehmens und denen anderer, vergleichbarer Unternehmen, um Informationen über die relative Stellung des Unternehmens in der Branche zu gewinnen. Beziehungszahl (relative figure) = Verhältniszahl, die zwei unterschiedliche, aber in einem Sinnzusammenhang stehende Zahlen in Beziehung setzt. BSC = Balanced Scorecard. CRM = Customer Relationship Management. EVA = Earned Value Analysis / Earned-Value-Analyse. Gliederungszahl (constructional figure) = Verhältniszahl, mit der ein Teil einer statistischen Masse zur Gesamtmasse in Beziehung gesetzt wird. Indexzahl (index figure) = Verhältniszahl, mit der gleichartige und selbstständige statistische Massen zueinander in Beziehung gesetzt werden; durch Indexzahlen bestimmte Größen können zu Reihen zusammengefasst und Veränderungen der Reihen durch Bezug auf eine gemeinsame Basis verglichen werden. Kennzahl (metric) = Zahl über Daten mit konzentrierter Aussagekraft zur Planung, Überwachung und Steuerung eines Systems. Kennzahlenanalyse (metric analysis) = systematisches Verfolgen des durch Kennzahlen erkannten Veränderungspotenzials zur Verifizierung und Ursachenerkennung. Kennzahlensystem (metric system) = ganzheitlicher Zusammenhang einer Menge von Kennzahlen, die zur Erreichung eines gemeinsamen Zwecks zusammenwirken. Messgröße (measuring figure) = Eigenschaft eines Objekts, deren Ausprägung mit einer Messmethode ermittelt werden kann. Synonym: Metrik. Metrik (metric) = Synonym für Messgröße und für Kennzahl. Soll/Ist-Vergleich (target vs. actual comparison) = systematische Gegenüberstellung von Kennzahlen mit Sollwerten und den gleichen Kennzahlen mit Istwerten. Spitzenkennzahl (top metric) = Kennzahl, die eine Gesamtaussage zum Untersuchungsbereich erlaubt. Validität (validity) = Ausmaß, mit dem eine Messgröße die Eigenschaft, die sie messen soll, auch tatsächlich misst. Zeitvergleich (period comparison) = systematische Gegenüberstellung von Kennzahlen mit Werten aus verschiedenen Perioden. Synonym: Periodenvergleich.

350

Methoden des strategischen Informationsmanagements

Zweck von Kennzahlensystemen Zweck eines Kennzahlensystems ist es, durch systematisches Vergleichen der in Kennzahlen erfassten Daten Aussagen über bestimmte Phänomene zu machen. Bei Verwendung von Planwerten (Sollwerten) wird ein Kennzahlensystem für Überwachungs- und Steuerungsaufgaben verwendet, wenn die Istwerte der entsprechenden Kennzahlen erfasst werden. Ein auf die Objekte und Eigenschaften des IT-Bereichs bezogenes Kennzahlensystem kann damit Hinweise auf notwendige Maßnahmen zur Veränderung der IT geben (insbesondere bei der strategischen Maßnahmenplanung, vgl. Lerneinheit SPLAN), ist aber selbst auch Gegenstand von Veränderungen (z. B. Anpassung an veränderte Unternehmensziele, Struktur- und/oder Ablauforganisation). Jede Aussage, die mit einem Kennzahlensystem gewonnen wird, hat den Charakter eines Auslösers für eine tiefer gehende Untersuchung; diese wird als Kennzahlenanalyse bezeichnet. Um die Ursachen von Veränderungspotenzial (Abweichungen und Trends) erkennen zu können, muss die Aufspaltung der Kennzahlen in detailliertere Kennzahlen möglich sein, bis man top-down auf der untersten Ebene des betrachteten Aussagebereichs angelangt ist (vgl. Abbildung KENNZ-2). Merkmale von Kennzahlen sind der Informationscharakter, die spezifische Form der Information und ihre Quantifizierbarkeit.   

Informationscharakter heißt, dass Kennzahlen Urteile über Phänomene der Wirklichkeit (wie Ereignisse, Prozesse, Strukturen und Zustände) ermöglichen. Spezifische Form der Information meint, dass komplizierte Phänomene auf einfache Weise dargestellt werden, um schnell einen umfassenden Überblick zu gewinnen. Quantifizierbarkeit besagt, dass Eigenschaften der Phänomene auf einer kardinalen Skala gemessen werden und somit relativ präzise Aussagen über sie möglich sind.

Kennzahlensystematik Eine Kennzahlensystematik kann nach verschiedenen Gesichtspunkten aufgebaut werden. Ein umfassender Ansatz ist durch folgendes Vier-Ebenen-Modell mit Objektebene, Definitionsebene, Datenebene und Kennzahlenebene gegeben. 



Auf der Objektebene wird der Untersuchungsbereich, der letztlich auf der Kennzahlenebene durch eine Kennzahl abgebildet werden soll, durch drei Größen festgelegt, nämlich Formalziel (z. B. Wirtschaftlichkeit, Wirksamkeit, Sicherheit), Phänomen (z. B. Planung, Realisierung, Nutzung) und Komponente (z. B. Software, Hardware, Personal). Kennzahlen sollen die Phänomene des Untersuchungsbereichs erfassen, die erfolgskritisch sind (so genannte Business Enabler oder Treiber, z. B. Kostentreiber). Auf der Definitionsebene wird für jeden Untersuchungsbereich, also für jede Kombination aus Formalziel, Phänomen und Komponente, eine Kennzahl definiert (z. B. „Wirtschaftlichkeit der Nutzung der Hardwarekomponente X“). Da eine Kennzahl nur im Vergleich Aussagekraft hat, wird auf der Definitionsebene auch festgelegt, welche Kennzahl bei welcher Art von Vergleich verwendet wird. Schließlich wird auf der Definitionsebene festgelegt, mit welchen Messgrößen der Untersuchungsbereich in eine

Kennzahlensysteme (KENNZ)





351

Kennzahl so abgebildet wird, dass sie das misst, was sie zu messen behauptet (Validität), und ob Daten zu den Messgrößen mit vertretbarem Aufwand erhoben werden können. Auf der Datenebene werden die Daten erhoben, die in die Kennzahl eingehen (z. B. für die Kennzahl „Wirtschaftlichkeit der Nutzung der Hardwarekomponente X“ die budgetierten Kosten und die tatsächlich entstandenen Kosten). Dies setzt zumeist den Anschluss des Kennzahlensystems an vorhandene Berichtssysteme (wie das der Kostenund Leistungsrechnung, vgl. Lerneinheit KOLER) voraus, da für die Zwecke des Kennzahlensystems allein der Erhebungsaufwand unvertretbar hoch ist. Sind Berichtssysteme vorhanden, geht es um die Festlegung der Datenquellen für jede Kennzahl. Sind keine Berichtssysteme vorhanden, geht es um die Festlegung von Messmethoden für die Datenerhebung für jede Kennzahl. Auf der Kennzahlenebene wird die Kennzahl berechnet (z. B. als Indexzahl). Daran schließt sich die Verwendung der Kennzahl für die Planung, Überwachung und Steuerung des Untersuchungsbereichs an, der auf der Objektebene festgelegt wurde.

Andere Systematiken, die aber nur Teilaspekte dieser grundsätzlichen Gliederung ansprechen und in dieser implizit enthalten sind, sind beispielsweise: 



 

Gliederung der Kennzahlen nach methodischen Gesichtspunkten in Verhältniszahlen und absolute Zahlen. Verhältniszahlen sind Gliederungszahlen (z. B. Personalkosten der IT-Abteilung im Verhältnis zu Gesamtkosten der IT-Abteilung), Beziehungszahlen (z. B. Anzahl Personal Computer zu Anzahl Arbeitsplätze) oder Indexzahlen (z. B. Steigerung der Produktivität von x auf y). Absolute Zahlen sind Einzelzahlen (z. B. Anzahl Mitarbeiter der IT-Abteilung) und Summen, Differenzen oder Mittelwerte, die aus Einzelzahlen gebildet werden. Gliederung der Kennzahlen nach Strukturmerkmalen. Quantitative Strukturmerkmale sind Gesamt- oder Teilgrößen (z. B. Kosten des IT-Projekts als Gesamtgröße und Testkosten als Teilgröße). Zeitliche Strukturmerkmale sind Zeitpunkt- oder Zeitraumgrößen (z. B. Projektmeilensteine oder Personalkosten einer Projektphase). Inhaltliche Strukturmerkmale sind Mengen- oder Wertgrößen (z. B. Anzahl Personal Computer oder ihr wertmäßiger Bestand). Gliederung der Kennzahlen nach den Funktionsbereichen des Unternehmens (z. B. Fachabteilungen und IT-Abteilung) oder nach Geschäftsprozessen. Nach der Art des Vergleichens der Kennzahlen wird zwischen Betriebsvergleich, Soll/Ist-Vergleich und Zeitvergleich unterschieden.

Anforderungen an Kennzahlensysteme Ein Kennzahlensystem ist ein ganzheitlicher Zusammenhang einer Menge von Kennzahlen. Die Kennzahlen sind entweder rechnerisch miteinander verknüpft (Formelsystem), oder sie stehen zumindest in einem Systematisierungszusammenhang (Ordnungssystem). Ein Kennzahlensystem für die Planung, Überwachung und Steuerung des IT-Bereichs muss folgende Anforderungen erfüllen:  

Es muss alle für die Planung, Überwachung und Steuerung bedeutsamen Phänomene des IT-Bereichs abbilden. Kennzahlenbezeichnung und -erklärung müssen klar und nachvollziehbar sein.

352

      

Methoden des strategischen Informationsmanagements

Es muss den Zusammenhang zwischen diesen Phänomenen zum Ausdruck bringen (z. B. wie Phänomen A auf Phänomen B wirkt und wie folglich die Kennzahl für Phänomen A im Zusammenhang mit Phänomen B zu interpretieren ist). Es muss Zugang zu validen Daten über die Phänomene haben (z. B. Daten der Kostenund Leistungsrechnung, vgl. Lerneinheit KOLER). Die Methoden der Datenermittlung müssen standardisiert sein, um Zeitvergleiche durchführen zu können. Die Daten müssen aktuell und zuverlässig sein (Datenqualität). Das Kennzahlensystem muss flexibel und damit an Änderungen der Informationsinfrastruktur wie auch der Anforderungen der Kennzahlenverwender anpassbar sein. Systembedingte Fehlinterpretationen müssen weitgehend ausgeschlossen sein. Entwicklung, Implementierung und Nutzung einschließlich Anpassung müssen wirtschaftlich möglich sein.

Ein Kennzahlensystem, das alle Anforderungen erfüllt, steht nicht zur Verfügung. Die folgenden Erläuterungen zeigen Ansätze eines solchen Kennzahlensystems bzw. geben Hinweise darauf, wie beim Entwurf eines Kennzahlensystems vorgegangen werden kann. Dabei muss beachtet werden, dass die Anwendung von Kennzahlen nicht nur Probleme lösen, sondern auch zu Problemen führen kann, beispielsweise: 



  

Betriebsvergleiche (z. B. innerhalb einer Branche bei in etwa gleicher Unternehmensgröße und vergleichbarer Art und Größe des IT-Bereichs) können durch Unterschiede in der Kosten- und Leistungsrechnung und damit der Datenermittlung zu falschen Schlüssen führen (z. B. beim Benchmarking, vgl. Lerneinheit MEGPM). Durch Dezentralisierung der Informationsinfrastruktur entstehen IT-Kosten nicht nur im IT-Bereich, sondern auch in den Fachabteilungen; dies wird von der Kosten- und Leistungsrechnung und damit bei der Ermittlung von Kennzahlen nicht immer ausreichend berücksichtigt. Die IT-Abteilung nimmt Leistungen anderer Fachabteilungen in Anspruch (z. B. der Abteilungen Controlling und Revision), die in der Regel nicht verrechnet werden Aussagefähige Vergleiche erfordern ein Zahlenmaterial über mehrere Perioden, das häufig nicht zur Verfügung steht (Zeit- oder Periodenvergleiche). Verschiedene Bezugsgrößen (z. B. Umsatz) sind für Kennzahlen ungeeignet; sie können sogar irreführend sein (z. B. IT-Kosten/Jahr in Prozent vom Umsatz/Jahr, eine in der Praxis häufig verwendete Kennzahl).

Struktur von Kennzahlensystemen Ein Kennzahlensystem baut auf einer Spitzenkennzahl auf. Aus ihr werden – nach bestimmten Auflösungsregeln – weitere Kennzahlen abgeleitet. Jede Kennzahl, außer den Kennzahlen auf der untersten Ebene des Kennzahlensystems, setzt sich aus zwei oder mehreren untergeordneten Kennzahlen zusammen. Zwischen der Spitzenkennzahl und den abgeleiteten Kennzahlen bestehen Beziehungen; außerdem können zwischen Kennzahlen der gleichen Ebene Beziehungen bestehen. Abbildung KENNZ-1 visualisiert diese Erläuterungen.

Kennzahlensysteme (KENNZ)

353

A B A C

•

B C

• •

A- D C A- E C

Spitzenkennzahl

• • •

D C

untergeordnete Kennzahlenebenen, abgeleitet nach Auflösungsregeln

• • •

E C

Abb. KENNZ-1: Aufbau von Kennzahlensystemen (Quelle: Diebold)

Für die Aussagekraft eines Kennzahlensystems sind ist nur die Anzahl der Kennzahlen und die in diese eingehenden Daten wesentlich, sondern viel mehr die systematische (z. B. logische oder arithmetische) Ordnung der Kennzahlen und ihre Zusammenfassung zu Aussagebereichen. Dies ermöglicht spezifische Informationen über einzelne Aussagebereiche. Jeder Aussagebereich hat Steuerungsgrößen (so genannte Hauptkennzahlen) und aus diesen abgeleitete Kennzahlen. Die Aussagebereiche stehen nebeneinander oder sind miteinander hierarchisch verknüpft (vgl. Abbildung KENNZ-2). Aussagebereich x + •

Aussagebereich x 1 +

Aussagebereich x 2 :

+

:

+ +

+ •

Aussagebereich x 11

Abb. KENNZ-2: Verknüpfung der Aussagebereiche eines Kennzahlensystems (Quelle: Diebold)

Der Umfang eines Kennzahlensystems, gemessen mit der Anzahl der Aussagebereiche und der Anzahl Kennzahlen je Aussagebereich, hängt primär von der Bedeutung des IT-Bereichs für den Unternehmenserfolg ab. Diese ist umso größer, je mächtiger das Leistungspotenzial der Informationsfunktion ist, das durch systematisch aufgebautes und genutztes Erfolgspotential der Informationsinfrastruktur ausgeschöpft werden kann (vgl. Lerneinheit SITAN).

354

Methoden des strategischen Informationsmanagements

Referenzmodelle Im Folgenden werden Balanced Scorecard (BSC), Earned-Value-Analyse (EVA) und der Goal/Question/Metric-Ansatz (GQM-Ansatz) erläutert, die als Referenzmodelle für die Entwicklung unternehmensspezifischer Kennzahlensysteme verwendet werden können.

Balanced Scorecard BSC ist ein zu Beginn der 1990er Jahre von Kaplan/Norton entwickeltes Konzept, auf dessen Grundlage Kennzahlensysteme konstruiert werden können, die auch zur Umsetzung von Strategien geeignet sind. Das Konzept verwendet mehrere Leistungsbereiche oder Perspektiven, in der ursprünglichen Form vier (vgl. weiter unten). Da es generisch ist, können die Anzahl der Perspektiven und der je Perspektive verwendeten Ziele und Maßnahmen beliebig gewählt werden. Beispielsweise können Umweltfaktoren oder eine Ökobilanz ebenso berücksichtigt werden wie Stakeholder oder branchenspezifische Faktoren. Unlogisch ist es, Zielinhalte (z. B. Sicherheit, Innovationsfähigkeit) als Perspektive zu verwenden. Die Sollwerte der Kennzahlen werden aus der Strategie abgeleitet (z. B. aus der Geschäftsstrategie für ein unternehmensweites Kennzahlensystem, aus der IT-Strategie für ein Kennzahlensystem des IT-Bereichs). Die wesentliche Leistung von BSC wird in der Identifikation von Ursache-Wirkungs-Beziehungen zwischen strategischen Zielen bzw. Strategien, Messwerten von Kennzahlen (Sollwerte bzw. Istwerte) und Maßnahmen gesehen. Die vier Perspektiven nach Kaplan/Norton sind (in Klammern Beispiele für Kennzahlen):    

Finanzperspektive (financial focus): Kennzahlen zum Erreichen der finanziellen Ziele (z. B. Kosten/Einheit, Umsatz/Vertriebsmitarbeiter, Deckungsbeitrag/Produktgruppe). Kundenperspektive (customer focus): Kennzahlen zum Erreichen der Kundenziele (z. B. Kundenzufriedenheit, Anzahl Reklamationen, Reaktionszeit auf Kundenanfragen). Prozessperspektive (process focus): Kennzahlen zum Erreichen der Prozess- und Produktionsziele (z. B. Zuverlässigkeit, Durchlaufzeit, Qualität, Prozessbeherrschung). Lern- und Entwicklungsperspektive (learning focus): Kennzahlen zum Erreichen der strategischen Unternehmensziele (z. B. Mitarbeiterfluktuation, Arbeitszufriedenheit, Innovationsfähigkeit, Umsatzanteil neuer vs. alter Produkte).

Der Konstruktions- und Implementierungsprozess für ein Kennzahlensystem des IT-Bereichs kann top-down oder bottom-up verlaufen. Top-down heißt, dass ein unternehmensweites Kennzahlensystem besteht, das für einzelne oder alle Unternehmensbereiche (z. B. Funktionalbereiche oder Geschäftsfelder) präzisiert wird. Wird das Kennzahlensystem zunächst für verschiedene Unternehmensbereiche entwickelt, kann es bottom-up zum unternehmensweiten Kennzahlensystem aggregiert werden. Das heißt u. a., dass für den IT-Bereich ein BSC-Kennzahlensystem implementiert werden kann, unabhängig davon, ob es ein unternehmensweites BSC-Kennzahlensystem gibt, et vice versa. Für die Perspektivensystematik bieten sich für den IT-Bereich – neben den von Kaplan/Norton genannten Perspektiven – die für das Controlling verwendeten Controlling-Objekte an (vgl. Lerneinheit CONTR). Mit einer übergeordneten Perspektive können die Steuerungsanforderungen der IT-Governance im Kennzahlensystem berücksichtigt werden (vgl. Lerneinheit GOVER).

Kennzahlensysteme (KENNZ)

355

Earned-Value-Analyse EVA ist nach Stelzer/Bratfisch (61) „... ein einfach anzuwendendes Hilfsmittel des Projektcontrollings, das die Projektverantwortlichen mit aussagekräftigen und leicht zu ermittelnden Kennzahlen unterstützt.“ Die auch als Ertragswertanalyse oder Arbeitswertanalyse bezeichnete Methode umfasst ein Kennzahlensystem zur Bewertung der Projektleistung bzw. des Projektertrags während der Projektlaufzeit. In DIN 69903 wird der methodische Kern der EVA als Fertigstellungswert bezeichnet, ohne erläutert zu sein. Mit EVA wird der Fortschritt bzw. Ertrag eines Projekts durch Vergleich des mit Plankosten bewerteten Projektfortschritts (der Projektleistung bzw. dem Ertragswert) mit den geplanten Terminen und den geplanten Kosten gemessen. EVA ist also eine Erweiterung einfacher Termin- und Budgetabweichungsanalysen, weil der zum Kontrolltermin erzielte Ertrag bzw. die Leistung eines Projekts in Geldeinheiten ausgedrückt werden kann. Mit EVA können auch Trends transparent gemacht werden, um Prognosen zum weiteren Projektverlauf abgeben zu können. Für die EVA charakteristische Kennzahlen sind:       

BAC = Budget at Completion bezeichnet das geplante Gesamtbudget des Projekts. BCWS = Budgeted Cost of Work Scheduled sind die budgetierten Kosten der bis zum Kontrolltermin geplanten Teilaufgaben, kurz die Plankosten. ACWP = Actual Cost of Work Performed sind die anteiligen Istkosten der bis zum Kontrolltermin erbrachten Teilaufgaben, kurz die Istkosten. BCWP = Budgeted Cost of Work Performed sind die Plankosten der bis zum Kontrolltermin abgearbeiteten Teilaufgaben. CPI = Cost Performance Index ist das Verhältnis zwischen BCWP und ACWP, kurz die relative Kostenabweichung. EAC = Estimate at Completion sind die geschätzten Gesamtkosten und informiert darüber, welche Kosten vom Kontrolltermin aus gesehen bis zum Projektende entstehen werden. ETC = Estimated Time to Completion oder geschätzte Projektlaufzeit informiert darüber, wie lange das Projekt voraussichtlich insgesamt dauern wird.

EVA eignet sich auch zum Controlling mehrerer offener Projekte, zwischen denen so hohe inhaltliche, zeitliche, personelle und finanzielle Abhängigkeiten bestehen, dass eine übergeordnete Koordination erforderlich ist (Multiprojektmanagement).

Goal/Question/Metric-Ansatz Auch der primär zum Messen und Bewerten entwickelte GQM-Ansatz (engl. GQM Approach oder GQM Paradigm) kann als Referenzmodell für die Entwicklung von Kennzahlensystemen verwendet werden. Basili/Caldiera/Rombach (528) beschreiben das Ergebnis der Anwendung des GQM-Ansatzes als „… specification of a measurement system targeting a particular set of issues and a set of rules for the interpretation of the measurement data.” Objekte des Messsystems können sein: 

Produkte wie alle im Produktlebenszyklus (z. B. von Softwareprodukten) entstehenden Artefakte: Entwürfe, Konzepte, Spezifikationen, Programme oder Testpläne.

356

 

Methoden des strategischen Informationsmanagements

Prozesse wie alle unter zeitlichem Aspekt betrachteten Phasen der Produktentwicklung: Analysieren, Spezifizieren, Entwerfen, Implementieren oder Testen. Ressourcen wie Personal, Hardware, Software, Werkzeuge, Zeit oder Budgets.

Die Aufzählung kann beliebig fortgesetzt werden; auch Dienstleistungen können Messobjekte sein. So wie bei BSC bieten sich die beim Projektcontrolling verwendeten ControllingObjekte als Messobjekte an (vgl. Lerneinheit CONTR). Das Messmodell besteht aus konzeptioneller Ebene (Goal), operationeller Ebene (Question) und quantitativer Ebene (Metric). Bestandteile eines GQM-Plans zur Entwicklung des Messsystems sind daher: 1.

2. 3.

Ein Ziel (z. B. ein Qualitätsziel) mit folgenden Informationen: Messobjekt (Produkte, Prozesse, Ressourcen), Messzweck, Zielfokus (d. h. die relevanten Eigenschaften des Messobjekts), Messsubjekt (d. h. aus wessen Sicht die Messungen durchgeführt werden, z. B. CIO, IT-Leitung, Projektleitung) und Kontext der Messung (z. B. Projektcontrolling). Grundsätzlich wird – je nach Messzweck – zwischen Zielen des Verständnisses, der Charakterisierung, der Bewertung oder der Verbesserung unterschieden. Eine Menge von Fragen zur Beschreibung des Messziels und zur Charakterisierung des Messobjekts bzgl. des Zielfokus (z. B. die Qualitätsmerkmale). Eine Menge von Metriken, mit denen die Fragen in weitgehend quantitativer Form beantwortet werden können. Die zugehörigen Messdaten können auf objektivem Messen (z. B. Geldeinheiten, Häufigkeiten, Zeitdauern) oder subjektivem Messen (z. B. Schätzen) basieren und sich auf unterschiedliche Skalen (vgl. Lerneinheit NUTZW) beziehen.

Die Beziehungen zwischen den Zielen, die gegebenenfalls durch Subziele verfeinert werden, den Fragen und Metriken können durch einen gerichteten Graph (GQM-Graph) dargestellt werden; das Messsystem ist also hierarchisch strukturiert. Die Knoten repräsentieren die Ziele, die Fragen und die Metriken. Kanten werden dann eingeführt, wenn eine Verbindung zwischen den durch die Knoten repräsentierten Inhalten (Ziel, Frage oder Metrik) besteht. GQM-Pläne werden top-down entwickelt, so dass nur die Metriken verwendet werden, die zur Beantwortung von mindestens einer Frage erforderlich sind; eine bestimmte Metrik kann zur Beantwortung mehrerer Fragen beitragen. Die nachfolgende Analyse und Interpretation der Messergebnisse erfolgt bottom-up. Ein Erfolgsfaktor für den GQM-Ansatz ist die Einbeziehung der Personen (Partizipation, vgl. Lerneinheit PERSM), die für das Messobjekt verantwortlich sind (z. B. Projektleitung und Kern-Mitarbeiter beim Messobjekt ITProjekte). Das Aufstellen und Auswerten von GQM-Plänen wird durch ein von Gresse/Rombach/Ruhe entwickeltes so genanntes Abstraction Sheet unterstützt, mit dem es gelingt, in der Vielfalt der Fragen und Metriken die wesentlichen Zusammenhänge zu erkennen. Es zwingt auch zur Formulierung von Hypothesen, anhand derer Messergebnisse analysiert werden.

Werkzeuge Der Aufwand für die Konstruktion, Implementierung, Wartung und Verwendung eines Kennzahlensystems hängt v. a. von dessen Umfang ab, der weiter oben definiert wurde. Häufig ist die Erfassung der Kennzahlendaten nur durch Abfragen verschiedener IT-Systeme mit vertretbarem Aufwand möglich. Dafür kommen insbesondere Systeme zur Erfassung und Analyse von Leistungs- und Kostendaten mit Chargeback-Mechanismen (vgl. Lerneinheit

Kennzahlensysteme (KENNZ)

357

KOLER) oder auch CRM-Systeme mit Funktionen zum Export von Leistungs- und Kostendaten in Frage. Die Verwendung eines anspruchsvollen Kennzahlensystems ist daher meist nur sinnvoll, wenn die Kennzahlendaten aus den Anwendungssystemen, insbesondere dem der Kosten- und Leistungsrechnung, automatisch erfasst, verarbeitet (z. B. verdichtet) und visualisiert dargestellt werden können (z. B. als Ampel, Tachometer oder Thermometer). Ein Instrument mit dieser Funktionalität – kurz gesagt: aus Daten Information zu gewinnen – wird Kennzahlen-Cockpit genannt (auch als Cockpit-Chart oder IT-Dashboard bezeichnet). Es kann als Teil eines Managementinformationssystems oder eines Data Warehouses (vgl. Lerneinheit DATEM) implementiert werden. Am IT-Markt werden Werkzeuge für die Implementierung von Kennzahlen-Cockpits angeboten (z. B. Dashboard Manager von Business Objects, QlikView von QlikTech oder Cognos 8 von IBM). Hersteller und Anbieter sind Softwarehäuser, die sich auf Business Intelligence (BI) spezialisiert haben. Wegen der starken Verbreitung von ERP-Systemen werden auch Werkzeuge angeboten, die Kennzahlendaten aus diesen Systemen extrahieren.

Forschungsbefunde Kütz nennt „IT-Kennzahlen für die Praxis“, die von der Fachgruppe 5.7 IV-Controlling der Gesellschaft für Informatik erarbeitet wurden, was ihre Einordnung in Abschnitt Forschungsbefunde rechtfertigen kann. Sie sind in neun Perspektiven gruppiert: Finanzmanagement, Kundenmanagement, Prozessmanagement, Produktmanagement, Mitarbeitermanagement, Lieferantenmanagement, Innovationsmanagement, Projektmanagement und Multiprojektmanagement. Die für die Erklärung verwendeten Attribute sind „Name, Formel, Beschreibung, Beschaffung der Daten, Bewertung“. Diese Systematik mit den rd. 80 definierten Kennzahlen ist als Anregung für die unternehmensspezifische Kennzahlenentwicklung verwendbar. Einen transparenten Konstruktionsprozess mit einem nachvollziehbaren Ergebnis kann sie nicht ersetzen. Jonen et al. beschreiben eine Balanced IT-Decision Card, welche die „Besonderheiten einer BSC für den IT-Bereich“ erfassen soll. Sie verwendet die sechs Perspektiven Sicherheit, Prozess, Innovation, Mitarbeiter, Kunden und Finanzen. Diese werden durch allgemeine Erklärungen beschrieben, aber nicht begründet. Dies gilt auch für den Aufbau und die Darstellung der Ursache-Wirkungs-Beziehungen. Das Beispiel zeigt, dass Forschungsergebnisse nicht immer als Referenzmodelle taugen. Gresse et al. haben den GQM-Ansatz zur Beschreibung, Bewertung, Kontrolle und systematischen Verbesserung von Qualitätszielen im Softwareentwicklungsprozess verwendet (Aktionsforschung, replizierte Fallstudie mit Softwareorganisationen in drei deutschen Unternehmen, Untersuchungszeitraum 1995-1996). Als Ergebnis wird u. a. festgestellt, dass die am Projekt beteiligten Unternehmen durch Anwendung des GQM-Ansatzes einen höheren Reifegrad in der Anwendung des zielorientierten Messens und Bewertens erreicht und dabei Fortschritte in Bezug auf die verwendeten Qualitätsziele erreicht und diese auch nachgewiesen haben. Eine Schlussfolgerung der Autoren ist (134): „In zukünftigen Softwareentwicklungsprozessen wird GQM [von den beteiligten Softwareorganisationen] von Anfang an als projektbegleitende Maßnahme in die Planung einbezogen.“

358

Methoden des strategischen Informationsmanagements

Vanini berichtet zur „Bedeutung von IT-Kennzahlen“ in mittelständischen Unternehmen (schriftliche Befragung von 775 Unternehmen mit einem Jahresumsatz von mindestens eine Mio. Euro, Rücklaufquote 17 %, Befragungszeitraum April 2007): Kennzahlen zur Beurteilung der IT-Wirtschaftlichkeit werden „nur sehr eingeschränkt“ verwendet (82 Unternehmen). Am häufigsten verwendet wird die Kennzahl „Aufwand“ (47 %). „Lediglich 25 % der Unternehmen gaben an, den Nutzen ihrer IT zu evaluieren. Die anderen Kennzahlen spielen keine nennenswerte Rolle. Lediglich 24 Unternehmen verwenden mehr als eine Kennzahl, 47 Unternehmen verzichten völlig auf einen Kennzahleneinsatz.“ (370). Die Autorin fügt dem an, dass dieser Befund durch eine Studie von Gadatsch gestützt wird, nach der 23,7 % der Befragten auf eine Wirtschaftlichkeitsbeurteilung ihrer IT „völlig verzichten“. Becker et al. werden mit dem Befund zitiert, dass auch in großen Unternehmen Kennzahlen zur Ermittlung der IT-Wirtschaftlichkeit nur bei 77 % der Befragten „häufig bis standardmäßig“ verwendet werden. Die Autorin zieht aus diesen Befunden den Schluss (371), „…dass der Einsatz von IT-Kennzahlen zu einer Verbesserung der IT-Wirtschaftlichkeit führen kann.“

Aus der Praxis Hofmann empfiehlt für die Definition von Kennzahlen die Beachtung folgender Kriterien:      

Die Erfüllung des konkreten Ziels muss mittels dieser Kennzahl messbar sein. Der Kennzahl müssen Ziel- und Toleranzwerte zugeordnet werden können. Die für die Berechnung der Kennzahl erforderlichen Basisdaten müssen verfügbar oder aufwandsarm zu ermitteln sein. Die Qualität der Datenquellen muss hinreichend gut sein. Für die Erhebung und Erfassung der Basisdaten müssen Verantwortliche benannt sein. Aus den Kennzahlen müssen sich steuernde Maßnahmen ableiten lassen.

Die obligatorische Dokumentation der Kennzahlen sollte ihre Beschreibung (Bezeichnung, Zielwert, Sollwert, Gültigkeit, Verantwortlicher usw.) und Angaben zur Datenermittlung und -aufbereitung sowie zu ihrer Präsentation beinhalten. Kathmann/Maicher berichten über Erfahrungen bei der Weiterentwicklung des Kennzahlensystems für den IT-Bereich Application Management eines IT-Dienstleister an veränderte strategische Unternehmensziele und organisatorische Einflussfaktoren u. a.: „Die relevanten Kennzahlenperspektiven“ wurden in Anlehnung an die Kennzahlenbereiche von BSC mit Finanzen, Kunden, Prozesse, Innovationen und Mitarbeiter festgelegt (der in BSC verwendete Kennzahlenbereich Lieferanten wurde als zweitrangig beurteilt). Zur „Definition von Anforderungen“ wurden drei Informationsquellen verwendet: das bestehende Funktionskonzept, Interviews mit operativen Führungskräften und Bereichscontrollern sowie Analyse der bestehenden, teilweise bereichsspezifischen Berichtssysteme. Ergebnis war ein „Kennzahlenüberblick“. Jede so gewonnene Kennzahl wurde „bis zur Elementarebene dekomponiert und kritisch hinterfragt“ (z. B. mit den Kriterien Zielbezug, Beeinflussbarkeit, Frühwarnorientierung, Konsistenz, Operationalisierbarkeit). Die Autoren berichten auch über Erfolgsfaktoren des Projekts und acht Lessons Learned. Zur achten davon heißt es (26): „Abschließende Erkenntnis war, dass ein Kennzahlensystem im Prinzip nie fertig wird.“

Kennzahlensysteme (KENNZ)

359

Das Softwareunternehmen Borland empfiehlt für Projekte der Softwareentwicklung drei Arten von Metriken:   

Portfoliometriken begleiten die Entwicklungsprojekte; mit ihnen lässt sich beispielsweise die Einhaltung der Budgets verfolgen, die Aufgabenverteilung darstellen und die Kundenreaktion auf Entwicklungsergebnisse beurteilen. Mit In-flight-Metriken wird der Projektentwicklungsstand zum eigenen Management (z. B. IT-Lenkungsausschuss) und zum Kunden kommuniziert. Über Post-mortem-Metriken werden mögliche Prozessverbesserungen identifiziert (z. B. zur Optimierung der Ressourcennutzung).

Der VDMA (Verband Deutscher Maschinen- und Anlagenbau e. V.) hat ein mehr als 1.500 Kennzahlen umfassendes Kennzahlensystem entwickelt, das für Unternehmen der Investitionsgüterindustrie geeignet ist. Die Kennzahlendaten werden in unterschiedlichen Abständen bei den Mitgliedsunternehmen erhoben und ausgewertet. Daraus kann Information über die gesamte Branche sowie über Teilbranchen, Betriebsgrößenklassen und Regionen gewonnen werden. Das SAP-Systemhaus Steeb Anwendungssysteme hat mit einem Pilotkunden ein Kennzahlen-Cockpit entwickelt, mit dem sich die VDMA-Kennzahlen aus SAP R/3 automatisch generieren lassen. Bislang wurden die Kennzahlendaten manuell erhoben. Es wird erwartet, dass die Erhebungskosten bei den Mitgliedsunternehmen um 60 % bis 80 % reduziert werden können. Die Unternehmensberatung TCW führt den mangelnden Erfolg von Kennzahlensystemen zur Steigerung von Wirksamkeit und Wirtschaftlichkeit der Führung, Überwachung und Steuerung der Geschäftsprozesse auf folgende Schwachstellen zurück, die durch den Einsatz von Kennzahlen-Cockpits beseitigt werden können:      

Die relevanten Kennzahlen werden nicht unternehmensindividuell herausgearbeitet. Es werden nur finanzwirtschaftliche Kennzahlendaten erhoben. Die Konzeption des Kennzahlensystems als „Sammlung von Einzelkennzahlen“ bewirkt den Verlust von Ursache-Wirkungs-Beziehungen. Die Unternehmensstrategie und -mission gehen nicht in das Kennzahlensystem ein. Aus Ineffizienzen werden keine Verbesserungspotenziale abgeleitet. Ein umfassendes Benchmarking ist nicht möglich.

Aufgabenverweise Controlling (Lerneinheit CONTR); Strategische Zielplanung (Lerneinheit SZIEL); Strategische Maßnahmenplanung (Lerneinheit STRAT); Technologiemanagement (Lerneinheit TECHM). Kontrollfragen 1. Welcher Zusammenhang zwischen Daten und Information und welche Unterschiede zwischen beiden sind für die Konstruktion eines Kennzahlensystems relevant? 2. Mit welchen Arbeitsschritten kann der Konstruktionsprozess für ein Kennzahlensystem beschrieben werden? 3. Welche weiteren, in der Lerneinheit nicht genannten Phänomene des IT-Bereichs sind als Business Enabler oder als Treiber besonders erfolgskritisch? 4. Welchen Beitrag liefern Referenzsysteme für die Konstruktion eines IT-Kennzahlensystems? 5. Welche Schlussfolgerungen sind aus den Forschungsbefunden im Hinblick auf aktuelle Forschungsbedarfe zum Forschungsgegenstand Kennzahlensysteme zu ziehen?

360

Methoden des strategischen Informationsmanagements

Quellen Basili, V. R. / Caldiera, G. / Rombach, H. D.: Goal Question Metric Paradigm. In: Marciniak, J. J. (Ed.): Encyclopedia of Software Engineering. New York 1994, 528–532 Blomer, R. / Bernhard, M. (Hrsg.): Balanced Scorecard in der IT. Düsseldorf 2003 Borland GmbH Langen: Kennzahlen helfen bei der besseren Ressourcennutzung. http://www.borland.com/de; Abruf 14.11.2008 Diebold Deutschland GmbH (Hrsg.): Diebold Kennzahlensystem (DKS). Ein Instrument zur Analyse der Wirkungen des Einsatzes informationstechnischer Mittel und Verfahren. Frankfurt a. M. 1984 Glohr, C.: IT-Kennzahlen für den CIO. In: CONTROLLING 3/2006, 149–156 Gresse, C. / Hoisl, B. / Rombach, D. / Ruhe, G.: Kontinuierliche Qualitätsverbesserung in der SoftwareEntwicklung. In: WIRTSCHAFTSINFORMATIK 2/1996, 160–171 Gresse, C. / Rombach, D. / Ruhe, G.: Kosten/Nutzen-Analyse von GQM-basiertem Messen und Bewerten. In: Grün, O. / Heinrich, L. J. (Hrsg.): Wirtschaftsinformatik – Ergebnisse empirischer Forschung. Wien/New York 1997, 119–135 Hofmann, E.: Kennzahlensysteme für Outsourcing-Dienstleistungen. Siemens Communication Consulting, Frankfurt a. M. 2003 Jonen, A. et al.: Balanced IT-Decision Card. In: WIRTSCHAFTSINFORMATIK 3/2004, 196–203 Kaplan, R. S. / Norton, D. P.: Balanced Scorecard. Stuttgart 1997 Kathmann, H. / Maicher, M.: Kennzahlensystem für einen konzerngebundenen IT-Dienstleister. In: HMD – Praxis der Wirtschaftsinformatik 254/2007, 16–26. Kütz, M. (Hrsg.): Kennzahlen in der IT. Heidelberg 2003 Steeb Anwendungssysteme GmbH Abstatt: Kennzahlen-Cockpit. http://www.steeb.de; Abruf 13.11.2008 Stelzer, D. / Bratfisch, W.: Earned-Value-Analyse – Controlling-Instrument für IT-Projekte und IT-Projektportfolios. In: HMD – Praxis der Wirtschaftsinformatik 254/2007, 61–70 TCW GmbH München – Kennzahlen-Cockpit: http://www.tcw.de/static_pages/view/34; Abruf 29.4.2011 Vanini, U.: Steuerung der IT-Wirtschaftlichkeit in mittelständischen Unternehmen. In: CONTROLLING 7/2008, 367–373 Vertiefungsliteratur Gladen, W.: Performance Measurement – Controlling mit Kennzahlen. 3. A., Wiesbaden 2005 Heinrich, L. J. / Damschik, I.: Kennzahlen für das strategische Controlling der Informationsverarbeitung. In: Rauch, W. / Strohmeier, F. / Hiller, H. / Schlögel, Ch. (Hrsg.): Mehrwert von Information – Professionalisierung der Informationsarbeit. Konstanz 1994, 461–470 Horváth, P.: Controlling. 11. A., München 2009 Kaplan, R. S. / Norton, D. P.: Die strategiefokussierte Organisation – führen mit der Balanced Scorecard. Stuttgart 2001 Reb, M. / Herr, R.: IV-Infrastruktur-Controlling – Kennzahlengestützte Steuerung der IT-Ressourcen. In: Krcmar, H. et al. (Hrsg.): IV-Controlling auf dem Prüfstand. Wiesbaden 2000, 75–103 Reichmann, T.: Controlling mit Kennzahlen und Management-Tools. 7. A., München 2006 Van Solingen, R. / Berghout, E.: The Goal/Question/Metric Method. New York 1999 Normen DIN 69903: Projektwirtschaft – Kosten und Leistung, Finanzmittel – Begriffe. 1987

Wirtschaftlichkeitsanalyse (WIRTA) Lernziele Sie kennen den Zweck von Wirtschaftlichkeitsanalysen bei IT-Investitionen. Sie können Kosten und Nutzen in Kostenarten und Nutzenarten zerlegen. Sie wissen, wie bei der Analyse der Kostenstruktur und bei der Analyse der Nutzenstruktur sowie bei der Analyse der Beziehungszusammenhänge zwischen Kosten und Nutzen vorgegangen wird. Sie kennen den Unterschied zwischen Wirtschaftlichkeitsanalysen und Wirtschaftlichkeitsrechnungen.

Definitionen und Abkürzungen Analyse (analysis) = möglichst exakte Bestimmung und Charakterisierung von Teilen eines Systems (eines Ganzen) sowie der Beziehungen der Teile untereinander und zum Ganzen mit dem Zweck, das Ganze zu erklären. Kennzahl (metric) = Zahl über Daten mit konzentrierter Aussagekraft zur Planung, Überwachung und Steuerung sowie zur Diagnose eines Systems. Kosten (costs) = mit Geldeinheiten bewertete Konsequenzen einer Leistung bezüglich ihres Verzehrs an Gütern und/oder Diensten. Kosten-Nutzen-Analyse (cost value analysis) = Variante der Nutzwertanalyse, bei der die Kosten der Alternativen zunächst nicht in das Zielsystem aufgenommen werden; nach der Ermittlung des Nutzwerts wird dieser mit dem Kostenwert in Beziehung gesetzt. Kostenart (cost item) = Ergebnis der Zerlegung von Kosten nach der Art des Verbrauchs an Gütern und/oder Dienstleistungen. Kostenstruktur (cost structure) = Zusammensetzung von Kosten nach Kostenart und Kostenhöhe bzw. relativer Anteil der Kosten je Kostenart. Lebenszyklus (life cycle) = nach Phasen strukturierte Lebensdauer eines Objekts (z. B. ein Produkt oder eine Dienstleistung). Lebenszyklusmodell (life cycle model) = geordnete Menge von Phasen, die ein Produkt oder eine Dienstleistung in bestimmter Anordnung zwingend durchläuft. Leistung (performance) = Fähigkeit eines Systems, in quantitativer oder qualitativer Hinsicht eine bestimmte Aufgabe zu erfüllen. Leistungsmanagement (performance management) = Managementprozess, dessen Zweck die Analyse der Leistung und deren zielgerichtete Beeinflussung ist. Nutzen (benefit) = Wert einer Handlungsalternative zur Befriedigung eines definierten Bedarfs. Synonym: Nutzwert. OR = Operations Research; Anwendung mathematischer Methoden zur Vorbereitung und Herbeiführung optimaler Entscheidungen. Prognose (forecast) = Voraussage einer zukünftigen Entwicklung oder eines zukünftigen Zustands auf Grundlage systematisch ermittelter Daten und Verwendung wissenschaftlicher Erkenntnisse. Projektplanung (project planning) = Prüfung der Realisierbarkeit der Anforderungen eines Projekts durch Herausarbeitung seiner organisatorischen, technischen, personellen, rechtlichen und wirtschaftlichen Konsequenzen (z. B. Aufgabenplanung, Terminplanung).

362

Methoden des strategischen Informationsmanagements

Zweck der Wirtschaftlichkeitsanalyse Zweck der Wirtschaftlichkeitsanalyse ist es, Systeme oder Systementwürfe sowie Produkte und Dienstleistungen, aber auch die Entwicklung und/oder den Einsatz von Methoden und Werkzeugen, kurz: jede Art von Investition im IT-Bereich unter dem Formalziel Wirtschaftlichkeit zu beurteilen. Dies erfolgt durch Analyse, d. h. durch Zerlegen des betrachteten Objekts in Teile, das Untersuchen dieser Teile und das Zusammenfassen der Beurteilungen zu einem Befund, nämlich dem der Wirtschaftlichkeit. Unter Wirtschaftlichkeit wird die Eigenschaft eines Objekts verstanden, bezüglich einer geplanten oder tatsächlichen Kostensituation in einem bestimmten Verhältnis zu einer Bezugsgröße (z. B. der günstigsten Kostensituation) oder bezüglich seiner Leistungssituation (z. B. Nutzen oder Nutzwert) in einem bestimmten Verhältnis zu einer Bezugsgröße (z. B. dem mit Kosten bewerteten Einsatz an Produktionsfaktoren zur Erbringung einer Leistung) zu stehen (vgl. Lerneinheit SZIEL). Ergebnis einer Wirtschaftlichkeitsanalyse ist das KostenNutzen-Verhältnis des untersuchten Objekts. Im Mittelpunkt der folgenden Erklärung stehen Analyseobjekte, deren Gegenstand die Entwicklung neuer oder die wesentliche Veränderung bestehender Informationssysteme ist (Entwicklungsprojekte). Je nach Analyseobjekt sind objektspezifische Anpassungen des Analysemodells erforderlich. Das Ergebnis eines Entwicklungsprojekts ist dann wirtschaftlich, wenn die Kosten der Entwicklung und Einführung (rollout) zuzüglich der Kosten der Nutzung (Nutzungs- oder Betriebskosten) des Projektergebnisses und der späteren Änderungen daran (z. B. Wartungskosten, Reengineering-Kosten) bezogen auf den geplanten Einsatzzeitraum einschließlich der Kosten der Entsorgung unter dem erwarteten Nutzen liegen. Der Nutzungszeitraum wird häufig als Lebenszyklus bezeichnet, weil er mehrere unterschiedliche „Lebensphasen“ umfasst (vgl. Lerneinheit LEMAN). Lebenszykluskosten sind die für den gesamten Lebenszyklus prognostizierten Kosten. Das sind nicht nur die Kosten des IT-Bereichs, sondern auch Kosten, die durch den IT-Einsatz in den Fachbereichen verursacht werden (z. B. für einen IT-Koordinator), sowie Kosten für Leistungen, die von anderen Fachbereichen für den ITBereich erbracht werden (z. B. Leistungen des Rechnungswesens, des Controllings oder der Revision). Die Gesamtheit dieser Kosten wird als Total Cost of Ownership (TCO) bezeichnet. Werden die TCO durch die Anzahl Nutzungsjahre dividiert, wird von jährlichen Lebenszykluskosten gesprochen. Nach dieser Terminologie ist das Projektergebnis dann wirtschaftlich, wenn seine Lebenszykluskosten unter dem erwarteten Nutzen für den gesamten Lebenszyklus liegen. Beim Vergleich nutzengleicher Alternativen gilt, dass die Alternative optimal ist, deren Lebenszykluskosten kleiner sind als die der anderen Alternativen. Für die Evaluierung der Leistungssituation ist zu berücksichtigen, dass Leistungen nur teilweise quantitativ erfasst werden können; viele Leistungen sind häufig das Resultat einer Schätzung oder nur qualitativ erfassbar. Deshalb ist es erforderlich, neben der üblichen Wirtschaftlichkeitsanalyse eine umfassende Beurteilung der Kosten- und Leistungssituation durchzuführen (z. B. mit einer Nutzwertanalyse, vgl. Lerneinheit NUTZW). Dabei wird für alle definierten Projektziele das Ausmaß der Zielerreichung ermittelt und über das gesamte Zielsystem der Nutzwert bestimmt. Die Ergebnisse der Wirtschaftlichkeitsanalyse gehen als Ausmaß der Zielerreichung für das Projektziel Wirtschaftlichkeit in die Nutzwertanalyse ein.

Wirtschaftlichkeitsanalyse (WIRTA)

363

Anforderungen der Wirtschaftlichkeitsanalyse Eine Wirtschaftlichkeitsanalyse für ein Entwicklungsprojekt kann erst durchgeführt werden, wenn die Ergebnisse verschiedener Teile der Projektplanung vorliegen (z. B. Aufgabenplanung, Personalplanung, Sachmittelplanung und Terminplanung bei Projekten der Systementwicklung). Diese Planungen bestimmen mit ihrem sachlichen Lösungsvorschlag die voraussichtlichen Kosten der Entwicklung, Einführung, Nutzung und Weiterentwicklung sowie mit den geplanten Funktionen und Leistungen den Nutzen des Projektergebnisses. Grundproblem der Wirtschaftlichkeitsanalyse ist, dass ein Projekt bzw. sein Ergebnis in seiner Wirkung auf Kosten und Nutzen nicht isoliert betrachtet werden kann; mit der Verwendung von Wirtschaftlichkeitsmodellen wird versucht, dieses Problem zu lösen (vgl. den gleichnamigen Abschnitt weiter unten). Die Analyse der Wirtschaftlichkeit erfordert Prognosen über Kosten und Nutzen und ist mit Unsicherheit behaftet. Je später ein Kostenfaktor oder ein Nutzenfaktor in der Zukunft wirksam wird, desto unsicherer ist die Aussage, die zum Analysezeitpunkt über seine tatsächliche Höhe gemacht werden kann. Kostenprognosen sind grundsätzlich sicherer als Nutzenprognosen, und Entwicklungskosten sind grundsätzlich genauer prognostizierbar als die erst während der Einführung und häufig auch erst während der Nutzung entstehenden Betriebskosten und Wartungskosten. Nutzenprognosen werden durch kurze Lebenszyklen der Technologien erschwert, da Erfahrungswerte schnell veralten. Die Wirtschaftlichkeitsanalyse muss je nach Projektumfang und Projektdauer in bestimmten Projektphasen bzw. an deren Ende (z. B. an den Meilensteinterminen) überprüft, korrigiert, vertieft und schließlich, nach der Systemeinführung, verifiziert werden (Ex-post-Evaluierung, vgl. Lerneinheit TECHM). Mit diesem planmäßigen Nachjustieren der Wirtschaftlichkeitsanalyse soll auch ihre willkürliche Verwendung (z. B. zum „Abwürgen“ eines Projekts) sowie eine Verwendung, die sich nur am Projektnotstand orientiert (z. B. zum Nachweis der weiterhin bestehenden Wirtschaftlichkeit) vermieden werden. An welchen Terminen bzw. bei Vorliegen welcher Zwischenergebnisse im Projektverlauf weitere Wirtschaftlichkeitsanalysen durchgeführt werden, sollte durch die Projektplanung festgelegt werden, die sich an den Anforderungen des verwendeten Vorgehensmodells orientiert (vgl. Lerneinheit VOMOD). Dies schließt nicht aus, dass sie auch ad hoc veranlasst werden können (z. B. durch den Lenkungsausschuss, vgl. Lerneinheit STRUK, auf Grund von Feststellungen der projektbegleitenden Revision, vgl. Lerneinheit REVIS).

Vorgehensweise der Wirtschaftlichkeitsanalyse Im wörtlichen und eigentlichen Sinne heißt Wirtschaftlichkeitsanalyse Folgendes:   

Analyse der Kostenstruktur, Analyse der Nutzenstruktur und Analyse der Beziehungen zwischen Kosten und Nutzen.

Die Betonung liegt auf Analyse, nicht auf Ermittlung einzelner Indikatoren für Wirtschaftlichkeit (z. B. Amortisationsdauer bei einer statischen Methode oder interner Zinsfuß bei einer dynamischen Methode der Wirtschaftlichkeitsrechnung, vgl. weiter unten).

364

Methoden des strategischen Informationsmanagements

Analyse der Kostenstruktur Kostenstruktur ist die Höhe und Zusammensetzung der Kosten nach Kostenarten, die für die Aufgaben der Entwicklung und Einführung (Entwicklungskosten), der Nutzung oder des Betriebs (Nutzungskosten oder Betriebskosten) und der Wartung (Wartungskosten) eines Informationssystems entstehen. Entwicklungskosten, Betriebskosten und Wartungskosten können wie folgt in Kostenarten gegliedert werden (Mindestgliederung):         

Personalkosten und Personal-Nebenkosten (wie Löhne, Gehälter, Sozialleistungen, Arbeitsplatzkosten), Hardwarekosten (wie Mietkosten bzw. Abschreibungen und Wartungskosten), Softwarekosten (wie Lizenz- und Wartungskosten bei Fremdbezug bzw. Abschreibungen bei Fremdbezug oder Eigenfertigung), Netzkosten (wie Leitungskosten und Kosten für Transportdienste), Materialkosten (wie für Formulare, Datenträger, Mikrofilme), Energiekosten im Rechenzentrum (wie Stromverbrauch für Hardwarebetrieb und Klimatisierung) und im Büroumfeld (wie Stromverbrauch für PCs und Arbeitsplatzdrucker), Kosten für Büroausstattung und -geräte, Grundstücks- und Gebäudekosten (wie Pacht, Miete und Instandhaltung) und Fremdkosten (wie Beratungskosten und Kosten für Outsourcing).

Zweck der Kostenartengliederung ist es, die Kostenarten zu identifizieren, bei denen sich Höhe und Zusammensetzung der Kosten im geplanten Zustand (Sollzustand) gegenüber dem gegenwärtigen Zustand (Istzustand) wesentlich verändern. Dabei kann die Verwendung der für die Kosten- und Leistungsrechnung üblichen Kostenstruktur hilfreich sein, obwohl diese grundsätzlich einen anderen Zweck erfüllt (vgl. Lerneinheit KOLER). Dadurch kann für das geplante Informationssystem eine Kostenstruktur sichtbar gemacht werden, die gegenüber dem Istzustand und/oder einem anderen Vergleichszustand (z. B. dem branchenüblichen oder bestmöglichen) vorteilhaft ist. Die Veränderung (Kostenreduzierung und/oder Kostenverschiebung) muss beurteilt werden. Die Analyse der Kostenarten erfolgt in der Reihenfolge ihrer relativen Bedeutung an den Gesamtkosten (d. h. die Kostenart mit der relativ größten Bedeutung werden zuerst untersucht). Aussagen über die Kostenstruktur allein können zu Fehlschlüssen führen, da jede einzelne Kostenart auch die Höhe der Gesamtkosten und über die Höhe der Gesamtkosten die relative Bedeutung der anderen Kostenarten bestimmt. Aus der Kostenstruktur allein lässt sich nicht erkennen, ob das Kostenniveau zu hoch ist; dies kann nur durch Gegenüberstellung der Kosten mit anderen Kennzahlen oder dadurch beurteilt werden, dass die Kosten mit absoluten Zahlen von Alternativen oder mit Sollgrößen verglichen werden (z. B. mit einem Competitive Benchmarking, vgl. Lerneinheit MEGPM). Bei der Analyse der Kostenstruktur werden auch die Kosten erfasst und untersucht, die Gemeinkosten sind; dies erfolgt methodisch mit der Gemeinkosten-Wertanalyse. Analog zur Vorgehensweise bei der Wertanalyse werden die Gemeinkosten daraufhin untersucht, ob die sie verursachenden Funktionen für die Erreichung des Zwecks des Untersuchungsobjekts unbedingt erforderlich (Hauptfunktionen), nur erforderlich (Nebenfunktionen) oder überflüssig sind. Bei der Durchführung der Gemeinkosten-Wertanalyse wird von der Annahme aus-

Wirtschaftlichkeitsanalyse (WIRTA)

365

gegangen, dass ein bestimmter Teil, etwa zwischen einem Viertel bis einem Drittel, der die Gemeinkosten verursachenden Funktionen überflüssig ist, so dass auf sie verzichtet werden kann, ohne die vom Anwender genutzte Funktionalität und geforderte Leistung des Untersuchungsobjekts zu verringern. Ohne eine solche realistische Annahme über das Verbesserungspotenzial lohnt sich erfahrungsgemäß eine Wertanalyse nicht. Zweck der Wertanalyse (WA) ist es, den Wert eines Objekts (WA-Objekt) durch ein Mehr an Funktionserfüllung und/oder ein Weniger an Kosten zur Realisierung der Funktionserfüllung zu steigern. Die Benennung „Wert“ wird auch verwendet, wenn außer den Kosten noch andere Faktoren betrachtet werden (z. B. Zuverlässigkeit, Verfügbarkeit von Ressourcen, Zeit). Dabei ist nicht das WA-Objekt in seiner physischen Realisierung Mittelpunkt der Betrachtung, sondern dessen Funktionen und der Wert der Funktionserfüllung für die Benutzer. Diese Sichtweise entspricht der für Entwicklungsprojekte typischen Methodik, die zwischen logischem Modell (Systementwurf) und physischem Modell (Systemimplementierung) unterscheidet und die fordert, sich von den physischen Attributen des Istzustands zu lösen und physische Attribute des Sollzustands als alternative Realisierungsmöglichkeiten eines logischen Modells des Sollzustands zu verstehen (vgl. dazu Heinrich/Heinl/Riedl, 116 f.). Zur Ergänzung zur Kostenstrukturanalyse und zur Analyse des Kostenniveaus kann durch eine Kostenverlaufsanalyse der Einfluss sprungfixer Kosten transparent gemacht werden. Für viele IT-Betriebsmittel typisch ist, dass eine steigende Arbeitslast bis zur Kapazitätsgrenze ohne wesentliche Änderung des Systemverhaltens (z. B. der Transaktionszeiten) möglich, bei Erreichen der Kapazitätsgrenze die Erweiterung der Kapazität des betreffenden Betriebsmittels bzw. die Anschaffung weiterer Betriebsmittel erforderlich ist.

Analyse der Nutzenstruktur Nutzenstruktur ist die Zusammensetzung des Nutzens nach Nutzenarten oder Nutzenfaktoren und deren Ausmaß; es gelten die Aussagen analog, die zur Analyse der Kostenstruktur gemacht wurden. Folgende Nutzenfaktoren werden unterschieden: direkt monetär messbarer Nutzen, indirekt monetär messbarer Nutzen und nicht monetär messbarer Nutzen. 





Ein direkt monetär messbarer Nutzen entsteht durch Kostensenkung (Minderkosten des geplanten Systems gegenüber dem bestehenden). Technologieunterstützung führt zu Kostensenkung, wenn durch geringere Kosten für Betriebsmittel höhere Personalkosten, und andere Sachkosten ersetzt werden. Zur Messung des monetären Nutzens werden die Werte der Kostenrechnung des bestehenden Systems gemäß Kosten- und Leistungsrechnung (vgl. Lerneinheit KOLER) den Kosten des geplanten Systems gegenübergestellt. Der indirekt monetär messbare Nutzen hat zwei Formen. Erstens können durch Technologieunterstützung Kosten gesenkt werden (z. B. Lagerkosten durch Verringerung des Lagerbestands). Zweitens kann durch Produktivitätssteigerung eine zukünftige Kostensteigerung vermieden werden (z. B. durch Marktausdehnung oder Sortimentserweiterung). Die Erfassung des indirekt monetär messbaren Nutzens erfolgt über eine Erfassung von Mengen (z. B. Umsatzsteigerung) und deren Bewertung (z. B. mit Marktpreisen oder Verrechnungspreisen). Der nicht monetär messbare Nutzen entsteht durch organisatorische und personelle Veränderungen wie Verbesserung der Qualität von Entscheidungen durch besseres Informa-

366

Methoden des strategischen Informationsmanagements

tionsangebot, Verbesserung der innerbetrieblichen und zwischenbetrieblichen Kommunikation und Erhöhung der Fachkompetenz der Mitarbeiter und der Arbeitszufriedenheit. An die Stelle der (direkten oder indirekten) Nutzenmessung tritt eine Nutzenschätzung.

Analyse der Kosten-Nutzen-Beziehungen Bei der Analyse der Beziehungen zwischen Kostenstruktur und Nutzenstruktur handelt es sich um ein umfassendes Verfahren der Gliederung und Aufbereitung der beiden Bezugsgrößen der Wirtschaftlichkeit, also der Kosten und des Nutzens. Dabei werden die einzelnen Kostenarten und Nutzenarten so miteinander vernetzt, dass eine zahlenmäßige Abbildung der Beziehungszusammenhänge hergestellt wird. Damit lässt sich der komplexe Zusammenhang zwischen Kosten und Nutzen auf kausale bzw. funktionale Einflussgrößen zurückführen. Gefragt wird also danach, welche Nutzenart welche Kostenart(en) verursacht bzw. – umgekehrt betrachtet – welche Kostenart welche Nutzenart(en) generiert. Von den Antworten dazu ausgehend wird wertanalytisch untersucht, durch welche Veränderungen der Kostenstruktur und/oder der Nutzenstruktur die Wirtschaftlichkeit positiv beeinflusst werden kann, indem Funktionen und/oder Leistungen des Analyseobjekts verändert werden bzw. auf sie verzichtet wird (Änderung des durch Anforderungsanalyse erstellten Anforderungsprofils). Wegen der Abhängigkeiten der einzelnen Kostenarten und Nutzenarten voneinander lassen sich derartige Beziehungszusammenhänge oft nur schwer isolieren und quantifizieren. Dies führt zu der Forderung, die Kostenstruktur und die Nutzenstruktur nicht zu fein zu wählen. Zwischen einer zu feinen Gliederung und einer zu groben Gliederung muss ein Kompromiss gefunden werden. Kennzahlen über Beziehungszusammenhänge, die aus umfassenden Analysen gewonnen werden (z. B. aus Branchenuntersuchungen), lassen im Vergleich mit Plandaten oder mit Daten anderer Alternativen erkennen, wo Schwachstellen bestehen und wo Maßnahmen zur Verbesserung der Wirtschaftlichkeit angesetzt werden können (vgl. auch Lerneinheit KENNZ). Auch eine nur verbale Beschreibung der Beziehungszusammenhänge ist erfahrungsgemäß hilfreich, wenn eine Quantifizierung nicht möglich ist.

Aktivierung von Entwicklungskosten Für die Analyse der Kostenhöhe, der Kostenstruktur und des Kostenverlaufs sowie für Zwecke der Kosten- und Leistungsrechnung (vgl. Lerneinheit KOLER) werden auch bei Eigenfertigung die Entwicklungskosten zu Herstellungskosten aktiviert und daraus Abschreibungen ermittelt. In der Regel erfolgt eine lineare Abschreibung über drei bis vier Jahre. Handels- und steuerrechtlich ist – nach deutscher und österreichischer Rechtslage – eine Aktivierung der Entwicklungskosten dagegen nur bei Fremdbezug zulässig (§ 197 Abs. 2 bzw. § 248 Abs. 2 HGB). Das Aktivierungsverbot dient primär dem Gläubigerschutz (Vorsichtsprinzip), widerspricht aber einer periodengerechten Erfolgsermittlung und der Vermittlung eines möglichst getreuen Bildes der Vermögens- und Ertragslage. In der Fachliteratur (z. B. bei Pirker) wird ein Aktivierungswahlrecht vorgeschlagen, wobei die Aktivierung an das Vorliegen einer verlässlichen Kosten- und Leistungsrechnung gebunden ist. Damit verbunden sein soll die Verpflichtung zu einem gesonderten Ausweis der aktivierten Beträge, zur Festlegung eines begrenzten Abschreibungszeitraums und zu einer Ausschüttungssperre

Wirtschaftlichkeitsanalyse (WIRTA)

367

sowie Erläuterungspflichten im Anhang zum Jahresabschluss. Die International Accounting Standards (IAS) erlauben die Aktivierung unter folgenden Voraussetzungen:     

Das Produkt ist klar definiert und die im Zusammenhang mit ihm entstandenen Kosten lassen sich direkt zuordnen und zuverlässig bestimmen. Die technische Durchführbarkeit des Produkts kann nachgewiesen werden. Das Unternehmen beabsichtigt, das Produkt zu vermarkten oder selbst zu verwenden. Ein Markt für das Produkt ist vorhanden oder – sofern es nur intern genutzt werden soll – kann sein Nutzen für das Unternehmen nachgewiesen werden. Ausreichende Ressourcen für die Durchführung und den Abschluss des Projekts und den Vertrieb oder Einsatz des Produkts sind vorhanden oder ihre Verfügbarkeit kann nachgewiesen werden.

Softwareaktivierung in diesem Sinne darf nicht mit der häufig gleich bezeichneten Sicherungsmaßnahme zum Kopierschutz verwechselt werden, die treffender Produktaktivierung genannt wird (vgl. Lerneinheit VERMA).

Wirtschaftlichkeitsrechnungen Entscheidende Schwäche der Verfahren der Wirtschaftlichkeitsrechnung ist, dass nur monetäre Größen verwendet und qualitative Wirkungen nicht berücksichtigt werden. Sie ersetzen die Wirtschaftlichkeitsanalyse daher nicht, können sie aber ergänzen. Für eine umfassende Beurteilung der Wirtschaftlichkeit ist es zweckmäßig, Verfahren zu verwenden, die mehrere Einzelansätze kombinieren. Nach dem Zeitpunkt der Durchführung werden zwei Formen der Wirtschaftlichkeitsrechnung unterschieden, Planungsrechnungen und Kontrollrechnungen.  

Planungsrechnungen ermitteln die Wirtschaftlichkeit vor der Entscheidung (ex ante), um die im Sinne der Zielsetzung optimale Handlungsalternative zu ermitteln; es handelt sich um Soll-Soll-Vergleiche. Kontrollrechnungen ermitteln während und/oder nach der Entscheidung (ex post), inwieweit die Zielplanung verwirklicht werden konnte; es handelt sich um Soll/IstVergleiche.

Für das Technologiemanagement sind sowohl Planungsrechnungen als auch Kontrollrechnungen von Bedeutung. Die meisten Methoden der Wirtschaftlichkeitsrechnung sind für einfache, meist monetäre Ziele entwickelt worden. Sie werden nach dem verwendeten mathematischen Modelltyp in zwei Gruppen geordnet, nämlich Ermittlungsmodelle (Methoden der Investitionsrechnung) und quantitative Entscheidungsmodelle (OR-Modelle). Beide Modelltypen werden zur Beantwortung der folgenden Fragen verwendet:  

Ist eine geplante Investition (z. B. ein Entwicklungsprojekt) unter bestimmten Voraussetzungen „absolut“ vorteilhaft? Welche von mehreren alternativen Investitionen (z. B. mehrere Entwicklungsprojekte) ist unter bestimmten Voraussetzungen vorteilhafter?

Für die Beantwortung der zweiten Frage muss die Forderung nach der absoluten Vorteilhaftigkeit erfüllt sein.

368

Methoden des strategischen Informationsmanagements

Ermittlungsmodelle Diese verwenden entweder statische oder dynamische Methoden. Der wesentliche Unterschied besteht darin, dass statische Methoden keine zeitlichen Gesichtspunkte im Entstehen der Einzahlungen und Auszahlungen berücksichtigen, während dies bei dynamischen Methoden der Fall ist (z. B. zu Verrechungspreisen bewertete Erlöse interner IT-Leistungen als Einzahlungen und Anschaffungskosten für IT-Betriebsmittel zur Erbringung dieser Leistungen als Auszahlungen, vgl. Lerneinheit KOLER). Da in der Wirklichkeit Einzahlungen und Auszahlungen zu unterschiedlichen Zeitpunkten stattfinden und da ihr Wert umso höher ist, je früher sie entstehen (et vice versa), entsprechen dynamische Methoden eher der Wirklichkeit als statische Methoden. Der daraus folgenden größeren Genauigkeit der dynamischen Methoden steht die leichtere praktische Handhabung der statischen Methoden gegenüber. Statische Methoden sind Kostenvergleichsrechnung, Gewinnvergleichsrechnung, Rentabilitätsrechnung und Amortisationsrechnung.   



Die Kostenvergleichsrechnung stellt die Kosten der Alternativen einander gegenüber. In den Kostenvergleich werden alle Kostenarten einbezogen, in denen sich die Alternativen unterscheiden. Optimal ist die Alternative mit den geringsten Kosten. Die Gewinnvergleichsrechnung erweitert die Kostenvergleichsrechnung um die Erlöse; es wird der Gewinn der Alternativen als Differenz zwischen Erlösen und Kosten ermittelt. Optimal ist die Alternative mit dem höchsten Gewinn. Mit der Rentabilitätsrechnung wird der Durchschnittsgewinn einer Periode (z. B. ein Jahr oder der gesamte Lebenszyklus) zum durchschnittlich gebundenen Kapital in Beziehung gesetzt. Ergebnis ist die Durchschnittsverzinsung des durchschnittlich gebundenen Kapitals (Rentabilität). Optimal ist die Alternative mit der höchsten Rentabilität. Mit der Amortisationsrechnung wird der Zeitraum ermittelt, in dem das für eine Alternative eingesetzte Kapital aus den Rückflüssen wiedergewonnen wird (Amortisationszeit). Optimal ist die Alternative mit der kürzesten Amortisationszeit.

Dynamische Methoden sind verschiedene Vermögenswertmethoden und Zinssatzmethoden. 



Vermögenswertmethoden ermitteln den Vermögenszuwachs während der Planperiode bei gegebenem Zinssatz. Zu dieser Methodengruppe gehören die Kapitalwertmethode (auch Vermögensbarwertmethode genannt) und die Vermögensendwertmethode. Die Kapitalwertmethode bezieht die Zahlungen auf den Beginn der Planperiode; für die Finanzmittelaufnahme und -anlage wird ein einheitlicher Zinssatz verwendet. Die Vermögensendwertmethode bezieht die Zahlungen auf das Ende der Planperiode; Aufnahmezinssatz und Anlagezinssatz sind nicht identisch. Zinssatzmethoden ermitteln einen Zinssatz bei gegebenem Vermögenszuwachs von Null während der Planperiode. Zu dieser Methodengruppe gehören die Interne-ZinssatzMethode und die Sollzinssatz-Methode. Die Interne-Zinssatz-Methode bestimmt den Zinssatz aus den Zahlungen; Zinssätze sind nicht vorgegeben. Die Sollzinssatz-Methode bestimmt eine obere Schranke für den Aufnahmezinssatz (Soll) aus den Zahlungen unter Berücksichtigung eines exogenen Habenzinssatzes (Anlagezinssatz).

Wirtschaftlichkeitsanalyse (WIRTA)

369

Die Brauchbarkeit der Investitionsrechnungsmethoden zur Beurteilung der Wirtschaftlichkeit von IT-Investitionen, insbesondere die von IT-Projekten wie Entwicklungsprojekte, ist relativ gering. Um Investitionsbudgets konkurrierende Projekte lassen sich damit sehr gut beurteilen; dies ist aber eine Aufgabe des Portfoliomanagements und damit der strategischen Maßnahmenplanung (vgl. Lerneinheit SPLAN). Für eine Reihe von Auswahlproblemen bei IT-Projekten eignen sich die theoretisch wenig anspruchsvollen statischen Methoden besser als die theoretisch genaueren dynamischen Methoden.

Quantitative Entscheidungsmodelle Diese Modelle ermitteln die Vorteilhaftigkeit der Alternativen im Hinblick auf ein bestimmtes Ziel. Dazu gehören analytische Methoden und Simulation. Bei Verwendung analytischer Methoden wird das zu lösende Problem (Realproblem) in ein mathematisches Problem (Formalproblem) übertragen. Auf das Formalproblem können verschiedene mathematische Methoden zur Problemlösung angewendet werden (z. B. die Simplex-Methode, ein Verfahren der linearen Programmierung). Das Ergebnis der Lösung des Formalproblems wird auf die Wirklichkeit übertragen, und man erhält so die Lösung des Realproblems. Die Anwendbarkeit analytischer Methoden zur Beurteilung der Wirtschaftlichkeit von IT-Investitionen ist deshalb gering, weil sich die komplexe Wirklichkeit nur selten mit einem vertretbaren Aufwand als mathematisches Modell abbilden lässt. Besonderes Kennzeichen der Simulation ist die ausdrückliche Problembezogenheit, das heißt, es wird ein konkretes Problem der Wirklichkeit untersucht. Simulationsmodelle sind daher meist stochastische Modelle. Ihre entscheidende Stärke ist, dass das zu untersuchende System wirklichkeitsnah abgebildet werden kann. Eine Simulationsstudie ist dann zweckmäßig, wenn eine oder mehrere der folgenden Bedingungen für die Problemlösung von Bedeutung sind:     

Die Wirklichkeit ist zu komplex und/oder zu kompliziert, um sie als ein geschlossen lösbares Formalproblem abbilden zu können; analytische Methoden versagen deshalb. Modellieren und Experimentieren, das heißt das Beobachten des Systemverhaltens am Modell, führen zu einem besseren Problemverständnis. Durch analytische und numerische Methoden ermittelte Problemlösungen können durch Simulation überprüft (verifiziert bzw. falsifiziert) werden. Durch Simulation kann auch das dynamische Verhalten eines Systems, das heißt sein Verhalten im Zeitablauf, beobachtet werden. Durch Simulation können die Auswirkungen gezielter Veränderungen eines Parameters oder einer Kombination von Parametern auf bestimmte Eigenschaften des Systems untersucht werden.

Probleme, die bei einer Simulationsstudie auftreten können, sind:  

Das Modellieren ist im Allgemeinen mit einem relativ großen Aufwand verbunden. Da jeder Simulationslauf (Modelllauf) eines stochastischen Simulationsmodells nur eine Ausprägung eines stochastischen Prozesses ist, müssen mehrere, oft sehr viele Simulationsläufe durchgeführt werden.

370

 

Methoden des strategischen Informationsmanagements

Der große Umfang an quantitativen Daten als Ergebnis einer Simulationsstudie erweckt den Anschein eines hohen, nicht immer gegebenen Wahrheitsgehalts, der durch grafische Animation verstärkt wird. Simulation ermittelt keine Problemlösung, sondern zeigt lediglich die Konsequenzen von Entscheidungsalternativen auf; sie hat eher Prognosefunktion als Problemlösungsfunktion.

Simulation besitzt im mathematischen Sinne keine zum Optimum führende Suchstrategie. Im Vordergrund stehen Heuristiken für die Auswahl der untersuchten Alternativen.

Wirtschaftlichkeitsmodelle Da Ergebnisse von Entwicklungsprojekten im Sinne neuer oder wesentliche veränderter Informationssysteme nicht nur Veränderungen an einzelnen betrieblichen Funktionen (z. B. für bestimmte Aufgaben und nur an bestimmten Arbeitsplätzen), sondern an ganzen Prozessketten (im Sinne von Geschäftsprozessen) oder an wesentlichen Teilen davon hervorrufen, muss die Analyse der Wirtschaftlichkeit funktions- und arbeitsplatzübergreifend bis unternehmensweit angelegt werden. Zudem muss bedacht werden, dass erfahrungsgemäß das Nutzenpotenzial nicht bei einzelnen Tätigkeiten der Prozesskette liegt, sondern zwischen ihnen und zu anderen Prozessketten, an den Schnittstellen also. Mehrstufige Wirtschaftlichkeitsmodelle berücksichtigen diese Einflüsse. Ein Wirtschaftlichkeitsmodell, das einen Stufen- oder Ebenenansatz verwendet, kann als Referenzmodell dienen. Beispielsweise werden in einem vierstufigen Wirtschaftlichkeitsmodell folgende Wirtschaftlichkeitsstufen oder Wirtschaftlichkeitsebenen unterschieden (nach Reichwald):    

W1: Isolierte technologiebezogene Wirtschaftlichkeit, mit der Kosten und Nutzen erfasst werden, die unmittelbar dem Technologieeinsatz zuzurechnen sind. W2: Subsystembezogene Wirtschaftlichkeit, mit der die vom Einsatzkonzept und anderen situativen Bedingungen abhängigen Kosten und der Nutzen im Hinblick auf die Arbeitsabläufe erfasst werden. W3: Gesamtorganisationale Wirtschaftlichkeit, mit der die Kosten zur Aufrechterhaltung der Anpassungsfähigkeit und Funktionsstabilität sowie kostenrelevante Humanaspekte und der damit bewirkte Nutzen erfasst werden. W4: Gesellschaftliche Wirtschaftlichkeit, mit der negative Auswirkungen (als Kosten) und positive Auswirkungen (als Nutzen) auf die Unternehmensumwelt erfasst werden.

Bei der Nutzenmessung wird zwischen quantitativen und qualitativen Ausprägungen unterschieden. Bei Verwendung der vier genannten Wirtschaftlichkeitsebenen sowie der Kosten und den beiden Nutzenkategorien ergibt sich eine 12-Felder-Matrix für die Beurteilung der Wirtschaftlichkeit. Verdichtungen und Saldierungen sollen vermieden werden, um die Wirtschaftlichkeit stufenweise sichtbar zu machen (vgl. Abbildung WIRTA-1). Durch die Verwendung des Controlling-Ansatzes (vgl. Lerneinheit CONTR) wird aus der „Ein-ZeitpunktBetrachtung“ der Wirtschaftlichkeitsanalyse ein Prozess, der einen Abschnitt im Regelkreis des Controllings darstellt. Beispielsweise kann für ein Vertriebsinformationssystem ein Regelkreis aufgebaut werden, wenn der Vertrieb zusätzliche IT-Kosten über die Erhöhung der Vertriebsziele (z. B. Erhöhung des Deckungsbeitrags) direkt kompensieren kann.

Wirtschaftlichkeitsanalyse (WIRTA)

Wirtschaftlichkeitsebenen

371

Kosten

quant. Nutzen

qual. Nutzen

W1 : Arbeitsplatz W2 : Geschäftsprozess W3 : Unternehmen W4 : Gesellschaft Abb. WIRTA-1: Wirtschaftlichkeitsmodell (Quelle: Reichwald)

Forschungsbefunde Mertens stellt fest, dass Ökonomie in der Marktwirtschaft für die Unternehmung Rentabilitätsmaximierung bedeutet und dass sich Wirtschaftlichkeits- und Rentabilitätsmaximierung nicht decken. „Ingenieurziele“ (z. B. Kostenminimierung, Maximierung der Kapazitätsauslastung) seien theoretisch nur haltbar, wenn zahlreiche Ceteris-Paribus-Klauseln gelten; bei Verwendung dieser Klauseln in der Wirtschaftsinformatik sei große Vorsicht geboten. Heinrich/Ambichl haben am Beispiel von Client-Server-Architekturen die Entwicklung und Verwendung von Simulationsmodellen zur Ermittlung der Vorteilhaftigkeit der Alternativen (hier Datenbank-Server vs. File-Server) im Hinblick auf das Ziel Leistung gezeigt. Mit dem Ergebnis dieser Simulationsstudie wurde die Lösung eines Entscheidungsproblems des Auftraggebers unterstützt und die Anwendbarkeit der Simulation als Methode der Wirtschaftlichkeitsanalyse nachgewiesen. Das Untersuchungsdesign kann Referenzmodell für andere Simulationsstudien zur Ermittlung der Wirtschaftlichkeit von IT-Betriebsmitteln sein. Högler schlägt vor, die relevanten, projektspezifischen Erfolgsfaktoren in die Wirtschaftlichkeitsanalyse einzubeziehen und bezeichnet dieses Vorgehen als holistische Wirtschaftlichkeitsanalyse, die „…aufgrund ihrer Modularität in ihrer Komplexität an die Bedürfnisse des Unternehmens angepasst werden kann.“ (2) Die Identifikation der Erfolgsfaktoren soll „automatisch“ erfolgen. Die als Framework vorliegende Dokumentation des Vorgehens lässt eine Beurteilung seiner Praxistauglichkeit nicht zu.

Aus der Praxis In der Praxis wird häufig die Frage nach dem Wertbeitrag der IT gestellt, also die Frage; welchen Beitrag die IT zum Unternehmenserfolg leistet, und das IT-Management wird aufgefordert, diese Frage zu beantworten. Dies kann nur so verstanden werden, dass nach dem Beitrag gefragt wird, den das Ergebnis einer bestimmten IT-Investition (z. B. eines Entwicklungsprojekts oder Beschaffungsprojekts) zum Unternehmenserfolg leistet. Dieser Beitrag zum Unternehmenswert ist als die Nutzen-Kosten-Differenz einer jeden IT-Investition ex post mit einer Wirtschaftlichkeitsanalyse ausreichend genau zu ermitteln. Die Frage, die sich auf „die IT im Unternehmen insgesamt“ bezieht, ist nur rhetorischer Art; sie ist nicht gar nicht zu beantworten. IT-Manager sollten mit der Gegenfrage reagieren: Wer fragt eigentlich

372

Methoden des strategischen Informationsmanagements

nach dem Wertbeitrag des Marketings oder der Logistik? (Ergebnis der Erörterung der Frage „IT-Manager – Dienstleister oder Innovator?“ in einem Workshop des ipo.) Nach Kossow, Projektleiter und Seniorberater der PROJECT CONSULT Unternehmensberatung Kampffmeyer GmbH, Hamburg, eine produkt- und herstellerunabhängige Beratungsgesellschaft für Informationsmanagement (IM), ist TCO „…ein anerkanntes Abrechnungsverfahren, um Verbrauchern und Unternehmen dabei zu helfen, alle anfallenden Kosten von Investitionsgütern (insbesondere in der IT) … abzuschätzen. Dabei werden nicht nur die Anschaffungskosten berücksichtigt, sondern alle Aspekte der späteren Nutzung … der betreffenden Komponenten. Somit können bekannte Kostentreiber oder auch versteckte Kosten möglicherweise bereits im Vorfeld einer Investitionsentscheidung identifiziert werden.“ Aufgabenverweise Wirtschaftlichkeitsanalysen erfordern die meisten strategischen und administrativen IM-Aufgaben. Kontrollfragen 1. Wie sollten die Lebenszykluskosten für eine Wirtschaftlichkeitsanalyse gegliedert werden? 2. Wie erfolgt die Analyse der Beziehungszusammenhänge zwischen Kosten und Nutzen? 3. Durch welche Merkmale unterscheiden sich Wirtschaftlichkeitsanalysen von Wirtschaftlichkeitsrechnungen? 4. Unter welchen Voraussetzungen können Entwicklungskosten aktiviert werden? 5. Was leistet ein Wirtschaftlichkeitsmodell mehr als eine typische Wirtschaftlichkeitsanalyse? Quellen Heinrich, L. J. / Ambichl, E.: Ergebnisse einer Leistungsbewertung von Client-Server-Architekturen. In: Krcmar, H. (Hrsg.): Client-Server-Architekturen. Halbergmoos 1993, 55–101 Heinrich, L. J. / Heinzl, A. / Riedl, R.: Wirtschaftsinformatik – Einführung und Grundlegung. 4. A., Berlin/Heidelberg 2011 Högler, T.: Framework für eine holistische Wirtschaftlichkeitsanalyse mobiler Systeme. Dissertationsprojekt, Institut AIFB, Universität Karlsruhe. http://gi-mms.de/mms2006/kurzbeitraege/hoegler.pdf; Abruf 3.11.2008 ipo: Stellenbild des Informationsmanagers. http://www.ipo.jku.at/index.php?menuid=103; Abruf 19.5.2008 Kossow, R.: http://www.erpmanager.de/magazin/artikel_1339_tco_total_cost_ownership_wirtschaftlichkeit.html; Abruf 20.5.2011 Mertens, P.: Operiert die Wirtschaftsinformatik mit falschen Unternehmenszielen? - 15 Thesen. In: Becker, J. et al. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie. Wiesbaden 1999, 379–392 Ott, H. J.: Wirtschaftlichkeitsanalyse von EDV-Investitionen mit dem WARS-Modell am Beispiel der Einführung von CASE. In: WIRTSCHAFTSINFORMATIK 6/1993, 522–531 Pirker, S.: Bilanzierung von Software. Wien 1992 Reichwald, R.: Ein mehrstufiger Bewertungsansatz zur wirtschaftlichen Leistungsbeurteilung der Bürokommunikation. In: Hoyer, R. H. / Kölzer, G. (Hrsg.): Wirtschaftlichkeitsrechnungen im Bürobereich. Berlin 1987, 23–33 Vertiefungsliteratur Blohm, H. / Lüder, K. / Schaefer, C.: Investition – Schwachstellenanalyse des Investitionsbereichs und Investitionsrechnung. 9. A., München 2006 Faisst, U. / Prokein, O. / Wegemann, N.: Ein Modell zur dynamischen Investitionsrechnung von IT-Sicherheitsmaßnahmen. In: Zeitschrift für Betriebswirtschaft 5/2007, 511–538 Lercher, H. J.: Wertanalyse an Informationssystemen. Wiesbaden 2000 Pauls, W.: Wirtschaftlichkeitsanalyse analytischer Informationssysteme. Saarbrücken 2007 Sprenger, J. / Klages, M. / Breitner, M. H.: Wirtschaftlichkeitsanalyse für die Auswahl, die Migration und den Betrieb eines Campus-Management-Systems. In: WIRTSCHAFTSINFORMATIK 4/2010, 211–223 Zarnekow, R. / Scheeg, J. / Brenner, W.: Untersuchung der Lebenszykluskosten von IT-Anwendungen. In: WIRTSCHAFTSINFORMATIK 3/2004, 181–187 Normen EN 1325-1: Value Management, Wertanalyse, Funktionenanalyse Wörterbuch, Teil 1: Wertanalyse und Funktionenanalyse. ÖNORM A 6757: Wertanalyse-Management: Planung, Durchführung und Controlling der Wertanalyse.

Nutzwertanalyse (NUTZW) Lernziele Sie kennen den Unterschied zwischen Nutzwertmodell und Nutzwertanalyse. Sie können die Komponenten des Nutzwertmodells und damit die Arbeitsschritte der Nutzwertanalyse erläutern. Sie sind in der die Lage, das Nutzwertmodell an eine konkrete Entscheidungssituation anzupassen, um aus einer Menge von Handlungsalternativen die optimale Alternative zu bestimmen. Sie kennen die Wahlprobleme, die dabei auftreten, und Sie können diese lösen. Sie kennen weiterführende Varianten der Nutzwertanalyse.

Definitionen und Abkürzungen Entscheidungsregel (decision rule) = Vorschrift, die für eine Entscheidungssituation angibt, wie eine Menge von Zielwerten für eine Menge von Handlungsalternativen zum Gesamtnutzen aggregiert wird. Synonym: Aggregationsfunktion. Kriteriengewicht (criterion weight) = relative Bedeutung der Kriterien in einer bestimmten Evaluierungssituation. Kriterium (criterion) = Eigenschaft eines Objekts, dessen Ausmaß durch Messung, Schätzung oder Prognose ermittelt wird. Synonym: Zielkriterium. Modell (model) = vereinfachte Abbildung eines Ausschnitts der Wirklichkeit oder Konstruktion eines Vorbilds für die Wirklichkeit. Nutzen (benefit) = Wert einer Handlungsalternative zur Befriedigung eines definierten Bedarfs. Synonym: Nutzwert. Nutzwert (value of benefit) = Synonym für Nutzen. Präferenz (preference) = Vorziehenswürdigkeit eines Objekts (z. B. einer Alternative, eines Kriteriums) gegenüber anderen Objekten. Präferenzordnung (preference order) = Ordnung von Objekten (z. B. Alternativen, Kriterien) aufgrund bestehender Präferenzen. Zerlegung (decomposition) = systematisches, zielorientiertes Verändern eines Objekts so, dass Teilobjekte entstehen, die bzgl. der verfolgten Ziele möglichst homogen sind. Ziel (objective) = angestrebter Endpunkt eines menschlichen Handlungsprozesses. Zielertrag (goal profit) = Ausmaß der Zielerreichung bezüglich eines Zielkriteriums. Synonym: Zielerreichungsgrad. Zielertragsmatrix (goal profit matrix) = Matrix, die in den Zeilen die Alternativen und in den Spalten die Kriterien enthält; die Elemente der Matrix sind die Zielerträge. Zielhierarchie (goal hierarchy) = stufenmäßig aufgebaute Ordnung der Elemente eines Zielsystems in Form einer Rangordnung mit von oben nach unten abnehmender Bedeutung. Zielsystem (goal system) = geordnete Menge von Zielen, zwischen denen Beziehungen bestehen, die idealtypisch gesehen komplementär, konfliktär oder indifferent sind. Zielwert (goal value) = Abbildung eines Zielertrags auf einer nominalen, ordinalen oder kardinalen Skala (Skalierung). Synonym: Teilnutzen. Zielwertmatrix (goal value matrix) = Matrix, die in den Zeilen die Alternativen und in den Spalten die Zielkriterien enthält; die Elemente der Matrix sind die Zielwerte.

374

Methoden des strategischen Informationsmanagements

Zweck der Nutzwertanalyse

Zustandsanalyse

Informationsgewinnung (Systemanalyse)

Problemdefinition (Zielbildung) Konzeptentwurf (Systemsynthese) Konzeptanalyse (Systemanalyse)

Informationsverarbeitung (Systemauswahl)

Informationsauswertung (Systemrealisierung)

Bewertung (Nutzwertanalyse) Auswahlentscheidung Ausarbeitung (Entwicklungsplanung) Ausführungsplanung

Planungsorganisation (Systemmanagement)

In der Problemlösungsstufe Bewertung des systemtechnischen Planungsansatzes (vgl. Abbildung NUTZW-1), der für die methodenorientierte Lösung von IM-Aufgaben grundlegend ist, besteht häufig folgende Situation: Aus einer Menge von Handlungsalternativen soll die optimale Alternative unter Berücksichtigung mehrerer Ziele (mehrdimensionales Zielsystem) bestimmt werden. Um eine Auswahlentscheidung treffen zu können, müssen die Handlungsalternativen geordnet werden. Als Kriterium für diese Ordnung wird der Nutzwert verwendet. Die Handlungsalternativen werden unter Beachtung der Präferenzen der Entscheidungsträger verglichen und die optimale (i. d. R. die nutzenmaximale) Alternative wird gewählt.

Abb. NUTZW-1: Problemlösungsstufen im systemtechnischen Planungsprozess (Quelle: Zangemeister)

Bewertungsprobleme dieser Art werden mit der als Nutzwertanalyse bezeichneten systemtechnischen Vorgehensweise bearbeitet. Sie ist keine Entscheidungsrechnung (wie die in Lerneinheit WIRTA dargestellten Methoden der Wirtschaftlichkeitsrechnung), sondern ein Modell für die systematische und nachvollziehbare Erarbeitung von Informationen zur Entscheidungsunterstützung. Das Modell kann an die Bedingungen nahezu beliebiger Entscheidungssituationen angepasst werden, so dass die Nutzwertanalyse in nahezu allen komplexen Entscheidungssituationen des Informationsmanagements als Methode zur Informationsgewinnung verwendet werden kann. Das Nutzwertmodell hat also die Funktion eines Referenzmodells. Abbildung NUTZW-2 zeigt die Logik der Nutzwertanalyse im Überblick mit einer in vier Arbeitsschritte gegliederten Vorgehensweise (in Klammern das Ergebnis des Arbeitsschrittes), nämlich Festlegen des Zielsystems, Ermitteln der Zielerträge (Zielertragsmatrix), Ermitteln der Zielwerte (Zielwertmatrix) und Durchführen der Wertsynthese (Nutzwertmatrix).

Nutzwertanalyse (NUTZW)

375

Festlegen des Zielsystems

Kriterien k1

k2 . kj . km

e11 e21 . ei1 . en1

e12 e22 . ei2 . en2

Alternativen A1 A2 . Ai . An

e1j e2j . eij . enj

e1m e2m . eim . enm

Ermitteln der Zielerträge

Zielertragsmatrix eij 

Bewertung Kriterien -gewichte Alternativen A1 A2 . Ai . An

g1

g2 . gj . gm

Ermitteln der Zielwerte

n 11 n 21 . n i1 . n n1

n 12 n 22 . n i2 . n n2

Zielwertmatrix n ij 

n 1j n 2j . n ij . n nj

n 1m n 2m . n im . n nm

Wertsynthese von m+1 Präferenzordnungen mit einer Entscheidungsregel

Alternativen

Nutzwerte

A1 A2 . Ai . An

N1 N2 . Ni . Nn

Durchführen der Wertsynthese Nutzwertmatrix Ni 

Abb. NUTZW-2: Logik der Nutzwertanalyse (Quelle: nach Zangemeister)

376

Methoden des strategischen Informationsmanagements

Vorgehensweise der Nutzwertanalyse Im Folgenden werden die vier Komponenten des Nutzwertmodells als eine Folge von vier Arbeitsschritten der Nutzwertanalyse erläutert. Das Ermitteln der Zielwerte (dritter Arbeitsschritt) wird in die Teilschritte Auswählen des Skalenniveaus und Bestimmen der Kriteriengewichte zerlegt.

Festlegen des Zielsystems Im ersten Arbeitsschritt wird das situationsrelevante Zielsystem festgelegt, das sich aus der Entscheidungssituation und den Präferenzen der Entscheidungsträger ergibt. Eine allgemein geltende Vorgehensweise zum Festlegen des Zielsystems gibt es nicht, so dass es eher Kunst als Wissenschaft ist, zu einem brauchbaren Arbeitsergebnis zu kommen. Wünschenswerte, teilweise konkurrierende Eigenschaften eines Zielsystems sind:    

Vollständigkeit: Alle entscheidungsrelevanten Merkmale der Alternativen werden im Zielsystem erfasst. Operationalität: Für alle Ziele können geeignete Zielkriterien formuliert werden. Zerlegbarkeit: Die Ziele können top-down durch Teilziele ersetzt bzw. können die Teilziele bottom-up zu Oberzielen zusammengefasst werden. Redundanzfreiheit: Jeder Zielertrag wird nur einmal erfasst.

Empfehlenswert ist eine hierarchische Vorgehensweise, bei der Ziele top-down in Teilziele zerlegt bzw. Teilziele bottom-up zu einem Oberziel zusammengefasst werden. Dem Topdown-Ansatz folgend, ist der oberste Knoten des Zielsystems Ausgangspunkt der Zerlegung (allgemein als optimale Alternative bezeichnet). Dieser Knoten wird in mehrere, möglichst überschneidungsfreie Teilmengen zerlegt. Die so auf der zweiten Hierarchieebene des Zielsystems entstehenden Knoten werden wiederum in mehrere, möglichst überschneidungsfreie Teilmengen zerlegt usw. Jedes Zielsystem kann durch Zerlegung beliebig tief gegliedert werden, wobei mit zunehmender Zerlegung die Zielanzahl und damit die Operationalität der Ziele zunimmt. Bedingt durch die zunehmende Zielanzahl steigt der Aufwand für die Ermittlung der Zielerträge. Der Zerlegungsprozess sollte daher abgebrochen werden, wenn die Teilziele eine Operationalität erreicht haben, die sie als Zielkriterien geeignet erscheinen lassen. Als Zielkriterien geeignet sind Teilziele dann, wenn einer Handlungsalternative ein messbarer Zielertrag bezüglich des betrachteten Zielkriteriums eindeutig zugeordnet werden kann; wenn nicht, muss der Zerlegungsprozess fortgesetzt werden. Wird beim Bestimmen des Zielsystems eine Vorgehensweise nach dem Bottom-up-Ansatz gewählt, dann sind Einzelbeobachtungen über entscheidungsrelevante Attribute der Handlungsalternativen Ausgangspunkt folgender Aggregation:  

Zusammengehörige Einzelbeobachtungen werden so zusammengefasst, dass überschneidungsfreie Teilziele formuliert werden können. Mehrere zusammengehörige Teilziele werden zu einem Oberziel zusammengefasst.

Nutzwertanalyse (NUTZW)

377

Die Aggregation wird so lange fortgesetzt, bis man bei einem gemeinsamen Knotenziel für alle Einzelbeobachtungen, die Ausgangspunkt der Aggregation waren, angelangt ist.

Ermitteln der Zielerträge Im zweiten Arbeitsschritt werden die Zielerträge je Zielkriterium und je Handlungsalternative ermittelt. Dabei handelt es sich primär um einen Prozess der Datenerhebung, dessen Art und organisatorische Gestaltung vom betrachteten Zielkriterium und von den konkreten Handlungsalternativen abhängen. Dieser Prozess kann aufwendige Ermittlungsverfahren erfordern (wie in Lerneinheit EVALU gezeigt wird). Ergebnis des zweiten Arbeitsschritts ist die Zielertragsmatrix, in der jeder Zielertrag eij durch seinen alphanumerischen Wert die erwartete Konsequenz der Handlungsalternative Ai bezüglich des Zielkriteriums kj abbildet.

Ermitteln der Zielwerte Im dritten Arbeitsschritt werden die Zielerträge durch Skalieren und durch Gewichten der Zielkriterien in Zielwerte überführt. Ein Zielwert nij bildet durch seinen numerischen Wert für die Handlungsalternative Ai den Teilnutzen des Zielkriteriums kj ab. Ergebnis des dritten Arbeitsschritts ist die Zielwertmatrix. Skalieren heißt also, den Zielerträgen eij Zahlen zuordnen, um die Zielerträge, die in der Regel in verschiedenen Dimensionen (z. B. Anzahl, Geldeinheiten, Zeiteinheiten) gemessen wurden, vergleichbar zu machen. Dazu ist zunächst in Abhängigkeit von der Entscheidungssituation das Skalenniveau festzulegen. Gewichten heißt, eine Präferenzordnung der Zielkriterien herzustellen.

Auswählen des Skalenniveaus Zur Wahl stehen nominale, ordinale und kardinale Skala. 



Nominale Skala: Die Bewertung erfolgt durch kategoriale Urteile, die angeben, in welche von zwei oder mehreren Wertkategorien eine Handlungsalternative in Bezug auf ein Kriterium einzuordnen ist. Bei zwei Wertkategorien wird also festgestellt, ob eine Handlungsalternative ein vorgegebenes Zielertragsniveau (auch als Befriedigungsniveau bezeichnet) erfüllt oder nicht erfüllt (z. B. auch durch ja / nein oder besser / schlechter ausgedrückt). Je nach Ergebnis wird die betrachtete Handlungsalternative der Wertkategorie „erfüllt“ oder der Wertkategorie „nicht erfüllt“ zugeordnet. Dem Vorteil der leichten Handhabung der nominalen Skala stehen ihre Nachteile des eingeschränkten Informationsgehalts und der mangelnden Entscheidungsrelevanz durch häufig willkürliche, jedenfalls nicht immer nachvollziehbare Festlegung des Befriedigungsniveaus gegenüber. Ordinale Skala: Die Bewertung erfolgt durch Herstellen einer Rangreihe n-ter Ordnung bei n Handlungsalternativen (Rangordnung). Das Herstellen der Rangordnung erfolgt entweder durch Anwendung des Rangordnungsverfahrens, bei dem die n Alternativen gleichzeitig zur Bewertung vorgegeben werden, oder durch Anwendung des vollständigen Paarvergleichs, bei dem jeweils zwei Alternativen zur Bewertung vorgegeben werden. Die Rangordnung gibt lediglich an, ob der Zielwert einer Handlungsalternative kleiner, gleich oder größer ist als der Zielwert einer anderen Handlungsalternative. Die absolute Differenz zwischen den Zielwerten bleibt unberücksichtigt. Das einzelne Bewertungsergebnis ist vom angestrebten Zielertragsniveau unabhängig. Insofern stellen

378



Methoden des strategischen Informationsmanagements

ordinale Urteile geringere Anforderungen an das Urteilsvermögen und sind im Hinblick auf ihre individuelle Vergleichbarkeit gehaltvoller als nominale Urteile. Kardinale Skala: Die Bewertung erfolgt durch quantitative Messung. Hinsichtlich des möglichen Skalenniveaus ist der Informationsgehalt kardinal skalierter Urteile am höchsten, doch gibt es in der Regel erhebliche praktische Messprobleme, weil geeignete Messinstrumente nicht zur Verfügung stehen. Varianten der kardinalen Skala sind Intervallskala und Verhältnisskala. Die Intervallskala (auch als intervallfixierte Skala bezeichnet) besitzt die Eigenschaften einer nominalen Skala und einer ordinalen Skala; darüber hinaus repräsentieren gleiche Abstände auf der Intervallskala gleiche Unterschiede der gemessenen Eigenschaft, die Intervalle können addiert und subtrahiert werden. Eine Verhältnisskala (auch als Ratioskala bezeichnet) besitzt zusätzlich zu den Eigenschaften der bisher genannten Skalen einen absoluten Nullpunkt (absolut fixierte Skala) oder einen natürlichen Nullpunkt, der eine empirische Bedeutung hat (nullpunktfixierte Skala); auf dieser Skala sind alle mathematischen Operationen zulässig.

Ein Vergleich der Skalentypen bezüglich ihrer Eigenschaften Aufwand für die Datenerhebung bzw. Messaufwand einerseits und Informationsgehalt andererseits verdeutlicht die Notwendigkeit einer klaren Formulierung der Entscheidungssituation, für die ein Analysemodell entwickelt werden soll.

Bestimmen der Kriteriengewichte Da die Zielkriterien für die Entscheidungsträger in der Regel eine unterschiedlich große Bedeutung haben, werden sie gewichtet, das heißt, es wird eine Präferenzordnung der Zielkriterien hergestellt. Die Präferenzordnung bewirkt, dass die Zielwerte (Teilnutzen) bei der anschließenden Wertsynthese mit unterschiedlichem Gewicht in den Gesamtnutzen eingehen. Zur Herstellung der Präferenzordnung können verschiedene Verfahren verwendet werden. Nachfolgend wird die als Paarvergleich bezeichnete Methode (auch als Methode der paarweisen oder Methode der sukzessiven Vergleiche bezeichnet) anhand ihrer wichtigsten Arbeitsschritte erläutert. Die praktische Anwendbarkeit dieser Methode hängt von der Anzahl der Zielkriterien ab; sie wird mit maximal sechs angegeben. Mächtigere Zielmengen müssen in Teilmengen zerlegt werden, und es wird dann innerhalb jeder Teilmenge wie folgt vorgegangen: 1. 2. 3.

Herstellen einer Rangfolge der Zielkriterien (Präferenzrelation) entsprechend ihrer relativen Bedeutung; jedes Zielkriterium erhält eine Rangziffer. Bestimmen vorläufiger Kriteriengewichte, wobei das wichtigste Zielkriterium den Gewichtungsfaktor 1,0 erhält; die Gewichtungsfaktoren der anderen Zielkriterien müssen mit zunehmender Rangziffer abnehmen. Der endgültige Gewichtungsfaktor für das bedeutsamste Zielkriterium wird ermittelt, indem zunächst abgeschätzt wird, ob dieser größer, gleich oder kleiner als die Summe der restlichen Gewichtungsfaktoren sein soll; es wird eine entsprechende Bedingung formuliert. Wird diese Bedingung von den vorläufig festgelegten Gewichtungsfaktoren erfüllt, dann wird der Gewichtungsfaktor für das bedeutsamste Zielkriterium mit 1,0 endgültig fixiert. Andernfalls sind entweder der vorläufige Gewichtungsfaktor des bedeutsamsten Zielkriteriums oder die restlichen Gewichtungsfaktoren unter Einhaltung der Präferenzrelation so zu modifizieren, dass die formulierte Bedingung erfüllt wird.

Nutzwertanalyse (NUTZW)

4.

5.

379

Bei der Festlegung der endgültigen Gewichtungsfaktoren für die übrigen Zielkriterien wird entsprechend ihrer Rangfolge prinzipiell so vorgegangen, wie dies für das bedeutsamste Zielkriterium dargelegt wurde. Der nächste, endgültig festzulegende Gewichtungsfaktor wird stets mit der Summe der restlichen, noch nicht festgelegten Gewichtungsfaktoren verglichen. Die ermittelten Gewichte werden auf 1 oder auf 100 normiert.

Zur weiteren Erläuterung diene folgendes Beispiel: Zielkriterien sind k1 = Benutzbarkeit, k2 = Funktionalität, k3 = Wartbarkeit, k4 = Anpassbarkeit und k5 = Flexibilität. 1.

k3 > k1 > k5 > k2 > k4

2.

k3 = 1,0; k1 = 0,6; k5 = 0,5; k2 = 0,2; k4 = 0,1

3.

Beispiel für k3, dessen Gewichtungsfaktor größer als die Summe der restlichen Gewichtungsfaktoren sein soll: 1,0>0,6 + 0,5 + 0,2 + 0,1 gilt nicht, so dass k1, k5, k2, k4 reduziert werden wie folgt: 1,0>0,4 + 0,3 + 0,1 + 0,05 gilt und es wird k3 = 1,0 fixiert.

4.

Beispiel für k1, dessen Gewichtungsfaktor größer als die Summe der restlichen Gewichtungsfaktoren sein soll: 0,4>0,3 + 0,1 + 0,05 gilt nicht, so dass k5, k2, k4 reduziert werden wie folgt: 0,4>0,2 + 0,1 + 0,05 gilt und es wird k1 = 0,4 fixiert. Beispiel für k5, dessen Gewichtungsfaktor größer als die Summe der restlichen Gewichtungsfaktoren sein soll: 0,2>0,1 + 0,05 gilt, so dass k5 = 0,2 fixiert wird. Beispiel für k2: 0,1>0,05 gilt, so dass k2 = 0,1 fixiert wird und k4 = 0,05 ist.

5.

Es ist k3 = 1,0; k1 = 0,4; k5 = 0,2; k2 = 0,1; k4 = 0,05; die Summe der Gewichte beträgt 1,75. Für die Normierung gilt: Summe der Gewichte = 1 bzw. = 100, das heißt: k3 = 1,0/1,75; k1 = 0,4/1,75; k5 = 0,2/1,75; k2 = 0,1/1,75; k4 = 0,05/1,75. Der Gewichtungsvektor lautet: (0,57; 0,23; 0,11; 0,06; 0,03).

Ergebnis ist gk1 = Benutzbarkeit 57 %, gk2 = Funktionalität 23 %, gk3 = Wartbarkeit 11 %, gk4 = Anpassbarkeit 6 % und gk5 = Flexibilität 3 %.

Durchführen der Wertsynthese Im vierten Arbeitsschritt werden die Teilnutzen je Handlungsalternative mit Hilfe einer Entscheidungsregel zum Gesamtnutzen aggregiert. Die Auswahl der Entscheidungsregel hängt vom verwendeten Skalenniveau ab, ob also nominal, ordinal oder kardinal skalierte Zielwerte vorliegen. Entscheidungsregeln der Wertsynthese bei nominal skalierten Zielwerten sind: 



Regel der befriedigenden Lösung: Eine Handlungsalternative ist dann optimal, wenn sie in allen Wertdimensionen befriedigende Zielerträge liefert. Wegen der häufig willkürlichen Festlegung des Befriedigungsniveaus ist diese Entscheidungsregel nur für eine Vor- oder Grobauswahl geeignet. Die Regel wird auch als auch als Simon-Regel bezeichnet. Regel der Befriedigung der großen Zahl: Eine Handlungsalternative ist dann optimal, wenn die Anzahl ihrer befriedigenden Wertdimensionen größer ist als die Anzahl der befriedigenden Wertdimensionen aller anderen Handlungsalternativen. Diese Entscheidungsregel bedingt die gegenseitige Verrechnung der von einer Handlungsalternative er-

380



Methoden des strategischen Informationsmanagements

reichten Bewertungen. Die Vorgehensweise impliziert kardinale Eigenschaften der nominal formulierten Zielwerte und ist daher spekulativ. Regel der lexikografischen Ordnung: Eine Handlungsalternative ist dann optimal, wenn sie bezüglich des wichtigsten Kriteriums von allen Handlungsalternativen am höchsten bewertet wird. Sind mehrere Zielwerte bezüglich des wichtigsten Kriteriums gleich, so entscheidet das zweitwichtigste Kriterium über die Vorzugswürdigkeit usw. Voraussetzung für die lexikografische Ordnung ist, dass das nominale Urteilsschema aus mindestens drei Klassen besteht. Diese Entscheidungsregel eignet sich besonders zur rationalen Ausschöpfung des Informationsgehalts einer nominal skalierten Zielwertmatrix.

Entscheidungsregeln der Wertsynthese bei ordinal skalierten Zielwerten sind:  



Majoritätsregel: Eine Handlungsalternative ist dann optimal, wenn sie allen anderen Handlungsalternativen in mehr Wertdimensionen überlegen als unterlegen ist. Vorzugs-/Häufigkeitsregel: Eine Handlungsalternative ist dann optimal, wenn sie allen anderen Handlungsalternativen in ihren Wertdimensionen häufiger vorgezogen wird. Varianten dieser Entscheidungsregel sind Copeland-Regel, Austin-Slight-Regel und Thurstone-Regel. Rangordnungssummenregel: Eine Handlungsalternative ist dann optimal, wenn die Summe der ihr in den Wertdimensionen zugeordneten Rangplätze kleiner ist als die vergleichbare Summe aller anderen Handlungsalternativen. Diese Entscheidungsregel ist sehr operational und wird häufig angewendet. Abbildung NUTZW-3 zeigt ihre formale Struktur. Sie impliziert die Annahme, dass die Nutzendistanzen zwischen benachbarten Rängen gleich groß sind (was in der Praxis allerdings nur selten der Fall ist). m

Ni 

 j1

n ij  g j

Ni Nutzwert der Alternative i n ij Nutzwert der Alternative i bezüglich Kriterium j gj Gewicht des Kriteriums j

Abb. NUTZW-3: Formale Struktur Rangordnungssummenregel

Entscheidungsregeln der Wertsynthese bei kardinal skalierten Zielwerten sind Additionsregel (bei Intervallskalen und bei Verhältnisskalen), Multiplikationsregel (bei Verhältnisskalen), verschiedene spieltheoretisch begründete Entscheidungsregeln (bei Verhältnisskalen, wie Maximin-Regel, Maximax-Regel und Pessimismus/Optimismus-Regel). Die größte praktische Bedeutung hat die Additionsregel, bei der – wie aus der Bezeichnung hervor geht – die gewichteten Zielwerte addiert werden, was auf Grund des Charakters von Intervall- und Verhältnisskala problemlos möglich ist.

Ergebnis der Nutzwertanalyse Schließlich werden die Handlungsalternativen in eine widerspruchsfreie und vollständige Ordnung gebracht, die sich aus dem Vergleich der Nutzwerte der Handlungsalternativen ergibt. Die optimale Handlungsalternative ist die, deren Nutzwert maximal ist bzw. (wie bei der Rangordnungssummenregel) minimal ist (vgl. Abbildung NUTZW-4). Ergebnis der Nutzwertanalyse ist die Ordnung der gegebenen Menge von Handlungsalternativen nach dem Nutzwert der einzelnen Handlungsalternativen, also nach ihrem Gesamtnutzen.

Nutzwertanalyse (NUTZW)

381

Aopt.= Ai | Ni  max! Aopt.= Ai | Ni  min! Abb. NUTZW-4: Zielfunktion optimale Handlungsalternative

Weiterführende Varianten der Nutzwertanalyse Die Ergebnisse der Nutzwertanalyse können mit den folgenden Methoden weiter untersucht werden: Empfindlichkeitsanalyse, Kosten-Nutzen-Analyse und Berücksichtigung der Prognoseungewissheit. 





Mit der Empfindlichkeitsanalyse (auch als Sensitivitätsanalyse bezeichnet) wird untersucht, welche Auswirkung die Änderung der Parameter Zielertrag, Skalenniveau, Kriteriengewicht und Entscheidungsregel auf den ermittelten Nutzwert haben. Je weniger die Ordnung der Handlungsalternativen dadurch verändert wird, desto geringer ist das Entscheidungsrisiko. Gesucht wird beispielsweise nach den Werten der Parameter, bei denen die zunächst ausgewählte Alternative nicht mehr optimal ist (kritische Parameterwerte). Nollau/Gottfried nennen drei Situationen, in denen die Verwendung der Empfindlichkeitsanalyse „von Vorteil“ ist (93): (1) Wenn Unsicherheit über die Richtigkeit und Genauigkeit der Annahmen besteht, (2) wenn erhebliche Meinungsverschiedenheiten bei den Entscheidungsträgern bzgl. des Zielsystems und der Gewichtungsfaktoren bestehen, (3) wenn die Nutzwerte der Alternativen nahe zusammenliegen. Obwohl es möglich ist, konkurrierende Ziele in die Vorgehensweise der Nutzwertanalyse einzubringen (insbesondere konkurrierende Ziele wie Kosten und Nutzen), wird bei der Kosten-Nutzen-Analyse empfohlen, die Kosten einer Handlungsalternative zunächst nicht in das Zielsystem aufzunehmen. Nach der Ermittlung des Nutzwerts wird dieser mit dem Kostenwert in Beziehung gesetzt. Die Entscheidungsregel lautet: Eine Handlungsalternative ist dann optimal, wenn ihr Kosten-Nutzen-Verhältnis das kleinste aller Handlungsalternativen ist. Die Anwendung der Kosten-Nutzen-Analyse ist nur bei kardinal skalierten Zielwerten möglich. Die Ungewissheit bei der Ermittlung zukünftiger Zielerträge kann bei der Nutzwertanalyse dadurch berücksichtigt werden, dass die eindeutigen, diskreten Zielerträge durch stetige Zielertragswahrscheinlichkeiten ersetzt werden. Analyseergebnis ist dann die Ordnung der Handlungsalternativen nach Nutzwert-Wahrscheinlichkeitsverteilungen.

Scholles (14) zitiert Bechmann mit der Feststellung, dass dieser „die Nutzwertanalyse der 2. Generation maßgeblich entwickelt“ hat. Als Forderungen an die Weiterentwicklung werden genannt:    

Der komplexe Bewertungsvorgang ist in mehrere, weniger komplexe Vorgänge aufzuteilen und die Gesamtbewertung aus Teilbewertungen zusammen zu fügen. Die Zielerträge sind ordinal zu skalieren mit maximal zehn Werten (Grenze der Überschaubarkeit). Es sind Vorstellungen zu entwickeln, welche Wertbeziehungen (Substitution, Komplementarität, Konkurrenz oder Indifferenz) zwischen den Zielerfüllungsgraden bestehen. Alle Zielerträge müssen durch Wertung und nicht durch Berechnung ermittelt werden.

382

Methoden des strategischen Informationsmanagements

Wesentliche Änderungen gegenüber der beschriebenen Vorgehensweise bei der Nutzwertanalyse ergeben sich aus diesen Forderungen allerdings nicht. Dies gilt auch für den Hinweis auf die Zweckmäßigkeit der Kombination der Nutzwertanalyse mit anderen Methoden wie Delphi-Methoden zum Festlegen des Zielsystems und zum Bestimmen der Kriteriengewichte, Kreativitätstechniken zum Identifizieren von Zielkriterien und Szenariotechnik zur Darstellung und Abschätzung der Wirkungen der Alternativen.

Annahmen des Nutzwertmodells Dem Nutzwertmodell liegen die folgenden Annahmen zu Grunde, die bei seiner Anpassung an spezifische Entscheidungssituationen und bei der Interpretation der Analyseergebnisse zu beachten sind:     

Die Menge der Handlungsalternativen ist bekannt; sie enthält auch die gesuchte optimale Alternative. Es existiert eine Nutzenfunktion, die durch das Zielsystem vollständig abgebildet wird. Ein geringer Zielertrag eines Ziels kann durch einen hohen Zielertrag eines anderen Ziels auf Grund der Zielgewichtung kompensiert werden. Die Zielinhalte sind disjunkt, so dass keine Doppel- oder Mehrfachbewertungen auftreten. Die Präferenzordnung der Entscheidungsträger bezüglich der Kriteriengewichte ist konsistent.

Vorbehalte gegen die Anwendung des Nutzwertmodells resultieren weniger aus diesen Annahmen als vor allem aus der subjektiv gestaltbaren Vorgehensweise bei der Anpassung an spezifische Entscheidungssituationen. Dies ist dann ohne Bedeutung, wenn die Entscheidungssituation dadurch gekennzeichnet ist, dass nur durch Einbeziehung der subjektiven Präferenzen der Entscheidungsträger eine optimale Alternative bestimmt werden kann. Das Vorliegen dieser Voraussetzung ist in jedem Anwendungsfall zu überprüfen. Durch die mathematische Einfachheit der Nutzwertanalyse (sie beschränkt sich auf die Verwendung der Grundrechenarten) wird eine Transparenz gewährleistet, die das leichte Nachvollziehen der Ergebnisse ermöglicht. Im Unterschied dazu ist das von Saaty an der Wharton School of Business in den 1970er Jahren entwickelte Analytic Hierarchy Process (AHP) – in der Fachliteratur auch als Eigenvektormethode bezeichnet – mathematisch gesehen ein vergleichsweise exaktes Verfahren. Die optimale Alternative, als die Alternative mit der höchsten Priorität definiert, wird mit folgenden Arbeitsschritten bestimmt (zitiert nach Zahedi):    

Step 1: Setting up the decision hierarchy by breaking down the decision problem into a hierarchy of interrelated decision elements. Step 2: Collection input data by pairwise comparisons of decision elements. Step 3: Using the „eigenvalue“ method to estimate the relative weights of decision elements. Step 4: Aggregating the relative weights of decision elements to arrive at a set of ratings for the decision alternatives (or outcomes).

Nutzwertanalyse (NUTZW)

383

Anwendungen des AHP sind aus verschiedenen Wissenschaftsdisziplinen bekannt, so auch aus der Information Systems Discipline, der sogenannten „Schwesterdisziplin der Wirtschaftsinformatik“, die sich explizit methodischer präsentiert als die auf Heuristiken fokussierte Wirtschaftsinformatik. Eine naheliegende Anwendung im Informationsmanagement ist die Unterstützung von Entscheidungen über alternative IT-Projekte im Portfoliomanagement (vgl. Lerneinheit SPLAN).

Forschungsbefunde Huizingh/Vrolijk verwenden acht Merkmale zur Beurteilung der Brauchbarkeit von AHP für das Portfoliomanagement (z. B. Möglichkeit einer realistischen Beschreibung des Entscheidungsproblems und Anwendbarkeit der Methode). Im Ergebnis wird als charakteristisch für AHP die Möglichkeit der Verwendung quantitativer und qualitativer Bewertungskriterien mit unterschiedlicher Bedeutung für Entscheidungssituation und Entscheidungsträger genannt. AHP strukturiert den Entscheidungsprozess, unterstützt die Entscheidungsfindung in Gruppen und bezieht Analysemethoden wie Sensitivitätsanalyse und What-if-Analyse ein. Für die relativ komplexe mathematische Berechnung der Eigenwerte und Eigenvektoren gibt es Werkzeuge. Wie bei der Nutzwertanalyse kann die Annahme der Unabhängigkeit der Kriterien zu Bewertungsproblemen führen. Riedl stellt als Fazit einer exemplarischen Darstellung der Funktionsweise eines Evaluierungsverfahrens fest, dass AHP der Nutzwertanalyse bei drei Merkmalen überlegen ist: Die Kriterien werden hierarchisch gegliedert, was die Transparenz der Entscheidungssituation erhöht, ein direkter Vergleich qualitativer und quantitativer Kriterien ist möglich und es erfolgt eine Konsistenzprüfung. Widersprüche im Evaluationsprozess können aufgedeckt werden. Die Nutzwertanalyse ist leichter verständlich, ein Rank Reversal ist nicht möglich und die Kosten für ein Softwarewerkzeug sind geringer. Nollau/Gottfried beschreiben eine als Vektor-Nutzwertanalyse und Methodik bezeichnete Vorgehensweise. Ihre Besonderheit im Vergleich zur klassischen Nutzwertanalyse bestehe sowohl in der Anwendungsbreite als auch in der Ergebnisverifikation a) durch die Möglichkeit, auch quantitative Daten einbeziehen zu können und b) die Vektordarstellung der Nutzwertkomponenten und deren Projektion auf den maximalen Gesamtnutzwertvektor zu ermöglichen. Nach Ansicht der Autoren (Vorwort) „… steht somit eine universelle Methodik zur Entscheidungskompetenz zur Verfügung, die sich in der Praxis bestens bewährt.“ Als Anwendungsbeispiele werden die Auswahl von Unternehmensstandorten, Investitionsentscheidungen, Lieferantenbewertung sowie Zeit- und Arbeitssystembewertung genannt. Über die Implementierung der auch als Projektionsmethode bezeichneten Variante der Nutzwertanalyse bei der Grammer AG (http://grammer.com/) wird berichtet. Auf die offensichtliche „Verwandtschaft“ der Vektor-Nutzwertanalyse mit AHP wird kein Bezug genommen. Eisenführ/Weber berichten über Ergebnisse einer empirischen Untersuchung, mit der die Auswirkung der Zerlegung von Zielen in Unterziele auf die Zielgewichte erkundet werden sollte (Laborstudie, 261 Studierende der Betriebswirtschaftslehre als Versuchspersonen in acht Gruppen, davon zwei Kontrollgruppen; Entscheidungsproblem: Arbeitsplatzwahl nach Studienabschluss). Ausgangsthese war, dass durch Zerlegung die vom Entscheidungsträger empfundene relative Bedeutung eines Ziels (relativ zu den übrigen Zielen im Zielsystem) vergrößert wird. Die untersuchten Hypothesen lauteten:

384

 

Methoden des strategischen Informationsmanagements

H1: Die Summe der Gewichte der Unterziele zerlegter Oberziele in einem linearen Modell ist größer als die Summe der Gewichte der nicht zerlegten Oberziele (so genannter Splitting-Bias). H2: Je höher die (subjektiv empfundene) Korrelation zwischen den durch Zerlegung entstehenden Unterzielen ist, desto größer ist der Splitting-Bias.

Zur Ermittlung der Zielgewichte wurden vier Gewichtungsmethoden verwendet: SwingMethode, Direct-Ratio-Methode, Conjoint-Methode und Multiple-Importance-Methode. H1 wurde bei allen verwendeten Gewichtungsmethoden deutlich bestätigt, zu H2 waren die Ergebnisse widersprüchlich. Im Ergebnis wird festgestellt, dass mit einem Splitting-Bias generell gerechnet werden muss. Aufgabenverweise Wahlprobleme, die mit Hilfe der Nutwertanalyse gelöst werden können, gibt es bei zahlreichen IM-Aufgaben auf strategischer und auf administrativer Aufgabenebene. Kontrollfragen 1. Was wird als Nutzwertmodell und was im Unterschied dazu als Nutzwertanalyse bezeichnet? 2. Welches sind die bestimmenden Einflüsse beim Ermitteln des Zielsystems? 3. Welcher Unterschied besteht zwischen Zielertrag, Zielwert und Nutzwert? 4. Was bewirkt die Gewichtung der Zielkriterien und wie kann dabei methodisch vorgegangen werden? 5. Welche Interdependenz besteht zwischen Skalierungsmethode(n) und Entscheidungsregel(n)? Quellen Eisenführ, F. / Weber, M.: Zielstrukturierung: ein kritischer Schritt im Entscheidungsprozeß. In: Zeitschrift für betriebswirtschaftliche Forschung 11/1986, 907–929 Huizingh, K. R. E. / Vrolijk, C. J.: Decision Support for Information Systems Management: Applying Analytic Hierarchy Process. Research Report No. 95B26, University Groningen, 1995 Mäder, O. B. / Ziegler, M.: Erfolgsfaktoren im Auswahlprozess betriebswirtschaftlicher Software für KMU. In: BFuP 5/2010, 558–574 Nollau, H.-G. / Gottfried, U.: Entscheidungskompetenz durch Anwendung der Vektor-Nutzwertanalyse. Lohmar 2009 Riedl, R.: Der Analytic Hierarchy Process: Ein geeignetes Verfahren für komplexe Entscheidungen in der Wirtschaftsinformatik? In: HMD 246/2005, 104–114 Saaty, Th. L.: Decision Making for Leaders – The Analytic Hierarchy Process for Decisions in a Complex World. 3. A., Pittsburgh 2001 Scholles, F.: Die Nutzwertanalyse und ihre Weiterentwicklung. http://www.laum.uni-hannover.de/ilr/lehre; Abruf 15.11.2008 Weber, M.: Nutzwertanalyse. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Stuttgart 1992, 1436– 1448 Zahedi, F.: The Analytic Hierarchy Process – A Survey of the Method and its Applications. In: INTERFACES 4/1986, 96–108 Zangemeister, C.: Nutzwertanalyse in der Systemtechnik. 4. A., München 1976 Vertiefungsliteratur Klein, R. / Scholl, A.: Planung und Entscheidung: Konzepte, Modelle und Methoden einer modernen betriebswirtschaftlichen Entscheidungsanalyse. München 2004 Schauenberg, B.: Entscheidungsregeln, kollektive. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Stuttgart 1980, 566–575 Weber, M.: Entscheidungen bei Mehrfachzielen. Wiesbaden 1983 Zangemeister, C. / Bomsdorf, E.: Empfindlichkeitsanalyse in der Nutzwertanalyse. In: Zeitschrift für betriebswirtschaftliche Forschung 5/1983, 375–397

Evaluierungsmethoden (EVALU) Lernziele Sie kennen den Zweck von Evaluierungsmethoden und können daraus die Aufgaben der Evaluierung ableiten. Sie können diese Aufgaben mit eigenen Worten beschreiben. Sie kennen die Organisation des Evaluierungsprozesses und eine Vorgehensweise beim Evaluieren. Sie können die Anwendung von Evaluierungsmethoden in die Aufgaben des Informationsmanagements einordnen.

Definitionen und Abkürzungen CC = Common Criteria for Information Technology Security Evaluation; Weiterentwicklung und Harmonisierung der ITSEC und anderer Sicherheitsstandards. Evaluierungskriterium (evaluation criterion) = Eigenschaft des Evaluierungsobjekts, die unter Berücksichtigung des Evaluierungsziels aus diesem abgeleitet und mit der im Einzelnen festgelegt wird, was zu evaluieren ist. Evaluierungsobjekt (evaluation object) = beliebiges Objekt, für das ein Evaluierungsbedarf besteht und das zur Evaluierung vorgegeben ist. Evaluierungsziel (evaluation objective) = Aussage darüber, welche Information der Auftraggeber einer Evaluierungsstudie erwartet bzw. der Evaluator erarbeiten soll. Extremalkriterium (unlimited criterion) = Kriterium, das hinsichtlich des Ausmaßes der Zielerreichung unbegrenzt (maximal oder minimal) formuliert ist. HGB = Handelsgesetzbuch (Deutschland, Österreich). ITSEC = Information Technology Security Evaluation Criteria. ITSEF = Information Technology Security Evaluation Facility. ITSEM = Information Technology Security Evaluation Methodology; Vorgehensweise zur Prüfung und Bewertung der Sicherheit von IT-Produkten. Kriterium (criterion) = Eigenschaft eines Evaluierungsobjekts, dessen Ausmaß durch Messung, Schätzung oder Prognose ermittelt wird. Synonym: Zielkriterium. Kriterienertrag (criterion production) = Ausmaß der Zielerreichung der Kriterien. Kriteriengewicht (criterion weight) = relative Bedeutung der Kriterien in einer bestimmten Evaluierungssituation (Präferenzordnung). Limitierungskriterium (limited criterion) = Kriterium, das hinsichtlich des Ausmaßes der Zielerreichung begrenzt formuliert ist. Messen (measuring) = Zuordnen von Zahlen oder anderen Symbolen zu Objekten, Ereignissen oder Situationen nach einem festgelegten Verfahren (einer Regel). Messgröße (metric) = Eigenschaft eines Objekts, deren Ausprägung mit einer Messmethode ermittelt werden kann. Synonym: Metrik. Metrik (metric) = Synonym für Messgröße. Präferenzordnung (preference order) = durch ein Individuum oder eine Gruppe vorgenommene Ordnung einer Menge von Kriterien auf Grund bestehender Präferenzen. Re-Evaluierung (re-evaluation) = erneute Evaluierung eines Objekts nach erfolgter Vornahme von Änderungen am Objekt auf Grundlage einer Evaluierung.

386

Methoden des strategischen Informationsmanagements

Zweck der Evaluierungsmethoden Evaluierung oder Evaluation heißt, bestimmte Objekte auf der Grundlage eines Systems von Kriterien zielbezogen zu beurteilen. Die Notwendigkeit der Evaluierung von Produkten und Dienstleistungen des IT-Marktes, von Strategien, Methoden und Werkzeugen, von Entwurfsund Entwicklungsergebnissen usw. besteht bei den meisten strategischen und bei vielen administrativen Aufgaben des Informationsmanagements. Evaluierungsbedarf besteht insbesondere dann, wenn es sich nicht um Routineaufgaben handelt, sondern um Vorhaben, die aus dem üblichen betrieblichen Geschehen herausragen und daher als Projekte organisiert sind (z. B. Beschaffungsprojekt, Sanierungsprojekt, Entwicklungsprojekt). Wenn der Evaluierungsbedarf sehr spezifisch und von erheblicher wirtschaftlicher Bedeutung ist (z. B. die Beurteilung mehrerer alternativer ERP-Systeme), dann ist die Evaluierung bestimmter Objekte (z. B. dieser ERP-Systeme) Projektgegenstand. Häufiger ist in der Praxis jedoch der Fall, dass im Rahmen anderer Projekte (z. B. Projekte zur Entwicklung von Informationssystemen) im Projektverlauf planmäßig oder auch ad hoc ein Evaluierungsbedarf besteht bzw. entsteht. Planmäßiger Evaluierungsbedarf wird im Projektplan als Aktivität vorgesehen. Ist für den Projektgegenstand die Verwendung eines Vorgehensmodells verbindlich (vgl. Lerneinheit VOMOD), wird der Evaluierungsbedarf für bestimmte Objekte und Situationen damit verbindlich gefordert. Im Vorgehensmodell können auch Evaluierungskriterien für bestimmte Objekte und Situationen definiert sein. Es ist zweckmäßig, explizit zwischen Evaluierung und Bewertung zu unterscheiden, um unterschiedliche Ziele, Objekte und Vorgehensweisen berücksichtigen zu können. Bei der Bewertung bzw. beim Bewerten geht es nicht um die Beurteilung von Objekten nach prinzipiell beliebigen Zielen, sondern darum, den Geldwert (Wert in Geldeinheiten) von ITKomponenten sowie die Kosten von Produkten und Dienstleistungen zu ermitteln, die hergestellt bzw. erbracht werden. Mit der Bewertung werden verschiedene Zwecke verfolgt bzw. sollen unterschiedliche Bewertungsprobleme gelöst werden, beispielsweise folgende: 





Bei einer Analyse möglicher Konsequenzen eines Verlustes der Verfügbarkeit im Rahmen einer Risikoanalyse wird der Wert der Informationsinfrastruktur ermittelt, um entscheiden zu können, welche Sicherungsmaßnahmen mit welchen Kosten zur Verhinderung oder Verringerung von Schäden erforderlich und wirtschaftlich sinnvoll sind (vgl. Lerneinheit SIKON). Die Bewertung erfolgt zu Wiederbeschaffungskosten, also zu den Kosten, die zur Wiederherstellung der Funktions- und Leistungsfähigkeit der Informationsinfrastruktur nach Beschädigung, Zerstörung oder Verlust erforderlich sind. Für den Abschluss von Computerversicherungen (z. B. einer Elektronikversicherung), die Ermittlung der Versicherungssumme und die Festlegung der Prämienhöhe wird der Wert der zu versichernden Objekte (z. B. neu beschaffte Hardware) ermittelt. Die Bewertung erfolgt zum Listenpreis (Neuwert). Für die innerbetriebliche Leistungsverrechnung, also für die Verrechnung von Dienstleistungen, welche die IT-Abteilung für die Anwender (z. B. Abteilungen, Geschäftsprozesse) erbringt, werden Verrechnungspreise kalkuliert und festgelegt (vgl. Lerneinheit KOLER).

Evaluierungsmethoden (EVALU)

387

Ein aus verschiedenen Gründen praktisch bedeutsames Bewertungsproblem ist das der Softwarebewertung, d. h. die Beurteilung von Software nach ihrem Wert gemessen in Geldeinheiten. Sie erfolgt – analog zur Evaluierung – nach bestimmten, dem Bewertungsobjekt angemessenen Prinzipien (Bewertungsprinzipien), insbesondere folgenden:  

 

Grundsätzlich gilt das Prinzip der Anschaffungskosten; Höchstwert sind die Anschaffungskosten (bei Fremdbezug) bzw. die Herstellungskosten (bei Eigenentwicklung). Soweit Software dem Anlagevermögen zuzurechnen ist, gilt das gemilderte Niederstwertprinzip; die Bewertung erfolgt zu den um planmäßige Abschreibungen verminderten Anschaffungskosten bzw. Herstellungskosten. Gegebenenfalls können oder müssen außerplanmäßige Abschreibungen vorgenommen werden. Gehört die Software zum Umlaufvermögen, gilt das strenge Niederstwertprinzip, nach dem der geringste Wert (Anschaffungs- bzw. Herstellungskosten oder Marktpreis) anzusetzen ist. Im Falle des Konkurses gilt der Zeitwert, der sich nach Art der Software (ob Individualsoftware oder Standardsoftware) und ihrer Verwendung (Einfachnutzung oder Mehrfachnutzung) aus dem Ertragswert, dem Marktpreis bzw. dem Einzelveräußerungspreis oder dem Reproduktionswert ergibt.

Handels- und steuerrechtlich gilt nach deutscher und österreichischer Rechtslage ein Aktivierungsverbot für selbst entwickelte Software (§ 248 Abs. 2 HGB bzw. § 197 Abs. 2 HGB). Das Verbot betrifft ausdrücklich nur das Anlagevermögen; Umlaufvermögen (wie z. B. selbst entwickelte und für den Verkauf bestimmte Software) ist zu aktivieren. In anderen Ländern ist eine Aktivierung oder Teilaktivierung wahlweise möglich oder sogar verpflichtend (z. B. in Frankreich). Das Aktivierungsverbot entspricht dem Vorsichtsprinzip, das bewirken soll, dass der Wert der Vermögensgegenstände nicht zu optimistisch angesetzt wird. Es widerspricht jedoch einer periodengerechten Erfolgsermittlung und erschwert die Vermittlung eines möglichst getreuen Bildes der Ertragslage (vgl. Lerneinheit KOLER). In einem engen Zusammenhang mit Evaluierung steht Bewertung im Sinne des Qualitätsmanagements (vgl. Lerneinheit QUALM), was in der Praxis häufig auch als solche bezeichnet wird, korrekter Weise aber als Assessment bezeichnet werden sollte. Nach Webster´s Seventh New Collegiate Dictionary ist die originäre Bedeutung von Assessment nicht Bewertung, sondern „a consideration of someone or something and a judgement about them”, also Beurteilung. Beispielsweise liefert die Verwendung des EFQM Excellence Modells (vgl. Lerneinheit MEQUA) Aussagen über Reifegrad, Stärken und Verbesserungspotenzial von Organisationen, was also Beurteilung bzw. Assessment und nicht Bewertung ist.

Vorgehensweise bei der Evaluierung Evaluierung soll methodisch erfolgen, also zielorientiert sein, auf einem System von Regeln aufbauen und intersubjektiv nachvollziehbar sein. Dies heißt, dass die Evaluierung nach einem dokumentierten Arbeitsplan (entsprechend dem Wertanalyse-Arbeitsplan nach EN 1325-1) durchgeführt wird. Er umfasst folgende Phasen:  

Festlegen der Evaluierungsobjekte, Formulieren des Evaluierungsziels,

388

     

Methoden des strategischen Informationsmanagements

Ableiten der Evaluierungskriterien, Gewichten der Evaluierungskriterien, Abbilden der Evaluierungskriterien in Messgrößen, Auswählen von Messmethoden, Messen der Kriterienerträge und Organisation des Evaluierungsprozesses.

Bezüglich der Evaluierungsobjekte ist zu unterscheiden, ob es sich um die Evaluierung von Prozessen (z. B. Softwareentwicklungsprozesse), Produkten (z. B. Softwareprodukte) oder Dienstleistungen (z. B. Benutzerschulung) handelt. Bei der Evaluierung von Prozessen geht es primär um Qualitätsverbesserung (vgl. Lerneinheit QUALM), bei der von Produkten primär um Informationsgewinnung für Technologieeinsatzentscheidungen (vgl. Lerneinheit TECHM), bei der von Dienstleistungen sowohl um Qualitätsverbesserung (vgl. Lerneinheit SEMAN) als auch um Informationsgewinnung für Entscheidungen (z. B. über den Outsourcing-Grad, vgl. Lerneinheit OUTSO). Im Folgenden wird die Vorgehensweise bei der Evaluierung von Produkten erklärt, die sinngemäß auf Dienstleistungen zu übertragen ist.

Festlegen der Evaluierungsobjekte Wegen der Vielzahl möglicher Evaluierungsobjekte (z. B. Hardware- und Softwareprodukte sowie Konfigurationen daraus, Methoden und Werkzeuge) wird diese Phase wie folgt exemplarisch erläutert: In einer Ausschreibung wird eine bestimmte Hardware/Systemsoftware-Konfiguration gefordert. Gegenstand der Angebote sind dann anbieterspezifische Konfigurationen, und jede Konfiguration ist ein Evaluierungsobjekt. Der Evaluierungsprozess wird so oft durchlaufen, wie entsprechende Angebote bzw. alternative Konfigurationen als Ergebnis der Ausschreibung als Evaluierungsobjekte zur Auswahl stehen.

Formulieren des Evaluierungsziels Bei den als Evaluierungsziel definierten Aussagen handelt es sich meist um absolute Aussagen je Objekt (z. B. über seinen Nutzwert, vgl. Lerneinheit NUTZW, oder seinen Gebrauchswert) sowie – häufig in Ergänzung dazu – um relative Aussagen (z. B. das Objekt mit dem maximalen Nutzwert einer zur Evaluierung anstehenden Objektmenge). Das Evaluierungsziel gibt zusammenfassend an, welche Information der Auftraggeber einer Evaluierung vom Evaluator (d. h. der Person oder Organisation, welche die Evaluierung vornimmt) erwartet bzw. welche Information der Evaluator liefern soll. Das Evaluierungsziel folgt aus dem geplanten Verwendungszweck des Ergebnisses der Evaluierung. Bestimmte Evaluierungsverfahren (z. B. das der ITSEF) sind explizit auf ein bestimmtes Evaluierungsziel (im Beispiel Sicherheit) an bestimmten Objekten (im Beispiel Systeme der Informationstechnik) ausgerichtet. Zweck der Evaluierung ist beispielsweise die Zertifizierung dieser Objekte. Für das Evaluierungsziel verantwortlich ist jedenfalls der Auftraggeber einer Evaluationsstudie, auch wenn die Zielformulierung gemeinsam bzw. in Abstimmung mit dem Evaluator erfolgt (was explizit Auftragsgegenstand sein kann).

Ableiten der Evaluierungskriterien Evaluierungskriterien sind Eigenschaften eines Evaluierungsobjekts, die unter Berücksichtigung des Evaluierungsziels aus diesem abgeleitet werden (z. B. die Eigenschaft Benutzbarkeit beim Evaluierungsobjekt Anwendungssoftware). Mit Evaluierungskriterien wird

Evaluierungsmethoden (EVALU)

389

im Einzelnen festgelegt, was evaluiert wird. Sind mehrere alternative Evaluierungsobjekte vorgegeben, werden nur solche Eigenschaften als Evaluierungskriterien verwendet, deren Ausprägungen (Kriterienerträge) als signifikant voneinander abweichend eingeschätzt werden, da Eigenschaften gleicher oder vergleichbarer Zielerträge zur Optimumbestimmung nichts beitragen. Aus methodischer Sicht unterscheiden sich Evaluierungskriterien insbesondere bezüglich des Aufwands für die Ermittlung der Kriterienerträge, und zwar wie folgt:  

das Ermitteln der Kriterienerträge ist unproblematisch (z. B. liegen die Daten als Produktbeschreibung vor und sind nur auf Plausibilität und Vollständigkeit zu überprüfen), das Ermitteln der Kriterienerträge erfordert aufwendige empirische Ermittlungsmethoden (vgl. den Abschnitt „Messen der Kriterienerträge“).

In der Regel liegen bei einer bestimmten Evaluierungsaufgabe beide Arten von Evaluierungskriterien vor. Beim Evaluierungsobjekt Hardware/Systemsoftware-Konfiguration trifft das zuerst genannte Merkmal auf Evaluierungskriterien wie Investitionskosten (Anschaffungspreise) oder Mietkosten, Wartungskosten, Anzahl der Installationen und Lieferzeit zu. Das zweite Merkmal trifft für eine Reihe von qualitativen und quantitativen Eigenschaften zu, die zum Kriterium Leistung zusammengefasst werden. Zum Ermitteln des Kriterienertrags muss Leistung empirisch gemessen werden. Das erfordert eine Analyse des Leistungsbegriffs, da Leistung im hier verwendeten Sinne nicht mit dem physikalischen Begriff Leistung (Quotient aus Arbeit und Zeit) identisch ist. Leistung im physikalischen Sinne kann nur für einzelne Komponenten des Evaluierungsobjekts (z. B. Leistung eines Arbeitsplatzdruckers in Zeichen/Zeiteinheit) gemessen werden. Der Versuch, die so definierten Leistungen einzelner Komponenten zur Leistung des Evaluierungsobjekts zu aggregieren (analytische Vorgehensweise), führt meist nicht zum Ziel. Leistung im hier verwendeten Sinne ist die Fähigkeit eines Techniksystems, in qualitativer und quantitativer Hinsicht bestimmte Aufgaben im Informations- und Kommunikationsprozess zu bewältigen. In Abhängigkeit von der Definition der Anforderungen reichen zur Messung der Leistung teilweise kategoriale Urteile auf einer nominalen Skala aus, teilweise sind präzisere Urteile erforderlich, die kardinal skaliert sein müssen (zur Skalierung vgl. Lerneinheit NUTZW). Das erfordert eine synthetische Vorgehensweise, mit der das Verhalten einer Menge von Komponenten und/oder stochastisch ablaufender Prozesse beobachtet und gemessen wird. Diese Leistungsmessung kann nur mit einer definierten Aufgabe (Arbeitslast) erfolgen, muss also in einer definierten Leistungsumgebung durchgeführt werden. Damit werden zwei Bereiche von Einflussfaktoren auf die Leistung erfasst, nämlich  

Einflussfaktoren, die auf Eigenschaften des Evaluierungsobjekts selbst beruhen, und Einflussfaktoren, die auf der Arbeitslast sowie darauf beruhen, wie die Durchführung der Aufgabe gestaltet ist (Organisation der Arbeitslast).

Gewichten der Evaluierungskriterien Die Evaluierungskriterien haben für die Ermittlung des Wertes eines Evaluierungsobjekts in der Regel eine unterschiedlich große Bedeutung. Deshalb werden sie mit Kriteriengewichten belegt, mit anderen Worten: es wird eine Präferenzordnung der Evaluierungskriterien hergestellt und verwendet. Die Präferenzordnung bewirkt, dass die Kriterienerträge bzw. Kriterienwerte (skalierte Kriterienerträge) bei der Wertermittlung mit unterschiedlichem Gewicht berücksichtigt werden. Zur Herstellung der Präferenzordnung können verschiedene Verfah-

390

Methoden des strategischen Informationsmanagements

ren verwendet werden. (Diese Verfahren und die Vorgehensweise bei ihrer Anwendung werden in Lerneinheit NUTZW erläutert).

Abbilden der Evaluierungskriterien in Messgrößen Die Kriterienerträge lassen sich häufig nicht direkt messen; daher müssen die Evaluierungskriterien in Messgrößen transformiert werden (vgl. Lerneinheit CONTR). Bei Transformation der Leistung als Evaluierungskriterium in Messgrößen müssen beide Bereiche von Einflussfaktoren (Hardware/Software und Arbeitslast) berücksichtigt werden. Deshalb sind konventionelle Messgrößen (z. B. Ausführungszeiten für einzelne Rechenoperationen) zur Leistungsmessung ungeeignet. Aussagekraft haben nur Messgrößen, die etwas über die ökonomischen und sozialen Auswirkungen des hier betrachteten Evaluierungsobjekts aussagen (z. B. Akzeptanz, Antwortzeitverhalten, Benutzbarkeit, Verfügbarkeit). Es können nur Messgrößen verwendet werden, die operational formuliert und mit einem angemessenen Aufwand verwendbar sind. Eine Messgröße ist operational, wenn es eine Messmethode gibt, mit der das Messergebnis intersubjektiv überprüft werden kann (d. h. dass verschiedene Evaluatoren bei deren Anwendung im Wesentlichen zum gleichen Ergebnis kommen). Welche Messgrößen für Leistung geeignet sind, muss in jedem Evaluierungsprozess unter Berücksichtigung der genannten Einflussfaktoren entschieden werden. Dabei bewegt man sich zwischen den beiden Extremen „Leistungsmessung mit einer Messgröße“ und „Leistungsmessung mit zahlreichen Messgrößen“. 



Leistungsmessung mit einer Messgröße ist unrealistisch, weil sich die Vielzahl der die Leistung beeinflussenden Faktoren nicht zu einer Messgröße aggregieren lässt. Leistung mit einer Messgröße zu erfassen würde wesentliche, die Leistung bestimmende Faktoren außer Acht lassen. Ergebnisse der Messung zu verschiedenen Leistungsmerkmalen können jedoch aggregiert werden (z. B. im einfachsten Fall mit einem Kiviath-Graph). Leistungsmessung mit zahlreichen Messgrößen ist ebenfalls unrealistisch, weil sich die Messergebnisse nicht zu aussagefähigen Kriterienerträgen zusammenfassen lassen und weil die Messung wegen der Interdependenz zwischen den Komponenten und/oder Prozessen des Evaluierungsobjekts, die nicht ausreichend beachtet werden können, zu unzuverlässigen Ergebnissen führt. Das schließt nicht aus, bei der Festlegung der Messgrößen zunächst eine feine Granularität der Evaluierungskriterien zu verwenden und sie in geeigneter Weise zu Messgrößen zusammenzufassen.

Messgrößen, welche die genannten Extreme vermeiden und für jeden Evaluierungsprozess mit dem Evaluierungsobjekt Hardware/Systemsoftware-Konfiguration verwendet werden können, sind:   

Durchsatzzeit (Zeiteinheiten/Arbeitslast) = Zeitraum, der zur Abarbeitung der Arbeitslast erforderlich ist, gemessen vom Beginn der Dateneingabe bis zum Ende der Datenausgabe. Antwortzeit (Zeiteinheiten/Transaktion) = Zeitraum, der zur Ausführung einer Transaktion erforderlich ist, gemessen vom Ende der Daten bis zum Ende der Datenausgabe. Antwortzeitverhalten (Antwortzeiten/Zeiteinheit) = Streuung der Antwortzeiten für eine Menge gleicher oder gleichartiger Transaktionen.

Evaluierungsmethoden (EVALU)

 

391

Verfügbarkeit (%) = 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 (Zeiteinheit) = 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.

Auswählen von Messmethoden Für das Messen der Kriterienerträge stehen alle Methoden zur Verfügung, mit denen Daten über Evaluierungsobjekte direkt (z. B. durch Beobachten) oder indirekt (z. B. durch Befragen) erfasst werden können (Erfassungsmethoden, auch als Erhebungstechniken bezeichnet). Ihre Eignung ist im Einzelfall – insbesondere in Abhängigkeit vom Evaluierungskriterium bzw. von der Messgröße – zu beurteilen. Im Folgenden werden Messmethoden genannt, die eine spezifische Ausrichtung auf die Bearbeitung von Evaluierungsaufgaben haben. Ihnen gemeinsam ist, dass sie eine oder mehrere Erfassungsmethoden verwenden, die Messung der Kriterienerträge empirisch und die Datenerfassung vor allem durch Beobachten und Messen und nicht durch Befragen erfolgt. 





Mit Experimenten werden behauptete Kausalzusammenhänge zwischen unabhängigen Variablen (UV) und abhängigen Variablen (AV) empirisch überprüft (z. B. die Hypothese „wenn die Anzahl der Arbeitsstationen a im Lokalen Netz X bei gleicher Arbeitslast Y erhöht wird, dann verlängert sich die Antwortzeit je Transaktion der Arbeitsstationen b“). Die UV werden vom Experimentator entsprechend den mit dem Experiment verfolgten Zwecken gesetzt und kontrolliert (im Beispiel wird a vom Experimentator vergrößert). Die AV werden auf Grund der Veränderungen der UV kausal beeinflusst; diese Beeinflussung wird beobachtet und ihr Wert wird gemessen (im Beispiel wird b in Abhängigkeit von den Veränderungen von a beobachtet und gemessen). Da Experimente nur selten als Feldexperiment, das heißt in der Wirklichkeit durchgeführt werden können, handelt es sich meist um Laborexperimente. Mit Benchmarking, einer spezifischen Form des Experiments, werden Kriterienerträge für Evaluierungskriterien ermittelt, die für Hardware-/Software-Systeme typisch sind. Benchmarks bilden wesentliche Eigenschaften der Evaluierungsobjekte und der Arbeitslast ab. Der Aufwand, den die Entwicklung und Implementierung von Benchmarks erfordert sowie die Zweckmäßigkeit der Verwendung einheitlicher Benchmarks für vergleichbare Evaluierungsaufgaben, haben zur Herausbildung von Standard-Benchmarks geführt, die weltweit verwendet werden (z. B. TPC Benchmarks, SPEC Benchmarks, anwendungsspezifische Benchmarks wie der Oracle Applications Standard Benchmark und der SAP Standard Application Benchmark). Die Entwicklung und Anwendung dieser Art Benchmarks ist mit dem Benchmarking im Sinne des Prozessmanagements nicht identisch (vgl. Lerneinheit MEGPM). Bei der Anwendung von Testmethoden ist das Evaluierungsobjekt oder sind Teile davon das Testobjekt. Testmethoden eignen sich dazu, Fehler im Testobjekt aufzudecken. Das heißt, dass Fehlervorgaben erforderlich sind, die aus den Evaluierungskriterien abgeleitet werden müssen, und das heißt auch, dass nicht alle im Testobjekt vorhandenen Fehler aufgedeckt werden können. Durch Test kann nur die Existenz von Fehlern nach-

392





Methoden des strategischen Informationsmanagements

gewiesen werden, für die Fehlervorgaben definiert worden sind. Das Testobjekt wird auf einem Testsystem implementiert und überprüft. Da es keine Theorie für die Konfigurierung von Testsystemen gibt, wird versucht, das Testsystem so zu gestalten, dass möglichst alle Komponenten des Testobjekts von den Testdaten einmal durchlaufen werden. Fehler, die auf fehlende Komponenten des Testobjekts zurückzuführen sind, können offenbar nicht gefunden werden. Mit Fallstudien im Sinne von Forschungsfallstudien (im Unterschied zu Lehrfallstudien) wird zu einem bestimmten Zeitpunkt oder in einem relativ kurzen Zeitraum, dessen Länge von der Art des Evaluierungsobjekts abhängig ist, beobachtet und gemessen. Eine anspruchsvolle Form der Fallstudie verwendet ein A-B-A-Untersuchungsdesign. Zunächst wird das Evaluierungsobjekt zu einem bestimmten Zeitpunkt oder in einem relativ kurzen Zeitraum (A) beobachtet, und es wird gemessen, dann wird das Evaluierungsobjekt entsprechend dem Evaluierungsziel verändert, und es wird erneut (B) beobachtet und gemessen; schließlich wird das Evaluierungsobjekt wieder in den Ausgangszustand (A) zurückversetzt, und es wird ein drittes Mal beobachtet und gemessen. Mit der Fehlerbaumanalyse (FBA) – für sicherheitstechnische Untersuchungen treffender als Gefährdungsbaumanalyse bezeichnet – werden Zuverlässigkeit bzw. Ausfallwahrscheinlichkeit großer und komplexer Systeme (Produkte und Prozesse) aller Art ermittelt. FBA ist ein deduktives Analyseverfahren, eine Vorgehensweise also, die – von einem unerwünschten Top-Ereignis ausgehend – top-down die Ereigniskombinationen als Eingangsereignisse betrachtet, die bottom-up zu diesem Top-Ereignis führen. Für das Sicherheitsmanagement und das Katastrophenmanagement (vgl. Lerneinheiten SICHM und NOMAN) ist eine derartige Untersuchung sowohl von Hardware als auch von Software und insbesondere von Hardware/Software-Kombinationen, im weiteren Sinne von Informationssystemen, von Interesse. Besonders die Tatsache, dass es keine Testmethoden für Software gibt, die sicherstellen, dass alle in einem Softwareentwurf enthaltenen Fehler aufgedeckt werden, macht die FBA zu einer wichtigen Messmethode und ihre Anwendung zu einer analytischen QM-Maßnahme (vgl. Lerneinheit QUALM).

Beobachten im Sinne der Evaluierungsmethoden meint methodisches Vorgehen bei der Erhebung von Daten über Evaluierungsobjekte, was insbesondere heißt: 

 

Beobachten erfolgt systematisch, indem Beobachtungen bewusst und selektiv zu ganz bestimmten Evaluierungszwecken durchgeführt werden. Ausgangspunkt ist ein Evaluierungsproblem, das vor dem Hintergrund mehr oder weniger umfangreicher theoretischer Grundlagen formuliert wird. Es werden häufig spezielle Beobachtungs- und Messinstrumente verwendet. Beobachten erfolgt kontrolliert; es werden die verwendete Beobachtungsform und die charakteristischen Merkmale der Beobachtungssituation dokumentiert, um eine Wiederholung der Beobachtung (z. B. zum Zweck der Überprüfung) zu ermöglichen.

Beobachten als direkte empirische Erfassungsmethode kann selbst wieder direkt oder indirekt erfolgen. Direktes Beobachten heißt, dass das interessierende Phänomen beobachtet wird. Das Beobachten erfolgt indirekt, wenn (nur) Spuren beobachtet werden, die das interessierende Phänomen erzeugt hat (z. B. Ereignisspuren über Befehlsfolgen und Prozessabläufe, um das dynamische Ablaufgeschehen in Computersystemen sichtbar zu machen).

Evaluierungsmethoden (EVALU)

393

Messen der Kriterienerträge Messen der Kriterienerträge heißt Anwenden der ausgewählten Messmethoden und Durchführen der Messungen am Evaluierungsobjekt. Da die Erläuterung dieses Prozesses nur exemplarisch erfolgen kann, wird auf einschlägige Lerneinheiten verwiesen (insbesondere auf die Lerneinheiten im Kapitel „Fallstudien“).

Organisation des Evaluierungsprozesses





Evaluierungsproblem

Informationsdefizit

Diese wird am Beispiel Angebotsanalyse gezeigt, deren Zweck es ist, aus einer Menge Systemalternativen (Hardware, Software und Nebenleistungen) das optimale System zu bestimmen (z. B. das System mit dem größten Nutzwert). Der Evaluierungsprozess ist in die Phasen Bestimmen der Evaluierungsobjekte (Alternativensuche), Grobauswahl und Optimumbestimmung gegliedert (vgl. Abbildung EVALU-1 mit Phasen und Rückkopplungen).

Alternativensuche - Informationsbeschaffung - Definition von K.o.-Kriterien Grobauswahl - Anwendung von K.o.-Kriterien - Definition des Kriterienkatalogs

Erste Phase: Alternativensuche. Informationen über potenzielle Evaluierungsobjekte werden durch AusschreiOptimumbestimmung bung beschafft und sind in Angeboten - Anwendung des Kriterienkatalogs dokumentiert. In der Regel sind ergän- Nutzwertanalyse zende Informationsquellen wie Softwarekataloge, Produktspezifikationen der Anbieter, Produktbeschreibungen Evaluierungsergebnis in Fachzeitschriften und Spezialdokumenten, Präsentationen auf Messen und Erklärungen in Seminaren sowie die Abb. EVALU-1: Organisation des Evaluierungsprozesses Webseiten der Anbieter erforderlich. Auf Grundlage dieser Informationen werden die Eigenschaften der Evaluierungsobjekte herausgearbeitet, die als K.o.-Kriterien definiert werden sollen. Zweite Phase: Grobauswahl. Die Evaluierungsobjekte werden anhand der Erträge der K.o.-Kriterien beurteilt. Wegen des Limitierungscharakters der K.o.-Kriterien wird die Objektmenge auf die Menge der zulässigen Objekte reduziert, also auf die Objekte, welche alle Limitierungskriterien erfüllen. Diese Aussage geht von der Annahme aus, dass in der ersten Phase alle Informationen beschafft wurden, welche notwendig sind, um die Erträge für die K.o.-Kriterien bestimmen zu können. Ist dies nicht der Fall, wird zur ersten Phase zurückgegangen und die Informationssuche fortgesetzt. Nach dem Bestimmen der zulässigen Objekte werden alle Eigenschaften herausgearbeitet, die als zusätzliche Evaluierungskriterien für die zulässigen Objekte verwendet werden sollen (Kriterienkatalog). Diese Evaluierungskriterien haben entweder den Charakter von Limitierungskriterien oder von Extremalkriterien.

394



Methoden des strategischen Informationsmanagements

Dritte Phase: Optimumbestimmung. Die zulässigen Objekte werden auf der Grundlage der Kriterienerträge beurteilt; es wird das optimale Objekt bestimmt. Dabei muss in der Regel davon ausgegangen werden, dass die bisher verwendeten Informationsquellen nicht ausreichen, um die Erträge für alle Evaluierungskriterien bestimmen zu können. Die erste Phase des Evaluierungsprozesses muss dann nochmals durchlaufen werden, wobei andere Methoden der Informationsbeschaffung eingesetzt werden müssen.

Forschungsbefunde Sibley/Editor haben zur Ex-post-Evaluierung von Projekten der Informationssystementwicklung mit einer 1989 in Kanada durchgeführten empirischen Studie (schriftliche Befragung von 462 IT-Managern, Rücklaufquote 21 %) u. a. festgestelllt, dass deren primärer Grund der Projektabschluss ist, wobei die Projektergebnisse mit den Projektzielen abgeglichen werden. „Evaluation does not seem to be for the purpose of either longterm assessment of the system impact and effectiviness or for the purpose of providing feedback to modify inappropriate development and project management practices. Further, it is not used to councel and educate ineffective project team personnel.“ (211). Miller/Dunn kommen zur gleichen Forschungsfrage mit einer 1996 in Großbritannien durchgeführten Studie (schriftliche Befragung von 150 IT-Managern, Rücklaufquote 22 %) zu dem Ergebnis, dass in 85 % der befragten Unternehmen Ex-post-Evaluierungen durchgeführt werden und die Größe der IT-Abteilung (IS/IT department) der entscheidende Einflussfaktor ist. Dies veranlasst die Autoren zur Formulierung folgender Hypothese: Je kleiner die ITAbteilung, desto weniger wahrscheinlich ist die Durchführung von Ex-post-Evaluierungen. 61 % der Befragten waren der Meinung, dass das Ausmaß, in dem Ex-post-Evaluierung in ihrem Unternehmen durchgeführt wird, zu gering ist. Osterloh/Frey stellen zum Evaluationsobjekt Forschung und Lehre u. a. fest: Evaluationen haben verborgene und damit meist vernachlässigte Kosten; ihr Nutzen wird überbewertet. Der Nettonutzen von Evaluationen wird überschätzt. Die durch Evaluationen gewonnenen Informationen tragen oft wenig dazu bei, Entscheidungen zu verbessern. Evaluationen verändern das Verhalten der davon betroffenen Personen in systematischer und unbeabsichtigter Weise, unabhängig davon, wie sorgfältig sie durchgeführt werden. Als Alternative zu den meist ex post durchgeführten, am Ergebnis orientierten Evaluationen (output control), werden am Input orientierte Evaluationen (input control, clan control) durch sorgfältige Auswahl und Schulung der Personen empfohlen (z. B. der Mitarbeiter in einem IT-Projekt). Michaels, Sprecher des DFG-Sonderforschungsbereichs Ritualdynamik an der Universität Heidelberg, empfindet Evaluationen in Forschung und Lehre als akademische Rituale, bei denen Ereignisse inszeniert werden, die der Verbesserung der Forschung allenfalls indirekt dienlich sind („inszenierte Überprüfungen, sogenannte Begehungen“). Er plädiert für mehr Vertrauen und für Evaluierungen im Sinne der Überprüfung der Individualität von Forscherpersönlickeiten, also mit einer sehr sorgfältigen Auswahl derer, denen Verantwortung übertragen wird. Mäder/Ziegler verfolgten mit einer empirischen Untersuchung das Ziel, die Transparenz im Auswahlprozess betriebswirtschaftlicher Software in KMU zu verbessern (Online-Fragebogen, 7.441 kontaktierte KMU, rd. 11 % verwertbare Fragebögen). Nach Meinung der Autoren konnte dargestellt werden, (1) welche Kriterien für die Softwareauswahl zentrale Be-

Evaluierungsmethoden (EVALU)

395

deutung haben, (2) dass sich die beiden untersuchten Unternehmensgruppen SoftwareAnwender und Nicht-Anwender hinischtlich ihrer Präferenzen unterscheiden und (3) dass unternehmensspezifische Kriterien kaum (bei Anwendern) bzw. keinen Einfluss (bei NichtAnwendern) auf die Kriterienauswahl haben.

Aus der Praxis Evaluierungskriterien werden in Abhängigkeit von der Evaluierungssituation festgelegt, die primär durch die Art des Evaluierungsobjekts unter Berücksichtigung des Evaluierungsziels bestimmt wird. Für das Evaluierungsobjekt Anwendungssoftware ist folgende Systematik der Evaluierungskriterien in der Praxis verbreitet:     

Evaluierungskriterien, welche die Art der betrieblichen Aufgabe und ihre Abbildung in Funktionen der Software erfassen (Funktionalität), Evaluierungskriterien, welche die systemtechnischen Leistungen der Software erfassen, Evaluierungskriterien, welche über Funktionen und Leistungen hinausgehende Eigenschaften der Software erfassen (so genannte Zusatzleistungen), Evaluierungskriterien, welche die ökonomischen Bedingungen des Erwerbs und der Nutzung der Software erfassen, und Evaluierungskriterien, welche die vom Produkt unabhängigen Eigenschaften des Anbieters der Software erfassen.

Für das Evaluierungsobjekt Entscheidungsunterstützungssysteme (EUS) kann folgende Systematik der Evaluierungskriterien verwendet werden:   

Evaluierungskriterien, mit denen die Benutzerschnittstelle beurteilt wird, Evaluierungskriterien, mit denen die Schnittstelle zwischen Benutzer und EUS sowie zwischen Unternehmensorganisation und EUS beurteilt wird, und Evaluierungskriterien, mit denen die Schnittstelle zwischen der Unternehmensorganisation und ihrer Umwelt beurteilt wird.

Diese Evaluierungskriterien werden aus dem Evaluierungsziel „overall utility or value“ für die Entscheidungsträger, für die das EUS verwendet werden soll, systematisch top-down in diesen drei Kategorien abgeleitet. Für das Evaluierungsobjekt Sicherungsmaßnahme (vgl. Lerneinheit SICHM) kann folgende Systematik der Evaluierungskriterien verwendet werden:    

Ausmaß der Reduzierung der Eintrittswahrscheinlichkeit einer Gefährdung, Ausmaß der Schadensminderung, Implementierungsaufwand (z. B. zeitlich, personell und finanziell) und Betriebskosten, Lebensdauer und Änderungsaufwand.

Es handelt sich um quantitative Evaluierungskriterien, deren Ertrag kardinal gemessen werden kann. Beispiele für Kriterien, deren Ertrag nur qualitativ erfasst werden kann, sind Änderbarkeit, Vereinbarkeit mit bestehenden Sicherungsmaßnahmen, Benutzerakzeptanz, Umgehungswahrscheinlichkeit, Überprüfbarkeit und Erkennbarkeit von Verletzungen. Für die IT-Sicherheitsevaluation, d. h. die Evaluierung der Sicherheit von IT-Produkten, steht mit den „Common Criteria for Information Technology Security Evaluation (CC) / Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstech-

396

Methoden des strategischen Informationsmanagements

nik“ ein international akzeptiertes, mit ISO/IEC 15408 standardisiertes Verfahren zur Verfügung, auf dessen Grundlage auch Zertifikate erteilt werden. Zentrales Instrument ist das Schutzprofil, mit dem Anwender ihren Sicherheitsbedarf darstellen; es können auch funktionale Anforderungen, die nicht in den CC definiert sind, zur Grundlage der Evaluation gemacht werden. Aufgabenverweise Evaluierungsprobleme gibt es bei fast allen strategischen und administrativen IM-Aufgaben. Kontrollfragen 1. Welche Aufgaben ergeben sich aus dem Zweck der Evaluierungsmethoden? 2. Welcher Unterschied besteht zwischen Evaluierungsziel und Evaluierungskriterium? 3. Warum müssen die meisten Evaluierungskriterien in Messgrößen transformiert werden? 4. In welche Phasen wird der Evaluierungsprozess gegliedert und was ist Zweck jeder dieser Phasen? 5. Welche Entscheiungsprobleme auf strategischer Aufgabenebene erfordern die Verwendung von Evaluierungsmethoden? Quellen Daumenlang, K. / Altstötter, C. / Sourisseaux, A..: Evaluation. In: Roth, E. / Holling, H. (Hrsg.): Sozialwissenschaftliche Methoden. 5. A., München/Wien 1995, 702–713 Mäder, B. / Ziegler, M.: Erfolgsfaktoren im Auswahlprozess betriebswirtschaftlicher Software für KMU. In: BFuP 5/2010, 558–574 Michaels, A.: Die große Begehung der Mittelbaustelle. F.A.Z. vom 11.8.2010, N5 Miller, K. / 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 Technologiy. Delft 1997, 47–55 Osterloh, M. / Frey, S.: Evaluations – hidden costs, questionable benefits, and superior alternatives. Unveröffentlichtes Manuskript, Universität Zürich 2007 Sibley, E. H. / Editor, P.: Post Implementation Evaluation of Computer-Based Information Systems: Current Practices. In: Communications of th ACM 2/1990, 203–212 Vertiefungsliteratur Irani, Z.: Information systems evaluation: navigating through the problem domain. In: Information & Management 2002, 111–124 Reichwald, R. et al.: Telekooperation im Innovationstest – Strategieorientierte Evaluation von Pilotprojekten. In: WIRTSCHAFTSINFORMATIK 3/1998, 205–213 Walter, S. G. / Spitta, T.: Approaches to the Ex-ante Evaluation of Investments into Information Systems. In: WIRTSCHAFTSINFORMATIK 3/2004, 171–180 Informationsmaterial Bundesamt für Sicherheit in der Informationstechnik (BSI) http://www.bsi.de/zertifiz/itkrit/itsec.htm Deutsche Gesellschaft für Evaluation: Standards für Evaluation http://www.degeval.de Europäische Union (Hrsg.): Handbuch für die Bewertung der Sicherheit von Systemen der Informationstechnik (ITSEM), 1997 ITSEM http://www.bsi.de/zertifiz/itkrit/itsem-dt.pdf Normen DIN 66273 Teil 1: Messung und Evaluierung der Leistung von DV-Systemen; Teil 2: Normlast Typ A. 1991 DIN ISO/IEC 15408-2 bzw. ÖNORM ISO/IEC 15408-2: Information technology – Security techniques – Evaluation criteria for IT security – Security functional requirements. 2007 EN 1325-1: Value Management, Wertanalyse, Funktionenanalyse Wörterbuch, Teil 1: Wertanalyse und Funktionenanalyse. 1996 ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality Characteristics and Guidelines for their Use. 2001 ISO/IEC 14598: Information Technology – Software Product Evaluation. 2001 ISO/IEC 15408-1: Information technology – Security techniques – Evaluation criteria for IT security. 2005 ÖNORM A 6757: Wertanalyse-Management: Planung, Durchführung und Controlling der Wertanalyse (WA). 1991

Vorgehensmodelle (VOMOD) Lernziele Sie wissen, für welche Zwecke Vorgehensmodelle verwendet werden. Sie kennen die Bedeutung von Vorgehensmodellen für Entwicklung und Wartung der Informationsinfrastruktur. Sie haben einen Überblick über typische Vorgehensmodelle für die Softwareentwicklung und können erklären, unter welchen Umständen sie sinnvoll eingesetzt werden können.

Definitionen und Abkürzungen agil (agile) = von großer Beweglichkeit zeugend, wendig; Bündel von Eigenschaften einer Klasse von Vorgehensmodellen und Entwicklungstechniken. Substantiv: Agilität. Aktivität (activity) = in sich geschlossene Folge von Tätigkeiten, deren Unterbrechung kein sinnvolles Ergebnis liefert. Synonyme: Arbeitsschritt, Operation. inkrementell (incremental) = schrittweise. Iteration (iteration) = Wiederholung einer bestimmten Folge von Aktivitäten. Konfiguration (configuration) = Menge definierter Elemente eines Systems, die zu einem bestimmten Zeitpunkt gemeinsam eine Aufgabe erfüllen sollen und dazu in Wirkungsweise und Schnittstellen aufeinander abgestimmt sind. Phase (phase) = Gruppierung von Aktivitäten. Phasenmodell (phase model) = systematische Gliederung einer Aufgabe in mehrere aufeinander folgende Phasen, die inhaltlich, technisch und organisatorisch unterscheidbar sind, charakteristische Ziele haben, Methoden erfordern und Ergebnisse erzeugen. PMBOK = Project Management Body of Knowledge; Empfehlungen des Project Management Institutes zum Projektmanagement. Prince2 = PRojects IN Controlled Environments; britischer Projektmanagementstandard. Prozess (process) = Menge von Teilprozessen, Prozess- und Arbeitsschritten, die durch einen Input, interne Funktionen und einen Output gekennzeichnet ist. Release (release) = Version eines Systems, die an den Auftraggeber ausgeliefert wird. RUP = Rational Unified Process. sequenziell (sequential) = aufeinander folgend; der Reihe nach. Scrum = engl. Gedränge, ein agiles Vorgehensmodell. Tailoring = Anpassung (z. B. eines Vorgehensmodells) an die aktuelle Aufgabe. UML = Unified Modeling Language. Validierung (validation) = Prüfung der Tauglichkeit eines Objektes für die vorgesehene Aufgabe. Verifizierung (verification) = Prüfung eines Objektes gegen die Spezifikation. Version (version) = Ausprägung eines Systemelements zu einem bestimmten Zeitpunkt. V-Modell XT = Vorgehensmodell, extreme tailoring; Entwicklungsstandard für IT-Systeme des Bundes (Deutschland). XP = Extreme Programming.

398

Methoden des strategischen Informationsmanagements

Zweck von Vorgehensmodellen Ein Vorgehensmodell ist der als Modell abgebildete Prozess zum Lösen eines Problems. Im Zusammenhang mit IT-Prozessen (vgl. Lerneinheit SEMAN) strukturieren Vorgehensmodelle Entwicklungsvorhaben. Diese werden in der Regel als Projekte organisiert, bei regelmäßig wiederkehrenden Entwicklungen (z. B. Entwicklung von Standardsoftware) sind auch andere Organisationsformen möglich. Ein Vorgehensmodell vereinheitlicht den Arbeitsprozess und soll langfristig möglichst stabil sein, um eine verlässliche Arbeitsgrundlage zu schaffen. Es stellt den Rahmen dar, innerhalb dessen eine Aufgabe organisiert ist. Idealtypisch gesehen ist ein Vorgehensmodell ein standardisierter Prozess, der an die aktuelle Aufgabe (z. B. die Konstruktion von Informationssystemen) angepasst wird. Ein Vorgehensmodell ist i. d. R. nicht monolithisch, sondern besteht aus Teilmodellen, die mehrfach verwendet und miteinander kombiniert werden können. Vorgehensmodelle werden auch als Prozessmodelle bezeichnet, weil sie in der Regel die Abwicklung von Prozessen (z. B. der Softwareentwicklung oder -einführung, der Evaluierung oder Beschaffung von Betriebsmitteln) unterstützen und eine prozessorientierte Ordnung der Tätigkeiten bewirken. Im Sinne des Qualitätsmanagements (vgl. Lerneinheit QUALM) ist die Verwendung eines Vorgehensmodells eine konstruktive QM-Maßnahme, da dadurch die Ausführung bestimmter Tätigkeiten sichergestellt wird. Vorgehensmodelle dienen als Vertragsgrundlage zwischen Auftraggeber und Auftragnehmer und als Arbeitsanleitung für den Auftragnehmer (vgl. Lerneinheit VERMA). Darüber hinaus ist ein Vorgehensmodell Leitfaden für das Projektmanagement, kann als Checkliste verwendet werden und bietet Unterstützung bei der Definition von Qualitätszielen.

Merkmale von Vorgehensmodellen Vorgehensmodelle lassen sich mit folgenden Merkmalen beschreiben: Gegenstandsbereich oder Objekt (z. B. Software- oder Architekturentwicklung), Art der Arbeitsteilung (z. B. produkt- oder verrichtungsorientiert), auszuführende Aktivitäten (z. B. Entwurf, Implementierung, Test), zeitliche Abfolge von Aktivitäten (z. B. sequenziell oder parallel), empfohlene Methoden und gegebenenfalls auch Werkzeuge, erwartete (Zwischen-)Ergebnisse, die durch Aktivitäten erzeugt werden und Voraussetzungen für weitere Aktivitäten sind, sowie den Aktivitäten zugeordnete Rollen (z. B. Projektleiter, Entwickler, Controller) oder Personen (z. B. CIO) bzw. Institutionen (z. B. IT-Lenkungsausschuss).

Kategorisierung von Vorgehensmodellen Vorgehensmodelle wurden zunächst für die Softwareentwicklung konstruiert und publiziert, später auch für andere IT-Aufgaben (z. B. die Entwicklung von IT-Strategien, vgl. Lerneinheit STRAT). Für die Softwareentwicklung unterscheidet Balzert (515 ff.) Basismodelle, monumentale und agile Modelle. Basismodelle skizzieren lediglich grob, welche Aufgaben in welcher Reihenfolge zu bearbeiten sind, nicht aber wie, mit welchen Hilfsmitteln und durch wen. Zu den Basismodellen zählen das Wasserfall-, das V- und das Spiral-Modell sowie die inkrementelle und evolutionäre Entwicklung. Monumentale Modelle werden auch als schwergewichtig bezeichnet, da sie sehr detailliert und umfangreich sind. In ihnen ist

Vorgehensmodelle (VOMOD)

399

nicht nur spezifiziert, welche Aufgaben in welcher Reihenfolge zu bearbeiten sind, sondern auch wie, durch welche Rollen und mit welchen Hilfsmitteln. Zu den monumentalen Modellen zählen das V-Modell XT sowie der RUP. Agile Modelle, die auch als leichtgewichtig bezeichnet werden, sind als Reaktion auf die immer schwerer zu handhabenden monumentalen Modelle entwickelt worden. In diesen Modellen werden keine detaillierten Handlungsanweisungen, sondern Prinzipien und Leitlinien beschrieben. Dabei wird Wert auf eine frühzeitige Entwicklung von Produktteilen, eine intensive Beteiligung von Kunden an der Entwicklung sowie direkte persönliche Kommunikation aller Beteiligten gelegt. Zu den agilen Modellen zählen Crystal Clear, Dynamic Systems Development Method (DSDM), Scrum und XP. Abbildung VOMOD-1 stellt charakteristische Merkmale monumentaler und agiler Vorgehensmodelle gegenüber. Monumentale bzw. schwergewichtige

Agile bzw. leichtgewichtige

Kundenanforderungen stehen zu Entwicklungsbeginn fest und sind detailliert dokumentiert; systematische und umfassende Planung, Steuerung und Kontrolle aller Aktivitäten; detaillierte Handlungsanweisungen; komplex, umfangreich, reichhaltig, aufwendig anzupassen; Verwendung bewährter, erprobter, systematischer Methoden und Werkzeuge; Dokumentation; standardisierte Prozesse; Planerfüllung; Anwendung wird oft als bürokratisch empfunden.

Kundenanforderungen sind zu Entwicklungsbeginn unklar oder unvollständig und verändern sich häufig; Gestaltungsfreiheit und Verantwortung aller Aufgabenträger; Leitlinien und Prinzipien; knapp, flexibel, anpassungsfähig; Verwendung dessen, was sich im Projekt bewährt; Offenheit für Veränderungen; persönliche Kommunikation; funktionsfähige Softwareprodukte; Kundenzufriedenheit; Anwendung soll Spaß machen und Mitarbeiter motivieren.

Abb. VOMOD-1: Charakteristische Merkmale monumentaler und agiler Vorgehensmodelle

Entwicklung von Vorgehensmodellen Die Entwicklung von Vorgehensmodellen erfolgt nicht „auf der grünen Wiese“. Entweder werden Erfahrungen mit einer bestimmten Kategorie von Prozessen dokumentiert und standardisiert oder es werden Referenzmodelle verwendet. Oft geht die Entwicklung von einem Basismodell aus, das für bestimmte Prozesskategorien (z. B. Softwareentwicklung oder -einführung) präzisiert, detailliert und zum Vorgehensmodell weiter entwickelt wird, oder es werden vorhandene Vorgehensmodelle für gleiche oder ähnliche Prozesse – unter Berücksichtigung situativer Bedingungen und einschlägiger Standards – angepasst (z. B. das für

400

Methoden des strategischen Informationsmanagements

Bundesbehörden in Deutschland entwickelte V-Modell XT an die Bedingungen bestimmter Wirtschaftszweige oder einzelner Unternehmen).

Aufgabentypen in Vorgehensmodellen Die in Vorgehensmodellen beschriebenen Aufgaben sind Management-, Entwicklungs- und Unterstützungsaufgaben.

Managementaufgaben Zur Initiierung eines Entwicklungsvorhabens gehört die Ist-Analyse, d. h. die Untersuchung von Stärken und Schwächen des Status quo, die Beschreibung der zu lösenden Probleme, die Formulierung von Erwartungen an das Entwicklungsergebnis und eine grobe Definition von Zielen, ferner eine Machbarkeitsstudie, in der die technische Umsetzbarkeit geprüft wird, und eine Wirtschaftlichkeitsanalyse (vgl. Lerneinheit WIRTA), gegebenenfalls Ausschreibung und Lieferantenauswahl (vgl. Lerneinheit TECHM) sowie die Erteilung eines Entwicklungsauftrags. Die Planung umfasst die detaillierte Definition der Ziele, Aufwandsschätzung, Zeit- und Terminplanung, Klärung von Rollen und Verantwortungsbereichen, Definition der Aufbau- und Ablaufstruktur, Evaluierung und Auswahl von Methoden und Werkzeugen (vgl. Lerneinheit EVALU) sowie die Festlegung und Dokumentation aller notwendigen Aktivitäten. Zur Steuerung und Kontrolle gehören Überprüfung der Zielerreichung (Sachfortschrittskontrolle), Kosten- und Terminabweichungsanalysen, gegebenenfalls Abstimmung mit anderen Vorhaben, Konfliktlösung, Pflege der Kommunikation zwischen Auftraggeber und Auftragnehmer, Koordination der Beziehungen zu Lieferanten und Kooperationspartnern. Den Abschluss eines Vorhabens bilden die Abnahme der Ergebnisse durch den Auftraggeber, eine Nachkalkulation sowie gegebenenfalls Kosten- und Terminabweichungsanalysen, eine Post-Mortem-Analyse (vgl. Lerneinheit MEWIM) sowie die Auflösung des Projekts.

Entwicklungs- und Unterstützungsaufgaben Zu den Entwicklungsaufgaben gehören Anforderungsmanagement, fachlicher und systemtechnischer Entwurf, Implementierung und Integration der Systemelemente sowie Wartung. Unterstützungsaufgaben umfassen Projektmanagement, Qualitätsmanagement (vgl. Lerneinheiten QUALM und MEQUA), Veränderungsmanagement, Dokumentation des Vorgehens und der erzielten Ergebnisse, Beschaffungsmanagement (Auswahl von Lieferanten, Vertragsgestaltung, Überprüfung und Steuerung der Lieferantenbeziehungen) sowie das Konfigurationsmanagement. (Vgl. zu einer detaillierten Darstellung der Entwicklungs- und Unterstützungsaufgaben Balzert.)

Vorgehensmodelle für die Softwareentwicklung In den folgenden Abschnitten werden Vorgehensmodelle für die Softwareentwicklung beschrieben. Grafische Darstellungen dieser Vorgehensmodelle finden sich auf http://www.informationsmanagement-buch.org.

Vorgehensmodelle (VOMOD)

401

Wasserfallmodell Das Wasserfallmodell gliedert die Softwareentwicklung verrichtungsorientiert in sequenziell zu bearbeitende Phasen, bei denen keine Rücksprünge in vorhergehende Phasen vorgesehen sind. Dieses Vorgehensmodell wurde von Boehm (1981) unter Verweis auf Royce als Wasserfallmodell bezeichnet, obwohl Royce diesen Begriff nicht verwendet und obwohl er bereits 1970 darauf aufmerksam gemacht hat, dass dieses Vorgehen für die meisten Softwareentwicklungsvorhaben ungeeignet ist. Das Wasserfallmodell dient nicht in erster Linie als Referenzmodell für die Softwareentwicklung, sondern als Archetyp, mit dem Eigenschaften anderer Vorgehensmodelle verdeutlicht und verglichen werden können. Boehm (1981, 36) gliedert das Wasserfallmodell in die Phasen Machbarkeitsstudie, Anforderungsanalyse, Grobentwurf, Feinentwurf, Codierung, Integration, Implementierung sowie Betrieb und Wartung. Das Wasserfallmodell beruht auf folgenden Grundgedanken. Zu Beginn jeder Phase sind die Anforderungen umfassend bestimmt. Jede Phase wird mit einer Dokumentation abgeschlossen, die im Sinne des Pflichtenhefts bzw. der Entwicklungsziele als vollständig gelten kann. Zum Abschluss einer Phase werden die Ergebnisse verifiziert und validiert. Das Wasserfallmodell eignet sich für Entwicklungsvorhaben, in denen sich die Anforderungen an das zu entwickelnde Produkt nur unwesentlich verändern und bei denen hoher Wert auf eine vollständige Dokumentation aller Entwicklungsschritte und -ergebnisse gelegt wird.

V-Modell Das V-Modell wurde 1979 von Boehm entwickelt, um die Bedeutung von Verifizierung und Validierung zu verdeutlichen. Die Bezeichnung V-Modell beruht auf der V-förmigen Anordnung der Phasen in der grafischen Darstellung dieses Modells. Sie darf nicht mit der zum Teil verwendeten Abkürzung für Vorgehensmodell verwechselt werden. Im V-Modell wird jeder Phase, die auf die Konstruktion eines Zwischenergebnisses ausgerichtet ist, eine andere Phase gegenübergestellt, die der Qualitätsprüfung (vgl. Lerneinheit QUALM) dient. Der linke Teil des V umfasst Konzeption, Anforderungsanalyse, Grobentwurf, Feinentwurf und Codierung, der rechte Teil Modultest, Integrationstest, Systemtest, Abnahmetest und Betrieb.

Spiralmodell Bei dem von Boehm (1988) in Form einer Spirale dargestellten Vorgehen werden vier Phasen mehrfach nacheinander durchlaufen. 1. 2. 3.

Entwicklungsdeterminanten: Bestimmung von Zielen für das nächste Zwischenergebnis, Erörterung alternativer Lösungsmöglichkeiten und Klärung von Randbedingungen, die einzuhalten sind. Entwicklungsrisiken: Bewertung der Alternativen im Hinblick auf die Entwicklungsziele und Rahmenbedingungen, Identifizierung von Risiken und Klärung von Möglichkeiten zur Risikoreduzierung. Entwicklungsdurchführung: Entwicklung und Verifizierung von (Zwischen-) Ergebnissen.

402

4.

Methoden des strategischen Informationsmanagements

Entwicklungsplanung: Planung des nächsten Spiraldurchlaufs einschließlich Form der Arbeitsteilung und der Vorgehensweise.

Jede neue „Runde“ baut auf den Ergebnissen und Erfahrungen des vorhergehenden Spiraldurchlaufs auf. Zu Beginn einer Entwicklung wird nicht das gesamte Vorgehen festgelegt, sondern nur die erste Runde. Der genaue Ablauf einer Entwicklung orientiert sich an den wirtschaftlichen und technischen Risiken. Zunächst werden die Teilaufgaben bearbeitet, welche die größten Risiken bergen, anschließend die weniger risikoreichen. Die Arbeitsteilung kann entweder produkt- oder verrichtungsorientiert erfolgen. Wenn Risiken oder veränderte Rahmenbedingungen es nahe legen, kann die Form der Arbeitsteilung nach jedem Spiraldurchlauf verändert werden. Das Spiralmodell kann mit anderen Vorgehensmodellen kombiniert werden, z. B. indem die Runden mit verschiedenen Vorgehensmodellen strukturiert werden. Das Spiralmodell eignet sich für neuartige, risikoreiche Entwicklungsvorhaben, bei denen auf keine Erfahrungen aus vergleichbaren Projekten zurückgegriffen werden kann. Die Anwendung ermöglicht eine große Flexibilität, erfordert aber auch einen hohen Planungs-, Kontroll- und Steuerungsaufwand.

Inkrementelle und evolutionäre Entwicklung Bei der inkrementellen und evolutionären Entwicklung erfolgt die Arbeitsteilung nicht primär verrichtungsorientiert, wie z. B. beim Wasserfallmodell, sondern produktorientiert. D. h., dass einzelne Teile des Produktes sequenziell entwickelt werden. Typische Entwicklungsaufgaben, wie Anforderungsanalyse, Entwurf, Implementierung und Integration, werden dabei nicht sequenziell für das gesamte Produkt, sondern jeweils für einzelne Komponenten des Produktes durchgeführt. Der Vorteil liegt darin, dass der Auftraggeber bereits frühzeitig Erfahrungen mit funktionsfähigen Komponenten des Produktes sammeln kann, die dem Auftragnehmer Hinweise für die Entwicklung weiterer Produktkomponenten geben. Bei der inkrementellen Entwicklung unterscheidet Balzert den Aufbau aus Teilprodukten und den schalenförmigen Aufbau. Im ersten Fall wird das Produkt „analog wie Legobausteine oder Puzzleteile“ (526) schrittweise entwickelt und zu einem Gesamtprodukt zusammengesetzt. Im zweiten Fall wird zunächst ein Produktkern entwickelt, dem schalenförmig neue Funktionen hinzugefügt werden. Voraussetzung für diese Art der Entwicklung ist, dass der Auftraggeber frühzeitig weitgehend vollständige Anforderungen beschreibt, die es erlauben, eine Softwarearchitektur (vgl. Lerneinheit ARCHI) zu definieren. Bei der evolutionären Entwicklung beschreiben die Kundenanforderungen, die auf jeden Fall umgesetzt werden müssen, den Produktkern. Dieser wird vollständig entwickelt und dem Kunden zur Verfügung gestellt. Die Erfahrungen, die der Kunde damit macht, bilden die Grundlage für Anforderungen an erweiterte Versionen. Durch diese Vorgehensweise wird das Risiko von Fehlentwicklungen reduziert und der Kunde kann bereits wichtige Teile des Produktes nutzen, während weitere Funktionen implementiert werden. Steht die Produktarchitektur relativ früh fest (z. B. bei neuen Versionen von bereits etablierten Standardprodukten), ist diese Art der Entwicklung gut geeignet. Problematisch ist dieses Vorgehensmodell, wenn damit gerechnet werden muss, dass die Eignung der Produktarchitektur erst relativ spät überprüft werden kann und diese eventuell grundlegend verändert werden muss.

Vorgehensmodelle (VOMOD)

403

V-Modell XT Das V-Modell XT ist der Entwicklungsstandard für IT-Systeme der deutschen Bundesbehörden. Vorläuferversionen des Modells wurden für den Verteidigungsbereich entwickelt, 1992 erstmals publiziert und in überarbeiteter Form 1997 unter der Bezeichnung V-Modell 97 veröffentlicht. Die folgenden Ausführungen beziehen sich auf die 2008 publizierte Version 1.3 des V-Modells XT. Die Dokumentation dieser Version umfasst mehr als 800 Seiten. Es werden folgende Projekttypen unterschieden: Systementwicklungsprojekte aus Sicht des Auftraggebers, Systementwicklungsprojekte aus Sicht des Auftragnehmers sowie Einführung und Pflege organisationsspezifischer Vorgehensmodelle. Außerdem werden Projekte anhand von fünf verschiedenen Projektgegenständen unterschieden: Hardwaresystem, Softwaresystem, Hardware- und Softwaresystem/eingebettetes System, Systemintegration sowie Vorgehensmodell. Für jeden Projekttyp wird festgelegt, welche Vorgehensbausteine eingesetzt werden müssen und welche zusätzlich ausgewählt werden können. Vorgehensbausteine sind Teilaufgaben, für die Produkte, Aktivitäten und Rollen festgelegt sind. Im V-Modell XT werden 21 Vorgehensbausteine beschrieben, die in vier Bereiche eingeteilt sind:   



Der V-Modell-Kern umfasst die Bausteine Projektmanagement, Qualitätssicherung, Konfigurationsmanagement sowie Problem- und Änderungsmanagement. Kaufmännisches Projektmanagement sowie Messung und Analyse können ergänzt werden. Der Vorgehensbaustein Einführung und Pflege eines organisationsspezifischen Vorgehensmodells gibt Leitlinien für die Einführung eines Vorgehensmodells und dessen kontinuierliche Verbesserung (vgl. Lerneinheit QUALM). In einem dritten Bereich sind alle Vorgehensbausteine beschrieben, die für die Entwicklung eines Systems benötigt werden: Anforderungsfestlegung, Systemerstellung, Hardwareentwicklung, Softwareentwicklung, Logistikkonzeption, Weiterentwicklung und Migration von Altsystemen, Evaluierung von Fertigprodukten, Benutzbarkeit und Ergonomie, Sicherheit und Multiprojektmanagement. Der vierte Bereich umfasst Bausteine, die für die Kommunikation zwischen Auftraggeber und Auftragnehmer benötigt werden: Lieferung und Abnahme sowie Vertragsschluss, jeweils differenziert für Auftragnehmer und Auftraggeber.

Obwohl das V-Modell XT für deutsche Bundesbehörden entwickelt wurde, setzen auch Unternehmen dieses Modell ein. Es eignet sich insbesondere dann, wenn für ein Entwicklungsvorhaben sehr detaillierte Vorgaben gewünscht werden, wenn der Entwicklungsprozess, die Produkte und Zwischenprodukte intensiv dokumentiert werden sollen und für Entwicklung und Darstellung der Produktarchitektur (vgl. Lerneinheit ARCHI) auf andere Hilfsmittel zurückgegriffen werden kann.

Rational Unified Process (RUP) Der Rational Unified Process wurde für die objektorientierte Softwareentwicklung von Mitarbeitern des Unternehmens Rational Software entwickelt, das seit 2003 zu IBM gehört. Es wurde von Kruchten in einer Vorgängerversion publiziert und durch die Arbeiten von Jacobson/Booch/Rumbaugh beeinflusst, die auch die UML maßgeblich geprägt haben. Für den RUP gibt es verschiedene Erweiterungen für bestimmte System- und Architekturtypen und als Kombination mit anderen Vorgehensmodellen (z. B. mit XP, vgl. folgenden Abschnitt).

404

Methoden des strategischen Informationsmanagements

Der RUP ist durch ein inkrementelles, iteratives Vorgehen geprägt, in dessen frühen Phasen eine funktionsfähige Systemarchitektur (vgl. Lerneinheit ARCHI) entworfen wird. Im RUP werden Aktivitäten, Arbeitsergebnisse, Arbeitsabläufe und Rollen beschrieben. Das Vorgehensmodell wird mit zwei Dimensionen strukturiert.  

Auf der horizontalen Achse werden vier Phasen unterschieden: Konzeption (inception), Ausarbeitung (elaboration), Konstruktion (construction) und Überleitung (transition). Jede Phase kann in mehreren Iterationen durchlaufen werden. Die vertikale Achse unterscheidet neun Disziplinen: die Kernaufgaben Geschäftsprozessmodellierung (business modeling), Anforderungsanalyse (requirements), Analyse und Entwurf (analysis & design), Implementierung (implementation), Test (test) und Auslieferung (deployment) sowie die Unterstützungsaufgaben Konfigurations- und Änderungsmanagement (configuration & change management), Projektmanagement (project management) und Entwicklungsumgebung (environment).

Der RUP ist weit verbreitet. Gründe dafür sind die enge Verbindung zur UML, die hohe Flexibilität, Kombinationsmöglichkeiten mit anderen Vorgehensmodellen sowie umfangreiche Literatur und vielfältige Anwendungserfahrungen. Er eignet sich sehr gut für objektorientierte Softwareentwicklung sowie Wartung von Individualsoftware.

Extreme Programming (XP) Extreme Programming (XP) beschreibt ein flexibles Vorgehen der inkrementellen Softwareentwicklung. Dabei wird frühzeitig ein funktionsfähiges (Teil-)Produkt implementiert, welches in kleinen Schritten und in intensiver Abstimmung mit dem Kunden erweitert wird. Die Bezeichnung extrem deutet darauf hin, dass XP zwar auf einigen bewährten und bereits seit langem bekannten Prinzipien und Methoden beruht, die aber radikal umgesetzt werden. Es gibt keine einheitliche oder verbindliche Definition von XP. Die ersten Publikationen stammen von Beck (1999 und 2000). Im Jahr 2004 wurde XP in einer überarbeiteten Form publiziert (Beck/Andres), die auch als XP 2 bezeichnet wird. Das Vorgehensmodell wird darin mit Werten, Prinzipien und Praktiken beschrieben. Die Werte von XP sind: Informationen werden durch persönliche Kommunikation der Beteiligten unter weitgehendem Verzicht auf schriftliche Dokumentation ausgetauscht. Für jedes Problem wird die einfachste praktikable Lösung umgesetzt. Die Arbeit wird mit Hilfe von Rückkopplungsmechanismen, z. B. Tests nach Entwicklungsarbeiten oder Aufwandsschätzungen bei veränderten Kundenanforderungen, so organisiert, dass Fehler schnell entdeckt und Konsequenzen von Entscheidungen rasch offensichtlich werden. Alle Beteiligten haben den Mut, Fehler zu machen und Probleme offen anzusprechen. Die Arbeit ist durch einen respektvollen Umgang miteinander geprägt. XP beruht auf folgenden Prinzipien: Menschen stehen im Mittelpunkt. Bedürfnisse der Teammitglieder müssen in Einklang mit den wirtschaftlichen Zielen von Entwicklungsvorhaben gebracht werden. Die Verschiedenartigkeit der Teammitglieder und der Lösungsmöglichkeiten wird als Chance verstanden, unterschiedliche Sichtweisen zu entwickeln und zu prüfen. Alle Projektbeteiligten reflektieren die eigene Arbeitsweise und prüfen Verbesserungsmöglichkeiten. Jeder Mitarbeiter trägt Verantwortung für das gesamte Entwicklungs-

Vorgehensmodelle (VOMOD)

405

vorhaben. Wer die Realisierung bestimmter Kundenanforderungen übernimmt, ist auch für Entwurf, Programmierung und Test der entsprechenden Funktionen des Produkts verantwortlich. Fehler lassen sich nicht vermeiden; sie werden als Chancen für Verbesserungen wahrgenommen. Alles wird kontinuierlich verbessert. Veränderungen am Produkt und am Prozess werden in kleinen Schritten durchgeführt; dadurch sinkt das Risiko von Fehlschlägen. Jedes Produktmerkmal muss Nutzen stiften, der die Entwicklungskosten übersteigt. Projekte, die nicht wirtschaftlich sind, werden als Misserfolg betrachtet. Projektergebnisse müssen Kunden und Entwickler zufrieden stellen. Kostensenkung und schnellere Entwicklung können nicht durch Abstriche bei der Qualität erreicht werden. Qualitativ hochwertige Software ist mittelfristig kostengünstiger als eine „Quick-and-dirty-Lösung“. Es wird grundsätzlich geprüft, ob bereits gefundene Lösungen wiederverwendet werden können. Das Produkt soll möglichst redundanzfrei sein, im Entwicklungsprozess soll es aber Redundanzen geben, um eventuell auftretende Probleme besser bewältigen zu können. Die wichtigsten Praktiken des XP sind: Alle Projektmitglieder arbeiten räumlich eng zusammen, im Idealfall in einem Raum. Das Projektteam ist so zusammengesetzt, dass notwendiges fachliches und technisches Wissen verfügbar ist. Alle Teammitglieder werden laufend über den aktuellen Stand des Entwicklungsvorhabens informiert (z. B. auf Postern und Pinnwänden). Die Arbeitsumgebung wird so gestaltet, dass die Mitarbeiter ihre Aufgaben engagiert, motiviert und gleichzeitig entspannt bewältigen können. Überstunden werden möglichst vermieden. Entwicklungsarbeiten werden grundsätzlich von zwei Personen gemeinsam ausgeführt. Anforderungen werden in Form von kurzen Geschichten formuliert. Der Aufwand zur Implementierung der Anforderungen wird mit dem Kunden abgestimmt. Das Projekt wird wöchentlich geplant. Jede Woche wird neu entschieden, welche Kundenanforderungen als nächstes implementiert werden. Das Projekt wird in Viertel eingeteilt, geplant, gesteuert und überwacht. Es werden nur solche Aufgaben begonnen, von denen die Teammitglieder annehmen, sie erfolgreich bewältigen zu können. Die Entwicklungsumgebung wird so gestaltet, dass Produktelemente innerhalb von zehn Minuten integriert und automatisch getestet werden können. Neue oder veränderte Produktelemente werden häufig, spätestens nach einigen Stunden integriert. Testfälle werden vor der Programmierung erstellt. Der Systementwurf erfolgt inkrementell und wird kontinuierlich verbessert. XP eignet sich für kleinere Projekte, bei denen die Auftraggeber ihre Anforderungen zu Entwicklungsbeginn nicht umfassend beschreiben können, wenn zu erwarten ist, dass sich die Anforderungen und die Prioritäten während der Entwicklung verändern oder wenn der Entwicklungsaufwand nicht ausreichend genau geschätzt werden kann (z. B. weil neue Entwicklungsumgebungen verwendet werden). Die Verwendung von XP setzt voraus, dass der Kunde bereit ist, intensiv an der Entwicklung mitzuwirken und akzeptiert, dass erst während des Entwicklungsvorhabens festgelegt wird, welche Funktionen implementiert werden.

Vorgehensmodelle für andere Aufgaben In den beiden folgenden Abschnitten werden – wegen der Bedeutung für die Unternehmenspraxis – Vorgehensmodelle für das Architekturmanagement und das Projektmanagement exemplarisch dargestellt. Auf der Website dieses Lehr- und Handbuchs wird ein Demonstrationsbeispiel zur Entwicklung von IT-Strategien gezeigt.

406

Methoden des strategischen Informationsmanagements

Architekturmanagement Hafner/Winter entwickelten ein Vorgehensmodell für das Management von Anwendungsarchitekturen. Empirische Grundlage dafür waren drei Fallstudien bei Finanzdienstleistungsunternehmen. Mit Interviews und Dokumentenanalysen wurden verwendete Vorgehensmodelle erhoben, um daraus ein konsolidiertes Vorgehensmodell abzuleiten. Die Autoren gliedern die Aufgaben des Architekturmanagements in folgende Bereiche: Architekturführung bezeichnet die Ermittlung strategischer Anforderungen an und die Evaluierung von Architekturen sowie die Entwicklung von Architekturprinzipien (vgl. Lerneinheit ARCHI). Architekturentwicklung umfasst die Entwicklung und Integration von Artefakten sowie die Abstimmung der Architektur mit allen IT-Belangen. Architekturkommunikation beschäftigt sich mit Information und Schulung relevanter Zielgruppen für die Architektur. Architekturvertretung bezeichnet die Beratung und Unterstützung von IT-Projekten in Architekturfragen. Das Vorgehensmodell TOGAF der Open Group zur Entwicklung von Architekturen wird in der Lerneinheit ARCHI erörtert.

Projektmanagement Im PMBOK des Project Management Institutes werden fünf Projektphasen (Basic Process Groups: Initiating, Planning, Executing, Controlling und Closing) und neun Aufgabengebiete (Knowledge Areas: Scope Management, Time Management, Human Resource Management, Cost Management, Procurement Management, Communications Management, Risk Management, Quality Management und Integration Management) beschrieben. Das Vorgehensmodell in Prince2 gliedert ein Projekt in vier Phasen (Starting a Project, Initiating a Project, Implementation, Closing a Project), die in acht Projektmanagementphasen (Processes: Starting up a Project, Planning, Initiating a Project, Directing a Project, Controlling a Stage, Managing Product Delivery, Managing Stage Boundaries und Closing a Project) bearbeitet warden. Die Phasen sind in 45 Teilprozessen (Sub-Processes) spezifiziert. Zusätzlich werden die Aufgaben Wirtschaftlichkeitsanalyse, Organisation, Planung, Kontrolle, Risiko- und Qualitätsmanagement, Konfigurationsmanagement und Änderungsmanagement erläutert.

Forschungsbefunde Guntamukkala/Wen/Tarn untersuchten Präferenzen von Projektmanagern und Softwareentwicklern zu Vorgehensmodellen im Hinblick auf die Flexibilität der Entwicklung (OnlineBefragung von 400 Projektmanagern und Softwareentwicklern in Nordamerika, die bereits Vorgehensmodelle ausgewählt haben, 74 auswertbare Antworten, Untersuchungszeitraum nicht angegeben). Die Autoren teilen Vorgehensmodelle in drei Klassen ein: schwergewichtige (Wasserfall- und V-Modelle), mittelgewichtige (inkrementelle Modelle und Spiralmodelle) sowie leichtgewichtige (XP und Scrum). Schwergewichtige Vorgehensmodelle werden bevorzugt, wenn Kundenanforderungen zu Entwicklungsbeginn gut verstanden und häufige Wartungsarbeiten zu erwarten sind. Leichtgewichtige Vorgehensmodell werden gewählt, wenn Anforderungen sich häufig ändern, der Produktumfang nur schlecht abgegrenzt, die Produktarchitektur aber klar strukturiert ist, wenn Endbenutzer im Hinblick auf neue Technologien anspruchsvoll, die Entwicklungsteams klein, Risiken und zeitliche Restriktionen

Vorgehensmodelle (VOMOD)

407

unklar, verwendete Technologien neu, Meilensteine nicht klar definiert sind und die Entwicklungsumgebung zu Projektbeginn nicht vollständig verfügbar ist.

Aus der Praxis Joecks berichtet über die kombinierte Anwendung eines monumentalen und eines agilen Vorgehensmodells in einem Softwareentwicklungsprojekt. Auftraggeber des Projekts, in dem eine komplexe Aufgabe durch eine serviceorientierte Architektur unterstützt werden sollte, war eine deutsche Behörde. Deshalb musste der Entwicklungsprozess mit dem VModell XT strukturiert werden. Die fachlichen Anforderungen wurden durch eine Fachabteilung der Behörde beschrieben, die bei Entwicklungsbeginn nur teilweise bekannt und dokumentiert waren. Die Mitarbeiter der Fachabteilung verfügten über keine IT-Kenntnisse und waren zuvor auch noch nie an einem Softwareentwicklungsprojekt beteiligt. Es stellte sich heraus, dass eine Anpassung des V-Modells XT, z. B. auf Basis der „Projektdurchführungsstrategie agile Systementwicklung“, allein nicht ausreichend gewesen wäre. Erforderlich war vielmehr eine intensive Beteiligung von Mitarbeitern der Fachabteilung an den Entwicklungsaufgaben in Kombination mit einer permanenten Fortschrittskontrolle und einer Flexibilisierung der Projektphasen (z. B. keine zeitliche Trennung von Konzeption, Implementierung und Test). Um dies zu realisieren, wurde das Vorgehen durch folgende Elemente von Scrum modifiziert: Implementierung von Systemelementen bereits während der Konzeption des Gesamtsystems, Parallelisierung der Entwicklung in verschiedenen Teams, Priorisierung von Anforderungen durch die Fachvertreter zu Beginn jeder Entwicklungsphase, Entwicklung von Testfällen vor der Implementierung von Softwarekomponenten, kurze Entwicklungsphasen mit einer Dauer von höchstens 3 Wochen sowie kontinuierliche Integration von implementierten Produktelementen. Der Autor nennt als wesentlichen Vorteil dieser Vorgehensweise die Motivation der Mitarbeiter der Fachabteilung. Aufgabenverweise Architekturmanagement (Lerneinheit ARCHI); Strategieentwicklung (Lerneinheit STRAT); Lebenszyklusmanagement (Lerneinheit LEMAN). Kontrollfragen 1. Welche Kategorien von Vorgehensmodellen werden unterschieden und welche Eigenschaften haben sie? 2. Welche Aufgabentypen werden in Vorgehensmodellen beschrieben? 3. Wodurch zeichnen sich agile Vorgehensmodelle aus? 4. Wie lässt sich folgende These begründen? „Je schlechter die Zeiten, desto leichter die Vorgehensmodelle.“ 5. Worin besteht der Unterschied zwischen einem Vorgehensmodell und einem Reifegradmodell? Quellen Balzert, H.: Lehrbuch der Softwaretechnik: Softwaremanagement. 2. A., Heidelberg 2008 Beck, K. / Andres, C.: Extreme Programming Explained: Embrace Change. 2. A., Reading 2004 Beck, K.: Embracing Change with Extreme Programming. In: Computer 10/1999, 70–79 Beck, K.: Extreme Programming Explained: Embrace Change. Reading 2000 Boehm, B. W.: A Spiral Model of Software Development and Enhancement. In: IEEE Computer 5/1988, 61–72 Boehm, B. W.: Guidelines for Verifying and Validating Software Requirements and Design Specifications. In: Samet, P. A. (Hrsg.): EURO IFIP: Proceedings of the European Conference on Applied Information Technology. Amsterdam et al. 1979, 711–719 Boehm, B. W.: Software Engineering Economics. Englewood Cliffs 1981 Guntamukkala, V. / Wen, H. J. / Tarn, J. M.: An Empirical Study of Selecting Software Development Life Cycle Models. In: Human Systems Management 4/2006, 265–278

408

Methoden des strategischen Informationsmanagements

Hafner, M. / Winter, R.: Vorgehensmodell für das Management der unternehmensweiten Applikationsarchitektur. In: Ferstl, O. K. et al. (Hrsg.): Wirtschaftsinformatik 2005. eEconomy, eGovernment, eSociety. Heidelberg 2005, 627–646 Jacobson, I. / Booch, G. / Rumbaugh, J.: The unified software development process. Amsterdam 1999 Joecks, F.: Kurzbericht: SCRUM & V-Modell XT in einem Projekt. München 2010; http://www.bpm-soacenter.com Abruf 28. Juni 2011 o. V.: V-Modell XT Version 1.3 Berlin 2008 Kruchten, P.: The Rational Unified Process. An Introduction. 3. A., Amsterdam 2004 Office of Government Commerce: Managing Successful Projects with PRINCE2. London 2005 Project Management Institute: A Guide to the Project Management Body of Knowledge: PMBOK Guide. 4. A., Newton Square 2010 Royce, W.: Managing the Development of Large Software Systems. In: Proceedings, IEEE WESCON August/1970, 1–9 Vertiefungsliteratur Becker, J. / Knackstedt, R. / Pöppelbuß, J.: Entwicklung von Reifegradmodellen für das IT-Management - Vorgehensmodell und praktische Anwendung. In: WIRTSCHAFTSINFORMATIK 3/2009, 249–260 Cockburn, A.: Crystal Clear: A Human-Powered Methodology for Small Teams. Amsterdam 2004 Hruschka, P.: Agility. (Rück)-Besinnung auf Grundwerte in der Softwareentwicklung. In: Informatik Spektrum 6/2003, 397–401 Kneuper, R. / Wiemers (Hrsg.), M.: Leichte Vorgehensmodelle. 8. Workshop der Fachgruppe 5.11 der Gesellschaft für Informatik e. V. (GI). Aachen 2001 Langer, P. et al.: Vorgehensmodelle für die Entwicklung hybrider Produkte – eine Vergleichsanalyse. In: Schumann, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2010. Göttingen 2010, 2043–2056 Padberg, F. / Tichy, W.: Schlanke Produktionsweisen in der modernen Softwareentwicklung. In: WIRTSCHAFTSINFORMATIK 3/2007, 162–170 Rausch, A. / Broy, M.: Das V-Modell XT: Grundlagen, Erfahrungen und Werkzeuge. Heidelberg 2008 Schwaber, K. / Beedle, M.: Agile Software Development with Scrum. Upper Saddle River 2001 Thomas, O. / Leyking, K. / Scheid, M.: Serviceorientierte Vorgehensmodelle: Überblick, Klassifikation und Vergleich. In: Informatik-Spektrum 4/2010, 363–379 Versteegen, G.: Projektmanagement mit dem Rational Unified Process. Berlin et al. 2000 Informationsmaterial Beck, K. et al.: Manifesto for Agile Software Development http://www.agilemanifesto.org Dynamic Systems Development Method (DSDM) Consortium http://www.dsdm.org Fachgruppe Vorgehensmodelle für die betriebliche Anwendungsentwicklung der Gesellschaft für Informatik http://www.vorgehensmodelle.de oder http://wi-vm.gi-ev.de Interessenvertretung der Anwender des Systementwicklungsstandards V-Modell ANSSTAND e. V. (Deutschland) http://www.ansstand.de Rational Software Process – Website von IBM http://www-01.ibm.com/software/awdtools/rup V-Modell XT Portal http://www.v-modell-xt.de Normen IEEE 1074-2006: IEEE Standard for Developing a Software Project Life Cycle Process ISO 10007:2003: Quality management systems - Guidelines for configuration management ISO/IEC 12207:2008: Systems and software engineering - Software life cycle processes ISO/IEC 15288:2008: Systems and software engineering - System life cycle processes

Szenariotechnik (SZENA) Lernziele Sie können den Zweck der Szenariotechnik erläutern. Sie kennen den Unterschied zwischen der Szenariotechnik und anderen Prognoseverfahren. Sie wissen, was ein Szenario ist und können eine in acht Arbeitsschritte gegliederte Vorgehensweise für die Anwendung der Szenariotechnik angeben. Sie erkennen, wie mit Hilfe der Szenariotechnik Information für Entscheidungen des Informationsmanagements generiert werden kann.

Definitionen und Abkürzungen Alternativstrategie (alternative strategy) = Strategie, welche die aus einem Szenario abgeleiteten Aussagen enthält, die nicht in die den Szenarien gemeinsame Leitstrategie integriert werden können. Deskriptor (descriptor) = Größe, mit der ein Einflussfaktor wertneutral zur Kennzeichnung des Istzustands und des zukünftigen Zustands einer Entwicklung beschrieben wird. Dialektik (dialectic) = schlüssige Darstellung kontrovers diskutierter Themen durch These und Antithese mit anschließender Synthese (Konklusion). Extrem-Szenario (extreme scenario) = Szenario, das am Rand des Szenario-Trichters liegt. Leitstrategie (mission strategy) = Strategie, die unter den Rahmenbedingungen der betrachteten Szenarien erfolgreich verfolgt werden kann. Prognose (forecast) = Voraussage oder Vorhersage einer zukünftigen Entwicklung oder eines zukünftigen Zustands auf der Grundlage systematisch ermittelter Daten und der Verwendung wissenschaftlicher Erkenntnisse. Störereignis (disturbance event) = Ereignis, das zu einer unerwünschten Veränderung der Entwicklung und damit zu einem anderen als dem ursprünglich angestrebten Szenario führt. Strategie (strategy) = langfristig und unternehmensweit angelegte Verhaltens- und Verfahrensweise zum Aufbau und Erhalt von Erfolgspotenzial. Systemgrid (system grid) = zweidimensionales Raster mit in der Regel zwei oder drei Ausprägungen je Dimension zur Ordnung von Objekten. Systemtheorie (system theory) = Wissenschaftsdisziplin, die allgemeingültige Gesetze über Zustände und Verhalten von Systemen erarbeitet. Szenario (scenario) = Darstellung eines möglichen zukünftigen Zustands eines Systems als Ergebnis der Anwendung der Szenariotechnik (von griech. Skene = Schauplatz einer Handlung, eine Szenenfolge). Synonym: Zukunftsbild. Szenario-Archetyp (scenario archetype) = jedes der (in der Regel) beiden in sich konsistenten, stabilen und disjunkten Szenarien, aus denen die Leitstrategie abgeleitet wird. Szenario-Trichter (scenario cone) = grafische Darstellung mehrerer möglicher Abläufe, die zwischen der Gegenwart und der Zukunft liegen, sowie zukünftiger Zustände zwischen zwei Extrem-Szenarien unter dem Einfluss von Störereignissen und von Maßnahmen. Trend-Szenario (trend scenario) = Szenario, das sich durch Trend-Extrapolation aus dem Istzustand (Null-Szenario) ergibt; es liegt im Mittelpunkt des Szenario-Trichters.

410

Methoden des strategischen Informationsmanagements

Zweck der Szenariotechnik Zweck der Anwendung der Szenariotechnik, auch als Szenariomethode bezeichnet, ist die Gewinnung von Information über mögliche zukünftige Situationen (Szenarien) offener Systeme. Für das Informationsmanagement geht es primär um methodische Unterstützung bei der Lösung folgender Aufgaben:  

    

Generieren von alternativen Strategien (z. B. IT-Strategie) oder von Teilstrategien (z. B. Nachhaltigkeitsstrategie, vgl. Lerneinheit STRAT), Abschätzen, mit welchen Situationen in Zukunft zu rechnen ist und welche Auswirkungen diese auf Informationsfunktion und Informationsinfrastruktur haben können (z. B. Bedrohungen der Informationsinfrastruktur und deren Auswirkungen, vgl. Lerneinheiten NOMAN und INMAN), Analysieren der Stärken und Schwächen des Istzustands, beispielsweise in Ergänzung zu einer Stärken-Schwächen-Analyse (vgl. Lerneinheit SITAN), Überprüfen von strategischen Zielsystemen und Leitbildern (vgl. Lerneinheit SZIEL), Evaluieren von strategischen Maßnahmen (vgl. Lerneinheiten SPLAN und EVALU), Entwerfen von grundlegenden Konzepten (z. B. Sicherheitskonzept, vgl. Lerneinheit SIKON) und Erkennen von Entwicklungen mit starkem Einfluss auf die Informationsinfrastruktur (z. B. Technologieentwicklung, vgl. Lerneinheit TECHM).

Für die strategische IT-Planung, insbesondere für die Maßnahmenplanung, ist es erforderlich, alternative Entwicklungen, qualitative Veränderungen, Wendepunkte und Strukturbrüche, insgesamt also den möglichen, strategisch bedeutsamen Wandel der Informationsinfrastruktur im Rahmen ihrer Umweltbedingungen (vor allem unter Berücksichtigung der Technologieentwicklung) zu erfassen. Die Szenariotechnik unterstützt die strategische Planung bei dieser Aufgabe, insbesondere in der Phase, in der es um die Definition eines gewünschten, zukünftigen Zustands der Informationsinfrastruktur und ihres Umfelds (Rahmenbedingungen) sowie um die Maßnahmen geht, die zu diesem Zustand führen können. Wird zur Entwicklung oder Überprüfung der IT-Strategie mit der Szenariotechnik gearbeitet, sollten bei der strategischen Maßnahmenplanung (vgl. Lerneinheit SPLAN) die strategischen Projekte und ihre Ordnung im Projektportfolio auf Übereinstimmung mit der Leitstrategie überprüft werden. Dazu sind Entscheidungsalternativen herauszuarbeiten (z. B. alternative Projektordnungen im Projektportfolio), deren Konsequenzen in die Leitstrategie projiziert werden. Gesucht wird die Alternative, die unter Berücksichtigung der beiden Szenarien, die der Leitstrategie zugrunde liegen, gleich gut passt und eine relativ geringe Anfälligkeit gegenüber Störereignissen hat. Die Bezeichnung Szenario im Zusammenhang mit strategischer Planung wurde erstmals Anfang der 1950er Jahre von dem Zukunftsforscher Herman Kahn und Mitarbeitern in den USA bei militärischen Planspielen verwendet, also bei nicht linearen Verläufen und unberechenbaren Ereignissen. Nach Gausemeier (92) gilt Kahn nicht zuletzt auf Grund seiner 1967 veröffentlichten Studie „The Year 2000“ als Impulsgeber für die Szenariotechnik. Wissenschaftliche Grundlage ist die Systemtheorie. In der Wirtschaft ist die Szenariotechnik seit den 1970er Jahren zur Informationsbeschaffung für Entscheidungen zur Beantwortung der

Szenariotechnik (SZENA)

411

Frage „Was wäre wenn …“ in Verwendung (insbesondere für die Raumplanung). Eigenschaften eines Szenarios sind nach Götze (38 f.):     

Es stellt ein hypothetisches Zukunftsbild (Übersetzung von Szenario) eines sozioökonomischen Bereichs und den Entwicklungspfad zu diesem Zukunftsbild dar. Es gibt in Verbindung mit weiteren Szenarien einen Raum möglicher zukünftiger Entwicklungen des untersuchten Bereichs an. Es wird systematisch und transparent sowie unter Berücksichtigung der Entwicklungen mehrerer Faktoren und der Zusammenhänge zwischen diesen erarbeitet und ist daher plausibel und widerspruchsfrei. Es enthält quantitative wie auch qualitative Aussagen, die einen ausformulierten Text bilden. Es dient der Orientierung über zukünftige Entwicklungen und/oder der Entscheidungsvorbereitung.

Nach von Reibnitz (28) soll ein Szenario folgende Bedingungen erfüllen:   

Stimmigkeit, Konsistenz und Widerspruchsfreiheit; die einzelnen Entwicklungen innerhalb eines Szenarios dürfen sich nicht gegenseitig aufheben. Stabilität des Szenarios; kleinere Veränderungen von Einflussfaktoren dürfen das Szenario nicht obsolet machen. Unterschiedlichkeit der beiden Extrem-Szenarien, die möglichst nahe an die Ränder des Szenario-Trichters herankommen sollen.

Merkmale der Szenariotechnik Bei der Formulierung und Verwendung von Szenarien wird bewusst in Alternativen gedacht, statt sich schon frühzeitig auf eine Alternative festzulegen und deren zukünftigen Zustand durch Prognose zu ermitteln. Typisch für die Anwendung der Szenariotechnik sind folgende Merkmale:     

Sie geht von einer Analyse des Istzustands aus. Sie berücksichtigt quantitative und qualitative Einflussfaktoren. Sie erfasst die Vernetzung zwischen den Einflussfaktoren und die Systemdynamik. Sie verwendet Annahmen über die Struktur und die Veränderungen der Einflussfaktoren (Störfaktoren). Sie generiert alternative, in sich konsistente Zukunftsbilder und zeigt Entwicklungspfade auf, die zu den Zukunftsbildern führen (Szenarien).

Mit Szenariotechnik sollen realistische Entwicklungsmöglichkeiten bzw. Entwicklungskorridore in vergleichsweise ferner Zukunft und bei relativ großer Unsicherheit – wenn quantitative Prognosemethoden versagen und die Unsicherheit für Simulationen zu groß ist – in Abhängigkeit von bestimmten Rahmenbedingungen aufgezeigt werden. Von quantitativen Prognosemethoden unterscheidet sich die Szenariotechnik durch Folgendes:  

mehrdimensionale Ergebnisauswertung, Nachvollziehbarkeit der Ergebnisse aus der gegenwärtigen Situation heraus,

412

    

Methoden des strategischen Informationsmanagements

Verwendung von Vergangenheitsdaten lediglich zum Verständnis von Zusammenhängen und ausdrücklich nicht zur Extrapolation, Entwicklung und Prüfung von Hypothesen, Denken in Alternativen (Dialektik), explizite Berücksichtigung von Störereignissen und Erarbeiten einer Leitstrategie auf der Basis von Alternativen.

Mit dem zuletzt genannten Merkmal wird der entscheidende Unterschied zwischen traditionellem Planungsverhalten und Szenariotechnik deutlich: Aus der Analyse der Zukunft, wie sie in alternativen Szenarien beschrieben wird, werden Maßnahmen abgeleitet, um bei deren Verwirklichung besser für die Zukunft gerüstet zu sein. Die Maßnahmen, die für die alternativen Szenarien entwickelt wurden, werden in die Leitstrategie integriert.

Szenario-Trichter Mit ihm kann die Szenariotechnik weiter verdeutlicht werden (vgl. Abbildung SZENA-1):    



 

Die Gegenwart beginnt am engsten Punkt des Trichters, da der Trichter Komplexität und Unsicherheit symbolisiert; je weiter von der Gegenwart in die Zukunft gegangen wird, desto komplexer und unsicherer wird die Situation. Der Istzustand ist durch eine Reihe von bekannten Einflussfaktoren geprägt, deren Wirkung für die gegenwärtigen Maßnahmen genutzt wird. Die Entwicklung in der nahen Zukunft (in zwei bis fünf Jahren) ist durch die Struktur der Gegenwart weitgehend festgelegt; signifikante Änderungen der Einflussfaktoren sind nicht zu erwarten. Wird versucht, aus der Gegenwart heraus die fernere Zukunft (über fünf bis zehn Jahre) zu erkennen, nimmt die Wirkung der bekannten Einflussfaktoren ab, und es tauchen neue Einflussfaktoren auf, deren Wirkung weniger oder nicht bekannt ist; der Möglichkeitsraum öffnet sich wie ein Trichter. Die verschiedenen Zukunftsbilder befinden sich auf der Schnittfläche des Trichters zu einem beliebigen Zeitpunkt; wird eine bestimmte Entwicklung verfolgt, wird auf Grund der vorhandenen Einflussfaktoren und deren Veränderung ein bestimmtes Zukunftsbild – Szenario A – erreicht. Wird ein Störereignis, das auf Grund seiner Auswirkungen die Entwicklung in eine andere Bahn lenkt, in diesen Szenario-Pfad eingeführt, entsteht ein anderes Zukunftsbild – Szenario A1. Durch Fortschreibung der gegenwärtigen Situation in die Zukunft entsteht das TrendSzenario, das im Folgenden nicht als Szenario verwendet werden sollte.

Aus dieser Erläuterung ist die entscheidende Schwäche der Szenariotechnik erkennbar: Tritt ein nicht vorhergesehenes Störereignis ein oder tritt ein Störereignis mit einer nicht vorhergesehenen Intensität ein, kann eine Situation entstehen, für die es kein Szenario gibt (sogenannter Fehler dritter Art). Mit der Szenariotechnik können nicht alle kombinatorisch möglichen Situationen beschrieben werden (das könnten mehrere 1000 sein), sondern nur wenige. Die Erfahrung zeigt, dass es im Allgemeinen ausreicht, zwei in sich konsistente, stabile und deutlich disjunkte Szenarien zu entwerfen (sogenannte Szenario-Archetypen).

Szenariotechnik (SZENA)

413

Positives Extrem-Szenario Störereignis

xA xA1 Trend-Szenario

Entscheidungszeitpunkt z. B. Einsetzen von Maßnahmen

Negatives Extrem-Szenario

Zeit Zukunft

Gegenwart X

Szenario = Bild einer denkbaren, zukünftigen Situation Entwicklungspfad eines Szenarios (A) durch ein Störereignis veränderter Entwicklungspfad (A1) Abb. SZENA-1: Szenario-Trichter (Quelle: nach von Reibnitz)

Vorgehensweise der Szenarioanalyse Szenarioanalyse oder Szenariostudie heißt methodisches Vorgehen beim Lösen eines Entscheidungsproblems mit Hilfe der Szenariotechnik, im konkreten Einzelfall in Verbindung mit anderen Techniken, insbesondere mit verschiedenen Arbeitstechniken wie Metaplantechnik oder Kreativitätstechniken (siehe Abschnitt Szenario-Team). Im Mittelpunkt der Vorgehensweise steht das Entwickeln von Szenarien, für das es kein im Detail festgelegtes Procedere gibt; es hängt sowohl vom Untersuchungsgegenstand als auch von den Präferenzen der Anwender ab. Ausgangsbasis für die Entwicklung einer an den Untersuchungsgegenstand angepassten und den Präferenzen der Anwender entsprechenden Vorgehensweise sind die acht Arbeitsschritte Aufgabenanalyse, Einflussanalyse, Trendprojektionen, Alternativenbündelung, Szenario-Interpretation, Konsequenzanalyse, Störereignisanalyse und SzenarioTransfer (nach von Reibnitz). Bei der folgenden Erläuterung dieser Arbeitsschritte wird mit Beispielen und Hinweisen der Bezug zur Informationsinfrastruktur als Untersuchungsgegenstand hergestellt.

Aufgabenanalyse Mit der Aufgabenanalyse wird im ersten Arbeitsschritt der Untersuchungsgegenstand in der gegenwärtigen Situation (Istzustand) analysiert. Dazu wird er in Subsysteme zerlegt, und es wird untersucht, welche Funktionen die Subsysteme haben und wie sie sich gegenseitig beeinflussen. Mehr als zwölf Subsysteme sollen nicht definiert werden. Eigenschaften des Untersuchungsgegenstands, an denen die Aufgabenanalyse ausgerichtet wird, sind:

414

   

Methoden des strategischen Informationsmanagements

Leistungsspektrum (Produkte und Dienstleistungen), strategische Ziele, Leitbilder und Strategien, typische Stärken und Schwächen und Rahmenbedingungen.

Anschließend wird der Szenario-Zeithorizont festgelegt. Als Faustregel für seine Länge gilt der Zeitraum, der im Allgemeinen benötigt wird, um grundlegende Innovationen am Untersuchungsgegenstand durchzuführen bzw. langfristige Investitionsvorhaben zu realisieren; einen generell gültigen Zeithorizont gibt es nicht. Für den Untersuchungsgegenstand Informationsinfrastruktur wird ein Zeithorizont von zehn Jahren empfohlen (mit zwei fünfjährigen Projektionen).

Einflussanalyse Mit der Einflussanalyse werden im zweiten Arbeitsschritt die externen Einflussfaktoren ermittelt, die auf den Untersuchungsgegenstand einwirken. Die Einflussfaktoren werden hinsichtlich ihrer Bedeutung beurteilt und miteinander vernetzt, um Aussagen über die Dynamik des Umfelds zu gewinnen. Dazu werden zunächst die Einflussbereiche festgelegt. Typische Einflussbereiche sind: Unternehmensstrategie, Geschäftsmodell, Produkte und Dienstleistungen, Geschäftsprozesse, IuK-Technologien, Benutzer. Es sollten nicht mehr als sieben Einflussbereiche definiert werden. Zur Ermittlung der Einflussfaktoren kann es zweckmäßig sein, die Einflussbereiche in Teilbereiche zu zerlegen (z. B. Produkte in Produktgruppen, Technologien in Technologiearten, Benutzer in Benutzergruppen). Vernetzung der Einflussfaktoren bedeutet, festzulegen, wie stark jeder Einflussbereich – repräsentiert durch seine Einflussfaktoren – jeweils alle anderen Einflussbereiche beeinflusst. Als Darstellungsmittel wird eine Vernetzungsmatrix verwendet, in deren Zeilen und Spalten die Einflussbereiche (im Folgenden als Systemelemente bezeichnet) angeordnet sind; in die Matrixfelder wird der durch kardinale Größen ausgedrückte Einfluss eingetragen (z. B. 0 = kein Einfluss, 1 = schwacher Einfluss, 2 = starker Einfluss). Die Spaltensumme gibt dann den Passiveinfluss (d. h. wie stark ein Systemelement von den anderen Systemelementen beeinflusst wird), die Zeilensumme den Aktiveinfluss (d. h. wie stark ein Systemelement die anderen Systemelemente beeinflusst) eines jeden Einflussbereichs an. Zur besseren Veranschaulichung können die Werte der Vernetzungsmatrix in ein Systemgrid übertragen werden, in dem auf der Horizontalen die Aktivwerte, auf der Vertikalen die Passivwerte aufgetragen werden. Vier Felder von Systemelementen werden im Systemgrid unterschieden:    

Feld I mit Systemelementen hoher Aktivität und niedriger Passivität (aktive Systemelemente), Feld II mit Systemelementen hoher Aktivität und hoher Passivität (ambivalente Systemelemente), Feld III mit Systemelementen niedriger Aktivität und niedriger Passivität (puffernde oder niedrig ambivalente Systemelemente) und Feld IV mit Systemelementen niedriger Aktivität und hoher Passivität (passive Systemelemente).

Szenariotechnik (SZENA)

415

Entsprechend der Bedeutung der Felder kann eine Rangordnung der Systemelemente hergestellt werden. Von besonderer Bedeutung sind die aktiven Systemelemente (Feld I); es gilt, diese so zu nutzen, dass sie den vom Anwender verfolgten Zielen entsprechen und zudem die ambivalenten und passiven Systemelemente aktivieren helfen (Systemdynamik).

Trendprojektionen Mit Trendprojektionen werden im dritten Arbeitsschritt auf Grundlage der Einflussfaktoren neutrale, beschreibende Kenngrößen (sogenannte Deskriptoren) ermittelt, die den jetzigen und zukünftigen Zustand der jeweiligen Entwicklungen beschreiben. Deskriptoren müssen wertneutral sein, das heißt in beide „Richtungen“ formuliert werden können (z. B. statt „Ablehnung von X“ oder „Akzeptanz von X“ muss es „Einstellung zu X“ heißen, denn es geht nicht um mehr oder weniger Ablehnung bzw. Akzeptanz, sondern um Akzeptanz oder Ablehnung als solche). Jeder Deskriptor wird zunächst in seinem Istzustand beschrieben (z. B. Jahr 2011), dann wird er in den nächsten Zeithorizont (z. B. 2016) projiziert. Danach wird gefragt, ob sich aus Sicht 2011 eine eindeutige Entwicklung bestimmen lässt oder ob Unsicherheit bezüglich der Zukunftsentwicklung besteht; im zweiten Fall müssen Alternativen erarbeitet werden. In beiden Fällen ist eine Begründung erforderlich. Danach folgt der Sprung in den zweiten Zeithorizont (z. B. 2021). Wo Unsicherheit besteht, müssen auch hier Alternativen erarbeitet, in jedem Fall muss jede Projektion begründet werden. Man erkennt so, welcher Deskriptor ein eindeutiger Deskriptor (d. h. ein Deskriptor ohne Alternativen) bzw. ein alternativer Deskriptor ist.

Alternativenbündelung Mit der Alternativenbündelung werden im vierten Arbeitsschritt die alternativen Entwicklungen, die im dritten Arbeitsschritt identifiziert wurden, auf Konsistenz bzw. Verträglichkeit geprüft. Bei wenigen Deskriptoren kann dies durch Gruppendiskussion im SzenarioTeam erreicht werden, bei einer größeren Anzahl von Deskriptoren (mehr als zwölf) ist eine Analyse mit Hilfe einer Konsistenzmatrix erforderlich. In den Zeilen und Spalten der Konsistenzmatrix sind die Deskriptoren mit ihren Alternativen eingetragen, in die Matrixfelder werden die Werte für den Zusammenhang zwischen den Alternativen eingetragen (z. B. mit 0 = neutral, +1 = konsistent ohne Verstärkung, +2 = konsistent mit Verstärkung, -1 = teilweise inkonsistent, -2 = inkonsistent). Zur Auswertung der Konsistenzmatrix gibt es Werkzeuge, mit denen im Ergebnis zwei konsistente, stabile und disjunkte Szenarien ermittelt werden.

Szenario-Interpretation Mit der Szenario-Interpretation werden im fünften Arbeitsschritt die beiden Szenarien aus dem vierten Arbeitsschritt weiter ausgestaltet, präzisiert, ausformuliert und dokumentiert. Dabei ist zu berücksichtigen, dass Szenarien eine gewisse Eigendynamik haben, so dass auf Grund einer bestimmten Szenario-Konstellation Reaktionen ausgelöst werden können (z. B. Reaktion von Benutzern auf bestimmte Dienstleistungen), die zu neuen Entwicklungen führen (z. B. zur Entwicklung anderer Dienstleistungen). Die beiden Szenarien sind im Ergebnis

416

Methoden des strategischen Informationsmanagements

konträre Szenarien, was Bezeichnungen wie progressives vs. konservatives, optimistisches vs. pessimistisches, harmonisches vs. disharmonisches Szenario zum Ausdruck bringen. Im Zusammenhang mit der Szenario-Interpretation ist es empfehlenswert, wie im zweiten Arbeitsschritt eine Vernetzungsmatrix bzw. ein Systemgrid anzufertigen, um die Systemelemente in ihrer zukünftigen Ausprägung in den beiden Szenarien darzustellen. Daraus sind die Unterschiede zwischen der gegenwärtigen Situation und den beiden Zukunftsbildern sowie zwischen den beiden Zukunftsbildern und ihrer Systemdynamik erkennbar.

Konsequenzanalyse Mit der Konsequenzanalyse werden im sechsten Arbeitsschritt auf Grundlage der beiden Szenarien die Chancen und Risiken für den Untersuchungsgegenstand abgeleitet, beurteilt und mit geeigneten Maßnahmen versehen. Chancen und Risiken bilden die Brücke zwischen den Aussagen der Szenarien und dem Untersuchungsgegenstand. Die Maßnahmen sollen bewirken, dass Chancen so früh wie möglich genutzt und Risiken soweit wie möglich vermindert oder in Chancen umgemünzt werden. Dabei sollte zwischen kreativer Maßnahmenentwicklung und späterer Beurteilung der Maßnahmen (z. B. bezüglich ihrer Realisierbarkeit) bewusst unterschieden werden. Die Maßnahmen dürfen nicht als Allgemeinplätze formuliert sein (z. B. nicht „mehr Personal“ oder „besseres Controlling“), sondern müssen konkret und detailliert sein (z. B. „zwei Mitarbeiter für Wartungsaufgaben im Geschäftsbereich X“ oder „Einführung eines IT-Kennzahlensystems“). Aus den unterschiedlichen Ergebnissen der Konsequenzanalyse für die beiden konträren Szenarien wird eine vorläufige Leitstrategie generiert (im Detail dazu vgl. achter Arbeitsschritt).

Störereignisanalyse Mit der Störereignisanalyse werden im siebenten Arbeitsschritt mögliche extern oder intern auftretende, abrupte Ereignisse, die den Untersuchungsgegenstand erheblich beeinflussen oder verändern können, gesammelt, ihre Bedeutung wird beurteilt, und sie werden mit entsprechenden vorbeugenden und reagierenden Maßnahmen versehen (Krisenpläne). Es empfiehlt sich, für jeden Einflussbereich nach möglichen Störereignissen zu fragen und diese im Hinblick auf ihre vermutete Auswirkung auf den Untersuchungsgegenstand zu beurteilen. Störereignisse, die einen entscheidenden Einfluss haben können, werden im Detail beschrieben. Störereignisse mit katastrophalen Folgen für den Untersuchungsgegenstand, für die es durch den Anwender selbst veranlasst weder vorbeugende noch reagierende Maßnahmen geben kann (z. B. Zerstörung durch Kriegsereignisse), sollten nicht berücksichtigt werden, im Unterschied zu Katastrophen, die verhindert oder auf die mit geeigneten Maßnahmen reagiert werden kann (z. B. Beschädigung durch Rauchentwicklung). Die Wirkungsanalyse der Störereignisse wird wie folgt durchgeführt: Wenn ein Störereignis die Szenarien betrifft, werden sowohl die Auswirkungen in den Szenarien als auch auf den Untersuchungsgegenstand betrachtet. Beim Eintritt eines Störereignisses können sich die Szenarien in eine andere Richtung bewegen (vgl. Abbildung SZENA-1). Bei den Auswirkungen auf den Untersuchungsgegenstand gilt es, sowohl die Auswirkungen der SzenarioÄnderung (indirekte Auswirkungen), als auch die direkten Auswirkungen zu berücksichtigen. Wird erkannt, dass bestimmte Stellen des Untersuchungsgegenstands häufig betroffen

Szenariotechnik (SZENA)

417

sind (z. B. der Rechenzentrumsbetrieb, vgl. Lerneinheit INMAN), sollte so schnell wie möglich gezielt an der Beseitigung dieser Schwachstellen gearbeitet werden. Mit Präventivmaßnahmen gegenüber externen Störereignissen wird der Untersuchungsgegenstand stabilisiert, mit anderen Worten: es werden Maßnahmen vorgesehen, die helfen, dass bei Eintritt eines Störereignisses dessen Auswirkung so gering wie möglich ist bzw. so schnell wie möglich beseitigt werden kann. Mit Präventivmaßnahmen gegenüber internen Störereignissen wird versucht, das Störereignis zu vermeiden bzw. zu verhindern. Notfallprogramme dienen dazu, auf Störereignisse sofort und angemessen reagieren zu können (vgl. Lerneinheit NOMAN). Präventivmaßnahmen werden in die Leitstrategie integriert, damit sie auch tatsächlich umgesetzt werden. Reaktivmaßnahmen auf Störereignisse sind Krisenpläne, also Maßnahmen, mit denen auf eingetretene Störereignisse umgehend und vorbereitet geantwortet werden kann.

Szenario-Transfer Mit dem Szenario-Transfer wird im achten Arbeitsschritt auf Grundlage der im sechsten Arbeitsschritt festgelegten Maßnahmen zu Chancen und Risiken die Leitstrategie formuliert, und es werden Alternativstrategien festgelegt. Ausgangsbasis für die Formulierung der Leitstrategie sind die für beide Szenarien gleichartigen Maßnahmen (sogenannter größter gemeinsamer Nenner). Davon ausgehend wird untersucht, wie folgende Fragen zu beantworten sind:  

Welche innovativen Ansätze aus Szenario A können auch unter den Rahmenbedingungen von Szenario B bzw. welche aus Szenario B können auch unter den Rahmenbedingungen von Szenario A wirksam gemacht werden? Welche innovativen Ansätze aus Szenario A und Szenario B können so modifiziert werden, dass sie zu beiden Szenarien passen?

Die nach Beantwortung dieser Fragen in den beiden Szenarien verbleibenden Maßnahmen sind Grundlage für die Erarbeitung von Alternativstrategien; sie sind Ergänzung bzw. Präzisierung der Leitstrategie, falls Szenario A oder Szenario B Wirklichkeit wird. Die zu den Störereignissen entwickelten Präventivmaßnahmen (siebenter Arbeitsschritt) werden in die Leitstrategie integriert. Die Leitstrategie wird nach den im ersten Arbeitsschritt definierten Subsystemen des Untersuchungsgegenstands gegliedert. Innerhalb dieser Gliederung nach inhaltlichen Gesichtspunkten erfolgt eine Gliederung nach formalen Gesichtspunkten (z. B. nach Zeithorizont und Priorität). Die Leitstrategie besteht aus einer Menge von inhaltlich und formal gegliederten Teilstrategien. Die Leitstrategie wird mit der im zweiten Arbeitsschritt im Systemgrid dokumentierten Systemdynamik rückgekoppelt. Dabei wird insbesondere überprüft, ob die Leitstrategie die Dynamik der aktiven Systemelemente nutzt und passive Systemelemente aktiviert. Durch Rückkopplung zu dem im ersten Arbeitsschritt beschriebenen Istzustand wird überprüft, ob und inwieweit die dort aufgelisteten strategischen Ziele, Leitbilder und Strategien mit der Leitstrategie übereinstimmen. Bei Abweichungen zwischen Leitstrategie und Istzustand sind zwei Verhaltensweisen typisch, die konservative und die progressive Verhaltensweise.

418

 

Methoden des strategischen Informationsmanagements

Die konservative Verhaltensweise ist dadurch gekennzeichnet, dass sie sich auf Maßnahmen der Leitstrategie konzentriert, die auf den Stärken des Istzustands basieren; Maßnahmen, die eine starke Veränderung bewirken, werden nicht bevorzugt. Die progressive Verhaltensweise ist dadurch gekennzeichnet, dass sie sich nicht nur auf Maßnahmen der Leitstrategie konzentriert, die auf den Stärken des Istzustands basieren, sondern zusätzlich Maßnahmen favorisiert, mit denen attraktive Ziele, die sich aus dem Szenario-Prozess ergeben, angestrebt werden.

Schließlich muss dafür gesorgt werden, dass die Deskriptoren mit ihrer eindeutigen Entwicklung bzw. mit ihren alternativen Entwicklungen beobachtet werden. Insbesondere sind die treibenden Deskriptoren zu beobachten (vgl. dazu den vierten Arbeitsschritt). Treibende Deskriptoren sind solche, mit deren Veränderung sich die meisten anderen Deskriptoren ebenfalls verändern. Daraus ergibt sich eine Konzentration der Beobachtung auf die für den Untersuchungsgegenstand wichtigsten externen Einflussfaktoren. Die aktuelle Entwicklung der externen Einflussfaktoren muss mit der Leitstrategie verknüpft werden; bei Abweichungen erfolgt eine vorsichtige Anpassung der Leitstrategie.

Szenario-Team Das Erarbeiten von Szenarien ist ein Prozess, der Partizipation erfordert (vgl. Lerneinheit PERSM). Für die Abarbeitung der acht Arbeitsschritte beim Untersuchungsgegenstand Informationsinfrastruktur ist eine Arbeitsgruppe (ein Szenario-Team) aus Mitgliedern des TopManagements (insbesondere dem CIO, wenn installiert, sonst dem CFO, vgl. Lerneinheit STELL), des Fachabteilungs- bzw. Geschäftsprozessmanagements und des IT-Managements, insbesondere dem Leiter der IT-Abteilung, erforderlich. Das Szenario-Team wird von einem (in der Regel externen) Experten moderiert, der das erforderliche Fachwissen bezüglich der Anwendung der Szenariotechnik einbringt, die Gruppenarbeit steuert und die Arbeitsergebnisse auswertet (z. B. die Ausformulierung der Szenarien); er ist auch für die Präsentation der Arbeitsergebnisse – also der Szenarien – zuständig, deren Beurteilung und Akzeptanz durch die Adressaten die Transparenz des Arbeitsprozesses voraussetzt. Szenarien müssen Überzeugungskraft entwickeln und dürfen nicht als „Luftschlösser“ erscheinen. Da im Unternehmen meist kein – oder zumindest kein ausreichendes – Expertenwissen über die externen Einflussfaktoren (z. B. über die Technologieentwicklung) vorhanden ist, ist auch deshalb die Mitwirkung externer Experten erforderlich. Über die Größe des SzenarioTeams bestehen unterschiedliche Vorstellungen; 12 bis 15 Personen haben sich häufig als zweckmäßig erwiesen. Allein dieses Merkmal weist darauf hin, dass Szenarioanalysen keine Vorgehensweise zur Problemlösung in kleinen bis mittleren Unternehmen ist. Das SzenarioTeam wird unter Beachtung folgender Kriterien zusammengesetzt:    

Entscheidungs- und Umsetzungskompetenz, Wissen, Erfahrung und Know-how zum Untersuchungsgegenstand und zu den Einflussfaktoren auf den Untersuchungsgegenstand, fachliche und altersmäßige Heterogenität, aber soziale Homogenität, und Phantasie und Kreativität.

Szenariotechnik (SZENA)

419

Bevorzugte Arbeitstechnik des Szenario-Teams ist die Metaplan-Technik; für die Arbeitsschritte drei, sechs und sieben sind Kreativitätstechniken von großer Bedeutung. Insbesondere für den vierten Arbeitsschritt ist die Verwendung von Werkzeugen zweckmäßig (z. B. CAS = Computer Aided Scenario, mit dem bis zu 50 alternative und eindeutige Deskriptoren verarbeitet und bis zu 1.024 Szenarien generiert werden können). Auch diese Hinweise zeigen, dass die Anwendung der Szenariotechnik einen erheblichen – insbesondere personellen – Aufwand erfordert. Dönitz beschreibt Möglichkeiten einer effizienteren Durchführung von Szenarioanalysen durch teilautomatische Generierung von Konsistenzmatrizen.

Stärken und Schwächen der Szenariotechnik Die Szenariotechnik hat folgende Stärken und Schwächen (nach Sträter):       



Sie trägt zu einem besseren Systemverständnis bei. Auch komplizierte Entwicklungen können dargestellt und dabei Einflussfaktoren, Beziehungen und Interventionsmöglichkeiten identifiziert werden. Politikoptionen können dargestellt und damit der Diskussion zugänglich gemacht werden; das Denken in Alternativen wird gefördert (didaktischer Wert). Qualitative und „weiche Daten“ (z. B. Grad der zu erwartenden Widerstände) können neben empirischen „harten Daten" (z. B. Kosten) einbezogen werden. Nicht-lineare Entwicklungen und Wechselwirkungen können abgebildet werden. Sie ist oft zeitaufwendig und dann auch kostenaufwendig, wenn Experten zugezogen werden müssen. Sie ist nicht wertfrei, sondern arbeitet mit Werthaltungen und Zielen und variiert diese gegebenenfalls. Es handelt sich nicht um zielgerichtete Zukunftsforschung. Voraussetzungen oder Randbedingungen können „vergessen" oder nicht ausgeführt werden. Es besteht die Gefahr eines übermäßigen Einflusses von subjektiven, nicht überprüfbaren Expertenurteilen. Sie macht zu wenig Gebrauch von grafischen und bildhaften Darstellungen; dies behindert die Partizipation und erschwert die Präsentation der Analyseergebnisse.

Forschungsbefunde Eine von Meyer-Schönherr 1989 durchgeführte explorative Studie (Fragebogenerhebung, 460 Unternehmen, Rücklaufquote 73 %) ergab, dass 26,4 % über Erfahrung mit der Szenariotechnik in der strategischen Planung (nicht explizit IT-Planung) verfügten. Nach einer 1982 von Skrobarczyk durchgeführten Untersuchung arbeiteten nur 14 % der befragten Unternehmen mit Szenariotechnik. Günther hat 1990 erhoben, dass 60,7 % der befragten Unternehmen Szenariotechnik in der strategischen Planung einsetzen. (Alle Angaben nach von Reibnitz.) Die Befunde können kaum miteinander verglichen werden, da ihnen sehr unterschiedliche Definitionen der Szenariotechnik zugrunde liegen. Immerhin können sie die Behauptung einer erheblichen, sich über der Zeit ausbreitenden Nutzung der Szenariotechnik stützen. Dönitz entwickelte auf der Grundlage von Daten zahlreicher empirischer Konsistenzmatrizen den Consistency Accellerator, ein Werkzeug zur teilautomatischen Generierung von Kon-

420

Methoden des strategischen Informationsmanagements

sistenzmatrizen (vierter Arbeitsschritt der Szenariotechnik). Erfahrungen mit seiner Erprobung geben Anlass zu der Annahme, dass eine deutliche Reduzierung des Aufwands für Szenarioanalysen möglich ist und damit eine Barriere für die breitere Anwendung der Szenariotechnik abgebaut wird. (Ergebnis einer Dissertation am Institut für Projektmanagement und Innovation an der Universität Bremen, Gutachter Möhrle. Im Vorwort wird der Zweitbegutachter Geschka als „Vater der Szenariotechnik“ bezeichnet.) Aufgabenverweise Situationsanalyse (Lerneinheit SITAN); Zielplanung (Lerneinheit SZIEL); Strategieentwicklung (Lerneinheit STRAT); Maßnahmenplanung (Lerneinheit SPLAN); Sicherheitskonzepte (Lerneinheit SIKON); Notfallmanagement (Lerneinheit NOMAN). Kontrollfragen 1. Welche Gemeinsamkeiten und welche Unterschiede bestehen zwischen der Szenariotechnik und anderen Prognoseverfahren? 2. Welche Aufgaben der strategischen IT-Planung können durch die Anwendung der Szenariotechnik unterstützt werden? 3. In welchen Arbeitsschritten wird bei einer Szenarioanalyse vorgegangen? 4. Von welchen Arbeitstechniken wird angenommen, dass sie die Durchführung von Szenarioanalysen erleichtern und wie kann diese Annahme begründet werden? 5. Was heißen Partizipation und Transparenz im vorliegenden Zusammenhang und warum muss eine Szenarioanalyse als partizipativer und transparenter Prozess organisiert sein? Quellenliteratur Dönitz, E. J.: Effizientere Szenariotechnik durch teilautomatische Generierung von Konsistenzmatrizen. Wiesbaden 2009 Gausemeier, J ./ Fink, A. / Schlake, O.: Szenario-Management: Planen und Führen nach Szenarien. 2. A., München/ Wien 1996 Götze, U.: Szenario-Technik in der strategischen Unternehmensplanung. 2. A., Wiesbaden 1993 Reibnitz, U. von: Szenariotechnik. Instrumente für die unternehmerische und persönliche Erfolgsplanung. 2. A., Wiesbaden 1992 Sträter, D.: Szenarien als Instrument der Vorausschau in der räumlichen Planung. In: Akademie für Raumforschung und Landesplanung (Hrsg.): Regionalprognosen – Methoden und ihre Anwendung. Hannover 1986 Weinbrenner, P.: Szenariotechnik. http//www.sowi-online.de/methoden/dokumente/szenariotechnik.htm; Abruf 27.5.2011 http://widawiki.wiso.uni-dortmund.de/index.php/Szenario-Technik; Abruf 28.5.2011 Vertiefungsliteratur Brauers, J. / Weber, M.: Szenarioanalyse als Hilfsmittel der strategischen Planung. Methodenvergleich und Darstellung einer neuen Methode. In: Zeitschrift für Betriebswirtschaft 7/1986, 631–652 Fink, A. / Schlake, O. / Siebe, A.: Erfolg durch Szenario-Management – Prinzip und Werkzeuge der strategischen Vorausschau. Frankfurt/M. 2001 Geschka, H. / Hammer, R.: Die Szenario-Technik in der strategischen Unternehmensplanung: In: Hahn, D. / Taylor, B. (Hrsg.): Strategische Unternehmensplanung. Heidelberg 1992, 311–336. Leemhuis, J. P.: Using Scenarios to Develop Strategies. In: Long Range Planning 2/1985, 30–37 Informationsmaterial Batelle-Institut (Hrsg.): Batelle-Szenario-Technik. Frankfurt/M. o. J. Blume, W.: Die Szenariotechnik in der räumlichen Planung. Diplomarbeit am Fachbereich Landschaftsarchitektur und Umweltentwicklung der Universität Hannover, Hannover 1996 Frank, J.: Szenario-Technik in der Praxis. Wirtschaftsförderungsinstitut der Bundeskammer der gewerblichen Wirtschaft, Wien 1985 http://www.szenario.com/ Institut für Landesplanung und Raumforschung, Universität Hannover: http//www.laum.uni-hannover.de /ilr/lehre/Ptm/Ptm_Szenario.htm; Abruf 27.5.2011

E. METHODEN DES ADMINISTRATIVEN INFORMATIONSMANAGEMENTS

strategische Ebene

administrative Ebene

operative Ebene

Grundlagen des Informationsmanagements

Methoden des Informationsmanagements

Aufgaben des Informationsmanagements

Fallstudien Informationsmanagement

422

Methoden des administrativen Informationsmanagements

Gegenstand dieses Kapitels sind Methoden des administrativen Informationsmanagements, also das administrative Information Engineering. Da sich die Methoden auf Aufgaben des Informationsmanagements beziehen, ist es sinnvoll, zunächst diese – unter Aufgabenverweisen in den einzelnen Lerneinheiten angegebenen – Lerneinheiten zu studieren, bevor mit der Lektüre der Methoden begonnen wird. Die Methoden überschneiden sich teilweise in ihrer Anwendungsdomäne, so dass es wichtig ist zu erkennen, worin ihre Gemeinsamkeiten bestehen und wodurch sie sich unterscheiden. Es ist daher angebracht, beim Durcharbeiten der Lerneinheiten den jeweils angegebenen Zweck zu durchdenken und Vergleiche zwischen den Methoden anzustellen.

Informationsbedarfsanalyse (INBAN) ................................................................................. 423 Methoden des Geschäftsprozessmanagements (MEGPM)................................................... 435 Methoden des Wissensmanagements (MEWIM)................................................................. 447 Kosten- und Leistungsrechnung (KOLER) .......................................................................... 459 Sicherheitskonzepte (SIKON).............................................................................................. 471 Methoden des Qualitätsmanagements (MEQUA)................................................................ 483 Serviceebenen-Vereinbarungen (SEVER) ........................................................................... 495

Informationsbedarfsanalyse (INBAN) Lernziele Sie wissen, für welche Anwendungen Informationsbedarfsanalysen durchgeführt werden. Sie kennen den Unterschied zwischen objektivem und subjektivem Informationsbedarf. Sie können erklären, warum objektiver und subjektiver Informationsbedarf sowie Informationsnachfrage voneinander abweichen können. Sie wissen, welche Methoden der Informationsbedarfsanalyse sich unter welchen Umständen eignen.

Definitionen und Abkürzungen Bedarf (requirement) = konkretisierter Wunsch nach Beschaffung von Mitteln zur Befriedigung von Bedürfnissen. Bedürfnis (need) = Wunsch, Notwendigkeit oder Bereitschaft zur Beseitigung eines Mangels. Benutzerforschung (user research) = Analyse, Beobachtung und Messung des Problemlösungs- und Informationsverhaltens von Personen bzw. Personengruppen. Informationsangebot (information supply) = Art, Qualität und Menge der Information, welche Aufgabenträgern zur Verfügung gestellt wird. Informationsbedarf (information requirement) = Art, Qualität und Menge der Information, welche Aufgabenträger zur Erfüllung einer bestimmten Aufgabe benötigen oder zu benötigen glauben. Informationsbedarfsanalyse (information needs assessment) = Erfassen, Strukturieren und Beurteilen des Informationsbedarfs. Informationsbedürfnis (information need) = von einem Aufgabenträger zur Erfüllung einer Aufgabe für erforderlich gehaltene Information. Synonym: subjektiver Informationsbedarf. Informationsdefizit (information deficit) = tatsächlicher oder wahrgenommener Mangel an Information. Informationsnachfrage (information demand) = von einem Aufgabenträger geltend gemachter Bedarf an Information. Informationsüberlastung (information overload) = Zustand eines Aufgabenträgers, in dem eine weitere Erhöhung des Informationsangebots zu einer Verschlechterung der Wahrnehmung eines Objektes führt, welches durch die Information beschrieben wird. Informationsverhalten (information behavior) = auf Information gerichtetes Tun oder Unterlassen von Personen oder Personengruppen. Nachfrage (demand) = geäußerter Bedarf nach einem Gut, verbunden mit der Bereitschaft, dafür eine Gegenleistung zu erbringen. objektiver Informationsbedarf (objective information requirement) = zur Erfüllung einer Aufgabe erforderliche Information. subjektiver Informationsbedarf (information need) = von einem Aufgabenträger zur Erfüllung einer Aufgabe für erforderlich gehaltene Information. Synonym: Informationsbedürfnis.

424

Methoden des administrativen Informationsmanagements

Zweck der Informationsbedarfsanalyse Informationsbedarfsanalysen werden durchgeführt, um die Information zu ermitteln, welche zur Erfüllung einer bestimmten Aufgabe erforderlich ist oder die ein Aufgabenträger bzw. eine Gruppe von Aufgabenträgern für erforderlich hält. Eine möglichst genaue Kenntnis des Informationsbedarfs ermöglicht es, den Aufgabenträgern die Information zur Verfügung zu stellen, welche sie zur Erfüllung ihrer Aufgaben benötigen oder zu benötigen meinen. Ein zu geringes Informationsangebot kann dazu führen, dass Aufgaben nur unzureichend erfüllt werden. Ein zu umfangreiches Informationsangebot ist unwirtschaftlich und führt zu Informationsüberlastung. Sofern die erforderliche Information durch Informationssysteme zur Verfügung gestellt werden soll, ist die Informationsbedarfsanalyse ein wichtiges Hilfsmittel für die Entwicklung der Informationsinfrastruktur. Typische Anwendungen der Informationsbedarfsanalyse sind die strategische Planung von Informationssystemen (vgl. Lerneinheiten SZIEL und STRAT), die Anforderungsermittlung im Rahmen der Systementwicklung (vgl. Lerneinheit VOMOD), die Entwicklung von Kennzahlensystemen (vgl. Lerneinheit KENNZ) zur Deckung des Informationsbedarfs von Führungskräften, der Entwurf von Data-Warehouse-Systemen (vgl. Lerneinheit DATEM) und die Einrichtung von UserHelp-Desks (vgl. Lerneinheit SEMAN).

Art, Menge und Qualität der Information Der Informationsbedarf eines Aufgabenträgers hat unterschiedliche Facetten. Die erste ist die Art der Information, d. h. die Problemrelevanz bzw. Zweckorientierung der Information. Die zweite Facette, die Menge, verdeutlicht, dass Aufgabenträger nicht beliebig viel Information benötigen und wünschen, sondern einen der jeweiligen Aufgabe entsprechenden Umfang. Die dritte Facette, Qualität, drückt aus, in welchem Ausmaß eine Information geeignet ist, Anforderungen zu erfüllen (vgl. Lerneinheit QUALM). Von ERP-Systemen ist z. B. bekannt, dass sie von vielen Benutzern nur wenig akzeptiert werden. Untersuchungen von Hurtienne/ Prümper und Topi/Lucas/Babaian zeigen, dass mangelnde Benutzerakzeptanz oft nicht damit begründet werden kann, dass diese Systeme Daten nicht zur Verfügung stellen, die zur Informationsgewinnung benötigt werden. Vielmehr sind die Benutzer mit anderen Eigenschaften des Informationsangebots unzufrieden. Sie empfinden z. B. folgende Mängel: unnötig komplizierte Handhabung, eingeschränkte Möglichkeiten des Datenexports in andere Softwareprogramme, unangemessene Bezeichnungen von Datenfeldern und Funktionen oder, dass Informationen nur mit Mühe gefunden werden können. In anderen Systemen führen fehlende Aktualität, ein unangemessener Detaillierungsgrad von Informationen, alphanumerische statt grafische Benutzeroberflächen, Darstellung von Informationen in Form von Zahlen statt Grafiken oder die fehlende Möglichkeit zur flexiblen Anordnung von Fenstern zu mangelnder Benutzerakzeptanz. Diese Beispiele verdeutlichen, dass im Rahmen einer Informationsbedarfsanalyse nicht nur Art und Menge, sondern auch die Qualität der erforderlichen Information ermittelt werden muss. Berthel nennt folgende Qualitätskriterien für Information:   

Problemrelevanz (Zweckorientierung), Wahrscheinlichkeit (Grad der Sicherheit, wahr zu sein), Bestätigungsgrad (Glaubwürdigkeit aufgrund verfügbaren Erfahrungswissens),

Informationsbedarfsanalyse (INBAN)

  

425

Überprüfbarkeit (Möglichkeit, den Wahrheitsgehalt festzustellen), Genauigkeit (Präzision, Detailliertheit) und Aktualität (Neuheitsgrad).

Informationsbedarf, -bedürfnis und -nachfrage Informationsbedarf setzt sich aus dem objektiven und dem subjektiven Informationsbedarf zusammen. Die Informationsnachfrage ist der Teil des subjektiven Informationsbedarfs, der tatsächlich nachgefragt wird. In der Regel sind objektiver und subjektiver Informationsbedarf sowie Informationsnachfrage nicht deckungsgleich. Abbildung INBAN-1 zeigt den Zusammenhang zwischen den drei Begriffen. Teilmenge 1 kennzeichnet Information, welche zur objektiver subjektiver Erfüllung einer bestimm- Informationsbedarf Informationsbedarf 2 3 ten Aufgabe notwendig (Informationsbedürfnis) ist, vom Aufgabenträger aber nicht für notwendig gehalten und deshalb auch 5 nicht nachgefragt wird. 1 Informationsnachfrage Ursächlich für diese Abweichung kann z. B. sein, 4 dass der Aufgabenträger die Aufgabe nicht richtig Abb. INBAN-1: Informationsbedarf, -bedürfnis und -nachfrage verstanden hat. Teilmenge 2 kennzeichnet Information, die zur Erfüllung der Aufgabe relevant ist, vom Aufgabenträger auch als notwendig erachtet, aber von ihm nicht nachgefragt wird. Ein Grund hierfür kann tatsächlicher oder subjektiv empfundener Zeitmangel für die Beschaffung oder Verwertung der Information sein. Teilmenge 3 kennzeichnet Information, welche für die jeweilige Aufgabe nicht relevant ist, vom Aufgabenträger zwar als notwendig erachtet, aber dennoch nicht von ihm nachgefragt wird. Gründe können eine fehlerhafte Wahrnehmung der zu lösenden Aufgabe sowie die Annahme sein, die vom Aufgabenträger für notwendig gehaltene Information sei nicht verfügbar oder nur mit unangemessen hohem Aufwand zu beschaffen. Teilmenge 4 kennzeichnet Information, die zur Erfüllung der Aufgabe objektiv nicht erforderlich ist, vom Aufgabenträger aber für notwendig gehalten und deshalb nachgefragt wird. Ursachen hierfür können ein falsches Verständnis der Aufgabe oder der Versuch des Aufgabenträgers sein, sich durch eine breite Informationsgrundlage abzusichern. Teilmenge 5 kennzeichnet Information, die zur Bewältigung der Aufgabe notwendig ist sowie vom Aufgabenträger als hilfreich angesehen und deshalb von ihm nachgefragt wird. Ein Ziel des Informationsmanagements besteht darin, Teilmenge 5 zu maximieren. Dies kann z. B. durch eine aufgabenbezogene Ausbildung der Aufgabenträger erfolgen.

426

Methoden des administrativen Informationsmanagements

Methoden der Informationsbedarfsanalyse In der Literatur werden verschiedene Methoden zur Informationsbedarfsanalyse beschrieben. Koreimann (2000) identifiziert ca. 20, Beiersdorf sogar 28 verschiedene Methoden. Darunter sind Methoden zur Ermittlung des objektiven und andere zur Ermittlung des subjektiven Informationsbedarfs; solche, die sich eher zur Untersuchung des Bedarfs von Führungskräften eignen und andere für den Informationsbedarf von Fachkräften. Einige Methoden sind für gut strukturierte Aufgaben entwickelt worden, andere für schlecht strukturierte. Es finden sich induktive Methoden, mit denen die tatsächlichen Gegebenheiten in einem Unternehmen analysiert werden, um daraus den Informationsbedarf abzuleiten. Deduktive Methoden bestimmen den Informationsbedarf ausgehend von den Zielen und Aufgaben der Organisation. Einige Methoden sind primär-, andere sekundäranalytisch ausgerichtet. In Projekten zur Ermittlung des Informationsbedarfs wird häufig eine Kombination dieser Methoden eingesetzt (vgl. den Abschnitt Aus der Praxis). Im Folgenden wird eine Auswahl der Methoden beschrieben, die sich an ihrer Praktikabilität orientiert.

Benutzerforschung Kluck gibt einen Überblick über Methoden der empirischen Sozialforschung, die sich für die Informationsbedarfsanalyse eignen. Hierzu zählen insbesondere schriftliche und mündliche Befragung, Beobachtung sowie Benutzerforschung. Diese diente ursprünglich der Erforschung des Verhaltens von Benutzern (vgl. Lerneinheit INVER) gegenüber institutionalisierten Informationsanbietern, insbesondere Bibliotheken. Die in der Benutzerforschung verwendeten Methoden sind vorwiegend verhaltenswissenschaftlich orientiert. Laut Koreimann (1976) lässt sich Benutzerforschung durch folgende Eigenschaften charakterisieren:   

Analyse, Beobachtung und Messung des Informationsverhaltens von Personen bzw. Personengruppen, Erforschung der Faktoren, die Informationsbedürfnisse auslösen und Einsatz quantitativer Methoden der empirischen Sozialforschung, um zu repräsentativen Aussagen zu gelangen.

Teilaufgaben der Benutzerforschung sind Benutzeranalysen und die Benutzerforschung im engeren Sinne. Mit Benutzeranalysen werden die Gruppenzugehörigkeit von Benutzern und deren Rollenverhalten untersucht. Dabei ist zu ermitteln, welche unterschiedlichen Gruppen von Benutzern es gibt. So müssen Personen, die Information für einen bestimmten Zweck verwenden und dadurch einen Nutzen generieren, von anderen Personen unterschieden werden, die lediglich als Informationsbeschaffer für Dritte agieren (z. B. Sekretärinnen oder Assistenten). Benutzerforschung im engeren Sinne zielt darauf ab, das Informationsverhalten einzelner Benutzer oder Benutzergruppen zu untersuchen und zu beschreiben. Hierzu zählen die Analyse  

der Einflussfaktoren, die Informationsbedarf auslösen, der Ziele, die Benutzer mit der Informationsnachfrage und -nutzung verfolgen,

Informationsbedarfsanalyse (INBAN)

 

427

des Problemlösungsverhaltens und dessen Zusammenhang mit dem Informationsverhalten (Wie geht ein Benutzer vor, der ein bestimmtes Problem lösen will?) sowie der Präferenzen, Gewohnheiten und Wertemuster der Benutzer.

Die Benutzerforschung eignet sich bei schlecht strukturierten Aufgaben, wenn Art und Zusammensetzung der Benutzergruppen unbekannt oder die Benutzer in ihrem Informationsverhalten weitgehend frei sind. Werden Informationsbedarfsanalysen im Rahmen der Entwicklung von Informationssystemen eingesetzt, die innerhalb eines Unternehmens zur Bewältigung gut strukturierter Aufgaben zum Einsatz kommen, ist die Benutzerforschung weniger zu empfehlen, denn die Benutzer dieser Systeme sind weitgehend bekannt und in ihrem Informationsverhalten durch Unternehmensziele, organisatorische Zwänge und Aufgaben gebunden, insbesondere wenn es sich nicht um Führungs-, sondern um Fachkräfte handelt. Da die Benutzerforschung sehr aufwendig ist, empfiehlt es sich in diesen Fällen eher, sekundäranalytische Methoden zu verwenden.

Aufgabenanalyse Die Aufgabe ist der zentrale Untersuchungsgegenstand zur Ermittlung des objektiven Informationsbedarfs. Berthel empfiehlt, Informationsbedarfsanalysen nach der Art der Aufgabe zu differenzieren. Handelt es sich um eine gut strukturierte und standardisierte Aufgabe, ergeben sich Anhaltspunkte für den Informationsbedarf aus den mit der Aufgabe verfolgten Zielen und Zwecken, den Teilaufgaben, den Aufgabenobjekten und Verrichtungsgegenständen sowie den Rahmenbedingungen. Hinweise hierauf können Untersuchungen der Aufbau- und der Ablauforganisation liefern (vgl. den folgenden Abschnitt). Soll der Informationsbedarf für eine schlecht strukturierte Aufgabe erhoben werden, können die mit der Aufgabe verfolgten Ziele sowie die Rahmenbedingungen nützliche Hinweise auf den Informationsbedarf geben. Zusätzlich kann es hilfreich sein, Aufgabenträger bei der Bearbeitung der Aufgabe zu beobachten, um zu erfassen, welche Informationen sie verwenden. Heinrich/Heinzl/Riedl erläutern die Vorgehensweise bei der Informationsbedarfsanalyse für den durch starke Strukturiertheit und geringe Veränderlichkeit gekennzeichneten Aufgabentyp. Die Merkmale für den Informationsbedarf liegen bei diesem Aufgabentyp in der Aufgabe selbst und sind aus der Aufgabenbeschreibung erkennbar; sie sind nicht von der Situation der Aufgabenerfüllung (z. B. vom Informationsverhalten des Aufgabenträgers) abhängig. Solche aufgabenspezifischen Merkmale sind vor allem die Art der Tätigkeiten (Verrichtungen) und die (meist) immateriellen Objekte, an denen die Tätigkeiten ausgeführt werden. Die Art der Tätigkeiten und die Objekte können durch systematisches Zerlegen der Aufgabe in Teilaufgaben, durch Zerlegen der Teilaufgaben in Unteraufgaben usw. bestimmt werden, bis die Ebene nicht weiter zerlegbarer Tätigkeiten erreicht ist. Auf dieser Ebene sind die zur Aufgabenerfüllung erforderlichen Informationen unmittelbar erkennbar. Die Systematik des Zerlegungsprozesses wird verbessert, wenn zwischen den Aufgabenphasen Planung, Durchführung und Kontrolle unterschieden wird, so dass man am Ende des Zerlegungsprozesses zu den für die Planung, Durchführung und Kontrolle der betrachteten Aufgabe erforderlichen Informationen gelangt. Mit der Aufgabenanalyse kann das Problem der Ermittlung des Informationsbedarfs deshalb nicht umfassend gelöst werden, weil sie sich zu sehr an der einzelnen Aufgabe und nicht an

428

Methoden des administrativen Informationsmanagements

den Aufgaben einer Struktureinheit oder mehrerer Struktureinheiten orientiert. Zudem geht sie von der Annahme aus, dass die Aufgabenerfüllung statisch ist. In Wirklichkeit handelt es sich aber um dynamische Aufgabenerfüllungsprozesse.

Organisationsanalyse Organisationsanalysen helfen, Aufgaben in die Struktur- und Ablauforganisation (vgl. Lerneinheiten STRUK und GPMAN) einzuordnen. Dadurch geben sie wichtige Anhaltspunkte für die Erfassung und Strukturierung des objektiven Informationsbedarfs. Stellenbeschreibungen geben Aufschluss über die Aufgaben einzelner Personen bzw. Rollen (vgl. Lerneinheit PERSM). Organigramme beschreiben den formalen Zusammenhang von Struktureinheiten und die ihnen zugewiesenen Aufgabenbereiche. Beschreibungen der Ablauforganisation helfen, den logischen und zeitlichen Zusammenhang von Aufgaben zu erkennen. Organisationsanalysen sind zwar nicht geeignet, den Informationsbedarf unmittelbar zu ermitteln, sie sind aber Hilfsmittel zur Erfassung des objektiven Informationsbedarfs für die Bewältigung gut strukturierter und stetig wiederkehrender Aufgaben. Sie geben Hinweise auf relevante Aufgabenträger und deren Informationsbedarf. Informationsbedarfsanalysen, die auf dokumentierte Ergebnisse von früheren Untersuchungen zurückgreifen können, z. B. auf Organigramme, Verfahrensanweisungen im Qualitätsmanagement (vgl. Lerneinheit QUALM) oder Prozessbeschreibungen in Form von Geschäftsprozessmodellen (vgl. Lerneinheit GPMAN), verursachen einen deutlich geringeren Aufwand als Analysen, für die Primärerhebungen durchgeführt werden müssen (wie z. B. bei der Benutzerforschung).

Kommunikationsanalyse Laut Koreimann (2000) können mit der Kommunikationsanalyse Kommunikationsbeziehungen in einem Unternehmen erfasst und gemessen werden. Gegenstand der Kommunikationsanalyse sind Aufgabenträger bzw. Kommunikationspartner, Kommunikationsformen und -kanäle, die Art der ausgetauschten Information sowie Kommunikationsanlässe und -zeiten. Diese können mit Befragungen oder Beobachtungen ermittelt werden. Die Ergebnisse lassen sich in Form von Kommunikations- oder Funktionsdiagrammen darstellen. Kommunikationsdiagramme stellen Kommunikationsbeziehungen zwischen Aufgaben oder Stellen dar. Sie können als Matrizen oder Netze gestaltet werden. Die Matrizen enthalten in den Zeilenund Spaltenüberschriften Sender und Empfänger von Nachrichten, die Matrizenwerte stellen die jeweils interessierenden Eigenschaften der Kommunikationsbeziehung dar (z. B. Art und Menge der Nachrichten, Kommunikationskanäle oder -anlässe). Kommunikationsnetze werden mit Knoten und Kanten gebildet, wobei die Knoten Aufgaben oder Stellen und die Kanten Kommunikationsbeziehungen abbilden. Funktionsdiagramme sind eine Erweiterung der Kommunikationsdiagramme. Sie ordnen Kommunikationsbeziehungen in den Kontext des Unternehmens ein, indem Kommunikation zwischen Aufgaben und Stellen dargestellt wird. Auf diese Weise können Kommunikationsbeziehungen im Kontext der Struktur- und Ablauforganisation (vgl. Lerneinheiten STRUK und GPMAN) dargestellt werden. Kommunikationsanalysen eignen sich zur Unterstützung der anderen Methoden; insbesondere, wenn der Bedarf zum Austausch von Informationen bzw. an Kommunikationssystemen ermittelt werden soll.

Informationsbedarfsanalyse (INBAN)

429

Informationssystemanalyse Durch die Erfassung und Untersuchung bereits bestehender oder geplanter Informationssysteme können das Informationsangebot ermittelt und Hinweise auf das Informationsverhalten der Benutzer gewonnen werden. Die Untersuchung von Ist-Architekturen kann für die Ermittlung des aktuellen Informationsbedarfs von Aufgabenträgern hilfreich sein, die Analyse von Ziel-Architekturen gibt Hinweise auf deren zukünftigen Informationsbedarf (vgl. Lerneinheit ARCHI). Koreimann (2000) erörtert, wie Datenbestände, Funktionsbeschreibungen und Informationsflüsse analysiert werden können, um Hinweise auf den Informationsbedarf abzuleiten. Informationssystemanalysen bieten sich insbesondere als Teil der Anforderungsanalyse an, wenn bereits bestehende Informationssysteme erweitert oder ersetzt werden sollen. Darüber hinaus besteht die Möglichkeit, Zugriffsstatistiken in Logfiles von Websites, Dokumenten- und Content-Management- sowie Data-Warehouse-Systemen auszuwerten, um das Informationsverhalten von Aufgabenträgern (vgl. Lerneinheit INVER) zu ermitteln.

Methode der kritischen Erfolgsfaktoren Rockart entwickelte eine strukturierte Vorgehensweise zur Ermittlung des Informationsbedarfs von Führungskräften. Grundlage seiner Vorschläge ist die Beobachtung, dass Mitarbeiter mit Leitungsfunktionen häufig deutlich mehr Information zur Verfügung gestellt bekommen, als sie sinnvoll auswerten können. Deshalb sollte sich das Informationsangebot für Führungskräfte auf die kritischen Erfolgsfaktoren konzentrieren. Als kritisch bezeichnet Rockart die Faktoren, von deren Ausprägung der Unternehmenserfolg entscheidend abhängt (vgl. auch Lerneinheit ERFAN). Mit der Methode der kritischen Erfolgsfaktoren wird der Informationsbedarf einzelner Führungskräfte erhoben, der mit Hilfe regelmäßiger Berichte befriedigt werden kann. In diesen Berichten sollen die Eigenschaften der Unternehmensleistung beschrieben werden, deren Ausprägungen die Führungskraft kontinuierlich überwachen soll. Die kritischen Erfolgsfaktoren, die eine einzelne Führungskraft im Blickfeld haben sollte, hängen von der Branche, dem Unternehmen, den Wettbewerbs- und sonstigen Rahmenbedingungen sowie den Aufgaben des betreffenden Managers ab. Sie variieren im Zeitverlauf, so dass die Ergebnisse der Informationsbedarfsanalyse von Zeit zu Zeit aktualisiert werden müssen. Rockart empfiehlt, die Informationsbedarfsanalyse in zwei bzw. drei Sitzungen durchzuführen. Jede Sitzung wird in Form eines Interviews oder Workshops mit der Führungskraft und einem oder mehreren Methodenspezialisten gestaltet. 



In der ersten Sitzung werden die Ziele der Führungskraft ermittelt und kritische Erfolgsfaktoren zur Erreichung der Ziele identifiziert. Im Anschluss werden Ursache/WirkungZusammenhänge zwischen den kritischen Erfolgsfaktoren und den Zielen erörtert. Als Ergebnis der ersten Sitzung wird festgelegt, wie die Ausprägungen der kritischen Erfolgsfaktoren gemessen werden sollen. In der zweiten Sitzung werden die zuvor erreichten Ergebnisse überprüft und überarbeitet. Außerdem wird die Grobstruktur der Berichte entworfen, mit denen die Führungskraft über die Ausprägungen der Erfolgsfaktoren informiert werden soll.

430



Methoden des administrativen Informationsmanagements

Falls notwendig, werden in einer dritten Sitzung Erfolgsfaktoren, Methoden zur Messung ihrer Ausprägungen sowie die Struktur der Berichte und die Berichtszyklen nochmals überprüft und dann festgelegt. Im Anschluss werden Maßnahmen eingeleitet, um die Führungskraft mit den zuvor erörterten Informationen zu versorgen.

Die Methode der kritischen Erfolgsfaktoren eignet sich gut zur Ermittlung des Informationsbedarfs von Führungskräften für routinemäßig durchzuführende Kontroll- und Steuerungsaufgaben. Sie ist hilfreich, wenn Führungskräfte unter einer Informationsüberlastung leiden und wenn festgestellt werden soll, wie sie in knapper Form mit den wichtigsten Informationen versorgt werden können. Rockart betont, dass die Methode zur Ermittlung des Informationsbedarfs für weniger gut strukturierte Aufgaben nicht geeignet ist (z. B. im Rahmen der strategischen Planung).

6-W-Methode Die 6-W-Methode stammt aus dem Total Quality Management (vgl. Lerneinheit QUALM) und hilft, insbesondere schlecht strukturierte Probleme besser zu durchdringen, zu erfassen und zu dokumentieren. Die Methode liefert ein Raster zur inhaltlichen Strukturierung relevanter Facetten des Informationsbedarfs. Der Name leitet sich aus sechs Fragen ab, die bei der Anwendung der Methode gestellt werden: Wer? Was? Warum? Wozu? Wie? Wann? Wer? Die Frage hilft, die Personen oder Gruppen zu identifizieren, die für die Ermittlung des Informationsbedarfs relevant sind. In erster Linie sind hiermit die Aufgabenträger gemeint, deren Informationsbedarf untersucht werden soll. Da insbesondere bei komplexeren Aufgaben nicht alle Fach- und Führungskräfte befragt werden können, muss versucht werden, Gruppen von Mitarbeitern zu identifizieren, von denen anzunehmen ist, dass sie einen ähnlichen Informationsbedarf haben. Bei geschickter Auswahl einzelner Vertreter der verschiedenen Gruppen kann der Aufwand für Befragungen in Grenzen gehalten werden. Darüber hinaus sind auch die Führungskräfte zu identifizieren, in deren Auftrag ein Informationssystem zur Befriedigung des Informationsbedarfs entwickelt oder erweitert werden soll. Dies kann insbesondere dann hilfreich sein, wenn zu vermuten ist, dass die Ziele, welche die Führungskräfte mit dem Informationssystem verfolgen, von den Zielen der Aufgabenträger abweichen. Antworten auf die folgenden Fragen sollten für die genannten Gruppen gesondert ermittelt werden. Was? Mit der zweiten Frage werden Art und Inhalt der Information bestimmt, welche die Aufgabenträger zur Erfüllung ihrer Aufgaben benötigen oder zu benötigen glauben. Hier sollte versucht werden, zunächst relevante Informationskategorien zu identifizieren. Im zweiten Schritt können (z. B. mit Hilfe einer A-B-C-Analyse) wichtige von weniger wichtigen Informationskategorien unterschieden werden. Im dritten Schritt ist für jede einzelne Kategorie zu untersuchen, welche Informationen im Einzelnen benötigt werden, wobei der Schwerpunkt der Analyse auf die Kategorien zu legen ist, welche als besonders wichtig klassifiziert wurden. Für jede Information sind die folgenden vier Fragen einzeln zu beantworten. Warum? Diese Frage hilft zu klären, welche Faktoren den Informationsbedarf auslösen. Sie ermöglicht den Personen, welche die Analyse durchführen, ein besseres Verständnis der verschiedenen Informationsbedürfnisse und hilft, objektiv nicht begründete Informations-

Informationsbedarfsanalyse (INBAN)

431

bedürfnisse zu identifizieren. In Verbindung mit der nächsten Frage können Informationsbedürfnisse erkannt werden, die durch Gewohnheiten entstanden sind, aber für die Bewältigung der Aufgabe nicht benötigt werden. Wozu? Mit der vierten Frage wird ermittelt, zu welchem Zweck eine bestimmte Information benötigt und wie sie verwendet wird. Antworten auf diese Frage helfen zu verstehen, für welche Teilaufgaben die Information verwendet wird bzw. welche Probleme damit gelöst werden sollen. Wie? Die fünfte Frage hilft feszustellen, welche Eigenschaften die benötigte Information hat. Häufig ist es wichtig zu wissen, im Kontext mit welchen anderen Informationen eine Information benötigt wird, damit die Aufgabenträger eine Teilaufgabe nicht zu häufig durch Öffnen anderer Programme oder Datenbestände unterbrechen müssen. Die Darstellungsform der Information ist oft ausschlaggebend für die Benutzerakzeptanz. Grafische Benutzeroberflächen werden in der Regel besser akzeptiert als alphanumerische. Eine flexible Anordnung verschiedener Fenster hilft den Benutzern, den Bildschirminhalt individuell zu gestalten. Ob bestimmte Informationen als Text, Zahlen, Daten und Fakten oder als Grafiken dargestellt werden sollen, kann je nach Aufgabe und Aufgabenträger variieren. Weitere Eigenschaften der Information sind das Daten- bzw. Dateiformat sowie die benötigte Aktualität und Genauigkeit der Information. Wann? Mit der letzten Frage wird erhoben, zu welchen Anlässen und Zeitpunkten bzw. über welche Zeiträume die Information benötigt wird. Außerdem können in diesem Zusammenhang Anforderungen an das Antwortzeitverhalten von Informationssystemen geklärt werden. Die 6-W-Methode eignet sich als Analyseraster insbesondere in Kombination mit anderen Methoden der Informationsbedarfsanalyse. Unabhängig davon, ob der objektive oder der subjektive Informationsbedarf ermittelt werden soll, hilft die 6-W-Methode, eine Informationsbedarfsanalyse auf relevante Aspekte zu fokussieren.

Forschungsbefunde Feldman et al. berichten über Ergebnisse einer Untersuchung zu den Kosten der Informationsbeschaffung (schriftliche Befragung von Mitarbeitern mit wissensintensiven Aufgaben in 600 Unternehmen in den USA, 234 auswertbare Antworten, Untersuchungszeitraum Sommer 2004). Die Teilnehmer gaben an, im Durchschnitt pro Woche folgende Zeiten für unproduktive Aufgaben zu benötigen:     

3,5 Stunden für erfolglose Suche nach Informationen, 3 Stunden für Erstellung von Inhalten, die an anderer Stelle bereits vorhanden sind, 2,8 Stunden für den Versand von Dokumenten mit verschiedenen Anwendungssystemen auf mehreren Kommunikationskanälen, 2,4 Stunden für die Konvertierung von Dokumenten in andere Formate und 2,3 Stunden für die Beschaffung von Informationen ohne oder nur mit geringer Unterstützung durch automatisierte Informationssysteme.

432

Methoden des administrativen Informationsmanagements

Diese Ergebnisse verdeutlichen, dass der Informationsbedarf häufig nur unzureichend gedeckt wird und dass durch eine Verbesserung des Informationsangebots Personalkosten gesenkt werden können. Koch/Lasi/Kemper berichten über eine Informationsbedarfsanalyse im Produktionsbereich (Fertigung und Produktionsmanagement) deutschsprachiger Unternehmen (Online-Befragung von 873 zufällig ausgewählten Fach- und Führungskräften, 329 auswertbare Antworten, Untersuchungszeitraum Ende 2009 bis Anfang 2010). Die Autoren führten eine Aufgabenanalyse durch, bildeten Aufgabentypenklassen und entsprechende Gruppen von Aufgabenträgern. Dabei wurde festgestellt, dass eine eindeutige Zuordnung von Aufgaben im Produktionsbereich in die Kategorien operativ und strategisch nicht sinnvoll ist. Stattdessen wurden zwei Zwischenformen eingeführt: (a) „Strategische Aufgaben mit operativer Auswirkung sind in diesem Zusammenhang solche, die im strategischen Kontext getroffen werden, sich jedoch durch einen hohen Wiederholungsgrad, strukturierte Informationen“ (458) und eine hohe Automatisierbarkeit charakterisieren lassen. Diese haben vielfach direkte Auswirkungen auf operative Aufgaben. (b) Unter operativen Aufgaben mit strategischer Auswirkung verstehen die Autoren „solche, die im eher operativen Umfeld zu fällen sind und sich auf die Marktposition und Ressourcenbasis eines Unternehmens auswirken und somit Einfluss auf die Erfolgspotentiale“ des Unternehmens (458) haben. Die Autoren unterscheiden vier Klassen von Aufgabenträgern, die sich in ihrem objektiven Informationsbedarf unterscheiden:    

Die Unternehmensführung (z. B. Vorstand, Geschäftsleitung) ist zuständig für strategische Aufgaben der Produktion. Die erste Führungsschicht des Produktionsmanagements (z. B. Produktionsleiter, Werksleiter) übernimmt strategische Aufgaben mit operativen Auswirkungen in der Produktion. Die zweite Führungsschicht des Produktionsmanagements (z. B. Bereichsleiter, Meister, Teamleiter) hat operative Aufgaben mit strategischen Auswirkungen. Die Ausführungsschicht (z. B. Facharbeiter) übernimmt operative Aufgaben in der Produktion.

Es wurde untersucht, inwieweit der Informationsbedarf der Aufgabenträgerklassen durch das Informationsangebot befriedigt wird und wie zufrieden die Befragten mit der Qualität des Informationsangebots sind. Im Hinblick auf Art und Menge des Informationsangebots wurde erhoben, welche Informationen (z. B. in Form von Kennzahlen), die in der Fachliteratur (vgl. z. B. Gienke) als relevant bezeichnet werden, zur Lösung der Aufgaben im Produktionsbereich verfügbar sind. Obwohl nahezu alle für die Aufgabenerfüllung relevanten Informationen in Industriebetrieben erfasst und gespeichert werden, stehen diese den Aufgabenträgern zur Lösung ihrer Aufgaben nur teilweise zur Verfügung. In keiner der vier Klassen der Aufgabenträger wird der Informationsbedarf vollständig befriedigt. Die Zufriedenheit der Aufgabenträger mit der Informationsqualität (vgl. Lerneinheit DATEM) wurde mit acht verschiedenen Merkmalen beurteilt, die in drei Gruppen eingeteilt wurden:

Informationsbedarfsanalyse (INBAN)







433

Detaillierungsgrad verfügbarer Daten, Möglichkeit des Zugriffs auf historische Daten, Verfügbarkeit / Vollständigkeit von Daten, flexible Analysemöglichkeiten sowie Zeitaufwand zur Datenbeschaffung: Mitarbeiter mit operativen und Führungskräfte mit strategischen Aufgaben sind im Durchschnitt zufriedener mit den Ausprägungen dieser Merkmale des Informationsangebots als Aufgabenträger der ersten und zweiten Führungsschicht. Mitarbeiter mit operativen Aufgaben sind unzufriedener mit Aktualität und Relevanz der Daten als Mitglieder der ersten und zweiten Führungsschicht. Mitglieder der Unternehmensführung haben die höchste Zufriedenheit mit den Ausprägungen dieser Qualitätsmerkmale. Mitarbeiter mit operativen Aufgaben (Ausführungsschicht und zweite Führungsschicht) sind mit der „Richtigkeit“ der Daten zufriedener als Führungskräfte (erste Führungsschicht und Unternehmensführung).

Das unbefriedigende Informationsangebot ist nicht auf einen Mangel an bestimmten „ITSystemen“ zurückzuführen. Weder Unternehmen, die viele IT-Systeme im Einsatz haben, noch Unternehmen, die eine geringere Anzahl an IT-Systemen einsetzen, unterscheiden sich maßgeblich in der Zufriedenheit der Fach- und Führungskräfte mit der Informationsversorgung. Die Autoren schließen daraus, dass vor der Entwicklung der IT-Systeme keine aufgabenorientierte Informationsbedarfsanalyse durchgeführt wurde und es einen Bedarf an einem differenzierten Informationsversorgungskonzept gibt.

Aus der Praxis Nusselein beschreibt die im Rahmen eines Projekts zur Entwicklung von Data Warehousebasierten Berichtssystemen für das Bayerische Staatsministerium für Wissenschaft, Forschung und Kunst sowie für die Hochschulen in Bayern entwickelte Methodenkombination zur Informationsbedarfsanalyse. Diese besteht aus folgenden Schritten:     

Organisationsanalyse zur Ermittlung relevanter Zielgruppen sowie deren Aufgaben und Entscheidungskompetenzen, Interviews mit Entscheidungsträgern zur Ergänzung des Aufgabenprofils und zur Ermittlung des subjektiven Informationsbedarfs, Aufgabenanalyse zur Ermittlung des objektiven Informationsbedarfs, schriftliche Befragung der Entscheidungsträger zur Überprüfung und Bewertung der Ergebnisse und zur Konkretisierung des Informationsbedarfs und ein Workshop zur Diskussion und abschließenden Formulierung der Ergebnisse der Informationsbedarfsanalyse. Organisationsanalyse zur Ermittlung relevanter Zielgruppen

Interviews mit Entscheidungsträgern

Aufgabenanalyse

schriftliche Befragung der Entscheidungsträger

Workshop zur Diskussion der Ergebnisse

Abb. INBAN-2: Methodenkombination zur Informationsbedarfsanalyse (Quelle: nach Nusselein)

434

Methoden des administrativen Informationsmanagements

Aufgabenverweise Architektur (Lerneinheit ARCHI); Informationsverhalten (Lerneinheit INVER); Zielplanung (Lerneinheit SZIEL); Strategieentwicklung (Lerneinheit STRAT); Qualitätsmanagement (Lerneinheit QUALM); Datenmanagement (Lerneinheit DATEM); Geschäftsprozessmanagement (Lerneinheit GPMAN); Servicemanagement (Lerneinheit SEMAN). Kontrollfragen 1. Welche Gründe können dazu führen, dass objektiver und subjektiver Informationsbedarf nicht übereinstimmen? 2. Warum werden bestimmte Informationen nicht nachgefragt, obwohl sie für die Erfüllung einer Aufgabe hilfreich sind und vom Aufgabenträger für relevant gehalten werden? 3. Welche Methode eignet sich zur Ermittlung des Informationsbedarfs, wenn Art und Zusammensetzung der Nutzergruppe weitgehend unbekannt ist? 4. Welche Eigenschaften hat der Informationsbedarf, der mit Hilfe der Methode der kritischen Erfolgsfaktoren ermittelt werden kann? 5. Welchen Beitrag kann die 6-W-Methode zu einer Informationsbedarfsanalyse leisten? Quellen Beiersdorf, H.: Informationsbedarf und Informationsbedarfsermittlung im Problemlösungsprozeß "Strategische Unternehmensplanung". München/Mering 1995 Berthel, J.: Informationsbedarf. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Stuttgart 1992, 872– 886 Feldman, S. et al.: The Hidden Costs of Information Work. IDC Whitepaper. Framingham 2005. http://www.scribd.com; Abruf 28. Juni 2011 Gienke, H.: Produktionscontrolling. In: Gienke, H. /Kämpf, R. (Hrsg.): Handbuch Produktion. Innovatives Produktionsmanagement: Organisation, Konzepte, Controlling. München 2007, 745–848 Heinrich, L. J. / Heinzl, A. / Riedl, R.: Wirtschaftsinformatik. Einführung und Grundlegung. 4. A., Heidelberg 2010, 177–189 Hurtienne, J. / Prümper, J.: Vom Zauberer zum Partner - Usability Beratung im Spiegel organisationaler Reife. In: Nissen, V. (Hrsg.): Consulting Research. Unternehmensberatung aus wissenschaftlicher Perspektive. Wiesbaden 2007, 335–353 Kluck, M.: Methoden der Informationsanalyse – Einführung in die empirischen Methoden für die Informationsbedarfsanalyse und die Markt- und Benutzerforschung. In: Kuhlen, R. / Seeger, T. / Strauch, D. (Hrsg.): Grundlagen der praktischen Information und Dokumentation. Handbuch zur Einführung in die Informationswissenschaft und -praxis. 5. A., München 2004, 271–288 Koch, M. / Lasi, H. / Kemper, H.-G.: Informationsmanagement in der Produktion - Empirische Ableitung eines Konzepts zur Ermittlung produktionsspezifischer Informationsbedarfe. In: Bernstein, A. / Schwabe, G. (Hrsg.): Proceedings of the 10th International Conference on Wirtschaftsinformatik WI 2.011. Volume 1. Zürich 2011, 456–465 Koreimann, D. S.: Methoden der Informationsbedarfsanalyse. Berlin/New York 1976 Koreimann, D. S.: Grundlagen der Software-Entwicklung. 3. A., München/Wien 2000 Nusselein, M.: Empirische Erkenntnisse einer Informationsbedarfsanalyse an bayerischen Hochschulen. In: Beiträge zur Hochschulforschung 1/2002, 100–114 Rockart, J. F.: Chief executives define their own data needs. In: Harvard Business Review 2/1979, 81–93 Topi, H. / Lucas, W. / Babaian, T.: Identifying Usability Issues with an ERP Implementation. In: Proceedings of the 7th International Conference on Enterprise Information Systems. Miami, USA 2005, 128–133 Vertiefungsliteratur Nicholas, D.: Assessing Information Needs: Tools, Techniques and Concepts for the Internet Age. 2. A., London 2000 Schoppek, W. / Putz-Osterloh, W.: Informationsverhalten. In: Schreyögg, G. / v. Werder, A. (Hrsg.): Handwörterbuch Unternehmensführung und Organisation. 4. A., Stuttgart 2004, 489–497 Informationsmaterial Luckhardt, H.-D.: Virtuelles Handbuch Informationswissenschaft. Nutzungs- und Bedarfsanalyse. Universität des Saarlandes. Philosophische Fakultäten. FR 5.6 Informationswissenschaften. http://is.uni-sb.de; Abruf 28. Juni 2011 o. V.: Assessing Information Needs. George Mason University. Management of Health Information Systems. http://gunston.gmu.edu; Abruf 28. Juni 2011

Methoden des Geschäftsprozessmanagements (MEGPM) Lernziele Sie können ausgewählte Methoden des Geschäftsprozessmanagements (GPM) mit ihren wesentlichen Eigenschaften erläutern. Sie haben einen Überblick über Sprachen, Referenzmodelle und Werkzeuge zur Modellierung von Geschäftsprozessen. Sie wissen, mit welchen Hilfsmitteln Prozesse implementiert und automatisiert werden können. Sie kennen die Bedeutung des Benchmarking und der Balanced Scorecard für die Prozessevaluierung.

Definitionen und Abkürzungen ARIS = Architektur integrierter Informationssysteme. BPEL = Business Process Execution Language. BPML = Business Process Modeling Language. BPMN = Business Process Modeling Notation. BPR = Business Process Reengineering. BSC = Balanced Score Card (oder Balanced Scorecard); ein kennzahlenbasiertes Führungsinstrument. CASE = Computer Aided Software Engineering. EPK (event-driven process chain) = ereignisgesteuerte Prozesskette; Modellierungssprache für Geschäftsprozesse. eEPK = erweiterte ereignisgesteuerte Prozesskette. GPM = Geschäftsprozessmanagement. OASIS = Organization for the Advancement of Structured Information Standards; internationales Konsortium, das IT-Standards entwickelt. OMG = Object Management Group; Konsortium von IT-Herstellern, das Standards für die herstellerunabhängige Entwicklung von Informationssystemen verfasst.. Prozesskostenrechnung (process cost allocation) = Verrechnung der nicht direkt zurechenbaren Kosten auf Produkte und Dienstleistungen proportional zu den Prozessmengen, die sie beansprucht haben. SCM = Supply Chain Management; Lieferkettenmanagement. SCOR = Supply-Chain-Operations-Reference-Modell; Referenzmodell zur Gestaltung von überbetrieblichen Geschäftsprozessen im Rahmen des SCM. SOA = serviceorientierte Architektur. UML = Unified Modeling Language. Web Service = Softwarekomponente, die mit Hilfe von Internettechnologien einen Dienst zur Verfügung stellt. WfMC = Workflow Management Coalition. Workflow = ausführbares Abbild eines Geschäftsprozesses. XML = Extensible Markup Language. XPDL = XML Process Definition Language.

436

Methoden des administrativen Informationsmanagements

Zweck der Methoden des GPM Die in dieser Lerneinheit beschriebenen Methoden unterstützen die Erreichung der Ziele des Geschäftsprozessmanagements, insbesondere die Reduzierung des Zeitbedarfs und der Kosten für die Ausführung von Prozessen sowie die Erhöhung der Qualität der Prozessergebnisse. Die Methoden helfen, relevante Prozesse zu identifizieren, zu analysieren und voneinander abzugrenzen. Modellierungssprachen, Referenzmodelle und Softwarewerkzeuge unterstützen die Modellierung, Implementierung und Automatisierung von Geschäftsprozessen. Methoden zur Prozessevaluierung und -verbesserung werden dazu verwendet, Geschäftsprozesse kontinuierlich weiter zu entwickeln.

Prozessidentifizierung

Produktinnovation

Gebäudemanagement

Kundendienst

hoch niedrig Beitrag zum Kundennutzen

Beitrag zum Unternehmenserfolg hoch niedrig

Finanzmanagement Personalwesen

niedrig

Beitrag zum Finanzerfolg

hoch

Methoden zur Prozessidentifizierung dienen dazu, Kernprozesse von Führungs- und Unterstützungsprozessen zu unterscheiden (vgl. Lerneinheit GPMAN). Außerdem werden sie dazu verwendet, Geschäftsprozesse zu identifizieren, die mit hoher Priorität verbessert bzw. durch neue Technologien unterstützt werden sollen. Zu diesem Zweck kann die Portfoliotechnik verwendet werden. Das linke Portfolio in Abbildung MEGPM-1 folgt den Empfehlungen von Kaplan/Norton und gruppiert Prozesse nach ihrem Beitrag zum Finanzerfolg und zum Kundennutzen. Prozesse, die sowohl einen hohen Beitrag zum Finanzerfolg als auch zum Kundennutzen leisten, werden mit hoher Priorität geplant, gesteuert, kontrolliert und verbessert. Das rechte Portfolio unterscheidet Geschäftsprozesse anhand ihres Erfolgsbeitrags und Verbesserungspotenzials. Geschäftsprozesse, die einen hohen Beitrag zum Unternehmenserfolg leisten und bei denen ein hohes Verbesserungspotenzial festgestellt wurde, sind die wichtigsten Kandidaten für eine Prozessverbesserung.

Prozesse pflegen (hohe Priorität)

Prozesse verbessern (hohe Priorität)

Prozesse Prozesse pflegen verbessern (geringe Priorität) (geringe Priorität) niedrig Verbesserungspotenzial

Abb. MEGPM-1: Geschäftsprozess-Portfolien

hoch

Methoden des Geschäftsprozessmanagements (MEGPM)

437

Prozessanalyse Die Prozessanalyse zerlegt Geschäftsprozesse in Teilprozesse, Prozess- und Arbeitsschritte. Letztere werden auch als Aktivitäten, Operationen oder Tätigkeiten bezeichnet. Der linke Teil der Abbildung MEGPM-2 zeigt schematisch die Zerlegung eines Geschäftsprozesses und der rechte Teil beispielhaft die Dekomposition eines Teils der Auftragsbearbeitung. Geschäftsprozess

Auftragsabwicklung

Teilprozess 1

Bestellung prüfen

Teilprozess 2

Material bereitstellen

Prozessschritt 2.1

Disponieren

Prozessschritt 2.2

Beschaffen

Arbeitsschritt 2.2.1

Lieferanten auswählen

Arbeitsschritt 2.2.2

Material bestellen

Arbeitsschritt 2.2.3

Material annehmen

Prozessschritt 2.3 Teilprozess 3

Abrufen Produkt fertigen

Abb. MEGPM-2: Dekomposition eines Geschäftsprozesses (Quelle: Schmelzer/Sesselmann)

Zur Darstellung der Beziehungen der Prozesselemente untereinander eignen sich Methoden der Prozessmodellierung, die im folgenden Abschnitt dargestellt werden.

Prozessmodellierung Prozessmodellierung bedeutet, bestimmte Merkmale von Geschäftsprozessen oder deren Elementen in einem Modell abzubilden. Welche Merkmale in Prozessmodellen abgebildet werden, hängt vom Modellierungszweck und der verwendeten Modellierungssprache ab. Typische, in Prozessmodellen dargestellte Merkmale sind:     

Ereignisse, die den Prozess bzw. einzelne Aktivitäten auslösen, Teilprozesse, Prozess- und Arbeitsschritte sowie deren Beziehungen zueinander, bei der Ausführung des Prozesses verwendete Ressourcen, insbesondere Datenbestände und Informationssysteme, Aufgabenträger bzw. Rollen und Organisationseinheiten sowie Material- und Informationsflüsse.

Zur Unterstützung der Prozessmodellierung werden Modellierungssprachen, Referenzmodelle und Modellierungswerkzeuge verwendet.

Modellierungssprachen Prozessmodelle können in Form von Texten, Tabellen oder Grafiken dargestellt werden. Üblicherweise wird eine Modellierungssprache verwendet, die eine – meist semiformale – Notation zur Abbildung von Geschäftsprozessen zur Verfügung stellt. Es stehen viele ver-

438

Methoden des administrativen Informationsmanagements

schiedene Modellierungssprachen zur Verfügung (vgl. zu einem Überblick Gadatsch, 66 ff.). Im Folgenden wird eine Auswahl von Sprachen dargestellt. Wertketten- oder Wertschöpfungskettendiagramme sind von Porter publiziert worden. Sie bilden Teilprozesse auf einem hohen Abstraktionsniveau ab. Ein Wertkettendiagramm kann in Teilprozesse zerlegt werden, bis eine weitere Unterteilung nicht mehr sinnvoll ist. Wertkettendiagramme eignen sich in erster Linie, um einen Überblick über die Elemente von Prozessen zu bekommen, nicht aber um Teilprozesse mit Prozess- und Arbeitsschritten sowie deren Interdependenzen im Detail darzustellen. EPK sind zur detaillierten Modellierung von Geschäftsprozessen und Prozesselementen gut geeignet. Die EPK-Notation ist 1992 von einer Arbeitsgruppe unter der Leitung von Scheer entwickelt worden. EPK sind das in ARIS verwendete Darstellungsmittel (Scheer). Der Schwerpunkt liegt auf dem Kontrollfluss von Prozessen. Wesentliche Darstellungsmittel sind Ereignisse, Funktionen und Verknüpfungsoperatoren. In eEPK können weitere Merkmale eines Prozesses abgebildet werden (z. B. Organisationseinheiten, Rollen von Mitarbeitern sowie Datenbestände bzw. Informationssysteme). Die Darstellung von Prozessen als EPK oder eEPK kann sehr umfangreich werden. Entwicklung und Pflege umfangreicher Modelle sind ohne Softwarewerkzeuge nicht praktikabel. Die UML ist eine Sprache zur Spezifikation, Modellierung und Dokumentation von objektorientierten Softwaresystemen (Oestereich). Sie ist aus drei Vorgängersprachen hervorgegangen und wird seit 1997 durch die OMG weiter entwickelt. Die UML umfasst mehr als zehn verschiedene Diagrammarten. Für die Modellierung von Geschäftsprozessen eignen sich Anwendungsfall- (bzw. Use-Case-) und Aktivitäts- (bzw. Activity-)Diagramme. Anwendungsfalldiagramme stellen Interaktionen zwischen Akteuren und Softwaresystemen in Form von Anwendungs- bzw. Geschäftsvorfällen dar. Akteure können Personen, Informationssysteme oder andere Prozesse sein. Use Case Diagramme sind gut geeignet, um einzelne Geschäftsvorfälle, d. h. Teilprozesse, Prozess- oder Arbeitsschritte, im Überblick darzustellen. Aktivitätsdiagramme stellen einzelne Arbeits- bzw. Prozessschritte detailliert dar. Sie ähneln Programmablaufplänen und bilden Verbindungen zwischen Aktivitäten in Form von Kontrollflüssen ab. Die BPML ist eine von der OMG gepflegte XML-basierte Modellierungssprache, mit der einzelne Web Services zur Automatisierung von Prozessen oder Prozesselementen verknüpft werden können. Eine grafische Darstellung der Prozesse ist mit der BPMN möglich. BPMN wurde durch die Business Process Management Initiative (BPMI) definiert. Diese Initiative ist 2005 in der OMG aufgegangen. Seit 2006 ist BPMN ein Standard der OMG. Darstellungsmittel der BPMN sind Flow Objects (Ereignisse, Entscheidungspunkte und Aktivitäten), Connecting Objects (Verbindungselemente), Swimlanes (Bereiche, die darstellen, welche Aktivitäten durch welche Rollen bzw. Organisationseinheiten ausgeführt werden) und Artifacts (Kommentare, Datenbestände und Zusammenfassungen von Geschäftsprozesselementen). Eine Besonderheit der BPMN besteht in der Verbindungsmöglichkeit zu Ausführungssprachen. Maschinell lesbare Prozessbeschreibungen ermöglichen die Ausführung von Workflows mit Hilfe von Softwaresystemen. Die bekanntesten Vertreter sind die XML-basierten Sprachen

Methoden des Geschäftsprozessmanagements (MEGPM)

439

Business Process Execution Language (BPEL) und XML Process Definition Language (XPDL). BPEL ermöglicht die Beschreibung von Prozessen, deren Elemente durch Web Services implementiert sind. Sie wird in erster Linie für die so genannte Orchestrierung, d. h. Koordination von Web Services verwendet. XPDL unterstützt die Speicherung von in BPMN notierten Prozessdarstellungen, deren Austausch zwischen verschiedenen Plattformen sowie die Ausführung der Prozesse.

Referenzmodelle Referenzmodelle für Geschäftsprozesse bilden gewollte oder geplante Zustände von Prozessen ab, an denen ihr gegenwärtiger Zustand beurteilt werden kann. Sie dienen auch als Vorbilder zur Ableitung, Planung und zum Entwurf neuer Prozesse. Durch die Verwendung von Referenzmodellen können Zeitbedarf und Kosten für den Prozessentwurf reduziert werden, z. B. im Zusammenhang mit der Einführung von Standardsoftware. Referenzmodelle sind für verschiedene betriebliche Aufgabenbereiche (wie Beschaffung, Produktion und Vertrieb) sowie Branchen (z. B. die Referenzmodelle für Industriebetriebe von Scheer, das so genannte Handels-H von Becker/Schütte oder das Consulting-C von Nissen/Seifert) entwickelt worden. Das Workflow Reference Model wurde 1995 von der WfMC entwickelt. Es erlaubt die Beschreibung von Schnittstellen in Workflow-Managementsystemen. Dadurch können komplexe Geschäftsprozesse durch heterogene Workflow-Managementsysteme verschiedener Hersteller unterstützt werden. Das SCOR ist ein Referenzmodell für Geschäftsprozesse im Rahmen des Supply Chain Managements. Es hilft, Lieferkettenaktivitäten zu beschreiben, zu analysieren, zu modellieren und zu evaluieren. Für die Evaluierung von Lieferketten werden im SCOR Kennzahlen definiert. Darüber hinaus bietet das SCOR Anhaltspunkte für die Unterstützung von Prozesselementen durch Software.

Modellierungswerkzeuge Nägele/Schreiner teilen Werkzeuge zur Modellierung von Geschäftsprozessen nach deren Funktionsschwerpunkt in die Klassen Visualisierung, Modellierung, Simulation und Workflowmanagement ein. (Die von den beiden Autoren ebenfalls erörterten CASE-Werkzeuge werden hier nicht behandelt.) Visualisierungswerkzeuge für Geschäftsprozesse ermöglichen es, vorgefertigte Symbole zur Abbildung von Prozesselementen darzustellen und miteinander zu verbinden. Die Werkzeuge sind einfach zu bedienen, die Pflege der darin abgebildeten Modelle ist allerdings sehr aufwendig. Visualisierungswerkzeuge eignen sich deshalb insbesondere für Analyse und Entwurf wenig umfangreicher Prozesse, die für einen klar abgegrenzten Zweck dargestellt und nicht mehrmals verwendet werden sollen. Beispiele für solche Werkzeuge sind Visio (Microsoft) und iGrafx FlowCharter (Corel Inc.). Modellierungswerkzeuge unterstützen in der Regel verschiedene Notationen zur Abbildung von Geschäftsprozessen und ermöglichen es, Geschäftsprozessmodelle in Ebenen bzw. Sichten zu gliedern. Die Funktionen dieser Werkzeuge gehen weit über die reine Darstellung von Geschäftsprozessen hinaus. Sie bieten z. B. die Möglichkeit, Metadaten zu Prozessen und

440

Methoden des administrativen Informationsmanagements

deren Elementen zu speichern und zu verwalten. Darüber hinaus können viele Werkzeuge Zeit-, Kosten- und Kapazitätsanalysen unterstützen. Modellierungswerkzeuge verfügen häufig über Schnittstellen zu ERP- und Workflow-Managementsystemen. Zum Teil bieten die Hersteller der Werkzeuge Referenzmodelle an, welche die Ableitung individueller Prozessmodelle vereinfachen. Modellierungswerkzeuge eignen sich, wenn verschiedene Personen über längere Zeiträume mit den Modellen arbeiten und diese mehrfach oder für unterschiedliche Einsatzzwecke verwendet werden sollen, z. B. zur Geschäftsprozessevaluierung und -verbesserung, zur Vorbereitung einer Softwareeinführung, zur Dokumentation im Rahmen des Qualitätsmanagements (vgl. Lerneinheit QUALM), zu Schulungszwecken oder zur Erstellung von IT-Architekturen (vgl. Lerneinheit ARCHI). Beispiele sind ARIS (Software AG), Bonapart (BTC AG), Corporate Modeler (Casewise), ibo Prometheus (IBO Software), MEGA Process (MEGA International) sowie iGrafx Process (Corel). Simulationswerkzeuge unterstützen das Experimentieren mit Geschäftsprozessmodellen. Die Werkzeuge ermöglichen das Abbilden von Prozessen in Form von Modellen, an denen Simulationsexperimente durchgeführt werden können. Gadatsch (188) unterscheidet drei Ziele der Prozesssimulation: Überprüfung der Ablauffähigkeit von Prozessmodellen, Validierung der Realitätstreue von Prozessmodellen und Evaluierung alternativer Prozessmodelle. Mögliche Kenngrößen zur Evaluierung von Prozessen sind Durchlaufzeiten, Kapazitätsauslastungen und Prozesskosten. Werkzeuge zur Simulation von Geschäftsprozessen können Bestandteile von Modellierungs- oder von Workflow-Managementwerkzeugen oder spezielle Simulationswerkzeuge sein. Beispiele sind Arena (Rockwell Automation), Corporate Modeler (Casewise), Flexsim (Flexsim Software Products) sowie iGrafx Process (Corel). Workflow-Managementwerkzeuge unterstützen die Ausführung gut strukturierter Geschäftsprozesse, die sich durch eine hohe Wiederholhäufigkeit und Aufgabenteilung der Aufgabenträger auszeichnen. Sie ermöglichen es, Prozessmodelle zu beschreiben oder stellen Schnittstellen zu Modellierungswerkzeugen zur Verfügung. Die Werkzeuge stellen in der Regel selbst keine Funktionalität zur operativen Bearbeitung der Aufgaben zur Verfügung, ermöglichen den Aufgabenträgern aber den Zugriff auf notwendige Ressourcen. Beispiele für Workflow-Managementwerkzeuge sind IBM WebSphere MQ Workflow, Oracle Workflow und SAP Business Workflow.

Prozessimplementierung und -automatisierung Workflowmanagement- und Enterprise-Resource-Planning-Systeme, Middleware und Enterprise Application Integration sowie serviceorientierte Architekturen sind Hilfsmittel, die sich zur Unterstützung von Geschäftsprozessen eignen. Enterprise-Resource-Planning-Systeme (ERP-Systeme) sind integrierte betriebswirtschaftliche Standardanwendungssoftware. Wesentliche Aufgaben eines Unternehmens (wie z. B. Finanz- und Rechnungswesen, Personal- und Materialwirtschaft, Produktionsplanung und steuerung sowie Vertrieb) werden durch ERP-Systeme unterstützt. Da die verschiedenen Komponenten eines solchen Systems bereits vom Entwickler aufeinander abgestimmt sind und auf gemeinsam genutzte Datenbanken zugreifen, ermöglichen ERP-Systeme eine prozessorientierte Gestaltung betrieblicher Aufgaben.

Methoden des Geschäftsprozessmanagements (MEGPM)

441

In der Regel werden Geschäftsprozesse allerdings nicht oder nicht ausschließlich durch integrierte Standardsoftware, sondern durch heterogene Softwaresysteme unterstützt, deren Funktionen nur unzureichend integriert sind, und die nicht immer auf einheitliche Datenbestände zugreifen. Mit Hilfe von Middleware können diese Systeme integriert werden, um Geschäftsprozesse besser zu unterstützen. Middleware ist ein Sammelbegriff für verschiedene Betriebssystem nahe Softwarearten, die den Austausch von Daten zwischen heterogenen Programmen und Datenbanken in verteilten IT-Systemen ermöglichen. Enterprise Application Integration baut auf Middleware auf und ermöglicht die geschäftsprozessorientierte Integration von heterogenen Anwendungssystemen. Enterprise Application Integration erweitert die Funktionalität von Middleware um Steuerungsmechanismen, mit deren Hilfe Prozesselemente, die von verschiedenen Anwendungssystemen unterstützt werden, zentral integriert werden können.

Anwendungssystem-Schicht

Service-Schicht

GeschäftsprozessSchicht

Serviceorientierte Architekturen (SOA) sind Architekturen (vgl. Lerneinheit ARCHI), die sich aus einzelnen Services zusammensetzen. Aus der fachlichen Perspektive betrachtet, sind Services klar umrissene Aufgaben, Arbeits- oder Prozessschritte. Sie können unterschiedlich umfangreich sein. Ein Service kann eine eng abgegrenzte Aufgabe (z. B. eine Währungskonvertierung) übernehmen oder eine umfangreiche, komplexe Aufgabe (z. B. Lohn- und Gehaltsabrechnung). Aus softwaretechnischer Sicht ist ein Service eine wiederverwendbare, gekapselte Softwarefunktion, die über eine definierte Schnittstelle angesprochen werden kann. Abbildung MEGPM-3 zeigt drei Schichten einer SOA.

Abb. MEGPM-3: Schichten einer serviceorientierten Architektur (Quelle: nach Erl 2005)

Die Geschäftsprozess-Schicht bildet einen Geschäftsprozess oder einen Teil davon ab. Die Service-Schicht stellt Dienste zur Verfügung, welche Geschäftsprozesse oder Prozessele-

442

Methoden des administrativen Informationsmanagements

mente unterstützen. Die Service-Schicht ist in drei Ebenen eingeteilt. Dies weist darauf hin, dass Services aus anderen Services zusammengesetzt sein können. In diesem Zusammenhang spricht man von Servicekomposition. Die Anwendungssystem-Schicht zeigt Komponenten von Anwendungssystemen, die Softwarefunktionen zur Unterstützung der Geschäftsprozesse zur Verfügung stellen. In einer SOA können heterogene IT-Systeme flexibel zusammengestellt werden, selbst wenn sie mit unterschiedlichen Technologien implementiert wurden und auf verschiedenen Plattformen ablaufen. Mit dem Einsatz von SOA wird die Erwartung verbunden, schneller auf veränderte fachliche Anforderungen reagieren zu können. Bei einer Veränderung von Geschäftsprozessen soll die IT-Unterstützung durch eine neue Komposition von Services schneller und flexibler erreicht werden als durch die Anpassung traditioneller, monolithischer Softwaresysteme (vgl. zu einer kritischen Analyse der Erfahrungen mit SOA Schlimm).

Prozessevaluierung Methoden zur Evaluierung von Geschäftsprozessen sind Audits und Reviews, Prozesskostenrechnung, Benchmarking und die Balanced Scorecard. Reviews und Audits werden in Lerneinheit MEQUA und Prozesskostenrechnung in Lerneinheit KOLER behandelt. Die folgenden Ausführungen konzentrieren sich auf Benchmarking und die Balanced Scorecard. Benchmarking bezeichnet das Messen von Prozesseigenschaften und Vergleichen der Messergebnisse mit denen von Referenzprozessen (möglichst mit dem „besten Prozess“, also „Best Practice“). Ziel des Benchmarking ist es, Ausprägungen relevanter Prozesseigenschaften mit denen der Referenzprozesse zu vergleichen, um Optionen für Prozessverbesserungen zu identifizieren. Als Referenzprozesse kommen Prozesse im (internes Benchmarking) oder außerhalb des eigenen Unternehmens (externes Benchmarking) in Frage. In dieser Lerneinheit sind die Benchmarking-Objekte Geschäftsprozesse, bei denen ein nennenswertes Verbesserungspotenzial vermutet wird. Das können Geschäftsprozesse sein, bei denen die Kundenzufriedenheit besonders gering und der Wettbewerbsdruck besonders hoch ist oder bei denen die größten Potenziale für Kostensenkung, Beschleunigung oder Qualitätsverbesserung vermutet werden. Besonders erfolgskritisch für ein Benchmarking-Projekt ist die Auswahl geeigneter Benchmarking-Partner. Da Benchmarking die Suche nach und Orientierung an den Best Practices ist, sind Marktführer die besten Kandidaten, insbesondere dann, wenn sie Mitbewerber sind. Die Schwierigkeit, diese als Partner zu gewinnen, liegt auf der Hand. Häufig sind auch Unternehmen anderer Branchen geeignete Partner, insbesondere dann, wenn es um das Benchmarking von Geschäftsprozessen geht, die trotz der Branchenverschiedenheit im Wesentlichen gleich sind (z. B. Transport und Logistik, Forschung und Entwicklung, IT-Unterstützung von Routineaufgaben). In großen, weltweit agierenden Konzernen bieten sich auch Unternehmen des gleichen Konzerns als geeignete Partner an. In Lerneinheit KENNZ wird die Balanced Scorecard (BSC) von Kaplan/Norton als Referenzsystem für die Entwicklung von Kennzahlensystemen und zur Umsetzung von Strategien dargestellt. Eine der vier Perspektiven der BSC hat die Geschäftsprozesse eines Unternehmens zum Gegenstand. Im Rahmen dieser Perspektive wird thematisiert, welche Geschäftsprozesse maßgeblichen Einfluss auf die Erreichung der vom strategischen Management vorgegebenen Ziele haben. Zu diesem Zweck werden Ursache/Wirkungs-Beziehungen zwischen

Methoden des Geschäftsprozessmanagements (MEGPM)

443

Merkmalen relevanter Prozesse und strategischen Zielen des Unternehmens identifiziert. Abbildung MEGPM-4 zeigt einen Ausschnitt aus einem solchen Zusammenhang. Genauigkeit der Terminplanung

Umsatzerhöhung

Kundenzufriedenheit

Termintreue

Intensität der Terminkontrollen

Lieferzeiten

…

Produktqualität

Fehlerquellen in der Produktion Intensität der Produktprüfung

Abb. MEGPM-4: Ursache/Wirkungs-Beziehung Umsatzerhöhung

Auf der Grundlage von Ursache/Wirkungs-Beziehungen können Kennzahlen definiert, aktuelle Ausprägungen (Ist-Werte) erhoben, Zielgrößen (Soll-Werte) bestimmt und Maßnahmen geplant werden, die notwendig sind, um die Ziele zu erreichen. Abbildung MEGPM-5 zeigt Beispiele für Ziele, Kennzahlen und Maßnahmen. Ziel

Kennzahl

Ist / Ziel

Maßnahmen

Erhöhung der Termintreue

Anteil pünktlicher Leistungen an der Gesamtzahl der Leistungen

88 % / 97 %

Verbesserung der Terminplanung Intensivierung der Terminkontrollen

Verkürzung der Lieferzeiten

Durchschnittlicher Zeitbedarf vom Auftragseingang bis zur Leistungserbringung

12 Werktage / 5 Werktage

Umstellung von Pushauf Pull-Prinzip Verbesserung des Informationsflusses

Erhöhung der Produktqualität

Anteil fehlerhafter Produkte an der Gesamtzahl der gelieferten Produkte

0,5 % / 0,1 %

Beseitigung von Fehlerquellen im Produktionsprozess Intensivierung der Produktprüfung

Abb. MEGPM-5: Ziele, Kennzahlen und Maßnahmen in einer Balanced Scorecard

Neben der Identifikation von Maßnahmen muss die Verantwortung für deren Umsetzung geklärt werden. Die jeweiligen Mitarbeiter sind dafür verantwortlich, dass entsprechende Projekte zur Prozessverbesserung geplant, gesteuert, durchgeführt und kontrolliert werden.

444

Methoden des administrativen Informationsmanagements

Prozessverbesserung Methoden zur Verbesserung von Geschäftsprozessen werden insbesondere im Qualitätsmanagement vorgeschlagen. Als Leitlinie bietet sich der Plan-Do-Check-Act-Zyklus (vgl. Lerneinheit QUALM) an. Reifegradmodelle wie das CMMI (vgl. Lerneinheit MEQUA) können ebenfalls verwendet werden. Dementsprechend können Geschäftsprozesse in folgende Reifegrade eingeteilt werden (Software Engineering Institute).   





1 (Initial): Es gibt keine einheitlichen Vorgaben für das GPM. Prozesse werden ad hoc geplant, gesteuert und kontrolliert. Das Ausmaß der Zielerreichung hängt wesentlich von der Erfahrung und vom Engagement der Mitarbeiter ab. 2 (Managed): Geschäftsprozesse werden auf der Grundlage eines Prozessmodells geplant, gesteuert und kontrolliert. Das Ausmaß der Zielerreichung wird transparent dargelegt und ist für das Management nachvollziehbar. 3 (Defined): Geschäftsprozesse folgen einem standardisierten und unternehmensweit gültigen Prozessmodell. Darin sind Ziele, Eingaben, Startbedingungen, Aktivitäten, Rollen, Maßnahmen, Prüfkriterien, Ausgaben und Endbedingungen beschrieben. Geschäftsprozesse und deren Management werden kontinuierlich verbessert. 4 (Quantitatively Managed): Es werden quantitative Ziele für Geschäftsprozesse formuliert, ihre Erreichung wird im Rahmen eines unternehmensweiten Messprogramms überprüft. Die Wirkungen von Maßnahmen des GPM auf relevante Ziele sind in Form von Ursache/Wirkungs-Beziehungen quantitativ formuliert. 5 (Optimizing): Das Unternehmen verbessert auf der Basis der in Reifegrad 4 etablierten quantitativen Beschreibung von Ursache/Wirkungs-Beziehungen kontinuierlich alle Geschäftsprozesse. Für die Prozessverbesserung werden quantitative Ziele vorgegeben, deren Erreichung regelmäßig überprüft wird.

Neben der Möglichkeit, Geschäftsprozesse mit Hilfe von Reifegradmodellen zu charakterisieren, zeigen diese Modelle auch einen Weg zur Prozessverbesserung auf.

Forschungsbefunde Overhage/Schlauderer/Birkmeier untersuchten, ob zur Abbildung von Geschäftsprozessen EPK oder UML-Aktivitätsdiagramme für Fachanwender besser geeignet sind (Laborexperiment, in dem 73 zufällig ausgewählte Studenten der BWL/VWL im Hauptstudium „aus einer größeren Menge an Freiwilligen“ unter kontrollierten Bedingungen Geschäftsprozesse mit beiden Sprachen modellierten). Die Teilnehmer bildeten eine natürlich-sprachliche Beschreibung eines Geschäftsprozesses in der ihnen zugewiesenen Notation ab. Die entwickelten Modelle wurden mit Referenzlösungen verglichen. Abweichungen der von den Studenten entwickelten Prozessmodelle wurden von drei Korrektoren beurteilt und auf sprachliche Unterschiede zwischen EPK und Aktivitätsdiagramme zurückgeführt. Grundsätzlich sind beide Sprachen für Fachanwender geeignet, Unterschiede ergeben sich in der Art der Fehler, die bei der Modellierung entstehen. Dass für die Modellierung von Geschäftsprozessen mit EPK lediglich neun Beschreibungselemente benötigt werden, erwies sich als Vorteil und führte im Vergleich zu den mit Aktivitätsdiagrammen entwickelten Modellen zu weniger wortsyntaktischen Fehlern. Anderseits erzwingen EPK sehr detaillierte und nicht immer

Methoden des Geschäftsprozessmanagements (MEGPM)

445

leicht verständliche Modelle. Dies erschwert es, den Überblick zu behalten, woraus Satzsyntaxfehler resultieren. Bei den Aktivitätsdiagrammen erwies sich die implizite Konnektoreigenschaft von Aktionen als Problem, da diese für Fachanwender schwer zu verstehen ist und u. a. mehr Textsyntaxfehler und Kontrollflussfehler verursacht. Andererseits erleichtern Aktivitätsdiagramme Identifikation und Nutzung von Parallelisierungspotenzialen in Geschäftsprozessen erheblich. Ist die Flexibilität von Prozessen wichtig, sind Aktivitätsdiagramme gegenüber EPK zu bevorzugen. Da Fachanwender die Wortsyntax der wenigen EPK-Konstrukte leichter beherrschen, ist bei der Modellierung mit Aktivitätsdiagrammen aber eine intensivere Unterstützung durch Analysten und Entwickler nötig.

Aus der Praxis Winkler/Lehnhardt berichten über ein Projekt zur Einführung des kontinuierlichen Geschäftsprozessmanagements bei der Lufthansa Cargo AG. Das Projekt wurde mit Hilfe des Plan-Do-Check-Act-Zyklus (vgl. Lerneinheit QUALM) strukturiert. Zur Gruppierung und Ableitung von Kennzahlen für das Prozesscontrolling diente die BSC. Als Modellierungswerkzeug wurde der Casewise Corporate Modeler verwendet. Mit einem individuell entwickelten Werkzeug wurden alle modellierten Geschäftsprozesse zusammen mit Problemen, Best Practices und Neuigkeiten zu den Prozessen dokumentiert. Da die Darstellung der Prozessmodelle in grafischer Form als EPK und Wertkettendiagramme „nur wenigen Mitarbeitern leicht verständlich ist“ (557), wurden zusätzlich alternative Darstellungsmöglichkeiten erarbeitet. Seit der Einführung des GPM „hat sich die Zusammenarbeit von IT und Fachbereich stetig verbessert“ (558). Aufgabenverweise Geschäftsprozessmanagement (Lerneinheit GPMAN); Qualitätsmanagement (Lerneinheit QUALM); Controlling (Lerneinheit CONTR). Fallstudienverweis Lerneinheit FSGPM zeigt ein Beispiel für die Verbesserung eines Geschäftsprozesses. Kontrollfragen 1. Zu welchen Zwecken werden Geschäftsprozesse modelliert? 2. Welche Eigenschaften von Geschäftsprozessen können besser mit Wertkettendiagrammen, welche mit eEPK und welche mit UML-Aktivitätsdiagrammen abgebildet werden? 3. Wie können Referenzmodelle die Modellierung von Geschäftsprozessen unterstützen? 4. Welche Unterstützung bieten Softwarewerkzeuge für die Automatisierung von Geschäftsprozessen? 5. Wie können Geschäftsprozesse evaluiert werden? Quellen Becker, J. / Schütte, R.: Handelsinformationssysteme. Domänenorientierte Einführung in die Wirtschaftsinformatik. 2. A., Frankfurt a. M. 2004 Gadatsch, A.: Grundkurs Geschäftsprozess-Management. Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker. 4. A., Wiesbaden 2005 Kaplan, R. S. / Norton, D. P.: Balanced Scorecard. Stuttgart 1997 Nägele, R. / Schreiner, P.: Bewertung von Werkzeugen für das Management von Geschäftsprozessen. In: ZfO Zeitschrift Führung und Organisation 4/2002, 201–210 Nissen, V. / Seifert, M.: Das Consulting C - Grundzüge eines Prozessreferenzmodells für Beratungsunternehmen. In: Bichler, M. et al. (Hrsg.): Proceedings der Multikonferenz Wirtschaftsinformatik, München 26.-28.02.2008. Berlin 2008, 1661–1674

446

Methoden des administrativen Informationsmanagements

Oestereich, B.: Analyse und Design mit UML 2.0. Objektorientierte Softwareentwicklung. 8. A., München/Wien 2006 Overhage, S. / Schlauderer, S. / Birkmeier, D.: Sind Ereignisgesteuerte Prozessketten besser für Fachanwender geeignet als UML Aktivitätsdiagramme? Eine empirische Untersuchung. In: Bernstein, A. / Schwabe, G. (Hrsg.): Proceedings of the 10th International Conference on Wirtschaftsinformatik WI 2.011. Volume 2. Zürich 2011, 745–755 Porter, M. E.: Competitive Advantage: Creating and Sustaining Superior Performance. New York 1985 Scheer, A.-W.: Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse. 7. A., Berlin 1997 Schlimm, N.: Serviceorientierte Architektur - eine Standortanalyse. In: Informatik Spektrum 3/2010, 282–287 Software Engineering Institute: CMMI for Development, Version 1.3. CMMI-DEV, V1.3. CMU/SEI-2010-TR-033. Pittsburgh, PA 2010 Supply Chain Council: Supply Chain Operations Reference-model. SCOR Overview Version 10.0. Cyprus, TX. http://supply-chain.org/SCOR; Abruf 22. Juni 2011 Winkler, A. / Lehnhardt, S.: Geschäftsprozessmanagement in der Lufthansa Cargo AG. In: Schmelzer, H. J. / Sesselmann, W. (Hrsg.): Geschäftsprozessmanagement in der Praxis. Kunden zufrieden stellen - Produktivität steigern - Wert erhöhen. 6. A., München 2008, 543–561 Vertiefungsliteratur Bernstein, P. A.: Middleware: a model for distributed system services. In: Communications of the ACM 2/1996, 86– 98 Conrad, S. et al.: Enterprise Application Integration. Grundlagen - Konzepte - Entwurfsmuster - Praxisbeispiele. Heidelberg 2006 Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River et al. 2005 Erl, T.: SOA: Principles of Service Design. Upper Saddle River 2008 Linthicum, D. S.: Enterprise Application Integration. Boston/San Francisco/New York 2000 Richter, J.-P. / Haller, H. / Schrey, P.: Serviceorientierte Architektur. In: Informatik Spektrum 5/2005, 413–416 Ruh, W. / Maginnis, F. X. / Brown, W. J.: Enterprise Application Integration. New York/Chichester/Weinheim 2001 Karcher, A.: Middleware. In: Kurbel, K. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik - Online-Lexikon. München 4. A. 2010, o. S. http://www.enzyklopaedie-der-wirtschaftsinformatik.de Informationsmaterial Arbeitskreis Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten der Gesellschaft für Informatik http://www.epk-community.de BPM Research http://bpm-research.com Business Modeling & Integration Domain Task Force der Object Management Group http://bmi.omg.org Business Process Management Initiative der Object Management Group http://www.bpmi.org Business Process Modeling Notation http://www.bpmn.org Fraunhofer IAO Studie Business Process Management Tools 2008 http://www.swm.iao.fhg.de OASIS Web Services Business Process Execution Language http://www.oasis-open.org Object Management Group http://www.omg.org SCOR http://supply-chain.org Supply Chain Council http://supply-chain.org UML Resource Page der OMG http://www.uml.org Web Services Business Process Execution Language Version 2.0 http://www.oasis-open.org Workflow Management Coalition http://www.wfmc.org Workflow Reference Model der Workflow Management Coalition http://www.wfmc.org XPDL-Website der Workflow Management Coalition http://www.xpdl.org Normen ISO/IEC 19501:2005 Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version 1.4.2 ISO/IEC 19793:2008 Information technology – Open Distributed Processing – Use of UML for ODP system specifications

Methoden des Wissensmanagements (MEWIM) Lernziele Sie wissen, welche Methoden zur Unterstützung der Aufgaben des Wissensmanagements geeignet sind. Sie können verschiedene Formen der Wissenstransformation unterscheiden. Sie kennen Methoden zur Unterstützung der Kodifizierungsstrategie und wissen, welche Methoden sich zur Wissensbewertung eignen.

Definitionen und Abkürzungen Blog = Kurzform für Web-Log; ein im WWW publiziertes Journal bzw. Tagebuch. Business Intelligence = IT-basierter Gesamtansatz zur Unterstützung der betrieblichen Entscheidungsfindung. Coaching = Beratung und Begleitung von Fach- und Führungskräften mit dem Ziel, deren Fähigkeit zur Lösung komplexer Probleme zu verbessern. Data Mining = Sammelbezeichnung für Verfahren der Statistik, der Künstlichen Intelligenz und der Mustererkennung, mit denen domänenunabhängig in strukturierten Datenbeständen nach bisher unbekannten Zusammenhängen (Mustern) gesucht werden kann. Information Retrieval = Informationswiedergewinnung; Methoden zur Speicherung und Repräsentation sowie zum Zugriff auf unstrukturierte Daten. Job Rotation = systematischer und regelmäßiger Wechsel von Arbeitsplatz und Aufgaben. Mentoring = Begleitung, Beratung und Förderung einer weniger erfahrenen Person im Hinblick auf deren persönliche und berufliche Entwicklung durch einen erfahrenen Mentor. OLAP = Online Analytical Processing; 1993 von Codd/Codd/Salley geprägter Begriff zur multidimensionalen Analyse von Daten in Data-Warehouse-Systemen. Text Mining = Extraktion von Informationen aus Textdokumenten, um implizite, nicht offensichtliche oder bisher nicht bekannte Zusammenhänge zu entdecken. Web 2.0 = Von O‘Reilly propagierte Sammelbezeichnung für verschiedene Entwicklungsund Nutzungsformen des WWW, die insbesondere durch eine hohe Interaktivität und die Beteiligung von Nutzern an der Erstellung von Inhalten gekennzeichnet sind. Wiki = hawaiianisches Wort für schnell; skript-basierte Website, die es Benutzern erlaubt, Inhalte einfach zu erweitern und zu modifizieren. Wissensentwicklung (knowledge development) = unternehmensinterne Entwicklung von Wissen. Wissenserwerb (knowledge acquisition) = Erwerb externen Wissens. Wissenskarte (knowledge map) = grafisches Verzeichnis von Wissensquellen bzw. Wissensträgern, Wissensbeständen, Wissensstrukturen oder Wissensanwendungen. Wissenstransformation (knowledge transformation) = Umwandlung von Wissen von einer Repräsentationsform in eine andere.

448

Methoden des administrativen Informationsmanagements

Zweck der Methoden des Wissensmanagements Methoden des Wissensmanagements sollen Fach- und Führungskräfte bei der Erfüllung ihrer Aufgaben unterstützen. Dementsprechend werden die Methoden mit Hilfe der Aufgaben des Wissensmanagements (vgl. Lerneinheit WIMAN) gegliedert. Einige Methoden sind auf bestimmte Aufgaben zugeschnitten (z. B. Data Mining zur Wissensentwicklung), andere eignen sich zur Unterstützung mehrerer Aufgaben des Wissensmanagements (z. B. Communities of Practice zur Entwicklung und Verteilung von Wissen). Die Einordnung der Methoden erfolgt nach dem Schwerpunkt ihres Beitrags zur Erfüllung von Aufgaben des Wissensmanagements. Für den Erwerb externen Wissens sowie für die Wissensnutzung sind keine spezifischen Methoden entwickelt worden.

Methoden zur Definition von Wissenszielen Ziele für das Wissensmanagement sind auf der Grundlage der Unternehmensziele sowie der Wissensmanagementstrategie zu definieren. Die Ziele sollen relevant, konkret und ihre Erreichung soll, soweit möglich, messbar sein. Die Ableitung und Definition von Zielen für das Wissensmanagement unterscheidet sich methodisch nicht von der Zieldefinition für andere betriebliche Aufgabenfelder. Deshalb sind hierzu keine spezifischen Aussagen nötig (vgl. Lerneinheiten SZIEL und SPLAN). Zum Bestimmen des Wissensangebots muss die Wissensnachfrage bekannt sein, die über den Wissensbedarf ermittelt wird. Der Wissensbedarf spezifiziert Art, Menge und Beschaffenheit des Wissens, das für die Aufgabenerfüllung aus Sicht der Aufgabe bzw. aus Sicht des Aufgabenträgers erforderlich ist. Der für die Bewältigung der Aufgabe erforderliche Wissensbedarf ist der objektive, der aus Sicht des Aufgabenträgers für erforderlich gehaltene Wissensbedarf ist der subjektive Wissensbedarf bzw. das Wissensbedürfnis. Objektiver und subjektiver Wissensbedarf können identisch sein. Erfahrungsgemäß wird nur ein Teil des objektiven Wissensbedarfs vom Aufgabenträger als Wissensnachfrage geäußert. Der Wissensnachfrage steht ein Wissensangebot gegenüber. Wissensnachfrage und Wissensangebot sind im Idealfall zur Deckung zu bringen. Zur Ermittlung von Wissensbedarf und -bedürfnis kann die Informationsbedarfsanalyse genutzt werden (vgl. Lerneinheit INBAN).

Methoden zur Wissensidentifikation Es kann angenommen werden, dass insbesondere in diversifizierten und dezentral organisierten Unternehmen mit geographisch verteilten Standorten die Mitarbeiter oft weder alle wichtigen Wissensbestände des Unternehmens noch intern und extern verfügbare Experten für relevante Wissensgebiete kennen. Noch seltener ist ein Überblick über das Wissen vorhanden, welches für die zukünftige Wettbewerbsfähigkeit des Unternehmens notwendig ist. Expertenverzeichnisse sind – in der Regel Datenbank gestützte – Kataloge von internen oder externen Experten, in denen deren Kenntnisse, Fähigkeiten und Erfahrungen beschrieben sind. Diese Verzeichnisse ermöglichen es Mitarbeitern, schnell Experten zu identifizieren, die ihnen bei der Lösung spezifischer Problem helfen können. Im Rahmen der Personalisierungsstrategie (vgl. Lerneinheit WIMAN) ist dies eine wichtige Funktion. In einigen Unternehmen wird versucht, diese Verzeichnisse für alle Mitarbeiter zu führen, um einen

Methoden des Wissensmanagements (MEWIM)

449

Überblick über die Gesamtheit der personengebundenen Wissensbestände zu erhalten. Die Verzeichnisse werden auch als „Gelbe Seiten“ bezeichnet. In Deutschland unterliegen sie sowohl den Mitbestimmungsregelungen als auch dem Datenschutz (vgl. Lerneinheit RECHT). Dies hat zur Folge, dass Einträge in diesen Verzeichnissen nur mit Zustimmung der Betroffenen erfolgen dürfen. Damit die Verzeichnisse Nutzen stiften können, müssen die Einträge aktuell und hinreichend genau sein. Insbesondere sehr umfangreiche Verzeichnisse können nur mit unverhältnismäßig hohem Aufwand zentral gepflegt werden. Hier ist das Wissensmanagement auf die Mitwirkung der registrierten Personen angewiesen. Eine weitere Herausforderung besteht in der hinreichend genauen Beschreibung der Kenntnisse, Fähigkeiten und Erfahrungen der Mitarbeiter. Sind die Einträge zu ungenau, erschwert dies das Auffinden geeigneter Wissensträger. Ist das Verzeichnis zu detailliert, senkt dies die Motivation der Mitarbeiter, die Einträge regelmäßig zu aktualisieren. Da sich das relevante Wissen nach und nach ändert, muss auch das entsprechende Begriffssystem zur Beschreibung von und Suche nach den Experten kontinuierlich angepasst werden. Zur Steigerung der Transparenz sind verschiedene Formen von Wissenskarten entwickelt worden (vgl. Eppler, 189 ff. oder Roehl, 235 ff.). Eppler beschreibt Wissenskarten als grafische Verzeichnisse von Wissensquellen bzw. Wissensträgern, Wissensbeständen, Wissensstrukturen, Wissensanwendungen oder von notwendigen Entwicklungsstufen des Wissens zur Erreichung bestimmter Ziele. Wissenskarten werden nicht in erster Linie dazu entwickelt, Wissen abzubilden, sondern darauf zu verweisen bzw. Wissen zu lokalisieren. Sie unterstützen das Auffinden von Wissensträgern und anderen Wissensquellen, verbinden Aufgaben mit Wissensbeständen und Wissensträgern und erleichtern die Strukturierung von Wissen.

Lücke 2

unbekannt

extern

Lücke 1

intern

Wissensziel Fähigkeit „x“ aufbauen

Die Erreichung von Wissenszielen erfordert es, auf bereits vorhandenes Wissen zuzugreifen. Expertenverzeichnisse und Wissenskarten helfen, dieses Wissen aufzufinden. Darüber hinaus, ist es häufig notwendig, auf extern verfügbares Wissen zuzugreifen oder neues Wissen zu entwickeln. Abbildung MEWIM-1 stellt schematisch dar, wie Wissenslücken identifiziert werden können.

extern vorhandenes Wissen

bereits intern vorhandenes Wissen

noch nicht existierendes Wissen

entwickeln

erwerben

bewahren

Abb. MEWIM-1: Identifikation von Wissenslücken (Quelle: nach Probst/Raub/Romhardt)

450

Methoden des administrativen Informationsmanagements

Methoden zur Wissensentwicklung

Ausgangspunkt

Zur Entwicklung von Wissen innerhalb eines Unternehmens stehen verschiedene Methoden zur Verfügung. Die bekannteste stammt von Nonaka/Takeuchi. Damit versuchen die Autoren, den Erfolg vieler japanischer Unternehmen zu erklären, die – so die These der Autoren – auf ein leistungsfähiges Zielpunkt Wissensmanagement zurückzuführen sei. Sie legen implizites explizites ihren Überlegungen die Wissen Wissen Unterscheidung von implizitem und explizitem Wisimplizites Sozialisierung Externalisierung sen zu Grunde (vgl. LernWissen einheit WIMAN) und geexplizites hen insbesondere auf die Internalisierung Kombination Wissen Transformation von Wissen ein. Sie unterscheiden vier Abb. MEWIM-2: Wissenstransformation (Quelle: nach Nonaka/Takeuchi) Formen der Wissenstransformation, die in Abbildung MEWIM-2 dargestellt sind. Sozialisierung beschreibt die Übertragung impliziten Wissens von einem Wissensträger auf einen anderen, ohne dass dieses Wissen explizit gemacht wird. Beispiele für diese Form der Wissenstransformation sind Beobachtungslernen oder Learning-by-Doing, z. B. in dem ein Auszubildender einen erfahrenen Mitarbeiter bei der Arbeit beobachtet und bestimmte Techniken von ihm übernimmt. Ein anderes Beispiel ist die Tradierung von impliziten Grundannahmen, Werten und Einstellungen, die in der Literatur oft als mentale Modelle bezeichnet werden. Externalisierung ist die Transformation impliziten Wissens in explizites Wissen bzw. Information. Jede Form der Verbalisierung bzw. Abbildung zuvor impliziten Wissens ist eine Form der Externalisierung. Beispiele sind die Beschreibung von bisher nicht dokumentierten betrieblichen Aufgaben im Rahmen des Qualitätsmanagements (vgl. Lerneinheit QUALM) und von Geschäftsprozessen im Rahmen des Geschäftsprozessmanagements (vgl. Lerneinheit GPMAN). Eine besondere Herausforderung ergibt sich bei der Externalisierung nicht oder nur schwer explizierbaren impliziten Wissens, dem so genannten tacit knowledge. Hierzu empfehlen Nonaka/Takeuchi die Verwendung von Bildern, Metaphern oder Analogien, welche die Durchführung von Innovationsprozessen in japanischen Unternehmen erleichtert haben. Internalisierung beschreibt die Umwandlung expliziten Wissens in implizites Wissen. Internalisierung findet z. B. statt, wenn Mitarbeiter durch wiederholtes Üben und fortgesetzte Anwendung eine Aufgabe immer besser bewältigen können, so dass sie nach einiger Zeit keine expliziten Anweisungen mehr benötigen. Kombination ist die Transformation von explizitem Wissen in auf eine andere Weise dargestelltes, explizites Wissen. Beispiele sind die Übersetzung eines Textes von einer Sprache in eine andere, die verbale Beschreibung einer Grafik und alle Formen der verbalen Kommuni-

Methoden des Wissensmanagements (MEWIM)

451

kation. Nonaka/Takeuchi zählen hierzu auch die Verbindung von verschiedenen Wissensobjekten oder -beständen, wie sie z. B. im Rahmen des betrieblichen Rechnungswesens oder des Controllings vorgenommen wird. Nonaka/Takeuchi vertreten die These, dass die vier Formen der Wissenstransformation ihre volle Wirkung im Wesentlichen durch das Zusammenspiel und durch die wiederholte Transformation von implizitem und explizitem Wissen entfalten. Zu den traditionellen Formen der Wissensentwicklung gehören Forschung und Entwicklung, Marktforschung und das betriebliche Vorschlagswesen. Auch im Qualitätsmanagement (vgl. Lerneinheit QUALM) wird Wert darauf gelegt, aus Erfahrungen zu lernen, um vorhandene Stärken auszubauen und Schwächen gezielt zu bekämpfen. Die Auswertung von Erfahrungen (in der englischen Literatur oft als „Lessons Learned“ bezeichnet) scheint selbstverständlich zu sein. Empirische Untersuchungen zeigen aber (vgl. z. B. Probst/Raub/Romhardt, 133), dass z. B. Post-Mortem-Analysen nach dem Abschluss von Projekten nur sehr selten durchgeführt werden. Post-Mortem-Analysen (auch als Post-Project-Reviews bezeichnet) sind Untersuchungen, welche nach Abschluss eines Projektes mit dem Ziel durchgeführt werden, Erfahrungen der Projektbeteiligten zu explizieren, um daraus Empfehlungen für die Durchführung weiterer Projekte und für die Verbesserung des Projektmanagements abzuleiten. Wertvolle Hilfen für die Wissensentwicklung können auch Kreativitätstechniken leisten, z. B. Brainstorming, Brainwriting, Metaplan-Technik, Mind Mapping, Morphologische Methoden oder die Synektik (vgl. Hauschildt/Salomo). Während die bisher erläuterten Methoden der Wissensentwicklung weitgehend ohne Softwareunterstützung auskommen, können Informationssysteme helfen, Wissen aus bereits vorhandenen Daten zu generieren. Kemper/Mehanna/Unger definieren Business Intelligence als integrierten, unternehmensspezifischen, IT-basierten Gesamtansatz zur betrieblichen Entscheidungsunterstützung. Chamoni/Gluchowski unterscheiden ein weites und ein enges Begriffsverständnis. Das weite Verständnis umfasst jegliche Aufbereitung und Speicherung operativer Daten, um diese für betriebliche Entscheidungen auswerten und präsentieren zu können. Ein Beispiel hierfür ist die Auswertung von Vertriebsdaten in einem Tabellenkalkulationsprogramm zur Ermittlung einer Preis-Absatz-Funktion. Das enge Verständnis geht von einem Data Warehouse (vgl. Lerneinheit DATEM) als technischer Grundlage aus und beschreibt modell- und methodenbasierte Analysen von betrieblichen Daten. In diesem Fall werden insbesondere die Erstellung von Ad-hoc-Berichten mit Hilfe von Generatoren, OLAP und Data Mining zum Business Intelligence gezählt. OLAP ermöglicht schnelle, einfach zu bedienende multidimensionale Auswertungen großer Datenbestände. Ein Beispiel ist die Auswertung von Umsatzzahlen nach Produktgruppen, Absatzwegen, Verkaufsregionen und Zeiteinheiten. Mit Data Mining wird oft der Anspruch verbunden, nicht explizite bzw. nicht offensichtliche Zusammenhänge entdecken zu können. Ein Beispiel für Data Mining ist die Analyse charakteristischer Eigenschaften von Bestandskunden mit gutem und von anderen Bestandskunden mit schlechtem Zahlungsverhalten, um auf diese Weise Indikatoren für das potenzielle Zahlungsverhalten von Neukunden gewinnen zu können.

452

Methoden des administrativen Informationsmanagements

Schätzungen (vgl. Gentsch, 64) gehen davon aus, dass bis zu 80 % des explizit repräsentierten Wissens in einem Unternehmen nicht in strukturierten Datenbeständen, sondern in Textdokumenten, E-Mails, Graphiken und Bildern sowie Filmen gespeichert sind. Diese Ressourcen können zwar für das Unternehmen wichtiges Wissen enthalten, entziehen sich aber dem Data Mining. Methoden des Information Retrieval können helfen, dieses Wissen nutzbar zu machen. Diese werden außer im Bibliothekswesen in Bildsuchmaschinen, für die Recherche in Film und Fotoarchiven sowie in Spam-Filtern eingesetzt. In zunehmendem Maße werden sie auch im Zusammenhang mit Portalen genutzt, die den Mitarbeitern eines Unternehmens Zugriff auf relevante Wissensbestände ermöglichen sollen, unabhängig davon, in welcher Form und in welchen Systemen diese repräsentiert sind. Eng damit verwandt sind Methoden des Text Mining (vgl. hierzu auch die Lerneinheit DATEM). Wikis eignen sich insbesondere in verteilten Teams zur kollaborativen Wissensentwicklung. Sie lassen sich mit geringem Aufwand implementieren und erweitern, ihre Bedienung ist leicht zu erlernen, alle Funktionen sind selbsterklärend. Durch die Offenheit der Systeme sind Erweiterung und Verbesserung der Inhalte durch die Benutzer leicht zu bewerkstelligen. Dies führt auch dazu, dass die Inhalte in der Regel sehr aktuell sind.

Methoden zur Wissensverteilung Zu den Methoden für die Verteilung impliziten Wissens zählen Coaching, Mentoring und Job Rotation. Sowohl beim Coaching als auch beim Mentoring wird explizites Wissen übertragen. Durch die enge persönliche Beziehung zwischen Ratgeber und Beratenem kann aber davon ausgegangen werden, dass der Beratene zusätzlich implizites Wissen seines Ratgebers übernimmt. Mit Job Rotation werden verschiedene Ziele verfolgt: Erhöhung der Motivation der Mitarbeiter durch Senkung der mit der Arbeit verbundenen Monotonie, Qualifikation von Mitarbeitern im Rahmen von Führungskräftenachwuchsprogrammen sowie Verteilung des Wissens auf eine größere Anzahl von Mitarbeitern. Zur Verteilung expliziten Wissens stehen verschiedene Methoden zur Verfügung. Diese lassen sich grob danach klassifizieren, ob das zu verteilende Wissen in Informationssystemen gespeichert ist oder in anderer Form vorliegt. Zur Verteilung von Wissen außerhalb von Informationssystemen können betriebliche Weiterbildung, Communities of Practice sowie Qualitätszirkel (vgl. Lerneinheit QUALM) und Coaching, Mentoring und Job Rotation zum Einsatz kommen. Zur Verteilung des Wissens mit Hilfe von Informationssystemen kommen zwei Prinzipien in Frage. Beim Pull-Prinzip fordert der Aufgabenträger die Information an, wenn er sie benötigt. Dies erfordert ein aktives Nachfrageverhalten. Beim Push-Prinzip wird vorab entschieden, welche Information für welche Aufgabenträger relevant ist, oder es wird den einzelnen Aufgabenträgern selbst überlassen, welche Arten von Informationen sie zugestellt bekommen wollen. Ein Workflow-Managementsystem unterstützt den korrekten Ablauf der administrativen Aufgaben von gut strukturierten Geschäftsprozessen, die sich durch eine hohe Wiederholhäufigkeit und intensive Aufgabenteilung der, in der Regel örtlich verteilten, Aufgabenträger auszeichnen. Workflow-Managementsysteme stellen selbst keine Funktionalität zur operati-

Methoden des Wissensmanagements (MEWIM)

453

ven Bearbeitung der Aufgaben zur Verfügung, gewährleisten aber, dass die Aufgabenträger Zugriff auf die jeweils relevanten Wissensobjekte haben. Groupware ist Software für Gruppenarbeit. Im Unterschied zu Workflow-Managementsystemen unterstützt Groupware schlecht strukturierte Aufgaben (z. B. Entwicklungstätigkeiten). Während Workflow-Managementsysteme die Verteilung von Wissensobjekten aktiv steuern, unterstützt Groupware Mitarbeiter bei der Wissensverteilung. Zu diesem Zweck ermöglichen Groupware-Systeme die synchrone (z. B. per Chat oder Videokonferenz) oder asynchrone (z. B. per E-Mail) Kommunikation räumlich getrennter Personen, die gleichzeitige Bearbeitung von Objekten (z. B. Dokumente, Zeichnungen oder Softwarecode) durch Teammitglieder an unterschiedlichen Standorten, die Terminverwaltung und -abstimmung in der Gruppe und den automatischen Abgleich verteilter Datenbestände. Content-Management-Systeme sind nach Hartmann Werkzeuge zur darstellungsunabhängigen Erzeugung und Verwaltung von Information und deren Ausgabe in verschiedenen Kontexten, Medien und Formaten. Der Vorteil von Content-Management-Systemen besteht darin, dass Information unabhängig von Struktur und Darstellungsform bzw. Layout gespeichert wird. Bei einer Aktualisierung der Information muss diese nur einmal verändert werden. Die Modifikation wird durch das Content-Management-System in allen damit verbundenen Systemen aktualisiert, welche die gleiche Information nutzen. Für die Wissensverteilung bedeutet das, dass viele Wissensobjekte nur noch in einem System gepflegt werden müssen. Mit Hilfe eines Content-Management-Systems kann die Darstellung dieser Wissensobjekte in anderen Systemen (z. B. in Wikis und Portalen) gesteuert werden (vgl. Lerneinheit FSDOK). Stelzer charakterisiert ein Portal als eine Website, welche den Einstieg in einen bestimmten Bereich des WWW erleichtert und deshalb von vielen Personen immer wieder benutzt wird. Unternehmensportale dienen den spezifischen Interessen eines Unternehmens, z. B. um Mitarbeitern einen einheitlichen Zugang zu verschiedenen Datenbeständen und Softwareanwendungen zu ermöglichen. Finkelstein unterscheidet vier Arten von Unternehmensportalen. Ein Enterprise Information Portal ermöglicht den Nutzern Zugang zu relevanten Informationen aus unternehmensinternen und –externen Quellen. Diese Portale lassen sich personalisieren und verfügen über Schnittstellen zu Datenbeständen, Softwareanwendungen und Ressourcen im Internet, die für die betreffende Gruppe von Mitarbeitern relevant sind. Enterprise Collaborative Portals unterstützen die Zusammenarbeit in Arbeitsgruppen. Zu diesem Zweck integrieren sie Funktionen von Workflow-Managementsystemen und Groupware. Enterprise Expertise Portals sind Kommunikationsplattformen, die speziell auf die Aufgaben bestimmter Mitarbeitergruppen (z. B. Sicherheitsverantwortliche) zugeschnitten sind. Neben den bereits dargestellten Funktionen der anderen Portale informieren sie die Nutzer gemäß dem Push-Prinzip über relevante Neueinträge, z. B. in Datenbanken, DokumentenManagement-Systemen sowie in ausgewählten Bereichen des Intranets oder des Internets. Enterprise Knowledge Portals vereinigen die Funktionen der drei anderen Portale und ergänzen diese durch den Zugriff auf spezifische Anwendungen des Wissensmanagements (z. B. Expertenverzeichnisse, Wissenskarten sowie Data und Text Mining). Obwohl die Hauptaufgabe von Wikis die Wissensentwicklung ist, kann mit ihrer Hilfe auch Wissen verteilt werden. Blogs eignen sich ebenfalls zur Wissensverteilung. Blogs werden in

454

Methoden des administrativen Informationsmanagements

erster Linie zur Publikation von Expertenwissen verwendet. Die Autoren nehmen darin – oft auf unterhaltsame Weise – zu bestimmten Themen Stellung.

Methoden zur Wissensbewahrung Der umfangreichste Teil der Wissensbasis ist an die Mitarbeiter eines Unternehmens gebunden. Im Rahmen der Personalisierungsstrategie (vgl. Lerneinheit WIMAN) wird nicht der Versuch unternommen, das implizite Wissen zu dokumentieren. Es wird durch die Mitarbeiter bewahrt. In diesem Fall kommt es darauf an, Mitarbeiter, welche über wichtiges Wissen verfügen, an das Unternehmen zu binden und darauf hinzuwirken, dass sie ihr Wissen an andere Mitarbeiter weitergeben. Im Rahmen einer Kodifizierungsstrategie sind nach Probst/Raub/Romhardt folgende Aufgaben der Wissensbewahrung zu erfüllen: Bei der Selektion geht es darum, Wissensobjekte zu identifizieren, die bewahrungswürdig sind. Hierzu sind Kenntnisse über den derzeitigen und im Idealfall auch den zukünftigen Wissensbedarf notwendig. Als bewahrungswürdig klassifiziertes Wissen muss so aufbereitet werden, dass es im Fall der Wiederverwendung leicht verstanden und angewendet werden kann. Es muss möglichst selbsterklärend dokumentiert und so beschrieben werden, dass interessierte Aufgabenträger es leicht wieder auffinden können. Im Anschluss sind die Wissensobjekte in Informationssystemen zu speichern. Damit das Wissen nützlich bleibt, muss es regelmäßig überprüft und wenn nötig aktualisiert werden. Soll ein unkontrolliertes Wachstum der Wissensobjekte vermieden werden, muss das Wissen gelöscht werden, welches veraltet ist oder voraussichtlich keinen Nutzen mehr stiften kann. Der überwiegende Teil des expliziten Wissens eines Unternehmens liegt in Textdokumenten, E-Mails, Besprechungsnotizen, Präsentationsunterlagen, Kalkulationen etc. vor. Diese Wissensobjekte lassen sich nur dann ohne erheblichen Aufwand finden, wenn z. B. in Wissenskarten auf sie verwiesen wird oder sie Methoden des Information Retrieval (vgl. Lerneinheit DATEM) zugänglich gemacht werden. Erschwerend kommt hinzu, dass viele Wissensobjekte zwar dokumentiert, nicht aber digitalisiert sind. Selbst, wenn das der Fall ist, liegen sie zum Teil nur auf den lokalen Speichern einzelner Rechner vor. Sie sind damit für andere Mitarbeiter nicht ohne weiteres zugänglich. Einfacher ist es, wenn das Wissen in Systemen gespeichert wird, die explizit für die Wissensbewahrung konzipiert sind. In diesen Systemen kann das Wissen regelmäßig auf Gültigkeit geprüft, aktualisiert, überarbeitet oder gelöscht werden. Für die Wissensbewahrung eignen sich in erster Linie Datenbank-, DataWarehouse- und Dokumenten-Management-Systeme. Ein Datenbanksystem ist eine geordnete Menge von logisch zusammengehörenden Daten, die von einem Datenverwaltungssystem verwaltet wird. Datenbanken dienen der Bewahrung von Faktenwissen in Form von strukturierten Daten. Im Rahmen der Personalisierungsstrategie bieten sie die technische Basis für Expertenverzeichnisse. Ein Data-Warehouse-System ist laut Kemper/Mehanna/Unger ein von den operativen Datenbeständen getrenntes, logisch zentralisiertes dispositives Datenhaltungssystem zur Entscheidungsunterstützung (vgl. Lerneinheit DATEM). Wie in einer operativen Datenbank wird auch in einem Data Warehouse Faktenwissen in Form von strukturierten Daten verwal-

Methoden des Wissensmanagements (MEWIM)

455

tet. Der Vorteil von Data-Warehouse-Systemen im Vergleich zu operativen Datenbanken liegt darin, dass Daten mit diesen Systemen vielfältiger analysiert und aufbereitet werden können. Data-Warehouse-Systeme sind insbesondere dazu geeignet, Ad-hoc-Berichte, Entscheidungsmodelle sowie Kennzahlensysteme, wie z. B. im Rahmen einer Balanced Scorecard (vgl. Lerneinheit KENNZ), mit Daten zu versorgen. Ein Dokumenten-Management-System ist laut Bock ein Sammelbegriff für verschiedene, sich in ihren Funktionen überschneidende Softwaresysteme, die der Unterstützung bei der Verarbeitung von Dokumenten dienen. Diese Verarbeitung umfasst die Abbildung von Dokumenten in digitaler Form (Imaging), die Klassifikation und Beschreibung von Dokumenten anhand bestimmter Kriterien (Indexing), das Einfügen von Dokumenten in digitale Archive (Archiving) sowie die Suche nach und Bereitstellung von Dokumenten für Benutzer (Retrieval). Moderne Dokumenten-Management-Systeme erlauben die Weiterleitung von Dokumenten in Workflows sowie die Bereitstellung in heterogenen, verteilten Umgebungen. Dadurch bilden sie eine wichtige Grundlage für die Bewahrung von Wissen in Form von Dokumenten.

Methoden zur Wissensbewertung Methoden zur Wissensbewertung lassen sich unterscheiden in   

Methoden zur Bewertung des Wissens, Methoden zur Bewertung des Wissensmanagements und kombinierte Methoden.

Methoden zur Bewertung des Wissens orientieren sich an Vorschlägen zur Bewertung immaterieller Vermögensgegenstände bzw. des intellektuellen Kapitals. North/Probst/Romhardt unterteilen diese Methoden in deduktiv summarische und induktiv analytische. Deduktiv summarische Methoden versuchen, den Wert des Wissens als Differenz aus Markt- und Buchwert eines Unternehmens zu bestimmen. Induktiv analytische Methoden beschreiben und bewerten einzelne Elemente der Wissensbasis. Der Nachteil dieser Methoden besteht darin, dass sie nur wenig geeignet sind, Wirkungszusammenhänge zwischen Maßnahmen des Wissensmanagements und Unternehmenszielen abzubilden. Deshalb lassen sich daraus nur schwer Handlungsempfehlungen für das Wissensmanagement ableiten. Stata unterbreitet mit der Half-Life Curve einen Vorschlag zur Bewertung des Erfolgs von Maßnahmen des Wissensmanagements. Mit der Half-Life Curve wird die Zeit gemessen, die benötigt wird, um eine Verbesserung eines bestimmten Leistungsmaßes von 50 % zu erreichen. So kann z. B. ermittelt werden, wie lange benötigt wird, den Fehleranteil in Produkten, die Liefertreue oder die Kosten betrieblicher Aufgaben mit Hilfe von Maßnahmen des Wissensmanagements um 50 % zu verbessern. Die Half-Life Cuve hat den Vorteil, dass sie Maßnahmen des Wissensmanagements mit der Erreichung von Unternehmenszielen bewertet. Da diese Methode aber ausschließlich auf Ergebnisse ausgerichtet ist, kann sie Veränderungen der Wissensbasis, welche sich noch nicht in Verbesserungen von Unternehmenszielen niedergeschlagen haben, nicht berücksichtigen. Verbesserungen des Wissens (z. B. über neue Entwicklungs- oder Produktionsverfahren) benötigen aber in der Regel mehrere Jahre, bevor sie in verbesserten betrieblichen Leistungen und Ergebnissen sichtbar werden.

456

Methoden des administrativen Informationsmanagements

Kombinierte Bewertungsmethoden versuchen, den Mängeln der zuvor dargestellten Methoden dadurch zu begegnen, dass sowohl Veränderungen der Wissensbasis eines Unternehmens als auch Wirkungszusammenhänge zwischen Maßnahmen des Wissensmanagements und Veränderungen betrieblicher Ergebnisse in die Bewertung einbezogen werden. Solche Methoden sind z. B. von Mertins/Alwert und North/Probst/Romhardt vorgestellt worden. Ein Werkzeug zur kombinierten Bewertung des Wissensmanagements ist die sogenannte Wissensbilanz. Eine Wissensbilanz ist keine Gegenüberstellung von Vermögen und Kapital, sondern eine Darstellung von Wirkungszusammenhängen zwischen Aufgaben des Wissensmanagements, Veränderungen der Wissensbasis sowie betrieblichen Aufgaben und Ergebnissen. Abbildung MEWIM-3 gibt einen Überblick über Wirkungszusammenhänge des Wissensmanagements, welche von den kombinierten Bewertungsmethoden berücksichtigt werden.

Maßnahmen des Wissensmanagements

Veränderungen der Wissensbasis

Veränderungen betrieblicher Aufgaben

Verbesserungen betrieblicher Ergebnisse

Abb. MEWIM-3: Wirkungszusammenhänge des Wissensmanagements

Schriftliche und mündliche Befragungen können helfen, die Kenntnisse über bestimmte Sachverhalte und das Verständnis von Zusammenhängen zu überprüfen. Auf diese Weise kann untersucht werden, ob das Wissensmanagement tatsächlich Veränderungen der organisatorischen Wissensbasis erreicht hat. Die Half-Life Curve ist ein Beispiel für Instrumente, mit deren Hilfe Veränderungen betrieblicher Aufgaben bewertet werden können. Mit Hilfe von Messungen klassischer betrieblicher Kennzahlen (z. B. Gewinn, Umsatz, Kosten; vgl. Lerneinheit KENNZ) kann untersucht werden, ob Maßnahmen des Wissensmanagements zu Verbesserungen betrieblicher Ergebnisse geführt haben.

Forschungsbefunde Sedera/Gable untersuchten den Zusammenhang zwischen Wissensmanagementkompetenz („effective management of knowledge of value for the on-going health and longevity of the Enterprise System“, 297) und dem Erfolg des Einsatzes von ERP-Systemen („the stream of net benefits from an information system, to-date and anticipated, as perceived by all key user groups“, 297) (Online-Befragung von 310 Mitarbeitern in 27 Landesbehörden des australischen Bundeslandes Queensland, die seit drei Jahren das Modul FI Finanzwesen des ERPSystems SAP R/3einsetzten; keine Angaben zu Rücklaufquote und Untersuchungszeitraum). Wissensmanagementkompetenz wurde anhand der Beherrschung folgender Aufgaben evaluiert: Wissensentwicklung (knowledge creation), Wissensbewahrung (knowledge retention), Wissensverteilung (knowledge transfer) und Wissensnutzung (knowledge application). Der Erfolg des Einsatzes des Moduls FI Finanzwesen wurde mit Hilfe des Modells von DeLone/ McLean zur Messung des Erfolgs von Informationssystemen anhand der Kriterien „Individual-Impact, Organizational-Impact, System-Quality and Information-Quality“ (300) evaluiert. Die Ergebnisse der Untersuchung bestätigen die Forschungshypothese: Je höher die Kompetenz der Behörden für die Wissensmanagementaufgaben war, desto stärker war der Erfolg des ERP-Einsatzes ausgeprägt.

Methoden des Wissensmanagements (MEWIM)

457

Aus der Praxis Bughin/Chui berichten über die Nutzung von Web-2.0-Technologien (z. B. soziale Netzwerke, Wikis und Blogs) in Unternehmen (Online-Befragung von 3249 Führungskräften weltweit, keine Angaben zu Grundgesamtheit und Untersuchungszeitraum, zwei Drittel der befragten Unternehmen nutzen Web-2.0-Technologien). Sie teilen die Unternehmen nach der Art der Nutzung des Web 2.0 in drei Klassen ein: (a) „Internally networked organizations“ (13 % der befragten Unternehmen, die Web-2.0-Technologien nutzen) verwenden das Web 2.0 in erster Linie für interne Zwecke. Sie berichten über effizientere Nutzung des unternehmensinternen Wissens, Reduzierung von Kommunikationskosten und schnelleren Zugriff auf interne Experten. Einige der Unternehmen, die Mitarbeitern mit operativen Aufgaben große Entscheidungsspielräume gewähren und ihnen erlauben, mit Hilfe von Web-2.0-Technologien Arbeitsgruppen aus internen Mitarbeitern, Kunden und Lieferanten zu bilden, erzielen bessere operative Ergebnisse als Unternehmen, in denen das nicht der Fall ist. (b) „Externally networked organizations“ (5 %) nutzen das Web 2.0 intensiv zur Kommunikation mit Kunden und Lieferanten. Diese Unternehmen geben als Nutzen u. a. an: höhere Kundenzufriedenheit und effizienteres Marketing, geringere Kommunikationskosten mit Kunden und Lieferanten und schnelleren Zugang zu unternehmensexternem Wissen. (c) „Fully networked organizations“ (3 %) sind Unternehmen, in denen das Web 2.0 sowohl für unternehmensinterne Kommunikation als auch für die Kommunikation mit Kunden und Lieferanten genutzt wird. Bughin/Chui bezeichnen diese Unternehmen als „learning organizations“, welche die durch verbesserten unternehmensinternen Wissenstransfer gewonnenen Erfahrungen nutzen, um auch stärker vom Wissenstransfer mit Kunden und Lieferanten profitieren zu können. Hagedorn et al. berichten über Erfahrungen beim Aufbau einer „Wissensdatenbank“ für ein Shared-Service-Center, das Aufgaben des Personalmanagements für 30 deutsche Gesellschaften der E.ON Energie AG übernimmt: Hilfreich war die Zusammenarbeit von ITSpezialisten und Mitarbeitern des Personalmanagements bereits in der Konzeptionsphase, um angemessene Anforderungen an das System zu definieren. Eine klare Rollenverteilung und intensive Kommunikation der Ziele und Verantwortungsbereiche für Wissenstransfer und -aktualisierung sind unverzichtbar. Es entstand ein erheblicher Aufwand für die Erstellung und Qualitätsprüfung der Inhalte der „Wissensdatenbank“. Der Aufwand konnte durch die Bereitstellung von Eingabehilfen, Mustertexten und Vorlagen sowie durch die Unterstützung eines für die Erstellung und Pflege der Datenbank zuständigen Wissensmanagers gesenkt werden. Die kontinuierliche Weiterentwicklung und Aktualisierung der Einträge in die „Wissensdatenbank“ kann durch Vernetzung der Autoren unterstützt werden. Aufgabenverweise Datenmanagement (Lerneinheit DATEM); Qualitätsmanagement (Lerneinheit QUALM); Wissensmanagement (Lerneinheit WIMAN). Fallstudienverweis Lerneinheit FSDOK beschreibt eine Einführungsstrategie für ein Content-Management-System. Kontrollfragen 1. Welche Methoden eignen sich zur Wissensidentifikation im Rahmen der Personalisierungsstrategie? 2. Welche Aufgaben können Wissenskarten unterstützen?

458 3. 4. 5.

Methoden des administrativen Informationsmanagements

Welcher Zusammenhang besteht zwischen Business Intelligence und Wissensmanagement? Welche Schwierigkeiten ergeben sich bei der Bewertung einer Wissensbasis eines Unternehmens mit deduktiv summarischen Wissensbewertungsmethoden? Wodurch unterscheidet sich eine kaufmännische Bilanz von einer Wissensbilanz?

Quellen Bock, A.: Dokumenten-Management-System (DMS). In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. A., Berlin/Heidelberg/New York 2001, 157–158 Bughin, J. / Chui, M.: The Rise of the Networked Enterprise: Web 2.0 finds its Payday. In: McKinsey Quarterly 12/2010, https://www.mckinseyquarterly.com; Abruf 31. Mai 2011 Chamoni, P. / Gluchowski, P.: Integrationstrends bei Business-Intelligence-Systemen. Empirische Untersuchung auf Basis des Business Intelligence Maturity Model. In: WIRTSCHAFTSINFORMATIK 2/2004, 119–128 Codd, E. F. / Codd, S. B. / Salley, C. T.: Providing OLAP to User-Analysts: An IT Mandate. Ann Arbor/Michigan 1993 DeLone, W. H. / McLean, E. R.: The DeLone and McLean Model of Information System Success: A Ten-Year Update. In: Journal of Management Information Systems 4/2003, 9–30 Eppler, M. J.: Making Knowledge Visible through Knowledge Maps: Concepts, Elements, Cases. In: Holsapple, C. W. (Hrsg.): Handbook on Knowledge Management 1. Knowledge Matters. Berlin/Heidelberg/New York 2003, 189–205 Finkelstein, C.: The Emergence and Potential of Enterprise Information Portals (EIPs). o. O. 1999. http://www.tdan.com; Abruf 17. September 2007 Gentsch, P.: Wissen managen mit innovativer Informationstechnologie. Strategien - Werkzeuge - Praxisbeispiele. Wiesbaden 1999 Hagedorn, T. et al.: Wissens- und Informationsmanagement in der Praxis - Einführung einer Wissensdatenbank beim Aufbau eines Shared-Service-Centers bei E.ON Energie. In: Keuper, F. / Neumann, F. (Hrsg.): Wissensund Informationsmanagement. Strategien, Organisation und Prozesse. Wiesbaden 2009, 241–264 Hartmann, P.: Content Management (CM). In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. A., Berlin/Heidelberg/New York 2001, 121–122 Hauschildt, J. / Salomo, S.: Innovationsmanagement. 4. A., München 2007 Kemper, H.-G. / Mehanna, W. / Unger, C.: Business Intelligence - Grundlagen und praktische Anwendungen. Eine Einführung in die IT-basierte Managementunterstützung. 2. A., Wiesbaden 2006 Mertins, K. / Alwert, K.: Integrierte Wissensbewertung - Ein Instrument zur Bewertung, Steuerung und Bilanzierung von Wissen. In: ZWF- Zeitschrift für wirtschaftlichen Fabrikbetrieb 11/2003, 578–582 Nonaka, I. / Takeuchi, H.: The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation. New York 1995 North, K. / Probst, G. / Romhardt, K.: Wissen messen - Ansätze, Erfahrungen und kritische Fragen. In: ZfO - Zeitschrift Führung und Organisation 3/1998, 158–166 O'Reilly, T.: What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software. http://www.oreilly.de/artikel/web20.html o. O. 2005, Abruf 9. Juni 2011 Probst, G. J. B. / Raub, S. / Romhardt, K.: Wissen Managen. Wie Unternehmen ihre wertvollste Ressource optimal nutzen. 5. A., Wiesbaden 2006 Roehl, H.: Instrumente der Wissensorganisation. Perspektiven für eine differenzierende Interventionspraxis. Wiesbaden/New York 2000 Sedera, D. / Gable, G.: Knowledge Management Competence for Enterprise System Success. In: Journal of Strategic Information Systems 4/2010, 296–306 Stata, R.: Organizational Learning - The key to management innovation. In: Sloan Management Review 3/1989, 63– 74 Stelzer, D.: Portale - Einführung und Überblick. In: Gentsch, P. / Lee, S. (Hrsg.): Praxishandbuch Portalmanagement. Profitable Strategien für Internetportale. Wiesbaden 2004, 1–26 Wenger, E. C. / Snyder, W. M.: Communities of Practice: The Organizational Frontier. In: Harvard Business Review. 1/2000, 139–145 Vertiefungsliteratur Güldenberg, S.: Wissensmanagement und Wissenscontrolling in lernenden Organisationen - Ein systemtheoretischer Ansatz. 4. A., Braunschweig/Wiesbaden 2003. 251–306 North, K.: Wissensorientierte Unternehmensführung. Wertschöpfung durch Wissen. 4. A., Wiesbaden 2005 Riempp, G.: Integrierte Wissensmanagement-Systeme. Architektur und praktische Anwendung. Berlin/Heidelberg/ New York 2004

Kosten- und Leistungsrechnung (KOLER) Lernziele Sie kennen die Zwecke der Kosten- und Leistungsrechnung für die IT. Sie können die Verrechnung durch Kostenumlage bzw. durch Verrechnungspreise als alternative Methoden der Auftragsrechnung erklären. Sie können begründen, unter welchen Voraussetzungen die Verwendung von Verrechnungspreisen zweckmäßig und welche Art von Verrechnungspreis geeignet ist. Sie kennen die Bedeutung von Leistungsportfolios, Kostenarten und Kostenstellen und können Beispiele für Leistungen, Kostenarten und Kostenstellen nennen.

Definitionen und Abkürzungen Auftrag (job) = Aufforderung zur Erbringung einer definierten Leistung. Betriebsmittel (production facility) = zur Abarbeitung eines Auftrags zur Verfügung stehende Hardware und Software sowie Personal und andere Hilfsmittel. Grenzkosten (marginal costs) = Kosten, die durch Veränderung der Beschäftigung um eine Produktionseinheit zusätzlich entstehen bzw. entfallen. Kosten (costs) = mit Geldeinheiten bewertete Konsequenzen einer Leistung bezüglich ihres Verbrauchs an Gütern und/oder Diensten. Kostenart (cost item) = Ergebnis der Zerlegung von Kosten nach der Art des Verbrauchs an Gütern und/oder Diensten. Kostenmanagement (cost management) = Managementprozess, dessen Zweck die Erfassung und Analyse der Kosten und deren zielgerichtete Beeinflussung ist. Kostenstelle (cost center) = Aufgaben- und Verantwortungsbereich, der Leistungen beansprucht und dem nach vereinbarten Gestaltungszielen Kosten zugerechnet werden. Kostenstruktur (cost structure) = Zusammensetzung von Kosten nach Kostenart und Kostenhöhe bzw. relativer Anteil der Kosten je Kostenart. Kostenträger (cost unit) = Leistungseinheit, der Kosten zugerechnet werden, idealer Weise die Kosten, die sie verursacht hat. Kostenumlage (cost allocation) = Verteilung von Kosten, die den Leistungen nicht direkt zugerechnet werden, mittels Kostenverteilungsschlüssel. Kostenverteilungsschlüssel (cost allocation key) = nach bestimmten Prinzipien gebildeter Algorithmus zur Verrechnung von Kosten auf Kostenstellen oder Leistungen. Leistung (performance) = Größe, die für die ökonomische Beurteilung des Outputs eines Systems von Bedeutung ist und als Bezugsgröße für Kosten dient. Nutzen (benefit) = der subjektiv beeinflussbare Wert einer Handlungsalternative zur Befriedigung eines Bedarfs. Nutzenpreis (benefit rate) = Preis für die Bearbeitung eines Auftrags, den ein Auftraggeber zu zahlen bereit ist. Synonym: Knappheitspreis. Verrechnungspreis (transfer rate) = Preis für innerbetriebliche Leistungen, die zwischen den Struktureinheiten ausgetauscht werden. Synonym: Lenkungspreis.

460

Methoden des administrativen Informationsmanagements

Zwecke der Kosten- und Leistungsrechnung Die konkreten Zwecke der Kosten- und Leistungsrechnung für den IT-Bereich bzw. die ITAbteilung (im Folgenden synonym verwendet) werden – wie bei der betrieblichen Kostenund Leistungsrechnung generell – aus ihren Funktionen abgeleitet, das sind:    

Kosten ermitteln oder berechnen (Ermittlungsfunktion bzw. Abrechnungsfunktion), Kosten vorhersagen (Prognosefunktion), Kosten vorgeben oder planen (Vorgabefunktion) und Kosten überprüfen oder kontrollieren (Kontrollfunktion).

Daraus ergeben sich folgende Zwecke der Kosten- und Leistungsrechnung:    

Preiskalkulation und Preisbeurteilung, Kontrolle der Wirtschaftlichkeit, Informationsgewinnung für Entscheidungsrechnungen und kurzfristige Erfolgsermittlung und Budgetierung.

Preiskalkulation und Preisbeurteilung: Bietet der IT-Bereich Produkte (z. B. Software) oder Dienstleistungen (z. B. Rechnerleistung) außerhalb des Unternehmens an, sind Verkaufspreise festzulegen bzw. Marktpreise zu ermitteln und daraufhin zu prüfen, ob sie die Kosten decken. Fragt die IT-Abteilung Produkte oder Dienstleistungen am Markt nach, ist zu prüfen, welche Einkaufspreise sie maximal akzeptieren kann, um bei gegebenen Verkaufsoder Verrechnungspreisen geplante Ziele zur erreichen (z. B. Kostendeckung zu erzielen). Schließlich sind Verrechnungspreise für interne Leistungen festzulegen, die internen Auftraggebern (Benutzer bzw. Fachabteilungen oder Geschäftsprozesse, allgemein Kostenstellen) angeboten oder von diesen nachgefragt werden. Kontrolle der Wirtschaftlichkeit: Diese bezieht sich auf die Kontrolle der Kosten ausgewählter Kostenarten, der IT-Kosten insgesamt oder einzelner Kostenstellen wie IT-Abteilung oder einzelner ihrer Struktureinheiten (vgl. Lerneinheit STRUK). Kosten meint in diesem Zusammenhang Informations- und Kommunikationskosten, das heißt die Kosten der Informationsproduktion und Kommunikation. Dabei kann ein Zeitvergleich, Betriebsvergleich oder Soll/Ist-Vergleich durchgeführt werden. Eine Kosten- und Leistungsrechnung, die nach Stellen innerhalb der IT-Abteilung gegliedert ist, ermöglicht die Kontrolle der Wirtschaftlichkeit der Leistungserstellung in kleinen Verantwortungsbereichen. Der Erfolg wird entweder als Differenz zwischen bewerteter Leistung und Kosten oder durch Vergleich von Sollkosten mit Istkosten ermittelt. Der Grundsatz der Trennung zwischen den vom Kostenstellenverantwortlichen beeinflussbaren und nicht beeinflussbaren Kosten ist zu beachten. Informationsgewinnung für Entscheidungsrechnungen: Dabei handelt es sich im Wesentlichen um Verfahrensvergleiche, methodisch meist um eine Wirtschaftlichkeitsanalyse (vgl. Lerneinheit WIRTA). Typische Beispiele sind die Wahl des Bereitstellungswegs für Software (Eigenerstellung oder Fremdbezug), die Beantwortung der Frage „Kauf oder Miete von Software- und Hardwareprodukten“ sowie die Entscheidung über Art und Umfang von Auslagerung bzw. Ausgliederung (Outsourcing-Grad, vgl. Lerneinheit OUTSO).

Kosten- und Leistungsrechnung (KOLER)

461

Kurzfristige Erfolgsermittlung und Budgetierung: Wird die Erfolgsermittlung auf kurze Zeiträume (in der Regel wenige Monate) bezogen und soll auch gezeigt werden, wie einzelne Produkte oder Dienstleistungen als so genannte Kostenträger zum Erfolg der IT-Abteilung bzw. einzelner Stellen der IT-Abteilung beigetragen haben, handelt es sich um eine kurzfristige Erfolgsermittlung. Sie setzt die Möglichkeit der verursachungsgerechten Zurechnung von Kosten auf Kostenträger voraus und schließt die Aufgabe der Bestandsbewertung von Produkten ein, was insbesondere bei Softwareprodukten schwierig ist (Bewertung im Unterschied zur Evaluierung von Software, vgl. Lerneinheit EVALU). Budgetierung meint in diesem Zusammenhang die Planung der IT-Kosten für zukünftige Perioden als Voraussetzung für ein wirksames Kostenmanagement (vgl. Lerneinheit CONTR).

Systematik der Verrechnungsmethoden Die Methoden der Kosten- und Leistungsrechnung werden nach folgenden Gesichtspunkten systematisiert:   

nach dem Zurechnungsobjekt in Periodenrechnung (Kostenarten-, Kostenstellen- und Kostenträgerzeitrechnung) und Auftragsrechnung, nach der Art der verrechneten Kosten in Plankostenrechnung und Istkostenrechnung und nach ihrem Umfang in Vollkostenrechnung und Teilkostenrechnung.

Die Beurteilung der Zweckmäßigkeit der Methoden hängt unter anderem davon ab, welche Betriebsmittel verwendet werden; dies gilt insbesondere für den Produktionsbetrieb (vgl. Lerneinheit INMAN). Die Methoden müssen der Technologieentwicklung entsprechend angepasst werden. Nachfolgend wird die Verwendung zentraler Betriebsmittel unterstellt, für die technische Leistungen bekannt sind und über deren Brauchbarkeit für die Kosten- und Leistungsrechnung Erfahrungen vorliegen. Bei Client/Server-Systemen ist beispielsweise eine Anschlussgebühr die adäquate Leistungsgröße für nicht direkt zurechenbare Kosten. Die Dynamik neuer Technologien, die Heterogenität der Verteilung der Betriebsmittel und die komplexere Nutzungsstruktur bei verteilten Systemen im Vergleich zu Hostsystemen erschweren die Kosten- und Leistungsrechnung. Allen Methoden liegt eine zweckmäßige Gliederung der Kosten in Kostenarten zu Grunde (vgl. Abschnitt Kostenarten und Kostenstellen). Aus dem umfangreichen Komplex der Methoden wird hier auf die Auftragsrechnung (Kalkulation oder Kostenträgerrechnung) eingegangen. Leistungen im Sinne der Auftragsrechnung sind unterscheidbare, bezüglich der Kostenverursachung unterschiedliche Produkte und Dienstleistungen (z. B. Produktions-, Wartungs-, Entwicklungs- oder Serviceaufträge). Es werden die Verrechnung durch Kostenumlage und die Verrechnung durch Verrechnungspreise als alternative Kalkulationsmethoden gezeigt, wie sie vor allem für Produktionsaufträge verwendet werden.

Gestaltungsziele der Auftragsrechnung Für die Gestaltung der Auftragsrechnung sollen folgende Ziele beachtet werden: 

Den Kostenstellen sollen die Leistungen, die sie beansprucht haben, und alle Kosten, die diese Leistungen verursacht haben, zugerechnet werden (Verursachungsgerechtigkeit).

462

     

Methoden des administrativen Informationsmanagements

Die Beanspruchung der Betriebsmittel soll in Abhängigkeit von ihrer Verfügbarkeit gesteuert werden. Den Auftraggebern sollen Anreize gegeben werden, ihre Aufträge nach ökonomischen Gesichtspunkten zu gestalten. Die Verrechnungsmethode soll für die Auftraggeber transparent sein; die Ergebnisse der Verrechnung sollen für sie nachvollziehbar sein. Die Verrechnungsmethode soll zwischen beeinflussbaren und nicht beeinflussbaren Kosten differenzieren und sich in das bestehende Gesamtkonzept des betrieblichen Rechnungswesens einfügen. Alle Auftraggeber sollen gleich behandelt werden; es soll keine Subventionierung des Leistungsbezugs und keine Kostenverrechnung ohne Leistungsbezug erfolgen. Die Verrechnung soll mit geringem Aufwand administrierbar sein.

Die Bedeutung der Erreichung der Gestaltungsziele ist umso größer, je mehr die Auftraggeber als Kunden agieren und behandelt werden, das heißt insbesondere gegenüber Outsourcing-Gebern (vgl. Lerneinheit OUTSO). Bereits eine oberflächliche Zielanalyse zeigt, dass es nicht möglich ist, mit nur einer Verrechnungsmethode alle Gestaltungsziele zu erreichen. Daher sind Zielkompromisse erforderlich, oder es sind – je nach Entscheidungssituation – unterschiedliche Verrechnungsmethoden zu verwenden. Nachfolgend werden die Verrechnung durch Kostenumlage und die Verrechnung mit Verrechnungspreisen mit jeweils mehreren Varianten gezeigt.

Verrechnung durch Kostenumlage Kostenumlage ist eine einfache und wenig differenzierende Verrechnungsmethode; die ITAbteilung ist verrechnungstechnisch eine Hilfskostenstelle. Die IT-Kosten einer Abrechnungsperiode (Ist-Rechnung), d. h. die in der IT-Abteilung entstandenen Kosten sowie die Kosten für Leistungen, die von anderen Fachbereichen für die IT-Abteilung erbracht werden (z. B. Leistungen des Rechnungswesens, des Controllings oder der Revision), werden mit Hilfe eines elementaren oder eines kombinierten oder mehrerer Kostenverteilungsschlüssel auf die Kostenstellen, welche die Leistungen beansprucht haben, umgelegt. Zweckmäßigerweise erfolgt die Verwendung dieser Verrechnungsmethode nur für den Teil der Kosten, der nicht direkt zurechenbar ist (also für die Gemeinkosten). Je mehr es gelingt, Kosten direkt zuzurechnen und so den Anteil der Gemeinkosten zu verringern, desto besser werden die Gestaltungsziele der Auftragsrechnung mit dieser einfachen Verrechnungsmethode erreicht. Eine Verringerung der Gemeinkosten kann auch dadurch erreicht werden, dass erbrachte und bezogene Leistungen bei vereinbarten Abnahmemengen zwischen den beteiligten Kostenstellen verrechnet werden (Ressourcensteuerung nach dem so genannten Factory-Modell). Mit der Reduzierung der Kosten, die umgelegt werden müssen, verringert sich das Problem der Bestimmung geeigneter (d. h. insbesondere verursachungsgerechter) Kostenverteilungsschlüssel. Elementare Kostenverteilungsschlüssel enthalten jeweils nur ein Kostenverteilungsprinzip (eine Schlüsselgröße); kombinierte Kostenverteilungsschlüssel verknüpfen mehrere Kostenverteilungsprinzipien. Schließlich können auch mehrere elementare oder kombinierte Kostenverteilungsschlüssel gemeinsam verwendet werden. Elementare Kostenverteilungsschlüssel reichen aus, wenn das Anspruchsprofil der Auftraggeber bzw. das Bean-

Kosten- und Leistungsrechnung (KOLER)

463

spruchungsprofil der Betriebsmittel homogen und stabil ist. Je weniger dies der Fall ist, desto weniger wird bei Verwendung elementarer Kostenverteilungsschlüssel zwischen beanspruchter Leistung und verrechneten Kosten die angestrebte Verhältnismäßigkeit erreicht. Kostenverteilungsschlüssel sollen so festgelegt werden, dass ein direkter Bezug zwischen der in Anspruch genommenen Leistung und den verrechneten Kosten hergestellt wird. Dies wird am besten dadurch erreicht, dass für unterschiedliche Leistungen spezifische Bezugsgrößen definiert und für die Kostenverrechnung verwendet werden. Da für bestimmte Stellen der ITAbteilung spezifische Bezugsgrößen nicht verfügbar sind (z. B. für Abteilungsleitung, Technologiemanagement, Controlling), werden die Kosten dieser Stellen zunächst nach einem (elementaren oder kombinierten) bzw. nach mehreren geeigneten Kostenverteilungsschlüsseln solchen Stellen der IT-Abteilung zugerechnet, die direkt zurechenbare Leistungen für die Auftraggeber erbringen (z. B. Helpdesk, Systementwicklung, Rechenzentumsbetrieb), und dann mit diesen Leistungen verrechnet. Die Kosten der Stelle Helpdesk werden mit der Leistung Serviceauftrag direkt verrechnet. Die Kosten der Kostenstelle Systementwicklung werden ebenfalls direkt verrechnet; als Leistungen können Entwicklungsaufträge und Wartungsaufträge verwendet werden. Der Projektaufwand kann zu einem erheblichen Teil direkt erfasst und – mit einem einheitlichen Stundensatz oder mit unterschiedlichen Stundensätzen nach Art der erbrachten Leistung – bewertet werden (insbesondere der Personalaufwand). Nicht direkt zurechenbare Projektkosten werden mittels Verteilungsschlüssel zugerechnet. Die Kosten der Stelle RZ-Betrieb werden den Produktionsaufträgen (nachfolgend kurz als Auftrag bezeichnet) zugerechnet. In der Praxis verwendete Bezugsgrößen für die Bildung von Verteilungsschlüsseln zur Zurechnung der Kosten der Stelle RZ-Betrieb auf Aufträge sind meist technische Leistungen wie Anzahl Transaktionen, Anzahl Zugriffe auf Datenbestände, Anzahl aufgerufene Bildschirmseiten, Anzahl Druckzeilen auf Listen oder beanspruchte CPU-Zeit.

Verrechnung mit Verrechnungspreisen Verrechnungspreise können summarisch oder differenziert gebildet werden. Summarische Verrechnungspreise unterscheiden nicht oder nur schwach nach der Art der Leistung; mit differenzierenden Verrechnungspreisen wird eine verursachungsgerechte Zurechnung der Kosten besser erreicht. Insoweit besteht eine Analogie zu den elementaren bzw. kombinierten Kostenverteilungsschlüsseln bei der Verrechnung durch Kostenumlage. Auch bezüglich der Verrechnung mit Verrechnungspreisen gilt, dass damit nur die Kosten verrechnet werden sollen, die nicht direkt zugerechnet werden können. Summarische Verrechnungspreise: Bei summarischer bzw. nur schwach differenzierender Bildung der Verrechnungspreise wird zwischen einem Personalstundensatz und einem Maschinenstundensatz unterschieden. Mit dem Personalstundensatz werden Aufträge oder Auftragsteile abgerechnet, die vorwiegend personelle Leistungen beanspruchen (z. B. Leistungen von Softwareentwicklern in der Stelle Systementwicklung). Mit dem Maschinenstundensatz werden Aufträge oder Auftragsteile abgerechnet, die vorwiegend Leistungen von Betriebsmitteln beanspruchen, vor allem Leistungen der Stelle RZ-Betrieb.

464

Methoden des administrativen Informationsmanagements

Differenzierende Verrechnungspreise: Für die Bildung differenzierender Verrechnungspreise werden verschiedene Differenzierungsstrategien (einzeln oder mehrere gemeinsam) verwendet. Beispiele sind:     

Differenzierung nach dem Zeitpunkt oder Zeitraum der Inanspruchnahme von Leistungen (z. B. Tages- bzw. Nachtpreise), Differenzierung nach Art der Aufträge (z. B. Aufträge mit geringer bzw. hoher Kostenbelastbarkeit), Differenzierung nach Leistungsmengen (z. B. durch Rabatte), Differenzierung nach der Bindungsdauer (z. B. ohne bzw. mit jährlicher Reservierung von Kapazität) und Differenzierung nach Arbeitsplätzen (z. B. technische Komponenten der Betriebsmittel).

Bei der Differenzierung nach Arbeitsplätzen werden innerhalb der Stellen Systementwicklung und RZ-Betrieb top-down Teilsysteme und innerhalb der Teilsysteme Untersysteme gebildet. Damit wird die Bezugsgröße Personalstunde nach der Leistungsart differenziert (z. B. Personalstundensätze für Analyse, Entwurf oder Implementierung). Der Maschinenstundensatz für Betriebsmittel wird in mehrere Maschinenstundensätze zerlegt. Systemkomponenten von Betriebsmitteln, die in das Verrechnungsmodell eingehen können, sind:      

Zentraleinheit (CPU) mit der Nutzungseinheit Zeit, Hauptspeicher mit der Nutzungseinheit belegter Speicher mal CPU-Zeit, Externspeicher mit der Nutzungseinheit belegter Speicher mal Belegungszeit, Drucker mit der Nutzungseinheit Druckzeile oder Druckseite, Datenerfassungsgeräte mit der Nutzungseinheit Datensatz und Datenübertragungseinrichtungen mit der Nutzungseinheit Anzahl Netzanschlüsse oder Anzahl Transaktionen.

Voraussetzung für die Verwendung differenzierender Verrechnungspreise ist eine entsprechend genaue Erfassung der durch den einzelnen Auftrag in Anspruch genommenen Leistungen. Für personelle Leistungen erfolgt eine auftragsbezogene Zeiterfassung; für die Erfassung der Leistungen von Betriebsmitteln ist ein Abrechnungssystem erforderlich (vgl. Abschnitt Werkzeuge). Jede Personalstunde und jede Maschinenstunde wird mit einem Verrechnungspreis (Personalstundensatz bzw. Maschinenstundensatz) bewertet. Aus Gründen der Kostentransparenz sollen Leistungen verwendet werden, die einen engen Bezug zur Arbeitsaufgabe haben (z. B. Anzahl Buchungen, Rechnungen oder Mahnungen). Die Verrechnung der Kosten technischer Leistungen (z. B. CPU-Zeit, Anzahl I/O Operations) ist für die Auftraggeber kaum nachvollziehbar. Da die direkte Zurechnung der Kosten auf betriebswirtschaftliche Leistungen einen erheblichen Aufwand verursachen würde, wird für jeden Business Service ein mit Kosten bewerteter „Warenkorb technischer Leistungen“ definiert, mit dem eine verursachungsgerechte Beziehung zwischen IT-Services und Business Services hergestellt wird. Brandl/Bichler/Ströbel bezeichnen diese Beziehungen als Ressourcenprofile (vgl. Abschnitt Forschungsbefunde). Derartige Lösungen sind nur für häufig wiederkehrende Aufträge zweckmäßig. Atypische Aufträge (z. B. Aufträge, die nur von einer Kostenstelle sporadisch veranlasst werden) sollen gesondert verrechnet werden.

Kosten- und Leistungsrechnung (KOLER)

465

Eignung unterschiedlicher Verrechnungspreise Im Abschnitt „Gestaltungsziele der Auftragsrechnung“ wurden Verrechnungsziele und Lenkungsziele genannt. Lenkungsziele helfen, knappe Betriebsmittel so einzusetzen, dass ihre Nutzung optimiert wird (Motivationsfunktion). Es wird gezeigt, welche Arten von Verrechnungspreisen eine Motivationsfunktion haben und Lenkungsziele gut unterstützen; dabei wird die Stelle RZ-Betrieb betrachtet. 





 

Kostenorientierter Verrechnungspreis auf der Basis von Grenzkosten: Da Grenzkosten der Stelle RZ-Betrieb die Kosten sind, die durch Veränderung der Beschäftigung um eine Produktionseinheit Auftrag zusätzlich entstehen bzw. entfallen, kann diese Art Verrechnungspreis grundsätzlich Lenkungsziele sehr gut unterstützen. Da aber die Kosten der Produktion kurzfristig fast zu 100 % fix sind, sind die Grenzkosten für einen Auftrag nahezu Null. Ein kostenorientierter Verrechnungspreis zu Grenzkosten kann daher bei der Auftragsrechnung im RZ-Betrieb die Erreichung von Lenkungszielen wie auch von Abrechnungszielen nicht unterstützen. Kostenorientierter Verrechnungspreis auf der Basis von Vollkosten: Vollkosten eines Auftrags werden so ermittelt, dass zunächst ein Kostensatz je Leistungseinheit eines Betriebsmittels bestimmt wird, indem die budgetierten Kosten durch die geplante oder die tatsächliche Beschäftigung dividiert werden. Dieser Kostensatz wird mit den in Anspruch genommenen Leistungseinheiten multipliziert. Dem Auftrag nicht direkt zurechenbare Kosten werden durch Kostenumlage verrechnet. Vollkosten auf Basis der geplanten Beschäftigung motivieren die Auftraggeber allenfalls zu einer in etwa kostendeckenden Verwendung der Betriebsmittel. Übersteigt die Nachfrage die vorhandene Kapazität, liefert dieser Verrechnungspreis keinen Anhaltspunkt dafür, wie die Aufträge verschoben werden sollen; er übt keine Lenkungsfunktion aus. Wird die tatsächliche Beschäftigung zugrunde gelegt, ist der Preis bereits bei geringer Auslastung hoch und motiviert dazu, wenig genutzte Betriebsmittel noch weniger zu beanspruchen (et vice versa). Marktorientierter Verrechnungspreis: Wenn ein relativ stabiler Marktpreis bekannt ist, kann er als Verrechnungspreis verwendet werden. Dies ist in der Regel nicht der Fall, weshalb es bereits Eugen Schmalenbach (1873-1955) als unlogisch bezeichnet hat, Marktpreise als Verrechnungspreise zu verwenden. Festpreis: Auftraggeber und Auftragnehmer vereinbaren einen für bestimmte Perioden oder Aufträge geltenden Preis je Leistungseinheit. Entscheidende Vorteile des Festpreises sind hohe Transparenz und geringer Administrationsaufwand. Nutzenpreis: Von einer Gruppe wartender Aufträge wird derjenige zuerst bearbeitet, der den höchsten Nutzenpreis hat. Die Bewertung eines Betriebsmittels entspricht dem Grad seiner Knappheit (Nutzenpreis = Knappheitspreis). Da der Nutzenpreis auch den Preis angibt, der für eine Kapazitätserweiterung maximal aufgewendet werden sollte, eignet er sich als Investitionsindikator.

Der Nutzenpreis als Verrechnungspreis unterstützt die Motivationsfunktion von Lenkungszielen am besten. Problematisch ist er bei stark schwankender Nachfrage, die zu einer erheblichen Schwankung des Verrechnungspreises führt. Das Benutzerverhalten kann zwar mit dem Nutzenpreis direkt beeinflusst werden, doch können Auftraggeber die Fertigstellung

466

Methoden des administrativen Informationsmanagements

ihres Auftrags nur bedingt planen, weil der Nutzenpreis nicht verlässlich vorausgesagt werden kann. Durch flankierende Maßnahmen – wie Preisstufen und Entscheidungshilfen – kann diese Auswirkung verringert werden. Weitere Typen von Verrechnungspreisen sind qualitätsorientierte Preise (die sich an Serviceebenen-Vereinbarungen orientieren, vgl. Lerneinheit SEVER), prozessbasierte Preise (was die Anwendung der Prozesskostenrechnung zur Ermittlung der Prozesskosten voraussetzt, vgl. Abschnitt Prozesskostenrechnung) und zielorientierte Preise, die sich wertanalytisch am Kundennutzen ausrichten.

Vergleich der Verrechnungsmethoden Bezüglich folgender Gestaltungsziele der Auftragsrechnung ist die Verrechnung mit Verrechnungspreisen günstiger als die mit Kostenumlage:    

Verursachungsgerechtigkeit, Anreizbildung zur optimalen Gestaltung der Aufträge, Vermeidung unnötiger Service-Anforderungen und Lenkung der Betriebsmittelnutzung.

Dies gilt umso mehr, je komplexer die verwendeten Betriebsmittel sind und je stärker die Verrechnungspreise differenzierend gebildet werden. Bezüglich der Nachvollziehbarkeit der Verrechnung haben Umlageverfahren zweifellos Vorteile. Bei Verrechnungspreisen sind den Auftraggebern deshalb aussagefähige, detaillierte Abrechnungen zur Verfügung zu stellen, welche die in Anspruch genommenen Leistungen, die Preise zur Bewertung der Leistungen und die Rechnungsbeträge je Auftrag und Arbeitsplatz angeben. Bezüglich der Zurechenbarkeit gilt: Bei Kostenumlage können alle (entstandenen) Kosten ex post auf die Aufträge zugerechnet werden. Bei Verrechnungspreisen sind die nicht zurechenbaren Kosten (z. B. Kosten ungeplanter Leerkapazität) en bloc im Betriebsergebnis zu verrechnen (bzw. im Ergebnis der IT-Abteilung, wenn diese als Profit-Center geführt wird, vgl. Lerneinheit STRUK). Die nicht zurechenbaren Kosten sind umso höher, je größer die Abweichung zwischen geplanter und tatsächlicher Kapazitätsauslastung bzw. geplanter und tatsächlicher Leistung ist. Die Verwendung von Verrechnungspreisen erfordert daher eine sorgfältige Planung der Leistungen und damit der Inanspruchnahme der Kapazität. Entscheidungen über die Gestaltung der Kosten- und Leistungsrechnung setzen eine systematische Strukturierung der Leistungen des IT-Bereichs sowie eine gründliche Analyse der Kostenhöhe, der Kostenstruktur und des Kostenverlaufs voraus (vgl. Lerneinheit CONTR). Leistungen müssen klar definiert und in einem Leistungsportfolio beschrieben sein (vgl. Lerneinheit SEMAN). Da nur Endprodukte (z. B. Produktionsaufträge) von den Kunden wahrgenommen werden, werden die Kosten der Vorprodukte (z. B. Wartungsaufträge) den Endprodukten zugerechnet. Für jede Leistung, Leistungsklasse (das sind funktional systematisierte Leistungen) oder für jedes Leistungspaket (das sind marktfähige Leistungen) sollte ein Produktmanager (vgl. Lerneinheit STELL) Ansprechpartner für die Auftraggeber sein. Sind die Leistungen definiert, kann eine zweckmäßige Struktur der Kostenarten und Kostenstellen erarbeitet werden.

Kosten- und Leistungsrechnung (KOLER)

467

Kostenarten- und Kostenstellenstruktur Für die Gliederung des IT-Bereichs in Kostenarten gilt der Grundsatz, dass nur vom Volumen her für das Kostenmanagement interessante Kosten eine eigene Kostenart rechtfertigen und dass die Kosten umso stärker gegliedert werden sollen, je besser sie vom Kostenverantwortlichen beeinflusst werden können. In den in der Praxis verwendeten Verrechnungssystemen sind IT-Kosten oft keine eigene Kostenart, sondern entsprechen einer bestehenden Kostenkategorie, der einzelne IT-Kosten zugeordnet werden (z. B. werden die Kosten für Hardware der Kostenkategorie Sachmittelkosten zugeordnet). Deshalb müssen bestehende Verrechnungssysteme für die explizite Berücksichtigung von IT-Kosten angepasst werden. Folgende Beispiele für Kostenarten verwenden sowohl bestehende Kostenkategorien (z. B. Personalkosten) als auch spezifische Kostenarten (z. B. Hardwarekosten):         

Materialkosten (wie Kosten für Datenträger), Energiekosten (wie Kosten für Stromverbrauch), Personalkosten und Personalnebenkosten (wie Löhne, Gehälter, Sozialleistungen), Hardwarekosten (wie Mietkosten bzw. Abschreibungen und Wartungskosten), Softwarekosten (wie Lizenz- und Wartungskosten bzw. Abschreibungen), Netzkosten (wie Leitungskosten und Kosten für Transportdienste), Grundstücks- und Gebäudekosten (wie Pacht, Miete und Instandhaltung), Fremdkosten (wie Beratungskosten und Kosten für Fremdprogrammierung), Kosten für Büroausstattung und Bürogeräte.

Die Bildung von Kostenstellen der IT-Abteilung soll sich an bestehenden Verantwortungsbereichen orientieren. Folgende Mindestgliederung soll dabei beachtet werden:     

Kostenstellen, die Leistungen für die Produktion (den RZ-Betrieb) erbringen, Kostenstellen, die Leistungen für die Systementwicklung erbringen, Kostenstellen, die Service- und Wartungsleistungen erbringen (z. B. Helpdesk), Kostenstellen, die Leistungen für die Unterstützung der Auftraggeber erbringen (z. B. Schulung und Beratung) und Kostenstellen, die für mehrere Bereiche Leistungen erbringen (z. B. Leitungsstellen).

Rahmenbedingungen für die Gliederung des IT-Bereichs in Kostenstellen sind die strategischen Entscheidungen zur Strukturorganisation (z. B. zentrale IT-Abteilung versus dezentrale IT-Abteilungen, vgl. Lerneinheit STRUK).

Prozesskostenrechnung Werden Leistungen der IT-Abteilung in Form von Leistungsprozessen definiert und diesen Kapazität und Kosten (in der Regel mit Verrechnungspreisen bewertet) zugeordnet, kann ein Prozesskostensatz bestimmt werden, der bei jeder Leistungsinanspruchnahme (z. B. durch einen Wartungsauftrag) verrechnet wird. Ein Auftrag kann einen Prozess mehrmals in Anspruch bzw. mehrere Prozesse und diese auch mehrmals in Anspruch nehmen. Die Kosten eines Prozesses i, die einem Auftrag j zugerechnet werden, ergeben sich wie folgt: PKij = PKSi . PMij

468

Methoden des administrativen Informationsmanagements

mit PKSi Prozesskostensatz des Prozesses i und PMij Kapazität von Prozess i, die von Auftrag j beansprucht wird. Drei Probleme müssen gelöst werden, um Prozesskostensätze ermitteln und die Prozesskostenrechnung verwenden zu können: Identifikation von IT-Prozessen, Bestimmung der Kapazität der IT-Prozesse und Zurechnung der Kostenarten auf die ITProzesse. Auch für die Prozesskostenrechnung gilt, dass nur die Kosten zugerechnet werden sollen, die den Kostenverursachern nicht direkt zugerechnet werden können (Gemeinkosten). IT-Prozesse sind teilweise aus den Auftrag gebenden Geschäftsprozessen ableitbar, insbesondere die primären IT-Prozesse oder IT-Kernprozesse, teilweise ergeben sie sich aus der Struktur- und Ablauforganisation der IT-Abteilung, im Allgemeinen stark beeinflusst durch die verwendeten Betriebsmittel. Die bei Geschäftsprozessen übliche Systematisierung kann auch für IT-Prozesse verwendet werden (z. B. in Kernprozesse, Unterstützungsprozesse und Managementprozesse). Beispiele für Geschäftsprozesse der IT nach dieser Typologie sind:   

Kernprozesse wie Systementwicklung, Abwicklung von Produktionsaufträgen, Erbringung von Helpdesk-Dienstleistungen, Unterstützungsprozesse wie Beschaffung von Betriebsmitteln, Vermarktung von RZDienstleistungen, Kosten- und Leistungsverrechnung, Personalschulung und Managementprozesse wie strategische IT-Planung, Generierung von ControllingInformationen, Bereitstellung von Normen und Standards, Abwicklung von Revisionsaufträgen.

Eine weiter verfeinerte Typologie verwendet zusätzlich die Kategorie Querschnittsprozesse (z. B. Mitarbeiter führen, Arbeitsumfeld gestalten). Geschäftsprozesse müssen in jedem Einzelfall identifiziert und definiert werden. Ihre Granularität bestimmt die Genauigkeit der Auftragsrechnung, so dass vor der Identifikation der Prozesse zu entscheiden ist, für welche Zwecke die Ergebnisse der Prozesskostenrechnung verwendet werden sollen (z. B. zur Preiskalkulation, was eine feinere Granularität erfordert, oder für das Controlling, das mit einer gröberen Granularität auskommt).

Werkzeuge Werkzeuge für die Kosten- und Leistungsrechnung sind im Zusammenhang mit Abrechnungssystemen zu sehen, deren Zweck es ist, Daten über die Inanspruchnahme und zeitliche Belegung von Betriebsmitteln durch Produktionsaufträge automatisch zu erfassen. Die Daten werden für das Controlling des Produktionsbetriebs verwendet (vgl. Lerneinheiten CONTR und INMAN), insbesondere für das Kapazitäts- und Leistungsmanagement, und sind Grundlage für das Ermitteln des Mengengerüsts der Kosten- und Leistungsrechnung (z. B. Erfassung der Art und Anzahl der Transaktionen und ihrer Verursacher). Abrechnungssysteme unterstützen auch das Sicherheitsmanagement (vgl. Lerneinheit SICHM), insbesondere durch Überwachung des Zugriffs auf Betriebsmittel, Daten und Programme (Zugriffsüberwachungssystem). Die von Abrechnungssystemen erfassten Daten erleichtern das Fällen von Investitionsentscheidungen (z. B. in Verbindung mit Hardwareerweiterungen) und sind sowohl für die interne Leistungsverrechnung als auch für die Verrechnung von Leistungen gegenüber externen Auftraggebern (externe Leistungsverrechnung, häufig als Billing bezeichnet) erforderlich.

Kosten- und Leistungsrechnung (KOLER)

469

Abrechnungssysteme verfügen auch über Funktionen zur Bewertung des Mengengerüsts mit Kosten, Verrechnungspreisen oder Marktpreisen. Spezifische Werkzeuge für die Kosten- und Leistungsrechnung mit hoher Funktionalität werden für bestimmte Betriebssystemumgebungen auf dem IT-Markt angeboten (z. B. SAS Financial Intelligence, u. a. mit der Komponente Activity-Based Management für die Prozesskostenrechnung). Sie verfügen über Schnittstellen zu den Abrechnungssystemen und können an die Anforderungen des Anwenders angepasst werden (z. B. bezüglich der Systeme, aus denen Daten importiert bzw. in die Daten exportiert werden, der verwendeten Kostenarten- und Kostenstellengliederung, der Verrechnungsmethoden, der Erstellung von Kosten- und Leistungsberichten sowie der Abrechnungsverfahren, z. B. laufende Abrechnung von Einzelleistungen, Stichtagsabrechnung, teilweises oder vollständiges Kumulieren von Rechnungen).

Forschungsbefunde Nach einer Studie von Trigonum Consulting (schriftliche Befragung von 400 IT-Managern, Untersuchungszeitraum 2007) bezeichnen rd. 40 % der Befragten die Kostentransparenz ihrer IT als unbefriedigend. Als primäre Ursachen werden „zu komplexe Kostenstrukturen“, mangelnde personelle Ressourcen und unzureichende Methoden und Werkzeuge angegeben. Konsequenzen sind, dass Kostentreiber oft nur zufällig identifiziert werden können und in Budgetverhandlungen nicht angemessen argumentiert werden kann. 23 % der Befragten vermuten, dass durch mangelnde Kostentransparenz nur geringe Nachteile entstehen. Brandl/Bichler/Ströbel beschreiben eine Methode zur Kostenschätzung unter Verwendung von Ressourcenprofilen pij, definiert als Vektoren i = 1…m Business Services und j = 1…n Verbrauchswerte („resource consumption values“ für CPU Zeit, Web Server, Application Server, Database Server, übertragene Datenmenge in Bytes, etc.). Die Verbrauchswerte werden zunächst geschätzt und dann mit Hilfe von experimentellen Belastungstests überprüft. Die mit der Anzahl der Service-Anforderungen der Benutzer in einer Abrechnungsperiode multiplizierten Ressourcenprofile ergeben einen kombinierten Kostenverteilungsschlüssel der Infrastrukturkosten. Die Methode wurde auf einer experimentellen Infrastruktur mit verschiedenen Betriebssystemen und Servern im IT-Bereich der BMW Group unter Verwendung realer Business Services evaluiert. Nach einer Studie von Forrester Research (schriftliche Befragung von 270 IT-Managern europäischer Unternehmen im Zeitraum 11-12/2005) wurde für 2006 folgende Verteilung der IT-Kosten budgetiert: IT-Personal 28 %, Hardware 21 %, Software 18 %, IT-Services 19 % und Netzkosten 14 %. Nach der seit 1980 jährlich durchgeführten SIM-Studie (SIM = Society for Information Management, USA) wurde für 2010 folgende Kostenverteilung budgetiert (Online-Befragung von 172 SIM-Mitgliedern in den USA sowie 107 bzw. 70 vergleichbaren Unternehmen in Asien/Australien bzw. Europa im 3. Quartal 2010): Internal Staff – Domestic 43 bzw. 33 bzw. 25 %, Hardware, Software, Network 32 bzw. 40 bzw. 35 %, Consulting Services 10 bzw. 11 bzw. 12 %, Outsources Staff – Domestic 7 bzw. 5 bzw. 20 %, Outsources Staff – Offshore 5 bzw. 4 bzw. 5 % und Internal Staff – Offshore 3 bzw. 6 bzw. 3 %. Verglichen mit früheren Jahren konnten nur geringe Änderungen der Budgetverteilung festgestellt werden. Kostentreiber sind die Personalkosten. Von den für 2011 geplanten Budgets werden rd. 69 % auf Personalkosten entfallen (USA).

470

Methoden des administrativen Informationsmanagements

Aus der Praxis Die Unternehmensberatung Droege & Comp. behauptet (zitiert nach Computerwoche vom 1.12.2005): „Die meisten Unternehmen klagen über zu hohe IT-Kosten. Fachbereiche verstehen Höhe sowie Zusammensetzung der IT-Umlagen nicht und bezweifeln demzufolge die Wettbewerbsfähigkeit des eigenen IT-Bereichs. … Ein konzeptioneller Rahmen für eine saubere Struktur der IT-Kosten, der sich an klaren Produkten orientiert, ist nur selten vorhanden.“ Best Practices aus Industrie- und Dienstleistungsunternehmen, von denen fünf genannt werden, zeigen, wie sich manche IT-Abteilungen transparent aufgestellt haben. Nach einer Befragung von Computer Economics in 94 US-Unternehmen (keine weiteren Angaben zur Untersuchungsmethode) „ ... haben 42 % der Unternehmen gar keine Chargeback-Mechanismen etabliert; der Rest berechnet seine Services selektiv.“ (Zitiert nach Computer Zeitung vom 28.1.2008, 4.) Die Völcker Informatik AG beschreibt die Systematik der Leistungsinformationen ihres Kostenmanagementsystems mit Antworten zu den Fragen: Wer hat geleistet (Leistungsträger)? Wann wurde geleistet (Zeiterfassung der Leistung)? Was wurde geleistet (Leistungs- oder Produktbeschreibung)? Wie viel wurde geleistet (Mengengerüst)? An wen wurde geleistet (Leistungsempfänger)? Welcher Preis wird für die Leistung berechnet (Preisgestaltung)? Aufgabenverweise Controlling (Lerneinheit CONTR); Infrastrukturmanagement (Lerneinheit INMAN); Servicemanagement (Lerneinheit SEMAN); Vertragsmanagement (Lerneinheit VERMA). Kontrollfragen 1. Welchen Zwecken dient die Kosten- und Leistungsrechnung im IT-Bereich? 2. Warum werden Nutzen- oder Knappheitspreise als Verrechnungspreise empfohlen? 3. Warum erfordert die Verwendung von Verrechnungspreisen eine sorgfältige Planung der Leistungen und damit der Inanspruchnahme der Kapazität? 4. Welche weiteren IT-Prozesse sind typische Beispiele für Unterstützungs- und für Managementprozesse? 5. Wie wird bei Verwendung der Prozesskostenrechnung vorgegangen? Quellen Brandl, R. / Bichler, M. / Ströbel, M.: Cost Accounting for Shared IT Infrastructures. In: WIRTSCHAFTSINFORMATIK 2/2007, 83–94 Droege & Comp. Düsseldorf http://www.droege.de; Abruf 25.1.2008 Forrester Research, Inc.: Global IT Budget Composition: 2006; zitiert nach Brandl et al., 83 und 92 Gerlinger, A. et al.: Prozessorientierte IV-Leistungsverrechnung – Der Weg zur totalen Transparenz? In: Krcmar, H. / Buresch, A. / Reb, M. (Hrsg.): IV-Controlling auf dem Prüfstand. Wiesbaden 2000, 105–134 Klook, J.: Verrechnungspreise. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A. 1992, 2554–2572 Luftman, J. / Ben-Zvi, T.: Key Issues for IT Executives 2010: Judicious IT Investments Continue Post-Recession. In: MIS Quarterly Executive 4/2010, 263–273 SIM-Studie 2010, zitiert nach Luftman/Ben-Zvi, 270 Trigonum Studie: http://www.trigonum.de/artikel; Abruf 12.01.2008 Völcker Informatik AG: ActiveEntry, http//www.activeentry.com; Abruf 30.4.2008 Vertiefungsliteratur Funke, H.: Kosten- und Leistungsrechnung in der EDV. Stand und Entwurf einer prozessorientierten DVKostenverrechnung. Kassel University Press, Kassel 1999 Fürer, P. J.: Prozesse und EDV-Kostenverrechnung – Die prozessbasierte Verrechnungskonzeption für Bankrechenzentren. Bern et al. 1994 Radisic, I.: Ein prozessorientierter, policy-basierter Ansatz für ein integriertes, dienstorientiertes Abrechnungsmanagement. Dissertation Universität München 2003

Sicherheitskonzepte (SIKON) Lernziele Sie kennen Prinzipien zur Entwicklung von Sicherheitskonzepten und können den Unterschied zwischen Risikoanalysen und Grundschutzkonzepten erklären. Sie können Sicherheitskonzepte entwerfen und kennen Werkzeuge zur Entwicklung von Sicherheitskonzepten.

Definitionen und Abkürzungen ALE = Annual Loss Exposure bzw. Annual Loss Expectancy; Erwartungswert für den pro Jahr aufgrund von Sicherheitsgefährdungen zu erwartenden Schaden. ENISA = European Network and Information Security Agency; Einrichtung der europäischen Union, die als Anlauf- und Beratungsstelle in Fragen der Netz- und Informationssicherheit für die Mitgliedstaaten und die EU-Organe dient. Grundschutz (baseline protection) = Prinzip zur Entwicklung von Sicherheitskonzepten, bei dem Sicherungsmaßnahmen anzuwenden sind, welche für einen normalen Schutzbedarf als angemessen und ausreichend betrachtet werden. Grundschutzmaßnahmen (baseline controls) = Mindestumfang von Maßnahmen zur Sicherung einer Informationsinfrastruktur mit einem durchschnittlichen Schutzbedarf. ISF = Information Security Forum; Vereinigung von mehr als 250 Unternehmen und Behörden, die den Standard of Good Practice for Information Security heraus gibt. IT-Grundschutzkataloge (baseline catalogues) = Publikation des BSI mit Beschreibungen von Sicherheitsgefährdungen und Empfehlungen zu Maßnahmen, welche ein Mindestmaß an Sicherheit gewährleisten sollen. Malware = Software-Anomalien, z. B. Viren, Würmer, Trojanische Pferde. Penetrationstest (penetration test) = Experimentelle Untersuchung mit dem Ziel, Schwachstellen zu identifizieren und Sicherungsmaßnahmen zu umgehen, um Potenzial für Verbesserung von Sicherheitskonzepten aufzudecken. Restrisiko (residual risk) = Risiko, das nicht durch Sicherungsmaßnahmen neutralisiert oder durch Versicherungen überwälzt werden kann oder soll. Risiko (risk) = Kombination aus zu erwartender Häufigkeit bzw. Eintrittswahrscheinlichkeit eines gefährdenden Ereignisses und dem beim Ereigniseintritt zu erwartenden Schadensausmaß. Risikoanalyse (risk analysis, risk assessment) = Prinzip zur Entwicklung von Sicherheitskonzepten, bei dem Schadenshöhen und Eintrittswahrscheinlichkeiten von Bedrohungen bzw. sicherheitsgefährdenden Ereignissen detailliert ermittelt werden. Schutzbedarf (security requirements) = angestrebtes oder erforderliches Sicherheitsniveau einer Informationsinfrastruktur. Schwachstelle (vulnerability, weakness) = Umstand, der das Eintreten gefährdender Ereignisse begünstigen oder deren negative Folgen verstärken kann. Sicherheitskonzept (security concept, security plan) = Entwurf des Vorgehens zur Erreichung und Erhaltung des gewünschten oder geforderten Sicherheitsniveaus. Sicherheitsniveau (security level) = Ausmaß an geforderter oder vorhandener Sicherheit.

472

Methoden des administrativen Informationsmanagements

Zweck der Sicherheitskonzepte Ein Sicherheitskonzept ist ein Entwurf zur Erreichung und Erhaltung des gewünschten oder geforderten Sicherheitsniveaus. In dem Konzept werden Bedrohungen dargelegt und Maßnahmen zu deren Eindämmung begründet. Ein Sicherheitskonzept ist eine wichtige Komponente eines Sicherheitsmanagement-Systems (vgl. Lerneinheit SICHM). Das Sicherheitskonzept dient der Umsetzung der Sicherheitsstrategie (vgl. Lerneinheit STRAT) und beschreibt Hilfsmittel, mit denen die Sicherheitsziele erreicht werden sollen. Sicherheitskonzepte können entweder für die gesamte Informationsinfrastruktur eines Unternehmens oder für Teile (z. B. für einzelne Informationssysteme) entworfen werden. Jede realisierte Sicherungsmaßnahme soll mit dem Sicherheitskonzept begründet werden können. Es gibt zwei Prinzipien zur Entwicklung von Sicherheitskonzepten: Grundschutz und Risikoanalysen.

Grundschutz Bei der Entwicklung eines Sicherheitskonzepts mit Hilfe des Grundschutzes werden Sicherungsmaßnahmen ausgewählt, welche von vergleichbaren Unternehmen in ähnlichen Situationen angewendet oder von anerkannten Autoritäten als Mindestschutz vorgeschlagen werden. Auf der Grundlage von Plausibilitätsüberlegungen werden die Sicherungsmaßnahmen angewendet, welche für den zu schützenden Bereich angemessen zu sein scheinen. Dies geschieht im Unterschied zur Risikoanalyse, ohne die korrespondierenden Risiken detailliert zu untersuchen. Grundschutzmaßnahmen definieren einen Mindestumfang von Maßnahmen zum Schutz eines Systems oder einer Organisation. Im BSI-Standard 100-2 wird eine Vorgehensweise beschrieben, mit der Sicherheitskonzepte in Form eines Grundschutzes realisiert werden können. Abbildung SIKON-1 gibt die wesentlichen Schritte wieder. Bevor mit der Grundschutzanalyse begonnen wird, ist der Bereich abzugrenzen, für den ein Sicherheitskonzept entwickelt werden soll. Dies kann ein ganzes Unternehmen sein; in vielen Fällen werden Sicherheitskonzepte aber für einzelne Organisationseinheiten, Aufgabenbereiche oder Informationssysteme angefertigt. Nachdem der relevante Analysebereich abgegrenzt ist, empfiehlt das BSI, für diesen Bereich eine IT-Strukturanalyse durchzuführen. Dabei werden die Elemente der Informationsinfrastruktur mit ihren Interdependenzen möglichst umfassend dokumentiert. Besonders zu beachten sind dabei betriebliche Aufgaben, die sie unterstützenden Anwendungssysteme sowie organisatorische und personelle Rahmenbedingungen. Auf dieser Grundlage erfolgt im nächsten Schritt eine Schutzbedarfsfeststellung. Deren Zweck ist es abzuschätzen, welche Schäden sich durch eine Beeinträchtigung der Integrität, Verfügbarkeit oder Vertraulichkeit von Elementen der Informationsinfrastruktur für das Unternehmen ergeben können. Die Schutzbedarfsfeststellung ähnelt einer Risikoanalyse, erfolgt aber pauschal und ohne die im jeweiligen Fall konkret vorliegenden Gefährdungen, Eintrittswahrscheinlichkeiten und Schadenspotenziale zu ermitteln. Für die Auswahl von Sicherungsmaßnahmen empfiehlt das BSI ein zweistufiges Vorgehen. Zunächst erfolgt die Modellierung nach IT-Grundschutz. Dabei wird der zu analysierende Bereich anhand der IT-Grundschutzkataloge des BSI (diese entsprechen dem frü-

Sicherheitskonzepte (SIKON)

473

heren IT-Grundschutzhandbuch) abgebildet. In den Katalogen werden typische Gefährdungen, Sicherungsmaßnahmen und Informationssysteme zu Bausteinen zusammengefasst. Diese sind folgendermaßen gegliedert: Übergeordnete Aspekte der IT-Sicherheit, Sicherheit der Infrastruktur und der IT-Systeme, Sicherheit im Netz und in Anwendungen. Die Grundschutzkataloge enthalten detaillierte Beschreibungen von Sicherheitsgefährdungen für einzelne Informationssysteme bzw. deren Komponenten. Die Gefährdungen sind in höhere Gewalt, organisatorische Mängel, menschliche Fehlhandlungen, technisches Versagen und vorsätzliche Handlungen gegliedert. Die Sicherungsmaßnahmen sind in sechs Maßnahmenkataloge gruppiert: Infrastruktur, Organisation, Personal, Hard- und Software, Kommunikation sowie Notfallvorsorge. Die in den IT-Grundschutzkatalogen empfohlenen Maßnahmen sollen ein Mindestmaß an Sicherheit gewährleisten. Abgrenzung des Analysebereichs IT-Strukturanalyse

Feststellung des Schutzbedarfs Auswahl von Sicherungsmaßnahmen: Modellierung nach IT-Grundschutz und Basis-Sicherheitscheck

ergänzende Sicherheitsanalyse bei hohem Schutzbedarf

Konsolidierung der Maßnahmen Realisierung der Maßnahmen Abb. SIKON-1: Grundschutzvorgehensweise

Beim Basis-Sicherheitscheck werden zunächst alle bereits realisierten Sicherungsmaßnahmen identifiziert. Durch Vergleich mit den in den Grundschutzkatalogen empfohlenen Maßnahmen werden Verbesserungsmöglichkeiten ermittelt. Wenn die empfohlenen Sicherungsmaßnahmen realisiert sind – so der Kerngedanke des Grundschutzes – ist ein angemessenes und ausreichendes Sicherheitsniveau für den durchschnittlichen Schutzbedarf erreicht. Für Bereiche oder Systeme mit höherem Schutzbedarf müssen mit Hilfe einer ergänzenden Sicherheitsanalyse zusätzliche Sicherungsmaßnahmen identifiziert werden. Eine solche Analyse kann z. B. in Form einer Risikoanalyse durchgeführt werden, welche sich aus-

474

Methoden des administrativen Informationsmanagements

schließlich auf den Bereich mit erhöhtem Schutzbedarf bezieht. Im BSI-Standard 100-3 werden Empfehlungen für eine Risikoanalyse auf der Basis von IT-Grundschutz beschrieben. Im Rahmen einer Konsolidierung werden die noch zu realisierenden Sicherungsmaßnahmen daraufhin überprüft, ob sie tatsächlich geeignet sind, das gewünschte Sicherheitsniveau zu erreichen, ob sie mit den Richtlinien des Unternehmens kompatibel sind und mit dem zur Verfügung stehenden Sicherheitsbudget realisiert werden können. Im Anschluss daran werden die ausgewählten Maßnahmen priorisiert, an die organisatorischen und technischen Rahmenbedingungen angepasst und dann realisiert. Das Sicherheitskonzept sollte in regelmäßigen Abständen überprüft werden, insbesondere dann, wenn die IT-Infrastruktur verändert wurde oder sich andere Rahmenbedingungen verändert haben, die für die Sicherheit relevant sind. Organisationen, die sich bei der Entwicklung des Sicherheitskonzepts an den Vorgaben des BSI orientiert haben, können mit Hilfe einer IT-Grundschutzzertifizierung (vgl. Lerneinheit SICHM) dokumentieren, dass sie die vom BSI empfohlenen Maßnahmen in der erforderlichen Tiefe implementiert haben.

Risikoanalysen In ISO/IEC 27000 werden Risikoanalysen als systematischer Prozess zur Identifikation und Einschätzung des Umfangs von Risiken definiert. Im Rahmen einer Risikoanalyse werden Ursachen und Konsequenzen von gefährdenden Ereignissen (vgl. Lerneinheit SICHM) untersucht und bewertet. Ein Risiko ist sowohl etwas Negatives, Bedrohliches bzw. Gefährliches als auch Zukünftiges und daher Ungewisses. Es gibt unterschiedliche Definitionen dieses Begriffes. Einigkeit herrscht aber darüber, dass Risiken die beiden folgenden Elemente enthalten:  

die zu erwartende Häufigkeit bzw. Eintrittswahrscheinlichkeit eines gefährdenden Ereignisses und das beim Ereigniseintritt zu erwartende Schadensausmaß.

Abbildung SIKON-2 gibt einen Überblick über die Grundstruktur einer Risikoanalyse. Wie bei der Grundschutzvorgehensweise müssen auch im Rahmen einer Risikoanalyse zunächst die Bereiche ausgewählt und abgegrenzt werden, die näher untersucht werden sollen. Dies ist notwendig, da in der Regel aus Zeit- und Kostengründen nicht alle Risiken einer Informationsinfrastruktur untersucht werden können. Man konzentriert sich bei einer Risikoanalyse auf solche Bereiche, welche für die Leistungsfähigkeit des Unternehmens besonders wichtig sind bzw. aus denen sich besonders hohe Schäden ergeben könnten. Wenn Informationssysteme oder Anwendungen zu neu sind oder außergewöhnliche Rahmenbedingungen herrschen, können mit Hilfe des Grundschutzprinzips oft keine angemessenen Sicherungsmaßnahmen ausgewählt werden. Auch in solchen Fällen bietet sich eine Risikoanalyse an. Bei der Auswahl und Abgrenzung des Analysebereichs werden Führungskräfte einbezogen, welche Verantwortung für die betreffenden Unternehmensbereiche oder Informationssysteme tragen. Um eine angemessene Informationsgrundlage für die Risikoanalyse zu schaffen,

Sicherheitskonzepte (SIKON)

475

werden die zu untersuchenden Bereiche möglichst detailliert beschrieben. Dabei geht es um das organisatorische und technische Umfeld, wesentliche Bestandteile und ihre Beziehungen sowie die Bedeutung des zu analysierenden Bereichs für die Leistungsfähigkeit des Unternehmens. Auswahl und Abgrenzung des Analysebereichs

Aufbereitung und Darstellung der Ergebnisse

Risikoerkennung bzw. -identifikation

Auswahl und Bewertung von Sicherungsmaßnahmen

Risikobewertung

Restrisikoanalyse

Abb. SIKON-2: Grundstruktur einer Risikoanalyse

Ziel des zweiten Schrittes der Risikoanalyse ist, wesentliche Risiken zu identifizieren und zu beschreiben. Zu diesem Zweck werden relevante Gefahren ermittelt und sicherheitsrelevanten Objekten zugeordnet, um im nächsten Schritt potenzielle Konsequenzen bzw. Schäden gefährdender Ereignisse einschätzen zu können. Es gibt zwei verschiedene Techniken zur Unterstützung der Risikoerkennung: die Szenario- und die Simulationstechnik. Ein Szenario ist eine hypothetische Aufeinanderfolge von Ereignissen zur Analyse kausaler Zusammenhänge. Werden Risiken mit Hilfe der Szenariotechnik (vgl. Lerneinheit SZENA) untersucht, so ist dies in der Regel keine umfassende und vollständige Analyse aller Risiken, sondern die Erörterung einiger weniger Fallbeispiele. Der Kern einer Szenarioanalyse ist die Konstruktion möglicher zukünftiger Situationen (Szenarien), wobei Ursache/WirkungBeziehungen von den denkbaren Gefahrenquellen bis zu den Auswirkungen für das Unternehmen von verschiedenen Mitarbeitern besprochen werden. Dies kann z. B. in Form eines Workshops geschehen, dessen Ergebnisse als Kurzgeschichten oder Grafiken dokumentiert werden. Diese Analysen können mit verschiedenen Mitarbeitern für mehrere Bereiche wiederholt werden. Die Befürworter von Szenarioanalysen versprechen sich davon, dass viele der gefundenen Maßnahmen per Analogieschluss auch auf andere, bisher nicht analysierte Bereiche übertragen werden können. Die Stärken und Schwächen der Szenariotechnik lassen sich wie folgt zusammenfassen. Szenarioanalysen sind in hervorragender Weise geeignet, das Wissen der Mitarbeiter über Schwachstellen und Sicherungsmöglichkeiten in ein Sicherheitskonzept einfließen zu lassen. Sie haben den Vorteil, dass sie sowohl das Verständnis der relevanten Zusammenhänge als auch das Sicherheitsbewusstsein der Mitwirkenden verbessern. Dies liegt daran, dass in den Szenarien realistische Fälle beschrieben werden. Die Analysen haben in der Regel eine hohe Überzeugungskraft. Sie erleichtern es, Entscheidungsträger und Mitarbeiter von der Notwendigkeit der Sicherungsmaßnahmen zu überzeugen. Szenarioanalysen können relativ kostengünstig durchgeführt werden. Aufgrund des exemplari-

476

Methoden des administrativen Informationsmanagements

schen Charakters der Szenarien ist es allerdings möglich, dass in den nicht behandelten Bereichen gravierende Risiken unentdeckt bleiben. Mit Hilfe der Simulationstechnik wird versucht, möglichst viele gefährdende Ereignisse sowie potenzielle Konsequenzen in einem Modell abzubilden. Da bereits die Abbildung des Analysebereichs sehr arbeitsintensiv ist, wird dies häufig durch ein Softwarewerkzeug unterstützt. Ist ein solches Modell erstellt worden, können darauf aufbauend gefährdende Ereignisse von den Gefahrenquellen bis zu den Auswirkungen simuliert werden. Das Ergebnis sind inhaltlich beschriebene Ursache/Wirkung-Zusammenhänge. Der Unterschied zur Szenariotechnik besteht darin, dass die Simulationstechnik für eine umfassende Analyse ausgelegt ist, wogegen die Szenariotechnik einzelne Fallbeispiele zum Inhalt hat. Ein Vorteil der Simulationstechnik ist, dass die Modelle des Analysebereichs wiederverwendet werden können. Dies verringert den Aufwand bei der Wiederholung von Analysen. Da die Simulationstechnik eine möglichst umfassende Nachbildung von Risiken anstrebt, liefert sie eine umfangreiche Grundlage für die nachfolgende Risikobewertung. Diese Vorteile müssen allerdings mit einem erheblichen Arbeitsaufwand erkauft werden. Vor allem die für die Simulation notwendige detaillierte Abbildung des Analysebereichs ist zeit- und kostenintensiv. Da entsprechende Methoden nicht einfach zu handhaben sind, müssen sich die Mitarbeiter zunächst sorgfältig mit der Vorgehensweise vertraut machen. Auch die Auswertung aller denkbaren Folgen gefährdender Ereignisse ist sehr arbeitsintensiv, selbst wenn Softwarewerkzeuge sinnvolle Unterstützung leisten. Das Simulationskonzept ist allerdings hervorragend für detaillierte Analysen geeignet, die häufig wiederholt werden sollen. Es eignet sich auch für Sicherheitsbeauftragte, die sich in ihren Arbeitsbereich einarbeiten wollen. Sind die Risiken identifiziert und inhaltlich beschrieben worden, muss festgestellt werden, welche Bedeutung sie für das Unternehmen haben, oder anders formuliert, die Risiken müssen bewertet werden. Dazu sind Eintrittswahrscheinlichkeiten bzw. -häufigkeiten zu ermitteln und Schadenspotenziale zu bewerten. Zum Abschluss der Risikobewertung werden Risikokenngrößen ermittelt, indem Eintrittswahrscheinlichkeiten und Schadenspotenziale miteinander verknüpft werden. Dafür kommen zwei verschiedene Techniken in Frage, die kardinale und die ordinale Risikobewertung. Bei der kardinalen Risikobewertung werden Eintrittswahrscheinlichkeiten und Schadenspotenziale gefährdender Ereignisse in kardinalen Werten ausgedrückt (vgl. zu den Skalenniveaus Lerneinheit NUTZW). Schadenspotenziale werden in der Regel in Währungseinheiten und Eintrittshäufigkeiten in Ereignissen pro Jahr formuliert. Für jedes gefährdende Ereignis werden Schaden und Häufigkeit miteinander multipliziert. Das Ergebnis ist ein statistischer Erwartungswert, der in anglo-amerikanischen Methoden mit dem Begriff Annual Loss Expectancy (ALE) bezeichnet wird. Ein stark vereinfachtes Beispiel soll dies verdeutlichen. Das Risiko, dass ein Rechenzentrum durch ein Erdbeben zerstört wird, soll bewertet werden. Der Schaden wird auf 10 Mio. EUR geschätzt und die Wahrscheinlichkeit, dass ein solches Ereignis eintritt, auf durchschnittlich einmal in 10.000 Jahren. Daraus lässt sich ein Risiko von 1.000 EUR / Jahr errechnen (= Schaden [EUR] x Eintrittswahrscheinlichkeit / Jahr). Dieser einfache Grundgedanke kann mit Konfidenzfaktoren, Spannbreiten oder statistischen Verfahren verfeinert werden.

Sicherheitskonzepte (SIKON)

477

Die Stärken der kardinalen Risikobewertung lassen sich wie folgt zusammenfassen. Risiken werden prägnant beschrieben und sind der Höhe nach leicht miteinander vergleichbar. Kardinale Risikobewertungen sind hilfreich, wenn Investitionen in Sicherungsmaßnahmen quantitativ begründet werden müssen. Sie eignen sich deshalb besonders gut als Teil einer monetären Kosten/Nutzen-Analyse für Sicherungsmaßnahmen. In der Praxis bereitet das Konzept aber erhebliche Probleme. Eine kardinale Risikobewertung erzwingt kardinale Formulierungen von Risiken auch dann, wenn keine verlässlichen Angaben oder Schätzungen vorliegen. Für einige Risiken lassen sich Werte ableiten, z. B. aus öffentlich zugänglichen Statistiken über Naturkatastrophen oder Erfahrungswerten des Unternehmens über den Ausfall bestimmter Komponenten der Informationsinfrastruktur. Für andere Risiken sind Schätzungen aber nur sehr schwierig oder aus prinzipiellen Gründen unmöglich. Wie hoch ist z. B. die Wahrscheinlichkeit, dass ein bestimmter Mitarbeiter die ihm erteilten Rechte in unzulässiger Weise missbraucht? Welcher Schaden entsteht, wenn ein Mitarbeiter Inhalte einer Datei zur Kenntnis nimmt, für die er kein Leserecht hat? Häufig müssen Schadenswerte und Eintrittswahrscheinlichkeiten geschätzt oder ohne verlässliche Grundlage ermittelt werden. Die Analysen täuschen dann eine Exaktheit vor, die bei genauer Betrachtung nicht gegeben ist. Aus diesem Grund hat die kardinale Bewertung oft nur eine geringe Überzeugungskraft. Im Unterschied zur kardinalen Risikobewertung werden Eintrittswahrscheinlichkeiten und Schadenspotenziale gefährdender Ereignisse im Rahmen der ordinalen Risikobewertung unschärfer beschrieben. Dies entspricht in der Regel eher der Qualität der vorliegenden Daten. Im IT-Sicherheitshandbuch des BSI wird empfohlen, mit Hilfe der ordinal klassifizierten Schäden und Eintrittswahrscheinlichkeiten tragbare und untragbare Risiken zu unterscheiden. Tragbare Risiken werden akzeptiert, untragbare mit Hilfe von Sicherungsmaßnahmen reduziert oder durch Versicherungen überwälzt. Während die Klassifikation von Risiken mit sehr hohen oder sehr niedrigen Schadenspotenzialen und Eintrittswahrscheinlichkeiten in der Regel kein Problem darstellt, ist eine angemessene Klassifikation der mittleren Risiken schwierig. Für die ordinale Risikobewertung spricht, dass die Verantwortlichen nicht gezwungen werden, Schäden und Eintrittswahrscheinlichkeiten in kardinalen Werten auszudrücken und dass Risiken pragmatisch in tragbare und untragbare unterteilt werden können. Gegen die ordinale Risikobewertung spricht, dass sie keine Grundlage für eine monetäre Kosten/Nutzen-Analyse von Sicherungsmaßnahmen bietet. Die Ergebnisse der Risikoanalyse müssen so aufbereitet werden, dass die Entscheidungsträger diese leicht verstehen können. Das bedeutet, dass die Ergebnisse nicht in ITFachbegriffen dargestellt werden dürfen, sondern in Konzepten und Begriffen, die den Entscheidungsträgern geläufig sind. Viele Risikoanalysemethoden weisen besonders in diesem Punkt gravierende Schwächen auf. Anschließend werden Sicherungsmaßnahmen ausgewählt, mit denen die identifizierten Risiken bekämpft werden können. Folgende Maßnahmenkategorien lassen sich unterscheiden:  

Vermeidung eines realen Schadens: Durch geeignete Sicherungsmaßnahmen werden gefährdende Ereignisse vermieden (z. B. durch Gebäudeschutz und Zu- und Abgangskontrollen gegen Intrusionsversuche). Verminderung des realen Schadens: Ein bereits eingetretenes gefährdendes Ereignis soll rechtzeitig entdeckt werden, um die Ausbreitung bzw. Vergrößerung des Schadens zu

478



 

Methoden des administrativen Informationsmanagements

verhindern (z. B. durch Brandmelde- und Löschsysteme gegen Brandfolgen oder durch Einbruch-Meldesysteme gegen erfolgte Intrusionen). Begrenzung des Risikos (für das Entstehen eines wirtschaftlichen Schadens): Ein realer Schaden kann zu einem wirtschaftlichen Schaden führen, der meist weitaus bedeutender ist als das ursprüngliche Ereignis. Durch geeignete Sicherungsmaßnahmen wird das Entstehen eines wirtschaftlichen Schadens verhindert oder zumindest begrenzt (z. B. durch Sicherung wichtiger Datenbestände in geografisch entfernten Rechenzentren, vgl. Lerneinheit NOMAN). Begrenzung des wirtschaftlichen Schadens: Die Kosten oder Erlösausfälle, die durch einen wirtschaftlichen Schaden verursacht werden können, sollen vermieden oder so klein wie möglich gehalten werden (z. B. durch Versicherungen gegen Erlösausfälle). Finanzielle Vorsorge für den Schadensfall: Für den Schadensfall werden finanzielle Mittel bereitgehalten, oder es wird deren Verfügbarkeit durch Abschluss von Versicherungen gesichert.

Im Rahmen der Restrisikoanalyse ist zu überprüfen, wie mit den Risiken umgegangen werden soll, die trotz Realisierung von Sicherungsmaßnahmen nicht vollständig vermieden werden können. Restrisiken können akzeptiert oder müssen auf andere überwälzt werden. Hierzu bieten sich Computerversicherungen an.

Werkzeuge für Sicherheitskonzepte Die Entwicklung von Sicherheitskonzepten kann mit verschiedenen Softwarewerkzeugen unterstützt werden. Zwei dieser Werkzeuge werden im Folgenden beispielhaft kurz vorgestellt. Das Grundschutz-Tool des BSI (GSTOOL) unterstützt die Erstellung, Verwaltung und Fortschreibung von Sicherheitskonzepten entsprechend dem Grundschutz. Im Rahmen der IT-Strukturanalyse können Elemente der Informationsinfrastruktur mit ihren Interdependenzen beschrieben und in einer Datenbank gespeichert werden. Dies erspart die vollständige Neueingabe bei einer Überarbeitung des Sicherheitskonzepts. Für die folgenden Schritte der Grundschutzvorgehensweise sind in dem Werkzeug alle vom BSI erfassten Sicherheitsgefährdungen und Sicherungsmaßnahmen strukturiert hinterlegt. Das bewahrt die Anwender davor, die umfangreichen IT-Grundschutzkataloge vollständig durcharbeiten zu müssen. Das Werkzeug unterstützt insbesondere die Auswahl von Sicherungsmaßnahmen. Das GSTOOL ermöglicht außerdem eine Kostenauswertung der vorgeschlagenen Sicherungsmaßnahmen sowie die Erstellung und Ausgabe verschiedener Berichte. Zu bemängeln ist, dass das GSTOOL es nicht erlaubt, bereits dokumentierte Elemente der Informationsinfrastruktur aus anderen Werkzeugen zu übernehmen. Deutsche Behörden erhalten gebührenfreie Lizenzen, für Unternehmen betragen die Preise zwischen ca. 900 EUR für eine und bis zu ca. 24.000 EUR für 40 Lizenzen. Das Risikoanalysewerkzeug CRAMM wurde Mitte der 1980er Jahre im Auftrag der britischen Regierung entwickelt und wird heute von einem englischen Tochterunternehmen der Siemens AG gepflegt. CRAMM unterstützt die Identifikation und Bewertung sicherheitsrelevanter Elemente der Informationsinfrastruktur, die Analyse von Schwachstellen, Gefahren und Risiken sowie die Auswahl von Sicherungsmaßnahmen. Mit Hilfe von CRAMM

Sicherheitskonzepte (SIKON)

479

können Sicherheitskonzepte in zwei verschiedenen Detaillierungsgraden entwickelt werden. Das Modul CRAMM Express unterstützt eine Vorgehensweise, welche dem Grundschutz des BSI ähnelt. CRAMM Expert ermöglicht detaillierte Risikoanalysen, in deren Rahmen einzelne Risiken mit ordinalen Skalen bewertet werden können. CRAMM verfügt über eine Datenbank mit mehr als 3000 Sicherungsmaßnahmen, die in Abhängigkeit von den vorhergehenden Analysen von Gefährdungen bzw. Risiken ausgewählt und für ein Sicherheitskonzept vorgeschlagen werden. Darüber hinaus unterstützt CRAMM die Planung, Steuerung und Kontrolle der Implementierung der Sicherheitskonzepte. Lizenzpreise sind auf Anfrage erhältlich. Die Website des BSI gibt Hinweise auf weitere Grundschutz-, die der ENISA auf weitere Risikoanalysewerkzeuge.

Grundschutz oder Risikoanalysen? Mit Hilfe des Grundschutzes können Sicherungsmaßnahmen für Bereiche mit normalem Schutzbedarf ermittelt werden. Risikoanalysen führen zu maßgeschneiderten Sicherungslösungen für Bereiche mit hohem Schutzbedarf. Sie sind aber deutlich aufwendiger durchzuführen als der Grundschutz. Risikoanalysen sollten nur dann verwendet werden, wenn mindestens eines der folgenden Kriterien erfüllt ist:    

Der Analysebereich ist komplex und mögliche Konsequenzen gefährdender Ereignisse sind nur schwer überschaubar. Im Analysebereich gibt es neuartige und in ihrer Sicherheitsrelevanz noch unbekannte Anwendungen oder Systeme. Es herrschen außergewöhnliche Rahmenbedingungen, die nicht vom Grundschutz abgedeckt werden. Die mit dem Betrieb von Informationssystemen verbundenen potenziellen Schäden sind sehr hoch.

Pragmatisch gesehen, sollten Risikoanalysen nur durchgeführt werden, wenn …    

es sachkundigen Experten nicht ohne weitere Analysen möglich ist, angemessene Sicherungsmaßnahmen vorzuschlagen, Kunden oder anderen Interessengruppen ein angemessenes Sicherheitsniveau nachgewiesen werden soll, für den zu analysierenden Bereich „maßgeschneiderte Sicherungslösungen“ notwendig sind und ausreichende Mittel zur Durchführung einer Risikoanalyse zur Verfügung stehen.

Eine Kombination beider Prinzipien ist sinnvoll. Viele Unternehmen schreiben bestimmte Sicherungsmaßnahmen vor, um einen einheitlichen Grundschutz zu erreichen und führen zusätzlich Risikoanalysen in besonders sensiblen Bereichen durch. Kurz gefasst: Grundschutz wenn möglich, Risikoanalysen wenn nötig.

480

Methoden des administrativen Informationsmanagements

Forschungsbefunde Die /Microsoft-Sicherheitsstudie 2010 gibt einen Lagebericht zur Informationssicherheit (schriftliche Befragung von 135 für IT-Sicherheit verantwortliche Mitarbeitern von Unternehmen und Behörden in Deutschland, Österreich und der Schweiz, Rücklaufquote nicht angegeben; Untersuchungszeitraum Dezember 2009 bis Mai 2010) mit folgenden Erkenntnissen: Die fünf größten Gefahrenbereiche sind (Angaben in Klammern = Anteil der Teilnehmer, die im letzten Jahr mittlere bis größere Beeinträchtigungen wahrgenommen haben): Irrtum und Nachlässigkeit eigener Mitarbeiter (36 %), Softwaremängel/-defekte (32 %), Hardwaremängel/-defekte (30 %), Malware (27 %), Mängel der Dokumentation (20 %). Die größten Hindernisse für mehr Sicherheit sind (Angaben in Klammern = Anteil der Teilnehmer, Mehrfachnennungen möglich): fehlendes Bewusstsein bei den Mitarbeitern (59 %), fehlendes Geld/Budget (57 %), fehlendes Bewusstsein beim mittleren Management (54 %) und fehlendes Bewusstsein und Unterstützung im Top-Management (47 %). Die Sicherheit von IKT wurde mit Schulnoten von 1 (sehr gut) bis 5 (nicht ausreichend) wie folgt bewertet (Angaben in Klammern = Mittelwerte); Rechenzentren/Mainframes (2,07), Server (2,29), kabelgebundene Netzwerke (2,39), drahtlose Netzwerke (2,68), Geschäftsanwendungen (2,7), Clients/PCs (2,75), mobile Speichermedien wie CDs oder USB-Sticks (3,34) und mobile Endgeräte wie Notebooks oder Smartphones (3,38). Schriftlich dokumentierte Strategien, Konzepte und Richtlinien gibt es in den teilnehmenden Organisationen zur Informationsverarbeitung (62 % der Organisationen), zur IT-Sicherheit (73 %), zur E-Mail-Nutzung (87 %), zur Gestaltung und Nutzung von Passwörtern (82 %), zum Software-Einsatz auf PCs (80 %), zur dienstlichen Nutzung privater IT-Systeme (74 %) und zur Weitergabe von Daten an berechtigte Dritte (73 %). Dagegen gibt es in lediglich 24 % der Organisationen Richtlinien zur Nutzung von Web 2.0 und Sozialen Netzwerken. Die Eignung der Richtlinien wird in 8 % der Organisationen nie geprüft, in 50 % anlassbezogen und in 41 % regelmäßig. Der durchschnittliche Anteil des Sicherheitsbudgets an den IT-Ausgaben beträgt bei den kleinen und mittleren Unternehmen 13 % und bei den großen Unternehmen 5 %. Fischer berichtet über Ergebnisse einer Studie zur WLAN-Sicherheit in Deutschland (schriftliche Befragung von Sicherheitsverantwortlichen in 210 Unternehmen und Behörden, Rücklaufquote 69 %, Untersuchungszeitraum April bis Juni 2009). Die Kenntnisse über Sicherungsmaßnahmen sind in großen Unternehmen und Behörden ähnlich stark ausgeprägt wie in kleinen. Für die Sicherung von WLAN-Infrastrukturen werden organisatorische Sicherungsmaßnahmen stärker genutzt als technische. Wesentliche Gründe dafür, dass verfügbare Sicherungsmaßnahmen nicht eingesetzt werden, sind Unkenntnis, hoher Implementierungs- bzw. Betriebsaufwand und eine zu geringe Wirkung. Unternehmen und Behörden, die IT-Sicherheitsmanagement implementiert haben, setzen mehr WLAN-Sicherungsmaßnahmen ein als Institutionen, bei denen dies nicht der Fall ist.

Sicherheitskonzepte (SIKON)

481

Böhme untersucht an einem spieltheoretischen Modell den Nutzen von IT-Security-Audits bei interdependenten Risiken, also in Situationen, in denen die Sicherheit auch von Investitionen anderer Unternehmen abhängt, z. B. beim Outsourcing oder im Supply-Chain-Management. Als Security-Audits bezeichnet er Sicherheitsprüfungen, die eine Zertifizierung beinhalten, um Dritten Vertrauen in das Sicherheitsniveau des geprüften Objekts zu vermitteln. Böhme kommt zu folgenden Ergebnissen: Prüfung und Zertifizierung von Sicherheit auf niedrigem Niveau ist für Kooperationspartner in den meisten Fällen wirkungslos. Stattdessen sei Wert auf die „zweifelsfreie Feststellung von hohen und höchsten Sicherheitsniveaus“ (392) zu legen. Audits, welche die spezifischen Rahmenbedingungen nicht berücksichtigen, sind nutzlos. Sinnvoll sind IT-Security-Audits, die in enger Absprache mit den Kooperationspartnern durchgeführt werden und auf die unternehmens- und umfeldspezifischen Faktoren abgestimmt sind.

Aus der Praxis Braun/Silbernagel berichten über Penetrationstests als Instrument der IT-Revision der Deutsche Lufthansa AG. Diese Tests werden regelmäßig mit eigenem Personal und externer Unterstützung durchgeführt, um potenzielle technische Sicherheitslücken zu identifizieren, die damit verbundenen Risiken zu bewerten und evtl. notwendige Sicherungsmaßnahmen abzuleiten. Vor Durchführung der Tests werden die betroffenen Fach- und Führungskräfte und die Mitbestimmungsgremien informiert. Die Tests dauern bis zu vier Wochen, in denen die Systemverantwortlichen täglich über die Testergebnisse des Vortages und die Testaktivitäten des laufenden Tages informiert werden. Penetrationstests bilden eine sinnvolle Ergänzung zu klassischen Prüfungen der IT-Sicherheit. Laut Braun/Silbernagel hat die Durchführung „von regelmäßigen Penetrationstests das Sicherheitsniveau der IT-Landschaft verbessert“ (694). Das ISF gibt den Standard of Good Practice for Information Security heraus. Auf der Grundlage des Standards können die Mitgliedsorganisationen im Rahmen des Information Security Status Surveys durch eine Selbstevaluation überprüfen, inwieweit sie die Vorgaben des Standards erfüllen. Aufgabenverweise Qualitätsmanagement (Lerneinheit QUALM); Revision (Lerneinheit REVIS); Sicherheitsmanagement (Lerneinheit SICHM); Notfallmanagement (Lerneinheit NOMAN). Kontrollfragen 1. Welchen Stellenwert haben Sicherheitskonzepte im Rahmen von Sicherheitsmanagement-Systemen? 2. Wie würden Sie vorgehen, um ein Sicherheitskonzept für den Forschungs- und Entwicklungsbereich eines Unternehmens zu entwickeln? 3. Welche Teilaufgaben verursachen den größten Aufwand bei der Durchführung von Risikoanalysen? 4. Welche Probleme ergeben sich bei der Bewertung eines Risikos mit dem ALE? 5. Wie lässt sich die Wirtschaftlichkeit von Sicherungsmaßnahmen bewerten? Quellen Boehme, R.: Wann sind IT-Security-Audits nützlich? In: Bernstein, A. / Schwabe, G. (Hrsg.): Proceedings of the 10th International Conference on Wirtschaftsinformatik WI 2.011. Volume 1. Zürich 2011, 385–394 Braun, H. / Silbernagel, D.: Penetrationstests als Instrument der IT-Revision. In: Datenschutz und Datensicherheit 11/2009, 693–694 Bundesamt für Sicherheit in der Informationstechnik (BSI): GSTOOL – Handbuch. Version 4.5. Bonn 2008. https://www.bsi.bund.de; Abruf 11. Mai 2011

482

Methoden des administrativen Informationsmanagements

Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Sicherheitshandbuch: Handbuch für die sichere Anwendung der Informationstechnik. 4. Entwurf v. 26. Juli 1991, Bonn 1991 Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz-Kataloge 2009. https://www.bsi.bund.de; Abruf 11. Mai 2011 Fischer, D.: WLAN-Sicherheit in deutschen Unternehmen und Behörden. In: KES - Die Zeitschrift für Informations-Sicherheit 1/2010, 66–72 Information Security Forum: Standard of Good Practice for Information Security. 2007. http://www.isfsecuritystandard.com; Abruf 31. März 2011 o. V.: Lagebericht zur Informationssicherheit (1). /Microsoft-Sicherheitsstudie 2010. In: Die Zeitschrift für Informationssicherheit 4/2010, 26–34 o. V.: Lagebericht zur Informationssicherheit (2). /Microsoft-Sicherheitsstudie 2010. In: Die Zeitschrift für Informationssicherheit 5/2010, 12–20 o. V.: Lagebericht zur Informationssicherheit (3). /Microsoft-Sicherheitsstudie 2010. In: Die Zeitschrift für Informationssicherheit 6/2010, 14–21 Siemens UK: CRAMM. http://www.cramm.com; Abruf 31. März 2011 Vertiefungsliteratur Lippold, H. et al.: Sicherheitskonzepte und ihre Verknüpfung mit Sicherheitsstrategie und Sicherheitsmanagement. In: WIRTSCHAFTSINFORMATIK 4/1992, 367–377 Peltier, T. R.: Information Security Risk Analysis. 2. A. Boca Raton 2005 Pfleeger, C. P. / Pfleeger, S. L.: Security in Computing. 4. A., Upper Saddle River 2006, 508–570 Stelzer, D.: Sicherheitsstrategien in der Informationsverarbeitung - Ein wissensbasiertes, objektorientiertes System für die Risikoanalyse. Wiesbaden 1993 Stelzer, D.: Risikoanalysen als Hilfsmittel zur Entwicklung von Sicherheitskonzepten in der Informationsverarbeitung. In: Roßbach, P. / Locarek-Junge, H. (Hrsg.): IT-Sicherheitsmanagement in Banken. Frankfurt a. M. 2002, 37–54 Informationsmaterial Bundesamt für Sicherheit in der Informationstechnik (BSI) http://www.bsi.de CRAMM (CCTA Risk Analysis and Management Method) http://www.cramm.com European Network and Information Security Agency (ENISA) http://enisa.europa.eu Information Security Forum http://www.securityforum.org ISO 27000 Directory http://www.27000.org IT-Security Portal http://www.securitymanager.de Suchmaschinen zur Informationssicherheit http://www.searchsecurity.de und http://searchsecurity.techtarget.com Normen BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS) Version 1.5. 2008 BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise Version 2.0. 2008 BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz Version 2.5. 2008 ISO/IEC 27000:2009: Information technology – Security techniques – Information security management systems – Overview and vocabulary ISO/IEC 27001:2005: Information technology – Security techniques – Information security management systems – Requirements ISO/IEC 27002:2005: Information technology – Security techniques – Code of practice for information security management ISO/IEC 27003:2010: Information technology – Security techniques – Information security management system implementation guidance ISO/IEC 27004:2009: Information technology – Security techniques – Information security management – Measurement ISO/IEC 27005:2008: Information technology – Security techniques – Information security risk management ISO 31000:2009: Risk management – Principles and guidelines ISO/IEC 31010:2009: Risk management – Risk assessment techniques NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems. Washington 2010

Methoden des Qualitätsmanagements (MEQUA) Lernziele Sie kennen Methoden des Qualitätsmanagements (abgekürzt QM). Sie können beschreiben, in welchen Schritten Produkte mit Hilfe von QFD kundenorientiert geplant werden. Sie wissen, welche Elemente der Informationsinfrastruktur mit Hilfe welcher Methoden geprüft werden können. Sie kennen Zweck und Inhalte von Reifegrad- und Exzellenzmodellen.

Definitionen und Abkürzungen Audit (audit) = von unabhängigen Personen durchgeführte Überprüfung, ob QM-Systeme, Prozesse oder Organisationen bestimmte Kriterien erfüllen. CMM = Capability Maturity Model; vom SEI herausgegebenes, mittlerweile durch das CMMI abgelöstes Reifegradmodell für Entwicklungsprozesse. CMMI = Capability Maturity Model Integration; vom SEI herausgegebenes Reifegradmodell zur Evaluierung und Verbesserung von Entwicklungsprozessen. EFQM = European Foundation for Quality Management. Fehler (defect) = Abweichung von einer Anforderung. Prüfung (inspection) = Vergleich der tatsächlichen mit den vorgesehenen bzw. geforderten Eigenschaften eines Objektes mit dem Ziel, Abweichungen bzw. Fehler zu finden QFD = Quality Function Deployment; Methode zur kundenorientierten Qualitätsplanung. Regressionstest (regression test) = wiederholte Ausführung eines Testobjekts mit Testdaten, um Fehler in bereits getesteten, aber danach modifizierten Elementen von Softwaresystemen zu finden. Review (review) = mehr oder weniger formaler Prozess der Analyse, Bewertung, Kommentierung und Genehmigung von Zwischen- oder Endergebnissen durch Gutachter. SEI = Software Engineering Institute der Carnegie Mellon University in Pittsburgh, USA. Spezifikation (specification) = Dokument, das Anforderungen an ein Objekt festlegt. Testdaten (test data) = Eingabewerte, die bei der Testdurchführung verwendet werden. Testdatenkombination (test data combination) = Testdaten, die gemeinsam bei der Ausführung eines Testobjekts verwendet werden. Testen (test) = Prüfung eines Softwaresystems oder von Teilen davon durch Ausführen mit Testdaten mit dem Ziel, Fehler zu finden. Testfall (test case) = Klasse von Eingabedaten, mit denen ein bestimmter Aspekt des Verhaltens eines Testobjekts geprüft werden soll. Testobjekt (test object) = zu testender Gegenstand (z. B. eine Softwarefunktion, ein Softwaremodul oder ein Softwaresystem). Testverfahren (test method) = begründete Vorgehensweise zur Aufdeckung einer bestimmten Klasse von Fehlern.

484

Methoden des administrativen Informationsmanagements

Zweck der Methoden des Qualitätsmanagements Viele neu entwickelte Informationssysteme erfüllen die Anforderungen der Auftraggeber und Nutzer nur unzureichend (vgl. z. B. El Emam/Koru). Das führt zu hohem Überarbeitungsaufwand. Im Extremfall gehen die Systeme nie in Betrieb und hohe wirtschaftliche Verluste sind die Folge. Aber auch andere Elemente der Informationsinfrastruktur erfüllen häufig nicht alle Anforderungen: IT-Abteilungen reagieren nicht so auf die Bedürfnisse der Fachabteilungen, wie diese das fordern, Entwicklungs- und Unterstützungsprozesse sind nicht ausreichend stabil und transparent oder das Preis/Leistungs-Verhältnis intern erbrachter ITDienstleistungen erscheint zu hoch. Um solche Probleme zu vermeiden bzw. ihre Anzahl zu senken, steht eine Vielzahl von Methoden zur Unterstützung des QM zur Verfügung. Die Gliederung orientiert sich an den Aufgaben des QM (vgl. Lerneinheit QUALM).

Methoden der Qualitätsplanung Quality Function Deployment (QFD) ist eine Methode zur kundenorientierten Qualitätsplanung, die in den 1970er Jahren in Japan von Akao entwickelt wurde. Ziel der Methode ist es, Produkte mit Eigenschaften zu entwickeln, welche die Kunden wünschen und honorieren. QFD wird in Teamarbeit durchgeführt. In einem QFD-Team sollen neben Methodenspezialisten sowohl Personen vertreten sein, welche die Kundenanforderungen kennen (z. B. Kundenvertreter, Vertriebs- und Marketingmitarbeiter), als auch für die Produktrealisierung Verantwortliche (z. B. Produktmanager und Entwickler). Der Kern der Methode besteht darin, zunächst Kundenanforderungen zu ermitteln und diese dann in Produkteigenschaften zu überführen. Dabei kann in folgenden Schritten vorgegangen werden:        

Identifizieren der relevanten Kundengruppen (Wer sind potenzielle Käufer und Nutzer?) Erfassen von Kundenanforderungen (Was wollen die Kunden?) Ermitteln der Kundenprioritäten (Welche Anforderungen sind Kunden wie wichtig?) Analyse der Kundenanforderungen (Warum sind sie den Kunden wichtig?) Ableiten von Qualitäts- bzw. Produktmerkmalen (Wie können Kundenanforderungen erfüllt werden?) Analyse von Korrelationen (Welche Qualitäts- bzw. Produktmerkmale sind in welchem Maße geeignet, Kundenanforderungen zu erfüllen?) Vergleich mit Wettbewerbern (Welche Stärken bzw. Schwächen hat das Produkt im Vergleich zur Konkurrenz?) Festlegen von Zielwerten für Qualitäts- bzw. Produktmerkmale (In welchem Maße sollen welche Qualitäts- bzw. Produktmerkmale erfüllt werden?)

Das Ergebnis ist ein durch Kundenprioritäten gesteuerter Produktplan. Zur Analyse und Dokumentation der Beziehungen zwischen Kundenanforderungen und Qualitätsmerkmalen bzw. Produkteigenschaften wird in der Regel eine Matrix verwendet, die als House-ofQuality bezeichnet wird (vgl. Abbildung MEQUA-1).

Methoden des Qualitätsmanagements (MEQUA)

Wechselbeziehungen der Produktmerkmale Produktmerkma le

Was wünschen die Kunden und wie wichtig sind ihnen die einzelnen Anforderungen?

Welche Interdependenzen bestehen zwischen den Produktmerkmalen?

Welche Eigenschaften bzw. technischen Merkma le ha t das Produkt? Vergleich mit Wettbewerbern

Kundenanforderungen

In welchem Ma ße erfüllen welche Produktmerkmale welche Kundenanforderungen?

485

Korrelationen zwischen Kundena nforderungen und Produktmerkmalen

Zielgrößen

Bewertung der Produktmerkma le

Wie gut erfüllen Wettbewerber bzw. Konkurrenzprodukte die Anforderungen?

In welchem Ma ße soll das Produkt welche Anforderungen erfüllen?

Abb. MEQUA-1: House-of-Quality

Mit Hilfe des Daches des House-of-Quality können Konflikte zwischen Qualitätsmerkmalen identifiziert werden, die durch Kompromisse oder innovative Lösungen entschärft werden müssen. Mit Hilfe weiterer Matrizen kann die Implementierung der Produkteigenschaften, z. B. im Hinblick auf Produktgestaltung, Entwicklungsprozessparameter und Produktionsplanung entworfen werden. Dabei lässt sich QFD auch mit Methoden zur Kostenplanung, z. B. Target Costing, verbinden (vgl. Lerneinheit KOLER).

Methoden der Qualitätsprüfung Methoden der Qualitätsprüfung dienen sowohl dazu, Fehler zu finden, um diese beheben zu können, als auch dazu, Fehlerursachen zu identifizieren, um weitere Fehler zu verhüten. In der Regel wird Qualitätsprüfung in Validierung und Verifizierung unterteilt.  

Validierung bezeichnet die Prüfung der Tauglichkeit eines Objektes für die vorgesehene Aufgabe bzw. den Nachweis, dass Anforderungen für eine spezifische Anwendung erfüllt worden sind. Verifizierung beschreibt die Prüfung eines Objektes gegen die Spezifikation bzw. den Nachweis, dass festgelegte Anforderungen erfüllt worden sind.

Ferner unterscheidet man Methoden der statischen und der dynamischen Qualitätsprüfung. Mit statischen Methoden können beliebige Objekte der Informationsinfrastruktur daraufhin überprüft werden, ob ihre Eigenschaften mit den vorgesehenen bzw. geforderten Eigenschaften übereinstimmen. Dynamische Methoden werden ausschließlich für die Prü-

486

Methoden des administrativen Informationsmanagements

fung von ausführbaren Softwareelementen (Modulen, Komponenten oder Systemen) verwendet. Die Anwendung dynamischer Methoden wird auch als (Software-)Testen bezeichnet. Abbildung MEQUA-2 gibt einen Überblick über die Methoden der Qualitätsprüfung. Dynamische Prüfung (Testen)

Statische Prüfung

Audit

Formale Verifikation

Review

Funktionsorientiertes Testen

Strukturorientiertes Testen

Inspektion

Kontrollflussorientiertes Testen

Walkthrough

Datenflussorientiertes Testen

Abb. MEQUA-2: Methoden der Qualitätsprüfung

Audits Mit Hilfe von Audits werden QM-Systeme, Prozesse, Organisationen oder Teile davon geprüft. Audits sollen von Personen (Auditoren) durchgeführt werden, die unabhängig von denjenigen sind, welche Planung, Entwicklung und Betrieb der zu prüfenden Objekte zu verantworten haben. Auditoren müssen objektiv und unparteilich sein, sie dürfen ihre eigene Tätigkeit nicht auditieren. Interne Audits werden von eigenem Personal durchgeführt, um zu überprüfen, ob bzw. in welchem Ausmaß festgelegte Anforderungen erfüllt werden. ISO 9001 fordert, dass interne Audits in geplanten Abständen durchgeführt werden, um zu ermitteln, ob das QM-System die Anforderungen der Norm und des Unternehmens erfüllt und ob es wirksam ist, d. h. ob es hilft, Qualitätsziele zu erreichen. Auditkriterien, -umfang, -häufigkeit und -methoden werden im QM-System festgelegt. ISO 19011 ist ein Leitfaden für Audits von QM-Systemen. Externe Audits werden von externen Dienstleistern durchgeführt, in der Regel um das Vorliegen der Voraussetzungen für eine Zertifizierung, z. B. gemäß ISO 9001, zu überprüfen.

Reviews Reviews dienen dazu, Zwischen- oder Endergebnisse von Entwicklungstätigkeiten zu prüfen. In der Regel werden sie im Rahmen der Softwareentwicklung eingesetzt. Neben der Identifikation von Softwarefehlern dienen Reviews auch dazu, Schwächen im Entwicklungsprozess aufzuzeigen und so zur Prozessverbesserung beizutragen. Es lassen sich zwei verschiedene Arten von Reviews unterscheiden:  

Bei der Inspektion versucht ein Team von Prüfern unter Anleitung eines Moderators durch gemeinsames Lesen des Prüfobjekts und mit Hilfe von Checklisten Fehler zu entdecken. Beim Walkthrough vollziehen die Prüfer die Ausführung des Softwarecodes mit Beispieldaten gemeinsam nach und versuchen auf diese Weise, Fehler zu finden.

IEEE 1028 sieht für ein Review verschiedene Rollen vor, wobei einzelne Teilnehmer mehrere Rollen einnehmen können. Ein Moderator leitet die Reviewsitzung, ein Protokollant dokumentiert gefundene Fehler und Empfehlungen zur Prozessverbesserung, ein Vorleser führt

Methoden des Qualitätsmanagements (MEQUA)

487

durch das Prüfobjekt, der Autor erörtert das Prüfobjekt und steht für Verständnisfragen zur Verfügung, verschiedene Inspektoren haben die Aufgabe, Fehler zu finden. Die Inspektoren sollten so ausgewählt werden, dass verschiedene Perspektiven auf das Prüfobjekt vertreten sind, z. B. Entwurf, Programmierung, Test und Anwendung bzw. Betrieb. Fagan beschreibt den idealtypischen Ablauf einer Inspektion wie folgt; der Ablauf kann analog auf Walkthroughs angewendet werden.     



Planung: Auswahl der Prüfobjekte und der Teilnehmer, Vereinbarung von Zeit und Ort der Sitzungen, Festlegung der Inspektionsziele. Übersichtssitzung: Information der Teilnehmer über Prüfobjekte und Inspektionsziele, Hinweis auf kritische Stellen und häufige Fehler, Aushändigung der Dokumentation und der Checklisten. Individuelle Vorbereitung: Teilnehmer analysieren die Prüfobjekte individuell, um ein besseres Verständnis der Prüfobjekte zu erhalten. Inspektionssitzung: In einer maximal zwei Stunden dauernden Sitzung werden Fehler gesucht und dokumentiert. Fehlerbehebung oder Suche nach alternativen Lösungen ist nicht Gegenstand der Sitzung. Nachbearbeitung: Der Projektleiter entscheidet, ob das Prüfobjekt für die weitere Bearbeitung freigegeben werden kann oder ob eine Fehlerbehebung notwendig ist. Wenn nötig, behebt der Autor die Fehler, dokumentiert die Änderungen und stellt diese dem Inspektionsleiter zur Verfügung. Bewertung: Es wird überprüft, ob alle Fehler behoben wurden und ob keine neuen Fehler entstanden sind. Bei geringfügigen Änderungen kann das durch den Moderator übernommen werden, bei umfangreichen Änderungen wird eine weitere Inspektionssitzung einberufen. Die Ergebnisse der Inspektion werden dokumentiert, gefundene Fehler in einer Fehlerstatistik festgehalten und Vorschläge für Verbesserungen der Entwicklungsprozesse an die zuständigen Instanzen gemeldet.

Mit Hilfe von Reviews können Fehler in Programmen gefunden werden und nicht lediglich Fehlerauswirkungen wie beim Softwaretesten. Das hat den Vorteil, dass die unter Umständen aufwendige Suche nach Fehlern entfällt, welche nach dem Testen notwendig ist. Ein weiterer Vorteil von Inspektionen im Vergleich zum Testen besteht darin, dass Inspektionen zur Prüfung beliebiger Zwischenergebnisse der Softwareentwicklung verwendet werden können, z. B. von Anforderungsdokumenten, Datenmodellen, Pseudo-Code, Testplänen oder Produktdokumentationen. Inspektionen können bereits in frühen Phasen der Softwareentwicklung (vgl. Lerneinheit VOMOD) eingesetzt werden und nicht erst nachdem ausführbarer Softwarecode vorliegt. Das ermöglicht es, Fehler früher zu finden als beim Testen.

Formale Verifikation Ziel der formalen Verifikation ist es, mit mathematischen Mitteln die Konsistenz von Spezifikation und Implementierung nachzuweisen. Entsprechende Verfahren werden auch als mathematische Korrektheitsbeweise bezeichnet. Voraussetzung für eine formale Verifikation ist, dass die Anforderungen in der Spezifikation mathematisch notiert sind. Im Unterschied zum Testen kann mit der formalen Verifikation nachgewiesen werden, dass ein Prüfobjekt korrekt aus der Spezifikation entwickelt worden ist. Fehler in der Spezifikation

488

Methoden des administrativen Informationsmanagements

können mit einer formalen Verifikation allerdings nicht gefunden werden. Die Anwendung formaler Methoden ist sehr aufwendig. Deshalb werden sie im Rahmen der IT auch nur selten eingesetzt. Sollen sicherheitsrelevante Komponenten von IT-Systemen gemäß Sicherheitskriterien evaluiert werden (vgl. Lerneinheit SICHM) und ist ein sehr hohes Sicherheitsniveau erforderlich, werden formale Verfahren verwendet, um nachzuweisen, dass die Implementierung keine Abweichung von der Spezifikation aufweist.

Testen Testen hat das Ziel, durch Ausführen eines Testobjekts Fehler zu finden. Genau genommen, werden mit Hilfe von Tests allerdings keine Fehler gefunden, sondern Fehlerauswirkungen, da durch Tests lediglich fehlerhaftes Verhalten der Software entdeckt werden kann. Da die Anzahl der möglichen Eingaben in ein Testobjekt in der Regel unüberschaubar groß ist, können Testobjekte praktisch nicht erschöpfend getestet werden. Deshalb ist Testen nicht geeignet, die Korrektheit eines Softwareprogramms nachzuweisen. Unterschiedliche Testverfahren führen zur Auswahl unterschiedlicher Testfälle bzw. Testdatenkombinationen. Testverfahren werden in funktionsorientierte und strukturorientierte unterschieden. Bei den funktionsorientierten Testverfahren werden Testfälle aus der funktionalen Spezifikation abgeleitet, bei den strukturorientierten aus der Struktur des Quellprogramms, z. B. aus dem Kontroll- oder dem Datenfluss eines Programms. Liggesmeyer und Myers beschreiben die wichtigsten Testverfahren detailliert. Der Ablauf eines Tests besteht aus folgenden Schritten: 1. 2. 3. 4. 5. 6. 7.

Definition von Testfällen, Auswahl von Testdatenkombinationen für jeden Testfall, Definition des erwarteten Softwareverhaltens für jede Testdatenkombination, Ausführen des Testobjekts mit einer Testdatenkombination, Vergleich des erwarteten mit dem tatsächlichen Softwareverhalten, Dokumentation des Testergebnisses, Wiederholung der Schritte 4 bis 6, bis das Testobjekt mit allen in 2. definierten Testdatenkombinationen ausgeführt wurde.

Da von einem fehlerhaften Verhalten der Software nicht unmittelbar auf den oder die Fehler im Softwarecode geschlossen werden kann, müssen im Unterschied zu Reviews nach dem Testen Fehler gesucht werden, bevor die Entwickler diese beheben können. Überarbeitete Testobjekte sollten einem Regressionstest unterzogen werden, da Fehlerbehebung häufig zu neuen Fehlern führt.

Methoden der Qualitätsverbesserung Qualitätszirkel Qualitätszirkel sind eine kombinierte Maßnahme zur Qualitätsverbesserung, zur Weiterbildung und Motivierung, also zielorientiert arbeitende Gruppen von Mitarbeitern, die ihr eigenes arbeitsspezifisches Wissen und ihre Erfahrung einbringen. Sie bearbeiten Probleme ihrer Arbeitssituation und entwickeln Problemlösungen, die helfen, die Arbeitssituation zu verbessern, die Arbeitszufriedenheit zu erhöhen und die zum Unternehmenserfolg beitragen. Ein

Methoden des Qualitätsmanagements (MEQUA)

489

Qualitätszirkel besteht aus vier bis acht Mitarbeitern, die sich regelmäßig während der Arbeitszeit treffen (z. B. wöchentlich für je eine Stunde). Betreuer unterstützen Qualitätszirkel ausschließlich arbeitsmethodisch; sie sind bezüglich der bearbeiteten Probleme fachneutral.

Reifegradmodelle In den 1980er Jahren entwickelte das SEI unter der Bezeichnung CMM for Software ein Reifegradmodell, mit dem Softwareentwicklungsprozesse im Hinblick auf deren Reife evaluiert werden konnten. Reife wird als Ausmaß verstanden, in dem ein Prozess geplant, definiert, dokumentiert, quantitativ kontrolliert und gesteuert sowie kontinuierlich verbessert wird. Außerdem gab das CMM detaillierte Anleitungen zur Verbesserung solcher Prozesse. Das CMM entwickelte sich zunächst in den USA und später weltweit zum De-facto-Standard für Softwareprozessverbesserung. In der Folge wurden sowohl vom SEI als auch von anderen Institutionen verschiedene Derivate des CMM entwickelt, z. B. Bootstrap und SPICE, deren wesentliche Inhalte in ISO 15504 standardisiert sind. Kneuper gibt einen Überblick über die wichtigsten Reifegradmodelle. Das CMM wurde im Jahr 2000 in das CMMI for development überführt und liegt seit 2010 in der Version 1.3 vor. Das SEI bezeichnet das CMMI for Development als Referenzmodell, welches Entwicklungs- und Wartungsaufgaben für Produkte und Dienstleistungen beschreibt. Im CMMI wird ein Prozess als Abfolge von (Entwicklungs-)Aktivitäten definiert. Dem CMMI liegt die Annahme zugrunde, dass mit steigendem Reifegrad die Fähigkeit zunimmt, Termine und Budgets einzuhalten sowie Qualitätsziele zu erfüllen. Ferner wird behauptet, dass bei einem Prozess mit hohem Reifegrad die Qualität der entwickelten Produkte höher, die Entwicklungszeiten von Projekten kürzer und die Entwicklungskosten niedriger seien als bei einem niedrigen Reifegrad. 5 optimizing 4 quantitatively managed

Quantitative Steuerung

3 defined 2 managed 1 initial

Kontinuierliche Verbesserung

Prozessmanagement

Projektmanagement Abb. MEQUA-3: Reifegrade des CMMI

Es gibt zwei Repräsentationsformen des CMMI: die stufenförmige und die kontinuierliche. Die stufenförmige Repräsentationsform unterscheidet fünf Reifegrade von Prozessen, die in Abbildung MEQUA-3 wiedergegeben sind. Diese Reifegrade geben Anhaltspunkte für die Prozessbewertung und zeigen konkrete Schritte auf dem Weg der Prozessverbesserung auf. Charakteristika der fünf Reifegrade sind: 

1 (initial): Es gibt keine einheitlichen Vorgaben für das Projektmanagement. Projekte werden ad hoc geplant, gesteuert und kontrolliert, ihr Erfolg hängt wesentlich von Erfah-

490









Methoden des administrativen Informationsmanagements

rung und Motivation der Mitarbeiter ab. Termin- und Budgetüberschreitungen sind die Regel. Erfolge in einzelnen Projekten können nur zufällig wiederholt werden. 2 (managed): Projekte werden gemäß einer Prozessbeschreibung geplant, gesteuert und kontrolliert. Durchführung und Ausmaß der Zielerreichung von Projekten werden transparent dargelegt und sind für das Management nachvollziehbar. Erfolge in Projekten können unter ähnlichen Bedingungen mit hoher Wahrscheinlichkeit wiederholt werden. 3 (defined): Projekte richten sich nach einem standardisierten und unternehmensweit gültigen Entwicklungsprozess. Darin sind Ziele, Eingaben, Startbedingungen, Aktivitäten, Rollen, Maßnahmen, Prüfkriterien, Ausgaben und Endbedingungen beschrieben. Situationsspezifische Anpassungen des Prozesses sind zulässig, sofern sie nachvollziehbar begründet werden. Die Anwendung der Maßnahmen wird kontinuierlich verbessert. Erfahrungen aus einzelnen Projekten helfen, den Entwicklungsprozess zu verbessern. 4 (quantitatively managed): Es werden quantitative Ziele für Softwareprodukte und -prozesse formuliert. Die Qualität von Produkten und die Produktivität von Prozessen werden im Rahmen eines unternehmensweiten Messprogramms bestimmt. Die Wirkungen von Management- und Engineering-Aktivitäten auf Zeit-, Kosten- und Qualitätsziele sind in Form von Ursache/Wirkung-Beziehungen quantitativ formuliert. Management-, Software-Engineering- und QM-Maßnahmen können dadurch gezielt eingesetzt werden. 5 (optimizing): Das Unternehmen verbessert kontinuierlich alle relevanten Prozesse. Dazu wird die bei Reifegrad 4 etablierte quantitative Beschreibung von Ursache/Wirkung-Beziehungen verwendet. Für die Prozessverbesserung werden quantitative Ziele vorgegeben, deren Erreichung regelmäßig überprüft wird.

Den Reifegraden 2 bis 5 sind bestimmte Prozessgebiete (vgl. Abbildung MEQUA-4) mit spezifischen Anforderungen zugeordnet. Um einen Reifegrad erreichen zu können, müssen in der stufenförmigen Repräsentation die Anforderungen dieses und aller darunter liegenden Reifegrade erfüllt werden. Reifegrad 2  Requirements Management  Project Planning  Project Monitoring and Control  Supplier Agreement Management  Measurement and Analysis  Process and Product Quality Assurance  Configuration Management Reifegrad 3  Requirements Development  Technical Solution  Product Integration  Verification

      

Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Decision Analysis and Resolution

Reifegrad 4  Organizational Process Performance  Quantitative Project Management Reifegrad 5  Organiz. Innovation and Deployment  Causal Analysis and Resolution

Abb. MEQUA-4: Prozessgebiete des CMMI

Methoden des Qualitätsmanagements (MEQUA)

491

Im Gegensatz zur stufenförmigen Repräsentation gibt die kontinuierliche keine bestimmte Reihenfolge für Prozessverbesserungen vor. Vielmehr erlaubt sie es, Verbesserungen in beliebiger Reihenfolge durchzuführen bzw. sich auf einzelne Prozessgebiete zu konzentrieren. Jedes Prozessgebiet wird mit einem der folgenden Fähigkeitsgrade bewertet.      

0 (incomplete): Prozessgebiet wird nicht oder nicht vollständig durchgeführt. 1 (performed): Prozessgebiet erfüllt vorgegebene Ziele. 2 (managed): Prozessgebiet wird gemäß einer standardisierten Beschreibung geplant, durchgeführt, gesteuert und kontrolliert. 3 (defined): Prozessgebiet wird nach definierten Regeln aus einer unternehmensweit gültigen Beschreibung abgeleitet und entsprechend durchgeführt. 4 (quantitatively managed): Prozessgebiet wird quantitativ geplant, gesteuert und kontrolliert. 5 (optimizing): Prozessgebiet wird auf der Grundlage quantitativ beschriebener Ursache/Wirkung-Beziehungen kontinuierlich verbessert.

Unternehmen können Entwicklungsprozesse durch vom SEI lizenzierte externe Auditoren daraufhin begutachten lassen, ob bzw. in welchem Ausmaß die im CMMI beschriebenen Anforderungen umgesetzt werden. Solche Begutachtungen werden als Assessments) bezeichnet.

Exzellenzmodelle Seit 1987 wird der Malcolm Baldrige National Quality Award vom Präsidenten der Vereinigten Staaten an amerikanische Unternehmen verliehen, die ein herausragendes QM implementiert haben. Seit 1992 vergibt die EFQM jährlich einen vergleichbaren Preis, der bis 2006 als European Quality Award und seit dem als EFQM Excellence Award (EEA) bezeichnet wird. Ähnliche Preise gibt es auch auf nationaler, zum Teil regionaler Ebene. Den Preisen liegen Modelle zugrunde, die als Grundlage für Selbstbewertungen dienen und Kriterien für die Auswahl der Preisträger beinhalten. Während Reifegradmodelle im Wesentlichen der Evaluierung und Verbesserung von Entwicklungsprozessen dienen, werden mit Exzellenzmodellen weitergehende Ziele verfolgt. Sie bieten Hilfestellung für die Bewertung und Verbesserung von ganzen Unternehmen. Die Exzellenzmodelle berücksichtigen explizit, dass QM kein Selbstzweck ist, sondern der Erreichung von Unternehmenszielen dient. Von allen Methoden der Qualitätsverbesserung entsprechen Exzellenzmodelle am deutlichsten der ganzheitlichen bzw. umfassenden Sicht des QM (vgl. Lerneinheit QUALM). Abbildung MEQUA-5 zeigt die Elemente des EFQM-Modells für Exzellenz. Die Elemente des EFQM-Modells für Exzellenz sind in so genannte Befähiger (enablers) und Ergebnisse (results) gegliedert. Befähiger beschreiben, wie ein Unternehmen wesentliche Aufgaben bewältigt. Ergebnisse beschreiben, in welchem Maße relevante Ziele erreicht werden. Der untere Pfeil deutet an, dass Lernen und Innovation helfen, die Gestaltung der Befähiger zu verbessern, was sich wiederum in besseren Ergebnissen niederschlagen wird. Die Elemente werden wie folgt charakterisiert.

492

Methoden des administrativen Informationsmanagements

Befähiger

Ergebnisse Mitarbeiterbezogene Ergebnisse

Mitarbeiter

Führung

Politik und Strategie Partnerschaften und Ressourcen

Prozesse

Kundenbezogene Ergebnisse

Schlüsselergebnisse

Gesellschaftsbezogene Ergebnisse Innovation und Lernen

Abb. MEQUA-5: EFQM-Modell für Exzellenz

     

Führung: Exzellente Führungskräfte entwickeln Ziele, Werte und Grundsätze ethischen Handelns, verankern diese im Unternehmen, verhalten sich selbst dementsprechend und setzen einen unternehmerischen Wandel in Gang sofern notwendig. Mitarbeiter: Exzellente Unternehmen entwickeln das gesamte Potenzial ihrer Mitarbeiter, ermächtigen diese zu eigenständigem Handeln, führen einen offenen Dialog mit ihnen, zollen Anerkennung und belohnen die Mitarbeiter in angemessener Weise. Politik und Strategie: Ziele und Pläne des Unternehmens werden auf die relevanten Interessengruppen ausgerichtet und auf der Basis von Leistungsmessungen kontinuierlich bewertet und aktualisiert. Partnerschaften und Ressourcen: Exzellente Unternehmen planen, steuern und kontrollieren Beziehungen zu externen Partnern, Finanzen, materielle Ressourcen, Technologien, Information und Wissen. Prozesse: Interne Leistungserstellungsprozesse werden systematisch gestaltet sowie im Hinblick auf die Bedürfnisse von Kunden und anderen Interessengruppen verbessert. Mitarbeiter-, kunden- und gesellschaftsbezogene Ergebnisse sowie Schlüsselergebnisse: Exzellente Unternehmen messen die Erreichung der von der Strategie vorgegebenen Ziele sowie die für Mitarbeiter, Kunden und die Gesellschaft relevanten Ziele und erzielen dabei ausgezeichnete Ergebnisse.

Forschungsbefunde Haag/Raja/Schkade berichten über eine Untersuchung zur Nutzung von QFD in Unternehmen, deren wesentlicher Geschäftszweck Softwareentwicklung ist (Telefoninterviews in 37 Unternehmen, keine Angaben zur Grundgesamtheit oder zum Untersuchungszeitraum). In sechs der befragten Unternehmen wird QFD eingesetzt. Die Erfahrungen der Befragungsteilnehmer beruhen auf 35 Projekten. Wesentliche Ziele des QFD-Einsatzes sind: analyzing

Methoden des Qualitätsmanagements (MEQUA)

493

customer demands, setting breakthrough targets und analyzing competitors. Die Befragten gaben an, der Einsatz von QFD habe positive Wirkungen auf folgende Aspekte der Softwareentwicklung (Angaben in Klammern repräsentieren den jeweiligen Durchschnitt der Nennungen gemäß einer Fünf-Punkt-Likert-Skala; 1 = strongly disagree, 5 = strongly agree): improved user involvement (4.6), improved management support and involvement (4.4), improved project development technique (4.4), technique to shorten … software develoment life cycle (4.0). Als wichtigste Nutzeneffekte des QFD-Einsatzes wurden genannt: structured step-by-step methodology (5.0), supports team involvement (4.8), aids in avoiding the loss of information (4.6), structured process for organizational communication (4.6), preventive quality tool (4.6), reduces departmental division (4.4), leads to innovative responses to customer demands (4.2), process to reduce complexity (4.0) und facilitates competitor analysis (4.0). Agrawal/Chari analysieren Nutzeffekte des CMM-Reifegrades 5 (Analyse der von Unternehmen zur Verfügung gestellten Daten sowie mündliche Befragung von Projektverantwortlichen für 37 Softwareentwicklungsprojekte vorwiegend für betriebswirtschaftliche Anwendungen in vier Unternehmen, Untersuchungszeitraum 1998 bis 2004). In den untersuchten Projekten haben Produktkomplexität und -modularität, Termindruck, Größe des Entwicklungsteams, Erfahrung der Mitarbeiter, Qualität der Anforderungsdokumente sowie die Erfahrung des Projektleiters keinen wesentlichen Einfluss auf Entwicklungsaufwand, und -zeit sowie Produktqualität. Der hauptsächliche Nutzen der Implementierung des CMM-Reifegrades 5 besteht in der Reduzierung der Varianz der Ergebnisse der Softwareentwicklung.

Aus der Praxis Jackson gibt Empfehlungen für ein „professionelles“ Testen. Testfälle sollen bereits während der Anforderungsanalyse bzw. der Erstellung des Fachkonzepts erstellt werden; dadurch lässt sich der Aufwand für die Testfallspezifikation begrenzen. Im Rahmen von Wartungsaufgaben soll der Schwerpunkt des Testens auf die Bereiche konzentriert werden, die von Änderungen betroffen sind. Ein risikobasiertes Testen hilft, die Testaktivitäten auf die Systemkomponenten zu fokussieren, die für das Unternehmen am kritischsten sind oder eine hohe Komplexität aufweisen. Testaufgaben sollen – soweit möglich – durch Werkzeuge unterstützt werden. Diese können z. B. aus Produktivsystemen Testdaten generieren oder selektieren. Capture-Replay-Tools, Werkzeuge, welche Aktivitäten des Benutzers oder Testers (z. B. Mausbewegungen oder Tastatureingaben) aufzeichnen, helfen, den Testaufwand für funktionale Regressionstests zu begrenzen. Aufgabenverweise Qualitätsmanagement (Lerneinheit QUALM). Kontrollfragen 1. Wie kann QFD im IT-Bereich genutzt werden? 2. Welche Arten von Fehlern können mit Softwaretests nicht gefunden werden? 3. In welcher Phase des Softwarelebenszyklus können frühestens Testfälle a) für ein funktionsorientiertes und b) für ein strukturorientiertes Testverfahren definiert werden? 4. Welcher Nutzen und welche Kosten sind mit der Verbesserung eines Entwicklungsprozesses von Reifegrad 3 auf Reifegrad 5 des CMMI verbunden? 5. Worin besteht der wesentliche Unterschied zwischen Reifegrad- und Exzellenzmodellen?

494

Methoden des administrativen Informationsmanagements

Quellen Agrawal, M. / Chari, K.: Software Effort, Quality and Cycle Time: A Study of CMM Level 5 Projects. In: IEEE Transactions on Software Engineering 3/2007, 145–156 Akao, Y.: QFD - Quality Function Deployment - Wie die Japaner Kundenwünsche in Qualität umsetzen. Landsberg, Lech 1992 El Emam, K. / Koru, A. G.: A Replicated Survey of IT Software Project Failures. In: IEEE Software. 5/2008, 84–90 Fagan, M. E.: Design and Code Inspections to Reduce Errors in Program Development. In: IBM Systems Journal 3/1976, 182–211 Fagan, M. E.: Advances in Software Inspections. In: IEEE Transactions on Software Engineering 7/1986, 744–751 Haag, S. / Raja, M. K. / Schkade, L. L.: Quality Function Deployment. Usage in Software Development. In: Communications of the ACM 1/1996, 41–73 Jackson, R.: Testmanagement: Professionelles Testen. In: Informatik Spektrum 1/2009, 37–41 Kneuper, R.: CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration. 2. A., Heidelberg 2007 Liggesmeyer, P.: Software-Qualität: Testen, Analysieren und Verifizieren von Software. 2. A. Heidelberg 2009 Myers, G. J.: Methodisches Testen von Programmen. 7. A., München/Wien 2001 Software Engineering Institute: CMMI for Development, Version 1.3. CMMI-DEV, V1.3. CMU/SEI-2010-TR-033. Pittsburgh, PA 2010 Vertiefungsliteratur Akao, J.: Quality Function Deployment: Integrating Customer Requirements into Product Design. Cambridge 2004 Freedman, D. P. / Weinberg, G. M.: Handbook of Walkthroughs, Inspections, and Technical Reviews. Evaluating Programs, Projects, and Products. 3. A., New York 1991 Humphrey, W. S.: Managing the Software Process. Reading 1989 Paulk, M. C. et al.: The Capability Maturity Model: Guidelines for Improving the Software Process. Reading 1995 Informationsmaterial CMMI: kurze Erklärung in einem Film http://www.wibas.de Deutsche Gesellschaft für Qualität (DGQ) http://www.dgq.de/ Deutsche Übersetzung des CMMI http://www.sei.cmu.edu/cmmi/tools/translations/german.cfm Deutsches Excellence Center (DEC) http://www.dgq.de/wid/excellence-center.htm European Foundation for Quality Management (EFQM) und EFQM Excellence Award (EEA) http://www.efqm.org EFQM (Hrsg.): Die Grundkonzepte der Excellence. Brüssel 2003 http://www.deutschlands-kundenchampions.de Initiative Ludwig-Erhard-Preis http://www.ilep.de International Software Testing Qualifications Board http://www.istqb.org Malcolm Baldrige National Quality Award http://www.nist.gov/baldrige Quality Austria http://www.qualityaustria.com QFD Institut Deutschland e. V. http://www.qfd-id.de/ Swiss Association for Quality (SAQ) http://www.saq.ch Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh, USA http://www.sei.cmu.edu Normen IEEE 829-1998 Standard for Software Test Documentation IEEE 1028-1997 Standard for Software Reviews ISO 9001:2008 Qualitätsmanagementsysteme – Anforderungen ISO 19011:2002 Guidelines for quality and/or environmental management systems auditing ISO/IEC 15504-1:2004 Information technology - Process assessment - Part 1: Concepts and vocabulary

Serviceebenen-Vereinbarungen (SEVER) Lernziele Sie kennen den Zweck von Serviceebenen-Vereinbarungen und deren interne und externe Partner. Sie wissen, welche Inhalte diese Vereinbarungen haben und wie ihre Einhaltung durch Managementprozesse gesichert wird. Sie können die Phasen des Entwicklungsprozesses für Serviceebenen-Vereinbarungen und Managementprozesse erläutern. Sie können das Nutzenpotenzial von Serviceebenen-Vereinbarungen angeben.

Definitionen und Abkürzungen Benutzerservice (service desk) = Struktureinheit, der operative Aufgaben des Störungsmanagements zugeordnet sind. Synonyme: Helpdesk, User-Help-Desk. CobiT = Control Objectives for Information and Related Technology Model; Leitfaden für Governance. Dienstleistung (service) = selbstständige, marktfähige Leistung, die mit der Bereitstellung und/oder Verwendung von vorhandenen Fähigkeiten verbunden ist, deren Erstellung interne und externe Faktoren mit dem Ziel kombiniert, an Menschen und/oder Objekten eine Nutzen stiftende Wirkung zu erreichen. Dienstleistungsqualität (service quality) = Übereinstimmung von definierten Anforderungen für Eigenschaften und Merkmale von Dienstleistungen mit den tatsächlich realisierten Anforderungen. Synonym: Servicequalität. ITIL = Information Technology Infrastructure Library; Leitfaden für Servicemanagement. OLA = Operational Level Agreement. Qualitätsniveau (quality level) = Ausmaß an geforderter oder vorhandener Qualität. Serviceebene (service level) = Qualitätsniveau einer Dienstleistung. Serviceebenenmanagement (service level management) = Führungsaufgabe, die mit der Festlegung von Serviceebenen und der Vereinbarung von Serviceebenen zwischen Dienstleistungsnehmer und Dienstleistungsgeber im Zusammenhang steht. Servicegrad (service degree) = Verhältnis von tatsächlichem zum vereinbarten Ausmaß der Dienstleistungsqualität. Servicekultur (service culture) = Ausmaß der Akzeptanz des Dienstleistungsgedankens und des gelebten Dienstleistungsbewusstseins im Unternehmen. SLA = Service Level Agreement; Serviceebenen-Vereinbarung; Vereinbarung über vom Kunden gewünschte und vom Dienstleister zugesagte Ausprägungen von Eigenschaften einer Dienstleistung. SLR = Service Level Requirement; Serviceebenen-Anforderung; vom Kunden formulierte Anforderung an eine Dienstleistung. SLS = Service Level Specification; Serviceebenen-Spezifizierung; detaillierte Beschreibung einer Serviceebenen-Vereinbarung, die als Leitlinie für die Gestaltung einer Dienstleistung dient.

496

Methoden des administrativen Informationsmanagements

Zweck von SLAs Serviceebenenmanagement (vgl. Lerneinheit SEMAN) hat das Ziel, die Einhaltung vereinbarter Qualitätsniveaus von Services zu möglichst geringen Kosten sicherzustellen. Das für das Serviceebenenmanagement charakteristische Instrument sind Serviceebenen-Vereinbarungen; sie sind die Voraussetzung für die Ausrichtung der IT-Organisation an den Kundenanforderungen. Mit zunehmender Kundenorientierung des IT-Bereichs entwickelt sich eine Dienstleistungsbeziehung zwischen Benutzern als Kunden und Dienstleistungsnehmern auf der einen und dem IT-Bereich als Dienstleistungsgeber auf der anderen Seite. Diese Entwicklung wird durch Ausbreitung von Outsourcing gefördert (vgl. Lerneinheit OUTSO), bei dem externe Dienstleister in einer Dienstleistungsbeziehung zu den Anwendern und Benutzern stehen. Dienstleistungsqualität und Kosten bzw. Preise werden zwischen Dienstleistungsgeber und -nehmer verbindlich und schriftlich in Verträgen vereinbart (vgl. Lerneinheit VERMA). Eine Serviceebenen-Vereinbarung ist ein Dokument dieser Art. Serviceebenen-Vereinbarungen sind für innerbetriebliche Dienstleistungsbeziehungen, bei denen vor allem die IT-Abteilung Dienstleistungsgeber ist, ebenso sinnvoll wie für zwischenbetriebliche Dienstleistungsbeziehungen, bei denen Unternehmen des IT-Marktes (Outsourcing-Dienstleister, insbesondere ASP, vgl. Lerneinheit OUTSO) Dienstleistungsgeber sind. Konflikte zwischen den Partnern sollen durch klare Vereinbarungen vermieden bzw. trotzdem auftretende Konflikte auf deren Grundlage gelöst werden. Aus Sicht des Nutzers kann die Verwendung von ServiceebenenVereinbarungen in drei Kategorien gegliedert werden:   

zwischen Nutzern von IT-Dienstleistungen in den Fachbereichen und dem IT-Bereich (z. B. Benutzerservice), zwischen verschiedenen Struktureinheiten des IT-Bereichs (z. B. zwischen Benutzerservice oder Helpdesk und Produktionsbetrieb) und zwischen IT-Bereich und externen Outsourcing-Dienstleistern (auch bei Ausgründung).

Weitere Anwendungsbereiche von Serviceebenen-Vereinbarungen sind denkbar, beispielsweise für Call Center und Shop-Betreiber beim E-Commerce (vgl. das Demonstrationsbeispiel auf der Website). Aus Serviceebenen-Vereinbarungen entwickeln sich ServicewertVereinbarungen, mit denen der Dienstleistungsgeber die Verantwortung für die Geschäftsprozesse übernimmt, die der Kunde mit Unterstützung der Dienstleistungen abwickelt. Die Bewertung der Dienstleistungen erfolgt dann unter Berücksichtigung des Wertes, den die Dienstleistungen für den Kunden schaffen, bzw. des Schadens, der durch Nichteinhaltung von Serviceebenen entsteht. (Im Folgenden wird zur Abkürzung für ServiceebenenVereinbarung das englischsprachige Akronym SLA bzw. im Plural SLAs, für Serviceebenen-Anforderung das englischsprachige Akronym SLR bzw. SLRs verwendet.) In ITIL (Rudd/Lloyd) ist SLA definiert als “… an agreement between an IT service provider and a customer. The SLA describes the IT service, documents Service Level Targets, and specifies the responsibilities of the IT service provider and the customer.“ SLAs legen die minimale, für den Kunden noch akzeptable Serviceebene fest. Für die Unterschreitung von Serviceebenen werden Konsequenzen festgelegt.

Serviceebenen-Vereinbarungen (SEVER)

497

SLAs in Managementsystemen SLAs sind Elemente folgender Managementsysteme:  





Für IT-Servicemanagementsysteme (vgl. Lerneinheit SEMAN) sind Anleitungen zur Formulierung, Planung, Steuerung und Kontrolle von SLAs in ITIL im Kapitel Service Design und in ISO/IEC 20000 im Kapitel Service Delivery Processes beschrieben. Empfehlungen zum Management von SLAs im Rahmen von IT-Governance (vgl. Lerneinheit GOVER) werden in CobiT unter anderem in den Kapiteln DS1 Define and manage service levels, PO8 Manage quality und ME1 Monitor and evaluate IT performance gegeben. ISO 9001:2000 fordert für die Realisierung von Qualitätsmanagementsystemen (vgl. Lerneinheit QUALM), dass bereits bei der Produktplanung, Qualitätsziele und Anforderungen – insbesondere von Kunden – an das Produkt festgelegt werden. Da laut ISO 9000-2005 ein Produkt das Ergebnis eines Prozesses ist, gelten diese Forderungen auch für Dienstleistungen. Es ist sicherzustellen, dass die Einhaltung der Anforderungen überprüft wird und dass Aufzeichnungen erstellt werden, mit denen nachgewiesen werden kann, in welchem Maße die Anforderungen erfüllt wurden. Ferner ist zu gewährleisten, dass Abweichungen von den Anforderungen beseitigt werden. Für das Sicherheitsmanagement (vgl. Lerneinheit SICHM) fordert das Bundesamt für Sicherheit in der Informationstechnik in den IT-Grundschutzkatalogen (vgl. Lerneinheit SIKON) den Abschluss von SLAs für die Notfallvorsorge (vgl. Lerneinheit NOMAN) für Speichersysteme.

Bestandteile von SLAs Zur Erleichterung der Nachvollziehbarkeit und Prüfung der Vollständigkeit empfiehlt Berger, folgende inhaltliche Struktur zu verwenden. Diese kann als Vorlage zur Gestaltung von SLAs dienen, welche an die jeweiligen Rahmenbedingungen angepasst werden müssen.   

Vereinbarungsbezogene Elemente beziehen sich auf Rahmenbedingungen und juristische Aspekte einer SLA, wobei die juristischen Aspekte lediglich bei Vereinbarungen mit externen Dienstleistern von Bedeutung sind. Dienstleistungsbezogene Elemente beschreiben Vereinbarungen, die in unmittelbarem Zusammenhang mit den zu erbringenden Dienstleistungen stehen. Managementbezogene Elemente sind Vereinbarungen, die im Zusammenhang mit der Handhabung von SLAs von Bedeutung sind.

Abbildung SEVER-1 gibt einen Überblick über den Inhalt von SLAs.

498

Methoden des administrativen Informationsmanagements

Vereinbarungsbezogene Elemente Grundelemente - Gegenstand - Zweck bzw. Ziele - Partner - Geltungsbereich - Inkrafttreten, Laufzeit, Beendigung

Juristische Elemente - Gerichtsstand - anwendbares Recht - Schiedsgerichtsverfahren - Haftung und Gewährleistung - Schadenersatz

Dienstleistungsbezogene Elemente Inhalt der Dienstleistung - Bezeichnung - Kurzbeschreibung - Teilleistungen - Ablauf - Rahmenbedingungen - Negativabgrenzung

Qualität der Dienstleistung - Kennzahlen - Messverfahren - Bezugsobjekte - Serviceebenen - Randbedingungen

Preis der Dienstleistung - Verrechnungspreismodell - Verrechnungspreise je Verrechnungseinheit

Managementbezogene Elemente - Regelungen - Regelungen - Regelungen - Regelungen - Regelungen - Regelungen

zum Serviceebenen-Berichtswesen für Abweichungen von vereinbarten Serviceebenen zur Kontrolle der Serviceebenen-Vereinbarung zur Änderung der Serviceebenen-Vereinbarung zur Lösung von Konflikten zur Verrechnung von erbrachten Dienstleistungen

Abb. SEVER-1: Inhalt von SLAs (Quelle: nach Berger)

Leistungsumfang von SLAs Beide Seiten, Leitungsgeber und -nehmer, vereinbaren Rechte und Pflichten sowie Konsequenzen, die eintreten, wenn Rechte verletzt bzw. Pflichten nicht erfüllt werden. Die Dienstleistungen werden in ihrer Qualität und ihrem Servicegrad mit Hilfe von Kennzahlen, Messwerten und anderen Attributen beschrieben. Dabei gilt für Dienstleistungsgeber der Grundsatz, nur solche Pflichten einzugehen, die auch erfüllt werden können. Dies soll durch das Serviceebenenmanagement (vgl. Lerneinheit SEMAN) erreicht werden. Nicht übersehen werden darf, dass sich eine Reihe von Merkmalen, die für ein funktionierendes Dienstleistungsverhältnis wesentlich sind, nicht mit SLAs erfassen und verbindlich regeln lassen (z. B. Vertrauen, Verständnis für einander, Gesprächsbereitschaft und Kommunikationsklima). Es ist auch schwierig, Serviceebenen für Beratungsdienstleistungen zu finden. Für die Beschreibung von SLAs sind – neben ihrer Bezeichnung (z. B. Antwortzeit, Verfügbarkeit) – weitere Attribute von Bedeutung, insbesondere Ziel der SLA, Serviceebenen-

Serviceebenen-Vereinbarungen (SEVER)

499

Kennzahl (Definition und Typ wie Spitzenkennzahl, Ergebniskennzahl, Leistungstreiber; vgl. Lerneinheit KENNZ), Kennzahlenwerte, Ersteller und Empfänger der Kennzahl, Messmethode, Messhäufigkeit, Folgen der Nichteinhaltung (Sanktionen und Maßnahmen), gegebenenfalls Zielvereinbarungsfähigkeit (falls ein Zielvereinbarungssystem für Mitarbeiter verwendet wird oder aufgebaut werden soll). Außerdem ist zu vereinbaren, auf welche konkreten Komponenten (Einzelkomponente oder Gesamtsystem) oder Prozesse (Teilprozess oder Gesamtprozess) sich die Kennzahlen beziehen (z. B. alle SAP-Anwendungen an allen Arbeitsplätzen oder bestimmte SAP-Module an einzelnen Arbeitsplätzen). Beispiele für SLAs sind:         

Reaktionszeit bei Fehlern als Zeitraum zwischen dem Empfang der Fehlermeldung und dem Ende der Fehlerbeseitigung (in Minuten bis Tagen), Meantime Between Failure (MTBF) als zeitlicher Abstand zwischen zwei gleichen Fehlern (in Tagen), Antwortzeit zu definierten Systemzeiten (in Sekunden, z. B. zwischen 8 und 10 Uhr, 12 und 14 Uhr), Betriebszeit mit Angabe der Tage und Zeiten (z. B. Montag bis Freitag jeweils von 5 bis 20 Uhr), Stillstandzeit für Hardware-Wartung und Betriebssystem-Updates (in Tagen pro Jahr mit Angabe der Wartungszeiten, z. B. „nur an Wochenenden“), Wiederanlaufzeit als Zeitraum zwischen einem Katastrophenfall bis zum Restart auf einem Backup-System (in Tagen), Skill-based Routing als Anzahl der Weiterleitungen bis zum Experten bei telefonischen Service-Anforderungen (in %, z. B. höchstens 10 %; diese müssen innerhalb von 2 Minuten zum Experten geschaltet sein), Release-Wechsel als Durchführungszeitraum in Tagen vom Beginn bis zum Ende sowie Termine für Beginn und Ende des Betriebs bestimmter Anwendungssysteme.

Strukturformen von SLAs ITIL unterscheidet drei Strukturformen von SLA (zitiert nach Herrmann/Müller):  



Servicespezifische SLAs sind Vereinbarungen für einen Service, für den für alle Kunden gleiche Qualitätsanforderungen gelten (z. B. für den Betrieb eines E-Mail-Dienstes). Kundenspezifische SLAs sind individuelle Vereinbarungen zwischen einem Anbieter und einem Kunden oder einer Kundengruppe, in denen Ausprägungen von Eigenschaften aller Services spezifiziert werden, die der Anbieter für diesen Kunden bzw. diese Kundengruppe erbringt (z. B. maximale Reaktionsdauer nach Anfragen durch Nutzer). Mehrdimensionale SLAs kombinieren mehrere Ebenen. Auf der obersten Ebene werden Vereinbarungen getroffen, die für alle Kunden eines Anbieters gelten (z. B. in einem Rahmenvertrag). Auf der Kundenebene werden Ausprägungen von Qualitätsmerkmalen spezifiziert, die für alle Dienstleistungen gelten, die ein Kunde von einem Anbieter bezieht. Auf der Serviceebene werden kundenspezifische Anforderungen an einzelne Services vereinbart.

Ziel der mehrdimensionalen Struktur ist es, den Umfang und die Komplexität von SLAs zu beschränken und Redundanz zu vermeiden.

500

Methoden des administrativen Informationsmanagements

Kontext von SLAs Ein Dienstleister muss sicherstellen, dass in den SLAs mit Kunden vereinbarte Qualitätsniveaus von Services eingehalten werden können. Da sich IT-Dienstleister häufig der Hilfe anderer interner oder externer Struktureinheiten bedienen, muss gewährleistet werden, dass die Erfüllung der SLAs nicht durch mangelhafte Leistungen der Zulieferer gefährdet wird. Ein IT-Bereich verwendet Operational Level Agreements (OLAs) und Underpinning Contracts, um die Qualität der Elemente von Dienstleistungen zu vereinbaren, die nicht in seinem unmittelbaren Einflussbereich liegen. OLAs sind Vereinbarungen über das Qualitätsniveau von Dienstleistungen, welche ein IT-Bereich bei einer anderen Struktureinheit des gleichen Unternehmens in Auftrag gibt (z. B. eine Vereinbarung zwischen IT- und Einkaufsabteilung über die maximale Zeitdauer für die Beschaffung bestimmter Hardwareeinheiten von externen Lieferanten). Ein Underpinning Contract ist ein Vertrag zwischen ITDienstleister und einem oder mehreren externen Lieferanten (z. B. Beratern, Hardwarelieferanten, Softwarehäusern), in dem unter anderem Qualitätsniveaus der IT-Dienstleistungen vereinbart werden, die von einem externen Anbieter Service Level Requirement bezogen werden (z. B. Verfügbarkeit von Anwendungen, die von einem OutService Level Agreement sourcing-Dienstleister betrieben werden). Abbildung SEVER-2 ordnet SLAs in den Kontext von SLRs, Underpinning Contract Operational Level Agreement OLAs und Underpinning Abb. SEVER-2: Kontext von SLAs Contracts ein.

Entwickeln von SLAs

Verschiedene Rückkopplungen

Die Vereinbarung von Serviceebenen ist ein kooperativer Prozess. Die für diesen Prozess erforderliche Kompetenz muss bei Dienstleistungsnehmern meist erst aufgebaut werden, während Dienstleistungsgeber aus Erfahrung häufiger darüber verfügen, weil bereits ihr Dienstleistungsangebot nach Form und Identifikationsphase Inhalt den Charakter von SLAs hat. Dienstleistungsgeber müssen und können Vorschlags- und Abstimmphase daher Vorleistungen erbringen (z. B. einen Vorschlag unterbreiten, der mit potenziellen Dienstleistungsnehmern abgeImplementierungsphase stimmt und dann vereinbart wird). Muster für SLAs werden im IT-Servicekatalog Einführungsphase (vgl. Lerneinheit SEMAN) beschrieben, konkrete Vereinbarungen über QualitätsWartungsphase niveaus für Dienstleistungen werden in einem Vertrag oder einer vertragsähnliAbb. SEVER-3: Phasenmodell Entwicklungsprozess SLA chen Vereinbarung zwischen Dienstleister

Serviceebenen-Vereinbarungen (SEVER)

501

und Kunden dokumentiert. Abbildung SEVER-3 zeigt ein von Heinrich/Riedl entwickeltes Phasenmodell für den Entwicklungsprozess; jede Phase umfasst die Feinplanung für die Folgephase. Identifikationsphase: Ziel dieser Phase ist es, den Dienstleistungsprozess mit allen beteiligten Organisationseinheiten und verantwortlichen Personen bei beiden Partnern und die Rolle dieser Personen im Dienstleistungsprozess zu erfassen. Dies schließt die Zuordnung von Aufgaben und Verantwortungen auf die Partner und damit die Festlegung der Schnittstellen zwischen ihnen ein. Neben dieser Rollenverteilung ist auch festzulegen, welche Personen die zur Definition der SLAs notwendigen Entscheidungen treffen sollen. Dies setzt ein klares Bild darüber voraus, für welche Aufgaben die Verwendung von SLAs überhaupt sinnvoll ist. Vorschlags- und Abstimmphase: Ziel dieser Phase ist es, die zur Planung, Überwachung und Steuerung der Dienstleistungsprozesse erforderlichen Kennzahlen zu definieren. Dazu werden zunächst vom potenziellen Dienstleistungsnehmer SLRs formuliert. Dabei ist folgender Zusammenhang zu beachten: Je höher die geforderte Serviceebene ist, desto geringer wird zwar das Risiko des Mangels an Unterstützung, desto höher werden aber die Kosten. Bei der Transformation von SLRs in Serviceebenen-Kennzahlen ist zu entscheiden, welche Kennzahlentypen verwendet werden sollen sowie ob und wie die Kennzahlen zu einem Kennzahlensystem (vgl. Lerneinheit KENNZ) geordnet werden können. Auf Grundlage der SLRs und mit den definierten Serviceebenen-Kennzahlen werden potenzielle Dienstleistungsgeber mit einer Ausschreibung zur Abgabe von Angeboten aufgefordert. Diese Phase soll auch dazu benutzt werden, die in den SLRs verwendeten Bezeichnungen für Kennzahlen (wie Antwortzeit, Verfügbarkeit, Stillstandzeit) eindeutig zu klären (z. B. durch ein der Ausschreibung beigefügtes Glossar), da sie erfahrungsgemäß von den Beteiligten nicht einheitlich verwendet werden. Implementierungsphase: Ziel dieser Phase ist es, die Serviceebenen der SLAs (vgl. die Beispiele im Abschnitt Leistungsumfang von SLAs), die für ihre Messung erforderlichen Messgrößen und die zur Messung vorgesehenen Messmethoden und Werkzeuge festzulegen und die zu ihrer Einführung und Nutzung erforderlichen Serviceebenen-Managementprozesse zu definieren. Alles zusammen ist durch die zuständigen Linieninstanzen zu verabschieden (z. B. durch das Management des IT-Bereichs und das Linienmanagement der betroffenen Fachbereiche) und damit verbindlich zu machen. Die erforderlichen Ressourcen (insbesondere Personal und Betriebsmittel) und Budgets müssen bereitgestellt werden. Über die Methode, mit der IT-Dienstleistungen verrechnet werden (vgl. Lerneinheit KOLER), muss ebenfalls entschieden werden. Bei der Entscheidung über die Serviceebenen soll beachtet werden, welche IT-Dienstleistungen bzw. von diesen benutzten Ressourcen (z. B. Personal) erfahrungsgemäß typische Kostentreiber sind. Es kann aus Kostengründen notwendig sein, die Serviceebenen geringer anzusetzen als zunächst beabsichtigt. Einführungsphase: Ziel dieser Phase ist es, die SLAs und die Serviceebenen-Managementprozesse produktiv nutzbar zu machen. Zur Vermeidung von Überforderung (insbesondere beim Dienstleistungsnehmer) und zur Förderung der Wirkung von Erfolgen wird eine rollierende Einführung empfohlen, bei der – von wenigen SLAs in Problembereichen ausgehend – sukzessiv vertieft und erweitert wird. Dies fördert die Akzeptanz der SLAs und das Wachsen der Servicekultur. Zu dieser Phase gehört auch die Bekanntmachung der SLAs gegenüber

502

Methoden des administrativen Informationsmanagements

den Benutzern so, dass sie verstanden werden und danach gehandelt werden kann. Ein Werkzeug, das als Informationsplattform dient und die SLAs objektiv, einfach und verständlich einschließlich der jeweils aktuellen Werte der Serviceebenen darstellt, ist hilfreich. Wartungsphase: Ziel dieser Phase ist es, die SLAs und die Serviceebenen-Managementprozesse zu verbessern und an veränderte Bedingungen (z. B. Technologiewechsel) und Anforderungen (z. B. Veränderung von Geschäftsprozessen) anzupassen. Die Erfahrung zeigt, dass bereits relativ kurze Zeit nach Einführung von SLAs Anpassungen erforderlich werden. Zum rechtzeitigen Erkennen des Anpassungsbedarfs werden in den ServiceebenenManagementprozessen Audits und Reviews (vgl. Lerneinheit MEQUA), beispielsweise zur Messung der Kundenzufriedenheit, und Benchmarks zum Vergleich mit best practices vorgesehen. Diese werden für bestimmte Zeitpunkte (etwa jeden Monat) oder bei Eintreten bestimmter Ereignisse (z. B. Verletzung von Schwellenwerten der Soll/Ist-Abweichungen) vereinbart. Dies weist darauf hin, dass nicht nur die SLAs, sondern auch die ServiceebenenManagementprozesse flexibel gestaltet sein müssen, um mit möglichst geringem finanziellen Aufwand und in kurzer Zeit an die veränderten Bedingungen angepasst werden zu können.

Nutzenpotenzial von SLAs Bei Differenzierung der verschiedenen, am Dienstleistungsprozess beteiligten Partner können folgende Kategorien von Nutzenpotenzialen genannt werden: 







Externer Dienstleistungsgeber (Outsourcing-Geber): Erhält klare Leistungsdefinitionen vom Auftraggeber; hat klare Ziele für das Schnittstellenmanagement zum Auftraggeber; kann Kapazitäten, Kosten und Erlöse besser planen; Mitarbeiter erhalten mehr Transparenz über von ihnen erbrachte Leistungen; hat eine klare Grundlage für das Lösen von Konflikten. Dienstleistungsnehmer IT-Bereich: Kennt das Minimum der vom Auftragnehmer zu erwartenden Leistungen; hat klare Ziele für das Schnittstellenmanagement zum Auftragnehmer; kann Kapazitäten und Kosten besser planen; hat eine klare Grundlage für das Lösen von Konflikten. Dienstleistungsgeber IT-Bereich: Kann seine Wertigkeit und sein Image im Unternehmen verbessern; schafft mehr Transparenz über Leistungen für Kunden; erreicht, dass die gemeinsam definierten und vereinbarten Leistungen von beiden Partnern akzeptiert und getragen werden; kann Kapazitäten und Kosten besser planen; kann sich mit externen Benchmarking-Partnern (besser) vergleichen; hat eine klare Grundlage für das Lösen von Konflikten. Interne Dienstleistungsnehmer: Erhalten mehr Transparenz über Leistungen; können ihre Anforderungen besser formulieren; können IT-Kosten besser planen; können sich als Kunden des IT-Bereichs verstehen; können die Leistungen des IT-Bereichs besser mit denen externer Dienstleister vergleichen; können ihre Anforderungen besser auf wirklich notwendige Dienstleistungen fokussieren.

Ob und in welchem Ausmaß es gelingt, das Nutzenpotenzial auszuschöpfen, das sich positiv auf den Unternehmenserfolg auswirkt, hängt von zahlreichen, oft kaum quantifizierbaren Einflussfaktoren ab (z. B. Kommunikationsklima zwischen den Partnern).

Serviceebenen-Vereinbarungen (SEVER)

503

Forschungsbefunde Grütter/Schwabe/Aschoff beschreiben die Ergebnisse einer Befragung zum IT-Servicemanagement in der Schweiz (Datenerhebung durch Online-Befragung ergänzt durch Befragungen während Workshops zum Thema IT-Servicemanagement und Telefoninterviews, 95 von Kunden und 121 von Anbietern von IT-Dienstleistungen beantwortete Fragebögen, 91 auswertbare Antworten von Kunden und 116 von Anbietern, Untersuchungszeitraum Februar bis März 2005). Zwei Forschungsfragen sollten beantwortet werden:  

Wie beurteilen Anbieter und Nachfrager die Qualität von IT-Leistungen und wo sind die größten Unterschiede? Welchen Einfluss haben die verschiedenen Einflussfaktoren auf die Dienstleistungsqualität?

Der Befragung lag ein Modell zugrunde, in dem Dienstleistungsqualität mit 14 Einflussfaktoren beschrieben wird: Kundenbetreuung, Termintreue, SLA- und Vertragsmanagement, Qualitätssicherungsmaßnahmen, Risiko- und Sicherheitsmanagement, Effizienz der ITProzesse, Effektivität der IT-Prozesse, Servicepreise / Kosten, Hardware-Betrieb und Wartung, Applikationsbetrieb und Wartung, Leistungen des User-Help-Desks, Problembehandlung und -lösung, Change Management und Software-Engineering. Gefragt wurde nach der wahrgenommenen Dienstleistungsqualität aus Kundensicht (Wie bewerten Kunden die Dienstleistungsqualität?) und nach der erwarteten Dienstleistungsqualität aus Anbietersicht. (Welche Bewertung der Dienstleistungsqualität durch die Kunden erwarten die Anbieter?)     

Anbieter beurteilen die Dienstleistungsqualität auf einer vorgegebenen Notenskala (von 1 = unbrauchbar bis 6 = sehr gut) im Mittel mit 4,99 (= gut); die Einschätzung der Kunden lag nur unwesentlich schlechter bei 4,71 (= gut). Die höchsten Noten von den Anbietern erhielten die Items Kundenbetreuung (4,98), Problembehandlung und -lösung (4,96) sowie Leistungen des User-Help-Desks (4,89). Am schlechtesten wurden von den Anbietern die Items Effizienz der IT-Prozesse (4,60), Qualitätssicherungsmaßnahmen (4,55) sowie Risiko- und Sicherheitsmanagement (4,53) beurteilt. Die besten Noten von den Kunden erhielten die Items Leistungen des User-Help-Desks (4,74); Problembehandlung und -lösung (4,64) sowie Hardware-Betrieb und Wartung (4,63). Am schlechtesten wurden von den Kunden die Items Risiko- und Sicherheitsmanagement (4,19), Servicepreis / Kosten (4,19) sowie Qualitätssicherungsmaßnahmen (4,02) beurteilt.

Mit einer Regressionsanalyse wurde ermittelt, welche Einflussfaktoren den größten Einfluss auf die generelle Beurteilung der Servicequalität haben. Für die Anbieter ergibt sich ein statistisch signifikanter Zusammenhang zwischen den Items Effektivität der IT-Prozesse sowie Termintreue und der erwarteten Dienstleistungsqualität, für die Kunden zwischen Kundenbetreuung, SLA- und Vertragsmanagement sowie Servicepreise / Kosten und der wahrgenommenen Dienstleistungsqualität.

504

Methoden des administrativen Informationsmanagements

Berger analysierte mit einer explorativen Erhebung (schriftliche Befragung von 122 Mitarbeitern aus Unternehmen, die SLAs für Dienstleistungen im IT-Systembetrieb einsetzten oder deren Einsatz planten, Untersuchungszeitraum 1999 bis 2001) die Verwendung von SLAs im Zusammenhang mit dem Betrieb von Informationssystemen in deutschen Unternehmen. Die von den Teilnehmern am häufigsten genannten Gründe für den Einsatz von SLAs sind:    



mangelnde Leistungstransparenz bzw. unzureichende Definition der zu erbringenden Leistungen, mangelnde Kostentransparenz, unzureichend definierte Verantwortlichkeiten, mangelnde Definition von Ansprechpartnern, mangelnde Definition der Schnittstelle zwischen Kunde und Dienstleister, mangelnde Definition der Rechte und Pflichten von Kunde und Dienstleister, unrealistische Einschätzungen der Nutzer in Bezug auf Leistungen und deren Kosten, Schließung der Lücke zwischen Erwartungen von Nutzern und der tatsächlichen Leistungsfähigkeit der IT, Begrenzung von überzogenen, unrealistischen Kundenerwartungen/-anforderungen sowie mangelnde Kundenzufriedenheit.

Ziele des Einsatzes von SLAs sind:    

Verbesserung der Kundenzufriedenheit, Reduktion von Konflikten zwischen Kunde und Dienstleister, Verbesserung der Leistungstransparenz und Sicherstellung der erforderlichen und vereinbarten Dienstleistungsqualität.

Auf die Frage nach Problemen im Zusammenhang mit der Erstellung von SLAs wurden die drei folgenden – aus einer Liste von zehn vorgegebenen – Antworten am häufigsten gewählt:   

Bemessung von Konsequenzen bei Abweichungen von Service-Levels ist sehr schwierig. Exakte Definition der Kennzahlen ist sehr schwierig. Festlegung / Vereinbarung der Service-Levels ist sehr schwierig.

Auf die Frage nach der Art der IT-Dienstleistungen im Systembetrieb, die mit SLAs geregelt werden, wurden folgende Dienstleistungen am häufigsten genannt:    

User-Help-Desk, Betrieb von Netzwerken: WAN, LAN, Desktopmanagement: Bereitstellung, Vor-Ort-Service, Softwareverteilung etc. sowie Betrieb von Servern: Hardware und Betriebssystem sowie Anwendungen.

Folgendes typische Profil von IT-Dienstleistungen, die mit SLAs geregelt werden, wurde ermittelt:   

eher technische und leicht standardisierbare Dienstleistungen, regelmäßige Inanspruchnahme durch den Kunden, hohe Relevanz für den Kunden und dementsprechend hohe Ausfallkosten bei nicht vereinbarungsgemäßer Erbringung der Dienstleistungen.

Serviceebenen-Vereinbarungen (SEVER)

505

Als positive Auswirkungen der Verwendung von SLAs wurden am häufigsten genannt:      

Förderung des Servicegedankens beim Dienstleister, Verbesserung des Qualitätsmanagements beim Dienstleister, Förderung eines partnerschaftlichen Verhältnisses zwischen Kunde und Dienstleister, Sicherstellung der Erbringung der vereinbarten Dienstleistungsqualität, Verbesserung der Leistungstransparenz und Verbesserung der Kenntnisse beim Dienstleister über die tatsächlichen Anforderungen des Kunden.

Auffällig ist, dass die beiden hauptsächlich verfolgten Ziele (Verbesserung der Kundenzufriedenheit und Verringerung der Konflikte zwischen Kunde und Dienstleister) nicht zu den am häufigsten genannten Merkmalen gehören, bei denen positive Auswirkungen durch den Einsatz von SLAs festzustellen sind. Sie belegen lediglich mittlere Plätze bei der Anzahl der Nennungen der positiven Auswirkungen. Als Nachteile des Einsatzes von SLAs wurden genannt:   

hoher Aufwand für das Management von SLAs (Überwachung, Anpassung), Interpretation von SLAs wirft Probleme auf (Schwierigkeit, exakte Formulierungen für IT-Dienstleistungen und zugehörige Service-Levels zu finden) und hoher Aufwand für die Erstellung von SLAs.

Aus der Praxis Herrmann/Müller beschreiben die Einführung von SLAs im Kontext von BusinessIntelligence-Leistungen bei T-Mobile Deutschland. Diese BI-Services stellen „eine spezifische Ausprägung von IT-Services dar, die in erster Linie relevante Informationen für Entscheider bereitstellen“ (235). Bei T-Mobile Deutschland werden folgende Gruppen von BIServices unterschieden: Unterstützung des operativen Geschäfts (z. B. Informationsbereitstellung zur Kundenrückgewinnung oder zum täglichen Personaleinsatz im Callcenter), Unterstützung geschäftskritischer Berichtsprozesse (z. B. Informationen zum Monats-, Quartalsoder Jahresabschluss), Standardinformationen für nicht unternehmenskritische taktische oder operative Aufgaben für eine große Nutzerzahl (z. B. Informationen zur Entwicklung der Neukundengewinnung und zum Verkauf neuer Produkte), Individualauswertungen mit geringer Nutzerzahl (z. B. Ad-hoc-Berichte in Form von Sonderauswertungen zu Einzelprodukten oder Bereitstellung bestimmter „Rohinformationen“ für das Database-Marketing). Da die BI-Services sehr unterschiedlich sind, werden verschiedene SLAs benötigt, um die vielfältigen Anforderungen angemessen abbilden zu können. Die vereinbarten SLAs charakterisieren BI-Services anhand des Einsatzzwecks, der unterstützten Nutzungsprozesse, der inhaltlich notwendigen Themenbereiche sowie der Kritikalität. Qualitätsparameter legen fest, welches Qualitätsniveau die Bestandteile von BI-Services erfüllen müssen. Bei T-Mobile Deutschland haben sich die folgenden „aus Kundensicht wichtigsten und praxistauglichsten Qualitätseigenschaften herauskristallisiert“ (240):  

Aktualität eines Informationsobjekts beschreibt, welchen Aktualitätsstand die zuletzt dem Objekt hinzugefügten Informationen haben. Vollständigkeit bezeichnet den fachlichen Umfang der Informationen in einem Objekt.

506

 

Methoden des administrativen Informationsmanagements

Korrektheit beschreibt die fachliche Richtigkeit von Informationen. Leistungsverhalten kennzeichnet die Geschwindigkeit der Rückmeldung an die Nutzer und ist nur für interaktive Analysemöglichkeiten relevant.

Aufgabenverweise Qualitätsmanagement (Lerneinheit QUALM); Vertragsmanagement (Lerneinheit VERMA); Servicemanagement (Lerneinheit SEMAN); Infrastrukturmanagement (Lerneinheit INMAN). Kontrollfragen 1. Warum sollte ein IT-Dienstleister SLAs mit seinen Kunden vereinbaren? 2. Aus welchen Inhalten bestehen SLAs und welche Kennzahlen beschreiben typische Inhalte von SLAs? 3. Welches sind wesentliche Phasen der Entwicklung von SLAs? 4. In welchem Zusammenhang stehen SLRs, SLAs und OLAs? 5. Warum sind SLAs für Outsourcing-Nehmer beim Cloud-Computing von besonderer Bedeutung? Quellen Berger, T. G.: Service-Level-Agreements: Konzeption und Management von Service-Level-Agreements für ITDienstleistungen. Saarbrücken 2007 Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz-Kataloge 2009. http://www.bsi.de; Abruf 27. Juni 2011 Grütter, R. / Schwabe, G. / Aschoff, F.-R.: Qualität von IT-Leistungen aus den Perspektiven von Anbietern und Nachfragern. Ergebnisse einer Umfrage in der Schweiz. In: Oberweis, A. et al. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering. 8. Internationale Tagung Wirtschaftsinformatik Karlsruhe, Bd. 1. Karlsruhe 2007, 365–382 Heinrich, L. J. / Riedl. R.: Phasenmodell zur Entwicklung von Serviceebenen-Vereinbarungen. In: HMD – Praxis der Wirtschaftsinformatik 231/2003, 88–96 Herrmann, C. / Müller, S.-A.: Business Intelligence Services bei T-Mobile Deutschland: Service Level Agreements und servicebezogenes Datenqualitätsmanagement zur kundengerechten Leistungserbringung. In: Dinter, B. et al. (Hrsg.): DW2008. Synergien durch Integration und Informationslogistik. 27./28.10.2008 in St. Gallen, Switzerland. Lecture Notes in Informatics (LNI) - Proceedings. Bonn 2008, 229–248 IT Governance Institute (Hrsg.): CobiT 4.1: Framework, Control Objectives, Management Guidelines, Maturity Models. Rolling Meadows 2007 Rudd, C. / Lloyd, V.: Service Design (ITIL), Version 3. London 2007 Vertiefungsliteratur Bernhard, M. G. et al. (Hrsg.): Praxishandbuch Service-Level-Management: Die IT als Dienstleistung organisieren. 2. A., Düsseldorf 2006 Eicker, S. / Heimann, E. / Bucksteeg, M.: Kostenabhängigkeitsbetrachtung für Service Levels von Managed Desktop Services am Beispiel der Verfügbarkeit. In: Bichler, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 951–962 Kronz, A. / La Greca, C. / Kaffai, B.: Prozessorientiertes Service Level Management. In: Lehner, F. / Nösekabel, H. / Kleinschmidt, P. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2006. Tagungsband 1. Berlin 2006, 35–46 Patel, P. / Ranabahu, A. / Sheth, A.: Service Level Agreement in Cloud Computing. In: Proceedings of the Workshop on Best Practices in Cloud Computing: Implementation and Operational Implications for the Cloud at ACM International Conference on Object-Oriented Programming, Systems, Languages, and Applications, Orlando, 2009. New York 2009, o. S. Informationsmaterial Karten, N.: Service Level Agreement Resources http://www.ServiceLevelAgreements.com Keller-Stoltenhoff, E.: SLA aus rechtlicher Sicht. Vertragliche Regelung wiederkehrender IT-Dienstleistungen http://www.gulp.de/kb/lwo/vertrag/servicelevelagreement.html Symposion Publishing GmbH: Dossier Service-Level-Management http://www.symposion.de/slm Normen ISO 9000:2005 Qualitätsmanagementsysteme – Grundlagen und Begriffe ISO 9001:2008 Qualitätsmanagementsysteme – Anforderungen ISO/IEC 20000-1:2005. Information Technology – Service Management – Part 1: Specification ISO/IEC 20000-2:2005. Information Technology – Service Management – Part 2: Code of Practice

F. FALLSTUDIEN DES INFORMATIONSMANAGEMENTS

strategische Ebene

administrative Ebene

operative Ebene

Grundlagen des Informationsmanagements

Methoden des Informationsmanagements

Aufgaben des Informationsmanagements

Fallstudien Informationsmanagement

508

Fallstudien des Informationsmanagements

Gegenstand dieses Kapitels sind vier Fallstudien zum Informationsmanagement. Das verwendete Material stammt aus Projekten, die von den Autoren – gemeinsam mit anderen Projektbearbeitern – durchgeführt wurden. Wie die Bezeichnung der Fallstudien zum Ausdruck bringt, wurden mit den Projekten typische Aufgaben des Informationsmanagements in der Praxis bearbeitet. Das umfangreiche Projektmaterial musste für die Darstellung in diesem Lehr- und Handbuch stark gekürzt werden. Trotzdem sind in jeder Fallstudie das bearbeitete Problem erkennbar, der Lösungsweg vom Problem zum Ergebnis nachvollziehbar und das Ergebnis verständlich dargestellt. Soweit Publikationen zu den Fallstudien vorliegen, werden sie angegeben. Von Mag. Dr. Katharina Steininger und Mag. David Rückel, Institut für Wirtschaftsinformatik – Information Engineering der Johannes Kepler Universität Linz, stammt das Manuskript der Fallstudie Dokumentenmanagementsystem (FSDOK). Das Manuskript der Lerneinheit Fallstudie Erfolgsfaktorenanalyse (FSERF) lieferte Dr. René Riedl, Institut für Wirtschaftsinformatik – Information Engineering der Johannes Kepler Universität Linz. Kirsten Oßmann hat die Daten für die Lerneinheit Fallstudie Lebenszyklusmanagement (FSLEM) zusammengestellt. Das Manuskript für die Lerneinheit Fallstudie Geschäftsprozessmanagement (FSGPM) erarbeitete Dr. Daniel Fischer, Fachgebiet Informations- und Wissensmanagement der TU Ilmenau.

Fallstudie Dokumentenmanagement (FSDOK) ................................................................... 509 Fallstudie Erfolgsfaktorenanalyse (FSERF)......................................................................... 521 Fallstudie Lebenszyklusmanagement (FSLEM) .................................................................. 533 Fallstudie Geschäftsprozessmanagement (FSGPM) ............................................................ 545

Fallstudie Dokumentenmanagement (FSDOK) Ausgangssituation BRP-Powertrain ist ein Unternehmen der Bombardier Recreational Products Inc. (BRP) mit Fertigungsstätten in Österreich und Mexiko (www.rotax.com/de). Das Unternehmen ist internationaler Marktführer in der Entwicklung und Herstellung von 2-Takt- und 4-TaktHochleistungsmotoren, welche als Antrieb von motorisierten Freizeitgeräten wie Schneeschlitten, Geländefahrzeugen, Sportbooten, Aufsitzbooten, Motorrädern, Roadster, Karts sowie Leichtflugzeugen verwendet werden. Am Standort Österreich beschäftigte BRPPowertrain zum Untersuchungszeitpunkt im Jahr 2007 etwa 1.200 und BRP weltweit etwa 6.200 Mitarbeiter. In der IT-Landschaft der BRP-Powertrain waren zu diesem Zeitpunkt Windows XP, Windows Server 2003, Linux und echte Unix-Derivate als Betriebssysteme, SAP 4.7, Microsoft Office 2003, Microsoft Outlook 2003, Adobe-Produkte sowie branchenspezifische Systeme wie ProEngineer im Einsatz. Außerdem wurden SQL-Server, MySQL und Informix als Datenbankserver sowie Active Directory als Verzeichnisdienst verwendet. Anfang des Jahres 2007 fiel am Standort Österreich die Entscheidung, die interne Kommunikation und Zusammenarbeit durch die Einführung eines Enterprise-Content-ManagementSystems (ECMS) zu unterstützen, um damit den Workflow zu verbessern. Aufgrund der im Unternehmen bestehenden IT-Landschaft wurde OpenText Content Server (ursprünglich Open Text Livelink, www.opentext.de) als ECMS ausgewählt. In einem ersten Schritt sollte von dem umfangreichen Funktionsangebot (siehe unten) zunächst nur am österreichischen Standort das Modul Dokumentenmanagement umgesetzt werden. Nach erfolgreicher Evaluierung sollte die Integration des Informationssystems BRP-weit erfolgen. Das Material der vorliegenden Fallstudie stammt aus dem Projekt „Strategie zur Einführung des OpenText Enterprise-Content-Management-Systems bei der BRP-Powertrain“, das im Jahr 2007 am Institut für Wirtschaftsinformatik - Information Engineering der Johannes Kepler Universität Linz durchgeführt wurde. Ergebnisse des Projekts wurden in der Zeitschrift HMD – Praxis der Wirtschaftsinformatik veröffentlicht.

Problemstellung Die Einführung eines ECMS bedarf einer strategischen Planung und erfolgt üblicherweise in mehreren Phasen über Jahre hinweg. Diese lange Einführungsdauer kann unter anderem auf folgende Faktoren zurückgeführt werden: die Langlebigkeit des ECMS und der darin gepflegten Dokumente im Unternehmen (oftmals gibt es für Dokumente lange, gesetzlich bedingte Aufbewahrungsfristen), die Komplexität der Integration in die bestehende ITLandschaft sowie die ausgeprägte Verzahnung von Dokumenten und Geschäftsprozessen. Da aus den meisten intern eingesetzten Software-Systemen heraus Dokumente generiert werden

510

Fallstudien des Informationsmanagements

(z. B. Fakturen aus SAP) und viele externe Dokumente zu Geschäftsvorfällen in bestehenden Systemen führen (z. B. Bestellscheine), ist es notwendig, kritische Systeme zumindest logisch, besser aber auch technisch in das ECMS zu integrieren. Die Einführung und Nutzung eines ECMS führt – so wie auch die Einführung und Nutzung anderer Systeme (z. B. Enterprise Resource Planning) – zu Veränderungen bei den Geschäftsprozessen. Insbesondere in der Einführungsphase ist daher für Anwender ein hoher Umstellungs- und Lernaufwand zu erwarten. Risiken, die mit der Einführung eines ECMS verbunden sind, können reduziert werden, indem man sich mit den Strukturen und Prozessen im Unternehmen auseinandersetzt, um eine Einführungsstrategie zu entwickeln. Die Adaption eines ECMS an die individuellen Gegebenheiten ist ein kritischer Erfolgsfaktor. Eine solche Adaption umfasst neben funktionalen Anpassungen auch so genannte nichtfunktionale Anpassungen wie beispielsweise Integration in die bestehende IT-Landschaft, Adaption von Benutzeroberflächen oder Art der Migration.

Ziel der Untersuchung Um eine möglichst wirtschaftliche Einführung und hohe Wirksamkeit bei der Nutzung des ECMS sicherzustellen, lag das Ziel der Untersuchung darin, eine Einführungsstrategie für das ECMS OpenText Content Server zu entwickeln. Insbesondere war dafür zu ermitteln   

welche aufbau- und ablauforganisatorischen Rahmenbedingungen, Verantwortungsbereiche, Geschäftsprozesse von einem ECMS betroffen waren, welche Dokumententypen, Dokumentenstrukturen und Dokumentenflüsse vorlagen, welche technischen Möglichkeiten das ausgewählte ECMS bot bzw. welche Restriktionen zu beachten waren.

Aufbauend auf den Antworten zu diesen Fragen wurde eine Einführungsstrategie für das Produkt OpenText Content Server bei BRP-Powertrain entwickelt.

Untersuchungsdesign Die Untersuchung wurde in Phasen strukturiert. In der Phase Vorstudie erfolgte die Identifikation der Rahmenbedingungen, die Projektplanung und die Auswahl von Beteiligten für die weiteren Projektphasen. In der Phase Feinstudie wurden die empirischen Daten für die Einführungsstrategie gewonnen. Diese Phase gliedert sich in eine Organisationsanalyse und in eine Softwareanalyse. In der Phase Konzeptionierung erfolgte die Ableitung eines Vorgehensmodells und konkreter Strategieobjekte für die Einführung des ECMS im Unternehmen. Schließlich wurde in der Phase Pilotierung das Vorgehensmodell evaluiert. Die empirischen Daten der Organisationsanalyse wurden in Workshops mit leitenden Angestellten, mit elektronischer Befragung von weiteren Mitarbeitern sowie Interviews mit Mitarbeitern aus betroffenen Abteilungen gewonnen. Die Einführungsstrategie wurde mit der in der Lerneinheit VOMOD aufgezeigten Vorgehensweise in Anlehnung an das phasenbasierte Wasserfallmodell entwickelt. Dabei wurde von der konkreten Anwendung in der Softwareentwicklung abstrahiert und die Aufgaben, Methoden und Techniken der einzelnen Phasen sowie Rückkopplungen zu vorherigen Phasen definiert.

Fallstudie Dokumentenmanagement (FSDOK)

511

Bezugsrahmen Wer in einem Unternehmen welches Wissen wann braucht und wie dieses Wissen zielgerichtet zur Verfügung steht, sind die zentralen Fragen der Wissensverteilung, einer der acht Aufgaben des Wissensmanagements. Dieses Wissen unter Vermeidung eines zu hohen Aufwandes zu transportieren und zu liefern ist die zentrale Herausforderung. Die Reduktion von Barrieren, beispielsweise die fehlende Kenntnis über die Existenz relevanten Wissens, ist essentiell für die Wissensnutzung, einer weiteren Aufgabe des Wissensmanagements. Die Wissensbewahrung hat zum Ziel, für das Unternehmen relevantes Wissen nicht zu verlieren, etwa durch Zerstörung, Nichtauffindbarkeit, Vergessen oder Ausscheiden eines Mitarbeiters. Teilaufgaben der Wissensbewahrung sind die Selektion bewahrungswürdigen Wissens sowie die Aufbereitung, Dokumentation, Indizierung, Speicherung, Aktualisierung und kontrollierte Löschung (vgl. Lerneinheit WIMAN). Dokumente und deren Metadaten (z. B. Ersteller, Rolle des Dokuments in anderen Systemen, Lebenszyklus, Aufbewahrungsfrist) sowie deren Inhalt (Content) sind eine Form von Wissen. ECM stellt als Erweiterung des klassischen Dokumentenmanagements die Inhalte von Dokumenten in den Mittelpunkt. ECMS bieten folgende Kernfunktionalitäten: (i) Erfassung des Inhalts von Dokumenten, (ii) seine Verwaltung, (iii) Speicherung, (iv) Bewahrung und (v) Bereitstellung. Wesentliche Eigenschaft von ECM ist die Integration von strukturierter, halb-strukturierter und unstrukturierter Information (vgl. Lerneinheit DATEM) sowie deren Metadaten in einem System. Ziele beim Einsatz eines ECMS sind: Verbesserung der internen und externen Zusammenarbeit, Steigerung von Zuverlässigkeit und Qualität, Minderung von Fehlern bei der Handhabung von Informationen sowie Steigerung der Effizienz. Durch die genannten Kernfunktionalitäten und die Erweiterung durch die Hinterlegung von vorgegebenen Workflows, wie beispielsweise Genehmigungsprozessen, bietet ein solches System eine technologische Grundlage für Wissensverteilung, Wissensnutzung und Wissensbewahrung (vgl. Lerneinheit MEWIM). Die wirksame Nutzung eines ECMS kann nur bei einer effektiven Einführung gewährleistet werden. Dies resultiert aus der Tatsache, dass für die wirksame und wirtschaftliche Nutzung eines ECMS (vgl. Lerneinheit ERMOD) der Aufbau einer entsprechenden Organisation im Unternehmen notwendig ist, die sich aus ablauf- und aufbauorganisatorischen Regelungen sowie der bestehenden Informationsinfrastruktur definiert. Zu diesem Zweck wurden zehn Strategieobjekte für die erfolgreiche Einführung eines ECMS entwickelt.

Ablauf der Untersuchung Die Untersuchung wurde zwischen März und Juli 2007 durchgeführt.

Datenerhebung Bevor die Einführungsstrategie für das ECMS erarbeitet werden konnte, wurde eine dreistufige Ist-Zustandsanalyse – bestehend aus Workshop im Rahmen der Vorstudie sowie elektronischer Befragung und persönlichen Interviews im Rahmen der Feinstudie – durchgeführt. Ziel dieser empirischen Datenerhebung war es, die organisatorischen und technischen Rah-

512

Fallstudien des Informationsmanagements

menbedingungen hinsichtlich Aufbau- und Ablauforganisation, Verantwortungsbereiche, kritischer Geschäftsprozesse, Dokumentenflüsse sowie Dokumentenstruktur zu erheben. In der Phase Vorstudie wurden in einem Workshop mit IT-Leiter und ECMS-Projektleiter von BRP-Powertrain sowie einem externen Projektbegleiter der Projektablauf, die organisatorischen Rahmenbedingungen sowie die Aufbau- und Ablauforganisation der BRPPowertrain besprochen. In der Gruppendiskussion wurde die Notwendigkeit zur Entwicklung einer individuellen Einführungsstrategie festgestellt. Für die folgenden Phasen der elektronischen Befragung sowie der Interviews wurden Adressaten bzw. Gesprächspartner ausgewählt. In der Phase Feinstudie erfolgte zunächst eine elektronische Befragung. Es wurden zwölf Fragebögen an nicht leitende Mitarbeiter in sechs Abteilungen am Standort Österreich versendet. Die Abteilungen wurden mit dem Ziel ausgewählt, eine möglichst hohe Anzahl heterogener Bereiche zu berücksichtigen (PE – Produktentwicklung, PM – Programmmanagement, EK – Einkauf, AK – Aggregate Konstruktion, QS – Qualitätssicherung, BI – Betriebstechnik und Instandhaltung). Die Ziele dieser Befragung waren (i) Identifikation verwendeter Dokumenttypen und Dateiformate, (ii) Umgang bei Archivierung von und Suche nach Dokumenten zu erfragen, (iii) Umfang und Modus abteilungsübergreifender Dokumentenbearbeitung festzustellen sowie (iv) Besonderheiten hinsichtlich Medienbrüchen, Berechtigungen, Aufbewahrungspflichten und Mehrsprachigkeit von Dokumenten zu erkennen. Im Anschluss an die Auswertung der Fragebögen wurden Interviews mit insgesamt vierzehn Mitarbeitern aus den oben genannten Abteilungen durchgeführt. Nach der Transkription erfolgte eine inhaltsanalytische Untersuchung, um weiterführende Informationen über (i) Dokumenttypen und -formaten, (ii) Dokumentenaustausch innerhalb der und zwischen den Abteilungen, (iii) Gewohnheiten bei der Erzeugung, Speicherung, Änderung, Weiterleitung und Archivierung von Dokumenten, (iv) Art und Ursachen von Medienbrüchen, (v) gesetzliche und konzerninterne Aufbewahrungspflichten, (vi) Berechtigungs- und Speicherverwaltung sowie (vii) Mehrsprachigkeit zu gewinnen. Parallel dazu fand die Softwareanalyse von OpenText Content Server statt. Dazu wurde nach einer Produktdemonstration ein Testsystem installiert und hinsichtlich der geforderten Funktionalitäten evaluiert.

Auswertung In einem ersten Schritt werden die Ergebnisse der Organisationsanalyse erläutert. Folgende, regelmäßig verwendete Dokumenttypen wurden identifiziert: Protokoll, Projektplan, Pflichtenheft, Mastergateplan, Product Design Review, Audit Product Design Review, Projekt/Stück-/Bestellliste, Bestellanforderung, Angebot, Vertrag, Konstruktionszeichnung, Lieferpapier, Rechnung und Korrespondenz (E-Mail). Diese Dokumente lagen in folgenden Formaten vor: Microsoft-Office-Formate, Adobe-Formate, CAD-Dateien, Bild-, Audio- und Video-Formate, MindJet-MindManager-Dateien, NC-Programmdateien. Die Hälfte der elektronisch befragten Personen gab zudem an, dass in ihrem Arbeitsprozess Medienbrüche auftraten, und zwar insbesondere bei folgenden Dokumenten: Rechnungen, Bestellanforderungen und Lieferpapiere, die zumeist ausgedruckt, vom Verantwortlichen unterschrieben und anschließend wieder eingescannt wurden. Unterschrifts- und Aufbewahrungspflichten, basierend auf Vorgaben des Sarbanes-Oxley-Acts und/oder internen Richt-

Fallstudie Dokumentenmanagement (FSDOK)

513

linien, erhöhten die Häufigkeit des Auftretens von Medienbrüchen. Zudem lagen einige international relevante Dokumente in deutscher, englischer und spanischer Sprache vor, wobei ohne Öffnen des Dokuments dessen Sprache nicht ersichtlich war. Für die Verwaltung der Ordnerstruktur auf den gemeinsamen Netzlaufwerken aller Anwender und die damit verbundene Berechtigungsverwaltung, insbesondere die Zugriffsberechtigung auf Projektordner, war die IT-Abteilung zuständig. Die Vergabe der Zugriffsberechtigungen erfolgte auf schriftlichen Antrag der Abteilungen. Einzelne Abteilungen schützten bestimmte Dokumente durch Vergabe von Kennwörtern vor unberechtigtem Zugriff. Sensible Dokumente (z. B. noch nicht geschützte Konstruktionszeichnungen) waren nicht auf Netzlaufwerken gespeichert, sondern wurden ausschließlich per E-Mail an berechtigte Adressaten verschickt. Dies erhöhte zwar die Sicherheit, wirkte sich jedoch negativ auf Kommunikation, Dokumentenfluss und Versionierung von Dokumenten aus. Es gab zudem bislang keine zeitlich begrenzten Berechtigungen, die beispielsweise nach Abschluss eines Projekts automatisch aufgehoben wurden. Für die automatische Versionierung war damals kein entsprechendes Werkzeug im Einsatz. Die befragten Abteilungen lösten das Problem zumeist, indem zum Dateinamen das Datum angegeben wurde. Für die Volltextsuche und die Schlagwortsuche innerhalb von Ordnerstrukturen stand ebenfalls kein Werkzeug zur Verfügung. Die Verteilung von Dokumenten innerhalb des Unternehmens erfolgte zum Großteil per EMail, um die Anforderung einer Zugriffsberechtigung (schriftlicher Antrag bei der ITAbteilung) zu umgehen. Für die Ablage von Dokumenten gab es keine unternehmensweiten Richtlinien (z. B. einheitliche Bezeichnung von Ordnern oder Dokumenten). Eine grafische Darstellung der Dokumentenflüsse z. B. in einem Dokumentenflussdiagramm diente der Visualisierung der Komplexität und zeigte, dass die Abteilungen stark vernetzt waren und viele Dokumenten-Schnittstellen aufwiesen. Viele Dokumenttypen waren im gesamten Kerngeschäftsprozess (Erstellung von Motoren) involviert und unterlagen ständiger Bearbeitung. Aus diesem Grund war es bedeutsam, dass ein ECMS diese Schnittstellen berücksichtigte und Zugriffe auf bzw. Verknüpfungen mit anderen Dokumenten ermöglicht. Dies verdeutlichte die Komplexität der abteilungsübergreifenden Dokumentenflüsse aus der Sicht einzelner Abteilungen. Im Folgenden werden die Ergebnisse der Softwareanalyse beschrieben. Das Informationssystem OpenText Content Server verfügte über Funktionalitäten in folgenden Bereichen: Archivierung, Geschäftsprozessmanagement, Compliance und IT-Governance, Vertragsmanagement, Dokumentenmanagement, Datenintegration, E-Mail-Archivierung und -Management, Wissensmanagement, Projektmanagement, Records-Management, Report-Management, Digital-Asset-Management sowie Web-Content-Management. Das System bot Schnittstellen zu Bürokommunikations-, ERP- und Datenbanksystemen. Neben diesen Funktionen ergab die Organisationsanalyse, dass für BRP-Powertrain folgende Funktionalitäten von Relevanz waren, die von OpenText Content Server auch angeboten wurden: 

Die Berechtigungsverwaltung erfolgt durch volle Integration in Windows Active Directory oder durch ein Rollenkonzept innerhalb des ECMS.

514



  

   

   

Fallstudien des Informationsmanagements

Das ECMS umfasst die Berechtigungen „Lesen“ (Dokument finden / Metadaten lesen / Dokument lesen), „Ändern“ (Metadaten ändern / Dokument ändern), „Berechtigung ändern“ (auf Dokumentenebene / auf Ordnerebene). Die Rechtevergabe ist außerdem vererbbar, das bedeutet, dass Rechte von einer Organisationseinheit auf eine andere übertragbar sind. Durch den Einsatz von Records-Management können für Dokumenttypen Lebenszyklen definiert werden, was insbesondere bei gesetzlichen Aufbewahrungsfristen relevant ist. Mit dem in OpenText Content Server integrierten Workflow-Designer können Prozesse modelliert und teilweise automatisiert werden. Die Versionierung von Dokumenten erfolgt automatisiert und sie kann für verschiedene Dokumenttypen unterschiedlich definiert werden (beispielsweise wird festgelegt, dass bei weniger wichtigen Dokumenttypen maximal fünf Versionen eines Dokuments, bei wichtigen Typen wie Verträgen alle Versionen erhalten bleiben). Zu jedem Dokument können Metadaten und Notizen abgelegt und angezeigt werden. Die Suchfunktion kann neben der Angabe von Schlagwörtern und Metadaten über verschiedene, von Anwendern individuell definierbaren Sichten sowie über virtuelle Ordner unterstützt werden. OpenText Content Server bietet eine Reportfunktion, die Statistiken über die Häufigkeit von Zugriffen auf Dokumente und ähnliches erstellt. Der Einsatz elektronischer Signaturen kann durch ein Zusatzmodul unterstützt werden, wodurch Medienbrüche vermieden werden können. Hierbei sind jedoch gesetzliche Einschränkungen zu berücksichtigen, die sich aufgrund des Sarbanes-Oxley-Acts ergeben können. Die Suchfunktion unterstützt mehr als 150 Sprachen und doppelte Dokumente in verschiedenen Sprachen lassen sich über Kategorien einfach verwalten. Das ECMS kann über einen Client ohne Internet-Anbindung oder über ein Webportal genutzt werden. Dokumente können zudem im Windows-Explorer und in Microsoft Office Outlook verwaltet werden. Neben den bereits genannten Schnittstellen zu Bürokommunikationssystemen bestehen Schnittstellen zu ERP-Systemen (entweder über iViews oder über DocuLink). OpenText Content Server hat zur automatisierten Wissensübermittlung eine Notification-Funktion, mit der definiert werden kann, dass ein Benutzer mittels E-Mail über ein bestimmtes Ereignis (z. B. Erstellung einer neuen Version eines Dokuments) informiert werden soll.

Ergebnis Die Einführungsstrategie spiegelt die Ergebnisse der Organisationsanalyse wider und ist in Form eines phasenbasierten Vorgehensmodells konzipiert (Abbildung FSDOK-1). Dies erleichtert die schrittweise Umsetzung der Strategie, weil die chronologische Abfolge der Phasen bei jeder Erweiterung des ECMS im Unternehmen berücksichtigt wird. Der Einsatz des Phasenmodells unterstützt eine konzernweite Einführung des ECMS, vor allem die zentrale Rolle der IT-Abteilung bei der Installations- und der Koordinationsphase, aber auch die Mitwirkung in der Definitionsphase basiert auf der aus der Organisationsanalyse gewonnenen Erkenntnis, dass der Querschnittsfunktion der IT in der BRP-Powertrain besondere

Fallstudie Dokumentenmanagement (FSDOK)

515

Beachtung geschenkt wird. Zu jeder Phase werden die abzuarbeitenden Aktivitäten erläutert und die Aufgabenträger angegeben.

Installationsphase Ziel dieser Phase ist es, das Softwarepaket OpenText Content Server bei BRP-Powertrain so zu installieren, dass eine vollständige Integration in die bestehenden IT-Systeme erfolgt. Einerseits sind von der Installation Softwaresysteme betroffen (z. B. SAP), andererseits Hardwarekomponenten (z. B. Server zur Speicherung bzw. Archivierung von Daten). Die Aufgabendurchführung übernimmt die IT-Abteilung von BRP-Powertrain, Kontakt zu Anwendern besteht in dieser Phase nicht.

Koordinationsphase

Installationsphase Koordinationsphase Definitionsphase

Going-Live-Phase

Abb. FSDOK-1: Vorgehensmodell zur Einführung von OpenText Content Server

Ziel dieser Phase ist es zu koordinieren, in welcher Reihenfolge die Abteilungen der BRPPowertrain an das ECMS angebunden werden sollen. Aufgabenträger ist wiederum die ITAbteilung. Die Entscheidung über die Reihenfolge kann auf Basis einer Komplexitätsanalyse, die im Rahmen der Organisationsanalyse durchgeführt wird, getroffen werden. Dabei werden Dokumentenflüsse von und zu Abteilungen analysiert. Auf Basis des Analyseergebnisses kann je nach Zielsetzung in einem Unternehmen die Reihenfolge der Abteilungen festgelegt werden. Ist die Zielsetzung beispielsweise die Risikoverminderung, so ist die Einführung in einer Pilotabteilung mit geringer Vernetzung zu anderen Abteilungen zweckmäßig. Ist die Zielsetzung die rasche Umsetzung der Nutzenpotenziale von ECMS, so ist die Einführung in einer Abteilung mit hoher Vernetzung sinnvoll, weil somit ein höheres Potenzial zur Produktivitätssteigerung ausgeschöpft werden kann. Schließlich werden in der Koordinationsphase Ähnlichkeiten zwischen Abteilungen sichtbar (z. B. Suchverhalten von Anwendern oder Berechtigungsstrukturen), die eine simultane Durchführung der Definitionsphase in diesen Abteilungen zweckmäßig erscheinen lassen. In BRP-Powertrain ist primäre Zielsetzung die Risikominimierung, weshalb für die erste Durchführung der Definitionsphase und die erste Einführung von OpenText Content Server die gering vernetzte BI-Abteilung ausgewählt wurde. Auf Basis der dabei gewonnenen Erkenntnisse wird die Einführung der weiteren Abteilungen koordiniert. Für jede dieser Abteilungen bzw. Abteilungsgruppen ist die Definitionsphase durchzuführen, um die Inhalte der Strategieobjekte zu definieren.

Definitionsphase Ziel dieser Phase ist es, Inhalte für die Strategieobjekte (die auf Basis der Erkenntnisse aus Organisations- und Softwareanalyse entwickelt wurden) für jede Abteilung zu definieren und das Ergebnis in OpenText Content Server abzubilden. Die Definition erfolgt im Rahmen eines Workshops, an dem der ECMS-Projektleiter, Vertreter der IT-Abteilung sowie Anwender aus den Abteilungen und der jeweilige Abteilungsleiter teilnehmen. In Abbildung FSDOK-2 sind zehn Strategieobjekte dargestellt, die von BRP-Powertrain als erfolgsrelevant

516

Fallstudien F des s Informationssmanagements s

w In jed der Abteilung findet ein Workshop statt, in dem Entsccheidungen zu u angesehen werden. den Strategiieobjekten gettroffen werdenn. Diese Phase wird iterativ v für alle in dder Koordinatiionsphase festgelegten Ab bteilungen durrchgeführt. Beei Bedarf kan nn auch die Reeihenfolge deer Koordinatio onsphase adap ptiert bzw. köönnen weitere ähnliche Abtteilungen zussammengefassst werden.

Abb. FSDOK-2: Strate egieobjekte am Beispiel BRP-P Powertrain

Strategieob bjekt 1 - Dok kumente: Zueerst werden diie in das ECM MS einzuglieddernden Doku umenttypen und u deren Dateiformate erm mittelt. Es werden nur solche Dokumente in das System m eingebunden n, die von meehreren Personnen bzw. Abtteilungen eing gesehen und/ooder bearbeiteet und Mastergateplän M werden könn nen. Dazu zäh hlen bei BRP--Powertrain ProjektP ne, Konstruktiionszeichnun ngen, Product Design Revieew, Verträge und u Protokollee. Strategieob bjekt 2 - Struk ktur: Es ist eiine Speichersttruktur für diee Ordner und D Dokumente zu u definieren. Die D Definition n kann auf Baasis von Projeekten, Bearbeiitern, Datum uusw. erfolgen n. n drei Ebenen als zweckmäßßig anzusehen Im Falle von n BRP-Powerrtrain ist die D Definition von n, nwendern frei gewählt weerden können anschließend d sollen Ord dnerstrukturenn von den An n. Durch die individuelle Darstellung D deer Dokumentee mit Hilfe veerschiedener SSichten (siehe Strategieobjekt 8) wird die Anwenddung des Sysstems nicht durch d die phhysische Speiicherstrukturr beeinflusst. Strategieob bjekt 3 - Metadaten: Metaadaten vereinffachen die Su uche nach Dokkumenten und d hat somit s ihre Darstelllung nach Sichten. Die Deffinition von Metadaten M positiveen Einfluss au uf den wahrgeenommen Beittrag eines EC CMS zur Auffgabenerfüllun ng, was die A Akzeptanz des ür jeden Doku Systems beii den Anwend dern günstig bbeeinflusst. Fü umenttyp müsssen Metadaten n V festgelegt werden, w die vo ollständig und zweckmäßig sein sollen. Vollständigke eit und Zweck k-

Fallstudie Dokumentenmanagement (FSDOK)

517

mäßigkeit von Metadaten leiten sich aus den Erfahrungen und dem Informationsbedürfnis der Anwender bei der Suche nach Dokumenten ab. Dieses Informationsbedürfnis wurde im Rahmen der Organisationsanalyse für sechs Abteilungen mittels elektronischem Fragebogen und Interview erhoben. Beispiele für Metadaten und damit für Suchkriterien bei BRPPowertrain sind: Dokumenttyp (z. B. Vertrag), Projektnummer und -name, Sprache, Bearbeiter oder Projektstatus. Strategieobjekt 4 - Berechtigungen: Mit einer wohldurchdachten Struktur von Berechtigungen kann der interne E-Mail-Verkehr bei BRP-Powertrain reduziert werden. Es sind für alle Dokumenttypen Berechtigungen für Personen bzw. Abteilungen zu definieren. Abbildung FSDOK-3 zeigt beispielhaft das Ergebnis der Entwicklung einer Berechtigungsstruktur in der Abteilung BI bei BRP-Powertrain für die in Projekten verwendeten Dokumenttypen Pflichtenhefte, Terminpläne, Projektpläne sowie Protokolle. Wird diese Berechtigungsstruktur in BRP-Powertrain durch verbindliche Unternehmensrichtlinien unterstützt, kann das Problem der „Umgehungstradition“ des bisherigen Berechtigungssystems gelöst werden. Strategieobjekt 5 - E-Mail-Integration: OpenText Content Server bietet eine umfassende Integration in das bei BRP-Powertrain verwendete E-Mail-System (Microsoft Outlook). EMails können einfach (mittels Drag-and-Drop) in das ECMS importiert werden und bei den jeweiligen Projekten abgelegt werden. Bei BRP-Powertrain werden Richtlinien definiert, die festlegen, welche E-Mail-Typen wo im ECMS abgelegt werden. Strategieobjekt 6 - Medienbrüche: Für jede Abteilung sind die kosten- und zeitintensiven Medienbrüche zu erheben und es sind Möglichkeiten zu erarbeiten, wie diese nach Einführung des ECMS vermieden werden können. Langfristig ist es das Ziel, den Einsatz von elektronischen Signaturen und deren Integration in OpenText Content Server zu realisieren. Strategieobjekt 7 - Versionierung: Mittels Records-Management bietet OpenText Content Server eine vollautomatisierte Versionierung und Archivierung von Dokumenten. Dafür ist einmalig festzulegen, für welche Dokumente Aufbewahrungs- bzw. Versionierungspflichten bestehen, um anschließend deren Verwaltung automatisiert durchzuführen. Es muss festgelegt werden, wie viele und welche Versionen von einem Dokumenttyp aufbewahrt werden, wie lange Dokumenttypen aufgrund gesetzlicher Vorschriften und/oder interner Richtlinien archiviert werden müssen und wann Dokumenttypen gelöscht werden sollen. In der BRPPowertrain gibt es aufgrund des Sarbanes-Oxley-Acts gesetzliche Aufbewahrungspflichten für verschiedene Dokumenttypen zwischen 5 und 40 Jahren, bei manchen Dokumenten wie z. B. Product Design Review ist eine Aufbewahrung aller Versionen zu empfehlen, während es beispielsweise bei Bestellanforderungen reicht, nur die letzten zwei Versionen aufzubewahren. Strategieobjekt 8 - Sichten: OpenText Content Server unterstützt die Definition verschiedener Sichten nach Anwendern. Der Vorteil dieser Funktionalität ist, dass jede Person individuell nach ihren Gewohnheiten auf Dokumente zugreifen kann. Die Organisation der Sichten erfolgt über die Eingabe von Metadaten. Beispiele für Sichten sind die Darstellung nach Bearbeiter, Projekt, Dokumenttyp, Projektstatus oder Jahr. Für die BRP-Powertrain sind z. B. folgende Sichten definiert worden: „Projekt ab Datum“ oder „Projekt nach Bearbeiter“.

518

Fallstudien des Informationsmanagements

Strategieobjekt 9 - SAP-Integration: Für die im ECMS abgelegten Dokumente sind die Schnittstellen zu vom ERP-System verwalteten Dokumenten zu definieren, wobei Ablageort und Berechtigungen festzulegen sind. Strategieobjekt 10 - Umstiegsszenario: Es sind alle Möglichkeiten der Umstellung mit der jeweiligen Abteilung zu besprechen, Vor- und Nachteile von Parallelbetrieb und Sofortumstellung sollen abgewogen werden. Außerdem sind Art und Umfang von Schulungsmaßnahmen in den einzelnen Abteilungen festzulegen; OpenText Content Server ist stark in die Windows-Oberfläche eingebunden, was die Benutzerfreundlichkeit erhöht und den Lernaufwand reduziert. Leseberechtigung

Änderungsberechtigung

Berechtigungsvergabe

Nein

Nein

Nein

Abteilungsfremde Personen im Projektteam

Ja

Ja

Nein

Abteilungsinterne Personen nicht im Projektteam

Ja

Nein

Nein

Abteilungsinterne Personen im Projektteam mit Leseinteresse (z. B. Techniker)

Ja

Nein

Nein

Abteilungsinterne Personen im Projektteam

Ja

Ja

Nein

Ausgewählte Mitarbeiter im Sekretariat

Ja

Ja

Ja

Personengruppen Abteilungsfremde Personen

Abb. FSDOK-3: Berechtigungsstruktur für die Abteilung BI bei BRP-Powertrain

Going-Live-Phase Ziel dieser Phase ist es, abteilungsübergreifende Aktivitäten (z. B. Definition von Workflows) zu planen und durchzuführen. Die Durchführung der Aktivitäten kann erst dann erfolgen, wenn alle Abteilungen an das ECMS angebunden sind und die Anwender das System nutzen. Des Weiteren soll in der vierten Phase der Ausbau von OpenText Content Server vom reinen DMS zu einem Content-, Collaboration- und Process-Management-System erfolgen, insbesondere durch die Modellierung von Geschäftsprozessen und deren Verknüpfung zu den Dokumenten im ECMS. Der Produktivstart war am österreichischen Standort mit Beginn des Jahres 2008 geplant. Eine Erfolgsmessung hinsichtlich der Zielerreichung konnte erst nach Produktivstart des ECMS durchgeführt werden. Der Nutzen eines ECMS (z. B. Verkürzung der Durchlaufzeiten) lässt sich beispielsweise mittels Beobachtung, insbesondere mit Videounterstützung oder Befragung messen. Überdies bietet OpenText Content Server die Funktionalität, nach vollständiger Abbildung der Workflows im System, Prozessmetriken automatisiert in einer Datenbank abzulegen und für spätere Analysen bereit zu stellen (z. B. Durchlaufzeit, Zugriffsfrequenz).

Fallstudie Dokumentenmanagement (FSDOK)

519

Evaluierung des Phasenmodells – Pilotanwendung Nach einem ersten Durchlauf der Installations- und Definitionsphase wurde die BI-Abteilung mit rund 20 Mitarbeitern und wenigen Dokumentenflussschnittstellen zu anderen Abteilungen für eine Piloteinführung ausgewählt. Für die Definitionsphase wurde mit ausgewählten Mitarbeitern ein Workshop abgehalten, in dem die Inhalte der Strategieobjekte festgelegt wurden. Eine zentrale Erkenntnis der Evaluierung ist, dass bei der Vorbereitung der Definitionsphase folgende Besonderheiten zu berücksichtigen sind: (i) Die Definition obligatorischer Metadaten und Kategorien muss in Abstimmung mit betroffenen Mitarbeitern einer Abteilung durchgeführt werden, da dies die Basis für personenspezifisches Suchverhalten und die Nutzung verschiedener Sichten darstellt. (ii) Es ist unerlässlich, dass bei jedem Workshop der jeweilige Abteilungsleiter anwesend ist. Obwohl in BRP-Powertrain flache Hierarchien herrschen, hat sich gezeigt, dass nicht leitende Mitarbeiter Vorbehalte gegenüber dem Fällen verbindlicher Entscheidungen hinsichtlich der Dokumentenintegration, der Aufbewahrungsfristen für das Records Management sowie der Richtlinien im Umgang mit der Versionierung hatten. Diese verbindlichen Entscheidungen müssen während des Workshops von einem Entscheidungsträger getroffen werden.

Implikationen Wie beim Bezugsrahmen abgeleitet, bietet ein ECMS eine technologische Grundlage für Wissensverteilung, Wissensnutzung und Wissensbewahrung und trägt damit zur Erfüllung der administrativen Aufgabe Wissensmanagement bei. Zu diesem Zweck wurden Strategieobjekte für die Einführung definiert. Aus Sicht der Aufgabe Wissensverteilung sind die Strategieobjekte SAP-Integration, E-MailIntegration und Sichten von besonderer Bedeutung. Die Einbindung von E-Mails sowie den entsprechenden Elementen des ERP-Systems bietet die Grundlage für das zur Verfügung stellen des Wissens zur richtigen Zeit im richtigen Prozess. Durch die Abbildung von Mitarbeitern auf Sichten ist die Assoziierung des Wissens zum entsprechenden Mitarbeiter gewährleistet und Redundanzen werden vermieden. Die Strategieobjekte Dokumente, Struktur und Metadaten unterstützen die Aufgabe Wissensnutzung und deren Motivation, Barrieren zu reduzieren. Die Kombination aus Dokumenteninformationen, deren Struktur und Zuordnung sowie deren Metadaten machen Dokumente und deren Inhalte auffindbar und Zusammenhänge transparent. Aufbauend auf den übrigen Strategieobjekten bieten Versionierung, Medienbrüche und Berechtigungen einen zusätzlichen Beitrag zur Erfüllung der Aufgabe Wissensbewahrung. Das Strategieobjekt Umstiegsszenario hat keinen direkten Bezug zum Wissensmanagement, sondern zielt auf die Bedeutung von Vorgehensmodellen ab. Die Erfahrung aus der Pilotierung, dass das Treffen von Entscheidungen auf administrativer Ebene in jeder Abteilung des Unternehmens essentiell ist, spricht für die Einbindung eines Aufgabenträgers des Wissensmanagements. Werden diese Entscheidungen von einem Chief Knowledge Officer koordiniert, so ergeben sich weitere Potentiale für die Optimierung des Systems unternehmensweit, was sowohl zu Wirksamkeit, als auch Wirtschaftlichkeit des ECMS als Werkzeug des Wissensmanagements beiträgt.

520

Fallstudien des Informationsmanagements

Aufgaben- und Methodenverweise Erklärungsmodell Informationsmanagement (Lerneinheit ERMOD); Wissensmanagement (Lerneinheit WIMAN); Vorgehensmodelle (Lerneinheit VOMOD); Methoden des Wissensmanagements (Lerneinheit MEWIM). Quellen Rückel, D. / Steininger, K.: Fallstudie: Einführung eines Enterprise-Content-Management-Systems. In: HMD – Praxis der Wirtschaftsinformatik 258/2007, 78–88 Vertiefungsliteratur Siehe dazu die in der Quelle angegebene Literatur.

Fallstudie Erfolgsfaktorenanalyse (FSERF) Ausgangssituation ASP ist eine Dienstleistung bzw. ein Dienstleister, die bzw. der Kunden gegen Entgelt Standardsoftware ohne bzw. mit einem geringen Umfang an Customizing zur Verfügung stellt (one-to-many-approach) und in einem Service-Rechenzentrum betreibt (eine Form des Software-Outsourcing, vgl. Lerneinheit OUTSO). Der Dienstleister sorgt für die Softwarelizenz, die Wartung und die Aktualisierung der Software und stellt in geeigneter Form Unterstützung zur Verfügung (Benutzerservice). Der Zugriff durch die Benutzer erfolgt über verschiedene Verbindungen (Internet, Standleitungen, Satellitenverbindung). Das Material der Fallstudie stammt aus dem Projekt „Messung von ASP-Qualität“, das 2002 und 2003 am ipo – Institut für Personal- und Organisationsentwicklung in Wirtschaft und Verwaltung an der Universität Linz durchgeführt wurde (http://www.ipo.jku.at). Auftraggeber war die ASP Group Austria. Projektziel war die Entwicklung eines Messmodells, das es potenziellen Kunden ermöglicht, ASP-Qualität ex-ante zu ermitteln. In Fachliteratur und Praxis wurde kein Messmodell gefunden, das die Bestimmung von ASP-Qualität ermöglicht hätte. Beschrieben wurden nur Checklisten, mit denen die Leistungsfähigkeit von ASP beurteilt werden soll. Eine Messung im wissenschaftlichen Sinn ist mit Checklisten nicht möglich. Methodisch im Mittelpunkt der Fallstudie steht die Anpassung der Erfolgsfaktorenanalyse (vgl. Lerneinheit ERFAN), um sie zur Messung der ASP-Qualität verwenden zu können. Im Folgenden werden die Charakteristika des Messmodells erläutert. Darauf aufbauend wird die Vorgehensweise bei seiner Anwendung – der Prozess der Qualitätsbestimmung – erklärt. Schließlich wird über Erfahrungen beim Einsatz des Messmodells im Feld berichtet; sie geben Aufschluss über seine Praxistauglichkeit. Die in dieser Lerneinheit genannten ITspezifischen Phänomene (z. B. Informationsmanager, Lenkungsausschuss, Outsourcing, Sicherheitsmanagement und strategische Zielplanung) sind in den einschlägigen Lerneinheiten erklärt worden (z. B. Lerneinheiten STELL, STRUK, OUTSO, SICHM und STRAT).

Messmodell In der Fachliteratur werden verschiedene Vorgehensweisen zur Messung von Dienstleistungsqualität vorgeschlagen; das Messmodell ASP-Qualität verwendet ein multiattributives Messverfahren. ASP-Qualität setzt sich aus Teilqualitäten verschiedener Qualitätsmerkmale zusammen. Diese werden auf einer doppelten Ordinalskala (Prioritätsskala und Leistungsskala) gemessen. Auf der Prioritätsskala wird die Wichtigkeit (Bedeutung oder Relevanz), auf der Leistungsskala die aus Kundensicht wahrgenommene Leistung des Anbieters gemessen. Analog zur Erfolgsfaktorenanalyse werden folgende Skalen verwendet:

522

Fallstudien des Informationsmanagements

Prioritätsskala

Leistungsskala

P(M) = 1: irrelevant

L(M) = 1: sehr schlecht

P(M) = 3: eventuell nützlich

L(M) = 3: ausreichend

P(M) = 5: wichtig

L(M) = 5: gut

P(M) = 7: sehr entscheidend

L(M) = 7: ausgezeichnet

Vom Outsourcing betroffene Mitarbeiter des potenziellen Kunden (Benutzer) beurteilen die Priorität der Qualitätsmerkmale auf der Skala P(M). Priorität drückt die Anforderung an die Leistung der Qualitätsmerkmale aus. Mitarbeiter von Referenzkunden von ASP, deren Qualität gemessen werden soll, beurteilen die Leistung auf der Skala L(M). Damit drücken sie ihre subjektive Zufriedenheit über die Leistung aus. Angenommen wird, dass Personen, die Erfahrung mit der ASP-Qualität eines bestimmten Anbieters haben – das sind die Benutzer der vom Referenzkunden ausgelagerten Applikation – die Leistung am besten beurteilen können. Als Voraussetzung für die Gültigkeit dieser Annahme müssen die Qualitätsmerkmale so erklärt werden, dass sie durch diese Benutzer beurteilt werden können, und so bezeichnet werden, dass alle urteilenden Personen unter den verwendeten Bezeichnungen die gleichen realen Phänomene verstehen. Die Messung der Priorität erfolgt mit einem Fragebogen, der folgende Frage enthält: Wie beurteilen Sie die Priorität der genannten Qualitätsmerkmale? Im Fragebogen folgen die Qualitätsmerkmale (mit Bezeichnung und Erklärung), jedes mit der vierstufigen Ordinalskala P(M) versehen. Für die Messung der Leistung wird ein Fragebogen verwendet, der folgende Frage enthält: Wie beurteilen Sie die Leistung der im Folgenden genannten Qualitätsmerkmale? Im Fragebogen folgen die Qualitätsmerkmale (mit Bezeichnung und Erklärung), jedes mit der vierstufigen Ordinalskala L(M) versehen. Im Folgenden werden 26 Qualitätsmerkmale erklärt, die durch empirische Untersuchungen sowie durch Analyse der Fachliteratur und einschlägiger Websites identifiziert wurden.

Schlüsselbereich Applikation A

Benutzerfreundlichkeit. Es wird die Steuerbarkeit der Applikation durch den Benutzer beurteilt (z. B. Gestaltung der Benutzungsoberfläche).

B

Customizing. Es wird die Anpassungsfähigkeit der Applikation an die betrieblichen Geschäftsprozesse beurteilt.

C

Funktionalität. Es wird die Übereinstimmung zwischen der von der Applikation angebotenen Problemlösung und der vom Kunden angegebenen Problemstellung beurteilt.

D

Leistungsfähigkeit. Es wird die Fähigkeit der Applikation beurteilt, eine bestimmte Anzahl an Transaktionen pro Zeiteinheit auszuführen.

E

Multimandanten- und Multiuserfähigkeit. Es wird die Fähigkeit der Applikation beurteilt, für mehrere Kunden (Mandanten) bzw. Benutzer (User) simultan identische Dienste zu leisten. Mehrere Kunden bzw. Benutzer können simultan Daten abfragen und bearbeiten.

Fallstudie Erfolgsfaktorenanalyse (FSERF)

523

F

Skalierbarkeit. Es wird die Anpassbarkeit der Systemkomponenten an veränderte quantitative Anforderungen (z. B. Rechnerleistung, Speicherkapazität, Datenübertragungskapazität) unter Beibehaltung ihrer qualitativen Eigenschaften beurteilt.

G

Systemintegration. Es wird die Zusammenführung intern betriebener Softwaresysteme mit der ausgelagerten Applikation beurteilt.

H

Web-Fähigkeit. Es wird die Fähigkeit der Applikation beurteilt, ohne spezielle ClientSoftware Daten über das Internet abzurufen und am Client darzustellen.

Schlüsselbereich Sicherheit I

Bestandsdauer. Es werden die bisherige Lebensdauer des ASP und die Wahrscheinlichkeit des zukünftigen Fortbestandes des ASP beurteilt.

J

Datenrückführung. Es wird die Art und Weise der Rückführung ausgelagerter Daten zum Kunden aufgrund geplanter (z. B. Vertragsende) und ungeplanter Ereignisse (z. B. Insolvenz) beurteilt.

K

Ergebnisverfügbarkeit. Es wird das Zeitverhalten bei der Lieferung von Auswertungen, beim Ausdruck von Dokumenten oder beim Zugriff auf Ergebnisse beurteilt (z. B. Antwortzeitverhalten, Bearbeitungsdauer).

L

Integrität. Es wird der Zustand der IT-Infrastruktur beurteilt, der ein unbefugtes Verändern an ihren Komponenten nicht zulässt. Alle sicherheitsrelevanten Objekte (z. B. Datenbestände) sind vollständig, unverfälscht und korrekt.

M

Maximaler Datenverlust. Es wird die Datenmenge beurteilt, die bei einem Zusammenbruch der gesamten IT-Infrastruktur bzw. einer ihrer Komponenten (z. B. Server, Datenübertragungseinrichtung) nicht wieder herstellbar ist.

N

Service Level Agreement. Es werden die Vertragsvereinbarungen zwischen Kunde und ASP beurteilt, in denen die Parameter der Dienstleistung und deren Qualitätsniveau festgelegt sind, einschließlich der Preisvereinbarungen und weiterer Nebenabreden (z. B. Vertragsstrafen bei Nichteinhaltung des vereinbarten Qualitätsniveaus).

O

Verbindlichkeit. Es wird die Nichtabstreitbarkeit einer gültigen Transaktion in der Datenbank der Applikation beurteilt.

P

Verfügbarkeit. Es werden die Ausfallszeiten der Systemkomponenten (z. B. Hardwareausfall, Softwareabsturz, Unterbrechung der Datenübertragungseinrichtung) im Verhältnis zur Arbeitszeit beurteilt.

Q

Vertraulichkeit. Es wird der Schutz von Daten vor unautorisiertem Lesen beurteilt.

Schlüsselbereich Services R

Ansprechpartner. Es wird beurteilt, ob der ASP dem Kunden einen bestimmten Mitarbeiter als Kontaktperson zur Verfügung stellt.

S

Benutzerschulung. Es werden der Umfang und die Qualität der Schulung und Weiterbildung der Benutzer sowie die dabei verwendeten Methoden beurteilt.

524

Fallstudien des Informationsmanagements

T

Implementierung. Es wird die technische Einführung der Systemkomponenten (z. B. der Applikation) beim Kunden beurteilt.

U

Monitoring. Es wird die Fähigkeit des ASP beurteilt, das Leistungsverhalten verschiedener Systemkomponenten (z. B. Server, Datenübertragungseinrichtung) werkzeuggestützt zu überwachen.

V

Pre-Sales-Services. Es werden der Umfang und die Qualität der vom ASP angebotenen Leistungen beurteilt, auf deren Basis potenzielle Kunden eine Auswahlentscheidung treffen können (z. B. Demozugang zur Applikation).

W

Problemmanagement. Es wird die Fähigkeit des ASP (z. B. Helpdesk-Mitarbeiter) beurteilt, Probleme der Benutzer rasch zu bestimmen und zu beheben.

X

Projektmanagement. Es wird die Fähigkeit des ASP beurteilt, den reibungslosen Übergang der Applikation vom Kunden zum ASP durchzuführen.

Y

Reporting. Es wird die Fähigkeit des ASP beurteilt, das Leistungsverhalten verschiedener Systemkomponenten (z. B. Server, Datenübertragungseinrichtung) benutzergerecht darzustellen (z. B. durch Grafiken).

Z

Technologiemanagement. Es wird die Fähigkeit des ASP beurteilt, zukünftige Technologien mit erheblichem Veränderungspotenzial erfolgreich in das eigene Leistungsportfolio zu integrieren.

Prozess der Qualitätsbestimmung Der Prozess wird von einem Projektbegleiter – ein Mitarbeiter des potenziellen Kunden oder ein Externer – organisiert, der über ASP-Fachwissen und Fachwissen zur Methodenanwendung verfügt. Er ist auch für die Auswertung der Fragebögen sowie für die Interpretation und Präsentation der Ergebnisse zuständig. Die Identifikation von ASP und Referenzkunden wird durch Suchfunktionen einschlägiger Websites (z. B. http://www.asperado.com) und durch Daten von Interessensverbänden, deren Mitglieder in der Regel ASP und ASP-Enablers sind (z. B. Hardwarehersteller), unterstützt. Der Prozess der Qualitätsbestimmung besteht aus acht Arbeitsschritten: 1. 2. 3. 4. 5. 6. 7. 8.

Identifikation der Qualitätsmerkmale, Festlegung der Teilnehmer an der Befragung, Formulierung des Fragebogens, Messung der Priorität der Qualitätsmerkmale beim potenziellen Kunden, Messung der Leistung der Qualitätsmerkmale bei Referenzkunden, Auswertung der Fragebogenerhebung, Darstellung und Interpretation der Untersuchungsergebnisse, Präsentation der Untersuchungsergebnisse.

1. Identifikation der Qualitätsmerkmale: Beim potenziellen Kunden wird eine Arbeitsgruppe gebildet, die aus Vertretern der drei Interessensgruppen Benutzer, IT-Abteilung und Geschäftsführung besteht. Durch die Arbeitsgruppe sollen folgende Aufgaben bearbeitet bzw. Fragen beantwortet werden:

Fallstudie Erfolgsfaktorenanalyse (FSERF)

     

525

Beschreiben die 26 Qualitätsmerkmale alle Eigenschaften, die Einfluss auf die Qualität haben? Welche Qualitätsmerkmale sind von geringer oder ohne Bedeutung und sollten im Fragebogen nicht enthalten sein? Welche Qualitätsmerkmale mit erheblicher Bedeutung fehlen und müssen im Fragebogen ergänzt werden? Entsprechen die Bezeichnungen und Definitionen der Qualitätsmerkmale der in der Praxis bekannten Fachsprache? Ist es möglich, mehrere, zunächst einzeln definierte Qualitätsmerkmale zusammenzufassen? Müssen Qualitätsmerkmale durch Zerlegung präzisiert werden?

2. Festlegung der Teilnehmer an der Befragung: Teilnehmer an der Befragung sind Personen der drei Interessensgruppen Benutzer, IT-Mitarbeiter und Personen der Geschäftsführung des potenziellen Kunden und Benutzer von Referenzkunden. 3. Formulierung des Fragebogens: Der Fragebogen wird mit den oben formulierten Fragen eingeleitet. Auf dem Deckblatt des Fragebogens zur Messung der Priorität werden zur Identifikation das Unternehmen, die Interessensgruppe und der Name der befragten Person angegeben. Auf dem Deckblatt des Fragebogens zur Messung der Leistung werden der ASP, dessen Referenzkunde sowie die Stellung der befragten Person im Unternehmen angegeben. 4. Messung der Priorität der Qualitätsmerkmale beim potenziellen Kunden: Benutzer, Mitarbeiter im IT-Bereich und Personen der Geschäftsführung beurteilen die Priorität. Sie sollen über den Erhebungszweck informiert sein und Instruktionen zur Beantwortung des Fragebogens erhalten haben. Um Absprachen zu vermeiden, soll die Beantwortung des Fragebogens durch alle Teilnehmer an einem bestimmten Arbeitstag erfolgen. 5. Messung der Leistung der Qualitätsmerkmale bei Referenzkunden: Mehrere Benutzer beurteilen die Leistung. Auch dafür soll die Beantwortung des Fragebogens durch alle Teilnehmer an einem bestimmten Arbeitstag erfolgen. 6. Auswertung der Fragebögen: Die Priorität eines Qualitätsmerkmals resultiert aus den Urteilen der Interessensgruppen, die durch die Urteile der befragten Personen gebildet werden. Die Priorität des potenziellen Kunden resultiert aus den Prioritäten aller Qualitätsmerkmale (vgl. Abbildung FSERF-1). Die Leistung des ASP resultiert aus den Urteilen der Referenzkunden. Die Urteile der Referenzkunden resultieren aus den Urteilen der Benutzer (vgl. Abbildung FSERF-2). 7. Darstellung und Interpretation der Untersuchungsergebnisse: Diese werden in PrioritätsLeistungs-Portfolios dargestellt, zuerst alle Qualitätsmerkmale durch Eintragung der Wertekombinationen (Priorität und Leistung).

526

Fallstudien des Informationsmanagements

I = Anzahl der Personen in der Interessensgruppe

I

Priorität eines Qualitätsmerkmals für den potenziellen Kunden

Priorität des potenziellen Kunden

x = Ausprägung P(M)

x  ...  xI  x 1

Priorität eines Qualitätsmerkmals für eine Interessensgruppe

xA 

xPK 

x = Priorität eines Qualitätsmerkmals für eine Interessensgruppe

x  ...  x  1

x

A1

N

N

N = Anzahl der Interessensgruppen

 ...  x AZ Z



x A = Priorität eines Qualitätsmerkmals für den potenziellen Kunden Z = Anzahl der Qualitätsmerkmale

Abb. FSERF-1: Berechnung der Priorität

Leistung eines Qualitätsmerkmals für einen Referenzkunden

Leistung eines Qualitätsmerkmals für einen ASP

Leistung des ASP

y = Ausprägung L(M)

 y  ...  y B  y 1

B = Anzahl der Benutzer beim Referenzkunden

B

yA 

y ASP 

= Leistung eines Qualitätsmerkmals für einen Referenzkunden y

y  ...  y  1

y

A1

R

R

 ...  y AZ Z

A

R = Anzahl der Referenzkunden



= Leistung eines Qualitätsmerkmals für einen ASP y

A

Z = Anzahl der Qualitätsmerkmale

Abb. FSERF-2: Berechnung der Leistung

Dienstleistungsqualität ist die Fähigkeit eines Anbieters, die Beschaffenheit einer primär intangiblen und der Kundenbeteiligung bedürfenden Leistung gemäß den Kundenerwartungen auf einem bestimmten Anforderungsniveau herzustellen; sie ergibt sich aus der Summe der Eigenschaften bzw. Merkmale der Dienstleistung, bestimmten Anforderungen gerecht zu werden (vgl. ISO 9000:2005 Qualitätsmanagementsysteme – Grundlagen und Begriffe). Daraus folgt, dass bei Qualitätsmerkmalen, die auf bzw. über der 45°-Diagonalen liegen, ein ASP die Anforderungen eines potenziellen Kunden an die Leistung erfüllt (vgl. Abbildung FSERF-3). Eine Qualitätsbetrachtung bei Merkmalen mit einer Priorität kleiner drei (P(M) = 3: eventuell nützlich) und einer Leistung kleiner drei (L(M) = 3: ausreichend)

Fallstudie Erfolgsfaktorenanalyse (FSERF)

527

ist nicht zweckmäßig. Die 45°-Diagonale entspringt daher nicht im Ursprung, sondern im Punkt (3/3).

1

3

Leistung

5

7

Bei Qualitätsmerkmalen, die unter der 45°CU Diagonalen liegen, erfüllt ein ASP die Leistungsanforderungen nicht. Der vertikale Abstand eines Qualitätsmerkmals zur 45°Diagonalen visualisiert die Abweichung der SY Leistung von der Priorität. Mit zunehmendem vertikalen Abstand von Qualitätsmerkmalen, die unter der 45°-Diagonalen liegen, vergrößert sich das Qualitätsdefizit. Zur besseren Visualisierung von Qualitätsdefiziten wird empfohlen, Priorität und Leistung auch in Polaritätsprofilen darzustellen. In Abbildung FSERF-3 sind beispielhaft die 1 3 5 7 Qualitätsmerkmale Customizing (CU), bei Priorität dem die Leistung die Priorität übersteigt, und Systemintegration (SY), bei dem die Abb. FSERF-3: Prioritäts-Leistungs-Portfolio (PLP1) Priorität die Leistung übersteigt (Qualitätsdefizit) dargestellt. Im Prioritäts-Leistungs-Portfolio werden auch die Priorität des potenziellen Kunden und die Leistung aller ASP dargestellt. Schneidet die horizontale Leistungslinie eines ASP die vertikale Prioritätslinie auf bzw. über der 45°-Diagonalen, so entspricht die Leistung der Priorität (siehe dazu die Ergebnisse der Feldstudien). 8. Präsentation der Untersuchungsergebnisse: Diese erfolgt durch den Projektbegleiter. Das Auditorium besteht aus Vertretern der drei Interessensgruppen des potenziellen Kunden. Mit den Ergebnissen wird der Anbieter identifiziert, dessen Qualität am höchsten ist. Die gewonnenen Qualitätsinformationen sind – neben dem Preis der Leistung – die Entscheidungsgrundlage bei der Auswahl eines ASP.

Feldstudien Objekte der Feldstudien waren zwei potenzielle Kunden sowie Referenzkunden von zwei ASP, die ERP-Systeme im ASP-Modell betreiben. Die Unternehmensprofile sind in Abbildung FSERF-4 dargestellt. Ziel der Feldstudien war die Bestimmung der Praxistauglichkeit des Messmodells.

528

Fallstudien des Informationsmanagements

Potenzieller Kunde1

Potenzieller Kunde2

ASP1

ASP2

Verlags- und Druckereiwesen

Produktion und Handel von Freizeitmöbeln

Softwarehersteller mit Unternehmenssparte ASP

Start-upASP

Mitarbeiter

150

250

150

25

Gründungsjahr

1948

2001

1972

2000

Umsatz [EUR]

9 Millionen

38 Millionen

14 Millionen

k.A.

Unternehmen Branche

Abb. FSERF-4: Unternehmensprofile

Gemäß Arbeitsschritt 8 wird zur Darstellung und Interpretation der Untersuchungsergebnisse ein Prioritäts-Leistungs-Portfolio mit allen untersuchten ASP angefertigt (Abbildung FSERF-5). Die von ASP1 angebotene Leistung entspricht aus Sicht beider potenzieller Kunden den Anforderungen. Die Leistungslinie von ASP1 schneidet die beiden Prioritätslinien der potenziellen Kunden über der 45º-Diagonalen. Die von ASP2 angebotene Leistung entspricht lediglich aus Sicht des potenziellen Kunden1 den Anforderungen. Die Leistungslinie von ASP1 schneidet die Prioritätslinie des potenziellen Kunden1 oberhalb und die des potenziellen Kunden2 unterhalb der 45º-Diagonalen. 7 6 ASP1 (5,47)

Leistung

5

ASP2 (4,85)

4 3

Potenzieller Kunde1 (4,58) Potenzieller Kunde2 (5,13)

2 1

1

2

3

4 Priorität

5

6

7

Abb. FSERF-5: Prioritäts-Leistungs-Portfolios (PLP2)

Bisher wurde angenommen, dass beide potenzielle Kunden risikofreudig sind. Daraus folgt, dass die Streuung der Werte, auf deren Basis die Werte der Leistungslinien errechnet wurden, bedeutungslos ist. Für risikoscheue Kunden ist die Streuung der Werte von Bedeutung.

Fallstudie Erfolgsfaktorenanalyse (FSERF)

529

Unter der Annahme, dass die bei den Referenzkunden ermittelte Leistung normal verteilt ist, kann für jeden ASP die Wahrscheinlichkeit ermittelt werden, mit der die Leistung unterhalb der Qualitätsgrenze liegt. Für ASP1 ergibt sich eine Leistung von 5,47 (ø); die Standardabweichung beträgt 1,24 (S). Für ASP2 ergibt sich eine Leistung von 4,85 (ø) bei einer Standardabweichung von 0,95 (S). Im Folgenden wird der Lösungsweg für Fragen dargestellt, deren Beantwortung in der Praxis für potenzielle Kunden von Interesse ist. Für den potenziellen Kunden1 ist folgende Frage von Interesse: Wie groß ist die Wahrscheinlichkeit, dass die Leistung von ASP1 bzw. ASP2 kleiner als 4,58 ist? Es sei in Erinnerung gerufen, dass der Wert 4,58 die Priorität vom potenziellen Kunden1 ist. Die Frage kann auch anders formuliert werden: Wie groß ist die Wahrscheinlichkeit, dass die Leistung von ASP1 bzw. ASP2 unter die Qualitätsgrenze (= 45°Diagonale) fällt? Gesucht ist die Wahrscheinlichkeit P (x < 4,58) der Variablen „x = Leistung von ASP1“. Durch Transformation z 

xø wird die standardisierte NormalverteiS

lung: P (x < 4,58) = P ( z  4,58  5,47 ) = P ( z < - 0,72). Der Normalverteilungstabelle (eine 1,24

solche ist in vielen Statistik-Lehrbüchern enthalten) kann entnommen werden, dass dem Argument k = 0,72 der Wert F(k) = 0,764238 zugeordnet ist. Aufgrund des Zusammenhangs F(-k) = 1 - F(k) ergibt sich F(- 0,72) = 1 - 0,764238 = 0,235762. Die Wahrscheinlichkeit, dass die Leistung von ASP1 unter die Qualitätsgrenze fällt, beträgt daher 23,5762 %. Gesucht ist außerdem die Wahrscheinlichkeit P (y < 4,58) der Variablen „y = Leistung von ASP2“. P ( z  4,58  4,85 ) = P ( z < - 0,28). Dem Argument k = 0,28 ist der Wert F(k) = 0,610261 0,95 zugeordnet. F(- 0,28) = 1 - 0,610261 = 0,389739. Die Wahrscheinlichkeit, dass die Leistung von ASP2 unter die Qualitätsgrenze fällt, beträgt daher 38,9739 %. Als Fazit wird festgehalten, dass die Leistung von ASP2 im Vergleich zu ASP1 mit einer um 15,3977 % höheren Wahrscheinlichkeit unter der Qualitätsgrenze liegt.

Praxistauglichkeit Die Praxistauglichkeit des Messmodells wird mit Testgütekriterien beurteilt, die sich aus der Testtheorie ableiten lassen. Aus den Feldstudien resultierende Erkenntnisse werden im Folgenden nach Testgütekriterien gegliedert dargestellt. 



Anzahl und Güte der Qualitätsmerkmale: Ein quantitatives Maß zur Beurteilung der Güte gibt es nicht. Deshalb wurden zwei Management-Foren mit ASP-Experten, Anbietern von ASP-Lösungen und potenziellen Kunden veranstaltet. Unter den Teilnehmern bestand Einvernehmen darüber, dass die 26 Qualitätsmerkmale ASP-Qualität ausreichend genau abbilden. Beurteilbarkeit: Diese wird mit der Anzahl der missing items gemessen, die mit 2,65 % bei der Priorität vernachlässigbar klein, bei der Leistung mit 15,08 % jedoch hoch ist. In beiden Fragebögen wurden die Beurteiler ausdrücklich angehalten, keine Beurteilung vorzunehmen, wenn die Erklärung eines Qualitätsmerkmals nicht ausreichend verständlich ist oder wenn sie sich als Beurteiler überfordert fühlen. Inwieweit dieser Aufforderung nachgekommen wird, lässt sich nicht feststellen.

530

Fallstudien des Informationsmanagements

Die Praxistauglichkeit wird durch den Nutzungsgrad von ASP-Lösungen beeinflusst, weil bei einem geringen Nutzungsgrad die errechneten Leistungen auf den Urteilen weniger Referenzkunden beruhen. Bei den Feldstudien war nur ein Mitarbeiter je Referenzkunde bereit, die Leistung zu beurteilen. Durch die Befragung nur eines Informanten kann ein Messfehler entstehen, der zu Einschränkungen der Validität der Messergebnisse führen kann. (In Arbeitsschritt 6 ist vorgesehen, dass mehrere Benutzer die Leistung beurteilen.) In der Fachliteratur wird ein solcher Messfehler als Informant Bias bezeichnet. Befunde einer empirischen Untersuchung zu den Erfolgsfaktoren für Innovationen zeigen, dass der Informant Bias die Konstruktvalidität von Messinstrumenten so reduzieren kann, dass ein Hypothesentest unmöglich wird; daraus folgt, dass viele Konstrukte (hier die Leistung des ASP) auf Basis einzelner Informanten nicht valide gemessen werden können. In der Fachliteratur wird deshalb gefordert, dass die Befragten kompetent sind, um den jeweiligen Sachverhalt beurteilen zu können. Dadurch wird der durch Wissensdefizite entstehende Messfehler reduziert. Daraus folgt für das Messmodell ASP-Qualität, dass Befragte über Erfahrung mit der Leistung des ASP verfügen müssen. Im Allgemeinen haben IT-Leiter und Leiter des Rechnungswesens Kontakt zu den Benutzern des ausgelagerten ERP-Systems, folglich sind ihnen die Erfahrungen der Benutzer über die Leistung der Qualitätsmerkmale bekannt. Es kann daher angenommen werden, dass solche Key Informants zuverlässige Angaben zur Leistung machen können. Befunde der empirischen Untersuchung zu den Erfolgsfaktoren für Innovationen zeigen aber auch, dass durch die Befragung von Key Informants ein Informant Bias nicht verhindert werden kann, weil Kompetenz oft direkt mit Verantwortung für den zu beurteilenden Sachverhalt zusammenhängt. Dies erhöht die Wahrscheinlichkeit des Auftretens eines aus der persönlichen Betroffenheit resultierenden Messfehlers. Komplexe Sachverhalte – wie die Beurteilung der Leistung eines ASP – sollten daher von mehreren Informanten beurteilt werden. In den Feldstudien stand aber nur ein Informant je Referenzkunde für die Leistungsbeurteilung zur Verfügung, was bei der Beurteilung der Validität der Messergebnisse als negativer Einflussfaktor zu berücksichtigen ist.  



Durchführungszeitraum / Zeitaufwand: Der Prozess der Qualitätsbestimmung dauerte etwa einen Monat. Der Zeitaufwand des Projektbegleiters betrug eine Woche. Kosten: Die Kosten für einen Projektbegleiter berechnen sich aus dem Zeitaufwand bewertet mit dem vereinbarten Honorarsatz. Unter der Annahme, dass das Honorar eines externen Projektbegleiters oder die Opportunitätskosten eines Mitarbeiters 1000 EUR / Tag betragen, entstehen Kosten in der Höhe von 7000 EUR. Nicht eingerechnet sind die Kosten der Datenerhebung, die je nach Erhebungsmethode (Hardcopy-Fragebogen, Telefon- oder Online-Befragung) variieren. Es kann daher angenommen werden, dass die Unternehmensgröße der potenziellen ASP-Kunden ein Einflussfaktor für die Einsatzhäufigkeit des Messmodells ist. Nützlichkeit: Ein Test ist dann nützlich, wenn er ein Merkmal misst oder vorhersagt, für dessen Untersuchung ein praktisches Bedürfnis besteht. Ein Test hat folglich eine hohe Nützlichkeit, wenn er in seiner Funktion durch keinen anderen Test substituiert werden kann, und er hat eine geringe Nützlichkeit, wenn er ein Merkmal prüft, das mit einer Vielzahl anderer Tests ebenso gut untersucht werden könnte.

Fallstudie Erfolgsfaktorenanalyse (FSERF)

531

Aufgaben- und Methodenverweise Strategieentwicklung (STRAT); Erfolgsfaktorenanalyse (Lerneinheit ERFAN); Serviceebenen-Vereinbarungen (Lerneinheit SEVER). Quellen Riedl, R.: Analytischer Hierarchieprozess vs. Nutzwertanalyse: Eine vergleichende Gegenüberstellung zweier multiattributiver Auswahlverfahren am Beispiel Application Service Providing. In: Fink, K. / Ploder, C. (Hrsg.): Wirtschaftsinformatik – Schlüssel zum Unternehmenserfolg. Wiesbaden 2006, 99–127 Riedl, R.: Application Service Providing – Entwicklung eines Modells zur Qualitätsmessung. Wiesbaden 2005 Vertiefungsliteratur Siehe dazu die in den beiden Quellen angegebene Literatur. Normen DIN EN ISO 9000:2005. Qualitätsmanagement-Systeme, Grundlagen und Begriffe

Fallstudie Lebenszyklusmanagement (FSLEM) Ausgangssituation Die Stadtwerke München GmbH (SWM) erzielte im Jahr 2007 einen Konzernumsatz von 4,7 Milliarden Euro in den Geschäftsfeldern Strom (52 % Umsatzanteil), Erdgas (24 %), Verkehr (7 %), Fernwärme (6 %), Telekommunikation (3 %), Wasser (3 %) sowie Bäder und Sonstige (5 %). Der Geschäftsbereich Informations- und Prozesstechnik bietet im Konzern Dienstleistungen für Informations-, Telekommunikations- und Automatisierungstechnik an. Der Bereich entwickelt und betreibt unter anderem ein Data Warehouse (DW), mit dem Daten von ca. 1,3 Millionen Privat- und Geschäftskunden (u. a. Adressdaten, Verbrauchswerte, Tarife, Rechnungen) sowie Controlling-, Personal-, Finanz- und Materialwirtschaftsdaten der SWM verwaltet werden. Im März 2008 hatte das Data Warehouse ein Datenvolumen von ca. 1,1 Terabyte. Mehr als 680 Benutzer arbeiteten regelmäßig mit dem System. Die Fallstudie fokussiert auf das Information Lifecycle Management (ILM) (vgl. Lerneinheit LEMAN).

Problemstellung Im März 2008 betrug das Verhältnis von genutztem Speicherplatz zum zur Verfügung stehenden Speicherplatz in dem Data Warehouse ca. 80 %. Sobald die Speicherplatzauslastung einen bestimmten Grenzwert überschreitet, muss die Speicherkapazität von den Administratoren erweitert werden, da es sonst – insbesondere bei Datenladevorgängen – zu Systemausfällen kommen kann. Beim Einfügen, Ändern oder Löschen von großen Datenmengen kann die physische Datenstruktur degenerieren (z. B. kann es zu unzureichender Speicherplatzausnutzung, Segmentfragmentierung oder fehlerhaften Sortierungen kommen). Dies führt zu erhöhten Speicher- und Verwaltungskosten und die Leistungsfähigkeit des Systems verschlechtert sich. Ein fortgesetztes Wachstum des vom Data Warehouse verwalteten Datenbestands hätte zu steigendem Speicherplatzbedarf, häufigeren Datenbankreorganisationen sowie steigenden Kosten für die Datenverwaltung geführt. Deshalb wurde es notwendig, das Wachstum des genutzten Speicherplatzes durch regelmäßiges Archivieren und Löschen nicht mehr benötigter Daten gezielt zu begrenzen.

Untersuchungsziel Das Ziel der Untersuchung bestand darin, zu beurteilen, ob und in welchem Maße die Administration des Data Warehouse durch die Einführung von Information Lifecycle Management entlastet werden kann. Insbesondere war zu ermitteln,  

welche Kriterien sich für die Klassifizierung von Daten des Data Warehouse bei der SWM eignen, welcher Anteil der Daten für eine Verlagerung auf die Nearline- bzw. die Offline-Ebene oder die Löschung in Frage kommt und

534



Fallstudien des Informationsmanagements

ob der benötigte Speicherplatz der Online-Ebene deutlich verringert werden kann, um dadurch Speicherkosten zu senken.

Die Untersuchung hatte explorativen Charakter. Sie sollte erste Hinweise auf die Praktikabilität des Information Lifecycle Managements bei der SWM geben. Es war nicht beabsichtigt, alle relevanten Aspekte zu berücksichtigen oder eine Wirtschaftlichkeitsanalyse (vgl. Lerneinheit WIMAN) durchzuführen.

Untersuchungsdesign Die Untersuchung wurde mit dem in der Lerneinheit LEMAN dargestellten Phasenmodell des Information Lifecycle Managements nach Matthesius/Stelzer strukturiert. Die empirischen Daten wurden durch Interviews mit Mitarbeitern der SWM, teilnehmende Beobachtung und Analyse von Metadaten im Statistikmodul des Data Warehouse gewonnen. Zur Durchführung der Fallstudie war es notwendig, das Phasenmodell zu konkretisieren und ein Verfahren zur Klassifizierung der Daten des Data Warehouse zu entwickeln. Der Kern des Verfahrens besteht in der Zuweisung von Werten, mit denen die Daten in eine der Klassen Online, Nearline, Offline oder Löschen eingeordnet werden. Eine Klasse bezeichnet hier die Gesamtheit der Daten, die auf der gleichen Ebene eingeordnet werden sollen. Folgende Anforderungen wurden an das Verfahren gestellt: 

 

 

Die Wertzuweisung zur Klassifizierung der Daten soll weitgehend automatisch durchgeführt werden können, damit die Kosten der Klassifizierung nicht den Nutzen übersteigen, der durch die Verlagerung von Daten auf kostengünstigere Speichermedien entsteht. Für die Klassifizierung der Daten müssen geeignete Metadaten verfügbar sein. Nicht alle für die Klassifizierung der Daten notwendigen Metadaten können automatisiert erhoben werden. Wissen der Benutzer und Administratoren muss in dem Verfahren berücksichtigt werden können. Dies gilt insbesondere für rechtliche Anforderungen und zukünftig zu erwartende Zugriffe auf Daten, die sich aus der bisherigen Nutzung nicht ableiten lassen. Wenn zur Klassifizierung der Daten mehrere Kriterien verwendet werden, müssen diese zu einer Kennzahl, dem Klassifizierungswert, verdichtet werden können. Da die Klassifizierung der Daten regelmäßig durchgeführt werden muss, darf diese die Leistungsfähigkeit des Data-Warehouse-Systems nicht merklich beeinträchtigen.

Ablauf der Untersuchung Die Untersuchung wurde zwischen November 2007 und Mai 2008 durchgeführt. Der erste Abschnitt (Analyse der IS-Architektur) des Phasenmodells von Matthesius/Stelzer musste nicht durchgeführt werden, da die Untersuchung auf die Analyse des Datenbestands eines Data Warehouse eingegrenzt und die darauf zugreifenden Anwendungssysteme sowie deren Verbindungen bereits bekannt waren.

Fallstudie Lebenszyklusmanagement (FSLEM)

535

Ermittlung der Größe und des Wachstums des Datenbestands Größe und Wachstum des Datenbestands konnten dem Statistikmodul des Data-WarehouseSystems entnommen werden. Im März 2008 umfasste es 207 Data Cubes, 63 Datenträgerobjekte und ca. 4000 Abfragen (Queries). Data Cubes und Datenträgerobjekte werden im Folgenden zusammengefasst und als Datenobjekte bezeichnet. Abbildung FSLEM-1 zeigt die Entwicklung des vom Data Warehouse genutzten Speicherplatzes zwischen Februar 2007 und März 2008 sowie eine Prognose des benötigten Speicherplatzes zwischen April 2008 und März 2009. Die Prognose basiert auf der Aussage der Systemadministratoren, dass auch in Zukunft mit einer ähnlichen oder sogar höheren Wachstumsrate zu rechnen ist. Wegen des hohen Datenwachstums werden in regelmäßigen Abständen Datenbankreorganisationen durchgeführt, bei denen der Speicherplatz gelöschter Daten freigegeben wird. Durch eine Datenbankreorganisation im Juli 2007 konnte der benötigte Speicherplatz des Data Warehouse um ca. 11 % verringert werden. Zukünftige Datenbankreorganisationen und entsprechende Speicherplatzfreigaben wurden bei der Prognose berücksichtigt. 1.800

Speicherplatz in Gigabyte

1.600 1.400 1.200 1.000 800 600 400 200

gemessene Speicherplatznutzung prognostizierte Speicherplatznutzung

0

Abb. FSLEM-1: Entwicklung und Prognose des Speicherplatzes des Data Warehouse

Trotz der Datenbankreorganisation wuchs der benötigte Speicherplatz in den 14 Monaten von Februar 2007 bis März 2008 um ca. 38 %. Für die folgenden Monate war mit einem ähnlichen Wachstum zu rechnen.

Auswahl geeigneter Gegenstände Als Gegenstände des Information Lifecycle Managements kommen in einem Data Warehouse einzelne Datensätze oder themenorientierte Zusammenfassungen von Datensätzen (z. B. Data Cubes) in Betracht. Die Analyse einzelner Datensätze würde einerseits eine detaillierte Klassifizierung und fein granulare Verlagerung der Elemente des Datenbestands

536

Fallstudien des Informationsmanagements

möglich machen. Andererseits würde dies eine hohe Rechenleistung erfordern und die Leistung des Systems negativ beeinflussen. Außerdem könnten bei einer Verlagerung einzelner Datensätze bestimmte Abfragen eventuell nicht mehr korrekt ausgeführt werden. Deshalb wurden der Untersuchung nicht einzelne Datensätze, sondern themenorientierte Zusammenfassungen von Datensätzen (Datenobjekte) zu Grunde gelegt.

Festlegung von Klassifizierungskriterien Zur Klassifizierung von Daten ist eine Vielzahl von Kriterien vorgeschlagen worden (vgl. z. B. Chen, Kosler/Matthesius/Stelzer oder Turczyk et al.). Das häufig vorgeschlagene Kriterium Wert einer Information für das Unternehmen wurde nicht in Betracht gezogen, da es für die Entscheidung, auf welchem Medium die entsprechenden Daten gespeichert werden sollen, irrelevant ist. In Abstimmung mit den verantwortlichen Mitarbeitern der SWM wurden folgende Kriterien näher erörtert:     

Anzahl der Zugriffe auf ein Datenobjekt, Zeitraum seit letztem Zugriff auf ein Datenobjekt, Alter eines Datenobjekts, Größe eines Datenobjekts sowie Ausmaß der Verbindungen eines Datenobjekts mit anderen Komponenten des Data Warehouse.

Die Anzahl der Zugriffe auf ein Datenobjekt ist das zentrale Kriterium zur Klassifizierung im Information Lifecycle Management. In die Untersuchung wurden lediglich lesende Zugriffe einbezogen. Änderungen der Struktur von Datenobjekten oder das Laden von Daten wurden nicht berücksichtigt. Im Untersuchungszeitraum umfasste das Data Warehouse 270 Datenobjekte. Bei der Ermittlung von Zugriffshäufigkeiten wurde festgestellt, dass es sowohl Datenobjekte mit mehr als 7000 Zugriffen pro Tag gibt als auch Datenobjekte, auf die bis zum Untersuchungszeitraum nie zugegriffen worden war. Anschließend wurde untersucht, ob die Wahrscheinlichkeit des Zugriffs auf ein Datenobjekt umso geringer ist, je länger der letzte Zugriff zurück liegt. Ist dies der Fall, kann die seit dem letzten Zugriff vergangene Zeit als Klassifizierungskriterium verwendet werden. Für diese Untersuchung wurde eine Stichprobe von ca. 100 repräsentativ ausgewählten Datenobjekten verwendet, deren Zugriffsprotokolle analysiert wurden. Dabei wurde der Zeitraum zwischen zwei aufeinander folgenden Zugriffen auf ein Datenobjekt in Tagen berechnet. In Abbildung FSLEM-2 sind die kumulierten Zugriffswahrscheinlichkeiten in Abhängigkeit von der Zeit dargestellt, die seit einem Zugriff vergangen ist. Zur Vereinfachung wurden jeweils 7 bzw. 8 Tage zu einer Zugriffsklasse zusammengefasst. Die erste Zugriffsklasse umfasst alle Zugriffe, bei denen innerhalb von 0 bis 7 Tagen erneut auf das gleiche Datenobjekt zugegriffen wurde. Die zweite Zugriffsklasse enthält alle Zugriffe, bei denen innerhalb von 8 bis 14 Tagen erneut auf das gleiche Datenobjekt zugegriffen wurde usw. Die Abbildung zeigt, dass es einen Zusammenhang zwischen dem Zeitraum seit dem letzten Zugriff auf ein Datenobjekt und der Wahrscheinlichkeit gibt, mit der auf dieses Datenobjekt erneut zugegriffen wird. Auf 86 % der Datenobjekte, auf die ein Zugriff erfolgt ist, wird in der kommenden Woche wieder zugegriffen. Liegt der Zeitpunkt des letzten Zugriffs auf Datenobjekte bereits 8 bis 14 Tage zurück, wird in der folgenden Woche nur noch auf 14 % dieser Datenobjekte zugegrif-

Fallstudie Lebenszyklusmanagement (FSLEM)

537

fen. Bei einem Zeitraum von drei Wochen seit dem letzten Zugriff liegt die Zugriffswahrscheinlichkeit bei 7 %. Von den Datenobjekten, auf die seit mehr als 10 Wochen nicht mehr zugriffen wurde, werden in der kommenden Woche lediglich weniger als 1 % für lesende Zugriffe benötigt. Der Zeitraum, der seit dem letzten Zugriff vergangen ist, kann als Kriterium für die Klassifizierung von Datenobjekten im Data Warehouse der SWM verwendet werden. 90,00%

Zugriffswahrscheinlichkeit

80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% 1

3

5

7

9

11 13 15 17 19 21 23 25 Anzahl Wochen seit letztem Zugriff

27

29

31

33

Abb. FSLEM-2: Zeitraum seit letztem Zugriff auf ein Datenobjekt und Zugriffswahrscheinlichkeit

Untersuchungen von Chen an Dateisystemen legen nahe, dass es einen Zusammenhang zwischen dem Alter eines Objektes und der Wahrscheinlichkeit gibt, mit der auf dieses Objekt zugegriffen wird. Auf jüngere Objekte wird häufiger zugegriffen als auf ältere. Deshalb wurde untersucht, ob dieser Zusammenhang auch für die Datenobjekte des Data Warehouse der SWM besteht. Zu diesem Zweck wurden Zugriffe auf mehr als 75 zufällig ausgewählte Datenobjekte, die seit mindestens drei Jahren bestehen, in deren ersten drei „Lebensjahren“ untersucht. Zunächst wurde das Erstellungsdatum der Datenobjekte ermittelt und anschließend, wie häufig und zu welchen Zeitpunkten auf diese Datenobjekte zugegriffen wurde. Um eine übersichtliche Darstellung zu erhalten, wurden jeweils die Zugriffe eines Monats zusammengefasst. Die Ergebnisse sind in Abbildung FSLEM-3 dargestellt. Es ist nur eine leichte Abnahme der Anzahl der Zugriffe auf Datenobjekte im Laufe des Lebenszyklus zu beobachten. Auf ältere Datenobjekte wird ähnlich häufig zugegriffen wie auf jüngere. Das Alter wurde deshalb nicht als Kriterium für die Klassifizierung von Datenobjekten im Data Warehouse der SWM verwendet. Außerdem wurde untersucht, ob es einen Zusammenhang zwischen der Größe von Datenobjekten und der Häufigkeit gibt, mit der auf diese zugegriffen wird. Zu diesem Zweck wurden ca. 160 unterschiedlich große Datenobjekte zufällig ausgewählt und deren Größe sowie die Anzahl der Zugriffe bestimmt. Mit einer Korrelationsanalyse wurde überprüft, ob es einen linearen Zusammenhang zwischen der Größe und der Anzahl der Zugriffe auf diese Objekte gibt. Der dabei ermittelte Korrelationskoeffizient hatte den Wert -0,02. Aus der

538

Fallstudien des Informationsmanagements

Größe der Datenobjekte kann also nicht auf die Anzahl der Zugriffe geschlossen werden. Die Größe der Datenobjekte wurde deshalb ebenfalls nicht als Kriterium zur Klassifizierung verwendet. 300

Anzahl Zugriffe

250 200 150 100 50 0 1

3

5

7

9

11 13 15 17 19 21 23 25 Alter von Datenobjekten in Monaten

27

29

31

33

Abb. FSLEM-3: Alter von Datenobjekten und Zugriffshäufigkeit

Die Datenobjekte eines Data Warehouse sind unterschiedlich intensiv mit anderen Komponenten des Data Warehouse verbunden. Einige Datenobjekte empfangen Daten aus operativen Datenbanken, stellen Daten für andere Datenobjekte bereit, empfangen Daten aus anderen Datenobjekten oder werden durch viele Abfragen aufgerufen. Je intensiver die Verbindungen zwischen einem Datenobjekt und anderen Komponenten eines Data Warehouse sind, desto weniger eignet sich das Datenobjekt für eine Verlagerung auf die Nearline oder Offline-Ebene oder für eine Löschung. Datenobjekte, die keine oder nur wenige Verbindungen zu anderen Objekten des Data Warehouse haben, eignen sich dagegen gut für eine Verlagerung oder Löschung. Das Ausmaß der Verbindungen zwischen einem Datenobjekt und anderen Komponenten des Data Warehouse wird als Verbindungsgrad bezeichnet.

Festlegung von Messmethoden und Messgrößen Von den im vorhergehenden Abschnitt diskutierten Kriterien wurden folgende für die Klassifizierung von Datenobjekten verwendet:   

Anzahl der Zugriffe; hier als Zugriffswert zw bezeichnet, Zugriffswahrscheinlichkeit lz, hier bestimmt durch den Zeitraum seit dem letzten Zugriff auf ein Datenobjekt, und Ausmaß der Verbindungen eines Datenobjekts mit anderen Komponenten des Data Warehouse, hier als Verbindungsgrad vg bezeichnet.

Eine Korrelationsanalyse ergab, dass die drei Kriterien nicht linear voneinander abhängig sind. Anschließend wurden eine Messmethode und Messgrößen bestimmt. Das Ziel der Messmethode besteht darin, jedem Datenobjekt einen Wert zuzuweisen, mit dem dieses in

Fallstudie Lebenszyklusmanagement (FSLEM)

539

eine der vier Klassen Online, Nearline, Offline oder Löschen eingeordnet werden kann. Da die drei dazu vorgesehenen Kriterien unterschiedliche Dimensionen haben, mussten diese zunächst normiert werden. Es wurde eine Normierung der Werte aller drei Kriterien auf das Intervall [0, 100] vorgenommen. Folgende Formel diente dazu, die Kriterien k für die Objekte i zu normieren: k inorm 

k i  min k  (max norm  min norm )  min norm max k  min k

Dabei stellt mink das Minimum und maxk das Maximum der Ausprägungen des Kriteriums k dar. Zur Festlegung der Zugriffswerte wurden die 270 Datenobjekte in 16 Klassen eingeteilt und diesen jeweils ein bestimmter Zugriffswert zugeordnet. Datenobjekte, auf die bis zum Untersuchungszeitraum nicht zugegriffen worden war, wurden in die Zugriffsklasse 1 mit dem Zugriffswert 0 eingeordnet. Datenobjekte, auf die bereits mehr als 1750 Mal zugegriffen worden war, wurde die Zugriffsklasse 16 und der Zugriffswert 15 zugeordnet. Einige Datenobjekte mit sehr hohen Zugriffszahlen wurden als Ausreißer klassifiziert. Es handelt sich dabei um Datenobjekte, auf die zur Berechnung bestimmter systeminterner Kennzahlen sehr häufig zugegriffen wird. Abbildung FSLEM-4 zeigt die Zugriffsklassen j, die Klassengrenzen, die Zugriffswerte zw und die normierten Zugriffswerte zwnorm für die Datenobjekte. Die normierten Zugriffswerte wurden mit folgender Formel berechnet:

zw jnorm  Zugriffsklasse j 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

zw j  min zw max zw  min zw

Anzahl Zugriffe im Intervall von bis 0 0 1 125 126 250 251 375 376 500 501 625 626 750 751 875 876 1000 1001 1125 1126 1250 1251 1375 1376 1500 1501 1625 1626 1750 1751 …

 100

Zugriffswert zw 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Normierter Zugriffswert zwnorm 0,00 6,67 13,33 20,00 26,67 33,33 40,00 46,67 53,33 60,00 66,67 73,33 80,00 86,67 93,33 100,00

Abb. FSLEM-4: Zugriffsklassen und Zugriffswerte

540

Fallstudien des Informationsmanagements

Um den Datenobjekten anhand der Tage, die seit dem letzten Zugriff vergangen sind, eine Zugriffswahrscheinlichkeit zuzuordnen, wurden die aus der Stichprobe ermittelten kumulierten Zugriffswahrscheinlichkeiten herangezogen (vgl. hierzu den Abschnitt Festlegung von Klassifizierungskriterien). Abbildung FSLEM-5 zeigt die Wahrscheinlichkeitsklassen j, die Klassengrenzen, die absoluten und die relativen Häufigkeiten, die Zugriffswahrscheinlichkeiten lz und die normierten Zugriffswahrscheinlichkeiten lznorm für die Datenobjekte. Es ist lediglich ein Ausschnitt der Wahrscheinlichkeitsklassen und der zugehörigen Werte dargestellt. Die normierten Zugriffswahrscheinlichkeiten wurden mit folgender Formel berechnet: lz j  min lz  100 lz jnorm  max lz  min lz Wahrscheinlichkeitsklasse j 1 2 3 4 5 6 7 8 9 … 33

Anzahl Tage seit letztem Zugriff im Intervall von

0 8 15 22 29 36 43 50 57 … 225

bis

7 14 21 28 35 42 49 56 63 … …

absolute Häufigkeit

relative Häufigkeit

Zugriffswahrscheinlichkeit

z 2070 170 69 37 22 7 6 5 4 … 0

lz 0,8571 0,0704 0,0286 0,0153 0,0091 0,0029 0,0025 0,0021 0,0017 … 0,0000

h 85,71 % 14,29 % 7,25 % 4,39 % 2,86 % 1,95 % 1,66 % 1,41 % 1,20 % … 0,04 %

normierte Zugriffswahrscheinlichkeit lznorm 100,00 16,63 8,41 5,07 3,29 2,22 1,88 1,59 1,35 … 0,00

Abb. FSLEM-5: Wahrscheinlichkeitsklassen und Wahrscheinlichkeitswerte

In Abhängigkeit vom Verbindungsgrad wird den Datenobjekten ein Wert zwischen 0 und 100 zugewiesen. Datenobjekte, die Daten aus operativen Quellsystemen erhalten und Daten für andere Datenobjekte bereitstellen, erhalten den Wert 100. Datenobjekte, die Daten aus operativen Quellsystemen oder anderen Datenobjekten erhalten, aber weder Daten für andere Datenobjekte noch für Abfragen zur Verfügung stellen, bekommen den Wert 50 zugewiesen. Den gleichen Wert erhalten Datenobjekte, die Daten für andere Datenobjekte oder Abfragen zur Verfügung stellen, aber keine Daten von anderen Datenobjekten oder operativen Quellsystemen erhalten. Datenobjekte, die nicht mit anderen Komponenten des Data Warehouse verbunden sind, bekommen den Wert 0 zugewiesen. Da der Verbindungsgrad bereits in Werten zwischen 0 und 100 ausgedrückt ist, war keine Normierung notwendig. Um festzustellen, ob die drei Kriterien für die Berechnung des Klassifizierungswertes den gleichen Stellenwert haben, wurden sechs Mitarbeiter der SWM gebeten, den drei Kriterien Gewichte zuzuordnen. Die von den Mitarbeitern genannten Gewichte wurden gemittelt und normiert. Dabei ergaben sich folgende normierte Gewichte:

Fallstudie Lebenszyklusmanagement (FSLEM)

  

541

normiertes Gewicht für den Zugriffswert zw = 0,35, normiertes Gewicht für die Zugriffswahrscheinlichkeit lz = 0,37 und normiertes Gewicht für den Verbindungsgrad vg = 0,28.

Die Klassifizierungswerte wz für die Datenobjekte i wurden mit folgender Formel berechnet: wzi = 0,35 zwj norm + 0,37 lzj norm + 0,28 vgi (Objekt i  Klasse j)

Erhebung von Messwerten Die Werte der Klassifizierungskriterien für die 270 Datenobjekte werden mit Programmen erhoben, die von Mitgliedern des Projektteams entwickelt wurden. Die Programme werten die vom Data Warehouse gespeicherten Metadaten aus und verarbeiten sie mit dem zuvor dargestellten Verfahren, dessen Ergebnis ein Klassifizierungswert für jedes Datenobjekt ist. Mit diesem Wert wird jedes Datenobjekt in eine der vier Klassen Online, Nearline, Offline oder Löschen eingeteilt. Zuvor mussten die Klassengrenzen festgelegt werden. Da die Festlegung der Grenzen nicht automatisch erfolgen kann, wurden hierzu Mitarbeiter der SWM befragt. Folgende Grenzwerte wurden bestimmt: Alle Objekte mit dem Klassifizierungswert 0 werden in die Klasse Löschen eingeordnet. Die anderen Klassen wurden gleich breit gestaltet. Abbildung FSLEM-6 zeigt, in welche Klassen die Datenobjekte in Abhängigkeit von ihrem Klassifizierungswert eingeteilt wurden. In der Abbildung ist außerdem angegeben, wie viele Datenobjekte den vier Klassen zugeordnet wurden, wie groß der jeweilige Speicherbedarf ist und welchen Anteil die vier Klassen am Gesamtspeicherbedarf haben. Klasse

Klassifizierungswerte

Anzahl Datenobjekte

Größe [GB]

Anteil Speicherbedarf

Online

[100; 67]

34

62,55

10,35 %

Nearline

[66; 34]

84

385,83

63,82 %

Offline

[33; 0)

121

156,01

25,81 %

Löschen

0

31

0,16

0,03 %

Abb. FSLEM-6: Einteilung der Datenobjekte in Klassen

Interpretation und Ergänzung der Messwerte Vor der Verlagerung der Datenobjekte bestand die Möglichkeit, die Vorschläge zur Verlagerung und Löschung von Daten zu interpretieren und – wenn nötig – zu ergänzen. Insbesondere war zu prüfen, ob Serviceebenen-Vereinbarungen (vgl. Lerneinheit SEVER) oder rechtliche Anforderungen einer Verlagerung auf die Nearline- oder Offline-Ebene bzw. der Löschung von Daten entgegenstehen. Dies war nicht der Fall. Aufgrund des nur geringen Speichervolumens, welches durch eine Löschung von Daten hätte freigegeben werden können, wurde entschieden, zunächst keine Daten zu löschen. Da noch keine ausreichende Anwendungserfahrung mit dem Verfahren vorlag, war es nicht möglich zu prüfen, ob die Grenzen der Klassen sinnvoll gewählt wurden. Sobald das Verfah-

542

Fallstudien des Informationsmanagements

ren einige Jahre im Einsatz ist, kann die Verlagerung der Daten über die Anpassung der Klassengrenzen genauer gesteuert werden.

Ergebnisse der Untersuchung Die Klassifizierung der 270 Datenobjekte zeigt, dass lediglich ca. 10 % des gesamten Speicherbedarfs des Data Warehouse der SWM online gehalten werden müssen. Ca. 90 % des Datenvolumens kann entweder auf die Nearline- oder die Offline-Ebene verlagert werden. Das Klassifizierungsverfahren schlägt 31 Datenobjekte zur Löschung vor, die allerdings insgesamt nur 0,16 Gigabyte oder 0,03 % des gesamten Speicherbedarfs benötigen. Die Untersuchung hat gezeigt, dass Information Lifecycle Management die Administration des Data Warehouse bei der SWM entlasten kann. Ca. 90 % des Datenvolumens eignen sich für eine Verlagerung von der Online- auf die Nearline- oder Offline-Ebene. Auf diese Weise kann der verfügbare Speicherplatz der Online-Ebene deutlich vergrößert werden. Datenladevorgänge könnten wieder ohne Verzögerung durchgeführt werden und die Kosten der Administration des Data Warehouse würden entsprechend sinken. Allerdings müssten neue Speichersysteme für die Nearline- und Offline-Ebene beschafft werden. Speichermedien für diese Ebenen sind preisgünstiger als die für die Online-Ebene.

Beurteilung der Untersuchung Nach der Einführung des Verfahrens in den Routinebetrieb kann dieses zum großen Teil automatisiert durchgeführt werden. Die Datenobjekte des Data Warehouse können in regelmäßigen Abständen klassifiziert werden, ohne dass dazu ein menschlicher Eingriff notwendig ist. Vor der Löschung von Daten sollten Nutzer oder Administratoren befragt werden. Das von der SWM genutzte Data-Warehouse-System lässt die Aufteilung der Daten auf die in der Lerneinheit LEMAN dargestellten Speicherebenen Online, Nearline und Offline bzw. Archivierung zu. Alle für die Klassifizierung von Datenobjekten benötigten Metadaten liegen in dem Data Warehouse vor. Die benötigten Werte können mit dem Statistikmodul des Systems ermittelt werden. Die Klassifizierung der Daten kann regelmäßig automatisch durchgeführt werden, ohne dass dadurch die Leistungsfähigkeit des Systems beeinträchtigt wird. Die Untersuchung gibt Hinweise auf die Praktikabilität des Verfahrens, ist aber keine Analyse der Wirtschaftlichkeit der Einführung und des Betriebs des Information Lifecycle Managements. Zu diesem Zweck müssten die Kosten (z. B. für Beschaffung und Betrieb von Speichersystemen für die Nearline- und Online-Ebene) dem Nutzen (z. B. Kostenreduzierung durch Nutzung preisgünstigerer Speichermedien als der für die Online-Ebene) gegenüber gestellt werden. In diesem Zusammenhang müsste auch geprüft werden, ob die Antwortzeiten bei Zugriff auf ausgelagerte Datenobjekte akzeptabel bleiben. Soll auf Datenobjekte zugegriffen werden, welche sich auf der Nearline- oder Offline-Ebene befinden, müssen diese zunächst in den Onlinespeicher zurück gespeichert werden, bevor sie für die Nutzer verfügbar sind. Weitere Untersuchungen könnten zeigen, ob die dabei auftretenden Ladezeiten für die Nutzer akzeptabel sind.

Fallstudie Lebenszyklusmanagement (FSLEM)

543

In dem Verfahren werden mehrere Kriterien zur Klassifizierung von Datenobjekten verwendet, wodurch die Aussagekraft der Ergebnisse verbessert wird. Durch das Kriterium Zugriffswert werden Objekte, auf die häufig zugegriffen wurde, anders bewertet, als Datenobjekte mit wenigen Zugriffen. Mit der Zugriffswahrscheinlichkeit werden die Zeitpunkte der Zugriffe und damit der Lebenszyklus der Datenobjekte berücksichtigt. Die Verbindungen der Datenobjekte zu anderen Komponenten des Data Warehouse werden im Verbindungsgrad berücksichtigt. Die drei Kriterien wurden gewichtet und deren Werte zu einem Klassifizierungswert zusammengefasst. Eine kritische Analyse ergab folgende Verbesserungsmöglichkeiten: 







Die Gewichte wurden durch Befragung von Nutzern und Administratoren ermittelt. Die Antworten zeugten von einer gewissen Unsicherheit der Befragten, da sie über keine Erfahrung mit der Klassifizierung und Verlagerung von Daten verfügten. Sobald Erfahrungen mit dem Betrieb des Information Lifecycle Managements vorliegen, sollten die Gewichte überprüft und gegebenenfalls angepasst werden. Das Verfahren beruht auf der Annahme, dass aus der bisherigen Nutzung von Datenobjekten auf deren zukünftige Nutzung geschlossen werden kann. Diese Annahme ist für regelmäßig wiederkehrende Datenauswertungen im Data Warehouse angemessen. Für Ad-hoc-Auswertungen trifft die Annahme aber weniger zu, da nicht angenommen werden kann, dass bisherige Ad-hoc-Zugriffe in Zukunft in ähnlicher Weise wiederholt werden. Genauere Analysen der Abfragen und Anwendungen könnten zeigen, welcher Anteil der Datenobjekte davon betroffen ist und ob die Ergebnisse der Untersuchung dadurch in Frage gestellt werden. Das Verfahren analysiert Datenobjekte (d. h. thematische Zusammenfassungen von Datensätzen), aber keine einzelnen Datensätze. Eine Klassifizierung und Verlagerung einzelner Datensätze würde eine deutlich genauere Behandlung des Datenbestands ermöglichen, wäre aber auch mit einem erheblich höheren Rechenaufwand für die Durchführung des Verfahrens verbunden. Es ist zu prüfen, ob eine Klassifizierung und Verlagerung einzelner Datensätze zu besseren Ergebnissen führt. Bei der Klassifizierung von Datenobjekten werden Inhalt bzw. Bedeutung der Datenobjekte nicht berücksichtigt. Das kann dazu führen, dass Datenobjekte, auf die bisher selten zugriffen wurde oder deren Zugriffe lange zurückliegen, für eine Verlagerung vorgeschlagen werden, obwohl für Nutzer oder Administratoren bereits absehbar ist, dass diese Daten in naher Zukunft (z. B. für ein geplantes Projekt) benötigt werden. Wenn Angaben über die voraussichtliche, zukünftige Nutzung von Daten in die Klassifizierung mit eingehen sollen, müssten die Metadaten um ein Merkmal ergänzt werden, das zu einer Verlagerungssperre führt. Die Werte für dieses Merkmal müssten von Nutzern oder Administratoren vergeben werden. Es müsste überprüft werden, wie hoch der dafür notwendige Aufwand ist und ob dadurch die Wirtschaftlichkeit des Verfahrens negativ beeinflusst wird.

Das Verfahren eignet sich in seiner Grundstruktur für die Klassifizierung von Daten auch in anderen Systemen und Unternehmen. Dazu müssen Objekte, Kriterien, Gewichte und Klassengrenzen überprüft und gegebenenfalls durch andere ersetzt werden. In einem solchen Fall

544

Fallstudien des Informationsmanagements

müssten auch die Programme zur Erhebung der Werte für die Klassifizierung der Datenobjekte angepasst werden. Aufgaben- und Methodenverweise Datenmanagement (Lerneinheit DATEM); Lebenszyklusmanagement (Lerneinheit LEMAN); Kennzahlensysteme (Lerneinheit KENNZ). Quellen Chen, Y.: Information Valuation for Information Lifecycle Management. In: Parashar, M. (Hrsg.): Proceedings of the 2nd International Conference on Autonomic Computing. Seattle, Washington 2005, 135–146 Kosler, M. / Matthesius, M. / Stelzer, D.: Ein Konzept zur automatisierten Klassifizierung von Informationen für das Information Lifecycle Management - dargestellt am Beispiel des SAP NetWeaver Business Intelligence. In: Dinter, B. et al. (Hrsg.): DW2008. Synergien durch Integration und Informationslogistik. Lecture Notes in Informatics (LNI) - Proceedings. Bonn 2008, 129–145 Matthesius, M. / Stelzer, D.: Analyse und Vergleich von Konzepten zur automatisierten Informationsbewertung im Information Lifecycle Management. In: Bichler, K. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 471–482 Stadtwerke München GmbH (Hrsg.): Geschäftsbericht 2007. München 2008. http://www.swm.de; Abruf 20. November 2008 Turczyk, L. A. et al.: Eine Methode zur Wertzuweisung von Dateien in ILM. In: Bichler, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 459–470 Vertiefungsliteratur Siehe dazu die in den Quellen und in der Lerneinheit LEMAN angegebene Literatur.

Fallstudie Geschäftsprozessmanagement (FSGPM) Ausgangssituation Im Geschäftsbereich Unterhaltungselektronik eines weltweit tätigen Technologiekonzerns soll die Bearbeitung eingehender Rechnungen verbessert werden. Schwachstellen des Prozesses sind lange Bearbeitungs- und Liegezeiten, finanzielle Verluste durch nicht in Anspruch genommene Skonti sowie ein hoher Personalaufwand. Zur Behebung dieser Probleme soll ein Workflow-Managementsystem eingeführt werden. Fraglich ist, inwiefern dadurch eine effektivere und effizientere Gestaltung des Prozesses möglich wird. Zur Beantwortung dieser Frage führten die Prozessverantwortlichen von Januar bis September 2004 in Zusammenarbeit mit dem Fachgebiet Informations- und Wissensmanagement der TU Ilmenau ein Projekt durch. Ziel des Projektes war es, Verbesserungspotenziale des Prozesses zu ermitteln und die mit der Einführung eines Workflow-Managementsystems verbundenen Veränderungen darzustellen. Das Projekt wurde in die Phasen Prozessanalyse, Prozessverbesserung und Prozessevaluierung gegliedert. In den folgenden Abschnitten werden Inhalt und Ergebnisse der Phasen beschrieben. Die Abfolge der Tätigkeiten zur Bearbeitung eingehender Rechnungen vor der Durchführung des Projektes wird als ursprünglicher und nach Abschluss des Projektes als überarbeiteter Prozess bezeichnet. Da das Unternehmen Wert darauf legt, nicht namentlich genannt zu werden, sind die Angaben anonymisiert und zum Teil verändert worden. Die Aussagekraft der Fallstudie wird dadurch nicht beeinträchtigt. Im folgenden Abschnitt wird der ursprüngliche Prozess zur Bearbeitung eingehender Rechnungen beschrieben. Im dritten Abschnitt wird der überarbeitete Prozess dargestellt und im letzten Abschnitt evaluiert.

Prozessanalyse Beschreibung und Modellierung des ursprünglichen Prozesses Auswertungen von Prozessdokumenten sowie Interviews mit den Prozessverantwortlichen ermöglichten einen ersten Überblick über den Prozess. Weitere Informationen wurden durch teilnehmende Beobachtung sowie Interviews mit Prozessbeteiligten gewonnen. Der Geschäftsbereich Unterhaltungselektronik besteht aus mehreren spezialisierten Tochterunternehmen, die für die Fertigung einzelner Produkte bzw. Produktgruppen verantwortlich sind. Diese Unternehmen sind eigenständig bilanzierende Einheiten. Der Einkauf von Vorprodukten wird für den gesamten Geschäftsbereich vom zentralen Einkauf der Muttergesellschaft durchgeführt. Das entlastet die Tochterunternehmen, ermöglicht die Bündelung von Einkäufen und dient der Standardisierung der Einkaufsprozesse. Warenlieferung, Rech-

546

Fallstudien des Informationsmanagements

nungslegung bzw. -bearbeitung und Zahlungsabwicklung erfolgen direkt zwischen den Tochterunternehmen und den Lieferanten. Die von den Lieferanten in Rechnung gestellten Preise weichen häufig von den durch den zentralen Einkauf ausgehandelten Bestellpreisen ab. Diese Abweichungen werden als Preisdifferenzen bezeichnet. An deren Bearbeitung ist sowohl der zentrale Einkauf der Muttergesellschaft als auch die Finanzbuchhaltung des Tochterunternehmens beteiligt, welches die Rechnung zu begleichen hat. Der Prozess Bearbeitung von Preisdifferenzen ist in drei Teile gegliedert. Alle drei Teilprozesse werden durch ein ERP-System unterstützt. In Abbildung FSGPM-1 sind die Unternehmen und Abteilungen dargestellt, die an dem Prozess beteiligt sind. Zentraler Einkauf Muttergesellschaft Preisverhandlung, Bestellung für Tochterunternehmen

Finanzbuchhaltung Tochterunternehmen A Bearbeitung der Finanzbuchhaltung Preisdifferenzen Tochterunternehmen B Finanzbuchhaltung Tochterunternehmen C Finanzbuchhaltung Tochterunternehmen D Lieferanten

Lieferung, Rechnungslegung

Abb. FSGPM-1: Überblick über die am Prozess beteiligten Unternehmen und Abteilungen

Der erste Teilprozess beginnt mit dem Eingang der Rechnung in der Finanzbuchhaltung eines Tochterunternehmens. Ein Mitarbeiter (im Folgenden als Rechnungskontrolleur bezeichnet) registriert die Rechnung, versieht sie mit einer Identifikationsnummer und digitalisiert den Rechnungsbeleg. Anschließend bucht er die Rechnung und speichert die digitalisierte Belegkopie im ERP-System. Stellt das System beim Buchen der Rechnung eine Differenz zwischen dem Rechnungspreis und dem in der Bestellung hinterlegten Bestellpreis fest, die eine bestimmte Toleranzgrenze übersteigt, sperrt es die Rechnung zur Zahlung. Für jede Rechnungsposition, die eine Preisdifferenz aufweist, wird vom System das Sperrkennzeichen Preisdifferenz gesetzt. Gleichzeitig erhält der Rechnungskontrolleur eine Statusmeldung. Zur weiteren Bearbeitung muss er den zentralen Einkauf über das Vorliegen der Preisdifferenz informieren. Dies erfolgt mit Hilfe des Formulars Preisdifferenz, das in Form einer Textverarbeitungsdatei vorliegt. Der Rechnungskontrolleur muss für jede gesperrte Rechnungsposition ein Formular ausfüllen. Dazu ermittelt er im ERP-System zunächst alle Daten, die in das Formular einzutragen sind (u. a. Lieferantennummer, Lieferantenname, Rechnungsnummer, Identifikationsnummer der gesperrten Rechnung sowie Materialnummer der gesperrten Rechnungsposition). Außerdem muss der Rechnungskontrolleur den für die Bestellung zuständigen Mitarbeiter des zentralen Einkaufs (im Folgenden als Einkäufer bezeichnet) in den Materialstammdaten des ERP-Systems ermitteln. Nach der Dateneingabe speichert der Rechnungskontrolleur das Formular auf seinem Arbeitsplatzrechner oder auf einem abteilungsinternen Netzlaufwerk ab und leitet es per E-Mail an den zuständigen Einkäufer weiter. Im zweiten Teilprozess entscheidet der Einkäufer, ob der Rechnungspreis akzeptiert werden muss. Initiiert wird dieser Teilprozess durch den Eingang des Formulars Preisdifferenz. An-

Fallstudie Geschäftsprozessmanagement (FSGPM)

547

hand der auf dem Formular vermerkten Identifikationsnummer der Rechnung greift der Einkäufer auf die Rechnungsbuchung, den Bestellbeleg und gegebenenfalls auf den digitalisierten Rechnungsbeleg im ERP-System zu. Anschließend überprüft er, ob beim Anlegen der Bestellung der korrekte Bestellpreis hinterlegt wurde oder ob es besondere Vereinbarungen mit dem Lieferanten gibt, die zu einem Preiszuschlag führen könnten. Mögliche Gründe für einen Preiszuschlag sind das Abweichen von Mindestbestellmengen oder das Nichteinhalten von Bestellfristen. Kommt der Einkäufer zu der Entscheidung, dass der Rechnungspreis korrekt ist und die Preisdifferenz akzeptiert werden muss, trägt er dies in das Formular Preisdifferenz ein. Des Weiteren trägt er einen Grund für die Preisdifferenz ein und korrigiert gegebenenfalls nicht korrekte Bestellpreisdaten im ERP-System. Ist der Rechnungspreis nicht korrekt, notiert der Einkäufer dies auf dem Formular Preisdifferenz. Außerdem trägt er den Rechnungspreis, den er für korrekt hält, mit einer kurzen Erläuterung ein. Diese Daten werden als Preisdifferenzdaten bezeichnet. Hat der Einkäufer alle notwendigen Angaben auf dem Formular gemacht, speichert er dieses auf einem abteilungsinternen Netzlaufwerk und sendet das Formular per E-Mail oder per Fax an den zuständigen Rechnungskontrolleur. Im dritten Teilprozess übernimmt wieder der Rechnungskontrolleur der Finanzbuchhaltung des zuständigen Tochterunternehmens die Bearbeitung. Nach Empfang des vom Einkäufer ausgefüllten Formulars archiviert der Rechnungskontrolleur dieses auf einem abteilungsinternen Netzlaufwerk. Wurde das Formular per Fax gesendet, muss der Rechnungskontrolleur das ursprünglich an den Einkäufer gesendete Formular mit den Preisdifferenzdaten selbst aktualisieren. Nach der Archivierung prüft der Rechnungskontrolleur, ob die Preisdifferenz akzeptiert oder abgelehnt wurde. Wurde der Rechnungspreis akzeptiert, löscht er das Sperrkennzeichen Preisdifferenz der betreffenden Rechnungsposition. Die Bearbeitung der Preisdifferenz ist damit beendet. Sobald alle Sperrkennzeichen einer Rechnung entfernt sind, gibt das ERP-System die Rechnung zur Zahlung frei. Stellt der Rechnungskontrolleur bei der Überprüfung des Formulars jedoch fest, dass der Rechnungspreis vom Einkäufer nicht akzeptiert wird, veranlasst er die Berichtigung des Rechnungsbetrages, indem er per E-Mail eine Gutschrift über den zu korrigierenden Betrag beim Lieferanten anfordert. Dieser E-Mail wird das Formular Preisdifferenz als Anlage beigefügt. Stimmt der Lieferant der Gutschrift zu, bucht der Rechnungskontrolleur die Gutschrift im ERP-System, löscht das Sperrkennzeichen Preisdifferenz der entsprechenden Rechnungsposition und beendet die Bearbeitung der Preisdifferenz. Lehnt der Lieferant die Ausstellung einer Gutschrift ab, leitet der Rechnungskontrolleur den Vorgang mit allen Unterlagen an den zuständigen Einkäufer zurück. Dieser muss dann mit dem Lieferanten verhandeln, bis die Preisdifferenz geklärt ist. Die Bearbeitung erfolgt wie zuvor beschrieben; der ursprüngliche Rechnungspreis wird entweder vom Einkäufer akzeptiert oder es wird erneut eine Gutschrift angefordert. Um eine bessere Grundlage für die Prozessverbesserung zu erhalten, wurde der ursprüngliche Prozess als ereignisgesteuerte Prozesskette modelliert. Als Visualisierungs- und Modellierungswerkzeuge kamen Microsoft Visio und ARIS Toolset zum Einsatz. Neben den einzelnen Arbeitsschritten zeigt Abbildung FSGPM-2, welche Arbeitsschritte durch Rechnungskontrolleure bzw. Einkäufer und welche automatisiert durch das ERP-System (graue Hinterlegung) durchgeführt werden.

548

Fallstudien des Informationsmanagements

Rechnungskontrolleur

ERP-System

Finanzbuchhaltung (Tochterunternehmen) Rechnungsbeleg geht ein

Rechnungsbeleg registrieren u. digitalisieren

Rechnungsbeleg registriert und digitalisiert

Rechnung buchen u. Beleg hinterlegen

Rechnung gebucht, Beleg hinterlegt

Prüfen, ob Preisdifferenz vorhanden

Einkäufer

Zentraler Einkauf (Muttergesellschaft)

XOR

Daten für Formular ermitteln

Daten ermittelt

Zuständigen Einkäufer ermitteln

Daten in Formular eingeben u. speichern

Formular ausgefüllt und gespeichert

Formular an Einkäufer senden

Preisdifferenz vorhanden

Preisdifferenz nicht vorhanden, Zahlung

Sperrkennzeichen setzen

Sperrkennzeichen gesetzt, Statusmeldung

Einkäufer ermittelt

Formular trifft ein Bestell- und Rechnungsbeleg angezeigt

Bestell- und Rechnungsbeleg aufrufen Preisdifferenz prüfen XOR

Preisdifferenz nicht korrekt

Preisdifferenz prüfen

Formular archiviert

Formular archivieren, ggf. digitalisieren

Formular trifft ein

Preisdifferenz korrekt

Preisdifferenzdaten ermitteln

Preisdifferenzdaten ermittelt

XOR

Formular speichern

Formular mit Preisdifferenzdaten ergänzt

Formular ergänzen

Formular an Rechnungskontrolleur senden

Formular gespeichert

XOR Preisdifferenz von Einkauf nicht akzeptiert

Preisdifferenz von Einkauf akzeptiert

Gutschrift anfordern XOR

Gutschrift trifft nicht ein bzw. ist nicht korrekt Bearbeitung erneut an Einkäufer weiterleiten

Gutschrift trifft ein und ist korrekt

Gutschrift gebucht

Gutschrift buchen Sperrkennzeichen löschen

XOR Sperrkennzeichen gelöscht

Abb. FSGPM-2: Ursprünglicher Prozess Bearbeitung von Preisdifferenzen

Identifizierung von Schwachstellen Auf der Grundlage des in Abbildung FSGPM-2 dargestellten Prozessmodells wurden zusammen mit den Prozessverantwortlichen und –beteiligten mehrere Workshops durchgeführt. Dabei wurden folgende Schwachstellen der Bearbeitung von Preisdifferenzen identifiziert. 

Medienbrüche: Das wichtigste Hilfsmittel im ursprünglichen Prozess ist das Formular Preisdifferenz. Bei der Verwendung dieses Formulars treten Medienbrüche auf. Die Einkäufer senden ca. 50 % aller Formulare per Fax an die Rechnungskontrolleure. Dies

Fallstudie Geschäftsprozessmanagement (FSGPM)













549

erhöht den Arbeitsaufwand erheblich, da die Rechnungskontrolleure die Preisdifferenzdaten in dem ursprünglich an den Einkäufer übermittelten Formular ergänzen müssen. Unzureichende Automatisierung: Rechnungskontrolleure und Einkäufer müssen häufig Routinetätigkeiten von Hand durchführen. Dies betrifft vor allem das Beschaffen und Weiterleiten von Daten, die zur Bearbeitung der Preisdifferenzen benötigt werden. Selbst Daten, die bereits im ERP-System vorhanden sind, werden manuell in das Formular Preisdifferenz übertragen. Beispielsweise ermittelt der Rechnungskontrolleur für jede gesperrte Rechnungsposition den zuständigen Einkäufer in den Materialstammdaten des ERP-Systems, ergänzt das Formular mit weiteren Daten und leitet es dann per E-Mail an den Einkäufer weiter. Diese Tätigkeiten nehmen bei Rechnungen mit Preisdifferenzen in mehreren Rechnungspositionen viel Zeit in Anspruch, da für jede Rechnungsposition ein eigenes Formular erstellt wird. Eine weitere Schwachstelle des Prozesses ist die Initiierung der einzelnen Teilprozesse, die nur dann erfolgt, wenn ein Bearbeiter das Formular Preisdifferenz per E-Mail oder Fax weiterleitet. Dies wird aber häufig versäumt. Liege- und Wartezeiten: Die manuellen Routinetätigkeiten führen zu einer langen Bearbeitungszeit. Diese steht den Rechnungskontrolleuren und Einkäufern nicht für andere Aufgaben zur Verfügung. Da diese Aufgaben aber oft eine hohe Dringlichkeit haben, entstehen lange Liege- bzw. Wartezeiten bei der Bearbeitung von Preisdifferenzen. Beispielsweise liegt unmittelbar vor einem Zahlungslauf (automatisierte Zahlung von Rechnungsbeträgen an einem Stichtag) die Priorität der Rechnungskontrolleure auf dem Buchen möglichst vieler Rechnungen. Das Bearbeiten von Preisdifferenzen wird dabei oft auf einen der folgenden Arbeitstage verschoben. Auch bei den Einkäufern ergeben sich zum Teil lange Liegezeiten. Nach dem Eintreffen des Formulars Preisdifferenz vergehen oft mehrere Tage, bis mit der Bearbeitung begonnen wird. Einige Einkäufer warten, bis sich eine größere Anzahl von Preisdifferenzen angesammelt hat, um deren Bearbeitung zu bündeln. Redundanz: Sowohl im zentralen Einkauf als auch in der Finanzbuchhaltung der Tochterunternehmen werden die ausgefüllten Formulare auf abteilungsinternen Netzlaufwerken redundant gespeichert. Ein zentraler Zugriff auf die aktuellen Preisdifferenzdaten ist nicht möglich. Skontoverluste: Aufgrund der langen Bearbeitungszeiten von Preisdifferenzen werden Zahlungsfristen häufig nicht eingehalten. Dies führt zu Unzufriedenheit der Lieferanten und verursacht Skontoverluste. Eine Terminüberwachung ist wegen der großen Anzahl von Preisdifferenzen und wegen des nur teilweise automatisierten Prozesses kaum möglich. In vielen Fällen wird erst bei Eintreffen einer Mahnung die verspätete Bearbeitung einer Preisdifferenz bemerkt. Bearbeitungsfehler: Aufgrund der vielen manuellen Tätigkeiten ist der Prozess sehr fehleranfällig. Beim Ausfüllen des Formulars Preisdifferenz treten oft Eingabefehler auf. Wegen der hohen Anzahl von Preisdifferenzen und der vielen Formulare, die zwischen Rechnungskontrolleuren und Einkäufern ausgetauscht werden, verlieren die Bearbeiter leicht den Überblick. Häufig wird die Weiterleitung von Formularen vergessen. Intransparenz: Die bearbeiteten Formulare werden archiviert. Sie enthalten zwar das Ergebnis der Bearbeitung, aber nur wenige Informationen über den Bearbeitungsverlauf. Es wird z. B. nicht dokumentiert, wann ein Einkäufer über das Vorliegen einer Preisdifferenz informiert wurde oder wie viel Zeit Rechnungskontrolleur und Einkäufer für die

550

Fallstudien des Informationsmanagements

Bearbeitung benötigt haben. Die Prozesstransparenz ist mangelhaft. Auskünfte über den Bearbeitungsstand einer Preisdifferenz sind nur schwer zu erhalten, da nur der aktuelle Bearbeiter diesen kennt. In vielen Situationen (z. B. wenn eine Zahlungsfrist überschritten, eine Mahnung eingetroffen ist oder ein Lieferant um Auskunft bittet) kann nur eine unzureichende Auskunft über den Bearbeitungsstand gegeben werden. Dies führt zu weiterer Verärgerung der Lieferanten.

Prozessverbesserung Anforderungen an den überarbeiteten Prozess Die Prozesseigner formulierten folgende Anforderungen an den überarbeiteten Prozess:  

  

Medienbrüche sind zu vermeiden. Das Formular Preisdifferenz soll nicht per Fax übertragen werden. Möglichst viele Routinetätigkeiten sind zu automatisieren. Dies gilt vor allem für das Beschaffen und Weiterleiten der Daten, die zur Bearbeitung der Preisdifferenz benötigt werden. Die Teilprozesse sollen automatisiert und nicht durch manuelles Weiterleiten des Formulars Preisdifferenz initiiert werden. Die bisher redundant gehaltenen Preisdifferenzdaten sind zentral zu speichern. Alle Prozessbeteiligten sollen jederzeit auf diese Daten zugreifen können. Termine sollen automatisiert überwacht und Rechnungskontrolleure und Einkäufer rechtzeitig informiert werden, bevor Zahlungsfristen verstreichen. Die Bearbeitung einer Preisdifferenz soll transparent dokumentiert werden. Alle Prozessbeteiligten sollen jederzeit die Möglichkeit haben, sich über den aktuellen Bearbeitungsstand zu informieren. Die Dokumentation der Tätigkeiten, ihrer Bearbeiter und der Bearbeitungszeiten soll automatisiert und leicht nachvollziehbar erfolgen.

Prozessentwurf Zur Erfüllung der Anforderungen wurde der Prozess verändert. Im Mittelpunkt stand eine stärkere Automatisierung des Prozesses. Dies wurde durch den Einsatz des WorkflowManagementsystems des ERP-Systems erreicht. Zunächst wurden gemeinsam mit den Prozessverantwortlichen mögliche Änderungen der Bearbeitungsreihenfolge im Prozess diskutiert, verschiedene Prozessalternativen entwickelt und deren Vor- und Nachteile erörtert. Hierbei wurden zur Visualisierung, Modellierung und Simulation der Prozessalternativen Microsoft Visio und ARIS Toolset verwendet. Anschließend wurde die favorisierte Prozessvariante in enger Abstimmung mit Mitarbeitern der IT-Abteilung der Muttergesellschaft im Workflow-Managementsystem abgebildet. Nach mehreren Verfeinerungen entstand folgender überarbeiteter Prozess zur Bearbeitung von Preisdifferenzen: Der erste Teilprozess beginnt mit dem Eingang einer Rechnung in der Finanzbuchhaltung. Ein Rechnungskontrolleur registriert und digitalisiert die Rechnung, bevor er diese im ERPSystem bucht und den digitalisierten Beleg dort speichert. Das ERP-System prüft, ob eine Preisdifferenz vorliegt und setzt ein Sperrkennzeichen für jede Rechnungsposition mit einer Preisdifferenz. Mit dem Setzen des Sperrkennzeichens beginnt die Unterstützung durch das Workflow-Managementsystem. Das System initiiert für jede gesperrte Rechnungsposition

Fallstudie Geschäftsprozessmanagement (FSGPM)

551

einen Workflow. Alle Daten und Belege, die zur Bearbeitung dieser Preisdifferenz notwendig sind, werden automatisiert zusammengestellt und mit dem Workflow verknüpft. Danach ermittelt das Workflow-Managementsystem den zuständigen Einkäufer und sendet ihm eine Nachricht über die Preisdifferenz. Im zweiten Teilprozess ruft der Einkäufer die Nachricht auf und erhält eine übersichtliche Darstellung aller Objekte, die mit der Bearbeitung der Preisdifferenz in Verbindung stehen. Bestell- und Rechnungsbeleg werden automatisch geöffnet. Der Einkäufer kann die hinterlegten Daten sofort analysieren und nicht korrekte Bestelldaten korrigieren. Entscheidet der Einkäufer, den in der Rechnung gestellten Preis zu akzeptieren, löscht eine Transaktion des Workflow-Managementsystems das entsprechende Sperrkennzeichen, beendet die Bearbeitung des Workflows und schließt die Bearbeitung der Preisdifferenz ab. Die bisher notwendige Rückmeldung an den zuständigen Rechnungskontrolleur, dass der Rechnungspreis zu akzeptieren ist, entfällt. Sind alle Sperrkennzeichen einer Rechnung gelöscht, gibt das ERPSystem die Rechnung zur Zahlung frei. Akzeptiert der Einkäufer die Preisdifferenz nicht, muss er Preisdifferenzdaten erstellen. Dazu füllt er ein im ERP-System hinterlegtes Formular aus und fügt es dem Workflow bei. Das Formular mit den Preisdifferenzdaten wird zentral im ERP-System gespeichert. Nachdem der Einkäufer die Bearbeitung beendet hat, ermittelt das Workflow-Managementsystem den zuständigen Rechnungskontrolleur und sendet ihm eine Nachricht. Im dritten Teilprozess fordert der Rechnungskontrolleur Gutschriften bei den Lieferanten an. Dazu öffnet er die Nachricht des Workflow-Managementsystems, greift auf das dort hinterlegte Formular mit den Preisdifferenzdaten zu und versendet dieses per E-Mail an den Lieferanten. Akzeptiert der Lieferant die Gutschrift (dies geschieht per E-Mail) bucht der Rechnungskontrolleur diese im ERP-System und löscht das Sperrkennzeichen der entsprechenden Rechnungsposition. Damit ist die Bearbeitung der Preisdifferenz abgeschlossen. Bestätigt der Lieferant die Gutschrift nicht innerhalb einer bestimmten Frist, leitet der Rechnungskontrolleur den gesamten Vorgang zur erneuten Prüfung an den zuständigen Einkäufer weiter. Dazu sendet er mit Hilfe des Workflow-Managementsystems eine Nachricht an den Einkäufer und die Bearbeitung der Preisdifferenz erfolgt wie zuvor beschrieben. In Abbildung FSGPM-3 ist der überarbeitete Prozess als EPK dargestellt. Die Abbildung verdeutlicht, dass im Vergleich zum ursprünglichen Prozess viele Routinetätigkeiten durch das ERP-System (graue Hinterlegung) übernommen werden. Zentrales Instrument zur Steuerung des Prozesses ist das Workflow-Managementsystem. Medienbrüche, insbesondere in Folge von Faxversand, gibt es nicht mehr. Alle Daten sind zentral im ERP-System und nicht mehr redundant auf Arbeitsplatzrechnern und Netzlaufwerken gespeichert. Die Verwendung des Workflow-Managementsystems gewährleistet, dass sämtliche Bearbeitungsschritte protokolliert werden. Das Workflow-Protokoll kann von den Prozessbeteiligten jederzeit eingesehen werden, um abgeschlossene Bearbeitungsschritte oder den aktuellen Bearbeitungsstatus zu prüfen. Rechnungskontrolleure und Einkäufer erhalten über die Bestell- und Rechnungsbelege Zugriff auf die Workflow-Protokolle. Das Formular mit den Preisdifferenzdaten kann ebenfalls eingesehen werden. Ferner überwacht das Workflow-Managementsystem alle relevanten Termine. Sofern die Bearbeitung eines bestimmten Arbeitsschrittes nicht innerhalb einer festgelegten Frist erfolgt, wird der zuständige Bearbeiter informiert.

552

Fallstudien des Informationsmanagements

Abb. FSGPM-3: Überarbeiteter Prozess Bearbeitung von Preisdifferenzen

Prozessevaluierung Vor und nach der Implementierung des überarbeiteten Prozesses wurden Werte ausgewählter Kennzahlen erhoben, um zu prüfen, in welchem Ausmaß durch die Veränderung und Automatisierung des Prozesses Verbesserungen erreicht werden konnten. Grundlage für diese Messungen waren Prozessbeobachtungen und Befragungen von Prozessbeteiligten sowie Berichte und Statistiken, die regelmäßig in der Finanzbuchhaltung der Tochterunternehmen und im zentralen Einkauf der Muttergesellschaft erstellt werden.

Fallstudie Geschäftsprozessmanagement (FSGPM)

553

Bearbeitungs- und Liegezeiten Am Beispiel von 25 zufällig ausgewählten Rechnungen mit je einer Preisdifferenz wurden die durchschnittlichen Bearbeitungszeiten der manuellen Tätigkeiten des ursprünglichen Prozesses ermittelt. Anschließend prüften zwei Rechnungskontrolleure und zwei Einkäufer die Ergebnisse und ergänzten diese sofern nötig. Nach der Einführung des überarbeiteten Prozesses wurde die Untersuchung wiederholt. Die Ergebnisse sind in Abbildung FSGPM-4 dargestellt. Bearbeitungs- Bearbeitungszeiten [min] zeiten [min] ursprünglicher überarbeiteter Prozess Prozess R1 Rechnungsbeleg registrieren u. digitalisieren 4,5 4,5 R2 Rechnung buchen u. Beleg hinterlegen 2,0 2,0 R3 Daten für Formular ermitteln 4,1 automatisiert R4 Zuständigen Einkäufer ermitteln 1,0 automatisiert R5 Daten in Formular eingeben u. speichern 3,1 automatisiert R6 Formular an Einkäufer senden 2,5 automatisiert E1 Bestell- und Rechnungsbeleg aufrufen 1,2 0,5 E2 Preisdifferenz prüfen 5,8 5,8 E3 Preisdifferenzdaten ermitteln 2,3* 2,3* E4 Formular ergänzen 3,5 3,5* E5 Formular speichern 0,5 0,5* E6 Formular an Rechnungskontrolleur senden 2,5 automatisiert R7 Formular archivieren, ggf. digitalisieren 3,8 automatisiert R8 Preisdifferenz prüfen 1,0 automatisiert R9 Gutschrift anfordern 4,5* 3,5* R10 Gutschrift buchen 1,5* 1,5* R11 Sperrkennzeichen löschen 1,0 1,0* *zusätzliche Bearbeitungszeiten, wenn die Preisdifferenz vom Einkauf abgelehnt wird

Teilprozess 3

Teilprozess 2

Teilprozess 1

Tätigkeiten der Rechnungskontrolleure (R) und Einkäufer (E)

Abb. FSGPM-4: Vergleich der Bearbeitungszeiten aller manuellen Tätigkeiten

Durch die Automatisierung der Tätigkeiten R3, R4, R5, R6, E6, R7 und R8 wurden die Bearbeitungszeiten aller drei Teilprozesse gesenkt. Im ersten Teilprozess verkürzt sich die durchschnittliche Bearbeitungszeit für die Rechnungskontrolleure von 17,2 Minuten auf 6,5 Minuten. Bei einer durchschnittlichen Anzahl von 50 Preisdifferenzen pro Woche entsteht dadurch eine wöchentliche Reduzierung von ca. 9 Arbeitsstunden. Im zweiten Teilprozess kommt es – je nachdem, ob der Einkäufer die Preisdifferenz akzeptiert oder nicht – zu unterschiedlichen Verkürzungen. Im Fall einer Ablehnung reduziert sich die Bearbeitungszeit um 3,2 Minuten, im Fall einer Zustimmung sogar um 7,2 Minuten. Im dritten Teilprozess muss der Rechnungskontrolleur nur die vom Einkäufer nicht akzeptierten Preisdifferenzen bearbeiten, der Einkäufer schließt die Bearbeitung aller akzeptierten Preisdifferenzen selbstständig

554

Fallstudien des Informationsmanagements

ab. Erfahrungswerte der Finanzbuchhaltungen zeigen, dass ca. 40 % aller Preisdifferenzen vom Einkauf akzeptiert werden. In diesen Fällen sind im dritten Teilprozess keine Tätigkeiten mehr durch den Rechnungskontrolleur zu erbringen. Aber auch bei der Bearbeitung der nicht akzeptierten Preisdifferenzen kommt es zu einer Zeitverkürzung von 4,8 Minuten, da die beiden Tätigkeiten R7 und R8 im überarbeiteten Prozess voll automatisiert sind. Zusätzlich zu den Bearbeitungszeiten wurden bei den Untersuchungen auch Liegezeiten im ursprünglichen Prozess festgestellt. Vor allem die Rechnungskontrolleure gaben an, dass die Weiterleitung des Formulars Preisdifferenz nicht immer am Tag der Feststellung der Preisdifferenz erfolgte. Bei über 50 % aller Preisdifferenzen leiteten die Rechnungskontrolleure das Formular erst Tage später an den Einkäufer weiter. Durch die Einführung des überarbeiteten Prozesses werden diese Liegezeiten vollständig vermieden, da der zuständige Einkäufer durch das Workflow-Managementsystem unmittelbar nach der Feststellung einer Preisdifferenz informiert wird und deren Bearbeitung fortsetzen kann.

Skontoverluste

Skontoverluste in %

Die Finanzbuchhaltungen führen Statistiken über die wöchentlichen Skontoverluste. Dabei wird jedem Skontoverlust eine Ursache zugeordnet. In Abbildung FSGPM-5 sind die Skontoverluste pro Kalenderwoche, die aufgrund verspäteter Bearbeitung einer Preisdifferenz entstanden sind, bezogen auf die gesamten Skontoverluste dargestellt. Ausgewertet wurden acht Wochen vor und nach der Einführung des überarbeiteten Prozesses. Die senkrechte gestrichelte Linie in Abbildung FSGPM-5 markiert den Umstellungszeitpunkt vom ursprünglichen auf den überarbeiteten Prozess. 40 % 30 % 20 % 10 % 0% 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Kalenderwochen Anteil der Skontoverluste, die durch verspätete Bearbeitung einer Preisdifferenz entstehen, an den gesamten Skontoverlusten Abb. FSGPM-5: Entwicklung der Skontoverluste aufgrund verspäteter Bearbeitung von Preisdifferenzen

Vor Einführung des überarbeiteten Prozesses nach der 21. Kalenderwoche betrug der prozentuale Anteil der Skontoverluste, die durch eine verspätete Bearbeitung von Preisdifferenzen verursacht werden, im Durchschnitt 31,5 % der gesamten Skontoverluste. Nach der Einführung des überarbeiteten Prozesses reduzierte sich der Wert auf 10,5 %.

Fallstudie Geschäftsprozessmanagement (FSGPM)

555

Sperrkennzeichen

Anzahl der gesperrten Rechnungspositionen

Als weitere Prozesskennzahl wird am letzten Werktag jeder Kalenderwoche ermittelt, bei wie vielen Rechnungspositionen das Sperrkennzeichen Preisdifferenz gesetzt ist. In Abbildung FSGPM-6 ist die Entwicklung der Werte dieser Kennzahl acht Wochen vor und nach der Einführung des überarbeiteten Prozesses dargestellt. 400 350 300 250 200 150 100 50 0 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Kalenderwochen Abb. FSGPM-6: Entwicklung der Anzahl gesperrter Rechnungspositionen

Beim ursprünglichen Prozess waren im Durchschnitt 313 Rechnungspositionen pro Woche gesperrt. Nach der Einführung des überarbeiteten Prozesses sank die Anzahl auf durchschnittlich 145. Ein wesentlicher Grund dafür ist, dass die Sperrkennzeichen bei akzeptierten Rechnungspreisen sofort nach der Bearbeitung des Einkäufers gelöscht werden. Des Weiteren führen die Verkürzungen der Bearbeitungszeiten im überarbeiteten Prozess zu einem schnelleren Löschen der Sperrkennzeichen.

Beurteilung Das Ziel des Projektes wurde erreicht. Verbesserungsmöglichkeiten des Prozesses zur Bearbeitung eingehender Rechnungen wurden identifiziert. Darauf aufbauend wurde ein veränderter Prozess entwickelt, eingeführt und durch ein Workflowmanagement-System unterstützt. Der überarbeitete Prozess weist im Vergleich zum ursprünglichen Prozess folgende Verbesserungen auf:     

Medienbrüche werden vermieden; Nachrichten und Dokumente werden in einem ERPSystem gespeichert und ausgetauscht. Routinetätigkeiten werden automatisiert; Einkäufer und Rechnungskontrolleure werden entlastet. Preisdifferenzdaten werden zentral gespeichert und den Mitarbeitern zugänglich gemacht. Termine werden automatisch überwacht; Rechnungskontrolleure und Einkäufer werden rechtzeitig informiert, bevor Fristen verstreichen. Der aktuelle Bearbeitungsstand wird dokumentiert; alle Mitarbeiter können sich entsprechend informieren.

556

Fallstudien des Informationsmanagements

Alle Anforderungen an den überarbeiteten Prozess wurden erfüllt. Die Prozessverbesserung wurde quantitativ mit folgenden Kennzahlen beschrieben: Bearbeitungszeiten, Anteil der Skontoverluste, die durch verspätete Bearbeitung von Preisdifferenzen entstehen, sowie Anzahl der gesperrten Rechnungspositionen. Dabei konnten deutliche Verbesserungen nachgewiesen werden. Diese wurden durch Veränderung der Bearbeitungsreihenfolge sowie durch Automatisierung verschiedener Tätigkeiten mit einem Workflowmanagement-System erreicht. Die Evaluierung wurde mit Kennzahlen durchgeführt, die aus der Perspektive des Praxispartners wichtige Eigenschaften des Prozesses beschreiben. Eine umfassende Evaluierung hätte die Wirtschaftlichkeit des überarbeiteten Prozesses mit der des ursprünglichen Prozesses vergleichen können. Dabei hätten auch Kosten der Einführung, Anpassung und des Betriebs des Workflowmanagement-Systems berücksichtigt werden müssen. Mertens hat darauf hingewiesen, dass eine marktwirtschaftliche Entscheidung über Verbesserungen von Geschäftsprozessen die Rentabilität der Investitionen berücksichtigen sollte. Da die Entscheidung über die Einführung des Workflowmanagement-Systems bereits vor der Planung des Projektes gefallen war, hatte eine umfassende Untersuchung der Wirtschaftlichkeit für den Praxispartner keine hohe Priorität. Weitere mögliche Kriterien zur Evaluierung der Prozessverbesserung sind die Mitarbeiter- sowie die Lieferantenzufriedenheit. Auch die in dem Projekt eingesetzten Methoden lassen sich weiterentwickeln. Zum Beispiel wurde davon ausgegangen, dass die nachgewiesenen Verbesserungen ursächlich auf die Veränderungen des Prozesses zurückzuführen sind. Allerdings wurde keine Kausalanalyse durchgeführt. Der Rückgang der gesperrten Rechnungspositionen nach Einführung des überarbeiteten Prozesses könnte aber auch andere als die bisher beschriebenen Ursachen haben. Denkbar ist z. B., dass die Motivation der Bearbeiter, das neue WorkflowmanagementSystem kennen zu lernen, in den ersten Wochen nach dessen Einführung sehr hoch war und dadurch die Bearbeitung von Preisdifferenzen anderen Tätigkeiten vorgezogen wurde. Das würde auch den leichten Anstieg gesperrter Rechnungspositionen ab der 25. Kalenderwoche erklären. Gespräche mit den Prozessverantwortlichen deuten jedoch darauf hin, dass die Maßnahmen zur Prozessverbesserung durchaus einen signifikanten Beitrag zur Verbesserung der Werte der verwendeten Prozesskennzahlen leisten. Dennoch müsste eine Analyse, bei der Wert auf einen fundierten Nachweis von Ursache/Wirkung-Zusammenhängen gelegt wird, dieses methodische Defizit beheben. Aufgaben- und Methodenverweise Geschäftsprozessmanagement (Lerneinheit GPMAN); Methoden des Geschäftsprozessmanagements (Lerneinheit MEGPM); Kennzahlensysteme (Lerneinheit KENNZ). Quellen Mertens, P.: Process focus considered harmful? In: WIRTSCHAFTSINFORMATIK 4/1996, 446–447 Vertiefungsliteratur Karagiannis, D.: Workflow-Management-System. In: Kurbel, K. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik - Online-Lexikon. München 4. A. 2010, o. S. http://www.enzyklopaedie-der-wirtschaftsinformatik.de Mende, U. / Berthold, A.: SAP® Business Workflow – Konzept, Anwendung, Entwicklung. 2. A. München 2000

Literaturverzeichnis Achilles, W.-A. (Hrsg.): Kommentar zum UN-Kaufrecht (CISG). 2. A., München 2011 Agrawal, M. / Chari, K.: Software Effort, Quality and Cycle Time: A Study of CMM Level 5 Projects. In: IEEE Transactions on Software Engineering 3/2007, 145–156 Aier, S. / Riege, C. / Winter, R.: Unternehmensarchitektur – Literaturüberblick und Stand der Praxis. In: WIRTSCHAFTSINFORMATIK 4/2008, 292–304 Akao, J.: Quality Function Deployment: Integrating Customer Requirements into Product Design. Cambridge 2004 Akao, Y.: QFD - Quality Function Deployment - Wie die Japaner Kundenwünsche in Qualität umsetzen. Landsberg, Lech 1992 Alavi, M. / Leidner, D. E.: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues. In: MIS Quarterly 1/2001, 107-136 Alloway, R. M.: Strategic Planning for Data Processing. Seminarunterlage des M.I.T. Industrial Liasion Program, Cambridge/Mass. 1985 Allweyer, T.: Geschäftsprozessmanagement: Strategie, Entwurf, Implementierung, Controlling. 2. A., Herdecke et al. 2007 Amberg, M. / Mossanen, K.: Forschungsbericht „Vorteile und Herausforderungen IT-gestützter Compliance-Erfüllung“. http://www.wi3.uni-erlangen.de/fileadmin/Dateien/Forschung/WI3_FB_2007.pdf; Abruf 12.11.2008 Amberg, M. et al.: Compliance im IT-Outsourcing. Theoretische und empirische Ermittlung von Einfluss nehmenden Compliance-Faktoren. Erlangen-Nürnberg 2009 Amling, Th. / Bantleon, U.: Handbuch der Internen Revision – Grundlagen, Standards, Berufsstand. Berlin 2007 Baars, H. / Kemper, H.-G.: Management Support with Structured and Unstructured Data - An Integrated Business Intelligence Framework. In: Information Systems Management 2/2008, 132–148 Balzert, H.: Lehrbuch der Softwaretechnik: Softwaremanagement. 2. A., Heidelberg 2008 Barzilai-Nahon, K.: Gatekeepers and gatekeeping mechanisms in networks. Unpublished doctoral dissertation, TelAviv University 2004 Basili, V. R. / Caldiera, G. / Rombach, H. D.: Goal Question Metric Paradigm. In: Marciniak, J. J. (Ed.): Encyclopedia of Software Engineering. New York 1994, 528–532 Bass, L. / Clements, P. / Kazman, R.: Software Architecture in Practice. 2. A., Reading et al. 2003 Bassellier, G. / Benbasat, I.: Business Competence of Information Technology Professionals: Conceptual Development and Influence on IT-Business Partnerships. In: MIS Quarterly 4/2004, 673–694 Baumöl, U.: IT-Controlling – Stand und Herausforderungen. In: CONTROLLING 12/2008, 649–654 Baumöl, U.: Methodenkonstruktion für das Business/IT-Alignment. In: WIRTSCHAFTSINFORMATIK 5/2006, 314–322 Baun, C. / Kunze, M. / Nimis, J. / Tai, S.: Cloud Computing. Web-basierte dynamische IT-Services. 2. A., Heidelberg et al. 2010 Bayer, B.: Kann man Benutzerzufriedenheit messen? Erfahrungen bei der Anwendung der Erfolgsfaktorenanalyse. In: Information Management 3/1987, 6–11 Beck, K. / Andres, C.: Extreme Programming Explained: Embrace Change. 2. A., Reading 2004 Beck, K.: Embracing Change with Extreme Programming. In: Computer 10/1999, 70–79 Beck, K.: Extreme Programming Explained: Embrace Change. Reading 2000 Becker, E. / Buhse, W. / Günnewig, D. / Rump, N. (Eds.): Digital Rights Management – Technological, Economic, Legal and Political Aspects. Lecture Notes in Computer Science 2770. Berlin/Heidelberg 2003 Becker, E. et al. (Hrsg.): Digital Rights Management – Technological, Economic, Legal and Political Aspects. Lecture Notes in Computer Science 2770. Berlin/Heidelberg 2003 Becker, J. / Knackstedt, R. / Pöppelbuß, J.: Entwicklung von Reifegradmodellen für das IT-Management - Vorgehensmodell und praktische Anwendung. In: WIRTSCHAFTSINFORMATIK 3/2009, 249–260 Becker, J. / Kugeler, M. / Rosemann, M.: Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. 6. A., Berlin/Heidelberg 2008 Becker, J. / Rosemann, M. / Schütte, R.: Grundsätze ordnungsmäßiger Modellierung. In: WIRTSCHAFTSINFORMATIK 5/1995, 435–445 Becker, J. / Schütte, R.: Handelsinformationssysteme. Domänenorientierte Einführung in die Wirtschaftsinformatik. 2. A., Frankfurt a. M. 2004 Beier, D.: Informationsmanagement aus Sicht der Betriebswirtschaftslehre. Frankfurt a. M. et al. 2002

558

Literaturverzeichnis

Beiersdorf, H.: Informationsbedarf und Informationsbedarfsermittlung im Problemlösungsprozeß "Strategische Unternehmensplanung". München/Mering 1995 Beimborn, D. / Franke, J.: IT-Business Alignment und der Wertbeitrag der IT. In: IM – Information Management & Consulting 1/2007, 74–79 Beims, M.: IT-Service Management in der Praxis mit ITIL 3: Zielfindung, Methoden, Realisierung 2. A., München 2009 Berger, T. G.: Service-Level-Agreements: Konzeption und Management von Service-Level-Agreements für ITDienstleistungen. Saarbrücken 2007 Bernhard, M. G. / Blomer, R. / Bonn, J. (Hrsg.): Strategisches IT-Management Bd. 2. Düsseldorf 2003 Bernhard, M. G. et al. (Hrsg.): Praxishandbuch Service-Level-Management: Die IT als Dienstleistung organisieren. 2. A., Düsseldorf 2006 Bernstein, P. A.: Middleware: a model for distributed system services. In: Communications of the ACM 2/1996, 86– 98 Berthel, J. / Becker, F. G.: Personal-Management. 8. A., Stuttgart 2007 Berthel, J.: Informationsbedarf. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Stuttgart 1992, 872– 886 Bhagwatwar, A. / Hackney, R. / Desouza, K. C.: Considerations for Information Systems 'Backsourcing': A Framework for Knowledge Re-integration. In: Information Systems Management 2/2011, 165–173 Biethahn, J. / Mucksch, H. / Ruf, W.: Ganzheitliches Informationsmanagement. München 1990 Birk, D. / Müller, M.: KnowledgeSharing@MED - turning knowledge into business. In: Davenport, T. H. / Probst, G. J. B. (Hrsg.): Knowledge Management Case Book. 2. A., Berlin/München 2002, 177–186 Bishop, M.: Computer Security. Art and Science. Boston 2003 BITKOM e. V.: Cloud Computing – Evolution in der Technik, Revolution im Business. Berlin 2009 Blohm, H. / Lüder, K. / Schaefer, C.: Investition – Schwachstellenanalyse des Investitionsbereichs und Investitionsrechnung. 9. A., München 2006 Blomer, R. / Bernhard, M. (Hrsg.): Balanced Scorecard in der IT. Düsseldorf 2003 Bock, A.: Dokumenten-Management-System (DMS). In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. A., Berlin/Heidelberg/New York 2001, 157–158 Bodendorf, F. / Bobra-Bissantz, S. / Bauer, C.: There´s more to IT – vom Innovationspotenzial zur Innovationsfähigkeit. In: HMD – Praxis der Wirtschaftsinformatik 239/2004, 7–17 Boehm, B. W.: A Spiral Model of Software Development and Enhancement. In: IEEE Computer 5/1988, 61–72 Boehm, B. W.: Guidelines for Verifying and Validating Software Requirements and Design Specifications. In: Samet, P. A. (Hrsg.): EURO IFIP: Proceedings of the European Conference on Applied Information Technology. Amsterdam et al. 1979, 711–719 Boehm, B. W.: Software Engineering Economics. Englewood Cliffs 1981 Boehme, R.: Wann sind IT-Security-Audits nützlich? In: Bernstein, A. / Schwabe, G. (Hrsg.): Proceedings of the 10th International Conference on Wirtschaftsinformatik WI 2.011. Volume 1. Zürich 2011, 385–394 Böhmann, T. / Krcmar, H.: Grundlagen und Entwicklungstrends im IT-Servicemanagement. In: HMD – Praxis der Wirtschaftsinformatik 237/2004, 7–21 Borland GmbH Langen: Kennzahlen helfen bei der besseren Ressourcennutzung. http://www.borland.com/de; Abruf 14.11.2008 Born, S. et al.: Leitfaden zum Thema "Information Lifecycle Management". 2004. http://www.bitkom.org; Abruf 16. Juni 2011 Böttcher, R.: IT-Servicemanagement mit ITIL V3: Einführung, Zusammenfassung und Übersicht der elementaren Empfehlungen. Hannover 2007 Brandl, R. / Bichler, M. / Ströbel, M.: Cost Accounting for Shared IT Infrastructures. In: WIRTSCHAFTSINFORMATIK 2/2007, 83–94 Brauers, J. / Weber, M.: Szenarioanalyse als Hilfsmittel der strategischen Planung. Methodenvergleich und Darstellung einer neuen Methode. In: Zeitschrift für Betriebswirtschaft 7/1986, 631–652 Braun, H. / Silbernagel, D.: Penetrationstests als Instrument der IT-Revision. In: Datenschutz und Datensicherheit 11/2009, 693–694 Brenn, C.: Zugangskontrollgesetz. Wien 2001 Brun, R.: Planen – Messen – Steuern: Die Kernprozesse von IT-Governance und ITR-Controlling. In: IM Information Management & Consulting 2/2008, 60–68 Brynjolfson, E.: The Productivity Paradox of Information Technology. In: Communications of the ACM 12/1993, 67–77 Brynjolfsson, E.: Beyond the productivity paradox. In: Communications of the ACM 8/1998, 49–55 Brynjolfsson, E.: The productivity paradox of information technology. In: Communications of the ACM 12/1993, 66–77

Literaturverzeichnis

559

Bughin, J. / Chui, M.: The Rise of the Networked Enterprise: Web 2.0 finds its Payday. In: McKinsey Quarterly 12/2010, https://www.mckinseyquarterly.com; Abruf 31. Mai 2011 Bühner, R.: Personalmanagement. 3. A., München/Wien 2005 Bullinger, H. J.: Einführung in das Technologiemanagement. Modelle, Methoden, Praxisbeispiele. Stuttgart 1994 Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz-Kataloge 2009. http://www.bsi.de; Abruf 27. Juni 2011 Bundesamt für Sicherheit in der Informationstechnik (BSI): GSTOOL – Handbuch. Version 4.5. Bonn 2008. https://www.bsi.bund.de; Abruf 11. Mai 2011 Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz-Kataloge 2008. http://www.bsi.de; Abruf 12. Mai 2011 Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Sicherheitshandbuch: Handbuch für die sichere Anwendung der Informationstechnik. 4. Entwurf v. 26. Juli 1991, Bonn 1991 Bundesamt für Sicherheit in der Informationstechnik (BSI): Zertifizierung nach ISO 27001 auf der Basis von ITGrundschutz. Prüfschema für ISO 27001-Audits. Version 2.1. Stand: 03.03.2008. Bonn 2008 Busch, U.: Org.-DV-Leiter vs. Kommunikationsmanager – Die neue Führungsposition im Unternehmen. In: Krallmann, H. (Hrsg.): Informationsmanagement auf der Basis integrierter Bürosysteme. Berlin 1986, 41–58 Business Continuity Institute (BCI): Good Practice Guidelines (GPG). Version 2010. http://www.thebci.org/gpg.htm; Abruf 12. Mai 2011 Byrd, T. / Turner, D.: An exploratory eximination of the relationship between flexible IT infrastructure and competitive advantage. In: Information & Management, 1/2001, 41–49 Cannon, D. / Taylor, S. / Wheeldon, D.: ITIL Service Operation. London 2007 Capgemini (Hrsg.): Der CIO – Verwalter oder Gestalter? http://www.ecin.de/strategie/rolle-cio; Abruf 19.12.2005 Carr, N. G.: IT Doesn't Matter. In: Harvard Business Review 5/ 2003, 41–49 Carr, N. G.: The Big Switch – Rewiring the World, from Edison to Google. Hüthig, Heidelberg 2009 Cerullo, V. / Cerullo, M. J.: Business Continuity Planning: A Comprehensive Approach. In: Information Systems Management 3/2004, 70–78 Chamoni, P. / Gluchowski, P.: Analytische Informationssysteme: Business Intelligence-Technologien und -Anwendungen 3. A., Berlin/Heidelberg/New York 2006 Chamoni, P. / Gluchowski, P.: Integrationstrends bei Business-Intelligence-Systemen. Empirische Untersuchung auf Basis des Business Intelligence Maturity Model. In: WIRTSCHAFTSINFORMATIK 2/2004, 119–128 Chamoni, P.: Berufsbilder, Tätigkeitsfelder und Arbeitsmarkt für Wirtschaftsinformatiker. In: Mertens, P. et al. (Hrsg.): Studienführer Wirtschaftsinformatik. 3. A., Braunschweig/Wiesbaden 2002, 19–24 Chaudhuri, S. / Dayal, U.: An Overview of Data Warehousing and OLAP Technology. In: ACM SIGMOD Record 1/1997, 65–74 Chen, P. P.-S.: Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned. Lecturing Notes in Computer Sciences. In: Broy, M. / Denert, E. (Hrsg.): Software Pioneers: Contributions to Software Engineering. Berlin 2002, 100–114 Chen, P. P.-S.: The Entity-Relationship Model - Toward a Unified View of Data. In: ACM Transactions on Database Systems 1/1976, 9–36 Chen, Y.: Information Valuation for Information Lifecycle Management. In: Parashar, M. (Hrsg.): Proceedings of the 2nd International Conference on Autonomic Computing. Seattle, Washington 2005, 135–146 Cockburn, A.: Crystal Clear: A Human-Powered Methodology for Small Teams. Amsterdam 2004 Codd, E. F. / Codd, S. B. / Salley, C. T.: Providing OLAP to User-Analysts: An IT Mandate. Ann Arbor 1993 Computer und Recht – Zeitschrift für die Praxis des Rechts der Informationstechnologien. http://www.computerundrecht.de Conrad, S. et al.: Enterprise Application Integration. Grundlagen - Konzepte - Entwurfsmuster - Praxisbeispiele. Heidelberg 2006 Crandell, M.: How to Ensure Business Continuity in the Cloud. 2011, http://gigaom.com; Abruf 28. Juni 2011 Crosby, P. B.: Quality is Free. The Art of Making Quality Certain. New York 1979 CUNO: http://www.consono.de/index.php/de/sapso/clmsams; Abruf 3.4.2011 Damien, J. et al.: Turnover of Information Technology Professionals: A narrative Review, meta-analytic structural Equation Modeling, and Model Development. In: MIS Quarterly 3/2007, 547–577 Daumenlang, K. / Altstötter, C. / Sourisseaux, A..: Evaluation. In: Roth, E. / Holling, H. (Hrsg.): Sozialwissenschaftliche Methoden. 5. A., München/Wien 1995, 702–713 Davenport, T. H. / Short, J. E.: The New Industrial Engineering: Information Technology and Business Process Redesign. In: Sloan Management Review 4/1990, 11–27 Davenport, T. H.: Process Innovation. Reengineering Work through Information Technology. Boston 1993 DeLone, W. H. / McLean, E. R.: The DeLone and McLean Model of Information System Success: A Ten-Year Update. In: Journal of Management Information Systems 4/2003, 9–30

560

Literaturverzeichnis

Deming, W. E.: Out of the Crisis: Quality, Productivity and Competitive Position. Cambridge 1992 Department of Trade and Industry. Information Technology Security Evaluation Criteria (ITSEC). Version 1.2. London 1991 Dern, G.: Management von IT-Architekturen. Leitlinien für die Ausrichtung, Planung und Gestaltung von Informationssystemen. 2. A., Wiesbaden 2006 Dernbach, W.: Grundsätze einer flexiblen Infrastruktur. In: Strunz, H. (Hrsg.): Planung in der Datenverarbeitung – Von der DV-Planung zum Informations-Management. Berlin et al. 1985, 82–97 Detecon Executive Briefing: IT-Organisation 2015 – Fit für die Zukunft? http://www.detecon.com/de/studies/itorganisation-2015-fit-fur-die-zukunft_2011_04_28_342; Abruf 22.5.2011 Devlin, B.: Data warehouse: From Architecture to Implementation. 6. A., Reading 2000 Dibbern, J. / Heinzl, A. / Leibbrand, S.: Interpretation des Sourcings der Informationsverarbeitung. Hintergründe und Grenzen ökonomischer Einflussgrößen. In: WIRTSCHAFTSINFORMATIK 5/2003, 533–540 Diebold Deutschland GmbH (Hrsg.): Diebold Kennzahlensystem (DKS). Ein Instrument zur Analyse der Wirkungen des Einsatzes informationstechnischer Mittel und Verfahren. Frankfurt a. M. 1984 Dietrich, L.: Die ersten 100 Tage des CIO – Quick Wins und Weichenstellungen. In: Dietrich, L. / Schirra, W. (Hrsg.): IT im Unternehmen. Berlin et al. 2004, 45–81 Dinter, B. et al.: Governance in der Informationslogistik am Beispiel eines Energieversorgers. In: Dinter, B. et al. (Hrsg.): DW2008. Synergien durch Integration und Informationslogistik. Lecture Notes in Informatics (LNI) Proceedings. Bonn 2008, 249–266 Dippold, R. et al.: Unternehmensweites Datenmanagement. Von der Datenbankadministration bis zum Informationsmanagement. 4. A., Braunschweig/Wiesbaden 2005 Disterer, G.: Zertifizierung der IT nach ISO 20000. In: WIRTSCHAFTSINFORMATIK 6/2009, 530–534 Doberitz, D.: IT-Kostenrechnung im Unternehmen – Verursachungsgerechte Leistungsverrechnung für innerbetriebliche IT-Dienstleistungen. Saarbrücken 2008 Dönitz, E. J.: Effizientere Szenariotechnik durch teilautomatische Generierung von Konsistenzmatrizen. Wiesbaden 2009 Dorgan, St. J. / Dowdy, J. J.: How good management raises productivity. In: The McKinsey Quarterly 4/2002, 14– 16 Dorgan, St. J. / Dowdy, J. J.: When IT lifts productivity. In: The McKinsey Quarterly 4/2004, o. S. Dosi, G.: Technological Paradigms and Technological Trajectories. In: Research Policy 3/1982, 147–162 Droege & Comp. Düsseldorf http://www.droege.de; Abruf 25.1.2008 Drumm, H. J.: Personalwirtschaft. 5. A., Berlin/Heidelberg 2005 Drury, D. H.: An Evaluation of Data Processing Steering Committees. In: MIS Quarterly 12/1984, 257–265 Dumslaff, U. / Lempp, P.: Studie IT-Trends 2011. Zukunft sichern in der Krise. Berlin 2011. http://www.de.capgemini.com; Abruf 15. Juni 2011 Duscha, A. / Hotz, A.: Netz- und Informationssicherheit im Unternehmen 2010. Ergebnisse einer Online-Befragung von 303 kleinen und mittelständischen Unternehmen in Deutschland. Köln 2010 Earl, M. (Ed.): Information Management – The Strategic Dimension. Oxford 1989 Earl, M. J.: Change isn’t optional for today’s CIO. In: FINANCIAL TIMES, Supplement „Mastering Information Management“, 15.2.1999, 2–3 Earl, M. J.: Management Strategies for Information Technology. Hempstead 1989 Earl, M.: The role of the chief knowledge officer. In: FINANCIAL TIMES, Supplement „Mastering Information Management“, 8.3.1999, 7–8 Ebel, N.: ITIL V3 Basis-Zertifizierung: Grundlagenwissen und Zertifizierungsvorbereitung für die ITIL FoundationPrüfung. München 2008 Eckert, C.: IT-Sicherheit. Konzepte - Verfahren - Protokolle. 5. A., München/Wien 2008 Edmundson, H.: Technical Communities of Practice at Schlumberger. In: Knowledge Management Review. 2/2001, 20–23 Eicker, S. / Heimann, E. / Bucksteeg, M.: Kostenabhängigkeitsbetrachtung für Service Levels von Managed Desktop Services am Beispiel der Verfügbarkeit. In: Bichler, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 951–962 Eisenführ, F. / Weber, M.: Zielstrukturierung: ein kritischer Schritt im Entscheidungsprozeß. In: Zeitschrift für betriebswirtschaftliche Forschung 11/1986, 907–929 El Emam, K. / Koru, A. G.: A Replicated Survey of IT Software Project Failures. In: IEEE Software. 5/2008, 84–90 Ellringman, H.: Vom Qualitätsmanagement zum strategischen Geschäftsprozessmanagement. In: Pfeifer, T. / Schmitt, R. (Hrsg.): Masing. Handbuch Qualitätsmanagement. 5. A., München 2007, 69–92 Elmasri, R. / Navathe, S. B.: Grundlagen von Datenbanksystemen. 3. A., München 2002 Enns, H. G. / Huff, S. L. / Higgins, C. A.: CIO Lateral Influence Behaviors: Gaining Peers´ Commitment to strategic Information Systems. In: MIS Quarterly 1/2003, 155–176

Literaturverzeichnis

561

Enns, H. G. / MacFarlin, D. B. / Huff, S. L.: How CIOs can effectively use Influence Behaviors. In: MIS Quarterly 1/2007, 29–38 Eppler, M. J.: Making Knowledge Visible through Knowledge Maps: Concepts, Elements, Cases. In: Holsapple, C. W. (Hrsg.): Handbook on Knowledge Management 1. Knowledge Matters. Berlin/Heidelberg/New York 2003, 189–205 Eppler, M. J.: Managing Information Quality. Increasing the Value of Information in Knowledge-intensive Products and Processes. Berlin, Heidelberg 2003 Erek, K. / Schmidt, N.-H. / Zarnekow, R. / Kolbe, L. M.: Nachhaltiges Informationsmanagement – Strategische Optionen und Vorgehensmodell zur Umsetzung. http://subs.emis.de/LNI/Proceedings/Proceedings154/gi-proc154-312.pdf2; Abruf 2.5.2011 Erl, T.: Service-Oriented Architecture. A Field Guide to Integrating XML and Web Services. 2. A., Englewood Cliffs 2004 Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River et al. 2005 Erl, T.: SOA: Principles of Service Design. Upper Saddle River 2008 Ernst & Young (Hrsg.): Borderless security. Ernst & Young’s 2010 Global Information Security Survey. o. O. 2010. http://www.ey.com; Abruf 07. April 2011 Ernst & Young (Hrsg.): IT-Kosten und IT-Performance 2002 – Betriebswirtschaftliche Studie der Schweizer Informatikabteilungen. Bern 2002 Ernst & Young (Hrsg.): Outpacing change. Ernst & Young’s 12th annual global information security survey. o. O. 2009, http://www.ey.com; Abruf 18. Mai 2010 Eymann, T.: Cloud Computing. In: Kurbel, K. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik - OnlineLexikon. München 4. A. 2010, o. S. http://www.enzyklopaedie-der-wirtschaftsinformatik.de F.A.Z. Institut und Intel Corp.: Energieeffizienz im Rechenzentrum – Chancen, Potenziale, Lösungen. Frankfurt/M. 2007 Fagan, M. E.: Advances in Software Inspections. In: IEEE Transactions on Software Engineering 7/1986, 744–751 Fagan, M. E.: Design and Code Inspections to Reduce Errors in Program Development. In: IBM Systems Journal 3/1976, 182–211 Faisst, U. / Prokein, O. / Wegemann, N.: Ein Modell zur dynamischen Investitionsrechnung von IT-Sicherheitsmaßnahmen. In: Zeitschrift für Betriebswirtschaft 5/2007, 511–538 Feldman, S. et al.: The Hidden Costs of Information Work. IDC Whitepaper. Framingham 2005. http://www.scribd.com; Abruf 28. Juni 2011 Feldman, S.: The high cost of not finding information. 2004. http://www.kmworld.com; Abruf 10. Juni 2011 Feraud, G.: What makes IT professionals tick? FINANCIAL TIMES, Supplement „Mastering Information Management“, 15.2.1999, 10 Fink, A. / Schlake, O. / Siebe, A.: Erfolg durch Szenario-Management – Prinzip und Werkzeuge der strategischen Vorausschau. Frankfurt/M. 2001 Finkelstein, C.: Information Engineering. Strategic Systems Development. Reading/MA 1992 Finkelstein, C.: The Emergence and Potential of Enterprise Information Portals (EIPs). o. O. 1999. http://www.tdan.com; Abruf 17. September 2007 Fischer, D.: WLAN-Sicherheit in deutschen Unternehmen und Behörden. In: KES - Die Zeitschrift für Informations-Sicherheit 1/2010, 66–72 Fisher, K. E. / Erdelez, S. / McKechnie, L. E. F. (Hrsg.): Theories of information behavior. Medford/New Jersey, 2005 Foegen, M. / Battenfeld, J.: Die Rolle der Architektur in der Anwendungsentwicklung. In: Informatik Spektrum 5/2001, 290–301 Forrester Research, Inc.: Global IT Budget Composition: 2006; zitiert nach Brandl et al., 83 und 92 Frank, U. / Hofmann, G. R.: IT-Controlling und IT-Produktivität. Editorial zu WIRTSCHAFTSINFORMATIK 3/2009, 233–234 Freedman, D. P. / Weinberg, G. M.: Handbook of Walkthroughs, Inspections, and Technical Reviews. Evaluating Programs, Projects, and Products. 3. A., New York 1991 Fröschle, H.-P. (Hrsg.): Wettbewerbsfaktor IT. Heidelberg 2009 Fröschle, H.-P. (Hrsg.): Wettbewerbsvorteile durch IT. Heidelberg 2004 Funke, H.: Kosten- und Leistungsrechnung in der EDV. Stand und Entwurf einer prozessorientierten DVKostenverrechnung. Kassel University Press, Kassel 1999 Fürer, P. J.: Prozesse und EDV-Kostenverrechnung – Die prozessbasierte Verrechnungskonzeption für Bankrechenzentren. Bern et al. 1994 Furth, B. / Escalante, A. (Eds.): Handbook of Cloud Computing. New York et al. 2010 Gadatsch, A. / Mayer, E.: Masterkurs IT-Controlling. Wiesbaden 2005

562

Literaturverzeichnis

Gadatsch, A.: Grundkurs Geschäftsprozess-Management. Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker. 4. A., Wiesbaden 2005 Gaitanides, M.: Prozessorganisation. Entwicklung, Ansätze und Programme des Managements von Geschäftsprozessen. München 2007 Ganzer, K.: Schlüsselfaktor Informationsmanagement. In: F.A.Z., Beilage Technik, Computer, Kommunikation vom 27.10.1986, B19 Garvin, D.A.: What Does „Product Quality“ Really Mean? In: Sloan Management Review 1/1984, 25–45 Gaus, W.: Berufe im Informationswesen. 5. A., Berlin et al. 2002 Gausemeier, J ./ Fink, A. / Schlake, O.: Szenario-Management: Planen und Führen nach Szenarien. 2. A., München/ Wien 1996 Gemünden, H. G.: Informationsverhalten. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Stuttgart 1992, 1010–1029 Gentsch, P.: Wissen managen mit innovativer Informationstechnologie. Strategien - Werkzeuge - Praxisbeispiele. Wiesbaden 1999 Gerlinger, A. et al.: Prozessorientierte IV-Leistungsverrechnung – Der Weg zur totalen Transparenz? In: Krcmar, H. / Buresch, A. / Reb, M. (Hrsg.): IV-Controlling auf dem Prüfstand. Wiesbaden 2000, 105–134 Geschka, H. / Hammer, R.: Die Szenario-Technik in der strategischen Unternehmensplanung: In: Hahn, D. / Taylor, B. (Hrsg.): Strategische Unternehmensplanung. Heidelberg 1992, 311–336. Gienke, H.: Produktionscontrolling. In: Gienke, H. /Kämpf, R. (Hrsg.): Handbuch Produktion. Innovatives Produktionsmanagement: Organisation, Konzepte, Controlling. München 2007, 745–848 Gladen, W.: Performance Measurement – Controlling mit Kennzahlen. 3. A., Wiesbaden 2005 Glohr, C.: Der CIO als Kostenmanager. In: Informatik Spektrum 2/2003, 134–139 Glohr, C.: IT-Kennzahlen für den CIO. In: CONTROLLING 3/2006, 149–156 Goeken, M. / Patas, J.: Wertbeitrag der IT als Gegenstand der IT-Governance und des IT-Controllings. In: CONTROLLING12/2009, 650–655 Gold, A. H. / Malhotra, A. / Segars, A. H.: Knowledge Management: An Organizational Capabilities Perspective. In: Journal of Management Information Systems. 1/2001, 185–214 Gollmann, D.: Computer Security. 2. A., Chichester 2006 Götze, U.: Szenario-Technik in der strategischen Unternehmensplanung. 2. A., Wiesbaden 1993 Gräwe, S. L.: Die Entstehung der Rechtsinformatik – Wissenschaftshistorische und -theoretische Analyse einer Querschnittsdisziplin. Hamburg 2011 Gresse, C. / Hoisl, B. / Rombach, D. / Ruhe, G.: Kontinuierliche Qualitätsverbesserung in der SoftwareEntwicklung. In: WIRTSCHAFTSINFORMATIK 2/1996, 160–171 Gresse, C. / Rombach, D. / Ruhe, G.: Kosten/Nutzen-Analyse von GQM-basiertem Messen und Bewerten. In: Grün, O. / Heinrich, L. J. (Hrsg.): Wirtschaftsinformatik – Ergebnisse empirischer Forschung. Wien/New York 1997, 119–135 Grimm, R.: Digitale Kommunikation. München/Wien 2005 Groll, T.: 1x1 des Lizenzmanagements. Praxisleitfaden für Lizenzmanager. 2. A., München 2010 Groomer, S. M. / Murthy, U. S.: Continuous Auditing of Database Application – An Embedded Audit Module Approach. In: Journal of Information Systems 4/1989, 53–69 Groß, St. / Vogl, A.: Continuous Auditing – Ein Ansatz zur zeitnahen und kontinuierlichen Prüfung. http://www.elektronische-steuerpruefung.de/loesung/gross_vogl_1.htm; Abruf 29.3.2011 Grover, V. et al.: The Implementation of Business Process Reengineering. In: Journal of Management Information Systems 1/1995, 109–144 Grütter, R. / Schwabe, G. / Aschoff, F.-R.: Qualität von IT-Leistungen aus den Perspektiven von Anbietern und Nachfragern. Ergebnisse einer Umfrage in der Schweiz. In: Oberweis, A. et al. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering. 8. Internationale Tagung Wirtschaftsinformatik Karlsruhe, Bd. 1. Karlsruhe 2007, 365–382 Güldenberg, S.: Wissensmanagement und Wissenscontrolling in lernenden Organisationen - Ein systemtheoretischer Ansatz. 4. A., Braunschweig/Wiesbaden 2003 Guntamukkala, V. / Wen, H. J. / Tarn, J. M.: An Empirical Study of Selecting Software Development Life Cycle Models. In: Human Systems Management 4/2006, 265–278 Haag, S. / Raja, M. K. / Schkade, L. L.: Quality Function Deployment. Usage in Software Development. In: Communications of the ACM 1/1996, 41–73 Hafner, M. / Winter, R.: Vorgehensmodell für das Management der unternehmensweiten Applikationsarchitektur. In: Ferstl, O. K. et al. (Hrsg.): Wirtschaftsinformatik 2005. eEconomy, eGovernment, eSociety. Heidelberg 2005, 627–646

Literaturverzeichnis

563

Hagedorn, T. et al.: Wissens- und Informationsmanagement in der Praxis - Einführung einer Wissensdatenbank beim Aufbau eines Shared-Service-Centers bei E.ON Energie. In: Keuper, F. / Neumann, F. (Hrsg.): Wissensund Informationsmanagement. Strategien, Organisation und Prozesse. Wiesbaden 2009, 241–264 Hammer, M. / Champy, J.: Business Reengineering. Die Radikalkur für das Unternehmen. 7. A., Frankfurt a. M. 2003 Hanschke, I.: Strategisches Management der IT-Landschaft. Ein praktischer Leitfaden für das Enterprise Architecture Management. 2. A., München 2010. Hansen, M. T. / Nohria, N. / Tierney, T.: What’s Your Strategy For Managing Knowledge? In: Harvard Business Review. 2/1999, 106–116 Harter, D. E. / Krishnan, M. S. / Slaughter, S. A.: Effects of Process Maturity on Quality, Cycle Time, and Effort in Software Product Development. In: Management Science 4/2000, 451–466 Hartmann, P.: Content Management (CM). In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. A., Berlin/Heidelberg/New York 2001, 121–122 Hauschildt, J. / Salomo, S.: Innovationsmanagement. 4. A., München 2007 Hawking, D.: Challenges in enterprise search. In: Schewe, K.-D. / Williams, H. (Hrsg.): Proceedings of the Fifteenth Australasian Database Conference. Dunedin, New Zealand 2004, 15–24 Hayes, B.: Cloud Computing. In: Communications of the ACM 7/2008, 9–11 Heinrich, L. J.: Datenverarbeitung außer Haus mit Hilfe der Computertechnik - Zeiterscheinung oder Notwendigkeit. In: Der Betrieb 51-52/1965, 1865–1868 Heinrich, L. J.: Informationsmanagement – Planung, Überwachung und Steuerung der Informationsinfrastruktur. 7. A., München/Wien 2002, Lerneinheit CHECK – Checklisten, 527–542 Heinrich, L. J.: Strategische Überdehnung der Informationsinfrastruktur. In: Bartmann, D. (Hrsg.): Lösungsansätze der Wirtschaftsinformatik im Lichte der praktischen Bewältigung. Berlin et al. 1991, 123–135 Heinrich, L. J. / Ambichl, E.: Ergebnisse einer Leistungsbewertung von Client-Server-Architekturen. In: Krcmar, H. (Hrsg.): Client-Server-Architekturen. Halbergmoos 1993, 55–101 Heinrich, L. J. / Damschik, I.: Kennzahlen für das strategische Controlling der Informationsverarbeitung. In: Rauch, W. / Strohmeier, F. / Hiller, H. / Schlögel, Ch. (Hrsg.): Mehrwert von Information – Professionalisierung der Informationsarbeit. Konstanz 1994, 461–470 Heinrich, L. J. / Häntschel, I. / Pomberger, G.: Diagnose der Informationsverarbeitung. Konzept und Fallstudie. In: CONTROLLING 3/1997, 196–203 Heinrich, L. J. / Häntschel, I. / Pomberger, G.: Information Systems Diagnosis. In: Zupancic, J. (Ed.): Evolution and Challenges in System Development. New York et al. 1999, 187–197 Heinrich, L. J. / Häntschel, I.: Messen der Benutzerzufriedenheit – Instrument und Anwendungserfahrungen. In: Schweiggert, F. / Stickel, E. (Hrsg.): Informationstechnik und Organisation. Stuttgart 1995, 39–54 Heinrich, L. J. / Häntschel, I.: Messen des Erfolgs des Benutzer-Service. In: HMD – Theorie und Praxis der Wirtschaftsinformatik 189/1996, 75–97 Heinrich, L. J. / Heinzl A. / Riedl, R.: Wirtschaftsinformatik: Einführung und Grundlegung. 4. A., Berlin/Heidelberg 2011 Heinrich, L. J. / Pomberger, G. / Thonabauer, C.: Entwickeln von EB/EC-Strategien. In: HMD – Praxis der Wirtschaftsinformatik 221/2001, 87–93 Heinrich, L. J. / Pomberger, G.: Diagnose der Informationsverarbeitung. In: Schweiggert, F. / Stickel, E. (Hrsg.): Informationstechnik und Organisation. Planung, Wirtschaftlichkeit und Qualität. Stuttgart 1995, 23–38 Heinrich, L. J. / Pomberger, G.: Entwickeln von Informatik-Strategien. In: Lausen, G. / Oberweis, A. / Schlageter, G. (Hrsg.): Angewandte Informatik und Formale Beschreibungsverfahren. Stuttgart/Leipzig 1999, 108–127 Heinrich, L. J. / Pomberger, G.: Erfolgsfaktorenanalyse – Instrument für das strategische IT-Controlling. In: HMD – Praxis der Wirtschaftsinformatik 217/2001, 19–28 Heinrich, L. J. / Riedl, R.: Phasenmodell zur Entwicklung von Serviceebenen-Vereinbarungen. In: HMD – Praxis der Wirtschaftsinformatik 231/2003, 88–96 Heinzl, A.: Die Evolution der betrieblichen DV-Abteilung. Eine lebenszyklustheoretische Analyse. Würzburg 1996 Heinzl, A.: Die Rolle des CIO in der Unternehmung. In: WIRTSCHAFTSINFORMATIK 4/2001, 408–420 Henderson, J. C. / Venkatraman, D. J.: Five principles for making the most of IT. FINANCIAL TIMES, Supplement „Mastering Information Management“ vom 1.3.1999, 4–5 Herrmann, C. / Müller, S.-A.: Business Intelligence Services bei T-Mobile Deutschland: Service Level Agreements und servicebezogenes Datenqualitätsmanagement zur kundengerechten Leistungserbringung. In: Dinter, B. et al. (Hrsg.): DW2008. Synergien durch Integration und Informationslogistik. 27./28.10.2008 in St. Gallen, Switzerland. Lecture Notes in Informatics (LNI) - Proceedings. Bonn 2008, 229–248 Herzwurm, G. / Stelzer, D.: Wirtschaftsinformatik versus Information Systems – Eine Gegenüberstellung. Ilmenauer Beiträge zur Wirtschaftsinformatik Nr. 2008-01 zugleich Stuttgarter Schriften zur Unternehmenssoftware – Arbeitsbericht Nr. 2. Ilmenau, Stuttgart 2008

564

Literaturverzeichnis

Heusler, B. / Roland, M.: IT-Vertragsrecht. Zürich 2004 Heussen, B. (Hrsg.): Handbuch Vertragsverhandlung und Vertragsmanagement. 3. A., Köln 2007 Hiles, A. (Hrsg.): The Definitive Handbook of Business Continuity Management. 2. A. Chichester 2007 Hill, A. / Ariyachandra, T. / Frolick, M.: 10 Principles to Ensure Your Data Warehouse Implementation is a Failure. In: International Journal of Business Intelligence Research 2/2011, 37–47 Hirsch, B. / Hammer, D. / Mäder, O. B. / Kauerhoff, M.: Wirtschaftsprüfung und Controlling – Ausgestaltung der institutionellen Zusammenarbeit. In: CONTROLLING 1/2009, 39–47 Hirschheim, R. / Heinzl, A. / Dibbern, J.: Information Systems Outsourcing. Enduring Themes, New Perspectives and Global Challenges. 2. A., Berlin et al. 2006 Hoch, D. / Laartz, J.: How IT can drive business process reorganization: An Interview with CIO of Volkswagen. In: The McKinsey Quarterly: The Online Journal of McKinsey & Co. September/2006, o. S. Hochstein, A. / Brenner, W. / Uebernickel, F.: Operations Management and IS. In: Proceedings oft he Twelfth Ammericas Conference on Information Systems. Acapulco, Mexiko, August 2006 Hofmann, E.: Kennzahlensysteme für Outsourcing-Dienstleistungen. Siemens Communication Consulting, Frankfurt a. M. 2003 Hofmann, R.: Führungskraft und Schiedsrichter. In: Computerwoche vom 18.7.1986, 27 Högler, T.: Framework für eine holistische Wirtschaftlichkeitsanalyse mobiler Systeme. Dissertationsprojekt, Institut AIFB, Universität Karlsruhe. http://gi-mms.de/mms2006/kurzbeitraege/hoegler.pdf; Abruf 3.11.2008 Horváth, P.: Controlling. 11. A., München 2009 Hosenfeld Consulting: http://www.ho-con.de/infoman.htm; Abruf 2.5.2011 Hruschka, P.: Agility. (Rück)-Besinnung auf Grundwerte in der Softwareentwicklung. In: Informatik Spektrum 6/2003, 397–401 Huizingh, K. R. E. / Vrolijk, C. J.: Decision Support for Information Systems Management: Applying Analytic Hierarchy Process. Research Report No. 95B26, University Groningen, 1995 Humphrey, W. S.: Managing the Software Process. Reading 1989 Hurtienne, J. / Prümper, J.: Vom Zauberer zum Partner - Usability Beratung im Spiegel organisationaler Reife. In: Nissen, V. (Hrsg.): Consulting Research. Unternehmensberatung aus wissenschaftlicher Perspektive. Wiesbaden 2007, 335–353 IBM Corp.: Cloud Computing: http://www-05.ibm.com/de/cloud/resources.html (Portal u.a. mit White Papers und Fallstudien; Abruf 19. April 2011 IBM Deutschland GmbH (Hrsg.): Der strategische Einsatz von Informationssystemen. In: IBM Nachrichten 290/1987, 66–70 IDEA: http://www.auditware.co.uk/downloads/180_V8-Highlights-A4-AUDITWARE.pdf; Abruf 11.5.2011 IDW (Hrsg.): Projekt begleitende Prüfung von Informationstechnologie. In: IDW Fachnachrichten 10/2008, 427– 441 (IDW PS 850) IDW (Hrsg.): Prüfung von IT-gestützten Geschäftsprozessen im Rahmen der Abschlussprüfung. In: IDW Fachnachrichten 1/2009, 39–49 (IDW PH 9.3302) IDW (Hrsg.): Stellungnahme FAMA 1/1987: Grundsätze ordnungsmäßiger Buchführung bei computergestützten Verfahren und deren Prüfung. In: Die Wirtschaftsprüfung 1,2/1988, 1–35 IEEE Security & Privacy, November/December 2010: Cloud Computing IIR-Arbeitskreis DV-Revision: Prüfung der Software-Lizenzen. In: Zeitschrift Interne Revision 1+2/1999, 20–34 Imai, M.: KAIZEN – Der Schlüssel zum Erfolg im Wettbewerb. 2. A., München 2001 Information Security Forum: Standard of Good Practice for Information Security. 2007. http://www.isfsecuritystandard.com; Abruf 30. März 2011 Inmon, W. H.: Building the Data Warehouse. 4. A., Indianapolis 2005 Institut für Interne Revision Austria (Hrsg.): Das interne Kontrollsystem aus Sicht der Internen Revision. Wien 2004 INTARGIA Managementberatung: www.intargia.com/deutsch/veranstaltungen/targion/index.php; Abruf 5.5.2011 ipo: Stellenbild des Informationsmanagers. http://www.ipo.jku.at/index.php?menuid=103; Abruf 19.5.2008 Iqbal, M. / Nieves, M.: ITIL Service Strategy. London 2007 Irani, Z.: Information systems evaluation: navigating through the problem domain. In: Information & Management 2002, 111–124 IT Governance Institute (Hrsg.): CobiT 4.1: Framework, Control Objectives, Management Guidelines, Maturity Models. Rolling Meadows 2007 IT Governance Institute / Office of Government Commerce / IT Service Management Forum (Hrsg.): Aligning CobiT, ITIL and ISO 17799 for Business Benefit: Management Summary. Rolling Meadows 2005. http://www.itsmf.com; Abruf 01. Juni 2011 IT-Beauftragte der Bundesregierung (BfIT): 1. Newsletter zu Green-IT: http://www.umweltbundesamt.de/produkte/dokumente/newsletter_bfit_intelligente_vergabe.pdf; Abruf 2.5.2011

Literaturverzeichnis

565

ITGI (Hrsg.): CobiT 4.1: Framework, Control Objectives, Management Guidelines, Maturity Models. Rolling Meadows 2007 ITGI (Hrsg.): Enterprise Value: Governance of IT Investments. The Val IT Framework 2.0. Rolling Meadows 2008 ITGI (Hrsg.): Global Status Report on the Governance of Enterprise IT (GEIT). Rolling Meadows 2011 ITGI / KPMG (Hrsg.): IT Governance für Geschäftsführer und Vorstände. 2. A. 2003. http://www.isaca.org; Abruf 01. Juni 2011 Ives, B. / Learmonth, G. P.: The Information System as a Competitive Weapon. In: Communications of the ACM 12/1984, 1193–1201 Jaburek, W. J.: Handbuch der EDV-Verträge. Musterverträge für Anwender und Anbieter Bd. I. 3. A., Wien 2000 Jaburek, W. J.: Handbuch der EDV-Verträge. Musterverträge für Anwender und Anbieter Bd. II., Wien 2003 Jackson, R.: Testmanagement: Professionelles Testen. In: Informatik Spektrum 1/2009, 37–41 Jacobson, I. / Booch, G. / Rumbaugh, J.: The unified software development process. Amsterdam 1999 Jäger, R.: Praxisbuch Coaching – Erfolg durch Business Coaching. Offenbach 2001 Jahnel, D. / Schramm, A. / Staudegger, E. (Hrsg.): Informatikrecht. 2. A., Wien/New York 2003 Jaspersen, T.: IT-Controlling für Mittel- und Kleinbetriebe. Berlin 2005 Joecks, F.: Kurzbericht: SCRUM & V-Modell XT in einem Projekt. München 2010; http://www.bpm-soacenter.com Abruf 28. Juni 2011 Johannsen, W. / Goeken, M.: Referenzmodelle für IT-Governance. Strategische Effektivität und Effizienz mit COBIT, ITIL & Co. Heidelberg 2007 Jonen, A. et al.: Balanced IT-Decision Card. In: WIRTSCHAFTSINFORMATIK 3/2004, 196–203 jusIT – Zeitschrift für IT-Recht. http://global.lexisnexis.com/at Kainz, G. A. / Walpoth, G.: Die Wertschöpfungskette als Instrument der IS-Planung. In: Information Management 4/1992, 48–57 Kaiser, M. G. / Smolnik, S. / Riempp, G.: Konzeption eines Information-Lifecycle-Management-Frameworks im Dokumenten-Management-Kontext. In: Bichler, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 483–494 Kanakamedala, K. / Kaplan, J. M. / Srinivasaraghavan, R.: A smarter approach to data storage. In: The McKinsey Quarterly: The Online Journal of McKinsey & Co. March/2007, 1–3 Kang, H. / Bradley, G.: Measuring the Performance of Internal Services: Is SERVQUAL the Answer? In: Neely, A. (Ed.): Performance Measurement 2000. Proc. of the 2. Int. Conf. on Performance Measurement, University of Cambridge, 19.-21. July 2000, 283–290 Kaplan, J. M. / Roy, R. / Srinivasaraghavan, R.: Meeting the demand for data storage In: The McKinsey Quarterly: The Online Journal of McKinsey & Co. June/2008, 1–6 Kaplan, R. S. / Norton, D. P.: Balanced Scorecard. Stuttgart 1997 Kaplan, R. S. / Norton, D. P.: Die strategiefokussierte Organisation – führen mit der Balanced Scorecard. Stuttgart 2001 Kappelman, L. A. (Hrsg.): The SIM Guide to Enterprise Architecture. New York 2010 Kappelman, L. A. et al.: Enterprise Architecture: Charting the Territory for Academic Research. In: Kappelman, L. A. (Hrsg.): The SIM Guide to Enterprise Architecture. New York 2010, 96–110 Kappelman, L. A.: Some Strategic Y2K Blessings. In: IEEE Software 2/2000, 42–46 Karagiannis, D.: Workflow-Management-System. In: Kurbel, K. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik - Online-Lexikon. München 4. A. 2010, o. S. http://www.enzyklopaedie-der-wirtschaftsinformatik.de Karcher, A.: Middleware. In: Kurbel, K. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik - Online-Lexikon. München 4. A. 2010, o. S. http://www.enzyklopaedie-der-wirtschaftsinformatik.de Kargl, H. / Kütz, M.: IV-Controlling. 5. A., München 2007 KARRIERE – Markt für Führungskräfte: Aufgaben des Org.-DV-Leiters ändern sich mit der Technik. In: Beilage Handelsblatt vom 23.1.1987, K12 Kasten, J. E.: Knowledge Strategy and Its Role in the Organization: An Exploratory Study. In: International Journal of Knowledge Management 3/2009, 38–53 Kathmann, H. / Maicher, M.: Kennzahlensystem für einen konzerngebundenen IT-Dienstleister. In: HMD – Praxis der Wirtschaftsinformatik 254/2007, 16–26. Kelm, P. / Heinzl, A.: Der Chief Information Officer im Vorstand von Unternehmen des deutschsprachigen Raumes. Working Papers in Information Systems Nr. 04/2003, Mannheim 2003 Kemper, H.-G. / Mehanna, W. / Unger, C.: Business Intelligence - Grundlagen und praktische Anwendungen. Eine Einführung in die IT-basierte Managementunterstützung. 2. A., Wiesbaden 2006 Klein, H.: Partnerschaft zwischen Fachabteilung und EDV. In: Heilmann, H. (Hrsg.): Zusammenarbeit zwischen Fachabteilung und EDV. Stuttgart/Wiesbaden 1980, 15–63 Klein, R. / Scholl, A.: Planung und Entscheidung: Konzepte, Modelle und Methoden einer modernen betriebswirtschaftlichen Entscheidungsanalyse. München 2004

566

Literaturverzeichnis

Klook, J.: Verrechnungspreise. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A. 1992, 2554–2572 Kluck, M.: Methoden der Informationsanalyse – Einführung in die empirischen Methoden für die Informationsbedarfsanalyse und die Markt- und Benutzerforschung. In: Kuhlen, R. / Seeger, T. / Strauch, D. (Hrsg.): Grundlagen der praktischen Information und Dokumentation. Handbuch zur Einführung in die Informationswissenschaft und -praxis. 5. A., München 2004, 271–288 Kneuper, R. / Wiemers (Hrsg.), M.: Leichte Vorgehensmodelle. 8. Workshop der Fachgruppe 5.11 der Gesellschaft für Informatik e. V. (GI). Aachen 2001 Kneuper, R.: CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration. 2. A., Heidelberg 2007 Knolmayer, G.: Benutzersupport – eine Kernkompetenz des IV-Bereichs? In: HMD – Theorie und Praxis der Wirtschaftsinformatik 189/1996, 7–24 Ko, M. / Osei-Bryson, K.-M. / Dorantes, C.: Investigating the Impact of Publicly Announced Information Security Breaches on Three Performance Indicators of the Breached Firms. In: Information Resources Management Journal 2/2009, 1–21 Köbler, F. / Fähling, J. / Krcmar, H. / Leinmeister, J. M.: IT-Governance und IT-Entscheidertypen in deutschen Krankenhäusern – Eine empirische Untersuchung unter Krankenhaus-IT-Leitern. In: WIRTSCHAFTSINFORMATIK 6/2010, 353–365 Koch, M. / Lasi, H. / Kemper, H.-G.: Informationsmanagement in der Produktion - Empirische Ableitung eines Konzepts zur Ermittlung produktionsspezifischer Informationsbedarfe. In: Bernstein, A. / Schwabe, G. (Hrsg.): Proceedings of the 10th International Conference on Wirtschaftsinformatik WI 2.011. Volume 1. Zürich 2011, 456–465 König, W. / Ludwig, J.-Ch.: Vergleichende Buchbesprechung „Informationsmanagement“. In: WIRTSCHAFTSINFORMATIK 4/1993, 405–410 Koreimann, D. S.: Grundlagen der Software-Entwicklung. 3. A., München/Wien 2000 Koreimann, D. S.: Methoden der Informationsbedarfsanalyse. Berlin/New York 1976 Kosler, M. / Matthesius, M. / Stelzer, D.: Ein Konzept zur automatisierten Klassifizierung von Informationen für das Information Lifecycle Management - dargestellt am Beispiel des SAP NetWeaver Business Intelligence. In: Dinter, B. et al. (Hrsg.): DW2008. Synergien durch Integration und Informationslogistik. Lecture Notes in Informatics (LNI) - Proceedings. Bonn 2008, 129–145 Kossow, R.: http://www.erpmanager.de/magazin/artikel_1339_tco_total_cost_ownership_wirtschaftlichkeit.html; Abruf 20.5.2011 Kozlova, E.: WI – Vergleichende Literaturstudie. IT-Governance. In: WIRTSCHAFTSINFORMATIK 5/2008, 418425 KPMG (Hrsg.): IT-Management 2005. Standortbestimmung und Trends in der Schweizer Informatik. http://www.kpmg.ch/RIM; Abruf 14.4.2008 Krcmar, H.: Informationsmanagement. 5. A., Berlin et al. 2010 Krcmar, H: Bedeutung und Ziele von Informationssystem-Architekturen. In: WIRTSCHAFTSINFORMATIK 5/1990, 395–402 Kronz, A. / La Greca, C. / Kaffai, B.: Prozessorientiertes Service Level Management. In: Lehner, F. / Nösekabel, H. / Kleinschmidt, P. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2006. Tagungsband 1. Berlin 2006, 35–46 Kruchten, P.: The Rational Unified Process. An Introduction. 3. A., Amsterdam 2004 Krüger, W. / Pfeiffer, P.: Strategisches Management von Informationen – Formulierung und organisatorische Umsetzung der Informationsstrategie. In: Office Management 10/1987, 28–34 Kuhlen, R.: Informationsmarkt. Chancen und Risiken der Kommerzialisierung von Wissen. Konstanz 1995 Kütz, M. (Hrsg.): Kennzahlen in der IT. Heidelberg 2003 Kütz, M.: IT-Controlling für die Praxis. Konzeption und Methoden. Heidelberg 2005 Lacy, S. / MacFarlane, I.: ITIL Service Transition. London 2007 Langer, P. et al.: Vorgehensmodelle für die Entwicklung hybrider Produkte – eine Vergleichsanalyse. In: Schumann, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2010. Göttingen 2010, 2043–2056 Lankhorst, M. et al.: Enterprise Architecture at Work. Modelling, Communication, and Analysis. 2. A., Berlin et al. 2009 Lee, D. M. S. / Trauth, E. M. / Farwell, D.: Critical Skills and Knowledge Requirements of IS Professionals. A Joint Academic/Industry Investigation. In: MIS Quarterly 3/1995, 313–340 Leemhuis, J. P.: Using Scenarios to Develop Strategies. In: Long Range Planning 2/1985, 30–37 Leimstoll, U.: Informationsmanagement in mittelständischen Unternehmen. Frankfurt a. M. et al. 2001 Lercher, H. J.: Wertanalyse an Informationssystemen. Wiesbaden 2000 Liggesmeyer, P.: Software-Qualität: Testen, Analysieren und Verifizieren von Software. 2. A. Heidelberg 2009 Linthicum, D. S.: Enterprise Application Integration. Boston/San Francisco/New York 2000

Literaturverzeichnis

567

Lippold, H. et al.: Sicherheitskonzepte und ihre Verknüpfung mit Sicherheitsstrategie und Sicherheitsmanagement. In: WIRTSCHAFTSINFORMATIK 4/1992, 367–377 Litke, H. D. / Voegele, A. A.: Informationsmanagement als Führungsaufgabe, In: Fraunhofer-Gesellschaft (Hrsg.): Information als Produktionsfaktor. FhG-Bericht 1/1986, 12–16 Loshin, D.: Master Data Management. Amsterdam 2008 Louridas, P.: Up in the Air: Moving Your Applications to the Cloud. In: IEEE Software 4/2010, 6–11 Luftman, J. / Ben-Zvi, T.: Key Issues for IT Executives 2010: Judicious IT Investments Continue Post-Recession. In: MIS Quarterly Executive 4/2010, 263–273 Luftman, J. / McLean, E. R.: Key Issues for IT Executives. In: MIS Quarterly Executive 3/2004, 89–104 Lullies, V. / Bollinger, H. / Weltz, F.: Konfliktfeld Informationstechnik. Innovation als Managementproblem. Frankfurt a. M. 1990 Lünendonk GmbH (Hrsg.): Information Lifecycle Management 2007 – Bedeutung für den Wertbeitrag der IT. Bad Wörishofen 2007 Madauss, B. J.: Handbuch Projektmanagement. 7. A., Stuttgart 2006 Mäder, B. / Ziegler, M.: Erfolgsfaktoren im Auswahlprozess betriebswirtschaftlicher Software für KMU. In: BFuP 5/2010, 558–574 Maier, R. / Hädrich, T.: Modell für die Erfolgsmessung von Wissensmanagementsystemen. In: WIRTSCHAFTSINFORMATIK 5/2001, 497–510 Maier, R.: Knowledge Management Systems: Information und Communication Technologies for Knowledge Management. 3. A., Berlin et al. 2007 Mark, D. / Rau, D.P.: Splitting demand from supply in IT. In: The McKinsey Quarterly, September 2006, S. 1-4. http://www.mckinseyquarterly.com; Abruf 28. Juni 2011 Marly, J.: Software-Überlassungsverträge. 4. A., München 2004 Marrone, M. / Kolbe, L. M.: Einfluss von IT-Service-Management-Frameworks auf die IT-Organisation. Eine empirische Studie zu Vorteilen, Herausforderungen und Prozessen. In: WIRTSCHAFTSINFORMATIK 1/2011, 5–19 Marten, K.-U. / Quick, R. / Ruhnke, K.: Lexikon der Wirtschaftsprüfung. Stuttgart 2006 Martin, J. with Leben, J.: Strategic Information Planning Methodologies. 2. Ed., Englewood Cliffs/NJ 1989 Martin, J.: Information Engineering. Book I Introduction. Englewood Cliffs/NJ 1989, Book II Planning & Analysis. Englewood Cliffs/NJ 1990, Book III Design & Construction. Englewood Cliffs/NJ 1990 Matthesius, M. / Stelzer, D.: Analyse und Vergleich von Konzepten zur automatisierten Informationsbewertung im Information Lifecycle Management. In: Bichler, K. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 471–482 Matys, E.: Praxishandbuch Produktmanagement – Grundlagen und Instrumente. 3. A. Frankfurt a. M. 2005 McFarlan, F. W. / McKenney, J. L.: Corporate Information Systems Management. Homewood/Ill. 1983 McFarlan, F. W.: Information Technology Changes the Way You Compete. In: Harvard Business Review 3/1984, 98–103 McKinney, E. H. / Yoos, C. J.: Information about information: A taxonomy of views. In: MIS Quarterly 2/2010, 329–344 Mell, P. / Grance, T.: The NIST Definition of Cloud Computing (Draft). Recommendations of the National Institute of Standards and Technology. Special Publication 800-145. 2011, http://csrc.nist.gov Abruf 25. Juli 2011 Mellis, W. / Herzwurm, G. / Stelzer, D.: TQM der Softwareentwicklung. Mit Prozeßverbesserung, Kundenorientierung und Change Management zu erfolgreicher Software. 2. A., Braunschweig/Wiesbaden 1998 Melville, N. / Kraemer, K. / Gurbaxani, V.: Information Technology and Organizational Performance – An integrative Model of IT Business Value. In: MIS Quarterly 2/2004, 283–322 Mende, U. / Berthold, A.: SAP® Business Workflow – Konzept, Anwendung, Entwicklung. 2. A. München 2000 Menon, T. / Tompson, L. / Choi, H.-S.: Tainted Knowledge vs. Tempting Knowledge: People Avoid Knowledge from Internal Rivals and Seek Knowledge from External Rivals. In: Management Science 8/2006, 1129–1144 Mertens, P. / Plattfaut, E.: Informationstechnik als strategische Waffe. In: Information Management 2/1986, 6–17 Mertens, P., Wirtschaftsinformatik – Von den Moden zum Trend. In: König, W. (Hrsg.), Wirtschaftsinformatik '95, Wettbewerbsfähigkeit – Innovation – Wirtschaftlichkeit. Heidelberg 1995, 25–64 Mertens, P.: Gefahren für die Wirtschaftsinformatik - Risikoanalyse eines Faches. In: Ferstl, O. K. et al. (Hrsg.): Wirtschaftsinformatik 2005. eEconomy, eGovernment, eSociety. Heidelberg 2005, 1733–1754 Mertens, P.: Operiert die Wirtschaftsinformatik mit falschen Unternehmenszielen? – 15 Thesen. In: Becker, J. / König, W. / Schütte, R. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie: Bestandsaufnahme und Perspektiven. Wiesbaden 1999, 379–392 Mertens, P.: Process focus considered harmful? In: WIRTSCHAFTSINFORMATIK 4/1996, 446–447 Mertins, K. / Alwert, K.: Integrierte Wissensbewertung - Ein Instrument zur Bewertung, Steuerung und Bilanzierung von Wissen. In: ZWF- Zeitschrift für wirtschaftlichen Fabrikbetrieb 11/2003, 578–582

568

Literaturverzeichnis

Messerschmidt, M. / Schülein, P. / Murnleitner, M.: Der Wertbeitrag der IT zum Unternehmenserfolg. Stuttgart 2008 Michaels, A.: Die große Begehung der Mittelbaustelle. F.A.Z. vom 11.8.2010, N5 Michels, J. K.: http://www.jomi1.com/; Abruf 4.3.2011 Miller, K. / 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 Mon, L.: Face threat. In: Fisher, K. E. / Erdelez, S. / McKechnie, L. E. F. (Hrsg.): Theories of information behavior. Medford/New Jersey, 2005, 149–152 Moriz, H.-W. / Dreier, T.: Rechtshandbuch zum E-Commerce. 2. A., Köln 2005 Müller-Zantop, S.: Wo liegt der Wert der Informationsverarbeitung? In: F.A.Z. vom 17.3.1998, B 6 Myers, G. J.: Methodisches Testen von Programmen. 7. A., München/Wien 2001 Nägele, R. / Schreiner, P.: Bewertung von Werkzeugen für das Management von Geschäftsprozessen. In: ZfO Zeitschrift Führung und Organisation 4/2002, 201–210 Nassim, B.: Investigating the Impact of Knowledge Management Factors on New Product Development Performance. In: International Journal of Knowledge Management 3/2009, 21–37 Naumann, F.: Datenqualität. In: Informatik Spektrum 1/2007, 27–31 Nicholas, D.: Assessing Information Needs: Tools, Techniques and Concepts for the Internet Age. 2. A., London 2000 Nippa, M.: Bestandsaufnahme des Reengineering-Konzepts. Leitgedanken für das Management. In: Nippa, M. / Picot, A. (Hrsg.): Prozeßmanagement und Reengineering. Die Praxis im deutschsprachigen Raum 2. A., Frankfurt a. M./New York 1996, 61–77 Nissen, V. / Seifert, M.: Das Consulting C - Grundzüge eines Prozessreferenzmodells für Beratungsunternehmen. In: Bichler, M. et al. (Hrsg.): Proceedings der Multikonferenz Wirtschaftsinformatik, München 26.-28.02.2008. Berlin 2008, 1661–1674 NIST Special Publication 800-100: Information Security Handbook: A Guide for Managers. Washington 2006 NIST Special Publication 800-34 rev. 1: Contingency Planning Guide for Federal Information Systems. Washington 2010 Nollau, H.-G. / Gottfried, U.: Entscheidungskompetenz durch Anwendung der Vektor-Nutzwertanalyse. Lohmar 2009 Nonaka, I. / Takeuchi, H.: The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation. New York 1995 North, K. / Probst, G. / Romhardt, K.: Wissen messen - Ansätze, Erfahrungen und kritische Fragen. In: ZfO - Zeitschrift Führung und Organisation 3/1998, 158–166 North, K.: Wissensorientierte Unternehmensführung. Wertschöpfung durch Wissen. 4. A., Wiesbaden 2005 Nusselein, M.: Empirische Erkenntnisse einer Informationsbedarfsanalyse an bayerischen Hochschulen. In: Beiträge zur Hochschulforschung 1/2002, 100–114 o. V.: Lagebericht zur Informationssicherheit (1). /Microsoft-Sicherheitsstudie 2010. In: Die Zeitschrift für Informationssicherheit 4/2010, 26–34 o. V.: Lagebericht zur Informationssicherheit (2). /Microsoft-Sicherheitsstudie 2010. In: Die Zeitschrift für Informationssicherheit 5/2010, 12–20 o. V.: Lagebericht zur Informationssicherheit (3). /Microsoft-Sicherheitsstudie 2010. In: Die Zeitschrift für Informationssicherheit 6/2010, 14–21 o. V.: V-Modell XT Version 1.3 Berlin 2008 o.V.: Firmen gehen Management von Stammdaten oft falsch an. In: Computer Zeitung 38/2007, 8 Odenthal, R.: Sicherheit und Prüfung von Betriebssystem und Netzwerk in einer SAP R3-Umgebung. http://www.roger-odenthal.de/Mitgliederbereich/downloads/Netz_1.pdf; Abruf 6.3.2008 Oestereich, B.: Analyse und Design mit UML 2.0. Objektorientierte Softwareentwicklung. 8. A., München/Wien 2006 Office of Government Commerce (OGC): The Official Introduction to the ITIL Service Lifecycle. London 2007 Office of Government Commerce: Managing Successful Projects with PRINCE2. London 2005 Oh, W. / Pinsonneault, A.: The Assessment of the strategic Value of Information Technologies – Conceptual and analytical Approaches. In: MIS Quarterly 2/2007, 239-265 Olbrich, A.: ITIL kompakt und verständlich: Effizientes IT Service Management – Den Standard für IT-Prozesse kennenlernen, verstehen und erfolgreich in der Praxis umsetzen. 4. A., Wiesbaden 2008 O'Reilly, T.: What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software. http://www.oreilly.de/artikel/web20.html o. O. 2005, Abruf 9. Juni 2011 Ortmann, G.: Unternehmensstrategien und Informationstechniken. In: Zeitschrift für betriebswirtschaftliche Forschung 11/1991, 997–1001

Literaturverzeichnis

569

Osterburg, S.: Das Rechenzentrum als Produktionsstätte für IT-Dienstleistungen – Verfügbarkeitsmangement in virtualisierten Rechenzentren. Göttingen 2010 Österle, H. / Brenner, W. / Hilbers, K.: Unternehmensführung und Informationssystem. Der Ansatz des St. Galler Informationssystem-Management. 2. A., Stuttgart 1992 Osterloh, M. / Frey, S.: Evaluations – hidden costs, questionable benefits, and superior alternatives. Unveröffentlichtes Manuskript, Universität Zürich 2007 Osterloh, M. / Frost, J.: Prozessmanagement als Kernkompetenz. Wie Sie Business Reengineering strategisch nutzen können. 5. A., Wiesbaden 2006 Ott, H. J.: Wirtschaftlichkeitsanalyse von EDV-Investitionen mit dem WARS-Modell am Beispiel der Einführung von CASE. In: WIRTSCHAFTSINFORMATIK 6/1993, 522–531 Overhage, S. / Schlauderer, S. / Birkmeier, D.: Sind Ereignisgesteuerte Prozessketten besser für Fachanwender geeignet als UML Aktivitätsdiagramme? Eine empirische Untersuchung. In: Bernstein, A. / Schwabe, G. (Hrsg.): Proceedings of the 10th International Conference on Wirtschaftsinformatik WI 2.011. Volume 2. Zürich 2011, 745–755 Padberg, F. / Tichy, W.: Schlanke Produktionsweisen in der modernen Softwareentwicklung. In: WIRTSCHAFTSINFORMATIK 3/2007, 162–170 Parker, M. M. / Benson, R.: Information Economics - Linking Business Performance to Information Technology. Englewood Cliffs/NJ 1988 Patel, P. / Ranabahu, A. / Sheth, A.: Service Level Agreement in Cloud Computing. In: Proceedings of the Workshop on Best Practices in Cloud Computing: Implementation and Operational Implications for the Cloud at ACM International Conference on Object-Oriented Programming, Systems, Languages, and Applications, Orlando, 2009. New York 2009, o. S. Paulk, M. C. et al.: The Capability Maturity Model: Guidelines for Improving the Software Process. Reading 1995 Pauls, W.: Wirtschaftlichkeitsanalyse analytischer Informationssysteme. Saarbrücken 2007 Pawloski, S. D. / Robey, D.: Bridging User Organizations: Knowledge Brokering and the Work of Information Technology Professionals. In: MIS Quarterly 4/2004, 645–672 Peemöller, C.-Ch. / Volker, H.: Corporate Governance und Interne Revision – Handbuch für die Neuausrichtung des Internal Auditings. Berlin 2007 Peltier, T. R.: Information Security Risk Analysis. 2. A. Boca Raton 2005 Pendse, N. / Creeth, R.: The OLAP Report. New York 1995 Peppard, J. / Lambert, R. / Edwards, C.: Whose job is it anyway? Organizational information competencies for value creation. In: Information Systems Journal 10/2000, 291–322 Peterhans, M.: Informationsmanagement – Theoretische Grundlagen und Führungskonzept. Zürich 1996 Petrocelli, T.: Data Protection and Information Lifecycle Management. New York et al. 2005 Pfarl, W. (Hrsg.): IT-Verträge – Handbuch für Praktiker. Wien 2007 Pfeifer, T. / Schmitt (Hrsg.), R.: Masing. Handbuch Qualitätsmanagement. 5. A., München/Wien 2007 Pfeiffer, P.: Technologische Grundlage, Strategie und Organisation des Informationsmanagements. Berlin/New York 1990 Pfleeger, C. P. / Pfleeger, S. L.: Security in Computing. 4. A., Upper Saddle River 2006 Pfohl, H.-Chr.: Produktionsfaktor „Information“ in der Logistik. In: Institut für Logistik der Deutschen Gesellschaft für Logistik (Hrsg.): Informationssysteme in der Logistik. Dortmund 1985 Philipp, M.: Ordnungsmäßige Informationssysteme im Zeitablauf. In: WIRTSCHAFTSINFORMATIK 4/1998, 312–317 Piccoli, G. / Blake, Ives: IT-dependent Strategic Initiatives and Sustained Competitive Advantage: A Review and Synthesis of the Literature. In: MIS Quarterly 4/2005, 141–116 Picot, A.: Entscheidungshilfen für den Aufbau und die Organisation von Informationssystemen. In: Dialog 2/1991, 5–9 Pietsch, T. / Martiny, L. / Klotz, M.: Strategisches Informationsmanagement. Bedeutung und organisatorische Umsetzung. 4. A., Berlin 2004 Pirker, S.: Bilanzierung von Software. Wien 1992 Polanyi, M.: The Tacit Dimension. Gloucester 1983 Polli, R. / Cook, V.: Validity of the Product Life Cycle. In: Journal of Business 4/1969, 385–400 Porter, M. E. / Millar, V. E.: How Information Gives You Competitive Advantage. In: Harvard Business Review 4/1985, 149–160 Porter, M. E.: Competitive Advantage: Creating and Sustaining Superior Performance. New York 1985 Porter, M. E.: Wettbewerbsstrategie. 10. A., Frankfurt a. M. 1999 Porter, M. E.: Wettbewerbsvorteile. 7. A., Frankfurt a. M. 2000 Posner, M. V.: International Trade and Technical Change. In: Oxford Economic Papers 3/1961, 323–341 PricewaterhouseCoopers: Cloud Computing – Navigation in der Wolke. Frankfurt/M. 2010

570

Literaturverzeichnis

Probst, G. J. B. / Raub, S. / Romhardt, K.: Wissen managen. Wie Unternehmen ihre wertvollste Ressource optimal nutzen. 5. A., Wiesbaden 2006 Project Management Institute: A Guide to the Project Management Body of Knowledge: PMBOK Guide. 4. A., Newton Square 2010 Prozept: http://www.prozept.com/quo-vadis-it-it-trends-2011Methodenverweise; Abruf 8. Mai 2011 Puppe, F.: Künstliche Intelligenz. In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. A., Berlin/Heidelberg/New York 2001, 276–278 Radisic, I.: Ein prozessorientierter, policy-basierter Ansatz für ein integriertes, dienstorientiertes Abrechnungsmanagement. Dissertation Universität München 2003 Rausch, A. / Broy, M.: Das V-Modell XT: Grundlagen, Erfahrungen und Werkzeuge. Heidelberg 2008 Reb, M. / Herr, R.: IV-Infrastruktur-Controlling – Kennzahlengestützte Steuerung der IT-Ressourcen. In: Krcmar, H. et al. (Hrsg.): IV-Controlling auf dem Prüfstand. Wiesbaden 2000, 75–103 Redeker, H.: Handbuch der IT-Verträge. Loseblattwerk, Berlin 2000 ff. Reibnitz, U. von: Szenariotechnik. Instrumente für die unternehmerische und persönliche Erfolgsplanung. 2. A., Wiesbaden 1992 Reichmann, T.: Controlling mit Kennzahlen und Management-Tools. 7. A., München 2006 Reichwald, R. et al.: Telekooperation im Innovationstest – Strategieorientierte Evaluation von Pilotprojekten. In: WIRTSCHAFTSINFORMATIK 3/1998, 205–213 Reichwald, R.: Ein mehrstufiger Bewertungsansatz zur wirtschaftlichen Leistungsbeurteilung der Bürokommunikation. In: Hoyer, R. H. / Kölzer, G. (Hrsg.): Wirtschaftlichkeitsrechnungen im Bürobereich. Berlin 1987, 23–33 Renkema, T. J. W.: The IT Value Quest. How to Capture the Business Value of IT-Based Infrastructure. Chichester et al. 1999 Richter, J.-P. / Haller, H. / Schrey, P.: Serviceorientierte Architektur. In: Informatik Spektrum 5/2005, 413–416 Riedl, R. / Kobler, M. / Roithmayr, F.: Zur personellen Verankerung der IT-Funktion im Vorstand börsennotierter Unternehmen. In: WIRTSCHAFTSINFORMATIK 2/2008, 111–128 Riedl, R.: Analytischer Hierarchieprozess vs. Nutzwertanalyse: Eine vergleichende Gegenüberstellung zweier multiattributiver Auswahlverfahren am Beispiel Application Service Providing. In: Fink, K. / Ploder, C. (Hrsg.): Wirtschaftsinformatik – Schlüssel zum Unternehmenserfolg. Wiesbaden 2006, 99–127 Riedl, R.: Application Service Providing – Entwicklung eines Modells zur Qualitätsmessung. Wiesbaden 2005 Riedl, R.: Der Analytic Hierarchy Process: Ein geeignetes Verfahren für komplexe Entscheidungen in der Wirtschaftsinformatik? In: HMD 246/2005, 104–114 Riempp, G.: Integrierte Wissensmanagement-Systeme. Architektur und praktische Anwendung. Berlin/Heidelberg/ New York 2004 Riempp, G.: Integriertes Wissensmanagement - Strategie, Prozesse und Systeme wirkungsvoll verbinden. In: HMD Praxis der Wirtschaftsinformatik. 246/2005, 6–19 Robb, A. / Parent, M.: Understanding IT Governance: A Case of Two Financial Mutuals. In: Journal of Global Information Management (JGIM) 3/2009, 59-77 Rockart, J. F. / Scott, M.: Implications of Changes in Information Technology for Corporate Strategy. In: Interfaces 1/1984, 84–95 Rockart, J. F.: Chief executives define their own data needs. In: Harvard Business Review 2/1979, 81–93 Rockart, J. F.: The Changing Role of the Information Systems Executive. A Critical Success Factors Perspective. In: Sloan Management Review 1/1982, 3–13 Rockart, J. F.: The Line Takes the Leadership – IS Management in a Wired Society. In: Information Management 4/1988, 6–13 Roehl, H.: Instrumente der Wissensorganisation. Perspektiven für eine differenzierende Interventionspraxis. Wiesbaden/New York 2000 Rogers, E. M.: Diffusion of Innovations. 4. Ed., New York 1995 Rohloff, M.: Ein Referenzmodell für die Prozesse der IT-Organisation. In: HMD – Theorie und Praxis der Wirtschaftsinformatik 256/2007, 27–36 Rohweder, J. P. et al.: Informationsqualität - Definitionen, Dimensionen und Begriffe. 2007. http://www.dgiq.de, Abruf 22. Mai 2008 Roßnagel, A. (Hrsg.): Handbuch Datenschutzrecht. München 2003 Roßnagel, A.: Personalisierung in der E-Welt. In: WIRTSCHAFTSINFORMATIK 1/2007, 8–18 Roszak, T.: Der Verlust des Denkens. Über die Mythen des Computer-Zeitalters. München 1986 Röthlin, M.: Management of Data Quality in Enterprise Resource Planning Systems. Lohmar, Köln 2010 Royce, W.: Managing the Development of Large Software Systems. In: Proceedings, IEEE WESCON August/1970, 1–9 Rückel, D. / Steininger, K.: Fallstudie: Einführung eines Enterprise-Content-Management-Systems. In: HMD – Praxis der Wirtschaftsinformatik 258/2007, 78–88

Literaturverzeichnis

571

Rudd, C. / Lloyd, V.: Service Design (ITIL), Version 3. London 2007 Ruh, W. / Maginnis, F. X. / Brown, W. J.: Enterprise Application Integration. New York/Chichester/Weinheim 2001 Rumpel, R.: Planung und Betrieb von Informationssicherheits-Managementsystemen. Erfahrungen aus der Praxis. In: Datenschutz und Datensicherheit 1/2011, 12–15 Saaty, Th. L.: Decision Making for Leaders – The Analytic Hierarchy Process for Decisions in a Complex World. 3. A., Pittsburgh 2001 Salton, G. / McGill, M. J.: Information Retrieval - Grundlegendes für Informationswissenschaftler. Hamburg et al. 1987 Schauenberg, B.: Entscheidungsregeln, kollektive. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Stuttgart 1980, 566–575 Scheer, A.-W.: ARIS - Vom Geschäftsprozess zum Anwendungssystem. 4. A., Berlin 2002 Scheer, A.-W.: Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse. 7. A., Berlin 1997 Schekkerman, J.: Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice. Victoria, Canada 2008 Schekkerman, J.: How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. 3. A., Victoria, Canada 2006 Schlimm, N.: Serviceorientierte Architektur - eine Standortanalyse. In: Informatik Spektrum 3/2010, 282–287 Schlögl, C.: Bestandsaufnahme Informationsmanagement. Wiesbaden 2001 Schmelzer, H. J. / Sesselmann, W.: Geschäftsprozessmanagement in der Praxis. Kunden zufrieden stellen - Produktivität steigern - Wert erhöhen. 6. A., München 2008 Schmidt, N.-H. / Erek, K. / Kolbe, L. M. / Zarnekow, R.: Nachhaltiges Informationsmanagement. In: WIRTSCHAFTSINFORMATIK 5/2009, 463-466 Schmidt-Reindl, K. M.: Informationsmanagement erobert Unternehmen und Behörden. In: GMD-Spiegel 1988, 67– 72 Scholles, F.: Die Nutzwertanalyse und ihre Weiterentwicklung. http://www.laum.uni-hannover.de/ilr/lehre; Abruf 15.11.2008 Scholz C.: Personalarbeit im IT-Bereich – Erfolgskritische Aktionsfelder. In: Sonderheft WIRTSCHAFTSINFORMATIK 10/2000, 14–23 Schönpflug, W. / Schönpflug, U.: Psychologie. 4. A., Weinheim 1997 Schoppek, W. / Putz-Osterloh, W.: Informationsverhalten. In: Schreyögg, G. / v. Werder, A. (Hrsg.): Handwörterbuch Unternehmensführung und Organisation. 4. A., Stuttgart 2004, 489–497 Schranner, G. / Gläser, D.: Nutzen der IT-Revision. In: Deutsches Institut für Interne Revision (Hrsg): Interne Revision aktuell. Berlin 2008, 39–338 Schulte, M. / Schröder, R. (Hrsg.): Handbuch des Technikrechts. Berlin et al. 2003 Schuppenhauer, R.: Grundsätze für eine ordnungsmäßige Datenverarbeitung (GoDV). Düsseldorf 1998 Schütt, P.: The post-Nonaka Knowledge Management. In: Journal of Universal Computer Science. 6/2003, 451– 462. Schütt, P.: Wissensmanagement. Niedernhausen 2000 Schwaber, K. / Beedle, M.: Agile Software Development with Scrum. Upper Saddle River 2001 Schwarzer, B. / Krcmar, H.: Zur Prozessorientierung des Informationsmanagements. In: WIRTSCHAFTSINFORMATIK 1/1995, 33–39 Sedera, D. / Gable, G.: Knowledge Management Competence for Enterprise System Success. In: Journal of Strategic Information Systems 4/2010, 296–306 Seibt, D.: Begriff und Aufgaben des Informationsmanagements – ein Überblick. In: Preßmar, B. (Hrsg.): Informationsmanagement. Wiesbaden 1993, 3–30 Seibt, D.: Informationsmanagement und Controlling. In: WIRTSCHAFTSINFORMATIK 2/1990, 116–126 Serafeimidis, V. / Smithson, S.: Information systems evaluation as an organizational institution – experience form a case study. In: Information Systems Journal 2003, 251–274 Shannon, C. E. / Weaver, W.: Mathematical Theory of Communication. 4. Ed., Urbana/Ill. 1968 Sharma, R. / Yetton. P.: The contingent effects of training, technical complexity, and task interdependence on successful information systems implementation. In: MIS Quarterly 2/2007, 219–238 Sibley, E. H. / Editor, P.: Post Implementation Evaluation of Computer-Based Information Systems: Current Practices. In: Communications of th ACM 2/1990, 203–212 Siemens UK: CRAMM. http://www.cramm.com; Abruf 31. März 2011 Sinz, E. J.: Unternehmensarchitekturen in der Praxis - Architekturdesign am Reißbrett vs. situationsbedingte Realisierung von Informationssystemen. In: WIRTSCHAFTSINFORMATIK 4/2004, 315–316 Skubsch, H.: Der Informations-Manager – ein Manager wie jeder andere? In: Computerwoche vom 4.7.1986, 8 Slaughter, S. A. / Harter, D. E. / Krishnan, M. S.: Evaluating the Cost of Software Quality. In: Communications of the ACM 8/1998, 67–73

572

Literaturverzeichnis

Software Engineering Institute: CMMI for Development, Version 1.3. CMMI-DEV, V1.3. CMU/SEI-2010-TR-033. Pittsburgh, PA 2010 Son, S. / Gladyszewski, Th.: Return on IT-Controlling 2005 – eine empirische Untersuchung zum Einfluss des ITControllings auf die unternehmensweite IT Performance. Arbeitsbericht, E-Finance Lab Frankfurt a. M., Kontakt: [email protected] Sowa, J. F. / Zachmann, J. A.: Extending and Formalizing the Framework for Information Systems Architecture. In: IBM Systems Journal 3/1992, 590–616 Spalding, G. / Case, G.: ITIL Continual Service Improvement London 2007 Spider Contract: http://www.brainwaregroup.com/index.php?id=812; Abruf 3.4.2011 Sprenger, J. / Klages, M. / Breitner, M. H.: Wirtschaftlichkeitsanalyse für die Auswahl, die Migration und den Betrieb eines Campus-Management-Systems. In: WIRTSCHAFTSINFORMATIK 4/2010, 211–223 Stadtler-Pree, I.: Soziale Kompetenz für IT-Mitarbeiter – Trainingsbedarfsanalyse und Trainingsdesign. Projektarbeit Universitätslehrgang Training und Bildungsmanagement an der Universität Linz, 2006 Stadtwerke München GmbH (Hrsg.): Geschäftsbericht 2007. München 2008. http://www.swm.de; Abruf 20. November 2008 Stannat, A. / Petri, C.: Trends in der Unternehmens-IT. In: Informatik Spektrum 3/2004, 227–237 Stata, R.: Organizational Learning - The key to management innovation. In: Sloan Management Review 3/1989, 63– 74 Steeb Anwendungssysteme GmbH Abstatt: Kennzahlen-Cockpit. http://www.steeb.de; Abruf 13.11.2008 Stelzer, D. / Bratfisch, W.: Earned-Value-Analyse – Controlling-Instrument für IT-Projekte und IT-Projektportfolios. In: HMD – Praxis der Wirtschaftsinformatik 254/2007, 61–70 Stelzer, D.: Enterprise Architecture Principles: Literature Review and Research Directions. In: Dan, A. / Gittler, F. / Toumani, F. (Hrsg.): Service-Oriented Computing. ICSOC/ServiceWave 2009. Lecture Notes in Computer Science, Vol. 6275. Berlin 2010, 12–21 Stelzer, D.: Informations- versus Wissensmanagement - Versuch einer Abgrenzung. In: Kemper, H.-G. / Mülder, W. (Hrsg.): Informationsmanagement. Neue Herausforderungen in Zeiten des E-Business. Lohmar 2003, 25–41 Stelzer, D.: Portale - Einführung und Überblick. In: Gentsch, P. / Lee, S. (Hrsg.): Praxishandbuch Portalmanagement. Profitable Strategien für Internetportale. Wiesbaden 2004, 1–26 Stelzer, D.: Risikoanalysen als Hilfsmittel zur Entwicklung von Sicherheitskonzepten in der Informationsverarbeitung. In: Roßbach, P. / Locarek-Junge, H. (Hrsg.): IT-Sicherheitsmanagement in Banken. Frankfurt a. M. 2002, 37–54 Stelzer, D.: Sicherheitsstrategien in der Informationsverarbeitung - Ein wissensbasiertes, objektorientiertes System für die Risikoanalyse. Wiesbaden 1993, 20–46 Stelzer, D.: Wissen. In: Kurbel, K. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik - Online-Lexikon. München 2009, o. S.; http://www.enzyklopaedie-der-wirtschaftsinformatik.de Stickel, E.: Informationsmanagement. München/Wien 2001 Stock, W. G. / Stock, M.: Wissensrepräsentation. Informationen auswerten und bereitstellen. München 2008 Stock-Homburg, R.: Personalmanagement: Theorien – Konzepte – Instrumente. 2. A., Wiesbaden 2010 Sträter, D.: Szenarien als Instrument der Vorausschau in der räumlichen Planung. In: Akademie für Raumforschung und Landesplanung (Hrsg.): Regionalprognosen – Methoden und ihre Anwendung. Hannover 1986 Straub, D. W. / Goodman, S. / Baskerville, R. (Hrsg.): Information Security: Policy, Processes, and Practices. Armonk NY 2008 Straub, W.: „Legal Engineering“ – Was Juristen und Ingenieure voneinander lernen könnten. Neue Zürcher Zeitung vom 15./16.5.2004, 54 Strecker, St.: IT-Performance-Management – Zum gegenwärtigen Stand der Diskussion, In: CONTROLLING 10/2008, 513–518 Studiengesellschaft für Wirtschaft und Recht (Hrsg.): Internet und Recht – Rechtsfragen von E-Commerce und EGovernment. Wien 2004 Supply Chain Council: Supply Chain Operations Reference-model. SCOR Overview Version 10.0. Cyprus, TX. http://supply-chain.org/SCOR; Abruf 22. Juni 2011 SwissICT – Schweizerischer Verband der Informations- und Kommunikationstechnologie (Hrsg.): Berufe der ICT – Informations- und Kommunikationstechnologien. 6. A., Zürich 2004 Synstar Int. (Ed.): Does the board understand the importance of IT yet? http://www.synstar.com/survey1; Abruf 15. Dezember 2004 Szyperski , N.: Gesamtbetriebliche Perspektiven des Informationsmanagements. In: Strunz, H. (Hrsg.): Planung in der Datenverarbeitung. Von der DV-Planung zum Informations-Management. Berlin et al. 1985, 6–20 Szyperski, N.: Geplante Antwort der Unternehmung auf den informations- und kommunikationstechnischen Wandel. In: Frese, E. / Schmitz, P. / Szyperski, N. (Hrsg.): Organisation, Planung, Informationssysteme. Stuttgart 1981, 177–195

Literaturverzeichnis

573

Tan, W.-G. / Cater-Steel, A. / Toleman, M.: Implementing IT Service Management: A Case Study Focussing on Critical Success Factors. In: Journal of Computer Information Systems 2/2009, 1–12 TCW GmbH München – Kennzahlen-Cockpit: http://www.tcw.de/static_pages/view/34; Abruf 29.4.2011 TCW Unternehmensberatung: Vorgehensmodell IT-Marketing. http://www.tcw.de/news/view/236; Abruf 8. Mai 2011 Teubner, A. / Feller, T.: Informationstechnologie, Governance und Compliance. In: WIRTSCHAFTSINFORMATIK 5/2008, 400–407 Teubner, A. / Klein, St.: Bestandsaufnahme aktueller deutschsprachiger Lehrbücher zum Informationsmanagement. Arbeitsbericht Nr. 86 des Instituts für Wirtschaftsinformatik der Universität Münster, März 2002 Teubner, A. / Klein, St.: Vergleichende Buchbesprechung „Informationsmanagement“. In: WIRTSCHAFTSINFORMATIK 4/2002, 285–299 The Open Group (Hrsg.): TOGAF (The Open Group Architecture Framework) Version 9 "Enterprise Edition". http://www.opengroup.org/togaf; Abruf 16. Mai 2011 Thiel, C. / Thiel, C.: Business Continuity Management für KMU. In: Datenschutz und Datensicherheit 6/2010, 404– 407 Thomas, O. / Leyking, K. / Scheid, M.: Serviceorientierte Vorgehensmodelle: Überblick, Klassifikation und Vergleich. In: Informatik-Spektrum 4/2010, 363–379 Thomas, O.: Das Referenzmodellverständnis in der Wirtschaftsinformatik. In: IWi – Veröffentlichungen des Instituts für Wirtschaftsinformatik im Deutschen Forschungszentrum für Künstliche Intelligenz 187/2006, 1–35 Thome, G. / Sollbach, W.: Grundlagen und Modelle des Information Lifecycle Management. Berlin 2007 Tippins, M. J. / Sohi, R. S.: IT Competency and Firm Performance – Is Organizational Learning a Missing Link? In: Strategic Management Journal 8/2003, 745–761 Tirmarche, A.: The New Enterprise Data Center. GUIDE SHARE EUROPE Management Summit. Brüssel 2008 Topi, H. / Lucas, W. / Babaian, T.: Identifying Usability Issues with an ERP Implementation. In: Proceedings of the 7th International Conference on Enterprise Information Systems. Miami, USA 2005, 128–133 Trigonum Consulting: Unternehmens- und IT-Strategien leben aneinander vorbei. http://www.trigonum.de/artikel; Abruf 12.11.2008 Trigonum Studie: http://www.trigonum.de/artikel; Abruf 12.01.2008 Trittmann, R. et al.: Managing Motivation bei der Softwareentwicklung – Ein Fallstudie bei der SAP. In: Frey, B. S. / Osterloh, M. (Hrsg.): Managing Motivation. 2. A., Wiesbaden 2002, 279–302 T-Systems: White Paper Cloud Computing II, August 2010 Turczyk, L. A. et al.: Eine Methode zur Wertzuweisung von Dateien in ILM. In: Bichler, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 459–470 Ulich, E.: Differentielle Arbeitsgestaltung. In: Zeitschrift für Arbeitswissenschaft 1983, 12–15 Unger, C. / Kemper, H.-G.: Organisatorische Rahmenbedingungen der Entwicklung und des Betriebs von Business Intelligence – Ergebnisse einer empirischen Studie. In: Bichler, K. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 141–153 Van Solingen, R. / Berghout, E.: The Goal/Question/Metric Method. New York 1999 Vanini, U.: Steuerung der IT-Wirtschaftlichkeit in mittelständischen Unternehmen. In: CONTROLLING 7/2008, 367–373 Vdf (Hrsg.): Berufe der Wirtschaftsinformatik in der Schweiz. 5. A., Zürich 2000 Veltri, N. F. / Saunders, C. S. / Kavan, C. B.: Information Systems Backsourcing: Correcting Problems and Responding to Opportunities. In: California Management Review 1/2008, 50–76 Versteegen, G.: Projektmanagement mit dem Rational Unified Process. Berlin et al. 2000 Vetter, M.: Aufbau betrieblicher Informationssysteme mittels pseudo-objektorientierter, konzeptioneller Datenmodellierung. 8. A., Stuttgart 1998 Vitruvius, M. P.: De Architectura Libri Decem. Zehn Bücher über Architektur. Wiesbaden 2004 Vogel, O. et al.: Software-Architektur. Grundlagen - Konzepte - Praxis. München 2005 Völcker Informatik AG: ActiveEntry, http//www.activeentry.com; Abruf 30.4.2008 von der Oelsnitz, D. / Hahmann, M.: Wissensmanagement. Strategie und Lernen in wissensbasierten Unternehmen. Stuttgart 2003 von Dobschütz, L. et al.: (Hrsg.): IV-Controlling. Wiesbaden 2000 von Dobschütz, L.: IV-Controlling. Theoretische Sicht und praktische Bedeutung. In: CONTROLLING 5/1995, 306–312 von Jouanne-Diedrich, H.: 15 Jahre Outsourcing-Forschung: Systematisierung und Lessons Learned. In: Zarnekow, R. / Brenner, W. / Grohmann, H. H. (Hrsg.): Informationsmanagement. Konzepte und Strategien für die Praxis. Heidelberg 2004, 125–133 von Krogh, G. / Nonaka, I. / Aben, M.: Making the Most of Your Company´s Knowledge: A Strategic Framework. In: Long Range Planning 4/2001, 421–439

574

Literaturverzeichnis

von Rössing, R. : Betriebliches Kontinuitätsmanagement. Bonn 2005 Voß, St. / Gutenschwager, K.: Informationsmanagement. Berlin et al. 2001 Wade, M. / Hulland, J.: The resource-based view and information systems research. In: MIS Quarterly 1/2004, 107– 142 Wagner, S. et al.: Softwarequalitätsmodelle. Praxisempfehlungen und Forschungsagenda. In: Informatik-Spektrum 1/2010, 37-44 Wall, F.: Informationsmanagement – Eine ökonomische Integration von Controlling und Wirtschaftsinformatik. München 2006 Walter, S. G. / Spitta, T.: Approaches to the Ex-ante Evaluation of Investments into Information Systems. In: WIRTSCHAFTSINFORMATIK 3/2004, 171–180 Wang, R. / Strong, D.: Beyond Accuracy: What Data Quality Means to Data Consumers. In: Journal of Management Information Systems 4/1996, 5–34 Weber, M.: Entscheidungen bei Mehrfachzielen. Wiesbaden 1983 Weber, M.: Nutzwertanalyse. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Stuttgart 1992, 1436– 1448 Wehrmann, A. / Heinrich, B. / Seifert, F.: Quantitatives IT-Portfoliomanagement. In: WIRTSCHAFTSINFORMATIK 4/2006, 234–245 Wehrmann, A. / Zimmermann, St.: Integrierte Ex-ante-Rendite-/Risikobewertung von IT-Investitionen. In: WIRTSCHAFTSINFORMATIK 4/2005, 247–257 Weill, P. / Ross, J. W.: A Matrixed Approach to Designing IT Governance. In: MIT Sloan Management Review 2/2005, 26–34 Weill, P. / Ross, J. W.: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Boston 2004 Weill, P. / Woodham, R.: Don't Just Lead, Govern: Implementing Effective IT Governance. MIT Sloan Working Paper No. 4237–02. Cambridge 2002. http://cisr.mit.edu; Abruf 01. Juni 2011 Weinbrenner, P.: Szenariotechnik. http//www.sowi-online.de/methoden/dokumente/szenariotechnik.htm; Abruf 27.5.2011 Weinhardt, C. et al.: Cloud-Computing – Eine Abgrenzung, Geschäftsmodelle und Forschungsgebiete. In: WIRTSCHAFTSINFORMATIK 5/2009, 453–462 Wenger, E. C. / Snyder, W. M.: Communities of Practice: The Organizational Frontier. In: Harvard Business Review. 1/2000, 139–145 Wieczorek, M. / Naujoks, U. / Bartlett, B. (Hrsg.): Business Continuity. Notfallplanung für Geschäftsprozesse. Berlin/Heidelberg/New York 2003 Wiener, N.: Cybernetics or Control and Communication in the Animal and the Machine. Boston 1948 Wilder, R. P.: The Continuing Revolution of Information Systems Planning. In: Strunz, H. (Hrsg.): Planung in der Datenverarbeitung. Von der DV-Planung zum Informations-Management. Berlin et al. 1985, 21–37 Willcocks, L. / Lester, St.: How do Organizations Evaluate and Control Information Systems Investments? Recent Survey Evidence. In: Avison, D. et al. (Eds.): Human, Organizational, and Social Dimensions of Information Systems Development. North-Holland et al. 1993, 15–39 Wilson, T. D.: Evolution in information behavior modeling: Wilson’s model. In: Fisher, K. E. / Erdelez, S. / McKechnie, L. E. F. (Hrsg.): Theories of information behavior. Medford/New Jersey, 2005, 31–36 Wilson, T. D.: Models in information behaviour research. In: Journal of Documentation 3/1999, 249–270 Wilson, T. D.: On user studies and information needs. In: Journal of Documentation 1/1981, 3–15 Winkler, A. / Lehnhardt, S.: Geschäftsprozessmanagement in der Lufthansa Cargo AG. In: Schmelzer, H. J. / Sesselmann, W. (Hrsg.): Geschäftsprozessmanagement in der Praxis. Kunden zufrieden stellen - Produktivität steigern - Wert erhöhen. 6. A., München 2008, 543–561 Wintergerst, A. / Welker, M.: Die Rolle der Transaktionskosten bei Outsourcingentscheidungen. In: ZfbF - Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 11/2007, 938–954 Wittmann, W.: Information. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Stuttgart 1980, 894– 904 Wixom, B. H. et al.: Continental Airlines Continues to Soar with Business Intelligence In: Information Systems Management 2/2008, 102–112 Wolle, B. / Müller, V.: Prozessorientiertes IT-Qualitätsmanagement. In: HMD - Praxis der Wirtschaftsinformatik 232/2003, 66–78 Wyssusek, B.: Geschäftsprozeßmodell, Geschäftsprozeßmodellierung. In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. A., Berlin/Heidelberg/New York 2001, 210–211 Zachmann, J. A.: A Framework for Information Systems Architecture. In: IBM Systems Journal 3/1987, 276–292 Zachmann, J. A.: Zachman Enterprise Framework 2. http://www.zachmaninternational.com; Abruf 16. Mai 2011

Literaturverzeichnis

575

Zahedi, F.: The Analytic Hierarchy Process – A Survey of the Method and its Applications. In: INTERFACES 4/1986, 96–108 Zahn, E.: Wissen und Strategie. In: Bürgel, H. D. (Hrsg.): Wissensmanagement. Berlin et al. 1998, 41–52 Zahrnt, C.: Richtiges Vorgehen bei Verträgen über IT-Leistungen. 2. A., Heidelberg 2005 Zangemeister, C. / Bomsdorf, E.: Empfindlichkeitsanalyse in der Nutzwertanalyse. In: Zeitschrift für betriebswirtschaftliche Forschung 5/1983, 375–397 Zangemeister, C.: Nutzwertanalyse in der Systemtechnik. 4. A., München 1976 Zarnekow, R. / Brenner, W. / Pilgram, U.: Integriertes Informationsmanagement. Berlin/Heidelberg 2005 Zarnekow, R. / Scheeg, J. / Brenner, W.: Untersuchung der Lebenszykluskosten von IT-Anwendungen. In: WIRTSCHAFTSINFORMATIK 3/2004, 181–187 Zarnekow, R.: Produktorientiertes Informationsmanagement. In: Zarnekow, R. / Brenner, W. / Grohmann, H. (Hrsg.): Informationsmanagement. Konzepte und Strategien für die Praxis. Heidelberg 2004, 41–56 Zeitler, N.: Die 13 "Worst Practices" der Enterprise Architecture. o.O. 18.03.2009, http://www.cio.de/873689; Abruf 18. Mai 2011 Zravy, W.: Serverkonsolidierung in Rechenzentren: Grundlagen, Konzepte und Motive von Virtualisierungstechnologien. Saarbrücken 2009

Schlagwortverzeichnis 6-W-Methode ..................................... 430

A ABGB................................................... 67 Abrechnungsmodell............................ 306 Abrechnungssystem.................... 464, 468 Abstimmung ....................................... 287 Abstraktionsprinzip .............................. 52 Abteilung............................................ 137 Abweichung ....................................... 199 Acitvity-Diagramm .................... 438, 444 Ad-hoc-Analysesystem ...................... 254 Aggregationsfunktion ......................... 373 agil...................................................... 397 agiles Vorgehensmodell ..................... 399 Agilität........................................ 107, 397 AHP.................................................... 383 AICPA................................................ 211 AIS ..................................................... 220 Aktivierungsverbot..................... 366, 387 Aktivierungswahlrecht ....................... 366 Aktivität...................................... 273, 397 Aktivitätsdiagramm .................... 438, 444 Aktualität.............................................. 82 Akzeptanz........................................... 346 Alarmplan................................... 187, 193 Alignment................................. 22, 55, 57 Allgemeines Bürgerliches Gesetzbuch . 67 Alternativstrategie .............................. 409 Altsystem............................................ 261 Amortisationsrechnung ...................... 368 Analyse................................. 91, 361, 363 Analytic Hierarchy Process ................ 382 analytische Methode........................... 369 analytisches Informationssystem........ 253 Änderbarkeit....................................... 152 Änderungsmanagement ...................... 315 Anforderung ....................................... 149 Anforderungsermittlung ..................... 424

Anforderungsprofil...................... 31, 34 f. Angebot...............................161, 168, 297 Angebotsanalyse .................161, 169, 393 Angebotsevaluierung ..........................169 angebotsorientierter Ansatz.................128 Annual Loss Expectancy.............471, 476 Annual Loss Exposure ........................471 Anonymität .........................................179 Anpassbarkeit......................................125 Anpassung...........................................108 Anpassungsqualifikation .....................243 Anpassungsstreben..............................107 Anpassungswartung ............................264 Ansatz, angebotsorientierter................128 Ansatz, nachfrageorientierter ..............128 Anwendungsarchitektur ..................43, 47 Anwendungsbetreuer ............................38 Anwendungsfalldiagramm ..................438 Anwendungsrückstau ..........................125 Anwendungssoftware..........................395 Anwendungssystem ............................261 Anwendungssystem-Administrator.....256 Anwendungssystembestand ................262 Anwendungstyp ..................................164 Application Management ....................358 Application Service Provider .......79, 161, 223, 230 Application Service Providing ...161, 223, 230 Appropriating Strategy........................292 Arbeitsteilung......................................287 Arbeitsverfassungsgesetz ......................76 Arbeitsvorbereitung ....................321, 327 Architecture Framework .......................47 Architektur ....................................43, 201 Beschreibungsfunktion......................44 Entwicklung ......................................50 Funktionen ........................................44 Gestaltungsfunktion ..........................45 Kommunikationsfunktion .................44

578

Metamodelle..................................... 47 serviceorientierte .....................231, 441 Teilarchitekturen .............................. 46 Zweck............................................... 44 Architektur integrierter Informationssysteme ...43, 48, 435, 438 Architekturbegriff ................................ 45 Architekturbeschreibung ...................... 45 Architekturentwicklung...................... 406 Architekturführung............................. 406 Architekturkommunikation ................ 406 Architekturmanagement ..................... 406 Architekturprinzipien ..................... 43, 51 Abstraktionsprinzip .......................... 52 Flexibilität ........................................ 51 Information-Hiding-Prinzip ............. 52 Inkrementalitätsprinzip..................... 52 Kohäsion .......................................... 52 Komplexitätsreduktion ..................... 51 Kopplung.......................................... 52 Modularitätsprinzip .......................... 52 Prinzip des Entwurfs für Veränderungen ............................. 52 Rückverfolgbarkeitsprinzip .............. 52 Selbstdokumentationsprinzip ........... 52 Separation-of-Concerns-Prinzip....... 52 Architekturvertretung ......................... 406 Argumentebilanz ................................ 229 ARIS .....................................48, 435, 438 ASP .........................79, 87, 161, 223, 230 Assessment..................................387, 491 Asset Management ......................170, 314 asymmetrische Informationsverteilung 86 atypischer Vertrag .............................. 302 Audit ...................................483, 486, 502 Qualität....................................483, 486 Sicherheit ....................................... 481 Audit Information System.................. 220 Aufbauorganisation ............................ 287 Aufgaben gut strukturierte .............................. 426 schlecht strukturierte ...................... 426 Aufgabenanalyse .137, 139, 237, 241, 427 Aufgabenebene administrative................................... 25

Schlagwortverzeichnis

Aufgabenentwicklung.........................263 Aufgabenprofil......................................31 Aufgabenrelevanz .................................82 Aufgabensynthese............... 137, 139, 241 Aufgabenträger .............................17, 237 Auftrag........................................ 297, 459 Auftraggeber .......................................297 Auftragnehmer....................................297 Auftragsbindung .................................216 Auftragsrechnung ...............................461 Gestaltungsziele ..............................461 Ausbildungsanalyse ............................242 Ausbildungsplan .................................242 Ausfallmanagement ............................330 Ausgangskontrollsystem.....................324 Ausgliederung.....................................223 Auslagerung........................................223 Ausmaß der Zielerreichung ................373 Ausschreibung .................... 161, 168, 501 Angebotsanalyse .............................169 Angebotsevaluierung ......................169 Fragenkatalog .................................169 Austauschvertrag ................................298 Ausweichrechenzentrum..... 187, 194, 328 Eigenvorsorge .................................194 Fremdvorsorge................................194 Kapazität .........................................194 Notkonfiguration.............................195 Verträge ..........................................196 Vertragsgestaltung ..........................196 Wiederanlaufzeit.............................194 Autarkiedenken...................................147 Authentifizieren ..................................321 Authentizität .......................................179 Automatisierung, unzureichende ........549 Automatisierungswerkzeug.................328

B B2B.....................................................161 Backsourcing .............................. 223, 233 Backup-Rechenzentrum......................328 Backup-System ...................................326 Balanced IT-Decision Card ................357

Schlagwortverzeichnis

Balanced Scorecard ... 276, 349, 354, 435, 442, 445 Baldrige Award .................................. 491 Basel II ........................................... 55, 56 Basis-Sicherheitscheck ....................... 473 Basistechnologie................................. 163 Basisvorgehensmodell........................ 398 Batch-Betrieb ..................................... 327 BDSG ................................................... 67 Bearbeitungsfehler.............................. 549 Bearbeitungszeit ................................. 273 Bedarf ................................................. 423 Bedarfsmanagement ........................... 312 Bedarfspotenzial......................... 107, 128 Bedrohung .................................. 175, 178 Bedürfnis ............................................ 423 Belüftung............................................ 325 Benchmark ......................................... 502 Benchmarking ............................ 391, 442 Benchmarking-Objekt ........................ 442 Benchmarking-Partner........................ 442 Benutzbarkeit ..................................... 152 Benutzerakzeptanz.............................. 424 Benutzerforschung...................... 423, 426 Benutzerfreundlichkeit ....................... 152 Benutzerschulung ............................... 246 Benutzerservice .......................... 146, 495 Benutzerzufriedenheit ........................ 346 Benutzungsschnittstelle ........................ 79 Berichtsgenerator................................ 330 Berichtssystem.................................... 254 Berufsbild ............................................. 33 Beschaffungsrichtlinie........................ 314 Besichtigungsanalyse ................. 337, 343 Best Practice ............................... 442, 470 Bestandsmanagement ......... 125, 127, 170 Bestätigungsgrad .................................. 82 Best-of-Breed-Strategie...................... 121 Betriebsmittel ..................... 321, 459, 461 Betriebsvereinbarung............................ 76 Betriebsverfassungsgesetz.................... 76 Betriebsvergleich................................ 349 Betroffene............................................. 70 Bewertung .................................. 374, 386 Beziehungszahl................................... 349

579

BGB ......................................................67 BI ................................................249, 253 BITKOM.......................................67, 161 Blog.............................................447, 453 Bootstrap .............................................489 Bottom-up-Ansatz.......................103, 376 BPaaS..........................................321, 331 BPEL...........................................435, 439 BPML..........................................435, 438 BPMN .........................................435, 438 BPR.............................273, 275, 279, 435 Branchenstrukturmodell......................118 Brandfrüherkennungsmelder...............325 British Standard 15000........................318 Brooks'sches Gesetz............................237 BSC.............................349, 354, 435, 445 BSI ......................................................175 Budgetierung...............................312, 461 Bundesamt für Sicherheit in der Informationstechnik ........................175 Bundesdatenschutzgesetz......................67 Bürgerliches Gesetzbuch.......................67 Business Continuity Management.......188 Business Domain ................................130 Business Intelligence..249, 253, 357, 447, 451 Serviceebenen .................................505 Business Process Execution Language.................................435, 439 Business Process Modeling Language.................................435, 438 Business Process Modeling Notation.435, 438 Business Process Outsourcing.............226 Business Process Reengineering 273, 275, 277, 279, 281, 435 Business Service .................................310 Business to Business ...........................161 Business-Intelligence-Spezialist .........257 Business-IT-Alignment....22, 55, 57, 116, 123, 145 Business-Process-as-a-Service............321

580

C CA ...................................................... 211 Capability Maturity Model..158, 483, 493 Capability Maturity Model for Software ......................................... 489 Capability Maturity Model Integration .......................444, 483, 489 Capture-Replay-Tool.......................... 493 CASE ................................................. 435 CA-System ......................................... 214 CC ...................................................... 385 CEO.........................................31, 36, 137 CFO................................................ 31, 36 Change Management.......................... 279 Change Request...................309, 315, 317 Chargeback-Mechanismus ................. 470 Checkliste............................211, 219, 221 Chief Executive Officer ................31, 137 Chief Financial Officer ........................ 31 Chief Information Officer .... 31 f., 39, 41, 137, 223 Chief Knowledge Officer .....31, 285, 292, 519 CICA .................................................. 211 CIO........................................31, 137, 223 CISG .................................................. 297 CISO .................................................... 31 CKO ......................................31, 285, 519 Cloud Computing ...20, 77, 195, 230, 231, 306, 330 CMDB................................................ 309 CMM...........................................158, 483 CMMI .................................444, 483, 489 Repräsentationsformen................... 489 Coaching .............................237, 447, 452 CobiT ........................29, 55, 59, 176, 495 Collaboration Tool ............................. 165 Common Criteria for Information Technology Security Evaluation ... 175, 385 Common Warehouse Metamodel....... 255 Communities of Practice ....285, 293, 294, 295

Schlagwortverzeichnis

Compliance .....................................55, 58 Compliance Management ...............68, 77 Compliance-Anforderung ...................139 Compliance-Erfüllung ..........................76 Computer Aided Software Engineering.....................................435 Computerversicherung................ 386, 478 Configuration Item...................... 309, 314 Configuration Management Database.......................... 309, 314, 316 Consistency Accellerator ....................419 Container-Rechenzentrum .......... 187, 195 Content-Management-System..... 453, 509 Continual Service Improvement .........317 Continuous Auditing................... 211, 213 Continuous Auditing System ..............214 Control Objectives for Information and Related Technology .... 55, 59, 176, 495 Aufgaben...........................................59 Aufgabenbereiche .............................59 control objectives..............................61 Qualitätsmerkmale für Information ..61 Reifegradmodell ...............................62 Control Process...................................318 Controller............................................210 Controlling............................ 27, 144, 199 Aufgaben.........................................202 Dezentralisierung ............................206 Innovationsaufgabe.........................205 Koordinationsaufgabe.....................204 Mehrfachunterstellung ....................206 Objekte............................................201 Organisation....................................205 organisatorische Einordnung ..........206 Planungs- und Kontrollaufgabe ......202 Weisungskompetenz .......................205 Ziele setzen .....................................203 Zielerreichung messen ....................203 Zweck .............................................200 Controlling und Revision....................208 Controlling-Konzept ...........................104 Controlling-Objekt..............................354 Controlling-Stelle ...............................205 Cookie......................................... 297, 307 Corporate Governance .......................55 f.

Schlagwortverzeichnis

Corporate Information Security.......... 140 Corporate Information Security Officer 31 Cost-Center......................................... 322 CRM ................................................... 349 CUNO................................................. 305 Customer Relationship Management ........................... 231, 349

D DAS.................................................... 321 Data Cube........................................... 254 Data Dictionary .......................... 249, 255 Data Mining........................ 254, 447, 451 Data Warehouse ................. 249, 451, 533 Data-Warehouse-System ............ 424, 454 Einführung...................................... 258 Daten ...................................... 1, 249, 286 Klassifizierung................................ 268 Nearline-Ebene............................... 268 Offline-Ebene ................................. 268 Online-Ebene.................................. 268 Produktionsfaktor ........................... 250 Qualitätsmerkmale.......................... 256 Verlagerung .................................... 269 wirtschaftliches Gut........................ 250 Daten, strukturierte............................. 249 Daten, unstrukturierte ......................... 249 Datenadministrator ............................. 256 Datenanalyse .............................. 250, 252 Datenarchitektur ..................... 43, 47, 250 Datenbank........................................... 253 Datenbankadministrator ..................... 256 Datenbankmanagementsystem ........... 249 Datenbankmodell................................ 251 Datenbankreorganisation.................... 535 Datenbanksystem........................ 249, 454 Datenbankverwaltungssystem ............ 249 Datenbeschaffung............................... 251 Datenbestand ...................................... 267 Datendiebstahl .................................... 178 Datenintegrität .................................... 214 Datenkatalogsystem-Administrator .... 257 Datenkomprimierung.......................... 251 Datenmanagement ...................... 249, 269

581

Aufgaben.........................................250 Aufgabenträger................................256 Ziele ................................................250 Zweck..............................................250 Datenmigration ...................................252 Datenmodell.................................... 249 f. Datenmodellierung..............................250 Datennetz ............................................325 Datenoase........................................67, 70 Datenobjekt .........................................535 datenorientierte Prüfung......................214 Datenqualität .......................249, 255, 259 Datenrecherche ...................................254 Daten-Reengineering ..........................252 Datenschutz.........................................176 Datenschutzgesetz...........................67, 69 Datenschutzrecht...................................69 Datensicherung ...................................252 Integrität..........................................252 Verfügbarkeit ..................................252 Vertraulichkeit ................................252 Datenspeicher......................................328 Datensystem........................................249 Denial of Service...................................67 Deskriptor ...........................................409 Dezentralisierung ................141, 147, 206 Diagnoseaufwand..................................98 Diagnosemodell ....................................98 Dialektik..............................................409 Dienstleister ..........................................35 Dienstleistung .....................................495 Dienstleistungsqualität .... 495 f., 503, 526 Dienstvertrag.........................................71 differenzierender Verrechnungspreis ..464 Differenzierung ...................................119 Digital Business ..................................113 Digital Restrictions Management..........72 Digital Rights Management ..........72, 297 Digital-Rights-Management-System...306 DIIR ....................................................211 Direct Attached Storage ......................321 Disaster-Recovery-Strategie ...............120 Dokumentation............................217, 330 Revision ..........................................217

582

Dokumentenmanagement................... 511 Fallstudie........................................ 509 Dokumenten-Management-System .... 455 Definitionsphase............................. 515 Going-Live-Phase .......................... 518 Installationsphase ........................... 515 Koordinationsphase........................ 515 DOS...................................................... 67 Drei-Ebenen-Modell .......................... 238 DRM .................................................. 297 DRMS ................................................ 306 Druckdienst ........................................ 326 DSG...................................................... 67 Dublin Core........................................ 255 Durchdringung ................................... 108 Durchdringungsstreben ...................... 107 Durchlaufzeit...................................... 273

E EAM............................................211, 220 Earned-Value-Analyse ................349, 355 eBusiness-Strategie .....................120, 122 E-Commerce-Gesetz ............................ 75 E-Commerce-Recht.............................. 75 EDI....................................................... 67 eEPK ...........................................435, 438 Effektivität ......................................... 107 Effizienz ......................................106, 152 EFQM .........................................237, 483 Eigenschaftsanalyse ............................. 97 Einflussverhaltensweisen ..................... 39 Einkaufsbedingungen......................... 305 Einsatzstrategie ...........................113, 120 Electronic Data Interchange ................. 67 Elektronischer Datenaustausch ............ 74 Element, sicherheitsrelevantes ........... 178 E-Mail Archivierung .................................. 271 Embedded Audit Module ............211, 220 Empfindlichkeitsanalyse .................... 381 Empowerment .................................... 247 ENISA................................................ 471 Enterprise Application Integration ..... 441 Enterprise Architecture Management... 53

Schlagwortverzeichnis

Enterprise Collaborative Portal...........453 Enterprise Expertise Portal .................453 Enterprise Information Portal .............453 Enterprise Knowledge Portal ..............453 Enterprise Rights Management System ............................................297 Enterprise Search ................................254 Enterprise-Content-ManagementSystem ............................................509 Einführungsstrategie .......................510 Enterprise-Resource-PlanningSystem .................................... 274, 440 Entity-Relationship-Notation..............250 Entscheidertypen...................................40 Entscheidungsbefugnis .........................58 Entscheidungskompetenz....................112 Entscheidungsrechnung ......................460 Entscheidungsregel ..................... 373, 379 Entscheidungsunterstützungssystem...395 Entwicklung evolutionäre ....................................402 inkrementelle ..................................402 Entwicklungsdokumentation...............400 Entwicklungskosten, Aktivierung.......366 Entwicklungsprojekt .............................45 Entwicklungsrückstau.........................125 Entwurfsmuster...............................17, 29 EPK............................. 435, 438, 444, 445 Ereignis...............................................211 Ereignis, gefährdendes........................178 Ereignis, sicherheitsrelevantes............178 Ereignisaufzeichnung..........................211 ereignisgesteuerte Prozesskette..435, 438, 444 f. Erfolgsermittlung ................................461 Erfolgsfaktor .....97, 164, 209, 246, 337 f., 356 kritischer .........................................337 Schlüsselbereich Kommunikation ..340 Schlüsselbereich Personal...............340 Schlüsselbereich Positionierung .....341 Schlüsselbereich Service.................339 strategischer ......................................25 Erfolgsfaktor, kritischer ......................429

Schlagwortverzeichnis

Erfolgsfaktorenanalyse ......... 97, 337, 521 Akzeptanz....................................... 346 Beurteilung ..................................... 346 Erfolgsfaktor................................... 338 Erhebungstechnik ........................... 342 Fallstudie ........................................ 521 Gesamterfolg .................................. 111 Leistung.......................................... 522 Messmethode.................................. 342 Messmodell .................................... 521 Priorität........................................... 522 Prozess der Qualitätsbestimmung... 524 Vorgehensweise.............................. 343 Weiterentwicklung ......................... 347 Zweck ............................................. 338 Erfolgskontrolle.................................. 181 Erfolgspotenzial................ 17, 19, 22, 104 Erklärungsmodell ........................ 17 f., 81 ERMS ......................................... 297, 306 ERP-System ....................................... 274 Datenqualität .................................. 257 Ersatzbeschaffungsplan ...................... 194 Erschütterungsmelder ......................... 325 erweiterte ereignisgesteuerte Prozesskette ............................ 435, 438 ETL .................................................... 254 European Foundation for Quality Management ........................... 237, 483 Excellence Award........................... 491 Model ............................................. 491 European Network and Information Security Agency ............................. 471 European Quality Award.................... 491 EVA.................................................... 349 Evaluierung ................ 113, 161, 385, 519 Arbeitsplan ..................................... 387 Messmethoden................................ 391 Messung ......................................... 393 Prozessorganisation ........................ 393 Vorgehensweise.............................. 387 Evaluierungskriterium 130, 138, 385, 388 Evaluierungsmethoden ....................... 385 Zweck ............................................. 386 Evaluierungsobjekt..................... 385, 388 Evaluierungsorientierung ................... 135

583

Evaluierungsstrategie ..........................120 Evaluierungsverfahren ........................172 Evaluierungsziel..........................385, 388 evolutionäre Entwicklung ...................402 Expanding Strategy .............................292 Experiment..........................................391 Expertenverzeichnis ............................448 Ex-post-Evaluierung ...........170, 172, 394 Extensible Markup Language .............435 Externalisierung ..................................450 Extremalkriterium ...............................385 Extreme Programming ................397, 404 Praktiken .........................................405 Prinzipien ........................................404 Werte...............................................404 Extrem-Szenario .................................409 Exzellenzmodell..................................491

F Face Threat............................................87 Fachausschuss IT im IDW ..................211 Fachkompetenz ...................................239 Factory-Modell ...................................462 Fähigkeitsgrade ...................................491 Fähigkeitsmanagement........................237 FAIT....................................................211 Fallstudie.............................................392 Dokumentenmanagement................509 Erfolgsfaktorenanalyse....................521 Geschäftsprozessmanagement.........545 Lebenszyklusmanagement ..............533 FAMA.................................................211 FAMA-Gutachten ...............................211 FAMA-PC...........................................220 FASMI ........................................249, 254 Fast Analysis of Shared Multidimensional Information 249, 254 Fehler ..................................................483 Fehlerbaumanalyse..............................392 Fehlerfolgekosten................................153 Finanzmanagement .............................312 Flatrates...............................................306 Flexibilität .............51, 107, 112, 133, 280 flexible Planung ..................................133

584

Fluchtplan........................................... 187 formale Verifikation........................... 487 Formalziel .......................21, 23, 103, 105 Forschungsatmosphäre ....................... 244 Fragebogenmethode ....................337, 342 Framework for Business Competence.. 39 Framework for Information Systems Architecture...................................... 47 freie Datenrecherche .......................... 254 Führung .............................................. 237 Führungsaufgabe .................................. 31 Führungskräfteplanung ...................... 243 Führungsprozess................................. 276 Führungsverantwortung ..................... 200 Full-IT-Outsourcing ........................... 226 Funktionalität ..................................... 152 funktionsorientierte Testverfahren ..... 488 Funktionsorientierung ........................ 274 Funktionssicherheit ............................ 217

G Ganzheitliche InformationssystemArchitektur ....................................... 49 Ganzheitlichkeit ............................... 6, 20 Gatekeeping ................................... 79, 85 GDPdU................................................. 67 Gebäudearchitektur ............................ 323 Gefahr .........................................175, 178 gefährdendes Ereignis ........................ 178 Gefährdungsbaumanalyse .................. 392 Gefahrenquelle ................................... 178 Gemeinkosten-Wertanalyse ............... 364 Genauigkeit .......................................... 82 Gesamterfolg.................................96, 342 Geschäftsarchitektur....................... 43, 46 Geschäftsmodell............................17, 120 Geschäftsprozess ....5, 216, 273, 275, 332, 468 Geschäftsprozessmanagement.....273, 310 Aufgaben........................................ 276 Fallstudie........................................ 545 Methoden ....................................... 435 Projektleiter .................................... 281 Rollen ............................................. 281

Schlagwortverzeichnis

Zweck .............................................274 Geschäftsvorfall..................................216 Gesetz zur Kontrolle und Transparenz im Unternehmensbereich ...............55 f. Gewinnvergleichsrechnung.................368 Gleichgewicht, strategisches.................94 Gliederungszahl ..................................349 Goal/Question/Metric-Ansatz .............355 GoBS ..................................................211 GOM...................................................251 Governance ...........................................55 Einflussfaktoren ................................65 Hilfsmittel .........................................65 Nutzen...............................................65 Ziele ..................................................65 GPM............................................ 273, 435 GQM-Ansatz............................... 355, 357 GQM-Graph........................................356 GQM-Plan ..........................................356 Green IT...................................... 111, 325 Grenzkosten ........................................459 Groupware ..........................................453 Grundsatz.................................... 137, 211 der Durchsichtigkeit........................218 der Übersichtlichkeit.......................217 der Vollständigkeit..........................218 der Zeitgerechtigkeit .......................218 Grundsätze der Ordnungsmäßigkeit ..212, 215 Buchführung ...................................216 Datenschutz.....................................216 Datenverarbeitung...........................216 Dokumentation ...............................217 Modellierung.............................52, 251 Speicherbuchführung ......................216 Grundschutz.............................471 f., 479 Grundschutzmaßnahme ...................471 f. Grundschutz-Tool ...............................478 Grundschutzvorgehensweise...............478 GS-Tool ..............................................478

H Haftung .................................................67 Half-Life Curve ..................................455

Schlagwortverzeichnis

Handelsgesetzbuch ....................... 67, 385 Handlungsspielraum...... 17, 24, 103, 104, 165, 213 Handlungstheorie der Wahrnehmung ... 83 Hauptfachausschuss des IDW ............ 211 heißes Rechenzentrum........................ 195 Helpdesk............................................. 495 Heuristik ............................................. 370 HFA.................................................... 211 HGB ............................................. 67, 385 Hierarchical Storage Management .... 252, 266 Hilfskostenstelle ................................. 462 Hinterlegungsstelle............................... 74 holistische Wirtschaftlichkeitsanalyse 371 House-of-Quality................................ 484 Humankapital ................................. 31, 37 Humanvermögen ............................ 31, 37 Hybrid Cloud...................................... 331 Hyper Cube ........................................ 254

I I/S Executive ........................................ 39 IaaS..................................................... 321 IDEA .................................................. 220 Identifikation ...................................... 321 IFRS ................................................... 199 IKS ..................................................... 211 ILM .................................... 261, 266, 533 IM-Ansatz............................................... 4 Führungsansatz................................... 5 ganzheitliches IM ............................... 5 Information Resource Management ... 4 Personal Information Management .... 4 Vier-Säulen-Ansatz ............................ 5 IM-Ansatz, leitungszentrierter................ 4 IM-Ansatz, produktorientierter............... 7 IM-Ansatz, prozessorientierter ............... 5 IM-Konzept Entwickeln........................................ 28 IM-Modell ............................................ 18 Implementierungsphase........................ 84 Indexzahl ............................................ 349 Individualziel...................................... 113

585

Informant Bias ....................................530 Information .............................1, 285, 286 Information Engineering ...................4, 28 Information Lifecycle Management...252, 261, 266, 270, 271, 533 Klassifizierungswert........................534 Verbindungsgrad.............538, 540, 543 Zugriffswahrscheinlichkeit ....538, 540, 543 Zugriffswert ........................ 538 f., 543 Information Retrieval..254, 447, 452, 454 Information Security Forum................471 Information Systems Audit and Control Association...........................55 Information Technology Infrastructure Library ................29, 67, 309, 317, 495 Information Technology Security Evaluation Criteria ..................175, 385 Information Technology Security Evaluation Facility ..........................385 Information Technology Security Evaluation Methodology.................385 informationelle Selbstbestimmung........69 Information-Hiding-Prinzip ..................52 Informations- und Kommunikationsdienste-Gesetz .......74 Informationsangebot ...............79, 82, 423 Informationsangebot, Art und Menge .432 Informationsangebot, Qualität.............432 Informationsart....................................424 Informationsaufnahme ..........................79 Informationsbedarf........81, 250, 423, 425 Führungskraft..................................429 objektiver ........................................423 subjektiver.......................................423 Informationsbedarfsanalyse 250, 423, 448 deduktive Methoden........................426 Funktionsdiagramm ........................428 Geschäftsprozessmodell..................428 induktive Methoden ........................426 Ist-Architektur.................................429 Kommunikationsdiagramm.............428 Methoden ........................................426 Methoden der empirischen Sozialforschung...........................426

586

Methodenkombination ................... 433 Organigramm ................................. 428 Stellenbeschreibung ....................... 428 Verfahrensanweisung ..................... 428 Ziel-Architektur.............................. 429 Zweck............................................. 424 Informationsbedürfnis ....79, 81, 254, 423, 425 Informationsbeschaffung, Kosten ...... 431 Informationsdefizit..................79, 81, 423 Informationsfunktion.....2, 17, 19, 86, 139 strategische Rolle ............................. 92 Informationsinfrastruktur ....3, 17, 19, 139 Informationslogistik ............................. 65 Informationsmanagement....................... 2 Definition ........................................... 2 Denkweisen ...................................... 20 Einordnung in Wissenschaftsdisziplinen ............... 8 Institutionalisierung........................ 146 Managementaufgabe ........................ 24 Managementebenen.......................... 24 Methodik .......................................... 20 Referenzmodelle .............................. 29 Stellenbilder ..................................... 31 Ziele ................................................. 21 Informationsmanagement-Ansätze......... 4 Informationsmanager .................. 32 f., 35 Anforderungsprofil........................ 34 f. Stellenbild ........................................ 34 Informationsmenge ............................ 424 Informationsmerkmal........................... 82 Informationsnachfrage .82, 250, 252, 423, 425 Informationsorganisation ..................... 82 Informationsproduktion...................... 250 Informationsqualität ........................... 424 Informationsquelle ............................... 82 Informationsrecht ................................. 67 Handlungsanalyse ............................ 69 Wirkung ........................................... 68 Informationssicherheit.................140, 176 Informationssuche ................................ 87 Informationssystemanalyse ................ 429 Informationssystemarchitektur....... 43, 47

Schlagwortverzeichnis

Informationssystemplan......................125 Informationstheorie.................................1 Informationsüberflutung .................79, 82 Informationsüberlastung .....................423 Informationsverhalten... 79, 423, 426, 429 Bedeutung .........................................80 Formen..............................................80 interpersonelles ........................79 f., 85 interpersonelles, Beispiele ................86 intrapersonelles ............................ 79 ff. intrapersonelles, Beispiele ................83 Informationsverteilung..........................86 Informationswirtschaft..........................10 Informationswissenschaft .......................9 Infrastructure Service..........................311 Infrastructure-as-a-Service..................321 Infrastruktur ........................................322 personelle..........................................37 Infrastrukturanalyse ..............................96 Infrastrukturarchitektur.........................47 Infrastrukturentwicklung ....................127 Infrastrukturentwicklung, strategische 128 Infrastrukturmanagement....................321 Aufgaben.........................................323 Berichtswesen .................................330 Cloud Computing............................332 Location Management ....................323 RZ-Ausstattung...............................324 RZ-Betrieb ......................................326 Zweck .............................................322 Infrastrukturplanung ...........................165 Inkrementalitätsprinzip .........................52 inkrementell ........................................397 inkrementelle Entwicklung .................402 Innovation ..................... 98, 161, 205, 287 Innovationsdenken ................................21 Innovationsfähigkeit .. 116, 125, 126, 166, 280 Innovationsmanagement ............. 167, 173 Innovationspotenzial............. 22, 116, 162 Innovationsstrategie ............................120 Innovator...............................................35 Insourcing ...........................................223 Inspektion ...........................................486 Institut für Interne Revision ................211

Schlagwortverzeichnis

Instruktionspflicht ................................ 72 integriertes Informationsmanagement .... 7 Integrität ..................................... 179, 252 Interaktionsbedürfnis.......................... 245 Interdependenzanalyse ............... 337, 341 Internalisierung................................... 450 International Accounting Standards ... 367 International Financial Reporting Standards ........................................ 199 Internes Kontrollsystem.............. 211, 214 Internetstrategie .................................. 120 Intransparenz ...................................... 549 Investitionsschutz ....................... 266, 328 Investment Center............................... 137 ISACA.................................................. 55 IS-Architektur..................................... 267 ISF ...................................................... 471 ISO 27001 .......................................... 183 ISO 9000 ............................................ 150 ISO/IEC 20000 ................................... 318 ISO/IEC 38500 ..................................... 58 ISO/IEC 9126 ..................................... 151 Ist-Architektur ...................................... 45 Istzustand.............................................. 91 IT Contract Library ............................ 297 IT Governance Institute........................ 55 IT Infrastructure Library..................... 176 IT turnover.......................................... 246 IT-Abteilung............... 137, 147, 171, 302 IT-Alignment........................................ 55 IT-Architekt........................................ 123 IT-Asset-Management........................ 301 IT-Business-Alignment ........................ 22 ITCL ................................................... 297 IT-Controller ................................ 37, 206 IT-Controlling .................................... 140 IT-Diagnose.................................. 98, 347 IT-Dienstleister................................... 309 IT-Dienstleistung................................ 309 Iteration .............................................. 397 IT-Funktion im Vorstand...................... 40 ITGI...................................................... 55 IT-Governance.............. 55, 176, 310, 497 Aufgaben .......................................... 56 Zweck ............................................... 56

587

IT-Grundschutz ...................................183 IT-Grundschutz, Modellierung ...........472 IT-Grundschutzkataloge.......... 471 f., 478 IT-Grundschutzzertifizierung..............474 ITIL.................29, 67, 176, 309, 317, 495 IT-Infrastruktur .......................................3 IT-Koordinator......................................38 IT-Kosten ....................................310, 469 IT-Leitbild...................................111, 242 IT-Management...................................247 IT-Manager .....................................31, 35 IT-Marketing...............................242, 247 IT-Organisation...................................213 IT-Performance ...................................209 IT-Prozess ...........................................398 IT-Referent............................................38 IT-Revisor .............................................37 ITSEC .........................................175, 385 ITSEF..................................................385 ITSEM ................................................385 IT-Service ...................................309, 310 IT-Servicekatalog................................500 IT-Servicemanagement .........56, 176, 225 IT-Servicemanagementsystem ....309, 497 IT-Sicherheit .......................................176 IT-Sicherheitsevaluation .....................395 itSMF ..................................................309 IT-Strategie .........................123, 167, 424 Entwicklung ....................................116 Gegenstand......................................114 Wirkung ..........................................115 Zweck..............................................114 IT-Strukturanalyse ......................472, 478 IT-System............................................213 IT-Verbund .........................................175 IT-Vertragsmuster...............................304 IT-Wert ...............................................100 IT-Ziel, strategisches...................103, 114

J Jahresabschlussprüfung.......................219 Job Rotation ................................447, 452 Jukebox .......................................261, 267

588

K Kaizen ................................................ 157 Kalkulation......................................... 312 kaltes Rechenzentrum ........................ 195 Kapazität ............................................ 321 Kapazitätsmanagement ...............313, 329 kardinale Risikobewertung................. 476 kardinale Skala ................................... 378 Katastrophe ........................................ 187 Katastrophenmanagement .................. 313 Kaufvertrag ........................................ 303 Kennzahl .............................349, 361, 366 Kennzahlenanalyse.......................... 349 f. Kennzahlen-Cockpit....................357, 359 Kennzahlensystem.......................349, 424 Anforderungen ............................... 351 Referenzmodelle ............................ 354 Struktur........................................... 352 Vier-Ebenen-Modell ...................... 350 Werkzeuge ..................................... 356 Zweck............................................. 350 Kennzahlensystematik........................ 350 Kernprozess........................................ 276 Key Performance Indicator .........103, 201 KNA................................................... 130 Knappheitspreis.................................. 459 Kodifizierung ..............................285, 291 Kodifizierungsstrategie .......243, 291, 454 Kognition ............................................. 79 Kohäsion .............................................. 52 Kommunikation...................................... 2 Kommunikationsanalyse .................... 428 Kommunikationsmodell ....................... 85 Kommunikationszufriedenheit ........... 245 Kompetenz ............................31, 137, 287 Kompetenzzentrum .....................285, 293 Komplexität.......................................... 51 Komponentenanalyse ........................... 97 Konfiguration ..............................309, 397 Konfigurationsmanagement ........314, 400 Konformitätskosten ............................ 153 Konsequenz primäre ........................................... 179 sekundäre ....................................... 179

Schlagwortverzeichnis

Konsequenzanalyse.............................416 Konsistenzmatrix ................................415 KonTraG....................................55 f., 113 Kontrolle ..................................... 199, 212 Kontrollierbarkeit ....................... 211, 217 Kontrollrechnung ................................367 Kontrollsystem....................................214 Konzentrationsstrategie ......................119 Kooperation ........................................237 Kooperationsprinzip............................153 Koordination137, 139, 199, 204, 237, 244 Koordinator.........................................143 Kopplung ..............................................52 Korrektheitsbeweis .............................487 Korrekturwartung ...............................264 Kosten......................................361 f., 459 Kosten- und Leistungsrechnung .........459 Auftragsrechnung............................461 Kostenumlage .................................462 Methodensystematik .......................461 Verrechnungsmethoden .......... 462, 466 Verrechnungspreis ..........................463 Verrechnungspreise ........................465 Werkzeuge ......................................468 Zweck .............................................460 Kostenanalyse .....................................204 Kostenart............. 361, 364, 459, 461, 467 Kostenartenstruktur.............................467 Kostendenken .......................................21 Kostenführerschaft..............................118 Kostenmanagement.............................459 Kostenmanagementsystem..................470 Kostenmodell......................................306 Kostenniveau ......................................364 Kosten-Nutzen-Analyse...... 130, 361, 381 Kosten-Nutzen-Beziehung..................366 Kostenplanung ....................................485 Kostensituation ...................................362 Kostenstelle................................. 459, 467 Kostenstellenstruktur ..........................467 Kostenstruktur..................... 361, 364, 459 Kostenträger........................................459 Kostentransparenz...............................469 Kostentreiber.......................................469 Kostenumlage ............................. 459, 462

Schlagwortverzeichnis

Kostenvergleichsrechnung ................. 368 Kostenverlaufsanalyse........................ 365 Kostenverteilungsprinzip.................... 462 Kostenverteilungsschlüssel......... 459, 462 KPI ............................................. 103, 107 Kreativitätstechnik...... 125, 129, 419, 451 Krisenstab................................... 187, 191 Kriterienertrag .................................... 385 Kriteriengewicht................. 373, 378, 385 Kriteriengewichtung ........................... 389 Kriterium .................................... 373, 385 Kritikalität ............................................ 95 kritischer Erfolgsfaktor....................... 337 kritischer Wettbewerbsfaktor ............... 17 Kühlung.............................................. 325 Kunde ................................................. 149 Kundenanforderung............................ 484 Kundenorientierung.................... 153, 496 Künstliche Intelligenz...................... 285 f. Kurzprüfung ............................... 211, 215 Kuvertierdienst ................................... 326

L Lastenheft ..................................... 73, 168 Lebenszyklus ...... 161, 163, 261, 361, 362 Lebenszykluskosten.................... 269, 362 Lebenszyklusmanagement.................. 261 Fallstudie ........................................ 533 Veränderungsbedarf ....................... 262 Zweck ............................................. 262 Lebenszyklusmodell ... 261, 263, 265, 361 Lebenszyklustheorie........................... 262 Legal Engineering .............................. 300 Leistung.......103, 337, 342, 361, 389, 459 Leistungsart ........................................ 464 Leistungsdifferenz .............................. 337 Leistungsmanagement ................ 106, 361 Leistungsmessung ................................ 57 Leistungsportfolio .............................. 466 Leistungspotenzial.................... 17, 19, 22 Leistungssituation............................... 362 Leistungsverrechnung ........................ 386 Leitstand ..................................... 321, 329 Leitstrategie .125, 133, 409, 410, 412, 417

589

Leitungshandeln ......................................2 Lenkungsausschuss . 130, 137, 145 f., 205 Lenkungspreis .....................................459 Leveraging Strategy ............................292 Lieferantenmanagement......................314 Liegezeit..............................................549 Limitierungskriterium .........................385 Linienmanagement..............................171 Lizenz..................................................297 Lizenzmanagement .....................301, 307 Lizenzvertrag ......................................303 Löschanlage ........................................325 Lücke, strategische................................95

M Machbarkeitsstudie .....................130, 400 Mainframe...........................................326 Mainframe-Management.....................326 Mainframe-System..............................326 Malcolm Baldrige National Quality Award..............................................491 Malware ..............................................471 Management............................................2 Management by Objectives.................138 Management Concerns..........................30 Management des Servicekatalogs .......312 Managementebenen ..............................24 administrative....................................25 operative............................................26 strategische........................................25 Managementmethode ..........................173 Managementsystem.............................497 Mangel ..................................................67 Mängelhaftung ......................................73 Mantelvereinbarung ........................ 297 f. Maßnahmenplanung, strategische .......125 Mean Time Between Failures .............103 Mean Time To Failure ........................103 Medienbruch .......................................548 Meldeplan ...........................................187 Mensch-ComputerInformationsverhalten ................... 79 f. mentales Modell..................................450 Mentoring....................................447, 452

590

Messen ........................................199, 385 Messgröße ...................199, 349, 385, 390 Messgrößentransformation................. 199 Messinstrument .................................. 199 Messkompetenz.................................. 159 Messmethode ..............................199, 203 Messmodell ........................................ 521 Messobjekt ......................................... 199 Messpunkt .......................................... 199 Messziel ............................................. 199 Meta Object Facility........................... 255 Metadaten....................249, 251, 255, 534 Metadatenmanagement ...................... 255 Metadatenmodell................................ 255 Metamodell ........................................ 255 Metaplan-Technik .............................. 419 Metaprojektmanagement.................... 206 Methode ............................................... 26 Methode der kritischen Erfolgsfaktoren............................... 429 Methoden Definition von Wissenszielen......... 448 der Qualitätsplanung ...................... 484 der Qualitätsprüfung....................... 485 der Qualitätsverbesserung .............. 488 des Geschäftsprozessmanagements 435 des Qualitätsmanagements ............. 483 Wissensbewahrung......................... 454 Wissensbewertung.......................... 455 Wissensentwicklung....................... 450 Wissensidentifikation ..................... 448 Wissensmanagement ...................... 447 Wissensverteilung .......................... 452 Metrik..........107, 199, 201, 349, 359, 385 Microsoft Operations Framework ...... 309 Middleware ........................................ 441 Mikrofiche.......................................... 326 Mikroform.......................................... 326 Mitbestimmungspflicht ........................ 77 Mitbestimmungsrecht........................... 76 mobiles Rechenzentrum ..................... 195 Modell ...........................................18, 373 mentales ......................................... 450 Modell CIO .......................................... 35 Modellierungswerkzeug ..................... 273

Schlagwortverzeichnis

Modellvertrag .....................................304 Modularitätsprinzip...............................52 MOF............................................ 255, 309 monumentales Vorgehensmodell........398 Motivation .................................. 237, 244 Motivationsfaktor ...............................246 MTBF .................................................103 MTTF..................................................103 multiattributives Messverfahren .........521 Mustervertrag......................................304

N Nachfrage............................................423 nachfrageorientierter Ansatz...............128 Nachhaltigkeit.................................7, 127 Nachhaltigkeitsdenken..........................21 Nachhaltigkeitsstrategie......................120 NAS ....................................................321 NAS-Speichersysteme ........................328 Near Shore Outsourcing......................228 NEMP .................................................321 NEMP-Fall..........................................324 Network Attached Storage..................321 Network Gatekeeping Theory...............85 Netzgüteklasse ....................................327 Netzmanagement ................................327 nominale Skala....................................377 Nonkonformitätskosten.......................153 Normstrategie ..................... 113, 117, 230 Notfall......................................187 f., 313 Notfallarten .........................................189 Notfallbetrieb......................................193 Notfallmanagement..................187 f., 313 Einsatzplan...................... 187, 190, 193 Einsatzplanung................................190 Vorgehensweise ..............................189 Vorsorgemaßnahme ........................190 Vorsorgeplan...................................190 Vorsorgeplanung.............................190 Zweck .............................................188 Notfallorganisation ..................187 f., 193 Notfallplan .................................. 187, 190 Gliederung ......................................191 Inhalt...............................................191

Schlagwortverzeichnis

Teilpläne......................................... 191 Notfallplanung.................................... 189 Notfall-Test ........................................ 196 Notfallursache .................................... 188 Not-invented-here-Syndrom............... 293 Notstromgenerator.............................. 325 Nucelar Electromagnetic Pulse........... 321 Nutzen ............. 101, 103, 361 f., 373, 459 Nutzendenken....................................... 21 Nutzenfaktor....................................... 365 Nutzenpreis................................. 459, 465 Nutzenstruktur .................................... 365 Nutzungsrecht....................... 67, 297, 303 Nutzwert .................................. 361, 373 f. Nutzwertanalyse ............. 87, 98, 117, 373 Ergebnis.......................................... 380 Logik .............................................. 375 Varianten ........................................ 381 Vorgehensweise.............................. 376 Zielerträge ...................................... 377 Zielwerte......................................... 377 Zweck ............................................. 374 Nutzwertmodell .................................. 376 Annahmen ...................................... 382

O OASIS ................................................ 435 Object Management Group 249, 435, 438 objektiver Informationsbedarf ............ 423 Objektsicherheit.................................. 324 Obligationenrecht ................................. 67 OCG ................................................... 297 OECD ................................................... 55 Off Shore Outsourcing ....................... 228 öffentliches Recht................................. 69 OGC ................................................... 309 Öko-IT................................................ 111 OLA.................................................... 495 OLAP ................................. 249, 254, 447 OLTP.................................................. 249 OMG .................................. 249, 435, 438 On Shore Outsourcing ........................ 228 On Site Outsourcing ........................... 227

591

Online Analytical Processing.....249, 254, 447, 451 Online Transaction Processing............249 Online-Betrieb.....................................327 Ontologie ............................................161 Operating.............................................329 Operation.............................................273 operational...........................................103 Operational Level Agreement .....495, 500 operationelles Risiko.............................55 Operations Research ...........................361 operative Datenbank ...........................253 Operator ......................................321, 329 OR.................................................67, 361 ordinale Risikobewertung ...................477 ordinale Skala......................................377 Ordnungsmäßigkeit.....................208, 211 Grundsätze ......................................212 Ordnungsmäßigkeitskriterien..............215 Organisation for Economic Co-operation and Development ........55 Organisationales Lernen ................. 285 f. Organisationsanalyse ..........................428 Organisationsziel.........................113, 238 Organization for the Advancement of Structured Information Standards ...435 Österreichische Computergesellschaft 297 Outsourcing.....83, 86, 223, 277, 496, 522 Entscheidungsunterstützung............229 Kernkompetenz ...............................224 Koordination ...................................225 Organisation....................................225 organisatorische Gestaltung ............229 Prozess ............................................202 rechtliche Gestaltung.......................228 Reichweite.......................................225 Ressourcen ......................................225 Risikoteilung ...................................225 Skaleneffekt ....................................224 Spezialisierungsvorteil ....................224 Strategie ..........................................224 verbleibende Aufgaben ...................226 Vertragsgestaltung ..........................228 Wachstumspotenzial .......................225 Wirtschaftlichkeit............................224

592

Zweck............................................. 224 Outsourcing, partielles ....................... 225 Outsourcing, selektives ...................... 225 Outsourcing, totales............................ 226 Outsourcing, transitionales................. 226 Outsourcing-Beziehung...................... 227 Outsourcing-Geber............................. 223 Outsourcing-Geber, Standort ............. 227 Outsourcing-Grad............................... 223 Outsourcing-Nehmer.......................... 223 Outtasking ...................................223, 225

P Paarvergleich...................................... 378 PaaS.............................................321, 331 Parallelverarbeitung ........................... 105 Partizipation ........................237, 242, 418 Partnerschaft......................................... 28 Patentrecht............................................ 72 Penetrationstest ...........................471, 481 Perfektionswartung ............................ 265 Performance Management.................. 329 Periodenvergleich............................... 349 Personal.............................................. 238 Personalbedarf.................................... 243 Personalbedarfsermittlung.................. 240 Personalbeschaffung .......................... 243 Personalbeschaffungsplan .................. 243 Personalbestand.................................. 240 Personalbestandsanalyse .................... 240 Personaleinsatz................................... 244 Personalentwicklung ...................241, 263 Personalfreisetzung ............................ 244 Personalführung ................................. 244 Personalisierung ....................76, 285, 291 Personalisierungsstrategie ..243, 291, 448, 454 Personalmanagement.......................... 237 Aufgaben........................................ 239 Zweck............................................. 238 Personalqualifikation Fähigkeit......................................... 245 Personalveränderung .......................... 263 Personalvertretungsgesetz .................... 76

Schlagwortverzeichnis

personelle Infrastruktur.................37, 238 personenbezogene Daten ......................70 Pflichtenheft........................................168 Phase...................................................397 Phasenmodell......................................397 PHG ......................................................67 Phishing ................................................77 Piraterierate.........................................307 Plan-Do-Check-Act ............................149 Plan-Do-Check-Act-Zyklus .....157, 444 f. Planspiel..............................................247 Planung, flexible .................................133 Planungsrechnung...............................367 Platform-as-a-Service .........................321 PMBOK ...................................... 397, 406 Portal...................................................453 Portfolio ................................................91 Portfolioanalyse ..................................207 Portfoliomanagement.. 127, 131, 135, 369 Portfoliotechnik ..................................436 Portierbarkeit ......................................152 Post-Mortem-Analyse................. 400, 451 Potenzialfaktor................................91, 99 Präferenz .............................................373 Präferenzordnung................ 373, 385, 389 Preisbeurteilung ..................................460 Preisdifferenz......................................546 Preisgestaltung....................................312 Preiskalkulation ..................................460 Preismodell .........................................306 primäre Konsequenz ...........................179 Prince2 ........................................ 397, 406 Principle of Least Effort ........... 79, 82, 84 Prinzip......................................... 137, 211 Priorität ....................................... 337, 342 privacy ................................................176 Privatautonomie ....................................73 Private Cloud ......................................331 Privatrecht.............................................68 Probing Strategy .................................292 Problemmanagement ..........................317 Process Integration Officer .................283 Produkt................................................149 Produktaktivierung...................... 297, 307 Produktarchitektur ..............................403

Schlagwortverzeichnis

Produkthaftungsgesetz.................... 67, 72 Produkthaftungsrecht............................ 72 Produktionsfaktor ................................... 4 Produktivität ............................... 108, 247 Produktivitätsparadoxon..... 100, 109, 173 Produktivitätsstreben .......................... 106 Produktmanager............................ 38, 466 Produktqualität ................................... 151 Produktrealisierung ............................ 155 Produktzertifizierung.......................... 184 Profildiagramm..................................... 91 Profit Center ............... 137, 141, 146, 322 Prognose ............................. 361, 363, 409 Prognosemethode ............................... 411 Project Management Body of Knowledge ............................. 397, 406 PRojects IN Controlled Environments 397 Projekt ................................................ 386 Projektcontrolling............................... 206 Projektgruppe ..................................... 244 Projektidee, evaluieren ....................... 130 Projektionsmethode ............................ 383 Projektleitung ....................................... 32 Projektmanagement .............. 86, 398, 400 Projektmanagement, Vorgehensmodell............................ 406 Projektmanager..................................... 38 Projektmeilenstein .............................. 218 Projektorganisation............ 31 f., 138, 238 Projektplan ......................................... 386 Projektplanung.................... 206, 361, 363 Projektportfolio .................................. 145 Projektportfolio, strategisches ............ 125 proprietäres System ............................ 167 Prozess................................ 149, 273, 397 Prozessanalyse.................... 276, 437, 545 Prozessautomatisierung .............. 279, 440 Prozessberater..................................... 281 Prozesscontroller ................................ 281 Prozessdenken ...................................... 21 Prozesseigner.............................. 273, 281 Prozesselement ................................... 273 Prozessentwurf ........................... 277, 550 Prozessevaluierung ............. 279, 442, 552 Prozessidentifizierung ................ 276, 436

593

Prozessimplementierung .............279, 440 Prozesskette.........................................370 Prozesskosten......................................280 Prozesskostenrechnung ............................. ................................230, 280, 435, 467 Prozesskostensatz................................467 Prozessmanager...................................281 Prozessmessung ..................................280 Prozessmitarbeiter...............................281 Prozessmodell .....................................398 Kommunikationsmittel....................278 Leistungsvereinbarungen ................278 Mess- und Steuerungssystem ..........278 Schulung .........................................278 Softwareeinführung.........................278 Wertschöpfungstransparenz ............278 Prozessmodellierung ....... 277 f., 437, 545 Modellierungssprache .....................437 Modellierungswerkzeug..................439 Referenzmodell ........................... 439 f. Simulationswerkzeug ......................440 Visualisierungswerkzeug ................439 Prozessorientierung........ 105, 153, 273 ff. Prozessqualität ....................................273 Prozessteam.........................................281 Prozessverantwortlicher ......................281 Prozessverantwortung .........................278 Prozessverbesserung ...........280, 444, 550 Prüffrage .............................................219 Prüfkriterium.......................................218 Prüfliste ...............................................211 Prüfung.................................... 211 f., 483 Prüfungsfragebogen ............................211 Prüfungslehre ......................................221 Prüfungstheorie ...................................221 Public Cloud........................................331 Pull-Prinzip .........................................452 Push-Prinzip........................................452

Q QFD ....................................................483 Qualifikation .......................171, 237, 241 Qualifikationsprofil...............................41 Qualifizierungsmaßnahme ..................171

594

Qualität............................................... 150 Qualitätsanforderung.......................... 149 Qualitätsdenken.................................... 21 Qualitätskosten................................... 153 Qualitätskriterien für Prozesse ........... 152 Qualitätslenkung .........................149, 156 Qualitätsmanagement.....58, 72, 149, 240, 398, 400 Aufgaben........................................ 156 Dokumentation............................... 158 Methoden ....................................... 483 Objekte ........................................... 151 Sichten............................................ 151 Verantwortung der Leitung ............ 154 Zweck............................................. 150 Qualitätsmanagement, ganzheitliches 152 Qualitätsmanagement, produktorientiertes ......................... 151 Qualitätsmanagement, prozessorientiertes.......................... 152 Qualitätsmanagementhandbuch ......... 158 Qualitätsmanagementmaßnahme ....... 149 analytische...................................... 151 konstruktive.................................... 151 Qualitätsmanagementsystem......154, 274, 276, 497 Analyse........................................... 155 kontinuierliche Verbesserung......... 155 Messung ......................................... 155 Verbesserung.................................. 155 Qualitätsmangel.................................. 150 Qualitätsmaß ...................................... 150 Qualitätsmerkmal ............................ 149 f. Information....................................... 61 Qualitätsmodell ............................... 149 f. Qualitätsniveau............................309, 495 Qualitätsorientierung.......................... 153 Qualitätsplanung .................149, 156, 484 Qualitätspolitik............................149, 156 Qualitätsprüfung..........................156, 485 dynamische..................................... 485 statische.......................................... 485 Qualitätssicherung.......................149, 157 Qualitätsverbesserung .149, 157, 388, 488 Qualitätsziel .................... 149 f., 156, 398

Schlagwortverzeichnis

Qualitätszirkel............................. 293, 488 Quality Function Deployment..483 f., 492 Querschnittsdisziplin ............................68 Querschnittsfunktion, besondere.............3 Querschnittsprozess ............................468

R RACI.....................................................55 RACI-Diagramm ..................................59 RAID .................................. 261, 321, 328 RAID-System .....................................267 Rational Unified Process ............ 397, 403 Rationalisierung ..............................17, 98 Rationalisierungspotenzial....................22 Rationalitätsdefizit ..............................208 Rationalitätsprinzip.............................153 Rationalitätssicherung.........................208 RDF ....................................................255 Realisierungsstrategie .........................113 Rechenzentrum ................................321 f. Architektur......................................323 Standort...........................................323 Rechenzentrum, heißes .......................195 Rechenzentrum, kaltes ........................195 Rechenzentrum, mobiles.....................195 Rechenzentrum, warmes .....................195 Rechenzentrumsbetrieb.......................194 Rechenzentrumsmanagement .............323 Virtualisierung ................................329 Rechtssubjekt........................................69 Redundant Array of Independent Disks ...............................................321 Redundant Array of Inexpensive Disks .......................................261, 267 Redundanz .................................. 321, 549 Reengineering ...............................71, 261 Re-Evaluierung ...................................385 Referenzdisziplin ..................................12 Referenzmodell.6, 17, 23, 28 f., 209, 273, 370, 374, 399 Regel...................................................212 Regelkreis ...........................................370 regelorientierte Prüfung ......................214 Regressionstest ................... 483, 488, 493

Schlagwortverzeichnis

Reifegrad ............................................ 489 Reifegradmodell ............. 59, 62, 158, 489 Relationship Process........................... 319 Release ............................................... 397 Release Process .................................. 318 Rentabilität ......................................... 109 Rentabilitätsmaximierung........... 111, 371 Rentabilitätsrechnung ......................... 368 Requirements Management ................ 171 Resolution Process ............................. 319 Resource Description Framework ...... 255 Resources-Conduct-PerformanceHypothese....................................... 120 Responsible, Accountable, Consulted and Informed .................................... 55 Ressourcenmanagement ............... 57, 155 Ressourcenprofil......................... 464, 469 Restrisiko............................................ 471 Restrisikoanalyse................................ 478 Restrukturierung................................. 266 Rettungsplan....................................... 187 Return On Capital Employed ..... 165, 246 Return on Investment ......................... 109 Reverse Engineering............. 71, 261, 266 Review................................ 483, 486, 502 Revision.............................................. 211 datenorientierte Prüfung ................. 214 Dokumentation ............................... 217 Initiierung ....................................... 215 Kurzprüfung ................................... 215 Prüffragen....................................... 219 Prüfkriterien ................................... 218 Prüfungsarten.................................. 214 Prüfungsmethoden.......................... 219 regelorientierte Prüfung.................. 214 Systemprüfung................................ 214 Tiefenprüfung................................. 215 Vorgehensweise.............................. 213 Werkzeuge...................................... 220 Zweck ............................................. 212 Revision und Controlling ................... 208 Revision, externe ................................ 213 Revision, interne................................. 213 Revision, Projekt begleitende............. 218 Revisionsleitfaden .............................. 221

595

Revisionsplan......................................215 Risiko ..................125, 130, 297, 298, 471 Risiko, operationelles............................55 Risikoanalyse ......................471, 474, 479 Risikobewertung .................................476 kardinale..........................................476 ordinale ...........................................477 Risikoerkennung .................................475 Risikomanagement................................57 Ritualdynamik.....................................394 ROCE..................................................165 ROI......................................................109 Rolle......................................................31 Rollout-Manager ...................................38 Rückverfolgbarkeitsprinzip...................52 RUP.............................................397, 403 RZ .......................................................321

S SaaS ............................223, 230, 321, 331 Sachmittelzuordnung ..........................140 Sachziel ...........................21, 22, 103, 105 safety...................................................176 SAN ....................................................321 SAN-Speichersysteme ........................328 Sarbanes-Oxley Act ............ 55 f., 64, 512 Schaden ...............................................179 Schlagkraft, strategische ............. 91, 94 f. Schlüsselbereich..................................337 Schlüsselfaktor ............................337, 347 Schlüsselfaktorenanalyse ....................347 schlüsselfertiges System .....................161 Schlüsseltechnologie...........................163 Schnittstelle.........................................209 Schrittmachertechnologie....................163 Schulung .............................................237 Schutzbedarf .......................................471 Schutzbedarfsfeststellung....................472 Schutzprofil.........................................396 Schwäche ..............................................91 Schwachstelle................91, 175, 179, 471 SCM ....................................................435 SCOR ..........................................435, 439 Scrum ..........................................397, 407

596

security ............................................... 176 SEI...................................................... 483 sekundäre Konsequenz....................... 179 Selbstdokumentationsprinzip ............... 52 Selbstkompetenz ................................ 239 Separation-of-Concerns-Prinzip........... 52 sequenziell.......................................... 397 Serverbetrieb ...................................... 327 Servermanagement............................. 326 Serversystem ...................................... 326 Service Delivery Process.................... 318 Service Design ................................... 317 Service Desk ...............................309, 316 Service Knowledge Management System............................................ 316 Service Level Agreement223, 229 f., 309, 495 Service Level Requirement .........495, 501 Service Level Specification................ 495 Service Operation............................... 317 Service Strategy ................................. 317 Service Transition .............................. 317 Serviceebene ...............................321, 495 Serviceebenenmanagement ........312, 314, 495 f., 498 Serviceebenen-Managementprozess .. 501 Serviceebenen-Vereinbarung .......84, 267, 305, 312, 495, 541 Bestandteile .................................... 497 Entwickeln ..................................... 500 Kontext........................................... 500 Leistungsumfang ............................ 498 Nutzenpotenzial.............................. 502 Strukturformen ............................... 499 Zweck............................................. 496 Servicegrad..................................495, 498 Servicekatalog .............................309, 312 Servicekomposition............................ 442 Servicekultur ...............................495, 501 Servicemanagement ........................... 309 Rahmenwerke................................. 317 Teilaufgaben................................... 311 Zweck............................................. 310 serviceorientierte Architektur......231, 441 Serviceportfolio-Management............ 311

Schlagwortverzeichnis

Servicequalität ....................................498 Servicewert-Vereinbarung ..................496 SERVQUAL ............................... 337, 348 Sicherheit .................................108, 175 f. Ebenenmodell .................................177 Kausalmodell ..................................178 logische Ebene ................................177 organisatorisch-soziale Ebene.........178 physische Ebene..............................177 wirtschaftlich-rechtliche Ebene ......178 Sicherheitsanalyse...............................473 Sicherheitsausschuss...........................147 Sicherheitsbeauftragter .......................182 Sicherheitsgefährdung ........................175 Sicherheitskonzept ............. 175, 177, 181, 471 f., 479 Werkzeuge ......................................478 Zweck .............................................472 Sicherheitskriterien ............. 175, 184, 488 Sicherheitsleitlinie ...................175, 181 f. Sicherheitsmanagement58, 175, 176, 314, 497 Audit ...............................................182 Evaluierung.....................................184 Wirtschaftlichkeit............................183 Zertifizierung ..................................184 Zweck .............................................176 Sicherheitsmanagement-System 175, 180, 314, 472 Geltungsbereich ..............................180 Managementprinzipien ...................182 Mitarbeiter ......................................183 Rahmenbedingungen ......................181 Ressourcen......................................183 Sicherheitsmanagement-Team............182 Sicherheitsniveau ................ 175, 183, 471 Sicherheitsorganisation.......................181 Sicherheitsprozess...............................180 sicherheitsrelevantes Element.............178 sicherheitsrelevantes Ereignis.............178 Sicherheitsrisiko .................................313 Sicherheitsstrategie ..120, 175, 181 f., 472 Sicherheitsstreben ...............................106 Sicherheitsverletzung..........................184

Schlagwortverzeichnis

Sicherheitsziel .................................... 179 Anonymität..................................... 179 Authentizität ................................... 179 Integrität ......................................... 179 Verbindlichkeit............................... 180 Verfügbarkeit.................................. 179 Vertraulichkeit................................ 179 Sicherungsmaßnahme. 175, 179, 395, 478 Auswahl.......................................... 472 Konsolidierung ............................... 474 SigG...................................................... 67 Signaturgesetz ...................................... 67 Simulation .......................................... 369 Simulationsmodell.............................. 371 Simulationstechnik ............................. 476 Single-Source-Strategie...................... 121 Situationsanalyse .................................. 91 Situationsanalyse, strategische ............. 91 Skala kardinale ......................................... 378 nominale ......................................... 377 ordinale........................................... 377 Skalenniveau ...................................... 377 Skill Management............................... 247 Skontoverlust.............................. 549, 554 SLA ......................... 223, 229 f., 309, 495 SLR .................................................... 495 SLS..................................................... 495 Snowflake-Schema ............................. 251 SOA............................................ 435, 441 Software Engineering Institute ........... 483 Software Process Improvement .......... 149 Software Process Improvement and Capability dEtermination................ 489 Software Reengineering ..................... 266 Softwareaktivierung ........................... 307 Softwarearchitektur ................ 43, 47, 402 Software-as-a-Service ..... 223, 230 f., 321 Softwarebewertung............................. 387 Softwareentwicklung, Vorgehensmodell............................ 400 Softwarehinterlegung ........................... 74 Software-Miete................................... 230 Software-on-Demand ................. 223, 230 Software-Outsourcing ........................ 230

597

Softwarepiraterie.................................307 Software-Rollout.................................315 Softwareschutzrecht ..............................70 Soll/Ist-Vergleich ........................212, 349 Sollzustand............................................91 Solvency II ........................................ 55 f. Source-Make-Deliver-Prinzip .................7 Sourcing ..............................................223 SOX ............................................ 55 f., 64 Sozialkompetenz .................239, 242, 246 Speichermanagement ..........................328 Speichermedium .................................267 Speichersystem ...................................326 Spezifikation .......................................483 SPICE..................................................489 Spider Contract ...................................305 Spiralmodell........................................401 Spitzenkennzahl ..........................349, 352 SQL.............................................249, 253 Stab .....................................................137 Stabsstelle ......................................... 31 f. Stammdaten.........................................259 Stammdatenmanagement ....................259 Standard of Good Practice for Information Security .......................481 Stärke ....................................................91 Star-Schema ........................................251 Stelle .............................................31, 137 Stellenbeschreibung ....................237, 241 Stellenbesetzung .................................140 Stellenbild .............................................32 Stellenbildung .............................140, 240 Steuerung ............................................199 Steuerungsgremium ............................143 Stichprobe ...................................337, 344 Storage Area Network.........................321 Störereignis .........................................409 Störereignisanalyse .............................416 Störung........................................187, 309 Störungsmanagement ..........................316 Strategie ......................................113, 409 Strategieansatz ....................................113 Strategiecharakter................................114 Strategieentwicklung113, 122 f., 311, 424 Strategieinhalt .....................................121

598

Strategielücke................................95, 100 Strategieobjekt ................................... 114 Strategiestruktur ................................. 115 Strategietyp ........................................ 113 strategische Infrastrukturentwicklung 128 strategische IT-Ziele........................... 112 strategische Lücke........................... 125 f. strategische Maßnahmenplanung Ergebnis ......................................... 126 Flexibilität ...................................... 133 flexible ........................................... 134 Vorgehensweise ............................. 128 Zweck............................................. 126 strategische Schlagkraft .............. 91, 94 f. strategische Situationsanalyse Vorgehensweise ......................... 95, 99 Zweck............................................... 92 strategische Systementwicklung ........ 127 strategische Überdehnung .................. 101 strategische Zielplanung Vorgehensweise ............................. 110 Zweck............................................. 104 strategischer IT-Plan ....................... 125 f. strategischer Technologieeinsatzplan. 125 strategisches Gleichgewicht ................. 94 strategisches IT-Ziel....................103, 114 strategisches Ungleichgewicht ............. 94 Stromnetz ........................................... 325 Structure-Conduct-PerformanceHypothese....................................... 118 Structured Query Language ........249, 253 Struktureinheit.............................137, 322 strukturierte Daten.......................249, 253 Strukturkonzept ...........................143, 146 Strukturmanagement .......................... 137 Aufgaben........................................ 139 Gestaltungsprinzipien..................... 141 Zweck............................................. 138 strukturorientierte Testverfahren........ 488 subjektiver Informationsbedarf .......... 423 summarischer Verrechnungspreis ...... 463 Supply Chain Management ................ 435 Supply-Chain-Operations-ReferenceModell .....................................435, 439 SWOT-Analyse .................................. 207

Schlagwortverzeichnis

Systemarchitektur ...............................404 Systemdekomposition.........................324 Systemdenken .......................................20 Systemdynamik...................................417 Systemeinführung ...............................263 Systementwicklung..................... 127, 165 Systementwicklung, strategische ........127 Systemgrid .................. 131, 409, 414, 416 Systemkomposition.............................324 Systemkosten ......................................266 Systemnutzung......................................26 abnehmende ....................................264 stagnierende ....................................264 zunehmende ....................................263 Systemorientierung .............................153 Systemprüfung.................................214 f. Systemtheorie ..................................409 f. Szenario ...........................................409 f. Szenarioanalyse ..................................475 Szenario-Archetyp ...................... 409, 412 Szenario-Interpretation .......................415 Szenariomethode.................................410 Szenario-Team....................................418 Szenariotechnik.. 113, 117, 133, 190, 196, 409, 475 Alternativenbündelung....................415 Aufgabenanalyse.............................413 Einflussanalyse ...............................414 Konsequenzanalyse.........................416 Konsistenzmatrix ............................415 Leitstrategie ....................................417 Merkmale........................................411 Präventivmaßnahme........................417 Schwächen ......................................419 Stärken ............................................419 Störereignisanalyse .........................416 Systemgrid .............................. 414, 416 Szenario-Interpretation ...................415 Szenario-Team................................418 Szenario-Transfer............................417 Trendprojektion ..............................415 Vernetzungsmatrix.................. 414, 416 Vorgehensweise ..............................413 Wirkungsanalyse.............................416 Zweck .............................................410

Schlagwortverzeichnis

Szenario-Transfer ............................... 417 Szenario-Trichter........................ 409, 412

T tacit knowledge................... 285, 287, 450 Tailoring ............................................. 397 Tätigkeit ............................................. 273 TCO............................................ 362, 372 Technik......................................... 26, 162 technische Infrastrukturarchitektur. 43, 47 Technologie........................................ 162 Technologie, neue .............................. 263 Technologieanalyse .............................. 98 Technologieart.................................... 161 Technologiebedarf...................... 165, 168 Technologiebestand............................ 170 Technologiediffusion.......................... 171 Technologieeinsatz..................... 170, 172 Technologieeinsatzentscheidung167, 173, 388 Technologieeinsatzplan, strategischer 125 Technologieentwicklung ......... 163 f., 262 Technologielücke ............................ 261 f. Technologiemanagement............ 161, 172 Aufgaben ........................................ 163 Aufgabenträger............................... 171 Zweck ............................................. 162 technologischer Korridor............ 161, 166 Technology Domain ........................... 131 Teilarchitektur ...................................... 46 Teilnutzen........................................... 373 Teilstrategie ................................ 113, 120 Telekommunikationsgesetz .................. 75 Telekommunikationsrecht .................... 74 Telemediengesetz ................................. 75 Testdaten ............................................ 483 Testdatenkombination ................ 483, 488 Testen ................................. 483, 488, 493 Testfall........................................ 483, 488 Testmethode ....................................... 391 Testobjekt ........................................... 483 Testverfahren.............................. 483, 488 funktionsorientierte ........................ 488 strukturorientierte ........................... 488

599

Text Mining ........................254, 447, 452 The Open Group Architecture Framework ................................43, 406 Tiefenprüfung .....................................215 TOGAF .........................................43, 406 Top-down-Ansatz................103, 203, 376 Total Cost of Ownership .....................362 Total Quality Management 149, 152, 281, 430 Totalerhebung .............................337, 344 Totalitätsprinzip ..................................153 TQM....................................................152 Transaktionskosten..............................223 Transaktionskostentheorie ....................83 Transparenz...................58, 217, 394, 418 Transparenzverantwortung..................200 Trendprojektion...................................415 Trend-Szenario....................................409

U Überdehnung, strategische ..................101 Überprüfbarkeit.....................................82 Übertragbarkeit ...................................152 Überwachung ......................................199 UGB ......................................................67 UML....................................397, 435, 438 Aktivitätsdiagramm.........................438 Anwendungsfalldiagramm ..............438 Umweltanalyse......................................98 Umweltschutz .......................................30 Umweltstrategie ..................................120 Underpinning Contract........................500 Ungleichgewicht, strategisches .............94 Unified Messaging System .................309 Unified Modeling Language ......397, 403, 435, 438 UN-Kaufrechtsübereinkommen ..........305 Unsicherheit ........................................176 unstrukturierte Daten...................249, 254 unterbrechungsfreie Stromversorgung.....................321, 325 Unternehmensarchitektur ................43, 46 Unternehmensdatenmodelle................251 Unternehmensforschung .....................361

600

Unternehmensgesetzbuch..................... 67 Unternehmenskultur....126, 285, 287, 293 Unternehmensportal ........................... 453 Unternehmensstrategie ............ 113 f., 288 Unternehmenstypologie .................... 91 f. Unternehmensziel........................110, 346 Unterstützungsprozess........................ 276 unzureichende Automatisierung......... 549 URG ..................................................... 67 Urheberrecht................................... 67, 71 Urheberrechtsgesetz ............................. 67 UrhG .................................................... 67 Ursache-Wirkungs-Beziehungen ..18, 354 Use-Case-Diagramm .......................... 438 User-Help-Desk...........................424, 495 USV.................................................... 321

V Val IT ............................................. 55, 62 Investitionsmanagement................... 64 Portfoliomanagement ....................... 63 Prinzipien ......................................... 62 Steuerung der Wirtschaftlichkeit...... 63 Validierung..........................397, 401, 485 Validität.............................................. 349 Vektor-Nutzwertanalyse .................... 383 Veränderungsmanagement ................. 400 Veränderungspotenzial....................... 162 Verantwortungsbereich ........................ 58 Verbindlichkeit................................... 180 Verbrauchsabrechnung....................... 306 Vereinzelungsschleusensystem .......... 324 Verfahren ........................................... 161 Verfahrensdokumentation ...........211, 221 Verfügbarkeit ..............179, 252, 321, 386 Verfügbarkeitsmanagement ........313, 328 Verifikation, formale.......................... 487 Verifizierung .......................397, 401, 485 Vermögenswertmethoden................... 368 Vernetzungsmatrix ......................414, 416 Verrechnungspreis...............459, 463, 465 differenzierender ............................ 464 Lenkungsziel .................................. 465 Motivationsfunktion ....................... 465

Schlagwortverzeichnis

summarischer..................................463 Version................................................397 Versions- und Bereitstellungsmanagement ............315 Verteilung ...........................................137 Vertrag .............................................297 f. atypischer........................................302 Vertragsänderung................................300 Vertragsarchivierung ..........................300 Vertragsart ..........................................302 Vertragsarten.......................................303 Vertragsbestand ...............................297 f. Vertragsgestaltung ..............................299 Vertragsgliederung..............................303 Vertragsinhalt .....................................303 Vertragskopplung .................................73 Vertragsmanagement ..........................297 Aufgaben.........................................299 Checkliste .......................................301 Institutionalisierung ........................302 Werkzeuge ......................................305 Zweck .............................................298 Vertragspflege.....................................300 Vertragsrecht........................70, 73, 297 f. Vertragstyp .........................................302 Vertragsumfang ..................................307 Vertragszweck ....................................298 Vertraulichkeit ............................ 179, 252 Videoüberwachung ...............................77 Virtualisierung ............................ 329, 332 V-Modell ............................................401 V-Modell XT ...................... 397, 403, 407 Vorgehensmodell . 30, 262, 297, 300, 386, 397 Architekturmanagement..................406 Aufgabentypen im...........................400 Basismodell.....................................398 Entwicklung....................................399 Entwicklungs- und Unterstützungsaufgaben..............400 Kategorisierung...............................398 Managementaufgaben.....................400 Merkmale........................................398 Projektmanagement ........................406 Risiko..............................................402

Schlagwortverzeichnis

Softwareentwicklung...................... 400 Zweck ............................................. 398 Vorgehensmodell, agiles .................... 399 Vorgehensmodell, leichtgewichtiges.. 399 Vorgehensmodell, monumentales ...... 398 Vorsorgeplan .............................. 187, 192

W Wahrscheinlichkeit............................... 82 Walkthrough....................................... 486 Warenzeichenrecht ............................... 72 warmes Rechenzentrum...................... 195 Wartbarkeit................................. 152, 261 Wartezeit ............................................ 549 Wartung.............................................. 261 Wartungsmaßnahme ........................... 264 Wasserfallmodell................................ 401 Web 2.0 ...................................... 447, 457 Web Service ............................... 231, 435 Werkstattatmosphäre .......................... 244 Werkvertrag.................................. 71, 303 Werkzeug ........................................... 220 Wertanalyse ........................................ 364 Wertbeitrag......................... 126, 209, 371 Wertbeitrag der IT ................................ 25 Wertkettendiagramm .................. 438, 445 Wertschöpfung ..................................... 57 Wertsynthese ...................................... 379 Wettbewerbsanalyse ..................... 95, 100 Wettbewerbsbedingung ...................... 287 Wettbewerbsfaktor ................. 91, 95, 337 Wettbewerbsfaktor, kritischer ........ 17, 25 Wettbewerbsstrategie ................. 113, 117 Differenzierung .............................. 119 Konzentration ................................. 119 Kostenführerschaft ......................... 118 Wettbewerbsvorteil .............. 91, 112, 134 Wettbewerbswirksamkeit ................... 126 WfMC......................................... 435, 439 Wiederanlaufplan ............... 187, 190, 194 Wiederanlaufplanung ......................... 190 Wiki.................................... 447, 452, 453 Wirksamkeit ........... 23, 94, 109, 115, 130 Wirksamkeitsanalyse.................. 161, 166

601

Wirksamkeitsstreben...........................107 Wirkungsanalyse.................................416 Wirtschaftlichkeit.....23, 57, 94, 109, 115, 130, 204, 358, 362 Wirtschaftlichkeitsanalyse ..161, 166, 361 Anforderungen ................................363 holistisch .........................................371 Vorgehensweise ..............................363 Zweck..............................................362 Wirtschaftlichkeitsdenken.....................21 Wirtschaftlichkeitskontrolle................460 Wirtschaftlichkeitsmodell ...........363, 370 Wirtschaftlichkeitsrechnung ...............367 Ermittlungsmodelle.........................368 Modelltypen ....................................367 quantitative Entscheidungsmodelle.369 Wirtschaftlichkeitsstreben...................106 Wirtschaftsprüfer ........................212, 215 Wissen................................. 1, 254, 285 f. Wissen, explizites................................286 Wissen, implizites ...............................286 Wissensanalyst ....................................292 Wissensbasis ...............................285, 287 Wissensbedarf .....................................448 Wissensbestand ...........................285, 287 Wissensbewahrung......................290, 454 Wissensbewertung ......................290, 455 deduktiv summarische Methoden ...455 induktiv analytische Methoden .......455 Wissensbilanz .....................................456 Wissensbroker.....................................292 Wissenselement...................................285 Wissensentwicklung............290, 447, 450 Wissenserwerb ............................289, 447 Wissensidentifikation..................289, 448 Wissenskarte ...............................447, 449 Wissenslücke.......................285, 289, 449 Wissensmanagement.............84, 285, 316 Aufgaben.........................................288 Aufgabenträger................................292 Bausteine.........................................288 Einflussfaktoren ..............................287 Handlungsfelder ..............................287 Methoden ........................................447 Strategien ........................................291

602

Zweck............................................. 286 Wissensmanagementstrategie......285, 293 Wissensmanager................................. 292 Wissensnutzung.................................. 290 Wissensobjekt .............................285, 287 Wissensträger ..................................... 285 Wissenstransfer .................................. 290 Wissenstransformation ....................... 447 Externalisierung ............................. 450 Internalisierung .............................. 450 Kombination................................... 450 Sozialisierung................................. 450 Wissensverteilung .........84, 290, 452, 511 Wissensziel..................................288, 448 WLAN-Sicherheit .............................. 480 Workflow ........................................... 435 Workflow Management Coalition..... 435, 439 Workflow Reference Model............... 439 Workflow-Managementsystem ...452, 545 Workflow-Managementwerkzeug...... 440

X XML................................................... 435 XML Metadata Interchange ............... 255 XML Process Definition Language... 435, 439 XP ...............................................397, 404 XPDL ..........................................435, 439

Z Zachman Enterprise Framework .......... 47 Zachman Framework ........................... 47 Zeitvergleich ...................................... 349 Zentralisierung ............................141, 147 Zerlegung ....................................373, 383 Zertifizierung ..............................149, 486 Grundschutz ................................... 474 ISO 27001 ...................................... 183 ISO 9001 ........................................ 157

Schlagwortverzeichnis

ISO/IEC 20000 ...............................318 IT-Grundschutz...............................183 Produkt............................................184 Qualitätsmanagement-System.........157 Servicemanagement ........................318 ZGB ......................................................67 Ziel..............................................103, 373 Zielanalyse empirische.......................................106 theoretische .....................................106 Ziel-Architektur ....................................45 Zielbeziehung .....................................103 Zielcharakter .......................................105 Zielerreichungsgrad ............................373 Zielertrag .................................... 373, 377 Zielertragsmatrix......................... 373, 377 Zielertragswahrscheinlichkeit .............381 Zielforschung......................................106 Zielgewicht .........................................383 Zielhierarchie...........................103 f., 373 Zielinhalt..................................106 f., 203 Zielkriterium ............................... 373, 376 Zielmaßstab.........................................107 Anpassung.......................................108 Durchdringung ................................108 Produktivität ...................................108 Sicherheit ........................................108 Wirksamkeit....................................109 Wirtschaftlichkeit............................109 Zielplanung .........................................103 Zielplanung, strategische ....................103 Zielsystem........103 f., 138, 287, 373, 376 Zielwert....................................... 373, 377 Zielwertmatrix ............................ 373, 377 Zinssatzmethoden ...............................368 Zivilgesetzbuch.....................................67 Zugangskontrollgesetz ..........................75 Zugangskontrollsystem.......................324 Zukunftsbild........................................409 Zukunftstechnologie ...........................163 Zuverlässigkeit....................................152