Entwicklung eines Einführungsplans für SharePoint und CRM in mittelständischen Unternehmen

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Entwicklung eines Einführungsplans für SharePoint und CRM in mittelständischen Unternehmen Masterarbeit im Studiengang Informatik von Mandy Weingartner Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Joel Greenyer Betreuer: Stephan Kiesling Hannover, 26. Mai 2015

2

3 Zusammenfassung Zusammenfassung Um die Produktivität und Performanz zu erhöhen setzen immer mehr Unternehmen Software ein, um die internen Prozesse zu unterstützen. Die Anbieter solcher Unternehmenssoftware versprechen die Zusammenarbeit der Teams zu revolutionieren, die Geschäftsprozesse transparent zu machen und Ordnung in die Dokumentenablage zu bringen. Unternehmen die sich dann dazu entscheiden, solche Systeme einzusetzen, werden nach der Einführung der Systeme oftmals enttäuscht. Die Akzeptanz bei den Benutzern bleibt aus, die Ordnung in der Dokumentenablage stellt sich nicht ein und die versprochene Transparenz bleibt aus. In dieser Arbeit werden zwei Systeme mit verschiedenen Schwerpunkten analysiert und eine Methode erarbeitet, den Anforderungen von mittelständischen Unternehmen gegenüber zu stellen. Zur Anforderungserhebung wurden vertriebliche und technische Vertreter der analysierten Systeme interviewt. In diesen Interviews konnten auch Gründe für die geringe Benutzerakzeptanz ermittelt werden. Unter Verwendung der Ergebnisse der Systemanalyse und Anforderungserhebung wurde ein semantisches Verfahren beschrieben, um die Systemfunktionen mit den Benutzeranforderungen zu vergleichen. Dieses Verfahren wurde in der Konzeptionierung eines Anforderungskatalogs genutzt. Der Anforderungskatalog soll dazu genutzt werden können, durch Auswahl von Anforderungen einen Systemvorschlag zu erhalten. Durch eine weitere Auswertung der Interviews nach Grounded Theory wurden Gründe ermittelt, warum die Benutzerakzeptanz gering ist. Diese und die Ergebnisse aus Systemanalyse und Anforderungserhebung wurden genutzt, um einen Plan zu erstellen, wie die Einführung der Systeme erfolgreicher gestaltet wird. Dabei werden verschiedene Schablonen und Vorlagen der Projektplanung genutzt und für die Einführung, Anpassung und Bereitstellung der Systeme angepasst und erweitert. Diese angepassten Projektplanschablonen sind nicht nur für die zwei behandelten Systeme nutzbar, sondern sind auch weitestgehend für ähnliche Systeme, die zusätzlich vorgestellt werden, verwendbar

4

5 Abstract Abstract More and more companies are using software to support their internal processes to increase their efficiency and productivity. The suppliers of these software products promise to revolutionize the collaboration between teams, the transparency of work processes and the organization of the depot of records. Companies that start using this advertised software products are often disappointed. The complete acceptance of the users never happens, the promised transparency is blurry and the files never get organized. In this research paper two systems with different focus will be analyzed and a method developed to contrast the requirements of medium-sized companies. Sales related employees and technical representatives have been interviewed to construct the requirements. These interviews have also shown reasons for the missing acceptance of the users. Using the results of the system analysis and the requirements engineering a semantic procedure has been characterized to compare the system functions with the user requirements. This procedure has been used to create a concept of a requirements specification. The requirements specification should be used to generate a system proposal by selecting the specific needs. By an additional evaluation of the interviews with the Grounded Theory further reasons why the user acceptance is so low could be established. All of these results have been utilised to create a proposition, how launching those systems could be more successful. Different templates of the project design have been used to adapt and to enhance the implementation, designation and customization of the systems. These customized project plan templates can not only be used for the two systems analysed in this paper, furthermore they may be used for any similar systems - 5 -

6

7 Inhaltsverzeichnis Inhaltsverzeichnis Zusammenfassung Abstract Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Aufbau der Arbeit Problemstellung Forschungsfragen Aufbau der Arbeit Grundlagen Mittelstand SharePoint Dynamics CRM Anwendungsbereiche von SharePoint und Dynamics CRM Dokumentenmanagement Kollaboration Business Intelligence Geschäftsprozesse Experteninterviews Theoriegenerierung Grounded Theory Heuristische Sozialforschung Projektmanagement On-site Customer Iterative Entwicklungsmethode Ontologien Systemanalyse SharePoint Dynamics CRM Arbeiten im Vertrieb

8 Inhaltsverzeichnis Arbeiten im Marketing Arbeiten im Kundenservice Gemeinsamkeiten der Systeme Zusammenfassung der Funktionen Reflexion Zielgruppenanalyse und Anforderungserhebung Das Interview Vorbereitung des Interviews Samplings Erstellung des Leitfadens und Durchführung der Interviews Auswertung der Interviews Zielgruppenanalyse Anforderungserhebung Reflexion Erstellung des Anforderungskatalogs Erstellung der Ontologie Erstellen der SPARQL-Abfragen Konzept des Anforderungskatalogs Benutzeroberfläche Berechnung des Deckungsbereichs Programmaufbau des Prototypen Reflexion Akzeptanzanalyse Auswahl der Methode Vorgehen nach Grounded Theory Ergebnisse der Grounded Theory Reflexion Erstellung des Projektplans Wichtige Projektrollen Einführungsvorgehensweisen Grobplanung Projektphasenmodell

9 Inhaltsverzeichnis Projektstrukturplan Feinplanung Erstellen des Zeitplans Erstellen des Ressourcenplans Realisierungsphasen Verwandte Systeme Alternativen zu Microsoft SharePoint IBM Notes SAP NetWeaver Portal Zusammenfassung Alternativen zu Microsoft Dynamics CRM SAP Business ByDesign Salesforce CRM Zusammenfassung Verwandte Arbeiten Fazit Kritische Würdigung Ausblick Literaturverzeichnis Anhang A Charakterisierung von Klein-, Mittel- und Großbetrieben Anhang B Funktionsliste Anhang C Interviewdokumente Anhang D Liste der Anforderungen gruppiert nach Themengebieten Anhang E Tripel der Funktionsontologie Anhang F Codes zur Theoriegenerierung Anhang G Kausalketten der Benutzerakzeptanz

10 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1.1: Aufbau der Arbeit Abbildung 2.1: Dokumentenmanagement-Pyramide Abbildung 2.2: Überblick der Business Intelligence Bereiche Abbildung 2.3: Zyklus der Grouded Theory Abbildung 2.4: Begriffliche Erklärung des Projektmanagements Abbildung 2.5: Darstellung des On-site Customers Abbildung 2.6: Spiralmodell Abbildung 2.7: Beispielgraph einer Ontologie Abbildung 3.1 Webanwendung im SharePoint Abbildung 3.2 Dynamics CRM-Klassendiagramm Vertrieb Abbildung 3.3 Dynamics CRM-Aktivitätsdiagramm Vertrieb Abbildung 3.4 Dynamics CRM-Klassendiagramm Marketing Abbildung 3.5 Dynamics CRM-Klassendiagramm Kundenservice Abbildung 5.1: Klassendiagramm der konstruierten Ontologie Abbildung 5.2: schematische Darstellung des Prototyps Abbildung 5.3: Pseudocode für die Berechnung des Deckungsbereichs Abbildung 5.4: Model-View-Controller-Pattern Abbildung 5.5: Modell des Prototyps Abbildung 5.6: Controller des Prototyps Abbildung 5.7: Schnittstellen des Prototyps Abbildung 5.8: EER-Modell der Datenbasis des Prototyps Abbildung 6.1: Gruppierung der Codes Abbildung 6.2: Graph der Kausalketten Abbildung 7.1: Projektorganisation für Systemeinführungen Abbildung 7.2: Projektphasenmodell Abbildung 7.3: Realisierungsphase im Projektphasenmodell Abbildung 7.4: Projektstrukturplan Abbildung 7.5: Muster für Arbeitspaketbeschreibungen Abbildung 7.6: Netzplanbeispiel Abbildung 7.7: Ressourcenplan

11 Abbildungsverzeichnis Abbildung 7.8: Projektstrukturplan für eine Iteration Abbildung 8.1: Aufbau von SAP NetWeaver Abbildung 8.2: SAP CRM Portfolio Abbildung 8.3: Anwendungsbereiche des Salesforce CRM Abbildung 8.4: Lebenszyklus der Entitäten in Salesforce CRM

12 Tabellenverzeichnis Tabellenverzeichnis Tabelle 2.1: Aufteilung in Klein-, Mittel- und Großbetriebe nach EU-Kommision Tabelle 2.2: betriebsgrößenrelevante Merkmale Tabelle 2.3: Gliederung von Experteninterviews Tabelle 3.1: SharePoint Listenvorlagen Tabelle 3.2: SharePoint Bibliotheksvorlagen Tabelle 3.3: SharePoint Websitevorlagen Tabelle 3.4: Gemeinsamkeiten und Unterschiede der Systeme Tabelle 3.5: quantitatives Ergebnis der Funktionsanalyse Tabelle 4.1: Ergebnisse der Zielgruppenanalyse Tabelle 7.1: Vor- und Nachteile der Einführungsvorgehensweisen Tabelle 7.2: Zieldefinitionen der nicht iterativen Projektphasen Tabelle 8.1: Vergleich zwischen SharePoint Systemen Tabelle 8.2: Vergleich zwischen CRM Systemen

13 Aufbau der Arbeit 1 Aufbau der Arbeit Die Einführung von Unternehmenssoftware verspricht große Veränderung und Erfolg für die Unternehmen. Dazu gehört ein Dokumentenmanagementsystem, welches Ordnung in die Ablagen bringt, ein Kollaborationstool, wodurch die Mitarbeiter zusammen an Projekten arbeiten und ein Business Intelligence Werkzeug, welches veranschaulicht wie hoch die Umsätze im letzten Quartal waren. Zusätzlich können in dieser Software auch Geschäftsprozesse unterstützt werden. SharePoint und CRM können miteinander kombiniert diese Versprechen erfüllen. Doch die Veränderungen und Erfolge bleiben bei Unternehmen, welche diese Systeme einführen, oftmals aus. In dieser Arbeit geht es darum, welche Anwendungsbereiche die Systeme SharePoint und CRM haben, welche Anforderungen mittelständische Unternehmen daran stellen und wovon die Akzeptanz der Benutzer abhängt. Diese gewonnenen Informationen werden abschließend genutzt, um einen Projektplan zur Einführung von SharePoint und CRM in mittelständische Unternehmen zu erstellen. 1.1 Problemstellung Es gibt Expertentheorien, warum SharePoint und CRM eine geringe Nutzerakzeptanz haben. Melanie Schmidt erläutert in der Einleitung ihres Buches SharePoint 2013 Praxisbuch für Anwender warum die Einführung eines SharePoint-Systems scheitern kann. Um einen Erfolg der Einführung gewährleisten zu können, müssen folgende Punkte beachtet werden: - Die Struktur und der Aufbau des Systems müssen zu dem Rechte- und Rollenkonzept passen. - Fachabteilungen und Teams sollten ihre alltäglichen Prozesse mit einbringen können. Auch Betriebs- und Personalrat, sowie Datenschutzbeauftragte sind für die Planung des SharePoints sehr wichtig. - SharePoint-Projekte unterscheiden sich stark voneinander. Eine Schulung der Anwender auf die umgesetzten Prozesse und Berechtigungen hat immer zu erfolgen. - Die Benutzer sollten langsam, in kleinen Schritten und mit richtigen Szenarien an SharePoint herangeführt werden. (vgl. Schmidt, 2013, S. 3ff) Der CRM-Experte Edgar Reh hat in der Zeitschrift Computerwoche eine ähnliche Liste für CRM Systeme aufgestellt. Folgende Punkte sind für diese Arbeit interessant: - Einige Unternehmen wollen mit der Einführung eines CRM-Systems alle Probleme auf einmal lösen, dabei ist es für den Benutzer angenehmer, wenn er sich nach und nach an immer einen neuen Prozess gewöhnen muss, statt seine Arbeit einmal von Grund auf zu ändern. - Es sind einheitliche Regeln zu definieren, nach denen die Benutzer auf Daten zugreifen können

14 Aufbau der Arbeit - Fachabteilungen und Teams müssen ihr Wissen und ihre Prozesse in der Planung und Umsetzung des Systems mit einbringen. Die Techniker wissen nur in den wenigsten Fällen wie das tägliche Geschäft der Vertriebler aussieht. - Es muss schon zu Beginn der technischen Umsetzung eine klare Prozessplanung stehen. Auch die Verhaltensregeln für die Datenverwaltung sind zu Beginn zu definieren. (vgl. Reh, 2011): Die Schwierigkeiten der Umsetzung sind bei beiden Systemen vergleichbar, obwohl die Kernanwendungsbereiche unterschiedlich sind. Zusammengefasst können folgende Sachverhalte Gründe für das Scheitern eines SharePoint- oder CRM-Projekts sein: - Vom Umsetzungsteam wird die Struktur und der Aufbau des Systems nicht vollständig geplant. - Den Benutzern ist nicht klar, wofür und wie die Systeme genutzt werden können. - Die Bereitstellung erfolgt als Komplettpacket, welches oft zu umfangreich für einen schnellen Einstieg ist. - Die Benutzer werden bei der Anforderungsanalyse nicht ausreichend eingebunden. Diese Schwierigkeiten der Einführung werden durch Analysen und Interviews geprüft. Anhand der Ergebnisse wird ein Projektplan, für die erfolgreiche Einführung von Unternehmenssoftware, speziell am Beispiel SharePoint und CRM, erstellt. Einer der Kernpunkte dieses Projektplans soll die Anforderungsanalyse mithilfe eines Anforderungskatalogs sein. 1.2 Forschungsfragen Um einen Projektplan zu erstellen, welcher der erfolgreichen Einführung der Systeme dient, werden folgende Forschungsfragen geklärt: RQ1: RQ2: Welche Schritte sind bei der Einführung der Systeme von Bedeutung? Welche Projektmanagementmethoden sind für die Einführung der Systeme geeignet? Auch der Anforderungskatalog kann nicht ohne die Klärung folgender Forschungsfragen erstellt werden: RQ3: RQ4: RQ5: Welche Eigenschaften besitzen Unternehmen, die erfolgreich mit SharePoint und Dynamics CRM arbeiten? Wie muss ein Anforderungskatalog für solche Systeme aufgebaut sein? Wie kann entschieden werden, welche Anforderungen durch die Systeme umgesetzt werden?

15 Aufbau der Arbeit RQ4 wird zur besseren Bearbeitung in folgende Forschungsfragen aufgeteilt: RQ4.1: RQ4.2: RQ4.3: Welche Funktionen haben die Systeme? Welche Anforderungen haben mittelständische Unternehmen? Wie können die Funktionen und Anforderungen miteinander verglichen werden? Die Akzeptanz der Benutzer, die auch einen wichtigen Teil der erfolgreichen Integration der Systeme bildet, kann nicht ohne die Klärung folgender Forschungsfragen erläutert werden: RQ6: 1.3 Aufbau der Arbeit Warum ist die Benutzerakzeptanz dieser Systeme so gering? Zur Beantwortung der Forschungsfragen ist die Arbeit in 7 Teile gegliedert. (vgl. Abbildung 1.1) Grundlagen Systemanalyse Zielgruppenanalyse Anforderungserhebung Anfoderungskatalog Akzeptanzanalyse Projektplan Abbildung 1.1: Aufbau der Arbeit Das Kapitel Grundlagen dient dazu, ein Überblick über die in der Arbeit behandelten Themen zu erhalten. Die in den Grundlagen angeschnittenen Systeme Microsoft SharePoint 1 und 1 Im Folgenden SharePoint genannt

16 Aufbau der Arbeit Microsoft Dynamics CRM 2 werden im Kapitel Systemanalyse wieder aufgegriffen, erläutert, verglichen und auf die einzelnen Funktionen hin untersucht. Die Teile Zielgruppenanalyse und Anforderungserhebung sind in Kapitel 4 zusammengefasst. Es beschreibt die Experteninterviews, die zur Datenerhebung genutzt und die qualitative Inhaltsanalyse, mit deren Hilfe die Daten ausgewertet wurden. Aus den erhobenen Daten wurden die Eigenschaften der Zielgruppen sowie die Anforderungen von mittelständischen Unternehmen herausgezogen und ausgewertet. Anhand der Ergebnisse der System- und Zielgruppenanalyse sowie der Anforderungserhebung wurde in Kapitel 5 der Anforderungskatalog erstellt. Dabei wird ein semantischer Ansatz genutzt, indem die Systeme über eine Ontologie repräsentiert und die Anforderungen über SPARQL-Abfragen geprüft werden. Kapitel 6 ist die Akzeptanzanalyse, welche auf den Interviews in Kapitel 4 aufbaut. Für die Definition der Faktoren, die sich auf die Benutzerakzeptanz auswirken, wurden die Interviews nach Grounded Theory ausgewertet. Diese Ergebnisse und der Anforderungskatalog werden in Kapitel 7 aufgegriffen, um den Projektplan für die Einführung der Systeme zu erstellen. Dazu werden verschiedene Ansätze der Projektplanung genutzt, zusammengefügt und angepasst. In Kapitel 8 werden Systeme neben SharePoint und Dynamics CRM vorgestellt, auf welche die Ergebnisse dieser Arbeit ebenfalls angewendet werden können. Als Ausblick in ähnliche Forschungsthemen dient Kapitel 9. Den Schluss bildet Kapitel 10 mit einem kurzen Fazit, einer Zusammenfassung der Reflexionen und einem Ausblick. 2 Im Folgenden Dynamics CRM genannt

