Lade Inhalt...

Untersuchung des Einsatzes und der Auswirkungen von Enterprise Social Software im agilen Projektumfeld

Masterarbeit 2014 129 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhaltsverzeichnis

1. Einleitung
1.1 Problemstellung
1.2 Zielsetzung
1.3 Hypothese
1.4 Vorgehensweise
1.5 Aufbau

2. Grundlagen
2.1 Groupware
2.2 Enterprise Social Software
2.3 Agiles Projektumfeld
2.4 Kommunikationseffizienz

3. Experiment
3.1 Allgemeine Rahmenbedingungen
3.2 Problembeschreibung
3.3 Unabhängige und abhängige Variablen
3.4 Experiment-Aufbau
3.5 Vorgaben an Experiment-Teilnehmer
3.5.1 Allgemeine Vorgaben
3.5.2 Tool-Vorgaben
3.5.3 Kanban
3.5.4 Zeiterfassung
3.5.5 Unterstützung durch den Projektleiter
3.5.6 E-Mail-Benachrichtigungen
3.6 Durchführung
3.7 Störvariablen
3.8 Fragebogen

4. Datenauswertung
4.1 E-Mails
4.2 Enterprise Social Software
4.3 Zeiterfassung Besprechungen
4.4 Fragebogen
4.4.1 Quantitative Auswertung
4.4.2 Qualitative Auswertung
4.5 Bewertung
4.6 Operation Reviews
4.6.1 Groupware-Szenario
4.6.2 Enterprise Social Software Szenario
4.7 Zusammenfassung der Auswertung
4.8 Kritische Reflexion
4.9 Überprüfung der Hypothese

5. Konzeptionelle Vorarbeit
5.1 Fallstudienanalyse
5.2 Analyse eines Leitfadens
5.3 Analyse des "Model of Employee's adoption of Enterprise 2.0"
5.4 Erfolgsmessung von Enterprise Social Software
5.5 Human-Performance-Cycle

6. Etablierungskonzept
6.1 Kommunizieren der Mehrwerte
6.1.1 Identifikation von Experten
6.1.2 Auffinden von Informationen
6.1.3 Kommunikation
6.1.4 Teilen von Wissen
6.1.5 Sozialer Austausch
6.1.6 Freude an der Nutzung
6.1.7 Offene Unternehmenskultur und Selbstorganisation
6.2 Mitarbeitergespräche
6.3 Schulungen
6.4 Motivation und Hilfestellung
6.5 Erfolgsmessung
6.6 Weiterentwicklung

7. Fazit
7.1 Zusammenfassung
7.2 Beitrag zur Forschung
7.3 Praktischer Nutzen
7.4 Einschränkungen
7.5 Ausblick

Anhang

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Literaturverzeichnis

Vorwort

Hinweis zu geschlechtsneutralen Formulierungen

Aus Gründen der Lesbarkeit sowie des persönlichen Sprachempfindens wird auf die Verwendung von Doppelnennungen verzichtet. Alle Aussagen in männlicher Form gelten ebenso gleichermaßen für das weibliche Geschlecht, welches trotz des Verzichts auf Doppelnennungen nicht ausgeschlossen werden soll.

Danksagung

In der eidesstaatlichen Erklärung am Ende der Masterarbeit erklärt der Autor, dass die Arbeit selbständig verfasst wurde und alle benutzten Hilfsmittel sowie Quellen angegeben worden sind. Das ist selbstverständlich, doch wer außer dem Autor noch hinter der Arbeit steckt wird, sollte nicht vergessen werden. Es haben viele Menschen zum Gelingen dieser Arbeit beigetragen, bei denen ich mich an dieser Stelle herzlich bedanken möchte. Zuerst möchte ich dem Betreuer meiner Masterarbeit, Prof. Dr. Hennermann, für die große Unterstützung und die regelmäßigen Treffen ein großes Dankeschön aussprechen. Auf ihn konnte ich mich immer verlassen. Außerdem danke ich dem technischen Mitarbeiter Herrn Riegler, der sich immer sofort die Zeit nahm, um von mir gewünschte Konfigurationen der Atlassian-Produkte JIRA und Confluence durchzuführen und mir beratend zur Seite stand. Prof. Dr. Braun sowie der Firma Atlassian möchte ich für die Zurverfügungstellung von JIRA und Confluence im Rahmen der Hochschul-Lizenz danken. Ebenfalls danke ich meiner Freundin, besonders für ihre Geduld in der Endphase der Masterarbeit. Des Weiteren danke ich meinen Freunden, besonders Patrick, für die sehr hilfreichen fachlichen Diskussionen. Auch die Teilnehmer des Experiments haben mich sowohl durch ihre Teilnahme als auch konstruktive kritische Einwände unterstützt, wofür ich sehr dankbar bin. Vor allem danke ich hier Sebastian für die Einrichtung und Zurverfügungstellung der E-Mail-Adressen. Außerdem möchte ich mich noch bei Marie bedanken, die mir durch das Korrekturlesen gegen Ende der Bearbeitungszeit sehr viel Zeit, Nerven und vor allem Fehler erspart hat. Abschließend danke ich meiner Familie, die mir Rückhalt und Unterstützung gibt.

"Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Werkzeuge vorzubereiten, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre die Männer die Sehnsucht nach dem weiten endlosen Meer." Antoine de Saint-Exupéry (1900-1944)

Kurzfassung

Die im privaten Bereich weit verbreiteten Sozialen Medien ergeben auch für Unternehmen ein erhebliches Potential (siehe Abschnitt 1.1). Besonders die Art und Weise der Kommunikation wird durch Soziale Medien grundsätzlich verändert (siehe Abschnitt 2.2). In einem agilen Projektumfeld liegt der Fokus auf Flexibilität und einer iterativen Vorgehensweise. Dadurch werden eine bessere Performance, ein höherer Innovationsgrad, sowie ein gesteigerter Mehrwert für den Kunden trotz weniger Management-Aufwand angestrebt. Allerdings erfordert dies zwangsläufig einen höheren Kommunikationsbedarf, wodurch Enterprise Social Software im agilen Projektumfeld besonders an Bedeutung gewinnt (siehe Abschnitt 2.3). In der Masterarbeit werden, im Rahmen eines Laborexperiments mit 24 Masterstudenten, der Einsatz und die Auswirkungen von Enterprise Social Software im agilen Projektumfeld untersucht (siehe Kapitel 3). Zum einen wird hierbei eine Hypothese in Bezug auf die Kommunikationseffizienz sowohl aufgestellt (siehe Abschnitt 1.3) als auch überprüft (siehe Abschnitt 4.9) und zum anderen ein Etablierungskonzept für die Praxis erarbeitet (siehe Kapitel 6).

Abstract

