Abstract
I. Abbildungsverzeichnis
II. Tabellenverzeichnis
III. Abkürzungsverzeichnis
1 Einleitung und Problemstellung
1.1 Ausgangssituation
1.2 Problemstellung
1.3 Zielsetzung
1.4 Vorgehen
2 Grundlagen
2.1 Modellierung im Kontext der Erfolgsmessung von Informationssystemen
2.1.1 Evaluation von Informationssystemen
2.1.2 Der „Modell-Begriff“
2.1.3 Die Grundsätze ordnungsgemäßer Modellierung und das Vorgehensmodell zur Erstellung betrieblicher Informationsmodelle
2.1.4 Definition Referenzmodellierung
2.1.5 Konstruktion von Referenzmodellen
2.1.6 Bekannte Modelle zur Erfolgsmessung von Informationssystemen
2.2 Enterprise 2.0: Social Software im Unternehmenskontext
2.2.1 Das Web 2.0
2.2.2 Social Software
2.2.3 Definition Enterprise 2.0: Social Software im Unternehmenskontext
2.2.4 Allgemeine Einsatzbereiche von Enterprise Social Software
2.3 Agiles Projektmanagement
2.3.1 Der Begriff „Agilität“
2.3.2 Das agile Manifest und agile Vorgehensmodelle
2.3.3 Scrum
3 Von Dimensionen, Erfolgsfaktoren & Barrieren
3.1 Referenzmodell-Basis: Anwendungstauglichkeit des D&M IS Success Models und IS Impact Success Models
3.1.1 Synergien und Konflikte ausgewählter Erfolgsmodelle
3.1.2 Erfolgsfaktoren von Informationssystemen
3.1.3 Prüfung auf Praxisrelevanz
3.1.4 Fazit
3.2 Neue Herausforderungen: Die Nutzungspotentiale von Enterprise Social Software
3.2.1 Nutzung und Potentiale von Enterprise Social Software im Unternehmen
3.2.2 Erfolgsfaktoren von Enterprise Social Software
3.2.3 Enterprise Social Software: Barrieren bei der Erfolgsmessung
3.2.4 Fazit
3.3 Enterprise Social Software trifft auf die Werte und Prinzipien des agilen Projektmanagements
3.3.1 Die agilen Werte
3.3.2 Dimensionen und Erfolgsfaktoren eines agilen Projektes
3.3.3 Nutzung und Potentiale von Enterprise Social Software in einem agilen Projekt
3.3.4 Fazit
4 Konzeption & Konstruktion des Referenzmodells
4.1 Konstruktion des Ordnungsrahmens
4.2 Modellierung der Struktur - A Priori Referenzmodell
4.2.1 Konzeption des Modells: Dimensions- & Erfolgsfaktorenbeschreibung
4.2.2 Konstruktion des Modells
5 Modellanwendung anhand eines exemplarischen Fallbeispiels
6 Fazit & Ausblick
7 Literaturverzeichnis
Anlage A: Tabelle mit Erfolgsfaktoren
Anlage B: Fragebogen zum IS Impact Measurement Model
Anlage C: Fragebogen zur Erfolgsmessung von Enterprise Social Software in einem agilen Projekt
Mit der vorliegenden Masterthesis wird das Ziel verfolgt, ein Referenzmodell zur Erfolgsmessung von Enterprise Social Software in einem agilen Projekt zu entwickeln. Dabei werden Erkenntnisse aus Forschungsbeiträgen aufgegriffen, die sich kritisch mit dem Thema Erfolgsmessung von Informationssystemen auseinandergesetzt haben. Anhand einer schrittweisen und spezifisch werdenden Vorgehensweise, wird die theoretische Grundlage für die Konzeption und Konstruktion eines Modells geschaffen. Bei der Modellerstellung werden etablierte Grundsätze und Konstruktionstechniken berücksichtigt. Die Besonderheit stellt die Einarbeitung des agilen Projektkontextes dar. Abschließend wird eine Modellanwendung anhand eines exemplarischen Fallbeispiels vorgenommen.
Keywords: Enterprise Social Software, Referenzmodell, Erfolgsmessung, Agiles Projekt
Abbildung 1: Konstruktionstechniken von Referenzmodellen
Abbildung 2: Konstruktionstechniken im Kostenvergleich
Abbildung 3: Altes Modell nach DeLone & McLean aus dem Jahr 1992
Abbildung 4: Das aktualisierte D&M IS Success Model
Abbildung 5: The IS-Impact Measurement Model
Abbildung 6: Zusammenhänge im Web 2.0
Abbildung 7: Das Social Software Dreieck
Abbildung 8: Einsatzbereiche von Enterprise 2.0 in Unternehmen (2010)
Abbildung 9: Konzeptuelles Model des IS-Impact Measurement Modell
Abbildung 10: IS-Impact Measurement Model (A Priori model) – Erfolgsfaktoren
Abbildung 11: 2. Reduzierung der Erfolgsfaktoren
Abbildung 12: Modell zur Enterprise Social Software Erfolgsmessung
Abbildung 13: Barrieren im Enterprise Social Software-Lebenszyklus
Abbildung 14: Empirische Validierung zur Einflussnahme des Agilitätsgrades auf den Projekterfolg
Abbildung 15: Matrix für die Potentiale in Bezug zu den agilen Prinzipien
Abbildung 16: Ordnungsrahmen
Abbildung 17: A Priori Enterprise Social Software Erfolgsmodell in einem agilen Projekt
Abbildung 18: Erfolgsfaktor Agilitätsgrad mit reduzierter Anzahl agiler Werte
Abbildung 19: Erfolgsmodell einer Enterprise Social Software Lösung in einem agilen Projekt
Tabelle 1: Bewertung agiler Methoden
Tabelle 2: Erfolgsfaktoren E-Commerce: DeLone & McLean IS Success Modell - Teil 1 (Übersetzt)
Tabelle 3: Erfolgsfaktoren E-Commerce: DeLone & McLean IS Success Modell - Teil 2 (Übersetzt)
Tabelle 4: Dimensionen des Applicability Check
Tabelle 5: Schwerpunkte der derzeitigen IS-Erfolgsmessung
Tabelle 6: Tauglichkeit der Dimensionen des IS-Erfolgsmodells von DeLone & McLean
Tabelle 7: Nutzungspotentiale von Enterprise Social Software
Tabelle 8: Dimensionen 1-3: Zusammenfassung der Erfolgsfaktoren für Social-Software-Systeme
Tabelle 9: Dimensionen 4-6: Zusammenfassung der Erfolgsfaktoren für Social-Software-Systeme
Tabelle 10: Neu identifizierte Erfolgsfaktoren
Tabelle 11: Barrieren der Enterprise Social Software Erfolgsmessung
Tabelle 12: Die Dimension Systemqualität mit den Erfolgsfaktoren unter Berücksichtigung des agilen Kontextes
Tabelle 13: Die Dimension Informationsqualität mit den Erfolgsfaktoren unter Berücksichtigung des agilen Kontextes
Tabelle 14: Die Dimension Enterprise 2.0 Readiness mit den Erfolgsfaktoren unter Berücksichtigung des agilen Kontextes
Tabelle 15: Die Dimension Individueller Einfluss mit den Erfolgsfaktoren unter Berücksichtigung des agilen Kontextes
Tabelle 16: Die Dimension Projekt Einfluss mit den Erfolgsfaktoren unter Berücksichtigung des agilen Kontextes
Abbildung in dieser Leseprobe nicht enthalten
In einem Projekt im Automotive-Bereich wird eine komplexe Software nach dem agilen Vorgehensmodell Scrum entwickelt. Die Software setzt sich aus zwei Modulen zusammen, die auf eine gemeinsame Datenbasis zugreifen. Bei einem Modul handelt es sich um eine Web-Applikation, bei dem anderen um eine Desktop-Applikation. Die Software bietet die Möglichkeit, Daten und deren Metadaten über Fahrzeugteile zu bearbeiten und zu verwalten, die in einem 3D-System zur visuellen Aufbereitung genutzt werden.
Die Rollen innerhalb des Scrum-Prozesses sind folgendermaßen vergeben: Es gibt einen Scrum-Master, der auch als Vorgesetzter des Entwicklungsteams fungiert und es gibt einen führenden Product Owner, der seitens des Auftraggebers eingesetzt wurde. Dieser wird aufgrund der Komplexität der Software von einer weiteren Person unterstützt.
Für das Anforderungs-, Quellcode- und Releasemanagement sowie dem Kommunikationsaustausch der internen und externen Stakeholder werden im Rahmen von Enterprise 2.0 verschiedene E-Collaboration-Tools zur Verfügung gestellt. Enterprise 2.0 beschreibt die Nutzung von Enterprise Social Software, die zum Beispiel die Zusammenarbeit von Entwicklern und Auftraggeber vereinfachen soll. Diese Software besteht aus mehreren Anwendungen, die auf einer Website innerhalb einer Plattform zugänglich gemacht wurden. Es handelt sich dabei um die folgenden lizenzpflichtigen Tools von Atlassian: Confluence, JIRA, Bitbucket und Bamboo. JIRA ist zuständig für das Anforderungs- und das Aufgabenmanagement, Confluence für das Wissens- beziehungsweise Informationsmanagement, Bitbucket für das Quellcodemanagement und Bamboo für das Releasemanagement und gegebenenfalls für Testautomatisierungen. Bis auf JIRA wurden die verschiedenen Tools nicht seit Beginn des Projektes eingesetzt. Sie wurden entweder im Projektverlauf neu eingeführt oder haben andere Anwendungen ersetzt.
Im Laufe des Projektes gab es einen Wandel in der Art und Weise, wie der Scrum-Prozess gelebt wurde. Aufgrund einer nicht allzu strengen Auslegung wurden viele Regeln des Vorgehensmodells von den externen und internen Stakeholdern nicht konsequent eingehalten. Mit dem Ziel, die Entwicklung der Software, das Informations- und Wissensmanagement zu verbessern, wurden einschlägige Änderungen in der Ausübung des Scrum-Prozesses vorgenommen. Die veränderte Umsetzung und Durchführung des agilen Projektmanagements hatte auch Auswirkungen auf den Umgang mit der zur Verfügung gestellten Enterprise Social Software zur Folge.
Es wird die These aufgestellt, dass die neue Prozessgestaltung und besonders die damit einhergehende Veränderung bezüglich der Nutzung der E-Collaboration-Tools unter Auflagen einen positiven Einfluss auf den Projektverlauf genommen haben. Diese Auswirkung kann zu besseren Ergebnissen in der Software-Entwicklung geführt haben. Daher wird besonders Wert auf die Betrachtung der eingesetzten E-Collaboration-Tools im Rahmen von Enterprise 2.0 gelegt. Obwohl die Nutzung derartiger Software zur Prozessunterstützung in vielen Bereichen eines Unternehmens bereits zum alltäglichen Gebrauch gehört, lassen sich ihre Auswirkungen auf die Zielgrößen eines Projektes nur schwer nachvollziehen. Es wird daher ein Werkzeug zur Erfolgsmessung benötigt, um die möglichen Einflüsse abbilden zu können. In der Forschung haben sich einige Modelle etabliert, die zur Ermittlung einer Wertschöpfung mittels Informationssysteme eingesetzt werden. Diese werden auch weiterhin diskutiert und weiterentwickelt. In der Praxis hingegen lassen sie sich nur schwer einsetzen[1]. Im Rahmen verschiedener Forschungsarbeiten wurden deshalb etablierte Modelle für den organisationalen Unternehmenskontext angepasst oder erweitert. Ob sich diese für eine Anwendung auf konkrete Projekte eignen, ist dagegen aufgrund fehlender Untersuchungen unklar. Die überwiegend projektgetriebene und zunehmend unter agilen Vorgehensmodellen stattfindende Softwareentwicklung verfügt demnach über kein standardisiertes Modell, anhand dessen der Nutzen durch die E-Collaboration-Tools messbar gemacht werden kann.
Aufgrund eines fehlenden Standards wird im Rahmen dieser Arbeit ein Referenzmodell zur Erfolgsmessung von Enterprise Social Software in einem agilen Projekt entwickelt.
Grundlage bildet die Bestimmung von Erfolgsfaktoren beziehungsweise Metriken unter Berücksichtigung des agilen Kontextes, anhand derer eine Messung durchgeführt werden kann. Mit Hilfe dieses Modells wird die Möglichkeit bestehen, eine Erfolgsmessung an einem konkreten agilen Projekt durchzuführen. Dies soll an einem Fallbeispiel inklusive eines Fragebogens erörtert werden.
Zunächst werden im zweiten Kapitel die fundamentalen Grundlagen behandelt. Diese sind in drei Teile untergliedert: Der Einstieg beginnt mit „Modelle zur Erfolgsmessung von Informationssystemen“. Hier wird eine kurze Einordnung in den wissenschaftlichen Kontext vorgenommen, eine Definition des „Modell-Begriffs“ durchgeführt und anschließend verschiedene Konstruktionsmöglichkeiten von Referenzmodellen erörtert. Abschließend werden ausgewählte und etablierte Modelle zur Erfolgsmessung beschrieben.
Im zweiten Teil der Grundlagen werden die notwendigen Begriffsdefinitionen von Enterprise 2.0: Social Software erfasst. Außerdem gibt es eine Übersicht über deren Einsatzbereiche in der Praxis.
Die Grundlagen des dritten Teils enthalten die Informationen zum agilen Projektmanagement. Es wird mit einer Definition des Begriffs „Agilität“ begonnen und das agile Manifest wiedergegeben. Ferner gibt es eine kurze Auflistung verschiedener agiler Vorgehensmodelle. Mit einer detaillierten Beschreibung von Scrum wird dieser Teil abgeschlossen.
Im dritten Kapitel Von Dimensionen, Erfolgsfaktoren & Barrieren wird in drei Stufen die Basis für das spätere Modell ermittelt. Zunächst werden in Kapitel 3.1 die aus den Grundlagen beschriebenen Modelle auf ihre konkrete Anwendungstauglichkeit im Rahmen der Arbeit untersucht. Da nicht alle Inhalte neu erschlossen werden müssen, wird untersucht, auf welche bereits etablierten Erkenntnisse zurückgegriffen werden kann. Dazu werden Konflikte und Synergien aus den beschriebenen Modellen gefiltert. Des Weiteren werden eine Reihe von Erfolgsfaktoren und Barrieren zur Erfolgsmessung anhand von kritischer Forschungsliteratur zu diesem Thema identifiziert und zur weiteren Untersuchung aufgelistet. Abschließend erfolgt ein Fazit zur Tauglichkeit in der Praxis.
Das nächste Unterkapitel Neue Herausforderungen: Die Nutzungspotentiale von Enterprise Social Software beginnt mit der Beschreibung des Nutzens und Potentials von Enterprise Social Software. Kern dieses Kapitels ist die Ermittlung von Erfolgsfaktoren und Barrieren in Bezug auf die Enterprise Social Software anhand einer Literaturstudie. Zum Abschluss folgt ein Fazit, in dem ihre Eignung für das künftige Modell unter anderem unter Berücksichtigung der Erkenntnisse aus dem vorherigen Kapitel herausgestellt wird.
Im letzten Schritt des dritten Kapitels Enterprise Social Software trifft auf die Werte und Prinzipien des agilen Projektmanagements werden zu Beginn die Werte und Prinzipien des agilen Projektmanagements aus der Literatur herausgearbeitet. Auch dort werden potentielle Erfolgsfaktoren erörtert. Diese sind entscheidend für die Modellentwicklung, da sie das Alleinstellungmerkmal zur Erfolgsmessung in einem agilen Projekt darstellen. Dazu werden die Nutzungspotentiale von Enterprise Social Software mit den agilen Prinzipien anhand einer Matrix in Verbindung gebracht. Wie in den vorherigen Unterkapiteln, wird hier mit einem Fazit abgeschlossen.
Im 4. Kapitel Konzeption & Konstruktion des Referenzmodells folgt die Konzeption des Referenzmodells. Hier werden die Ergebnisse aus den vorherigen Kapiteln zusammengeführt. Aus dieser Konsolidierung wird ein neues Referenzmodell hervorgehen. Dieses Modell wird im Anschluss als Grundlage für die Erfolgsmessung von Enterprise Social Software in einem agilen Projekt dienen.
Nach der Modellierung erfolgt im 5. Kapitel die Modellanwendung anhand eines exemplarischen Fallbeispiels. Das Fallbeispiel leitet sich aus der Ausgangssituation ab. Bei der Modellanwendung werden die Erkenntnisse aus dem drittel Kapitel mit einbezogen.
Das letzte Kapitel enthält eine kritische Betrachtung des erstellten Modells. Mögliche neue oder nicht überwundene Barrieren werden erläutert und Errungenschaften herausgearbeitet. Die Erörterung des Modells mündet in einem Ausblick.
In diesem Kapitel werden die Grundlagen zur Thematik Modellierung erörtert. Es wird eine Einordnung in den wissenschaftlichen Kontext vorgenommen und darauf eingegangen, welche Forschungsrelevanz sie hat. Daraufhin wird der grundsätzliche Modell-Begriff erläutert. Im Anschluss wird dargestellt, welche Konstruktionsmöglichkeiten zur Auswahl stehen und nach welchen Grundsätzen ein Referenzmodell entwickelt werden kann. Abschließend gibt es eine Übersicht über bekannte Modelle in der Forschung, die in dieser Arbeit als Orientierung dienen und aus denen weiterführende Erkenntnisse gewonnen werden.
In der Literatur erschließen sich zahlreiche Quellen zum Thema Erfolgsmessung von Informationssystemen. Die Fragen, warum und wie Informationssysteme gemessen werden sollten, beschäftigen seit vielen Jahren die Unternehmen und Wissenschaftler.
Viele Beiträge zu diesen Fragestellungen behandeln die Entwicklung oder Überprüfung von Modellen. Gerade in der Wirtschaftsinformatik genießt die Modellierung von Beziehungen und Prozessen mittels grafischer Abbildungen, die auf einer systematischen Notation beruhen, einen hohen Stellenwert. Erfahrungsgemäß werden die aktuellen Geschäftsprozesse und sozialen Beziehungen in einem Unternehmen zu einem Zeitpunkt aufgenommen und dokumentiert, wenn die Modellierung sehr praxisorientiert durchgeführt wird. Beispielhaft ist dies bei der Anforderungsanalyse in den Gebieten der Prozessoptimierung, des E-Governments und des Wissensmanagements.[2]
Um die nachfolgende Definition der Referenzmodellierung besser nachvollziehen zu können, wird zunächst der allgemeine Modellbegriff erläutert. Dies ist von Bedeutung, da er einerseits in der Wirtschaftsinformatik viel diskutiert, neben den aufgefundenen Implikationen für die Referenzmodellierung und die Perspektive auf die Gestaltung von Konstruktionsprozessen jedoch vernachlässigt wurde.[3]
Aus der Literatur geht hervor, dass der Informationsmodellbegriff auf verschiedene Arten definiert wird. Dabei sind drei erwähnenswerte Betrachtungsweisen aufzufinden:[4]
1. Modell als Abbildung:
In diesem Fall wird angenommen, dass vom Modell ein direkter Bezug zum Original besteht. Das heißt Modelle sind Darstellungen der objektiven Realität.[5] Dies geht auch aus folgendem Zitat hervor:
„Charakteristisch für diesen Modellbegriff ist es, dass die Realität objektiv existiert und wahrgenommen sowie in einem Modell objektiv abgebildet werden kann.“ [6]
In diesem Kontext übernimmt der Modellierer einzig und allein eine passiv-rezeptive Rolle.[7]
2. Modell als zweckrelevante Abbildung:
Eine Definition zu dieser Betrachtungsweise lautet wie folgt:
„Ein Modell wird verstanden als eine subjekt- und zweckgebundene Rekonstruktion eines Ausschnittes aus der Realität.“ [8]
In diesem Fall entscheidet sich der Modellierer bewusst für den Modellierungszweck, den Rahmen des Modellobjektes und die Sprachen zur Repräsentation des Modellobjektes, was dazu führt, dass von einem Modellobjekt verschiedene Modelldarstellungen bestehen können. Trotzdem nimmt dieser eine passiv-rezeptive Rolle ein.[9]
3. Modell als Konstruktion:
In diesem Zusammenhang ist der Konstruktivismus durch einen Relativismus charakterisiert. Subjektive mentale Konstruktionen aus verschiedenen Realitäten bestehen nebeneinander. Der Modellierer schließt die seiner Meinung nach unwichtigen Charakteristika aus und markiert die relevanten Merkmale.[10] Bei der Modellerstellung nimmt er dementsprechend eine aktive Rolle ein. Dabei ist der Theorie- und Kenntnisstand des Erstellers maßgeblich entscheidend für die Konzeption. Die Beschreibung wird zusätzlich mit dem folgenden Zitat erörtert:
„Modelle werden aktiv durch den Modellersteller konstruiert. Das reine Modellabbild tritt in den Hintergrund. Vielmehr besteht bereits bei der Auswahl und Abgrenzung des Realitätsausschnittes eine subjekt- und zweckbezogene Abgrenzung.“ [11]
Das Modell wird in diesem Fall als ein Tripel aufgefasst, dass aus Modellobjekt, -abbild und -kontext besteht.[12]
Den methodischen Ordnungsrahmen für die Modellierung eines betrieblichen Informationsmodells im Rahmen dieser Arbeit bilden die entworfenen „Grundsätze ordnungsgemäßer Modellierung (GOM)“ und ihre Implementierung in ein Vorgehensmodell. Darin sind sechs nachfolgend näher erörterte Grundsätze beschrieben, die ein Modell erfüllen sollte. Das erwähnte Vorgehensmodell besteht aus fünf aufeinanderfolgenden Phasen, die im Anschluss der Grundsätze detailliert erläutert werden. Zusammengenommen sind die Grundsätze und das Vorgehensmodell als Richtlinie beziehungsweise Handlungsempfehlung zu sehen: Sie geben dem Modellierer einen gewissen Interpretationsspielraum bei der Erstellung einer Abbildung.[13]
Die Grundsätze ordnungsgemäßer Modellierung nach Becker lauten:
1. Grundsatz der Richtigkeit:
Dieser Grundsatz verlangt, dass die Abbildung der Realwelt in einem Modell mit derjenigen grundsätzlich übereinstimmt. Außerdem wird er in die semantische sowie syntaktische Richtigkeit geteilt. Bei der semantischen Richtigkeit muss eine Überprüfung eines Modells hinsichtlich der Operationalisierbarkeit auf bestimmte Maßnahmen stattfinden. Exemplarisch werden die Definition und der Gebrauch von Namenskonventionen oder die Verwendung von strukturanalogen Modellen genannt. Die Bestätigung der syntaktischen Richtigkeit kann mit Hilfe einer Konsistenzprüfung gegen ein Metamodell realisiert werden.[14]
2. Grundsatz der Relevanz:
In diesem Grundsatz wird herausgestellt, dass der Fokus eines Modells auf die Wiedergabe der notwendigen Sachverhalte gelegt wird. Die Relevanz eines Sachverhalts ergibt sich dabei aus dem Modellierungszweck und gibt den Detaillierungsgrad eines Modells vor.[15]
3. Grundsatz der Wirtschaftlichkeit:
Hierbei handelt es sich um ein theoretisches Konstrukt, das nicht leicht zu handhaben ist. Der ökonomische Grundsatz gibt wieder, wann der bestmögliche Detaillierungsgrad eines Modells erstellt wurde. Um eine Untersuchung zu vereinfachen, müssen Ersatzziele definiert werden. Es wird beispielsweise gefragt, wie gut die Persistenz des Realweltausschnittes ist. Das heißt, welches Maß an Einfluss haben Veränderungen einer detaillierten Stufe auf übergeordnete weniger detaillierte Stufen.[16]
4. Grundsatz der Klarheit:
Mit diesem Grundsatz wird sichergestellt, dass ein Modell leserlich, verständlich und anschaulich ist. Es wird darauf bestanden, die Komplexität eines Modells auf das Notwendigste zu beschränken und es möglichst einfach zu halten. Die Maxime lautet: So detailliert wie nötig, so klar wie möglich.[17]
5. Grundsatz der Vergleichbarkeit:
Hiermit wird das Ziel verfolgt, eine Vergleichbarkeit von Modellen zu gewährleisten, die mit unterschiedlichen Modellierungsverfahren erstellt wurden. Das sind zum Beispiel Modelle, die in verschiedenen Projekten mit unterschiedlichen Werkzeugen erzeugt wurden. Mit Hilfe von Beziehungsmetamodellen können diese ineinander überführt werden. Grundsätzlich sollten innerhalb eines Unternehmens nur wenige Modellierungstechniken verwendet werden, um Konflikte zu vermeiden.[18]
6. Grundsatz des systematischen Aufbaus:
Anhand dieses Grundsatzes wird eine sichtenübergreifende Konsistenz sichergestellt. Sichten sind zum Beispiel Organisationssicht, Datensicht und Funktionssicht. Wenn sich zum Beispiel in einem Funktionsmodell Referenzierungen auf Daten wiederfinden, müssen diese Daten auch in einem Datenmodell modelliert sein.[19]
Das Vorgehensmodell nach Becker ist in fünf Phasen aufgeteilt:
1. Zieldefinition:
Mit der Zieldefinition wird der Modellierungszweck bestimmt. Dieser Schritt ist notwendig, da ein Informationsmodell verschiedenen Zwecken dienen kann und der Detaillierungsgrad eine wichtige Rolle spielt. Beispielhafte Nutzungsabsichten sind die Erstellung von Benchmarking, Softwareeinführungen, Simulationen oder Geschäftsprozessoptimierungen.[20]
2. Konstruktion des Ordnungsrahmens:
Der Ordnungsrahmen nimmt die Einbettung eines Informationsmodells in eine komplexe Umgebung vor. Dadurch bleibt ein Modell verständlich und kann klarer in einen Kontext eingeordnet werden. Viele Informationsmodellprojekte werden nicht erfolgreich abgeschlossen, da ihnen eine entsprechende Eingliederung in einen geordneten Ordnungsrahmen fehlt.[21]
3. Modellierung der Struktur:
In dieser Phase wird die Struktur, die im zweiten Schritt erzeugt wurde, mit Inhalt gefüllt. Zu beachten sind beispielsweise etablierte Namenskonventionen oder die Verwendung von Modellbausteinen, die vorher in Strukturanalogien gebildet wurden. Hierbei ist die Zieldefinition ständig zu berücksichtigen, um nur die tatsächlich relevanten Sachverhalte abzubilden.[22]
4. Konsolidierung und Komplettierung:
Hier werden Nacharbeiten nach einer Konsolidierung von Modellen aus dem Ordnungsrahmen durchgeführt. Gerade bei komplexen Gebilden ist dies eine wichtige Aufgabe. Schnittstellen und Überschneidungen zwischen den Modellen werden noch einmal genau überprüft.[23]
5. Umsetzung und Prozessanalyse:
Die Umsetzung wird von einem kleinen Team durchgeführt. Je nach Art und Zweck des Modells müssen die Anwender aus den Fachbereichen einbezogen werden, damit es für alle verständlich ist und ein vertrauter Umgang sichergestellt wird. Daraufhin erfolgt die Prozessanalyse, bei der analysiert wird, ob das Modell alle benötigten Strukturen abbildet.[24]
Nachdem die GOM und das Vorgehensmodell näher beschrieben wurden, folgen die Grundlagen zur Definition und Konstruktion zum Thema Referenzmodellierung.
In der Wirtschaftsinformatik gehört die Referenzmodellierung zu den beliebten und häufig verwendeten Forschungsmethoden. Ein Referenzmodell ist ein Informationsmodell, das zum Entwurf eines weiteren Informationsmodells eingesetzt werden kann.[25] Es handelt sich vorwiegend um ein Daten- oder Prozessmodell. Die Aufgabe der Referenzmodellierung besteht darin, spezifische Informationsmodelle leichter, schneller, optimiert und preiswerter zu erarbeiten. Der günstige Nutzen ist durch eine hohe Wiederverwendbarkeit sichergestellt, da die Erstellung eines Modells nur einmalig erfolgen muss.[26] Ein weiterer Punkt ist, dass die Informationsmodelle, die in der Praxis zum Einsatz kommen, mögliche Abbildungsvarianten eines impliziten Referenzmodells sind.[27]
Es gibt in der Literatur keine einheitliche Definition von Referenzmodellen. Trotzdem zeichnen sich die Modelle durch gewisse Merkmale aus:
- Empfehlungscharakter: Dies leitet sich aus ihrer Funktion ab, als Ausgangslösung von Referenzmodellen zu gelten, aus der ein Modell hergeleitet wird.
- Wiederverwendbarkeit: Hierbei handelt es sich um eines der Hauptziele, dass mit einem Referenzmodell verfolgt wird.
- Allgemeine Gültigkeit: Die Absicht hinter diesem Merkmal besteht in der Verwendung von Referenzmodellen für eine Kategorie von unternehmensspezifischen Modellen.
- Akzeptanz: Zusammen mit der Wiederverwendbarkeit gehört es zu den grundlegenden Merkmalen, die ein Referenzmodell ausmachen.[28]
Grundsätzlich werden die Konstruktionstechniken eines Referenzmodells in Konfiguration, Instanziierung, Aggregation, Spezialisierung und Analogie differenziert (siehe Abbildung 1).[29] Der Umfang eines spezifischen Modells, das zuvor ausgearbeitet wurde, macht den Unterschied zwischen diesen Techniken aus. Ein Referenzmodell, das sich durch die Wiedergabe von vielen Inhalten auszeichnet, vereinfacht die Ausarbeitung eines spezifischen Modells in hohem Maße. Jedoch steigt damit auch der Aufwand für die Konstruktion. Dies ist der Tatsache geschuldet, dass zur Konstruktionszeit viele Optionen in Betracht gezogen werden müssen.[30]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Konstruktionstechniken von Referenzmodellen
(Quelle: Vom Brocke, 2013.)
Benutzt man bei der Erstellung eines Referenzmodells die Konstruktionstechnik Konfiguration, wird ein komplettes Modell erstellt. Aus diesem Modell werden jedoch je nach Anwendungsfall nur die berührenden Positionen für eine Evaluation herangezogen. Wird bei der Konstruktion eine Instanziierung gewählt, erstellt man ein detailliertes Teilmodell, das stark auf seinen Verwendungszweck zugeschnitten ist. Dieses Teilmodell wird daraufhin in ein generisches Ursprungsmodell integriert. Bei der Aggregation ergibt sich das Gesamtmodell aus der Zusammenführung unterschiedlicher Teilmodelle. Unter einer Spezialisierung versteht man die Ableitung eines geänderten oder erweiterten Modells aus einem abstrakten Modell. Eine Analogie beschreibt die Konstruktion eines Modells, wo ein Referenzmodell als Muster für ein Modell mit einem verwandten Zweck dient. Grundsätzlich kann auch eine Kombination dieser Techniken vorgenommen werden. Dabei müssen aber die jeweiligen Eigenschaften bewahrt werden. Welche Konstruktionstechnik schließlich ausgewählt wird, hängt von verschiedenen Faktoren ab. Ein sehr wichtiger Faktor stellt die Menge an Inhalten dar, die bereits bei der Gestaltung eines Referenzmodells einfließen oder wie viele sich erst bei der Anwendung im Unternehmenskontext erschließen. Außerdem geht aus der Abbildung 2 hervor, dass die Komplexität des ausgewählten Untersuchungsgebietes als weiterer Entscheidungsfaktor hinsichtlich der Kosten nicht außer Acht zu lassen ist.[31]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Konstruktionstechniken im Kostenvergleich
(Quelle: Vom Brocke, 2013.)
Der Ablauf der Referenzmodellierung wird wie folgt in zwei Prozesse aufgeteilt:
1. Der Prozess der Konstruktion von Referenzmodellen
In diesem Prozess wird für eine bestimmte Unternehmensklasse ein Referenzmodell erstellt. Er ist mit der Fertigstellung eines Referenzmodells abgeschlossen, das in unterschiedlichen Situationen der Modellierung herangezogen werden kann.
2. Der Prozess der Konstruktion von unternehmensspezifischen Informationsmodellen auf Basis von Referenzmodellen
Bei diesem Prozess handelt es sich um die Anwendung des Modells. Hier besteht das Ziel darin, auf Basis von Referenzmodellen ein Informationsmodell für ein bestimmtes Unternehmen in einer bestimmten Situation der Modellierung zu erarbeiten.[32]
In der Vergangenheit wurden verschiedene Modelle und Methoden entwickelt, um den Erfolg von Informationssystemen zu messen. Darunter befinden sich die Social Business Scorecard, das Aperto five model, das DeLone & McLean IS Success Model und das IS-Impact Measurement Model. Die beiden letztgenannten stellen die Grundlage für die Untersuchungen im Rahmen dieser Arbeit dar. Aufgrund ihrer Stellung in der Forschung bieten sie den Zugang zu zahlreichen Forschungsbeiträgen zu diesen Themen. Hierbei handelt es sich im Besonderen um kritische Auseinandersetzungen, die Vor- und Nachteile der verschiedenen Modelle sowie Barrieren bei der Erfolgsmessung analysieren.
Im Folgenden wird das DeLone & McLean IS Success Model beschrieben:
Ein in der Literatur häufig auftauchendes Modell zur Erfolgsmessung von Informationssystemen ist das 1992 entworfene DeLone & McLean IS Success Model. Durch Erkenntnisse aus der Kommunikationstheorie wurde ermittelt, dass sich eine große Zahl an Erfolgsmessungen in sechs Kategorien aufteilen lassen. Diese Kategorien werden auch als Dimensionen terminiert. Es handelt sich bei den Dimensionen um zusammenhängende, voneinander abhängige Variablen und nicht um unabhängige Erfolgskriterien.[33] Sie beinhalten jedoch messbare Erfolgsfaktoren, die in Kapitel 3.2.2 erörtert werden. In der folgenden Auflistung werden sie erläutert und in Abbildung 3 zur Übersicht dargestellt:
- Informationsqualität: Zuständig für die Messung der Eigenschaften über die geforderten Inhalte innerhalb eines Systems
- Systemqualität: Zuständig für die Messung der geforderten Eigenschaften eines Systems und gibt Aufschluss über das Ausmaß an Zufriedenheit der Nutzer sowie über die Nutzungshäufigkeit
- Nutzung: Anhand verschiedener Faktoren wird der Gebrauchsumfang eines Systems gemessen
- Nutzerzufriedenheit: Zuständig für die Ermittlung der Nutzerhaltung gegenüber einem System
- Individueller Einfluss: Messung des Einflusses (der Nutzung) eines Systems auf den einzelnen Nutzer
- Organisatorischer Einfluss: Zuständig für die Messung des Einflusses (der Nutzung) eines Systems auf die Leistung einer Organisation[34]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Altes Modell nach DeLone & McLean aus dem Jahr 1992
(Quelle: Richter, 2010, S. 91 in Anlehnung an: DeLone & McLean, 1992, S. 87.)
Zehn Jahre nach der Veröffentlichung wurde das Modell auf Drängen vieler Forscher ergänzt.[35] Hinzugefügt wurde die „Servicequalität“, die eine Grundvoraussetzung bei aktuellen Informationssystemen für eine erfolgreiche Nutzung darstellt. Dabei wird der Service und Support eines Systems bewertet. Zusätzlich wurde das Modell um „ beabsichtigte Nutzung“ erweitert. Damit wird die Einstellung der Nutzer zur Verwendung des Systems gemessen. Außerdem wurden die Kategorien „ Individueller Einfluss“ und „ Organisatorischer Einfluss“ zu einer leichter handhabbaren Kategorie, mit dem Namen „ Net Benefits beziehungsweise Nettonutzen“, zusammengefasst. Die folgende Abbildung 4 stellt das überarbeite IS-Erfolgsmodell dar:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Das aktualisierte D&M IS Success Model
(Quelle: DeLone & McLean, 2003, S. 24.)
Trotz großer Verbreitung ist dieses Modell einer Vielzahl an Kritik ausgesetzt. Dies ist auf die nicht ausreichende Begründung seines theoretischen Fundaments und auf die nicht einheitlichen empirischen Untersuchungsergebnisse zurückzuführen.[36]
Als nächstes folgt die Beschreibung zu dem IS-Impact Measurement Model:
Das IS-Impact Measurement Model ist ein Modell, das auf der Arbeit zu dem Erfolgsmodell von DeLone & McLean basiert. Es versucht, dessen Kritikpunkten entgegenzuwirken, indem es die Schwachstellen identifiziert und optimiert.[37] Die Entwickler beabsichtigen, ein robustes und valides Modell zu erstellen. Es soll überdies eine hohe Übertragbarkeit auf verschiedene Thematiken ermöglichen. Trotzdem wird viel Wert darauf gelegt, dass die aus dem Modell hervorgehenden Ergebnisse bezüglich Zeit, Stakeholder, unterschiedlicher Systeme und Systemkontext vergleichbar sind.[38]
Der Abbildung 5 ist zu entnehmen, dass die Erfolgsmessung mit diesem Modell anhand von vier Dimensionen erfolgt. Impact(Einfluss) beinhaltet die individuellen und organisatorischen Auswirkungen und Quality(Qualität) erfasst die Systemqualität und Informationsqualität.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: The IS-Impact Measurement Model
(Quelle: Gable et al. 2008, S. 395.)
Der Individual Impact ermittelt, wie stark der Einfluss eines Informationssystems auf die Effektivität eines Nutzers ist. Mit dem Organization Impact wird gemessen, wie groß die Einflussnahme auf den Fortschritt der organisatorischen Resultate ist. Die Dimension Information Quality gibt die Qualität der Informationen wieder, die innerhalb eines Informationssystems erzeugt werden. Mit der System Quality wird die technische und designbasierte Performance eines Systems ermittelt.[39]
Im Zusammenhang mit Enterprise 2.0 oder Enterprise Social Software tauchen viele Begrifflichkeiten auf, deren Bedeutungen stark verwandt sind und deshalb leicht miteinander verwechselt werden können. Es gilt, eine klare Abgrenzung zwischen diesen Ausdrücken herzustellen. Dabei wird auf das Web 2.0, Social Software und Enterprise Social Software eingegangen. Zum Abschluss werden Einsatzbereiche von Enterprise Social Software näher erörtert.
Die Bedeutung von Enterprise 2.0 geht Hand in Hand mit dem Begriff Web 2.0. Um Enterprise 2.0 im Detail verstehen zu können, müssen zunächst die Grundlagen des Web 2.0 erörtert werden.
Dieser Ausdruck entstand im Zuge eines Brainstormings von Tim O'Reilly und Dale Dougherty zur Vorbereitung auf eine Konferenz zum Thema Internet. Sie nahmen die Vorgehensweise bei der Softwareversionierung als Vorbild für die Benennung. Ihre Begründung beruhte darauf, dass nach dem Börsenkrach der Dotcom-Blase weiterhin interessante Web-Anwendungen im Internet zur Verfügung standen und es damit einen Wendepunkt in der Geschichte des Internets gab.[40] Es gab eine große Resonanz auf die Verwendung des erfundenen Begriffs, dies hatte auch viele Meinungsverschiedenheiten zur Folge.[41] Deshalb wurden folgende Charakterisierungen für das Web 2.0 festgelegt, um ein einheitliches Verständnis zu erzeugen:
- The Web as platform: Web-Anwendungen stellen dem Nutzer ihre Services gemäß einer Plattform bereit. Sie werden kontinuierlich erweitert, ohne das von einem Benutzer einen Mehraufwand hinsichtlich Installationen erwartet wird. Im Gegensatz zu klassischen Softwareprogrammen, die in Softwarepaketen ausgeliefert werden.
- Harnessing collective intelligence: Durch Hyperlinking innerhalb von Webseiten und die gemeinsame Bearbeitungs- oder Bewertungsmöglichkeit von Inhalten durch die Nutzer wird eine kollektive Intelligenz erschaffen. Dadurch werden interessante von weniger interessanten Inhalten differiert und aussagekräftige Informationen gewonnen.
- Data is the next Intel Inside: Im Fokus der Anwendungen stehen die Daten und nicht die Software selbst.
- End of the software release cycle: Software wird als Service angesehen und nicht mehr als Produkt. Diese hat für ein Unternehmen grundlegende Veränderungen der Geschäftsmodelle zur Folge.
- Lightweight programming models: Offene Schnittstellen und die Einhaltung von übersichtlichen Standards in modularen Anwendungen schaffen die Voraussetzung für eine Wiederverwendung von Daten für neue oder bestehende Anwendungen.
- Software above the level of a single device: Eine Beschränkung der Nutzung von Web 2.0-Anwendungen auf einem PC ist nicht mehr gegeben. Es ist möglich, die gleichen Inhalte auf mobilen Endgeräten abzurufen.
- Rich user experiences: Mit dem Gebrauch von Technologien wie zum Beispiel AJAX(Asynchronous JavaScript and XML) werden schnelle Reaktionszeiten zugelassen. Dies ermöglicht den Einsatz von dynamischen Oberflächen.[42]
In der folgenden Abbildung 6 von Koch und Richter werden die Zusammenhänge grafisch dargestellt:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: Zusammenhänge im Web 2.0
(Quelle: Vgl. Koch & Richter, 2009 S.5.)
Zusammengefasst wird das Web 2.0 so beschrieben, dass der Nutzer sich aktiv in die Weiterentwicklung des Internets einbringt und nicht ausschließlich als Konsument auftritt. Die Entwicklung und der Einsatz von neuen Technologien ebnen den Weg, um verbesserte Anwendungen auf den Markt zu bringen und leichter benutzbar zu machen. Je einfacher die Benutzbarkeit für die Anwender ist, desto höher ist die Wahrscheinlichkeit, dass diese auch aktiv mitwirken.[43]
Die Definition von Social Software lautet folgendermaßen:
Die Begrifflichkeit ist bereits vor dem Web 2.0 entstanden und bildet die Voraussetzung für ebenjenes und mithin für Enterprise 2.0.[44] Heute wird der Ausdruck für die verschiedenen Web-Anwendungen oder Softwaretools und Entwicklungen gebraucht, die dem Web 2.0 zuzuordnen sind. Eine häufig verwendete Definition liefert Tom Coates, der einen allgemeinen Ansatz verfolgte:
“Social Software can be loosely defined as software which supports, extends, or derives added value from, human social behaviour – message-boards, musical taste-sharing, photo-sharing, instant messaging, mailing lists, social networking.” [45]
Sie wurde auch aus anderen Perspektiven beschrieben, wie zum Beispiel aus der Kommunikationssoziologie von Jan Schmidt.
„[…] Social Software diejenigen onlinebasierten Anwendungen umfaßt, die das Informations-, Identitäts- und Beziehungsmanagement in den (Teil-)Öffentlichkeiten hypertextueller und sozialer Netzwerke unterstützen“ [46]
Es gibt eine Vielzahl an Optionen, das Angebot an unterschiedlichen Social Software Anwendungen zu klassifizieren. Eine von Koch und Richter vorgeschlagene Strukturierungsmöglichkeit ist die Fokussierung auf die Basis-Funktionen des Gebrauchs von Social Software. Dort werden drei Kategorien benannt, die in der Abbildung 7 im Zusammenhang mit den Anwendungsklassen dargestellt werden:
- Informationsmanagement: Die Zurverfügungstellung der Möglichkeit online verfügbare Informationen zu finden, zu bewerten und zu verwalten
- Identitäts- und Netzwerkmanagement: Im Internet die Möglichkeit zur Selbstdarstellung zu bieten sowie Kontakte herzustellen und aufrechtzuerhalten
- Interaktion und Kommunikation: Den Anwendern untereinander eine direkte und indirekte Kommunikation zu ermöglichen[47]
Außerdem werden aus der Perspektive der Wirtschaftsinformatik die technologischen und ökonomischen Betrachtungsweisen des Web 2.0 einbezogen.
Abschließend folgt eine Definition von Social Software nach Koch und Richter, die auch in dem Kontext dieser Arbeit ihre Gültigkeit besitzt.
„Anwendungssysteme, die unter Ausnutzung von Netzwerk- und Skaleneffekten, indirekte und direkte zwischenmenschliche Interaktion (Koexistenz, Kommunikation, Koordination, Kooperation) auf breiter Basis ermöglichen und die Identitäten und Beziehungen ihrer Nutzer im Internet abbilden und unterstützen.“ [48]
Die Anwendungsklassen von Social Software werden nachfolgend beschrieben:
Social Software Anwendungen werden, wie in der Definition beschrieben, in Anwendungsklassen gruppiert. Dies trägt neben der Definition zu einem besseren Verständnis bei, was Social Software im Kontext meint. Eine Anwendungsklasse sind zum Beispiel Wikis, die weitgehend der Kategorie Informationsmanagement zugeordnet werden. Von Koch und Richter wurden die folgenden Klassen beschrieben und wie in Abbildung 7 dargestellt nach ihrem Einsatzzweck in dem „Social Software Dreieck“ angeordnet:
- Weblogs und Microblogs
- Wikis und Gruppeneditoren
- Dienste zum Social Tagging und Social Bookmarking
- Social Networking Services
- Dienste zum Instant Messaging[49]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7: Das Social Software Dreieck
(Quelle: Koch & Richter, 2009 S.14.)
Der Begriff Enterprise 2.0 wurde 2006 von Andre P. McAfee erstmals benannt und beschreibt die Nutzung von Social Software Anwendungen wie zum Beispiel Wikis, Social Network-Diensten und Blogs im Unternehmenskontext. Enterprise Social Software steht dementsprechend für die computergestützte Vernetzung von Menschen innerhalb einer Organisation. Im folgenden Zitat von McAfee wird dies deutlich:
"Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers." [50]
Der zweite Teil der Aussage hebt deutlich hervor, dass sich der Gebrauch von Social Software nicht nur auf ein Unternehmen allein beschränken muss, sondern dass die Anwendung auch unternehmensübergreifend stattfinden kann. Das Hauptaugenmerk liegt auf der Weiterentwicklung der eigenen Fähigkeiten. Trotzdem werden auch die Möglichkeiten zur Verbesserung der Kundenorientierung identifiziert.[51] Da der Aspekt zur Intensivierung der Kundenbeziehungen von den unternehmensinternen Aufgaben getrennt betrachten werden sollte, hat McAfee seine ursprüngliche Definition dahingehend angepasst:
"Enterprise 2.0 is the use of emergent social software platforms by organisations in pursuit of their goals" [52]
Weiterhin definiert McAfee den Nutzen von Social Software anhand von sechs Eigenschaften, die das Akronym SLATES bilden. Richter und Koch haben diese Merkmale entsprechend der unten stehenden Auflistung interpretiert:
- Search – Die Suche nach Informationen
- Links – Die Verlinkung von Informationen
- Authoring – Das Erstellen und Bearbeiten von Inhalten
- Tags – Die Verknüpfung von Metadaten zu Informationen
- Extensions – Ein serviceorientierter, datenzentrierter Aufbau der Software
- Signals – Die Bekanntmachung von neuen Inhalten mittels Abonnement[53]
Ein weiterer Punkt besteht darin, dass neben einer Einbindung dieser Software auch Anpassungen der Strategien im Unternehmenskontext vorgenommen werden müssen. Sie äußern sich in neuen Management-Philosophien, Kommunikationsformen und Kollaborationen.[54] Dementsprechend erhoffen sich die Unternehmen mit dem Einsatz dieser Technologien, verschiedene Ziele zu verwirklichen, wie zum Beispiel das Potential der Mitarbeiter zu entfalten oder eine höhere Effektivität im Wissensaustausch erfolgreich sowie messbar zu unterstützen und zu verbessern,[55] Dies wird im nachfolgenden Zitat noch einmal erläutert:
„Insbesondere die Flexibilität von Geschäftsmodellen und Systemen ist ein wettbewerbsentscheidender Aspekt der Wertschöpfung im heutigen Markt geworden. […] Die Fähigkeit zu schnellen Innovationen durch vielfältige Kollaboration innerhalb der Mitarbeiterschaft ist ein weiteres zentrales Thema, […] um wettbewerbsfähig zu bleiben.“ [56]
In die hier erwähnten Einsatzbereiche fallen die in Kapitel 2.2.2 erwähnten Anwendungsklassen. Dabei werden vor Einführung einer Software zunächst Einsatzszenarien entworfen, die Aufschluss über die tatsächlichen Use Cases geben und eine Spezifizierung von Anforderungen ermöglichen. Diese Bedarfsermittlung stellt die Grundlage für eine Auswahl von einer oder mehreren Software-Anwendungen dar. Im Anschluss daran werden sie entsprechend eingeführt.
Die folgende Auflistung gibt eine Übersicht über mögliche Einsatzbereiche innerhalb eines Unternehmens wieder:
- Wissensmanagement
- Unternehmensinterne Kommunikation
- Projektmanagement
- Geschäftsprozessmanagement
- Verfahrensanweisungen/Dokumentation
- Ideenmanagement
- Produktentwicklung
- Kommunikation
Es gibt dabei klare Tendenzen, welche Einsatzbereiche den größten Faktor innerhalb der Unternehmen ausmachen. Dies geht aus einer Statistik von 2010 in der folgenden Abbildung 8 hervor. In der Interpretation muss berücksichtigt werden, dass sich die Einsatzbereiche nicht gegenseitig ausschließen. Im Gegenteil, so wird zum Beispiel innerhalb des Projektmanagements mit hoher Wahrscheinlichkeit auch Wissensmanagement eingesetzt und Kontakt mit der Unternehmensinternen Kommunikation betrieben.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8: Einsatzbereiche von Enterprise 2.0 in Unternehmen (2010)
(Quelle: centrestage. (n.d.). Einsatzbereiche von Enterprise 2.0 in Unternehmen im Jahr 2010. In Statista - Das Statistik-Portal. Zugriff am 10. Dezember 2017, von https://de.statista.com/statistik/daten/studie/163056/umfrage/einsatzbereiche-von-enterprise-20-in-unternehmen-2010/.)
Das in dieser Arbeit zu entwickelnde Referenzmodell wird in einem agilen Projekt zur Anwendung kommen. Um einen Unterschied in der Erfolgsmessung zwischen dem Unternehmens- und agilen Projektmanagementkontext herausarbeiten zu können, werden vorab die entsprechenden Begrifflichkeiten geklärt. Was macht Agilität aus? Was genau verbirgt sich hinter agilem Projektmanagement? Als agiles Vorgehensmodell wird Scrum näher beschrieben. Das ist auf die beschriebene Ausgangssituation zurückzuführen, da es dort in dem Projekt zum Einsatz kommt.
Um deutlich zu machen, was sich hinter dem Begriff „Agilität“ verbirgt, werden einige Definitionen aus der Literatur herangezogen.
„Agility is the ability to both create and respond to change in order to profit in a turbulent business environment” [57]
Die Definition sagt aus, dass Agilität sich durch einen bestimmten Aspekt in einem chaotischen Geschäftsumfeld auszeichnet. Es geht darum, die Fähigkeit zu besitzen einen Nutzen aus bewusst herbeigeführten Veränderungen oder entsprechenden Reaktionen zu ziehen. Agile Organisationen üben einen großen Druck auf ihre Konkurrenz aus, indem sie neue Wege gehen und damit einen Wandel auslösen.[58]
Letztere und drei weitere Definition sind folgendermaßen zusammengefasst und interpretiert worden:
„Agilität ist die Fertigkeit schnell, flexibel und situationsbezogen in chaotischen und dynamischen Situation zu agieren, indem eine Balance zwischen Strukturierung und Flexibilität geschaffen wird, um daraus einen Nutzen für den Kunden und sich selbst zu generieren.“ [59]
Die Aussage gibt einen deutlichen Eindruck davon wieder, welches Verständnis mit Agilität verbunden wird. Das Chaos als Risiko stellt auch Chancen bereit. Es gibt Wege und Möglichkeiten wirkungsvoll auf Veränderungen zu reagieren.
Im Folgenden wird das agile Manifest erläutert:
Alle agilen Vorgehensmodelle bauen auf dem agilen Manifest auf. Es wurde bei einer Zusammenkunft von 17 Autoren verfasst und im Jahr 2001 veröffentlicht. Vor der Verabschiedung des Manifests wurden bereits agile Vorgehensmodelle nach agilen Prinzipien entworfen, diese jedoch erst rückwirkend auch als solche entsprechend bezeichnet.[60] Die vier Leitsätze des agilen Manifests lauten im Folgenden:
- Individuen und Interaktionen stehen über Prozessen und Werkzeugen
- Funktionierende Software steht über einer umfassenden Dokumentation
- Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung
- Reagieren auf Veränderung steht über dem Befolgen eines Plans[61]
Sie sollen zum Ausdruck bringen, welche Prioritäten bei einer agilen Vorgehensweise gesetzt werden. Es spielt beispielsweise eine untergeordnete Rolle, welche Prozesse die Mitarbeiter einzuhalten haben oder welche Entwicklungswerkzeuge sie einsetzen. Entscheidend ist, dass der Mensch als solches und die Interaktionen untereinander eine wichtigere Position einnehmen. Im Weiteren enthält das agile Manifest zwölf Prinzipien. Diese wurden in den bereits eingesetzten agilen Methoden einbezogen. Wobei sie zum Teil unterschiedlich stark berücksichtigt werden.[62] Sie sind selbsterklärend und werden nachfolgend aufgelistet. Im weiteren Verlauf dieser Arbeit werden sie eine wichtige Rolle einnehmen, da viele Bezüge zu ihnen hergestellt werden.
1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
4. Fachexperten und Entwickler müssen während des Projektes
täglich zusammenarbeiten.
5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
10. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.
11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.[63]
Im Anschluss an die Beschreibung des agilen Manifests folgt eine Beschreibung der agilen Vorgehensmodelle:
In dem vorherigen Abschnitt wird erwähnt, dass es verschiedene agile Vorgehensmodelle beziehungsweise Methoden gibt, die in der Softwareentwicklung eingesetzt werden. Im Allgemeinen zeichnen sie sich durch die zuvor erörterten Werte und durch die Umsetzung der Vorgaben aus den Prinzipien des agilen Manifests aus. Im Besonderen liegen ihnen unter anderem die folgenden Eigenschaften zugrunde:
- Inkrementelle Entwicklung (kurze Zyklen, schnelle Entwicklungszeiträume)
- Kooperative Zusammenarbeit
- Leicht und schnell anpassbar[64]
Der Kunde soll zum Beispiel in einem Softwareentwicklungsprojekt durch die kurzen Zyklen frühzeitig die Möglichkeit bekommen, Teilergebnisse testen und bewerten zu können. Dadurch kann in frühen Stadien der Entwicklung festgestellt werden, ob das Produkt den Anforderungen entspricht. Bei Unstimmigkeiten erhält das Entwicklungsteam zeitnahe Rückmeldungen, kann anhand des Feedbacks entsprechend reagieren und kurzfristig Änderungen vornehmen. Dabei bildet eine kooperative Zusammenarbeit das Grundgerüst für ein erfolgreiches Projekt.[65]
Einige Methoden werden zur Übersicht nachfolgend aufgelistet:
- Crystal
- Feature Driven Development
- Lean
- Development
- Scrum
- XP
Die Art und Weise, wie die Vorgehensmodelle die agilen Werte berücksichtigen, kann unterschiedlich ausgeprägt sein. Deshalb wurde von Highsmith, 2002 eine Untersuchung dazu durchgeführt. Nachfolgend gibt die Tabelle 1 einen Überblick zu den verschiedenen Vorgehensmodellen in Bezug zu dem Grad ihrer Agilität. Dabei wird ersichtlich, dass es sich bei Scrum um die Methode mit dem zweithöchsten Grad handelt.
Tabelle 1: Bewertung agiler Methoden
Abbildung in dieser Leseprobe nicht enthalten
(Quelle: In Anlehnung an Trepper, 2012, S. 76.)
Es wurde die Methode Scrum für eine nähere Beschreibung ausgewählt, da in dem Projekt aus der Ausgangsituation Scrum eingesetzt wird und sich das exemplarische Fallbeispiel, das im späteren Teil dieser Arbeit zum Einsatz kommt, daran orientiert. Die folgende Definition und die Spielregeln von Scrum richten sich nach dem Scrum Guide von Schwaber & Sutherland, 2016, der als Leitfaden für die korrekte Umsetzung Scrum dient. Dort lautet die Definition von Scrum folgendermaßen:
Scrum ist ein leichtgewichtiges Vorgehensmodell, das leicht zu begreifen, aber schwierig umzusetzen ist. Es wird zur Erstellung von komplexen Produkten eingesetzt. Innerhalb des Modells können verschiedene Techniken und Prozesse verwendet werden, die die Menschen dabei unterstützen, komplexe Anforderungen mit einem möglichst hohen Maß an Qualität umzusetzen. Deshalb ist es als Rahmenwerk aufzufassen und nicht als Prozess oder Technik.
Scrum setzt sich zusammen aus dem Scrum Team, Ereignissen, Artefakten und Regeln. Dabei sind alle genannten Teilstücke wichtige Elemente des Gesamten und die Voraussetzung für einen gelungenen Einsatz von Scrum.
Die Regeln von Scrum reglementieren die Korrelationen zwischen den Artefakten, Ereignissen und Rollen.
Im Anschluss an die Definition von Scrum werden die Rollen, Ereignisse und Artefakte beschrieben:
- Das Scrum Team
Das Team setzt sich aus dem Entwicklungsteam, dem Product Owner sowie dem Scrum Master zusammen. Sie sind mit allen erforderlichen Qualifikationen und Befugnissen ausgestattet, um unabhängig von anderen Personen außerhalb des Teams eigenverantwortlich ihre Arbeiten erfolgreich verrichten zu können. Der Fokus dieser Zusammenstellung liegt auf der Optimierung der Flexibilität, Kreativität und Produktivität.
- Das Entwicklungsteam
Die primäre Eigenschaft eines Entwicklungsteams liegt in der Fähigkeit, am Ende eines Sprints ein potentiell auslieferbares Produkt bereitstellen zu können. Die Größe eines Teams ist nicht strikt festgelegt und folgt der Anforderung, sich in Relation zum Umfang und der Komplexität eines Projektes auszurichten. Wobei die Faustregel gilt: Kleine Teams steigern die Flexibilität und zu kleine Teams verringern das Know-how. Große Teams erfordern viel Koordination und erzeugen damit eine hohe Komplexität. Der Product Owner und Scrum Master gehören nicht zum Entwicklungsteam. Es sei denn, sie verrichten ebenfalls Aufgaben aus dem Product Backlog, das bei den Artefakten beschrieben wird.
- Der Product Owner
Diese Person ist für die Verwaltung des Backlogs zuständig. Dazu gehören Aufgaben wie zum Beispiel die Einträge im Backlog zu verfassen und sie entsprechend zu sortieren. Dabei liegt der Fokus darauf, die Priorisierung in der Sortierung dahingehend auszurichten, dass die vorgegebenen Ziele bestmöglich erreicht werden können. Außerdem muss der Product Owner die Verständlichkeit der Einträge für das Entwicklungsteam sicherstellen.
- Der Scrum Master
Der Scrum Master trägt die Verantwortung über die richtige Interpretation der vergebenen Rollen und die korrekte Umsetzung von Scrum. Gegenüber dem Scrum Team tritt diese Rolle als Servant Leader auf. Das heißt, dass diese Position eine dienende Komponente bezüglich seiner Führungsrolle übernimmt.
Drei übergeordnete Aufgabengebiete werden vom Scrum Master übernommen. Ein Gebiet ist der Dienst gegenüber dem Product Owner. Darunter fallen unter anderem die Vermittlung von Techniken zur effektiven Verwaltung des Product Backlogs und das Herstellen eines Verständnisses hinsichtlich der Wichtigkeit präziser und nachvollziehbarer Einträge für das Scrum Team. Ein weiteres Aufgabengebiet ist der Dienst gegenüber dem Entwicklungsteam. In diesem Zusammenhang übernimmt er die Aufgabe Hindernisse zu beseitigen, die das Entwicklungsteam bei der Arbeit behindern. Weiterhin gehört es zu seinen Pflichten, das Team soweit zu führen, dass diese sich weitgehend selbst organisieren und funktionsübergreifend interagieren. Das dritte Aufgabengebiet bezieht sich auf seine Verpflichtungen gegenüber der Organisation. Der Scrum Master übernimmt die Leitung und das Einweisen bei der Einführung von Scrum. Ferner unterstützt er die Stakeholder Scrum und die empirische Produktentwicklung verständlich zu machen und zu realisieren.
- Scrum Ereignisse
Die Ereignisse sind notwendig, um Regelmäßigkeiten innerhalb eines Sprints herzustellen. Sie sollen die Anzahl anderer Besprechungen möglichst gering halten, die nicht von Scrum definiert wurden. Jedes Ereignis, mit Ausnahme des Sprints, bietet die Möglichkeit zur Kontrolle und Adaption des Vorgehens. Der Entfall eines Ereignisses verringert die Transparenz und erschwert die Überprüfungen, wodurch die Gelegenheit zur Reaktion auf Veränderungen genommen wird.
Bei dem Sprint handelt es sich um das Kernelement von Scrum. Er ist zeitlich begrenzt und innerhalb dieser Zeit wird ein nutzbares Produktinkrement hergestellt und ausgeliefert. In einem Projekt sollte die Dauer immer konstant bleiben, wobei die Dauer nach Komplexität und Umfang des Projektes zu Beginn festgelegt wird. Trotzdem sollte er nicht länger als einen Monat dauern. Der neue Sprint startet im Anschluss des Abgeschlossenen.
In diesem festdefinierten Zeitrahmen gibt es weitere Ereignisse, die im Rahmen eines Sprints durchgeführt werden. Dazu gehören die Folgenden:
- Sprint Planning: Planung des Sprints und Festlegung des Sprint-Ziels
- Daily Scrum: Synchronisation der Teamaktivitäten und Planung der nächsten 24 Stunden
- Sprint Review: Überprüfung des Produktinkrements am Ende eines Sprints mit den Stakeholdern
- Sprint Retrospektive: Selbstüberprüfung des Sprint Teams für einen möglichen Verbesserungsplan, der im nächsten Sprint umgesetzt wird
- Artefakte
Es gibt verschiedene Artefakte in Scrum. Sie stellen Arbeit oder Wert dar und bringen Transparenz in ein Projekt sowie die Möglichkeit, Überprüfungen und Anpassungen vornehmen zu können:
- Product Backlog: Das ist die Gesamtliste von Anforderungen, was ein Produkt beinhalten kann. Anforderungen werden in User Stories formuliert.
- Sprint Backlog: Dabei handelt es sich um ausgewählte Anforderungen aus dem Product Backlog, die zur Erreichung des Sprint-Ziels notwendig sind.
- (Produkt-)Inkrement: Das ist das Ergebnis, das sich aus der Umsetzung aller Anforderungen aus dem Sprint Backlog ergibt.[66]
[...]
[1] Vgl. Steinhüser & Räth, 2010, S. 1735f., ähnlich Gemlik, Neumann, Sprenger, & Breitner, 2010, S. 619.
[2] Vgl. Jahnke, Hermann, & Prilla, 2008, S. 377.
[3] Vgl. Vom Brocke, 2015, S. 9.
[4] Vgl. Fettke & Loos, 2002, S. 15., zit. nach Vgl. Schütte, 1998, S. 40-48.
[5] Vgl. Krüger, 2012 S.215.
[6] Fettke & Loos, 2002, S. 15.
[7] Vgl. Fettke & Loos, 2002, S. 15.
[8] Fettke & Loos, 2002, S. 15.
[9] Vgl. Fettke & Loos, 2002, S. 15.
[10] Vgl. Krüger, 2012 S.215.
[11] Fettke & Loos, 2002, S. 16.
[12] Vgl. Fettke & Loos, 2002, S. 16.
[13] Vgl. Becker, 1998.
[14] Vgl. Becker, 1998, S. 4.
[15] Vgl. Becker, 1998, S. 4f.
[16] Vgl. Becker, 1998, S. 5.
[17] Vgl. Becker, 1998, S. 5f.
[18] Vgl. Becker, 1998, S. 6f.
[19] Vgl. Becker, 1998, S. 7.
[20] Vgl. Becker, 1998, S. 7f.
[21] Vgl. Becker, 1998, S. 8f.
[22] Vgl. Becker, 1998, S. 9.
[23] Vgl. Becker, 1998, S. 9f.
[24] Vgl. Becker, 1998, S. 10f.
[25] Vgl. Vom Brocke, 2015, S. 31.
[26] Vgl. Zimmermann, 2013, S. 113f.
[27] Vgl. Vom Brocke, 2015, S. 82.
[28] Vgl. Vom Brocke, 2015, S. 31f.
[29] Vgl. Vom Brocke, 2007, S. 7.
[30] Vgl. Zimmermann, 2013, S. 114.
[31] Vgl. Zimmermann, 2013, S. 115.
[32] Vgl. Fettke & Loos, 2002, S. 10.
[33] Vgl. Gemlik, Neumann, Sprenger, & Breitner, 2010, S. 616.
[34] Vgl. Richter, 2010, S. 91., ähnlich. DeLone & McLean, 1992, S. 64-74.
[35] Vgl. Pitt, Watson, & Kavan, 1995.
[36] Vgl. Gable, Sedera, & Chan, 2008, S. 390.
[37] Vgl. Steinhüser & Räth, 2010, S. 1737.
[38] Vgl. Gable, Sedera, & Chan, 2008, S. 378.
[39] Vgl. Gable, Sedera, & Chan, 2008, S. 389f.
[40] Vgl. O'Reilly, 2007 S.7.
[41] Vgl. O'Reilly, 2007 S.8.
[42] Vgl. O'Reilly, 2007, S. 18-36.
[43] Vgl. Koch & Richter, 2009S.5.
[44] Vgl. Koch & Richter, 2009 S.11f.
[45] Coates, 2005.
[46] Schmidt, 2006 S.37.
[47] Vgl. Koch & Richter, 2009 S.12.
[48] Koch & Richter, 2009 S. 12.
[49] Vgl. Koch & Richter, 2009 S. 13f.
[50] Pelkmann & Gaudin, 2010.
[51] Vgl. Göhring, Niemeier, & Vujnovic, 2010 S.12.
[52] McAfee A. , 2009 S.73.
[53] Vgl. Koch & Richter, 2009 S.14.
[54] Vgl. Koch & Richter, 2009 S.15ff.
[55] Vgl. Göhring, Niemeier, & Vujnovic, 2010 S.13.
[56] Göhring, Niemeier, & Vujnovic, 2010 S.11.
[57] Highsmith, 2002, S. 29.
[58] Vgl. Highsmith, 2002, S. 29.
[59] Trepper, 2012, S. 67.
[60] Vgl. Trepper, 2012, S. 67f.
[61] Beck, et al., 2001.
[62] Vgl. Trepper, 2012, S. 69.
[63] Beck, et al., 2001.
[64] Vgl. Trepper, 2012, S. 76.
[65] Vgl. Trepper, 2012, S. 75.
[66] Vgl. Schwaber & Sutherland, 2016.