17 Grundlagen 2 Grundlagen Die Grundlagen können in drei Gruppen eingeteilt werden: - Die betriebswirtschaftlichen Grundlagen umfassen die Definition von mittelständischen Unternehmen. - Die technischen Grundlagen sind jeweils eine kleine Einführung in SharePoint und Dynamics CRM. - Die methodischen Grundlagen sind Themen wie Interviews, Theoriegenerierung, Projektmanagement und Ontologien. 2.1 Mittelstand In Deutschland werden Klein- und Mittelbetriebe als Mittelstand bezeichnet. Die Abgrenzung der Klein- und Mittelbetriebe von Großbetrieben findet anhand der Betriebsgröße und des Umsatzes statt. Die Europäische Kommission schlägt als Abgrenzungskriterien die Werte aus Tabelle 2.1vor. Tabelle 2.1: Aufteilung in Klein-, Mittel- und Großbetriebe nach EU-Kommision Unternehmensgröße Beschäftigte Umsatz (Mio. ) Bilanzsumme (Mio. ) kleinst < klein < mittel < groß 250 > 50 > 43 (Pfohl, 2013, S.16) Hans-Christian Pfohl beschreibt zusätzlich die Wichtigkeit der Branche des Unternehmens, die bei der Einteilung der Betriebe zu beachten ist. Er verweist auf eine Tabelle von Thürbach und Menzenwerth, welche die Grenzen der Klein-, Mittel- und Großbetriebe branchenabhängig bestimmen. Dabei sind die Grenzen der Größenklasseneinteilung in den Branchen Handwerk, Einzelhandel, Verkehr- und Nachrichtenübermittlung und Dienstleistungen von Unternehmen und freien Berufen weit geringer als in Industrie und Großhandel. 3 3 Die genaue Größenklasseneinteilung kann Anhang A entnommen werden

18 Grundlagen Hans-Christian Pfohl nennt zusätzliche betriebsgrößenrelevante Merkmale, welche in Tabelle 2.2 genannt werden: Tabelle 2.2: betriebsgrößenrelevante Merkmale Problembereiche Unternehmerleitung Organisation Beschaffung Produktion Absatz Entsorgung Forschung und Entwicklung Finanzierung Personal Logistik Größenmerkmale Gewinn, Umsatzentwicklung Anzahl der Hierarchieebenen, Anzahl der Beschäftigten Einkaufsmengen, Anzahl der Lieferanten Anzahl der Maschinen, Maschinenstunden, Produktionsmengen Umsatz, Anzahl der Verkaufsabschlüsse, Anzahl der Kunden Entsorgungsaufwendungen, Abfallmengen Forschungs- und Entwicklungsaufwendungen, vergebene Lizenzen Zahlungsströme, Kapitalbestände, Vermögensbestände, Bilanzsummen Anzahl der Beschäftigten Logistikkosten, Anzahl der Aufträge (Pfohl, 2013, S. 8) Diese weiteren betriebsgrößenrelevanten Merkmale nutzt er, um typische Klein- und Mittelbetriebe den Großbetrieben gegenüberzustellen. Anhand dieser Merkmale bestimmte er durch Literaturrecherchen und empirischen Nachweisen die Charakterisierungen von Klein-, Mittel- und Großbetrieben. Er ging dabei auf die Bereiche Unternehmensführung, Organisation, Beschaffung, Produktion, Absatz, Entsorgung, Forschung und Entwicklung, Finanzierung, Personal und Logistik ein und beschreibt in den einzelnen Bereichen die Unterschiede zwischen den Betriebsklassen. 4 Die Charakterisierungen sollen in dieser Arbeit nicht der Einteilung der Unternehmen in Klein- und Mittel- und Großbetrieben dienen, sondern viel mehr der Einschätzung eines Unternehmens. 2.2 SharePoint SharePoint ist ein Content Management System mit Dokumentenmanagementfunktionen. Es wird in mittelständischen Unternehmen eingesetzt, um Dokumente und Daten zu sammeln, verwalten und verteilen. Das Produkt Microsoft SharePoint bietet mit der Version 2013 auch mannigfaltige Einsatzmöglichkeiten im Bereich Enterprise Vgl. Anhang A Charakterisierung von Klein-, Mittel- und Großbetrieben 5 Enterprise 2.0 beschreibt die Nutzung von Sozial Media in Unternehmen

19 Grundlagen SharePoint kann Benutzer in den Bereichen Kollaboration, Dokumentenmanagement und Geschäftsanwendungen unterstützen, außerdem kann es wie ein Enterprise Content Management System 6 genutzt werden. Unterschiedliche Unternehmensdaten können für Mitarbeiter in einem Intranet bereitgestellt werden. Es können öffentliche oder semiöffentliche Webseiten mit Dokumentenmanagementfunktionen für die Kunden definiert werden. Durch Bibliotheken, in denen Dokumente wie Textdateien, Tabellenkalkulationen, Bilder, Videos und andere Dateien abgelegt werden, sind die Mitarbeiter dazu in der Lage, gemeinsam mit und an diesen Dokumenten zu arbeiten. Die gemeinsame Arbeit wird durch Versionierung und Co-Authoring 7 unterstützt. Das Kopieren, Verschicken und Verschieben von Dokumenten ist somit nicht nötig. Als Intranetanwendung bietet SharePoint durch die Einbindung von Foren, Blogs, Wikis, Aufgabenlisten und Projektseiten viele Möglichkeiten der Kollaboration. Mitarbeiter und Teams können ihre Aufgaben und Termine gemeinsam verwalten. Kooperativ können Inhalte bearbeitet und für andere Mitarbeiter veröffentlicht werden. Durch einen persönlichen Bereich können die eigenen Aufgaben oder interessante Beiträge gesammelt und zentral dargestellt und verwaltet werden. SharePoint bietet auch die Möglichkeit, fremde Arbeiten zu bewerten und anderen Mitarbeitern und deren Arbeiten sowie Projekten zu folgen. Für bestimmte Prozesse im Unternehmen können Apps und Workflows in SharePoint genutzt werden. Eine Möglichkeit zur Bearbeitung von Anträgen ist die Nutzung eines Genehmigungsworkflows. 2.3 Dynamics CRM Customer Relationship Management umfasst den Aufbau und die Festigung langfristig profitabler Kundenbeziehungen durch abgestimmte kundenindividuelle Marketing-, Sales-, und Servicekonzepte mit Hilfe moderner Informations- und Kommunikationstechnologien. Ein Zitat von Leußer, auf welches sich auch Beate Hubricht, die Verfasserin des Werks Strategisches CRM, bezieht. (vgl. Hubrich, 2014, S. 20) Sie geht in ihrer Arbeit auf das strategische CRM, also die Nutzung des CRMs zur Generierung und Pflege nachhaltiger Kundenbeziehungen. (vgl. Hubrich, 2014, S. 29) Folgend soll das operative CRM betrachtet werden. Dieses dient zur Unterstützung der Geschäftsprozesse, ohne auf eine langfristige Strategieplanung einzugehen. Microsoft Dynamics CRM, welches hier beispielhaft untersucht wird, ist nicht ausschließlich für die Verwaltung von Kundenbeziehungen geschaffen. Es kann in verschiedene Richtungen erweitert werden, sodass statt Kunden beispielsweise Patienten verwaltet werden. Daher wird das Dynamics CRM von Microsoft auch als universelles xrm bezeichne. (vgl. Wolenik, 2014, S. 66ff) Out-of-the-Box bietet Dynamics CRM Entitäten zur Vertriebsverwaltung, zum Kundenservice und zum Marketing. In der Vertriebsverwaltung kann Dynamics CRM richtig eingesetzt zur 6 Ein Enterprise Content Management System dient zur Verwaltung Unternehmensrelevanter Daten und Dokumente wie Verträge, Rechnungen und Richtlinien. 7 Eine Funktion von Microsoft SharePoint zur gleichzeitigen Bearbeitung von Dokumenten

20 Grundlagen Organisation von potenziellen und bestehenden Kunden genutzt werden sowie für Verkaufschancen, Angebote, Bestellungen und Rechnungen. Das gesamte Produkt- und Dienstleistungsportfolio einer Unternehmung kann dafür in Dynamics CRM abgebildet werden. Auch Ressourcen wie Zeit, Mitarbeiter und Werkzeuge 8 können in Dynamics CRM für den Kundenservice abgebildet werden. Dadurch können Einsätze und Termine geplant, sowie Kundenanfragen bearbeitet werden. Im Bereich Marketing kann Dynamics CRM zur Verwaltung und Evaluation von Kampagnen herangezogen werden. Als zentrales System eines Unternehmens kann Dynamics CRM die Arbeitsabläufe beschleunigen und vereinfachen. Alle Inhalte werden in Tabellen aufgelistet. Diese Tabellen sind auch wie die Detailansichten anpassbar. Zusätzlich dient es als Dokumentationstool, welches die Möglichkeit bietet, für alle erfassten Daten Auswertungen und Diagramme zu erzeugen. Es ist somit nicht nur ein reines Verwaltungs- sondern auch ein Controllingsystem. 2.4 Anwendungsbereiche von SharePoint und Dynamics CRM SharePoint und Dynamics CRM werden mit den Themen Dokumentenmanagement, Kollaboration, Business Intelligence, Geschäftsprozesse und Projektmanagement in Zusammenhang gebracht. Daher werden diese Themen nachstehend vorgestellt Dokumentenmanagement Dokumentenmanagement ist die Verwaltung von Papier- oder elektronischen Dokumenten. Dazu gehört, dass Dokumente und deren Verwaltung in die Prozesse der Unternehmen integriert werden. Wolf Steinbrecher und Martina Müll-Schnurr zählen folgende betriebliche Notwendigkeiten für Dokumente auf: - Während eines aktiven Vorgangs dessen Arbeitsfluss unterstützen - Gedächtnisstütze für interne Zwecke - Abwehr unberechtigter Ansprüche von außen - Termin- und Aktivitätsplanung - Dokumentation von Abläufen und Nachweisen dessen, was getan wurde. (Steinbrecher & Müll-Schnurr, 2014, S. 21f) Neben diesen Notwendigkeiten, gibt es auch eine Reihe von gesetzlichen Vorschriften, wie Rechnungsrichtlinien und Aufbewahrungspflicht für Handelsbriefe, Buchungsbelege, Inventare und Bilanzen. (vgl. Steinbrecher & Müll-Schnurr, 2014, S. 22) 8 Werkzeuge sind in diesem Kontext Systeme, Tools, Geräte, Fahrzeuge und ähnliches

21 Grundlagen Die internationale Norm DIN ISO gilt als Qualitätsstandard, welche die Verwaltung und Aufbewahrung von Unterlagen beschreibt. Darin wird unter anderem definiert, welche Anforderungen an Schriftgut gestellt werden: - Authentizität: Inhalt und Bearbeiter des Dokuments müssen verständlich und identifizierbar sein. - Zuverlässigkeit: Das Dokument muss die nachgewiesenen Aktivitäten glaubwürdig, vollständig und genau wiedergeben. - Integrität: Das Dokument muss vollständig und unverändert bleiben. - Benutzbarkeit: Das Dokument muss nachgewiesen, wieder aufgefunden, dargestellt und verstanden werden können. (vgl. Steinbrecher & Müll-Schnurr, 2014, S. 31) Für die Umsetzung von Dokumentenmanagement hilft ein Dokumentenmanagementsystem 9 (DMS) nur an der Oberfläche. Um die Vorteile eines DMS zu nutzen, muss zuerst die Grundlage geschaffen werden. Dazu gehören wie in Abbildung 2.1 dargestellt die grundlegende Ordnungsstruktur, die Objektkategorien, das Berechtigungskonzept und das Archivkonzept. DMS Archivkonzept, Regeln Berechtigungskonzept Objektkategorien und normierte Objektlisten Grundlegende Ordnerstruktur = praktikabler Ordnerplan Abbildung 2.1: Dokumentenmanagement-Pyramide 9 System zur Verwaltung von Dokumenten. Die Funktionen gehen über einen herkömmlichen Fileserver hinaus

22 Grundlagen Kollaboration (Steinbrecher & Müll-Schnurr, 2014, S. 16) Kollaboration ist die Zusammenarbeit von Teams und die konstruktive Wissensgenerierung in einem Unternehmen. Dabei überwiegen selbstgesteuerte und interaktive Austauschprozesse zwischen den Gruppenmitgliedern (Bornemann, 2011, S. 77). Zur Unterstützung können unter anderem Wikis, Diskussionsforen, Blogs und Instant Messenger dienen. Mit Hilfe dieser Instrumente sollen folgende Ziele erreicht werden: - Beteiligung der Mitarbeiter durch Bereitstellen von Inhalten - Vernetzung der Mitarbeiter - Höhere Tranzparenz, indem dialogische Informationsflüsse sichtbar und nachvollziehbar werden - Strukturieren von Inhalten und Reduzieren von Komplexität - Einrichten einer zentralen Suchfunktion - Archivieren der Einträge - Selbstbestimmtes Informationsmanagement (vgl. Plass, Rehmann, Zimmermann, Janssen, & Wibbing, 2013, S. 53) Business Intelligence Business Intelligence ist ein Konzept, welches der Wissensgenerierung durch Integration, qualitative Verbesserung, Transformation und statische Analyse der operativen und externen Unternehmensdaten dient. Dazu gehören die angrenzenden Disziplinen Betriebswirtschaft/Management Science, Operations Research, Data Mining/Maschinelles Lernen, explorative Datenanalyse und Data Warehousing. Grundsätzlich kann zu Business Intelligence gesagt werden, dass durch statistische Methoden, Schätzverfahren und Testverfahren gesammelte Daten analysiert und für Planer, Entscheider und Controller visualisiert werden. (vgl. Müller & Lenz, 2013, S. 3ff) Es umfasst allerdings einen weit größeren Bereich, wie in Abbildung 2.2 dargestellt

23 Grundlagen Abbildung 2.2: Überblick der Business Intelligence Bereiche (Müller & Lenz, 2013 S. 6) Business Intelligence Werkzeuge beinhalten Auswertungsverfahren für interne und externe Unternehmensdaten. Dies sind quantitative Verfahren für Planungs-, Entscheidungs- und Controllingzwecke und umfassen folgende Anwendungsfelder: - Internes Business Intelligence, welches sich auf die taktische Ebene konzentriert. - Business Activity Monitoring, welches die operativen Prozesse unterstützt. - Corporate Performance Management, welches interne Informationen auf der strategischen Ebene bereitstellt. - Supply Chain Intelligence, welches sich auf die Informationen über Beschaffung, Vertrieb, Logistik und Lagerhaltung konzentriert. - Strategic Intelligence, welches die langfristige Entwicklung analysiert. - Customer Relationship Analytics, welches die Kundenbeziehungen fokussiert. - Web Analytics, welches zum Verstehen und Optimieren der Internetnutzung dient. - Competitive Intelligence, welches zur Auswertung von Informationen über Märkte, Technologien und Wettbewerber dient. (vgl. Müller & Lenz, 2013, S. 259 und 262) Für diese Arbeit sind Internes Business Intelligence, Business Activity Monitoring und Customer Relationship Analytics relevant