Social media is an ubiquitous part within the general public, which fundamentally changed the way we communicate (see chapter 2.2). These changes indicate potential benefits in utilizing this form of interaction in modern companies (see chapter 1.1). Consistent performance, innovation and customer benefits are ubiquitous objectives. Agile processes aim to achieve these goals, while keeping the management overhead within a reasonable limit. However, they require elaborate forms of communication, thus demanding capable Enterprise Social Software (see chapter 2.3). Therefore, this thesis investigates the usage and its impact of Enterprise Social Software within agile projects by evaluating the experience of 24 graduate students (see chapter 3). In doing so, a hypothesis related to the communication efficiency is being stated (see chapter 1.3) and validated (see chapter 4.9) while designing an adoption-strategy for practical use (see chapter 6).

1. Einleitung

Nach einer Erläuterung der Problemstellung und der Zielsetzung werden in diesem Kapitel der Aufbau sowie die Vorgehensweise behandelt. Ebenso werden die Sachhypothese und die dazugehörigen statistischen Hypothesen erläutert. Die Sachhypothese wird in Abschnitt 4.9 überprüft.

1.1 Problemstellung

Wäre es nicht schön, auch im Berufsleben nicht mehr in der täglichen E-Mail-Flut zu ertrinken und stattdessen bekannte Funktionalitäten sozialer Medien zu nutzen?

Aus einer Studie der International Data Corporation (IDC), die im August 2013 veröffentlicht wurde, wird das Potential von Social Media im Bereich von Unternehmen deutlich. Ein Drittel der befragten 359 Unternehmen setzt bereits Social Media ein, Tendenz steigend, sowohl für die externe Interaktion (beispielsweise mit Geschäftspartnern) als auch für die interne Zusammenarbeit. Bis 2017 wird für Enterprise Social Software ein Marktvolumen von 134 Millionen EUR prognostiziert, was im Vergleich zur Hochrechnung aus 2013 einer Vervierfachung entsprechen würde. Doch es gibt auch zu überwindende Hürden. Als größte Hürde wird die Messbarkeit des Einflusses auf die Geschäftsziele angegeben.[1]

Dies deckt sich mit den Aussagen einer Veröffentlichung im Rahmen der Wirtschaftsinformatik-Konferenz 2014 in Paderborn, welche basierend auf 26 Experteninterviews einen Bedarf an Erfolgsmessungsmodellen im Bereich Enterprise Social Software aufzeigt, die einfach und praktikabel sind und verschiedene Lebenszyklen sowie Aufwand-Nutzen-Aspekte betrachten.[2]

Somit besteht ein hoher Bedarf, beispielsweise Produktivitätsverbesserungen zu ermitteln. Allerdings sollten auch weiche Faktoren, wie beispielsweise eine Erhöhung der Mitarbeiterzufriedenheit, nicht außer Betracht gelassen werden.[3]

In dem genannten Forschungsgebiet setzt diese Masterarbeit an. Es werden hierbei der Einsatz sowie die Auswirkungen von Enterprise Social Software untersucht. Der Anwendungsbereich wird hierbei auf das agile Projektumfeld eingegrenzt. Im Kern geht es um Flexibilität und Iteration, eine genauere Erläuterung zum agilen Projektumfeld findet sich im Abschnitt 2.3. Die erforderliche Flexibilität basiert auf häufigen Änderungen. Diese erhöhen zwangsläufig die notwendige Menge an Kommunikation, ebenso wie die genannte Iteration. Der Fokus auf das agile Projektumfeld wirkt sich somit vor allem durch eine intensive Ausprägung im Bereich Kommunikation aus, weshalb auch in diesem Bereich eine Hypothese aufgestellt (Abschnitt 1.3) und überprüft wird (Abschnitt 4.9).

1.2 Zielsetzung

Das Ziel dieser Arbeit teilt sich in zwei Teilziele auf.

Das erste Teilziel behandelt die Überprüfung der Hypothese "Durch den Einsatz von Enterprise Social Software (in Kombination mit klassischer Groupware) für die interne Kommunikation im agilen Projektumfeld lässt sich die Kommunikationseffizienz steigern, verglichen mit dem Einsatz klassischer Groupware-Lösungen." durch eine Vorstudie im Rahmen eines Laborexperiments.

Das zweite Teilziel befasst sich mit der Erstellung eines Konzepts für den Einsatz von Enterprise Social Software im agilen Projektumfeld in der Praxis.

1.3 Hypothese

Im Rahmen dieser Masterarbeit wird folgende Sachhypothese aufgestellt:

Durch den Einsatz von Enterprise Social Software (in Kombination mit klassischer Groupware) für die interne Kommunikation im agilen Projektumfeld lässt sich die Kommunikationseffizienz steigern, verglichen mit dem Einsatz klassischer Groupware-Lösungen.

Diese unterteilt sich in zwei statistische Hypothesen (siehe Abbildung 1). Der in den statistischen Hypothesen verwendete Begriff „klassische Groupware" repräsentiert im Rahmen des Experiments Google Hangout, Google Drive, Thunderbird und JIRA (mit deaktivierten Social Software Funktionalitäten).

Statistische Hypothese 1:

Durch den Einsatz von Confluence (in Kombination mit klassischer Groupware) für die interne Kommunikation in Software-Beratungs-Projekten nach Kanban lässt sich die Anzahl an E-Mails, verglichen mit dem Einsatz klassischer Groupware-Lösungen, um durchschnittlich mindestens 90% senken. Der Output bleibt hierbei gleich.

Statistische Hypothese 2:

Durch den Einsatz von Confluence (in Kombination mit klassischer Groupware) für die interne Kommunikation in Software-Beratungs-Projekten nach Kanban lässt sich der Zeitaufwand für virtuelle Besprechungen, verglichen mit dem Einsatz klassischer Groupware-Lösungen, um durchschnittlich mindestens 20% senken. Der Output bleibt hierbei gleich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aufteilung der Sachhypothese

1.4 Vorgehensweise

Basierend auf einer Literaturanalyse wird definiert, was im Rahmen dieser Masterarbeit unter Groupware, Enterprise Social Software, einem agilen Projektumfeld und Kommunikationseffizienz zu verstehen ist. Ebenso wird eine Sachhypothese aufgestellt, die sich in zwei statistische Hypothesen unterteilt, um die Sachhypothese messbar zu machen. Die Überprüfung der Hypothesen erfolgt durch eine Nutzungsdatenanalyse eines durchzuführenden Laborexperiments sowie einer Befragung im Rahmen dieses Experiments.

Die Struktur der Beschreibung des durchzuführenden und hier beschriebenen Experiments orientiert sich an einem Handbuch für Methoden der Organisationsforschung. Hierzu erfolgt eine Unterteilung in unabhängige Variablen, abhängige Variablen und Störvariablen. Da eine Ermittlung und Berücksichtigung aller möglichen Störvariablen bezogen auf den Wirkungszusammenhang unmöglich ist, müssen die Untersuchungseinheiten (hier: Teams) zufallsbasiert in eine Kontroll- und Experimentalgruppe zugeteilt werden. Wird dies berücksichtigt, gilt ein Experiment im kausal-wissenschaftlichen Paradigma bezüglich der Ermittlung der ursächlichen Wirkrichtung der Variablen als Königsweg, verglichen mit einer ausschließlichen Befragung.[4]

