Anwendungsorientierte Wirtschaftsinformatik: Strategische Planung, Entwicklung und Nutzung von Informationssystemen [9. Aufl. 2019] 978-3-658-25580-0, 978-3-658-25581-7

Table of contents :
Front Matter ....Pages I-XIII
Front Matter ....Pages 1-1
Bedeutung von Informationssystemen und grundlegende Begriffe (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 3-23
Informationssysteme (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 25-46
Planung und Steuerung des Einsatzes von Informationssystemen (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 47-73
Organisation des Einsatzes von Informationssystemen (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 75-99
Digitale Transformation (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 101-123
Front Matter ....Pages 125-125
Mehr-Ebenen-Betrachtung bei der Gestaltung (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 127-137
Strategieebene (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 139-149
Organisationsebene (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 151-171
Informationssystemebene (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 173-193
Front Matter ....Pages 195-195
Anwendungen in ERP-Systemen (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 197-268
Anwendungen zur Entscheidungsunterstützung (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 269-322
Anwendungen zur Vernetzung mit Kunden und Lieferanten (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 323-343
Front Matter ....Pages 345-345
Phasenmodelle in der Softwareentwicklung (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 347-402
Individualentwicklung von Software (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 403-427
Fazit: Berufsbilder der Wirtschaftsinformatik (Paul Alpar, Rainer Alt, Frank Bensberg, Peter Weimann)....Pages 429-432
Back Matter ....Pages 433-516

Citation preview

Paul Alpar Rainer Alt Frank Bensberg Peter Weimann

Anwendungsorientierte Wirtschaftsinformatik Strategische Planung, Entwicklung und Nutzung von Informationssystemen 9. Auflage

Anwendungsorientierte Wirtschaftsinformatik

Paul Alpar • Rainer Alt • Frank Bensberg Peter Weimann

Anwendungsorientierte Wirtschaftsinformatik Strategische Planung, Entwicklung und Nutzung von Informationssystemen 9., überarbeitete und aktualisierte Auflage

Prof. Dr. Paul Alpar Institut für Wirtschaftsinformatik Philipps-Universität Marburg Marburg, Deutschland

Prof. Dr. Rainer Alt Institut für Wirtschaftsinformatik Universität Leipzig Leipzig, Deutschland

Prof. Dr. Frank Bensberg Wirtschaftsinformatik Hochschule Osnabrück Osnabrück, Deutschland

Prof. Dr. Peter Weimann Wirtschaftsinformatik Online Beuth Hochschule für Technik Berlin Berlin, Deutschland

In dieser Publikation wird auf Produkte der SAP SE oder eines SAP-Konzernunternehmens Bezug genommen. SAP, SAP SE, SAP R/2, SAP R/3, ABAP, SAP NetWeaver, SAP ERP, SAP ERP Solution Map, SAP FIORI, SAP Fiori Cloud, SAP S/4HANA, SAP Predictive Analytics, SAP Business Connector, SAP Activate, SAP Lumira, SAP Supply Network Collaboration, SAP Customer Relationship Management, SAP CRM, SAP Enterprise Portal, SAP Application Server, SAP Supplier Relationship Management, SAP Product Lifecycle Management, SAP Supply Chain Management, Supply Chain Cockpit, SAP-Referenz-IMG, SAP ERP Solution Map, SearchSAP, SAP.com, Global Bike Germany GmbH, SAP HANA, sowie weitere im Text erwähnte SAP-Produkte und Dienstleistungen sowie die entsprechenden Logos sind Marken oder eingetragene Marken der SAP SE in Deutschland oder eines SAP-Konzernunternehmens. Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen. Die Angaben im Text sind unverbindlich und dienen lediglich zu Informationszwecken. Produkte können länderspezifische Unterschiede aufweisen. Die SAP ist weder Autor noch Herausgeber dieser Publikation. Der SAP-Konzern übernimmt keinerlei Haftung oder Garantie für Fehler oder Unvollständigkeiten in dieser Publikation. Der SAP Konzern steht lediglich für Produkte und Dienstleistungen nach der Maßgabe ein, die in der Vereinbarung über die jeweiligen Produkte und Dienstleistungen ausdrücklich geregelt ist. Aus den in dieser Publikation enthaltenen Informationen ergibt sich keine weiterführende Haftung.

ISBN 978-3-658-25580-0    ISBN 978-3-658-25581-7  (eBook) https://doi.org/10.1007/978-3-658-25581-7 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Vieweg © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 1998, 2000, 2002, 2005, 2008, 2011, 2014, 2016, 2019 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Vorwort zur 9. Auflage

Die neunte Auflage setzt die Anwendungsorientierung der vorherigen Auflagen mit der Aktualisierung der Beschreibung wichtiger betriebswirtschaftlicher Standardsysteme ­sowie zahlreicher Anwendungsbeispiele fort. Insbesondere hat die Anwendungsorientierung mit der Digitalisierung auch in der öffentlichen Wahrnehmung seit der vergangenen Auflage erheblich zugenommen. Entsprechend enthält das Buch nun zusätzlich Beschreibungen einiger Methoden, die teilweise schon vor Jahren entstanden sind, aber nun Anwendungsreife ­erlangen. Dazu gehören Lernmethoden der künstlichen Intelligenz wie Reinforcement ­Learning, Recurrent und Convolutional Neural Nets, aber auch Text Mining, mit dem z. B. unstrukturierte Inhalte in sozialen Medien analysiert werden können. Mit Convolutional Neuronal Nets hat man schon große Erfolge bei der automatisierten Erkennung von P ­ ersonen, Objekten und Situationen erzielt. So kann der Einsatz solcher Methoden die Automatisierung in der Fertigung (als Industrie 4.0 bezeichnet), den Schutz von Objekten oder das Einkaufen im Supermarkt vorantreiben. Ähnliches gilt für den Einsatz der Blockchain, die sichere Geschäfte ohne Intermediäre erlaubt. Industrie 4.0 und allgemein die Anbindung von Dingen in das Internet (Internet of Things) werden in der Praxis durch Cloud und Edge Computing unterstützt. Diese Beispiele illustrieren die Intention der anwendungsorientierten Wirtschaftsinformatik: der laufende technologische Fortschritt führt zu Informationstechnologien, die ­jedoch erst in einem Anwendungszusammenhang auch einen Nutzen entwickeln. Für den Einsatz im Wirtschaftsleben sind diese Technologien daher stets in der Wechselwirkung mit den Geschäftsmodellen und -prozessen zu betrachten. Methoden zur Gestaltung ­betrieblicher Systeme unter Berücksichtigung dieser Wechselwirkungen haben in dieser Auflage eine weitere Überarbeitung in Form eines neuen durchgehenden Beispiels erhalten. Ebenso sind neuere Verfahren wie das Process Mining zur Identifikation von Prozessverbesserungen oder die Robotic Process Automation zur Reduktion manueller Tätigkeiten in Prozessen berücksichtigt. Ferner hat das gesellschaftlich wichtige Thema des Datenschutzes nach der neuen DSGVO eine Aktualisierung erfahren, denn gerade die ­zunehmende Digitalisierung von Wirtschaft und Gesellschaft erfordert mehr Schutz der privaten Sphäre.

V

VI

Vorwort zur 9. Auflage

Zur Konzentration auf die Anwendungsorientierung fällt der Teil zur Softwareentwicklung nun etwas schlanker aus und bezieht dafür neue Themen wie das agile Projektmanagement und die schnelle Inbetriebnahme von neuentwickelten Informationssystemen (Dev­ Ops) mit ein. Wir schließen diesmal mit Berufsbildern für Wirtschaftsinformatiker ab, die derzeit und perspektivisch hervorragende Chancen für Absolventen bieten, obgleich die Automatisierung viele andere, teilweise anspruchsvolle Berufe zunehmend b­ edroht. Wie in der Vergangenheit enthält das überarbeitete Glossar viele technische Begriffe, die Leser dort nachschlagen können, ohne nach weiteren Quellen suchen zu müssen. Für die gewissenhafte Unterstützung der inhaltlichen Überarbeitung und der Gesamtredaktion danken wir insbesondere Herrn Christian Hrach von der Universität Leipzig, den Herr Finn Jessen bei der Finalisierung tatkräftig unterstützt hat. Ebenso danken wir Herrn Lars Osterbrink von der Universität Marburg für weitere wertvolle Hinweise. Ganz besonders möchten wir uns bei den bisherigen Mitautoren Heinz Lothar Grob von der Universität Münster und Robert Winter von der Universität St. Gallen für ihr langjähriges Mitwirken an diesem Lehrbuch seit der ersten Auflage im Jahr 1998 bedanken und hoffen, dass wir die „Anwendungsorientierte Wirtschaftsinformatik“ in ihrem Sinne weitergeführt haben. Berlin, Leipzig, Marburg, Osnabrück, im März 2019 Die Autoren

Vorwort zur 1. Auflage (gekürzt)

Die Wirtschaftsinformatik befasst sich mit der Untersuchung der Struktur und des Verhaltens betrieblicher Informations- und Kommunikationssysteme (IKS) sowie mit deren Planung, Entwicklung, Einführung und Betrieb. Die große Verbreitung und Bedeutung solcher Systeme in der Unternehmenspraxis sowie die erfreulich große Zahl von Studiengängen, Vertiefungsgebieten und Wahlfächern zu Wirtschaftsinformatik an Fachhochschulen und Universitäten haben dazu geführt, dass heute eine Vielzahl von Lehrbüchern zu diesem Thema angeboten wird. Viele Bücher sind jedoch noch immer von einer früher vorherrschenden, technischen Sicht bestimmt, sie fangen mit der Hardware an und kommen erst zum Schluss zu den eigentlichen unternehmerischen Problemen („Bottom-­up“Orientierung). Wir versuchen deshalb mit diesem Buch, IKS von ihrer strategischen Planung bis zu ihrer Realisierung mit bestehender Software und Hardware zu erklären („Top-down“-Orientierung). Das „Wozu“ wird konsequent dem „Wie“ vorangestellt. In Teil I des Buches wird zunächst die Nutzung der Potenziale von IKS zur Lösung betrieblicher Probleme analysiert. In Teil II werden die unterschiedlichen, zur Erreichung dieser Ziele verfügbaren Anwendungsarchitekturen vorgestellt. Nachdem die Struktur und das Verhalten solcher Anwendungsarchitekturen erklärt wurden, wird in Teil III beschrieben, wie deren Komponenten, nämlich einzelne Anwendungen, selbst entwickelt oder aus fremd bezogenen Standardkomponenten geschaffen werden. Die zur Realisierung betrieblicher IKS benutzten Hardware- und Softwarekonzepte sowie ihre relevanten technischen Grundlagen stehen im Mittelpunkt des abschließenden Teils IV. Alle Darstellungen sind unternehmensorientiert, d. h. ausdrücklich auf die betriebliche Verwendung von IKS zugeschnitten. Zielgruppe dieses Buches sind einerseits Benutzer betrieblicher IKS, die sich einen Überblick über die Strukturen und Hintergründe des Einsatzes sowie der Entwicklung und Einführung von IKS verschaffen wollen. Andererseits wenden wir uns natürlich an Studierende der Wirtschaftsinformatik, sei es in den ersten Semestern eines Studiengangs Wirtschaftsinformatik, in einem entsprechenden Wahl- bzw. Vertiefungsfach eines

VII

VIII

Vorwort zur 1. Auflage (gekürzt)

wirtschaftswissenschaftlichen Studiums (BWL, VWL, Ökonomie, Wirtschaftsmathematik, Wirtschaftsingenieurwesen etc.) oder als Teil der allgemeinen BWL.  Auch Studierende der Informatik können sich mithilfe dieses Buches als Ergänzung technischer oder naturwissenschaftlicher Sichtweisen die anwendungsorientierte Sicht der Informationsverarbeitung erarbeiten. November 1997 Die Autoren

Inhaltsverzeichnis

Teil I  Informationssysteme in Unternehmen 1 Bedeutung von Informationssystemen und grundlegende Begriffe . . . . . . . .   3 1.1 Bedeutung von Informationssystemen in Organisationen ����������������������������   3 1.2 Information und Wissen ������������������������������������������������������������������������������   6 1.3 Problemlösen������������������������������������������������������������������������������������������������   9 1.4 Wert von Informationen ������������������������������������������������������������������������������  12 1.5 System und Modell ��������������������������������������������������������������������������������������  15 1.6 Modelle von Unternehmen ��������������������������������������������������������������������������  18 1.6.1 Unternehmen als eine Organisation ������������������������������������������������  18 1.6.2 Unternehmensaufgaben��������������������������������������������������������������������  19 1.6.3 Unternehmen aus ganzheitlicher Sicht��������������������������������������������  21 2 Informationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  25 2.1 Definition von Informationssystemen����������������������������������������������������������  25 2.2 Evolution der Informationssysteme ������������������������������������������������������������  26 2.3 Arten von Informationssystemen ����������������������������������������������������������������  28 2.3.1 Klassifikationsschemata ������������������������������������������������������������������  28 2.3.2 Systems of Record ��������������������������������������������������������������������������  32 2.3.3 Systems of Insight����������������������������������������������������������������������������  33 2.3.4 Systems of Engagement ������������������������������������������������������������������  43 2.4 Wechselwirkungen zwischen Informationstechnologie und Organisationen ��������������������������������������������������������������������������������������������  44 3 Planung und Steuerung des Einsatzes von Informationssystemen . . . . . . . . .  47 3.1 Informationsmanagement ����������������������������������������������������������������������������  47 3.1.1 Aufgaben des Informationsmanagements ����������������������������������������  47 3.1.2 Sichten auf das Informationsmanagement ��������������������������������������  48 3.1.3 Wissensmanagement������������������������������������������������������������������������  48 3.2 Controlling von Informationssystemen��������������������������������������������������������  50 3.2.1 Begriffsbestimmung ������������������������������������������������������������������������  50 3.2.2 Strategisches IT-Controlling ������������������������������������������������������������  51 IX

X

Inhaltsverzeichnis

3.2.3 Operatives IT-Controlling ����������������������������������������������������������������  56 3.2.4 Balanced Scorecard als Integrationsinstrument ������������������������������  59 3.3 Wertbeitrag von Informationssystemen ��������������������������������������������������������  61 3.4 IT- und Data Governance ����������������������������������������������������������������������������  67 3.4.1 Bezugsrahmen����������������������������������������������������������������������������������  67 3.4.2 COBIT����������������������������������������������������������������������������������������������  68 3.4.3 Data Governance������������������������������������������������������������������������������  73 4 Organisation des Einsatzes von Informationssystemen . . . . . . . . . . . . . . . . . .  75 4.1 Organisation der IS-Funktion ����������������������������������������������������������������������  75 4.1.1 Betriebliche Einordnung der IS-Funktion����������������������������������������  75 4.1.2 Innere Organisation der IT-Abteilung����������������������������������������������  77 4.2 IT-Servicemanagement mit Hilfe von ITIL ��������������������������������������������������  80 4.2.1 ITIL ��������������������������������������������������������������������������������������������������  80 4.2.2 Service Strategy��������������������������������������������������������������������������������  81 4.2.3 Service Design����������������������������������������������������������������������������������  82 4.2.4 Service Transition ����������������������������������������������������������������������������  83 4.2.5 Service Operation ����������������������������������������������������������������������������  84 4.2.6 Continual Service Improvement ������������������������������������������������������  84 4.3 Datensicherheit und Datenschutz ����������������������������������������������������������������  85 4.3.1 Gegenstand der Sicherheitsbemühungen ����������������������������������������  85 4.3.2 Standards und Zertifizierung������������������������������������������������������������  89 4.3.3 Datenschutz ��������������������������������������������������������������������������������������  89 4.3.4 Blockchain����������������������������������������������������������������������������������������  91 4.4 Fremdbezug von IS-Leistungen ������������������������������������������������������������������  93 4.4.1 Theoretische Grundlagen ����������������������������������������������������������������  93 4.4.2 Formen von Outsourcing������������������������������������������������������������������  95 4.4.3 Cloud, Edge und Fog Computing ����������������������������������������������������  96 5 Digitale Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.1 Digitalisierung ���������������������������������������������������������������������������������������������� 101 5.2 Electronic Business�������������������������������������������������������������������������������������� 103 5.2.1 Einführung���������������������������������������������������������������������������������������� 103 5.2.2 Ausgehende Aktivitäten�������������������������������������������������������������������� 105 5.2.3 Interne und eingehende Aktivitäten�������������������������������������������������� 106 5.2.4 Unterstützende Aktivitäten �������������������������������������������������������������� 107 5.3 Mobile Business ������������������������������������������������������������������������������������������ 109 5.4 Soziale Medien und Web 2.0������������������������������������������������������������������������ 111 5.4.1 Eigenschaften von Web 2.0-Anwendungen ������������������������������������ 111 5.4.2 Soziale Netzwerke mit Fokus auf Kommunikation ������������������������ 113 5.4.3 Soziale Netzwerke mit Fokus auf multimediale Inhalte ������������������ 114 5.4.4 Weblogs�������������������������������������������������������������������������������������������� 116

Inhaltsverzeichnis

XI

5.4.5 Wikis ������������������������������������������������������������������������������������������������ 117 5.4.6 Weitere soziale Netzwerke �������������������������������������������������������������� 118 5.5 Internet der Dinge, M2M und Industrie 4.0 ������������������������������������������������ 119 5.5.1 Internet der Dinge ���������������������������������������������������������������������������� 119 5.5.2 Industrie 4.0 ������������������������������������������������������������������������������������ 120 Teil II  Gestaltung der Digitalisierung 6 Mehr-Ebenen-Betrachtung bei der Gestaltung. . . . . . . . . . . . . . . . . . . . . . . . . 127 6.1 Gestaltungsansätze���������������������������������������������������������������������������������������� 129 6.2 Gestaltungsebenen ���������������������������������������������������������������������������������������� 133 7 Strategieebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.1 Gestaltungsinhalte auf Strategieebene �������������������������������������������������������� 139 7.2 Kundenprozessmodell���������������������������������������������������������������������������������� 140 7.3 Geschäftsmodell und -netzwerk ������������������������������������������������������������������ 142 7.4 Strategische Prozessführung ������������������������������������������������������������������������ 147 8 Organisationsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 8.1 Gestaltungsinhalte auf Organisationsebene ������������������������������������������������ 151 8.2 Prozess- und Leistungsüberblick������������������������������������������������������������������ 152 8.3 Ablaufplanung ���������������������������������������������������������������������������������������������� 156 8.3.1 Makro-Ablaufplanung ���������������������������������������������������������������������� 156 8.3.2 Mikro-Ablaufplanung und Workflows �������������������������������������������� 157 8.3.3 Prozessmodellierungssprachen am Beispiel eEPK und BPMN ������ 157 8.3.4 Aktuelle Entwicklungen ������������������������������������������������������������������ 164 8.4 Aufbauorganisation �������������������������������������������������������������������������������������� 167 8.5 Operative Prozessführung und -messung ���������������������������������������������������� 167 9 Informationssystemebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 9.1 Gestaltungsinhalte auf IS-Ebene ������������������������������������������������������������������ 173 9.2 Anwendungsarchitektur und Anwendungslandschaft���������������������������������� 175 9.3 Gestaltung und Weiterentwicklung von Services���������������������������������������� 179 9.4 Systemmodellierung mit der Unified Modeling Language (UML) ������������ 182 9.5 Datenmodellierung mit der Entity-Relationship-Notation (ER) �������������������� 190 Teil III  Betriebliche Anwendungen 10 Anwendungen in ERP-Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 10.1 Überblick���������������������������������������������������������������������������������������������������� 197 10.2 Sektorneutrale Anwendungen �������������������������������������������������������������������� 200 10.2.1 Rechnungswesen als Kern des ERP-Systems ������������������������������ 200 10.2.2 Externes Rechnungswesen ���������������������������������������������������������� 204

XII

Inhaltsverzeichnis

10.2.3 Internes Rechnungswesen������������������������������������������������������������ 235 10.2.4 Nutzung des SAP Enterprise Portal���������������������������������������������� 238 10.3 Sektorspezifische Anwendungen ���������������������������������������������������������������� 241 10.3.1 Industriebetriebe �������������������������������������������������������������������������� 241 10.3.2 Handelsbetriebe���������������������������������������������������������������������������� 245 10.3.3 Finanzdienstleister������������������������������������������������������������������������ 247 10.3.4 Telekommunikationsdienstleister ������������������������������������������������ 252 10.3.5 Energiewirtschaft�������������������������������������������������������������������������� 255 10.4 Einführung von ERP-Systemen als Standardsoftware ������������������������������ 259 10.4.1 Vorgehensmodell zur ERP-Einführung���������������������������������������� 259 10.4.2 SAP Activate als Vorgehensmodell zur Einführung von SAP ERP�������������������������������������������������������������������������������������� 264 10.4.3 Open Source Software������������������������������������������������������������������ 266 11 Anwendungen zur Entscheidungsunterstützung . . . . . . . . . . . . . . . . . . . . . . . 269 11.1 Überblick���������������������������������������������������������������������������������������������������� 269 11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen ������ 278 11.2.1 Data-Warehouse-Konzept ������������������������������������������������������������ 278 11.2.2 Berichtssysteme �������������������������������������������������������������������������� 282 11.2.3 OLAP-Konzept ���������������������������������������������������������������������������� 283 11.2.4 Mobile Business Intelligence ������������������������������������������������������ 290 11.2.5 BI-Systembeispiel: Microsoft Power BI�������������������������������������� 295 11.2.6 Big Data���������������������������������������������������������������������������������������� 298 11.2.7 Big-Data-Systembeispiel: SAP HANA �������������������������������������� 306 11.3 Anwendungsbeispiele für aufgabenorientierte Entscheidungsunterstützungssysteme �������������������������������������������������������� 309 11.3.1 Integrierte Erfolgs-, Finanz- und Bilanzplanung������������������������ 309 11.3.2 Unternehmensplanung ������������������������������������������������������������������ 315 11.3.3 Investitionscontrolling mit Simulationswerkzeugen�������������������� 318 12 Anwendungen zur Vernetzung mit Kunden und Lieferanten . . . . . . . . . . . . . 323 12.1 Überblick���������������������������������������������������������������������������������������������������� 323 12.2 Überbetriebliche Anwendungen ���������������������������������������������������������������� 326 12.2.1 Customer Relationship Management ������������������������������������������ 327 12.2.2 Supply Chain Management ���������������������������������������������������������� 332 12.2.3 Electronic Commerce ������������������������������������������������������������������ 335 12.3 Nutzen vernetzter Anwendungen �������������������������������������������������������������� 340 Teil IV  Softwareentwicklung 13 Phasenmodelle in der Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.1 Gegenstand und Ziele �������������������������������������������������������������������������������� 347 13.2 Grundlegende Entwicklungsstrategien ������������������������������������������������������ 350 13.3 Softwareentwicklungszyklus���������������������������������������������������������������������� 352

Inhaltsverzeichnis

XIII

13.4 Requirements Engineering in der Softwareentwicklung ���������������������������� 357 13.4.1 Vorgehen beim Requirements Engineering ���������������������������������� 362 13.4.2 Lastenheft und Pflichtenheft �������������������������������������������������������� 364 13.5 Vorgehensmodelle�������������������������������������������������������������������������������������� 365 13.5.1 Phasenmodelle am Beispiel des V-Modells �������������������������������� 365 13.5.2 Prototyping ���������������������������������������������������������������������������������� 368 13.5.3 Agile Softwareentwicklung���������������������������������������������������������� 371 13.5.4 DevOps ���������������������������������������������������������������������������������������� 375 13.5.5 Vorgehensmodelle zur Entwicklung sicherer Software �������������� 377 13.6 Projektmanagement������������������������������������������������������������������������������������ 379 13.6.1 Grundlegende Begriffe ���������������������������������������������������������������� 379 13.6.2 PMBOK und PRINCE2 �������������������������������������������������������������� 381 13.6.3 Projektphasen ������������������������������������������������������������������������������ 382 13.6.4 Projektstart ���������������������������������������������������������������������������������� 384 13.6.5 Projektplanung ���������������������������������������������������������������������������� 385 13.6.6 Planoptimierung �������������������������������������������������������������������������� 393 13.6.7 Projektdurchführung und Projektkontrolle ���������������������������������� 393 13.6.8 Projektabschluss �������������������������������������������������������������������������� 394 13.6.9 Risikomanagement ���������������������������������������������������������������������� 395 13.6.10 Nachforderungsmanagement ������������������������������������������������������ 399 13.7 Qualitätsmanagement �������������������������������������������������������������������������������� 400 13.8 Konfigurationsmanagement ���������������������������������������������������������������������� 402 14 Individualentwicklung von Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 14.1 Objektorientierte Softwareentwicklung������������������������������������������������������ 403 14.2 Vorgehen bei der objektorientierten Softwareentwicklung������������������������ 405 14.3 Methoden für die Analyse�������������������������������������������������������������������������� 407 14.3.1 Anwendungsfallgesteuerte Analyse �������������������������������������������� 407 14.3.2 Klassendiagramme in der Analyse ���������������������������������������������� 409 14.4 Methoden für den Entwurf ������������������������������������������������������������������������ 413 14.4.1 Objektorientierter Entwurf ���������������������������������������������������������� 413 14.4.2 Entwurf der Benutzeroberfläche �������������������������������������������������� 419 14.5 Methoden für die Implementierung und den Test �������������������������������������� 420 14.5.1 Codierung ������������������������������������������������������������������������������������ 421 14.5.2 Test ���������������������������������������������������������������������������������������������� 421 14.6 Methoden für die Softwarewartung ������������������������������������������������������������ 426 14.6.1 Software Reengineering �������������������������������������������������������������� 426 14.6.2 Reverse Engineering �������������������������������������������������������������������� 427 15 Fazit: Berufsbilder der Wirtschaftsinformatik . . . . . . . . . . . . . . . . . . . . . . . . . 429 Glossar�������������������������������������������������������������������������������������������������������������������������� 433 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

Teil I Informationssysteme in Unternehmen

1

Bedeutung von Informationssystemen und grundlegende Begriffe

Zusammenfassung

Das erste Kapitel definiert grundlegende Begriffe, darunter Daten, Information und System. Es werden auch verschiedene Ansätze vorgestellt, mit denen man den Wert von Informationen ermitteln kann.

1.1

Bedeutung von Informationssystemen in Organisationen

Dieses Buch führt in die Disziplin der Wirtschaftsinformatik ein. Sie ist zunächst aus der Anwendung der Informatik in Wirtschaftswissenschaften bzw. in Unternehmen entstanden. Inzwischen sind viele Methoden und Werkzeuge originär innerhalb der Wirtschaftsinformatik entwickelt worden, die der strategischen Planung von Informationssystemen (IS), ihrem Aufbau und der Beobachtung ihres organisationalen Einsatzes dienen. Die Wirtschaftsinformatik kann über ihren Gegenstand definiert werden. cc Wirtschaftsinformatik  Gegenstand der Wirtschaftsinformatik sind Informationssysteme in Wirtschaft, Verwaltung und privatem Bereich (WKWI/GI 2017). Die genauere Betrachtung ihrer Ziele als Wissenschaftsdisziplin macht deutlich, dass es dabei nicht nur um den ingenieurwissenschaftlichen Aufbau und die Nutzung von IS geht, sondern auch um die wirtschaftliche und soziologische Betrachtung ihres Einsatzes.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_1

3

4

1  Bedeutung von Informationssystemen und grundlegende Begriffe

cc Ziele der Wirtschaftsinformatik  Ziele der Wissenschaftsdisziplin Wirtschaftsinformatik sind a) die (Weiter-)Entwicklung von Theorien, Methoden und Werkzeugen zur Gewinnung intersubjektiv überprüfbarer Erkenntnisse über IS, b) die gestaltungsorientierte Konstruktion von IS sowie die dafür notwendige (Weiter-) Entwicklung von Konzepten, Vorgehensweisen, Modellen, Methoden, Werkzeugen und (Modellierungs-)Sprachen, c) die Erzielung eines realwissenschaftlichen Verständnisses von Einsatz, Akzeptanz, Management und Beherrschbarkeit von IS sowie von ihren jeweiligen Systemelementen, etwa im Hinblick auf das Verhalten von Menschen in und mit diesen Systemen als Aufgabenträger oder Anwender, d) die primär wirtschaftswissenschaftlich fundierte Bewertung von Risiko-, Nutzen- und Wirtschaftlichkeitsdimensionen bei Gestaltung und Einsatz von IS, der durch sie veränderten Wertschöpfungsprozesse sowie der damit verbundenen strategischen und organisatorischen Auswirkungen auf Individuen, Gruppen, Unternehmen, Branchen und Wirtschaftsräume, und e) die Prognose technischer und nichttechnischer Entwicklungen und Auswirkungen des Einsatzes von IS (WKWI/GI 2017). In der angelsächsischen Welt wird die Disziplin meist als Information Systems oder Management Information Systems bezeichnet. Informations- und Kommunikationssysteme werden nachfolgend der Praxis entsprechend kurz als Informationssysteme bezeichnet, wobei alle IS auch Komponenten der Kommunikationstechnologie enthalten. Ebenso wird nachfolgend für den Begriff Informations- und Kommunikationstechnologie das kürzere Wort Informationstechnologie (IT) verwendet. Der wichtigste deutsche Wirtschaftsverband von Unternehmen, die Produkte und Dienstleistungen mithilfe von IS bzw. IT anbieten, nennt sich BITKOM (Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.). IS sind allgegenwärtig. Nicht nur in Unternehmen haben sie einen Einfluss auf die Organisation, auf Gruppen und Individuen. Auch privat kommt jeder Mensch direkt oder indirekt mit IS in Berührung. Von Geburt an werden Daten zur Person erfasst: vom Krankenhaus, von der Einwohnermeldestelle, von Babynahrungsmittelherstellern, von Versicherungen und vielen anderen Organisationen. Dies setzt sich bis zum Tod und darüber hinaus fort. Viele Vorgänge im täglichen Leben werden ebenso erfasst und verarbeitet: Gehaltszahlungen, Geldabhebungen, Lebensmittelkäufe, Reklamationen, Anfragen und Interaktionen im Internet. Der Zweck all dieser Datenerfassungen ist nicht immer klar, aber zumindest privatwirtschaftliche Organisationen sehen darin einen ökonomischen Sinn. Die erfassten Daten werden gespeichert und sofort oder später verarbeitet und ggf. an Dritte veräußert. Zur Beschreibung dieser Entwicklung hin zu immer stärker daten- bzw. informationsgetriebenen Strukturen sowie der integralen Rolle von IT für neue Geschäftsmodelle (s. Abschn. 2.4 und 7.3) hat sich (neben seiner ursprünglichen Bedeutung als Umwandlung analoger Signale)

1.1 Bedeutung von Informationssystemen in Organisationen

5

der Begriff der Digitalisierung (s. Abschn. 5.1) im Sinne einer organisationalen und gesellschaftlichen Transformation etabliert. Zwei kurze Fälle sollen die Rolle von IS in Organisationen beispielhaft illustrieren: Online oder Filiale?

Die norwegische Großbank DNB hat ihr Geschäft innerhalb von zwei Jahren digitalisiert. In 2015 haben ihre Kunden ihr Angebot 156 Millionen Mal über das Handy und 91 Millionen Mal im stationären Internet genutzt. Einen Sparplan haben 80 % von ihnen online abgeschlossen. Die Geschäftskunden nehmen die digitalen Kanäle genauso an. 90 Prozent der neu gewonnenen Geschäftskunden kamen zur Bank über das Internet. Das alles hatte natürlich Auswirkungen auf das Geschäftsaufkommen in den 116 Filialen. Von 2013 bis 2015 wurden dort 82 % weniger Dienstleistungen erbracht. Die Bank verändert folglich ihre Organisationsstruktur. Die Zahl der Filialen für Privatkunden sinkt bis Ende Juni 2016 von 116 auf 57 und für Geschäftskunden von 63 auf 46. Nach einem Abbau von 200 Filialmitarbeitern in 2015 sollen weitere 600 wegfallen, wenn auch möglichst ohne Kündigungen. Der Verband BITKOM hat zu diesem Thema Manager in deutschen Banken befragt. Die Mehrheit erwartet auch für Deutschland einen starken Rückgang der Zahl der Filialen. Das Filialsterben fand schon in den letzten Jahren statt. (In Anlehnung an http://fazjob.net/, 07.02.2016, Martin Gropp, Abgerufen am 29.2.2016) Der Fall zeigt, wie schnell mit Hilfe von IS leistungsfähige Vertriebswege für Dienstleistungen angeboten werden können, was zu großen Ersparnissen führen kann. Dabei kann das Leistungsangebot sogar verbessert werden (z. B. 24 Stunden Zugang zu Dienstleistungen). Das verändert die Beziehung zum Kunden, aber auch die Organisation des Unternehmens selbst. Wenn IS zur Verbesserung des Leistungsangebots bei gleichzeitigen Ersparnissen genutzt werden können, stellt sich die Frage, warum nicht alle Organisationen dieses Potenzial realisieren. Der nächste Fall zeigt, dass die Nutzung der Potenziale von IT keineswegs einfach ist. Zu spät, zu teuer

Die Kreditanstalt für Wiederaufbau (KfW) wollte eine neue einheitliche IT-Architektur einführen. Diese sollte verschiedene Systeme in eine Struktur mit einer gemeinsamen Datenbasis überführen. Diese sollte auch für die vorgeschriebene Übermittlung der Daten über Eigenmittel und Liquidität an BaFin verwendet werden. Das Projekt sollte 400 Millionen Euro kosten. Das Projekt erfuhr jedoch Schwierigkeiten. Allein der für die Finanzbuchhaltung vorgesehene Teil der Software sollte 180 Millionen Euro statt der geplanten 90 Millionen Euro kosten. Der Zeitplan war auch nicht zu halten. Die automatisierte Übermittlung der Daten an BaFin wurde von 2015 auf 2017 verschoben. Die IT-Chefin der KfW kam unter Bedrängnis. Doch die KfW stand mit ihren P ­ roblemen nicht allein. Der Handelskonzern Otto gab sein großes IT-Projekt zur Einführung einer Standardsoftware in 2012 nach drei Jahren ganz auf. (In Anlehnung an Finance Magazin, 04.08.2014, Sabine Reifenberger)

6

1  Bedeutung von Informationssystemen und grundlegende Begriffe

Die Komplexität der Aufgaben wird offenbar oft falsch eingeschätzt, was zu großen Zeitverzögerungen und Kostenüberschreitungen führen kann. Misserfolge werden zwar seltener als Erfolge publiziert, aber sie sind nicht selten. Nicht nur die Entwicklung neuer Software, sondern auch die Einführung und Anpassung bereits vielfach eingesetzter Standardsoftware kann misslingen. Im Frühjahr 2013 wurde das Projekt zur Einführung eines Systems für Gehaltszahlungen aller Bediensteten des Staates Kalifornien nach ca. 10 Jahren und Ausgaben in Höhe von über 370 Millionen Dollar ohne Aussicht auf Erfolg eingestellt (Sweeny und Korber 2013). Nach einem ersten Kollaps im Projekt wurde die erste, namhafte Beratungsfirma durch den Hersteller der Standardsoftware ersetzt, die von Anfang an implementiert werden sollte. Viele einzelne Probleme sind im Nachhinein bekannt geworden. So wurde z. B. erst nach mehr als acht Projektjahren festgestellt, dass die wichtige Frage nach der Zuständigkeit für die Datenmigration zum neuen System nicht geklärt worden war. Für private Organisationen können Probleme mit IS existenzbedrohend sein. Am 01.08.2012 führte die fehlerhafte Installation eines Programms zum Computerhandel von Aktien der Firma Knight Capital innerhalb von 45 Minuten zu einem Verlust für die Firma in Höhe von 440 Millionen Dollar (Spiegel 2012). Der Wert der Aktie der Firma fiel in zwei Tagen um 75 %. Die Firma musste sich am Ende des gleichen Jahres übernehmen lassen, da sie allein nicht mehr überleben konnte. Dieses Buch soll einführend die Potenziale der IS aufzeigen, aber auch die Risiken ihres Einsatzes deutlich machen. In den folgenden Abschnitten werden die Begriffe Information, Kommunikation, Wissen, Modell und System betrachtet, um darauf basierend den Begriff IS besser erläutern zu können.

1.2

Information und Wissen

Im täglichen Sprachgebrauch werden die Begriffe Informationen, Daten und Nachrichten oft synonym verwendet. Wir benötigen jedoch ein genaueres Verständnis dieser Begriffe, da aus der Sicht der Wirtschaftsinformatik zwischen Daten bzw. Nachrichten und Informationen zu unterscheiden ist. Schließlich ist auch der Bezug zwischen Information und Wissen zu klären, die zwar nicht als Synonyme angesehen werden, aber deren Beziehung oft unklar bleibt. Die als klassisch zu bezeichnende Definition des Begriffs Information von Wittmann lautet: Information ist zweckorientiertes Wissen. Demnach wäre Information eine Teilmenge von Wissen. Hier soll Information als Bewegungsgröße und Wissen als Bestandsgröße aufgefasst werden, sodass Information als Wissenszuwachs anzusehen ist. Wir definieren deswegen in Anlehnung an (Wessling 1991): cc Information  Information ist zusätzliches zweckorientiertes Wissen.

1.2 Information und Wissen

7

Ob etwas für eine Person eine Information darstellt, hängt also vom Wissensstand dieser Person ab. Die Antwort kann nur in einem konkreten Kontext gegeben werden. Ein einfaches Beispiel soll die Kontextabhängigkeit von Informationen verdeutlichen. Daten oder Information?

Die Wettervorhersage für den kommenden Sommer in Kanada stellt für die meisten Europäer Daten, aber keine Informationen dar. Wenn aber der Empfänger dieser Vorhersage ein Kapitalanleger ist, der mit Terminkontrakten für Weizen handelt, ist das eine wichtige Information, für die der Kapitalanleger vielleicht viel zahlen würde. Auch jemand, der seinen nächsten Sommerurlaub in Kanada verbringen möchte, wird die Vorhersage schätzen, obwohl er für diese Information wahrscheinlich nicht so viel wie der erwähnte Kapitalanleger zahlen würde. Ob und wie viel jemand für diese Information zahlen würde, hängt auch davon ab, für wie zuverlässig er die Information hält. Der Übergang von Information zu Wissen ist ein wechselseitiger Prozess. Auf der einen Seite entsteht per Definition für den Empfänger einer Information Wissen, sofern er die Information akzeptiert. Auf der anderen Seite werden aber Informationen aus Wissen erzeugt. Kuhlen (2013) bezeichnet den ersten Transformationsprozess als „Informationsverwaltung“ und den zweiten als „Informationserarbeitung“. Diese Sichtweise entspricht der hier vertretenen Auffassung über den Zusammenhang von Information und Wissen. Wir folgen also nicht der vereinfachenden Sicht, die Wissen als die nächste, qualitativ höhere Ebene von Informationen versteht, die durch Vernetzung von Informationen entsteht, und evtl. von weiteren „höheren“ Zuständen wie z. B. Kompetenz oder Intuition gefolgt wird. Wissen entsteht zwar oft aus expliziter Verknüpfung von Informationen, aber auch einzelne Informationen führen zu Wissen. Wissen und Information stellen eher unterschiedliche Zustände der gleichen Substanz dar oder, in Kuhlens Worten (2013, S. 4): „Information ist Wissen in Aktion.“ Die Darstellung von Informationen bezeichnet man als Daten. In Computern werden Daten binär kodiert, sie können aber auch auf Papier gedruckt sein oder auf verschiedenen anderen Medien gespeichert werden. Zwischen Daten und Informationen besteht eine ähnliche Beziehung wie zwischen Information und Wissen. Daher kann man die gegenseitigen Beziehungen wie in Abb. 1.1 darstellen. Informationsverwaltung (s. o.) entspricht in der Abbildung dem Begriff Verwaltung, während Informationserarbeitung als Integration bezeichnet wird. Wenn Daten übermittelt werden, bezeichnet man sie als Nachrichten, unabhängig davon, ob sie durch Personen, über Leitungen oder drahtlos übermittelt werden. Darauf basierend können wir Kommunikation wie folgt definieren: cc Kommunikation  Kommunikation ist Austausch von Nachrichten.

8

1  Bedeutung von Informationssystemen und grundlegende Begriffe

Erlebnisstrom (Handeln) Wahrnehmung

Datum

Ordnung

Gestaltung

Information

Unterscheidung

Be-Deutung

Wissen

Integration (Sinn)

Reflexion (Denken) Abb. 1.1  Übergänge zwischen Daten, Information und Wissen (Derboven et al. 1999, S. 17)

Die obige Definition von Information ist nicht leicht quantifizierbar. Eine formale und direkt quantifizierbare Definition des Begriffs Information geht auf (Shannon und Weaver 1949) zurück. Sie sehen Information als Mittel zur Reduktion von Unsicherheit und messen dieses Reduktionspotenzial mit der Entropiefunktion, hier mit H bezeichnet: n

H = −∑ p i log 2 p i ,

i =1 wobei pi die Wahrscheinlichkeit eines Ereignisses ist. Je höher der Wert von H ist, desto größer sind die Unsicherheit und damit die Möglichkeit, mithilfe von Informationen die Unsicherheit zu reduzieren. Wenn keine Unsicherheit besteht, also ein Ereignis mit Sicherheit von pi = 1 auftritt, dann ist H = 0 bzw. zusätzliche Informationen haben keinen Wert. Dieser Ansatz hat sich in der Kommunikationstheorie bei der Analyse von Verschlüsselungsverfahren bewährt. Die Entropiefunktion spielt auch in einigen Verfahren des Data Mining (s. Abschn. 2.3.3.4) eine wichtige Rolle. Für die Ermittlung des ökonomischen Werts einer Information ist der Ansatz jedoch nicht geeignet, da die Entscheidungsrelevanz der Information außer Acht gelassen wird. Deswegen müssen wir uns um die Quantifizierung des Werts von Informationen, insbesondere im Sinne eines ökonomischen Werts, noch bemühen. Das geschieht im Abschn. 1.4. Eine Information kann viele Eigenschaften haben, die ihren Wert beeinflussen. Einige dieser Attribute sind nachfolgend beschrieben. Aktualität bezieht sich auf die Frage, wie weit in der Zeit der Zustand zurückliegt, auf den sich die Information bezieht. Wenn sich z.  B. zwei Informationen auf den bisher

1.3 Problemlösen

9

Tab. 1.1  Informationsattribute und ihre möglichen Ausprägungen dargestellt am Beispiel der Information „Umsatz“ Attribut

Mögliche Ausprägungen

Aktualität

Letzter Monat

Version

Letzte 12 Monate

Letztes Jahr

Ist

Seit Anfang des Jahres Plan

Organisationsebene

Produkt

Produktgruppe

Geschäftsbereich

Konzern

Genauigkeit

In € mit allen Nachkommastellen

In € und ganzen Cents

In ganzen €

In 1.000€

e­ rzielten Jahresumsatz eines Produkts beziehen, dann ist die Information mit dem jüngeren Datum die aktuellere. Korrektheit bezieht sich auf den Wahrheitsgehalt der Information. Genauigkeit bezieht sich auf die Präzision der Information. Im Prinzip wünscht man sich immer genaue Informationen, denn eine ungenaue Information könnte zu schlechten oder sogar falschen Entscheidungen führen. Vollkommen genaue Informationen sind aber oft nicht erhältlich (z. B. bei zukunftsbezogenen Informationen), zu teuer oder aber nicht notwendig (z. B. Centbeträge). Der Aggregationsgrad von Informationen sagt etwas über die Bezugsobjekte oder -ereignisse aus. Bei „Umsatzzahlen“ kann das Bezugsobjekt Unternehmen, Geschäftsbereich, Produktgruppe, Region und vieles andere sein. Oft besteht eine Hierarchie von Objekten, entlang derer Informationen sinnvoll zusammengefasst werden können. Die Präsentation einer Information ist ebenso wichtig, da die volle Ausschöpfung des Informationswerts davon abhängt, dass der Empfänger die Information vollständig aufnimmt. Daher wurde die Eignung unterschiedlicher Präsentationsformen von Informationen in IS frühzeitig untersucht (z. B. Tabellen versus Grafiken, Nutzung von Farben, Anzahl von Bildschirmfenstern). Die Kosten einer Information sind insbesondere bei ex ante Betrachtungen wichtig, wenn über die Beschaffung der Information entschieden werden muss. Man kann weitere Attribute nennen (z. B. Herkunft der Information oder Nutzungshäufigkeit) oder die genannten Attribute weiter aufgliedern. Wir verzichten darauf, weil die geeignete Dimensionierung, d. h. die Wahl der zu betrachtenden Attribute, wiederum vom jeweiligen Kontext bzw. Informationszweck abhängt und dies den Umfang des vorliegenden Buches übersteigen würde. Tab.  1.1 enthält als Beispiel einige Attribute und deren Ausprägungen der Information „Umsatz“.

1.3

Problemlösen

Bevor wir zur Bestimmung des Werts einer Information kommen, wollen wir den Prozess untersuchen, in dem Informationen verwendet werden. Generell werden Informationen benötigt, um eine Entscheidung zu treffen oder eine Kontrolle vorzunehmen. Informationen sind als Rohstoff für Entscheidungs- und Kontrollprozesse zu betrachten.

10

1  Bedeutung von Informationssystemen und grundlegende Begriffe

Entscheidung i. e. S. bedeutet die Auswahl einer von mindestens zwei Handlungsalternativen. Eine der beiden Handlungsalternativen kann im Nichtstun bestehen (Unterlassensalternative). Der Problemlösungs- bzw. Entscheidungsprozess wird in Phasen unterteilt, wobei das am häufigsten zitierte Phasenmodell auf (Simon 1957) zurückgeht. Das Modell kennt die Phasen: Problemerkennung, Alternativengenerierung und Alternativenauswahl. In der ersten Phase wird untersucht, ob eine Diskrepanz zwischen dem wahrgenommenen Ist-­Zustand und dem angestrebten Soll-Zustand vorliegt. Wenn das der Fall ist, liegt ein Problem vor. Da eine frühe Erkennung eines Problems in vielen Fällen eine Voraussetzung für die rechtzeitige Lösung ist, kommt dieser Phase eine zentrale Bedeutung zu. Wie wir später sehen, werden manche IS speziell für diese Phase entwickelt. Wenn ein Problem erkannt wurde, können Lösungsalternativen entwickelt werden. Schließlich wird in der dritten Phase aufgrund von gegebenen Kriterien eine dieser generierten Alternativen ausgewählt. In der Praxis nutzt eine Entscheidung nur etwas, wenn sie implementiert wird. Anschließend ist zu kontrollieren, inwieweit die mit der Entscheidung verfolgten Ziele auch erreicht wurden. Deswegen muss der Entscheidungs- bzw. Problemlösungsprozess durch die Phasen Implementierung und Kontrolle vervollständigt werden. Aus Abb. 1.2 geht hervor, dass Phasen mehrfach wiederholt werden können. So liefert die Phase der Kontrolle Informationen für die Problemerkennung, sodass der Prozess des Problemlösens beim Auftreten signifikanter Differenzen sofort wieder angestoßen werden kann. Dies ist durch den Pfeil angedeutet, der von der Kontrolle zur Problemerkennung führt. Der Lösungsprozess gestaltet sich nicht notwendig linear von Phase zu Phase. Wie die Pfeile es andeuten, kann der Entscheider bei Bedarf zu früheren Phasen zurückkehren, um einen neuen Problemlösungsanlauf zu nehmen. Wenn ein Entscheider etwa beim Vergleich der Alternativen in der Auswahlphase mit keiner der betrachteten Alternativen z­ ufrieden ist, kann er zur Generierung von Alternativen zurückgehen, um neue und hoffentlich bessere Alternativen zu entwickeln. Abb. 1.2 Problemlösungsphasen

1.3 Problemlösen

11

Die zu treffenden Entscheidungen bzw. die zu lösenden Probleme können nach dem Grad ihrer Strukturiertheit mithilfe der soeben beschriebenen Phasen klassifiziert werden. Wenn ein Entscheidungsträger hinsichtlich eines Problems zu jeder der Phasen ein geeignetes Vorgehen kennt, ist das Problem für ihn wohlstrukturiert. In einem solchen Fall ist es oft möglich, das Problemlösen so zu automatisieren, dass eine Lösungsvorschrift festgelegt wird, die auch von einem anderen menschlichen oder maschinellen Aufgabenträger befolgt werden kann. Im anderen Extremfall, wenn zu keiner der Phasen ein geeignetes Vorgehen bekannt ist, wird das Problem als unstrukturiert bezeichnet. Die Bestimmung des Strukturierungsgrads ist offensichtlich subjektiv. Die Verwendung von vielen Klassen zwischen den genannten Extremen ist daher nicht sinnvoll. Deswegen findet sich in der Literatur meist nur eine weitere Klasse: die der semistrukturierten (oder teilstrukturierten) Probleme. Wie die Bezeichnung andeutet, sind hier Lösungsansätze zwar für einige der Phasen, aber nicht für alle Phasen bekannt. In der Entscheidungstheorie wird zwischen Entscheidungen unter Sicherheit und unter Unsicherheit unterschieden. Im ersten Fall liegen sämtliche Prognosedaten über die Entscheidungskonsequenzen der zu beurteilenden Alternativen in einwertiger Form vor. Bei Entscheidungen unter Unsicherheit werden die Konsequenzen mehrwertig notiert. Mehrwertigkeit liegt z.  B. dann vor, wenn die Vorhersagen für verschiedene Szenarien getroffen werden. Häufig werden dem Eintritt der Szenarien subjektiv geschätzte Wahrscheinlichkeiten zugeordnet. Bei derartig strukturierten Entscheidungssituationen unter Unsicherheit können für die betrachteten Entscheidungsalternativen nicht nur Erwartungswerte, sondern auch Risiken und Chancen quantifiziert werden. Die standardisierte Bemessung kann z. B. mit der Standardabweichung vorgenommen werden. Der angestrebte Zielerreichungsgrad des Entscheidungsträgers ist ein weiterer wichtiger Aspekt. Nach dem Prinzip des rationalen Entscheidungsverhaltens sucht er grundsätzlich nach der besten Alternative, also nach einer optimalen Lösung. Simon (1957) hat hingegen aufgrund von Beobachtungen festgestellt, dass Entscheidungsträger oft auch eine zufriedenstellende Lösung akzeptieren. Das kann z. B. daran liegen, dass sie einfach nicht imstande sind, die beste Alternative herauszufinden, oder dass sie nicht nach besseren Alternativen suchen wollen, sobald ein bestimmter Zielerfüllungsgrad erreicht ist. Die Persönlichkeit des Entscheidungsträgers drückt sich auch in seiner Risikoeinstellung aus. Diese kann aufgrund des Nutzenerwartungswerts bei einem zufallsbedingten Ereignis bestimmt werden: n



E ( X ) = ∑ pi N ( x i ) i =1



12

1  Bedeutung von Informationssystemen und grundlegende Begriffe

Tab. 1.2  Dimensionen des Entscheidens Dimension

Ausprägung

Problemstruktur

Wohlstrukturiert

Semistrukturiert

Zielerreichung

Optimal

Zufriedenstellend

Entscheider

Risikoscheu

Risikoneutral

Sicherheitsgrad

Sicherheit

Unsicherheit

Unstrukturiert

Risikofreudig

wobei pi die Eintrittswahrscheinlichkeit des Ereignisses xi ist und N(xi) der Nutzen, den der Entscheidungsträger dem Eintreten des Ereignisses xi beimisst. Dieses Ereignis kann z.  B. der Geldertrag einer Investition sein. Der Nutzenerwartungswert kann mit einem ­sicheren Wert verglichen werden, dem sog. Sicherheitsäquivalent (Bamberg et al. 2008), den der Entscheider auswählt bzw. bei einem Glücksspiel als Spieleinsatz akzeptiert. Wenn die beiden Werte gleich sind und der Entscheider keine der beiden Alternativen bevorzugt, dann wird der Entscheider als risikoneutral bezeichnet. Wenn sich der Entscheider für ein ihm angebotenes Sicherheitsäquivalent entscheidet, das kleiner als der Nutzenerwartungswert ist, dann ist der Entscheider risikoscheu; wenn er sich für den (höheren) Nutzenerwartungswert entscheidet, ist er risikofreudig. Im letzteren Fall zieht er die Chance auf den Erhalt eines größeren Nutzens einem sicheren, kleineren Nutzen vor. Die Risikoeinstellung eines Menschen ist nicht immer die gleiche, sondern fallabhängig. Erschwerend kommt hinzu, dass Menschen leicht Fehleinschätzungen unterliegen. Sie entscheiden z. B. in einer objektiv identischen Situation bei lediglich unterschiedlichen Problemformulierungen ganz unterschiedlich (Kahneman und Tversky 1979). Alle diese Aspekte des Entscheidens unterstreichen die Komplexität des Prozesses, in den Informationen eingehen und der den Kontext zur Evaluierung von Informationen darstellt. Sie sind in Tab. 1.2 zusammenfassend dargestellt.

1.4

Wert von Informationen

Nun können wir uns der Wertbestimmung von Informationen zuwenden (Ahituv und Neumann 1994). Der methodisch einfachste Ansatz ist die subjektive Bestimmung des Werts. Hier befragt man den Informationsbenutzer, wie viel ihm die Information wert ist. Dieser Ansatz wird insbesondere dann gewählt, wenn es sich um unstrukturierte Probleme unter Unsicherheit handelt. Seine Stärke, die nachfragebezogene Wertbestimmung, ist ­gleichzeitig auch seine Schwäche, nämlich die mangelnde Nachprüfbarkeit der Korrektheit. Es ist möglich, den Grad der Subjektivität zu verringern, indem mehrere Benutzer in einer Organisation befragt und die Antworten in geeigneter Weise zusammengefasst werden. Hier besteht die Hoffnung, dass mehrere Personen den Wert besser einschätzen können als eine einzelne, wofür es aber keine Garantie gibt. Ein objektiver Ansatz ist die Ermittlung des beobachtbaren Werts von Informationen. Dabei wird das Ergebnis eines Entscheidungsprozesses mit und ohne eine

13

1.4 Wert von Informationen

b­ estimmte Information betrachtet. Die Ergebnisdifferenz entspricht dem Informationswert, wenn man alle anderen Einflüsse konstant halten kann. In dieser Bedingung verbirgt sich die Schwierigkeit des Ansatzes. In einer experimentellen Umgebung können wir andere Einflüsse gut kontrollieren. In der Praxis aber werden wir eine Vielzahl von Daten und komplexe Methoden benötigen, um die genauen Anteile der Ergebnisdifferenz der betrachteten Information zuordnen zu können. Der Vorteil des Ansatzes besteht darin, dass er die tatsächlich erreichten Ergebnisse berücksichtigt und damit die Fähigkeiten und Zielerreichungsbedürfnisse der Entscheidungsträger. Ein Nachteil ist, dass der Wert nur ex post ermittelt werden kann, wenn man die Information schon erworben hat. Die Wertermittlung kann jedoch auch für diesen Fall sinnvoll sein, um für den Wiederholungsfall zu lernen. Ein ebenfalls objektiver Ansatz, der auch ex ante angewendet werden kann, ist die Bestimmung des normativen Werts der Information. Hier wird der Informationswert durch die Differenz des erwarteten Gewinns mit der betreffenden Information und dem erwarteten Gewinn ohne die Information gemessen. Die Information führt i.  d.  R. zu einer Revision der ursprünglichen (a priori) Wahrscheinlichkeiten für die Umweltzustände unter Anwendung des Bayes-Theorems. Ein stark vereinfachtes Beispiel soll den Ansatz verdeutlichen. Normativer Informationswert

Ein Unternehmen erwägt die Einführung eines neuen Produkts. Der mit der Planung beauftragte Produktmanager schätzt, dass Einnahmen von 1.000.000 € erzielt werden können, wenn „ausreichender“ Bedarf (aB) nach dem Produkt besteht. Wenn ein solcher Bedarf nicht existiert (kaB), werden die Einnahmen aufgrund von Produktentsorgung und -aufgabe mit Null geschätzt. Herstellungs- und Produkteinführungskosten werden mit 300.000 € kalkuliert. Die Wahrscheinlichkeit, dass ein ausreichender Bedarf besteht, schätzt der Produktmanager aufgrund seiner Erfahrungen mit 60 % ein. Der aufgrund dieser Zahlen errechnete, erwartete Gewinn der Produkteinführung beträgt:

(1.000.000 − 300.000 )

∗



0, 6 + ( −300.000 ) 0, 4 = 300.000 ∗

Um seine Einschätzungen über den Bedarf überprüfen zu lassen, bittet der Manager ein Marktforschungsunternehmen um ein Angebot für eine entsprechende Marktuntersuchung. Die Marktforscher bieten eine Untersuchung an, die u. a. einen Feldversuch und die Durchführung von Fokusgruppen beinhaltet. Da die Untersuchung mit Stichproben arbeitet bzw. potenzielle Käufer nur nach Kaufabsichten befragt, kann sie keine 100 % sicheren Ergebnisse liefern. Das Marktforschungsinstitut beschreibt die Güte der Untersuchung (U) wie folgt: Wenn ein ausreichender Bedarf nach dem Produkt tatsächlich besteht, wird es deren Studie mit einer Wahrscheinlichkeit von P(UaB|aB) = 90 % ermitteln. Gleiches gilt für den Fall, dass kein ausreichender Bedarf besteht. In beiden Fällen wird mit der jeweiligen Restwahrscheinlichkeit von 10 % ein falsches Ergebnis angezeigt (z. B., dass kein ausreichender Bedarf bestünde (UkaB), obwohl er tatsächlich besteht). Die beschriebenen quantitativen Eigenschaften der Untersuchung lassen sich wie in nachfolgender Tabelle darstellen:

14

1  Bedeutung von Informationssystemen und grundlegende Begriffe Untersuchung ergibt

Dann

UaB

UkaB

aB

0,90

0,10

kaB

0,10

0,90

Wenn

In der Realität gilt

(zu Bezeichnungen s. Text)

Mit diesen Angaben kann der Produktmanager mithilfe des Theorems von Bayes errechnen, wie viel die vom Marktforschungsinstitut angebotene Information wert ist, wenn entsprechend der Empfehlung der Studie auch gehandelt wird. Die (a posteriori) Wahrscheinlichkeit, dass ausreichender Bedarf vorliegt, wenn dies durch die Untersuchung angezeigt wird, beträgt

(

)

P ( aB| UaB) = P ( UaB|aB) P ( aB) / P ( Uab ) = 0, 9∗ 0, 6 / 0,9∗ 0,6 + 0,1∗ 0,4 = 0, 93. ∗



Die Wahrscheinlichkeit, dass kein ausreichender Bedarf trotz eines gegenteiligen Untersuchungsergebnisses vorliegt, beträgt P(kaB|UaB) = 1 − P(aB|UaB) = 0,07 (das lässt sich auch nach der Bayesschen Formel berechnen). Untersuchung ergibt

Wenn

UaB

UkaB

aB

0,930

0,143

kaB

0,070

0,857

Dann

Realität

(zu Bezeichnungen s. Text)

Die Wahrscheinlichkeit für ein „positives“ Untersuchungsergebnis (dass Bedarf besteht) entspricht dem Ausdruck im Nenner der obigen Formel, also P(UaB) = 0,58. Die Wahrscheinlichkeit für ein negatives Untersuchungsergebnis ist dann

1.5 System und Modell

15

P ( UkaB) = 1 – 0, 58 = 0, 42.



Wir nehmen zunächst an, dass der Preis der Untersuchung 0 beträgt, um auszurechnen, wie viel die Information (Untersuchung) maximal wert ist. Wenn das Untersuchungsergebnis positiv ist, beträgt der erwartete Gewinn 0,93 * 700.000 + 0,07 * (−300.000) = 630.000. Wenn das Untersuchungsergebnis negativ ist, wird das Produkt nicht eingeführt und der erwartete Gewinn ist 0. Damit errechnet sich der erwartete Gewinn bei erfolgter Marktuntersuchung als 0, 58∗ 630.000 + 0, 42∗ 0 = 365.400.



Die Differenz zwischen dem Erwartungswert ohne die Information (300.000) und dem Erwartungswert mit der Information (365.400) entspricht dem Wert der I­nformation nach diesem Ansatz. Wenn also die Marktforscher für die Untersuchung weniger als 65.400 € fordern, „lohnt“ es sich, die Information zu beschaffen. Der Nachteil dieses Verfahrens ist, dass die Güte der Information, im obigen Beispiel der Marktforschungsuntersuchung, nicht leicht bestimmbar und nachprüfbar ist. Wenn man die Wahrscheinlichkeiten hier als Erfahrungswerte (empirische Häufigkeiten) interpretiert, so bedarf es zunächst vieler früherer, gleichartiger Fälle. Beides ist je seltener gegeben, desto neuer das Problem bzw. neuartiger die benötigte Information ist. In der Praxis wird der Wert einer Information oft nicht im Kontext von „mit“ oder „ohne“ Information ermittelt, sondern es werden Informationen mit unterschiedlichen Ausprägungen eines oder mehrerer Attribute (s. Abschn. 1.2) betrachtet, um eine zufriedenstellende Konstellation auszuwählen. Abschließend ist festzuhalten, dass das Ergebnis eines Entscheidungsprozesses, in den Informationen eingeflossen sind, wiederum eine Information darstellt.

1.5

System und Modell

Das zweite Wort, das in IS konstituierend mitwirkt, ist System. Es wird täglich in vielen Zusammenhängen verwendet und kann wie folgt definiert worden. cc System  Ein System besteht aus einer Menge von miteinander verknüpften Elementen, die sich insgesamt von ihrer Umgebung abgrenzen lassen. Abb. 1.3 stellt die Definition bildlich dar. Die Grafik enthält zusätzlich Eingaben (Inputs) und Ausgaben (Outputs), die das System mit der Umwelt austauscht. Diese sind in der Definition nicht enthalten, weil es geschlossene Systeme gibt, die mit ihrer Umwelt nichts austauschen. Die Ermittlung der Grenzen eines Systems und der Beziehungen zwischen seinen Elementen können schwierig sein. Wenn man an den Elementen und ihren Beziehungen nicht

16

1  Bedeutung von Informationssystemen und grundlegende Begriffe

Umwelt

Input

Grenze

Output

Abb. 1.3  Ein System und seine Umwelt

interessiert ist, sondern nur an der Verwendung eines Systems, dann bezeichnet man das System als eine „Blackbox“. Es reicht oft aus zu wissen, welche Inputs zu welchen Outputs führen, um ein System zu nutzen. Ein Element eines Systems kann ebenfalls ein System sein (es wird dann auch als Subsystem bezeichnet), sodass sich zusätzlich die Frage nach dem geeigneten Detaillierungsgrad der Betrachtung stellt. Die Konstruktion eines konkreten Systems hängt vom beabsichtigten Zweck ab. Generell kann gesagt werden, dass das Denken in Systemen als ein analytisches Konzept verstanden werden kann. Systeme können im Hinblick auf ihre Entstehung natürlich sein (z. B. Mensch, Erde). Künstliche Systeme sind von Menschen geschaffen worden (z. B. Computer, Auto). Die Elemente eines Systems können natürlich, maschinell oder gemischt sein. Ein System kann konkret existieren oder nur ein abstraktes Gedankenkonstrukt darstellen, wie es etwa die Zahlensysteme sind. Ein System, dessen Verhalten exakt voraussagbar ist, wird als deterministisch bezeichnet. Wenn das Verhalten (nur) einer Komponente eines Systems einer Wahrscheinlichkeitsverteilung folgt (z. B. bezüglich ihres Ausfalls), so ist das gesamte System stochastisch. Wenn ein Beobachter nicht einmal Wahrscheinlichkeiten für das Verhalten eines Systems kennt, verhält sich das System für ihn zufällig (z. B. (Ahituv und Neumann 1994)). Ein adaptives System reagiert auf Veränderungen der Umwelt oder seiner Komponenten, sodass es sich selbst oder, wenn möglich und sinnvoll, die Umwelt der neuen Situation anpasst. Ein nicht-adaptives System reagiert auf solche Veränderungen nicht, was i. d. R. zu Nachteilen für das System führt. In vielen Organisationen werden die realisierten Ergebnisse regelmäßig mit angestrebten Zielen verglichen. Wenn die Übereinstimmung als nicht zufriedenstellend angesehen wird, werden die Systemeingaben und/oder das interne Systemverhalten geändert. Man spricht hier von Rückkopplung. Die Klassifikation der Systeme könnte weiter fortgesetzt werden, auch könnten die genannten Kategorien weiter verfeinert werden – aber die aufgeführten Kriterien und ihre

1.5 System und Modell

17

Tab. 1.3 Systemklassifikationen Kriterium

Ausprägung

Entstehung

Natürlich

Künstlich

Komponenten

Maschinell

Natürlich

Existenz

Abstrakt

Konkret

Umweltinteraktion

Offen

Geschlossen

Verhalten

Deterministisch

Stochastisch

Anpassung

Adaptiv

Nicht-adaptiv

Steuerung

Mit

Ohne Rückkopplung

Maschinell und natürlich

Zufällig

Kombinationen reichen schon aus, um Systeme nach ihren wichtigsten Dimensionen untersuchen zu können. Tab. 1.3 gibt die besprochenen Klassifikationskriterien und -ausprägungen zusammenfassend wieder. In vielen Fällen arbeitet man nicht direkt mit einem System, sondern mit einer Abbildung dieses Systems, die wir als Modell bezeichnen. Wir definieren Modell nach (vom Brocke 2003, S. 19 ff.): cc Modell  Ein Modell ist das Ergebnis eines Konstruktionsprozesses, das die Wahrnehmung von Inhalten eines ausgewählten Gegenstands zweckorientiert repräsentiert. In der Wirtschaftsinformatik wird aufgrund der systemgestaltenden Ausrichtung eine Konzentration auf Modelle vorgenommen, die Informationssysteme (allgemeiner: Systeme) zum Gegenstand haben. In Modellen werden die für nicht relevant angesehenen Eigenschaften eines Systems weggelassen. Mit einem Modell kann somit einfacher experimentiert werden, um das zu analysierende System bzw. das Original besser verstehen bzw. steuern zu können, ohne dieses selbst zu beeinflussen. Das Modell kann ein dimensionsgerechtes, physisches Replikat des Systems sein (z. B. ein Spielzeugauto). Andere Modelle repräsentieren wiederum das System nur analog, indem eine Größe eine andere symbolisch darstellt (z. B. eine geografische Karte, in der Blautöne unterschiedliche Wassertiefen und Brauntöne unterschiedliche Gebirgshöhen andeuten). Bei der Betrachtung von Unternehmen spielen mathematische Modelle eine große Rolle. Hier werden z. B. Leistungs- und Zahlungsfolgen quantitativ dargestellt und durch Formeln miteinander in Verbindung gebracht. Ein solches Modell ist abstrakter als die beiden vorher genannten Modellarten. Der Zweck eines Modells kann sein, ein System zu beschreiben (deskriptiv) oder Handlungen zu empfehlen (normativ). Die Qualität des Modells ist daran zu beurteilen, inwiefern die Repräsentation geeignet ist, die Zwecke des Modellnutzers zu erfüllen. Zur

18

1  Bedeutung von Informationssystemen und grundlegende Begriffe

Tab. 1.4 Modellklassifikationen Kriterium

Ausprägung

Abstraktionsgrad

Physisch

Analog

Zweck

Normativ

Deskriptiv

Zeit

Statisch

Dynamisch

Verhalten

Deterministisch

Stochastisch

Anpassung

Adaptiv

Nicht-adaptiv

Mathematisch

Operationalisierung der Qualität von Modellen wurden Grundsätze ordnungsmäßiger Modellierung (GoM) entwickelt (Becker et al. 1995). Wenn das Modell Größen beinhaltet, die sich auf mehr als einen Zeitpunkt beziehen, wird von einem dynamischen (also mehrperiodigen) Modell gesprochen. In statischen (einperiodigen) Modellen beziehen sich alle Variablen auf den gleichen Zeitpunkt bzw. Zeitraum. Im Hinblick auf Verhalten und Anpassungsfähigkeit können im Prinzip die gleichen Ausprägungen wie bei Systemen unterschieden werden. Die getreue Modellierung eines Systems ist allerdings nicht möglich, wenn sein Verhalten unbekannt ist. Weitere Klassifikation von Modellen ist möglich, aber hier nicht erforderlich. Tab. 1.4 fasst die ausgewählten Modellklassifikationen zusammen. Die planvolle Konstruktion eines Modells kann in Anlehnung an das Bauen als Architektur bezeichnet werden. Noch häufiger wird der Begriff in der Wirtschaftsinformatik jedoch auf das entstehende Gebilde angewandt, insb. die Beziehung der einzelnen Komponenten zueinander (zum Begriff Architektur s. auch Abschn. 6.2). Wie in Teil 2 dieses Buches dargestellt kann es sich dabei um Komponenten von Geschäfts-, Organisationssowie von IS-Modellen handeln.

1.6

Modelle von Unternehmen

1.6.1 Unternehmen als eine Organisation Obwohl wir die konstituierenden Bestandteile des Begriffs IS erläutert haben, wollen wir vor einer Begriffsdefinition noch weitere Begriffe betrachten, die für das Verständnis von IS notwendig sind. IS für wirtschaftswissenschaftliche Aufgaben werden fast ausnahmslos in künstlichen Systemen eingesetzt, wo sie eine bestimmte Funktion als Subsystem ausüben. Dagegen werden in der Medizin IS manchmal auch in natürlichen Systemen eingesetzt. Im Rahmen dieser Einführung interessiert insbesondere der Einsatz von IS in einer Organisation als einem künstlichen, konkreten System. Unter Organisationen gilt unser Augenmerk solchen, die ökonomische Ziele verfolgen, wobei eine Gewinnorientierung

1.6 Modelle von Unternehmen

19

nicht notwendig ist. Wir werden nachfolgend die Begriffe Organisation und Unternehmen synonym verwenden, weil sich sämtliche Beispiele auf Organisationen beziehen, die als Unternehmen organisiert sind. Aus der Sicht der Systemtheorie enthalten Organisationen i. d. R. maschinelle und natürliche Komponenten und sind meistens offene, adaptive Systeme mit Rückkopplung. Da eine Organisation viele Komponenten enthält, ist zwecks Erreichung der Organisationsziele eine Koordination dieser Komponenten notwendig. Diese Koordination wird durch eine Aufbauorganisation, die Aufgaben, Aufgabenträger und ihre formalen Beziehungen untereinander festlegt, und durch eine Ablauforganisation, die Arbeitsabläufe bestimmt, unterstützt (s. auch Abschn. 6.2). Neben diesen formalen Strukturen spielen auch die informellen Strukturen, die sich aus menschlichen Beziehungen ergeben (z. B. Sympathien, Antipathien, Machtstreben, Neid, Drang nach Anerkennung), in der Realität eine große Rolle. Die Entstehung und Veränderung von Organisationsstrukturen im Zeitablauf ist ein komplexer Prozess. Hier sei zunächst nur auf die Komplexität des Umfelds hingewiesen, in dem IS zum Einsatz kommen.

1.6.2 Unternehmensaufgaben In vielen Organisationen herrscht hierarchische Koordination mit einer oder mehreren Leitungsebenen vor. Die Leitungs- oder Managementfunktionen werden oft in drei Ebenen unterteilt (Anthony 1965). Die oberste Ebene stellt das Topmanagement dar, dessen vornehmliche Aufgabe darin besteht, die strategischen Ziele und Pläne für die Organisation festzulegen. Der Planungshorizont dieser Ebene wird als langfristig bezeichnet, was in der Praxis i. d. R. drei bis fünf Jahre bedeutet. Auf der nächsten Ebene, der des mittleren Managements, werden die taktischen Pläne ausgearbeitet, die zur Realisierung der vorher festgelegten Strategien notwendig sind. Der Zeithorizont bewegt sich hier in der Praxis zwischen einem Quartal und drei Jahren. Auf der untersten Leitungsebene, der operativen Ebene, kümmern sich die Manager um das „tägliche Geschäft“, indem sie die Realisierung der taktischen Pläne vorantreiben und überwachen. Die Manager einer Ebene haben Mitarbeiterverantwortung für die unteren Ebenen. Da die zahlenmäßige Besetzung der Ebenen mit Personal von oben nach unten zunimmt, wird die beschriebene Hierarchie oft in Form einer Pyramide dargestellt. In Abb. 1.4 sind die Leitungsebenen um die Ausführungsebene ergänzt, damit das gesamte Unternehmen in dem Modell repräsentiert wird. Die Linien, die die Pyramide vertikal unterteilen, trennen die verschiedenen funktionalen Bereiche, wie etwa Beschaffung, Produktion oder Vertrieb, voneinander ab. Es handelt sich somit zusätzlich um eine funktionsorientierte Aufgabengliederung des Unternehmens. Spezialisten, die oft keine Mitarbeiterverantwortung tragen, aber dennoch wichtige Aufgaben erfüllen und hierdurch hohes Ansehen genießen, werden manchmal als Wissensarbeiter (Knowledge Worker) bezeichnet. Zu ihren Tätigkeiten gehören z. B. Strategieplanung, Marktanalysen und Produktentwicklungen. Diese Experten sind die primären Benutzer einiger der in Abschn. 2.3 beschriebenen IS.

1  Bedeutung von Informationssystemen und grundlegende Begriffe

20

Organisationsebene

Leitungsebenen

strategisch

taktisch

operativ

Ausführungsebene

Beschaffung

...

...

Vertrieb Kundendienst

Funktionale Bereiche

Abb. 1.4  Organisationsebenen eines Unternehmens

Die unterschiedlichen Aufgaben der Manager auf den drei Ebenen führen zu unterschiedlichen Informationsbedürfnissen. Diese werden in Tab. 1.5 dargestellt. Dabei sind die Einträge so zu interpretieren, dass z. B. bezüglich der Herkunft der Informationen die operative Ebene vorwiegend interne Informationen benötigt, die strategische Ebene vorwiegend externe Informationen und die taktische Ebene dazwischen liegt. Mittlerweile hat die stark hierarchisch gestaltete Organisation an Bedeutung verloren, weil es nicht effizient erscheint, dass viele Akteure hauptsächlich nur mit Überwachung und Informationsweitergabe entlang der Leitungsebenen beschäftigt sind. Heute wird versucht, „flache“ Organisationen mit möglichst wenig Personal, das nur überwacht und informiert, zu entwickeln. Die Entwicklung solcher Organisationen unterstützen IS erheblich, da sie es z. B. den Managern erleichtern, mehr Mitarbeiter zu führen, als es ohne sie möglich wäre. Die vorher genannten planerischen Aufgaben existieren trotz Verflachung der Organisation weiter. Die dargestellten Ebenen sind zu abstrakt und generell, um für eine Gruppierung von Mitarbeitern einer großen Organisation als Kriterien dienen zu können. Für diese Zwecke wird eine funktions-, produkt- oder prozessorientierte Darstellung gewählt, wie sie durch die vertikale Unterteilung beispielhaft angedeutet ist. Weiterhin sei daran erinnert, dass eine Organisation als ein System selbst Bestandteil anderer Systeme ist. Eine Organisationsbeziehung, die auf einer bewussten und explizit vereinbarten Zusammenarbeit zwischen Unternehmen basiert, „zwischenbetriebliche Kooperation“ und E-Business wie in Kap.  12 beschrieben, benötigt oft weitere darauf zugeschnittene IS.  Es ist heute aufgrund vielfacher Verknüpfungen zwischen Unternehmen manchmal schwierig, sinnvolle

21

1.6 Modelle von Unternehmen Tab. 1.5  Informationsbedürfnisse der Leistungsebenen Informationsattribut

Operative Ebene

Taktische Ebene

Strategische Ebene

Entstehung Herkunft

Intern

Extern

Berechnung

Einfach

Komplex

Aktualität

Hoch

Niedrig

Verdichtung

Niedrig

Hoch

Zeitl. Ausrichtung

Vergangenheit, Gegenwart

Zukunft, Gegenwart

Genauigkeit

Hoch

Niedrig

Präsentation

Einfach

Aufwendig

Eindeutig

Vage

Inhalt

Darstellung

Nutzung Zweck Häufigkeit

Hoch

Niedrig

Periodizität

Vorbestimmt

Ad hoc

Unternehmensgrenzen zu identifizieren. In diesem Zusammenhang wird auch der Begriff virtuelles Unternehmen verwendet. Unter einem virtuellen Unternehmen wird im Allgemeinen eine Kooperation rechtlich unabhängiger Unternehmen verstanden, die bei der Leistungserstellung Dritten gegenüber als eine Einheit erscheint. Das geeignete Modell eines Unternehmens hängt von der jeweiligen Fragestellung ab. Wenn einzelne betriebliche Prozesse oder Einheiten genau untersucht werden sollen, werden Modelle mit höherem Detaillierungsgrad gebraucht. In die Methoden zu ihrer Modellierung führt Teil 2 ein.

1.6.3 Unternehmen aus ganzheitlicher Sicht Das Handeln eines Unternehmens beeinflusst nicht nur seine Mitarbeiter und seine direkten Geschäftspartner, sondern auch eine Vielzahl an Interessengruppen, mit denen es vielleicht nicht direkt interagiert. Ohne das Verständnis der komplexen Beziehungen, in denen ein Unternehmen steht, lassen sich diese Auswirkungen nicht verstehen und beeinflussen. Das in Abb. 1.5 gezeigte Modell eines Unternehmens aus Führungssicht versucht, die Komplexität seiner Beziehungen durch sechs Grundkategorien einzufangen: • Umweltsphären (Gesellschaft, Natur, Technologie, Wirtschaft) sind Rahmenbedingungen, die ständig auf Veränderungen beobachtet werden sollten und teilweise beeinflusst werden können. • Anspruchsgruppen (Kapitalgeber, Kunden, Mitarbeitende, usw.) stehen in beabsichtigten Austauschprozessen mit dem Unternehmen (s. Abschn.  7.2) oder werden von

22

1  Bedeutung von Informationssystemen und grundlegende Begriffe Gesellschaft Natur Technologie Wirtschaft Kapitalgeber

Konkurrenz

Managementprozesse

Lieferanten

Kunden

Geschäftsprozesse Unterstützungsprozesse

Ressourcen Staat

Normen und Werte Anliegen und Interessen

Mitarbeitende

Öffentlichkeit/ NGOs

Abb. 1.5  St. Galler Management-Modell (Rüegg-Stürm 2003)

seinen Handlungen mehr oder weniger zufällig betroffen (z. B. durch Umweltbelastung). Aus finanzwirtschaftlicher Sicht kommt in börsennotierten Unternehmen den Eigenkapitalgebern (Shareholder) eine dominierende Bedeutung zu. • Interaktionsthemen (Ressourcen, Normen und Werte, Anliegen und Interessen) repräsentieren den Austausch zwischen dem Unternehmen und den Anspruchsgruppen, der materieller (Güter) oder immaterieller (z. B. Rechte, Anliegen oder Normen) Art sein kann. • Ordnungsmomente (Strategie, Strukturen, Kultur) stellen das interne Rahmenwerk des Unternehmens dar, indem sie Ziele und formale/informale Kommunikationsstrukturen bestimmen. Wir werden, insb. in Teil 2, statt Struktur den Begriff Organisation verwenden und auf IS eingehen, die hauptsächlich die formalen Kommunikationsstrukturen abbilden bzw. unterstützen. • Prozesse bilden die sachlichen und zeitlichen Bedingungen und Abfolgen der Leistungserbringung ab. Ein Prozess ist eine logisch zusammenhängende Kette von Aktivitäten, die einen Start- und Endpunkt besitzen und auf Basis eines definierten Inputs die Leistungserbringung für einen bestimmten Nutzer spezifizieren. Eine besonders wichtige Ausprägung im betrieblichen Umfeld sind Geschäftsprozesse, welche auf die Erzielung eines messbaren positiven Wertschöpfungsbeitrags und die wiederkehrende Bearbeitung betrieblicher Objekte (z. B. Aufträge, Fakturierung) über verschiedene Organisationseinheiten hinweg für einen (internen oder externen) Kunden oder einen Markt ausgerichtet sind (s. Abschn. 6.1). Mit der Digitalisierung (s. Kap. 5) steigt der Umfang der

1.6 Modelle von Unternehmen

23

IT-Unterstützung von Geschäftsprozessen und liefert die Voraussetzung für sog. „Realtime“-Geschäftsprozesse (Alt 2008). Zu berücksichtigen ist, dass Management- und Unterstützungsprozesse auch eine Art von Geschäftsprozessen darstellen. • Entwicklungsmodi (schattierte Seitenfläche des Polyeders) zeigen Möglichkeiten der Weiterentwicklung auf, die aus der Verbesserung bestehender Prozesse (Optimierung) oder aus der Transformation unter Ausnutzung von Innovationen (Erneuerung) bestehen. Auf die Entwicklung der internen Strukturen, insb. die Ordnungselemente und die Prozesse, geht Teil 2 detailliert ein, während die Möglichkeiten der Verbesserung bestehender Prozesse und der Transformation an vielen Stellen im Buch erwähnt sind.

2

Informationssysteme

Zusammenfassung

Dieses Kapitel definiert zuerst auf Basis der im vorherigen Kapitel eingeführten Begriffe den Begriff Informationssystem und betrachtet danach die Evolution des Einsatzes von Informationssystemen in Unternehmen. Der Besprechung alternativer Möglichkeiten zur Gruppierung von Informationssystemen folgt die Erklärung ihrer einzelnen Arten. Das Kapitel wird durch die Betrachtung der Wechselwirkungen zwischen Organisationsformen und Informationstechnologie abgeschlossen.

2.1

Definition von Informationssystemen

Wir haben im Abschn.  1.2 den Begriff Information definiert. Die Begriffe System und Modell hat Abschn. 1.5 eingeführt. Nun können wir den zusammengesetzten Begriff Informationssystem definieren. cc Informationssystem  Ein Informationssystem (IS) ist ein künstliches, konkretes System, das aus maschinellen und menschlichen Elementen besteht und seine Nutzer mit Informationen versorgt. Es ist gleichzeitig ein Modell und ein Element einer Organisation oder verbundener Organisationen. Ein IS wird meistens von Menschen entwickelt, bedient und genutzt. Eine Ausnahme bzgl. Bedienung stellen die sog. eingebetteten IS (Embedded Systems) dar, die automatisch bedient werden und Ergebnisse autonom auswerten. Solche IS werden z. B. in Flugzeugen eingesetzt. Wie in Abb. 2.1 dargestellt ist der Begriff des IS allgemeiner gefasst und beinhaltet den Menschen als Anwender sowie das Anwendungssystem (AS), welches aus der ­Anwendungssoftware sowie der „darunter“ liegenden Basissoftware und dem Hardwaresystem besteht. In diesem Buch findet sich der Begriff des IS auch häufig abgekürzt © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_2

25

26

2 Informationssysteme

Mensch/Nutzer Softwaresystem

Hardwaresystem

Anwendungssoftware (Anwendung) Basissoftware Rechner

Informationssystem Anwendungssystem

sonstige technische Einrichtungen

Abb. 2.1  Informationssystem-Begriff und Unterbegriffe (Teubner 1999, S. 26)

als System wieder. Um die Unterstützung von betrieblichen Aufgaben in den Vordergrund zu stellen ist in diesem Buch (fettgedruckt gekennzeichnet in Abb. 2.1) darüber hinaus der Begriff der Anwendung, und um die Softwareentwicklung zu akzentuieren jener der Software enthalten. Im Kontext der anwendungsorientierten Wirtschaftsinformatik beziehen sich diese mehrheitlich auf die Anwendungssoftware. Die Intention der Softwareentwickler ist, dass sich das IS wie von ihnen geplant verhält. IS beinhalten jedoch oft Entwicklungsfehler, die erst im Zeitablauf zutage treten. Auch können Personen bei der Arbeit mit IS zufallsbedingte Bedienungsfehler unterlaufen, die zum Absturz der IS führen können. Es kommt weiter hinzu, dass Systeme aufgrund schwer vorhersehbarer äußerer Ereignisse ausfallen können (z. B. Erdbeben). Aus diesen Gründen kann das Verhalten der IS weder deterministisch noch stochastisch vorhergesagt werden. Diese Problematik wird je nach Wichtigkeit eines IS berücksichtigt, indem z. B. redundante Systeme genutzt oder Daten und Programme geeignet gesichert werden.

2.2

Evolution der Informationssysteme

Die mit dem Einsatz von IS verfolgten Ziele und die technischen Mittel zum Einsatz von IS haben sich seit ihrer Entstehung in den 50er-Jahren des vergangenen Jahrhunderts stark verändert. Aufgrund der stark durch den wirtschaftlichen Verwendungskontext ­geprägten Wirtschaftsinformatik soll sich die Darstellung der Evolution der IS an organisatorischen Aspekten orientieren. Danach lässt sich die Evolution der IS grob in vier Phasen einteilen. In der ersten Phase war das primäre Ziel die kommerzielle Computernutzung zur Unterstützung der Ausführungsebene. Ein Beispiel dafür stellt die Automatisierung des Rechnungswesens dar. Manuelle Abläufe wurden i.  d.  R. ohne Veränderungen auf den Computer übertragen. Das vorwiegende Argument für den Einsatz der sog. Elektronischen Datenverarbeitung (EDV) war die Steigerung der Effizienz. Das bedeutet, dass ein günstiges Verhältnis zwischen Ertrag und Aufwand erreicht werden sollte. Die bisherigen Abläufe sollten schneller und sicherer gemacht werden. Kosten sollten durch den Ersatz menschlicher Arbeitskraft durch Rechner eingespart werden. Die erste Phase kann daher

2.2 Evolution der Informationssysteme

27

auch als das Streben nach quantitativen Verbesserungen der Produktivität bezeichnet werden (z. B. mehr Buchungen pro Angestellter und Tag). Die IS wurden ausschließlich von Spezialisten entwickelt, die einer EDV-Abteilung angehörten, sofern sie Mitglieder der eigenen Organisation waren. Als seit Mitte der 70er-Jahre große Unternehmen IS für die meisten automatisierbaren Funktionen der Ausführungsebene bereits eingeführt hatten, wendeten sich diese der Unterstützung der Leitungsebenen zu. Das vornehmliche Ziel war nun die Erhöhung der Effektivität und letztlich die Verbesserung von Entscheidungen. Effektivität misst, wie nah man an ein gesetztes Ziel herangekommen ist. Sie kann auch umschrieben werden als „das Richtige zu tun“, während es bei Effizienz darum geht, dass man das, was man tut, „richtig tut“. Die IS aus dieser Phase entwickeln nicht nur IT-Spezialisten, sondern zunehmend auch Mitarbeiter funktionaler Abteilungen, in denen diese Systeme genutzt werden. Die von Fachanwendern entwickelten Systeme sind zwar kleiner als die von IT-Spezialisten entwickelten (die verwendeten Werkzeuge unterscheiden sich ebenfalls), aber sie können für die Unternehmen ebenso wichtig sein. Die Benutzer von IS werden von IT-­Spezialisten als Endbenutzer bezeichnet. Mitte der 80er-Jahre wurde festgestellt, dass manche der bereits eingesetzten IS ihren Organisationen große Wettbewerbsvorteile brachten. Deswegen begannen Unternehmen, gezielt solche Systeme zu entwickeln. Es ging nun oft darum, durch IS Kunden oder Zulieferer an die Firma zu binden, um höhere Marktanteile oder zusätzliche Gewinne zu erreichen. Natürlich führten auch in den zwei ersten Phasen erfolgreiche IS zu geringeren Kosten oder höheren Umsätzen, aber in dieser Phase wird der direkte Bezug zu den obersten finanziellen Zielen zum Zweck der Verbesserung der Wettbewerbssituation gesucht und gemessen. Investitionen in IS mussten sich gleichzeitig stärker dem Konkurrenzkampf zur ökonomisch sinnvollen Verwendung von knappen Ressourcen stellen. Während in der zweiten Phase die IS-Planung bestenfalls aus der strategischen Gesamtplanung abgeleitet war (und im schlimmsten Fall unabhängig von ihr oder in Unkenntnis derselben stattfand), wurde nun die IS-Planung in die strategische Gesamtplanung einbezogen. Ab Mitte der 90er-Jahre wurde das Internet für die kommerzielle und die private Nutzung geöffnet (Alpar 1998). In der ersten Welle haben Unternehmen zuerst Websites geschaffen, die sie zunächst nur für Marketing und dann auch zur Erzielung von Umsätzen mit isolierten Systemen nutzten. Diese Systeme wurden danach mit internen Systemen verknüpft (z. B. Rechnungswesen und Verwaltung des Lagerbestands). Seit dieser Zeit boomt der Handel über das Internet, insb. aufgrund der rasant gewachsenen privaten Nutzung. So ist der Internethändler Amazon heute erfolgreicher als die meisten Handelsunternehmen mit stationären Verkaufsgeschäften. Mit der weiteren Entwicklung der Internetnutzung in Richtung sozialer Anwendungen, der Zunahme der mobilen Nutzung und dem Anschluss von Geräten und Maschinen an das Internet (s. Abschn. 5.5) haben Unternehmen erkannt, dass sich mit diesen Technologien auch Produktions- und viele Serviceprozesse automatisieren lassen. Sie haben inzwischen verstanden, dass die

2 Informationssysteme

28 Tab. 2.1  Evolution von IS Unterstützung der Unterstützung der Primärziel Ausführungsebene Leitungsebenen Maß der Effizienz Effektivität Zielerreichung Entstehung IT-Abteilung IT-Abt. und der intern Endbenutzer entw. IS unabhängig voneinander Position des Im unteren oder Zweite oder dritte IT-Leiters mittleren Managementstufe Management Ausrichtung Funktional Technisch des IT-Leiters IT-Ausgaben 1 % des Umsatzes

Innovations-­ orientiert >1 % des Umsatzes Ab 1995

Ab 1985

Automatisierung einzelner Prozesse nicht mehr ausreicht, sondern dass eine umfassende digitale Transformation des gesamten Unternehmens notwendig ist, um wettbewerbsfähig zu bleiben. Tab. 2.1 zeigt das hier beschriebene Phasenmodell mit einigen weiteren Charakteristiken. Dabei ersetzen die neuen Ziele nicht die alten, vielmehr kommen diese eher dazu und die Art der Realisierung ändert sich aufgrund der ständigen Fortschritte in der IT. Außerdem wächst der Anteil der Unternehmen, für die IS den Kern ihrer Dienstleistung ausmachen wie auch der Anteil der IT in Produkten. Bei der Tabelle ist auch zu berücksichtigen, dass es sich hier um eine starke Vereinfachung handelt, die nur bestimmte Trends verdeutlichen soll (ausführlicher in (Alt et al. 2017, S. 17)). Desweiteren sind das Ausmaß und die Art der Nutzung von IS branchenspezifisch. In informationsintensiven Branchen wie Banken und Versicherungen (s. Abschn. 10.3.3) ist z. B. der Anteil der Ausgaben für IS wesentlich höher als in weniger informationsintensiven Branchen (z. B. Baugewerbe). Aber auch in letzeren Branchen ändert sich die Situation dadurch, dass Maschinen und Produkte zunehmend in die digitale Welt zu integrieren sind.

2.3

Arten von Informationssystemen

2.3.1 Klassifikationsschemata IS für betriebswirtschaftliche Anwendungen können unter Verwendung verschiedener Kriterien klassifiziert werden. Wir verwenden hier eine Klassifikation, die sich am Hauptzweck der IS orientiert (s. Abb. 2.2). Sie ähnelt einerseits früheren Klassifikationen, da die

2.3 Arten von Informationssystemen

29

früher eingesetzten IS weiter benötigt werden. Andererseits nehmen wir nun auch IS dazu, die oft nicht von Unternehmen besessen oder von diesen initiiert werden, aber deren Inhalte genauso für die Unternehmen wichtig sind und auch berücksichtigt werden. Zunächst sind hier die Systeme zu nennen, die Transaktionen bearbeiten. Eine Transaktion stellt hier einen Geschäftsvorgang dar, der zusammenhängende Funktionen auslösen kann. Eine Kundenbestellung als Beispiel erfordert verschiedene Prüfungen (z. B. Kreditwürdigkeit des Kunden, Höhe des Warenbestands), Berechnungen (z. B. Auftragssumme, Mehrwertsteuer), Bestandsänderungen (z. B. Vergrößerung des Auftragsbestands). Diese Systeme speichern die entsprechenden Daten und stellen somit die Quelle der „Wahrheit“ dar. Man nennt sie englisch Systems of Record. Die Ergebnisse der Transaktionsverarbeitung und Informationsbereitstellung dienen letztlich der Vorbereitung von Entscheidungen. Systeme, die das Entscheiden selbst unterstützen, können Alternativen generieren und/oder bewerten. Manche Programme fällen sogar autonom Entscheidungen. Man kann sie daher als Systeme zur Gewinnung von Erkenntnissen (engl. Systems of Intelligence oder Systems of Insight) bezeichnen. Die dritte Kategorie stellen, wie angedeutet, Systeme, die nicht immer von oder für Unternehmen geschaffen wurden, sondern oft der Interaktion zwischen Privatleuten oder zwischen Maschinen dienen, sog. Systems of Engagement (Systeme der Interaktion). Dieser Begriff geht auf (Moore 2011) zurück. Beispielsweise dient ein soziales Netzwerksystem (s. Abschn.  5.4.2) zunächst der Kommunikation zwischen Bekannten oder der Diskussion bestimmter Fragestellungen. Für Unternehmen können jedoch die entstehenden Daten so interessant sein, dass sie, so-

Abb. 2.2  Arten von Informationssystemen (in Anlehnung an (Chen et al. 2015))

30

2 Informationssysteme

fern das rechtlich zulässig ist, diese Daten speichern oder zumindest für Werbung ausnutzen. Ähnliches gilt für Daten, die bei der Interaktion von Maschinen oder Sensoren im Internet of Things (s. Abschn.  5.5) entstehen. Abb.  2.2 zeigt die Systemarten und ihre Beziehungen. Die Begriffe innerhalb der abgerundeten Rechtecke werden im Folgenden erklärt. Bei Systems of Records stehen sie beispielhaft für verschiedene Arten von Anwendungen. Bei Systems of Insight sind Methoden genannt, auf denen spezifische Anwendungen basieren. Bei Systems of Engagement sind AS-Unterarten und Geräte angegeben, die in IS eingebunden werden, über die Menschen und Maschinen untereinander und mit Unternehmen interagieren. Die Pfeile haben folgende Bedeutung. Meistens werten die Systems of Insight Daten aus, die in anderen Systemen entstehen. Manchmal schreiben sie auch in diese zurück. Nach der Analyse einer Diskussion in einem sozialen Netzwerk kann automatisch ein Beitrag für dieses Netzwerk erstellt werden. Das Ergebnis einer Kundensegmentierung in einem System of Insight kann in ein System of Records (z. B. ein Customer Relationship Management, CRM, s. Abschn. 12.2.1) eingetragen werden, um die zukünftige Ansprache der Kunden geeignet zu steuern. In vielen Fällen greifen heute Nutzer über das Web (System of Engagement) auf ein System of Records zu (z. B. ein Kunde, um den aktuellen Kontostand bei seiner Bank abzurufen). Daten aus einem System of Record können aber auch situationsbedingt in einem System of Engagement präsentiert werden. Wenn ein CRM beispielsweise merkt, dass ein Kunde in Geschäft eingetreten ist (z.  B. über ein WLAN), kann es ihm eine gezielte Nachricht über SMS oder WhatsApp schicken (basierend auf seinem letzten Einkauf). Weitere IS, die in Unternehmen zum Einsatz kommen, sind technische Systeme (z. B. zur Steuerung von Maschinen oder zum technischen Zeichnen) sowie Programme zur Steigerung der Produktivität am Arbeitsplatz (z. B. elektronische Post oder Textverarbeitung) und zur Unterstützung der Softwareentwicklung. Arbeitsplatzprogramme werden auf allen Ebenen und in nahezu allen Funktionsbereichen verwendet. Programme, die die Zusammenarbeit (Collaboration oder Cooperation) mehrerer Personen unterstützen, bezeichnet man als Software für Computer-Supported Collaborative Work (CSCW). Damit können Mitarbeiter kommunizieren und gemeinsam Aufgaben lösen. Ein Beispiel ist die gemeinsame, eventuell auch gleichzeitige Bearbeitung eines Dokuments. IS können auch danach unterschieden werden, ob sie an einem festen Ort (im Büro oder zu Hause) oder mobil verwendet werden. Während die frühe mobile Nutzung durch mobile PCs (meist sog. Laptops) erfolgte und daher keine grundsätzlichen Unterschiede gegenüber stationären IS aufwies, geschieht die mobile Nutzung heute oft mithilfe kleiner und spezifisch bedienbarer Endgeräte, wie Smartphones oder Tablets (s. Glossar). Dies erfordert Änderungen an den IS, z. B. am Format der Ausgabe der Ergebnisse, sodass diese Systeme zusammen mit den mobilen Endgeräten als mobile IS bezeichnet werden. Der Begriff lässt sich auch mit anderen Systembegriffen, z. B mit Business Intelligence (BI) (s. Abschn. 2.3.3) kombinieren. So bezeichnet Mobile BI ein BI-System, das auf die mobile Nutzung ausgerichtet ist.

2.3 Arten von Informationssystemen

31

Eine andere Möglichkeit, IS zu klassifizieren, besteht in der Verwendung der Kriterien Anwendungsbreite, mit den Ausprägungen Individual- und Standardsoftware, und Sektorspezifität, mit den Ausprägungen sektorspezifisch und -neutral. Individualsoftware (s. Kap. 14) erstellt das Unternehmen selbst oder gibt deren Entwicklung speziell in Auftrag. Standardsoftware wird für viele Anwender(organisationen) entwickelt. Sie kann von einer einzelnen Organisation, aber auch von vielen unabhängigen Softwareentwicklern entwickelt werden. Standardsoftware muss i. d. R. für die Nutzung im Unternehmen im Rahmen des sog. Customizing (s. Abschn. 10.4.1) angepasst werden. Aufgrund der hohen Kosten von Softwareentwicklung und -wartung lässt sich behaupten, dass tendenziell Standardsoftware der Vorzug gegeben wird, wenn es sich nicht um spezifische Vorgehensweisen in dem Unternehmen handelt, die eine Basis für Wettbewerbsvorteile darstellen. Ein Softwareprodukt kann zur Nutzung in einem bestimmten volkswirtschaftlichen Sektor vorgesehen sein. Zu den relevanten Sektoren zählen aus Sicht der Wirtschaftsinformatik insbesondere Handel, Industrie, Banken/Versicherungen sowie Dienstleistungen allgemein. Softwareprodukte mit ausgeprägtem Querschnittscharakter, wie z. B. Textverarbeitungssysteme oder Tabellenkalkulationsprogramme, stellen sektorneutrale Anwendungen dar. Weitgehend sektorneutral sind aber auch z. B. Anwendungen für das Rechnungswesen. Innerhalb bestimmter Sektoren sind unterschiedliche Branchen zu differenzieren, die spezifische Softwarelösungen benötigen. So lassen sich für den indus­ triellen Sektor etwa die Branchen Elektrotechnik, Maschinenbau, Chemie und Nachrichtentechnik unterscheiden, in denen unterschiedliche IS zum Einsatz kommen. Tab.  2.2 bildet die Klassifizierung zusammen mit einigen Beispielen ab. Eine weitere Unterscheidung von IS kann danach getroffen werden, ob die Systeme nur innerhalb einer Organisation oder von mehreren Organisationen gemeinsam genutzt werden. Durch die Verknüpfung von IS zwischen Organisationen entstehen zwischenbetriebliche oder interorganisationale Systeme (Interorganizational Systems, IOS). Ihre Anzahl und Bedeutung ist in den letzten Jahren aufgrund der Zunahme von Allianzen, Joint Ventures und anderer Unternehmenskooperationen, z. B. Beschaffungslieferketten (Supply Chains), ­gewachsen. Als Beispiel können IS angeführt werden, die einen Automobilhersteller mit seinen Zulieferern verbinden, sodass der Hersteller die Lieferbereitschaft der Zulieferer prüfen, Teile bestellen und andere Funktionen in einem System ohne Medienbrüche erledigen kann. Die Tab. 2.2  Klassifizierung von IS nach Anwendungsbreite und Sektorspezifität mit Beispielen Sektorspezifität Sektorspezifisch Anwendungsbreite Standardsoftware Individualsoftware

Produktionsplanung- und -steuerungssytem Selbst entwickelte PPS

Sektorneutral

Textverarbeitungsprogramme, EnterpriseResource-Planning-Systeme Selbst entwickelte Finanzbuchhaltung

32

2 Informationssysteme

wirtschaftlichen Vorteile solcher Systeme können groß sein (z. B. Minimierung der Lagerhaltungskosten oder Bindung der Kunden), sie können aber auch die Machtverhältnisse in Unternehmensbeziehungen verstärken oder umkehren. Solche Systeme betrachtet Kap. 12. Die Zusammenarbeit der Unternehmen über elektronische Kanäle unter Vermeidung von Medienbrüchen hat besonders aufgrund der verstärkten Nutzung des Internet zugenommen, was einen Teil von Electronic Business ausmacht (s. Abschn. 5.2). IS können auch nach eher technischen Aspekten unterschieden werden, z.  B. bzgl. ihrer Nutzung der Computer, der sog. Betriebsart (s. Glossar). So werden bei zeitkritischen Anwendungen Echtzeitsysteme eingesetzt, die eine sofortige Bearbeitung neuer Zustände bzw. Daten erfordern. Auf diese Klassifizierungen wird an dieser Stelle nicht weiter eingegangen. Eine Schwierigkeit einer umfassenden und überschneidungsfreien Kategorisierung von IS besteht darin, dass IS nach unterschiedlichen Gesichtspunkten benannt werden. Manchmal steht der funktionale Zweck im Vordergrund (z.  B. bei CRM-Systemen, s. Abschn. 12.2.1), manchmal die hierarchische Ebene der Informationsempfänger (z. B. bei Executive Information Systems, s. u.), manchmal die genutzten Methoden (z. B. bei Data Mining Systemen, s. u.) oder die im System eingefangene Erfahrung (z. B. bei Expertensystemen, s. u.). Im Folgenden werden die in Abb. 2.2 aufgeführten IS näher dargestellt.

2.3.2 Systems of Record Wenn der Schwerpunkt auf die Verarbeitung der Systems of Records gelegt wird, spricht man auch von Transaktionssystemen (Transaction Processing Systems, TPS). Sie unterstützen die Bearbeitung wiederkehrender Geschäftsvorgänge. Beispiele hierfür sind Auftragsbearbeitung, Lohn- und Gehaltszahlungen oder Materialbestellungen. Da die Transaktionen heute nicht mehr gesondert erfasst werden, z. B. auf Lochkarten, sondern sofort im IS, in dem sie weiter verarbeitet werden, nennt man solche IS auch Online Transaction Processing System (OLTP). TPS helfen den Mitarbeitern auf der Ausführungsebene (z. B. Buchhalter) effizienter zu arbeiten. Manchmal ermöglichen sie Transaktionen ohne weitere manuelle Eingriffe (z.  B. bei Geldautomaten). Die Behandlung der Geschäftsvorgänge ist standardisiert. Manager der operativen Ebene haben manchmal die Option, von der standardisierten Verarbeitung abzuweichen. Sie nutzen TPS auch zur Überprüfung der Korrektheit von Prozessabläufen. TPS wurden als erste IS eingesetzt; sie bilden oft die Basis für andere IS, indem sie die Datengrundlage für sie schaffen. Programme, die verschiedene betriebswirtschaftliche Funktionen in einem integrierten Softwareprodukt unterstützen, werden als Systeme zur Planung betrieblicher Ressourcen (Enterprise Resource Planning, ERP) bezeichnet. Sie sind heute die wichtigsten betriebswirtschaftlichen TPS und bilden das Rückgrat der Informationsverarbeitung in Unternehmen. Die Funktionalität von ERP-Systemen wird in Kap. 10 ausführlich erläutert, während die in Kap. 12 besprochenen Systeme die Transaktionsverarbeitung mit Kunden und Lieferanten unterstützen.

2.3 Arten von Informationssystemen

33

2.3.3 Systems of Insight 2.3.3.1 MIS und EIS Für die operative und taktische Managementebene eignen sich die Managementinformationssysteme (MIS), die Managern die Beobachtung des Ablaufs der Unternehmensprozesse, den Vergleich mit Planzahlen sowie die kurzfristige Geschäftsplanung erleichtern. Experten erwarteten am Anfang von MIS eine vollkommene Integration aller Unternehmensbereiche und eine sofortige Auskunftsbereitschaft über alle Vorgänge in dem Unternehmen und in seiner Umgebung. Diese ursprünglichen Erwartungen an MIS waren zu hoch gesteckt, sodass MIS letztlich in Misskredit gerieten. Zur Zeit der Entstehung von MIS in den 70er-Jahren waren die organisatorischen, software- und hardwaretechnologischen Grundlagen für eine solche Integration noch nicht gegeben. Heute wäre ein „totales MIS“ zwar eher möglich, aber nach wie vor nicht unbedingt sinnvoll. Angestrebt wird stattdessen der Aufbau aufeinander abgestimmter, spezialisierter IS. Die ursprünglichen MIS generierten periodisch eine Vielzahl von Berichten, die als Ausdruck an die vorgegebenen Adressaten verschickt wurden. Heute werden die meisten dieser Berichte elektronisch abgelegt, sodass sie berechtigte Benutzer nach Bedarf abrufen können, oder sie werden elektronisch verschickt. Häufig werden sie auch erst bei Bedarf generiert. Abb. 2.3 zeigt ein Beispiel für ein interaktives Berichtssystem. Die relativ schwierige direkte Nutzung von MIS und ihre Ausrichtung auf interne Daten führten zur Entwicklung von Führungs-IS, engl. Executive Information Systems (EIS),

Abb. 2.3  Beispiel eines Berichtssystems (entwickelt mit IBM Cognos 10.1)

34

2 Informationssysteme

für die strategische Managementebene. Diese Systeme zeichnen sich durch stärkere Benutzerfreundlichkeit aus. So lassen sich komplexe Berichte per Mausklick oder Bildschirmberührung abrufen. Außerdem setzen sie Farben und Grafiken konsequent ein. Durch den hierarchischen Berichtsaufbau kann schnell von hoch aggregierten Daten zu Detaildaten vorgestoßen werden. Weiterhin zeichnen sie sich durch die Einbeziehung externer Daten aus, wie sie z.  B. von Informationsdiensten wie Reuters oder Bloomberg angeboten werden. Da die Aggregation großer Datenmengen, die von den TPS erzeugt werden, viel Zeit und Rechenkapazitäten in Anspruch nimmt, werden diese Operationen häufig im Voraus ausgeführt und deren Ergebnisse gespeichert. Dadurch erhält der Benutzer des EIS die Ergebnisse seiner Anfragen sehr schnell. In vielen Organisationen wird die Vorverarbeitung nachts auf Großrechnern durchgeführt, sodass morgens der Manager mit dem EIS die Berichte auf seinem Arbeitsplatzrechner oder Smartphone abrufen kann. Aufgrund hoher Investitionskosten für EIS und relativ geringer Kosten pro zusätzlichem EIS-Arbeitsplatz besteht der Trend, solche Systeme auch unterhalb der Ebene des Topmanagements zur Verfügung zu stellen. Bei relativ geringen Zusatzkosten wird es dadurch möglich, eine bessere Informationsversorgung weiterer Manager zu erreichen. Bei EIS handelt es sich i. d. R. eher um eine Umgebung zur besseren Informationsversorgung des Topmanagements als um Funktionen zur Lösung konkreter Problemstellungen. Wenn sich ihr Informationsbedarf ändert, müssen Stabsmitarbeiter oder Mitarbeiter aus Fachabteilungen und oft auch Programmierer einbezogen werden, selbst wenn benötigte Daten in der Organisation bereits existieren. Folglich leidet in dieser Situation die Reaktionsgeschwindigkeit der Entscheider. Bei einer funktionalen Ausweitung der Systeme um Funktionen zur Entscheidungsunterstützung wird auch von Führungsunterstützungssystemen (Executive Support Systems, ESS) gesprochen. Dabei geht es jedoch weniger darum, die Topmanager wie bei DSS (s. nächster Abschnitt) zu befähigen, Modelle für gegebene Entscheidungsprobleme zu entwickeln, als ihnen das Durchspielen fertiger Modelle zu erleichtern. Der Begriff ESS ist zwar umfassender als EIS, aber wir behalten den älteren Begriff der EIS als Bezeichnung für diese Klasse von Systemen aufgrund seiner stärkeren Verbreitung bei. In den letzten Jahren hat sich in der Praxis der Begriff Business Intelligence (BI) eingebürgert, der je nach Verständnis für Anwendungen zur Berichtsgenerierung und -verteilung (ähnlich den MIS/EIS) und/oder für Anwendungen zur Entscheidungsunterstützung (ähnlich den DSS) steht (Gluchowski et al. 2008). Der Begriff beinhaltet allerdings auch spezielle Konzepte und Technologien zur Datenhaltung und -integration. Hierauf geht Kap. 11 detailliert ein.

2.3.3.2 DSS und GDSS MIS können der Phase der Problemfindung dienen. Die nachfolgenden Schritte des Problemlösens, die Generierung und Bewertung von Alternativen, müssen menschliche Entscheider allein durchführen. Die ersten für diese Phasen entwickelten Systeme, werden als Entscheidungsunterstützungssysteme (Decision Support Systems, DSS) bezeichnet. Sie sollen das ­gemeinsame Problemlösen von Mensch und Maschine erleichtern, indem sie dem Menschen

2.3 Arten von Informationssystemen

35

Daten, Methoden und Modelle zum Problemlösen über eine benutzerfreundliche Schnittstelle zur Verfügung stellen (Keen und Scott Morton 1978). Die Daten für DSS werden oft aus operativen Datenbeständen extrahiert, verdichtet und durch externe Daten „angereichert“. Der Methodenvorrat besteht i. d. R. aus traditionellen statistischen und mathematischen Verfahren. Aus diesem Methodenvorrat werden dann bei Bedarf Modelle erstellt. Methodenorientierte DSS können auf Verfahren der Unternehmensforschung (Management Science, MS oder Operations Research, OR) basieren. Mit ihnen kann z. B. die optimale Zuteilung von zu verarbeitenden Produkten zu Maschinen oder die Simulation des Kundenaufkommens zwecks Personaleinsatzplanung im Einzelhandel durchgeführt werden. Dies sind zwar wiederkehrende Aufgaben, die aber nicht vollkommen automatisiert werden können und i. d. R. methodische Kenntnisse erfordern. Wenn man den Begriff DSS weiter fasst, gehören dazu auch Systeme, die auf Verfahren der Künstlichen Intelligenz (KI) und des Data Mining (DM) aufbauen (s. Abschn. 2.3.3.4). In diesem Abschnitt werden nur die traditionellen DSS betrachtet. Als DSS werden sowohl Systeme bezeichnet, die für eine spezifische Anwendung entwickelt wurden, als auch solche Systeme, mit deren Hilfe sich spezifische DSS bauen lassen (sog. DSS-Generatoren). Mit den letzteren können auch Mitarbeiter in Fachabteilungen ihre eigenen Anwendungen entwickeln. Dafür sind jedoch gewisse Computer- und Methodenkenntnisse und oft viele Modellierungsversuche notwendig, sodass insbesondere hochrangige Entscheidungsträger DSS oft nicht direkt, sondern über Mitarbeiter (hier Knowledge Worker) nutzen. Die ersten DSS wurden auf spezifische Aufgabenträger ausgerichtet, z. B. Portfoliomanager, die Kunden bei Vermögensanlagen beraten, oder Produktmanager, die Marketingpläne vorbereiten. Später wurde die Idee der DSS ausgeweitet auf die Unterstützung zusammenarbeitender Gruppen (Group Decision Support Systems, GDSS) und ganzer Organisationen bei interdependenten Aufgaben (Organizational Decision Support Systems, ODSS), wie etwa bei der jährlichen Ergebnisplanung. Diese „Verwandten“ von DSS weisen zusätzliche Komponenten für ihre jeweiligen spezifischen Aufgaben auf. Bei GDSS sind es insbesondere Komponenten für eine reibungslose Kommunikation, die unabhängig davon ist, wo sich die einzelnen Gruppenmitglieder zur Zeit der Kommunikation befinden. Außerdem unterstützen sie die Findung eines Gruppenkonsensus. Bei ODSS ist ein „institutionelles Gedächtnis“, das frühere Pro­ blemfälle und zugehörige Entscheidungen beinhaltet, als Besonderheit vorhanden.

2.3.3.3 Künstliche Intelligenz Die Anfänge der heutigen KI können ungefähr auf die Mitte des vorigen Jahrhunderts zurückverfolgt werden, wobei der Begriff selbst während einer Konferenz in Dartmouth (USA) 1956 geprägt wurde. KI ist ein Gebiet der Informatik zur Entwicklung von Verfahren, mit denen das menschliche Problemlösungsverhalten nachgeahmt wird. Mit den ersten KI-Systemen versuchte man Programme zu entwickeln, mit denen man viele Arten von Problemen lösen kann. Diese Bemühungen waren nur von begrenztem Erfolg gekrönt. Die ersten kommerziellen Erfolge stellten sich erst ein, als man Systeme entwickelte, die sich auf ein spezielles Problem konzentrierten, wie z. B. Expertensysteme (Expert Systems, XPS).

36

2 Informationssysteme

XPS dienen der Lösung von Problemen, für die es keine exakten Lösungsverfahren gibt, im Gegenteil zu MS/OR-Methoden. Stattdessen arbeiten sie mit dem Wissen erfahrener Praktiker, das oft in Form von Regeln und Symbolen formuliert ist. Der Erfolg von XPS stellte sich insbesondere dort ein, wo Lösungsansätze schon bestanden, aber nicht mit rein quantitativen Algorithmen erfassbar waren. Das ist z. B. der Fall bei der Diagnose von Maschinenfehlern oder bei der Aufdeckung von Kreditkartenbetrug. Ein XPS besteht mindestens aus einer Wissensbasis und einer Komponente, die dieses Wissen verarbeitet (sog. Inferenzmechanismus). Viele XPS besitzen auch eine Komponente für den Dialog mit dem Anwender sowie eine Erklärungskomponente, die dem Anwender antworten kann, warum ihm das XPS bestimmte Fragen stellt oder wie das XPS zu einem Ergebnis gekommen ist. Selten verfügen XPS auch über eine Komponente zur Wissensakquisition, die aus dem Dialog mit dem Benutzer Wissen extrahiert und der Wissensbasis für die spätere Nutzung zuführt. Üblicher ist es, dass die Arbeit der Erweiterung und Verbesserung der Wissensbasis von Menschen geleistet werden muss, die in diesem Zusammenhang als Wissensingenieure bezeichnet werden. Wegen der schnellen Änderung des Wissens und der spezifischen Kenntnisse für die Entwicklung und Wartung von XPS ist ihre Pflege aufwändig. Manche Verfahren der KI versuchen, neue Lösungsansätze oder Zusammenhänge zu entdecken, weswegen sie als Wissensentdeckungssysteme gelten. Da sich die Suche nach Zusammenhängen meist in Datenvorräten vollzieht, die man als Datenbanken bezeichnet, wird dieser Forschungsbereich auch als Wissensentdeckung in Datenbanken (Knowledge Discovery in Databases) bezeichnet. Inhaltlich verwandt dazu ist die Bezeichnung maschinelles Lernen (Machine Learning), die den Fokus auf Maschinen (Computer) legt, die in Daten selbständig Zusammenhänge erkennen können, die Menschen vorher nicht explizit genannt haben (und oft nicht kannten). Es gibt keine eindeutige Zuordnung von Techniken und Systemen zu diesen Kategorien. Es werden dazu z. B. Künstliche Neuronale Netze (KNN), englisch Artificial Neural Networks (ANN), gerechnet. Ein ANN besteht aus mehreren verbundenen Ebenen von Verarbeitungselementen, die in Analogie zur Informationsverarbeitung im menschlichen Gehirn als Neuronen bezeichnet werden. Die erste Ebene wird als Eingabe- und die letzte als Ausgabeebene bezeichnet. Dazwischen kann es eine oder mehrere „versteckte“ Zwischenebenen geben. Ein Neuron (ab zweiter Ebene) erhält numerische Eingaben, gewichtet und summiert sie, transformiert die Summe und gibt den transformierten Wert aus, entweder an Neuronen der nächsten Ebene oder als Endausgabe. Ein neuronales Netz kann lernen, indem es die verwendeten Gewichte so lange verändert, bis die gewünschte Güte des ANN erreicht ist. Die Güte kann z. B. danach beurteilt werden, wie stark die Ergebnisse der Berechnungen historischer Fälle mit bekannten Ergebnissen übereinstimmen. Dieser Vorgang wird als überwachtes Lernen bezeichnet. Beim nicht überwachten Lernen (Unsupervised Learning) liegen nur Inputdaten vor, die die Algorithmen versuchen, geeignet zu klassifizieren. Beim Vorliegen von vielen Schichten spricht man vom „tiefen“ Lernen (Deep Learning), ohne dass es für die Bezeichnung eine genaue Vereinbarung gibt. ANN werden zur Erkennung von Mustern und zur Klassifikation von Daten eingesetzt. Bei rückgekoppelten neuronalen Netzen (Recurrent Neural Networks, RNN) kann die Ausgabe eines Neurons als Eingabe für Neuronen einer vorhergehenden Schicht oder der

2.3 Arten von Informationssystemen

37

gleichen Schicht oder für sich selbst dienen. Sie eignen sich besonders für die Verarbeitung sequenzieller Daten und speziell temporaler Daten und werden z. B. erfolgreich bei Spracherkennung angewandt. Eine populäre Variante von RNN verwendet das Konzept der Long Short-Term Memory (LSTM), um das Lernen in RNN zu verbessern, indem die Erinnerung an frühere Trainingsdaten (bzw. das Vergessen) geeignet gesteuert wird. Eine weitere, neuere Form von ANN stellen die gefalteten neuronalen Netze (Convolutional Neural Networks, CNN) dar. Diese können Inputdaten in Form von Matrizen verarbeiten, was sie besonders für die Bildverarbeitung geeignet macht. Sie bestehen aus Neuronenschichten, die Daten filtern (Convolution Layer) und dann die Ergebnisse zusammenfassen (Pooling Layer). Abb. 2.4 zeigt ein Beispiel, in dem durch Erkennung von kleinen Bildausschnitten und der vollständigen Vernetzung aller Zwischenergebnisse, das Gesamtbild mit einer Wahrscheinlichkeitsangabe interpretiert wird. Schließlich sei an dieser Stelle auch das bestärkende Lernen (Reinforcement Learning, RL) genannt, obwohl es unabhängig von KNN entwickelt wurde und funktionieren kann. Dabei wählt ein Agent (ein Algorithmus) in jedem Zustand eine Aktion, die zu einem neuen Zustand und zu einer Belohnung führt. Trainingsdaten werden also durch Probieren generiert. Nach vielen solchen Explorationen kann der Agent eine Funktion für den erwarteten Nutzen seiner Aktionen schätzen bzw. das Gelernte verwerten (Exploitation), die ihm hilft eine optimale Strategie für das Erreichen einer maximalen Gesamtbelohnung zu erlernen. Bei wenigen Zuständen kann die Bewertung der erreichbaren Zustände mit Tabellen erfolgen. Bei vielen Zuständen benötigt man andere Verfahren, wie z. B. KNN, die nun das Erlernen der besten Strategie unterstützen. Mit RL ist es u. a. gelungen ein Programm zu entwickeln, das den weltbesten Spieler des Strategie-Brettspiels Go schlägt. Ein Nachteil aller KNN ist, dass ihre Entscheidungen oft nicht nachvollziehbar sind. In der nächsten Entwicklungsstufe wird daher versucht, ihr Lernvermögen (aus Daten) mit Erklärungen anzureichern, so dass Menschen besser verstehen können, warum eine Entscheidung, Regel oder Strategie empfohlen wird. Einen ganz anderen Ansatz in der KI stellen Genetische Algorithmen (Genetic Algorithms, GA) dar, die aus einer Menge potenzieller Lösungen diejenigen auswählen, die einem vorgegebenem Ziel am nächsten sind. Dann verändern sie diese durch Anwendung von Operationen wie „Fortpflanzung“, „Austausch von Genen“ oder „Mutation“. Dadurch entstehen neue Lösungen. Der Algorithmus stoppt, wenn Lösungen gefunden worden sind, die zufriedenstellend nah am vorgegebenen Ziel liegen. Convolution

Pooling

Convolution

Pooling

Fully Fully Connected Connected

Output Predictions

dog (0.01) cat (0.04) boat (0.94) bird (0.02)

Abb. 2.4  Erkennung von Bildinhalten mit Hilfe von CNN (Britz 2015)

38

2 Informationssysteme

2.3.3.4 Data Mining In den letzten Jahren werden die Verfahren der Wissensentdeckung auch zur Gruppe der Algorithmen des Data Mining (DM) gezählt, sodass die Begriffe Wissensentdeckung und Data Mining oft synonym verwendet werden. Der Begriff DM wird häufig mit Datenmustererkennung übersetzt und subsumiert alle Methoden, die in einer gegebenen Datenmenge interessante Muster aufdecken. Diese Muster stellen „Hypothesen“ dar, die der weiteren Verifikation bzw. Falsifikation bedürfen. Der Prozess des DM wird in einzelne Phasen aufgeteilt: Auswahl der Daten aus geeigneten Datenquellen, Exploration der Daten mit den Methoden der explorativen Datenanalyse, Stichprobenziehung aus ausgewählten Datensätzen, Vorverarbeitung der Daten inklusive einer eventuellen Bereinigung der Daten (Data Cleansing), sowie eine Transformation der Daten in die von DM-Algorithmen benötigte Form. Nach Schätzung von Experten werden ca. 80 % der Zeit und Kosten des DM für diese Vorarbeiten aufgewandt. Die letzte Phase, die Wissensgewinnung i. e. S., identifiziert schließlich die Datenmuster. Außer den erwähnten Verfahren der KI (z. B. ANN) und manchen schon lange angewandten Verfahren der multivariaten Statistik (z. B. Clusteranalyse, Diskriminanzanalyse und logistische Regression) werden u. a. folgende Aufgaben und Verfahren dem DM zugerechnet. • Basierend auf einer Zusammenfassung von Objekten in Gruppen, die sich durch charakteristische Attribute und gleiches Verhalten bezüglich des zu untersuchenden Pro­ blems auszeichnen, werden nicht klassifizierte Objekte aufgrund ihrer Attributausprägungen diesen Klassen zugeordnet. Zur Klassifikation (Classification) sind z.  B. Entscheidungsbäume (Decision Trees) einsetzbar. Als Beispiel wird in Abb.  2.5 das Ergebnis der Entwicklung eines Entscheidungsbaums dargestellt. Die Verbindungen von der Baumwurzel bis zu einem Endknoten (Blattknoten) stellen eine Regel dar, die aus „und“-verknüpften Bedingungen besteht. Aus dem Teilbaum ist z. B. ablesbar, dass eine Regel Objekte gruppiert, deren Alter ≥ 44,5 (oder fehlend) ist und die einen Wohlstandsgrad von < 12,5 (oder fehlend) besitzen. Zur Ermittlung von Knoten, die einen hohen Anteil von Elementen einer Klasse enthalten, kann die Entropiefunktion benutzt werden (s. Abschn. 1.2). • Die Abweichungsanalyse (Deviation Detection) beschäftigt sich mit Objekten, die sich keinem Datenmuster eindeutig zuordnen lassen. Wird ein „Ausreißer“ im Datenpool identifiziert, so werden alle assoziierten Datenbestände durchsucht, um mögliche Ursachen für die atypischen Merkmalsausprägungen des Ausreißers aufzudecken. • Die Verfahren der Assoziationsanalyse (Association Discovery) suchen nach signifikanten Abhängigkeiten zwischen einzelnen Attributen der Analyseobjekte und bewerten diese mit Häufigkeiten. Im Handel wird die Assoziationsanalyse insbesondere bei der Warenkorbanalyse angewandt. Dabei wird ein hohes Volumen von Kaufakten analysiert, um Trendaussagen über das Käuferverhalten zu entwickeln oder sachliche Verbundeffekte aufzudecken. Ein mögliches Ergebnis einer Warenkorbanalyse kann lauten: Bei 55  % der Einkäufe, bei denen Milch eingekauft wurde, wurde auch Joghurt gekauft.

2.3 Arten von Informationssystemen

39

Abb. 2.5  Beispiel eines Entscheidungsbaums in KNIME Analytics 3.6.1

• Um zeitliche Verbundeffekte aufzudecken, wird die Warenkorbanalyse um die Dimension Zeit erweitert. Das Ziel der Reihenfolgeanalyse (Sequential Pattern Discovery) ist es, einzelne Phasen und die zeitlichen Distanzen zwischen wiederkehrenden Ereignissen zu entdecken. Im Handel ist hierfür Voraussetzung, dass die Daten einzelner Kunden über einen Zeitraum gesammelt werden. Ein denkbares Ergebnis einer Sequenzanalyse ist beispielsweise: Von den Kunden, die einen PC gekauft haben, kaufen 23 % sechs Wochen später ein Spielprogramm. • Die Analyse ähnlicher Zeitabfolgen (Similar Time Sequence Discovery) sucht Zeitabfolgen mit ähnlichem Muster. Ziel einer solchen Analyse könnte sein: Suche alle Aktien, deren Kurs sich in 2015 ähnlich wie der Kurs von ABC bewegt haben. Erzeugt der DM-Prozess keine Hypothesen mit interessantem Informationsgehalt, so könnte eine Rückkopplung zu früheren Phasen nötig sein. Das Hinzuziehen weiterer Datenquellen oder die Ziehung einer andersartigen Stichprobe könnten zu neuen Erkenntnissen führen. Beim Einsatz von DM-Werkzeugen sollten die betriebswirtschaftlichen

40

2 Informationssysteme

Fragestellungen die erforderlichen DM-Methoden bestimmen. Eine unsystematische Anwendung von DM-Methoden auf die Datenbestände des Unternehmens führt dabei selten zur Entdeckung neuer Datenmuster. Eine detaillierte Beschreibung verschiedener betriebswirtschaftlicher Anwendungen des DM findet sich in (Alpar und Niedereichholz 2000). Im Zug der zunehmenden Größe und Vielfalt von Datenmengen (s. Abschn. 11.2.6), die heute gesammelt werden, werden ständig neue Algorithmen entwickelt, die sich für die Automatisierung weiterer Prozesse eignen.

2.3.3.5 Text Mining und Verarbeitung natürlicher Sprache Text Mining kann analog zu Data Mining als die Suche nach interessanten Mustern in Texten verstanden werden. Die meisten Daten in Unternehmen bestehen aus Texten ohne feste Struktur. Dazu gehören Verträge mit Geschäftspartnern und Mitarbeitern, Korrespondenz mit Geschäftspartnern, Produktbeschreibungen, E-Mails, Beiträge in sozialen Medien (s. Abschn. 5.4) usw. Texte können zwar rein statistisch ausgewertet werden (z. B. danach, wie oft einzelne Worte vorkommen oder nach Ähnlichkeit bzgl. verwendeter Worte), aber bessere Ergebnisse können i. d. R. nach einer linguistischen Vorverarbeitung erzielt werden. Bei einer einfachen Gruppierung nach Ähnlichkeit würde z. B. die Ähnlichkeit zwischen „ist“ und „war“, „Haus“ und „Häuser“ oder „Manager“ und „Abteilungsleiter“ kaum erkannt werden. Wenn jedoch Worte zuerst auf ihren Stamm und Verben auf ihre Infinitivform zurückgeführt und ein Wörterbuch mit Synonymen verwendet würden, könnte die Ähnlichkeit leicht erkannt werden. Diese Vorarbeiten fallen auch bei Aufgaben an, bei denen es nicht um die Ähnlichkeit von vielen Texten geht, sondern eher um das Verstehen einzelner Sätze (z. B. Sprachassistenten) oder Dokumente (z. B. Übersetzung). Bei dieser Vorverarbeitung geht es immer um die Verarbeitung natürlicher Sprache (Natural Language Processing, NLP). Text Mining und das inhaltliche Verstehen einzelner Sätze oder Dokumente nutzen also teilweise die gleichen linguistischen Verarbeitungsschritte (s. Tab. 2.3). Phonologie hilft, gesprochene Laute zu erkennen. In der Morphologie werden z. B. Worte auf ihre Stämme zurückgeführt (Stemming). Bei der Syntaxanalyse werden Wortarten (Part-of-Speech Tagging) und ihre Zusammensetzung in Phrasen bestimmt (z. B. können ein Artikel und ein Substantiv eine Nominalphrase bilden). Ein Satz wird entsprechend einer Grammatik auf die korrekte Zusammensetzung der Phrasen untersucht Tab. 2.3  Schritte der Sprachverarbeitung (in Anlehnung an (Görz 1989)) Ebene Ordnung

Inhalt

Bereich Phonologie Morphologie Syntax Semantik

Gebrauch

Pragmatik und Diskurs

Zweck Erkennung von gesprochenen Lauten Erkennung von Worten Erkennen von Wortstrukturen Erkennen der Bedeutung von Worten und Strukturen Erkennen des Zwecks eines Textes

2.3 Arten von Informationssystemen

41

(Parsing), wobei Mehrdeutigkeiten möglich sind. Bei der semantischen Analyse wird dann festgestellt, welche Funktion die einzelnen Phrasen haben (z. B. als Subjekt oder Objekt). Schließlich kann der Zweck einer Aussage oft nicht aus dem Satz selbst, sondern nur im Kontext eines Dokuments oder weiteren Wissens verstanden werden. Der Umfang der notwendigen linguistischen Vorverarbeitung hängt hauptsächlich von der Auswertungsaufgabe ab. Folgende Aufgaben des Text Mining sind nach Umfang der Texteingabe geordnet: • Ein oder wenige Worte –– Suche von Dokumenten, die eingegebene Worte enthalten –– Textvervollständigung • Frage oder Kommando –– Beantwortung einer Frage –– Sprachsteuerung • Wenige Sätze oder ein Dokument –– Textkorrektur bzgl. Zeichensetzung und Grammatik –– Sentiment-Analyse (automatische Erkennung der Einstellung eines Text-Autors zu einem Objekt, z. B. Produkt oder Ereignis; dabei wird immer zwischen positiver und negativer Einstellung unterschieden und manchmal auch die Stärke der Einstellung gemessen) –– Übersetzung –– Textzusammenfassung –– Informationsextraktion, z. B. bzgl. bestimmter Personen –– Verschlagwortung • Dokumentensammlung –– Kategorisierung von Texten –– Vergleich von Texten (z. B. von Autoren oder über Zeit) Abb. 2.6 zeigt beispielhaft den Workflow mit dem Softwarewerkzeug KNIME, um Worthäufigkeiten in vier Nachrichten-Feeds in Form einer Datenwolke (Tag Cloud) darstellen zu können, sowie das Ergebnis dieser Analyse am 13.09.2018. Dabei wird ein Wort umso größer dargestellt je häufiger es vorkommt. Weiter deuten Farben die Wortart an (z. B. blau für Eigennamen, rot für geographische Begriffe). Obwohl diese Anwendung relativ einfach erscheint, müssen einige der genannten Schritte durchgeführt werden, u. a. auch eine Eigennamenerkennung (Named-Entity Recognition, NER). Die Einbeziehung der Wahrnehmung physischer Vorgänge bei der Nachahmung des menschlichen Problemlösens in Programmen führt zu Cognitive Computing. Ein Kundenanruf kann z. B. mit Hilfe der Verarbeitung der natürlichen Sprache, wie beschrieben, von Programmen akustisch und inhaltlich verstanden werden. Wenn zusätzlich der Tonfall oder die Geschwindigkeit des Sprechens ausgewertet werden, können zusätzliche Erkenntnisse gewonnen werden, die ein menschlicher Kundenberater zumindest ­wahrnehmen würde. Cognitive Computing basiert also auf NLP und Auswertung von Wahrnehmungen von Prozessen der Umwelt (D’Onforio et al. 2018).

42

2 Informationssysteme

Abb. 2.6  Beispiel von Text Mining in KNIME Analytics 3.6.1

2.3.3.6 Visual Analytics Wenn sehr viele Daten vorliegen, liegen manchmal keine Anhaltspunkte für eine quantitative Analyse vor. Mit geeigneter Software können die Daten grafisch dargestellt werden. Danach kann man Daten interaktiv filtern, transformieren und aggregieren, so dass eventuell ein Muster zum Vorschein kommt oder zumindest Annahmen über den Zusammenhang von Variablen gemacht werden können. Diese Annahmen können dann mit quantitativen Methoden überprüft werden. Die erste Analyse erfolgt also per Augenschein, weswegen hier der Begriff Visual Analytics verwendet wird. Pakete für Visual Analytics enthalten oft auch einige der beschriebenen analytischen Verfahren, so dass sich die quantitative Analyse mit gleicher Software anschließen kann. Die Ergebnisse werden sofort grafisch dargestellt und können bei Bedarf kommuniziert werden. Abb. 2.7 stellt eine beispielhafte Darstellung des Bewertungsverhaltens in der Region Edinburgh im Kontext einer geografischen Karte mit der Software Tableau dar.

2.3 Arten von Informationssystemen

43

Abb. 2.7  Beispiel einer Analyse mit der Software Tableau (Stull-Lane o. J.)

2.3.4 Systems of Engagement Systems of Engagement ermöglichen die Interaktion und Kollaboration mit Kunden und Geschäftspartnern (Moore 2011) wie sie auch in Kap. 12 enthalten sind. Sie basieren auf Schnittstellen zu sozialen Medien, Apps (s. Kap. 5), Konferenzwerkzeugen und anderen dezentralen Systemen, die oft die Cloud (s. Abschn. 4.4.3) als Infrastruktur nutzen. Ihr Nutzen ergibt sich häufig aus der Integration mit bestehenden Geschäftsprozessen, indem sie dadurch den unternehmensexternen Nutzern weitere Dienstleistungen anbieten. Zudem unterliegen sie ausgeprägten Netzwerkeffekten (s. Abschn. 12.3), da ihr Nutzen von der Nutzung durch andere Partner abhängt. Ein oft genanntes Beispiel sind Laufschuhe, die Daten an eine App im Smartphone des Trägers senden, auf deren Basis Bewegungsmuster analysiert werden können. Die App kann die Daten auch mit anderen persönlichen Fitnessdaten verknüpfen, aber auch (anonymisiert) an den App-Betreiber senden, der sie mit Daten anderer Läufer verknüpfen und analysieren kann, um Verbesserungsvorschläge für den Läufer und das Produkt zu machen. Ein neueres Beispiel ist die Verknüpfung einer Hotelzimmerbuchung (etablierter Geschäftsprozess) mit einem Check-In vor Ort ohne Hotelpersonal (inkl. Generierung eines Codes für Zugang zum Hotel und zum Zimmer). Moore (2011) sieht Systems of Engagement als die nächste Stufe der Entwicklung von Systems of Records, die diese auch ersetzen könnten. Das ist bisher nicht geschehen denn die Abwicklung von Transaktionen und die Aufbewahrung ihrer Ergebnisse stellen, nicht

44

2 Informationssysteme

zuletzt aus gesetzlichen Gründen, hohe Anforderungen an Korrektheit und Sicherheit. Das lässt sich bei Systems of Engagement, die auf Komponenten basieren können, die anderen Organisationen gehören, und oft nur spezifische Dienste anbieten, kaum realisieren.

2.4

 echselwirkungen zwischen Informationstechnologie und W Organisationen

Die bislang erwähnten Beispiele unterstreichen, dass die Einführung von IS zu starken Veränderungen in der betroffenen Organisation führt und, je nach IS, auch in den Beziehungen der Organisation zu ihrer Außenwelt. Arbeitsgänge ändern sich, Aufgaben entfallen und neue Aufgaben kommen hinzu. Viele Veränderungen hat das Internet induziert: Aus Konsumenten werden aufgrund stärkerer Interaktion mit einem Unternehmen Produktentwickler, einzelne Buchkäufer werden durch Schreiben von Rezensionen in elek­ tronischen Buchläden zu Meinungsmachern, Kunden geben ihre Aufträge selbst ein. So werden Angestellte bei Expressgutversendern, die nur Auskunft über Sendungen geben, dafür nicht mehr gebraucht, weil Kunden selbst die Verfolgungssysteme abfragen. Es stellt sich also die Frage, wie IS Organisationen beeinflussen (Markus und Robey 1988). Nach der Theorie des „technologischen Imperativs“ determiniert IT die Organisationsstrukturen. So wird bestimmten Hardwaretechnologien ein zwangsläufiger Einfluss auf die De- oder Zentralisierung in Unternehmen zugesprochen. Beispielsweise wird behauptet, dass Großrechner eine zentrale Organisation unterstützten, während Client-­ Server-­Architekturen (s. Abschn. 9.2 und Glossar) zu dezentralen Strukturen führten. Die Theorie des „organisatorischen Imperativs“ nimmt hingegen an, dass Organisationen eine vollständige Kontrolle über die Auswahl und den Einsatz von IT besitzen. Empirische Forschungen konnten für keine dieser Theorien eindeutige Beweise liefern, sodass heute der Vorzug einer Sicht gegeben wird, nach der Organisationsänderungen aufgrund einer wechselseitigen Beeinflussung zwischen Organisationsstrukturen und der vorhandenen IT entstehen. Dies bedeutet, dass die gleiche IT in unterschiedlichen Unternehmen zu unterschiedlichen Strukturen führen kann und dass Unternehmen mit annähernd gleicher Organisation unterschiedliche IT einsetzen. Der Zusammenhang zwischen Technologieänderungen und Veränderungen einer Organisation kann wie in Abb. 2.8 dargestellt werden. Manche Veränderungen betreffen nur die Ebene der IT (z.  B. neue Bildschirmtechnologie), andere durchdringen alle Unternehmensebenen. Das beginnt bei der Strategie, die festlegt, was zu tun ist, und setzt sich auf Organisationsebene fort, die Geschäftsprozesse (Business Processes) bestimmt und vorgibt, wie etwas erfolgen soll. Daraus ergeben sich die fachlichen Anforderungen für die Gestaltung der benötigten IS, die mithilfe der vorhandenen IT umgesetzt werden. Die letzte Ebene beantwortet also die Frage nach dem womit. Die IT ist aber nicht nur Umsetzungsinstrument, sondern die Innovationen der IT eröffnen auch fachliche Möglichkeiten zur Entwicklung neuer Geschäftsmodelle und daraus abgeleiteter Strategien und

2.4 Wechselwirkungen zwischen Informationstechnologie und Organisationen

Unternehmen heute Unternehmensstrategie

Anforderungen an IT

Unternehmensorganisation

Informationstechnologie

Transformation

45

Unternehmen morgen

Veränderung von Geschäftsstrategien und -modellen durch Digitalisierung

Veränderung von Prozessen und Organisationsstrukturen durch Digitalisierung

IT als Enabler

Informationstechnologische Potenziale (Big Data, Internet of Things, Social Media etc.)

Abb. 2.8  Beziehungen zwischen Unternehmen und IT

Geschäftsprozesse (IT als Enabler). Ein Beispiel dafür stellen digitale bzw. auf den Potenzialen der Digitalisierung (s. Abschn. 1.1) beruhende Geschäftsmodelle dar, die es Kunden dank moderner IT ermöglichen, Fahrräder oder Autos ohne menschliche Vermittler minutenweise auszuleihen. Alle Veränderungen finden unter jeweils relevanten politischen und kulturellen Rahmenbedingungen statt. Erneuerung durch Transformation ist einer der zwei Entwicklungsmodi im Modell des Unternehmens in Abb.  1.5. Um Transformationen erfolgreich umzusetzen, müssen Veränderungen über alle Bereiche konsistent gestaltet werden. Auf die damit notwendige integrierte Betrachtung von Strategie-, Organisationsund IS-Ebene geht Kap. 6 genauer ein. Die Einführung von IS führt oft zu Machtverschiebungen. Zu Verlusten von Macht kommt es, wenn Informationen, über die bisher nur wenige Mitarbeiter verfügt haben, durch ein IS vielen Mitarbeitern zur Verfügung stehen. IS können die Kontrolle von Mitarbeitern erleichtern, was zur Einschränkung der Selbstständigkeit der Kontrollierten führt. Die IT-Abteilung wird von anderen Abteilungen manchmal als mächtig angesehen, weil sie mit neuen IS im Auftrag des Topmanagements auch die Arbeitsabläufe in den betroffenen Abteilungen verändert. Mitarbeiter in der IT-Abteilung befürchten wiederum, dass sie an Bedeutung für die Organisation verlieren, wenn Mitarbeiter in anderen Abteilungen selbst IS entwickeln. Aus diesen Beispielen folgt, dass IS nicht per se ein Instrument zur Machterhöhung einer bestimmten Hierarchieebene oder Fachgruppe sind. Die Entwicklung, Einführung und der Einsatz von IS werden deswegen von Machtkämpfen der Interessengruppen begleitet, die Entscheidungen über den Ressourceneinsatz und die Organisation der Nutzung der IS beeinflussen wollen (z. B. (Kling und Iacono 1984)). Eine Reihe von Aktionen und Verhalten werden offen oder versteckt eingesetzt, um die Einführung von IS zu verhindern (Keen 1981). In vielen Fällen, in denen ein IS nicht erfolgreich entwickelt oder eingeführt werden konnte, lag es nicht an technischen Pro­ blemen, sondern an mangelnder Beachtung der politischen Implikationen des neuen IS.

46

2 Informationssysteme

Eine erfolgreiche Änderung kann nur gelingen, wenn Aufgaben, Technologie und Menschen gleichzeitig geändert werden. Die Steuerung der Organisationsänderungen (Change Management) stellt heute eine wichtige Unternehmensaufgabe dar. Dabei spielt die Weiterbildung von Mitarbeitern eine wichtige Rolle. Bei der Planung der organisatorischen Implementierung eines neuen IS kann man generelle Modelle der Veränderungen in Organisationen heranziehen. Viele dieser Modelle basieren auf dem Modell von Lewin und Schein (Ginzberg 1981), das drei Phasen unterscheidet. In der ersten Phase ist die Atmosphäre für Veränderung herzustellen, d. h. Menschen müssen für die Aufgabe des momentanen Zustands gewonnen werden (Auftauphase). Erst wenn diese Bereitschaft geschaffen oder, im ungünstigen Fall, erzwungen worden ist, sollte die Veränderung auch durchgeführt werden (Durchführungsphase). In der letzten Phase geht es darum, den neuen Zustand für eine bestimmte Zeit ohne Veränderungen beizubehalten (Einfrierphase), damit sich die Menschen an ihn anpassen können und dabei die Angst vor der Neuigkeit verlieren. In den letzten Jahren ist der Druck auf Unternehmen stark gestiegen, häufige organisatorische Änderungen (oft mithilfe von IS) durchzuführen. Die Phase des Einfrierens wird damit zunehmend kürzer und die Forderung nach konstantem Lernen und ständiger Änderung wird immer öfter vorgebracht. Es ist noch nicht klar, ob und wo die menschliche Psyche solchen Forderungen Grenzen setzt. Auf den ständigen Wandel gehen die Ausführungen zu Business Process Reengineering und Continuous Improvement in Abschn. 6.1 genauer ein.

3

Planung und Steuerung des Einsatzes von Informationssystemen

Zusammenfassung

Dieses Kapitel führt in die Aufgaben ein, die sich für die Leitung eines Unternehmens aus der Nutzung der Informationstechnologie ergeben. Dazu gehören vereinfacht Planung, Umsetzung und Überwachung. Überwachung schließt die ökonomische Bewertung des Einsatzes von Informationstechnologie ein.

3.1

Informationsmanagement

3.1.1 Aufgaben des Informationsmanagements Informationsmanagement (IM) umfasst die Aufgaben der Planung, Überwachung und Steuerung der Informationsinfrastruktur als Ganzes (strategische Ebene) und der einzelnen Komponenten dieser Infrastruktur (taktische Ebene) sowie der Nutzung dieser Infrastruktur (operative Ebene) (Heinrich und Stelzer 2011). Diese Beschreibung positioniert die Aufgaben des IM in der Managementpyramide (s. Abb. 1.4). Eine andere Beschreibung des IM unterscheidet drei Sichten auf das IM, aus denen sich unterschiedliche Aufgaben des IM ergeben. Diese Sichten sind die unternehmerische, konzeptionelle und instrumentelle Sicht (Österle et al. 1992). Die darin anfallenden Aufgaben sind: • Prinzipielle Lösung geschäftlicher Fragestellungen mithilfe der IT, • Entwicklung des logischen Aufbaus der IS, und • Realisierung und Betrieb der IS. Diese drei Sichten erläutert der nächste Abschnitt genauer. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_3

47

48

3  Planung und Steuerung des Einsatzes von Informationssystemen

3.1.2 Sichten auf das Informationsmanagement Die unternehmerische Sicht erfordert ein „informationsbewusstes“ Management. Das beinhaltet das Erkennen der Potenziale der IT und ihre Umsetzung in generelle unternehmerische Lösungen. Diese Lösungen müssen in Bezug auf Erfolgsfaktoren der Leistungserbringung gesetzt werden, um eine wirkungsvolle Unterstützung der betriebswirtschaftlichen Kernaufgaben durch IS erreichen zu können. Träger dieser Aufgabe sind alle Bereiche und Ebenen der Unternehmensführung. Diese Sicht wurde schon frühzeitig in der Forderung nach einer stärkeren „EDV-Orientierung“ der Betriebswirtschaftslehre geäußert (Scheer 1984). Die konzeptionelle Sicht des IM umfasst die logischen Aspekte aller IS in dem Unternehmen und die Beziehungen der IS untereinander. Sie bezieht sich auf Daten, Funktionen, Aufgabenträger und Kommunikationsbeziehungen. Es handelt sich hier um eine Gesamtsicht, die es erlaubt, Integrationsbereiche zu erkennen. Die sich hieraus ergebenden Aufgaben sind weitgehend in der für IS zuständigen Abteilung angesiedelt (s. Abschn. 4.1.1 zur organisatorischen Eingliederung dieser Abteilung). Die anderen funktionalen Abteilungen bringen ihre Fachkompetenzen ein und entscheiden über ihre Manager über das zu realisierende Portfolio an Anwendungen mit. Die instrumentelle Sicht bezieht sich schließlich auf das Management der Ressourcen zur Implementierung und zum Betrieb der IS. Zu diesen Ressourcen gehören das zuständige Personal, Software und Hardware. Hierein fallen z. B. die Aufgaben der quantitativen und qualitativen Personalbedarfsplanung, die Planung der Weiterbildungsmaßnahmen, die Festlegung der einzusetzenden Hardware und Software, der Abschluss von Rahmenverträgen mit Lieferanten, der Anschluss von Hardware, die Installation von Software, die Konfiguration/Wartung von Hardware und Software, der Betrieb der IS und das IT-­ Sicherheitsmanagement. Die meisten dieser Aufgaben sind ausschließlich in der IT-Abteilung angesiedelt. Einige Teile der Aufgaben werden manchmal in andere Fachabteilungen verlagert, um eine benutzernahe Unterstützung zu gewährleisten. Ebenso ist ein Auslagern (s. Abschn. 4.4.2) an spezialisierte Dienstleister häufig zu beobachten.

3.1.3 Wissensmanagement Entsprechend der Informationsdefinition in Abschn. 1.2 betreibt man mit IM auch Wissensmanagement (WM). Eine gesonderte Betrachtung dieser Aktivität ist jedoch sinnvoll, weil darin alle Anstrengungen eines Unternehmens zusammengefasst werden können, Wissen als eine explizite Unternehmensressource zu betrachten, zu vermehren und erfolgreich einzusetzen. WM steht in enger Beziehung zu Konzepten des organisationalen Lernens und der lernenden Organisation (Senge 1990). Diese gehen davon aus, dass nicht nur Individuen, sondern auch Organisationen als Ganzes lernen können und müssen, um die immer schnelleren Veränderungen der Umwelt bewältigen zu können. WM unterstützt das organisationale Lernen durch einen konkreten Handlungsrahmen. So wie IM muss auch WM in allen Bereichen eines Unternehmens betrieben werden. Die Aktivitäten des WM können wie in Abb. 3.1 zusammengefasst werden.

3.1 Informationsmanagement

49

Abb. 3.1  Bausteine des Wissensmanagements (Probst et al. 2013)

Die Abbildung stellt zwei Kreisläufe dar. Der „äußere Kreislauf“ beinhaltet die Festlegung der Wissensziele, die Umsetzung dieser Ziele und die Bewertung des daraus gewonnenen Wissens. Die Umsetzung der Ziele besteht aus einem „inneren Kreislauf“, der mit der Prüfung des bestehenden Wissens beginnt und mit der Wahrung des evtl. gewonnenen Wissens endet. Die Aktivität der Festlegung von Wissenszielen dient der Verknüpfung des WM mit der allgemeinen strategischen Planung des Unternehmens sowie der Definition von Zielen, die kommunizierbar sind und deren Zielerreichung nachprüfbar ist. Diese Prüfung findet in der Teilaktivität der Wissensbewertung statt, die damit zur Regelung des äußeren Kreislaufs beiträgt. In der Praxis kommt es leider vor, dass zwar messbare Ziele definiert werden, aber deren Erreichung doch nicht zur Erreichung der übergeordneten Unternehmensziele führt. Die Wissensziele sollten deswegen stringent aus Unternehmenszielen abgeleitet sein oder im Zusammenhang mit Geschäftsprozessen definiert werden. Dann kann der Beitrag des WM auch sinnvoll bewertet und gesteuert werden (s. zum methodischen Vorgehen zur Kopplung von Wissenszielen an Geschäftsprozesse (Kalmring 2004)). Der erste Baustein in der Umsetzung der gesetzten Ziele ist die Wissensidentifikation, die einem Unternehmen helfen soll zu erkennen, welche Wissenselemente vorhanden sind und welche fehlen. Danach kann bei Bedarf ein Wissenserwerb betrieben werden, wobei dafür unterschiedlichste Quellen und Bezugsmöglichkeiten existieren (z. B. eigene Kunden, andere Unternehmen, Manager auf Zeit). Die Wissensentwicklung ist ein nur bedingt steuerbarer Prozess. Hier kommt es hauptsächlich auf die Schaffung von geeigneten ­Rahmenbedingungen für Kreativität an. Das kann auf Algorithmen basierende Verfahren wie das beschriebene Data Mining (s. Abschn. 2.3.3.4) beinhalten, aber auch einfach die Teilnahme an bestimmten Fortbildungskursen. Gezielte Wissensverteilung sichert, dass aus individuellem oder Gruppenwissen organisationales Wissen wird. Das bedeutet natürlich nicht, dass alle Mitglieder einer

50

3  Planung und Steuerung des Einsatzes von Informationssystemen

Organisation schließlich über das gleiche Wissen verfügen sollen. Die Bestimmung, wer in einem Unternehmen welches Wissen benötigt, stellt eine schwierige Aufgabe der Wissensverteilung dar. Die Wissensnutzung ist ebenfalls eine Aktivität, die gezielt gefördert werden muss, da Individuen Wissen oft nicht nutzen, selbst wenn sie seine Existenz kennen. Die Schaffung geeigneter Anreizsysteme zur Nutzung fremden Wissens ist eine solche Maßnahme. Die Wissensbewahrung dient schließlich der Sicherstellung, dass das benötigte Wissen auch stets verfügbar ist. Dies beinhaltet auch Entscheidungen und Maßnahmen bezüglich der legalen Vernichtung von Wissen, das den Zwecken des Unternehmens nicht mehr dient. Jeder der Bausteine des WM kann durch IS unterstützt werden, was insbesondere bei der Wissensbewahrung und -verteilung naheliegend erscheint. Das gilt aber auch für andere Bausteine, für die teilweise schon spezielle IS oder zumindest Darstellungsmöglichkeiten entwickelt wurden. So können z. B. die Wissensidentifikation und Wissensnutzung durch die Darstellung verschiedener Wissenskarten (z.  B. durch Wissensquellen-, Wissensträger-, Wissensstruktur- oder Wissensanwendungskarten) unterstützt werden. Nochmals sei betont, dass es sich bei WM um keine Funktion handelt, die nur oder vorwiegend von Mitarbeitern der IT-Abteilung ausgeführt wird. In manchen Unternehmen befindet sich WM nicht in der gleichen Abteilung wie IM. Doch unabhängig davon, wo WM organisatorisch angesiedelt wird, muss es in enger Abstimmung mit dem IM durchgeführt werden.

3.2

Controlling von Informationssystemen

3.2.1 Begriffsbestimmung Um das IS-Controlling einordnen und erläutern zu können, sollte zunächst der Begriff Controlling allgemein definiert werden. Nach anfänglich kontroversen Diskussionen in der Betriebswirtschaftslehre über das Verhältnis von Unternehmensführung und Controlling sowie um die generellen Aufgaben des Controllings liegt mittlerweile eine weit verbreitete Auffassung vor, die auf Weber und Schäffer zurückgeht (Weber und Schäffer 1999, S.  731  ff.). Demnach stellt Controlling eine Unterstützungsfunktion der Führung dar. Konkret wird die „Rationalitätssicherung der Führung als originärer Inhalt und Kern des Controllings“ (Weber und Schäffer 2011, S. 43) angesehen. Unter Rationalität ist eine Mittel-Zweck-Betrachtung zu verstehen, bei der die „herrschende Meinung von Fachleuten“ relevant ist (Weber und Schäffer 2011, S. 45). Wenn auch der Begriff „Rationalitätssicherung“ als nicht praxiskonform zu kritisieren ist, wird hier inhaltlich der von Weber und Schäffer entwickelten Grundidee zur Charakterisierung des Controllings gefolgt. Aufgrund dieser Überlegungen wird das Controlling durch die beiden folgenden Aufgabenklassen, die letztlich der Unterstützung der Führung dienen, definiert: • Gestaltung und Betreuung der Informationsversorgung bei der Planung, Steuerung und Kontrolle (Systemgestaltung), sowie • Durchführung von Planung, Steuerung und Kontrolle (Systemnutzung).

3.2 Controlling von Informationssystemen

51

Systemgestaltung und -nutzung betreffen sowohl die aufbau- und ablauforganisatorischen Strukturen als auch die Eigenschaften von Controllingsystemen als Bestandteil von IS. Damit sind Controllingsysteme als wesentliches Merkmal des Controllings anzusehen (Grob und Bensberg 2009). Beim IS-Controlling ist das Controllingobjekt der IT-Bereich eines Unternehmens, der die Planung, Steuerung und Kontrolle des Hardware- und Softwareeinsatzes sowie die hierbei beteiligten personellen und räumlichen Ressourcen verantwortet. Obwohl inhaltlich beim IS-Controlling das gesamte IS und sein Output (Informationen) im Vordergrund stehen, wird in der Praxis überwiegend von IT-Controlling gesprochen. Dieser sprachlichen Gewohnheit soll auch hier gefolgt werden. Gegenstand des IT-Controllings ist die Planung einer Infrastruktur, durch die das IM mit allen erforderlichen Informationen versorgt wird, um die Wirtschaftlichkeit des IT-Bereichs zu sichern und um Potenziale von IS aufzuspüren. Diese systemgestaltende Aufgabe dient  – wie dargelegt  – der Rationalitätssicherung des IMs, das ggf. mit weiteren Trägern der Unternehmensführung die relevanten Entscheidungen zu treffen hat. Hierbei kann zwischen dem strategischen und dem operativen IT-Controlling differenziert werden. Diese beiden Ausprägungen werden im Folgenden näher erläutert. Da die Koordination von Planung und Kontrolle sowie das Planen und Kontrollieren der IS Bestandteil des IT-Controllings ist, kann es zu institutionellen Konflikten zwischen IM und IT-Controlling kommen, sofern unterschiedliche Organisationseinheiten hierfür zuständig sind, da einerseits die Aktivitäten des IM durch das IT-Controlling geplant und kontrolliert werden, und andererseits Controlling generell ohne ein effizientes IM nicht funktionieren kann.

3.2.2 Strategisches IT-Controlling Das strategische IT-Controlling bezeichnet die Schaffung einer Infrastruktur zur langfristigen Planung und Kontrolle des IT-Bereichs sowie die Koordination und Durchführung dieser Aktivitäten. Dabei hat sich in den letzten Jahren ein Wandel in der Zielsetzung des IT-Controllings vollzogen. Während anfänglich vor allem ein effizientes Kostenmanagement des IT-Bereichs (IT als cost center) im Mittelpunkt der Betrachtung stand, wird heutzutage der gezielte Einsatz der Informationsverarbeitung als Wettbewerbsfaktor verfolgt. Damit decken sich die Aufgaben des strategischen IT-Controllings teilweise mit Aufgaben der IT-Governance (s. Abschn. 3.4).

3.2.2.1 Strategische Informationssysteme Mitte der 80er-Jahre wurde erkannt, dass einige IS für die Unternehmen eine strategische Bedeutung besaßen (s. Abschn. 2.2), die dann als strategische Informationssysteme (SIS) bezeichnet wurden (Wiseman 1988). Eine genaue Definition dessen, was ein „strategisches“ IS ausmacht, wurde nicht erarbeitet. Als Konsequenzen des Einsatzes eines SIS, die allerdings nicht immer gleichzeitig zutreffen müssen, werden genannt: nachhaltige Wettbewerbsvorteile, erhöhte Umstiegskosten (Switching Costs) für Kunden oder Lieferanten, neue oder

52

3  Planung und Steuerung des Einsatzes von Informationssystemen

differenzierte Produkte oder Dienstleistungen, Kostenvorteile gegenüber der Konkurrenz, signifikant höhere Marktanteile und Gewinne. Damit stellen SIS im Sinn der Klassifikation in Abb. 2.2 keine neue Klasse dar; in jedem der dort dargestellten Systembereiche kann ein SIS entstehen und Auswirkungen auf die Branchenstruktur (s. Abschn. 3.2.2.2) haben. Als eines der ersten Beispiele für SIS diente das Reservierungssystem SABRE von American Airlines. Damit konnte die Fluggesellschaft Wettbewerbsvorteile gegenüber der Konkurrenz erzielen. Obwohl die Technologie für solche Systeme ausgereift ist, ist es noch immer nicht einfach, leistungsfähige multifunktionale Reservierungssysteme zu entwickeln. Ein anderes bekanntes Beispiel für den wettbewerbsrelevanten Einsatz von IS ist das System Economost der Firma McKesson für den Pharmahandel. Durch Economost war es möglich, die Automatisierung und den Umsatz erheblich zu steigern. Trotz dieser eindrucksvollen Erfolge und einer industrieweiten Verbesserung der Profitabilität hätte McKesson jedoch weder höhere Marktanteile noch zusätzliche Gewinnmargen gegenüber seinen Konkurrenten erzielt. Das lag u. a. daran, dass die Konkurrenten imstande waren, ähnliche Systeme zu schaffen. Dennoch hatte Economost strategische Bedeutung für McKesson. Ohne Economost hätte die Firma vielleicht nicht überlebt. Auch wäre sie für Verhandlungen mit Pharmaherstellern nicht gerüstet gewesen. Das System stellte für McKesson eine strategische Notwendigkeit (Strategic Necessity) (Clemons und Kimbrough 1986) dar. Ein anderes Beispiel der strategischen Notwendigkeit repräsentieren Geldausgabeautomaten, deren Aufstellung einer Bank kaum Wettbewerbsvorteile einbringt. Würden jedoch keine Automaten zur Verfügung gestellt, entstünden der Bank sicherlich erhebliche Wettbewerbsnachteile. Gleiches gilt für das Betreiben von Webseiten oder Onlineshops. Die Erzielung strategischer Vorteile ist keineswegs nur großen Unternehmen vorbehalten, wie das nachfolgende Beispiel zeigt. Klein, aber wendig

Die Fidor Bank ist ein kleiner, 2003 gegründeter Finanzdienstleister. Fidor besitzt im Gegensatz zu vielen Fintechs (Start-ups im Finanzbereich) eine Banklizenz, sodass sie Kunden vollwertige Konten mit guten Konditionen anbieten kann. Als Direktbank verfügt sie über keine Filialen, sondern nur über stationäre und mobile digitale Zugänge. Kunden können auch Kredite jederzeit schnell und online erhalten (inkl. sog. „Notruf“-Kredite). Für Maestro- und Kreditkartenzahlungen benötigen sie nur eine Karte, die auch eine Paypass-Funktion besitzt. Mit diesen Annehmlichkeiten besitzen sie auch Vorteile gegenüber traditionellen Banken. Die Akquise der Kunden erfolgt über Online Marketing oder Mund-zu-Mund-Propaganda. Fidor bedient auch Geschäftskunden. Als Grundlage für den Erfolg wird die eigene Software gesehen. Diese wird intern von der eigenen Firmentochter entwickelt, die die Hälfte der gesamten Belegschaft von 130 Mitarbeitern ausmacht. Zur Software gehört ein Middle Layer, genannt Fidor Operating System, der an ein Kernbankensystem angeschlossen ist, sowie Anwendungsschnittstellen (APIs) für eigene Anwendungen und Drittanbieter bietet. Dazu gehören bereits die Kreditvergleichsfirma Smava oder Bitcoin.de, der Anbieter für den Handel mit Bitcoins. Damit hat Fidor auch andere Finanzdienstleister als Kunden für ihre Software.

3.2 Controlling von Informationssystemen

53

Interessierten (auch Nicht-Kunden) steht eine Community zur Verfügung, in der über Finanzthemen diskutiert werden kann. Jeder Teilnehmer wird dort aufgrund seiner Aktivität automatisiert bewertet und mit einem „Karma“ versehen. Dieses kann von anderen Teilnehmern berücksichtigt werden, z. B. beim Peer-to-Peer Lending, bei dem Kunden von anderen Kunden Kleinkredite erhalten können. (In Anlehnung an Computerwoche, 25.08.2015, Karin Quack) Während die ersten SIS zunächst meistens „nur“ zur Verbesserung bestehender Abläufe entwickelt wurden und ihre strategische Bedeutung erst im Nachhinein erkannt wurde, begann Mitte der 80er-Jahre eine gezielte Suche nach Systemen, die Wettbewerbsvorteile generieren. Einige Methoden beschreibt der nächste Abschnitt.

3.2.2.2 Methoden der strategischen IS-Planung Die Planung der IS war zunächst relativ kurzfristig orientiert und reagierte hauptsächlich auf bereits geäußerte Benutzeranforderungen. Die Anforderungen wurden kaum antizipiert. Auch wurden Ressourcen häufig erst dann beschafft, wenn die ursprünglich vorhandenen nicht mehr ausreichten. Dadurch war es den IT-Abteilungen selten möglich, die Informationsbedürfnisse rechtzeitig zu befriedigen. Aufgrund dieser Erkenntnisse und mit wachsender Bedeutung der IS wuchs sowohl bei IS-Verantwortlichen als auch beim Topmanagement die Einsicht, dass für IS eine langfristige strategische Planung notwendig ist, die mit der gesamtunternehmerischen strategischen Planung verknüpft ist. Diese Verknüpfung wurde zunächst so verstanden, dass die Strategie für IS aus der Unternehmensstrategie abgeleitet werden sollte. Heute ist man jedoch zu der Erkenntnis gelangt, dass das volle Potenzial der IT nur erreicht werden kann, wenn durch IS gleichzeitig auch die Unternehmensstrategie beeinflusst wird. Aus strategischer Sicht gilt also, Kerngeschäft und IS eng miteinander abzugleichen (Strategic Alignment). Unter verschiedenen Ansätzen zu einer systematischen Suche werden hier nur einige ausgewählte Ansätze dargestellt. Zur Entwicklung von Strategien wird empfohlen, zunächst die Branchenstruktur des Unternehmens zu untersuchen. Zur Analyse dieser Struktur dient das bekannte Fünf-­ Kräfte-­Modell (Porter 1985). In seinem Modell geht Porter von der These aus, dass die Branchenstruktur einen wichtigen Einfluss auf die Unternehmensstrategie ausübt. Folgende fünf Kräfte sieht Porter als wesentlich an. Die zentrale Einflussgröße stellt die Wettbewerbssituation des Unternehmens dar, die durch die Struktur und das Verhalten der aktuellen Mitbewerber determiniert ist (s. Abb. 3.2). Die übrigen vier Kräfte werden in den Bedrohungen durch potentielle (neue) Konkurrenten, in den Beziehungen zu Lieferanten und Kunden sowie in der Beeinflussung des betrachteten Unternehmens durch Substitutionsprodukte gesehen. Bei Lieferanten und Kunden ist insbesondere deren Verhandlungsstärke zu beurteilen. Für neue Konkurrenten sind die Markteintrittsbarrieren zu untersuchen. Substitutionsprodukte sind solche Produkte, die aufgrund ihrer Funktionalität das aktuell angebotene Produkt des Unternehmens ersetzen können.

54

3  Planung und Steuerung des Einsatzes von Informationssystemen

Abb. 3.2  Modell der Wettbewerbskräfte nach (Porter 1980)

Eine offensichtliche Schwäche des Fünf-Kräfte-Modells ist darin zu sehen, dass konkurrierende Ersatzprodukte auch in anderen Branchen entstehen können, sodass nicht nur die eigene Branche untersucht werden sollte, sondern ein „Blick über den Tellerrand“ erforderlich ist. Die Relevanz des Fünf-Kräfte-Modells für Fragestellungen der Wirtschaftsinformatik ergibt sich u. a. aus folgenden Aspekten. Da strategische Entscheidungen für den I­T-­Bereich gerade im Zeitalter der Digitalisierung die Marktposition von Unternehmen sichern und verbessern sollen, ist bei der Formulierung von IS-Strategien eine Branchenstrukturanalyse von grundlegender Bedeutung. Unternehmen der IT-Branche sind besonders intensiv der Bedrohung der Wettbewerbskräfte ausgeliefert. Für einen großen Teil der IS-Produkte existieren offene Standards (z. B. für die Kommunikation von Programmen im Internet), die die Erzielung komparativer Konkurrenzvorteile bzw. den Aufbau von Eintrittsbarrieren für Konkurrenten erschweren. Ein Standard legt Vorgehensweisen fest, die durch Gesetz oder ein Gremium vorgegeben sind. In manchen Fällen bildet sich ein allgemeines Vorgehen in der Praxis aus. Der zweite Ansatz stellt ebenfalls eine Anwendung einer Methode der generellen Strategieplanung dar: die Wertschöpfungskette (Value Chain) nach (Porter 1985). Diese Methode versucht, in der Wertschöpfungskette eines Unternehmens (s. Abb. 3.3) diejenigen Wertaktivitäten zu identifizieren, die noch nicht durch IS angemessen unterstützt werden (Porter und Millar 1985). Dabei kann es zu mehr Integration von Wertaktivitäten, zu Reorganisationen von Geschäftsprozessen oder zur Auslagerung von Aktivitäten kommen. Wenn z. B. die Wertkette eines Herstellers mit der Wertkette einer Handelsorganisation besser integriert wird, indem dem Hersteller Informationen vom Point-of-Sale direkt weitergeleitet und an die Funktionen der Disposition und Lagerversorgung übergeben werden, können nach Praxiserfahrungen 10–15  % der Prozesskosten eingespart werden (Sempf 1996). Die Vorteile kommen sowohl dem Hersteller (z. B. einfachere und sicherere Produktionsplanung, weniger Produktion auf Vorrat) als auch dem Händler (z. B. geringe oder keine Lagerhaltung, einfachere Einkaufsabwicklung, keine Wareneingangsprüfung) zugute (s. auch Abschn. 12.2.2). Den Stellenwert einer durchdachten IT-Strategie verdeutlicht das nachfolgende Beispiel.

3.2 Controlling von Informationssystemen

55

Abb. 3.3  Wertschöpfungskette nach (Porter 1985) Digitale Transformation bei Schindler, einem Industriekonzern

Nach der erfolgreich abgeschlossenen Phase „IT-Rationalisierung“, wurde der Schwerpunkt auf die Erzielung einer weltweiten „Operational Excellence“ gelegt. Zur Erreichung der „Operational Excellence“ hat Schindler die Plattform „Business Process Platform SHAPE (Schindler Harmonized Applications for Process Excellence)“ zur Harmonisierung von Prozessen und Strukturen entwickelt und eingeführt. Darin sind alle operativen und dispositiven Wertschöpfungsprozesse aller Landesgesellschaften und Produktionswerke eingeschlossen. Die nächste Entwicklungsphase hat Schindler „Leading-Edge Digital Business“ benannt. Michael Nilles, CIO der Schindler Gruppe, berichtet: „Hier steht die Transformation mittels enger Verzahnung von Produkt, Technologie, Prozess und Mensch in ein integriertes Eco-System im Vordergrund, um nachhaltiges, profitables Wachstum zu generieren“. Die Digitalisierungsstrategie besteht aus vier Elementen. „Customer Experience“. Das Geschäftsmodell wird auf den Kunden ausgerichtet, der über Customer Portale und Customer Apps (z. B. „MySchindler“) mit ­Informationen versorgt wird. Dazu gehören z. B. Informationen für einen Facility Manager über den Wartungsstatus seiner Anlagen. „Smart Products“. Alle Anlagen sollen mit Connectivity ausgestattet werden, sodass sie relevante Daten an eine „Connectivity Platform“ senden können. Service-Techniker haben darauf Zugang mit ihrem „digitalen Werkzeugkoffer“. Mit Hilfe einer „Big Data Business Rules Engine“ können Vorhersagen über Wartungsfälle berechnet werden. Für mehr als 30.000 Mitarbeiter, die im Feld Services verrichten, wurde in Zusammenarbeit mit Apple Inc. der erwähnte „digitale Werkzeugkoffer“ für iPhones und iPads entwickelt. Damit können sie Service-Aufträge bearbeiten, Fehler analysieren oder Ersatzteile bestellen. „Smart Processes“. Eine Reihe von Algorithmen wurde entwickelt, um Produktivität und Qualität zu erhöhen. Als Beispiel kann ein Algorithmus dienen, mit dem die Routen der Service-Techniker optimiert werden. Die Digitalisierungsstrategie verstärkt ihre Wirkung durch die Abstimmung der vier Elemente miteinander. (In Anlehnung an Handelsblatt, 04.08.2015, Henning Haake)

56

3  Planung und Steuerung des Einsatzes von Informationssystemen

3.2.2.3 Planung der IS-Infrastruktur Die strategische Planung der IS bezieht sich nicht nur auf die Identifikation und Planung von SIS, sie betrifft auch die Planung geeigneter Infrastrukturen. Diese Infrastrukturen beziehen sich auf verschiedene Aspekte oder Sichten der IS, wobei der Aufbau der jeweiligen Infrastruktur auch als Architektur bezeichnet wird (s. Abschn. 1.5). Dabei handelt es sich um Modelle (s. Kap. 9), die eine unterschiedliche Anzahl von idealerweise aufeinander abgestimmten Sichten betrachten. In (Zachman 2008) werden sechs Sichten auf die Architektur von IS unterschieden: Bestände, Prozesse, Verteilung, Verantwortlichkeiten, Zeit und Motivationen. Die Modellierung dieser Aspekte beantwortet die Fragen nach Daten, Funktion, Netzwerk, Personen, Zeit und Motivation. Die Modellierung vollzieht sich in Stufen, die von einem hohen Abstraktionsgrad bis zur konkreten Implementierung von IS reichen. Die Elemente der Sichten sind auf allen Ebenen horizontal integriert. Die strategische Planung bezieht sich nur auf die beiden höchsten Stufen. Darauf geht der zweite Teil des Buches detailliert ein. Das Glossar erläutert einige technische Komponenten (z. B. Hardware oder anwendungsneutrale Software) einer IS-­Architektur.

3.2.3 Operatives IT-Controlling Gegenstand des operativen IT-Controllings ist die Sicherung der Rationalität des für den IT-Bereich zuständigen Managements durch kurzfristige Planung und Kontrolle der Aktivitäten zur Nutzung von IS sowie die dabei notwendige Koordination. Auf der operativen Ebene sind die Vorgaben des strategischen IT-Controllings zu berücksichtigen. Im Einzelnen ergeben sich für das operative IT-Controlling folgende Aufgaben: • • • • •

Transparente Planung, Überwachung und Abrechnung von Kosten und Leistungen, IT-Budgetierung und Kontrolle, operative Koordinierung des IT-Ressourceneinsatzes, Überwachung von IT-Projekten im gesamten Projektverlauf, und Erstellung von Erfahrungsbilanzen und -statistiken sowie Ermittlung von zeit- bzw. projektbezogenen Kennzahlen.

In der Praxis hat sich eine Reihe von Instrumenten für das operative IS-Controlling bereits bewährt. Im Folgenden wird zunächst auf das Monitoring eingegangen, das bedeutsame Leistungsdaten ermittelt. Anschließend ist die Verdichtung zu Kennzahlen kurz zu betrachten. Diese stellen die Grundlage für ein Berichtswesen dar. Schließlich ist auf die IT-Kosten- und Leistungsrechnung einzugehen, die als Bestandteil des internen Rechnungswesens eines Unternehmens zusammen mit der Budgetierung die administrative Grundlage für das operative IT-Controlling darstellt.

3.2.3.1 Monitoring Unter Monitoring wird die Leistungsmessung und -beobachtung in IS verstanden. Es gewinnt Informationen, die für eine bessere Lastenverteilung auf die IS-Ressourcen, für die Ermittlung von Schwachstellen und für die damit verbundene Einleitung von Verbesserungen von

3.2 Controlling von Informationssystemen

57

Programm- oder Datenstrukturen oder für Aufstockungsmaßnahmen herangezogen werden können. Es existieren fünf verschiedene Arten von Monitoring: • Hardware Monitoring. Mittels Sensoren werden die Leistungen der Hardwarekomponenten, wie z. B. der Zentralprozessor (CPU) oder der internen Datenleitungen (s. Glossar), aufgrund physikalisch messbarer Signale erfasst. Eine Zuordnung zu den Anwendungen, die die jeweilige Komponente nutzen, ist durch Hardware Monitoring nicht möglich. • Software Monitoring. Bei zentraler Informationsverarbeitung werden mittels Monitoren für das Betriebssystem (s. Glossar) oder für Anwendungsprogramme Informationen über das Einsatzverhalten dieser Software gewonnen. Bei diesen Monitoren handelt es sich um Programme, die ständig im internen Speicher eines Rechners verbleiben. Ein Betriebssystemmonitor liefert Informationen über die Leistung des zentralen Rechnersystems. Dies sind z. B. die Auslastung des Systems oder der Durchsatz, d. h. die Anzahl von Aufträgen, die in einem bestimmten Zeitintervall bearbeitet werden. Mithilfe der Anwendungsmonitore kann eine Verbindung der gemessenen Leistungsdaten zu den Anwendungen, die den Ressourcenverbrauch verursacht haben, hergestellt werden. Messgrößen sind hierbei z. B. die verbrauchte Zeit der Zentraleinheit (s. Glossar) oder die Anzahl der Dateizugriffe je Benutzer. Bei dezentraler Informationsverarbeitung verfügen die Benutzer über eigene Kapazitäten. Eine Leistungsüberwachung dieser lokalen Ressourcen ist daher aus Sicht der Abteilung i. d. R. nicht erforderlich. Von Interesse kann aber eine Überwachung der auf einem zentralen Dateiserver zur Verfügung gestellten, lizenzierten Anwendungen sein. Eine Zuordnung zwischen diesen Softwareressourcen und den jeweiligen Benutzern kann durch ein Lizenzmanagement erfolgen, das die Anpassung der zu beschaffenden Softwareprodukte an den tatsächlich beobachteten Bedarf fokussiert. • Netzwerk-Monitoring. Durch die Anwendung von Hard- und Software Monitoren kann auch eine Überwachung und Leistungsmessung des Netzwerks erfolgen. Sie können Messgrößen, wie z.  B.  Arbeitslast, Durchsatz, Wartezeit auf die Nutzung einer Ressource sowie die Antwortzeit und die Verfügbarkeit einer Ressource ermitteln. • Datenbank-Monitoring. Das Datenbank-Monitoring überwacht das Datenbankmanagementsystem (s. Glossar). Wichtige Informationen in diesem Zusammenhang sind beispielsweise die Speicherplatzbelegung einer Datenbank, die Zugriffshäufigkeiten auf bestimmte Datenbestände sowie Antwort- oder Wartezeiten bei der Abfrage von Daten. • Accounting. Eine spezielle Form der Ablaufüberwachung von Anwendungsprogrammen ist das Accounting. Als Ziel ist hierbei die kostenmäßige Weiterverrechnung der von Nutzern beanspruchten Systemressourcen anzusehen. Dazu dienen sog. Job-Accounting-Systeme, die mit der IT-Kosten- und Leistungsrechnung verbunden sind.

3.2.3.2 Kennzahlen und Kennzahlensysteme Kennzahlen sind Zahlen, die in verdichteter Form über quantifizierbare Sachverhalte rückwirkend informieren oder diese vorausschauend festlegen. Die wichtigsten Kennzahlen werden als Schlüsselkennzahlen (Key Goal Indicators oder Key Performance Indicators, KPI) bezeichnet. Einzelne Kennzahlen sind hinsichtlich ihrer Aussagekraft begrenzt. Eine Kombination mehrerer Kennzahlen führt zu einem Kennzahlensystem,

58

3  Planung und Steuerung des Einsatzes von Informationssystemen

in dem die einzelnen Kennzahlen in einer sachlich sinnvollen Beziehung zueinander stehen, sich ergänzen und/oder aufeinander aufbauen. Letztlich sind sie auf ein gemeinsames übergeordnetes Ziel ausgerichtet. Bei der Definition von Kennzahlen ist zu beachten, dass mehrere einfließende Größen kompensierend wirken können. Ferner ist bei einem zwischenbetrieblichen Vergleich eine einheitliche Definition der zu vergleichenden Zahlen sicherzustellen (Konsistenzsicherung). Beispielhafte Kennzahlen aus dem IT-Bereich sind: • Durchschnittliche Antwortzeit –– Summe Antwortzeiten/Anzahl Transaktionen • Durchschnittliche Nutzungsdauer –– Summe Nutzungsdauer/Anzahl Programmnutzungen • Relevanz einer Anwendung –– Summe der Aufrufe dieser Anwendung/Anzahl aller Programmaufrufe • Zuverlässigkeit –– Summe fehlerfreier Ausführungen/Summe aller Programmausführungen

3.2.3.3 Berichtswesen Das Berichtswesen dient der Erstellung und Weiterleitung von entscheidungsrelevanten Informationen. Allgemein kann zwischen Standard- und Ausnahmeberichten differenziert werden. Standardberichte werden den jeweiligen Entscheidungsträgern in einheitlicher Form und in regelmäßigen Zeitabständen zur Verfügung gestellt. Ausnahmeberichte werden unverzüglich erstellt, sobald die Toleranzgrenze eines Beobachtungswerts über- oder unterschritten worden ist. In der Darstellung sollte auf diese kritischen Werte fokussiert werden. Bei der Gestaltung von Berichten ist die Kombination unterschiedlicher Darstellungstechniken wie Grafiken, Tabellen, Kennzahlen und verbale Erläuterungen sinnvoll. Im Fall einer dezentralen Informationsverarbeitung können z. B. aus den Daten des Lizenzmanagements Auswertungen zur Analyse der Anwendungen und Benutzer generiert werden, aus denen hervorgeht, welche Anwendungen bzw. PC-Werkzeuge die Organisationseinheiten nutzen. Daraus ist der Stellenwert eines Softwareprodukts innerhalb einer Organisationseinheit ersichtlich. Diese Information wiederum kann z. B. für die Planung von Schulungsmaßnahmen oder bei der Neubeschaffung von Nachfolgeprodukten herangezogen werden. 3.2.3.4 IT-Kosten- und Leistungsrechnung Die Kosten- und Leistungsrechnung für den IT-Bereich dient zum einen der Erfassung und Bewertung des Verbrauchs sowie zur Abbildung, Steuerung und Kontrolle der IT-­ Ressourcen; zum anderen sind die Leistungen des IT-Bereichs abzurechnen. Die Kostenrechnung hat folgende Funktionen zu erfüllen: • Ermittlungsfunktion. Die Kosten der Informationsverarbeitung müssen erhoben werden. • Prognosefunktion. Die wirtschaftlichen Konsequenzen einzelner, die Infrastruktur betreffenden Handlungen müssen vorhergesagt werden können. So sind z. B. die Kosten der einzelnen Phasen eines Softwareentwicklungsprojekts zu prognostizieren.

3.2 Controlling von Informationssystemen

59

• Vorgabefunktion. Für einzelne Objekte des IT-Bereichs (z. B. bestimmte Leistungen) sind in Absprache mit den jeweiligen Verantwortlichen Sollwerte für die entstehenden Kosten vorzugeben. • Kontrollfunktion. Die vorgegebenen Sollwerte gilt es nach Abschluss einer Planungsperiode mit den tatsächlichen Kosten der zu kontrollierenden Objekte zu vergleichen. Im Falle von signifikanten Abweichungen sind die Ursachen zu analysieren. Durch die Erfüllung dieser Funktionen können IT-Leistungen kalkuliert und mit den Preisen von Angeboten Dritter verglichen werden. Des Weiteren kann die Wirtschaftlichkeit einzelner Objekte des IT-Bereichs kontrolliert werden, und die gewonnenen Informationen können zur Entscheidungs- und kurzfristigen Erfolgsrechnung herangezogen werden. Da es sich beim IT-Bereich i. d. R. um einen indirekten Leistungsbereich mit einem hohen Gemeinkostenanteil handelt, und sich betriebliche Abläufe auch in den Prozessen der Informationsverarbeitung widerspiegeln, wird der Einsatz einer Prozesskostenrechnung als sinnvoll erachtet. Hierbei werden die im IT-Bereich stattfindenden Prozesse analysiert und ihre tatsächliche Ressourceninanspruchnahme bewertet.

3.2.3.5 Budgetierung Ein Budget bezeichnet die zusammenfassende und vollständige Darstellung der geplanten und wertmäßigen Gesamttätigkeiten einer Entscheidungseinheit in einer Planungsperiode. Der Prozess der Aufstellung, Verabschiedung, Kontrolle und Abweichungsanalyse von Budgets heißt folglich Budgetierung. Im Rahmen des operativen IT-Controllings ist der IT-Bereich diejenige Entscheidungseinheit, für die ein Budget festgelegt wird. Dieses Budget kann gemäß der Organisation des IT-Bereichs in Teilbudgets untergliedert werden, um eine differenziertere Kontrolle zu ermöglichen. Ein Gliederungskriterium sind die unterschiedlichen Leistungsbereiche im IT-Bereich, wie z. B. laufender Betrieb, Beschaffung von Hardware, Beschaffung von Software, Entwicklung und Wartung von Software sowie Beratung und Service.

3.2.4 Balanced Scorecard als Integrationsinstrument Ein Beispiel für ein Instrument des strategischen und operativen IT-Controllings ist die Balanced Scorecard (s. auch Abschn. 7.4). Die Balanced Scorecard (Kaplan und Norton 1996) ist entwickelt worden, um die Leistung eines Unternehmens über die finanziellen Kennzahlen hinaus zu beobachten und zu steuern. Dabei geht es insbesondere darum, nicht nur die Leistung vergangener Perioden zu messen, sondern auch Größen zu beobachten, deren Entwicklung die zukünftige Entwicklung des Unternehmens beeinflusst. Die Balanced Scorecard soll ein Instrument sein, das sowohl die Umsetzung der operativen wie auch der strategischen Ziele fördert. Zur Klassifikation der Anwendungsbereiche werden Perspektiven formuliert. Zusätzlich zur finanziellen Perspektive gibt es die Kundenperspektive, die Perspektive der internen Geschäftsprozesse sowie die Perspektive des

60

3  Planung und Steuerung des Einsatzes von Informationssystemen

Lernens und des Wachstums. Für jede der vier Perspektiven sollen Kennzahlen definiert werden, mit deren Hilfe das Unternehmen so gesteuert werden kann, dass die Erreichung seiner Ziele über eine ausgeglichene Zielerreichung bei allen Perspektiven erfolgen kann. Dieses Instrument lässt sich an die Ansprüche des IT-Controllings anpassen (van Grembergen und van Bruggen 1998). Tab. 3.1 zeigt die Anwendung der Balanced Scorecard auf die IS-Funktion. Die Vorgabe weiterer Perspektiven (z. B. die Sicherheitsperspektive) ist denkbar. Zu jeder Perspektive sind Kennzahlen zu definieren. Für die in Tab.  3.1 dargestellte Balanced Scorecard für den IT-Bereich kann für die Benutzerperspektive z. B. eine Kennzahl für die Beteiligung der Benutzer bei der Entwicklung neuer Anwendungen entwickelt werden. Die Unternehmensperspektive lässt sich beispielsweise durch den Umsatz mit IS-Dienstleistungen messen. Die Ausführungsperspektive kann u. a. durch die Produktivität der Softwareentwickler und die Zukunftsorientierung durch den Budgetanteil der IS-Ausbildung am Gesamtbudget für IS gekennzeichnet werden. Jedes Unternehmen, das dieses Konzept anwenden möchte, kann es individuell anpassen. Dabei ist vor allem da­ rauf zu achten, dass die Verknüpfung zu den strategischen Zielen des Unternehmens deutlich bleibt, weil die vom Instrument gelieferten Ergebnisse ansonsten keine Beachtung beim Topmanagement finden werden. Dies soll verhindern, dass die Balanced Scorecard ausschließlich für operative Zwecke eingesetzt wird. Tab. 3.1  Balanced Scorecard im IT-Bereich (van Grembergen und van Bruggen 1998 Benutzerorientierung Wie sehen die Benutzer die IT-Abteilung? Auftrag Vorzugslieferant für IS zu sein und optimale Ausnutzung der Geschäftsmöglichkeiten durch IT Ziele • Vorzugslieferant für Anwendungen • Vorzugslieferant für den Betrieb • Partnerschaft mit Benutzern • Benutzerzufriedenheit Ausführungskapazität Wie effektiv und effizient sind die IS-Prozesse? Auftrag effiziente Fertigstellung von IS-Produkten und -Dienstleistungen Ziele • Effiziente Softwareentwicklung • Effizienter Betrieb • Beschaffung von PCs und PC-Software • Problemmanagement • Benutzerausbildung • Management der IS-Mitarbeiter • Benutzung der Kommunikationssoftware

Unternehmensbeitrag Wie sieht das Management die IT-Abteilung? Auftrag Akzeptabler Return von Investitionen in IT Ziele • Kontrolle der IS-Kosten • Verkauf von IS-Produkten und -Dienstleistungen an Dritte • Geschäftswert neuer IS-Projekte • Geschäftswert der IS-Funktion Zukunftsorientierung Ist die IT-Abteilung für zukünftige Herausforderungen gut positioniert? Auftrag Entwicklung der Fähigkeiten, um auf zukünftige Herausforderungen reagieren zu können Ziele • Ständige Ausbildung der IS-Mitarbeiter • Expertise der IS-Mitarbeiter • Alter des Anwendungen-Portfolios • Beobachtung neuer IS-Entwicklungen

3.3 Wertbeitrag von Informationssystemen

3.3

61

Wertbeitrag von Informationssystemen

Unternehmen interessieren sich nicht nur für den Wert einzelner Informationen (s. Abschn. 1.4), sondern auch für den Wertbeitrag ganzer IS und der IT. Sie müssen vor einer Investition in IT-Geräte oder IS, die nicht durch gesetzliche Bestimmungen oder andere Umstände unausweichlich ist, rational entscheiden können, ob sich die Investition betriebswirtschaftlich lohnt. Bei den ersten IS, die hauptsächlich nur manuelle Tätigkeiten automatisierten, war eine traditionelle Kosten-Nutzen-Analyse noch möglich. Bei vielen neuen Systemen ist die Zurechenbarkeit von Kosten und Nutzen zu einzelnen IS fast ­unmöglich. Nehmen wir z. B. an, ein IS soll mithilfe einer neuen Software entwickelt werden, die Mitarbeiter erst erlernen müssen. Sollen diese Lernkosten nur dem zu erstellenden IS zugeordnet oder über alle IS, die diese Technologie in Zukunft benutzen werden, verteilt werden? Wenn sie auch auf zukünftige IS verteilt werden sollen, wie lange soll dies geschehen? Betrachten wir nun ein IS, das dazu dient, bei Kunden die Zufriedenheit mit der Firma und ihren Produkten zu stärken. Wie viel zufriedener sind die Kunden aufgrund dieses Systems und wirkt sich diese Zufriedenheit auch auf die Umsätze positiv aus? Die Schwierigkeit, solche und ähnliche Fragen zu beantworten, führt oft dazu, dass gar nicht erst versucht wird, den wirtschaftlichen Wert von IS zu ermitteln. Ein IS wird häufig als strategisch notwendig deklariert oder es wird behauptet, dass der durch das IS entstehende Nutzen nicht quantifizierbar sei. Die Frage, ob einzelne IS oder die gesamten IS einen positiven wirtschaftlichen Beitrag zum Unternehmenserfolg leisten, wird dann zur Glaubenssache. Lediglich die langfristigen Kostenkonsequenzen werden prognostiziert (Total Cost of Ownership). Dieser Zustand ist nicht befriedigend, denn jede Investition – auch IS-Investitionen  – müssen langfristig einen nachweisbaren positiven Beitrag zum Unternehmenserfolg leisten. Auch dann, wenn ein positiver Beitrag nicht eingetreten ist, sollte dies ein Unternehmen wissen, um daraus zu lernen und um korrektive Schritte ­unternehmen zu können. So ist auch bei institutionalisierten IS deren Wertbeitrag zu prüfen, weil bei schlechter Performanz eine Desinvestition, eine Ersatzinvestition oder Fremdbezug (s. Abschn.  4.4) ratsam sein könnten. Schließlich sind die ökonomischen Auswirkungen der IT auch auf volkswirtschaftlicher Ebene von Interesse. Die komplexen Zusammenhänge des IS-Einsatzes und der Messung ihres Wertbeitrags deutet Abb. 3.4 an. Die Ansätze zur Bestimmung des Wertbeitrags eines IS können dem Modell entsprechend nach verschiedenen Kriterien klassifiziert werden, z.  B. nach der Organisationsebene, auf der ein Verfahren angewendet werden kann, oder der Anzahl von betrachteten Transformationsstufen vom IS-Einsatz bis zur organisationalen Performanz. Ein Kriterium kann auch der generelle Einsatzzweck der Anwendungen sein, dessen Wert gemessen werden soll. Dabei wird zwischen drei Anwendungsgruppen unterschieden (Parker und Benson 1988, S. 102 f.). Substitutive Anwendungen ersetzen die menschliche Arbeitskraft, dazu gehört z.  B. die Lohnbuchhaltung. Zur Berechnung der Wirtschaftlichkeit solcher Systeme können Verfahren der Investitions- und Finanzierungsrechnung (I+F) verwendet werden. Diese Anwendungen werden bezüglich ihrer Bewertbarkeit als „rechenbar“ bezeichnet (Nagel 1990, S. 31).

62

3  Planung und Steuerung des Einsatzes von Informationssystemen

III. Makroökonomische Bedingungen Ländercharakteristika

II. Wettbewerbsumgebung Branchencharakteristika

I. Betrachtete Unternehmung Wertgenerierung durch IS IT-Ressourcen: Technologie & Menschen Komplementäre organisationale Ressourcen

Geschäftsprozesse

Performanz der Geschäftsprozesse

Organisationale Performanz

Ressourcen und Geschäftsprozesse der Geschäftspartner

Abb. 3.4  Modell der Wertgenerierung durch IS (übersetzt aus (Melville et al. 2004))

Komplementäre Anwendungen werden eingesetzt, um die Produktivität und Effektivität ihrer Nutzer bei bestehenden Aktivitäten zu erhöhen; hierzu gehören z. B. Tabellenkalkulationsprogramme. Auch bei dieser Gruppe können Verfahren der Investitions- und Finanzierungsrechnung zur Anwendung kommen, doch ist der Bedarf an Vorhersagen und Schätzungen hier größer als bei substitutiven Anwendungen. Deswegen könnte hierfür der Einsatz eines speziellen Verfahrens, wie z.  B. das hedonistische Modell (im Folgenden erklärt), erwogen werden. Diese Anwendungen werden in Bezug auf die Bewertung als „kalkulierbar“ bezeichnet (Nagel 1990, S. 31). Innovative Anwendungen dienen dazu, Wettbewerbsvorteile zu gewinnen oder zu erhalten. Hierzu gehören z. B. IS, die differenzierte oder neue Produkte oder Dienstleistungen schaffen. Sie führen oft zu Strukturveränderungen ganzer Branchen oder begleiten diese zumindest. Ihre Wirtschaftlichkeit ist schwer zu messen, weil der dem IS zuzuordnende Nutzen aus einem komplexen ökonomischen System isoliert werden muss. Diese ­Anwendungen werden in Hinblick auf die Bewertbarkeit als „entscheidbar“ bezeichnet (Nagel 1990, S. 31). Diese Typisierung ist in der Praxis problematisch, da IS häufig mehrere Einsatzzwecke haben können. So beinhaltet die Einführung der automatischen Textverarbeitung sowohl substitutive als auch komplementäre Effekte. Bei innovativen Anwendungen kann der Wert der IS oft mit ökonometrischen Verfahren berechnet werden, auf die im Folgenden näher eingegangen wird.

3.3 Wertbeitrag von Informationssystemen

63

Wenn die aufbauorganisatorische Dimension als Klassifikationskriterium gewählt wird, stehen verschiedene Vorschläge zur Verfügung (Schumann 1993). Wir berücksichtigen hier auch die Ebene der Volkswirtschaft. Tendenziell gilt: Je höher die Ebene, desto komplexer das Verfahren. Es kann auch notwendig sein, mehrere Verfahren einzusetzen und Ebenen zu analysieren, um ein vollständiges Bild aller Kosten- und Nutzenaspekte zu erhalten. Tab. 3.2 zeigt vier Ebenen mit beispielhaft zugewiesenen spezifischen Verfahren. Der Wert von IS-Investitionen – insbesondere, wenn es sich um bereichsbezogene und damit überschaubare Projekte handelt – sollte mit I+F-Verfahren berechnet werden. Hierzu zählen sowohl klassische statische (einperiodige) als auch dynamische (mehrperiodige) Verfahren. Den klassischen Verfahren liegen formelorientierte Ansätze (z. B. Ermittlung von Kapitalwerten oder Endwerten) zugrunde. Als Alternative zu den klassischen Verfahren wurde mit der vollständigen Finanzplanung ein tabellenorientierter Ansatz entwickelt, der als einfach, aber ausbaufähig zu bezeichnen ist (Grob 2006). Dieser Ansatz wird zur Beurteilung von IS-Investitionen sowohl in der Form des Total-Cost-of-Ownership-Verfahrens als auch eines Verfahrens, bei dem die aus Ein- und Auszahlungen bestehenden Cashflows zu ermitteln sind, in der Praxis zunehmend eingesetzt. Das Verfahren Time-Saving Time-Salary versucht, über die eingesparte und bewertete Zeit der Mitarbeiter den Wert eines IS zu berechnen. Das Verfahren verläuft in fünf Schritten (Schumann 1993): (1) Klassifikation der Mitarbeiter zu Mitarbeitergruppen (z.  B.  Führungskräfte, technische Fachkräfte, Sachbearbeiter), (2) Identifikation von Aufgabenklassen und ihren Zeitanteilen für die Mitarbeitergruppen (z. B. Dokumente erstellen, Schriftgut verwalten), (3) Ermitteln individueller IS-unterstützter Arbeitsinhalte (z. B. Texterfassung, Retrieval), (4) Ableiten und Abschätzen von Einsparungspotenzialen bei den Arbeitsinhalten, und (5) Monetäre Bewertung der Gesamteinsparungen. Das Problem des Verfahrens besteht darin, dass die berechneten Einsparungen aufgrund von Restriktionen (z.  B. arbeitsrechtlicher Natur) nicht unbedingt realisiert werden Tab. 3.2  Verfahren zur Wirtschaftlichkeitsbewertung von IS Aufbauorganisatorische Ebene Arbeitsplatz, Abteilung (bereichsbezogen)

mehrfunktionale Einheiten, z. B. Niederlassungen (bereichsübergreifend) Unternehmen, Unternehmensnetze Branche, Volkswirtschaft

Beispiele für Verfahren Verfahren der Investitions- und Finanzierungsrechnung Time-Saving Time Salary (TSTS) Nutzwertanalyse Hedonistisches Verfahren Analyse von Nutzeffektketten Data Envelopment Analysis Produktivitätsmessung mit Produktions- und Kostenfunktionen Messung der Konsumentenrente

64

3  Planung und Steuerung des Einsatzes von Informationssystemen

­ önnen. Sind etwa die Einsparungen nicht durch Freisetzung der Kapazitäten, sondern k durch Erledigung zusätzlicher Arbeit zu realisieren, geht das Modell davon aus, dass die eingesparte Zeit im selben Verhältnis wie vor dem IS-Einsatz auf die Tätigkeiten aufgewandt wird (Janko et al. 1991). Das Hedonistische Verfahren (Sassone und Schwartz 1986) geht einen Schritt weiter, indem es, vereinfacht zusammengefasst, die durch das betrachtete IS eingesparte Zeit vorwiegend höherwertigen Aktivitäten zuordnet und daraus den zusätzlichen Nutzen berechnet. Dabei berechnet es für die einzelnen Aktivitäten implizite hedonistische Preise unter der Annahme eines effizienten Einsatzes der Ressource Arbeit. Bei der Beurteilung von IS ist regelmäßig eine Vielzahl von Teilzielen zu beachten, die in Form von Kriterien zu fixieren sind. Zur Quantifizierung und Verdichtung dieser Kriterien wird häufig die Nutzwertanalyse (Zangemeister 1976) verwendet. Bei diesem Verfahren werden den vorgegebenen Kriterien Gewichte zugeordnet, die deren Bedeutung für den Entscheidungsträger ausdrücken. Für die Merkmalsausprägungen der Kriterien vergibt das Verfahren für jede der zu untersuchenden Alternativen einen Teilnutzen, z. B. in Form von Schulnoten. Das gewogene arithmetische Mittel sämtlicher Merkmalsausprägungen einer Alternative gibt deren Gesamtnutzen wieder. Wird die Entscheidung im Team vorbereitet, so sind über die Kriterien und Gewichte sowie über die Bewertung der Merkmalsausprägungen Kompromisse zu erarbeiten. Ihre Einfachheit „erkauft“ die Nutzwertanalyse durch einige gravierende Probleme. Hierzu gehört insbesondere die Austauschbarkeit der Teilnutzen. Ein generelles Problem ist in der Gleichbehandlung monetärer und nicht-monetärer Kriterien zu sehen. Zur Erhöhung der Entscheidungstransparenz sollten monetäre Zielwerte (z. B. die Kosten eines IS) nicht in Nutzwerte umgerechnet werden (Grob und Bensberg 2009). Aus dieser Überlegung folgt, dass die Nutzwertanalyse ausschließlich nicht-monetäre Kriterien berücksichtigen sollte. Ein Verfahren, das über mehrere Bereiche und Ebenen einsetzbar ist, sind die Nutzeffektketten. Dieses versucht, alle Auswirkungen des Einsatzes eines IS zu verfolgen, um dadurch ein konzeptionelles Verständnis der Wirkungszusammenhänge zu erreichen. Allerdings lässt der Ansatz die Frage nach der genauen quantitativen Bewertung offen. Abb. 3.5 zeigt ein Beispiel für die Analyse von Nutzeffektketten bei der Einführung einer Computer Aided Design (CAD) Software über zwei Ebenen. Auf der ersten Ebene sind die Effekte an den Arbeitsplätzen im Konstruktionsbereich dargestellt, während die zweite Ebene die Auswirkungen in verschiedenen, nachfolgenden Bereichen zusammenfasst. Die Data Envelopment Analysis (DEA) ist ein Verfahren, das basierend auf Produktionsinputs (z.  B. menschliche Arbeitskraft, Fertigungsanlagen, Grundstücke, Computer) und -outputs (Produkte, Dienstleistungen) betrachteter Entscheidungseinheiten diejenigen Einheiten identifiziert, welche das beste Verhältnis von Outputs zu Inputs aufweisen. Dabei sind keine Annahmen über den funktionalen Zusammenhang zwischen Inputs und Outputs zu treffen, wie dies bei parametrischen, ökonometrischen Verfahren der Fall ist. Auch Preise für die Inputs brauchen nicht im Voraus berechnet zu werden, da durch die Modellrechnungen Schattenpreise ermittelt werden. Als Entscheidungseinheiten kommen

65

3.3 Wertbeitrag von Informationssystemen

Geringere Werkzeugkosten

Geringere Lagerkosten

Geringere Rüstkosten

Höhere Fertigungsqualität

Bessere LagerraumHöherer Reduzierte Weniger nutzung Reduzierte LagerWerkzeuganzahl Rüstvorgänge Fehlerrate umschlag in der Montage Kürzere, Reduzierte störungsfreiere Teilevielfalt Durchlaufzeit in nachfolgenden Bereichen

Weniger Fehlerfolgekosten

Schnelleres Bereitstellen von technischen Angebotsunterlagen

Nachfolgende Funktionen können früher beginnen

Ebene 2 Weniger Konstruktionsfehler

Kürzere Auftragsdurchlaufzeit in der Konstruktion

Höhere Änderungsflexibilität

Standardisierung/ Normierung der Teile

Schnellere Zeichnungserstellung

Kürzerer Entwicklungsprozess

Weniger Zeitaufwand und Kosten für den Prototypbau und Testreihen

Höhere Qualität der Konstruktionsunterlagen

Bessere Produktentwicklung durch Simulation und Berechnung

Ebene 1

Abb. 3.5  Nutzeffektketten eines CAD-Systems (Schumann 1993)

ganze Unternehmen oder ihre relativ autonom operierenden Einheiten infrage, wie z. B. Filialen einer Handelskette oder Zweigstellen einer Bank. Nicht effizient produzierenden Entscheidungseinheiten kann basierend auf effizienten Referenzeinheiten aus ihrer (mathematischen) Nähe aufgezeigt werden, wie sie ihre Effizienz erhöhen können. Wenn Ausgaben für IS oder andere Charakteristika des IS-Einsatzes als ein Inputfaktor in die Analyse eingehen, können die Auswirkungen der IS quantitativ bewertet werden (Alpar und Porembski 1998).

66

3  Planung und Steuerung des Einsatzes von Informationssystemen

Produktions- und Kostenfunktionen sind traditionelle Modelle der Mikroökonomie, um die Produktionstechnologie eines Unternehmens, einer Branche oder einer ­Volkswirtschaft abzubilden. Mit ihrer Hilfe können wichtige Erkenntnisse über das Zusammenspiel der Produktionsfaktoren, die Produktivität, Preiselastizitäten, die Verbundenheit der Produktionsoutputs und über andere ökonomische Aspekte gewonnen werden. Wenn die eingesetzte IT, die sonst in den Produktionsfaktor Kapital eingeht, explizit berücksichtigt wird, kann ihr „wahrer“ Beitrag zu Unternehmenszielen gemessen werden. Wenn in diese Messung die Daten mehrerer Jahre eingehen, werden die Effekte dieser Technologien langfristig transparent gemacht. Die praktische Bedeutung ist evident, da sich der Nutzen großer IS-Investitionen erst nach mehreren Jahren einstellt. Bei adäquater Modellierung können so die Auswirkungen der IS aufgedeckt werden, auch wenn die Ausgaben für sie nur einen kleinen Anteil an den Gesamtausgaben bzw. dem Umsatz ausmachen (s.  Abschn.  2.2). Mit diesen Verfahren kann der gemeinsame Beitrag aller eingesetzten IS und nicht nur der Wert einer einzelnen IS-Investition, gemessen werden (Alpar und Kim 1990). Die Messung der Konsumentenrente ist ein Beispiel für ein Verfahren auf Ebene einer Volkswirtschaft, welches das Problem des Werts von IT von der Nachfrageseite analysiert. Obwohl unter Konsumenten i. d. R. Endverbraucher zu verstehen sind, werden bei diesen Messungen auch Unternehmen berücksichtigt, die diese Technologien als Inputfaktor nachfragen. Die Theorie geht davon aus, dass der Konsument einen Mehrwert (Rente) erhält, wenn er ein Gut billiger kaufen kann, als er dafür zu bezahlen bereit wäre. Da die Preise für Produkte der IT im Laufe der Zeit drastisch gefallen sind, ist ein hoher Mehrwert für die Konsumenten entstanden (Brynjolfsson 1996). Dieser Ansatz ist für das einzelne Unternehmen als Teil einer Volkswirtschaft scheinbar nur indirekt relevant. Jedoch haben die Ergebnisse für die meisten Unternehmen erhebliche Bedeutung, weil die positive Konsumentenrente den Konsumenten Mittel zur Verfügung stellt, die sie wieder für weitere Waren und Dienstleistungen ausgeben können. Andernfalls müssen die Unternehmen Kosten senken oder nach neuen Märkten suchen, um ihre Gewinne zu erhöhen. Weiterhin lassen sich die Verfahren, wie erwähnt, danach unterscheiden, wie viele Transformationsstufen zwischen Inputs und Outputs einbezogen werden. Modelle mit mehr als einer Transformationsstufe versuchen, den Transformationsprozess zumindest teilweise zu erklären. Das kann z. B. bei einem Auftragsbearbeitungssystem heißen, dass auf der ersten Stufe u. a. die mit dem System erzielte höhere Geschwindigkeit und geringere Fehlerhäufigkeit der Auftragsbearbeitung, und auf der zweiten Stufe der daraus resultierende Gewinnbeitrag gemessen wird. Dieses Vorgehen entspricht den beschriebenen Nutzeffektketten, nur dass es die Effekte jeder Stufe quantitativ erfasst. Modelle mit einer Stufe messen „nur“ den Wert des IS. Der Transformationsprozess selbst bleibt dann in der „Blackbox“. Außer Produktionsoutputs oder erbrachten Dienstleistungen verwendet es als abhängige Variable auch Größen wie Produktivität oder Marktanteil. Unabhängig von der Anzahl betrachteter Modellstufen ist es wichtig, dass alle relevanten Faktoren eines Produktionsprozesses erfasst werden. Das ist bei manchen vorgeschlagenen Verfahren und in der Praxis (z. B. bei Kennzahlen) häufig nicht der Fall. Ein oft benutztes Vorgehen setzt das Verhältnis von gesamten IT-Ausgaben zum Gesamtumsatz in Beziehung

3.4 IT- und Data Governance

67

zum Betriebsergebnis, Marktanteil, zur Produktivität oder einer anderen Kennzahl. Dann vergleicht es diese Zahlen über mehrere Perioden oder Unternehmen, um aus einer bestehenden oder fehlenden Beziehung Schlüsse über die Wirtschaftlichkeit und Wirkung des Einsatzes von IS zu ziehen, z. B. (Strassmann 1997). Solche Schlüsse sind in jedem Fall Trugschlüsse, weil sie den Einfluss aller anderen Faktoren neben IS außer Acht lassen (Alpar und Kim 1990) für einen theoretischen und empirischen Methodenvergleich). Während die Bewertung der Wirtschaftlichkeit von IS als Gesamtsystem eines Unternehmens mit erheblichen Problemen verbunden ist, ist die im Rahmen des IT-Controllings durchzuführende Beurteilung von Einzelprojekten regelmäßig als machbar zu bezeichnen. Die Entscheidungsvorbereitung für ein Projekt kann z. B. mit der tabellenorientierten Methode der Investitionsrechnung VOFI vorgenommen werden. VOFI ist ein Akronym des Instruments „vollständiger Finanzplan“ (Grob 2000, 2006). Als besondere Eigenschaften von VOFI im Vergleich zu den klassischen Methoden der Investitionsrechnung (wie z. B. der Kapitalwertmethode) gelten dessen Einfachheit und Ausbaufähigkeit.

3.4

IT- und Data Governance

3.4.1 Bezugsrahmen Mangelnde Transparenz der Unternehmensführung, Verletzungen gesetzlicher Bestimmungen wie auch nicht gesetzeswidrige, aber unverantwortliche Handlungen von Unternehmensleitungen haben in den letzten Jahren zum Wunsch geführt, Regeln für eine gute und verantwortungsbewusste Unternehmensführung vorzuschreiben. cc Corporate Governance  Die Grundsätze der Unternehmensführung, die die Rechte und Pflichten der Unternehmensleitung, Aufsichtsorgane, Anteilseigner und verschiedener anderer am Unternehmen interessierter Gruppen (Stakeholder) bestimmen, werden als Regeln der Corporate Governance bezeichnet. Solche Grundsätze hat z. B. die OECD vorgeschlagen (OECD 2004). Außerdem haben Länder eigene Regelwerke entwickelt, so gilt z. B. in Deutschland der Deutsche Corporate Governance Kodex (2017). Spezifische Regelungen existieren auch für einzelne Branchen. Die Regelwerke enthalten neben gesetzlich bindenden auch freiwillige Vorschriften, sodass jedes Unternehmen aufgerufen ist, für sich spezifische Strukturen und Instrumente zu definieren, die seiner geografischen Präsenz und seiner Branche entsprechen. Es wird erwartet, dass Unternehmen mit guter Corporate Governance nicht nur Vorschriften genauer befolgen, sondern auch mehr Vertrauen genießen und letztlich wirtschaftlich erfolgreicher sind. Das soll schließlich auch für die ganze Volkswirtschaft eines Landes gelten, in dem solche Regelwerke vorgeschrieben sind. Die Regeln beinhalten neben Aussagen über die Organe eines Unternehmens, seine Zusammenarbeit und seine Überwachung auch Vorgaben zur Berichterstattung und zum Umgang mit Risiken.

68

3  Planung und Steuerung des Einsatzes von Informationssystemen

Die Erreichung von Unternehmenszielen unterstützen heute meist IS, deren Betrieb wiederum Risiken birgt. Daher lassen sich aus den Anforderungen der Corporate Governance auch Ziele und Anforderungen für die Entwicklung, Beschaffung und den Betrieb von IS ableiten, die als IT-Governance bezeichnet werden. cc IT-Governance  IT-Governance beinhaltet Regeln und Methoden zur Planung, Steuerung und Kontrolle des Einsatzes von IS in einem Unternehmen, die sicherstellen, dass sie an Unternehmenszielen ausgerichtet sind und unter Beachtung von Risiken effizient und effektiv eingesetzt werden. Damit diese anspruchsvolle Aufgabe planmäßig und nachvollziehbar organisiert und durchgeführt werden kann, sind entsprechende Ansätze entwickelt worden, von denen das Rahmenwerk Control Objectives for Information and Related Technologies (COBIT) die größte Praxisrelevanz aufweist. Dieses Konzept beschreibt der nächste Abschnitt kurz.

3.4.2 COBIT COBIT wurde vom Verband der Prüfer von IS in den USA Mitte der 90er-Jahre entwickelt. Eine Prüfung der IS ist oft als Teil einer Wirtschaftsprüfung notwendig, da Buchhaltung, Bilanzierung und andere gesetzlich geregelte wirtschaftliche Tätigkeiten regelmäßig mit IS durchgeführt werden (s. Kap. 10). Das Rahmenwerk liegt inzwischen in der Version 5 vor. Die nachfolgenden Ausführungen basieren auf der aktuellen Originalversion und der deutschen Übersetzung von COBIT 5.0 (ISACA 2012). Aus der Sicht von COBIT betrifft IT-Governance fünf Bereiche: • Die strategische Ausrichtung (Strategic Alignment) konzentriert sich auf den Abgleich von Unternehmens- und IT-Zielen sowie auf die Festlegung, Beibehaltung und Validierung des Wertbeitrags von IS. • Die Wertschöpfung (Value Delivery) beschäftigt sich mit der Realisierung des Wertbeitrags im Leistungszyklus sowie der Sicherstellung, dass IS den strategisch geplanten Nutzen generieren können und dabei kostenoptimal agieren. • Das Ressourcenmanagement umfasst die Optimierung von Investitionen in IT-­Ressourcen und ein geregeltes Management derselben. IT-Ressourcen sind Anwendungen, Information, Infrastruktur und Personal. Ebenso sollte Wissen optimal eingesetzt werden. • Das Risikomanagement erfordert ein Risikobewusstsein bei der Unternehmensleitung, ein klares Verständnis über die Risikobereitschaft, ein Verständnis für Compliance-­ Erfordernisse, Transparenz über die für das Unternehmen wichtigsten Risiken und die Verankerung des Risikomanagement in der Ablauf- und Aufbauorganisation. • Die Leistungsmessung (Performance Measurement) überwacht die Umsetzung der Strategie und der Projekte, die Verwendung von Ressourcen sowie die Prozess- und Outputperformance. Die Messung geht hierbei über die Anforderungen des Rechnungswesens hinaus.

69

3.4 IT- und Data Governance

Aus der Unternehmensstrategie ergeben sich Unternehmensziele, deren Erreichung IS unterstützen sollen. Deswegen können aus ihnen Ziele für die Informationsverarbeitung abgeleitet werden, die COBIT als IT-Ziele bezeichnet. Tab. 3.3 zeigt beispielhaft einige Unternehmensziele und daraus ableitbare IT-Ziele. Zur Erreichung der IT-Ziele müssen geeignete Prozesse festgelegt und durchgeführt werden. Die aus den Prozessen gewonnenen Informationen müssen bestimmte Qualitätskriterien erfüllen, um den Geschäftsanforderungen zu entsprechen. Diese sog. Informationskriterien sind aus den Anforderungen zur Einhaltung von Gesetzen und abgeschlossenen Verträgen, Sicherheitsbedürfnissen und wirtschaftlichen Erfordernissen abgeleitet. In COBIT werden sieben Informationskriterien für relevant gehalten (s. Tab. 3.4). Die Dimensionen Informationskriterien, IT-Prozesse sowie IT-Ressourcen, mit denen die Prozesse durchgeführt werden, bilden den COBIT-Würfel (s. Abb. 3.6). Während die Informationskriterien unterschiedliche Geschäftsanforderungen darstellen und die IT-­ Ressourcen die involvierten Objekte gruppieren, stellen die Ausprägungen der Dimension IT-Prozesse eine Hierarchie dar. Aktivitäten werden zu Prozessen und Prozesse zu vier Domänen zusammengefasst, die einen Regelkreis bilden. Die IT-Ressource Infrastruktur fasst Hardware, Systemsoftware, Netze, Gebäude u. ä. zusammen. Prozesse dienen der Erreichung der Ziele (Control Objectives), also den Geschäftsanforderungen. Die Prozesse sind auf die Anforderungen unterschiedlich stark ausgerichtet. Bei der intendierten Wirkung ist zwischen primären (P) oder sekundären (S) Einflüssen zu unterscheiden. Den Zusammenhang zwischen Prozessen und Geschäftsanforderungen Tab. 3.3  Beispiele für Unternehmens- und IT-Ziele in COBIT Unternehmensziel Einen guten ROI bei Investitionen in IT-gestützte Geschäftsprozesse erreichen Kunden- und Serviceorientierung erhöhen

Geschäftsprozesse überarbeiten und verbessern

Produkt-/Geschäftsinnovationen entwickeln

IT-Ziel Verbessere die Kosteneffizienz der IT und ihren Beitrag zum Unternehmenserfolg! Stelle die Enduser-Zufriedenheit mit den Serviceangeboten und Service Levels sicher! Stelle die Verfügbarkeit des IT-Services gemäß den Anforderungen sicher! Definiere, wie funktional geschäftliche und Steuerungsanforderungen in wirksame und wirtschaftliche automatisierte Lösungen überführt werden! Beschaffe und unterhalte integrierte und standardisierte Anwendungen! Integriere die Anwendungen und Technologielösungen nahtlos in Geschäftsprozesse! Stelle IT-Agilität her! Setze Projekte pünktlich und im Budgetrahmen unter Einhaltung der Qualitätsstandards um! Stelle sicher, dass die IT eine kosteneffiziente Servicequalität, eine kontinuierliche Verbesserung und Bereitschaft für künftige Veränderungen zeigt!

3  Planung und Steuerung des Einsatzes von Informationssystemen

70

Tab. 3.4  Die Bedeutung von Informationskriterien in COBIT Informations-­ kriterium Effektivität

Effizienz Vertraulichkeit Integrität Verfügbarkeit

Compliance

Verlässlichkeit

Erläuterung Bezieht sich auf die Relevanz und Angemessenheit von Informationen für den Geschäftsprozess und ihre angemessene Bereitstellung bezüglich Zeit, Richtigkeit, Konsistenz und Verwendbarkeit. Bezieht sich auf die Bereitstellung von Informationen unter möglichst wirtschaftlicher Verwendung von Ressourcen. Bezieht sich auf den Schutz von sensiblen Daten vor unberechtigten Zugriffen. Bezieht sich auf die Richtigkeit, Vollständigkeit und Gültigkeit von Informationen in Bezug auf Unternehmenswerte und Erwartungen. Bezieht sich auf die momentane und zukünftige Verfügbarkeit von Informationen für Geschäftsprozesse; sie betrifft auch die Sicherheit der notwendigen Ressourcen. Bezieht sich auf die Einhaltung von Gesetzen, externen und internen Regeln und vertraglichen Vereinbarungen, die von Geschäftsprozessen eingehalten werden müssen. Bezieht sich auf die Bereitstellung geeigneter Informationen, damit das Management die Organisationseinheit führen und seinen Treue- und Governancepflichten nachkommen kann.

Abb. 3.6 COBIT-Würfel

3.4 IT- und Data Governance

71

stellt Tab. 3.5 dar. Wenn weder ein P noch ein S eingetragen sind, besteht ein geringer Einfluss. Ein „X“ kennzeichnet, welche Ressourcen im Prozess zum Einsatz kommen. Tab. 3.5 veranschaulicht Prozesse der Domäne Planung und Organisation (PO). Die erreichte Güte des Prozessmanagements wird mithilfe eines Reifegradmodells ausgedrückt, das ursprünglich im Bereich der Softwareentwicklung entstanden ist (s. Abb. 3.7). Die spezifische Messung der Erreichung von Zielen und Leistungen der Prozesse erfolgt mithilfe von KPI. Jeder Prozess besteht aus Aktivitäten, deren Folge Flussdiagramme darstellen. Rechtecke repräsentieren Aktivitäten und Rauten Entscheidungen. Den Ablauf kennzeichnen gerichtete Kanten. Abb. 3.8 zeigt als Beispiel den Ablauf der Aktivitäten des Prozesses PO1 („definiere einen strategischen IT-Plan“). Tab. 3.5  Zusammenhang zwischen Prozessen, Informationskriterien und Ressourcen für die Domäne „Planung und Organisation“

P

P

Infrastruktur

P

Anwendungen

P

Information

P

Personal

P

Reliability

P

Ressourcen

Compliance

S

Verfügbarkeit

S

Integrität

Effizienz

P

Vertraulichkeit

Effektivität

Informationskriterien

X

X

X

X

X

X

Plane und organisiere PO1

Definiere einen strategischen Plan

PO2

Definiere die Informationsarchitektur

PO3

Bestimme die technische Ausrichtung

PO4

Definiere IT-Prozesse, Organisation und ihre Beziehungen

PO5

Verwalte IT-Investitionen

PO6

Kommuniziere Managementziele und -strategie

S

P

S S

Manage IT-Personal

P

P

PO8

Manage Qualität

P

P

PO9

Erfasse und verwalte IT-Risiken

S

S

PO10

Verwalte Projekte

P

P

X

X

X

X

P

PO7

X

X X

X

X S P

P

P

S

S

X

X

X

X

S

X

X

X

X

X

X

X

72

3  Planung und Steuerung des Einsatzes von Informationssystemen

Abb. 3.7  Modell zur Beurteilung der Reife von Prozessen

Start

Verbinde Geschäftsziele mit IT-Zielen

Analysiere Abhängigkeiten / jetzige Performance

Entwerfe strategischen Plan Überprüfen

Abb. 3.8 Ablaufdiagramm des Prozesses „Definiere einen strategischen IT-Plan“ (angelehnt an (Goltsche 2006, S. 52))

Entwerfe taktischen Plan

Analysiere Programm-Portfolio und verwalte Projekt- und ServicePortfolio

Nein

Richtig? Ja Ende

3.4 IT- und Data Governance

73

3.4.3 Data Governance Der COBIT-Ansatz beinhaltet bereits die Ressource Information (s. Abb.  3.6) und ihre Behandlung (s. z.  B.  Prozess PO8 „Management der Qualität“ in Tab.  3.5). Eigentlich sollte die Ressource Daten statt Informationen heißen (s. Kap. 1). Unabhängig davon hat die Fülle an Daten, die heute Unternehmen zur Verfügung steht, dazu geführt, dass die gezielte Bewirtschaftung dieser Ressource besondere Beachtung erfährt und die Regelungen hierzu als Data Governance bezeichnet werden. cc Data Governance  Data Governance definiert die gewünschte Datenqualität, Maßnahmen zu ihrer Einhaltung und Rollen und Aufgaben der damit beauftragten Personen. Die vorhandene Menge an Daten ermöglicht einerseits die Gewinnung interessanter Erkenntnisse, erschwert aber andererseits auch deren Qualitätsmanagement, weil die Daten oft in unterschiedlichen Informationssystemen vorhanden sind oder durch unternehmensexterne Personen (oder Dinge) generiert werden, ohne dass das Unternehmen darauf Einfluss nehmen kann (z. B. in sozialen Medien, s. Abschn. 5.4). Im Rahmen von Data Governance können folgende Funktionen weitgehend automatisiert werden: • • • • •

Die Erstellung eines Datenkatalogs aller verfügbaren Daten, die Erstellung von Metadaten (Daten über Daten), das Aufzeigen von Beziehungen zwischen Daten, die Überprüfung der Datenqualität, und die Auflösung von Widersprüchen in Daten (z. B. zwei unterschiedliche Adressen eines privaten Kunden) usw.

Viele Softwarewerkzeuge sind in der Lage, die genannten Funktionen über grafische Schnittstellen zur Verfügung zu stellen, so dass sie auch von Benutzern ohne informationstechnische Kenntnisse bedient werden können. Data Governance ist auch für die Einhaltung der gesetzlichen Vorschriften hilfreich. Wenn ein Unternehmen überprüfen möchte, welche personenbezogenen Daten es speichert, um den Vorschriften der Datenschutzgrundverordnung (DSGVO) zu entsprechen, kann es das mit den genannten Funktionen durchführen.

4

Organisation des Einsatzes von Informationssystemen

Zusammenfassung

Dieses Kapitel erörtert wie der Einsatz der Informationstechnologie in einem Unternehmen organisiert und als eine klar definierte Dienstleistung an organisationsinterne und -externe Abnehmer abgegeben werden kann. Danach werden das zunehmend wichtige Management der Sicherheit im Umgang mit Informationssystemen und die Möglichkeiten des Fremdbezugs der genannten Dienstleistungen betrachtet.

4.1

Organisation der IS-Funktion

4.1.1 Betriebliche Einordnung der IS-Funktion Die Praxis verwendet für die Abteilungen, denen die IS-Funktionen zugeordnet sind, verschiedene Bezeichnungen. Hier wird nachfolgend generisch die Bezeichnung IT-­Abteilung verwendet. In den Anfängen des kommerziellen Rechnereinsatzes war die IT-Abteilung häufig als Unterabteilung einer funktionalen Abteilung organisiert. Da die Buchhaltung eine der ersten EDV-Anwendungen war, wurde die IT-Abteilung regelmäßig der Abteilung Rechnungswesen zugeordnet. Nachdem Anwendungen aus anderen funktionalen Bereichen dazukamen, war es nicht mehr gerechtfertigt, eine funktionale Einheit des Unternehmens durch die Zuordnung der Informationsverarbeitung zu ihr zu bevorzugen. Es gab auch die Gefahr, dass Chancen der Automatisierung in anderen Bereichen verkannt würden. Deswegen findet sich in der heutigen Praxis meistens eine der drei folgenden Zuordnungsalternativen der IT-Abteilung.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_4

75

76

4  Organisation des Einsatzes von Informationssystemen

Alternative 1. Die IT-Abteilung stellt eine Hauptabteilung neben anderen funktionalen Abteilungen dar (s. Abb. 4.1). Damit haben alle anderen Abteilungen formal einen gleichrangigen Zugriff auf die Dienste der IT-Abteilung, und die IT-Abteilung bewirbt sich eigenständig um die Ressourcen des Unternehmens. Die IT-Abteilung stellt ihre Dienste i. d. R. den anderen Bereichen in Rechnung. In manchen Fällen haben die anderen Bereiche auch die Möglichkeit, IS-Leistungen von außerhalb des Unternehmens zu beziehen, und die IT-Abteilung kann ihre Leistungen auch unternehmensextern anbieten. Die IT-Abteilung wird dann oft als Profit Center oder auch als rechtlich selbstständige Tochterfirma geführt. Alternative 2. Die IT-Abteilung wird als eine Stabsabteilung der Unternehmensleitung etabliert. Abb. 4.2 stellt dies durch die Anordnung der IT-Abteilung außerhalb der Hierarchie grafisch dar. Diese Anordnung wird aus der Einschätzung heraus gewählt, dass die Informationsverarbeitung zwar wichtig, aber keine primäre Aufgabe des Unternehmens ist. Die Informationsverarbeitung ist vornehmlich eine Unterstützungsfunktion, was die Gefahr birgt, dass manche strategischen Potenziale der IS nicht erkannt werden, weil die IT-Abteilung von anderen Abteilungen nicht als Partner erkannt und in die täglichen Prozesse integriert wird. Durch die gute Anbindung an die Unternehmensleitung hat sie zwar ein großes Durchsetzungsvermögen. Allerdings wird ihr häufig Argwohn aus anderen Abteilungen entgegengebracht. Alternative 3. Bei einem divisionalisierten Unternehmen sind Teile der IT-Abteilung der Zentrale und andere Teile den einzelnen Divisionen (Geschäftsbereichen) zugeordnet. Die Positionierung der Informationsverarbeitung in den Geschäftsbereichen soll die optimale Versorgung dieser Bereiche mit IS-Diensten sicherstellen. Die Bildung der zentralen IT-Abteilung soll die Ausnutzung von Skaleneffekten erleichtern (z.  B. bei Unternehmensleitung

Forschung und Entwicklung

Vertrieb und Marketing

Produktion

Finanz- und Rechnungswesen

Personal

IS

Abb. 4.1  IT-Abteilung als eine Hauptabteilung in der Linie

Unternehmensleitung

IS

Forschung und Entwicklung

Vertrieb und Marketing

Produktion

Abb. 4.2  IT-Abteilung als eine Stabsabteilung

Finanz- und Rechnungswesen

Personal

4.1 Organisation der IS-Funktion

77

Marktbeobachtung und bei der Beschaffung von Hard- und Software) sowie der erforderlichen ­Koordination dienen (z. B. bei technischen Aspekten der Ergebnisberichterstattung der Geschäftsbereiche an die Zentrale). Die Mitarbeiter der IT-Abteilung, oder zumindest ihr Leiter, berichten dann primär an die Leitung ihres Geschäftsbereichs und sekundär an die zentrale Informationsverarbeitung. Diese „doppelte“ Zuordnung kann zu Problemen führen. Abb. 4.3 zeigt, dass die Einordnung der dezentralen Informationsverarbeitung innerhalb der Geschäftsbereiche sowohl in der Linie als auch in Form einer Stabsabteilung geschehen kann. Die Idee, dass die IS-Mitarbeiter möglichst viel von den Produkten und Funktionen verstehen, die sie unterstützen, führt auch dazu, dass IS-Experten manchmal anderen fachlichen Abteilungen zugeordnet werden. So können z.  B. bei einer produktorientierten Unternehmensorganisation den Managern für Produktgruppen IS-Mitarbeiter unterstellt werden. Da die Ressourcen der IT-Abteilung regelmäßig knapp sind, besteht zwischen den Fachabteilungen ein Konkurrenzkampf um diese Ressourcen. Um die Zuordnung dieser Ressourcen aus Unternehmenssicht optimal vornehmen zu können, entscheidet oft ein Komitee über die Priorisierung der Anforderungen der Fachabteilungen (Steering Committee). Diese Arbeitsgruppe setzt sich dann aus leitenden Angestellten der Fach- und der IT-Abteilungen zusammen.

4.1.2 Innere Organisation der IT-Abteilung Die Gliederung der IT-Abteilung kann nach verschiedenen Kriterien erfolgen. Dazu zählen beispielsweise: Status der IS (z.  B.  Entwicklung, Wartung, Betrieb), funktionaler Zweck (z. B. Produktion, Marketing, Finanzen), Geschäftsbereiche, Rechnerplattformen

Unternehmensleitung

IS

Leitung GB2

Leitung GB1

IS IS GB=Geschäftsbereich

Abb. 4.3  Organisation der IT in einer divisionalisierten Unternehmen

78

4  Organisation des Einsatzes von Informationssystemen

(z. B. Großrechner, Arbeitsplatzrechner), sowie Art der IS (z. B. ERP). Es sollten ­diejenigen Gliederungskriterien gewählt werden, die den jeweiligen Bedürfnissen nach spezifischen Kenntnissen am besten entsprechen (Picot 1990). Ein Unternehmen, das die fachliche Spezifität der Anwendungen kritischer als die technische Spezifität der eingesetzten Hardware und Software einschätzt, sollte einer Organisation nach betrieblichen Funktionen oder nach Geschäftsbereichen den Vorzug geben. Im umgekehrten Fall sollte der Vorzug einer organisatorischen Strukturierung nach Plattformen, Art oder Status der Systeme gegeben werden. Je größer die IT-Abteilung ist, desto mehr dieser möglichen Organisationskriterien kommen i. d. R. gleichzeitig zur Anwendung. Aufgrund der Tatsache, dass seit Anfang der 80er-Jahre die Anwender einen Teil der Datenverarbeitung selbst durchführen, gibt es innerhalb der IT-Abteilung auch Organisationseinheiten, die sich speziell um die Unterstützung der unmittelbaren Benutzer der IS bei ihrer (individuellen) Datenverarbeitung kümmern. Eine solche Einheit bezeichnet man oft als Information Center (IC). Die Mitarbeiter eines IC helfen den Benutzern bei der Nutzung von Programmen, wie z. B. bei Werkzeugen für Textverarbeitung und Tabellenkalkulation. Eine Datenverarbeitung, die nicht unter der (direkten) Kontrolle der zentralen IT-­ Abteilung stattfindet, gilt als dezentrale Datenverarbeitung. Die IT-Abteilung übt darüber eine indirekte Kontrolle aus, indem sie z. B. den Zugang zu zentralen Datenbeständen regelt oder Richtlinien für die Anschaffung von Soft- und Hardware ausgibt. Die Rolle der dezentralen Datenverarbeitung und damit die dafür aufgewendeten Budgets sind in den letzten Jahren stark gewachsen; es wird geschätzt, dass ca. zwei Drittel der IS-Gesamtausgaben für die dezentrale Datenverarbeitung anfallen. Die Position und die Bezeichnung des IT-Leiters spielt eine nicht zu unterschätzende Rolle für die wahrgenommene und die tatsächliche Bedeutung der IS in einem Unternehmen. Je höher der Leiter in der Hierarchie angesiedelt ist, desto besser sind die Bedingungen, dass die IS die Unternehmensziele optimal unterstützen können. Die IT-Abteilung kann sich dann nicht nur an die Gesamtstrategie des Unternehmens anpassen, sondern auch zur Entwicklung dieser Strategie beitragen. Für Großunternehmen bedeutet das, dass der Leiter der IT-Abteilung Mitglied des Vorstands sein sollte. In Anlehnung an die ­Bezeichnung anderer Vorstandsmitglieder wurde in den USA dafür die Bezeichnung Chief Information Officer (CIO) oder neuerdings die Bezeichnung Chief Digitalization Officer (CDO) eingeführt. Es sei angemerkt, dass die Vergabe dieses oder eines anderen wichtig klingenden Titels wenig bewirkt, wenn der Titelträger nicht auch Mitglied des Vorstands ist. Abb. 4.4 zeigt die grobe aufbauorganisatorische Verankerung der IS in einer Bank. Der Hauptverantwortliche für die zentral organisierte Funktion, hier Chief Information Technology Officer (CITO) genannt, ist Mitglied des Vorstands. Eine Stabsabteilung (CITO Office) unterstützt ihn u.  a. bei Standards und Richtlinien, Budgetplanung und -kontrolle des IT-Projekt- und -Produktportfolios, der Optimierung IT-interner Prozesse und Fragen der

4.1 Organisation der IS-Funktion

79

Abb. 4.4  Interne Organisation der IS-Funktion einer Bank

Informationssicherheit und des Datenschutzes. Die Fachabteilungen sind hier nach Softwarekomponenten zusammengefasst. Sie sind nicht Geschäftsbereichen untergeordnet, deren Systeme sie hauptsächlich betreuen, sondern haben designierte Partner im höheren Management der Geschäftsbereiche, um eine optimale Zusammenarbeit ­sicherzustellen. Die Abteilung Vertriebssysteme unterstützt den Produktvertrieb der Bank über die strategischen Vertriebs- und Zugangswege und dient als IS-Schnittstelle für das Privatkundengeschäft, während Produkte die IS-Produkte verantwortet und als IS-Schnittstelle für das Firmenkundengeschäft fungiert. Die Abteilung Corporate-Service-Systeme entwickelt oder implementiert Systeme für bankinterne Nutzer (z. B. Personal- oder Controllingsysteme). Banksysteme wie etwa Buchungssysteme, die für jede Art von Bankgeschäft benötigt werden, sind in der Abteilung Transaktions- und Kernsysteme konzentriert. Diese Abteilung dient als zentrale Serviceeinheit. Betrieb und Wartung der IS-Infrastruktur erbringen dabei externe Dienstleister. Abb. 4.5 zeigt die aufbauorganisatorische Verankerung der IS in einem Industrieunternehmen, in welchem der ranghöchste IT-Manager kein Mitglied der Geschäftsleitung ist. Die Aufteilung der Funktionen in die drei Bereiche beschreiben folgende Begriffe: • Anwendungen („Informationsverarbeitung“), • Systemsoftware und Produktivitätswerkzeuge („Informationstechnik“), und • Hardware und Betrieb („Rechenzentrum“). Die Abteilung „Informationsverarbeitung“ ist sowohl für betriebswirtschaftliche Anwendungen (z. B. Vertrieb) als auch für technische Anwendungen (z. B. Computer Aided Design) verantwortlich. International tätige Unternehmen verfügen oft über regionale oder nationale IT-­ Abteilungen. Die Leiter dieser Abteilungen berichten meist an den Gesamtleiter der regionalen Organisation (z. B. an den Country Manager) und haben einen sekundären Berichtsweg zum globalen CIO (Dotted-Line-Prinzip).

80

4  Organisation des Einsatzes von Informationssystemen

Abb. 4.5  Interne Organisation der IS-Funktion in einem Industrieunternehmen

4.2

IT-Servicemanagement mit Hilfe von ITIL

4.2.1 ITIL Die Ergebnisse der Arbeit von Mitarbeitern, die IS entwickeln, betreiben oder warten, schlagen sich bei den Benutzern von IS als Dienstleistungen nieder. Damit diese Dienstleistungen sinnvoll geplant und eingesetzt werden, bedarf es eines IT-­Servicemanagements. Über die Jahre haben sich dabei verschiedene Praktiken bewährt, die zu ganzheitlichen Ansätzen entwickelt wurden. Der bekannteste Ansatz in diesem Bereich ist die Information Technology Infrastructure Library (ITIL). ITIL hat gewisse Überschneidungen mit COBIT (s. Abschn. 3.4.2). Die Konzepte werden durchaus mit COBIT zusammen eingesetzt, wobei ITIL die spezifische Ausgestaltung der von COBIT nicht konkret benannten Serviceaufgaben übernimmt. In ITIL wurden bewährte Vorgehensweisen (Best Practices) in Form von Büchern (Library, Bibliothek) durch eine britische Regierungsorganisation gesammelt,

4.2 IT-Servicemanagement mit Hilfe von ITIL

81

die heute Office of Government Commerce (OCG) heißt (Olbrich 2006). Die Inhalte beziehen sich dabei vorwiegend darauf, was gemacht werden soll und nicht wie die Aufgabe auszuführen ist. Die hier verwendete ITIL-Definition eines Service ist sehr offen. Eine umfassendere, stärker fachorientierte Auseinandersetzung mit dem Begriff erfolgt in Abschn. 9.3. cc Service  Ein Service ist eine Dienstleistung, deren Erbringung dem Serviceempfänger einen Nutzen stiftet. Dafür hält der Leistungserbringer die notwendigen Betriebsmittel und das Know-how vor und trägt die entsprechenden Kosten und Risiken (in Anlehnung an (Böttcher 2010, S. 9)). In der noch aktuellen Version, ITIL V3, sind die wichtigsten Aspekte in fünf Hauptbüchern organsiert, je eines für jeden Kernbereich (ITSMF 2012). Die darin enthaltenen Aufgaben und Prozesse sind in Ebenen angeordnet, die von der Strategie bis zur Ausführung führen (s. Abb. 4.6). Die kontinuierliche Bewertung und Verbesserung der Prozesse (Continual Service Improvement, links in Abb. 4.6) stellt eine Rückkopplung dar, sodass die fünf Bereiche zusammen einen Servicelebenszyklus repräsentieren. Die Tätigkeiten auf den einzelnen Ebenen verdeutlicht eine Kurzbeschreibung der darin enthaltenen Prozesse.

4.2.2 Service Strategy Auf der Ebene der Dienstleistungsstrategie fallen folgende Aufgaben an: Strategy Generation. Die Entwicklung der Strategie muss auf einer eingehenden Analyse der Benutzerbedürfnisse basieren, damit der Anbieter bestimmen kann, was er wann und an wen liefern kann und will. Ebenso ist frühzeitig zu bestimmen, wie die Strategy

Continual Service Improvement

Strategy Generation Financial Management

Service Portfolio Management

Demand Management

Service Design Capacity Management Availability Management

IT Service Continuity Management

Service Level Management

Service Catalogue Management

Information Security Mgmt

Supplier Management

Service Transition Transition Planning and Support Service Asset & Config. Management

Service Validation and Testing

Evaluation

Change Management

Release and Deployment Mgmt

Knowledge Management

Service Operation Event Management Request Fulfilment

Problem Management

Incident Management

Abb. 4.6  Kernbereiche und Prozesse in ITIL V3

Access Management

82

4  Organisation des Einsatzes von Informationssystemen

Performance der Leistungen zu messen und der erbrachte Wert für die Nutzer zu bewerten ist. Dabei sollte auch berücksichtigt werden, dass Nutzer die Wahl zwischen verschiedenen Anbietern haben möchten. Financial Management. Wirtschaftliches Handeln in der IS-Organisation ermöglicht das Financial Management. Eine nachvollziehbare Aufstellung von Kosten und Leistungen für IS-Dienste sind die Voraussetzung für sinnvolle Service-Vereinbarungen mit den Kunden. Service Portfolio Management. Bestandteil dieses Prozesses ist die Bestimmung der aktuell und der in Zukunft angebotenen Leistungen. Leistungen, die nicht mehr ökonomisch sinnvoll angeboten werden können, sollten möglichst aus dem Portfolio eliminiert werden. Die Nutzer können sie eventuell von anderen Anbietern beziehen. Demand Management. Die Nachfrage der Benutzer nach Leistungen sollte vom Anbieter geplant und nach Möglichkeit gesteuert werden, damit die Kapazitäten kontinuierlich ausgelastet werden, und Einschränkungen in der Qualität oder Verfügbarkeit der Leistungen nicht auftreten. Aus jeder der nachfolgenden drei Ebenen aus Abb. 4.6 werden exemplarisch drei Aufgaben erläutert.

4.2.3 Service Design Der Entwurf von Dienstleistungen beinhaltet u. a. folgende Prozesse: Service Level Management. Der Prozess des Service Level Managements ist bei ITIL von zentraler Bedeutung und organisatorisch mit allen Prozessen verflochten. Er steuert die Servicevereinbarungen (Service Level Agreement, SLA) und kontrolliert die Qualität der erbrachten Leistungen. SLAs legen dabei Ziele und Messgrößen für den IS-Service fest, sorgen für eine transparente Leistungsfähigkeit der IT-Organisation und erzielen ein ausgewogenes Verhältnis zwischen Kundenanforderungen und den Kosten der Services. Capacity Management. Heutige und zukünftige Anforderungen an den Umfang und die Leistungsfähigkeit der IS-Ressourcen werden im Prozess des Kapazitätsmanagements erfasst. Hier werden die benötigten und kostenmäßig vertretbaren Kapazitäten der IS-Ressourcen ermittelt, um die vereinbarten Serviceleistungen termingerecht und in vollem Umfang erfüllen zu können. Availability Management. Die Abhängigkeit vieler Unternehmensprozesse von IS verlangt eine hohe Zuverlässigkeit der entsprechenden Systeme. Ziel des Availability Managements ist es, die mit dem Kunden vereinbarten Verfügbarkeiten der IS zu gewährleisten. Zur Überprüfung der Einhaltung von SLAs werden Verfügbarkeitsdaten der IS-Komponenten gesammelt und ausgewertet. In der Tabelle im nachfolgenden Beispiel ist die Vereinbarung des Dienstes zur Authentifizierung von Benutzern der IS an der Technischen Universität München mit dem Bayerischen Landesrechnungszentrum als Dienstleister dargestellt.

4.2 IT-Servicemanagement mit Hilfe von ITIL

83

Beispiel der Definition eines Service in ITIL Serviceklasse Betriebszeiten Support-Sprachen Störungsannahmezeit Onlinezeiten Verfügbarkeit Reaktionszeiten Problemlösungszeiten Lösungsrate Ausnahmebedingungen

Gold Montag–Sonntag 0:00–24:00 Es werden folgende Sprachen unterstützt: 1. Deutsch, English Montag–Sonntag 0:00–24:00 24 Stunden x 7 Tagen größer als 99,9 % 09:00–17:00 weniger als 15 Minuten 17:00–24:00 weniger als 16 Stunden 09:00–17:00 weniger als 1 Stunde 17:00–24:00 weniger als 17 Stunden 100 % Höhere Gewalt

Aus (Nguyen 2009, S. 18)

4.2.4 Service Transition Die Inbetriebnahme der Dienstleistungen besteht aus sieben Prozessen, darunter: Change Management. Mithilfe des Change Managements sollen effiziente, kostengünstige und termingerechte Veränderungen im IS-Umfeld mit kontrolliertem Risiko für die bestehende IS-Infrastruktur koordiniert und durchgeführt werden. Der Service Desk (Kundendienstbüro) ist die zentrale Stelle, an die sich Anwender mit Fragen und Wünschen bzgl. zugesagter Services wenden können. Im Kontext des Change Management kann ein Service Desk Informationen über Status und Verlauf der Änderungen geben. Release Management. Prüfung, Freigabe und Einführung neuer Hardware- und Softwarekomponenten erfolgen im Prozess des Release Managements. Dazu werden Releases geplant und gestaltet, notwendige Tests durchgeführt, die Einführung geplant und die betroffenen Anwender informiert und geschult. Service Asset und Configuration Management. Alle IS-Objekte werden zur Überwachung und Pflege eindeutig identifizierbar in einer Datenbank (Configuration Management Database, CMDB) gespeichert. Die Statusüberwachung der einzelnen Objekte lässt erkennen, bei welcher Stelle die Verantwortlichkeit für sie liegt und wie sie eingesetzt werden können.

84

4  Organisation des Einsatzes von Informationssystemen

4.2.5 Service Operation Zum Dienstleistungsbetrieb gehören z. B.: Incident Management. Meldungen über Störungen (Incidents), Servicebeeinträchtigungen und -beschwerden nimmt ein Service Desk entgegen und leitet diese an das Incident Management weiter. Dort werden die Störungen mit dem vorrangigen Ziel der schnellstmöglichen Wiederherstellung der gestörten Funktionen diagnostiziert und klassifiziert. Dieser Prozess stellt die Schnittstelle zwischen der IS-Organisation und den Anwendern dar. Problem Management. Ziel des Problem Managements ist die mittel- bis langfristige Reduktion der Anzahl der Störungen durch systematische Fehlersuche und -beseitigung. Request Fulfillment. Dieser Aufgabenbereich nimmt vorgesehene Serviceaufträge (Service Requests) der Anwender entgegen, prüft und stößt die Ausführung der Aufträge an und rechnet diese nach erfolgreicher Ausführung ab.

4.2.6 Continual Service Improvement Die kontinuierliche Verbesserung der Prozesse erfolgt in sieben Stufen (s. Abb. 4.7). Sie dienen dem Messen und Bewerten der erbrachten Leistungen, der Ableitung von Verbesserungsmöglichkeiten und ihrer Umsetzung. Wenn eine Organisation viele Dienstleister hat, wird das Management der Diensterbringung komplizierter und bedarf spezieller Lösungen, wie im nachfolgenden Beispiel erläutert.

Vision Strategie Zielwerte Korrekturmaßnahmen

Aufbereitung der Analyseergebnisse

Bestimmungsgröben der Servicequalität

Messung der Servicequalität

Ziele

Datenanalyse und -auswertung

Datenerhebung

Aufbereitung von Daten

Abb. 4.7  Kontinuierliche Verbesserung in sieben Stufen (Böttcher 2010)

4.3 Datensicherheit und Datenschutz

85

Siemens entwickelt IT-Servicemanagement weiter

IT-Servicemanagement wird auch bei Siemens mit ITIL betrieben. Die Siemens-IT spezifiziert was benötigt wird, während sich die Dienstleister um die Ausführung kümmern. Bei ca. einem Dutzend externen Dienstleistern im Bereich der IT reicht ITIL jedoch nicht aus. Matthias Egelhaaf, der zuständige Program Director der Siemens AG, erklärt: „Es fehlt eine Integrationsschicht, die mir im Fall eines Problems hilft zu erkennen, wo es entstanden ist und wer daran arbeitet. Andernfalls wird der Schwarze Peter zwischen den Providern immer weitergereicht.“ Diese Integrationsschicht hat Siemens selbst entwickelt. Auf diese Weise können Siemens-Manager immer verfolgen, wie die externen Dienste gerade laufen. Für die Endbenutzer wurde das Serviceportal „myIT“ entwickelt, in dem sie Standardartikel bestellen oder Support Tickets einstellen können. Die Anwender können sogar Cloud Services direkt bestellen, wenn diese vorher prinzipiell von der IT genehmigt wurden. Die Siemens-IT verwaltet danach die Prozesse mit den Providern von „Ende-zu-Ende“. Für die internen Entwickler und externe Service Provider wurde ebenfalls ein Portal entwickelt, in dem die ITIL-Prozesse (z. B. Incident Management) verwaltet werden. Beide Gruppen können ihre Prozesse damit über standardisierte Schnittstellen verknüpfen. Egelhaaf sagt: „Wir können auf Knopfdruck sehen, inwieweit die SLAs erfüllt sind.“ myIT kann bereits von 178.000 Mitarbeitern genutzt werden, was bis Ende 2016 auf 260.000 erhöht werden soll. Egelhaaf hat den Leitsatz: „Unser Anspruch ist: Es muss einfacher sein, direkt im Portal zu bestellen, als der Assistenz zu sagen, sie soll es tun“. Die erzielten Vorteile bestehen aus Prozessverbesserungen, Ablösung nicht benötigter Werkzeuge und mehr Wettbewerb der Dienstleister bei Ausschreibungen. (In Anlehnung an Computerwoche, 25.02.2016, Karin Quack) ITIL selbst ist nicht durch eine Standardisierungsorganisation normiert worden. Indes wurde auf seiner Basis zuerst der britische Standard BS 15000 und daraus die Norm ISO 20000 für IT-Servicemanagement entwickelt, nach der sich Unternehmen zertifizieren lassen können. Ein weiterer Bereich von ITIL, der eng mit dem IT-Servicemanagement verbunden ist, und dessen Teile auch in den einzelnen Bereichen des IT-Servicemanagements berücksichtigt werden, ist das IT-Sicherheitsmanagement. Da ITIL IT-Sicherheitsmanagement jedoch nicht detailliert betrachtet, behandelt es der nächste Abschnitt anhand eines spezifischen Ansatzes.

4.3

Datensicherheit und Datenschutz

4.3.1 Gegenstand der Sicherheitsbemühungen Das Management der Sicherheit von Ressourcen der IT zählt zu denjenigen Aufgaben des IM, die in den letzten Jahren an Bedeutung und Komplexität gewonnen haben. Das liegt einerseits an der zunehmenden Digitalisierung aller Geschäftsprozesse und an der

86

4  Organisation des Einsatzes von Informationssystemen

Öffnung der früher nur intern genutzten IS für Lieferanten, Kunden und andere Interessengruppen. Andererseits wurden Gesetze und Bestimmungen verabschiedet, die Unternehmen zu mehr Sicherheit in der Nutzung von IS verpflichten. So verlangt die DSGVO (s. Abschn. 4.3.3) den Schutz der in Organisationen gespeicherten und verarbeiteten persönlichen Daten. Darüber muss u. a. auch ein Datenschutzbeauftragter wachen. Die Buchführung muss die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD) beachten. Diese schreiben eine genaue Dokumentationspflicht des eingesetzten Systems und die Aufbewahrung originär digitaler Daten in maschinell auswertbarer Form vor, sodass das Finanzamt bei Bedarf die Daten bei buchführungspflichtigen Steuerzahlern elektronisch auswerten kann. Seit Mitte 2015 ist das Gesetz zur Erhöhung der Sicherheit informationstechnischer Systeme (IT-­Sicherheitsgesetz) in Kraft, das vor allem Betreiber von öffentlichen Telekommunikationsnetzen, Webseiten und kritischen Infrastrukturen zur Absicherung der IT und zur Meldung von Sicherheitsvorfällen verpflichtet. Auch eine 2015 erlassene europäische Verordnung zur IT-Sicherheit ist in den kommenden Jahren in nationales Recht umzusetzen. Das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) betrifft den Vorstand von Aktiengesellschaften und die Geschäftsleitung großer GmbHs. Es verpflichtet Leitungsorgane, geeignete Prozesse zur Unternehmenssicherung, inklusive der Sicherheit der IS, zu etablieren. Bei Verstößen können sie persönlich haftbar gemacht werden. Für in den USA operierende Aktiengesellschaften ergeben sich ähnliche Konsequenzen aus dem Sarbanes-­Oxley-­Gesetz. Andere Bestimmungen lassen wirtschaftliche Sachzwänge entstehen, die Unternehmen zur erhöhten Sicherheit bezüglich ihrer IS und der zugehörigen Prozesse veranlassen. Ein Beispiel hierfür ist die 2007 in Kraft getretene Vereinbarung für Internationale Konvergenz der Kapitalmessung und Eigenkapitalanforderungen (besser bekannt als Basel II), die Entscheidungen über die Kreditvergabe von Banken standardisiert. Weitere Regelungen (Basel III) sind bereits beschlossen und werden seit 2014 stufenweise eingeführt. Dabei ist die individuelle Wahrscheinlichkeit eines Kreditausfalls zu berücksichtigen. Um diese zu bestimmen, beziehen die Banken quantitative sowie qualitative Faktoren des Kreditnehmers in die Bewertung ein. Die Sicherheit der IS stellt dabei einen wichtigen Faktor im Bereich operationaler Risiken dar. Die genaue Auswahl und Gewichtung der in das Rating einbezogenen Faktoren kann dabei zwischen den Kreditinstituten variieren. In jedem Fall führt mangelnde Sicherheit der IS zu einer Verschlechterung des Ratings und damit zu höheren Kreditkosten. Ähnliches gilt beim Abschluss von Versicherungen, da Versicherungsgesellschaften über Solvency II zu einer genaueren Steuerung und Kontrolle der Risiken aus ihrer Tätigkeit angehalten sind (Gründl und Perlet 2005). Zu den schützenden Ressourcen zählen Daten, Programme, Hardware und Netze. Sie sind einer Reihe von Bedrohungen ausgesetzt, die frühzeitig erkannt werden müssen. Die Aufgabe des Sicherheitsmanagements (Security Management) besteht darin, die Schadensfälle nach Möglichkeit zu verhindern und auf Vorfälle zur Beeinträchtigung der Sicherheit vorbereitet zu sein. Das geschieht mithilfe vielfältiger technischer und organisatorischer Maßnahmen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI)

4.3 Datensicherheit und Datenschutz

87

unterteilt die Gefahren, Ressourcen und Vorgehensweisen in seinem IT-Grundschutz-­ Kompendium – Edition 2018 in folgende vier Gruppen (BSI 2018a): • Elementare Gefährdungen (Feuer, Wasser, Diebstahl von Ressourcen, fehlerhafte Nutzung von Ressourcen, Schadprogramme usw.), • Bausteine (Organisation und Personal, Anwendungen, Netze und Kommunikation usw.), • Umsetzungshinweise (für jeden Baustein), und • Anleitung zur Migration (von der alten Version des BSI-Standards). Die Bausteine beinhalten zunächst nur einen Teil der in früheren Versionen erfassten Bausteine und werden zügig ergänzt. Das zentrale Konzept in diesem Ansatz stellen die Bausteine dar. Sie werden in Prozess(z. B. Betrieb) und Systembausteine (z. B. Anwendungen) unterteilt. Jeder Baustein erklärt zuerst, worum es im Baustein geht (z. B. Organisation und Personal oder Netze und Kommunikation), was mit der Implementierung entsprechender Sicherheitslinien erreicht werden kann, welche spezifischen Gefährdungen bestehen (die bei elementaren Gefährdungen schon allgemein beschrieben sind) und dann Anforderungen, die umgesetzt werden müssen, um diesen Gefährdungen zu begegnen. Die Anforderungen sind immer in drei Stufen unterteilt: • Basis-Anforderungen, • Standard-Anforderungen, und • Anforderungen bei erhöhtem Schutzbedarf. Die Basis-Anforderungen müssen vorrangig umgesetzt und die Standard-­Anforderungen sollten grundsätzlich umgesetzt werden. Die Umsetzung beider Anforderungsgruppen erfüllt den Stand der Technik bzw. den normalen Schutzbedarf. Kreuztabellen zeigen jeTab. 4.1  Elementare Gefährdungen für den Baustein CON.6 (Löschen und Vernichten) (BSI 2018a)

Elementare Gefährdungen Anforderungen CON.6.A1 CON.6.A2 CON.6.A3 CON.6.A4 CON.6.A5 CON.6.A6 CON.6.A7 CON.6.A8 CON.6.A9 CON.6.A10 CON.6.A11

G 0.18

G 0.19

X

X X X X X X X X X X X

X

G 0.31

X

G 0.44

X

X X X X

X

88

4  Organisation des Einsatzes von Informationssystemen

weils übersichtlich den Zusammenhang zwischen den relevanten elementaren Gefährdungen und den Anforderungen eines Bausteins. Tab. 4.1 zeigt die Anforderungen (A), die umgesetzt werden müssen damit die spezifischen Sicherheitsgefährdungen (G) beim Löschen und Vernichten von Informationen entschärft werden. Diese Anforderungen sind Teil des Bausteins Konzepte und Verfahren (CON). Tab. 4.2 enthält die vollen Bezeichnungen der Abkürzungen. Die fetten Linien bei den Anforderungen deuten die genannten Schutzstufen an (Basis, Standard, erhöhter Bedarf). Jede Anwenderorganisation kann ihr Modell für den Grundschutz mit den benötigten Bausteinen und Anforderungen planen und umsetzen. Die Entwicklung des Managements der Informationssicherheit kann als ein kontinuierlicher Prozess betrachtet und implementiert werden, wie es die Abb. 4.8 darstellt. ISMS ist hier die Bezeichnung für den Baustein Sicherheitsmanagement. Tab. 4.2  Gefährdungen und Anforderungen (BSI 2018a)

G 0.18 G 0.19 G 0.31 G 0.44 CON.6.A1 CON.6.A2 CON.6.A3 CON.6.A4 CON.6.A5 CON.6.A6 CON.6.A7 CON.6.A8 CON.6.A9 CON.6.A10 CON.6.A11

Gefährdungen Fehlplanung oder fehlende Anpassung Offenlegung schützenswerter Informationen Fehlerhafte Nutzung oder Administration von Geräten und Systemen Unbefugtes Eindringen in Räumlichkeiten Anforderungen Regelung der Vorgehensweise für die Löschung und Vernichtung von Informationen Ordnungsgemäße Entsorgung von schützenswerten Betriebsmitteln und Informationen Löschen der Datenträger vor und nach dem Austausch Auswahl geeigneter Verfahren zur Löschung oder Vernichtung von Datenträgern Geregelte Außerbetriebnahme von IT-Systemen und Datenträgern Einweisung aller Mitarbeiter in die Methoden zur Löschung oder Vernichtung von Informationen Beseitigung von Restinformationen Richtlinie für die Löschung und Vernichtung von Informationen Auswahl geeigneter Verfahren zur Löschung oder Vernichtung von Datenträgern bei erhöhtem Schutzbedarf Beschaffung geeigneter Geräte zur Löschung oder Vernichtung von Daten Vernichtung von Datenträgern durch externe Dienstleister

4.3 Datensicherheit und Datenschutz

89

Initiierung des Sicherheitsprozesses Übernahme der Verantwortung durch die Leitungsebene

Bereitstellung von finanziellen, personellen und zeitlichen Ressourcen

Konzeption und Planung des Sicherheitsprozesses

Entscheidung für eine Vorgehensweise

Erstellung der Leitlinie zur Informationssicherheit

Organisation des Sicherheitsprozesses

Erstellung einer Sicherheitskonzeption

Umsetzung der Sicherheitskonzeption

Aufrechterhaltung und Verbesserung Fortentwicklung des ISMS

Erweiterung der gewählten Vorgehensweise

Abb. 4.8  Entwicklung des Managements der Informationssicherheit

4.3.2 Standards und Zertifizierung Wenn ein Unternehmen die beschriebenen Anforderungen umgesetzt hat, kann es die Zertifizierung seiner Sicherheitsbemühungen beantragen. Das BSI kann ein entsprechendes Zertifikat ausstellen, wobei die Prüfung durch unabhängige, anerkannte Prüfer (Auditoren) erfolgt. Abb. 4.9 zeigt die Akteure im Zertifizierungsprozess. Das BSI hat seine Richtlinien an die ISO/IEC-Norm 27001, die aus dem britischen Standard BS 7799 Teil 2 hervorgegangen ist, angepasst. Mit der Zertifizierung nach ISO 27001 auf Basis von IT-Grundschutz wird einer Organisation attestiert, dass sie sowohl ISO 27001 als auch IT-Grundschutz erfolgreich umgesetzt hat. Dies ist insbesondere für international tätige Organisationen hilfreich.

4.3.3 Datenschutz Die DSGVO (englisch General Data Protection Regulation, GDPR) ist seit dem 25.05.2018 verbindlich und ersetzt alle vorherigen staatenspezifischen Datenschutzbestimmungen in der ganzen EU.  Sie besteht aus 99 Artikeln in elf Kapiteln (https://dsgvo-gesetz.de/).

90

4  Organisation des Einsatzes von Informationssystemen

Abb. 4.9  Rollen im Zertifizierungsverfahren (BSI 2018b)

Die inhaltlichen Anforderungen sind den Anforderungen des früher gültigen Bundesdatenschutzgesetzes (BDSG) ähnlich, aber nun muss die Einhaltung dieser Vorschriften genau nachgewiesen werden können und die Strafen für die Nichteinhaltung der Vorschriften können „Geldbußen von bis zu 20.000.000 EUR oder im Fall eines Unternehmens von bis zu 4  % seines gesamten weltweit erzielten Jahresumsatzes des vorangegangenen Geschäftsjahrs“ (Art. 83) sein. Die DSGVO gilt nicht für natürliche Personen und ihre private Datenverarbeitung, jedoch auch für die nicht-automatisierte Verarbeitung in Organisationen. Sie ist also z.  B. auf manuell geführte Karteikarten eines Außendienstmitarbeiters anwendbar. Sie gilt für in der EU erhobene personenbezogene Daten bzw. Daten der Personen, die sich in der EU „befinden“, auch wenn die Verarbeitung außerhalb der EU erfolgen sollte. Personenbezogene Daten sind „alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person … beziehen“ (DSGVO). Eine Person kann durch Bezug zu einer Kennnummer, Standortdaten oder besonderen Merkmalen identifizierbar sein, ohne dass eine Identifizierung tatsächlich stattgefunden hat (Art. 4). Die Entwicklung der entsprechenden internen Richtlinien ist eine Aufgabe des Leitungsmanagements eines Unternehmens, das u. a. einen Datenschutzbeauftragten bestellt. Dieser überwacht die Einhaltung der Richtlinien und kann, insb. bei kleinen Unternehmen, ein Externer sein. Die DSGVO schützt nicht nur die Kunden eines Unternehmens (und ihre Daten), sondern auch die Mitarbeiter und alle anderen Personen, deren persönliche Daten von diesem gespeichert werden. Die Einwilligung zur Speicherung und Nutzung dieser Daten (z. B. zwecks Versendung eines Newsletters) muss vorliegen, so dass viele Organisationen im Zug des Inkrafttretens der DSGVO diese Einwilligung nachgeholt bzw. erneuert

4.3 Datensicherheit und Datenschutz

91

haben. Ihr Vorliegen muss im Fall eines Disputs nachgewiesen werden. Die Erlaubnis zur Speicherung und Verarbeitung personenbezogener Daten bezieht sich immer nur auf den bewilligten Zweck. Wenn das der Empfang eines Newsletters ist, dürfen die Daten nicht für das Angebot von Waren genutzt werden. Im Fall eines Datenmissbrauchs, der trotz aller Vorkehrungen passieren kann, ist die Organisation nun klar verpflichtet, die potenziell Betroffenen so schnell wie möglich darüber zu informieren. Ein Verbraucher, der z. B. davon Kenntnis bekommt, dass seine Kreditdaten bei einer Firma entwendet wurden, wird wahrscheinlich die Kreditkarte sperren wollen. Das Recht auf Vergessenwerden ist nun Bestandteil der DSGVO. Es gibt Betroffenen die Möglichkeit, die Löschung ihrer personenbezogenen Daten (oder Hinweisen darauf), unter bestimmten Umständen zu verlangen (Art. 17). Ebenso gibt es das Recht, die Übertragung eigener personenbezogener Daten von einem Verarbeiter an einen anderen „in einem strukturierten, gängigen und maschinenlesbaren Format“ zu verlangen (Art. 20). Jede Website, die personenbezogene Daten verarbeitet, muss zwecks Transparenz eine Datenschutzerklärung vorhalten. Diese muss über Zweck und Rechtsgrundlage der Datenerhebung, Dauer der Datenspeicherung, Auskunfts- und Beschwerderechte, gegebenenfalls die Kontaktdaten des Datenschutzbeauftragten und andere Punkte informieren (Art. 12 ff.). Unternehmen über 250 Mitarbeiter (aber auch manche kleinere) müssen ein Verzeichnis von Verarbeitungstätigkeiten führen, in dem u. a. der Zweck der Verarbeitung personenbezogener Daten steht. Für bestimmte Verarbeitungen (z.  B. bei Verwendung neuer Technologien) muss auch eine Datenschutz-Folgeabschätzung durchgeführt (und dokumentiert) werden (Art. 35). Darin werden die Risiken „für die Rechte und Freiheiten der betroffenen Personen“ bewertet und Abhilfemaßnahmen genannt, die zur Bewältigung dieser Risiken geplant sind.

4.3.4 Blockchain Wir besprechen die Blockchain-Technologie wegen ihres Potenzials zur Erhöhung der IT-Sicherheit an dieser Stelle. Die Technologie kann aber auch für weitere Zwecke genutzt werden. Ein Beispiel dazu sind Smart Contracts, die eine Automatisierung der Vertragsumsetzung erlauben. Bestimmte Aktionen können angestoßen werden, sobald bestimmte Bedingungen eintreten (z. B. bei Erreichen eines Datums oder bei Erreichen der vereinbarten Zahlungshöhe). Eine Blockchain speichert Daten in sequenziellen Blöcken auf unterschiedlichen Rechnern redundant ab. Diese Rechner gehören unterschiedlichen Organisationen oder privaten Personen und sind im Allgemeinen alle gleichberechtigt (ein Peer-to-Peer-Netzwerk, s. Glossar), so dass eine nachträgliche Manipulation bereits gespeicherter Daten durch Einzelne unmöglich ist. Diese Art der verteilten Datenhaltung entspricht einer verteilten Journalführung (englisch Distributed Ledger). Sie ermöglicht eine hohe Verfügbarkeit der Daten und gleichzeitig eine Art öffentlicher Aufsicht über die Daten. Dadurch entfällt der Bedarf nach einer Vertrauensinstanz, wie sie sonst bei vielen Transaktionen nötig ist.

92

4  Organisation des Einsatzes von Informationssystemen

Die momentan bekannteste Anwendung des Ansatzes ist die Verwaltung des elektronischen Geldes Bitcoin. Dabei wird jede Bewegung einer „Münze“ aufgezeichnet, von ihrer Schöpfung bis zum aktuellen Verbleib, so dass eine nachträgliche Änderung einer Überweisung oder eine doppelte Ausgabe dieser Münze nicht möglich ist. Jeder Block besteht aus den Informationen zur Transaktion und einer „Blocküberschrift“ (Block-Header). Jeder Block-Header erhält einen eindeutigen Hashwert, eine Identifikation, die per Algorithmus berechnet wird. Der nachfolgende Block stellt die Verknüpfung her, indem er auch den Hash seines Vorgängers speichert. Ein weiterer Hashwert fasst die gesamte bisherige Kette über die Wurzel des entsprechenden Hash-Baum zusammen (Merkle 1980). Die Gültigkeit eines Blocks wird durch einen Proof of Work (oder ein anderes Konzept) festgestellt, bei dem viele Netzwerkteilnehmer Berechnungen durchführen und dann die Mehrheit den Block als korrekt anerkennt. Ein oder wenige Teilnehmer könnten nicht die Gültigkeit zufällig oder absichtlich abstreiten (oder umgekehrt einen ungültigen Block akzeptieren), denn der Konsens der Mehrheit ist entscheidend. Dieser Prozess verbraucht Rechenressourcen, wird als Mining bezeichnet und geeignet belohnt, z. B. durch (Anteile von) Bitcoins. Bei Bitcoins wird der Proof of Work durch eine nur einmal verwendete Zahl (Nonce, number used only once) repräsentiert. Schließlich enthält der Block-Header auch einen Zeitstempel. Die Verkettung in einer Blockchain wird in Abb. 4.10 dargestellt. Eine eventuelle Gleichzeitigkeit von Aktivitäten kann dazu führen, dass unterschiedliche Kettenverlängerungen möglich erscheinen. Dieser Zustand wird jedoch schnell aufgehoben, indem nur eine Verlängerung (die längste) als valide angesehen wird und andere verworfen werden. Während der Inhalt der Transaktion relativ leicht lesbar ist, können die Teilnehmer der Transaktion dank Anonymisierung unerkannt bleiben, die durch asymmetrische Verschlüsselung (s. Glossar) realisiert wird. Das führt bei Bitcoins dazu, dass das System manchmal für illegale Transaktionen missbraucht wird (Geldwäsche, Waffenverkauf, usw.). Die Technologie kann in verschiedenen Varianten realisiert werden. Einerseits kann die Kette für alle zugänglich (also öffentlich oder public) sein, andererseits kann sie von einer einzelnen Organisation oder einem Verbund kontrolliert werden (eine private Blockchain). Die Schreibrechte in der Blockchain können in beiden Fällen eingeschränkt werden, so dass man nur mit Erlaubnis die Blöcke ändern kann (permissioned). Wenn alle Personen das dürfen, dann ist die Kette permissionless. Alternative Konsensmethoden wie Proof of Stake, Proof of Burn oder Proof of Activity können auch zur Anwendung kommen.

Abb. 4.10  Kettenbildung bei Bitcoins (in Anlehnung an (Nakamoto 2008))

4.4 Fremdbezug von IS-Leistungen

4.4

93

Fremdbezug von IS-Leistungen

4.4.1 Theoretische Grundlagen Viele kleine Institutionen beziehen aufgrund ihrer Größe IS-Leistungen von anderen Organisationen. Beispiele hierfür sind kommunale Gebietsrechenzentren, die einen großen Teil der Datenverarbeitung von kleinen Kommunen und Versorgungsbetrieben erledigen, oder die Serviceeinrichtung der Steuerberater, die Datev e.G., die die Buchhaltung und verwandte Funktionen für Mandanten ihrer Mitglieder mit Hilfe ihrer IS ausführt. Anfang der 90er-Jahre begannen jedoch auch einige Großunternehmen, ihre bestehenden IT-Abteilungen teilweise oder ganz in unabhängige Firmen auszulagern (Outsourcing). Dabei werden Mitarbeiter, ganze Rechenzentren und andere Ressourcen an die neuen Dienstleister übertragen oder verkauft und es wird ein langjähriger Vertrag geschlossen, in dem sich der Auftraggeber verpflichtet, vom Outsourcinganbieter bestimmte Dienstleistungen zu bestimmten Preisen zu beziehen. Manche Autoren bezeichnen auch die Ausgliederung der IT-Abteilungen in separate Tochterfirmen als Outsourcing. Es stellt sich die Frage, warum große Unternehmen Outsourcing der IS-Dienstleistungen b­ etreiben, wenn sie im Prinzip selbst von Größendegressionseffekten profitieren können, die durch fallende Durchschnittskosten aufgrund steigender Produktionsmengen entstehen. Ein Motiv hierfür besteht darin, dass sie ihre Aktivitäten auf Kernkompetenzen konzentrieren. IS sind komplex und unterliegen einem anhaltenden, technologischen Wandel. Infolgedessen erscheint es dem Topmanagement häufig unmöglich, die jeweiligen Abteilungen so zu führen, dass sie das Unternehmen optimal mit Informationen zu vertretbaren Kosten versorgen. Einen wesentlichen Einflussfaktor bilden dabei die als Agenturkosten (Agency Costs) bezeichneten internen Koordinationskosten (Jensen und Meckling 1976). Diese entstehen aufgrund der teilweise inkongruenten Interessen der Auftraggeber (Principal) und Auftragnehmer (Agent) und der Informationskosten der Entscheidungen. In manchen Unternehmen ist die Leitung mit den Leistungen der IT-Abteilungen zwar nicht unzufrieden, aber sie geht nicht davon aus, dass der Wechsel zu einer neuen Technologie mit der bestehenden Organisation erfolgreich realisierbar ist. Weiterhin können die Outsourcinganbieter die benötigten Leistungen oft günstiger produzieren als die nachfragenden Firmen, weil sie sich auf bestimmte Dienste spezialisieren und dadurch noch größere Produktionsmengen erreichen oder weil sie als Hardware- und Softwarehersteller Informations- und Wissensvorsprünge gegenüber Anwenderfirmen besitzen. Das Outsourcing birgt aber auch eine Vielzahl von Risiken. Dadurch, dass nun Firmenfremde die IS-Leistungen erbringen, verstehen diese eventuell weniger vom Kerngeschäft des Kunden und haben weniger Interesse am Kunden. Sofern es ehemalige Angestellte des Kunden sind, tritt diese Situation eventuell erst nach einer gewissen Zeit ein. Das strategische Potenzial des Einsatzes von IS wird dann vielleicht nicht erkannt und realisiert. Man versucht diesen negativen Effekten vorzubeugen, indem die Atmosphäre der Zusammenarbeit gepflegt und die Beziehung nicht als ein einfaches Tauschgeschäft betrachtet wird. Die Wahl des Outsourcinganbieters können Verfahren des IS-Controlling unterstützen (Austrup 2007).

94

4  Organisation des Einsatzes von Informationssystemen

Die Wahl der optimalen Organisation von IS-Aktivitäten hängt nach der Theorie der Transaktionskosten (Williamson 1986) von der Sicherheit und Häufigkeit einer Transaktion sowie der Spezifität der involvierten Ressourcen (z. B. Maschinen oder Wissen) ab. Eine Transaktion stellt in diesem Kontext einen Austausch von Gütern oder Dienstleistungen zwischen zwei Parteien dar. Beispiele hierfür sind der Kauf eines Rechners oder die Eigenerstellung eines Programms. Die in einer Transaktion eingesetzten Ressourcen ­weisen eine hohe Spezifität auf, wenn ihr Wert in anderen Transaktionen gering ist. Man kann zwei extreme Koordinationsmechanismen für die Anbahnung von Transaktionen unterscheiden: den Markt und die sog. hierarchische Kontrolle innerhalb einer Institution. Dazwischen lassen sich weitere Kontrollmechanismen definieren. Hier werden nur zwei Erscheinungsformen betrachtet: Outsourcing als zeitbasierten Vertragsrahmen und projektbasierte Verträge, die bei gelegentlichen Transaktionen geschlossen werden. Die sog. Normstrategien ergeben sich aus der Kombination der Ausprägungen der drei genannten Charakteristika von Transaktionen. Sie sind unter der Annahme mittlerer (Un-)Sicherheit in Tab. 4.3 dargestellt. Bei hoher Sicherheit lässt sich die optimale Lösung relativ leicht bestimmen, während bei hoher Unsicherheit tendenziell die hierarchische Koordination vorzuziehen ist. In einem konkreten Fall kann es jedoch sinnvoll sein, von einer Normstrategie abzuweichen. Wenn z. B. ein Unternehmen eine IS-Funktion mittlerer Spezifität, Häufigkeit und Unsicherheit so gut erledigt, dass kein Outsourcinganbieter diese Funktion unter Berücksichtigung sämtlicher Kosten günstiger durchführen kann, bringt Outsourcing keine Vorteile. Im Gegenteil, die Unternehmensleitung könnte in Betracht ziehen, diese Funktion selbst am Markt anzubieten. Außerdem weisen Alpar und Saharia (1995) darauf hin, dass Unternehmen aktiv einen zunächst bestehenden Zustand verändern können, um in den Genuss einer besseren Sourcing-­Strategie kommen zu können. Wenn eine Aktivität mittlerer Unsicherheit, aber mit hoher Häufigkeit und hoher Spezifität vorliegt, wird nach der ausgeführten Theorie die hierarchische Kontrolle empfohlen. Hier kann jedoch versucht werden, diese Aktivität in kleinere Bestandteile aufzugliedern, von denen manche dann eine geringere Spezifität aufweisen und deswegen Kandidaten für Outsourcing werden können. Die korrekte Verarbeitung von Versicherungsfällen ist für eine Versicherung eine kritische Tätigkeit, die häufig vorkommt, aber spezifisches Wissen erfordert. Indes lassen sich einzelne Schritte, wie z. B. die Erfassung einer Schadensmeldung, problemlos ausgliedern. Bei hoher Unsicherheit, bei der sonst die hierarchische Kontrolle empfohlen wird, kann überlegt werden, ob sich die benötigte Leistung nicht standardisieren lässt, um sie eventuTab. 4.3  Bevorzugte Koordinationsmechanismen (in Anlehnung an (Williamson 1986)) Frequenz Selten Häufig

Spezifität Niedrig Markt

Mittel

Hoch

Projekt Outsourcing

Hierarchie

4.4 Fremdbezug von IS-Leistungen

95

ell am Markt günstiger zu beziehen als ihre Selbsterstellung kostet. Ein Beispiel hierfür ist eine exogen vorgeschriebene, generelle Programmumstellung, wie sie etwa die Einführung des einheitlichen Euro-Zahlungsverkehrsraums (SEPA, Single Euro Payments Area) fordert. Die Veränderung von vielen, teilweise schlecht dokumentierten Programmen ist eine kostspielige und riskante Angelegenheit, die grundsätzlich nicht Dritten zu überlassen ist. Statt viele Programme zu ändern, können Firmen jedoch entscheiden, in Zukunft Standardprogramme zu verwenden (s. Abschn. 2.3.1 und 10.1). Diese können sie am Markt potenziell zu Kosten beziehen, die geringer sind als die Überarbeitungskosten für die eigenen Programme.

4.4.2 Formen von Outsourcing Das Management eines Unternehmens versucht häufig, durch geeignete Verträge die Interessen der Partner noch stärker mit den eigenen Interessen zu verbinden. Es wird z. B. nicht nur die IS-Unterstützung einer betriebswirtschaftlichen Funktion, sondern auch die Funktion selbst dem Outsourcinganbieter übergeben, sodass seine Bezahlung an den erzielten Beitrag der Funktion gekoppelt werden kann (Business Function Outsourcing). Ein frühes bekanntes Beispiel für eine solche Vertragsgestaltung war die Vergabe der Einziehung von Geldern für falsches Parken durch die Stadt Chicago an die Firma EDS. In manchen Fällen werden auch einzelne Geschäftsprozesse ausgelagert (Business Process Outsourcing, BPO). Das können horizontale Geschäftsprozesse sein, die in verschiedenen Funktionen notwendig sind, aber gleichartig ausgeführt werden sollen (z.  B. der Geschäftsprozess Kreditprüfung, der im Vertrieb bei Privat- und Geschäftskunden und evtl. im Mahnwesen eingesetzt wird). Es können aber auch vertikale Geschäftsprozesse sein, die nur in einem Geschäftsbereich vorkommen, wenn sie auch verschiedene Abteilungen betreffen können. In beiden Fällen übernimmt der Anbieter die Verantwortung für den gesamten Prozess und nicht nur für den IS-Betrieb. Solche Leistungen werden heute oft über das Internet bezogen. Ein anderer Ansatz ist die Bildung einer gemeinsamen Tochtereinheit durch die Vertragspartner, i. d. R. einer selbstständigen Firma, die dann auch anderen Parteien Leistungen verkauft. Dieses Arrangement wird als Cosourcing bezeichnet. Wenn eine Firma vor einer Outsourcing-Entscheidung auch die eigenen Mitarbeiter um ein Angebot bittet und diese den Wettbewerb gewinnen, kommt es zu einer Form, die als Insourcing bezeichnet wird. Dabei schließt sie Verträge über die zu erbringenden Leistungen mit der eigenen Abteilung; die Entlohnung der Mitarbeiter wird an die Erfüllung dieser Verträge gekoppelt. Den Kern der Verträge bilden wie bei externen Outsourcinganbietern die SLAs (s. Abschn. 4.2.3). Wenn der Outsourcinganbieter seine Leistungen im Ausland (insbesondere in Übersee) erstellt, wird von Offshore Outsourcing oder

96

4  Organisation des Einsatzes von Informationssystemen

kürzer Offshoring gesprochen. Dabei handelt es sich i. d. R. um Länder mit niedrigeren Lohnniveaus, wie sie derzeit z. B. in Indien und China vorherrschen. Outsourcing nach Osteuropa stellt aus deutscher Sicht Nearshoring dar. Nach Schätzungen von Marktforschern wird der Anteil der über Outsourcing erbrachten IS-Leistungen weiterhin steigen. Das Outsourcing verkleinert die IT-Abteilungen, sodass man in diesem Zusammenhang auch von Downsizing spricht. Dieser Begriff kennzeichnet auch den Übergang von Großrechnern auf kleinere Rechner. Da jedoch mit der Zeit erkannt wurde, dass kleinere Rechner und kleinere IT-Abteilungen nicht immer zu besseren Ergebnissen führen, versucht man mittlerweile, die für das jeweilige Unternehmen richtige Größe der IT zu finden (Rightsizing) und genau die Leistungen zu beziehen, die andere ökonomisch sinnvoller bereitstellen können. Dieses Konzept wird auch als Smartsourcing bezeichnet. Application Service Providing (ASP) ist eine Form des Outsourcings, bei der der Anbieter eine Anwendung für den Kunden in seinem Rechenzentrum (oder dem eines von ihm beauftragten Unternehmens) mit einer von ihm entwickelten, gekauften oder gemieteten Software betreibt. Der Kunde nutzt die Anwendung in seinen Räumen meist über das Internet mithilfe eines Webbrowsers. Die eingesetzte Software können mehrere Kunden gleichzeitig verwenden, ohne dass mehrfache Lizenzen erworben werden müssen. Dies ist ein Unterschied zum traditionellen Outsourcing wie auch die Tatsache, dass es beim ASP regelmäßig zu keiner Übertragung von Ressourcen oder zu einem Wechsel der Mitarbeiter zum Outsourcinganbieter kommt. Ein ASP-Anbieter wird die Anwendungen nur in geringem Ausmaß an die Anforderungen einzelner Kunden anpassen wollen, da er sonst seine „Produktionskosten“ nicht niedrig halten kann. Er stellt eine Art Serienfertiger dar – im Gegensatz zu Outsourcinganbietern, die als Einzelfertiger angesehen werden können (Knolmayer 2000). Im Gegensatz zu BPO übernimmt der Anbieter keine (Teil-)Verantwortung für die geschäftlichen Aspekte der Anwendung, da diese beim Kunden verbleibt.

4.4.3 Cloud, Edge und Fog Computing Eine Erweiterung von ASP stellt das Cloud Computing dar. Dabei wird nicht nur der Betrieb von Anwendungen angeboten, sondern auch andere IT-Dienstleistungen, die von einem oder mehreren kooperierenden Anbietern mit ihrer Hardware und Software zur Verfügung gestellt werden. Der Zugriff auf die angebotene Dienstleistung erfolgt i. d. R. über das Internet, das oft als eine Wolke (Cloud) vernetzter Computer dargestellt wird. Die Vorteile von Cloud Computing basieren auf der Vorstellung, dass der Kunde die Dienstleistungen flexibel nach Bedarf (On Demand) nutzen und nach Verbrauch bezahlen kann (Workload Based Billing). Zusätzlich benötigte Ressourcen werden sofort ohne weitere Verhandlungen zur Verfügung gestellt und abgerechnet. Der Kunde kann dabei sowohl ein Unternehmen als auch eine Privatperson sein. Während Privatpersonen Dienste (z. B. E-Mail) oft kostenlos nutzen können, bezahlen Unternehmen nach Anzahl der Nutzer, der Nutzungsdauer oder dem Ressourcenverbrauch. Eine Definition des Cloud Computing bietet das Nationale Institut für Standards und Technologien der USA an:

4.4 Fremdbezug von IS-Leistungen

97

cc Cloud Computing  Cloud Computing ist eine Architektur, die einen bequemen Netzwerkzugang nach Bedarf zu einem gemeinsam genutzten Vorrat von konfigurierbaren Rechenressourcen (z. B. Netzwerke, Server, Speicherplatz, Anwendungen und Dienste) ermöglicht, die schnell und mit einem geringen Managementaufwand oder mit geringer Anbieterinteraktion bereitgestellt und abgerufen werden können (übersetzt aus Mell und Grance 2009). Cloud Computing unterscheidet unterschiedliche Dienstkategorien. Das Angebot von standardisierten Anwendungen, die einzelne Softwarekomponenten oder Services umfassen, wird als Software as a Service (SaaS) bezeichnet. Wenn Kunden nur die Hardware des Anbieters nutzen möchten, um dort z. B. Daten zu speichern oder eigene Programme ausführen zu lassen, dann wird diese Dienstleistung Infrastructure as a Service (IaaS) g­ enannt. Manche Anbieter bieten auch eine Plattform an, auf der flexibel Software mit standardisierten Schnittstellen entwickelt werden kann, was dann als Platform as a Service (PaaS) bezeichnet wird. Die genannten Dienstleistungen können auch kombiniert angeboten werden. Diese Kombination kann zu einem kompletten Geschäftsprozess führen. Wenn ein Geschäftsprozess über die Cloud angeboten wird, wird dies als Business Process as a Service (BPaaS) bezeichnet. Sofern es sich bei den dabei genutzten Anwendungen um eine monolithische Applikation handelt, wie z. B. eine Standardsoftware zur Unterstützung von Personalprozessen, so unterscheidet sich dieser Sachverhalt inhaltlich und technisch nicht von der Nutzung von BPO über das Internet (s. Abschn. 4.4.2). Wenn die Anwendung jedoch aus verschiedenen einzelnen Services besteht, die eventuell auf SaaS, IaaS und/oder PaaS zurückgreifen, stellt dies eine technisch differenzierte Lösung dar, die häufig flexi­ bler und kostengünstiger ist. Auf diese Weise können bestehende Services kurzfristig durch alternative Lösungen substituiert werden, die z. B. mehr Funktionalität bieten. Wenn die angebotenen Ressourcen und Dienste der Organisation gehören, in der sie genutzt werden, liegt eine Private Cloud vor. In einem Konzern kann z. B. ein Tochterunternehmen oder eine zentrale IT-Abteilung Dienstleistungen anbieten, die andere Konzerntöchter oder Geschäftsbereiche in Anspruch nehmen. Wenn Dienstanbieter und Nutzer unterschiedlichen Organisationen angehören, wobei die Nutzer Mitglieder vieler Organisationen (oder Privatpersonen) sind, spricht man von einer Public Cloud. Variationen dieser „reinen“ Organisationsformen sind möglich. Wenn Cloud Computing nur ­einem geschlossenen Kreis von Nutzern, die bestimmten Organisationen angehören, angeboten wird, ist diese Konfiguration als eine Community Cloud zu bezeichnen. Die Ressourcen können dabei durch einen dafür beauftragten Dienstanbieter oder durch die nutzenden Organisationen zur Verfügung gestellt werden. Schließlich können manche Organisationen zwei oder mehrere der genannten Formen verwenden. Wenn diese nicht nur isoliert, sondern auch durch eine Kombination der Ressourcen genutzt werden können, führt dies zur Hybrid Cloud. Beim Multi Cloud Computing liegt der Fokus auf der Verwendung mehrerer Clouds von dritten Anbietern. Das bringt oft finanzielle und Flexibilitätsvorteile mit sich, macht aber das Management einer solchen Umgebung komplizierter (Alpar und Polyovlu 2017). Abb. 4.11 zeigt das mögliche Zusammenspiel der Akteure beim Cloud Computing, wobei zur Vereinfachung nicht alle Erscheinungsformen dargestellt sind. Ein Praxisbeispiel erläutert die Nutzung einer privaten Cloud.

98

4  Organisation des Einsatzes von Informationssystemen

Leistungsanbieter

Kundenschnittstelle & Integrationsstufe

Leistungsabnehmer

Integration & Consulting Services

Endnutzer

Software as a Service (SaaS)

Endnutzer

Platform as a Service (IaaS)

Entwickler, SaaSAnbieter

Infrastructure as a Service (IaaS)

Endnutzer, Entwickler, SaaSAnbieter, PaaSBetreiber

ServiceAnbieter

Netzwerk Anbieter

PlattformAnbieter

ServiceAnbieter

Private Cloud Infrastrucutre Public Cloud Infrastrucutre

Hardware Anbieter

ServiceAnbieter

PlattformAnbieter ServiceAnbieter

PlattformAnbieter

ServiceAnbieter ServiceAnbieter

Kooperation

Wertschöpfungsbeitrag

Integration

Abb. 4.11  Cloud Computing (Repschläger et al. 2010)

T-Systems bringt ThyssenKrupp in die Cloud

T-Systems, die Tochterfirma der Deutschen Telekom, überführt ca. 80.000 Computerarbeitsplätze und 10.000 Server der ThyssenKrupp AG in 34 Ländern in die Cloud. Dabei werden IT-Prozesse und -Services aus bisher ca. 700 Datenräumen und elf Rechenzentren in fünf globale Rechenzentren transferiert. Die Vertragsdauer beträgt sieben Jahre und der Betrag ist im dreistelligen Millionenbereich. Die Mitarbeiter der ThyssenKrupp werden weltweit aus der Telekom-Cloud Computerdienste an ihrem Arbeitsplatz erhalten, die auch verschiedene Microsoft Anwendungen beinhalten. ThyssenKrupp strebte bereits seit 2012 die Harmonisierung und Standardisierung der IT-Landschaft mit dem Programm „unITe“ an. Klaus-Hardy Mühleck, CIO der ThyssenKrupp AG, äußert sich zum Vertrag mit T-Systems: „Unser Ziel ist es, konzernweit eine integrierte IT-Landschaft zu schaffen, die die globale Zusammenarbeit einfacher und effizienter macht, aber auch die unterschiedlichen IT-Bedürfnisse der Konzernsparten bedient“. Und Reinhard Clemens, ein Vorstandsmitglied der Deutsche Telekom AG, merkt an: „Je komplexer die IT-Welt eines Unternehmens, desto notwendiger die Migration in die Cloud: Nur sie reduziert die Kosten, steigert die Effizienz und erhöht die Flexibilität der IT“. (In Anlehnung an https://www.telekom.com/medien/konzern/260952, 16.12.2014, Abgerufen am 28.2.2016)

4.4 Fremdbezug von IS-Leistungen

99

Wenn an einem Ort sehr viele Daten entstehen, z. B. durch Sensoren, die kontinuierliche Prozesse überwachen, dann kann ihre Verarbeitung an einem anderen Ort wegen der notwendigen Übertragung zu lange dauern oder zu teuer sein. Das gilt z. B. dann, wenn die Reaktion auf die Messungen aufgrund der Kritikalität der Prozesse sofort erfolgen muss. Diese Verzögerung (Latenz) bei der Übertragung großer Datenmengen kann vermieden werden, wenn die Daten zuerst vor Ort verarbeitet werden (an den Rändern einer Cloud-Architektur), was zu Edge Computing führt. Aggregierte Daten können danach in die Cloud gesendet werden, um dort detaillierte Analysen vieler solcher Prozesse, die an verschiedenen anderen Orten ablaufen, durchzuführen und Prozesse mittelfristig zu verbessern. In manchen Umgebungen kann es auch sinnvoll sein, zwischen Rändern und einer (oder mehreren) zentralen Cloud(s) Verarbeitungskapazitäten zu schaffen. Damit können z.  B.  Engpässe bei der Leistung an Edge-Geräten vermieden werden bei gleichzeitiger Minderung der Probleme der Übertragungslatenz. Eine solche Möglichkeit wird als Fog Computing bezeichnet. Dabei kann es mehrere Fog-Schichten geben. Das Zusammenspiel der Schichten wird in Abb. 4.12 dargestellt. In der Abbildung sind Sensoren und Geräte aus den Bereichen Gebäude und Stadt, also dem Anwendungsbereich Smart City, zu sehen, aber die Architektur gilt für alle anderen Anwendungen im Bereich Internet of Things (IoT) (z. B. Industrie).

Abb. 4.12  Fog Computing zwischen Cloud und Edge (OpenFog 2017)

5

Digitale Transformation

Zusammenfassung

Dieses Kapitel betrachtet die Rolle der Unternehmen in der durch digitale Kommunikation geprägten Welt. Zuerst werden die grundlegenden Möglichkeiten des Einsatzes des zunächst an einen festen Ort gebundenen Internets für kommerzielle Zwecke entlang der Wertschöpfungskette kurz erläutert. Diese Betrachtung wird dann auf die mobile Nutzung und damit mobile Geschäftsaktivitäten erweitert. Die Kommunikation mit Konsumenten spielt sich zunehmend in sozialen Medien, in die deswegen in diesem Kapitel eingeführt wird. Das Kapitel schließt mit der Betrachtung von Möglichkeiten, die sich aus der Kommunikation von Maschinen und Informationssystemen untereinander ergeben.

5.1

Digitalisierung

Seit der Nutzung von Computern werden Daten digital dargestellt und verarbeitet. Die Interaktion zwischen Unternehmen untereinander und mit ihren Kunden erfolgte zuerst jedoch meist über Telefon, Telefax oder Gespräche am Begegnungsort (z. B. Messe oder Filiale). Wenn die Ergebnisse dieser Interaktion oder nur Daten zur Interaktion selbst (z. B. Gespräch mit Kunde X am Tag Y über Produkt Z) Eingang in die IS finden sollten, bedurfte es zusätzlicher, meist manueller Dateneingaben. Die ersten medienbruchlosen Datenübertragungen fanden mit Hilfe von Software für Electronic Data Interchange (EDI) statt, die Daten nach standardisierten Formaten (z. B. UN-EDIFACT) von einem System (z. B. Bestellsystem eines Unternehmens) zum anderen (z. B. Auftragsbearbeitungssystem eines anderen Unternehmens) elektronisch versenden konnte. Solche Software ist aber nicht für Konsumenten konzipiert und für viele Unternehmen zu kompliziert g­ ewesen.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_5

101

102

5  Digitale Transformation

Zu einer breiten Digitalisierung der Interaktion kam es erst durch die Öffnung des Internets für die Öffentlichkeit. In dieser ersten Welle der digitalen Transformation wurde zuerst Electronic Business (E-Business) und danach Mobile Business (M-Business) eta­ bliert. Man kann sie vereinfacht beschreiben als die Öffnung des Online- und danach des Mobile-Kanals für den Handel. Teilweise wurden alte Intermediäre (z.  B.  Reisebüros) durch neue Intermediäre (z. B. Reisebuchungsplattformen) ersetzt, aber die Geschäftsmodelle blieben im Wesentlichen bestehen. In der aktuellen zweiten Welle der digitalen Transformation kommt es zur Dekonstruktion der bisherigen Geschäftsmodelle, was teilweise durch neue Konstruktionen mit Hilfe der Technologien der ersten Welle und teilweise mit neuen bzw. verbesserten Technologien, wie der Künstlichen Intelligenz, geschieht. Ein Beispiel für neue Geschäftsmodelle sind verschiedene Angebote der Sharing Economy, bei denen Aktiva, die früher nur von Einzelnen genutzt wurden, nun von vielen genutzt werden. Konkrete Beispiele hierfür sind der Dienst Uber, bei dem Privatleute Taxidienstleistungen übernehmen, oder AirBnB, bei dem Privatleute ihren Wohnraum Touristen anbieten. Dies führt zur Substitution bei der Nachfrage nach entsprechenden Leistungen, erhöht aber auch die Nachfrage, weil nun Personen Dienstleistungen in Anspruch nehmen, die sie auf früheren Preisniveaus nicht nutzen konnten oder wollten. Diese Entwicklungen bringen noch nicht zufriedenstellend gelöste Probleme mit sich, z. B. schlechtere Arbeitsbedingungen für Fahrer bei Uber als im regulären Taxigewerbe oder der Entzug von knappem Wohnraum in Städten. In vielen Fällen besteht die bisherige Lösung nur im Verbot solcher Dienste. Manche Unternehmen verfolgen im Rahmen der digitalen Transformation eine Plattform-­Strategie, bei der sie eine Plattform zur Verfügung stellen, über die man z. B. auf ihre Kunden (sofern es diese zulassen) zugreifen kann. Auf diese Weise bieten sie ihren Kunden Dienste Dritter an, die sie selbst nicht anbieten oder nicht programmieren möchten. Ein Beispiel dafür sind einige Banken, die auf diese Weise ihren Kunden spezialisierte Dienste innovativer kleinen Firmen anbieten (z. B. Sparprodukte ausländischer Banken oder automatisierte Beratung), ohne dass die Kunden getrennte Zugänge zu diesen Firmen aufbauen müssen. Alle Dienste stehen ihnen über die Plattform ihrer etablierten Hausbank zur Verfügung. Ein anderer Aspekt, bei dem oft neue Technologien zur Anwendung kommen, bezieht sich auf Prozesse zur Erstellung von Dienstleistungen oder Produkten, die von mehreren, evtl. unabhängigen Organisationseinheiten durchgeführt werden und noch nicht voll integriert sind. In solchen Fällen sind oft menschliche Eingriffe und Entscheidungen notwendig. Nun können diese Prozesse mit Robotic Process Automation (RPA) automatisiert werden (s. Abschn.  8.3.4). Dabei werden Schritte, die bisher von Menschen ausgeführt wurden, z. B. an der Schnittstelle zwischen zwei IS, automatisiert, indem die Entscheidungen nun vom Programm getroffen werden. Das ist oft einfacher als eine volle Integration der bestehenden IS und kann schnell hohe Einsparungen (und mehr Entscheidungskonsistenz) bringen. In anderen Fällen macht man sich die Datenfülle zunutze, die Sensoren (in Maschinen, Produkten oder Menschen) liefern, indem man auf Basis ihrer Auswertungen Prozesse

5.2 Electronic Business

103

verbessert. Im industriellen Bereich bezeichnet man die Einbeziehung der „Dinge“ als Industrie 4.0 worauf Abschn. 5.5.2 näher eingeht. Ein Beispiel für die Nutzung mehrerer neuer Technologien sind Einzelhandelsgeschäfte ohne Personal für den Verkauf. Die Firma JD.com bietet bereits einige solcher Geschäfte mit folgenden Prozessen an: Der Kunde betritt den Laden und weist sich an einem Scanner mit seinem Smartphone und einer Anwendung per QR-Code aus. Danach wählt er die Waren aus, die er kaufen möchte. Beim Checkout wird er per Kamera und KI-basierter Gesichtserkennung unter den angemeldeten Kunden identifiziert, die RFID-Chips (s. Glossar) der Waren werden zwecks Abrechnung ausgelesen und der Kunde verlässt den Laden. Die Rechnung wird auf sein Smartphone übermittelt und der Betrag automatisch abgebucht.

5.2

Electronic Business

5.2.1 Einführung Elektronische Netzwerke und Medien werden schon seit langer Zeit für wirtschaftliche Tätigkeiten genutzt, doch die seit ca. 1992 einsetzende kommerzielle Nutzung des Internet (Alpar 1998) führte zu einer viel stärkeren Nutzung (neuer) elektronischer Netzwerke und Medien für diese Zwecke. Diese Verwendung beschreibt der Begriff E-Business: cc Electronic Business  Electronic Business schließt alle Aktivitäten ein, die über ein elektronisches Kommunikationsnetz abgewickelt werden und direkt oder indirekt kommerziellen Zwecken dienen. Diese umfassende Definition schließt dennoch manche Aktivitäten aus, z. B. das Versenden privater E-Mails. Der Begriff E-Commerce (s. Abschn. 12.2.3) wird, je nach Autor, entweder als ein Synonym für E-Business oder, enger, nur für den elektronischen Handel verwendet. Die einzelnen funktionalen Komponenten von E-Business werden ebenfalls mit dem Kürzel E ausgestattet, sodass auch z. B. von E-Marketing gesprochen wird. Auf die Eigenschaften des E-Business und die Gestaltungsbereiche geht Kap. 12 vertieft ein. Eine häufig verwendete Klassifikation der Erscheinungsformen von E-Business unterscheidet drei gesellschaftliche Bereiche, aus denen die Teilnehmer kommen können: Öffentliche Verwaltungen (Administration), Unternehmen (Business) oder Privatpersonen (Consumer). Aus der Kombination von jeweils zwei Teilnehmern entstehen dann Bezeichnungen wie Business-to-Business (B2B) oder Business-to-Consumer (B2C). Tab. 5.1 gibt die möglichen Kombinationen mit Beispielen wieder. Anwendungen mit Beteiligung öffentlicher Verwaltungen werden auch als E-Government bezeichnet. Wenn ökonomische Transaktionen auf einer elektronischen Plattform erfolgen, liegt ein elektronischer Marktplatz vor. Elektronische Marktplätze unterscheiden sich nach der Anzahl der Teilnehmer, die auf der Anbieter- und Nachfragerseite am Zustandekommen einer Transaktion beteiligt sind. Tab. 5.2 gibt einen Überblick über vier Typen elektronischer Marktplätze.

104

5  Digitale Transformation

Tab. 5.1  Akteure im Internet mit Anwendungsbeispielen von Administration Business Consumer

an Administration

Business

Consumer

Dokumentenaustausch zwischen Behörden

Ausschreibung von Projekten

Einreichung von Mahnbescheiden beim Amtsgericht Einreichung der Steuererklärungen

Austausch technischer Produktspezifikationen

Benachrichtigung über ausgestellte Dokumente Produkt- und Preisinformationen

Einsendung einer Produktreklamation

Erfahrungsaustausch über Produkte

Tab. 5.2  Klassifikation elektronischer Marktplätze (in Anlehnung an (Nomikos 2002)) Anbieter Ein Viele

Nachfrager Ein E-Shop Ausschreibung

Viele Auktion Börse

Ein E-Shop stellt den einfachsten „Marktplatz“ dar. Er kann von vielen Nachfragern besucht werden, aber die Preisverhandlung findet jeweils zwischen dem Anbieter und einem Nachfrager statt, wenn es überhaupt eine gibt. Zwischen den Nachfragern gibt es indirekte Beziehungen, da der Anbieter seine Preise mittelfristig anhand der Gesamtnachfrage anpassen würde. Bei einer Auktion geben viele Nachfrager Gebote für ein vom Anbieter angebotenes Gut ab. Im einfachsten Fall wird das aktuell höchste Gebot allen Nachfragern ohne die Identität des Bieters bekannt gemacht; den Zuschlag erhält das am Ende der Auktion höchste Gebot. Auf einer Ausschreibungsplattform treffen sich jeweils ein Nachfrager und viele Anbieter, die seine Nachfrage erfüllen möchten. Die Anbieter kennen meist nicht das Gebot ihrer Konkurrenten. Der Nachfrager bewertet die Angebote nach verschiedenen Kriterien, sodass hier der Preis zwar wichtig ist, aber nicht unbedingt das billigste Gebot den Zuschlag erhält. Bei der Börse gibt es schließlich viele Anbieter und viele Nachfrager. Wenn sich ein Preis aus allen Geboten bildet, kommt es zum Austausch von Besitzrechten. Im Internet überwiegen E-Shops, aber es gibt auch viele Ausschreibungs- und Auktionsplattformen. Börsen findet man selten (es gibt sie schon für Strom oder Wertpapiere); sie befinden sich meistens noch in proprietären Kommunikationsnetzen, die einer bestimmten Institution gehören, die staatlich beaufsichtigt wird. Der hohe Standardisierungsgrad von Internettechnologien und das große Softwareangebot haben Unternehmen dazu motiviert, diese Technologien auch für firmeninterne Kommunikationsnetze einzusetzen. Solche Netze werden dann als Intranet bezeichnet. Wenn Unternehmen ihr Kommunikationsnetz für ausgewählte Geschäftspartner öffnen, spricht man von einem Extranet. Sowohl ein Intra- als auch ein Extranet können die Infrastruktur des Internets verwenden, wobei Passworte und Verschlüsselung (s. Glossar) die Exklusivität der Nutzung sicherstellen.

5.2 Electronic Business

105

Websites, die Besucher als zentralen Zugang zum Internet benutzen, werden als Portal (Pforte) bezeichnet. Die Portale können Dienste wie Suche, Inhalte (z. B. aktuelle Nachrichten), Gemeinschaftsdienste wie Kommunikation unter den Nutzern oder elektronischen Handel anbieten. Sie können oft vom Benutzer über Parameter seinen Bedürfnissen angepasst werden (Personalisierung). Portale, die Benutzern zur Suche nach anderen Websites dienen, werden als Suchmaschinen bezeichnet (z. B. Google oder Yahoo). Portale werden oft auch im Intranet als Unternehmensportale (Enterprise Portal) zur Verfügung gestellt. Die Klassifikationen in Tab.  5.1 und  5.2 treffen Aussagen über die Teilnehmer am E-Business und darüber, durch welche Marktmechanismen Transaktionen zustande kommen, aber wenig über die inhaltliche Nutzung elektronischer Netzwerke. Die nächsten drei Abschnitte thematisieren daher einige funktionale Komponenten von E-Business anhand der Wertschöpfungskette aus Abschn. 3.2.2.2.

5.2.2 Ausgehende Aktivitäten Unter E-Marketing ist die Nutzung elektronischer Netzwerke und Medien für die Aufgaben des Marketings zu verstehen. Insbesondere das Internet kann zur Unterstützung vieler Marketinginstrumente sowie zur Marketingforschung genutzt werden (Fritz 2004), z. B. das World Wide Web (WWW, s. Glossar) für die Zwecke der Werbung. Beim Werben im Internet wird die Werbebotschaft häufig in einem kleinen, rechteckigen Bereich (Banner) auf einer Website präsentiert. Die Werbung kann aus einem Text, einer Grafik oder einer Videosequenz bestehen. Wenn der Betrachter mehr Informationen haben möchte, kann er i. d. R. auf das Banner klicken und so zur beworbenen Website gelangen. Bei dieser Werbeform ergeben sich Vorteile gegenüber den traditionellen Werbeformen wie z. B. Print-Medien, Radio und TV-Werbung: • Geringere Streuung (Werbung wird auf Websites platziert, die in Zusammenhang mit dem beworbenen Produkt stehen, oder nur denjenigen Besuchern gezeigt, die aufgrund ihrer demografischen oder Verhaltensdaten als Zielgruppe für das beworbene Produkt ermittelt wurden), • höhere Flexibilität (die Werbung kann ganz kurzfristig geschaltet werden), • geringere Kosten (die Erstellung eines Banners ist kostengünstig und die Präsentation wird automatisch gesteuert), und • bessere Erfolgskontrolle (es ist feststellbar, wie Besucher zu einer Website gelangt sind und welche Aktionen sie dort ausgeführt haben). Ebenso kommen Textanzeigen zur Anwendung, insbesondere auf Suchmaschinen. Die Werbetreibenden buchen Begriffe, sodass bei Verwendung dieser Begriffe in der Suche ihre Textanzeigen eingeblendet werden. Diese Werbeform wird Search Engine Advertising

106

5  Digitale Transformation

(Suchmaschinenwerbung) genannt. Die Anpassung eigener Websites sowie die ­Platzierung von Verweisen auf das eigene Informationsangebot auf externen Websites, damit die eigene Website einen hohen Rang in Suchergebnissen erhält, wird als Search Engine Optimization (SEO) bezeichnet. E-Marketing ist kein Ersatz für traditionelle Marketinginstrumente, sondern stellt eine Ergänzung dar. So führen vielfach Konsumgüterhersteller hybride Marketingkampagnen durch, die unterschiedliche Werbeformen (z.  B.  TV-­ Werbung und Websites) kombinieren. Ein Bestandteil der Marketingforschung im Web ist die Beobachtung des Besucherverhaltens auf der Unternehmenswebsite. Das wird durch die Aufzeichnung aller Seitenaufrufe in einer Logdatei unterstützt. Die spätere Analyse dieser Datei mit Methoden des Data Mining (s. Abschn. 2.3.3.4) gilt als Web Log Mining (Bensberg 2001), was besonders bei einem E-Shop zu wertvollen Erkenntnissen führen kann. Das Marketing verändert in den letzten Jahren seinen Fokus von transaktions- und produkt- hin zu beziehungsorientierten Aspekten. Es stehen nicht der einzelne Produktverkauf, sondern der Aufbau und die Pflege der langfristigen Kundenbeziehung im Vordergrund, aus der dann ökonomische Vorteile entstehen sollen. Dieser Ansatz, der die Integration kundenorientierter Aktivitäten im Marketing, Vertrieb und Kundendienst erfordert, wird als CRM bezeichnet (s. Abschn. 12.2.1). Erfolgreiches CRM erfordert entsprechende organisatorische und mitarbeiterbezogene Maßnahmen, aber die Umsetzung des CRM ist in großen Organisationen ohne Unterstützung durch spezifische IS kaum realisierbar. Die Ausgangslogistik (Distributionslogistik) wird zusammen mit anderen Formen von Logistik im nächsten Abschnitt betrachtet.

5.2.3 Interne und eingehende Aktivitäten Die Nutzung elektronischer Netzwerke zur Produktionsunterstützung wird als E-Production bezeichnet. Die Ziele von E-Production können sich sowohl auf die betriebswirtschaftlichen als auch die technischen Aspekte der Produktion beziehen. Zuerst geht es darum, den Planungsstand und den Fortschritt der Produktion im Intranet oder im Extranet besser zu kommunizieren. Durch die verbesserte Kommunikation können dann notwendige Dispositionen früher getroffen werden. Eine Fortführung dieser Gedanken unter Einschluss der technischen Aspekte findet unter dem Begriff Industrie 4.0 statt (s. Abschn. 5.5.2). Logistikprozesse umfassen Güter- und begleitende Informationsflüsse. Der Güterfluss besteht aus Transport-, Umschlag-, Lager-, Verpackungs- und Signierprozessen. Sie dienen der Überbrückung von Raum- und Zeitunterschieden. Logistische Leistungen werden auf der eingehenden Seite eines Unternehmens (Beschaffungslogistik), betriebsintern (Produktionslogistik) und auf der ausgehenden Seite (Distributionslogistik) benötigt. Sofern es sich um digitale (z. B. Software) bzw. digitalisierbare Güter (z. B. Musik) oder Dienstleistungen (z. B. Beratung) handelt, können sämtliche Logistikprozesse mithilfe

5.2 Electronic Business

107

elektronischer Netzwerke realisiert werden. Andernfalls beschränkt sich die ­Unterstützung durch IS auf die begleitenden Informationsflüsse. E-Logistik schließt also den Versand digitaler Güter über elektronische Kommunikationsnetze wie auch elektronische Marktplätze für logistische Leistungen ein, auf denen z. B. LKW-Transportkapazitäten gehandelt werden. Die Verbesserung der Logistikprozesse wird ebenfalls im Kontext von Industrie 4.0 angestrebt. Die Notwendigkeit der Verbesserung zwischenbetrieblicher Prozesse hat in den letzten Jahren zu Konzepten wie Supply Chain Management (SCM) geführt (s. Abschn. 12.2.2). SCM soll die Zusammenarbeit zwischen einem Produzenten und seinen Zulieferern entlang aller Zulieferstufen (also der gesamten Lieferkette) so fördern, dass ein optimales Ergebnis für alle Beteiligten entsteht. Zur Erreichung dieser Ziele ist u. a. ein präzise geplanter und standardisierter Informationsaustausch notwendig.

5.2.4 Unterstützende Aktivitäten Die in Abschn. 5.2.2 und 5.2.3 erwähnten Aktivitäten werden als primäre Wertschöpfungsaktivitäten (s. Abb. 3.3) bezeichnet. Diese werden von verschiedenen anderen Aktivitäten unterstützt, von denen hier nur zwei kurz besprochen werden sollen: die Personalfunktion sowie Forschung und Entwicklung. Die Personalfunktion umfasst u. a. die Personalbeschaffung und die Personalentwicklung. Bei der Personalbeschaffung spielten Stellenanzeigen in Print-Medien jahrelang eine dominierende Rolle, unabhängig davon, ob sie von den Unternehmen selbst oder durch Personalberater geschaltet wurden. In zunehmendem Maße werden zur Personalbeschaffung internetbasierte Jobportale verwendet, mit denen der Bewerbungsprozess digital unterstützt werden kann. Solche Jobportale werden von Medienunternehmen (z. B. Frankfurter Allgemeine Zeitung) zur Verfügung gestellt, oder aber von personalsuchenden Unternehmen (z. B. Telekom). Darin können auch anstehende Projekte, die zukünftige Arbeitsumgebung oder evtl. auch zukünftige Arbeitskollegen vorgestellt werden. Zusätzlich zu dieser Bekanntmachung von Stellenangeboten nutzen Personalverantwortliche das Internet inzwischen auch für die aktive Suche nach Mitarbeitern in sozialen Netzwerken (s. Abschn. 5.4.2). Eine der wichtigsten Maßnahmen der Personalentwicklung ist die Weiterbildung der Mitarbeiter. Die Bedeutung des lebensbegleitenden Lernens wird generell hoch eingeschätzt. Die Kosten hierfür sind jedoch hoch, denn bei konventionellem Lernen müssen sich die Mitarbeiter an einen bestimmten Ort zu einer bestimmten Zeit befinden (Präsenzlernen). Dadurch entstehen nicht nur direkte Kosten, sondern auch Kosten durch Unterbrechungen der normalen betrieblichen Abläufe. Diese Probleme lassen sich beim Lernen mit vorwiegender Hilfe elektronischer Medien umgehen. Der Begriff des E-Learning (auch Computer Assisted Learning) fasst verschiedene Szenarien zusammen. Im Szenario des virtuellen Seminarraums findet Unterricht zu einer bestimmten Zeit statt, aber Lehrende und Lernende können an verschiedenen Orten sein und miteinander

108

5  Digitale Transformation

audiovisuell kommunizieren. Der Vorteil besteht darin, dass die Anonymität zwischen den Teilnehmern aufgehoben wird, allerdings bleiben die Zeitgebundenheit und ein relativ hoher technischer Aufwand. Im Szenario des Web-Based Training ist ein Kurs jederzeit über das Internet abrufbar und der Nutzer kann den Ablauf (z. B. Lernpfad und Lerntempo) individuell steuern. Idealerweise enthält das Programm Lernfortschrittskontrollen, analysiert die Schwächen des Lernenden, verweist auf Hintergrundwissen und bietet, je nach Bedarf, multimediale Inhalte an. Ein Austausch mit dem Dozenten oder anderen Schülern sollte auch möglich sein. Diese Funktionalitäten sind jedoch nicht immer gegeben. In einer Version verfolgen manchmal sehr viele Lehrende den gleichen Kurs über einen gegebenen Zeitraum, daher der Name Massive Open Online Course (MOOC). Oft sind das aber nur ins Internet gestellte Videos von Kursen ohne spezielle didaktische Aufbereitung für das Medium. Die MOOCs werden in manchen Fällen kostenlos angeboten. Computer Based Training (CBT) ist die historisch älteste Form des E-Learning und kann auf einem PC ohne Netzanbindung erfolgen. Bei dem Szenario des Business TV wird das Lernprogramm über einen unternehmenseigenen Fernsehkanal oder einen Video on Demand Server bereitgestellt. Die verschiedenen Formen des E-Learning können nach den Merkmalen der Kommunikationsfähigkeit des Lernenden mit anderen Lernenden oder dem Lehrenden und dem zeitlichen Bezug zwischen Angebot und Nachfrage der Lerninhalte zueinander abgegrenzt werden (s. Tab. 5.3). Eine relativ neue Form zur Erschließung externer Wissensressourcen findet im Bereich der Forschung und Entwicklung Anwendung. Dabei werden externe Personen offen oder verdeckt dazu aufgefordert, bei der Entwicklung neuer Produkte (oder Dienstleistungen) oder der Verbesserung bestehender Produkte mitzuhelfen. Dieser Ansatz des Open Innovation kann im Internet in Diskussionsgruppen, auf einfachen Websites oder mithilfe spezieller Plattformen umgesetzt werden (Reichwald und Piller 2009). Abb. 5.1 zeigt exemplarisch eine einfache Open-Innovation-Plattform, die ein Verbrauchsgüterhersteller verwendet. Der Benutzer identifiziert sich zuerst, danach werden einige rechtliche Aspekte geklärt und erst im dritten Schritt wird der Lösungsvorschlag beschrieben. Im dargestellten Fall wird auf einen Aufruf des Unternehmens reagiert, der das Ziel hat, neue Ideen für Fettreiniger zu entwickeln. Tab. 5.3  Merkmale von Formen des E-Learning (Schüle 2002) Zeitbezug Asynchron

Synchron

Kommunikationsfähigkeit Ja

Web-Based Training

Virtuelle Seminarräume

Nein

Computer-Based Training

Business TV

5.3 Mobile Business

109

Abb. 5.1  Beispiel für eine Open-Innovation-Plattform

5.3

Mobile Business

Die rasante Verbreitung mobiler Kommunikationstechniken hat zum zunehmenden Einsatz von mobilen Endgeräten zur Abwicklung von Geschäfts- und Transaktionsprozessen geführt (M-Business). Generell ist M-Business als ortsungebundenes E-Business aufzufassen. M-Business liefert gegenüber E-Business zusätzliche Anwendungsmöglichkeiten, die sich insbesondere aus der Lokalisierungsmöglichkeit ergeben, wenn das Zugangsgerät im mobilen Netz angemeldet oder auf andere Weise lokalisierbar ist. Dann können dem Benutzer auch ortsabhängige Dienste (Location Based Services) angeboten werden (z. B. Anzeige des nächst gelegenen Restaurants). Zusätzlich kann der Netzbetreiber auch die Bewegung (Motion) des Zugangsgeräts feststellen. Im vorhergehenden Beispiel könnte man eine Werbung einem Benutzer senden, der sich in Richtung des Restaurants bewegt, aber nicht einem, der sich davon entfernt oder sich schon eine bestimmte Zeit gar nicht bewegt, obwohl sie alle im Augenblick gleich entfernt von Restaurant sind. Wenn Lokation und Bewegung vieler Teilnehmer beobachtet wird, können auch neue Anwendungen entstehen, z. B. die Vorhersage von Staus. Dabei sind jedoch stets Fragen des Datenschutzes (s. Abschn. 4.3.3) zu klären. Auf modernen mobilen Endgeräten wie Smartphones können Anwendungen (Apps als Abkürzung für Applications) installiert werden, womit Nutzer ihre Endgeräte um neue Funktionalitäten erweitern können. Die Potenziale von M-Business fasst (Zobel 2001) wie folgt zusammen:

110

5  Digitale Transformation

• Ubiquität (Allgegenwärtigkeit), d. h. die Angebote sind überall und stets verfügbar, da die Endgeräte i. d. R. immer eingeschaltet sind (Always On), nicht gestartet werden müssen und an jeden Ort mitgenommen werden können. • Kontextspezifizität, d. h. durch die Möglichkeit der Lokalisierung und der Interaktion mit der Umgebung wird der Kontext (Ort, Bewegungsrichtung, Uhrzeit, Temperatur, bekannte Interessen des Nutzers) in das Angebot mit einbezogen. • Datenproaktivität, d. h. Dienste können nach dem Push-Prinzip automatisiert ausgelöst werden (z. B. Unwetterwarnung). • Abschlussmöglichkeit, d. h. Abrechnung von Leistungen, indem man das mobile Gerät zur Identifikation des Kunden benutzt (Mobile Payment). • Interaktion, d. h., dass beispielsweise mittels App mit anderen Kommunikationspartnern im Umkreis kommuniziert werden kann. • Integration von Unterhaltung, d.  h., dass beispielsweise Videos oder Musik im MP3-Format auf das Endgerät übertragen, im Gerät gespeichert und jederzeit abgespielt werden können. Die Unterhaltungsangebote können auch alternativ sofort ohne Speichermöglichkeit abgespielt werden. • Remote Control (Fernsteuerung), d. h., dass beispielsweise aus dem Urlaub per „intelligentem Endgerät“ die Elektronik des eigenen Hauses ferngesteuert werden kann. Das nachfolgende Interview verdeutlicht die wachsende Bedeutung von M-Business. Mobile-Strategie von Zalando

Zwei Manager der Firma Zalando erklärten in einem Interview die Wichtigkeit einer Mobile-Strategie für ihre Firma. Bereits im vierten Quartal 2014 kamen 48 Prozent des Traffic in deren Shops von mobilen Geräten, mit steigender Tendenz. Daher hat die Firma die Strategie „Mobile First“ festgelegt. Alle Prozesse würden vom Mobile-Ansatz her gedacht. Die Zielsetzung für 2015 war nicht mehr Konversionen, sondern mehr Engagement der Kunden und Etablierung von Zalando als ihrem Modeexperten. Mehr Engagement sollte sich in häufigeren Besuchen und längeren Aufenthaltszeiten äußern. Der Fokus verlagert sich von Transaktionen zu einer langfristigeren Kundenbeziehung. Apps spielen dabei eine wichtige Rolle, weil sie eine hohe Wiederkehrrate und Kundenloyalität fördern. Neue Ideen werden über Experimentieren gefördert, z. B. durch eine Hack Week (ein Wettbewerb, bei dem intensiv neue Programme entwickelt werden), und ein grundsätzliches „Out of the Building“-Denken (frühe Suche von Kontakten mit Kunden, um neue Ideen auszuprobieren). Das bedeutet z. B., dass Kunden in Momenten beobachtet werden, in denen sie mit Mode in Berührung kommen. Funktionen wie das Teilen von Erfahrungen (Mobile Sharing) sowie Feed oder Push Notifications im Kontext der Personalisierung sollten dazukommen. Die Shopping Experience sollte geräteübergreifend funktionieren. Das Feature der Fotosuche stellt ein erstes Beispiel für die Unterstützung des virtuellen „Bummelns“ dar. (In Anlehnung an http://www.internetworld.de/e-commerce/zalando/zalando-shopping-erlebnis-schaffen-917472.html, Laura Melchior 30.03.2015, Abgerufen am 29.2.2016)

5.4 Soziale Medien und Web 2.0

111

Als ein weiteres mobiles Endgerät für M-Business kann ein sog. Head-up Display (HUD), das auf dem Kopf ähnlich einer Brille getragen wird, für die Darstellung der virtuellen Realität genutzt werden. Das erlaubt z. B. einem Wartungstechniker, der vor Ort ein Gerät reparieren muss, das zugehörige Wartungshandbuch virtuell zu öffnen, wenn er das Gerät in Realität ansieht. Ein Tourist könnte sich historische Daten zu einem Denkmal virtuell ansehen, während er dieses Denkmal gerade auf der Straße sieht. Dadurch erhalten Benutzer zusätzlich zur betrachteten Realität Informationen aus einem IS (Augmented Reality). Weitere tragbare, am Körper befestigte Geräte, englisch kurz Wearables, können direkt oder indirekt (z.  B. über Smartphones) mit dem Internet verbunden sein und für vielfältige kommerzielle (z. B. Bezahlen) und nicht-kommerzielle Zwecke (z. B. Messung von Fitnesswerten) genutzt werden. Grundsätzlich sind Anwendungen der virtuellen Realität auch auf Smartphones und damit mobil nutzbar.

5.4

Soziale Medien und Web 2.0

5.4.1 Eigenschaften von Web 2.0-Anwendungen Die Organisatoren einer Konferenz in Kalifornien im Jahr 2004 empfanden, dass einige der damals innovativen Anwendungen im Web spezifische Merkmale besaßen und benannten diese Anwendungen insgesamt Web 2.0 (O’Reilly 2005). Prägend für diese Anwendungen ist, dass die Inhalte auf den Websites primär von ihren Besuchern generiert werden (User Generated Content, UGC). Sowohl die Programme als auch die Daten werden auf der Webplattform vorgehalten und sind deswegen von überall mithilfe des B ­ rowsers nutzbar. Den Unterschied zwischen den Anwendungen des Web 1.0 und 2.0 stellt Abb. 5.2 grafisch dar. Der Nutzen von Web 2.0-Anwendungen entwickelt sich nach dem Prinzip der Netzwerkeffekte (s. auch Abschn. 12.3). Je mehr Nutzer eine Anwendung hat, desto wertvoller wird sie für sämtliche Nutzer, da mit jedem neuen Benutzer die Anzahl potenzieller Kommunikationsmöglichkeiten überproportional wächst.

Abb. 5.2  Vergleich zwischen Web 1.0 und 2.0 (in Anlehnung an Alpar et al. 2007)

5  Digitale Transformation

112

Bei einer aktiven Teilnahme vieler Benutzer wachsen meist auch Quantität und Qualität der Inhalte, weil eine Gruppe mehr und bessere Informationen als ein Einzelner oder einige wenige Benutzer beitragen kann. Dieses Prinzip wird als Crowdsourcing oder Wisdom of Crowds (Surowiecki 2004) oder kollektive Intelligenz bezeichnet. Einige Anwendungen erlauben die Bedienung spezieller Interessen, z.  B. den Austausch selten gebrauchter Produkte oder die Beantwortung sehr spezifischer Fragen. Diese Art von Nachfrage wird als Long Tail (Anderson 2004) bezeichnet. Der Begriff kommt daher, dass die statistische Verteilung der Nachfrage wie ein langes Rumpfende (s. Abb. 5.3) erscheint. Sie ergibt sich daraus, dass einige wenige Güter sich großer Nachfrage erfreuen (Bestseller), während viele andere Güter nur selten nachgefragt werden (Nischenprodukte). Die Bedienung von Nischenmärkten mit Informationen oder Produkten, die digital geliefert werden können (z. B. Bilder, Musikstücke oder Videos), verursacht relativ geringe Grenzkosten, sodass Geschäftsmodelle, die sich außerhalb der elektronischen Netze nicht lohnen würden, im Internet wirtschaftlich sein können. Die gemeinsame Entwicklung von Inhalten, die Kommunikation mit anderen Benutzern der Anwendung oder der regelmäßige Konsum der Beiträge anderer Benutzer führen zu sozialen Beziehungen zwischen den Benutzern des Web 2.0. Deswegen wird die Gesamtheit der Benutzer einer solchen Anwendung auch als eine soziale Gemeinschaft (Social Community) angesehen, und die verschiedenen Anwendungen werden zusammen als soziale Medien (Social Media) bezeichnet. Sie stehen damit im Gegensatz zu traditionellen Medien wie Fernsehen oder Druckmedien, bei denen die Anbieter gleiche Inhalte an viele passive Empfänger (Konsumenten) verteilen. Die Konsumenten können die traditionellen Medien nur nutzen oder nicht, aber bis auf wenige Ausnahmen keine eigenen Inhalte beisteuern (z. B. vom Anbieter ausgewählte Leserkommentare). Die unterstützenden Programme werden als Social (Networking) Software bezeichnet. Die Kommunikationsbeziehungen zwischen den Benutzern einer Web 2.0-Anwendung können mithilfe von Methoden der Social Network Analysis (SNA) untersucht werden (Scott 2012; Umsatz in Stück 10.000

2 1 123

Rangliste der Produkte nach Stückumsatz

Abb. 5.3  Grafische Darstellung des Long-Tail-Prinzips (Alpar et al. 2007)

253.000

5.4 Soziale Medien und Web 2.0

113

Wasserman und Faust 1999). Mit diesen Methoden kann z. B. analysiert werden, welche Teilnehmer Einfluss auf andere Teilnehmer ausüben, wie sich Informationen im betrachteten Netz ausbreiten und welche thematischen Subnetze existieren. Der Begriff des Web 2.0 war zunächst umstritten, weil u. a. auch einige ältere Anwendungen ähnliche Funktionalitäten anbieten bzw. die gleichen Prinzipien ausnutzen. So machen sich der Online-Händler Amazon und die Auktionsplattform eBay ebenfalls das Long-Tail-Prinzip zunutze. Die Benutzer von Amazon steuern mit ihren Buchkritiken ebenso eigene Inhalte bei und die Benutzer von eBay bauen über die Bewertung anderer Benutzer und die kurzen Kommentare zu Kaufvorgängen ebenso soziale Netzwerke auf. Der Begriff hat sich in der Praxis dennoch durchgesetzt. Die Web 2.0-Anwendungen wurden zunächst als Anwendungen für die Privatsphäre angesehen, aber ihre kommerziellen Nutzungsmöglichkeiten sind inzwischen deutlich geworden. Das spiegelt sich nicht nur im Wert der Firmen wider, die solche Anwendungen anbieten, sondern auch in der intensiven Präsenz von Unternehmen auf den entsprechenden Websites, als Werbetreibende, Personalsuchende, Besitzer von Präsenzen in Social Media mit vielen Fans bzw. Followern, „Showrooms“ und E-Shops. Schließlich nutzen auch viele Unternehmen vergleichbare Technologien und Anwendungen intern und für die Ausgestaltung der Kundenbeziehung (Alpar et  al. 2007). Auf das dadurch entstehende Social CRM (Alt und Reinhold 2016) geht Abschn. 12.2.2 genauer ein.

5.4.2 Soziale Netzwerke mit Fokus auf Kommunikation Bei kommunikationsfokussierten sozialen Netzwerken (SN) stehen die Individuen und deren Kommunikationsprozesse im Vordergrund. Zu diesem Zweck spezifizieren Benutzer ein individuelles Profil. Dieses kann u. a. Fotos, demografische Angaben, Angaben zu Interessen, Freunden oder Kontakten enthalten. Teile des Profils können auch als privat deklariert und so nur ausgewählten Benutzern zugänglich gemacht werden. Meistens gehören zunächst bestehende Bekanntschaften zum eigenen Kommunikationskreis, aber im Laufe der Zeit kommen neue Bekanntschaften aus dem Netzwerk hinzu. Innerhalb des Netzwerkes bilden sich thematische Subnetze z. B. nach Studienort, Beruf oder Hobby. Die Mitglieder können u. a. mit einzelnen Bekannten Nachrichten austauschen, in Foren diskutieren, multimediale Inhalte in ihrem Bereich publizieren und anderen zur Verfügung stellen, sowie Fragen stellen. SN sind zunächst für private Zwecke, wie z. B. Facebook, oder für berufliche oder geschäftliche Zwecke, wie z.  B. LinkedIn, angeboten worden. Weiterhin wird zwischen offenen und geschlossenen Netzwerken unterschieden, die nur für bestimmte Personenkreise zugänglich sind (z. B. nur für Fahrer eines bestimmten Automodells). Inzwischen dürfen auch Unternehmen Mitglieder mancher SN für Privatpersonen werden und diese, über Werbung hinaus, kommerziell nutzen. Bei ihrer Teilnahme gelten jedoch andere Regeln mit dem Umgang von Daten als für private Mitglieder, wie das nachfolgende Beispiel verdeutlicht. Eine zentrale Bedeutung besitzt auch hier der Umgang mit personenbezogenen Daten (s. Abschn. 4.3.3).

114

5  Digitale Transformation

„Gefällt mir“ gefällt nicht Verbraucherschützern

Der „Gefällt mir“-Button wird von Websites gern eingebunden, da es ihre Popularität auf Facebook erhöht und dadurch mehr Besucher, mehr Besuche und evtl. mehr Umsätze bringt. Das Landgericht Düsseldorf gab jedoch einer Klage wegen der Verwendung des „Gefällt mir“-Buttons der Verbraucherschutzzentrale Nordrhein-Westfalen gegen die Bekleidungsfirma Peek & Cloppenburg statt. Die Platzierung des Buttons auf eigenen Webseiten müsse mit Aufklärung der Besucher über die Folgen und/oder Einholung ihrer Einwilligung zu diesem Vorgehen einhergehen, weil Facebook mit Hilfe eines Plug-ins Informationen über Besucher der Website sammelt, selbst wenn sie nicht auf das Button klicken und nicht Mitglied von Facebook sind. Nach Ansicht der Richter verstößt die Aufnahme des Buttons gegen die Datenschutzvorschriften, weil dies zur Weiterleitung der IP-Adresse des Nutzers an Facebook ohne seine ausdrückliche Zustimmung führt (Az.: 12 O 151/15). Die Verbraucherzentrale argumentierte, dass der Besuch einer Website nicht die Zustimmung zur automatischen Weitergabe und Auswertung ihrer Surfspuren bedeutete. Daher verstoße das Vorgehen gegen das Telemediengesetz. Sie hatte sechs Unternehmen wegen des „Gefällt mir“-Buttons abgemahnt: Peek & Cloppenburg, das Hotelportal HRS, den Kosmetikhersteller Beiersdorf, den Rabattanbieter Payback, das Ticketportal Eventim und die Kaufhauskette Kik. Vier nahmen den Button raus oder verhinderten die Weitergabe der Kundendaten. Das Verfahren gegen Payback hängt am Landgericht München an. (In Anlehnung an FAZ, 10. März 2016, Nr. 59, Joachim Jahn) Manche SN erleichtern die Aufnahme neuer Kontakte durch die Ausnutzung des Phänomens der „Kleinen Welt“ bzw. der „Sechs Grade der Trennung“ (Newman et al. 2006). Experimente haben gezeigt, dass Menschen über durchschnittlich sechs Verbindungen miteinander bekannt sind. Abb. 5.4 zeigt die Umsetzung dieser Idee im Netzwerk Xing für berufliche und geschäftliche Kontakte. Die Verbindung von Max Muster zu Martina Müller (fiktive Namen) ist im oberen Teil der Abbildung mit den dazwischenliegenden Kontaktknoten (Personen) dargestellt. Eine weitere Funktion mancher SN ist die Darstellung der Mitglieder als dreidimensionale Stellvertreterfiguren, sog. Avatare, die sich dann in einer virtuellen Welt bewegen können. Die bekannteste Anwendung in diesem Bereich stellte Second Life dar. Die Avatare konnten dort z. B. mit anderen Avataren kommunizieren, Häuser bauen, Diskotheken und Konzerte besuchen, oder einkaufen. Als Währung für kommerzielle Transaktionen dienten Linden-Dollars, die in echtes Geld konvertiert werden konnten. Allerdings wurde Second Life aus verschiedenen Gründen eingestellt.

5.4.3 Soziale Netzwerke mit Fokus auf multimediale Inhalte Bei multimedialen Netzwerken publizieren die Benutzer Bilder (z. B. bei Flickr), Videoclips (z. B. bei YouTube) oder Audiodateien und stellen sie der Allgemeinheit zur Verfügung. In manchen Fällen können die entsprechenden Dateien auch als privat deklariert

5.4 Soziale Medien und Web 2.0

115

Abb. 5.4  Verbindungskette zwischen zwei Personen in Xing

werden, sodass nur ausgewählte Besucher Zugang haben. Derjenige, der einen Beitrag hochlädt, kann diesen mithilfe einiger Stichworte beschreiben, die als Tags bezeichnet werden. Daraus entsteht eine implizite Kategorisierung der Beiträge, nach denen mit Stichworten gesucht werden kann. Benutzer können Beiträge bewerten und kommentieren. Mit neueren Ansätzen wird versucht, die Klassifizierung der multimedialen Inhalte aufgrund der Inhalte selbst vorzunehmen. Dann kann z. B. nach allen Bildern, auf denen ein Sonnenuntergang abgebildet ist, oder nach allen Videoclips, in denen Fußball gespielt wird, gesucht werden, ohne dass diese Begriffe in Tags vorkommen müssen. Dies gestattet auch die zielgenauere Platzierung von Werbung, sodass z. B. ein Werbespot für Fußballschuhe automatisch nur in Videoclips, in denen Fußball gespielt wird, ausgestrahlt wird. Ein weiterer Ansatz stellt die Bereitstellung eines am persönlichen Geschmack des Nutzers ausgerichteten Musikprogramms dar. Der Dienst Last.fm verfolgt diesen Ansatz und stellt, basierend auf Angaben von Nutzern hinsichtlich ihrer Lieblingsmusik oder der auf dem Endgerät angehörten Musik, ein personalisiertes Webradio zur Verfügung. Für den aktuell abgespielten Titel steht hier die Möglichkeit der positiven Bewertung oder des Sperrens zur Verfügung. Im Zeitverlauf soll so ein möglichst personalisiertes Musikprogramm für den Nutzer entstehen. Im Rahmen des SNs schlägt Last.fm zudem Nutzer als Kontakte vor, die einen ähnlichen Musikgeschmack haben und verweist auf anstehende Konzerte bevorzugter Künstler.

5  Digitale Transformation

116

5.4.4 Weblogs Das Wort Weblog, abgekürzt Blog, setzt sich zusammen aus Web und Logbuch und kennzeichnet damit eine Art Tagebuch im World Wide Web, das von einem oder mehreren Autoren geführt wird. Der neueste Beitrag erscheint auf der Website ganz oben, gefolgt von älteren Beiträgen. Leser können die Beiträge an gleicher Stelle kommentieren. Zum Schreiben in einem Blog sind dank entsprechender Softwarelösungen keine Programmierkenntnisse notwendig. Ein Blog kann mit einer Liste auf andere Weblogs verweisen (Blogroll). Ein Blog kann auch Bezüge auf seine Beiträge in anderen Weblogs verzeichnen (Trackbacks). Durch alle diese Querbezüge entsteht ein Netzwerk, das als Blogosphäre bezeichnet wird und exemplarisch in Abb. 5.5 dargestellt ist. Diese intensive Verknüpfung führt dazu, dass Suchmaschinen Beiträge in viel beachteten Blogs bei entsprechenden Suchworten priorisiert auf ihren Trefferlisten zeigen und ihnen so mehr Aufmerksamkeit beimessen. Wer sich für Beiträge in einem Blog interessiert, kann diesen auch abonnieren, sodass er über neue Einträge informiert wird, ohne die Website wiederholt zur Sichtung von Neueinträgen besuchen zu müssen. Die Benachrichtigungen enthalten meist Titel und einige Zeilen des Neueintrags und erfolgen über einen sog. RSS-Feed, der entweder direkt in einem Webbrowser, oder in einem speziellen RSS-Reader gelesen werden kann. Der Autor eines Beitrags kann diesen mithilfe einiger Stichworte beschreiben, um die Suche nach Beiträgen innerhalb des Weblogs zu erleichtern. Während Millionen Blogs nur wenige Einträge und Leser haben, können Beiträge von Blogautoren, die als Meinungsmacher angesehen werden, hohe Relevanz für Unternehmen besitzen. Deswegen betreiben große Unternehmen bisweilen eine regelmäßige, teilweise automatisierte Beobachtung von Blogs, um mögliche Probleme oder Chancen frühzeitig zu erkennen. Immer mehr Unternehmen setzen Blogs auch für die externe und interne Kommunikation ein. Als Autor tritt dort oft der Vorstandsvorsitzende auf.

Autor/ Leser

Weblog

Leser

Autor/ Leser

Weblog

SuchMaschine

Kommentar

Blogroll

Abb. 5.5  Blogosphäre (Alpar et al. 2007)

Track back

schreiben/lesen

5.4 Soziale Medien und Web 2.0

117

Eine spezielle Form des Weblogs stellen sog. Mikroblogs dar (z. B. Twitter). Wenngleich diese typische Merkmale von Weblogs, wie die umgekehrt chronologische Darstellung der Nachrichten eines Nutzers, besitzen, unterscheiden sie sich insbesondere hinsichtlich des Umfangs eingereichter Nachrichten von dem zuvor dargestellten Weblog. Verschiedene Dienste geben eine maximale Anzahl von Zeichen pro Eintrag vor. Abonnenten werden in diesem Kontext als Follower bezeichnet. Die Beliebtheit von Twitter hat das Entstehen einer Vielzahl von Erweiterungen des Diensts beflügelt, die auch die einfache Nutzung auf Mobiltelefonen umfassen. Dadurch ist es möglich geworden, dass jeder Mobilfunknutzer zum Reporter vor Ort wird. Die Notlandung eines Flugzeuges im Hudson River vor New York City wurde zuerst über Twitter berichtet und hat zur weiteren Popularität der Anwendung beigetragen. Im Kontext der nach außen gerichteten Kommunikation benutzen Unternehmen Mikroblogging, um z. B. Mitteilungen über Jobangebote oder über das eigene soziale Engagement zu verbreiten.

5.4.5 Wikis Der Begriff Wiki kommt vom hawaiischen Ausdruck wiki wiki für „schnell“. Er soll andeuten, dass mit dieser Technologie eine schnelle und einfache Veröffentlichung von gemeinsam entwickelten Dokumenten möglich ist. Ein Benutzer erstellt einen Text mit der Bearbeitungsfunktion der Wiki-Software, die einfache Textverarbeitungsbefehle zur Verfügung stellt. Der Text kann dann sofort im WWW veröffentlicht, von anderen Benutzern gelesen und geändert werden. Die Zielsetzung besteht darin, dass durch die gemeinsame Entwicklung vieler Autoren Dokumente mit hoher Qualität entstehen, da ein Kollektiv stets über mehr Wissen und Intelligenz verfügt als ein individuelles Mitglied dieses Kollektivs (kollektive Intelligenz, s. Abschn. 5.4.1). Einzelne Dokumente eines Wikis sind miteinander verknüpft und die Änderungen des Dokuments werden fortlaufend festgehalten, sodass die Änderungshistorie transparent ist. Ungewollt oder absichtlich eingetragene Fehler können schnell entdeckt und korrigiert werden, wenn ein Wiki viele Benutzer hat. Dokumente im Wiki können auch multimediale Inhalte enthalten. Das bekannteste öffentliche Wiki ist die frei verfügbare Enzyklopädie Wikipedia (s. Abb. 5.6). Wikipedia hat Anfang 2016 mit über 37 Millionen Artikeln in knapp 300 Sprachen und Dialekten einen größeren Umfang als traditionelle Enzyklopädien und steht ihnen in der Qualität nicht nach, wie Tests nachgewiesen haben (Giles 2005). Ihre Offenheit muss allerdings auch kritisch gesehen werden, da die Qualität von Wikipedia von böswilligen Attacken und politischen Auseinandersetzungen bedroht wird. Für Unternehmen stellt die Technologie eine einfache, kostengünstige und dennoch leistungsfähige Plattform für das Wissensmanagement dar, sodass zunehmend unternehmensinterne Wikis für Projektmanagement, Produkt- oder Kundeninformationen u. a. Zwecke entstehen.

118

5  Digitale Transformation

Abb. 5.6  Beispiel einer Wiki-Seite

5.4.6 Weitere soziale Netzwerke Es gibt weitere Anwendungen im Web 2.0, die zu sozialen Gemeinschaften führen. Die bereits beschriebenen Funktionalitäten kommen immer wieder vor: Bewertung von Inhalten oder Benutzern, Vergabe von Stichworten (Tagging), Abonnieren über RSS, mehr oder weniger umfangreiche Benutzerprofile mit Statistiken über die Teilnahme an der Anwendung. Manche Anbieter vermischen auch Anwendungen (Mash-up), indem sie die Anwendung eines anderen Anbieters (oft kostenfrei) in ihre Anwendung einbinden. ­Benutzerberichte über Restaurantbesuche werden z. B. mit einem Kartendienst verknüpft. An dieser Stelle seien zwei Anwendungen genauer beschrieben. Social Bookmarking. Jeder Webbrowser erlaubt das Speichern ausgewählter Internetadressen, damit man diese beim nächsten Besuch nicht mehr eingeben muss, sondern einfach aus der Liste selektieren kann. Diese Einträge werden als Bookmarks (Lesezeichen) oder Favorites bezeichnet. Die physische Speicherung der Lesezeichen erfolgt auf dem Rechner, an dem man zur Zeit der Speicherung gerade arbeitet. Wenn später ein anderer Rechner benutzt wird, stehen diese Lesezeichen nicht zur Verfügung. Deswegen gibt es Dienste, die Lesezeichen im WWW aufbewahren, sodass sie von jedem Rechner im Internet abrufbar sind. Dies hat den weiteren Vorteil, dass die Lesezeichen einfach mit anderen Benutzern ausgetauscht werden können. Manche der Dienste vergleichen auch die Lesezeichen der Benutzer und identifizieren so Benutzer mit ähnlichen Interessen (aufgrund gleicher Lesezeichen oder Lesezeichen ähnlichen Namens). Dann werden Benutzern Vorschläge unterbreitet, Lesezeichen aufzunehmen, die sie noch nicht haben.

5.5 Internet der Dinge, M2M und Industrie 4.0

119

Social News. Es gibt Anwendungen, um andere Benutzer auf interessante Nachrichten auf Portalen von Medienunternehmen, auf Blogeinträge, auf Videoclips o. ä. aufmerksam zu machen. Die Zitation (Citation) enthält eine kurze subjektive Zusammenfassung des Inhalts, die Internetadresse des Inhalts und beschreibende Tags. Andere Benutzer bewerten und kommentieren eventuell diese Hinweise (meist Nachrichten genannt). Hinweise mit einer bestimmten Punktzahl werden aus der Warteschlange der eingereichten Nachrichten auf die Hauptseite befördert und erhalten dadurch noch mehr Aufmerksamkeit. Solche Dienste gibt es in vielen Ländern und Sprachen, wobei Reddit derzeit der populärste ist. Bei vielen von ihnen erhalten Benutzer Punkte für das Einreichen, Kommentieren oder Bewerten von Nachrichten, sodass die aktivsten Benutzer hohes Ansehen in der Benutzergemeinde genießen, und ihre Hinweise oder Empfehlungen besonderes Gewicht erhalten. Es ist meist möglich, alle oder nur bestimmte Nachrichten per RSS zu abonnieren.

5.5

Internet der Dinge, M2M und Industrie 4.0

5.5.1 Internet der Dinge Die bisher beschriebenen Dienste und Anwendungen verknüpfen hauptsächlich Menschen untereinander bzw. Menschen mit IS. Da viele Maschinen über Sensoren zur Erhebung von Zustandsdaten verfügen, die für deren Wartung oder andere Maschinen relevant sein können, und diese Maschinen wiederum über Programme gesteuert werden, die selbstständig Entscheidungen treffen können, ist auch die autonome Kommunikation zwischen Maschinen (engl. Machine-to-Machine oder abgekürzt M2M) zu betrachten. Die Initiative zur Kommunikation geht dann von Maschinen aus und richtet sich an andere Maschinen, die auch entfernt voneinander im Einsatz sein können. Dank der Version 6 des Internet-­ Protokolls, abgekürzt IPv6 (s. Glossar), ist es möglich geworden, nicht nur Milliarden von Computern eindeutig zu adressieren und zu vernetzen, sondern auch alle mit IP-Zugang ausgestatteten „Dinge“ oder Maschinen. Das können Haushaltsgeräte und Heizungen in Wohnungen und Häusern sein (Smart Home), selbstfahrende Autos oder in der Produktion eingesetzte Maschinen. Eine IP-Adresse und eine direkte Verbindung zum Internet ist oft nicht notwendig, sondern die von einem Sensor gesammelten Daten können zunächst an ein an das Internet angeschlossenes Gerät gesendet werden, z. B. über Bluetooth (s. Glossar) an ein Smartphone, von wo sie mit oder ohne Weiterverarbeitung an andere IS im Internet gelangen. Das Beispiel (s. Abschn. 2.3.4) der „intelligenten“ Laufschuhe ist also auch ein Beispiel für IoT im persönlichen Bereich. Die in der physischen Welt real agierenden Dinge sind über das Internet miteinander vernetzt und können sich selbstständig steuern, wenn sie über entsprechende Steuereinheiten verfügen. Da sie also in der physischen Welt und im Internet aktiv sind, kann man von cyber-physischen Systemen (Cyber-Physical Systems) sprechen. Abb.  5.7 stellt verschiedene Geräte dar, die an das Internet der Dinge angeschlossen werden können.

120

5  Digitale Transformation

Abb. 5.7  Internet der Dinge

Die durch Sensoren entstehenden Daten können am Ort ihres Entstehens verarbeitet werden (s. Abschn. 4.4.3) oder mit oder ohne Aggregation an zentralisierte Ressourcen (evtl. in einer Cloud) weitergegeben werden. Dort können sie integriert werden (z. B. mit Daten vieler anderer gleichartigen Maschinen). Daraus kann man evtl. neue Erkenntnisse gewinnen und Handlungsempfehlungen zurück an die Maschinen versenden.

5.5.2 Industrie 4.0 In Deutschland wurde für Anwendungen von IoT im industriellen Bereich der Begriff Industrie 4.0 geprägt, der diese Entwicklung als die nächste Welle der Industrialisierung kennzeichnet (Kagermann et al. 2013). Die vier Wellen können wie folgt charakterisiert werden: (1) Mechanisierung (2) Elektrifizierung (3) Automatisierung mit IT (4) Vernetzung

5.5 Internet der Dinge, M2M und Industrie 4.0

121

Industrie 4.0 basiert auf den beschriebenen cyber-physischen Systemen. Produkte und Produktionsprozesse werden schon lange Zeit am Computer geplant und simuliert. Bei Industrie 4.0 wird nun sowohl der Produktionsprozess weiter kontinuierlich beobachtet als auch die Verwendung des Produkts. Die digitale Abbildung eines realen Systems wird als digitaler Zwilling bezeichnet. Sie erlaubt Berechnungen mit dem digitalen Zwilling, deren Ergebnisse dann automatisch zur Steuerung oder Wartung des realen Systems verwendet werden können. Abb. 5.8 zeigt diesen Zusammenhang. Die Voraussetzungen für Industrie 4.0 sind u. a. die Realisierung einer geeigneten technischen Infrastruktur (z. B. die Verfügbarkeit von Telekommunikation der fünften Generation, 5G), Standardisierung der Kommunikationsprotokolle für die M2M-Kommunikation (da oft Maschinen und Geräte unterschiedlicher Hersteller zum Einsatz kommen), Verarbeitungskapazitäten für große Datenmengen, Sicherheit der Kommunikation (damit z. B. kein Fremder die Kontrolle eines autonomen Fahrzeugs übernehmen kann) und die Mitarbeiterakzeptanz. Akzeptanz bedeutet in diesem Fall z. B. die Erlangung neuer Qualifikationen, Anpassung an neue Prozesse oder das Teilen des Arbeitsplatzes und Zusammenarbeit mit kleinen Robotern (Cobots), die ermüdende oder gefährliche Arbeitsschritte übernehmen. Ein bereits funktionierendes Beispiel im Mittelstand wird nachfolgend beschrieben. Beispiel

Die Berger Gruppe produziert Maschinen für Firmen in vielen Branchen, die damit verschiedene Werkstücke herstellen (z.  B.  Roboterzellen für die Automobilbranche zum Entgraten von Gussteilen, Maschinen zum Fertigen von scharfen Messern für den Bereich Chirurgie oder Maschinen für die Herstellung von Töpfen im Bereich Haushaltswaren). Die Anlagen für die Messerherstellung vermessen die Schmiedestücke, um die Bearbeitung jedes Stücks genau zu planen und sie beobachten den gesamten Prozess mit Kameras (IHK 2015). Die einzelnen Roboter tauschen die Kameradaten

Abb. 5.8  Reale Systeme und ihre digitalen Zwillinge in Industrie 4.0 (in Anlehnung an (Siemens o. J))

122

5  Digitale Transformation

aus und entscheiden selbstständig, wie die Bearbeitung weiter erfolgen soll. Wenn sich ein Vorgang verzögert und das eingesetzte Werkzeug daher nicht verfügbar ist, können sie einen kürzeren Bearbeitungsvorgang an einem anderen Schmiedestück vorziehen. Durch Auswertung von Sensordaten kann auch der Maschinenverschleiß beobachtet werden, so dass vorausschauende Wartung automatisch initiiert werden kann, bevor es zu Ausfällen kommt. Die konsequente Anwendung von Industrie 4.0 kann sowohl zur weiteren Erhöhung der Effizienz in der Produktion führen als auch die Flexibilisierung der Produktion erhöhen, so dass Aufträge mit kleinen Losgrößen (im Extremfall von nur einem Einzelstück) kostengünstig ausgeführt werden können. Weiterhin sind Konzepte von Industrie 4.0 auch in der Landwirtschaft angekommen. Internet der Dinge in der Landwirtschaft

Die Firma Claas, größter Hersteller von Mähdreschern in Europa, und die Deutsche Telekom betreiben in Sachsen-Anhalt ein Pilotprojekt. Auf einem Feld voller Landmaschinen werden Informationen über die Fahrrichtung der Fahrzeuge, Fülle der Tankbehälter, Feuchtigkeit des Getreides usw. gesammelt. Sie werden von Sensoren der Fahrzeuge erhoben und per Mobilfunk an Rechner gemeldet. Diese verarbeiten die Daten und zeigen sie auf Bildschirmen der Fahrzeugfahrer an. Der Traktorfahrer kann dann rechtzeitig losfahren, um den vollen Korntank eines Mähdreschers im richtigen Moment zu leeren. Die Verbesserung der Prozesse wird auf 10–15 % eingeschätzt. Weitere Geräte und Lokationen können leicht einbezogen werden, so dass alle Beteiligten sofort über Menge und Qualität informiert werden und sich bei Bedarf koordinieren können. Weitere Produktivitätsgewinne von bis zu 30 Prozent seien zu erwarten. Die gemeinsam entwickelte Plattform soll auch anderen Unternehmen angeboten werden. Die Landwirtschaft wird als ein gutes Versuchsfeld angesehen, weil in ihr viele Partner mit unterschiedlichen Maschinen agieren und stark vom Wetter abhängen. (In Anlehnung an Handelsblatt, 20.08.2013) Abb.  5.9 zeigt eine grafische Abbildung dieser Anwendung, wobei sich die Fahrzeuge inzwischen auch autonom bewegen können.

5.5 Internet der Dinge, M2M und Industrie 4.0

Abb. 5.9  M2M in der Landwirtschaft am Beispiel der Firma CLAAS (Grothaus 2013)

123

Teil II Gestaltung der Digitalisierung

6

Mehr-Ebenen-Betrachtung bei der Gestaltung

Zusammenfassung

Kapitel 6 orientiert sich an der Einbettung von IS in den fachlichen und strategischen Zusammenhang in Unternehmen. Es beschreibt typische multidimensionale Gestaltungsansätze, wie sie beispielsweise das Business Engineering mit den Ebenen Strategie, Organisation und IS vorsieht. Kapitel 6 liefert damit den Überblick für die ebenenbezogenen Detailbetrachtungen in den Kapiteln 7 bis 9.

Betriebliche Anwendungen (s. Abschn.  9.1) unterstützen die Anwender innerhalb eines Unternehmens bei der Durchführung ihrer Aufgaben (s. Abschn. 2.1 und 9.1). Anwendungen bilden dabei die Geschäftslogik bzw. die fachlichen Funktionszusammenhänge ab. Daher sind bei der Gestaltung von Anwendungen grundsätzlich die fachlichen, also die nicht-technischen Aspekte in den Vordergrund zu stellen, und erst anschließend Fragen der technischen Umsetzung zu adressieren. Gerade im Zeitalter der Digitalisierung (s. Kap. 5) bedeutet dies jedoch nicht, dass Technologien eine nachgelagerte Bedeutung zukommt. Vielmehr sind bei der Diskussion fachlicher Gestaltungsalternativen die technologischen Potenziale einzubeziehen („IT als Enabler“). Dies gilt besonders für strategische Anwendungen (s. Abschn. 3.2.2.1), da Anpassungen an strategischen Anwendungen je nach technischer Ausgestaltung zu Veränderungen in der Unternehmensstrategie (z. B. die Realisierung neuer Geschäftsmodelle wie etwa in der Sharing Economy) führen. Aus diesen Überlegungen heraus lassen sich vier Gestaltungsziele formulieren: • Multidimensionalität. Die Gestaltung von Anwendungen berücksichtigt systematisch die Wechselwirkungen zwischen fachlichen und technischen Gestaltungsaspekten. Dazu sind mehrere Gestaltungsebenen bzw. -sichten zu unterscheiden, die zur Sicherung der Konsistenz von Gestaltungsaktivitäten auf den einzelnen Ebenen integrativ bzw. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_6

127

128

6  Mehr-Ebenen-Betrachtung bei der Gestaltung

wechselseitig miteinander verbunden sein sollten. Die Unterscheidung von Ebenen und Sichten variiert dabei nach dem jeweiligen Ansatz, sie reflektiert jedoch immer eine differenzierte und damit gezielte Adressierung bestimmter Gestaltungsdimensionen. • Formalisierung. In Anlehnung an die Ingenieurwissenschaften soll die Gestaltung bzw. Konstruktion von Anwendungen systematisch erfolgen, und dabei bewährte sowie untereinander abgestimmte Ergebniskonstrukte bzw. -artefakte verwenden. Unter einem Artefakt versteht die (Wirtschafts-)Informatik ein zumeist immaterielles Ergebnis eines menschlichen und/oder maschinell ausgeführten Prozesses zur Erstellung von (Dienst-) Leistungen (z. B. Informationsbestände, Softwaresysteme, Architekturen, Modelle, Quellcode, Textdokumente), die ihrerseits wiederum als Ressourcen in weiterführenden Wertschöpfungsprozessen Anwendung finden können (in Erweiterung von (Recktenfelderbäumer und Arnold 2015)). Das Einhalten vorgegebener Modellierungssprachen bzw. -notationen und die damit einhergehende Formalisierung reduziert die Beliebigkeit der Gestaltung und unterstützt die intersubjektive Verständigung – also das Verständnis zwischen verschiedenen Personen – bezüglich der Gestaltungsergebnisse. Verschiedene Beteiligte in und außerhalb des Unternehmens können so auch bei unterschiedlichen Wissensständen und Kontexten die Inhalte der Ergebnisartefakte schnell erfassen. Gegenüber der späteren Programmierung sollen bereits auf den fachlichen Ebenen semi-formale Modelle zum Einsatz kommen, die auf der einen Seite vorgegebene Elemente und Regeln enthalten, auf der anderen Seite aber auch gewisse Freiräume für die individuelle Modellgestaltung belassen. Beispielsweise geben Modellierungssprachen wie etwa BPMN (s. Abschn.  8.3.3) die Form und Semantik der Modellelemente vor (z.  B. ein Rechteck zur Darstellung einer Aktivität), überlassen aber die Bezeichnung der Aktivitäten dem jeweiligen Modellersteller. • Ergebnisorientierung. Die Gestaltung von Anwendungen soll sich an den Anforderungen der Nutzer orientieren (s. Abschn. 7.2). Dabei kann es sich sowohl um interne als auch um externe Kunden handeln. Ergebnisorientierung bedeutet, dass der Mehrwert für den Nutzer im Vordergrund steht und nicht-mehrwertgenerierende Aspekte wegzulassen sind. • IT als „Enabler“. Wie Teil 1 dieses Buchs gezeigt hat, gestalten Anwendungen die Aufgaben von Organisationen nicht nur durch (Teil-)Automatisierung rationeller, sondern tragen durch ihre Rolle als „Ermöglicher“ neuer oder verbesserter Lösungen auch zur Differenzierung im Wettbewerb sowie zur Gewinnsteigerung bei. Ein Beispiel ist die in Abschn. 1.1 skizzierte Großbank DNB. Inner- und überbetriebliche Anwendungen ermöglichen Verbesserungen in der operativen Effizienz von Unternehmen sowie das Entstehen neuer Geschäftsmodelle. Beides ist bei der Gestaltung zu berücksichtigen. Ein wichtiges Gestaltungsziel der Wirtschaftsinformatik ist die Integration im Sinne einer Abstimmung aller Gestaltungselemente, um die Effizienz des betrachteten Gesamtsystems (s. Abschn. 1.5) zu erhöhen. Abgestimmte Elemente, wie etwa Abläufe, Funktionen und Daten, bilden die Voraussetzung zur Realisierung von Automations- und Flexibilisierungspotenzialen bzw. von Kosten- und Wettbewerbsvorteilen. In der Realität besteht ­aufgrund der zahlreichen abzustimmenden Gestaltungselemente (z.  B.  Nutzergruppen,

6.1 Gestaltungsansätze

129

­ eschäftsprozesse, Endgeräte) und den zwischen ihnen bestehenden Abhängigkeiten eine G hohe Komplexität. Dazu tragen auch die vielen am Markt verfügbaren Anwendungen ­unterschiedlicher Hersteller (z. B. Microsoft, Oracle, Salesforce, SAP) bei, die teilweise auch vorkonfigurierte, untereinander in der Regel aber nicht kompatible Referenzlösungen umfassen (zu Referenzmodellen s. Abschn. 10.1).

6.1

Gestaltungsansätze

Gestaltungsansätze zielen auf eine Reduktion der Gestaltungskomplexität. Häufig als Methode bezeichnet, beschreiben sie zeitliche und inhaltliche Abhängigkeiten zwischen Gestaltungsaktivitäten und den dabei verwendeten Modellen bzw. Artefakten. Ansätze des Methoden Engineering (z. B. (Gutzwiller 1994; Winter 2011, S. 55 ff.)) skizzieren die Inhalte/Elemente solcher Methoden. Typische Bestandteile sind danach ein aus mehreren Schritten bzw. Gestaltungsphasen bestehendes Vorgehen („Wie ist bei der Gestaltung einer Anwendung vorzugehen?“) in Form eines Vorgehensmodells (s. Abschn. 13.2) und die innerhalb der Schritte/Phasen entstehenden Ergebnisartefakte (bzw. -dokumente oder -konstrukte). Weitere Bestandteile sind die bei der Anwendung der Methode benötigten Rollen/Personengruppen und Techniken/Werkzeuge (z.  B. fragebogenbasierte Informationserhebung, Prototyping, eingesetzte Modellierungssprachen) sowie ein übergreifendes Metamodell zur Konsistenzsicherung der Methodenelemente. Teilweise geben die Methoden (s. Abschn. 13.2) die Modelle (s. Abschn. 1.6) und die zum Einsatz kommenden Modellierungssprachen sowie Werkzeuge zur Modellierung explizit vor (z.  B. die Sprache eEPK (s. Abschn.  8.3.3) im Rahmen der ARIS-Methode (s. Abschn. 6.2)). In der Praxis sind zahlreiche methodische Ansätze zur Spezifikation fachlicher Zusammenhänge anzutreffen. Eine leistungsfähige Modellierungsmethodik ist dabei von einem einfacheren Modellierungsansatz zu unterscheiden (Sinz 2004): Während ein Modellierungsansatz sprachliche Konstrukte zur Modellbildung (Modellierungsobjekte/Modellelementtypen) sowie ein Metamodell (spezifiziert Modellierungsobjekte als Bausteine einer Modellierungssprache und deren Beziehungen) zur Gewährleistung eines abgestimmten Begriffssystems enthält, umfasst eine Modellierungsmethodik zusätzlich (s. Abb. 6.1): • Ein Architekturmodell, das Modellierungsebenen, Sichten und die Verwendungsmöglichkeit von Submodellen zur Reduzierung der Modellkomplexität spezifiziert, • ein Vorgehensmodell, das die Aktivitätsfolge während der Modellierung vorgibt, und • (Software-)Werkzeuge zur Unterstützung der Modellerstellung und -pflege. Die längste Tradition besitzen Gestaltungsansätze im Rahmen der Softwareentwicklung. So gehen Ansätze wie etwa das Wasserfallmodell (s. Abschn. 13.3) auf die 1970er-­Jahre zurück. Wie in Kap. 13 dargestellt, haben seitdem verschiedene Weiterentwicklungen zu stärker iterativen Vorgehensweisen, insbesondere der agilen Softwareentwicklung, geführt.

130

6  Mehr-Ebenen-Betrachtung bei der Gestaltung

Modellierungsmethodik Architekturmodell

Vorgehen im Rahmen der Modellierung

(Software-) Modellierungswerkzeuge

Modellierungsansatz Modellierungssprache Modellierungsobjekte (Modellelementtypen)

beschreibt

Metamodell

Abb. 6.1  Zusammenhang zwischen Modellierungsansatz und Modellierungsmethodik

Mit Aufkommen von betriebswirtschaftlicher Standardsoftware ab den 1980er-Jahren hat sich jedoch gezeigt, dass die Softwareentwicklungsmethoden zwar von fachlichen Anforderungen ausgehen, nicht jedoch die Gestaltung der Organisationsstrukturen selbst im Fokus haben. Gerade das Hinterfragen bestehender organisatorischer Strukturen, um damit die Potenziale zentralisierter funktionsübergreifender ERP-­Anwendungen (s. Kap. 10) zu erschließen, fand in diesen Methoden zu wenig Beachtung. In den 1990er-Jahren sind daher Methoden des Business Process (Re-)Design (BPR) entstanden (Davenport und Short 1989; Österle 1995; Rummler und Brache 1995) die bestehende Organisationsstrukturen in Frage stellen und den Geschäftsprozess als Gestaltungsobjekt in den Vordergrund rücken. Nachdem integrierte Anwendungen Informationen über Organisationseinheiten hinweg bereitstellen und abteilungsübergreifende Abläufe ermöglichen, hat die Gestaltung der Ablauforganisation an Bedeutung gewonnen. Gemäß der Ergebnisorientierung geht es dabei nicht primär um die Unterstützung der intern in einem Unternehmen durchgeführten Funktionen (und der Orientierung an Suboptima einzelner funktionaler Bereiche), sondern um das Zusammenwirken aller Funktionen im Rahmen eines Ablaufs, dessen Nutzen einen Wertbeitrag beim (internen oder externen) Kunden bildet (s. Abb. 6.2). Zur Überwachung der Leistung von Prozessen dienen Messgrößen/Kennzahlen sowie eigene Zuständigkeiten und Aktivitäten der Prozessführung (s. Abschn. 7.4 und 8.5), welche auf die Bewertung, Steuerung und Kontrolle von Unternehmen ausgerichtet sind. cc Prozess/Geschäftsprozess  Ein Prozess ist eine logisch zusammenhängende Kette von Aktivitäten, die mindestens einen Start- und Endpunkt besitzt und auf Basis eines definier­ ten Inputs die Leistungserbringung für einen bestimmten Nutzer spezifiziert. Prozesse im betrieblichen Umfeld bzw. Geschäftsprozesse sind auf die Er­zielung eines messbaren positiven Wertschöpfungsbeitrags und die wiederkehrende Bearbeitung betrieblicher Objekte (z. B. Aufträge, Rechnungen) über verschiedene Organisationseinheiten hinweg für einen (internen oder externen) Kunden oder einen Markt ausgerichtet. Mit der Digitalisierung (s. Kap. 5) steigt der Umfang der IT-­Unterstützung von Geschäftsprozessen, was eine Voraussetzung für sog. „Realtime“-Geschäftsprozesse darstellt (Alt 2008, S. 59 ff.).

6.1 Gestaltungsansätze

131

Prozessführung

Organisationseinheit 1

Organisationseinheit 2

Organisationseinheit 3

Messgrößen Organisationseinheit 4

Geschäftsprozess Lieferant

Teilprozess1

Teilprozess 2

Teilprozess 3

Teilprozess 4

Kunde

IS

Abb. 6.2  Prozessorientierung (in Anlehnung an (Österle 1995, S. 20))

Ein idealtypisches Vorgehen bei der (Neu-)Gestaltung betrieblicher Strukturen verläuft Top-down von der Unternehmensstrategie hin zur Implementierung eines konkreten IS (s. Tab. 6.1). Es legt bereits zu Beginn die Zielstellung und die wichtigsten Elemente des geplanten Systems fest und detailliert diese im weiteren Verlauf der Entwicklung. Dies folgt der Logik, wonach zwar bei der Digitalisierung fachliche und technische Gestaltungselemente zu verzahnen sind, gleichzeitig aber der Einsatz der IT die geschäftlichen Ziele des Unternehmens unterstützen soll und keinen Selbstzweck darstellt. Zunächst geht es um die strategische Positionierung des Unternehmens im Wettbewerb, anschließend um die Ausgestaltung der organisatorischen Elemente (Ablauf- und Aufbauorganisation) und anschließend um die Fragen der technischen Umsetzung. Zur Strukturierung des Zusammenspiels zwischen diesen Gestaltungsaspekten unterscheiden Ansätze wie das Business Engineering (BE) (Österle und Winter 2003) mehrere Gestaltungsebenen, worin die Unternehmensorganisation, und hier insbesondere der Geschäftsprozess, das Bindeglied zwischen einer Strategie- und einer IS-Ebene bildet. Gestaltung bezeichnet hierbei sowohl die Erst- als auch die Weiterentwicklung des betrieblichen Systems auf diesen verschiedenen Ebenen. Im Gegensatz zu jungen Start-up-Unternehmen ist dabei eine erstmalige Gestaltung als „grüne Wiese“-Ansatz bei etablierten Unternehmen nur selten möglich, da dort bereits bestehende Strukturen zu berücksichtigen sind. Grundsätzlich können die Veränderungsmaßnahmen nicht nur Top-down von den übergeordneten Themenstellungen der Strategieebene, sondern auch von der Fachseite auf Organisationsebene (z.  B.  Realisierung effizienterer Bestellprozesse) sowie Bottom-up (s. Abschn. 13.2) von der IT getrieben sein. Im letzteren Falle sind beispielsweise die Einführung einer neuen betriebswirtschaftlichen Standardsoftware (s. Kap. 10) oder das Aufkommen disruptiver Technologien (d.  h. neue technologische Entwicklungen, die bestehende Technologien ersetzen, wie z.  B.  Blockchain (s. Abschn.  4.3.4), Big Data oder künstliche Intelligenz (s. Abschn. 11.2.6 und 2.3.3.3)) Ausgangspunkte für Veränderungen von inner- und überbetrieblichen Prozessen, darauf aufbauenden Organisationsstrukturen

132

6  Mehr-Ebenen-Betrachtung bei der Gestaltung

Tab. 6.1  Schritte und Aktivitäten eines BPR-Projekts (Kettinger et al. 1997, S. 61) Phase 1. Vision 2. Initiierung 3. Diagnose 4. Redesign 5. Ausbau 6. Evaluation

Aktivitäten Überzeugen des Managements, Visionsentwicklung, Identifizierung der Reengineering-Potenziale Organisation des Reengineering-Teams, Projektplanung, Bestimmung der Kundenanforderungen und Leistungsziele Erfassung, Dokumentation und Analyse des Ist-Prozesses mit Prozessvarianten, Mengengerüst und Potenzialen Definition und Analyse des Soll-Prozesses, Prototyp und Gestaltung des Soll-­Prozesses, Analyse und Gestaltung der IT Durchführung der Reorganisation, Anwendertraining, operative Implementierung des Soll-Prozesses Evaluation der Prozessleistung, Verbindung mit kontinuierlichen Verbesserungsprogrammen

sowie ggf. sogar von übergeordneten Geschäftsstrategien, wie z. B. die Anpassung des Produkt- und Dienstleistungsportfolios oder die veränderte Positionierung im Partnernetzwerk. Bei Projekten zur Transformation einzelner Prozesse oder gesamter Unternehmen sind immer wieder typische Schritte/Aktivitäten/Phasen zu durchlaufen (s. Tab.  6.1). Ausgangspunkt bildet dabei das Festlegen der Eckpunkte der zukünftigen Lösung und das Überzeugen von Entscheidern (Phase 1: Vision). Ein bewährtes Element ist die Orientierung an Kundenbedürfnissen und die Entwicklung einer Kundenprozessvision entlang einer Customer Journey (s. Abschn. 7.2). Es folgt die Initiierung des Transformationsprojektes und erst in der dritten Phase (Diagnose) die Erfassung des Ist-Zustandes. Dies ist dadurch begründet, dass bei einer zu intensiven Untersuchung bestehender Strukturen die Gefahr besteht, dass die in der folgenden Phase angesiedelte Lösungsfindung im Ist-Zustand verhaftet bleibt, und ein Hinterfragen des aktuellen Zustands zu wenig stattfindet. In der vierten Phase (Redesign) sind dann die zukünftigen Prozessstrukturen und deren technische Unterstützung sowie deren Einbettung in die bestehenden Unternehmensstrukturen zu konzipieren. Hierbei ist ein Nebeneinander von zwei Konzepten hervorzuheben: während das BPR eine periodisch stattfindende Neugestaltung vorsieht, zielen Ansätze der kontinuierlichen (Prozess-)Verbesserung (Continuous (Process) Improvement, CI) (Neumann et al. 2012) auf eine kontinuierliche Verbesserung der entworfenen Strukturen. Nach den Ansätzen zur Softwareentwicklung und zur Prozessentwicklung sind in den 2000er-Jahren die Gestaltungsansätze für die Geschäftsmodellentwicklung entstanden. Obgleich das BPR ebenfalls strategische Aspekte diskutiert, so stehen hier jedoch Fragen der Organisationsgestaltung im Vordergrund. Dedizierte Gestaltungsansätze auf strategischer Ebene sind gegenüber den software- und organisationsorientierten Methoden infolge der hohen Abstraktion der Gestaltungsaspekte weniger formalisiert. Im Mittelpunkt dieser Ansätze stehen die Identifikation und Modellierung neuer IT-basierter Geschäftsmodelle, wobei aufgrund des innovativen Charakters dieser Aufgaben die Einbeziehung kreativer Elemente von besonderer Bedeutung ist. Zur Erarbeitung derartiger Lösungen hat sich das Design Thinking etabliert, das Prinzipien agiler Softwareentwicklungsmethoden mit

6.2 Gestaltungsebenen

VERSTEHEN

BEOBACHTEN

133

SYNTHESE

IDEEN

PROTOTYPING

TESTEN

Abb. 6.3  Vorgehen im Design Thinking (Grots und Pratschke 2009, S. 20)

­ reativitätstechniken verbindet. Das Ergebnis dieses Ansatzes ist jedoch keine fertiggeK stellte Software, sondern ein testbarer Prototyp als Basis für (weitere) Diskussionen und Konkretisierungen des Geschäftsmodells. Ein typisches Vorgehen für das Design Thinking zeigt Abb. 6.3.

6.2

Gestaltungsebenen

Wie in Abschn. 1.6 dargestellt, bilden Unternehmensmodelle eine Grundlage zur Gestaltung betrieblicher Systeme. So enthält das St. Galler Managementmodell betriebliche IS als ein Element, das in Abhängigkeit der Unternehmensziele zusammen mit den übrigen Gestaltungselementen zu entwickeln ist. Da die Komplexität realer betrieblicher Systeme die gleichzeitige Bearbeitung aller Gestaltungsaspekte erschwert, ist analog der Konstruktion physischer Gebäude eine Gestaltung bzw. Beschreibung in Teilmodellen sinnvoll. Während beim Hausbau Pläne für Grundriss, Statik oder Installationen bestehen, so sind dies bei der Gestaltung betrieblicher IS unterschiedliche Modelle für die Geschäftsleitung, die Fachabteilung oder den (internen oder externen) Softwareentwickler. Obgleich diese Modelle bezüglich der Abstraktionsebene und der abgebildeten Elemente voneinander abweichen, so sollten sie sich doch möglichst konsistent ineinander überführen lassen. Zwei Charakteristika seien hier genannt: • Gestaltungsebenen. In multidimensionalen Modellen beschreibt die Ebenenbildung hierarchische Abhängigkeiten zwischen den Modellen, wie sie bei der Unterscheidung von Strategie-, Organisations- und IS-Ebene anzutreffen sind. Daneben findet sich der Begriff der Sichten, der – wenngleich nicht inhaltlich übereinstimmend von allen Autoren verwendet – die Zerlegung eines komplexen Modells in Teilmodelle (z. B. Unterscheidung von Daten- und Funktionssichten) auf einer oder mehreren Ebenen vorsieht. Die Rangfolge der Sichten ergibt sich aus dem Anwendungskontext und ist nicht allgemein festgelegt. So rückt die IS-Entwicklung meist die Funktions- und die Datensicht in den Fokus, wohingegen im Rahmen von organisatorischen Umstrukturierungen

134

6  Mehr-Ebenen-Betrachtung bei der Gestaltung

die aufbau- und die ablauforganisatorischen Sichten im Vordergrund stehen. Es ist möglich, dass eine Sicht auf einer spezifischen Ebene aufgrund der hohen Komplexität nicht durch ein einzelnes Modell darstellbar ist. In diesen Fällen erfolgt die Modellbildung auf mehreren Abstraktionsebenen: ein verdichtetes Grobmodell enthält beispielsweise die Strukturierung der Hauptkomponenten sowie deren Zusammenhänge, während die feinere Beschreibung von Komponenten bzw. Teilbereichen eines Grobmodells dann in untergeordneten Modellen erfolgt. • Architekturmodelle. Ergebnisartefakte auf den Gestaltungsebenen sind häufig semi-­ formale Modelle, die mit vorgegebenen Elementen und Regeln (z. B. Verwendung bestimmter Modellierungsnotationen) arbeiten, dabei aber Freiräume für die individuelle Gestaltung belassen. Architekturen zeichnen sich dadurch aus, dass sie die Elemente eines Systems (s. Abschn. 1.5) und die Beziehungen zwischen diesen Elementen sowie mit ihrer Umwelt darstellen. So zeigen Unternehmensarchitekturen (Enterprise Architectures) die Grobstruktur eines Unternehmens mit seinen Teilbereichen (Stellen, Aufgaben, IS etc.) und den Beziehungen zu Lieferanten und/oder Kunden ((Winter und Aier 2014), s. Abschn.  3.2.2.2). Beispiele für Ergebnisartefakte in diesem Kontext bilden etwa das Geschäftsnetzwerkmodell, das Organigramm oder das Ablaufdiagramm. Der bereits in Abschn. 6.1 erwähnte Business Engineering (BE)-Ansatz (Österle und Winter 2003) unterscheidet drei Gestaltungsebenen: (1) Die Strategieebene legt für ein Unternehmen die strategischen Eckpunkte fest. Dazu zählen etwa die Identifikation der Prozessvision, die Positionierung im Wettbewerb (Märkte und Leistungen) oder die Zusammenarbeit mit Partnern und die entsprechenden Werte-/ Leistungsflüsse. Modelle auf der Strategieebene zeigen typischerweise die in einer Wertschöpfungskette bzw. einem Wertschöpfungsnetzwerk positionierten Unternehmen (bzw. Geschäftseinheiten) mit den sie verbindenden Leistungsflüssen (Alt 2008, S. 8). Kap. 7 enthält dazu entsprechende Methoden und die dabei verwendeten Modelle. Daneben liefert die Strategieebene den Ausgangspunkt für die Prozessführung, indem sie aus den Zielstellungen der Kunden (s. Abschn. 7.2) und den daraus abgeleiteten kritischen Erfolgsfaktoren die strategischen Führungsgrößen/Kennzahlen für das Prozesscontrolling (Process Performance Management) ableitet (zu Kennzahlen und Kennzahlensystemen siehe auch Abschn. 3.2.3.2). In diesem Sinne verbindet die Strategieebene klassische Ansätze zur strategischen Positionierung wie etwa den Market-Based View (Porter 1999) oder den Resource-­Based View (Hamel und Prahalad 1990) mit Ansätzen zur Produkt-/ Leistungsmodellierung (Jørgensen 2006), Ansätzen zur Zielsystembildung (z. B. Balanced Scorecard (Kaplan und Norton 1997), s. Abschn. 3.2.4 und 7.4) und vor allem mit Ansätzen zur Geschäftsmodelldefinition (z. B. (Weill und Vitale 2001)) sowie zur Geschäftsnetzwerkkonstruktion (z. B. (Hagel und Singer 1999)). Die Strategieebene liefert ­damit wichtige Vorarbeiten für die Prozessmodellierung und für die operative Prozessmessung (Prozessführung). (2) Die Organisationsebene konkretisiert die auf strategischer Ebene festgelegten Strukturen und unterscheidet grundsätzlich zwischen der Prozessgestaltung und der Prozessführung.

6.2 Gestaltungsebenen

135

Die Prozessgestaltung besteht aus dem fachlichen Prozessentwurf und unterscheidet wiederum die Gestaltung der Ablauf- und der Aufbauorganisation. Seitens der Ablauforganisation bringen Prozessmodelle die abstrakteren Modelle der Strategieebene in einen zeitlichen Zusammenhang und ordnen die Aktivitäten den verschiedenen ausführenden Organisationseinheiten (Stellen, Verantwortlichkeiten, Organisationseinheiten) der Aufbauorganisation (s. Abschn. 1.6.1) zu. Kap. 8 beschreibt entsprechende Methoden und die dabei entstehenden Modelle. Durch die Orientierung am Kundennutzen stellt die Prozessgestaltung einerseits die geforderte Qualität und Quantität (Effektivität im Sinne von „Doing the right things“) sicher. Andererseits bildet die operative Prozessführung mit der Ableitung der operativen Führungsgrößen/Kennzahlen, ihrer Zuordnung zu konkreten Prozessen/Teilprozessen und Organisationseinheiten sowie der Bestimmung konkreter Sollkennzahlenwerte die Voraussetzung für Auswertungen zur Prozesseffizienz (im Sinne von „Doing things right“). ( 3) Die IS-Ebene spezifiziert, welche softwaretechnischen Bausteine (Anwendungen und deren Module bzw. „technische Services“) zur Unterstützung von Geschäftsprozessen und -modellen zum Einsatz kommen. Dies umfasst in erster Linie die Ebene der Anwendungssoftware und kann, sofern der Detailgrad dies erfordert, weitere Subebenen der IS-Ebene ­umfassen (z.  B. die technologische Infrastruktur mit Hardware- und Netzwerkkomponenten). Ein zentrales Gestaltungsziel auf IS-Ebene bildet die ­Abstimmung mit den fachlichen Gestaltungsebenen im Sinne eines Business-/ IT-Alignment bzw. Strategic Alignment (s. Abschn. 3.2.2.2). Weitere Ziele bilden die Transparenz und Vereinfachung sowie die Flexibilität bzw. Agilität und die Wiederverwendung fachlicher Bausteine/Softwarekomponenten. Kap. 9 beschreibt derartige Methoden und die dabei entstehenden Modelle. Diese lassen sich weiterhin dem fachlichen Entwurf und damit der Abbildung der Geschäftslogik zuordnen, während die Realisierung der Software einen Teil der Softwareentwicklung darstellt (s. Teil 4). Eine Ausdifferenzierung von Subebenen kann abhängig vom Gestaltungsziel stattfinden. So fasst z. B. das Framework von Zachman (2008) die Strategie- und die Organisationsebene zusammen, während die Architektur integrierter Informationssysteme (ARIS) als ein verbreiteter Strukturierungsansatz im deutschsprachigen Raum die Strategieebene nicht unmittelbar erwähnt. Wie in Abschn. 8.3.3 ausgeführt, unterscheiden die fünf Sichten von ARIS mit Steuerungs- (bzw. Prozess-), Daten-, Funktions-, Leistungs- und Organisationssicht ähnliche Elemente wie die Organisations- und IS-Ebene des BE (s. Abb. 6.4). Wechselwirkungen zwischen den Gestaltungsebenen zeigen sich etwa darin, dass Anwendungen die Voraussetzung für neue Geschäftsmodelle (z.  B.  Cloud Computing, s. Abschn. 4.4.3) liefern, oder innovative Geschäftsprozesse (z. B. das One Click Ordering von Amazon) einen strategischen Wettbewerbsvorteil unterstützen können. Die Strategie- und die Organisationsebene bilden auch den Ausgangspunkt für die Prozessführung. Diese leitet aus den strategischen Unternehmenszielen Führungsgrößen ab, die meßbare Ziele für die Prozessmessung und -steuerung liefern. Abb. 6.5 zeigt die Zuordnung von Beschreibungselementen/Modelltypen der Strategie- und Organisationsebene (s. Abb. 6.4) zu diesen beiden Bereichen sowie deren Beziehungen.

136

6  Mehr-Ebenen-Betrachtung bei der Gestaltung

Architektur integrierter Informationssysteme (ARIS)

Business Engineering (BE) Strategieebene

Organisationssicht Organigramm

Datensicht

Datenmodell

Organisationsziele

Stakeholdermodell

Geschäftsmodell

Kritische Erfolgsfaktoren

Kundenprozessmodell

Geschäftsnetzwerkmodell

Strategische Führungsgrößen

SteuerungsSicht

Funktionssicht

Ereignisgesteuerte Prozesskette

Funktionsmodell

Top-down-Vorgehen Organisationsebene

Bottom-up-Vorgehen

Prozesslandkarte

Fachliches Servicemodell

Leistungsverzeichnis

(Kooperatives) Prozessmodell

Prozesskontextdiagramm

Organigramm

Workflowmodell

Qualitätsprofil

Prozessführungsgrößen

Leistungssicht Top-down-Vorgehen

Leistungsmodell

Informationssystemebene

Anwendungslandschaft

Bottom-up-Vorgehen Technisches Servicemodell

Datenmodell

Abb. 6.4  Gestaltungs- bzw. Beschreibungsebenen bei ARIS und im Business Engineering mit beispielhaften Beschreibungselementen/Modelltypen (in Anlehnung an (Scheer 1992; Österle und Blessing 2005))

Organisationsziele

Prozessgestaltung / Prozessentwurf

Geschäfts- und Prozessvision

• • • • •

Stakeholdermodell Anforderungskatalog Kundenprozessmodell Geschäftsmodell Geschäftsnetzwerkmodell

Leistungsanalyse

• •

Leistungsverzeichnis Qualitätsprofil

Ablaufplanung

• • • •

Prozesslandkarte Prozessmodell Fachliches Servicemodell Workflowmodell

Prozessführung

Strategieebene

Kritische Erfolgsfaktoren Strategische Führungsgrößen

Organisationsebene

ProzessFührungsgrößen

Abb. 6.5  Zusammenhang zwischen Prozessgestaltung/Prozessentwurf und Prozessführung

6.2 Gestaltungsebenen

137

Tab. 6.2  BPR und CI am Beispiel der Herstellung und des Vertriebs von Uhren Business Process Reengineering/ Redesign (BPR) Aufbau eines Marketingkanals in sozialen Medien zusätzlich zum telefonischen Marketing Realisierung einer „Uhrenwunschliste“ im Uhren-Onlineshop, über die Kunden ihre Anforderungen an eine „perfekte“ Uhr angeben können Umstellung auf eine automatisch ausgelöste Komponentenbestellung bei den Zulieferern auf Basis der softwaregestützten Produktionsplanung des Uhrenherstellers

Continuous Process Improvement (CI) Konzentration des telefonischen Marketings in den Nachmittags- und Abendstunden Bessere Anpassung des Uhrensortiments und der Gestaltungsalternativen an bestimmte Kundengruppen

Einführung eines zusätzlichen manuellen Kontrollschrittes zur Vermeidung von Fehlern bei Mengenangaben und Komponentenbezeichnungen vor dem Versand handschriftlich ausgefüllter Komponentenbestelllisten vom Uhrenhersteller an die Zulieferer

Zur Veranschaulichung der Inhalte von Teil 2 dient nachfolgend das Beispiel der Herstellung und des Vertriebs von Uhren. Hierbei handelt es sich um einen (fiktiven) Uhrenhersteller, der seine Produkte bislang über klassische Kanäle (z. B. Telefon, physische Kataloge, Shops) vertreibt und diese distributionsseitigen Prozesse verbessern möchte (Alt 2008, S. 227 ff.). So kommen gegenwärtig keine elektronischen Kanäle zum Einsatz, die Aktualisierung der (physischen) Kataloge findet nur in längeren Intervallen (d. h. jährlich) statt und es fehlt neben Telefon und Shop eine zeitgemäße Kundeninteraktion. Der Uhrenhersteller führt daher ein Reengineering-Projekt durch, um die Potenziale eines elektronischen Produktkataloges (s. auch Kap. 12) zu erschließen (z. B. Aktualität des Kataloges, Effizienz des Bestellprozesses), um mit einem Uhrenkonfigurator die Individualisierungsmöglichkeiten der Produkte zu verbessern und um mittels einer Präsenz in Social Media eine möglichst interaktive Kundenbeziehung zu realisieren. Aufbauend auf diesem Szenario zeigt Tab. 6.2 mögliche grundlegende bzw. radikale (BPR) sowie graduelle (CI) (s. Abschn. 6.1) Veränderungsmaßnahmen. Die Struktur der nachfolgenden Kapitel in Teil 2 orientiert sich an den in Abb. 6.4 dargestellten drei BE-Ebenen mit ihren Beschreibungselementen und Modelltypen. Im Sinne eines Top-down-orientierten Vorgehens (s. Abschn. 6.1) konzentriert sich Kap. 7 zunächst auf die strategische Gestaltung und Führung von betrieblichen Systemen, bevor Kap. 8 die systematische Entwicklung der Ablauf- und Aufbauorganisation in den Vordergrund stellt. Kap.  9 beschreibt schließlich Gestaltungs- und Modellierungsansätze auf IS-Ebene als Vorbereitung für die Ausführungen zur Softwareentwicklung in Teil 4.

7

Strategieebene

Zusammenfassung

Kapitel 7 beschreibt strategische Gestaltungsaspekte der digitalen Transformation. Hier zeigt sich, wie sich Kundenanforderungen mit den grundsätzlichen Fragen des Geschäftsmodells wie der Positionierung im Wettbewerb, den Partnerverflechtungen und den Leistungsbestandteilen modellhaft abbilden lassen. Neben der Gestaltung geht das Kapitel auf die Bedeutung von Unternehmenszielen als Basis für die Umsetzung der strategischen Prozessführung ein.

7.1

Gestaltungsinhalte auf Strategieebene

Die Strategieebene legt in Abstimmung mit der allgemeinen Unternehmensstrategie die grundsätzliche Ausrichtung und Positionierung eines Unternehmens im Wettbewerb fest. Ein solches Top-down-Vorgehen steht zu Beginn von Start-up-Unternehmen und sollte auch bei bestehenden Unternehmen (sog. „Incumbents“) regelmäßig im Sinne eines Hinterfragens des Geschäftsmodells bzw. einer Weiterentwicklung der digitalen Transformation erfolgen. Grundsätzlich sind die dabei zum Einsatz kommenden Modelle auf organisatorische Einheiten beliebiger Größe anwendbar, z. B. auf ein gesamtes Unternehmen, einen Unternehmensteilbereich oder auch auf ein Unternehmensnetzwerk. Die strategische Positionierung umfasst einerseits die Entwicklung der Kundenvision, die Festlegung der relevanten Kundengruppen einschließlich der Erhebung von Kundenprozessen und der darauf aufbauenden Ableitung von Kundenkontaktkanälen. Zum anderen bestimmt sie die eigenen Kernkompetenzen und die daraus resultierenden Produkt-/Leistungsangebote für den Kunden, die Identifizierung von Wertschöpfungspartnern und die Etablierung von Leistungsaustauschbeziehungen, die Grobkonzeptionierung der Prozessarchitektur sowie die Festlegung der strategischen Prozessführung (Winter 2011, S. 76 f.). Zu den Modelltypen der Strategieebene zählen:

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_7

139

140

7 Strategieebene

• Das Kundenprozessmodell (s. Abschn. 7.2) beschreibt zunächst aus Kundensicht, welche Aktivitäten zur Lösung seiner Bedürfnisse zu durchlaufen und welche Vorleistungen von anderen Stakeholdern (z. B. Unternehmen) dafür erforderlich sind. Ein Unternehmen kann daraus ableiten, welche Aktivitäten des Kundenprozesses es mit seinem Leistungsprogramm adressieren/unterstützen möchte. • Das Geschäftsmodell (s. Abschn. 7.3) spezifiziert die Positionierung des Unternehmens im Markt. Es enthält u.  a. Informationen zum (differenzierenden) Geschäftszweck/ Kundennutzen, den Kernressourcen/-aktivitäten und zu den finanziellen Konsequenzen des Geschäftsbetriebs. Zusätzlich bildet das Geschäftsnetzwerkmodell (s. Abschn. 7.3) das Zusammenwirken von Unternehmen in einem Geschäfts- bzw. Wertschöpfungsnetzwerk im Sinne einer Geschäftsarchitektur ab. Die strategische Prozessführung (Process Performance Management/Prozesscontrolling) (s. Abschn. 7.4) bildet die für ein Unternehmen festgelegten strategischen Ziele und die davon abgeleiteten (kritischen) Erfolgsfaktoren sowie strategischen Führungsgrößen bzw. Kennzahlen ab und stellt sicher, dass die Gestaltung des fachlichen Entwurfs den geschäftlichen (Ziel-)Vorgaben folgt.

7.2

Kundenprozessmodell

Ausgangspunkt zur Identifikation der (künftig) angebotenen Leistungen eines Unternehmens sind die Bedürfnisse der Zielkunden als wesentliche Stakeholder (s. Abschn.  13.4) eines Unternehmens, die sich in Kunden- bzw. Verwendungsprozessen niederschlagen. Dazu sollte sich die Gestaltung an der Kundenperspektive (Outside-In) im Sinne einer Customer Dominant Logic (Heinonen et al. 2010) und weniger an der Unternehmensperspektive (Inside-Out) orientieren. Gerade innovative Start-up-Unternehmen haben in verschiedenen Branchen (z.  B.  Fintech-Unternehmen im Finanzbereich) die Potenziale einer kundenorientierten Transformation (s. Abschn. 2.4) aufgezeigt. Durch Kundenbefragungen, die Beobachtung von Kundenmeinungen in sozialen Medien oder die Zusammenarbeit mit Testanwendern können Unternehmen frühzeitig auf Kundenbedürfnisse und mögliche Verbesserungen aufmerksam werden. Auf dieser Basis lassen sich Kundenprozessmodelle entwerfen. cc Kundenprozessmodell  Das Kundenprozessmodell reflektiert den Leistungsbedarf eines Kunden aus seiner Sicht. Es spezifiziert die Aktivitäten beim Kunden und die benötigten Leistungsbestandteile zur Deckung eines häufig komplexen - da aus mehreren Leistungsbestandteilen zusammengesetzten - Kundenbedürfnisses für ein bestimmtes Kundensegment. Ziel ist die Zuordnung der aus Kundensicht nachgefragten zu den aus Unternehmenssicht angebotenen Leistungen. Kundenprozessmodelle enthalten daher einerseits die Aktivitäten auf Kundenseite (rechter Bereich in Abb. 7.1) und andererseits die korrespondierenden Aktivitäten innerhalb des Unternehmens (linker Bereich in Abb. 7.1). Im Vordergrund des Kundenprozesses stehen nicht die

7.2 Kundenprozessmodell Leistungsprozess „Kundenwerbung“ Versand Newsletter

141 Kundenprozess „Uhr kaufen“ Informieren über Uhrenhersteller

Vorbereitung und Ausstrahlung Radiowerbung Verlinkung von externen Preisvergleichsportalen

Aufrufen des Uhren-Onlineshops

Leistungsprozess „Herstellung von Uhren und Kaufabwicklung“ Anzeige von Uhrenmodellen und deren Ausstattungs- und Gestaltungsvarianten Ausstattungsspezifische Preiskalkulation

Suche nach Uhrenmodellen

Konfiguration von Uhrenmodellen

Anzeige des Vergleichs verschiedener bepreister Uhrenmodelle und Ausstattungsvarianten

Preisvergleich zwischen verschiedenen Uhrenmodellen und Ausstattungsvarianten

Bereitstellung eines Dialogs zur Eingabe der Kunden- und Zahlungsinformationen

Kauf eines Uhrenmodells

Zustellung der Buchungsbestätigung Herstellung der Uhr Versand der Uhr

Uhr erhalten

Abb. 7.1  Kundenprozessmodell mit Leistungsprozessen im Uhren-Beispiel

Produkte bzw. Dienstleistungen des Unternehmens und der Prozess ihrer Erstellung, ­sondern der Verwendungsprozess aus Sicht der Kunden, welcher als komplexes Leistungsbündel mehrere Produkte/Dienstleistungen des Unternehmens oder externer Anbieter umfassen kann. Ansätze zur Ableitung von Kundenprozessen liefern (Alt 2008, S. 173): • Die Phase des Kundenprozesses, wonach sich die Kunden in einer Anforderungs-, Akquisitions-, Besitz- oder Entsorgungsphase befinden können. Beispielsweise unterscheiden sich dadurch Neu- und Bestandskunden. • Der Lebensabschnitt des Kunden, wonach sich Kundenbedürfnisse an bestimmten „Life Events“, wie Schulabschluss, Berufsanfang, Firmengründung etc. orientieren. • Der Kundenwert (Customer Lifetime Value) bewertet Kunden nach ihrem getätigten und ihrem zukünftigen Geschäftsvolumen. Ein Beispiel für die Verwendung des Kundenwertes ist die Segmentierung von Kunden im Rahmen von Loyalitätsprogrammen.

142

7 Strategieebene

• Die Rolle im Wertschöpfungsprozess, z. B. ausgehend von Privatkunden (Business-­to-­ Consumer) und Geschäftskunden (Business-to-Business) in Händler, Endkunden etc. (s. Abschn. 5.2.1). • Die Region des Kunden, wonach insbesondere international agierende Unternehmen zusätzlich nach lokalen, nationalen oder globalen Kunden segmentieren. Abb.  7.1 setzt das Uhren-Beispiel fort. Für den Kundenprozess „Uhr kaufen“ zeigt es, welche Teilaspekte bzw. Aktivitäten aus Kundensicht wichtig sind (z. B. Suche nach Uhrenmodellen, Preisvergleiche) und welche Teilaktivitäten der übergeordneten Leistungsprozesse „Herstellung von Uhren und Kaufabwicklung“ sowie „Kundenwerbung“ auf die Unterstützung der Kundenaktivitäten ausgerichtet sind und mit diesen in gleichzeitiger Beziehung stehen (gestrichelte Kanten). Für ausgewählte Gestaltungsaspekte lassen sich zusätzliche Modelle einsetzen. So ist angesichts der zahlreichen, für die Kundeninteraktion verfügbaren Kanäle eine abgestimmte Nutzung im Rahmen von Cross-Channel-Management-Ansätzen notwendig. Eine solche hybride Kundeninteraktion geht von einem Nebeneinander mehrerer Kanäle und einem Wechsel während einer Kundeninteraktion im Sinne von Customer Journeys aus. Diese beginnen beim ersten Auftreten eines Kundenbedürfnisses und erstrecken sich über das Informieren und Abwägen verschiedener Leistungsangebote, den Kauf von Produkten und/oder Dienstleistungen sowie dem nachfolgenden Aftersale-Service bis hin zu langfristigen loyalitätsfördernden Maßnahmen (Heinemann 2018, S. 182 ff.). Eine besondere Berücksichtigung erfahren dabei die Kontaktkanäle bzw. Touchpoints, über welche die Kunden mit dem Unternehmen und ggf. auch anderen Akteuren (z. B. ­Kunden-Communities, Vergleichsportale, Social Media) leistungsbezogene Informationen (z. B. Produktrezensionen, Leistungsangebote, Erfahrungen aus dem sozialen Umfeld) austauschen. Hier sind sowohl Online- als auch Offline-Kontaktkanäle in die Customer Journeys einzubeziehen. Abb. 7.2 zeigt beispielhaft eine Customer Journey, die auf dem in Abb. 7.1 dargestellten Ablauf des Kundenprozesses aufbaut und den Aktivitäten die genutzten Interaktionskanäle zwischen Kunde und Unternehmen zuordnet. So kann ein Uhren-Kunde zunächst über E-Mail-Newsletter oder Radiowerbung Informationen zum Uhrenhersteller erhalten, und anschließend den Uhren-Onlineshop direkt aufrufen oder über ein Vergleichsportal dahin gelangen. Die nachfolgenden Kundenaktivitäten von der Suche bis zur Buchung eines Uhrenmodells erfolgen über den Kanal des Uhren-Onlineshops, bevor am Ende die gekaufte Uhr über den Postweg den Uhren-Kunden erreicht.

7.3

Geschäftsmodell und -netzwerk

Der Kundenprozess bildet einen zentralen Ausgangspunkt zur Ableitung von Geschäftsmodellen. Da in arbeitsteilig organisierten Wertschöpfungsstrukturen ein Unternehmen nicht alle Aufgaben selbst ausführt, entstehen Netzwerke von mehreren Unternehmen. Die Unternehmen ergänzen sich dabei idealerweise mit ihren Kernkompetenzen, wobei sich unterschiedliche generische Schwerpunkte für die Gestaltung erkennen lassen (Alt 2008, S. 173):

7.3  Geschäftsmodell und -netzwerk

E-MailNewsletter

Informieren über Uhrenhersteller

Radiowerbung

Informieren über Uhrenhersteller

Vergleichsportale

UhrenOnlineshop

143

Aufruf des UhrenOnlineshops Aufruf des UhrenOnlineshops

Suche nach Uhrenmodellen

Postversand

Konfiguration von Uhrenmodellen

Preisvergleich zwischen Uhrenmodellen und Ausstattungsvarianten

Buchung eines Uhrenmodells

Erhalt der Uhr

Abb. 7.2  Customer Journey im Uhren-Beispiel

• Position in der Wertschöpfungskette. Wertschöpfungsnetzwerke lassen sich aus Unternehmenssicht in kunden- und lieferantenorientierte Abschnitte untergliedern. Die Leistungsrichtung hin zum Endkunden lässt sich als Downstream und jene hin zum (Rohstoff-)Lieferanten als Upstream bezeichnen (s. Abb. 8.1). • Bündelungsgrad von Leistungen. Unternehmen können sowohl Einzelaufgaben in einem Prozess übernehmen als auch Leistungen für einen Prozess bündeln. Orchestratoren zur Bündelung von (Teil-)Leistungen sind insbesondere von Bedeutung, wenn es um die durchgängige Leistungserbringung entlang eines Kundenprozesses geht (Bündelangebot aus einer Hand). Daneben ist Leistungsbündelung auch im betrieblichen Umfeld relevant, da Hersteller etwa durch Systemlieferanten Zuständigkeiten für Bauteile (z. B. die gesamte Armaturentafel bei einem Fahrzeug) oder Dienstleistungsbereiche (z. B. die gesamte Distributionslogistik mit mehreren Transportdienstleistern) auslagern können. • Kompetenzen der Leistungserstellung. Unternehmen vereinen Kompetenzen in den Bereichen Vertrieb, Produkt und Infrastruktur (Hagel und Singer 1999, S.  135  f.). Spezialisierung ist sinnvoll, weil die drei Bereiche unterschiedliche Ziele verfolgen: Während vertriebsorientierte Unternehmen die umfassende Abdeckung von Kundenbedürfnissen (z. B. ein Allfinanzangebot) anstreben, ist dies bei produkt- und dienstleistungsorientierten Unternehmen die schnelle Entwicklung Know-how-intensiver Angebote (z. B. modischer Produkte) und bei standardisierten Dienstleistungen die Bereitstellung einer effizienten Infrastruktur zur Realisierung von Mengeneffekten im Massengeschäft. Durch die Kombination von Positionierung, Bündelungsgrad und Leistungserstellungskompetenzen lassen sich Geschäftsmodelle ableiten. Geschäftsmodelle spezifizieren die Funktionsweise einer marktfähigen wirtschaftlichen Lösung und umfassen neben Angaben zur Vernetzung der Netzwerkpartner im Rahmen der Leistungserstellung mindestens noch

144

7 Strategieebene

eine Beschreibung der differenzierenden (Value Proposition bzw. Kundennutzen) s­ owie der monetären (Revenue Model bzw. Ertragsmodell) Eigenschaften. Diese drei Kernelemente spiegelt die Begriffsdefinition wider: cc Geschäftsmodell  Ein Geschäftsmodell spezifiziert die Geschäftslogik eines Unterneh­ mens. Dieses umfasst u. a. den differenzierenden Geschäftszweck (Value Proposition), die beteiligten Akteure mit den sie verbindenden Leistungsflüssen sowie Angaben zu den finanziellen Konsequenzen (Weiner et al. 2010, S. 239). Ein Geschäftsmodell soll die übergeordnete Funktionsweise und die strategische Positionierung einer Organisation abbilden. Beispiele für mögliche, aus den drei genannten Schwerpunkten abgeleitete Geschäftsmodelle sind (Müller-Stewens und Lechner 2011, S. 370 f.): • Schichtenspezialisten konzentrieren sich auf eine oder mehrere Wertschöpfungsstufen einer Wertkette und besitzen gegenüber anderen Wettbewerbern einen Wettbewerbsvorteil. Dieser Vorteil kann in einem Wissensvorsprung, in Größenvorteilen und/oder in spezifischen Eigentumsrechten liegen. In der Regel besitzen sie zur Erzielung von Skaleneffekten eine effiziente Infrastruktur für die eigene Leistungserstellung. In einigen Fällen bieten Schichtenspezialisten ihre Leistungen anderen Akteuren im gleichen Marktbereich an (z.  B. spezialisierte Transaktionsbanken wie Equensworldline oder Xchanging zur Transaktionsabwicklung für andere Bankhäuser im Finanzbereich). Vielfach sind Schichtenspezialisten auch branchen- bzw. industrieübergreifend aktiv (z. B. Outsourcing-Unternehmen im Bereich Informationstechnologie wie DXC oder IBM). • Pioniere erweitern bestehende Wertketten um zusätzliche und innovative Wertschöpfungsstufen/Leistungen. Diese verschaffen den Pionieren ein Alleinstellungsmerkmal, das sie in der Regel kontinuierlich weiterentwickeln müssen, um ihren Wettbewerbsvorteil zu erhalten. Ein Beispiel sind die jüngsten Fintech-Unternehmen in der Finanzindustrie (s. Abschn.  10.3.3), die häufig als Start-ups innovative IT-Lösungen wie Crowdfunding oder alternative Bezahllösungen (z.  B. auf Basis der Blockchain-­ Technologie) anbieten (Alt und Puschmann 2016). • Orchestratoren koordinieren das Zusammenspiel von Leistungen und Akteuren über einen Teil oder die Gesamtheit der Wertschöpfungskette. Ihre Kernkompetenz liegt deshalb in der umfassenden Kenntnis von Kundenbedürfnissen bzw. Kundenprozessen (Customer Intimacy) und in der daraus abgeleiteten Bündelung von (zumeist externen) Leistungsangeboten sowie in deren Bereitstellung. Typische Beispiele sind im B2C-­ Bereich Mobilitätsportale (z. B. Moovel, Qixxit) oder Finanzportale (z. B. Finanzblick, Mint) und im Business-to-Business-Bereich Outsourcing-Dienstleister wie etwa SpecialChem für Prozesse rund um Oberflächenbehandlung oder die DZ Bank für sämtliche Prozesse in der Bankenwertschöpfungskette (Alt et al. 2009, S. 245 ff.) (zum Outsourcing s. auch Abschn. 4.4).

7.3  Geschäftsmodell und -netzwerk

145

• Integratoren sind für überwiegende Teile der Wertschöpfung entlang der Wertschöpfungskette verantwortlich, wobei der Anteil von fremdbezogenen Leistungen gering bis nicht vorhanden ist (z. B. in der Pharmaindustrie oder bei Expressdiensten). Von zentraler Bedeutung ist hierbei zum einen die Minimierung von Transaktionskosten zwischen den Wertschöpfungsstufen, um damit einen Wettbewerbsvorteil gegenüber den Orchestratoren zu erlangen oder zu behalten. Zum anderen muss ein Integrator jede Wertschöpfungsstufe effizient gestalten, damit er nicht gegenüber Schichtenspezialisten ins Hintertreffen gerät. Zur strukturierten Darstellung von Geschäftsmodellen haben sich zahlreiche Methoden etabliert (z. B. (Deelmann und Loos 2003)). Ein in der Praxis verbreiteter Ansatz ist die Business Model Canvas (Osterwalder und Pigneur 2010), welche die Gestaltungsdimensionen eines Geschäftsmodells in neun Bereiche untergliedert. Darin beschreiben Unternehmen in verbaler Form die von ihnen beabsichtigte Ausgestaltung und hinterfragen diese in regelmäßigen zeitlichen Abständen. Die Bereiche sind: • Die Kundensegmente umfassen Personengruppen oder Organisationen, die ein Unternehmen mit seinen Produkten und Dienstleistungen erreichen möchte. • Ein Nutzenversprechen (Value Proposition) stellt ein Bündel von Produkten und/oder Dienstleistungen dar, die für ein Kundensegment einen Nutzen stiften. Dies umfasst auch Informationen zu den Inhalten, Funktionen und zum Design der Produkte und Dienstleistungen. • Die Kanäle beziehen sich auf die Wege zur Kommunikation (z.  B.  Chatfunktionen, E-Mail) sowie zur Übermittlung der Produkte (z. B. Versand über einen Logistikdienstleister, Vor-Ort-Abholung) und Umsetzung der Dienstleistungen (z.  B.  Beratungsgespräche über Telefon) gegenüber den Kundensegmenten. • Die Kundenbeziehungen umfassen die Beziehungen, die ein Unternehmen mit seinen Kundensegmenten besitzt bzw. aufbauen möchte. Dies reicht von Informationsangeboten (z. B. über eine Webseite oder als E-Mail-Newsletter) über persönliche Beratung (z. B. Hotlines), Self-Service-Angeboten (z. B. Überweisung per Online Banking) und dem Betreuen von Communities (z.  B. zur Verprobung neuer Produktideen) bis hin zum gemeinsamen Entwickeln und Gestalten neuer Produkte und Dienstleistungen (Co-Creation). • Die Schlüsselressourcen beschreiben die wichtigsten materiellen (z.  B.  Maschinen) und immateriellen (z. B. Patente, Mitarbeiterwissen) Güter und Fähigkeiten (Assets) einer Organisation zur Umsetzung des Geschäftsmodells. • Die Kernaktivitäten sind die wichtigsten Aktivitäten und Prozesse zur Umsetzung des Geschäftsmodells. • Die Schlüsselpartnerschaften beschreiben die wichtigsten Zulieferer und sonstigen Partner im Wertschöpfungsnetzwerk.

146

7 Strategieebene

• Die Erlösquellen beschreiben die finanziellen Rückflüsse von Seiten der Kundensegmente für gelieferte Produkte und geleistete Dienstleistungen einschließlich der quantitativen Kalkulation von Verkaufspreisen und Verkaufsmengen. • Die Kostenstruktur umfasst die wesentlichen Kostenpositionen zur Umsetzung des Geschäftsmodells. Zur Analyse und zur Ausgestaltung von Geschäftsmodellen lassen sich weitere Methoden verwenden. Zunächst ist hier die Literatur des strategischen Managements zu nennen (z. B. (Müller-Stewens und Lechner 2011)), die u. a. das Fünf-Kräfte-Modell zur Wettbewerbsanalyse (s. Abschn. 3.2.2.2) und die Wertschöpfungskette zur Identifikation der internen Prozessbereiche als bekannte Vertreter kennt. Das Fünf-Kräfte-Modell identifiziert mit Kunden und Lieferanten sowie den bestehenden und branchenfremden Wettbewerbern wichtige Akteure im Wertschöpfungsnetzwerk und unterstützt bei der Diskussion des Geschäftsmodells im Kontext einer Branche (also gegenüber Kunden, Lieferanten, bestehenden und neuen Wettbewerbern). Das Modell der Wertschöpfungskette liefert Anhaltspunkte für die notwendigen eigenen Leistungen bzw. Kernprozesse (z.  B.  Marketing, Produktion, Vertrieb). Eine weitere Unterstützung leisten Methoden der Geschäftsmodell-Modellierung. Diese ergänzen verbale Methoden wie die Business Model Canvas um grafische Notationen, welche das Zusammenspiel der in einem Geschäftsmodell beteiligten Akteure darstellen. So beschreibt das Geschäftsnetzwerkmodell bzw. die Geschäftsarchitektur als Bestandteil eines Geschäftsmodells die Rollen der Akteure in einem Wertschöpfungsnetzwerk und den Austausch von Leistungen zwischen den Netzwerkpartnern. Eine Möglichkeit zur Modellierung von Geschäftsnetzwerken ist die in Abb. 7.3 verwendete e3Value-­Notation. Darin

Abb. 7.3  Geschäftsnetzwerkmodell im Uhren-Beispiel

7.4  Strategische Prozessführung

147

stellen Rechtecke mit spitzen Ecken einen oder mehrere Akteure (Actors), Rechtecke mit abgerundeten Ecken die zentralen Aufgabenbereiche, die Kanten (bzw. Verbindungslinien) die Wertflüsse bzw. Leistungsübergänge (Value Exchanges), die ovalen Symbole die Leistungsschnittstellen (Value Interfaces) mit den Leistungsrichtungen (Dreiecke) und die roten Punkte Startereignisse (einfacher Kreis) oder Endereignisse (Doppelkreis) dar. In Abb. 7.3 ist zu erkennen welche Leistungsaustauschbeziehungen notwendig sind, um ausgehend von einem Kundenwunsch eine Uhr zu fertigen und schließlich an den Uhren-Kunden auszuliefern. Dies betrifft zum einen durch den Kunden ausgelöste Austauschbeziehungen (z. B. Spezifikation der Anforderungen an die Ausstattung und Gestaltung der Uhr), die sich daran anschließenden und bei den Unternehmen ablaufenden Leistungsaustausche (z. B. Bestellung von Komponenten) sowie im Vorfeld angesiedelte Interaktionsbeziehungen (z.  B. Übermittlung von Sortimentslisten von Zulieferern als Basis für die Zusammenstellung der Uhrenmodelle). Im Rahmen der Kaufabwicklung ist neben den Akteuren (Zulieferer, Uhrenhersteller, Uhren-Onlinehändler) noch eine Auskunftei (z. B. Schufa) als externer Dienstleister zur Beurteilung der Kundenbonität beteiligt. Bei der Konstruktion des Geschäftsnetzwerkmodells sind die in Abschn. 4.4.1 erwähnten Transaktionskosten zu beachten. So entstehen mit jeder Verbindung zu einem Leistungsanbieter oder Leistungsorchestrator Kosten für das Vereinbaren, das Umsetzen und die Kontrolle der Geschäftsbeziehung. Gerade bei bilateralen Verbindungen geht damit die Etablierung eines gewissen Abhängigkeitsverhältnisses zum Leistungsanbieter einher, was Kunden häufig aufgrund der erhöhten Wechselkosten auf alternative Anbieter häufig als nachteilig empfinden. Eine weitere Möglichkeit besteht in der Vernetzung über multilaterale Plattformen, wie etwa elektronische Märkte (s. Abschn. 5.2.1 und 12.2.3). An die Stelle vieler bilateraler Vernetzungen zwischen den Akteuren und den dazugehörigen individuellen Schnittstellen tritt bei elektronischen Märkten jeweils nur eine (standardisierte) Schnittstelle zum Anbieter der Marktinfrastruktur (elektronische Markt- oder Transaktionsplattform). In der Reisebranche haben sich zum einen elektronische Märkte in Form von sog. Computerreservationssystemen (z. B. Amadeus, Galileo, Sabre) mit einem breiten Angebot an Marktleistungen sowie den technischen Protokollen und Infrastrukturen des Dienstleisters SITA etabliert, an den sowohl Reiseanbieter als auch Reisebüros angeschlossen sind. Zum anderen existieren zahlreiche Marktplatzangebote für die rein endkundengetriebene Reisebuchung wie z.  B. check24 oder idealo. Zusammenfassend trägt somit der IT-Einsatz zur Reduktion von Transaktionskosten bei, sodass ­Geschäftsnetzwerke mit mehreren externen Partnern aufgrund der Spezialisierungseffekte zumindest ökonomische Vorteile besitzen (s. auch Abschn. 12.3).

7.4

Strategische Prozessführung

Unternehmen haben sicherzustellen, dass die Gestaltungsaktivitäten auch zu den angestrebten Zielen führen. Zur Entwicklung der fachlichen Vorgaben entlang der strategischen Vorgaben umfasst die strategische Prozessführung (s. Abb. 6.5) zunächst eine genauere Beschreibung von aus der allgemeinen Unternehmensstrategie bzw. dem Geschäftsmodell abgeleiteten Organisationszielen sowie die diesen Zielen zuzuordnenden kritischen Erfolgsfaktoren.

148

7 Strategieebene

­ llerdings sind die kritischen Erfolgsfaktoren (z.  B. hohe Kundenbindung, differenziertes A Uhrenangebotsportfolio) häufig auf hohem Abstraktionsniveau formuliert und daher nicht direkt messbar. Sie erfordern daher eine Operationalisierung in Form eines detaillierten und konsistenten Systems von strategischen Führungsgrößen (strategischen Messgrößen), mit denen sich Geschäftsprozesse hinsichtlich der Zielerreichung gegenüber strategischen Vorgaben messen und steuern lassen (Winter 2011, S. 108 f.): • Organisationsziele definieren die geplanten langfristigen Entwicklungsperspektiven einer Organisation. Beispiele für diese unternehmensstrategischen Ziele sind die Erlangung einer marktdominierenden Wettbewerbsstellung oder die Erhöhung der Produktinnovationen. • Kritische Erfolgsfaktoren (KEFs) konkretisieren die (langfristigen) Organisationsziele und beschreiben gewünschte bzw. notwendige Eigenschaften und Fähigkeiten einer Organisation (z. B. schnelle Auslieferung bestellter Artikel oder ausgeprägtes gestalterisches Know-how der Mitarbeiter). • Führungsgrößen oder Key Performance Indicators (KPI) (s. auch Abschn. 3.2.3.2) sind Messgrößen, die den Umsetzungsgrad einzelner Erfolgsfaktoren quantitativ bewerten (Österle 1995, S.  113). Hierbei ist zwischen den übergeordneten strategischen Führungsgrößen (z. B. durchschnittliche Auftragsdurchlaufzeit von Bestellung bis Auslieferung) und den daraus abgeleiteten Prozessführungsgrößen (z.  B. durchschnittliche Wartezeit zwischen Produktionsende und Versand) zur unmittelbaren Beurteilung der Prozessleistung (s. Abschn. 8.5) zu unterscheiden. Sollwerte bzw. Prozessziele sorgen für eine weitere Konkretisierung, indem sie die Führungsgrößen um eine Zielvorgabe für einen bestimmten Zeitraum ergänzen (z. B. soll die durchschnittliche Wartezeit eines Artikels zwischen Produktionsende und Versand weniger als ein Tag betragen). Führungsgrößen lassen sich in finanzielle und direkte Führungsgrößen unterscheiden. Finanzielle Führungsgrößen, wie etwa Prozesskosten oder der Umsatz, gelten als abgeleitete Kennzahlen und sind häufig nicht von den Prozessbeteiligten direkt beeinflussbar und nur zeitverzögert messbar. Eine unmittelbare Messung der Prozessleistung übernehmen direkte Führungsgrößen (z. B. Auftragsabwicklungszeit, Antwortzeit auf Kundenanfragen, Nutzungsanteil von Online-Kanälen), die in der Regel eine ­umfassendere und gleichzeitig feingranularere Bewertung unter Einbeziehung verschiedener Bewertungsdimensionen erlauben (Österle 1995, S. 113). Abb. 7.4 zeigt die Beziehungen zwischen Organisationszielen, kritischen Erfolgsfaktoren und Führungsgrößen in Form einer Balanced Scorecard, wie sie bereits Abschn. 3.2.4 für den IT-Bereich skizziert hat. Balanced Scorecards sind aufgrund ihrer Berücksichtigung von nichtfinanziellen sowie zukunfts- und potenzialorientierten Zielen eine Weiterentwicklung traditioneller Controllinginstrumente. Hierbei sind die mit monetären Zielen (z. B. bezüglich Kosten und Umsätzen) sowie Prozesszielen (z. B. bezüglich Stückzahlen und Durchlaufzeiten) verbundenen Führungsgrößen nach einem gewissen initialen Abstimmungs- und Abgrenzungsaufwand in der Regel gut messbar. Bei den kunden- und

7.4  Strategische Prozessführung

149

Unternehmensstrategie Finanzen Höhe des gebundenen Kapitals für gelagerte Uhrenbauteile

Senkung der Lagermengen bei Uhrenbauteilen Geringe Höhe an gebundenem Kapital

Durschnittliche Verweildauer von Uhrenbauteilen im Lager

Just in Time Lieferung von Uhrenbauteilen

Kunden Kundenzufriedenheitsindex im Bereich Bestellung laut Umfrage

Kundenfreundlicher Bestellprozess Erhöhung der Kundenzufriedenheit Verfügbarkeitsrate Uhren-Onlineshop

Bestellabbruchrate

Kundenzufriedenheitsindex im Bereich Produktangebot laut Umfrage

Attraktives Uhrenund Gestaltungsportfolio Erhöhung der Kundenzahl

Anzahl Kundenbeschwerden im Bereich Bestellung

Anzahl Uhrenmodelle

Anteil bestellter Uhren mit Verzierungen

Prozess Durchschnittlicher Zeitraum von Uhrenbestellung bis -versand

Schnelle Auslieferung der bestellten Uhren Effiziente Prozessgestaltung Zeitnahe Verzierung hergestellter Uhren

Hohe Produktqualität

Durchschnittlicher Zeitraum von Uhrenherstellung bis Beginn der Verzierung

Anteil von als fehlerhaft identifizierter Geringer Anteil von Ausschuss im Uhren im Rahmen der Qualitätskontrolle Rahmen der Uhrenproduktion

Geringer Anteil reklamierter Uhren

Anzahl der reklamierten Uhren

Potenzial Anzahl neuer Verzierungsvarianten p.a. Erhöhung der Produktinnovationen

Legende

Hohes gestalterisches Know-how der Mitarbeiter Anzahl neuer Modellvarianten p.a.

Organisationsziel

Kritischer Erfolgsfaktor

Führungsgröße

Abb. 7.4  Balanced Scorecard im Uhren-Beispiel

potenzialorientierten Zielstellungen ist eine eindeutige Messbarkeit häufig schwieriger umsetzbar, da sich diese Faktoren vielfach nur schwer messen lassen (z. B. Beurteilung der Kundenzufriedenheit oder des Innovationsgrades) (Winter 2011, S.  109). Die ­Bezeichnung „Balanced“ bezieht sich darauf, dass die einzelnen Zieldimensionen ausbalanciert sein sollen und für jede Zieldimension Führungsgrößen definiert sind, also keine Zielkategorie unberücksichtigt bleibt.

8

Organisationsebene

Zusammenfassung

Kapitel 8 fokussiert mit der Organisationsebene die Prozessgestaltung und die operative Prozessführung als Bindeglied zwischen der strategischen Unternehmensgestaltung und der technischen Implementierung (IS-Ebene). Es liefert einen Überblick zu Modellen und Notationen, die auf Basis der Leistungserbringung des Unternehmens die Ableitung ablauforganisatorischer Prozessstrukturen auf mehreren Detaillierungsebenen unterstützen. Als weitere Bereiche sind die Ausgestaltung der aufbauorganisatorischen Strukturen, die operative Prozessführung mit Hilfe qualitativer und quantitativer Führungsgrößen sowie Ansätze zur systematischen Prozessverbesserung enthalten.

8.1

Gestaltungsinhalte auf Organisationsebene

Die Organisationsebene konkretisiert die Umsetzung der Strategieebene. Dies bezieht sich einerseits auf die in der Ablauforganisation zusammengefassten und miteinander in Beziehung stehenden Prozesse, die zunächst grob und nachfolgend in ausdifferenzierteren Strukturen zu betrachten sind. Sie zeigt für jeden Geschäftsprozess die Inputfaktoren aus vorgelagerten Prozessen, die Prozessabfolge mit ihren spezifischen Aktivitäten sowie die zu erzeugenden Prozessergebnisse/-leistungen. Andererseits ist auch die sich anschließende Gestaltung der Aufbauorganisation (einschließlich der Definition von Verantwortlichkeiten, Stellen und Organisationseinheiten) als zweiter wesentlicher Baustein auf der Organisationsebene angesiedelt. Neben der Spezifikation von Sequenz- und Leistungsflüssen zwischen Aktivitäten und Prozessen adressiert die organisatorische Gestaltung

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_8

151

152

8 Organisationsebene

somit auch die konkrete Umsetzung der auf strategischer Ebene grob vorgegebenen Austauschbeziehungen zwischen einzelnen inner- und überbetrieblichen Einheiten der Aufbauorganisation. Sie bezieht dabei die Potenziale der Digitalisierung mit ein, ohne sich jedoch an bestehenden, den Gestaltungsspielraum beschränkenden IT-Strukturen zu orientieren. Ausgangspunkt der Prozessmodellierung ist die Beschreibung des Zusammenspiels der Geschäftsprozesse in einer Prozesslandkarte sowie in Prozesskontextdiagrammen (s. Abschn. 8.2). Darauf aufbauend konkretisiert die Leistungsanalyse (s. Abschn. 8.2) die Prozessleistungen hinsichtlich ihrer Bestandteile sowie der (Prozess-)Kunden und eingesetzten Distributions- bzw. Zugangskanäle. Die eigentliche Ablaufplanung (s. Abschn. 8.3) mit Hilfe der Prozessmodellierung ergänzt Abschn. 8.4 um die Ableitung aufbauorganisatorischer Strukturen. Die operative Prozessführung (s. Abschn. 8.5) schließlich leitet aus strategischen Führungsgrößen konkrete Prozessführungsgrößen ab. Auf Basis der Prozessführung und -messung ist eine kontinuierliche Prozessverbesserung (s. Abschn. 8.5) im Sinne des CI (s. Abschn. 6.1) anzustreben.

8.2

Prozess- und Leistungsüberblick

Aufgrund der Ergebnisorientierung dominiert die Gestaltung der Ablauforganisation die Gestaltung der Aufbauorganisation. Als erste Prozesskategorie hatte Abschn. 7.2 den Kundenprozess erwähnt, der bei einer kundenorientierten Betrachtung den Ausgangspunkt zur Ableitung von Unternehmensleistungen bildet. Während der Kundenprozess die Abläufe aus Sicht des Kunden (Outside-In) betrachtet, geht die Prozessanalyse des Unternehmens von den eigenen Abläufen (Inside-Out) aus. Neben Kundenprozessen sind hier drei weitere Prozesstypen zu nennen (Alt 2008, S. 139 ff.; Winter 2011, S. 114): • Leistungsprozesse oder Kernprozesse liefern einen direkten Beitrag zur Wertschöpfung eines Unternehmens. Ein typisches Beispiel in Banken ist etwa der Zahlungsverkehr oder das Portfoliomanagement und in Industrieunternehmen der Einkauf oder die Fertigung. • Unterstützungsprozesse ergänzen die Leistungsprozesse durch Vorleistungen, die nicht direkt wertschöpfend auf die organisationseigene Erzeugung/Bereitstellung von Produkten oder Dienstleistungen einwirken, aber dennoch einen Beitrag zur Aufrechterhaltung der Geschäftstätigkeit leisten. Beispiele für Unterstützungsprozesse sind der Personalbereich oder das Rechnungswesen. • Führungsprozesse überwachen und bewerten die Umsetzung von Leistungs- und Unterstützungsprozessen mit Hilfe quantitativer Führungsgrößen und greifen bei Bedarf steuernd ein. Weiterhin dienen Führungsprozesse der Anpassung und Weiterentwicklung der strategischen und operativen Prozessführung.

8.2 Prozess- und Leistungsüberblick

153

Unternehmen

Führungsprozesse

Strategieentwicklung

Lieferant

Leistungsprozesse

Controlling

Kunde

Leistungsprozesse Markt- und Kundenanalyse

Marketing

Produktentwicklung

Vertrieb

Beschaffung

Retoure

Produktion

Kundenservice

Kundenprozesse

Unterstützungsprozesse

Upstream

Finanzen und Rechnungswesen

Personalmanagement (HR)

Downstream

Abb. 8.1  Generische Prozesslandkarte

Die Prozesslandkarte liefert einen Überblick zu den übergeordneten Prozessen bzw. Prozessbereichen eines Unternehmens. Sie ordnet den aus dem Geschäftsnetzwerk benannten Akteuren die wichtigsten Prozesse zu und kann diese auch mittels Leistungsflüssen verbinden. Das (bezüglich Anwendungsfall und Modellierungstechnik) generische Beispiel in Abb. 8.1 zeigt die übergeordneten Prozesse eines Unternehmens und die Einbettung der unternehmerischen Führungs-, Leistungs- und Unterstützungsprozesse in die unternehmensübergreifenden Wertschöpfungsketten/Prozessstrukturen. Hierbei bestehen insbesondere Beziehungen zwischen den unternehmerischen Leistungsprozessen in Richtung der wertschöpfungsseitig vorgelagerten Leistungsprozesse der Lieferanten (Upstream) und den nachgelagerten Kundenprozessen (Downstream). Aufgrund ihres funktionsübergreifenden Charakters lassen sich die Prozesse/Prozessbereiche einer Prozesslandkarte häufig nicht eindeutig einem Organisationsbereich zuordnen, so dass eine Prozessverantwortung in der Regel nicht auf Basis funktionaler (Linien-)Verantwortlichkeiten, sondern durch eine separate organisatorische Einheit (Process Owner) umzusetzen ist (Winter 2011, S. 87).

154

8 Organisationsebene

Für das Uhren-Beispiel illustriert Abb. 8.2 eine mögliche Prozesslandkarte. Zur Vereinfachung enthält dieses Modell nur eine integrierte Betrachtung ausgewählter Führungs-, Leistungs- und Unterstützungsprozesse des Uhrenherstellers und des Uhren-­Onlinehändlers ohne Berücksichtigung der Kunden- und Lieferantenprozesse. Für die Definition und Abgrenzung von Prozessen existieren keine allgemeingültigen Regeln; jedoch können sich Anhaltspunkte aus künftigen oder bestehenden Strukturen ergeben (Österle 1995, S. 86 ff.). Dazu zählen beispielsweise die Leistungen des Kundenprozesses, die mit einem Geschäftsobjekt verbundenen Aktivitäten (z. B. Auftragserfassung, Auftragsprüfung und Auftragsanpassung) oder die funktionalen Bezeichnungen von Organisationseinheiten (z. B. Buchhaltung als Bezeichner für einen Unterstützungsprozess, Montage für den Leistungsprozess einer Fertigung oder Controlling für operative Führungsprozesse). Um die Übersichtlichkeit eines Ablaufs zu behalten gilt als Orientierungsgröße, dass einzelne Aktivitäten ca. 10 % des Gesamtaufwands eines Prozesses ausmachen sollten, und bei darüber hinausgehender Komplexität die Zerlegung in mehrere aufeinanderfolgende Prozesse und/oder eine Hierarchisierung der Prozesse anzuwenden sind. Für eine genauere Analyse der in der Prozesslandkarte enthaltenen Prozessbereiche dient eine detaillierte Betrachtung der Wechselwirkungen bzw. Leistungsverflechtungen von Prozessen mit ihren vor- und nachgelagerten sowie parallel ablaufenden Umfeld-­ Prozessen. Die dazu verwendeten Prozesskontextdiagramme (s. Abb. 8.3) dienen als Grundlage für die spätere Verfeinerung der Prozessbeschreibungen und detaillieren die auf Strategieebene im Geschäftsnetzwerkmodell grob beschriebenen Leistungen (Österle 1995, S. 79). In Abb. 8.3 sind für das Uhren-Beispiel die Leistungsverflechtungen des Leistungsprozesses „Herstellung von Uhren und Kaufabwicklung“ sowohl mit dem Kundenprozess „Uhr kaufen“ als auch mit drei weiteren Leistungsprozessen als Prozesskontextdiagramm dargestellt. Dabei sind die im Geschäftsnetzwerkmodell des Uhren-­Beispiels (s. Abb. 7.3) ­zunächst grobgranular abgebildeten Leistungsflüsse (z. B. „Bepreistes Angebotssortiment Führungsprozesse

Leistungsprozesse

Unterstützungsprozesse

Entwicklung Unternehmenspolitik/-strategie

Durchführung Unternehmenscontrolling

Strategische Unternehmenssteuerung

Weiterentwicklung Techniken Uhrenher-stellung u. -gestaltung

Zusammenstellung Uhrenmodelle

Herstellung von Uhren und Kaufabwicklung

Kunden-/ Marktanalyse

Kundenwerbung

Kundenmanagement

Personalmanagement

Bereitstellung ITInfrastruktur

Finanz- und Rechnungswesen

Abb. 8.2  Prozesslandkarte im Uhren-Beispiel

Zulieferermanagement

155

8.2 Prozess- und Leistungsüberblick

Uhrenhersteller / Uhren-Onlinehändler

Uhren-Kunde

Kundenprozess „Uhr kaufen“

Leistungsprozess „Herstellung von Uhren und Kaufabwicklung“

Leistungsprozess „Kundenwerbung“

Leistungsprozess „Zusammenstellung Uhrenmodelle“

Leistungsprozess „Kundenmanagement“

Abb. 8.3  Prozesskontextdiagramm im Uhren-Beispiel

und Gestaltungsalternativen“) in einem prozessorientierten Kontext als Austauschbeziehungen zwischen dem Kundenprozess und den unternehmerischen Leistungsprozessen dargestellt. Dadurch lassen sich die im Geschäftsnetzwerkmodell zunächst grobgranular enthaltenen Leistungen in Unterleistungen zerlegen (z.  B. die „Auftragskorrektur“ als zusätzliche Teilleistung der Leistungsbeziehung „Anforderungen an Ausstattung und Gestaltung der Uhr“ in Abb. 7.3). Zumeist ist es sinnvoll, die durch einen Prozess erzeugten Leistungen bezogen auf Leistungsbestandteile (einzelne Elemente einer Leistung) und Leistungsmerkmale (Eigenschaften der Leistungsbestandteile) genauer zu spezifizieren. Ein sog. Leistungsverzeichnis fasst zusätzliche Informationen zu den Leistungen (wie etwa adressierte Kundensegmente, geeignete Distributions- bzw. Zugangskanäle, grundlegende Qualitätsmerkmale, technische Produktspezifikationen bzw. finanzielle Kennzahlen) zusammen (s. Abb. 8.4 rechts, (Österle 1995, S. 80)). Bei der Spezifizierung der Leistungscharakteristika ist auch zu beurteilen, welche Bedeutung die Leistungsbestandteile/-merkmale für den jeweiligen Prozesskunden haben und wie ihre Qualität insbesondere im Vergleich zu wichtigen Konkurrenten einzuschätzen ist. Abb. 8.4 zeigt links ein solches Qualitätsprofil (Österle 1995, S. 81 ff.) für ausgewählte Leistungen des Prozesses „Herstellung von Uhren und Kaufabwicklung“ im Uhren-Beispiel.

156

8 Organisationsebene

Leistungsbestandteile

Bedeutung

vorhanden

Leistungen

Leistungsbeschreibung

Elektronischer Produktkatalog

Vorhandensein eines elektronischen Kataloges mit Beschreibungen und -klassifikationen der angebotenen Uhren

Bewertungsprofile

Bewertungen von Kunden, die bereits Uhren gekauft haben

Bewertungsprofile

Vorschläge aus Social Media

Vorschläge aus Social Media

Uhrenhersteller generiert Verbesserungen für die Kundenberatung aus Social Media-Beiträgen

…

fehlt

Verbindung zu Loyalitätsprogrammen Elektronischer Produktkatalog

Leistungsmerkmale

Bedeutung

vorhanden

Personalisierbarkeit der Uhren

fehlt

Legende:

Eigenes Unternehmen Wichtigster Konkurrent

Aktualität der Beschreibungen

Hohe Bedeutung

Hohe Bildqualität bei den Angeboten

Mittlere Bedeutung

Qualitätsgesicherte Bewertungen

Geringe Bedeutung

Abb. 8.4  Qualitätsprofil (links) und Leistungsverzeichnis (rechts) im Uhren-Beispiel

8.3

Ablaufplanung

8.3.1 Makro-Ablaufplanung Die Ablaufplanung zerlegt die Erstellung der Prozessleistungen sukzessive in feinere Teilschritte. Nach dem Detaillierungsgrad ist zwischen einer Ablaufplanung im Groben (Makro-­Planung) und einer Ablaufplanung im Detail (Mikro-Planung) zu unterscheiden (Österle 1995, S. 90 ff.). Während die Leistungsplanung eine Konkretisierung der stattfindenden Warenflüsse oder Kommunikationsbeziehungen aus Sicht eines Prozesses darstellt, detailliert die Ablaufplanung die Betrachtung der Prozessaktivitäten über die Zeit. Die Makro-Planung löst dabei die Prozesslandkarte in einzelne Geschäftsprozesse mit ihren Schnittstellen zu anderen Prozessen auf. Hierfür kommen Prozessmodelle zum Einsatz (s. Abb. 8.5), die Prozesse bzw. Prozessbereiche der Prozesslandkarte in Subprozesse bzw. Aufgabenbereiche zerlegen und diese (soweit möglich) in ihrer sachlogischen Reihenfolge darstellen. Abb. 8.5 zeigt für das Uhren-Beispiel, dass der auf der ersten Modellierungsebene angesiedelte übergeordnete Leistungsprozess „Herstellung von Uhren und ­Kaufabwicklung“ auf der zweiten Modellierungsebene aus acht Subprozessen besteht, die nacheinander auszuführen sind. Jeder dieser Subprozesse ist auf weiteren Modellierungsebenen (teilweise auch Modellierungslevel genannt) in detailliertere Subprozesse zerlegbar. Abgeschlossen ist die Makro-Planung, wenn ein Überblick über den gesamten Prozess besteht und eine für das Entwurfsteam und die Prozessbeteiligten ausreichende Verfeinerung gegeben ist.

8.3 Ablaufplanung

157

Uhrenwusch des Kunden vorhanden

Uhrenmodelle und deren Ausstattungsund Gestaltungsvarianten anzeigen

Uhr beim Kunden eingetroffen

Uhrenmodelle suchen und konfigurieren

Preis ausstattungsspezifisch kalkulieren

Preisvergleich zwischen Uhrenmodellen und Ausstattungsvarianten anzeigen

Uhrenmodell kaufen

Kaufbestätigung versenden

Uhr herstellen und gestalten

Uhr versenden

Abb. 8.5  Makro-Prozessdarstellung im Uhren-Beispiel

8.3.2 Mikro-Ablaufplanung und Workflows Die Ergebnisse der Grob-Ablaufplanung dienen als Grundlage für die sich anschließende Ablaufplanung im Detail (Mikro-Planung), welche die in der Grobablaufplanung benannten Prozesse auf weiteren Modellierungsebenen spezifiziert. Im Zuge der detaillierten Ablaufmodellierung berücksichtigt die Mikro-Planung auch bestehende Zusammenhänge bzw. Abhängigkeiten zwischen Teilprozessen und Aktivitäten (z. B. festgelegte Reihenfolgen sowie parallele oder nebenläufige Abfolgen). Neben der zeitlich-logischen Ablauforganisation klärt die Ablaufplanung auch die aufbauorganisatorischen Gestaltungsaspekte. Jede Aktivität ist einer Organisationseinheit zugeordnet, um damit eine Grundlage für die spätere Ableitung der Aufbauorganisation zu schaffen. Sind Prozessmodelle bis zu den elementaren Aktivitäten auf der Ausführungsebene spezifiziert, so spricht man bei diesem Detaillierungsgrad nicht mehr von Prozessmodellen, sondern von sog. Workflowmodellen. cc Workflow  Ein Workflow ist ein formal beschriebener, ganz oder teilweise automatisierter Prozess, der die zur automatischen Steuerung des Arbeitsablaufs auf operativer ­Ebene notwendigen zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen beinhaltet. Der Übergang zwischen diesen beiden Modellformen ist häufig nicht exakt zu bestimmen. Workflowmodelle (Gadatsch 2017, S. 11 ff.) fokussieren gegenüber Prozessmodellen weniger auf die fachlich orientierte Gestaltung von Aktivitätsabfolgen, sondern stärker auf deren schrittweise und (teil-)automatisierte Umsetzung. Daraus ergeben sich die in Abb. 8.6 dargestellten Unterschiede.

8.3.3 Prozessmodellierungssprachen am Beispiel eEPK und BPMN Prozessmodellierungswerkzeuge können sowohl die Makro- als auch die Mikro-­ Ablaufplanung unterstützen. Bekannte Werkzeuge wie etwa der ARIS Designer oder Signavio stellen die Notationen bestimmter Modellierungssprachen (z. B. der nachfolgend beschriebenen Notationen BPMN und EPK) zur Verfügung, erlauben ein einfaches

158

8 Organisationsebene Geschäftsprozess

Workflow

Ziel

Analyse und Gestaltung von Arbeitsabläufen im Sinne gegebener (strategischer) Ziele

Spezifikation der technischen Ausführung von Arbeitsabläufen

Hauptnutzergruppe

Management und Fachabteilung

IT-Abteilung

Gestaltungsebene

Konzeptionelle Ebene mit Verbindung zur Geschäftsstrategie

Operative Ebene mit Verbindung zu unterstützender Technologie

Detaillierungsgrad

Je nach Anforderung grob- oder feingranulare fachlich orientierte Prozessbeschreibung

Detaillierung von Arbeitsschritten hinsichtlich Arbeitsverfahren sowie personeller und technologischer Ressourcen

Abb. 8.6  Unterschiede zwischen Workflows und Prozessen (in Anlehnung an (Gadatsch 2017, S. 13))

Verbinden und Bezeichnen von Aktivitäten und Prozessflüssen sowie die Hierarchisierung von Prozessen über mehrere Ebenen. Um eine hohe Wiederverwendbarkeit von Prozessteilen bzw. Aktivitäten zu erreichen, verwalten Verzeichnisse bzw. Repositories einmal modellierte Elemente (z. B. „Uhren-Kunde“ als eine Ausprägung des Objekttyps „Organisationseinheit“), wodurch neue Elemente nur dann anzulegen sind, wenn nicht bereits ein anderes inhaltlich übereinstimmendes Element existiert. Für die Prozessmodellierung sind eine Vielzahl von semi-formalen Notationen/Modellierungssprachen entstanden (Gadatsch 2017, S. 81 ff.), wobei nachfolgend aufgrund ihrer Verbreitung in der Praxis BPMN und EPK näher beschrieben sind. Wie in Tab. 8.1 dargestellt, umfassen beide Prozessmodellierungssprachen bzw. -notationen vergleichbare Darstellungselemente und erfüllen daher ähnliche Zwecke. Die Business Process Model and Notation (BPMN) ist jüngeren Datums und nicht zuletzt aufgrund der Normierung durch die ISO internationaler ausgerichtet (s. Glossar). BPMN umfasst mit dem Konversationsdiagramm, dem Choreografiediagramm und dem Kollaborationsdiagramm drei Modelltypen, wobei die ersten beiden den Nachrichtenaustausch zwischen verschiedenen Akteuren wiedergeben (Freund und Rücker 2016). Das in der Praxis am häufigsten angewendete Kollaborationsdiagramm stellt dabei Aktivitätsfolgen bzw. Prozessflüsse mit Beteiligung von einem oder mehreren Akteuren dar. Vorteile von BPMN sind die Ausdrucksmächtigkeit durch die große Anzahl an Modellierungsobjekten sowie die Möglichkeit zur Überführung von Kollaborationsdiagrammen in technisch-orientierte Workflowspezifikationen (z.  B. mittels der Business Process Execution Language (BPEL) (s. Glossar)). Abb. 8.7 beschreibt für das Uhren-Beispiel den Prozess „Uhrenauswahl und Bestellung“ in grober Form als BPMN-Kollaborationsdiagramm. Abgerundete Rechtecke bezeichnen dabei Prozessschritte und Kreise die Start- sowie Endereignisse (s. Tab. 8.1). Die Prozessschritte sind den ausführenden organisatorischen Einheiten in den (Swim-) Lanes „Uhren-Kunde“ und „Uhren-Onlineshop“ zugeordnet. (Swim-)Lanes kennzeichnen hierbei Verantwortungsbereiche von Akteuren (z. B. einer Abteilung) für die Ausführung einzelner Aktivitäten (Gadatsch 2017). Einfache Vorgänger-Nachfolger-Beziehungen

8.3 Ablaufplanung

159

Tab. 8.1  Elemente der eEPK- und der BPMN-Notation Element Ereignis

Symbol

Funktion/Aktivität

Fluss

Verzweigung x

Informationsobjekt/ Datenobjekt

Name Name

Name

Organisationseinheit

Beschreibung Ein Ereignis beschreibt einen eingetretenen Zustand (z. B. „Bestellung eingetroffen“) (EPK oben; Start-, Zwischen- und Endereignis bei BPMN unten). Eine Funktion beschreibt manuell oder IT-gestützt auszuführende Aktivitäten, die einem Ereignis folgen (z. B. „Bestellung bearbeiten“) (identische Darstellung bei EPK und BPMN). Bei der EPK beschreiben durchgezogene gerichtete Kanten den Prozessverlauf als Abfolge von Ereignissen und Funktionen (Kontrollfluss). Durchgezogene gerichtete Kanten zwischen Aktivitäten und Informationsobjekten zeigen, ob die jeweiligen Informationsobjekte für die Durchführung der Aktivität benötigt werden (Input), oder aber ein Ergebnis dieser Aktivität (Output) darstellen (Informationsfluss). Bei BPMN spezifiziert eine durchgezogene gerichtete Kante die Reihenfolge von Aktivitäten. Gestrichelte Kanten stellen zum einen den Nachrichtenübergang zwischen zwei Prozessteilnehmern dar (Mitte), und zeigen zum anderen als Daten-Assoziationen an, ob Datenobjekte ein In- oder Output für einzelne Aktivitäten darstellen (unten). Konnektoren detaillieren die Steuerungslogik bei verzweigenden Kontrollflüssen. EPKs verwenden logische Konnektoren (oben: UND, ODER, Exklusives ODER) und BPMN Entscheidungspunkte, sog. Gateways (unten: Paralleles Gateway (UND), Inklusives Gateway (ODER), Exklusives Gateway (Exklusives ODER), Ereignisbasiertes Gateway). Verantwortlichkeiten und aufbauorganisatorische Zuordnungen stellen eEPKs mittels Organisationseinheiten dar, die durch ungerichtete Kanten mit Funktionen verbunden sind (oben). Bei BPMN zeigen die Zeilen als sog. Pools und (Swim-)Lanes die Prozessteilnehmer und die Verantwortlichkeiten (unten). Informationsobjekte kennzeichnen prozessrelevante Daten oder Informationen (Informationsobjekte in eEPK oben; Datenobjekt bei BPMN unten).

verknüpfen die Prozessschritte und sind durch gerichtete Kanten visualisiert. Den Prozessablauf prägen nicht nur lineare Abläufe, sondern auch Verzweigungen (nach „Uhrenkonfiguration speichern“). Bei Verzweigungen sind die jeweiligen Bedingungen festzulegen. So kann entweder eine Verzweigung in verschiedene Richtungen gleichzeitig erfolgen, oder nur in Richtung bestimmter Prozesspfade beim Vorliegen formulierter Bedingungen. Ebenso ist zu definieren, unter welchen Bedingungen bei Zusammenführungen der Folgeschritt beginnen kann. Grundsätzliche Bedingungen sind mit Hilfe boolescher Operatoren darstellbar: So kann

160

8 Organisationsebene

BasisUhrenmodell suchen

BasisUhrenmodell konfigurieren

Uhrenkonfiguration speichern

Uhren-Kunde Weiteres Uhrenmodell konfigurieren? nein

ja

Uhren-Kunde

Uhrenwunsch des Kunden vorhanden

UhrenOnlineshop öffnen

Gespeicherte Uhrenkonfiguration auswählen

Kunden-, Zahlungsund Versanddaten eingeben

Kaufwunsch bestätigen

Uhren-Onlineshop Uhren-Onlineshop

Prozess "Uhrenauswahl und Bestellung"

der Folgeschritt in einem Fall erfolgen, wenn alle vorangehenden Schritte abgearbeitet sind (logisches UND), oder in einem anderen Fall wenn mindestens einer der vorangehenden Schritte abgearbeitet ist (logisches ODER) (Winter 2011, S. 118 f.). Wie erwähnt, umfasst die Ablaufmodellierung in der Regel mehrere Verfeinerungsebenen/Prozessmodellierungsebenen. Die in Abb.  8.7 benutzte BPMN-Notation symbolisiert mit einem Kreuz innerhalb des Prozessschrittes „Konfiguration des Basis-Uhrenmodells“, dass sich dieser Prozessschritt aus weiteren Teilschritten/Aktivitäten zusammensetzt. Diese sind wiederum als (Mikro-)Ablaufmodell in einem separaten BPMN-Modell (s. Abb. 8.8) verfeinert. Da der übergeordnete Prozessschritt „Konfiguration des Basis-Uhrenmodells“ in Abb. 8.7 organisatorisch dem Uhren-Kunden zugeordnet ist, gilt dies auch für alle seine Teilschritte bzw. Aktivitäten in Abb. 8.8. Das verfeinerte Ablaufmodell in Abb. 8.8 beginnt daher nach dem erfolgreichen Abschluss des vorgelagerten Prozessschrittes „Suche nach einem Basis-Uhrenmodell“ (s. Abb. 8.7) und das Startereignis ist in Abb. 8.8 mit „Basis-­Uhrenmodell ist ausgewählt“ angegeben. Das nachfolgende XOR-Gateway dient der Zusammenführung der Sequenzflüsse und adressiert den Fall, dass ein Kunde nach seiner anschließenden, parallel ablaufenden Auswahl der Komponentenvarianten

Uhrenmodelle und deren Ausstattungsund Gestaltungsvarianten anzeigen

Preise auf Basis der konfigurierten Ausstattungsund Gestaltungsvarianten kalkulieren

Vergleich gespeicherter Uhrenkonfigurationen anzeigen

Bepreistes Uhrenangebot anzeigen

Uhrenmodell ist bestellt

Abb. 8.7  Grobes BPMN-Ablaufmodell im Uhren-Beispiel Uhren-Kunde

Komponentenzusammenstellung entspricht Kundenwunsch?

Uhrenmodellspezifische Komponentenauswahlliste

ja

Gestaltungsalternative auswählen

Gestaltungsalternative personalisieren

nein

Uhren-Kunde

Basis-Uhrenmodell ist ausgewählt

Gehäusevariante auswählen

Uhrwerk variante auswählen

Armbandvariante auswählen

Uhrenmodellspezifische Gestaltungsalternativen

Komponentenauswahl

Abb. 8.8  Verfeinertes BPMN-Ablaufmodell im Uhren-Beispiel

Auswahl Gestaltungsalternative

Uhrenmodell ist konfiguriert

Personalisierte Gestaltungsalternative

8.3 Ablaufplanung

161

noch nicht zufrieden ist und die Komponenten noch einmal anders zusammenstellen möchte. Weiterhin sind in diesem Detail-Ablaufmodell die für die einzelnen Aktivitäten benötigten Datenobjekte (Input-Beziehungen) sowie erzeugten Datenobjekte (Out­ put-Beziehungen) dargestellt. Diese datenorientierten Inhalte/Prozessbedarfe bilden eine erste Vorgabe für die sich auf der IS-Ebene anschließenden technischen Detailspezifikationen (s. Abschn. 9.4 und 9.5). Im Zusammenhang mit BPMN sind in der Forschung weitere darauf aufbauende Modellierungsansätze entstanden. So lassen sich etwa mit dem Ansatz Data Quality in Business Processes (dqBP) BPMN-Modelle mit Datenschutzanforderungen anreichern (Rodriguez et al. 2012). Als weiterer Ansatz konzentriert sich BPMN extensions for interaction modeling (iBPMN) auf die Abfolge von Interaktionsbeziehungen zwischen verschiedenen Pools eines BPMN-Modells (Decker und Barros 2008). Neben BPMN ist insbesondere bei Unternehmen im deutschsprachigen Raum der Ansatz der Architektur integrierter Informationssysteme (ARIS) (Scheer 1992) verbreitet. Wie in Abschn. 6.1 und Abb. 6.4 erwähnt, umfasst ARIS fünf Sichten: Die Funktionssicht stellt die hierarchischen Beziehungen zwischen den betrieblichen Funktionen und Unterfunktionen dar. Die Organisationssicht enthält die aufbauorganisatorische Struktur, die Leistungssicht die materiellen sowie immateriellen Input- und Output-­Leistungen und die Datensicht die betriebswirtschaftlich relevanten Informationsobjekte (z. B. Angebot, Auftrag, Rechnung). Die Steuerungs- bzw. Prozesssicht enthält den eigentlichen Ablauf in Form Ereignisgesteuerter Prozessketten (EPK), (s. Tab. 8.1). Im Kern bestehen diese aus einer Folge von: • Elementaren Ereignissen, sowie • elementaren (fachlichen oder technischen) Funktionen. Ein oder mehrere Ereignisse lösen danach eine Funktion aus, die wiederum ihrerseits ein oder mehrere Ereignisse initiiert. In diese Abfolge von Funktionen und Ereignissen fließen die Spezifikationen der Daten-, Leistungs- und Organisationsicht ein, indem eine Zuordnung der Informations-, Material- bzw. Ressourcenobjekte sowie der beteiligten Organisationseinheiten zu den Funktionen erfolgt. Eine derart mit Informationen aus den anderen Sichten angereicherte EPK heißt dann erweiterte EPK (eEPK). Falls mehrere Ereignisse eine Funktion auslösen oder eine Funktion mehrere Ereignisse auslöst, spezifiziert ein Konnektor die Auslösungslogik. Die einsetzbaren Konnektoren sind auch hier das logische UND (Konjunktion) und das logische ODER (Adjunktion) sowie das ausschließende ODER (Disjunktion). Die zulässigen Varianten der Ereignis-Funktions-­Verknüpfung mittels Konnektoren fasst Abb. 8.9 zusammen. eEPK-Modelle besitzen gegenüber BPMN-Kollaborationsdiagrammen einen geringeren Sprachumfang und sind rein auf die fachliche Betrachtung von Prozessen ausgelegt. Zudem fehlt eine direkte Verbindung zu technischen (Workflow-)Modellierungen. Für eine bessere Lesbarkeit bietet es sich an, komplexere eEPK-Modelle entweder in mehrere Teilmodelle gleicher Hierarchieebene wie das Originalmodell aufzuspalten, oder aber Teilaspekte in einer Funktion des Originalmodells zu aggregieren und die Details in einem

8 Organisationsebene

162

Konnektor

Funktionsverknüpfung

Ereignisverknüpfung

Art der Verknüpfung

Disjunktion (XOR)

Konjunktion (AND)

Adjunktion (OR)

Auslösendes Ereignis

Ausgelöstes Ereignis

Auslösendes Ereignis

X

X

Ausgelöstes Ereignis

Abb. 8.9  Varianten der Ereignis-Funktions-Verknüpfung in einer EPK (nach (Keller und Meinhardt 1994, S. 13))

zusätzlichen Modell in der darunterliegenden Hierarchiestufe abzubilden. Eine weitere Möglichkeit zur Verschlankung von eEPK-Modellen ist die Entfernung von Ereignissen, deren Bedeutung mit der sie auslösenden Funktion identisch ist (sog. Trivialereignisse: z. B. Ereignis „Uhren-Konfiguration ist erstellt“ als Folge der Aktivität „Uhren-­Konfiguration erstellen“). Abb.  8.10 zeigt den Ablauf des Leistungsprozesses „Zusammenstellung Uhrenmodelle“ aus der Prozesslandkarte des Uhren-Beispiels (s. Abb. 8.2) als eEPK-Modell mit beteiligten Organisationseinheiten und jeweils benötigten bzw. erstellten Informationsobjekten. Dieser Prozess kann nur beginnen, wenn freie Mitarbeiterkapazitäten bei den Uhren-­Konfiguratoren vorhanden sind. Da bei der Zusammenstellung eines Kinderuhrenmodells zu Beginn andere Aktivitäten zu durchlaufen sind als bei der Zusammenstellung eines Sportuhrenmodells, splittet in Abb. 8.10 ein XOR-Konnektor den Sequenzfluss zunächst für die beiden verschiedenen Uhrenmodellgruppen auf. Vor der Herstellung des Uhren-Prototypen fließt der Sequenzfluss wieder zusammen, da ab hier das weitere Vorgehen bei beiden Uhrenmodellgruppen identisch weiterverläuft. Auch dieses eEPK-­ Prozessmodell zeigt, wie einzelne Funktionen/Aktivitäten in einem Prozess Informationsobjekte erzeugen und in nachfolgenden Funktionen wiederverwenden. Neben Modellen in eEPK- und BPMN-Notation kommen zur Prozessmodellierung in der Praxis auch Notationen aus dem Bereich der Softwareentwicklung zum Einsatz. Dazu zählen Aktivitätsdiagramme, Sequenzdiagramme und Use Case-/Anwendungsfall-­ Diagramme, wie sie in der Modellierungssprache UML (s. Abschn. 9.4 und 14.3.1) enthalten sind. Sequenzdiagramme sind dabei auf die Darstellung von nachrichtenbasierten

8.3 Ablaufplanung

163

Freie Mitarbeiterkapazitäten bei den UhrenKonfiguratoren

Neues Uhrenmodell soll entworfen werden

Teamleiter Konfiguration

Kundenzielgruppe bestimmen Vorlagen Kindermotive

Uhrenmodell für Kinder

Uhrenmodell für Sportler

Liste Sportfunktionen

Konfigurator Kinderuhren

Konfigurator Sportuhren Kindermotiv für den Hintergrund auswählen

Sportfunktionen der Uhr auswählen

Auswahl Kindermotiv

Sortimentslisten für Kinderuhren: - Gehäuse - Armbänder - Uhrwerke

Auswahl Sportfunktionen Komponenten für Kinderuhr auswählen

Komponenten für Sportuhr auswählen

Sortimentslisten für Sportuhren: - Gehäuse - Armbänder - Uhrwerke

Uhren-Prototyp herstellen Stückliste Uhrenmodell Qualitätsverantwortlicher

Uhrmacher Uhren-Prototyp technisch prüfen

Prüfprotokoll des UhrenPrototyps

Teamleiter Konfiguration

Abteilungsleiter Produktmanagement

Uhrenmodell vorstellen

Uhrenmodell in das Verkaufssortiment aufnehmen

Konfigurator Kinderuhren oder Sportuhren

Bestätigung Verkaufsfreigabe für Uhrenmodell

Verkaufsfreigabe für Uhrenmodell erteilt

Abb. 8.10  eEPK-Ablaufmodell im Uhren-Beispiel

I­ nteraktionen zwischen Objekten bzw. Systemen, und Use-Case-Diagramme auf die statische Darstellung von Anwendungsfällen, Akteuren und ihren Beziehungen fokussiert. Sie sind somit weniger für die fachliche Modellierung von Prozessen geeignet. Das Aktivitätsdiagramm bildet jedoch mit seinen Aktivitätsknoten, Kontrollknoten sowie Kontroll- und Datenflüssen eine Alternative für die fachliche Prozessmodellierung.

164

8 Organisationsebene

8.3.4 Aktuelle Entwicklungen Die Ansätze zur Organisations- bzw. Prozessmodellierung haben in den vergangenen Jahren Weiterentwicklungen in verschiedene Richtungen erfahren. Dazu zählen die Prozesssimulation, das Process Mining, die Modellierung von Entscheidungsregeln sowie die robotergesteuerte Automatisierung von Prozessen. Bei der Prozesssimulation ergänzen Mengen- und Zeitgerüste die Prozessmodelle für quantitative Analysen und Simulationen des Prozessablaufs. Diese initialen Vorgaben enthalten z. B. Informationen zur prognostizierten Häufigkeit von Aktivitäten bzw. Prozessen, zu den erwarteten Durchlauf- und Transportzeiten, zu aktivitätsbedingten Kostensätzen und zu Ressourcenkapazitäten. Geeignete Modellierungs- oder spezialisierte Simulationswerkzeuge berechnen auf Basis der Mengengerüste quantitative Ergebnisse zur Entwicklung spezifischer Führungsgrößen im Zeitverlauf. Durch solche Simulationen lassen sich neben kritischen Pfaden auch Prozesskosten und Durchlaufzeiten prognostizieren, sodass sich gezielt Prozessparameter (z. B. geeignete Anzahl von Mitarbeitern pro Schicht) zur Verkürzung von Durchlaufzeiten, Minimierung von Kapazitätsüberschüssen oder zur Senkung von Kosten ermitteln lassen. Um Simulationen und darauf aufbauende Prozessverbesserungen zu ermöglichen sind Ablaufdiagramme bis auf die gewünschte Granularitätsstufe zu detaillieren, logische Verknüpfungen von Aktivitäten zu modellieren und Ausführungswahrscheinlichkeiten für die Prozesspfade anzugeben (Winter 2011, S. 120). Seit Anfang der 2000er-Jahre sind mit dem Process Mining Werkzeuge entstanden, die eine automatisierte Konstruktion und Analyse von Prozessen vorsehen (van der Aalst 2011). Das Process Mining nutzt einen Bottom-up-Ansatz, da es von den in der Vergangenheit real abgelaufenen anwendungsgestützten Prozessen ausgeht. Process-­Mining-­Werkzeuge, wie etwa ARIS PPM, Celonis, Disco oder ProM, ermitteln aus Protokolldateien (Log Files) historischer Prozessinstanzen die aufgetretenen Varianten in der Aktivitätsabfolge und führen weitere quantitative Analysen durch (z. B. Bestimmung von Häufigkeiten für Prozessvarianten). Die Protokolldateien aus den am Prozess beteiligten Anwendungen enthalten zeitliche (z. B. Start- und Endzeitpunkt der Bearbeitung einer Anwendungsfunktion), ablauforganisatorische (z. B. Bearbeitungsreihenfolge von Anwendungsfunktionen) und aufbauorganisatorische (z. B. Bearbeiter einer Anwendungsfunktion) Informationen. Aus den tabellarisch oder auch in Form von grafischen Modellen (z. B. Prozessmodelle, Organigramme) aufbereiteten Ergebnissen lässt sich etwa die Reihenfolge der durchlaufenen Aktivitäten jeder einzelnen Prozessinstanz herauslesen, welche Organisationseinheiten bzw. Rollen oder Mitarbeiter beteiligt waren, wie lange die Aktivitäten gedauert oder welche Prozessinstanzen zum gewünschten Ergebnis geführt haben. In der Gesamtheit liefern Process-Mining-Analysen somit Hinweise auf Problembereiche und Ansatzpunkte für zukünftige Prozessveränderungen in der Ablaufplanung. In diesem Zusammenhang ist auch erkennbar, ob die Prozessausführungen (Prozessinstanzen) den regulatorischen Anforderungen genügen (Compliance). Abb.  8.11 zeigt beispielhaft die Ablaufvarianten eines Prozesses zur Erstellung von Kostenvoranschlägen im Process-Mining-Werkzeug Disco. Bereits in den dargestellten ersten Schritten dieses Prozesses ist zu erkennen, dass alle Prozessinstanzen zunächst mit

8.3 Ablaufplanung

165

337 Create Purchase Requisition 337

109

228 Analyze Purchase Requisition 228

Create Request for Quotation Requester 109

165

Create Request for Quotation Requester Manager 165

109

165 Analyze Request for Quotation 303

194 Send Request for Quotation to Supplier 194

29

29

Amend Request for Quotation Requester 29

194

Abb. 8.11  Beispiel einer Process-Mining-Analyse (erstellt in Disco 2.1.0)

der Aktivität „Create Purchase Requisition“ beginnen, sich im weiteren Verlauf jedoch verschiedene Prozesspfade herausbilden, die unterschiedlich häufig zur Anwendung gekommen sind und zum Teil sogar zum vorzeitigen Abbruch von Prozessinstanzen geführt haben (gestrichelte Kanten). Einen weiteren Entwicklungsschritt bildet die Modellierung von Entscheidungsregeln (Business Rules). Dieser entstand aus der Beobachtung, dass Entscheidungssituationen in Prozessen häufig vorkommen und diese einfach veränderbar sein sollen. In Prozessmodellierungssprachen (z. B. EPK, BPMN) sind Entscheidungssituationen mit Hilfe von Konnektoren bzw. Gateways (s. Abschn. 8.3.3) direkt in den Prozessmodellen darstellbar. Bei komplexen Entscheidungen stößt diese Art der Modellierung jedoch in Bezug auf die Übersichtlichkeit schnell an ihre Grenzen. Das Business Rules Management zielt daher auf separate und damit schnell anpassbare Abbildung von Entscheidungsregeln (z. B. mit Hilfe von Entscheidungstabellen oder grafischen Entscheidungsmodellen) losgelöst von den Prozessmodellbeschreibungen. Die 2015 entwickelte Decision Model and Notation (DMN) (OMG 2018) ist eine standardisierte Sprache zur Modellierung von Entscheidungsregeln im Prozessmanagement und unterstützt auch deren automatisierte Verarbeitung. Die Basis der DMN bildet das Decision-Requirements-Diagramm, das Entscheidungen zusammen mit den hierfür benötigten Hilfsmitteln/Informationen in grafischer Form darstellt.

8 Organisationsebene

166

Abb.  8.12 zeigt ein solches Diagramm für die Entscheidung „Gutschein für Uhren-­ Kunden auswählen“. Diese Entscheidung (dargestellt als Rechteck) unterstützt ein zusammengefasstes, und hier in Form einer Entscheidungstabelle abgebildetes Geschäftswissen (ein sog. Business Knowledge Model, dargestellt als Rechteck mit zwei abgeschrägten Ecken). Diese Tabelle und die darin enthaltene Entscheidungslogik basiert auf zwei sog. Knowledge-Source-Elementen (dargestellt als Rechtecke mit einer Wellenlinie als untere Kante). Zum einen ist dies die „Kundenwertanalyserichtlinie“ mit den vom Uhrenhersteller beschlossenen Vorgaben zur Bestimmung des Kundenwertes eines Uhren-Kunden, sowie die „Gutscheinvergaberichtlinie“ mit den Vorgaben für die Vergabe unterschiedlicher Gutscheine in Abhängigkeit vom Kundenwert. Auch sind für die Entscheidungssituation „Gutschein für Uhren-Kunden auswählen“ neben der „Entscheidungstabelle zur Gutscheinvergabe“ weitere Inputdaten („Kaufhistorie Uhren-Kunde“, „Stammdaten Uhren-Kunde“) einzubeziehen. Die robotergesteuerte Prozessautomatisierung (Robotic Process Automation, RPA) (van der Aalst et al. 2018) zielt auf die vollautomatisierte Nachahmung manueller Prozessschritte, bei denen bisher eine einfache menschliche Interaktion mit Benutzerschnittstellen von Anwendungen notwendig gewesen ist. Software„roboter“ übernehmen dabei die in Prozessabläufen notwendigen Eingaben und die Extraktion von Daten über die Benutzeroberflächen einer oder mehrerer Anwendungen. Die einzelnen Softwareroboter-­Instanzen arbeiten dazu in virtuellen Arbeitsumgebungen und steuern die Interaktion mit Hilfe von simulierten Maus- und Tastaturinteraktionen. Der Vorteil von RPA liegt darin, dass damit eine Automatisierung manueller Arbeitsschritte erfolgen kann, ohne jedoch aufwändig zu programmierende Schnittstellen zwischen den Anwendungen zu schaffen. Zudem zielen RPA-Werkzeuge auf eine einfache Konfiguration der zu automatisierenden Schritte, sodass diese auch geschulte Fachanwender durchführen können. Damit entlastet RPA Anwender von monotonen Routineaufgaben und reduziert das Potenzial menschlicher Benutzerfehler. Im Uhren-Beispiel ist der Onlineshop nicht über eine direkte Datenschnittstelle mit der Customer Relationship Management (CRM)-Anwendung (s. Abschn. 12.2.1) des Uhrenherstellers verbunden. RPA könnte hier die vom Uhren-Kunden im Onlineshop eingegebenen Kundenstammdaten über die Benutzerschnittstelle der Onlineshop-Bestellverwaltung auslesen und einen entsprechenden Kundendatensatz in der CRM-Anwendung neu anlegen oder aktualisieren.

Kundenwertanalyserichtlinie

Kaufhistorie Uhren-Kunde Gutschein für Uhren-Kunden auswählen Stammdaten Uhren-Kunde

Entscheidungstabelle zur Gutscheinvergabe Gutscheinvergaberichtlinie

Abb. 8.12  Modellierung von Entscheidungen mittels DMN im Uhren-Beispiel

8.5 Operative Prozessführung und -messung

8.4

167

Aufbauorganisation

Obgleich im Prozessmanagement die Ablauforganisation dominiert und die Ablaufplanung damit zunächst unabhängig von bestehenden Abteilungsgrenzen erfolgt, ist in einem anschließenden Schritt über die Aufbauorganisation zu entscheiden. Die Grundelemente der aufbauorganisatorischen Struktur eines Unternehmens bilden die Stellen, die durch die Bündelung inhaltlich zusammenhängender Einzelaufgaben entstehen. Der Umfang eines Aufgabenbündels und damit einer Stelle ist in der Regel so gestaltet, dass ein Mitarbeiter bzw. Aufgabenträger längerfristig damit beschäftigt ist. Die Beschreibung einer ­organisatorischen Rolle basiert ebenfalls auf der Zuordnung zu spezifischen Aufgaben, enthält aber zusätzlich Informationen zu den Mindestqualifikationen eines Rollenträgers und zu den durch die Rolle übertragenen Kompetenzen (Winter 2011, S. 120 ff.). Organigramme sind Modelle, die die aufbauorganisatorische Struktur einer Organisation mit ihren Stellen, den darauf aufbauenden Organisationseinheiten und den sich dabei ergebenden Hierarchiebeziehungen abbilden. Prozessmodelle und Organigramme stellen im Kern jeweils andere Aspekte einer Organisation dar. Je nach Bedarf können aber Querbezüge durch Zuordnung von Aktivitäten zu Organisationseinheiten hergestellt werden (Winter 2011, S. 120 ff.), so wie dies bei eEPK-Modellen durch die Verwendung des Objekttyps Organisationseinheit und bei BPMN-Modellen durch die Verwendung von Pooles und Lanes berücksichtigt ist. Zum Abschätzen des künftigen Ressourcenbedarfs organisatorischer Einheiten und Stellen (z. B. in Form von Stellen-Vollzeitäquivalenten) können Prozesssimulationen sinnvoll sein, deren Ergebnisse zur benötigten Personalstärke wiederum die Grundlage zur Bildung aufbauorganisatorischer Strukturen (z.  B.  Teams oder Abteilungen) liefern. Es folgt die Bestimmung von Teamleitern, Abteilungsleitern und weiteren Führungseinheiten. Abb. 8.13 zeigt für das Uhren-Beispiel das Organigramm für den aufbauorganisatorischen Bereich des Produktmanagements. Dieser Organisationseinheit sind sechs Rollen zugeordnet, die wiederum jeweils ein oder mehrere Mitarbeiter ausfüllen. Dieses Organigramm enthält zusätzlich Informationen zu den Führungsstrukturen (Abteilungsleiter und Teamleiter) innerhalb dieser Organisationseinheit.

8.5

Operative Prozessführung und -messung

Die operative Prozessführung setzt an der Spezifikation von Organisationszielen, kritischen Erfolgsfaktoren und strategischen Führungsgrößen an (s. Abschn. 7.4). cc Prozessführungsgröße  Prozessführungsgrößen leiten sich aus strategischen Organisationszielen ab und dienen der Messung und Bewertung von Prozessen. Tab. 8.2 illustriert die Ableitung von kritischen Erfolgsfaktoren sowie von strategischen und Prozessführungsgrößen bezüglich der strategischen Zielstellung „Platzierung unter den Top 10

8 Organisationsebene

168

Frau Klos

Produktmanagement

Ansprechpartner UhrengehäuseLieferanten

Ansprechpartner ArmbandLieferanten

Frau Mayer Herr Schuster

Organisationseinheit

Herr Huster

Rolle Ansprechpartner UhrwerkLieferanten

Konfigurator Kinderuhren

Frau Walser Frau Czernik

Abteilungsleiter

Herr Paulsen

Teamleiter

Mitarbeiter Konfigurator Sportuhren

Herr Peters

Frau Steiner Designer Verzierungen

Abb. 8.13  Organigramm im Uhren-Beispiel

Tab. 8.2  Operative Prozessführung im Uhren-Beispiel Kritische Strategische Unternehmensziele Erfolgsfaktoren Führungsgrößen Platzierung unter Hohe Kundenzufriedenheitsindex den Top 10 Kundenorientierung Uhrenherstellern

Hohe Variabilitätsindex Angebotsvariabilität Uhrenkomponenten

Prozessführungsgrößen mit Sollwerten Stornierungsrate (Soll: < 3 %) Beschwerderate (Soll: < 7 %) Wiederkaufrate (Soll: > 30 % nach 2 Jahren) Anzahl Gehäusevarianten pro Basis-Uhrenmodell (Soll: > 5 Gehäusevarianten)

8.5 Operative Prozessführung und -messung

169

Uhrenherstellern“. Beispielsweise lässt sich der kritische Erfolgsfaktor „Hohe Kundenorientierung“ durch die strategische Führungsgröße „Kundenzufriedenheitsindex“ abbilden und damit einer Messbarkeit zuführen. Zur Berechnung des „Kundenzufriedenheitsindex“ dienen wiederum die in den operativen Prozessen zu messenden Prozessführungsgrößen „Stornierungsrate“, „Beschwerderate“ und „Wiederkaufrate“. Letztere sind mit Sollwerten versehen, sodass der Uhrenhersteller bei der kontinuierlichen Messung dieser Führungsgrößen im operativen Betrieb (im Sinne eines Business Activity Monitoring, BAM) die gemessenen Größen mit den Sollwerten vergleichen kann. Für den Fall der Überschreitung von Soll-/Schwellwerten sind Alarmierungsprozesse und – soweit möglich – Problembehebungsprozesse festzulegen. Die Messung und Bewertung von Prozessen dient vornehmlich zur Identifizierung von Situationen und Prozesszuständen, die die Erreichung von Prozesszielen und damit die performante Ausführung von Prozessen behindern. Die in den 1980er-Jahren entwickelte, und sich am Konzept des Continuous Improvement (CI) (s. Abschn. 6.1) orientierende Six-Sigma-Prozessverbesserungsmethodik (Toutenburg und Knöfel 2008) versucht durch Verbesserung der Prozessqualität und Reduzierung von zuvor gemessenen/identifizierten Prozessfehlern sowohl die Kundenzufriedenheit als auch die Wirtschaftlichkeit von Unternehmen zu erhöhen. Zur Bestimmung der Qualität von Prozessinstanzen kommt hier die Kennzahl Defects per Million Opportunities (DPMO) zur Anwendung. Diese Messgröße unterscheidet nicht nach spezifischen Kennzahlendimensionen (z. B. Kosten, Zeit), sondern subsumiert diese spezifischen Aspekte unter einem generischen Qualitätsbegriff. Zur Berechnung der DPMO ist wie folgt vorzugehen: • Zu jedem Prozess existieren Anforderungen aus Kundensicht, deren Einhaltung mit entsprechenden Messinstrumenten zu überwachen ist. Im Rahmen des Uhren-Beispiels sind dies einerseits der Versand einer bestellten Uhr an den „Uhren-Kunden“ innerhalb von sieben Tagen, und andererseits die Ausstattung und Gestaltung der Uhr in Übereinstimmung mit den Kundenwünschen. • Bei jeder einzelnen Prozessinstanz (z. B. eine einzelne Bestellung einer Uhr durch einen spezifischen Kunden) besteht die Möglichkeit, dass eine oder mehrere Anforderungen nicht erfüllt sind. Im Uhren-Beispiel gibt es somit je Prozessinstanz zwei Fehlermöglichkeiten, die bei Nichterreichung als Defekt zu zählen sind. • Nach der Berechnungsformel der DPMO (s. Abb. 8.14), stellt die „Anzahl betrachteter Einheiten“ die im Rahmen der Berechnung berücksichtigte Anzahl/Stichprobe von Prozessinstanzen dar (z. B. 200 Uhrenkauf-Prozesse). Die „Gesamtanzahl Defekte“ bezieht sich auf die bei dieser Stichprobe ermittelte Anzahl an Defekten. In diesem Beispiel (s. Abb. 8.14) sollen bei den 200 Prozessinstanzen insgesamt zwölf Defekte (d. h. jeweils ein verspäteter Versand oder eine nicht anforderungsgerecht gestaltete Uhr) vorgekommen sein. • Durch die Multiplikation mit 1 Million ergibt sich für dieses Beispiel ein DPMO-Wert von 30.000. Die (idealtypische, und in der Praxis meist nur schwer zu erreichende) Zielstellung beim Six-Sigma-Ansatz besteht darin, den DPMO-Wert auf 3,4 (99,99966 % Fehlerfreiheit) und damit auf das Sigma-Level 6 zu reduzieren. Das Uhrenbeispiel bewegt sich mit einem DPMO-Wert von 30.000 (97 % Fehlerfreiheit) zwischen dem Sigma-Level 3 und 4 und besitzt somit noch Verbesserungspotenzial.

170

DPMO =

DPMO =

8 Organisationsebene Gesamtanzahl Defekte bei den betrachteten Einheiten Anzahl betrachteter Einheiten * Fehlermöglichkeiten pro Einheit 12 200 * 2

* 1.000.000

* 1.000.000 = 30.000

Abb. 8.14  Berechnung der DPMO-Kennzahl

Die Berechnung des DPMO-Werts dient somit zur Bestimmung des Qualitätsgrads für einzelne Prozesse oder ganze Prozess- oder Unternehmensbereiche. Entspricht das Qualitätsniveau nicht den Erwartungen, so bietet sich die Durchführung eines Six-Sigma-­ Prozessverbesserungsprojekts in fünf Phasen an (Toutenburg und Knöfel 2008, S. 37 ff.): • Define. Umfasst die Eingrenzung und Beschreibung der Probleme, die Bestimmung der Prozesskunden und ihrer Anforderungen bzw. Projektziele sowie die Projektzeitplanung und die Organisation des Projektteams. • Measure. Fokussiert auf die Konfiguration des Messsystems, die Detailmessung der Prozessleistungen und den anschließenden Vergleich mit den Kundenanforderungen. • Analyze. Konzentriert sich auf die Analyse der Prozessergebnisse, der Fehlerursachen und der Einflussfaktoren sowie auf die nachfolgende Bestimmung detaillierter Verbesserungsziele. • Improve. Evaluiert die Gestaltungsoptionen zur Prozessverbesserung sowie die Entwicklung, Pilotierung und Implementierung der Lösung. • Control. Erstellt einen Kontrollplan und überprüft die neuen Prozessergebnisse hinsichtlich der Zielsetzungen. Die Inhalte dieses Six-Sigma-Vorgehensmodells ähneln den in Tab. 6.1 gezeigten Aktivitäten im Rahmen von BPR-Projekten. Im Detail existieren jedoch Abweichungen insbesondere bei der Zuordnung einzelner Aktivitäten zu den übergeordneten Phasen. So vereint die Define-Phase (Six-Sigma) beispielsweise inhaltliche Elemente aus den BPR-Phasen Projektvision und Initiierung sowie Teile der Diagnose. Des Weiteren setzen Six-Sigma-Projekte direkt auf den aktuellen Prozessstrukturen auf und versuchen diese nicht nach dem BPR-Ansatz radikal zu verändern, sondern im Sinne des CI-­Ansatzes schrittweise zu perfektionieren. Die Six-Sigma-Methodik bietet zahlreiche Techniken und Modelle, die in den einzelnen Projektphasen zum Einsatz kommen können. Das SIPOC-Diagramm ist eine Modellform zur groben Beschreibung der Abfolge von Kernaktivitäten in Prozessen und ist für die Makro-Prozessdarstellung (s. Abschn. 8.3.1) in der Define- und Measure-Projektphase sowie ggf. auch in der Improve-Phase einsetzbar. Ein SIPOC-Diagramm enthält zu jedem Prozessschritt (mittlere Spalte Process, s. Tab. 8.3) die jeweils notwendigen Vorleistungen (Input) und deren Bereitsteller (Supplier) sowie die jeweils erzeugten Leistungen (Output) und deren Konsumenten (Customer). Tab. 8.3 zeigt ein Teil des aus Abb. 8.7 bekannten Prozesses zur Uhrenauswahl als SIPOC-Diagramm. In Erweiterung zur standardmäßigen

8.5 Operative Prozessführung und -messung

171

Tab. 8.3  SIPOC-Diagramm im Uhren-Beispiel Supplier IT-Abteilung

Input Webseite Uhren-­ Onlineshop

Process Uhren-­ Onlineshop öffnen (Uhrenkunde) Produktmanagement Elektronische Uhrenmodelle anzeigen Liste (Uhren-­ verfügbarer Uhrenmodelle Onlineshop) Uhren-Onlineshop Übersicht Basis-­ verfügbarer Uhrenmodell Uhrenmodelle suchen Uhren-Kunde Anforderungen (Uhren-­ Kunde) an das Uhrenmodell Interne Ausgewähltes Basis-­ Konfigurationsfunktion Basis-­ Uhrenmodell Uhrenmodell konfigurieren (Uhren-­ Basis-­ Uhrenmodell-­ Kunde) spezifische Konfigurations-­ elemente Uhren-Kunde Anforderungen an die Ausstattung und Gestaltung des BasisUhrenmodells

Output Zugang zum Uhren-­ Onlineshop

Customer Uhren-Kunde

Übersicht Uhren-Kunde verfügbarer Uhrenmodelle Ausgewähltes Interne Basis-­ Konfigurationsfunktion Uhrenmodell

Konfiguriertes Interne Preis-­ Basis-­ kalkulationsfunktion Uhrenmodell

Darstellung eines SIPOC-Diagramms sind hier zu den Prozessschritten zusätzlich die verantwortlichen Akteure in Klammern vermerkt. Während in der Measure-Phase vorwiegend Kennzahlendefinitionen und Kennzahlenmessungen (u. a. mit Hilfe statistischer Funktionen) zum Einsatz kommen, sind in der Analyze-Phase u. a. Techniken zur Ursachenermittlung (z. B. Ishikawa (Fishbone)-Diagramm) und zur Fehlereffektanalyse (z. B. Failure Mode and Effects Analysis, FMEA) einsetzbar. In der Improve-Phase kommen sowohl Kreativitätstechniken (z. B. Brainstorming) zur Generierung neuer Ideen für die Prozessumgestaltung als auch Techniken zur Vorab-Bewertung von Lösungsalternativen (z. B. Kosten-Nutzen-Matrix, Simulationen (s. Abschn. 8.3.4, Pilotierungen) zum Einsatz. Die Control-Phase nutzt neben den Prozessmessungstechniken aus der Measure-Phase Instrumente für die langfristige Prozesskontrolle und Problembeseitigung (z. B. Kontroll- und darauf aufbauende Reaktionspläne) sowie Techniken für die Replikation von Best Practices auf andere Prozess- oder Unternehmensbereiche (z. B. Einrichtung regelmäßiger Workshops für den innerbetrieblichen Erfahrungsaustausch).

9

Informationssystemebene

Zusammenfassung

Kapitel 9 beschreibt zunächst die Gestaltungsziele auf IS-Ebene sowie die prinzipiell zu unterscheidenden Architekturtypen. Im weiteren Verlauf erläutert es den Beitrag serviceorientierter Architekturen (SOA) für die fachlich-technische Integration. Die Darstellung der UML-Modellfamilie als übergreifender Ansatz zur Modellierung von IS und der Entity-Relationship-Notation zur Modellierung von Daten bildet den Abschluss des Kapitels.

9.1

Gestaltungsinhalte auf IS-Ebene

Gegenüber der Strategie- und der Organisationsebene konzentriert sich diese Ebene auf Fragen der Gestaltung von Informationssystemen (IS) mit den darin verwendeten Anwendungen und hardwaretechnischen Komponenten. Trotz des Strebens nach möglichst integrierten Anwendungen (s. Teil 3) besitzen Unternehmen in der Realität mehrere Anwendungen, die darüber hinaus von verschiedenen Softwareanbietern stammen können. Dies kann zum Beispiel bei spezifischen Geschäftsfunktionen (z.  B.  Produktionssteuerung) oder bei verschiedenen Geschäftsbereichen (z.  B.  Produktmarken) oder Landesgesellschaften der Fall sein. cc Anwendung  Eine Anwendung (oder eine Anwendungssoftware bzw. eine Applikation) ist ein Softwaresystem, das durch die Abbildung der Geschäftslogik die fachlichen Aufgaben eines Unternehmens unterstützt. Als Teilbereich eines IS konzentriert sich die Anwendung auf eine hohe Integration der darin abgebildeten Funktionen, um einen möglichst hohen Automationsgrad zu erzielen.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_9

173

174

9 Informationssystemebene

Für eine möglichst medienbruchfreie Unterstützung von Geschäftsprozessen lassen sich die einzelnen Anwendungen über Schnittstellen miteinander verbinden. Derartige Schnittstellen erlauben einerseits die flexible (Wieder-)Verwendung von Komponenten dieser Anwendung, und andererseits die Kopplung mit weiteren Anwendungen innerhalb und außerhalb des Unternehmens. Sie erfordern jedoch auch eine übergreifende Betrachtung und Abstimmung im Rahmen einer Gesamtarchitektur bzw. Anwendungslandschaft. Auf der IS-Ebene lassen sich fünf grundsätzliche Gestaltungsziele formulieren (Winter 2011, S. 47 f.): • Die Grundlage bildet die Transparenz, wonach Beziehungen zwischen fachlichen Strukturen (Aktivitäten und Informationen) und IT-Strukturen (z. B. Softwarekomponenten und Datenstrukturen) dokumentiert sind. Dies erlaubt die systematische Erfassung und Umsetzung von Veränderungen, wie sie bei der Einführung neuer Produkte oder bei der Anpassung an neue regulatorische Vorgaben vorkommen. • Ist Transparenz erreicht, folgt das Konsistenzziel (s. Kap. 6). Konsistenz heißt hier, dass die Anforderungen aus der Geschäfts- und Prozessarchitektur mit den Funktionen der Anwendung abgestimmt sind (Business-IT-Alignment, s. Abschn.  3.2.2.2). Die Abstimmung verläuft dabei in zwei Richtungen: Einerseits sollen die Anwendungsfunktionen die fachlichen Anforderungen abdecken, und andererseits sollen die fachlichen Lösungen die Digitalisierungspotenziale nutzen. • Wenn Konsistenz gegeben ist, schließt sich das Vereinfachungsziel an. Zur Vereinfachung tragen insbesondere die Beseitigung von Redundanzen (z. B. durch Wiederverwendung von Anwendungs-Komponenten/-Funktionen) und die Vereinheitlichung (z.  B. durch Standardisierung von Prozessen, Datenformaten sowie Schnittstellen) bei. • Wenn fachliche und IS-Strukturen konsistent und einfach gestaltet sind, können weitere Maßnahmen versuchen, die Flexibilität des Gesamtsystems zu erhöhen. Einerseits lässt sich dies durch eine modulare Gestaltung von IS-Strukturen erreichen. Andererseits hilft auch die Berücksichtigung einer Integrations-Architekturebene dabei, dass nicht jede Änderung fachlicher Anforderungen zu IS-Änderungen führt und umgekehrt. Das Konzept der serviceorientierten Architektur (SOA) (s. Abschn. 9.3) ist ein Ansatz in diese Richtung. • Sind alle anderen Ziele erfüllt, lässt sich auch Agilität erzielen: Im Gegensatz zur Flexibilität bezieht sich Agilität nicht auf bekannte bzw. aktuelle Änderungen, sondern auf die Fähigkeit zur Anpassung auf unbekannte/zukünftige Änderungen. Nachfolgend steht in Abschn. 9.2 zunächst die Anwendungslandschaft „im Großen“ im Vordergrund, die auf aggregierter Ebene Integrationsbereiche und ihre Kopplungen enthält. Danach skizziert Abschn.  9.3 den Modularisierungsansatz der serviceorientierten Architekturen (SOA) und ihre Bedeutung für die Gestaltung flexibler und agiler Anwendungen. Anschließend zeigen die Abschn. 9.4 und 9.5 zwei auf IS-Ebene verwendete Modellierungsansätze. Dies sind die Sprachfamilie UML zur Systemmodellierung und die Entity-Relationship-Notation zur Datenmodellierung.

9.2 Anwendungsarchitektur und Anwendungslandschaft

9.2

175

Anwendungsarchitektur und Anwendungslandschaft

Zur Realisierung der vorgenannten Gestaltungsziele ist beim Aufbau betrieblicher Anwendungen eine Entwicklung in Richtung modularisierter Architekturkonzepte zu beobachten. Diese folgt dem Prinzip, wonach sich Komponenten mit festgelegter Funktionalität und Schnittstelle entkoppeln und wiederverwenden lassen. Ausgangspunkt ist die Aufteilung von Anwendungen in eine Präsentations-, eine Funktions- und eine Datenschicht (Alt und Puschmann 2016, S.  151  ff.). Danach besitzt jede Anwendung eine Benutzerschnittstelle (Präsentationsschicht), eine funktionale Verarbeitungslogik zur Abbildung der betriebswirtschaftlichen Prozesse (Funktionsschicht) sowie eine Datenbank zur Speicherung der verwendeten Daten (Datenschicht). Während bei den frühen sog. Einschicht-­ Architekturen („1-Tier“, s. Tab. 9.1) Anwendungen alle Schichten monolithisch zusammengefasst haben, fand mit Client-Server-Architekturen (s. Glossar) zunächst eine Entkopplung von Anwendungslogik und Datenbank statt. Auf die Schnittstelle der entkoppelten Datenbank konnten damit mehrere Anwendungen mit ihren Funktionen zugreifen („2-Tier“). In einer späteren Entwicklungsstufe war in Client-Server-Architekturen auch eine Entkopplung von Anwendungslogik und Präsentationsschicht zu beobachten. Dies ermöglichte den Nutzern den Zugriff auf die Funktionen mehrerer Anwendungen über eine entkoppelte Benutzerschnittstelle (z. B. einen Webbrowser). Die aktuelle Entwicklungsstufe hat zur Bildung einer weiteren Schicht geführt. Ursächlich dafür ist der mit der bilateralen Kopplung von Modulen verbundene Integrationsaufwand, der gerade in großen Unternehmen mit mehreren hundert oder sogar tausend Anwendungen stark angestiegen ist. Eine Integrationsschicht soll als zentrale Instanz die bilateralen Beziehungen vermeiden, sodass sich über eine einzige Verbindung zur Integrationsschicht alle anderen daran angeschlossenen Module ansprechen lassen. Derartige Integrations-Anwendungen erlauben die zentralisierte Verwaltung von Schnittstellen, die Transaktionsabwicklung über mehrere verteilte (operative) Anwendungen hinweg sowie die Bereitstellung zentralisierter Dienste (z. B. Verzeichnisse). Bekannt sind hier Middleware- und Enterprise-Application-Integration (EAI)-Anwendungen. Derartige zentralisierte Integrationsplattformen Tab. 9.1  Architekturtypen betrieblicher Anwendungen (Alt und Puschmann 2016, S. 153) Architekturtyp 1-Tier Anzahl Eine Schichten Beispiel Host-zentriert, z. B. IBM CICS Beschreibung Präsentation, Anwendungsfunktionalität, Daten sind in einer Anwendung integriert.

2-Tier Zwei

3-Tier Drei

n-Tier > Drei

2-Tier Client-/ Server (Fat Client), z. B. SAP R/2 Zusammengefasste Präsentations- und Anwendungsfunktionalität, separate Daten-Server-­ Ebene.

3-Tier Client-/ Server, z. B. SAP R/3 Anwendungs-­ funktionalität, Daten und Präsentation sind als eigene Schicht umgesetzt.

4-Tier Integrationsarchitektur, z. B. SAP NetWeaver Anwendungsfunktionalität, Daten und Präsentation sind auf viele Schichten verteilt.

176

9 Informationssystemebene

­ ilden ein Merkmal serviceorientierter Architekturkonzepte (SOA), die Komponenten der Anb wendung als sog. Services verwalten und verbinden (s. Abschn. 9.3). Wie aus der Beschreibung der Anwendungsschichten (s. Tab. 9.1) hervorgeht, sind auf IS-Ebene neben den Anwendungsfunktionalitäten die Datenmodelle und die unterstützenden technischen Infrastrukturen relevant. Analog zu den Modellen auf Organisationsebene kommen auch bei Modellen zur Anwendungslandschaft grob- und feingranulare Übersichten (Makro/Mikro-Sicht) zum Einsatz. Grobgranulare Modelle enthalten Gesamtübersichten über alle Anwendungscluster einer Organisation, w ­ ährend feingranulare Modelle konkrete Anwendungen mit ihren funktionalen Modulen und Schnittstellen abbilden. Aufbauend auf den grundsätzlichen Architekturtypen betrieblicher Anwendungen zeigt die Anwendungslandschaft eine Gesamtsicht über die Anwendungen einer organisatorischen Einheit. cc Anwendungslandschaft  Eine Anwendungslandschaft besteht aus der Gesamtheit aller Anwendungen eines Untersuchungsobjekts (z. B. einer Abteilung, eines Unternehmens oder eines Unternehmensnetzwerks) einschließlich der zwischen den Anwendungen bestehenden Kommunikationsbeziehungen und Schnittstellen (Wittenburg 2007, S. 3). Ein generisches Beispiel zeigt Abb.  9.1, bei dem innerhalb der Anwendungslandschaft verschiedene Applikationskomponenten (z.  B. ein Portal, domänenspezifische Fachanwendungen (s. sektorspezifische Anwendungen in Abschn. 2.3.1) sowie Querschnittsanwendungen (s. sektorneutrale Anwendungen in Abschn. 2.3.1) und ihre Beziehungen abgebildet sind. Zusätzlich zur organisationsbezogenen Anwendungslandschaft sind hier im oberen Bereich auch die internen und externen Zugriffsmöglichkeiten auf diese Anwendungslandschaft dargestellt. Weitere Beispiele für generalisierte Anwendungslandschaften finden sich auch als branchenbezogene Referenzmodelle in Abschn. 10.3. Die systematische Planung und Gestaltung einer Anwendungslandschaft im Rahmen des Architekturmanagements ist eine eigene Aufgabe in Unternehmen. Sie soll den „Wildwuchs“ von Anwendungslandschaften (sog. Schatten-IT) vermeiden, der häufig auf die Partikularinteressen von Organisationseinheiten zurückzuführen ist. Dabei entscheiden sich diese Organisationseinheiten für Anwendungen, die zwar aus ihrer untergeordneten organisatorischen (Abteilungs-)Sicht die spezifischen fachlichen Anforderungen erfüllen, aus einer übergeordneten Perspektive (z. B. aus Unternehmenssicht) aber zu einer heterogenen und unabgestimmten Gesamtarchitektur führen. Das Idealbild stellen architektierte Anwendungslandschaften dar, in welchen die Anwendungen planvoll und in Abstimmung mit der Gesamtanwendungslandschaft zum Einsatz kommen (Winter 2011, S. 147). Diese versuchen in einzelnen Anwendungen bestimmte Teilaspekte wie die Unterstützung von Geschäftsprozessen (z. B. Artikelbestellung, Qualitätsprüfung, Risikomanagement) und die Bewirtschaftung von Informationsobjekten (z. B. Kunde, Produkt, Umsatz, Bestellung) zu bündeln und die dazugehörenden Anwendungsfunktionen (z. B. Autorisierung, Auftragsfreigabe, Ermittlung Bestandsreichweite) im Sinne der erwähnten Services zu kapseln.

9.2 Anwendungsarchitektur und Anwendungslandschaft Interne Nutzer

Native-Client

177 Externe Nutzer

Web-Client

Web-Client

Web-Client

Anwendung

Anwendungslandschaft Service-Gateway

Portal Domäne

Domäne Querschnittssystem

Fachanwendung

Fachanwendung

Querschnitt

Fachanwendungen

Fachanwendung (Interaktion)

Querschnittssystem

Querschnittssystem

Querschnittssystem

Querschnittssystem

Querschnittssystem

Querschnittssystem

Fachanwendung (Bestand)

Abb. 9.1  Generische Anwendungslandschaft (Bundesverwaltungsamt 2018)

Für eine hohe Wiederverwendung sollten die einzelnen Funktionen möglichst nur in einer Anwendung abgebildet sein. Wie in Teil 3 dargestellt, kann eine architektierte Anwendungslandschaft beispielsweise Transaktionssysteme (operative Anwendungen, s. Kap.  10) und Entscheidungsunterstützungssysteme (analytische Anwendungen, s. Kap. 11) unterscheiden. Für die digitale Transformation sind neben Ist-Architekturmodellen auch die Ziel-Architekturmodelle von Bedeutung. Letztere ermöglichen eine zielgerichtete Entwicklung der Gesamtarchitektur, was insbesondere bei der Umsetzung durchgängig digitaler Geschäftsprozesse notwendig ist. Grundsätzlich ist hier jedoch anzumerken, dass sich viele Gestaltungsansätze auf ein Unternehmen und weniger das ­Zusammenwirken mehrerer Unternehmen in einer Wertschöpfungskette bzw. einem Unternehmensnetzwerk beziehen. Für die digitale Transformation sind daher über Organisationsgrenzen hinaus gestaltete architektierte Anwendungslandschaften eine wichtige Voraussetzung, was große Unternehmen häufig in Form von Vorgaben gegenüber ihren Partnern durchsetzen. Demgegenüber besitzen auch dezentrale Ansätze (wie etwa Blockchain- bzw. Distributed-Ledger-Technologien (s. Abschn. 4.3.4)) das Potenzial zur Herstellung abgestimmter verteilter Instanzen, wobei sich diese aber noch in einem frühen Entwicklungsstadium befinden.

178

9 Informationssystemebene

Zur Unterstützung des Architekturmanagements sind im Laufe der Zeit eigene Modellierungswerkzeuge entstanden, die sich neben Ist- und Ziel-Visualisierungen der Anwendungslandschaft auf die Darstellung von weiteren IS-spezifischen Inhalten konzentrieren. Ein ­Beispiel bildet die gemeinsame Betrachtung von Anwendungslandschaft und Hardwareinfrastruktur im Rahmen von IT-Landschaften (Kirchner 2003). Gleichzeitig berücksichtigen diese Werkzeuge zunehmend auch andere (fachliche) Inhalte aus dem Unternehmenskontext (z. B. die Zuordnung von Anwendungen zu den sie benutzenden Organisationseinheiten), so dass man von Werkzeugen des Enterprise Architecture Management (EAM) zur Gestaltung und Modellierung von Unternehmensarchitekturen spricht. cc Unternehmensarchitektur  Die Unternehmensarchitektur (Enterprise Architecture) adressiert den ganzheitlichen Aufbau eines Unternehmens unter Berücksichtigung informationstechnologischer und betriebswirtschaftlicher Elemente. Dies umfasst neben den Elementen des Unternehmens selbst (z. B. Aufbau- und Ablauforganisation, Anwendungen, Infrastrukturelemente) auch flankierende Aspekte wie Strategien und Ziele, Anforderungen, Projekte, Richtlinien und Muster sowie Kennzahlen (Wittenburg 2007, S. 4). Werkzeuge des EAM (z. B. Iteraplan von Iteratec oder Rational System Architect von IBM) verwenden grafische Notationen zur Darstellung von Unternehmensarchitekturen, zu denen etwa das Information Systems Architecture Framework (Zachman 2008), ArchiMate und das The Open Group’s Architecture Framework (TOGAF) zählen. Diese zielen auf eine integrierte Unternehmensmodellierung unter Berücksichtigung mehrerer Sichten (s. Abb.  9.2). Neben den IS-spezifischen Elementen wie Anwendungen und Infrastrukturkomponenten (z.  B.  Datenbanksysteme und Applikationsserver) sind hier auch betriebswirtschaftliche Elemente enthalten. Damit ist es möglich, Inhalte auf mehreren Gestaltungsebenen (z. B. strategische Ziele, ausführende Prozesse und unterstützende IS)

Geschäfts-Service-Schicht Anwendungssystem- und InformationsSchicht Infrastruktur-Service-Schicht Infrastruktur-Schicht

Abb. 9.2  Inhaltliche Elemente von Unternehmensarchitekturen (Matthes 2015)

Kennzahlen & Metriken

Richtlinien & Muster

Anforderungen & Projekte

Strategien & Ziele

Geschäfts- und Organisations-Schicht

9.3 Gestaltung und Weiterentwicklung von Services

179

und ihre Beziehungen gemeinsam modellhaft darzustellen. Auch die Unified Modeling Language (UML) (s. Abschn. 9.4) lässt sich aufgrund der zahlreichen Modelltypen dazu verwenden.

9.3

Gestaltung und Weiterentwicklung von Services

Serviceorientierte Architekturen (SOA) haben als mehrschichtiges Architekturkonzept seit den 2000er- Jahren eine hohe Bedeutung erlangt (Erl 2008). Die dabei zum Einsatz kommenden Dienste bzw. Services sind nicht mit dem aus der Dienstleistungsforschung etablierten englischen Begriff des Service bzw. der Dienstleistung (s. Abschn.  4.2) zu verwechseln. Im Vordergrund einer serviceorientierten Gestaltung stehen vielmehr die ­Gestaltungsziele von IS-Architekturen (s. Abschn.  9.1) im Vordergrund, wie etwa eine erhöhte Flexibilität und Agilität. Diese beruhen auf der Modularisierung, da die Anwendungsfunktionalitäten nicht mehr in großen vordefinierten Anwendungsarchitekturen „fest verdrahtet“ bzw. hart gekoppelt sind, sondern sich bei Veränderungen von Geschäftsprozessen mit geringerem Aufwand neu zusammenstellen lassen. Services im Sinne einer SOA setzen sich aus einem fachlichen und einem technischen Teil zusammen und schlagen so die Brücke zwischen den auf der Organisationsebene angesiedelten Prozessen und den Anwendungen der IS-Ebene. So hat die Services selbst können als Software wie in Teil 4 beschrieben umgesetzt sein. So hat das Software Engineering mit der Objekt- und Komponentenorientierung (s. Abschn. 14.1) wichtige Ideen für das SOA-Konzept geliefert, für das drei Bestandteile charakteristisch sind (s. Abb. 9.3): • Services. Diese Module umfassen fachlich gekapselte Funktionen auf Basis technischer (Software-)Services. Durch semantisch und syntaktisch standardisierte Schnittstellen erlauben sie eine lose Kopplung (gegenüber einer als „hart“ bezeichneten festen Kodierung der Funktionen in einer Anwendung) mit anderen Services und sind aufgrund ihrer definierten Leistungsbeschreibung in mehreren fachlichen Anwendungsbereichen einsetzbar. Sowohl fachliche als auch technische Services können aus weiteren Services zusammengesetzt sein, woraus mächtige Servicecluster resultieren können. Gegenüber Anwendungen, die sich als Bündel von Services verstehen lassen, haben (Einzel-)Services eine feinere Granularität, was die Flexibilität bei der Rekomposition verbessert. Beispiele für Services zeigt Tab. 9.2. • Service Bus. Austausch und Nutzung von Services erfolgen über eine Integrationsplattform, welche die datentechnische Anbindung von Services und ihre wechselseitige Kommunikation über definierte Schnittstellen erlaubt. Ein Service Bus kann sowohl zur Verknüpfung unternehmensinterner Services (als sog. Enterprise Service Bus) als auch zur Verbindung organisationsübergreifend verfügbarer Services zum Einsatz kommen.

9 Informationssystemebene

180

Serviceverzeichnis

Serviceanbieter

Vertragliche Bindung / Service nutzen

Servicekonsument

Abb. 9.3  Akteure in einer SOA Tab. 9.2  Beispiele für Services (Winter 2011, S. 145) Servicetyp Prozessorientierte Services

Informationsorientierte Services

Funktionsorientierte Services

Beispiel Realtime-Bonitäts- bzw. Kundenwertermittlung während eines automatisierten Verkaufsprozesses. Diese ist für die Bestimmung individueller Preise und Konditionen notwendig und integriert Anwendungsfunktionen und Informationen für den Preisbildungsprozess. Mehrere Geschäftsprozesse greifen auf diesen Service zurück. Bereitstellung von Kunden- oder Produktstammdaten für mehrere Prozesse. Dadurch ist einerseits gewährleistet, dass die Prozesse einen konsistenten Datenbestand nutzen und andererseits, dass die Funktionalitäten zur Datenpflege nur an einem Ort zu realisieren bzw. weiterzuentwickeln sind. Berechnung und Bereitstellung eines aktuellen Kontostands, der sowohl in einer Desktop-Anwendung für Bank-Mitarbeiter als auch in Geldautomaten oder einer Web-Anwendung (E-Banking) für Kunden Anwendung findet.

• Serviceverzeichnis. Das Auffinden und Verwalten der häufig in hoher Zahl vorhandenen Services unterstützt ein zentrales Verzeichnis, das je nach Funktionsumfang auch Service Repository oder Registry heißt. Repositories enthalten die Services in katalogisierter Form mit ihren Servicebeschreibungen sowie die technischen Daten für die jeweiligen Serviceaufrufe. Registries dagegen enthalten einen Katalog mit Verweisen (Links) auf dezentral bereitgehaltene Services. cc Service (im Kontext Serviceorientierter Architekturen)  Ein Service ist eine abgeschlossene und plattformunabhängig einsetzbare Softwarekomponente zur Umsetzung einer fachlichen Funktionalität, die andere Anwendungen/Services über eine definierte Schnittstelle ansprechen und nutzen können. Der fachliche Teil eines Service beschreibt

9.3 Gestaltung und Weiterentwicklung von Services

181

dessen Einbettung in den fachlichen Anwendungskontext, z. B. welche fachliche Funktion/ Aufgabe der Service erfüllt oder welche Organisationseinheit(en) den Service erstellt, verantwortet und verwendet. Der technische Teil beinhaltet die zugrunde liegenden Anwendungsfunktionen und Datenstrukturen sowie die Beschreibung der technischen Schnittstellen. Das Zusammenwirken der drei Bausteine beginnt damit, dass ein Serviceanbieter seinen erstellten Service in einem Serviceverzeichnis veröffentlicht, wodurch Servicekonsumenten diesen Service auffinden können. Nach der vertraglichen Bindung zwischen Serviceanbieter und -konsumenten steht der Service zur Nutzung bereit. Aus technischer Sicht ist das SOA-Konzept mit Web-Service-Technologien verbunden, die drei Standards verwenden. Dies sind das SOAP-Protokoll zur Kommunikation zwischen den drei Bausteinen, die UDDI-Verzeichnisstruktur zur Realisierung von ­Serviceverzeichnissen und die WSDL sowie die USDL zur formalisierten Beschreibung von Services (Melzer 2010) (s. auch Glossar). Zur Entwicklung und zum Management von Services sind in der Vergangenheit zahlreiche Modellansätze entstanden. Hierbei ist zunächst bezüglich der initialen Serviceidentifikation zwischen Bottom-up-Ansätzen (Identifikation/Abgrenzung von Services auf Basis (zusammenhängender) technischer Softwarefunktionalitäten), Top-down-Ansätzen (Identifikation auf Basis fachlicher Aktivitäten/Aktivitätsbündel s. Abschn. 13.2) sowie gemischten (Hybrid-)Ansätzen zu unterscheiden. Die notwendigen Aufgaben für das Service (Lifecycle) Management können sich an Ansätzen wie etwa ITIL (s. Abschn. 4.2.1) orientieren und reichen von der Serviceidentifikation und -spezifikation über die Servicevereinbarung (Kauf/Verkauf) hin zur Serviceimplementierung und -lieferung sowie zum Servicemonitoring, dem Servicesupport und zur Serviceweiterentwicklung (Fischbach et al. 2013). Angesichts der Flexibilitätsanforderungen bezüglich der Nutzung weiterer Vertriebskanäle (z. B. mobiler Dienste), effizienter Produktentwicklungsprozesse im Sinne einer geringen „Time to Market“ und eines effizienten Betriebs sowie der Weiterentwicklung der Anwendungsarchitekturen haben Fragen der Serviceorientierung an Bedeutung gewonnen. Insbesondere große Unternehmen haben daher in den vergangenen Jahren SOA-­ Projekte durchgeführt. Dabei hat sich gezeigt, dass der Aufwand zur Erstellung und Pflege von Servicearchitekturen häufig erheblich ist und hohe Abstimmungsaufwände in und zwischen Unternehmen erzeugt. Dazu zählen etwa die Definition und Abgrenzung fachlicher Services im Rahmen von Brancheninitiativen, wie etwa BIAN (Banking Industry Architecture Network) im Bankenbereich (Alt und Puschmann 2016, S. 178 ff.). Zur Illustration eines solchen komplexen Abstimmungsprozesses zeigt Abb. 9.4 die akteursübergreifenden Aktivitäten im Rahmen der Serviceentwicklung eines Serviceanbieters und der nachfolgenden Qualitätsüberprüfung durch einen Servicemarktplatzbetreiber (zur Funktionsweise elektronischer Marktplätze s. Abschn. 5.2.1). Aus wissenschaftlicher Sicht hat sich die Disziplin der Service Science (Buhl et al. 2008) herausgebildet mit dem Ziel, ein die technische und fachliche Servicesicht integrierendes Verständnis herzustellen.

Entwicklerteam

Serviceanbieter - Entwicklerteam

Nutzeranforderungen sind bekannt

technischer Serviceentwurf

Service entwickeln

Serviceentwurf nachbessern / anpassen

Serviceanbieter - Servicemanagement Servicemetainformationen in MarktplatzRepository eintragen

ServiceMetadatenstruktur des Servicemarktplatzes

Mängel sichten

Serviceentwurf übermitteln Dokumentation des ServiceReviews

ServiceMetadaten

Servicemarktplatz

Qualitätsanforderungen des Servicemarktplatzes

Serviceentwurf begutachten

Mängelliste bereitstellen

Mängelliste

nein

Anforderungen erfüllt?

ja

Servicemanagement

Serviceanbieter

9 Informationssystemebene

Servicemarktplatz

Serviceentwicklung und Service-Review

182

Service auf Servicemarktplatz veröffentlichen

Service ist veröffentlicht

Abb. 9.4  Serviceentwicklung und marktplatzbezogener Service-Review-Prozess

9.4

Systemmodellierung mit der Unified Modeling Language (UML)

Die Unified Modeling Language (UML) (OMG 2017) ist eine der dominierenden Sprachen zur Modellierung von Softwaresystemen. Sie dient zur Modellierung, Dokumentation, Spezifizierung und Visualisierung komplexer Systeme unabhängig von deren Fachund Realisierungsgebiet. Sie liefert die Notationselemente für die statischen und dynamischen Modelle dieser Modellfamilie (s. Abb.  9.5), die schwerpunktmäßig beim IS-Entwurf und bei der IS-Analyse, aber auch bei der Gestaltung von Abläufen/Prozessen und anderen Systemaspekten (z.  B.  Darstellung von Anwendungsfällen) zum Einsatz kommen. Die statischen Modelle oder auch Strukturdiagramme beschreiben die strukturelle Sicht auf ein System. Die dynamischen Modelle oder auch Verhaltensdiagramme legen den Schwerpunkt auf das Verhalten eines Systems (Booch et al. 1999). UML umfasst viele Notationselemente. Wie für eine Sprache üblich legt UML fest, welche Elemente zu nutzen und nach welchen Regeln wohldefinierte Modelle zu bilden sind. UML legt jedoch nicht fest, welche Diagramme wann für welche Aktivität (z. B. im Rahmen eines Softwareentwicklungsprojekts) zu Anwendung kommen sollen. Bei der praktischen Modellierung ist daher festzulegen, welches Diagramm in welcher Projektphase für welche

9.4 Systemmodellierung mit der Unified Modeling Language (UML)

183

Diagramme in UML 2.5

Verhaltensdiagramme

Strukturdiagramme

Klassendiagramm

Objektdiagramm

Komponentendiagramm

Verteilungsdiagramm

Kompositionsstrukturdiagramm

Paketdiagramm

Profildiagramm

Aktivitätsdiagramm

Use-CaseDiagramm

Zustandsautomat

Interaktionsdiagramme

Sequenzdiagramm

Interaktionsübersichtsdiagramm

Kommunikationsdiagramm

Timingdiagramm

Abb. 9.5  Diagrammtypen in UML 2.5

Aufgabe zum Einsatz kommt. Der folgende Abschnitt erläutert dazu die unterschiedlichen Diagrammtypen sowie ihre Aufgaben und Stärken (Jeckle et al. 2004; Booch et al. 1999; Larman 1998). • Klassendiagramme (s. Abb. 9.6) bilden den Kern der meisten objektorientierten Entwicklungen. Sie beschreiben die statische Struktur des zu entwickelnden Softwaresystems. Klassen- und Anwendungsfalldiagramme (auch Use-Case-Diagramme genannt) sind Ausgangspunkte für die Festlegung des Systemverhaltens in den dynamischen Modellen. Die Klassendiagramme enthalten alle relevanten Strukturen, Datentypen sowie deren Abhängigkeiten (s. auch Abschn. 14.3.2 und 14.4.1). In Abb. 9.6 sind zunächst die beiden Klassen „Uhrenmodell“ und „Einzelkomponente“ mit ihren jeweiligen Attributen (z. B. „Grundpreis“) und Operationen (z.  B. „ErmittleVerkaufteStückzahl“) abgebildet. Zwischen den beiden Klassen existiert eine „Besteht aus“-Beziehung, zu der auch die Kardinalitäten (Angabe über die Anzahl der an einer Beziehung beteiligten Objekte, s. auch Abschn. 9.5) vermerkt sind. In diesem Beispiel besteht ein Uhrenmodell aus mindestens drei Einzelkomponenten, wobei eine Einzelkomponente keinem oder einer unbegrenzten Anzahl von Uhrenmodellen zugeordnet sein kann. Weiterhin ist die Klasse „Uhrenmodell“ eine Generalisierung zu den beiden spezifischeren Klassen „Kinderuhr“ und „Sportuhr“, die jeweils noch ein eigenes zusätzliches Attribut besitzen.

184

9 Informationssystemebene

Klassendiagramm Uhrenmodell

Einzelkomponente Besteht aus

- Grundpreis - Verkaufsstart

0..*

+ ErmittleVerkaufteStückzahl() + ErmittleAnzahlReklamationen()

Kinderuhr - Kindermotiv im Hintergrund

3..*

- Lieferant - Güteklasse + ZuVerkaufssortimentHinzufügen()

Sportuhr - Wasserdichtigkeitsklasse

Objektdiagramm Gerano:Uhrenmodell

Paketdiagramm Package Preisberechnung

- Grundpreis = „69,99“ - Verkaufsstart = „15.02.2018“

Besteht aus

ArmbandA15:Einzelkomponente - Lieferant = „Musterfrau GmbH“ - Güteklasse = „2A“

Besteht aus

UhrenmodellPreisberechnung

KomponentenStammdatenverwaltung

UhrwerkLB7:Einzelkomponente - Lieferant = „Mustermann GmbH“ - Güteklasse = „1“

Besteht aus

Gehäuse7BA:Einzelkomponente - Lieferant = „Musterkind GmbH“ - Güteklasse = „2C“

Abb. 9.6  Klassen-, Objekt- und Paketdiagrammen im Uhren-Beispiel

• Objektdiagramme (s. Abb. 9.6) zeigen den inneren Aufbau eines Systems. Sie stellen die einzelnen Objekte und deren Wertebelegung zu einem bestimmten Zeitpunkt dar. Dieser Diagrammtyp kann beispielhaft zur Visualisierung der Mengenverhältnisse dienen. Objektdiagramme und Klassendiagramme besitzen den gleichen Detaillierungsgrad. In Abb. 9.6 basiert das gezeigte Objektdiagramm auf den im Klassendiagramm spezifizierten Inhalten. Hierbei besteht das beispielhafte Uhrenmodell „Gerano“ aus drei spezifischen Einzelkomponenten („ArmbandA15“, „UhrwerkLB7“ und „Gehäuse7BA“), zu denen die jeweiligen „Lieferanten“ und „Güteklassen“ vermerkt sind. • Paketdiagramme (s. Abb. 9.6) eignen sich dazu, ein System in größere Einheiten zu organisieren und Teile des Modells zusammenzufassen. Die zentrale Frage ist, wie man das Gesamtmodell in kleinere Teile zerlegen und gleichzeitig den Überblick behalten kann. In Abb. 9.6 besteht das Paket „Preisberechnung“ aus zwei Unterpaketen, wobei das erste Unterpaket „Uhrenmodell-Preisberechnung“ auf alle frei verfügbaren und öffentlichen Elemente des zweiten Unterpakets „Komponenten-­Stammdatenverwaltung“ zugreifen darf.

9.4 Systemmodellierung mit der Unified Modeling Language (UML)

185

• Sequenzdiagramme (s. Abb. 9.7) stellen detailliert den nacheinander erfolgenden Informations- und Nachrichtenaustausch zwischen mehreren Objekten dar. Hierbei ist der zeitliche Ablauf durch die vertikal von den Objekten nach unten verlaufenden und gestrichelt dargestellten Lebenslinien angedeutet, d.  h. die Nachrichtenübermittlungen erfolgen in der von oben nach unten spezifizierten Reihenfolge (s. auch Abschn. 14.4.1). In Abb. 9.7 geht im Sequenzdiagramm „Prototypentwicklung“ die erste Nachrichtenkommunikation vom „Uhrenmodell-Konfigurator“ aus. Die Nachricht „ErstellePrototypen“ an den „Uhrmacher“ ist als synchrone Kommunikation gekennzeichnet, d. h. der „Uhrenmodell-Konfigurator“ wartet als Sender der Nachricht auf das „Prüfprotokoll“ als Rückantwort und pausiert bis zu deren Eintreffen mit seiner weiteren Verarbeitung (s. Balken auf der Lebenslinie). Gleiches gilt für die sich anschließende Nachricht „PrüfePrototypen“ vom „Uhrmacher“ zum „Qualitätsverantwortlichen“ und der dazugehörigen Rückantwort. • Kommunikationsdiagramme (s. Abb. 9.7) dienen wie Sequenzdiagramme dazu, das Zusammenspiel und die Kommunikation der Objekte bei der Problemlösung zu spezifizieren. Semantisch sind Sequenzdiagramme und Kommunikationsdiagramme äquivalent. UML stellt bewusst äquivalente Diagramme zur Modellierung zur Verfügung, da die Darstellung des dynamischen Verhaltens schwierig ist und es manchmal hilfreich sein kann, ein komplexes Problem aus unterschiedlichen Blickwinkeln zu betrachten (Booch et al. 1999). So beziehen sich die in Abb. 9.7 im Kommunikationsdiagramm „Prototypenprüfung“ dargestellten Nachrichtenbeziehungen zwischen dem „Uhrmacher“ und dem „Qualitätsverantwortlichen“ auf die bereits im Sequenzdiagramm dargestellten Inhalte. Hierbei zeigt die ungerichtete Kante zwischen den beiden Objekten das Bestehen einer Kommunikationsbeziehung an. Die Nachrichten sind als zusätzliche gerichtete Kanten unter Angabe der Reihenfolgebeziehung abgebildet. • Timingdiagramme (s. Abb. 9.7) veranschaulichen die durch Nachrichten ausgelösten Zustandsänderungen von Objekten, Klassen oder Schnittstellen im Zeitverlauf. Sie sind wichtig, wenn exakte Zeitpunkte für Ereignisse festzulegen sind. Im Timingdiagramm „Prototypenprüfung“ (s. Abb. 9.7) befindet sich der „Qualitätsverantwortliche“ im initialen Zustand „Warten“ und der „Uhrmacher“ im initialen Zustand „Bauen“. Die nachfolgend vom „Uhrmacher“ ausgehende Nachrichtenübermittlung „Prototypen prüfen“ verändert seinen Zustand in „Warten“ und versetzt den „Qualitätsverantwortlichen“ in den Zustand „Prüfen“. Spätestens nach zwei Tagen soll der „Qualitätsverantwortliche“ sein „Prüfprotokoll“ an den „Uhrmacher“ versenden, wobei letzterer im Anschluss die Prüfergebnisse analysiert und sich damit im Zustand „Auswerten“ befindet. • Anwendungsfalldiagramme (s. Abb. 9.8) (auch Use-Case-Diagramme genannt) stellen aus Anwendersicht die Verknüpfungen zwischen den Akteuren und den Anwendungsfällen eines Systems dar. Weiterhin sind hiermit die Beziehungen zwischen Anwendungsfällen (z. B. Erweiterungen oder Aggregationen) abbildbar. Es handelt sich um ein relativ einfaches aber mächtiges Modellierungswerkzeug, das insbesondere für die Diskussion mit den Anwendern geeignet ist. Die Anwendungsfalldiagramme stellen die Außensicht auf das System dar. Das Anwendungsfalldiagramm in Abb. 9.8 zeigt beispielsweise, dass der „Uhrenmodell-Konfigurator“ am Anwendungsfall „Entwurf

9 Informationssystemebene

186

Sequenzdiagramm sd Prototypentwicklung Uhrenmodell-Konfigurator :Qualitätsverantwortlicher

:Uhrmacher ErstellePrototypen() PrüfePrototypen() Prüfprotokoll

Prüfprotokoll

Kommunikationsdiagramm

Qualitätsverantwortlicher

:Uhrmacher

Prüfen

Warten

2: Prüfprotokoll

:Qualitätsverantwortlicher

Uhrmacher

1: Prüfe_Prototypen()

Timingdiagramm sd Prototypenprüfung

interaction Prototypenprüfung

Bauen

2 Tage

Prüfprotokoll Prototypen prüfen

Warten Auswerten

Abb. 9.7  Darstellung von Sequenz-, Kommunikations- und Timingdiagramm im Uhren-Beispiel

eines Uhren-Basismodells“ beteiligt ist, wobei dieser Anwendungsfall eine Aggregation aus den beiden Anwendungsfällen „Entwurf einer Kinderuhr“ und „Entwurf einer Sportuhr“ darstellt. • Aktivitätsdiagramme (s. Abb. 9.8) helfen dabei, Prozesse und Aktivitätsfolgen detailliert mit Start- und Endereignissen, Bedingungen, aufbauorganisatorischen Zuordnungen, Schleifen und Verzweigungen zu beschreiben (s. auch Abschn.  14.3.2). Aktivitätsdiagramme sind auch zur Darstellung von Datenflüssen einsetzbar. Das Aktivitätsdiagramm in Abb. 9.8 orientiert sich an den in Abb. 8.10 gezeigten Inhalten und zeigt die Aktivitätsfolge von der Idee eines neuen Uhrenmodells bis zur Herstellung eines Uhrenmodell-Prototypen. Hierbei ist wie in der Prozessmodellierungsnotation BPMN (s. Abschn. 8.3.3) die aufbauorganisatorische Zuordnung der einzelnen Aktivitäten mit Hilfe von Swimlanes abgebildet. Abhängig davon, ob es sich bei dem neuen Uhrenmodell um eine Kinder-

9.4 Systemmodellierung mit der Unified Modeling Language (UML)

187

Anwendungsfalldiagramm Entwurf einer Sportuhr

Entwurf einer Kinderuhr

Herstellung eines Uhrenprototyps

Entwurf eines Uhren-Basismodells

Technische Prüfung des Uhrenprototyps

Vorstellung des Uhrenmodells

UhrenmodellKonfigurator

Uhrmacher

Qualitätsverantwortlicher

Uhrmacher

Konfigurator Sportuhren

Konfigurator Kinderuhren

Teamleiter Konfiguration

Aktivitätsdiagramm Neues Uhrenmodell entwerfen Kundenzielgruppe bestimmen

Sportler als Kundenzielgruppe bestimmt

Kindermotiv auswählen

Sportfunktionen auswählen

Kinder als Kundenzielgruppe bestimmt Kindermotiv ausgewählt

Sportfunktionen ausgewählt

KinderUhrenkomponenten auswählen

SportUhrenkomponenten auswählen

KinderUhrenbasismodell entworfen

SportUhrenbasismodell entworfen

Prototyp hergestellt Uhren-Prototyp herstellen

Abb. 9.8  Darstellung von Anwendungsfall- und Aktivitätsdiagramm im Uhren-Beispiel

uhr oder eine Sportuhr handelt, sind voneinander abweichende Aktivitäten im Rahmen der Erstellung des Uhrenentwurfs vom zuständigen Konfigurator zu durchlaufen, bevor der „Uhrmacher“ im Anschluss einen Uhrenmodell-­Prototypen erstellen kann. • Interaktionsübersichtsdiagramme (s. Abb. 9.9) stellen Interaktionen in ihrer sachlogischen und damit auch zeitlichen Reihenfolge dar. Hierbei kommen innerhalb der Modelle Sequenzdiagramme zur Darstellung einzelner Interaktionen sowie Referenzen auf an anderer Stelle bereits modellierte Interaktionen (Bezeichner „ref“) zur Anwendung. Gleichzeitig ermöglichen aus dem UML-Aktivitätsdiagramm stammende Modellelemente die Darstellung der sachlogischen Abfolge der Interaktionen mit

188

9 Informationssystemebene

Interaktionsübersichtsdiagramm sd Uhrenkauf Anzeige Uhrenmodelle

ref Suche u. Konfiguration Uhrenmodelle

ref

sd Preisübermittlung

ref

Anzeige Preisvergleich

ref Auswahl Uhrenmodell für Kauf

ref Auswahl gespeicherter Uhrenmodelle

:Preisberechnungsfunktion

:Onlineshop

Berechne_Uhrenkonfigurationen() Preisberechnung

Komponentendiagramm Uhrenkonfiguration empfangen

Preisberechnung übermitteln

UhrenmodellPreisberechnungsfunktion Beschaffungspreise der Komponenten übermitteln

Verteilungsdiagramm

Onlineshop: Server



ERP_Backend:Server Komponentenstammdatenverwaltung



preislistenimport_ uhrenkomponenten.csv

preisberechnung.jar

Komponentenstammdatenverwaltung

Abb. 9.9  Interaktionsübersichts-, Komponenten- und Verteilungsdiagramm im Uhren-Beispiel

Berücksichtigung von Start- und Endereignissen sowie Verzweigungen. Das Interaktionsübersichtsdiagramm „Uhrenkauf“ (s. Abb. 9.9) illustriert die Interaktionen von der „Anzeige der Uhrenmodelle“ bis zur „Auswahl Uhrenmodell für Kauf“. Hierbei zeigt die mit Hilfe eines Sequenzdiagramms dargestellte Interaktion „Preisübermittlung“ im Detail den Nachrichtenaustausch zwischen dem „Onlineshop“ und der „Preisberechnungsfunktion“, während andere Interaktionen auf bestehende Modelle verweisen (z. B. „Suche und Konfiguration Uhrenmodelle“). • Komponentendiagramme (s. Abb. 9.9) stellen Komponenten als wiederverwendbare und austauschbare modulare Einheiten eines Softwaresystems (z. B. eines fachlichen Service) sowie die zwischen ihnen bestehenden Abhängigkeiten und Schnittstellen dar. In Abb. 9.9 ist die Komponente „Uhrenmodell-Preisberechnungsfunktion“ zunächst über zwei

9.4 Systemmodellierung mit der Unified Modeling Language (UML)

189

Schnittstellen mit ihrer Umwelt zum „Empfangen von Uhrenkonfigurationen“ und zur „Übermittlung von Preisberechnungen“ verbunden. Eine weitere Schnittstelle zur ­„Komponentenstammdatenverwaltung“ liefert die für die Preisberechnung von Uhrenmodellen notwendigen „Beschaffungspreise der Komponenten“. • Verteilungsdiagramme (s. Abb.  9.9) zeigen die technische bzw. physische IS-Umgebung (z. B. Hardware, Server, Datenbanken) sowie die Zuordnung von Software- zu Hardwarekomponenten. In Abb. 9.9 sind im Verteilungsdiagramm die zwei Serverkomponenten „Onlineshop“ und „ERP_Backend“ über eine „Ethernet“-Verbindung verknüpft. Zudem betreibt der „ERP-Backend“-Server die Softwarefunktion „Komponentenstammdatenverwaltung“ und nutzt in diesem Zusammenhang die beiden Artefakte „preisberechnung.jar“ und „preislistenimport_uhrenkomponenten.csv“. • Zustandsautomaten (s. Abb. 9.10) zeigen, welche Abfolge von Zuständen ein Objekt bei einer Anzahl von nacheinander auftretenden Ereignissen bzw. ausgeführten Aktivitäten einnehmen kann. Sie ermöglichen eine exakte Abbildung von Zustandsmodellen mit Zuständen, Ereignissen, Anfangs- und Endzuständen sowie Nebenläufigkeiten

UhrenOnlineshop

UhrenKunde

Zustandsautomat Uhrenwunsch UhrenOnlineshop im Browser öffnen Uhren-Onlineshop ist geöffnet

Uhrenmodelle und Varianten sind angezeigt

UhrenBasismodell suchen

Uhren-Basismodell ist ausgewählt UhrenBasismodell konfigurieren

Uhrenangebote anzeigen

Uhren-Basismodell ist konfiguriert

Konfiguriertes Uhrenmodell bepreisen

Konfiguriertes Uhrenmodell mit Preisangabe

Profildiagramm

Uhrenprofil



Uhrenklasse

Class

Bezeichner:String

Sportuhr Sportfunktion:String

UML

Kinderuhr Kindermotiv:String

Abb. 9.10  Zustandsautomat und Profildiagramm im Uhren-Beispiel

190

9 Informationssystemebene

und Bedingungen, und bilden damit das zustandsorientierte Gegenstück zu den in Abb. 9.8 gezeigten Aktivitätsdiagrammen. In Abb. 9.10 sind die Zustandsabfolgen von einem „Uhrenwunsch“ des „Uhren-Kunden“ bis hin zu einem „konfigurierten Uhrenmodell mit Preisangabe“ innerhalb des „Uhren-Onlineshops“ abgebildet. Dabei sind die Zustände unter Verwendung der Swimlane-Darstellung immer denjenigen organisatorischen Einheiten zugeordnet, die (z. B. mit Hilfe einer Aktivität) zur Veränderung dieses Zustands in der Lage sind (z.  B. der „Uhren-Kunde“ verändert durch seine Aktivität „Uhren-Basismodell suchen“ den Zustand von „Uhrenmodelle und Varianten sind angezeigt“ hin zu „Uhren-Basismodell ist ausgewählt“). • Profildiagramme (s. Abb. 9.10) dienen der benutzerorientierten Anpassung und Erweiterung der UML-Metamodellebene durch die Definition von sog. Profilen, in denen ausgewählte Notationselemente des Klassendiagramms (wie z.  B.  Stereotypen) zum Einsatz kommen. Das in Abb. 9.10 gezeigte „Uhrenprofil“ erweitert das Metamodell von UML, indem es die „Uhrenklasse“ als neue aggregierte Klasse mit den Unterklassen „Sportuhr“ und „Kinderuhr“ einführt.

9.5

Datenmodellierung mit der Entity-Relationship-Notation (ER)

Bei der Vorstellung der zu UML gehörenden Modellarten (s. Abschn.  9.4) fällt auf, dass diese Modellfamilie keinen auf die grafische Datenmodellierung fokussierten Modelltyp enthält. Für diesen Anwendungszweck kommt in der Praxis häufig das vor UML entstandene, und seitdem kontinuierlich weiterentwickelte Entity-­Relationship-­Modell (ER-Modell) zum Einsatz. Die ER-Notation (Chen 1976) dient einerseits zur konzeptionellen Abstimmung zwischen Softwareentwickler und -anwender bezüglich der in einer Anwendung benötigten und zu berücksichtigenden Informationseinheiten und deren gegenseitigen Beziehungen. Andererseits lassen sich die Modelle in der späteren Implementierungsphase als Vorlage für die Strukturierung von (relationalen) Datenbanken verwenden. In ER-Diagrammen sind Datenobjekte als sog. Entitäten sowie die zwischen ihnen bestehenden Beziehungen abgebildet. Unter einem Datenobjekt ist hier ein individuell identifizierbares Objekt der realen Welt zu verstehen. ER-­Diagramme enthalten fünf Elementtypen (Winter 2011, S. 127 f.): • Entitiätstypen. Ein Entitätstyp fasst gleichartige Datenobjekte zusammen und ist in Form eines beschrifteten Rechtecks dargestellt. Obwohl für die Benennung von Entitäten keine strikten Vorgaben existieren, sollte als Name ein Substantiv im Singular Anwendung finden. So können im Uhren-Beispiel der Entitätstyp „Uhrenmodell“ alle angebotenen Uhrenmodelle und der Entitätstyp „Uhren-Kunde“ alle Kunden abbilden (s. Abb. 9.11). • Attribute. Die Entitäten eines Entitätstyps lassen sich mit einer Menge von Attributen beschreiben, z. B. alle „Uhren-Kunden“ mit einer „Kundennummer“ sowie einem „Vornamen“ und „Nachnamen“ (s. Abb. 9.11). Jedes Attribut besitzt dabei eine Bezeichnung,

9.5 Datenmodellierung mit der Entity-Relationship-Notation (ER)

191

Uhrengutschein (0,n) Kundennummer

Erhält (1,1)

Vorname

Uhren-Kunde

Nachname

Gehäuse

Armband

(0,n) Kindermotiv im Hintergrund

Verzierung

(0,n)

Kinderuhr

Grundpreis

Uhrenmodell Sportuhr

(0,1)

(0,n)

Einzel-Komponente (3,n)

(0,n)

Besteht aus

Beinhaltet

(1,1) SIM-Karte

Uhrwerk

Bestellnummer

Uhrenkauf

Ist gekoppeltan

(1,1)

Mobilfunknummer

Abb. 9.11  ER-Diagramm des Uhren-Beispiels

einen Datentyp (z. B. ganze Zahlen, Zeichenkette) und gegebenenfalls einen bestimmten Wertebereich. Attribute sind in ER-Modellen nach der klassischen Notation durch eine beschriftete Ellipse gekennzeichnet, die mit dem jeweiligen Entitätstyp über eine ungerichtete Kante verbunden sind. Bei neueren Darstellungen sind die Attribute meist in dem Rechteck aufgeführt, das den jeweiligen Entitätstyp repräsentiert. Identifikationsschlüssel (oder Primärschlüssel) sind besondere Attribute oder Attributkombinationen, mit deren Hilfe ein einzelnes Datenobjekt des Entitätstyps eindeutig zu identifizieren ist, z. B. die „Kundennummer“ eines „Uhren-Kunden“. • Beziehungen. Datenobjekte/Entitätstypen sind in der Regel nicht isoliert zu betrachten, sondern stehen mit anderen Entitätstypen in Beziehung. Beziehungen sind als Beziehungstyp (Relationship-Typ) zu modellieren und verbinden zwei oder mehr Entitätstypen. Da im Uhren-Beispiel ein „Uhrenmodell“ aus mehreren „Einzel-Komponenten“ (z. B. Gehäuse, Armband) besteht, ist zwischen diesen beiden Entitätstypen eine „Besteht aus“-Beziehung einzufügen (s. Abb. 9.11). Weiterhin ist die Beziehung zwischen den Entitätstypen „Uhren-Kunde“ und „Uhrenmodell“ über den „Uhrenkauf“ herzustellen. In der ursprünglichen ER-Modellierungsnotation von Chen sind Beziehungstypen als Rauten abgebildet, die über ungerichtete Kanten mit den Entitätstypen verbunden sind. Neuere Varianten der ER-Modellierung bilden Beziehungstypen ohne

192

9 Informationssystemebene

eigene ­Attribute als Beschriftung an den ungerichteten Kanten, und mit eigenen Attributen (z. B. das Attribut „Bestellnummer“ zum Beziehungstyp „Uhrenkauf“) analog zu den Entitätstypen ab. Zur Benennung eines Beziehungstyps sollten möglichst Partizipien oder Verben Anwendung finden, z. B. die bereits genannte Beziehung „Besteht aus“ als Name des Beziehungstyps zwischen „Uhrenmodell“ und „Einzel-­ Komponenten“. • Generalisierungen. Eine Generalisierungsbeziehung ist dann zu verwenden, wenn sich mehrere zunächst voneinander unabhängige Entitätstypen unter einem generelleren Entitätstyp zusammenfassen lassen, z. B. „Einzel-Komponenten“ als genereller Entitätstyp zu den Einzelentitätstypen „Gehäuse“, „Armband“ und „Uhrwerk“ (s. Abb. 9.11). Bei Generalisierungen vererben die generellen Entitätstypen ihre Attribute an die verbundenen Einzelentitätstypen (z. B. das Attribut „Grundpreis“ des „Uhrenmodells“ gilt ebenfalls für die verbundenen Einzelentitätstypen „Sportuhr“ und „Kinderuhr“), wobei die Einzelentitätstypen jeweils noch zusätzliche individuelle Attribute besitzen können (z. B. ist der Einzelentitätstyp „Kinderuhr“ mit dem zusätzlichen Attribut „Kindermotiv im Hintergrund“ versehen). Im ER-Modell dienen Dreiecke zur Darstellung von Generalisierungsbeziehungen, die über ungerichtete Kanten mit den Einzelentitätstypen und dem generellen Entitätstyp verbunden sind. • Kardinalitäten. Zur vollständigen Modellierung eines Beziehungstyps ist anzugeben, wie viele Datenobjekte der beteiligten Entitätstypen an Beziehungen dieses Typs teilnehmen können (Kardinalität), z. B. 1:1-, 1:n- und m:n-Beziehungen. So ist nach dem Beispiel in Abb. 9.11 ein „Uhrengutschein“ immer an genau einen „Uhren-Kunden“ gebunden, aber ein „Uhren-Kunde“ kann eine unbegrenzte Anzahl an „Uhrengutscheinen“ besitzen/einlösen (1:n-Beziehungstyp). Eine m:n-Beziehung liegt beispielsweise vor, wenn ein „Uhren-Kunde“ mehrere „Uhrenmodelle“ kaufen kann und gleichzeitig ein „Uhrenmodell“ von mehreren „Uhren-Kunden“ erworben werden kann. Eher selten sind 1:1-Beziehungstypen, z. B. wenn eine in der Uhr integrierte „SIM-Karte“ an genau eine „Mobilfunknummer“ gekoppelt ist, und umgekehrt eine „Mobilfunknummer“ genau zu einer „SIM-Karte“ gehört. In der x:y-Darstellung von Kardinalitäten stehen die jeweiligen Zahlen für die maximale Anzahl der an einer Beziehung beteiligten Entitäten. Um Kardinalitäten vollständig zu beschreiben ist es notwendig, auch die minimal vorkommende Anzahl der Entitäten in einer Beziehung anzugeben. Dazu dient die Anwendung der sog. (Min-Max)-Notation für Kardinalitäten, die für eine Beziehung auf jeder Seite des Doppelpunkts jeweils in Klammern die minimale und maximale Anzahl der jeweiligen Entitäten angibt (Winter 2011, S. 129 f.): • (0,1). Die Entitäten des betreffenden Entitätstyps können (müssen aber nicht) an maximal einer Beziehung teilnehmen. • (0,n). Die Entitäten des betreffenden Entitätstyps können (müssen aber nicht) an einer oder mehreren Beziehungen teilnehmen.

9.5 Datenmodellierung mit der Entity-Relationship-Notation (ER)

193

• (1,1).  Die Entitäten des betreffenden Entitätstyps müssen an genau einer Beziehung teilnehmen (klassische Existenzabhängigkeit). • (1,n). Die Entitäten des betreffenden Entitätstyps müssen an einer oder mehreren Beziehungen teilnehmen. Beispielsweise ist davon auszugehen, dass ein „Uhrenmodell“ entweder gar keine oder höchstens eine „SIM-Karte“ beinhaltet ((0,1)-Kardinalität). Ein „Uhrengutschein“ wiederum muss genau einem „Uhren-Kunden“ zugeordnet sein ((1,1)-Kardinalität), und ein „Uhrenmodell“ kann minimal aus drei (Uhrwerk, Armband, Gehäuse) oder (theoretisch) aus einer unbegrenzten Menge an „Einzel-Komponenten“ (z. B. zusätzliche Verzierungen) bestehen ((3,n)-Kardinalität). Abb. 9.11 zeigt ein ER-Schema zum Uhren-Beispiel in der Notation von Chen (1976).

Teil III Betriebliche Anwendungen

Anwendungen in ERP-Systemen

10

Zusammenfassung

Dieses Kapitel erläutert, wie Anwendungen in ERP-Systemen Unternehmensprozesse unterstützen und automatisieren können. Es werden sowohl sektorneutrale als auch sektorspezifische Anwendungen vorgestellt. Abschließend wird darauf eingegangen, wie ERP-Systeme als Standardsoftwareprodukte in Unternehmen einzuführen sind.

10.1 Überblick Wie in Teil 2 dargestellt, sind bei der Entwicklung betrieblicher Anwendungen (bzw. Anwendungssoftware) die in einem betrieblichen Teilgebiet relevanten Informationen zu identifizieren und in Informationsmodellen zu beschreiben. Dabei müssen die Anforderungen bezüglich der Qualität der betriebswirtschaftlichen Problemlösung erfüllt werden und die Kosten beachtet werden. Bei integrierten Anwendungen wie Enterprise Resource Planning (ERP)-Systemen (zur Einordnung von ERP-Systemen als Systems of Record s. Abschn. 2.3.2) sind Referenzmodelle gebräuchlich, die auch einen Forschungsgegenstand der Wirtschaftsinformatik bilden (Becker und Schütte 2004, S.  76  ff.; Schütte 1998, S. 69 ff. und vom Brocke 2003, S. 31 ff.). Zum Modellbegriff s. Abschn. 1.5. cc Referenzmodell  Ein Referenzmodell ist ein Informationsmodell, dessen Inhalt bei der Entwicklung von Anwendungsmodellen wiederverwendet werden kann (in Anlehnung an (vom Brocke 2003, S. 34)). Referenzmodelle werden zumeist auf fachkonzeptioneller Ebene und mit semi-­formalen Darstellungstechniken erstellt. Sie beinhalten Modelle zur Beschreibung von Eigenschaftsstrukturen (z.  B.  Entity-Relationship-Modelle, ERM) und Verhaltensstrukturen

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_10

197

198

10  Anwendungen in ERP-Systemen

(z. B. BPMN-Modelle) des ausgewählten betrieblichen Teilgebiets. Eine detaillierte Darstellung der Instrumente findet sich in Abschn. 9.5 (ERD) und Abschn. 8.3 (BPMN). Eine Übersicht zu Unterscheidungsmerkmalen von Referenzmodellen gibt Abb. 10.1. Während sich einige Referenzmodelle in der Wirtschaftsinformatik und Unternehmenspraxis weitgehend etabliert haben, erfüllen andere Vorschläge diese Anforderungen nur teilweise oder gar nicht. Beispiele für etablierte Modelle sind das Y-CIM (Scheer 1990, S.  2), das Handels-H (Becker und Schütte 2004, S.  42  ff.), das Supply-ChainOperations-­Reference (SCOR, s. Abschn. 12.2.2)-Modell (Supply Chain Council 2012) sowie die enhanced Telecom Operations Map (eTOM) (Czarnecki 2013, S. 56). Einige allgemeine Aussagen zur Gestaltung von Referenzmodellen sollen einen Einblick in konzeptionelle Überlegungen bieten. Grundlage hierfür bildet das Vorgehensmodell zur Entwicklung und Anwendung von Referenzmodellen (Schlagheck 2000, S. 78) (s. Abb.  10.2). Ausgangspunkt der Referenzmodellentwicklung bildet die Problemdefinition, mit der der Modellierungsbereich und die Ziele der Referenzmodellkonstruktion fixiert sind. Anschließend wird durch Analyse der Problemdomäne Wissen über den Modellierungsbereich aufgebaut und ein Modellrahmen definiert. In der folgenden Phase findet die Kons­ truktion der strukturellen und dynamischen Aspekte des Modells statt. Durch die Evaluation wird sichergestellt, dass die konstruierten Modelle konsistent sind und den Anforderungen der Anwender genügen. Defizite oder Anforderungsänderungen führen dazu, dass der Entwicklungsprozess erneut ausgeführt wird. Mit dem Entwicklungsprozess ist der Anwendungsprozess von Referenzmodellen verknüpft, der durch die Problemdefinition des Anwenders angestoßen wird und zu definierten Anforderungen führt. In der folgenden Phase erfolgt die Suche und Selektion geeigneter Referenzmodelle, die anschließend zur Konstruktion eines spezifischen Modells für das Anwenderproblem führen. Ausprägung

Merkmal

Aspekt

modellbezogen

aspektspezifisch Eigenschaftsmodell

Verhaltensmodell

aspektübergreifend

erweitertes Modell

Formalität

unformal

semi-formal

formal

Fachbezug

Fachkonzept

DV-Konzept

Implementierung

Zielperspektive Sektor Aufgabe methoden- Anforderungsbezogen erfüllung technologieRepräsenbezogen tation organisatiVerfügbarkeit onsbezogen

Anwendungssystemmodell

Organisationssystemmodell Industrie

Handel

öffentliche Verwaltung

Unterstützungsbereich

Beratung

Zweckbereich

...

Lenkungsbereich

referenzmodellunspezifisch

referenzmodellspezifisch

Printmedien

computergestützte Medien

unveröffentlicht

veröffentlicht

Abb. 10.1  Typologie von Referenzmodellen (vom Brocke 2003, S. 98)

10.1 Überblick

199 Problemdefinition

Konstruktion

Anforderungsermittlung

Problemdomäne analysieren

Problemdefinition

Evaluation und Evolution

Referenzmodellentwicklung

spezifisches Modell

Konstruktion, bzw. Anwendung

Suche und Selektion

Anwendung von Referenzmodellen

Abb. 10.2  Vorgehensmodell zur Entwicklung und Anwendung von Referenzmodellen (Schlagheck 2000, S. 78)

Zur Überführung eines generellen in ein spezifisches Referenzmodell stehen unterschiedliche Konstruktionstechniken zur Verfügung (Esswein 2016, S. 55 ff.): • Bei der Spezialisierung wird das generelle Modell in eine spezifische Lösung überführt und bei Bedarf erweitert oder modifiziert. Referenzmodelle, die für eine Spezialisierung vorgesehen sind, besitzen im Allgemeinen einen höheren Abstraktionsgrad. • Sofern Referenzmodelle modular aufgebaut sind, können diese durch Aggregation einzelner Bausteine zu spezifischen Modellen zusammengesetzt werden. • Für die Anwendung der Instanziierung werden Referenzmodelle mit Platzhaltern versehen, die dann bei der Modellanwendung durch zulässige Ausprägungen des jeweiligen Wertebereichs der Platzhalter belegt werden. • Bei der Analogiebildung werden Analogien zum Anwendungsfall gezogen und dann entsprechend dem vorgegebenen Referenzmodell modelliert. • Konfigurierbare Referenzmodelle (Becker et al. 2002) enthalten explizite Anpassungspunkte, die regeln, wie in Abhängigkeit bestimmter anwendungsspezifischer Besonderheiten eine Modellvariante abzuleiten ist. Konfigurierbare Referenzmodelle enthalten somit Regeln, nach denen sie an spezifische Bedürfnisse eines Unternehmens anzupassen sind. Dabei können einerseits Modell- und Elementtypen aus den Referenzmodellen ausgewählt werden, um den Anforderungen bestimmter Anwendergruppen zu entsprechen. Andererseits ist es möglich, spezifische Elemente aus den Referenzmodellen zu selektieren und diese anforderungsgerecht zu visualisieren. Bei Wiederverwendung von Inhalten durch Konfiguration treten gegenüber den anderen Techniken geringere Kosten auf.

200

10  Anwendungen in ERP-Systemen

Eine Klassifizierung von Anwendungen nach Herkunft und Einsatzbereich wurde bereits in Abschn. 2.3 vorgenommen. Hier wurde zwischen sektorspezifischen und -neutralen Anwendungen unterschieden. Aufgrund ihrer Praxisrelevanz werden im folgenden Abschn.  10.2 die Elemente einer sektorneutralen Anwendung auf Basis der SAP-­ Referenzmodelle zur Administration und Disposition vorgestellt. Sektorneutrale Standardsoftware wird aufgrund gleichartiger betriebswirtschaftlicher Anforderungen bzw. rechtlicher Normen in unterschiedlichen Betriebs- und Organisationstypen einheitlich eingesetzt. Die große Anzahl der bereits installierten Anwendungen und die anhaltende Verbreitung von Standardsoftwaresystemen zeigt die zunehmende Bedeutung derartiger Systeme für die operative Datenverarbeitung (Mertens et  al. 2012). Daher wird schwerpunktmäßig auf sektorneutrale Standardsoftware eingegangen. Anschließend werden sektorspezifische Anwendungsarchitekturen (s. Abschn.  10.3) sowie Konzepte zur Einführung von Standardsoftware erörtert (s. Abschn. 10.4).

10.2 Sektorneutrale Anwendungen 10.2.1 Rechnungswesen als Kern des ERP-Systems Ein ERP-System unterstützt die Administrations- und Dispositionsaufgaben eines Unternehmens. Das Rechnungswesen stellt den Kern des ERP-Systems dar. Die Teilsysteme Finanzbuchhaltung) (externes Rechnungswesen) und Kosten- und Leistungsrechnung (internes Rechnungswesen) werden als seine zentralen Komponenten betrachtet. Sie weisen nicht nur Schnittstellen zu den Anwendungen des übergeordneten Controllingsystems auf, sondern stehen auch mit untergeordneten Modulen der Anwendungsarchitektur in Verbindung. Einerseits muss die Finanzbuchhaltung auf Daten des Personalwesens oder der ­Lagerbuchhaltung zugreifen können; andererseits ist es erforderlich, dass sie relevante Daten für entscheidungsunterstützende Anwendungen (z. B. ESS, MIS, DSS) zur Verfügung stellt. Auf die angesprochenen Teilsysteme wurde bei der Behandlung der Arten von IS (s. Abschn. 2.3) eingegangen. Die Schnittstellenbeziehungen zwischen den operativen Anwendungen lassen sich aus Abb. 10.3 ablesen, deren Ausgangspunkt die Kunden und Lieferanten eines Unternehmens sind. Die Pfeile stellen die Datenflüsse zwischen den einzelnen Komponenten dar. Unternehmen stehen dem Einsatz von Standardsoftwarepaketen aus Kosten-, Risiko- und Qualitätsgründen zunehmend positiv gegenüber. Um die Funktionalität moderner ERP-Standardsoftware darzustellen, wurde das System SAP ERP der SAP SE als Referenzsystem ausgewählt. Die Funktionalität eines ERP-Systems ist durch geeignete Techniken an die konkreten betrieblichen Anforderungen anpassbar. Die folgenden Ausführungen lehnen sich dabei eng an die Dokumentation des SAP-Systems an. Hervorzuheben ist dabei, dass SAP ERP ein – vor allem bei Konzernen – weltweit verbreitetes Standardprodukt ist. Der Markt für integrierte, betriebliche Standardsoftware bietet eine Reihe weiterer Produkte, wie etwa von den Herstellern Microsoft, Oracle oder Salesforce. Dem SAP-System kommt insofern lediglich der Rang eines Beispiels zur Illustration von ERP-Konzepten zu.

201

10.2  Sektorneutrale Anwendungen

Lieferant

Kunde

Bestellung/ Lieferschein/ Wareneingang

Auftrag/Rechnung/ Warenausgang

Beschaffung

Bedarfsmeldung

Produktion

Auftragsdaten

Vertrieb

Bestandsdaten Lohndaten

Rechnungsdaten

Materialmengen

Personalwirtschaft

Löhne/ Gehälter

Kostenrechnung

Primärkosten

Finanzbuchhaltung

Abb. 10.3  Schnittstellen zwischen operativen Anwendungen

Der marktwirtschaftliche Erfolg von ERP-Systemen beruht auf der Idee, eine betriebswirtschaftliche Standardsoftware zu entwickeln, die wesentliche Teilbereiche eines Unternehmens abdeckt und sämtliche Daten durch eine einheitliche Datenbank integriert. Durch die unternehmensindividuellen Anpassungsmöglichkeiten, aber auch durch die Mehrsprachigkeit und eine standardisierte Benutzeroberfläche, wird gewährleistet, dass ein ERP-System unternehmensübergreifend und multinational eingesetzt werden kann. Damit werden auch die Anforderungen global agierender Unternehmen abgedeckt. Zur individuellen Auswertung und Weiterverarbeitung ist es möglich, Daten des ERP-Systems über Schnittstellen zu exportieren. Auf diese Weise können Data-Warehouse-Systeme mit ­Daten zur Unterstützung von Entscheidungsprozessen bewirtschaftet werden. Zudem wird meist der Datenexport an allgemeine PC-Werkzeuge (z. B. Microsoft Excel) unterstützt. Neuere Entwicklungen im ERP-Umfeld forcieren die Nutzung von In-Memory-­ Datenbanken (IMDB, s. Abschn. 11.2.6), um das Datenmanagement für operative und analytische Zwecke effizient zu vereinheitlichen. SAP stellt hierzu die SAP HANA-Plattform zur Verfügung (s. Abschn. 11.2.7), die auch als Grundlage für das neuere ERP-System SAP S/4HANA Enterprise Management dient (Plattner und Leukert 2015, S.  44  ff.). Dieses ERP-System, das seit 2015 verfügbar ist, besitzt eine stärkere Ausrichtung an den Unternehmensprozessen und eine Präsentationsschicht, die mobile Endgeräte unterstützt sowie durch den Anwender flexibel anpassbar ist (Silvia et al. 2017, S. 169 ff.). In dieser Oberfläche, die in Abb. 10.4 exemplarisch dargestellt ist, werden einzelne Kachelelemente mit Aufgaben und Statusinformationen für den Anwender angeordnet. Der Abbildung ist beispielsweise zu entnehmen, dass im Bereich Logistik (MM) eine Reihe von Beschaffungsaufträgen (Purchase Order) freizugeben ist. Einzelne Kachelelemente werden in Gruppen organisiert und in Abhängigkeit von den Nutzeranforderungen visualisiert. Zur Unterstützung unterschiedlicher Nutzerrollen (z. B. Administratoren, Anwender) bietet SAP S/4HANA entsprechende Kachelkataloge an, die über ein vorkonfiguriertes Set an Kachelelementen verfügen.

202

10  Anwendungen in ERP-Systemen

Abb. 10.4  SAP FIORI © Copyright 2018. SAP SE. Alle Rechte vorbehalten

Zur Darstellung der Funktionalitäten eines ERP-Systems wird im Folgenden auf SAP ERP zurückgegriffen, das trotz der Verfügbarkeit von SAP S/4HANA in vielen Unternehmen immer noch die dominierende ERP-Plattform bildet. Das System SAP ERP ist serviceorientiert aufgebaut (zu serviceorientierten Architekturen (SOA) s. Abschn. 9.3 und Glossar). So werden Unternehmen in die Lage versetzt, IT-Lösungen auf ihre individuellen Bedürfnisse hin zuzuschneiden und graduell an dynamische Bedürfnisse anzupassen. Zudem können Kunden und Lieferanten im Rahmen eines Supply Chain Managements in unternehmensübergreifende Prozesse eingebunden werden (s. Abschn. 12.2.2). Neben dem System SAP ERP existieren weitere Lösungen im Bereich Customer Relationship Management (SAP CRM), Supplier Relationship Management (SAP SRM), Product Lifecycle Management (SAP PLM) und Supply Chain Management (SAP SCM). Wie aus Abb. 10.5 ersichtlich, sind sämtliche Lösungen Teil der SAP Business Suite. Lösungen aus den Bereichen des CRM, SRM und SCM fokussieren die unternehmensexterne Vernetzung mit Kunden sowie Lieferanten und werden in Kap. 12 ausführlicher dargestellt. Einzelne Softwarefunktionalitäten innerhalb von SAP ERP sind einem der Bereiche Analytics (Analyse, Controlling), Financials (Finanzwesen), Human Capital Management (Personalwesen), Procurement & Logistics Execution (Einkauf und Logistik), Product Development & Manufacturing (Produktentwicklung und Fertigung) und Sales & Service (Vertrieb und Kundendienst) zugeordnet. Abb. 10.6 liefert einen Überblick über die Kernbereiche von SAP ERP. In den folgenden Abschnitten werden die Teilbereiche Finanzbuchhaltung (FIBU) und Kosten- und Leistungsrechnung (KLR) des Referenzsystems SAP ERP näher betrachtet. Aufgrund des hohen Standardisierungsgrads der Finanzbuchhaltung wird hier

10.2  Sektorneutrale Anwendungen

203 SAP Business Suite SAP Netweaver SAP PLM

SAP SRM

SAP ERP

SAP CRM

SAP SCM

Abb. 10.5  Überblick über die SAP-Lösungen © Copyright 2014. SAP SE. Alle Rechte vorbehalten

Analytics

Financials

Human Capital Management

Procurement & Logistics Execution

Product Development & Manufacturing

Sales & Service

Financial Analytics

Financial Supply Chain Management

Talent Management

Procurement

Production Planning

Sales Order Management

Operations Analytics

Treasury

Workforce Process Management

Manufacturing Execution

Aftermarket Sales and Service

Workforce Analytics

Financial Accounting

Workforce Deployment

Product Development

ProfessionalService Delivery

Management Accouting

Inventory & Warehouse Management Inbound & Outbound Logistics Transportation Management

Life-Cycle Data Management

Corporate Governance

Abb. 10.6  Auszug aus der SAP ERP Solution Map © Copyright 2014. SAP SE.  Alle Rechte ­vorbehalten

der Schwerpunkt gelegt. Die im Folgenden zu erläuternden Teilbereiche umfassen die Daten-, Prozess-, Funktions- und Organisationssicht auf die Kernbereiche und auf ausgewählte Komponenten. Zu ihrer Beschreibung werden hauptsächlich Entity-Relationship- und BPMN-Modelle verwendet (s. Abschn. 9.5 und 8.3). Darüber hinaus werden Funktionsdekompositionsdiagramme (FDD, auch Funktionshierarchien) und Datenflussdiagramme (DFD) mit selbsterklärender Notation benutzt.

204

10  Anwendungen in ERP-Systemen

10.2.2 Externes Rechnungswesen 10.2.2.1  Aufgaben der Finanzbuchhaltung Die Aufgabe der Finanzbuchhaltung besteht darin, sämtliche Geschäftsvorfälle eines Unternehmens auf Konten zahlenmäßig abzubilden und durch den Jahresabschluss eine verdichtete Darstellung der unternehmerischen Vermögens- und Erfolgssituation in Form der Bilanz und der Gewinn- und Verlustrechnung (GuV) zu erzeugen. Die Finanzbuchhaltung bildet somit die informatorische Grundlage zur Erfassung, Klassifizierung und Verdichtung der Geschäftsvorfälle und stellt damit das zentrale Informationssystem für weitere Planungs- und Kontrollrechnungen dar. Sie richtet sich primär an externe Adressaten (z. B. Gläubiger, Aktionäre). Außerdem stellen die Bilanz und die GuV die Basis zur Ermittlung von Ertragsteuern dar. Für deutsche Unternehmen besteht gem. § 238 HGB Finanzbuchhaltungspflicht, wobei die Grundsätze ordnungsmäßiger Buchführung (GoB) zu beachten sind. Seit dem Jahr 1977 ist es zulässig, die Bücher nicht mehr ausschließlich in gedruckter Form, sondern auch IT-gestützt zu führen. In diesem Fall liegt das Konzept der Speicherbuchführung vor. Allerdings wird von der Speicherbuchführung die Ausdrucksbereitschaft von Konten ­gefordert. Lediglich die Bilanz und die GuV-Rechnung müssen in gedruckter Form vorliegen. Indes werden nicht nur von börsennotierten Unternehmen, sondern in steigendem Maße auch von nicht-kapitalmarktorientierten Unternehmen internationale Regeln des Rechnungswesens in der Finanzbuchhaltung beachtet (IFRS, US GAAP). Die einzelnen Teilbereiche werden in Abb. 10.7 dargestellt. Als grundlegender Baustein der Finanzbuchhaltung ist die Hauptbuchhaltung anzusehen, in der die Buchungen auf den Sachkonten des Kontenplans vorgenommen werden. Als Sachkonten werden diejenigen Bestands- und Erfolgskonten bezeichnet, die im Kontenplan des Unternehmens enthalten sind. Der Abschluss dieser Sachkonten in Form des Jahresabschlusses führt zur Bilanz und zur Gewinn- und Verlustrechnung. Neben den Sachkonten der Hauptbuchhaltung sind weitere Konten erforderlich. Diese werden im Rahmen von Nebenbuchhaltungen erfasst, zu denen die Kontokorrentbuchhaltung, die Lagerbuchhaltung, die Anlagenbuchhaltung und die Lohn- bzw. Personalbuchhaltung gehören. Der Gegenstand der Kontokorrentbuchhaltung (ital. conto corrente = laufende Rechnung) ist die Abbildung der Geschäftsbeziehungen zu Lieferanten (Kreditoren) und Kunden (Debitoren). Durch die Kontokorrentbuchhaltung wird es möglich, für jeden Lieferanten bzw. Kunden den aktuellen Stand der Verbindlichkeiten bzw. Forderungen zu erfassen. Zu diesem Zweck ist es erforderlich, für jeden Lieferanten bzw. Kunden ein eigenes Personenkonto einzurichten, auf dem die entsprechenden Buchungen mit den Verbindlichkeits- bzw. Forderungskonten vorgenommen werden. Die Lagerbuchhaltung dient der Aufzeichnung der Bestände, Abgänge und Zugänge einzelner Materialarten sowie unfertiger und fertiger Erzeugnisse. Die Erfassung der Materialien erfolgt dabei mengenorientiert, sodass für jedes Material der mengenmäßige Bestand buchmäßig ermittelbar ist. Ein Abgleich erfolgt im Rahmen einer physischen Inventur.

10.2  Sektorneutrale Anwendungen

205

Finanzbuchhaltung

Hauptbuchhaltung

Nebenbuchhaltung

Kontokorrentbuchhaltung

Kreditorenbuchhaltung Debitorenbuchhaltung

Anlagenbuchhaltung Lohn- und Gehaltsbuchhaltung

Lagerbuchhaltung

Abb. 10.7  Struktur der Finanzbuchhaltung

Durch die vollständige Aufzeichnung der Lagerbestände kann auch eine kontinuierliche Kontrolle in Form von Mindest- oder Höchstbeständen für einzelne Artikel durchgeführt werden. Ferner kann durch die Integration eines Ausnahmeberichtswesens (Exception Reporting) eine Lagersteuerung implementiert werden, die zielgerichtete interaktive Dispositionen ermöglicht. Um das Anlagevermögen des Unternehmens zu verwalten, ist ein Verzeichnis aller zugehörigen Wirtschaftsgüter erforderlich. Da die Anlagekonten des Hauptbuchs als Sammelkonten geführt werden, ist eine Detaillierung in Form einer eigenen Anlagenbuchhaltung erforderlich. In der Anlagenbuchhaltung erfolgt die Erfassung der Sach- und Finanzanlagen und der immateriellen Vermögensgegenstände. Für sämtliche Teile des Anlagevermögens werden in der Anlagenbuchhaltung auch die für die Berechnung der Abschreibungen benötigten Daten erfasst. In der Lohn- und Personalbuchhaltung werden die entsprechenden Konten der Mitarbeiter des Unternehmens geführt, auf denen nicht nur die Erfassung von Löhnen und Gehältern erfolgt, sondern auch die Dokumentation sonstiger Leistungen, wie beispielsweise Vorschüsse, Sondervergütungen und Sachleistungen. Im Folgenden werden die einzelnen Teilbereiche der Finanzbuchhaltung anhand des Referenzsystems SAP ERP dargestellt. Der Großteil der Funktionen wird dabei durch den

206

10  Anwendungen in ERP-Systemen

Bereich Financial Accounting abgedeckt (s. Abb. 10.6). Zur Darstellung der Finanzbuchhaltung sind zunächst die Grunddaten zu erörtern. Hierzu gehören generelle Parameter zur Anpassung des Softwaresystems an die Unternehmenssituation als auch die Stammdaten. Anschließend wird auf die Funktionalität der Finanzbuchhaltung eingegangen.

10.2.2.2  Stammdaten der Hauptbuchhaltung Zur Einrichtung der Finanzbuchhaltung als operatives System der Anwendungsarchitektur wird i. d. R. eine unternehmensspezifische Anpassung vorgenommen, die als Customizing bezeichnet wird (s. Abschn. 10.4). Im Rahmen des Customizingprozesses ist die Abbildung der Unternehmensstruktur sowie der landesspezifischen Besonderheiten (z. B. Währung, Steuersätze) erforderlich. Dies erfolgt anhand von Stammdaten. cc Stammdaten  Stammdaten sind Grunddaten eines Unternehmens, die sich auf betriebswirtschaftlich relevante Objekte beziehen. Stammdaten existieren unabhängig von anderen Daten und werden im Zeitablauf selten verändert. Das SAP ERP-System verwendet zum Customizing einen standardisierten Einführungsleitfaden, der als SAP-Referenz-IMG (Implementation Guide) bezeichnet wird. Die einzelnen Schritte dieses Leitfadens müssen zur Einführung des Systems abgearbeitet werden, um ein lauffähiges SAP ERP-Produktivsystem zu erhalten. Abb.  10.8 zeigt einen Auszug aus dem SAP ERP-Referenz-IMG für den Bereich Finanzwesen. Die oberste Hierarchieebene der SAP-Stammdaten ist der Mandant. Ein Mandant ist eine geschlossene Unternehmenseinheit, verfügt über einen eigenen Stammdatenbestand und ist von anderen Mandanten unabhängig (Maassen et al. 2006, S. 15). Die Eigenschaft der Anwendungen, einzelne Teilbereiche in sich geschlossen abzurechnen, wird als Mandantenfähigkeit bezeichnet. In einem SAP ERP-System können, da die Bedingung der Mandantenfähigkeit erfüllt ist, folglich mehrere eigenständig abzurechnende Unternehmen abgebildet werden. Zur Identifizierung eines Mandanten muss der Anwender einen Mandantenschlüssel angeben. Alle anschließenden Operationen werden dann nur für diesen Mandanten durchgeführt. Als nächste organisatorische Einheit unterhalb des Mandanten stellt sich der Buchungskreis dar. Mit Buchungskreisen werden rechtlich selbstständige Tochtergesellschaften abgebildet. Daher werden für jeden Buchungskreis eine eigene Bilanz und GuV nach den jeweiligen rechtlichen Bestimmungen erstellt. Betriebswirtschaftlich stellt ein Buchungskreis eine Gesellschaft im juristischen Sinne dar (z. B. eine GmbH, AG, KG), die innerhalb eines als Mandant abgebildeten Konzerns organisiert sein kann. In der Terminologie des SAP-Customizingprozesses werden für jeden Mandanten unternehmensinterne und unternehmensexterne Sachverhalte auf interne und externe Organisationseinheiten abgebildet. Externe Organisationseinheiten stellen dabei Objekte dar, die für die Erfüllung von Rechtsnormen erforderlich sind und daher Außenwirkungscharakter besitzen. Die externen Organisationseinheiten werden daher auch als rechtliche ­Organisationseinheiten bezeichnet. Zu diesen rechtlichen Konstrukten gehören der Buchungskreis und die Gesellschaft.

10.2  Sektorneutrale Anwendungen

207

Abb. 10.8  SAP-Referenz-IMG (Auszug) © Copyright 2018. SAP SE. Alle Rechte vorbehalten

Eine Gesellschaft ist eine organisatorische Einheit des Rechnungswesens eines Unternehmens. Bei der Durchführung der Konzernkonsolidierung fließen die Einzelabschlussdaten der Gesellschaften in das Konsolidierungssystem ein. Ein Buchungskreis ist eine organisatorische Einheit des Rechnungswesens, durch die das Unternehmen aus Sicht der Finanzbuchhaltung gegliedert wird. In einem Buchungskreis erfolgt eine vollständige Buchhaltung. Ein Buchungskreis umfasst grundsätzlich eine rechtlich selbstständige Gesellschaft. Aber auch rechtlich unselbstständige Einheiten, beispielsweise Betriebsstätten im Ausland, können abgebildet werden. Auf diese Weise lassen sich für diese Einheit eigene Berichtsfunktionen in der jeweiligen Landeswährung nutzen. Zu den Stammdaten, die für einen Buchungskreis zu definieren sind, gehören insbesondere der Kontenplan, die Geschäftsjahresdefinition und die zu verwendenden Parallelwährungen. Das SAP ERP-System wird mit dem voreingestellten Buchungskreis ausgeliefert, der die Parameter für Deutschland enthält. Weitere voreingestellte Buchungskreise sind als Länderschablonen (Country Templates) verfügbar. Abb. 10.9 stellt einige buchungskreisspezifische Parameter dar.

208

10  Anwendungen in ERP-Systemen

Abb. 10.9  Globale Parameter für den Buchungskreis © Copyright 2018. SAP SE.  Alle Rechte ­vorbehalten

Die internen Organisationseinheiten besitzen lediglich Innenwirkungscharakter und dienen dazu, die interne Funktionalität des Rechnungswesens zu erweitern. Zu den internen Organisationseinheiten gehören die optionalen Konstrukte Geschäftsbereich sowie Kreditkontroll- und Mahnbereich. Durch die Definition von Geschäftsbereichen ist es im Rahmen der Finanzbuchhaltung von SAP ERP möglich, die Buchungen auf den Sachkonten differenziert auszuwerten. SAP ERP unterstützt dabei die Erstellung einer internen Bilanz und GuV auf Geschäftsbereichsebene, die auch als Informationsgrundlage für das Controlling dient. Um bei der Buchung von Geschäftsvorfällen eine korrekte Zuweisung zu den verursachenden Geschäftsbereichen sicherzustellen, ist der entsprechende Geschäftsbereichsschlüssel bei jeder Buchung anzugeben (s. Abb. 10.10). Ein Kreditkontrollbereich ist eine interne Organisationseinheit des Rechnungswesens, die für Debitoren ein Kreditlimit definiert und überwacht. Ein Kreditkontrollbereich ist dadurch gekennzeichnet, dass er eine einheitliche Währung aufweist und mehrere Buchungskreise umfassen darf. Abb. 10.11 stellt den Zusammenhang zwischen Buchungskreisen und Kreditkontrollbereichen her. Der im Beispiel abgebildete Konzern besitzt Niederlassungen in Deutschland, Frankreich, USA und Kanada und verfügt über vier

10.2  Sektorneutrale Anwendungen

209

Abb. 10.10  Definition von Geschäftsbereichen unter SAP ERP © Copyright 2018. SAP SE. Alle Rechte vorbehalten

Buchungskreise, die nach den landesspezifischen Rechtsnormen einzeln abgeschlossen werden. In jedem Buchungskreis existieren Geschäftsbeziehungen mit dem Debitor X. Innerhalb des SAP ERP-Systems werden die beiden Kreditkontrollbereiche Europa (Währung Euro) und Nordamerika (Währung USD) angelegt. Für jeden dieser Kreditkontrollbereiche wird ein Kreditlimit in der entsprechenden Währung definiert. Dieses Kreditlimit gilt grundsätzlich für jeden einzelnen Debitor. Für einzelne Debitoren kann jedoch zusätzlich ein individuelles Kreditlimit festgelegt werden. Abb. 10.12 stellt einen Kreditkontrollbereich dar, der unter SAP ERP definiert wurde. So weist der Kreditkontrollbereich Nordamerika beispielsweise ein Kreditlimit von 200.000 USD für jeden einzelnen Debitor auf, der in den Buchungskreisen dieses Kreditkontrollbereichs aktiv ist. Das Mahnwesen von SAP ERP wird im Allgemeinen auf Buchungskreisebene abgewickelt, sodass jeder Buchungskreis genau einen Mahnbereich bildet. In der Praxis liegt häufig eine divisionalisierte Unternehmensstruktur vor, bei der die Mahnfunktion auf die einzelnen Geschäftsbereiche, Vertriebsorganisationen oder Sparten verteilt wird. Diese Organisationsbereiche können unter SAP ERP als Mahnbereiche erfasst werden.

210

10  Anwendungen in ERP-Systemen

Kreditkontrollbereich Europa Buchungskreis Frankreich

Buchungskreis Deutschland

Debitor X

Debitor X

Kreditkontrollbereich Nordamerika Buchungskreis USA

Buchungskreis Kanada

Debitor X

Debitor X

Abb. 10.11  Kreditkontrollbereiche und Buchungskreise

Abb. 10.12  Definition eines Kreditkontrollbereichs mit SAP ERP © Copyright 2018. SAP SE. Alle Rechte vorbehalten

211

10.2  Sektorneutrale Anwendungen

Die dargestellten internen und externen Organisationseinheiten können als logisches Organisationssystem des Rechnungswesens interpretiert werden. Dieses wird in Abb. 10.13 durch ein Entity-Relationship-Diagramm (in traditioneller Notation, s. Abschn. 9.5) illustriert. Sämtliche Geschäftsvorfälle des Unternehmens werden auf Sachkonten der Hauptbuchhaltung gebucht. Um einen systematischen Aufbau und eine einheitliche Benennung der Konten zu gewährleisten, sind die einzelnen Sachkonten durch Kontenrahmen und Kontenplan zu gliedern. Der Kontenrahmen ist in zehn Kontenklassen unterteilt, bei denen wiederum einzelne Kontengruppen unterschieden werden. Durch die Einheitlichkeit dieses Ordnungssystems kann sowohl ein Betriebsvergleich (z.  B. zwischen Konzerntöchtern) als auch ein Zeitvergleich (innerhalb eines Unternehmens) auf Kontenebene durchgeführt werden. Bei der Auswahl des Kontenrahmens gibt es neben branchenspezifischen Empfehlungen (z. B. für den Einzelhandel) die grundlegenden Gliederungsprinzipien der Abschluss- und der Prozessgliederung (Bechtel und Brink 2010, S.  106  ff.). Das Abschlussgliederungsprinzip

Geschäftsbereich

(1,1)

(0,n)

GBZO

logisches System Finanzbuchhaltung (0,n)

(0,n)

KKBZO

BKZO

(0,1)

(0,1)

Kreditkontrollbereich

(0,n)

KKBBK-ZO

(0,1)

Buchungskreis (0,n)

(0,1) BKG-ZO

(0,n)

Mahnbereich

(0,1)

BKMB-ZO

Legende GBZO KKBZO BKZO BKG-ZO BKMB-ZO

Geschäftsbereich-Zuordnung Kreditkontrollbereich-Zuordnung Buchungskreis-Zuordnung Buchungskreis-Gesellschaft-Zuordnung Buchungskreis-Mahnbereich-Zuordnung

Abb. 10.13  System der Finanzbuchhaltung als Entity-Relationship-Diagramm

Gesellschaft

212

10  Anwendungen in ERP-Systemen

wird beispielsweise im Industriekontenrahmen des Bundesverbands der Deutschen Industrie realisiert (Tab. 10.1). Das Prinzip orientiert sich am Jahresabschluss der Kapitalgesellschaften nach § 266 Abs. 2 und 3 (Bilanz) und § 275 Abs. 2 und 3 (GuV) des HGB. Beim Prozessgliederungsprinzip wird der Kontenrahmen nach dem generellen Ablauf der betrieblichen Leistungserstellung gegliedert. Dieser lässt sich in die Stufen der Beschaffung von Kapital und Produktionsfaktoren, Verbrauch von Produktionsfaktoren, Herstellung und Lagerung der produzierten Güter und deren Verkauf unterteilen. Dieses ­Gliederungsprinzip wird z. B. vom Gemeinschaftskontenrahmen der Industrie (GKR) realisiert, der bereits im Jahr 1948 vom Arbeitsausschuss Betriebswirtschaft industrieller Verbände erarbeitet und Industrieunternehmen zur Anwendung empfohlen wurde (s. Tab. 10.2). Die datenorientierte Modellierung der Konten und des Kontenplans wird durch das Entity-Relationship-Modell in Abb. 10.14 beschrieben, das außerdem den Buchungskreis und den Mandanten erfasst. Aus Gründen der Übersichtlichkeit wird in der Abbildung auf die Darstellung der Attribute verzichtet. Jeder Mandant (Konzern) kann mehrere Buchungskreise (Konzerntöchter) aufweisen. Dieser Sachverhalt wird durch den Beziehungstypen MBKZO ausgedrückt (Mandant-­ Buchungskreis-­ Zuordnung). Jedem Buchungskreis muss genau ein Kontenrahmen (z. B. GKR oder IKR) zugewiesen werden. Dies geschieht durch den Beziehungstypen Tab. 10.1  Gliederung des Industriekontenrahmens (IKR)

Tab. 10.2  Gliederung des Gemeinschaftskontenrahmens (GKR)

Klasse 0–1 2 3 4 5 6 7 8 9

Konten Anlagevermögen Umlaufvermögen Eigenkapital und Rückstellungen Verbindlichkeiten Erträge Betriebliche Aufwendungen Weitere Aufwendungen Ergebnisrechnungen Kosten- und Leistungsrechnung

Klasse Konten 0 Anlagevermögen 1 Umlaufvermögen, Forderungen Verbindlichkeiten 2 Neutrale Aufwendungen und Erträge 3 Roh-, Hilfs- und Betriebsstoffe Wareneinkauf 4 Kostenarten 5 Verrechnungskonten 6 Kostenstellenrechnung 7 Kostenträgerrechnung 8 Erlöskonten 9 Abschlusskonten

10.2  Sektorneutrale Anwendungen

(1,n)

Mandant

213

MBKZO

(1,1)

Buchungskreis (1,1)

(1,1)

Konto

KZO

(1,n)

KPBKZO

(0,n)

(0,n)

(0,n) KSTRUKTUR

Kontenplan

Legende MBKZO KPBKZO KZO KSTRUKTUR

Mandant-Buchungskreis-Zuordnung Kontenplan-Buchungskreis-Zuordnung Kontenzuordnung Kontenstruktur

Abb. 10.14  Modellierung der Konten und des Kontenplans

KPBKZO.  Erst wenn die Zuordnung des zum Kontenrahmen gehörenden detaillierten Kontenplans zum Buchungskreis erledigt ist, kann über den Beziehungstyp der Kontenzuordnung die Abbildung der Konten auf den Kontenplan für den gewünschten Buchungskreis erfolgen. Der Aufbau des Kontenplans wird durch den Beziehungstypen KSTRUKTUR erfasst. Die (0,n):(0,n)-Kardinalität erlaubt die Abbildung vernetzter Kontenbeziehungen. Auf diese Weise lassen sich unterschiedliche Abschlussvorschriften abbilden, wie sie beispielsweise im Steuerrecht und im Handelsrecht vorgesehen sind. Das System SAP ERP wird mit einer Vielzahl von vordefinierten Kontenrahmen ausgeliefert. Einen Überblick über die im System verfügbaren Kontenrahmen liefert das sog. Kontenplanverzeichnis (s. Abb. 10.15). Für das System eines Mandanten unterstützt SAP ERP beliebig viele Kontenpläne. Dadurch können unterschiedliche Anforderungen der einzelnen Buchungskreise an den Kontenrahmen realisiert werden, die sich dann ergeben, wenn die Buchungskreise des Mandanten in mehreren Ländern ansässig sind, zu unterschiedlichen Sektoren gehören oder verschiedene Rechtsformen besitzen. Grundsätzlich ist es auch möglich, eigene Kontenpläne und die damit verbundenen Sachkonten manuell aufzubauen. Zu überlegen ist, einen vorhandenen Kontenplan zu kopieren und lediglich die vom Kontenplan abweichenden Konten anzupassen.

214

10  Anwendungen in ERP-Systemen

Abb. 10.15  Kontenplanverzeichnis © Copyright 2018. SAP SE. Alle Rechte vorbehalten

Die Attribute der Sachkonten können in buchungskreis- und kontenplanspezifische Daten differenziert werden. Während sich die kontenplanspezifischen Daten aus dem ­selektierten Kontenplan ableiten lassen, sind die buchungskreisspezifischen Daten nur für den aktuellen Buchungskreis (z.  B. für eine Konzerntochter) gültig. Zu den buchungskreisspezifischen Daten gehören: • Die Währung, in der auf dem Konto gebucht werden kann. Grundsätzlich kann auf einem Konto in jeder gewünschten Währung gebucht werden, doch bietet es sich z. B. für Devisenkonten an, nur Buchungen in einer Währung zuzulassen. • Das Steuerkennzeichen gibt an, welche Umsatzsteuersätze zu verwenden sind. • Die Kontenabstimmung stellt sicher, dass entsprechende Abstimmbuchungen mit den Büchern der Nebenbuchhaltung (z. B. Kreditoren-, Debitoren- oder Anlagenbuchhaltung) durchgeführt werden. Durch die Abstimmkontentechnik kann jederzeit ein Abschluss erstellt werden, da die Beträge aus den Nebenbuchhaltungen auch in der Hauptbuchhaltung gebucht werden. • Die Berechtigung kennzeichnet die Benutzergruppe, die zum Zugriff auf das Konto autorisiert ist.

10.2  Sektorneutrale Anwendungen

215

Zu den kontenplanspezifischen Daten des Sachkontenstamms gehören: • Die Kontonummer und die Kontenbezeichnung, • der Kontentyp, der angibt, ob es sich bei dem Konto um ein Bilanz- oder ein Erfolgskonto handelt, und • die Kontengruppe, die bestimmt, welche Felder beim Anlegen oder Ändern des Sachkontenstammsatzes ausgefüllt werden müssen. • Bei Bilanzkonten erfolgt zum Jahreswechsel der automatische Saldenvortrag, während bei Erfolgskonten explizit angegeben werden muss, auf welches Konto der GuV ein eventueller Gewinn- bzw. Verlustvortrag gebucht werden soll.

10.2.2.3  Stammdaten der Debitoren- und Kreditorenbuchhaltung Im Rahmen der Debitoren- und Kreditorenbuchhaltung werden die Geschäftsbeziehungen der Unternehmen zu Kunden und Lieferanten erfasst. Hierzu gehören beispielsweise Adressdaten, Zahlungsbedingungen und Bankverbindungen. Da Debitoren und Kreditoren in mehreren Buchungskreisen eines Konzerns aktiv sein können, ist es sinnvoll, die Daten in einen allgemeinen und einen buchungskreisabhängigen Bereich zu untergliedern. Abb. 10.16 liefert einen Überblick über die zu verarbeitenden Kreditoren- und Debitorenstammdaten. Die allgemeinen Stammdaten umfassen diejenigen Attribute, die einen Debitoren bzw. Kreditoren unabhängig von seiner Aktivität in den Buchungskreisen des Mandanten beschreiben. Zu diesen Daten gehören sämtliche Anschriftdaten, die neben dem Namen und der Adresse des Kreditoren bzw. Debitoren auch die Kommunikationsmöglichkeiten (z. B. Telefax, E-Mail) enthalten. Werden steuerbefreite Lieferungen erbracht, ist die Erfassung der Steuerdaten des Debitoren erforderlich. Dies geschieht z.  B. in Form einer Kreditoren-/ Debitorenstammdaten

allgemeine Daten

buchungskreisabhängige Stammdaten

Anschrift

Abstimmkonto

Steuerdaten

Zahlungsverkehr

Referenzdaten

Mahndaten Versicherung

Abb. 10.16  Stammdaten für Kreditoren bzw. Debitoren

216

10  Anwendungen in ERP-Systemen

Steuernummer, die als zusammenfassende Meldung den Finanzbehörden mitgeteilt und auf der Rechnung ausgewiesen wird. Zur eindeutigen Identifikation im Geschäftsverkehr kann außerdem die Erfassung von besonderen Referenzdaten erfolgen. Zu diesem Zweck wird häufig die globale Lokationsnummer (Global Location Number, GLN) verarbeitet, die in Deutschland von der GS1 Germany an Unternehmen vergeben wird. Zu den buchungskreisabhängigen Stammdaten für Kreditoren und Debitoren gehören die Kontoführungsdaten, auf die nun im Einzelnen einzugehen ist. Die Geschäftsvorfälle, die in der Kreditoren- und Debitorenbuchhaltung gebucht werden, müssen gleichzeitig auf den Konten der Hauptbuchhaltung abgebildet werden. Zu diesem Zweck wird jedem Kreditoren- bzw. Debitorenkonto ein Abstimmkonto in der Hauptbuchhaltung zugewiesen. Sowohl für Kreditoren als auch für Debitoren ist die Abbildung des Zahlungsverkehrs erforderlich. Dazu gehört die Erfassung der gewährten Zahlungsbedingungen durch die Kreditoren bzw. Debitoren sowie die Darstellung der Bankverbindungen. Bei der Durchführung des Zahlungsverkehrs ist neben dem Bank Identifier Code (BIC) die IBAN (International Bank Account Number) als zweites Identifikationsmerkmal zu erfassen, die weltweit der eindeutigen Adressierung von Konten dient. Alle Bankenstammdaten werden unter SAP  ERP zentral in einem Bankenverzeichnis abgelegt. Dieses Bankenverzeichnis umfasst sowohl die eigenen Bankverbindungen des Mandanten als auch die Bankverbindungen der Kreditoren und Debitoren. Das Bankenverzeichnis kann im SAP ERP-System automatisch aufgebaut werden, indem das von den Geschäftsbanken bereitgestellte nationale Bankenverzeichnis eingespielt wird. Die Mahndaten geben an, mit welchen Parametern die Mahnung von Debitoren erfolgen soll. Zu den Parametern des Mahnverfahrens gehört die Anzahl der Mahnstufen, die vor Durchführung eines gerichtlichen Mahnverfahrens (Mahn- und ­Vollstreckungsbescheid bzw. Betreibung) durchlaufen werden, sowie die Mahntexte, aus denen automatisch eine schriftliche Mahnung erstellt wird. Für Forderungen mit längerer Laufzeit können Warenkreditversicherungen abgeschlossen werden, die als Teil der Debitorenstammdaten zu erfassen sind. Die dargestellten Stammdaten verdeutlichen, dass das Anlegen eines neuen Kreditoren bzw. Debitoren mit relativ hohem Aufwand verbunden ist. Für Geschäftspartner, bei denen selten bzw. einmalig Geschäftsvorfälle anfallen, empfiehlt sich die Anlage sog. Conto-­pro-­ Diverse-Konten (CpD-Konten). Bei dieser Art von Personenkonto werden die Stammdaten bei der Belegerfassung eingegeben und innerhalb des Belegs gespeichert. Auf diese Weise werden die Datenbestände des Kreditoren- bzw. Debitorenstamms nicht unnötig vergrößert. Bei der Verwaltung der Kreditoren- und Debitorenstammdaten kann die Besonderheit auftreten, dass ein Kreditor gleichzeitig auch Debitor des Mandanten ist. Für den Ablauf der Buchhaltung ist dies von Interesse, wenn z. B. ein Kunde eine gegen ihn bestehende Forderung automatisch mit eigenen Lieferungen verrechnet. In diesem Fall muss die Verwaltung der offenen Posten im Rahmen der Debitorenbuchhaltung angepasst werden. Dies geschieht unter SAP ERP, indem für den Geschäftspartner ein Debitoren- und ein Kreditorenstammsatz angelegt und die Optionen zur Verrechnung aktiviert werden. Da die ­Verrechnung auf Buchungskreisebene eingestellt wird, kann für jeden Buchungskreis entschieden werden, bei welchen Kreditoren bzw. Debitoren diese Möglichkeit vorzusehen ist.

10.2  Sektorneutrale Anwendungen

217

10.2.2.4  Stammdaten der Anlagenbuchhaltung Die Anlagenbuchhaltung dient der Dokumentation des Anlagevermögens der Unternehmen. Dabei werden die Arten des Anlagevermögens in immaterielle Vermögensgegenstände (z. B. Rechte, Konzessionen), Sachanlagen (z. B. Maschinen, Gebäude) und Finanzanlagen (z. B. Unternehmensbeteiligungen, Wertpapiere) unterschieden. Die größte praktische Relevanz im Rahmen der Anlagenbuchhaltung haben die Sachanlagen, die ein Unternehmen durch Kauf oder Eigenfertigung investiert hat. Im Folgenden wird daher nur auf den Bereich der Sachanlagen eingegangen. Das Entity-Relationship-Modell in Abb. 10.17 beschreibt die erforderlichen Sachverhalte für die Erfassung von Sachanlagen. In der Praxis treten Anlagen nicht als homogene Einheiten auf, sondern als heterogene Anlagenkomplexe, die einem dynamischen Entwicklungsprozess unterliegen. Um diesen Sachverhalt betriebswirtschaftlich abzubilden, ist bei der Stammdatenerfassung die Abbildung von Anlagenkomplexen zu unterstützen. Dies wird in dem angeführten ER-­ Diagramm durch die rekursive Assoziation ASTRUKTUR (Anlagenstruktur) ermöglicht. Standort (0,n)

ASZO (0,n)

(1,1)

Anlage

ASTRUKTUR

(0,1)

AAKZO

(0,n)

Anlagenklasse

(1,1) (0,n) AKSZO

(0,n)

Kostenstelle

(1,1)

KSGBZO

Legende ASZO ASTRUKTUR AAKZO AASZO KSGBZO

Anlagen-Standort-Zuordnung Anlagenstruktur Anlagen-Anlagenklassen-Zuordnung Anlagen-Kostenstellen-Zuordnung Kostenstellen-Geschäftsbereich-Zuordnung

Abb. 10.17  Modellierung der Anlagenbuchhaltung

(0,n)

Geschäftsbereich

218

10  Anwendungen in ERP-Systemen

Diese Assoziation erlaubt es, einer Anlage mehrere Teilanlagen zuzuordnen. Einzelne Teilanlagen können auch mehreren Anlagen zugeordnet werden. Neben der hierarchischen Strukturierung komplexer Anlagen werden unter Integrationsaspekten verschiedene Angaben erforderlich. So ist es sinnvoll, Anlagenklassen (z. B. Fuhrpark, Maschinen) zu definieren, um beispielsweise spezifische Abschreibungsund Bewertungsmethoden auf sämtliche Anlagen dieser Klasse anwenden zu können. Wenn Bilanzen zu Auswertungszwecken auf Geschäftsbereichsebene erstellt werden, ist außerdem die Zuordnung der Anlage zu einem bestimmten Bereich erforderlich. Dies erfolgt über die Erfassung der Kostenstelle, der die Anlage zugeordnet ist. Außerdem ist eine Zuordnung zu einem räumlichen Standort (z. B. Werk, Gebäude) üblich.

10.2.2.5  Bewegungsdaten der Finanzbuchhaltung Die Bewegungsdaten resultieren aus den Geschäftsvorfällen eines Mandanten und haben i. d. R. Auswirkungen auf dessen Bestandsdaten. cc Bewegungsdaten  Bewegungsdaten sind ereignis- bzw. zeitbezogene Daten, die die Ausprägung von Bestandsdaten verändern. Bestandsdaten beziehen sich auf betriebswirtschaftlich relevante Mengen- und Wertangaben. Zur korrekten Abbildung der Geschäftsvorfälle sind aber auch Stammdaten, z. B. Kreditoren- und Debitorenkonten, erforderlich. In der Datenmodellierung sind Bewegungsdaten durch Zeitpunkt- und/oder Transaktionsbezüge gekennzeichnet, während Stammdaten entweder unbeschränkt gültig sind oder einen Zeitraumbezug aufweisen (gültig von … bis …). Bei der Abbildung von Geschäftsvorfällen im System der Finanzbuchhaltung ist das Belegprinzip als maßgeblicher Grundsatz zu beachten. Ein Beleg dokumentiert einen Geschäftsvorfall und stellt die Grundlage für die Buchung im System der Finanzbuchhaltung dar. In der betrieblichen Praxis existiert eine Vielzahl von Belegarten, wie z. B. Eingangs- und Ausgangsrechnungen, Gutschriften und Stornierungen sowie selbst erstellte Dokumente als Buchungsgrundlage. SAP ERP wird standardmäßig mit den folgenden Belegarten ausgeliefert: Debitorenrechnung, Debitorenzahlung, Debitorengutschrift, Kreditorenbeleg, Kreditorengutschrift, allgemeiner Beleg, Sachkontenbeleg und Kassenbeleg. Dabei lässt sich die Struktur von Belegen in einen Belegkopf und einzelne Belegpositionen einteilen. Abb. 10.18 stellt als Beispiel den Beleg „Ausgangsrechnung“ dar. Um eine möglichst einfache Abbildung der Belegarten im System der Finanzbuchhaltung zu ermöglichen, ist eine einheitliche Belegstruktur für die Bewegungsdatenverwaltung sinnvoll. Abb. 10.19 veranschaulicht eine Modellierungsvariante für den Sachverhalt der Verwaltung von Bewegungsdaten. In dem dargestellten ER-Diagramm werden die unterschiedlichen Dokumente der Geschäftsvorfälle (z.  B.  Kundenrechnung, Lieferantenrechnung) erfasst und zwecks Vereinheitlichung auf ein generalisiertes Dokument abgebildet. Dieses Dokument, das die Entitätstypen Urbelegkopf und Urbelegposition umfasst, dient dabei lediglich der Standardisierung

219

10.2  Sektorneutrale Anwendungen Belegart: Belegnummer: Buchungskreis: Datum:

Ausgangsrechnung an Debitoren 0001 0000018056 2 28.07.2014

Belegkopf

Position

Artikel

Menge

Preis

1

0100

2

99,00

2

0466

10

10,00

3

0622

76

21,76

4

0666

1

00,47

Belegpositionen

Abb. 10.18  Beispiel für einen Beleg (Ausgangsrechnung an Debitoren) Dokumente der Geschäftsvorfälle

Generalisiertes Dokument der Geschäftsvorfälle (fiktiv)

den Geschäftsvorfall repräsentierendes Dokument des Rechnungswesens BLGTYNR, Buchungsdatum (BLGNR)

BLGTYNR Belegtyp

UBLGNR

Buchungsdatum

(0,n)

Kundenrechnung

Urbelegkopf

(0,n)

UBZUO

(1,1)

(1,n)

Zahlungseingang (Kontoauszug) Zahlungsaufforderung

UBPZO

(1,1) (0,n)

UBLGNR.POSNR

Gutschrift

Zeit

BKBPZO

(1,1)

Urbelegposition

(0,n)

(1,n)

Lieferantenrechnung Zahlungseingang (Scheck)

Belegkopf

UBPZUO

(1,1)

Belegposition

Legende UBZUO UBPZUO BKBPZO UBPZO

Urbelegkopf-Zuordnung Urbelegposition-Zuordnung Belegkopf-Belegposition-Zuordnung Urbeleg-Position-Zuordnung

Abb. 10.19  ER-Diagramm zur Erfassung von Belegdaten (Scheer 1997, S. 632)

vielfältiger materieller Belegarten. Es wird benötigt, um die Belegerfassung durch die Entitätstypen Belegkopf und Belegposition zu ermöglichen. Neben dem Belegkopf und den einzelnen Belegpositionen ist es aus Sicht der Datenorganisation erforderlich, den Belegtypen zu erfassen. Dieser dokumentiert auch die Transformationsbeziehungen, die zur Abbildung eines materiellen Belegtypen im System des Rechnungswesens notwendig sind.

220

10  Anwendungen in ERP-Systemen

SAP ERP orientiert sich am Belegprinzip und speichert Buchungen stets in Belegform. Der Beleg, der über eine eindeutige Schlüsselnummer identifiziert wird, verbleibt als zusammenhängende Einheit im System. Lediglich durch die Archivierung von Beleggruppen kann der Beleg das System verlassen und ausgelagert werden. Zur Buchung von Belegen muss der Beleg dem Kriterium der Vollständigkeit genügen. Dies ist dann erfüllt, wenn der Saldo aus den Soll- und Habenpositionen ausgeglichen ist und alle Mindestkontierungen aufweist, zu denen Belegdatum, Buchungsdatum, Belegart, Buchungsschlüssel und Kontonummer gehören.

10.2.2.6  Funktionen der Hauptbuchhaltung Abb.  10.20 klassifiziert die Funktionen der Hauptbuchhaltung, die im Folgenden näher betrachtet werden. Im Bereich der Stammdatenpflege werden die Sachkonten der Hauptbuchhaltung verwaltet. Zu den zentralen Aufgaben gehören dabei das Anlegen, Ändern, Anzeigen und Löschen der Sachkontenstammdaten. Will sich der Anwender beispielsweise Informationen über ein Konto anzeigen lassen und wählt im SAP ERP-System das entsprechende Kommando aus, verlangt das System zur Identifikation des Kontos die beiden Schlüsselattribute Buchungskreisnummer und Kontonummer. Gerade bei komplexen Mandanten mit vielen Buchungskreisen ist diese Art von Kontenidentifikation umständlich. Als Suchhilfe ist deshalb die Matchcodesuche einzusetzen (Körsgen 2015). Die für die Sachkontensuche möglichen Matchcodes sind in Abb. 10.21 dargestellt. In dem Menü hat der Anwender die Möglichkeit, den Suchmodus zu definieren. So wird bei der Eingabe der Kontonummer standardmäßig nach der Sachkontonummer im Kontenplan gesucht. Effektiver ist häufig jedoch die Suche nach Schlagworten bzw. der Sachkontenbezeichnung des gesuchten Kontos. Bei der Suche nach der Sachkontenbezeichnung können Platzhalterzeichen (z. B. *) eingegeben werden, um rasch geeignete Ergebnismengen zu finden. Abb. 10.21 liefert das Ergebnis der Suche nach dem Begriff „Forderung“, der an einer beliebigen Stelle innerhalb der Sachkontenbezeichnung stehen darf. Neben allgemeinen Verwaltungsoperationen, wie Anzeigen, Anlegen, Ändern und Löschen von Sachkonten, bietet SAP ERP auch die Möglichkeit, einzelne Sachkonten zu sperren (s. Abb. 10.22). Der Prozess der Sachkontenbuchung lässt sich in BPMN-Notation darstellen (s. Abb. 10.23). Der Ablauf dieses Buchungsprozesses wird anhand eines Beispiels ­dargestellt. Dabei wird eine Umbuchung zwischen zwei Bankkonten durchgeführt (Aktivtausch).

Hauptbuchhaltung

Stammdatenpflege

Buchungen durchführen

Abb. 10.20  Funktionen der Hauptbuchhaltung

Abschluss

Planung

10.2  Sektorneutrale Anwendungen

221

Abb. 10.21  Suche nach dem Begriff „Forderung“ in der Sachkontenbezeichnung © Copyright 2018. SAP SE. Alle Rechte vorbehalten

Wird der Menüpunkt „Allgemeine Buchung“ aus der Hauptbuchhaltung ausgewählt, hat der Anwender in einem ersten Schritt Informationen über den Belegkopf einzugeben, wie in Abb. 10.24 dargestellt. Beim Belegdatum handelt es sich um das Datum, auf das der Originalbeleg – also der Überweisungsbeleg der transferierenden Bank – ausgestellt worden ist. Das Buchungsdatum dagegen stellt das Datum dar, an dem der Beleg in das System eingespeist wird. Dieses Datum wird vom System automatisch vorgegeben. Die Angabe des Buchungskreises erlaubt die Zuordnung des Belegs zu der jeweiligen Konzerntochter als eine

222

10  Anwendungen in ERP-Systemen

Abb. 10.22  Sperrmöglichkeit von Konten mit SAP ERP © Copyright 2014. SAP SE. Alle Rechte vorbehalten

selbstständig bilanzierende Einheit. Für Belege, die in einer Fremdwährung erfasst werden, ist die Angabe des Währungsschlüssels und ggf. des Umrechnungskurses sowie des Umrechnungsdatums relevant. Das Feld Referenz enthält eine Referenzbelegnummer zur Erfassung der Belegnummer externer Belege (z. B. der Bank). In das Feld Belegkopftext können Erläuterungen eingetragen werden, die für den gesamten Beleg gültig sind. Das Feld Belegart steuert die Buchung des Belegs. Auf diese Weise ist es möglich, Geschäftsvorfälle zu unterscheiden. Anhand der Belegart kann sofort erkannt werden, um welche Art von Geschäftsvorfall es sich handelt. Dies ist z. B. bei der Anzeige der Einzelposten eines Kontos von Bedeutung. Außerdem bestimmt die Belegart, welche Kontoarten (Personen- bzw. Sachkonten) gebucht werden können und welche Belegnummern vergeben werden. In dem dargestellten Beispiel steht das Kürzel SA für einen Sachkontenbeleg. Im SAP ERP-System besitzt jede Belegart einen eigenen Nummernkreis, aus dem für j­eden neuen Beleg eine Nummer gewählt wird. Nachdem der Belegkopf eingetragen ist, sind die einzelnen Belegpositionen der Buchung zu definieren. Dabei sind für jede Position die folgenden Parameter zu definieren: • Die Nummer des Sachkontos, das bebucht werden soll, • die Buchungsart, und • den zu buchenden Betrag.

10.2  Sektorneutrale Anwendungen

223

Abb. 10.23  Prozess der Sachkontenbuchung als BPMN-Modell

Sachkontenbuchung ist durchzuführen

Sollbuchungen erfassen

Habenbuchungen erfassen

Buchungskreise sind erfasst

Konten sind erfasst

Beträge sind erfasst

Saldo prüfen

Saldo ist Null

Saldo ist ungleich Null

Beleg buchen

Sachkontenbeleg ist gebucht

Die Angabe der gewünschten Buchungsart und des betroffenen Sachkontos erfolgt bereits nach Eingabe des Belegkopfs. Im Fußbereich des Dialogs wird der Buchungsschlüssel (Bschl) sowie die Sachkontonummer eingegeben. In diesem Fall wird der Buchungsschlüssel 40 gewählt. Das betroffene Konto mit der Kontonummer 100000 steht dabei für

224

10  Anwendungen in ERP-Systemen

Abb. 10.24  Belegkopf einer Sachkontenbuchung © Copyright 2018. SAP SE. Alle Rechte vorbehalten

das Bankkonto des Unternehmens. Der Buchungsschlüssel gibt an, wie eine Belegposition im System zu buchen ist. Der Buchungsschlüssel steuert: • Welche Kontenarten (Kreditoren-, Debitoren-, Sach-, Anlage- und Materialkonten) gebucht werden, • ob eine Soll- oder Habenbuchung durchgeführt wird, und • ob die Buchung umsatzwirksam ist. Abb. 10.25 liefert einen Auszug aus den verfügbaren Buchungsschlüsseln. Beispielsweise kennzeichnet der Buchungsschlüssel 40 eine Sollbuchung, der Buchungsschlüssel 50 eine Habenbuchung. Zur Vervollständigung der Buchung ist in einem weiteren Dialog die erste Belegposition zu definieren (s. hierzu Abb. 10.26). Hier wird zunächst der Betrag von 10.000 € für die Sollbuchung eingegeben und die gewünschte Kontierung gewählt. Dabei kann die Buchung auf unterschiedliche Bezugsobjekte kontiert werden, wie beispielsweise einen Geschäftsbereich, eine Kostenstelle oder einen Kundenauftrag. Im Feld Steuer rechnen kann bei steuerrelevanten Vorgängen die Berechnung der Umsatz- bzw. Vorsteuer aktiviert werden. Das Valutadatum kennzeichnet den Tag der Wertstellung des gebuchten Betrags. Nach Erfassung der Sollbuchung ist außerdem der Buchungsschlüssel und das Konto für die nächste Belegposition einzugeben. In Abb. 10.26 wird der Buchungsschlüssel 50 (Habenbuchung) sowie das Konto 101000 (Alternatives Bankkonto) gewählt.

10.2  Sektorneutrale Anwendungen

225

Abb. 10.25  Liste der Buchungsschlüssel (Auszug) © Copyright 2018. SAP SE. Alle Rechte vorbehalten

Die Erfassung der zweiten Sachkontenposition wird in Abb. 10.27 dargestellt. In diesem Dialog wird eine Habenbuchung von 10.000 € auf dem alternativen Bankkonto spezifiziert. Auch hier können entsprechende Kontierungen vorgenommen werden. Um den Saldo der beiden Belegpositionen zu überprüfen, kann die Belegübersicht aktiviert werden. In der Belegübersicht werden der Belegkopf und alle erfassten Belegpositionen zur Buchungskontrolle angezeigt (s. Abb. 10.28). Wenn alle Belegpositionen vollständig und in korrekter Form eingegeben wurden, ist der Beleg zu buchen. Wird der Anwender bei der Eingabe des Belegs unterbrochen oder fehlen noch einzelne Kontierungsdaten, unterstützt SAP ERP das Parken (Vorerfassen) von Belegen. Vorteilhaft ist, dass die einzelnen Belegpositionen bereits für zeitnahe Auswertungen zur Verfügung stehen, ohne dass die Buchung abschließend erfolgt ist. Um die Umsetzung der vorgenommenen Buchungen zu überprüfen, kann in einem anschließenden Schritt die Einzelpostenanzeige der betroffenen Konten aufgerufen werden.

226

10  Anwendungen in ERP-Systemen

Abb. 10.26  Erfassung der ersten Sachkontenposition © Copyright 2018. SAP SE.  Alle Rechte ­vorbehalten

Abb. 10.27  Erfassung der zweiten Sachkontenposition © Copyright 2018. SAP SE. Alle Rechte vorbehalten

10.2  Sektorneutrale Anwendungen

227

Abb. 10.28  Belegübersicht © Copyright 2018. SAP SE. Alle Rechte vorbehalten

Für fehlerhaft gebuchte Belege besteht die Möglichkeit, eine Stornierung durchzuführen oder Teile des Belegs abzuwandeln. Die dargestellte Vorgehensweise stellt den grundsätzlichen Ablauf bei der Erfassung und Buchung von Belegen dar. Für periodisch wiederkehrende Geschäftsvorfälle werden vom System verschiedene Automatisierungsmöglichkeiten angeboten. Beim Buchen mit Referenzbelegen wird ein bereits gebuchter Beleg als Vorlage genutzt. Das System kopiert diesen Beleg und erlaubt dem Anwender die freie Bearbeitung der kopierten Belegpositionen. Außerdem können beim Kopieren eines Referenzbelegs automatisch Umkehrbuchungen erzeugt werden. Dabei wird für jede Belegposition der Originalbuchungsschlüssel durch den entsprechenden Stornobuchungsschlüssel ersetzt. Für alle Belegpositionen wird hierdurch die Zugehörigkeit zur Soll- bzw. Habenseite des Kontos geändert. Um periodische Kontierungen (z. B. das Aufteilen von Beträgen auf verschiedene Buchungskreise oder Sachkonten) zu vereinfachen, werden Kontierungsmuster verwendet. Ein Kontierungsmuster ist eine Schablone für die Belegerfassung, die eine beliebige Anzahl von Sachkontenpositionen enthält. Diese Positionen müssen nicht vollständig sein und können vom Anwender nachträglich ausgefüllt werden. Außerdem können Äquivalenzziffern vergeben werden, sodass bei Verwendung eines Kontierungsmusters ein bestimmter Gesamtbetrag in einem vordefinierten Verhältnis auf die einzelnen Belegpositionen verteilt wird. Fallen periodisch wiederkehrende Geschäftsvorfälle an (z. B. Mietzahlungen), können Dauerbuchungen vorgenommen werden. Bei dieser Art von Buchung bleiben der

228

10  Anwendungen in ERP-Systemen

Buchungsschlüssel, die Kontonummern und bei Bedarf auch der Betrag gleich. Diese Parameter werden in einen zeitlich terminierten Dauerbeleg eingegeben. Die Terminierung kann in einem bestimmten Ausführungsrhythmus erfolgen, bei dem die Zeitspanne in Monaten bzw. Tagen zwischen den Buchungen definiert wird. Für Dauerbuchungen, die nicht rhythmisch erfolgen, kann ein gesonderter Ausführungsplan vorgegeben werden, der die relevanten Termine enthält. Zur Information und Rechenschaftslegung über die Vermögens-, Finanz- und Ertragslage sind im Rahmen der Hauptbuchhaltung Abschlussarbeiten durchzuführen. Die Abschlussarbeiten werden unter SAP ERP zeitlich differenziert. So ist neben dem Jahresabschluss auch ein Monats- und sogar ein Tagesabschluss möglich. Die Abschlussarbeiten des Jahresabschlusses umfassen: • Die periodengerechte Abgrenzung der Aufwendungen und Erträge, • die Bestandsaufnahme und Bewertung der Forderungen und Verbindlichkeiten, und • das Erstellen der Bilanz und GuV-Rechnung. Der Jahresabschluss wird in zwei Phasen unterteilt. Wird im aktuellen Geschäftsjahr bereits eine Buchung für das neue Geschäftsjahr durchgeführt, ist die neue Buchungsperiode im System einzurichten und der Saldo vorzutragen. Dabei werden die GuV-Konten auf das Ergebnisvortragskonto und die Bestandskonten für die neue Buchungsperiode angelegt. Zu einem späteren Zeitpunkt können dann die Vorbereitungen zum Jahresabschluss durchgeführt und die Bilanz sowie die GuV-Rechnung erstellt werden. Nachdem dies ­geschehen ist, bietet sich die Archivierung der nicht mehr benötigten Belege an. Abb.  10.29 stellt ­einen Auszug aus einer Handelsbilanz dar, die mit SAP ERP erzeugt wurde.

Abb. 10.29  Auszug aus einer generierten Handelsbilanz © Copyright 2018. SAP SE. Alle Rechte vorbehalten

229

10.2  Sektorneutrale Anwendungen

Der Monatsabschluss dient zur Erstellung externer Berichte. Hierzu zählen neben der zum Monatsende auszugebenden Bilanz und GuV-Rechnung die jeweils auf Landesebene zu erstellenden Berichte und Erklärungen, wie z. B. die Umsatzsteuervoranmeldung und der Bericht über exportierte Güter gemäß der Außenwirtschaftsverordnung. Zur Dokumentation und Abstimmung der Buchungen, die während des Monats angefallen sind, können einzelne Berichte erzeugt werden. Zu diesen gehören das Grundbuch, das alle gebuchten Belege zeitlich ordnet, und die Saldenliste, die für selektierte Konten die aktuellen Salden enthält. Der Tagesabschluss umfasst diejenigen Tätigkeiten, die am Ende eines Geschäftstages durchgeführt werden müssen. Hierzu gehören das Drucken der angefallenen Korrespondenz mit den Geschäftspartnern und die Ausgabe des Belegjournals. Außerdem sollten zur vollständigen Dokumentation des Buchungsstoffs alle abgebrochenen Buchungen bzw. die noch nicht gebuchten Belege gelistet werden.

10.2.2.7  Funktionen der Kreditoren- und Debitorenbuchhaltung Die Kreditoren- und Debitorenbuchhaltung erfasst alle Belege, die Geschäftsvorfälle mit Geschäftspartnern abbilden. Dazu gehören typischerweise die in Tab. 10.3 dargestellten Fälle. Die Belege zeigen, dass es sich bei der Kreditoren- und Debitorenbuchhaltung um Prozesse handelt, die mit anderen Funktionsbereichen des Unternehmens verknüpft sind. So erhält die Debitorenbuchhaltung aus dem Funktionsbereich Vertrieb die Fakturierungsdaten und hat in Verbindung mit dem Cash Management zur Liquiditätsplanung beizutragen. Die Kreditorenbuchhaltung erhält aus dem Funktionsbereich Beschaffung (Procurement) die Daten über alle lieferantenbezogenen Geschäftsvorfälle und unterstützt durch das Management der Zahlungsdaten die Finanzflussrechnung des Cash Managements. Da es sich bei der Kreditoren- und Debitorenbuchhaltung um spiegelbildliche Prozesse handelt, wird an dieser Stelle nur auf die Debitorenbuchhaltung eingegangen, deren Funktionen in Abb. 10.30 dargestellt werden. Zu den zentralen Aufgaben der Stammdatenpflege gehören das Anlegen, Ändern, Anzeigen und Löschen der Debitorenkonten. Wie bei den Sachkonten der Hauptbuchhaltung können Debitorenkonten auch zum Buchen gesperrt werden. Dies ist beispielsweise dann erforderlich, wenn die Forderungen gegen einen Debitoren zweifelhaft werden und daher keine weiteren Geschäftsvorfälle mit diesem Debitor zugelassen werden sollen. Die Sperren können auch aus dem Funktionsbereich Vertrieb (Sales Order Management) verhängt werden. So kann beispielsweise der Vertrieb für einzelne Debitoren Auftrags-, Liefer- oder Tab. 10.3  Typische Belege der Kreditoren- und Debitorenbuchhaltung Kreditorenbuchhaltung Lieferantenrechnungen Gutschriften von Lieferanten Ausgehende Zahlungen an Lieferanten

Debitorenbuchhaltung Rechnungen an Kunden Gutschriften an Kunden Eingehende Zahlungen von Kunden

230

10  Anwendungen in ERP-Systemen Debitorenbuchhaltung Stammdatenpflege

Belege buchen

Kreditmanagement

Mahnwesen

Abb. 10.30  Funktionen der Debitorenbuchhaltung

Fakturasperren verhängen. Diese werden in der Debitorenbuchhaltung bei der Bearbeitung von Debitorenstammdaten entsprechend abgebildet. Der Bereich der Belegbuchung der Debitorenbuchhaltung wird hier auf die Basisbelege Rechnung und Zahlungseingang beschränkt. Im praktischen Geschäftsverkehr sind weiterhin besondere Problembereiche bei der Debitorenabwicklung zu beachten. Hierzu gehören beispielsweise die Wechselverwaltung und die Erfassung von Bürgschaften. Unter SAP ERP erfolgt die Erstellung von Debitorenrechnungen analog zur Sachkontenbuchung in der Hauptbuchhaltung. Die Bildschirmmasken werden dabei um spezifische Elemente erweitert, wie beispielsweise die Erfassung der Erlösschmälerungen (z.  B.  Skonti), Zahlungsbedingungen und Steuerkennzeichen. Abb.  10.31 liefert einen Auszug aus dem Funktionsumfang der Debitorenbuchhaltung. Die Erstellung einer Debitorenrechnung führt zu einer Sollbuchung auf dem Debitorenkonto und damit zu einer fälligen Forderung, die als offener Posten bezeichnet wird. Erfolgt der Zahlungseingang zum Ausgleich beispielsweise auf einem Bankkonto, so wird dieser Eingangsposten analog als geklärt gekennzeichnet. Als Ausgleichsvorgänge sind die folgenden Standardvorgänge definiert: • Zahlungseingang, • Lastschrift, und • Umbuchung. Der in Abb. 10.32 dargestellte Prozess zeigt ein BPMN-Modell über die einzelnen Teilaktivitäten, die im Rahmen der Debitorenrechnungserstellung zu durchlaufen sind. Ein ablauforganisatorisch effizienter Zahlungsausgleich ist dann möglich, wenn die Eingangszahlungen, die beispielsweise mit Bankauszügen belegt werden, mit den offenen Posten automatisch abgeglichen werden können. So müssen vom System automatisierte Korrekturbuchungen im Bereich der Erlösschmälerungen und im Umsatzsteuerbereich durchgeführt sowie der summarische Rechnungsausgleich erkannt werden. Ist der Debitor gleichzeitig Kreditor des Mandanten, kann auch eine Verrechnung mit eigenen ­Verbindlichkeiten stattfinden. Die Differenz beim Zahlungsausgleich ist vom System automatisch zu identifizieren und auf Zulässigkeit zu überprüfen. Unzulässige Zahlungsdifferenzen treten häufig aufgrund unterschiedlicher Skontofristen auf. Wird die Skontofrist vom Debitor überschritten und bei der Zahlung trotzdem Skonto angesetzt, ist eventuell eine Nachforderung zu erstellen, die sich wiederum als offener Posten auf der Sollseite des

10.2  Sektorneutrale Anwendungen

231

Abb. 10.31  Debitorenrechnung erstellen © Copyright 2018. SAP SE. Alle Rechte vorbehalten

Debitorenkontos niederschlägt. Ähnliche Probleme treten auch bei der Verwendung von Teilzahlungen oder Anzahlungen auf. Das Kreditmanagement zählt zu den periodischen Arbeiten der Debitorenbuchhaltung. Kunden weisen im Allgemeinen unterschiedlich hohe Bonitätsgrade auf. Aufgrund dieser Tatsache wird die Annahme von Aufträgen erheblich beeinflusst. Um das Risiko durch einen möglichen Zahlungsausfall zu reduzieren, wird im Bereich des Kreditmanagements häufig mit Kreditlimits gearbeitet, die auf Debitorenebene individuell vergeben werden können. Eine weitere periodische Funktion der Debitorenbuchhaltung ist das Mahnwesen. Vo­ raussetzung für ein effektives Mahnwesen ist das Erfassen von Fälligkeitsterminen für den Zahlungsausgleich. Diese können ggf. automatisch bei der Rechnungserstellung vom System generiert oder manuell vom Sachbearbeiter festgelegt werden. Die im Rahmen des Mahnwesens zu verarbeitenden Daten werden in Abb. 10.33 anhand eines Datenflussdiagramms (DFD) dargestellt. Wird ein Mahnlauf durchgeführt, selektiert das Mahnprogramm aus den Debitorenstamm- und Belegdaten alle fälligen Forderungen, also die offenen Posten. Diese werden vom Mahnprogramm in einen eigenen Mahnbestand übernommen, aus dem der Mahnvorschlag zusammengestellt wird. Aus diesem Mahnvorschlag kann der Anwender die tatsächlich zu mahnenden Debitoren auswählen. Soll ein Debitor nicht gemahnt werden, obwohl eine Forderung nicht fristgerecht ausgeglichen wurde, kann eine Mahnsperre verhängt werden. Auch können im Mahnbestand die erforderlichen Mahnstufen vergeben

232

10  Anwendungen in ERP-Systemen Rechnung an Debitor ist zu erstellen Debitor erfassen

Forderungs betrag erfassen

Buchungskreis bestimmen

anderer Buchungskreis ist betroffen

gleicher Buchungskreis ist betroffen

Gegenbuchungen erfassen

Erlösbuchung ist erfasst

Erlösschmälerung ist erfasst

Gegenbuch. über Kontierungsmuster erstellt

Steuerbuchung ist erfasst

Saldo prüfen

Saldo ist ungleich Null

Saldo ist Null Debitorenrechnung buchen Debitorrechnung ist erstellt

Abb. 10.32  Prozess zur Erstellung von Debitorenrechnungen als BPMN-Modell

10.2  Sektorneutrale Anwendungen

233

Debitorenstammdaten

Debitorenbelegdaten Mahnempfänger

Offene Posten

Mahnprogramm Fortschreibung der Mahnstufe

Mahnbestand

Mahntexte

Mahnbriefe

Druckprogramm

Mahnbescheide

Mahnliste

Legende:

Datenspeicher (Festplatte)

Verarbeitung

Liste

Datenfluss

Abb. 10.33  Datenflussdiagramm des Mahnwesens

werden, die vor Einleitung des gerichtlichen Mahn-/Zwangsvollstreckungs- bzw. Betreibungsverfahrens zu durchlaufen sind. Nach der Bearbeitung des Mahnvorschlags ist das Druckprogramm zu starten, bei dem standardisierte, unterschiedlich gestufte Mahntexte verwendet werden können. Das Druckprogramm generiert neben den Mahnungen auch eine Mahnliste, die zur internen Dokumentation des Mahn(ab)laufs benötigt wird. Um beim nächsten Mahnlauf eines Debitors die Mahnstufe erhöhen zu können, ist deren Fortschreibung in den Belegdaten des Debitors erforderlich. Bei Erreichen der höchsten Mahnstufe kann automatisch ein Mahnbescheid generiert werden. Um ein positionsspezifisches Mahnen zu ermöglichen, werden die Mahnstufen auf der Ebene der Belegpositionen erfasst.

234

10  Anwendungen in ERP-Systemen

10.2.2.8  Funktionen der Anlagenbuchhaltung Die zentralen Funktionen der Anlagenbuchhaltung zur Verwaltung von Sachanlagen werden in Abb. 10.34 dargestellt. Die Stammdatenpflege der Anlagenbuchhaltung verwaltet alle langfristig konstanten Anlagendaten. Ein Anlagenstammsatz für ein Objekt ist beim Zugang einer Anlage aufgrund von Eigenfertigung oder Kauf zu erstellen. Der Stammsatz enthält sowohl sachbezogene Daten als auch organisatorische Zuordnungen (z. B. Geschäftsbereich, Standort) und Bewertungsparameter für die Fortschreibung der Anlage. Dabei muss berücksichtigt werden, dass bei der Neuaufnahme von Einzelanlagen deren Zuordnung zu Anlagenkomplexen möglich ist. Auf diese Weise können Anlagenkomplexe integriert bewertet werden. Die Geschäftsvorfälle der Anlagenbuchhaltung lassen sich anhand der folgenden Phasen differenzieren: • • • •

Buchungen während des Baus der Anlage, Buchung bei Anlagenzugang, Buchungen während der Nutzungsphase der Anlage, und Buchungen bei Anlagenabgang.

Während der Nutzungsphase einer Anlage können durch bestimmte Geschäftsvorfälle Umbuchungen, Anlagentransfers und Nachaktivierungen erforderlich werden (z. B. beim Umbau einer Anlage). Eine konzerninterne Umbuchung der Anlage zwischen zwei Buchungskreisen (Gesellschaften) wird als Anlagentransfer bezeichnet. Dabei kann es sich um einen physischen Ortswechsel oder um eine rein organisatorische Unternehmensumgliederung handeln. Eine Nachaktivierung ist erforderlich, wenn Aufwendungen, die mit der Beschaffung oder Ingangsetzung der Anlage verbunden sind, nachträglich den Anschaffungskosten zugeschrieben werden müssen. Der Anlagenabgang kann durch Verkauf oder Verschrottung der Anlage erfolgen. Bei einem Verkauf wird bei der Buchung des Anlagenabgangs eine entsprechende Gegenbuchung auf einem Debitorenkonto oder einem Verrechnungskonto durchgeführt, um den damit verbundenen Geschäftsvorfall abzubilden. Außerordentliche Erträge (Aufwendungen) fallen an, wenn der Verkaufswert größer (kleiner) als der Restbuchwert ist. Zu den grundlegenden Funktionen der Anlagenbuchhaltung gehört die Planung und Durchführung von Abschreibungen im Zeitablauf (Abschreibungslauf). Die möglichen Abschreibungsarten werden differenziert in Normalabschreibung durch Werteverzehr im Rahmen des betrieblichen Leistungsprozesses, Sonderabschreibung durch wirtschaftspolitisch Anlagenbuchhaltung Stammdatenpflege

Buchungen

Abb. 10.34  Funktionen der Anlagenbuchhaltung

Abschreibungen

Dokumentation und Planung

10.2  Sektorneutrale Anwendungen

235

induzierte Rechtsnormen (z. B. in Form von Sonderabschreibungen für Umweltschutzanlagen) oder außerplanmäßige Abschreibungen durch dauerhafte Wertminderung. Die Basis für den Abschreibungslauf ist der Abschreibungsschlüssel, der anlagenindividuell zugewiesen wird. Abb. 10.35 liefert eine Übersicht über die Abschreibungsschlüssel, die innerhalb von SAP ERP zu einer länderspezifischen Tabelle, die als Musterbewertungsplan bezeichnet wird, zusammengefasst werden. Innerhalb des Abschreibungsschlüssels werden die internen Rechenschlüssel für die Normal- und Sonderabschreibung der Anlage definiert. Über die Customizing-­ Funktionalitäten von SAP ERP können diese internen Rechenschlüssel formulargestützt an die betrieblichen Anforderungen angepasst werden. Die relevanten Dokumente der Anlagenbuchhaltung sind in Deutschland das Anlagenverzeichnis gem. §  268, 2 HGB und das Verzeichnis geringwertiger Wirtschaftsgüter (GWG). Das Anlagenverzeichnis (Anlagengitter) dokumentiert alle Änderungen des Anlagevermögens innerhalb des Geschäftsjahres. Zur Unterstützung der Planung können Abschreibungsläufe auch für nachfolgende Geschäftsjahre simuliert werden. Auf diese Weise können geplante Abschreibungen und Buchwerte in die Entwicklung von Planbilanzen bzw. Plan-GuV-Rechnungen einfließen, die Instrumente des Controlling- bzw. Entscheidungsunterstützungssystems darstellen.

10.2.3 Internes Rechnungswesen Inhalt des internen Rechnungswesens eines Unternehmens ist die Kosten- und Leistungsrechnung. Eine ausführliche Darstellung des SAP-Systems findet sich bei (Grob und Bensberg 2005). Hier sollen nur einige grundlegende Eigenschaften des Systems erörtert werden.

Abb. 10.35  Musterbewertungsplan mit Abschreibungsschlüsseln © Copyright 2018. SAP SE. Alle Rechte vorbehalten

236

10  Anwendungen in ERP-Systemen

Bei der Kosten- und Leistungsrechnung stehen der unternehmensinterne Adressatenkreis und dessen Informationsbedarf im Vordergrund. Zur Deckung dieses Bedarfs werden die güterwirtschaftlichen Vorgänge des Unternehmens erfasst, bewertet und verdichtet. Der Geltungsbereich der Kosten- und Leistungsrechnung beschränkt sich somit auf den Bereich der betrieblichen Leistungserstellung und die damit verbundenen Faktorverbräuche. Für die Entwicklung eines Informationssystems zur Kosten- und Leistungsrechnung sind grundsätzlich keine Rechtsnormen zu beachten, da der unternehmensinterne Informationsempfänger im Mittelpunkt des Interesses steht. Nur in Spezialfällen sind für die Kostenrechnung besondere rechtliche Vorschriften anhängig. Ein solcher Fall ist beispielsweise bei der Kalkulation öffentlicher Aufträge gegeben. Die Stamm- und Bewegungsdatenverwaltung der Kosten- und Leistungsrechnung gliedert sich analog zu den Daten der Finanzbuchhaltung. Anzumerken ist, dass auch Buchungen auf kalkulatorischen Kostenartenkonten (z.  B. kalkulatorischer Unternehmerlohn) unter den Bewegungsdaten der Finanzbuchhaltung erfasst werden. Dieser Ablauf ist durch das SAP ERP zugrunde liegende Einkreissystem bedingt, bei dem Finanzbuchhaltung und Kosten- und Leistungsrechnung im Rahmen eines geschlossenen Abrechnungssystems abgewickelt werden. Beim sog. Zweikreissystem existieren zwei isolierte Abrechnungskreise, die entweder Spiegelbildkonten oder Übergangskonten erforderlich machen. Die Funktionen der Kosten- und Leistungsrechnung sind in Abb. 10.36 dargestellt. Die Kostenrechnung weist im Vergleich zur Leistungsrechnung in der Praxis üblicherweise eine höhere Komplexität auf. Im Folgenden wird deshalb nur auf das Teilgebiet Kostenrechnung eingegangen. Zur Erfüllung der in Abb. 10.36 aufgeführten Funktionen hat die Kostenrechnung sämtliche relevanten Geschäftsvorfälle zu identifizieren und im Rahmen einer Grundrechnung zu erfassen. Auf der Basis dieser Dokumentationsfunktion sind Kontrollen und Entscheidungsunterstützungen möglich. Abb. 10.37 stellt den Weg der Kostenverrechnung bei einem System der Teilkostenrechnung dar, bei dem ein Kostenträger nur mit den variablen Kosten belastet wird. Diese Verrechnungsstruktur bildet die logische Grundlage für die hier darzustellenden Abläufe. Die Aufgabe der Kostenartenrechnung besteht in der Erfassung und Gliederung aller angefallenen Istkosten sowie in der innerbetrieblichen Leistungsverrechnung. Bei der Nutzung des integrierten Rechnungswesens im Rahmen eines Einkreissystems ist in SAP ERP eine separate Erfassung der Kosten nicht erforderlich, da alle relevanten Geschäftsvorfälle automatisch auf den Kostenkonten gebucht werden. So führt beispielsweise jeder Verbrauchsvorgang der Materialwirtschaft zu einer Buchung auf dem entsprechenden Konto. Eine explizite Buchung von Kosten ist deshalb nur für Anders- und Zusatzkosten durchzuführen. Als Beispiel seien die kalkulatorischen Abschreibungen, die von den bilanziellen Abschreibungen aufgrund der unterschiedlichen Ziele des internen und externen Rechnungswesens differieren, angeführt. Es sei daran erinnert, dass die kalkulatorische Abschreibung unter dem Aspekt der Substanzerhaltung vom Wiederbeschaffungswert einer Anlage durchgeführt wird, während die bilanzielle Abschreibung auf den nominellen Anschaffungskosten basiert.

237

10.2  Sektorneutrale Anwendungen

Kosten- und Leistungsrechnung

Dokumentation

Kontrolle

Entscheidungsunterstützung

Bewertung von fertigen/ unfertigen Erzeugnissen

Leistungskontrolle

Kalkulation

Ermittlung von Selbstkosten für öffentliche Aufträge

Kostenkontrolle

Sortimentspolitik

Ermittlung von Konzernverrechnungspreisen

Abb. 10.36  Funktionen der Kosten- und Leistungsrechnung

Kostenartenrechnung („Welche Kosten sind angefallen?“)

Gemeinkosten

Kostenstellenrechnung („Wo sind die Kosten angefallen?“)

fixe Kosten variable Kosten Einzelkosten

Kostenträgerrechnung („Wofür sind die Kosten angefallen?“)

Leistungsrechnung

Betriebsergebnisrechnung

Abb. 10.37  Verrechnungsweg der Kosten auf Teilkostenbasis

Die Kostenstellenrechnung hat die in der Kostenartenrechnung erfassten primären Gemeinkosten verursachungsgerecht weiterzuverrechnen und bildet damit für das Istkostenrechnungssystem auf Vollkostenbasis, in dem auch die fixen Kosten auf Produkte verteilt

238

10  Anwendungen in ERP-Systemen

werden, das Bindeglied zwischen Kostenarten- und Kostenträgerrechnung. Leistungen, die von den Hilfskostenstellen für die Hauptkostenstellen erfolgen, werden dabei über periodenspezifische Bezugswerte abgerechnet. Die Aufgaben der Kostenstellenrechnung bestehen neben der Ermittlung von Gemeinkostenzuschlagssätzen für die Kalkulation in der Wirtschaftlichkeitskontrolle der Kostenstellen. Neben Zeitvergleichen (Ist-Ist-­ Vergleich) können im Rahmen von Budgetierungsrechnungen auch Soll-Ist-Analysen durchgeführt werden. Die Kostenträgerrechnung stellt die letzte Stufe des Verrechnungswegs der Kosten dar. Ihre Aufgabe besteht darin, die Selbstkosten von Produkten, Aufträgen, Projekten oder anderen Kalkulationseinheiten (Marktleistungen oder innerbetriebliche Leistungen) zu ermitteln. Neben der Ermittlung von Selbstkosten dient die Kalkulation der Ermittlung der Herstellungskosten zur Bewertung von unfertigen und fertigen Erzeugnissen. Die Kostenträgerstückrechnung wird durch das gewählte Fertigungsverfahren bestimmt. Tab.  10.4 liefert einen Überblick über die Kalkulationsverfahren. Das System SAP ERP unterstützt die angeführten Fertigungsverfahren durch geeignete Erweiterungen. So können beispielsweise auch komplexe Strukturen, wie sie bei der Projektfertigung (Großanlagen) auftreten, abgebildet werden. Da die Kosten- und Leistungsrechnung weniger standardisiert ist als die Finanzbuchhaltung, ist das Softwaresystem durch ein größeres Maß an Offenheit gekennzeichnet.

10.2.4 Nutzung des SAP Enterprise Portal Die Integration von ERP-Systemen und Onlinekanälen ermöglicht die elektronische Gruppenarbeit (CSCW) und die Abwicklung von Transaktionen. Das Internet stellt eine Reihe von Kommunikationsdiensten zur Verfügung, die den Austausch von Nachrichten zwischen Anbietern und Nachfragern ermöglichen. Als bekannteste Vertreter dieser Basisdienste sind neben elektronischer Post (E-Mail), Diskussionsforen (Newsgroups) und Dateitransfer (File Transfer Protocol, FTP) vor allem das Hypertext Transfer Protocol (HTTP) zu nennen (s. Glossar). Diese Basisdienste werden im Rahmen des World Wide Web (WWW) integriert und können über einen Webbrowser genutzt werden. Zu den konzeptionellen Grundlagen s. Abschn. 5.1 und zu den technischen Grundlagen s. Glossar. Das SAP Enterprise Portal ist ein Portal, das auf dem SAP Application Server basiert und Benutzern eine Infrastruktur (Portal Infrastructure) zur Verfügung stellt, die einen gesicherten, verschlüsselten Zugriff auf Anwendungen und Daten erlaubt. Diesem Zugriff ist ein Rollenkonzept zugrunde gelegt worden. Benutzer, die im SAP-System angelegt sind, ­können Tab. 10.4  Überblick über die Kalkulationsverfahren

Fertigungsverfahren Einzel- und Serienfertigung Massenfertigung Sortenfertigung Kuppelproduktion

Kalkulationsverfahren Zuschlagskalkulation Divisionskalkulation Äquivalenzziffernkalkulation Kuppelkalkulation

10.2  Sektorneutrale Anwendungen

239

gemäß der ihnen zugewiesenen Rollen (z.  B.  Marketingleiter, Lagerarbeiter) auf vordefinierte Daten und Anwendungen zugreifen. Dazu ist lediglich ein Webbrowser auf dem lokalen Computer des Benutzers nötig. Über ein Single Sign-on, das durch die bestehende Infrastruktur bereitgestellt wird, erfolgt der Zugriff auf Daten und Applikationen verschiedener Unternehmensanwendungen (Gómez et al. 2009, S. 388). Das Single Sign-on-Konzept weist den Vorteil auf, dass der Portalbenutzer sich nicht an jedes einzelne System, das er in seiner personalisierten Portalumgebung eingebunden hat, anmelden muss. Vielmehr wird er nach einer einmaligen Registrierung am Portal automatisch bei den erforderlichen Teilsystemen angemeldet. Um die Benutzerfreundlichkeit und die Handhabung des Portals zu erhöhen, wird vom SAP Enterprise Portal ein Look & Feel Service bereitgestellt, der die Darstellung und Handhabung verschiedener Systeme vereinheitlicht. Durch diesen Service entsteht für den Benutzer der Eindruck, alle Informationen und Anwendungen entstammten dem gleichen System. Die adressierten Benutzergruppen eines solchen Unternehmensportals sind nicht nur die Mitarbeiter des eigenen Unternehmens, sondern auch Kunden, Lieferanten und sonstige Geschäftspartner. Auf diese Weise entsteht eine geschlossene Benutzergruppe, die sowohl unternehmensintern als auch unternehmensübergreifend agieren kann (s. Abb. 10.38). Im Rahmen unternehmensübergreifender Geschäftsprozesse (Supply Chain Management, s. Abschn. 12.2.2) wird die Zusammenarbeit zwischen einem Unternehmen, seinen Zulieferern und Kunden durch ein solches Portal unterstützt. Durch die informationstechnologische Integration der Geschäftsprozesse können Kostensenkungspotenziale realisiert werden. So sind die Unternehmen in der Lage, individuelle Konditionen, den Lagerbestand des Lieferanten sowie den Lieferfortschritt einzelner Aufträge (Order Tracking) aktuell einzusehen. Lieferanten können ihren Kunden individuelle Kataloge per Internet zur Verfügung stellen und eine Onlinebestellung aus diesen Katalogen heraus ermöglichen. Nicht nur die Ausführung von Transaktionen über ein Portal ist möglich, sondern auch die Realisierung unternehmensinterner und -externer Gruppenarbeit (Collaboration). In virtuellen Gruppen wird internen und externen Personen die Möglichkeit zur Koordination von verteilten Geschäftsprozessen und verteilter Projektarbeit gegeben. Gruppen (z. B. Projektteams) können sich in virtuellen Räumen (Collaboration Rooms) zusammenfinden und die dort bereitgestellten Kollaborationsanwendungen nutzen. In Abb.  10.39 ist ein Beispiel eines individualisierten virtuellen Arbeitsplatzes eines Mitarbeiters zu sehen. Das zentrale Eingangsbild informiert den Benutzer über anstehende Aufgaben und stellt Verweise (Hyperlinks) zu wichtigen Webseiten innerhalb oder ­außerhalb des Portals zur Verfügung. Zudem besteht die Möglichkeit, Komponenten auf der Oberfläche zu integrieren, die Warnhinweise aus operativen Systemen enthalten oder über aktuelle Entwicklungen in Collaboration Rooms (z. B. neue Beiträge, aktuelle Dokumentenversionen, Einladungen zu Onlinetreffen) informieren. Zukünftig ist mit einer zunehmenden Nutzung von Portallösungen zu rechnen, die für die Nutzer eine personalisierte Onlinearbeitsumgebung bereitstellen.

240

10  Anwendungen in ERP-Systemen Lieferanten

Unternehmensportal

Unternehmen

Unternehmensprozesse

Kunden/Partner

Unternehmen

Engineering

Marketing

Produktion

CRM

Finanzen

Material u. Logistik

Training und Learning

Sales and Distribution

HR

unternehmensübergreifende Prozesse

Unternehmen

Engineering

Marketing

Produktion

CRM

Finanzen

Material und Logistik

Training und Learning

Kundenportal

Sales and Distribution

Lieferantenportal

HR

HR

Sales and Distribution

Engineering

Marketing

Produktion

CRM

Finanzen

Material u. Logistik

Training und Learning

unternehmensübergreifende Prozesse

Mitarbeiterportal Mitarbeiter

Abb. 10.38  Anwendergruppen von Unternehmensportalen (in Anlehnung an (Gurzki et al. 2004, S. 8))

Abb. 10.39  Personalisierte Sicht eines Mitarbeiters auf ein Unternehmensportal

10.3  Sektorspezifische Anwendungen

241

10.3 Sektorspezifische Anwendungen 10.3.1 Industriebetriebe 10.3.1.1  Architektur klassischer PPS-Systeme Die Anwendungsarchitektur für Industriebetriebe wird in der Literatur (Scheer 1997, S. 92 ff.) als Y-Modell dargestellt, dessen linker Ast mit der Produktionsplanung und -steuerung (PPS) vorwiegend betriebswirtschaftliche und dessen rechter Ast primär technische Funktionen enthält. Das Gesamtsystem wird auch als Computer Integrated Manufacturing (CIM)-Konzept bezeichnet (s. Abb. 10.40). Zunächst soll auf die Produktionsplanungsund -steuerungssysteme (PPS-Systeme) eingegangen werden. Dabei sind folgende Teilbereiche zu koordinieren (Adam 1998, S. 673 ff.): • Programmplanung, • Produktionsdurchführungsplanung, und • Bereitstellungsplanung. Zwischen diesen Teilbereichen bestehen vielfältige Abhängigkeiten, die dazu führen, dass für die operative Planung, Steuerung und Überwachung der Produktionsabläufe ein inte­ griertes Softwaresystem erforderlich ist. In der Betriebswirtschaftslehre werden zwei Planungsansätze diskutiert, um die Planung innerhalb und zwischen den beschriebenen Teilbereichen durchzuführen (Knolmayer 1990, S. 72 ff.). Hierbei handelt es sich um Modelle zur simultanen und zur sukzessiven Produktionsplanung und -steuerung. Erstere versuchen, eine integrierte Lösung der bisher als isoliert angesehenen Teilbereiche zu erzeugen, bei denen die Operations-­ Research-­Methode der Linearen Programmierung erforderlich ist. Indes sind Simultanplanungsmodelle wegen des hohen Informationsbedarfs und der damit verbundenen langen Optimierungszeiten praktisch selten sinnvoll einsetzbar. Für die Praxis ist daher ausschließlich das Sukzessivplanungskonzept als geeignet anzusehen. Innerhalb der sukzessiven Planung wird versucht, eine hierarchische Ordnung von Teilplänen aufzubauen, die das gesamte Planungsproblem sinnvoll zerlegt. Auf diese Weise wird die Planungskomplexität vermindert und das Planungsproblem handhabbar gemacht. Die Teilpläne werden innerhalb eines Stufenkonzepts erstellt und sukzessiv verfeinert. Häufig werden die einzelnen Stufen mehrfach durchlaufen, um mit verbesserten Informationen eine zy­ klische Planung durchzuführen. Das Sukzessivplanungskonzept bildet mit seinem Stufenkonzept gleichzeitig einen Ordnungsrahmen für Anwendungssoftware zur PPS.  Der Ordnungsrahmen stellt für die PPS-Software eine Architektur bereit, die in Abhängigkeit vom Detaillierungsgrad des Stufenkonzepts und der Integration in die bestehende Softwarearchitektur unterschiedliche Ausprägungen annehmen kann. Im Folgenden wird exemplarisch die Architektur klassischer PPS-Systeme erläutert (Adam 1998, S. 535 ff.). Die in Abb. 10.40 gezeigte E ­ inteilung orientiert sich an der zeitlichen Ausrichtung der Planung. Bei der Produktionsplanung

242

10  Anwendungen in ERP-Systemen

Abb. 10.40  Informationssysteme im Industriebetrieb (Scheer 1997, S. 93)

­ eträgt der Planungszeitraum eine oder mehrere Wochen. Die Produktionssteuerung hinb gegen weist wesentlich kürzere Planungszeiträume auf und ist, da sie als Realisation der Produktionsplanung anzusehen ist, dieser zeitlich nachgelagert. Die inhaltliche Detaillierung der Planung nimmt in den aufeinander folgenden Funktionen zu. Zwischen den einzelnen Funktionen der Planung und Steuerung erfolgt der Informationsaustausch über eine gemeinsame Grunddatenverwaltung. Diese wird im Idealfall durch eine integrierte Datenbank realisiert. In der Praxis wird jedoch häufig die Grunddatenverwaltung durch mehrere Datenbanken und entsprechende Programme zur Datenkonvertierung verwirklicht. Die erste Stufe innerhalb der Produktionsplanung ist die Produktionsprogrammplanung, die i.  d.  R. über einen längeren Planungshorizont verfügt. Das Ziel der Produktionsprogrammplanung ist die Primärbedarfsermittlung, bei der das Absatzprogramm bezüglich Art,

10.3  Sektorspezifische Anwendungen

243

Menge und Termin für eine bestimmte Planungsperiode festgelegt wird. Grundlage für diese Ermittlung sind Absatzprognosen und/oder bereits eingegangene Aufträge. Nebenbedingungen für die Planung sind technische und wirtschaftliche Restriktionen (z. B. Kapazitäten, Lagerbestände). Das Ergebnis der Produktionsprogrammplanung ist der Primärbedarf, der die Vorgabe für die Mengenplanung darstellt. Die Mengenplanung umfasst die Planungsaktivitäten, die für eine kostengünstige und termingerechte Materialbereitstellung zur Primärbedarfsdeckung notwendig sind. Aus dem Primärbedarf wird der Sekundärbedarf (Bedarf an Rohstoffen und unfertigen Erzeugnissen zur Erstellung des Primärbedarfs) und der Tertiärbedarf (Bedarf an Betriebs- und Hilfsstoffen) abgeleitet. Bei dem so ermittelten Sekundär- und Tertiärbedarf handelt es sich zunächst um den Bruttobedarf, der sich durch eine Lagerbestandsfortschreibung zu einem Nettobedarf umrechnen lässt. Die Ermittlung des Sekundärbedarfs kann bedarfs- oder verbrauchsgebunden erfolgen. Bei einer bedarfsgebundenen Planung muss zunächst eine stufenweise Auflösung der Stücklisten durchgeführt werden. Einer verbrauchsgebundenen Bedarfsplanung liegen regelmäßig Verbrauchswerte aus der Vergangenheit zugrunde. Basierend auf diesen Verbrauchswerten werden die zukünftigen Bedarfe prognostiziert. Beide Verfahren werden im Normalfall kombiniert, d. h., wertvolle oder selten benötigte Materialien werden bedarfsgebunden disponiert, während geringwertige oder häufig benötigte Materialien verbrauchsgebunden disponiert werden. Nach der eigentlichen Bedarfsermittlung kann evtl. eine Entscheidung über die Alternative Fremdbezug und/oder Eigenfertigung gefällt werden. Anschließend ist die Bestellterminplanung bzw. Bereitstellungsplanung sowie die Bestellmengenplanung bzw. Losgrößenplanung durchzuführen. Die Ergebnisse der Mengenplanung sind Einkaufs- und Fertigungsvorschläge, wobei letztere dazu dienen, Fertigungsaufträge zu generieren, die zur Termin- und Kapazitätsplanung heranzuziehen sind. Der Ablauf dieser Planung gliedert sich in die Schritte Durchlaufterminierung und Kapazitätsabgleich, Verfügbarkeitsprüfung sowie Kapazitätsterminierung. In der Durchlaufterminierung werden Fertigungsaufträge zu spätest möglichen retrograd zu ermittelnden oder frühest möglichen Zeitpunkten ohne ­Berücksichtigung von Kapazitätsgrenzen eingeplant. Die so terminierten Aufträge führen zu einer Kapazitätsnachfrage, die mit dem Kapazitätsangebot abzugleichen ist. Durch eine Verfügbarkeitsprüfung von Roh- und Hilfsstoffen sowie von benötigten Anlagen werden denjenigen Fertigungsaufträgen Freigabevermerke erteilt, die zu den geplanten Terminen zu realisieren sind. Eine anschließende Kapazitätsterminierung im Rahmen der Fein- oder Reihenfolgeplanung legt die Zeitpunkte und Fertigungsmodalitäten für die einzelnen Aufträge fest. Letztlich liefert die Termin- und Kapazitätsplanung von der Durchlauf- bis zur Kapazitätsterminierung die Feinterminierung für die Fertigungsveranlassung. Die Schnittstelle zwischen Produktionsplanung und Produktionssteuerung stellt die Auftragsfreigabe der Fertigungsaufträge dar. Dazu ist die Bereitstellung der für den jeweiligen Auftrag notwendigen Produktionsmittel und Auftragsunterlagen (z. B. Produktionsauftrag, Materialkarte) erforderlich. Nach der Verfügbarkeitsprüfung können diejenigen Aufträge freigegeben werden, die innerhalb eines Freigabehorizonts liegen.

244

10  Anwendungen in ERP-Systemen

Die Auftragsüberwachung befasst sich mit aktuellen Eingriffen in den laufenden Fertigungsprozess und der Kundenauftragssituation. Außerdem wird der Arbeitsfortschritt festgestellt, um über den aktuellen Zustand der Fertigung informiert zu sein. Dies erfolgt häufig unter Verwendung eines Betriebsdatenerfassungssystems (BDE-System).

10.3.1.2  Technische Komponenten Die Gesamtarchitektur umfasst neben dem primär wirtschaftlich ausgerichteten PPS eine Reihe von Komponenten zur Unterstützung der Technik eines Industriebetriebs. Im Folgenden sollen einige wichtige Teilgebiete kurz erörtert werden: • Computer Aided Design (CAD). CAD umfasst das computergestützte Entwerfen, Zeichnen und Konstruieren einschließlich der zugehörigen technischen Berechnungen. Hierbei werden ökonomische Fragen einbezogen und auch technische Alternativen bewertet, um zu einer effizienten Lösung zu gelangen. • Computer Aided Planning (CAP). Das CAP beinhaltet die rechnergestützte Arbeitsplanung, die sowohl eine konventionelle Planung (z. B. Materialbeschreibungen, technischer Fertigungsablauf) als auch eine Planung für NC- (Numeric Control) und DNC (Digital Numeric Control)-gesteuerte Fertigungsanlagen unterstützt. • Computer Aided Manufacturing (CAM). Unter CAM ist der Rechnereinsatz im Bereich der Fertigung (NC-Maschinen, Roboter) und der innerbetrieblichen Logistik zu verstehen, bei dem insbesondere der Materialfluss verbessert werden soll.

10.3.1.3  Integration Wesentlich für das CIM-Konzept ist die Verknüpfung der Software des ERP-Systems (insbesondere Finanzbuchhaltung, Kosten- und Leistungsrechnung, Auftragsabwicklung) mit der Produktionsplanung und -steuerung durch die Nutzung der technisch orientierten Verfahren (CAD, CAM, CAP) und durch den Zugriff auf eine einheitliche Datenbasis. Dadurch wird die Bedeutung einer integrierten Stammdatenbank für die beiden Bereiche des CIM-Konzepts deutlich (s. Abb. 10.41). Eine Integration der betriebswirtschaftlichen und technischen Perspektive auf Datenebene wird auch mit einem Produktdatenmanagement (PDM)-System angestrebt. Das System hat die Aufgabe, Daten über Produkte über den gesamten Lebenszyklus hinweg konsistent zu speichern, zu verwalten und im Unternehmen bereitzustellen (Schöttner 1999) sowie VDI-Richtlinie 2219). Als zentrales Element in einem PDM-System stellt sich das Produktmodell dar. Dabei handelt es sich um eine formale Beschreibung aller Daten zu einem Produkt über alle Phasen des Lebenszyklus hinweg. Hierfür stehen Normen zur Verfügung, wie etwa der Standard for the Exchange of Product Model Data (STEP), der in der ISO-Norm 10303 definiert ist. Das Zusammenwachsen von Teilsystemen zu einem einheitlichen betrieblichen IS ist auch in der Zukunft eine wesentliche Anforderung von Industriebetrieben.

10.3  Sektorspezifische Anwendungen Abb. 10.41 Datenintegration im CIM-Konzept (in Anlehnung an (Stahlknecht und Hasenkamp 2005), S. 363)

245

Produktionsprogramm

Materialwirtschaft

Stücklisten

CAD

Fertigungsplanung

Arbeitspläne

CAP

Fertigungssteuerung

Fertigungsaufträge

CAM

Erzeugnisse

10.3.2 Handelsbetriebe 10.3.2.1  Konzeptionelle Grundlagen Handelsunternehmen sind dadurch charakterisiert, dass sie die Güterströme zwischen Wirtschaftssubjekten organisieren und koordinieren. Durch die Überbrückung räumlicher, zeitlicher, qualitativer und quantitativer Diskrepanzen wird letztlich der Konsum von Gütern und Dienstleistungen ermöglicht. Die zentralen Funktionen des Handels beziehen sich somit auf die Beschaffung, Lagerhaltung und die Distribution von Gütern. Diese Funktionsbereiche werden unter dem Begriff der Warenwirtschaft subsumiert. Die IS des Handels, die den physischen Warenstrom und sämtliche damit verbundenen Prozesse abbilden, werden als Warenwirtschaftssysteme bezeichnet. Ein Referenzmodell, das die Architektur von Warenwirtschaftssystemen beschreibt, ist das von Becker und Schütte entwickelte Handels-H-Modell in Abb. 10.42 (zu Referenzmodellen s. Abschn. 10.1). Die zentralen Prozesse der Beschaffung und der Distribution werden in den äußeren Rechtecken des H-Modells erfasst. Eingebettet wird das dargestellte Warenwirtschaftssystem (das „H“) in den sektorunabhängigen Teil der Anwendungsarchitektur, der oben aus den entscheidungsunterstützenden Komponenten Unternehmensplanung, Executive Information System (EIS) und Controlling sowie unten aus den sonstigen operativen Systemen (z. B. Haupt- und Anlagenbuchhaltung) besteht. So stellen die Daten des Warenwirtschaftssystems z. B. die Basis für EIS dar. Dagegen liefern die operativen Systeme, wie Hauptbuchhaltung, Kosten- und Leistungsrechnung sowie Personalwirtschaft, relevante Daten für das Handels-H. Eine Besonderheit der Architektur besteht darin, dass es sich um ein dreidimensionales Modell handelt, das in Anlehnung an die ARIS-Architektur

246

10  Anwendungen in ERP-Systemen

Abb. 10.42  Das Handels-H-Modell (Becker und Schütte 2004, S. 42 ff.)

(Scheer 1997, S. 4 ff.) die Funktions-, Daten- und Prozesssicht als eigene Betrachtungsdimensionen erfasst und somit einen integrativen Beschreibungsansatz darstellt.

10.3.2.2  Funktionen Warenwirtschaftssysteme, wie sie beispielsweise von Kaufhaus- oder Supermarktketten eingesetzt werden, nutzen regelmäßig voll integrierte Kassensysteme (Point-of-Sale-­Systeme). So werden die Artikel an der Kasse durch einen Laserscanner über die globale Artikelidentnummer (Global Trade Item Number, GTIN) mengenmäßig erfasst. Dieser Datenerfassungsprozess löst bei einem integrierten Warenwirtschaftssystem automatisch weitere Ereignisse aus. So werden mittels GTIN aus den Artikelstammdaten die ­Artikelbezeichnung, der Preis und der Umsatzsteuersatz festgestellt und auf dem Kassenbeleg ausgedruckt. Die Mengendaten der abgesetzten Artikel werden an die Lagerhaltung weitergeleitet, um eine Fortschreibung der Bestandsmengen durchzuführen. Bei Unterschreitung des Mindestbestands (Meldemenge) wird automatisch die Bestellung des entsprechenden Artikels

10.3  Sektorspezifische Anwendungen

247

beim Lieferanten ausgelöst. Der Umsatz wird auf den Erlöskonten der Buchhaltung gebucht. Aggregierte Umsatzdaten stehen dann zeitnah für Auswertungen durch Berichtssysteme zur Verfügung. Für den Zweck von Warenkorbanalysen im Rahmen innovativer Controllingkonzepte (z.  B.  Data Mining, s. Abschn.  2.3.3.4) ist es jedoch erforderlich, die Belegdaten einzelner Kaufereignisse unverdichtet (elementar) zu speichern. So sind die verfügbaren Daten, die einzelne Kaufprozesse charakterisieren, in einem eigenen Datenpool abzulegen, der für analytische Zwecke aufbereitet werden kann. Zu diesen Daten gehören beispielsweise: • • • • • • •

Artikelbezeichnung, Artikelmenge, Preis und Rabatt, Kaufzeit und Datum, Kaufort (Filialkennung, Kassenkennung), Zahlungsart und -konditionen, sowie Kundennummer.

Abb. 10.43 liefert einen Überblick über den Datenfluss in einem integrierten Warenwirtschaftssystem.

10.3.3 Finanzdienstleister Finanzdienstleistungen (FDL) umfassen Dienstleistungen, die in Verbindung mit Finanzgeschäften stehen. Dazu zählen die von Bank- und Kreditinstituten sowie von Versicherungen erbrachten Leistungen, die Kundenprozesse mit überwiegend finanziellem Charakter (z.  B.  Alterssicherung, Zahlungsverkehr, Kredite, Vermögensanlage) durch Herstellung, Vermittlung/Handel, Integration, Beratung und/oder Abwicklung unterstützen. Da Finanzdienstleistungen primär aus Informationen bestehen, sind sie in hohem Maße für die Abbildung in IS geeignet. Traditionelle FDL-Unternehmen sind Banken und Versicherungen. Seit der Deregulierung des Finanzbereichs ab den 1980er-Jahren sind auch Nichtbanken, wie Handels- (z. B. Migros und Coop in der Schweiz) und Logistikunternehmen (z. B. die Post in verschiedenen Ländern) oder Pkw-Hersteller (z. B. VW, BMW, Daimler) im FDL-Bereich präsent. Weitere Impulse für Veränderungen gehen vom Aufkommen der Fintech-Unternehmen (Finanztechnologie, Financial Technology) seit etwa 2010 aus. Es handelt sich dabei häufig um Start-up-Unternehmen, die innovative IT-basierte Lösungen (z. B. mittels Social Media, Verschlüsselungstechnologien, Blockchain) an der Kundenschnittstelle anbieten. Für den Versicherungsbereich ist der Begriff Insurtech (Versicherungstechnologie) anzutreffen (Alt und Ehrenberg 2016). Ausgangspunkt zur Strukturierung der Anwendungen für FDL-Unternehmen bildet bei Banken häufig die Unterscheidung von Firmen- und Privatkunden. In den USA führt dies beispielsweise zu „Investment Banks“ für Firmenkunden einerseits und „Commercial

248

10  Anwendungen in ERP-Systemen

Warenkorb Datenerfassung über Laserscanner / RFID Artikelbezeichnung, Preise, USt.-Satz Artikelstamm

ele

rte gie gre tag wer ige ß mä aten D

re nta me ele aten D

me Da ntar ten e

POS-Kassenterminal

S

Kassenbeleg

me ng

enm

Umsatzerlöse

Data MiningProzess

ige

Da ten

H

Lagerbestand

Data Mining-Pool

Kunde

äß

Berichtswesen

automatische Bestellabwicklung

Abb. 10.43  Datenfluss in einem integrierten Warenwirtschaftssystem

Banks“ für Privatkunden andererseits. Im deutschsprachigen Bereich sind Universal-, Retail- und Privatbanken anzutreffen. Bei Universalbanken handelt es sich um große Institute (z. B. Deutsche Bank, Commerzbank), die mit ihrer breiten Produktpalette große Firmenkunden bis hin zu Privatkunden bedienen können. Retailbanken dagegen konzentrieren sich auf kleinere Firmenkunden sowie Privatkunden und besitzen ein tendenziell standardisiertes Leistungsangebot (z. B. Raiffeisenbanken, Sparkassen). Privatbanken schließlich fokussieren auf individualisierte Leistungen für vermögende Privatkunden (z. B. die Vermögensberatung). Zu ihnen zählen Großbanken wie UBS ebenso wie Kleininstitute (z. B. Berenberg). Obgleich sich für die einzelnen Banktypen spezifische Standardsoftwareanwendungen herausgebildet haben (z. B. Agree für Volks- und Raiffeisenbanken, OSPlus für Sparkassen, Finnova für Privatbanken, SAP für Universalbanken), unterstützen diese Softwareprodukte jeweils ähnliche Aufgabenbereiche (z. B. Kredite, Zahlungsverkehr) (s. Abb. 10.44).

10.3  Sektorspezifische Anwendungen Interne Prozesse

Finanzieren

249 Kundenprozesse

Zahlen

Anlegen

Kernbanken-AS Banksteuerung & Controlling Führungsprozesse

Vertriebsprozesse

Business Intelligence

Business Intelligence

Risikomanagement & Compliance

Risikomanagement & Compliance

Servicelebenszyklusmanagement

Servicelebenszyklusmanagement

Online Banking

Bankschalter

Beraterarbeitsplatz

Mobile App

Social Media

Contact Center

Ausführung/ Abwicklung

Kredite

Zahlungsverkehr

Transaktionsbezogene Prozesse

Rating

Karten

Kanalmanagement & CRM

Geldautomat

Kundenportal

Externe Berater

Mobile App

Beratung

Lebensversicherung

Nicht-Lebensversicherung

Wertpapiere Verwaltungshandlungen Handel

Verrechnung & Erfüllung Produktentwicklung

Transaktionsübergreifende Prozesse

Absichern

Kernversicherungs-AS Versicherungsteuerung&Controlling

Kanalmanagement & Customer Relationship Management (CRM)

Sicherheiten

Vorsorgen

Maklersystem

Bestandsmanagement Provisionsmanagement Schaden-/Leistungsmgmt. Produktentwicklung

Stammdatenmanagement

Rückversicherung

Portfoliomanagement

Policierung/Underwriting

Finanzinformationen & Marktforschung

Kontokorrent (In-/Exkasso)

Finanzplanung

Finanz-/Anlagenverwaltung Personalwesen

Unterstützungsprozesse

Finanz- und Rechnungswesen Dokumentenmanagement & Scanning Beschaffung

Abb. 10.44  Funktionsbereiche von FDL-Anwendungen (in Anlehnung an (Alt und Puschmann 2016, S. 157))

Im Versicherungsbereich ist zwischen Erst- und Rückversicherern zu unterscheiden. Während Erstversicherer das Geschäft mit Privat- und Firmenkunden abdecken, zielen die Produkte von Rückversicherern auf die Absicherung der Risiken von Erstversicherern und großen Firmenkunden. Versicherungsunternehmen haben ihre Anwendungen zunächst wie Banken selbst entwickelt. Erst in den vergangenen 20 Jahren haben sich Standardsoftwareprodukte von Unternehmen wie SAP und MSG herausgebildet. Eine wichtige Entwicklung stellt die Versicherungsanwendungsarchitektur (VAA) von mehreren im Gesamtverband der Deutschen Versicherungswirtschaft (GDV) vertretenen Versiche­ rungsunternehmen dar. Obgleich sich die VAA in der Praxis nicht wie erhofft etablieren konnte, so hat sie doch zu einem unternehmensübergreifenden Verständnis der grundsätzlichen Anwendungen in Versicherungsunternehmen beigetragen. Zusammenfassend lassen sich die Anwendungen für FDL-Unternehmen nach zwei Dimensionen strukturieren, wie in Abb. 10.44 gezeigt (Alt und Puschmann 2016): • Kundenprozesse in der horizontalen Dimension orientieren sich an den Bedürfnissen des Kunden und unterscheiden für den Bankbereich zwischen Finanzieren, Zahlen und Anlegen. Für den Versicherungsbereich stehen die Kundenprozesse Vorsorgen und Absichern im Mittelpunkt. Zusätzlich können Versicherungsprodukte wie Lebensversicherungen auch den Kundenprozess Anlegen betreffen. Sie deuten damit auf Überschneidungen von Versicherungen und Banken hin.

250

10  Anwendungen in ERP-Systemen

• Unternehmensprozesse in der vertikalen Dimension skizzieren die wesentlichen Geschäftsprozesse eines Finanzdienstleisters. Zu unterscheiden sind Führungs-, Leistungs- und Unterstützungsprozesse, wobei sich die Leistungsprozesse in Vertriebs- und Ausführungs-/Abwicklungsprozesse sowie transaktionsbezogene und -übergreifende Prozesse aufgliedern lassen. Eine Unterscheidung zwischen Banken und Versicherungen ist in der vertikalen Dimension nicht erforderlich. Die Anwendungsarchitektur eines großen Finanzdienstleisters umfasst häufig mehrere hundert Anwendungen, die traditionell größtenteils als Eigenentwicklungen historisch gewachsen und in komplexer Weise miteinander verknüpft sind. Die jüngeren Fintech-­ Unternehmen (z. B. Fidor, Friendsurance, Knip, Lending Club) setzen zwar ebenfalls auf Eigenentwicklungen, jedoch besitzen sie eine geringere Leistungsbreite und konzentrieren sich i. d. R. auf spezifische FDL, die noch wenig reguliert sind. Aufgrund der traditionell hohen Bedeutung von gesetzlichen Vorgaben (z. B. Berichtspflichten an Aufsichtsbehörden, Einhalten von Regelungen des Geldwäschegesetzes, Revisionsfähigkeit) und der hohen Übereinstimmung von Aufgaben bei den einzelnen FDL-Typen haben Standardsoftwaresysteme in den vergangenen 20 Jahren viele Eigenentwicklungen abgelöst. Die Vision einer gemeinsamen IT-Plattform über sämtliche Bereiche großer Finanzinstitute hat in der Praxis jedoch aufgrund der hohen Komplexität zu Problemen geführt, sodass sich für einzelne Bereiche auch weiterhin dedizierte Anwendungen finden (insbesondere zwischen Banken und Versicherungen), die über Schnittstellen bzw. Integrationslösungen zur Ermöglichung eines elektronischen Datenaustausches verbunden sind. Grundsätzlich unterscheiden Finanzdienstleister zwei Anwendungsbereiche: • Frontoffice-Anwendungen unterstützen Vertriebsprozesse zur Kundenberatung und -betreuung „vor Ort“, die in einer (physischen) Filiale ebenso wie im Call Center oder im Bereich der elektronischen Medien (Social, Online oder Mobile Banking) angesiedelt sein können. • Backoffice-Anwendungen bezeichnen die kundenfernen Anwendungen, die z.  B. die Abwicklung und Verwaltung von Krediten, Kapitalanlagen und Zahlungen vornehmen. Die Anwendungen besitzen Schnittstellen zur Bankenwertschöpfungskette, etwa anderen Spezialdienstleistern (z.  B. für das Scanning von papierhaften Belegen) oder Dienstleistern aus dem Interbankenbereich (z. B. Swift, Target, Finanzbörsen). Eine genauere Sicht auf die Anwendungen bietet Abb. 10.44. Sie zeigt als übergreifende Anwendung für den Bankenbereich das Kernbankensystem und für den Versicherungsbereich das Kernversicherungssystem, die jedoch in der Praxis im Funktionsumfang variieren. Konzeptionell handelt es sich bei beiden um integrierte betriebswirtschaftliche Anwendungen, welche die zentralen Prozesse ihrer Anwendungsdomäne abbilden. Während bei Kernbankensystemen zur Unterstützung der wesentlichen internen Prozesse Ausführung/Abwicklung sowie der transaktionsbezogenen Prozesse auf die Bereiche

10.3  Sektorspezifische Anwendungen

251

Zahlungsverkehr, Wertpapiere und Kredite ausgerichtete Softwarefunktionen Anwendung finden, so sind dies bei Kernversicherungssystemen unterstützende Softwarefunktionen in den Bereichen Lebensversicherung und Nicht-Lebensversicherung (Kranken-, Sach-, Haftpflicht-, Unfall- und Kfz-Versicherungen). Ausgehend von den Backoffice-­ Funktionalitäten in den Bereichen Ausführung und Abwicklung sowie den transaktionsbezogenen und -übergreifenden Prozessen haben Anbieter von Kernanwendungen sukzessive auch Funktionalitäten für die Führungs- und Vertriebsprozesse in ihr Portfolio aufgenommen. Nachdem spezialisierte Lösungen ein weitergehendes Leistungsspektrum aufweisen, setzen Finanzdienstleister in den Bereichen der Führungs-, Vertriebs- und Supportprozesse häufig separate Anwendungen ein, die sie dann über Schnittstellen mit dem Kernbankensystem integrieren. Vor allem größere Institute nutzen hierzu Integrationslösungen, die unter dem Begriff Enterprise Application Integration (EAI, s. Abschn. 9.2) firmieren und eine zentralisierte Schnittstellenverwaltung bereitstellen sowie mittels definierter Workflows für das Zusammenspiel der Anwendungen sorgen. Grundsätzlich sollte sich die Strukturierung von Anwendungen an fachlichen und weniger an technischen oder physischen Aspekten, wie z. B. „Filiale“ oder „Zentralrechenzentrum“, orientieren. Damit stehen längerfristig stabile Dimensionen wie Funktionalitäten, Datenverwendung und Verantwortlichkeiten im Vordergrund, auf denen Entwicklungs-, Integrations- und Architekturprojekte aufbauen können. Mögliche Ausnahmen entstehen, wenn Funktionen, Daten und Verantwortlichkeiten kanalspezifisch ausfallen (z. B. Social Media, Bankschalter in Abb. 10.44). Die IS-Architekturplanung (s. Abschn. 9.2) versucht gewachsene, und durch viele Überschneidungen und Lücken gekennzeichnete Anwendungslandschaften in Richtung einer „sauberen“ Zielarchitektur zu entwickeln. Dies ist z. B. durch Einführung geeigneter Standardsoftwarekomponenten sowie von Integrationsund Entkopplungsanwendungen zu erreichen. Eine solche Anwendungslandschaft besteht aus folgenden Komponenten: • Vertikale Anwendungen unterstützen produktspezifische Abwicklungsprozesse, die meist mit bestimmten Organisationsbereichen verbunden sind (z. B. Kredite, Zahlungsverkehr, Wertpapiere, Lebensversicherung, Nicht-Lebensversicherung). • Horizontale Anwendungen unterstützen produktübergreifende Zugangs- und Vertriebsprozesse, die an einen bestimmten Kanal gebunden sind, d. h. um bestimmte Funktionalitäten herum integriert sind (z. B. Vertriebsprozesse, transaktionsübergreifende Prozesse). • Analytische Anwendungen unterstützen Führungsprozesse durch Bereitstellung von aufbereiteten Informationen auf Basis von Daten aus operativen Anwendungen (z. B. Führungsprozesse, Kundensegmentierung). Integrationszentrierte Anwendungen, wie etwa Data Warehouse- (DWS) und Enterprise-Application-Integration-(EAI)-Anwendungen, stellen anwendungsübergreifende Verbindungen her. So entkoppeln DWS die operativen Anwendungen des Kernbanken-/versicherungssystem

252

10  Anwendungen in ERP-Systemen

von analytischen Anwendungen (Analysewerkzeugen), indem sie Daten aus Geschäftsvorfällen historisieren und integrieren, um damit eine konsistente Entscheidungsgrundlage herzustellen. EAI entkoppeln operative Anwendungen, indem nicht mehr bilaterale Schnittstellen zwischen einzelnen Anwendungen erforderlich sind, sondern eine zentralisierte EAI-Plattform die notwendigen Formatumwandlungen und Weiterleitungen zwischen den Anwendungen vornimmt.

10.3.4 Telekommunikationsdienstleister Die weitgehende Liberalisierung der Telekommunikationsmärkte gegen Ende der 90er-­ Jahre hat dazu geführt, dass dieser Sektor – der zumindest in Europa lange Zeit als natürliches Monopol betrachtet wurde – einen gravierenden Transformationsprozess durchlaufen hat (Fuß 2010, S.  71  ff.). So existiert mittlerweile eine Vielzahl von Anbietern für Telekommunikationsdienste, die den Austausch von Informationen durch Einsatz nachrichtentechnischer Systeme zum Ziel haben (Lenhard 2009, S. 59 ff.). Zu diesen Diensten ist nicht nur die traditionelle Sprachtelefonie über das Telefonnetz zu zählen, sondern auch Mobilfunk- und Internetdienste. Neben der zunehmenden Wettbewerbsintensität hat auch der anhaltende technologische Fortschritt dazu beigetragen, dass die Margen auf Telekommunikationsmärkten kontinuierlich sinken und in dieser Branche ein hoher Kostendruck besteht (Czarnecki und Dietze 2017, S. 21–23). Diese Entwicklung wird auch durch die Entwicklung der Mobilfunkgeneration 5G stimuliert, mit der deutlich höhere Datenraten möglich sind als mit der Vorgängergeneration 4G (LTE+). Zudem stehen Telekommunikationsdienstleister vor der Herausforderung, zur Erfüllung der stetig wachsenden Kundenanforderungen im Rahmen von Dienstleistungsketten bzw. -netzwerken eng zusammenzuarbeiten und dabei auf gemeinsame, möglichst standardisierte Prozesse und Schnittstellen zurückzugreifen. Dies gilt insbesondere für moderne Triple Play-Angebote, mit denen Dienste für Festnetz-Telefonie, Breitband-Internet und digitales Fernsehen verbunden werden. Die Integration solcher Dienste setzt aus Anbietersicht flexible Anwendungsarchitekturen voraus, die nicht wie traditionell üblich einzelne Telekommunikationstechnologien oder Geschäftsbereiche fokussieren, sondern die betrieblichen und technischen Prozesse über die gesamte Wertschöpfungskette – d. h. vom Endgerätehersteller bis hin zum Kunden – durchgängig unterstützen. Aufgrund des hohen Kostendrucks kommt der Realisierung von Kostensenkungspotenzialen durch weitestgehende Prozessautomatisierung hohe Bedeutung zu. Als Basis zur Identifikation und Systematisierung relevanter Prozesse von Telekommunikationsdienstleistern hat die enhanced Telecom Operations Map (eTOM) weite Verbreitung gefunden (Czarnecki und Dietze 2017, S.  78  ff.). Dabei handelt es sich um einen Ordnungsrahmen für Geschäftsprozesse (Business Process Framework), der vom TeleManagement Forum (TMF) als Verband der Telekommunikationsindustrie entwickelt worden ist. Einen Überblick über das eTOM-Modell liefert Abb. 10.45.

10.3  Sektorspezifische Anwendungen

253

Customer

Operations

Strategy, Infrastructure & Product Strategy & Commit

Infrastructure Product Lifecycle Lifecycle Management Management

Operations Support & Readiness

Fulfillment

Assurance

Billing

Marketing & Offer Management

Customer Relationship Management

Service Development & Management

Service Management & Operations

Resource Development & Management (Application, Computing and Network)

Resource Management & Operations (Application, Computing and Network)

Supply Chain Development & Management

Supplier / Partner Relationship Management

Enterprise Management Strategic & Enterprise Planning

Enterprise Risk Management

Financial & Asset Management

Enterprise Effevtiveness Management

Stakeholder & External Relations Management

Knowledge & Research Management

Human Resources Management

Abb. 10.45  Enhanced Telecom Operations Map (eTOM) nach (ITU 2007, S. 12)

Im eTOM-Modell werden drei Hauptprozessgruppen für Telekommunikationsdienstleister unterschieden (Ashford und Gauthier 2009, S. 5): • Managementprozesse des Unternehmens (Enterprise Management), • Entwicklungsprozesse (Strategy, Infrastructure & Product), und • operative Prozesse des Betriebs (Operations). Die erste Hauptprozessgruppe Enterprise Management umfasst Tätigkeiten, die generell – d. h. unabhängig vom betrachteten Sektor – zur Führung eines Unternehmens erforderlich sind und in jedem größeren Unternehmen anzutreffen sind. Hierzu gehören einerseits übergeordnete Prozesse, wie z. B. die strategische Unternehmensplanung und Unternehmensentwicklung (Strategic & Enterprise Planning). Andererseits sind in dieser Gruppe auch solche Tätigkeiten zu finden, die üblicherweise als flankierende bzw. unterstützende Wertschöpfungsprozesse gelten. Darunter fallen z. B. Prozesse wie die der Personalführung (Human Resources Management) und des Finanzmanagements (Financial & Asset Management).

254

10  Anwendungen in ERP-Systemen

Die zweite Hauptprozessgruppe hat solche Tätigkeiten zum Gegenstand, die der langfristigen, lebenszyklusübergreifenden Entwicklung und Ausrichtung von Strategien, In­ frastrukturen sowie Produkten dienen (Strategy, Infrastructure & Product). In diesem Bereich findet auch eine vertikale Aufgliederung in unterschiedliche Ebenen statt, die auf unterschiedliche Phasen der Wertschöpfung vom Lieferanten bis hin zum Kunden Bezug nehmen: • Die unterste Ebene umfasst den strategischen Einkauf bzw. die Beschaffung notwendiger Ressourcen (Supply Chain Development & Management). • Die beschafften Ressourcen fließen dem Unternehmen zu und werden als Komponenten zum Aufbau von Kommunikationsnetzen eingesetzt (Resource Development & Management). Typische Komponenten sind z. B. systemtechnische Elemente wie Router, Ports und Einschubkarten. • Im Bereich Service Development & Management findet die Entwicklung von Services statt, die als funktionelle Einheiten zur Abdeckung von Kundenanforderungen dienen. Typische Services von Telekommunikationsdienstleistern sind z. B. Internetzugänge, Telefonanschlüsse, Web Space und E-Mail-Adressen. • Auf der Ebene Marketing & Offer Management werden die Services schließlich zu Produkten gebündelt und als kundengerichtete Leistungsangebote am Markt platziert. Diese vertikale Aufgliederung wird auch in der Hauptprozessgruppe Operations berücksichtigt. Gegenstand dieser Gruppe sind die operativen Prozesse der Leistungserstellung, deren inhaltlich-funktionalen Schwerpunkte in der horizontalen Aufgliederung zum Ausdruck gelangen. Neben Supportaktivitäten (Operations Support & Readiness) gehören hierzu vor allem Prozesse zur Belieferung (Fulfillment), Qualitätssicherung (Assurance) und Fakturierung (Billing). Diese drei Prozessbereiche bilden die sog. FAB-Prozesse, die direkt mit dem Kunden interagieren und im operativen Tagesgeschäft von Telekommunikationsdienstleistern von erheblicher Bedeutung sind: • Fulfillment-Prozesse beinhalten solche Tätigkeiten, mit denen bestellte Produkte bzw. deren Services konfiguriert und anschließend an den Kunden bzw. Endanwender ausgeliefert bzw. geschaltet werden. • Assurance-Prozesse stellen sicher, dass die produktspezifischen Services zur Verfügung stehen und den vertraglichen Vereinbarungen (Service Level Agreements) entsprechen. Hierzu kann z. B. ein proaktives Performance Monitoring erfolgen, das die Verfügbarkeit der zugesicherten Services kontinuierlich überwacht. • Billing-Prozesse haben die Erstellung und den Versand von Rechnungen zum Inhalt. In diese Fakturierungsprozesse können auch mengenorientierte Daten wie z.  B. ­übertragene Datenvolumina einfließen, die auf der Ressourcen- bzw. Netzwerkebene erhoben worden sind und zur Tarifermittlung dienen.

10.3  Sektorspezifische Anwendungen

255

Der Überblick über das eTOM-Modell zeigt, dass Telekommunikationsdienstleister über Anwendungen verfügen müssen, die sowohl strategische als auch operative Aufgabenstellungen prozessorientiert unterstützen bzw. automatisieren können. In der Telekommunikationsindustrie werden üblicherweise Operations- und Business-Support-Systeme unterschieden (Czarnecki 2013, S. 98): • Operations-Support-Systeme (OSS) dienen der Unterstützung von Betrieb und Wartung der Telekommunikationsinfrastruktur. Hierzu gehören Elemente der Linientechnik, wie etwa Erdkabel und Verteiler, sowie Komponenten der Systemtechnik zur Vermittlung und Dienstbereitstellung. • Business-Support-Systeme (BSS) werden eingesetzt, um kundenorientierte Prozesse zu unterstützen. Hierzu gehören insbesondere Aufgabenstellungen des Vertriebs und des Kundenservice, sodass der Kern eines BSS durch ein CRM-System gebildet wird (s. Abschn. 12.2.1). Ein Problem beim Aufbau solcher Anwendungsarchitekturen bilden bestehende Altsysteme (Legacy Systems), die im Hinblick auf die zugrundeliegenden Netze häufig hersteller- und technologiespezifische Lösungen darstellen und sich nur schwierig in eine moderne, weitgehend technologieneutrale Anwendungslandschaft integrieren lassen. Aufgrund des technologischen Fortschritts und der zunehmenden Konvergenz von Informations- und Kommunikationstechnologien ist damit zu rechnen, dass die Entwicklung von Anwendungen und Netzen bei Telekommunikationsdienstleistern künftig integriert erfolgen wird. Auf diese Weise können nicht nur die Betriebskosten für Netze verringert werden, sondern auch neue Telekommunikationsdienstleistungen nach den dynamischen Anforderungen des Kunden gestaltet und mithilfe der Anwendungen zeitnah im Markt realisiert werden.

10.3.5 Energiewirtschaft Aufgrund der Energiewende befindet sich die deutsche Energiewirtschaft derzeit in einem Transformationsprozess, der durch neue Aufgaben und Herausforderungen gekennzeichnet ist. Durch die zunehmende Stromerzeugung aus erneuerbaren Energiequellen entsteht die Herausforderung, Produzenten und Konsumenten über die Marktprozesse zu integrieren. Im Zuge dieser Integration ist einerseits das Phänomen zu handhaben, dass Haushalte sowohl als Produzenten als auch als Konsumenten von Energie auftreten können und somit im Energiemarkt als Prosumer agieren. Andererseits wird die Energieproduktion künftig nicht mehr durch zentrale, grundlastfähige Großkraftwerke gekennzeichnet sein, sondern durch zahlreiche dezentrale Anlagen, die eine stark schwankende, zeit- und wetterabhängige Leistung aufweisen. Die für den Energiesektor wesentlichen Prozesse und Akteure werden in Abb. 10.46 dargestellt.

256

10  Anwendungen in ERP-Systemen

Börslicher Energiehandel

OTC-Geschäft Kauf/Verkauf

Marktprozesse

Börse (EEX)

Broker Kauf/Verkauf

Kapazitätshandel

Händler

Kauf/Verkauf v. Kapazitäten

Bilateraler Handel und Abwicklung

Finanzielle & physische Abwicklung

Payment Netting

ClearingBank

Clearinghaus Allokation von Kapazität

Übertragungsnetzbetreiber (ÜNB)

Anbieter von Regelenergie Laststeuerung

Andere ÜNB

Stromerzeuger

Verteilnetzbetreiber Messstellenbetreiber

Legende: Trading

Physische Abwicklung

Finanzielle Abwicklung

Abrechnung

Prosumer

Verbrauchserfassung

Regelenergie

Abb. 10.46  Prozesse im Energiemarkt nach (Merz 2016)

Aus der Darstellung wird deutlich, dass Energiehandelstransaktionen entweder zentral über die Börse – z. B. die European Energy Exchange in Leipzig (EEX) – oder außerbörslich als Folge einer Direktvermarktung (als OTC-Geschäft, Over the Counter) zustande kommen. Im europäischen Energiemarkt existiert eine Vielzahl von Brokern, die entsprechende Handelsplattformen für Energiegeschäfte anbieten. Die Abwicklung des börslichen Energiehandels wird von einem Clearinghaus übernommen. Die Aufgabe des Clearinghaus besteht darin, als neutraler, zentraler Kontrahent (Central Counterparty, CCP) zwischen den Vertragspartnern für die Erfüllung der Geschäfte zu sorgen. So übernimmt z.  B. die European Commodity Clearing (ECC AG) als Tochtergesellschaft der EEX die Abwicklung von Geschäften mit Energie bzw. energienahen Produkten. Zu diesem Zweck werden etwa die gegenseitigen Forderungen und Verbindlichkeiten von Anbietern und Nachfragern gegeneinander aufgerechnet (Netting) und schließlich finanziell ausgeglichen.

10.3  Sektorspezifische Anwendungen

257

Darüber hinaus stellt das Clearinghaus auch Dienste für das Risikomanagement zur Verfügung, indem z. B. das Ausfallrisiko über die Hinterlegung von Sicherheitsleistungen reduziert wird. Zur physischen Abwicklung der Transaktion ist die gehandelte Strommenge über Netze zu liefern, die durch Netzbetreiber zur Verfügung gestellt werden. Während Übertragungsnetzbetreiber (Transmission System Operator, TSO) die Höchstspannungsnetze zur überregionalen Energieübertragung operativ betreiben, dient das Verteilnetz zur Anbindung von Endverbrauchern (z. B. private Haushalte, Unternehmen). Das Verteilnetz wird üblicherweise von Energieversorgungsunternehmen (EVU) betrieben, die die regionale Stromversorgung sicherstellen. Zur Koordination der Lieferprozesse erfolgt eine Fahrplananmeldung, mit der die Netzbetreiber über die aus den Handelstransaktionen resultierenden Stromlieferungen informiert werden. Die Produktion der erforderlichen Strommengen findet durch dedizierte Stromerzeuger bzw. Kraftwerke oder aber auch durch dezentrale Haushalte statt, die durch die Nutzung regenerativer Energiequellen als Prosumer auftreten. Die Verbrauchserfassung erfolgt durch entsprechende Messgeräte (z. B. Smart Meter), die von Messstellenbetreibern (MSB) installiert, betrieben und abgelesen werden. Diese Daten bilden schließlich auch die Abrechnungsgrundlage für den Verteilnetzbetreiber, der die verbrauchte Strommenge den Endverbrauchern in Rechnung stellt. In der Energiewirtschaft ist die Energieerzeugung und -verteilung mithilfe entsprechender Anlagen und Versorgungsnetze eng mit IS zur Messung, Regelung und Steuerung der technischen und ökonomischen Prozesse verknüpft (Brandt 2007): • Im Bereich der Energieerzeugung werden IS zur Überwachung und Steuerung der technischen Prozesse in den Kraftwerken eingesetzt, die generell als SCADA-Systeme (Supervisory Control and Data Acquisition) bezeichnet werden. • Zur Überwachung des Zustands der Übertragungs- und Verteilnetze müssen nicht nur Informationen über deren Topologie vorliegen, die z.  B. mithilfe von Geoinformationssystemen (GIS) verarbeitet werden, sondern auch über die ange­ schlossenen Kunden und deren aktuellen Strombedarf. Zu diesem Zweck werden Distribution-­Management-­Systeme (DMS) eingesetzt, die eine Überwachung der Stromverteilung auf der Basis von Echtzeitinformationen gewährleisten und bei Ausfall (Blackout) oder Unterbrechung der Energieversorgung für die Wiederherstellung sorgen (Outage Management). • Zum Energiehandel sind IS erforderlich, die den Zugriff auf die börslichen bzw. außerbörslichen Handelsplattformen gestatten, um die Marktentwicklung zu überwachen und Order zu platzieren. Darüber hinaus sind auch Funktionalitäten vorzusehen, die die Abwicklung von Energiehandelstransaktionen unterstützen, wie etwa die automatische Fahrplananmeldung und finanzielle Abwicklung. • Darüber hinaus benötigen Energieunternehmen IS zur Unterstützung der Vertriebs- und Abrechnungsprozesse. Da Strom als handelbares Produkt standardisiert ist und geringe Differenzierungspotenziale bietet, besitzen Stromkunden tendenziell eine hohe

258

10  Anwendungen in ERP-Systemen

­ echselbereitschaft (Krickel 2015). Infolgedessen müssen IS zur Kundengewinnung, W Kundenbindung und Optimierung des Kundenservice verfügbar sein (s. Abschn. 12.2.1). • Unter dem Begriff des Demand Side Management (DSM) wird die Steuerung der Stromnachfrage durch die Abnehmer verstanden (Häfner 2018). Insbesondere energieintensive Industrieunternehmen verfügen über eigene Beschaffungseinheiten für Energie und ggf. auch über dezentrale Anlagen zur Energieerzeugung und -speicherung. Zur Unterstützung von Beschaffungsentscheidungen sind daher IS zur Verbrauchserfassung und -prognose notwendig. Weitere Impulse erhalten IS in der Energiewirtschaft aktuell durch die Nutzung von Blockchain-Technologien (s. Abschn. 4.3.4). So können mithilfe einer Blockchain die Marktprozesse im Energiemarkt potenziell dezentralisiert werden und die Markteffizienz durch die sichere Einbindung der unterschiedlichen Akteure und Rollen gesteigert werden. Ein Beispiel hierfür bildet der dezentrale Handel mit Strom aus regenerativen Energiequellen, der prinzipiell durch Disintermediation von Energieversorgern, Händlern und Börsen direkt zwischen Anbietern und Nachfragern stattfinden kann. Mithilfe der Blockchain wird es möglich, direkte Handelstransaktionen (Peer-to-Peer-Transaktionen) mithilfe von Smart Contracts zu initiieren (Hukkinen et  al. 2017). Ein Smart Contract ist ein Programmcode, der auf einer Blockchain ausgeführt wird und digitale Güter oder Rechte zwischen mehreren Akteuren regelbasiert zuordnet (s. Abschn. 4.3.4). Ein vereinfachtes Beispiel für einen solchen Smart Contract zeigt Abb. 10.47. In diesem Smart Contract wird mithilfe von Wenn-Dann-Regeln gesteuert, wie selbst erzeugte Energie – etwa aus einem Windkraftwerk – zu handhaben ist. Für jede erzeugte Kilowattstunde (kWh) wird zunächst ein Token als Abrechnungseinheit erzeugt. Anschließend wird geprüft, ob die erzeugte Energie am Markt verkauft werden soll, oder aber einem Speicher zuzuführen ist. Diese Entscheidung erfolgt in Abhängigkeit vom aktuellen Strompreis, der z. B. über die Börse bereitgestellt wird. Das skizzierte Beispiel verdeutlicht, dass mithilfe der Blockchain-Technologie Marktprozesse im Energiesektor tendenziell automatisiert werden können. Die weitere Diffusion dieser Technologie hängt nicht nur von der Verbreitung von Smart-Meter-­Technologien ab, die eine zuverlässige und aktuelle Verbrauchserfassung gewährleisten, sondern vielmehr auch von der resultierenden Versorgungssicherheit für den Endverbraucher. WENN Stromeingang DANN Token erstellen

Der Smart Contract erzeugt automatisiert 1 Token je KW.

WENN Preis >= X DANN Verkaufen

Der Smart Contract prüft den aktuellen Stromprels und beauftragt ggf. elnen Verkauf.

WENN Preis < X DANN Speichern

Der Smart Contract prüft den aktuellen Stromprels und beauftragt ggf. den Strom einem Speicher zuzuführen.

Abb. 10.47  Vereinfachtes Beispiel für einen Smart Contract (Fiedler et al. 2016)

10.4  Einführung von ERP-Systemen als Standardsoftware

259

10.4 Einführung von ERP-Systemen als Standardsoftware 10.4.1 Vorgehensmodell zur ERP-Einführung Die Realisierung von ERP-Systemen erfolgt in der Regel auf Grundlage von Standardsoftwareprodukten, die am Softwaremarkt verfügbar sind. Dies bedeutet, dass keine IS selber entwickelt werden müssen (Individualentwicklung, s. Kap.  14), sondern entsprechende Standard-Anwendungssoftware einzuführen und anzupassen ist. Nach dem in diesem Buch verfolgten Mehr-Ebenen-Ansatz (s. Kap. 6) muss ein ERP-Einführungsprojekt zumindest an der Organisationsebene beginnen und kann darüber hinaus auch unternehmensstrategische Leitlinien berücksichtigen. Das Ziel einer ERP-Einführung ist es, die Standardsoftware an die Anforderungen des Unternehmens anzupassen. Bei der Einführung standardisierter ERP-Systeme treten daher Fragen des Vorgehensmodells, der Projektplanung und -steuerung sowie des Abgleichs von Soll- und Ist-Modellen in den Vordergrund. Diese Fragen sind zwar auch für die Individualentwicklung wichtig, werden aber meist durch die Suche nach neuen fachlichen Lösungen und deren optimaler Implementierung überlagert. Die Auswahlentscheidung einer ERP-Lösung sollte gründlich vorgenommen werden, da sie nur mit erheblichem personellen Aufwand und hohen Kosten wieder rückgängig gemacht werden kann. Da die Anschaffung von ERP-Lösungen häufig auch mit dem Kauf von Hardware verbunden ist, sollte diese auch mit in den Auswahlprozess einbezogen werden. Neben der lokalen Inhouse-Installation (On-Premises) besteht vermehrt auch die Möglichkeit, auf SaaS-ERP-Lösungen (s. Abschn. 4.4.3) zurückzugreifen, die per Public Cloud zur Verfügung gestellt werden. Ein projektorientiertes Vorgehensmodell für die ERP-Einführung zeigt Abb. 10.48. Ausgangspunkt der ERP-Einführung bildet die Phase der Initialisierung und Situationsanalyse, mit der zunächst die Projektziele und das Projektumfeld zu fixieren sind. Die ERP-Einführung betrifft meistens einen aufbau- und ablauforganisatorisch abgrenzbaren, betrieblichen Bereich, in dem die Einführung eines ERP-Systems erforderlich ist. Impulse hierfür können einerseits aus dem Unternehmensumfeld kommen (z. B. neue rechtliche Regularien) oder aber aus dem Unternehmen, wie beispielsweise durch strategische Initiativen (z.  B. funktionale Digitalisierungsstrategien). In dieser ersten Phase ist auch eine detaillierte Istanalyse zu leisten, um evtl. bereits bestehende ERP-Lösungen zu dokumentieren und bestehende Schwachstellen herauszuarbeiten. Zu diesem Zweck bietet sich die Istmodellierung der relevanten Unternehmensprozesse, der Aufbauorganisation und der Datenbestände (Stamm- und Bewegungsdaten, s. Abschn. 10.2.2.5) an. In der anschließenden Phase ist ein Sollkonzept zu erarbeiten und zu validieren, das die Anforderungen (s. Abschn. 7.2) an die künftige ERP-Lösung fixiert und Auskunft über die zu unterstützenden Sollprozesse, Funktionalitäten, Schnittstellen und Datenbestände liefert. Dabei ist zu berücksichtigen, dass ein ERP-Einführungsprojekt eine mehr oder weniger starke Neuorientierung in dem Unternehmen zur Folge haben kann. Daher sollte auch das Bewusstsein für eine umfassende, nicht nur die Informationsverarbeitung betreffende Erneuerung der Unternehmensprozesse geschaffen werden und

260

10  Anwendungen in ERP-Systemen • •

Initialisierung & • • Situations• analyse •

•

Sollkonzept

• • • •

Projektinitialisierung (Projektziele, -umfeld) Analyse bestehender ERP-Lösungen (Funktionalitäten, Datenflüsse) und Schnittstellen Analyse relevanter Datenbestände (Stamm-, Bewegungsdaten) Analyse der relevanten Unternehmensprozesse Systematisierung bestehender Schwachstellen in der IT-Unterstützung Definition der Anforderungen an die ERP-Lösung (Kann-, Soll-, MussAnforderungen) Definition der relevanten Sollprozesse, Funktionalitäten, Datenbestände und Schnittstellen Validierung des Sollkonzepts Erhebung des Marktangebots Installation von ERP-Testsystemen (On-Premises) oder Test von ERPCloud-Lösungen Dokumentation und Grobbewertung der verfügbaren Alternativen

Marktanalyse •

• •

Feinbewertung der relevanten Alternativen in Bezug auf relevante Merkmale Durchführung einer Nutzwertanalyse zur Verdichtung nicht-monetärer Eigenschaften Durchführung von TCO-Analysen zur Verdichtung monetärer Effekte Finalentscheidung für eine Alternative und Dokumentation

• • • • •

Beschaffung der ERP-Lösung Durchführung von Anpassungsmaßnahmen (z. B. Customizing) Realisierung und Test der Anpassungsmaßnahmen Implementierung der notwendigen Schnittstellen Abnahmetests mit Endanwendern

• • • • •

Schulung der Anwender und Administratoren Installation und Rollout des Produktivsystems Optimierung des Systemverhaltens Übernahme historischer Datenbestände Betrieb und Wartung des ERP-Systems (Updates, Upgrades)

•

Systemauswahl

Realisierung

Einführung & Betrieb

Abb. 10.48  Vorgehensmodell zur ERP-Einführung (in weiter Anlehnung an Hansmann und Neumann 2012, S. 335)

die für die Umsetzung erforderlichen Maßnahmen in die Wege geleitet werden. Das Konzept des Business Process Redesign (s. Abschn. 6.1) kann dazu wichtige Impulse geben. Bestehende Strukturen sollen strategisch überdacht und gegebenenfalls reorganisiert werden. Aufgrund des Sollkonzepts ist eine Marktanalyse durchzuführen, um potenzielle ERP-Alternativen zu identifizieren. Im Zuge der Marktanalyse können beispielsweise auch Testsysteme installiert werden oder aber verfügbare SaaS-Produkte

10.4  Einführung von ERP-Systemen als Standardsoftware

261

getestet werden. Die Ergebnisse sind zu dokumentieren und bieten die Möglichkeit zur Grobbewertung der ERP-Alternativen. Diese Grobbewertung kann verwendet werden, um den Alternativenraum zu reduzieren, indem beispielsweise diejenigen Systeme verworfen werden, die bestimmte Muss-­Anforderungen (K.O.-Kriterien) nicht erfüllen. Aufbauend auf den Ergebnissen der Marktstudie ist in der Phase Systemauswahl die Finalentscheidung für eine ERP-Lösung zu fällen. Empfehlenswert hierfür ist eine systematische Feinbewertung der verfügbaren Alternativen in Bezug auf sämtliche relevanten Zielkriterien und deren Vergleich. Zu diesem Zweck stehen unterschiedliche Auswahlkriterien zur Verfügung (Toedtli 1990): • Anbieterqualifikation. Wie hoch ist die Reputation des Anbieters, die Qualifikation seiner Entwickler und Berater sowie die Wahrscheinlichkeit, dass das Softwareprodukt über einen langen Zeitraum weiterentwickelt wird? Gibt es Updates bzw. Upgrades und müssen diese gesondert bestellt und bezahlt werden (Releasepolitik)? • Schnittstellen. Sind Standardschnittstellen zu umgebenden Systemen vorhanden? Erzielt man eine gewisse Unabhängigkeit von der eingesetzten Betriebssystem- und Kommunikationssoftware? Gibt es Schnittstellen zu bereits in dem Unternehmen vorhandenen Anwendungen bzw. wie hoch sind die Kosten, um diese zu realisieren? Werden die bereits eingesetzten elektronischen Systeme (z. B. Electronic Mail, Workflow-­ Systeme, EDI) unterstützt? • Endbenutzerfähigkeit. Wird die Bedienung durch Funktionstasten/Shortcuts und Menüsteuerung unterstützt? Gibt es Auswertungsmöglichkeiten ohne Programmiersprachenkenntnisse? • Softwareanpassungen. Wie gut werden individuelle Anpassungen unterstützt? Gibt es eine Entwicklungsumgebung bzw. Schnittstellen zu einer Standard-CASE-Umgebung? Sind für einfache Anpassungen Programmierkenntnisse notwendig? • Zugriffsschutz, Datensicherheit. Wie differenziert und flexibel ist das Berechtigungsund Sicherungskonzept des Softwareprodukts? • Performance. Ist das Softwareprodukt in der Lage, die aufkommenden Datenvolumina zu bewältigen? Welche Zugriffs- bzw. Laufzeiten können garantiert werden? • Kosten/Nutzen. Wie hoch sind die Kosten für Softwarelizenz, Wartung und notwendige Hardwareplattform? Wie stark steigert das Softwareprodukt die Effektivität und Effizienz der Geschäftsprozessausführung? Welche finanziellen und personellen Ressourcen müssen für Einführung, Wartung, Schulung und Beratung bereitgestellt werden? Als Methode zur Erfassung und Verdichtung der systembedingten Nutzeffekte hat sich die Nutzwertanalyse (synonym: Scoring-Modell, Punktbewertungsverfahren) durchgesetzt, die eine multikriterielle, qualitative Bewertung von Alternativen gestattet (s. Abschn. 3.3). Grundsätzlich sind dabei solche Kriterien zugrunde zu legen, die aus den Unternehmenszielen bzw. den Zielen der Anwender von ERP-Systemen ableitbar sind. Zur nutzwertanalytischen Bewertung von ERP-Systemen ist zu empfehlen, situativ relevante Erfolgsfaktoren auszuwählen,

262

10  Anwendungen in ERP-Systemen

zu gewichten und in einen Kriterienkatalog zu transformieren, sodass anschließend eine Bewertung erfolgen kann. Neben den Nutzeffekten ist auch der notwendige Ressourceneinsatz für die Einführung und den Betrieb des Systems zu erfassen. Hierzu sind sämtliche kostenrelevanten Sachverhalte zu erheben und verursachungsgerecht zu verrechnen. Aufgrund potenziell langfristiger Nutzungshorizonte von ERP-Systemen eignet sich hierfür insbesondere der Total-Cost-of-Ownership-Ansatz (TCO-Ansatz), der sämtliche Kosten erfasst und verdichtet, die im Laufe des Lebenszyklus eines Beschaffungsobjekts anfallen (Götze und Weber 2008). Dabei sind ggf. nicht nur Kosten für den Ressourceneinsatz zu erfassen, sondern auch potenzielle Einsparungseffekte (Cost Savings), die durch das Beschaffungsobjekt verursacht werden. Im Rahmen einer langfristigen Betrachtung sollten dabei sämtliche systembedingten Ein- und Auszahlungen berücksichtigt werden, beispielsweise durch Nutzung eines Vollständigen Finanzplans (VOFI) (Grob und Bensberg 2009, S. 183). Beispiel

Ein Beispiel für die Unterstützung der Nutzwertanalyse bietet das Werkzeug WiBe Kalkulator, das zur Durchführung von Wirtschaftlichkeitsanalysen für IT-Investitionen in der Bundesverwaltung entwickelt wurde (BMI 2018). Dieses Werkzeug unterstützt die freie Konfiguration von Kriterienkatalogen (Attributhierarchien), die anschließend zur Bewertung von Systemalternativen eingesetzt werden können. Folgende Abbildung zeigt eine Kriterienkatalogstruktur zur Bewertung von IT-Investitionen. Dabei werden einerseits monetäre Daten erfasst, die zur monetären Kennzahl Kapitalwert verdichtet werden. Andererseits wird der qualitativ-strategische Nutzwert aus den ordinalen Einzelbewertungen von Systemalternativen berechnet. Das System ist frei verfügbar und besitzt vordefinierte Kriterienkataloge.

10.4  Einführung von ERP-Systemen als Standardsoftware

263

Nach der Finalentscheidung ist in der Phase der Realisierung die ERP-Lösung zu beschaffen und anzupassen. Zur Anpassung von Standardsoftware (Customizing) an individuelle betriebliche Anforderungen nennen (Stahlknecht und Hasenkamp 2005, S.  298) drei ­Optionen: • Durch Parametereinstellung werden Softwareanpassungen an individuelle Bedürfnisse ohne Programmänderungen vorgenommen. Die gewünschten Anpassungen werden durch Veränderung bestimmter Parameter (z. B. Systemtabellen) erreicht. Voraussetzung ist, dass möglichst viele Programmfunktionen in der Software enthalten sind, deren Ausführung parametrisiert wurde. • Unter Ergänzungsprogrammierung (oder allgemeiner Individualprogrammierung) ist eine Softwareanpassung durch individuell erstellte Programmänderungen zu verstehen. Mit Individualprogrammierung lassen sich zwar spezifische, funktionale Anforderungen am besten realisieren. Es handelt sich aber um eine kostenintensive Anpassung, durch die darüber hinaus die Fähigkeit verloren gehen kann, an Weiterentwicklungen der Standardsoftware durch Einspielen von Upgrades oder Patches automatisch zu partizipieren (sog. Releasefähigkeit). • Bei der Konfigurierung (Modularisierung) wird die Standardsoftware durch die Auswahl benötigter Programmbausteine (Module) und die Definition der Beziehungen zwischen den Programmbausteinen gebildet. Da die Individualprogrammierung nicht nur mit erheblichen Kosten verbunden ist, sondern auch die Releasefähigkeit gefährdet, sollte es das Ziel sein, möglichst wenige Anpassungen vorzunehmen. Das gilt auch für die Konfigurierung, wenn dabei Module hinzugefügt werden, die nicht Bestandteil der Standardsoftware sind. Somit muss entschieden werden, ob es sinnvoller ist, die Software an die Abläufe und Strukturen des Unternehmens anzupassen oder umgekehrt. Die Anpassung von Unternehmensstrukturen an die Software ist dabei nicht immer nachteilig. Oft werden mit der Standardsoftware betriebswirtschaftliche Konzepte und Methoden „eingekauft“, die fortschrittlicher sind als die bisher in dem Unternehmen eingesetzten. Mit der Einführung von Standardsoftware sind deshalb oft auch organisatorische Änderungen in dem Unternehmen verbunden. Flexibilität in dem Unternehmen (Berichtswege, Kompetenzen) erspart daher oft einen signifikanten Teil der Anpassungskosten. Auf jeden Fall sollte der Anpassungsentscheidung eine detaillierte Kosten/Nutzen-Analyse vorangehen. Die Einführung von Standardsoftware ist ein geeigneter Zeitpunkt, um alte Strukturen in dem Unternehmen kritisch zu überdenken. Neben Kosten, Releasefähigkeit und Fachkonzept ist bei der Entscheidung über Softwareanpassung auch die Einführungszeit zu beachten. Die erforderlichen Anpassungen müssen von Spezialisten vorgenommen und getestet werden. Hierdurch kann sich die Projektdauer erheblich verlängern. Schließlich ist das angepasste Softwareprodukt auch durch den Anwender abzunehmen (z. B. in Form von Abnahmetests). In der letzten Phase ist die Softwarelösung in den Betrieb zu überführen. Voraussetzung hierfür sind sowohl die Schulung der Anwender und Administratoren als auch die Installation

264

10  Anwendungen in ERP-Systemen

und die Inbetriebnahme des Systems. Eventuell sind hierfür bereits vorhandene historische Datenbestände auf das Neusystem zu migrieren. Im Zuge des Betriebs können Optimierungsmaßnahmen erforderlich werden, um das Systemverhalten (z. B. Antwortzeit, Verfügbarkeit) zu verbessern. Zur Einführung von Standardsoftwareprodukten bieten Softwarehersteller sowie IT-Beratungshäuser methodische Unterstützung an. Als Beispiel hierfür wird im Folgenden das Vorgehensmodell zur Einführung von SAP ERP-Systemen erörtert, das von der SAP SE unter der Bezeichnung SAP Activate zur Verfügung gestellt wird.

10.4.2 SAP Activate als Vorgehensmodell zur Einführung von SAP ERP SAP Activate ist ein Vorgehensmodell zur Einführung von SAP ERP-Systemen (Kraljić und Kraljić 2018). Dieses basiert auf einem agilen Entwicklungsansatz und wird in Abb. 10.49 dargestellt. Hervorzuheben ist, dass dieses Vorgehensmodell keine Auswahl zwischen unterschiedlichen Systemalternativen vorsieht, sondern bereits die Entscheidung für ein SAP-System voraussetzt. In der ersten Phase Discover wird die SAP-Lösung zunächst in einer Cloud-basierten Versuchsumgebung getestet, um erste Erfahrungen mit dem IS zu sammeln. Dabei werden vordefinierte Geschäftsszenarien zur Verfügung gestellt, die anhand von Testdaten exploriert werden können. Auf diese Weise kann das Unternehmen Domänenwissen über die neue ERP-Lösung aufbauen. In der anschließenden Phase Prepare erfolgt die eigentliche Projektvorbereitung und Projektplanung, die insbesondere auch die notwendigen ERP-Infrastrukturen (z. B. Auslegung von Hardware und Netzwerkressourcen) umfasst. In dieser Phase werden die Projektziele definiert, sowie die zur Umsetzung erforderlichen Zeit- und Budgetpläne fixiert. Als Ergebnis steht auch ein detaillierter Arbeitsplan mit entsprechenden Arbeitspaketen und Meilensteinen. Hierfür sind auch Projektgremien (z. B. Lenkungsausschuss, Projektteams) einzurichten und Personalressourcen zuzuordnen. Im Anschluss findet die Definition der geschäftskritischen Anforderungen (s. Abschn. 7.2) statt, die ausführlich zu dokumentieren sind (Explore). Hieraus entsteht ein Istmodell für den betrachteten Geschäftsprozess (Business Blueprint), das durch ein Sollmodell ergänzt wird. Aus dem Sollmodell geht hervor, wie der Geschäftsprozess mithilfe des SAP-­ Systems realisiert wird. Zur Gewinnung dieser Informationen werden sog. Blueprint Workshops durchgeführt, deren Dauer von der Komplexität des Geschäftsprozesses abhängt. Als weiteres Ergebnis dieser Phase wird die notwendige SAP-Basiskonfiguration definiert. Außerdem herrscht Transparenz bezüglich der noch notwendigen Anpassungen (z. B. per Customizing oder Ergänzungsentwicklung). Die Realisierung (Phase Realize) bildet die eigentliche Entwicklungsphase im Vorgehensmodell, in der die SAP ERP-Lösung konfiguriert wird und die notwendigen Anpassungen durchgeführt werden. Aus Vereinfachungs- und Sicherheitsgründen wird die Realisierung eines Basisumfangs kritischer Funktionalitäten (Baseline-Konfiguration) zuerst

10.4  Einführung von ERP-Systemen als Standardsoftware

265

Phase 0

Phase 1

Phase 2

Phase 3

Phase 4

Phase 5

Discover

Prepare

Explore

Realize

Deploy

Run

• Testen einer Cloud-basierten Versuchsumgebung • Nutzung vordefinierter Geschäftsszenarien zur Wissensgewinnung

• Projektvorbereitung und Projektplanung durchführen • Steuerungsgruppe und Projektorganisation verankern

• Anforderungen erheben • Istprozess modellieren • Sollprozess modellieren • SAPKonfiguration definieren

• Basisfunktionalitäten entwickeln • Akzeptanztests durchführen • Change Management planen

• Produktivbetrieb vorbereiten • Nutzer schulen • Systemmanagement aufbauen

• Produktivbetrieb durchführen • Support betreiben • Leistung überwachen u. optimieren

Abb. 10.49  Vorgehensmodell SAP Activate (in Anlehnung an (Kraljić und Kraljić 2018))

durchgeführt und abgenommen; erst danach werden weniger kritische Funktionalitäten betrachtet. Begleitend zur Einführung sind Maßnahmen zur organisatorischen Umsetzung der notwendigen Veränderungen zu planen und durchzuführen (Change Management), Übernahmeprogramme für Daten und Schnittstellenprogramme für weiter bestehende Anwendungen außerhalb des ERP-Systems zu entwickeln, Berichte und Formulare zu gestalten, ein Berechtigungskonzept zu erarbeiten, die Archivierung einzurichten sowie Benutzerdokumentation und Schulungsunterlagen zu erstellen. Die Realisierungsphase wird durch Akzeptanztests (User Acceptance Test, UAT) durch die Endanwender abgeschlossen. Notwendige Voraussetzung hierfür ist die Verfügbarkeit geeigneter Datenbestände für Testzwecke. Sofern die Geschäftsprozessanforderungen durch das ERP-System erfüllt werden, erfolgt die Produktionsvorbereitung (Deploy), womit das System mit den notwendigen Daten für den Produktivbetrieb vorbereitet wird. Dabei werden auch die zukünftigen Benutzer des Systems geschult, das Systemmanagement des Produktivsystems aufgebaut, der Wechsel vom alten zum neuen System (Cutover) geplant und letzte offene Fragen geklärt. Zusätzlich gehört ein „Safety-Belt“, auch „Fallback“- oder „Recovery“-Szenario genannt, zu den letzten Schritten vor dem Produktivstart. In der letzten Phase (Run) wird von der vorproduktiven Umgebung in den Dauerbetrieb gewechselt. In diesem Zusammenhang ist eine Supportinstanz für Benutzer zu schaffen, die nicht nur die ersten kritischen Tage des Produktivbetriebs betreut, sondern auch den Dauerbetrieb. Diese Phase wird ebenfalls verwendet, um die Systemtransaktionen zu überwachen und die Gesamtleistung des Systems zu optimieren. Mit dem Abschluss dieser Phase, die die Betreuung der Anwender mit dem neuen System über einige Wochen beinhaltet, ist das Einführungsprojekt beendet. Sämtliche dieser Phasen werden durch eine Qualitätsprüfung abgeschlossen. Im Vergleich zum traditionellen Lebenszyklusmodell der Systementwicklung (s. Abschn. 13.3) fällt auf, dass der Projektplanung breiterer Raum gegeben wird, während die üblicherweise dominierenden Phasen des sukzessiv verfeinernden Entwurfs in einer einzigen

266

10  Anwendungen in ERP-Systemen

Phase (Realize) zusammengefasst sind. Einerseits liegt das daran, dass an die Stelle des technischen Entwurfs und der Implementierung bei Standardsoftware hauptsächlich die Parametereinstellung tritt und Implementierungsfragen nur ausnahmsweise relevant werden. Andererseits sieht das Vorgehensmodell vor, dass verschiedene Projektphasen auch von unterschiedlichen Akteuren durchgeführt werden. Während Anwendungsfachleute in den ersten beiden Phasen (d. h. bis zum Business Blueprint) dominieren, werden die letzten drei Phasen wesentlich durch System- bzw. Softwarespezialisten geprägt.

10.4.3 Open Source Software Bei der Einführung von ERP-Systemen entscheiden sich Unternehmen häufig für kommerzielle Standardsoftwareprodukte spezieller Anbieterunternehmen, für die entsprechende Lizenzen erworben werden müssen. Eine Alternative hierzu bildet Open Source-­ Software, die für unterschiedliche Anwendungsfelder zur Verfügung steht. Bis in die sechziger Jahre des vorigen Jahrhunderts war Software eine kostenlose Beigabe zu einem neuen Rechner. Dann hörte die Firma IBM auf, den Quellcode mit den Betriebssystemen der Rechner auszuliefern und in den folgenden Jahrzehnten stellten die Firmen fest, dass mit eigenständigen, marktfähigen Softwareprodukten erhebliche Einkünfte zu erzielen sind. Durch Lizenzverträge wurde die Weitergabe von Software eingeschränkt bzw. verboten. Hierdurch wurden die Einkünfte gesichert und der Quellcode wurde zum gehüteten Geheimnis der Unternehmen. Nutzende Unternehmen waren jetzt bei der Behebung von Fehlern, der Erweiterung der Software oder deren Anpassung an das Entgegenkommen des entwickelnden Unternehmens angewiesen. Mitte der achtziger Jahre wurde von Richard Stallmann vom MIT (Massachusetts Institute of Technology) mit GNU, eine Softwareentwicklungsumgebung rund um den Kern des UNIX-­Betriebssystems entwickelt. Dies war die erste so genannte Open Source Software. Sie wurde dann auch über die von Stallmann mitbegründete FSF (Free Software Foundation) frei verfügbar gemacht. Die Ursache für diese Entwicklung, wie auch für viele andere Open Source Softwareentwicklungen, war die Unzufriedenheit mit der bestehenden Softwarequalität und die mangelnde Bereitschaft des entwickelnden Unternehmens, die Fehler bzw. Mängel zu beheben. cc Open Source Software  Open Source Software (OSS) bezeichnet Software, deren Programme als Quellcode (Source Code) in verständlicher Form frei verfügbar sind und bei der die Nutzer auch das Recht haben, den Programmcode zu verändern und ohne Zahlung eines Kaufpreises zu nutzen. Die Nutzer bzw. nutzenden Unternehmen können diese Programme für ihre Zwecke verändern, Verbesserungen entwickeln und Fehler beseitigen. Die Nutzer haben das Recht, alle Änderungen und Verbesserungen am Quellcode weiterzugeben. Kein Unternehmen besitzt die Exklusivrechte an der Software, d. h. die Open Source Software steht allen offen.

10.4  Einführung von ERP-Systemen als Standardsoftware

267

Konventionelle Software, proprietäre Software, Closed Source oder kommerzielle Software (auch engl. Commercial off the Shelf, COTS) sind Begriffe, die für Software benutzt werden, welche die obigen Bedingungen nicht erfüllen. Bei dieser wird der Quelltext vom Hersteller unter Verschluss gehalten. Bekannteste OSS-Beispiele sind das Betriebssystem LINUX, die Datenbank MySQL, der Webserver APACHE und der Webbrowser Mozilla Firefox. OSS ist aber auch zunehmend in den betrieblichen Anwendungsbereichen verfügbar. Obwohl die meisten OpenSource-Programme auf LINUX verfügbar sind, gibt es auch zunehmend Anwendungen, die auf proprietären Betriebssystemen aufsetzen. Die folgende Aufstellung gibt beispielhaft ohne Anspruch auf Vollständigkeit einen groben Überblick über die in unterschiedlichen Bereichen verfügbaren Open-Source-Programme: • Betriebssysteme: GNU/LINUX, Android • Betriebliche Standardsoftware (z.  B.  ERP-Software): ADempiere, Apache OFBiz, Metasfresh • Customer Relationship Management-Systeme: Vtiger, SuiteCRM, FreeCRM • Geschäftsprozess- und Workflowmanagement: Bonita BPM, Camunda, Activiti • Content Management-Systeme: Drupal, Joomla!, Neos, Plone, TYPO3 • E-Learning-Software: Moodle, ILIAS, Sakai • Büroanwendungen: OpenOffice, LibreOffice, Calligra Suite, NeoOffice • Grafikanwendungen: GIMP, Scribus • Datenbanken: MySQL, PostgreSQL, Interbase • Programmiersprachen: Perl, PHP, Python, Ruby, Free Pascal, FreeBasic • Entwicklungswerkzeuge: Ant, Make, Maven, GIMP-Toolkit, KDevelop, Eclipse, GNU Compile Collection (GCC), CVS Die folgenden Stärken von Open-Source-Software beeinflussen die Entscheidung für eine OSS-Lösung in dem Unternehmen: • Der offene Quellcode der OSS erhöht die Unabhängigkeit von einem Hersteller. • Geringerer Lock-In-Effekt, da keine prinzipielle marktbeherrschende Position eines Anbieters vorliegt. • Keine Lizenzkosten und geringere Erweiterungs- und Wartungskosten als bei vielen proprietären Programmen. • Etwaige Softwarefehler können von der Entwicklergemeinschaft, die sich dem Open-Source-Gedanken verpflichtet fühlen, behoben werden. • OSS kann durch unmittelbare Änderung des Quellcode an eigene Bedürfnisse angepasst werden. • Das Unternehmen kann gegebenenfalls von fremden Erweiterungen der OSS profitieren. • Größere Zukunftssicherheit, da kein einzelnes Unternehmen, sondern eine Gemeinschaft die Weiterentwicklung unabhängig von finanziellen Aspekten sicherstellen kann.

268

10  Anwendungen in ERP-Systemen

Die folgenden Schwächen von OSS sollten berücksichtigt werden: • Ggf. Schwierigkeiten beim Daten- und Dokumentenaustausch zwischen einzelnen Lösungen. • Die Hardwareunterstützung weist in manchen Fällen, z. B. bei hardwarebeschleunigten Grafikkarten oder bei Multimedia-Geräten, wie z. B. Scannern, Mängel auf. • Beschaffung von Informationen zu einzelnen OSS-Lösungen ist teilweise problematisch. Folgende Punkte sollten bei der Auswahl einer OSS-Lösung bedacht werden: • Support. Da für Anpassung und Support qualifiziertes Personal notwendig ist, muss geprüft werden, ob Dienstleister beauftragt werden können oder hinreichende interne Ressourcen zur Verfügung stehen. Für verbreitete OSS stehen häufig Dienstleistungen über das Internet zur Verfügung. • Dokumentation. Nicht immer ist eine umfangreiche Nutzerdokumentation zu der OSS verfügbar. • Verbreitungsgrad. Die Verbreitung der OSS beeinflusst die Größe der Entwicklergemeinschaft.

Anwendungen zur Entscheidungsunterstützung

11

Zusammenfassung

Dieses Kapitel stellt solche Anwendungen dar, die der Rationalitätssicherung von Entscheidungsprozessen in Unternehmen dienen. Aufbauend auf den allgemeinen ­ Komponenten solcher dispositiven bzw. analytischen Anwendungen werden Anwendungsbeispiele für aufgabenorientierte Lösungen zur betrieblichen Entscheidungsunterstützung vorgestellt.

11.1 Überblick Unter dem Begriff Entscheidungsunterstützungssystem (EUS) werden Anwendungen verstanden, die Entscheidungsträger zur Rationalitätssicherung in Entscheidungsprozessen einsetzen. EUS sind zur Kategorie der Systems of Insight zu zählen (s. Abschn. 2.3.3), da sie – aufbauend auf verfügbaren Realdaten – zur Gewinnung neuer Erkenntnisse beitragen. Unter einer Entscheidung werden im Rahmen der Entscheidungstheorie sämtliche Handlungen von Entscheidungsträgern begriffen, die die Wahl zwischen mindestens zwei Möglichkeiten (Alternativen, Optionen) zum Gegenstand haben. Im betrieblichen Kontext werden dabei bewusste, systematisch geführte Wahlhandlungen fokussiert, die im Kontext von Planungs-, Steuerungs- und Kontrollaufgaben stattfinden. Als Bezugsrahmen für die Ausgestaltung von EUS wird hier ein idealtypischer Führungsprozess zugrunde gelegt, der im Vergleich zu dem in Abschn. 1.3 eingeführten Problemlösungsprozess die Alternativenbewertung explizit als Phase aufführt (s. Abb. 11.1). Dieser Führungsprozess basiert auf einer systematischen, rationalen Planung zur Entscheidungsvorbereitung sowie einer dedizierten Kontrolle.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_11

269

11  Anwendungen zur Entscheidungsunterstützung

270

Zielvorgabe(n)

1. Problemidentifikation

2. Alternativensuche Planungsphase

Entscheidungsvorbereitung

3. Alternativenbewertung

4. Entschluss

Finalentscheidung

Entscheidungsphase

Vorgabeinformation (Soll) 5. Realisation

Durchsetzungsphase

6. Kontrolle

Teilphasen des Führungsprozesses mit spezifischem Führungsverhalten

detaillierte Festlegung u. Veranlassung der Ausführung sowie Überwachung

Ausführung

Vergleich der Ausführungs- u. Entscheidungsresultate (Soll/Ist) Tätigkeiten und Aufgaben der Unternehmungsführung

Rückinformation (Ist)

Abb. 11.1  Idealtypischer Führungsprozess (Grob und Bensberg 2009, S. 4)

11.1 Überblick

271

Der dargestellte Führungsprozess wird durch die Identifikation eines Problems initialisiert. Ein Problem liegt immer dann vor, wenn eine negative Abweichung zwischen den angestrebten Zielen (Sollzustand) und dem Istzustand besteht und unklar ist, wie der Sollzustand zu erreichen ist. Grundlage für die Problemidentifikation können unternehmensinterne und ­-externe Beobachtungsfelder liefern. Unternehmensinterne Indikatoren sind etwa die Ergebnis- und Finanzlage des Unternehmens, während im externen Umfeld beispielsweise die konjunkturellen und strukturellen Entwicklungen am Absatzmarkt zur Problemerkennung beitragen können. Nach der Problemidentifikation erfolgt die Suche nach Handlungsalternativen, die potenziell zur Problemlösung führen. Hierzu können sowohl logisch-systematische Methoden eingesetzt werden (z. B. Marktforschung, Produktionsprogrammplanung) sowie kreativ-intuitive Verfahren (z.  B.  Brainstorming, s. Abschn.  6.1). Die gewonnenen ­Alternativen werden im Anschluss bewertet, sodass in der Entscheidungsphase eine Finalentscheidung möglich wird. In der anschließenden Durchsetzungsphase erfolgt die Realisation der ausgewählten Alternative, die begleitend überwacht wird. Nach der Umsetzung findet schließlich die Kontrolle statt, mit der letztlich im Zuge eines Soll-Ist-Vergleichs überprüft wird, ob das originäre Problem abgebaut werden konnte. Abweichungen zwischen Soll- und Istzustand liefern Anhaltspunkte zur Erfolgsbeurteilung der ergriffenen Maßnahme sowie Hinweise auf Ursachen für Misserfolge. In den einzelnen Teilphasen des dargestellten Führungsprozesses werden EUS eingesetzt, um den Informationsbedarf von Entscheidungsträgern zu decken. Hierzu werden aufbauend auf vorhandenen Daten mithilfe betriebswirtschaftlicher bzw. mathematisch-­ statistischer Konzepte neue Informationsangebote für Entscheidungsträger generiert und visualisiert. Hierbei sind zwei Kategorien von EUS zu differenzieren: • Datenorientierte EUS dienen der Überwachung (Monitoring), Beschaffung, Aufbereitung und Verdichtung von Daten. Im Verarbeitungsfokus solcher datenorientierter Systeme steht die Ermittlung betriebswirtschaftlicher Kennzahlen, die beispielsweise in Form von Berichten (Reports) bereitgestellt werden. Solche EUS werden in der Initialphase von Entscheidungsprozessen eingesetzt, um die Problemidentifikation zu unterstützen, oder aber in der Kontrollphase verwendet, um Abweichungsanalysen durchzuführen. • Modell- bzw. methodenorientierte EUS gestatten die Anwendung komplexer, formaler Methoden zur Konstruktion problemorientierter Modelle. Hierbei können z. B. Simulations-, Optimierungs- oder auch explorative Methoden zur Anwendung kommen. Solche Verfahren werden vorzugsweise in den späteren Teilphasen des Entscheidungsprozesses eingesetzt, um die Alternativensuche, die Alternativenbewertung sowie die Finalentscheidung zu unterstützen. Aus dem Einsatz von EUS können unterschiedliche Effekte für den Entscheidungsträger und den unterstützten Entscheidungsprozess resultieren. Einerseits kann die Bereitstellung rechnergestützter Verfahren zur kognitiven Entlastung des Entscheidungsträgers beitragen und somit die Effizienz des Entscheidungsprozesses steigern. Durch Automatisierung von

272

11  Anwendungen zur Entscheidungsunterstützung

Entscheidungsprozessen (Decision Automation) wird im Extremfall der gesamte Prozess durch eine Anwendung realisiert, sodass dem Menschen lediglich die Tätigkeiten der Überwachung und ggf. auch der Anpassung der Anwendung zufallen. Andererseits besteht die Möglichkeit, durch die Anwendung komplexer numerischer Verfahren die Entscheidungsfähigkeit von Entscheidungsträgern zu ergänzen, sodass durch EUS potenziell auch die Effektivität von Entscheidungsprozessen – im Sinne der erzielten Entscheidungsqualität – zunimmt. Sowohl die Entlastung als auch die Ergänzung des menschlichen Entscheidungsträgers dienen letztlich der Rationalitätssicherung des Entscheidungsprozesses. Die Bedeutung der Rationalitätssicherung menschlicher Entscheidungsprozesse wird auch die Erkenntnisse der psychologischen Entscheidungsforschung unterstützt. So sind durch experimentelle Studien zahlreiche Heuristiken und Tendenzen (Biases) im menschlichen Entscheidungsverhalten aufgedeckt worden, die letztlich zu fehlerhaften oder suboptimalen Entscheidungen führen (Kahneman et al. 1982). So besagt beispielsweise der Sunk Cost Bias, dass Entscheidungsträger die Tendenz besitzen, gerade solche Projekte fortzusetzen, für die in der Vergangenheit bereits Mittel investiert worden sind. Diese historischen Kosten sind allerdings nicht mehr entscheidungsrelevant, da sie bereits angefallen sind und in der Regel durch künftige Entscheidungen nicht mehr neutralisiert werden können (Grob und Bensberg 2005, S. 45). Bei der Gestaltung von EUS ist daher kritisch zu hinterfragen, ob deren Informationsangebot am subjektiven Informationsbedarf der Entscheidungsträger auszurichten ist, oder aber am objektiven Informationsbedarf, der beispielsweise durch den State of the Art in der betriebswirtschaftlichen Literatur, Referenzmodelle (s. Abschn.  10.1) oder fachkundige Experten für das jeweilige Entscheidungsproblem vorgegeben wird. Zur Erhebung des subjektiven Informationsbedarfs betrieblicher Entscheidungsträger stehen unterschiedliche Datengewinnungsmethoden zur Verfügung: • Befragung der Entscheidungsträger in Form von Interviews oder schriftlichen Befragungen, • Beobachtung des Informationsbeschaffungsverhaltens von Entscheidungsträgern in direkter und indirekter Form (z.  B. durch Protokollierung des Suchverhaltens im Intranet), und • Inhaltsanalyse von relevanten Dokumenten (z.  B.  Prozessbeschreibungen für Planungs- und Entscheidungsprozesse). Der Nutzerkreis von EUS umfasst grundsätzlich sämtliche Personen der Leitungsebene, die in der betrieblichen Praxis mit der Handhabung und Lösung von Entscheidungspro­ blemen beauftragt sind. Hierzu gehören sämtliche Stufen des Managements, sowie deren Entscheidungsbegleiter, wie z. B. Akteure aus dem Controlling, aus Stabstellen oder aus Unternehmensberatungen. Darüber werden EUS auch auf der Leistungsebene von Unternehmen zur Unterstützung operativer Entscheidungsprozesse eingesetzt, die etwa im Rahmen von Geschäftsprozessen (z. B. Kreditsachbearbeitung, Schadensregulierung) erforderlich sind und häufig ausgeführt werden. Gerade in diesen operativen Bereichen liegen

11.1 Überblick

273

oftmals gut strukturierte Entscheidungssituationen vor, die durch Automatisierung ­maschinell realisiert werden können und aufgrund ihrer hohen Frequenz ein großes Rationalisierungspotenzial besitzen. Die aktuelle Diskussion von EUS wird in der Wirtschaftsinformatik durch den Oberbegriff Business Analytics geprägt. Dabei werden drei unterschiedliche Ausrichtungen von EUS differenziert: • Descriptive Analytics. Deskriptive Analysesysteme gestatten eine kennzahlenorientierte Auswertung großvolumiger Daten. Hierzu zählen auch die traditionellen Instrumente des Berichtswesens, mit denen Standard- und Ausnahmeberichte auf der Basis vergangenheitsorientierter Daten realisiert werden. Ein exemplarischer Anwendungsfall solcher EUS ist etwa die Berichterstattung über diejenigen Kunden, die ihre Geschäftsbeziehung aufgelöst haben (Abwanderer). Ein konkretes Systembeispiel für Descriptive Analytics liefert Abschn. 11.2.5. • Predictive Analytics. Mithilfe multivariater Analyseverfahren können Modelle generiert werden, die anschließend zur Prognose (Prädiktion) und Klassifikation von ­Geschäftsobjekten (z. B. Kunden, Aufträge, Maschinen) dienen. Auf diese Weise kann beispielsweise das künftige Abwanderungsverhalten von Kunden prognostiziert werden. Ein weiterer Anwendungsfall im Rahmen der Industrie 4.0 ist beispielsweise die vorausschauende Wartung (Predictive Maintenance), die auf der Erfassung und Analyse von Maschinendaten über das Internet der Dinge (s. Abschn. 5.5) basiert und durch die Berechnung von Fehlerwahrscheinlichkeiten maschinenspezifische Wartungsmaßnahmen automatisch auslösen kann. • Prescriptive Analytics. Diese Kategorie umfasst die Konstruktion normativer (präskriptiver) Entscheidungs- bzw. Optimierungsmodelle, die in gut strukturierten Entscheidungssituationen konkrete Handlungsempfehlungen liefern. Mit solchen Techniken können beispielsweise Empfehlungen generiert werden, wie abwanderungsgefährdete Kunden am besten an das Unternehmen gebunden werden können. Ein Systembeispiel für Prescriptive Analytics ist das System IBM ILOG CPLEX Optimization Studio (siehe Kasten).

IBM ILOG CPLEX Optimization Studio als Predictive-Analytics-Lösung

IBM ILOG CPLEX Optimization Studio bietet die Möglichkeit, Optimierungsmo­ delle zu entwickeln und zu lösen. Zu diesem Zweck steht dem Anwender eine integrierte Entwicklungsumgebung zur Verfügung, mit der Optimierungsmodelle in der Optimization Programming Language (OPL) formuliert werden können. Dabei wird das Paradigma der Constraint-Programmierung eingesetzt. Dies bedeutet, dass der Anwender sein Problem in deklarativer Weise formuliert und das Softwaresystem die Problemlösung durch Anwendung von Optimierungs- und Suchverfahren übernimmt. Zur Formulierung des Problems werden Datenobjekte deklariert und mit Werten belegt, für die anschließend Randbedingungen (Constraints) und eine

274

11  Anwendungen zur Entscheidungsunterstützung

­ ielfunktion (Objective) ­definiert werden. Derartige Optimierungsmodelle sind in Z der Lage, Handlungsempfehlungen für konkrete, gut strukturierte Entscheidungssi­ tuationen zu generieren. Ein Erfolgsfaktor für die praktische Anwendung ist, dass einerseits die relevanten Realdaten zum Entscheidungsproblem automatisch in das Optimierungssystem integriert werden können und andererseits die Lösung des Entscheidungsmodells (Entscheidungsvariablen) zur Steuerung der operativen Geschäftsprozesse über geeignete Schnittstellen an die Anwendungen propagiert werden kann. Folgende Abbildung zeigt ein exemplarisches OPL-Modell in der integrierten Entwicklungsumgebung.

Eine Weiterentwicklung dieser Paradigmen ist der Ansatz des Cognitive Analytics. So stehen zur Entscheidungsfindung häufig diverse Datenquellen zur Verfügung, die für den jeweiligen Entscheidungskontext implizites Wissen liefern können. Unter Cognitive Analytics wird daher ein Ansatz verstanden, der unterschiedliche Arten von Datenquellen (Collection) verarbeiten kann, diese miteinander in Beziehung setzt (Context) und darauf aufbauend neue Einblicke und Erkenntnisse ableiten kann (Cognition) (Maymir-Ducharme und Angelelli 2014, S. 34). Ein Beispiel für eine Anwendung des Cognitive Analytics ist der Cloud Service Personality Insights, der auf der Softwarefamilie IBM Watson aufbaut und anhand von Texten (z. B. E-Mails, Twitter Tweets) differenzierte Hinweise auf das Persönlichkeitsprofil des jeweiligen Autoren liefert (s. Abb. 11.2). Die Ergebnisse basieren auf der Einbindung psychologischer Persönlichkeitsmodelle, empirischer Studien und Analysen von Online-Kommunikationsprofilen. Liegt beispielsweise eine schriftliche Kundenbeschwerde vor, können mithilfe dieses Dienstes anhand des Beschwerdetextes Handlungsempfehlungen zur Kundenbindung im Rahmen des CRM (s. Abschn. 12.2.1) generiert werden.

Clo s (9 e 5

Ne e

%) 3%)

sity (4

(95%)

Artistic in

Ope n (100 ness %)

)

1%

x tr a ve ( 1 3 r si on %)

Fiery (59%)

)

vtl

.v

ng

(5

3%

)

erk

(50

lei

%)

ne

rn

(10

-20

%)

4%

g (9

isin

Prone

to worr

y (31%

%)

)

ss

eki

ke

%)

Mel

)

anc

rat

afi

ne

0%

de

%)

-se

76

mo

us

n(

)

rom

0%)

thy (10

Im

(32%

ion

(28

s( es

Gr

(9

tio

holy

45

%

)

(4

ss

re

s (20

ent

ism

sn

rio

tru

st

se

ga

5%)

lnes

item

die

Al

to

eness (7

erfu

era

op

Co 40%

ty (

iou

Assertiv

re

des

le

cy (77%)

Che

G

Mo

sc

e bl e n A gre ea %) (9 7

omp

on

)

(86%

ipline

Activity level (56%)

ss

Unc

tib

%)

(86

ess

rlin rde

disc Self-

Exc

Em oti on (24 al rang e %)

Sympa

lf-c

tif

%)

(91

O

E

Trust (70%)

ep

ss

e uln

Du

Op e n (10 ness 0% )

m

Se

Ca

)

7%

6 s(

s

ne

us

io ut

Big 5

es

e nc nha ) (3%

sc

A

ds

V alu

S e l f- e

0%)

3%) ent ( cem n a %) h -en (15 Self ism %) n o d 15 He e( g n ) ha 1% oc (7 st e n n tio en va Op se n Co

Su

em

ev

i ch

0 (1

Self-effica

ence (7

nscend

g

vin

s nt

e

challenge (40%)

Self-tra

)

0%

tri

usness ntio cie ns 94%) ( Co

ss ne )

(35

%)

)

)

)

8%

(5%

(2

%)

Curio

Closeness

%)

ent

5%

n ssio

94

item

(4

) 4%

Exc

al

(3

y(

58

on

rty

Ide

re (24 Structu ) 87%

ility ( Stab

pre f-ex Sel

rm

ve

Lo

be

Ha

( lity

tica

c Pra Li

terests (9 0%) Emo tiona lity (8 Ima 7%) gin atio n (2 Int 9% ell ) ec Au t (6 th 3 or %) ity -c ha lle ng ing (4 7% )

275 Adventurousness (86%)

11.1 Überblick

)

Abb. 11.2 Personality Insights als Beispiel für Cognitive Analytics (http://personality-insights-demo.ng.bluemix.net/)

Wie die unterschiedlichen analytischen Paradigmen zeigen, ist eine grundlegende ­ oraussetzung für die produktive Nutzung von EUS die Verfügbarkeit einer adäquaten V ­Datenbasis, die aus unternehmensinternen und -externen Datenquellen gespeist wird. ­Besondere Bedeutung als unternehmensinterne Datenlieferanten für EUS besitzen die ­Finanzbuchhaltung und die Kosten- und Leistungsrechnung. Diese Datenquellen dienen nicht nur der operativen Abrechnung und wertmäßigen Dokumentation von Geschäftsvorfällen, vielmehr stellen sie auch einen wichtigen Informationspool für EUS dar und sind für die Zwecke des Controllings des Unternehmens von maßgeblicher Bedeutung

276

11  Anwendungen zur Entscheidungsunterstützung

Tab. 11.1  Diskrepanzen der Datennutzung Thema/Funktion Dateninhalt

Transaktionsorientierte Datenverarbeitung (OLTP) Atomistische Istwerte

Datenorganisation

Anwendungsabhängig

Art der Daten Datenstruktur Zugriffsfrequenz Aktualisierung der Daten Nutzung

Dynamisch Funktionsabhängig Hoch Transaktionsbezogene Updates

Antwortzeit Datenbankarchitektur

Strukturierte wiederholte Verarbeitung 2–3 Sekunden Relationale Datenbanken (SQL)

Entscheidungsorientierte Datenverarbeitung Archivdaten aggregierte Daten berechnete Daten Themenbezogene Bereiche des Gesamtunternehmen Statisch bis zum nächsten Update Universell Niedrig Nur lesender Zugriff Unstrukturierte analytische Verarbeitung I. d. R. mehrere Minuten oder länger Relational und nicht-relational (SQL, NoSQL)

(Grob und Bensberg 2009, S. 81 ff.). Darüber hinaus sind auch die operativen Datenbestände weiterer betrieblicher Funktionsbereiche, wie etwa des Marketing, der Produktion und der Logistik, für EUS zu erschließen. Als unternehmensexterne Datenquellen können die Inhalte von Websites und Portalen ausgelesen werden (Web Scraping), um beispielsweise Entscheidungsprozesse durch Konkurrenz- und Marktanalysen empirisch zu fundieren. Unter Web Scraping (synonym: Web Harvesting, Web Data Extraction) wird die automatisierte Extraktion und Weiterverarbeitung von WWW-Daten verstanden, die in der Regel in Form von HTML-Dokumenten über das HTTP-Protokoll abrufbar sind. Zu diesem Zweck stehen mittlerweile zahlreiche Entwicklungswerkzeuge und Standardsoftwareprodukte zur Verfügung (vanden Broucke und Baesens 2018, S. 187 ff.). Zwar greifen EUS auf die operativen Datenbestände des Unternehmens zu (Systems of Record, s. Abschn. 2.3.2), doch unterscheiden sie sich in der Art der Verarbeitung dieser Daten erheblich von operativen Anwendungen. Während die operativen Systeme auf dem Grundsatz der transaktionsorientierten Verarbeitung von Massendaten (Online Transaction Processing, OLTP) basieren, fokussieren EUS eine entscheidungsorientierte Verarbeitung von Massendaten. Die Unterschiede dieser beiden Verarbeitungsparadigmen werden in Tab. 11.1 dargestellt. Die Diskrepanzen zwischen den Verarbeitungsparadigmen führen bei der Entwicklung von EUS oft zu Misserfolgen. EUS-Projekte scheitern häufig aufgrund mangelnder Kompatibilität in heterogenen Systemlandschaften, in denen z.  T. noch proprietäre Systeme eingesetzt werden. In vielen Fällen ist eine Datenintegration für EUS aufgrund mangelnder Schnittstellen oder gar fehlender Datenmodellierung nur mit hohem Aufwand möglich. Letzteres ist beispielsweise der Fall, wenn wichtige Daten in Tabellenkalkulationsblättern verstreut sind. Die Bedeutung der Daten ist dann bestenfalls aus Spalten- und

11.1 Überblick

277 BI-System

Dialog- und Analyseschicht

Bereitstellungsschicht

originäre Datenschicht

OLAPSysteme

Berichtssysteme

Data MiningSysteme

Data Warehouse-System

unternehmensexterne Datenquellen

unternehmensinterne Datenquellen

Abb. 11.3  BI-Architektur (in Anlehnung an (Bensberg 2010, S. 43))

Zeilenüberschriften zu ermitteln, die aber oft untereinander nicht abgestimmt sind. Eine Datenintegration ist dann nur durch mühsame manuelle Arbeit möglich. Diese ist i. d. R. immer wieder zu leisten, weil kleinste Strukturänderungen (Streichen einer Zeile oder Einfügen einer Spalte) in einem der Kalkulationsblätter zu Inkonsistenzen führen können. Erfolgt die Realisierung einer unternehmensweiten EUS-Infrastruktur auf der Basis einer integrierten Standardsoftware, wie beispielsweise SAP ERP, so lässt sich der Aufwand der Datenintegration aufgrund des hohen Homogenitätsgrads der operativen Datenbanken stark reduzieren. Die bestehende Problematik fehlender Schnittstellen und Datenmodellierung für eine unternehmensweite EUS-Gestaltung wurde von der Forschung bereits in den 1990er-­ Jahren erkannt und durch Entwicklung innovativer Konzepte für die entscheidungsorientierte Informationsverarbeitung beantwortet. Derartige Konzepte werden unter dem Begriff Business Intelligence zusammengefasst. Unter Business Intelligence (BI) ist ein Gesamtansatz zu verstehen, mit dem Komponenten für die Beschaffung, Aufbereitung und Bereitstellung von gut strukturierten, tabellarischen Daten zur Unterstützung betrieblicher Entscheidungsprozesse zusammengeführt werden (Kemper et al. 2010, S. 8 ff.). Der generelle Aufbau eines BI-Systems stellt Abb. 11.3 dar. In diesem Architekturmodell sind drei Schichten voneinander abzugrenzen. Die Grundlage von BI-Systemen bildet die originäre Datenschicht. Diese umfasst sämtliche Datenbestände, die für die Entscheidungsunterstützung aufzubereiten sind und aus unternehmensinternen bzw. -externen Quellen stammen können. Die Datenbestände werden in einem Data-Warehouse-System abgelegt, das als zentraler Datenspeicher dient und somit die Bereitstellungsschicht darstellt. Die bereitgestellten Daten können anschließend mithilfe von Anwendungsprogrammen verarbeitet werden, die auf der Dialog- und Analyseschicht angesiedelt sind. Neben Data-Mining-Systemen (s. Abschn. 2.3.3.4) werden zu diesem Zweck häufig Berichtssysteme und Systeme für das Online Analytical Processing (OLAP) eingesetzt. Ein prägendes Merkmal von BI-Systemen ist, dass die Datenspeicherung – wie auch

278

11  Anwendungen zur Entscheidungsunterstützung

in den operativen Anwendungen – nahezu regelmäßig auf Basis relationaler Datenbankmanagementsysteme (RDBMS) erfolgt. Auf diese Weise können ­beispielsweise Belegdaten aus Geschäftsvorfällen (s. Abschn. 10.2.2.5) effizient verarbeitet werden. Zur Analyse besonders großer und komplex strukturierter Datenbestände hat sich in jüngerer Zeit das Konzept Big Data herausgebildet. Dieses Konzept adressiert den Bedarf von Unternehmen, Datenbestände aus verschiedenen Quellen mit einem breiten Spektrum an unterschiedlichen Datentypen für Entscheidungszwecke aufzubereiten. Als Datenquelle sind beispielsweise die Inhalte von Websites oder Social Media genannt, die Texte, Bilder und Videos zur Verfügung stellen. Zur Verarbeitung solcher großvolumiger, komplex strukturierter Daten sind differenzierte Lösungen zur Speicherung und Verarbeitung erforderlich. Im folgenden Abschn. 11.2 werden zunächst die Komponenten der BI-Architektur näher erörtert, wobei insbesondere auf das Data-Warehouse-Konzept sowie auf Berichtsund OLAP-Systeme eingegangen wird. Dabei handelt es sich um etablierte Komponenten zur Konstruktion datenorientierter EUS.  Anschließend wird in den Aufbau mobiler BI-­ Systeme eingeführt (s. Abschn. 11.2.4), während Abschn. 11.2.5 Microsoft Power BI als Systembeispiel skizziert. Anschließend werden die zentralen Merkmale des Big-Data-­ Ansatzes identifiziert (s. Abschn. 11.2.6) und SAP HANA (s. Abschn. 11.2.7) als Big-Data-Beispielsystem vorgestellt. Abschließend werden aufgabenorientierte EUS skizziert, die die Anwendung formalisierter Methoden zur Konstruktion betrieblicher Entscheidungsmodelle zum Gegenstand haben.

11.2 A  llgemeine Komponenten von Entscheidungsunterstützungssystemen 11.2.1 Data-Warehouse-Konzept Die Unterschiede zwischen der transaktions- und entscheidungsorientierten Datenverarbeitung (s. Tab. 11.1) haben dazu beigetragen, dass in den 80er-Jahren das Data-­Warehouse-­ Konzept entwickelt worden ist. Mit diesem Konzept, das bisweilen auch als Information Warehouse bezeichnet wird, wird eine von datenliefernden, unternehmensinternen oder -externen Fremdsystemen emanzipierte Datenhaltung für dispositive Zwecke gewährleistet. Auf diese Weise soll eine zentrale, konsistente Datenbasis für die Entscheidungsträger des Unternehmens zur Verfügung gestellt werden. cc Data Warehouse  Ein Data Warehouse ist ein themenorientierter, integrierter, nicht flüchtiger und zeitvarianter Datenspeicher (Inmon 2002, S. 33). Aus dieser Definition lassen sich im Vergleich zur klassischen, transaktionsorientierten Datenhaltung wesentliche Unterschiede herausarbeiten. So bedeutet die themenorientierte Datenhaltung, dass die Informationsobjekte nicht wie die operativen Daten funktional anwendungsbezogen interpretiert werden, sondern eine abbildungsorientierte Aufbereitung

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

279

der realen Informationsobjekte hergestellt wird. Ein Data Warehouse ermöglicht demnach eine von der operativen Anwendungsarchitektur unabhängige Darstellung entscheidungsrelevanter Daten. Das Data Warehouse integriert sämtliche Daten aus den verfügbaren Datenbeständen des Unternehmens. Durch diesen Prozess wird im Gegensatz zur klassischen Datenhaltung eine einheitliche Sicht auf den gesamten Unternehmensdatenbestand ermöglicht. Als weiteres Merkmal sind die Datenelemente des Data Warehouse als nicht flüchtig anzusehen, d. h., sie können nicht durch den Eingriff der operativen Systeme gelöscht oder manipuliert werden. Zudem erfolgt im Data Warehouse die explizite Erfassung des Faktors Zeit als Bezugsgröße. Durch dieses Merkmal der Zeitabhängigkeit können dynamische Entwicklungen einzelner Datenelemente verdeutlicht werden, um beispielsweise Lebenszyklusanalysen, Strukturbrüche oder Soll-Ist-Abweichungen transparent zu machen. Beim Data Warehouse handelt es sich nicht um ein monolithisches Element, sondern um ein komplexes System, das in der BI-Architektur zwischen den Analysewerkzeugen und den originären Datenquellen eingegliedert ist (s. Abb. 11.4). Bei den internen Datenquellen handelt es sich um Daten, die in den operativen Systemen des betreffenden Unternehmens gespeichert werden. Es liegen detaillierte Datensätze vor, bei denen der vorherige Eintrag bei einer Aktualisierung überschrieben wird. Datenänderungen werden bei BI-System Dialog- und Analyseschicht

Data MiningSysteme

OLAPSysteme

Berichtssysteme

Data Warehouse-System

Archivierungssystem

Bereitstellungsschicht

Metadaten

Data Marts

Core Data Warehouse

Monitor

Extraktor

Integrator

ETL-System

originäre Datenschicht

unternehmensexterne Datenquellen

unternehmensinterne Datenquellen

Abb. 11.4  Architektur des Data Warehouse (in Anlehnung an (Bensberg 2010, S. 43))

280

11  Anwendungen zur Entscheidungsunterstützung

den operativen Systemen nicht als Historie geführt. Bei den externen Datenquellen ­handelt es sich um Daten, die durch Fernübertragung von externen Anbietern in das Unternehmen gelangen, beispielsweise über das Internet. Damit die operativen Daten oder auch Daten aus externen Quellen ins Data Warehouse integriert werden können und dort in einer einheitlichen Form vorliegen (In-Flow), sind Extraktions-, Transformations- und Ladeprozesse (ETL-Prozesse) erforderlich. Diese werden durch das ETL-System mit seinen Teilkomponenten realisiert. Monitore dienen der Analyse von Änderungen in den angebundenen Datenquellen, die im Bedarfsfall eine Übertragung von Daten auslösen. Dieser Datentransport aus den Vorsystemen wird mithilfe von Extraktoren abgewickelt, die das Data-Warehouse-System an heterogene Datenquellen anbinden und lesend auf diese zugreifen (Jung 2006, S. 166 ff.). Bevor die extrahierten Daten in dem Data Warehouse gespeichert werden, sind Transformationen vorzunehmen, die eine Filterung, Harmonisierung, Aggregation oder Anreicherung der Datenextrakte leisten. Dabei sind i. d. R. auch organisatorische Abstimmungen zwischen den Organisationseinheiten erforderlich, um eine einheitliche Datenbasis zu schaffen. Als Beispiel kann die mehrfache Speicherung des Informationsobjekts „Kundenname“ in den verschiedenen Teilbereichen der Organisation angeführt werden. So kann der Fall eintreten, dass der Kunde „Fritz Müller KG“ unter den Synonymen „Müller KG“ und „F. Müller KG“ gespeichert wird. Sind die Daten aus den operativen Systemen extrahiert und bereinigt, stellt sich die Frage, wo und in welcher Form sie im Data Warehouse abgelegt werden sollen. Diese Aufgabenstellung wird als Up-Flow bezeichnet. Der ETL-Prozess wird mit dem Laden der vorbereiteten Daten in den Datenbestand des Data-Warehouse-Systems abgeschlossen. Der Zweck des Data-Warehouse-­Datenbestands, der auch als Kerndatenbestand bzw. Core Data Warehouse bezeichnet wird, besteht darin, eine möglichst universelle, vielfältig auswertbare Datenbasis zur betrieblichen Entscheidungsunterstützung zur Verfügung zu stellen. Infolgedessen sind die Data-­Warehouse-­ Daten in einem hinreichenden Detaillierungsgrad zu speichern. Eine verdichtete Speicherung von Daten würde dazu führen, dass Freiheitsgrade bei anschließenden Analysen eingeschränkt werden und eventuell erneute Zugriffe auf die datenliefernden Quellsysteme erforderlich sind, in denen Detaildaten vorgehalten werden. Zur Speicherung des Data-Warehouse-Datenbestands werden zumeist relationale Datenbankmanagementsysteme (RDBMS) eingesetzt. Diese müssen allerdings in der Lage sein, die Arbeitslasten zu bewältigen, die etwa durch periodische Integration operativer Daten in das Data Warehouse oder zeitlich punktuelle Zugriffe von Entscheidungsträgern auf die Datenbestände zustande kommen. Da hierbei häufig hohe Datenvolumina zu verarbeiten sind, verfügen Data Warehouse DBMS über Optimierungsmechanismen zur Sicherstellung akzeptabler Antwortzeiten. Entscheidungsträger werden mit dispositiven Daten entweder durch unmittelbaren Zugriff auf den Kerndatenbestand oder aber mithilfe von Data Marts versorgt, die als abhängige Teildatenbestände aus dem Kerndatenbestand abgeleitet werden. Aus datenbanktechnischer Perspektive handelt es sich bei Data Marts typischerweise um materialisierte Sichten, die in Form von Relationen vorliegen. Diese Sichten sind inhaltlich an den fachlichen Informationsbedarfen der Entscheidungsträger auszurichten. Durch den Aufbau dieser Data Marts als abhängige und im Hinblick auf den Kerndatenbestand redundante

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

281

Teildatenbestände wird die sog. Hub-and-Spoke-Architektur (Nabe- und Speichenarchitektur) realisiert. So werden im Data Warehouse unternehmensintern verteilte oder unternehmensexterne Daten zusammengeführt (In-Flow), die anschließend in Abhängigkeit vom Informationsbedarf der Entscheidungsträger aufbereitet und schließlich wieder herausgeführt werden (Out-Flow). Weitere Elemente des Data-Warehouse-Systems bilden die Metadaten und das Archivierungssystem. Metadaten dienen der Dokumentation fachlicher und technischer Sachverhalte über die im Data Warehouse vorgehaltenen Daten und der zu deren Erzeugung erforderlichen Prozesse. Die Bedeutung von Metadaten erstreckt sich dabei über sämtliche Ebenen des Data-Warehouse-Systems. Auf der untersten Ebene umfassen Metadaten Beschreibungen der erforderlichen ETL-Prozesse und der ausgelesenen Vorsysteme, während auf der Ebene der zentralen Speicherstrukturen (Kerndatenbestand) eine Dokumentation der verfügbaren Datenbestände mithilfe von Datenmodellen zu leisten ist. Auf der Ebene der Data Marts sind hingegen die Teildatenbestände und die zu deren Erzeugung erforderlichen Prozesse zu beschreiben. Metadaten dienen nicht nur der Steuerung des Data-Warehouse-Betriebs, sondern können auch Endbenutzer bei der Interpretation und Suche nach Daten unterstützen. Das Archivierungssystem übernimmt hingegen die Funktion, (Meta-)Datenbestände des Data-Warehouse-Systems zu sichern. Hiermit wird einerseits die Zielsetzung der Datensicherung verfolgt, sodass nach Eintritt von Fehlern eine Rekonstruktion des Data Warehouse erfolgen kann. Andererseits können im Zuge der Archivierung gezielt solche Daten aus dem Kerndatenbestand ausgelagert werden, die nur selten benötigt werden (Mucksch 2006, S. 136 f.). Eine Auslagerung dieser auch als Dormant Data bezeichneten Datenbestände bildet angesichts steigender Datenvolumina im Data Warehouse nicht nur eine wirksame Maßnahme zur Performanzsteigerung, sondern reduziert tendenziell auch die Kosten für die Datenbereitstellung. Die Steuerung dieser Archivierungsvorgänge wird als Down-Flow bezeichnet. Insgesamt stellt das Data-Warehouse-System eine zentrale, einheitliche und konsistente Datenbasis für die Entscheidungsträger des Unternehmens zur Verfügung. Mit dieser Datenbasis können nicht nur die Akteure einzelner Abteilungen oder Organisationsbereiche, sondern im Extremfall auch des gesamten Unternehmens versorgt werden. Dieser Ansatz des Enterprise Data Warehouse gestattet die Konsolidierung abteilungsoder bereichsspezifischer Data-Warehouse-Systeme, die in der Praxis als historisch gewachsene Systeme anzutreffen sind. Auf diese Weise können die Daten unterschiedlicher Organisationsbereiche aufbereitet, untereinander abgestimmt und schließlich zusammengeführt werden. Sowohl Anwender als auch Entwickler benötigen Werkzeuge, um einen einfachen Zugriff auf das Data Warehouse zu erlangen. Damit dies seitens der Anwender ohne besondere Vorkenntnisse möglich ist, müssen Endbenutzerwerkzeuge verfügbar gemacht werden, die die in der jeweiligen Abteilung erforderlichen Geschäftsbegriffe mit den entsprechenden Datendefinitionen verknüpfen und dem Endanwender erlauben, die gewünschten Daten ohne großen Aufwand zu beschaffen. Zu diesem Zweck werden Data-Warehouse-Systeme häufig mit den nun zu beschreibenden Berichtssystemen oder OLAP-Systemen gekoppelt.

282

11  Anwendungen zur Entscheidungsunterstützung

11.2.2 Berichtssysteme Zur Versorgung des Managements mit relevanten Daten werden Berichtssysteme eingesetzt. Bei dieser Bezeichnung steht der Systemoutput im Vordergrund. Die in diesen Systemen erzeugten Berichte (Reports) sollen der Leitungsebene inhaltlich richtige und relevante Informationen zur Verfügung stellen. Berichtssysteme werden aber auch für die „Massenberichterstattung“ eingesetzt (z.  B. über die jährlichen Wertverläufe und -bestände von Lebensversicherungen oder Anlagedepots). In Abhängigkeit von der Auslösung der Berichtserstellung lassen sich aktive Berichtssysteme und passive Berichtssysteme unterscheiden. In aktiven Berichtssystemen erfolgt die automatische Erstellung der Reports zu bestimmten Zeitpunkten oder bei bestimmten Datenkonstellationen. Dabei werden Berichte mit einem weitgehend fest definierten Inhalt für einen bestimmten Adressatenkreis erzeugt. Wird die Berichtserstellung periodisch, also in einem regelmäßigen Turnus angestoßen, z. B. als Monatsbericht mit elementaren betrieblichen Kennzahlen, wird das Ergebnis als Standardbericht bezeichnet. Erfolgt die Auslösung der Reportgenerierung hingegen aperiodisch und in Abhängigkeit von bestimmten Datenkonstellationen, wie z.  B. dem Unterschreiten eines Mindestbetriebsergebnisses, werden die erzeugten Berichte als Ausnahmebericht (Exception Reporting) charakterisiert. Deshalb müssen dem Inhalt und den Adressaten auch die Regeln für das Auslösen der Ausnahmeberichte hinterlegt sein. Dagegen wird in passiven Berichtssystemen die Berichtserstellung durch den Benutzer ausgelöst. In derartigen Systemen hat der Benutzer die Möglichkeit, durch Interaktion mit dem Berichtssystem individuelle Reports zu erstellen, die auf die gewünschte Fragestellung Antwort geben. Um die Anfertigung zu erleichtern, stellen Berichtssysteme hierfür häufig vorgefertigte, parametrisierbare Standardberichte zur Verfügung, die in sog. Berichtsheften (Briefing Books) verwaltet werden. Berichtssysteme sind üblicherweise integraler Bestandteil betrieblicher Standardsoftwaresysteme, wie z. B. SAP ERP. Aus einer Vielzahl vordefinierter Standardberichte können dabei die gewünschten Reports ausgewählt, angepasst und interaktiv verwendet werden. Darüber hinaus sind am Softwaremarkt auch eigenständige Berichtssysteme erhältlich, die an ein breites Spektrum unterschiedlicher Datenquellen angebunden werden können (Gluchowski 2010). Solche Berichtssysteme unterstützen den Entwurf von Berichtsschablonen (Reporting Templates), die inhaltliche und formale Gestaltungsmerkmale für die zu erstellenden Berichte umfassen. Zu diesem Zweck werden Entwicklungsumgebungen eingesetzt, die die Definition der Berichtselemente (z. B. Geschäftsgrafiken, Tabellen) unterstützen. Als Beispiel für eine solche Entwicklungsumgebung wird in Abb.  11.5 das Open-Source-Berichtssystem BIRT (Business Intelligence and Reporting Tools) dargestellt (Ward 2008). Um erstellte Berichtsschablonen mit konkreten Inhalten zu füllen, ist der Bericht auszuführen. Diese Aufgabe übernimmt eine Reporting Engine , die die zentrale Steuerungskomponente von Berichtssystemen darstellt. Sie ermöglicht es, einen Berichtsplan anzulegen, mit dem die Auslösungsart, die Empfänger und das gewünschte Zielformat der einzelnen Berichte definiert werden.

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

283

Abb. 11.5  Entwicklungsumgebung des Berichtssystems BIRT

Eine grundlegende Eigenschaft von Berichtssystemen ist darin zu sehen, dass Berichte lediglich in der Lage sind, vorab fest definierte Sichten auf die zugrunde liegenden Daten zu erschließen. Eine freie Analyse der Datenbasis wird nicht unterstützt. Diese Möglichkeit wird hingegen von OLAP-Systemen erschlossen, die nun zu erörtern sind.

11.2.3 OLAP-Konzept Das OLAP-Konzept ist auf E. F. Codd zurückführen, den Entwickler des relationalen Datenbankmodells (Codd und Codd 1995a, b). Während OLTP für die Verwaltung operativer Daten entwickelt wurde, zielt das OLAP-Konzept darauf ab, Daten (auch aus OLTP-Systemen) speziell für analytische multidimensionale Fragestellungen ­aufzubereiten. Das OLAP-Konzept setzt sich aus spezifischen Bausteinen zusammen, die in Abb. 11.6 dargestellt werden. Im Zentrum der Architektur steht der OLAP-Server. Bei diesem System handelt es sich um einen leistungsfähigen Datenbankserver, der die Daten aus Datenquellen extrahiert und in einer multidimensionalen Datenbank (OLAP-Datenbank) speichert. Bei den Datenquellen kann es sich z. B. um Data Marts handeln, die durch das Data-Warehouse-System zur Verfügung gestellt werden. Darüber hinaus können auch weitere Datenquellen angebunden werden, wie z. B. die Datenbestände operativer Anwendungen.

284

11  Anwendungen zur Entscheidungsunterstützung

OLAPFrontends

Data Marts

Endanwender

OLAPServer Data Warehouse

sonstige Datenquellen Abb. 11.6  Architektur eines OLAP-Systems

Bei den OLAP Frontends handelt es sich um Werkzeuge, mit denen die Datenbestände des OLAP Servers interaktiv untersucht werden können. Zu diesem Zweck werden z. B. eigenständige Betrachtungsprogramme eingesetzt, aber auch spezielle Erweiterungen für Tabellenkalkulationsprogramme (z. B. Add-ons für Microsoft Excel) und WWW-Anwendungen. Die zentralen Funktionalitäten von OLAP Frontends bestehen darin, die verfügbaren Datenbestände für eine dimensionsorientierte Analyse zu erschließen. Zu diesem Zweck werden die Erfolgsgrößen des Unternehmens so strukturiert, dass logisch unabhängige Dimensionen zur Verfügung gestellt werden, in denen der Endanwender über Konsolidierungspfade schrittweise navigieren kann. Der Ausgangspunkt eines Konsolidierungspfads ist die Dimension. Eine Dimension ist eine Menge mit mindestens zwei Elementen, nach der sich Daten eindeutig einordnen und gliedern lassen. Sie eröffnet für den Anwender eine Perspektive, nach der die Daten in der Analyse betrachtet werden. In der Praxis wird eine Vielzahl von Dimensionen benötigt, um alle relevanten Erfolgsgrößen des Unternehmens gliedern zu können. So werden typischerweise die Dimensionen Produkte, Regionen und Vertriebskanäle gebildet und hierarchisiert. Die einzelnen Dimensionen lassen sich miteinander kombinieren. Bei der Kombination von zwei Dimensionen entsteht eine als klassisch zu bezeichnende Tabelle, während die Kombination von drei Dimensionen die räumliche Darstellung in Form eines Würfels erfordert. Die Kombination von mehr als drei Dimensionen ergibt einen Hyperwürfel (Hypercube). Unter Datenkonsolidierung ist der Prozess der Verdichtung von einzelnen Informations­ elementen zu Aggregaten zu verstehen. In der betriebswirtschaftlichen Anwendung bedeutet die Datenkonsolidierung meist die Addition von Erfolgsgrößen. Um die Datenkonsolidierung

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

285

Zeit

Kalenderjahr

Geschäftsjahr

Quartal

Quartal

Monat

Woche

Monat

Woche

Abb. 11.7  Exemplarische Konsolidierungspfade für die Dimension Zeit

zu ermöglichen, ist jede Dimension in eine sinnvolle Anzahl von Ebenen zu zerlegen. Die Ebenen unterscheiden sich nach dem Grad der Verdichtung. Diesen Sachverhalt verdeutlicht Abb. 11.7. Die dargestellten Konsolidierungspfade erlauben die Gliederung der Dimension Zeit nach dem Kalenderjahr und dem hiervon oft abweichenden Geschäftsjahr. Dies zeigt, dass auch parallele Konsolidierungspfade innerhalb einer Dimension anzutreffen sind. Analysiert der Anwender beispielsweise die zeitliche Entwicklung des Umsatzes, kann er zwischen den Pfaden Kalenderjahr und Geschäftsjahr wählen und somit den Analysezeitraum bestimmen. Innerhalb jedes Pfads können dann die Ebenen Quartal, Monat und ggf. Woche durchlaufen werden. Zur Navigation in den Konsolidierungspfaden kommen die Drill-Down- und die Roll-Up-Techniken zum Einsatz. Sofern die Daten eines Konsolidierungspfads aggregiert wurden (Roll Up), ist die Rückdifferenzierung (Drill Down) möglich. Um spezifische Sichten aus dem multidimensionalen Datenmodell abzuleiten, sind die Techniken des Slicing und Dicing anzuwenden. Diese Techniken stellen Sichten in Form von Scheiben bzw. Würfeln dar. Die Anwendung der Dicing-Technik wird in Abb. 11.8 dargestellt. Der Würfel umfasst Elemente für die Dimensionen Zeit, Produkte und Regionen. Durch die Dicing-Technik wird die Extraktion von Teilwürfeln aus dem Würfelkomplex ermöglicht. Dies wird in der Abbildung für den Teilwürfel (Süd, Saft, Quartal 4) durchgeführt. Diesem Teilwürfel wird dabei mindestens eine Erfolgsgröße (z. B. Umsatz oder Deckungsbeitrag) zugeordnet. Die Slicing-Technik ermittelt Scheiben, die aus dem Würfel herausgeschnitten werden. Eine Scheibe zeigt beispielsweise den Umsatz im dritten Quartal von sämtlichen Produkten in allen Regionen. Durch Rotation des Würfels zeigt eine andere Scheibe den Umsatz aller Quartale in sämtlichen Regionen des Produkts Saft. Die Anwendung der Slicing-­ Technik wird in Abb. 11.9 dargestellt.

11  Anwendungen zur Entscheidungsunterstützung

286

West Süd Ost Nord Bier Wasser

Saft

Limonade Süd Saft Quartal 4

Quartal1 Quartal 2 Quartal 3 Quartal 4

Abb. 11.8  Grafische Darstellung der Dicing-Technik (Finkelstein 1996)

Produkt

Umsatz Quartal

Alle Produkte und Regionen für ein Quartal

Alle Regionen und Quartale für ein Produkt

Abb. 11.9  Grafische Darstellung der Slicing-Technik

Region

Alle Produkte und Quartale für eine Region

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

287

Abb. 11.10  Multidimensionale Datenexploration (PowerPlay)

In der praktischen Anwendung werden die relevanten Dimensionen meist in Tabellenform dargestellt. Der Anwender kann die beiden Dimensionen der Tabelle auswählen und dabei den Detaillierungsgrad bestimmen. Häufig wird auch das Schichten (Stapeln) von Tabellen unterstützt. Auf diese Weise wird es möglich, Tabellen in einer weiteren Dimension zu vergleichen. Abb. 11.10 zeigt das OLAP Frontend des Produkts PowerPlay des Herstellers IBM Cognos. Dargestellt wird eine klassische Tabellensicht auf die Kennzahl Umsatz nach zwei Dimensionen (Produkt, Gebiet), die bei Bedarf auch grafisch aufbereitet werden kann. Zur Erstellung solcher multidimensionaler Sichten sind die analyserelevanten Daten zuvor in geeigneter Form zu speichern. In relationalen Datenbankmanagementsystemen wird hierzu das Sternschema (Star Schema) eingesetzt. Im Sternschema werden Faktentabellen angelegt, welche die relevanten quantitativen Datenwerte (Fakten) enthalten, sowie Dimensionstabellen, in denen die Elemente einer Dimension mit den zugehörigen Attributen und hierarchischen Zuordnungen gespeichert sind. Die Abb.  11.11 zeigt ein exemplarisches Sternschema für den Handelsbereich zur multidimensionalen Repräsentation von Verkäufen. Es enthält vier Dimensionstabellen (DT) für die Dimensionen Zeit, Mitarbeiter, Artikel und Vertriebskanal. Die Faktentabelle (FT) enthält für jeden Geschäftsvorfall Verkauf die beiden monetären Kennzahlen Umsatz und Deckungsspanne sowie die mengenorientierte Kennzahl Absatz. Die Schlüssel der einzelnen Dimensionen

288

11  Anwendungen zur Entscheidungsunterstützung DT_Zeit KZeit Kalenderjahr Geschäftsjahr Quartal Monat Tag

DT_Mitarbeiter KMitarbeiter Name Abteilung Land

DT_Artikel

FT_Verkauf KZeit KMitarbeiter KArtikel KVertriebskanal Absatz Umsatz Deckungsspanne

KArtikel Artikelbezeichnung Artikelgruppe Artikeltyp

DT_Vertriebskanal KVertriebskanal Vertriebskanal Vertriebskanaltyp

Abb. 11.11  Exemplarisches Sternschema

bilden gemeinsam den kombinierten Gesamtschlüssel der Faktentabelle. In den Dimensionstabellen sind Attribute hinterlegt, die für die kennzahlenorientierte Analyse (z. B. Filterung nach Land, Artikelgruppe oder Geschäftsjahr) relevant sind. Somit enthält die Faktentabelle die Bewegungsdaten, während die Dimensionstabellen diejenigen Stammdaten enthalten, welche die Bewegungsdaten näher charakterisieren. Zur Abfrage eines Sternschemas werden die Fakten- und Dimensionstabellen miteinander verbunden, etwa mithilfe der SQL-­Anweisung SELECT. Zur fachkonzeptionellen Modellierung multidimensionaler Datenstrukturen von OLAP-Anwendungen (Würfel, Dimension, Kennzahl) haben sich traditionelle Techniken der Datenmodellierung wie etwa Entity-Relationship-Modelle nicht durchsetzen können (Goeken 2006, S. 201 f.). Stattdessen haben sich unterschiedliche, alternative Techniken zur multidimensionalen Modellierung entwickelt (Hahne 2010). Diese können im Rahmen von Informationsbedarfsanalysen dazu eingesetzt werden, um den relevanten ­Realitätsausschnitt aus fachlich-inhaltlicher Perspektive darzustellen. Als Beispiel für eine Darstellungstechnik zur multidimensionalen Modellierung wird im Folgenden die ADAPT-Notation (Application Design for Analytical Processing Technologies) eingeführt (Bulos und Forsman 2006). Die beiden grundlegenden Objekttypen von ADAPT-Modellen sind der Würfel (Cube) und die Dimension. In einem Würfel wird festgehalten, welche Kennzahl abgebildet wird und durch welche Dimensionen dieser strukturiert wird. Im ADAPT-Modell in Abb. 11.12 wird der Würfel Umsatz durch die Dimensionen Zeit, Artikel und Kunde näher bestimmt. Eine Stärke der ADAPT-Notation besteht darin, differenzierte Beschreibungsmittel zur Modellierung der einzelnen Dimensionen und deren Konsolidierungspfade bereitzustellen, welche die Grundlage für Drill-Down- und Roll-Up-Operationen sind. Als Beispiel hierfür wird zunächst die Dimension Zeit aus dem oben stehenden Modellbeispiel in Abb. 11.13 detailliert aufgegliedert.

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

289

Abb. 11.12  ADAPT-Modell zur Bestimmung eines Würfels und seiner Dimensionen

Das dargestellte Modell erfasst für die Dimension Zeit zwei Hierarchien, nämlich die Kalenderjahrhierarchie und die Geschäftsjahrhierarchie. Beide Zeithierarchien eröffnen alternative Konsolidierungspfade zur Analyse des Umsatzwürfels und werden Topdown durch Modellierung untergeordneter Hierarchieebenen (Level) als Konsolidierungsstufen weiter ausdifferenziert. Gemäß den Hierarchiebezeichnungen wird die oberste Hierarchieebene beider Konsolidierungspfade durch das Kalenderjahr bzw. das Geschäftsjahr gebildet. Auf der untergeordneten, zweiten Ebene wird hingegen das Quartal erfasst. Durch die Verbindung der Quartalsebene zum Kalender- bzw. Geschäftsjahr in Form eines Doppelpfeils wird zum Ausdruck gebracht, dass es sich um eine strenge Beziehung handelt. Dies bedeutet, dass jedes Quartal genau einem Kalender- bzw. Geschäftsjahr zugeordnet ist. Auf den nächsttieferen Hierarchieebenen werden der Monat und der Tag erfasst, der schließlich die feinste Granularität der Zeitdimension für die Umsatzanalyse bildet. Neben der Modellierung von Hierarchien gestattet ADAPT die Beschreibung einzelner Elemente durch Attribute und Kategorisierung. Diese beiden Möglichkeiten werden in Abb. 11.14 anhand der beiden Dimensionen Artikel und Kunde des Umsatzwürfels verdeutlicht. Die Artikelhierarchie wird auf der Basisebene durch den Artikel gebildet, der durch drei Attribute (Artikelnummer, Bezeichnung, Preis) näher beschrieben wird. Attribute werden in der ADAPT-Notation entsprechenden Dimensionsebenen zugeordnet. Zur Kategorisierung einzelner Dimensionsebenen stehen in ADAPT unterschiedliche Möglichkeiten zur Verfügung. In Abb. 11.14 wird die Dimensionsebene Kunde mithilfe des Symbols ⊗ in zwei disjunkte Teilmengen (Dimensionsausschnitte) für männliche bzw. weibliche Kunden zerlegt. Die skizzierten ADAPT-Modelle zeigen, dass diese Darstellungstechnik zur anschaulichen und feingranularen Modellierung multidimensionaler Strukturen eingesetzt werden kann. Damit wird die Möglichkeit eröffnet, Informationsbedarfe als Anforderungen an OLAP-Anwendungen auf fachlich-inhaltlicher Ebene zu erfassen und zu dokumentieren. Diese bilden die Grundlage für eine anschließende Informationssystemgestaltung, bei der der Entwurf und die Implementierung der OLAP-Anwendung vorzunehmen ist.

290

11  Anwendungen zur Entscheidungsunterstützung

Abb. 11.13  ADAPT-Modell zur Bestimmung der Dimension Zeit

11.2.4 Mobile Business Intelligence Im Mittelpunkt der Mobile BI steht die Unterstützung mobiler Entscheidungsprozesse, bei denen der Zugriff auf dispositive Daten des Data Warehouse über mobile Endgeräte und unterschiedliche Kommunikationsnetze abgewickelt werden muss. Hierfür sind BI-­ Lösungen als mobil verteilte Systeme zu realisieren, deren Besonderheiten und Potenziale im Folgenden diskutiert werden. Mit der Gestaltung mobiler BI-Systeme entsteht die Herausforderung, bestehende BI-Lösungen an die unterschiedlichen Eigenschaften mobiler Umgebungen und Kontexte

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

291

Abb. 11.14  ADAPT-Modell zur Bestimmung der Dimensionen Artikel und Kunde

anzupassen. Hierbei sind nicht nur die teils sehr unterschiedlichen Kommunikationseigenschaften drahtloser Netze zu berücksichtigen, sondern auch die Heterogenität der Endgeräte. Abb. 11.15 illustriert die Struktur mobiler BI-Systeme, in denen der Zugang sowohl über zellulare Mobilfunknetze (z. B. LTE, 5G) als auch Hotspots (WLAN) stattfinden kann. Zur Gestaltung solcher Systeme sind mobile BI-Komponenten erforderlich, über die Entscheidungsträger auf die Datenbestände des Data-Warehouse-Systems zugreifen können. Hierfür sind zunächst Mechanismen notwendig, die eine Ab- und spätere Wiederankopplung mobiler Entscheidungsträger an das stationäre BI-System leisten (Schill und Springer 2012, S. 291 ff.). Solche Mechanismen haben sicherzustellen, dass die stationären Data Marts des Data-Warehouse-Systems auf den mobilen Endgeräten in Form mobiler Data Marts repliziert und synchronisiert werden, sodass eine konsistente D ­ atengrundlage zur Entscheidungsfindung entsteht. Zur Umsetzung der notwendigen Replikations- und Synchronisationsprozesse können Erweiterungen etablierter, relationaler Datenbanksysteme eingesetzt werden, die den automatischen Abgleich und die Konsistenzsicherung

292

11  Anwendungen zur Entscheidungsunterstützung

Entscheidungsträger

Endgeräte Smartphone

Zugangsarten

PDA

Tablet PC

Notebook

HotspotZugang (WLAN)

Mobiler Zugriff (GSM, LTE, 5G)

Stationärer PC

FestnetzZugang (Gigabit Ethernet, DSL)

Mobile BI-Anwendungen

Mobile BIKomponenten

Mobile BI-Client Datenschicht Mobile Data Marts

Mobilitätsunterstützung durch Replikations-, Synchronisations- und Sicherheitsmechanismen Data Warehouse-System Stationäre Data Marts

Stationäre BI-Komponenten Core Data Warehouse ETL-System

Mobiles BI-System

Abb. 11.15  Mobiles BI-System (in Anlehnung an (Bensberg 2008, S. 76))

zwischen stationären und mobilen Data Marts leisten. Auf dem mobilen Endgerät ist hierfür ebenfalls ein relationales Datenbanksystem zu betreiben, das das Arbeiten mit den mobilen Datenbeständen im abgekoppelten Zustand gestattet. Zum Abgleich der Datenbestände sind Kompressionsverfahren einzusetzen, mit denen die Effizienz der Datenübertragung sichergestellt werden kann. Da solche Data Marts unternehmenskritische Informationen enthalten können, sind dedizierte Sicherheitsmechanismen für den Betrieb mobiler BI-Systeme notwendig.

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

293

Mit solchen Sicherheitsmechanismen ist nicht nur ein unberechtigtes Abhören bei der Datenreplikation zu unterbinden, sondern auch der Zugriff auf mobile Data Marts durch wirksame Authentifizierungs- und Verschlüsselungsverfahren einzuschränken. Auf diese Weise ist auch zu gewährleisten, dass im Fall des Verlusts oder des Diebstahls mobiler Endgeräte die Datenbestände nicht eingesehen und verwertet werden können. Mobile Data Marts bilden die Grundlage für Frontend-Anwendungen, mit denen die Datenbestände auf den Endgeräten für Entscheidungszwecke aufbereitet und visualisiert werden. Hierfür sind mobile BI Clients erforderlich, die Anwendungs- und Dialogfunktionen zur Verfügung stellen. Bei solchen BI Clients sind zwei Ansätze zu unterscheiden. So kann der Zugriff über Thin Clients erfolgen, die auf WWW-Technologien aufsetzen und somit Standardfunktionalitäten anbieten. In diesem Fall werden üblicherweise Webbrowser als BI Frontend auf dem mobilen Endgerät eingesetzt. Rich Clients stellen hingegen eigenständige Anwendungen dar, die über ein breiteres Spektrum an Funktionalitäten verfügen, als dies mit klassischen Browserumgebungen realisierbar ist. So können mithilfe von Rich Clients beispielsweise dynamische Visualisierungstechniken und komplexe Anwendungsfunktionen umgesetzt werden. Diese Rich Clients können auf dem jeweiligen Betriebssystem des Endgeräts (z.  B.  Google Android, Apple iOS) oder einer Java-­ Umgebung aufsetzen. Mit einer systemspezifischen Realisierung können zwar sämtliche Eigenschaften des mobilen Endgeräts (z. B. bestimmte Bedienelemente zur Navigation) genutzt und eine hohe Performanz sichergestellt werden, allerdings wird die Portabilität hierdurch eingeschränkt. Dieser Ansatz kann sich dann als problematisch erweisen, wenn ein breites Spektrum unterschiedlicher Endgeräte von den betrieblichen Akteuren eingesetzt wird. In diesem Fall ist mit einem höheren Aufwand für die Wartung des mobilen BI-Systems zu rechnen. Aufgrund der im Vergleich auf stationären PCs eingeschränkten Visualisierungsund Interaktionsfähigkeiten mobiler Endgeräte werden mobile BI Clients primär zur Realisierung von Berichtsanwendungen und Dashboards eingesetzt. Die hierfür erforderlichen Visualisierungstechniken können auch mit den Ausgabemedien von Smartphones oder Tablets effektiv umgesetzt werden, die eine vergleichsweise geringe Auflösung und Farbtüchtigkeit besitzen. Abb.  11.16 zeigt die Visualisierung einer exemplarischen BI-­Berichtsanwendung mit dem Rich Client des Softwareprodukts IBM Cognos Mobile. Zur Entwicklung solcher BI-Anwendungen werden in der betrieblichen Praxis BI-Werkzeuge eingesetzt, die in Form von Standardsoftwareprodukten am Markt verfügbar sind. Komplettlösungen (BI-Suiten) stellen dabei Entwicklungsumgebungen zur Verfügung, mit denen sämtliche Schichten des BI-Systems implementiert werden können. Auf diese Weise entstehen End-to-End-Lösungen, die durchgängig mithilfe herstellerspezifischer und integrationsfähiger Entwicklungswerkzeuge realisiert werden. Die Entwicklung mobiler BI-Anwendungen erfolgt im Rahmen solcher Komplettlösungen nach dem Prinzip des Single Source Authoring. So können beispielsweise Berichte auf Grundlage

294

11  Anwendungen zur Entscheidungsunterstützung

Abb. 11.16  Beispiel für eine mobile BI-Anwendung (IBM Cognos Mobile)

des Data-Warehouse-Systems erzeugt werden, die anschließend sowohl auf mobilen als auch stationären Endgeräten abrufbar sind. Auf diese Weise müssen zur Entwicklung mobiler BI-Anwendungen einerseits keine manuellen Adaptionen vorgenommen werden, mit denen Berichtsinhalte an die jeweiligen Visualisierungsfähigkeiten des Endgeräts angepasst werden. Andererseits sind keine eigenständigen Entwicklungsumgebungen erforderlich, sodass der zusätzliche Entwicklungsaufwand zur Mobilisierung von BI-­Anwendungen gering gehalten werden kann. Mit dem skizzierten Entwicklungsansatz können vor allem Berichtsanwendungen zur Verfügung gestellt werden, sodass eine höhere Flexibilität des betrieblichen Berichtswesens erzielt werden kann. Weitere Potenziale des Mobile BI gehen aus der Berücksichtigung des Benutzungskontextes hervor, mit der das Verhalten der BI-Anwendung an die jeweilige Anwendungssituation angepasst werden kann. Zu solchen kontextabhängigen

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

295

Informationen sind nicht nur Ort und Zeit der Nutzung zu zählen, sondern insbesondere auch der jeweilige Entscheidungsprozess, der mithilfe der BI-Anwendung abgewickelt wird. Sofern ein solcher Prozesskontext ermittelt werden kann, entsteht eine Grundlage zur Anpassung mobiler BI-Anwendungen an die jeweilige Entscheidungssituation, mit der nicht nur die generelle Gebrauchstauglichkeit (Usability) im mobilen Umfeld gesteigert werden kann, sondern auch die Qualität des Entscheidungsprozesses und der daraus resultierenden Entscheidung.

11.2.5 BI-Systembeispiel: Microsoft Power BI Am Softwaremarkt sind zahlreiche Produkte verfügbar, um BI-Systeme zu entwickeln und zu betreiben. Als Beispiel für ein solches Softwareprodukt wird hier Microsoft Power BI vorgestellt, das insbesondere BI-Funktionalitäten für Endanwender bereitstellt. Grundgedanke ist dabei, dass der Anwender – z. B. der Entscheidungsträger oder ein Assistent – seine eigenen Analysen (z.  B.  Berichte, OLAP-Abfragen, Dashboards) entwickelt und ausführt, ohne dass Mitarbeiter der IT-Abteilung involviert sind. Diese Organisationsform der BI-Entwicklung wird auch als Self Service BI (SSBI) bezeichnet und zielt auf eine flexiblere und agilere Ausgestaltung der dezentralen Informationsversorgung von Entscheidungsträgern (Imhoff und White 2011, S. 5). Die entsprechenden SSBI-Werkzeuge können von der IT-Organisation bereitgestellt, überwacht und betrieben werden. Hinsichtlich der Funktionalitäten von SSBI-Werkzeugen sind drei grundlegende Kategorien zu unterscheiden (Alpar und Schulz 2016, S. 152): • Eine grundlegende Funktionalität von SSBI-Werkzeugen ist die Unterstützung des Zugriffs und der Navigation in bestehenden Berichten. Diese Funktionalitäten zielen auf Geschäftsanwender (Business User), die vorwiegend als Informationskonsumenten agieren und BI-Anwendungen zur Deckung ihres Informationsbedarfs nutzen. Zu diesen Informationskonsumenten gehören etwa Geschäftsführer, Führungskräfte und Manager, aber auch Gelegenheitsanwender (Casual User), die im täglichen Geschäft Entscheidungen fällen müssen. • Außerdem unterstützten SSBI-Werkzeuge auch die Konstruktion neuer Berichte und richten sich damit an Kernanwender (Power User), die im oder unmittelbar für den Fachbereich einer Organisation arbeiten, ein tiefes Verständnis über die Geschäftsprozesse sowie die damit verbundenen Datenflüsse besitzen, und darauf aufbauend BI-Anwendungen entwickeln. Dieser Anwenderkreis nutzt SSBI-Werkzeuge vorwiegend in der Rolle des Informationsproduzenten. • Mit der zunehmenden Verfügbarkeit und Vielfalt neuer Datenquellen steigt die Notwendigkeit, auch diese für Entscheidungszwecke zu erschließen. Hierfür bieten SSBI-­ Werkzeuge die Möglichkeit, neue Datenquellen zu importieren und mit bereits vorhandenen Datenbeständen des Unternehmens zu integrieren.

296

11  Anwendungen zur Entscheidungsunterstützung

Abb. 11.17  Exemplarisches Sternschema (MS Power BI Desktop)

Die Produktlinie MS Power BI umfasst einerseits das Werkzeug Power BI Desktop, das zunächst den Import von Daten aus einer Vielzahl von Datenquellen unterstützt. Zu diesem Zweck können Daten sowohl aus Datenbanken, Dateien (z. B. Tabellenkalkulationsblätter) und Online-Diensten (z. B. Google Analytics) abgerufen und transformiert werden. Dabei können beispielsweise Datentypen transformiert werden oder aber Datensätze nach bestimmten Werten gefiltert werden. Power BI Desktop generiert aus den Nutzereingaben Abfragen in einer eigenen Abfragesprache (Power Query Formula Language). Zur Erstellung eines integrierten Datenmodells – etwa in Form eines Sternschemas (s. Abschn. 11.2.3) – können Beziehungen zwischen unterschiedlichen Tabellen automatisch erkannt werden (Autodetect). Abb. 11.17 zeigt ein exemplarisches Sternschema, das neben der Faktentabelle Bestellungen die beiden Dimensionstabellen Produkte und Kunden enthält. Solche Datenmodelle können vom Anwender generiert und an die eigenen Anforderungen angepasst werden, indem beispielsweise neue Kennzahlen für die Faktentabelle angelegt werden. Hierfür stellt Power BI Desktop die Sprache Data Analysis Expressions (DAX) zur Verfügung, die an die Formelsprache des Tabellenkalkulationsprogramms Micro­soft Excel angelehnt ist und auch die Datenaggregation (z. B. durch Summen- oder Durchschnittsbildung) unterstützt (Aspin 2018, S. 367 f.). Aufbauend auf den skizzierten Funktionalitäten zum Datenmanagement bietet Power BI Desktop die Möglichkeit an, Berichte zu erzeugen. Zu diesem Zweck stehen dem

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

297

Abb. 11.18  Exemplarischer Bericht (MS Power BI Desktop)

Anwender unterschiedliche visuelle Gestaltungselemente (Visuals) zur Verfügung, die in einem Berichtsbereich frei platziert und konfiguriert werden können. Abb. 11.18 zeigt einen exemplarischen Bericht, der ein Flächenkartogramm, ein Balkendiagramm sowie ein Liniendiagramm kombiniert. Der generierte Bericht erlaubt einen interaktiven Durchgriff (Drill-Down) auf Einzelelemente. So führt beispielsweise die Auswahl einer Region im Flächenkartogramm dazu, dass auch in den anderen Diagrammen die Datenselektion entsprechend der ausgewählten Region angepasst wird. Power BI Desktop verfügt über einen Satz von mehr als 25 visuellen Gestaltungselementen für Berichte, die erweitert werden können. So steht ein entsprechendes Open Source Framework zur Verfügung, mit dessen Hilfe die Entwicklung eigener Visuals möglich ist. Dies hat dazu geführt, dass mittlerweile zahlreiche Visuals der Entwicklergemeinde über einen elektronischen Marktplatz bezogen und in eigene Berichte eingebunden werden können. Die generierten Berichte samt Datenmodell und Dateninhalten werden in einer Datei gespeichert, die anschließend über den dedizierten Cloud-Dienst Power BI Services veröffentlicht werden können. Auf diese Weise können neue Berichte, die z. B. von Kernanwendern entwickelt worden sind, von Gelegenheitsanwendern abgerufen und zur Deckung des eigenen Informationsbedarfs genutzt werden. Ebenfalls ist eine Anbindung an das Cloud-Ökosystem Microsoft Azure möglich. Aus ökonomischer Perspektive besitzt die skizzierte Lösung das Potenzial, um sowohl das Kostenniveau als auch die Kostenstruktur im BI-Bereich zu verändern. So steht das Werkzeug Power BI Desktop lizenzkostenfrei zur Verfügung, sodass beispielsweise lizenzkostenpflichtige BI-Lösungen substituiert werden können. Auszahlungen fallen

298

11  Anwendungen zur Entscheidungsunterstützung

lediglich für die Inanspruchnahme des Cloud-Dienstes Power BI Services an, wobei zur Tarifierung die Bezugsgröße Nutzermonat herangezogen wird. Somit variieren die Kosten in Abhängigkeit der tatsächlichen Nutzer und können somit über den Nutzungslebenszyklus beeinflusst werden.

11.2.6 Big Data Unter dem Sammelbegriff Big Data werden Ansätze und Techniken subsumiert, die sich mit der Speicherung, Verwaltung, Analyse und Visualisierung solcher Datenbestände beschäftigen, die aufgrund ihrer quantitativen und qualitativen Eigenschaften mit traditionellen, analytischen Informationssystemen nicht handhabbar sind (Manyika et al. 2011, S. 1). Ein wesentlicher Impuls für die Entwicklung von Big-Data-Techniken bildet das anhaltende Datenwachstum. So unterliegt das Volumen der in wissenschaftlichen und wirtschaftlichen Datenbanken gespeicherten Daten einem exponentiellen Zuwachs. Schätzungen gehen davon aus, dass sich das Volumen der globalen, digital gespeicherten Daten etwa alle zwei Jahre verdoppelt, sodass im Jahr 2020 mit einem globalen Datenvolumen von 40.000 Exabytes (1 Exabyte entspricht 1018 Bytes bzw. 1 Mrd. GB) gerechnet wird (Gantz und Reinsel 2012). Die Gründe für dieses Datenwachstum sind vielfältig. Einen wesentlichen Beitrag liefern die verfügbaren Beobachtungsinstrumente und Methoden, die in den empirischen Wissenschaften eingesetzt werden. In vielen Forschungsbereichen erreichen die generierten Datenmengen Größenordnungen, die mithilfe traditioneller Techniken nicht mehr beherrschbar sind (Lynch 2008). Beispiele hierfür sind etwa astronomische Daten, die von Satelliten zur Erdbeobachtung oder Radioteleskopen generiert werden, oder Simulationsdaten, die für Studien der Klimaforschung berechnet werden. Im ökonomischen Umfeld hat die Verbreitung des Electronic Commerce (s. Abschn. 12.2.3) dazu geführt, dass neue Datenbestände entstanden sind, die einem kontinuierlichen Wachstum unterliegen. So nutzen Anbieter im elektronischen Handel (z.  B.  Amazon, eBay) sowie Betreiber von Suchmaschinen (z.  B.  Google, Yahoo) die Möglichkeit, Nutzerinteraktionen in Form von Clickstreams zu protokollieren und auf dieser Basis Aussagen über das Konsumentenverhalten zu generieren (Bensberg 2001). Durch die breite Akzeptanz von Social-Media-Anwendungen (s. Abschn. 5.4) steht zudem eine Fülle nutzergenerierter Inhalte (User Generated Content) zur Verfügung, mit denen sich aktuelle Themen und Einstellungen in sozialen Netzen untersuchen lassen. Ein zentraler Treiber für das Datenwachstum ist in der automatisierten, sensorbasierten Datenerzeugung zu sehen (Chen et al. 2012), die beispielsweise durch den Einsatz von RFID-Systemen, „intelligenter“ Messstellen (Smart Meter) oder Bewegungssensoren in Smartphones realisiert werden kann. Durch diese „Sensorisierung“ bzw. „Datafizierung“ des Unternehmensgeschehens sind nicht mehr nur direkte, marktbezogene Bereiche wie z. B. Marketing und Vertrieb betroffen. Vielmehr ist auch damit zu rechnen, dass indirekte Unternehmensbereiche, wie etwa das Personalmanagement (Strohmeier et al. 2016), in verstärktem Maße neuartige Datenbestände zur Unterstützung und Automatisierung erschließen werden.

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

299

Die charakteristischen Merkmale der skizzierten Datenkategorien des Big Data und die damit verbundenen Herausforderungen für deren Verarbeitung können mithilfe des 3V-Modells (Russom 2011, S. 6) anhand der Dimensionen Volume, Velocity sowie Variety systematisiert werden: • Die kontinuierliche Sammlung von Daten führt dazu, dass sich in Unternehmen Datenkollektionen anhäufen, die zunehmend höhere Speichervolumina (Volume) beanspruchen. Hierfür sind Infrastrukturen notwendig, die eine kostengünstige Speicherung gestatten und geeignete Mechanismen bereitstellen, um benötigte Daten in analysefähiger Form zur Verfügung zu stellen. • Durch die Nutzung neuer Datengewinnungsinstrumente nimmt die Geschwindigkeit (Velocity) zu, mit der Daten in Unternehmen erzeugt werden. Um zeitnah auf kritische Ereignisse reagieren zu können, sind Techniken erforderlich, welche die anfallenden Daten in Echtzeit analysieren. • Unternehmen sind zunehmend mit einer höheren Datenvielfalt (Variety) konfrontiert. Traditionell konzentriert sich das betriebliche Datenmanagement auf stark strukturierte Datenbestände, die sich mithilfe von RDBMS effizient verwalten und auswerten lassen. Internetbasierte Inhalte (z. B. Blogs, Diskussionsforen, Bilder, Videos) und Sensordaten besitzen jedoch nur einen geringen Strukturierungsgrad, sodass alternative Speicher- und Auswertungstechniken erforderlich werden. Die praktische Bedeutung dieser drei Merkmale sei anhand eines Beispiels aus dem Maschinenbau verdeutlicht. Überwachung und Diagnose bei komplexen technischen Systemen

Lösungsanbieter: Empolis Information Management GmbH Problem: In vielen Bereichen des Maschinenbaus – wie auch in der Energietechnik – wandelt sich zurzeit das Geschäftsmodell von einer reinen Lieferantenrolle hin zum Dienstleister, d. h. Betreiber der Anlage. Dadurch wächst die Bedeutung von Service und Support. Es findet eine Transformation des Service vom Cost Center hin zum Profit Center statt. Telematik und Remote Service sind die technologischen Bausteine, die dies ermöglichen und doch auch eine große Herausforderung darstellen. Moderne Produktionsmaschinen sind mit einer Vielzahl von Sensoren ausgestattet. Die überwachten Geräte liefern kontinuierlich Daten über den Zustand der Maschine und ihrer Komponenten. Dazu gehören normale Vorgänge wie das Anfahren oder Stoppen eben­so wie Ereignismeldungen, Warnungen und Fehlercodes. Lösung: Die gelieferten Daten werden auf relevante Ereignisse hin untersucht, um so den allgemeinen Zustand der Maschine zu ermitteln. Bei einem Vergleich mit der Historie von Instandsetzungsvorgängen  – als Folge von Problemen an der Maschine – werden Trends erkannt und ggf. präventive Maßnahmen eingeleitet. Bei Störfällen helfen ähnlich gelagerte Fälle aus der Vergangenheit bei der schnellen Fehlerbehebung.

300

11  Anwendungen zur Entscheidungsunterstützung

Big-Data-Merkmale: • Volume: Jedes Gerät liefert täglich mehrere Gigabyte an strukturierten und unstrukturierten Daten, die vom Remote Service bearbeitet werden müssen. Das Anwenderunternehmen verfügt aktuell über mehr als 1000 Installationen entspre­chender Geräte. • Variety: Die Daten unterscheiden sich je nach Gerätetyp im Format und Inhalt. • Velocity: Die Daten müssen annähernd in Echtzeit nach relevanten Vorfällen durchsucht und verdichtet werden. Bei 1000 Geräten sind dies 3,5 GB pro Minute. BITKOM (Hrsg.): Big Data im Praxiseinsatz, Berlin 2012, S. 71. Wie das Beispiel verdeutlicht, müssen Big-Data-Anwendungen größere, unterschiedlich strukturierte Datenmengen schnell und wirtschaftlich verarbeiten können. Traditionelle BI-Architekturen (s. Abschn. 11.1) sind hierfür jedoch nur begrenzt geeignet. Infolgedessen wurden neue Konzepte und Techniken entwickelt, die diesen Anforderungen gerecht werden können. Wesentliche Komponenten eines Big-Data-Systems zeigt Abb. 11.19. Den Kern des dargestellten Architekturmodells bildet ein Datenspeicher (Data Store), der unterschiedliche Datenkategorien speichert. Big-Data-Lösungen basieren schwerpunktmäßig auf NoSQL (Not Only SQL)-Datenbanken, die zumeist eine verteilte Datenhaltung unstrukturierter Daten ermöglichen. Durch Verzicht auf eine tabellenorientierte Datenorganisation, wie sie für RDBMS typisch ist, erzielen NoSQL-Datenbanken in Big-Data-Anwendungen eine tendenziell höhere Leistungsfähigkeit und Skalierbarkeit. Big Data-System Bereitstellungsschicht

Data Delivery Service

Datenvisualisierung

Analyseschicht

Big Data Mining

Text Analytics

Streaming Analytics

Datenspeicher Document Store

Key/Value-Store

In-Memory-Store

Speicherschicht Datenaufnahme

Sensordaten

Datenquellen

• • • • • •

Smart Meter RFID-Systeme GPS-Sensoren Audiodatenströme Videodatenströme ...

Web-basierte Inhalte • • • •

User Generated Content Foren und Blogs Social Media-Inhalte Multimedia-Sites (Fotos, Videos) • Finanzmarktdaten • E-Mails • ...

Verhaltensdaten • • • • •

Kauftransaktionen Logfiles und Clickstreams Web-Suchanfragen Likes und Tweets Verbindungsdaten (Telekommunikation) • ...

Abb. 11.19  Architektur eines Big-Data-Systems (in Anlehnung an (Mohanty) et al. 2013, S. 147)

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

301

Zur Speicherung web-basierter Inhalte (z.  B. in Form von HTML- oder XML-­ Dokumenten) werden Dokumentendatenbanken (Document Stores) genutzt, in denen Dokumente beliebiger Länge in Form von Objekten abgelegt werden. Eine einfache und performante Speichertechnik bieten Schlüssel/Werte-Speicher (Key/Value Stores) an. Diese ordnen einem bestimmten Schlüssel (Key) einen Wert zu, der beliebige Datentypen (z. B. Zeichenfolgen, Messdaten, Bilder) besitzen kann. In-Memory-Datenbanken (IMDB) halten die Daten im Arbeitsspeicher und stellen auf diese Weise eine hohe Performanz sicher. Zur Bewirtschaftung dieser Datenspeicher verfügen Big-Data-Systeme über Komponenten zur Datenaufnahme (Big Data Ingestion, Mohanty et al. 2013, S. 148). Ähnlich wie ETL-Systeme (s. Abschn.  11.2.1) übernehmen diese Aufgaben zur Extraktion, Transformation und Laden von Daten in den Zieldatenspeicher. Im Unterschied zu traditionellen Data-Warehouse-Systemen müssen diese Komponenten in der Lage sein, unterschiedlich strukturierte Daten mit hoher Geschwindigkeit zu verarbeiten. Die Analyseschicht von Big-Data-Systemen umfasst Komponenten zur Auswertung der Datenbestände. Im Gegensatz zu traditionellen Data-Warehouse-Systemen steht dabei nicht die Erstellung vordefinierter Berichte oder OLAP-Datenbestände mit ex ante definierten Kennzahlen im Mittelpunkt, sondern die explorative Datenanalyse, die häufig ad hoc erfolgt. Analytische Komponenten sind aufgrund der hohen Datenvolumina so ausgelegt, dass eine parallele Verarbeitung der Analyseoperationen auf mehreren Rechnersystemen stattfinden kann. Zur Erkundung von Datenbeständen werden Instrumente für die Datenvisualisierung eingesetzt, die mithilfe von Techniken der grafischen Datenverarbeitung die Präsentation großvolumiger und hochdimensionaler Datenräume gestatten. Hierfür sind in der jüngeren Vergangenheit moderne Diagrammtypen (z. B. Baum- und Netz-Diagramme, Dambeck 2013) entwickelt worden, mit denen grundlegende Zusammenhänge in Datenbeständen vom Anwender visuell entdeckt werden können (Visual Analytics). Im Unterschied zum klassischen Berichtswesen, in dem die visualisierten Sachverhalte durch das Informationsdesign fixiert sind, zeichnen sich Visual-Analytics-Anwendungen dadurch aus, dass die Nutzer die Daten frei und interaktiv explorieren können (Kohlhammer et  al. 2018). Ein Beispiel für eine solche Anwendung ist die kostenfrei verfügbare Software Gapminder, die länderspezifische Daten von UN-Organisationen visualisiert. Dabei wird die Entwicklung der Zeitreihen dynamisch animiert, sodass Korrelationen und Tendenzen in den raum- und zeitbezogenen Daten durch den Nutzer erkannt werden können. Abb.  11.20 zeigt eine exemplarische Visualisierung der Bevölkerung (Population) anhand eines Kartogramms. Darüber hinaus verfügen Big-Data-Architekturen über Komponenten, die mithilfe statistisch-­mathematischer Methoden Muster in Datenbeständen entdecken können (Big Data Mining, Fan und Bifet 2012). Diese Werkzeuge bieten Verfahren an, die der Segmentierung (Clustering), Klassifikation und Regression dienen, und meist nur stark strukturierte, quantitative Daten verarbeiten (s. Abschn. 2.3.3.4). Zur Erschließung von Textdokumenten, deren Inhalte nur relativ schwach ausgeprägte Beziehungen zueinander aufweisen, sind hingegen linguistische Ansätze für

302

11  Anwendungen zur Entscheidungsunterstützung

Abb. 11.20  Gapminder als Instrument zur Visualisierung raum- und zeitabhängiger Daten

die Textanalyse (Text Analytics) erforderlich (s. Abschn.  2.3.3.5). Als grundlegende Aufgabenstellungen bei der Textanalyse sind die folgenden zu nennen (Feldman und Sanger 2006): • Mithilfe der Textklassifikation können einzelne Dokumente bestimmten Klassen zugeordnet werden. Ein Anwendungsfeld in Unternehmen ist beispielsweise die Zuordnung von eingehenden E-Mails zu vordefinierten Klassen (z.  B.  Bestellung, Beschwerde, Stornierung). Zur Textklassifikation stehen Verfahren des maschinellen Lernens zur Verfügung, die mithilfe einer Trainingsmenge von Dokumenten (z.  B. historische E-Mails mit bekannter Klassenzugehörigkeit) angelernt werden. Der resultierende Klassifikator kann anschließend dazu genutzt werden, um die Klassenzugehörigkeit neuer E-Mails zu prognostizieren. Diese Aufgabenstellung ist auch für die Gestaltung von ChatBots von Bedeutung, da diese von den Eingaben der Anwender auf deren Intention schließen müssen (Khan und Das 2018, S. 27). • Bei der Textsegmentierung (Clustering) werden Dokumentkollektionen in Klassen eingeteilt, wobei die Klassen aus den Merkmalen der Dokumente selbst abgeleitet werden und nicht durch den Anwender vorgegeben werden. Auf diese Weise können beispielsweise interessante Subgruppen in bestehenden Dokumentkollektionen aufgedeckt werden, die über ähnliche Inhalte verfügen. Ein exemplarisches Anwendungsfeld der Textsegmentierung ist die Analyse von Störungsmeldungen (Incidents) in einem IT-Servicecenter. Durch Clustering können beispielsweise Störungsmeldungen mit gleichen Inhalten (z. B. mit den Substantiven Login, Anmeldung, Passwort) automatisch erkannt werden. • Mithilfe der Sentimentanalyse (Stimmungsanalyse, Sentiment Detection) werden Texte im Hinblick auf die positive, neutrale oder negative Einstellung des Autoren gegenüber

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

303

bestimmten Bewertungsobjekten (z.  B.  Produkte, Dienstleistungen) untersucht. Ein etabliertes Anwendungsfeld der Sentimentanalyse bildet die Untersuchung, ob der Kursverlauf einer Aktie mit der veröffentlichten Meinung (z.  B.  Twitter) korreliert (Neubauer 2014, S. 207). Als Grundlage für Text Analytics können neben unternehmensinternen Dokumentenbeständen (z.  B.  Geschäftsberichte, Projektdokumente, interne E-Mails) auch unternehmensexterne Dokumente herangezogen werden. Gängige Quellen bilden beispielsweise die sozialen Medien (z. B. Twitter, Facebook), E-Commerce-Plattformen (z. B. Amazon, eBay) sowie Suchmaschinen (z.  B.  Google) oder Literaturdatenbanken (z.  B.  Google Scholar, SpringerLink). Der Zugriff auf solche Datenbestände kann einerseits – wie beispielsweise bei Twitter – per Programmierschnittstelle (API, s. Glossar) erfolgen. Andererseits besteht die Möglichkeit, Inhalte per Web Scraping auszulesen. Analyse von Stellenanzeigen mit Text Analytics

Der Bereich Personalentwicklung (Human Resource Development, HRD) eines deutschen Telekommunikationsunternehmens möchte Klarheit darüber gewinnen, welche Kompetenzen im Umfeld von IT-Zukunftsthemen (z.  B.  Data Science, Big Data) am Arbeitsmarkt nachgefragt werden. Zu diesem Zweck werden Stellenanzeigen gesammelt und ausgewertet, die in entsprechenden Job-Portalen (z. B. Monster, StepStone, JobServe) als digitale Dokumente zur Verfügung stehen (Bensberg und Buscher 2016). Folgende Abbildung zeigt den Aufbau der Analysepipeline, mit der die schrittweise Verarbeitung der Rohdaten erfolgt. Analyst

Job-Portale

Analysepipeline für Text Analytics Extraktor

Stellenanzeigen (Rohdaten)

Dokumentprozessoren

Analysedatenbestand

Analysemethoden

Abfrage- und Berichtsdienste

Mit dieser Pipeline werden ausgewählte Job-Portale periodisch auf neue Stellenanzeigen untersucht, die mithilfe eines Extraktors in eine lokale Rohdatenbasis überführt werden (Web Scraping). Diese Rohdaten werden mithilfe von Dokumentprozessoren vorverarbeitet. Im Zuge der Vorverarbeitung erfolgt die Tokenisierung und das POSTagging. Außerdem wird ein Index für sämtliche Wörter aufgebaut. Aufbauend auf dieser Datenvorbereitung werden schließlich Techniken zur Textanalyse eingesetzt.

304

11  Anwendungen zur Entscheidungsunterstützung

Zur Untersuchung von Stellenanzeigen werden häufig Korrelations- und Frequenzana­ lysen genutzt, um z. B. die Häufigkeiten zu ermitteln, mit denen bestimmte Produkte, Programmiersprachen und Soft Skills in den Stellenanzeigen für bestimmte Berufsbilder genannt werden. Durch Auswertung von n  =  1.942 englischsprachigen Stellenanzeigen für das Berufsbild des Data Scientist konnte festgestellt werden, welche Kompetenzen dieses Tätigkeitsfeld prägen. Die folgende Abbildung zeigt, welche Konzepte und Programmiersprachen für das Berufsbild Data Scientist am wichtigsten sind (Top 10). Konzepte 0% Big Data Machine Learning

20%

40%

Programmiersprachen 60%

80%

100%

0%

10%

20%

30%

40%

50%

60%

Python SQL

Data Mining

R

Predictive Analytics

Java

Data Analysis

MATLAB

Business Intelligence

C++

Natural Language Processing

NoSQL

Relational Databases

PERL

Data Visualization

Scala

Reporting

C#

Open Source

C

Diese Ergebnisse sind für die Personalentwicklung des Telekommunikationsunternehmens wichtig, um neue Berufsbilder und deren Kompetenzanforderungen frühzeitig und detailliert zu erkennen. Auf dieser Grundlage kann schließlich eine gezielte Weiterbildung bestehender Mitarbeiter oder die Rekrutierung neuer Mitarbeiter ­erfolgen. Sämtliche skizzierten Komponenten basieren auf der Analyse eines ex ante fixierten, statischen Datenbestands, der im Datenspeicher des Big-Data-Systems verfügbar gehalten wird. Wie das vorangegangene Praxisbeispiel gezeigt hat, müssen im Big-Data-Kontext jedoch auch Datenströme mit einer hohen Datendichte zeitnah verarbeitet werden können. Unter einem Datenstrom ist dabei eine in der Länge meist unbeschränkte Sequenz von Datenelementen zu verstehen, die in Echtzeit verarbeitet werden muss (Bifet et  al. 2011, S.  6). Solche Datenströme können z.  B.  Einzelhandels- und Finanzmarkttransaktionen, Ereignisse in Telekommunikationsnetzen oder Messdaten aus Sensornetzwerken abbilden. Zur Analyse solcher „fließender Daten“ dienen Instrumente des Streaming Analytics. Diese sind in der Lage, bestimmte Ereignisse und Bedingungskonstellationen in Datenströmen fortlaufend zu erkennen und daraufhin bestimmte Aktionen durchzuführen. Im Mittelpunkt der Entwicklung solcher Analysesysteme steht die Formulierung entsprechender Reaktionen, die bei Erkennung kritischer Ereignisse auszulösen sind, wie etwa die gezielte Steuerung operativer Geschäftsprozesse. Um die Ergebnisse weiter zu verwenden, die mithilfe dieser Analysekomponenten generiert werden, ist im Architekturmodell eine Komponente für die Datenbereitstellung

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

305

(Data Delivery Service) fixiert. Diese hat die Aufgabe, relevante Informationen an Informationsverwender weiter zu leiten. Dabei kann es sich um menschliche Akteure (z. B. Entscheidungsträger) handeln, aber auch um Anwendungen, die Daten für die Abwicklung von Geschäftsprozessen benötigen. Zum Aufbau von Big-Data-Systemen steht mittlerweile ein breites Spektrum unterschiedlicher Softwareprodukte zur Verfügung, wobei insbesondere Open-Source-Produkte hohe Bedeutung erlangt haben. Hervorzuheben sind die Programmiersprache R zur mathematisch-­statistischen Datenanalyse sowie das Framework Apache Hadoop für die verteilte Datenhaltung (Chen et al. 2012). Zur analytischen Verarbeitung großvolumiger Datenbestände im Big-Data-Umfeld hat das Framework Apache Spark große Bedeutung erlangt. Es stellt u. a. Dienste zur Verarbeitung von Datenströmen und Algorithmen für maschinelle Lernverfahren bereit, die zur Wissensentdeckung eingesetzt werden können. So stehen zwar die grundlegenden Analysetechnologien zur Verfügung, indes erfordert die Exploration großvolumiger Datenbestände meist hohe Rechen- und Speicherkapazitäten. Zum Abbau dieser Investitionsbarriere bietet sich der Einsatz von Mechanismen des Cloud Computings an, mit denen notwendige Ressourcen bei Bedarf von einem IT-Dienstleister bezogen werden können. Darüber hinaus bildet die Identifikation, Bereinigung und Integration relevanter Datenbestände einen kritischen Erfolgsfaktor für Big-Data-Lösungen. Da Datenbestände in der betrieblichen Praxis meist in unterschiedlichen Unternehmensbereichen verteilt vorliegen und kontinuierlich geändert werden, müssen analyserelevante Daten häufig wiederholt integriert, angereichert und bereinigt werden. Zur Rationalisierung der datenlogistischen Prozesse im Umfeld von Big-Data-Projekten gewinnt daher das Organisationskonzept des Data Lake an Bedeutung. Unter einem Data Lake ist ein zentralisierter Datenspeicher zu verstehen, der Datenbestände aus unterschiedlichen Quellen zusammenführt und für analytische Operationen zur Verfügung stellt (Chessell et  al. 2014). Die verfügbaren Datenbestände (Repositorien) des Data Lake werden in einem Katalog verzeichnet und bei Änderungen der Originaldaten sychronisiert. Der Aufbau eines Data Lake wird in Abb. 11.21 dargestellt. Aus der Abbildung wird deutlich, dass ein Data Lake mit der IT-Landschaft des Unternehmens sowie anderen Data Lakes verknüpft ist. Auf diese Weise können nicht nur die Daten aus operativen Anwendungen (z. B. ERP- und E-Business-Systemen) extrahiert und im Data Lake vorgehalten werden, sondern etwa auch öffentliche Daten (Open Data) integriert und zur Anreicherung genutzt werden. Die Verwaltung der vorgehaltenen Daten übernehmen Informationskuratoren, zu deren Aufgaben auch die Pflege des Datenkatalogs gehört. Das Governance & Compliance Team hat demgegenüber dafür zu sorgen, dass die unternehmensinternen Richtlinien und Regularien für das Datenmanagement auch im Umfeld des Data Lake eingehalten werden. Nach diesen Vorgaben erfolgt auch der Betrieb des Data Lakes als Teil der betrieblichen IT-Infrastruktur. Die Nutzung der bereitgestellten Daten findet einerseits durch die analytischen Anwendungen der Fachabteilungen auf Basis von Self-Service-Schnittstellen statt (Alpar und Schulz 2016). Andererseits

306

11  Anwendungen zur Entscheidungsunterstützung

Entscheidungsmodelle

UnternehmensIT als Datenquelle

Data Lake

Externe Data Lakes

Informationskuratoren

Governance & Compliance Team

Analytische Anwendungen der Fachabteilungen

Data Lake Betrieb

Abb. 11.21  Data Lake (nach Chessell et al. 2014, S. 8)

nutzen Data Scientists und Big-Data-Analysten (s. Kap. 15) das Repositorium zur Kon­ struktion und Anwendung von Entscheidungsmodellen. Bei der betrieblichen Einführung und Nutzung von Big-Data-Techniken sind deren Risiken zu berücksichtigen. Durch die Speicherung, Auswertung oder Auslagerung großvolumiger Datenbestände an IT-Dienstleister können rechtliche Risiken induziert werden, insbesondere dann, wenn personenbezogene Daten verarbeitet werden (BITKOM 2013, S. 24). In diesem Fall können Techniken der Anonymisierung oder Pseudonymisierung eingesetzt werden, um rechtliche Problemfelder bei der Datennutzung zu vermeiden. Schließlich gehen aus dem großflächigen Einsatz von Big Data durch ­Regierungorganisationen (Big Government) auch gesellschaftliche Risiken einher, die zu einem Verlust der individuellen Freiheit führen können (Schulz 2014). Dieses Problemfeld ist im Rahmen einer gesellschaftlichen Diskussion zu adressieren, die Impulse für die Weiterentwicklung der grundrechtlich fundierten Regularien zur Sammlung und Auswertung personenbezogener Daten liefert. Als Systembeispiel für eine Big-Data-Lösung wird im Folgenden die Plattform SAP HANA vorgestellt.

11.2.7 Big-Data-Systembeispiel: SAP HANA Die Verfügbarkeit neuer Technologien zur Datenverarbeitung bei sinkenden Speicherkosten führt dazu, dass die klassischen Architekturansätze für Datenbanksysteme zunehmend überarbeitet und weiterentwickelt werden. Um die unterschiedlichen Anforderungskriterien bei der analytischen und operativen Datenverarbeitung zu erfüllen, werden verstärkt hybride Datenbankarchitekturen eingesetzt, in denen diverse Technologien miteinander kombiniert werden (Färber et al. 2010, S. 81). Als Produktbeispiel für einen solchen hybriden Ansatz

307

11.2 Allgemeine Komponenten von Entscheidungsunterstützungssystemen

wird hier SAP HANA (High Performance Analytic Appliance) vorgestellt, das von der SAP SE als Technologie- und Entwicklungsplattform für die operative und dispositive Datenverarbeitung positioniert wird. Die grundlegende Architektur von SAP HANA zeigt Abb. 11.22. Grundlage von SAP HANA als Big-Data-System bildet die technische Fähigkeit, Daten aus unterschiedlichen Quellsystemen (Source) mit verschiedenen Datentypen speichern und verarbeiten zu können. Hierzu gehören nicht nur Daten aus ERP-Systemen bzw. generell transaktionsorientierte Daten aus OLTP-Systemen, sondern auch ­Social-­Media-­Quellen und Daten aus sensor- bzw. maschinenbasierten Quellen. Diese werden in der Speicherschicht (Store) des SAP HANA-Systems verfügbar gemacht, wobei unterschiedliche Speichertechnologien zum Einsatz gelangen können. Kern der Speicherschicht bildet eine IMDB, die alle relevanten Daten im Hauptspeicher eines Rechnersystems (Random Access Memory, RAM) ablegt, sodass diese direkt zur Auswertung zur Verfügung stehen. Im Gegensatz zu festplattenzentrierten Datenbanken (On-Disk-Datenbanken) entsteht damit der Vorteil, dass medienspezifische Eigenschaften, wie z. B. Blockstrukturen und auf diesen aufbauende Indizes, in den Hintergrund treten und deutliche Effizienzgewinne bei der Verarbeitung erzielt werden können. Des weiteren ist bei der Ablage der Daten die Art der physischen Datenorganisation von Bedeutung, die in Abhängigkeit vom Verwendungszweck der Daten zu bestimmen ist. So wird für transaktionsorientierte Systeme, deren typische Verarbeitungsoperationen in der Erzeugung oder Änderung ganzer Datensätze bestehen, häufig eine zeilenbasierte Datenorganisation gewählt. In diesem Fall werden die einzelnen Attribute eines Datensatzes (Zeile) nacheinander auf dem Datenspeicher abgelegt, sodass sie sich in zusammenhängenden Blöcken befinden. Sollen jedoch Daten verdichtet werden, wie dies bei EUS häufig der Fall ist, ist eine spaltenbasierte Datenorganisation zu empfehlen. In diesem Fall werden die Werte eines Attributs (Spalte) nacheinander auf dem Datenspeicher abgelegt, Consume

BI |Reporting | Ad-hoc Analysis | OLAP | Planning | Unstructured Data Discovery | Predictive | Apps

SAP HANA Compute

Stream Processing

Event Stream Data

Store

Source

Analytics Engine

ERP

OLTP

Predictive Engine

Text Engine

Dynamic Tier Data

In-MemoryData

Geo

Logs

Text

Abb. 11.22  SAP HANA-Architektur (in Anlehnung an (SAP 2016))

Spatial Processing

Social

Machine

Sensor

308

11  Anwendungen zur Entscheidungsunterstützung

sodass diese effizient ausgelesen und aggregiert werden können. Diese beiden Arten der physischen Datenorganisation werden anhand eines Beispiels in Abb.  11.23 dargestellt (Knabke und Olbrich 2016, S. 191). Die Datenbank enthält drei Datensätze (Zeilen) mit je drei Attributen (Spalten). In einer zeilenbasierten Datenbank wird jede Zeile in sequenziellen Blöcken des Speichermediums abgelegt, während bei der Spaltenorganisation die Werte der einzelnen Spalten nacheinander gespeichert werden. SAP HANA gestattet es, Tabellen zeilen- oder spaltenbasiert im Hauptspeicher abzulegen. Neben der In-Memory-Speicherung verfügt SAP HANA auch über eine klassische plattenbasierte Datenbankkomponente, mit der die Persistenz von Datenbeständen sichergestellt wird. Aus Gründen der Wirtschaftlichkeit sind außerdem Daten, die zur Archivierung bestimmt sind oder aber selten genutzt werden, auf langsamere, kostengünstigere Medien (Festplattenspeicher) auszulagern. Hierfür sorgt ein dynamisches Tiering, das in Abhängigkeit von der Relevanz einzelner Tabellen unterschiedliche Speichermodi vorsieht (Silvia et al. 2017, S. 50). So werden häufig benutzte, „heiße“ Daten (Hot Data) in der Hauptspeicherdatenbank vorgehalten, während „warme“ Daten mittlerer Nutzungsfrequenz in einer On-Disk-Datenbank abgelegt sind und für Lese- bzw. Schreibzugriffe zur Verfügung stehen. Zu archivierende Daten werden hingegen außerhalb der SAP HANA-­Lösung auf dedizierten Servern (Near Line Storage, NLS) abgelegt und stehen für Lesezugriffe zur Verfügung. Eine weitere Speicheroption der SAP HANA-Plattform unterstützt die Abbildung von Datenströmen (Event Stream Data). Datenströme, die von verschiedenen Quellen wie Sensoren, Überwachungsinfrastrukturen oder WWW-Quellen (z. B. Clickstreams, Twitter) zur Verfügung gestellt werden, können in SAP HANA mithilfe von virtuellen Tabellen abgebildet und kontinuierlich überwacht werden. Zur Analyse von Daten (Compute) stellt SAP HANA unterschiedliche Komponenten zur Verfügung (Silvia et al. 2017, S. 101 ff.): • Stream Processing dient der analytischen Verarbeitung von Datenströmen. Zu diesem Zweck können kontinuierliche Abfragen definiert werden, die dauerhaft auf die eingehenden Datenströme angewendet werden und beispielsweise zur Detektion kritischer Ereignisfolgen dienen. • Die Komponente Analytics Engine wird eingesetzt, um multidimensionale Auswertungsrechnungen (s. Abschn. 11.2.3) zu erstellen. • Die Predictive Engine stellt Verfahren des maschinellen Lernens und der multivariaten Datenanalyse zur Verfügung (z. B. für die Zeitreihenanalyse, Klassifikation und Segmentierung). • Zur Analyse von Textdaten bietet die Text Engine entsprechende Verfahren an, die ein breites Spektrum unterschiedlicher Aufgabenstellungen unterstützen. Hierzu gehören z. B. die Sentiment Detection (Stimmungsanalyse) von Texten und die Texterkennung auf Basis selbstdefinierter Wörterbücher (Custom Dictionaries). • Die Komponente Spatial Processing enthält Funktionalitäten zur Verarbeitung raumbezogener Daten (Spatial Data). Hiermit kann etwa eine Geokodierung von Adressdaten durchgeführt werden oder aber raumbezogene Relationen (z. B. Distanzen, Nachbarschaften) zwischen Objekten aufgedeckt werden.

11.3 Anwendungsbeispiele für aufgabenorientierte …

s1

Spalten

Zeilenorientierte Datenorganisation

s2

v11 v12 v13 v21 v22 v23 v31 v32 v33

s3

309

Zeilen

z1 v11 v12 v13 z2 v21 v22 v23

v11 v21 v31 v12 v22 v32 v13 v23 v33

z3 v31 v32 v33

Spaltenorientierte Datenorganisation

Abb. 11.23  Arten der physischen Datenorganisation (in Anlehnung an (Knabke und Olbrich 2016, S. 191))

Die oberste Schicht der SAP HANA-Architektur stellt die skizzierten Funktionalitäten über entsprechende Anwendungen zur Verfügung. Zur Erstellung von Berichten auf Grundlage relationaler Daten bietet sich der Einsatz von SAP Lumira an, das Funktionen zur Filterung, Verdichtung und Visualisierung von Berichtsdaten aus SAP HANA besitzt. Zur Unterstützung von Data-Mining-Analysen steht das Werkzeug SAP Predictive Analytics zur Verfügung, mit dem Data-Mining-Prozesse visuell modelliert und ausgeführt werden können. In den vorangehenden Abschnitten sind generelle Komponenten und Lösungen für datenorientierte EUS vorgestellt worden. Im Folgenden werden nun aufgabenorientierte EUS thematisiert, die formalisierte Methoden zur Handhabung betrieblicher Planungsund Entscheidungsprobleme zur Verfügung stellen.

11.3 A  nwendungsbeispiele für aufgabenorientierte Entscheidungsunterstützungssysteme 11.3.1 Integrierte Erfolgs-, Finanz- und Bilanzplanung 11.3.1.1  Aufgabenstellung Die Planung von erfolgs- und finanzwirtschaftlichen Zielen gehört zu den traditionellen Aufgaben des Controllings. Häufig fehlt eine sachliche Abstimmung zwischen Bilanz-, Erfolgs- und Finanzrechnung. Außerdem ist die Unternehmensplanung regelmäßig durch Brüche zwischen der kurz-, mittel- und langfristigen Planung gekennzeichnet. Zur Handhabung dieser Problematik bietet sich die Anwendung eines integrierten EUS zur Ergebnis- und Finanzplanung und -kontrolle an. Die integrierte Planung umfasst die zielgerichtete Abstimmung in sachlicher, zeitlicher und organisatorischer Hinsicht (s. Abb. 11.24). Die strategische Planung hat die gegenwärtige und zukünftige Entwicklungsfähigkeit des Unternehmens zum Inhalt. Der Aufbau strategischer Erfolgspotenziale erfolgt durch die Entwicklung und Realisierung von Gesamtunternehmens- und Geschäftsbereichsstrategien. Im Rahmen der operativen Planung werden die angestrebten Erfolgspotenziale

310

11  Anwendungen zur Entscheidungsunterstützung

Abb. 11.24  System der integrierten Ergebnis- und Finanzplanung in einem divisional organisierten Unternehmen

konkretisiert und in quantitative Erfolgsgrößen umgesetzt. Ein zentrales Instrument hierfür stellt die Budgetierung dar. Dabei werden Funktions- oder Geschäftsbereichsbudgets ermittelt und als Vorgaben für die Budgetperiode verwendet. Die anschließende Budgetkontrolle dient der Überwachung der Zielgrößen, um bei Bedarf Anpassungsmaßnahmen und ggf. Budgetkorrekturen einzuleiten. Als Beispiel für eine integrierte EUS-Anwendung zur Unternehmensführung, die auf den Daten des ERP-Systems aufbaut, wird die Planungssoftware Corporate Planner vorgestellt. Hier wird bewusst ein System präsentiert, das eine niedrigere Komplexität als das bisher dargelegte SAP ERP-System aufweist.

11.3.1.2  Anwendung mit Corporate Planner Für die computergestützte Planung mit Corporate Planner sind zunächst unternehmensspezifische Daten in einem Strukturbaum abzubilden. Der Strukturbaum nimmt im Corporate Planner eine zentrale Rolle ein. Er dient als Navigationsinstrument bei der Eingabe und Auswertung von Daten und bietet dabei eine grafische Darstellung des Rechenwegs. Ein Beispiel für einen Strukturbaum wird in Abb. 11.25 dargestellt. In dieser Abbildung wird die hierarchische Struktur der Aufwendungen gezeigt, die zur Ermittlung des Erfolgs benötigt werden.

11.3 Anwendungsbeispiele für aufgabenorientierte …

311

Abb. 11.25  Beispiel eines Strukturbaums

Zur Erstellung eines solchen Baums können vorgegebene Standards genutzt werden, die an die unternehmensspezifischen Bedürfnisse angepasst werden (Customizing). Ebenso ist es möglich, einen Strukturbaum von Grund auf individuell zu erstellen. Beim Aufbau des Baums in Corporate Planner sind verschiedene Feldtypen von Bedeutung. Die Verwendung der Typen richtet sich nach den spezifischen Anforderungen innerhalb der unternehmensindividuellen Struktur. Im Strukturbaum stellen Felder vom Typ „Quelldaten“ Eingabefelder dar. Ein Eingabefeld ist ein Feld, das Zahlen über Datenimport oder durch Eingabe des Anwenders aufnehmen kann. Hinter einem solchen Feld können verschiedene Arten von Daten stehen. Je nach Anforderung und Datenverfügbarkeit können dort Istdaten sowie Prognose- und Simulationsdaten hinterlegt werden. Es handelt sich bei den Quelldaten um sog. Endfelder der Baumstruktur, d. h. diese Felder stellen „naturanalog“ die Blätter eines Strukturbaums dar, die keine Tochterfelder besitzen. Auf der Grundlage von Quelldaten können mithilfe des Feldtyps „Kennzahl“ Kennzahlensysteme aufgebaut werden. Ein Kennzahlenfeld ist ein Feld, das mittels einer benutzerdefinierten Formel Kennzahlen auf Basis der Quelldaten berechnet. Während mit Kennzahlen eine periodenbezogene Verdichtung von Daten vorgenommen werden kann, bietet ein Feld vom Typ „Formel“ die Möglichkeit, durch eine mathematische Formel aus Quelldaten Zahlenfolgen zu berechnen. Eine Formel kann auch als direkter Bezug zu einem anderen Feld definiert werden. Ein solches Feld wird dann als Spezialfall eines Formelfelds mit der Feldart „Querverweis“ abgebildet. Um Felder zu definieren, bei denen es nötig ist, sowohl Formel- als auch Eingabefelder zur Verfügung zu stellen, können sog. Hybridfelder erstellt werden. Ein typischer Anwendungsfall ist die Abbildung von Absatzzahlen. Dabei werden für die Planbilanz die Pro­ gnosen durch eine mathematische Formel berechnet. Die Istmengen sind dagegen über die Feldart „Quelldaten“ periodisch aus der Fakturierung einzulesen. Auf dieser Basis können Abweichungsanalysen für das Vertriebscontrolling vorgenommen werden. Zur praktischen Durchführung der Planung müssen zunächst Daten im Corporate Planner angelegt werden. Es existieren mehrere Möglichkeiten, um diese Daten zu erzeugen. Neben der manuellen Eingabe und dem Import der Daten aus heterogenen Datenquellen (z.  B.  Tabellenkalkulationsblättern, Text- und XML-Dateien) können diese mithilfe des sog. Planungsassistenten gefüllt werden. Mit seiner Hilfe ist es z. B. ­möglich,

312

11  Anwendungen zur Entscheidungsunterstützung

Abb. 11.26  Assistent zur Top-down-Planung

eine zeitlich fortzuschreibende (rollierende) Mehrjahresplanung mit frei definierbaren Zeitabschnitten und mehreren Planungsebenen zu realisieren. Daneben wird über den Goal Seeker eine Zielwertsuche ermöglicht und über die Funktion des Life Cycle Costing eine langfristige Planung der Kosten- und Ergebnisverläufe von beliebigen Produkten ermöglicht. Als Beispiel wird an dieser Stelle der Planungsassistent für die Top-down-Planung vorgestellt, der in der Lage ist, einen vorgegebenen Planwert auf die Daten eines ­Quelldatenfelds zu verteilen. In Abb. 11.26 ist das Eingabe- und Auswahlfenster dieses Assistenten für den geplanten Erfolg eines Jahres abgebildet worden. Die zeitliche Verteilung des vorgegebenen Planerfolgs von 500.000 € auf die einzelnen Planperioden kann auf zwei Arten erfolgen. Bei einer gleichmäßigen Verteilung wird der eingetragene Wert linear auf die Monate des Planjahres verrechnet. Auch kann der vorgegebene Planwert gemäß der bisher bestehenden prozentualen Vorgabe auf die Monate bezogen werden. Diese Einstellung macht eine Erfolgsplanung auf der Basis historischer Daten möglich.

11.3 Anwendungsbeispiele für aufgabenorientierte …

313

Abb. 11.27  Verteilung des Vorgabewerts auf einen Zeitraum

Die Bestimmung der periodenindividuellen Vorgabewerte kann auch durch Auswahl von Verteilungen methodisch gestützt werden. Beispielsweise lassen sich exponentielle und diskrete Verteilungen mit treppenförmigem Anstieg zur Erzeugung der Vorgabewerte generieren (s. Abb. 11.27). Corporate Planner verfügt über verschiedene analytische Methoden zur Unterstützung der Auswertungsrechnung sowie Möglichkeiten zur Visualisierung der Zahlenfolgen. Abb. 11.28 zeigt die tabellarische Auswertung der Controllingdaten. Per Navigation im Strukturbaum können so Drill-Down-Techniken, Soll-Ist-Vergleiche und Alternativ-­ Referenz-­Vergleiche realisiert werden. Des Weiteren sind grafische Darstellungen auf Basis der im System vorhandenen Daten erzeugbar. Zu diesem Zweck stehen verschiedene Diagrammtypen zur Verfügung. Auch bei der Darstellung von Grafiken kann der Strukturbaum als Navigationshilfe genutzt ­werden, um einen schnellen Wechsel zwischen den Datenfeldern zu ermöglichen (s. Abb. 11.29). Durch die Anwendung von Simulationsmethoden besteht die Option, verschiedene Datensituationen „durchzuspielen“ und die Ergebnisse zu vergleichen. Im Rahmen der Kennzahlenanalyse werden anpassbare Kennzahlensysteme auf die vorgegebenen Daten angewendet und dargestellt. Zusätzlich können Methoden zur ABC-Analyse, zur Abweichungsanalyse und zur Break-Even-Analyse genutzt werden. Corporate Planner verfügt außerdem über einen Kanon statistischer Methoden zur Zeitfolgen- und Trendanalyse. Das System bietet hierbei die Möglichkeit an, lineare, degressive und progressive Regressionsverfahren zu nutzen, um den zeitlichen Verlauf von Variablen aufgrund von Vergangenheitswerten zu prognostizieren. Die Ausführungen zum Softwareprodukt Corporate Planner verdeutlichen, dass zum Zweck der Unternehmensplanung unterschiedliche Controllinginstrumente kombiniert werden können. Zum einen werden OLAP-Techniken zur hierarchischen Strukturierung

314

11  Anwendungen zur Entscheidungsunterstützung

Abb. 11.28  Auswertungen von Daten im Tabellenfenster

Abb. 11.29  Beispiel einer grafischen Auswertung mittels Strukturbaum

11.3 Anwendungsbeispiele für aufgabenorientierte …

315

und zur Navigation in Datenbeständen zur Verfügung gestellt (s. Abschn. 11.2.3). Zum anderen steht eine Vielzahl von statistischen und analytischen Methoden zur Verfügung, um betriebswirtschaftlich relevante Kennzahlen zu erzeugen. Wesentliche Erfolgsfaktoren für die Einführung und Anwendung eines derartigen EUS sind allerdings nicht nur in der datentechnischen Integration mit den operativen Systemen, sondern auch in der Methodenkompetenz, vor allem aber in der Akzeptanz der Nutzer zu sehen.

11.3.2 Unternehmensplanung 11.3.2.1  Aufgabenstellung Unter methodengestützter Planung ist eine Planung auf Basis der normativen Entscheidungstheorie zu verstehen, bei der Entscheidungen unter Unsicherheit unter Verwendung von Entscheidungsmatrizen und -bäumen getroffen werden. Typisch für derartige Entscheidungssituationen ist die Verwendung von Risiko-Nutzen-Funktionen. Im einfachsten Fall der Risikoneutralität stimmen diese mit der Maximierung der Erwartungswerte von Zielwerten überein. Dieses Konzept wird nun am Beispiel der Flexiblen Planung kurz dargestellt. Anders als bei der starren Planung, bei der der Planende bereits zum Planungszeitpunkt festlegt, wie er sich in den zukünftigen Perioden verhalten will, werden bei der Flexiblen Planung optimale bedingte Pläne für zukünftige Datensituationen festgelegt. Diese mehrstufigen Entscheidungsprobleme unter Unsicherheit können durch Verwendung von Entscheidungsbäumen visualisiert werden. Dabei werden zunächst alle künftig denkbaren Umweltzustände mit ihren Eintrittswahrscheinlichkeiten dargestellt. Danach werden die Wahrscheinlichkeiten mit den Entscheidungskonsequenzen verknüpft und zu Zielwerten (z. B. zum Erwartungswert des Gewinns) verdichtet. Durch die Bewertung der einzelnen Äste des Baums soll eine Aussage über die zu treffenden Entscheidungen gewonnen und so die Unternehmensplanung beim Treffen der richtigen Entscheidung unterstützt werden. In der Literatur wird die Flexible Planung teilweise als zu aufwendig und rechenintensiv kritisiert, weshalb sie weniger als eine praktikable Planungstechnik, sondern vielmehr als eine Denkrichtung gesehen wird, die die Abhängigkeit der Qualität einer Entscheidung von einer später zu treffenden Folgeentscheidung verdeutlichen soll (Adam 1996, S. 539). Diese Argumente sind allerdings aufgrund der Möglichkeiten, EUS-Software nutzen zu können, nicht mehr akzeptabel. Ein typisches Instrument zur computergestützten Lösung von Entscheidungsproblemen ist das Softwareprodukt Vanguard Studio, das von Vanguard Software vertrieben wird. Der Einsatz dieses EUS-Produkts wird im Folgenden für das Beispiel der Flexiblen Planung dargestellt. 11.3.2.2  Ein mehrstufiges Entscheidungsproblem mit Vanguard Studio Die Beschreibung eines mehrstufigen Entscheidungsproblems kann mit Vanguard Studio auf zwei Arten erfolgen. Einerseits bietet die Software die Möglichkeit, ein Hilfsprogramm (Build Wizard) einzusetzen; andererseits erlaubt sie, den Entscheidungsbaum

316

11  Anwendungen zur Entscheidungsunterstützung

unter Verwendung einer domänenspezifischen Spezifikationssprache (DScript) direkt zu erstellen. Zum Einstieg und zur Umsetzung kleinerer Probleme bietet sich der Build Wizard an. Innerhalb des Entscheidungsbaums werden jedem Entscheidungsknoten bzw. den da­ raus folgenden Konsequenzen die monetären Entscheidungskonsequenzen zugeordnet. Die Entscheidungskonsequenzen lassen sich in Nebenrechnungen mit gängigen Tabellenkalkulationsprogrammen ermitteln und in Vanguard Studio importieren. Nach Fertigstellung des Entscheidungsbaums wird die Berechnung gestartet und das Programm weist dem Ast denjenigen Wert zu, der aus den untergeordneten Verzweigungen, ihren monetären Konsequenzen und den Wahrscheinlichkeiten von Umweltsituationen resultiert. Aus den Ergebnissen ist ablesbar, zu welchen Zeitpunkten welche Entscheidungsalternative auszuwählen ist. Als Beispiel für die Umsetzung eines mehrstufigen Entscheidungsproblems mit Van­ guard Studio wird in Abb. 11.30 ein Ausschnitt aus einem Entscheidungsbaum dargestellt. In diesem Entscheidungsbaum werden Handlungsalternativen (Kauf und Kapazitätserweiterung von Anlagen) und Umweltsituationen (Nachfrageentwicklungen) abgebildet. Weitere Methoden bieten die Möglichkeit, die gewonnenen Ergebnisse zu analysieren. So ist eine statische Analyse möglich, bei der die im Entscheidungsbaum enthaltenen Informationen extrahiert und visualisiert werden. Hierzu gehören Risikodiagramme und die Berechnung des Informationswerts. Die einzelnen Äste eines Entscheidungsbaums bergen unterschiedliche Risiken, die vor allem bei großen Entscheidungsbäumen nicht leicht zu überblicken sind. Mithilfe von Risikodiagrammen können jedoch alle möglichen Zielwerte der im Baum festgehaltenen Strategien mit ihren Eintrittswahrscheinlichkeiten versehen werden, um die dem Entscheidungsproblem zugrunde liegende Risikostruktur transparent zu machen. Die Unsicherheit über die zukünftige Datensituation kann durch zusätzliche Informationen, z. B. aus Marktforschungsdaten, verringert werden. Diese Informationsgewinnung verursacht normalerweise Kosten, die dem erwarteten zusätzlichen Nutzen der Information gegenüberzustellen sind. Die Informationsgewinnungsentscheidung kann unter Verwendung des Bayes’schen Theorems in einem Entscheidungsbaum vorgenommen werden (s. Abschn.  1.4). Dabei wird auch der Wert einer vollkommenen Information berechnet. Diese Modellvorstellung geht auf Marschak (Marschak 1957) zurück. In seinem Modell wird davon ausgegangen, dass die Erlangung vollkommener Informationen möglich ist. Wenn z. B. das Ergebnis eines Marktforschungsprojekts ein Steigen der Nachfrage um x % beinhaltet, dann wird – so wird angenommen – dieser Anstieg auch tatsächlich eintreten. Der Wert dieser vollkommenen Information wird als Expected Value of Perfect Information (EVPI) bezeichnet. EVPI stellt die Preisobergrenze dar, die zum Zukauf vollkommener Informationen nicht überschritten werden sollte. Die zweite Klasse der von Vanguard Studio unterstützten Methoden betrifft die dynamische Analyse, die Aussagen über das Verhalten des Modells bei Änderungen des ­Entscheidungsfelds durch Variation des Entscheidungsbaums ermöglicht. Hier können

A2 Kauf der kleinen Anlage -80526 12252,68

A4 Nichtausbau der Kapazität_ -32227

keine Belebung in t2 bis t4_ 100% 25006 -32227

keine Belebung in t2 bis t4 100% 12323 -64875

ungünstige Nachfrageentwicklung in t2 bis t4_ 40% 62834 18644

günstige Nachfrageentwicklung in t2 bis t4_ 60% 83953 39763

ungünstige Nachfrageentwicklung in t2 bis t4 40% 50537 -13618

A3 Ausbau der Kapazität_ -19965 -64875

A4 Nichtausbau der Kapazität 31315,4

schwache Nachfrage in t1 30% 23293 -32227

starke Nachfrage in t1 70% 36336 31315,4

A3 Ausbau der Kapazität -19965 22734,8

günstige Nachfrageentwicklung in t2 bis t4 60% 111125 46970

schwache Nachfrage in t1 und fehlende Belebung in t2 bis t4 30% 36155 -66332

starke Nachfrage in t1 und ungünstige Entwicklung in t2 bis t4 28% 108030 5543

Abb. 11.30  Beispiel eines Entscheidungsbaums (Grob und Schultz 2001, S. 138)

12252,68

A1 Kauf der großen Anlage -102487 9684,5

starke Nachfrage in t1 und günstige Entwicklung in t2 bis t4 42% 169230 66743

11.3 Anwendungsbeispiele für aufgabenorientierte … 317

318

11  Anwendungen zur Entscheidungsunterstützung

Sensibilitätsanalysen, Risiko-Chancen-Analysen sowie die Variation der unterstellten Nutzenfunktion vorgenommen werden. Mithilfe von Sensitivitätsanalysen kann untersucht werden, wie stark eine einzelne Variable innerhalb eines Entscheidungsbaums variieren darf, ohne die bestehende Optimallösung zu verändern. In dem Zusammenhang können kritische Werte bestimmt werden, die die Grenze zum „Kippen“ der Entscheidung bilden. Sind die stochastischen Verteilungen der Einzelwerte bestimmter Äste des Entscheidungsbaums bekannt, so kann die Risiko-Chancen-Analyse zur Entscheidungsunterstützung genutzt werden. Mithilfe der Monte-Carlo-Simulation wird die Abhängigkeit des Zielwerts von mehreren stochastischen Einflussgrößen gleichzeitig bestimmt. Als Ergebnis der Auswertung des Entscheidungsbaums ergibt sich eine Häufigkeitsverteilung des betrachteten Zielwerts. Diese Häufigkeitsverteilung kann dann in sog. Risiko-­ Chancen-­Profile überführt werden, die z. B. Aussagen darüber ermöglichen, mit welcher „Mindestwahrscheinlichkeit“ ein bestimmter Zielwert eintritt (s. zu diesen Methoden Abschn. 11.3.3). In der Standardeinstellung basieren die Berechnungen von Vanguard Studio auf der Annahme der Risikoneutralität des Entscheiders. Es ist aber auch möglich, die unterstellte Nutzenfunktion so zu variieren, dass das Verhalten von risikoscheuen (s. Abschn. 1.3) bzw. risikofreudigen Entscheidern dargestellt wird, was zu entsprechend anderen Optimallösungen des Problems führen kann. Zu diesem Zweck ermöglicht Vanguard Studio die Ermittlung der Nutzenfunktion des Anwenders. Abb.  11.31 zeigt den Dialog zur interaktiven Parameterzuweisung der Nutzenfunktion. Dabei wird eine fiktive Entscheidungssituation (Laborsituation) zugrunde gelegt, für die ein Sicherheitsäquivalent zu bestimmen ist.

11.3.3 Investitionscontrolling mit Simulationswerkzeugen 11.3.3.1  Aufgabenstellung Investitionsentscheidungen stellen Entscheidungen unter Unsicherheit dar. Zur Handhabung der damit verbundenen Problematik wird in der Investitionsrechnung die Risiko-­ Chancen-­Analyse empfohlen (Grob 2006, S. 488-495). Bei der Risiko-Chancen-Analyse werden Einflussgrößen (z. B. Absatzmengen) zur Bewertung von Investitionsalternativen anhand von Pseudozufallszahlen unter Verwendung der Monte-Carlo-Simulation quantifiziert. Die simulierten Einflussgrößen werden zu Zielgrößen, wie beispielsweise dem Endwert einer Investitionsalternative, verdichtet und in Risiko-Chancen-Profilen dargestellt. An einem Risiko-Chancen-Profil kann die Wahrscheinlichkeit abgelesen werden, mit der ein Zielwert unter Zugrundelegung der Eingabedaten mindestens erreicht wird. Risiko-­Chancen-­Profile ermöglichen dem Entscheidungsträger den Vergleich unterschiedlicher Alternativen unter expliziter Berücksichtigung der Unsicherheit. Abb.  11.32 stellt die Risiko-Chancen-Profile von drei Investitionsalternativen dar. ­Anhand dieser Profile kann z. B. die Aussage getroffen werden, dass beide Sachinvestitionen

11.3 Anwendungsbeispiele für aufgabenorientierte …

319

Abb. 11.31  Interaktive Bestimmung der Nutzenfunktion

1,00

Finanzinvestition

0,90

Wahrscheinlichkeit

0,80

0,40

0

11.000

Sachinvestition A 17.000

Sachinvestition B

Endwert [€]

Abb. 11.32  Risiko-Chancen-Profile für drei Investitionsalternativen

320

11  Anwendungen zur Entscheidungsunterstützung

mit einer Wahrscheinlichkeit von 40 % einen Mindestendwert von 17.000 € erzielen. Im Vergleich hierzu ist der Endwert der sicheren Finanzinvestition mit genau 11.000 € beziffert.

11.3.3.2  Risiko-Chancen-Analyse mit Crystal Ball Die Durchführung der Risiko-Chancen-Analyse kann softwaretechnisch durch das Excel-­ Add-­on Crystal Ball von Oracle unterstützt werden. Neben der Angabe von Verteilungsannahmen für die Einflussgrößen, der Definition von Zielgrößen sowie der Erstellung von Risiko-Chancen-Profilen durch die Simulation bietet Crystal Ball eine Reihe weiterer Funktionen, wie z. B. die Anpassung von Verteilungen an historische Daten. Auch sind unterschiedliche Varianten zur Durchführung von Sensitivitätsanalysen möglich. Im Folgenden wird der Ablauf der Risiko-Chancen-Analyse bei Verwendung des Softwarewerkzeugs Crystal Ball beschrieben. Zunächst ist das Simulationsmodell in einem Excel-Spreadsheet deterministisch abzubilden. Zur Unterstützung der Investitionsentscheidung sind für sämtliche Entscheidungsalternativen vollständige Finanzpläne (VOFIs) (s. Abschn. 3.3) in Excel zu modellieren (s. Abb. 11.33). Zu Beginn der Risiko-Chancen-Analyse sind dabei alle Einflussgrößen durch eindimensionale (deterministische) Werte fest vorzugeben.

Abb. 11.33  Abbildung eines VOFIs in Microsoft Excel

11.3 Anwendungsbeispiele für aufgabenorientierte …

321

Im nächsten Schritt sind die unsicheren Einflussgrößen auszuwählen und für sie Verteilungen zu hinterlegen. Crystal Ball stellt eine Reihe stetiger und diskreter Verteilungen standardmäßig zur Verfügung, die den Zellen der Einflussgrößen zugewiesen werden können. Abb. 11.34 zeigt eine Auswahl der verfügbaren Verteilungstypen. In Abhängigkeit vom gewählten Verteilungstyp sind die spezifischen Parameter (z. B. Mittelwert und Standardabweichung bei Verwendung einer Normalverteilung) einzugeben (s. Abb. 11.35). Die Auswahl von Verteilungen für Einflussgrößen bedarf detaillierter Kenntnisse des Verhaltens der realen Werte. Größen, die nur einen geringen funktionalen Einfluss auf den Zielwert besitzen oder deren Verteilung nicht genau spezifiziert werden kann, sollten nicht mit Verteilungen hinterlegt werden. Zur Messung der Stärke des funktionalen Zusammenhangs zwischen Einfluss- und Zielgrößen bietet Crystal Ball das Tornado-Chart-Tool an, mit dem eine Sensitivitätsanalyse durchgeführt werden kann. Liegen historische Daten für Einflussgrößen vor, kann Crystal Ball diese anhand von statistischen Verfahren durch Verteilungen mit entsprechenden Parametern annähern (Distribution Fitting). Nach der Definition der Einflussgrößen müssen die Zielgrößen angegeben werden (Define Forecasts). Für jede Zielgröße kann nach der Simulation ein Risiko-Chancen-Profil erzeugt werden. Liegen sämtliche Einfluss- und Zielgrößen vor, kann die eigentliche Simulation durchgeführt werden. Die Simulationseigenschaften, wie z. B. die Anzahl der Durchläufe oder der Algorithmus zur Generierung der Zufallszahlen, werden dann festgelegt. Crystal Ball protokolliert während der Simulation für jeden Durchlauf den Zielwert jeder Alternative und stellt die Ergebnisse in einem Häufigkeitsdiagramm (Frequency Chart) dar. Das Histogramm wird in ein Risiko-Chancen-Profil (Reverse Cumulative Chart) zur Entscheidungsfindung überführt (s. Abb. 11.36).

Abb. 11.34  Verteilungen bei Crystal Ball (Auswahl)

322

11  Anwendungen zur Entscheidungsunterstützung

Abb. 11.35  Angabe der Parameter einer Normalverteilung

Abb. 11.36  Risiko-Chancen-Profil bei Crystal Ball

Die Anwendung des dargestellten Werkzeugs zeigt auf, wie durch den Einsatz von Simulationsverfahren Bewertungsdefekte und Risiken bei strategischen Entscheidungspro­ blemen gehandhabt werden können. Voraussetzung hierfür ist jedoch ein hoher Grad an Domänenwissen der beteiligten Anwender. Die Verteilungsschätzungen sollten bereits absehbare Umweltentwicklungen antizipieren und im Rahmen zeitlich nachgelagerter Kontrollrechnungen mit prospektiven Eigenschaften aktualisiert werden, um eine hohe Realitätsnähe bei der Abbildung betrieblicher Entscheidungssituationen zu erzielen.

Anwendungen zur Vernetzung mit Kunden und Lieferanten

12

Zusammenfassung

Anknüpfend an das fünfte Kapitel des Buches beschreibt dieses Kapitel zunächst die Treiber zur verstärkten Vernetzung mit Kunden und Lieferanten. Zu den, die betrieblichen ERP-Systeme ergänzenden Anwendungen zählen jene für das Customer Rela­ tionship Management, für den elektronischen Handel (E-Commerce) sowie für das Supply Chain Management. Die Systeme sind mit den Kernfunktionalitäten sowie jeweils einem Fallbeispiel dargestellt. Eine Zusammenfassung der betriebswirtschaftlichen Auswirkungen zu diesen überbetrieblich ausgerichteten Anwendungen schließt das Kapitel ab.

12.1 Überblick Der elektronischen Integration innerhalb des Unternehmens folgt die überbetriebliche Vernetzung mit Kunden und Lieferanten. Ziel der vernetzten Unternehmen ist dabei die Realisierung eines durchgängigen Informationsflusses über die gesamte Wertschöpfungskette (s. Abschn. 3.2.2.2) hinweg, also vom Kunden über Händler und produzierende Unternehmen hin zu den Zulieferern. Hier existieren häufig Ineffizienzen, die sich mit der funktionalen internen Organisation vergleichen lassen: Nicht, partiell oder zeitverzögert an den Organisationsgrenzen weitergegebene Informationen mit zahlreichen manuellen (Wieder-) Eingaben oder redundante und nicht übergreifend abgestimmte Abläufe. Beispielsweise führen häufig sowohl die (versendenden) Lieferanten als auch die (empfangenden) Hersteller Waren- und Rechnungsprüfungen durch oder planen ihre Absatzdaten losgelöst voneinander. Dies führt einerseits zu redundanten Aktivitäten und andererseits zur Bestandsbildung,

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_12

323

324

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

da die Beteiligten die informationell bedingten Unsicherheiten durch Bestände kompensieren. Projekte der digitalen Transformation zielen auf eine v­ erbesserte Vernetzung mit Kunden und Lieferanten durch die Nutzung weiterer Anwendungen. Diese Entwicklung beruht auf mehreren Treibern: (1) Aus technologischer Sicht besitzen Unternehmen in der vernetzten Welt (s. Kap. 5) elektronische Interaktionskanäle mit Kunden und Lieferanten sowie Behörden. Studien zufolge verwendeten 2018 in Deutschland etwa 63 Mio. Personen über 14 Jahre das Internet (Statista 2018a) und im Jahr 2017 kauften 66 % davon elektronisch ein (Statista 2018b). Neben Verkaufskanälen setzen Unternehmen IT zur Zusammenarbeit mit Lieferanten ein. Umfragen des Bundesverbands Materialwirtschaft, Einkauf und Logistik aus dem Jahr 2018 (Bogaschewsky und Müller 2018) zeigen, dass die befragten Unternehmen zu 57 % elektronische Ausschreibungen, zu 74 % elektronische Kataloge und zu 64 % Anwendungen bei der Materialbeschaffung und -bezahlung einsetzen. Allein die Substitution klassischer Papierdokumente führt dabei zu ökonomischen Vorteilen. Während eine Papierrechnung Kosten von geschätzten 16 Euro (Papier- und Portokosten, Arbeitszeit) verursacht, so sind dies etwa zwei Euro bei einer elektronischen Rechnung (mit Signatur-Management, Transportkosten und Archivierung) (AWV 2006). Ähnliche Effizienzeffekte von 70 % bis 80 % bei den Pro­ zesskosten sind vom elektronischen Einkauf (E-Procurement, s. Abschn. 12.2.3) bekannt, wenn Unternehmen von papierbasierten Prozessen auf durchgängig digitalisierte Prozesse wechseln. (2) Mit dem IT-Einsatz zur Unterstützung überbetrieblicher Kunden-/Lieferantenbeziehungen haben sich die ökonomischen Transaktionskosten verringert und flexible überbetriebliche Organisationsformen verbreitet. Die Höhe der Transaktionskosten bestimmt, ob Unternehmen ihre Leistungen intern, in Unternehmensnetzwerken oder über den Markt organisieren (s. Abschn. 4.4.1). Transaktionskosten betreffen mit der Suche von Produkten und Geschäftspartnern, der Aushandlung von Konditionen sowie der Vertragsformulierung und der Überwachung von Transaktionen mehrheitlich informationsbasierte Aktivitäten, die sich durch IT beeinflussen bzw. reduzieren lassen. Sinkende Transaktionskosten wiederum machen koordinationsintensivere Formen – also Netzwerke und Märkte – gegenüber der internen Organisation ökonomisch sinnvoll. Beispiel ist die in vielen Branchen zu beobachtende vertikale Desintegration, welche sich in der Auslagerung betrieblicher Aktivitäten an Dritte (Outsourcing, s. Abschn. 4.4), der Gründung von Gemeinschaftsunternehmen (Joint Ventures) oder der Bildung von Unternehmensnetzwerken und virtuellen Unternehmen widerspiegelt. Überbetrieblich ausgerichtete Anwendungen erlauben, dass aus externen Quellen stammende Auftrags-, Kunden- oder Planungsinformationen in den operativen und taktischen Prozessen genauso wie interne Informationen verfügbar sind. (3) Ein weiterer technologischer Treiber ist die Diffusion mobiler Endgeräte. In 2013 haben mobile Endgeräte erstmals die PCs als häufigste internetfähige Geräte übertroffen (s. die Ausführungen zu M-Business in Abschn. 5.3). Sie erlauben es einerseits

12.1 Überblick

325

den (End-)Kunden ubiquitär in die Abläufe eines Unternehmens einzubeziehen – von marketingbezogenen Aktivitäten wie mobilen Coupons, über die Erteilung von ­Aufträgen (z.  B. Überweisungen, Aktienorders) hin zur Überwachung bestimmter Ressourcen (z. B. Konten, Depots, Maschinen, Immobilien). Anderseits können mobile Geräte wie Tablets und Smartwatches gemeinsam mit intelligenten Maschinen in Industrie 4.0-Konzepten (s. Abschn. 5.5) Verwendung finden. Impulse gehen auch von der RFID- und der NFC-Technologie aus, wobei physische Güter (z. B. Paletten, Verpackungen) durch das Aufbringen kleiner Computerchips „intelligent“ werden. Gleichermaßen erhöhen solche intelligenten, auch als Smart Products bezeichneten Produkte die Möglichkeiten zur Echtzeitüberwachung und -steuerung von Warenflüssen und zur automatisierten Erfassung von Informationen, welche sich dann in den betrieblichen Anwendungen weiterverarbeiten und -leiten lassen. Gerade bei physischen Gütern trägt dies deutlich zur Beherrschung von Prozessen bei, die räumlich und über mehrere Unternehmen verteilt sind. (4) Verstärkte überbetriebliche Kontakte ergeben sich auch aus dem Wandel vom Produktzum Kundenfokus. Eine wesentliche Aussage der Prozessorientierung (s. Abschn. 6.1) ist die Ausrichtung sämtlicher Aktivitäten in der Wertschöpfungskette am Kundennutzen. Dabei kann es sich prinzipiell um unternehmensinterne als auch um externe (End-)Kunden handeln. Im Vordergrund stehen dabei aber stets Problemlösungen, welche i. d. R. mehrere Einzelleistungen bzw. Einzelprodukte umfassen. Die IT unterstützt über elektronische Kataloge, Portale und standardisierte Leistungen die Bündelung von Leistungen entlang von Kunden- bzw. Nutzungsprozessen (s. Abschn.  7.2). Dabei beziehen Kundenprozesse häufig externe Leistungen mit ein. Beispielsweise zählen zum Kundenprozess „Autobesitz“ neben dem reinen Kauf des Fahrzeugs auch Leistungen wie Finanzierung, Versicherung oder Navigation, welche die Interaktion mit Drittanbietern erfordern. Für die elektronische Integration von Leistungsbeziehungen mit Kunden und Lie­ feranten haben sich die Begriffe des Business Networking oder des Electronic Business (s. Abschn.  5.2) etabliert. Beide bezeichnen die Ausweitung des Integrationsgedankens der Wirtschaftsinformatik auf die gesamte Wertschöpfungskette und lassen sich als integrierte Ausführung aller digitalisierbaren Bestandteile ökonomischer Prozesse definieren (Thome et al. 2005). • Die integrierte Ausführung bezeichnet dabei nicht nur die medienbruchfreie elektronische Übertragung von Informationen, sondern auch deren möglichst automatisierte Weiterverarbeitung, das Auslösen von Reaktionen auf die eingehenden Informationen sowie die unmittelbare Bereitstellung der Informationen an allen notwendigen Orten. Für diesen Teilaspekt des E-Business findet sich auch der Begriff der Business Collaboration, welcher den Informationsaustausch in Echtzeit zwischen mindestens zwei Akteuren zur Konsolidierung, Bereitstellung, Distribution, Verarbeitung, Veränderung oder Optimierung von Informationen bezeichnet (Alt 2008, S. 63 ff.).

326

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

• Zu den digitalisierten Bestandteilen zählen Informationen aus sämtlichen betrieblichen Prozessen, also etwa Forschung und Entwicklung, Marketing, Produktion, Kundenservice oder Entsorgungslogistik eines Unternehmens mit Lieferanten, Behörden und (End-)Kunden. Hierin zeigt sich auch, dass E-Business deutlich breiter gefasst ist als der rein auf Kauftransaktionen ausgerichtete Begriff des Electronic Commerce (s. Abschn. 12.2.3). • Ökonomische Prozesse schließlich grenzen den Anwendungsbereich des E-Business auf Austauschprozesse zwischen Wirtschaftssubjekten ein, bei welchen einer Leistung eine, häufig monetäre, Gegenleistung gegenübersteht. Daran beteiligt sind neben (End-) Kunden sämtliche privatwirtschaftliche und öffentliche Unternehmen aus den Bereichen Industrie, Dienstleistung und öffentliche Verwaltung. Zusammenfassend bewirkt die elektronische Vernetzung mit Kunden und Lieferanten nicht nur erhebliche Rationalisierungspotenziale durch die integrierte Informationsverarbeitung in der Wertschöpfungskette. Vielmehr entstehen durch veränderte Formen der Zusammenarbeit oder neue Kanäle und Dienste zur Interaktion mit Kunden und Lieferanten strategische Effekte, welche unmittelbar den Markterfolg eines Unternehmens beeinflussen können. Gemäß den Gestaltungsebenen betrieblicher Systeme (s. Abschn. 6.2) sind überbetrieblich eingesetzte Anwendungen als Software zunächst der IS-Ebene zuzuordnen. Analog zu den innerbetrieblichen Anwendungen realisieren sie jedoch fachliche Abläufe und eröffnen Handlungsoptionen auf strategischer Ebene  – entweder als strategischen Vorsprung i. S. e. Wettbewerbsvorteils oder als strategische Notwendigkeit i. S. e. Gleichziehens mit Konkurrenten (s. Abschn. 3.2.2.1).

12.2 Überbetriebliche Anwendungen Obgleich erste Softwareanwendungen zum elektronischen Datenaustausch (Electronic Data Interchange, EDI) zwischen Unternehmen sowie zur Durchführung von Reservations- und Bestellvorgängen bereits in den 1980er-Jahren aufkamen, sind erst mit der seit Mitte der 1990er-Jahre erfolgten geschäftlichen Nutzung des Internets Standardsoftwareangebote zur Vernetzung mit Kunden und Lieferanten entstanden. Durch diese überbetriebliche Ausrichtung ergänzen sie die betrieblichen Anwendungen (ERP), und die meisten ERP-Anbieter wie SAP (s. Abschn. 10.2.1), Microsoft oder Oracle haben ihre Lösungen um derartige E-Business-Funktionalitäten erweitert. Aus der Konvergenz verschiedener Entwicklungspfade (z. B. EDI, elektronische Märkte, Internet und ERP-­Anwendungen) zeichnet sich zunehmend eine überbetriebliche Informationsinfrastruktur ab. Diese erlaubt in Analogie zum innerbetrieblichen Umfeld (hier ermöglicht eine mit ERP-Anwendungen entstehende durchgängige interne Informationsinfrastruktur die Umsetzung durchgängiger funktionsbereichsübergreifender Prozesse) eine überbetriebliche Prozessreorganisation (Alt 2008, S. 41).

12.2  Überbetriebliche Anwendungen

327

- Ziel: Effiziente Transaktionsabwicklung mit Lieferanten und Kunden im Ein- und Verkauf - Direkter Einbezug von Lieferanten und Kunden, z. B. über elektronische Kataloge oder Märkte

eCommerce (buy) Lieferanten

eCommerce (sell) Unternehmen

Kunden

ERP Customer Relationship Management

Supply Chain Management - Ziel: Austausch materialflussbezogener Informationen für reduzierte Bestände und Lieferzeiten

-Ziel: Zentrales Kundendatenmanagement zur verbesserten Kundenbindung

Abb. 12.1  Anwendungsbereiche bei der Vernetzung mit Kunden und Lieferanten

Die Anwendungen zur Vernetzung mit Kunden und Lieferanten verfolgen unterschiedliche Ziele (s. Abb. 12.1). Beispielsweise führen Anwendungen aus dem CRM-Bereich Informationen aus mehreren Anwendungen zusammen und realisieren dadurch eine Gesamtsicht auf die Aktivitäten eines Kunden. Auch Anwendungen für das SCM tauschen Informationen über eine Schnittstelle mit ERP-Anwendungen aus, in diesem Falle zur leistungsfähigeren Simulation und Berechnung von Kapazitäten und Lieferzeiten als dies in einer ERP-Anwendung möglich wäre. Während sich Anwendungen im CRM-Bereich auf Kundendaten und im SCM-Bereich auf materialflussbezogene Daten konzentrieren, liegt der Schwerpunkt von Anwendungen für Electronic Commerce (EC) auf der effizienten Transaktionsabwicklung mit Kunden und Lieferanten. Nachfolgend sind diese drei Anwendungsbereiche näher beschrieben (s. Abb. 12.1).

12.2.1 Customer Relationship Management Die Anwendungen des Kundenbeziehungsmanagements bzw. CRM bilden die Grundlage zur ganzheitlichen und abgestimmten Interaktion eines Unternehmens mit seinen Kunden. Beim Einsatz einer CRM-Anwendung ist zu beachten, dass es sich beim CRM letztlich – ebenso wie beim nachfolgend skizzierten SCM – um einen Managementansatz handelt. Die strategischen Voraussetzungen zur kundenorientierten Ausrichtung eines Unternehmens (z. B. Verankerung der Kundenverantwortung in der Geschäftsleitung, kundenorientierte Philosophie in der Unternehmenskultur) müssen ebenso gegeben sein wie die Definition und Akzeptanz der kundenorientierten Prozesse (z. B. Marketingmaßnahmen, Vertriebsprozess, Interaktionskanäle) innerhalb des Unternehmens (s. Kap. 7 und 8).

328

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

cc Customer Relationship Management  Customer Relationship Management ist ein kundenorientierter Managementansatz, bei dem Anwendungen die Informationen für ope­ rative, analytische und kooperative CRM-Prozesse integriert bereitstellen und damit zur Verbesserung der Kundengewinnung, -bindung und -profitabilität beitragen. Kernprozesse des CRM sind Marketing, Verkauf und Service. Die Funktionalitäten von CRM-Anwendungen setzen an den Aufgaben des Kundenbeziehungslebenszyklus an, die vom Marketing über die Evaluation von Angeboten zum Kauf von Produkten bzw. Problemlösungen hin zum Service bzw. Kundendienst (After Sales) reichen (Hippner et  al. 2011). Das Marketing stellt den Kontakt zu Kunden her, wobei es sich bei den Adressaten sowohl um bestehende Kunden als auch neue oder ehemalige Kunden handeln kann. Weil sich die Kosten für die Neugewinnung eines Kunden gegenüber dem Halten bestehender Kunden auf das fünf- bis achtfache belaufen können, sind Kundenbindungsprogramme ein wichtiges Instrument des CRM. Zentrale Aufgaben des Marketings bilden die Planung und Durchführung von Kampagnen. Im positiven Fall schließt sich an das Marketing der Verkaufsprozess an, welcher ein Angebot unterbreitet und möglichst in einem Auftrag seinen Abschluss finden soll. Als wichtigste Aufgabenfelder gelten hier die Kundenberatung, die Produktkonfiguration und die Konditionsvereinbarung. Neben Marketing und Verkauf bildet der Service (nicht im Sinne eines technischen Service, s. Abschn. 9) den dritten Kernprozess des CRM. Ziel ist hier, neben der Erfüllung von Gewährleistungspflichten, die Zufriedenheit des Kunden während der Besitz- bzw. Nutzungsphase zu steigern und damit die Grundlage für eine neue Transaktion zu schaffen. Typische Aufgaben des Service bilden die Aufnahme von Servicefällen, die Durchführung von Wartungsarbeiten oder das Beschwerdemanagement. Die Funktionalitäten von CRM-Anwendungen lassen sich in drei Bereiche unterteilen: • Das operative CRM liefert grundlegende Funktionen in den Bereichen Marketing, Verkauf und Service, um die Kundeninteraktion mit Blick auf eine einheitliche Datenbasis zu realisieren. Es unterstützt das Kampagnenmanagement (Definition von Kampagnen und Verteilern, Verfolgung und Verwaltung von Kampagnen), die Aktivitäten im Call Center (Gesprächsführung, Kundenhistorie, Telefonieintegration, Beschwerdemanagement) oder den Außendienst (Besuchsplanung und Berichterstattung, Produktkonfigurations- und Beratungsfunktionalitäten). Zentrales Element des operativen CRM bilden eine Kundendatenbank bzw. ein Data Warehouse (s. Abschn. 11.2), welche sämtliche Informationen über einen Kunden und bisherige Interaktionen mit ihm enthält und dadurch die Grundlage zur Bildung von Kundenprofilen und -historien liefert. Daneben bestehen Module zum Content- bzw. Dokumentenmanagement (z.  B.  Texte für die Call-Center-Agenten), zur effizienten Durchführung von (Massen-)Mailings sowie Schnittstellen zur Telefonieanwendung (z.  B. automatisches Wählen, Anzeige von Kundennamen zu Telefonnummer) und zur ERP-Anwendung (z. B. für Verfügbarkeitsprüfungen, Weitergabe von Angeboten und Aufträgen).

12.2  Überbetriebliche Anwendungen

329

• Das analytische CRM versucht, aufbauend auf den Daten des operativen CRM, mittels statistischer Verfahren den Kundenbedarf, das Kundenverhalten und den Kundenwert zu ermitteln. Analog zu den entscheidungsunterstützenden Anwendungen im betrieblichen Bereich (Business Intelligence, s. Abschn. 11.1) führt das analytische CRM eine Auswertung konsolidierter Informationen durch, um daraus Aussagen zur Profitabilität von Kundensegmenten und Kampagnen ableiten zu können. Die Auswertungen können retro- und prospektiv ausgerichtet sein. Während Erstere mit Berichten und Abfragen über bestehende Datendimensionen die klassischen Reporting- und Dashboard-­ Funktionalitäten aus dem Bereich des OLAP (s. Abschn. 11.2.3) betreffen (z. B. Welches sind die profitabelsten Kunden und Regionen?), versuchen Letztere über Instrumente des Data Mining (s. Abschn. 2.3.3.4) neue Zusammenhänge zwischen den Daten zu erkennen (z. B. Welche Kunden würden weitere Produkte kaufen?). Ergebnisse aus beiden Auswertungsrichtungen fließen zurück in das operative CRM zur Umsetzung entsprechender Maßnahmen. • Das kooperative (bzw. kommunikative) CRM soll die kanalübergreifende Transparenz über die Kundenhandlungen sicherstellen. Im Sinne eines durchgängigen Nebeneinanders mehrerer Kommunikationskanäle (Multi Channel Management) könnte etwa ein Call-Center-Agent beim Anruf des Kunden davon wissen, dass dieser zuvor ein bestimmtes Produkt im Onlineshop konfiguriert hat, oder der Außendienst von den über das Call Center getätigten Beschwerden des Kunden erfahren. Im Vordergrund des kooperativen CRM steht daher die Leistungsintegration über alternative ­Interaktionskanäle (z. B. Self-Service-Portale, Call Center) und das abgestimmte Anbieten von Anreizprogrammen (z. B. Loyalitätsprogramme, Betreuung durch Key-Account-Verantwortliche). Zusammenfassend steht bei CRM-Anwendungen die Zusammenführung von Informationen über die Kunden, das Bilden von konsistenten Kundenprofilen und -historien, das Durchführen von Kampagnen und Kundenberatungen (z. B. durch den klassischen Außendienst) und das Gewährleisten einer konsistenten bzw. abgestimmten Kundeninteraktion über mehrere Kanäle (z.  B.  Online, Filiale, Außendienst) hinweg, im Vordergrund. Aufgrund der Überlappungen zur Transaktionsabwicklung über Onlineshops, Kataloge oder Auktionen kommen hierfür häufig die Anwendungen des EC zum Einsatz (s.  Abschn.  12.2.3). Ein Beispiel eines typischen operativen CRM-Formulars im Call Center zeigt Abb. 12.2. Neben der abgebildeten Anwendung von Siebel/Oracle sind zahlreiche weitere CRM-­Produkte verfügbar. Dazu zählen SAP CRM als klassische betriebliche Lösung, Salesforce.com als externe SaaS-Lösung (s. Abschn. 4.4.3), sowie OpenSource-Produkte wie SugarCRM oder vTiger (s. Abschn.  10.4.3). Auch haben Social Media sowie mobile Geräte ihren Einsatz im CRM gefunden. Die Lösungen zeigen die Entwicklung hin zum Multi Channel Management. Zwei Anwendungsbereiche seien vor diesem Hintergrund herausgegriffen:

330

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

Abb. 12.2  Beispiel einer operativen CRM-Anwendung (Siebel/Oracle)

• Das Social CRM (Alt und Reinhold 2016) erschließt das Social Web (s. Abschn. 5.4) für die Kundeninteraktion. Bekannte Social-Media-Plattformen wie etwa Facebook oder Twitter besitzen elektronische Schnittstellen (sog. API), welche einen automatisierten Export zahlreicher Daten aus den Plattformen (z. B. die verfassten Beiträge, die Anzahl Follower und Likes) in spezialisierte Anwendungen erlauben. Lösungen des Social Media Monitoring zeigen dann beispielsweise welche Teilnehmer welche Themen verfassen und präferieren (z. B. durch ein „like“ gekennzeichnet), und können dadurch Anhaltspunkte zu Meinungen und Entwicklungen ermitteln, die sich mittels bewerteter Stichwortlisten auch nach positiv und negativ (Sentiment Analysis) einteilen lassen. Analysen der Interaktionsbeziehungen zwischen Teilnehmern oder Fans (Social Network Analysis, s. Abschn. 5.4.1) liefern dagegen Informationen, wer ggf. als Meinungsführer eine besondere Bedeutung zur Identifikation von Trends besitzt. Das Social CRM versucht nun die CRM-Datenbasis um Wissen aus dem Social Web anzureichern, um dadurch einerseits Anhaltspunkte zur Kundenberatung, zur Durchführung von Kampagnen und auch zur Kundenbetreuung zu erhalten. Andererseits bieten die sozialen Medien einen interaktiven (z. B. schnelle Antwortzeiten in Facebook oder Twitter) und persönlichen (z. B. persönliche Ansprache mit „Du“, Posten von Bildern) Kommunikationskanal, den

12.2  Überbetriebliche Anwendungen

331

Unternehmen für Zwecke des Marketing (z. B. Ideenmanagement, Produktfeedback), des Verkaufs (z.  B.  Facebook Shops) und des Service (z.  B.  Beschwerdemanagement, Kundendienstanfragen) einsetzen können. • Mittels Location Based Services (s. Abschn. 5.3) können Nutzer von intelligenten Endgeräten Informationen über Kampagnen, Angebote oder Produkte erhalten. Die Kundeninteraktion erfolgt daher situationsspezifisch, und soll darüber zusätzliche Umsatzpotenziale erschließen und zur Kundenbindung beitragen. Mobile Services zum Produktscanning und -vergleich, zum Check-in in Geschäften, zur Verwaltung elektronischer Kundenkarten und Coupons sowie mobile elektronische Bezahllösungen (z.  B.  E-Payment mittels Nearfield-Communication-Technologie) sind weitere Beispiele für die unmittelbare Einbindung des Kunden und Verknüpfung einzelner Kundenkontakte zu einem vollständigen Kundenprofil. Die Sammlung und Auswertung von Kundendaten ist immer mit Fragen des Datenschutzes verbunden. Die DSGVO (s. Abschn. 4.3.1) regelt hier die Möglichkeiten und Grenzen der Datenerfassung und -auswertung. Sie gibt zum Beispiel vor, dass Kundendaten nur für bestimmte Verwendungszwecke zu erheben sind und dem Kunden immer ein Auskunftsrecht zusteht, welche Daten ein Unternehmen über ihn gespeichert hat. CRM bei der Consorsbank

Ein Beispiel für die Nutzung einer CRM-Anwendung findet sich bei der Consorsbank (ehemals Cortal Consors SA), einem Teil des französischen Finanzdienstleisters BNP Paribas. Die Direktbank bedient ihre Kunden primär über ein Call Center und ein Internetportal, das online sowie mobil verfügbar ist. Zur Unterstützung dieser Kanäle und für ein gezielteres Kampagnenmanagement hat Consors bereits im Jahr 2000 mit der Implementierung einer CRM-Lösung begonnen. Voraus ging die Einführung einer kundenorientierten Organisationsstruktur, nach der jedes Geschäftsleitungsmitglied eines der vier Kundensegmente verantwortet. Mit dem primär nach dem Kriterium InTime und erst sekundär nach In-Budget bewerteten CRM-Projekt hat das Unternehmen innerhalb von sieben Monaten eine Anwendung von Clarify (heute Amdocs) für das operative CRM und eine Anwendung von SAS für das analytische CRM eingeführt. Auf Basis des zentralen Data Warehouse ließen sich dadurch Transaktionen nach Kriterien wie Depot oder Order auswerten. Insbesondere für prospektive Auswertungen stand eine zentrale CRM-Marketing-Gruppe als interner Dienstleister zur Verfügung. Die vollständige Portalintegration mit personalisierter Online-Beratung im kooperativen CRM war Teil einer zweiten Ausbaustufe. Consors beurteilte die Wirksamkeit seiner CRM-Investitionen vor allem anhand regelmäßiger Kundenzufriedenheitsmessungen und anhand einer Balanced Scorecard (s. Abschn. 7.4). Obgleich nicht aus Gründen der Wirtschaftlichkeit eingeführt, so waren operative Potenziale wie Prozesskostenreduktionen von 30 % und 40 % je nach Geschäftsprozess sowie eine erhöhte Responserate bei Kampagnen, eine höhere Anzahl an Produktabschlüssen und reduzierte Portokosten bei Kampagnen zu beobachten (Alt 2008, S. 300 ff.).

332

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

12.2.2 Supply Chain Management Während das CRM seine Wurzeln im Marketing besitzt, lässt sich das SCM auf den Produktionsbereich, insbesondere die Materialwirtschaft und die Logistik, zurückführen. Im Kern ist das SCM ein nach dem logistischen Flussdenken konzipierter Ansatz, der sich auf den überbetrieblichen Zusammenhang von Leistungen und Prozessen in längerfristigen Partnerbeziehungen konzentriert. Idealerweise handelt es sich dabei nicht nur um die interne Wertschöpfungskette eines Unternehmens, sondern um eine ganzheitliche Betrachtung sämtlicher Akteure und Aktivitäten vom Rohmateriallieferanten bis hin zum Endkunden. Maßnahmen des SCM zielen einerseits auf eine verbesserte Effektivität der Wertschöpfungskette, die sich im Kundenservice bzw. in einer höheren Kundenzufriedenheit niederschlagen (z. B. durch verkürzte Lieferzeiten, hohe Flexibilität bei variierenden Kundenanforderungen). Andererseits stehen Effizienzverbesserungen wie etwa reduzierte Bestände und verminderte Transport-, Lager- und/oder Umschlagskosten im Mittelpunkt des SCM. cc Supply Chain Management  Supply Chain Management bezeichnet die Abstimmung sämtlicher Leistungsflüsse und Aktivitäten zwischen den Partnern eines Wertschöpfungsnetzwerks zur Erreichung gemeinsamer Ziele. Die Kernprozesse des SCM sind Planung, Beschaffung, Produktion, Distribution und Entsorgung. Die Funktionalitäten von SCM-Anwendungen setzen an den logistischen Kernaktivitäten an, die nach dem Supply Chain Operations Reference Model (SCOR) auf die fünf Prozesse Planung, Beschaffung, Produktion, Distribution und Entsorgung fokussieren. Wie in Abschn. 10.1 erwähnt ist das SCOR-Modell ein Referenzmodell, das diese fünf Kernprozesse auf drei Hierarchieebenen untergliedert sowie Standardprozesse (z. B. Build to Order) vorgibt und entsprechende Messgrößen (KPI) zuordnet (Alt 2008, S. 291 ff.). Planungsprozesse gelten dabei als unabdingbare Voraussetzung für alle weiteren Prozesse und können von der strategischen Konfiguration der Liefer- bzw. Wertschöpfungskette hin zum operativen Austausch der geplanten Produktionsdaten des Tages reichen. Die Notwendigkeit zeigt eindrücklich der sog. Peitscheneffekt (Bullwhip-Effekt). Danach kann ein geringer Anstieg der bei den Händlern erwarteten Nachfrage zu einem überhöhten Anstieg bei Herstellern und Lieferanten führen, da diese mangels Kenntnis der Planungen der Händler Sicherheiten in ihre Planungen einbeziehen, um dadurch ihre Lieferfähigkeit sicherzustellen. Allerdings verstärken sich diese Effekte mit jedem in der Wertschöpfungskette beteiligten vorgelagerten Unternehmen, wodurch hohe (Sicherheits-)Bestände in der gesamten Lieferkette die Folge sein können. Durch die Weitergabe von Abverkaufs- und Planungsdaten an alle Unternehmen in der Kette versuchen SCM-Ansätze dieses Problem zu entschärfen. Die Verzahnung von Beschaffungs-, Produktions- und Distributionsprozessen finden sich in Strategien, wie etwa Just in Time (JIT) in der Automobilindustrie (zeitgenaue und bestandsarme Belieferung der Produktion), Efficient Consumer Response (ECR) im Bereich des Handels (Wiederbevorratung der Regale abhängig von ­Abverkäufen) oder dem in vielen Branchen eingesetzten Vendor Managed Inventory (VMI), wobei Hersteller für ihre Kunden die Verwaltung der Lagerbestände übernehmen.

12.2  Überbetriebliche Anwendungen

333

Infolge ihrer Nähe zur betrieblichen Materialwirtschaft müssen SCM-Anwendungen eng mit den ERP-Anwendungen abgestimmt sein. Auf der Basis eines regelmäßig erfolgenden Datentransfers überführt das SCM die operativen ERP-Daten in ein typischerweise hauptspeicherresidentes Datenmodell einer In-Memory-Datenbank (IMDB, s. Abschn. 11.2.6), um dort in einer gegenüber den ERP-Anwendungen erheblich leistungsfähigeren Umgebung Simulationen, Analysen und Optimierungen (z.  B.  Engpasserkennung, Lieferzeitpunktermittlung, Auftragseinplanung) in Echtzeit sowie unter Einbezug realistischer Ressourcenauslastungen durchführen zu können. Die Ergebnisse dieser Vorgänge überträgt die SCM-Anwendung anschließend wieder zurück an die ERP-Anwendung. Vor dem Hintergrund mehrerer in einer Supply Chain beteiligter Unternehmen führen SCM-Anwendungen auch Informationen von ERP-Anwendungen mehrerer Unternehmen zusammen oder es tauschen mehrere betriebliche SCM-Anwendungen im Sinne eines dezentralen Lösungsansatzes die Daten untereinander aus. Die Funktionalitäten von SCM-Anwendungen lassen sich in drei Bereiche unterteilen: • Die Supply-Chain-Konfiguration dient der Analyse und der Gestaltung logistischer Strukturen und Netzwerke. Wie in Abb. 12.3 dargestellt, visualisieren und simulieren derartige Supply Chain Cockpits die in einer Wertschöpfungskette enthaltenen Produktions-, Lager- und Umschlagspunkte mit den Wegen und Kapazitäten. Unter Verwendung einer Notation zur Lieferkettenmodellierung definiert die Supply-Chain-­ Konfiguration die längerfristigen Produktions- sowie Logistikstrukturen und legt dadurch wichtige Eckpunkte bezüglich Flexibilität (z. B. welche Verflechtungen existieren zwischen den einzelnen Teilnehmern?) und Kosten (z. B. Auslegung der Kapazitäten) für eine Supply Chain (bzw. ein Supply-Chain-Netzwerk) fest. • Funktionalitäten der Supply-Chain-Planung haben einen kurz- bis mittelfristigen Zeitbezug. Sie dienen der Abstimmung von Bedarfs- und Absatzmengen, Produktionsgrobund Maschinenbelegungsplänen, Lagerbeständen oder Transporten. Zur Unterstützung der Planungsfunktionalitäten und der (teil-)automatischen Optimierung greifen SCM-Anwendungen auf zahlreiche Planungsalgorithmen des Operations Research zurück (z. B. der linearen Programmierung, Heuristiken), die aufgrund der leistungsfähigen Hauptspeicher-Umgebung in SCM-Anwendungen schneller und umfassender (i. S. v. mehreren Parametern, Berücksichtigung von Kapazitäten) als in ERP-Anwendungen ausfallen können. Lieferanten nutzen die Planungsfunktionalitäten einer SCM-­Anwendung beispielsweise, um aus den Planungsdaten des Herstellers dessen Lagerbestandsführung zu übernehmen (VMI) oder um unter Berücksichtigung der geplanten Kapazitätsauslastung verbindliche Liefertermine zu ermitteln (Available to Promise, ATP). • Die operativen Funktionalitäten einer SCM-Anwendung dienen der Supply-Chain-­ Ausführung. Die Abwicklung der einzelnen Aufträge umfasst die Auftrags-, Transport-, Lager- und Bestandssteuerung. Bekannte Funktionalitäten in diesem Bereich sind das Tracking und das Tracing, wobei Ersteres die Ermittlung des aktuellen Sendungsstatus und Letzteres die Nachverfolgung eines Transports betrifft. Das SCM integriert diese Statusdaten aus mehreren operativen Anwendungen, leitet Auftrags- und Sendungsdaten weiter und berechnet Steuerinformationen. Dies ist besonders wichtig beim Supply Chain

334

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

Abb. 12.3  Beispiel einer SCM-Anwendung © Copyright 2014. SAP SE. Alle Rechte vorbehalten.

Event Management (SCEM), welches geeignete Maßnahmen bei Planabweichungen ergreift. Dazu überwacht die Anwendung die Statusinformationen aus der Supply Chain und kommuniziert im Störungsfall entsprechende Nachrichten (Alerts) nach einem vorab definierten und elektronisch unterstützen Arbeitsablauf (Workflow, s. Glossar). Zusammenfassend liegen die Schwerpunkte des SCM in ausdifferenzierten Planungs- und Optimierungsfunktionalitäten, die SCM-Anwendungen mithilfe eines großen Hauptspeichers in Echtzeit durchführen und in Form geeigneter Darstellungen (z. B. Cockpits) visualisieren können. Das SCM ergänzt dadurch betriebliche ERP-Systeme und hat Schnittstellen zu kundenorientierten Anwendungen, etwa um Lagerbestände, Verfügbarkeiten und Liefertermine in den Angebotsprozess einfließen zu lassen. Dies ist vor allem bei EC-, aber auch bei CRM-Anwendungen notwendig. Eine weitere Schnittstelle besteht zu EC-­Anwendungen, wenn nach einer elektronischen Bestellung (z. B. im Onlineshop) die Transportplanung stattfinden soll. SCM-Anwendungen stammen von Herstellern klassischer ERP-Systemen, wie etwa SAP (SCM), Oracle (SCM), Microsoft (Dynamics SCM) oder Spezialisten wie etwa JDA oder Wassermann (Way). Zunehmend relativieren die IMDB-basierten ERP-Anwendungen (z. B. SAP HANA, s. Abschn.  11.2.7) die Geschwindigkeitsvorteile von SCM-Anwendungen. Während SCM-Anwendungen bislang die Modelle mit den Ressourcen und Flüssen in der Supply

12.2  Überbetriebliche Anwendungen

335

Chain für Analysen in Echtzeit im Hauptspeicher abbilden, bilden diese ERP-Systeme die SCM-Funktionalitäten nun direkt ab (s. Abschn. 10.1), wodurch sich neue Potenziale für das SCM ergeben. Beispielsweise kann die Produktionsprogrammplanung (Sales and Operations Planning) anstatt grober Schätzwerte künftig realitätsnahe Werte aus der Feinplanung verwenden und damit die Planungsgenauigkeit in der Supply-Chain-Planung verbessern (Schmalzried 2014). Generell fallen die Funktionalitäten dedizierter SCM-Anwendungen jedoch weiterhin fortgeschrittener als in ERP-­Systemen aus. SCM bei Alfred Ritter

Ein Beispiel für den Einsatz einer SCM-Anwendung findet sich beim Schokoladenhersteller Alfred Ritter GmbH & Co. KG. Die Anwendung war ein wesentlicher Be­ standteil, um die Produktion von einem Push- auf ein Pull-Prinzip umstellen zu können. Während das Unternehmen bislang für eine anonyme Nachfrage auf Lager gefertigt und die Ware anschließend auf den Markt gebracht hat, versucht Ritter nun, diese genauer an das Markt- und Konsumverhalten anzupassen. Zur bedarfsgerechten Ermittlung des Zulieferbedarfs dient das Supply Network Collaboration System von SAP, welches den Lieferanten Einblick in Bedarfsprognosen und Auftragslage von Ritter erlaubt. Die Lieferanten stellen dann in eigener Verantwortung und Steuerung die notwendigen Materialien im Lager von Ritter nach dem VMI-Prinzip bereit. Durch die laufend angepassten Planungen besitzen die Lieferanten eine höhere Planungssicherheit und können ihre Sicherheitsbestände an jene von Ritter dynamisch anpassen. Weiterhin hat die Informationstransparenz die Durchlaufzeit zwischen Wareneingang und Produktion verringert sowie die Arbeitslast für Disponenten reduziert (SAP 2008).

12.2.3 Electronic Commerce Die elektronische Abwicklung ökonomischer Transaktionen bildet den Aufgabenbereich des EC, der seit Aufkommen des anwendungsorientierten Digitalisierungsbegriff gelegentlich auch die Bezeichnung Digital Commerce erhält.  Da Transaktionen Gegenstand der betrieblichen Auftragsabwicklung sind, finden sich Teile des EC auch häufig in CRM- und/ oder SCM-Lösungen und deuten einerseits auf die Überschneidung der Konzepte, sowie andererseits auf einen dadurch entstehenden Integrationsbedarf hin. cc Electronic Commerce  Electronic Commerce bezeichnet die Abwicklung ökonomischer Transaktionen über elektronische bzw. digitale Medien. Bei den Kernprozessen sind eine Informations-, eine Vereinbarung- und eine Abwicklungsphase zu unterscheiden. Gegenüber dem breiter gefassten E-Business orientiert sich EC am klassischen ökonomischen Transaktionsverständnis der Transaktionskostentheorie (s. Abschn. 12.1). Danach sind Transaktionen Vorgänge zwischen Wirtschaftssubjekten, die sich bezüglich der Aktivitäten, der Teilnehmer und der Kooperationsformen unterscheiden lassen:

336

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

• Ökonomische Transaktionen umfassen Informations-, Vereinbarungs- und Abwicklungsfunktionalitäten. Innerhalb der Informationsphase geht es um die Ermittlung relevanter Produkte und Geschäftspartner, wobei mehrheitlich elektronische Kataloge (z. B. Preisvergleichsseiten im Internet wie etwa idealo) den Vergleich alternativer Angebote unterstützen. Die Vereinbarungsphase beinhaltet die formelle, gegenseitige Bindung an eine vertragliche Vereinbarung. Hier legen die Transaktionspartner die notwendigen Bedingungen wie Preis, Liefertermin oder Serviceleistungen fest. Die Abwicklungsphase schließlich dient der Erfüllung vereinbarter Leistungen, wonach letztlich der Kunde sein Produkt erhält und er dieses als Gegenleistung – möglichst ebenfalls elektronisch – bezahlt. • Als Teilnehmer ökonomischer Transaktionen sind die in Abschn. 5.2.1 erwähnten Akteure zu nennen. Abhängig von den drei Gruppen Behörden (Administration, A), Unternehmen (Business, B) und Endkunden (Consumer, C) (s. Abschn. 5.2.1). ergeben sich neun mögliche Geschäftsfelder und ein breites Anwendungsspektrum für den elektronischen Handel (s. Tab. 5.1). Während Anbieter wie Ebay Transaktionen zwischen Endkunden und/oder Unternehmen betreffen (C2C, B2C), sind Lösungen des E-­ Procurement den volumenmäßig dominierenden Transaktionen zwischen Unternehmen (B2B) zuzuordnen. Abläufe mit öffentlichen Verwaltungen fasst das Anwendungsfeld des E-Government zusammen. Neben der elektronischen Steuererklärung Elster (C2A, s. Tab. 5.1) sind etwa Transferzahlungen der Behörden an die Bürger (A2C) oder die elektronische Umsatzsteuervoranmeldung von Unternehmen (B2A) sowie der Datenaustausch zwischen Behörden (A2A) zu nennen. • Die Kooperationsformen ökonomischer Transaktionen (Governance Structure) definieren in der Transaktionskostentheorie die Organisation der Transaktionen (s. Abschn. 4.4.1). Diese kann grundsätzlich innerbetrieblich (bzw. hierarchisch), in Netzwerken (bzw. kooperativ) oder marktlich erfolgen. Aus Sicht des EC bezeichnen elektronische Hierarchien einseitig dominierte Formen, etwa die Zusammenarbeit von Automobilzulieferern mit einem mächtigen Automobilhersteller über dessen Lieferantenportal. Elektronische Netzwerke dagegen verbinden mehrere tendenziell gleichberechtigte Unternehmen mit komplementären Kompetenzen zur Verfolgung eines gemeinsamen Geschäftszwecks. Ein Beispiel ist die Netbank (seit 2015 Teil der Augsburger Aktienbank), die als Europas erste Internet-Direktbank ohne Filialen gilt, und lange Zeit als virtuell tätige Retailbank ihre Leistungen primär aus einem P ­ artnernetzwerk bezogen hat. Elektronische Märkte (s. Abschn. 5.2.1) wie Ebay oder die elektronischen Börsen im Finanzbereich schließlich bezeichnen multilaterale Systeme, an denen sich mehrere Anbieter und Nachfrager wettbewerblich gegenüberstehen und mit jeder (atomistischen) Transaktion auch die Wahl des Transaktionspartners erfolgt. Zentrales Charakteristikum sind dabei Mechanismen zur dynamischen Preisbildung. Einen Überblick über die Funktionalitäten von EC-Anwendungen liefern die nachfolgend geschilderten verkaufsseitigen (E-Sales) und einkaufsseitigen (E-Procurement) EC-Anwendungen, welche sich jeweils aus Unternehmenssicht unterscheiden lassen. Wenngleich beide Einsatzbereiche auch Besonderheiten aufweisen, so ergänzt die

12.2  Überbetriebliche Anwendungen

337

Abb. 12.4  Beispiel einer EC-Anwendung (Kaufhaus des Bundes)

EC-Anwendung in beiden Fällen das betriebliche ERP-System. Während die E-Sales-­ Anwendungen der elektronischen Produktpräsentation und dem Verkauf über den Online-Kanal dienen, steht beim E-Procurement die Beschaffung von Materialien im Vordergrund, die das ERP-System nicht abdeckt. Bei Letzteren handelt es sich typischerweise um unregelmäßig anfallende Bedarfe mit geringer Wertigkeit, wie dies bei nicht unmittelbar in die Produkte eines Unternehmens eingehenden Hilfs- und Betriebsstoffen bzw. C-Artikeln der Fall ist (z. B. Reagenzien in der Pharmaindustrie, Büroartikel, Verbrauchsstoffe, Gemeinkostenmaterial). Da das ERP-System deren Beschaffung üblicherweise nicht unterstützt, übersteigen hier bei papierbasierten manuellen Prozesse die Prozesskosten vielfach die Materialkosten deutlich. Gemeinsame EC-Funktionalitäten von E-Procurement und E-Sales sind: • Die Produktauswahl zur elektronischen Leistungspräsentation (s. Abb. 12.4) und -konfiguration sowie der Leistungsvergleich beruhen auf einer konsistenten und aktuellen Verwaltung von Produktstammdaten und Verfügbarkeiten in einem elektronischen Katalog entlang einer Artikelklassifikationssystematik. Mit einer solchen Systematik lassen sich Kunden in Gruppen aufteilen und für jede Gruppe unterschiedliche Preise oder Rabatte (z. B. Sonderaktionen) festlegen. Von Bedeutung sind hierbei die Mehrsprachigkeit und -währungsfähigkeit ebenso wie die Kundenverwaltung. Die Kataloganwendung ist mit dem internen ERP-System sowie (externen) Lieferantenanwendungen zur Übermittlung des Artikelstamms sowie der Aufträge verbunden.

338

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

• Die Kontrahierung erlaubt die elektronische Bestellung von Produkten durch den Kunden. Während Kataloge mehrheitlich auf einseitig fixierten Preisen beruhen, kommen bei marktlichen Verfahren (z. B. Auktionen) dynamisch gebildete Preise zum Einsatz. Ausgewählte Produkte gelangen in einen Warenkorb oder ein Auftragsbuch (Order Book) und werden um Angaben zu Käufer und Bezahlung ergänzt. Im Idealfall fließen diese Informationen ohne manuelle Zwischenschritte weiter in die Anwendung zur Auftragsbearbeitung des Anbieters. • Die Abwicklung umfasst drei grundlegende Funktionalitäten. Dazu zählen die Auftragsabwicklung (E-Fulfillment) mit Leistungen zur elektronischen Auftragseingabe und -verarbeitung, dem Lagermanagement oder After Sales Services, die Transportabwicklung (E-Logistics) mit Leistungen zur physischen Distribution und zur Sendungsverfolgung (Tracking & Tracing, s. Abschn. 12.2.2) sowie die elektronische Zahlungsabwicklung (E-Payment) zur Regelung der Zahlungsmodalitäten wie Überweisungen, Kontoauszüge oder Gutschriften. Da diese Funktionalitäten häufig externe Finanzdienstleister (s. Abschn. 10.3.3) übernehmen (z. B. Apple Pay, Google Pay, Paydirekt, PayPal oder Kreditkarten), sind hier weitere externe Schnittstellen notwendig. • Die Auswertung bezeichnet auf der Protokollierung der EC-Aktivitäten beruhende Funktionalitäten. Hierunter fallen Statistiken zur Häufigkeit der gekauften Produkte, dem Verhalten der Anwender oder Zeitverläufe von der Auftragseingabe bis zur Auslieferung. Auf Grundlage dieser Informationen lassen sich beispielsweise das Produktangebot (z. B. verstärkte Beschaffung beliebter Produkte), die Gestaltung eines Onlineshops (z.  B. durch sog. Landing Pages, welche Kunden gezielt zu einem Produkt führen) sowie Marketing-Aktivitäten (z. B. Angebote beliebter Produkte) gestalten. Besonderheiten finden sich bei E-Sales in der Verbindung der Online-Produktauswahl mit dem Konzept der Auftragsfertigung (Build to Order). Hier erlauben Konfiguratoren die Zusammenstellung eines individuellen Produkts aus einem vordefinierten Portfolio standardisierter Komponenten. So können Kunden im Automobilbereich die Ausstattung ihrer Fahrzeuge interaktiv spezifizieren (z. B. Motorleistung, Innenausstattung, Zubehör) und damit Grundmodelle auf ihre Anforderungen zuschneiden. Im Gegensatz dazu richtet sich das E-Procurement an die Mitarbeiter eines Unternehmens und bildet Produkte gemäß vorher verhandelter Rahmenbedingungen und -verträge in der Anwendung ab. Hierbei sind drei Besonderheiten von Bedeutung: • Zunächst gilt es, die regelmäßig erforderlichen Aktualisierungen der Kataloge bezüglich der Artikel(-merkmale) und Preise möglichst automatisiert durchzuführen. Hier kommen standardisierte Katalogaustauschformate (z. B. des Bundesverbandes für Materialwirtschaft und Einkauf, BME) ebenso zum Einsatz wie Klassifikationssysteme zur Vereinheitlichung der Katalogkategorien (z. B. eCl@ss). Ein Beispiel zeigt Abb. 12.4. • Nachdem Mitarbeiter die Produkte im E-Procurement auf Kosten des Unternehmens erwerben, sehen die Anwendungen die Funktionalität des Genehmigungsworkflows vor. Bestellanforderungen gelangen dabei zur Freigabe zum Kostenstellenverantwortlichen und erst nach dessen Zustimmung zur Ausführung an den Lieferanten.

12.2  Überbetriebliche Anwendungen

339

• Nach der Zustellung an den Bedarfsträger im Unternehmen erfolgt die Verrechnung auf die entsprechende Kostenstelle. Damit auch dies automatisiert geschehen kann, sehen Anwendungen für das E-Procurement die Abstimmung mit den jeweiligen betrieblichen Kostenstellensystematiken vor. Zusammenfassend liegen die Potenziale des EC in der direkten und eineindeutigen – also Fehllieferungen vermeidenden – Produktauswahl, der direkten – und damit aufwandsreduzierenden – Auftragseingabe durch den Kunden bzw. Bedarfsträger sowie der Direktbelieferung vom Lieferanten an den Besteller. Nachdem alle Aktivitäten über die EC-Anwendung stattfinden, verbessern sich die Möglichkeiten zur Prozessführung – mit entsprechend positiven Auswirkungen auf Auslieferungszeiten und Prozesskosten. Zu den Anbietern von Standardanwendungen im Bereich EC zählen ERP-Anbieter wie SAP und Oracle, CRM-Anbieter wie Salesforce sowie Spezialisten wie Intershop und Magento. Nach dem Multi- bzw. Omni-Kanalmanagement sind gerade beim E-Sales die Verbindungen zwischen den Verkaufskanälen, und generell die Integration innovativer Logistik- und Bezahldienste in Zukunft von steigender Bedeutung. E-Commerce bei LeShop und UBS

Aus der Vielzahl heute existierender EC-Anwendungen seien zwei beschrieben. Verkaufsseitig ist LeShop.ch ein Beispiel für den elektronischen Lebensmitteleinkauf, der mit Lösungen von food.de oder Rewe Lieferservice auch in Deutschland zunehmende Verbreitung erfährt. Das Tochterunternehmen des Schweizerischen Einzelhandelsunternehmens Migros setzt eine Anwendung für E-Sales für den nahezu flächendeckenden (ca. 90 % aller Schweizer Haushalte) Vertrieb sämtlicher Supermarktartikel wie Brot, Fleisch, Obst und Gemüse sowie ausgewählter Non-Food-Artikel wie etwa Unterwäsche ein. Die über den Onlineshop bis 24:00 aufgegebenen Bestellungen liefert LeShop am folgenden Tag zwischen 17:00 und 20:00 aus, die Bezahlung kann über Kreditkarte, die Schweizer Post oder Einzahlungsschein erfolgen. Die Anwendungen erlauben LeShop eine automatisierte Steuerung der Auftragslogistik und -abrechnung von der Bestellung der Kunden im Onlineshop bis zur Auslieferung durch die Schweizerische Post. Neben dem Heimlieferservice können Kunden die Ware in Filialen und Packstationen sowie eine Zeit lang über ein Anfang 2019 jedoch wieder eingestelltes Volvo In-car Delivery-Verfahren e­ rhalten. Nach einer Evaluation bestehender Standardsoftware hat sich LeShop für eine integrierte Eigenentwicklung mit drei Hauptkomponenten entschieden: das Frontend (Website mit Onlineshop), das Backend (alle internen operativen Prozesse einschließlich der Anbindung der Barcode Scanner der Schweizer Post) sowie die als „Call Center“ bezeichnete Kundenverwaltung. Neben diesen Eigenentwicklungen kommen auch Tools für spezielle Bereiche zum Einsatz. Für die Produktsuche im Onlineshop verwendet LeShop Celebros, welches eine selbstlernende Suche beinhaltet und das Kaufverhalten der Kunden analysiert. In der Warenwirtschaft kommt das Warehouse Management System XElog zum Einsatz, da dieses u. a. auch der Handelspartner Migros nutzt, und damit eine kooperative Lagerbestandsführung vereinfacht.

340

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

Eine Anwendung für das E-Procurement setzt beispielsweise das globale Finanzinstitut UBS bei der Beschaffung von Gütern und Dienstleistungen ein. Wesentliche Ziele sind dabei die Bündelung von Volumina, die Einhaltung von Rahmenverträgen und die Reduzierung der Prozesskosten vom Einstellen der Produkte in einen Katalog über die Bestellung bis hin zur Rechnungsprüfung. UBS-Mitarbeiter können benötigte Artikel im SAP-System auswählen und in einen Warenkorb legen. Eine Ampeldarstellung teilt mit, ob alle relevanten Daten (Betrag, Lieferant) hinterlegt sind oder sich ein Einkäufer einschalten muss. Nach erfolgter Freigabe bzw. Genehmigung wandelt die Anwendung den Warenkorb in Bestellungen um und leitet diese elektronisch an den Lieferanten weiter. Erfolgt der Rechnungseingang elektronisch, so wird die Rechnung automati­ siert im SAP Materials Management (MM) mit der Bestellung abgeglichen und bei Übereinstimmung zur Zahlung freigegeben sowie anschließend mit der Software IXOS archiviert. Die von der Swisscom betriebene Conextrade-Plattform reduzierte die technische Kommunikation mit den Geschäftspartnern auf eine Schnittstelle und realisiert dadurch einen medienbruchfreien sowie automatisierten Nachrichtenaustausch mit den Lieferanten. Als Format kommt bei Conextrade der xCBL-Standard (XML Common Business Library) zum Einsatz, den ein Konverter (SAP Business Connector) bei der UBS in das IDoc-Format umwandelt, welches wiederum das SAP SRM (Supplier Relationship Management, Materials Management, Financial Accounting) verwendet. Den Katalog betreibt für die UBS ein zweiter Dienstleister. Das Unternehmen Heiler (heute Teil von Informatica) übernimmt die Katalogpflege und damit auch die Anbin­ dung der Lieferanten bei der Aktualisierung von Preisen oder Artikeldaten. Die Bestell­ applikation der UBS (SAP SRM) greift über ein Open Catalog Interface (OCI) auf diesen zu (Wölfle und Schubert 2009).

12.3 Nutzen vernetzter Anwendungen Betriebliche Anwendungen haben in Unternehmen wichtige Potenziale erschlossen, die von Rationalisierungseffekten (z.  B. reduzierte Antwortzeiten, Durchlaufzeiten, Pro­ zesskosten) hin zu Wettbewerbseffekten (z. B. neue vernetzte Geschäftsmodelle) reichen (s. Abschn. 3.3). Durch das Wechselspiel von technischer Gestaltung – also dem Einsatz einer integrierten betrieblichen Anwendung (s. Kap. 10) – und fachlicher Gestaltung – also der abgestimmten (Neu-)Gestaltung von Geschäfts-, Prozess- und IS-Modell wie im zweiten Teil beschrieben  – lassen sich verschiedene Grade der IT-basierten Transformation unterscheiden (s. Abb. 12.5). Die geringste Veränderung bedeutet die Automation einzelner betrieblicher Funktionen (z. B. des Rechnungswesens), während die Realisierung der innerbetrieblichen Integration mit der ablauf- und funktionsbereichsübergreifenden Sicht weitere Potenziale erschließt. Allerdings sollte bei Einführung betrieblicher Anwendungen nicht die Abbildung bestehender Prozesse, sondern die Neugestaltung (BPR, s. Abschn. 6.1) unter Berücksichtigung der integrierten Anwendung im Vordergrund stehen. Ansonsten gehen Rationalisierungseffekte durch überholte Zuständigkeiten verloren.

12.3  Nutzen vernetzter Anwendungen Potenzieller Nutzen

Gering

Grad der Transformation

Hoch

Gering

341

Revolutionär

Hoch

Business Scope Redefinition (BSR)

Business Network Redesign (BNR)

Business Process Redesign (BPR)

Interne Integration

Funktionale Automation

Evolutionär

Abb. 12.5  Transformation und Nutzen des IT-Einsatzes (Venkatraman 1994, S. 74)

­ eispielsweise müssen Berichtswege bei integrierten Anwendungen nicht mehr hierarB chisch erfolgen, da Entscheidungsträger gleichermaßen auf die Informationen zugreifen können. Einen nächsten Schritt bedeutet die Ausweitung der Prozessgestaltung auf die Vernetzung mit Kunden und Lieferanten (Business Network Redesign) durch den Einsatz überbetrieblicher Anwendungen (s. Abschn. 12.2) sowie die häufig darauf aufbauende Definition neuer Geschäftsmodelle (Business Scope Redefinition). Anhand der in Teil 2 eingeführten Ebenen des Business Engineering (s. Abschn. 6.2) lassen sich die Effekte betrieblicher Anwendungen in vier Kategorien zusammenfassen (Alt 2008, S. 56 ff.): (1) Die Basis bilden Kommunikations- und Informationseffekte, welche die ubiquitäre bzw. ortsunabhängige Verfügbarkeit von Informationen in den Vordergrund stellen und damit auf der IS-Ebene anzusiedeln sind. Über (möglichst standardisierte) Schnittstellen lassen sich Daten aus betrieblichen Anwendungen mit anderen Anwendungen austauschen, etwa um Lagerbestände und Liefertermine in den ­Angebotsprozess einfließen zu lassen. Mit der Anbindung von sämtlichen Objekten an das Internet (Internet der Dinge, s. Abschn. 5.5.1) lassen sich weitere Informationen für betriebliche Anwendungen gewinnen und bilden die Voraussetzung medienbruchfreier Kommunikation in Echtzeit unter Vermeidung manueller Eingriffe (s. Abschn. 5.5). So können intelligente mobile Geräte nicht nur durch Sensorik (z. B. GPS, Bewegung, Temperatur) und intuitive Eingabemöglichkeiten Daten am Ort ihres Entstehens erfassen, vielmehr können sie am Ort der Datenverwendung durch Displays und Anbindung an physische Systeme (sog. Cyber-Physical Systems, s. Abschn. 5.5.1) dort auch Zustände beeinflussen. Informations- und Kommunikationseffekte sorgen zwar für eine effizientere Informationserfassung, -weitergabe und -ausgabe, aber sie sorgen in der Praxis erst in Verbindung mit

342

12  Anwendungen zur Vernetzung mit Kunden und Lieferanten

Prozesseffekten für einen nachhaltigen geschäftlichen Nutzen. So ist eine reine ­Beschleunigung der Übertragung einer elektronischen Nachricht erst dann sinnvoll, wenn die empfangenden Systeme diese dann auch unverzüglich weiterverarbeiten, und eine Weiterleitung nicht erst nachts in einem sog. Batchlauf erfolgt. (2) Die zweite Kategorie bilden die Prozesseffekte. Sie beruhen auf den Effizienz- und Transparenzpotenzialen des Informations- und Kommunikationseffekts und schlagen sich spezifisch in den betroffenen Prozessen nieder. So profitieren die Transaktionsprozesse des EC von einer verbesserten Informationsbeschaffung über Produkte und Leistungen (z. B. in elektronischen Katalogen), der Nutzung neuer Koordinationsmechanismen (z.  B. elektronischer Märkte) sowie effizienten Abwicklungsprozessen. Neben reduzierten Transaktionskosten sind insbesondere durch die verbesserte Markttransparenz Preiseffekte möglich, wobei jedoch häufig Lieferkosten einerseits und die verbesserten Möglichkeiten zur Schaffung von Marktintransparenz durch Preis- und Produktdifferenzierung andererseits die verringerten Produktpreise überkompensieren. Im SCM ist ebenfalls die Steuerung von materiellen und immateriellen Leistungsflüssen zu nennen, da aufgrund der Weitergabe von Planungs- und Statusdaten die materialflussbezogenen Aktivitäten enger abstimmbar sind. Reduzierte Durchlaufzeiten, Lagerbestände und höhere Verfügbarkeiten sind daher typische Prozesseffekte im SCM. Im Kundenbeziehungsmanagement schließlich betreffen Prozesseffekte die genauere Zielkundenansprache, die verbesserten Möglichkeiten im Cross- und Upselling sowie die effizientere Kundeninteraktion im Servicebereich (z.  B. durch Self-­ Service-­Portale). (3) Auf Ebene der Strategie lassen sich vor allem Struktur- bzw. Akteurseffekte identifizieren. Danach können Anwendungen die zur Kundeninteraktion genutzten Kommunikationskanäle ebenso beeinflussen wie die in einer Geschäftsarchitektur beteiligten Marktteilnehmer und die dabei zum Einsatz kommenden neuen Koordinationsformen (Governance Structures). Bezüglich des Verhältnisses zu anderen Vertriebskanälen lässt sich zeigen, dass elektronische Kanäle das traditionelle Verhältnis zwischen Reichhaltigkeit und Reichweite auflösen (Evans und Wurster 1997) und die Kanäle – also mobile, online, physisch  – in Multikanal-Konzepten zunehmend parallel zum Einsatz kommen. Dies kann zwar zur Umsatzentwicklung (breitere Marktansprache, Online-Kunden weisen höhere Durchschnittskäufe auf) führen, gleichzeitig aber erhebliche Kosten im Aufbau und in der Pflege der Kanäle bedeuten. Seitens der Marktteilnehmer können Intermediationseffekte entstehen, wenn sich in einer Branche z.  B. aufgrund eines heterogenen unübersichtlichen Angebots günstige Voraussetzungen für das Geschäftsmodell eines Intermediärs (z. B. einen Serviceorchestrator, s. Abschn.  7.3) bieten. Ebenso gibt es die Möglichkeit zur Umgehung bestehender Intermediäre, also etwa wenn ein Automobilhersteller selbst einen elektronischen Kanal zum Verkauf seiner Produkte an Endabnehmer (E-Sales) betreibt (Disintermediation). Den grundsätzlich möglichen Einspareffekten durch Entfallen der Margen bestehender Händler sind jedoch die dann beim Hersteller anfallenden zusätzlichen Kosten für Sortiments- und Vertriebsfunktionen gegenüberzustellen. Letztlich sorgen

12.3  Nutzen vernetzter Anwendungen

343

reduzierte Transaktionskosten für Verschiebungen in den Koordinationsformen. Danach nehmen marktlich oder netzwerkartig organisierte Formen zulasten der innerbetrieblichen Leistungserstellung zu. Forschungsergebnisse haben gezeigt, dass insbesondere im B2C-Bereich von einer Verbreitung marktlicher Koordination (sog. Move-to-the-­Market-Hypothese) auszugehen ist, während im B2B-Bereich den längerfristigen, und einer vertieften Zusammenarbeit entgegenkommenden Netzwerkformen (z. B. strategische Allianzen, Joint Ventures) eine höhere Bedeutung zukommt. (4) Ein vierter Effekt ist auf überbetrieblicher Ebene zu beobachten. Ebenso wie die Nutzung von Telefonie- oder Faxgeräten findet die Verwendung von Kommunikationsinfrastrukturen, Standards für betriebliche Daten und Prozesse sowie die eingesetzten Plattformen (bzw. elektronische Märkte) im Kontext mehrerer Anwender statt. Gerade bei elektronischen Märkten im B2B-Bereich (z. B. Börsen im Finanzbereich) oder im B2C-Bereich (z. B. Ebay) ist eine ausreichende Marktliquidität i. S. v. ausreichenden Kauf- und Verkaufsgeboten von zentraler Bedeutung. Neben dieser kaum objektiv messbaren und sozial bestimmten kritischen Masse umfassen Netzwerkeffekte das Phänomen der Externalitäten. Danach haben die Marktteilnehmer zunehmend positive (oder auch negative) Erwartungen an die Verbreitung bzw. Nutzung des Marktes, sodass ab einem gewissen Punkt (z. B. dem Erreichen der kritischen Masse) selbstverstärkende Effekte auftreten, und der Nutzen eines Teilnehmers überproportional mit der Anzahl weiterer Teilnehmer steigt. Zu beachten ist dabei, dass nicht nur die Anzahl der an einem Markt teilnehmenden Unternehmen ausschlaggebend ist, sondern vor allem die von diesen Unternehmen operativ über den Marktplatz durchgeführten Transaktionen. Insbesondere die zuständigen Mitarbeiter sind daher in die Gestaltung einzubeziehen, um zu vermeiden, dass sich diese durch die Anwendung substituiert fühlen. Zusammenfassend hat Teil 3 die Funktionalitäten von Anwendungen innerhalb von Unternehmen und in ihrer Vernetzung über Unternehmensgrenzen hinweg beschrieben. Sie zeigen das umfassende Wirk- und Bedingungsgeflecht, das bereits die ersten beiden Teile des Buches thematisiert hatten. Der Einsatz geht weit über die Implementierung ­eines technischen Systems hinaus und fordert den Wirtschaftsinformatiker in vielerlei Hinsicht (s. Kap. 15).

Teil IV Softwareentwicklung

Phasenmodelle in der Softwareentwicklung

13

Zusammenfassung

Dieses Kapitel erläutert zunächst den Gegenstand und die Ziele der Softwareentwicklung. Es stellt die grundlegenden Entwicklungsstrategien und den Softwareentwicklungszyklus vor und beschreibt die Rolle, Probleme und die Techniken des Anforderungsmanagements. Dabei geht es auf die Problematik unklarer Anforderungen und Ziele in Pflichtenheft und Lastenheft ein. Es folgt die Vorstellung sowohl klassischer als auch agiler Vorgehensmodelle inklusive ihrer jeweiligen Vor- und Nachteile. Dies sind zum einen das Wasserfallmodell und das V-Modell, zum anderen Extreme Programming, Scrum, KANBAN und Feature Driven Development sowie der Dev­Ops-Ansatz. Ergänzend dargestellt sind die Bereiche des Projekt-, Risiko-, Qualitäts- und Konfigurationsmanagements von Entwicklungsprojekten.

13.1 Gegenstand und Ziele Schon in den 1950er-Jahren ist Systems Engineering als Sammelbegriff für die Gesamtheit der Modelle und Methoden zur Strukturierung und Entwicklung komplexer Systeme entstanden. Die ingenieurmäßige, d. h. modell- und methodenbasierte Entwicklung von Software begann jedoch erst Ende der 1960er-Jahre mit Dijkstras Erkenntnis, dass der Programmcode weder als Kommunikations- noch als Dokumentationsgrundlage geeignet ist, und auch nicht die Wiederverwendung von Problemlösungen zulässt (Dijkstra 1967). Seitdem werden verschiedene Phasen der Softwareentwicklung unterschieden, die durch abnehmende Abstraktion bei gleichzeitig zunehmender Realisierungsnähe gekennzeichnet sind, und deren Ergebnisse erst in ihrer Gesamtheit ein Softwareprodukt beschreiben.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_13

347

348

13  Phasenmodelle in der Softwareentwicklung

cc Softwareentwicklung  Die Softwareentwicklung umfasst alle Aktivitäten der Softwareplanung, der Softwaredefinition, des Softwareentwurfs und der Softwareumsetzung unter Berücksichtigung von Kundenwünschen und geforderten Qualitätseigenschaften (in Anlehnung an (Balzert 2009)). 1969 wurde der Begriff Software Engineering für die pünktliche, wirtschaftliche und systematische Entwicklung sowie Wartung von Software eingeführt (Naur und Randell 1969). Die Abstraktionsebenen des Softwareentwurfs wurden 1971 auch auf den Entwurf von Datenbanken übertragen. Zur Dimension der Realisierungsnähe kam die Dimension der Anwendungsnähe hinzu: Neben realisierungsunabhängigen, anwendungsspezifischen „externen“ Entwürfen sind demnach auch „konzeptionelle“ Entwürfe anzufertigen, die sowohl realisierungs- wie auch anwendungsunabhängig sind. Die konsequente Trennung fachlicher und realisierungsbezogener Softwarebeschreibungen sowie die Mitte der 1980er-­Jahre einsetzende Verfügbarkeit computergestützter Systementwicklungsumgebungen (CASE = Computer Aided Software Engineering) trugen zur Verbesserung der Situation bei. In CASE-Umgebungen (s. Glossar) stehen rechnergestützte Werkzeuge für alle Phasen und Sichten der Softwareentwicklung zur Verfügung und erlauben es im Idealfall, unter einer gemeinsamen Oberfläche und auf Grundlage einer gemeinsamen Entwicklungsdatenbank Software in integrierter Form zu entwickeln und dabei bereits bestehende Software- und IS-Elemente konsequent wieder zu verwenden. Mit der Verbreitung von CASE-Umgebungen verschiebt sich der Fokus von der Softwareentwicklung zur integrierten IS-/Systementwicklung, d. h. Daten- und Organisationssicht ergänzen und ersetzen teilweise die im Software Engineering traditionell im Vordergrund stehende Funktionssicht (s. z.  B. die Ausführungen zu den ARIS-Sichten in Abschn. 6.2). Eine abgestimmte Berücksichtigung verschiedener Sichten ist notwendig, da z. B. bei einer rein funktionsorientierten Softwareentwicklung die Gefahr besteht, dass Datenstrukturen nicht für eine Verwendung in mehreren Funktionsbereichen ausgelegt und Daten somit redundant gespeichert sind. Viele Anwendungsgeneratoren und einige objektorientierte Ansätze beginnen deshalb mit der Modellierung der Datensicht. Dem Vorteil eines konsistenten Datenmodells steht aber die Gefahr der Funktionsredundanz und einer erschwerten Wiederverwendung von Funktionen gegenüber. Einen erfolgversprechenden Ansatz stellt die Ableitung aller Teilsichten aus einem übergreifenden, wenn auch meist aggregierten Gesamtmodell dar. Prozessmodelle (s. Abschn. 8.3) können hier dazu dienen, die verschiedenen Systemsichten integrativ abzubilden. Spätestens in den 1990er-Jahren wird deutlich, dass in Unternehmen nur wenige betriebliche Anwendungen so einzigartig sind, dass die Entwicklung einer Individualsoftware notwendig ist. In den meisten Fällen ist es möglich, Standardsoftware (s. Abschn. 2.3.1 und 10.2) so anzupassen, dass die in der jeweiligen betrieblichen Informationsverarbeitung gewünschten Funktionalitäten mit wesentlich geringeren Kosten und in viel kürzerer Zeit realisiert werden können. Beim Standardsoftwareeinsatz kaufen Unternehmen nämlich keine maßgefertigte Anwendung, sondern lediglich eine Referenzlösung, die durch Anpassung an die jeweiligen Verhältnisse des Unternehmens sinnvoll nutzbar wird. In der Praxis haben größere Systementwicklungsprojekte aufgrund des hohen Komplexitätsgrades teilweise

13.1  Gegenstand und Ziele

349

den Charakter von Eigenentwicklungsprojekten und teilweise den Charakter von Standardsoftware-Einführungsprojekten (s. Abschn.  10.4). Dennoch ist erkennbar, dass sich das Schwergewicht der Softwareentwicklung im betrieblichen Bereich von der Eigenentwicklung individueller Anwendungen zur Anpassung standardisierter Softwareprodukte bzw. Softwarekomponenten verschiebt. Unabhängig von der Art der Softwareentwicklung haben Softwareprodukte bestimmte prozessbezogene wie auch ergebnisbezogene Qualitätsanforderungen zu erfüllen (Schmitz 1990): • Änderbarkeit. Sie sollen leicht änderbar und anpassbar sein (Easy to Modify), beispielsweise durch Parametrisierung. • Allgemeingültigkeit. Komponenten der Software sollen mit geringem Änderungsaufwand auch für ähnliche Problemstellungen anwendbar sein. • Benutzerfreundlichkeit. Sie sollen dem Benutzer eine sichere, komfortable und leicht verständliche Handhabung ermöglichen. Dabei sollen sie über endbenutzerfähige, und in allen Komponenten gleich gestaltete Dialogelemente verfügen (Easy to Learn). • Effizienz. Sie sollen ein angemessenes zeitliches Verhalten (z. B. kurze Antwortzeiten) bei geringem Ressourcenaufwand aufweisen. • Funktionsabdeckung. Sie sollen die im Fachkonzept geforderten Funktionen vollständig enthalten. • Kompatibilität. Sie sollen sich mit anderen bereits vorhandenen Anwendungen leicht verbinden lassen, um Informationen austauschen zu können. • Portabilität. Sie sollen auf verschiedenen Hardware- und Systemsoftwareplattformen konsistent benutzbar sein (Easy to Use). • Produktivität. Sie sollen unter Benutzung portabler, ineinandergreifender Werkzeuge soweit wie möglich automatisiert entwickelbar sein. • Richtigkeit. Sie sind richtig (korrekt), wenn sie für jede Eingabe aus dem Definitionsbereich der Funktion eine richtige Ausgabe erzeugen. • Robustheit. Sie sollen möglichst alle falschen Eingaben erkennen und melden. Eingabefehler sollen nicht zu Systemabstürzen führen. • Sicherheit. Sie sollen Funktionen enthalten, die automatisiert vor Verlust der Daten schützen (beispielsweise bei einem Systemausfall). • Testbarkeit. Einzelne Komponenten der Software sollen unabhängig voneinander und ebenso wie die Gesamtanwendung leicht testbar sein. Die Vielschichtigkeit komplexer Software erfordert verschiedene Konzepte und Methoden die ineinander greifen müssen, um alle Entwicklungsphasen und Sichtweisen konsistent abzudecken. Die Methodenanwendung soll dabei nicht nur vollständig, pünktlich und wirtschaftlich sein. Die Arbeitsteiligkeit der Entwicklung und Einführung sowie die Langlebigkeit der Ergebnisse erfordern es, den Methodeneinsatz plan- bzw. steuerbar zu gestalten und validierbare/verifizierbare, zumindest aber nachvollziehbare Ergebnisse zu erzeugen. Ziel ist daher ein möglichst hoher Grad an Formalisierung und Standardisierung. Um dies zu erreichen können verschiedene Entwicklungsstrategien und methodische Ansätze zum Einsatz kommen, die nachfolgend beschrieben sind.

350

13  Phasenmodelle in der Softwareentwicklung

13.2 Grundlegende Entwicklungsstrategien Grundsätzlich ist die Entwicklung eines komplexen Systems auf zwei verschiedene Arten möglich (s. Abb. 13.1, s. auch Abschn. 6.1). Das Top-down-Vorgehen beschreibt das System zunächst auf vereinfachter und/oder aggregierter Ebene und verfeinert diese Beschreibung dann solange schrittweise, bis eine detaillierte Spezifikation vorliegt. Das Bottom-­up-­Vorgehen beschreibt die verschiedenen Bestandteile des Systems zunächst detailliert. Die Detailbeschreibungen werden dann sukzessive ergänzt und schließlich, u. U. vergröbert, zum Gesamtmodell des Systems integriert. Beide Vorgehensweisen haben Vor- und Nachteile: • Das Top-down-Vorgehen entspricht eher der menschlichen Vorgehensweise bei der Problemlösung. Die Gesamtsicht auf das System bleibt bei (konsistenten) Verfeinerungen dann erhalten, wenn schon am Anfang der Systembeschreibung eine „richtige“ ­Gesamtsicht vorliegt. Aber auch dann können die Verfeinerungen zu letztlich inkompatiblen Teilmodellen führen. • Das Bottom-up-Vorgehen erlaubt es, mit der Analyse übersichtlicher, wohlverstandener Teilprobleme zu beginnen. Allerdings ist die Integration der Teillösungen u. U. aufwändig, und die sich schließlich ergebende Gesamtsicht des Systems kann von der ursprünglichen Zielsetzung abweichen. Zur konkreten Umsetzung eines Entwicklungsvorgehens kommen Methoden zum Einsatz (s. die Inhalte zum Methoden Engineering in Abschn. 6.1).

0

1

2 Bottom-UpEntwicklung

Top-DownEntwicklung

1.1

1.1.1

1.2

2.2

2.1

1.1.2 1.2.1

2.2.2 2.2.1

2.2.3

Abb. 13.1  Grundlegende Entwicklungsstrategien (Schönthaler and Németh 1990, S. 17)

13.2 Grundlegende Entwicklungsstrategien

351

cc Methode  Eine Methode enthält Aussagen über die Aktivitäten des Vorhabens und deren Reihenfolge, über die hierbei verwendeten Techniken, über die beteiligten Akteure bzw. Rollen sowie über die Repräsentation der Ergebnisse. So ist z. B. die Entity-Relationship-Modellierung (s. Abschn. 9.5) eine Methode/Vorschrift zur semantischen Datenmodellierung, die auch die Dokumentation der Ergebnisse in Form von Entity-Relationship-Diagrammen festlegt. Zur strukturierten Beschreibung von Aktivitätsfolgen (als ein wesentliches Element einer Methode) kommen Vorgehensmodelle zum Einsatz. cc Vorgehensmodell  Ein Vorgehensmodell enthält die zur Erreichung eines bestimmten Ergebnisses notwendigen Aktivitäten, und stellt diese in einer sachlogischen Reihenfolge dar. Im Bereich der Softwareentwicklung sind Vorgehensmodelle häufig in Form von Phasenmodellen gestaltet, bei denen einzelnen Aktivitäten unterschiedlichen übergeordneten Phasen zugeordnet sind. So ist z. B. SAP Activate (s. Abschn. 10.4.2) ein Vorgehensmodell zur Einführung der betriebswirtschaftlichen Standardsoftware SAP ERP (s. Abschn. 10.2.1). SAP Activate empfiehlt, welche Aktivitäten in einem ERP-­Einführungsprojekt in welcher Reihenfolge im Rahmen verschiedener Phasen durchgeführt werden sollten. Zusätzlich enthält SAP Activate auch bereits über die reine Aktivitätsabfolge hinausgehende Angaben zu den beteiligten Akteuren und den geplanten Ergebnissen. Softwareentwicklungswerkzeuge (wie die bereits in Abschn.  13.1 genannten CASE-­ Anwendungen (s. Glossar)) sind Softwareprodukte, die bei der Anwendung von Softwareentwicklungsmethoden in der Praxis unterstützen. So ermöglicht z.  B. der Oracle SQL Developer das Bearbeiten von Datenbankobjekten, das Erstellen und Testen von SQL-Anweisungen und Skripten, das Erstellen und Debuggen von SQL-Prozeduren und eine einfache Datenbankanalyse. Neben den rein auf die inhaltliche Gestaltung einer Software ausgerichteten Aufgaben sind während der Entwicklungsphasen weitere phasenübergreifende Aktivitäten auszuführen. Dies umfasst sowohl Aktivitäten im Bereich des Projektmanagements (s. Abschn. 13.6), der Qualitätssicherung (s. Abschn. 13.7) sowie des Konfigurationsmanagements (s. Abschn. 13.8) (s. Abb. 13.2). Abb. 13.2  Phasenübergreifende Komponenten zur Unterstützung einer Softwareentwicklungsmethode

Softwareentwicklung

Qualitätsmanagement

Konfigurationsmanagement

Projektmanagement

352

13  Phasenmodelle in der Softwareentwicklung

13.3 Softwareentwicklungszyklus Eine Software unterliegt wie jedes Produkt einem Lebenszyklus. Dieser Lebenszyklus ist in Zeitabschnitte (sog. Phasen) unterteilt und wird im Folgenden kurz dargestellt, um die Einordnung der Softwareentwicklung in den Lebenszyklus aufzuzeigen. Anlehnend an die Norm ISO 12207 (ISO 12207 1995) ist dieser Lebenszyklus in Abb. 13.3 dargestellt. Der Softwarelebenszyklus und auch die Softwareentwicklung beginnt mit der Projektdefinitionsphase, in der die Problembereiche im bisherigen IS-Anwendungskontext identifiziert und die sich daraus ergebenden groben Zielstellungen in Bezug auf die zu entwickelnde Software formuliert werden. Die Softwareentwicklung endet zunächst mit der Integrations- und Testphase. Es folgt der produktive Einsatz der Software (Betriebsphase). Während der Betriebsphase können (wiederkehrende) Aktivitäten zur Wartung, Aktualisierung und/oder Erweiterung der Software erfolgen, die ebenfalls zur Softwareentwicklung zu zählen sind. Der Lebenszyklus einer Software endet schließlich mit deren Stilllegung und ggf. mit der Ablösung durch ein Nachfolgeprodukt. Abb. 13.4 zeigt die Abfolge der wichtigsten Phasen der Softwareentwicklung am Beispiel des Wasserfallmodells (Boehm 1983) sowie die in den jeweiligen Phasen erzeugten Ergebnisse. Das hier dargestellte Wasserfallmodell ist linear zu durchlaufen und enthält

Im ple me nti eru ng tion Integra st e u nd T

Softwareentwicklungszyklus

Entwurf

ng, artu erung it ie W sow d Erwe ieb n Betr rung u alisie Aktu

Abb. 13.3  Lebenszyklus einer Software

Proje ktd (Vor efinition phas e)

gs un er rd se fo aly An an

/ ung g lös Ab legun l Sti

13.3 Softwareentwicklungszyklus

353 Projektidee, Machbarkeitsanalyse

Projektdefinition (Vorphase)

Anforderungskatalog, Lastenheft

Anforderungsanalyse

IT-Konzept, Pflichtenheft

Entwurf

Softwarekomponenten

Implementierung

Integration und Test

Wartung, Erweiterung und Aktualisierung

Integrierte Software

Updates, Upgrades

Abb. 13.4  Softwareentwicklungsphasen und ihre Ergebnisse am Beispiel des klassischen Wasserfallmodells

keine Rücksprünge in frühere Phasen. Hierbei ist eine Phase zuerst vollständig abzuschließen, ehe der Übergang in die nächste Phase erfolgt. Man spricht in diesem Zusammenhang auch von Phasenmodellen (s. Abschn. 13.5). In der Praxis kommt es aber häufig vor, dass Fehler, geänderte Rahmenbedingungen oder neue Anforderungen einen Rücksprung in vorgelagerte Phasen erfordern. Daher sind im Laufe der Zeit Ansätze entstanden, die im Rahmen des Wasserfallmodells Rücksprünge in frühere Phasen erlauben, wobei allerdings der ursprüngliche Charakter eines einmaligen Phasendurchlaufs im Wesentlichen erhalten bleibt. Bei anderen, insbesondere in jüngerer Zeit an Bedeutung gewinnenden (agilen) Ansätzen sind zur Entwicklung eines stark vereinfachten Systems (sog. Prototyp) sämtliche Phasen schnell zu durchlaufen, um aufgrund der Realisierungserfahrungen diesen Prototyp sukzessiv zu verfeinern (s. Abschn. 13.5.2 und 13.5.3). Zusammengefasst sind die Inhalte der einzelnen Softwareentwicklungsphasen: • Die Projektdefinitionsphase (Vorphase) dient dazu, den Ist-Zustand des IS zu analysieren, wesentliche Anforderungen an die neue Software (bzw. Änderungswünsche) zu skizzieren und alternative Grobkonzepte zur Umsetzung dieser Anforderungen zu entwickeln sowie die Machbarkeit der Softwareentwicklung aus wirtschaftlichen, technischen, zeitlichen und organisatorischen Gesichtspunkten zu untersuchen. Bei den Aktivitäten zur Definitionsphase soll zum einen auf das Requirements Engineering in Abschn. 13.4 und

354

•

•

•

•

13  Phasenmodelle in der Softwareentwicklung

zum anderen auf die unterschiedlichen grafischen Modelle der Analyse in Abschn. 14.3 verwiesen werden. Die grafische Darstellung dieser Modelle erleichtert die Kommunikation zwischen Entwicklern, Fachabteilung und Management. Die technische Durchführbarkeit und Wirtschaftlichkeit von Alternativen werden bewertet und für die ausgewählte Alternative wird ein Projektplan (s. Abschn. 13.6.5) erstellt. Die Anforderungsanalyse dient dazu, aus den Arbeiten der Vorphase eine präzise, realisierungsunabhängige Beschreibung der zu entwickelnden Software abzuleiten. Auch hier sei nochmals auf Abschn. 13.4 zum Requirements Engineering und Abschn. 14.3 zu den Methoden in der Analyse verwiesen. Diese geht von einer „perfekten Technologie“ aus, sodass Realisierungsrestriktionen zunächst nicht zu beachten sind. Die Ergebnisse dieser Phase sind ein Anforderungskatalog bzw. ein daraus entwickeltes Lastenheft, die die Anforderungen an Abläufe und Leistungen des zu entwickelnden Systems aus fachlicher Sicht detailliert beschreiben. In der Entwurfsphase werden die Anforderungen auf eine informationstechnische Beschreibungsebene übertragen. Da dieser Schritt komplex sein kann, wird oft zwischen Grobentwurf (Festlegung der globalen Hardware- und Softwarearchitektur, der Kommunikationsdiagramme und logischen Grobschemata), Feinentwurf (Bildschirmlayouts, Programmentwürfe, detaillierte logische Schemata) und Testplanung unterschieden. Das Ergebnis dieser Phase wird oftmals IT-Konzept bezeichnet und enthält eine systematische Beschreibung der Daten- und Funktionssicht der zu entwickelnden Software sowie Informationen zu ihrer geplanten Einbettung in das übergeordnete IS aus dem Blickwinkel der Organisations- und Steuerungssicht. Ein IT-Konzept wird in der Implementierungsphase durch Datenstrukturen und Algorithmen in die Konstrukte der jeweiligen Hard- und Softwareumgebung umgesetzt. Die als Ergebnis dieser Phase realisierten Softwarekomponenten können in einer Testumgebung durch Formulierung von Testfällen und Durchführung modulspezifischer Tests überprüft werden. Eventuelle Fehler sind zu lokalisieren und zu beseitigen. Für die Implementierung existieren zwei grundlegende Strategien (s. Abschn. 13.2): Entweder werden erst übergeordnete Komponenten realisiert, um diese dann schrittweise durch Realisierung detaillierter Module zu ergänzen (Top-down-Strategie). Alternativ können erst detaillierte Module realisiert werden, um diese dann inkrementell in übergeordnete Komponenten zu integrieren (Bottom-up-Strategie). Die während des Komponententests isoliert voneinander betrachteten Softwarekomponenten werden in der Integrations- und Testphase zunächst zusammengefügt und einem sog. Systemtest (Integrationstest) unterzogen. Gleichzeitig oder danach erfolgt eine Portierung der Software in die Produktionsumgebung (Installation). Die entwickelte Software muss mit vor- und nachgelagerten Anwendungen integriert und die Verarbeitung operativer Datenbestände getestet werden. Als Ergebnis dieser Phase wird die in

13.3 Softwareentwicklungszyklus

355

der Produktionsumgebung getestete Software abgenommen und in die Betriebsphase überführt. • Während der Betriebsphase einer Software können zwei Arten von Softwareentwicklungsaktivitäten erfolgen: –– Entwicklungstätigkeiten aufgrund geänderter oder zusätzlicher funktionaler Anforderungen oder zur Beseitigung von Leistungsmängeln stellen Aktualisierungen oder Erweiterungen dar. –– Entwicklungstätigkeiten zur Korrektur von Entwurfs- oder Implementierungsfehlern werden als Wartung bezeichnet. Während aller Phasen der Softwareentwicklung, sowohl bei Individualentwicklung wie auch bei der Einführung von Standardsoftware, sollte eine permanente Dokumentation erfolgen (z. B. in Form von Modellen der Strategie- und Prozessebene, Machbarkeitsstudien, Anforderungskataloge, IT-Konzept, Implementierungsdokumentation und Testbeschreibungen). Neben Entwicklungsdokumenten im engeren Sinne sind auch nutzerorientierte Benutzungs-, Installations- und Softwarehandbücher zu erstellen. Für die Beurteilung der Ergebnisse einer Softwareentwicklung besitzen die Verifikation und die Validation im Qualitätsmanagement eine besondere Bedeutung. cc Verifikation  Die Verifikation einer Systemkomponente (z. B. eines Softwareprodukts) bezeichnet die Überprüfung der Übereinstimmung zwischen der Systemkomponente und ihrer Spezifikation. Die hierfür typische Fragestellung lautet: „Entspricht die Softwarekomponente den bei der Entwicklung zugrunde gelegten Anforderungen?“ cc Validation  Die Validation einer Systemkomponente (z.  B. eines Softwareprodukts) bezeichnet die Überprüfung der Eignung bzw. des Wertes einer Systemkomponente bezogen auf ihren Einsatzzweck. Die hierfür typische Fragestellung lautet: „Ist eine Softwarekomponente so gestaltet, so dass sie im operativen Betrieb die Handlungen/Aufgabenbearbeitungen der geplanten Softwarenutzer möglichst umfassend und effizient unterstützt?“. Die Fähigkeit eines Unternehmens, den Softwareentwicklungsprozess zu durchlaufen und dabei möglichst qualitativ hochwertige und valide Softwareprodukte zu erzeugen, lässt sich auf der Basis von Reifegradmodellen bewerten. Das ursprünglich vom SEI (Software Engineering Institute, USA) entwickelte, und in unterschiedlichen Anwendungsgebieten einsetzbare Capability Maturity Model Integration (CMMI) beinhaltet fünf Reifegradlevel (s. Abb. 13.5), um die Qualität von Prozessen (z. B. von einem Softwareentwicklungsprozess) zu bewerten. Prinzipiell existieren Reifegradmodelle für unterschiedliche G ­ ebiete

356

13  Phasenmodelle in der Softwareentwicklung

5 - Optimierend 4 - Geführt auf der Basis quantitativer Leistungsdaten 3 - Wohldefiniert und dokumentiert 2 - Geführt (Managed)

1 - Initial

Abb. 13.5  Reifegradstufen gemäß CMMI

(z. B. Produktentwicklung, Projektmanagement). Für den Bereich der Softwareentwicklung sind Anforderungen an ein Prozessmodell in der Norm ISO/IEC 15504 (SPICE) aufgeführt. Die Reifegradstufen für die Softwareentwicklung (IEEE 2013) sind wie folgt ­beschrieben: • Reifegradstufe 1. Der Softwareentwicklungsprozess wird spontan auf einer informellen Basis durchlaufen. • Reifegradstufe 2. Die Prozesse werden so durchlaufen, dass es dem Management möglich ist, Zwischenergebnisse zu erkennen und Steuerungsmaßnahmen in den einzelnen Prozessen anzustoßen. • Reifegradstufe 3. Die Entwicklungsprozesse sind im Unternehmen definiert und können für unterschiedliche Softwareentwicklungen wiederholt werden. Sie bieten damit prinzipiell Ansatzpunkte für organisationsweite Verbesserungen und ermöglichen es, Leistungsdaten über die Prozesse zu erfassen. • Reifegradstufe 4. Es werden Leistungsdaten über die Prozesse erfasst und zur Prozessbewertung genutzt. • Reifegradstufe 5. Das Unternehmen hat Mechanismen zur kontinuierlichen Prozessverbesserung eingeführt. Softwareentwickelnde Unternehmen sollten ihre Prozessfähigkeit gemäß diesem Reifegradmodell bewerten, um Problembereiche sowie Verbesserungspotenziale zu erkennen und dementsprechend Verbesserungsmaßnahmen durchzuführen. Aufgrund ihrer besonderen Relevanz im Rahmen der Softwareentwicklung vertieft der nachfolgende Abschnitt die Phase der Anforderungsanalyse.

13.4  Requirements Engineering in der Softwareentwicklung

357

13.4 Requirements Engineering in der Softwareentwicklung Die Anforderungsanalyse (Requirements Analysis) stellt in der Informatik eine wichtige Aktivität im Rahmen des Softwareentwicklungsprozesses dar. Sie dient hier zur Ermittlung von Zielstellungen und davon abgeleiteten Anforderungen eines Auftraggebers sowie der Stakeholder und späteren Nutzer bezüglich der zu entwickelnden Software. Der Ausgangspunkt bei der Entwicklung und Gestaltung sowohl von Software als auch von betrieblichen Systemen/Unternehmen ist die Identifikation relevanter und damit anforderungsstiftender Stakeholder. cc Stakeholder  Als Stakeholder bezeichnet man einzelne Personen oder Personengruppen, die das Erreichen der Ziele oder der Aktivitäten einer Organisation beeinflussen können (Freeman 1984). Jeder Stakeholder hat aufgrund seiner spezifischen Beziehung eine individuelle Sicht auf eine Anwendung und dementsprechend andere Zielstellungen und Erwartungen sowie davon abgeleitete Anforderungen an dessen Leistungen. Abb.  13.6 vermittelt einen Überblick über Stakeholdergruppen, die in der Regel unterschiedlich große Einflussmöglichkeiten auf einen Untersuchungsgegenstand (z. B. auf die Gestaltung einer Anwendung) haben. Um dies darzustellen unterscheidet Abb. 13.6 zwischen primären Stakeholdern als den wesentlichen Einflussgruppen und den nachgelagerten sekundären Stakeholdern. Um ein umfassenderes Bild von den Stakeholdern zu erlangen und darauf aufbauend deren Einbeziehung in die Gestaltung betrieblicher Anwendungen bzw. Systeme besser planen zu können ist es häufig sinnvoll, diese erste grobe Kategorisierung der Stakeholder mit weiteren Beschreibungsdimensionen zu erweitern. Zu diesen Beschreibungsdimensionen zählen z. B.: • • • • •

Grad der Einflussmöglichkeit auf die Unternehmenssituation, Grad der Einflussmöglichkeit auf andere Stakeholder (z. B. Meinungsführer), Rolle im Projekt (z. B. Berater), Einstellung zum Projekt (z. B. Gegner, Befürworter), Stärken/Schwächen (z.  B. bezüglich der Fähigkeiten zur Bedienung von Software), und • verfügbare Ressourcenkapazitäten. Zur Visualisierung der stakeholderspezifischen Ausprägungen der Beschreibungsdimensionen können grafische Stakeholdermodelle zur Anwendung kommen. Abb. 13.7 zeigt im Rahmen des Uhren-Beispiels die Bewertung der externen Lieferanten hinsichtlich deren Ausgangslage zur Interaktion mit den Anwendungen des Uhrenherstellers in Form eines Netzdiagramms. Für die Beschreibungsdimensionen (z. B. „Technisches Know-how der

358

13  Phasenmodelle in der Softwareentwicklung Primäre Stakeholder Regierung / Behörden

Communities

Medien Investoren

Endkonsumenten

Unternehmen

Wettbewerber Mitarbeiter

Lieferanten Interessenvertreter

Verbraucherschützer Sekundäre Stakeholder

Abb. 13.6  Stakeholdergruppen (Freeman et al. 2007)

Softwarenutzer“) sind hier zu jedem Lieferanten die spezifischen Werte auf einer Skala von 1 (gering) bis 5 (hoch) dargestellt. Die Einordnung von Stakeholdern in solche Beschreibungsdimensionen bzw. Stakeholdermodelle bezieht sich immer auf einen konkreten Untersuchungsgegenstand zu einem konkreten Zeitpunkt. Daher sind diese Stakeholderbewertungen innerhalb des Projektzeitraums in gewissen Abständen zu aktualisieren. Stakeholder sollten eine klare Vorstellung von ihren Erwartungen haben und ihre Ziele eindeutig und bestenfalls auch messbar (s. Abschn. 7.4) formulieren können. Ziele lassen sich im Hinblick auf verschiedene Dimensionen näher beschreiben (Gernert und Ahrend 2000): • • • •

Reichweite der Ziele, Bedeutung (Haupt- oder Nebenziele), Zeithorizont (lang-, mittel- oder kurzfristige Ziele), Inhalt (unterschieden nach dem Bereich des Unternehmens (z. B. Marketingziele) oder der Branche), • Messbarkeit (quantitativ oder qualitativ), sowie • Verantwortungsbereich.

13.4  Requirements Engineering in der Softwareentwicklung

359

Abb. 13.7  Beschreibung von Stakeholdergruppen mit Hilfe eines Netzdiagramms im Rahmen des Uhren-Beispiels

Die von den Zielstellungen abgeleiteten Anforderungen sind für alle an der Softwareentwicklung beteiligten Personen eine Grundlage der Kommunikation und Diskussion des Leistungsumfangs einer zukünftigen Software. cc Anforderung  Eine Anforderung ist eine Aussage über eine Eigenschaft oder Leistung eines Produkts, eines Prozesses oder der am Prozess beteiligten Personen (Rupp 2015). Anforderungen können sich auf unterschiedliche Aspekte eines betrieblichen Systems beziehen. Auf der Strategieebene betrifft dies z. B. die Leistungsanforderungen der Kunden (s. Abschn.  7.2) sowie die geschäftlichen Zielstellungen der Geschäftsleitung. Auf der Ebene der Organisation sind dies beispielsweise Vorgaben für die konkrete Gestaltung von Interaktionsprozessen mit Partnern und Kunden im Wertschöpfungsnetzwerk sowie Prozessanforderungen der eigenen Mitarbeiter. Auf Softwareebene können sich Anforderungen etwa auf die Etablierung technischer Datenschnittstellen gegenüber Partnern (z. B. im Rahmen von Electronic Data Interchange, EDI), auf die technische Umsetzung von Kundenschnittstellen (z. B. mit Hilfe von Kundenportalen) sowie auf die funktionale Gestaltung von Software beziehen.

360

13  Phasenmodelle in der Softwareentwicklung

Bei der Erhebung von Anforderungen im Rahmen der Anwendungsentwicklung ist auf eine klare Abgrenzung der zu gestaltenden Anwendung zu achten (z. B. durch die Angabe von zu unterstützenden Softwarefunktionsbereichen oder (Teil-)Prozessen), da sonst der Entwicklungsaufwand nicht realistisch geschätzt werden kann. Zudem verstärken Grauzonen in der Abgrenzung der Anwendung (und des damit zu unterstützenden IS) die Gefahr von nachträglichen Forderungen mit all den damit verbundenen Problemen (s.  Abschn.  13.6.10). Im Rahmen der Lasten- und auch der Pflichtenhefterstellung (s. Abschn. 13.4.2) ist zur Vermeidung von Grauzonen die Erstellung von Negativ-Listen hilfreich. Dort wird ausdrücklich festgeschrieben, was nicht zum betrachteten IS gehört und damit auch nicht bei der Erstellung der Software zu berücksichtigen ist. Weiterhin ist aus der Sicht des Projektmanagements auch zwischen dem Umfang der Software und dem Umfang des (Gesamt-)Projekts zu unterscheiden. Anforderungen an eine Software lassen sich nach zwei zentralen Kriterien klassifizieren (Partsch 2010): • Funktionale Anforderungen adressieren die funktionalen Verhaltensweisen und Strukturen einer Software inklusive der relevanten Systemzustände. Zusätzlich umfassen sie auch die Inputs (z. B. Daten, manuelle Eingaben, Ereignisse) sowie die sich aus dem funktionalen Verhalten der Software ergebenden Outputs (z. B. Daten, Reaktionen des Systems). • Nichtfunktionale Anforderungen beziehen sich auf die Qualitätsattribute der gewünschten Funktionen (z. B. Zuverlässigkeit, Ressourcenauslastung Nutzerfreundlichkeit), die Anforderungen an die Gesamtanwendung (z. B. Notfallmaßnahmen, Mitarbeiterqualifikationen), die Vorgaben für die Softwareerstellung (z.  B.  Projektorganisation, verwendete Hilfsmittel) sowie Anforderungen an die Prüfung, Einführung und den Betrieb der Software. Darüber hinaus existieren weitere Klassifikationskriterien, die beispielhaft in Abb. 13.8 mit entsprechenden Kriterienausprägungen dargestellt sind. Diese Zusammenstellung zeigt, welche Anforderungsaspekte bei der Systementwicklung eine Rolle spielen können. Welche Anforderungskategorien in einem spezifischen Projekt Berücksichtigung finden sollen, ist je nach Anwendungskontext zu entscheiden. Die Anforderungsanalyse als Untersuchung einzelner Anforderungen und ihres Zusammenwirkens ist eine Kernaktivität im Rahmen des Requirements Engineering (RE) (s. Abb. 13.9). Die Zielstellung des RE liegt in der strukturierten und systematisch betriebenen Zusammenstellung relevanter Anforderungen in Form von Anforderungskatalogen als Basis für die nachfolgende Softwareentwicklung. Die Erhebung und Analyse der Anforderungen an ein IS stellt einen besonders problematischen Teil in der Softwareentwicklung dar, denn Fehler oder Probleme in dieser frühen Phase der Entwicklung pflanzen sich häufig fort und sorgen dann für hohe Kosten in den späteren Phasen eines Projekts bzw. in der Betriebsphase einer Software. Notwendig ist hier eine enge Zusammenarbeit und ein intensiver Dialog zwischen dem systemnutzenden Fachbereich im Unternehmen (Auftraggeber) und den Softwareentwicklern

13.4  Requirements Engineering in der Softwareentwicklung

Typ

361

Funktional

Nichtfunktional

Einschränkung (der Lösung)

Inhalt

Nutzungsanforderung

Leistungsanforderung

Funktionalität

Scope

Geschäftsanforderung

Benutzeranforderung

Technische Anforderung

Detaillierungsgrad

Systemanforderung

Subsystemanforderung

Softwareanforderung

Bezugs-Objekttyp

Produktanforderungen

Prozessanforderungen

Form Formalität Quelle

Schablone

Text

Informell Nutzer

Reife Verbindlichkeit Priorisierung

Grafik

Modell

Semiformal Kunde

Vertrieb

Formal

Lieferant

Abgestimmt

Initial Wunsch

Tabelle

Feste Absicht

Wichtig, dringend

Domain Requirements

Vorschlag

Verabschiedet Kommentar

Wichtig, nicht dringend

Zurückgewiesen

Pflicht

Nicht wichtig, nicht dringend

Abb. 13.8  Klassifikationskriterien für Anforderungen (Partsch 2010)

Ziele des IS / IS-Abgrenzung

Liste der Stakeholder

Anforderungsermittlung

Anforderungsanalyse und -abstimmung

Anforderungsspezifikation und -dokumentation

Anforderungsvalidierung

Anforderungskatalog (z. B. Lastenheft, Pflichtenheft)

Abb. 13.9  Vorgehen im Requirements Engineering

Sonstige Informationsquellen

362

13  Phasenmodelle in der Softwareentwicklung

(Auftragnehmer). Dabei bedarf es eines Entgegenkommens auf beiden Seiten, da der Fachbereich in den seltensten Fällen die Fachbegriffe der Softwareentwickler kennt, und umgekehrt der Softwareentwickler meist nicht über tiefgreifende Kenntnisse im Fachgebiet des Fachbereichs verfügt. Somit ist eine Art „Übersetzungsprozess“ zwischen der Sprache des Fachbereichs und der des Entwicklers notwendig, der im Dialog möglichst iterativ stattfindet. Zusätzlich zu den RE-Aktivitäten umfasst das Anforderungsmanagement (Requirements Management) flankierende und unterstützende Tätigkeiten. Dazu zählen das Planen und Koordinieren von RE-Aktivitäten, das kontinuierliche Beobachten von Veränderungen im IS-Kontext und das sich daraus ergebende Anpassen der Anforderungsspezifikationen sowie die Verwaltung und Ablage der Anforderungsdokumente und der weiteren Anforderungsartefakte (Rupp 2015; Pohl 2010). Das Anforderungsmanagement ist somit nicht mit der Analyse der Anforderungen beendet, sondern erstreckt sich über den gesamten Softwareentwicklungsprozess. Hierbei sind folgende Punkte zu berücksichtigen: • Änderungen. Auch bei der Änderung von Anforderungen sind diese zwischen den Stake­holdern abzustimmen und auf Konsistenz zu prüfen. • Kommunikation. Da an der Entwicklung einer Software verschiedene Akteure beteiligt sind, müssen alle Beteiligten immer auf dem aktuellen Stand der Anforderungen gehalten werden. • Verfügbarkeit. Bei der Bereitstellung anforderungsrelevanter Inhalte ist zu berücksichtigen, dass Projekte zumeist räumlich und organisatorisch verteilt stattfinden. • Komplexität. Mit Anforderungen sind im Laufe der Entwicklung eine Vielzahl von Informationen (Historie der Anforderung, zugehörige Dokumente, abhängige Anforderungen, usw.) verbunden, die in der Ablage nachvollziehbar zueinander in Beziehung gesetzt werden müssen.

13.4.1 Vorgehen beim Requirements Engineering Die in Abb. 13.9 überblicksartig aufgeführten Kernaktivitäten des RE umfassen vier Bereiche (Pohl 2010): (1) Das Ermitteln von Anforderungen dient der Erfassung der Ansprüche aller relevanten Stakeholder an ein IS unter Verwendung verschiedener Informationserhebungstechniken. Neben einer direkten Befragung der Stakeholder können weitere Informationsquellen (z.  B.  Organisationshandbücher, Dokumentationen und Berichte des Alt-­ Systems) herangezogen werden. Bei der Anforderungsermittlung im Rahmen der IS-Entwicklung sind verschiedene inhaltliche Aspekte des Anwendungskontextes einzubeziehen. Diese Informationen umfassen Aspekte aus allen drei Ebenen des Business Engineering (s. Abschn.  6.2). Das bedeutet, dass neben den zentralen IS-­ spezifischen Inhalten (z. B. übergeordnete Anwendungsarchitektur im Unternehmen;

13.4  Requirements Engineering in der Softwareentwicklung

363

Informationsbedarfe und Darstellungsanforderungen der späteren Nutzer, Verfügbarkeit von Softwarefunktionen, Gestaltung von Datenschnittstellen) auch Inhalte aus dem Bereich der Organisation (Einbindung von Software in Prozessabläufe, Nutzergruppen und ihre Zugriffsberechtigungen auf das geplante Softwaresystem auf Basis ihrer aufbauorganisatorischen Einordnung) sowie auch aus dem strategischen Bereich (z. B. in der Zukunft geplante Einrichtung neuer Vertriebswege oder technische Anbindung weiterer Marktpartner an die eigene Anwendungs-Infrastruktur) bei der Anforderungsermittlung zu berücksichtigen sind. Für die Ermittlung der Anforderungen lässt sich keine allgemeingültige Technik festlegen. Die Wahl des Vorgehens hängt stark vom Projekt sowie von den Mitarbeitern und deren Erfahrungen mit der jeweiligen Technik ab. Bei der Auswahl der Technik für die Anforderungsermittlung sind zum einen menschliche Aspekte wie Kommunikationsfähigkeit, Abstraktionsvermögen und Motivation der betroffenen Mitarbeiter sowie der Einfluss der Gruppendynamik zu beachten. Des Weiteren spielen die organisatorischen Randbedingungen (Verfügbarkeit und Anzahl der Stakeholder, verfügbares Budget, kontinuierliche (CI) oder radikale (Redesign) Transformation (s. Abschn. 6.1)) und der fachliche Inhalt (Systemumfang und -komplexität, Beobachtbarkeit des Systemverhaltens, funktionale vs. nichtfunktionale Anforderungen) eine wichtige Rolle (Rupp 2015). Für die Ermittlung von Anforderungen gibt es einerseits analytische Methoden, wie z. B. die direkte Beobachtung, der Dokumenten-Review, das Interview (vorbereitete Fragen werden an die Stakeholder gestellt und deren Antworten protokolliert), die schriftliche Befragung (selbstständige Beantwortung eines Fragebogens) oder Workshops (kooperative Analyse oder Ausarbeitung eines Sachverhalts mit einer begrenzten Gruppe von Stakeholdern). Daneben existieren explorative Methoden, wie z. B. das explorative Prototyping (s. Abschn. 13.5.2). Für detailliertere Informationen zu den genannten Methoden und zu weiteren Techniken, wie z.  B.  Mindmapping, Formularverfolgung, Snowcards, CRC-Karten und Essenzbildung sei auf weiterführende Literatur verwiesen (z. B. (Rupp 2015)). ( 2) Das Analysieren von Anforderungen bezieht sich auf die Konsolidierung, gegenseitige Abgrenzung und Klassifizierung von Anforderungen zur Erreichung überdeckungs- und konfliktfreier Anforderungsinhalte und als Vorbereitung für die Anforderungspriorisierung. Hierbei sind kausale Abhängigkeiten zwischen den Anforderungen, die jeweils subjektiv eingefärbte Sicht von verschiedenen Stakeholdern auf bestimmte Anforderungssachverhalte und der Grad der Kritikalität einzelner Anforderungen hinsichtlich der Auswirkungen bei Nichteinhaltung (z. B. Gefahr für große Vermögenswerte, s. (Cockburn 2002)) zu beachten. In diesem Zusammenhang ist auch die Relevanz der Anforderungen für die einzelnen Stakeholdergruppen (z. B. Unterscheidung in Pflichtanforderungen, Wünsche, Vorschläge) zu ermitteln. Die z. B. mit Hilfe von Klassifikationsansätzen (s. Abb.  13.8) strukturierten Anforderungen sind zwischen den Stakeholdern und Softwareentwicklern abzustimmen. Diese Abstimmung kann sich gegebenenfalls zu einem iterativen Prozess entwickeln, der zur Verfeinerung der Anforderungen führt.

364

13  Phasenmodelle in der Softwareentwicklung

(3) Das Spezifizieren von Anforderungen fokussiert auf das Abbilden und Dokumentieren von vollständigen, konsistenten und eindeutigen Anforderungen in einer standardisierten Form. Die hierfür zum Einsatz kommenden Ansätze sollten verständliche und gut lesbare Anforderungsspezifikationen erzeugen und es erlauben, Anforderungen systematisch zu klassifizieren, notwendige von wünschenswerten Anforderungen zu trennen und die Abhängigkeiten zwischen Anforderungen zu beschreiben. Hierfür existieren zum einen natürlichsprachliche Ansätze, die aufgrund der Verwendung von einfach und realisierungsunabhängig gestalteten Beschreibungstexten sowohl für Softwareentwickler als auch Stakeholder leicht anwendbar sind, und deshalb häufig die erste Stufe der Anforderungsdokumentation darstellen. Darauf aufbauend können grafisch orientierte Modellierungstechniken (z.  B.  Prozessmodelle (s. Abschn.  8.3) oder UML-Diagramme (s. Abschn. 9.4)) bei der weiteren Verfeinerung und Präzisierung der dokumentierten Anforderungen zum Einsatz kommen, die häufig besser als bloße textuelle Anforderungsbeschreibungen eine Brücke zur (technischen) Konzeption und Implementierung der geplanten Software schlagen. Unabhängig von der ­verwendeten Technik sollten die dokumentierten Anforderungen gewissen Qualitätskriterien (z. B. Vollständigkeit, Eindeutigkeit, Verständlichkeit; (Rupp 2015)) genügen. Am Ende dieses Schrittes stehen die dokumentierten und zusammengefassten Anforderungen in einem als Anforderungskatalog bezeichneten Dokument/Dokumentenbündel zur Verfügung. (4) Beim Validieren von Anforderungen werden noch einmal die Inhalte der dokumentierten Anforderungsspezifikationen mit den tatsächlichen Erwartungen der Stakeholder abgeglichen und Probleme (z. B. bezüglich Vollständigkeit, Detailgrad und Konsistenz) behoben. Gleichzeitig ist zu bewerten, ob eine nach diesen Anforderungen entwickelte Software von den zukünftigen Nutzern akzeptiert werden würde und mit vertretbarem Aufwand umsetzbar ist. Ein Ergebnis der abschließenden Validierung kann darin bestehen, die Anforderungsanalyse mit modifizierter Abgrenzung des IS oder unter Nutzung zusätzlicher Informationsquellen zu wiederholen. Der fertige Anforderungskatalog ist eine wesentliche inhaltliche Basis für die im weiteren Projektverlauf anstehende Erstellung des Lasten- und des Pflichtenheftes.

13.4.2 Lastenheft und Pflichtenheft Im Rahmen der Softwareentwicklung hat die systematische Erfassung und Dokumentation der Anforderungen in Form eines Lastenheftes eine längere Tradition. Das Lastenheft (teils auch Kundenspezifikation genannt) wird von einem Auftraggeber (z. B. dem späteren Softwareverantwortlichen oder -nutzer) erarbeitet und hat nach DIN 69901-5 die Gesamtheit der Anforderungen an die Lieferungen und Leistungen eines externen oder internen Auftragnehmers/Softwareentwicklers zum Inhalt. Ein Lastenheft dient damit u.  a. auch zur Einholung von Angeboten von potenziellen Auftragnehmern. Im Lastenheft sind folgende Angaben zu berücksichtigen:

13.5 Vorgehensmodelle

• • • • • • •

365

Ausgangssituation und Zielsetzung, Überblick über das zu gestaltende IS-System sowie über die Teilsysteme (IS-Archi­tektur), funktionale und nichtfunktionale Anforderungen, Anforderungen an den Auftragnehmer (z. B. Zertifizierungen), Anforderungen an das Projekt- und Qualitätsmanagement des Auftragnehmers, Rahmenbedingungen für die Softwaregestaltung, und Abnahmekriterien.

Das Pflichtenheft (teils auch Fachfeinkonzept, Sollkonzept oder Implementierungsspezifikation genannt) ist nach DIN 69901-5 die Beschreibung der vom Auftragnehmer auf Basis eines Lastenheftes erarbeiteten Vorgaben für die Softwareumsetzung. Ein Pflichtenheft wird in der Regel als Teil eines Angebots vom Auftragnehmer erstellt. Das Pflichtenheft enthält eine Zusammenfassung aller fachlichen Anforderungen, die die zu e­ ntwickelnde Software aus der Sicht des Auftragnehmers erfüllen muss. Dabei geht es um den Funktions-, Leistungs- und Qualitätsumfang der geplanten Software. Das Pflichtenheft muss so abgefasst sein, dass es als Basis eines juristischen Vertrages dienen kann. Das Pflichtenheft geht mit seinen umsetzungs- und sollkonzeptbezogenen Inhalten bereits über den Umfang eines reinen Anforderungskatalogs/Lastenheftes als Basis für die IS-­Gestaltung hinaus.

13.5 Vorgehensmodelle Das hier skizzierte Requirements Engineering liefert die fachlich-inhaltliche Basis für die Konstruktion von Software. Etablierte Vorgehensmodelle stehen im Mittelpunkt dieses Abschnitts.

13.5.1 Phasenmodelle am Beispiel des V-Modells Das lineare Phasenmodell sieht vor, alle Phasen der Softwareentwicklung nur einmal zu durchlaufen, d.  h. zur nächsten Phase nur dann überzugehen, wenn die vorhergehende Phase vollständig und definitiv abgeschlossen wurde. Dazu sind die jeweiligen Phasenergebnisse ausführlich zu verifizieren bzw. zu validieren (s. Abschn. 13.3). Wegen seines linearen Verlaufs wird dieser Ansatz auch als Wasserfallmodell bezeichnet (s. Abb. 13.4). Es ist generell sinnvoll, den Entwicklungsprozess durch klare Anordnung der verschiedenen Tätigkeiten zu strukturieren, durch Standardisierung der Tätigkeiten und ­Dokumente eine Grundlage für die arbeitsteilige Entwicklung zu bilden und Meilensteine als Eckpfeiler der Projektplanung und -kontrolle zu schaffen. Allerdings ist der lineare, einmalige Durchlauf aller Phasen eher unwahrscheinlich, weil gerade in frühen, „unscharfen“ Phasen eine Überlappung von Tätigkeiten sinnvoll ist und Fehler nie ganz ausgeschlossen werden können. Der Zwang, die Anforderungsanalyse vor dem Entwurf völlig abzuschließen, stellt oft zu hohe Anforderungen an die Abstraktionsfähigkeit und Vorstellungskraft der Beteiligten.

366

13  Phasenmodelle in der Softwareentwicklung

Schließlich sehen Endbenutzer bei dieser Vorgehensweise erst sehr spät die entwickelte Software, so dass bei Akzeptanzproblemen oder Fehlern im Rahmen der Anforderungsdefinition umfangreiche und aufwändige Nachbesserungen durchzuführen sind. Im zyklischen oder auch iterativen Phasenmodell wird deshalb von vornherein vorgesehen, dass Validierungs- bzw. Verifikationsprobleme auch zum Rücksprung in bereits „abgeschlossene“, frühere Phasen der Softwareentwicklung führen können. Das iterative, inkrementelle Phasenmodell versucht, die Nachteile des linearen Modells zu umgehen, indem nur in der Projektdefinitionsphase die Software in seiner Gesamtheit betrachtet wird, und danach Teile der Software (Inkremente) gebildet und jeweils getrennt nach dem Phasenmodell weiterentwickelt werden. Die Entwicklung der Gesamtsoftware erfolgt dann komponentenweise. Beim iterativen und inkrementellen Phasenmodell wird die Software also in einer stufenweisen Vorgehensweise entwickelt. Die Entwicklung findet in Iterationen statt, d. h. die Stufen werden aufeinanderfolgend entwickelt. Jedes Inkrement ist inhaltlich weitgehend unabhängig von den anderen Inkrementen, so dass mit jeder Fertigstellung eines Inkrements bei der Lieferung eine lauffähige Software zur Verfügung steht. Ein Inkrement kann Gegenstand einer Iteration sein. cc Iteration  Eine Iteration bezeichnet eine einzelne Durchführung eines bestimmten vorgegebenen Vorgehens. Bezogen auf die Softwareerstellung bringt eine iterative Vorgehensweise periodisch wiederkehrende, ähnliche Aufgaben der Softwareentwicklung mit sich. Dem Vorteil der Komplexitätsbewältigung steht jedoch der Nachteil gegenüber, dass zwischen den Teilen der Software nicht immer (leicht trennbare) lose Kopplungen vorliegen, so dass sich die Softwareteile auseinander entwickeln können und später Probleme bei der Integration zur Gesamtsoftware entstehen. Abb. 13.10 zeigt ein iteratives und inkrementelles Phasenmodell, wie es in der betrieblichen Praxis der Softwareentwicklung weite Verbreitung gefunden hat. Das auf Boehm zurückgehende V-Modell ist im Wesentlichen ein Wasserfallmodell mit Rückkopplung, d. h. mit Integration einer ausdrücklichen Qualitätssicherung. Aktivitäten zur Verifikation und Validation sind feste Bestandteile des V-Modells (s. Testfälle und Anwendungsszenarien in Abb. 13.11). Das V-Modell 97 ist eine Weiterentwicklung des Böhmschen V-Modells und wurde im Auftrag der Bundesrepublik Deutschland entwickelt. In vielen öffentlichen Ausschreibungen in Deutschland ist die Anwendung des V-Modells Pflicht. Auch international ist das V-Modell verbreitet. In der Schweiz ist das mit dem V-Modell sehr eng verwandte Vorgehensmodell Hermes und die weiter entwickelte Version neoHermes im Einsatz. Das V-Modell XT ist die Weiterentwicklung des V-Modells 97 und wurde 2005 veröffentlicht (Weit e.V. 2006). Das V-Modell XT basiert auf aufeinander aufbauenden Vorgehensbausteinen, die die modularen Einheiten des V-Modells bilden. Es gibt einen Kern von verpflichtenden Vorgehensbausteinen, die das Projektmanagement, die Qualitätssicherung,

367

13.5 Vorgehensmodelle

Entwicklungszyklen

Anforderungsanalyse

Anforderungsanalyse

Anforderungsanalyse

Entwurf

Entwurf

Entwurf

Implementierung

Implementierung

Implementierung

Integration und Test

Integration und Test

Integration und Test

Projektdefinition

Betrieb, Wartung, Aktualisierung und Erweiterung

Abb. 13.10  Iteratives, inkrementelles Phasenmodell

Anforderungsdefinition

Anwendungsszenarien

Grobentwurf

Feinentwurf

Modulimplementierung

Testfälle

Testfälle

Testfälle

Abb. 13.11  V-Modell nach Boehm (Balzert 1996)

Abnahmetest

Systemtest

Integrationstest

Modultest

Validierung

Verifikation

368

13  Phasenmodelle in der Softwareentwicklung

das Konfigurationsmanagement und das Problem- und Änderungsmanagement betreffen. Hierdurch soll ein Mindestmaß an Projektdurchführungsqualität gewährleistet werden. Abhängig vom Projekttyp kann dieser Kern um weitere optionale Vorgehensbausteine ergänzt werden. Während das V-Modell 97 aus vier großen Submodellen besteht, basiert das V-Modell XT auf 18 erheblich feiner geschnittenen Vorgehensbausteinen. Durch diese kleineren Vorgehensbausteine ist es einfacher, das V-Modell XT an die jeweiligen Projektspezifika anzupassen. Diese Anpassung wird auch als Tailoring bezeichnet (XT = eXtreme Tailoring) und wurde bereits mit dem V-Modell 97 verfolgt. cc Tailoring  Tailoring bezeichnet die projektspezifische Anpassung eines Phasenmodells an die konkrete Projektaufgabe. Klassische Vorgehensmodelle wie die Nachfolger des Wasserfallmodells oder auch der Rational Unified Process (RUP) (s. Abschn. 14.2) erfordern eine umfangreiche Projektdokumentation. Daraus können folgende Probleme resultieren: • • • •

Die Anforderungen müssen vor Beginn der Entwicklung vollständig vorhanden sein. Der Auftraggeber hat Probleme, sämtliche Anforderungen konkret zu formulieren. Einige Wünsche der Anwender ergeben sich erst nach der ersten Nutzung. Von der Spezifikation der Anforderungen bis zum ersten Release der Software vergehen oft Monate oder Jahre.

Auch wenn nicht alle dieser Probleme immer eintreten, ist dennoch festzustellen, dass die klassischen Phasenmodelle nicht flexibel genug sind, um auf dynamisch ändernde Rahmenbedingungen zu reagieren. Daher bezeichnet man diese Phasenmodelle auch als schwergewichtig. Die Entwicklung sog. leichtgewichtiger Modelle soll bei diesen Problemen Abhilfe schaffen. Das Prototyping (s. Abschn. 13.5.2) und die agile Softwareentwicklung (hier speziell das Extreme Programming (XP) und Scrum) (s. Abschn. 13.5.3) verzichten auf umfangreiche Dokumentation und setzen auf einen frühzeitigen Beginn der Implementierung.

13.5.2 Prototyping Je früher ein Fehler in der Softwareentwicklung gemacht und je später er bemerkt wird, umso teurer ist seine Beseitigung. Da man auf der Grundlage von Phasenmodellen viele Fehler erst in der Testphase erkennt, kann die Fehlerbeseitigung sehr teuer werden. ­Prototyping dient dazu, durch „Simulation“ einer Software (z. B. der Benutzeroberfläche mit den wichtigsten Funktionen) schon in frühen Phasen der Softwareentwicklung Endbenutzer einzubeziehen und dadurch fehlende oder fehlerhafte Anforderungen zu erkennen.

13.5 Vorgehensmodelle

369

cc Prototyp  Ein Prototyp einer Software ist eine frühe ausführbare Version, die bereits die relevanten grundlegenden Merkmale des späteren Produkts aufweist. Prototyping bezeichnet die Vorgehensweise, Prototypen solange iterativ zu entwickeln, zu bewerten und zu verfeinern, bis das endgültige Produkt entstanden ist. Die Entwicklung eines Prototyps ist nur mit der Hilfe von Werkzeugen möglich, die eine Implementierung auch auf der Basis unvollständiger Spezifikationen erlauben. Meist handelt es sich dabei um sog. Anwendungsgeneratoren oder Werkzeuge für die Endbenutzerentwicklung (End User Development), wie z.  B.  Microsoft Excel, das über eine eigene Softwareentwicklungsumgebung verfügt. Mit konventionellen Programmiersprachen ist Prototyping nur eingeschränkt möglich, da versucht werden muss, einzelne Funktionen auch ohne vollständige Programmierung benutzbar erscheinen zu lassen. Bei der Einführung von Standardsoftware (s. Abschn. 10.4) kann Prototyping auf zwei Arten erfolgen: • Die Standardsoftware wird zunächst nur für einen bestimmten Geschäftsprozess eingeführt und solange getestet bzw. angepasst, bis sie den Anforderungen entspricht. Anschließend wird die Standardsoftware sukzessiv für weitere Geschäftsprozesse in gleicher Weise eingeführt. • Die Standardsoftware wird zwar für mehrere Geschäftsprozesse eingeführt, aber nur mit ausgewählten Daten getestet. Nachfolgend werden die Tests auf weitere Daten ausgedehnt und Anpassungen ausgeführt. Prototyping erschwert das Projektmanagement, da aufgrund der schnellen Verfügbarkeit eines Prototyps und seiner Änderungsfreundlichkeit die Plan- und Steuerbarkeit des Projekts erheblich vermindert wird. Deshalb muss bei den Anwendern und beim Management der Eindruck vermieden werden, dass zum einen Änderungswünsche beliebig oft und lange geäußert werden dürfen, und dass zum anderen mit dem ersten Prototyp das Projekt schon fast abgeschlossen ist. Daher ist das Prototyping durch Steuerungsmechanismen zu ergänzen, die unnötige Iterationen verhindern und den Projektfortschritt messbar (z.  B. durch Meilensteine) kontrollieren. Ein solcher Mechanismus kann z. B. darin bestehen, Prototypen in bestimmten Zyklen zu entwickeln. In jedem Prototyping-Zyklus sind: • Die abzubildenden Softwarebereiche, zu testenden Abläufe und erhofften Lerneffekte festzulegen und zu dokumentieren (Zielanalyse), • die Genauigkeit, mit der die einzelnen Funktionen im Prototyp realisiert werden sollen, festzulegen (Funktionsauswahl), • der Prototyp mit möglichst geringem Kosten- und Zeitaufwand (und unter Vernachlässigung bestimmter Qualitätsanforderungen) zu realisieren (Prototypentwicklung), sowie • der Prototyp zusammen mit Endanwendern zu bewerten und Modifikations-, Verbesserungs- und Verfeinerungsvorschläge zu dokumentieren (Prototypauswertung).

13  Phasenmodelle in der Softwareentwicklung

370

Anforderungsanalyse Anforderungen identifizieren

Prototypen entwickeln

O.K.

Prototypen evaluieren

Nicht O.K.

Anforderungen überarbeiten

Exploratives Prototyping

Entwurf

Implementierung

Integration und Test Betrieb, Wartung, Aktualisierung und Erweiterung Traditionelles Phasenmodell

Abb. 13.12  Exploratives Prototyping

Prototyping kann auf verschiedene Weise erfolgen: • Exploratives Prototyping. Sukzessive Klärung fachlicher Anforderungen durch wiederholte, schnelle Erzeugung (und Verwerfung) von Prototypen in einer Testumgebung. Das explorative Prototyping kann im Rahmen der Anforderungsanalyse in traditionelle Phasenmodelle eingebunden werden (s. Abb. 13.12). • Experimentelles Prototyping. Nachweis der Realisierbarkeit eines Entwurfs vor Einstieg in die Implementierungsphase eines traditionellen Phasenmodells. Auf diese Weise können technische Fragestellungen geklärt werden, die beispielsweise die Machbarkeit betreffen. • Evolutionäres Prototyping. Laufende Anpassung der sich in Entwicklung befindlichen Software an geänderte Anforderungen oder neue Erkenntnisse. Das evolutionäre Prototyping ist mit traditionellen Phasenmodellen unvereinbar. Ein wichtiger Vorteil des Prototyping besteht darin, Akzeptanzprobleme und Fehler in frühen Phasen der Softwareentwicklung zu erkennen und sie damit wirtschaftlicher zu beseitigen. Allerdings wird eine gewisse Abhängigkeit von Prototyping-Werkzeugen und ihren jeweiligen Möglichkeiten geschaffen. Darüber hinaus legt ein Prototyp sowohl beim Entwickler wie auch beim Benutzer schon früh die weitere Vorgehensweise fest. Schließlich erhöht die frühe Verfügbarkeit des Prototyps den Druck auf die Entwickler (Freigabe vor Produktionsreife, schlechte Wartbarkeit, keine ausreichende Qualitätssicherung) und es besteht die Gefahr, dass sich das Entwicklungsprojekt durch ständige Nachbesserungswünsche verzögert. Die Vorteile des Prototyping sind deshalb nur dann nachhaltig, wenn es durch ein geeignetes Vorgehensmodell und Projektmanagement ergänzt wird.

13.5 Vorgehensmodelle

371

13.5.3 Agile Softwareentwicklung Agile Softwareentwicklung beabsichtigt, dem Kunden schnell einsetzbare Software zu liefern, die inkrementell in engem Kontakt zu ihm ausgebaut wird. Grundprinzipien der agilen Softwareentwicklung sind (Beck et al. 2001), dass • • • •

Individuen und Interaktion über Prozesse und Werkzeuge gestellt werden, eine lauffähige Software über eine umfassende Dokumentation gestellt wird, die Zusammenarbeit mit Kunden über Vertragsverhandlungen gestellt wird, und die Reaktion auf Veränderung über die Befolgung eines Plans gestellt wird.

Auch wenn für (Beck et al. 2001) der jeweils rechte Teil der oberen vier Aussagen ebenfalls eine gewisse Relevanz besitzt, so bewerten sie den linken, kursiv gedruckten Teil höher.

13.5.3.1  Extreme Programming (XP) Eine besondere Form der agilen Softwareentwicklung ist das Extreme Programming (XP). Mehrere interessante Arbeitstechniken, von denen die eine oder andere so auch bei Projekten in den klassischen Phasenmodellen eingesetzt wird, sind in ihrer Gesamtheit charakteristisch für das Extreme Programming (Beck 2000). Die Arbeitstechniken umfassen: • Permanenter Test und Test vor Codierung, • Kunde vor Ort, d. h. der Anwender wird stark in die Systementwicklung mit einbezogen, • fortlaufende Integration der Entwicklungsergebnisse in das System, und • Programmierung in Paaren von Softwareentwicklern. Extreme Programming ist eher auf die Entwicklung kleinerer Software ausgelegt. Es geht von relativ kurzen Entwicklungszeiten aus und verfolgt ein inkrementelles Vorgehen. Nachteilig ist bei dieser Art der Softwareentwicklung die mangelhafte Projektkontrolle.

13.5.3.2  Scrum Scrum folgt wie das Extreme Programming den Prinzipien der agilen Softwareentwicklung. Hierbei macht Scrum noch weniger Vorgaben bezüglich Vorgehensweise, Dokumentation und Test, als es generell schon bei der agilen Softwareentwicklung vorgesehen ist. Als Richtlinie für das Entwicklungsteam gelten eine Anzahl von Rollen, eine spezielle Besprechungsphilosophie und bestimmte Entwicklungszyklen. Von seiner Entwicklungsphilosophie kann Scrum in gewisser Weise als eine Art „schlanker Softwareentwicklungsprozess“ (angelehnt an Lean Production) angesehen werden. Hierbei wird grundsätzlich angenommen, dass der Entwicklungsprozess für eine umfangreiche Software so komplex ist, dass er sich weder in großen abgeschlossenen Phasen planen lässt, noch dass den einzelnen Mitarbeitern vorab detaillierte Arbeitspakete mit Aufwandsschätzungen in Stunden und Tagen zugeordnet werden können. Daher wird dem gesamten Team die Aufgabe mit

13  Phasenmodelle in der Softwareentwicklung

372

Sprint Backlog

ProduktBacklog

Sprint 1. Sprint Planungstreffen

Sprint Planungstreffen

Daily Scrum Meeting

Lauffähige, inkrementell verbesserte Software

Sprint Review Meeting

Produkt (Software)

Abb. 13.13 Scrum-Entwicklungszyklus

abgestimmten Rahmenbedingungen übertragen und es obliegt dem Team, sich selbst zu organisieren. Hierbei wird die traditionelle Projektsteuerung (s. Abschn.  13.6) und ein übergeordnetes Management (z. B. in Form eines Lenkungsgremiums), das Einfluss auf die Zusammenarbeit im Team nimmt, abgelehnt. Scrum unterscheidet drei zentrale ­Rollen: • Product Owner. Er legt mit dem Team das Ziel und die Rahmenbedingungen der Projektaufgabe fest. Hierzu kann er beispielsweise User Stories (ähnlich Use Cases, s. Abschn. 14.3.1) verwenden. Er priorisiert regelmäßig die Funktionalitäten/Anforderungen im Produkt-Backlog (s. Abb. 13.13) und legt dadurch fest, welche Softwareteile am wichtigsten sind. Weiterhin bestimmt er Auslieferungsdatum und Inhalt. Er akzeptiert die Arbeitsergebnisse bzw. weist sie zurück. • Scrum Master. Er ist verantwortlich für die Einhaltung der Scrum-Philosophie und -Methoden. Er sollte Projekthindernisse entfernen und sicherstellen, dass das Team produktiv zusammenarbeiten kann. • Das Team besteht typischerweise aus fünf bis zehn Personen. Alle Teammitglieder sollten Vollzeitmitglieder sein. Das Team arbeitet selbst organisiert über eine Anzahl von Entwicklungszyklen (Sprints) und hat das Recht und die Pflicht, selbst zu entscheiden, wie viele Funktionen/Anforderungen nach dem nächsten Sprint gemäß Sprint Backlog erledigt sein müssen (s. Abb. 13.13). Zentrales Element des Entwicklungszyklus von Scrum ist der Sprint. Scrum-Projekte schreiten in Serien von Sprints voran. Die angestrebte Dauer eines Sprints beträgt ungefähr einen Monat. Hierbei führt eine konstante Dauer zu einem besseren Arbeitsrhythmus. Der Ausgangspunkt für die Zyklen sind die Anforderungen im Produkt-Backlog. Das Produkt-Backlog muss nicht von Beginn an vollständig sein, sondern es wird fortlaufend geführt. Die Anforderungen werden informell skizziert. Für einen Sprint wird ein Sprint Backlog erstellt. Die Software wird während des Sprints entworfen, kodiert und getestet. Im Sprint-Planungstreffen erläutert der Product Owner dem Team alle einzelnen Anforderungen des Produkt-Backlog, die gemäß der Priorisierung für den nächsten Sprint ­vorgesehen sind. Hierbei können diese Priorisierungen geändert werden, neue Anforderungen hinzukommen oder gestrichen werden. Weiterhin wird ein gemeinsames Ziel festgesetzt, das in Sprint Review Meetings die Basis für die Abnahme darstellt. An jedem Tag

13.5 Vorgehensmodelle

373

findet ein kurzes (maximal 15-minütiges) Daily Scrum Meeting statt. Das Team stellt sich gegenseitig die folgenden Fragen: • Welche Aufgaben wurden seit dem letzten Daily Scrum Meeting fertiggestellt? • Welche Aufgaben werden bis zum nächsten Daily Scrum Meeting bearbeitet? • Gibt es Probleme, die die nächsten Aufgaben behindern? Hierbei ist festzuhalten, dass diese Meetings nicht zur Problemlösung dienen. In den Sprint Review Meetings präsentiert das Team, was es während eines Sprints erreicht hat. Typischerweise erfolgt dies in Form einer Demonstration von neuen Funktionen oder der zugrunde liegenden Architektur. Zur Dokumentation sieht Scrum folgende Artefakte vor: • Alle Anforderungen sind als Listeneinträge im Produkt-Backlog festgehalten. Das Dokument umfasst alle vom Kunden geäußerten Anforderungen sowie technische Abhängigkeiten. Vor jedem Zyklus (Sprint) werden die Anforderungen des Produkt-Backlogs neu bewertet und priorisiert. Dabei können bestehende Anforderungen entfernt sowie neue Anforderungen hinzugefügt werden. Ein wesentliches Merkmal des Produkt-­Backlogs ist die Tiefe der Beschreibung von einzelnen Anforderungen. Hoch priorisierte Anforderungen werden im Gegensatz zu niedrig priorisierten Anforderungen detaillierter beschrieben. • Das Sprint Backlog enthält alle Aufgaben die notwendig sind, um das Ziel des Sprints zu erfüllen. Bei der Planung des Sprints werden nur so viele Aufgaben eingeplant, wie das Team mit seinen Kapazitäten bewältigen kann. Für die einzelnen Aufgaben werden verantwortliche Teammitglieder benannt.

13.5.3.3  KANBAN KANBAN (Japanisch: „Signalkarte“) ist ein leichtgewichtiges Vorgehensmodell, das viele Gemeinsamkeiten mit der agilen Softwareentwicklung nach Scrum hat. Angelehnt an die japanische „schlanke (lean)“ Produktion versucht KANBAN als Vorgehensmodell bei der Softwareentwicklung schnellere Durchlaufzeiten zu erreichen und Probleme früher sichtbar zu machen. Hierzu wird eine Anzahl von Regeln vorgegeben (Anderson 2011): • Visualisiere den Arbeitsfluss an einem KANBAN Board. Einzelne Arbeitsschritte/Anforderungen/Eigenschaften durchlaufen als Karteikarten (auch Tickets genannt) die unterschiedlichen Phasen wie Anforderungsdefinition oder Test, und sind daher allen Teammitgliedern transparent dargestellt. • Begrenze die Anzahl gleichzeitig bearbeiteter Aufgaben. Entsprechend dem angesprochenen KANBAN Board ist die Anzahl der gleichzeitig zu bearbeitenden Aufgaben bzw. Anforderungen an einer Station (Phase) zu begrenzen. Man spricht auch von einer reduzierten, parallelen Bearbeitung des WIP (Work in Progress). Hierbei wird das Pull-Prinzip verfolgt. Es werden die fertigen Ergebnisse nicht an die Nachfolgerstation einfach weitergeleitet, sondern müssen vom Nachfolger zur weiteren Bearbeitung abgeholt werden, wenn dessen Kapazität es zulässt.

374

13  Phasenmodelle in der Softwareentwicklung

• Messe und steuere den Arbeitsfluss. Zur Erleichterung der Planung und Steigerung der Verlässlichkeit werden unterschiedliche Kenngrößen wie Zykluszeit, Fehlerrate, Durchsatz und Warteschlangenlänge für die einzelnen Tickets bzw. Stationen erfasst, und falls notwendig die Arbeitsorganisation an einzelnen Stationen verbessert. • Erläutere die Regeln für den Prozess. Die Regeln der Bearbeitung werden allen Mitarbeitern transparent erläutert. Dies bezieht sich speziell auf die Annahmen und Gesetzmäßigkeiten des KANBAN-Prinzips, z.  B. Wann ist ein Ergebnis als „fertig“ zu bezeichnen? Wann darf welches Ticket gezogen werden? • Wende Methoden und Modelle an, um Verbesserungspotenzial in der Zusammenarbeit aufzudecken. Unterschiedliche Modelle (z.  B. auch aus der klassischen Produktion) sollen genutzt werden, um beispielsweise Engpässe zu erkennen und Verschwendung aufzuzeigen. Der kontinuierliche Verbesserungsprozess (KVP), auch als KAIZEN bekannt, stellt einen integralen Bestandteil des KANBAN in der Softwareentwicklung dar. Durch eine Begrenzung des WIP und Visualisierung des Arbeitsflusses an einem KANBAN Board kann relativ einfach erkannt werden, wie schnell Tickets die einzelnen Stationen durchlaufen und wo sich Arbeit (die Tickets) anstaut. Dementsprechend lassen sich Engpässe erkennen und Maßnahmen zur Nachsteuerung einleiten (z.  B. höherer Mitarbeitereinsatz an einer bestimmten Station).

13.5.3.4  Feature Driven Development (FDD) Auch beim Feature Driven Development (FDD) handelt es sich um ein agiles, leichtgewichtiges Phasenmodell. Hierbei steht der Begriff des Features (Anforderung oder auch Funktion/Eigenschaft) im Mittelpunkt. Ein Feature ist definiert als ein Merkmal der Software, das in den Augen des Kunden nützlich ist. Jedes Feature sollte für den Kunden einen Mehrwert darstellen. Die Größe eines Features wird durch die Bedingung eingeschränkt, dass ein Feature maximal in zwei Wochen entwickelt werden sollte. Andernfalls muss das Feature weiter unterteilt werden, bis die Vorgabe erfüllt wird. FDD hat die folgenden fünf Phasen, welche bezogen auf die Features wiederholt durchlaufen werden müssen: • Entwicklung Gesamtmodell. Das Gesamtmodell wird in Workshops vom gesamten Team erstellt. Hierbei wird der Umfang der zu entwickelnden Software festgelegt. Im Mittelpunkt des Modells stehen die Klassendiagramme (s. Abschn. 14.3.2) zu den fachlichen Anforderungen. Darüber hinaus werden Sequenzdiagramme eingesetzt, um das geplante Verhalten der Software besser zu verstehen. • Erstellung Feature-Liste. In dieser Phase wird die Feature-Liste erstellt. Das Feature ist das zentrale Element in FDD für die Beschreibung von Anforderungen. Abschließend werden die einzelnen Features eingeteilt und priorisiert. • Planung je Feature. Die Features werden gemeinsam vom Projektleiter, Entwicklungsleiter und dem Chefprogrammierer geplant. Hierzu wird analysiert, welche Klassen von welchem Feature betroffen sind und die dazugehörigen Klassenbesitzer werden

13.5 Vorgehensmodelle

375

festgelegt. Dabei wird auf die Auslastung der Programmierteams sowie die Komplexität der Features geachtet. • Entwurf je Feature. Der Chef-Programmierer analysiert das ihm zugeordnete Feature und stellt das Feature Team auf Basis der betroffenen Klassen zusammen. Die Feature Teams entwerfen die zugewiesenen Features eigenständig. Abschließend wird im Team ein Review des Entwurfs durchgeführt. • Konstruktion je Feature. Nach dem Entwurf der Features sind diese von den Entwicklern zu programmieren. Bei der Programmierung kommen Tests und Code-­Inspektionen zur Qualitätssicherung zum Einsatz. Die drei ersten Phasen werden in der Regel nur einmal durchlaufen. Die beiden letzten Phasen hingegen adressieren die Realisierung der Features und laufen zyklisch ab. Dieses Phasenmodell wird durch ein Rollenmodell (Projektleiter, Entwicklungsleiter, Chefprogrammierer, Entwickler) mit entsprechenden Verantwortlichkeiten ergänzt. FDD hat Ähnlichkeiten mit dem XP-Phasenmodell. Die Codierung wird beim FDD jedoch Einzelpersonen (Individual Code Ownership) und nicht wie bei XP Zweierteams zugeordnet.

13.5.4 DevOps Mit Aufkommen mobiler Anwendungen (Apps) hat die agile Softwareentwicklung eine verstärkte Aufmerksamkeit erfahren. Während bei der klassischen Entwicklung Releasezyklen von mehreren Monaten oder gar Jahren die Regel waren, so erwarten Anwender in der dynamischen „App Economy“ Entwicklungen und Aktualisierungen in erheblich kürzeren Zeiträumen. So erhalten Anwender bei den PC-Betriebssystemen MacOS und Windows 10 sowie den Smartphone-Betriebssystemen Android und IOS im Wochenrhythmus neue Softwareversionen zur Verfügung gestellt. Dies setzt neben einer effizienten Aktualisierungsinfrastruktur (z.  B. den App Store, den Google Play Store oder den Windows Store), welche Entwickler nutzen können, auch die Fähigkeit zur Bereitstellung neuer Software bzw. Versionen in kurzen Zeitabständen voraus. Das DevOps-Konzept setzt hier an, indem es eine Verbindung von Entwicklung (Development) und Betrieb (Operations) von Software vorsieht. Es versucht dabei die unterschiedlichen Zielsetzungen dieser beiden Bereiche abzustimmen (Alt et al. 2017): während die Entwicklung typischerweise in Projekten unter Zeitrestriktionen, in Abstimmung mit dem Kunden und häufig unter Nutzung innovativer Technologien stattfindet, zielt der laufende Betrieb auf eine hohe Stabilität der entwickelten Software und betrachtet jedes vorgesehene Update auch als eine potenzielle Gefährdung der Systemstabilität. Zudem sind zwischen beiden Bereichen häufig Defizite in der Zusammenarbeit anzutreffen, wenn die Entwicklungsabteilung ihr Projekt mit der Freigabe (Release) als abgeschlossen betrachtet und die Betriebsabteilung anschließend die Installation in der Produktivumgebung (Deployment) vornehmen soll. DevOps hat sich bislang als übergreifender Ansatz etabliert, der zur verbesserten Zusammenarbeit von Kunden, Entwicklung und Betrieb zahlreiche Techniken, Prozesse und Entwicklungswerkzeuge verbindet. Standardisierte Beschreibungen und Zertifizierungen,

376

13  Phasenmodelle in der Softwareentwicklung

Kunde/ Nutzer Nutzererlebnis Erwartungen

Nutzen IT-Produkt/ IT-Service Delivery Pipeline

Entwicklung (Dev)

Culture

Automation

Measurement

Sharing

Betrieb (Ops)

Integration

Abb. 13.14  DevOps im Überblick (Alt et al. 2017, S. 28)

wie etwa bei ITIL oder PRINCE2, sind jedoch bei DevOps noch nicht vorhanden. Als etabliert gelten vor allem die vier Grundprinzipien, die sich unter dem Akronym CAMS zusammenfassen lassen: • Culture. DevOps sieht eine Kultur der Zusammenarbeit zwischen den Beteiligten vor. Dies sind insbesondere die Kunden, die Entwicklerteams und die Betriebsabteilung. Alle Beteiligten sollen sich gemeinsam für eine hohe Qualität und Kundenzufriedenheit verantwortlich fühlen. Dies können auch Raumkonzepte (z. B. Innovation Labs) unterstützen. • Automation. DevOps versucht möglichst viele Routineaufgaben im Entwicklungs- und Betriebsprozess zu automatisieren, um dadurch Zeit- und Kostenvorteile zu nutzen. Ansätzen der kontinuierlichen Softwareauslieferung folgend, sieht DevOps eine Delivery Pipeline vor, die verschiedene Entwicklungs- und Betriebswerkzeuge (z. B. Jenkins, Puppet) miteinander verbindet. Der Kreislauf in Abb. 13.14 zeigt diese neben der agilen Entwicklung als „Continuous Integration & Testing“ sowie als „Continuous ­Delivery“. • Measurement. Der DevOps-Ansatz beinhaltet die Messung von definierten Führungsgrößen/Metriken zur Beurteilung der Kundenzufriedenheit und der Steigerung der Produktivität. Dazu zählen beispielsweise die Durchlaufzeit von Deployments, die Wiederanlaufzeit nach Fehlern oder die Fehlerrate von Deployments. • Sharing. Zur Verbesserung des Wissensmanagements zwischen allen Beteiligten sollen mit DevOps entsprechende Plattformen, Publikationen und Schulungsangebote entstehen. Auch regelmäßige Informationsveranstaltungen zur Darstellung der erreichten Erfolge zählen zu Maßnahmen in diesem Bereich.

13.5 Vorgehensmodelle

377

Mit dem Aufkommen digitaler Geschäftsmodelle (s. Abschn. 7.1 und 5.1) hat DevOps auch eine Bedeutung bei der Entwicklung innovativer Lösungen. So ist im Rahmen strategischer Entwurfsmethoden (wie etwa Design Thinking, s. Abschn. 6.1) die frühzeitige Entwicklung von Prototypen vorgesehen, welche den Nutzen der entwickelten Lösung demonstrieren bzw. validieren sollen. Häufig wird bei diesen ersten Versionen die Bezeichnung Minimum Viable Product (MVP) verwendet, da bereits kleine Nutzenverbesserungen zur schrittweisen und kontinuierlichen Weiterentwicklung der Innovation beitragen (s. Continuous Improvement in Abschn. 6.1) und dabei helfen, zeitnah Rückmeldungen der Nutzer zu erhalten.

13.5.5 Vorgehensmodelle zur Entwicklung sicherer Software Aufgrund der steigenden Bedeutung sicherer Software und Systeme (s. Kap.  1 und Abschn. 4.3) wurden in den letzten Jahren Phasenmodelle entwickelt, die spezifische Methoden für das Software Engineering sicherer Software beinhalten. Im Folgenden werden die drei wesentlichen Modelle (De Win et al. 2009) kurz vorgestellt.

13.5.5.1  CLASP Das Open Web Application Security Project (OWASP) ist eine Non-Profit-Organisation mit dem Ziel, die Sicherheit von Software zu verbessern. Das von der OWASP entwickelte leichtgewichtige Phasenmodell Comprehensive, Lightweight Application Security Process (CLASP) definiert einen Satz von 24 Aktivitäten, die spezifisch für das jeweilige Entwicklungsprojekt angepasst werden können (OWASP 2006). Wesentliche Charakteristika von CLASP sind: • Zentrale Rolle von Sicherheit in der Entwicklung. Basierend auf einer Vielzahl von Methoden in den unterschiedlichen Entwicklungsphasen wird die Entwicklung sicherer Software in den Mittelpunkt gestellt. • Wenige Vorgehensvorgaben. Die einzelnen Aktivitäten für die unterschiedlichen Phasen des Entwicklungsprozesses sind weitgehend unabhängig voneinander beschrieben. Die Auswahl und Reihenfolge der Aktivitäten ist abhängig vom jeweiligen Entwicklungsprojekt. Es sind zwei sog. Road Maps beschrieben, die Hinweise zur Auswahl und Reihenfolge der Aktivitäten geben sollen. • Rollendefinition. CLASP definiert Rollen (wie z. B. Architekt, Sicherheitsverantwortlicher, Projektmanager, Anforderungsanalytiker) und weist ihnen spezifische sicherheitsrelevante Aktivitäten zu. Die einzelnen Rollen sind verantwortlich für die Fertigstellung der Ergebnisse in den Aktivitäten (z. B. Erstellung der Misuse Cases und Abuse Cases in der Anforderungsanalyse) sowie deren Qualität. • Umfangreiche Checklisten und Beschreibungen. CLASP stellt eine Anzahl von Checklisten (z.  B.  Liste von bekannten Schwachstellen in Anwendungsprogrammen für Code Reviews) und Vorlagen zur Unterstützung der unterschiedlichen Aktivitäten zur Verfügung.

378

13  Phasenmodelle in der Softwareentwicklung

Weiterhin wird in CLASP wie auch bei SDL (s. nachfolgend) die Bedeutung von Schulungen und die Sensibilisierung zum Thema Softwaresicherheit hervorgehoben. Eine Weiterentwicklung von CLASP ist das Software Assurance Maturity Model (SAMM), auf dessen Basis sich der sicherheitsbezogene Reifegrad der Softwareentwicklungsaktivitäten eines Unternehmens messen, vergleichen und planen lässt (OWASP SAMM).

13.5.5.2  SDL Der Secure Development Lifecycle (SDL) von Microsoft umfasst ebenfalls einen Satz von Aktivitäten, die den klassischen Microsoft-Entwicklungszyklus ergänzen und spezifisch das Thema Sicherheit ansprechen. Das Vorgehensmodell kann wie folgt charakterisiert werden: • Sicherheit als unterstützendes Qualitätsmerkmal. SDL zielt als ergänzende Vorgehensweise auf die Erhöhung der Softwarequalität, wobei sicherheitsspezifische Entwicklungsaktivitäten gemeinsam mit funktionsorientierten Aktivitäten durchzuführen sind. • Klare Vorgehensweise. SDL beschreibt eindeutig, welche Methoden in den einzelnen Aktivitäten angewandt werden sollen. Beispielsweise ist die Bedrohungsanalyse als ein Satz von Prozessen dargestellt, deren einzelne Schritte ausgeführt werden müssen. • Unterstützende Managementsicht auf das Qualitätsmerkmal Sicherheit. SDL integriert das Management in die Aktivitäten und zeigt damit, dass es aufgrund der Komplexität des Themas Sicherheit notwendig ist, dieses Qualitätsmerkmal auch aus Managementsicht entsprechend zu behandeln. SDL hat seine besonderen Stärken in der Behandlung von Bedrohungen in der Entwurfsphase der Softwareentwicklung. Hier wird eine Anzahl von sicherheitsrelevanten Aktivitäten vorgeschrieben, die speziell diese Entwicklungsphase unterstützen (De Win et al. 2009).

13.5.5.3  Touchpoints Der Ansatz Touchpoints umfasst eine Anzahl von Best Practices (McGraw 2006). Die wesentlichen Elemente von Touchpoints sind: • Risikomanagement. In Touchpoints ist die Handhabung von Risiken durch entsprechende Aktivitäten im Vorgehensmodell integriert (s. zum prinzipiellen Vorgehen Abschn. 13.6.9 und Abschn. 4.3). • Black versus White. Touchpoints kombiniert Black-Hat- und White-Hat-Aktivitäten als Entwurfs-, Implementierungs- und Test-Aktivitäten in seinem Prozessmodell. Black-Hat-Aktivitäten umfassen beispielsweise Angriffe, das Ausnutzen von Sicherheitslücken durch spezifische Software sowie umfangreiche Sicherheitstests (Penetrationstests). White-Hat-Aktivitäten sind überwiegend konstruktiver Natur und beinhalten beispielsweise auch Code Reviews. • Hohe Flexibilität. Auch Touchpoints wird spezifisch an das jeweilige Entwicklungsprojekt angepasst. Dies wird durch eine Priorisierung von durchzuführenden Aktivitäten unterstützt und ermöglicht die schrittweise Einführung von Touchpoints im Unternehmen.

13.6 Projektmanagement

379

• Praktische Beispiele. Touchpoints gibt eine große Anzahl von praktischen Beispielen. • Umfangreiche Checklisten und Beschreibungen. Für die Durchführung der Aktivitäten liefert Touchpoints detaillierte Beschreibungen und konkrete Beispiele. Die systematische Berücksichtigung von Bedrohungen, die während der Analyse identifiziert wurden, stellt einen der wesentlichen Vorteile von Touchpoints dar. Insbesondere durch die spezifischen Black-Hat- und White-Hat-Aktivitäten (De Win et al. 2009) kann die Sicherheit der Software bezogen auf die identifizierten Bedrohungen getestet bzw. konstruiert werden.

13.5.5.4  SSE-CMM Abschließend wird das System Security Engineering Capability Maturity Model (SSE-­ CMM) als ein sicherheitsspezifisches Reifegradmodell für die Analyse der Entwicklungsprozesse in einem Unternehmen vorgestellt. Es wurde von der International Systems Security Engineering Association (ISSEA) entwickelt und stellt die Basis der ISO-Norm 21827:2008 dar. Analog zu den in Abschn. 13.3 beschriebenen Reifegradstufen des CMMI werden im SSE-CMM die typischen Reifegradstufen bezogen auf die Entwicklung sicherer Software definiert. Hierfür beinhaltet das SSE-CMM in elf Prozessgebieten sicherheitsspezifische Ziele und Basisprozesse, die im Entwicklungsprozess berücksichtigt werden sollen. Dies umfasst etwa das Risikomanagement, die Bedrohungs- und Schwachstellenanalyse, das entsprechende Anforderungsmanagement sowie die notwendigen Managementaktivitäten (s. Abschn. 4.3). Die Anwendung der SSE-CMM ermöglicht dem Unternehmen eine Analyse bestehender Entwicklungsprozesse und zeigt Verbesserungspotenziale auf.

13.6 Projektmanagement 13.6.1 Grundlegende Begriffe Die (Weiter-)Entwicklung von Software erfolgt typischerweise im Rahmen von Projekten. Dem nachfolgend dargestellten Begriffsverständnis folgend ist ein Projekt dann erfolgreich, wenn die im Leistungsverzeichnis dokumentierte technische Aufgabe erfüllt, der zur Bearbeitung veranschlagte Zeitraum eingehalten und die budgetierten Kosten nicht überschritten werden. cc Projekt  Ein Projekt ist ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.  B.  Zielvorgabe, zeitliche, ­finanzielle, personelle oder andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben und projektspezifische Organisation (DIN 69901-5 2009). Softwareentwicklungsprojekte sind besonders problematisch, weil es viele Beteiligte gibt, das Projekt oft eine lange Dauer hat, viele Schnittstellen zu anderen Projekten und

380

13  Phasenmodelle in der Softwareentwicklung

zu existierenden Systemen bestehen und das Projekt immer ein gewisses Machbarkeitsrisiko hat. Viele Realisierungsprobleme werden erst im Lauf der Entwicklung sichtbar. Deshalb bestehen auch große Unsicherheiten bezüglich Termin- und Kostenplanung. Zudem besteht zumeist eine Konkurrenz um knappe finanzielle wie personelle Ressourcen mit anderen Projekten. Im Gegensatz zu konventionellen Projekten (z. B. im Schiffbau) und zur Standardsoftwareeinführung gibt es bei der Individualentwicklung oft keine verlässlichen Konstruktions- und Arbeitspläne, sondern nur grobe Abschätzungen und Erwartungen. Viele Teilaktivitäten überlappen und wiederholen sich und sind u. U. durch komplexe Interdependenzen verbunden. Nicht zuletzt erschwert der hohe Spezialisierungsgrad vieler Aufgabenträger eine flexible Planung, und selbst nach Abschluss von Aktivitäten ist die Messung der Produktivität und Qualität aufwändig und/oder ­unsicher. Empirische Untersuchungen (Nelson 2007) belegen die Probleme von Softwareprojekten: Nach Nelson liegen 45 % der Probleme im „Planungsbereich“ wie zum Beispiel einer falschen Aufwandsschätzung, und 43 % im Bereich „Führung und Kommunikation“ wie Kommunikationsprobleme mit dem Auftraggeber oder Missverständnisse im Team. In relativ wenigen Fällen handelt es sich um technische Fehler oder Produktfehler (12 %). Ein geeignetes Projektmanagement kann das Gelingen eines Projekts unterstützen. cc Projektmanagement  Projektmanagement bezeichnet die Gesamtheit von Fü­hrungs­ aufgaben, -organisationen, -techniken und -mitteln für die Abwicklung sowohl aller Projekte als auch eines einzelnen Projekts (DIN 69901-5 2009). Mit einer sorgfältigen Projektplanung, einer kontinuierlichen Projektkontrolle und rechtzeitiger Planungsaktualisierung wird eine wichtige Voraussetzung geschaffen, um Entwicklungsprojekte erfolgreich abzuschließen. Flankierend sollte grundsätzlich versucht werden Projekte vor laufenden Änderungswünschen zu schützen, und soweit möglich Termin- und Kostenschätzungen für überschaubare Teilaktivitäten statt für das Gesamtprojekt durchzuführen. Als Schutz vor laufenden Änderungswünschen muss ein stringent angewendetes Nachforderungsmanagement (s. Abschn. 13.6.10) durchgeführt werden: Änderungswünsche werden dabei weder ignoriert noch automatisch integriert. Vielmehr geht es darum, das Bewusstsein zu schaffen, dass die Änderungswünsche zu veränderten Zielen, neuen Anforderungen oder einem veränderten Systemumfang geführt haben. Die Stakeholder müssen über die möglichen Konsequenzen bezogen auf Kosten, Zeit oder Qualität informiert sein. Hilfsmittel für das Projektmanagement sind dazu geeignet, bestimmte Sachverhalte zu visualisieren, anderen Beteiligten zu kommunizieren und Probleme aufzudecken. Die Planung und Steuerung der Projektarbeit kann durch Werkzeuge zwar unterstützt, nicht jedoch ersetzt werden. Im Folgenden werden einige der zentralen Punkte des ­Projektmanagements von Entwicklungsprojekten angesprochen. Für die weicheren Faktoren eines erfolgreichen Projektmanagements wie z. B. Führungsverhalten, Verhandlungsmanagement oder Konfliktbehandlung, sei auf die Literatur verwiesen

13.6 Projektmanagement

381

(z. B. (Schwalbe 2006; Hughes und Cotterell 2006; PMI 2017)). Einen Überblick über die unterschiedlichen Aspekte des Projektmanagements findet sich bei (Süß und Eschlbeck 2002).

13.6.2 PMBOK und PRINCE2 Im Rahmen der Unterstützung und Standardisierung der Abläufe im Projektmanagement sind vor allem zwei Handlungsrichtlinien hervorzuheben: Das Project Management Book of Knowledge (PMBOK) des Project Management Institute (PMI) und PRINCE2 vom britischen Office of Government Commerce (OGC). Beide Standards dienen dazu, im Unternehmen bzw. in der Zusammenarbeit zwischen den Unternehmen eine einheitliche Sprache im Projektmanagement sowie ein gemeinsames Verständnis entstehen zu lassen. Eine Anzahl von Prozessgruppen, Prozessen und Aktivitäten helfen die Abläufe in den Projekten eines Unternehmens effizienter zu organisieren. Detailliert beschriebene Themen und Wissensgebiete sorgen für ein fundiertes Know-how im Projektmanagement im Unternehmen bzw. vermitteln sog. Best Practices. Während das PMBOK für die Unterstützung jeder Art von Projekten angelegt ist, wurde PRINCE (Projects in Controlled Environments) zunächst für das Projektmanagement von IS-Projekten entwickelt. Der Standard PRINCE2:2009 zeichnet sich insbesondere durch eine bessere Integration von anderen Methoden (wie z. B. ITIL) aus. Sowohl zum PMBOK (PMI 2017) als auch zu PRINCE2 (Axelos 2017) ist umfangreiche Literatur verfügbar. Abb. 13.15 stellt die unterschiedlichen Prozesse und Themengebiete gegenüber und zeigt damit gleichzeitig die Gemeinsamkeiten. Beide Methoden werden laufend aktualisiert, zuletzt im Jahr 2017. Dennoch gewinnt agiles Projektmanagement an Beliebtheit. Das liegt daran, dass sich die agile Systementwicklung immer mehr durchsetzt. Bei kleinen Projekten wird sie einfach auch als Methode für das Projektmanagement genutzt, da manche der nachfolgend beschriebenen Phasen (z. B. Ablauf- und Terminplanung) schon integriert bzw. überschaubarer (z. B. Risikomanagement) als bei großen Projekten strukturiert sind. Die Erhöhung der Agilität bei großen Projekten wird methodisch auf zwei Wegen versucht. Auf der einen Seite werden die besprochenen traditionellen Ansätze mit agilen Konzepten vermischt. Für PRINCE2 gibt es auch eine neue Methode, genannt PRINCE2 Agile (Axelos 2015). Auf der anderen Seite gibt es Erweiterungen der agilen Vorgehensweise auf große Projekte (mit Hunderten von Softwareentwicklern). Als Beispiel wird hier kurz auf das Scaled Agile Framework (SAFe) eingegangen (Scaled Agile 2018). SAFe kennt zwei bis vier hierarchische Ebenen, je nach Umfang des Projekts. Auf der untersten Organisationsebene arbeiten kleine Teams mit Scrum erweitert um XP. Die Koordination der Teams erfolgt auf der nächsten Ebene, genannt Program, auf der ein Agile Release Team kontinuierlich neue Teillösungen liefert. Das entspricht auch dem DevOps-­Ansatz (s. Abschn.  13.5.4). Wenn noch Koordination für große Projekte benötigt wird, geschieht diese auf der Ebene Large Solution. Beim Einsatz von SAFe auf strategischer Ebene kann

382

13  Phasenmodelle in der Softwareentwicklung

Bereich

PMBOK 2010

PRINCE2 2009

Prozesse

Fünf Prozessgruppen mit 42 Prozessen:

Sieben Prozesse mit 40 Aktivitäten:

Wissensgebiete

Projektsteuerung

Werkzeuge/ Methoden

• • • • •

Initiierung Planung Ausführung Überwachung/Steuerung Abschluss

• • • • • • •

Vorbereiten eines Projekts Lenken eines Projekts Initiieren eines Projekts Steuern einer Phase Managen der Produktauslieferung Managen der Phasenübergänge Abschließen eines Projekts

• • • • • • • • •

Integrationsmanagement Inhalts- und Umfangsmanagement Terminmanagement Kostenmanagement Qualitätsmanagement Personalmanagement Kommunikationsmanagement Risikomanagement Beschaffungsmanagement

• • • • • • •

Business Case Organisation Qualität Pläne Risiken Änderung Fortschritt

(keine bzw. beschränkte Abdeckung des Beschaffungs- und Personalmanagements)

• Fortlaufende Ausrichtung an den Kundenanforderungen • Geringer Produktfokus • Konzentration auf das PM

• Fortlaufende Ausrichtung am Business Case (Überprüfung nach jeder Phase) • Ausgeprägter Produktfokus • Konzentration auf die Schnittstelle zwischen PM und der Erstellung von Produkten

• Hohe Anzahl verschiedener Werkzeuge und Methoden zur Unterstützung jedes Projekts • Implizite Aufforderung zur Nutzung bestimmter Methoden

• Begrenzte Anzahl verschiedener Methoden und Werkzeuge • Explizite Aufforderung zur Nutzung bestimmter Methoden

Abb. 13.15  Vergleich zwischen PMBOK und PRINCE2 (in Anlehnung an (Bölke et al. 2009))

schließlich auch eine Portfolio genannte Ebene zum Einsatz kommen. Ein solcher Einsatz ist auch ohne große Projekte denkbar. Auf der Ebene von Teams unterstützt der Scrum Master die Teams, wie in Abschn. 13.5.3.2 beschrieben. Auf den Ebenen Program und Large Solution übernimmt das ein Release Train Engineer bzw. ein Solution Train Engineer. Anhänger der Agilitäts-Philosophie kritisieren die hierarchische ­Organisation des Ansatzes, aber die Methode wird bereits von vielen großen Unternehmen eingesetzt (z. B. Deutsche Bahn).

13.6.3 Projektphasen Man kann die verschiedenen Aktivitäten eines Projekts zur übersichtlicheren Beschreibung unterschiedlichen Phasen zuordnen (s. Abb. 13.16). Hiermit soll grob eine zeitliche Anordnung erfolgen. Die in den Phasen durchzuführenden Aktivitäten werden in den folgenden Unterabschnitten erläutert. Zunächst soll jedoch unabhängig davon auf das Thema Projektorganisation eingegangen werden. Wie in der Definition eines Projekts

13.6 Projektmanagement

383

Projektstart

Projektplanung

Projektdurchführung

Projektkontrolle

Projektabschluss

Abb. 13.16  Phasen eines Projekts

Lenkungsausschuss

Auftraggeber

Projektleiter

Mitarbeiter

Teilprojektleiter

Teilprojektleiter

Mitarbeiter

Mitarbeiter

Teilprojektleiter

Abb. 13.17 Projektorganisation

festgehalten, kann man davon ausgehen, dass ein Projekt eigene personelle (wenn auch begrenzte) Ressourcen besitzt. Entsprechend den Aufgaben der Personen hat ein Projekt eine eigene Projektorganisation. Abb. 13.17 zeigt eine beispielhafte Projektorganisation mit den wichtigsten Projektrollen: • Der Lenkungsausschuss überwacht die Projektdurchführung hinsichtlich der erbrachten Leistungen, deren Qualität, des Ressourceneinsatzes und der Termine. Er nimmt die Projektergebnisse verantwortlich ab und entscheidet verbindlich über den Projektfortschritt.

384

13  Phasenmodelle in der Softwareentwicklung

Er unterstützt die Klärung wichtiger Probleme und Konflikte. Der Lenkungsausschuss setzt sich zumeist aus Personen mit Entscheidungskompetenz (z. B. Mitgliedern der Geschäftsführung, Bereichsleitern, ggf. dem Auftraggeber und Sponsoren) zusammen. • Der Auftraggeber gibt die Ziele des Projekts vor und überprüft die Ergebnisse im Hinblick auf diese Ziele. Er hat ein Vetorecht bei Entscheidungen mit Auswirkungen auf die Ziele, den finanziellen Rahmen oder die Termine. Er kann Statusberichte und Informationen bei drohenden Termin- und Kostenüberschreitungen anfordern. Er unterstützt den Projektleiter bei fachlichen Fragen und stellt die nötigen Ressourcen für das Projekt zur Verfügung. Er nimmt die Projektleistungen ab und entlastet den Projektleiter bei Projektabschluss. • Die wichtigste Rolle in der Projektorganisation ist die des Projektleiters (PL). Er stimmt sich mit dem Auftraggeber in allen Belangen des Projekts ab. Zu Beginn eines Projekts prüft er die Durchführbarkeit. Er bereitet die Infrastruktur für das Team vor und sorgt für bestmögliche Arbeitsbedingungen. Außerdem organisiert und moderiert er die Projektsitzungen und plant das Projekt. Er informiert den Auftraggeber bei drohenden Risiken sowie Planabweichungen und er führt regelmäßige Soll-Ist-Vergleiche für Kosten, Termine und Ziele durch. Letztendlich ist er für die auftragsgemäße Projektdurchführung sowie die Einhaltung von Projektzielen, Terminen und Budget verantwortlich. Die Kompetenzen des Projektleiters müssen so gestaltet sein, dass er seine Aufgaben wahrnehmen und der Verantwortung gerecht werden kann. Informationsrechte und Unterstützung durch Fachabteilungen sind unverzichtbar. Die fachliche Weisungsbefugnis gegenüber den Projektmitarbeitern ist bei den meisten Projekten für eine erfolgreiche Projektführung dringend notwendig. Idealerweise sind fachliche und personelle Weisungsbefugnis in der Person des PL integriert. • Die Mitarbeiter sind dem Projekt in Vollzeit oder zu einem definierten Prozentsatz zugeordnet. Sie erledigen die übertragenen Arbeitspakete selbstständig, dokumentieren die Arbeitsergebnisse, berichten Arbeitsfortschritte an den Projektleiter und arbeiten bei fachlichen Problemstellungen konstruktiv im Team mit.

13.6.4 Projektstart Die Startphase eines Projekts ist gekennzeichnet durch die Voruntersuchung auf der Basis einer Projektidee (meist inklusive einer entsprechenden Machbarkeitsuntersuchung), die Durchführungsentscheidung auf der Grundlage der Voruntersuchung, sowie die Erstellung des Projektantrags (als Basis des Lastenhefts). Diese Aktivitäten sind mehr als informeller Projektstart zu sehen, da erst mit der verbindlichen Festschreibung der Ziele, der Anforderungen und des Projektumfangs (s.  Abschn.  13.4) sowie der Festlegung des Budgets und des Zeitrahmens ein Projekt entsteht (s. Abb. 13.18). Dementsprechend erfolgt erst mit der Auftragsvergabe an einen (internen/externen) Auftraggeber auf der Basis eines Pflichtenhefts (s. Abschn. 13.4.2) der formelle Projektstart.

13.6 Projektmanagement

385

Projektidee

Ernennung eines Verantwortlichen

Voruntersuchung Projekt Informeller Projektstart

Entscheidung über Projektdurchführung

Studie Projektantrag

Nein

Ja

Festlegung Projektumfang, Projektziele, Projektbearbeitung

Projektauftrag

Formeller Projektstart

Abb. 13.18  Informeller – Formeller Projektstart

13.6.5 Projektplanung Im Rahmen des Projektmanagements ist die Planung eine der zentralen Aufgaben. Hierbei sind die folgenden Aktivitäten zu unterscheiden: • Projektstrukturierung. Was ist alles zu tun? • Meilensteinplanung. Welches sind wichtige Ereignisse im Projektverlauf? • Einsatzmittelbedarfsplanung. Wie viel Arbeitsaufwand und welche sachlichen Einsatzmittel sind zur Erbringung von Arbeitsergebnissen notwendig? • Ablauf- und Terminplanung. In welcher Reihenfolge und zu welchen Terminen müssen die Arbeitspakete abgearbeitet werden? • Kostenplanung. Welche Kosten verursachen die einzelnen Arbeitspakete?

386

13  Phasenmodelle in der Softwareentwicklung

• Planoptimierung. Stimmt der bis dahin geplante Projektverlauf mit den Wünschen des Auftraggebers überein? • Risikomanagementplanung. Sind die Aktivitäten des Risikomanagements für das Projekt definiert (s. Abschn. 13.6.9)?

13.6.5.1  Projektstrukturierung Ein Projekt ist ein komplexes Vorhaben. Die Strukturierung dient also in erster Linie der Reduktion der Komplexität und der Herstellung von Transparenz. Die Gesamtaufgabe des Projekts wird in plan- und kontrollierbare Teile gegliedert. Dargestellt wird die Strukturplanung im Projektstrukturplan (PSP), der auch als Work Breakdown Structure (WBS) bezeichnet wird. Der PSP dokumentiert alle Aktivitäten, macht aber keine Aussage zum zeitlichen Ablauf. Der besondere Wert des Projektstrukturplans liegt darin, dass er alle zum Erreichen des Projektziels notwendigen Aktivitäten aufzeigt. Der fertige PSP bildet die vollständige und strukturierte Gliederung des Projekts ab. Es gibt zwei grundsätzliche Prinzipien, nach denen ein Projektstrukturplan aufgebaut werden kann: • Objekt- bzw. produktorientiert (s. Abb. 13.19), oder • prozess-, funktions- bzw. phasenorientiert (s. Abb. 13.20). Die Zahl der Gliederungsebenen richtet sich nach der Größe des Projekts. Bei der objekt- oder produktorientierten Strukturierung ist das zu erreichende Projektziel der Ausgangspunkt. Die prozess-, funktions- oder phasenorientierte Strukturierung folgt dem Weg zum Erreichen des Projektziels. Dieser Weg wird in kleinere, meist chronologisch geordnete Teilziele zerlegt. Die oberste Gliederungsebene wird gemäß dem EntwicklungsFirmenInternetAuftritt

Struktur der Website

Start-Seite

FirmenDarstellung

Verkaufs-Seite

Struktur

Text

Text

Text

Layout

Bilder

Bilder

Bilder

Programme

Verweise

Verweise

Verweise

Abb. 13.19  Beispiel eines produktorientierten PSP

13.6 Projektmanagement

387

FirmenInternetAuftritt

ProjektDefinition

Definiere Projektplan Spezifiziere erste Anforderungen Plane Personal und Ressourcen

Analyse

Entwurf

Implementierung

Analysiere bestehendes System

Definiere Anforderungen

Definiere Nutzeranforderungen

Definiere Website-Inhalte

Definiere Systemanforderungen

Test

Einführung

Wartung

Definiere nichtfunktionale Anforderungen

Analysiere Risiken

Abb. 13.20  Beispiel eines prozessorientierten PSP

ablauf strukturiert, die dann weiter in einzelne Prozessschritte unterteilt wird. Der Vorteil dieses Prinzips liegt in der übersichtlichen Darstellung des zeitlichen Verlaufs. Wenn sich die Phasen nicht scharf trennen lassen, so ist diese Gliederung weniger geeignet. Das Projektteam erstellt den PSP in Teamarbeit. Wichtigstes Ziel ist die Vollständigkeit aller Aktivitäten. Die Aktivitäten sollten klar voneinander abgegrenzt und Überschneidungen sollten vermieden werden. Oftmals wird ein PSP gemischt-orientiert sein. Man sollte jedoch versuchen, jeweils ein Element nach einem einheitlichen Prinzip zu detaillieren. Dies erleichtert die Überprüfung auf Vollständigkeit. Der PSP sollte soweit detailliert werden, bis jeder Aktivität der untersten Ebene (= Arbeitspaket) genau ein Verantwortlicher zuordenbar ist. Weiterhin ist der Detaillierungsgrad so zu wählen, dass eine zuverlässige Schätzung der Kosten und Dauer der Arbeitspakete möglich ist. Das Ziel des PSP ist es nicht, eine Reihenfolge von Aktivitäten darzustellen. Der PSP dient ausschließlich zur inhaltlichen Gliederung des Projektziels. Wenn ein Unternehmen häufig gleichartige Projekte durchführt, so bietet sich die Verwendung von Standardstrukturplänen an. Damit werden vor allem zwei Ziele verfolgt: Erfahrungssicherung und Planungsvorlage. Man muss jedoch überprüfen, ob alle Aspekte des Projekts im verwendeten Standardstrukturplan berücksichtigt sind. Als Arbeitspakete (AP) bezeichnet man die unterste Ebene im PSP. Ein AP wird nicht weiter aufgegliedert und kann auf einer beliebigen Gliederungsebene liegen. Jedes Arbeitspaket ist eine klar abgegrenzte und in sich geschlossene Einheit. Ein Arbeitspaket sollte so festgelegt sein, dass es eindeutig ist und eigenverantwortlich bearbeitet, zugekauft oder bereitgestellt werden kann. Die Arbeitspakete bilden die Basis für die weitere Projektplanung. Zur näheren inhaltlichen Beschreibung eines Arbeitspakets werden im weiteren Verlauf der Projektplanung zu jedem Arbeitspaket auch Termine, Kosten und zeitlichen Aufwände ermittelt.

388

13  Phasenmodelle in der Softwareentwicklung

13.6.5.2  Meilensteinplanung Zur laufenden Kontrolle des Projektfortschritts sollten verschiedene Zeitpunkte im Projekt festgelegt werden, zu denen bestimmte Hauptvorgänge abgeschlossen sein müssen. Für Entwicklungsprojekte werden typischerweise Meilensteine mit Fertigstellung des Projektantrags, des Pflichtenhefts, des Prototyps und/oder mit der Abnahme definiert. 13.6.5.3  Einsatzmittelbedarfsplanung Ein detaillierter PSP ist eine geeignete Grundlage für die Kostenschätzung. Welche Einsatzmittel werden in welcher Menge zur Bearbeitung der einzelnen Arbeitspakete benötigt? Wichtigster und schwierigster Unterpunkt bei der Einsatzmittelbedarfsplanung ist die Aufwandsermittlung. Der Aufwand ist die benötigte Menge menschlicher Arbeit. Die Schätzung dieser Komponente gestaltet sich besonders schwierig. Die Einsatzmittelbedarfsplanung bildet die Grundlage für die Kostenplanung und damit auch für das Controlling. Es werden zu jedem Arbeitspaket die zur Erstellung der Leistung benötigten Einsatzmittel ermittelt. Man unterscheidet die Einsatzmittel (die „drei M“): Mensch, Maschine und Material. Es existieren viele Aufwandsschätzmethoden, die mehr oder weniger aufwändig sind und die teilweise speziell für bestimmte Branchen und Projektarten entwickelt wurden. Eine äußerst effektive und universal einsetzbare Methode basiert auf der Analyse der Arbeitspakete. Jedes Arbeitspaket wird isoliert betrachtet. Folgende Vorgehensweise empfiehlt sich (s. Abb. 13.21): • Das Abschätzen der Arbeitsmenge (= Aufwand, Einheit z. B. Personenmonate [PM], Personentage [PT] oder -stunden [PH]), die voraussichtlich notwendig sein wird, um das definierte Ergebnis des Arbeitspakets zu erreichen. Falls möglich, wird der hier geschätzte Aufwand bereits nach einzelnen Rollen aufgeteilt (also z. B. Analytiker, Programmierer und Administrator). Da jede Schätzung einzig und allein auf Erfahrungen basiert, ist es zur Verbesserung der Aufwandsschätzung notwendig, Erfahrungssicherung zu betreiben. Die Methoden zur Unterstützung der Aufwandsschätzung zielen darauf ab, die Erfahrungssicherung zu systematisieren und möglichst transparent zu machen. Beim Abschätzen des Aufwands für ein Arbeitspaket sollte unbedingt der zuständige Mitarbeiter mit eingebunden sein, da der Projektleiter alleine dies in der Arbeitspakete Definiere Projektplan Spezifiziere erste Anforderungen Plane Personal und Ressourcen Analysiere Risiken

Bearbeiter Fr. Herzog Hr. Kasse Fr. Herzog Hr. Zog Fr. Herzog Hr. Kasse

Abb. 13.21  Tabelle zur Aufwandsschätzung

Personaleinsatz 50% 100% 100% 100% 50 % 20 %

Aufwand 4 PH 90 PH

Dauer 8H 30 H

4 PH

8H

10 PH

50 H

13.6 Projektmanagement

389

Regel nicht leisten kann. Der geschätzte Aufwand hängt vom Arbeitsinhalt eines Arbeitspakets ab. • Das Abschätzen der maximalen Intensität, mit der eine Ressource diesen Aufwand erbringen kann (= Personaleinsatz, Einheit entweder in [%] oder z. B. [PH/T]). Hier gibt es meist „natürliche“ Obergrenzen. So können beispielsweise nicht gleichzeitig zwei Teams an einem Modul arbeiten. • Urlaube, Schulungen oder sonstige geplante Abwesenheiten von Ressourcen werden in diesem Planungsstadium noch nicht berücksichtigt, dies erfolgt im Rahmen der Planoptimierung. • Aus den beiden Größen Aufwand und (maximal sinnvollem) Personaleinsatz lässt sich ableiten, welcher Zeitbedarf (= Dauer, Einheit in Tagen [T], Wochen [W] oder Stunden [H]) für die Durchführung eines Arbeitspakets notwendig ist. Als einfache Rechenformel kann hierfür die lineare Verteilung des Aufwands über die Dauer angewendet werden (Dauer = Aufwand/Personaleinsatz). Wenn im ersten Schritt die Aufwände bereits für die einzelnen Ressourcen getrennt geschätzt wurden, so ergibt sich je Rolle/Ressource eine individuelle Bearbeitungsdauer. Fehler bei der Aufwandsschätzung sind in beinahe jedem Projekt zu beklagen. Teilweise werden aber auch Schätzfehler unterstellt, obwohl eine Veränderung der Rahmenbedingungen für erhöhte Aufwände verantwortlich ist. Allerdings liegen Schätzungenauigkeiten in der Natur der Materie. Projekte sind komplexe Vorhaben mit anfangs unklaren Vorstellungen, auf welchen Wegen das Ziel erreicht wird. Erste Schätzungen sind somit höchst unsicher und es sollte eine Bandbreite von akzeptierten Abweichungen definiert werden. Folgende Punkte sind bei der Aufwandsschätzung zu beachten: • Aufwandsschätzungen zu neuen Themen fallen erfahrungsgemäß zu niedrig aus. • Zu niedrige Schätzungen sind auch für Mitarbeitende typisch, die nur selten bewusst Aufwände schätzen. • Viele Mitarbeiter trennen Aufwand und Dauer nicht scharf. Der Aufwand hängt vom zu erbringenden Arbeitsinhalt ab, ist also nicht direkt beeinflussbar. Die Dauer kann dagegen durch mehr oder weniger intensives Arbeiten an einem Arbeitspaket beeinflusst werden. • Auch Projektmanagement verursacht Aufwand. Dieser wird jedoch häufig nicht in die Planung mit einbezogen. Analog verhält es sich mit Aufwänden für die Qualitätssicherung. • Es sollten erfahrene Mitarbeiter zur Aufwandsschätzung hinzugezogen werden. Die Bestimmung der Dauer bereitet dann keine Probleme, wenn der Aufwand und der Personaleinsatz richtig geschätzt sind. Der lineare Zusammenhang zwischen Personaleinsatz und Dauer bei gegebenem Aufwand existiert nur, wenn die Tätigkeit teilbar ist, ohne dass ein erhöhter Kommunikationsaufwand dazu kommt. Man unterscheidet teilbare Tätigkeiten, nicht-teilbare Tätigkeiten und Tätigkeiten, deren Teilung einen erhöhten Aufwand verursacht.

390

13  Phasenmodelle in der Softwareentwicklung

• Bei teilbaren Tätigkeiten kann durch eine Verdopplung des Arbeitseinsatzes eine proportionale Verkürzung der Dauer erreicht werden – der Aufwand bleibt gleich (zu vernachlässigender Koordinationsaufwand). • Bei nicht-teilbaren Tätigkeiten ändert eine Erhöhung des Arbeitseinsatzes die Dauer nicht – dafür steigt der Aufwand proportional. Tätigkeiten dieser Kategorie sind prinzipiell teilbar, allerdings bringt die Erhöhung des Arbeitseinsatzes keine proportionale Verkürzung der Dauer. Mit anderen Worten: Um die Dauer zu halbieren, muss der Arbeitseinsatz mehr als verdoppelt werden, d. h. der Aufwand erhöht sich. Dieses Phänomen wird nach (Brooks 1975) als Brooks Law bezeichnet. Ein Verfahren, um die Aufwandsschätzung auf eine gute Grundlage zu stellen, ist die sog. Schätzklausur. Das Hauptziel der Schätzklausur ist es, die Gesamtkosten des Projekts so genau wie möglich zu schätzen. Hierzu sind die voraussichtlichen Kosten der Arbeitspakete zu ermitteln. Es sollen Missverständnisse über den Leistungsinhalt der Arbeitspakete beseitigt und Informationslücken geschlossen werden. Alle Voraussetzungen, die für die Projektarbeit erfüllt sein müssen (z. B. Zulieferungen von anderen Abteilungen), sollen erläutert werden. An der Schätzklausur sollten der Projektleiter und die verantwortlichen Mitglieder des Projektteams beteiligt sein. Wenn es erforderlich ist, können auch andere Fachleute aus der Organisation, die nicht am Projekt beteiligt sind, zur Unterstützung hinzugezogen werden. Weiterhin ist es vorteilhaft, wenn ein Moderator, der die Klausur leitet und ein Kaufmann, der die Mengenangaben in Kostenwerte umrechnet, dem Teilnehmerkreis angehören. Eine Schätzklausur kann wie folgt ablaufen: • Zunächst wird jedes einzelne Arbeitspaket von dem verantwortlichen Teammitglied erläutert. • Dann fordert der Moderator die Beteiligten auf, gleichzeitig auf Papptafeln, ähnlich wie die Punktrichter beim Eiskunstlauf, eine Schätzung abzugeben. • Wenn die Einzelschätzwerte, die durch Errechnung eines Durchschnitts zu einem Gesamtschätzwert zusammengefasst werden, sehr weit auseinander liegen, kann folgendermaßen vorgegangen werden. • Der Schätzer mit dem höchsten und der Schätzer mit dem niedrigsten Wert werden vom Moderator aufgefordert, in der Diskussion die Gründe für ihren niedrigen bzw. hohen Schätzwert darzulegen. Dabei stellt sich zumeist heraus, dass beide von sehr unterschiedlichen Annahmen über den Arbeitsumfang ausgehen. Es muss möglichst in der Sitzung noch geklärt werden, welche davon voraussichtlich zutreffen und welche nicht. • Nach der Diskussion wird die Schätzung wiederholt. Die Teilnehmer der Schätzklausur haben dabei die Möglichkeit, die neuen Informationen, die sie möglicherweise erhalten haben, zu berücksichtigen und ihre Schätzung nach oben oder unten zu revidieren. Natürlich ist auch ein weniger formaler Ablauf ohne Moderator insbesondere bei kleineren Projekten möglich und auch sinnvoll. Weitere Verfahren zur Aufwandsschätzung sind

13.6 Projektmanagement

391

die Aufwandschätzung durch die Entwickler in Lines of Codes (LoC) und eine von der Leistungsfähigkeit des Teams abhängige Hochrechnung auf den Personalaufwand. Weiterhin gibt es algorithmische Verfahren, die verschiedene Aufwandsfaktoren, welche den Entwicklungsprozess beeinflussen, in einer Formel berücksichtigen. Die bekanntesten Vertreter hierfür sind das Constructive Cost Model (COCOMO) und die Function Point Analysis (Hughes und Cotterell 2006). Bei der agilen Softwareentwicklung basiert die Schätzung oft auf Story Points. Diese werden von den Teammitgliedern auf Basis der Anforderungen (User Stories, s. Abschn. 13.5.3.2) geschätzt, die im Product Backlog stehen. Dabei werden i. d. R. Punkte so vergeben, dass sie der relativen Schwierigkeit der Umsetzung entsprechen. Wie schnell die Story Points abgearbeitet werden, hängt u. a. von der Erfahrenheit des Teams ab.

13.6.5.4  Ablauf- und Terminplanung Im Rahmen dieser Planung werden die Aktivitäten mittels Netzplantechniken in die richtige Reihenfolge gebracht. Voraussetzungen sind die Projektstrukturierung, die Meilensteinplanung und die Einsatzmittelplanung inklusive der Aufwandsschätzung. Weiterhin ist eine Analyse der Abhängigkeiten zwischen den einzelnen Arbeitspaketen notwendig. Zwei Arbeitspakete A und B können durch verschiedene Arten von Abhängigkeiten verknüpft sein. Z.  B. kann B frühestens nach Abschluss von A anfangen oder A muss ­spätestens bei Beginn von B beendet sein. Der zeitliche Verlauf der Aktivitäten lässt sich in Form eines Balkendiagramms darstellen. Ein solches Diagramm (auch Gantt-Diagramm genannt) dokumentiert sehr gut die verschiedenen Verknüpfungen zwischen den Teilaktivitäten. Abb. 13.22 zeigt Teile des Gantt-Diagramms zum Projektstrukturplan für das Projekt Internet-Auftritt aus Abb. 13.19. Es dokumentiert, wie die Hauptaktivitäten entsprechend ihrer Dauer und Abhängigkeiten terminiert werden. Im Beispiel kann der Entwurf erst begonnen werden, wenn die Analyse abgeschlossen wurde. Sind die Aktivitäten terminiert, kann aus dem Projektplan ein Ressourcennutzungsplan abgeleitet werden, aus dem erkennbar wird, wann welche Beteiligten wie stark ausgelastet sind. Eine Weiterentwicklung des Balkendiagramms stellt der Netzplan dar. Allen Netzplantechniken ist ein grafisches Modell gemeinsam, das die einzelnen Vorgänge und die Zeitpunkte, an denen diese Vorgänge beginnen bzw. enden (Ereignisse), in ihrer logischen Aufeinanderfolge übersichtlich und eindeutig darstellt. Auf dieser Grundlage kann dann beispielsweise der kritische Pfad ermittelt werden, der die Vorgänge des Netzplans angibt, deren Verzögerung auch den Endtermin des Gesamtprojekts verzögern würde. Nicht kritische Vorgänge sind auch innerhalb gewisser Grenzen (Pufferzeiten) verschiebbar. In Abb. 13.23 wird ein einfacher Beispiel-Netzplan dargestellt, dessen Knoten die Ereignisse bilden, während die Pfeile die Vorgänge repräsentieren. Die Knoten weisen jeweils den frühest möglichen (FAZ) und spätest möglichen Starzeitpunkt (SAZ) auf, der noch die Einhaltung des Projektendtermins ermöglicht. Der FAZ wird durch Vorwärtsterminierung (Addition der Vorgangszeiten) und der SAZ durch Rückwärtsterminierung (sukzessive

392

13  Phasenmodelle in der Softwareentwicklung

Abb. 13.22 Balkendiagramm

FAZ SAZ

Vorgang Dauer

15 20

C 5

20 25

B

D

5

5

A 10

10 10

E

15 15

30 30 H

S1 0

5

20 25 G 5

0 0

F 10

K 10

40 40

5

25 25

Abb. 13.23 Netzplan

Subtraktion der Vorgangszeiten von der Gesamtprojektdauer) der Vorgänge berechnet. Der kritische Pfad ist in Abb. 13.23 durch dickere Pfeile gekennzeichnet. Zur Unterstützung des Projektmanagements im Rahmen der Projektplanung sind schwerpunktmäßig die klassischen Werkzeuge zur Netzplantechnik (allen voran Microsoft Project mit einer integrierten Personaleinsatzplanung) zu nennen.

13.6 Projektmanagement

393

13.6.6 Planoptimierung Die bisher erstellte Planung weist noch erhebliche Defizite auf, da die Verfügbarkeit von Personal nicht berücksichtigt wurde. Die Verfügbarkeit von Personal ist in der frühen Phase der Planung schwer einzuschätzen, da unterschiedliche Projekte und Abteilungen des Unternehmens um das Personal konkurrieren. Prinzipiell lässt sich die Planung nach den drei wichtigsten Planungselementen optimieren: Personal, Termine und Kosten. Das Hauptinteresse bei der Optimierung eines Projektplans liegt in der Regel auf den benötigten Ressourcen. Mit Hilfe des sog. Belastungsdiagramms wird der Personaleinsatz überprüft. Ein Belastungsdiagramm besteht aus den zwei Grundelementen: Personalverfügbarkeit und Personalbedarf. Die Personalverfügbarkeit bildet die voraussichtliche Kapazität ab, mit der Personal für das Projekt zur Verfügung steht. Wenn der Mitarbeiter in Urlaub ist, so sinkt die Linie auf Null. Der Bedarf ergibt sich aus der bisherigen Planung. Die zeitliche Lage ergibt sich aus der Terminplanung. Aus der Gegenüberstellung von Verfügbarkeit und Bedarf geht hervor, ob die geplanten Aufwände in der dafür vorgesehenen Zeit erbracht werden können. Übersteigt der Bedarf im betrachteten Zeitraum die Verfügbarkeit, so ist die Planung nicht realisierbar. Sie muss nochmals verbessert werden. Prinzipiell gibt es hierfür zwei Möglichkeiten: (1) Man erhöht die Verfügbarkeit, indem zusätzliches Personal zum Einsatz kommt, z. B. durch Überstunden oder Fremdbezug. Dies macht man, wenn der Termin eingehalten werden muss. (2) Man ändert die Termine und verschiebt die Aufgaben nach hinten oder vorne, weil die Verfügbarkeit nicht erhöht werden kann oder freie Pufferzeiten dies ermöglichen. So kann etwa durch das Verschieben des Arbeitspakets von der frühesten Lage zur spätesten Lage die Personalüberlast abgebaut werden.

13.6.7 Projektdurchführung und Projektkontrolle Eine fundierte und realistische Projektplanung ist die Basis für eine funktionierende Projektdurchführung und -kontrolle. Sie wird wie eine Landkarte verwendet die es erlaubt, das Abweichen vom richtigen Weg möglichst frühzeitig festzustellen. So wichtig die Planung auch ist, sie wurde nur gemacht, um das Projekt auch durchführen zu können. Da die Wirklichkeit sich aber nicht immer an Pläne hält, muss der Projektleiter aktiv steuern um das Projekt plangemäß durchführen zu können, und bei drohender Planabweichung muss er bereits im Vorfeld Steuerungsmaßnahmen ergreifen um das Projekt im Plan zu halten. Der Plan-Ist-Vergleich ist mit Sicherheit das bekannteste und am weitesten verbreitete Instrument der Projektsteuerung. Das Ziel ist es, durch die Gegenüberstellung von ursprünglicher Planung (= Plan) und momentaner Situation (= Ist) Abweichungen

394

13  Phasenmodelle in der Softwareentwicklung

Abb. 13.24  Zielgrößen der Projektplanung

Leistung Qualität

Zielgrößen der Projektplanung

Zeit/ Termine

Kosten (Ressourcen)

transparent zu machen und deren Auswirkungen auf den weiteren Projektverlauf abzuschätzen. Wenn sich aus der Gegenüberstellung der Plan- und Ist-Daten eine Abweichung ergibt, die eine Planänderung erforderlich macht, werden die aktualisierten Plandaten Soll-Daten genannt. Man spricht dann auch von Soll-Ist-Vergleich. Der Plan-Ist-Vergleich kann für alle Steuerungsparameter (Termine, Aufwände, Kosten) gemacht werden. Alle Plan-Ist-Vergleiche und Trendanalysen dienen einzig dem Ziel, möglichst frühzeitig Abweichungen bei Terminen, Leistungen, Aufwänden oder Qualität erkennen und geeignete Gegenmaßnahmen ergreifen zu können. Die Steuerungsmaßnahmen haben „Nebenwirkungen“. Wenn man zum Beispiel einen drohenden Terminverzug durch den Einsatz von Gegenmaßnahmen abwenden will, so wirkt dies in der Regel auf Kosten und/ oder die Leistung bzw. Qualität aus (s. Abb. 13.24).

13.6.8 Projektabschluss Der Projektabschluss ist der offizielle Schlusspunkt eines Projekts. Das Projektergebnis wurde vom Auftraggeber abgenommen. Es fallen keine weiteren Aufwände für die Erreichung des Projektziels an. Die Ziele des Projektabschlusses sind: • Überleitung des während des Projekts entstandenen IS in die Betriebs- und Wartungsphase. • Auflösung der Projektorganisation. Um die Voraussetzungen für einen geregelten Projektabschluss zu schaffen, muss der Projektleiter rechtzeitig die künftige Verwendung der Mitarbeiter klären. Dies kann einen Motivationsabfall zum Ende des Projekts vermeiden. • Erfahrungssicherung. Die Projektbeteiligten sollten ihre Erfahrungen aus der Planung, Durchführung und Steuerung des Projekts für Folgeprojekte zeitnah dokumentieren bzw. kommunizieren.

13.6 Projektmanagement

395

• Konfliktbewältigung. Die in dem Projekt aufgetretenen Konflikte im Team oder auch mit dem Auftraggeber sollten jetzt noch einmal analysiert und wenn möglich abschließend bereinigt werden. Im Folgenden sind einige Fragen, die im Rahmen der Abschlusssitzung zur Erfahrungssicherung angesprochen werden sollten, aufgeführt: • • • • • • • • • • • • • •

Wie sind die Qualität, die Termine und die Kosten des Projekts zu beurteilen? Welche Abweichungen haben stattgefunden? Was war die Ursache der Abweichungen? Wann wurden die Abweichungen erkannt? Was waren die ersten Anzeichen für drohende Abweichungen? Warum wurden sie nicht erkannt? Was kann getan werden, um künftig drohende Abweichungen früher zu erkennen? Welche Steuerungsmaßnahmen wurden ergriffen und wie ist die Wirksamkeit der Maßnahmen zu beurteilen? Wären andere Maßnahmen möglich und nach heutigem Kenntnisstand geeigneter gewesen? Wo haben keine Abweichungen stattgefunden? Was waren die Gründe für die plankonforme Durchführung? Wurden alle Risiken erfasst und verfolgt? Wie kann das Risikomanagement verbessert werden? Wie war die Zusammenarbeit im Projektteam? Wie war die Zusammenarbeit mit dem Auftraggeber/Kunden?

13.6.9 Risikomanagement Ein wichtiger Punkt in der Projektplanung und Projektdurchführung ist das Management von Risiken, die in der Systementwicklung auftreten können. Es liegt an den Eigenschaften eines Projekts, dass es mit Risiken verbunden ist. Die Vergangenheit hat zudem gezeigt, dass speziell Systementwicklungsprojekte große Risiken bergen und aufgrund der nicht angemessenen Behandlung dieser Risiken gescheitert sind. Im Folgenden soll ein grober Überblick zu dem Thema Risikomanagement gegeben werden. Für eine umfassendere und detaillierte Behandlung sei u.  a. auf (Wallmüller 2004) und (PMI 2017) ­verwiesen. Eine anschauliche Einführung in dieses Thema geben auch (DeMarco und Lister 2003). cc Risiko  Ein Risiko ist ein unbestimmtes Ereignis, dessen Eintreten eine Gefahr für den Projekterfolg, d. h. für die zu erbringenden Leistungen, die Terminplanung und/oder die geplanten Einsatzmittel, darstellt. Ein Risiko hat eine Eintrittswahrscheinlichkeit sowie eine Auswirkung auf das Projekt bzw. das Unternehmen.

396

13  Phasenmodelle in der Softwareentwicklung

Risikoidentifikation Identifizierung und Erfassung von Risiken/Risikoursachen

Risikoanalyse und Risikobewertung Wie wahrscheinlich ist das Eintreten eines Risikos und welche Folgen ergeben sich?

Risikoüberwachung Laufende Berichtserstattung und Überwachung der Risiken und Risikosteuerungsmaßnahmen

Risikohandhabung Maßnahmen und Mechanismen zur Risikobeeinflussung

Abb. 13.25  Grundaufgaben des Risikomanagement-Prozesses (Wallmüller 2004)

Ausgehend von der Risikoidentifikation wird in Abb. 13.25 der Ablauf des Risikomanagement-Prozesses aufgezeigt. Im Folgenden werden dann diese Grundaufgaben näher erläutert. Entsprechend können die Aufgaben des Risikomanagements wie folgt definiert werden. cc Risikomanagement  Die Aufgabe des Risikomanagements ist es, Faktoren, die eine Gefahr für den Projekterfolg (die im Projektauftrag definierte Leistung in geplanter Zeit mit den geplanten Ressourcen im vorgegebenen Budget zu erbringen) darstellen, zu identifizieren, zu bewerten und entsprechende Gegenmaßnahmen vorzubereiten bzw. einzuleiten.

13.6.9.1  Risikoidentifikation Das Ziel der Risikoidentifikation ist es, alle denkbaren Gefahren für den Projekterfolg zu identifizieren. Was nicht bekannt ist, dem kann nicht im Vorfeld begegnet werden. Zur Risikoidentifikation gibt es prinzipiell zwei Zugänge: • Kreativität. Hier kann man Kreativitätstechniken sinnvoll einsetzen, wie z. B. Brainstorming. Kreativitätstechniken sind besonders geeignet für Projekte, die für das Unternehmen vollkommen neu sind. • Erfahrungen. Neben den eigenen Erfahrungen des Projektteams werden diese meist in Form von Checklisten und Datenbanken zusammengefasst und stehen dem Projektteam so zur Verfügung. Auch Expertenbefragungen stellen eine Auswertung von Erfahrungen dar. In jedem Projekt tauchen neue Risiken auf. Typische Projektrisiken sind Gefahrenquellen, die besonders häufig und unabhängig vom Projekttyp zu beobachten sind. Hier eine kurze Auswahl immer wiederkehrender Risiken: • Unklare Zieldefinition. • Ausfall von wichtigen Mitarbeitern während der Projektabwicklung durch Krankheit, Kündigung oder unvorhersehbare Unabkömmlichkeit.

13.6 Projektmanagement

397

• Zugesagte Termine werden nicht eingehalten. • Fehlende Akzeptanz bei den potenziellen Nutzern des Produkts – ein Beispiel für ein wirtschaftliches Risiko. • Einsatz von noch nicht ausgereifter Technik unter dem Druck des Wettbewerbs. • Zu optimistische Planung. • Verzögerung aufgrund unklarer Definition der Projektrollen und daraus resultierender Kompetenzkonflikte. • Konflikte zwischen den Teammitgliedern. • Widerstand im Unternehmen gegen das Projekt.

13.6.9.2  Risikoanalyse und Risikobewertung Nach der Identifikation müssen die einzelnen Risiken auf ihre Ursachen untersucht werden. Nur aus der Kenntnis der Ursachen heraus kann der Projektleiter geeignete Gegenmaßnahmen entwickeln und Rückschlüsse auf die Eintrittswahrscheinlichkeit eines Risikos ziehen. Die Ursachenanalyse erleichtert zudem die Ableitung von Indikatoren, die ein frühzeitiges Erkennen von drohenden Abweichungen erlauben. Danach müssen die Risiken auf ihre Wirkung untersucht werden. Für eine Klassifizierung von Risiken sind sowohl die Ursachen als auch die Auswirkungen erforderlich. Die Bewertung von Risiken ist Voraussetzung für eine Einteilung in Risikoklassen. Diese Klassifizierung wiederum ist die Basis einer effizienten und wirtschaftlichen Risikopolitik im Projekt. Der Einsatz von Maßnahmen ist nicht umsonst, deshalb ist auch eine Kosten-­ Nutzen-­Abschätzung vorzunehmen. Die wirtschaftliche Mittelverwendung setzt voraus, dass der Nutzen die Kosten übersteigt. Die Risiken lassen sich daher anhand zweier Eigenschaften bewerten: • Eintrittswahrscheinlichkeit, und • Auswirkung bei Eintritt. Aus Eintrittswahrscheinlichkeit und Auswirkungen bei Eintritt des Risikos lässt sich dann das finanzielle Risiko (Risikopotenzial) in Form von Mehraufwendungen errechnen. Sind die Risiken einer Berechnung zugänglich, ergeben sich daraus Anhaltspunkte für die angemessenen Kosten der durchzuführenden Maßnahmen. Diese Berechenbarkeit ist nur gegeben, wenn sich sowohl Eintrittswahrscheinlichkeit als auch Auswirkungen genau angeben lassen und die Wirkungen zudem monetär bestimmt werden können. Dies ist in den meisten Fällen aber nicht der Fall. Deshalb wird meist lediglich eine Einteilung in Klassen vorgenommen: • Eintrittswahrscheinlichkeit (hoch, mittel, niedrig), und • Auswirkungen (unbedeutend, mittel, katastrophal). Entsprechend der Bewertung von Eintrittswahrscheinlichkeit und Auswirkungen kann der Projektleiter die Risiken in Stufen einteilen. Diese Einteilung in Stufen erfolgt zu-

398 Abb. 13.26 Beispielhafte Risikobewertungsmatrix

13  Phasenmodelle in der Softwareentwicklung

Eintrittswahrscheinlichkeit hoch

II

II

I

mittel

III

II

I

niedrig

III

III

II

unbedeutend

mittel

katastrophal

Auswirkung

meist auf der Basis einer Risikobewertungsmatrix (s. Abb. 13.26). Dabei muss aber berücksichtigt werden, dass die Risikobewertungsmatrix, die Stufenzuteilung in der Matrix und die Definition der Stufen unternehmens- und projektspezifisch sind. Folgende Stufen sind beispielhaft zu obiger Matrix sinnvoll: • Stufe I. Risiken gefährden akut das Projekt und können sogar zum Abbruch des Projekts führen; eine Neuplanung ist ggf. erforderlich. • Stufe II. Risiken können umfangreiche Planänderungen erfordern. • Stufe III. Risiken erfordern lediglich kleinere Plankorrekturen.

13.6.9.3  Risikohandhabung Die Maßnahmen zur Beherrschung von Risiken können entweder die Eintrittswahrscheinlichkeit reduzieren oder die Auswirkungen bei Eintreten eines Risikos mindern. Es sind sowohl Präventiv- als auch Korrektiv-Maßnahmen (Notfallplanung) möglich. Zunächst einmal lassen sich generelle Maßnahmen unterscheiden: • Risikomeidung. Die Risikomeidung ist ein Extremfall, denn sie bedeutet den Verzicht auf das Projekt. Ein Projekt ohne jedes Risiko wird es nicht geben. Die Risikomeidung ist lediglich dann eine reale Alternative, wenn die Risikolage des Projekts so ungünstig ist, dass sie für das Unternehmen existenzbedrohend ist und die Kosten der Risikobewältigung unverhältnismäßig hoch sind. • Risikominderung. Die Risikominderung vermindert entweder die Gefahr der Zielabweichung (die der Eintrittswahrscheinlichkeit) oder die Schadenshöhe (die Auswirkungen). Dies ist der Bereich der klassischen Risikobewältigung im Projektmanagement.

13.6 Projektmanagement

399

• Risikoteilung. Die Teilung von Risiken ist ein wichtiger Aspekt, wenn Konsortien oder Arbeitsgemeinschaften ein Projekt durchführen. Die Zusammenarbeit großer Unternehmen bei Entwicklungsprojekten ist ein typischer Fall von Risikoteilung. Das Risiko erscheint für ein Unternehmen zu groß, durch Zusammenarbeit mit anderen werden die Risiken auf mehrere Schultern verteilt. • Risikoüberwälzung. Ein Haftungsausschluss stellt die Überwälzung von Risiken dar. Auch die Etablierung von sog. Systemzulieferern ist eine Maßnahme der Risikoüberwälzung. Hier werden die Entwicklungsrisiken (aber auch die Chancen) auf die Zulieferer überwälzt. Zur Risikoüberwälzung auf Kunden, Partner oder Lieferanten ist meistens ein Mindestmaß an Marktmacht erforderlich. • Schadenkostenüberwälzung. Hier wird nicht das Risiko des Projekts überwälzt, sondern die finanziellen Folgen des Risikos. Klassisches Instrument der Schadenkostenüberwälzung ist die Versicherung. So wird etwa bei einer Feuerversicherung nicht das Risiko eines Brandes vermindert, sondern die finanziellen Schäden auf die Versicherung überwälzt. • Reservenbildung. Der Aufbau von finanziellen Reserven ändert (isoliert betrachtet) das Projektrisiko zunächst nicht. Es wird weder die Eintrittswahrscheinlichkeit von Projektrisiken vermindert noch die Auswirkungen nach Eintritt. Die Risiken werden selbst getragen. Daneben sind auch der Aufbau und die Bereitstellung von sachlichen Reserven möglich.

13.6.9.4  Risikoüberwachung Zur Risikoüberwachung sollte der Projektleiter bereits bei der Planung eine Liste mit den zehn bedeutendsten Risiken aufstellen und während des Projekts regelmäßig aktualisieren. Die eingehende Beschäftigung mit den das Projekt bedrohenden Risiken schärft das Risikobewusstsein und verkürzt die Reaktionszeit beim tatsächlichen Eintreten eines Risikos erheblich.

13.6.10  Nachforderungsmanagement Das Nachforderungsmanagement (Claim Management) beschäftigt sich damit, wie Ansprüche an den Vertragspartner durchgesetzt bzw. abgewehrt werden, die sich aus Abweichungen von den vertraglichen Vereinbarungen ergeben. Speziell im Bereich der IS ist die Behandlung von berechtigten und unberechtigten Nachforderungen ein problematischer Punkt, da in der Vergangenheit zahlreiche Projekte aufgrund falsch behandelter Nachforderungen gescheitert sind (Yourdon 1997). Der Projektleiter sollte bestrebt sein, dass die Änderungswünsche des Auftraggebers vergütet werden. Daher dürfen Änderungswünsche nicht nur als Störungen des Projektablaufs betrachtet werden, sondern müssen als Instrument zur Verbesserung der Wirtschaftlichkeit eines Projekts genutzt werden. Es gilt aber auch, unberechtigte Forderungen

400

13  Phasenmodelle in der Softwareentwicklung

abzuwehren. Die Grundlage eines angemessenen Nachforderungsmanagements ist ein gutes Pflichtenheft und die Dokumentation aller Abweichungen vom Pflichtenheft. Dazu gehören die Änderungsanträge, der Grund, der Antragsteller sowie die Konsequenzen (Kosten und Termine). Die folgende Checkliste für das Nachforderungsmanagement soll beitragen, Nachforderungen angemessen zu behandeln: • • • • • • • • • •

Der Projektstart wird mit dem gesamten Projektteam durchgeführt. Es werden immer wieder Kurzinformationen über den Vertrag zur Verfügung gestellt. Es existieren Checklisten über typische Nachforderungssituationen. Es werden Vereinbarungen über das Vorgehen in Situationen, in denen Änderungsanträge aufkommen, getroffen. Es wird fortlaufend das Verhalten der Vertragspartner auf sich anbahnende Nachforderungen analysiert. Alle Änderungen, Schadensfälle, Garantiefälle usw. werden fortlaufend dokumentiert. Relevante Sitzungen werden dokumentiert. Es werden Projekttagebücher geführt. Relevante Telefongespräche werden dokumentiert. Anweisungen, Entscheidungen, Änderungen und wichtige Unterlagen sind schriftlich zu bestätigen.

Die häufigsten Fehler beim Nachforderungsmanagement sind entweder eine zu aggressive Verhandlungsführung bei Nachforderungen gegen Partner mit langen und ausgesprochen guten Geschäftsbeziehungen. Auf der anderen Seite wird oftmals eine zu nachgiebige Haltung bei berechtigten Ansprüchen auf Vergütung von Nachforderungen gezeigt, d. h. Leistungen werden erbracht, ohne dass Nachforderungen aufgenommen und verhandelt werden. Vielfach werden aufkommende Nachforderungen unzureichend dokumentiert.

13.7 Qualitätsmanagement Der Qualitätsbegriff ist zunächst unabhängig von Software oder einem IS wie folgt zu definieren. cc Qualität  Gemäß der Norm DIN EN ISO 9000:2015 wird Qualität als derjenige Grad bezeichnet, in dem ein Satz inhärenter Merkmale eines Objekts Anforderungen erfüllt. Die Anforderungen an das zu entwickelnde bzw. einzuführende IS werden im Laufe des Entwicklungsprojekts ergänzt und verfeinert. Die Aufgabe des Qualitätsmanagements besteht darin, die Erfüllung dieser Anforderungen zu überprüfen. Speziell für Softwarekomponenten von IS gelten neben den fachlichen Anforderungen auch die folgenden generellen Qualitätsmerkmale:

13.7 Qualitätsmanagement

401

• Unmittelbare Gebrauchsfähigkeit. Die Komponente muss sowohl für Benutzer wie auch für Administratoren akzeptabel sein. Benutzer akzeptieren eine ­Softwarekomponente, wenn sie benutzerfreundlich ist, d. h. eine verständliche und übersichtliche Oberfläche sowie effiziente und nachvollziehbare Dialogabläufe hat, Hilfefunktionen anbietet (z. B. Eingabehilfe, Fehlerhilfe), und vor allem schnelle Antwortzeiten bietet. • Zuverlässigkeit. Die Komponente muss darüber hinaus zuverlässig sein, also korrekt arbeiten, robust sein und den Datenschutz gewährleisten. Administratoren akzeptieren eine Softwarekomponente, wenn sie die Integrität des Gesamtsystems nicht gefährdet, geeignete Maßnahmen für die Datensicherheit und die Wiederherstellung bestimmter Zustände/Ergebnisse trifft und vor allem effizient mit den verfügbaren Ressourcen umgeht. • Zukünftige Gebrauchsfähigkeit. Wie gut sich die unmittelbare Gebrauchsfähigkeit auch in Zukunft aufrechterhalten lässt, richtet sich allgemein nach der Allgemeingültigkeit der Problemlösung, ihrer Wiederverwendbarkeit und vor allem ihrer Portabilität, d. h. Übertragbarkeit auf andere Rechner- bzw. Systemplattformen. Natürlich soll eine Softwarekomponente wartungsfreundlich sein, d. h. für andere Entwickler verständlich sein (Transparenz), Änderungen/Reparaturen nicht erschweren, anpassungsfähig und erweiterbar sein. Dazu zählt auch ein systematisch durchführbarer und wiederholbarer Test der Komponente. Neben diesen eher technischen Qualitätsmerkmalen ist sicherzustellen, dass eine Softwarekomponente wirtschaftlich ist (d. h. höheren Nutzen stiftet als Kosten verursacht), revisionsfähig ist (d.  h. dokumentierte, nachvollziehbare Abläufe realisiert) und natürlich ausreichend dokumentiert ist, sodass Management, Entwickler, Administratoren, Revisoren und Benutzer die unterstützten Abläufe erschließen und nachvollziehen können. Die Qualität von Software wird durch eine Vielzahl von Normen und Standards geregelt (Bons und Salmann 1992). Neben allgemeinen Begriffs- und Prozessnormen (z. B. Normen der ISO 9000er-Reihe) und technischen Normen für Datenaustausch und Portabilität gibt es z. B. Normen für die Dokumentation (z. B. IEEE 829, ISO/IEC/IEEE 29119), für die Spezifikation von Anforderungen (z. B. IEEE 830), für allgemeine Produkteigenschaften (z. B. DIN 66285 für Standardsoftware) und für einzelne Fachgebiete (z. B. „Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme“ (BMF 1995)). Auch wenn es sich nicht um eine Norm im engeren Sinne handelt, sind hier auch die Grundsätze ordnungsmäßiger Modellierung (GoM) zu nennen, die Qualitätskriterien für die fachliche Modellierung definieren (Becker et al. 1995). Die Sicherung der Qualität von Software ist eine Querschnittsaufgabe, die nahezu sämtliche Phasen des Softwareentwicklungsprozesses betrifft. Zu diesen Aufgaben gehört beispielsweise die systematische Handhabung von Fehlern (Fehlermanagement), die im Test- oder Produktivbetrieb auftreten, oder aber die Sicherung der Betriebsbereitschaft von Softwareprodukten.

402

13  Phasenmodelle in der Softwareentwicklung

13.8 Konfigurationsmanagement Das Konfigurationsmanagement (KM) ist „eine Managementdisziplin, die organisatorische und verhaltensmäßige Regeln auf den Produktlebenslauf einer Konfigurationseinheit von ihrer Entwicklung über Herstellung und Betreuung anwendet.“ (DIN 10007 2003). Das Ziel des Konfigurationsmanagements besteht darin sicherzustellen, dass ein Produkt bezüglich seiner funktionalen wie auch äußeren Merkmale jederzeit eindeutig identifizierbar ist. Diese Identifikation dient der systematischen Kontrolle von Änderungen und zur Sicherstellung der Integrität auch während der Nutzung des Produkts. cc Konfigurationseinheit  Eine Konfigurationseinheit meint eine beliebige Kombination aus Hardware, Software oder Dienstleistung im Zusammenhang mit einem IS. Das Konfigurationsmanagement überwacht die Konfigurationen während der gesamten Entwicklung, sodass die Zusammenhänge und Unterschiede zwischen früheren Konfigurationen und den aktuellen Konfigurationen jederzeit erkennbar sind. Auf diese Weise können beispielsweise auch Abweichungen von den Anforderungen und dem Entwurf des IS erkannt werden. Das Konfigurationsmanagement stellt außerdem sicher, dass jederzeit auf vorausgegangene Versionen zurückgegriffen werden kann. Dadurch sind Änderungen nachvollziehbar und überprüfbar. Konfigurationen sind verschiedene Ausprägungen desselben IS (z. B. lauffähiges Gesamtsystem). Dieses wird aus Versionen von Komponenten zusammengestellt für: • • • •

Eine bestimmte Systemsoftware, eine bestimmte Hardware, eine bestimmte Arbeitsumgebung, und einen bestimmten Leistungsumfang.

Dabei müssen folgende Probleme bei der Verwaltung von Komponenten berücksichtigt werden: • Mehrfachverwendung von Komponenten, • Abhängigkeiten zwischen den Komponenten, oder • unterschiedliche Zugriffsrechte auf die Komponenten. Aus diesen Gründen ist bei größeren Projekten die Unterstützung durch eine entsprechende Software (CASE-Werkzeuge, s. Abschn.  13.1 und Glossar) für die Verwaltung nötig.

Individualentwicklung von Software

14

Zusammenfassung

Dieses Kapitel beschreibt das systematische Vorgehen bei der Individualentwicklung von Software. Dies umfasst die Methoden in Analyse, Entwurf, Implementierung und Test von Software. Hierbei liegt der Schwerpunkt bei der objektorientierten Softwareentwicklung und den unterschiedlichen statischen und dynamischen Modellen, die UML anbietet.

14.1 Objektorientierte Softwareentwicklung Aus der Sicht der Softwareentwicklung sind die funktionalen und technischen Anforderungen, wie sie Anwender fordern, der Ausgangspunkt für die Gestaltung eines Softwaresystems. Auf die Aufgaben der Anforderungsanalyse geht Abschn.  13.4 ein. In diesem Abschnitt liegt der Schwerpunkt auf der Dokumentation, Verfeinerung und Umsetzung des gewünschten Systemverhaltens. Bereits Ende der 70er-Jahre sind Methoden für die Softwareentwicklung entstanden, die sich zwar in der Notation und im Umfang abgedeckter Phasen bzw. Sichten leicht unterschieden, aber in Bezug auf wesentliche Eigenschaften wie schrittweise Verfeinerung, Abstraktion von Realisierungsrestriktionen und Fokus auf die Funktionssicht vergleichbar sind. Wichtigste Vertreter dieser sog. Strukturierten Analyse (SA) sind (Gane und Sarson 1977; DeMarco 1979; McMenamin und Palmer 1988) und (Yourdon 1989). Ein vergleichbarer, wenn auch wesentlich weitergehender Ansatz ist die Structured Analysis and Design Technique (SADT) (Ross 1977). Die Strukturierte Analyse geht auf eine Zeit zurück, als Dateiverarbeitung und prozedurale Programmierung die Implementierung dominierten. Auch wenn sie Implementierungsunabhängigkeit anstrebt, führt die Konzentration auf die Funktionssicht, die

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_14

403

404

14  Individualentwicklung von Software

­ rozedurale Spezifikation von Funktionen und die isolierte Betrachtung von Datenflüssen p dazu, dass die Strukturierte Analyse in den letzten Jahren ihre Bedeutung verloren hat. Sie wird daher hier nicht weiter vorgestellt. Die Trennung zwischen (hierarchisch verfeinerter) Ablaufbeschreibung und (flacher) Beschreibung der Informationsstrukturen in den frühen Ansätzen zur Entwicklung von IS ist manchmal künstlich. Dies ist dadurch bedingt, dass sich entsprechende Modelle auf einen Teilaspekt konzentrieren, um eine zu hohe Komplexität zu vermeiden. Eines der Hauptprobleme in diesem Ansatz besteht also darin, die verschiedenen Beschreibungsmethoden und -modelle zu integrieren bzw. Inkompatibilitäten zu erkennen und zu beseitigen. Sinnvoller ist es, von vornherein strukturelle und verhaltensmäßige Aspekte gemeinsam zu modellieren. Dies ist das Ziel der objektorientierten Softwareentwicklung. Die objektorientierte Softwareentwicklung hat seit den 90er-Jahren zunehmend an Bedeutung gewonnen. Hierbei waren neue Konzepte in der Programmierung der Ausgangspunkt. Historische Vorreiter waren die Programmiersprachen SIMULA und SMALLTALK. Die Norweger Nygaard, Myhrhaug und Dahl (Rohlfing 1973) hatten in den 70er-Jahren Konzepte zur Bildung von Klassen in ihre Simulationssprache SIMULA eingeführt. Diese Klassenkonzepte ermöglichen es, Verhalten als Funktionen und Daten als Attribute gemeinsam für eine Anzahl gleichartiger Objekte zu definieren und zu verwenden. Kay und Goldberg (Goldberg und Robson 1983) haben diese Konzepte aufgenommen und verfeinert und mit der objektorientierten Programmiersprache SMALLTALK die Art und Weise zu programmieren neu definiert. Im Mittelpunkt der Programmierung stehen die Objekte, deren Verhalten und Datenstruktur in so genannten Klassen zusammengefasst und definiert werden. In SMALLTALK existieren bereits viele vordefinierte Klassen, deren Funktionalität genutzt bzw. mittels Vererbung an selbst entwickelte Klassen weitergegeben werden kann. Vererbung und damit Wiederverwendung waren die Konzepte, die zur Integration der Objektorientierung in den gesamten Entwicklungszyklus geführt haben. Die Wiederverwendung von Softwarekomponenten in Form von Klassen kann die Qualität von Software erhöhen und die Kosten reduzieren. Damit werden zwei wesentliche Problempunkte in der Softwareentwicklung angesprochen. In den 80er und Anfang der 90er-Jahre sind unterschiedliche Ansätze entstanden, um Objektorientierung im Entwurf und in der Analyse mit zu berücksichtigen. Das Ziel war es, Software in einem ganzheitlichen Ansatz (von der Analyse bis zur Programmierung) objektorientiert zu entwickeln. Dies führte zu einer Vielzahl von Methoden und Notationen (z. B. (Booch 1991; Rumbaugh et al. 1991; Jacobsen 1996)), die erst durch die Entwicklung von UML (Unified Modeling Language) bereinigt und auf einen einheitlichen Stand gebracht wurden. 1997 hat die OMG (Object Management Group) und 2004 die ISO (ISO/IEC 19501) UML zum Standard für die objektorientierte Analyse und den objektorientierten Entwurf erklärt. Aktueller Stand der UML-­Spezifikation ist die Version 2.5.1 (OMG 2017) (s. Abschn. 9.4).

14.2  Vorgehen bei der objektorientierten Softwareentwicklung

405

14.2 Vorgehen bei der objektorientierten Softwareentwicklung Das Ziel der objektorientierten Entwicklung ist es, reale Handlungsabläufe in ein Softwaremodell zu übertragen. Sie fasst dazu die Realität als objektorientiertes System auf und ersetzt reale Objekte durch passende Modellobjekte. Diese Modellobjekte übernehmen die Modellhandlungen. Daher ist es eine Kernaufgabe der Analyse, diese Objekte zu identifizieren und ein geeignetes Modell zu schaffen (Larman 1998). Ein (Anwendungs-) System, das den Prinzipien der objektorientierten Entwicklung folgt, besteht aus einer Menge von Objekten, die sich gegenseitig Nachrichten schicken. Der Empfang einer Nachricht löst dann eine Operation bei dem empfangenden Objekt aus. Objekte in der realen Welt können vielerlei Dinge sein, wie z. B. physische oder fassbare Objekte (Buch, Produkt, Maschine), Personen (Kunde, Mitarbeiter, Lieferant), Entwürfe oder Beschreibungen von Dingen, Orte (Städte, Fabrikstandorte), Transaktionen (Lieferung, Überweisung, Zahlung), Elemente von Transaktionen (Lieferposition, Zahlungsposten), Rollen von Personen (Buchhalter, Rezeptionist, Sekretärin). In der objektorientierten Entwicklung besitzt ein Objekt einen Zustand, beschrieben durch eine Anzahl von Attributen und ihre aktuellen Werte. Jedes Objekt hat ein Verhalten, das eine Anzahl von Operationen (auch als Methoden bezeichnet) charakterisiert. Jedes Objekt erhält eine Identität, die es von allen anderen Objekten unterscheidet. Dadurch unterscheiden sich sämtliche Objekte aufgrund ihres Bestehens voneinander, auch wenn sie die gleichen Attributwerte haben. Ein Objekt kann ein oder mehrere andere Objekte kennen. Dies wird durch Beziehungen (Assoziationen) ausgedrückt. Objekte mit gleicher Struktur, gleichem Verhalten und gleichen Beziehungen, aber unterschiedlichen Attributwerten, werden in einer Klasse ­zusammengefasst. Aus einer Klasse und deren Beschreibung können neue Objekte erzeugt (Instance Creation) werden. Abb. 14.1 zeigt eine vereinfachte Spezifikation der Klasse „Kunde“ sowie drei Objekte dieser Klasse. Jedes Objekt hat Werte für seine Attribute „Kundennummer“, „Name“, „PLZ“, „Ort“ und „Straße“. Für alle Objekte der Klasse „Kunde“ sind die Operationen „PrüfeStatus“, „AddiereZuUmsatz“ und „BestimmeRabattSatz“ definiert, d.  h. nur über diese Operationen sind die (internen) Daten der Klasse überhaupt erfassbar und auswertbar. cc Objekt  Ein Objekt ist eine eindeutig identifizierbare Instanz einer Klasse. Objekte sind Aggregate aus lokalen Daten und lokalen Operationen, deren interne Strukturen nach außen nicht transparent sind. Lediglich als öffentlich deklarierte Operationen können über eine entsprechende Schnittstelle ausgelöst werden und auf lokale Daten und lokale Operationen zugreifen. Objekte kommunizieren miteinander durch Austausch („das Senden“) von Nachrichten. Diese Nachrichten entsprechen dem Aufruf der als öffentlich dekla­ rierten Operationen.

406

14  Individualentwicklung von Software Müller : Kunde

Namensfeld

Kunde Attribute

Methoden

-Kundennummer : Integer -Name : String -PLZ : Integer -Ort : String -Straße : String +PrüfeStatus() : Boolean +AddiereZuUmsatz() +BestimmeRabattSatz() : int

Kundennummer : Integer = 12328 Name : String = Müller PLZ : Integer = 13353 Ort : String = Berlin Straße : String = Luxemburger Straße 10 Schmitz : Kunde Kundennummer : Integer = 12329 Name : String = Schmitz PLZ : Integer = 31134 Ort : String = Hildesheim Straße : String = Domhof 15 Meyer : Kunde Kundennummer : Integer = 12330 Name : String = Meyer PLZ : Integer = 40104 Ort : String = Düsseldorf Straße : String = Ringstraße 150

Abb. 14.1  Klasse Kunde mit den Objekten Meyer, Schmitz und Müller

Klassen fassen zwar wie Entitätstypen gleichartige Objekte zusammen, haben aber im Gegensatz zur konzeptionellen Datenmodellierung (s. Abschn. 9.5) nicht nur (allen Objekten gemeinsame) Attribute, sondern auch (auf alle Objekte anwendbare) Operationen (auch als Methoden bezeichnet). Eine wesentliche Aufgabe der objektorientierten Analyse ist die Identifikation von Klassen, d. h. von gleichartig strukturierten und gleichartig verarbeitbaren Objekten. Daten dienen dabei nicht nur als Vorlage des Entwurfs von Ein- und Ausgabefunktionen, sondern werden durch die mit ihnen verbundenen Methoden zu vollwertigen Komponenten der Softwareentwicklung erweitert. Die wichtigsten Prinzipien der Objektorientierung sind: • Kapselung. Die Daten eines Objekts sind so eng mit seinen Funktionen verbunden, dass sie nach außen hin nur gemeinsam (d. h. als Ein- oder Ausgabedaten einer Operation) sichtbar werden. Die interne Struktur der Daten bleibt nach außen genauso wie alle nicht als „öffentlich“ deklarierten Funktionen verborgen. • Vererbung. Klassen sind durch Generalisierungsbeziehungen miteinander verbunden. Spezielle Klassen erben die Eigenschaften (z. B. Funktionen, Schnittstellen) ihrer übergeordneten Klasse. Sie ergänzen und/oder ersetzen diese generellen Eigenschaften durch speziellere oder zusätzliche Eigenschaften. Hierbei spricht man speziell auch von Polymorphie, wenn verschiedene Unterklassen dieselbe Botschaft verstehen, obwohl die technische Umsetzung der Reaktion auf diese Botschaft völlig unterschiedlich sein kann. • Wiederverwendung. Objektorientierte Anwendungen werden nicht auf der Basis einer zentralen Struktur (z. B. Hauptprogramm) entworfen und realisiert. Vielmehr werden sie auf der Grundlage wieder verwendbarer Klassendefinitionen zusammengesetzt.

14.3  Methoden für die Analyse

407

Wie bei Produktvarianten, die aus Komponenten zusammengesetzt werden, wird dadurch eine hohe Flexibilität mit einfacher Erweiterbarkeit verbunden. Generell ist die objektorientierte Systementwicklung nicht an ein bestimmtes Phasenmodell gebunden. Iterative, inkrementelle Phasenmodelle eignen sich jedoch besser für die objektorientierte Systementwicklung als ein lineares Phasenmodell, da sie die Wiederverwendung eher berücksichtigen können. Nach der maßgeblichen Mitarbeit an UML hat die Firma Rational (jetzt Teil von IBM) 1999 ein eigenes Phasenmodell, den Unified Process, speziell für die objektorientierte Systementwicklung konzipiert. Der Rational Unified Process (RUP) benutzt UML. Der RUP ist ein inkrementelles und iteratives Phasenmodell. Jede Iteration besteht aus den Arbeitsschritten Anforderung, Analyse, Entwurf, Implementierung und Test. Phasen (Beginn, Ausarbeitung, Konstruktion und Umsetzung) fassen dabei die verschiedenen Iterationen zusammen. Wie in der objektorientierten Systementwicklung üblich, spielen Anwendungsfälle in dem gesamten Phasenmodell eine zentrale Rolle. Rational bezeichnet den RUP daher auch als anwendungsfallgesteuert. Der RUP ist ein schwergewichtiges Phasenmodell (s. Abschn. 13.5.1) mit einer Vielzahl unterschiedlicher Dokumente. IBM vertreibt für den RUP eine darauf abgestimmte Entwicklungsumgebung, welche die Phasen sowie Bearbeiterrollen unterstützt und eine Vielzahl von Schablonen für die Generierung der Dokumente bietet.

14.3 Methoden für die Analyse Der Kern der objektorientierten Analyse ist es, die Problemwelt aus der Sicht der Objekte, die in der realen Welt relevant sind, zu betrachten.

14.3.1 Anwendungsfallgesteuerte Analyse Als Ausgangspunkt für die objektorientierte Analyse schlagen die meisten Phasenmodelle die Konstruktion von Anwendungsfalldiagrammen vor. Dieses Vorgehen wird auch als anwendungsfallgesteuerte Analyse bezeichnet. Die Anwendungsfälle dienen dazu, bereits verbal im Fachkonzept erfasste Nutzeranforderungen grafisch zu visualisieren und die Anwendungsfälle und damit auch die Anforderungen in Workshops zu verifizieren. Sie sind auch der Ausgangspunkt für die dynamischen und statischen Modelle in der Analyse. Ein Anwendungsfalldiagramm (s. Abschn.  9.4) beschreibt die Sicht auf das System, wie es sich vom Verhalten her dem außen stehenden Nutzer darstellt. Es unterteilt das System funktional in Transaktionen oder auch Anwendungsfälle (Use Cases). Mit diesen Anwendungsfällen sind die Akteure (Actors), welche an dem Anwendungsfall beteiligt sind, verbunden (s. Abb. 14.2). Ein Anwendungsfall beschreibt in einer Sequenz von Ereignissen, wie die Akteure das System zur Durchführung einer Aufgabe einsetzen. Ein

408

14  Individualentwicklung von Software

Auftragsmanagement-System Prüfe die Warenverfügbarkeit

Erzeuge neuen Auftrag Kunde

Verkäufer

Prüfe Auftragsstatus

Erstelle Lieferung

Bestätige Auslieferung Lieferant

Abb. 14.2  Ausschnitt aus dem Anwendungsfalldiagramm „Auftragsmanagement-System“

­ nwendungsfalldiagramm zeigt Anwendungsfälle, Akteure und deren Beziehungen. BeA gleitende Texte können die Anwendungsfall-Interna ergänzen. Die Detaillierung der Beschreibung von Anwendungsfällen kann variieren. Oftmals ist der Ablauf der einzelnen Anwendungsfälle detailliert in Form konkreter Szenarien (Szenario 1: „Auftrag von existierendem Kunden“, Szenario 2: „Auftrag von einem Neukunden“) spezifiziert. Ebenso können Formulare für die einzelnen Anwendungsfälle (Larman 1998; Maciaszek und Liong 2004; Balzert 1999) den Systemanalytiker und den Nutzer dabei unterstützen, die einzelnen Anwendungsfälle in ihrer Komplexität zu erfassen. Wichtige Elemente solcher Formulare zur Beschreibung von Anwendungsfällen sind (Larman 1998; Balzert 1999): • • • • • • • •

Verweis auf den Anwendungsfall im Diagramm, Verweis auf Anforderungen im Fachkonzept, Vorbedingung zur Durchführung des Anwendungsfalls, Nachbedingung: Was für Auswirkungen hatte der Anwendungsfall auf das Softwaresystem, Akteure, auslösendes Ereignis, Kurzbeschreibung, und Ablauf, ggf. als Dialog zwischen Akteur und Software.

14.3  Methoden für die Analyse

409

Die detaillierte Beschreibung von Anwendungsfällen ist hilfreich und notwendig, um das Verhalten der Software in entsprechenden Diagrammen (wie z. B. Sequenz-, Kommunikations- und/oder Aktivitätsdiagrammen) beschreiben zu können. Diese Beschreibungen helfen auch, die wesentlichen Klassen des Klassendiagramms (statisches Modell) zu identifizieren.

14.3.2 Klassendiagramme in der Analyse Ausgehend von den verbalen Anforderungen des fachlichen Konzepts und den vorliegenden detaillierten Anwendungsfällen ist das Klassendiagramm (s. Abschn. 9.4) als zentrales Element der objektorientierten Softwareentwicklung zu spezifizieren. Basierend auf Larman (1998) und Balzert (1999) sind zu seiner Erstellung sechs Schritte durchzuführen: • • • • • •

Klassen identifizieren, Assoziationen identifizieren, Attribute identifizieren, Vererbungsstrukturen identifizieren, Assoziationen verfeinern, und Attribute spezifizieren.

Die Identifikation von Objekten, die Klassifikation dieser Objekte zu Objekttypen (Klassen) und der Aufbau der Beziehungen zwischen Klassen hat große Ähnlichkeit mit der konzeptionellen Datenmodellierung (s. Abschn. 9.5). Die objektorientierte Analyse sieht neben der Generalisierung von vornherein auch Aggregation und Referenzierungs- bzw. Verwendungsbeziehungen vor. Diese Beziehungsarten fehlen in den meisten traditionellen semantischen Datenmodellen. Als Kern des gesamten objektorientierten Ansatzes sind nachfolgend einige wichtige Elemente der Klassendiagramme ausgeführt. Zunächst erfolgt die Verfeinerung des Klassendiagramms und besonders die Zuordnung von Verantwortlichkeiten in Form von Operationen im Entwurf. Wenn zwei Klassen durch eine Generalisierungsbeziehung verbunden sind, so lassen sich Daten und Methoden des generellen Objekttyps auf den speziellen Objekttyp vererben. Die Beziehung heißt deshalb Vererbung. Klassen sind grafisch als Rechtecke dargestellt, deren Segmente neben der Klassenbezeichnung auch Attribute und Operationen enthalten. Kanten visualisieren Klassenbeziehungen, wobei ein Dreieck die Vererbung darstellt. Das Vererbungsprinzip ist für die objektorientierte Softwareentwicklung besonders wichtig, da Vererbung ein inhärenter Teil der Entwicklungsphilosophie („Nutze vorhandene Klassen, um die Software zu entwickeln“) ist, und die Basis für die Wiederverwendung bildet (s. Abb. 14.3). Wenn zwei Objekttypen durch eine Aggregation verbunden sind, so lassen sich Daten des aggregierten Typs aus Daten des detaillierten Typs (z. B. durch Zählung, Zusammenfassung, Summen- oder Durchschnittsbildung) ableiten. Man unterscheidet hier noch

14  Individualentwicklung von Software

410 Zahlung

-Betrag : Short -Datum : Date

Kreditkartenzahlung -Kreditkarte : Single -Kartennummer : String

Barzahlung

Bankeinzug -Bankleitzahl : String -Kontonummer : String

Abb. 14.3  Klassendiagramm mit Vererbung

Auftrag

Auftragsposition

-Datum : Date -Gesamtsumme : Short

-Bestellmenge : Integer -Liefermenge : Integer

Abb. 14.4 Komposition

feiner nach Aggregation und Komposition. Aggregation ist eine Art von Beziehung, die genutzt wird, um eine Teil-Ganzes-Beziehung auszudrücken. Eine ungefüllte Raute stellt die Aggregation dar. Die Aggregation ist nichts anderes als eine abkürzende Schreibweise der Beziehung „Besteht aus“ und „Ist Teil von“. Eine Komposition (ausgefüllte Raute) ist eine stärkere Form der Aggregation, die bedeutet, dass Teile und Ganzes eine Einheit bilden, deren Auflösung die Zerstörung des Ganzen nach sich zieht (s. Abb. 14.4). Wenn zwei Objekttypen durch eine Referenzierungsbeziehung verbunden sind, die weder eine Generalisierung noch eine Aggregation ist, so spricht man von einer Assoziation (s. Abb. 14.5). Da im Normalfall die Existenz der Objekte der referenzierenden Klasse von der Existenz der referenzierten Objekte abhängig ist, können sich daher Löschungen, ggf. auch Erzeugungen, fortpflanzen (propagieren). Abb. 14.6 zeigt ein vereinfachtes Klassendiagramm, das neben den strukturellen Aspekten des abgebildeten Realitätsausschnitts auch einige funktionale Aspekte darstellt. Die (Min,Max)-Notation (s. Abschn.  9.5) moderner semantischer Datenmodelle findet sich in UML in Form von Min..Max wieder. Sowohl Klassenbeziehungen als auch die Rollen der einzelnen Klassen in einer Beziehung können, müssen aber nicht benannt werden.

14.3  Methoden für die Analyse

411

Kunde -Kundennummer : Integer -Name : String -PLZ : Integer -Ort : String -Straße : String +PrüfeStatus() : Boolean +AddiereZuUmsatz() +BestimmeRabattSatz() : int

Auftrag

erteilt 0..*

1

-Datum : Date -Gesamtsumme : Short

Abb. 14.5 Assoziation Kunde -Kundennummer : Integer -Name : String -PLZ : Integer -Ort : String -Straße : String +PrüfeStatus() : Boolean +AddiereZuUmsatz() +BestimmeRabattSatz() : int

erteilt 1

0..*

Auftrag

Auftragsposition

-Datum : Date -Gesamtsumme : Short

-Bestellmenge : Integer -Liefermenge : Integer

1 1 Rechnung -Rechnungsnummer : Integer -Summe : Short -Datum : Date -Bezahlt : Boolean +istBezahlt() : Boolean

Zahlung 1

Kreditkartenzahlung -Kreditkarte : Single -Kartennummer : String

1

-Betrag : Short -Datum : Date

Barzahlung

Bankeinzug -Bankleitzahl : String -Kontonummer : String

Abb. 14.6  Vereinfachtes Klassendiagramm

• Neben den statischen Modellen ist das Verhalten der Software zu spezifizieren. Ein Ausgangspunkt für die Spezifikation des Verhaltens sind die detaillierten Anwendungsfallbeschreibungen und die Beschreibung unterschiedlicher Szenarien. Mit der Umsetzung dieser Beschreibungen in unterschiedliche Verhaltensdiagramme befindet man sich an der Schnittstelle zwischen Analyse und Entwurf. Soweit die Diagramme dazu dienen, die Anforderungen an die Software zu spezifizieren bzw. Abläufe im Unternehmen zu verstehen, sollten die Diagramme in der Analyse erstellt und in das Fachkonzept integriert werden. Sobald man mit den Diagrammen das Softwareverhalten definiert und die Operationen der Klassen festlegt, trifft man technische Entwurfsentscheidungen, die in der nächsten Phase durchgeführt werden sollten. Generell gilt jedoch, dass der Übergang zwischen Analyse und Entwurf und damit zwischen Fachkonzept und IT-Konzept fließend ist. Entsprechend wird dies auch in jedem Unternehmen unterschiedlich umgesetzt.

412

14  Individualentwicklung von Software

Ein Hilfsmittel, um die Abläufe der Szenarien oder detaillierten Beschreibungen der Anwendungsfälle umzusetzen, sind Aktivitätsdiagramme. Sie konkretisieren die Ablaufplanung der Organisationsebene (s. Abschn. 8.3) und ermöglichen es, die Abläufe eines Anwendungsfalls zu visualisieren und Nebenläufigkeit von Aktionen oder bedingte Aktionen darzustellen. Beispielsweise ist in Abb.  14.7 die Reihenfolge, in welcher die Aktionen „Rechnung erstellen“ und „Warenlieferung zusammenstellen“ stattfinden, aus fachlicher Sicht irrelevant, denn beide Aktionen ließen sich auch parallel ausführen. Abb. 14.7 zeigt ein einfaches Aktivitätsdiagramm, das nur einige Notationselemente des umfangreichen Baukastens zum Aktivitätsdiagramm einsetzt. Die Aktivitätsdiagramme wurden zur Version UML 2.0 grundlegend überarbeitet und bieten jetzt Notationselemente, um die Abläufe eines komplexen Anwendungsfalls, eines umfangreichen Geschäftsprozesses oder

Startknoten

Aktivität

Kundendaten aufrufen und aktualisieren

Warenverfügbarkeit prüfen

Kontrollfluss Auftrag bestätigen

Parallelisierungsknoten

Warenlieferung zusammenstellen

Rechnung erstellen

Parallelisierungsknoten

Waren mit Rechnung verschicken

Endeknoten Abb. 14.7  Einfaches Aktivitätsdiagramm

14.4  Methoden für den Entwurf

413

auch die Implementierung einer Operation zu visualisieren. Insbesondere für die abstrakte Beschreibung eines Algorithmus findet man bei den Aktivitätsdiagrammen die notwendigen Notationselemente (Jeckle et al. 2004).

14.4 Methoden für den Entwurf 14.4.1 Objektorientierter Entwurf Das Ziel des objektorientierten Entwurfs ist es, die Analysemodelle soweit zu verfeinern und zu ergänzen, dass sie die Implementierung der geforderten Software erlauben. Hierbei sind die Benutzeroberflächentechnologie, die Programmiersprache, das Datenbanksystem, mögliche Verteilungskonzepte, Komponentenwiederverwendung und vieles mehr zu berücksichtigen (Booch et al. 1999). Insbesondere müssen die Entwurfsmodelle auf einem solchen Niveau sein, sodass die folgende Implementierung eine erkennbare Verfeinerung des Entwurfs darstellt. Eine wichtige Aufgabe des objektorientierten Entwurfs ist es, den Objekten die „Verantwortung“ (Operationen) zuzuweisen, so dass sie für die Lösung des Problems zusammenarbeiten können. Dies bedeutet auch, die Modelle gemäß technischer Erfordernisse zu ergänzen. In der Analyse steht die Frage nach dem „Was soll die Software leisten?“ im Vordergrund. Der Schwerpunkt beim Entwurf liegt bei der Frage: „Wie soll die Software die Anforderungen erfüllen?“. Eine zentrale Rolle im objektorientierten Entwurf übernehmen die Interaktionsdiagramme. Mittels Sequenz- oder ­Kommunikationsdiagramm kann die Softwarefunktionalität entworfen und den beteiligten Klassen die notwendigen Operationen zugeordnet werden. Festlegung der Ablaufreihenfolge Die Ausgangspunkte für die Sequenzdiagramme (s. Abschn. 9.4) sind zum einen detaillierte Szenariobeschreibungen bzw. Anwendungsfallbeschreibungen und zum anderen die Klassendiagramme aus der Analyse. Die Sequenzdiagramme dienen dazu, die zeitliche Abfolge des Aufrufs von Methoden festzulegen und die Methoden entsprechend den Klassen zuzuweisen. Abb.  14.8 zeigt die wichtigsten Notationselemente eines Sequenzdiagramms. Dies sind einerseits die Kommunikationspartner (Angestellter, Kunde, Auftrag und Bestandsartikel) mit ihren Lebenslinien (gestrichelte Linien) und andererseits die Nachrichten (Aufruf einer Methode des Kommunikationspartners) mit ihren gerichteten Kanten (Pfeile). Ein schmaler Balken über der Lebenslinie kennzeichnet die Ausführung von Aktionen. Neben den Sequenzdiagrammen finden sich in der Entwurfsphase zur Modellierung des Softwareverhaltens vor allem Kommunikationsdiagramme, Zustandsautomaten und Timingdiagramme (s. Abschn. 9.4). Dabei ist es das Ziel, den Klassen die Verantwortung in Form von Operationen zuzuordnen und diese Operationen zu spezifizieren. Dies geschieht jeweils im Zusammenspiel mit den Klassendiagrammen.

14  Individualentwicklung von Software

414

Kunde

Bestandsartikel

Angestellter abfragen(Kundennummer)

erfassen()

Kommunikationspartner Lebenslinie

Nachricht

Auftrag istLieferbar erstelleRechnung

Ausführung von Aktionen

Abb. 14.8  Vereinfachtes Sequenzdiagramm zur Auftragsbearbeitung von einem Kunden

Verfeinerung der Klassendiagramme Für den Entwurf stehen für die Klassendiagramme weitere Notationselemente zur Verfügung. Diese sollen die Modellierungsmöglichkeiten vor allem um implementierungsrelevante Details erweitern. Folgende Überarbeitungsschritte der Klassendiagramme sind im Rahmen des Entwurfs durchzuführen (Larman 1998): • Identifiziere alle Klassen, die Teil der Softwarelösung sind. Dies erfolgt durch die Betrachtung/Analyse der Interaktionsdiagramme. • Zeichne alle diese Klassen in das neue Klassendiagramm. • Kopiere die Attribute in dieses Klassendiagramm. • Analysiere die Interaktionsdiagramme und füge entsprechende Methoden hinzu. • Füge Typinformationen zu Attributen und Methoden hinzu. • Füge Assoziationen hinzu, um die notwendige Sichtbarkeit von Attributen/Klassen zu unterstützen. • Füge Pfeile hinzu, um die Sichtbarkeit der Attribute anzuzeigen. Neben den in der Analyse beschriebenen Assoziationen existieren Assoziationen mit eigenen Attributen. Diese Assoziationen werden als eigene Klassen modelliert, die mit der Assoziation verknüpft werden. Diese Assoziationsklassen entsprechen aus der Sicht der Daten den Beziehungstypen von ER-Diagrammen (s. Abschn.  9.5). Die Assoziationsklasse dient dazu, eine Beziehung um Informationen zu ergänzen, die keiner der beteiligten Klassen sinnvoll zuordenbar sind (s. Abb. 14.9).

14.4  Methoden für den Entwurf

415 Belegung -Note -Semester

Student -Immatrikulationsnummer -Immatrikualtionsnummer -Name +bezahleStudiengebuehr()

Kurs

*

*

-Kursnummer -Kurstitel -Hörsaal -Anfangszeit -Dauer +FügeStudentHinzu() +LöscheStudent()

Abb. 14.9 Assoziationsklasse

Navigation

Nutzer

Password 1

*

Abb. 14.10 Navigierbarkeit

Die Navigierbarkeit einer Assoziation stellt die Pfeilspitze am Ende einer Beziehung dar (s. Abb. 14.10). Navigierbarkeit ist die Eigenschaft einer Beziehung, die anzeigt, inwieweit von der Quelle auf das Ziel zugegriffen werden kann. Navigierbarkeit bedeutet damit auch Sichtbarkeit. Wenn ein Objekt A eine Nachricht an B senden will, dann muss B für A sichtbar sein. Implementierungstechnisch weist die Navigierbarkeit auf die notwendigen Fremdschlüsselattribute hin. Aus diesen Gründen gehört die Festlegung der Navigierbarkeit in die Entwurfsphase. Eine Klasse erhält Operationen während der Entwicklung von Interaktionsdiagrammen zugewiesen. Dies zeigt Abb. 14.11 am Beispiel der Auftragsbearbeitung für einen Neukunden. Entwurfsmuster Eine objektorientierte Software besteht aus einer Anzahl kommunizierender Objekte. Daher sind die Interaktionsdiagramme die zentralen Elemente, um das Verhalten zu beschreiben. Es ist wichtig, während der Entwicklung von Interaktionsdiagrammen die Verantwortung den richtigen Objekten zuzuordnen. Es gibt Entwurfsmuster und Prinzipien, um die Qualität der Architektur und der Diagramme zu erhöhen. Das Ziel von Entwurfsmustern ist es, Erfahrungswissen über einen guten Entwurf weiterzugeben, d. h. für im Entwurf immer wiederkehrende Probleme werden Lösungen aufgezeigt bzw. Lösungsempfehlungen gegeben. Die Idee der Entwurfsmuster stammt aus der Architektur (Alexander et al. 1977).

14  Individualentwicklung von Software

416

Bestandsartikel erfassen Kunde

erfassen() Auftrag new() Auftragsposition

SetzeBestellmenge

istLieferbar [nicht lieferbar]: SetzeLiefermenge

erstelleRechnung

Bestandsartikel +istLieferbar() 1

* erteilt

Kunde +erfassen()

1

0..*

Auftrag

Auftragsposition

+erfassen() +erstelleRechnung()

+setzeBestellmenge() +setzeLiefermenge()

Abb. 14.11  Zuordnung der Operationen auf der Basis der Interaktionsdiagramme am Beispiel eines Sequenzdiagramms zur Auftragsbearbeitung

Erste Kataloge von Entwurfsmustern für die Softwareentwicklung sind in (Gamma et al. 1995) und (Buschmann et al. 2000) zusammengestellt. cc Entwurfsmuster (Pattern)  Ein Entwurfsmuster (Pattern) beschreibt ein bestimmtes, in einem bestimmten Kontext immer wiederkehrendes Entwurfsproblem sowie ein generisches Schema zur Lösung dieses Problems (Forbig und Kerner 2004).

14.4  Methoden für den Entwurf

417

Die wesentlichen Elemente eines Entwurfsmusters sind: • • • •

Name des Musters, Beschreibung der Problemklasse, bei der das Muster anwendbar ist, Beschreibung der Lösung, und Beschreibung der Konsequenzen.

Entwurfsmuster können unterschiedliche Bereiche betreffen. Es existieren Entwurfsmuster, welche dem Entwurf in den Diagrammen, wie z. B. der Zuweisung von Verantwortlichkeiten an Objekte, dienen (Larman 1998). Andere Muster beschäftigen sich mit der gesamten Architektur einer Software. Das erste und auch das bekannteste ­Entwurfsmuster ist das Model-View-Controller-Entwurfsmuster (MVC) für die Architektur interaktiver Systeme (Goldberg und Robson 1983): • Problem. Benutzerschnittstellen sind häufig von Änderungen betroffen. Manchmal müssen unterschiedliche Benutzerschnittstellen von einer Anwendung bedient werden. Zudem besteht oftmals die Notwendigkeit, Änderungen in den Daten sofort in allen Darstellungen sichtbar zu machen. Wie kann man unterschiedliche Benutzerschnittstellen bzw. sich ändernde Benutzerschnittstellen unterstützen, ohne Änderungen an der eigentlichen Anwendung durchzuführen? • Lösung. Das MVC-Muster trennt die Anwendung in drei Teile (s. Abb. 14.12): 1. Das Modell (Model), welches für die Verarbeitung zuständig ist, 2. die Sicht (View), die sich um die Ausgabe kümmert und 3. die Kontrolle (Controller) behandelt die Eingabe. • Konsequenzen. Es ist vorteilhaft, dass mehrere Sichten zum gleichen Modell existieren und dass diese Sichten synchron bedient werden können. Der Zugriff auf ein Modell ist dadurch erweiterbar, dass sich weitere Beobachter zuschalten können. Von Nachteil sind die erhöhte Komplexität der Architektur und die starke Kopplung zwischen Modell und Sicht sowie zwischen Modell und Kontrolle. Abb. 14.12 zeigt die Struktur zum MVC-Muster. Hierzu sei angemerkt, dass sich bei dem Modell mehrere Beobachter (Observer), d. h. Sichten und Kontrollen, anmelden können. Komponentenarchitektur Im Entwurf müssen die Festlegung einer Architektur und die Aufteilung der Klassen in einzelne Komponenten erfolgen. Die Architektur soll den statischen Aufbau der Komponenten sowie deren Schnittstellen und Interaktionen beschreiben. Hier kommen sowohl die Paketdiagramme als auch Komponenten- und Verteilungsdiagramme zum Einsatz. Paketdiagramme dienen zur Strukturierung von Klassendiagrammen (s. Abschn. 9.4). Diese Aufteilung in Subsysteme zerlegt das Entwurfsmodell für die Implementierung in kleinere Teile und reduziert hiermit auch die Komplexität. Inhaltlich sollten die Subsysteme zusammengehörende Teile der Software umfassen. Wichtige Punkte in diesem Entwurfsschritt sind die Identifikation der Anwendungssubsysteme, die Definition der Abhängigkeiten zwischen den

418

14  Individualentwicklung von Software

Modell -Daten +anmeldenBeobachter() +abmeldenBeobachter() +benachrichtigen() +abfragenDaten()

Beobachter benachrichtigen

beobachte

1

Darstellung aktualisieren 0..* Beobachter +aktualisiere()

Sicht +initialisiere() +erzeugeKontrolle() +aktiviere() +anzeige() +aktualisiere()

Kontrolle

1

0..1

+initialisiere() +verarbeiteEreignis() +aktualisiere()

Abb. 14.12  Klassendiagramm des MVC-Musters

Subsystemen sowie die Identifikation von Schnittstellen. Abb.  14.13 zeigt das Paketdiagramm zur Auftragsmanagementanwendung. Beim Entwurf der Architektur sind zwei Grundregeln zu berücksichtigen: • Hohe Kohärenz (High Cohesion). Zusammengehörige Teile einer Software sollten in einem Subsystem zusammengefasst werden. • Geringe Kopplung (Low Coupling). Es sollten möglichst wenige Abhängigkeiten zwischen den einzelnen Subsystemen bestehen. Die Berücksichtigung dieser beiden Grundregeln ergibt eine leichtere Änderbarkeit und Austauschbarkeit von einzelnen Teilen. Für weitere Empfehlungen, Prinzipien und

14.4  Methoden für den Entwurf

419

Auftragsmanagementsystem AuftragserfassungsSubsystem

KundenverwaltungsSubsystem

Auftragsposition Kunde

Auftrag

Rechnung

Kommissionierungs- und Auslieferungs-Subsystem Bestandsartikel

Lieferant

Lieferung

Abb. 14.13  Paketdiagramm zum Auftragsmanagement

Entwurfsmuster zur Architektur eines objektorientierten Softwaresystems s. (Balzert 1999; Booch 1991; Buschmann et al. 2000; Forbig und Kerner 2004; Gamma et al. 1995; Maciaszek und Liong 2004; Pressman 2001).

14.4.2 Entwurf der Benutzeroberfläche Beim Entwurf der Benutzeroberfläche wird u. a. festgelegt, • Welche Datenelemente welchen Präsentationselementen (z. B. Fenstern, Bildschirmseiten) zugeordnet werden, • Welche Datenelemente wie angezeigt werden („Druckaufbereitung“ von Feldern, Anzahl der angezeigten Sätze einer Tabelle, Sortierung einer Tabelle), • Welche Präsentationselemente welche Eigenschaften haben (z. B. Fenstergröße, Fenstertitel, zusätzliche Schaltflächen), und • Welche Funktionalitäten die Oberfläche standardmäßig haben soll (z. B. Verknüpfung zweier Tabellen, Vorschlagslisten für Felder, Navigationshilfen).

420

14  Individualentwicklung von Software

Die Spezifikation dieser Eigenschaften kann tabellarisch erfolgen. Viele CASE-­ Umgebungen umfassen jedoch grafische Werkzeuge, um auch die Datennutzung von Modulen und die grafische Oberfläche von Modulen zu erfassen. Dabei wird u. a. festgelegt, ob die Felder der verschiedenen Tabellen in unterschiedlichen Fenstern angezeigt werden sollen, wie die Felder innerhalb der Fenster anzuordnen sind (z. B. in Maskenform oder in Tabellenform), wie viele Datensätze in welcher Sortierung angezeigt werden sollen und wie die Tabelleninhalte untereinander zu verknüpfen sind. Für die Verknüpfung von Tabellen gibt es zwei Grundformen: • Eine Master-Detail-Beziehung legt fest, dass ein untergeordneter Maskenteil nur solche Datensätze enthält, die sich auf den gerade im übergeordneten Maskenteil angezeigten Datensatz beziehen. Beispielsweise zeigt der untergeordnete Maskenteil nur Auftragspositionen an, die sich auf den aktuellen Kundenauftrag im übergeordneten Maskenteil beziehen. Beim Blättern im übergeordneten Maskenteil werden dann automatisch die jeweils zugehörigen Auftragspositionen angezeigt, beim Einfügen eines Satzes im untergeordneten Maskenteil wird automatisch ein Bezug zum aktuellen Datensatz im übergeordneten Maskenteil hergestellt. Grundlage einer Master-Detail-­ Beziehung ist im Normalfall eine zwischen den Tabellen bestehende Fremdschlüsselbeziehung (s. Abschn. 9.5). • Eine Lookup-Beziehung legt fest, dass für ein bestimmtes Datenfeld auf Wunsch eine Auswahltabelle angezeigt wird, um z. B. dort einen Code zu markieren und in die Basistabelle zu übernehmen. Auch die Lookup-Beziehung basiert im Normalfall auf einer Fremdschlüsselbeziehung zwischen den Tabellen. Andere Werkzeuge zum Entwurf der Benutzerschnittstelle unterscheiden sich vom hier gezeigten Beispiel zwar in der Oberfläche, im Umfang der grafischen Entwurfsmöglichkeiten und im Umfang der implizierbaren Funktionalität des Moduls, nicht aber in der prinzipiellen Vorgehensweise. Zu diesen Werkzeugen sind insbesondere Maskengeneratoren zu zählen, die sich auf den Entwurf von Eingabe- bzw. Auswertungsmasken konzentrieren.

14.5 Methoden für die Implementierung und den Test Die Anforderungsanalyse und die Umsetzung des fachlichen Konzepts in ein IT-Konzept haben das Ziel, eine stabile, realisierungsunabhängige Grundlage für die Softwareentwicklung zu schaffen. Wenn alle relevanten Informationen im Rahmen des Entwurfs erfasst und unter Benutzung einer formalen Spezifikationssprache beschrieben sind, ist der Implementierungsprozess theoretisch automatisierbar: Die realisierungsunabhängig „codierten“ Spezifikationen müssen dann lediglich in die (formale) Realisierungssprache übersetzt werden. Diesen Ansatz verfolgen alle CASE-Umgebungen (s. Glossar). Der hohe Aufwand für Prozessmodellierung, konzeptionelle Datenmodellierung, ­ Normalisierung, Dekomposition, Oberflächenmodellierung und Ablaufbeschreibung lohnt sich nur, wenn die durch die

14.5  Methoden für die Implementierung und den Test

421

entsprechenden Werkzeuge erfassten Spezifikationen nicht nur für den Entwurf wiederverwendet und als Dokumentation benutzt, sondern auch für die Generierung der Software eingesetzt werden können.

14.5.1 Codierung Manuelle Codierung ist die traditionelle Form der Implementierung. Aufgrund des hohen Aufwands, der hohen Fehleranfälligkeit und der Gefahr, die Wartbarkeit und Änderbarkeit nicht ausreichend zu unterstützen, sind andere Formen der Implementierung im Normalfall der manuellen Codierung vorzuziehen. Das gilt zumindest für betriebliche Anwendungen. Für hardwarenahe Software und Realtime-Anwendungen jedoch sind Ablaufeffizienz und Ressourcennutzung oftmals wichtiger als Wartbarkeit und Änderungsfreundlichkeit. Generierte Anwendungen weisen hohe Standardfunktionalitäten auf, sind qualitätsgesichert und auf der Grundlage eines detaillierten Entwurfs einfach realisierbar. Im Normalfall ist ihre Ablaufeffizienz jedoch geringer und ihr Bedarf an Rechnerressourcen höher als bei manuell codierten Anwendungen. Zur Unterstützung der manuellen Codierung stehen verschiedene Werkzeuge zur Verfügung: • Editoren unterstützen die „Textverarbeitung“ des Programmcodes, etwa durch Such-, Kopier- und Formatierfunktionen. Außerdem ist es möglich, vorbereitete Anweisungen in Form von Textbausteinen in den Programmcode einzufügen. • Debugger erlauben es, manuell erstellten Code interaktiv zu testen. So können z. B. Prozeduren und Methoden schrittweise ausgeführt und die aktuellen Werte von Variablen kontrolliert werden. • Bibliotheken sind ein wichtiges Hilfsmittel für die Wiederverwendung von Code. Dabei steht nicht die technische Speicherung von Modulen im Vordergrund, sondern ihre sinnvolle „Verschlagwortung“, um in späteren Projekten effizient geeignete Wiederverwendungskandidaten zu identifizieren. • Schließlich dienen Data Dictionaries zur modulübergreifenden Dokumentation von Datenstrukturen. In der prozeduralen Programmierung (ohne Nutzung relationaler Datenbanken) ist es notwendig, die Trennung von Anwendungen und Daten wenigstens durch eine anwendungsunabhängige Beschreibung der verschiedenen Datenelemente ansatzweise zu realisieren.

14.5.2 Test Mit der Umsetzung des Entwurfs in ausführbaren Programmcode startet auch das Testen von Programmen und Programmteilen, inwieweit sie das gewünschte Leistungsverhalten besitzen. Diese Testaktivitäten sind analytische Maßnahmen, um die Qualität von IS/Software sicherzustellen.

422

14  Individualentwicklung von Software

cc Testen  Testen bezeichnet jede einzelne (im Allgemeinen stichprobenartige) Ausführung des Testobjekts, d. h. einer Komponente, eines integrierten Teilsystems oder einer gesamten Anwendung (in einer Version), um die (beobachteten) Ergebnisse im Hinblick auf gewisse Eigenschaften zu überprüfen (Forbig und Kerner 2004). Das Testen auf Fehler kann auf zwei Arten erfolgen: Einmal auf die Nichterfüllung der Spezifikation und zum anderen auf die Nichterfüllung der Anforderungen. Daher sei nochmals auf die Begriffe Verifikation und Validation verwiesen (s. Abschn. 13.3). cc Fehler  Ein Fehler ist die Nichterfüllung einer festgelegten Anforderung, eine Abweichung zwischen dem Ist-Verhalten (während der Ausführung der Tests oder des Betriebs festgestellt) und dem Soll-Verhalten (in der Spezifikation oder den Anforderungen festgelegt) (Forbig und Kerner 2004).

Teststrategien und Prinzipien Entsprechend der Codierung von Komponenten erfolgen zunächst Testaktivitäten, die die Erfüllung der Spezifikation bzw. des Entwurfs prüfen. Nachdem einzelne Komponenten fertig gestellt und zusammengefasst (integriert) sind, erfolgen weitere Testaktivitäten, um die integrierten Softwareteile zu prüfen. Danach wird die Gesamtsoftware überprüft, ob es zunächst gemäß Spezifikation/Entwurf fehlerfrei ist (Verifikation) und dann, ob es die tatsächlichen Anforderungen des Nutzungskontexts erfüllt (Validation) (s. auch Abschn.  13.3). Abb.  14.14 veranschaulicht diese Teststrategie, wie sie teilweise auch durch die Vorgehensmodelle (s. Abschn.  13.5) vorgegeben ist. Im Folgenden sind die ­Testplanung und die Testmethoden grob erläutert. Für die weitere Darstellung sei auf Pressman 2001; Wallmüller 2001; Forbig und Kerner 2004; Myers 1999 verwiesen.

Anforderungen

Validierung

Entwurf

Integrationstests Komponententests

Code

Komponententests Testrichtung

Abb. 14.14  Grundlegende Teststrategie

Gesamtsystem

Teilsysteme

Komponenten

14.5  Methoden für die Implementierung und den Test

423

Für die Planung und Durchführung von Tests existieren viele zu berücksichtigende Hinweise. Dazu zählen: • Testaktivitäten sollten soweit möglich aus den Anforderungen an das IS abgeleitet sein. • Testaktivitäten sollten vor ihrer Durchführung geplant werden. • Für das Testen gilt das Pareto-Prinzip, d. h. in diesem Fall, dass 80 Prozent der aufgedeckten Fehler durch 20 Prozent der Software verursacht werden. • Es ist nicht möglich, alle Fehler durch Testen aufzudecken. • Testen sollte „im Kleinen“, d. h. bei den Komponenten beginnen, bevor „im Großen“, d. h. z. B. bei einer integrierten Teilanwendung fortgefahren wird. • Die effektivste Art des Testens erfolgt durch einen unabhängigen Dritten, d. h. der Programmierer selbst ist nicht die beste Person, um alle Tests an seiner Software ­durchzuführen. • Ein guter Test hat eine hohe Wahrscheinlichkeit einen bisher unerkannten Fehler zu finden.

Planung von Tests Die bei einer Softwareentwicklung durchzuführenden Tests sind im Rahmen des gewählten Vorgehensmodells zu planen. Zumeist werden schon sehr früh, zum Beispiel in der Anforderungsdefinition, die durchzuführenden Tests festgelegt. Abb. 14.15 zeigt die im Rahmen des Testens durchzuführenden Aktivitäten: • Die Testplanung beginnt mit dem Projektstart. Es sind die für den Test notwendigen Ressourcen (wie z. B. Personal, Testwerkzeuge, Testdaten, Rechner) festzulegen. Da ein vollständiger Test eines Programms nicht möglich ist, muss eine entsprechende Teststrategie festgelegt werden. Welcher Testaufwand soll für welche Komponenten erbracht werden (kritische Komponenten müssen besonders intensiv getestet werden.)? Welche Testmethoden werden wann und wo eingesetzt? Je nach Testmethode muss festgelegt werden, wann die Tests zu beenden sind. Da Tests immer im letzten Drittel eines Projekts durchgeführt werden, stehen sie unter einem besonderen Zeitdruck. Daher ist es sinnvoll, die Tests zu priorisieren. • Spezifikation von Testfällen. In der Testspezifikation werden die notwendigen Testfälle festgelegt. Das Ziel ist es, Testfälle mit minimalem Aufwand zu entwerfen, die aber eine große Wahrscheinlichkeit haben, einen Fehler zu entdecken. Dies hängt von der Testmethode ab. Zumeist sind logische Testfälle zu definieren, die dann sukzessiv konkretisiert werden. Im Rahmen der Überprüfung der Anforderungen können zum Beispiel unterschiedlich detaillierte Beschreibungen von Anwendungsfällen (s. Abschn. 14.3.1) ausgewählt und dann mit Testdaten konkretisiert werden. • Durchführung. Wenn die Ablauffähigkeit eines Testobjekts gegeben ist und die Testspezifikation vorliegt, dann können die entsprechenden Tests durchgeführt werden.

424

14  Individualentwicklung von Software

• Protokollierung. Die Durchführung der Tests ist exakt und vollständig zu protokollieren. • Auswertung und Folgeplanung. Nach Abschluss der Tests sind die Protokolle auszuwerten. Gegebenenfalls müssen weitere Tests geplant werden. Weiterhin muss entschieden werden, ob die Tests abgeschlossen werden können.

Testmethoden Im Folgenden sollen die wichtigsten Testmethoden aufgeführt und kurz erläutert werden. Für eine detaillierte Beschreibung wird auf Pressman 2001; Wallmüller 2001; Forbig und Kerner 2004; Spillner und Linz 2012; Myers 1999 verwiesen: • Blackbox-Tests. Wenn beim Testen das Testobjekt nur von außen betrachtet wird und das Innere des Testobjekts bei dem Test verborgen bleibt, so bezeichnet man den Test als Blackbox-Test. Blackbox-Tests werden häufig für die Überprüfung der Anforderungen in den höheren Teststufen (s. Abb. 14.15) verwendet. • Whitebox-Tests. Im Gegensatz zu den Blackbox-Tests wird bei den Whitebox-Tests das Innere des Testobjekts bei dem Entwurf eines Testfalls berücksichtigt. Hierbei wird speziell auf kritische Programmteile geachtet. Whitebox-Tests werden überwiegend bei den Komponententests eingesetzt. • Integrationstests. Beim Integrationstest liegt der Schwerpunkt des Testens auf der Interaktion zwischen den Komponenten. Hierbei wird besonders auf das Außenverhalten der Komponenten geachtet. Die Integrationstests laufen schrittweise ab, d. h. es wird die Schnittstelle zwischen zwei Komponenten untersucht, bevor iterativ weitere Komponenten hinzugenommen werden. • Regressionstests. Der Regressionstest ist ein erneuter Test, um bereits getestete Programmteile nach deren Modifikation erneut auf Fehlerfreiheit zu prüfen. Denn sowohl Wartungsarbeiten als auch Weiterentwicklungen an der Software oder die Ergänzung weiterer Softwarebausteine können unvorhergesehene Defekte und Auswirkungen an bestehenden Bereichen hervorrufen. Der Regressionstest kann zu jeder Phase im Softwareentwicklungsprozess stattfinden. Testfälle für den Regressionstest müssen ausreichend dokumentiert sein, um sie bei Bedarf zu wiederholen. Sie sind daher bevorzugte Kandidaten für eine Testautomatisierung.

Testautomatisierung Zu den Aufgaben eines Softwaretesters gehören die Testfallerstellung sowie deren Durchführung, Auswertung und Dokumentation. Theoretisch kann ein Test fast eine endlose Anzahl an Testfällen beinhalten, da Tests nur die Anwesenheit von Fehlern nachweisen, nicht aber deren Abwesenheit. Das heißt, dass lediglich die Wahrscheinlichkeit verringert wird, dass noch unentdeckte Fehlerzustände im Testobjekt vorhanden sind. Die Testautomatisierung kann die Entwicklungsprozesse beschleunigen. Aufgrund der relativ kurzen

14.5  Methoden für die Implementierung und den Test

425

Testplanung

Spezifikation von Testfällen

Durchführung

Nein

Protokollierung

Auswertung und Folgeplanung

Endekriterium erfüllt ? Ja

Abb. 14.15  Grundlegender Testprozess

Sprintzyklen und der stetigen Modifikation von Programmcode besitzt die Testautomatisierung daher bei der agilen Softwareentwicklung (s. Abschn.  13.5.3.2) eine besondere Bedeutung. Beim Testen können im Prinzip folgende Aktivitäten (s. Abb. 14.15) automatisiert werden: • Testplanung und Testadministration. Dies umfasst die Verwaltung und Versionierung von Testumgebungen sowie die Bereitstellung einer angemessenen Benutzungsumgebung. • Spezifikation von Testfällen. Bei der Generierung von Testfällen aus Testspezifikationen werden die Eingabedaten und Abläufe gemäß der zu erzielenden Testabdeckung ausgewählt. Zur Erstellung der Testdatenerstellung kann zum Beispiel das zugrundliegende Datenmodell und zur Testskripterstellung zum Beispiel die Verhaltensmodelle der Software dienen. • Testdurchführung. Hier kommen Testwerkzeuge zum Beispiel für die einzelnen Softwarekomponenten, für die Datenbank und die grafische Benutzeroberfläche oder Web-Oberfläche zum Einsatz.

426

14  Individualentwicklung von Software

• Testprotokollierung. Aus den erhaltenen Testergebnissen muss ein nachvollziehbarer und verständlicher Testbericht erzeugt werden. Hierfür können zum Beispiel Dokumentgeneratoren und Schablonenwerkzeuge eingesetzt werden. • Testauswertung. Das erhaltene Testergebnis muss mit dem erwarteten Wert verglichen werden. Oftmals ist hier nur ein Tabellenvergleich vorzunehmen. Für die Automatisierung dieser Aktivitäten gibt es unterschiedliche Werkzeuge und Frameworks, die sich zumeist auf die Lösung einzelner Aufgaben fokussieren.

14.6 Methoden für die Softwarewartung Jede Software ist sowohl in eine technische wie auch in eine organisatorische Umgebung eingebettet. Die organisatorische Umgebung und insbesondere die Geschäftsprozesse wandeln sich im Zeitablauf aufgrund von immer neuen Herausforderungen. Ein extremes Beispiel ist die fundamentale Neustrukturierung von Geschäftsprozessen im Rahmen des Business Process Redesign (s. Abschn. 6.1). In der technischen Umgebung ergeben sich ebenfalls neue Anforderungen: Die Hersteller der für den Betrieb einer Anwendung notwendigen Hardware und Systemsoftware bringen kontinuierlich neue Produkte und Versionen auf den Markt und stellen gleichzeitig die Wartung älterer Produkte ein.

14.6.1 Software Reengineering Organisatorische und technische Veränderungen bedingen für IS einen Alterungsprozess, obwohl Software keinem physischen Verschleiß unterliegt. Das Ergebnis sind so genannte Software-Altlasten oder Legacy-Systeme. Diese stellen das betriebliche Informationsmanagement regelmäßig vor die Frage, ob es die alten Softwareprodukte durch neue Anwendungen ersetzen oder aber weiterhin warten soll. Wartung bedeutet in aller Regel, dass die Anwendungen unter Beibehaltung ihres veralteten Technologiestands in einem betriebsfähigen Zustand zu halten sind. In einigen Branchen, wie z. B. Banken und Versicherungen, hat dieses Vorgehen dazu geführt, dass diese Unternehmen Software mit einer bis zu dreißigjährigen Entwicklungsgeschichte betreiben (Brombacher 1995). Dadurch entstehen verschiedene Probleme: • Die Software orientiert sich häufig nicht an aktuellen Geschäftsprozessen. Stattdessen werden umgekehrt suboptimale Teilprozesse als Behelfslösungen geschaffen, um die Software möglichst unverändert weiternutzen zu können. • Der Technologiestand der alten und neuen Software in den Unternehmen ist sehr heterogen und erfordert deshalb für Betrieb und Wartung einen personell und technisch hohen Aufwand.

14.6  Methoden für die Softwarewartung

427

• Die Modifikation der Software ist eine softwaretechnisch komplexe Aufgabe. Der Grund liegt darin, dass in der Regel entweder kein Fachkonzept verfügbar ist oder dass diese Informationen durch jahrelange Wartungsaktivitäten an Aktualität verloren haben. Auf die Lösung der genannten Probleme zielt das Software Reengineering ab (Baumöl et al. 1996). Im Gegensatz zur „konventionellen“ Wartung, die Modifikationen häufig auf Code-Ebene vornimmt, zielt das Reengineering darauf ab, zunächst die fehlenden konzeptionellen Informationen über eine Software-Altlast zu rekonstruieren. Diese Informationen bzw. die entstandenen Entwurfsdokumente können dann modifiziert und anschließend im Rahmen eines softwaretechnisch modernen Entwicklungsprozesses genutzt werden, um ein neues IS zu implementieren. Dabei können beispielsweise CASE-Umgebungen (s. Glossar) zum Einsatz kommen.

14.6.2 Reverse Engineering Die wesentliche Teildisziplin des Software Reengineering ist die Rekonstruktion von Entwurfsdokumenten, das so genannte Reverse Engineering. Software-Altlasten weisen häufig nicht die für moderne Anwendungen typische Trennung von Benutzeroberfläche, Anwendungslogik und Datenbanknutzung auf. Deshalb erfordert das Reverse Engineering i. d. R. eine Untersuchung des gesamten Softwaresystems, bei der aufgrund des großen Programmumfangs unterstützende Werkzeuge einzusetzen sind. Abhängig vom zu rekonstruierenden Entwurfsdokument, lassen sich zwei grundsätzliche Formen des Reverse Engineering unterscheiden: • Als Daten-Reverse-Engineering wird die Rekonstruktion konzeptioneller Informationen über die verwendeten Datenstrukturen bezeichnet. Es ist beispielsweise möglich, die Datenstrukturen, die einem Cobol-Programm zugrunde liegen, als konzeptionelles Datenschema in Entity-Relationship-Notation darzustellen. • Das Oberflächen-Reverse-Engineering dokumentiert die Ein- und Ausgabefunktionen einer Altsoftware in Form eines sog. Dialogmodells, sodass anschließend eine moderne Oberfläche realisierbar ist. Ein typisches Anwendungsbeispiel für das Oberflächen-­ Reverse Engineering ist die Migration zeichenorientierter Ein-/Ausgabemasken zu einer grafischen Benutzeroberfläche. Da der Code eines Software-Altsystems nicht notwendigerweise alle konzeptionell relevanten Sachverhalte explizit oder implizit enthält, ist das Reverse Engineering immer ein Prozess, der menschliches Problemlösungswissen und insbesondere Wissen über das Anwendungsgebiet der Altsoftware erfordert.

Fazit: Berufsbilder der Wirtschaftsinformatik

15

Dieses Lehrbuch zur anwendungsorientierten Wirtschaftsinformatik hat in den vorangehenden Teilen den aktuellen Stand der IT reflektiert, die im betrieblichen Anwendungskontext ihre ökonomische und gesellschaftliche Wirkung entfaltet. Besondere Potenziale liefert transformationale IT, wie beispielsweise Cloud Computing (s. Abschn.  4.4.3), das Internet der Dinge (s. Abschn. 5.5.1), Industrie 4.0 (s. Abschn. 5.5.2) oder Big Data (s. Abschn.  11.2.7), die maßgeblich zur Digitalisierung von Märkten, Wertschöpfungsketten und Unternehmensprozessen beitragen. Die informationstechnologischen Veränderungen vollziehen sich dabei mit einer hohen Geschwindigkeit, sodass traditionelle Fähigkeiten und Fertigkeiten in immer kürzeren Zeiträumen obsolet werden. Daher steigt der Bedarf nach flexiblen Arbeitskräften, die über ein hohes Maß an Anpassungsvermögen und über Kompetenzen zur Gestaltung und zur Anwendung von IS verfügen. Der Bedarf nach diesen Kompetenzen kommt am Arbeitsmarkt insbesondere in den facettenreichen Berufsbildern für Absolventen der Wirtschaftsinformatik zum Ausdruck, die die Chancen der anwendungsorientierten Auseinandersetzung mit IS aufzeigen und hier zum Abschluss des Lehrbuchs im Überblick dargestellt werden. Absolventen der Studiengänge Wirtschaftsinformatik sowie Betriebswirtschaftslehre und Volkswirtschaftslehre mit Spezialisierung in Wirtschaftsinformatik oder IM sind nachfolgend vereinfachend als Wirtschaftsinformatiker bezeichnet. Bachelor- und Masterabschlüsse in Wirtschaftsinformatik bieten sowohl Universitäten als auch Fachhochschulen an. Zu diesen akademischen Abschlüssen zählen der Bachelor/Master of Science (B.Sc./M.Sc.) und der Bachelor/Master of Arts (B.A./M.A.). Am Arbeitsmarkt sind Wirtschaftsinformatiker derzeit sehr gefragt. Einerseits bieten sich Perspektiven in IT-Kernberufen, die sich mit der Konzeption, Entwicklung und Einführung von IS beschäftigen. In diesem Tätigkeitsfeld stehen Wirtschaftsinformatiker aufgrund des Schnittstellencharakters der Disziplin in Konkurrenz zu Informatikern und differenzieren sich gegenüber diesen vor allem durch einen stärkeren Anwendungsbezug.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7_15

429

430

15  Fazit: Berufsbilder der Wirtschaftsinformatik

Andererseits finden Wirtschaftsinformatiker auch in IT-Randberufen Verwendung, in denen die Nutzung bestehender IS zur Handhabung betrieblicher Aufgabenstellungen im Mittelpunkt steht, z. B. in den Funktionsbereichen Marketing, Personal oder Logistik. In diesen Bereichen konkurrieren Wirtschaftsinformatiker mit anderen Wirtschaftswissenschaftlern und im Bereich der Produktion auch mit ingenieurwissenschaftlichen Absolventen. Zur Systematisierung von IT-Kernberufen für Wirtschaftsinformatiker dient im Folgenden die Wertschöpfungskette (s. Abb. 3.3) der Softwareindustrie. Abb. 15.1 identifiziert in Anlehnung an (Pussep et al. 2011) die zentralen Aktivitäten, die bei der Gestaltung und anschließenden Nutzung von IS über deren gesamten Lebenszyklus von Bedeutung sind. Dazu lässt sich idealtypisch zwischen Aktivitäten in IT-Anbieterunternehmen und IT-­ Anwenderunternehmen differenzieren. Ein zentrales Tätigkeitsfeld von Wirtschaftsinformatikern in IT-Anbieterunternehmen besteht in der Entwicklung von Standard- oder Individualsoftware und deren Dokumentation. Hiermit sind insbesondere Aufgaben zum Entwurf, zur Programmierung und zum Testen von Software verbunden, die in Stellenanzeigen für Wirtschaftsinformatiker häufig im Berufsbild des Entwicklers (Software Engineer, Software Developer) zum Ausdruck kommen. Entwickler beherrschen gängige Programmiersprachen (z. B. Java, C#, ABAP) und die dazugehörigen Softwareentwicklungswerkzeuge. Für Absolventen, die eine Tätigkeit als Softwareentwickler anstreben, sind außerdem Englischkenntnisse sowie Berufserfahrung zentrale, überfachliche Einstellungskriterien (Bensberg et al. 2017). Auch im Kontext des Marketings und Vertriebs von Softwareprodukten sind Wirtschaftsinformatiker notwendig. In dieses Tätigkeitsfeld fallen Aufgaben wie z. B. die Präsentation der Systeme bei Kunden, auf Fachmessen oder ähnlichen Veranstaltungen, die individuelle Betreuung der Kunden und teils auch die Erhebung der K ­ undenanforderungen für die jeweiligen Systeme. Zur Unterstützung von Vertriebsaufgaben kommen technische

Abb. 15.1  Wertschöpfungskette der Softwareindustrie in Anlehnung an (Pussep et al. 2011)

15  Fazit: Berufsbilder der Wirtschaftsinformatik

431

Vertriebsbeauftragte (Technical Sales Manager) zum Einsatz. Aufgrund der zunehmenden Verbreitung von Public Cloud-Lösungen im Rahmen betrieblicher Anwendungen sind Marketing- und Vertriebsaktivitäten im Softwareumfeld verstärkt auf Services fokussiert, wie z. B. SaaS (s. Abschn. 4.4.3). Unternehmensberatung (Consulting) ist eine professionelle Dienstleistung, die fachlich befähigte, und von den beratenen Klienten hierarchisch unabhängige Personen zeitlich befristet erbringen (Nissen 2013). Im Tätigkeitsfeld des IT-Consulting geht es häufig darum, den Einsatz von IS mit der zugrunde liegenden IT bei Anwenderunternehmen zu verbessern. Auftraggeber für IT-Beratungsprojekte sind häufig die Leiter der IT-­Abteilungen oder der Fachabteilungen im Unternehmen. Dabei übernehmen IT-Berater typischerweise Aufgaben zur Auswahl, Beschaffung, Einführung und ggf. auch Anwendung von IS. In deutschsprachigen Stellenanzeigen für Wirtschaftsinformatiker prägen konkrete Softwareprodukte der SAP SE stark das Berufsbild des IT-Beraters (Bensberg et al. 2017). So suchen Unternehmen Wirtschaftsinformatiker als IT-Berater insbesondere für betriebswirtschaftliche Anwendungen in den Funktionsbereichen Vertrieb (SAP SD), Materialwesen (SAP MM) sowie externes und internes Rechnungswesen (SAP FI/CO). Wesentliche Aufgaben bestehen dabei in der Einführung und Anpassung der entsprechenden Module der SAP-Anwendungslandschaft an die betrieblichen Anforderungen (Customizing, s. Abschn. 10.4.1). Zur Einführung von IS in Anwenderunternehmen ist nicht nur deren Installation und Konfiguration vorzunehmen, sondern auch für die Integration des Softwaresystems in die bestehende Systemlandschaft zu sorgen. Sofern diese Tätigkeiten nicht IT-Berater erbringen, kommen hierfür Wirtschaftsinformatiker beispielsweise in den Rollen des Administrators (z. B. als Datenbank-Administrator) und Softwareentwicklers zum Einsatz. Damit anschließend die Endanwender produktiv mit IS arbeiten können, ist deren Training und Zertifizierung erforderlich. In diesem Aufgabenfeld können Wirtschaftsinformatiker als Trainer, Ausbilder bzw. Dozenten tätig werden. Voraussetzung hierfür sind – ähnlich wie bei der Dokumentation von Software – spezialisiertes Wissen über das jeweilige IS sowie Kenntnisse über die auszubildenden Zielgruppen und deren Informationsbedarf. Zur Sicherung des Bildungserfolgs der Zielgruppe spielen insbesondere auch didaktische Kompetenzen eine Rolle. In den letzten beiden Aktivitäten der Wertschöpfungskette erfolgen Wartung, Support und Betrieb von IS. Hierunter fallen insbesondere solche Aufgaben, die mit der Bereitstellung von IT-Services verknüpft sind und sich beispielsweise im ITIL-Framework im Bereich Service Operations (s. Abschn. 4.2.5) finden (Incident Management, Problem Management, Request Management). In diesen Bereichen kommen Wirtschaftsinformatiker beispielsweise als IT-Service- und Applikationsmanager zum Einsatz. Die hier skizzierten Tätigkeitsfelder führen nicht nur auf der operativen bzw. ausführenden Ebene zu entsprechenden Berufsbildern und Stellenangeboten, sondern auch auf der dispositiven bzw. leitenden Ebene. Alle Leitungstätigkeiten beinhalten die Verantwortung für die in der jeweiligen Organisationseinheit zu erfüllenden Aufgaben. Die ­langfristige Planung, Durchführung und Kontrolle dieser Aufgaben ist somit wesentlicher Bestandteil von Leitungsfunktionen. Zu diesen Berufsbildern sind beispielsweise der Chief Information

432

15  Fazit: Berufsbilder der Wirtschaftsinformatik

Officer (CIO, Synonym: IT-Leiter, IT-Direktor) zu zählen, der die Gesamtverantwortung für die IT trägt und diese ggf. im Vorstand vertritt, sowie der IT-Controller, der durch Wirtschaftlichkeitsbewertung von IS zur Entscheidungsunterstützung beiträgt. Da die Einführung von IS in der Regel in Projektform erfolgt, werden Wirtschaftsinformatiker häufig auch als IT-Projektmanager eingesetzt. Diese übernehmen die Planung, Koordination und Kontrolle von Projekten mithilfe formaler Projektmanagementtechniken und steuern das verfügbare Projektbudget (Bensberg et al. 2017). Aufgrund der anhaltenden Digitalisierung in IT-Anwenderunternehmen ist die langfristige, strategische Gestaltung von IS und den zugrundliegenden Informationstechnologien in Abstimmung mit der Unternehmensstrategie und den Geschäftsprozessen zu koordinieren. In diesem Tätigkeitsfeld haben sich Berufsbilder für IT-Architekten herausgebildet, die unterschiedliche Aufgabenfelder fokussieren (Bensberg und Buscher 2018). So plant beispielsweise der Anwendungsarchitekt (Application Architect) die strategische Entwicklung von Applikationen, für die entsprechende Richtlinien – z. B. in Bezug auf Sicherheit und Basistechnologien – zu formulieren sind. Der Daten-Architekt (Data Architect) konzipiert hingegen eine Datenstrategie, die durch Umsetzung technischer und organisatorischer Datenmanagementkonzepte zu realisieren ist. In Hinblick auf den deutschen Arbeitsmarkt ist festzustellen, dass Unternehmen für die skizzierten IT-Kernberufe generell eine hohe Einstellungsbereitschaft besitzen. So zählen IT-Kernberufe wie die IT-Anwenderberatung, die Softwareentwicklung und die Programmierung in Deutschland mittlerweile zu den bundesweiten Mangelberufen (BfA 2017). Wirtschaftsinformatiker finden in diesen Berufen ihren organisatorischen Wirkungskreis typischerweise in der IT-Abteilung von Unternehmen oder öffentlichen Institutionen. Aufgrund der Verbreitung von IS in sämtlichen Funktionsbereichen des Unternehmens haben sich die Einsatzfelder für Wirtschaftsinformatiker auch auf IT-Randberufe ausgeweitet, bei denen die produktive Nutzung von IS im Mittelpunkt steht. Hierbei kommt dem Wirtschaftsinformatiker zunehmend die Funktion der Schnittstellenbildung zwischen Anwendern und IT-Abteilung zu. Aktuelle Beispiele für solche IT-Randberufe sind die Berufsbilder des Big-Data-Analysten oder des Data Scientist (Schumann et al. 2016). Deren typische Aufgaben bilden die Exploration, Integration und Analyse großvolumiger Datenbestände sowie deren Nutzung zur Konstruktion von Optimierungs- und Prognosemodellen. Diese benötigen Fachabteilungen nicht nur zur Unterstützung von Planungs- und Entscheidungsprozessen in Fachabteilungen, sondern vermehrt auch zur operativen Steuerung von Geschäftsprozessen. Die fortschreitende Digitalisierung von Wirtschaft und Gesellschaft sorgt dafür, dass Unternehmen verstärkt mit der Herausforderung konfrontiert sind, innovative IT-­Lösungen zur Automatisierung und Unterstützung ihrer Geschäftsmodelle einzusetzen. Die hiermit einhergehende IT-gestützte Unternehmenstransformation (s. Teile 1 und 2) eröffnet in Verbindung mit dem demografischen Wandel weiterhin attraktive Beschäftigungsmöglichkeiten für Wirtschaftsinformatiker als IT-Fach- und Führungskräfte. Dabei ist allerdings zu berücksichtigen, dass aufgrund der hohen Entwicklungsdynamik von IT die am Arbeitsmarkt gesuchten Kompetenzen auch weiterhin einem anhaltenden Wandel unterliegen (Bensberg und Buscher 2017).

Glossar

Zusammenfassung Das Glossar erläutert zentrale Begriffe der Hardware- und Softwaretechnologie im jeweiligen Zusammenhang. Daher ist nicht jeder Begriff als Einzeleintrag angelegt, sodass der Zugang auch über das Stichwortverzeichnis erfolgen sollte.

A Algorithmus Ein Algorithmus ist eine Verarbeitungsvorschrift zur Lösung eines klar definierten und begrenzten Problems oder einer Klasse von Problemen. Er wird durch einen endlichen Text beschrieben und besteht aus mehreren elementaren Schritten oder Operationen, die in einer bestimmten Reihenfolge durchzuführen sind, wobei Wahlmöglichkeiten und Verzweigungen zugelassen sein können. Er beschreibt die auszuführenden Verarbeitungsschritte hinreichend präzise. Anwendungssoftware Anwendungssoftware (Synonyme: Applikationssoftware, Applikation) bezeichnet eine Kategorie von Software, die für den Endnutzer entwickelt wurde, um ihn bei seinen betrieblichen Aufgaben zu unterstützen. Sie kann funktionsspezifisch oder funktionsübergreifend sein. Beispiele sind Textverarbeitungsprogramme (funktionsübergreifend) und Buchhaltungsprogramme (funktionsspezifisch).

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7

433

434

Glossar

Archivierung Dokumente sind elektronisch, auf Papier oder sonstigem Datenträger gespeicherte Daten. Dokumente können textueller, grafischer oder sonstiger Art (z. B. Sprache) sein. Dokumente als Sammelbegriff für Objekte der rechnergestützten Text-, Präsentations-, Tabellen-, Grafik- und Datenverarbeitung werden erzeugt bzw. eingelesen, bearbeitet und dann archiviert. Letzteres erfolgt im Rahmen der Archivierung als Papierdokument oder e­ lektronisches Dokument. Im Rechner erfolgt die Ablage kurz- bzw. mittelfristig als Datei in einem meist hierarchisch aufgebauten Dateisystem. Die Anforderungen an die Archivierung in einem vernetzten IS sind: • Hierarchisches Management von elektronischen Ordnern, Mappen oder Vorgängen, • Differenzierte Zugriffsberechtigungen nach Funktionen (Lesen, Ändern, Löschen, Anfügen, Kopieren, Drucken) oder nach Gruppen, Personen bzw. Organisationseinheiten, • Indexierung nach frei wählbaren Stichworten bzw. wahlweise automatische Indexierung mit Software für Thesauruspflege, • Volltextrecherche, • Wiedervorlagefunktion, • verteilte Ablage, und • Archivierung mit automatisierter Auslagerung auf kostengünstigere Speichermedien. Die Archivierung von Dokumenten wird durch Archivierungssysteme unterstützt, die in Behörden, Verlagen, Anwaltskanzleien, Krankenhäusern, Banken, Versicherungen, sowie anderen Branchen zunehmend Einsatz finden. Wichtige funktionale Elemente von Archivierungssystemen sind das Scannen, das Indizieren (auch: Verschlagwortung, Attributierung), das Rendering, das Archivieren, das Recherchieren sowie das Vernichten von Dokumenten. Hierbei kommen Techniken der elektronischen Bildverarbeitung zum Einsatz. Application Programming Interface (API) Zur Entwicklung von Anwendungen dienen neben den Sprachkonstrukten einer Programmiersprache auch Dienste anderer Anwendungen über eine sog. API (Application Programming Interface). Die einzelnen Anwendungsdienste (Datenbank, Sicherheit, Datenanalyse, usw.) stellen über eine definierte Schnittstelle Funktionen zur Verfügung, die bei der Entwicklung der neuen Anwendungssoftware genutzt werden können. Durch eine anwendungsdienstbezogene Standardisierung des jeweiligen API sollen sowohl der Einsatz der API in der Systementwicklung verstärkt als auch Portabilität und Interoperabilität erhöht werden. Apps, mobil und web-basiert Apps als Kurzform für das englische Applications sind Anwendungsprogramme, die fast ausschließlich auf mobilen Endgeräten, wie Smartphones und Tablets eingesetzt werden. Der Begriff Apps wird häufig mit mobilen Anwendungsprogrammen gleichgesetzt, obwohl teilweise auch bei Microsoft Windows bei Anwendungen auf dem Tablet oder Desktop-­PC von Apps gesprochen wird. Neben den mobilen Apps, die auf den Betriebssystemen mobiler Geräte laufen, unterscheidet man noch web-basierte Apps, die im Webbrowser eines Endgeräts ablaufen.

B

435

Arbeitsplatzrechner Die Verarbeitungsfunktionalität befindet sich am Arbeitsplatz, d. h. das IS stellt sowohl die Verarbeitungskapazität als auch die Anwendungsdienste zur Verfügung. Der Nutzer ist weitgehend unabhängig von anderen IS und kann seine Aufgaben mit den ihm zur Verfügung stehenden Diensten lösen. Das am häufigsten eingesetzte IS am Arbeitsplatz ist der mit entsprechender Software ausgestattete Personal Computer (PC). Architektur eines IS Die Architektur eines IS beschreibt die Struktur und die Verbindungen zwischen den IS-Komponenten, d. h. zwischen Hardware-, Software- und fachlichen Komponenten. Die unterschiedlichen Dienste in der Architektur eines IS beschreiben Programme, welche die Anwendungssoftware benötigt. Die Architektur spezifiziert die Interaktionen zwischen den Komponenten und letztendlich die Details der Schnittstelle zwischen interagierenden Komponenten eines IS. Eine Architektur gilt als offen, wenn die Schnittstellen von allen Produzenten der Komponenten unterstützt werden. Die einzelnen Komponenten können dann einfach integriert werden.

B Benutzeroberfläche Unter einer Benutzeroberfläche wird die Schnittstelle zwischen Nutzer und Software verstanden. Der Begriff umfasst alle Funktionen und Eigenschaften, die den Nutzer bei der Arbeit an einem IS betreffen. Die Benutzeroberfläche zu einer Software legt das Erscheinungsbild und die Bedienung des Systems fest. Die intuitive Benutzbarkeit einer Oberfläche entscheidet oftmals über dessen Erfolg. Die Benutzeroberfläche basiert auf Systemfunktionen, die das Betriebssystem oder die darauf basierende systemnahe Software (z. B. das Fenster-System) bereitstellen. Bei den Oberflächen kommen berührungsempfindliche Bildschirme zum Einsatz, die eine haptische Steuerung ermöglichen. Bei der Beurteilung von Benutzeroberflächen sind hinsichtlich der Hardware und Software die Funktionalität, Präsentation und Ergonomie zu berücksichtigen. Die Anforderungen der Dialoggestaltung aus ergonomischen Gesichtspunkten haben sich in Normen von ISO und DIN niedergeschlagen. Die grundsätzlichen Aspekte beschreibt die ISO 9241: „Visual Display Terminals used for Office Tasks; Ergonomic Requirements“. In die DIN 66234: „Bildschirmarbeitsplätze  – Grundsätze ergonomischer Dialoggestaltung (Teil 8)“ wurden Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität und Fehlerrobustheit übernommen. Hinzu kommen noch ISO-Forderungen nach Individualisierbarkeit und Erlernbarkeit, die noch nicht in die deutsche Norm eingegangen sind.

436

Glossar

Betriebssystem Als Betriebssystem werden die Programme eines digitalen Rechnersystems bezeichnet, die zusammen mit den Eigenschaften der Rechenanlage die Basis der möglichen Betriebsarten des digitalen Rechnersystems bilden sowie die Abwicklung von Programmen steuern und überwachen. Ein Betriebssystem ermöglicht den Zugriff auf die Hardware mittels spezifischer Treiber und verwaltet und steuert diese Hardware. Das Betriebssystem umfasst alle systemnahen Programme, die sog. Systemprogramme. Diese dienen der Durchführung des Betriebs des Rechners. Heutige Rechner sind komplexe Systeme, die aus einer Vielzahl von Komponenten, wie unterschiedlichen Prozessoren, zahlreichen Speichern, Netzwerkmodulen, Bildschirm, Drucker, Scanner, usw. bestehen. Diese einzelnen Komponenten werden vom Betriebssystem verwaltet und ihre Zusammenarbeit gesteuert. Über eine Benutzeroberfläche gewährt das Betriebssystem dem Nutzer den Zugang zu den Applikationen und den systemnahen Programmen. Gängige Betriebssysteme wie Microsoft Windows 10 sind Universalbetriebssysteme, die für verschiedene Zwecke einsetzbar sind (z. B. Büroanwendungen, Kommunikation). Demgegenüber sind Echtzeitbetriebssysteme (z. B. QNX) in der Lage, innerhalb definierter Reaktionszeiten auf externe Ereignisse zu reagieren. Solche Echtzeitbetriebssysteme werden beispielsweise in zeitkritischen Anwendungsfeldern eingesetzt (z.  B.  Anlagenund Verkehrssteuerung). Betriebsarten Rechner sind in dem Unternehmen in unterschiedlichen Ausprägungen im Netz miteinander verbunden oder aber auch als isolierte Rechner vertreten. Nutzung und Betrieb der Rechner hängen von dem jeweiligen Anwendungsgebiet und den sich daraus ergebenden Anforderungen ab. Eine Reihe von Konzepten unterstützt die Umsetzung der Nutzeranforderungen in die unterschiedlichen Betriebsarten. Hinsichtlich der räumlichen Trennung von Komponenten ist zwischen lokaler und entfernter (remote) Verarbeitung zu unterscheiden. Abhängig davon, ob die Verbindung einer einzelnen Komponente (PC, Datenerfassungssystem, Kasse, Scanner, usw.) zum Rechner besteht oder nicht, unterscheidet man zwischen Online- und Offlinebetrieb einer Komponente. Im Onlinebetrieb sind alle Komponenten direkt am zentralen Rechner angeschlossen und nutzen dessen Verarbeitungsbzw. Rechenkapazität. Die entfernte Verarbeitung wird dabei durch die Datenfernverarbeitung realisiert. Im Gegensatz dazu steht der Offlinebetrieb; bei dem Offlinebetrieb sind die betreffenden Komponenten nicht an das IS angeschlossen. Beispielsweise könnten Banküberweisungen zunächst offline eingescannt und überprüft werden, bevor sie dann in den Großrechner eingelesen und die einzelnen Überweisungsaufträge abgearbeitet werden. Der Offlinebetrieb wurde in der Vergangenheit zumeist aufgrund mangelnder Übertragungskapazität, mangelnder Verarbeitungskapazität oder fehlender Speicherkapazität eingerichtet.

B

437

Heutzutage ist Offlinebetrieb entweder eine Backup-Lösung für den Ausfall von Kommunikationsverbindungen oder mit einer höheren Sicherheit, z.  B.  Vertraulichkeit, ­begründet. Unter Realzeitverarbeitung versteht man eine Verarbeitung, bei der die Ergebnisse schritthaltend innerhalb einer vorgegebenen Zeitspanne vorliegen müssen (z. B. im Bereich der Luftverkehrskontrolle oder bei medizinischen Überwachungssystemen). Wenn ein Rechner in mehreren Betriebsarten eingesetzt wird (z. B. Dialogbetrieb, Stapel- und Realzeitverarbeitung), so erhalten Realzeitaufträge die höchste Priorität. Bit Ein binäres Zeichen wird als Bit bezeichnet und stellt entweder eine „1“ oder eine „0“ dar. In der Hardware eines IS bedeutet das Vorhandensein eines elektrischen oder magnetischen Impulses eine „1“, die Abwesenheit wird als „0“ interpretiert. Byte Acht Bits werden zu einem Byte zusammengefasst. Mit einem Byte können maximal 256 verschiedene Ziffern, Zeichen und Symbole dargestellt werden. Die Zuordnung von Ziffern, Zeichen bzw. Symbolen zu den im Byte repräsentierten Daten nennt man Kodierung bzw. Zeichensatz. Verbreitete Kodierungen sind ASCII (American Standard Code for Information Interchange) und EBCDIC (Extended Binary Coded Decimal Interchange Code, für Großrechnersysteme) sowie Unicode. Bluetooth Bluetooth ist ein funkbasiertes Übertragungsverfahren. Seine Reichweite liegt derzeit maximal bei etwa 100 Metern. Es benötigt keinen Sichtkontakt und es können mehrere Geräte gleichzeitig kommunizieren. Die Übertragungskapazität liegt bei max. 1 Mbit/s. BPEL (Business Process Execution Language) Die Business Process Execution Language (BPEL) ist eine XML-basierte Sprache zur Beschreibung von Geschäftsprozessen, deren einzelne Aktivitäten durch Webservices implementiert sind. Das Ziel von BPEL ist, das Programmieren im Großen zu ermöglichen. Hierbei bedeutet Programmieren im Großen, dass zur Implementierung der Geschäftsprozesse die Webservices, welche ihrerseits als kleine, eigenständige Programme bestimmte Funktionen erfüllen, verwendet werden. BPEL ist also eine Beschreibungssprache, die die technische Umsetzung von SOA unterstützt. Dabei ist zu beachten, dass BPEL die direkte Interaktion mit den Nutzern nicht unterstützt. BPEL-Prozesse kommunizieren ausschließlich mit Web Services. Hierbei können die Webservices jedoch eine Benutzerschnittstelle umsetzen.

438

Glossar

BYOD (Bring your own device) Bring Your Own Device (BYOD) ist ein organisatorisches Konzept, das regelt, auf welche Weise Mitarbeiter ihre eigenen Computer bzw. mobilen Endgeräte zu dienstlichen Zwecken nutzen dürfen. Hierbei sind insbesondere der Zugriff auf Netzwerkdienste und das Verarbeiten und Speichern unternehmensinterner Daten kritische Aktivitäten, da fremde Geräte ein potenzielles Sicherheitsrisiko darstellen. Zahlreiche rechtliche Fragen, wie zum Beispiel die Haftung bei Schäden und der Datenschutz, sind zu klären. Wenn private Geräte in einem Unternehmen eingesetzt werden, können unter Umständen Beschaffungskosten gespart werden. Es ist aber aufgrund der Gerätevielfalt mit höheren system-­administrativen Kosten zu rechnen.

C Cache Memory Die Zugriffszeit auf den Hauptspeicher können Cache-Memory-Speicher (Pufferspeicher) verkürzen. Der Cache ist ein Speicherelement mit besonders schnellem Zugriff. Er übernimmt die Funktion eines Puffers, d. h. er nimmt eine Anpassung zwischen der Verarbeitungszeit im Zentralprozessor und der längeren Zugriffszeit zum Hauptspeicher vor. Es werden hierzu im Cache die Inhalte „benachbarter“ Speicherzellen zu den in Bearbeitung befindlichen Speicherzellen aus dem Hauptspeicher bereitgestellt. CASE (Computer Aided Software Engineering) Eine CASE-Umgebung (Softwareproduktionsumgebung) ist eine Menge aufeinander abgestimmter Werkzeuge zur durchgängigen, alle wesentlichen Phasen und Systemsichten abdeckende Unterstützung der Systementwicklung auf der Grundlage einer integrierten Entwicklungsdatenbank (Repository, Enzyklopädie) und phasenübergreifender Hilfsmittel zur Projektplanung und -steuerung. CASE-Umgebungen sind für die Entwicklung von neuen Anwendungen sehr gut geeignet. Solange keine enge Integration mit bestehenden Anwendungen notwendig ist, bietet sich auch die Entwicklung von Insellösungen („Stand alone“-Anwendungen) mit CASE an. Weiterhin wird die Entwicklung interaktiver, datenbankorientierter Anwendungen gut unterstützt, da diese einen standardisierbaren Kontrollfluss haben und deshalb als 4GL-Anwendungen generierbar sind. Zurzeit sind CASE-­ Umgebungen für die Entwicklung komplexer, integrierter Systeme eher ungeeignet, da viele Altlasten aufzuarbeiten sind und große arbeitsteilige Teams unterstützt werden müssen. Ebenso wird die Entwicklung rechenintensiver Anwendungen meist nicht ausreichend unterstützt. Vorstudie und Entwurf des Fachkonzepts sowie Entwurf des IT-Konzepts werden oft als Upper CASE zusammengefasst. Dieses Wortspiel (uppercase = Großbuchstaben) macht deutlich, dass es sich dabei um die eher realisierungsunabhängigen, vorwiegend

C

439

fachbezogenen Aktivitäten der Systementwicklung handelt. Die Aktivitäten der Implementierungs-, Test- und Wartungsphase werden dagegen als Lower CASE zusammengefasst (lowercase = Kleinbuchstaben). Die Aufgliederung in „höhere“ und „niedere“ Aktivitäten macht deutlich, dass der fachliche Entwurf aufwändiger, fehlerträchtiger und anspruchsvoller ist, während die Umsetzung in IS-Komponenten als eher mechanisierbare, oft durch Generatoren automatisierbare Tätigkeit interpretiert wird. Client-Server-Architektur Eine Client-Server-Architektur besteht aus spezialisierten Systemkomponenten (Clients und Server), die sich eine Aufgabenbearbeitung teilen. Die Client-Server-Architektur erlaubt es dabei von einem Anwendungsprogramm (Client) aus, die Dienste eines anderen Anwendungsprogramms (Server) zu nutzen. Man unterscheidet z.  B.  Datenbankserver, Druck-Server, Datei-Server, Rechen-Server, Kommunikations-Server, WWW-Server und Mail-Server. Ein Beispiel für ein verbreitetes ERP-System war das 1992 auf Markt gekommene R/3 von SAP, das sich heute von einer Client-Server-Architektur zu einer serviceorientierten Architektur weiterentwickelt hat. Merkmale einer Client-Server-­ Architektur sind: • Die Dienste der Server stehen unterschiedlichen Anwendungen zur Verfügung. Es liegt keine feste Rollenzuordnung vor, d. h. auch Server können als Clients die Dienste eines anderen Servers beanspruchen. • Clients und Server können auf unterschiedliche Geräte verteilt sein oder aber auch nur auf einem Gerät. • Client-Server-Architekturen benötigen leistungsfähige Kommunikationsdienste. • Durch definierte und standardisierte Schnittstellen kann ein hohes Maß an Mehrfachnutzung und Flexibilität erreicht werden. Content-Management-Systeme (CMS) Mit dem Internet hat die Verwaltung von Inhalten (Content), die z. B. auf einer Website veröffentlicht werden sollen, eine besondere Rolle bekommen. Hierbei fasst man unter Content jede Art von Daten, wie z. B. Bilder, Texte, Grafiken oder Videos zusammen, die verwaltet werden müssen. Nach (Rothfuss und Ried 2003) versteht man unter Content Management die systematische und strukturierte Beschaffung, Erzeugung, Aufbereitung, Verwaltung, Präsentation, Verarbeitung, Publikation und Wiederverwendung von Inhalten (Content). CMS sind technologisch gesehen die Nachfolger der Dokumentenmanagementsysteme (DMS). Im Unterschied zu DMS legen CMS jedoch verstärkt Wert auf Kollaborationsfähigkeiten, Revisionsverfolgung von Inhalten, Steuerung der Zugriffsrechte, Implementierung von Workflows und Typunabhängigkeit bzw. Konvertierungsmöglichkeiten (z. B. Word zu PDF oder Texte zu HTML). Das zentrale Digital Asset Management (DAM) eines CMS verwaltet die Inhalte, also den Content

440

Glossar

(z. B. Bilder, Texte, Dateien), der über ein CMS verarbeitet werden kann. Um Inhalte besser finden zu können, bietet DAM meist die Möglichkeit, Taxonomien und Metadaten anzuwenden bzw. auszuwerten (z.  B.  Tags/Schlagworte, hierarchische Strukturen und Metadatenauswertung). Ein Web CMS stellt einen Sonderfall von CMS dar, da es zur Realisierung von Webseiten dient. Dabei wird von einem CMS gesprochen, auch wenn das Softwaresystem nicht die Anforderungskriterien erfüllt, z. B. fehlt in Web CMS häufig eine Komponente für das Workflowmanagement. Enterprise CMS (ECMS) dienen vorwiegend der Automatisierung von Geschäftsprozessen in Bezug auf Dokumente oder Medieninhalte. Sie verfügen h­ äufig über erheblich mehr Formate zur Dateikonvertierung, welche durch Implementierungen beliebig erweitert werden können. ECMS dienen nicht der Verwaltung von Webseiten, können aber durch workflowbasierte Prozesse Änderungen an diesen vornehmen. Compiler Ein Compiler setzt ein Quellprogramm in ein Zielprogramm bzw. den Objektcode um. Er nimmt dabei eine Fehleranalyse auf der Syntaxebene, eine Speicherbelegungsplanung und die Optimierung des Programmcodes vor. Erst das erzeugte Zielprogramm ist ablauffähig. CPU (Central Processing Unit) Die CPU (Central Processing Unit) kann als Gehirn des Rechners bezeichnet werden. Sie holt die Befehle aus dem Hauptspeicher und führt sie aus. Beim Von-Neumann-Rechner besteht der Zentralprozessor aus einem Steuerwerk und einem Rechenwerk. Das Steuerwerk hat die Aufgabe, die Reihenfolge, in der die Befehle eines Programms ausgeführt werden, zu steuern, die Befehle zu entschlüsseln und die für ihre Ausführung notwendigen digitalen Signale an die integrierten Schaltkreise abzugeben. Die einzelnen Programmbefehle bestehen aus der Operation und den Operanden. Die Operanden enthalten entweder Daten oder die Speicherplatzadressen der Daten. Steuerwerk und Rechenwerk arbeiten nach dem Pipeline-Prinzip miteinander, d. h. ein Befehl wird wie in einer Pipeline zunächst im Steuerwerk und dann im Rechenwerk abgearbeitet. Die einzelnen Programmschritte werden in einem bestimmten Takt ausgeführt. Die Verarbeitungsleistung eines Zentralprozessors hängt von der Taktfrequenz und der pro Befehl benötigten Anzahl von Takten ab. Rechnerleistung [MIPS] =

Taktfrequenz [MHz] Anzahl Takte pro Befehl

MIPS : Million Instructions per Second

Berechnung der Rechnerleistung:

D

441

Beispielsweise besitzt ein Prozessor mit einer Taktfrequenz von 3,6 GHz und vier Takten pro Befehl eine Rechnerleistung von 900 MIPS. Bei der Leistungsfähigkeit der Prozessoren ist in den letzten zwei Jahrzehnten eine rapide Entwicklung zu verzeichnen. Daher ist für die Hardwarebeschaffung stetige Marktbeobachtung und entsprechende Neuorientierung notwendig. Jede CPU besitzt eine feste Menge von Befehlen, die sie ausführen kann. Diese Menge an Befehlen bezeichnet man auch als Befehlssatz. Der Befehlssatz unterscheidet sich bei den einzelnen Prozessortypen.

D Datei Während mit Hilfe einer Zeichenkodierung Informationen in Datenfeldern darzustellen sind, werden auf der nächsten Ebene diese Datenfelder zu Datensätzen zusammengefasst. Die konventionelle Datenhaltung ist durch getrennt verwaltete Dateien gekennzeichnet, in denen die Daten in Form solcher Datensätze verwaltet werden. In den 60er-Jahren hat das DIN das Kunstwort „Datei“ geprägt, und damit die primitivste Form der permanenten Datenhaltung umschrieben. Der Zugriff auf einzelne Datensätze erfolgt zumeist über einen Schlüssel.

Schlüsselfeld(er) identifizieren einen Datensatz

Datenfeld: kleinste Einheit, auf die zugegriffen werden kann.

Datensatz: Strukturierte Daten mit fester Feldeinteilung und Schlüssel

Datei: Zusammensetzung gleichartiger Datensätze

Auau einer Datei

442

Glossar

Dateisystem Ein Dateisystem verwaltet die Daten in Datensätzen innerhalb von Dateien. Die verarbeitenden Elemente – die Programme – benutzen Eingabedaten aus Dateien und liefern Ausgabedaten in Dateien, welche wiederum nachfolgenden Programmen als Eingabedaten dienen können. Die Dateien sind in Form und Inhalt speziell auf die beteiligten Programme abgestimmt.

Anwendungsprogramm 1

Datei A

Anwendungsprogramm 2 Datei B

Anwendungsprogramm n

Datei C

Verarbeitungsorientierte Datenorganisation

Diese verarbeitungsorientierte Sicht der Daten basiert auf der Anwendungsentwicklung in den 60er-Jahren. Die Datenhaltung umfasst die Speicherung, den Zugriff und die Verwaltung von Daten und ist damit ein Kernelement eines IS. Die Organisation der Dateien ist vom Datenträger (z.  B.  Magnetband, Plattenspeicher) und vom Einsatzzweck abhängig und kann seriell, sequenziell, index-sequenziell, direkt oder indirekt erfolgen. Entsprechend der Organisation der Daten existieren verschiedene Zugriffsverfahren. Die Nachteile der konventionellen Datenhaltung (Datenabhängigkeit, Redundanz der Daten, mangelhafte Integritätskontrolle zwischen den Datensätzen, aufwändiger Zugriffsschutz) machen sich insbesondere dort bemerkbar, wo viele Anwendungsprogramme und Benutzer auf einen gemeinsamen Datenbestand zugreifen. Um diese Nachteile auszugleichen, wurde der Ansatz des Datenbanksystems (DBS) entwickelt.

443

D

Datenbank Ein Datenbanksystem (DBS) ist ein Softwaresystem zur Beschreibung, Speicherung und Wiedergewinnung von umfangreichen Datenmengen, die von mehreren Anwendern und mehreren Anwendungen benutzt werden. Es besteht aus der Datenbank, in der die Daten abgelegt werden, und dem Datenbankmanagementsystem (DBMS), das die Verwaltung der Daten durchführt. Mit dem Einsatz von Datenbanken will man: • Verhindern, dass Veränderungen der Daten und ihrer Strukturen zwangsläufig Programmänderungen nach sich ziehen (Datenunabhängigkeit), • verhindern, dass sich jeder Programmierer mit der internen Organisation der Daten befassen muss, • verhindern, dass Daten mehrfach gespeichert werden (Datenredundanz). • unterschiedliche Sichten auf Daten ermöglichen, • ermöglichen, dass Daten mehreren Nutzern gleichzeitig zugänglich sind, • einen Schutz wichtiger Daten vor unberechtigtem Zugriff gewährleisten, und • verhindern, dass jeder Nutzer unkontrolliert auf die Daten zugreifen kann.

AS 1

AS 2

Datenbanksystem Datenbankmanagementsystems

Datenbank

AS n

Aufbau eines Datenbanksystems

Datenbankmanagementsystem (DBMS) Zu den Aufgaben des DBMS gehören u. a. die Beschreibung der Daten, die Speicherung und der gezielte Zugriff, sowie die Bereitstellung von Verarbeitungsfunktionen (z. B. die Berechnung von Summe und Durchschnitt). Die Integration von Daten unterschiedlicher

444

Glossar

Anwendungen und die zentrale Beschreibung und Strukturierung der Datenbestände unterstützen die Erstellung und Änderung von Anwendungsprogrammen. Datenbank, Integritätsregeln Das Ziel von Integritätsregeln ist es, sicherzustellen, dass nur „korrekte“ Daten in Datenbanken (DB) enthalten sind. Der Zugriff auf die Daten erfolgt über Schlüssel. Ein Primärschlüssel (Hauptordnungsbegriff) ist ein Datenfeld (oder die Kombination mehrerer ­Datenfelder), welcher die einzelnen Datensätze eindeutig identifiziert. Ein Fremdschlüssel bezeichnet ein Datenfeld (oder die Kombination mehrerer Datenfelder) eines Datensatzes, welches einen Bezug zu einem anderen Datensatz herstellt. Welche Daten korrekt sind, wird in den Integritätsregeln festgelegt. Man unterscheidet folgende Integritätsregeln (Sauer 1998; Reinhart 1995): • Bei der Wertebereichsintegrität muss der Wert aller Schlüsselattribute einer Tabelle innerhalb eines vorgegebenen Wertebereichs liegen. • Bei der Integrität der Entität muss jede Tabelle einen Primärschlüssel enthalten. Keine Komponente des Primärschlüssels darf einen „NULL“-Wert enthalten. Hierbei bezeichnet der „NULL“-Wert den nicht vorhandenen Inhalt eines Datenfelds. • Bei der referenziellen Integrität muss es für jeden Wert eines Fremdschlüssels ungleich einem „NULL“-Wert in einer anderen Tabelle der DB einen entsprechenden Primärschlüssel mit diesem Wert geben. • Die semantische Integrität beinhaltet Zustands-, Übergangs- und Ablaufbedingungen bezüglich der Nichtschlüsselattribute aus der Sicht eines speziellen Anwendungsprogramms. DBS bieten die Möglichkeit, Integritätsregeln innerhalb der Ausdrucksmittel des DBS zu formulieren und deren Überwachung dem DBS zu überlassen. Datenbank, Architekturkonzept Datenunabhängigkeit der Anwendungsprogramme, Abfragemöglichkeiten im Dialogbetrieb und die zentrale Verwaltung der Daten setzen ein bestimmtes Architekturprinzip voraus. Das wesentliche Element eines solchen Konzepts ist die einheitliche Beschreibung der Daten für alle Anwendungsprogramme. Um eine Basis für diese in der Praxis schwierige Entwurfsaufgabe zu schaffen, wurde das 3-Schema-Konzept entwickelt. Die Beschreibung der Daten einer Datenbank erfolgt nach diesem Konzept in drei Schemata, die aus unterschiedlichen Blickrichtungen die Datenstrukturen in einer Datenbeschreibungssprache definieren. Im Mittelpunkt steht das konzeptionelle Schema, das die logische Gesamtstruktur der Daten, ihrer Eigenschaften und ihrer Beziehungen untereinander unabhängig von der Sicht einzelner Anwendungen und der physikalischen Speicherungsstruktur darstellt. Dieses Schema ist die Grundlage für das externe und das interne Schema. Das interne Schema beschreibt die implementierungsabhängige Sicht der Daten (z. B. die physikalische Organisation und die Zugriffspfade). Eine Anpassung dieser Sicht an die gegebene Rechnerausstattung beeinflusst die Effizienz des Systems.

D

445

Mithilfe einer Datendefinitionssprache kann für jede Anwendung, für jeden Benutzer bzw. Benutzergruppe im externen Schema eine Sicht auf die Daten der Datenbank definiert werden. Datenbank, Datenschutz Unter Datenschutz in Datenbanksystemen versteht man Schutzmaßnahmen, die den Zugriff auf die Daten in der Datenbank regeln. Datenbanken sollten folgende Anforderungen zum Schutz der Daten erfüllen: • Abgestufte Schutzeinheiten. Es können Grade der Schutzbedürftigkeit definiert und unterschiedliche Einheiten wie Dateien, Tabellen, Datensätze oder Felder geschützt werden. • Eindeutige Schnittstellen. Der Zugang zur Datenbank darf nur über die vorgesehenen Schnittstellen möglich sein. • Dezentrale Autorisierung. Die Vergabe und der Entzug der Zugriffsbestimmungen auf bestimmte Datengruppen innerhalb einer Datenbank sollen von zuständigen Fachabteilungen möglich sein. Ansonsten muss jede Veränderung einer Zugriffsberechtigung über eine zentrale Stelle erfolgen. • Dynamische Autorisierung. Vergabe und Entzug von Zugriffsberechtigungen muss im laufenden Betrieb möglich sein. • Kooperative Autorisierung. Bei besonders schutzbedürftigen Daten muss die Möglichkeit bestehen, das Zugriffsrecht zu diesen Daten von der gemeinsamen Zustimmung mehrerer Instanzen abhängig zu machen, wie etwa die Zugriffsberechtigung zu einem Tresor von mehreren Personen über mehrere Schlüssel, die gleichzeitig eingeschoben werden müssen. • Datenfluss- und Inferenzkontrolle. Verhinderung der Zwischenspeicherung von geheimen Daten in temporäre Dateien und Verhinderung der Rekonstruktion von Daten durch Inferenz der Ergebnismengen aufeinander folgender Anfragen.

446

Glossar

Data Dictionary/Data Repository Im Rahmen des Datenmodells besitzt das Data Dictionary sowohl für die Datenbankadministration als auch für die Softwareentwicklung eine besondere Bedeutung. Ein Data Dictionary ist eine Art Lexikon (Metadaten), in dem die Informationen über die in der Datenbank gehaltenen Daten verwaltet werden. Datenbanksprachen Die Datenbanksprachen beinhalten mindestens die Datendefinitions- und die Datenmanipulationssprachen. Mittels einer Datendefinitionssprache werden die Daten für die Speicherung in der Datenbank definiert, d. h. es wird beispielsweise festgelegt, welche Tabellen (z. B. Kunden- und Artikeltabelle) und welche Felder in den Tabellen die Datenbank enthalten soll. Der Zugriff auf die Daten (Eingabe, Änderung, Löschung und Abfrage) erfolgt mithilfe der Datenmanipulationssprache. Hiermit können beispielsweise einzelne Datensätze gesucht werden oder neue Datensätze (z. B. ein neuer Kunde) in die Datenbank eingegeben werden. Bei den Datenmanipulationssprachen können navigierende (Angabe, wie eine Menge von Daten aus der Datenbank gebildet werden soll) und deskriptive Ansätze (Beschreibung der Eigenschaften der gewünschten Daten) unterschieden werden. Zur Datendefinition und Datenabfrage empfiehlt sich grundsätzlich die Verwendung von standardisierten Schnittstellen, um eine Unabhängigkeit der Programme von speziellen DBS zu gewährleisten. Durch die Entwicklung von standardisierten Abfragesprachen wird eine leichtere Portierbarkeit der Anwendungen erreicht (siehe auch SQL). Datenbankserver Ein Datenbankserver ist ein dedizierter Rechner, der die Datenverwaltung für mehrere Clients gemeinsam übernimmt. Basierend auf dem Konzept der Client-Server-Architektur kommunizieren ein oder mehrere Frontend-Prozesse (Anwendungen) mit einem Backend-­ Prozess (Datenbank). Dieser Vorgang läuft im Allgemeinen auf mehreren Rechnern unter Nutzung entsprechender Kommunikationsdienste ab. Die Datenbank muss die Client-­ Server-­Architektur unterstützen. Datenmodelle DBS bieten jeweils eine einheitliche Datenstruktur an, auch als zugrunde liegendes Datenmodell bezeichnet, die als Basis für die Benutzerabfragen und die Anwendungsentwicklung dient. Man unterscheidet zwischen hierarchischen, netzwerkartigen, relationalen sowie objektorientierten Datenbanksystemen. Datensicherung Durch Hardwarefehler und vor allem durch Bedienungsfehler können Daten in einem IS zerstört werden. Auch durch Feuer oder Wassereinbruch kann es zum Verlust der Daten kommen. Eine Plattenspiegelung (Mirroring) bietet zwar teilweisen Schutz vor einem Datenverlust, der durch Hardwarefehler verursacht wurde, bewahrt aber nicht vor Fehlbedienungen, Softwarefehlern sowie bewussten Zerstörungsmaßnahmen (wie z. B. durch

D

447

­ iren). Daher ist es zu empfehlen, alle Daten regelmäßig auf einem Backup-Träger (DaV tenspeichermedium zur Datensicherung) zu sichern und diese an einem sicheren Ort aufzubewahren. Hierzu gibt es spezielle Dienstprogramme, die eine regelmäßige Datensicherung unterstützen, sowie Verfahren, die eine stufenweise Datensicherung und eine entsprechende Restaurierung der Daten organisatorisch vorschreiben. Für die Datensicherung gibt es eine Reihe wechselbarer Datenträger. Datenübertragung Nach DIN 44302 versteht man bei der Datenübertragung unter einer Schnittstelle alle Festlegungen über die physikalischen Eigenschaften des Transportmediums, die Bedeutung der ausgetauschten Signale und die gegenseitige Abhängigkeit der ausgetauschten Signale. Bei der Datenübertragung wird nach der Synchronisation der angeschlossenen Datenstationen unterschieden. Zu Beginn der synchronen Datenübertragung werden vom Sender Steuerzeichen abgesendet, um Sender und Empfänger auf den gleichen Übertragungstakt einzustellen. Die einzelnen Bits der Daten werden mit gleichbleibender Geschwindigkeit übertragen. Wenn keine Daten zu übertragen sind, müssen Füllzeichen gesendet werden, um den Übertragungstakt beizubehalten. Bei der asynchronen Übertragung werden vor der Übertragung jedes Zeichens Startbits, darauf folgend dann die Bits des Zeichens und danach Stoppbits gesendet, um Anfang und Ende eines Zeichens anzukündigen. Wegen der großen Anzahl zusätzlicher Steuersignale ist die asynchrone Übertragungsart zwar langsamer als die synchrone, braucht aber nicht ständig Füllzeichen zu senden. Neben Festlegungen über Schnittstellen und Übertragungsverfahren müssen Vereinbarungen über den organisatorischen Ablauf jeder Datenübertragung getroffen werden, insbesondere über die verwendeten Datenformate und Kommandos. Solche Vereinbarungen heißen Protokolle. Domain Name System (DNS) Das Domain Name System (DNS) wird für den Abgleich von logischen Namen von Servern im Internet zwischen Domain Name Servern (DNS-Servern) und zur Steuerung des Zugriffs vom Client auf den zuständigen Name Server benutzt. Durch den Domain Name Service (DNS) kann zu einem Domänennamen (z.  B. de.wikipedia.org) die eindeutige IP-Adresse ermittelt werden (z. B. 91.198.174.192). Downsizing In einigen Unternehmen werden zentrale IS durch Client-Server-basierte Lösungen ersetzt. Ein Hauptgrund hierfür liegt bei den seit Jahren sinkenden Preisen für Prozessorund Speicherleistung von PCs. Der Vorgang, dass Anwendungen von Großrechnern auf kleinere Systeme wie zum Beispiel PCs übertragen werden, wird als Downsizing bezeichnet. Die Entscheidung für ein Downsizing hat neben geringeren Kosten für die Hardware auch Auswirkungen auf betriebliche Organisationsstrukturen und Organisationsabläufe, auf Schulungen sowie die System- und Anwendungssoftware.

448

Glossar

3D-Druck Unter 3D-Druck versteht man das direkte Fertigen von dreidimensionalen Objekten. Im Gegensatz zu anderen Fertigungsmethoden, wie dem Drehen oder Fräsen, wird das zu fertigende Werkstück nicht aus einem Stück Rohmaterial gefertigt indem man Material entfernt. Beim 3D-Druck wird das zu erzeugende Objekt direkt in seiner fertigen Form aus dem entsprechenden Werkstoff aufgebaut. Der 3D-Druck zählt daher aus fertigungstechnischer Sicht zu den Urformverfahren und wird allgemein als additives, generatives oder auch aufbauendes Fertigungsverfahren bezeichnet. Aktuelle 3D-Drucker arbeiten komplett computergesteuert. Man entwickelt ein dreidimensionales Modell mit Computer Aided Design, welches anschließend der Steuerung des 3D-Druckers übergeben wird. Dieser zerlegt das Modell in zweidimensionale Schichten entlang der Höhenachse des Modells. Diese Schichten werden anschließend von unten nach oben durch den 3D-Drucker aufgebaut, bis letztlich das gesamte 3D-Computermodell physisch vorhanden ist. Dynamic Host Configuration Protocol (DHCP) Aufgrund des gegenwärtig begrenzten Adressraums im Internet und um Netzwerkänderungen leichter durchführen zu können, kommt DHCP (Dynamic Host Configuration Protocol) zum Einsatz. Ein DHCP Server verwaltet einen Pool von IP-Adressen. Jeder Rechner meldet sich beim DHCP Server an und erhält für die aktuelle Sitzung eine temporäre, aber eindeutige IP-Adresse aus dem verfügbaren Satz von IP-Adressen (des Unternehmens) zugewiesen (siehe auch TCP/IP).

E Einprogrammbetrieb Beim Einprogrammbetrieb (Single Tasking) werden einzelne Benutzeraufträge vom Rechner nacheinander bearbeitet. Das heißt, es befindet sich jeweils ein Benutzerauftrag (Programm) in der Bearbeitung des Rechners. Die notwendigen Ressourcen (oder auch Betriebsmittel) des Rechners (Prozessor, Speicher, periphere Geräte, usw.) werden entsprechend dem Programm zugeteilt. Endbenutzersprachen Eine Weiterentwicklung der prozeduralen Programmiersprachen sind die Endnutzersprachen oder auch Sprachen der 4. Generation (4GL). Endbenutzersprachen eignen sich für einen Entwicklungsansatz, bei dem der Anwender in den Fachabteilungen IS zur Unterstützung oder Automatisierung der eigenen Aufgaben erstellen. Dieser Ansatz wird bisweilen auch als Individuelle Datenverarbeitung (IDV) bezeichnet. Zwei Kategorien von Endbenutzersprachen gehören nach heutigem Verständnis zu den 4GL-Sprachen: • Integrierte Abfragesprachen, Reportgeneratoren und ein umfassendes Endbenutzersystem, und • komplexe Werkzeuge für die Entwicklung von IS durch Entwickler mit möglichst wenig geschriebenem Programmcode bzw. basierend auf Modellen.

F

449

Die 4GL-Systeme sind eng mit Datenbanksystemen gekoppelt. Als Endbenutzersprache bezeichnet man beispielsweise die relationale Datenbanksprache SQL, die für eine Vielzahl von Computersystemen existiert und zu einem de facto Standard für relationale Datenbanken geworden ist. Eine weitere 4GL-Sprache ist ABAP (Allgemeiner Berichtsaufbereitungsprozessor oder Advanced Business Application Software) von SAP, die für die Entwicklung und Erweiterung der SAP ERP-Software konzipiert wurde. Auch Visual Basic for Applications (VBA), das in unterschiedlichen Office-Produkten von Microsoft zur Verfügung gestellt wird, ist als Endbenutzersprache zu erfassen. Extranet Wenn in einem firmeneigenen Intranet ausgewählten Personengruppen oder Unternehmen selektiv der kontrollierte Zugriff auf dieses Intranet und damit auf die Firmendaten gewährt wird, dann spricht man von einem Extranet.

F Firewall-Konzept Im Rahmen der zunehmenden Vernetzung von Haushalten und Unternehmen erhalten weite Personenkreise Zugang zu Daten und anderen Ressourcen einer Organisation. Eine Firewall (Brandmauer) soll sicherstellen, dass Bedrohungen aus einem Weitverkehrsnetz (WAN) nicht auf das lokale Netzwerk (LAN) übergreifen können. Es soll unerwünschte Personen von dem Zugriff auf sensible Unternehmensdaten fernhalten.

Computer

Server

Computer

LAN

Computer

Firewallrechner

Auau eines LAN mit Firewall

WAN

450

Glossar

Der Firewall-Rechner überwacht und protokolliert die Zugriffe, die von außerhalb des überwachten Bereichs erfolgen. Dabei werden alle Datenpakete nach ihrem Absender untersucht. Wenn nicht-legitimierte Zugriffe identifiziert werden, dann erfolgt eine Sperrung des Zugriffs auf die Ressourcen. Weiterhin wird der Zugriff protokolliert, um Einbruchsversuche erkennen zu können (Intrusion Detection). FTP (File Transfer Protocol) Das File Transfer Protocol (FTP) ermöglicht das Kopieren von Dateien über das Netz. FTP enthält Steuerfunktionen zur Zeichendarstellung, zur Einstellung der Dateistruktur und des Übertragungsmodus sowie Befehle für den Zugriffsschutz (siehe auch TCP/IP).

G Grid Computing Die Entwicklung des Grid Computing ist motiviert durch die gemeinsame, koordinierte Nutzung von Ressourcen (wie z. B. Rechner, Datenbanken, Speicher, Anwendungen oder auch Messgeräte) und die gemeinsame Lösung von Problemen innerhalb dynamischer, institutionsübergreifender, virtueller Organisationen. Die typischen Aufgaben, bei denen sich Grid Computing anbietet, sind solche, die die Leistung einzelner Computer überfordern. Dazu gehören beispielsweise die Integration, Auswertung und Darstellung von sehr großen Datenmengen aus der naturwissenschaftlichen und medizinischen Forschung. Grid Computing wird auch in der Meteorologie und für rechenintensive Simulationen in der Industrie eingesetzt. Ein Grid koordiniert Ressourcen, die keiner zentralen Stelle untergeordnet sind, um Dienste zur Lösung komplexer Probleme unter gemeinsamer ­Verwendung der Ressourcen bereitzustellen. Hierfür verwendet es offene und standardisierte Protokolle und Schnittstellen. In diesem Zusammenhang werden u. a. Bereiche Sicherheit, Abrechnung und Mitgliedschaft berücksichtigt. Groupware Groupware stellt Funktionen und Dienste zur Verfügung, die die Teamarbeit unterstützen sollen. Die Zusammenarbeit und der Austausch von Ideen im Team sollen durch die folgenden Fähigkeiten von Groupware-Systemen erleichtert werden: • • • • •

Gemeinsame Texterstellung und Textkommentierung, Planung von Besprechungs- und Einzelterminen, elektronische Besprechungen, Diskussionsgruppen und Konferenzen, gezielte E-Mail-Verteilung, und gemeinsame Dateien, Verzeichnisse und Datenbanken.

Speziell soll Groupware auch die Zusammenarbeit in der Gruppe über zeitliche und/oder räumliche Distanzen hinweg unterstützen. Hierzu sind die einzelnen Mitarbeiter über ein

H

451

Netzwerk miteinander verbunden. Die Arbeiten finden am lokalen Arbeitsplatz statt. Durch Groupware soll insbesondere auch die Zusammenarbeit von räumlich verteilten Teams unterstützt werden. Die Fähigkeiten des Internets haben zu zahlreichen Erweiterungen von Groupware Systemen geführt. Webbrowser wie Firefox sowie Webmailprogramme wie Googlemail haben Groupwarefunktionen, wie zum Beispiel elektronische Diskussionsgruppen oder Video- bzw. Audiokonferenzen, in ihr Leistungsspektrum integriert. Weit verbreitete Groupware-Systeme sind IBM Notes, Microsoft Sharepoint und Slack. Auch Wikis können als Groupware eingesetzt werden und die Teamarbeit unterstützen.

H Hardware Hardware ist der Sammelbegriff für die mechanischen und elektronischen Bestandteile eines IS (siehe auch Software). Hauptspeicher Der Hauptspeicher, oftmals auch als interner Speicher bezeichnet, dient dazu, Programme, Daten und Zwischenergebnisse temporär zu speichern. Hierzu sind Prozessor, Hauptspeicher und die anderen Hardwarekomponenten mittels Bussen oder Kanälen miteinander verbunden. Für den gezielten Zugriff auf Programmbefehle oder Daten sind die Speicherzellen fortlaufend adressiert. Der Hauptspeicher wird oftmals auch als RAM (Random Access Memory) bezeichnet, da im RAM wahlfrei auf eine spezielle Adresse zugegriffen werden kann. Zudem ist RAM flüchtig, d. h. der Speicher verliert beim Abschalten des Stroms seinen Inhalt. Die Grundlage für die Verarbeitung und die Speicherung von Daten sind die Zeichenkodierungen ASCII, EBCDIC und Unicode. Spezielle Hauptspeicherarten stellen die Festwertspeicher ROM (Read Only Memory), PROM (Programmable Read Only Memory) und EPROM (Erasable Programmable Read Only Memory) dar. Diese Speicher sind im Gegensatz zum RAM nicht flüchtig, d. h. sie verlieren ihre Daten nicht, wenn der Strom abgeschaltet wird. Sie dienen dazu, spezielle Programme, z. B. zum Laden des Betriebssystems, und unveränderliche Anwendungsprogramme des Kunden zu speichern (z. B. in der Prozessteuerung). HTTP (Hypertext Transfer Protokoll) siehe WWW. HTML (Hypertext Markup Language) Die Präsentation von Informationen im WWW basiert zumeist auf der Auszeichnungssprache HTML (Hypertext Markup Language). HTML ist eine vereinfachte Untermenge des internationalen Standards SGML (Standard Generalized Markup Language). Markups ordnen jedem Textabschnitt mithilfe eines speziellen Formatbefehls (Markup) ein

452

Glossar

bestimmtes Format zu. Das Programm, das dann den Textabschnitt interpretiert, kann mit seinen proprietären Möglichkeiten den Text im gewünschten Format darstellen. HTML-­Dokumente bestehen daher aus ASCII-Text mit Formatbefehlen, die sich erst durch die Interpretation durch einen Webbrowser (wie z. B. Firefox, Opera oder Microsoft Explorer) als Grafikdokument darstellen. Daher beträgt auch der Speicherplatz nur einen Teil dessen, was die meisten proprietären Dateiformate fordern. Zudem sind HTML-Dokumente sehr portabel, da sie von jedem Webbrowser verarbeitet werden können und somit auch auf nahezu jeder Hardware darstellbar sind. Da es sich bei den HTML-Dokumenten um reine ASCII-Texte handelt, kann ihre Erstellung mit jedem beliebigen Text-Editor erfolgen. Um sie zu erstellen, muss man aber nicht unbedingt HTML „programmieren“, sondern man kann diese auch mit sog. HTML-Generatoren automatisch erzeugen. Dies erfolgt zumeist auf der Basis eines grafischen Designs. Die HTML-Generatoren kann man nach speziellen HTML-Editoren, für die keine HTML-Kenntnisse benötigt werden, und nach tag-orientierten HTML-Editoren, welche HTML-Kenntnisse voraussetzen, unterscheiden. In HTML werden die Auszeichnungspaare als Tags bezeichnet. Tags dienen dazu, die Eigenschaften der Elemente eines HTML-Dokuments zu definieren. Beispielsweise definiert kursiv, dass das Wort „kursiv“ im HTML-Dokument kursiv dargestellt wird. Je nach dem Funktionsumfang der einzelnen Werkzeuge können entweder nur einfache oder auch komplexe Webseiten entwickelt werden. Bei der Entwicklung von komplexen Webseiten kann es notwendig bzw. empfehlenswert sein, den generierten HTML-­Text manuell nachzubearbeiten.

I Informationssystem Ein IS ist integriert, wenn die Komponenten aufeinander abgestimmt sind, der Übergang zwischen einzelnen Komponenten weitgehend automatisiert erfolgt und die verwendeten Daten frühzeitig erfasst und allen Komponenten über eine gemeinsame Datenbank zur Verfügung gestellt werden. Ein integriertes IS stellt eine durchgängige Benutzeroberfläche zur Verfügung, sodass die Anwendungen des IS in ihrer Präsentation, ihrem Verhalten und ihrer Funktionalität konsistent sind. Mehrere IS können über ein Übertragungsmedium über größere Entfernungen miteinander verbunden sein. Hierbei werden spezielle Anwendungsdienste des Unternehmens oder öffentlich verfügbare Dienste (wie z. B. Internet) in Anspruch genommen (siehe auch Peer-to-Peer Computing, Grid Computing und Web Services). In lokal vernetzten Systemen sind mehrere IS über ein Übertragungsmedium miteinander verbunden. IS stellen als Arbeitsplätze einzelne Anwendungsdienste zur Verfügung. Weitere Dienste ergeben sich aus der Verbindung der IS (wie z. B. elektronische Post). Einige Anwendungsdienste sind nur auf bestimmten Systemen in diesem Netz verfügbar. Man geht davon aus, dass die einzelnen Systeme in einem räumlich begrenzten Gebiet bzw. in einem Unternehmen

I

453

angesiedelt sind. Die Gründe hierfür sind zum einen technischer Natur (unzureichende Übertragungskapazität) und zum anderen organisatorischer Natur (IT-Sicherheit). Ein zentrales IS besteht aus einem zentralen Rechner, meist einem Großrechner. Dieser zentrale Rechner stellt Verarbeitungskapazität und die notwendigen Anwendungsdienste an den Arbeitsplätzen zur Verfügung. Es findet nahezu keine Ausführung von Anwendungsprogrammen an den Arbeitsplätzen statt. Interoperabilität Ein Informationssystem unterstützt das Qualitätsmerkmal Interoperabilität, wenn es Mechanismen zur Verfügung stellt, um Informationen mit anderen IS auszutauschen. Internet Als weltumspannender dezentraler Verbund von Rechnernetzen bietet das Internet unterschiedliche Dienste zum Nachrichten- und Datenaustausch an. Die einzelnen Rechnernetze sind über Datenleitungen miteinander größtenteils permanent verbunden. Hierbei verbinden Transkontinentalkabel und Satelliten die Hauptverbindungswege der Kontinente, an welche sich die regionalen und nationalen Internetdienstleister (Internet Service Provider, ISP) anbinden. Das Internet verwendet als Transportprotokoll TCP/IP und bietet seinen Nutzern u.  a. die hierauf basierenden Dienste wie Elektronische Post oder File Transfer Protocol (FTP) an. Weitere Internetdienste sind: • World Wide Web (WWW): hypertext-basiertes, intuitives Navigieren im Internet, • Echtzeit-Audio, und • Echtzeit-Video. Die heutige Popularität erreichte das Internet insbesondere durch die Einführung grafischer Benutzeroberflächen zur Navigation im WWW. Hiermit wurde das Internet weltweit zum größten Marktplatz von Informationen, da es für jedermann leicht zugänglich ist. Interpreter Ein Interpreter ist ein Übersetzungsprogramm, das jeden Befehl einzeln in Maschinensprache übersetzt und sofort ausführt, ohne einen Objektcode zu generieren. Interpreter beschleunigen den Programmtest, erzeugen jedoch langsameren Programmcode als Compiler. Intranet Unternehmen setzen TCP/IP und die hierauf aufbauenden Dienste und Werkzeuge für die Zusammenarbeit und Kommunikation in der Unternehmen ein. Man spricht von einem Intranet. Hierbei können drei Wege eingeschlagen werden, um zu verhindern, dass unbefugte Personen in das firmeneigene Intranet gelangen. Man kann ein internes vom Internet unabhängiges WAN (z. B. mittels gemieteter Standleitungen) auf der Basis von TCP/IP

454

Glossar

aufbauen. Ein solches Netz ist sicher und zuverlässig, aber auch teuer. Alternativ können bestimmte Teile des firmeninternen Netzes über Firewalls an das Internet angeschlossen werden. Dieser Lösungsweg ist relativ preiswert, da für die Fernverbindungen das Internet genutzt wird. Die Daten sind auf ihrem Weg im Internet allerdings nicht sicher. Beim dritten Weg wird das Internet als virtuelles privates Netz (VPN) genutzt, in dem zusätzlich zu Firewalls die Daten nur verschlüsselt verschickt werden. ISO-OSI-Referenzmodell Das ISO-OSI-Referenzmodell dient neben der Unterstützung der Kommunikation zwischen unterschiedlichen Systemen auch dazu, die unterschiedlichen Netzdienste in ihrem Leistungsumfang, d. h. welche Schichten sie abdecken und damit welche Dienste sie anbieten, zu beurteilen. Die Protokolle des ISO-OSI Referenzmodells (siehe folgende Abbildung) lassen sich nach den Funktionen der Schichten in die folgenden zwei Bereiche gliedern: Transportsystem (Schichten 1–4) und Anwendung (Schichten 5–7).

6

Datendarstellungsschicht

5

Sitzungsschicht

4

Transportschicht

3

Netzschicht

2

Sicherungsschicht

1

Physikalische Schicht

Transportdienste

Anwendungsschicht

Anwendungsdienste

7

ISO-OSI Referenzmodell

Die physikalische Schicht (Schicht 1), auch Bitübertragungsschicht genannt, hat die Aufgabe, ungesicherte Verbindungen zwischen Systemen für die Übertragung von Bits zur Verfügung zu stellen. Zu diesem Zweck werden die physikalischen, elektrischen und mechanischen Eigenschaften an der Schnittstelle zwischen Endsystem bzw. Transitsystem und Datenübertragungseinrichtung zur Herstellung, Aufrechterhaltung und zum Abbruch einer physikalischen Verbindung festgelegt.

L

455

Die Sicherungsschicht (Schicht 2) hat die Aufgabe, den Bitstrom der Schicht 1 gegen Übertragungsfehler abschnittsweise zu sichern. Hierzu wird der Bitstrom zwischen Systemen in Blöcke unterteilt, und auf diese Blöcke werden Methoden zur Erkennung und Behebung von Fehlern angewandt. Die Netzschicht (Schicht 3), häufig auch Vermittlungsschicht genannt, hat die Aufgabe, innerhalb eines Netzes die einzelnen Übertragungsabschnitte einer Verbindung richtig aufzubauen, verfügbar zu halten und kontrolliert abzubauen. Die Transportschicht (Schicht 4) hat die Aufgabe, die Kommunikationsteilnehmer von unnötigen Details der Benutzung unterlagerter netzabhängiger Dienste zu befreien und Daten transparent zu übertragen. Die Sitzungsschicht (Schicht 5) hat die Aufgabe, die Sprachmittel für Aufbau, Durchführung (insbesondere Synchronisation, d. h. der Abstimmung des Dialogs) und Abbau einer Kommunikationsbeziehung (Sitzung genannt) zur Verfügung zu stellen. Eine weitere wichtige Aufgabe der Sitzungsschicht ist es, die Defekte, die aus einem Zusammenbruch des Transportsystems resultieren, zu beheben. Die Aufgabe der Darstellungsschicht (Schicht 6) ist es, die Dateneinheiten, die zwischen den eigentlichen Kommunikationspartnern (den Anwendungsinstanzen) auszutauschen sind, unter Erhaltung ihres Informationsgehalts zu übertragen. Die Aufgabe der Anwendungsschicht (Schicht 7) ist es, den Anwendungsinstanzen den Zugang zur ISO-Welt zu ermöglichen. Die Dienste der Anwendungsschicht werden direkt von den Anwendungsinstanzen benutzt. Beispiele hierfür sind Datenbankanwendungen, virtuelle Terminals, Dateiübertragung (file transfer) und Nachrichtenaustausch (electronic mail). ISP (Internet Service Provider) Die ISPs stellen ihren Kunden Einwahlknoten zur Verfügung, um sich an das Internet anzuschließen. Die lokalen Zugangspunkte (Point of Presence, POP) werden bei einigen ISPs von unabhängigen Firmen, die mit den ISPs kooperieren, aufgebaut und verwaltet.

L LAN (Local Area Network) – WAN (Wide Area Network) Architekturen von Netzwerken lassen sich aufgrund der zu überbrückenden Entfernungen wie folgt differenzieren: • Local Area Network (LAN). Meist im Gelände oder Grundstücksbereich eines Unternehmens, und • Wide Area Network (WAN). Weitverkehrsnetze, teilweise auch länderübergreifend.

456

Glossar

Leitergebundene Übertragungsmedien Die über verdrillte, mehradrige Leitungen, wie z. B. Telefonkabel, erreichbaren Übertragungsraten hängen von der Qualität des Kabels und den zu überbrückenden Entfernungen ab. Die Übertragungsraten liegen bei 100 MBit/s im Meterbereich und bei einigen KBit/s im Kilometerbereich. Verdrillte Kabel sind relativ preisgünstig, leicht zu verlegen und haben eine einfache Anschlusstechnik. Sie haben aber nur eine begrenzte Leistungsfähigkeit und sind sehr störanfällig. Aus diesem Grund kommt optische Übertragungstechnik zum Einsatz. Sie ermöglicht die Nutzung der Lichtwellenleiter (Glasfaserkabel, fiberoptisches Kabel) und den Vorstoß in den Hochgeschwindigkeitsbereich mit Übertragungswerten bis in den GigaBit-Bereich. Es ist eine maximale Länge von bis zu 100 km ohne Verstärker möglich. Der ­Lichtwellenleiter besteht in seiner äußeren Schicht aus einem Kunststoff, in dem sich ein äußerer Lichtleiter und ein in diesem koaxial eingebetteter innerer Lichtleiter befinden. Es erfordert eine andere Übertragungstechnik mit Sende- und Empfängerbausteinen. In der Summe der technischen Eigenschaften sind die Lichtwellenleiter den Koaxialkabeln überlegen. Sie sind gegenüber elektrischen und magnetischen Störungen unempfindlich, besitzen eine hohe Abhörsicherheit, ein geringes Kabelgewicht, einen kleinen Kabelquerschnitt und überzeugen durch eine hohe Übertragungskapazität. Jedoch sind sie relativ teuer, insbesondere wenn eine sehr hohe Leistungsfähigkeit nicht benötigt wird. Lokale Netze (LAN) Der Anwendungsbereich der lokalen Netze ist die Kommunikation „im Haus“ bzw. im Nahbereich bis zu einigen Kilometern Reichweite. Die wesentlichen Merkmale eines lokalen Netzes sind: • Kurze Reichweite, einige 100 m bis zu wenigen km bei Verwendung von Kupferkabeln, meist als Koaxial-Kabel, und bis zu 20 km bei Verwendung von Glasfasern, • hohe Bandbreite, bei Kupferkabeln üblicherweise bis zu 20 MBit/s, bei Verwendung von Glasfaser zwischen 100 und 650 MBit/s, und • niedrige Fehlerrate, weniger als 10−9 auf der Bitübertragungsschicht. Ein lokales Netzwerk unterstützt unterschiedliche Arten des Verbunds. Der Datenverbund ermöglicht den Zugriff auf die im Netz verteilt gespeicherten Daten. Die Fähigkeit des Netzes, jedem Endgerät einen Zugang zu anderen Endgeräten im Netz bereitzustellen, erlaubt die Implementierung von Server-Funktionen. Wenn Daten von Clients an Server übertragen werden, stehen diese Daten auch anderen Nutzern im Rahmen ihrer Zugangsberechtigung zur Verfügung. Der Betriebsmittelverbund ermöglicht die Nutzung der im Netz vorhandenen Software und Hardware durch alle angeschlossenen Rechner. Bei der gemeinsamen Nutzung von Hardware ermöglicht der Server den Clients, die Serverhardware gemeinsam zu nutzen. So bieten Druckerserver den Clients die Möglichkeit, die Ausgabe auf den jeweiligen Drucker zu lenken, der die gewünschte Qualität liefert.

M

457

Kommunikationsserver stellen eine Einrichtung dar, die von den Clients genutzt wird, um über sog. Gateways mit anderen Rechnernetzen zu kommunizieren (Kommunikationsverbund). Die Leistung des Servers besteht hierbei in der Anpassung der beteiligten Netze. Lokale Netze, Sternstruktur Bei der Sternstruktur gehen von einem zentralen Rechner Punkt-zu-Punkt-Verbindungen zu den Endgeräten, wobei der zentrale Rechner die Aufgabe der Vermittlung hat. Vorteilhaft an der Sternstruktur ist, dass jede Datenleitung unabhängig von den anderen Leitungen ist. Dies ist bei Anwendungen sinnvoll, die primär auf zentrale Daten zugreifen. Nachteilig wirkt sich aus, dass der Zentralrechner sehr leistungsfähig sein muss. Hinzu kommt, dass der Ausfall des Zentralrechners den Zusammenbruch des gesamten Netzes bedeutet. Da jeder Rechner über eine eigene Leitung mit dem Zentralrechner verbunden ist, ist der erforderliche Verkabelungsaufwand hoch. Lokale Netze, Ringstruktur Bei der Ringstruktur wird jedes Endgerät mit seinem Nachbarn verbunden. Beim Datenfluss wird geprüft, ob die Daten für das aktuell angesprochene Endgerät bestimmt sind. Ist dies nicht der Fall, werden sie zum nächsten Nachbarn weitergeleitet. Vorteile der Ringstruktur sind der niedrige Kabelaufwand sowie die minimale Sendeleistung der Endgeräte. Ein Zentralrechner ist nicht erforderlich. Nachteile der Ringstruktur sind darin zu sehen, dass der Defekt einer Leitung einen Totalausfall zur Folge hat. Zudem sind die Durchlaufzeiten relativ hoch. Schließlich ist ein Neuanschluss eines Endgerätes während des Betriebs nicht möglich. Lokale Netze, Lastverbund Der Lastverbund ermöglicht die Verteilung der benötigten Rechenleistung auf die angeschlossenen Rechner. Hierbei wird das Ziel verfolgt, Engpässe zu überwinden bzw. die verteilt vorhandenen Rechnersysteme besser auszulasten. Lokale Netze, Kommunikationsverbund Beim Kommunikationsverbund wird die Vernetzung der Rechner genutzt, um mit anderen Benutzern zu kommunizieren, z. B. asynchron mittels E-Mail und elektronischen Diskussionsforen, oder synchron mithilfe von Audio- und Videokonferenzen.

M Maschinensprachen Zu den maschinenorientierten Programmiersprachen gehören erstens die Maschinensprachen oder Sprachen der 1. Generation, die Befehle in binärer Form für die Maschine direkt verständlich darstellen und in ihrer Struktur der jeweiligen Maschinenlogik entsprechen.

458

Glossar

Programme in der Maschinensprache sind infolge des extrem beschränkten Zeichenvorrats für die Darstellung von Anweisungen außerordentlich unübersichtlich und deswegen auch sehr fehleranfällig. Mehrprogrammbetrieb Beim Mehrprogrammbetrieb (Multi Tasking) werden mehrere Benutzeraufträge vom Rechner gemeinsam und zwar abwechselnd in Zeitabschnitten verzahnt bearbeitet (z. B. im Time-Sharing-Verfahren). Es befinden sich gleichzeitig mehrere Benutzeraufträge (Programme) ganz oder teilweise im System und bekommen die unterschiedlichen Betriebsmittel (wie den Zentralprozessor) wechselseitig zugeteilt.

Betriebssystem

Betriebssystem

Programm 1

Programm 1 Programm 2 Programm 3

Ungenutzter Speicher Ungenutzter Speicher Einprogrammbetrieb

Mehrprogrammbetrieb

Einprogramm- versus Mehrprogrammbetrieb

Mehrprozessorarchitekturen Oftmals besitzt ein Rechner nicht nur einen, sondern mehrere Prozessoren. In PCs beispielsweise wird die Leistungsfähigkeit des Gesamtsystems verbessert, indem die CPU von bestimmten Operationen wie mathematischen Berechnungen durch einen Coprozessor freigestellt wird. Weitere Möglichkeiten, die Leistungsfähigkeit eines Rechners zu erhöhen, bestehen in der Änderung der Rechnerarchitektur, wie sie durch den Von-­Neumann-­Rechner beschrieben wird. Dies bedeutet, dass man statt einem Prozessor mehrere Prozessoren oder statt einem Rechenwerk mehrere Rechenwerke hat. Multicore-Prozessor Multiprozessorsysteme sind auch als Arbeitsplatzrechner verfügbar. Hierbei werden die Begriffe Multicore Processor (Multikernprozessor) oder als Spezialfälle auch Dual Core Processor (Zweikernprozessor) sowie Quad Core Processor (Vierkernprozessor) verwendet.

N

459

Die Bezeichnung „Core“ in dem Namen weist auf die Tatsache hin, dass für diese Systeme die Prozessoren jeweils auf einem „Chip“ gefertigt sind. Es handelt sich jedoch um vollständige Prozessoren, die sich meist nur den Bus teilen.

N Netz-Topologien von LAN Bei Netz-Topologien werden physische und logische Netzstrukturen unterschieden. Während die physische Struktur des Netzes die Anordnung der Leitungen zum Inhalt hat, geht es bei der logischen Struktur um die Organisation der Kommunikationsbeziehungen. Dabei können die physische und die logische Struktur eines Netzes voneinander abweichen. Netzzugangsprotokolle Die Netzzugangsprotokolle regeln die Nutzung von Verbindungen zwischen Systemen und beschreiben die Schnittstelle zwischen den Endeinrichtungen und den Netzzugangseinrichtungen. Sie sind durch folgende allgemeine Merkmale gekennzeichnet: Netzzugangsprotokolle sind abhängig vom Netztyp, d. h. mit der Wahl eines Netztyps ist auch ein festgelegter Satz von Protokollen je Schicht definiert. Netzzugangsprotokolle unterstützen sowohl verbindungsorientierte wie verbindungslose Datenübertragungsdienste. Die Protokolle der Bitübertragungsschicht und Übertragungssicherungsschicht treffen keine Unterscheidung zwischen beiden Betriebsmodi. In der Vermittlungsschicht findet abhängig vom Netztyp eine Differenzierung zwischen den beiden Betriebsmodi statt. Netztypen Die Netzzugangsprotokolle der ISO können nach folgenden Netztypen gegliedert werden: • • • •

Leitungsvermittelte analoge Fernsprechnetze, paketvermittelte Datennetze, integrierte Sprach- und Datennetze, sowie lokale Netze.

NoSQL (Not only SQL) NoSQL-Datenbanken bilden eine Klasse strukturierter Datenspeicher, die nicht die Tabellenstruktur traditioneller, relationaler Datenbanksysteme zugrunde legen. Sie sind besonders dann vorteilhaft, wenn keine Verbundoperationen ausgeführt werden müssen, wie sie beispielsweise für die Transaktionsverarbeitung (Systems of Record) typisch sind, und die Skalierbarkeit eine große Rolle spielt, wie etwa bei lastintensiven Web-Anwendungen. Anwendungsfelder von NoSQL-Datenbanken sind beispielsweise die Verarbeitung von Dokumenten (z. B. Webseiten), Datenströmen (z. B. Audio/Video Streaming) oder Graphen (z. B. Beziehungen eines sozialen Netzwerks). Gängige NoSQL-Datenbanksysteme sind beispielsweise MongoDB, CouchDB und Neo4j.

460

Glossar

O Objektorientiertes Datenmodell Objektorientierte DBS ermöglichen es, komplex strukturierte Objekte und Objekte mit besonderen Charakteristika (z.  B. sehr lange Felder) zu verwalten. Dies ist speziell für Multimediaanwendungen (integrierte Sprache und Bilder), für die industrielle Fertigung als auch z. B. für geografische Informationssysteme von Bedeutung. In diesen Bereichen kann durch den Einsatz von objektorientierten Datenbanken eine Leistungssteigerung der Anwendungen erreicht werden, da die Daten entsprechend den Objektstrukturen verwaltet werden. Da die Daten zudem problemadäquat modelliert werden, reduziert sich der Aufwand in der Entwicklung von Anwendungen.

P Peer-to-Peer Computing Unter Peer-to-Peer Computing versteht man ein sich selbst organisierendes System gleichberechtigter, autonomer Einheiten (Peers), das vorzugsweise ohne Nutzung zentraler Dienste auf der Basis eines Rechnernetzes mit dem Ziel der gegenseitigen Nutzung von Ressourcen operiert (angelehnt an (Oram 2001) und (Steinmetz und Wehrle 2004)). Dabei können Peers Dienste in Anspruch nehmen oder auch Dienste zur Verfügung stellen. Die Systeme können als Arbeitsstationen genutzt werden, aber auch Aufgaben im Netz übernehmen. Peer-to-Peer Computing stellt also nicht nur ein Verfahren zum Austausch von Dateien dar, sondern ist vielmehr ein Entwurfsprinzip für verteilte Systeme. Ein Kernbereich beim Peer-to-Peer Computing ist die dezentrale Selbstorganisation in einem verteilten System. Die Suche nach dem Ort (Lokation) an dem sich eine bestimmte Information befindet, nimmt dabei eine zentrale Rolle ein. Die Verwaltung von Inhalten und der Lokation der Inhalte stellt einen großen Teil der Funktionalität von Peer-to-Peer-Systemen dar. Obwohl das Peer-to-Peer Computing sich zunächst hauptsächlich als Mechanismus für die rechtlich umstrittenen Dateitauschbörsen etabliert hatte, stellt es ein interessantes Konzept zur Nutzung unterschiedlichster Ressourcen im Internet dar. Man schätzt, dass in den meisten Unternehmen die Nutzer weniger als 25 % der Speicher- und Prozessorleistung ihrer Systeme in Anspruch nehmen. Das Peer-to-Peer Computing soll diese ungenutzten Ressourcen für die produktive Nutzung erschließen. Portabilität Das Qualitätsmerkmal Portabilität bezeichnet die Eigenschaft einer IS-Komponente, in unterschiedlichen Umgebungen eingesetzt zu werden. Wenn eine Software von einer Umgebung in eine andere Umgebung überführt werden kann, so wird sie als portabel bezeichnet. Portabilitätsstandards existieren u. a. in den Bereichen Betriebssysteme, Datenhaltung, Benutzeroberflächen und Programmiersprachen.

P

461

Programmiersprachen Programmiersprachen werden benutzt, um den Lösungsweg (Algorithmus) für ein durch ein IS zu lösendes Problem in einer für die Maschine verständlichen Sprache zu formulieren. Digitalrechner verarbeiten Programme, die in binärer Codierung (Objektcode) vorliegen müssen. Als Hilfsmittel zur Erstellung dieses Objektcodes dienen Compiler bzw. Assembler, die einen symbolischen Code (Quellcode), dessen Struktur durch die verwendete Programmiersprache definiert ist, in den Objektcode übersetzen.

Problemlösungsweg (Algorithmus)

Software-Entwickler

Quellcode in einer Programmier sprache

WHILE NOT EOF DO IF X > 2500 THEN Y:=1000 + X ELSE Y:= 1000 - X

Übersetzungsprogramm

Binärer Objektcode

000001010101010 101010101010101 010101001011

Vom Algorithmus zum Objectcode

Programmiersprachen, höhere Das Ziel der Entwicklung höherer Programmiersprachen war es, dem Programmierer Sprachkonstrukte zur Verfügung zu stellen, mit denen er seinen Algorithmus bzw. seine Problemlösung beschreiben kann, ohne die ausführende Rechnerarchitektur detailliert berücksichtigen zu müssen. Mit diesem Ansatz war es auch möglich, Programme für verschiedene Hardware- oder Software-Architekturen zu entwickeln. Zum Einsatz auf einer anderen Rechnerarchitektur muss das Programm (Quellcode) in den entsprechenden Objectcode übersetzt werden. Höhere Programmiersprachen können Universalsprachen sein, die nicht nur auf einen Anwendungsbereich oder eine Teilaufgabe ausgerichtet sind, sondern vielfältige Aufgabenstellungen bewältigen. Daneben gibt es problemorientierte Sprachen, die durch ihren Aufbau und ihre sprachlichen Mittel die Lösung spezieller

462

Glossar

Aufgabenstellungen unterstützen. Problemorientierte Programmiersprachen sind jeweils auf einen spezifischen Anwendungsbereich ausgerichtet und (weitgehend) unabhängig von einem bestimmten Rechnertyp. Die erste derartige Programmiersprache war die von IBM für den technisch-wissenschaftlichen Bereich entwickelte Programmiersprache FORTRAN (Formula Translation), eine im Bereich der technischen Anwendungen auch heute noch benutzte Sprache. Der Versuch, eine einfach erlernbare und interaktiv (im Dialog mit dem Benutzer) verwendbare Sprache zu entwickeln, führte auf der Basis von FORTRAN zu BASIC (Beginners All Purpose Symbolic Instruction Code). Mit Pascal wurde eine Programmiersprache entwickelt, die einfach zu erlernen ist und sich trotzdem für die übersichtliche Gestaltung von Algorithmen und Datenstrukturen eignet. Die Programmiersprache C hat mit der Verbreitung von UNIX als Betriebssystem, das auf der Sprache C basiert, eine besondere Bedeutung erlangt. C besitzt als Programmiersprache sowohl Eigenschaften und Sprachelemente aus höheren als auch aus assemblerähnlichen Programmiersprachen. Trotz der assemblerähnlichen Sprachteile ist C weitgehend maschinenunabhängig. Der Sprachumfang von C ist relativ gering, da C-Programme auf Standardprozeduren aus sog. Bibliotheken zurückgreifen. Programmiersprachen, Klassifikation Die große Anzahl der entwickelten Programmiersprachen kann nach verschiedenen Kriterien klassifiziert werden. Als Unterscheidungskriterien dienen dabei sowohl Abstraktionsebenen (maschinen- oder benutzerorientiert), Sprachgenerationen gemäß der historischen Entwicklung oder spezielle Eigenschaften (objektorientiert, prozedural, nicht prozedural)

maschinenorientiert

Maschinensprachen Assembler

benutzerorientiert

Höhere Programmiersprachen (prozedural)

Symbolische und Objektorientierte Programmiersprachen

Endbenutzersprachen (4GL-Sprachen)

Cobol, Fortran, C, Basic, RPG, Pascal

C++, Lisp, Smalltalk, Eiffel, Prolog, Java, Python

SQL, ABAP/4, R

Klassifikation der Programmiersprachen

Programmiersprachen, Portabilität Die Entwicklung der höheren Programmiersprachen ist dadurch gekennzeichnet, dass von den Standardisierungsgremien (primär ANSI und ISO) jeweils ein Sprachkern mit grundlegenden Konstrukten definiert wurde, der aber von den einzelnen Herstellern jeweils um spezielle auf die jeweilige Hardware abgestimmte Funktionen erweitert wurde. So kann die Portabilität von Programmen nur garantiert werden, wenn ausschließlich dieser Standard-­ Sprachumfang benutzt wird.

R

463

Programmiersprachen, Syntax und Semantik Bei jeder Programmiersprache unterscheidet man in Analogie zu den natürlichen S ­ prachen: • Die Syntax, die die Form der Sprachzeichen (Alphabet) und Worte und die grammatikalischen Regeln, d. h. die formale Richtigkeit der Sprache beschreibt, und • die Semantik, die die Beziehungen zwischen den Sprachzeichen bzw. Worten und deren Bedeutung, d. h. die Logik der Sprache, festlegt. Programmiersprachen, Symbolische und objektorientierte Der Bereich der Programmiersprachen zur symbolischen und logischen Datenverarbeitung ist eng mit dem Begriff Künstliche Intelligenz (Artificial Intelligence) verknüpft. LISP (List Processing) ist nach FORTRAN die zweitälteste Programmiersprache und wurde speziell für die symbolische Datenverarbeitung entwickelt. In den objektorientierten Programmiersprachen sind die Konzepte der Objektorientierung und Vererbung enthalten. Ein Objekt ist hierbei definiert als ein Informationsträger, der einen Zustand besitzt und auf bestimmte Nachrichten an das Objekt reagiert. Die Programmierung in reinen objektorientierten Programmiersprachen erfolgt über das Senden von Nachrichten. Gleichartige Objekte werden als Klassen definiert. Zwischen einzelnen Klassen können die Eigenschaften der Objekte vererbt werden. Zu den reinen objektorientierten Programmiersprachen zählen Smalltalk und Eiffel. Bei den hybriden objektorientierten Programmiersprachen (z. B. C++) handelt es sich um Erweiterungen herkömmlicher Sprachen. Aufgrund der Bedeutung von C hat sich C++ mit der Erweiterung um objektorientierte Sprachelemente als ein de facto-Standard mit sich ständig verbreiterndem Einsatzspektrum entwickelt. Für die Entwicklung von Internetanwendungen hat die Programmiersprache Java große Bedeutung. Hierbei ist zwischen Java und JavaScript zu unterscheiden. Java ist eine objektorientierte Programmiersprache, ähnlich wie C++, und ermöglicht es, sog. Applets als eigenständige Anwendungen, die in eine Webseite eingebettet werden können, zu gestalten. Diese Applets werden auf dem Server in Bytecode übersetzt und laufen auf den Webbrowsern der Clients ab. Obwohl Java hierfür bereits einige Unterstützung bietet, ist der komplette Vorgang des Entwickelns und Übersetzens eines Applets ohne Programmierkenntnisse nicht vorstellbar. Java-Programme bestehen nur aus Klassen und ihren Methoden. Javas objektorientierter Ansatz, also die Anforderung, Klassen zu deklarieren und die Verpflichtung, Objekte zu erzeugen, macht die Programmierung in Java weitaus anspruchsvoller als das Schreiben von Scripts. Die Vererbung in Java erlaubt komplexe Objekthierarchien. JavaScript ähnelt in der Syntax Java, weist aber große Unterschiede in den verfügbaren Sprachkonstrukten und Konzepten auf.

R Rechnernetz Wenn mindestens zwei Rechner über Datenleitungen miteinander verbunden sind, dann liegt ein Rechnernetz vor. Ein Rechnernetz stellt die Infrastruktur dar, über die die an den Anschlusspunkten befindlichen Endgeräte kommunizieren können.

Glossar

464

Relationales Datenmodell Relationale DBS sind dadurch gekennzeichnet, dass alle Datenstrukturen und Beziehungen zwischen den Daten in Form von zweidimensionalen Tabellen dargestellt werden. Als Ergebnis von Datenmanipulationen ergeben sich wieder Tabellen. Diese Art der Darstellung ergibt in den meisten Anwendungsfällen eine wesentlich größere Flexibilität, was der Grund dafür ist, dass die relationalen DBS die hierarchischen oder netzwerkartigen DBS nahezu vollständig abgelöst haben. Kunde KdNr Bestellung BesNr

Name

KdNr

Adresse

ArtNr Menge

Artikel ArtNr

Bezeichung

LNr

Lieferant LNr

Preis

Name

Adresse

Relationales Datenmodell

RFID (Radio Frequency Identification)-Systeme In vielen Anwendungsbereichen kommen zur Dateneingabe und Identifikation (von z.  B.  Produkten, Menschen, Geldscheinen oder Fahrzeugen) zunehmend RFID (Radio Frequency Identification)-Systeme zum Einsatz. Ein RFID-System umfasst einen Transponder, der den Gegenstand kennzeichnet, ein Lesegerät zum Lesen der Transponder-­ Kennung und eine Verarbeitungskomponente mit Schnittstellen zu weiteren IS. Der Transponder besteht aus einem winzigen Chip und einer flachen Antenne. Der Datenaustausch erfolgt über elektromagnetische Wellen und gestattet einen schnellen Informationsabruf ohne Sichtkontakt. Der Chip ermöglicht einen Lese- und Schreibzugriff auf die auf ihm gespeicherten Daten. Der Chip auf dem Transponder kann je nach Ausführung eine unterschiedliche Speicherkapazität besitzen und auch mehrfach beschreibbar sein. Man unterscheidet aktive und passive Transponder. Bei aktiven Transpondern besitzt der Chip eine eigene Stromversorgung. Bei passiven Transpondern wird der Chip durch induktive Kopplung, bzw. kapazitive Kopplung im Nahfeld eines Lesegerätes mit Energie versorgt. Der passive Transponder hat keine eigene Energieversorgung. Das Lesegerät erzeugt ein hochfrequentes elektromagnetisches Wechselfeld, welches die Antenne des RFID-­Transponders empfängt. In der Antennenspule entsteht, sobald sie in die Nähe des elektromagnetischen Feldes kommt, Induktionsstrom.

S

465

Router Wenn unterschiedliche Netze miteinander gekoppelt werden, so geschieht dies mit Hardwareeinrichtungen, die Router genannt werden. Die Übertragung von Daten von einem Netz in das andere Netz kann sowohl selektiv als auch nicht selektiv erfolgen. Die selektive Übertragung erfolgt mit Routern. Mit der eingebauten Intelligenz weiß der Router, welches IS an welchem Subnetz liegt und lässt nur Informationen für die an diesem Subnetz liegenden IS durch. Router bewirken eine Entkopplung von Subnetzen mit dem Vorteil, dass Störungen und Lastspitzen nur auf ein Subnetz beschränkt bleiben und nicht die Möglichkeit besteht, von einer Station aus das gesamte Netz „abzuhören“. Der Anschluss von IS an das Netz geschieht durch eine physikalische Hardwareeinrichtung, die als Transceiver bezeichnet wird. Router sind separate Hardwareeinrichtungen zur Netzverbindung. Diese Aufgabe kann jedoch auch durch Rechner erledigt werden. Rechner mit derartigen „Zusatzaufgaben“ werden Gateway-Rechner genannt.

S Servervirtualisierung Servervirtualisierung erlaubt es, Ressourcen von Computern zusammenzufassen bzw. aufzuteilen und Nutzern nach Bedarf als Service zur Verfügung zu stellen. Damit können die Nutzer mehrere logische Ressourcen oder Anwendungen auf einem oder mehreren physischen Serversystemen nutzen bzw. ablaufen lassen. Die Abhängigkeit zwischen Hardware und Software wird teilweise aufgehoben. Smartphone Bei einem Smartphone handelt es sich um ein Mobiltelefon, das über eine höhere Computerfunktionalität und umfangreichere Datenkommunikationsfähigkeiten als ein Handy verfügt. Smartphones sind mit einem hoch auflösenden berührungsempfindlichen Bildschirm ausgestattet und verfügen über eine schnelle Internetverbindung mittels mobilem Breitband (z. B. über UMTS oder LTE) und WLAN. Weiterhin besitzen sie meist eine oder zwei digitale Kameras und GPS. Mittels mobiler Apps kann auf umfangreiche Funktionalitäten, z. B. zur Kommunikation, Unterhaltung (Musik, Spiele und Filme), Navigation, Adress-, Termin und Datenverwaltung sowie Information (Internet) zugegriffen werden. Da ein Smartphone ein technisch komplexes Gerät ist, das über eine Reihe von Komponenten verfügt, benötigt es ein entsprechendes Betriebssystem. Derzeit wird der Markt von zwei Betriebssystemen dominiert: Android und Apple IOS besitzen gegenwärtig etwa einen Marktanteil von 90 %. SMTP (Simple Mail Transfer Protocol) Das Simple Mail Transfer Protocol (SMTP) stellt Empfangs- und Sendedienste von elektronischen Nachrichten (E-Mail) zur Verfügung. Das Protokoll ist zeichenorientiert. Eine Nachricht besteht aus einem Kopf und einem Rumpf. Der Kopf enthält u. a. Empfänger, Absender, Kopienempfänger, Datum und Bezug. Der Rumpf besteht normalerweise aus freiem ASCII-Text.

466

Glossar

SOA (Service-Orientierte Architektur) Eine (IT-, IS- oder fachliche) Architektur ist serviceorientiert, wenn sie aus in sich geschlossenen, lose gekoppelten Komponenten besteht, die bestimmte (IT-, IS- oder fachliche) Leistungen flexibel erbringen. Meist wird das Akronym SOA (Service Oriented Architecture) für serviceorientierte Softwaresysteme benutzt. Prinzipiell lassen sich jedoch auch IS, fachliche Strukturen und sogar Hardwaresysteme serviceorientiert strukturieren. Das Ziel aller serviceorientierten Architekturen ist es, schnell auf veränderte Anforderungen reagieren zu können, indem die lose gekoppelten Komponenten anders verknüpft oder indem andere Komponenten eingebunden werden. Web Services (s. Glossareintrag Web Services) bieten sich aufgrund ähnlicher Ziele und Prinzipien zur Implementierung serviceorientierter IS an. Im Prinzip lassen sich serviceorientierte IS auch mit konventionellen Mechanismen implementieren. SOAP (Simple Object Access Protocol) Das Simple Object Access Protocol (SOAP) dient der Herstellung der Interoperabilität von Diensten. Es verpackt Informationen auf der Basis von XML, die zur Kommunikation mit einem Web-Service-Anbieter notwendig sind. Software Allgemein bezeichnet man als Software die detaillierten Anweisungen an den Computer. Ein Softwareprogramm besteht also aus einer Anzahl von Anweisungen für den Computer. Speichermaßzahlen Die Maßzahlen für den Speicher sind die Speichergröße und die Zugriffszeit. Die Speichergröße wird in Byte angegeben. Aufgrund der Entwicklungen im Umfeld des Big Data werden mittlerweile auch höhere Größenordnungen, wie Peta- und Exabyte relevant. Hierbei gelten die folgenden Zusammenhänge: • • • • • • • •

1 Kilobyte (KB) = 1024 Byte (10241) 1 Megabyte (MB) = 1024 KB (10242) = 1.048.576 Byte 1 Gigabyte (GB) = 1024 MB (10243) = 1.073.741.824 Byte 1 Terabyte (TB) = 1024 GB (10244) = 1.099.511.627.776 Byte 1 Petabyte (PB) = 1024 TB (10245) = 1.125.899.906.842.624 Byte 1 Exabyte (EB) = 1024 PB (10246) = 1.152.921.504.606.846.976 Byte 1 Zettabyte (ZB) = 1024 EB (10247) = 1.180.591.620.717.411.303.424 Byte 1 Yottabyte (YB) = 1024 ZB (10248) = 1.208.925.819.614.629.174.706.176 Byte

Speichermedien, extern Externe Speichermedien sind alle Daten- und Programmspeicher, die nicht im direkten Zugriff der CPU sind, sondern als periphere Geräte über einen separaten Bus angesprochen werden. Sie werden auch als sekundärer Datenspeicher bezeichnet. Ein sekundärer Speicher ist nicht flüchtig: Die Informationen bleiben erhalten, wenn der Rechner ausgeschaltet wird. Die wichtigsten Sekundärspeichertechnologien sind magnetische, optische und halbleiterbasierte Speicher.

S

467

Spracherkennung Wie bei der Audioverarbeitung erfolgt die Spracheingabe über einen Digital-­Analog-­ Wandler und ein Mikrofon. Bei der Spracherkennung soll erkannt werden, was gesprochen wird, um es entweder in einen Text im Rahmen der Texteingabe oder in Befehle umzusetzen. Anwendungsfelder sind digitale Sprachassistenten wie z. B. Microsoft Cortana oder Apple Siri, die die Arbeit mit dem Smartphone unterstützen. Für die Spracherkennung ist eine Spracherkennungssoftware notwendig. Man unterscheidet bei der Spracherkennung nach sprecherabhängiger und sprecherunabhängiger Erkennungssoftware. Bei der sprecherabhängigen Erkennung ist eine Stimmanpassung der Erkennungssoftware notwendig. Dafür ist die sprecherabhängige Software leistungsfähiger, d. h. sie hat eine höhere Trefferquote bei den erkannten Worten. Die Spracherkennungssoftware arbeitet mit Wortlexika über die erkennbaren Worte. Speichermedien, Smartcards, Secure Digital Cards und USB Sticks Smartcards haben die Form einer Scheck-Karte und verfügen über einen eingebauten, veränderbaren Speicher und einen Mikroprozessor. Man unterscheidet nach: • Memory Cards, die ausschließlich der Speicherung dienen, wie zum Beispiel die Krankenversicherungskarte. • Processor Cards haben einen eigenen Prozessor und ein eigenes Betriebssystem. Die Daten können nicht nur gespeichert, sondern auch verarbeitet werden. • Encryption Cards mit Co-Prozessor, der zur Verschlüsselung von Daten dient. Diese Karten werden zum Beispiel in elektronischen Zahlungssystemen eingesetzt. Secure Digital Cards (SD Cards und Micro SD Cards) sind nicht viel größer als Briefmarken und Micro SD Cards haben Fingernagelgröße. Ihr Gewicht liegt bei einigen Gramm. Handelsübliche Karten besitzen gegenwärtig eine Kapazität von bis zu 128 Gigabyte. Sie werden in mobilen Geräten wie Smartphones, Tablets und Digitalkameras verwendet. Mittels Kartenleser kann auch über PCs auf sie lesend und schreibend zugegriffen werden. USB Sticks sind größer als SD Cards und können über die USB-Schnittstelle mit dem PC verbunden werden. Sie haben als wiederbeschreibbares Wechselspeichermedium die Disketten ersetzt. Handelsübliche USB Sticks haben gegenwärtig eine Kapazität von bis zu 2 TB. Speichernetzwerk Ein Speichernetzwerk oder auch Storage Area Network (SAN) ist ein lokales Netzwerk, das unterschiedliche und umfangreiche Speichermedien miteinander über ein schnelles Medium (z. B. Glasfaserkabel) verbindet und den Nutzern in den Unternehmen zur Verfügung stellt. Hierbei soll eine unternehmensweite Infrastruktur bereitgestellt werden, die es den Nutzern ermöglicht, gemeinsam auf die Daten zuzugreifen. Mit dieser Infrastruktur soll aber auch den schnell wachsenden Datenmengen in speziellen Bereichen (wie z. B. dem WWW oder dem Gebiet Multimedia) Rechnung getragen werden.

468

Glossar

SQL (Structured Query Language) Die einzige heute allgemein anerkannte und standardisierte Datenbanksprache zum Aufbau und zur Manipulation relationaler Datenbanken ist SQL. Die offizielle standardisierte Version von SQL beruht auf der Norm ISO 9075. Sie beschreibt Grundbegriffe einer Datenbank mit SQL-Schnittstelle sowie Grundoperationen wie beispielsweise die Definition von Datenbanktabellen oder lesende und ändernde Zugriffe auf Datenbanktabellen. Die Norm beschreibt auch Integritäts- und Zugriffsberechtigungsregeln, deren Einhaltung bei der Verwendung von Lese- und Änderungsoperationen sichergestellt wird. SQL wird daher zunehmend als Schnittstelle zu einem Datenbanksystem betrachtet, auf die benutzerfreundliche Oberflächen aufgesetzt werden müssen (siehe auch (Date 1996)). Die Standardisierungen hinken den Anforderungen hinterher, so dass viele Hersteller Erweiterungen vorgenommen haben, die nicht miteinander und nicht mit jeweiligen Standards verträglich sind. Für den Vorteil zusätzlicher Funktionalität muss man dann den Preis geringerer Portabilität bezahlen. Standard Häufig wird Normung synonym zu Standardisierung bzw. Norm synonym zu Standard, Richtlinie oder Empfehlung verwendet. Richtiger ist es, zwischen Norm und Standard zu unterscheiden, da eine Norm einen wesentlich verbindlicheren Charakter hat. So betreiben z. B. ISO (International Standards Organization) und DIN (Deutsches Institut für Normung) Normung, Gremien wie ECMA (European Computer Manufacturers Association) jedoch Standardisierung. Im Folgenden wird in Anlehnung an den englischen Sprachgebrauch der Begriff Standard umfassend und synonym zum Begriff Norm verwendet. Standardisierungsgremien Das wichtigste Normungsgremium auf internationaler Ebene stellt die ISO dar. Die ISO ist mit Sitz in Genf Dachorganisation von über 50 nationalen Normungsausschüssen. Die Aufgabe der ISO ist es, die von den einzelnen Ländern vorgeschlagenen Normungsthemen zu prüfen, auszuwählen, aufeinander abzustimmen und auszuarbeiten. Die von der ISO zusammen mit den Ländergremien (z. B. DIN für Deutschland) erarbeiteten Normen werden an die nationalen Normungsausschüsse als Empfehlung für eine nationale Norm weitergegeben. Im Bereich der Informationstechnik befasst sich die ISO z.  B. mit der Normung der Kommunikation offener Systeme (Open Systems Interconnection, OSI). Das Ziel ist die Zusammenarbeit von Systemen unterschiedlicher Herkunft. Das Pendant zur ISO ist für die Telekommunikation die ITU (International Telecommunication Union) mit dem CEPT (Conference Européenne des Administrations des Postes et des Télécommunications) als europäische Konferenz der Post- und Fernmeldeverwaltungen und das Europäische Institut für Telekommunikationsstandards ETSI (European Telecommunication Standardization Institute) eng zusammenarbeiten. Zwischen ISO und ITU) wurden

S

469

mittlerweile eine enge Zusammenarbeit und die gegenseitige Übernahme von Standards vereinbart, sodass die ITU-Empfehlungen mit den jeweiligen ISO-Normen weitgehend identisch sind. Als drittes Glied im internationalen Standardisierungsprozess ist die IEC (International Electrotechnical Commission) anzuführen. Die IEC ist eine internationale Organisation, deren Mitglieder Anwender, Hersteller und Repräsentanten staatlicher Behörden sind. IEC ist verantwortlich für Standardisierungen in der Elektrotechnik im weiten Sinne. Seit 1987 bildet die IEC zusammen mit der ISO das JTC 1 (Joint Technical Committee 1), um Aufgaben, die mit der Informationstechnologie zusammenhängen, in koordinierter Weise zu behandeln. Nationale Gremien, wie z.  B.  DIN (BRD) und BSI (GB) unterstützen die Arbeit von ISO auf nationaler Ebene. Den größten Einfluss in der internationalen Standardisierung zur Informationstechnologie dürften jedoch ANSI (American National Standards Institute) und IEEE (Institute of Electrical and Electronics Engineers) aus den USA ausüben. Strichcode- oder Barcodeleser Strichcode- oder Barcodeleser sind heute in der gesamten Warenwirtschaft zu finden. Mit ihrer Hilfe können geringe Datenmengen sehr einfach, schnell und vor allem sicher für die Weiterverarbeitung in ein IS eingelesen werden. Der Strichcodeleser zur Verarbeitung der 13-stelligen Europa-einheitlichen Artikelnummer EAN (European Article Number) bzw. der globalen Artikel-Identnummer (Global Trade Item Number, GTIN) ist heute an nahezu jedem Kassensystem zu finden. Es gibt aber auch eine Vielzahl von Codes für andere Einsatzgebiete. Die Codes werden mit einer Sequenz schmaler und breiter Striche und Lücken dargestellt. Beim optischen Abtasten werden die unterschiedlichen Reflexionen der dunklen Striche und hellen Lücken im Empfänger in entsprechende elektronische Impulse umgewandelt. Diese Impulse werden von einem Mikroprozessor in Zeichen umgewandelt und übertragen. Weit verbreitet sind Strichcodeleser, die über das Tastaturkabel an den Rechner angeschlossen werden. Der Rechner muss nicht unterscheiden, ob die Daten vom Strichcodeleser oder von der Tastatur kommen. Neuerdings werden statt eindimensionaler Barcodes mehr und mehr zweidimensionale Barcodes verwendet, die statt als Strichcode als Pixelmuster erscheinen. Suchmaschinen Suchmaschinen sind über das WWW zur Verfügung gestellte Anwendungen, die Benutzern helfen, gesuchte Inhalte im WWW (und teilweise anderen Internetdiensten) zu finden. Im Gegensatz zu Suchkatalogen, die manuell erstellt werden, besuchen Suchmaschinen Webseiten per Programm (sog. Webcrawler) und verschlagworten diese automatisch. Neben den Schlagworten, die auf einer Webseite vorkommen, werden weitere Informationen gespeichert (wie oft die Schlagworte auf einer Seite vorkommen, am Anfang oder am Ende, als Seitentitel oder als Überschrift, usw.). Wenn ein Benutzer Worte in die Suchmaschine eingibt, die beschreiben, wonach er sucht, vergleicht sie die Suchmaschine mit

470

Glossar

dem vorher erstellten Index der Webseiten und wählt diejenigen aus, die zur Suche bestmöglich passen. Die Reihenfolge der ausgegebenen Websites in der Trefferliste hängt von einem komplexen, i. d. R. geheim gehaltenen Algorithmus ab. Dieser berücksichtigt sowohl die Inhalte der Webseiten (On-site-Faktoren) als auch andere Faktoren (Off-site), die auf Informationen auf anderen Websites (z. B. Links auf die ausgegebenen Websites als Ausdruck ihrer Popularität im Netz) und Eigenschaften des Benutzers (z. B. seiner Lokation) basieren. Damit können unterschiedliche Nutzer bei gleicher Anfrage Ergebnisse in unterschiedlicher Reihenfolge erhalten. Die Suchmaschinen finanzieren sich meist über Werbung. Suchmaschinenoptimierung Aktivitäten, die dazu dienen, Links auf eine Website möglichst weit oben in der Trefferliste bei gewünschten Suchworten erscheinen zu lassen, werden als Suchmaschinenoptimierung (Search Engine Optimization, SEO) bezeichnet. Dazu gehört die Gestaltung der zu optimierenden Website (z. B. die für die Website wichtigen Stichworte im Seitentitel unterzubringen) und beispielsweise das Kreieren von Beiträgen auf anderen Websites, die sich auf die Zielwebsite beziehen, inkl. einem Link auf die Zielwebsite. SEO-Experten basieren ihre Tätigkeit auf ihren Erfahrungen, Berichten anderer Experten und Empfehlungen der Suchmaschinen, denn der genaue Algorithmus zum Ranking der Suchergebnisse wird ständig geändert und bleibt geheim. Das Ergebnis der Bemühungen hängt auch von den Aktivitäten der um gute Positionierungen konkurrierenden Websites ab. Außerdem ist darauf zu achten, dass man die von dem Suchmaschinenbetreiber vorgegebenen Regularien nicht missachtet, weil im schlimmsten Fall der Ausschluss aus dem Index, d. h. aus den Suchergebnissen, droht.

T Tablet Ein Tablet, Pad, oder Tablet Computer ist ein tragbarer, flacher Rechner in besonders leichter Ausführung mit einem berührungsempfindlichen, hochauflösenden Bildschirm, der aber anders als ein Notebook keine ausklappbare Tastatur besitzt, sondern eine Tastatur auf dem berührungsempfindlichen Bildschirm anzeigt. Aufgrund des berührungsempfindlichen Bildschirms zeichnen sich Tablet Computer durch einfache Handhabung aus. Tablets werden auch den mobilen Endgeräten zugeordnet. TCP/IP (Transmission Control Protocol/Internet Protocol) TCP/IP hat sich zum de facto-Standard unter den Kommunikationsprotokollen entwickelt. Dies wurde insbesondere durch die zunehmende Bedeutung des Internets unterstützt. TCP/IP ist älter als die ISO-Normen und entspricht diesen daher nicht genau. TCP/IP setzt

T

471

erst auf Schicht 3 des ISO-Modells auf, und verbirgt so vollständig die darunterliegende Hardware. Das Internet hat gezeigt, dass so auch Kommunikation über Netzgrenzen möglich ist. Das Internet Protocol (IP) steuert den Datenaustausch zwischen zwei Rechnern auf der Grundlage von verbindungslosem Datentransfer. Hier findet vorwiegend eine Umsetzung auf das darunterliegende Netzwerk statt, z. B. eine Anpassung an maximale Nachrichtengrößen. IP-Adresse des Absenders IP-Adresse des Empfängers Prüfsumme Kennung des zerlegten Pakets

IP-Header

Nutzdaten

Prinzipieller Auau einer IP-Nachricht

Die Rechner innerhalb eines IP-Netzwerks besitzen zur Identifikation eine eindeutige IP-Adresse. Diese hat eine Länge von 32 Bit und wird durch vier mittels Punkt getrennte Dezimalzahlen (von 0 bis 255) angegeben. In der Protokollversion IPv4 ist somit eine Adressierung von 232 = 4,3 * 109 Rechnern möglich. Die IP-Adressräume können in so genannte Subnets unterteilt werden. Staatliche Einrichtungen wie auch große Firmen haben entsprechende Adressräume für sich reserviert, die jedoch nicht immer genutzt werden. Der stetig wachsende Bedarf, hat dazu geführt, dass IP-Adressen knapp sind. Mit der neuen IPv6 (Version 6) wird u. a. die Anzahl der Adressen auf 3,4 * 1038 erhöht. Das Transport Communication Protocol (TCP) setzt die Pakete des IP wieder zusammen. TCP arbeitet verbindungsorientiert. Dies heißt, dass eine eigene Sitzung aufgebaut wird, bevor die Daten übertragen werden. Diese Sitzung stellt sicher, dass die Daten vollständig und in richtiger Reihenfolge beim Empfänger ankommen. Time Sharing Time Sharing bezeichnet die Fähigkeit eines Betriebssystems, dass die Programme den Prozessor quasi gleichzeitig in Anspruch nehmen können. Hierbei wird dem einzelnen Programm der Prozessor jeweils nur für eine kurze Zeit zugeteilt. In dieser Zeit führt der Prozessor die Anweisungen des jeweiligen Programms aus. Der Effekt der nahezu gleichzeitigen Nutzung wird dadurch erreicht, dass die zugeteilten Zeitscheiben sehr kurz und die Prozessoren sehr schnell sind. So fällt im Dialogbetrieb dem Nutzer nicht auf, dass er den Großrechner, an dem er arbeitet, mit mehreren hundert Kollegen teilt.

472

Glossar

Touchscreen Berührungsempfindliche Bildschirme, sog. Touchscreens, dienen als Eingabemedium von Befehlen, zur Steuerung von Werkzeugmaschinen oder zum Abruf von Informationen. Diese berührungsempfindlichen Bildschirme reagieren durch Berühren auf dem Bildschirm mit dem Finger oder einen spitzen Gegenstand. Zwei Komponenten sind für einen Touchscreen notwendig: der am Bildschirm angebrachte berührungsempfindliche Teil und eine zugehörige Steuereinheit, welche über eine Standardschnittstelle mit dem Rechner kommuniziert. Transaktionskonzept Damit eine Datenbank im Mehrbenutzerbetrieb einen konsistenten Datenbankstatus sicherstellen kann und auch im Falle eines Systemabsturzes einen korrekten Datenbankstatus wiederherstellen kann, benötigt die Datenbank ein Transaktionskonzept. Hierbei stellt eine Transaktion eine Folge logisch zusammengehörender Aktionen dar, welche Leseoder Schreiboperationen in der Datenbank durchführen. Wenn eine Transaktion ihre Operationen nicht korrekt oder vollständig ausführen kann, werden alle bereits durchgeführten Operationen der Transaktion wieder rückgängig gemacht (Rollback). Dies soll vermeiden, dass die Datenbank in einen fehlerhaften Zustand gerät. Transportprotokolle Transportprotokolle unterstützen die Verbindungen zweier Anwendungsprozesse. Daher haben die Protokolle der Transportschicht die generelle Aufgabe, Verbindungen zwischen Endsystemen zu Teilnehmerverbindungen unter Einbeziehung der Dienste der darüber liegenden Schichten zu erweitern, d. h. es wird eine End-to-End-Verbindung hergestellt. Ein Transportprotokoll ist verbindungslos, wenn auf der Netzschicht keine Beziehung zwischen zwei Paketen besteht, auch wenn sie vom selben Sender zum selben Empfänger geschickt werden. Ein Transportprotokoll heißt hingegen verbindungsorientiert, wenn eine logische Verbindung zwischen den Kommunikationspartnern eingerichtet ist und damit das Netz die Aufgabe hat, für die Sequenz, Eindeutigkeit und Vollständigkeit der beförderten Daten zu sorgen. Trojaner Der Angriff auf ein IS kann von innerhalb des Systems durch sog. „Trojanische Pferde“ erfolgen. Ein scheinbar harmloses Programm oder Dokument enthält Befehlsfolgen, die eine unerwartete und unerwünschte Funktionalität ausführen. Dies kann nur erreicht werden, wenn dieses scheinbar harmlose Programm vom Nutzer ausgeführt wird. Dafür muss die Person, die den Angriff durchführen will, den Nutzer dazu ermutigen, dieses Programm auf seinen Rechner zu laden (beispielsweise aus dem Internet oder einem E-Mail-Anhang) und auszuführen, indem man eine interessante Funktionalität verspricht.

V

473

U URL (Uniform Resource Locator) Für die Adressierung vom Objekten im Internet wird der URI (Uniform Resource Identifier) verwendet. Bei dem URI werden zwei Unterarten unterschieden: URL (Uniform Resource Locator) und URN (Uniform Resource Name). Die URL identifiziert eine Ressource über den primären Zugriffsmechanismus, d. h. sie gibt den Ort (engl. location) der Ressource im Netz an (Beispiele sind HTTP oder FTP). Mit der URN können Objekte im Internet mittels eines vorhandenen oder frei zu vergebenden Namens adressiert werden.

V Verschlüsselung Bei der Verschlüsselung (Kryptologie) geht es zunächst darum, zu verhindern, dass ein unerlaubter Abhörer eine zwischen zwei Partnern ausgetauschte Nachricht versteht. Kryptologische Verfahren werden also zur Verschlüsselung eingesetzt, um sensible Daten (z. B. Passwörter) bei Übertragung über einen unsicheren Kanal (öffentliches Netz) gegen den unerlaubten Zugriff zu schützen. Der Klartext ist meistens ein Text aus Buchstaben und Ziffern, die irgendwie einen Sinn ergeben, sodass der gedankliche Inhalt dieses Texts jedem der Sprache mächtigen Leser klar ist. Moderne Chiffrierverfahren verarbeiten natürlich nicht nur Klartexte in Form von Buchstaben und Ziffern, sondern auch Folgen aus Bits und Bytes, sodass alles, was mit einem Computer darstellbar ist, verschlüsselt werden kann. Das Ziel der Verschlüsselung ist es, den Klartext derart umzuformen, dass der Informationsgehalt des Texts nicht mehr erkennbar ist. Den umgeformten Klartext nennt man Kryptogramm. Zum Verschlüsseln benötigt man ein Chiffrierverfahren und einen Schlüssel. Das Chiffrierverfahren ist eine Folge von mehr oder weniger komplexen Vorschriften, die beschreiben, auf welche Weise der Klartext umzuformen ist. Gängige Techniken sind das Vertauschen von Buchstaben, Ersetzen bestimmter Buchstaben durch andere Buchstaben oder Buchstabenfolgen. Bei den meisten klassischen Chiffrierverfahren sind diese Vorschriften auf vielfältige Weise durchführbar. Um eindeutig festzulegen, was beim Umformen des Klartexts genau zu tun ist, benötigt man neben dem Chiffrierverfahren noch eine Zusatzinformation, den Schlüssel. Meistens ist dieser Schlüssel eine geheime Ziffernfolge oder ein geheimes Wort. Die eigentliche Besonderheit eines Chiffrierverfahrens ist die Tatsache, dass es auch ein inverses Verfahren (Dechiffrierverfahren) gibt, das es erlaubt, ein Kryptogramm wieder in Klartext zu verwandeln, aber nur, wenn man den geheimen Schlüssel kennt. Gute Chiffrierverfahren müssen nicht geheim gehalten werden. Die Sicherheit der Kryptogramme beruht lediglich auf der Geheimhaltung des verwendeten Schlüssels, d. h.: Ein Kryptogramm kann nur derjenige entschlüsseln, der den Schlüssel kennt, der beim Verschlüsseln des Klartexts verwendet wurde (Beutelspacher 2009).

474

Glossar

Verschlüsselung, symmetrische Man unterscheidet zwei grundlegende Verschlüsselungsverfahren: Symmetrische und asymmetrische Verschlüsselung. Wenn Sender und Empfänger denselben Schlüssel verwenden, handelt es sich um ein symmetrisches Verschlüsselungsverfahren. Chiffrierverfahren

Kryptogramm

Dechiffrierverfahren

Schlüssel S1

Schlüssel S1 Klartext

Klartext

Symmetrische Verschlüsselung In diesem Fall muss der Schlüssel geheim gehalten werden. Das bekannteste symmetrische Verschlüsselungsverfahren stellt der Data Encryption Standard (DES) dar. Er wurde 1976 entwickelt. Nach diesem Standard wird der Originaltext in Blöcken von 64 Bit mit den Methoden der Substitution und Permutation verschlüsselt. Verschlüsselung, asymmetrisch Die grundlegende Idee des asymmetrischen Verfahrens besteht darin, zum Verschlüsseln und zum Entschlüsseln unterschiedliche Schlüssel zu verwenden. Der eine Schlüssel ist jedem zugänglich, das ist der sog. öffentliche Schlüssel (Public Key). Der zweite Schlüssel ist privat und wird von seinem Eigentümer geheim gehalten (Private Key). Ein Chiffrierverfahren dieser Art hat praktische Vorteile.

Chiffrierverfahren

Kryptogramm

Dechiffrierverfahren

Schlüssel S1

Schlüssel S2 Klartext

Klartext

Asymmetrische Verschlüsselung

V

475

Die Schlüssel zum Verschlüsseln der Nachrichten können in einem öffentlichen Verzeichnis ähnlich einem Telefonbuch publiziert werden, während man die Schlüssel zum Entschlüsseln geheim hält. Damit ist es jedem möglich, anderen eine geheime Nachricht zuzusenden, indem man sie mit dem öffentlichen Schlüssel des Empfängers chiffriert. Nur der Besitzer des dazugehörigen geheimen Schlüssels kann die Nachricht dechiffrieren. Das setzt natürlich voraus, dass es nicht möglich ist, die geheimen Schlüssel auf irgendeine Weise aus den öffentlichen Schlüsseln zu ermitteln. Public­Key-Verfahren ermöglichen aber auch die Herstellung elektronischer Signaturen. Auch bei dieser Anwendung muss jeder, der ein Dokument signieren will, zwei Schlüssel besitzen. Ein Schlüssel zum Signieren (Verschlüsseln) und einen weiteren Schlüssel, mit dem es möglich ist, eine Signatur zu verifizieren (Entschlüsseln). Der Schlüssel, der zum Signieren benötigt wird, muss von seinem Besitzer geheim gehalten werden. Der Schlüssel zum Verifizieren der Signaturen wird in einem öffentlichen Verzeichnis ­publiziert. Angenommen, B möchte ein Dokument signieren, dann muss B das Dokument mit seinem geheimen Schlüssel chiffrieren. Das daraus resultierende Kryptogramm ist die „digitale Signatur“ und wird gemeinsam mit dem Klartextdokument versendet. Will man die Signatur prüfen, dann „dechiffriert“ man das Kryptogramm mit dem öffentlichen Schlüssel von B und überprüft somit, ob die Signatur und das Dokument zusammengehören. Dieser Prüfvorgang liefert nur dann ein positives Ergebnis, wenn weder das Klartextdokument noch die von B erzeugte Signatur verändert wurden. Der Vorteil dieses Verfahrens besteht darin, dass der Schlüssel zum Verschlüsseln allgemein zugänglich gemacht werden kann, während der Schlüssel zum Entschlüsseln geheim zu halten ist. Auf diese Weise können Nachrichten verschlüsselt über einen unsicheren Übertragungskanal gesendet werden, die nur vom legitimen Empfänger mit seinem geheim zuhaltenden Schlüssel entschlüsselt werden können. Das erste praktikable Public-Key-Verfahren wurde 1977 vorgestellt. Das sog. RSA-­ Verfahren gilt heute als eines der sichersten Kryptoverfahren. Bislang ist es noch niemandem gelungen, ernsthafte Einwände gegen die kryptologische Sicherheit des Verfahrens vorzubringen. Es ist kein anderes Verfahren öffentlich bekannt, das nachweislich sicherer als das RSA-Verfahren ist und vergleichbare Eigenschaften hat. Ein wirklicher Nachteil des Verfahrens ist jedoch der relativ große Zeitaufwand beim Verschlüsseln und Entschlüsseln. Besonders die Implementierung auf Prozessorchipkarten ist schwierig, da die langen Schlüssel fast den gesamten Speicherplatz der Chipkarte belegen. Softwareimplementierungen auf modernen Computern benötigen etwa eine Sekunde, um einen 80 Byte großen Datensatz zu verschlüsseln. Das ist akzeptabel, wenn man gelegentlich einige Datensätze zu verschlüsseln hat. Für viele Anwendungen ist es jedoch erforderlich, dass mehrere Kilobyte oder sogar Megabyte pro Sekunde verschlüsselt werden.

476

Glossar

Verteilte Datenbanken Eine verteilte Datenbank besteht aus mehreren Rechnern (Knoten), die durch ein Netzwerk miteinander verbunden sind, in welchem gilt: • Jeder Knoten enthält ein eigenständiges DBMS, wobei die Durchführung und Kontrolle lokaler Datenbankoperationen allein durch das lokale DBMS erfolgt, und • Nutzer (bzw. Anwendungen) können an jedem Knoten des Netzwerks auf Daten aller anderen Knoten des Netzwerks genauso zugreifen, wie auf Daten ihres lokalen Knotens. Seit den 1970er-Jahren ist man aufgrund der sinkenden Kosten im Bereich der Rechnernetze und der an vielen Stellen des Unternehmens anfallenden Daten bestrebt, Software für verteilte Datenbanken zu entwickeln. Die Vorteile einer verteilten Datenbank sind: • Lokationsunabhängigkeit. Ein Nutzer muss nicht wissen, wo die Daten im System gespeichert sind. • Entschärfung von Kapazitäts- und Leistungsengpässen: Datenbestände können zwischen den Knoten verlagert werden. • Leichtere Modifikation im Netz: Durch die Verlagerung von Knoten im Netz können organisatorische Änderungen technisch einfacher durchgeführt werden. • Portabilität der IS. • Lokale Autonomie: Jeder Knoten stellt ein autonomes System dar. Virenschutzsoftware Zum Schutz des IS vor Viren wird Virenschutzsoftware eingesetzt. Ein Virus ist eine Befehlsfolge, deren Ausführung bewirkt, dass eine Kopie oder Mutation ihrer selbst in einem anderen Speicherbereich reproduziert wird, und die bewusst darauf ausgelegt ist, Schaden zu verursachen. Der Virus besteht i. d. R. aus drei Komponenten: • Einem Teil zur Ausbreitung des Virus (Replikation), • einem Mechanismus, der die eigentliche Funktion unter bestimmten Umständen auslöst (Trigger), und • der eigentlichen Funktion. Viren sind keine eigenständigen Programme, sondern nutzen immer andere Programme, bei deren Ausführung sie aktiv werden. Virenschutzsoftware bietet im Allgemeinen die folgenden Grundfunktionen: • Verhinderung der Infektion (sog. Impfung), • Erkennung der Infektion (Virenscanner) und • Beseitigung des Virus.

V

477

Hierbei gibt es zwei einfache Vorgehensweisen, die sowohl zur Erkennung als auch zur Verhinderung der Vireninfektion eingesetzt werden: 1. Zu den schutzwürdigen Objekten werden Zusatzinformationen abgelegt, anhand derer man Veränderungen an den Objekten nachträglich feststellen kann. Man sucht in den Dateien bzw. den Datenträgern nach Merkmalen (Signaturen), die für einen bestimmten Virus typisch sind. 2. Virenschutzsoftware hält eine sog. Signaturendatenbank. Sie hat aber damit das Problem, dass die Signaturendatenbank veraltet und nicht mehr den neuesten Virensignaturen entspricht. Generell gilt, dass keine Virenschutzsoftware einen vollständigen Schutz gewährleistet, da sie nur bekannte und damit in der Signaturendatenbank abgelegte Viren erkennen kann. Es gibt heuristische Verfahren (z. B. McAfee), um unbekannte Viren zu entdecken. Virtueller Speicher Die virtuelle Speicherung ist keine spezielle Hardwareeinrichtung, sondern ein vom Betriebssystem gesteuertes Speicherverfahren, bei dem der reale Hauptspeicher scheinbar vergrößert wird. Dies wird dadurch ermöglicht, dass der Inhalt bestimmter Speicherbereiche auf die Festplatte ausgelagert und bei Zugriff hierauf wieder eingelagert wird (sog. Paging). Die Größe des virtuellen Speichers ist von der Größe des vorhandenen Hauptspeichers abhängig. Diese auswechselbaren Teile werden als Seiten bezeichnet. Die Anzahl der pro Zeiteinheit ausgetauschten Seiten heißt Paging-Rate. Vorteile bringt der virtuelle Speicher dadurch, dass bei der Programmierung nicht auf Hauptspeicherbegrenzungen Rücksicht genommen werden muss. Nachteile entstehen, wenn durch den ständigen Transfer zwischen realem und virtuellem Speicher längere Programmlaufzeiten zustande kommen. Plattenspeicher - externer SpeicherProgramm 1 Hauptspeicher - interner Speicher Programm 2 Betriebssystem Programm 1 Zeilen 0 bis 50 Programm 3

Programm 2 Zeilen 30 bis 70

Programm 3 Zeilen 21 bis 105

Virtueller Speicher

478

Glossar

Das Konzept des virtuellen Speichers wird auch im Rahmen des Mehrprogrammbetriebs eingesetzt. Dadurch können Teile von mehreren Programmen gleichzeitig in den Hauptspeicher geladen werden. Ein alternatives Verfahren zum virtuellen Speicher ist das Swapping. Hierbei wird jedes Programm vollständig in den Speicher geladen. Nachdem die Zeitscheibe für die Abarbeitung dieses Programms abgelaufen ist (s. Time Sharing), wird es wieder vom Hauptspeicher auf die Festplatte ausgelagert. Von-Neumann-Architektur Der prinzipielle Arbeitsablauf in jedem Computer besteht darin, dass Daten eingegeben (Eingabedaten oder Input), durch Programme verarbeitet und als Ergebnis ausgegeben werden (Ausgabedaten oder Output). Die Eingabe bzw. Erfassung von Daten verliert an Bedeutung, da die Daten oftmals automatisch erfasst und einmal erfasste Daten allen IS, die sie benötigen, zur Verfügung gestellt werden. Periphere Geräte bieten die Möglichkeit der kostengünstigen Eingabe. Die Geräte für die Eingabe, die Ausgabe und die Speicherung der Daten werden als periphere Medien bezeichnet.

Zentraleinheit Zentralprozessor

Übertragungsmedien

Steuerwerk

Hauptspeicher

Rechenwerk

Periphere Speichermedien

Elemente der Von-Neumann-Architektur

Ein-/ Ausgabemedien

W

479

Gemäß der Von-Neumann-Architektur bestehen Rechner aus • Dem Hauptspeicher für die Speicherung der Programme und der benötigten Daten, • dem Zentralprozessor (CPU – Central Processing Unit) mit einem Steuerwerk für die Interpretation und einem Rechenwerk (ALU, Arithmetic Logic Unit) für die Ausführung von Programmbefehlen, sowie den • Bussen/Kanälen (internen Datenwegen), auf denen der Datentransfer innerhalb der Zentraleinheit sowie zwischen der Zentraleinheit und den peripheren Geräten erfolgt.

W W3C (World Wide Web Consortium) Mit dem World Wide Web Consortium (W3C) hat sich eine weitgehend firmenneutrale Organisation der Standardisierung der Web Services angenommen. Das W3C ist das Gremium zur Standardisierung der das WWW betreffenden Techniken. Es wurde 1994 gegründet. WAN (Wide Area Network) Siehe LAN. Webanwendung, dynamisch, clientseitig, serverseitig Bei den Webanwendungen kann man zwischen statischen und dynamischen Webanwendungen unterscheiden. Webanwendungen im Rahmen des E-Business müssen den Nutzern die Möglichkeit bieten, nicht nur Informationen abzufragen, sondern auch Informationen einzugeben und hiermit auch die Kommunikation mit der Anwendung zu steuern. Beispielsweise ist es bei B2C-Anwendungen notwendig, dass der Nutzer sich registriert, nach spezifischen Informationen sucht, seine Auftragsdaten und Lieferadresse eingibt, sich in eine gesicherte Verbindung einloggt, oder aber seine Kreditkarteninformation dem Unternehmen mitteilt. Dazu gehört auch die Abfrage von Kundendaten oder Überweisungsdaten einer Bank, die über eine speziell aufgebaute HTML-Seite eingegeben werden. Mit Hilfe von dynamischen Webseiten ist es möglich, diese Anforderungen umzusetzen. Bei dynamischen Webanwendungen erfolgt die Anpassung des Inhalts von Webseiten an die aktuellen Rahmenbedingungen des HTTP-Aufrufs. Dies sind u. a. der Nutzer, der Inhalt einer Datenbank auf der Serverseite sowie die Anfragedaten des Nutzers. Aufgrund dieser Angaben werden der Inhalt und das Layout der Webseiten festgelegt. Für die Umsetzung von dynamischen Webanwendungen bestehen zwei Architekturalternativen: Clientseitige und serverseitige Programme.

Glossar

480

Webanwendung, clientseitig dynamisch Nach dem Aufruf einer Funktion auf einer HTML-Seite wird das Java Applet vom Server auf den Client übertragen und dort ausgeführt. Ein Applet ist ein Java-Programm, das speziellen Anforderungen unterliegt. Zur Ausführung benötigt der Client ein entsprechendes Plug-in, eine Java Virtual Machine. Plug-ins sind Erweiterungen des Browsers. Es handelt sich um eine Technik, um die Benutzerschnittstelle einer Anwendung (z. B. einen PDF-Viewer oder einen Videoplayer) in ein Browserfenster zu integrieren. Die Eingabe und Ausgabe erfolgen in einer Region des Browser-Fensters. Weiterhin muss der Client über einen Java-Interpreter verfügen. Client (Anwender)

HTML Dokument

WWW-Server

URLAufruf

Server

WWW-Browser mit Java Plugin

Client Rechner

HTML Dokument mit Applet

HTML Dokument mit Applet HTML Dateien

Auau dynamischer Webanwendungen mit Java Applets

Es besteht auch die Möglichkeit, clientseitig mittels JDBC (Java Database Connector) über die Java-Anwendungen auf Datenbanken zuzugreifen. Die Vorteile clientseitiger Lösungen sind, dass der WWW-Server entlastet wird und dass der Nutzer eine schnelle Rückmeldung auf seine Eingaben erhält. Die Nachteile sind eine Browserabhängigkeit und, dass der Quelltext bei den Skriptsprachen ungeschützt übertragen wird. Dadurch entstehen Sicherheitsprobleme für die Clients. Webanwendung, serverseitig dynamisch Wenn dynamische Webanwendungen mit serverseitigen Programmen umgesetzt werden, so werden die Anfragedaten vom Client an den Server übergeben und dort von Gateway-­Programmen oder mittels Skriptprozessoren ausgeführt. Die Ergebnisse werden vom Server an die Clients mittels des HTTP-Protokolls im HTML-Format zurückgesandt. Auf diese Weise entstehen dynamische HTML-Seiten, deren Inhalte nicht statisch vorgegeben sind.

W

481 Client (Anwender)

WWW-Server

URLAufruf

WWW-Browser

Skriptprozessor

Datenbank

Server Generiertes HTML Dokument

Generiertes HTML Dokument

HTML Dokument mit Script HTML Dateien

Auau dynamischer Webanwendungen durch serverseitige Skripte

Die folgenden Techniken werden hauptsächlich für die serverseitige Programmierung von dynamischen Webanwendungen eingesetzt: CGI, ASP, Skriptsprachen, Server APIs und SSI. CGI (Common Gateway Interface) stellt die Spezifikation der Schnittstelle zwischen Gateway-Programmen und WWW-Servern dar. CGI definiert, in welcher Form Eingaben an aufgerufene Programme übermittelt werden, und wie die Ausgabe dieser Programme gestaltet sein muss. Jede Art von Programm kann über CGI angesprochen werden, vorausgesetzt es existiert und ist ohne weiteres lauffähig. Die Vorteile serverseitiger Programme sind ihre Browserunabhängigkeit, die Möglichkeit des Zugriffs auf serverseitige Ressourcen (z. B. auf die Datenbank oder ein ERP-System). Die Nachteile sind die Serverbelastung, die häufigen Anfragen/Rückfragen beim Server, die Sicherheitsprobleme für den Server, teilweise auch die Abhängigkeit von einem bestimmten WWW-Server. Web Services Ein Web Service ist ein durch einen URI/URL eindeutig identifiziertes Anwendungsprogramm, dessen Schnittstelle durch XML-Dokumente definiert, beschrieben und gefunden werden kann. Ein Web Service unterstützt mittels XML-basierter Nachrichten die direkte Interaktion mit anderen Anwendungen. Die XML-Nachrichten werden über Internetprotokolle miteinander ausgetauscht. Zur Nutzung der Internettechnologien im Rahmen des Electronic Business besteht für Unternehmen die Notwendigkeit, Informationen über Unternehmensgrenzen zu transferieren, zusammenzuführen und zu verarbeiten. Hierbei müssen einzelne Transaktionen zu kompletten Geschäftsprozessen zusammengeführt werden. In vielen Fällen ist es möglich, Geschäftsfunktionen automatisch über eine Programmschnittstelle aufzurufen. Im Rahmen des B2C kann z. B. der Besitzer eines E-Shops die Berechnung von Transportkosten als Dienstleistung eines anderen Anbieters (z. B. eines Expressgutversenders) in seiner Anwendung nutzen. Die Kreditkartenüberprüfung ist ein

482

Glossar

anderes Beispiel (siehe (Dumke et al. 2003) und (Eberhard und Fischer 2003)). Ein solches Programm, das nur bei Bedarf über das Internet aufgerufen wird, wird als Web Service bezeichnet. Die Abwicklung und die Koordination von Web Services sollten in einer verteilten Umgebung stattfinden. Hierbei müssen unterschiedliche IS-Architekturen, Programmierkonzepte und Datenformate berücksichtigt werden, da der Zugriff auf die Web Services beim Anwender über eine Schnittstelle in den Programmen erfolgen soll. Mittels Web Services sollen Anwendungsfunktionalität über das Internet auf eine einfache Art verfügbar gemacht und somit verteilte Geschäftsprozesse unterstützt werden. Die generelle Idee der Web Services ist nicht neu, nur ist ihre Ausgestaltung in der Vergangenheit durch proprietäre Ansätze bestimmt (siehe auch W3C). Die Strategie hinter den Web Services ist folgende: Zum einen werden standardisierte Technologien als Basis festgeschrieben. Zum anderen werden die Web Services aber auch nicht über lang laufende offizielle Standardisierungsgremien definiert. Die Web Services sind so ausgelegt, dass man vorhandene Funktionalitäten verteilter Anwendungen wieder verwenden kann, statt diese erneut zu implementieren (siehe auch SOA/Serviceorientierte Architektur).

Web ServiceVermittler

UDDI

Web ServiceNutzer

Verbinden

Web ServiceAnbieter

SOAP

Auau von Web Services

WSDL

Das in dargestellte Prinzip zeigt die Einbindung der unterschiedlichen Partner. Die Anbieter von Web Services veröffentlichen ihre Dienste beim Web-Service-Vermittler. Ein potenzieller Web-Service-Nutzer sucht bzw. findet einen Dienst beim Vermittler und nimmt diesen dann vom Anbieter in Anspruch (siehe auch (Dumke et al. 2003) und (Eberhard und Fischer 2003)). (Siehe auch SOAP, WSDL).

W

483

WLAN (Wireless Local Area Network) Die Wireless Local Area Network (WLAN)-Technik (oder auch Wi-Fi) ermöglicht eine punktuelle, drahtlose, räumlich beschränkte Anbindung von Rechnern an ein lokales Netz. Dies erfolgt mittels so genannter Access Points. Für die über einen Access Point auf ein Netz zugreifenden Rechner liegt die gemeinsame maximale Brutto-Übertragungsrate abhängig vom umgesetzten IEEE 802.11 Standard zwischen 2 bis 600 Mbit/s. Hierbei muss die Bandbreite für Up- und Download geteilt werden. Für den Betrieb eines Access Points ist keine Frequenzlizenz erforderlich. Beim Wechseln zwischen zwei WLANs bricht die Verbindung ab. Als Internet-Protokoll kommt Mobile IP zum Einsatz. Ein großes Problem der WLANs ist das Sendefeld des Access Points. Daher muss, um unberechtigten Nutzern den Zugang zum WLAN zu versperren, auf eine Zugangskontrolle und Verschlüsselung geachtet werden. Workflow-System Ein Vorgang besteht aus einer Folge von Tätigkeiten und dem Laufweg des Vorgangs über mehrere Arbeitsplätze. Aufgrund definierter Entscheidungsalternativen können Verzweigungen realisiert werden. Eine Tätigkeit umfasst mehrere Arbeitsschritte, die zusammengehörend an einem Arbeitsplatz ablaufen. Die Unterstützung der Bearbeitung von Vorgängen durch sog. Workflow-Systeme nimmt in Unternehmen zunehmend eine wichtige Rolle ein. Zudem sind Workflow-Systeme oftmals in betriebliche Anwendungen (z. B. im SAP ERP-System) und Content-Management-Systeme (s. CMS) integriert. Mit den Workflow-­Systemen soll der einzelne Arbeitsplatz bei seiner Zusammenarbeit mit anderen Beteiligten unterstützt werden, wenn für die Zusammenarbeit eine Anzahl von festgelegten Regeln erkannt wird. Neben der Ablauforganisation, d. h. den Vorgängen, muss die Aufbauorganisation des Unternehmens durch das Workflow-System berücksichtigt werden. Die Zuordnung der Tätigkeiten erfolgt i. d. R. über die Stelle/Rolle und nicht über die Person. Folgende Funktionen sind von einem Workflow-System zu fordern: • • • • • • • • • • •

Laufwegssteuerung, formalisierte Vorgänge und individuelle Vorgänge, Arbeitsplätze als Empfänger/Sender, Programme als Empfänger/Sender, dynamische Laufwegssteuerung (abhängig von Inhalten und erfolgter Verarbeitung), differenzierte Befugnisse Einzelner oder von Gruppen für die Bearbeitung der Dokumente und des Laufwegs (lesen, ändern, löschen, anfügen, kopieren, drucken), Statuskontrolle, differenzierte Statusverfolgung, Mitzeichnungsverfahren, revisionsfähiger Nachweis, und Ausnahmebehandlung.

484

Glossar

WSDL (Web Service Description Language) Die Web Service Description Language (WSDL) dient der Beschreibung eines Web Service. Mit der Sprache kann festgelegt werden, was der Web Service tut, wie er aufgerufen wird und wo er sich befindet. Ein WSDL-Dokument beinhaltet einen Schnittstellen- und einen Implementierungsteil. Die Basis für den Informationsaustausch ist wiederum XML. Würmer Würmer sind ähnlich wie Viren, sie können sich jedoch im Gegensatz zu Viren selbst replizieren und automatisch auf andere, vernetzte Systeme ausbreiten. Würmer nutzen hierzu Fehler in den Systemen. WWW (World Wide Web) Das Prinzip des World Wide Web beruht auf der Verknüpfung von elektronischen Dokumenten über Schlüsselbegriffe und Symbole, sog. Hyperlinks. Dokumente, die solche Verknüpfungen beinhalten, werden als Hypertextdokumente bezeichnet. Durch das Anklicken eines Hyperlinks wird der Aufruf eines anderen Dokuments oder die Verarbeitung einer Funktion initiiert. Das Internet verwendet für die WWW-Dienste das Protokoll HTTP (Hypertext Transfer Protocol). Damit wird die Kommunikation zwischen den WWW-Servern und den -Clients durchgeführt. HTTP ist ein zustandsloses Protokoll. Dies bedeutet, dass jede einzelne Clientanforderung an den WWW-Server mit einem einzigen HTTP-Datenpaket beantwortet wird. Dies führt dazu, dass Server eine große Anzahl von Clients quasi-parallel bedienen können, da die Server keine Verbindungszustände abspeichern müssen. WWW-Server (Web-Server) Beim WWW-Server handelt es sich um ein Programm zum Empfang und zur Beantwortung von HTTP-Anfragen. Der WWW-Server ist also keine spezielle Hardware sondern eine Software. Ein WWW-Server stellt eine Verbindung zwischen dem Dateisystem des Servers und dem Benutzer mittels HTTP her. Er verhindert, dass der Benutzer direkten Zugriff auf das Dateisystem hat. Der WWW-Server verwaltet die Benutzer und Zugriffsrechte und protokolliert die Zugriffe. Die am weitesten verbreiteten WWW-Server sind der Apache WWW-Server und der Internet Information Server (IIS) von Microsoft. Der Apache WWW-Server ist eine Open Source Software. Er ist zwar für unterschiedliche Betriebssysteme erhältlich, wird aber bevorzugt unter dem Betriebssystem LINUX in der LAMP-Konfiguration (LINUX, Apache, MySql und PHP), die nur aus Open Souce Software Komponenten besteht, betrieben.

X XML (Extensible Markup Language) XML (Extensible Markup Language) ist eine Auszeichnungssprache, die entwickelt wurde, um die Aussagekraft von Webdokumenten zu verbessern. Während HTML beschreibt, wie Daten (Text und Bilder) dargestellt werden sollen, legt XML fest, was die

X

485

Daten bedeuten. Mit XML kann jedem Datenelement auf einer WWW-Seite oder in einem Dokument eine Bedeutung zugeordnet werden. Dies erleichtert die Verwendung von Informationen aus dem WWW oder aus Dokumenten in betrieblicher Anwendungssoftware. In XML ist eine Zahl nicht nur eine Zahl, sondern kann eine Postleitzahl, einen Preis oder ein Datum darstellen. Beispielsweise würde ein Buchpreis auf einer Webseite mit HTML mittels HTML-Tags EURO 39,99 fett dargestellt werden. Die Zahl besitzt aber für den Zweck der Datenverarbeitung keine Bedeutung. Dies gilt insbesondere, wenn diese Information durch ein Programm automatisch interpretiert werden müsste. XML kann der Zahl nun eine Bedeutung zuweisen, indem die Zahl mit einem entsprechenden Label ausgezeichnet wird: EURO 39,99. Durch seine Eigenschaften ist XML nicht nur für das WWW und die Anwendungssoftware, die auf WWW-Seiten zugreift, von Bedeutung, sondern kann allgemein für Anwendungen zur Speicherung bzw. zum Austausch von Informationen dienen.

Literaturverzeichnis

Adam, D.: Planung und Entscheidung, 4. Auflage, Springer Gabler, Wiesbaden 1996. Adam, D.: Produktions-Management, 9. Auflage, Springer Gabler, Wiesbaden 1998. Ahituv, N, Neumann, S.: Principles of Information Systems for Management, 4. Auflage, William C. Brown Publishers, Dubuque 1994. Alexander, C., Ishikawa, S., Silverstein, M.: Pattern Language  – Towns Buildings Construction, Oxford University Press, New York 1977. Alpar, P., Blaschke, S., Keßler, S.: Web 2.0, Hessen-Media, Bd. 57, 2007. Alpar, P., Kim, M.: A Microeconomic Approach to the Measurement of IT Value, in: Journal of MIS, 7(1990)2, S. 55–69. Alpar, P., Niedereichholz, J. (Hrsg.): Data Mining im praktischen Einsatz, Springer, Braunschweig/ Wiesbaden 2000. Alpar, P., Polyovlu, A.: Management of Multi-cloud Computing, in: Oshri, I., Kotlarsky, J., Willcocks, L. P. (Hrsg.): Global Sourcing of Digital Services: Micro and Macro Perspectives, Springer, 2017, S. 124–137. Alpar, P., Porembski, M.: Auswirkungen von IT-Einsatz auf die Kosteneffizienz kleinerer Banken – Eine empirische Analyse mittels Data Envelopment Analysis, in: Weinhardt, C., Meyer zu Selhausen, H., Morlock, M.: Informationssysteme in der Finanzwirtschaft, Springer, Berlin 1998, S. 459–472. Alpar, P., Saharia, A. N.: Outsourcing Information System Functions – An Organization Economics Perspective, in: Journal of Organizational Computing, 5(1995)3, S. 197–217. Alpar, P., Schulz, M.: Self-Service Business Intelligence, in: Business & Information Systems Engineering, 58(2016)2, S. 151–155. Alpar, P.: Kommerzielle Nutzung des Internet, 2. Auflage, Springer, Berlin 1998. Alt, R.: Überbetriebliches Prozessmanagement. Gestaltungsalternativen und Vorgehen am Beispiel integrierter Prozessportale, Logos, Berlin 2008. Alt, R., Auth, G., Kögler, C.: Innovationsorientiertes IT-Management mit DevOps – IT-Management im Zeitalter von Digitalisierung und Software-defined Business, Springer Gabler, Wiesbaden 2017. Alt, R., Bernet, B., Zerndt, T.: Transformation von Banken – Praxis des In- und Outsourcings auf dem Weg zur Bank 2015, Springer, Berlin/Heidelberg 2009. Alt, R., Ehrenberg, D.: Fintech – Umbruch der Finanzbranche durch IT, in: Wirtschaftsinformatik & Management, 8(2016)3, S. 8–17. Alt, R., Puschmann, T.: Digitalisierung der Finanzindustrie, Springer, Berlin/Heidelberg 2016. Alt, R., Reinhold, O.: Social Customer Relationship Management – Grundlagen, Anwendungen und Technologie, Springer, Berlin/Heidelberg 2016.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7

487

488

Literaturverzeichnis

Anderson, C.: The Long Tail, in: Wired, http://www.wired.com/2004/10/tail/, 2004, abgerufen am 13.04.2016. Anderson, D.: Kanban – Evolutionäres Change Management für IT-Organisationen, dpunkt, Heidelberg 2011. Anthony, R. A.: Planning and Control Systems – A Framework for Analysis, Harvard University, Cambridge 1965. Ashford, C., Gauthier, P.: OSS Design Patterns – A Pattern Approach to the Design of Telecommunications Management Systems, Springer, Berlin 2009. Aspin, A.: Pro Power BI Desktop, 2. Auflage, Apress, New York 2018. Austrup, S.: Controlling von Business Process Outsourcing, Logos, Berlin 2007. AWV: Der elektronische Rechnungsaustausch – Ein Leitfaden für Unternehmen zur Einführung elektronischer Rechnungen, Arbeitsgemeinschaft für wirtschaftliche Verwaltung e. V., Eschborn 2006. Axelos 2015: PRINCE2 Agile, 2015. Axelos 2017: Managing Successful Projects with PRINCE2, 6. Auflage, 2017. Balzert, H.: Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering. 3. Auflage, Spektrum Akademischer Verlag, Heidelberg, 2009. Balzert, H.: Lehrbuch der Objektmodellierung, Spektrum Akademischer Verlag, Heidelberg/Berlin 1999. Balzert, H.: Lehrbuch der Software-Technik, Spektrum Akademischer Verlag, Heidelberg/Brelin 1996. Bamberg, G., Coenenberg, A. G., Krapp, M.: Betriebswirtschaftliche Entscheidungslehre, 14. Auflage, Vahlen, München 2008. Baumöl, U. et  al.: Einordnung und Terminologie des Software Reengineering, in: Informatik-­ Spektrum, 19(1996)4, S. 191–195. Bechtel, W., Brink, A.: Einführung in die moderne Finanzbuchführung – Grundlagen der Buchungsund Abschlußtechnik und Grundzüge der EDV-Buchführung, 10. Auflage, De Gruyter Oldenbourg, München 2010. Beck, K. et  al.: Manifesto for Agile Software Development, http://agilemanifesto.org/, 2001, abgerufen am 15.12.2018. Beck, K.: Extreme Programming – Das Manifest, Addison-Wesley, München 2000. Becker, J., Delfmann, P., Knackstedt, R., Kuropka, D.: Konfigurative Referenzmodellierung, in: Becker, J., Knackstedt, R. (Hrsg.): Wissensmanagement mit Referenzmodellen, Physica, Heidelberg 2002, S. 25–144. Becker, J., Rosemann, M., Schütte, R.: Grundsätze ordnungsmäßiger Modellierung, in: Wirtschaftsinformatik, 37(1995)5, S. 435–445. Becker, J., Schütte, R.: Handelsinformationssysteme, 2. Auflage, mi-Wirtschaftsbuch, Frankfurt a. M. 2004. Bensberg, F., Buscher, G.: Digitale Transformation und IT-Zukunftsthemen im Spiegel des Arbeitsmarkts für IT-Berater  – Ergebnisse einer explorativen Stellenanzeigenanalyse, in: Nissen, V., Stelzer, D., Straßburger, S., Fischer, D. (Hrsg.): Tagungsband Multikonferenz Wirtschaftsinformatik (MKWI), Technische Universität Ilmenau, Ilmenau 2016, S. 1007–1018. Bensberg, F., Buscher, G., Schmidt, A.: Der Arbeitsmarkt für Wirtschaftsinformatiker – Berufsbilder und Kompetenzen im Spannungsfeld der digitalen Transformation, in: 30. Jahrestagung des Arbeitskreises Wirtschaftsinformatik der deutschsprachigen Fachhochschulen (AKWI), Brandenburg 2017. Bensberg, F., Buscher, G.: Die Kunst der Systeme  – Kompetenzen und Berufsbilder des Enterprise Architecture Management, in: Czarnecki, C. et al. (Hrsg.): Workshops der Informatik 2018, ­Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Köllen Druck+Verlag, Bonn 2018, S. 43–58. Bensberg, F., Buscher, G.: Treiber der Digitalisierung – Transformationale Informationstechnologien im Spiegel des Arbeitsmarkts, in: AKWI Journal, (2017)6, S. 76–85.

Literaturverzeichnis

489

Bensberg, F.: Mobile Business Intelligence – Besonderheiten, Potenziale und prozessorientierte Gestaltung, in: Bauer, H. H., Dirks, T., Bryant, M. D. Hrsg.): Erfolgsfaktoren des Mobile Marketing, Springer, München 2008, S. 71–87. Bensberg, F.: BI-Portfoliocontrolling – Konzeption, Methodik und Softwareunterstützung, Nomos, Baden-Baden 2010. Bensberg, F.: Web Log Mining als Instrument der Marketingforschung in internet-basierten Märkten – Ein systemgestaltender Ansatz für internetbasierte Märkte, Springer, Wiesbaden 2001. Beutelspacher, A.: Kryptologie, 9. Auflage, Springer, Braunschweig/Wiesbaden 2009. BfA: Fachkräfteengpassanalyse, Bundesagentur für Arbeit, http://statistik.arbeitsagentur.de/Statischer-Content/Arbeitsmarktberichte/Fachkraeftebedarf-Stellen/Fachkraefte/BA-FK-Engpassanalyse-2018-06.pdf, 2017, abgerufen am 06.08.2018. Bifet, A., Holmes, G., Kirkby, R., Pfahringer, B.: Data Stream Mining – A Practical Approach, Centre for Open Software Innovation (COSI), Waikato 2011. BITKOM: Management von Big-Data-Projekten, Berlin 2013. Blocher, W.: C2B statt B2C? – Auswirkungen von Blockchain, Smart Contracts & Co. auf die Rolle des Verbrauchers, in: Kenning, P., Lamla, J., (Hrsg.): Entgrenzungen des Konsums, Springer Gabler, Wiesbaden 2018, S. 87–107. BME: Elektronische Beschaffung 2015: Stand der Nutzung und Trends, Bundesverband Materialwirtschaft, Einkauf und Logistik e.V. (BME), Frankfurt/M. 2015. BMF: Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS), Bundesministerium der Finanzen, in: BStBl. I 1995, S. 738. BMI: Wirtschaftlichkeitsbetrachtungen – WiBe Kalkulator, Bundesministerium des Innern: https:// www.cio.bund.de/Web/DE/Architekturen-und-Standards/Wirtschaftlichkeitsbetrachtungen/ Software/software_node.html, 2018, abgerufen am 15.01.2019. Boehm, B. W.: Seven Basic Principles of Software Engineering, in: Journal of Systems and Software, 3(1983)1, S. 3–24. Bogaschewsky, R., Müller, H.: BME-Barometer Elektronische Beschaffung, Bundesverband Materialwirtschaft, Einkauf und Logistik e.V., 2018. Bölke, S., Campana, C., Schott, E.: Was bringt die neue PMBOK-Version in der Praxis?, in: Computerwoche 2009, http://www.computerwoche.de/1904516, abgerufen am 13.04.2016. Bons, H., Salmann, S.: Software-Qualitätssicherung und Software-Normen, in: Wirtschaftsinformatik, 34(1992)4, S. 401–412. Booch, G., Rumbough, J., Jacobson, I.: The Unified Modeling Language User Guide, Addison Wesley, Boston 1999. Booch, G.: Object-oriented Design with Applications, Redwood City 1991. Böttcher, R.: IT-Service-Management mit ITIL V3 – Einführung, Zusammenfassung und Übersicht der elementaren Empfehlungen. 2. Auflage, Heise, Hannover 2010. Brandt, P.: IT in der Energiewirtschaft, in: Wirtschaftsinformatik, 49(2007)5, S. 380–385. Britz, D.: Understanding Convolutional Neural Networks for NLP, http://www.wildml.com/2015/11/ understanding-convolutional-neural-networks-for-nlp/, 2015, abgerufen am 06.11.2018. Brombacher, R.: Ansätze zur Bewältigung der Softwarekrise bei Banken und Versicherungen, in: Information Management, 10(1995)3, S. 12–20. Brooks, F. P.: The Mythical Man-Month, Addison-Wesley, Reading 1975. Brynjolfsson, E.: The Contribution of Information Technology to Consumer Welfare, in: Information Systems Research, 7(1996)3, S. 281–300. BSI: IT-Grundschutz-Kompendium  – Edition 2018, https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/itgrundschutzKompendium.html, 2018a, abgerufen am 06.08.2018.

490

Literaturverzeichnis

BSI: Zertifizierung nach ISO 27001 auf der Basis von IT-Grundschutz, https://www.bsi.bund.de/ SharedDocs/Downloads/DE/BSI/Grundschutz/Zertifikat/ISO27001/Zertifizierungsschema_ Kompendium.pdf?__blob=publicationFile&v=3, 2018b, abgerufen am 06.08.2018. Buhl, H.-U., Heinrich, B., Henneberger, M., Krammer, A.: Service Science, in: Wirtschaftsinformatik, 50(2008)1, S. 60–65. Bulos, D., Forsman, S.: Getting Started with ADAPT – OLAP Database Design, http://www.symcorp.com/downloads/ADAPT_white_paper.pdf, 2006, abgerufen am 13.04.2016. Bundesverwaltungsamt:Anwendungslandschaft, http://www.bva.bund.de/DE/Organisation/Abteilungen/ Abteilung_BIT/Leistungen/IT_Produkte/IsyFact/Produkt/dossier-produkte.html?nn=5918236¬First=true&docId=5918216, 2018, abgerufen am 30.05.2018. Buschmann, F., Schmidt, D., Stal, M., Rohnert, H.: Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, Wiley, New York 2000. Chen, H., Chiang, R. H. L., Storey, V. C.: Business Intelligence and Analytics – From Big Data to Big Impact, in: MIS Quarterly, 36(2012)4, S. 1165–1188. Chen, P. P.: The Entity-Relationship Model – Towards a Unifed View of Data, in: ACM Transactions on Database Systems, 1(1976)1, S. 9–36. Chessell, M., Scheepers, F., Nguyen, N., van Kessel, R., van der Starre, R.: Governing and Managing Big Data for Analytics and Decision Makers, Redguide REDP-5120-00, IBM, Armonk 2014. Clemons, E. K., Kimbrough, S. O.: Information Systems, Telecommunications and Their Effects on Industrial Organization, in: Proceedings 7th International Conference on Information Systems, San Diego 1986, S. 99–108. Cockburn, A.: Agile Software Development, Addison-Wesley, Boston 2002. Codd, E. F., Codd, S. B.: Ein neuer Begriff: OLAP – Online Analytical Processing, in: it Management, (1995a)1–2, S. 39–47. Codd, E.  F., Codd, S.  B.: Pro und contra von OLAP  – Was bieten diese Systeme?, Analytische Datenbanken, in: it Management, (1995b)3–4, S. 34–39. Czarnecki, C., Dietze, C.: Reference Architecture for the Telecommunications Industry: Transformation of Strategy, Organization, Processes, Data, and Applications, Springer, Cham 2017. Czarnecki, C.: Entwicklung einer referenzmodellbasierten Unternehmensarchitektur für die Telekommunikationsindustrie, Logos, Berlin 2013. Dambeck, H.: Malen mit Zahlen  – Daten im neuen Look, in: C’t magazin für computertechnik, (2013)17, S. 102–109. Date, C. J.: A Guide to the SQL Standard, 4. Auflage, Addison-Wesley, Boston 1996. Davenport, T. H., Short, J. E.: The New Industrial Engineering – Information Tech-nology and Business Process Redesign, in: Sloan Management Review, 31(1989)4, S. 11–27. De Win, B., Gregoire, J., Buyens, K., Scandariato, R., Joosem, W.: On the Secure Software Development Process – CLASP, SDL and Touchpoints Compared, in: Information and Software Technology, 51(2009), S. 1152–1171. Decker, G., Barros, A.: Interaction Modeling Using BPMN, in: ter Hofstede, A. H. M., Benatallah, B., Paik, H.-Y. (Hrsg.): BPM 2007 International Workshops, LNCS Vol. 4928, 2008, S. 208–219. Deelmann, T., Loos, P.: Visuelle Methoden zur Darstellung von Geschäftsmodellen – Methodenvergleich, Anforderungsdefinition und exemplarischer Visualisierungsvorschlag, Arbeitsbericht der Forschungsgruppe Information Systems & Management/Universität Mainz, 2003. DeMarco, T., Lister, T.: Bärentango, Hanser, München/Wien 2003. DeMarco, T.: Structured Analysis and System Specification, Prentice Hall, Englewood Cliffs 1979. Derboven, W., Dick M., Wehner, T.: Erfahrungsorientierte Partizipation und Wissensentwicklung. Die Anwendung von Zirkeln im Rahmen von Wissensmanagementkonzepten, Hamburger Beiträge zur Psychologie und Soziologie der Arbeit, (1999)18. Deutscher Corporate Governance Kodex, https://dcgk.de/de/kodex.html, 2017, abgerufen am 10.01.2019. Dijkstra, E. W.: A Discipline of Programming, Prentice Hall, Englewood Cliffs 1967.

Literaturverzeichnis

491

DIN 69901-5:2009: Projektmanagement – Projektmanagementsysteme, Teil 5: Begriffe, Berlin 2009. DIN-ISO 10007: Qualitätsmanagement – Leitfaden für Konfigurationsmanagement (ISO 10007:2003), 2003. Dumke, R., Lother, M., Wille, C., Zbrog, F.: Web Engineering, 1. Auflage, Pearson Studium, München 2003. Eberhard, A., Fischer, S.: Web Services, 1. Auflage, München 2003. Erl, T.: SOA – Principles of Service Design, Prentice Hall, 2008. Esswein, W.: Referenzmodelle und -modellierung, in: Benker, T., Jürck, C., Wolf, M. (Hrsg.): Geschäftsprozessorientierte Systementwicklung  – Von der Unternehmensarchitektur zum IT-­ System, Springer, Wiesbaden 2016, S. 51–62. Evans, P. B., Wurster, T. S.: Strategy and the New Economics of Information, in: Harvard Business Review, 75(1997)5, S. 70–82. Fan, W., Bifet, A.: Mining Big Data – Current Status, and Forecast to the Future, in: SIGKDD Explorations, 14(2012)2, S. 1–5. Färber, F., Jäcksch, B., Lemke, C., Große, P., Lehner, W.: Hybride Datenbankarchitekturen am Beispiel der neuen SAP In-Memory-Technologie, in: Datenbank Spektrum, 10(2010), S. 81–92. Feldman, R., Sanger, J.: The Text Mining Handbook: Advanced Approaches in Analyzing Unstructured Data, Cambridge University Press, New York 2006. Fiedler, I., Fiedler, F., Ante, L.: Die Vision eines integrierten Energiemarktes – Wie die Verknüpfung der Technologien Smart Meter, Blockchain und Echtzeitauktionen einen effizienten Markt schafft und die notwendige Regelleistung drastisch reduziert, http://www.blockchainresearchlab. org/wp-content/uploads/2017/01/Die-Vision-eines-integrierten-Energiemarktes.pdf, 2016, abgerufen am 12.09.2017 Finkelstein, R.: Understanding the Need for On-Line Analytical Servers, Arbor Software Corporation, Sunnyvale 1996. Fischbach, M., Puschmann, T., Alt, R.: Service-Lifecycle-Management, in: Business & Information Systems Engineering, 5(2013)1, S. 45–49. Forbig, P., Kerner, I. (Hrsg.): Lehr- und Übungsbuch Softwareentwicklung, Carl Hanser Verlag, München 2004. Frank, J.: Standard-Software – Kriterien und Methoden zur Beurteilung und Auswahl von Software-­ Produkten, 2. Auflage, Verlagsgesellschaft Rudolf Müller, Köln 1980. Freeman, E. R.: Strategic Management. A Stakeholder Approach, Pitman, Boston 1984. Freeman, E. R., Harrison, J. S., Wicks, A. C.: Managing for Stakeholders. Survival, Reputation, and Success. Yale University Press, New Haven 2007. Freund, J., Rücker, B.: Praxishandbuch BPMN, 5. Auflage, Hanser, München 2016. Fritz, W.: Internet-Marketing und Electronic Commerce, 3. Auflage, Springer Gabler, Wiesbaden 2004. Fuß, F.: Die Kunden, die Kultur und die Kontinuität – Über eine der größten Transformationen in der Telekommunikationsindustrie, in: Mohr, N. et al. (Hrsg.): Herausforderung Transformation – Theorie und Praxis, Springer, Berlin/Heidelberg 2010, S. 71–84. Gabler: Industrie 4.0, Springer Gabler, http://wirtschaftslexikon.gabler.de/Archiv/-2080945382/industrie-4-0-v1.html, 2016, abgerufen am 13.04.2016. Gadatsch, A.: Grundkurs Geschäftsprozess-Management. 8. Auflage, Springer Vieweg, Wiesbaden 2017. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns – Elements of Reusable Software Components, Addison-Wesley, Reading 1995. Gane, C., Sarson, T.: Structured Systems Analysis and Design – Improved Systems Technologies, New York 1977. Gantz, J., Reinsel, D.: The Digital Universe In 2020 – Big Data, Bigger Digital Shadows, and Biggest Growth in the Far East, IDC IView, http://idcdocserv.com/1414, 2012, abgerufen am 13.04.2016.

492

Literaturverzeichnis

Gastner, R.: Automatisierung der Migration von CUI nach GUI, in: Huber-Wäschle, F. et al. (Hrsg.): Proceedings GISI 95 – Herausforderungen eines globalen Informationsverbundes für die Informatik, Berlin 1995, S. 536–543. Gernert, C., Ahrend, N.: IT-Management: System statt Chaos – Ein praxisorientiertes Vorgehensmodell, De Gruyter Oldenbourg, München 2000. Giles, J.: Internet Encyclopedias Go Head to Head, in: Nature, 438(2005), S. 900–901. Ginzberg, M.: A Prescriptive Model of System Implementation, in: Systems, Objectives, Solutions, 1(1981)1, S. 33 46. Gluchowski, P., Gabriel, R., Dittmar, C.: Management Support Systeme und Business Intelligence – Computergestützte Informationssysteme für Fach- und Führungskräfte, 2. Auflage, Springer, Berlin 2008. Gluchowski, P.: Techniken und Werkzeuge zur Unterstützung des betrieblichen Berichtswesens, in: Chamoni, P., Gluchowski, P. (Hrsg.): Analytische Informationssysteme – Business Intelligence-­ Technologien und -Anwendungen, 4. Auflage, Springer Gabler, Berlin 2010, S. 259–280. Goeken, M.: Entwicklung von Data-Warehouse-Systemen – Anforderungsmanagement, Modellierung, Implementierung, Deutscher Universitätsverlag, Wiesbaden 2006. Goldberg, A., Robson, D.: Smalltalk-80 – The Language and its Implementation, Longman Higher Education, Menlo Park 1983. Goltsche, W.: COBIT kompakt und verständlich, Vieweg+Teubner, Wiesbaden 2006. Gómez, J. M., Rautenstrauch, C., Cissek, P.: Einführung in Business Intelligence mit SAP NetWeaver 7.0, Springer, Berlin 2009. Görz G.: Verarbeitung natürlicher Sprache, in: von Luck K. (Hrsg.): Künstliche Intelligenz, Informatik-­Fachberichte Band 203, Springer, Berlin/Heidelberg 1989. Götze, U., Weber, T.: ZP-Stichwort: Total Cost of Ownership, in: Zeitschrift für Planung & Unternehmenssteuerung, 19(2008)2, S. 249–257. Grob, H. L., Bensberg, F.: Controllingsysteme – Entscheidungstheoretische und informationstechnische Grundlagen, Vahlen, München 2009. Grob, H. L., Bensberg, F.: Kosten- und Leistungsrechnung – Theorie und SAP-Praxis, Vahlen, München 2005. Grob, H. L., Schultz, M. B.: Computergestützte Analyse von Entscheidungsbäumen, in: Wirtschaftswissenschaftliches Studium, 30(2001)3, S. 135–142. Grob, H. L.: Einführung in die Investitionsrechnung – Eine Fallstudiengeschichte, 5. Auflage, Vahlen, München 2006. Grob, H.  L.: Investitionsrechnung zur Beurteilung substitutiver Anwendungssoftware, in: Grob, H. L. (Hrsg.): Arbeitsbericht Nr. 10 der Reihe Computergestütztes Controlling, Münster 2000. Grothaus, H.-P.: M2M Kommunikation im Agrarsektor, eco – Verband der deutschen Internetwirtschaft e.V., Keynote M2M – Vom Hypertrend zum Geschäftsmodell, Köln 21.11.2013. Grots, A., Pratschke, M.: Design Thinking – Kreativität als Methode, in: St.Gallen Marketing Review, (2009)2, S. 18–23. Gründl, H., Perlet, H. (Hrsg.): Solvency II & Risikomanagement – Umbruch in der Versicherungswirtschaft, Gabler, Wiesbaden 2005. Gurzki, T., Hinderer, H., Kirchhof, A., Vlachakis, J.: Die Fraunhofer Portal Analyse und Design Methode (PADEM) – Der effiziente Weg vom Prozess zum Portal, Fraunhofer-Institut für Arbeitswirtschaft und Organisation, Stuttgart 2004. Gutzwiller, T. A.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Physica, Heidelberg 1994. Häfner, L.: Demand Side Management – Entscheidungsunterstützungssysteme für die flexible Beschaffung von Energie unter integrierten Chancen- und Risikoaspekten, in: HMD Praxis der Wirtschaftsinformatik, 55(2018)3, S. 627–645.

Literaturverzeichnis

493

Hagel, J., Singer, M.: Unbundling the Corporation, in: Harvard Business Review, 77(1999)2, S. 133–141. Hahne, M.: Mehrdimensionale Datenmodellierung für analyseorientierte Informationssysteme, in: Chamoni, P., Gluchowski, P. (Hrsg.): Analytische Informationssysteme, 4. Auflage, Springer Gabler, Berlin 2010, S. 229–258. Hamel, G., Prahalad, C. K.: The Core Competence of the Corporation, in: Harvard Business Review, 68(1990)3, S. 79–91. Hansmann, H., Neumann, S.: Prozessorientierte Einführung von ERP-Systemen, in: Becker, J., Kugeler M., Rosemann M. (Hrsg.): Prozessmanagement, Springer Gabler, Berlin/Heidelberg 2012, S. 329–366. Heinemann, G.: Die Neuausrichtung des App- und Smartphone-Shopping, Springer Gabler, Wiesbaden 2018. Heinonen, K., Strandvik, T., Mickelsson, J., Andersson, P.: A Customer-Dominant Logic of Service, in: Journal of Service Management, 21(2010)4, S. 531–548. Heinrich, L. J., Stelzer, D.: Informationsmanagement – Grundlagen, Aufgaben, Methoden, 10. Auflage, De Gruyter Oldenbourg, München 2011. Hippner, H., Hubrich, B., Wilde, K. D. (Hrsg.): Grundlagen des CRM – Konzepte und Grundlagen, 3. Auflage, Springer Gabler, Wiesbaden 2011. Hughes, B., Cotterell, M.: Software Project Management, McGraw Hill Higher Education, Maidenhead 2006. Hukkinen, T.; Mattila, J.; Ilomäki, J.; Seppälä, T.: A Blockchain Application in Energy. ETLA Reports No. 71, https://www.etla.fi/wp-content/uploads/ETLA-Raportit-Reports-71.pdf, 2017, abgerufen am 12.09.2017. IEEE (Hrsg.): Guide to the Software Engineering Body of Knowledge (SWEBOK) V3, IEEE Computer Society, http://www.swebok.org, 2013, abgerufen am 13.04.2016. IEEE (Hrsg.): IEEE Recommended Practice for Architectural Description of Software Intensive Systems (IEEE Std 1471-2000), IEEE Computer Society, New York 2000. IHK NRW: Digitale Transformation und Industrie 4.0, https://www.ihk-nrw.de/beitrag/digitale-transformation-und-industrie-40, 2015, abgerufen am 06.08.2018. Imhoff, C., White, C.: Self-Service Business Intelligence. Empowering Users to Generate Insights. TDWI Research, http://triangleinformationmanagement.com/wp-content/uploads/2014/02/SelfService-Business-Intelligence-empowering-users-to-generate-insights.pdf, 2011, abgerufen am 31.08.2018. Inmon, W. H.: Building the Data Warehouse, 3. Auflage, Wiley, New York 2002. ISACA: COBIT 5, Information Systems Audit and Control Association, http://www.isaca.org, 2012, abgerufen am 13.04.2016. ISO 12207:1995: Information Technology – Software Lifecycle Process, 1995. ITSMF UK: ITIL® Foundation Handbook, 3. Auflage, Belfast 2012. ITU: Enhanced Telecom Operations Map (eTOM) – The Business Process Framework: ITU-T Recommendation M.3050.1., http://www.itu.int/rec/T-REC-M.3050.1-200703-I/en, 2007, abgerufen am 22.09.2018. Jacobsen, I.: Object-Oriented Software Engineering  – A Use Case Driven Approach, Addison-­ Wesley Professional, Wokingham 1996. Janko, W. H., Taudes, A., Dyduch, G.: Praktische Erfahrungen in der Bewertung von Büroautomationssystemen, in: Bartmann, D. (Hrsg.): Lösungsansätze der Wirtschaftsinformatik im Lichte der praktischen Bewährung, Springer, Berlin 1991, S. 147–165. Jeckle, M., Rupp, C., Hahn, J., Zengler, B., Queins, S.: UML 2 Glasklar Carl Hanser Verlag, München 2004. Jensen, M. C., Meckling, W. H.: Theory of the Firm – Managerial Behavior, Agency Costs and Ownership Structure, in: Journal of Financial Economics, (1976)3, S. 305–360.

494

Literaturverzeichnis

Jørgensen, K. A.: Product Modeling on Multiple Abstraction Levels, in: Blecker, T., Friedrich, G. (Hrsg.): Mass Customization – Challenges and Solutions, International Series in Operations Research & Management Science Vol. 87, Springer Berlin 2006, S. 63–84. Jung, R.: Architekturen zur Datenintegration – Gestaltungsempfehlungen auf der Basis fachkonzeptueller Anforderungen, Deutscher Universitätsverlag, Wiesbaden 2006, Kagermann, H., Wahlster, W., Helbig, J.: Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0 – Abschlussbericht des Arbeitskreises Industrie 4.0, Bundesministerium für Bildung und Forschung, Berlin 2013. Kahneman, D., Slovic, P., Tversky, A.: Judgment under uncertainty: Heuristics and biases, Cambridge University Press, Cambridge 1982. Kahneman, D., Tversky, A.: Prospect Theory – An Analysis of Decision under Risk, in: Econometrica, 47(1979), S. 263–291. Kalmring, D.: Performance Measurement von wissensintensiven Geschäftsprozessen, Deutscher Universitatsverlag, Wiesbaden 2004. Kaplan, R. S., Norton, D. P.: Balanced Scorecard, Schäffer-Poeschel, Stuttgart 1997. Kaplan, R., Norton, D. P.: Using the Balanced Scorecard as a Strategic Management System, in: Harvard Business Review, 74(1996)1, S. 75–85. Keen, P. G. W., Scott Morton, M. S.: Decision Support Systems – An Organizational Perspective, Addison-Wesley, Reading 1978. Keen, P. G. W.: Information Systems and Organizational Change, in: Communications of the ACM, 24(1981)9, S. 24–33. Keller, G., Meinhardt, S.: DV-gestützte Beratung bei der SAP-Softwareeinführung, in: HMD Praxis der Wirtschaftsinformatik, 31(1994)175, S. 74–88. Kemper, H.-G., Baars, H., Mehanna, W.: Business Intelligence – Grundlagen und praktische Anwendungen, 3. Auflage, Vieweg+Teubner, Wiesbaden 2010. Kettinger, W. J., Teng, J. T. C., Guha, S.: Business Process Change – A Study of Methodologies, Techniques, and Tools, MIS Quarterly, 21(1997)1, S. 55–98. Khan, R., Das, A.: Build Better Chatbots  – A complete Guide to Getting Started with Chatbots, Apress, New York 2018. Kirchner, L.: Eine Sprache für die Modellierung von IT-Landschaften: Anforderungen, Potenziale, zentrale Konzepte, in: Sinz, E., Plaha, M., Neckel, P. (Hrsg.): Modellierung betrieblicher Informationssysteme  – MobIS 2003, LNI P-38, Köllen Druck und Verlag, Bamberg 2003, S. 69–86. Kling, R., Iacono, S.: The Control of IS Development After Implementation, in: Communications of the ACM, 27(1984)12, S. 1218–1226. Knabke, T., Olbrich, S.: Grundlagen und Einsatzpotentiale von In-Memory-Datenbanken, in: Gluchowski, P., Chamoni, P. (Hrsg.): Analytische Informationssysteme, Springer Gabler, Berlin 2016, S. 187–203. Knolmayer, G.: Application Service Providing (ASP), in: Wirtschaftsinformatik, 42(2000)5, S. 443– 446. Knolmayer, G.: Computergestützte Produktionsplanung und -steuerung, in: Kurbel, K., Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik, Schäffer-Poeschel, Stuttgart 1990, S. 69–87. Kohlhammer, J., Proff, D., Wiener, A.: Visual Business Analytics – Effektiver Zugang zu Daten und Informationen, 2. Auflage, dpunkt, Heidelberg 2018. Körsgen, F.: SAP® ERP Arbeitsbuch – Grundkurs SAP© ERP ECC 6.0 mit Fallstudien, 4. Auflage, Erich Schmidt Verlag, Berlin 2015. Kraljic, A., Kraljic, T.: Agile Software Engineering Practices and ERP Implementation with Focus on SAP Activate Methodology, in: Zdravkovic, J., Grabis, J., Nurcan, S., Stirna, J. (Hrsg.): BIR 2018, LNBIP 330, 2018, S. 190–201.

Literaturverzeichnis

495

Krickel, F.: Digitalisierung in der Energiewirtschaft, in: Hecker, W., Lau, C., Müller, A. (Hrsg.): Zukunftsorientierte Unternehmenssteuerung in der Energiewirtschaft, Springer Gabler, Wiesbaden 2015, S. 41–74. Kuhlen, R.: Information – Informationswissenschaft, in: Kuhlen, R., Semar, W., Strauch, D. (Hrsg.): Grundlagen der praktischen Information und Dokumentation – Handbuch zur Einführung in die Informationswissenschaft und -praxis, 6. Auflage, De Gruyter, Berlin 2013, S. 1–24. Larman, C.: Applying UML and Patterns, Prentice Hall, Upper Saddle River 1998. Lenhard, R.: Erfolgsfaktoren von Mergers & Acquisitions in der europäischen Telekommunikationsindustrie, Gabler Verlag, Wiesbaden 2009. Lynch, C.: Big Data – How Do Your Data grow?, in: Nature, 455(2008), S. 28–29. Maassen, A., Schoenen, M., Frick, D., Gadatsch, A.: Grundkurs SAP R/3®, Lern- und Arbeitsbuch mit durchgehendem Fallbeispiel  – Konzepte, Vorgehensweisen und Zusammenhänge mit Geschäftsprozessen, 4. Auflage, Vieweg, Wiesbaden 2006. Maciaszek, L. A., Liong, B. L.: Practical Software Engineering – A Case Study Approach, Addison-­ Wesley Educational, Harlow 2004. Manyika, J. Chui, M., Brown, B., Bughin, J., Dobbs, R., Roxburgh, C., Byers, A.: Big Data – The Next Frontier for Innovation, Competition, and Productivity, McKinsey Global Institute, 2011. Markus, M. L., Robey, D.: Information Technology and Organizational Change –Causal Structure in Theory and Research, in: Management Science, 34(1988)5, S. 583–598. Marschak, J.: Towards an Economic Theory of Organization and Information, in: Thrall, R.  M., Coombs, C. H., Davis, R. L. (Hrsg.): Decision Processes, 2. Auflage, Wiley, New York/London 1957, S. 187–220. Matthes, F.: Softwarekartographie, in: Gronau, N. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik, Online-Lexikon, http://www.enzyklopaedie-der-wirtschaftsinformatik.de/lexikon/is-management/Systementwicklung/Softwarearchitektur/Architekturentwicklung/Software-Kartographie, 2015, abgerufen am 13.04.2016. Maymir-Ducharme, F., Angelelli, L. A.: Cognitive Analytics: A Step Towards Tacit Knowledge?, in: Journal of Systemics, Cybernetics and Informatics, 12(2014)4, S. 32–38. McGraw, G.: Software Security – Building Security, Addison-Wesley Professional, Boston 2006. McMenamin, S. M., Palmer, J. F.: Strukturierte Systemanalyse, Hanser Fachbuch, München 1988. Mell, P., Grance, T.: The NIST Definition of Cloud Computing, http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf, 2009, abgerufen am 13.04.2016. Melville, N., Kraemer, K., Gurbaxani, V.: Review: Information Technology and Organizational Performance – An Integrative Model of IT Business Value, in: MIS Quarterly, 28(2004)2, S. 283–322. Melzer, I.: Service-orientierte Architekturen mit Web Services – Konzepte-Standards-Praxis, 4. Auflage, Spektrum Akademischer Verlag, Heidelberg 2010. Merkle, R. C.: Protocols for Public Key Cryptosystems, in: Proceedings Symposium on Security and Privacy, IEEE Computer Society, 1980, S. 122–133. Mertens, P., Bodendorf, F., König, W., Picot, A., Schumann, M., Hess, T.: Grundzüge der Wirtschaftsinformatik, 11. Auflage, Springer, Berlin 2012. Merz, M.: Einsatzpotenziale der Blockchain im Energiehandel, in: Burgwinkel, D. (Hrsg.): Blockchain Technology – Einführung für Business- und IT Manager, De Gruyter, 2016, S. 51–98. Mohanty, S., Jagadeesh, M., Srivatsa, H.: Big Data Imperatives – Enterprise Big Data Warehouse, BI Implementations and Analytics, Apress, New York 2013. Moore, G.: Systems of Engagement and the Future of Enterprise IT: A Sea Change in Enterprise IT, https://info.aiim.org/systems-of-engagement-and-the-future-of-enterprise-it, 2011, abgerufen am 26.10.2018. Mucksch, H.: Das Data Warehouse als Datenbasis analytischer Informationssysteme, in: Chamoni, P., Gluchowski, P. (Hrsg.): Analytische Informationssysteme, 3. Auflage, Springer Gabler, Berlin 2006, S. 129–142.

496

Literaturverzeichnis

Müller-Stewens, G., Lechner, C.: Strategisches Management  – Wie strategische Initiativen zum Wandel führen, 4. Auflage, Schäffer-Poeschel, Stuttgart 2011. Myers, G. J.: Methodisches Testen von Programmen, De Gruyter Oldenbourg, München 1999. Nagel, K.: Nutzen der Informationsverarbeitung, 2. Auflage, Oldenbourg Wissenschaftsverlag, München 1990. Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. Naur, P., Randell, B. (Hrsg.): Software Engineering  – Report on a Conference, NATO Scientific Affairs Division, Brüssel 1969. Nelson, R.: IT Project Management – Infamous Failures, Classic Mistakes, and Best Practices, in: MIS Quarterly Executive, 6(2007)2, S. 67–77. Neubauer, N.: Semantik und Sentiment: Konzepte, Verfahren und Anwendungen von Text-Mining, Dissertation, Universität Osnabrück, 2014. Neumann, S., Probst, C., Wernsmann, C.: Kontinuierliches Prozessmanagement, in: Becker, J., Kugeler, M., Rosemann, M. (Hrsg.): Prozessmanagement. 7. Auflage, Springer, Berlin 2012. Newman, M., Barabási, A.-L., Watts, D. J.: The Structure and Dynamics of Networks, Princeton University Press, Princeton 2006. Nguyen, T. H.: Erweiterung des TUM Trouble Ticket Systems um IT Service Management Komponenten, TU München, Fakultät für Informatik, 2009. Nissen, V.: Stand und Perspektiven der informationsverarbeitungsbezogenen Beratung, in: HMD Praxis der Wirtschaftsinformatik, 50(2013)4, S. 23–32. Nomikos, M.: Zwischenbetriebliche Anwendungen, in: Biethahn, J., Nomikos, M. (Hrsg.): Ganzheitliches E-Business, De Gruyter, München 2002, S. 149–180. O’Reilly, T.: What is Web 2.0 – Design Patterns and Business Models for the Next Generation of Software, O’Reilly Network, http://oreilly.com/web2/archive/what-is-web-20.html, 2005, abgerufen am 13.04.2016. OECD: OECD-Grundsätze der Corporate Governance, Neufassung, http://www.oecd.org/dataoecd/57/19/32159487.pdf, 2004, abgerufen am 13.04.2016. OGC: Managing Successful Projects with PRINCE2 (Official PRINCE2 Publication) – The Stationery Office Books, 5. Auflage, Office of Government Commerce, Norwich 2005. Olbrich, A.: ITIL kompakt und verständlich, 3. Auflage, Vieweg+Teubner, Wiesbaden 2006. OMG: Object Management Group, Decision Model and Notation – Version 1.2. Object Management Group, 2018. OMG: Object Management Group, Unified Modeling Language Specification Version 2.5.1, https:// www.omg.org/spec/UML/About-UML/, 2017, abgerufen am 18.12.2018. OpenFog: OpenFog Reference Architecture for Fog Computing, (Technical Paper), https://www. openfogconsortium.org/resources/#white-papers, 2017, abgerufen am 18.09.2018. Oram, R.: Peer-to-Peer – Harnessing the Power of Disruptive Technologies, O’Reilly Media, Sebastopol 2001. Österle, H., Blessing, D.: Ansätze des Business Engineering, in: HMD Praxis der Wirtschaftsinformatik, 42(2005)241, S. 7–17. Österle, H., Brenner, W., Hilbers, K.: Unternehmensführung und Informationssystem, Vieweg+Teubner, Stuttgart 1992. Österle, H., Winter, R.: Business Engineering, in: Österle, H., Winter, R. (Hrsg.): Business Engineering – Auf dem Weg zum Unternehmen des Informationszeitalters, 2. Auflage, Springer, Berlin 2003, S. 3–19. Österle, H.: Business Engineering – Prozess- und Systementwicklung, in: Österle, H. (Hrsg.): Entwurfstechniken, Bd. 1, Springer, Berlin 1995. Osterwalder, A., Pigneur, Y.: Business Model Generation, Wiley, Hoboken (NJ) 2010.

Literaturverzeichnis

497

OWASP SAMM: Software Assurance Maturity Model – A guide to building security into software development (Version 1.5), https://www.owasp.org/images/6/6f/SAMM_Core_V1-5_FINAL. pdf, Abruf am 15.12.2018 OWASP: CLASP Concepts, https://www.owasp.org/index.php/CLASP_Concepts, 2006, abgerufen am 15.12.2018. Parker, M. M., Benson, R. J.: Information Economics, Prentice Hall, Englewood Cliffs 1988. Partsch, H.: Requirements-Engineering systematisch. 2. Auflage, Springer, Heidelberg 2010. Picot, A.: Organisation von Informationssystemen und Controlling, in: Controlling, (1990)6, S. 296–305. Plattner, H., Leukert, B.: The In-Memory-Revolution – How SAP HANA enables Business of the Future, Springer, Cham 2015. PMI: A Guide to the Project Management Body of Knowledge, 6. Auflage, Project Management Institute, Newtown Square 2017. Pohl, K.: Requirements Engineering: Fundamentals, Principles and Techniques, Springer, Berlin 2010. Porter, M. E., Millar, V. E.: How Information Gives You Competitive Advantage, in: Harvard Business Review, 63(1985)4, S. 149–160. Porter, M. E.: Competitive Advantage, Free Press, New York/London 1985. Porter, M. E.: Wettbewerbsvorteile – Spitzenleistungen erreichen und behaupten, 5. Auflage, Campus Verlag, Frankfurt/New York 1999. Porter, M.: Competitive Strategy  – Techniques for Analyzing Industries and Competitors, Free Press, New York 1980. Pressman, R.  S.: Software Engineering  – A Practitioner’s Approach, 5. Auflage, McGraw-Hill, New York 2001. Probst, G., Raub, S., Romhardt, K.: Wissen Managen  – Wie Unternehmen ihre wertvollste Ressource optimal nutzen, 7. Auflage, Gabler, Wiesbaden 2013. Pussep, A., Schief, M., Widjaja, T., Buxmann, P., Wolf, C.: The Software Value Chain as an Analytical Framework for the Software Industry and Its Exemplary Application for Vertical Inte­ gration Measurement, in: Proceedings American Conference on Information Systems (AMCIS), Detroit 2011. Recktenfelderbäumer, M., Arnold, C.: Value Creation durch ubiquitären E-Service – eine innovative Angebotsform aus Sicht der Leistungslehre. In: Fließ, S., Haase, M., Jacob, F., Ehret, M. (Hrsg.): Kundenintegration und Leistungslehre, Springer, Wiesbaden 2015, S. 87–111. Reichwald, R., Piller, F. T.: Interaktive Wertschöpfung – Open Innovation, Individualisierung und neue Formen der Arbeitsteilung, 2. Auflage, Gabler, Wiesbaden 2009. Reinhart, M.: Relationales Datenbankdesign, Vahlen, München 1995. Repschläger, J., Pannicke, D., Zarnekow, R.: Cloud Computing – Definitionen, Geschäftsmodelle und Entwicklungspotenziale, in: HMD Praxis der Wirtschaftsinformatik, 47(2010)5, S. 6–15. Rodríguez, A., Caro, A., Cappiello, C., Caballero, I.: A BPMN Extension for Including Data Quality Requirements in Business Process Modeling. In: Mendling, J., Weidlich, M. (Hrsg.): BPMN 2012, LNBIP Vol. 125, Springer, Heidelberg 2012, S. 116–125. Rohlfing, H.: SIMULA – Eine Einführung, Mannheim 1973. Ross, D. T.: Structured Analysis (SA) – A Language for Communicating Ideas, IEEE Transactions on Software Engineering, 3(1977)1, S. 16–34. Rothfuss, G., Ried, C.: Content Management mit XML, Springer, Berlin 2003. Rüegg-Stürm, J.: Das neue St. Galler Management-Modell, 2. Auflage, Haupt Verlag, Bern 2003. Rumbaugh, J.  Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.: Object-oriented Modeling and Design, Pearson, Englewood Cliffs 1991. Rummler, G. A., Brache, A. P.: Improving Performance, 2. Auflage, Jossey-Bass, San Francisco 1995.

498

Literaturverzeichnis

Rupp, C.: Requirements-Engineering und-Management: Professionelle, iterative Anforderungsanalyse für die Praxis, 6. Auflage, Hanser, München 2015. Russom, P.: Big Data Analytics, TDWI Best Practices Report, Fourth Quarter, 2011. SAP: What Is The Difference Between SAP HANA And A Traditional RDBMS, https://wiki.scn.sap. com/wiki/display/SAPHANA/What+Is+The+Difference+Between+SAP+HANA+And+A+Traditional+RDBMS, 2016, abgerufen am 10.01.2018 SAP: Ritter Sport – Logistics Application Controls Goods Receipt Based on Market Dynamics, SAP AG, Walldorf 2008. Sassone, P. G., Schwartz, A. P.: Cost-Justifying OA, in: Datamation, 32(1986)4, S. 83–88. Sauer, H.: Relationale Datenbanken – Theorie und Praxis, 4. Auflage, Addison-Wesley, Bonn 1998. Scaled Agile 2018: SAFe® 4.6 Introduction – Overview of the Scaled Agile Framework for Lean Enterprises, A Scaled Agile, Inc. White Paper, Boulder, CO, USA 2018. Scheer, A.-W.: Architektur integrierter Informationssysteme  – Grundlagen der Unternehmensmodellierung, 2. Auflage, Springer, Berlin 1992. Scheer, A.-W.: CIM Computer Integrated Manufacturing – Der computergesteuerte Industriebetrieb, 4. Auflage, Springer, Berlin 1990. Scheer, A.-W.: EDV-orientierte Betriebswirtschaftslehre – Grundlagen für ein effizientes Informationsmanagement, Springer, Berlin 1984. Scheer, A.-W.: Wirtschaftsinformatik – Referenzmodelle für industrielle Geschäftsprozesse, 7. Auflage, Springer, Berlin 1997. Schill, A., Springer, T.: Verteilte Systeme – Grundlagen und Basistechnologien, 2. Auflage, Springer, Berlin 2012. Schlagheck, B.: Objektorientierte Referenzmodelle für das Prozess- und Projektcontrolling, Grundlagen – Konstruktion – Anwendungsmöglichkeiten, Springer, Wiesbaden 2000. Schmalzried, D.: In-Memory-basierte Real-Time Supply Chain Planung, Gito, Berlin 2014. Schmitz, P.: Softwarequalität, in: Mertens, P. et  al. (Hrsg.), Lexikon der Wirtschaftsinformatik, Springer, Berlin 1990, S. 393–395. Schönthaler, F., Németh, T.: Software-Entwicklungswerkzeuge – Methodische Grundlagen, Teubner, Stuttgart 1990. Schöttner, J.: Produktdatenmanagement in der Fertigungsindustrie – Prinzip – Konzepte – Strategien, Fachbuchverlag Leipzig, 1999. Schüle, H.: E-Learning in Unternehmen, in: Pepels, W. (Hrsg.): E-Business-Anwendungen in der Betriebswirtschaft, NWB Verlag, Berlin 2002, S. 226–250. Schulz, M.: Technologischer Totalitarismus – Warum wir jetzt kämpfen müssen, in: FAZ, 06.02.2014. Schumann, C., Zschech, P., Hilbert, A.: Das aufstrebende Berufsbild des Data Scientist, in: HMD Praxis der Wirtschaftsinformatik, 53(2016)4, S. 453–466. Schumann, M.: Wirtschaftlichkeitsbeurteilung für IV-Systeme, in: Wirtschaftsinformatik, 35(1993)2, S. 167–178. Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung  – Konstruktion konfigurationsund anpassungsorientierter Modelle, Gabler, Wiesbaden 1998. Schwalbe, K.: Project Management, 4. Auflage, Thomson Course Technology, Boston 2006. Scott, J.: Social Network Analysis, 3. Auflage, Sage Pubn Inc, London 2012. Sempf, U.: Warum das Management der Wertschöpfungskette nicht an den eigenen Unternehmensgrenzen enden darf, in: Kompetenz – Diebold Management Journal, (1996)32, S. 4–13. Senge, P. M.: The Fifth Discipline – The Art and Practice of the Learning Organization, Random House Business, New York 1990. Shannon, C. E., Weaver, W.: The Mathematical Theory of Communication, University of Illinois Press, Urbana 1949.

Literaturverzeichnis

499

Siemens: Der durchgängige digitale Zwilling im Detail o. J. https://www.siemens.com/global/de/ home/unternehmen/themenfelder/zukunft-der-industrie/digital-enterprise.html, abgerufen am 06.08.2018. Silvia, P., Frye, R., Berg, B.: SAP HANA ® – Die neue Einführung, 3. Auflage, SAP PRESS, Bonn 2017. Simon, H. A.: Models of Man, Wiley, New York 1957. Sinz, E. J.: Unternehmensarchitekturen in der Praxis, in: Wirtschaftsinformatik, 46(2004)4, S. 315–316. Spiegel: 400 Millionen Verlust in 45 Minuten – Finanzfirma Knight kämpft ums Überleben, http:// www.spiegel.de/wirtschaft/unternehmen/wall-street-firma-knight-capital-kaempft-ums-ueberleben-a-848127.html, 2012, abgerufen am 13.04.2016. Spillner, A., Linz, T.: Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester; Foundation Level nach ISTQB-Standard, dpunkt, 2012. Stahlknecht, P., Hasenkamp, U.: Einführung in die Wirtschaftsinformatik, 11. Auflage, Springer, Berlin 2005. Statista: Anzahl der Internetnutzer in Deutschland in den Jahren 1997 bis 2018, Statista GmbH, 2018a. Statista: Anteil der Online-Käufer in Europa nach ausgewählten Ländern im Jahr 2017, Statista GmbH, 2018b. Steinmetz, R., Wehrle, K.: Peer-to-Peer-Networking & -Computing, Aktuelles Schlagwort, in: Informatik Spektrum, (2004)1 , S. 51–54. Strassmann, P.: The Squandered Computer  – Evaluating the Business Alignment of Information Technologies, Atlantic Books, New Canaan 1997. Strohmeier, S., Piazza, F., Majstorovic, D., Schreiner, J.: Smart HRM – Eine Delphi-Studie zur Zukunft der digitalen Personalarbeit („HRM 4.0“), in: Strohmeier, S. (Hrsg.), Saarbrücken 2016, http://www.gfos.com/fileadmin/user_upload/Studien/Abschlussbericht%20Smart%20HRM_final.pdf, 2016, abgerufen am 13.04.2016. Stull-Lane, P.: Analytics neu definiert: Die veränderte Bedeutung des beliebtesten BI-­Sammelbegriffs, Tableau, o. J. Supply-Chain Council Inc. (Hrsg): Supply Chain Operations Reference Model (SCOR), Version 11.0, http://docs.huihoo.com/scm/supply-chain-operations-reference-model-r11.0.pdf, 2012, abgerufen am 13.04.2016. Surowiecki, J.: The Wisdom of Crowds – Why the Many are Smarter Than the Few and how Collective Wisdom Shapes Business, Economics, and Nations, New York 2004. Süß, G., Eschlbeck, D.: Der Projektmanagement-Kompass, Vieweg, Braunschweig/Wiesbaden 2002. Sweeny, J., Korber, D.: Crash Course – Failure to Heed Early Warnings, Troubles of the Past contributed to Payroll System Collapse, Sacramento 2013. Teubner, R.  A.: Organisations- und Informationssystemgestaltung, Deutscher Universitätsverlag, Wiesbaden 1999. Thome, R., Schinzer, H., Hepp, M.: Electronic Commerce und Electronic Business  – Mehrwert durch Integration und Automation, 3. Auflage, Vahlen, München 2005. Toedtli, B.: Technische Kriterien bei der Auswahl und der Einführung von Standardsoftware, in: Österle, H. (Hrsg.): Integrierte Standardsoftware – Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 2, AIT Verlags GmbH, Hallbergmoos 1990, S. 125–140. Toutenburg, H., Knöfel, P.: Six Sigma – Methoden und Statistik für die Praxis, Springer, Berlin 2008. van der Aalst, W. M. P.: Process Mining, Springer, Berlin 2011. van der Aalst, W.M.P., Bichler, M., Heinzl, A.: Robotic Process Automation., in: Business Information Systems Engineering, 60(2018)4, S. 269–272. van Grembergen, W., van Bruggen, R.: Measuring and Improving Corporate Information Technology through the Balanced Scorecard, in: Electronic Journal of Information Systems Evaluation, 1(1998)1, Art. 3.

500

Literaturverzeichnis

vanden Broucke, S., Baesens, B.: Practical Web Scraping for Data Science  – Best Practices and Examples with Python, Apress, New York 2018. Venkatraman, N.: IT-enabled Business Transformation – From Automation to Business Scope Redefinition, in: Sloan Management Review, 35(1994)2, S. 73–87. V-Modell XT: Prozessmodell Dokumentation, http://www.kbst.bund.de/, 2004, abgerufen am 13.04.2016. vom Brocke, J.: Referenzmodellierung, Gestaltung und Verteilung von Konstruktionsprozessen, Logos, Berlin 2003. Wallmüller, E.: Risikomanagement für IT- und Software-Projekte, Hanser, München 2004. Wallmüller, E.: Software-Qualitätsmanagement in der Praxis, Hanser, München, Wien 2001. Ward, J.: Practical Data Analysis and Reporting with BIRT, Packt, Birmingham 2008. Wasserman, S., Faust, K.: Social Network Analysis – Methods and Applications, Cambridge University Press, Cambridge 1999. Weber, J., Schäffer, U.: Einführung in das Controlling, 13. Auflage, Schäffer-Poeschel, Stuttgart 2011. Weber, J., Schäffer, U.: Sicherstellung der Rationalität von Führung als Aufgabe des Controlling?, in: DBW, 59(1999)6, S. 731–747. Weill, P., Vitale, M. R.: Place to Space – Migration to eBusiness Models, Harvard Business School Press, Boston 2001. Weiner, N., Renner, T., Kett, H.: Geschäftsmodelle im Internet der Dienste  – Aktueller Stand in Forschung und Praxis, Fraunhofer, Stuttgart 2010. Weit e. V.: Das deutsche Referenzmodell für Systementwicklungsprojekte (Version: 2.2), http:// ftp.tu-clausthal.de/pub/institute/informatik/v-modell-xt/Releases/2.2/Dokumentation/V-Modell-XT-HTML/index.html, 2006, abgerufen am 15.12.2018. Wessling, E.: Individuum und Information, Mohr Siebeck, Tübingen 1991. Williamson, O. E.: Economic Organization: Firms, Markets and Policy Control, Harvester Wheatsheaf, Brighton 1986. Winter, R.: Business Engineering Navigator  – Gestaltung und Analyse von Geschäftslösungen „Business-­to-IT“, Springer, Berlin 2011. Winter, R., Aier, S.: Informationssystem-Architektur, in: Kurbel, K., Becker, J., Gronau, N., Sinz, E., Suhl, L. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik  – Online Lexikon, http://www. enzyklopaedie-der-wirtschaftsinformatik.de/lexikon/daten-wissen/Informationsmanagement/Information-/Informationssystem-Architektur/index.html, abgerufen am 14.01.2019. Wiseman, C.: Strategic Information Systems, Richard d Irwin, Homewood 1988. Wittenburg, A: Softwarekartographie: Modelle und Methoden zur systematischen Visualisierung von Anwendungslandschaften, Diss. TU München, München 2007. WKWI/GI: Rahmenempfehlung für die Ausbildung in Wirtschaftsinformatik an Hochschulen, https://gi.de/service/publikationen/empfehlungen, 2017, abgerufen am 25.10.2018. Wölfle, R., Schubert, P. (Hrsg.): Dauerhafter Erfolg mit Business Software, Hanser, München 2009. Yourdon, E.: Death March – The Complete Software Developer’s Guide to Surviving „Mission Impossible“ Projects, Prentice Hall, New Jersey 1997. Yourdon, E.: Modern Structured Analysis, Prentice Hall, Englewood Cliffs 1989. Zachman, J. A.: John Zachman’s Concise Definition of The Zachman Framework™, http://www. zachman.com/about-the-zachman-framework, 2008, abgerufen am 13.04.2016. Zangemeister, C.: Nutzwertanalyse in der Systemtechnik, 4. Auflage, Wittemannsche Buchhandlung, München 1976. Zobel, J.: Mobile Business und M-Commerce – Die Märkte der Zukunft erobern, Hanser, München 2001.

Stichwortverzeichnis

A ABAP (Advanced Business Application Sofware) 449 Ablage 434 Ablauf -modell 157 -organisation  19, 135, 157 -planung 156 - und Terminplanung  385 Abschreibung 234 ADAPT (Application Design for Analytical Processing Technologies)  288 Agenturkosten 93 Aggregation 409 Aktivitätsdiagramm  163, 186, 412 Algorithmus 433 genetischer 36–37 Alternativen -auswahl 10 -generierung 10 ALU (Arithmetic Logic Unit)  479 Analyse Anforderungs- 357 anwendungsfallgesteuerte 407 deskriptive 273 Kosten-Nutzen- 61 Nutzwert- 64 objektorientierte 407 prediktive 273 preskriptive 273 Sentiment- 302 strukturierte 403 Text- 302

Anforderung  259, 359 Erfassung von  363 -sanalyse  354, 357 -smanagement 362 Anlagenbuchhaltung  205, 217 ANSI (American National Standards Institute) 469 Anwendung  26, 127, 173 sektorneutrale 200 sektorspezifische 241 -sfalldiagramm 185 -sgenerator 369 -slandschaft 176 -slogik 175 -sschnittstelle 174 -ssoftware  25, 173, 433 -ssystem 25 strategische 127 überbetriebliche 324 zur Entscheidungsunterstützung  269 Apache Hadoop 305 Spark 305 App 434 Applet 480 Application Programming Interface  434 Service Providing  96 Arbeiten, kooperatives  30 Arbeitsplatzrechner 435 Architektur 134 Client-Server- 175 Geschäfts- 146

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 P. Alpar et al., Anwendungsorientierte Wirtschaftsinformatik, https://doi.org/10.1007/978-3-658-25581-7

501

502 integrierter Informationssysteme (ARIS)  135, 161 -management 176 -modell  129, 134 offene 435 Unternehmens- 178 Archivierung  265, 434 -ssystem 281 Artefakt Ergebnis- 128–129 Artikelklassifikation 337 ASCII (American Standard Code for Information Intercharge)  437 Assoziation 410 -sklasse 414 Aufbauorganisation  19, 135, 151, 167 Auftrags -freigabe 243 -überwachung 244 Aufwandsschätzung 388 Augmented Reality  111 Auktion 338 Available to Promise (ATP)  333 Avatar 114 B Backoffice 250 Balanced Scorecard  59, 148, 331 Balkendiagramm 391 Barcodeleser 469 Basel  II 86 BASIC (Beginners All Purpose Symbolic Instruction Code)  462 Basissoftware 25 Benutzer End- 27 -freundlichkeit 401 -oberfläche  419, 435 -schnittstelle 175 Berichts -schablone 282 -system 282 Bestandsdaten 218 Betriebsarten 436 Offlinebetrieb 436 Onlinebetrieb 436 Time Sharing  471

Stichwortverzeichnis Betriebsphase 355 Betriebssystem  261, 436 Systemprogramme 436 Bewegungsdaten 218 Bewertung von IS  61 Data Envelopment Analysis  63–64 Hedonistisches Verfahren  63 I+F-Verfahren 63 Konsumentenrente  63, 66 Kostenfunktion 63 Nutzeffektketten 63–64 Time-Saving Time-Salary  63 Beziehungstyp 191 BIC (Bank Identifier Code)  216 Big Data  298 Mining 301 BIRT (Business Intelligence and Reporting Tools) 282 Bit 437 Blackbox  16, 66 -Test 424 Blockchain  91, 258 Blog 116 Blogroll 116 Bluetooth 437 Bottom-up -Gestaltung 131 -Vorgehen 350 BPEL (Business Process Execution Language) 437 Branchenstruktur 53 BS 7799 89 15000 85 BSI 469 BSS (Business Support System)  255 Buchhaltung Anlagen-  205, 217 Debitoren- und Kreditoren-  215 Finanz- 200 Haupt-  204, 220 Kontokorrent- 204 Kreditoren- 229 Lager- 204 Lohn- und Personal-  205 Neben- 204 Buchungskreis 207 Build to Order  332, 338

Stichwortverzeichnis Bullwhip-Effekt 332 Bundesamt für Sicherheit in der Informationstechnik (BSI)  87 Bundesdatenschutzgesetz (BDSG)  86, 331 Business Activity Monitoring  169 Analytics 273 Collaboration 325 Engineering  131, 134 Intelligence  34, 277 -IT-Alignment 174 Model Canvas  145 Networking 325 Process as a Service  97 Process Execution Language (BPEL)  437 Process Model and Notation (BPMN)  158, 161 Process Outsourcing  95 Process Redesign (BPR)  130, 137, 260, 340, 426 Rules Management  165 -to-Business (B2B)  103, 336 -to-Consumer (B2C)  103, 336, 343, 479, 481 BYOD (Bring Your Own Device)  438 Byte 437 C C++ 463 Cache Memory  438 CASE 348 Lower 439 Upper 438 CEPT (Conference Européenne des Administrations des Postes et des Télécommunications) 468 CGI 481 Change Management  46 Chief Information Officer  78 Chiffrierverfahren 473 CLASP (Comprehensive, Lightweight Application Security Process) 377 Client-Server-Architektur  175, 439 Cloud Community 97 Computing  96, 305 Hybrid 97

503 Private 97 Public 97 COBIT 68 Cobots 121 Cockpit 333 COCOMO (Constructive Cost Model)  391 Co-Creation 145 Codierung 421 Cognitive Analytics  274 Community Cloud  97 Compiler 440 Compliance 70 Computer Aided Design (CAD)  244 Aided Manufacturing (CAM)  244 Aided Planning (CAP)  244 Aided Software Engineering (CASE)  348, 420 Based Training  108 Integrated Manufacturing (CIM)  241 Constraint-Programmierung 273 Content  298, 328 Management  267, 439 Continuous Process Improvement (CPI)  132, 137, 169 Controllingsystem 200 Convolutional Neural Networks, CNN  37 Core Data Warehouse  280 Corporate Governance 67 Planner 310 Cosourcing 95 CouchDB 459 CpD (Conto-pro-Diverse)  216 CPU (Central Processing Unit)  440 Crowdsourcing 112 CSCW (Computer Supported Cooperative Work) 238 Customer Intimacy 144 Journey 142 Customer Relationship Management (CRM)  106, 202, 255, 267, 327 analytisches 329 kooperatives 329 operatives 328 Social 330 Customizing  206, 263 Cyber-Physical Systems  119

504 D Data Cleansing 38 Dictionary 421 Lake 305 Mart 280 Warehouse  278, 281, 328 Data Mining  38, 40, 329 Abweichungsanalyse 38 Analyse ähnlicher Zeitabfolgen  39 Assoziationsanalyse 38 Entscheidungsbaum 38 Klassifikation 38 Reihenfolgeanalyse 39 Warenkorbanalyse 38 Datei 441 -system 442 Daten 7 -attribut 190 Bestands- 218 Bewegungs- 218 -definitionssprache 445 -integration 277 -konsolidierung 284 -manipulationssprache 446 Meta- 281 -modell  281, 333, 446 -modellierung  276, 288 -objekt  159, 190 Sachkontenstamm- 214 -schicht 175 -schutz  89, 331 -sicherheit 401 -sicherung 447 -sicht  135, 161 Stamm- 206 -strom  304, 308 -visualisierung 301 Datenbank 175 Data Dictionary  446 Datenschutz 445 -entwurf 444 hierarchische 446 In-Memory- 301 -managementsystem  57, 443 objektorientierte 460 relationale 464 -server 446 -system 443 verteilte 476

Stichwortverzeichnis Datenmodellierung  217, 288 konzeptionelle  406, 409 multidimensionale 288 semantische 351 Datenübertragung asynchrone 447 synchrone 447 Datenverarbeitung elektronische 27 entscheidungsorientierte 276 DAX (Data Analysis Expressions)  296 Debitoren- und Kreditorenbuchhaltung  215 Debugger 421 Decision Automation 272 Model and Notation (DMN)  165 Support Systems (DSS)  34, 200 Decision-Requirements-Diagramm 165 Deep Learning  36 Defects per Million Opportunities (DPMO)  169 Delivery Pipeline  376 Deployment 375 Descriptive Analytics  273 DES (Data Encryption Standard)  474 Design Thinking  132 DevOps 375 DFD (Datenflussdiagramm)  203 Diagramm Aktivitäts-  163, 186, 412 Anwendungsfall-  185, 407 Balken- 391 Datenfluss- 203 Decision-Requirements- 165 Entity-Relationship-  217, 351 Funktionsdekompositions- 203 Gantt- 391 Häufigkeits- 321 Interaktions- 413 Interaktionsübersichts- 187 Ishikawa (Fishbone)-  171 Klassen-  183, 374, 409, 414 Kommunikations- 185 Komponenten- 188 Objekt- 184 Paket- 184 Profil- 190 Prozesskontext- 154 Sequenz-  162, 185, 413 SIPOC- 170 Struktur- 182

Stichwortverzeichnis Timing- 185 Use-Case-  163, 185 Verhaltens- 182 Verteilungs- 189 Dicing 285 Digitalisierung  5, 101 Dimensionalität Multi- 127 Dimensionstabelle 288 DIN (Deutsches Institut für Normung)  468 Disintermediation 342 Document Store  301 Dokument 434 Dokumentation  355, 401 Domain Name Service (DNS)  447 Down-Flow 281 Downsizing  96, 447 Downstream  143, 153 Drill Down  285, 313 Druck, dreidimensionale  448 DSGVO (Datenschutz-Grundverordnung)  89 Dual Core Processor  458 Durchlaufzeit 164 Dynamic Host Configuration Protocol (DHCP) 448 E E -Business  103, 325, 335, 479 -Fulfillment  254, 338 -Government  103, 336 -Learning 107 -Logistik  106, 107, 338 -Marketing 105 -Payment  331, 338 -Procurement  336, 339 -Production 106 -Shop  104, 339, 481 e3Value 146 EAN (European Article Number)  469 Ebay 336 EBCDIC (Extended Binary Decimal Interchange Code)  437 Ebene Informationssystem- 173 Organisations- 151 Strategie-  134, 139 Echtzeit (Realtime)  299, 325, 334, 341, 437 ECMA (European Computer Manufactures Association) 468

505 Edge Computing  99 Editor 421 EEX (European Energy Exchange)  256 Efficient Consumer Response (ECR)  332 Eiffel 463 Einsatzmittelbedarfsplanung  385, 388 Electronic Business (E-Business)  102 Commerce (E-Commerce)  298, 327, 335 Data Interchange (EDI)  101 Elementtyp 190 Encryption Card  467 Endbenutzer 27 Energiewirtschaft 255 Engineering Business  131, 134 Computer Aided Systems  348 Methoden 129 Requirements 357 Reverse 427 Software 348 Systems 347 Enterprise Application Integration (EAI)  175 Architecture  134, 178 Architecture Management (EAM)  178 Data Warehouse  281 Resource Planning (ERP)  32, 197, 337 Service 179 Service Bus  179 Entität (Entity)  190 Entitätstyp 190 Entity-Relationship-Modell (ERModell)  190, 211, 212, 288, 427 Entropiefunktion 8 Entscheider risikofreudiger 12 risikoneutraler 12 risikoscheuer 12 Entscheidungsdimension 12 Entscheidungsregel 165 Entscheidungsunterstützungssystem (EUS)  34, 235, 269 Entwurf Benutzeroberfläche 419 Grob- 354 konzeptioneller 348 -muster 415 objektorientierter 413 EPROM (Erasable Programmable Read Only Memory) 451

506 Ereignis 159 Ereignisgesteuerte Prozesskette (EPK)  159, 161 Erfolgsfaktor, kritischer  140, 148, 167 Ergebnis -artefakt 128–129 -orientierung 128 Erlösquelle 146 ERP-Einführung 259 ERP-System  32, 197, 328, 333, 337 ETL (Extraktion, Transformation, Laden)  280, 301 eTOM 252 ETSI (European Telecommunication Standardization Institute)  468 Exception Reporting  282 Executive Information System (EIS)  33, 245 Support System (ESS)  34 Expected Value of Perfect Information  316 Expertensystem 35 Extreme Programming (XP)  371 F Fahrplananmeldung 257 Failure Mode and Effects Analysis (FMEA) 171 Faktentabelle 287 Feature Driven Development (FDD)  374 Feinentwurf 354 Fidor Bank  52 File Transfer Protokoll (FTP)  450, 453 Finanzbuchhaltung (FIBU)  200, 202 Fintech (Financial Technology)  144, 247 Firewall 449 Flexible Planung  315 Fog Computing  99 Formalisierung 128 FORTRAN 462 Free Software Foundation  266 Fremdbezug von IS-Leistungen  93 Fremdschlüssel 444 Frontoffice 250 Führungsgröße  136, 140, 148 operative 135 Prozess- 167 strategische 134 Führungsprozess  152, 269 Fünf-Kräfte-Modell 146 Function Point Analysis  391

Stichwortverzeichnis Funktion 159 -sschicht 175 -ssicht  135, 161 G Gantt-Diagramm 391 Gateway-Rechner 465 Gebrauchsfähigkeit unmittelbare 401 zukünftige 401 General Data Protection Regulation (GDPR) 89 Generalisierung  192, 409 Geoinformationssystem (GIS)  257 Geschäfts -architektur  146, 342 -bereich 208 -modell  341, 342 -prozess  130, 239, 252, 304, 426 Geschäftsmodell  140, 142, 144 -entwicklung 132 Geschäftsnetzwerkmodell  140, 146 Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) 86 Gestaltung Bottom-up- 131 -ebene 133 Top-down- 139 Glasfaserkabel 456 GLN (Global Location Number)  216 Grid Computing  450 Grobentwurf 354 Group Decision Support System (GDSS)  35 Groupware 450 GTIN (Global Trade Item Number)  246, 469 GuV-Konten 228 GWG (Gerinwertige Wirtschaftsgüter)  235 H Handelsbilanz 228 Handels-H-Modell 245 Hardware 451 -system 25 Hauptbuchhaltung  204, 220 Hauptspeicher 451 Head-up Display (HUD)  111 HTML (Hypertext Markup Language)  451

Stichwortverzeichnis HTTP (Hypertext Transfer Protocol)  484 Hub-and-Spoke-Architektur 281 Hybrid Cloud  97 Hypertextdokument 484

I IBAN (International Bank Account Number) 216 IBM ILOG  273 IEC (International Electrotechnical Commission) 469 IEEE (Institute of Electrical and Electronics Engineers) 469 IFRS 204 IMG (Implementation Guide)  206 Implementierung 10 Individualsoftware 31 Industrie  4.0 120 In-Flow 280 Information 6 Aggregationsgrad 9 Center 78 -saktualität 8 -sattribut 21 -sbedarf 272 -sbedürfnis 21 -seffekt 341 -sgenauigkeit 9 -skorrektheit 9 -skosten 9 -sobjekt  159, 278 -spräsentation 9 -swert  8, 12 -swert (normativ)  13 -swert (objektiv)  12 -swert (subjektiv)  12 Informationsmanagement 47 instrumentelle Sicht  48 konzeptionelle Sicht  48 Informationssystem (IS)  25 -Controlling 56 -ebene  135, 173 Entstehung 26 Geo- 257 global vernetztes  452 integriertes 452 lokal vernetztes  452 Management- 33 zentrales 453

507 Infrastructure as a Service (IaaS)  97 Inkrement 366 In-Memory-Datenbank 301 Insourcing 95 Integration  128, 218, 244, 323, 350, 354 -sschicht 175 -stest 424 Integrator 145 Integrität 401 -sregel 444 Intelligenz kollektive 112 künstliche  35, 36, 463 Interaktionsdiagramm 413–415 Interaktionsübersichtsdiagramm 187 Internet  324, 341, 453 der Dinge (Internet of Things)  103, 119, 341 -Protokoll (IP)  471 Interoperabilität 453 Interpreter 453 Intranet  449, 453 Ishikawa (Fishbone)-Diagramm  171 ISO (International Standards Organization)  468 20000 85 ISP (Internet Service Provider)  455 IT -Abteilung 75 als Enabler  45 -Konzept 354 -Prozess 69 IT-Controlling 51 Berichtswesen 58 Budgetierung 59 Kennzahlen 57 Leistungs- und Kostenrechnung  58 strategisches 51 Iteration 366 ITIL  80, 381 Availability Management  82 Capacity Management  82 Change Management  83 Configuration Management  83 Financial Management  82 Incident 84 Problem Management  84 Release Management  83 Service Level Management  82 ITU (International Telecommunication Union) 468

508 J Jahresabschluss 228 Java 463 Database Connector (JDBC)  480 JTC (Joint Technical Committee)  1 469 Just in Time  332

K KANBAN 373 Kapselung 406 Kardinalität 192 Katalogaustauschstandard 338 Kennzahl  130, 134, 135, 140, 148 Kernbankensystem 250 Kernversicherungssystem 250 KI (Künstliche Intelligenz)  35 Klartext 473 Klasse 405 Klassendiagramm  183, 409, 414 Klassifikation Text- 302 KLR (Kosten- und Leistungsrechnung)  202 Knowledge Worker  19 Kommunikation  7, 380 -sdiagramm 185 -seffekt 341 -skanal  145, 329 -sserver 457 Komponenten -architektur 417 -diagramm 188 Komposition 410 Konfigurationsmanagement 402 Konfigurator 338 Konfigurierung 263 Konnektor 159 Konsolidierungspfad 284 Konten -planverzeichnis 213 -rahmen 211 Kontierungsmuster 227 Kontokorrentbuchhaltung 204 Kontrolle 10 Kontrollfluss 159 Konzept Data Warehouse-  278 Sukzessivplanungs- 241 Koordinationsform 336

Stichwortverzeichnis Kosten Agentur- 93 -artenrechnung 236 -Nutzen-Analyse 61 -planung 385 Prozess- 164 -stellenrechnung 237 -struktur 146 -trägerrechnung 238 Transaktions-  94, 147 Kredit -kontrollbereich 208 -management 231 Kreditorenbuchhaltung 229 Kryptogramm 473 Kryptologie 473 Künstliche Intelligenz (KI)  35, 36, 463 Künstliches Neuronales Netz (KNN)  36 Kunden -bedürfnis 140 -beziehung 145 -perspektive 140 -prozess 152 -prozessmodell 140 -prozessvision 132 -segment 145 -sicht 169 -wert 141 L Lagerbuchhaltung 204 LAMP 484 LAN (Local Area Network)  455 Legacy System  255 Leistungs -bestandteil 155 -bündel 141 -bündelung 143 -fluss  134, 154 -merkmal 155 -prozess 152 -sicht  135, 161 -übergang 147 -verzeichnis 155 Leitung, verdrillte  456 Lenkungsausschuss 383 Lernen, maschinelles  36 Lichtwellenleiter 456

Stichwortverzeichnis Life Cycle Costing  312 LINUX 267 LISP (List Processing)  463 Location Based Service  109, 331 Lösung, optimale  11 Lohn- und Personalbuchhaltung  205 Long Short-Term Memory (LSTM)  37 Long Tail  112 Lower CASE  439 M Machine Learning  36 Machine-to-Machine 119 Mahn -bereich 208 -wesen 231 Management Change 46 Content  267, 439 -ebene 19 Informations- 47 -modell St. Galler  133 Produktdaten- 244 Risiko- 68 Sicherheit- 86 Wissens- 48 Managementebene 19 operative 19 strategische 19 taktische 19 Managementinformationssystem (MIS)  33 Mandant 206 Marketing 328 Markt elektronischer  103, 147, 336, 343 -leistung 238 Mash-up 118 Maskengenerator 420 Massive Open Online Course  108 Master-Detail-Verknüpfung 419 Matchcodesuche 220 Mehrprogrammbetrieb 458 Mehrprozessorarchitektur 458 Meilensteinplanung  385, 388 Memory Card  467 Mengenplanung 243 Metadaten 281 Metamodell 129

509 Methode  129, 349, 351, 377, 405, 409 analytische  313, 363 Aufwandsschätzung 390 Bewertungs- 218 Entwurfs- 414 Projektmanagement- 381 Systemimplementierungs- 420 Test- 424 Verschlüsselungs- 474 Methoden Engineering  129 Microsoft Azure  297 Middleware 175 Migration 427 Minimum Viable Product  377 MIPS 441 Mirroring 446 Mobile BI 290 Business (M-Business)  102, 109 Modell Ablauf- 157 analoges 17 Architektur-  129, 134 Daten-  281, 333, 446 deskriptives 17 dynamisches  18, 182 3-Ebenen- 444 Entity-Relationship- 190 Geschäfts-  140, 142, 144 Geschäftsnetzwerk-  140, 146 Handels-H- 245 Kundenprozess- 140 mathematisches 17 Meta- 129 normatives 17 Phasen- 351 physisches 17 Prozess-  135, 156, 157 Referenz-  197, 245 semi-formales 128 -Sicht 133 Simultanplanungs- 241 statisches  18, 182 St. Galler Management-  133 3V- 299 V- 366 V-97- 366 Vorgehens-  129, 170, 351 V-XT- 366

510 Wasserfall- 353 Workflow- 157 Y- 241 Modellierung Daten- 217 multidimensionale 288 -sansatz 129 -smethodik 129 -ssprache 158 Monatsabschluss 229 MongoDB 459 Monte-Carlo-Simulation 318 Move-to-the-Market 343 MS Power BI  296 Multi Channel Management  329 Cloud Computing  97 -core Processor  458 -dimensionalität 128 -kanal  329, 339, 342 Tasking 458 MVC-Muster 417 N Nachforderungsmanagement  360, 380, 399 Nachricht 7 Named-Entity Recognition, NER  41 Natural Language Processing, NLP  40 Navigierbarkeit 415 Nearshoring 96 Nebenbuchhaltung 204 Neo4j 459 neoHermes 366 Netz -plan 391 -typ 459 -zugangsprotokoll 459 Netz, lokales  456 Betriebsmittelverbund 456 Datenverbund 456 Kommunikationsverbund 457 Lastverbund 457 Ringstruktur 457 Sternstruktur 457 Topologie 459 Netzwerk  142, 145 -effekt  111, 343 soziales 113–114 Wertschöpfungs-  134, 142

Stichwortverzeichnis Norm  401, 468 NoSQL  300, 459 Nutzen 342 -funktion 318 Nutzwertanalyse  64, 261 O Object Code 461 Management Group (OMG)  404 Objekt 405 Daten-  159, 190 -diagramm 184 Informations-  159, 278 Offshoring 96 OMG (Object Management Group)  404 Online Analytical Processing (OLAP)  278, 283, 329 Transaction Processing (OLTP)  32, 276 Open Innovation  108 Open Source  266, 329 Open Source Software (OSS)  266, 282, 329 Schwächen 268 Stärken 267 OPL (Optimization Programming Language) 273 Orchestrator  143, 144, 147 Organigramm 167 Organisation Ablauf-  19, 135, 157, 483 Aufbau-  19, 135, 151, 167 der IS-Abteilung  77 flache 20 -sebene  20, 63, 134, 151 -seinheit  51, 58, 70, 78, 130, 135, 151, 157, 159, 167, 176, 206, 280, 431 -sgestaltung 132 -ssicht  135, 161 -sziel  140, 148, 167 Organizational Decision Support System (ODSS) 35 Out-Flow 281 Outsourcing  93, 324 P Paketdiagramm 184 Parametrisierung  206, 216, 263, 321

Stichwortverzeichnis Pattern 415 PC (Personal Computer)  435 Peer-to-Peer Computing  460 Personalfunktion 107 Personality Insights  274 Perspektive Inside-Out-  140, 152 Outside-In-  140, 152 Pfad, kritischer  164, 391 Pferd, trojanisches  472 Pflichtenheft 365 Phasenmodell 365 inkrementelles 366 iteratives 366 leichtgewichtiges  368, 371, 373, 374 lineares 365 schwergewichtiges 368 zyklisches 366 Pionier 144 Plan-Ist-Vergleich 393 Planoptimierung  386, 393 Planung  309, 315 Ablauf- 156 flexible 315 Kosten- 385 Makro-  156, 170 Mengen- 243 Mikro- 156–157 Produktionsprogramm- 242 Risikomanagement- 386 Termin- und Kapazitäts-  243 Platform as a Service (PaaS)  97 Plattenspiegelung 446 PMBOK (Project Management Book of Knowledge) 381 Point-of-Sale-System 246 POP (Point of Presence)  455 Portabilität  401, 460 Portal  105, 331 Positionierung, strategische  139 PowerPlay 287 PPS-System 241 Präsentationsschicht 175 Predictive Analytics  273 Prescriptive Analytics  273 Primärschlüssel  191, 444 PRINCE2 381 Private Cloud  97

511 Problem 11 -erkennung 10 -lösen 9 semistrukturiertes 11 unstrukturiertes 11 wohlstrukturiertes 11 Process Mining 164 Performance Management  134 Processor Card  467 Product Lifecycle Management (PLM)  202 Produktdatenmanagement (PDM)  244 Produktionsprogrammplanung 242 Profildiagramm 190 Programmiersprache  369, 461 C 462 höhere 461 Klassifikation 462 Maschinensprachen 457 nicht prozedurale  462 objektorientierte 463 Semantik 463 Syntax 463 Projekt 379 -abschluss 394 Charakteristika 379 -definitionsphase 353 -durchführung 393 Erfahrungssicherung 393 -kontrolle  380, 393 -leiter 384 -management 369 -mitarbeiter 384 -organisation 383 -phase 382 -planung  380, 385 -risiko 396 -start 384 -strukturierung 385–386 -strukturplan (PSP)  386 PROM (Programmable Read Only Memory)  451 Prototyp 369 Prototyping 368 experimentelles 370 exploratives 370 Prozess 135 -abgrenzung 154 Alarmierungs- 169

512 -effekt 342 -effektivität 135 -effizienz 135 -führung  130, 134, 135, 167, 339 operative 167 strategische  140, 147 Führungs-  152, 269 -führungsgröße 167 Geschäfts-  130, 239, 252, 426 -gestaltung 134 IT- 69 -kontextdiagramm 154 -kosten 164 Kunden- 152 -landkarte  153, 156 Leistungs- 152 -management 71 -modell  135, 156, 157 -orientierung 325 -sicht 161 -simulation  164, 167 Unterstützungs- 152 -verbesserung 169 -zerlegung 161 -ziel 148 Prozessmodell für Kunden-  140 Prozessverbesserung kontinuierliche  132, 137, 169 Public Cloud  97 Q Qualitätsprofil 155 Quellcode 461 R Radio Frequency Identification (RFID)  298, 325, 464 RAM (Random Access Memory)  451 Rational Unified Process (RUP)  407 RDBMS (Relationales Datenbankmanagementsystem) 280 Realzeitverarbeitung 437. Siehe auch Echtzeit (Realtime) Rechnerarchitektur ALU 479 Bus 479 CPU 479 Hauptspeicher 479 Rechenwerk (ALU)  440

Stichwortverzeichnis Steuerwerk 440 Zentralprozessor (CPU)  479 Rechnernetz 463 Recurrent Neural Networks (RNN)  36 Reengineering-Software 427 Referenzmodell  197, 245, 454 Reifegradmodell  355, 379 Reinforcement Learning, RL  37 Relationshiptyp 191 Releasefähigkeit 263 Report 282 -generator 448 Reporting Engine  282 Repository 438 Requirements Engineering  357 Ressource 145 Reverse Engineering  427 Revisionsfähigkeit 401 Rightsizing 96 Risiko 395 -analyse 397 -bewertung 397 -bewertungsmatrix 398 -Chancen-Analyse 318 -handhabung 398 -identifikation 396 -klasse 397 -meidung 398 -minderung 398 -teilung 399 -überwachung 399 -überwälzung 399 Risikomanagement  68, 378, 395 Aufgaben 396 -planung 386 Robotic Process Automation (RPA)  102, 166 Rolle  129, 167 Roll Up  285 ROM (Read Only Memory)  451 Router 465 RSA 475 RSS  116, 118 S SABRE 52 Sachkontenstammdaten 214 SAP Activate 264 ERP 200 HANA  201, 307

Stichwortverzeichnis Sarbanes-Oxley-Gesetz 86 SCADA (Supervisory Control and Data Acquisition) 257 Schadenkostenüberwälzung 399 Schätzklausur 390 Schema externes 445 internes 444 konzeptionelles 444 Schicht Daten- 175 Funktions- 175 Integrations- 175 Präsentations- 175 Schichtenspezialist 144 Schlüssel 473 -kennzahl 57 Primär- 191 Schnittstellenbenutzer- 175 Scrum 371 Search Engine Marketing  106 Engine Optimization (SEO)  106 Secure Development Lifecycle (SDL)  378 Digital Card (SD Card)  467 Sekundärbedarf 243 Self Service BI  295 Sentiment Analysis  302, 330 SEO (Search Engine Optimization)  470 Sequenzdiagramm  162, 185, 413 Servervirtualisierung 465 Service 81 -anbieter 181 Bus 179 fachlicher (Enterprise)  179 -integrator 343 -konsument 181 Lifecycle Management  181 Science 181 SOA-  176, 179, 180 technischer 179 -verzeichnis (Service Repository/ Registry) 180 Serviceorientierte Architektur (SOA)  176, 179, 202, 466 SGML (Standard Generalized Markup Language) 451 Sicherheitsmanagement 86

513 Sicht Daten- 161 Funktions- 161 Leistungs- 161 Makro-  156, 170, 176 Mikro-  156, 157, 176 Organisations- 161 Prozess- 161 Steuerungs- 161 Simple Object Access Protocol (SOAP)  181, 466 Simple Mail Transfer Protocol (SMTP)  465 SIMULA 404 Simulationsprozess 164 Simultanplanungsmodell 241 Single Sign-on 239 Source Authoring  293 Tasking 448 SIPOC-Diagramm 170 Six-Sigma 169 Slicing 285 SMALLTALK  404, 463 Smart -card 467 Contract 258 Meter 257 -phone 465 Product 325 -sourcing 96 Social Bookmarking 118 Community 112 CRM 330 Media  298, 329 Network 113–114 Network Analysis (SNA)  330 (Networking) Software  112 News 119 Software  26, 433, 466 -altlasten 426 Anwendungs-  25, 173 Basis- 25 Engineering 348 -entwicklung agile  368, 371 Individual- 31 -lebenszyklus 351 -produktionsumgebung 438

514 proprietäre 267 Reengineering 427 -roboter 166 as a Service  97, 329 Standard-  31, 132, 200, 267, 282, 293, 326 Softwareentwicklung objektorientierte 404 Softwareentwicklung, agile  368, 371 Soll-Ist-Vergleich 394 Solvency  II 86 Sourcing Co- 95 Crowd- 112 In- 95 Out-  93, 324 Smart- 96 Speichermaßzahl 466 Speichermedium, externes  466 Speicherung, virtuelle  477 Spezialist Schichten- 144 SPICE 356 Sprache, 4GL 438, 448 Spracherkennungssoftware 467 Sprint 372 SRM (Supplier Relationship Management)  202 Stakeholder 140 Stammdaten 206 -pflege 229 Standard  401, 468 Standardisierungsgremium 468 Standardsoftware  31, 132, 200, 267, 282, 293, 326, 348, 351, 369 Customizing 263 Einführung 369 STEP (Standard for the Exchange of Product Model Data)  244 Sternschema  287, 296 Steuerung -sicht  135, 161 St. Galler Managementmodell  133 Storage Area Network (SAN)  467 Strategic Alignment  53, 68 Strategieebene  134, 139 Strategisches Informationssystem (SIS)  51 Streaming Analytics  304 Structured Query Language (SQL)  267, 468

Stichwortverzeichnis Struktur -diagramm 182 -effekt 342 Suchmaschinen 469 -optimierung 470 Sukzessivplanungskonzept 241 Sunk Cost Bias  272 Supply Chain -Ausführung 333 Cockpit 333 Event Management  334 -Konfiguration 333 Management  107, 332 Operations Reference Model (SCOR)  198, 332 -Planung 333 Swapping 478 System  15, 26 abstraktes 16 adaptives 16 Anwendungs- 25 Berichts- 282 Betriebs- 261 Controlling- 200 deterministisches 16 Entscheidungsunterstützungs-  34, 235 -entwicklung objektorientierte 407 ERP- 197 EUS- 269 Experten- 35 Geoinformations- 257 Informations- 25 interorganisationales 31 Kernbanken- 250 konkretes 16 künstliches 16 natürliches 16 nicht-adaptives 16 Point-of-Sale- 246 PPS- 241 rückgekoppeltes 16 SAP- 201 stochastisches 16 -test 354 Warenwirtschafts- 245 -wartung 426 Workflow- 261

Stichwortverzeichnis Systems of Engagement  43 Engineering 347 of Insight  33, 269 of Record  32 System Security Engineering Capability Maturity Model (SSE-CMM)  379

T Tablet 470 Tag  115, 118 Tagesabschluss 229 Tailoring 368 TCO (Total-Cost-of-Ownership)  262 TCP/IP 453 Telekommunikationsdienstleister 252 Termin- und Kapazitätsplanung  243 Test -automatisierung 424 Blackbox- 424 Integrations- 424 -methode 424 -planung 423 -spezifikation 423 -strategie 422 System- 354 Whitebox- 424 Testen 422 Text -analyse 302 -klassifikation 302 -segmentierung 302 Time Sharing  458, 471 Timingdiagramm 185 TMF (TeleManagement Forum)  252 Top-down  312, 350 -Gestaltung  131, 132, 139 -Vorgehen 350 Total Cost of Ownership  61 Touchpoints 378 Touchscreen 472 Trackbacks 116 Tracking&Tracing  333, 338 Transaction Processing System (TPS)  32 Transaktions -konzept 472 -kosten  94, 147, 324, 342 -kostentheorie 335

515 Transceiver 465 Transformation 132 kundenorientierte 140 Transport Communication Protocol (TCP)  471 Transportprotokoll 472 verbindungsloses 472 verbindungsorientiertes 472 Triple Play  252 Typ Beziehungs- (Relationship-)  191 Element- 190 Entitäts- 190 U Übertragungsnetzbetreiber 257 Unified Modeling Language (UML)  182, 404 Service Description Language (USDL)  181 Uniform Ressource Identifier (URI)  473 Locator (URL)  473 Name (URN)  473 Universal Description Discovery Integration (UDDI) 181 UNIX 266 Unternehmen -sarchitektur 178 -smodellierung 178 -snetzwerk 145 -sperspektive 140 -sziel  140, 148, 167 virtuelles 21 Unternehmensarchitektur (Enterprise Architecture) 134 Unterstützungsprozess 152 Up-Flow 280 Upper CASE  438 Upstream  143, 153 USB-Stick 467 Use-Case-Diagramm  163, 185 US GAAP  204 V Validation 355 Value Proposition  145 Vanguard Studio  315 Vendor Managed Inventory  332 Verarbeitung natürlicher Sprache  40

516 Vererbung  404, 406, 409 Vergleich, Soll-Ist-  393–394 Verhaltensdiagramm 182 Verifikation 355 Vernetzungsbereich 327 Vernetzung, überbetriebliche  323 Verschlüsselungsverfahren asymmetrisches 474 symmetrisches 474 Verteilungsdiagramm 189 Viren -scanner 476 -schutzsoftware 476 Vision 132 Visual 297 Analytics 42 Data Mining  301 V-Modell 366 97 366 XT 366 VOFI (Vollständiger Finanzplan)  67, 262 Von-Neumann -Architektur 478 -Rechner 458 Vorgehen Bottom-up- 350 -modell  129, 170, 351 Top-down- 350 Vorstudie 354 VPN (Virtuelles privates Netz)  454 W WAN (Wide Area Network)  455 Warenwirtschaftssystem 245 Wartung 355 -sfreundlichkeit 401 von Systemen  426 Wasserfallmodell 365 Wearables 111 Web -browser 452 -log 116 Log Mining  106 Scraping 276 Service  181, 481 Service Description Language (WSDL)  181, 484

Stichwortverzeichnis Webanwendung clientseitige Programme  479 dynamische 479 serverseitige Programme  480 Werkzeug 129 Wertschöpfungs -aktivität, primäre  107 -kette  54, 146 -netzwerk  134, 142 Whitebox-Test 424 WiBe-Kalkulator 262 Wiederverwendung  347, 401, 404, 406, 409 Wiki 117 Wirtschaftlichkeit  354, 401 Wirtschaftsinformatik 3–4 Wisdom of Crowds  112 Wissens 6 -entdeckung 38 -entdeckung in Datenbanken (KDD)  36 -karten 50 -management 48 -management-Baustein 49 Work Breakdown Structure (WBS)  386 Workflow  157, 334 -modell 157 -System  261, 483 World Wide Web (WWW)  293 -Dienste 484 -Server 484 World Wide Web Consortium (W3C)  479 Würmer 484

X XML (Extensible Markup Language)  484 XP (Extreme Programming)  371

Y Y-Modell 241

Z Zachman Framework  135 Zustandsautomat 189 Zwilling, digitaler  121