24 Grundlagen Geschäftsprozesse Ein Geschäftsprozess ist ein bestimmter Ablauf von Bearbeitungsschritten. Dieser kann implementiert werden, wenn er ein hohes Standardisierungsmaß aufweist. (vgl. Freund & Götzer, 2008, S. 7) Durch Workflow-Systeme können formal und präzise beschriebene Prozesse unterstützt werden. Die Prozessorganisation ist eine permanente Aufgabe, welche die Definition und Entwicklung neuer und bestehender Prozesse, die Entwicklung von Kennzahlen für die Leistungsfähigkeit der Prozesse und die Beobachtung der Prozesse beinhaltet. Dabei spielt die Dokumentation und das Aktualisieren der Dokumente eine übergeordnete Rolle. (vgl. Freund & Götzer, 2008, S. 25) Für die Implementierung von Prozessen in die Unternehmens-IT bieten sich Webanwendungen an. Änderungen werden dadurch nicht aufwändig auf die einzelnen Arbeitsplätze verteilt, sondern auf einem Server zentral administriert, zudem ist die Nutzung der Prozesse über die Unternehmensgrenzen hinaus möglich. (vgl. Freund & Götzer, 2008, S. 63) 2.5 Experteninterviews Eine Methode der qualitativen Sozialforschung sind die Experteninterviews. Der Experte zeichnet sich durch sein spezifisches Forschungsinteresse und seine soziale Repräsentativität aus. (vgl. Bogner, Littig, & Menz, 2014, S. 11) Er kann befragt werden um technisches Wissen oder Prozesswissen zu sammeln. Alexander Bogner, Beate Littig und Wolfgang Menz stellen vier Varianten von Experteninterviews vor, welche in Tabelle 2.3 aufgezählt werden: Tabelle 2.3: Gliederung von Experteninterviews Informatorische Experteninterviews Deutungswissensorientierte Experteninterviews Explorative Experteninterviews Experteninterviews zur explorativen Datensammlung Experteninterviews zur Exploration von Deutungen Fundierte Experteninterviews Systematisierende Experteninterviews Theoriegenerierende Experteninterviews (Bogner, Littig, & Menz, 2014 S. 23) Explorative Experteninterviews dienen zur ersten Orientierung im Feld, so zum Beispiel auch vorangehend zu quantitativen Untersuchungen. Sie können sowohl zur Daten- als auch zur Deutungssammlung 10 genutzt werden. Systematisierende Experteninterviews werden genutzt, um Sachwissen zu erheben. Sie benötigen eine gute Vorbereitung und helfen dem Forscher seinen Wissenstand zu erweitern und zu vervollständigen. 10 Interpretationen und Vorstellungen des Experten

25 Grundlagen Theoriegenerierende Experteninterviews zielen auf das Deutungswissen der Befragten ab. Sie werden genutzt, um im empirischen Material Zusammenhänge zu erarbeiten und Theorien zu entwickeln. (vgl. Bogner, Littig, & Menz, 2014, S. 25) Alle Experteninterviews sind teilstrukturiert, sie werden unter Zuhilfenahme eines Leitfadens durchgeführt. Dabei ist es dem Interviewer überlassen, welchen Umfang dieser Leitfaden hat. Je nach Erfahrung und Sicherheit kann es von allgemeingehaltenen Topic Guides 11 bis hin zum ausformulierten Fragebogen reichen. In der Regel ist ein Leitfaden zwischen einer und sechs Seiten lang, behandelt ein bis acht Themen und zu jedem Themenblock eine bis drei Hauptfragen. (vgl. Bogner, Littig, & Menz, 2014, S. 28f) Der Interviewer sollte im Interview nicht zu sehr auf seine Fragen fixiert sein, sondern den Redefluss seines Gegenübers nutzen, um so einen annähernd natürlichen Dialog zu führen. Für die Auswertung der Interviews sind die qualitative Inhaltsanalyse und die Grounded Theory von Bedeutung. Bei der qualitativen Inhaltsanalyse werden die Informationen aus den Interviews verdichtet und miteinander verknüpft. Sie dient nicht dem Aufstellen neuer Thesen, sondern der Wiederlegung oder Bestärkung von bereits bestehenden Thesen. Ganz im Gegensatz dazu steht das Prinzip der Grouded Theory. Es dient dazu neue Thesen durch das Kodieren der gesammelten Informationen aufzustellen. (vgl. Bogner, Littig, & Menz, 2014, S. 72ff) 2.6 Theoriegenerierung Zwei Ansätze der datennahen Theoriegenerierung, Grounded Theory und Heuristische Sozialforschung werden hier vorgestellt Grounded Theory Grounded Theory ist eine von Barney Glaser und Anselm Strauss entwickelte Methode zur Theoriegenerierung aus der qualitativen Sozialforschung. Dabei geht es darum eine Forschungsfrage durch spiralförmig angelegte Folge von Schritten zu beantworten. (vgl. Krotz, 2005, S. 160ff) Dieser Spirallauf wird mit der Forschungsfrage eröffnet. Nachdem durch den ersten vollständigen Zyklus (vgl. Abbildung 2.3) erste Erkenntnisse gewonnen und eine Theorie gebildet wurde, werden im zweiten Zyklus die Erkenntnisse genutzt, um die Theorie weiter auszuformulieren. Wenn ein definiertes Abbruchkriterium erreicht ist, wird der Spirallauf beendet. (vgl. Krotz, 2005, S. 167ff) 11 In einem Topic Guide werden Themen gesammelt und geordnet

26 Grundlagen Auswahl der Befragten, Erhebung von Daten Zusammenfassen und strukturieren, Theorien entwickeln, testen und prüfen, weiteres Vorgehen planen, Memos schreiben Codieren, auswerten, vergleichen, prüfen, Memos schreiben Abbildung 2.3: Zyklus der Grouded Theory (Krotz, 2005, S. 167) Bei der Codierung der Interviews werden Aussagen in den Transkripten durch Oberbegriffe markiert und so einander zugeordnet, dabei können interpretierende, zusammenfassende, abstrahierende und ordnende Auswertungsschritte zum Codieren gezählt werden. Während der Codierung sollte der Forscher Fragen, Erkenntnisse und Besonderheiten als Memos notieren, um später darauf zurück zu kommen. (vgl. Krotz, 2005, S. 172ff) Anhand dieser Auswertungen werden Theorien generiert, neue Fragen aufgestellt und ein neues Sampling 12 durchgeführt. Im nächsten Zyklus werden unter Berücksichtigung dieser Erkenntnisse neue Interviews durchgeführt und ausgewertet. Die Resultate werden zusammen mit den Vorherigen genutzt, um die vorher entstandene Theorie zu erweitern. Sobald die Theorie gesättigt ist, also durch Interviews keine neuen Erkenntnisse für oder gegen die Theorie gewonnen werden können, ist das Abbruchkriterium erreicht. (vgl. Krotz, 2005, S. 176f) 12 Ein Sampling ist Auswahl der Befragten

27 Grundlagen Heuristische Sozialforschung Die heuristische Sozialforschung ist eine Weiterentwicklung der Grouded Theorie und bietet Regeln für das Vorgehen zur Theoriegenerierung an. Dabei soll die Forschung als Dialog angesehen werden. Friedrich Krotz beschreibt es mit den Worten: Heuristische Forschung findet als Prozess des Fragens und Antwortbekommens statt. (vgl. Krotz, 2005S, S. 208) Dies kann auch auf die Theoriegenerierung angewendet werden, indem der Forschende Fragen stellt, welche durch das Sammeln und Auswerten von Daten beantwortet werden. Es wird in dieser Art der Sozialforschung somit nicht mit den Codes und deren Kategorisierung gearbeitet. Gerhard Kleining nennt vier Regeln der heuristisches Sozialforschung: Regel 1: Offenheit der Forschungsperson Der Forschende soll seine Meinung ändern, wenn die Daten gegen ihn sprechen. Regel 2: Offenheit des Forschungsgegenstandes Die Theorie ist vorläufig und änderbar, bis der Forschungsgegenstand vollständig entdeckt ist. Regel 3: Maximale strukturelle Variation der Perspektiven Durch Variation aller Bedingungen der Forschung, soll der Forschungsgegenstand von allen Seiten beleuchtet werden. Regel 4: Analyse auf Gemeinsamkeit Die verschiedenen Bilder des Gegenstandes werden auf Zusammenhänge und Gemeinsamkeiten untersucht. (vgl. Krotz, 2005S, S. 209)

28 Grundlagen 2.7 Projektmanagement Projektmanagement ist die Konzeption für die Durchführung von zeitlich begrenzten Aufgaben. Diese müssen geplant, gesteuert und überwacht werden. (vgl. Wytrzens, 2010, S. 22) Abbildung 2.4 zeigt die begriffliche Zusammensetzung des Wortes Projektmanagement. Projekt Temporäres Unterfangen zur Entwicklung und Produktion von Neuem Management System von Steuerungsaufgaben, die bei der Leistungserstellung und -sicherung in arbeitsteiligen Organisationen zu erbringen sind Projektmanagement Gesamtheit aller Aktivitäten, Aufgaben, Instrumente und Methoden zur Planung, Organisation, Führung, Kontrolle, Steuerung sowie Abwicklung von komplexen Vorhaben auf Zeit. Abbildung 2.4: Begriffliche Erklärung des Projektmanagements Hans Karl Wytrzens schreibt, dass Projektmanagement aus drei Aufgabenschwerpunkten besteht: - Projektplanung, zu welcher die Aufgaben Benennung des Projektleiters, die Errichtung der Projektgruppen, die Festlegung der Projektziele, die Ableitung von Teilprojekten, die Planung der Abläufe, die Schätzung des Bedarfs und des Aufwandes sowie Terminplanung und Budgetierung gehören. - Projektsteuerung, zu der die Anleitung und Motivation von Mitarbeitern, die Überwachung des Projektverlaufs, die Sicherung des Projektfortschritts, das Ergreifen von Maßnahmen bei Planabweichungen und die Koordinerung verschiedener Projektteilnehmer gehören. - Projektkontrolle, welche die Projektplanung und die Wirksamkeit der Maßnahmen überprüft. (vgl. Wytrzens, 2010, S. 22f) Zur Umsetzung von Projektmanagement können verschiedenen Methoden genutzt werden, wovon zwei vorgestellt werden: On-site Customer und Iterative Entwicklungsmethode

29 Grundlagen On-site Customer Bei dieser agilen Entwicklungsmethode wird ein erfahrener und entscheidungsbefähigter Vertreter des Kunden im Entwicklungsteam eingesetzt. Dieser Vertreter steht bei Fragen der Entwickler zur Verfügung und schreibt Story-Cards. Diese sind gleichzeitig die Spezifikation für das entstehende Produkt. (vgl. Schneider, 2014) Die Rolle des On-site Customers wird Abbildung 2.5 grafisch dargestellt. Abbildung 2.5: Darstellung des On-site Customers (Schneider, 2014) Story Cards werden umgangssprachlich und informell von dem On-Site Customer auf Karteikarten geschrieben. Danach Schätzen die Entwickler die Komplexität der Story Cards und geben diese zurück an den Vertreter des Kunden, welcher die Storycards priorisiert und definiert welche davon in die nächste iteration mit einfließen

30 Grundlagen Iterative Entwicklungsmethode Bei dem iterativen Vorgehen wird ein Projekt in Zyklen realisiert, dabei wird die Trennung zwischen Spezifikation und Konstruktion aufgehoben. Die einzelnen Bausteine des Projekts durchleben ihre Projektphasen unabhängig von den anderen Bausteinen. Die genaue Anforderungsanalyse und Implementierung der Bausteine findet nicht zu Beginn des Projekts statt, sondern mit der Bearbeitung der einzelnen Bausteine. Als Vergleich wird das Spiralmodell von Boehm aus Abbildung 2.6 herangezogen. Abbildung 2.6: Spiralmodell (vgl. Zehnder, 2003, S. 244) Sollte ein Fehler in einer späteren Iteration festgestellt werden, geht das Projektteam zum fehlerhaften Baustein zurück und passt es an. Es ist wichtig, dass die einzelnen Iterationen keine drastischen Mutationen unterliegen. (vgl. Koch, 2008, S.25) 2.8 Ontologien Ontologien stammen aus der theoretischen Philosophie und bauen auf das Universalienproblem, Objekte und Symbole auf. (vgl. Stuckenschmidt, 2009) Das Universalienproblem ist die Frage, ob Begriffe existieren oder ob es menschliche Konstruktionen sind, die aus dem Drang entstehen, alles eine Bezeichnung zuzuordnen. Objekte besitzen Eigenschaften und können Kategorien zugeordnet werden. Objekte und Kategorien zeichnen sich durch ihre Eigenschaften aus und werden durch diese auch von anderen Objekten unterschieden. In der menschlichen Sprache besitzt jeder Begriff mindestens eine Bedeutung. Diese Begriffe sind Symbole. In der künstlichen Intelligenz sind Ontologien endliche Mengen von Begriffen und formalen Definitionen der Relationen zwischen Begriffen. (vgl. Conrad, 2010, S. 101)

31 Grundlagen Ontologien können mit den auf XML basierenden Sprachen RDF und OWL beschrieben werden. Dabei werden Tripel gebildet, welche ein semantisches Netz darstellen. Die Tripel haben folgenden Aufbau: Ƭ(Subjekt, Prädikat, Objekt) Subjekte können Klassen und Instanzen sein, Prädikate sind Beziehungen und Eigenschaften und Objekte können Instanzen und Werte sein. Abbildung 2.7 stellt eine Ontologie als Graph dar. Klassen sind als K vreise, Eigenschaften als Rechtecke und Beziehungen als Pfeile dargestellt. name Spike Hund name Tom Hundehütte lebt_in jagt Katze lebt_in jagt name Jerry Haus lebt_in maus Abbildung 2.7: Beispielgraph einer Ontologie

32 Systemanalyse 3 Systemanalyse Um zu entscheiden welche Anforderungen von den Systemen umgesetzt werden können, muss zuerst analysiert werden, welchen Funktionsumfang die Systeme haben. Dies dient auch der Beantwortung der Forschungsfrage: RQ4.1: Welche Funktionen haben die Systeme? Beide Systeme besitzen tiefgehende Strukturen. SharePoint ist ein System, mit dem der Aufbau eines Intranets und wenn gewünscht eines Internetauftritts möglich ist. Das Intranet kann unter anderem für die Zusammenarbeit in Teams oder Projekten genutzt werden. Dazu können abgesehen von Websites, Listen und Bibliotheken bereitgestellt und Prozesse eines Unternehmens abgebildet und technisch unterstützt werden. Durch verschiedene Erweiterungen können Daten im SharePoint gesammelt, aufbereitet und grafisch dargestellt werden. Dynamics CRM bietet eine Visualisierung von Tabellen, Datensätzen und Formularen. Es wird hauptsächlich zur Kundenverwaltung und Organisation von Kundenaktivitäten genutzt. Zusätzlich stellt es die Möglichkeiten bereit, dass Teams gemeinsame Daten bearbeiten. In Dynamics CRM können Prozesse eines Unternehmens abgebildet werden. Dynamics CRM ist wie SharePoint eine Browseranwendung, hat im Gegensatz dazu allerdings nicht das Lookand-Feel eines Webauftritts. Es ist ein reines Verwaltungstool um Ressourcen, Vorgänge, Kunden und weitere unternehmensrelevante Sachverhalte gesammelt, aufbereitet und grafisch darzustellen. In diesem Kapitel werden beide Systeme im Detail beschrieben und deren Unterschiede herausgearbeitet. Abschließend wird erklärt, warum beide Systeme für diese Arbeit von Bedeutung sind. 3.1 SharePoint SharePoint basiert auf Webanwendungen, in denen eine oder mehrere Websitesammlungen abgelegt sind. (vgl. Abbildung 3.1) Websites 13 einer Websitesammlung verfügen über einen gemeinsamen Webpart-Katalog, gemeinsame Vorlagen für Sites, Listen und Bibliotheken und über gemeinsame Benutzer und Verwaltungsfunktionen. Zwei Websitesammlungen sind von der Datenhaltung, über das Berechtigungskonzept, bis hin zur Administration komplett voneinander getrennt. (vgl. Larisch, 2013, S. 20) 13 Eine Website ist ein Internet- bzw. Intranetauftritt, bei dem Inhalte thematisch zusammengefasst dargestellt werden

33 Systemanalyse Webanwendung Websitesammlung Websitesammlung Website Website Website Website Website Website Website Website Website Website Abbildung 3.1 Webanwendung im SharePoint Um Daten auf Websites anzuzeigen und zu verarbeiten bietet SharePoint zwei Arten von Komponenten an: Listen und Bibliotheken. Listen sind für einfache Elemente vorgesehen und ähnlich der Repräsentation einer Datenbanktabelle. Bibliotheken können genutzt werden, um Dateien in verschiedenen Formaten hochzuladen und bereitzustellen. Alle Komponenten einer SharePoint-Website werden in der Literatur Apps genannt, auch Listen und Bibliotheken. In dieser Arbeit wird der Begriff App für Anwendungen, welche nicht zur Standardinstallation gehören und speziell zugeschnittene Erweiterungen für SharePoint sind, verwendet. Um Daten im SharePoint bereitzustellen, werden Listen benötigt. Diese werden in verschiedenen Formaten mit unterschiedlichen Eigenschaften angeboten. SharePoint bietet bereits eine Auswahl an Vorlagen für Listen an, welche in Tabelle 3.1 aufgezählt sind