Durch die Kombination von experimenteller und nichtexperimenteller Forschung kann die häufig kritisierte Künstlichkeit eines Laborexperiments relativiert werden, was zu einer Erhöhung der Validität führt.[5]

Aus diesem Grund wird als Ergänzung des Experiments die erwähnte Befragung aller Versuchsteilnehmer mit Hilfe eines Fragebogens durchgeführt.

Basierend auf einer Auswertung des Experiments sowie einer konzeptionellen Vorarbeit wird abschließend ein Etablierungskonzept für den Einsatz von Enterprise Social Software im agilen Projektumfeld in der Praxis erarbeitet.

1.5 Aufbau

Die vorliegende Masterarbeit teilt sich gemäß Abbildung 2 in 7 Kapitel auf. Die einzelnen Kapitel sind stark miteinander verknüpft. Die entsprechenden Verknüpfungen werden im Text jeweils explizit erwähnt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Aufbau der Arbeit

Durch Kapitel 1 erhält der Leser eine Einführung, welche durch das Vermitteln von Grundlagen sowie notwendigen Definitionen im zweiten Kapitel vervollständigt wird. Im Anschluss daran wird ein durchzuführendes Laborexperiment beschrieben (Kapitel 3), analysiert, ausgewertet und zur Überprüfung der Hypothese verwendet (Kapitel 4). Danach erfolgt eine konzeptionelle Vorarbeit (Kapitel 5), welche als zusätzliche Grundlage für die Konzepterstellung (Kapitel 6) dient. Kapitel 7 schließt die Arbeit mit einem Fazit ab.

2. Grundlagen

In diesem Kapitel werden theoretische Grundlagen vermittelt und Begriffe definiert, die in den darauffolgenden Kapiteln verwendet werden.

2.1 Groupware

Für Groupware gibt es unzählige Definitionen in der Literatur. Im Folgenden werden einige Definitionen aus der Entstehungszeit von Groupware betrachtet.

Johansen sieht 1988 in Groupware sowohl Hardware, Software, Dienste, als auch Gruppenprozess-Support für kollaborative Arbeitsgruppen, die in der Regel aus kleinen Projektteams bestehen, enge Zeitfenster haben und bedeutsame Aufgaben erledigen müssen ("... a generic term for specialised computer aids that are designed for the use of collaborative work groups. Typically, these groups are small, project-oriented teams that have important tasks and tight deadlines. Groupware can involve software, hardware, services, and/or group process support.").[6]

Opper und Fersko-Weiss verstehen 1991 unter Groupware Informationssysteme zur elektronischen Zusammenarbeit von Gruppen ("Groupware is any information system designed to enable groups to work together electronically.").[7]

Lewe und Krcmar bezeichnen Groupware im gleichen Jahr als Kommunikations- und Informationstechnologie für Gruppenarbeit ("Mit CSCW wird das Forschungsgebiet bezeichnet, das sich ganz allgemein mit der Rolle von Informations- und Kommunikationstechnologien bei der Gruppenarbeit beschäftigt, während Groupware die beforschte Technologie selbst bezeichnet.").[8]

Finke sieht in Groupware ein Jahr später grundsätzlich eine effektive und effiziente Zusammenarbeit sowie die Identifikation und Auswertung von Informationen ("... handelt es sich bei Groupwaresystem [sic!] um Softwareprodukte, die es Arbeitsgruppen ermöglichen, effizient und effektiv im Rahmen gemeinsamer Aufgabenstellungen zusammenzuarbeiten und die gleichzeitig dazu beitragen, Informationen im Rahmen von Arbeitsprozessen besser zu erschließen und verwerten."). [9]

Im Rahmen dieser Masterarbeit wird daher Groupware grundsätzlich als „Software zur Gruppenzusammenarbeit" definiert, wobei im Folgenden eine Betrachtung der konkreten Funktionalitäten erfolgt.

Koch und Richter zählen zu Groupware E-Mails, gemeinsame To-Do-Listen/Adressbücher/Terminkalender. Ebenfalls verstehen sie darunter Informationsräume, um gemeinsame Datenbestände zu verwalten. Außerdem zählen sie Instant-Messaging, Gruppeneditoren und Konferenzsysteme dazu.[10]

Für diese Arbeit werden, mit Ausnahme von Instant-Messaging, alle genannten Funktionalitäten dem Begriff Groupware zugeordnet.

Der Grund für die Definition von Groupware im Rahmen dieses Unterkapitels ist die Verwendung dieses Begriffs in Kapitel 3 und 4.

2.2 Enterprise Social Software

Im Rahmen dieser Masterarbeit werden die Begriffe "Enterprise 2.0", "Enterprise Web 2.0", "Social Software für Unternehmen", "Social Networking Services für Unternehmen", "Social Media für Unternehmen", "Enterprise Social Networks" und "Web 2.0 für Unternehmen" synonym mit "Enterprise Social Software" verwendet. Dieser Hinweis soll zum einen den Lesefluss erleichtern, aber auch auf die Suchbegriffe im Rahmen der Literaturrecherche aufmerksam machen. Es wurde jeweils sowohl nach "Unternehmen" als auch "Firma" bzw. "Firmen" gesucht und im Englischen "Organization", "Enterprise" und "Company" (inkl. dazugehöriger Mehrzahlformen).

Da Begriffe wie Wiki, Blog etc. in der Regel bekannt sind und in der Literatur häufig genug erläutert werden, wird im Rahmen dieser Arbeit auf entsprechende Beschreibungen verzichtet.

Soziale Medien wie beispielsweise Facebook sind im privaten Bereich weit verbreitet, doch auch für den geschäftlichen Bereich ergibt sich ein erhebliches Potential. Allerdings herrscht in vielen Unternehmen Unkenntnis über die genaue Bedeutung und Herausforderungen.[11]

Besonders die Art und Weise der Kommunikation wird durch Social Media verändert. Es handelt sich sowohl im Privatbereich als auch in Unternehmen nicht um eine vorübergehende Erscheinung. Betroffen ist vielmehr die Unternehmenskultur anstatt der Technologie. Es stellt für Unternehmen daher eine der größten Herausforderungen in der heutigen Zeit dar, da sowohl die Organisation, die Führung als auch die Mitarbeiter betroffen sind. Die Umsetzung ist häufig tiefgreifend und langwierig.[12]

Geprägt wurde der Begriff "Enterprise 2.0", der im Rahmen dieser Masterarbeit, wie bereits erwähnt, synonym mit "Enterprise Social Software" verwendet wird, durch Andrew McAfee im Jahr 2006: "Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.".[13] Somit geht es nicht nur um eine ausschließliche Verwendung innerhalb der eigenen Firma, sondern auch beispielsweise um die Kommunikation mit dem Kunden.

McAfee listet 2006 in seiner vielzitierten Veröffentlichung "Enterprise 2.0: The Dawn of Emergent Collaboration" sechs Komponenten von Enterprise 2.0 auf:[14]

