DV-Controlling [4., unwesentlich veränderte Auflage. Reprint 2018] 9783486800043, 9783486250657

Citation preview

DV-Controlling Von Universitätsprofessor

Dr. Herbert Kargl

4., unwesentlich veränderte Auflage

R. Oldenbourg Verlag München Wien

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Kargl, Herbert: DV-Conctrolling / von Herbert Kargl. - 4., unwes. veränd. Aufl. - München ; Wien : Oldenbourg, 1999 ISBN 3-486-25065-5

© 1999 R. Oldenbourg Verlag Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0, Internet: http://www.oldenbourg.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Gedruckt auf säure- und chlorfreiem Papier Druck: Grafik + Druck, München Bindung: R. Oldenbourg Graphische Betriebe GmbH, München ISBN 3-486-25065-5

Inhaltsverzeichnis 1.

Wettbewerbswirkungen von Informations- und Kommunikationssystemen

2.

Controlling und Controllingaufgaben

3. 3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.3

Koordinationsfeld „Strategische IuK-Planung" Controllingziele Strategische Planung der IuK-Systeme Unternehmensstrategie und Geschäftsfeldstrategie Planungsprozeß Entwicklung strategischer IuK-Systemkonzeptionen Bewertung strategischer IuK-Systemkonzeptionen Projektportfolio Strategische Planung der IuK-Infrastruktur

4.

Koordinationsfeld „Planung und Durchführung von IuK-Projekten" Controllingziele Management von IuK-Projekten Erfolgskriterien für IuK-Projekte Rollenverständnis der Projektpartner Projektteam Projektziele Vorprojekt Koordinationsgremien Planung und Steuerung der Software-Eigenentwicklung Projektplanung Vorgehensmodelle Spezifizierung der fachlichen Anforderungen Software-Entwurfsumgebungen Termin- und Kostenplanung Qualitätsplanung Projektsteuerung Qualitätslenkung Benutzerbefragung Projektwertanalyse Projektfortschrittskontrolle Unterstützung der Teamarbeit Software-Produktmanagement

4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.3 4.3.1 4.3.1.1 4.3.1.2 4.3.1.3 4.3.1.4 4.3.1.5 4.3.2 4.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4 4.3.2.5 4.4

VI

Inhaltsverzeichnis

4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5

Planung und Steuerung des Software-Fremdbezugs Software-Fremdbezug Vorgehensmodelle Auswahl Konzeptionierung und Anpassung Umstellung

5. 5.1 5.2 5.3 5.4 5.5 5.6 5.7

Koordinationsfeld „Wirtschaftlichkeit" Controllingziele Wirtschaftlichkeitskriterien Wirtschaftlichkeitsrechnung Nutzenbegründung Risikoanalyse von IuK-Projekten Priorisierung von IuK-Projekten Lebenszykluskosten

85 85 85 88 92 97 100 101

6.

Koordinationsfeld „Anwendungsbetrieb und DV-Infrastruktu r" Controllingziele Sicherheitsmanagement Wartungsmanagement Produktionsmanagement Benutzerservice

103 103 103 108 113 114

6.1 6.2 6.3 6.4 6.5

72 73 73 77 77 84

7.

Koordinationsfeld „Verrechnung von Kosten und Leistungen" 7.1 Controllingziele 7.2 Budgetierung 7.3 Kosten- und Leistungsverrechnung 7.3.1 Ziele 7.3.2 Anforderungen 7.3.3 Grundsatzfragen 7.3.4 Verrechnungsmethoden 7.3.4.1 Kostenumlage 7.3.4.2 Leistungsverrechnung 7.3.4.2.1 Bezugsgrößen und Verrechnungspreise 7.3.4.2.2 Verrechnung bei zentraler IuK-Infrastruktur 7.3.4.2.3 Verrechnung bei dezentraler IuK-Infrastruktur 7.3.4.3 Prozeßkostenrechnung 7.3.4.4 Service Level Vereinbarung

117 117 117 119 119 119 119 121 121 122 122 123 128 129 134

8. 8.1 8.2

137 137 137

Koordinationsfeld „IuK-Organisation" Controllingziele Eingliederung in die Aufbauorganisation

Inhaltsverzeichnis

VII

8.3 8.4

Strukturierung der internen Organisation Rezentralisierung

139 143

9. 9.1 9.2 9.3 9.4 9.5

Koordinationsfeld „Outsourcing" Definition Controllingziele Grundsatzfragen Ausschöpfung des Rationalisierungspotentials Vorgehensweise

145 145 145 146 146 147

10.

Controllinginformationen

151

11.

Literaturverzeichnis

159

12.

Stichwortverzeichnis

167

Vorwort

IX

Vorwort zur 3. und 4. Auflage Die 3. Auflage ist gegenüber der 2. Auflage, die ein unveränderter Nachdruck der 1. Auflage ist, eine völlige Neubearbeitung. Diese ist nicht nur deshalb erforderlich geworden, weil sich die Informations- und Kommunikationstechnik sowie insbesondere deren Nutzung im Unternehmen erheblich verändert hat, sondern auch deshalb, weil in der Praxis das Controllingbewußtsein dazu ausgeprägter geworden ist, und weil deshalb auch die Anforderungen an dieses Controlling gestiegen sind. Die Unterschiede zu den bisherigen Auflagen zeigen sich zunächst darin, daß der Buchtitel in „DV-Controlling" geändert wurde. Dadurch soll dem Sachverhalt Rechnung getragen werden, daß ein Controlling, das sich auf den DV-Bereich als Unternehmensabteilung beschränkt, als zu eng anzusehen ist, denn Informations- und Kommunikationssysteme (IuK) durchziehen heute das gesamte Unternehmensgeschehen. Wenn als Buchtitel nicht IuK-Controlling oder ITControlling (IT = Information Technology), sondern einfach „DV-Controlling" gewählt wurde, so soll dadurch ausgedrückt werden, daß trotz aller flächendeckenden und wettbewerbsrelevanten Wirkungen von zeitgemäßen Informations- und Kommunikationssystemen diese nicht Selbstzweck sind, sondern letztlich nur dienenden Charakter für das Erreichen der Unternehmensziele haben. Ein weiterer, aus der Gliederung bereits ersichtlicher Unterschied ist der, daß die bisher „Prüffelder" genannten Objektbereiche des Controllings in „Koordinationsfelder" umbenannt wurden, um dadurch eventuelle Fehlinterpretationen über die Controllingfünktion bereits im Vorfeld zu vermeiden. Materiell sind u. a. folgende Unterschiede zu vermerken: • das Konzept der Geschäftsprozeßorgansiation als weitere Grundlage für die Entwicklung strategischer IuK-Systemkonzeptionen, • der Vergleich der Vorteilhaftigkeit von zentralen und dezentralen Hardware-Infrastrukturen, • die Betonung der Rolle des Projektleiters als „Unternehmer auf Zeit", • das Einbeziehen der Empfehlungen nach ISO 9000, Teil 3, in die Qualitätsplanung, • das Konzept eines Software-Produktmanagements als Weiterfuhrung oder als Ablösung für das Software-Projektmanagement, • Referenzmodelle zur Evaluierung und Konzeptionierung von Standard-Anwendungssoftware, • das Konzept lebenszyklusbezogener Kostenfortschreibung für Anwendungssysteme, • Benutzerservice (Aufgaben und Effizienzbeurteilung), • Leistungsverrechnung in Netzen, • Prozeßkostenrechnung für den IuK-Bereich, • die organisatorische Gestaltung des IuK-Bereichs im Unternehmen. Schließlich sind die Controllinginformationen zu den einzelnen Koordinationsfeldern in einem eigenen Kapitel (Kapitel 10) zusammengefaßt, um dadurch das gezielte Nachschlagen zu erleichtern. Besonderen Dank schuldet der Verfasser Frau Dipl.-Hdl. B. Mohneck, die in unermüdlichem Einsatz und mit der ihr eigenen Akribie die zahlreichen Abbildungen erstellt hat. In der 4. Auflage habe ich mich, auf Grund des raschen Absatzes, auf eine kritische Durchsicht des Textes beschränken können.

Herbert Kargl

X

Vorwort

Vorwort zur 1. Auflage Controlling ist eine Funktion zur Unterstützung der Führung im Unternehmen durch Koordination und Koordinationskontrolle; der Controller ist deshalb als „unterstützender Konstrukteur" der fachlichen Informations-, Planungs- und Kontrollsysteme, als Koordinator von Planung und Überwachung und Steuerung und als „Warner" bei sich abzeichnenden Planabweichungen und Veränderungen zu sehen. Controlling gilt im Unternehmen und in dessen Teilbeeichen heute als etabliert; nicht jedoch im DV-Bereich, denn hier bestehen in der Praxis nich selten noch erhebliche Defizite an Controlling-Aktivitäten - und das, obwohl die DV nicht nur ein erheblicher Kostenfaktor, sondern auch ein signifikanter Wettbewerbsfaktor für das Unternehmen ist. Dieses Buch will Ansatzpunkte zu einem Controllingkonzept für den DV-Bereich vermitteln, das sich nicht nur an der traditionellen Controllingfrage „Döing things right?" (Effizienz), sondern besonders an der aktuelleren Frage „Döing the right things?" (Effektivität) orientiert. Die Grundlage dazu sind die DV-Anwendungen, die strategische Planung der DV-Unterstützung, die Anwendungsentwicklung und der Anwendungsbetrieb, ergänzt durch die Verrechnung von DV-Leistungen und -Kosten und durch Überlegungen zum Outsourcing, die die „Prüffelder" für Controlling-Aktivitäten bilden. Für jedes dieser „Prüffelder" werden zunächst die Controllingziele formuliert; daran schließt sich ein Aufriß von Vorgehensweisen, Methoden und Instrumenten an, die sich als Grundlage für Planung und Steuerung eignen. Informationen sind die wichtigste Ressource für das Controlling; deshalb werden zu jedem „Prüffeld" typische Controllinginformationen genannt. Das Buch entstand aus Materialien zu der Vorlesung „Controlling im DV-Bereich", die zu den Lehrveranstaltungen des Wahlfaches „Wirtschaftsinformatik" im Rahmen der wirtschaftswissenschaftlichen Studiengänge an der Universität Mainz gehört, und aus zahlreichen Praxissseminaren, die an der Technischen Akademie Wuppertal gehalten worden sind. Deshalb wendet sich dieses Buch an Studierende als Lehrbuch, an Controller als Leitfaden und an geplagte DVLeiter als Hilfestellung, um Controlling im eigenen Bereich auch ohne Controller durchführen zu können. Für die kritische Durchsicht des Manuskriptes sowie für wertvolle Hinweise danke ich meinen Mitarbeitern, Herrn Diplom-Mathematiker G. Dischinger und Herrn Diplom-Volkswirt A. Schwickert. Darüber hinaus danke ich besonders Frau cand. rer. pol. B. Mohneck für die akribische Anfertigung der Abbildungen und Herrn Diplom-Volkswirt G. Maurer für die sorgfältige Erstellung der Druckvorlagen. Mein Dank gilt weiter dem Cheflektor am Oldenbourg-Verlag, Herrn Diplom-Volkswirt M. Weigert, der es ermöglicht hat, daß das Manuskript in kurzer Zeit als Buch veröffentlicht werden konnte. Herbert Kargl

1. Wettbewerbswirkungen von Informations- und Kommunikationssystemen

1.

1

Wettbewerbswirkungen von Informations- und Kommunikationssystemen

Der Einsatz der Datenverarbeitung (DV) im Unternehmen, insbesondere in Form von operativen Systemen für die Bereiche Vertrieb, Lagerhaltung und Beschaffung, Fertigungsplanung und -Steuerung usw., war von jeher ein Mittel zum Zweck, vorrangig zum Zweck der Rationalisierung. Die Fragestellung für die Nutzung der DV unter dieser Sichtweise lautete: Welche Aufgaben und Arbeitsabläufe lassen sich durch den Einsatz von DV rationalisieren? Die Ziele, die dazu verfolgt werden, sind Leistungsziele (z. B. Bearbeitungszeiten reduzieren, Produktionsmengen erhöhen) und Kostenziele (z. B. Personaleinsparung, Reduzierung von Lagerbeständen). Datenverarbeitung besteht jedoch schon lange nicht mehr nur aus operativen Systemen zur Verarbeitung von Massendaten aus funktionaler Arbeitsteilung; das zeitgemäße Nutzungspotential der „DV" besteht aus • integrierten Anwendungssystemen zur Unterstützung von Geschäftsprozessen, • Systemen für den zwischenbetrieblichen Datenverbund, durch die die Leistungsbeziehungen zwischen Lieferanten und Kunden unterstützt werden, •

Vorgangssteuerungssystemen, die eine umfassende, aber individualisierte Sachbearbeitung ermöglichen, • Informationssystemen zur gezielten, bedarfsorientierten Informationsversorgung von Führungskräften, • Planungs- und entscheidungsunterstützenden Systemen, • Systemen zur Unterstützung der internen und externen Kommunikation mit Text, Bild und Ton, •

Systemen zur Unterstützung von lokal und nicht lokal gebundenen kooperativen Arbeitsprozessen.

Diese Nutzungsmöglichkeiten stehen nicht isoliert nebeneinander, sondern sie bilden einen Verbund von Informations- und Kommunikationssystemen (IuK-Systeme). Dieser Systemverbund beinhaltet mehr als nur Rationalisierungspotentiale: Da nahezu sämtliche Wertschöpfungsprozesse in der Unternehmung sowie insbesondere der Verbund der Wertschöpfungsprozesse von Unternehmungen untereinander von Informationen getragen werden, folgt daraus, daß IuK-Systeme als ein Mittel zum Zweck auf einer höheren Ebene als nur der Rationalisierungsebene anzusiedeln sind: auf der Ebene von Wettbewerbswirkungen und dort als ein Mittel zur Erzielung von strategischen Wettbewerbsvorteilen. Ein strategischer Wettbewerbsvorteil hat allgemein folgenden Anforderungen zu entsprechen (vgl. Simon, 8): • er muß auf ein Leistungsmerkmal zielen, das für den Kunden wesentlich ist, • er muß von dem Kunden wahrgenommen werden, • er muß dauerhaft sein, d. h. der Vorteil darf von der Konkurrenz nicht bereits in kurzer Zeit eingeholt werden.

2

1. Wettbewerbswirkungen von Informations- und

Kommunikationssystemen

Die Wettbewerbsvorteile, die von einem Verbund von IuK-Systemen ausgehen können, sind z. B.: • schnelles und flexibles Reagieren auf Kundenwünsche, • bedarfsgerechte Lieferfähigkeit, • individuelle, gezielte Kundenbetreuung, • engere Kundenanbindung, • größere Marktpräsenz, • schnellere Produktdifferenzierung, • schnellere Neuproduktentwicklung, • Verbesserung der Serviceleistungen insgesamt. Vor dem Hintergrund dieser Beispiele stellt sich die Frage: Wann gelten IuK-Projekte bzw. IuK-Systeme als wettbewerbsrelevant? Die Antwort darauf ergibt sich aus einer kurzen Betrachtung des Zusammenhangs von Wettbewerbsstrategien, kritischen Erfolgsfaktoren und IuK-Systemen. Die Wettbewerbsstrategien, die von Unternehmungen verfolgt werden können, lassen sich wie folgt untergliedern (vgl. Porter/Millar; Hinterhuber): • Kostenführerschaft: Ausnutzen der Möglichkeit zur Kostendegression durch große Produktionsmengen. • Differenzierung: Abgrenzung der eigenen Produkte und Dienstleistungen gegenüber vergleichbaren Produkten und Dienstleistungen in der Branche; Schaffung „einmaliger", signifikant unterschiedlicher Produkte und Dienstleistungen. • Konzentration: Konzentration auf bestimmte Marktsegmente, Geschäftsfelder oder Marktnischen. • Koalition: Abstimmung/Bündnisbildung mit Wettbewerbern. • Fusion: Zusammenschluß/Aufkaufen von Unternehmen zum Ausbau marktdominierender Positionen. Die Wirksamkeit von Wettbewerbsstrategien hängt primär von den kritischen oder strategischen Erfolgsfaktoren ab, die das Fundament einer jeden Strategie bilden. Als kritische Erfolgsfaktoren gelten solche Einflußgrößen, von denen der Erfolg einer Unternehmung bzw. einer verfolgten Wettbewerbsstrategie essentiell abhängt; typische allgemeine Beispiele dazu sind z. B. • • • • • •

strikte Kundenorientierung, marktkonformes Produktprogramm, kurze Lieferzeiten, kurze Beschaffungszeiten, hohe Produktqualität, hohe Servicequalität.

1. Wettbewerbswirkungen

von Informations-

und Kommunikationssystemen

3

Kritische Erfolgsfaktoren ergeben sich aus der Analyse vielschichtiger Ursache-Wirkungsbeziehungen; die drei erstgenannten Wettbewerbsstrategien sind z. B. von folgenden kritischen Erfolgsfaktoren abhängig: •

Kostenluhrerschaft:

hohe Produktivität, stringente Kostenkontrolle, Verfahrensinnovation;

•

Differenzierung:

attraktive Produktgestaltung, signifikante Produktqualität, schnelle Produktinnovation, besondere Servicequalität, fertigungstechnische Flexibilität, organisatorische Flexibilität;

•

Konzentration:

bedarfsgerechte und/oder kaufbudgetgerechte Gestaltung von Produkten und Dienstleistungen.

Die meisten dieser kritischen Erfolgsfaktoren beruhen unstrittig auf der Nutzung von IuK-Systemen (Abb. 1).

Kritischer Erfolgsfaktor:

luK-Basis:

Kostenkontrolle:

Integrierte Abrechnungs- und Kontrollsysteme;

Verfahrensinnovation:

Computer Aided Quality Control, Zugriff zu externen DatenbankInformationsdiensten (z. B. Patentinformationen);

Produktgestaltung:

Computer Aided Design, Computer Aided Planning;

Produktqualität:

Fertigungsautomation, Computer Aided Quality Control;

Servicequalität:

Kundeninformationssystem, Außendienststeuerung, Lieferlogistik, Telewartung, Problemmanagementsystem;

Flexibilität:

flexible Fertigungssysteme, moderne PPS-Systeme, Lagersysteme, Unterstützung der Transportlogistik, zwischenbetrieblicher Datenverbund, integrierte Sachbearbeitung, Vorgangssteuerungssysteme.

Abb. 1: Kritische Erfolgsfaktoren und Unterstützung durch luK-Systeme

4

1. Wettbewerbswirkungen

von Informations- und

Kommunikationssystemen

Daraus folgt als Antwort auf die Frage, wann Informations- und Kommunikationssysteme als wettbewerbsrelevant anzusehen sind: • Informations- und Kommunikationssysteme sind dann wettbewerbsrelevant, wenn sie die Wettbewerbsstrategien der Unternehmung und die diesen Strategien zugrundeliegenden kritischen Erfolgsfaktoren unterstützen!

2. Controlling und Controllingaufgaben

2.

5

Controlling und Controllingaufgaben

In der Praxis zählt Controlling zu den etablierten Aufgaben in Unternehmen und in der Theorie ist Controlling ein eigenständiges Lehr- und Forschungsgebiet; dennoch wird der Begriff des Controllings „in der Literatur fast einhellig als unklar oder schillernd charakterisiert" (Schildbach, 21). Die Diskussion darüber, warum das so ist, und welches Spektrum von Interpretationen mit dem Controllingbegriff verbunden ist, soll hier nicht aufgegriffen werden; die einschlägige Literatur dazu gibt Aufschluß (so z. B. Albach/Weber, Horväth, Lehmann, Spremann/Zur). Der Intention dieses Buches entspricht am ehesten diejenige Sichtweise, die Controlling als Unterstützung der Führung versteht (so z. B. Bottier, 21). Diese vergleichsweise weitgefaßte Interpretation bedarf der Präzisierung: Die wesentlichen sachbezogenen Komponenten der Führung sind Zielvorgabe bzw. Zielvereinbarung, Planung, Entscheidung, Kontrolle und die Übernahme der Verantwortung für getroffene Entscheidungen. Der Controller leistet hierzu „in begleitender Funktion betriebswirtschaftlichen Service, sorgt für Kosten- und Ergebnis- sowie Strategietransparenz, koordiniert die Teilpläne des Unternehmens ganzheitlich und nicht nur zahlenmäßig, organisiert ein unternehmensübergreifendes Berichtswsen und sorgt für die Wirtschaftlichkeit im System" (Deyhle, 2). Aus einem solchen Selbstverständnis des Controllings ergibt sich, daß der Führung die „Entscheidungsverantwortung" vorbehalten bleibt und dem Controlling die „Transparenzverantwortung" obliegt (vgl. Horväth [Controllingkonzept], 4). Der Kern der Controllingaufgabe ist die Koordination und die Koordinationskontrolle innerhalb des Führungssystems des Unternehmens (vgl. Horväth [Controlling], 143); die Teilaufgaben dazu sind: • Unterstützung bei der Zielfindung; • Unterstützung bei der Planung: - Bewertung der Situation, - Entwerfen/Auswahl von Planungssystemen; • Unterstützung bei der Überwachung: - Bewertung der Situation, - Entwerfen/Auswahl von Überwachungs- und Steuerungssystemen; • Informationsversorgung für Zielfindung, Planung und Überwachung, • Koordination von Zielen, Planung und Überwachung. Für das DV-Controlling sind die zentralen Objektbereiche • die strategische IuK-Planung, • die Planung und Durchführung von IuK-Projekten, • der Anwendungsbetrieb und die DV-Infrastruktur, • die Verrechnung von Kosten und Leistungen, • die organisatorische Gestaltung des IuK-Bereiches, • das Outsourcing von DV-Leistungen.

6

2. Controlling und Controllingaufgaben

Jeder dieser Objektbereiche repräsentiert ein „Koordinationsfeld" i. S. des dargelegten Selbstverständnisses des Controllings, das hier nach folgendem Konzept dargestellt wird: • • •

Controllingziele, Methoden, Controllinginformationen.

Die Controllingziele repräsentieren die Ziele, die der Controller in Wahrnehmung seiner Aufgaben von feldspezifischer Koordination und Koordinationskontrolle verfolgt. Unter „Methoden" werden in einem kurzen Aufriß diejenigen Vorgehensweisen und Instrumente skizziert, die sich als Grundlage für die Planung und Steuerung in dem jeweiligen Koordinationsfeld eignen. Informationen sind die wichtigste Ressource für das Controlling; deshalb werden für jedes Koordinationsfeld die wichtigsten Controllinginformationen in Form einer Checkliste zusammengestellt (Kap. 10).

3. Koordinationsfeld

3. 3.1

„Strategische

¡uK-Planung"

7

Koordinationsfeld „Strategische IuK-Planung" Controllingziele

Für das Koordinationsfeld „Strategische IuK-Planung" lassen sich die Controllingziele durch folgende Fragen umreißen: • Existiert eine strategische IuK-Planung? • Wo ist die strategische IuK-Planung im Unternehmen angesiedelt? • Haben wir die „richtigen" IuK-Systeme? • Welches Qualitätsniveau haben die gegenwärtigen IuK-Systeme? • Haben wir die „richtige" IuK-Infrastruktur? • Wird das Potential von zeitgemäßer IuK-Technik und von zeitgemäßen IuK-Systemen erkannt und zielorientiert genutzt? • Erfolgt die strategische IuK-Planung konform zu den Zielen der strategischen Unternehmensplanung? • Wie werden strategische IuK-Konzeptionen entwickelt? • Sind Konzept und Inhalt der strategischen IuK-Planung konsistent? • Welches Qualitätsniveau haben die geplanten IuK-Systeme? • Existiert eine „Meßlatte" zur vergleichenden Bewertung von strategischen IuK-Konzeptionen? Die erste Frage mag überflüssig erscheinen, aber es gehört durchaus noch nicht zur Selbstverständlichkeit, daß für den Bereich Information und Kommunikation im Unternehmen eine strategische, d. h. an den mittel- und langfristigen Unternehmenszielen orientierte Planung praktiziert wird (vgl. Erhebung von Zanger/Schöne). Die nicht selten anzutreffende „Bündelung" von Software-Entwicklungsvorhaben in mittel- bis langfristig anstehende IuK-Projektpakete ist als „strategische" IuK-Planung zu wenig. Zur Beantwortung der obigen Fragen soll die strategische IuK-Planung in eine strategische Planung der IuK-Systeme und in eine strategische Planung der IuK-Infrastruktur unterteilt werden.

3.2

Strategische Planung der IuK-Systeme

3.2.1

Unternehmensstrategie und Geschäftsfeldstrategie

Die Durchsetzung von Wettbewerbsstrategien ist nicht selten abhängig von einer entsprechenden Unterstützung durch IuK-Systeme. Umgekehrt ermöglicht das Nutzungspotential von IuK-Systemen oftmals erst das Erzielen von Wettbewerbsvorteilen (sog. „Hebel- oder Enabler"-Wirkungen); so z. B. die Leistungssynchronisation zwischen Kunde und Lieferant auf Grundlage von Electronic Data Interchange (EDI) oder in Form von vernetzten Organisationsstrukturen, die z. B. durch das Ver- oder Auslagern von Geschäftsaktivitäten bei gleichzeitiger Erhaltung des Informationsverbundes im Unternehmen entstehen. Diese Sachverhalte rechtfertigen und fordern es zugleich, die mittel- bis langfristige IuK-Planung in die strategische Unternehmensplanung einzubinden, denn zwischen beiden Planungsfeldern besteht heute eine sehr enge Wechselwirkung.

8

3. Koordinationsfeld

„ Strategische IuK-Planung

"

Gegenstand der strategischen Unternehmensplanung ist die Entwicklung von Strategien für das Sichbehaupten des Unternehmens im Wettbewerb. Dazu werden üblicherweise zwei Strategierichtungen

unterschieden (Hanssmann, 29): die Unternehmensstrategie und die Geschäftsfeld-

strategie. Die Unternehmensstrategie befaßt sich mit der Entwicklung und Pflege des unternehmerischen Selbstverständnisses, mit der Optimierung des bestehenden Geschäftsfeldportfolios, dem Anbahnen und Aufbauen neuer Geschäftsfelder und mit dem Management kritischer Ressourcen. Die Geschäftsfeldstrategie befaßt sich für jedes Geschäftsfeld mit der Entwicklung der strategischen Rahmenkonzeption (Tätigkeitsfeld, Basis der Konkurrenzfähigkeit, Zielvorstellungen) und der Planung von Geschäftsprozessen. Die strategische Planung von IuKSystemen ist zweckmäßigerweise in die Geschäftsfeldstrategie einzubinden, denn dort werden die konkreten Vorgaben für die Gestaltung der unternehmerischen Aktivitäten für die nächsten 3-5 Jahre entwickelt. 3.2.2

Planungsprozeß

Für die Durchführung der strategischen IuK-Planung wurden verschiedene Vorgehensmodelle entwickelt (s. hierzu Übersichten und Vorgehensmodelle von z. B. Hansen/Riedl, Heinrich/Lehner, Lehner, Österle/Brenner/Hilbers, Riedl), von denen die meisten auf dem üblichen Top-down-Planungsprozeß beruhen mit der Schrittfolge von Situationsbeurteilung, formulierung und Strategie-Entwicklung.

Analyse der internen Situation

i

Problemfelder

Analyse der externen Situation

¡

1f 4

Strategische Defizite

Standortbestimmung

Szenarien

Situationsbeurteilung Situation:

Gegenwart

Zukunft

positive Aspekte

STÄRKEN

CHANCEN

negative Aspekte

SCHWÄCHEN

RISIKEN

Abb. 2: Analyseobjekte der Situationsbeurteilung

I

Ziel-

3. Koordinationsfeld „Strategische IuK-Planung"

9

Die Situationsbeurteilung dient dazu, Stärken und Schwächen, aber auch Chancen und Risiken der Unternehmung bzw. der einzelnen Geschäftsfelder herauszuarbeiten; sie wird üblicherweise mit einer Analyse der internen und der externen Situation (Abb. 2) eingeleitet. Anlässe dazu sind z. B. die Erfolgssituation in bestehenden Geschäftsfeldern, das Entstehen neuer Geschäftsfelder, technische Entwicklungen sowie das Überprüfen bisher praktizierter Wettbewerbsstrategien. Objekte der Analyse der internen Situation sind die Sachverhalte, die Geschäftsfelder begründen: Produkte, Kunden, Produkt-Kunden-Beziehungen sowie darüber hinaus interne Ressourcen, Restriktionen etc.; Objekte der Analyse der externen Situation sind dann dementsprechend Märkte, Marktsegmente, Wettbewerbssituation, externe Ressourcen, Restriktionen etc. Die Schwerpunkte, auf die sich eine solche Situationsanalyse konzentriert, sind üblicherweise: • Problemfelder, • strategische Defizite, • Standortbestimmung, • Szenarien. Problemfelder sind Schwachstellenbereiche, die folgende Ursachen haben können: eingetretene oder vermutete Planabweichungen (z. B. Geschäftsfelder mit nachhaltigen Verlusten), potentielle Planabweichungen (z. B. Geschäftsfelder, die in eine neue Phase des Lebenszyklus treten oder die unternehmenspolitische Entscheidungen erfordern), Änderungen von Zielen und Maßnahmen, Änderungen von Ressourcen, Änderungen von wirtschaftlichen, rechtlichen und gesellschaftlichen Rahmenbedingungen sowie nicht zuletzt Änderungen und Entwicklungen auf dem Gebiet der Informations- und Kommunikationstechnik. Strategische Defizite sind Mangelerscheinungen, die die Existenzerhaltung des Unternehmens oder der Geschäftsfelder gefährden können; sie können in allen Bereichen auftreten, die aus dem Kontext einer konkreten Situation heraus als „existenziell" anzusehen sind; dies können z. B. sein das Produktionsprogramm, das fertigungstechnische Potential, die Serviceleistungen, das Mitarbeiterpotential, das Innovationspotential, die Managementqualität, die Organisationsstruktur, aber auch fehlende Reaktionen auf das Entstehen neuer Geschäftsfelder oder das Nichterkennen des Nutzungspotentials zeitgemäßer IuK-Unterstützung. Vor dem Hintergrund schneller Veränderungen auf den Märkten und dem daraus resultierenden Zwang zu schnellem und flexiblem Reagieren erhält der Faktor Zeit einen sehr hohen Stellenwert, der deshalb zu einem vorrangigen Indikator für die „strategische Fitneß" eines Unternehmens oder eines Geschäftsfeldes wird; so z. B. die • Zeit zur Beantwortung von Kundenanfragen, • Zeit für das Beliefern von Kunden, • Zeit für das Erfüllen von Kundenwünschen, • Zeit für die Anpassung von Produkten, • Zeit für die marktreife Entwicklung von Produkten, • Zeit für das Treffen von Entscheidungen.

10

3. Koordinationsfeld

„ Strategische IuK-Planung "

Da die wettbewerbsrelevante Wirkung von IuK-Systemen nicht zuletzt auf der Fähigkeit zur Unterstützung von zeitgerechtem und abgestimmtem Agieren und Reagieren beruht, sind im Rahmen der Analyse strategischer Defizite vorrangig diejenigen kritischen Erfolgsfaktoren herauszuarbeiten, die auf der Nutzung von IuK-Systemen beruhen, und die fur die Unternehmung bzw. deren Geschäftsfelder relevant sind Es sind dies z. B.: •

für den Bereich Vertrieb: - Lieferservice, - Kundeninformation, - Kundenbetreuung; • für den Bereich Produktentwicklung: - Produktinnovation, - Produktgestaltung, - Produktqualität; • für den Bereich Management und Organisation allgemein: - Reaktionsschnelligkeit, - Flexibilität. Diese kritischen Erfolgsfaktoren bilden die Grundlage für ein Polaritätsprofil, welches durch Vergleich der Erfolgspositionen nach eigener Einschätzung mit denen des oder der Wettbewerber die strategischen Defizite visualisiert (Abb. 3).

Erfolgsfaktoren

Erfolgsprofil

+3

+2

+1

0

-1

-2

-3

Lieferservice

Kundeninformation

Kundenbetreuung

Produktgestaltung

Produktqualität

Produktinnovation

Reaktionsfähigkeit

Flexibilität

Abb. 3: Polaritätsprofil zur Analyse strategischer Defizite im luK-Bereich

3. Koordinationsfeld „Strategische IuK-Planung"

11

Der Standortbestimmung kommt neben der Analyse strategischer Defizite eine hervorgehobene Bedeutung zu, denn sie bildet die Grundlage für das Erkennen der „Wertigkeit" der eigenen Position. Dazu sind die Standorte in den Geschäftsfeldern und im Potential der IuK-Unterstützungsmöglichkeiten zu bestimmen; in Abb. 4a sind die Analysefelder dazu zusammengestellt.

Standortbestimmung von Geschäftsfeldern: • die Analyse der Stellung im Markt: - Wettbewerbssituation / eigene Position, - Marktgängigkeit von Produkten / eigene Position, - Qualität von Serviceleistungen / eigene Position, - Modernität von Verfahrenstechniken / eigene Position, - geforderte Human Resources / eigene Position. • die Analyse von Umweltbedingungen: - Auflagen des Gesetzgegebers, - Anforderungen von Kunden und Lieferanten, - soziale Einwirkungen, - eigenes Aktions- oder Reaktionsvertialten. Standortbestimmung im Potential der luKUnterstützungsmöglichkeiten: • die Analyse der bestehenden und der geplanten Anwendungen: - Marktorientierung, - Unterstützung von Geschäftsprozessen, - Förderung des Kundennutzens, - unternehmensspezifische Wettbewerbsvorteile, - Innovationsförderung, - Qualitätsförderung, - Flexibilitätsförderung, - Informationsversorgung, - Anwendungen mit "Added Values", - Unterstützung von administrativen Prozessen, - Kosten und Nutzen der Anwendungen; • die Analyse der luK-lnfrastruktur: - Architektur der Hardware-Systemstruktur, - Architektur der Software-Systemstruktur, - Architektur der Vernetzung und der Datenkommunikation, - Struktur der Datenhaltung, - Struktur der Software-Entwicklungsumgebung, - Mitarbeiter-Qualifikation, - Organisation des luK-Bereichs; • die Analyse des "State of the Art": - im Bereich von Anwendungen, - im Bereich der luK-lnfrastruktur.

Abb. 4a: Analysefelder zur Standortbestimmung

12

3. Koordinationsfeld

„Strategische

IuK-Planung"

Die Analyse der bestehenden Anwendungen kann dadurch aussagefähig gestaltet werden, daß diese zunächst auf die Wertschöpfungskette des Unternehmens projeziert werden (Abb. 4b); daraus ergibt sich ein grober Überblick darüber, welche Segmente der Wertschöpfungskette in welchem Ausmaß dv-unterstützt sind, gemessen an der Anzahl der vorhandenen DV-Systeme.

GLAZ-R. Reisekosten-R. Lohn/ Geh.-R.

Kosten-R ARGE-B. Anlagen-B. Kreditoren-B. Debitoren-B.

Wareneingang Einkauf Bestandsführung

Fertigungssteuerung Auftragsverw. Terminplanung Bedarfsplanung Projektierung

After-SalesService Fakturierung Auslieferung Auftragsbearbeitung

leistungsverzDatenbank Ausschreibung Angebotsbearbeitung

Produktion» Vertrieb

Abb. 4b: Bestandsaufnahme bestehender DV-Anwendungen (erstellt nach Wiedhöfel, S. 48)

Anschließend daran kann das Anwendungsportfolio erarbeitet werden; dazu sind die bestehenden Anwendungen nach ihrer Wettbewerbsrelevanz i. S. des Haltens unternehmensspezifischer

Wettbewerbsvorteile

und

gleichzeitig

nach

deren

laufenden

Betriebs-

und

Wartungskosten zu gruppieren. Zur Visualisierung des Anwendungsportfolios wird eine Matrix gebildet, deren Achsen die Wettbewerbsrelevanz und die Kosten

kennzeichnen.

Unterteilt man diese Achsen weiter in die Ausprägungsbereiche „niedrig", „mittel" und „hoch", so erhält man ein Raster für die Positionierung der bestehenden Anwendungen nach Maßgabe des Wertepaares „Wettbewerbsrelevanz/Kosten" (Abb. 4c).

Wettbewerbs relevanz

hoch

Vertriebsinformationssystem

CAD

Ausschreibung

After-Sa lesService Angebotsbearbeitung

mittel

Auftragsbearbeitung

Auslieferung

niedrig

Textverarbeitung

Reise kosten-R. GLA2-R. LohrWGehaltsrechnung

hoch

Sach-, FinanzBuchhaltung

mittel

Abb. 4c: Anwendungsportfolio

niedrig

Kosten

3. Koordinationsfeld

„ Strategische luK-Planung"

13

Eine Analyse auf der Grundlage von Szenarien ist z. B. für die Bereiche Wettbewerbsentwicklung, Gestaltung der Produkt- und Dienstleistungspalette, Strukturierung von Geschäftsprozessen, Gestaltung von Logistikbeziehungen sowie für die Nutzungsmöglichkeiten des IuKPotentials angebracht. Im Anschluß an die interne und und externe Situationsanalyse und gestützt auf die Analyseergebnisse aus Problemfeldern, strategischen Defiziten, Standortbestimmung und Szenarien sind die verschiedenen Möglichkeiten von strategierelevanten Situationen (Stärken, Schwächen, Chancen, Risiken) im untersuchten Geschäftsfeld zu umreißen. An die Situationsbeurteilung schließt sich die Zielbildung für die strategische Planung an, deren Resultate zu den einzelnen Segmenten des Bewertungsrahmens die ersten Ansatzpunkte liefern. In einer globalen Orientierung sind dies zunächst Maximen wie z. B. „nachgewiesene Stärken sind zu erhalten und auszubauen", „erkannte Schwächen sind zu beseitigen", „gegebene Chancen sind zu nutzen" und „vorhandene und potentielle Risiken sind zu reduzieren oder zu vermeiden". Die Zielbildung selbst ist i. d. R. kein punktueller Vorgang, sondern ein Prozeß, der aus mehreren Schritten besteht (Krüger, 47): Zielideen suchen, Zielkatalog formulieren, Zielstruktur erstellen, Ziele operationalisieren, Ziele gewichten, Zielbeziehungen analysieren, Zielkonflikte bereinigen, Zielentscheidung treffen. Der Prozeß, wie Ziele zustande kommen und wie diese formuliert werden, unterliegt einigen typischen Einflußfaktoren (vgl. Krüger, 38): • kritische Wertung der Resultate der Situationsbeurteilung, • Problembewußtsein, • Kenntnis von geeigneten Maßnahmen zur Problemlösung, • Berücksichtigung von übergeordneten Zielen, • Evaluierung der Konsequenzen von Lösungsalternativen, • persönliches Anspruchsniveau an die Zielerfullung, • persönliche Präferenzen, • Bereitschaft zur Lösung von Problemen. Keiner der Einflußfaktoren ist alleine ursächlich für die Zielbildung; diese erfolgt erst durch das Zusammenwirken der sich teilweise gegenseitig bedingenden EinfluQfaktoren. Dies gilt insbesondere für Problembewußtsein und MaBnahmenkenntnis: Ziele können nur schwerlich losgelöst von Problembewußtsein und von der Kenntnis geeigneter Maßnahmen gebildet werden, und umgekehrt ist ein Problembewußtsein ohne eine zumindest rudimentäre Vorstellung über ein Anspruchsniveau ebensowenig möglich wie das Ergreifen von geeigneten Maßnahmen ohne die Kenntnis von Problemen und Zielen. 3.2.3

Entwicklung strategischer IuK-Systemkonzeptionen

Durch die bisher dargelegten Schritte, insbesondere durch die Standortbestimmung im Potential der IuK-Unterstützungsmöglichkeiten, konnte die strategische Planung von IuK-Systemen

14

3. Koordinationsfeld

„Strategische

IuK-Planung"

nur in Grundzügen in die strategische Unternehmensplanung eingebunden werden. Eine präzisere Einbindung kann erfolgen durch • das Konzept der kritischen Erfolgsfaktoren, • die Technikanalyse, • die Restrukturierung der Unternehmensorganisation. Das Konzept der kritischen Erfolgsfaktoren, das auf die Ergebnisse der Situationsbeurteilung anzuwenden ist, läßt sich durch Leitfragen beschreiben; die Fragestellung im ersten Schritt dazu lautet: • Von welchen kritischen Erfolgsfaktoren wird das Erreichen der strategischen Geschäftsfeldziele entscheidend beeinflußt? Nachdem die kritischen Erfolgsfaktoren herausgearbeitet wurden, sind im zweiten Schritt folgende Fragen zu stellen: • Wodurch lassen sich die kritischen Erfolgsfaktoren kontrollieren? • Welche Informationen und welche Maßnahmen sind dazu erforderlich? Im dritten Schritt lautet die Frage : • Welcher IuK-Unterstützungsbedarf wird durch die Ziele, die kritischen Erfolgsfaktoren und durch die zugehörigen Kontrollgrößen induziert?

Abb. 5: Ableitung der luK-lnfrastruktur aus der strategischen Planung

3. Koordinationsfeld „ Strategische IuK-Planung "

15

In Abb. 5 ist die Struktur dieser Schrittfolgen schematisch dargestellt. Abb. 6 enthält ein Beispiel dazu; darin rechtfertigen z. B. die Kontrollgrößen „Besuchserfolgsquote", „Deckungsbeitrag pro Kunde" (bezogen auf den kritischen Erfolgsfaktor „Qualität der Außendienststeuerung") sowie „Lieferzeiten", „Lieferrückstände", „Stornoquoten" (bezogen auf den kritischen Erfolgsfaktor „Qualität des Lieferservice") die Außendienststeuerung sowie die Auftragsbearbeitung und Auslieferung zum Gegenstand eines eigenständigen, wettbewerbsrelevanten IuK-Vorhabens zu machen. Durch diese Schrittfolgen wird es möglich, Basiskonzepte für IuK-Systeme zu entwickeln, die sich schlüssig aus den strategischen Unternehmens- bzw. Geschäftsfeldzielen ableiten lassen.

Strategisches Ziel für das Geschäftsfeld X: 'Erhöhung des Marktanteils in Produktgruppe Y um 1 0 % in 2 Jahren" Kritische Erfolgsfaktoren

Kontrollgrößen:

•

Marktgängigkeit der Produkte

•

Entwicklung der Marktanteile (Menge, Wert, Positionierung im Produktportfolio).

•

Qualität des Lieferservice

•

Lieferzeiten, Lieferrückstände, Stomoquoten.

•

Qualität der Außendienststeuerung

•

Besuchserfolgsquote, KundenDeckungsbeitrag.

•

Zuverlässigkeit der Auftragslogistik

•

Termineinhaltung, Komplettierunggrad der Auslieferung.

•

Qualität der MarketingUnterstützung

•

Abgrenzung von Marktsegmenten, Dokumentation von Informationen über Kunden, Erfolgsquote von SalesPromotion-Aktionen.

•

Motivation der Vertriebsbeauftragten

•

Einkommensentwicklung, Besuchsfrequenzen Aquisitionsqute, Fehlzeiten, Fluktuationsrate.

Abb. 6: Beispiel für den Zusammenhang von Zielen, kritischen Erfolgsfaktoren und Kontrollgrößen

Das Top-down-Vorgehen von den Zielen über kritische Erfolgsfaktoren und deren Kontrollgrößen zur zieladäquaten IuK-Unterstützung ist jedoch nur ein Weg zur Erarbeitung strategisch relevanter IuK-Konzeptionen. Der andere Weg fuhrt über die Potentialanalyse der

16

3. Koordinationsfeld „Strategische IuK-Planung"

IuK-Technik, wonach ausgehend von dem vorhandenen und zu erwartenden IuK-Potential unternehmensspezifische wettbewerbsrelevante IuK-Konzeptionen entwickelt werden. Der Einstieg dazu erfolgt über die Standortbestimmung im Potential der IuK-Nutzungsmöglichkeiten, wobei hier die Analyse zukünftiger Entwicklungslinien von besonderer Bedeutung ist. Für die sich daran anschließende Suche nach geeigneten Anwendungsfeldern gilt, daß sie sich allgemein an der Unternehmensstrategie und speziell an der strategischen Rahmenkonzeption für die einzelnen Geschäftsfelder orientieren muß, wenn die zu erarbeitenden IuK-Konzeptionen letztlich wettbewerbsrelevant sein sollen. Folgende Leitfragen unterstützen diese Vorgehensweise: • • •

Welche IuK-Trends zeichnen sich ab? Welche IuK-Trends sind für die Branche relevant? Welche IuK-Trends sind für das Unternehmen relevant?

• Welchen Stellenwert hat IuK-Unterstützung für die einzelnen Geschäftsfelder? • Welchen Nutzen können die einzelnen Geschäftsfelder aus IuK-Unterstützung ziehen? Es ist empfehlenswert, für die Entwicklung strategisch relevanter IuK-Konzeptionen beide Vorgehensweisen parallel anzuwenden, denn sie ergänzen und fördern sich wechselseitig. Die Restrukturierung der Unternehmensorganisation beruht auf einem Paradigmenwechsel für die Gestaltung organisatorischer Strukturen. Die fundamentalen Prinzipien für die Gestaltung der Organisation von Unternehmen sind die Verrichtungszentralisierung und die Objektzentralisierung. Die Verrichtungszentralisierungin Verbindung mit dem Gedankengut F. W. Taylors („Effizienz durch Arbeitsteilung") prägte und kennzeichnet auch heute noch das Grundbaumuster der Organisationsstruktur von Unternehmen: funktionale Gliederung und mehrstufige, hierarchisch gestaltete Aufgaben- und Führungsstruktur. Die Konsequenzen dessen sind weitgehende Arbeitsteilung und Sequentialisierung von Arbeitsabläufen und Entscheidungsprozessen, die nicht nur zu Lasten der Zeit und der Flexibilität für das Erbringen der betrieblichen Leistungen gehen, sondern die auch einen hohen Koordinationsbedarf zur Folge haben. Die Objektzentralisierung ist das zur Verrichtungszentralisierung konträre Gestaltungsprinzip: den Bezugspunkt bilden Objekte (Produkte, Produktgruppen, Märkte), denen unterschiedliche Verrichtungen (Funktionen) zugeordnet werden. Die klassischen Organisationsstrukturen, die daraus entstanden, sind die divisionale oder Sparten-Organisation und die Matrix-Organisation. Diese Organisationsstrukturen haben im Vergleich mit rein funktional gegliederten Strukturen spezifische Vorteile, aber innerhalb der objektorientiert gestalteten Unternehmensbereiche bleibt das Prinzip funktionaler Arbeitsteilung und damit auch dessen Nachteile erhalten. Erst mit einer weiter verfeinerten, streng marktbezogen objektorientierten Strukturierung - der Untergliederung des Unternehmens in strategische Geschäftsfelder oder Business Units - und mit der Gliederung der Unternehmung nach Wertschöpfungsketten (vgl. Porter/Miliar) sowie in Verbindung mit kundenorientierter Unternehmensführung („Customer Focus"), wurde ein Gestaltungsraster geschaffen, der als das Konzept der ProzeDketten, der Geschäftsprozeßorganisation (vgl. Adler) oder des Reengineering (vgl.

3. Koordinationsfeld

„Strategische

IuK-Planung"

17

Hammer/Champy) bezeichnet wird. Die danach zu entwickelnde Unternehmensstruktur ist durch folgende Merkmale gekennzeichnet: • nicht mehr funktionale Arbeitsteilung und hierarchische Aufgabengliederung prägen die Unternehmensstruktur, sondern Geschäftsprozesse; • Geschäftsprozesse setzen an Geschäftsfeldern und deren Charakteristika an; • Geschäftsprozesse sind auf Leistungen ausgerichtet, die für den Kunden einen Nutzen haben und die vermarktungsfähig sind; • diese Leistungen, deren oberste Maxime die Orientierung an den Kundenbedürfhissen ist, müssen meßbar und damit kontrollierbar sein; • jeder Geschäftsprozeß bildet einen eigenständigen Verantwortungsbereich. Geschäftsprozesse verlaufen quer zur herkömmlichen funktionalen Arbeitsteilung; sie repräsentieren jeweils eine eigenständige Wertschöpfüngskette, die personell von „Prozeßteams" getragen wird (Abb. 7); typische Beispiele dazu sind: • Neuproduktplanung und -entwicklung: Prozeßleistung: marktfähiges Produkt, Meßgröße: Entwicklungszeit (Time to Market); • Kundenaquisition und Angebotserstellung: Prozeßleistung: abgegebenes Kundenangebot, Meßgrößen: Aquisitionsdauer, Bearbeitungszeit für Kundenangebote, Anzahl von Rückfragen, erzielbarer Deckungsbeitrag; • Kundenauftragslogistik: Prozeßleistung: erfüllter Kundenauftrag, Meßgrößen: Bearbeitungszeit für Kundenaufträge, Termineinhaltung, Vollständigkeit der Auslieferung, verursachte Kosten, erzielter Deckungsbeitrag; • After-Sales-Service: Prozeßleistung: geleistete Beratung, gelöstes Kundenproblem, Meßgrößen: Wartezeit des Kunden auf die Leistungserbringung, Zeitdauer für die Leistungserbringung, Anzahl der Rückfragen / Reklamationen des Kunden nach der Leistungserbringung; • Beschaffungsauftragslogistik: Prozeßleistung: erfüllter Beschaffungsauftrag, Meßgrößen: Bearbeitungszeit, verursachte Kosten, Termineinhaltung der Lieferung, Vollständigkeit der Lieferung; • Fertigungsauftragslogistik: Prozeßleistung: erfüllter Fertigungsauftrag, Meßgrößen: Durchlaufzeit, Termineinhaltung, Vollständigkeit, verursachte Kosten. vermaschte Teams

X r

Marktk leistung ^ ^

Ziele für das Marktsegment

Abb. 7: Struktur von Geschäftsprozessen

^ ^ ^^r

18

3. Koordinationsfeld

„ Strategische IuK-Planung "

Die Restrukturierung der Untemehmensorganisation nach dem Konzept der Wertschöpfiingsketten bzw. der Geschäftsprozesse erfordert gleichzeitig eine Restrukturierung der IuK-Unterstiitzung, denn entsprechend der Maxime für die strategische IuK-Planung „Information Technology follows Organization" (modifiziert nach Chandlers „Structure follows Policy") sind die IuK-Systeme, der Informationsfluß und die Kommunikation an den Erfordernissen der einzelnen Geschäftsprozesse, aber auch gleichzeitig an deren Systemverbund auszurichten.

Wertschöpfungsketten:

"Beschaffungslogistik PC-Komponenten"

"Produktionslogistik PC"

"Marketing + Vertrieb PC"

Geschäftsprozesse:

EBENE 2

(Ausschnitt für Marktsegment "Industriekunden")

G P "Kunden aqujrieren und Angebote abgeben"

Abb. 8: Zusammenhang von Wertschöpfungsketten, Geschäftsprozessen und Vorgangsketten

Angebot an Kunde

3. Koordinationsfeld

„ Strategische luK-Planung "

19

Nicht mehr funktionale, mengenorientierte Anwendungssysteme wie z. B. Auftragsbearbeitung und Versand, Lagerhaltung und Beschaffung, Produktionsplanung und -Steuerung, eventuell ergänzt durch Komponenten der individuellen Datenverarbeitung, bilden den Planungsschwerpunkt, sondern eine flexible, modular konzipierte IuK-Unterstützung, die den Anforderungen an Integration innerhalb der Geschäftsprozesse und geschäftsprozeßübergreifend gerecht wird. Für die strategische Planung von IuK-Systemen ergibt sich daraus, daß die Geschäftsprozessein ihre fachlichen Komponenten zu strukturieren sind, die dann zum Gegenstand einer IuK-Unterstützung, z. B. in Form von geschäftsprozeßspezifischen Vorgangssteuerungssystemen und Systemen zur Unterstützung kooperativen Arbeitens, werden (Abb. 8). 3.2.4

Bewertung strategischer IuK-Systemkonzeptionen

Nach dem Erarbeiten der strategischen IuK-Konzepte für die einzelnen Geschäftsfelder sind diese Konzepte aus fachlicher Sicht aufeinander abzustimmen, um dadurch das Fundament einer konsistenten Anwendungsarchitektur für das Unternehmen zu schaffen; gleichzeitig damit sind die Prioritäten für die einzelnen IuK-Vorhaben zu bestimmen. In diesem Stadium der Planung lassen sich die Prioritäten lediglich durch Schätzungen des zu erwartenden strategischen Nutzens und der voraussichtlich anfallenden Kosten ermitteln; das geeignete Verfahren, das diese Schätzungen systematisch unterstützt, ist die Nutzwertanalyse. Die Nutzwertanalyse ist ein Verfahren zur Bewertung von Entscheidungsalternativen, das es ermöglicht, subjektive Präferenzen und Werturteile in die Bewertung mit einzubeziehen. Das Vorteilhaftigkeits- oder Nutzenkriterium nach einer Nutzwertanalyse ist der Erfüllungsgrad der Bewertungskriterien; dieser ergibt sich aus der Verdichtung von Einzelwertungen zu Präferenzpunkten. Die Bewertungskriterien bilden den Beurteilungsmaßstab für die Entscheidungsalternativen; bei der Gewichtung der Kriterien kann es zweckdienlich sein, zwischen hoch-gewichteten Muß-Kriterien und geringer gewichteten Kann-Kriterien zu unterscheiden. Zur Bewertung der Kriterienerfüllung („E") wird üblicherweise eine Kardinalskala (z. B. 0-10 Punkte) verwendet; dadurch wird eine verbale Einschätzung der Kriterienerfüllung (z. B. „sehr gut geeignet" = 10, „nicht geeignet" = 0) in rechenbare und damit verdichtbare Größen transformiert. Durch eine anschließende Sensibilitätsprüfung kann bestimmt werden, wie stabil die ermittelte Rangfolge der Varianten auf Veränderungen der Kriteriengewichtung und der Kriterienerfullung reagiert. In Abb. 9 ist ein allgemeines Schema für eine Nutzwertanalyse dargestellt. Die Bewertungskriterien („Meßlatte"), nach denen die Priorität strategischer IuK-Vorhaben durch eine Nutzwertanalyse bestimmt werden kann, sind in Abb. 10 zusammengestellt.

20

3. Koordinationsfeld „Strategische IuK-Planung"

Bewertungskriterien

Gewichtung Alternative

Alternative

Alternative

2

3

1

(G)

Alternative 4

(E)

(N)

(E)

(N)

(E)

(N)

(E)

(N)

100

Kriterium A

10

10

100

10

100

10

100

10

Kriterium B

32

0

0

0

0

1

32

0

0

Kriterium C

3

10

30

5

15

0

0

8

24

Kriterium D

38

5

190

3

114

9

342

0

0

Kriterium E

7

2

14

6

42

0

0

10

70

Kriterium F

1

10

10

0

0

5

5

5

5

Kriterium G

9

2

18

5

45

8

72

3

27

Summe Gewichtung

100

Nutzwert (Punkte-Summe) RANGFOLGE

362

316

551

226

2

3

1

4

E = Kriterienerfüllung (0-10) N = G x E = gewichtete Kriterienefüllung Abb. 9: Schema der Nutzwertanalyse

•

• • • • • • • • • • •

Kundenorientierung: - Möglichkeit zum gezielten Eingehen auf Kundenwünsche, - Erzielen von zusätzlichem Nutzen für den Kunden, - Intensivierung der Kundenbindung; Kostensenkung, Innovationsförderung, Qualitätsförderung, Flexibilitätsförderung, Verbesserung des Umweltschutzes, Verbesserung der organisatorischen Infrastruktur, Anforderungen an die luK-lnfrastruktur, Anforderungen an die Mitarbeiter, Kosten, Amortisationsdauer, Realisierungschance.

Abb. 10: Bewertungskriterien zur Bestimmung der Priorität von strategischen luK-Vorhaben

3. Koordinationsfeld

3.2.5

„ Strategische

luK-Planung

"

21

Projektportfolio

Aus dem Projektportfolio lassen sich die Prioritäten für geplante IuK-Vorhaben vor dem Hintergrund quantitativer und qualitativer Nutzenaspekte ableiten; es ermöglicht dadurch die zielgerichtete Koordinierung der IuK-Projekte und es bildet die Grundlage für eine rational begründete und nachvollziehbare Zuteilung der verfugbaren Ressourcen. Werden den einzelnen Segmenten dieser Positionierungsmatrix die verschiedenen IuK-Vorhaben zugeordnet, so erhält man ein Portfolio, aus dem sich der Stellenwert der einzelnen IuK-Projekte für das Unternehmen aus der Kombination von quantitativen und qualitativen Nutzenkriterien ergibt. Portfolios dieser Art werden üblicherweise in der Dimension „strategische Bedeutung / monetäre Wirtschaftlichkeit" erstellt (Abb. 11); die Schlußfolgerungen, die aus dieser Visualisierungshilfe gezogen werden kann, lauten je nach Segmentbereich der Matrix plakativ verkürzt: „Projekt fördern" oder „Projekt ablehnen" bzw. „Investieren / Desinvestieren". Strategische Bedeutung für das Unternehmen (Wettbewertsvorteile): -

Außendienststeuerung

hoch

Kundennähe Lieferflexibilität Lieferschnelligkeit Marktpräsenz

Produktionslogistik

Führungsinformationssystem

mittel

Buchhaltung, Provisionsabrechnung

niedrig

niedrig

mittel

hoch

Wirtschaftlichkeit (monetär) Abb. 11: Projekt-Portfolio

Das Projektportfolio bietet weiterhin eine Grundlage für die Analyse des vielfältigen Beziehungszusammenhanges von IuK-Projekten, der zwangsläufig aus integrierten IuK-Konzeptionen entsteht. Folgende Zusammenhänge sind zu Zwecken der Projektkoordinierung von besonderem Interesse: •

Innovationszusammenhang (durch ein Projekt werden neue Konzeptionen für andere Projekte möglich oder durch ein Projekt werden andere Projekte gegenstandslos),

22

3. Koordinationsfeld

„Strategische

IuK-Planung"

•

Integrationszusammenhang (die Realisierung eines Projektes setzt die Realisierung anderer Projekte voraus oder ein Projekt stellt sich als „Engpaßfaktor" für andere Projektplanungen heraus), • Investitionszusammenhang (durch ein Projekt werden die Kosten anderer Projekte beeinflußt).

3.3

Strategische Planung der IuK-Infrastruktur

Die Rahmenvorgaben für die Ausrichtung der IuK-Infrastruktur eines Unternemens resultieren aus dem Selbstverständnis, das das Management des IuK-Bereiches von seinen Aufgaben hat, und aus der Architektur der IuK-Anwendungen, die aus der strategischen Unternehmensplanung entwickelt wurde. Das Selbstverständnis wird im Leitbild des IuK-Bereiches dokumentiert; darin können folgende Aussagen enthalten sein: • • • •

IuK als Dienstleistungsfunktion für das Unternehmen, das Rollenverständnis für die Kooperation mit den Fachabteilungen, das Angebot und die Konditionen für die Dienstleistungen , die Organisationsstruktur und die Regelung der Verantwortung.

Eine zeitgemäße Anwendungsarchitektur besteht aus einem Verbund von IuK-Systemen; dies erfordert einen Verbund von Hardware- und Softwarekomponenten, denn: •

auf zentral und dezentral vorgehaltene Datenbestände muß von verschiedenen Arbeitsplätzen aus zugegriffen werden können; • lokale IuK-Anwendungen müssen untereinander und mit zentralen IuK-Anwendungen kommunizieren können; • von den einzelnen Benutzerarbeitsplätzen muß der Zugang zu verschiedenen Rechnern möglich sein, • unter den einzelnen Arbeitsplätzen muß die Kommunikation in Form von Daten, Texten und Bildern möglich sein. Für die IuK-Infrastruktur bedeutet dies: • lokale Rechner sind untereinander und ggf. mit zentralen Rechnern zu verbinden; • zwischen den verschieden Rechnern muß ein schneller Datenaustausch möglich sein; • zentral vorgehaltene Systemkomponenten (Server, Drucker, Plotter, Massendatenspeicher) sollen gemeinsam genutzt werden können. Diese Forderungen können durch zentralisierte und durch dezentralisierte Systemkonfigurationen erfüllt werden. Zentralisierte Systemkonfigurationen bestehen aus einem hierarchischstrukturierten Rechnerverbund mit den Ebenen (Abb. 12): • Zentrale Ebene, • Abteilungsebene, • Arbeitsplatzebene.

3. Koordinationsfeld

„Strategische

luK-Planung"

23

Zentralrechner

Vorrechner

Mehrplatzsystem

Terminal

Abb. 12: Hierarchisch strukturierter Rechnerverbund

Die zentrale Ebene (Back-end-Bereich) wird durch einen Zentralrechner (Mainframe) repräsentiert; dessen Aufgaben sind der Betrieb von Anwendungen mit Stapelverarbeitung von Massendaten, der Betrieb von Anwendungen, die zeitkritisch sind, d. h., die kurze Antwortzeiten und eine hohe Systemverfiigbarkeit erfordern (Transaktionssysteme), das Verwalten von Daten- und Dokumentenarchiven und die Sicherung von großen Datenbeständen. Die Abteilungsebene wird durch Abteilungsrechner (z. B. Mehrplatzsysteme) gebildet, auf die abteilungsspezifische Anwendungen verlagert werden, die nicht die Leistungsfähigkeit eines Zentralrechners erfordern. Die Arbeitsplatzebene (Front-end-Bereich) wird durch die Hardwarekomponentendargestellt, über die der Benutzer mit den IuK-Systemen kommuniziert (Terminals, Personalcomputer, Workstations und zugehörige Arbeitsplatzperipherie). Die Verarbeitung in einem hierarchisch strukturierten Rechnerverbund erfolgt vorwiegend auf dem Zentralrechner und/oder auf den Abteilungsrechnern; bei Problemstellungen, zu denen das Instrumentarium der individuellen Datenverasrbeitung (IDV) erfordererlich ist, wird die Verarbeitung lokal auf Personalcomputern und Workstatations vorgenommen. Zentralisierte Hardware-Konfigurationen basieren auf hierarchisch-strukturierten Rechnernetzen mit gestufter Kommunikationssteuerung; so müssen z. B. Terminals über die Stufen Terminal-Controller und Kommunikationsrechner (Vorrechner) oder über die Zwischenschaltung

24

3. Koordinationsfeld

„Strategische

IuK-Planung"

von Mehrplatzsystemen und Vorrechnern mit dem Zentralrechner kommunizieren, und der Zugriff von Persdonalcomputern zum Zentralrechner ist i. d. R. nur über die Zwischenschaltung eines PC-Cluster-Controllers möglich. Die Kommunikation in solchen Netzen erfolgt i. d. R. nach herstellerspezifischen, d. h. proprietären Netzkonzepten (z. B. SNA von IBM, TRANSDATA von SNI), die vorrangig auf die Einbindung von Geräten der eigenen Produktpalette ausgerichtet sind; die Konsequenz dessen ist, daß Netze dieser Art weitgehend geschlossene Netze sind, in die sich Fremdprodukte nur bedingt einbinden lassen. Dezentralisierte Systemkonfigurationen bestehen aus einem Netzverbund von autonomen Rechnern (Personalcomputern, Workstations, Zentralrechner) mit der Möglichkeit, von jedem Arbeitsplatz auf jeden Rechner des Netzverbundes zugreifen zu können. Das besondere Merkmal ist jedoch die Arbeitsteilung in diesem Netz nach dem Client-Server-Konzept. Rechner fordern Serviceleistungen an („Clients"), die von anderen Rechnern erbracht werden („Server") wobei die Rolle von Client und Server wechseln kann. Typische Server-Funktionen, die mehreren Clients gleichzeitig zur Verfugung stehen, sind datenbankgestützte Datenhaltung (Datenbankserver), Druckdienste (Druckserver), Dokumenteverwaltung (Ablageserver), Postdienste (E-Mail-Server) und Netzsteuerung (Netzserver). Der Datenaustausch in ClientServer-Konfigurationen wird über lokale Netze (LAN) vorgenommen. Ein besonderes Merkmal dezentralisierter Systemkonfigurationen ist, daß darin Arbeitsplatzund Serversysteme von unterschiedlichen Herstellern und demzufolge mit unterschiedlichen Betriebssystemen und unterschiedlichen Regeln zur Datenübermittlung miteinander kommunizieren müssen. Das ist nur dann möglich, wenn diese Netze „offen" sind, d. h., wenn die Schnittstellen für den Zugang zum lokalen Netz und die Modalitäten der Datenübermittlung im Netz standardisiert sind („Protokolle"). Das Client-Server-Konzept ist jedoch nicht vorrangig ein technisches Konzept zur Konfiguration von Hardware- und Softwarekomponenten in Netzen, sondern es ist vielmehr ein betriebswirtschaftlich-organisatorisches Konzept zur Verteilung von Aufgaben und der zugehörigen Software und DV-Infrastruktur auf die Funktionsträger im Unternehmen, um dadurch Effizienz und weitestgehende Flexibilität in der Aufgabenerflillung zu erzielen. Die Voraussetzungen dazu sind, • eine Anwendungsarchitektur, die sich an den Geschäftsprozessen des Unternehmens orientiert, • Anwendungen, die nach dem Software-Schichtenmodell strukturiert sind (Präsentationsschicht, Anwendungsschicht, Datenschicht), • im Netz verteilte Datenhaltung, • im Netz verteilte Software, • Kommunikation von Programm zu Programm sowie Aufruf verteilter Prozeduren, • Netzwerk-Management. Die sich daraus ergebenden unterschiedlichen Nutzungsformen von Client-Server-Konzepten sind in Abb. 13 dargestellt.

3. Koordinationsfeld

„Strategische IuK-Planung"

verteilte Verarbeitung

25

ausgelagerte Datenhartung

^

M

Anwendungs-I logik

Präsentation

Abb. 13. Nutzungsarten der Client-Server-Struktur (Quelle: Gartner Group, entnommen CW24 v. 11.6.93, S.43)

Zentralisierte und dezentralisierte Systemkonzeptionen sind zunächst Optionen im Rahmen der strategischen Planung der IuK-Infrastruktur, die nach der Bedarfslage des Einzelfalls zu evaluieren sind. Die allgemeine Leitlinie dazu ist das Postulat des „Rightsizing", wonach aufgrund der unterschiedlichen Anforderungen von unterschiedlichen Anwendern ein Höchstmaß an aufgabenindividueller IuK-Unterstützung zu gewährleisten ist („Das richtige System am richtigen Arbeitsplatz"). Da Anforderungen und Anwender i. d. R. heterogen sind, kann eine Kombination aus zentralen und dezentralen Infrastrukturkomponenten die zweckmäßige Lösung sein. Eine Entscheidungshilfe für das Abwägen der beiden Optionen ist in Form einer Argumente-Bilanz in Abb. 14 dargestellt. Die wichtigsten Aussagen, die im Planungskonzept für die IuK-Infrastruktur zu treffen sind, beziehen sich auf die Hardware-Systemstruktur, das Vernetzungskonzept, die Ausgestaltung der Benutzeroberfläche, die Software-Systemstruktur, die Kommunikationsdienste und das Konzept der Datenhaltung; in Abb. 15 sind Angaben dazu zusammengestellt. Die Planungsvorgaben für die IuK-Infrastruktur müssen häufig auf „gewachsene Strukturen" Rücksicht nehmen, die bei Veränderungen oder Innovationen im Bereich der IuK-Unterstützung nur schwer oder nur sehr langwierig zu beseitigen sind. Solche „Eckdaten" für die Planung der IuK-Infrastruktur sind z. B. die „Offenheit" (Proprietät) von Hardware, Software und Netzen, Integrationskonzepte, Datenbanksysteme, Anwendungssysteme, Software-Entwurfsmethoden und -Umgebungen und nicht zuletzt die Mitarbeiterqualifikation.

26

3. Koordinationsfeld „ Strategische IuK-Planung "

Pro • • •

• • • •

flexible Nutzungsmöglichkeiten, flexible Ausbaufähigkeit, Effizienzsteigerung der Arbeit des Anwenders durch Integrationsverbund der Software, lokale Datenhaltung, Multi-MediaVerbund und ergonomische Benutzeroberflächen, flexible Portierbarkeit von Software, „offene" Systemstruktur, Möglichkeit zur schnellen Nutzung neuer Techniken und Systeme, niedrigere Hardware-Kosten.

Contra • • • • •

• •

•

Eignung für zeitkritische Massendatenverarbeitung, hohe Komplexität des Gesamtsystems (Vernetzung, Protokolle, Schnittstellen), Risiko permanenter Veränderung der Systemkomponenten und damit der Systemstruktur, Notwendigkeit für ein eigenes Netzwerkmanagement, Verlagerung ursprünglich zentraler DV-Funktionen in den Anwenderbereich (Systemadminstration, Datensicherung), niedriges Sicherheitsniveau, hohe Kosten für den Benutzerservice (Ausbildung, Beratung, Hotline- und Helpdesk-Dienste Wartung), Tendenz zu vergleichsweise steigenden Hardwarekosten bei zunehmender Anzahl von Datenendstationen.

Abb. 14: Argumentebilanz zu Client-Server-Systemkonzeptionen im Vergleich mit zentralen Systemkonzeptionen

3. Koordinationsfeld

„Strategische luK-Planung"

Hardware-Systemstruktur: - Plattformenkonzept, - Ebenen-Struktur, - Client-Server-Struktur; • Vernetzungskonzepte: - LAN-Strukturen, - WAN-Strukturen; • Benutzeroberfläche: - Arbeitsplatzaustattung mit Hardware, - Arteitsplatzausstattung mit individueller Software; • Software-Systemstruktur: - zentrale Anwendungssysteme, - dezentrale Anwendungssysteme; • Kommunikationsdienste: - Mailboxservice, - Netzangebote, - Service-Dienste; • Konzept der Datenhaltung: - Struktur und Umfang eines Untemehmensdatenmodells, - zentral gehaltene Datenbestände, - dezentral gehaltene Datenbestände, - verteilte Datenbestände, - Datenbanksysteme; • Software-Entwicklung: - Bereiche und Umfang der SW-Eigenerstellung, - Bereiche und Umfang des SW-Fremdbezuges, - Richtlinien und Infrastruktur für die SW-Eigenentwicklung; • Sicherheitskonzept: - für die Hardware, - für die Software, - für die Vernetzung und Kommunikation; • Gestaltung der Organisation: - interne Organisationsstruktur, - Eingliederung in die Organisationsstruktur der Unternehmung; • Planung der Personalentwicklung; • Budgetvorgaben. •

Abb. 15: Erforderliche Aussagen zur Planung der luK-lnfrastruktur

27

4. Koordinationsfeld

4. 4.1

„ Planung und Durchfiihrung von IuK-Projekten "

29

Koordinationsfeld „Planung und Durchführung von IuKProjekten" Controllingziele

Die Planung und Durchfiihrung von IuK-Projekten war und ist ein besonderer Schwachstellenbereich im Unternehmen, dessen Situation sich nicht selten durch folgende Sachverhalte beschreiben läßt: • Terminüberschreitungen, • Kostenüberschreitungen, • Diskrepanzen zwischen den vom Anwender erwarteten und den vom Projektteam realisierten Software-Leistungen. Die Ursachen dafür sind im wesentlichen Defizite in der Planung und Steuerung von Projekten sowie Defizite in der Mitwirkung der Anwenderseite und in der Unterstützung von Seiten der Unternehmensführung. Defizite in der Planung und Steuerung von IuK-Projekten resultieren z. B. aus • unklar formulierten Projektzielen, • falscher Einschätzung des Ressourcenbedarfs, • unzureichender Strukturierung der Aufgabenstellung, insbesondere aus unpräziser Definition der fachlichen Anforderungen, • unzweckmäßig gewählter Organisationsform des Pojektmanagements, • Mängeln in der Projektleitung wegen: - unzweckmäßigen Unterstellungsverhältnissen, - unzureichender Kompetenzausstattung, - unklarer Verantwortungsregelung, - mangelhaften Führungsqualitäten; • unzureichender Projektorganisation wegen: - des Verzichts auf ein Vorgehensmodell, - eines projektspezifisch ungeeignet gewählten Vorgehensmodells, - des Fehlens eines Projektstrukturplanes, - der Nichteinhaltung von „Meilensteinen" im Projektablauf, - des Fehlens oder wegen nicht stringent angewendeter Methoden und Werkzeuge für die Software-Entwicklung, - fehlender Leitlinien fur den Fremdbezug von Standard-Anwendungssoftware, - der Nichteinhaltung von Vorschriften über die Projektdokumentation; • unzureichender Projektsteuerung wegen - fehlender Abstimmung von Projektbudget, Projektterminen und Mitarbeitereinsatz, - zu locker gehandhabte Qualitäts-Reviews, - eines fehlenden oder zuwenig straff geführten Projekt-Berichtswesens.

30

4. Koordinationsfeld

„ Planung und Durchführung von IuK-Projekten "

Defizite in der Mitwirkung der Anwenderseite bei IuK-Projekten haben ihre Ursachen nicht selten • in einem unklaren Rollenverständnis der am Projekt Beteiligten, • in einer unklaren Verantwortungsregelung, • in Verständigungsproblemen aufgrund von unterschiedlicher Terminologie von Anwendern und Entwicklern sowie wegen der für die Anwenderseite nicht selten schwer nachvollziehbaren Entwurfs- und Dokumentationsverfahren. Defizite in der Unterstützung von Seiten der Unternehmensführung resultieren z. B. aus der Verkennung des Nutzungspotentials von IuK-Systemen, des Stellenwertes von Investitionen in eine zeitgemäße IuK-Infrastruktur für das eigene Unternehmen, aber auch aus Akzeptanzproblemen gegenüber Innovationen durch IuK-Systeme. Vor dem Hintergrund dieser Schwachstellen lassen sich die Controllingziele für das Koordinationsfeld „Planung und Durchfuhrung von IuK-Projekten" wie folgt formulieren: Projektbezogene Ziele: • Effektivität des Projektes: - Beitrag des Projektvorhabens zur Umsetzung der Unternehmensstrategie, - konsistente und begründete Projektdefinition; • Abstimmung des Projektes mit der mittelfristigen Projektportfolio-Planung, • konsistente und realistische Projektplanung, • Früherkennung von Planungsabweichungen, • Effizienz der Projektarbeit: - Termineinhaltung, - Kosteneinhaltung, - Funktionserfullung, - Einhaltung von Qualitätsvorgaben. Infrastrukturbezogene Ziele: • Schaffen der Voraussetzungen für ein effizientes Management von IuKProjekten, • Überwachung und Koordinierung des Managements von IuK-Projekten, • Schaffen der Voraussetzungen für eine effiziente Software-Eigenentwicklung, • Schaffen der Voraussetzungen für effiziente Auswahl und Einfuhrung von Standard-Software.

4.2 4.2.1

Management von IuK-Projekten Erfolgsfaktoren für IuK-Projekte

Zu den Kernaufgaben des Managements von IuK-Projekten zählen die Wahl der zweckgeeigneten Form der Projektorganisation (aufbauorganisatorischer Managementaspekt) und die Planung, Steuerung und Kontrolle der Projektdurchführung (ablauforganisatorischer Managementaspekt). Die Wirksamkeit der Erfüllung dieser Aufgaben und damit die des Projektmanagements ist von folgenden Erfolgsfaktoren abhängig:

4. Koordinationsfeld

„ Planung und Durchfiihrung von IuK-Projekten "

31

• klar definierte Projektziele, • fordernde, d. h. zur Leistung motivierende Aufgabenstellung, • sichtbare Unterstützung durch die Geschäftsführung bei Projekten von besonderer Tragweite, • durchdachtes und für die Projektmitarbeiter verständliches Konzept des Projektes, • Akzeptanz des Projektvorhabens bei Auftraggebern und bei Betroffenen, • kompetente und motivierte Projektmitarbeiter, • kompetenter und motivationsfähiger Projektleiter, • Kommunikation „auf kurzen Wegen" im Projektteam sowie zwischen Projektteam und Auftraggebern/Betroffenen, • realistische Zeitplanung, • sachgerechte Ablaufplanung, • bedarfsgerechte, auch an Eventualitäten orientierte Kostenplanung, • Projektfortschrittskontrolle mit adressatengerechtem Berichtswesen, • Management der Projektänderungen, • Auftragsmanagement bei Projekten mit vielen Zulieferern, • Krisenmanagement mit Eventualplänen für unerwartet auftretende Probleme, • effiziente Softwareentwicklungs- und -anpassungsinfrastruktur. Als Meßgrößen, durch die die Einhaltung oder Berücksichtigung dieser Erfolgsfaktoren bewertet werden kann, eignen sich die zentralen Kriterien zur Beurteilung der Projektdurchfuhrung: • realisierter Nutzenbeitrag, • benötigte Zeit, • verursachte Kosten. 4.2.2

Rollenverständnis der Projektpartner

Die Beteiligten an IuK-Projekten sind i. d. R. Anwender aus den Fachabteilungen, Analytiker und Entwickler aus dem IuK-Bereich sowie ggf externe Mitarbeiter (z. B Berater). Von besonderer Bedeutung ist hierbei die Partizipation der Anwenderseite: Die Anwender von zeitgemäßen IuK-Systemen sind nicht mehr nur „Sachmittelanwender" i. S. von traditioneller Datenverarbeitung zur Unterstützung isolierter operationaler Tätigkeiten, sondern sie sind integraler Bestandteil eines Mensch-Maschine-Interaktionssystems, das Träger der vielfältigen Aufgaben und Aufgabenprozesse im Unternehmen ist. Deshalb kommt dem Anwender die Rolle des aktiven Mitgestalters zu, der in die Projektarbeit sein fachspezifisches Wissen einbringen muß. Die aktive Mitgestaltung von IuK-Systemen durch deren zukünftige Anwender wird in der Praxis auch heute noch nicht als unabdingbar und selbstverständlich angesehen; die Folge eines solchen Verhaltens sind dann nicht selten Unstimmigkeiten oder Fehler in der Konzeption und im Entwurf von IuK-Systemen, die erst bei der Systemrealisierung oder gar erst im laufenden

32

4. Koordinationsfeld

„ Planung und Durchführung von IuK-Projekten "

Systembetrieb entdeckt werden, und die dann nur unter Inkaufnahme hoher Kosten beseitigt werden können. Für ein effizientes Management von IuK-Projekten ergibt sich deshalb als erste Grundvoraussetzung, daß sich die am Projekt Beteiligten ihres sachlich bedingten Rollenverständnisses bewußt sind: die Anwenderseite als Auftraggeber für IuK-Systeme in der Rolle des „Bauherren" und die Entwicklerseite als Auftragnehmer in der Rolle des „Architekten". Daraus resultieren folgende Verantwortungsfelder: • für den „Bauherren" die fachliche Verantwortung, konkretisiert durch: - die Entscheidung über die Nutzungsfelder der IuK-Unterstützung, d. h. über die anwenderrelevanten Projektziele, - die Vorgabe der fachlichen Systemanforderungen (anwenderseitige Projektspezifikation), - Begründung des erwarteten Nutzens des geplanten IuK-Systems, - Definition der Abnahmebedingungen für das zu entwickelnde IuK-System; • für den „Architekten" die Durchführungsverantwortung mit Beratungsfunktion, konkretisiert durch: - Beratung der Anwender über das Nutzungspotential von IuK-Systemen, - Durchführung von Situationsanalysen und Erarbeiten von Vorschlägen über IuKNutzungskonzepte, - Unterstützung der Anwender bei der Erstellung der fachlichen Systemanforderungen, - Beratung der Anwender über mögliche Konsequenzen von Systemvorgaben oder von Änderungswünschen, - Entwurf, Entwicklung und Realisierung von IuK-Systemen. Aus diesen Verantwortungsfeldern ergibt sich, daß die aktive Mitwirkung der Anwenderseite vorrangig in den frühen Phasen, aber auch in den Endphasen von IuK-Projekten erforderlich ist. 4.2.3

Projektteam

IuK-Projekte werden üblicherweise in Teamarbeit durchgeführt; die Wahl der problemadäquaten Organisationsform für ein solches Team ist eine weitere wesentliche Voraussetzung für ein effizientes Projektmanagement. Grundsätzlich lassen sich folgende Organisationsformen für Projektteams unterscheiden: • Arbeitskreis/Kommission, • Matrix-Projektorganisation, • reine Projektorganisation, • Projekt-Laboratorium. Bei der Organisation eines Projektteams in Form eines Arbeitskreises bzw. einer Kommission wird die Arbeitsgruppe aus Mitarbeitern des Unternehmens gebildet, die ihren angestammten

4. Koordinationsfeld „ Planung und Durchfiihrung von luK-Projekten "

33

Linieninstanzen voll unterstellt bleiben, und die sich der Projektarbeit temporär neben ihren eigentlichen Aufgaben in der Linie widmen. Aus dem Kreis der Mitglieder der Arbeitsgruppe wird ein Sprecher bestimmt, der die Projektarbeit koordiniert und Entscheidungen vorbereitet, aber selbst keine Entscheidungskompetenz hat; in der Rolle als „Primus inter pares" hat er zudem keine Weisungsbefügnis gegenüber den Mitgliedern des Projektteams. Bei der Organisationsform der Matrix-Projektorganisation werden die Teammitglieder aus ihren Linienfunktionen ebenfalls nur temporär für die Projektarbeit delegiert, jedoch weisungsgebunden in bezug auf die Projektarbeit. Dies wird durch einen Projektleiter erreicht, der gegenüber der Arbeitsgruppe die projektbezogene Weisungskompetenz besitzt; in disziplinarischer Hinsicht sind die Mitglieder des Teams ihren jeweiligen Linienvorgesetzten unterstellt. Die reine Projektorganisation ist dadurch gekennzeichnet, daß die Mitglieder des Projektteams für die gesamte Laufzeit des Projektes aus ihren Linientätigkeiten ausgegliedert und in einer ausschließlich projektbezogenen „temporären Abteilung" unter eigenständiger, fachlich und disziplinär weisungsbefugter Leitung tätig sind. Das Projekt-Laboratorium ist eine Mischform von Arbeitskreis/Kommission, Matrix-Projektorganisation und reiner Projektorganisation, jedoch mit dem besonderen Kennzeichen, daß es „offen" ist für die Mitarbeiter aus den Linienfünktionen. Die personelle Zusammensetzung ist den Organisationsformen Matrix-Projektorganisation und reine Projektorganisation ähnlich, jedoch mit dem Unterschied, daß i. d. R. nur die Mitarbeiter aus dem IuK-Bereich temporär oder dauerhaft in dem Projektteam gebunden sind, wohingegen die Mitarbeiter von der Anwenderseite sowie ggf. externe Spezialisten nur fallweise zur Projektarbeit herangezogen werden. Diese Organisationsformen sind Grundmuster für die Einbindung von Projektteams in die Organisation der Unternehmung; welche Form gewählt wird, hängt von folgenden Merkmalen eines Projektes ab: • Innovationscharakter, • Komplexität, • Strukturierung, • Integrationsbedarf, • Koordinationsbedarf, • Projektdauer, • Priorität, • Zeitdruck. Als Orientierungshilfe kann gelten: bei geringer Komplexität, guter Strukturierung, routinehaftem Charakter, geringem Koordinationsbedarf, kurzer Projektdauer und geringem Zeitdruck ist die Form Arbeitskreis/Kommission geeignet. Die reine Projektorganisation wird erforderlich bei hohem Zeitdruck, hoher Priorität, hohem Innovationscharakter und damit auch

34

4. Koordinationsfeld „ Planung und Durchführung von luK-Projekten "

i. d. R. hoher Komplexität und geringer Strukturierung. Die Matrix-Projektorganisation, die der praktischen Erfahrung nach die am häufigsten gewählte Organisationsform für IuKProjekte ist, ist im mittleren Bereich der Ausprägungen der o. a. Merkmale anzusiedeln. Das Projekt-Laboratorium eignet sich fiir Projekte von mittlerer bis langer Laufzeit, großer Komplexität und hohem Integrationsbedarf; es ist dann besonders zweckmäßig, wenn sich die Projektarbeit auf Prototyping abstützt oder das Evaluieren und Anpassen von hochintegrierter Standard-Anwendungssoftware zum Gegenstand hat. Für den Projektablauf kann es sinnvoll sein, diesen nicht ausschließlich unter einer einzigen Form der Teamorganisation durchzufuhren; so kann es z. B. zweckmäßig sein, die ersten Orientierungsschritte für ein IuK-Projekt einem Arbeitskreis bzw. einer Kommission zu übertragen und dann die weiteren Konzeptions- und Entwicklungsschritte in der strafferen Form von z. B. der Matrix-Projektorganisation oder der reinen Projektorganisation durchzufuhren. Neben der Wahl der geeigneten Organisationsform für das Projektteam ist die Regelung der Zusammenarbeit der Teammitglieder von besonderer Bedeutung; dies gilt insbesondere dann, wenn Projekte in Form der Matrix-Projektorganisation durchgeführt werden sollen. Das bewährte Instrument zur Regelung der Kooperation im Team ist die Verantwortungsmatrix, in der die Art der Mitarbeit der am Projekt Beteiligten, bezogen auf die einzelnen Abschnitte oder Phasen des Projektes, dokumentiert werden (Abb. 16). Zur Vermeidung von Unklarheiten oder Fehlinterpretationen über die erforderliche Zusammenarbeit ist eine solche Verantwortungsmatrix jeweils in der Vorplanung der einzelnen Projektabschnitte zu erstellen. Der nächste Planungsschritt ist die Entscheidung darüber, welcher Seite („Bauherren-Seite" oder „Architekten-Seite") die Projektleitung übertragen werden soll. Dazu gibt es grundsätzlich folgende Möglichkeiten, die sich aus dem schematisierten Verlauf des Umfanges der Verantwortung der beiden Seiten ableiten lassen (Abb. 17): • Projektleitung durch die Anwender-Seite, • Projektleitung durch die Entwickler-Seite, • geteilte Projektleitung. Eine Projektleitung durch die Anwenderseite läßt sich dadurch rechtfertigen, daß in den frühen Gestaltungsschritten von IuK-Projekten der fachlichen Verantwortung der Anwender eine herausragende Bedeutung zukommt, die dann im weiteren Verlauf der Projektarbeit zugunsten der Durchführungsverantwortung der Entwicklerseite in den Hintergrund tritt. Aus dieser Charakteristik des Verantwortungsverlaufes läßt sich deshalb gleichwertig argumentieren, daß die Projektleitung der Entwicklerseite übertragen werden kann, oder begündet durch den Schnittpunkt der Verantwortlungslinien, auch eine geteilte Projektleitung vertretbar ist In diesem Fall ist aber eine präzise „Schnittstellendefinition" der Verantwortungsübergabe, z. B. in Form einer vollständigen Dokumentation von Zwischenresultaten der Projektarbeit, unerläßlich. Praktischen Erfahrungen nach werden alle drei Möglichkeiten angewendet, jedoch mit unterschiedlichen Präferenzen aufgrund von unternehmensspezifischen Gegebenheiten. Nicht selten jedoch wird eine durchgängige Projektleitung durch die

4. Koordinationsfeld „ Planung und Durchführung von IuK-Projekten "

ProjektProjek^\P^ phase

n e r

1. Situationsstudie 2. Fachkonzeption 2.1 Anforderungsermittlung 2.2 Anforderungsspezifizierung

Entwickler-Seite

Benutzer-Seite

Auftrag- Betrof- Ent- Projekt- Fach- System- Systemgeber fene scheider ierter berater analytiker äntwickler P, A

M

K, E

P

M

—

—

K, E

M

!

P

M

A

—

3. Systemkonzeption 3.1 Entwurf des Programmsystems 3.2 Entwurf des Datensystems 3.3 Entwurf des Hardware-Systems 4. Systemrealisierung 4.1 Programmierung 4.2 Integration

P E A l< r\ M I

= = = —= =

Planung Entscheidung Ausführung Knntrnllp r\ui in une Mitwirkung Information

5. Systemanwendung 5.1 Installation 5.2 Wartung Abb. 16: Verantwortungsmatrix

Verantwortungsumfang

- Projektphasen Abb. 17: Schematische Verteilung der Projektverantwortung

35

36

4. Koordinationsfeld

„ Planung und Durchführung von IuK-Projekten "

Anwenderseite bevorzugt, denn dadurch wird ein besseres Akzeptanzverhalten bei den von IuK-Maßnahmen Betroffenen vermutet. Eine vierte Möglichkeit ist die Vergabe der Projektleitung an einen Außenstehenden (Berater); diese Variante ist dann angebracht, wenn z. B. nicht lösbare interne Konfliktsituationen bestehen oder intern die nötige Qualifikation fehlt. Nach der Entscheidung darüber, von welcher Seite der Projektleiter gestellt werden soll, ist die Entscheidung über die Person des Projektleiters zu treffen. Diese Entscheidung ist von großer Tragweite, denn eine ungeeignete personelle Besetzung dieser Funktion kann sehr schnell gleichbedeutend mit dem Scheitern des Projektvorhabens sein. Folgende Merkmale bilden das ideale Anforderungsprofil für die Qualifikation eines Leiters von IuK-Projekten: • • • • •

Fachkompetenz für die Projektaufgabe, projektübergreifende Fachkompetenz, Methodenkompetenz, Erfahrung in der Führung vonTeams, Fähigkeit zur Integration: - innerhalb des Projektteams, - zwischen den Ansprechpartnern des Projektteams; • Fähigkeit zur Querschnittskoordination, • situative Flexibilität, • Durchsetzungsfähigkeit. Die wichtigste Eigenschaft eines erfolgreichen Leiters von IuK-Projekten ist jedoch, daß er sich nicht ausschließlich als Administrator der ihm übertragenen Ressourcen oder als Koordinator divergierender Interessen sieht, sondern daß er sich als selbständiger „Unternehmer auf Zeit" versteht, für den der Projekterfolg, gemessen an ökonomischen Kriterien, die Leitmaxime seines Handelns ist. Um diese Rolle wahrnehmen zu können, ist der Projektleiter mit entsprechenden Kompetenzen auszustatten, so z. B.: • Repräsentanz des Projektes nach außen, • projektbezogene Weisungsbefugnis, nicht nur in bezug auf das Projektteam, sondern auch in bezug auf die Unternehmensbereiche, die in das IuK-Projekt involviert sind, • Recht auf projektbezogene Informierung durch die Bereichsund Unternehmensleitung, • Mitsprache bei der Formulierung der Projektziele, • Abgrenzung der Aufgabenstellung, • Mitsprache bei der Definition der Rahmenbedingungen für das Projekt, • Mitsprache bei der Definition der Abbruchkriterien („K.-o - Kriterien") für das Projekt, • projektbezogene Koordination, • Recht zur Delegation von projektbezogenen Aufgaben nach innen und außen, • uneingeschränktes Verfugungsrecht über das Projektbudget.

4. Koordinationsfeld „ Planung und Durchftihrung von IuK-Projekten " 4.2.4

37

Projektziele

Die Entwicklung von Zielvorstellungen ist der wichtigste Schritt für den Beginn eines IuKProjektes, denn wichtiger als die Suche nach einer geeigneten Lösung für anstehende Probleme ist zunächst die Bestimmung der richtigen Ziele. Werden unklare oder falsche Ziele vorgegeben, so besteht die Gefahr, daß irrelevante Sachverhalte als zu lösende Probleme angesehen werden. Ziele sind die Essenz von Projekten; sie haben die Funktion von Leitlinien für das Erarbeiten von geeigneten Mitteln zur Zielerreichung (Maßnahmen), und sie haben die Funktion von Kriterien für die Beurteilung von Maßnahmen hinsichtlich deren Eignung zur Zielerfüllung. Ziele lassen sich grundsätzlich unterscheiden in Sachziele und Formalziele. Sachziele beschreiben den Zweck eines IuK-Systems; dieser ist gleichzusetzen mit den geforderten Funktionen eines solchen Systems (Hilfsfrage: „Welche Funktionen soll das IuK-System erfüllen?"; die Funktion eines PPS-Systems ist z. B., eine belastungsorientierte Freigabe von Fertigungsaufträgen durchfuhren). Die beabsichtigte ökonomische Wirkung des Systemzwecks ist dadurch noch nicht ausgedrückt. Dies erfolgt duch die Formalziele, die die „Rationalität des Handelns" (Kosiol, 59) beschreiben, und die Ausdruck für die übergeordneten qualitativen Wirkungen sind, die von dem Zweck bzw. von den geforderten Funktionen eines IuK-Sytems ausgehen sollen (Hilfsfrage: „Welche übergeordneten Wirkungen soll die Funktionserfüllung haben?"; die Wirkung, die von der o. a. Funktion eines PPS-Systmes ausgehen soll, ist z. B. eine Reduzierung der Durchlaufzeiten). Formalziele rechtfertigen die Sachziele bzw. Funktionen, die von einem IuK-System geleistet werden sollen, aus ökonomischer Sicht; daher ist es wesentlich, daß für ein rational begründetes IuK-Projekt zuerst die Formalziele genannt werden, die dann den Rahmen für die Erarbeitung der Sachziele bilden. Für die praktische Projektarbeit sind Formalziele und Sachziele zweckmäßigerweise zu gruppieren in • Wirtschaftlichkeitsziele, • Systemleistungsziele, • Vorgehensziele, • Akzeptanzziele. Wirtschaftlichkeitsziele sind die Formalziele eines IuK-Projektes, sie werden z. B. formuliert als „Kosten reduzieren", „Zeiten reduzieren", „Kundenservice verbessern", „Marktpräsenz erhöhen". Systemleistungsziele sind die Sachziele bzw. die Funktionen, auf die hin ein IuK-System zu entwickeln ist oder die von einer auszuwählenden Standard-Software zu erbringen sind, damit die vorgegebenen Wirtschaftlichkeitsziele erreicht werden. Vorgehensziele repräsentieren die Soll-Vorgaben für die Projektdurchführung; so z. B. der gesetzte Zeitrahmen, die Form und Zusammensetzung des Projektteams, der geplante Ablauf, die einzusetzenden Entwicklungsmethoden und -Werkzeuge usw. Akzeptanzziele weisen die Richtung dafür, auf welche Art und in welchem Umfang die Bereitschaft der am Projekt Beteiligten und der vom Projekt Betroffenen zu gewinnen ist, sich mit dem Entwicklungsvorhaben zu identifizieren;

38

4. Koordinationsfeld „ Planung und Durchführung von luK-Projekten "

dazu zählen z. B. die Benennung derjenigen Gruppen, mit denen ein Konsens herbeizufuhren ist, das Ausmaß und die Toleranzbreite des Konsenses, die Planung des Mitteleinsatzes zur Akzeptanzförderung. Projektziele sind operational zu formulieren, denn sie sollen zu kontrollierbaren Handlungsvorgaben fuhren, und sie sollen darüber hinaus die Suche nach geeigneten Mitteln zur Zielerreichung (Maßnahmen) gezielt eingrenzen. Ziele können dann als operational gelten, wenn die Formulierung zumindest in den Zieldimensionen „Zielinhalt" und „Zielvorschrift" vorliegt (vgl. Kupsch). Der Zielinhalt beschreibt das Zielobjekt, z. B. „Lieferbereitschaft verbessern". Die Zielvorschrift präzisiert den Zielinhalt in bezug auf das angestrebte Ausmaß der Zielerreichung, z. B. „Lieferbereitschaft um 10% verbessern". Die dritte Zieldimension ist der zeitliche Bezug; dadurch wird die Fristigkeit der Zielformulierung ausgedrückt (z. B. „Lieferbereitschaft im nächsten Quartal um 10% verbessern"). Parallel zur Operationalisierung von Zielen sind diese in Ober- und Unterziele zu strukturieren, um daraus Ziel-Mittel-Ketten abzuleiten (Abb. 18a und Abb. 18b). Zielstrukturen dieser Art setzen Konformität oder Komplementarität der Einzelziele voraus. Bei Zielkonkurrenz oder bei Vorliegen von Präferenzen für Einzelziele sind diese durch Faktoren zu gewichten, wodurch die Bedeutung der Einzelziele untereinander relativiert wird; das Resultat ist dann eine gewichtete Zielhierarchie. Bei besonders ausgeprägten Präferenzen kann dann in Verbindung mit einer entsprechenden Zielgewichtung eine Unterscheidung in „Mußziele" und „Kannziele" vorgenommen werden. Projektziele werden sinnvollerweise durch das Herausarbeiten von kritischen Erfolgsfaktoren ergänzt. Frage: "Wozu dienen die Mittel?'

Frage: "Wodurch soll das Oberziel

Oberziel

Unterziele 1. Detaillier

Unterziele 2. Detaillier

Abb. 18a: Schema von Ziel-Mittel-Ketten

4. Koordinationsfeld

„ Planung und Durchführung von luK-Projekten "

39

Oberziel (OZ): "Liefertiereitschaft verbessern"

Unterziele (Detaillierungsstufe 1):

UZ 11:

Durchlaufzeit in der Fertigung um 20% reduzieren

UZ 12:

Durchlaufzeit für Fremdbezugsaufträge um 10% reduzieren

UZ 13:

Fertigprodukte und Teile bedarfskonform disponieren

UZ 14:

Bei Produkten der Kategorie A ist ein Servicegrad von 80% einzuhalten

Unterziele (Detaillierungsstufe 2):

UZ 24:

offene Bestellaufträge laufend überwachen

UZ 25:

Wareneingänge tagfertig den Lägern zuordnen

Abb. 18b: Beispiel einer Ziel-Mittel-Ketten (Zielhierarchie)

4.2.5

Vorprojekt

Das „Vorprojekt" stellt den Planungsschritt dar, der vor dem eigentlichen Projektbeginn liegt, und in dem wichtige Aussagen und Vereinbarungen zu treffen sind, die als Entscheidungsgrundlage für das Genehmigungsprocedere von Projekten dienen (s Abb. 19); diese Angaben sind formal in einem Projektvorschlag zu dokumentieren, der dadurch eine erste, grobe Projektdefinition darstellt. 4.2.6

Koordinierungsgremien

Eine wesentliche Aufgabe des Controlling besteht in der Koordination der einzelnen Projektvorhaben; dazu ist es zweckmäßig, in größeren Organisationen spezielle Koordinationsgremien zu schaffen. Typische Gremien dieser Art sind der Projekt-Koordinierungsausschuß und der Projekt-Lenkungsausschuß. Der Projekt-Koordinierungsausschuß, der i. d. R. aus Mitgliedern der Geschäftsleitung und aus den Leitern der Organisationsbereiche besteht (Abb.20), entscheidet über die Priorität der einzelnen Projektvorhaben, koordiniert diese nach fachlichen, personellen, finanziellen und terminlichen Aspekten, und entscheidet über die Annahme oder

40

4. Koordinationsfeld „ Planung und Durchführung von luK-Projekten "

•

•

• • • •

•

• • • •

Darstellung der Ausgangslage mit - Stärken/Schwächen, - Chancen/Risiken; Projektziele (ggf. als Muß-/Kannziele): - Wirtschaftlichkeitsziele, - Systemleistungsziele; kritische Erfolgsfaktoren, Rahmenbedingungen für das Projekt, Lösungsskizze, Wirtschaftlichkeitsbegründung: - geschätzte Kosten, - geschätzte Einsparungen, - erwarteter Nutzen; geplante Termine: - Projektabschnitte ("Meilensteine"), - Datum der Fertigstellung; zu erwartende Widerstände gegen das Projekt und in der Projektarbeit, involvierter Personenkreis, geplante Fremdvergaben, "K.-o." - Kriterien für das Projekt.

Abb. 19: Inhalt eines Vorprojektes (Projektvorschlag)

Abb. 20: Struktur der Koordiniemngsgremien für Projekte

4. Koordinationsfeld „ Planung und Durchflihrung von IuK-Projekten "

41

Ablehnung des Projektvorschlags; er ist die Instanz, die über das mittelfristige Projektportfolio bestimmt. Der Projekt-Lenkungsausschuß, der für größere Projekte mit langer Laufzeit zweckmäßig ist, nimmt Steuerungsaufgaben während der Projektdurchfuhrung wahr, dazu gehören Entscheidungen bei gravierenden Plan-Istabweichungen, deren Regelung über die Kompetenz des Projektleiters hinausgeht, sowie insbesondere Entscheidungen über gravierende Änderungen, über Problem- und Krisenfälle sowie grundlegende Personalentscheidungen.

4.3 Planung und Steuerung der Software-Eigenentwicklung 4.3.1 Projektplanung 4.3.1.1 Vorgehensmodelle Vorgehensmodelle sind Leitlinien für die Durchfuhrung von Projekten; sie strukturieren den Arbeitsverlauf am Projekt in sachlicher und zeitlicher Hinsicht. Für die Entwicklung von Anwendungssoftware lassen sich folgende Typen von Vorgehensmodellen unterscheiden: • • •

sequentiell strukturierte Modelle, parallel-sequentiell strukturierte Modelle, evolutionäre Modelle.

Sequentiell strukturierte Modelle, auch Phasenkonzepte genannt, folgen strikt dem Grundsatz der schrittweisen Verfeinerung des Entwicklungsvorhabens, welcher besagt, daß ein nachfolgender Projektabschnitt (Phase) immer eine weitere Verfeinerung des unmittelbar vorangehenden Abschnittes darstellt (Abb. 21). Damit die einzelnen Projektabschnitte bzw. Projektphasen schlüssig, d. h. sukzessive detailliert aufeinander aufbauen können, sind jeweils konkrete Phasenergebnisse („Meilensteine") zu definieren. Eine Folgephase kann nach diesem Vorgehensmodell erst dann begonnen werden, wenn die vorangegangene Phase vollständig abgeschlossen worden ist („Baseline-Konzept" oder Konzept des stufenweisen „Einfrierens" von Phasenvorgaben). •

Eignung: Vorgehensmodelle dieser Art eigenen sich für IuK-Projekte, die eine sehr präzise Aufgabenstellung zum Gegenstand haben, deren Entwicklungsumfeld im Zeitablauf stabil bleibt und die wenig Arbeitsteilung erfordern.

Parallel-sequentiell strukturierte Modelle sind dadurch gekennzeichnet, daß die Arbeitsschritte am Entwicklungsvorhaben innerhalb einer Projektphase und phasenübergreifend zeitlich versetzt („überlappt") durchgeführt werden, wodurch die zeitliche Fixierung auf ein bestimmtes Phasenresultat entfällt. Voraussetzung dafür ist, daß an Stelle „monolithischer" Meilenstein- oder Phasenergebnisse kleinere Leistungseinheiten in Form von z. B. Arbeitspaketen definiert werden können (Abb. 22). So läßt sich z. B. das Phasenergebnis „Anforderungsspezifizierung" unterteilen in die weitgehend verselbständigt zu bearbeitenden Arbeitspakete • •

fachliches Detailkonzept, Benutzerschnittstellen,

42

4. Koordinationsfeld „ Planung und Durchführung von IuK-Projekten " Entwicklungsebenen

Fach\/Meilenkonzeption / stein

System

/Meilens,eln

wicklung / «

System/MeBeninstallation 7 stein \

Zeit Abb. 21 : Phasenkonzept mit Meilensteinen für die Anwendungsentwicklung

Entwicklungsebenen AP31 9 AP1

o

AP21

AP5

1

1

;

4

1

API? 0

J

1

;

AP6

AP22 AP4 i

A P 2 3

Zeit Abb. 22: Phasenkonzept mit "Arbeitspaketen" (parallel-sequentiell strukturiert)

4. Koordinationsfeld „ Planung und Durchfiihrung von IuK-Projekten "

43

• organisatorische Rahmenlösung, • Konzeptbewertung. Vorgehensmodelle dieser Art erfodern eine detaillierte Phasenbeschreibung, so z. B. Angaben über: • Phasenmanagement (Zeitplan, Personaleinteilung, Zuständigkeiten), • Phasenergebnisse („Produktbeschreibung" der Arbeitspakete), • Aktivitäten („Arbeitsgänge" an den Arbeitspaketen), • Qualitätskontrolle („Qualitätsprüfung" der Phasenergebnisse), • Phasendokumentation (zu erstellende Dokumentation für das Projektmanagement). Wenn diese Angaben, insbesondere die Definition der Arbeitspakete, vorliegen, läßt sich ein Projektstrukturplan (Abb. 23) erstellen, der die Grundlage für die Projektdurchfuhrung bil-

X ! Situations- | \ !

Studie

I

Fach-

I

; konzeption !

System-

System-

j konzeption I

I entwicklung |

j

Abb. 23: Projektstrukturplan

I

]

System-

|

\ installation ]

44

4. Koordinationsfeld „ Planung und Durchführung von IuK-Projekten "

det. Da Vorgehensmodelle dieser Art aus zeitlicher und sachlicher Sicht eine Netzstruktur von Vorgänger-Nachfolgerbeziehungen der Arbeitspakete aufweisen, eignen sich zur Unterstützung der Ablaufsteuerung der Entwicklungsarbeiten Projektmanagementsysteme, die auf Netzplantechnik basieren. • Eignung: Parallel-sequentiell strukturierte Vorgehensmodelle entsprechen den Realitäten der Softwareentwicklung besser als sequentiell strukturierte Vorgehensmodelle, denn die Fixierung auf die Phasenzäsur entfällt, Änderungen im Entwicklungsumfeld können - in Grenzen - berücksichtigt werden und die Struktur dieser Modelle ist auf weitgehende Arbeitsteilung ausgelegt; von Nachteil ist allerdings der vergleichsweise erhöhte Koordinationsaufwand. Evolutionäre Modelle sind dadurch gekennzeichnet, daß auf eine Sequentialisierung der Entwicklungsschritte weitestgehend verzichtet wird, und daß statt dessen Riickspriinge auf zurückliegende Zwischenresultate und kontinuierliche Rückkopplung zwischen Anwendern und Entwicklern den Projektverlauf prägen. Grundlage dieser Art von Vorgehensmodellen ist das Prototyping, das die Softwareerstellung durch das Entwickeln von Prototypen, also von Mustern oder Modellen des zukünftigen Softwareproduktes unterstützt. Prototyping kann in folgenden Formen angewendet werden: • exploratives Prototyping, • experimentelles Prototyping, • evolutionäres Prototyping. Das explorative Prototyping wird als Spezifikationshilfe verwendet; das Interesse gilt hierbei vorrangig der fachlichen Funktionalität des Prototypen und weniger der softwaretechnischen Funktionalität. Diese Form des Prototyping eignet sich besonders zur Unterstützung der Entwicklung des Fachkonzeptes von Anwendungssoftware, weil dadurch die Benutzeroberfläche des zukünftigen IuK-Systems modellhaft und anschaulich abgebildet werden kann. Beim experimentellen Prototyping werden funktionsfähige „Baumuster" des zukünftigen Softwareproduktes entwickelt, um daran die softwaretechnische Realisierbarkeit von Anforderungen zu erproben. Das evolutionäre Prototyping trägt dem Sachverhalt Rechnung, daß die Anforderungen an IuK-Systeme während der Entwicklungszeit Veränderungen unterliegen oder daß, besonders bei hochintegrierten und innovativen IuK-Systemen, die Anforderungen zunächst nur „unscharf vorliegen. Die Prototypen, die auf dieser Basis entwickelt werden, sind Arbeitsmodelle, die sukzessive weiterentwickelt und verbessert werden, bis funktionsfähige Komponenten des gewünschten Softwareproduktes vorliegen. Prototyping kann im Entwicklungsprozeß von Software als Unterstützungshilfe punktuell eingesetzt werden; im Gegensatz dazu stellt das Spiralmodell von Boehm (Boehm [Spiral]) ein evolutionäres Vorgehenmodell dar: Grundlage ist ein phasenstrukturiertes Entwicklungskonzept, das spiralartig durchlaufen wird (Abb. 24). Jeder Spiraldurchlauf repräsentiert eine Phase und fuhrt zu einem Prototyp; dieser wird überprüft und modifiziert und bildet dadurch die Basis fur den nächten Phasendurchlauf, der zu einem verbesserten Prototyp fuhrt. Nach

4. Koordinationsfeld „ Planung und Durchführung von luK-Projekten "

45

Alternativen bewerten Risiken identifizieren und auslösen

Ziele, Alternativen, Randbedingungen festlegen

nächsten Schritt planen

Produkt der nächsten Stufe entwickeln und verifizieren

Abb. 24: Spiralmodell der Softwareentwicklung (Boehm, 23)

diesem Vorgehensmodell werden iterativ und unter Anwendung des evolutionären Prototypings jeweils Versionen der Softwareprodukte erzeugt, die von Version zu Version verbessert werden. Durch diese Vorgehensweise wird die „durchgängige" Planungsorientierung sequentiell und parallel-sequentieller Modelle zugunsten einer iterativ-rückgekoppelten Realisierungsorientierung betont; die Phasenstruktur bleibt aber als „Rückgrat" der Projektplanung erhalten. Ein anderes Konzept eines evolutionären Vorgehensmodells stellt das Drei-Ebenen-Modell (Kurbel, Dornhoff) dar: die Planung von Softwareentwicklungsprojekten wird zunächst ähnlich dem Prinzip der schrittweisen Verfeinerung und damit dem klassischen „WasserfallmodeH" der Projektplanung in drei Planungseben strukturiert (Abb. 25): • strategische Ebene (Gesamtplanung des Projektes nach Entwicklungsabschnitten),

46 •

4. Koordinationsfeld „ Planung und Durchfllhrung von luK-Projekten " taktische Ebene (Umsetzung der Entwicklungsabschnitte in Aufgaben und deren Zusammenhang),

•

operative Ebene (Konkretisierung und Strukturierung der Aufgaben in Aktivitäten).

Strategische Ebene Abschnitte

A ! !

;J

r Taktische Ebene Aufgaben A

Operative

i

Ebene

_

Aktivitäten J

Abb. 25: Drei-Ebenen-Modell der Softwareentwicklung (Kurbel/Dornhoff 112)

Das wesentliche Merkmal dieses Vorgehensmodells ist die geplante Rückkopplung unter den drei Planungsebenen und in den Aufgabenfeldern der jeweiligen Planungsebene (z. B. über Kommunikations-, Zwischenergebnis-, Endergebnis- und zeitliche Beziehungen), wodurch ein evolutionäres Vorgehen der Softwareentwicklung impliziert wird. •

Eignung: Evolutionäre Modelle eignen sich für komplexe, innovative und deshalb im voraus schwierig zu strukturierende IuK-Projekte sowie für Softwareentwicklungen, bei denen die Entwicklungsvorgaben Veränderungen unterliegen.

4.3.1.2

Spezifizierung der fachlichen Anforderungen

Ein kritischer Erfolgsfaktor von zentraler Bedeutung für die Effizienz der Eigenentwicklung von Anwendungssoftware ist die Vorgabe der fachlichen Anforderungen, denn diese bilden das Fundament der Entwicklungsarbeit. Das Postulat nach korrekt spezifizierten fachlichen Anforderungen (synonym: fachliches Pflichtenheft) existiert seit den Anfängen der Programmierung, aber es wurde und wird auch heute noch nicht mit der Sorgfalt erfüllt, die seinem hervorgehobenen Stellenwert im Prozeß der Softwareerstellung entspricht. Die Konsequenzen davon sind

4. Koordinationsfeld „ Planung und Durchfiihrung von luK-Projekten "

47

bekannt: kostenintensive Korrekturen an den Anwendungssystemen und verspätete Inbetriebnahme, weil Fehler, die im Entwurf gemacht wurden, erst bei der Realisierung des Systems entdeckt worden sind, bis hin zum Scheitern von Entwicklungsvorhaben wegen Unstimmigkeit der Projektvorgaben oder Ablehung wegen realisierter Lösungen, die nicht den Vorstellungen der Auftraggeber bzw. Anwender entsprechen. Um dies zu vermeiden, sind zwei Dinge zu beachten: die Anwenderpartizipation und korrekte fachliche Vorgaben. Ar.wendungssysteme repräsentieren im weitesten Sinne das Arbeitsumfeld der Mitarbeiter in den Fachabteilungen; deshalb ist es nicht nur naheliegend, sondern geradezu geboten, den Anwender in entsprechende Projektvorhaben miteinzubinden, und zwar nicht nur zu Zwecken der Information über die geplanten organisatorischen Veränderungen in seinem Arbeitsumfeld, sondern zur aktiven Mitgestaltung am Systemkonzept, um dadurch die fachlichen Anforderungen fundiert, d. h. ohne zusätzlich erforderliche Interpretation, definieren zu können, aber auch, um den Anwender in die Verantwortung für das Projekt miteinzubinden. Dazu ist es hilfreich, wenn dem Anwender das Rollenverständnis als „Bauherr" einer Anwendungsentwicklung bewußt ist, und wenn dessen Mitarbeit im Projekt einer formalen Regelung, z. B. du. :h Anwendung einer Verantwortungsmatrix, unterliegt. Fachliche Vorgaben beschreiben die Leistungen, die von einem Anwendungssystem aus der Sicht der Anwender zur Unterstützung von deren Aufgaben im Unternehmen zu erbringen sind, und sie sind gleichzeitig die Grundlage für den Entwurf des Programmsystems und des Datenhaltungssystems. Deshalb gelten fachliche Vorgaben dann als vollständig spezifiziert, wenn sie diesen beiden Sichtweisen gerecht werden; Abb. 26 enthält das Anforderungsprofil einer solchen Fachspezifikation von Anwendungssystemen. Fachspezifikationen dieses Detaillierungsgrades sind i. d. R. besonders dann möglich, wenn das Entwicklungsvorhaben sich auf Anwendungssysteme zur Unterstützung operationaler Aufgaben im Unternehmen bezieht. 4.3.1.3 Software-Entwurfsumgebungen Die Entwicklung von Softwaresystemen, insbesondere die von Anwendungssystemen, ist mit einer Vielzahl von Problemen verbunden; diese beginnen bei der korrekten Spezifizierung der fachlichen Anforderungen und setzen sich fort über die zweckmäßige Zerlegung des zu entwerfenden Gesamtsystems in Teilsysteme, die Koordination der Teilsystemerstellung, die Abstimmung der Teilsysteme aufeinander, den Test der Teilsysteme, die Integration der Teilsysteme und den Integrationstest, die Implementierung zum laufenden Betrieb bis hin zu den Forderungen nach Zuverlässigkeit, Änderbarkeit, Übertragbarkeit und Wiederverwendung sowie nach einer entwicklungsbegleitenden, vollständigen Dokumentation. In Ansehung dessen und unter Berücksichtigung, daß sich die Softwareerstellung, so wie andere Produktionsprozesse schon von jeher, auch an Effizienzkriterien messen lassen muß, kommt der Art und Weise, wie diese Software erstellt wird, ein hoher Stellenwert zu.

48

4. Koordinationsfeld „ Planung und Durchflihrung von luK-Projekten"

• • •

•

•

•

• • •

•

Beschreibung des Geschäftsprozesses Schnittstellen des Geschäftsprozesses zu anderen Geschäftsprozessen Funktionsmodell - statische Funktionsstruktur (fachlicher Funktionsbaum) - dynamische Funktionsstruktur (fachliches Prozeßmodell / Vorgangsketten) Funktionsbeschreibung - benutzerrelevanter Output - benutzerrelevanter Input - fachliche Verarbeitungsvorschrift Informationsmodell (fachliches Datenmodell) - Informationsobekttypen / Entity-Typen - Beziehungstypen - Attribute - Primär-, Sekundärschlüssel, - fachliche Integritätsbedingungen Benutzerschnittstelle - Maskenlayout - Listenlayout Dialogstruktur Anforderungen an Datenschutz und Datensicherheit Leistungsangaben • Bewegungsdaten - Stammdaten - Anzahl gleichzeitiger Dialog-Anwender fachliche Testfälle

Abb. 26: Anforderungsprofil einer Fachspezifikation für DV-Anwendungssysteme

Die Palette an Prinzipien, methodischen Ansätzen, Methoden, Werkzeugen und Werkzeugsystemen zur Softwareerstellung ist breit gefächert; deshalb ist durchaus die Möglichkeit gegeben, die Vorgehensweise dazu nach individuellen Präferenzen zu gestalten. Sachverhalte dieser Art sind in der Praxis nicht selten anzutreffen, und sie werden damitbegründet, daß das Rationalisierungspotential im Vorfeld der Programmerstellung erheblich höher sei als in der Programmerstellung selbst - insbesondere dann, wenn methodenerfahrene Softwareentwickler in langjährigem Einsatz sind. Auffassungen dieser Art mögen aus dem Kontext von Unternehmens- und mitarbeiterspezifischen Gegebenheiten gerechtfertigt sein; als generelle Regelung für die Art und Weise der Softwareerstellung sind sie nicht geeignet. Die Forderungen nach Änderbarkeit, Übertragbarkeit und Wiederverwendung von Software sowie insbesondere die Forderung nach Schnittstellenkompatibilität zu anderen Softwaresystemen (z. B. Anbindung an Standard-Anwendungssoftware) bedingen, daß die Softwareentwicklung sich an dem Grundsatz der Verfahrensstandardisierung orientieren muß. Der geeignete Weg dazu ist der Einsatz von computerunterstützten Software-Entwurfsumgebungen oder CASE-Systemen (CASE: Computer Aided Software Engineering). Systeme dieser Art dienen zur Unterstützung des Prozesses der Softwareerstellung; sie beinhalten Entwurfshilfen für die einzelnen Schritte

4. Koordinationsfeld „ Planung und Durchflihrung von IuK-Projekten "

49

der Systementwicklung. Die wichtigsten Komponenten eines CASE-Systems sind die Entwicklungsdatenbank und die Entwicklungshilfen. Die Entwicklungsdatenbank („Repository") enthält alle projektrelevanten Daten der Komponenten von Anwendungssystemen (z. B.Projekt, Funktion, Informationsobjekt/Entity, Datenelement, File, Programm-Modul, Bildschirmmaske, Liste etc.) sowie die Beziehungen der Komponenten untereinander; sie repräsentiert gewissermaßen die „Stücklisten" der Anwendungssysteme bzw. den „Teileverwendungsnachweis" der Systemkomponenten, dokumentiert über die verschiedenen Entwicklungsstadien hinweg. Die wesentlichen Funktionen sind deshalb die Verwaltung der Entwicklungsdokumente, die Verwaltung der Systemkonfigurationen und die Verwaltung von Entwurfs- und Systemversionen. Die Entwicklungshilfen („Werkzeuge", „Toolbox") dienen zur Erarbeitung der einzelnen „Zwischenprodukte" eines Softwaresystems. Von zentrale Bedeutung ist hier, welche Entwurfsmethoden durch die Werkzeuge unterstützt werden; dies können fiinktionsorientierte, datenorientierte oder objektorientierte Methoden sein. Funktionsorientierte Methoden beruhen auf der schrittweisen hierarchischen Zerlegung des Entwurfsobjektes in Teil- und Unterfunktionen, und für jede Funktion werden die Ausgabedaten und die zugehörigen Eingabedaten definiert, wobei diese Daten lediglich in bezug auf die jeweilige Funktion betrachtet werden. Funktionsorientiertes Entwerfen ist immer unter zwei Aspekten zu sehen: einem statischen und einem dynamischen. Der statische Aspekt bzieht sich auf den strukturellen Aufbau des Softwaresystems, dargestellt z. B. durch einen Funktionsbaum. Funktionen enthalten auch eine Ablaufsteuerung, die z. B. die Reihenfolge der einzelnen Funktionen sowie Alternativen in der Abfolge und deren Auswahlbedingungen festlegt. Daher ist zusätzlich zum Funktionsbaum der Steuerfluß zu erarbeiten, der den dynamischen Aspekt des funktionsorientierten Entwerfensdarstellt. Zur Dokumentation des Steuerflusses eignen sich Flußdiagramme wie z. B. Prozeßdiagramme, Datenflußdiagramme, Programmablaufpläne oder Struktogramme. Datenorientierte Methoden wählen konträr zu den funktionsorientierten Methoden als zentralen Ansatz die Daten des Entwurfsobjektes. In einem ersten Schritt wird die logische Datenstruktur ermittelt, was einer Betrachtung des Entwurfsobjektes unter statischem Aspekt entspricht; die Vorgehensweise hierzu liefert das Entity-Relationship-Modell. Im zweiten Schritt werden den Daten die zugehörigen Funktionen zugeordnet; diese Verbindung von Daten und Funktionen resultiert aus der Analyse der Verarbeitungserfordernisse für die Daten sowie aus der Ermittlung des erforderlichen Datenflusses. Objektorientierte Methoden wählen einen Ansatz, der zunächst Ähnlichkeiten mit den datenorientierten Methoden hat: das zu entwerfende Softwaresystem wird als eine Menge von Objekten gesehen, die untereinander in Beziehung stehen. Die wesentlichen Unterschiede zu den datenorientierten Methoden und zu sämtlichen anderen Softwareentwurfsmethoden bestehen in der Datenkapselung, der Klassenbildung, der Vererbung und der Kommunikation über

50

4. Koordinationsfeld „ Planung und Durchführung von IuK-Projekten "

Nachrichten. Durch Datenkapselung werden Objekte geschaffen, die mit ihren Attributen und den darauf wirkenden Operationen eine Einheit bilden. Objekte von potentiell gleicher Struktur und gleichem Verhalten werden in Objektklassen zusammengefaßt; die Beschreibung einer Klasse liefert dann den „allgemeinen Strukturplan" für die verschieden möglichen Objektausprägungen dieser Klasse (Bildung von Unterklassen). Durch Vererbung werden die Eigenschaften von Objektklassen, d. h. deren Daten und Operationen, auf Unterklassen und einzelne Objektausprägungen übertragen. Zusätzlich zu den ererbten Eigenschaften können jeweils neue Daten und Operationen definiert werden, wodurch sich die Funktionalität von Unterklassen oder einzelnen Objektausprägungen gegenüber den Oberklassen erhöht. Objektorientiert entworfene Software bedarf allerdings auch eines Steuerungsflusses, der die Kommunikation der Objekte untereinander regelt; diese Kommunikation erfolgt jedoch nicht auf Grundlage eines vorher festgelegten „Datenflußplanes", sondern durch Nachrichtenaustausch zwischen den Objekten. Diese Form der Kommunikation wird notwendig, weil die Objekte gekapselte, d. h. autonome Einheiten darstellen, die definierte Dienste zur Verfügung stellen, und die nur über ihre Schnittstellen manipulierbar sind. Diese Dienste können mit Hilfe von Nachrichten abegrufen und von anderen Objekten genutzt werden; der Versand einer Nachricht ist also gleichbedeutend mit der Nutzung der Dienstleistung eines bestimmten Objektes. Die genannten Entwurfsmethoden und ihre entsprechende Werkzeugunterstützung sind wie folgt kurz zu werten: Funktionsorientierte Entwurfsmethoden sind die traditionellen Entwurfsmethoden, die zu einer einfachen und übersichtlichen funktionalen Struktur des Softwaresystems fuhren. Von Nachteil sind die weniger transparenten Steuerungsflüsse und insbesondere die Datenstrukturen, denn diese werden fünktionsbezogen entworfen und sind deshalb zwangsläufig redundant und programmabhängig; so konzipierte Softwaresysteme sind kaum zur Integration geeignet. Datenorientierte Methoden vermeiden diese Nachteile, denn das Datenmodell, das den entsprechenden Softwaresystemen zugrunde liegt, und insbesondere dessen Realisierung in Form von relationalen Datenbanken, bietet hohe Flexibilität für die Integration von Softwaresystemen und für allfällige Systemänderungen. Objektorientierte Methoden bieten zusätzlich zu diese Vorteilen noch den wesentlichen Vorteil der Wiederverwendbarkeit von Softwarekomponenten, wodurch die Effizienz der Softwareentwicklung erheblich verbessert wird. Neben den Entwicklungshilfen, die die genannten Methoden unterstützen, sind in CASESystemen weiter Werkzeuge zum Entwurf von Bildschirmmasken und von Dialogabläufen vorhanden, sowie Werkzeuge, die zur unmittelbaren Programmerstellung dienen; es sind dies neben den herkömmlichen Programmiersprachen der 3. Generation und ihren Compilern die 4GL-Sprachen und Programmgeneratoren, die Pseudocode oder den Programmcode für die Hardwareplattformen erzeugen, auf denen das Softwaresystem eingesetzt werden soll. Für die Beurteilung einer Software-Entwurfsumgebung ist es weniger bedeutend, wieviel unterschiedliche Werkzeuge in der „Toolbox" enthalten sind, als vielmehr, ob diese Werkzeuge einen Werkzeugverbund bilden. Ein solcher Verbund ist dann gegeben, wenn die für einzelnen Entwicklungsschritte spezifisch benötigten Werkzeuge vorhanden sind (z. B. Funkti-

4. Koordinationsfeld

„ Planung und Durchfiihrung von luK-Projekten "

51

onsstrukturierung für die Fachspezifikation, Datenmodellierung für den Systementwurf, Generierung von Pseudocode für den Programmentwurf und Testhilfen für den Modultest) und die damit erstellten Zwischenstadien des Softwaresystems schlüssig und weiterführend aufeinander aufbauen; unabdingbare Voraussetzung dazu ist, daß jedes Werkzeug des Werzeugverbundes Zugriff zur Entwicklungsdatenbank hat. Weitere Beurteilungsfaktoren sind die Gestaltung der Benutzerschnittstelle (z. B. benutzerfreundliche Gestaltung der grafischen Bildschirmoberfläche, einheitlich über die Nutzung der verschiedenen Werkzeuge), die Erweiterbarkeit durch neue Werkzeuge („Tool-Slots"), die Offenheit (es können Ergebnisse in bezug auf unterschiedliche Betriebssystem- und Hardwareplattformen produziert werden), die Mehrprojektfähigkeit, die Teamfähigkeit und die Portabilität. Durch die Nutzung von Sofware-Entwurfsumgebungen dieser Art wird gewissermaßen eine Standardisierung der Vorgehensweise zur Softwareentwicklung, der Ergebnisse und Zwischenergebnisse sowie der entwurfsbegleitenden Dokumentation erzwungen - ein Sachverhalt, der der geforderten Effizienzsteigerung in diesem Bereich nicht abträglich ist. 4.3.1.4 Termin- und Kostenplanung Die Planung von Terminen und damit auch von Kosten eines IuK-Projektes ist abhängig von den Anforderungen, die an das IuK-System gestellt werden, von der Projektgröße, von der fachlichen Qualität der Projektmitarbeiter, von den Arbeitsbedingungen, unter denen dieses Projektgeplant, entwickelt und realisiert wird, und von der Qualität der Projektleitung. Da diese Einflußfaktoren sehr heterogen sind und in ihren Ausprägungen von Projekt zu Projekt stark variieren können, lassen sich nur schwer konsistente Meßgrößen finden, auf deren Grundlage ein fundiertes Kalkulieren des Zeitaufwandes i. S. einer Vorgabezeitermittlung, gestützt auf Rüstzeiten und Ausfiihrungszeiten, möglich wäre. Auch das Sammeln von Erfahrungen, die die Grundlage fiir das Ermitteln von Projektzeiten sein können, wird erschwert: Die Eigenentwicklung von Software ist vergleichbar mit dem Leistungstyp „Einzelfertigung" der industriellen Produktion, bei der sich der Ressourceneinsatz wegen der geringen Wiederholungshäufigkeit des Leistungstyps nur sehr beschränkt aus Erfahrungswerten kalkulieren läßt. Erfahrungen, die sich als Basis für das Kalkulieren des Ressourcenverbrauchs eignen, lassen sich eher bei dem Leistungstyp der „Serienfertigung" sammeln; der ist aber im Bereich von Software vorzugsweise bei Softwarehäusern und weniger bei Anwendern anzutreffen. Als Konsequenz dessen ergibt sich, daß sich die Planung von Terminen und Kosten von IuKProjekten mit Schätzverfahren begnügen muß. Folgende Verfahren können Verwendung finden: • Multiplikatorverfahren, • Produktivitätsverfahren, • Analogieverfahren, • Top-down-Verfahren, • Bottom-up-Verfahren,

52

4. Koordinationsfeld „ Planung und Durchfiihrung von luK-Projekten "

• Function-Point-Verfahren, • Object-Point-Verfahren. Das Multiplikatorverfahren beruht auf der Nachkalkulation abgeschlossener Softwareprojekte und auf den Erfahrungen über die Größe von Programmen, ausgedrückt in Anzahl der Programmanweisungen: die insgesamt angefallenen Projektkosten werden durch die Anzahl der erstellten Programmanweisungen („Lines of Code") dividiert; die daraus gewonnene Kennzahl K (Kosten je Programmanweisung) wird wie folgt zur Kostenschätzung verwendet: • Schätzen der Anzahl der Programmanweisungen (A) des geplanten Softwareproduktes, • Multiplikation A x K = geschätzte Gesamtkosten (G) des Softwareprojektes. Grundlage des Produktivitätsverfahrens ist die Produktivitätskennzahl P (erstellte Programmanweisungen pro Arbeitsstunde). Diese wird aus der Nachkalkulation abgeschlossener Softwareprojekte ermittelt, indem die Anzahl der erstellten Programmanweisungen durch die Anzahl der dazu erforderlichen Arbeitsstunden dividiert wird. Die Schätzung der Projektkosten wird damit wie folgt durchgeführt: • Schätzen der Anzahl A der Programmanweisungen des geplanten Softwareproduktes, • Errechnen der erforderlichen Personalkapazität (PK) in Stunden durch Division A : P, • Errechnen der Projekt-Gesamtkosten durch Multiplikation PK x S (S = Personal-Stundensatz). Beim Analogieverfahren werden die Kosten für ein neues Softwareprojekt durch Vergleich mit abgeschlossenen Softwareprojekten anhand von Ahnlichkeitskriterien ermittelt; solche Ähnlichkeitskriterien sind z. B. Anwendungsgebiet, Programmiersprache, Programmgröße, Programmkomplexität (z. B. Anzahl der Schnittstellen, Anzahl der Moduln, Modulverknüpfung), Struktur der Datenorganisation, Gestaltung der Benutzeroberfläche, Projektgröße in Anzahl der Mitarbeiter-Monate. Zur Durchfuhrung von Vergleich und Analogieschluß werden die nicht unmittelbar quantifizierbaren Ähnlichkeitskriterien mit Indexwerten gewichtet. Beispiel:

Merkmale des neuen Softwareprojektes: Programmgröße 20.000 Anweisungen Programmkomplexität : 8 Punkte Datenorganisation 4 Punkte Merkmale und Kosten eii s ähnlichen, abgeschlossenen Softwareprojektes: 24.000 Anweisungen Programmgröße 6 Punkte Programmkomplexität : 6 Punkte Datenorganisation 700.000 DM Gesamtkosten

4. Koordinationsfeld „ Planung und Durchfiihrung von luK-Projekten " Relativierung der Unterschiede: Programmgröße Programmkomplexität Datenorganisation

neu 1 1 1

alt/neu 1,20 0,75 1,50

Punktesumme

3

3,45

53

(24:20 = 1,20) (6:8 = 0,75) (6:4 = 1,50)

Analogieschluß: G = 700.000 x (3/3,45) = 608.695 DM (Kostengewichtung mit einer „Äquivalenzziffer") Bei dem Top-down-Verfahren wird das Softwareprojekt hierarchisch durch fortschreitendes Spezifizieren so lange dekomponiert, bis eine Ebene erreicht wurde, auf der plausible Zeitschätzungen für die einzelnen Komponenten möglich werden. Die Addition dieser Zeiten, bewertet mit einem Personal-Stundensatz S, ergibt die geschätzten Projekt-Gesamtkosten. Bei dem Bottom-up-Verfahren wird die Zeitschätzung auf der Grundlage einer repräsentativen Teilmenge des gesamten Softwareprojektes durchgeführt. Dazu sind folgende Schritte zu durchlaufen: • Bestimmung der repräsentativen Teilmenge, • Bestimmung des Faktors (F), der das Verhältnis der Teilmenge zum gesamten Softwareprojekt kennzeichnet, • Dekomposition der repräsentativen Teilmenge in Komponenten, die eine plausible Zeitschätzung gestatten, • Zeitschätzung für die Teilmenge, • Hochrechnung der geschätzen Zeiten für die Teilmenge zur geschätzten Gesamtzeit des Projektes, • Bewerten der Projekt-Gesamtzeit mit dem Personal-Stundensatz. Das Function-Point-Verfahren (Albrecht) trägt dem Sachverhalt Rechnung, daß der Zeitaufwand für die Entwicklung von Anwendungssoftware vorrangig vom Funktionsumfang des geplanten Anwendungssystems, von dem Schwierigkeitsgrad der einzelnen Funktionen und von Einflußfaktoren aus dem Umfeld der Projektarbeit und der Softwareentwicklung abhängig ist. Der Grundgedanke dieses Verfahrens besteht darin, die Anforderungen an ein Softwareprojekt sukzessive bis auf die Ebene von Funktionen („Functions") zu zergliedern, diese je nach Schwierigkeitsgrad für deren Realisierung mit Gewichtsfaktoren („Function Points") zu bewerten und anschließend mit der Anzahl der Ausprägungen je Funktion zu multiplizieren. Das Resultat, aufsummiert über die spezifizierten Funktionen des Anwendungssystems, wird auf eine Erfahrungskurve bezogen, aus der sich der dazu entsprechende Zeitaufwand ablesen läßt. Die Schrittfolge dazu im einzelnen lautet wie folgt: • Ermittlung der Funktionen des Anwendungssystems Top-down aus den Projektvorgaben, • Bewertung der Funktionen nach dem Schwierigkeitsgrad für deren Realisierung (Klassifikation für den Schwierigkeitsgrad: „einfach", „mittel", „schwer") mit Ge-

54

4. Koordinationsfeld

„ Planung und Durchßihrung von IuK-Projekten "

wichtsfaktoren („Function Points"); diese dimensionslosen Faktoren sind Erfahrungswerte der Praxis, •

Ermitteln der Anzahl der Ausprägungen je Funktion und Multiplikation mit den Function Points, • Aufsummieren über sämtliche Funktionen; das Resultat sind die „ungewichteten Function Points" (El in Abb. 27), • •

Korrektur der Summe der ungewichteten Function Points mit den Einflußfaktoren (E2 und E3 in Abb. 27), Analogieschluß von den so gewichteten Function Points über eine Erfahrungskurve zu dem zu erwartenden Zeitaufwand (Abb. 28).

Funktionstyp Eingabe

Anzahl

Function Points e 2 rn 4 s 6

x...

Ausgabe

e m s

2 5 8

x...

Datei

e m

x...

s

5 10 15

Referenz

e m s

6 11 20

x ...

Abfrage

e m

3 4 6

x...

s

Gesamt

E i = Summe (ungewichteter) Function Points E2= Summe Einflußfaktoren Eß= Bewertungsfaktor: 0,70 +

^

( 0 , 7 0 < E 3 < 1,3) Bewertete Function Points: E - | X E ß

Abb. 27: Bewertungsschema nach dem Function-Point-Verfahren

Als Funktionen i. S. des Function-Point-Verfahrens werden z. B. verstanden: • Eingabefünktionen: - Dateneingabe im Dialog, - Dateneingabe im Stapelbetrieb, - Dateneingabe über Schnittstellen zu anderen Systemen; • Ausgabefünktionen: - Bildschirmausgaben, - Listenausgaben,

4. Koordinationsfeld „ Planung und Durchfiihrung von IuK-Projekten "

55

- Formularausgaben, - Stapelausgaben auf Dateien, - Schnittstellen-Ausgaben; • DateifUnktionen, • Referenzfunktionen: - Zugriff auf Tabellen, - Zugriff auf Read-only-Dateien; • Abfragefunktionen: - On-line-Abfragen ohne Verarbeitungsfünktionen, - On-line-Abfragen mit Verarbeitungsfunktionen.

Function

Function Points

Function Points gesamt 4000 - ,

3000

2000

1000 -

100

200

300

400

500

IS-Mannmonate

IS-MM

Points

IS-MM 85

50

5

1100

100

8

1200

94

150

11

1300

103

200

14

1400

112

250

17

1500

122

300

20

1600

132

350

24

1700

142

400

28

1800

153

450

32

1900

164

500

36

2000

175

550

40

2100

188

600

44

2200

201

650

48

2300

2152

700

52

2400

30

750

56

2500

245

800

60

2600

263

850

64

2700

284

900

68

2800

307

950

72

2900

341

1000

76

Abb. 28: Erfahrungskurve zum Function-Point-Verfahren (Seibt, D.,[1987], S.8)

Um die Funktionen nach ihrem Schwierigkeitsgrad klassifizieren zu können, sind diese inhaltlich näher zu präzisieren; in den Abbildungen 29 und 30 sind ausschnittsweise Beispiele dazu dargestellt. Den einzelen Schwierigkeitsklassen werden die Function Points zugeordnet, die je nach Funktionstyp Werte von 1-20 betragen können (Abb. 27).

56

4. Koordinationsfeld „ Planung und Durchfiihrung von luK-Projekten "

Schwierigkeitsgrad Anforderungen einfach

mittel

schwer

1 - 5

6 - 10

> 10

Dateneingabeprüfung

nur Wertprüfung alphanumerisch

Plausibilitätsprüfung lokal

Plausibilitätsprüfung mit DB-Zugriff

Maskenaufbau

Standard-Format

angepaßtes Format

individuelles Format

Maskenblättern

kein

vorwärts

vorwärts und rückwärts

Bedienerführung

Standard-Menü

Funktionstasten

cursor-abhängig window-unterstützt

Standard

Lang-Fehlertext

Handlungsaltemativen

Anzahl Datenfelder

Fehlerbehandlung

Abb. 29: Schwierigkeitsklassifizierung einer Bildschirmeingabe

Schwierigkeitsgrad Anforderungen einfach

mittel

schwer

bereits vorhanden

vorhanden, ergänzt

neu zu konzipieren

1 - 15

16 - 50

> 50

Anzahl Zugriffspfade

1 - 2

3 - 5

> 5

Anzahl Read

1 - 3

4 - 6

> 6

Anzahl Update

1 - 2

3 - 4

> 4

Gruppenwechsel

keine

1 - 2

> 2

Sortierung

keine

einfach sequentiell

verschachtelt sequentiell

Sicherheit

Zugriffssperre Datei

Zugriffssperre Datensätze

Zugriffssperre Datenfelder

Existenz Anzahl Datenfelder

Abb. 30: Schwierigkeitsklassifizierung der Dateifunktion

4. Koordinationsfeld „Planung und Durchführung von luK-Projekten"

57

Als Einflußfaktoren aus dem Umfeld der Projektarbeit und der Softwareentwicklung können berücksichtigt werden: • die Mitwirkung des Anwenders, • der Umfang der erforderlichen Anwenderschulung, • die Komplexität des Anwendungssystems, • Fachkenntnisse und praktische Erfahrung mit dem Entwicklungsgegenstand, • die Schnittstellen zu anderen Anwendungen, • geforderte Antwortzeiten, • geforderte Transaktionsrate, • Systemumgebung: - Betriebssystem, - TP-Monitor; • Portabilitätserfordernisse. Die Bewertung der Einflußfaktoren erfolgt nach einer Skala von 0-5, um dadurch die subjektiven Einschätzungen über den projektspezifischen Stellenwert der einzelnen Faktoren (z. B. 0 = kein Einfluß, 5 = sehr starker Einfluß) zu quantifizieren. Das Object-Point-Verfahren (Oriolo) ist dem Function-Point-Verfahren ähnlich; auch hier werden die Projektvorgaben sukzessive spezifiziert, bis eine plausible Grundlage für die Zeitschätzung erarbeitet worden ist. Diese Grundlage wird durch folgende Schätzobjekttypen gebildet: • • •

Bildschirmmaske, Druckausgabe, Informationsobjekt,

• Datentransfer und Verarbeitung.? funktion. Jedes Schätzobjekt wird durch die Angabe spezifischer Ausprägungen näher beschrieben (z. B. für das Schätzobjekt „Bildschirmmaske" - s. Abb. 31 - die Spalte „Anforderungen" in Abb. 32); jeder Ausprägung ist ein dimensionsloser Gewichtungsfaktor zugeordnet (Spalte „Formel" in Abb. 32), der den „Object Point" darstellt. Die Bewertung erfolgt dadurch, daß die projektspezifische Anzahl der Ausprägungen je Schätzobjekt ermittelt wird (Spalte „Wert" in Abb. 32) und mit den Object Points multipliziert wird (Spalte „Ergebnis" in Abb. 32). Einflußfaktoren, die sich aufwandssteigernd auf das Softwareprojekt auswirken können, werden durch Zuschläge auf die Gesamtsumme der Object Points berücksichtigt (Abb. 33). Der Transfer von den so ermittelten Object Points in eine Zeitaussage erfolgt über eine Erfahrungskurve (Abb. 34).

58

4. Koordinationsfeld „ Planung und Durchführung von JuK-Projekten "

Plan 05 Susp 02

Kundenkonto verwalten

12.09.91 1

Kundennr. Name Vorname _

Straße PLZ

Kontonr.

Ort. BLZ

Bank

Kommando > Enter-PFl —PF2—PF3—PF4—PF5—PF6—PF7—PF8- -PF9—PF10--PF11 —PF12 HELP EXIT ++ FLIP + TECH < > CAN Abb. 31: Schätzobjekt Bildschirmmaske (Quelle: Oriolo, S. 8)

Die genannten Verfahren sind wie folgt zu werten: das Multiplikatorverfahren und das diesem sehr ähnliche Produktivitätsverfahren sind nur noch sehr begrenzt anwendbar, denn die für diese Verfahren charakteristische Schätzgröße (Anzahl der Programmanweisungen) ist nicht mehr signifikant ftir Softwareprojekte, die datenbankgestützte Dialoganwendungen zum Gegenstand haben, und die zudem in höheren Programmiersprachen (z. B. 4GL) geschrieben werden; lediglich nicht-integrierte, einfache Stapel-Anwendungen, zu programmieren in Sprachen der 2. oder 3. Generation, eignen sich für diese Schätzverfahren. Das Analogieverfahren ist frei von diesen Restriktionen, denn die Merkmale können beliebig gewählt werden. Voraussetzung ist allerdings eine kontinuierliche Dokumentation von Projektmerkmalen und Projektkosten und eine nicht zu große Heterogenität der Projektmerkmale, denn diese schränkt die Möglichkeit für plausible Analogieschlüsse erheblich ein. Das Top-down-Verfahren kann erst dann sinnvoll eingesetzt werden, wenn das Entwicklungsvorhaben so weit detailliert ist, daß für einzelne Programm-Module Schätzungen auf der Basis von Anzahl der Programmanweisungen abgegeben werden können; im übrigen gelten hierzu die Einschränkungen, die zum Multiplikator- und zum Produktivitätsverfahren gemacht worden sind. Zu dem Bottom-upVerfahren ist zu vermerken, daß sich geringe Schätzfehler bei der Teilmenge multiplikativ auf die Zeit- und Kostenschätzung des Gesamtprojektes übertragen. Weiter ist zu berücksichtigen, daß das Abgrenzen einer repräsentativen Teilmenge aus einem Projekt ohne umfassende Analyse des Gesamtvorhabens rational kaum durchführbar ist.

4. Koordinationsfeld „ Planung und Durchfiihrung von luK-Projekten "

Schätzobjekttyp:

Maske

Name Maske:

K u n d e n k o n t o verwalten Wert

Formel

Ergebnis

1. Anzahl einfache Maskenfelder

6

•0.2

1,2

2. Feldgruppen mit M e h r f a c h a u s p r ä g u n g e n Anzahl Felder je F e l d g r u p p e

3

"0,4

1,2

X

-0

0

X

-0

0

Anforderung

3. D a t e n a u f b e r e i t u n g keine bis 30 % bis 30 % bis 70 % bis 100% 4. Selektionen keine Werteingabe PF-Tasten einfaches Ankreuzen Cursorpositionierung Zeilenkommandos 3. Blättern Nein Blätterarten +

X

0

Startwert

+, -

+, Startwert Seitensteuerung einfach schwer 6. F u n k t i o n e n - Anz. gelesener Informationsobjekte - Anz. geschriebener Informationsobjekte a) Anzeigen b) Eingeben c) Ändern d) Löschen

2,2,2 2,2 2,2

*2 *2,*4 *2,*4 *2,*4

Object Pointa:

4 12 12 12

42,4

Abb. 32: Bewertungsschema nach dem Object-Point-Verfahren (Quelle: Oriolo, S. 9)

59

60

4. Koordinationsfeld,, Planung und Durchßihrung von luK-Projekten "

1. Unbekannte Systemumgebung Batchanteil der Anwendung:

bis 20% 21 - 40% 41 - 5 0 % >50%

2. Betreten von technischem Neuland bezogen auf die Phasen: - technischer Entwurf - Realisierung

•

3. Betreten von fachlichem Neuland 4. Spezielle ZugrifTmechanismen a) Funktionalität vorhanden b) Funktionalität vorhanden, aber nur selten oder noch gar nicht eingesetzt c) keine Funktionalität vorhanden - funktionale Security - datenabhängige Security - 4-Augen-Prinzip 5. Endbenutzerhilfen

6. RZ-Hilfen

- maskenbezogene Hilfe - feldbezogene Hilfe - separates Benutzerhandbuch

5% (z.B.)

- Operator-Handbuch - Restart-Verfahren

2% (z.B.) 3% (z.B.)

7. Fremd- und Mehrsprachigkeit Es wird nicht in der Muttersprache entwickelt: - Benutzeroberfläche - Projektdokumentation Es wird zusätzlich in anderen Sprachen entwickelt: . „ . , - Benutzeroberfläche je Zusatzsprache: .... . .. r - Projektdokumentation 8. Erschwerte Testanforderungen - Code Inspection - Testdeckungsgrad - Testdatenbereitstellung ausreichend (Auftraggeber) nicht ausreichend, aber keine besondere Anforderung nicht ausreichend trotz besonderer Anforderung

•

•

9. Umfangreiches Berichtswesen 10. Beteiligung mehrerer Fachbereiche - 2-4 Fachbereiche - ab 5. Fachbereich 11. Installationen (Anzahl Installationen der Anwendung)

je FB je FB

je Installation

Abb. 33: Aufwandssteigernde Einflußfaktoren auf die Projektarbeit (Quelle: Oriolo, S. 13)

•

•

4. Koordinationsfeld „ Planung und Durchßihrung von luK-Projekten "

Zusammenfassung Schätzergebnisse 120 Masken 30 Listen 52 Informationsobjekte 8 Verarbeitungsfunktionen Zusammenfassung Einflußfaktoren Betreten von fachlichem Neuland Endbenutzerhilfen RZ-Hilfen

61

Summe Object Points 4950 1270 1930 140 2% 5% 3%

8290

10% Endergebnis: 8290 Object Points* 1,1 Einflußfaktor - 9119 Object Points.

Die Object Points werden an einer Erfahrungskurve in Mitarbeitermonate umgerechnet: Object

Abb. 34: Zusammenfassung der Schätzergebnisse und Erfahrungskurve (Quelle: Oriolo, S. 14)

Das Function-Point-Verfahren und das Object-Point-Verfahren setzen sich von den bisher genannten Verfahren (Ausnahme: Analogieverfahren) schon dadurch ab, daß für sie die Bezugsgröße „Anzahl der Programmanweisungen" (LOC) obsolet ist. Statt dessen orientiert sich das Function-point-Verfahren am Funktionsumfang und an den Datei- und Verarbeitungscharakteristika eines Anwendungssystems, und es bildet dadurch eine differenzierte, fundierte Schätzbasis. Allerdings sind die dazu erforderlichen Angaben („Systemspezifikationen") i. d. R.

62

4. Koordinationsfeld

„ Planung und Durchführung von IuK-Projekten "

erst nach der Phase der Anforderungsspezifizierung verfugbar und damit häufig zu spät für eine vorausschauende Zeit- und Kostenplanung von IuK-Projekten. Diesen Nachteil vermeidet das Object-point-Verfahren, das dem Function-point-Verfahren zeitlich vorgelagert in der Phase der Anforderungsspezifizierung eingesetzt wird, denn dessen Schätzobjekte (Bildschirmmasken, Druckoutput, fachliche Beschreibung der Verarbeitungsvorgänge, Informationsobjekte) sind die tragenden Säulen eines Fachkonzeptes. Beide Verfahren setzen allerdings voraus, daß Erfahrungswerte über die Korrelation von Function-Points bzw. Object-Points und Zeitaufwand [Personal-Monate] vorhanden sind; dadurch wird die Nutzung dieser Verfahren durch Anwender, für die Softwareentwicklung vom Charakter der „Einzelfertigung" ist, zumindest anfänglich erschwert. Wenn durch eines der genannten Schätzverfahren die voraussichtlich erforderlichen PersonalStunden ermittelt werden konnten, so lassen sich auf dieser Basis die Kosten für das Softwareprodukt z. B. nach dem Schema der Zuschlagskalkulation (Abb. 35) bestimmen.

Personal-Einzelkosten (Stunden x Stundensatz) + Personal-Gemeinkosten (%-Satz der Pers.-Einzelkosten) = Personalkosten + Hardware-Einzelkosten + Hardware-Gemeinkosten + Software-Einzelkosten + Software-Gemeinkosten + Material-Einzelkosten + Material-Gemeinkosten + Ausbildungskosten = Kosten des Softwareproduktes

Abb. 35: Zuschlagskalkulation für die Software-Eigenentwicklung

4.3.1.5

Qualitätsplanung

Die Qualität eines Produktes wird nach den Normen DIN 55630 und ISO 8402 definiert als die Gesamtheit der Eigenschaften und Merkmale, die sich auf dessen Eignung zur Erfüllung vorausgesetzter oder vorgegebener Anforderungen beziehen. Dieser allgemeine QualitätsbegrifT wird für das Produkt „Software" nach ISO/IEC 9126 präzisiert durch die Merkmale (Hohler 25, s. auch Abb. 36): • Funktionalität: Vorhandensein eines Satzes von Funktionen mit spezifizierten Eigenschaften;

4. Koordinationsfeld

„ Planung und Durchführung von IuK-Projekten "

•

Zuverlässigkeit: Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum aufrechtzuerhalten; • Benutzbarkeit: Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung einer Benutzung durch die vorausgesetzte Gruppe von Benutzern; • Effizienz: Verhältnis zwischen Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen; •

Änderbarkeit: Aufwand, der zur Durchfuhrung vorgegebener Änderungen notwendig ist; • Übertragbarkeit: Eignung einer Software, von einer Umgebung in eine andere übertragen zu werden.

Software-Qualitätsmerkmale nach I S O / I E C 9 1 2 6 1 H

Funktionalität Angemessenheit

Richtigkeit H Interoperabilität H —| Ordnungsmäßigkeit H 1

Sicherheit Zuverlässigkeit

H

Reife

Fehlertoleranz H H Wiederherstellbarkeit 1

Benutzbarkeit H

1

Verständlichkeit

H

Erlernbarkeit

H

Bedienbarkeit

Effizienz Zeitverhalten H H Verbrauchsverhalten

1 H

Änderbarkeit Analysiertarkeit

H H

Modifizierbarkeit

H

Prülbarkeit

1

Stabilität Übertragbarkelt

H H

Anpaßbarkeit Installierbarkeit

H

Konformität

H

Austauschbarkeit

A b b . 36: Qualitätsmerkmale v o n Software nach I S O / I E C 9 1 2 6 bzw. D I N E 6 6 2 7 2 (Hohler, 24)

63

64

4. Koordinationsfeld „ Planung und Durchßihrung von IuK-Projekten "

Die Qualität von Software bzw. eines IuK-Systems kann nicht nachträglich durch Kontrollen und Tests „hineingeprüft" werden, sondern sie muß systematisch produziert werden. Die Grundlage dazu bildet die Qualitätsplanung, die sich mit der Planung der Rahmenbedingungen für den Prozeß der Softwareerstellung befaßt, damit das gewünschte Qualitätsniveau von IuK-Systemen erreicht werden kann. Diese Rahmenbedingungen wurden bisher von Unternehmen zu Unternehmen sehr unterschiedlich gesetzt, je nachdem, in welchem Umfang und wie stringent das dazu verfugbare Instrumentarium genutzt wurde: so z. B. Projektmanagement, Softwareentwicklung auf Grundlage eines Vorgehensmodells, Anwenderpartizipation, methodische Softwareentwicklung (Funktionsorientierung, Datenorientierung, Objektorientierung), CASE-Unterstützung, Change Request Management usw. Mit der Norm ISO 9000, Teil 3, wurde eine allgemeingültige Richtlinie für die Qualitätssicherung von Software geschaffen. Diese Richtlinie hat jedoch nicht eine weitere Detaillierung der Qualitätsmerkmale von Softwareprodukten und von Metriken zu deren Messung zum Gegenstand, sondern sie setzt Mindest-Rahmenbedingungen für einen qualitätsdeterminierten Softwareerstellungsprozeß durch (s. auch Abb. 37) • Rahmenempfehlungen zur Gestaltung eines Qualitätssicherungssystems,

i Verantwortung der obersten Leitung - des Lieferanten - des Auftraggebers

• Vertragsüberprüfung • Spezifikation des Auftraggebers

• Interne Qualitätsaudits

• Planung der Entwicklung - Entwicklungsplanung - Entwicklungslenkung - Vorgaben für Entwicklungsplanung - Ergebnisse der Entwicklungsphasen - Verifizierung jeder Phase

• Korrekturmaßnahmen

• Planung der Qualitätssicherung

i Qualitätsmanagementsystem (QMS) - Dokumentation des Q M S • QM-Plan

• Design und Implementierung • Testen und Validierung • Annahme • Verfielfäitigung, Lieferung, Installierung • Wartung -Wartungsplan - Identifikation des Ausgangszustands -Unterstützende Organisation Arten von Wartungstätigkeiten - Wartungsaufzeichnungen und -berichte - Freigabeverfahren (neue Versionen)

B Konfigurationsmanagement - Identifikation und Rückverfolgbarkeit der Konfiguration - Lenkung der Änderungen Ko nfiguratio ns-Statusbe rieht • Lenkung der Dokumente • Messungen - Messungen am Produkt - Prozeßmessungen • Werkzeuge und Techniken • Beschaffung - Beurteilung von Unterlieferanten - Validierung von beschafften Produkten • Beigestelltes Softwareprodukt • Schulung

Abb. 37: Qualitätsmanagement für die Softwareentwicklung nach ISO 9000 (Hohler, S. 28)

4. Koordinationsfeld „ Planung und Durchfiihrung von IuK-Projekten "

65

• Maßnahmen, die sich direkt auf den Lebenszyklus von Softwareprodukten beziehen, • Maßnahmen, die den Prozeß der Softwareerstellung flankierend unterstützen. Die Normenserie ISO 9000 ff. wird vorwiegend zu Zwecken der Zertifizierung der Unternehmen darüber benutzt, daß in den Unternehmen normengerechte Vorschriften zur Qualitätssicherung von Produkten und Dienstleistungen existieren; nicht der Zertifizierung unterliegt jedoch die Art und Weise, wie diese Vorschriften in Einzelnen erfüllt werden. Voraussetzung für die Zertifizierung ist u. a. die Existenz eines Handbuches zur Qualitätssicherung i. S. der genannten Normen. Für ein qualitätssicherndes Controlling der Software-Eigenentwicklung bietet die Norm ISO 9000, Teil 3, eine geeignete Grundlage für das Erstellen eines solchen Qualitätssicherungshandbuches, das je nach dem Stellenwert des Denkens und Handelns in Qualität in einem Unternehmen individuell detailliert und präzisiert wird. Das kann z. B. dadurch erfolgen, daß zu den definierten Prozessen der Softwareerstellung i. S. von ISO 9000 ein Projekt-Qualitätsplan erstellt wird, der die wichtigsten qualitätssichernden Vorgaben enthält (Abb. 38 ), und/oder durch ergänzende Einzelpläne, die die Projektplanung unterstützen (Abb. 39).

•

Projektauftrag - Projektbezeichnung - Projektart - Auftraggeber • Projektorganisation - Projektgremien - Projektleiter - Projektteam • Projektziele - Wirtschaftlichkeitsziele - Systemleistungsziele • Projektergebnissse - Abschlußergebnisse - Zwischenergebnisse • Projekttermine • Projektkosten • Projektrisiken • Projektkonfiguration • Projektkontrolle - Reviewpunkte - Reviewergebnisse - Projektänderungen • Projektberichterstattung - Projekt-Fortschrittsberichte - Projekt-Reviewberichte - Projekt-Abschlußbericht

Tabb. 38: Projektbezogener Qualitätsplan , erstellt in Orientierung an Norm ISO 9000, Teil 3

66

4. Koordinationsfeld „ Planung und Durchfllhrung von IuK-Projekten "

Bezeichnung:

Plangrößen:

Beschreibung:

Aufgabenplan

Aufgaben, Mitarbeiter, Termine, Abhängigkeiten der Aufgaben;

Auflistung der projektbezogenen Aufgaben und deren Abhängigkeiten untereindander sowie der zugehörigen Aufgabenträger

Ausbildungsplan

Mitarbeiter, Kurse, Termine, Kosten;

Enthält die für die Mitarbeiter vorgesehenen projektbezogenen Ausbildungsmaßnahmen

Berichtsplan

Projektberichte, Verteiler, Termine;

Legt die Informationswege der Projektberichterstettung fest

Inspektionsplan

Inspektionsobjekte, Termine, Teilnehmer;

Enthält die geplanten Inspektionsaktivitäten

Kostenplan

Kostenart, Kostenträger; Termine;

Zeigt die nach Leistungseinheiten und Terminen geplanten Projektkosten auf

Krisenplan

Problemfälle, Maßnahmen, Beauftragter;

Weist für vorausgedachte Problemfälle die geplanten Maßnahmen aus

Meilensteinplan

Meilenstein, Termin, Verantwortlicher;

Enthält die Projektmeilensteine mit deren geplanten Terminen

Mitarbeitereinsatzplan

Mitarbeiter, Arbeitspakete, Termine;

Zeigt den Einsatz der einzelnen Mitarbeiter bezogen auf die Arbeitspakete des Projektes auf

Projektorganisationsplan

Projektabschnitte, Projektbeteiligte, Gremien;

Entscheidungs- und Verantwortungsregelung über das gesamte Projekt

Projektstrukturplan

Arbeitspakete, Projektphasen;

Strukturübersicht der Arbeitspakete eines Projektes

Terminplan

Meilensteine, Arbeitspakete, Termine;

Terminübersicht über das Projekt

Zuliefe rplan

Leistungen, Zulieferer, Temine

Übersicht über die Projektzulieferungen von externen Dienstleistern

Abb. 39: Projektpläne (Auszug nach Burghandt, S. 254)

4. Koordinationsfeld „Planung und Durchführung von IuK-Projekten "

4.3.2 4.3.2.1

67

Projektsteuerung Qualitätslenkung

Die Qualitätslenkung befaßt sich mit der Überwachung und Korrektur des Softwareentwicklungsprozesses zu Zwecken des Erreichens des geplanten Qualitätsniveaus des IuK-Systems. Objekte der Qualitätslenkung sind die Zwischenprodukte des Entwicklungsprozesses (Meilensteine, Arbeitspakete oder Prototypen); diejenigen Zwischenprodukte, die das Fundament eines IuK-Systems bilden, sind von besonderem Interesse: das Fachkonzept und das Systemkonzept. Beim Fachkonzept erstrecken sich die Aktivitäten der Qualitätslenkung auf • die Schlüssigkeit und Operationalität der Sachziele, • die funktionale Abdeckung der Anforderungen, • die Qualität der Anforderungsspezifikation, • die Plausibilität der Nutzenbegründung, und beim Systemkonzept auf die Gestaltung • der Benutzerschnittstellen, • der Verarbeitungslogik, • der Datenhaltung, • der Programmschnittstellen, • der Hardwarestruktur, • der Netzstruktur. Die Qualitätslenkung erfolgt üblicherweise in Form von strukturierten Gruppendiskussionen, für die auch die Bezeichnungen „Software-Audit", „Projekt-Review" oder „Walk Through" verwendet werden, und die nach folgenden Teilschritten verlaufen (Abb. 40): Die Planung befaßt sich mit der Auswahl der Prüfobjekte, der Auswahl der Teilnehmer an der Gruppendiskussion und der Bestimmung des Diskussionsmoderators. In der Vorbesprechung erfolgt eine gemeinsame Einfuhrung in die Prüfobjekte anhand der für das Entwicklungsprocedere vorgeschriebenen Begleitdokumentation; anschließend werden die Ziele für den Prüfprozeß formuliert, und es werden die Aufgaben verteilt. Daran schließt sich die individuelle Vorbereitung der Teilnehmer mit den übertragenen Teilaufgaben an. In der Gruppensitzung werden die Entwicklungsschritte und deren Ergebnisse vorgetragen und gemeinsam diskutiert. Mängel, die dabei festgestellt werden, werden in einem Mängelkatalog visualisiert; anschließend werden gemeinsam Verbesserungsvorschläge erarbeitet und die dazu zu ergreifenden Maßnahmen nach Prioritäten (z. B. „Muß"/"Kann") unterteilt. Die Nachbearbeitung des Prüfobjektes aufgrund der festgestellten Mängel und der dazu beschlossenen Maßnahmen zur Mängelbeseitigung obliegt dem jeweiligen Entwicklungsteam. Danach erfolgt wieder gemeinsam durch die Gruppe die Bewertung des Prüfobjekts darauf, ob die geforderten Qualitätsziele erreicht worden sind. Die Teilergebnisse dieses „Walk Through" sind jeweils zu dokumentieren und aus Gründen eines späteren Gesamt-Projektreview der Entwicklungsdokumentation beizufügen.

68

4. Koordinationsfeld

„ Planung und Durchführung von

IuK-Projekten"

T

Bewertung

Abb. 40: Strukturierte Gruppendiskussion im Rahmen der Qualitätslenkung

4.3.2.2

Benutzerbefragung

Eine weitere Möglichkeit zur Verankerung des Denkens und Handelns in Qualität im Prozeß der Softwareentwicklung ist die Benutzerbefragung über abgeschlossene IuK-Projekte, denn dadurch kann sich eine wesentliche Rückkopplung für die Planung und Steuerung zukünftiger IuK-Projekte ergeben. Folgende Fragestellungen sind dazu geeignet (s. auch Douglass/Walsh, 5): • Hat das Projekt Ihre fachlichen Vorgaben erfüllt? • Ist das Projekt termingerecht fertiggestellt worden? • Sind die Projektkosten im veranschlagten Rahmen geblieben? • Hat das Projekt Ihre Nutzenerwartungen erfüllt? • Sind Sie in die Projektarbeit miteinbezogen worden? • Wurden Sie regelmäßig über den Projektfortschritt informiert? • Wurden Sie über erforderliche Änderungen rechtzeitig informiert und wurden Sie zur Durchführung von Änderungen miteinbezogen? • Hatten Sie den Eindruck, daß das Projektteam die erforderliche Professionalität hatte? • Hatten Sie den Eindruck, daß die Mitarbeiter am Projekt sich als Team verstanden haben? • Erwies sich der Projektleiter für Sie als qualifizierter Ansprechpartner? • Hatten Sie den Eindruck, daß das Projektteam zielstrebig und effizient geführt wurde? • Was können wir zur Verbesserung Ihrer Zufriedenheit tun?

4. Koordinationsfeld „ Planung und Durchfiihrung von luK-Projekten "

69

4.3.2.3 Projektwertanalyse Die Projektwertanalyse dient zur Überprüfung der Zweckmäßigkeit des Leistungsumfanges eines IuK-Systems; sie ergänzt dadurch die Qualitätslenkung. So wie für die Produktwertanalyse oder fiir die Gemeinkostenwertanalyse gilt auch hier die Maxime: „Funktion so zweckmäßig wie möglich, zugehörige Kosten so niedrig wie möglich". Daraus lassen sich als Ziele für die Projektwertanalyse konkretisieren die • zweckdeterminierte Gestaltung des Fachkonzeptes, • zweckdeterminierte Gestaltung des Systemkonzeptes, um dadurch Entwicklungszeiten und Entwicklungskosten zu reduzieren. Ansatzpunkte dazu sind der Verzicht auf nicht-zweckdienliche Funktionen und/oder eine vereinfachte Funktionsgestaltung bei Beibehaltung oder evtl. Verbesserung der geforderten Funktionalität. Folgende Leitfragen skizzieren die Schrittfolge dazu: • Wozu dienen die Systemleistungen? • Welche Kosten verursachen die geforderten Systemleistungen? • Welchen Nutzen haben die Systemleistungen fiir den Anwender? • Können die Systemleistungen in anderer Form und zu niedrigeren Kosten erbracht werden? • Gibt es andere Systemleistungen, durch die das Anspruchsniveau des Anwenders besser erfüllt werden kann? • Welche Konsequenzen ergeben sich aus dem Verzicht auf die geforderten Systemleistungen? • Welche alternative Verwendung gibt es für die Mittel, die durch den Verzicht auf geforderte Systemleistungen frei werden? 4.3.2.4 Projektfortschrittskontrolle Während die Qualitätslenkung zur Überwachung und Korrektur der Produktqualität dient, hat die Projektfortschrittskontrolle darüber übergreifend die Aufgabe, das Projektmanagement und die am Projekt direkt und indirekt beteiligten Mitarbeiter über den Projektstatus zu informieren. Das geeignete Instrument dazu ist der Projektstatusbericht (s. Abb. 41); dieser Bericht ist die Grundlage für die weiteren Planfortschreibungen, und er ist dehalb regelmäßig zu festen Terminen zu erstellen, die als „Management-Checkpoints" die Aktivitäten- oder Ergebnisabfolge nach Maßgabe eines Vorgehensmodells überlagern. Unabdingbare Voraussetzung für das Erstellen des Projektstatusberichtes sind objekt-, personen- und tätigkeitsbezogene Zeitaufschreibungen, denn ohne diese wird jede Projektfortschrittskontrolle illusorisch.

70

4. Koordinationsfeld „ Planung und Durchfiihrung von IuK-Projekten"

•

• • • • • •

• • • • • •

Stand der Arbeiten am Projekt It. Projektstrukturplan: - fertiggestellt, - in Arbeit, - in Unterbrechung, - noch zu bearbeiten; Terminplan der Projektaktivitäten/-ergebnisse nach SOLL-/ISTTermin, Kostenplan der Projektaktivitäten/-ergebnisse nach SOLL-/ISTKosten, Kapazitätsbelastungsübersicht auf Grundlage von Projektaktivitäten/-ergebnissen [Mitarbeitertage], Ergebnisse der Abweichungsanalysen von SOLL/IST-Vorgaben, akkumulierte Stundenbelastung der Projekt-Mitarbeiter, Stand des Projektbudgets: - Planansatz, - bisher verbraucht, - noch verfügbar, - Abweichungen gegenüber Planansatz; Hinweise auf Probleme, Hinweise auf Risiken, Hinweise auf Sachverhalte, die einer Änderung bedürfen ("Change Request"), unmittelbar erforderlicher Handlungsbedarf, projektbezogene Kennzahlen, Benutzerzufriedenheit.

Abb. 41: Inhalt eines Projektstatusberichtes

Zur Unterstützung der Projektsteuerung, aber auch der Projektplanung, bieten sich computergestützte Projektmanagementsysteme (PMS) an. Das Funktionsspektrum dieser Systeme umfaßt üblicherweise • Projektstrukturierung auf Grundlage eines Vorgehensmodells, • Erstellen und Verwalten von Projektnetzplänen, • Erstellen/V erdichten von Teilnetzplänen, • Projektdarstellung in Form von Netzplänen und Balkendiagrammen (Gantt-Diagramme) • •

Mehrprojektplanung, Durchfuhrung von Planungsrechnungen: - Terminplanung, - Kostenplanung, • Zeiterfassung und Zeitauswertung, • Kostenerfassung und Kostenauswertung, • Ressourcenzuordnung - Mitarbeiterzuordnung, - Sachmittelzuordnung; • Planfortschreibungen,

4. Koordinationsfeld „ Planung und Durchführung von IuK-Projeklen" •

Simulation/Hochrechnung von Terminen, Kapazitäten und Kosten,

•

Aufdecken und Lösen von Ressourcenkonflikten zwischen Projekten.

71

Verfugen Systeme dieser Art zudem über ein lokales Datenbanksystem mit Datenmanipulations- und Abfragesprache und Berichtsgenerator sowie über Tabellenkalkulation, Textverarbeitung und Präsentationsgraphik, dann sind dadurch die softwaretechnischen Voraussetzungen für ein eigenständiges Projektinformationssystem gegeben. 4.3.2.5

Unterstützung der Teamarbeit

Projektarbeit ist ausgeprägte Teamarbeit, und diese Form der Arbeitsorganisation hat wegen ihrer speziellen Charakteristika einen besonderen Unterstützungsbedarf (vgl. Petrovic, 17): • es muß die gemeinsame Bearbeitung von Teilaufgaben des Projektes möglich sein, • die Kommunikation zwischen den Teammitgliedern muß organisiert werden, • die Kooperation der Teammitglieder muß organisiert und gesteuert werden, • das Treffen von Gruppenentscheidungen ist zu unterstützen Das geeignete Instrumentarium liefert hierzu Groupware (synonym: Work Group Computing, Computer Aided Team, Computer-supported Cooperative Work); dieses um faßt i d. R.: • •

Co-Autorensysteme zur gemeinsamen Erstellung von Dokumenten, Textfilterungssoftware zum Durchsuchen und Zusammenstellen von individuell erarbeiteten Texten oder Dokumenten,

• zentrales Dokumentationssystem, • gruppenindividuelle Datenhaltung, • Screen-Sharing zur gleichzeitigen und wechelseitigen Kopplung von Bildschirmdarstellungen unterschiedlicher Teammitglieder, • Kommunikationssysteme, bestehend aus Electronic Mail, Telekonferenz und der Möglichkeit zu spontanem Datenaustausch im Netz, • Electronic Bulletin-Boards, • Gruppen-Terminkalender mit zentraler Terminkalenderverwaltung.

4.4

Software-Produktmanagement

Das Management von IuK-Projekten nach dem Konzept des Projektmanagements (s. Kap. 4.2) setzt gemäß der Definition des Begriffes Projekt („zeitlich befristetes Vorhaben") voraus, daß ein Projekt dieser Art zu einem bestimmten Termin als beendet gilt und der Projektleiter demzufolge aus seiner Verantwortung für dessen erfolgreiche Durchführung entlassen werden kann. Diese Voraussetzung wird der praktischen Erfahrung nach nur selten erfüllt, denn geänderte oder zusätzliche Vorgaben und Wünsche der Auftraggeber sowie Veränderungen in der IuK-Infrastruktur erfordern eine Weiterentwicklung des IuK-Systems, auch wenn dieses mit der betriebsfertigen Übergabe an den Anwender als abgeschlossenes Entwicklungsprojekt gilt.

72

4. Koordinationsfeld

„Planung undDurchflihrung

von

IuK-Projekten"

Die Weiterentwicklung und die sonstige Systempflege fallt aber nicht mehr in den Verantwortungsbereich des Projektleiters. In Ansehung dieser Sachverhalte liegt es nahe, das Projektmanagement durch ein Produktmanagement zu ergänzen. Der Produktmanager hat im Rahmen einer Produkt-Matrixorganisation üblicherweise die volle Erfolgsverantwortung für ein oder mehrere Produkte; diese Verantwortung beginnt bei der Budgetierung und Produktplanung und erstreckt sich über Marketing, Koordinierung der Produktion, Verkauf, Produktpflege bis hin zur Produktablösung. Soll dieses Konzept auf Softwareprodukte übertragen werden, so bedeutet dies: •

mit einem gegebenen Budget ist ein Softwareprodukt in einer definierten MußFunktionalität zu einem bestimmten Termin fertigzustellen; • vorrangiger Erfolgsfaktor für die Projektarbeit dazu ist „Time to Market"; • für die wirtschaftliche Rechtfertigung des Projektes sind analog zur Bestimmung der Amortisationsdauer einer Inverstition Kosten und Nutzen des Softwareproduktes über dessen gesamte Lebensdauer in das Kalkül zu nehmen (Lebenszykluskosten). Der Projektleiter muß sich vom Verantwortlichen für eine zeitlich begrenzte Entwicklungsaufgabe zum Verantwortlichen für ein Produkt wandeln, d. h , er trägt die Verantwortung für: • den „marktgerechten" Produktdesign, • wirtschaftliche Produktentwicklung, • die Zuverlässigkeit des Produktes im laufenden Betrieb, • die Beratung, Schulung und Betreuung der Anwender, • die Wartung des Produktes und die Release-Freigaben, • das Management der Probleme, die bei der Nutzung des Produktesauftreten, • die Wirtschaftlichkeit des Produktes über dessen gesamte Nutzungsdauer.

4.5 4.5.1

Planung und Steuerung des Software-Fremdbezugs Software-Fremdbezug

Die Alternative zur Eigenentwicklung von Software ist der Fremdbezug von Software. Neben der Fremderstellung von Individualsoftware (Auftragsfertigung von Anwendungssoftware) bietet sich hierzu der Bezug von Standard-Anwendungssoftware an. Diese Software eignet sich vorrangig für solche Anwendungsbereiche, die durch gesetzliche Vorschriften und/oder durch gesicherte betriebswirtschaftliche Erkenntnisse als „standardisiert" gelten. Typisch für die erste Kategorie sind die Bereiche Finanzbuchhaltung, Anlagenbuchhaltung, Lohn- und Gehaltsabrechnung und die von Behörden geforderten Meldungen und Berichte; zur zweiten Kategorie zählen z. B. Auftragsbearbeitung, Lagerhaltung, Einkauf, Fertigungsplanung und -Steuerung, Instandhaltung, Fakturierung und Versand, betriebliches Rechnungswesen, Personalverwaltung. Das derzeit verfugbare Angebot an Standard-Anwendungssoftware ermöglicht es, nahezu sämtliche operativen Bereiche und viele Planungsaufgaben im Unternehmen abzudecken. Die Entscheidung darüber, für welche Bereiche im Unternehmen Standard-Anwendungssoftware eingesetzt werden soll, sollte sich grundsätzlich an der Maxime orientie-

4. Koordinationsfeld „Planung und Durchführung von IuK-Projekten "

73

ren „Individualität im Bereich der kritischen Erfolgsfaktoren, Konformität im administrativen Bereich!". Deshalb sind z. B. Marketingunterstützung, Distributionslogistik, Kundenberatung, Serviceunterstützung, Projektierung, aber auch die innerbetriebliche Auftragslogistik Anwendungsfelder für IuK-Systeme, die wegen des unmittelbaren Bezuges zu kritischen Erfolgsfaktoren die Eigenentwicklung von Software oder umfangreiche Anpassungen von Standard-Anwendungssoftware rechtfertigen oder erfordern. 4.5.2

Vorgehensmodelle

So wie die Anwendungsentwicklung als Projekt durchgeführt wird, ist auch der Fremdbezug von Standard-Anwendungssoftware als Projekt zu planen und durchzuführen, wenn das Entscheidungsprocedere darüber rational durchgeführt werden soll. Als Vorgehensmodell dazu eignet sich wegen der vergleichsweise gut strukturierbaren Aufgabengebiete, für die StandardAnwendugssoftware eingesetzt wird, ein sequentiell oder ein parallel-sequentiell strukturiertes Modell, z. B. ein Phasenkonzept mit Meilensteinen und Arbeitspaketen, ergänzt durch phasenspezifisches Prototyping, das folgende Schrittfolgen beinhaltet (Abb. 42): • •

Situationsstudie, Anforderungsermittlung, Entwicklungsebenen

Zeit Abb. 42: Phasenkonzept mit Meilensteinen zur Auswahl von Standard-Software

74

4. Koordinationsfeld „Planung und Durchßihrung von luK-Projekten "

• Produktevaluierung, • Anwendungskonzeptionierung, • Produktanpassung, • Produkteinführung. In der Phase Situationsstudie sind die Aussagen zu erarbeiten, die grundsätzlich zur Begründung eines jeden Reorganisationsprojektes erforderlich sind: die inhaltlichen Vorgaben des Vorprojektes (s. Kap. 4.2.5). Im Gegensatz zur Planung und Entwicklung von selbstzuerstellender Anwendungssoftware kann sich die Anforderungsermittlung hier auf ein grobes Rahmenkonzept der gewünschten betriebswirtschaftlichen Funktionalität der Software - z. B. in Form von Funktionen und/oder Prozessen - beschränken. Das Erarbeiten dieses Rahmenkonzeptes kann jedoch durch Referenzmodelle unterstützt werden; dies sind Modellierungshilfen, die aus „typischen" Strukturen betriebswirtschaftlicher Funktionen und Prozesse bestehen (Abb.43 und 44). „Typisch" bedeutet hierbei nicht allgemein-betriebswirtschaftliche Funktions- und Prozeßstrukturen, sondern solche Strukturen von Funktionen und Prozessen, wie sie typisch für Unternehmen einer bestimmten Branche sind. Referenzmodelle sind deshalb als branchenspezifische Baumuster für die zukünftige Gestaltung von Anwendungssystemen zu verstehen. Durch Abgleich der eigenen groben Vorstellungen über erforderliche Funktionen und Prozesse mit entsprechenden Referenzmodellen erhält man das Basisprofll der Fachlichen Anforderungen an ein Standard-Softwareprodukt. Detaillierte Erhebungen über den individuellen organisatorischen Istzustand in einem Unternehmen als Grundlage für die Anforderungsermittlung sind durch die Verwendung von Referenzmodellen und in Anbetracht des betriebswirtschaftlichen Reifegrades heutiger Standard-Anwendungssoftware i. d. R. weitgehend obsolet. In der Phase Produktevaluierung werden die zur Auswahl stehenden Standard-Softwareprodukte auf ihre Eignung geprüft. Die Evaluierung erfolgt zweckmäßigerweise zunächst anhand des Basisprofils fachlicher Anforderungen, das die Grundlage für eine systematische Vorauswahl bildet. Daran anschließend kann im Rahmen eines Projekt-Laboratoriums die Detailfünktionalität der in engere Wahl genommenen Softwareprodukte vertiefend evaluiert werden; der Erfahrung nach ist es zweckdienlich, wenn dieser Evaluierungsschritt gemeinsam mit den im Unternehmen meinungsbildenden Anwendern, d. h. mit „Schlüssel-Anwendern", durchgeführt wird. Die Produktevaluation wird abgeschlossen durch einen Kostenvergleich zwischen Eigenentwicklung und Fremdbezug; folgende Kostenarten des Fremdbezuges sind hierzu den Kosten für die Eigenentwicklung gegenüberzustellen: • • • • • • •

Informationskosten, Evaluierungskosten, Kaufpreis oder kumulierte Nutzungskosten, Anpassungs- und Installationskosten, Schulungskosten, Wartungskosten, Weiterentwicklungs- bzw. Releasekosten der Standard-Software.

4. Koordmationsfeld

„ Planung

und Durchführung

"

von luK-Projekten

Anwendungsteilsystem LAGERHALTUNG und BESCHAFFUNG - Basismodule -

Bevorratung

Beschaffung

M1

M2

. Bestandsführung

_ Angebotsbearbeitung

. Bestelldisposition

. Auftragsvergabe

. Lagerbestandsbewertung

- Wareneingang

Bereitstellung M3

Entsorgung M4

. Anforderungsdisposition

. Entsorgungsdisposition

. Materialzustellung

. Entsorgungskontrolle

Inventur

Zusatzfunktionen M1

M2

•

Bestellpolitik

•

Lieferantenauswahl

•

stoch. Bedarfsermittlung

•

EDIFACT

•

Bestandssimulation

•

Mahnung

•

wirtschaftliche Losgrößen

•

Qualitätshistorie

•

Lagersystem

M3

M4

•

innerbetriebl. Transportlogistik

•

Entsorgungshistorie

•

Lagersystem

•

Lagersystem

M5

© Sicherheitsbestände •

Lagersystem

Lagerinformationssystem / Lieferanteninformationssystem Abb. 43: Referenzmodell Funktionsstruktur

75

76

4. Koordinationsfeld

„Planung und Durchführung von IuK-Projekten "

Abb. 44: Referenzmodell Prozeßstruktur (Beschaffungsauftragsführung)

4. Koordinatiomfeld,, Planung und Durchfiihrung von luK-Projekten "

77

In der Phase Anwendungskonzeptionierung wird aus dem Leistungsspektrum der ausgewählten Standard-Anwendungssoftware das unternehmensindividuelle Funktions- und Prozeßmodell mit den zugehörigen detaillierten Arbeitsabläufen generiert. Nach Maßgabe dieser Modelle wird ein Prototyp des Anwendungssystems erzeugt, der die Grundlage für weitere Modifizierungen oder Detaillierungen ist. In der Phase Produktanpassung werden die Korrekturen, Änderungen, Ergänzungen und Erweiterungen an der Standard-Anwendungssoftware vorgenommen und es werden die Anwendungs- und Systemparameter gesetzt, die erforderlich sind, um den Anwendungsprototypen in ein realisierungsfähiges, unternehmensindividualisiertes Anwendungssystem zu transformieren. Die wichtigsten Aktivitäten in der Phase Produkteinführung sind die Datenübernahme (Stammdaten, Bewegungsdaten), der Probebetrieb, die Freigabe des Anwendungssystems für den laufenden Betrieb und die Unterstützung des Anwenders in dessen Nutzung.

4.5.3

Auswahl

Das wichtigste Kriterium für eine systematische Auswahl von Standard-Anwendungssoftware ist das Basisprofil der fachlichen Anforderungen; daneben gibt es aber noch eine Reihe von nicht minder gewichtigen Kriterien, die sich in Kriterien zur Beurteilung der Produktqualität und in Kriterien zur Beurteilung der Produzentenqualität untergliedern lassen (Abb. 45 und 46). Zur detaillierten Evaluierung der auszuwählenden Softwarepakete bietet sich die Nutzwertanalyse an (Abb. 47); durch entsprechende Gewichtung der Kriterien lassen sich diese dazu in unbedingt einzuhaltende Vorgaben („Muß-Kriterien") und in ergänzende Vorgaben („Kann-Kriterien") untergliedern.

4.5.4

Konzeptionierung und Anpassung

Standard-Anwendungssoftware ist Software, die für einen weiten Kreis unterschiedlicher Anwender entwickelt worden ist; dies bedeutet aber nicht, daß Uniformierung der organisatorischen Strukturen zu Lasten der notwendigen Individualisierung gehen muß. Um das zu gewährleisten, verfugen zeitgemäß gestaltete Standard-Softwarepakete über ein breites Spektrum an betriebswirtschaftlichen Funktionalitäten, das in seiner Gesamtheit i. d. R. über den Bedarf des einzelnen Unternehmens hinausgeht. Damit ein Unternehmen in der StandardAnwendungssoftware seine gewünschte fachliche und organisatorische Individualität finden kann, ist eine unternehmensspezifische Konzeptionierung des Gesamtsystems und eine Anpassung der Detailkomponenten erforderlich.

78

4. Koordinationsfeld

•

•

•

•

•

•

•

• •

•

•

• • •

„ Planung und Durchflihrung von IuK-Projekten"

Betriebswirtschaftliches Leistungsspektrum - Funktionen - Prozesse Benutzeroberfläche - Bildschirmgestaltung - Dialoggestaltung - Fehlermeldungen - Hilfe-Fuktionen Anpassung - durch Änderungen im Quellcode - durch Parametrisierung (Tabellen) - durch standardisierte 4GL - über Zugangssysteme Integration in bestehende Anwendungssysteme - Schnittstellen - Schnittstellenhandhabung Datenhaltungsinfrastruktur - Datenmodell - Dateisystem - Datenbanksystem Programminfrastruktur - Schichtenkonzept (DCE) - Modulkonzept - Strukturierung des Quellcodes - Programmiersprache Konstruktionsmethodik - Funktionsorientierung - Datenorientierung - Objektorientierung Einbettung in die Software-Entwicklungsumgebung Plattformen - Hardware - Betriebssysteme - Netze Plattformstruktur - zentrale Struktur - dezentrale Struktur (CS) Sicherheitskonzept Zeitverhalten Ressourcenverbrauch Dokumentation - Benutzerdokumentation - Softwaredokumentation

Abb. 45: Kriterien zur Auswahl von Standard-Anwendungssoftware - Produktqualität -

4. Koordinationsfeld „ Planung und Durchführung von IuK-Projekten "

Vertragskonditionen: • Kosten - Kaufpreis - Miet-/Leasingkosten - Lizenzgebühren - Wartung (HW/SW) - Beratung - Umstellungsunterstützung - Schulung • Leistungen - Lieferumfang - Anpassungsunterstützung - Installationsunterstützung - Testmöglichkeiten - Wartungsunterstützung - Garantiezusagen - Nutzungseinschränkungen - Schulungsmöglichkeiten - Lieferzeit Anbieterbezogene Kriterien: • Branchenkenntnis • Fachkenntnis • Kontinuität der Produktpolitik • Standort • Servicenetz • Servicequalität • Qualifikation der Mitarbeiter • Marktposition • Referenzen • ISO-Zertifizierung

Abb. 46: Kriterien zur Auswahl von Standard-Anwendungssoftware - Produzentenqualität -

79

80

4. Koordinationsfeld „ Planung und Durchßihrung von luK-Projekten"

Bewertungskriterien Gewichtung Software-Produkt A Software-Produkt B G Funktionserfüllung

E

N

E

N

60

(40)

- Auftragsführung

20

4

80

3

- Lagerhaltung

10

3

30

3

30

- Einkauf

10

1

10

2

20

Benutzeroberfläche

10

3

30

2

20

Produktarchitektur

(20) 10

1

10

2

20

- Datenhaltung

5

1

5

0

0

- Anpassung

5

2

10

1

5

- Integration

Produzentenqualität

(10)

- Leistungen

5

2

10

4

20

- Qualifikation

5

4

20

3

15

20

3

60

3

60

(100)

-

265

-

250

Kosten Gesamt-Nutzen

E = Kriterienerfüllung N = G x E = Kriterienbezogener Nutzwert einer Variante (Einzel-Nutzen) Abb. 47: Auswahl von Standard-Anwendungssoftware nach der Nutzwertanalyse

Die Konzeptionierung besteht darin, aus dem Leistungsspektrum des Softwarepaketes diejenigen Funktionen und Prozesse auszuwählen, die den gewünschten fachlichen Anforderungen entsprechen. Dies erfolgt i. d. R. durch das Erarbeiten eines unternehmensspezifischen Prototyps des Anwendungssystems, der jedoch nicht softwaretechnisch entwickelt, sondern generiert wird. Dazu eignet sich ebenfalls der Einsatz von Referenzmodellen, die sich jetzt allerdings auf die Strukturen von Funktionen und Prozessen des Standard-Softwarepaketes beziehen, ergänzt z. B. durch Referenzdarstellungen detaillierter Arbeitsabläufe (Ereignis-Prozessketten) und Datenmodelle (Abb. 48a u. 48b).

4. Koordinationsfeld „ Planung und Durchfiihrung von luK-Projekten "


f

| J

Rechnung

\

erstellt

/

Rechnung buchen

| I

82

4. Koordinationsfeld

„ Planung und Durchführung von IuK-Projekten "

Abb. 48b: Referenzmodell zu einem Datenmodell (Datenstruktur zu .Vertriebsabwicklung"; Scheer, [Wl], S. 463)

Die Anpassung befaßt sich mit den erforderlichen Detailausprägungen des unternehmensspezifisch konzeptionierten Standard-Anwendungssystems; typische Objekte der Anpassung sind • die Benutzeroberfläche, (Bildschirmmasken, Menusteuerung) • die Programmodule des des Anwendungssystems, • der Aufbau und Inhalt von Datensätzen und Relationen, • die Kommunikationsschnittstellen auf Programmebene, • die Hinweis- und Hilfetexte. Die traditionelle Form der Anpassung ist die Änderung des mitgelieferten Quellcodes des Software-Paketes; dieses Vorgehen ist jedoch sehr problembehaftet, denn abgesehen von dem dazu erforderlichen sehr hohen Zeitaufwand werden dadurch Veränderungen erzeugt, die bei allfälligen Releasewechseln der Standard-Anwendungssoftware zwangsläufig Inkompatibiltäten der Systemkomponenten bewirken. Die zeitgemäße Form der Anpassung ist die Änderung

4. Koordinationsfeld

„Planung

und Durchführung

von

IuK-Projekten"

83

über Tabellen, denn flexibel konstruierte S o f t w a r e ist tabellengesteuert, d, h. P a r a m e t e r , die die V e r a r b e i t u n g steuern, sind in separaten, den Anwendern zugänglichen Tabellen abgelegt. Im Vergleich z u r Anpassung durch Änderungen im Quellcode ist die A n p a s s u n g über Tabellen, die z u d e m menügesteuert durchgeführt wird, wesentlich effizienter. Allerdings darf dabei nicht übersehen

werden,

d a ß auch hierbei ein hoher Zeitaufwand entstehen

kann,

denn

die

beabsichtigte Flexibilität von S t a n d a r d - A n w e n d u n g s s o f t w a r e hat als z w i n g e n d e K o n s e q u e n z ein breites Spektrum v o n Anpassungsmöglichkeiten bzw. -erfordern!ssen; Abb. 4 9 gibt einen Einblick in diese Problematik. Der Zeitaufwand für die Anpassung über Tabellen kann d a d u r c h

Parameter Umsatzgrenzen von Kunden, oberhalb deren Angebot erstellt wird Zeit seit letzter Bestellung, bei deren Überschreitung Angebot erstellt wird Erfolgsquote früherer Angebote, die gegeben sein muß, damit Angebot erstellt wird Gewichte einzelner Kriterien und Schwellwerte innerhalb einer Nutzwertanalyse hinsichtlich der Angebotsauswahl

. . .

-

.

Angebotsauswahl

< S t o p >

Rabattstaffeln Kapazitätsreservierungs-Faktor Parameter des Financial Engineering (z.B. maximale monatliche Belastung, Darlehenslaufzeit) Parameter zur Berechnung des zuzusagenden Liefertermins

Debitorengrenze, bei deren Überschreitung keine weiteren Auftrage mehr angenommen werden absoluter/relativer MindesMDeckungsbeitrag Kundenpriorität für Lieferzeitkonflikte Reserve für Intensitätsanpassungen Sicherheitsbestand/Sicherheitszeit/Sicherheitsfäktor Bestellpolitik Losgrößenberechnungsverfahren zwischen zwei Aufträgen für das gleiche Teil Mindest-)•/Höchstauftragsmengen für Fremdbezug/

Auftragsprüfling

Materialwirtschaft

geplanter Äusschußfaktor geplante Durchlaufzeiten geplante Vor- und Nachbereitungszeit geplanter Arbeitsgang-Ausschußfaktor eplanter Arbeitsgang-Wirkungsgrad plittungsparameter Liberia ppünasparameter geplanter Maschinen-Wirkungsgrad Belastungsschranke

t

anzuwendende Reihenfolgeregelung Anzahl KANBAN-Karten Splittungsparameter Uberiappungsparameter

Zeitwirtschaft

Prozeßsteuerung

Abb. 49: Parameter in Programmen zur Administration und Disposition des Auftragsdurchlaufs (Auszug) (Mertens/Wedel/Hertinger, 583)

84

4. Koordinationsfeld

„ Planung und Durchführung

von IuK-Projekten "

reduziert werden, daß der Anwender sich entweder mit der standardisierten Voreinstellung der Systemparameter begnügt, oder daß die Tabelleneinstellung selektiv erfolgt (Boll, 423): • Tabellen, die angepaßt werden müssen, • Tabellen, die angepaßt werden können, • Tabellen, die nicht verändert werden dürfen. Eine andere, anspruchsvollere Möglichkeit besteht darin, zur Parametereinstellung von umfassenden Standard-Anwendungssystemen spezielle Zugangssysteme einzusetzen, die auf Grundlage wissenbasierter Systeme konzipiert sind (s. hierzu Mertens/Wedel/Hartinger). 4.5.5

Umstellung

Für die Umstellung auf Standard-Anwendungssoftware bieten sich zwei grundsätzlich unterschiedliche Vorgehensweisen an: die schrittweise, sukzessive flächendeckende Umstellung oder die punktuelle Gesamtumstellung. Die schrittweise Umstellung hat den Vorteil des gleitenden Hineinwachsens in ein komplexes, neues Anwendungssystem und des zeitlich verteilten Sammeins von Erfahrungen damit - ein Sachverhalt, der unzweifelhaft zur Unterstützung der Akzeptanzförderung dient. Demgegenüber steht jedoch der nicht zu vernachlässigende Nachteil, daß diese Art der Umstellung i. d. R. spezielle Schnittstellen zu den Altsystemen und zur Infrastruktur der Datenhaltung sowie den teilweisen Parallelbetrieb dieser Systeme erfordert - ein Sachverhalt, der ebenfalls unzweifelhaft kostentreibend wird. Die punktuelle Gesamtumstellung vermeidet diese Kosten; sie ist aber nur dann zu empfehlen, wenn vorher eine präzise Konzeptionierung des Gesamtsystems mit entsprechender Anpassung stattgefunden hat, und wenn dem praktischen Einsatz ein umfassender Integrationstest sowie ein repräsentativer Probebetrieb vorangegangen ist.

5. Koordinationsfeld

„Wirtschaftlichkeit"

5.

Koordinationsfeld „Wirtschaftlichkeit"

5.1

Controllingziele

85

Das Controllinginteresse im Koordinationsfeld „Wirtschaftlichkeit" gilt dem Wirtschaftlichkeitsnachweis von IuK-Projekten und von Anwendungssystemen; die Controllingziele hierzu lauten • Nachvollziehbarkeit und Plausibilität der Wirtschaftlichkeitsrechnung und Nutzenbegründung von IuK-Projekten, • Konsistenz der ausgewiesenen Projektwirtschaftlichkeit zu den Wirtschaftlichkeitskriterien, die nach den Investitionsrichtlinien des Unternehmens einzuhalten sind, • Erkennen von Projektrisiken, • Transparenz und Eingrenzung der Folgekosten von IuK-Projekten, • Wirtschaftlichkeitsverfolgung einzelner IuK-Systeme über deren Nutzungszeit, • Definition von Entscheidungskriterien für die Ablösung von IuK-Systemen, • Schaffen der Voraussetzungen für die Vergleichbarkeit der Wirtschaftlichkeitsbegründung von IuK-Projekten, • Schaffen der Voraussetzungen für eine Wirtschaftlichkeitsfortschreibung von IuKSystemen.

5.2

Wirtschaftlichkeitskriterien

Als „Wirtschaftlichkeit" wird allgemein als das Verhältnis von Leistungen / Kosten bezeichnet. Eine so verstandene Wirtschaftlichkeit ist zur Bewertung von IuK-Projekten nur bedingt geeignet, denn die „Leistungen" von IuK-Systemen sind nicht ausschließlich monetär, d. h. quantitativ, sondern häufig nur qualitativ bewertbar, und qualitative Wertaussagen sind nicht selten das Resultat subjektiver Einschätzungen. Deshalb ist es erforderlich, den herkömmlichen Wirtschaftlichkeitsbegriff zu Zwecken der Bewertung von IuK-Systemen aus einer anderen Sichtweise zu interpretieren: aus der Sicht von Entscheidungen. Eine Entscheidung, die rational getroffen wird, besteht darin, diejenige Alternative zu wählen, durch die die Ziele, die für die Entscheidungssituation relevant sind, am besten erfüllt werden. Die Ziele können von sehr unterschiedlicher Art sein, es können quantitative Ziele wie z. B. Reduzierung von Kosten, Einhaltung von Terminen und Erzielen einer bestimmten Kapitalverzinsung sein, oder es können qualitative Ziele wie z. B. stärkere Kundenorientierung, Erhöhung der Marktpräsenz und Verbesserung der innerbetrieblichen Informationsversorgung sein. Maßgebend für die Beurteilung von Entscheidungsalternativen und damit für die ökonomische Rechtfertigung von IuK-Projekten oder für die Vorzugswürdigkeit verschiedener Systemlösungen ist das jeweils dadurch erreichbare Zufriedenheitsniveau oder der Zielerreichungsgrad, denn was als „gerechtfertigt" erscheint oder als „vorzugswürdig" gilt, kann logischerweise nur unter dem Aspekt von vorher definierten Zielen beurteilt werden. Deshalb soll der Begriff Wirtschaftlichkeit zu Zwecken der Bewertung von IuK-Projekten als „Ausmaß der Zielerreichung" interpretiert werden. Bezugsgrößen dazu sind die Ziele, die für ein IuK-

86

5. Koordinationsfeld

„Wirtschaftlichkeit"

Projekt formuliert wurden; das „Ausmaß der Zielerreichung" ist allerdings nicht als das Ergebnis eines Prozesses „um jeden Preis"zu verstehen, sondern als ein Ergebnis, das unter Bindung an die für das Investitionsvorhaben jeweils maßgeblichen Rahmendaten oder Restriktionen zustande gekommen ist. Ein so verstandener Wirtschaftlichkeitsbegriff ist zunächst nur eine Leerformel, die erst durch die Formulierung von konkreten Projektzielen an Inhalt gewinnt. Eine reine Aufzählung von denkbaren Zielen fiir IuK-Projekte ergibt keine sinnvollen Ansätze für eine Systematisierung von zielbezogenen Wirtschaftlichkeitsindikatoren; besser geeignet ist die Unterscheidung in quantitative und qualitative Projektziele (Abb. 50).

Abb. 50: Zielorientierter Wirtschaftlichkeitsbegriff

Quantitative Projektziele beinhalten Mengen-, Zeit- und Kostenvorgaben (z. B. Lagerbestände senken, Bearbeitungszeiten reduzieren, Fertigungskosten vermindern); das Ausmaß der Zielerreichung hierzu läßt sich direkt oder indirekt monetär quantifizieren. Direkt-monetär quantifizierbare Zielwirkungen sind solche, die sich in Form von Einsparungen an Produktionsfaktoren unmittelbar aus der Realisierung eines IuK-Projektes ergeben. Indirekt-monetär quantifizierbare Zielwirkungen sind solche, die sich als Sekundärfolgen ergeben; das sind z. B. zukünftige Kosteneinsparungen oder vermiedene Aufwendungen. Der gemeinsame Nenner der monetären Bewertbarkeit dieser Zielwirkungen erlaubt in Verbindung mit den dazu erforderli-

5. Koordinationsfeld „Wirtschaftlichkeit"

87

chen Kosten eine Verdichtung zur monetären (quantitativen) Wirtschaftlichkeit, die durch die Kriterien Kosteneinsparung, Amortisationsdauer und Kapitalverzinsung beurteilt werden kann. Die Verfahren, die zur Ermittlung der monetären Wirtschaftlichkeit herangezogen werden können, sollen hier als Verfahren zur Wirtschaftlichkeitsrechnung bezeichnet werden. Qualitative Projektziele beinhalten Vorgaben, deren Erreichung i. d. R. nicht mehr durch monetäre Wertansätze, sondern nur durch subjektive Wertschätzung beurteilt werden kann. Beispiele dazu sind Verbesserung der Entscheidungsbasis, Erhöhung der Flexibilität, Verbesserung Transparenz von Arbeitsabläufen, größere Kundennähe und verbesserte Servicequalität. Diesen Zielen fehlt der gemeinsame Nenner für eine monetäre Bewertung. Deshalb resultiert die nicht-monetäre (qualitative) Wirtschaftlichkeit grundsätzlich aus dem subjektiven Zufriedenheitsniveau über das Erreichen der qualitativen Projektziele. Da aber auch hierbei aus Gründen der Entscheidungsunterstützung „verdichtete", d. h. auf einen gemeinsamen Nenner gebrachte Wirtschaftlichkeitsaussagen erforderlich sind, werden zur Beurteilung der nichtmonetären Wirtschaftlichkeit Ersatzgrößen herangezogen, die auf Präferenzskalierungen oder Präferenzpositionierungen beruhen, oder es werden Argumentationsergebnisse akzeptiert, die auf Pro- und Contra-Argumenten zum Projektvorhaben beruhen. Durch Präferenzskalierungen wird das subjektive Zufriedenheitsniveau auf Punktwerte verdichtet, die die Zielwirkung oder die Vorzugswürdigkeit von Alternativen signalisieren (z. B. mehrdimensionale Nutzwertanalyse). Bei Präferenzpositionierungen werden die subjektiven Wertschätzungen durch Prioritäten ausgedrückt, die sich aus den Einstufungen in die Felder einer Positionierungsmatrix (z. B. Projektportfolio) ergeben. Argumentationsgewinne oder Argumentationsverluste sind das Ergebnis des Abwägens von verbalen Pro- und Contra-Argumenten zu einem Investitionsvorhaben in Form einer Argumente-Bilanz. Neben den eingangs dargelegten Problemen, die mit dem Wirtschaftlichkeitsbegriff in bezug auf IuK-Projekte verbunden sind, ergibt sich eine weitere Schwierigkeit für deren Wirtschaftlichkeitsbegründung: IuK-Systme sind heute längst aus der punktuellen Unterstützung für einzelne Abteilungen oder Arbeitsplätze herausgewachsen; das Potential der IuK-Unterstützungsmöglichkeiten hat dazu gefuhrt, daß nahezu das gesamte Prozeßgeschehen im Unternehmen von Planung, Entscheidung, Vollzug und Kontrolle auf IuK-Systemen beruht. Dieser Sachverhalt fuhrt zwangsläufig dazu, daß die Auswirkungen von Investitionen in eine zeitgemäße IuK-Infrastruktur sich nicht mehr nur auf einzelne Arbeitsplätze oder einzelne Abteilungen beschränken, sondern daß diese arbeitsplatzübergreifend, abteilungsübergreifend und auch unternehmensübergreifend durchschlagen. Zur Lösung des dadurch erschwerten Problems der Wirtschaftlichkeitsermittlung bietet sich die Sichtweise nach dem vierstufigen Wirtschaftlichkeitsmodell (Reichwald, 29) an: Zu Zwecken der Wirtschaftlichkeitsermittlung soll der Verbundwirkung von IuK-Systemen dadurch Rechnung getragen werden, daß alle direkten und indirekten Kosten- und Leistungskonsequenzen zu erfassen sind, die sich durch den Einsatz von IuK-Systemen am Arbeitsplatz, im Arbeitsplatzverbund, im Unternehmen und im Unternehmensumfeld ergeben. Verdichtungen und Saldierungen über die einzelnen Ebenen sind zu vermeiden, um dadurch den stufenweisen Wirtschaftlichkeitsausweis nicht zu beeinträchtigen; Abb. 51 erläutert dieses Modell näher.Die Verfahren, die zur Ermittlung der nicht-mone-

88

5. Koordinationsfeld

„Wirtschaftlichkeit"

t ä r e n W i r t s c h a f t l i c h k e i t h e r a n g e z o g e n w e r d e n k ö n n e n , sollen hier als V e r f a h r e n z u r N u t z e n ' begriindung bezeichnet werden.

Kurzbeschreibung der Wirtschaftlichkeitsstufen

Indikatoren (Grobdarstellung) Kosten

Leistungen

(W1) isolierte technikbezogene Wirtschaftlichkeit: hierunter werden sämtliche Indikatoren subsumiert, die unmittelbar der Kommunikationstechnik (Kanal einschließlich Endgerät) zuzurechnen sind

Personal- und Sachkosten, insbesondere Anlagenkosten und anfallende Gebühren

Menge, Schnelligkeit, Qualität und Zuverlässigkeit der Informationsübertragung

(W2) subsystembezogene Wirtschaftlichkeit: die vom Einsatzkonzept (z.B. dezentral) und anderen situativen Bedingungen abhängigen Kosten- und Leistungsgrößen werden im Hinblick auf subsystembezogene Verfahrensabläufe erfaßt

interne Transportkosten, Überwälzungskosten, Opportunitätskosten

Gesamtdurchlaufzeiten, Beschleunigung und qualitative Verbesserung von Verfahrensabläufen, Tätigkeitsverschiebungen zwischen den Betroffenen

(W3) gesamtorganisationale Wirtschaftlichkeit: Berücksichtigung der relevanten Kriterien; Aufgabenbewältigung, Flexibilität; Humanbereich bezüglich der langfristigen Funktionstüchtigkeit der Organisation

Kosten zur Aufrechterhaltung der Anpassungsfähigkeit und Funktionsstabilität, kostenrelevante Humanaspekte

Verbesserung der Anpassungsfähigkeit und der Funktionsstabilität der Organisation, Verbesserung der Humansituation

(W4) gesellschaftliche Wirtschaftlichkeit; potentielle (langfristige) Auswirkungen auf die organisatorische Umwelt

negative Auswirkungen

positive Auswirkungen bezüglich

Arbeitsmarkt, Gesundheits- und Sozialsystem, Ökologie, nationale und internationale Konkurrenzbedingungen, Kommunikationspartner anderer Organisationen

Abb. 51 : Vierstufiges Wirtschaftlichkeitsmodell (Reichwald, 29)

5.3

Wirtschaftlichkeitsrechnung

Z u r E r m i t t l u n g der m o n e t ä r e n (quantitativen) Wirtschaftlichkeit v o n I u K - P r o j e k t e n k ö n n e n d i e b e k a n n t e n V e r f a h r e n z u r I n v e s t i t i o n s r e c h n u n g h e r a n g e z o g e n w e r d e n . G r u n d l a g e f ü r die A n w e n d u n g dieser V e r f a h r e n sind die Kosten u n d die m o n e t ä r b e w e r t e t e n L e i s t u n g e n d e s g e p l a n ten I u K - S y s t e m s . D i e K o s t e n s e i t e läßt sich g r o b w i e folgt untergliedern (in A b b . 5 2 ist ein detailliertes G l i e d e r u n g s s c h e m a enthalten): •

Einmalige Kosten: - Personalkosten, - Sachkosten;

5. Koordinationsfeld

•

„Wirtschaftlichkeit"

89

Laufende Kosten: - Personalkosten, - Sachkosten.

Auf der Leistungsseite stehen den Kosten die direkt-monetär quantifizierbaren Zielwirkungen und die indirekt-monetär quantifizierbaren Zielwirkungen gegenüber. Die Verfahren zur Ermittlung der monetären (quantitativen) Wirtschaftlichkeit lassen sich untergliedern in einperiodische und mehrperiodische Verfahren: einperiodische Verfahren stellen nur auf eine Rechnungsperiode ab, indem sie von Durchschnittswerten der Kosten und Leistungen der Investition, bezogen z. B. auf ein Nutzungsjahr, ausgehen (sog. „statische Investitionsrechnung'), während bei mehrperiodischen Verfahren die Kosten und Leistungen verteilt über die gesamte Lebensdauer des Investitionsvorhabens in Ansatz gebracht werden (sog. „dynamische Investitionsrechnung"). Zu den einperiodischen Verfahren zählen die Kostenvergleichsrechnung, die Rentabilitätsrechnung und die Amortisationsrechnung. Beurteilungskriterium für die Wirtschaftlichkeit eines IuK-Projektes nach der Kostenvergleichsrechnung ist die erzielbare Kostenersparnis; sie ergibt sich aus dem Vergleich der durchschnittlichen Jahreskosten der geplanten Lösung mit den durchschnittlichen Jahreskosten der vorhandenen Lösung. Die einmaligen Kosten werden hierbei in Form von Abschreibungen auf die Jahre der geplanten Nutzungsdauer des IuKSystems (z. B. 5 - 10 Jahre) verteilt und mit einem kalkulatorischen Zinssatz verzinst; in Abb 52 ist ein Berechnungsschema dazu enthalten. Wesentliche Voraussetzung für eine aussagefähige Anwendung der Kostenvergleichsrechnung ist, daß die zu vergleichenden IuK-Lösungen nicht nur von der Kostenseite, sondern insbesondere von der Leistungsseite her überhaupt miteinander vergleichbar sind. Beurteilungskriterium für die Wirtschaftlichkeit eines IuK-Projektes nach der Rentabilitätsrechnung ist die geforderte oder die erzielbare Verzinsung der Investition; sie wird ermittelt aus dem Verhältnis der durchschnittlichen jährlichen Kosteneinsparung zu dem für die Investition erforderlichen Kapitaleinsatz. Der Kapitaleinsatz entspricht hier den Einmalkosten für das Investitionsvorhaben. Beurteilungskriterium für die Wirtschaftlichkeit eines IuK-Projektes nach der Amortisationsrechnung ist die geforderte oder die erzielbare Amortisationsdauer der Investition, die den Zeitraum angibt, der für die Wiedergewinnung des eingesetzten Kapitals erforderlich ist (sog.„Pay-off period"). Dazu wird der Kapitaleinsatz (Einmalkosten für das Investitionsvorhaben) durch den Betrag der jährlichen Wiedergewinnung (durchschnittliche Kostenersparnis + Abschreibungsquote auf den Kapitaleinsatz) dividiert. Die mehrperiodischen Verfahren berücksichtigen die zeitlich verteilten Einzahlungen und Auszahlungen, die mit einer Investion verbunden sind, durch zeitpunktbezogene Auf- oder

90

5. Koordimtionsfe Id „Wirtschaftlichkeit"

A. Einmalige Kosten

1. Personalkosten:

geplantes Verfahren

vorhandenes Verfahren

geplantes Verfahren

vorhandenes Verfahren

Entwicklungskosten EDV-Bereich: - Analyse - Konzeption - Programmierung - Test u. Integration - Dokumentation Entwicklungskosten Fachabteilung: - Analyse - Konzeption Entwicklungskosten Fremdfirmen Einführungskosten: - Schulung - org. Umstellung - Datenübernahme Beratungskosten Sonstige Projektkosten S U M M E einmalige Sachkosten

2. Sachkosten:

Fremdsoftware: -Kauf - Anpassung Hardware: -Kauf - Installation Hilfsgeräte Material: - Datenträger - Formulare Räume: - Netz-Installation - Neubau/Umbau - Klimatisierung - Arbeitsplatz-Ausstattung S U M M E einmalige Sachkosten

Abb. 52: Schema zur Kostenvergleichsrechnung

5. Koordinationsfeld „ Wirtschaftlichkeit"

B. Laufende Kosten 1. Personalkosten:

geplantes Verfahren

vorhandenes Verfahren

geplantes Verfahren

vorhandenes Verfahren

Arbeitsplatz Systemadministration Wartungskosten: -

Programmpflege Stammdatenpflege Hardwarewartung Netz-Wartung Hilfsgeräte-Wartung

externe Dienstleistungen SUMME laufende Personalkosten 2. Sachkosten: Betriebskosten: - Haidware - Netze DFÜ-Gebühren Sottware-Lizenzen Verbrauchsmaterial externe Servicenutzung Versicherungen Energie SUMME laufende Sachkosten C. Umlage der einmaligen Kosten Basis: x Jahre Nutzungsdauer, kalk. Zinssatz.

geplantes Verfahren

vorhandenes Verfahren

Abschreibungen p.a kalk. Zinsen aus 1/2 Investition SUMME Umlage Einmalkosten D. Laufender Nutzen p.a. geplantes Verfahren

vorhandenes Verfahren

aus Nutzenkategorie I aus Nutzenkategorie II aus Nutzenkategorie III SUMME periodischer Nutzen E. Rechnerische Wirtschaftlichkeit geplantes Verfahren

vorhandenes Verfahren

Periodischer Nutzen Periodische Kosten ./. lfd. Personalkosten ./. lfd. Sachkosten ./. Umlage Einmalkosten Periodische Wirtschaftlichkeit

Abb. 52:Schema zur Kostenvergleichsrechnung

91

92

5. Koordinationsfeld

„

Wirtschaftlichkeit"

Abzinsung (Diskontierung von Einzahlungs- und Auszahlungsreihen). Die Verfahren, die dazu üblicherweise benutzt werden, sind die Kapitalwerthode und die Methode des internen Zinssatzes. Der Kapitalwert einer Investition ergibt sich aus den diskontierten Rückflüssen (Einzahlungen - Auszahlungen), abzüglich des Kapitaleinsatzes im Bezugszeitpunkt. Die Diskontierung erfolgt mit einem kalkulatorischen Zinssatz, der die geforderte Mindestverzinsung des Investitionsvorhabens aus der Sicht des Entscheidenden darstellt: KW = R,-l/(l+p) + R 2 -l/(l+p) 2 + - + R„'l/(l+p) n +L-l/(l+p) n - J 0 wobei:

KW R„

p L

= Kapitalwert = Jährliche Rückflüsse (Differenz zwischen jährlichen Einnahmen und Ausgaben) = Nutzungsdauer der Investition = Kalkulatorischer Zinssatz = Liquidationserlös aus der Investition am Ende der Nutzungsdauer

Jo l/(l+p)"

= Kapitaleinsatz für das Investitionsvorhaben im Bezugszeitpunkt = Abzinsungsfaktor

n

Der Kapitalwert ist wie folgt zu interpretieren: KW = 0 : Die Einzahlungsüberschüsse (Rückflüsse) reichen gerade aus, um die Investition zum kalkulierten Zinssatz zu verzinsen (Erfüllung der geforderten Mindestverzinsung). KW > 0: Es wird eine Verzinsung erzielt, die über der geforderten Mindestverzinsung liegt; die Höhe des Kapitalwertes gibt den Einzahlungsüberschuß über den Kapitaleinsatz zum Bezugszeitpunkt an. KW < 0: Es wird eine Verzinsung erzielt, die unter der geforderten Mindestverzinsung liegt; die Höhe des Kapitalwertes gibt das ungedeckte Defizit des Kapitaleinsatzes zum Bezugszeitpunkt an. Bei der Methode des internen Zinssatzes wird nicht von einer geforderten Mindestverzinsung für das Investitionsvorhaben ausgegangen, sondern es wird der Diskontierungszinssatz ermittelt, der zu einem Kapitalwert KW = 0 fuhrt. Dadurch erhält man die effektive Verzinsung des Investitionsvorhabens. Diese ist dann mit der geforderten Soll-Verzinsung zu vergleichen; vorteilhaft ist die Investition dann, wenn der errechnete interne Zinsatz der Soll-Verzinsung entspricht oder diese überschreitet.

5.4

Nutzenbegriindung

Zur Ermittlung des Nutzens, d. h. der nicht-monetären (qualitativen) Wirtschaftlichkeit von IuK-Projekten sind mehrdimensionale Bewertungsverfahren heranzuziehen, denn eine Verdich-

5. Koordinationsfeld „Wirtschaftlichkeit"

93

tung der unterschiedlichen Nutzeffekte, die durch solche Projekte bewirkt werden können, auf eine einzige, monetäre Zielgröße ist nicht möglich. Folgende Verfahren eignen sich dazu: • Verbale Nutzenbeschreibung, • Nutzenwirkungsnetz, • Multifaktorenverfahren, • Nutzwertanalyse, • Argumentebilanz, • Mehr-Ebenen-Modell der Wirtschaftlichkeit. Das gemeinsame Merkmal dieser Verfahren ist, daß sie versuchen, das „Zufriedenheitsniveau" über die geplante Zielerreichung so strukturiert wie möglich darzustellen, um dadurch die subjektiven Einschätzungen der verschieden möglichen Auswirkungen von IuK-Systemen - den Nutzen - so weit wie möglich transparent und nachvollziehbar zu gestalten. Verfahren zur Nutzenbegründung sollten möglichst nur ergänzend zu einer Wirtschaftlichkeitsrechnung von IuK-Projekten -und sei diese auch noch so rudimentär -angewendet werden, den i. d. R. orientieren sich Entscheidungen über Projektvorhaben in diesem Bereich zunächst an monetären Wirtschaftlichkeitskriterien. Die verbale Nutzenbeschreibung wird dieser eben genannten Forderung nach Strukturierung nicht gerecht, aber sie ist ein in der Praxis weit verbreitetes Verfahren: die vermuteten Nutzeffekte von IuK-Projekten werden verbal, d. h. weitgehend unstrukturiert, formuliert; die Transparenz und die Nachvollziehbarkeit der Nutzenbegründung leidet dadurch zwangsläufig. Das Nutzenwirkungsnetz vermeidet diese Nachteile: die voraussichtlichen Nutzeffekte werden einzeln aufgeschlüsselt und in ihrem Wirkverbund dargestellt. Gemeinsamer „Nenner" der Nutzenwirkungen sind Zeit und Kosten, weshalb es möglich ist, ein solches Netz letztlich auf monetäre Wirtschaftlichkeitskriterien konvergieren zu lassen (s. Abb. 53). Nach dem Multifaktorenverfahren (Abb. 54) werden die Nutzenindikatoren, die für das IuKProjekt relevant sind, zunächst aufgelistet; anschließend wird nach Maßgabe dieser Indikatoren durch eine Bewertungsskala der Nutzen ermittelt. Dazu werden die Nutzenkriterien mit Vorgabefaktoren - diese sind Ausdruck der subjektiven Erwartungshaltung über die Wirkungen des geplanten IuK-Systems - versehen (Spalte B in Abb.54). Diesen Vorgabefaktoren werden die Erfüllungsfaktoren - diese sind Ausdruck der subjektiven Einschätzung über die tatsächlichen Wirkungen - gegenübergestellt (Spalte A in Abb. 54). Durch Multiplikation der Spaltenwerte A x B und durch Bildung des Quotienten der Spaltensummen C und B erhält man den NutzenkoefTizienten des IuK-Projektes. Wesentlich ist hierbei, daß die Nutzenkriterien nicht individuell und unterschiedlich für jedes einzelne IuK-Projekt formuliert werden, sondern daß ein einheitlicher Katalog von Nutzenkriterien vorliegt, der zur „qualitativen Meßlatte" für IuK-Projekte wird; erst dadurch ergibt sich die Vergleichbarkeit der Nutzenkoeffiziente der Projekte.

94

5. Koordinationsfeld

„Wirtschaftlichkeit"

PPS-System

mi

Materialwirtschaft

Bereich

Nutzenpotentiale

Dispositionsqualität

bessere Einkaufs-1 bündelung

Engpässe 1-

+ +

Wirkungsnetz

gleichmässigere Auslastung

1 |

Wartezeiten

|

w

+1

Rüstzeiten-

1

Auftragsdurchlaufzeit 1-

1 |

Lieferbereitschaft T Bezugsgrößen

[

Liefertermintreue '

Kosten/ Erlös-Struktur

Erlös

1 1

+

1

Anzahl der Bestellungen

1 |

+i |

Bestellkosten

|

Abb. 53: Nutzenwirkungsnetz (Quelle: Eisele/Schwan, S. 43)

Die Nutzwertanalyse ist ein Verfahren zur Bewertung von Entscheidungsalternativen, das es ermöglicht, subjektive Präferenzen und Werturteile in die Bewertung mit einzubeziehen. Das Vorteilhaftigkeits- oder Nutzenkriterium nach einer Nutzwertanalyse ist der Erfiillungsgrad der Bewertungskriterien; dieser ergibt sich aus der Verdichtung von Einzelwertungen zu Präferenzpunkten. Die Durchführung einer Nutzwertanalyse ist bereits in Kapitel 3.2.4. dargestellt worden. In der Argumentebilanz werden Vorteile und Nachteile, die mit einem IuK-Projekt verbunden sind, als verbale „Wertschätzungs-Aktiva" und „Wertschätzungs-Passiva" gegenübergestellt; die Aktiva und Passiva können dazu noch in positive / negative Innen-und Außenwirkungen

5. Koordinationsfeld„

Wirtschaftlichkeit"

Nutzenkriterien:

A

B

C

-

1 1 3 0 2 3 3 2 3 0 0

3 3 2 0 3 1 2 2 2 0 0

3 3 6 0 6 3 6 4 6 0 0

18

37

Kostenreduzierung Zeitreduzierung Qualität Schnelligkeit Flexibilität Entscheidungsunterstützung Auskunftsbereitschaft Sicherheit Anwenderfreundlichkeit Kapazitätsreserve Transparenz

SUMME:

95

Erläuterung: A = Erfüllungsfaktoren B = Vorgabefaktoren C =Ax B Bedeutung der Faktorenwerte: +/-3 = +1-2 = +/-1 = 0 =

erhebliche Veränderung deutliche Veränderung geringfügige Veränderung keine Veränderung

Ergebnis: Summe C/Summe B = Nutzenkoeffizient nach Beispiel: 37/18 = 2,05 (deutliche Verbesserung) Abb. 54: Beispiel zur Multifaktorenmethode

untergliedert werden (Abb. 55). Durch den abwägenden Vergleich von Vorteilen und Nachteilen ist dann ein „Argumente-Gewinn" oder „Argumente-Verlust" verbal herauszuarbeiten; dies kann dadurch unterstützt werden, daß fur jede einzelne Position der Aktiva und Passiva nach Art der Meta-Planmethode Bewertungspunkte vergeben werden, die sich zu einem positiven oder negativen Punkte-Saldo verdichten lassen. Das Mehr-Ebenen-Modell der Wirtschaftlichkeit ist besonders dazu geeignet, Wirtschaftlichkeits- und Nutzenaspekte von IuK-Systemen auf verschiedenen Wirkungsebenen - z. B. Arbeitsplatz, Arbeitsplatzverbund, Gesamtunternehmung, Unternehmungsumwelt - zu veranschaulichen. Die Zuordnung der Nutzeffekte erstreckt sich auf die Kosten für die Organisation und den quantitativen und qualitativen Nutzen für Organisation und Mitarbeiter. Daraus ergibt sich eine Mehrfelder-Matrix, in der zu Zwecken der Wirtschaftlichkeitsbeurteilung die direkten und indirekten Kosten- und Leistungswirkungen ausgewiesen werden, die sich kurz-oder mittelfristig als Konsequenzen von IuK-Systemen fur die jeweilige Bewertungsebene ergeben. In Abb. 56 ist ein Beispiel dazu dargestellt.

96

5. Koordinationsfeld

„Wirtschaftlichkeit"

SYSTEMVORTEILE ("AKTIVA") 1. Innenwirkungen Direkte Wirkungen Erhöhung der Fertigungskazaprtäten Rüstzeitreduzierung Bessere Auslastung Reduzierung der Losgrößen Höhere Flexibilität Steigende Produktivität Höherer Planungsgrad Durchlaufzeitreduzierung Verbesserte ProduktquaTität Direktkosten-Reduzierung Lohngemeinkosten-Reduzierung

SYSTEMNACHTEILE ("PASSIVA") 1. Innenwirkungen Taktzeiterhöhung Gemeinkostensteigerung Kapitalkostensteigerung Ausbildungskosten Instandhaltungskosten DV-Planungsaufwand Akzeptanz der Anwender Finanzielles Risiko Einführungsrisiko Risiko der nichtabgestimmten Kapazitäten

Indirekte Wirkungen Kapazitätsnutzung durch bedienarme Schichten Kontinuierlicher Materialfluß Systematisierung des Produktionsprogramms Nutzung des Leistungspotentials durch effiziente Materiallogistik Beherrschte Fertigung Erhöhte Lieferbereitschaft Qualitätssicherung durch Qualitätskontrolle Qualitätssicherung durch Selbstkontrolle Integrierter Informationsfluß Mitarbeiterausbildung Innovationsfreundlichkeit Behebung von Engpässen Technologie-Know-How-Gewinn

Ii. Außenwirkungen Großer Anspruch an DV-Programme Programmierkapazität Zulieferprobleme

III. Argumentengewinn der neuen Technologie

II. Außenwirkungen Qualitätssteigerung Flexibilität, rasche Marktanpassung Schnelle Reaktionauf Kundenwünsche Imageeffekt Liefertreue

Abb. 55: Argumentebilanz für Flexible Fertigungssysteme (Schumann/Mertens/Haspel, S.22)

5. Koordinationsfeld

Zuordnung ^ x . der ^\Effekte Bewertung^, ebene

Ebene 1: Arbeitsplatz

Ebene 2: Arbeitsplatzverbund

Ebene 3: Gesamtunternehmung

Ebene 4: Unternehmungsumwelt

Kosten für Organisation

„Wirtschaftlichkeit"

97

Nutzen für Organisation und Mitarbeiter

quantitativ/qualitativ

quantitativ

qualitativ

-Personalkosten -Ausstattungskosten (Technik, Mobiliar, Ergonomie) -Ausbildungskosten -Betriebskosten

-Arbeitsmenge -Qualität der Leistung -Aufgabenstruktur, z.B. - Be a rbe rtungsze ite n verbesserte Möglichkeiten -Abwesenheitszeiten -Koordinationsaufwand der Aufgabenintegration -Qualifikations-Fehlerquote anforderungen -Belastung -Arbeitsplatzkomfort -Kosteneinsparungen

-Kosten der Organisationsanalyse und -gestaltung -Qualifikationskosten -Implementierungskosten - Aussta ttu ngskosten -Betriebskosten -Kosten des innerbetrieblichen Transports

-Durchlaufzeit -Tätigkeitsvielfalt -Liege-, Transport- und -Bearbeitungsqualität -Verbundrationali-Rüstzeiten sierung -Produktivität -Erreichbarkeit •Abstimmungszeit -Bearbeitungsaufwand

-Infrastrukturen -Personal kosten -Reorganisationskosten -Ausbildungskosten -Beratungskosten

-Reaktionszeiten -Straffung der Abläufe -Führungsaufwand •Konfiguration

negative Auswirkungen bezüglich Aufgabenumwelt und der generellen Umwelt (Gesellschaft, Arbertsmarkt, Konkurrenz, Kunden, etc.)

-Flexibilität -Verbesserung der Humansituation -Inhaltliche Qualität der Leistung -Innovationsfähigkeit -Entscheidungsqualität -Individualisierung der Marktbe dienung

positive Auswirkungen bezüglich Aufgabenumwelt und der generellen Umwelt (Gesellschaft, Arbeitsmarkt, Konkurrenz, Kunden, etc.)

Abb. 56: Beispiel für ein Mehr-Ebenen-Bewertungsmodell (Beschorner, S. 348)

5.5

Risikoanalyse von IuK-Projekten

Durch die verschiedenen Verfahren zur Wirtschaftlichkeitermittlung kann dargelegt werden, welche quantitative und qualitative Wirtschaftlichkeit ein IuK-Projekt aufweist. Die vielfältigen Risiken jedoch, die mit der Entwicklung und Implementierung eines IuK-Systems verbunden sein können, lassen sich im Rahmen dieser Verfahren nur sehr beschränkt explizit darstellen und berücksichtigen - z. B. durch einen pauschalen Risikozuschlag auf den kalkulatorischen Zinssatz im Rahmen eines der Verfahren zur Wirtschaftlichkeitsberechnung. Deshalb ist es angebracht, die Wirtschaftlichkeitsermittlung durch eine projektspezifische Risikoanalyse zu ergänzen. In Abb. 57 sind Risikofaktoren dargestellt, die dazu eine Orientierungshilfe sein können.

98

5. Koordinationsfeld „Wirtschaftlichkeit"

•

•

•

•

•

•

Risiken aus dem Projekt: - Innovationscharakter, - Komplexität, (Anzahl der Schnittstellen zu anderen luK-Systemen), - Präzisierung der Projektvorgaben, - Strukturierung der fachlichen Anforderungen, - geplante Projektdauer; Risiken aus dem Projektmanagement: - Zeit- und Kostenschätzungen, - Verfügbarkeit und Ausgereiftheit von Entwicklungswerkzeugen; Risiken aus dem Projektteam: - Teamgröße, - Teamzusammensetzung, - Verfügbarkeit der Teammitglieder, - Regelung der Zuständigkeiten, - Mitwirkung der Anwenderseite, - Qualifikation der Teammitglieder, - Kohäsion des Teams, - Fluktuationsgefahr von Spezialisten, - Projektleitung (Fachkompetenz, Führungskompetenz), Risiken aus der luK-lnfrastruktur: - Verfügbarkeit und Stabilität von Software, - Verfügbarkeit und Stabilität von Hardware; Risiken bei der Systemeinführung: - Benutzerakzeptanz, - Schulung der Benutzer; Risiken aus dem Projektumfeld: - Unterstützung durch die Geschäftsleitung, - Änderung in der Zusammensetzung von Entscheidungsträgem, - gesetzliche Vorgaben.

Abb. 57: Risikofaktoren von luK-Projekten

D a d i e R i s i k o f a k t o r e n v o n I u K - P r o j e k t e n s o w o h l v o n quantitativer, w i e a u c h v o n qualitativer Art sind, gibt es keinen gemeinsamer N e n n e r zu deren V e r d i c h t u n g in eine signifikante " R i s i k o k e n n z a h l " . U m die den einzelnen I u K - P r o j e k t e n inhärenten Risiken d e n n o c h zu v e r a n s c h a u l i c h e n , b i e t e n sich P o l a r k o o r d i n a t e n d i a g r a m m e o d e r P o l a r i t ä t s d i a g r a m m e an ( A b b . 5 8 ) , d u r c h d i e d a s p r o j e k t s p e z i f i s c h e Risikoprofil dargestellt w e r d e n kann; a u s diesen R i s i k o p r o f i len l a s s e n sich d a n n d u r c h Interpretation der „Risikofläche" ( P o l a r k o o r d i n a t e n d i a g r a m m ) o d e r der „ R i s i k o d i s t a n z e n " (Polaritätsdiagram) RisikokoefTizienten ableiten, die als d i m e n s i o n s l o s e F a k t o r e n in eine N u t z w e r t a n a l y s e v o n I u K - P r o j e k t e n eingehen k ö n n e n ( A b b . 59).

5. Koordinationsfeld„ Wirtschaftlichkeit" Risiken aus dem Projektteam r3

Re Risiken aus dem Projektumfeld Ri....Rn= Risikofaktoren für DV-Projekte Abb. 58a: Risikoprofil von luK-Projekten

-3

Risikofaktor

-2

-1

0

+1

9fc

Risiken aus dem Projekt Risiken aus dem Projektmanagement

+2

i k- - 7' *

Risiken aus dem Projektteam

1 i

Risiken aus der luKInfirastruktur

..

..

„-

Risiken aus der Systemeinführung

w

Risiken aus dem Projektumfeld

#

\

i

Abb. 58b: Risikoprofil von luK-Projekten

n

9

+3

99

100

5. Koordinationsfeld

„Wirtschaftlichkeit"

Bewertungs- Gewichtung Alternative kriterien

Alternative

Alternative

2

3

1

(G)

Alternative 4

(E)

(N)

(E)

(N)

(E)

(N)

(E)

(N) 100

Kriterium A

10

10

100

10

100

10

100

10

Kriterium B

32

0

0

0

0

1

32

0

0

Kriterium C Kriterium D Kriterium E

3 38 7

10 5

30 190 14

5 3

15 114

0 342

8 0

10

5

0 5

10

1 9

42 0

24 0 70

Kriterium F

6 0

0 9 0

18

5

45

8

72

5 3

27

Kriterium G XGewichtung

2 10 2

5

100

Nutzwert (Punkte-Summe) Rangfolge nach Punktsumme Risikofaktor (R) Nutzwert (risikogewichtet) Rangfolge nach Risiken

362

316

551

226

2 0,1

3 0,7

1 0,5

4 0,3

36

221

275

68

1

3

4

2

E = Kriterienerfüllung (0-10) N = G x E = gewichtete Kriterienefüllung Abb. 59: Berücksichtigung von Projektrisiken im Rahmen derNutzwertanalyse

5.6

Priorisierung von IuK-Projekten

N a c h d e m die Wirtschaftlichkeit der einzelnen IuK-Projekte ermittelt w o r d e n ist, sind diese in A n s e h u n g beschränkter R e s s o u r c e n für die Projektdurchiuhrung nach ihrer Dringlichkeit zu untergliedern. F o l g e n d e Entscheidungskriterien können dazu herangezogen werden: •

Technische N o t w e n d i g k e i t e n : - A b l ö s u n g v o n Altsystemen w e g e n Auslaufens der U n t e r s t ü t z u n g von H a r d w a r e und Software, - A n p a s s e n v o n IuK-Systemen wegen grundlegender Ä n d e r u n g e n in der IuK-Infrastruktur, - A n p a s s e n v o n IuK-Systemen und der IuK-Infrastruktur w e g e n Unternehmensfusion;

•

ExtemeVorgaben: - gesetzlicheAuflagen, - überbetriebliche A n f o r d e r u n g e n ;

•

Erzielen von Wettbewerbsvorteilen;

•

U n t e r s t ü t z u n g der kritischen Erfolgsfaktoren des Unternehmens;

•

A m o r t i s a t i o n s d a u e r des Entwicklungsaufwands.

5. Koordinationsfeld„

Wirtschaftlichkeit"

101

Technische Notwendigkeiten und externe Vorgaben gruppieren entsprechende Projektvorhaben per se in die Kategorie von Muß-Projekten. Bei den weiter angeführten Kriterien ist eine differenziertere Betrachtung zur Dringlichkeit von IuK-Projekten angebracht, da hier insbesondere das Erzielen von Wettbewerbsvorteilen, die als qualitative Wirtschaftlichkeit ausgewiesen sein können, gegen das Ausmaß quantitativer Wirtschaftlichkeitabzuwägen ist. Das geeignete Instrument hierzu ist das Projektportfolio (s. Kap. 3.2.5). Die für ein Projektportfolio üblichen beiden Dimensionen „strategische Bedeutung" / „monetäre Wirtschaftlichkeit" kann um eine dritte Dimension erweitert werden, durch die das Ausmaß der Unterstützung der Erfolgsfaktoren des Unternehmens durch die jeweiligen IuK-Projekte visualisiert wird (Abb. 60). Eine weitere Variante des Projektportfolios ergibt sich aus den beiden Dimensionen „Projektnutzen" / „Realisierbarkeit des Projektnutzens"(Abb. 61). Aus der Positionierung der einzelen Projektvorhaben in den Feldern eines Projektportfolios resultiert dann die Empfehlung für deren Dringlichkeitsklassifizierung.

strategische Bedeutung "

hoch

©

mittel

niedrig

©

#

o

o

0

Einbeziehen von Erfolgsfaktor in als dritte Dim ension niedrig

mittel

© hoch Wirtschaftlichkeit (monetär)

Abb. 60: Portfolio-Bewertung von IuK-Projekten (Nagel, S. 62)

5.7

Lebenszykluskosten

Um die Wirtschaftlichkeit von IuK-Systemen über deren Nutzungszeit zu verfolgen, ist es notwendig, eine lebenszyklusbezogene Kostenfortschreibung durchzuführen. Das Vorgehensmodell, das der Softwareentwicklung zugrundeliegt, umfaßt üblicherweise die Phasen Situationsstudie, Fachkonzeption, Systemkonzeption, Systementwicklung und Systeminstallation, die insgesamt den Entwicklungsabschnitt eines Softwaresystems repräsentieren, erst

102

5. Koordinationsfeld

„ Wirtschaftlichkeit"

Projektnutzen

Ber aich ProjBkte

kurzfristig

mittelfristig

langfristig

Realisierbarkeit des Projektnutzens Abb. 61: Projektportfolio

durch das Einbeziehen der Phase „Systembetrieb" mit den darin anfallenden Folgekosten für • laufenden Betrieb, • Anpassungswartung, • korrigierende Wartung, • verbessernde Wartung und • Systemstillegung entsteht eine vollständige Lebenszyklusbetrachtung eines Anwendungssystems. Diese Betrachtungsweise, in der Entwicklungskosten, Einführungskosten und Folgekosten eines Softwaresystems zusammengeführt werden, ermöglicht eine sachliche fundierte Entscheidung über Sanierung oder Ablösung eines Anwendungssystems nach dem Investitionskalkül, z. B. durch Vergleich der periodisierten Kosten des Altsystems mit den periodisierten Kosten des Nachfolgesystems. Für das DV-Controlling sollte es eine vorrangige Aufgabe sein, die Lebenszykluskosten für jedes IuK-System zu gesondert zu erfassen und zu analysieren. Dadurch wird die Grundlage für ein lebenszyklusorientiertes Produktcontrolling geschaffen, das nicht nur zur Effizienzsteigerung der Produktentwicklung dient, sondern auch entscheidungsrelevante Informationen dazu liefert, wann eine Produktablösung angebracht ist, welche Konsequenzen sich daraus ergeben und mit welchem Vorlauf Nachfolgeprodukte zu entwickeln oder zu beschaffen sind.

ó. Koordinationsfeld „Anwendungsbetrieb und DV-Infrastruktur"

6. 6.1

103

Koordinationsfeld „Anwendungsbetrieb und DV-Infrastuktur" Controllingziele

Im Koordinationsfeld "Anwendungsbetrieb und DV-Infrastruktur" liegen die Schwerpunkte des Controllings in den Bereichen Datenschutz und Datensicherung (Sicherheitsmanagement), Änderungsdienst und Pflege von IuK-Systemen (Wartungsmanagement), laufender Betrieb von IuK-Systemen (Produktionsmanagement) sowie Unterstützung und Betreuung der Anwender (Benutzerservice). Die Controllingziele für diese Bereiche lauten: •

eine Sicherheitspolitk, die sich an der Risikorelevanz der IuK-Systeme orientiert,

•

ein stringentes Management des Änderungsdienstes an IuK-Systemen,

•

Transparenz und Eingrenzung der Folgekosten von IuK-Systemen,

•

Definition von Entscheidungskriterien für die Ablösung von IuK-Systemen,

•

bedarfsgerechte Dimensionierung der Kapazität der DV-Infrastruktur,

•

Optimierung der Ressourcennutzung,

•

Effizienz der Benutzerbetreuung,

•

Vermeiden von "Wildwuchs" im Bereich der benutzerindividuellen Datenverarbeitung, d. h. Vermeiden von Hardware- und Software-Inkompatibilitäten, Vermeiden von doppelten Systementwicklungen und Wahrung der Konsistenz der Datenhaltung.

6.2

Sicherheitsmanagement

Der Datenschutz dient dazu, den Bürger davor zu schützen, daß er durch die Verwendung von Daten über ihn in seinem Persönlichkeitsrecht beeinträchtigt wird. Verwendung bedeutet in diesem Zusammenhang das Speichern, Verändern oder Übermitteln von personenbezogenen Daten, d. h., von Einzelangaben über persönliche oder sachliche Verhältnisse natürlicher Personen. Gesetzliche Vorschriften (Bundesdatenschutzgesetz, hier insbes. § 6 und Anlage dazu) umreißen die Maßnahmen, die zur Realisierung des Datenschutzes im Einzelfall zu ergreifen sind •

Zugangskontrolle (Unbefugten ist der Zugang zu Datenverarbeitungssystemen, mit denen personenbezogene Daten verarbeitet werden, zu verwehren)

•

Abgangskontrolle (Personen, die bei der Verarbeitung personenbezogener Daten tätig sind, sind daran zu hindern, daß sie Datenträger unbefugt entfernen)

•

Speicherkontrolle (Die unbefugte Eingabe in Datenspeicher sowie die unbefugte Kenntnisnahme, Veränderung oder Löschung von gespeicherten personenbezogenen Daten ist zu verhindern)

•

Benutzerkontrolle (Die Benutzung von Datenverarbeitungssystemen, aus denen oder in die personenbezogene Daten durch selbsttätige Einrichtungen übermittelt werden, ist zu verhindern)

104

6. Koordinationsfeld„Amvendungsbetrieb undDV-Infrastruktur"

• Zugriffskontrolle (Es ist zu gewährleisten, daß die zur Benutzung eines Datenverarbeitungssystems Berechtigten durch selbsttätige Einrichtungen ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden personenbezogenen Daten zugreifen können) Übermittlungskontrolle (Es ist zu gewährleisten, daß überprüft und festgestellt werden kann, an welche Stellen personenenbezogene Daten durch selbsttätige Einrichtungen übermittelt werden können) • Eingabekontrolle (Es ist zu gewährleisten, daß nachträglich geprüft und festgestellt werden kann, welche personenbezogenen Daten zu welcher Zeit von wem in Datenverarbeitungssysteme eingegeben worden sind) •

•

Auftragskontrolle (Es ist zu gewährleisten, daß personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können) • Transportkontrolle (Es ist zu gewährleisten, daß bei der Übermittlung personenbezogener Daten sowie beim Transport entsprechender Datenträger diese nicht unbefugt gelesen, verändert oder gelöscht werden können) •

Organisationskontrolle (Die innerbetriebliche Organisation ist so zu gestalten, daß sie den besonderen Anforderungen des Datenschutzes gerecht wird)

Die Realisierung dieser Maßnahmen muß in einem angemessenen Verhältnis zum angestrebten Schutzzweck stehen; daraus folgt, daß im Einzelfall solche Vorgaben nicht erfüllt werden müssen, für die die Voraussetzungen aufgrund der speziellen Gegebenheiten der DV-Organisation und der DV-Infrastruktur fehlen. Das Prüfen der Existenz und das Überwachen der Einhaltung der Maßnahmen zum Datenschutz obliegt vorrangig dem Datenschutzbeauftragten des Unternehmens; es stellt aber hinsichtlich der konkreten Ausgestaltung der Schutzmaßnahmen und wegen der Nähe zur Datensicherheit gleichfalls ein Aufgabengebiet für das DV-Controlling dar. Im Gegensatz zum Datenschutz, durch den die Interessen von Personen geschützt werden, hat die Datensicherung die Aufgabe, für einen störungsfreien Betrieb der IuK-Systeme zu sorgen und deren unberechtigte Nutzung sowie die Zerstörung und den Verlust von Daten zu verhindern. Die Gefahren, gegen die der Anwendungsbetrieb zu schützen ist und die entsprechende Abwehrmaßnahmen erfordern, lassen sich untergliedern in • • • •

Systemversagen Systemversagen Systemversagen Systemversagen

durch durch durch durch

Hardware-Defekte, Software-Defekte, Netz-Defekte, fehlerhafte oder fahrlässige Bedienung,

6. Koordinationsfeld„Anwendungsbetrieb

undDV-Infrastruktur"

•

Systemversagen durch Umwelteinwirkung (Feuer, Wasser, Blitzschlag),

•

Systemversagen durch deliktische Handlungen.

105

V o n diesen Gefahren ist die der deliktischen Handlungen am bedeutendsten, denn durch die Dezentralisierung der Hardware- und Software-Infrastruktur sowie durch die Vernetzung der Systemkomponenten und durch Datenfernübertragung haben sich die Angriffsflächen von IuKSystemen erheblich erweitert: zu den bisher schon an zentralen DV-Systemen

und

an

Arbeitsplatzssystemen möglichen deliktischen Handlungen wie z. B. unbefugter Zugriff auf Daten, Manipulation von Daten und Programmen, Zeitdiebstahl oder Systemsabotage kommen für vernetze Anwendungen noch hinzu die Möglichkeit des Abhörens und Abzweigens v o n Daten, das beabsichtigte Erzeugen von Netzüberlastungen durch Übertragung von Fülldaten und das Einschleusen von Viren. Zur Abwendung dieser und der anderen genannten Gefahren steht ein breites Spektrum von Maßnahmen zur Verfügung, dessen Übersicht in Abb. 6 2 zusammengefaßt ist.

• Bauliche Sicherheitsmaßnahmen: zerstörungssichere Standorte für zentrale Komponenten, bauliche Ausgestaltung, Energieversorgung und Energiesicherung, Brand- und Wassermeldesysteme, Zutrittskontrollsysteme; • Organisatorische Sicherheitsmaßnahmen: Funktionstrennung (.Vier-Augen-Prinzip"), Authentisierung, Kontrollmaßnahmen nach $ 6 BDSG, Maßnahmen für den Katastrophenfall wie z. B. Back-up-Lösungen für Rechenzentren (Betrieb von Duplex-Anlagen, Anmieten eines mobilen NotRechenzentrums im Container, Vorhalten von angemieteter NotAusweichkapazität, Vorhalten von gemeinschaftlich betriebenen NotRechenzentren); • Software-Sicherheitsmaßnahmen: Schutzfunktionen im Rahmen des Betriebssystems, der Netzsoftware und des Datei- oder Datenbankverwaltungssystems, Kontrollfunktionen in Anwendungssystemen; • Hardware-Sicherheitsmaßnahmen: redundante Bauelemente, Spiegelung von Festplatten, Diagnoseund Teleservicemodule; • Sicherheitsmaßnahmen für Netze: Netz-Authentisierung, krytographierte Datenübertragung, Zugangsund Zugriffsprotokollierung, Trusted-path-Einrichtungen; • Sicherheitsmaßnahmen für Arbeitsplatzcomputer: mehrstufige Paßworte, systemgesteuerter Paßwortwechsel, benutzerabhängige Freischaltung von Systemfunktionen, Verbot des privaten Installierens von Software („diskless stations"), Vorinstallation von fremdbezogener Software in „Quarantänestationen", Zwangssicherung bei Abmelden oder Abschalten, Benutzungsprotokollierung (Logfiles).

Abb. 62: Übersicht zu den Maßnahmen zur Datensicherheit (nach Krallmann, 85)

106

6. Koordinationsfeld

„Anwendungsbetrieb

und

DV-Infrastruktur"

Für das Sicherheitsmanagement stellt sich in Ansehung der vielfältigen Gefahren und deren Abwehrmaßnahmen die Frage, für welche Bereiche der unternehmensweiten IuK-Infrastruktur welche Sicherheitsmaßnahmen risikogerecht zu ergreifen sind, und ob neben der dadurch geschaffen Eigenversicherung noch Fremdversicherungen wirksam werden sollen. Dazu sind folgende Fragen zu beantworten: •

Welche Bereiche der IuK-Infrastruktur können durch welche Gefahren bedroht werden? • Welche Sicherheitsschwachstellen weisen diese Bereiche auf? • Welches sind die risikokritischen Anwendungen des Unternehmens? • Welche Sicherheitsmaßnahmen sind den risikokritischen Anwendungen zuzuordnen?

Zur Beantwortung der ersten Frage ist es zweckmäßig, zunächst die unternehmensweite IuKInfrastruktur in signifikante Risikofelder zu untergliedern; dies können z. B. zentrale Systeme, dezentrale Systeme, lokale Netze mit Servern, Schnittstellen zu öffentlichen Netzen, die Datenhaltung und die Benutzeroberfläche sein. Für diese Felder ist dann das spezifische Gefahrenpotential zu ermitteln, wozu sich die Fehlerbaummethode, Kreativitätstechniken und Szenarios eignen. Die Sicherheitsschwachstellen in den Risikofeldern lassen sich durch Gegenüberstellen des bereichsspezifischen Gefahrenpotentials mit den bereits vorhandenen Sicherheitsmaßnahmen analysieren; diese Schwachstellenanalyse kann zweckmäßigerweise noch durch Fragenkataloge unterstützt werden (s. hierzu z. B. Heinrich, 418, Schlette, Siemens, Thaller, 249 und 285-292). Die Frage nach den risikokritischen Anwendungen des Unternehmens fuhrt zur wichtigsten Determinante für eine effiziente Sicherheitspolitik, denn dadurch wird die risikogerechte Dimensionierung der Sicherheitsmaßnahmen bestimmt. Zur Ermittlung des Ausmaßes, wann eine Anwendung als risikokritisch gilt, gibt es zwei Wege: die Bestimmung der Schadenshöhe und die Bestimmung der Risikorelevanz, jeweils bezogen auf die Eintrittswahrscheinlichkeit von risikofeldspezifischen Gefahren. Zur Bestimmung der Schadenshöhe bei einem Systemversagen sind Schadensarten und Schadenskosten zu ermitteln. Die Schadensarten lassen sich untergliedern in Sachschäden (unmittelbarer Schaden an Hardware und Software), Unterbrechungsschäden (unmittelbarer Folgeschaden aus Sachschäden) und Good-Will-Schäden (mittelbare Schadenswirkungen aus Sach- und Unterbrechungsschäden). Bei den Schadenskosten sind direkte und indirekte Kosten zu unterscheiden. Direkte Schadenskosten sind diejenigen Kosten, die durch die Wiederherstellung der Systemverfugbarkeit entstehen (z. B. Hardwarekosten, Softwarekosten, Kosten für die Wiedererstellung von Datenbeständen); indirekte Schadenskosten sind die Folgekosten, die sich aus einem Systemausfall für das Unternehmen ergeben (z. B. Kosten für ausfallüberbrückende Maßnahmen, entgangene Gewinne, Konventionalstrafen bei verzögerter Lieferung, Imageverluste). Diese Kostenarten bestimmen unzweifelhaft die Schadenshöhe eines Systemversagens, sie haben aber auch ebenso unzweifelhaft den Nachteil, daß sie nur sehr

6. Koordinatiotisfeld

„Anwendungsbetrieb

undDV-lnfrastruktur"

107

schwierig zu quantifizieren sind; dies gilt insbesondere für die Folgekosten, die deshalb häufig nur geschätzt werden können. Dennoch lassen sich dadurch Wertevorstellungen ableiten, die als Orientierungshilfe für die Risikoklassifizierung von Anwendungen dienen können. Die Bestimmung der Risikorelevanz von Anwendungssystemen kann anhand folgender Kriterien erfolgen: • Positionierung des Anwendungssystems im Anwendungsportfolio (strategische Bedeutung der Anwendung), • Verbundwirkung mit anderen Anwendungssystemen (z. B. Schlüsselfünktionen in integrierten Anwendungen), • Kundennähe des Anwendungssystems, • Abhängigkeit von der Daten- und Programmintegrität, • tolerierbare Ausfallzeit, • kritischer Ausfallzeitpunkt, • Kosten von ausfallüberbrückenden Maßnahmen, • Anzahl der vom Systemausfall betroffenen Anwender, • Zeitdauer der Wiederherstellung der Systemverfligbarkeit, • Kosten der Wiederherstellung der Systemverfugbarkeit, • Nutzungshäufigkeit des Systems. Diese Faktoren können nach der Methode der Nutzwertanalyse zu Kennzahlen der Risikorelevanz verdichtet werden. In Verbindung mit den subjektiv geschätzten Eintrittswahrscheinlichkeiten der risikofeldspezifischen Gefährdungen kann dann ein Risikoportfolio der Anwendungen erstellt werden (Abb. 63). Nach Maßgabe der Positionierung in den Risikoklassen dieses Portfolios sind dann die gefährdungsspezifischen Sicherheitsmaßnahmen zu definieren

Risikorelevanz, A Schadenshöhe

Bereich kritischer Anwendungen

H

Risikoklasse 3

Risikoklasse 4

N

Risikoklasse 1

Risikoklasse

2

N Eintrittswahrscheinlichkeit von Gefahren Abb. 63: Risikoportfolio von Anwendungssystemen (nach Krallmann 136)

108

6. Koordinationsfeld

„Anwendungsbetrieb

undDV-Infrastruktur"

Ein verkürztes Verfahren zur Handhabung der Systemsicherheit ist die Bildung von Meldungsklassen für Systemausfälle. Diese Meldungsklassen basieren auf den Kriterien zur Risikorelevanz, die vergleichsweise einfach zu bestimmen sind: Kundennähe des Anwendungssystems, Verbundwirkung mit anderen Anwendungssystemen (Folgewirkung von Systemausfällen)

und

vorgegebene

tolerierbare

Ausfallzeiten

(Minuten,

Stunden,

Tage).

Je

nach

Ausprägung dieser Kriterien ergeben sich unterschiedliche Meldungsklassen, die Ausdruck für die Dringlichkeit der Schadensbehebung sind Neben diesen Maßnahmen, die einer Eigenversicherung gegen Gefahren entsprechen, ist es für kritische Anwendungen empfehlenswert, alternativ oder zusätzlich dazu die Möglichkeiten zur Fremdversicherung zu prüfen. Das Spektrum dazu ist weit gefaßt und läßt sich wie folgt gliedern (vgl.Grobe [Versicherungen]): •

Sachversicherungen: Elektronik-Versicherung, Datenträger-Versicherung, Software-Versicherung, DV-Vermögensschadenversicherung, PC-Kaskoversicherung;

•

Folgekostenversicherungen: Elektronik-Betriebsunterbrechungsversicherung, Mehrkosten-Versicherung;

•

Personenversicherungen: Computermißbrauch-Versicherung, Datenmißbrauch-Versicherung, DatenschutzHaftpflichtversicherung, Daten-Rechtsschutzversicherung.

Zur Entscheidung darüber, welche Versicherungen in welchem Umfang gewählt werden sollen, ist das Gefährdungsprofil der einzelnen Risikofelder sowie die Risikorelevanz oder die präsumtive Schadenshöhe der jeweiligen Anwendungen heranzuziehen.

6.3

Wartungsmanagement

IuK-Anwendungen unterliegen wie jedes Produkt einem Lebenszyklus; die typischen Lebensphasen dieses Produktes sind (Heinrich, 189) die Systemeinführung, die zunehmende Systemnutzung, die stagnierende Systemnutzung und die abnehmende Systemnutzung. Die Phase Systemeinführung ist i. d. R. durch eingeschränkte Nutzung gekennzeichnet, denn auftretende Fehler und deren Beseitigung verhindern noch den vollen Betrieb. In der Phase der zunehmenden Systemnutzung kommt das volle Leistungsspektrum der Anwendung zum Tragen, denn Tests und Fehlerbeseitigung können hier als abgeschlossen gelten. Mit wachsender Nutzung der Anwendung stellt sich aber auch i. d. R. der Bedarf an Anpassung und Erweiterung der Anwendung ein, wodurch die Stabilität des Systembetriebes beeinträchtigt werden kann. Die Phase der stagnierenden Systemnutzung (Reifephase) ist die der stabilen, vollen Nutzung der Anwendung; Anpassungen oder Erweiterungen sind in nennenswertem Umfang nicht mehr erforderlich. Die Phase der abnehmenden Systemnutzung hat ihre Ursache darin, daß die Anwendung von Seiten der Hardware, von Seiten der Software und/oder von Seiten der fachlichen Funktionalität nicht mehr dem zeitgemäßen Standard entspricht, und daß - nicht zuletzt - die Wartungskosten zu Zwecken der Aufrechterhaltung des Systembetriebs erheblich ansteigen.

6. Koordinationsfeld „Anwendungsbetrieb und DV-Infrastruktur''

109

Betrachtet man vor dem Hintergrund des Lebenszyklus einer IuK-Anwendung die im Zeitablauf verursachte Gesamtkosten (Lebenszykluskosten), so ist nach verbreiteter Praxiserfahrung festzustellen, daß die Entwicklungs- und Einfuhrungskosten eines IuK-Systems nicht selten nur 40 - 50 % der Lebenszykluskosten betragen. Dies bedeutet, daß 50 - 60 % der Lebenszykluskosten auf den Systemunterhalt, d. h. auf die Wartung, entfallen. Betrachtet man den Anteil der Wartungskosten am DV-Gesamtbudget eines Unternehmens, so beanspruchen diese nicht selten bis zu 80% davon. Von diesen Wartungskosten werden wiederum bis zu 50% durch das Einarbeiten in die zu wartende Software verursacht (s Abb. 64).

% der DV-Kosten

> des Wartungsaufwandes Dokumentation

Entwicklung

10

Änderung

10

Änderungsplanung

25

Test

50

Einarbeitung/ Verständnis

Wartung

Abb. 64: Verteilung der DV-Kosten und des Wartungsaufwandes (Eicker u.a., S.70)

Zu Zwecken einer differenzierten Analyse dieses Sachverhaltes ist es üblich, die Wartungskosten zu untergliedern in Kosten für Anpassungswartung, für korrigierende Wartung und für Verbesserungswartung. Als Anpassungswartung werden Wartungsarbeiten bezeichnet, die an den Anwendungssystemen wegen Änderungen der Hardware und der systemnahen Software (z. B. Betriebssystem, Netzsoftware, Benutzerschnittstellen), aber auch wegen Änderungen von z. B. gesetzlichen Vorschriften erforderlich werden. Korrigierende Wartung erstreckt sich auf das Beseitigen von Fehlern in der Anwendungssoftware, die nach der Übergabe des Systems an den Anwender aufgetreten sind. Als verbessernde Wartung werden die Arbeiten bezeichnet, die zur Ergänzung oder Erweiterung des Anwendungssystems fuhren („Änderungsdienst"), ohne jedoch dessen Grundstruktur oder prinzipielle Funktionalität wesentlich zu ändern. Im Vergleich zur Anpassungswartung und zur korrigierenden Wartung, deren Ursachen meist sachlich zwingend sind, bedarf die verbessernde Wartung in besonderem Maße der Planung und Überwachung, denn auf diese Wartungsart entfällt nach Praxiserfahrung nicht selten der

110

6. Koordinationsfeld „Anwendungsbetrieb

undDV-Infrastruktur"

größte Anteil der gesamten Wartungskosten eines Unternehmens. Die Hauptursachen dafür sind häufig unzureichend spezifizierte Projektanforderungen, insbesondere mangelhafte fachliche Vorgaben, und ein fehlendes, stringentes Management des Änderungsdienstes. Auch Änderungen an Programmsystemen sind ähnlich wie Projekte der Anwendungsentwicklung oder wie Wartungsarbeiten in der industriellen Fertigung zu planen, zu steuern und zu kontrollieren, um zu vermeiden, daß durch spontane Änderungsanforderungen, durch unkoordinierte Änderungen oder durch beständige Änderungsaktivitäten die Kapazitäten vorwiegend zur Nachbesserung gebunden werden, anstatt zur Neuentwicklung oder zur Ablösung von Systemen zur Verfugung zu stehen. Ein effizientes Wartungsmanagement hat sich deshalb auf folgende Bereiche zu konzentrieren (Dobschütz u. a.,89): •

Erhöhung der Wartbarkeit der Systeme

(z. B. durch Reduktion der Größe von Systemen, durch konsequente Modularisierung, durch Wiederverwendbarkeit von Programmteilen, durch Dokumentation, die auf dem aktuellen Stand ist .) • Erhöhung der Hürde für Wartungsaufträge (z. B. durch Einfuhrung eines Genehmigungsprocederes mit Planung und Steuerung von Wartungsaufträgen ) • Erhöhung der Produktivität der Wartung (z. B. durch Trennung der Entwicklung von der Wartung, durch das Ermöglichen unterbrechungsfreier Arbeit, durch die Zurverfügungstellung von leistungsfähigen CASE-Systemen, durch die Einfuhrung der Produktverantwortung für Softwaresysteme.) Zur konkreten Handhabung der Änderungsanforderungen aus den Fachabteilungen empfiehlt sich eine Vorgehensweise, die in Abb. 65 dargestellt ist. Darüber hinaus sollten die durchgeführten Änderungen nach fachlichen Kriterien dokumentiert und analysiert werden, um dadurch Hinweise für das Anforderungsprofil von Weiter- oder Neuentwicklungen, aber auch für anstehende Systemablösungen zu erhalten. Ein weiteres Problemfeld für das Wartungsmanagement ist die Sanierung von Anwendungssystemen. Im Gegensatz zu Wartungsmaßnahmen, die an Anwendungssystemen i. d. R. aus konkreten Anlässen und vergleichsweise partiell durchgeführt werden, soll durch Sanierung die Struktur des gesamten Anwendungssystems verbessert werden, ohne jedoch dadurch auch gleichzeitig dessen fachliche Funktionalität grundsätzlich zu ändern. Das Instrumentarium dazu liefert das Software-Reengineering, das sich mit der Analyse und dem Ändern der Konstruktion und der Strukturkomponenten von Softwaresystemen befaßt. Software-Reengineeringmaßnahmen lassen sich zweckmäßigerweise danach unterscheiden, an welcher Schicht eines Softwaresystems diese ansetzen: • •

an der Programm-Präsentation, an der Programm-Logik,

• •

an der Datenhaltung, am Programmcode.

6. Koordinationsfeld

• • • • • • • • • •

„Artwendungsbetrieb und DV-Infrastruktur"

111

Begründung der Notwendigkeit für die Programmänderung, Begründung des Nutzens, der durch die Programmänderung erzielt werden soll, Analyse der Auswirkungen der Änderungsanforderung auf bestehende Systeme (Programmsysteme, Datenhaltung, Benutzeroberflächen), Zeitschätzung für die Durchführung der Programmänderung, wertanalytische Überprüfung der Änderungsanforderung, Abstimmung der Änderungsanforderungen von verschiedenen Auftraggebern untereinander und Bildung von "Änderungspaketen", paketweise Durchführung der Programmänderungen zu Zwecken von terminlich koordinierten Versionsfreigaben, Kontrolle der durchgeführten Programmänderungen gegen die Änderungsvorgaben, Dokumentation von Programmversionen mit dem jeweiligen Stand von Ändrungen, kostenstellen- und kostenträgerbezogene Verrechnung der Änderungskosten.

Abb. 65: Vorgehensweise zur Handhabung von Änderungsanforderungen

Sanierungsmaßnahmen auf der Schicht der Programm-Präsentatation erstrecken sich auf die Um- oder Neugestaltung von Dialogstrukturen, der Benutzerfiihrung, von Bildschirmmasken, von Listendarstellungen und von Hilfefiinktionen; auf der Schicht der Programm-Logik haben sie zum Gegenstand die Unterteilung von monolithisch gestalteten Programmen in Module, die systematische Strukturierung der Module, die Definition und Vereiheitlichung von ModulSchnittstellen, die Zusammenfassung von variierenden Daten, von Konstanten und von Texten in Tabellen und die Parametrisierung des Kontrollflusses. Sanierungsmaßnahmen auf der Schicht der Datenhaltung erstrecken sich auf die Umgestaltung von Dateisystemen in Datenbanksysteme, aber auch auf die Überfuhrung von hierarchisch-strukturierten Datenbanken in relationale Datenbanken. Auf der Schicht des Programmcodes gelten die Sanierungsmaßnahmen der Nachdokumentation der Ablaufstruktur von Programmen, der Überarbeitung von Verzweigungsstrukturen, der Code-Bereinigung, der Code-Kommentierung und der CodeUmsetzung in andere Sprachkonstrukte. Vorrangiges Sanierungsziel ist die Verbesserung der Wartbarkeit bestehender Anwendungssysteme, um dadurch die Wartungskosten senken zu können; daneben können aber auch Integrationsziele (z. B. Zusammenfuhren von inselhaften Anwendungssystemen), Qualitätsziele (z B. verbesserte Benutzerfiihrung, Wiederverwendung von Programmteilen) und Migrationsziele (z. B. Überfuhren von Anwendungssystemen auf andere Systemplattformen) die Auslöser von Sanierungsmaßnahmen sein.

112

6. Koordinationsfeld

„Anwendungsbetrieb

und

DV-Infrastruktur"

Folgende Entscheidungsalternativen bieten sich im Zusammenhang mit Sanierungsüberlegungen: • terminierte Systemstillegung unter weitgehendem Verzicht auf Wartung bis dahin, • Teilsanierung des Altsystems, • Vollsanierung des Altsystems, • Systemablösung durch Eigenentwicklung oder durch Fremdbezug von Software. Zur Entscheidung darüber, welcher Alternative der Vorzug gegeben werden soll, sind grundsätzlich folgende Kostenarten zu vergleichen: • Wartungskosten des Altsystems, • Sanierungskosten des Altsystems, • Kosten des Nachfolgesystems. Von besonderer Bedeutung hierzu und insbesondere für die Entscheidung Systemsanierung oder Systemablösung sind die Lebenszykluskosten eines Anwendungssystems (s. Kap. 5.7). Diese Betrachtungsweise, in der Entwicklungskosten, Einfuhrungskosten und Folgekosten eines Softwaresystems zusammengeführt werden, ermöglicht eine sachliche fundierte Entscheidung über Sanierung oder Ablösung eines Anwendungssystems nach dem Investitionskalkül, z. B. durch Vergleich der periodisierten Kosten des Altsystems mit den periodisierten Kosten des Nachfolgesystems. Zusätzlich zu den Kostenkriterien können zur Entscheidungsfindung über die obigen Alternativen noch folgende Kriterien herangezogen werden, die sich teilweise aus den Qualitätsmerkmalen von Software herleiten. • Funktionalität, • Integrationsgrad, • Anwenderzufriedenheit, • Zuverlässigkeit, • Effizienz, • Wartbarkeit, • Entwurfsqualität, • Nutzungshäufigkeit, • Lebensalter der Anwendung. Zur Visualisierung der Entscheidungsgrundlagen bieten sich Polardiagramme (Abb. 66) an. Für das DV-Controlling sollte es eine vorrangige Aufgabe sein, die Lebenszykluskosten für jedes IuK-System zu gesondert zu erfassen und zu analysieren, sowie die weiteren System-Ablösungskriterien anwendungsspezifisch zu bewerten. Dadurch wird die Grundlage für ein lebenszyklusorientiertes Produktcontrolling geschaffen, das nicht nur zur Effizienzsteigerung der Produktentwicklung dient, sondern auch entscheidungsrelevante Informationen dazu liefert, wann eine Produktablösung angebracht ist, welche Konsequenzen sich daraus ergeben und mit

6. Koordinationsfeld

„Anwendungsbetrieb

und DV-lnfrastruktur"

113

welchem Vorlauf Nachfolgeprodukte auf welcher IuK-Infrastruktur zu entwickeln oder zu beschaffen sind. 2. Integrationsgrad

Abb. 66:Polardiagramm zur Unterstützung der Entwicklung Systemsanierung/Systemablösung

6.4

Produktionsmanagement

Dem Produktionsmanagement obliegen bei einer zentralen Infrastruktur i. d. R. folgende Aufgaben (vgl. Heinrich, 245): • Übernahme neuer Anwendungssysteme in den Produktionsbetrieb, • Planung und Durchführung von Stapelverarbeitungsaufträgen, • Vorhalten der Systemverfügbarkeit für Dialoganwendungen, • Nachbearbeitung von Produktionsergebnissen (z. B. Druckoutput), • Sicherung und Archivierung von Programmen und Datenbeständen, • Reparatur und Pflege der Betriebsmittel. Bei einer dezentralen Infrastruktur, insbesondere bei einer Client-Server-Struktur, erstreckt sich das Produktionsmanagement auf die • Bereitstellung, Verwaltung und Wartung dezentraler Hardware-Komponenten, • Bereitstellung und Verwaltung von Serverleistungen, • Bereitstellung von Datennetzen, • Bereitstellung und Verwaltung von Kommunikationsdiensten, • Verwaltung der Benutzerberechtigungen,

114

6. Koordinationsfeld

„Amvendungsbetrieb

und DV-lnfrastruktur "

• Benutzerbetreuung, • zentrale Sicherung und Archivierung von Programmen und Datenbeständen. Das Interesse des Controllings hierzu gilt der bedarfsgerechten Dimensionierung der Kapazität der Betriebsmittel und der Optimierung der Betriebsmittelnutzung, z. B. durch Umschichtung oder Umstrukturierung von Hardware-Komponenten. Um die dazu benötigten Daten zu erhalten, ist es erforderlich, daß im Produktionsbetrieb permanent Hardware- und Software-Monitoringaufzeichnungen durchgeführt werden. Diese Aufzeichnungen, die von den System- und Netzbetriebssystemen durchgeführt werden, liefern Daten über die Lastprofile und die Leistung der einzelnen Komponenten der IuK-Infrastruktur. Daraus lassen sich die Kapazitätsausnutzung sowie ggf. Engpaßkapazitäten erkennen, woraus sich Ansatzpunkte für eine Optimierung der Komponentennutzung ergeben. Ein weiteres Gebiet für Controllingaktivitäten im Zusammenhang mit dem Produktionsmanagement ist die Verwaltung der im Unternehmen vorhandenen Hardware- und Softwarekomponenten (Ressourcenverwaltung); diese erstreckt sich auf • PCs, Workstations, Server, • die technische Ausstattung dieser Geräte, • die Software, die auf diesen Geräten installiert ist, • die Netz-Konfigurationen, • die DFÜ-Leitungen, • die Anwendungssysteme, • die Verträge, • die Anlagenbuchhaltung. Von vorrangigem Interesse für das Controlling hierzu ist die Vertragveraltung (Kaufverträge, Miet-/Leasingverträge, Lizenzverträge, Wartungsverträge, Versicherungsverträge), denn die Bindungsfristen von Verträgen, die Möglichkeit von Vertragsumschichtungen, die Modalitäten von Zahlungsverpflichtungen und Zahlungsleistungen sowie deren Abstimmung mit dem Finanzmanagement des Unternehmens sind unmittelbar erfolgsreievante Faktoren.

6.5

Benutzerservice

Die Dezentralisierung der DV-Infrastruktur vom traditionellen Rechenzentrumsbetrieb zu einem unternehmensweiten vernetzten PC- und Workstationverbund ermöglicht den Anwendern nicht nur den selbständigen Zugang zu einem neuen Nutzungspotential von IuK-Systemen - z. B. in Form von individueller Datenverarbeitung (IDV), Work Group Computing und Vorgangssteuerungssystemen -, sondern erfordert von diesen in einem nicht geringen Ausmaß Grundkenntnisse der Datenverarbeitung sowie die Übernahme von dv-spezifischen Aufgaben, die z. T. bisher von den Rechenzentren wahrgenommen wurden (z. B. Datensicherung und Pflege von Datenbeständen). Die Verselbständigung in der Nutzung von IuK-Systemen bringt auf der einen Seite den Anwendern ohne Zweifel ein hohes Maß an effizienzsteigernder Flexi-

6. Koordinationsfeld „Anwendungsbetrieb und DV-lnfrastruktur "

115

bilität bei der Erfüllung ihrer fachlichen Aufgaben; auf der anderen Seite birgt sie nicht geringe Gefahren, insbesondere für die Gesamtheit der Untemehmensorganisation: durch individuelle Beschaffung von Hardware und Software können irreparable Inkompatibilitäten auftreten, gleichartige IDV-Lösungen werden an verschiedenen Stellen wiederholt entwickelt, IDV-Lösungen werden als Insellösungen entwickelt, inkonsistente Datenhaltung wegen fehlender Abstimmungen, mangelhafte Datensicherheit und nicht zuletzt Überforderung desAnwenders im Umgang mit dem Instrumentarium. Diese Sachverhalte erfordern Koordination und Unterstützung; es ist deshalb zweckmäßig, dafür einen eigenständigen Bereich zu schaffen, der sich als „Kompetenzzentrum Benutzerservice" versteht; die Aufgaben dieses Bereiches umfassen z B : •

Beraten der Benutzer über zweckmäßige Anwendungsalternativen (zentrale/dezentrale Lösung, dazu geeignete Hardware- und Softwarekomponenten),

•

Entwickeln von Prototypen zur Demonstration von Lösungsmöglichkeiten,

•

Entwickeln von IDV-Anwendungen für die Benutzer,

•

Organisation des Filetransfers zwischen Datenbanken und IDV-Anwendungen,

•

Koordinierung der dezentralen Datenhaltung,

•

Datensicherung von sensiblen Datenbeständen,

•

Unterstützung der Benutzer bei Problemen („Hotline- und Helpdesk-Dienste"),

•

W a r t u n g der IDV-Anwendungen und der IDV-Infrastruktur,

•

Schulung der Benutzer,

•

Durchführung von Erfahrungsaustausch unter Benutzergruppen,

•

Auswahl und Beschaffung von Hardware und Software,

•

Betreiben eines Vorführzentrums für Hardware und Software („Walk-in-Center"),

•

Vorhalten von Leihgeräten,

•

Information der Benutzer über aktuelle Entwicklungen von Hardware und Software.

Der Erfolg der Tätigkeit eines Benutzerservice ist von einer Anzahl von Faktoren abhängig wie z. B. Ausstattung mit aktueller Hardware und Software, Akzeptanz der Unterstützungsdienste bei den Anwendern etc.; die wichtigsten Erfolgsfaktoren sind jedoch die schnelle Verfügbarkeit der Serviceleistungen im Bedarfsfall - insbesondere bei Störungen -, sowie qualifiziertes Personal, das nicht nur Detailkenntisse zeitgemäßer Datenverarbeitung, sondern auch ein fundiertes Sachverständnis von den Fachaufgaben der Anwender hat Die Arbeit des Benutzerservice selbst kann durch Problemanagementsysteme unterstützt werden, deren Hauptbestandteile für die diesen Zweck eine Konfigurationsdatenbank, eine

Wissensdatenbank

(Datenbank der bisher gelösten Problemfälle)und eine online-retrievalfähige Handbuchbibliothek ist. Das Controllinginteresse am Benutzerservice gilt vorrangig dessen Effizienz; deshalb ist zu prüfen, ob das Aufgabengebiet dazu bedarfsgerecht ausgestaltet ist. Weiter ist zu prüfen, ob

116

6. Koordinationsfeld„Amvendungsbetrieb

undDV-Infrastruktur"

die Koordinationsfiinktion des Benutzerservice wirksam wahrgenommen werden kann; dazu ist nach Richtlinien zu fragen, durch die folgendes geregelt werden soll: • welche Hardware zu verwenden ist, • welche Software zu verwenden ist, • nach welchen Modalitäten Fremdsoftware zu installieren ist, um ein Maximum an Virenprotektion zu erzielen (z. B. Installation zuerst in „Software-Quarantänestation"), • wie die Benutzeroberfläche zu gestalten ist (z. B. Bildschirmoberflächen nach GUI-Standards, Verwendung nur von diskless Stations), • wie die Vernetzung zu gestalten ist, • welche Schnittstellenerfordernisse im Systemverbund zu erfüllen sind (z. B. MicroMainframe-Connection), • welche Daten in welcher Form an welchen Stelle im Netz des Datenverbundes zu halten sind, • wie die Dokumentation von IDV-Anwendungen zu gestalten ist, • welche Sicherheitsmaßnahmen durchzuführen sind, • nach welchen Modalitäten die Beschaffung von Hardware und Software zu begründen und durchzufuhren ist.

7. Koordinationsfeld „ Verrechnung von Kosten und Leistungen "

7. 7.1

117

Koordinationsfeld "Verrechnung von Kosten und Leistungen" Controlliiigziele

Für das Koordinationsfeld „Verrechnung von Kosten und Leistungen", zu dem notwendigerweise die Budgetierung der IuK-Kosten gehört, lassen sich folgende Controllingziele formulieren: • Schaffen eines unternehmensweiten Kostenbewußtseins fur die Inanspruchnahme der Ressource Information, • Transparenz über Kosten und Leistungen des IuK-Bereiches, • Kostenreduzierung durch Begrenzung oder Abbau von IuK-Leistungen, • Leistungssteigerung durch effizienzfördernde Maßnahmen, • Fördern und Erhalten des Wettbewerbsdenkens der Anwender bei der Inanspruchnahme von Leistungen des IuK-Bereiches.

7.2

Budgetierung

Die Budgetierung von Kosten ist eine zeitbezogene Vorschaurechnung, die auf den Leistungen beruht, die im Planungszeitraum erbracht werden sollen. IuK-Leistungen werden primär von den Anwendern in den Fachabteilungen angefordert bzw. geplant; sie finden deshalb zunächst ihren Niederschlag in den IuK-Budgets der Fachabteilungen (dezentrale Kostenbudgets). Die Zusammenfassung der IuK-Budgets der Fachabteilungen ergibt dann das Budget des IuK-Bereiches (zentrales oder Gesamtkostenbudget), das zusätzlich noch die Kosten für diejenigen Leistungen enthält, die für diesen Bereich selbst bestimmt sind. Die Verbindung von Gesamtkostenbudget und dezentralen Kostenbudgets erfolgt durch die Verrechnung von IuKLeistungen und ggf. durch die Verteilung von IuK-Kosten (Abb. 67).

Budget des luK-Bereichs 1 Fachabteilung A Budget für IuK-Leistungen

Zusammenfassung der luK-Leistungsbudgets der Fachabteilungen

Bereichseigene Kosten und Leistungen

Entlastung

Abb. 67: Zusammenfassung von Budget und Verrechnung von Kosten und Leistungen

118

7. Koordinationsfeld

„ Verrechnung von Kosten und Leistungen "

Die Kosten in IuK-Budgets können nach Kostenarten und nach Leistungsbereichen untergliedert werden. Eine Untergliederung nach Kostenarten weist i. d. R. folgende Struktur auf: • Personalkosten: - eigenes Personal, - externes Personal; • Hardwarekosten: - Mainframe-Systeme, - Midrange-Systeme, - Server, - Workstations, - Pcs, - Drucker, - sonstige Peripherie; • Netzkosten, • Kommunikationskosten: - Kommunikationseinrichtungen, - DFÜ-Gebühren, • • •

- Anbieterentgelte; Software-Lizenzen, Verbrauchsmaterial, Infrastrukturkosten: - Arbeitsplatzausstattung, - Gebäude, - technische Einrichtungen, - Energie, - Versicherungen.

Eine Budgetgliederung nach Leistungsbereichen enthält üblicherweise folgende Positionen: • Kosten für den laufenden Betrieb von IuK-Systemen, • Kosten für die Bereitstellung von Netz- und Kommunikationsdiensten, • Kosten für Anwendungsentwicklung, • Kosten für Anwendungswartung, • Kosten für Benutzerberatung, • Kosten für Benutzerbetreuung, • Kosten für Benutzerschulung. Die Gliederung von IuK-Budgets nach Kostenarten eignet sich zu periodenbezogenen SollIst-Vergleichen und zu zwischenbetrieblichen Vergleichen. Für ein strategieorientiertes Controlling ist eine Gliederung nach Kostenarten weniger geeignet; dazu eignet sich eine Gliederung nach Leistungsbereichen besser, denn daraus lassen sich Ansatzpunkte für effizienzund eflektivitätsverbessernde Entscheidungen gewinnen. Die Kostenblöcke Betriebskosten und Wartungskosten geben i. d. R. die ersten Hinweise für die Notwendigkeit von effizienzverbessernden Maßnahmen (s. hierzu Kapitel 5). Die Kostenblöcke Kosten für Anwendungs-

7. Koordinationsfeld „ Verrechnung von Kosten und Leistungen "

119

entwicklang und Kosten für Softwarelizenzen, die im Vergleich zu den vorgenannten Kostenblöcken nicht selten erheblich geringer dimensioniert sind, sind signifikante Indikatoren für die Erfordernis von strategischen Entscheidungen zur Verbesserung der Effektivität der IuK-Nutzung durch die Disposition entsprechender Finanzmittel; Instrumente zur Vorbereitung dieser Entscheidungen sind im engeren Sinne die Zero-Base-Budgeting-Analyse und im weiteren Sinne die strategische IuK-Planung (s. hierzu Kapitel 3).

7.3 7.3.1

Kosten- und Leistungsverrechnung Ziele

Eine Verrechnung von Kosten und Leistungen des IuK-Bereiches an die Leistungsempfänger im Unternehmen ist dann erforderlich, wenn folgende Ziele erreicht werden sollen: • Rechtfertigung von IuK-Projekten durch den Nachweis quantitativer Wirtschaftlichkeit, • Entscheidung über „Eigenfertigung oder Fremdbezug" von IuK-Leistungen, • Erziehung der Anwender zum wirtschaftlichen Umgang mit der Ressource Information, • gezielte Steuerung der Inanspruchnahme von IuK-Ressourcen, • Kostenreduzierung und /oder Leistungssteigerung, • Wirtschaftlichkeitskontrolle des IuK-Bereiches, • Unterstützung von Entscheidungen über „Outsourcing"

7.3.2

Anforderungen

Ergänzend zu den genannten Zielen soll eine Verrechnung von Kosten und Leistungen des IuK-Bereiches folgenden Anforderungen entsprechen: • die Verrechnungsmethode soll gerecht in dem Sinne sein, daß die Empfänger von IuK-Leistungen proportional zur Inanspruchnahme der Leistungen belastet werden (verursachungsgerechte Kostenzuordnung); • die Verrechnungsmethode soll fair in dem Sinne sein, daß alle Leistungsempfänger gleich behandelt werden; Subventionierungen einzelner Leistungsempfänger sind zu vermeiden; • die Verrechnungsmetode soll differenzieren zwischen solchen Kosten, die vom Leistungsempfänger zu verantworten sind (beeinflußbare Kosten), und solchen Kosten, die vom Leistungsempfänger nicht zu verantworten sind (nicht beeinflußbare Kosten); • die Verrechnungsmethode soll die Verrechnung sämtlicher Kosten und Leistungen des IuKBereiches ermöglichen; • für den Empfänger von IuK-Leistungen soll die Verrechnungsmethode transparent und nachvollziehbar sein; • die Verrechnungsmethode muß sich in den Gesamtrahmen des betrieblichen Rechnungswesens einfügen lassen.

7.3.3

Grundsatzfragen

Vor der Entscheidung darüber, nach welcher Methode die Verrechnung von Kosten und Leistungen durchgeführt werden soll, sind einige Grundsatzfragen zu klären. Die erste Grundsatz-

120

7. Koordinationsfeld „ Verrechnung von Kosten und Leistungen"

frage betrifft den organisatorischen Status, den der IuK-Bereich im Unternehmen hat. Dies kann sein: • Vor- oder Hilfskostenstelle oder • Profitcenter. Wenn der organisatorische Status des IuK-Bereiches dem einer Vor- oder Hilfskostenstelle entspricht, dann erübrigt sich i. d. R.eine Verrechnung von Kosten und Leistungen, denn Kostenstellen dieser Art haben nur Sammelfunktion im Rahmen des betrieblichen Rechnungswesens; die Kosten solcher Kostenstellen werden durch Umlagen den Hauptkostenstellen zugerechnet. Wird der IuK-Bereich als Profitcenter angesehen, das über ein Budget und über Investitionskompetenz verfugt und das selbständige Erfolgsverantwortung hat, dann ist eine Leistungsverrechnung erforderlich. Wenn der Status des IuK-Bereiche eine Leistungsverrechnung bedingt, dann stellt sich als nächste Grundsatzfrage, ob die Fachabteilungen gezwungen sind, ihre IuK-Leistungen ausschließlich vom unternehmenseigenen IuK-Bereich zu beziehen, oder ob sie die Freizügigkeit haben, alternative Angebote des Marktes für IuK-Dienstleistungen wahrnehmen zu können. Im ersten Fall wird dem IuK-Bereich eine Monopolstellung eingeräumt, die zwangsläufig die wettbewerbsfördernde Wirkung einer Leistungsverrechnung stark einschränkt, denn den Leistungsempfangern fehlen Marktalternativen. Im zweiten Fall besteht Freiheit im Leistungsbezug - soweit dies technisch und/oder organisatorisch möglich und sinnvoll ist - mit der Konsequenz der Förderung des wettbewerbsorientierten Verhaltens des IuK-Bereiches gegenüber den auftraggebenden Fachabteilungen. Die dritte Grundsatzfrage betrifft die Wahl des Kostenrechnungssystems. Sofern diese nicht durch das vorgegebene System des betrieblichen Rechnungswesens beantwortet ist, konzentriert sich die Frage auf die Verrechnung von Vollkosten oder die Verrechnung von Teilkosten. Aus betriebswirtschaftlicher Sicht ist der Verrechnung von Teilkosten grundsätzlich der Vorzug zu geben, insbesondere dann, wenn es sich bei den verrechnungsfähigen Kosten um entscheidungsrelevante Kosten aus der Sicht des Leistungsempfängers handelt. Die vom Leistungsempfänger nicht beeinflußbaren Kosten sind dann als Vorhaltekosten oder Kosten der Betriebsbereitschaft entweder global in das Betriebsergebnis zu übernehmen oder durch Kostenumlage zu verteilen (Abb. 68). Die betriebliche Praxis steht der Verrechnung von Teilkosten aber häufig entgegen, denn die Kosten des IuK-Bereiches sind bis auf wenige Kostenarten weitestgehend fixe Kosten und daher vom Leistungsempfänger kaum beeinflußbar. Deshalb bietet sich trotz der bekannten Mängel die Verrechnung von Vollkosten an; dazu ist aber zu berücksichtigen, daß IuK-Leistungen wie auch andere betriebliche Leistungen i. d. R. nicht zu gleichen Kosten reproduzierbar sind. Dies bedeutet, daß eine Leistungsverrechnung auf Grundlage von Kosten unzureichend ist, statt dessen ist ist eine Leistungsverrechnung auf Grundlage von vollkostenorientierten Plan-Verrechnungspreisen erforderlich.

7. Koordinationsfeld,,

Verrechnung von Kosten und Leistungen "

121

Abb. 68: Struktur der Verrechnung von Kosten und Leistungen

7.3.4 7.3.4.1

Verrechnungsmethoden Kostenumlage

Die Umlage der Kosten des IuK-Bereiches an die Empfänger von IuK-Leistungen ist die einfachste, aber auch die undifFerenzierteste Methode, die nur dann gerechtfertigt ist, wenn dem IuK-Bereich im Unternehmen der Status einer Vor- oder Hilfskostenstelle zukommt: Hierzu werden die gesamten in der Abrechnungsperiode angefallenen Kosten im Verhältnis der Inanspruchnahme auf die Nutzer verteilt. Diese Methode ist lediglich eine Kostenverteilung, bei der das Problem im wesentlichen darin besteht, einen geeigneten Verteilungsschlüssel für eine verursachungsgerechte Kostenumlage zu finden. Folgende Schlüsselgrößen bieten sich dazu an: • beanspruchte CPU-Zeit, • Anzahl der Transaktionen, • Anzahl der Druckzeilen. Wird nur eine Schlüsselgröße für die Kostenumlage verwendet, so setzt dies indirekt ein homogenes Lastprofil für die IuK-Infrastruktur voraus - ein Sachverhalt, der in der Praxis nur sehr selten anzutreffen ist. Werden die Schlüsselgrößen kombiniert verwendet, so verbessert sich dadurch die Proportionalität der verteilten Kosten zur erfolgten Nutzung; inhomogene Lastprofile werden dadurch besser berücksichtigt. Die Kostenumlage hat zwar den Vorteil der Einfachheit, aber diesem Vorteil steht entgegen, daß die Ziele, die mit einer Verrechnung von Kosten und Leistungen erreicht werden sollen, durchweg nicht erreicht werden können. Die Hauptursache dafür ist, daß durch Kostenumlagen keine Einflußnahme auf das Benutzerverhalten hinsichtlich der Inanspruchnahme von IuK-Leistungen bewirkt wird, denn Kostenumlagen werden von Leistungsempfängern i. d. R. nicht als restringierend empfunden. Deshalb ist bei Anwendung von Kostenumlagen nicht selten die Grundhaltung anzutreffen, IuK-Leistungen seien für die Benutzer frei und in beliebiger Menge zu erhalten. Diese Grundhaltung wird besonders dann verstärkt, wenn die Kosten des

122

7. Koordinationsfeld „ Verrechnung von Kosten und Leistungen "

IuK-Bereiches en bloc als Vorhaltekosten den Verwaltungsgemeinkosten des Unternehmens zugeschlagen werden; die Konsequenz dessen ist dann häufig das Entstehen des bekannten „Anwendungsstaus". 7.3.4.2 Leistungsverrechnung 7.3.4.2.1 Bezugsgrößen und Verrechnungspreise Für eine Leistungsverrechnung ist Voraussetzung, daß ein Budgetsystem existiert (zentrales Gesamtbudget und dezentrale Breichsbudgets), daß Leistungen und zugehörige Meß-bzw. BezugsgröOen definiert sind und daß Preise für die Leistungseinheiten vorliegen. Die Struktur eines Budgetsystems ist in Kap. 7.2 dargestellt. Die Leistungen, die vom IuK-Bereich für die Nutzer erbracht werden, lassen sich in zunächst grober Annäherung wie folgt gliedern: • Systembetrieb, • Systementwicklung, • Systemwartung, • Benutzerberatung und -betreuung. Für die Verrechnung der Leistungsart Systembetrieb eignen sich technische und anwenderbezogene Bezugsgrößen; technische BezugsgröOen sind z. B : • CPU-Zeit [sec], • Hauptspeicherbelegung [MBsec], • permanent genutzte Kapazität externer Speicher, • Anzahl der Zugriffe auf externe Speicher [Platten-IO], • Anzahl der Jobs, • Anzahl der Transaktionen, • Anzahl der Druckzeilen/-seiten, • Terminal- bzw. Logon-Zeiten, • Netzbeanspruchung [Zeit, übertragene Datenmenge]. Als anwenderbezogene Bezugsgößen bieten sich z. B.an: • Auftragsbestätigung, • Rechnungszeile, • Rechnung, • Buchungszeile, • Mahnung, • Serienbrief, • Datenbankabfrage, • gespeicherte Stammsätze, • Anlegen/Ändern von Stammsätzen.

7. Koordinationsfeld

„ Verrechnung von Kosten und Leistungen "

123

Systementwicklung, Systemwartung sowie Benutzerberatung und -betreuung bestehen im wesentlichen aus Personalleistung, deren BezugsgröBe für die Verrechnung der Zeitaufwand (Personalstunde, Personaltag) ist. Im Gegensatz zur Kostenumlage, durch die die angefallenen luK-Gesamtkosten lediglich möglichst verursachungsgerecht verteilt werden sollen, dient die Leistungsverrechnung zur zielorientierten Ressourcenallokation. Das Instrument dazu sind Verrechnungspreise, die als Kostenpreise (z. B. auf Grundlage von Standard- oder Plankosten), Marktpreise, vereinbarte Preise oder als nutzenorientierte Preise für die Leistungseinheiten in Ansatz gebracht werden können. Die Allokationsfünktion von Preisen wird noch dadurch verstärkt, wenn diese flexibel gestaltet werden; für den IuK-Bereich bieten sich dazu folgende Möglichkeiten: • Preisdifferenzierung nach dem zeitlichen Anfall der Leistungen (Tages- und Nachtpreise für zentrale IuK-Ressourcen), • Preisdifferenzierung nach der Prioriät von Anwendungen, • Preisdifferenzierung nach der Art der Leistung (z. B. unterschiedliche Preise für Stapel-Anwendungen und Dialog-Anwendungen), • Preisdifferenzierung nach der Art der benutzten Komponenten (z. B. unterschiedliche Preise für zentralen und dezentralen Druckoutput), • Preisdifferenzierung nach Benutzern oder Leistungsmengen (Rabatte). 7.3.4.2.2 Verrechnung bei zentraler IuK-Infrastruktur Die Verrechnung bei zentraler IuK-Infrastruktur kann je nach der Anzahl der dazu herangezogenen Bezugsgrößen summarisch oder differenziert erfolgen. Bei der summarischen Leistungsverrechnung werden nur ein oder zwei Bezugsgrößenverwendet, auf die das gesamte Leistungsspektrumdes IuK-Bereiches verdichtet wird; es sind dies die Personalstunde und die Maschinenstunde. Nach Personalstunden werden üblicherweise Entwicklungsleistungen, Softwarewartung, Beratungs- und Betreuungsleistungsleistungen verrechnet; Voraussetzung dazu ist eine projektoder tätigkeitsbezogene Zeitaufschreibung, die folgende Positionen beinhalten sollte: • Projektbezeichnung, • Tätigkeitsart, • leistende Kostenstelle, • empfangende Kostenstelle, • Tätigkeitsbeginn, • Tätigkeitsende, • Unterbrechungsdauer, • Unterbrechungsursache.

124

7. Koordinationsfeld,, Verrechnung von Kosten und Leistungen"

Die angefallen Personalstunden werden mit einem durchschnittlichen Personalstundensatz bewertet, der sich aus Gehältern, Gehaltsnebenkosten, Arbeitsplatzkosten und Weiterbildungskosten errechnet. Die Leistungsverrechnung über die Maschinenstunde erfordert eine Laufzeitprotokollierung der einzelnen Allwendungsysteme; alleinige Meßgröße ist in diesem Fall häufig die CPUStunde. Diese Maschinenstunde wird mit dem Maschinenstundensatz bewertet, der sich zusammensetzt aus den Kosten für • Miete/Leasing von Hardware oder • Abschreibungen auf Hardware bei Kauf, • Lizenzen für Software, • Wartung/Reparatur, • Operating, • Energie, • Verbrauchsmaterial. Weitere Kosten des Anwendungsbetriebes (z. B. anteilige Verwaltungskosten, kalkulatorische Abschreibungen und Zinsen, Versicherungskosten) werden durch einen Zuschlagssatz zum Maschinenstundensatz berücksichtigt. Vor dem Hintergrund der Komponentenvielfalt einer zeitgemäßen IuK-Infrastruktur und unter Berücksichtigung des Sachverhaltes, daß die vielfältigen IuK-Systeme diese Komponenten sehr unterschiedlich beanspruchen, ist eine summarische Leistungsverrechnung heute wenig dazu geeignet, die Ziele zu erfüllen, die durch eine Verrechnung von Kosten und Leistungen erreicht werden sollen. Die differenzierte Leistungsverrechnung erfüllt diese Ziele besser, denn zur Leistungserfassung und -Verrechnung wird ein breites Spektrum an Bezugsgrößen verwendet, das der Lei-

stungsvielfalt des IuK-Bereiches gerecht wird. So wird bei der Bezugsgröße Personalstunde wird z. B. differenziert nach der jeweiligen Leistungsart: • Anlytikerstunde, • Programmiererstunde, • Beraterstunde, • Betreuungsstunde. Die Bezugsgröße Maschinenstunde wird aufgegliedert in Meßgrößen, durch die es möglich wird, die Inanspruchnahme der einzelnen Komponenten der technischen DV-Infrastruktur zu messen (Abb. 69). Die Daten dazu liefern Betriebsprotokollprogramme bzw. Job Accounting-Softwaresysteme, die aufgrund von Terminalidentifikation, Name der Anwendung oder Benutzerkennung die Ressourcennutzung anwenderindividuelle erfassen und zuordnen können.

7. Koordinationsfeld „ Verrechnung von Kosten und Leistungen "

• Zentrale Verarbeitungseinheiten: - CPU-Zeit (nach Stapel-VA/Dailog-VA) (nach Tag/Nacht-Nutzung) - belegte Hauptspeicherkapazität (Region Size) - Kombination aus Region Size und CPU-Zeit [MB-Stunde] - angeforderte und tatsächlich genutzte HS-Kapazität

•

Druckperipherie: - Zeilen/Seiten zentraler Output - Zeilen/Seiten dezentraler Output (mit/ohne Nachbearbeitung)

•

Terminals/WSs/PCs: - Anschlüsse - Anschaltzeit - Transaktionen (Datenfreigaben)

•

•

Netze: - Netzanschlüsse - Benutzer - Netzzugriffe - übertragene Datenmenge - E-Mail-Transaktionen

Externspeicher: - Plattenzugriffe (Disk-IO) - permanent belegter Plattenplatz - temporär belegte Plattenplatz [Plattenplatz x Belegungszeit] - Datenbank-Requests - Kassetten-ZBandzugriffe (Tape-IO) - belegter Kassetten-/Bandplatz - Kassetten-/Bandwechsel (Mounts) (manuell/Roboter-gesteuert) - Kassetten-/Bandlagerung [Einheiten/Monat]

125

Abb. 69: Meßgrößen der Komponenten der technischen Infrastruktur

Für jede einzelne Bezugsgröße ist ein Preis zu bestimmen, der sich z. B. aus den Kosten der jeweiligen Komponente der IuK-Infrastruktur ableiten läßt. Daraus entstehen dann „Preislisten" für die Komponentennutzung (Abb. 70). Der Verrechnungspreis (P), mit dem der Nutzer für die in Anspruch genommenen Leistungen belastet wird, ergibt sich aus der Aufsummierung der bewerteten Teilleistungen der technischen IuK-Infrastruktur; der formale Ansatz dazu lautet P = Exi pi, wobei die genutzten technischen Komponenten mit i = l,2,...,n, die Preise pro Bezugsgröße mit pi und die Anzahl der Nutzungseinheiten mit x, bezeichnet sind. Bei der Messung der Nutzungseinheiten ist sicherzustellen, daß gleiche Anwendungen bei unterschiedlichen Multiprogramming-Bedingungen mit gleichen Preisen verrechnet werden, denn Wartezeiten wegen systeminterner Engpässe dürfen nicht in die Nutzungszeit eingehen, denn sie sind nicht vom Anwender zu vertreten. Neben diesen primären Leistungen, deren Ressourcenverbrauch unmittelbar gemessen werden kann, fallen noch sekundäre Leistungen an in Form von z. B. Arbeitsvorbereitung und Operating bei Mainframe-Systemen, Nachbearbeitung von Druckoutput (Sortieren, Kuvertieren, Frankieren, Binden), Hotline-Dienste zur Benutzerbetreuung usw. Eine direkte Zuordnung dieser Leistungen auf die einzelnen Leistungsempfänger ist - wenn überhaupt möglich -i. d. R. nur

126

7. Koordinationsfeld

„ Verrechnung von Kosten und Leistungen "

Bezeichnung der Leistungseinheit

Mittelpreise 1993

CPU-Zeit

1 MlPS-Stunde

270

Plattenplatz

1 MB-Monat

6,67 1,22

PlattenzugrifTe

1000 Stück

Magnetband-Zugriffe

1000 Stück

1,92

Magnetband-Montage

Stück

6,78

Magnetband-Lagerung

Rolle/Monat

7,92

DV-lmpact-Druck

1000 Zeilen

2,33

DV-Laser-Druck

1000 Seiten

99,2

RJE-Zeilen

1000 Blöcke

0,2-3,0

Bildschirm-Miete

Monat

173

BS-Anschaltzeit

Stunde

5,98

BS-Arbeitsplatz

Monat (100 Stunden)

402

PC/WS-Miete

Monat

311

PC/WS-Anschaltzeit

Stunde

3,3

PC/WS-Arbeitsplatz

Monat (100 Stunden)

491

Druckermiete

Monat

260

Drucker-Anschaltzeit

Stunde

2,27

Drucker-Arbeitsplatz

Monat (50 Stunden)

435

DFU-Steuereinheit

1 Monat

878

DFÜ-Leitungsanschluß

1 Monat

DFÜ-Übertragung

1 Million Zeichen

274 29,83

Operating/AV/AN-Arbeit

Stunde

AV/AN-Arbeit

Job/Step

8,17

88 129

Systemarbeit

Stunde

Anwendungsentwicklung

Stunde

148

Datenerfassung

1000 Zeichen

9,55

Abb. 70: Durchschnittspreise für verrechnete DV-Leistungen (Quelle: Michels, I.; CW29, 16.7.93, S.30)

über einen sehr hohen Erfassungsaufwand zu erreichen; deshalb ist es üblich, die Kosten für diese sekundären Leistungen nach einem Umlageschlüssel auf die primären Leistungen zu verteilen. Dieses Verfahren ist einfach, aber es verzerrt die Kostenbelastung des Anwenders, denn ggf werden diesem sekundäre Kosten in Rechnung gestellt, die er nicht verursacht hat. Abgesehen von diesem Sachverhalt ist eine Leistungsverrechnung nach differenzierten Bezugsgrößen präziser als eine summarische Verrechnung, denn dadurch wird die geforderte Proportionalität zwischen Inanspruchnahme von Leistungen und Verrechnung von Leistungen erfüllt. Probleme können sich jedoch hinsichtlich der Akzeptanz dieser Art der Leistungsverrechnung durch die Fachabteilungen ergeben, denn für diese sind die technischen Bezugsgrößen, die letztlich den Verrechnungspreis für die genutzte Anwendung ergeben, nicht selbstverständlich transparent. Um deren Akzeptanz zu gewinnen und um die Forderung nach Transparenz der Verrechnungsmethode zu erfüllen, sind die technischen Bezugsgrößen zu anwenderbezogenen Bezugsgrößen zu aggregieren; solche sind z. B. Rechnung, Buchungszeile, Mahnung etc. (s.o.). Dazu ist es erforderlich, pro anwendungsbezogene Bezugsgröße eine „Stückliste" der technischen Bezugsgrößen zu erstellen (Abb. 71), die die Grundlage für diese erforderliche

7. Koordinationsfeld

„ Verrechnung von Kosten und Leistungen "

127

Aggregierung ist. Hilfestellung dazu erhält man durch das Data-Repository, das die MetaStrukturen von Anwendungssystemen enthält.

Druckzeilen Abb. 71: "Stückliste" von anwenderbezogenen Bezugsgrößen

Für die Einrichtung einer differenzierten Leistungsverrechnung ist zunächst Voraussetzung, daß ein Budgetsystem existiert und daß die Bezugsgrößen, nach denen die Verrechnung von IuK-Leistungen erfolgen soll, definiert sind. Weitere Voraussetzung ist, daß je Leistungsart die Leistungsmengen vorliegen, auf deren Grundlage die Preisermittlung erfolgen soll. Diese können für den Zeitraum der Abrechnungsperiode über Ist-, Plan-oder Schätzwerte ermittelt werden. Die Ist-Werte der einzelnen Leistungsmengen ergeben sich durch Protokollierung (so z. B. die im Abrechnungszeitraum angefallenen Personalstunden durch Zeitaufschreibung oder die CPU-Sekunden, Plattenzugriffe, Druckzeilen etc. durch Accountingaufzeichnungen). Planoder Schätzwerte der Leistungsmengen lassen sich aus statistischen Aufzeichnungen über die Belastungsprofile der einzelnen Komponenten der IuK-Infrastruktur (Stunden-, Tages-, Wochen- oder Monatsprofil) und durch Analyse des Kapazitätsbedarfes neuer Anwendungen ableiten;so z. B. der Bedarf an Personalkapazität für die Anwendungsentwicklung aus Schätzverfahren für die Systementwicklung oder der Bedarf an technischer Kapazität für den Anwendungsbetrieb durch Analyse der voraussichtlichen Komponentennutzung (Anzahl erforderlicher Transaktionen, I/Os, Druckzeilen). Sind die Leistungsmengen ermittelt, so werden diesen jeweils die Kosten (Standard- oder Plankosten) gegenübergestellt, die im Abrechnungszeitraum berücksichtigt werden sollen. Die Periodenkosten je Komponente der technischen IuK-Infrastruktur (z. B. CPU, Platteneinheit, Drucksystem) setzen sich bei Vollkosten aus den direkt zugeordneten Kosten (Hardwarekosten, Wartung, Energie, Verbrauchsmaterial etc.) und aus den indirekt über Schlüsselgrößen zugeordneten Kosten (z. B. Verwaltungsgemeinkosten des IuK-Bereiches) zusammen. Die

128

7. Koordinationsfeld „ Verrechnung von Kosten und Leistungen "

Division der geplanten Periodenkosten einer Komponente durch die Planbezugsmenge ergibt dann der Kostenpreis für die Inanspruchnahme dieser Komponente, der dann ggf. preispolitisch modifiziert werden kann. 7.3.4.2.3 Verrechnung bei dezentraler IuK-Infrastruktur Eine dezentrale IuK-Infrastuktur besteht aus einem Komponenten-Netzwerk; die aktuelle Ausprägung davon ist die Client-Server-Struktur. Diese Struktur besteht i. d. R. aus zentral vorgehaltenenen Komponenten (zentrale Server für z. B. Datenbanken, Seitendrucker, Archivsysteme, E-Mail; Backbone-Netz mit Gatewayservern) und dezentralen Komponenten, die Abteilungen und Arbeitsplätzen zugeordnet sind (Server für z. B. Abteilungsdrucker, Benutzerendgeräte Workstations, Pcs, Tischdrucker und deren lokale Vernetzung). Die Inanspruchnahme der Komponenten durch die Anwender ist sehr unterschiedlich, denn es gibt Anwender, die bestimmte Komponenten regelmäßig nutzen (z. B. operative Aufgaben), und solche, die nur gelegentlich bestimmte Komponenten nutzen (z. B. Informationsrecherchen), für die aber die entsprechende technische Infrastruktur vorgehalten werden muß. In einer solchen dezentralen Infrastruktur stehen folgende Leistungsarten für eine Verrechnung zur Disposition: • Leistungen zentraler Server, • • • • • •

Bereitstellung der allgemeinen Netzinfrastruktur, Nutzung der allgemeinen Netzinfrastruktur, Bereitstellung und Nutzung anwenderindividueller Netze und Netzzugänge, Bereitstellung der Benutzerendgeräte, Bereitstellung und Nutzung lizenzpflichtiger Software, personelle Entwicklungs-, Beratungs-, und Betreuungskosten.

Die Verrechnung von Leistungen zentraler Server kann nach den gleichen Modalitäten der Verrechnung bei zentraler IuK-Infrastruktur erfolgen, sofern dazu ein Betriebssystem mit Accountingroutinen vorhanden ist; dies ist i. d. R. dann problemlos möglich, wenn als zentraler Server ein Mainframe-Rechner eingesetzt wird. Die Bereitstellung der allgemeinen Netzinfrastruktur verursacht Kosten für: •

• •

• •

Verkabelung: - Materialkosten, - Verlegekosten; Repeater, Kopplungskomponenten: - Bridges, - Router, - Verteilsysteme; Netzserver, Netzadministration.

7. Koordinationsfeld „ Verrechnung von Kosten und Leistungen "

129

Für die Verrechnung bietet sich an, diese Kosten über eine „Bereitstellungsgebühr", ähnlich der laufenden Grundgebühr für einen Telefonanschluß, den Nutzern in Rechnung zu stellen. Dazu ist es erforderlich, die periodisierten Sachkosten der Investition in die Netz-Infrastruktur zu ermitteln; die Personalkosten für die Netzadministration können zu einem Teil durch Schlüsselung (z. B. Anzahl der in den Abteilungen vorhandenen Benutzerendgeräte) in die Bereitstellungsgebühr eingerechnet werden. Die Nutzung der allgemeinen Netzinfrastruktur kann über die Bezugsgrößen „Anzahl der übertragenen Zeichen" und „Anschlußzeit" auf die Leistungsempfänger verrechnet werden. Dazu sind die Kosten des Netzbetriebs zu ermitteln; dies sind i. d. R. Kosten für • Energie, • Wartung der Netzkomponenten, • Netzadmininistration (anteilig nach aktiven Nutzern), • Leitungsgebühren bei DFÜ-Zugang. Die Bereitstellung und Nutzung anwenderindividueller Netze und Netzzugänge (z. B. abteilungseigene Standleitungen) ist aufgrund der direkten Zurechenbarkeit den jeweiligen Anwendern unmittelbar zu belasten. Hinsichtlich der Benutzerendgeräte ist zunächst zu klären, ob diese aus dem abteilungseigenen Budget oder aus dem zentralem Gesamtbudget des IuK-Bereiches beschafft worden sind. Im ersten Fall erübrigt sich eine Verrechnung der Nutzung, denn die Fachabteilung ist wirtschaftlicher Eigentümer; im zweiten Fall ist eine Verrechnung der Nutzung angebracht. Dazu sind die periodisierten Kosten aus der Investition in die Benutzerendgeräte unter Einbeziehung von Wartungs- und Reparaturkosten sowie der Kosten für pcspezifische Netzanschlüsse zu ermitteln; diese Kosten sind dann als laufende „Gerätemiete" den Anwendern in Rechnung zu stellen. Personelle Entwicklungs-, Beratungs- und Betreuungskosten sind auch hier über die Bezugsgröße „Personalstunde" zu verrechnen. 7.3.4.3

Prozeßkostenrechnung

Kosten der indirekten Leistungsbereiche von Unternehmen (Gemeinkosten) werden üblicherweise durch Zuschlagssätze auf die direkten Kosten von Produkten und Dienstleistungen verrechnet. Diese Vorgehensweise ist vertretbar, wenn die direkten Kosten den Hauptanteil an den Selbstkosten von Produkten und Dienstleistungen bilden. Verschiebt sich jedoch die Zusammensetzung der Selbstkosten dahingehend, daß der Hauptanteil daran von den Gemeinkosten gebildet wird, so sind Kostenrechnungsverfahren erforderlich, die es gestatten, den dominierenden Gemeinkostenblock zu analysieren und differenziert zu verrechnen. Dies wird durch die Prozeßkostenrechnung (Cooper/Kaplan, Horväth/Mayer)) möglich, wonach den Marktleistungen eines Unternehmens neben deren direkten Kosten insbesondere diejenigen Kosten gezielt zuzuordnen sind, die im Verlauf der verschiedenen Prozesse, die zur Erstellung der Marktleistung erforderlich sind, indirekt anfallen. Die Prozeßkostenrechnung ist demnach eine auf Geschäftsprozesse bezogene Kostenrechnung, durch die indirekten Kosten, die hauptsächlich durch Administration und Disposition im Unternehmen verursacht werden, in

130

7. Koordinationsfeld „ Verrechnung von Kosten und Leistungen "

Form von Kostensätzen für Teilprozesse differenziert den einzelnen Geschäftsprozessen zugeordnet werden. Wenn der Geschäftsprozeß z. B. „Kundenauftragslogistik" ist, dessen Prozeßleistung der erfüllte Kundenauftrag ist, dann lassen sich hierzu als Teilprozesse unterscheiden: • Aufträge bearbeiten, • Aufträge disponieren, • Aufträge ausliefern, Aufträge abrechnen. Die Fragestellungen zu den Kosten dieser Teilprozesse lauten: • Was kostet das Abklären eines Auftrages? • Was kostet eine Auftragsbestätigung? • Was kostet eine Zukaufsbestellung? • Was kostet eine Wareneinlagerung? • Was kostet eine Fertigungsauftrag? • Was kostet eine Auslieferung? • Was kostet das Erstellen einer Faktura? Kernpunkt der Prozeßkostenrechnung ist die Identifizierung von Prozessen und von denjenigen Indikatoren, die signifikant für die Verursachung der Kosten der Prozesse sind („Cost Drivers"). Prozesse werden durch Gruppierung und stufenweises Verdichten von Aktivitäten (Tätigkeiten) gewonnen (Abb. 72). Cost Driver sind Maßgrößen für die Kostenverursachung,

Abb. 72: Prinzip der Hauptprozeßverdichtung (Mayer, R., S.86, entnommen bei Horväth, P. [Controlling], S. 494)

7. Koordinationsfeld

„ Verrechnung von Kosten und Leistungen "

131

und zwar für die Kosten, die proportional zur Menge der Cost Driver entstehen. Cost Driver sind häufig die Auslöser der entsprechenden Teilprozesse (Abb. 73); sie entsprechen unter kostenrechnerischem Aspekt den Bezugsgrößen der flexiblen Plankostenrechnung.

25.000.000,-

Kosten des Untersuchungsbereichs Hauptprozesse

Cost Driver (Anzahl der...)

1.

Produktänderungen Produktänderungen

2. 3. 4.

vornehmen Varianten fertigen Teilemanagement Produktion planen

5. 6.

Produktion steuern Aufträge Inland abwickeln

7.

Aufträge Ausland abwickeln Sonstiges

8.

Varianten Teilenummem Arbeitsplanpositionen Fertigungsaufträge Inlandsaufträge Auslandsaufträge -

Anzahl

Prozeßkosten insgesamt

Prozeßkosten pro Durchführung

1.000

5.000.000,-

5.000,-

500 12.000 15.000

4.000.000,2.400.000,1.500.000,4.000.000,-

8.000,200,100,-

8.000 10.000 7.000 -

1.500.000,-

500,150,-

2.450.000,-

350,-

4.150.000,-

in % des Kostenvolumens 20,0% 16,0% 9,6% 6,0% 16,0% 6,0% 9,8% 16,6%

Abb. 73: Beispiel für Hauptprozesse, Cost Driver und verursachte Kosten (Mayer, R., S. 88, entnommen bei Horväth, P. [Controlling 9, S. 495])

Der IuK-Bereich ist der indirekte Leistungsbereich eines Unternehmens schlechthin, denn dessen Kosten sind Gemeinkosten; deshalb liegt es nahe zu prüfen, ob sich die Prozeßkostenrechnung für diesen Bereich als Instrument zur Analyse und Verrechnung von Kosten und Leistungen eignet. Zur Eignung der Prozeßkostenrechnung als Instrument nur zur Verrechnung von Kosten und Leistungen ist zu vermerken: Zeitgemäße DV-Anwendungssysteme sind integriert gestaltet, entweder nach dem Konzept integrierter Sachbearbeitung oder nach dem Konzept von integrierten Vorgangssteuerungssystemen. Leistungsobjekte solcher integrierter Systeme sind z. B. das erstellte Angebot, der bestätigte Kundenauftrag oder die versandfähige Lieferung. Die Software, die dazu benötigt wird, hat i. d. R. eine hierarchische Modulstruktur (Abb. 74); jeder dieser Module läßt sich schrittweise weiter untergliedern bis auf die Ebene von physischen Verarbeitungsprozessen (z. B. I/O-Calls, I/O-PlattenzugrifFe, Belegung von Hauptspeicher, Programm-Swaps, Menge zu übertragenden Daten in Netzen). Diese Prozesse werden durch Accounting-Programme protokolliert, und da es sich hierbei um eindeutig meßbare technische Bezugsgrößen handelt, kann die Ressourcennutzung der einzelnen Verarbeitungsprozesse nutzungs- und damit kostenproportional erfaßt werden. Die technischen BezugsgröBen entsprechen auf dieser Ebene den Cost Drivern der Prozeßkostenrechnung. Für den Anwender ist eine solcheDetaillierung von Prozessen mit zugehörigen Cost Drivern jedoch wenig geeignet. Deshalb ist auf Grundlage der Meßdaten der Accountingprogramme eine Prozeßverdichtung erforderlich, die bis auf die Ebene von anwenderbezogenen Teilprozessen reicht; dies wird

132

7. Koordinationsfeld

„ Verrechnung von Kosten und Leistungen "

dadurch erreicht, daß jedem Prozeßauslöser (Transaktion bei Dialogverarbeitung, Job bei Stapelverarbeitung) eine systeminterne Kennung (Transaktioncode, Jobcode) zugeordnet wird, über die in Verbindung mit der Benutzerkennung oder der Kennung des Anwendungssystems die Aggregierung von physischen Verarbeitungsprozessen zu anwenderbezogenen Teilprozessen vorgenommen wird. Die Beantwortung von Fragen wie z. B. „Was kostet die Erstellung eines Angebots?" oder „Was kostet die Bearbeitung eines Kundenauftrags?" wird dann dadurch möglich - vorausgesetzt, die Software weist die dazu erforderliche integrative Struktur auf.

Angebote bearbeiten

Aufträge bearbeiten

Aufträge verwalten

r

Aufträge ausliefern

*

Aufträge abrechnen

Abb. 74a: Struktur einer Vongangskette (anwenderbezogener Teilprozeß)

Abb. 74b: Modulstruktur der Software

Soll die Prozeßkostenrechnung zur Analyse und Verrechnung von Kosten und Leistungen eingesetzt werden - und das ist der eigentliche Zweck -, dann sind folgende Voraussetzungen zu erfüllen: • Untergliedern des IuK-Bereichs in Aktivitätszentren, • Definition der Teilprozesse eines jeden Aktivitätszentrums, • Definition von Cost Drivern, die signifikant für die Kostenverursachung der Teilprozesse sind.

7. Koordinationsfeld

„ Verrechnung

von Kosten

und Leistungen

"

133

D i e B i l d u n g v o n A k t i v i t ä t s z e n t r e n o r i e n t i e r t sich a n d e n L e i s t u n g e n , d i e v o m I u K - B e r e i c h f ü r d i e A n w e n d e r e r b r a c h t w e r d e n ( s . o . ) ; d a r a u s lassen sich in w e i t e r e r U n t e r g l i e d e r u n g f ü r d i e s e n Z w e c k abgrenzen(s. auch Fürer, Lammich): •

S y s t e m b e t r i e b , u n t e r g l i e d e r t in: - Arbeitsvorbereitung, - Operating, - Datenhaltung, - Ausgabe, - Netzdienste;

•

Systementwicklung,

•

Systemwartung,

•

Benutzerberatung und -betreuung.

Aktivitätszentrum „Systembetrieb"

Arbeitsvorbereitung

Teilprozesse

Vorbereiten Stapelverarbeitung

Vorbereiten Dialogverarbeitung

Cost Driver

# zentrale Jobs # Remote-Entry-Jobs # externe Datenbestände # Formularvorlagen für Druckoutput # Nutzer Teilnehmerbetrieb # Nutzer Teilhaberbetrieb

Operating

Stapelverarbeitung Dialogverarbeitung

# Jobläufe # Transaktionen

Datenhaltung

Anlegen von Datenbeständen

# # # # # #

Pflege von Datenbeständen

Ausgabe - Druck

Erstellen Druckoutput

- Nachbearbeiten

Separieren, Schneiden Versenden Druckoutput

- Archivierung

Druckoutput archivieren

Netzdienste

Netz administrieren

Auslöse-Ereignisse Speicherstellen l/O's Änderungen Speicherstellen l/O's

# # # # #

Druckzeilen Druckseiten Mehrfachdrucke Formate Kuverts pro Portokategorie # Archivierungsaufträge # archivierte Druckseiten # Netzteilnehmer # Gateways

Abb. 75: Aktivitätszentren, Teilprozesse und Cost Driver im Bereich Systembetrieb (erstellt nach Lammich, Fürer)

7. Koordinationsfeld „ Verrechnung von Kosten und Leistungen "

134

Die wichtigsten Teilprozesse, die diesen Aktivitätszentren zugeordnet werden können, sowie die zugehörigen Cost Driver sind in Abb. 75 zusammengestellt. Liegen diese Ergebnisse vor, so sind je Teilprozeß die Planmengen und die Plan-Prozeßkosten zu ermitteln; für letztere können die Accounting-Aufzeichnungen herangezogen werden, sofern es sich um systemtechnische Bezugsgrößen (Cost Driver) handelt. Aus der Division von Plan-Prozeßkosten durch Planmenge ergibt sich der Kostensatz dieses Prozesses (Abb. 76). Wird dies für alle Teilprozesse durchgeführt, so ist das Resultat eine „Preisliste" für die Leistungen der einzelnen Aktivitätszentren, die zur Analyse der Kosten und zur Verrechnung der Leistungen dient. Da die Verrechnung der Leistungen der so detaillierten Teilprozesse an den Anwender wenig zweckdienlich ist, sind diese Teilprozesse mit ihren Kostensätzen zu anwenderbezogenen Hauptprozessen zu verdichten; dies sind i. d. R. die Geschäftsprozesse. Die Prozeßkostenrechnung erweist sich somit als ein flexibles Planungs-, Steuerungs- und Kontrollinstrument, das auch für den IuK-Bereich geeignet ist.

Aktivitätszentrum:

Operating

Teilprozesse

Cost Driver

Bezeichnung

Art

Stapelverarbeitung

Anzahl Joblaufe

Dialogverarbeitung

Anzahl Transaktionen

Kostenzu- Prozeßkosten (DM) rechnung Menge

Basis

Imi

Imn

Prozeßkostensatz (DM) gesamt

Imi

gesamt

400.000

4,0 MJ

480.000,-

160.000,-

640.000,-

1,20

1,60

100.000.000

2,0 MJ

240.000,-

80.000,-

320.000,-

2,40

3,20 pro 100 Transakttonen

Überwachung/ Bedienung Host/Peripherie

1,9 MJ

Besprechnungen

0,1 MJ

8,0 MJ

228.000,-

960.000,-

Imi = leistungsmengeninduzierte Kosten Imn = leistungsmengenneutrale Kosten Abb. 76: Ermittlung von Prozeßkostensätzen (modifiziertes Beispiel von Lammich, S.17)

7.3.4.4

Service Level Vereinbarung

Die Verfahren zur Leistungsverrechnung und die Prozeßkostenrechnung werden den Zielen und den Anforderungen, die für die Verrechnung von Kosten und Leistungen des IuK-Bereiches gelten, weitgehend gerecht, aber sie verursachen auch einen nicht geringen Aufwand. Diesen zu umgehen und dennoch den Zielen und Anforderungen möglichst weitgehend zu entsprechen versucht die Methode der Service Level Vereinbarung. Darunter ist eine pauschalierte Leistungsberechnung zu verstehen, deren Grundlage die Vereinbarung zwischen Leistungser-

7. Koordinationsfeld

„ Verrechnung von Kosten und Leistungen "

135

bringer (IuK-Bereich) und Leistungsempfänger (Fachabteilung) über die Einhaltung eines bestimmten Paketes an IuK-Dienstleistungen ist. Ein solche Paket („Service Level') beinhaltet z. B. die verbindliche Zusage über feste Betriebszeiten, über das Vorhalten bestimmter Hardware- und Softwarekomponenten (z. B. Datenbanken), über Wartungsleistungen, über Reaktionszeiten bei Systemausfällen, über Hotline-Dienste, über den Umfang der Benutzerbetreuung u. ä. Die Preise für solche Dienstleistungspakete, denen ein bestimmtes Menegengerüst an voraussichtlicher Ressourcennutzung zugrunde liegt, werden pauschal gestaltet und für eine feste Zeitdauer vereinbart. Ändert sich das Mengengerüst oder ändern sich die zu erbringenden Dienstleistungen, so sind neue Preisvereinbarungen erforderlich. Wird der IuK-Bereich als Profit Center gefuhrt, so erfolgt die Preisbildung für die Dienstleistungspakete in Orientierung an den Erfolgsvorgaben für diesen Bereich.

8. Koordinationsfeld

8. 8.1

„luK-Organisation"

137

Koordinationsfeld „IuK-Organisation" Controllingziele

Die Gestaltung der Organisation des IuK-Bereiches in einem Unternehmen erstreckt sich auf die Eingliederung dieses Bereiches in die Aufbauorganisation und auf die Strukturierung der internen Organisation dieses Bereiches selbst Die Ziele fur die Organisationsgestaltung sind allgemein Effizienz und Flexibilität, wobei organisationale Effizienz wirksame und produktive Aufgabenerfullung und organisationale Flexibilität Anpassungs- und Neuerungsfähigkeit, insbesondere Fähigkeit zu Strukturveränderungen bedeutet (vgl. Schanz, 51). Daraus läßt sich als generelles Ziel für ein Organisationscontrolling • die Verbesserung der Koordinations-, Reaktions- und Anpassungsfähigkeit der Unternehmensfiihrung ableiten (Schweitzer/Friedl, 144f ). Die Präzisierung für das koodinationsfeldspezifische Controlling dazu lautet: • Schaffen der Voraussetzungen fur eine an Effizienz und Flexibilität orientierte organisatorische Gestaltung des IuK-Bereiches, d. h. - Zuordnung des IuK-Bereiches auf die Führungsebene, der der Stellenwert dieses Bereiches im Unternehmen entspricht, - Untergliederung des IuK-Bereiches und Strukturierung der bereichsinternen Organisation so, daß Wertschöpfungsfelder und Geschäftsprozesse effizient unterstützt werden können; • Effizienz der Organisation des IuK-Bereiches, d. h. insbesondere Leistungsevaluation zentraler und dezentraler Organsiationsstrukturen, • effizientes Schnittstellenmanagement, d. h. - Effizienz der Kommunikations-, Koordinations- und Kooperationsprozesse im IuKBereich, - Effizienz der Kommunikations-, Koordinations- und Kooperationsprozesse zwischen IuKBereichen und Anwendern in den Fachabteilungen („Benutzernähe"), - Effizienz der Kommunikations-, Koordinations- und Kooperationsprozesse zwischen IuK-Bereichen unternehmensintern und unternehmensübergreifend („Verbundeffizienz"); • motivationsförderndes Arbeitsumfeld.

8.2

Eingliederung in die Aufbauorganisation

Datenverarbeitung bzw. das Vorhalten einer IuK-Infrastruktur und der Betrieb von IuK-Systemen zählen i. d. R.nicht zu den primären Aufgaben oder zu den unmittelbar wertschöpfenden Prozessen eines Unternehmens; sie sind Dienstleistungsbereiche, die diese Aufgaben oder Prozesse unterstützen. Allerdings gibt es in bezug auf die Wertschätzung der Dienstleistungsfùnktion in der Praxis erhebliche Unterschiede; sie reicht von der simplen Unterstützungshilfe bei der Verarbeitung von Massendaten über die Unterstützung bei Rationalisierungsvorhaben bis zur Unterstützung und Durchdringung der strategischen Unternehmensplanung. Dementsprechend sind auch die Möglichkeiten zur Eingliederung in die Organisationsstruktur des Un-

138

8. Koordinationsfeld „ luK-Organisation "

ternehmens gefächert, denn die Verteilung von Aufgaben auf die Führungsebenen erfolgt allgemein nach deren Bedeutung fuir die Unternehmensfuhrung. Legt man vereinfachend die typische dreigestufte Führungshierarchie zugrunde, so ergeben sich fur eine funktionsorientiert gestaltete Unternehmensorganisation folgende Alternativen: •

Eingliederung von IuK auf der unteren Führungsebene als Teil einer Abteilung,

•

Eingliederung von IuK auf der mittleren Führungsebene als Abteilung,

•

Z u o r d n u n g von IuK zur oberen Führungsebene als Stabstelle,

•

Z u o r d n u n g von IuK zur oberen Führungsebene als Vorstandsressort.

Die Eingliederungsalternativen für eine objektorientiert gestaltete Unternehmensorganisation, d. h. eine divisionale Organisation bzw. eine Organisation nach Sparten oder Geschäftsbereichen, sind • •

IuK als Teil eines Zentralbereichs, z. B. als Teil des Zentralbereichs Controlling, IuK als eigener Zentralbereich, gleichrangig neben anderen Zentralbereiche, z. B. Finanzen, Controlling, Personal, und gleichrangig zu den Sparten.

Weitere Gestaltungsmöglichkeiten ergeben sich durch die Dezentralisierung der IuK-Organisation. Bei großen Unternehmen ist es üblich, den einzelnen Funktionalbereichen oder Sparten eigene IuK-Einheiten zuzuordnen, die dort als Abteilung, bereichseigene Stabstelle oder divisionales Vorstandsressort eingegliedert werden können. In diesen Fällen verbleibt i. d. R. eine übergeordnete IuK-Einheit, die je nach dem Ausmaß der Verselbständigung der funktionalbereichs- oder sparteneigenen IuK-Einheiten als zentraler IuK-AusschuB übergreifende Planungs- und Koordinationsfunktion hat, oder als zentraler Dienstleistungsbereich übergreifende IuK-Unterstützung leistet. Eine darüber hinausgehende Dezentralisierung ist die vollständige Ausgliederung des IuK-Bereichs aus dem Gefuge der internen Organisation zu einer wirtschaftlich und rechtlich selbständigen Einheit („Systemhaus"), die jedoch über eine Holding-Struktur im Unternehmensverbund verbleibt. Vor d e m Hintergrund der Ziele Effizienz und Flexibilität, die für organisatorisches Gestalten als übergeordnet gelten, sowie dem Sachverhalt Rechnung tragend, daß Informations- und Kommunikationstechnik nicht nur ein Rationalisierungsinstrument, sondern auch ein vorrangiger Wettbewerbsfaktor ist, ist die Eingliederung auf der unteren Führungsebene als Teil einer Abteilung selbst bei kleinen oder mittleren Unternehmensgrößen als nicht zeitgemäß anzusehen oder nur noch als historisches Relikt zu werten („EDV-Abteilung als Unterabteilung der Abteilung Rechnungswesen"). Die Variante „Stabstelle der oberen Führungsebene" bzw. „Teil eines Zentralbereichs" wird der Dienstleistungs- und Beratungsfunktion des IuK-Bereichs im Unternehmen gerecht, allerdings mit dem fur alle Stabstellen gelten Nachteil der fehlenden formalen Durchsetzungskompetenz gegenüber den Linieninstanzen. Dieses M a n k o erzwingt jedoch eine partnerschaftliche Kooperation zwischen der Stabstelle IuK und den Anwendern in den Fachbereichen, insbesondere dann, wenn sich diese Stabstelle wegen ihrer unmittelbaren Nähe zur Geschäftsleitung als deren Instrument zur Umsetzung der strategischen Planung versteht

8. Koordinationsfeld „ hiK-Organisation "

139

Die Variante „Abteilung auf mittlerer Führungsebene" wird dem Rollenverständnis von einer zeitgemäßen IuK-Unterstützung im Unternehmen eher gerecht, insbesondere dann, wenn diese Abteilung als Profit Center mit eigener Erfolgsverantwortung gefuhrt wird. Die Gestaltung des IuK-Bereichs als „Vorstandsressort der oberen Führungsebene" bzw. als „eigener Zentralbereich", mit oder ohne dezentralisierten Untereinheiten, aber gestaltet als Profit Center, ist von den genannten Eingliederungsmöglichkeiten die wirksamste, denn dadurch wird nicht nur die bereichsübergreifende Koordinations- und Dienstleistungsfunktion dieses Bereiches ermöglicht, sondern dessen von den übrigen Unternehmensbereichen hervorgehobene Rolle als Gestalter ganzheitlicher, wettbewerbsrelevanter Systemlösungen betont.

8.3

Strukturierung der internen Organisation

Für die Strukturierung der internenen Organisation des IuK-Bereichs gelten zunächst die allgemeinen Organisationsprinzipien für die Bildung von Stellen und Abteilungen: Verrichtungszentralisierung, Objektzentralisierung sowie Übereinstimmung von Aufgabe, Kompetenz und Verantwortung. Nach dem Prinzip der Verrichtungszentralisierung werden gleichartige Tätigkeiten („Verrichtungen") zu Aufgabenkomplexen zusammengefaßt; das Resultat ist eine fiinktionsorientierte Aufgabengliederung. Nach dem Prinzip der Objektzentralisierung hingegen werden unterschiedliche Tätigkeiten, die sich auf ein Objekt beziehen, zu Aufgabenkomplexen zusammengefaßt; das Resultat dessen ist eine objektorientierte Aufgabengliederung. Werden beide Prinzipien kombiniert angewendet, so ergeben sich Mischformen der Aufgabengliederung wie z. B. die Matrix-Organisation. Eine funktionsorientierte Aufgaben- bzw. Abteilungsgliederung ist allgemein dann zweckmäßig, wenn wenig differenzierte, möglichst homogene Leistungen zu erbringen sind. Für den IuK-Bereich ist dies dann gegeben, wenn die Leistungserstellung im wesentlichen auf dem Zentralrechnerkonzept basiert, das die geignete Infrastruktur für den Betrieb und die Erhaltung großer Administration- und Dispositionssysteme ist; in Abb. 77 ist eine dafür typische Abteilungsgliederung dargestellt. Wenn ein Spektrum an differenzierten Leistungen zu erbringen ist, die sich zudem nach Art und Umfang verändern, dann ist eine objektorientierte Aufgaben- und Abteilungsgliederung zweckmäßig, denn dadurch kann dem Sachverhalt Rechnung getragen werden, daß unterschiedliche Objekte auch unterschiedliche Tätigkeiten erfordern. Im IuK-Bereich können folgende Objekte als Bezugspunkte für die Aufgaben- und Abteilungsgliederung herangezogen werden: • Betriebswirtschaftliche Anwendungssysteme, (Entwicklung und Betreuung) • Technische Anwendungssysteme, • Zentralrechnerbetrieb, • verteilte Systeme und Netze, • Telekommunikation,

140 • • • • •

8. Koordinationsfeld

„IuK-Organisation"

Datenschutz und Datensicherheit, Benutzerservice und Informationszentrum, Komptenzzentrum „Standardsoftware", Kompetenzzentrum „Methoden und Standards" Schulung.

DV-Abteilung

Systementwicklung

Systempflege

Systemplanung

Änderungsdienst

Arbeitsvorbereitung

SystemSoftware

_

Budget u. Kontrolle

Programmierung

Wartung

Produktion

Datenbanken

-

Sicherheit u. Revision

L

Schulung

Rechenzentrum

Allg. Verwaltung

Systemtechnik

Druck

Nachbearbeitung L

Archivierung

Abb. 77: Traditionelle Gliederung einer DV-Abteilung

Diese Objekte repäsentieren die vielfältigen Dienstleistungen, die vom IuK-Bereich fur externe Auftraggeber, aber auch fur interne Zwecke erbracht werden müssen; sie sind eine Folge der weitgehend dezentralisierten Nutzung der Ressource Information im Unternehmen. Abb. 78 enthält eine detailliertere Darstellung zur aufbauorganisatorischen Gliederung des IuK-Bereiches. Als Objekt in dem obigen Sinne gelten aber auch Geschäftsprozesse, und deshalb ist es naheliegend, den IuK-Bereich prozeßorientiert zu gestalten. Zum einen wird dies zu einer zwingenden Konsequenz, wenn die Struktur der Unternehmensorganisation nach Geschäftsprozessen gestaltet wird, denn entsprechend der Maxime „Information Technology follows Organization" ist die IuK-Unterstützung an diesen Prozessen auszurichten. Zum anderen ist dies insbesondere dann sinnvoll, wenn der IuK-Bereich als Profitcenter eigenverantwortlich fur den Bereichserfolg ist, denn durch eine Strukturierung der Organisation nach Geschäftsprozessen wird markt- und erfolgsorientiertes Denken und Handeln gefördert.

8. Koordinationsfeld„IuK-Organisation"

141

Ressort Information und Kommunikation

Controlling

Administration

Betriebswirtschaftliche Anwendungssysteme

Technische Anwendungssysteme

Zentrale Systeme (Mainframe)

Dezentrale Systeme (CS)

Benutzerservice

Kompetenzzentrum

AS. Vertrieb

CAD

Operating

Endgeräte Server

Beratung u. Information

Standardsoftware

AS. Materialwirtschaft

CNC/DNC

Betriebssystem

Betriebssysteme

Help Desk u. Hotline

Dezentrale Systeme

AS. Produktion

CAQ

Datenbanken

Netze

Schulung

Methoden u. Standards Datenschutz Datensicherheit

AS. Buchhaltung

A b b . 78: Objektorientierte Gliederung d e s Ressorts Information u n d K o m m u n i k a t i o n

Geschäftsprozesse sind an Geschäftsfeldern orientiert, sie fuhren zu einer konkreten Prozeßleistung, die Effizienz des Prozesses muß meßbar sein und sie bilden jeweils einen eigenen Verantwortungsbereich. Für den IuK-Bereich im Unternehmen oder im Unternehmensverbund gibt es im Grundsatz nur ein Geschäftsfeld: der Anwender in der Rolle als zu erhaltender oder zu gewinnender Kunde. Dieser „Kunde" kann aber verschiedene Felder für „geschäftliche" Aktivitäten bieten, so z. B. • • • • •

der Betrieb und die Betreuung seiner Anwendungen, die Projektierung und Entwicklung neuer Anwendungen, die Umstellung /Umorganisation seiner Anwendungen, sein Bedarf nach individueller Nutzung der IuK-Infrastuktur, sein Bedarf nach Beratung undSchulung.

Vor dem Hintergrund dieser „Geschäftsfelder" lassen sich folgende Geschäftsprozesse für den IuK-Bereich definieren, die Grundlage für eine entsprechende organisatorische Gliederung sein können: • Betrieb und Betreuung von Anwendungssystemen (Full-Service-Konzept), • Kundenaquisition und Angebotserstellung,

142

8.

Koordinationsfeld„IuK-Organisation"

• auftragsgebundener Projektdienst: - Entwicklung von Anwendungssystemen, - Customizing von Standard-Anwendungssoftware, - technische Dienstleistungen, - Migrationsdienste, - Outsourcingunterstützung; • Infrastrukturdienst: - Bereitstellung arbeitsplatznaher IuK-Infrastruktur, - Bereitstellung von Netzdiensten, • Anwenderberatung (Dienste von Kompetenzzentren), • Helpdesk- und Hotline-Dienst. Die Organisationsstruktur des IuK-Bereiches, die nach Geschäftsprozessen dieser Art gestaltet wird, kann zusätzlich aus Gründen gezielter Kundenbetreuung durch das Konzept des „Key Account" ergänzt werden. Als „Key Account" oder als „Schlüsselkunde" gilt ein Kunde, der für ein Unternehmen bzw. hier für ein Profitcenter einen besonderen erfolgsrelevanten Stellenwert hat. Dies muß nicht unbedingt ein hoher Umsatz oder Kundendeckungsbeitrag sein; wesentlich ist vielmehr, daß der Kunde z. B. durch besondere Innovationsbereitschaft und

Abb. 79: Strukturierung des Ressorts Information und Kommunikation nach Geschäftsprozessen

8. Koordinationsfeld

„ IuK-Organisation

"

143

durch Meinungsbildung im Unternehmen Absatz- und Erfolgspotentiale „erschließt". In Abb. 79 ist eine Organisationsstruktur für den IuK-Bereich skizziert, die auf Geschäftsprozessen und „Key Accounts" beruht.

8.4

Rezentralisierung

Das Client-Server-Konzept gestattet in Verbindung mit den Möglichkeiten zur Datenfernübertragung eine weitgehende technische, räumliche und organisatorische Dezentralisierung der IuK-Unterstützung im Unternehmen bzw. im Unternehmensverbund. Das Augenmerk des Controlling hierzu gilt dem „vernünftigen Ausmaß" von Zentralisierung und Dezentralisierung. Der Beurteilungsmaßstab dafür ergibt sich zum einen aus der Struktur der Unternehmensorganisation, denn nach der Maxime „Information Technology follows Organization" soll die IuK-Organisation der organisatorischen Struktur des Unternehmens entsprechen, und zum anderen aus der Effizienz der IuK-Organisation. Wenn die Unternehmensorganisation dezentralisiert ist, z. B. in Form von Geschäftsbereichen oder Geschäftsprozessen, so erfordert dies auch eine Infrastruktur an verteilter Hardware und Software; dies bedeutet jedoch nicht, daß sämtliche Komponenten einer solchen Infrastruktur dezentralisiert werden müssen. Aus Kosten- und EfFizienzgründen sind folgende Aufgabengebiete auf einer zentralen Infrastruktur, bestehend z. B. aus Zentralrechner (Mainframe) oder einem Verbund von UNIX-Rechnern, besser aufgehoben als auf einer Infrastruktur mit verteilten Datenbanken und Applikationen: • •

transaktionsintensive Anwendungen in großen Terminlanetzen, Schnittstellenpflege integrierter Groß-Anwendungen,

• • • • •

Pflege von unternehmensweiten Datenmodellen, Pflege von unternehmensweiten Datenbanken, Netzmanagement, Kommunikationsdienste, Sicherheitsmanagement.

Verteilte Systeme hingegen haben als unstrittige Vorteile die flexible Nutzungsmöglichkeiten, die flexible Ausbaufähigkeit und moderne Benutzeroberflächen. Allerdings sind mit Systemen dieser Art auch Kosten verbunden, die sich als „versteckte Kosten" (Miller) erst im praktischen Einsatz zeigen, so z. B.: • • • • • •

Kosten für die Administration lokaler Netze, Kosten für die Wartung lokaler Server, Kosten, die aus der Komplexität von Standard-Anwendungssoftware resultieren, (z. B. Tabellenpflege durch den Anwender) Kosten durch Benutzerbetreung, Kosten für lokale Datensicherung durch den Anwender, Kosten für Fehlerbehebung durch den Anwender selbst.

In Ansehung dieser Sachverhalte stellt sich dem Controller die Aufgabe, dezentralisierte Systemkonzeptionen auf die Notwendigkeit einer Rezentralisierung hin zu überprüfen; dies kann das Client-Server-Konzept in einem Unternehmen, aber auch die Zusammenlegung von Re-

144

8. Koordinationsfeld

„IuK-Orgatiisation"

chenzentren eines Unternehmensverbundes betreffen. Was die Rezentralisierung in einer Client-Server-Struktur betrifft, so kommen dazu die oben genannten Aufgabengebiete in Frage, ergänzt z. B. durch die Einrichtung eines zentralen Benutzerservice und von Kompetenz-Zentren, z. B. für bestimmte Softwareprodukte. Ursachen für die Zusammenlegung von Rechenzentren sind im wesentlichen unterschiedliche Kapazitätsauslastung und Kosten, denn der mehrfache Betrieb und Unterhalt von weitgehend identischen Anwendungen verurschacht auch entsprechend mehrfache Kosten. Vor einer Zusammenlegung sind zwei Grundsatzfragen zu klären: •

Welche Anwendungen sind dem Front-End-Bereich, welche dem Back-End-Bereich zuzuordnen'

•

Auf welche standardisierten Software-Produkte soll man sich konzentrieren?

Die erste Frage zielt darauf ab, diejenigen Anwendungen, die „kundennah" sind (Front-EndBereich), vor Ort auf einer dezentralisierten Infrastruktur zu halten; i. d. R. sind dies unmittelbar vertriebsunterstützende Anwendungen wie z. B. Angebotserstellung, Auftragsbearbeitung, Auslieferung und After-Sales-Service. Als „kundenferne" Anwendungen (Back-End-Bereich) gelten hingegen Produktionsplanung und -Steuerung, Materialwirtschaft, Kostenrechnung und Finanzen; es bietet sich daher an, diese Anwendungen, die Querschnittsfunktionen abdecken, auf ein Rechenzentrum zu konzentrieren. Die zweite Frage resultiert aus dem Sachverhalt, daß nicht selten in den Rechenzentren eines Unternehmensverbundes für gleichartige betriebswirtschaftliche Funktionen verschieden Softwareprodukte eingesetzt werden. Häufig sind diese Produkte für unterschiedliche Systemplattformen und auf Grundlage unterschiedlicher Konzepte zur Datenhaltung entwickelt worden, so daß eine nachträgliche Integration erheblich erschwert ist. Als Lösung dieses Problems bietet sich der Einsatz von Standard-Anwendungssoftware an, wobei die Entscheidung darüber nicht ausschließlich auf ein einziges Produkt fokussieren muß. Der zentrale Betrieb mehrerer ausgewählter Standard-Softwareprodukte ist dann vertretbar und erforderlich, wenn im Unternehmensverbund unterschiedliche Betriebstypen, wie z. B. Anlagenbau, Kleinserienfertigung, Serienfertigung und Handel, vorhanden sind, die jeweils eine unterschiedlich gestaltete IuK-Unterstützung erfordern.

9. Koordinationsfeld „Outsourcing"

9.

Koordinationsfeld "Outsourcing"

9.1

Definition

145

Mit Outsourcing wird die Ausgliederung von Dienstleistungen des IuK-Bereiches zu Zwecken des Fremdbezuges ("Outside Resourcing") bezeichnet. Das Spektrum der Ausgliederungsmöglichkeiten ist weit gefaßt: Zukauf von Dienstleistungen, Betrieb der IuK-Infrastruktur, Planung der IuK-Ressourcen fur das Unternehmen, komplette Ausgliederung des gesamten IuK-Bereiches. Abb. 80 gibt einen Überblick über die verschiedenen Formen des Outsourcings; folgende Dienstleistungen sind damit verbunden: • System-Integration umfaßt die Übertragung von Planung, Entwicklung und Realisierung von kompletten IuK-Systemen auf einen externen Dienstleister; • System-Operation umfaßt die komplette oder teilweise Übertragung des Betriebes der IuK-Infrastruktur auf externe Dienstleister. Diese Form, flir die auch die Bezeichnung „Facilities Management" üblich ist, wird weiter untergliedert in: • professionelle Dienste: von externen Dienstleistern werden Personalleistungen erbracht; typische Beispiele hierzu sind Beratung, Projektmanagement, Softwareentwicklung, Softwareportierung, Erfassung von Massendaten, Pflege von Stammdaten, Schulung, Benutzerservice, Wartung.; • Verarbeitungsdienstleistungen: von externen Dienstleistern werden Sachleistungen erbracht; typisches hierzu ist der teilweise oder vollständige Betrieb der technischen IuK-Infrastruktur incl. des Betriebes von Datennetzen.

Abb. 80: Formen des Outsourcing (Quelle: Bongard, S. 84)

9.2

Controllingziele

Entsprechend den breitgefächerten Möglichkeiten, die Outsourcing bietet, sind auch die Ziele für das Controlling zu diesem Koordinationsfeld demzufolge vielfältig: • Ausschöpfen des Rationalisierungspotentials, das im IuK-Bereich des Unternehmens vorhanden ist,

146

9.

Koordinationsfeld„Outsourcing"

• Abstimmung der Planungen für Outsourcingvorhaben mit der strategischen IuK-Planung, • Definition von Entscheidungskriterien für Outsourcingvorhaben, • Wirtschaftlichkeit von Outsourcingvorhaben, • Vermeiden von Risiken durch Outsourcing, • Schaffen eines Vorgehenskonzeptes für Outsourcing-Aktivitäten, • Wahl geeigneter Outsourcingpartner und vertragliche Sicherung der vereinbarten Dienstleistungen.

9.3

Grundsatzfragen

Outourcing ist kein Spezifikum des IuK-Bereiches, sondern nur eine Variante des allgemeinen betriebswirtschaftlichen Problems zweckmäßiger Arbeitsteilung, vergleichbar mit der Entscheidung über Eigenfertigung oder Fremdbezug im industriellen Sektor. Die Entscheidungskriterien dazu sind üblicherweise Kosten, Kapitalbindung, Qualität, Versorgungssicherheit, Wirkungen auf Arbeitsplätze sowie die strategische Relevanz (z. B. Know-how-Vorsprung, kritische Erolgsfaktoren, Wettbewerbsvorteile). Diese Kriterien gelten auch für Outsourcingvorhaben des IuK-Bereiches und auch mit der grundsätzlichen betriebswirtschaftlichen Maßgabe, strategisch relevante Leistungsbereiche des Unternehmens nicht durch Fremdbezug zu ersetzen. Für den Leistungsbereich "IuK-Systeme" wäre demnach zuerst zu entscheiden, welche Systeme aus dem Anwendungsportfolio strategisch relevant sind und daher nicht Objekte des Outsourcings sein dürfen. Ein solches Vorgehen ist jedoch wenig praktikabel, denn wegen des integrativen Verbundes von Anwendungssystemen lassen sich einzelne Systeme daraus nur bedingt auf externe Dienstleistrer ausgliedern. Daraus folgt, daß es nicht sinnvoll ist, für Outsourcingplanungen, die den Betrieb der IuK-Infrastruktur betreffen, zwischen strategisch relevanten und strategisch weniger relevanten Anwendungsystemen zu unterscheiden; wenn Outsourcingüberlegungen zum Betrieb der iuK-Infrastruktur vorgenommen werden, dann sollten diese das Spektrum der IuK-Systeme in der Gesamtheit betreffen. Die strategische Planung von IuK-Ressourcen darf jedoch - mit Ausnahme des Zukaufes von Beratungsleistungen - nicht das Objekt von Outsourcingüberlegungen sein, denn diese ist eine wesentliche Komponente der nicht nach außen delegierbaren strategischen Unternehmensfuhrung.

9.4

Ausschöpfen des Rationalisierungspotentials

Bevor Überlegungen zum Outsourcing diskutiert werden, ist vorher zu prüfen, ob das Rationalisierungs- und Kostensenkungspotential im IuK-Bereich bereits voll ausgeschöpft worden ist, denn Outsourcing eignet sich nicht als Instrument, um einfach „organisatorischen Ballast" abzuwerfen. Die wichtigsten Ansatzpunkte dazu bilden die Bereiche Software, Datenhaltung, Wartung und Hardware-Infrastruktur: •

Software: - Methodisierung der Softwareentwicklung, (Entwicklungsstandards und Nutzung von CASE) - stringentes Projektmanagement,

9. Koordinationsfeld„Outsourcing"

147

- Vereinheitlichung der Software-Architektur, (z. B. nach DCE-Standard) - Einsatz von Standard-Anwendungssoftware, - Einsatz integrierter Anwendungssysteme (Reduzierung von Schnittstellen und der damit verbundenen Probleme). • Datenhaltung: - einheitliche Datenbanksysteme, - Data Warehouse für die IDV. • Wartung: - stringentes Wartungsmanagement, - stringentes Versionsmanagement, - Sanierung/Ablösung wartungsintensiver Anwendungen. • Hardware-Infrastruktur: - Umkonfigurieren/Downsizing zentraler Komponenten, - Automatisierung des Rechenzentrumbetriebs, - Zusammenlegung von Rechenzentren, - Dezentralisierung von Anwendungen und der zugehörigen Hardware-Komponenten, - einheitliche Standards für PCs und Workstations.

9.5

Vorgehensweise

Eine systematische Planung von Outsourcingüberlegungen folgt, wie bei jedem größerem Planungsvorhaben üblich, einem Top-down-Vorgehen mit der Schrittfolge von Situationsbeurteilung, Zielformulierung, Konzeptentwicklung und Realisierung. Durch die Situationsbeurteilung sollen Effizienz und Effektivität des IuK-Bereiches bewertet werden; der Weg dazu ist die Analyse von Stärken, Schwächen, Chancen und Risiken. Diese Analyse setzt zweckmäßigerweise an der strategischen IuK-Planung an, die Aussagen über das Anwendungs- und Projektportfolio, die Anwendungsarchitektur, das Datenhaltungskonzept, die Hardwarearchitektur, die Netzarchitektur, die Anwendungsentwicklung, und die organisatorische Gestaltung enthält. Von besonderem Interesse sind hierbei folgende Situationsindikatoren: • Kosten für - lfd. Anwendungsbetrieb, - Wartung und Sanierung, - Weiterentwicklung, - Neuentwicklung; • Betriebskosten der Anwendungsysteme, • Wartungsintensität der Anwendungsysteme, • Lebenszykluskosten der Anwendungsysteme, • Verrechnungssätze für IuK-Leistungen,

148 •

• • • • • • •

9. Koordinationsfeld

„Outsourcing"

Kapazitätsauslastung: - Personalkapazität, - technische Kapazität; Terminstau bei Wartungs- und Entwicklungsarbeiten, Systemverfugbarkeiten, IuK-Attraktivität und Nutzung des IuK-Potentials, Zusammensetzung des Anwendungs- und des Projektportfolios, Ausrichtung des Anwendungs- und des Projektportfolios auf die Erfordernisse von Geschäftsfeldern, Beherrschbarkeit von zeitgemäßen Methoden des Software-Engineering, Beherrschbarkeit zeitgemäßer IuK-Technik.

Aus den Ergebnissen der Situationsbeurteilung sind die Ziele für Outsourcingvorhaben abzuleiten; solche sind z. B. • Kosten des IuK-Bereiches reduzieren, • fixe Kosten des IuK-Bereiches durch Ausgliederung von Leistungen in variable Kosten umwandeln, • Erziehung der Anwender zum wirtschaftlichen Umgang mit IuK-Ressourcen durch gezieltere Leistungsverrechnung, • Personalengpässe beseitigen, • Flexibilität der Nutzung des IuK-Potentials verbessern, • Konzentration der Investitionen auf das Kerngeschäft des Unternehmens. Nach der Analyse der Ziele, die durch Outsourcing erreicht werden sollen, sind - gestützt auf die Ergebnisse der Situationsbeurteilung - die Outsourcingobjekte (Software-Entwicklung, Software-Wartung, Systeminstallation, Systembetrieb, Informationsdienste usw.) sowie der geplante Umfang und die zu wählende Form des Outsourcings zu bestimmen. Die Entscheidungen darüber stehen in engem Zusammenhang mit der Wahl des geeigneten OutsourcingPartners. Als Anbieter von Outsourcing-Dienstleistungen sind derzeit tätig HardwareHersteller, Systemhäuser, die aus der Ausgliederung unternehmenseigener EDV-Bereiche entstanden sind, Softwarehäuser, Beratungsunternehmen und Service-Rechenzentren. Für die Auswahlentscheidung geben folgende Kriterien Anhaltspunkte: • • • • • • • • •

informationstechnische Kompetenz, (Hardware, Software, Netze) betriebswirtschaftliche Kompetenz, branchenspezifische Kompetenz, Spektrum der Dienstleistungen, lokale Präsenz, Preis- und Konditionengestaltung, wirtschaftliche Stabilität, Unabhängigkeit von Hardware- oder Software-Produzenten, internationale Orientierung,

9. Koordinationsfeld„Outsourcing" • •

149

Unternehmenskultur, Vertrauenswürdigkeit.

Wird Outsourcing in Form des Facilities Managements gewählt, dann ist eine besonders sorgfältige und vorausschauende Vertragsgestaltung erforderlich, denn im Gegensatz zum Outsourcing durch Zukauf von Softwareprodukten und Dienstleistungen ist diese Form des Outsourcings i. d. R. irreversibel. Verträge über Facilities Management haben nicht selten eine Laufzeit von 10 und mehr Jahren; in Ansehung dieser langen Bindungsfristen empfiehlt es sich, den den Outsourcingvertrag in einen festen Rahmenvertrag und in variable Leistungsvereinbarungen zu untergliedern (Riedel, 3): • der Rahmenvertrag enthält die für die gesamte Laufzeit geltenden Vereinbarungen; dazu zählen z. B. Verantwortungsbereiche der Vertragspartner, Haftungsfragen sowie Garantieleistungen; • die Leistungsvereinbarungen dokumentieren die jeweils zu erbringenden Dienstleistungen, deren Konditionen und Rahmenbedingungen. Für jedes präsumtive Outsourcingobjekt ist eine Wirtschaftlichkeitsbegründung durchzufuhren. Da in einer solchen Wirtschaftlichkeitsbegründung zahlreiche qualitative Aspekte zu berücksichtigen sind, bietet es sich an, neben einer Wirtschaftlichkeitsrechnung eine ArgumenteBilanz über das Pro und Contra des Outsourcingvorhabens aufzustellen; Abb. 81 enthält ein Beispiel einer outsourcingbezogenen Argumente-Bilanz. Die Realisierung von Outsourcingvorhaben in Form von System-Operation bzw. von Facilities Management ist als Projekt durchzufuhren; das geeignete Vorgehensmodell dazu kann ein Phasenkonzept sein, das die Schrittfolge von • Situationsstudie, (Situationsbeurteilung, Zielfindung, Definition der externen Serviceleistung) • Auswahl der Servicepartner, • Vertragserstellung, • Umstellung auf externe Leistungen, • Anpassung an die bestehende Organisation enthalten kann.

150

9. Koordinationsfeld

„Outsourcing"

PRO:

CONTRA:

Strategische Aspekte:

Strategische Aspekte:

Konzentration der Finanzmittel und Investitionen auf das Kerngeschäft

Irreversible Abhängigkeiten v o m Service-Unternehmen

Know-how-Transfer durch das ServiceUnternehmen

Fremdbestimmung wegen Verzicht auf auf eigene luK-Kompetenz

Nutzung moderner luK-Technik ohne eigene direkte Investionen

Offenlegen von Strategien des Unternehmens

Flexibles reagieren auf veränderte Anforderungen an luK-Unterstützung

Schutz sensibler Daten

Standardisierung der luK-lnfrastruktur

Langfristige Bindung durch Serviceverträge

Transfer von Risiken auf das ServiceUnternehmen

Überlebensgarantie des ServiceUnternehmens

Leistungsaspekte:

Leistungsaspekte:

Professionalität des ServiceUnternehmens

Übervorteilung durch das ServiceUnternehmen wegen Verlustes an luKKnow-how

Schnelle Verfügbarkeit von technischen und personellen Kapazitäten

Fehlende Anwendernähe des luKSupports

Durchführung von luK-Vorhaben ohne betriebsinterne Restriktionen (z. B. personelle Abhängigkeiten)

Einflußverlust des luK-Managements wegen fehlender operativer Kapazitäten

Kostenaspekte:

Kostenaspekte:

Kostenreduzierung

Erhöhung der Transaktionskosten

Umwandlung von fixen Kosten in variable Kosten

Erhöhung der Kosten für SoftwareLizenzen

Verbesserte Bewertbarkeit und Planung von luK-Leistungen

Erhöhte Kommunikations- und Koordinationskosten

Verbessertes Kostenbewußtsein Personalaspekte:

Personalaspekte:

Unabhängigkeit von Problemen der Personalbeschaffung

Motivationsprobleme bei dem verbleibenden luK-Personal

Unabhängigkeit von Problemen der Personalqualifikation

Probleme bei der Personalüberleitung zum Service-Unternehmen

Entlastung des luK-Managements

Abfindungsleistungen

Abb. 81: Argumentebilanz zum Outsourcing (vgl. Knolmayer, S. 333; Lang, S. 76-79; Jagoda,S. 4; Bongard, S. 152-153)

10. Controllinginformationen

151

10.

Controllinginformationen

10.1

Controllinginformationen zum Koordinationsfeld „Strategische IuK-Planung"

11. Zu den Geschäftsfeldern des Unternehmens • • • • • • •

Geschäftsfeldziele kritische Erfolgsfaktoren Geschäftsprozesse mit definierter Leistung und mit Meßgrößen strategische Defizite Unternehmens- und geschäftsfeldspezifische Attraktivität von IuK-Technik und IuK-Systemen geschäftsprozeßbezogene und funktionale Durchdringung mit luK-Technik und IuK-Systemen Defizite in der Nutzung von [uK-Technik und IuK-Systemen

2. Zum Anwendungsportfolio •

•

Zusammensetzung - Anwendungen von strategischer Bedeutung - Anwendungen mit „Added Values" - Anwendungen zur Unterstützung der Administration - Anzahl Online-Anwendungen - Anzahl Stapel-Anwendungen - Altersstruktur der Anwendungen (%-Anteil nach Nutzungsjahren) Kosten der Anwendungen - Betriebskosten - Wartungskosten - A-B-C-Verteilung der Anwendungen nach Betriebs- und/oder Wartungskosten - Lebenszykluskosten

13. Zum Projektportfolio •

•

•

Zusammensetzung - Projekte von strategischer Bedeutung - Projekte mit „Added Values" - Pflichtprojekte (notwendiger Ersatz, gesetzliche Erfordernisse) - Projekte zur Unterstützung der Administration Kosten - Entwicklungskosten - Kosten des Fremdbezugs von Software - Projekt-Folgekosten - A-B-C-Verteilung der Projekte nach Kosten/Investionsbedarf und Nutzen Terminstau der Entwicklungsvorhaben

|4. Zur IuK-Infrastruktur •

•

Kosten - Kosten für lfd. Betrieb/IuK-Gesamtkosten - Kosten für Wartung und SW-Sanierung/IuK-Gesamtkosten - Kosten für Neuentwicklungen/IuK-Gesamtkosten - Wartungskosten/Entwicklungskosten - Investitionen in HW und SW/IuK-Gesamtkosten - Sicherheitskosten/IuK-Gesamtkosten Kapazitätsauslastung - Personalkapazität - technische Kapazität

152 10.2

10.

Controllinginformationen

Controllinginformationen zum Koordinationsfeld „Planung und Durchführung von IuK-Projekten"

11. Zum einzelnen Projekt • • • • • • • • •

• •

•

Termineinhaltung Projekt gesamt (IST-Termin / SOLL-Termin) Termineinhaltung von Projektabschnitten (IST-Termine / SOLL-Termine) Kosteneinhaltung Projekt gesamt (IST-Kosten / SOLL-Kosten) Kosteneinhaltung von Projektabschnitten (IST-Kosten / SOLL-Kosten) Kostenverteilung über die Projektphasen Projekt-Eigenleistungen (Kosten, Personalmonate) Projekt-Fremdleistungen (Kosten, Personalmonate) Projekt-Fertigstellungsgrad (Prozentsatz fertiggestellter Teilprojekte) Projektstatus (Projektfortschritt EFFEKTIV [Std| / Projektfortschritt GEPLANT [Std] // Projektkosten EFFEKTIV / Projektkosten GEPLANT) Kennzahl > 1 positiver Projektstatus Kennzahl < 1 negativer Projektstatus Reibungsfaktor der Projektaibeit (unproduktive Projektzeit / produktive Projektzeit) Rerun-Quote (Zeit für projektbezogene Test- und Wiederholungsläufe / Gesamtentwicklungszeit des Projektes) Fehlzeitenquote der Projekt-Mitarbeiter (Fehlzeiten / SOLL-Anwesenheitszeiten)

2. Zur Anwendungsentwicklung allgemein •

• • • • • • • • • • •

Anzahl lfd. Projekte nach Kategorien (Eigenentwicklung: Neuentwicklung, Ergänzung, Ersatz; Standard-Anwendungssoftware: Konzeptionierung, Anpassung) Verteilung der lfd. Projekte nach Prioritäten (MuB- / Kann-Projekte, Prioritäten nach Maßgabe des Projektportfolios) Verteilung der lfd. Projekte nach A-B-C-Klassifizierung (Kriterien: Investitionssumme, gebundene Personalkapazität) Anzahl der Projekte oberhalb einer bestimmten Investitionssumme Verteilung der Projekte nach SOLL- / IST-Fertigstellungsterminen Anzahl lfd. Projekte, bei denen eine kritische Warnschwelle erreicht wurde (Terminverzug, Kostenüberschreitung) Projekte mit externen Auflagen (Anzahl, Investitionssumme, Terminstand, Kostenstand) Software-Entwicklungskosten / IuK-Gesamtkosten Software-Wartungskosten / IuK-Gesamtkosten Personalstunden-Verrechnungssatz (Gesamt-Personalstunden / verrechenbare Personalstunden) Termintreue der Projektarbeit (Gesamtprojektzeit IST/Gesamtprojektzeit SOLL) Servicegrad der Projektaibeit (Zahl der Projektrealisierung IST / Zahl der Projektrealisierang SOLL)

10. Controllinginformationen

• • • • • •

Entwicklungsproduktivität (Anzahl Function Points / Entwicklerstunde) Auslastung der Personalkapazität (IST-Kapazität |Std] / PLAN-Kapazität [Std]) Auftragsstau [Personenmonate] Zur Anwendungsentwicklung verwendete Methoden und Werkzeuge CASE-Arbeitsplätze / Anzahl der Mitarbeiter in der Software-Entwicklung CASE-Verfflgbarkeit

153

154 10.3

10. Controllinginformationen Controllinginformationen zum Koordinationsfeld „Wirtschaftlichkeit"

11. Zum einzelnen Projekt •

• • •

• • • • • •

Projektkosten, unterteilt nach - einmalige Kosten - laufende Kosten Sondereinzelkosten des Projektes monetärer Nutzen nach Nutzenkategorien rechnerische Wirtschaftlichkeit nach - Kosteneinsparung - Amortisationsdauer - Kapitalverzinsung nicht-monetäre Nutzeffekte Prioritätskennzahl Risikokennzahl Kostenverteilung über die Projektphasen Eigenleistungen am Projekt (Kosten, Personalmonate) Fremdleistungen am Projekt (Kosten, Personalmonate)

|2. Zum Projektportfolio • • • • •

•

Investitionssumme gesamt Gesamt-Wirtschaftlichkeit A-B-C-Verteilung der Projekte nach Investitionsmitteln Rangfolge der Projekte nach Wirtschaftlichkeitskriterien Deckungsausgleich im Investitionsportfolio - geforderte Verzinsung - Wettbewerbsrelevanz Zusammensetzung - Projekte mit strategischer Bedeutung - Projekte mit „Added Values" - Pflichtprojekte - Projekte zur Unterstützung der Infrastruktur

13. Zu Anwendungssystemen • • • • •

Betriebskosten Wartungskosten A-B-C-Verteilung der Anwendungssysteme nach Betriebskosten und nach Wartungskosten Altersstruktur der Anwendungssysteme Lebenszykluskosten (Entwicklungskosten + akkumulierte Folgekosten)

10. Controllinginformationen

10.4

155

Controllinginformationen zum Koordinationsfeld „Anwendungsbetrieb und DV-Infrastruktur"

11. Zum Sicherheitamanagement • • • • • • • • • • •

Risikofelder und zugehöriges Gefahrenpotential A-B-C-Verteilung der Anwendungssysteme nach Meldungsklassen (erforderliche Reaktionszeiten) A-B-C-Verteilung der Anwendungssysteme nach präsumtiven Schadenshöhen präsumtive Schadenshöhe je Anwendungssystem (direkte und indirekte Schadenskosten) A-B-C-Verteilung der Anwendungssysteme nach Risikorelevanzzahlen Risikorelevanz je Anwendungssystem Klassifizierung der Anwendungssysteme nach Risikoklassen Kosten für Back-up-Maßnahmen Kosten für Fremdversicherungen Sicherheitskosten je Risikofeld Sicherheitskosten/DV-Gesamtkosten

12. Zum Wartungsmanagement • •

• • • • • • •

A-B-C-Verteilung der Anwendungssysteme nach Wartungskosten Wartungsintensität der Anwendungssysteme (Aufteilung der Wartungskosten je Anwendungssystem nach Anpassungwartung, korrigierende Wartung, Verbessemngswartung) Häufigkeit von Wartungsmaßnahmen pro Anwendungssystem akkumulierte Wartungskosten je Anwendungssystem/Entwicklungskosten des Anwendungssystems fortgeschriebene Lebenszykluskosten je Anwendungssystem (Entwicklungskosten, Einfuhrungskosten, Folgekosten) Gesamt-Softwarewartungskosten/Gesamt-Softwareentwicklungskosten Gesamt-Softwarewartungskosten/Gesamt-DV-Kosten Altersstruktur der Anwendungssysteme (Klassenbildung nach der Nutzungsdauer) durchschnittliche Lebensdauer der Anwendungssysteme

3. Zum Produktionsmanagement •

•

•

Systemtechnische Infrastruktur - Hardware-onfiguration - Netz-Konfiguration Leistungskennzahlen - Anzahl Transaktionen - durchschnittliche Antwortzeiten - Mainframe-Antwortzeit - Antwortzeit im Netz - Kapazität externer Datenspeicher - Netzdaten - Anzahl Netzteilnehmer - Übertragungskapazität - zentraler Output - Druckoutput [Seiten] - Archivierung (CD-ROMS, Mikrofiches) Auslastungskennzahlen - Produktionszeit/Geamtbetriebszeit - Systemverfugbarkeit (IST-Stunden/SOLL-Stunden [%]

156

•

• •

10.

Controllinginformationen

- Anzahl der Betriebsunterbrechungen pro Periode - mittlere Dauer einer Betriebsunterbrechung - Dialog-Betriebsrate (Dialogbetriebszeit/Gesamtbetirebszeit) - Stapel-Betriebsrate (Stapelbetriebszeit/ Gesamtbetriebszeit) - Belastungsprofil der Systemkomponenten nach Tageszeit - Belastungsprofil der Systemkomponenten nach Anwendungsystemen - Kapazitätsauslastung der Systemkomponenten nach Benutzern - Nutzungsgrad von Anwendungssystemen (Transaktionen/Zeiteinheit) - Ressourcenverbrauch pro Transaktionstyp Systementwicklung und Wartung - Compilierzeiten/Gesamtbetriebszeit - Testzeiten/Gesamtbetriebszeit - Wartungszeiten/Gesamtbetriebszeit Service-Level-Vereinbarungen pro Anwendungssystem Einhaltung der Service-Level-Vereinbarungen

4. Zum Benutzerservice • • • • • • • • • • • • • • •

IDV-Gesamtkosten/DV-Gesamtkosten IDV-Personalkosten/DV-Personalkosten IDV-Hardwarewartungskosten/IDV-Gesamtkosten IDV-Softwarewartungskosten/IDV-Gesamtkosten IDV-Schulungskosten/IDV-Gesanitkosten Betreuungskosten/Benutzer Betreuungszeit/Benutzer Hotline-Anfragen/Stunde Servicegrad des Hotline-Dienstes (Anzahl sofort beantwortbarer Anfragen/Gesamtzahl der Anfragen) Durchschnittliche Bearbeitungsdauer/Stömngsmeldung Personalverfiigbarkeit (durchschnittliche Wartezeit/Störungsmeldung) Schulungsangebot nach Bedarfsfeldera Schulungshäufigkeit/Anwender Schulungsdauer/Anwender Anteil CBT-Soflware im Software-Angebot

10. Controllinginformationen

10.5

Controllinginformationen zum Koordinationsfeld „Verrechnung von Kosten und Leistungen"

11. Zum Bereich Budgetierung •

• • • • • • •

Zusammensetzung der Budgets nach - Kostenarten - Leistungsbereichen Anteil der Kosten der Leistungsbereiche am Gesamtbudget Investitionen in Hardware und Software absolut Anteil der Investitionen in Hardware und Software am Gesamtbudget Sicherheitskosten absolut Anteil der Sicherheitskosten am Gesamtbudget Bindungsfnstcn von Miet-, Leasing-, Lizenzverträgen Ergebnisse der Zero-Base-Budgeting-Analyse

2. Zum Bereich Verrechnung von Kosten und Leistungen • • • • • • • • • • • • • • •

Belastungsprofile der Hardware-Komponenten der IuK- Infrastruktur Gesamtbelegungsübersichten pro Planperiode und Hardwaresystem (zentrales System, dezentrale Systeme) Batch-Statistik (Anzahl Jobs, Jobdauer) TSO-Statistik (Anzahl Log-On, Sessionzeit und Beanspruchung der Ressourcen pro TSO-User) Transaktionsstatistik (Anzahl der Transaktionen je Transaktionstyp, Anzahl der Service-Units pro Transaktion) Netzstatistik (Anzahl aktive Nutzer, übertragene Datenmengen) Outputstatistik (Anzahl Druckzeilen, Anzahl Druckseiten, Anzahl archivierter Druckseiten) Betriebskosten/Leistungsobjekt (Anwendungssystem, Dienstleistung) Betriebskosten/Anwender A-B-C-Verteilung der Anwendungssysteme nach Ressourcennutzung A-B-C-Verteilung der Anwendungssysteme nach Betriebskosten Betriebskosten/Hardware-Komponente Verrechnungssatz/Bezugsgröße Kostensatz/Teilprozeß Kostensatz/Geschäftsprozeß

157

11. Literaturverzeichnis

11.

159

Literaturverzeichnis

Adler, G.: Vorsprung durch strategische Fitness. In: Kompetenz (Diebold), Heft 18, Sept. 1992, S. 4-12.

Albach, H.; Weber, J. (Hrsg.): Controlling: Selbstverständnis - Instrumente - Perspektiven. In: ZfB-Ergänzungsheft 1991, Nr. 3, S. VII-IX.

Albrecht, A. J.: AD/M Productivity Measurement and Estimate Validation Draft. White Plains 1984.

Beschomer, D. : Investieren in die Mitarbeiterqualifikation rechnet sich und wirkt doppelt. In: Marktnahe Produktion (Hrsg. Reichwald, R ) , Wiesbaden: Gabler 1994, S. 334-351.

Biethahn, J.; Mucksch, H.; Ruf, W.: Ganzheitliches Informationsmanagement, Band I: Grundlagen, 3. Aufl. München, Wien: Oldenbourg 1994.

Boehm, B. W.: A Spiral Model of Software Development and Enhancement. In: ACM SIGSOFT Software Engineering Notes 1986, Nr. 11, S. 22-42.

Boehm, B. W. : Wirtschaftliche Software-Produktion. In: Schriftenreihe integrierte Datenverarbeitung in der Praxis, Bd. 37, Wiesbaden 1986.

Boll, M. : Prozeßorientierte Implementation des SAP Softwarepaketes. In: Wirtschaftsinformatik 1993, Nr. 5, S.418-423.

Bongard, St.: Outsourcing-Entscheidungen in der Informationsvrarbeitung. Wiesbaden: Gabler 1994.

Bottler, J.: Das Controlling-Konzept. In: Cotrolling und automatisierte Datenverarbeitung (Hrsg. Horväth, P.; Kargl, H.; Müller-Merbach, H ). Wiesbaden: Gabler 1975.

Brenner, W. ; Osterie, H. : Wie Sie Informationssyteme optimal gestalten. In: Harvard Business Manager 1994, Nr. 1, S. 46-52.

Brenner, W. : Das IV-Leitbild als Grundlage des Informationsmanagements großer Unternehmen. In. Information Management Nr. 1, 1995, S. 44-51.

Bundesamt für Sicherheit in der Informationstechnik: Grundschutz beim PC-Einsatz. Faltblatt Nr. 2, Stand: Januar 1995.

Bundschuh, M. ; Peetz, W. ; Siska, R. : Aufwandschätzung von DV-Projekten mit der Function-Point-Methode. Köln: TÜV Rheinland 1991.

Burghardt, M. : Projektmanagement. München, Berlin: Siemens 1993.

Chandler, A. D. : Strategy and Structure: Chapters in the History of the American Industrial Enterprise. Cambridge,Mass./London 1962.

Cooper, R.; Kaplan, S. : Measure Costs Right.: Make the right decisions. In: Harvard Business Review, Nr. 5, 1988, S. 96-103.

160

11.

Literaturverzeichnis

Davenport, Th.: Process Innovation: Reenigineering Work through Information Technology. Boston 1993. Dernbach, W.: Management-Konzepte: Warum Sie mit Rezepten von gestern die Krise nicht bewältigen können. In: Kompetenz (Diebold), Heft 23, Dez. 1993, S. 4-14. Dernbach, W.: Rezession als Chance - Feuerprobe fur die Informatik. In: Kompetenz (Diebold), Heft 20, März 1993, S. 40-52. Deyhle, A.: Kommentar der 12 Thesen im Beitrag KüpperAVeber/Zünd zum "Verständnis und Selbstverständnis des Controlling". In: ZfB-Ergänzungsheft 1991, Nr. 3, S. 1-8. DIN 66285: Informationsverarbeitung - Anwendungssoftware - Gütebedingungen und Prüfbestimmungen. August 1990. DIN/ISO 9000 Teil3: Qualitätsmanagement und Qualitätssicherungsnormen - Leitfaden für die Anwendung von ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software. Juni 1992. Dobschütz, L. v.; Prautsch, W.: Outsourcing-kein Allheilmittel zur Senkung der IV-Kosten. In: Controlling Heft 2, 1993, S. 100-103. Dobschütz, L. v.; Langenbacher, S.: Die systematische Erschließung von Einsparungspotentialen in der DV. In: HMD- Theorie und Praxis der Wirtschaftsinformatik 1994, Heft 178, S. 126-138. Dobschütz, L. v.; Kisting, J.; Schmidt, E. (Hrsg.): IV-Controlling in der Praxis. Wiesbaden: Gabler 1994. Dobschütz, L. v.: Wirtschaftlichkeitsanalyse von Anwendungssystemen: Prämissen und Praxis. In: Information Management, Nr. 4, 1992, S. 42-46. Dobschütz,L. v.; Kisting,./.; Prautsch, W.: Wertorientiertes Wartungsmanagement. In: DV-Management, Nr. 2, 1994, S.86-92. Douglas, D. P.(Ed.): The Role of IT in Business Reengineering. In: I/S Analyzer 1993, Nr. 8. Douglass, D. P.; Walsh, L. (Ed.): TQM in IS: Defining User Expectations. In: I/S Analyzer 1993, Nr. 5. Douglass, D. P. (Ed.): New Wrinkles in IS Outsourcing. In: I/S Analyzer 1993, No. 9. Eicker, St.u.a: Anwendungssystem-Integration und Verteilungsarchitektur aus Sicht des Reengineerings. In: Informatik Spektrum, Nr. 8, 1992, S. 137-145. Federolf, S.: Kundenorientierte Netzverrechnung. In: Office Management, Nr. 9, 1993, S. 14-47. Fürer, P. J.: Prozesse und EDV-Kostenverrrechnung. Bern: Haupt 1994. Fürer, P. J.: Prozeßbasierte DV-Leistungsverrechnung in Bankrechenzentren. In: HMD-Theorie und Praxis der Wirtschaftsinformatik 1994, Heft 179, S. 38-53. Gouillart, F. J., Kelly, J. N.: Transforming the Organization. New York u. a.: McGraw-Hill 1995.

II. Literaturverzeichnis

161

Griese, J.: Der Beitrag von ISO 9000 zur Software-Qualitätssicherung. In: Wirtschaftsinformatik 1993, Nr. 6, S.575-585. Hammer, M. ; Champy, J.: Reengineering the Corporation: A Manifestó for Business Revolution. New York 1993. Hansen, H. H. ; Riedl, R.: Strategische langfristige Informationsplanung. In: Handbuch der Wirtschaftsinformatik (Hrsg.: Kurbel, K.; Strunz, H.), Stuttgart 1990, S. 659-682. Hansen, W. R: Client-Server-Architektur. Grundlagen und Herstellerkonzepte für Downsizing und Rightsizing. Bonn u. a.: Addison-Wesley 1993. Hanssmann, F.: Informatik-Strategie im Kielwasser der Unternehmensstrategie. In: HMD-Theorie und Praxis der Wirtschaftsinformatik 1990, Heft 154, S. 29-36. Hau/s, P.: DV-Controlling. Heidelberg: Physica 1989. Heib, R.; Scheer, A.-W.: Informationssystem-Controlling. In: Management & Computer 1994, Nr. 2.,109-118. Heilmann, H. : IV-Aufbauorganisation im Wandel. In: HMD Theorie und Praxis der Wirtschaftsinformatik 1994, Heft 179, S. 27-37. Heilmann, H.: Organisation und Management der Informationsverarbeitung im Unternehmen. In: Handbuch Wirtschaftsinformatik (Hrsg. Kurbel, K„ Strunz, H ), Stuttgart:Poeschel 1990, S.683-702. Heinrich, L. J.: Informationsmanagement. 4. Aufl., München, Wien: Oldenbourg 1992. Heinrich, L. J.; Lehner, F. : Entwicklung von Informatik-Strategien. In: HMD-Theorie und Praxis der Wirtschaftsinformatik 1990, Heft 154, S. 3-28. Herrmann, O.: Kalkulation von Software-Entwicklungen. München, Wien: Oldenbourg 1983. Herrmann, O.: Verfahren der Aufwandschätzung bei der Entwicklung von Anwendungssystemen. In: Handbuch Wirtschaftsinformatik (Hrsg. Kurbel, K.; Strunz, H ) . Stuttgart: Poeschel 1990, S. 419-434. Hinlerhuber, H.: Strategische Unternehmensfuhrung I. 4. Aufl., Berlin, New York 1989. Hohler, B. : Zertifizierung und Prüfling von Softwareprodukten. In: HMD-Theorie und Praxis der Wirtschaftsinformatik 1994, Heft 175, S. 20-37. Horváth, P.; Mayer, R.: Prozeßkostenrechnung. Der neue Weg zu mehr Kostentransparenz und wirkungsvolleren Unternehmensstrategeien. In: Controlling, Nr. 4., 1989, S. 214-219. Horváth, P.; Reichmann, Th.: Vahlens Großes Controllinglexikon. München: Vahlen 1993. Horváth, F.: Controlling. München: Vahlen, 5. Aufl. 1994.

162

IL

Literaturverzeichnis

Horváth, P.: Das Controlling-Konzept. München: Beck dtv 1991. Illik, J. A.Datensicherung im Workstation-Bereich - technische und organisatorische Möglichkeiten In: HMD Theorie und Praxis der Wirtschaftsinformatik 1993, Heft 171, S. 61-72. ISO/1EC 9126: Information Technology - Software product evaluation - Quality characteristics an guidelinesfor their use. First edition 1991. Jagoda, F. : Outsourcing: Offenbarungseid des DV-Managers? In: Diebold Management Report 1991, Nr. 3, S. 3-8. Jost, IV. : Das ARIS-Toolset: Eine neue Generation von Reengineering-Werkzeugen. In: Schriften zur Unternehmensfuhrung, Bd. 53, Wiesbaden: Gabler 1994, S. 77-99. Kainz, G. A.; Walpolh, G.: Die Wertschöpfungskette als Instrument der IS-Planung. In: Information Management 1992, Nr. 4, S. 48-57. Kar gl, H.: Controlling im DV-Bereich. 2. Aufl., München, Wien: Oldenbourg 1994. Kaufmann, A.; Falkenberg, G.: Ein Vorgehensmodell zum Software-Reengineering und seine praktische Umsetzung. In: Wirtschaftsinformatik, Nr. 1, 1993, S. 13-22. Keller, G.; Meinhardt, St.: DV-gestützte Beratung bei der SAP-Softwareeinfuhrung. In: HMD Theorie und Praxis der Wirtschaftsinformatik 1994, Heft 175, S. 74-88. Knöll, H. D.; Schwarze, M.: Re-Engineering von Anwendungssoftware. Mannheim, Leipzig u. a.: BI-Wiss.-Verl., 1993, Knöll, H.-D.; Busse, J.: Aufwandschätzung von Software-Projekten in der Praxis. Mannheim: BI 1991. Knolmayer, G.: Die Auslagerung von Servicefunktionen als Strategie des IS-Managements. In: Die Informationswirtschaft im Unternehmen (Hrsg. Heinrich, L. J.; Pomberger, G.; Schauer, R ). Linz: Trauner 1991. König, R. ; Meyer, H.-U.; Mosblech, tí.: Prüfungsaspekte beim Outsourcing von DV-Leistungen. In: Zeitschrift Interne Revision Nr. 6, 1994, S.285-301. Kosiol, E.: Organisation der Unternehmung. Wiesbaden 1962. Krallmann, H.; Wiegemann, B.: Ganzheitliche Sicherheit betrieblicher Informations- und Kommunikationssysteme. In: Handbuch Informationsmanagement (Hrsg. A. W. Scheer), Wiesbaden: Gabler 1993, S.697-711. Krallmann, H.: EDV-Sicherheitsmanagement. Berlin 1989. Krüger, W.: Grundlagen der Organisationsplanung. Gießen 1983. Kupsch, P.: Unternehmensziele. In: Allgemeine Betriebswirtschaftslehre, Bd. 2: Führung (Hrsg. Bea, F., Dichtl, E.; Schweitzer, M ). Stuttgart, New York:Fischer 19983.

11. Literaturverzeichnis

163

Kurbel, K.; Dornhoff, P. : Mehr Flexibilität: Ein innovativer Ansatz fur das Softwareprojektmanagement. In: HMDTheorie und Praxis der Wirtschaftsinformatik 1993, Heft 170, S. 111-127.

Kurbel, K.: Unterstützung kooperativen Arbeitens beim Softwareprojekt-Management. In: Information Management 1993, Nr. 4, S. 50-58.

Kurbel, K.: Unterstützung kooperativen Arbeitens beim Softwareprojekt-Management. In: Information Management 1993, Nr. 4, S. 50-58.

Lammich, H.: Prozeßkostenorientierte Verrechnung von RZ-Leistungen. In: Office Management, Nr. 6, 1993, S. 14-17.

Lang, M.: Ein Votum fur partnerschaftliche Kooperation. In: Outsourcing - Modelle - Strategien Praxis (Hrsg. Heinrich, W.) Bergheim:Datacom 1992.

Lang, M. : Software-Outsourcing-globales Denken. In: Diebold Management Report Nr. 5, 1994, S. 11-14

Lehmann, F.-O.: Zur Entwicklung eines koordinationsorientierten Controlling-Paradigmas. In: zfbf 1992, Nr. 1, S. 45-61.

Lehner, F.; Röckelein, W.: Werkzeuge für die Softwarewartung. Schriftenreihe des Lehrstuhls fur Wirtschaftsinformatik und Informationsmanagement, Forschungsbericht Nr. 8, April 1994, Wissenschaftliche Hochschule fur Unternehmensfuhrung Koblenz.

Lehner, F.: Informatik-Strategien. München, Wien: Hanser 1993.

Lehner, F. : Nutzung und Wartung von Software: Das Anwendungssystem-Management. München, Wien: Oldenbourg 1989.

Leibfried, K..H.J.; McNair, C. J.: Benchmarking. Freiburg i. Br.: Haufe 1993.

Mayer, E. ; Weber, J. : Handbuch Controlling. Stuttgart: Poeschel 1990.

Mayer, R. : Prozeßkostenrechnung und Prozeßkostenmanagement. In: IFuA Horváth und Partner, Prozeßkostenmanagement, München 1991, S. 73-100.

Mertens, P.; Wedel, Th.; Hartinger, M.: Management by Parameters? In: Zeitschrift für Betriebswirtschaft 1991, Heft 5/6, S.569588.

Mertens, P. ; Dräger, U. : Expertensysteme in der Revision. In: Handwörterbuch der Revision, 2. neugestaltete und ergänzte Auflage, Stuttgart: Poeschel 1992, Sp. 504-512.

Michels, J. : Rechenzentren werden immer billiger. In: Computerwoche 1993, Nr. 29, S. 30-31.

Miller, K.: The Not-So Hidden Costs of Client-Server Computing. In: Data Communications, August, 1993, S. 25-26.

Moad, J. : Welcome to the Virtual IS Organization. In: Datamation 1994, N I . 1, S 32-35.

164

11. Literaturverzeichnis

Moll, K.-R.: Informatik-Management. Berlin u. a.: Springer 1994. Moning, II.; Winkelmann, B.: Entwicklungsphasen von Information Center. In: Wirtschaftsinformatik, Nr. 6, 1993, S. 532-541. Nagel, K.: Bewertung strategischer Wettbewerbsvorteile durch Informationssysteme. In: Informationstechnologie und strategische Führung (Hrsg. Spremann, K.; Zur, E ) , Wiesbaden: Gabler 1989, S. 49-63. Oriolo, M. : Die Object Point-Methode. Erfahrungen und neue Ansätze der SOFTWARE AG bei der Schätzung von Anwendungsprojekten. SOFTWARE AG Alsbach-Hähnlein. Osterie, H.; Brenner, W.; HiIbers, K.: Unternehmensfiihrung und Informationssystem - Der Ansatz des St.Galler Informationssystem-Managements. Stuttgart: Teubner 1991. Osterie, H.; Brenner, W.; HUbers, K.: Unternehmensfiihrung und Informationssystem. Stuttgart: Teubner 1991. Osterie, H.: Business Engineering. Berlin, Heidelberg u. a.: Springer 1995. Petrovic, O.: Groupware - Systemkategorien, Anwendungsbeispiele, Problemfelder und Entwicklungsstand. In: Information Management 1992, Nr. 1, S. 16-22. Petzold, H. J.; Schmitt, H. ./.; Verteilte Anwendungen auf der Basis von Client-Server-Architekturen. In: HMD- Theorie und Praxis der Wirtschaftsinformatik 1994, Heft 170, S. 79-92. Porter, M. E.; Millar, V.: Wettberbsvorteile durch Information. In: Harvard manager 1986, Nr. 1, S. 26-35. Preßmar, D. B. (Hrsg.): Informationsmanagement. Schriften zur Unternehmensfiihrung Bd. 49, 1993. Prey, K.: Client-Server oder Mainframe? In: Diebold Management Report, Nr. 1, 1994, S.16-18. Reichwald, R. : Ein mehrstufiger Bewertungsansatz zur wirtschaftlichen Leistungsbeurteilung der Bürokommunikation. In: Wirtschaftlichkeitsrechnungen im Bürobereich (Hrsg. Hoyer, R. H.; Kölzer, G ), Berlin 1987, S. 23-33. Richter, L.: Wiederbenutzbarkeit und Restrukturieung oder Reuse, Reengineering und Reverse Engineering. In: Wirtschaftsinformatik, Nr. 2, 1992, S. 127-136. Riedel, M. : Outsourcing, wenn "Ja" gesagt wurde. In: Diebold Management Report, Nr. 6, 1993, S. 3-6. Riedl, R.: Strategische Planung von Informationssystemen. Heidelberg 1991. Rosenbaum, U.; Sauerbrey, J.: Bedrohungs- und Risikoanalysen bei der Entwicklung sicherer IT-Systeme. In: Datenschutz und Datensicherung Nr. 1, 1995, S. 28-34. Rudolphi, M. : Client-Server-Konzept: Am Ende aller Wege? In: Diebold Management Report, Nr. 11, 1993, S. 3-6.

II. Literaturverzeichnis

165

Schanz, G.: Organisationsgestaltung. 2. Aufl., München: Vahlen 1994.

Sehe er, A. W: Wirtschaftsinformatik - Referenzmodelle für industrielle Geschäftsprozesse. Berlin u. a.: Springer, 4. Auflage, 1994.

Sehe er, A.-W.; Hoffmann, W.; Wein, R.: Customizing von Standardsoftware mit Referenzmodellen. In: HMD-Theorie und Praxis der Wirtschaftrsinformatik 1994, Heft 180, S. 92-103.

Scheer, A.-W. (Hrsg.): Handbuch Informationsmanagement. Wiesbaden: Gabler 1993.

Schildbach, Th.: Grundprobleme des Controllings aus betriebswirtschaftlicher Sicht. In: Controlling: Grundlagen - Informationssysteme - Anwendungen (Hrsg. Spremann, K.; Zur, E ). Wiesbaden. Gabler 1992, S. 21-36.

Schumann, M.; Mertens, P.; Haspel, B.: Abschätzung der Vorteilhaftigkeit von CIM-Komponenten und Integrationskonzepten: eine Bestandsaufnahme. In. Arbeitsberichte des Instituts für Mathematische Maschinen und Datenverarbeitung, Band 22, Nr. 16, 1989, Friedrich-Alexander-Universität Erlangen-Nürnberg.

Schumann, M.: Wirtschaftlichkeitsbeurteilung für IV-Systeme. In: Wirtschaftsinformatik, Nr. 2, 1993, S. 167-178.

Schweitzer, M.; Friedl, B.: Beitrag zu einer umfassenden Controlling-Konzeption. In: Controlling. Grundlagen, Informationssysteme, Anwendungen (Hrsg. Spremann, K.; Zur, E ) , Wiesbaden: Gabler 1992, S. 141-167.

Seibt, D.: Die Function-Point-Methode: Vorgehensweise, Einsatzbedingungen und Anwendungserfahrungen. In: Angewandte Informatik 1987, Nr. 1, S.3-11.

Seibt, D.: EDV-Controlling: Vom "Buchhalter" zum "Strategen". In: Office Management 1988, Nr. 2, S. 6-14.

Simon, H.: Simon für Manager. Düsseldorf, Wien u. a. 1991.

Spremann, K.; Zur, E.: Controlling: Grundlagen - Informationssysteme - Anwendungen. Wiesbaden: Gabler 1992.

Stahlknecht, P.; Drasdo, A.: Methoden und Werkzeuge der Programmsanierung. In: Wirtschaftsinformatik 1995, Nr.2, S. 160-174.

Stahlknecht, P.: Einfuhrung in die Wirtschaftsinformatik. Berlin u. a. : Springer, 7. Auflage, 1995.

Stahlknecht, P.: Verrechnungskonzepte für IV-Leistungen-ein Dauerbrenner der Informationsverarbeitung In: IIR-Conference Proceeedings, Köln 22. März 1995.

Szyperski, N.; Schmitz, P.; Kronen, J.: Outsourcing: Profil und Markt einer Dienstleistung für Unternehmen auf dem Wege zur strategischen Zentrierung. In: Wirtschaftsinformatik Nr. 3, 1993, S.228-240.

Thaller, G. E.: Computersicherheit. Braunschweig, Wiesbaden: Vieweg 1993.

166

11.

Literaturverzeichnis

Thurner, R.: Re-Engineering und Innovation in der Anwendungsentwicklung. In: Information Management, Nr. 1, 1994, S. 22-28. Wähner, G. W.: Datensicherheit und Datenschutz. Düsseldorf: VDI 1993. Wallmüller, K. : Software-Qualitätssicherung in der Praxis. München, Wien: Hanser 1990. Ward, J.; Griffiths, P.; Whitmore, P.: Strategie planning for information systems. Chichester 1990. Weidner, A.; Pietsch, M.: Neuere Entwicklungen bei der Aufbauorganistion von IV-Abteilungen. In: Arbeitspapier Nr. 4/1992 (Hrsg. Bodendorf, F.; Mertens, P.), Universität Erlangen-Nürnberg, Wirtschaftsinformatik. Windhöfel, P.: Eine Software-Inventur zeigt Mängel und Stärken der DV auf. In: Computerwoche Nr. 6, v. 10. 2. 1995, S. 47-48. Wolfram, G.: Organisatorische Gestaltung des Informationsmanagements. Bergisch Gladbach/Köln 1990. Zangemeister, Ch.: Erweiterte Wirtschaftlichkeitsanalyse (EWA). In: Fortschrittliche Betriebsfuhrung / Industrial Engineering 43 (1994), S. 63-71. Zangemeister, Ch.: Nutzwertanalyse in der Systemtechnik. 5. Aufl., München 1994. Zanger, C. ; Schöne, K. : IV-Controlling - Status quo und Entwicklungstendenzen in der Praxis. In: Information Management 1994, Nr. 1, S. 62-69.

12. Stichwortverzeichnis

12.

Stichwortverzeichnis

Analogieverfahren 52 Änderungsanforderungen 111 Anforderungsspezifizierung 46, 48 Anwenderpartizipation 47 Anwendungsbetrieb 103 ff Anwendungsentwicklung 41 ff Anwendungsportfolio 12 Arbeitskreis 32 Arbeitspaket 41 Argumentebilanz 94, 96 Benutzerbefragung 68 Benutzerservice 114 ff Bezugsgrößen anwenderbezogene 122, 126, 127 technische 122, 125, 126 für Verrechnung in Netzen 128 Bottom-Up-Verfahren 53 Budgetgliederung 118 Budgetierung 117 CASE 48, 49 Client-Server-Konzept 24 ff, Controllingaufgabe 5 Controllinginformation 151 ff Controllingziele zu Anwendungsbetrieb 103 Durchfuhrung von IuK-Projekten 29 DV-Infrastruktur 103 Organisation 137 Outsourcing 145 Planung von IuK-Projekten 29 strategische IuK-Planung Verrechnung von Kosten und Leistungen 117 Wirtschaftlichkeit 85 Datenschutz 103 Datensicherung 104 Defizite Mitwirkung der Anwenderseite 30 Planung und Steuerung von IuKProjekten 29 Unterstützung durch die Unternehmensfuhrung 30 strategische 8, 9

Entwurfsmethoden 49 Erfolgsfaktoren kritische 2, 14, 15 für Projekte 30, 31 Fachspezifikation 48 Facility Management 145, 149 Fremdversicherung 108 Function-Point-Verfahren 53 ff Geschäftsfeldstrategie 7 Geschäftsprozeß 16, 17, 142 Groupware 71 Gruppendiskussion 67 Hardwarekonfiguration 22 ff IDV 114, 115 ISO 9000 64 Kommission 32 Kostenplanung 51 ff Kostenrechnungssystem 120 Kostenumlage 121 Kostenvergleichsrechnung 90 ff Kostenverrechnung 119 ff Lebenszykluskosten 101 ff Lei stungsverrechnung differenziert 124 in Netzen 128 summarisch 123 Maschinenstunde 124 Maschinenstundensatz 124 Matrix-Projektorganisation 33 Mehr-Ebenen-Bewertungsmodell 97 Mehr-Ebenen-Wirtschaftlichkeit 88 Multifaktorenanalyse 93, 94 Multiplikatorverfahren 52 Nutzenbegrundung 92 ff Nutzwertanalyse 20, 80, 94, 100 Nutzenwirkungsnetz 94 Object-Point-Verfahren 57 ff

167

168

12.

Stichwortverzeichnis

Organisation Eingliederung in die 137 ff interne 139 ff OutsourcingArgumentebilanz 150 Formen 145 Grundsatzfragen 146 Objekte 148 Partner 148 Situationsindikatoren 147 Vertragsgestaltung 149 Vorgehensmodell 149 Phasenbeschreibung 43 Phasenkonzept 41 Potentialanalyse 15 Priorisierung 100 Problemfelder 9 Produktcontrolling 102 Produktionsmanagement 113 ff Produktmanagement 71 Produktivitätsverfahren 52 Projektdefinition 39, 40 fortschrittskontrolle 69 informationssystem 71 koordinierungsausschuß 39, 40 laboratorium 33 leiter 36 leitung 34 lenkungsausschuß 41 management 30 ff managementsystem 70 organisation 32 ff partner 3 1 , 3 1 plane 66 planung 41 ff portfolio 21, 101, 102 priorisierung 20, 100 ff risiken 98, 100 risikoprofil 99 statusbericht 70 Steuerung 67 ff strukturplan 43 team 32 Verantwortung 34, 35 Vorschlag 3 9 , 4 0

wertanalyse 69 zeitschätzung 51 f f ziele 37, 3 8

Prototyping 44 Prozeßkette 16, 17 Prozeßostenrechnung 129 ff Qualitätslenkung 67 Qualitätsmanagement 64 Qualitätsplanung 62 ff Reengineering 16 Referenzmodell 74 ff, 80 ff Ressourcenverwaltung 114 Restrukturierung 16, 18 Rezentralisierung 143 Risikoanalyse von Anwendungssystemen 107 von Projekten 97 ff Risikoportfolio 107 Risikorelevanz 107 Rollenverständnis „Bauherr" und „Architekt" 32 der Projektpartner 31 Sanierung 110 ff Schadensarten 106 Schadenshöhe 106 Schadenskosten 106 Schätzverfahren 51 ff Service-Level-Vereinbarung 134 Sicherheitsmanagement 103 ff Sicherheitsmaßnahmen 105, 106 Situationsbeurteilung 8, 9 SoftwareEigenentwicklung 41 ff Entwurfsumgebung 47 ff Fremdbezug 72 ff Produktmanagement 71 Qualität 62, 63 Reengineering 110 Sanierung 110 ff Spiralmodell 45 Standard-Anwendungssoftware Anpassung 82 Auswahl 77, 80 Auswahlkriterien 78, 79 Konzeptionierung 80 Kostenvergleich 74 Referenzmodelle 74 ff, 80 ff Tabellensteuerung 83 Umstellung 84 Vorgehensmodell

12. Stichwortverzeichnis Standortbestimmung 11 strategische Planung Unternehmensplanung 7, 8 ff der IuK-Infrastruktur 22 ff von IuK-Systemkonzeptionen 13 ff Systemablösung 112, 113 Systemsanierung 110 ff Terminplanung 51 ff Top-Down-Verfahren 53 Unternehmensstrategie 7 Verantwortungsmatrix 34, 35 Verrechnung von Kosten und Leistungen 117 ff Verrechnungsmethoden 121 ff Verrechnungspreise 123, 125, 126 versteckte Kosten 143 Vertragsverwaltung 114 Vorgangskette 18 Vorgehensmodelle zu Software-Eigenentwicklung 41 ff Software-Fremdbezug 73, 74 Outsourcing 147 Vorprojekt 39, 40

Wartung Anpassungs- 109 korrigierende 109 verbessernde 109 Wartungsmanagement 108, 110, 111 Wettbewerbsstrategie 2, 3 Wettbewerbsvorteil 1 Wettbewerbswirkungen 1 Wirtschaftlichkeit qualitative 87, 92 ff quantitative 86, 88 ff Wirtschaftlichkeitsbegriff 85 ff kriterien 85 ff modell 86, 88, 97 rechnung 88 ff Zentralrechnerkonzept 22, 23, 26 Zielbildung 13, 38 Zielstrukturierung 38 Zuschlagskalkulation 62

169