34 Systemanalyse Tabelle 3.1: SharePoint Listenvorlagen Vorlage Ankündigungen Aufgaben Projektaufgaben Benutzerdefiniert Diskussionsrunde Externe Listen Links Höhergestufte Links Kalender Kontakte Probleme Umfragen Newsfeed KPI-Liste (Key Performance Indicator) Beschreibung zur Verwaltung von Neuigkeiten, abgelaufene Ankündigungen werden automatisch ausgeblendet zur Verwaltung von Aufgaben im Team, ein Vorteil ist die Verknüpfung mit Outlook zur Verwaltung von Aufgaben in Projekten, zusätzlich zu der normalen Aufgabenliste besitzen die einzelnen Elemente auch ein Startdatum und einen Vorgänger, eine Verbindung zu Outlook ist ebenfalls möglich, sowie eine Verbindung zu Microsoft Projects zur Erstellung von beliebigen Listen mit beliebigen Inhalten zur zentralen Verwaltung der Teamdiskussionen in einem Forum zum Darstellung von Listen, die außerhalb von SharePoint gespeichert sind zur Festlegung von Verweisen in- und außerhalb von SharePoint ähnlich der Liste Links, nur dass die Links in der Liste als Kacheln angezeigt werden zur Terminverwaltung innerhalb eines Teams, auch hier ist eine Verbindung zu Outlook und eine automatische Synchronisation möglich zur Verwaltung von Kontaktdaten, eine Einbindung von Outlook ist möglich zur Verwaltung von Problemen, die in einem Projekt auftreten können, zu Problemen können Aufgaben zugeordnet werden, zusätzlich gibt es die Möglichkeit Visio, Excel oder Project einzubinden zur Erstellung und grafischen Auswertung von Umfragen zur Teilung von Informationen mit Kollegen und Kolleginnen zur Überwachung und Überprüfung bestimmter Zielvorgaben (vgl. Schmidt, 2013, S. 42ff) und (vgl. Larisch, 2013, S. 177) Bibliotheken und Listen müssen durch Webparts in Websites eingebettet werden. Eine Liste kann mit verschiedenen Webparts unterschiedlich dargestellt werden. Ein Webpart kann auch mehrere Listen miteinander kombinieren. (Larisch, 2013, S. 107) Webparts dienen nur der Repräsentation der Inhalte. Zum Bereitstellen von Dokumenten, Bildern und anderen Dateien können Bibliotheken genutzt werden. Diese unterscheiden sich insoweit von Listen, dass darin Dokumente als

35 Systemanalyse Elemente abgelegt werden. Melanie Schmidt nennt 9 Vorlagen für Bibliotheken die SharePoint bereitstellt: (vgl. Tabelle 3.2) Tabelle 3.2: SharePoint Bibliotheksvorlagen Vorlage Dokumentenbibliothek Bildbibliothek Objektbibliothek Datenverbindungsbibliothek Formularbibliothek Datensatzbibliothek Berichtsbibliothek Prozessdiagrammbibliothek Wiki-Seitenbibliothek Beschreibung zur Zentralen Speicherung von Dateien zur Bereitstellung von Bildern zur Bereitstellung von Rich-Media-Objekten wie Videos oder Sounds zur zentralen Speicherung und zum Zugriff auf externe Datenquellen per Office Data Connection (ODC) zur Bereitstellung von XML-basierten Formularen, die via InfoPath erstellt wurden zur Erstellung eines Datenarchivs zur Speicherung von Excel-Arbeitsmappen, Dashboards oder Key Performance Indicators (KPI) zur Bereitstellung von Visio-Zeichnungen zur Bereitstellung von Informationen in einem Wiki (vgl. Schmidt, 2013, S. 38ff) Auch für die Websites bietet SharePoint Vorlagen an, die bereits eine Vorauswahl an Listen und Bibliotheken bereitstellen. (vgl. Tabelle 3.3) Jede Website kann individuell angepasst werden, indem Listen oder Bibliotheken entfernt, hinzugefügt oder bearbeitet werden. Tabelle 3.3: SharePoint Websitevorlagen Vorlagen Teamwebsite Blog Projektwebsite Communitywebsite Dokumentencenter Beschreibung zur Verwaltung eines Teams und zur Förderung der Zusammenarbeit im Team zur Verbreitung von Meinungen, Ideen oder Ereignissen unter Kollegen und Kolleginnen, jeder Blogeintrag kann kommentiert und bewertet werden zur Verwaltung aller projektrelevanten Informationen zur Schaffung einer Forenumgebung für Diskussionen zwischen Kollegen und Kolleginnen zur zentralen Ablage und Verwaltung von Dateien

36 Systemanalyse Datenarchiv Business Intelligence Center Unternehmenssuchcenter Basissuchcenter Visio-Prozess-Repository Unternehmenswiki zur Ablage von aktuellen Kopien aller Datensätze zur visuellen Auswertung von Daten und Analyse, so können Dashboards und interaktive Bereiche erstellt werden zur Durchführung von allgemeinen, personenbezogenen Unterhaltungs- und Videosuchvorgängen einfache Suchwebsite zur Abbildung von Geschäftsprozessen und Diagrammen zur Bereitstellung einer Wiki-Umgebung für Kollegen und Kolleginnen (vgl. Schmidt, 2013, S. 45ff) Reichen die Funktionalitäten der gewählten Listen, Bibliotheken oder Websites nicht aus, können diese vollständig angepasst werden, wenn der Benutzer die nötigen Rechte dafür besitzt. Aus angepassten Bibliotheken, Listen oder Websites können Vorlagen erstellt werden. Vorlagen können, laut Melanie Schmidt, nicht ohne Programmieraufwand bearbeitet werden. (vgl. Schmidt, 2013, S. 257) Microsoft hat die FAST-Search aufgekauft und SharePoint mit dieser umfassenden Such- Engine erweitert. Dadurch kann in SharePoint ein unternehmensweites Suchcenter aufgebaut werden, welches neben SharePoint-Inhalten auch Websites und Dateifreigaben eines Servers durchsuchen kann. (vgl. Larisch, 2013, S. 303) Da die FAST-Search kein Kernthema dieser Arbeit ist, wird auf weiterführende Literatur 14 verweisen. 3.2 Dynamics CRM Dynamics CRM unterstützt die Benutzer in drei Hauptanwendungsbereichen: Vertrieb, Marketing und Kundenservice. Jede dieser drei Bereiche besitzt Dashboards, in denen die für den Benutzer wichtigsten Zahlen grafisch dargestellt werden können. Die folgenden Erklärungen beschreiben die Entitäten, Relationen und Prozesse von Dynamics CRM nach der Standardinstallation. Alle Komponenten können durch Customizing 15 angepasst, gelöscht oder erweitert werden Arbeiten im Vertrieb Die wichtigste Entität in Dynamics CRM ist der Kunde, diese setzt sich zusammen aus einem Firmenkunden und einer oder mehreren Kontaktpersonen. Zusätzlich gibt es die Entität Lead, welche einen potenziellen Kunden darstellt. ( vgl. Wolenik, 2014, S. 119ff) 14 (Alitezaei, et al., 2013) und (Micka, Trantopoulos, Elborg, Keilholz, & De Maddalena, 2014) 15 Anpassen des Systems ohne den Programmcode zu ändern

37 Systemanalyse In dem folgenden Klassendiagramm (vgl. Abbildung 3.2) ist eine Übersicht der im Anwendungsbereich Vertrieb relevanten Entitäten. Produkt 0..* 1.. Preisliste Auftrag 0..* Konkurrent 0..* Rechnung 1..* Angebot 0..* 1..* SharePointDokument 0..* 1 Verkaufchance 0..* 0..* 0..* Case 1 1 Marketingliste 0..* * Firmenkunde Kontaktperson Lead 1 0..* 0..* Aktivität 0..* Abbildung 3.2 Dynamics CRM-Klassendiagramm Vertrieb Das Dynamics CRM-System bietet bereits einen Grundstock an Attributen für die einzelnen Entitäten 16. Das oben abgebildete Klassendiagramm in Abbildung 3.2, sowie alle folgenden Klassendiagramme Abbildung 3.4 und Abbildung 3.5 in diesem Kapitel sind übersetzte Zusammenfassungen der Ausführungen von Marc Wolenik. Der Firmenkunde kann mit allen anderen Entitäten des Dynamics CRMs verknüpft werden. Dazu gehören Kontaktperson, Marketingliste, Dokument, Auftrag, Rechnung, Verkaufschance, Case und Aktivität. Case stellt verschiedenartige Kundenanfragen oder Kundenprobleme dar. (vgl. Wolenik, 2014, S. 126) Unter Aktivität werden Aufgaben, Faxe, Telefonate, s, Briefe, Termine, Serientermine, Serviceaktivitäten, Kampagnenreaktionen, Kampagnenaktivitäten und andere Kundenaktivitäten verstanden (vgl. Wolenik, 2014, S. 150) Zur Bereitstellung von Dokumenten in Dynamics CRM kann eine Schnittstelle zu SharePoint geschaffen werden. 16 Für genauere Erläuterungen der einzelnen Entitäten kann das Werk Microsoft Dynamics CRM 2013 Unleashed von Marc Wolenik herangezogen werden

38 Systemanalyse Dynamics CRM gibt einen Geschäftsprozess vor, welcher die Erstellung und die Bearbeitung des Leads in Teilschritte gliedert. Somit kann der Benutzer erkennen, in welcher Phase sich der Lead befindet. (vgl. Wolenik, 2014, S. 221) Im folgenden Aktivitätsdiagramm Abbildung 3.3, wird dieser Prozess vorgestellt: Lead erstellen Kontaktperson aus Lead generieren Verkaufschance aus Lead generieren [Firmeninformationen sind vorhanden] Firmenkunden aus Lead generieren [Firmeninformationen sind nicht vorhanden] Angebot aus Verkaufschance generieren Verkaufschance schließen [Verkaufschance gewonnen] [Verkaufschance verloren] Auftrag aus Angebot generieren Rechnung aus Auftrag generieren Abbildung 3.3 Dynamics CRM-Aktivitätsdiagramm Vertrieb Dieser Prozess ist von Dynamics CRM vorgegeben und kann durch Customizing deaktiviert oder angepasst werden. Wenn mit einem Lead gearbeitet wird, ist zu beachten, dass im Lead

39 Systemanalyse selbst keine Daten zum Verkauf hinzugefügt werden. In Dynamics CRM ist es vorgesehen, dass diese nur in den Verkaufschancen hinterlegt werden. Der Lead ist die Repräsentation eines potentiellen Kunden. (vgl. Wolenik, 2014, S. 227) Im Aktivitätsdiagramm ist beschrieben, dass die Entitäten Kontaktperson, Verkaufschance, Firmenkunde, Angebot, Bestellung und Rechnung aus jeweils anderen Entitäten generiert werden. Sie können abweichend davon auch unabhängig voneinander erstellt werden. (vgl. Wolenik, 2014, S. 260) Arbeiten im Marketing Die grundlegende Entität im Bereich Marketing ist die Marketingliste. Diese Liste kann statisch oder dynamisch sein. Ihre Elemente sind in der Regel Kontakte, können aber auch Leads oder Firmen sein. In einer Liste kann immer nur eine Art von Entitäten vertreten sein. Eine dynamische Marketingliste wird aktualisiert, wenn neue Entitäten die entsprechenden Kriterien erfüllen. Im Gegensatz dazu können den statischen Marketinglisten nur manuell neue Datensätze hinzugefügt werden. (vgl. Wolenik, 2014, S. 272ff) Im folgenden Klassendiagramm Abbildung 3.4 sind die marketingrelevanten Entitäten und deren Beziehungen zusammengefasst: Lead 1..* Kontaktperson 1..* 1 1 Marketingliste 1 1..* 1 Firmenkunde 1..* 1 1 Kampagne SchnelleKampagne * 1..* Aktivität Abbildung 3.4 Dynamics CRM-Klassendiagramm Marketing Marketinglisten werden genutzt, um die Empfänger für Kampagnen anzugeben, welche mehrere Marketinglisten als Grundlage nutzen. Eine Kampagne benötigt nicht nur eine Marketingliste sondern auch eine oder mehrere Aktivitäten, die für die Entitäten in der Marketingliste durchgeführt werden. Eine Aktivität kann zum Beispiel das Senden von E- Mails sein. Wenn Kampagnen wiederholt durchgeführt werden, können Kampagnentemplates verwendet werden. (vgl. Wolenik, 2014, S. 280) Da für das Marketing wichtig ist, wie die Kunden auf die Kampagnen reagierten, können aus den Aktivitäten Kampagnenreaktionen generiert werden. Aus den Reaktionen können Leads, Kunden, Verkaufschancen oder Aufträge erzeugt werden. (vgl. Wolenik, 2014, S. 288ff)

40 Systemanalyse Eine weitere, für das Marketingpersonal oder den Vertriebler nützliche Entität, ist die Verkaufsliteratur. Mit dieser Entität können Produkte genauer beschrieben werden. Dazu zählt der Aufbau eines Produkts oder einer Dienstleistung, mit welchen Produkten oder Dienstleistungen diese gut zusammen passen, welche Zielgruppe das Produkt oder die Dienstleistung haben oder welche Konkurrenten ein ähnliches Produkt oder eine ähnliche Dienstleistung anbieten. (vgl. Wolenik, 2014, S. 290ff) Arbeiten im Kundenservice Im Bereich Kundenservice können Ressourcen wie Zeit, Räume und Personen verwaltet werden. Dazu können Serviceaktivitäten genutzt werden. (vgl. Wolenik, 2014, S. 302) In Abbildung 3.5 ist ein Überblick der Entitäten abgebildet: Ressource 1..* 1..* 1 Serviceaktivität 0..* Vertrag 1 1 Firmenkunde 1 Servicekalender 1 0..* 1 Termin Case Wissensdatenbank 1 0..* Article Abbildung 3.5 Dynamics CRM-Klassendiagramm Kundenservice Im Dynamics CRM integrierten Servicekalender werden die Serviceaktivitäten erstell. (vgl. Wolenik, 2014, S. 308ff) Sollte die Outlook-Integration in Dynamics CRM aktiviert sein, werden diese mit dem Outlookkalender des jeweiligen Benutzers synchronisiert und als Termine angezeigt. (vgl. Wolenik, 2014, S. 300f) Auch Termine, welche keine Serviceaktivitäten sind, können eingetragen werden. (vgl. Wolenik, 2014, S. 317) Aus diesen Terminen können Verkaufschancen oder Cases generiert werden. (vgl. Wolenik, 2014, S. 318) Aus Cases können Wissensartikel erzeugt werden. Diese können in einer Wissensdatenbank gesammelt werden und beschreiben wie ein Problem gelöst oder eine Frage beantwortet wurde. (vgl. Wolenik, 2014, S. 327) Zur Verplanung der Ressourcen gehört auch die Monetarisierung der Leistungen. Um die Monetarisierung zu verwalten bietet Dynamics CRM die Entität Vertrag an. In dieser wird

41 Systemanalyse festgehalten, zu welchen Konditionen und in welchen Zeiträumen die Kunden Leistungen erhalten. (vgl. Wolenik, 2014, S. 337ff). 3.3 Gemeinsamkeiten der Systeme Auf den ersten Blick haben beide Systeme kaum Gemeinsamkeiten. SharePoint ist ein Enterprise Content Management System und Dynamics CRM ist ein Verwaltungssystem für Kundendaten. Wenn die Systeme genauer betrachtet werden, wird deutlich, dass beide Systeme die Arbeitsabläufe in einem Unternehmen vereinfachen und beschleunigen können. Beide Systeme sind so flexibel, dass die Anwendungsbereiche ineinander übergehen und für viele Bereiche sowohl SharePoint, als auch Dynamics CRM genutzt werden kann. Tabelle 3.4: Gemeinsamkeiten und Unterschiede der Systeme Anwendungsbereich SharePoint Dynamics CRM Content Management Dokumentenmanagement Kollaboration Business Intelligence Geschäftsprozesse SharePoint ist ein Content Management Systems Dokumente können gesichert, bearbeitet und versioniert werden. Dynamics CRM ist kein Content Management System Dokumente können an Entitäten angehängt werden. Sie können danach nicht mehr bearbeitet werden. Die Zusammenarbeit wird durch gemeinsame Bearbeitung von Elementen und Wissensbereitstellung unterstützt. SharePoint verfügt über Möglichkeiten zur Auswertung der Inhalte, besitzt aber keine standardisierten Listen für Unternehmenszahlen. Dynamics CRM verfügt über Möglichkeiten zur Auswertung der Inhalte, wie beispielsweise Kunden-, Vertriebs- und Marketingdaten. In beiden Systemen können Workflows zur Geschäftsprozesunterstützung implementiert werden. Weitere Gemeinsamkeiten der Systeme sind die Schwierigkeiten, die bei der Umsetzung auftreten können: - Vom Umsetzungsteam wird die Struktur und der Aufbau des Systems nicht vollständig geplant. - Den Benutzern ist nicht klar, wofür und wie die Systeme genutzt werden können. - Die Bereitstellung erfolgt als Komplettpacket, welches oft zu umfangreich für einen schnellen Einstieg ist. - Die Benutzer werden bei der Anforderungsanalyse nicht ausreichend eingebunden. (vgl. Schmidt, 2013, S. 3ff) und (vgl. Reh, 2011)