1. Search: Die Benutzer müssen das, wonach sie suchen, auch finden können.
2. Links: Möglichst vielen Benutzern muss die Möglichkeit gegeben werden, Links zu setzen.
3. Authoring: Viele Menschen haben die Sehnsucht, selbst Autor zu sein bzw. einer großen Zielgruppe etwas mitzuteilen. Mit Hilfe von Blogs (kumulative Erstellung von Inhalten) und Wikis (iterative Erstellung von Inhalten) wird dies den Benutzern ermöglicht. Die Qualität der Inhalte bleibt dabei erstaunlicherweise hoch.
4. Tags: Im Gegensatz zu vordefinierten Kategorien können Inhalten Ein-Wort-Beschreibungen (sogenannte "Tags") zugeordnet werden, die von den Benutzern vergeben werden. Auch wenn diese teilweise redundant und nicht multidimensional sind, haben sie den Vorteil, dass tatsächlich gegebene Zusammenhänge und Strukturen verwendet werden statt Vordefinierte, die eventuell gar nicht gebräuchlich sind.
5. Extensions: Bei Extensions geht es um automatisierte Vorschläge, basierend auf den aktuell besuchten Seiten. Ein bekanntes Beispiel hierfür ist das Amazon Empfehlungssystem.
6. Signals: Um über relevante, neu eingestellte Inhalte benachrichtigt zu werden, sind sogenannte Signale erforderlich, möglichst per RSS (Really Simple Syndication) statt per E-Mail.

Auf diese Komponenten wird im Rahmen der Definition von Enterprise Social Software weiter unten Bezug genommen.

Nach McAfee sind eine offene Unternehmenskultur sowie eine gemeinsame Plattform ebenso notwendig, wie die Einbeziehung der Mitarbeiter und die Unterstützung der Geschäftsführung.[15] Ebenso muss aber jedes Unternehmen individuell seine Stärken und Schwächen identifizieren und bei dem Einsatz von Enterprise Social Software berücksichtigen.[16]

Koch und Richter grenzen Social Software von Groupware grundsätzlich wie folgt voneinander ab:[17]

Groupware legt den Fokus auf eine vereinfachte Zusammenarbeit aller Beteiligten einer Organisation oder eines Teams, während Social Software auf eine hohe Benutzbarkeit zur Unterstützung von sozialen Netzwerken sowie der Unterstützung von Gemeinschaften abzielt. Ebenso wird für Social Software ein größerer Personenkreis der Interaktionspartner angegeben.

Groupware ist eher top-down-orientiert, während Social Software als bottom-up gesehen werden kann. Es werden bei Social Software also Funktionalitäten durch die Software bereitgestellt, aber dem Anwender überlassen, wie diese genutzt werden, während bei Groupware sehr viel vorgegeben bzw. erzwungen wird und die Teams vorab zusammengestellt werden. Es ist somit selten eine Selbstorganisation gegeben.

Die Erkenntnisse von McAfee sowie Koch und Richter werden im Konzeptteil dieser Arbeit (Kapitel 6) nochmals aufgegriffen.

Eine für die Europäische Kommission erstellte Studie zum Thema "Enterprise 2.0" versteht unter einem Komplettpaket im Bereich Enterprise 2.0 Tools zur Identifikation von Experten, Auffinden/Kennzeichnen/Teilen von nützlichen Informationen sowie der gemeinsamen Erstellung von Inhalten in Wikis. Ebenso muss eine gemeinsame Wissensbasis gegeben sein und eine Verlinkung der Inhalte untereinander ermöglicht werden.[18]

Eine Zuordnung zu den von McAfee genannten Komponenten zeigt, dass durch die Definition des Komplettpaketes die Komponenten "Search", "Links", "Authoring" sowie "Tags" abgedeckt werden. Hingegen werden "Extensions" und "Signals" nicht explizit abgedeckt. Für die Definition eines Komplettpaketes im Rahmen dieser Arbeit werden somit ebenso eine RSS Unterstützung sowie automatisierte Vorschläge basierend auf besuchten Seiten aufgenommen.

Zur konkreten Charakterisierung ordnen Koch und Richter Social Software die Anwendungsklassen Blogs (Microblogs und Weblogs), Wikis sowie Gruppeneditoren, Social Bookmarking/Tagging/Networking Dienste und Instant Messaging zu.[19]

Die von Koch und Richter genannten Anwendungsklassen für Social Software werden im Rahmen dieser Arbeit auch für Enterprise Social Software übernommen, mit Ausnahme von Gruppeneditoren, da diese bereits Groupware zugeordnet sind.

Eine Kombination der 2006 von McAfee aufgestellten Begriffsbestimmung und Komponentenerläuterung mit den modifizierten Zuordnungen von Koch und Richter sowie einer für die Europäische Kommission erstellten Studie (inkl. genannter Ergänzungen) ergibt für diese Arbeit folgende Definition:

Unter Enterprise Social Software werden folgende Tools verstanden, welche in der Regel kombiniert werden oder im besten Fall in einer Komplettlösung abgedeckt sind:

Identifizieren von Experten durch Social Networking, unterstützt durch automatisierte Vorschläge basierend auf besuchten Seiten

Auffinden von Inhalten durch eine übersichtliche Gestaltung, automatisierter Vorschläge basierend auf besuchten Seiten sowie eine integrierte Suchfunktion für Blog und Wiki Kennzeichnen mit Hilfe von Social Tagging kumulatives Teilen von nützlichen Informationen durch Blog und Social Bookmarking inkrementelles, gemeinsames Erstellen von Inhalten durch Wikis Hierbei müssen die Inhalte untereinander verlinkt werden können, auf neue oder geänderte Inhalte durch RSS Unterstützung hingewiesen werden und eine gemeinsame Wissensbasis besitzen. Als Ergänzung zu den oben genannten Tools dient für eine eilige schriftliche Kontaktaufnahme Instant Messaging.

Die genannten Tools können hierbei sowohl innerhalb Firmen (intern) als auch zwischen Firmen und ihren Geschäftspartnern (extern) eingesetzt werden.

Tabelle 1 zeigt die sich aus der Definition entsprechende Abgrenzung im Kontext dieser Masterarbeit zwischen Groupware (Abschnitt 2.1) und Enterprise Social Software:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Groupware vs. Enterprise Social Software