42 Systemanalyse 3.4 Zusammenfassung der Funktionen Viele Anwender haben nur eine geringe Vorstellung, welchen Funktionsumfang SharePoint und Dynamics CRM besitzen. In diesem Abschnitt wird verdeutlicht, welche Funktionen beide Systeme abdecken. Die Funktionen wurden anhand einer systematischen Literaturrecherche erhoben und durch Tests verifiziert. Abschließend wurden die Funktionen in Kategorien unterteilt, um eine bessere Übersicht und Auswertung gewährleisten zu können. Als Kategorien wurden die oben genannten Anwendungsbereiche Content Management, Dokumentenmanagement, Kollaboration, Business Intelligence und Geschäftsprozesse gewählt. Zusätzlich wurde die Kategorie Allgemein hinzugefügt, da nicht alle Funktionen eindeutig durch einen technischen Experten für Dynamics CRM und SharePoint zugeordnet werden konnten. Insgesamt konnten 109 Funktionen aus der Literaturrecherche gewonnen werden, von denen 89 durch SharePoint und 62 durch Dynamics CRM umsetzbar sind. In Tabelle 3.5 kann die Aufteilung betrachtet werden. 17 Tabelle 3.5: quantitatives Ergebnis der Funktionsanalyse Anzahl der Funktionen in SharePoint in Dynamics CRM Allgemein Content Management Dokumentenmanagement Kollaboration Geschäftsprozesse Business Intelligence Reflexion Beide Systeme haben starke Anpassungsmöglichkeiten, weshalb die Funktionen nicht unbedingt eins zu eins aufgelistet werden können, da durch das Erstellen neuer Listen und Ansichten sowie Felder und Formulare neue Funktionen geschaffen werden. Um zu entscheiden, welche Möglichkeiten die Systeme bieten, reicht eine reine Funktionsanalyse der Standardinstallationen nicht aus. Um aussagekräftigere Ergebnisse zu erhalten, sollten Systeme, welche in Benutzung sind, analysiert werden. Diese Untersuchung sollte auch den Umfang der Systemanpassungen berücksichtigen. 17 Die Auflistung der einzelnen Funktionen kann dem Anhang B entnommen werden

43 Zielgruppenanalyse und Anforderungserhebung 4 Zielgruppenanalyse und Anforderungserhebung In dieser Arbeit wird die Zielgruppe Mittelstand betrachtet. Da diese Zielgruppe sehr umfangreich ist, wird eine Subzielgruppe abgesteckt. Dazu dienen Interviews, die mit Vertriebsberatern und Consultants für kleine und mittelständische Unternehmen durchgeführt werden. 4.1 Das Interview Als Interviewform wird ein halboffenes Experteninterview auf Basis eines Leitfadens gewählt. Dies ermöglicht, dass Experten in Ihren Antworten nicht eingeschränkt werden und so ein Dialog zwischen Experte und interviewendem Co-Experten begünstigt wird. Um eine Vergleichbarkeit der Interviews zu gewährleisten, müssen jeweils alle Themen abgedeckt werden. In welcher Reihenfolge die Themen bearbeitet werden, hat keinen Einfluss. (vgl. Misoch, 2014, S. 13) Vorbereitung des Interviews Vor der Durchführung der Interviews wurde von jedem zu interviewenden Experten eine Einverständniserklärung eingeholt. Diese Einverständniserklärung und der Leitfaden des Interviews können in Anhang C Interviewdokumente eingesehen werden. Um zu prüfen, ob die Themen und Fragen des Leitfadens aussagekräftige Antworten hervorbringen, wurde ein Pretest durchgeführt. Dadurch wurde festgestellt, dass die Fragen im Bereich der Geschäftsprozesse zu abstrakt waren und kein Redefluss des Befragten eintrat. Diese Fragen wurden konkretisiert. Das Testinterview wurde nicht gewertet. Um fortwährend neue Erkenntnisse mit den geführten Interviews zu gewinnen, wurden die Fragen und der Leitfaden zwischen den einzelnen Interviews angepasst. Der dem Anhang beigefügte Leitfaden ist die Endfassung. So konnte ein möglichst weites Spektrum an Informationen gesammelt werden. Der Inhalt der Einverständniserklärung richtet sich nach Kapitel 1.4 Ethische Grundprinzipien qualitativer Interviews aus dem Werk Qualitative Interviews von Sabina Misoch. (vgl. Misoch, 2014, S. 20f) Samplings Mit Hilfe der Interviews werden folgende Forschungsfragen beantwortet: RQ3: RQ4.2: Welche Eigenschaften besitzen Unternehmen, die erfolgreich mit SharePoint und Dynamics CRM arbeiten? Welche Anforderungen haben mittelständische Unternehmen? Es wurden Nutzer dieser Systeme und die Vertriebler eines fast 100 Angestellten großen IT- Dienstleisters befragt. Alle Mitarbeiter des Unternehmens sind auch Nutzer, da beide Systeme in ihrem Tagesgeschäft eingesetzt werden. Die Vertriebler sind neben ihrer Vertriebstätigkeit auch für die Anforderungsanalysen zuständig. Daher belief sich das erste Sampling auf drei Vertriebler, welche für kleine Unternehmen mit weniger als 100 Beschäftigten zuständig sind

44 Zielgruppenanalyse und Anforderungserhebung und auf drei Vertriebler, welche für größere Unternehmen ab 100 Beschäftigten zuständig sind. In diesem ersten Durchlauf der Interviews, gingen die Befragten nicht nur auf die Anforderungen der Systeme ein sondern auch auf die Benutzerakzeptanz. Deshalb wurde für den zweiten Durchlauf folgende Forschungsfrage mit betrachtet: RQ6: Warum ist die Benutzerakzeptanz dieser Systeme so gering? Das zweite und letzte Sampling wurde durch Consultants erweitert. Es ergaben sich 5 neue Interviewsituationen mit folgenden Befragten: - Zwei Consultants für kleine Unternehmen mit weniger als 100 Beschäftigten und mit dem Schwerpunkt auf Infrastrukturbereitstellung. - Ein Consultant für größere Unternehmen ab 100 Beschäftigten und mit dem Schwerpunkt auf Bereitstellung von Unternehmenssoftware. - Ein Teamleiter, welcher als Vertriebler und Consultant tätig ist. Er betreut große Unternehmen ab 100 Beschäftigten bei der Auswahl und Bereitstellung von Unternehmenssoftware. - Ein Vertriebler für kleine Unternehmen mit weniger als 100 Beschäftigten. - Ein Vertriebler für größere Unternehmen mit mehr als 100 Beschäftigten. Der Leitfaden wurde bezüglich der hinzugefügten Forschungsfrage erweitert und an das neue Sampling angepasst Erstellung des Leitfadens und Durchführung der Interviews Das Interview und der Leitfaden wurden nach der Offenheit als erkenntnistheoretisches Prinzips erstellt und durchgeführt. Das bedeutet, dass bei der Erstellung des Leitfadens und der Durchführung der Interviews zwar eine klare Richtung der Fragen existierte, jedoch noch keine formulierte These, welche durch die Interviews bewiesen oder widerlegt werden sollte. Damit wird gewährleistet, dass sich der Interviewende nicht auf bestimmte Fragen versteift und neue Fragen während eines Interviews auftreten können. Es ist für den Interviewenden so möglich mehr auf die Aussagen des Experten einzugehen, um aus seinem breiten Erfahrungsschatz zu schöpfen. (vgl. Misoch, 2014, S. 28f)

45 Zielgruppenanalyse und Anforderungserhebung Der Leitfaden orientiert sich an vier Phasen: 1. Informationsphase: Klärung des Zwecks des Interviews, Einweisung des Befragten und Unterzeichnung der Einverständniserklärung 2. Aufwärm- und Einstiegsphase: Sehr allgemeine Fragen zur Person und deren Tätigkeit 3. Hauptphase: Bearbeitung der Themen Dokumentenmanagement, Kollaboration, Geschäftsprozesse, Business Intelligence und Projektmanagement im Dialog mit der zu interviewenden Person 4. Ausklang und Abschlussphase: Frage nach möglichen Ergänzungen, abseits der bisherigen Aussagen (vgl. Misoch, 2014, S. 68f) Die Hauptphase ist in fünf Themen Dokumentenmanagement, Kollaboration, Business Intelligence, Geschäftsprozesse und Projektmanagement mit jeweils 3 Fragen gegliedert Auswertung der Interviews Direkt nach der Durchführung der Interviews wurde eine Einschätzung unternommen, inwiefern die Interviews für die Auswertung von Bedeutung sind. Dabei sind Faktoren wie Befangenheit, Erfahrung und Bereitschaft der Experten ausschlaggebend. Drei der geführten Interviews wurden dadurch von der weiteren Bearbeitung ausgeschlossen. So wurden neun relevante Interviews in zwei Durchgängen ausgewertet. Für die Analyse der Experteninterviews schlägt Sabina Misoch folgende fünf Schritte vor: 1. Transkription Beim Transkribieren eines Experteninterviews ist es nicht vorgesehen ein komplettes Transkript anzufertigen. Sabina Misoch gibt zu bedenken, dass dabei Daten verloren gehen können, weil sie während des Transkribierens für unwichtig erachtet werden. Damit nicht schon im ersten Schritt wichtige Daten übersehen werden, sollen daher vollständige standardorthografische Transkripte angefertigt werden. 2. Paraphrase Nachdem das Transkript erstellt wurde, soll dieses paraphrasiert werden, um die Aussagen inhaltsgetreu zusammenzufassen. 3. Codierung Bei der Codierung werden Teile aus den Transkripten thematisch zugeordnet. Dabei kann der gleiche Transkriptausschnitt auch zu mehreren Codes gehören. 4. Thematischer Vergleich Die den Codes zugeordneten Ausschnitte werden in diesem Schritt zusammengefasst. 5. Typologische Analyse Nun wird das gesamte Material den einzelnen Codes zugeordnet, dabei werden alle Interviews zusammengefasst

46 Zielgruppenanalyse und Anforderungserhebung Dabei werden die Schritte 1. bis 4. nacheinander auf ein Interview angewendet. Abschließend werden alle Interviews mit dem 5. Schritt zusammengefasst. (vgl. Misoch, 2014, S. 124ff) Dieses Verfahren wurde nach dem ersten Sampling für 4 Interviews und nach dem zweiten Sampling mit weiteren 5 Interviews durchgeführt. Nachdem die Transkripte nach der typologischen Analyse thematisch zusammengefasst wurden, konnten je Themengebiet vier für die weitere Bearbeitung relevante Kategorien definiert werden: - K1: Benutzergruppen, die in diesem Themengebiet Software zur Unterstützung einsetzen - K2: Benutzergruppen, die in diesem Themengebiet keine Software zur Unterstützung nutzen - K3: Anforderungen an Systeme zu diesen Themen - K4: Gründe für die geringe Benutzerakzeptanz 4.2 Zielgruppenanalyse Für die Zielgruppenanalyse wurde an den zusammengefassten Transkripten aus dem zweiten Sampling eine qualitative Inhaltsanalyse durchgeführt. Dabei wurden die Ursachen für die Nutzung und Nicht-Nutzung von Software zur Unterstützung in den einzelnen Themengebieten gesammelt und veranschaulicht. Die Ursachen wurden nach den Charakteristiken, welche Hans-Christian Pfohl in der Charakterisierung von Klein-, Mittelund Großbetrieben erarbeitet hat, sortiert werden. Dabei stellten sich folgende Gruppen heraus: - Größe des Unternehmens - Gruppenentscheidungen - Formalisierungsgrad Weitere Charakteristiken, die in den Interviews genannt wurden, aber Hans-Christian Pfohl nicht aufzählt sind: - Alter des Unternehmens - Zukunftsorientierung - Standortverteilung - Alter der Mitarbeiter - Beziehung der Mitarbeiter untereinander - Teambildung Die Gruppen Größe des Unternehmens, Alter des Unternehmens und Alter der Mitarbeiter hatten sehr gestreute Aussagen, weshalb diese nicht weiter zur Subzielgruppendefinition herangezogen wurden

47 Zielgruppenanalyse und Anforderungserhebung In den anderen Gruppen bildeten sich die in Tabelle 4.1 vorgestellten Kernaussagen heraus: Tabelle 4.1: Ergebnisse der Zielgruppenanalyse Gruppe Kernaussage Gruppenentscheidungen Ein Unternehmen, welches Wert auf Gruppenentscheidungen legt, kann in der Regel Social Media im Unternehmen nutzen. Formalisierungsgrad Zukunftsorientierung Standortverteilung Beziehung der Mitarbeiter untereinander Ein Unternehmen, welches seine Geschäftsprozesse formalisiert, kann diese in der Regel in Systeme implementieren. Ein Unternehmen, welches zukunftsorientiert arbeitet, kann in der Regel Business Intelligence gewinnbringend nutzen. Ein Unternehmen, welches auf mehrere Standorte verteilt ist, kann in der Regel Social Media im Unternehmen nutzen. Je besser die Beziehungen der Mitarbeiter untereinander ist, desto erfolgreicher ist die Kollaboration im Unternehmen. Somit kann Forschungsfrage RQ3: Welche Eigenschaften besitzen Unternehmen, die erfolgreich mit SharePoint und Dynamics CRM arbeiten? wie folgt beantwortet werden: Die Subzielgruppe, welche aus den Ergebnissen der Interviews definiert wurde, besteht aus Unternehmen mit folgenden Eigenschaften: - Das Unternehmen trifft mehr Gruppenentscheidungen, als dass es den Einzelentscheidungen der Geschäftsführung blind verfolgt. - Das Unternehmen hat einen vergleichbar hohen Formalisierungsgrad. - Das Unternehmen ist eher zukunftsorientiert als gegenwartsorientiert. - Das Unternehmen ist über mehrere Standorte verteilt. - Die Mitarbeiter des Unternehmens haben tendenziell gute Beziehungen zueinander. 4.3 Anforderungserhebung Auch für die Anforderungen wird eine qualitative Inhaltsanalyse nach dem zweiten Sampling durchgeführt. Nach der Zusammenfassung der Transkripte gibt es fünf Unterkategorien zu K3: K3T1 Anforderungen an Dokumentenmanagementsysteme K3T2 Anforderungen an Kollaborationssysteme K3T3 Anforderungen an Systeme zur Unterstützung bei Business Intelligence K3T4 Anforderungen an Systeme zur Geschäftsprozessunterstützung K3T5 Anforderungen an Projektmanagementsysteme

48 Zielgruppenanalyse und Anforderungserhebung Dabei werden die einzelnen Anforderungen aus den Transkripten als kurze Aussage notiert und auf Duplikate geprüft. Das vollständige Ergebnis dieser Anforderungserhebung kann im Anhang D eingesehen werden. Die weitere Bearbeitung der Ergebnisse wird im Kapitel 5 beschrieben. Die Liste der Anforderungen stellt die Beantwortung der RQ4.2: Welche Anforderungen haben mittelständische Unternehmen? dar. 4.4 Reflexion Für die Zielgruppendefinition und die Erfassung der Anforderungen würde ein drittes Sampling mit Beobachtungen der Angestellten in Unternehmen bei der Arbeit mit Dokumenten, im Controlling und im Projektmanagement, sowie der Kommunikation zwischen den Angestellten genauere Erkenntnisse liefern. Auch die Einsicht der Geschäftsprozessdokumentationen, sofern vorhanden und die Befragungen der Benutzer nach deren Zufriedenheit würde mehr Variabilität in die vorangegangene Statistik einfließen lassen. Die Informationen aus den Experteninterviews bieten einen eingeschränkten Blickwinkel auf Benutzer und Systeme. Sie wurden gewählt, weil wenige Geschäftsführer die Prozesse und Dokumente ihres Unternehmens für die Forschung offen legen wollen und weil der Zugang zu den Beobachtungen und die Auswertungen der Geschäftsprozessdokumentation zeitlich nicht in dem Rahmen der Arbeit durchführbar waren. Eine qualitative Auswertung von Unternehmen bezüglich der Ursachen für die Nutzung und Nicht-Nutzung von Software zur Unterstützung in den einzelnen Themengebieten bietet sich für SharePoint und Dynamics CRM zusätzlich zu den durchgeführten qualitativen Interviews an. Bei der Erstellung des Fragebogens können die Charakteristiken von Hans-Christian Pfohl und die Charakteristiken aus den Interviews herangezogen werden. Bei der Auswertung des Fragebogens ist darauf zu achten, dass keine zwei Bögen von Probanden aus demselben Unternehmen einfließen, weil dies das Ergebnis verfälschen würde. Daher müssen die Antworten vor der Auswertung auf Duplikate geprüft werden