Im Folgenden wird eine Fallstudie im Bereich Enterprise Social Software betrachtet, die als Grundlage für Abschnitt 3.5.5 verwendet wird. Die betrachtete Firma der Fallstudie ist die ABB AG aus der Schweiz, die im Bereich Automatisierungs- und Energietechnik tätig sind und Blogs sowie Wikis einsetzen. Die Nutzeranzahl beträgt 180 und die Datenerhebung fand von Mai bis November 2009 statt. Zur erfolgreichen Nutzung und Implementierung haben diverse Faktoren geführt, die im Folgenden erläutert werden. Mit Hilfe einer Wiki-Tour wurde eine große Zielgruppe angesprochen und zur Nutzung animiert. Ebenso erwies sich eine Beratung und Motivation potentieller Meinungsmacher als sinnvoll, da diese als Multiplikatoren dienten. Des Weiteren wurden kompetente Mitarbeiter zur Sicherstellung der Informationsvalidität ausgewählt, sie betreuten sozusagen indirekt die Benutzer durch die Vermittlung einer Sensibilität bezüglich der Daten. Außerdem trug eine Kombination aus dem Feedback der Anwender und regelmäßiger Besprechungen zwischen der Kommunikationsabteilung und der „Trendschmiede-Mitglieder“ zur kontinuierlichen Optimierung der Lösung bei. Zusätzlich wurde die Nutzerakzeptanz positiv durch eine weitestgehend offene Unternehmenskultur beeinflusst, ebenso wie durch die aktive Software-Nutzung des Managements. Diese zeigte sich durch das Verfassen von Beiträgen sowie die Reaktion auf Inhalte. Außerdem wurde vom Management die Software-Verbreitung unterstützt. Abschließend sind noch systembezogene Faktoren sowie ein externer Faktor als Erfolgsfaktoren zu erwähnen. Systembezogen war die Wiki-Anbindung an den Newsletter und Blog, die Befüllung mit Inhalten sowie die Einrichtung abgetrennter Projekträume. Der externe Faktor ist die Medienpräsenz von „Web 2.0“, was zu Interesse und Aufgeschlossenheit führte.[20]

2.3 Agiles Projektumfeld

Eine vom Massachusetts Institute of Technology (MIT) in 2014 veröffentlichte Studie zeigt auf, dass 28% der betrachteten Projekte eine agile Methode verwendeten. Die drei größten Sektoren dieser agilen Projekte sind die Software-Industrie (37%), Finanzdienstleistungen (15%) sowie die Beratung (10%).[21]

Die Studie basiert auf 856 ausgefüllten Fragebögen, die Teilnehmer waren „Professionals" und stammen aus 76 Ländern.[22] Die Ergebnisse zeigen, dass agile Praktiken unabhängig von dem Innovationsgrad und der Produkttypen eingesetzt werden und nicht nur in Industrien mit Fokus auf Software. Daher muss die Theorie der Agilität weiter untersucht werden.[23]

Im Bereich der Softwareentwicklung existiert gegenüber dem klassischen Projektmanagement im agilen Projektmanagement keine starre Planung, da Flexibilität bedeutsam ist. Klassische Vorgehensmodelle werden nicht ausgeschlossen aber auch nicht befürwortet. Es geht vielmehr um Best Practices und kurze, iterative Entwicklungsinkremente.[24]

Während der Mensch im klassischen Projektmanagement eine Ressource darstellt, steht er im agilen Umfeld im Mittelpunkt bzw. wird als Haupterfolgsfaktor gesehen.[25]

Die Studie des MIT sieht ein agiles Management, nicht nur bezogen auf den Softwarebereich, als „an approach based on a set of principles whose goal is to render the process of project management simpler, more flexible and iterative in order to achieve better performance (cost, time and quality), with less management effort and higher levels of innovation and value added for the customer".[26]

Es wird somit sowohl im Bereich der Softwareentwicklung als auch allgemein bezogen auf ein agiles Management die Flexibilität sowie die iterative Vorgehensweise hervorgehoben. Als Ziele werden in obenstehender Definition des MIT eine bessere Performance, ein höherer Innovationsgrad sowie ein gesteigerter Mehrwert für den Kunden trotz weniger Management-Aufwand genannt.

Im Rahmen dieser Masterarbeit wird daher unter einem agilen Projektumfeld ein Projektmanagement mit Fokus auf Flexibilität und Iteration verstanden.

Basierend auf der Studie zieht das MIT folgende allgemeine Schlussfolgerungen (im Folgenden mit "S" abgekürzt) für ein agiles Projektmanagement, die für Kapitel 6 relevant sind:

Agilität ist besonders bei innovativen Projekten (S1) ausschlaggebend und nicht unbedingt eine Frage der Methodik, sondern eher der Kompetenz (S2). Ebenso ist Flexibilität (S3) ein Kernelement von Agilität, da Änderungen an der Tagesordnung sind. Neben einer einfachen Umsetzung (S4) von Praktiken, Tools und Prozessen sind auch eine Selbstorganisation (S5) in den Projektteams sowie ein hybrides Framework (S6), das auf verschiedene Arten von Projekten ausgerichtet ist, erforderlich.[27]

Ebenso spielen individuelle Kompetenzen (S7) wie beispielsweise eine positive Einstellung gegenüber Herausforderungen in Veränderungen eine Rolle. Außerdem sind Erfahrungen mit gleichen oder ähnlichen Projekten (S8), sowie eine Interaktion im Team (S9), die wiederum abhängig von der Teamgröße (S10) ist, erforderlich. Des Weiteren sind eine Kollaboration (S11) im Team sowie iterative Problem-Lösungsprozesse (S12) und die Einbeziehung von Stakeholdern (S13) sehr bedeutend.[28]

Da im Rahmen des Experiments (Kapitel 3) der agile Prozess Kanban verwendet wird, wird im Folgenden Kanban im Softwareumfeld betrachtet.

Aus einer in 2013 veröffentlichten systematischen Literaturrecherche mit dem Thema "Kanban in software development: A systematic literature review" geht hervor, dass Kanban in der Softwareentwicklung erstmals von David J. Anderson im Jahre 2004 im Rahmen eines IT-Projekts bei Microsoft entstand.[29]

Kanban in der Softwareentwicklung kann in verschiedene Praktiken eingeteilt werden:

1. Visualisierung: Auf einem Kanban-Board werden mit Hilfe von Signalkarten Anforderungen visualisiert und in verschiedene Phasen der Wertschöpfungskette eingeordnet. Je Phase gibt es eine mengenmäßige Begrenzung an Anforderungen.[30]
2. Begrenzung nicht abgeschlossener Arbeit: Die Anzahl nicht abgeschlossener Arbeiten wird je Zustand limitiert.[31]
3. Überwachung und Steuerung des Flusses: Durch die Überwachung und Steuerung des Flusses soll ein schneller und gleichmäßiger Fluss sichergestellt werden.[32]
4. Eindeutige Richtlinien: Richtlinien müssen eindeutig definiert sein, um Prozessverbesserungen durchführen zu können.[33]
5. Feedback-Schleifen: Durch Soll/Ist-Vergleiche können Prozessverbesserungen ermöglicht werden. Eine der vier spezifischen Feedback-Praktiken ist das Operations Review.[34]

Die spezifische Praktik Operations Review wird im Rahmen des Experiments (Kapitel 3) verwendet, weshalb hierauf näher eingegangen wird. Zum besseren Verständnis wird im Folgenden zuerst die Retrospektive betrachtet, bevor das Operations Review erläutert wird.

Ein regelmäßiges Treffen aller Team-Mitglieder sowie gegebenenfalls weiterer relevanter Personen in der Wertschöpfungskette zur Identifizierung von Ballast mit einer Zeitbegrenzung von 1 Stunde wird als Retrospektive bezeichnet. Zu beachten gilt, dass es hier nicht um eine inhaltliche Abstimmung geht.[35] Eine Retrospektive wird als Operations Review bezeichnet, wenn Veränderungen der Unternehmenskultur und Arbeitspraktiken institutionalisiert werden sollen, um Vertrauen aufzubauen, Prozessverbesserungen voranzutreiben und Transparenz zu schaffen.[36]