49 Erstellung des Anforderungskatalogs 5 Erstellung des Anforderungskatalogs Der Anforderungskatalog soll dazu dienen, die Komponenten der Systeme anhand der Zielgruppen und deren Anforderungen zu bestimmen. Mit Hilfe des Katalogs soll entschieden werden können, ob SharePoint, Dynamics CRM oder beide Systeme für Unternehmen geeignet sind. Die Erstellung des Katalogs dient gleichzeitig zur Beantwortung der Forschungsfrage: RQ4.3: Wie können die Funktionen und Anforderungen miteinander verglichen werden? Um den Anforderungskatalog zu erstellen, werden die Ergebnisse aus den vorangegangenen Kapiteln genutzt. Zu Beginn ist es sinnvoll, die Anforderungen den Zielgruppen zuzuordnen, um damit eine Vorauswahl der relevanten Anforderungen treffen zu können. Da ausschließlich wenige Eigenschaften der Subzielgruppe definiert werden konnten, wird dieser Ansatz nicht weiter verfolgt. Es wird nur die Verknüpfung zwischen den Anforderungen aus der vorangegangenen Erhebung und den Funktionen aus der Funktionsanalyse hergestellt. Die gewonnen Daten besitzen kein einheitliches Format und sind untereinander nicht direkt vergleichbar, weshalb ein semantischer Ansatz gewählt wird. Es ergeben sich folgende Ansätze: 1. Das Erstellen mehrerer Ontologien, die im Anschluss mit einem Ontologie-Matching miteinander verglichen werden. 2. Das Erstellen einer Ontologie, die beide Systeme beschreibt und durch SPARQL 18 - Abfragen entscheiden kann, welches System geeignet ist. Werden mehrere Ontologien erstellt, so ergeben sich die drei folgenden semantischen Netze. Eine Ontologie beschreibt SharePoint, eine andere Dynamics CRM und die dritte beschreibt die Anforderungen eines spezifischen Unternehmens an die beiden Systeme. In diesem Fall müssen Matchings zwischen SharePoint-Ontologie und Anforderungsontologie sowie zwischen Dynamics CRM-Ontologie und Anforderungs-Ontologie durchgeführt werden. Im Anschluss kann durch einen Vergleich der Größe der Deckungsbereiche bestimmt werden, welches System für das Unternehmen mit den gegebenen Anforderungen geeigneter ist. Der zweite Ansatz erfordert eine Ontologie, welche sowohl SharePoint, als auch Dynamics CRM abbildet. Die Anforderungen werden durch eine Reihe von SPARQL-Abfragen abgebildet, welche ein definitives Ergebnis ausgeben. Dieses kann SharePoint, Dynamics CRM, beide Systeme oder keines sein. Aus den daraus erhaltenen Ergebnissen kann nachfolgend ein Deckungsbereich gebildet werden. Vorteile dieses Ansatzes sind zum einen eine mögliche Gewichtung der SPARQL-Abfragen, zum anderen führt das Erstellen einer Ontologie zu einem Zeitgewinn. Eine Erweiterung des Anforderungskatalogs, kann im Gegensatz zu dem ersten Ansatz unproblematisch durchgeführt werden. 18 Abfragesprache für Ontologien

50 Erstellung des Anforderungskatalogs Tabelle 5.1: Vergleich der Ontologieansätze Anzahl der Ontologien Vergleich durch Gewichtung der Anforderungen Erweiterung um ein neues System mehrere Ontologien eine Ontologie je System und eine für die Anforderungen das Messen der Übereinstimmungen der Ontologiegraphen ist durch die Erweiterung der Ontologie möglich durch die Erstellung einer neuen Ontologie eine Ontologie eine Ontologie für alle Systeme SPARQL-Abfragen ist durch die Gewichtung der SPARQL-Abfragen möglich durch das Erweitern der Ontologie Auf Grund der in Tabelle 5.1 dargestellten Vorteile des zweiten Ansatzes wird dieser für die weitere Bearbeitung verwendet. Zunächst wird eine Ontologie, die beide Systeme beschreiben soll, erstellt. In einem weiteren Schritt werden die SPARQL-Abfragen ausgearbeitet. Abschließend wird ein Konzept für einen Prototypen entwickelt, welcher auf die Ontologie und den Abfragen aufbaut. 5.1 Erstellung der Ontologie Eine Ontologie ist ein Netz aus Tripeln, welche aus Subjekt, Prädikat und Objekt bestehen. Subjekte und Objekte sind Konzepte, beziehungsweise Klassen, welche Teile der realen Welt beschreiben, während Prädikate Beziehungen zwischen den Klassen darstellen. Die Erstellung einer Ontologie erfolgt in den unten beschriebenen Schritten: 1. Fokussierung des Anwendungsgebiets 2. Wiederverwendung von bestehenden Ontologien 3. Identifikation relevanter Begriffe 4. Festlegung der Klassenhierarchie 5. Definition von Relationen Diese Schritte werden auf die zuvor erarbeitete Funktionsliste angewandt. (vgl. Stuckenschmidt, 2009) Fokussierung des Anwendungsbereichs Die Fokussierung des Anwendungsbereichs dient dazu, abzugrenzen welche Informationen in der Ontologie abgebildet werden. Dabei können Competency Questions genutzt werden, bei denen es sich um Fragen handelt, welche später durch die Ontologie beantwortet werden können. Für die Ontologie, welche die Funktionen von SharePoint und Dynamics CRM abbildet, wurden folgende Bereiche mittels der Competency Questions abgedeckt: - Nennung der Komponenten je System. - Beschreibung der Funktionen je System und Komponente

51 Erstellung des Anforderungskatalogs Wiederverwendung von bestehenden Ontologien Die Recherche innerhalb der Universitätsbibliothek Hannover und diverser Internetquellen ergab, dass keine klassische oder bewährte Ontologie existiert, welche den Anforderungen in Hinblick auf SharePoint und Dynamics CRM genügen. Daher muss eine neue und individuelle Ontologie für diese Systeme erstellt werden. Identifikation relevanter Begriffe Um die relevanten Begriffe zu identifizieren, wurde die Funktionsliste analysiert und die wesentlichen Klassen, Objekte und Relationen definiert. Es wurden in diesem Schritt noch keine Klassen, Objekte und Relationen miteinander verknüpft. Festlegung der Klassenhierarchie Nachdem die einzelnen Klassen definiert wurden, werden diese miteinander in Verbindung gesetzt. Die Zuordnung der relevanten Begriffe in Objekte und Klassen konnte nach zwei Ansätzen erfolgen. Abstrakte Komponenten werden in der Ontologie als Klassen behandelt In der Funktionsanalyse wurde nicht mit konkreten Komponenten gearbeitet. Alle Komponenten sind abstrakt. Aus ihnen können verschiedene konkrete Komponenten erzeugt werden. Zum Beispiel ist die Aufgabenliste aus der Funktionsanalyse eine abstrakte Komponente, weil diese nicht existiert. Benutzer können verschiedene Instanzen der Aufgabenliste erzeugen. In der Ontologie kann dieses Verhalten abgebildet werden. Die Komponenten aus der Funktionsanalyse wären Klassen, keine Instanzen. Die Ontologie würde fast ohne Instanzen erstellt werden, könnte allerdings erweitert werden, um ein konkretes, bereits installiertes und genutztes System zu repräsentieren. Dann könnte die Ontologie auch dazu genutzt werden, zu ermitteln, welche der Anforderungen umgesetzt sind und in wie weit das SharePoint oder Dynamics CRM dem Kundenwunsch entspricht. Abstrakte Komponenten werden in der Ontologie als Instanzen behandelt Ausgewählte Komponenten aus der Funktionsanalyse werden, obwohl diese nicht konkret sind, in der Ontologie als Instanz dargestellt. Somit ist zum Beispiel die Aufgabenliste die Instanz der Klasse Liste. Wenn die abstrakten Komponenten als Klassen behandelt werden, müssen die SPARQL- Abfragen auf die Range 19 der Prädikate basieren. Sofern die abstrakten Komponenten Instanzen sind, basieren die Abfragen auf den Subjekten. Die Erweiterung der Ontologie um konkrete Komponenten ist nicht möglich, wenn die abstrakten Komponenten als Klassen behandelt werden. Da dies keine Voraussetzung des Anforderungskatalogs darstellt, werden ausgewählte abstrakte Komponenten als Instanzen 19 Die Range bestimmt den Wertebereich einer Beziehung

52 Erstellung des Anforderungskatalogs dargestellt. Daher konnte folgendes Klassendiagramm 20 (vgl. Abbildung 5.1) definiert werden. Präsentationsansicht Kollaboarations_Komponenten Controlling_Komponente Prozessunterstützungs_Komponenten Richtlinien System App Suche Vorlage Website Prozess Import Datei Bibliothek Export Menüband Menü Feld Formular Ziel Dashboard Ansicht Ansicht Liste Element Externe_Ressourcen Mobiles_Gerät WCM_System Anhang Abbildung 5.1: Klassendiagramm der konstruierten Ontologie Definition der Relationen Abschließend zur Erstellung der Ontologie werden die Relationen definiert und mit den Klassen kombiniert. Dabei müssen alle Tripel auf eines der Systeme abgeleitet werden können. Ein Beispiel sei gegeben durch die Tripel Ƭ1(SharePoint, hat, Aufgabenliste) und Ƭ2(Benutzer, kann_erstellen, Aufgabenliste). Während bei Ƭ1 eine direkte Zuordnung möglich ist, ist dies bei Ƭ2 nicht möglich, da weder das Subjekt noch das Objekt das System darstellt. Die Ableitung, dass in SharePoint eine Aufgabenliste erstellt werden kann, ist Interpretation, da beide Prädikate nicht transitiv zueinander sind. Daher werden Ƭ1 und Ƭ2 zu Ƭ[1+2] (Aufgabenliste, kann_erstellt_werden_in, SharePoint) zusammengefasst. 20 In der Ontologie werden Entitäten und Datensätze unter Elemente und Apps und Solutions unter Apps zusammengefasst

53 Erstellung des Anforderungskatalogs Als URI 21 für die Beschreibung der Ontologie wurde gewählt. Nach der Erstellung der beide Systeme beschreibenden Ontologie 22 wurden die SPARQL-Abfragen definiert. 5.2 Erstellen der SPARQL-Abfragen Die Anforderungen wurden in der Anforderungserhebung gesammelt, jedoch nicht einheitlich formuliert. Bevor die Abfragen erstellt werden, ist es erforderlich die Anforderungen in ein einheitliches Format zu überführen. Hierfür wurde ebenfalls ein Ansatz mit Tripeln gewählt, welcher der Form des Tripels der Ontologie ähnelt. Dabei stellt das letzte Element eines Tripels einen Platzhalter dar, welcher für ein beliebiges System steht. Eine Anforderung hat somit folgenden Aufbau: (Subjekt, Prädikat, Systemplatzhalter) Aus der Anforderung Es sollen Aufgabenlisten erstellt werden können entsteht das Tripel: (Aufgabenliste, soll_erstellt_werden_können_in, Systemplatzhalter) Die daraus resultierenden Subjekte werden mit den Instanzen der Ontologie verglichen. Dabei stellt sich heraus, dass einige der Subjekte und Instanzen zueinander kongruent sind. Subjekte, welche nicht als Instanzen der Ontologie vorkommen, werden darauf geprüft, ob diese denselben Wortstamm besitzen oder Synonyme für Instanzen sind. Trifft dies zu, wird das Subjekt durch die Instanz ausgetauscht, sonst wird das Subjekt als Instanz der Ontologie hinzugefügt. Auch die Prädikate der Anforderungen werden mit den Beziehungen der Ontologie verglichen. Zu verschiedenen Prädikaten existieren Beziehungen, welche dieselbe Bedeutung besitzen, jedoch anders konjugiert sind, wie beispielsweise das Prädikat soll_erstellt_werden_können_in und die dazu gleichartige Beziehung kann_erstellt_werden_in. Anhand dieser Vergleiche werden die Anforderungstripel in SPARQL-Abfragen übersetzt. Die Abfrage zur oben genannten Anforderung sieht wie folgt aus: SELECT WHERE { }?system unternehmenssoftware:aufgabenliste unternehmenssoftware:kann_erstellt_werden_in?system. 5.3 Konzept des Anforderungskatalogs Damit der Anforderungskatalog als Prototyp umgesetzt werden kann, wird ein Konzept erstellt. Die Erstellung des Konzepts baut auf die Ergebnisse der Bearbeitung der Forschungsfragen RQ4.1 Welche Funktionen haben die Systeme?, RQ4.2: Welche 21 Eine URI ist ein einheitlicher Bezeichner für Daten im Internet. 22 In Anhang E sind die Tripel der Ontologie aufgelistet

54 Erstellung des Anforderungskatalogs Anforderungen haben mittelständische Unternehmen? und RQ4.3: Wie können die Funktionen und Anforderungen miteinander verglichen werden? auf und dient der Beantwortung der Forschungsfrage: RQ4: Wie muss ein Anforderungskatalog für solche Systeme aufgebaut sein? Benutzeroberfläche In einer grafischen Oberfläche, welche in Abbildung 5.2 schematisch dargestellt ist, können die Anforderungen aktiviert oder deaktiviert werden. Über ein Feld am rechten Rand können Wertungen zwischen 1 und 5 eingetragen werden. Der Benutzer kann durch fünf Reiter, in denen die Anforderungen thematisch sortiert sind, navigieren. Anforderungskatalog Dokumentenmanagement Kollaboration Business Intelligence Geschäftsprozesse Projektmanagement Dokumente sollen gespeichert werden können Dokumente sollen bearbeitet werden können Dokumente sollen gleichzeitig bearbeitet werden können Dokumente sollen versioniert werden können Dokumente sollen kopiert werden können eingescannte Dokumente sollen verwaltet werden können zu Dokumenten sollen Notizen angefügt werden Dokumentvorlagen sollen verwaltet werden Dokumente sollen übersichtlich abgelegt werden Dokumente müssen schnell gefunden werden Dokumentenmanagement: Kollaboration: Business Intelligence: Geschäftsprozesse: Projektmanagement: Insgesamt: SharePoint 74% 63% 26% 65% 31% 58% CRM 21% 43% 73% 67% 16% 52% Abbildung 5.2: schematische Darstellung des Prototyps Als Ergebnis wird die Größe des Deckungsbereichs in Prozent angegeben. Es wird keine Einzelauswertung je Anforderung angezeigt, damit der Nutzer sich nicht auf die Anforderungen eines Systems fokussiert. Der Deckungsbereich wird bei jeder Änderung in der Ansicht neu berechnet. Der mit dem Anforderungskatalog arbeitende Requirements Engineer kann dann anhand der Ergebnisse die Empfehlung aussprechen welches System oder welche Kombination aus beiden Systemen eingeführt wird