6. Experimentelle Entwicklung und kollaborative Verbesserung: Modelle in Kombination mit wissenschaftlichen Methoden ermöglichen kollaborativ, Auswirkungen von Änderungen besser zu prognostizieren.[37]

2.4 Kommunikationseffizienz

Bei der Effektivität geht es um Leistungsanforderungen, während Effizienz den wirtschaftlichen Grad eingesetzter Ressourcen des Unternehmens zum Erreichen der Leistungsanforderungen berücksichtigt.[38]

Das Wirtschaftlichkeitsprinzip, nach dem vorgegebene Ziele durch möglichst geringen Mitteleinsatz oder eine Maximierung angestrebter Ziele durch minimalen Mitteleinsatz erreicht werden sollen, wird durch Effizienz widergespiegelt. Hierbei werden sowohl monetäre als auch nicht-monetäre Kenngrößen berücksichtigt.[39]

Eine Literaturstudie, in der mehr als 180 Beiträge betrachtet wurden, weist den Begriff der Effizienz als Verhältnis zwischen Output und Input nach.[40]

Unter Kommunikationseffizienz wird im Rahmen dieser Masterarbeit daher eine auf Kommunikation bezogene Wirtschaftlichkeit verstanden, die den Output im Verhältnis zum Input darstellt. Der Output wird hier durch den Mehrwert der Kommunikation definiert, während der Input den Aufwand für die Kommunikation repräsentiert. Sowohl Output als auch Input müssen hierbei nicht ausschließlich monetär bewertbar sein.

3. Experiment

Im Folgenden werden allgemeine Rahmenbedingungen, der Versuchsaufbau und die Durchführung des Laborexperiments, das zur Überprüfung der Hypothese sowie zur Erstellung des Konzepts dient, beschrieben. Außerdem wird der zu dem Experiment gehörende Fragebogen erläutert.

3.1 Allgemeine Rahmenbedingungen

Das Laborexperiment wird im Rahmen der Master-Vorlesung „Kollaborative Business-Prozesse und -Systeme" an der Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt Abteilung Würzburg (Dozent: Prof. Dr. Hennermann) durchgeführt. Es werden in 6 Teams (insgesamt 24 Teilnehmer) verschiedene Kollaborations-Lösungen für einen Anwendungsfall einer Beispielfirma evaluiert. Gegen Semesterende wird die ausgewählte Lösung präsentiert. Es handelt sich bei der Aufgabenstellung um eine Modifizierung des Unternehmensplanspiels "Enterprise 2.0 - The Game" des "University Competence Center for Collaborative Technologies powered by IBM". Die Bearbeitung ist in 4 Arbeitspakete aufgeteilt. Das Experiment wird im Rahmen des Arbeitspaketes 3 durchgeführt und teilt sich in 2 Aufgaben (Task 1 und Task 2) auf. In Task 1 geht es um eine Auswahl von Enterprise Social Software Tools, die zusätzlich Bibliotheken und Workflows abdecken. Bei Task 2 muss die Bibliothek, die Tagging-Funktionalität und die Workflowfunktionalität simuliert werden.

Das Experiment startet am 13.05.2014 und endet am 17.06.2014. Die Veröffentlichung der Unterlagen zur Aufgabe 1 des Arbeitspaketes 3 erfolgt am 15.05.2014, Aufgabe 2 wird erst am 01.06.2014 veröffentlicht. Der Zeitraum vom 13.5. - 15.5. ist für das Lesen der Experiment-Vorgaben sowie die Software Einarbeitung vorgesehen.

An dem Experiment nehmen 23 männliche und 1 weiblicher Masterstudent(en) des Studiengangs "Informationssysteme" teil. Der geschätzte Altersdurchschnitt liegt bei circa 25 Jahren und die Gruppe besteht aus den Bachelorabschlüssen Wirtschaftsinformatik und Informatik, wobei es sich tendenziell um mehr Informatiker handelt. Einige Studenten haben vor dem Studium eine Berufsausbildung absolviert (häufig im IT-Umfeld), andere nicht. Im Bachelorstudium wurden beispielsweise Business Software, Business-Technologies oder andere Schwerpunkte belegt. Die im Rahmen des Experiments verwendeten Tools haben alle Teilnehmer schon einmal genutzt, mit Ausnahme von JIRA und Confluence, welche für die meisten komplett neu sind.

3.2 Problembeschreibung

Untersucht wird, ob sich die Kommunikationseffizienz durch den Einsatz von Enterprise Social Software für die interne Kommunikation im agilen Projektumfeld steigern lässt. Hierzu wird klassische Groupware (im Folgenden Szenario „Groupware") mit einer Kombination aus Enterprise Social Software und klassischer Groupware (im Folgenden Szenario „Enterprise Social Software") verglichen. Der Autor dieser Masterarbeit besitzt ein Masterkonto für die Überwachung der gesamten E-Mail-Kommunikation sowie vollen Zugriff auf die Inhalte des Projektmanagement-Tools sowie der Enterprise Social Software aller Gruppen. Dies wurde mit den Teilnehmern des Experiments abgesprochen.

3.3 Unabhängige und abhängige Variablen

Unabhängige Variablen:

Team-Zuteilung zu den Szenarien „Groupware" und „Enterprise Social Software"

Abhängige Variablen:

Anzahl an E-Mails

Zeitaufwand für virtuelle Besprechungen

3.4 Experiment-Aufbau

Um statt einer spontanen Face-to-face-Interaktion die Interaktion in Organisationen abzubilden, muss der Experimentaufbau so konzipiert sein, dass die Team-Mitglieder für den Zeitraum des Experiments in einer Art Organisation verbunden sind, um die notwendige Hierarchie-Akzeptanz und Zweckerfüllung widerzuspiegeln.[41]

Dies ist in dem hier beschriebenen Experiment der Fall, da je Team eine Hierarchie (Team-Leiter und Team-Mitglieder) und eine Zweckerfüllung (Aneignen von Kenntnissen, Erreichen einer guten Note usw.) gegeben sind.

Zu Beginn werden die Teams alphabetisch sortiert durchnummeriert: "antuprise" ist Team 1, "B3R" ist Team 2, "Business Information Architects AG" ist Team 3, "cometogether solutions" ist Team 4, "Palm Consulting" ist Team 5 und "Yogurt - IT-Consulting" ist Team 6. Durch Werfen eines Würfels wird die Zuteilung in Kontroll- und Experimentalgruppen randomisiert vorgenommen (eine geworfene Zahl 1,2 oder 3 bedeutet, dass Team 1 bis 3 zuerst in der Kontrollgruppe ist). Das Ergebnis des Würfelwurfes ist 2. Somit darf Team 1 bis 3 für die Kommunikation im Rahmen von Aufgabe 1 lediglich klassische Groupware einsetzen, während Team 4 bis 6 für Aufgabe 2 eine vorgegebene Enterprise Social Software in Kombination mit Groupware einsetzt. Bei Aufgabe 2 erfolgt ein Wechsel, d.h. Team 1 bis 3 arbeitet nun mit Enterprise Social Software kombiniert mit Groupware und Team 4 bis 6 mit klassischer Groupware. Durch den Wechsel soll sichergestellt werden, dass nicht eventuell vorhandene Unterschiede der Aufgabenschwierigkeit das Ergebnis verfälschen.