55 Erstellung des Anforderungskatalogs Berechnung des Deckungsbereichs Für die Berechnung des Deckungsbereichs prüft der Anforderungskatalog über die SPARQL- Abfragen je Anforderung, für welches System die ausgewählten Anforderungen in der Ontologie vorhanden sind. Wenn dies zutrifft, wird die Wertung auf die Summe der umsetzbaren Anforderungen addiert. Danach wird die Summe der umsetzbaren Anforderungen durch die Summe aller ausgewählten Anforderungen geteilt. Das Ergebnis ist das Maß des Deckungsbereichs. Diese Berechnung wird für alle Anwendungsbereiche einzeln und insgesamt durchgeführt. Diese Berechnung wurde in Abbildung 5.3 in Pseudocode umgesetzt. global map systems; anforderungwurdeaktiviert(anforderung){ results = Ontologie.query(anforderung.getSparqlAbfrage(); foreach(results as result){ system = systems.getvaluebykey(result); deckungsbereich = system.getdeckungsbereichbyanfoderung(anforderung); deckungsbereich.calculate(); system.calculate(); } } calculate(){ a = this.numberofallanforderungen(); b = this.numberofwantedanforderungen(); summe = b/a } Abbildung 5.3: Pseudocode für die Berechnung des Deckungsbereichs

56 Erstellung des Anforderungskatalogs Programmaufbau des Prototypen Der Prototyp soll nach dem Model-View-Controller-Pattern 23, welches in Abbildung 5.4 dargestellt ist, umgesetzt werden. Model benachrichtigt lädt Daten ändert Daten View Events Controller Abbildung 5.4: Model-View-Controller-Pattern (Gamma, Helm, Johnsin, & Vlissides, 2009) Die View soll, wie oben dargestellt, umgesetzt werden. Das Modell besteht aus vier Klassen: Anforderung, Themenbereich, Deckungsbereich und System, welche in Abbildung 5.5 visualisiert werden. ThemenBereich Anforderung - id:int - label:string - sparql:string - selected:boolean - value:int 0..* 0..* id:int - label:string 0..* DeckungsBereich - value:float 1 0..* 1 System - id:int - label:string - uri:string Abbildung 5.5: Modell des Prototyps Die Klasse Deckungsbereich ist die Menge der erfüllten Anforderungen eines Systems. In diesem Set werden alle Anforderungen referenziert, unabhängig davon, ob die Anforderung ausgewählt ist. Erst bei der Berechnung wird geprüft, ob die Anforderung ausgewählt ist. 23 Eine Möglichkeit Code zu strukturieren um Ansichtskomponente, Businesslogik und Datenmodell voneinander zu trennen

57 Erstellung des Anforderungskatalogs Der Controller wird durch die Implementierung eines ActionListener umgesetzt. Dieser ActionListener kontrolliert Änderungen der Attribute selected und value in der View. Eine Veränderung der Werte bedingt eine Neuberechnung der Deckungsbereiche. (vgl. Abbildung 5.6) ActionListener DeckungsBereichsController - berechnedeckungsbereich():void Abbildung 5.6: Controller des Prototyps Die Anforderungen und Systeme werden bei Start des Prototyps geladen. Danach werden die Deckungsbereiche mit allen erfüllten Anforderungen erzeugt. Die Anforderungen und Systeme werden in einer Datenbank gepflegt. Die Prüfung, durch welches System eine Anforderung umgesetzt werden kann, erfolgt in der Ontologie. Somit gibt es im Prototyp zwei Schnittstellen. Eine Schnittstelle zur Datenbank und eine Schnittstelle zur Ontologie. (vgl. Abbildung 5.7) Persistence Ontology - getallsysteme():list<system> - getallanfoderungen():list<anforderung> - getsystemebyanforderung(anforderung):list<system> Abbildung 5.7: Schnittstellen des Prototyps Die Datenbank beschreibt zwei Tabellen: Anforderung und System (vgl. Abbildung 5.8) id id label Anforderung System label sparql uri Abbildung 5.8: EER-Modell der Datenbasis des Prototyps

58 Erstellung des Anforderungskatalogs 5.4 Reflexion Der semantische Ansatz, der in diesem Kapitel gewählt wurde, bietet die Möglichkeit die abstrakten Funktionen, die ein SharePoint bieten kann, abzudecken. Das Wissen über die Funktionen ist durch die Ontologie begrenzt. Es herrscht kein Anspruch auf Vollständigkeit. Auch das statische Matching durch die SPARQL-Abfragen, ist nicht allumfassend, da die Verknüpfungen innerhalb der Ontologie nicht genutzt werden. Wenn die Ontologie erweitert wird, ist es möglich an einem dynamischen Matching zu forschen. Hinzu kommt, dass die Anforderungen ausschließlich auf erfüllt oder nicht erfüllt" geprüft werden. Eine Bewertung, welches System die Anforderungen am besten umsetzt, existiert nicht. Zur funktionellen Erweiterung ist es nötig der Ontologie Bewertungen der Funktionen hinzuzufügen. Weiterführend enthält die Ontologie keine Klassen zur Repräsentation der Nutzer, lediglich die Systeme und deren Funktionen sind abgebildet. Um durch die Ontologie zu entscheiden, welche Benutzergruppen welche Funktionen benötigen und nutzen, muss die Struktur der Ontologie überarbeitet werden

59 Akzeptanzanalyse 6 Akzeptanzanalyse Nach der Einführung eines SharePoint- oder Dynamics CRM-Systems kann es vorkommen, dass die Systeme nur zögernd von den Benutzern angenommen werden. Die Gründe dafür werden in diesem Kapitel analysiert. Die durchgeführten Interviews wurden für die Zielgruppen- und Anforderungsanalyse herangezogen. Dafür wird eine qualitative Inhaltsanalyse durchgeführt. Für die Akzeptanzanalyse werden die zusammengefassten Transkripte nach einer Methode zur Theoriegenerierung ausgewertet. Dabei werden folgende Forschungsfragen beantwortet: RQ6: Warum ist die Benutzerakzeptanz dieser Systeme so gering? 6.1 Auswahl der Methode Zwei bekannte Methoden zur Theoriegenerierung sind Grounded Theory und heuristische Sozialforschung an. Beide basieren unter anderem auf die Nutzung der durch Interviews erhobenen Daten zur Theoriegenerierung. In der Grounded Theory werden Transkripte codiert und kategorisiert und es werden Memos geschrieben, welche bei dem weiteren Verlauf der Interviews und Auswertungen helfen. Durch mehrere Zyklen wird die Theorie immer weiter verfeinert, bis keine neuen themenrelevanten Daten erhoben werden können. Die heuristische Sozialforschung richtet sich nach Fragen, wodurch neue Bereiche des Forschungsgebiets erschlossen und weitere Interviews geführt werden. In der Datenerhebung soll ein möglichst breites Feld genutzt werden. Die erhobenen Daten werden nicht codiert, sondern es wird versucht Fragen zu beantworten, um eine Theorie zu generieren. Die Auswertung der Interviews soll in diesem Fall nach Grounded Theory erfolgen, da die Fragen der heuristischen Sozialforschung das Risiko beinhalten, sich zu sehr auf detaillierte Fragen zu beziehen und dadurch den Fokus auf die Forschungsfragen zu verlieren. 6.2 Vorgehen nach Grounded Theory Durch die vorherige Zusammenfassung der Transkripte wurde folgende relevante Kategorie 24 definiert: - K4: Gründe für die geringe Benutzerakzeptanz Diese Kategorie wird in zwei Samplings nach Grounded Theory analysiert. - Sampling 1: Interviews mit vier Vertrieblern - Sampling 2: Interviews mit zwei Vertrieblern, zwei Consultants und einem Hybriden 24 Die Kategorien wurden in Kapitel Auswertung der Interviews definiert. Sie dienen der Thematischen Eingrenzung der Transkripte

60 Akzeptanzanalyse Die Analyse der erhobenen Daten erfolgte ohne vorherige systematische Erweiterung des Vorwissens, um das Risiko einer voreingenommenen Theoriebildung zu senken. Aus den oben genannten Kategorien wurden die Kernaussagen der Befragten herausgearbeitet und als Codes 25 verwendet. Diese Codes wurden themenunabhängig verschiedenen Kategorien zugeordnet. Aus diesen Codes wurden themenunabhängige Kategorien gebildet. a) Höherer Aufwand beim Tagesgeschäft b) Schlechte Planung der Systeme c) Inhalte werden nicht gepflegt d) Nutzen des Systems ist unklar e) Zusammenhalt der Mitarbeiter fehlt f) Nutzer werden organisatorisch eingeschränkt g) Fehlende Motivation der Benutzer h) Es herrscht eine heterogene Systemlandschaft i) Geringe Bekanntheit des Systems j) Nutzer werden technisch eingeschränkt Danach wurden die Kategorien anhand der Kernaussagen wieder den Themengebieten 26 zugeordnet. Wenn Kernaussagen aus verschiedenen Themengebieten in einer Kategorie vorkamen, so wurden diese Kategorien zu mehreren Themengebieten zugeordnet. Das Resultat der Zuordnung ist in Abbildung 6.1 grafisch dargestellt: 25 Die Codes können Anhang F Codes zur Theoriegenerierung entnommen werden. 26 Für das Themengebiet Projektmanagement konnten keine Codes bezüglich der Benutzerakzeptanz gebildet werden

61 Akzeptanzanalyse Dokumentenmanagemene Kollaboration j b f c h d e i g a Business Intelligence Geschäftsprozesse Abbildung 6.1: Gruppierung der Codes Da es sehr unwahrscheinlich ist, dass themenfremde Kategorien sich aufeinander auswirken, wurden zur weiteren Bearbeitung 4 Gruppen gebildet: - G1: Negativ-Akzeptanzkriterien von Dokumentenmanagement mit den Kategorien b) und j) - G2: Negativ-Akzeptanzkriterien von Dokumentenmanagement und Kollaboration mit den Kategorien c), d), f) und h) - G3: Negativ-Akzeptanzkriterien von Kollaboration mit den Kategorien e), i) und g) - G4: Negativ-Akzeptanzkriterien von Business Intelligence und Geschäftsprozessen mit der Kategorie a) Innerhalb dieser Gruppen und zwischen den benachbarten Gruppen wird nach Zusammenhängen gesucht. Benachbarte Gruppen überschneiden sich in mindestens einem Themengebiet. Das bedeutet, dass die Kategorie j) mit b) und f) verglichen wurde, allerdings nicht mit e) da beide Kategorien keine Überschneidung im Themengebiet hat. Kategorien aus nicht benachbarten Gruppen werden nicht miteinander verglichen, weil keine thematische Ähnlichkeit existiert

62 Akzeptanzanalyse Die in Abbildung 6.2 dargestellten Kausalketten konnten zwischen den Kategorien gebildet werden: i) Geringe Bekanntheit des Systems h) Es herrscht eine heterogene Systemlandschaft a) Höherer Aufwand beim Tagesgeschäft j) Nutzer werden technisch eingeschränkt e) Zusammenhalt der Mitarbeiter fehlt b) Schlechte Planung der Systeme g) Fehlende Motivation der Benutzer d) Nutzen des Systems ist unklar f) Nutzer werden organisatorisch eingeschränkt c) Inhalte werden nicht gepflegt Legende Ursache Wirkung Abbildung 6.2: Graph der Kausalketten Diese Ergebnisse spiegeln nicht die Akzeptanz von Business Intelligence, Geschäftsprozessen und Projektmanagement wieder. Daher wird der Leitfaden für das zweite Sampling angepasst und konkretere Fragen auf die Benutzerakzeptanz bezüglich dieser Themengebiete hinzugefügt. Dadurch konnten sechs neue Kategorien gebildet werden: k) Innovationsverweigernde Nutzer l) Geringe Anpassungen der Systeme m) Ungenügende Anforderungserhebung n) Falsche Vorstellungen o) Die Geschäftsprozesse sind den Nutzern unbekannt p) Die Geschäftsprozesse werden in den Systemen nicht abgebildet Die Kategorie d) und n) wurden zusammengefasst zu d) Nutzen des Systems ist unklar. Diese Kategorien und die Vorhergehenden werden neu gruppiert und analog des vorherigen Samplings auf Zusammenhänge ausgewertet Die Kausalketten können in Anhang G Kausalketten der Benutzerakzeptanz nachgeschlagen werden

63 Akzeptanzanalyse 6.3 Ergebnisse der Grounded Theory Aus den erstellten Kausalketten wurde abgeleitet, dass die Motivation der Benutzer von folgenden Faktoren abhängt: - Erhebung der Anforderungen - Anpassung des Systems - Pflege des Systems - Zusammenhalt der Mitarbeiter - Einschränkungen der organisatorischen Möglichkeiten der Nutzer Dabei steht die Erhebung der Anforderungen im Mittelpunkt, da sie sich auf insgesamt acht Kategorien auswirkt. Bei genauerer Betrachtung dieser Kategorie wird festgestellt, dass die Benutzerakzeptanz davon abhängt, wer in die Anforderungserhebung mit einbezogen wird. Die Codes sagen aus, dass häufig nur die IT-Abteilung und das höhere Management bei der Anforderungsanalyse einbezogen und der Großteil der Nutzer außer Acht gelassen wird. Die Erhebung der Anforderungen bedingt auch die Anpassung des Systems. Je besser ein System an die Anforderungen der Benutzer und des Unternehmens angepasst ist, desto größer ist die Akzeptanz der Benutzer. Die Pflege des Systems ist ein laufender Prozess. Es bietet sich an, eine Person dafür zu beauftragen, die Verantwortung über das eingesetzte System zu übernehmen und auf Aktualität und Wertigkeit der Inhalte achtet. Bei der Betrachtung der Kategorie Zusammenhalt der Mitarbeiter wird festgestellt, dass sie sich auf das Themengebiet Kollaboration bezieht. Sie wird damit als weniger wichtig eingestuft, trägt aber einen wichtigen Faktor zur Zusammenarbeit der Mitarbeiter bei. Die Kategorie Einschränkungen der organisatorischen Möglichkeiten der Nutzer beschreibt, welche Regeln der Benutzer von seinem Unternehmen auferlegt bekommt. Dazu gehört zum Bespiel, welche Pflichtfelder der Benutzer in einem Formular ausfüllen muss oder in welcher Reihenfolge die Arbeitsschritte eines Prozesses erfolgen müssen. Zu viele Regeln und Einschränkungen verringern die Benutzerakzeptanz. Die Forschungsfrage RQ6: Warum ist die Benutzerakzeptanz dieser Systeme so gering? kann daher wie folgt beantwortet werden: Die abschließende Theorie lautet, dass die Benutzerakzeptanz von vier Faktoren abhängt. Diese Faktoren sind die Pflege des Systems, die Anpassungen des Systems, die Einschränkungen der organisatorischen Möglichkeiten der Nutzer und die Anforderungserhebung. Dabei wird die Anforderungserhebung als wichtigster Faktor gesehen

64 Akzeptanzanalyse 6.4 Reflexion Für die Evaluation der gebildeten Theorie, sollte die eigentlichen Nutzer befragt werden. Zusätzliche Beobachtungen der Benutzer und deren Umgang mit den Systemen würden ein tieferes Verständnis für die Benutzerakzeptanz erbringen. Aber auch die Befragung und Beobachtung von Nutzern würde Deutungswissen und kein Sachwissen erzeugen. Um genauere Ergebnisse zu erhalten, sollten bereits bereitgestellte Systeme miteinander verglichen werden. Dabei sollen die Funktionsumfänge, sowie die Benutzerfreundlichkeit und die Akzeptanz der einzelnen Systeme jeweils gegenübergestellt werden. Aus diesen Ergebnissen kann geschlossen werden, wie ein System aufgebaut sein muss, um die größtmögliche Benutzerakzeptanz aufzuweisen

65 Erstellung des Projektplans 7 Erstellung des Projektplans Einer der Befragten sagte im Interview: SharePoint-Projekte sind Organisationsprojekte, da geht s nicht um Technik, da geht s um Organisation. [sic] Grundsätzlich hat die Einführung von Unternehmenssoftware und anderer komplexer Anwendungen nicht das Ziel, ein bestehendes System auszutauschen. Stattdessen soll die verbesserte und optimierte IT- Unterstützung den Mitarbeitern und somit dem Unternehmen effizienteres Arbeiten ermöglichen. Verschiedene Experten sagen: Aufbauorganisation, Geschäftsprozesse und Ressourcen auf der Seite des operativen Business sind regelmäßig mit der IT-Architektur und der IT-Infrastruktur sowie mit den IT-Prozessen und den IT-Ressourcen auf der Seite der operativen IT abzustimmen. (Plass, Rehmann, Zimmermann, Janssen, & Wibbing, 2013 S.89f) In diesem Kapitel werden Empfehlungen gegeben, wie die Projektplanung für die Einführung von SharePoint und Dynamics CRM aufgebaut sein kann. Diese Empfehlungen sind gleichzeitig die Beantwortungen der Forschungsfragen: RQ1: Welche Schritte sind bei der Einführung der Systeme von Bedeutung? und RQ2: Welche Projektmanagementmethoden sind für die Einführung der Systeme geeignet? Dabei wird zuerst auf die wichtigen Projektrollen und ihre Aufgaben eingegangen. Danach wird erläutert welche Einführungsvorgehensweise angebracht ist und die die Grobplanung des Projekts aufgebaut sein sollte. Dabei werden ein Projektphasenmodell und ein Projektstrukruplan vorgestellt. Die Feinplanung ist sehr stark von den tatsächlichen Projekten abhänging, daher können abschließend nur Vorschläge gegeben werden, wie diese auszusehen hat

66 Erstellung des Projektplans 7.1 Wichtige Projektrollen Zur Einführung von komplexen Systemen werden folgende Rollen benötigt: - Professionelle Projektleitung - Lenkungsausschuss - Kernteam - Key User Die Zusammenarbeit dieser Rollen wird in Abbildung 7.1 grafisch dargestellt. Abbildung 7.1: Projektorganisation für Systemeinführungen (vgl. Plass, Rehmann, Zimmermann, Janssen, & Wibbing, 2013 S.122ff) Da bei der Einführung der Systeme Geschäftsführer, Vertreter aus den Fachbereichen und externe Berater involviert sind und ein hohes Potenzial an Interessenskonflikten besteht, wird ein versierter und erfahrener Projektleiter benötigt

67 Erstellung des Projektplans Der Lenkungsausschuss besteht aus Entscheidungsbefugten der zur Einführung des Systems bestimmten Unternehmensbereiche, ausgewählten Systemlieferanten und Beratungsunternehmen. Hinzu kommt der Auftraggeber als Vorsitzender. Die Aufgaben des Lenkungsausschusses belaufen sich auf: - Genehmigen der Projektplanung - Prüfen der Projektstatusberichte - Überwachen der Kosten und Ablaufpläne - Freigeben der Projektphasen - Entscheiden über Änderungen des Pflichtenhefts und der Verträge (vgl. Plass, Rehmann, Zimmermann, Janssen, & Wibbing, 2013 S.122ff) Das Kernteam ist für die technische Einführung des Systems zuständig. Es bereitet die Hardware auf, installiert die Systeme und passt diese den Anforderungen an. Das Team besteht aus Mitarbeitern des zur Einführung des Systems bestimmten Unternehmens und des Systemanbieters. Die Key User sind die Vertreter des Fachbereichs und stellen sicher, dass die Anforderungen an das neue System umgesetzt werden. Dazu erfüllen sie folgende Aufgaben: - Fachliche Unterstützung des Customizings - Mitarbeit bei der Erstellung der Benutzungsdokumentation - Erarbeiten von Testfällen - Unterweisen der Benutzer in das neue System (vgl. Plass, Rehmann, Zimmermann, Janssen, & Wibbing, 2013 S.122ff) Zur Gewährleistung der Erfüllung dieser Aufgaben kann hier nach der Entwicklungsmethode On-Site Customer gearbeitet werden. Dies beschreibt eine agile Methode, bei der ein Vertreter des auftraggebenden Unternehmens ein Teil des Entwicklungsteams ist und für Fragen bereitsteht 28. Eine zweite Möglichkeit ist, dass die Entwickler bei dem auftraggebenden Unternehmen vor Ort die Software anpassen, so können sie jederzeit auf die Benutzer zugehen und bei Bedarf Fragen stellen. 7.2 Einführungsvorgehensweisen Eine Vielzahl von Experten schlagen drei mögliche Einführungsvorgehensweisen vor: - Big Bang: Mit diesem konzeptionellen Vorgehen wird das alte System komplett durch ein Neues ersetzt. 28 Nähere Informationen können im Kapitel 2 Grundlagen nachgeschlagen werden

68 Erstellung des Projektplans - Pilotbereich und Ausrollen: Anfangs wird bei diesem iterativen Vorgehen das neue System nur für eine Abteilung bereitgestellt. Nach den ersten gewonnen Erfahrungen können diese für weitere Iterationen genutzt werden. - Suksezzives Anschalten: Es ist ein iteratives Vorgehen, bei dem einzelne Funktionsbzw. Prozessbereiche des Systems aufeinander aufbauend implementiert und freigegeben werden. (vgl. Teich, Kolbenschlag, & Reiners, 2008 S. 193f) und (vgl. Plass, Rehmann, Zimmermann, Janssen, & Wibbing, 2013 S.131) Die Vor- und Nachteile dieser Ansätze werden in Plass, Rehmann, Zimmermann, Janssen, & Wibbing (2013, S.133) diskutiert und in Tabelle 7.1 aufgegriffen und ergänzt. Tabelle 7.1: Vor- und Nachteile der Einführungsvorgehensweisen konzeptionelles Vorgehen (Big Bang) iteratives Vorgehen (Pilotbereich und Ausrollen, Suksezzives Anschalten) Vorteile - kurze Einführungszeit - wenige Schnittstellen müssen erzeugt werden - hohe erreichbare Verbesserung - unternehmensweite Prozesse werden in einem Schritt umgesetzt - doppelte Datenhaltung wird verhindert, da das alte System nicht parallel läuft - pro Iteration sind nur wenige Fachbereiche betroffen - Erfahrungen aus der Pilotbereitstellung können in späteren Iterationen genutzt werden - geringes Einführungsrisiko - schnelle Reaktion bei Anforderungsänderungen möglich - das Scheitern des Projekts wird frühzeitig erkannt - es gibt immer kleine Erfolgserlebnisse - die Benutzer gewöhnen sich in kleinen Schritten an das System Nachteile - hoher Personalbedarf - hohes Risiko - erfordert ein überaus genaues Projektmanagement - erfordert umfangreiche Tests - Vorlaufzeit für Konzeption und Schulungen werden benötigt - Kernteam kann nicht schnell auf Anforderungsänderungen eingehen - das Scheitern des Projekts wird erst nach der kompletten Einführung erkannt - bei jeder Iteration müssen neue Schnittstellen bereitgestellt werden - die Einführung erstreckt sich über einen langen Zeitraum - Teams, die spät eingeplant werden, könnten sich vernachlässigt fühlen - eine doppelte Datenhaltung kann eintreten, da das alte System noch parallel läuft - abteilungsübergreifende Prozesse können erst spät implementiert werden

69 Erstellung des Projektplans Aus den vorrangegangenen Untersuchungen geht die Empfehlung hervor, dass ein iteratives Vorgehen präferiert werden sollte. Dabei können die Iterationen zum Umsetzen und Ausrollen von einzelnen Funktionen dienen oder zum Bereitstellen des Systems für einzelne Benutzergruppen des Unternehmens genutzt werden. 7.3 Grobplanung Für die Grobplanung eines Projekts dienen das Projektphasenmodell und der Projektstrukturplan Projektphasenmodell Felkai und Beiderwieden stellen ein allgemeines Projektphasenmodell vor, welches in einer abgewandelten Form auch für SharePoint- und Dynamics CRM-Projekte genutzt werden kann. Initialisierungsphase Angebotsphase Konzeption Bereitstellung/ Anpassung Realisierungsphase Migration Testphase Verifikation Abschlussphase Abbildung 7.2: Projektphasenmodell (vgl. Felkai & Beiderwieden, 2013 S19) Die Initialisierungsphase dient dazu das Projektziel und die technischen Anforderungen zu klären und darauf beziehend eine grobe Durchführungsanalyse realisieren. In der Angebotsphase werden grob Lösungskonzept, Entwicklungskonzept und Projektplanung ausgearbeitet. Die Durchführbarkeitsanalyse wird in dieser Phase nochmals genauer betrachtet. Wenn das Angebot angenommen wurde beginnt die erste Realisierungsphase. Die Realisierungsphase ist die iterative Phase, die sich bis zur Fertigstellung des Systems wiederholen wird. Sie ist nochmals aufgeteilt in Konzeption, Bereitstellung/Anpassung, Testphase, Migration und Verifikation. Die Abschlussphase dient zum Beenden des Projekts und zur vollständigen Übergabe des Systems. Je nach Angebotsmodell ist der Systemlieferant nicht mehr für die Anpassung und Weiterentwicklung des Systems verantwortlich

70 Erstellung des Projektplans Jede Phase muss mit einem Meilenstein abgeschlossen werden. Um zu prüfen, ob dieser erfolgreich erreicht wurde, muss es Zieldefinitionen geben, die vor dem Start der Phase festgelegt werden. (vgl. Felkai & Beiderwieden, 2013, S. 21) Im Fall von SharePoint und Dynamics CRM werden diese Ziele für die nicht iterativen Teile des Projektphasenmodells in Tabelle 7.2 definiert: Tabelle 7.2: Zieldefinitionen der nicht iterativen Projektphasen Projektphase Initialisierungsphase Angebotsphase Realisierungsphase Abschlussphase Zieldefinition Nach der Initialisierungsphase müssen sich Auftraggeber und Systemlieferant kennen, der Lenkungsausschuss muss gebildet und funktionsfähig sein und eine grobe Durchführbarkeitsanalyse muss abgeschlossen sein. Mit der Angebotsphase müssen ein erstes Grobkonzept, sowie eine grobe Projektplanung abgeschlossen sein. Das Angebot muss von allen Seiten unterzeichnet werden und eine detaillierte Durchführungsanalyse muss durchgeführt sein. Die Zieldefinition dieser Phase muss immer zu Beginn der Realisierung neu definiert werden. Das System wurde in der Abschlussphase erfolgreich an den Auftraggeber übergeben, es wurden Entwicklungs- und Systemdokumentationen fertiggestellt, sowie ein Abnahmeprotokoll und Abschlussbericht angefertigt Realisierungsphase Die Realisierungsphase wird in einem Projekt iterativ bearbeitet. Sie ist in fünf weitere Phasen eingeteilt: Konzeption, Bereitstellung/Anpassung, Testphase, Migration und Verifikation. (vgl. Abbildung 7.3) Realisierungsphase Konzeption Bereitstellung/ Anpassung Migration Testphase Verifikation Abbildung 7.3: Realisierungsphase im Projektphasenmodell Die Konzeption beinhaltet eine genaue Anforderungsanalyse und Konzeption der Iteration. Die erste Iteration ist im Regelfall die technische Bereitstellung der Systeminfrastruktur, wie Server und Geräte. Die darauf folgenden Iterationen richten sich nach den Wünschen des Auftraggebers und der Einführungsvorgehensweise. Bei Pilotbereich und Ausrollen wird das betroffene Team bestimmt, welches zuerst mit dem neuen System arbeiten soll. Bei Suksessives Anschalten werden die Anwendungsfälle bestimmt. Durch Befragungen und Auswahl deines On-site Customers beziehungsweise eines Key Users werden die

71 Erstellung des Projektplans Anforderungen erhoben und das Konzept geschrieben. Mit einer vollständigen Iterationsplanung, welche vom Lenkungsausschuss angenommen wird, geht es dann in die nächste Teilphase. In der Bereitstellung/Anpassung setzen die Entwickler die Wünsche der Benutzer um, dabei unterstützt der On-Site Customer. Es muss eine ständige Kommunikation zum Auftraggeber erfolgen. Die Dauer dieser Phase kann sich je nach Umfang des Entwicklungs- und Customizingaufwandes zwischen den Iterationen unterscheiden. Dabei ist zu beachten, dass die in einer Iteration umzusetzenden Anwendungsbereiche nicht zu unübersichtlich werden. Nach der Bereitstellung der neuen Funktionen erfolgt die Migrationsphase, in der die Übernahme der relevanten Daten aus den vorhandenen Systemen konzipiert wird. Danach erfolgt die Testphase, in der die Bereitstellung/Anpassung und die Migration getestet werden. Den Abschluss bildet die Phase Verifikation, welche dazu dient die Iteration vom Auftraggeber abnehmen zu lassen und die neuen Systemteile produktiv zu setzen. Wenn eine Iteration abgeschlossen ist und eine thematisch neue Iteration beginnt, ist es von Vorteil den Key User zu wechseln. Dies gewährleistet, dass auch bei neuen Anwendungsfällen ein fachlich versierter On-site Customer zur Verfügung steht Projektstrukturplan Anhand des kompletten Phasenmodells wird der Projektstrukturplan erstellt. Dieser spiegelt den kompletten Projektumfang wieder und bildet die hierarchische Struktur des Projekts. Diese Hierarchie kann sich an verschiedenen Kriterien orientieren: - Phasen: Jede Projektphase 29 wird als Unterprojekt behandelt. - Fachgebiete: Das Projekt wird nach den beteiligten Fachbereichen gegliedert. - Funktionen: Anhand der Funktionsbereiche werden die Unterprojekte definiert. - Objekte: Je nach Komponenten des Produkts werden die Unterprojekte erstellt. (Vgl. Anna Hoffmann, Andrea Herrman und Rüdiger Weißbach aus Herrmann, Knauss, & Weißbach, 2013, S. 53) 29 Eine Phase ist die Zeit zwischen zwei Meilensteinen oder eine Iteration in einem Projekt

72 Erstellung des Projektplans Innerhalb eines Projektstrukturplans können auf unterschiedlichen Ebenen verschiedene Orientierungen auftreten. Der Projektstrukturplan in Abbildung 7.4 für SharePoint- und Dynamics CRM-Projekte richtet sich in der ersten Ebene nach den Projektphasen. Es ist zu beachten, dass der iterative Teil während des Projekts entsteht und erst nach der Konzeption der Realisierungsphase bindend ist. SharePoint/CRM Projektinitialisierung Angebotsphase Realisierungsphase 1 Realisierungsphase 2 Realisierungsphase n Abschlussphase Projektzieldefinition Erstellung des Angebots Übergabe des Systems erste Anforderungserfassung genaue Durchführbarkeitsanalyse Übergabe der Projektdokumentationen grobe Durchführbarkeitsanalyse Erstellung eines Gesamtkonzepts Anfertigen eines Abschlussberichts Definition der Iterationen Anfertigen eines Abnahmeprotokolls erste Projektplanung Abbildung 7.4: Projektstrukturplan

73 Erstellung des Projektplans Arbeitspaketdefinitionen Die kleinsten Elemente des PSP sind die Arbeitspakete. Für jedes Arbeitspaket wird empfohlen eine Arbeitspaketbeschreibung nach der Vorlage aus Abbildung 7.5 angefertigt. Abbildung 7.5: Muster für Arbeitspaketbeschreibungen

74 Erstellung des Projektplans Der Aufbau der Arbeitspaketbeschreibung ist nach Felkai und Beiderwieden: - Das Arbeitspaketziel beschreibt, welche Rolle das Arbeitspaket im Projekt spielt und warum dieses Arbeitspaket erledigt werden muss. - Die Arbeitspaketvoraussetzungen sind die Ressourcen und Dokumente, die vor Beginn der Bearbeitung vorliegen müssen. - Das Arbeitspaketergebnis sind in diesem Arbeitspaket entstandene Artefakte. Diese müssen dokumentiert und auffindbar sein. - Ausnahmen sind Aufgaben, die explizit aus dem Arbeitspaket ausgeschlossen werden. - Arbeitspaketschnittstellen sind Verknüpfungen zu anderen Arbeitspaketen. - Arbeitspaket-Aktivitäten sind die einzelnen Schritte, die zur Erreichung der Arbeitspaketergebnisse dienen. 7.4 Feinplanung (vgl. Felkai & Beiderwieden, 2013 S. 227f) Zur Feinplanung der Projekte müssen ein Zeitplan und ein Ressourcenplan angefertigt werden. Da die Größen Zeit und Ressourcen sehr stark vom Projekt und vom Projektumfeld abhängen, können nur Hinweise gegeben werden, wie diese zu erstellen sind Erstellen des Zeitplans Der Zeitplan dient durch das Abschätzen der einzelnen Arbeitspakete dazu, eine voraussichtliche Projektdauer zu bestimmen und die Projektkosten zu berechnen. Felkai und Beiderwieden schlagen sechs Schritte zur Zeitplanerstellung vor, welche auch für die Einführung von SharePoint und Dynamics CRM genutzt werden sollten: Schritt 1: Auflisten der Meilensteine Schritt 2: Erfassen und Auflisten der Vorgänge Schritt 3: Schätzen der Dauer der Vorgänge Schritt 4: Identifizieren von Abhängigkeiten der Vorgänge Schritt 5: Ermitteln von Terminen, Pufferzeiten und kritischem Weg Schritt 6: Abstimmen des Zeitplans mit dem Projektteam und Prüfen der Kohärenz (Felkai & Beiderwieden, 2013 S.233)

75 Erstellung des Projektplans Für die Darstellung des Zeitplans, wird empfohlen den Netzplan zu verwenden. In Abbildung 7.6 ist ein Beispiel eines Netzplans zu sehen. Abbildung 7.6: Netzplanbeispiel (Felkai & Beiderwieden, 2013 S.234) Anhand des Netzplans können die Abhängigkeiten der Arbeitspakete und somit der kritische Weg 30 abgelesen werden. Sollten Verzögerungen in den einzelnen Arbeitspaketen auftreten, können diese hervorgehoben werden. 30 Ein kritischer Weg ist ein Pfad von aufeinanderfolgenden Arbeitspaketen, in dem kein Arbeitspaket einen Puffer hat. Eine Verzögerung innerhalb des kritischen Wegs wirkt sich direkt auf die Projektdauer aus

76 Erstellung des Projektplans Erstellen des Ressourcenplans Abschließend müssen die benötigten Ressourcen definiert werden. Dabei sind sowohl Personal als auch Sachressourcen 31 zu beachten. Danach muss definiert werden, in welcher Menge die Ressourcen benötigt werden. Anschließend werden die Ressourcen mit dem Zeitplan verknüpft. Dabei ist die Verfügbarkeit der Ressourcen einzuplanen. Der Ort des Ressourceneinsatzes muss im Ressourcenplan definiert werden. (Felkai & Beiderwieden, 2013 S.241) Ein Beispiel eines Ressourcenplans ist in Abbildung 7.7 dargestellt. Abbildung 7.7: Ressourcenplan (Felkai & Beiderwieden, 2013 S.242) 31 U.a. Hard- und Software