Um eine gewisse Gleichheit der Teams zwischen den Versuchs- und Kontrollgruppen sicherzustellen, wird zusätzlich das Parallelisieren angewandt. Hierzu werden dem Experiment entsprechende Tests vorgeschaltet. Vgl. Kühl (2009), Seite 541 In dem hier durchgeführten Experiment werden die Tests durch eine Analyse vorliegender Bewertungen ersetzt. Die Bewertungen wurden vom Dozenten für die Arbeitspakete 1 und 2 im Rahmen der Vorlesung durchgeführt. Gemäß Abbildung 3 ist erkennbar, dass sich die Summe von Team 1 bis 3 (116 Punkte) von der Summe von Team 4 bis 6 (111 Punkte) um insgesamt lediglich 5 Punkte (4,5%) und somit je Team im Durchschnitt um gerundet 1,7 Punkte unterscheidet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Team-Bewertung aus vorherigen Arbeitspaketen

Zusammenfassend ergibt sich folgende Aufteilung:

Aufgabe1:

Experimentalgruppen: Team 4,5,6

Kontrollgruppen: Team 1,2,3

Aufgabe 2:

Experimentalgruppen: Team 1,2,3

Kontrollgruppen: Team 4,5,6

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Aufteilung in Experimental- und Kontrollgruppen

3.5 Vorgaben an Experiment-Teilnehmer

In diesem Unterkapitel wird beschrieben, welche Vorgaben die Teilnehmer des Experiments bekommen haben. Es wurde darauf geachtet, im Vorfeld möglichst viel vorzugeben, um die Durchführung des Experiments einheitlich zu gestalten und die Qualität zu erhöhen.

3.5.1 Allgemeine Vorgaben

Im Rahmen des Experiments wird folgendes Szenario definiert: Jedes Team-Mitglied sitzt an einem anderen Standort. Aus diesem Grund ist es nicht erlaubt, vor Ort über das Projekt zu reden. Dies würde die Ergebnisse verfälschen. Falls vor Ort aus Versehen doch über das Projekt geredet wird, muss die Kommunikation nachträglich „abgebildet" (je nachdem per E-Mail oder in der Enterprise Social Software) und in der Zeiterfassung berücksichtigt werden.

Jedes Team hat das Arbeitspaket 3, das sich in 2 Aufgaben (je 10 Punkte) aufteilt, zu bearbeiten. Aufgabe 1 muss bis Ende Mai abgeschlossen sein, danach erfolgt der Start für Aufgabe 2.

3.5.2 Tool-Vorgaben

Als Projektverfolgungstool ist JIRA von der Firma Atlassian einzusetzen. Es werden hier auch Workflows ermöglicht. Somit wird in beiden Szenarien (Groupware vs. Enterprise Social Software in Kombination mit Groupware) JIRA verwendet. Da JIRA auch Elemente einer Enterprise Social Software hat, wurden diese für das Experiment deaktiviert. Ebenfalls ist durch Klick auf „Startseite" - „Dashboards verwalten" - „Populär" das „WP3-Dashboard" auszuwählen und zu den Favoriten hinzufügen (durch Klick auf „fügen Sie es den Favoriten hinzu"). Im Groupware-Szenario sind speziell dafür eingerichtete E-Mail-Adressen zu nutzen (vorname.nachname@mywue.de). Als E-Mail-Programm wird Thunderbird vorgegeben. Für Telefon/-Videokonferenzen ist von Google Hangout Gebrauch zu machen, allerdings darf im Groupware-Szenario die Chatfunktion nicht benutzt werden. Google Drive ist als Dokumentenmanagement-System zu verwenden, weitere Funktionalitäten von Google Drive sind nicht erlaubt. Jedes Team hat zur besseren Vergleichbarkeit die gleiche Enterprise Social Software einzusetzen. Hierzu wird Confluence von der Firma Atlassian verwendet. Die Einarbeitungszeit in Confluence ist nicht zu erfassen und wird somit für den Effizienzvergleich zwischen Groupware und Enterprise Social Software nicht berücksichtigt, da die Einarbeitungszeit kein kontinuierlicher Aufwand ist.

Die Nutzung von Confluence hat wie folgt zu erfolgen: Foren für die Abstimmung im Team, unterteilt in verschiedene Themen. Wiki als „Notizblock" für Ideen, zur Fehlerprotokollierung der Qualitätssicherung und als Grundlage für Operation Reviews. Nachrichten an eine Person sind in Confluence nicht möglich und sollten ohnehin vermieden werden, falls diese trotzdem notwendig sind, hat dies per E-Mail zu erfolgen. Im Enterprise Social Software Szenario ist die Chatfunktion von Google Hangout erlaubt und für eine eilige Kontaktaufnahme zu verwenden, falls dies nicht über das Telefon gewünscht ist. Der Chat-Verlauf ist in Confluence abzulegen.

Telefonate/Konferenzen (Videokonferenzen mit Google Hangout) sind für Diskussionen bzw. längere Unterhaltungen geeignet, müssen aber gemäß folgender Beispielvorlage protokolliert werden:

Datum: 20.05.14

Task: 1

Subtask: 1.1

Dauer in min.: 30

Diskussionspunkte: Klärung Anforderungen 30-33

Teilnehmer: Hans, Fritz

3.5.3 Kanban

Die Bearbeitung des Arbeitspaketes 3 hat agil zu erfolgen. Hierzu wird nach Kanban (siehe Abschnitt 2.3) vorgegangen. Hierzu steht ein für jedes Team eingerichtetes Kanban-Board in JIRA zur Verfügung. Nach Fertigstellung einer Teilaufgabe ist diese an den fiktiven Kunden, den Autor dieser Masterarbeit, zu schicken, um das frühe Feedback zu ermöglichen. Je nach Anwendungsfall hat dies per E-Mail oder Enterprise Social Software stattzufinden. Zur Visualisierung werden durch eine Einteilung in die Zustände „To-Do", „Execute", „Review", „Done". Mit „To-Do" werden alle Aufgaben repräsentiert, die noch zu erledigen sind, „Execute" zeigt auf, was in Bearbeitung ist, während „Review" die Aufgaben beinhaltet, die erledigt wurden aber noch in der Qualitätssicherung liegen. Erledigte Aufgaben werden in den Bereich „Done" verschoben. Durch hinterlegte Workflows erfolgt die Verschiebung automatisch.

Das maximale Limit gleichzeitiger Subtasks in „Execute" und „Review" liegt für Task 1 bei 4 (kann bei Bedarf erhöht werden) und wurde in den Kanban-Boards in JIRA entsprechend vorab konfiguriert.

Die Aufteilung in Subtasks muss im Team selbst zustande kommen. Dadurch kann jedes Team u.a. auch die Häufigkeit des Feedbacks selbst wählen (mehr Subtasks ergeben häufigere Feedback-Zyklen). Die Subtasks sollten vom Aufwand in etwa gleich groß sein.

Es hat ein regelmäßiges Statusmeeting (Vorgabe: 1x pro Woche) stattzufinden, in dem Lösungswege zu Problemen besprochen werden. Verteilt über das gesamte Arbeitspaket 3 sind zusätzlich insgesamt 2 Operations Reviews (Erläuterung im Abschnitt 2.3) durchzuführen, 1 je Aufgabe, möglichst in der Mitte der Bearbeitungszeit der jeweiligen Aufgabe. Hierfür dient das Wiki als Grundlage, da sowohl Positives als auch Negatives festgehalten werden muss. Die Qualitätssicherung deckt Fehler auf und protokolliert diese, behoben werden diese nicht von der Qualitätssicherung. D.h. der Ersteller eines Dokuments ist nicht der gleiche wie der QS-Beauftragte.

3.5.4 Zeiterfassung

Der Zeitaufwand ist auf der Teilaufgaben-Ebene zu erfassen. Anzugeben sind neben der Teilaufgaben-Bezeichnung die Tätigkeit sowie die Dauer in Minuten. Die Zeiterfassung hat ebenso für das Einlesen in die jeweilige Aufgabenstellung zu erfolgen.

Die Zeiterfassung muss bei Telefonaten und Konferenzen nicht zusätzlich erledigt werden bzw. wird durch die Spalte „Dauer in min." abgedeckt. Die allgemeine Zeiterfassung hat analog folgendem Beispiel zu erfolgen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Vorgaben und Zeiterfassung

Auch die Auftragsklärung, also die Abstimmung mit dem fiktiven Kunden diesbezüglich, ist zeitlich zu erfassen und die Kommunikation gemäß den entsprechenden Tool-Vorgaben vorzunehmen (je nachdem per E-Mail oder Confluence). Eventuell macht es hierfür Sinn, ebenfalls ein Subtask zu vergeben.

Es gibt keine Vorgabe, mit welchem Tool die Zeit zu erfassen ist, es empfiehlt sich allerdings eine App (beispielsweise die Google Play Anwendung „ Jiffy - Zeiterfassung") oder ein Online-Tool. Wird die Zeiterfassung vergessen, ist diese basierend auf einer Schätzung nachzuholen.

3.5.5 Unterstützung durch den Projektleiter

Basierend auf einer in Abschnitt 2.2 betrachteten Fallstudie wird in diesem Abschnitt die Art und Weise der Unterstützung durch den Projektleiter beschrieben.

Der Projektleiter ist zuständig für die Betreuung, Überwachung und Motivation in Bezug auf die Enterprise Social Software und hat im Umgang mit der Software eine Vorbildfunktion, um Akzeptanz und Vertrauen im Umgang mit der Software zu erzeugen. Die Notwendigkeit doppelter Dateneingaben ist zu vermeiden.

Bei Unklarheiten ist der Autor der Masterarbeit zu kontaktieren (zuständig: Projektleiter), damit dieser eventuell noch fehlende Standards für alle Gruppen definieren kann.

3.5.6 E-Mail-Benachrichtigungen

E-Mail-Benachrichtigungen aus Confluence, JIRA und Google Drive/Hangout sind für alle Szenarien zu deaktivieren bzw. automatisiert auszufiltern, um besonders im Enterprise Social Software Szenario keine „alternative" E-Mail-Flut zu bekommen und um gleichzeitig im Rahmen des Experiments zu beweisen, dass dies nicht erforderlich ist.

[...]


[1] Vgl. IDC (2013)

[2] Vgl. Herzog et al. (2014), Seite 10

[3] Vgl. IDC (2013)

[4] Vgl. Kühl (2009), Seite 534 ff.

[5] Vgl. Kühl (2009), Seite 554

[6] Johansen (1988), Seite 1

[7] Opper, Fersko-Weiss (1991), Seite 4

[8] Lewe, Krcmar (1991), Seite 1

[9] Finke (1992), Seite 25

[10] Vgl. Koch, Richter (2009), Seite 17

[11] Vgl. Lembke, Soyez (2012), Seite 197

[12] Vgl. Lembke, Soyez (2012), Seite 209

[13] McAfee (2006b)

[14] Vgl. im Folgenden McAfee (2006a), Seite 23-25

[15] Vgl. McAfee (2006a), Seite 26-28

[16] Vgl. Koch, Richter (2009), Seite 15 f.

[17] Vgl. im Folgenden Koch, Richter (2009), Seite 20

[18] Vgl. Osimo et al. (2010), Seite 15

[19] Vgl. Koch, Richter (2009), Seite 13

[20] Vgl. Steinhüser, Räth (2010), Seite 1f. und 12f.

[21] Vgl. Conforto et al. (2014b), Seite 14

[22] Vgl. Conforto et al. (2014b), Seite 8

[23] Vgl. Conforto et al. (2014b), Seite 22

[24] Vgl. Trepper (2012), Seite 106

[25] Vgl. Trepper (2012), Seite 103

[26] Conforto et al. (2014a), Seite 2

[27] Vgl. Conforto et al. (2014b), Seite 19

[28] Vgl. Conforto et al. (2014b), Seite 21

[29] Vgl. Ahmad, Markkula, Oivo (2013), Seite 10

[30] Vgl. Epping (2011), Seite 115 und Vgl. Anderson (2014)

[31] Vgl. Anderson (2014)

[32] Vgl. Anderson (2014)

[33] Vgl. Anderson (2014)

[34] Vgl. Anderson (2014)

[35] Vgl. Epping (2011), Seite 125 f.

[36] Vgl. Anderson (2007)

[37] Vgl. Anderson (2014)

[38] Vgl. North, Güldenberg (2008), Seite 106

[39] Vgl. Schwarz (2012), Seite 9

[40] Vgl. Ahn (2003), Seite 90 ff.

[41] Vgl. Kühl (2009), Seite 537 f.

Details

Seiten
129
Jahr
2014
ISBN (eBook)
9783656858362
ISBN (Buch)
9783656858379
Dateigröße
2.7 MB
Sprache
Deutsch
Katalognummer
v285852
Institution / Hochschule
Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt
Note
1,0
Schlagworte
Enterprise 2.0 Enterprise Social Software Agil Agiles Projektmanagement Experiment Enterprise Web 2.0 Social Software für Unternehmen Kommunikationseffizienz Social Networking Services für Unternehmen Social Media für Unternehmen Enterprise Social Networks Web 2.0 für Unternehmen Kanban IT Experiment Confluence Effizienzmessung Masterarbeit Enterprise Social Software

Autor

Teilen

Zurück

Titel: Untersuchung des Einsatzes und der Auswirkungen von Enterprise Social Software im agilen Projektumfeld