Entwicklung eines Einführungsplans für SharePoint und CRM ... · Zusammenfassung - 3 -...

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

Zusammenfassung

- 3 -

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.

Abstract

- 5 -

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

Inhaltsverzeichnis

- 7 -

Inhaltsverzeichnis

Zusammenfassung ................................................................................................................. - 3 -

Abstract ................................................................................................................................. - 5 -

Inhaltsverzeichnis .................................................................................................................. - 7 -

Abbildungsverzeichnis ........................................................................................................ - 10 -

Tabellenverzeichnis ............................................................................................................. - 12 -

1 Aufbau der Arbeit ........................................................................................................ - 13 -

1.1 Problemstellung .................................................................................................... - 13 -

1.2 Forschungsfragen .................................................................................................. - 14 -

1.3 Aufbau der Arbeit ................................................................................................. - 15 -

2 Grundlagen .................................................................................................................. - 17 -

2.1 Mittelstand ............................................................................................................ - 17 -

2.2 SharePoint ............................................................................................................. - 18 -

2.3 Dynamics CRM .................................................................................................... - 19 -

2.4 Anwendungsbereiche von SharePoint und Dynamics CRM ................................ - 20 -

2.4.1 Dokumentenmanagement .............................................................................. - 20 -

2.4.2 Kollaboration ................................................................................................. - 22 -

2.4.3 Business Intelligence ..................................................................................... - 22 -

2.4.4 Geschäftsprozesse ......................................................................................... - 24 -

2.5 Experteninterviews ............................................................................................... - 24 -

2.6 Theoriegenerierung ............................................................................................... - 25 -

2.6.1 Grounded Theory .......................................................................................... - 25 -

2.6.2 Heuristische Sozialforschung ........................................................................ - 27 -

2.7 Projektmanagement .............................................................................................. - 28 -

2.7.1 On-site Customer ........................................................................................... - 29 -

2.7.2 Iterative Entwicklungsmethode ..................................................................... - 30 -

2.8 Ontologien ............................................................................................................ - 30 -

3 Systemanalyse ............................................................................................................. - 32 -

3.1 SharePoint ............................................................................................................. - 32 -

3.2 Dynamics CRM .................................................................................................... - 36 -

3.2.1 Arbeiten im Vertrieb ..................................................................................... - 36 -

Inhaltsverzeichnis

- 8 -

3.2.2 Arbeiten im Marketing .................................................................................. - 39 -

3.2.3 Arbeiten im Kundenservice ........................................................................... - 40 -

3.3 Gemeinsamkeiten der Systeme ............................................................................. - 41 -

3.4 Zusammenfassung der Funktionen ....................................................................... - 42 -

3.5 Reflexion .............................................................................................................. - 42 -

4 Zielgruppenanalyse und Anforderungserhebung ........................................................ - 43 -

4.1 Das Interview ........................................................................................................ - 43 -

4.1.1 Vorbereitung des Interviews ......................................................................... - 43 -

4.1.2 Samplings ...................................................................................................... - 43 -

4.1.3 Erstellung des Leitfadens und Durchführung der Interviews ........................ - 44 -

4.1.4 Auswertung der Interviews ........................................................................... - 45 -

4.2 Zielgruppenanalyse ............................................................................................... - 46 -

4.3 Anforderungserhebung ......................................................................................... - 47 -

4.4 Reflexion .............................................................................................................. - 48 -

5 Erstellung des Anforderungskatalogs .......................................................................... - 49 -

5.1 Erstellung der Ontologie ....................................................................................... - 50 -

5.2 Erstellen der SPARQL-Abfragen ......................................................................... - 53 -

5.3 Konzept des Anforderungskatalogs ...................................................................... - 53 -

5.3.1 Benutzeroberfläche ........................................................................................ - 54 -

5.3.2 Berechnung des Deckungsbereichs ............................................................... - 55 -

5.3.3 Programmaufbau des Prototypen .................................................................. - 56 -

5.4 Reflexion .............................................................................................................. - 58 -

6 Akzeptanzanalyse ........................................................................................................ - 59 -

6.1 Auswahl der Methode ........................................................................................... - 59 -

6.2 Vorgehen nach Grounded Theory ........................................................................ - 59 -

6.3 Ergebnisse der Grounded Theory ......................................................................... - 63 -

6.4 Reflexion .............................................................................................................. - 64 -

7 Erstellung des Projektplans ......................................................................................... - 65 -

7.1 Wichtige Projektrollen .......................................................................................... - 66 -

7.2 Einführungsvorgehensweisen ............................................................................... - 67 -

7.3 Grobplanung ......................................................................................................... - 69 -

7.3.1 Projektphasenmodell ..................................................................................... - 69 -

Inhaltsverzeichnis

- 9 -

7.3.2 Projektstrukturplan ........................................................................................ - 71 -

7.4 Feinplanung .......................................................................................................... - 74 -

7.4.1 Erstellen des Zeitplans .................................................................................. - 74 -

7.4.2 Erstellen des Ressourcenplans ...................................................................... - 76 -

7.5 Realisierungsphasen ............................................................................................. - 77 -

8 Verwandte Systeme ..................................................................................................... - 78 -

8.1 Alternativen zu Microsoft SharePoint .................................................................. - 78 -

8.1.1 IBM Notes ..................................................................................................... - 78 -

8.1.2 SAP NetWeaver Portal .................................................................................. - 79 -

8.1.3 Zusammenfassung ......................................................................................... - 80 -

8.2 Alternativen zu Microsoft Dynamics CRM .......................................................... - 81 -

8.2.1 SAP Business ByDesign ............................................................................... - 82 -

8.2.2 Salesforce CRM ............................................................................................ - 84 -

8.2.3 Zusammenfassung ......................................................................................... - 85 -

9 Verwandte Arbeiten .................................................................................................... - 88 -

10 Fazit ............................................................................................................................. - 89 -

10.1 Kritische Würdigung ......................................................................................... - 89 -

10.2 Ausblick ............................................................................................................ - 90 -

Literaturverzeichnis ............................................................................................................. - 91 -

Anhang A – Charakterisierung von Klein-, Mittel- und Großbetrieben ............................. - 95 -

Anhang B – Funktionsliste ................................................................................................ - 101 -

Anhang C – Interviewdokumente ..................................................................................... - 107 -

Anhang D – Liste der Anforderungen gruppiert nach Themengebieten ........................... - 109 -

Anhang E – Tripel der Funktionsontologie ....................................................................... - 115 -

Anhang F – Codes zur Theoriegenerierung ...................................................................... - 121 -

Anhang G – Kausalketten der Benutzerakzeptanz ............................................................ - 123 -

Abbildungsverzeichnis

- 10 -


Abbildung 1.1: Aufbau der Arbeit ...................................................................................... - 15 -

Abbildung 2.1: Dokumentenmanagement-Pyramide .......................................................... - 21 -

Abbildung 2.2: Überblick der Business Intelligence Bereiche ........................................... - 23 -

Abbildung 2.3: Zyklus der Grouded Theory ....................................................................... - 26 -

Abbildung 2.4: Begriffliche Erklärung des Projektmanagements....................................... - 28 -

Abbildung 2.5: Darstellung des On-site Customers ............................................................ - 29 -

Abbildung 2.6: Spiralmodell ............................................................................................... - 30 -

Abbildung 2.7: Beispielgraph einer Ontologie ................................................................... - 31 -

Abbildung 3.1 Webanwendung im SharePoint ................................................................... - 33 -

Abbildung 3.2 Dynamics CRM-Klassendiagramm Vertrieb .............................................. - 37 -

Abbildung 3.3 Dynamics CRM-Aktivitätsdiagramm Vertrieb ........................................... - 38 -

Abbildung 3.4 Dynamics CRM-Klassendiagramm Marketing ........................................... - 39 -

Abbildung 3.5 Dynamics CRM-Klassendiagramm Kundenservice ................................... - 40 -

Abbildung 5.1: Klassendiagramm der konstruierten Ontologie .......................................... - 52 -

Abbildung 5.2: schematische Darstellung des Prototyps .................................................... - 54 -

Abbildung 5.3: Pseudocode für die Berechnung des Deckungsbereichs ............................ - 55 -

Abbildung 5.4: Model-View-Controller-Pattern ................................................................. - 56 -

Abbildung 5.5: Modell des Prototyps ................................................................................. - 56 -

Abbildung 5.6: Controller des Prototyps ............................................................................. - 57 -

Abbildung 5.7: Schnittstellen des Prototyps ....................................................................... - 57 -

Abbildung 5.8: EER-Modell der Datenbasis des Prototyps ................................................ - 57 -

Abbildung 6.1: Gruppierung der Codes .............................................................................. - 61 -

Abbildung 6.2: Graph der Kausalketten .............................................................................. - 62 -

Abbildung 7.1: Projektorganisation für Systemeinführungen ............................................. - 66 -

Abbildung 7.2: Projektphasenmodell .................................................................................. - 69 -

Abbildung 7.3: Realisierungsphase im Projektphasenmodell ............................................. - 70 -

Abbildung 7.4: Projektstrukturplan ..................................................................................... - 72 -

Abbildung 7.5: Muster für Arbeitspaketbeschreibungen .................................................... - 73 -

Abbildung 7.6: Netzplanbeispiel ......................................................................................... - 75 -

Abbildung 7.7: Ressourcenplan .......................................................................................... - 76 -


- 11 -

Abbildung 7.8: Projektstrukturplan für eine Iteration ......................................................... - 77 -

Abbildung 8.1: Aufbau von SAP NetWeaver ..................................................................... - 79 -

Abbildung 8.2: SAP CRM Portfolio ................................................................................... - 82 -

Abbildung 8.3: Anwendungsbereiche des Salesforce CRM ............................................... - 84 -

Abbildung 8.4: Lebenszyklus der Entitäten in Salesforce CRM ........................................ - 84 -

Tabellenverzeichnis

- 12 -

Tabellenverzeichnis

Tabelle 2.1: Aufteilung in Klein-, Mittel- und Großbetriebe nach EU-Kommision ........... - 17 -

Tabelle 2.2: betriebsgrößenrelevante Merkmale ................................................................. - 18 -

Tabelle 2.3: Gliederung von Experteninterviews ................................................................ - 24 -

Tabelle 3.1: SharePoint Listenvorlagen .............................................................................. - 34 -

Tabelle 3.2: SharePoint Bibliotheksvorlagen ...................................................................... - 35 -

Tabelle 3.3: SharePoint Websitevorlagen ........................................................................... - 35 -

Tabelle 3.4: Gemeinsamkeiten und Unterschiede der Systeme .......................................... - 41 -

Tabelle 3.5: quantitatives Ergebnis der Funktionsanalyse .................................................. - 42 -

Tabelle 4.1: Ergebnisse der Zielgruppenanalyse ................................................................. - 47 -

Tabelle 7.1: Vor- und Nachteile der Einführungsvorgehensweisen ................................... - 68 -

Tabelle 7.2: Zieldefinitionen der nicht iterativen Projektphasen ........................................ - 70 -

Tabelle 8.1: Vergleich zwischen SharePoint Systemen ...................................................... - 81 -

Tabelle 8.2: Vergleich zwischen CRM Systemen ............................................................... - 85 -

Aufbau der Arbeit

- 13 -

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.

Aufbau der Arbeit

- 14 -

- 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: Welche Schritte sind bei der Einführung der Systeme von Bedeutung?

RQ2: 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: Welche Eigenschaften besitzen Unternehmen, die erfolgreich mit SharePoint

und Dynamics CRM arbeiten?

RQ4: Wie muss ein Anforderungskatalog für solche Systeme aufgebaut sein?

RQ5: Wie kann entschieden werden, welche Anforderungen durch die Systeme

umgesetzt werden?

Aufbau der Arbeit

- 15 -

RQ4 wird zur besseren Bearbeitung in folgende Forschungsfragen aufgeteilt:

RQ4.1: Welche Funktionen haben die Systeme?

RQ4.2: Welche Anforderungen haben mittelständische Unternehmen?

RQ4.3: 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: Warum ist die Benutzerakzeptanz dieser Systeme so gering?

1.3 Aufbau der Arbeit

Zur Beantwortung der Forschungsfragen ist die Arbeit in 7 Teile gegliedert. (vgl. Abbildung

1.1)

Grundlagen

Syst

eman

alys

e

Ziel

gru

pp

en-

anal

yse

An

ford

eru

ngs

-er

heb

un

g

Akz

epta

nza

nal

yse

Anfoderungskatalog

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 SharePoint1 und

1 Im Folgenden SharePoint genannt.

Aufbau der Arbeit

- 16 -

Microsoft Dynamics CRM2 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.

Grundlagen

- 17 -

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 < 10 ≤ 2 ≤ 2

klein < 50 ≤ 10 ≤ 10

mittel < 250 ≤ 50 ≤ 43

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.

Grundlagen

- 18 -

Hans-Christian Pfohl nennt zusätzliche betriebsgrößenrelevante Merkmale, welche in Tabelle

2.2 genannt werden:

Tabelle 2.2: betriebsgrößenrelevante Merkmale

Problembereiche Größenmerkmale

Unternehmerleitung Gewinn, Umsatzentwicklung

Organisation Anzahl der Hierarchieebenen, Anzahl der Beschäftigten

Beschaffung Einkaufsmengen, Anzahl der Lieferanten

Produktion Anzahl der Maschinen, Maschinenstunden, Produktionsmengen

Absatz Umsatz, Anzahl der Verkaufsabschlüsse, Anzahl der Kunden

Entsorgung Entsorgungsaufwendungen, Abfallmengen

Forschung und Entwicklung Forschungs- und Entwicklungsaufwendungen, vergebene Lizenzen

Finanzierung Zahlungsströme, Kapitalbestände, Vermögensbestände,

Bilanzsummen

Personal Anzahl der Beschäftigten

Logistik 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 2.05.

4 Vgl. Anhang A – Charakterisierung von Klein-, Mittel- und Großbetrieben 5 Enterprise 2.0 beschreibt die Nutzung von Sozial Media in Unternehmen.

Grundlagen

- 19 -

SharePoint kann Benutzer in den Bereichen Kollaboration, Dokumentenmanagement und

Geschäftsanwendungen unterstützen, außerdem kann es wie ein Enterprise Content

Management System6 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-Authoring7 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.

Grundlagen

- 20 -

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 Werkzeuge8 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.

2.4.1 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.

Grundlagen

- 21 -

Die internationale Norm DIN ISO 15489 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 Dokumentenmanagementsystem9 (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.

Abbildung 2.1: Dokumentenmanagement-Pyramide

9 System zur Verwaltung von Dokumenten. Die Funktionen gehen über einen herkömmlichen

Fileserver hinaus.

DMS

Archivkonzept,

Regeln

Berechtigungskonzept

Objektkategorien und

normierte Objektlisten

Grundlegende Ordnerstruktur

= praktikabler Ordnerplan

Grundlagen

- 22 -

(Steinbrecher & Müll-Schnurr, 2014, S. 16)

2.4.2 Kollaboration

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)

2.4.3 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.

Grundlagen

- 23 -

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.

Grundlagen

- 24 -

2.4.4 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

Explorative Experteninterviews Fundierte Experteninterviews

Informatorische

Experteninterviews

Experteninterviews zur

explorativen Datensammlung

Systematisierende

Experteninterviews

Deutungswissensorientierte

Experteninterviews

Experteninterviews zur

Exploration von Deutungen

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 Deutungssammlung10 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.

Grundlagen

- 25 -

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 Guides11 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.

2.6.1 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.

Grundlagen

- 26 -

Auswahl der Befragten, Erhebung von Daten

Codieren, auswerten, vergleichen, prüfen,

Memos schreiben

Zusammenfassen und strukturieren, Theorien entwickeln, testen und

prüfen, weiteres Vorgehen planen, 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 Sampling12 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

Grundlagen

- 27 -

2.6.2 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)

Grundlagen

- 28 -

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.

ProjektTemporäres Unterfangen zur Entwicklung und Produktion

von Neuem

ManagementSystem von

Steuerungsaufgaben, die bei der Leistungserstellung

und -sicherung in arbeitsteiligen

Organisationen zu erbringen sind

ProjektmanagementGesamtheit 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

Grundlagen

- 29 -

2.7.1 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.

Grundlagen

- 30 -

2.7.2 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)

Grundlagen

- 31 -

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.

Hund

Katze

maus

jagt

jagt

Spike

Tom

Jerry

name

name

name

Hundehütte

Haus

lebt_in

lebt_in

lebt_in

Abbildung 2.7: Beispielgraph einer Ontologie

Systemanalyse

- 32 -

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 Look-

and-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) Websites13 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.

Systemanalyse

- 33 -

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.

Systemanalyse

- 34 -

Tabelle 3.1: SharePoint Listenvorlagen

Vorlage Beschreibung

Ankündigungen zur Verwaltung von Neuigkeiten, abgelaufene Ankündigungen werden

automatisch ausgeblendet

Aufgaben zur Verwaltung von Aufgaben im Team, ein Vorteil ist die

Verknüpfung mit Outlook

Projektaufgaben 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

Benutzerdefiniert zur Erstellung von beliebigen Listen mit beliebigen Inhalten

Diskussionsrunde zur zentralen Verwaltung der Teamdiskussionen in einem Forum

Externe Listen zum Darstellung von Listen, die außerhalb von SharePoint gespeichert

sind

Links zur Festlegung von Verweisen in- und außerhalb von SharePoint

Höhergestufte Links ähnlich der Liste Links, nur dass die Links in der Liste als Kacheln

angezeigt werden

Kalender zur Terminverwaltung innerhalb eines Teams, auch hier ist eine

Verbindung zu Outlook und eine automatische Synchronisation

möglich

Kontakte zur Verwaltung von Kontaktdaten, eine Einbindung von Outlook ist

möglich

Probleme 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

Umfragen zur Erstellung und grafischen Auswertung von Umfragen

Newsfeed zur Teilung von Informationen mit Kollegen und Kolleginnen

KPI-Liste (Key Performance

Indicator)

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

Systemanalyse

- 35 -

Elemente abgelegt werden. Melanie Schmidt nennt 9 Vorlagen für Bibliotheken die

SharePoint bereitstellt: (vgl. Tabelle 3.2)

Tabelle 3.2: SharePoint Bibliotheksvorlagen

Vorlage Beschreibung

Dokumentenbibliothek zur Zentralen Speicherung von Dateien

Bildbibliothek zur Bereitstellung von Bildern

Objektbibliothek zur Bereitstellung von Rich-Media-Objekten wie Videos oder

Sounds

Datenverbindungsbibliothek zur zentralen Speicherung und zum Zugriff auf externe Datenquellen

per Office Data Connection (ODC)

Formularbibliothek zur Bereitstellung von XML-basierten Formularen, die via InfoPath

erstellt wurden

Datensatzbibliothek zur Erstellung eines Datenarchivs

Berichtsbibliothek zur Speicherung von Excel-Arbeitsmappen, Dashboards oder Key

Performance Indicators (KPI)

Prozessdiagrammbibliothek zur Bereitstellung von Visio-Zeichnungen

Wiki-Seitenbibliothek zur Bereitstellung von Informationen in einem Wiki


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 Beschreibung

Teamwebsite zur Verwaltung eines Teams und zur Förderung der Zusammenarbeit

im Team

Blog zur Verbreitung von Meinungen, Ideen oder Ereignissen unter

Kollegen und Kolleginnen, jeder Blogeintrag kann kommentiert und

bewertet werden

Projektwebsite zur Verwaltung aller projektrelevanten Informationen

Communitywebsite zur Schaffung einer Forenumgebung für Diskussionen zwischen

Kollegen und Kolleginnen

Dokumentencenter zur zentralen Ablage und Verwaltung von Dateien

Systemanalyse

- 36 -

Datenarchiv zur Ablage von aktuellen Kopien aller Datensätze

Business Intelligence Center zur visuellen Auswertung von Daten und Analyse, so können

Dashboards und interaktive Bereiche erstellt werden

Unternehmenssuchcenter zur Durchführung von allgemeinen, personenbezogenen

Unterhaltungs- und Videosuchvorgängen

Basissuchcenter einfache Suchwebsite

Visio-Prozess-Repository zur Abbildung von Geschäftsprozessen und Diagrammen

Unternehmenswiki zur Bereitstellung einer Wiki-Umgebung für Kollegen und

Kolleginnen


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 Literatur14 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 Customizing15 angepasst, gelöscht

oder erweitert werden.

3.2.1 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.

Systemanalyse

- 37 -

In dem folgenden Klassendiagramm (vgl. Abbildung 3.2) ist eine Übersicht der im

Anwendungsbereich Vertrieb relevanten Entitäten.

Firmenkunde Kontaktperson

Lead

1 1..*

Aktivität

1 1

1

Verkaufchance

Rechnung

Auftrag

Konkurrent

SharePointDokument

1

1..*

Case

Marketingliste

11

1

Produkt

Preisliste

0..*

1..

1..*

Angebot

1

11

1

0..*

0..*

0..*

0..*0..*

0..*

0..*

0..*0..*

0..*

0..*

Abbildung 3.2 Dynamics CRM-Klassendiagramm Vertrieb

Das Dynamics CRM-System bietet bereits einen Grundstock an Attributen für die einzelnen

Entitäten16. 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, E-Mails, 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.

Systemanalyse

- 38 -

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

Firmenkunden aus Lead generieren

[Firmeninformationen sind vorhanden]

[Firmeninformationen sind nicht vorhanden]

Angebot aus Verkaufschance

generieren

Verkaufschance schließen

Auftrag aus Angebot generieren

Rechnung aus Auftrag generieren

[Verkaufschance gewonnen]

[Verkaufschance verloren]

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

Systemanalyse

- 39 -

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)

3.2.2 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:

Marketingliste

Kampagne SchnelleKampagne

Firmenkunde

Kontaktperson

Lead

Aktivität

1..*

1..*

1..*

1..* 1..*

1..* 1

1 1

1 1

1

11

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)

Systemanalyse

- 40 -

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)

3.2.3 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:

Wissensdatenbank Article0..*1

Serviceaktivität

Ressource

Servicekalender Termin

Vertrag

Firmenkunde

11

1

1

1

1..*

1..*

0..*

1

0..*

Case

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

Systemanalyse

- 41 -

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 SharePoint ist ein Content

Management Systems

Dynamics CRM ist kein

Content Management System

Dokumentenmanagement Dokumente können gesichert,

bearbeitet und versioniert

werden.

Dokumente können an Entitäten

angehängt werden. Sie können

danach nicht mehr bearbeitet

werden.

Kollaboration Die Zusammenarbeit wird durch gemeinsame Bearbeitung von

Elementen und Wissensbereitstellung unterstützt.

Business Intelligence 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.

Geschäftsprozesse 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)

Systemanalyse

- 42 -

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 5 5 5

Content Management 30 30 19

Dokumentenmanagement 18 18 0

Kollaboration 28 26 10

Geschäftsprozesse 19 6 19

Business Intelligence 9 4 9

109 89 62

3.5 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.

Zielgruppenanalyse und Anforderungserhebung

- 43 -

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)

4.1.1 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)

4.1.2 Samplings

Mit Hilfe der Interviews werden folgende Forschungsfragen beantwortet:

RQ3: Welche Eigenschaften besitzen Unternehmen, die erfolgreich mit SharePoint

und Dynamics CRM arbeiten?

RQ4.2: 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 -

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:


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.

4.1.3 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 -

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.

4.1.4 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 -

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-, Mittel-

und 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 -

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 Ein Unternehmen, welches seine Geschäftsprozesse formalisiert, kann diese

in der Regel in Systeme implementieren.

Zukunftsorientierung Ein Unternehmen, welches zukunftsorientiert arbeitet, kann in der Regel

Business Intelligence gewinnbringend nutzen.

Standortverteilung

Ein Unternehmen, welches auf mehrere Standorte verteilt ist, kann in der

Regel Social Media im Unternehmen nutzen.

Beziehung der

Mitarbeiter

untereinander

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 -

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.

Erstellung des Anforderungskatalogs

- 49 -

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 SPARQL18-

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 -

Tabelle 5.1: Vergleich der Ontologieansätze

mehrere Ontologien eine Ontologie

Anzahl der Ontologien eine Ontologie je System und eine

für die Anforderungen

eine Ontologie für alle Systeme

Vergleich durch das Messen der Überein-

stimmungen der Ontologiegraphen

SPARQL-Abfragen

Gewichtung der

Anforderungen

ist durch die Erweiterung der

Ontologie möglich

ist durch die Gewichtung der

SPARQL-Abfragen möglich

Erweiterung um ein neues

System

durch die Erstellung einer neuen

Ontologie

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

(vgl. Stuckenschmidt, 2009)

Diese Schritte werden auf die zuvor erarbeitete Funktionsliste angewandt.

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 -

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 Range19 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 -

dargestellt. Daher konnte folgendes Klassendiagramm20 (vgl. Abbildung 5.1) definiert

werden.

Dashboard

Ziel

System

App

MenüMenüband

Präsentationsansicht

Mobiles_GerätElement

Liste

Anhang

Ansicht

Datei

Feld

Import

Formular

Website

Controlling_Komponente Vorlage

Suche

Externe_Ressourcen

Bibliothek

Richtlinien

Kollaboarations_Komponenten

Prozess

Prozessunterstützungs_Komponenten

WCM_System

Ansicht

Export

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 -

Als URI21 für die Beschreibung der Ontologie wurde „http://www.mwde.de/swb/unsw#“

gewählt. Nach der Erstellung der beide Systeme beschreibenden Ontologie22 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 ?system

WHERE { 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 -

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?

5.3.1 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

Business Intelligence Geschäftsprozesse Projektmanagement

1

1

3

4

1

1

1

1

2

1

Kollaboration

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

Dokumentenmanagement

Dokumente müssen schnell gefunden werden

Dokumentenmanagement:

Kollaboration:

Business Intelligence:

Geschäftsprozesse:

Projektmanagement:

Insgesamt:

SharePoint CRM

74%

63%

26%

65%

31%

58%

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 -

5.3.2 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 -

5.3.3 Programmaufbau des Prototypen

Der Prototyp soll nach dem Model-View-Controller-Pattern23, welches in Abbildung 5.4

dargestellt ist, umgesetzt werden.

Model

View Controller

benachric

htigt

lädt D

aten

ändert Daten

Events

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.

Anforderung

- id:int- label:String- sparql:String- selected:boolean- value:int

ThemenBereich

- id:int- label:String

10..*

System

- id:int- label:String- uri:String

DeckungsBereich

- value:float

0..*0..*1 1

1

0..*

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 -

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)

DeckungsBereichsController

ActionListener

- 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

- getAllSysteme():List<System>- getAllAnfoderungen():List<Anforderung>

Ontology

- getSystemeByAnforderung(Anforderung):List<System>

Abbildung 5.7: Schnittstellen des Prototyps

Die Datenbank beschreibt zwei Tabellen: Anforderung und System (vgl. Abbildung 5.8)

Anforderung System

id

label

sparql

id

label

uri

Abbildung 5.8: EER-Modell der Datenbasis des Prototyps


- 58 -

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.

Akzeptanzanalyse

- 59 -

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:


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 Kategorie24

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 4.1.4 „Auswertung der Interviews“ definiert. Sie dienen der

Thematischen Eingrenzung der Transkripte.

Akzeptanzanalyse

- 60 -

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 Codes25 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 Themengebieten26

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.

Akzeptanzanalyse

- 61 -

b

a

c

dfg

h

i

j

e

Dokumentenmanagemene Kollaboration

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.

Akzeptanzanalyse

- 62 -

Die in Abbildung 6.2 dargestellten Kausalketten konnten zwischen den Kategorien gebildet

werden:

b) Schlechte Planung der Systeme

a) Höherer Aufwand beim Tagesgeschäft

c) Inhalte werden nicht gepflegt

d) Nutzen des Systems ist unklar

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

e) Zusammenhalt der Mitarbeiter fehlt

Ursache Wirkung

Legende

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.27

27 Die Kausalketten können in Anhang G – Kausalketten der Benutzerakzeptanz nachgeschlagen

werden

Akzeptanzanalyse

- 63 -

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.

Akzeptanzanalyse

- 64 -

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.

Erstellung des Projektplans

- 65 -

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 -

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 -

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


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


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

bereitsteht28. 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 -

- 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 Funktions-

bzw. 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

Vorteile Nachteile

konzeptionelles

Vorgehen

(Big Bang)

- 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

- 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

iteratives Vorgehen

(Pilotbereich und

Ausrollen,

Suksezzives

Anschalten)

- 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

- 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 -

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.

7.3.1 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.

Initialisierungs-phase

Angebotsphase

Realisierungsphase

KonzeptionBereitstellung/

AnpassungMigration

AbschlussphaseTestphase Verifikation

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 -

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 Zieldefinition

Initialisierungsphase 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.

Angebotsphase 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.

Realisierungsphase Die Zieldefinition dieser Phase muss immer zu Beginn der Realisierung

neu definiert werden.

Abschlussphase Das System wurde in der Abschlussphase erfolgreich an den

Auftraggeber übergeben, es wurden Entwicklungs- und

Systemdokumentationen fertiggestellt, sowie ein Abnahmeprotokoll und

Abschlussbericht angefertigt.

7.3.1.1 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


AnpassungMigration 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 -

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.

7.3.2 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 Projektphase29 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 -

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

Projekt-initialisierung

Projektziel-definition

erste Anforderungs-

erfassung

grobe Durchführ-barkeitsanalyse

Angebotsphase

Erstellung des Angebots

genaue Durchführ-barkeitsanalyse

Erstellung eines Gesamtkonzepts

Definition der Iterationen

erste Projektplanung

Abschlussphase

Übergabe des Systems

Übergabe der Projekt-

dokumentationen

Anfertigen eines Abschlussberichts

Anfertigen eines Abnahme-protokolls

Realisierungs-phase 1

Realisierungs-phase 2

Realisierungs-phase n

Abbildung 7.4: Projektstrukturplan


- 73 -

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 -

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.

(vgl. Felkai & Beiderwieden, 2013 S. 227f)

7.4 Feinplanung

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.

7.4.1 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 -

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


Anhand des Netzplans können die Abhängigkeiten der Arbeitspakete und somit der kritische

Weg30 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 -

7.4.2 Erstellen des Ressourcenplans

Abschließend müssen die benötigten Ressourcen definiert werden. Dabei sind sowohl

Personal als auch Sachressourcen31 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


31 U.a. Hard- und Software


- 77 -

7.5 Realisierungsphasen

Die Realisierungsphasen sind die Iterationen des Projekts. Wie in Kapitel 6 bewiesen ist es

für die Akzeptanz der Benutzer entscheidend, dass diese in die Iterationen mit einbezogen

werden. Außerdem müssen Unternehmensorganisation und Geschäftsprozesse in das neue

System übernommen werden. Dabei sollen die Geschäftsprozesse in den Systemen nicht

spartanisch abgebildet werden, sondern unter Zuhilfenahme einer Vorstudie kritisch

hinterfragt werden. Diese Vorstudie findet im Rahmen der Anforderungsanalyse statt und

umfasst die Erarbeitung der Problemstellung, die Dokumentation und Zieldefinition des

Geschäftsprozesses. In Abbildung 7.8 ist ein Projektstrukturplan für eine Iteration abgebildet.

Realisierungs-phase n


AnpassungTestphaseMigration Verifikation

detaillierte Anforderungs-

analyse

Spezifikation der Iteration

Planung der Iteration

technische Umsetzung: Funktion A

technische Umsetzung: Funktion B

technische Umsetzung: Funktion C

Durchführung: Test A

Planung der Testphase

Planung der Migration

Planung der Bereitstellung/

Anpassung

Durchführung: Test B

Durchführung: Test C

Durchführung: Migrations-

schritt A

Durchführung: Migrations-

schritt B

Abnahme der Iteration

Anfertigen eines Abschlussberichts

Anfertigen eines Abnahme-protokolls

Abbildung 7.8: Projektstrukturplan für eine Iteration

Da sich die Geschäftsprozesse in einem ständigen Wandel befinden, sollte eine vorhandene

Geschäftsprozessdokumentation nicht ohne Prüfung übernommen werden.

Verwandte Systeme

- 78 -

8 Verwandte Systeme Microsoft bietet ein pluripotentes Konzept für Unternehmen jeglicher Art an. Dazu gehören

SharePoint als Content Management System für Kollaboration und für

Dokumentenmanagement und Dynamics CRM für die Verwaltung von Kundendaten. Es gibt

weitere Systeme, die in Betracht gezogen werden können. Im Folgenden werden diese

Alternativen diskutiert.

8.1 Alternativen zu Microsoft SharePoint

Eine Statistik des Beratungsunternehmens Gartner veranschaulicht, welche Enterprise Content

Management Systeme die Führenden sind. Daraus wird erkennbar, dass IBM und Microsoft

die beiden führenden Unternehmen sind. (vgl. workshares, 2014)

Eine Alternative zu SharePoint ist IBM Notes, welches wie SharePoint das Arbeiten orts- und

zeitunabhängig ermöglicht und dabei Vorteile eines Dokumentenmanagementsystems bietet.

Ein weiteres, bekanntes Unternehmen, welches vergleichbare Produkte anbietet, jedoch nicht

in dieser Statistik aufgeführt wurde, ist SAP. SAP bietet mit dem Produkt SAP Enterprise

Portal eine Intranetlösung, die wie SharePoint auch Werkzeuge für Dokumentenmanagement

und Kollaboration anbietet.

Im Folgenden wird diese Auswahl an Konkurrenzprodukten detaillierter mit dem System

SharePoint verglichen.

8.1.1 IBM Notes

IBM bietet IBM Notes als Groupware32 an. Es bietet Funktionen zur Organisation und

Verwaltung von gemeinsamen Dokumenten, ermöglicht einen internen sowie externen

Nachrichtenaustausch und dient zur Termin- und Aufgabenverwaltung. Eine

Grundvoraussetzung zur Nutzung des Notes Systems ist der IBM Domino Server. Elmar

Fuchs beschreibt in dem Buch „Notes 9 - Grundlagen für Anfänger“ die Funktionalitäten des

Systems. Die folgenden Zeilen stellen eine kurze Zusammenfassung dar. (vgl. Fuchs, 2013, S.

7f)

IBM bietet mit Note eine Dokumentverwaltung an. In diesem Zusammenhang sind

Dokumente zum Beispiel Diskussionsbeiträge, Urlaubsanträge und Zeiterfassungstabellen.

Alle Daten werden in speziellen Anwendungen gespeichert, organisiert und verwaltet. Damit

keine unberechtigten Personen auf Dokumente zugreifen, verfügt auch IBM Notes über ein

vielstufiges Sicherheitskonzept, womit die Berechtigungen auf Anwendungen, Dokumente

und einzelnen Dokumenteninhalte verwaltet werden können.

IBM Notes beinhaltet einen E-Mail-Client. Neben Mails können Sofortnachrichten in einem

Chat ausgetauscht werden. Dafür steht eine Awareness-Funktion bereit, welche die

Verfügbarkeit anderer Nutzer visualisiert. Zusätzlich können über die Kalenderfunktion

Termine, Besprechungen, Veranstaltungen und Erinnerungen verwaltet werden. Aktivitäten

32 Groupware ist Software zur Unterstützung von Kollaboration.

Verwandte Systeme

- 79 -

und Aufgaben der Benutzer können mithilfe der Aufgabenverwaltung organisiert, delegiert

und überwacht werden.

Replizierung ist die Synchronisation zwischen den Domino-Servern und den mobilen

Rechnern. Dabei werden lokale Kopien der Server-Datenbank auf den Arbeitsgeräten

gehalten. Neben dem Notes-Client ist das System zusätzlich durch den Browser erreichbar. Es

werden Browser von verschiedenen Gerätetypen unterstützt.

8.1.2 SAP NetWeaver Portal

SAP NetWeaver ist eine Plattform für Geschäftsanwendungen. Eine Erweiterung davon ist

SAP NetWeaver Portal. Es dient der synchronen und asynchronen Kollaboration sowie der

Abbildung von Geschäftsprozessen. (vgl. Nicolescu, Klappert, & Krcmar, 2012, S. 13 und 19)

SAP NetWeaver kann in drei Ebenen unterteilt werden: Applikationsplattform, Integration

von Informationen und Integration von Menschen. Zusätzlich existieren die

Querschnittsbereiche Composite Application Framework und Lifecycle Management. (vgl.

Abbildung 8.1)

SAP NetWeaver

Co

mp

osi

te A

pp

licat

ion

Fra

mew

ork

Integration von Menschen

Integration von Informationen

Applikationsplattform

Multi-Channel Access

Abstraktion von Datenbank und Betriebssystem

Java EE ABAP

Portal Collaboration

Life

cycl

e M

anag

emen

t

Master Data Management

Business Intelligence

Knowledge Management

Abbildung 8.1: Aufbau von SAP NetWeaver

(Nicolescu, Klappert, & Krcmar, 2012, S. 20)

Verwandte Systeme

- 80 -

Die Ebene Integration von Menschen und zusätzlich die Komponente Knowledge

Management werden durch SAP NetWeaver Portal umgesetzt.

Um umfangreiche Daten konsistent auf mobilen Geräten darzustellen, dient der Multi-

Channel Access. Mobile Geräte sind nicht nur Smartphones und Tablets sondern auch

Laptops. So können Mitarbeiter im Außendienst ihre Daten synchronisieren und damit beim

Kunden arbeiten. Die Portal-Funktionen ermöglichen es Daten und Applikationen in einem

webbrowserbasierten Frontend anzuzeigen und zu nutzen. (vgl. Nicolescu, Klappert, &

Krcmar, 2012, S. 22)

Das Knowledge Management umfasst zwei größere Funktionen: Content Management und

TREX. TREX ist die Such- und Klassifizierungsmaschine von SAP NetWeaver. Zum Content

Management gehören die Verwaltung, Bearbeitung, Bewertung und der Austausch von

Dateien, das Führen von Diskussionen in Foren und das Erstellen und Benutzen von Wikis.

(vgl. Nicolescu, Klappert, & Krcmar, 2012, S. 45)

Die asynchrone und synchrone Zusammenarbeit zwischen Teams, wie zum Beispiel Instant

Messaging, E-Mails, Foren, Gruppenkalendern und Chatrooms wird im SAP NetWeaver

Umfeld unter Collaboration zusammengefasst. (vgl. Nicolescu, Klappert, & Krcmar, 2012, S.

22) Collaboration und Knowledge Management überschneiden sich in Funktionen der

Dokumentenverwaltung, der Forendiskussionen und des Wikis. Weitere wichtige Funktionen

sind die People-centric Components, welche das Suchen nach Personen ermöglichen.

Virtuelle Räume und das Synchronous Collaboration Framework mit der Real-Time

Collaboration zum Instant Messaging und Application Sharing, sind weitere Funktionen des

SAP NetWeaver Portals. Letztere stehen jedoch ausschließlich im Microsoft Internet Explorer

zur Verfügung.

8.1.3 Zusammenfassung

Microsoft SharePoint und SAP NetWeaver Portal sind zwei Content Management Systeme,

welche von Funktionsumfang ähnlich sind. IBM Note ist ein Mail-Client mit Kalender und

Aufgabenverwaltung. Der Fokus von IBM Notes liegt auf der Verwaltung der eigenen

Aufgaben und weniger auf Kollaboration.

Verwandte Systeme

- 81 -

In Tabelle 8.1 werden die zuvor beschriebenen Systeme und Microsoft SharePoint

gegenübergestellt:

Tabelle 8.1: Vergleich zwischen SharePoint Systemen

Microsoft

SharePoint

SAP NetWeaver

Portal

IBM Notes

CMS x x

Widgets x

RSS-Feeds x x

Suchfunktion x x x

E-Mail-Verwaltung x

Benachrichtigungen x x x

Textverarbeitung x x

Integration von Office x x

Chat x x

Wiki x x

Verwendung im Browser x x

Forum x x

Workflows zur

Dokumentenverwaltung

x x

Versionsverwaltung von Dokumenten x x

Umfragen x x

Aufgaben x x x

Kalender/Gruppenkalender x x x

Funktionen für Business Intelligence bieten weder SAP NetWeaver Portal, noch IBM Notes

Out-of-the-Box an. Beide Systeme können allerdings dahingehend erweitert werden, da

sowohl SAP als auch IBM passende Komponenten anbietet.

Durch den Vergleich des Funktionsumfangs der Systeme ist zu erkennen, dass IBM Notes

erheblich weniger Funktionen aufweist als SAP NetWeaver Portal und Microsoft SharePoint.

8.2 Alternativen zu Microsoft Dynamics CRM

Im Bereich CRM gibt es neben Microsoft auch SAP und Salesforce als Anbieter. SAP bietet

zwei Ausprägungen von CRM-Systemen an. Das umfangreiche SAP CRM, welches für die

großen Unternehmen und Konzerne gedacht ist und SAP Business ByDesign, welches auf die

kleinen und mittelständischen Unternehmen abzielt.

Verwandte Systeme

- 82 -

SAP Business ByDesign und das Salesforce CRM werden in den folgenden Abschnitten kurz

vorgestellt.

8.2.1 SAP Business ByDesign

SAP bietet nicht nur ein System für die Verwaltung von Kundenbeziehungen und anderen

Geschäftsprozessen, sondern eine ganze Produktfamilie in der sowohl Systeme für

Großunternehmen als auch für Kleinunternehmen integriert sind. Abbildung 8.2 zeigt das

SAP Portfolio für CRM-Systeme.

GroßunternehmenKleine und mittelständische

Unternehmen

SAP Business Suite

SAP Business All-in-One

SAP Business ByDesign

SAP Business One

SAP BusinessObjects-Portfolio

SAP-Lösungen für nachhaltige Unternehmensführung

SAP NetWeaver

Abbildung 8.2: SAP CRM Portfolio

(Konstantinidis, Kienegger, Flormann, Wittges, & Krcmar, 2012, S. 42)

SAP empfiehlt für mittelständische Unternehemen folgende Systeme:

- SAP Business One für Unternehmen mit bis zu 100 Mitarbeitern

- SAP Business ByDesign für Unternehmen mit 100 bis 500 Mitarbeitern und

- SAP Business All-in-One für Unternehmen mit bis zu 2.500 Mitarbeitern

(vgl. Konstantinidis, Kienegger, Flormann, Wittges, & Krcmar, 2012, S. 42)

Eine weitere Unterteilung der SAP Systeme ist die Einteilung der Systeme in On-Device-

Systeme, On-Deman33-Systeme und On-Premise-Systeme. SAP Business ByDesign ist eine

On-Deman-Lösung, welche von SAP bereitgestellt, gewartet und weiterentwickelt wird.

33 On-Deman-Lösungen sind Systeme die vom Anbieter gehostet werden.

Verwandte Systeme

- 83 -

Dafür entrichtet der Kunde eine monatliche Gebühr, anstatt Lizenzen zu erwerben. On-

Premise-Systeme sind diejenigen Systeme, die der Kunde nach Erwerb der nötigen Lizenzen

selbst hostet, wartet und weiterentwickelt. Dies sind vor allem SAP Business Suit und SAP

CRM. SAP ist bestrebt alle Lösungen auf mobilen Endgeräten wie Smartphone und Tablet als

On-Device-Systeme bereitzustellen. (vgl. Konstantinidis, Kienegger, Flormann, Wittges, &

Krcmar, 2012, S. 44f)

SAP Business ByDesign bietet in acht Bereichen Lösungsansätze für mittelständische

Unternehmen:

- Managementunterstützung durch integrierte Analyse- und Berichtsinstrumente, sowie

Berechtigungs- und Genehmigungskonzepte.

- Finanzmanagement mit den Instrumentarien für das interne und externe

Rechnungswesen.

- Kundenbeziehungsmanagement mit den verschiedenen Marketingaktivitäten, wie

Kampagnen und Opportunities.

- Personalmanagement für die Pflege des aktiven Personals von der Lohnabrechnung bis

hin zu den organisatorischen Strukturen.

- Produktions- und Logistikmanagement durch die Abbildung von Materialien,

Stücklisten, Arbeitspläne und Produktionsmodellen.

- Projektmanagement und Projektcontrolling durch automatisierte Prozesse.

- Lieferantenbeziehungsmanagement für die Verwaltung von Bezugsquellen und

Materialien.

- Compliance Management zur Sicherung gesetzlicher Vorgaben.

(vgl. Konstantinidis, Kienegger, Flormann, Wittges, & Krcmar, 2012, S. 48f)

Mit diesen Lösungen kann SAP Business ByDesign nicht nur als CRM kategorisiert werden

sondern auch als ERP-Systemen34.

34 ERP-Systeme unterstützen unternehmerische Tätigkeiten wie Ressource-, Kapital-, Betriebmittel-,

Material- und Informationsplanung,

Verwandte Systeme

- 84 -

8.2.2 Salesforce CRM

Salesforce CRM ähnelt mit den drei Bereichen Marketing Administration, Salesforce

Automation und Customer Service and Support Automation dem Microsoft Dynamics CRM

stark. (vgl. Abbildung 8.3) Um Verwechslungen zu vermeiden, werden die drei

Funktionsbereichen im Folgenden mit den englischen Begriffen bezeichnet.

MarketingAdministration

Customer service and support Automation

Salesforce Automation

Abbildung 8.3: Anwendungsbereiche des Salesforce CRM

(Goodey, 2011, S. 243)

Der Bereich Marketing Administration dient dazu Campaigns, Leads und Opportunities zu

erstellen, zu verwalten und auszuwerten. Die Salesforce Automation ist der Kern des CRM

und dient zur Verwaltung von Sales Activities, Leads, Contacts, Opportunities, Qoutes und

Forecasts35. Dabei haben die Entitäten im Salesforce CRM sehr ähnliche Bedeutung wie die

Entitäten im Microsoft Dynamics CRM. Customer service and support Automation werden

auch als Service Cloud bezeichnet und dienen zur Organisation des Service- und

Supportteams, sowie der Anfragen, die an diese Teams gestellt werden. (vgl. Goodey, 2011,

S. 243f) Alle drei Bereiche arbeiten wie in Abbildung 8.4 zu sehen im Salesforce CRM

Record Lifecycle zusammen. (vgl. Goodey, 2011, S. 244f)

Marketing Administration Marketing/Sales

Salesforce Automation

Customer Acquisition

Customer service and support Automation

Campaigns LeadsAccounts Contacts

Opportunities

Sales (Won Deals)

Cases

Abbildung 8.4: Lebenszyklus der Entitäten in Salesforce CRM

(Goodey, 2011, S. 244)

35 Forecasts ist in diesem Kontext die englische Bezeichnung für Vorhersage.

Verwandte Systeme

- 85 -

Dieser Lifecycle bildet die Kundenbeziehung von der Kundengewinnung bis zur nachhaltigen

Kundenbindung ab. Im ersten Schritt stehen die Campaigns, welche zur Verwaltung von

Werbemitteln dienen. Aus Campaigns werden Leads, also die potenziellen Kunden abgeleitet.

Aus diesen wiederrum werden die Contacts, Accounts und Opportunities erzeugt. Kommt es

zu einem Verkauf, werden die Sales erstellt und im Anschluss die Cases für die Service- und

die Supportverträge eines Kunden.

Ein eigenes Hosting ist mit Salesforce CRM nicht möglich. Salesforce setzt auf den Software-

as-a-Service-Ansatz36

8.2.3 Zusammenfassung

Salesforce CRM und Microsoft Dynamics CRM besitzen einen ähnlich großen Umfang an

Grundfunktionalität. SAP Business ByDesign ist eher ein ERP-System als ein CRM-System.

Folgend eine Auflistung der Geschäftsszenarien, die mit den drei Produkten realisiert werden

können. Tabelle 2.1 orientiert sich an der Tabelle von Konstantinidis, Kienegger, et al.

Tabelle 8.2: Vergleich zwischen CRM Systemen

Mic

roso

ft

Dyn

am

ics

CR

M

SA

P B

usi

nes

s

ByD

esig

n

Sale

sforc

e C

RM

Geschäftsszenario F D F D F D

Beschaffung

Planungsgesteuerte Beschaffung x

Nichtlagerbeschaffung x x

Servicebeschaffung x x

Strategische Bezugsquellenfindung x

Produktkatalogverwaltung x x x x

Lieferantenretouren x x

Produktentwicklung

Produktkonstruktion x

Produktdefinition x x x

Produktentwicklung x

36 Software-as-a-Service sind Systeme, die für die Benutzer nur online zur Verfügung stehen. Es ist

vergleichbar mit Cloud-Lösungen.

Verwandte Systeme

- 86 -

Vertrieb und Marketing

Marketing-to-Opportunity x x x

Vertriebsplanung x x x x x x

Auftragsabwicklung x x x x

Kundenretourenabwicklung x

Kundenvertragsverwaltung x x x

Projektmanagement

Projektmanagement x

Auftragsabwicklung x x x

Service und Support

Vor-Ort-Service und Reparatur x x x

Bearbeitung von Kundenanfragen x x x

Finanzwesen

Zahlungsmittelverwaltung x x x x x x

Bearbeitung von Forderungen und Zahlungen x x

Bearbeitung von Verbindlichkeiten und Zahlungen x x

Kassenverwaltung x x

Anlagenbuchhaltung x x

Steuerverwaltung x x x x

Hauptbuch x x

Abschluss x x

Konsolidierungsvorbereitung x x

Spesenerstattung x x

Finanzplanung x x

Materialvorkalkulation x x

Personalwesen

Workforce Administration x x x x

Arbeitszeitmanagement x x x x

Personalabrechnung x x x x

Ressourcenmanagement x x x x

(vgl. Konstantinidis, Kienegger, Flormann, Wittges, & Krcmar, 2012, S. 50 ff)

Dadurch, dass SAP im Gegensatz zu Microsoft ein in Deutschland gegründetes Unternehmen

ist, sind auch deren Produkte eher für den deutschen Markt optimiert. Microsoft und

Verwandte Systeme

- 87 -

Salesforce haben bezüglich Steuern und andere rechtliche Vorgaben Nachholbedarf. Nicht zu

unterschätzen ist auch die Tatsache, dass Microsoft Dynamics CRM im Haus selbst gehostet

werden kann. SAP Business ByDesign ist eine On-Deman-Lösung und Salesforce CRM ist

Software-as-a-Service, das Hosting findet also in den SAP- beziehungsweise in Salesforce-

Rechenzentren statt.

Verwandte Arbeiten

- 88 -

9 Verwandte Arbeiten

Maximilian Peters beschreibt in seiner Masterarbeit die Entwicklung einer Sprache, um

Anforderungen zu beschreiben und einen Ansatz zur Überführung von Projektdokumenten in

Ontologien. Seine Ergebnisse sollen dazu dienen die erhobenen Anforderungen mit den

Ergebnissen im Projekt abzugleichen und um so schnell auf Abweichungen zu reagieren. Es

selbst betont allerdings, dass seine Ansätze durch die starken Einschränkungen der

Grammatik, der Sprache zur Beschreibung der Anforderungen, nicht wirtschaftlich genutzt

werden können. Dies bestätigten auch die Experten, welche er im Rahmen seiner Studien

befragte. (Peters, 2013)

Jan Conrad prüfte in seiner Dissertation die Nutzung von semantischen Netzen zur Erfassung

und Verbreitung von Informationen und Wissen in der Produktentwicklung. Dabei geht er

sehr stark auf die Möglichkeiten semantischer Netze zur Wissensrepräsentation ein. Er

verfolgte den Ansatz Ressourcen und Produktentwicklungstheorien durch Ontologien zu

repräsentieren. Doch aufgrund der hohen Komplexität von Ontologien stellt er die produktive

Nutzung seiner Ergebnisse in Frage. (Conrad, 2010)

Stefan Harnisch untersuchte in seiner Dissertation den anwenderseitigen Lebenszyklus von

Standardsoftware in Unternehmen, wofür er Literaturanalysen und empirische

Untersuchungen heranzog. Dabei stellte er ein allgemeines Softwareeinkaufs-Prozessmodell

auf. Er beschreibt auch die Zusammenarbeit der IT- und Fachabteilungen bei der Auswahl

von Standardsoftware. Abschließend stellt er Handlungsempfehlungen für die erfolgreiche

Softwareauswahl dar. (vgl. Harnisch, 2015)

Anne Katrin Neumann setzte in ihrer Dissertation die Benutzer bei der Umsetzung von CRM

in den Mittelpunkt. Sie beschreibt die Fehlschlagquote von CRM-Projekten und

erfolgskritische Mitarbeiter-Rollen. Dabei geht sie auch darauf ein, wie mit diesen Rollen im

Unternehmen umgegangen werden sollte. CRM-Projekte betrachtet sie nicht als technische

Projekte zur Einführung eines CRM-Systems sondern als ganzheitliches Projekt zur

Verbesserung des Kundenmanagements. (vgl. Neumann, 2013)

Fazit

- 89 -

10 Fazit Ziel der vorliegenden Arbeit war es einen Projektplan zu erstellen, welcher die Einführung

von SharePoint und Dynamics CRM erleichtert. Dies wurde in vier Schritten erreicht. Durch

die Systemanalyse im ersten Schritt wurde ein allgemein verständliches Bild der beiden

Systeme geschaffen. Es wurde beschrieben, dass die Systeme für die Themenbereiche

Dokumentenmanagement, Kollaboration, Business Intelligence, Geschäftsprozesse und

Projektmanagement geeignet sind. Der zweite Schritt diente zur Anforderungserhebung durch

Experteninterviews. Wie bereits geschildert, wurden in zwei Samplings Vertriebler und

Consultants zu ihren Erfahrungen in fünf Themengebieten befragt. Dabei konnten neben den

Anforderungen auch Zielgruppeneigenschaften und Gründe der geringen Benutzerakzeptanz

gewonnen werden. Durch die Zusammenführung von Systemanalyse und

Anforderungserhebung konnte über einen semantischen Ansatz ein Anforderungskatalog

konzipiert werden. Das Matching zwischen Funktionen und Anforderungen wurde aufgrund

der Ähnlichkeit der Bedeutungen durch Ontologien und SPARQL-Abfragen realisiert. Dabei

wurden zwei verschiedene Ansätze vorgestellt. Die Entscheidung fiel auf den Ansatz in der

die Gewichtung der einzelnen Anforderungen mit einfließen konnte.

Die Auswertung der Interviews nach Grounded Theory im dritten Schritt diente der Definition

der Faktoren, die ausschlaggebend für eine geringe Benutzerakzeptanz sind. Um Faktoren mit

ähnlichen Bezug zu definieren, wurden die durch Grounded Theory erzeugten Kategorien in

Gruppen nach den Themengebieten und deren Schnittmengen gegliedert. Die entscheidenden

Faktoren und die Ergebnisse aus den vorangegangenen Untersuchungen wurden dazu genutzt,

um bereits bewährte Projektmanagementmethoden auf die Einführung der Systeme

anzupassen. Die daraus entstandenen Ergebnisse sind nicht SharePoint beziehungsweise

Dynamics CRM spezifisch. Der entstandene Rahmenprojektplan kann auch auf ähnliche

Systeme wie SAP NetWeaver Portal oder Salesforce CRM angewandt werden.

10.1 Kritische Würdigung

Diese Arbeit entstand in einem Unternehmen. Deshalb musste ein Mittelweg zwischen

Forschung und Wirtschaft gefunden werden. Die Forschung verlangt, tiefgehende und

kritische Auseinandersetzungen mit den im Forschungsfokus befindlichen Themen. Die

Wirtschaft fordert möglichst viele Ergebnisse in einer möglichst kurzen Zeit. Dies führte

dazu, dass mehrere verschiedene Themen in dieser Arbeit meist nur kurz betrachtet wurden.

So wurde eine Systemanalyse an theoretischer Literatur durchgeführt, anstatt an Systemen die

in verschiedenen Unternehmen eingesetzt wurden. Die Anforderungserhebung geschah durch

die Befragung von Vertrieblern und Consultants, welche zwar auch Benutzer solcher Systeme

sind, aber einen anderen Blickwinkel als andere Benutzergruppen haben. Die Ergebnisse der

Analysen sind in den meisten Fällen aussagekräftig, könnten allerdings durch eine

detailliertere Betrachtung des Forschungsfeldes weitreichender sein.

Der semantische Vergleich ist ein Mittel, um die Funktionen auf die Anforderungen

abzugleichen. Doch auch hier gibt es Forschungsbereiche die noch tiefer gehen. So zum

Beispiel in der Arbeit von Maximilian Peters, in der eine Sprache entwickelt wurde, die dazu

genutzt werden kann, um Anforderungen zu beschreiben, welche dann wiederum mit

Projektdokumenten verglichen werden. (vgl. Peters, 2013) In dem hier beschriebenen

Fazit

- 90 -

Verfahren wurden die Anforderungen in SPARQL-Abfragen übersetzt, um den semantischen

Vergleich herzustellen. Die Implementierungen des Anforderungskatalogs konnten bis zur

Fertigstellung dieser Arbeit nicht abgeschlossen werden, weshalb noch nicht mit Gewissheit

gesagt werden kann, dass dieser Ansatz die gewünschten Ergebnisse liefert.

Den größten Gewinn bilden die Projektpläne, die an die Einführung der Systeme angepasst

wurden. Die Grundlage dieser Anpassungen sind die Ergebnisse aus den Interviews und aus

der Systemanalyse. Durch diese war es möglich die Besonderheiten der Systeme zu

beschreiben und in den Projektplänen darauf einzugehen. Der in dieser Arbeit beschriebene

Hergang, das heißt die Systemanalyse, die Anforderungserhebung, die Akzeptanzanalyse und

die Anpassungen der Projektpläne, kann so auf jede Art von Systemen umgesetzt werden.

10.2 Ausblick

Die vorgestellten Ergebnisse zeigen, dass der wichtigste Faktor der Einführung von

SharePoint und Dynamics CRM die Benutzer sind. Diese müssen frühzeitig in die Projekte

mit eingebunden werden. Bei der Einführung sollte der beschriebene Projektplan genutzt

werden. Dabei sollte der Fokus auf die Anforderungsanalyse und die Einbindung der Benutzer

liegen. Zusätzlich sollten bei diesen Projekten immer eine Studie geführt werden, welche

Stakeholder einbezogen werden und wie die Benutzer das System annehmen. Dabei soll

ermittelt werden welche Faktoren positive und negative Wirkung auf den Erfolg der Systeme

haben.

Abschließend ist festzuhalten, dass die Umsetzung solcher Systeme keine reinen IT-Projekte

sind, sondern auch immer strategische und organisatorische Relevanz haben. Dies muss in der

Konzeptionierung und Planung der Projekte berücksichtigt werden.

Literaturverzeichnis

- 91 -


Alitezaei, R., Schwartz, B., Ranlett, M., Hiller, S., Wilson, B., Fried, J., & Swider, R. J.

(2013).

Professional SharePoint 2013 Development. Indianapolis: John Wiley & Sons, Inc.

Bogner, A., Littig, B., & Menz, W. (2014).

Interviews mit Experten. Eine praxisorientierte Einführung. Springer Fachmedien

Wiesbaden.

Bornemann, S. (2011).

Kooperation und Kollaboration. Das Kreative Feld als Weg zu innovativer

Teamarbeit. Kassel: VS Verlag für Sozialwissenschaften | Springer Fachmedien

Wiesbaden 2012.

Conrad, J. (2010).

Semantische Netze zur Erfassung und Verarbeitung von Informationen und Wissen in

der Produktentwicklung. Saarbrücken.

Felkai, R., & Beiderwieden, A. (2013).

Projektmanagement für technische Projekte. Ein prozessorientierter Leitfaden für die

Praxis. 2., überarbeitete Auflage. Wiesbaden: Springer Fachmedien.

Freund, J., & Götzer, K. (2008).

Vom Geschäftsprozess zum Workflow. Ein Leitfaden für die Praxis. Carl Hanser

Verlag München.

Fuchs, E. (2013).

IBM Notes 9 Grundlagen für Anwender. 1. Auflage. HERDT-Verlag für

Bildungsmedien GmbH.

Gamma, E., Helm, R., Johnsin, R., & Vlissides, J. (2009).

Design Patterns. Elements of Reusable Object-Oriented Software. 37th Printig.

Indianapolis: Addison-Wesley.

Goodey, P. (2011).

Salesforce CRM: The Definitive Admin Handbook. Packt Publishing.

Harnisch, S. (2015).

Einkauf und Einsatz von Unternehmenssoftware. Empirische Untersuchungen zum

anwenderseitigen Software-Lebenszyklus. Wiesbaden: Springer Fachmedien.


- 92 -

Herrmann, A., Knauss, E., & Weißbach, R. (2013).

Requirements Engineering und Projektmanagement. Berlin Heidelberg: Springer-

Verlag.

Hubrich, B. (2014).

Strategisches CRM. Entwicklung eines Referenzprozesses. Hamburg: VERLAG DR

KOVAČ GmbH.

Koch, O. (2008).

Strategieorientierte Einführung komplexer Softwaresysteme Vorgehensmodell zur

Sicherung von Wettbewerbsvorteilen und zum TCO-Projektmanagement 1. Auflage.

WITEC Verlag Kassel.

Konstantinidis, Kienegger, Flormann, Wittges, & Krcmar. (2012).

SAP Business ByDesign. Anpassungen und Integration. 1. Auflage. Bonn: Galileo

Press.

Krotz, F. (2005).

Neue Theorien entwickeln. Eine Einführung in die Grounded Theory, die Heuristische

Sozialforschung und die Ethnographie anhand von Beispielen aus der

Kommunikationsforschung. Köln: Herbert von Harlem Verlag.

Larisch, D. (2013). Microsoft SharePoint 2013 Über 300 Lösungen für Anwender &

Administratoren. Carl Hander Verlag GmbH & Co. KG.

Micka, W., Trantopoulos, M., Elborg, T., Keilholz, S., & De Maddalena, M. (2014).

Microsoft SharePoint 2013 für Administratoren - Das Handbuch 1. Auflage. Microsoft

GmbH.

Misoch, S. (2014).

Qualitative Interviews 1. Auflage. Walter de Gruyter GmbH.

Müller, R., & Lenz, H.-J. (2013).

Business Intelligence. Berlin: Springer-Verlag Berlin Heidelberg.

Nicolescu, V., Klappert, K., & Krcmar, H. (2012).

SAP NetWeaver Portal. 2. Auflage. Bonn: Galileo Press.

Pfohl, H.-C. (2013).

Betriebswirtschaftslehre der Mittel- und Kleinbetriebe. 5. Auflage. Berlin: Erich

Schmidt Verlag GmbH & Co KG.

Plass, C., Rehmann, F. J., Zimmermann, A., Janssen, H., & Wibbing, P. (2013).

Chefsache IT. Wie Sie Cloud Computing und Social Media zum Treiber Ihres

Geschäfts machen. Berlin Heidelberg: Springer-Verlag.


- 93 -

Reh, E. (01. 12 2011).

computerwoche. Von http://www.computerwoche.de/a/risiken-der-einfuehrung-

vermeiden,1908362 abgerufen

Schmidt, M. (2013).

Microsoft SharePoint 2013. Das Praxisbuch für Anwender 1. Auflage. dpunkt.verlag

GmbH.

Schneider, K. (2014).

Vorlesung: Moderne Entwicklungsmethoden. Hannover.

Steinbrecher, W., & Müll-Schnurr, M. (2014).

Prozessorientierte Ablage. Dokumentenmanagement-Projekte zum Erfolg führen

Praktischer Leitfaden für die Gestaltung einer modernen Ablagestruktur. 3.,

überarbeitete Auflage. Wiesbaden: Springer Fachmedien.

Stuckenschmidt, H. (2009).

Ontologien. Konzepte Technologien und Anwendungen. 1. Auflage. Springerverlag

Berlin-Heidelberg.

Teich, I., Kolbenschlag, W., & Reiners, W. (2008).

Der richtige Weg zur Softwareauswahl. Lastenheft, Pflichtenheft, Compliance,

Erfolgskontrolle. Berlin Heidelberg: Springer-Verlag.

Wolenik, M. (2014).

Microsoft Dynamics CRM 2013 Unleashed. First Printing (E-Book). Tearson

Education Inc.

workshares. (05. 12 2014).

Von http://www.workshares.co.uk/our-blog/microsoft-sharepoint-gartner-enterprise-

content-management-ecm-2013/ abgerufen

Wytrzens, H. K. (2010).

Projektmanagement. Der erfolgreiche Einstieg. 2., erweiterte Auflage. Wien, Austria:

Facultas Verlags- und Buchhandels AG.

Zehnder, C. A. (2003).

Informatik-Projektentwicklung. 4. Auflage. vdf - Praxis und Lehre.

Anhang A – Charakterisierung von Klein-, Mittel- und Großbetrieben

- 95 -


Branche und Größenklasse Größenklasseneinteilung

nach Beschäftigten nach Umsatz

Industrie

klein bis 49 bis 1 Mio. €

mittel 50 – 499 1 Mio. – 12,5 Mio. €

groß 500 und mehr 12,5 Mio. € und mehr

Handwerk

klein bis 2 bis 50.000 €

mittel 3 – 49 50.000 – 1 Mio. €

groß 50 und mehr 1 Mio. € und mehr

Großhandel


mittel 10 – 199 500.000 -25 Mio. €


Einzelhandel


mittel 3 – 49 250.000 – 5 Mio. €


Verkehr und Nachrichtenübermittlung


mittel 3 – 49 50.000 -1 Mio. €


Dienstleistungen von Unternehmen und freien Berufen


mittel 3 – 49 50.00 – 1 Mio. €


(Pfohl, 2013, S. 10)

Unternehmensführung

Klein- und Mittelbetriebe Großbetriebe


- 96 -

Eigentümer-Unternehmer Manager

mangelnde Unternehmensführungskenntnisse fundierte Unternehmensführungskenntnisse

technisch orientierte Ausbildung gutes technisches Wissen in Fachabteilungen und

Stäben verfügbar

unzureichendes Informationswesen zur Nutzung

vorhandener Flexibilitätsvorteile

ausgebautes formalisiertes Informationswesen

patriarchalische Führung Führung nach Management-by-Prinzipien

kaum Gruppenentscheidungen häufig Gruppenentscheidungen

große Bedeutung von Improvisation und Intuition geringe Bedeutung von Improvisation und

Intuition

kaum Planung umfangreiche Planung

durch Funktionshäufung überlastet; wenn

Arbeitsteilung, dann personenbezogen

hochgradig sachbezogene Arbeitsteilung

unmittelbare Teilnahme am Betriebsgeschehen Ferne zum Betriebsgeschehen

geringe Ausgleichsmöglichkeiten bei

Fehlentscheidungen

gute Ausgleichsmöglichkeiten bei

Fehlentscheidungen

Führungspotential nicht austauschbar Führungspotential austauschbar

Organisation


auf den Unternehmer ausgerichtetes

Einliniensystem, von ihm selbst oder mit Hilfe

weniger Führungspersonen bis in die Einzelheiten

überschaubar

personenunabhängig an den sachlichen

Gegebenheiten orientierte komplexe

Organisationsstruktur

Funktionshäufung Arbeitsteilung

kaum Abteilungsbildung umfangreiche Abteilungsbildung

kurze direkte Informationswege vorgeschriebene Informationswege

starke persönliche Bindungen geringe persönliche Bindungen


- 97 -

Weisungen und Kontrolle im direkten

personenbezogenen Kontakt

formalisierte unpersönliche Weisungs- und

Kontrollbeziehungen

Delegation in beschränktem Umfang Delegation in vielen Bereichen

kaum Koordinationsprobleme große Koordinationsprobleme

geringer Formalisierungsgrad hoher Formalisierungsgrad

hohe Flexibilität geringe Flexibilität

Beschaffung


schwache Position am Beschaffungsmarkt starke Position am Beschaffungsmarkt

häufig auftragsbezogene Materialbeschaffung überwiegend auftragsunabhängige

Materialbeschaffung, abgesichert durch

langfristige Verträge mit Lieferanten

Produktion


arbeitsintensiv kapitalintensiv

geringe Arbeitsteilung hohe Arbeitsteilung

überwiegend Universalmaschinen überwiegend Spezialmaschinen

geringe Kostendegression steigender

Ausbringungsmenge

starke Kostendegression mit steigender

Ausbringungsmenge

häufig langfristig gebunden an eine bestimmte

Basisinnovation

keine langfristige Bindung an eine

Basisinnovation

Absatz



- 98 -

Deckung kleindimensionierter individualisierter

Nachfrage in einem räumlich und/oder sachlich

schmalen Marktsegment

Deckung großdimensionierter Nachfrage in einem

räumlich und/oder sachlich breiten Marktsegment

Wettbewerbsstellung sehr uneinheitlich gute Wettbewerbsstellung

Logistik

Klein. Und Mittelbetriebe Großbetriebe

keine systematische Umsetzung von

Logistikkonzepten

oft Logistikkonzeption vorhanden

leine institutionalisierte Logistikabteilung meist institutionalisierte Logistikabteilung

Schwerpunkt auf der Ausführung der operativen

logistischen Tätigkeiten

operatives und strategisches Logistikmanagement

Finanzierung


im Familienbesitz in der Regel breit gestreuter Besitz

kein Zugang zum anonymen Kapitalmarkt,

dadurch nur begrenzte

Finanzierungsmöglichkeiten

ungehinderter Zugang zum anonymen

Kapitalmarkt, dadurch vielfältige

Finanzierungsmöglichkeiten

keine unternehmensindividuellem kaum

allgemeine staatliche Unterstützung in

Krisensituationen

unternehmensindividuelle, staatliche

Unterstützung in Krisensituationen

wahrscheinlich

Forschung und Entwicklung


keine dauernd institutionalisierte Forschungs- und

Entwicklungsabteilung

dauernd institutionalisierte Forschungs- und

Entwicklungsabteilung

kurzfristig-intuitiv ausgerichtete Forschung und

Entwicklung

langfristig-systematisch angelegte Forschung und

Entwicklung


- 99 -

fast ausschließlich bedarfsorientierte Produkt-

und Verfahrensentwicklung, kaum

Grundlagenforschung

Produkt und Verfahrensentwicklung in engen

Zusammenhang mit Grundlagenforschung

relativ kurzer Zeitraum zwischen Erfindung und

wirtschaftliche Nutzung

relativ langer Zeitraum zwischen Erfindung und

wirtschaftlicher Nutzung

Personal

Kein- und Mittelbetriebe Großbetriebe

geringe Anzahl von Beschäftigten hohe Anzahl von Beschäftigten

häufig unbedeutender Anteil von ungelernten und

angelernten Arbeitskräften

häufig großer Anteil von ungelernten und

angelernten Arbeitskräften

wenige Akademiker beschäftigt Akademiker in größerem Umfang beschäftigt

überwiegend breites Fachwissen vorhanden starke Tendenz zum ausgeprägten

Spezialistentum

vergleichsweise hohe Arbeitszufriedenheit geringe Arbeitszufriedenheit

Entsorgung


oft extreme Verhaltensweisen (Umgehung

abfallpolitischer Normen oder aber Nutzung

entsorgungsrelevanter Innovationspotentiale)

häufig reaktive Politik der Risikobegrenzung

kein öffentlichen Interesse an der

Entsorgungspolitik des Unternehmens

Entsorgungspolitik oft Bestandteil der PR, da

großes öffentliches Interesse

(Pfohl, 2013, S. 19)

Anhang B – Funktionsliste

- 101 -


Funktionsbeschreibung SharePoint CRM

Allgemein

Erweiterung durch Apps bzw. Solutions möglich ja ja

Manübänder ja ja

Erweiterung von Menübändern ja ja

Präsentationsansicht ja ja

Mobile Nutzung ja ja

Content Management

Listen von Elementen ja ja

Anfügen von Anhängen zu Elementen ja ja

Suchen von Elementen ja ja

Versionierung von Elementen ja ja

Anpassen von Listen ja ja

Hinzufügen von Listen ja ja

Löschen von Listen ja ja

Vorlagen für Listen sind vorhanden ja nein

Anpassen von Ansichten ja ja

Hinzufügen von Ansichten ja ja

Löschen von Ansichten ja ja

Personalisierung von Ansichten ja ja

Vorlagen für Ansichten sind vorhanden ja ja


- 102 -

Anpassen von Feldern ja ja

Hinzufügen von Feldern ja ja

Löschen von Feldern ja ja

Anpassen von Formularen ja ja

Hinzufügen von Formularen ja ja

Löschen von Formularen ja ja

Anpassen von Websites ja nein

Erstellen von öffentlichen Websites ja nein

Erstellen von semiöffentlichen Websites ja nein

Erstellen von privaten Websites ja nein

Löschen von Websites ja nein

Personalisierung von Websites ja nein

Vorlagen für Websites sind vorhanden ja nein

Einbinden von Webressourcen ja ja

Systemweite Suche ja nein

Webinhaltsdienste zur Veröffentlichung von Inhalten ja nein

Web Content Management ja nein


Erstellen von Bibliotheken ja nein

Anpassen von Bibliotheken ja nein

Löschen von Bibliotheken ja nein

Bibliotheken für Officedokumente ja nein

Bibliotheken für Bilder ja nein

Bibliotheken für Berichte (Excel-Tabellen, Dashboards und KPI) ja nein


- 103 -

Bibliotheken für Videos und Sounds ja nein

Bibliotheken für Visio-Zeichnungen ja nein

Bibliotheken für sonstige Dateien ja nein

Vorlagen für Bibliotheken ja nein

Vorlagenmanagement für Dokumente ja nein

Zentrales Dokumentencenter ja nein

Ein- und Auschecken von Dokumenten ja nein

Suchen nach Dokumenten ja nein

Inhaltssuche in Dokumenten ja nein

Versionierung von Dokumenten ja nein

Verwaltung von Informationsverwaltungsrichtlinien ja nein

Einbinden eines Fileservers zur Dateiverwaltung ja nein

Kollaboration

Aufgabenmanagement ja ja

persönliche Aufgabensammlung ja ja

Vorlage für Listen mit Problemen und offenen Punkten ja ja

Vorlage für Pojektaufgabenliste ja nein

Vorlage für Projektwebsites ja nein

Vorlagen für Ankündigungslisten ja nein

Vorlagen für Kontaktlisten ja ja

Vorlagen für Linklisten ja nein

Vorlagen für Teamwebsites ja nein

Newsfeed ja nein

Persönlicher Bereich mit eigenem Newsfeed ja nein


- 104 -

eigene Profilwebsite ja nein

Folgen von Datensätzen ja ja

Folgen von Benutzern ja nein

Folgen von Websites ja nein

Folgen von Listen ja nein

Folgen von Bibliotheken ja nein

Liste mit Wissensartikeln ja ja

Wiki ja nein

Vorlage zur Organisation von Produkt- und Dienstleistungsbeschreibungen nein ja

Blog ja nein

Forum ja nein

Erstellen von Umfragen ja nein

Durchführen von Umfragen ja nein

Integration sozialer Netzwerke ja nein

Kalender ja ja

Synchronisation mit dem Outlookkalender ja ja

Referenzieren von Mails aus Outlook nein ja

Geschäftsprozesse

Erstellung von Workflows ja ja

Generierung von Objekten ja ja

berechnen von Werten in Formularen ja ja

automatischer Versand von E-Mails ja ja

kontrollieren von falschen Eingabewerten ja ja

Prozessunterstützung durch Dialoge nein ja


- 105 -

Prozessunterstützung durch Schritt-für-Schritt-Anleitungen nein ja

Vorlage für Kundenverwaltung nein ja

Vorlage für Ressourcenverwaltung nein ja

Vorlage für Auftragsabwicklung nein ja

Vorlage für Bestellabwicklung nein ja

Vorlage für Rechnungsverwaltung nein ja

Vorlage für statische Marketinglisten nein ja

Vorlage für dynamische Marketinglisten nein ja

Vorlage für Kampagnenverwaltung nein ja

Vorlage für Konkurrentenverwaltung nein ja

Produktkatalogsvorlage nein ja

Export in Excel ja ja

Import aus CSV ja ja


Verknüpfung beliebiger Daten nein ja

Generierung von Reports nein ja

Generierung von Diagrammen ja ja

Vorlagen für Dashboards ja ja

Ziele definieren ja ja

Übergeordnete Ziele definieren nein ja

Teamziele definieren nein ja

Ziele kontrollieren ja ja

Teamziele kontrollieren nein ja

Anhang C – Interviewdokumente

- 107 -


Interview zur Anforderungserhebung in KMU

Allgemeine Informationen über den Interviewten

1. Seit wann arbeitest du als Vertriebler/Consultant für KMU?

2. Wie viele Kunden hast du bereits als Vertriebler/Consultant betreut und wie groß sind

diese Kunden?

3. Wie sieht dein Kontakt mit den Kunden aus?


1. Welche Systeme werden am häufigsten für das Dokumentenmanagement bei deinen

Kunden genutzt?

2. Wie sieht der Dokumentenlebenszyklus bei deinen Kunden aus?

3. Nenne bitte 10 Anforderungen in Bezug auf Dokumente, die dir bei deinen Kunden

begegnen.

Kollaboration

1. Was verstehen deine Kunden unter Kollaboration? Gehört Wissensmanagement dazu?

2. Wie stellen deine Kunden Wissen für die Mitarbeiter bereit?

3. Glaubst du, dass deine Kunden offen für Social Media im Unternehmen sind? Warum?


1. Was verstehen deine Kunden unter Business Intelligence?

2. Arbeiten deine Kunden viel mit Diagrammen, Reports und anderen

Präsentationsmöglichkeiten um ihre Unternehmenszahlen zu repräsentieren?

3. Glaubst du, dass deine Kunden Business Intelligence unterschätzen/überschätzen?

4. Nenne bitte 10 Anforderungen in Bezug auf Business Intelligence, die dir bei deinen

Kunden begegnen.

Geschäftsprozesse

1. Glaubst du es gibt Standardgeschäftsprozesse?

2. Welche Geschäftsprozesse sind das?

3. Bei welchen Geschäftsprozessen macht es Sinn, diese durch Software zuunterstützen?

Projektmanagement

1. Setzen deine Kunden bewusst Projektmanagement ein?

2. Setzen deine Kunden Software für Projektmanagement ein? Welche?

3. Welche Methoden des Projektmanagements begegnen dir bei deinen Kunden?


- 108 -

Einverständniserklärung zur Durchführung eines Interviews

1. Die Teilnahme am Interview ist freiwillig.

2. Das Interview dient dem folgenden Zweck: Interview für eine Masterarbeit an der

Leibniz Universität Hannover.

3. Verantwortlich für die Durchführung und wissenschaftliche Auswertung des

Interviews ist:

Mandy Weingartner

4. Die Auswertung wird von der Universität im Rahmen der Masterarbeit betreut. Die

Verantwortlichen tragen dafür Sorge, dass alle erhobenen Daten des Interviews streng

vertraulich behandelt werden und ausschließlich zum vereinbarten Zweck verwendet

werden.

5. Der Interviewte erklärt sein Einverständnis mit der Tonbandaufnahme und

wissenschaftlichen Auswertung des Interviews. Nach Ende der Bandaufnahme können

auf seinen Wunsch einzelne Abschnitte des Gesprächs gelöscht werden.

6. Die Tonbandaufnahme wird verschlossen aufbewahrt. Sie ist nur der unter Punkt 3

genannten Person zugänglich.

7. Zu Auswertungszwecken wird von der Aufnahme ein schriftliches Protokoll

angefertigt. Name und Identität des Interviewpartners werden auf dem Protokoll

unkenntlich gemacht und für eventuell spätere Rückfragen gesondert aufbewahrt.

8. Kurze Ausschnitte, aus denen die Person des Interviews nicht identifiziert werden

kann, können aus dem Protokoll in der Masterarbeit / Forschungsarbeit zitiert werden.

Ich kann diese Erklärung jederzeit ganz oder teilweise widerrufen, ohne dass irgendwelche

Nachteile für mich entstehen.

Kontaktadresse für Widerruf:

Mandy Weingartner

Engelbosteler Damm 85

30167 Hannover

Mit oben genannten Punkten erkläre ich mich einverstanden.

Ich habe eine Ausfertigung dieser Erklärung erhalten.

Hannover, den __________________________________________________

Anhang D – Liste der Anforderungen gruppiert nach Themengebieten

- 109 -

Anhang D – Liste der Anforderungen gruppiert nach Themengebieten Dokumentenmanagement

- 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

- digitale Akten sollen angelegt werden können

- Vorlagen sollen verwaltet werden

- Dokumente sollen übersichtlich abgelegt werden

- Dokumente sollen schnell für andere Nutzer bereitgestellt werden können

- Dokumente sollen Nutzern zugeordnet werden können

- Berechtigungen sollen schnell und flexibel verteilt werden können

- Datenschutz soll eingehalten werden

- Dokumente sollen in Sicherheitsstufen eingeordnet werden

- Dokumente sollen vor Angriffen und Datendiebstahl geschützt sein

- Backups sollen automatisch erstellt werden

- eine regelmäßige und automatische Archivierung soll erfolgen

- der Zugang zum Dokumentenarchiv soll einfach sein

- Dokumente sollen automatisch nach Nachfrage gelöscht werden

- bestimmte Dokumente dürfen nicht gelöscht werden können

- Dokumente sollen in flachen Strukturen abgelegt werden

- Dokumente sollen in übersichtlichen Strukturen abgelegt werden

- Dokumente müssen schnell gefunden werden

- Dokumente sollen über eine Suche gefunden werden können

- Dokumente sollen über eine Volltextsuche gefunden werden

- Dokumente sollen über eine Titelsuche gefunden werden können

- Dokumente sollen durch Schlagworte kategorisiert werden

- Dokumente sollen durch eine Schlagwortsuche gefunden werden

- Bibliotheksfavoriten sollen angelegt werden können

- Dokumente sollen auch außerhalb des Unternehmensnetzwerks verfügbar sein

- PDFs sollen im Browser angezeigt werden

- grafische Oberfläche soll ansprechend sein

- einfache und intuitive Bedienung

- doppelte Datensicherung von Dokumenten soll verhindert werden


- 110 -

- Dokumente sollen zu allen Geräten kompatibel sein

- das System soll ein hohes Maß an Automatisierung aufweisen

- Metadaten sollen automatisch erhoben werden

- das System muss kurze Reaktionszeiten haben

- das System muss skalierbar sein

- das System muss eine hohe Verfügbarkeit aufweisen

- das System muss auf allen gängigen Geräten portabel sein

- das System muss auch von unterwegs nutzbar sein

- Schnittstellen zu anderen Systemen müssen zur Verfügung stehen

Kollaboration

- Verfügbarkeit von Wissen

- Verfügbarkeit von Guidelines

- Verfügbarkeit von Produktbeschreibungen

- Verfügbarkeit der besten Verkaufsargumente

- Leitfäden sollen für Mitarbeiter und Kunden bereitgestellt werden

- Anleitungen sollen für Mitarbeiter und Kunden bereitgestellt werden

- E-Mails soll an Inhalten angefügt werden

- Dokumente sollen an Inhalten angefügt werden

- Wissen soll von überall erreichbar sein

- Wissen soll strukturiert sein

- Wissensartikel sollen erstellt werden können

- Wissensartikel sollen einer Wissensdatenbank abgelegt werden

- Wissensartikel sollen ausdruckbar sein

- Wissen soll nicht über die hierarchischen hinaus nach unten verteilt werden

- Dokumente sollen als Wissensartikel abgelegt werden

- Wiki soll dynamisch sein

- Wiki soll einfach zu bedienen sein

- Wiki-Artikel sollen verändert werden können

- Wiki-Artikel sollen über einer Suchfunktion gefunden werden

- Foren in denen auch die Kunden agieren können

- ein öffentlicher Blog soll vorhanden sein

- ein privater Blog soll vorhanden sein

- es soll ein Redaktionssystem für meinen Blog existieren

- Lehrvideos sollen zur Verfügung gestellt werden können

- Instant Messaging soll innerhalb des Unternehmens zur Verfügung stehen

- Mitarbeiter sollen ein Profil haben, damit sie kennengelernt werden können


- 111 -

- Mitarbeiter sollen Skills austauschen können

- Skillprofile sollen in einer Wissensdatenbank abgelegt werden

- Skillprofile sollen nach Themen gegliedert werden

- Skillprofile sollen nach Themen durchsucht werden

- Skillprofile sollen eingesehen werden können

- Dokumente sollen an Skillprofilen angehängt werden

- Ressourcenplanung soll möglich sein (Personal, Werkzeug, Räume)

- Kalender sollen öffentlich sein

- Verfügbarkeit der Mitarbeiter soll sichtbar sein

- Aufgaben sollen öffentlich sein

- Projektmatrizen sollen bereitgestellt werden

- Projekte sollen dokumentiert werden können

- Kollaboration zwischen den Partnerunternehmen

- Kollaboration zwischen den Standorten

- Benachrichtigungen sollen verschickt werden wenn Inhalte angepasst werden

- Berechtigungen sollen auf Wissensdatenbanken vergeben werden können

- Informationen sollen sicher vor Datendiebstahl sein

- das System soll auf allen Geräten kompatibel sein

- Intranet soll damit erstellt werden können

- Inhalte müssen gefunden werden können


- neue Diagramme sollen erzeugt werden können

- vordefinierte Diagramme sollen vorhanden sein

- Diagramme sollen automatisch erstellt werden

- Diagramme sollen angepasst werden können

- konkrete Daten sollen vom Diagramm aus aufgerufen werden

- zentrale Zusammenfassung der Unternehmensdaten soll vorhanden sein

- Buchhaltung soll grafisch dargestellt werden können

- Daten sollen zeitnah erfasst werden können

- Daten sollen auf Korrektheit geprüft werden

- Digitalisierung der Prozesse zur besseren Datensammlung

- Gewinn soll veranschaulicht werden

- Gewinn nach Kundengruppen soll ausgewertet werden

- Ertrag soll veranschaulicht werden

- Produktivität soll veranschaulicht werden

- Deckungsbeitrag soll veranschaulicht werden


- 112 -

- Lagerauslastung soll veranschaulicht werden

- Personalauslastung soll veranschaulicht werden

- Jahresendabschlüsse sollen ausgewertet werden können

- Auslastung der Ressourcen soll veranschaulicht werden

- Ausgaben sollen veranschaulicht werden

- Personalkosten sollen ausgewertet werden können

- Kontakte sollen ausgewertet werden

- Gewinn pro Kontakt soll ausgewertet werden können

- Auswertung welcher Mitarbeiter an welchen Kunden welches Produkt verkauft

- Vertiebstrichterablaufsauswertung soll möglich sein

- Verkaufschancen sollen ausgewertet werden

- Auftragsdaten sollen ausgewertet werden

- Vertriebsdaten sollen ausgewertet werden

- Dienstleistungsdaten sollen ausgewertet werden

- Tagessätze sollen ausgewertet werden

- Zielerreichung soll veranschaulicht werden

- Monatsziele sollen veranschaulicht werden

- Quartalsziele sollen veranschaulicht werden

- Umsatzziele sollen veranschaulicht werden

- der Verlauf der letzten 10 Jahre soll veranschaulicht werden

- eine Vorschau der nächsten 10 Jahre soll erstellt werden können

- das Tool sollte selbsterklärend sein

- das Tool sollte selbsterklärend sein

Geschäftsprozesse

- Einkaufsabwicklung soll unterstützt werden

- Produktion soll abgebildet werden

- Vertriebsweg soll abgebildet werden

- Angebotsphasen sollen abgebildet werden

- Verkaufsabwicklung soll unterstützt werden

- Rechnungsabwicklung soll unterstützt werden

- Reklamationsbearbeitung soll unterstützt werden

- Urlaubsantrag soll abgebildet werden

- Dienstreiseabwicklung soll unterstützt werden

- Beschaffung von Betriebs und Geschäftsausstattung soll unterstützt werden

- Investitionsabwicklung soll unterstützt werden

- Rekrutierungsprozess soll unterstützt werden


- 113 -

- sonstige Genehmigungen sollen abgebildet werden können

- neue Prozessunterstützungen sollen eingebaut werden können

- Prozessunterstützung soll anpassbar sein

- Budget soll abgebildet werden

- Hinweismails sollen generiert werden

- Erinnerungsmails sollen verschickt werden können

- Dateileichen sollen gemeldet werden

- Schnittstellen zu anderen Systemen müssen zur Verfügung stehen

Projektmanagement

- Projektübersicht soll erstellt werden können

- Projektstatus soll gesehen werden

- Projektaufgabenstatus soll gesehen werden

- Projektverantwortlicher soll gesehen werden

- Projektaufgabenverantwortlicher soll gesehen werden

- Projektablaufpläne sollen erstellt werden können

- Teilprojekte sollen definiert werden können

- Meilensteine sollen definiert werden können

- Fälligkeitsdaten sollen definiert werden können

- Erinnerungen sollen eingestellt werden können

- Kommunikation mit Dritten soll geplant werden können

- Ist-Zustand soll definiert werden können

- Soll-Zustand soll definiert werden können

- Ressourcen sollen verplant werden können

- Projektbudgetverwaltung soll abgebildet sein

- Kostenstellen sollen abgebildet werden können

- Änderungen des Projektplans sollen nachvollziehbar sein

- ToDo-Listen sollen erstellt werden

- es soll mit Tickets gearbeitet werden können

- Mit dem Projekt soll auch die Arbeitszeit verwaltet werden

- Telefonate sollen automatisch in der Arbeitszeitverwaltung auftauchen um diese

einem Projekt zuzuordnen

- Leitstrahl soll visualisiert werden

- GANTH soll erstellt werden können

- ITIL soll unterstützt werden

- Dokumente sollen abgelegt werden können

- Zugriffe sollen beschränkt werden


- 114 -

- System soll an die Projektgröße anpassbar sein

Anhang E – Tripel der Funktionsontologie

- 115 -


Funktion Subjekt Prädikat Objekt

Allgemein

Erweiterung durch Apps

bzw. Solutions möglich

App kann_erweitern SharePoint,

Dynamics CRM

Manübänder Menüband ist_vorhanden_in SharePoint,

Dynamics CRM

Erweiterung von

Menübändern

Menüband kann_erweitert_werden_in SharePoint,

Dynamics CRM

Präsentationsansicht Präsentationsansicht ist_vorhanden_in SharePoint,

Dynamics CRM

Mobile Nutzung Mobile_Nutzung ist_möglich_durch SharePoint,

Dynamics CRM

Content Management

Listen von Elementen Listenelement kann_erstellt_werden_in SharePoint,

Dynamics CRM

Anfügen von Anhängen zu

Elementen

Elementanhang kann_hochgeladen_werden

_in

SharePoint,

Dynamics CRM

Suchen von Elementen Elemente kann_gesucht_werden_in SharePoint,

Dynamics CRM

Versionierung von

Elementen

Element kann_versioniert_werden_i

n

SharePoint,

Dynamics CRM

Anpassen von Listen Liste kann_angepasst_werden_in SharePoint,

Dynamics CRM

Hinzufügen von Listen Liste kann_erstellt_werden_in SharePoint,

Dynamics CRM

Löschen von Listen Liste kann_gelöscht_werden_in SharePoint,

Dynamics CRM

Vorlagen für Listen sind

vorhanden

Listenvorlage ist_vorhanden_in SharePoint

Anpassen von Ansichten Ansicht kann_angepasst_werden_in SharePoint,

Dynamics CRM

Hinzufügen von Ansichten Ansicht kann_erstellt_werden_in SharePoint,

Dynamics CRM

Löschen von Ansichten Ansicht kann_gelöscht_werden_in SharePoint,

Dynamics CRM


- 116 -

Personalisierung von

Ansichten

Ansicht kann_personalisiert_werde

n_in

SharePoint,

Dynamics CRM

Vorlagen für Ansichten

sind vorhanden

Ansichtenvorlage ist_vorhanden_in SharePoint,

Dynamics CRM

Anpassen von Feldern Feld kann_anpasst_werden_in SharePoint,

Dynamics CRM

Hinzufügen von Feldern Feld kann_erstellt_werden_in SharePoint,

Dynamics CRM

Löschen von Feldern Feld kann_gelöscht_werden_in SharePoint,

Dynamics CRM

Anpassen von Formularen Formular kann_anpasst_werden_in SharePoint,

Dynamics CRM

Hinzufügen von

Formularen

Formular kann_erstellt_werden_in SharePoint,

Dynamics CRM

Löschen von Formularen Formular kann_gelöscht_werden_in SharePoint,

Dynamics CRM

Anpassen von Websites Website kann_anpasst_werden_in SharePoint

Erstellen von öffentlichen

Websites

Öffentliche_Website kann_erstellt_werden_in SharePoint

Erstellen von

semiöffentlichen Websites

Semiöffentliche_We

bsite

kann_erstellt_werden_in SharePoint

Erstellen von privaten

Websites

Private_Website kann_erstellt_werden_in SharePoint

Löschen von Websites Website kann_gelöscht_werden_in SharePoint

Personalisierung von

Websites

Website kann_personalisiert_werde

n_in

SharePoint

Vorlagen für Websites sind

vorhanden

Websitevorlage ist_vorhanden_in SharePoint

Einbinden von

Webressourcen

Webressource kann_eingebunden_werden

_in

SharePoint,

Dynamics CRM

Systemweite Suche Systemweite_Suche ist_vorhanden_in SharePoint

Webinhaltsdienste zur

Veröffentlichung von

Inhalten

Webinhaltsdienst ist_vorhanden_in SharePoint

Web Content Management Web_Content_Mana

gement

ist_vorhanden_in SharePoint


Erstellen von Bibliotheken Bibliothek kann_erstellt_werden_in SharePoint


- 117 -

Anpassen von Bibliotheken Bibliothek kann_anpasst_werden_in SharePoint

Löschen von Bibliotheken Bibliothek kann_gelöscht_ werden_in SharePoint

Bibliotheken für

Officedokumente

Office_Dokumenten

_Bibliothek


Bibliotheken für Bilder Bilderbibliothek ist_vorhanden_in SharePoint

Bibliotheken für Berichte

(Excel-Tabellen,

Dashboards und KPI)

Berichtebibliothek ist_vorhanden_in SharePoint

Bibliotheken für Videos Videobibliothek ist_vorhanden_in SharePoint

Bibliotheken für Sounds Soundbibliothek ist_vorhanden_in SharePoint

Bibliotheken für Visio-

Zeichnungen

Visiobibliothek ist_vorhanden_in SharePoint

Bibliotheken für sonstige

Dateien

Dateibibliothek ist_vorhanden_in SharePoint

Vorlagen für Bibliotheken Bibliotheksvorlage ist_vorhanden_in SharePoint

Vorlagenmanagement für

Dokumente

Dokumentenvorlage

management


Zentrales

Dokumentencenter

Dokumentencenter ist_vorhanden_in SharePoint

Ein- und Auschecken von

Dokumenten

Dokument kann_gesperrt_werden_in SharePoint

Suchen nach Dokumenten Dokumentensuche ist_vorhanden_in SharePoint

Inhaltssuche in

Dokumenten

Inhaltssuche ist_vorhanden_in SharePoint

Versionierung von

Dokumenten

Dokument kann_versioniert_werden SharePoint

Verwaltung von

Informationsverwaltungsric

htlinien

Informationsverwaltu

ngsrichtlinien


Einbinden eines Fileservers

zur Dateiverwaltung

Fileserver kann_eingebunden_werden

_in

SharePoint

Kollaboration

Aufgabenmanagement Augabenmanagemen

t

ist_vorhanden_in SharePoint,

Dynamics CRM

persönliche

Aufgabensammlung

Persönliche_Aufgabe

nsammlung

ist_vorhanden_in SharePoint,

Dynamics CRM


- 118 -

Vorlage für Listen mit

Problemen und offenen

Punkten

Problemlistenvorlage ist_vorhanden_in SharePoint,

Dynamics CRM

Vorlage für

Pojektaufgabenliste

Projektaufgabenliste

nvorlage


Vorlage für

Projektwebsites

Projektwebsitevorlag

e


Vorlagen für

Ankündigungslisten

Ankündigungslistenv

orlage


Vorlagen für Kontaktlisten Kontaktlistenvorlage ist_vorhanden_in SharePoint,

Dynamics CRM

Vorlagen für Linklisten Linklistenvorlage ist_vorhanden_in SharePoint

Vorlagen für Teamwebsites Teamwebsitevorlage ist_vorhanden_in SharePoint

Newsfeed Newsfeed ist_vorhanden_in SharePoint

Persönlicher Bereich mit

eigenem Newsfeed

Persönlicher_Bereich ist_vorhanden_in SharePoint

eigene Profilwebsite Profilwebite ist_vorhanden_in SharePoint

Folgen von Datensätzen Datensatz kann_gefolgt_werden_in SharePoint,

Dynamics CRM

Folgen von Benutzern Benutzer kann_gefolgt_werden_in SharePoint

Folgen von Websites Website kann_gefolgt_werden_in SharePoint

Folgen von Listen Liste kann_gefolgt_werden_in SharePoint

Folgen von Bibliotheken Bibliothek kann_gefolgt_werden_in SharePoint

Liste mit Wissensartikeln Wisensartikelliste ist_vorhanden_in SharePoint,

Dynamics CRM

Wiki Wiki ist_vorhanden_in SharePoint

Vorlage zur Organisation

von

Produktbeschreibungen

Produktbeschreibung

slistenvorlage

ist_vorhanden_in Dynamics CRM

Vorlage zur Organisation

von

Dienstleistungsbeschreibun

gen

Dienstleistungsbesch

reibungslistenvorlage


Blog Blog ist_vorhanden_in SharePoint

Forum Forum ist_vorhanden_in SharePoint

Erstellen von Umfragen Umfragen kann_erstellt_werden_in SharePoint

Durchführen von

Umfragen

Umfragen kann_durchgeführt_werden

_in

SharePoint


- 119 -

Integration sozialer

Netzwerke

Soziale_Netzwerke ist_vorhanden_in SharePoint

Kalender Kalender ist_vorhanden_in SharePoint,

Dynamics CRM

Synchronisation mit dem

Outlookkalender

Outlooksynchronisati

on

kann_synchronisiert_in SharePoint,

Dynamics CRM

Referenzieren von Mails

aus Outlook

Mails kann_referenziert_werden_

in

Dynamics CRM

Geschäftsprozesse

Erstellung von Workflows Workflow ist_vorhanden_in SharePoint,

Dynamics CRM

Generierung von Objekten Objekt kann_automatisch_erzeugt_

werden_in

SharePoint,

Dynamics CRM

berechnen von Werten in

Formularen

Feldwert kann_berechnet_werden_in SharePoint,

Dynamics CRM

automatischer Versand von

E-Mails

Mail kann_automatisch_versend

et_werden_in

SharePoint,

Dynamics CRM

kontrollieren von falschen

Eingabewerten

Falscheingabe kann_erkannt_werden_in SharePoint,

Dynamics CRM

Prozessunterstützung durch

Dialoge

Dialog ist_vorhanden_in Dynamics CRM

Prozessunterstützung durch

Schritt-für-Schritt-

Anleitungen

ProcessFlow ist_vorhanden_in Dynamics CRM

Vorlage für

Kundenverwaltung

Kundenverwaltung ist_vorhanden_in Dynamics CRM

Vorlage für

Ressourcenverwaltung

Ressourcenverwaltun

g


Vorlage für

Auftragsabwicklung

Aiftragsabwicklung ist_vorhanden_in Dynamics CRM

Vorlage für

Bestellabwicklung

Bestellabwicklung ist_vorhanden_in Dynamics CRM

Vorlage für

Rechnungsverwaltung

Rechnungsverwaltun

g


Vorlage für statische

Marketinglisten

Statische_Marketingl

iste


Vorlage für dynamische

Marketinglisten

Dznamische_Marketi

ngliste



- 120 -

Vorlage für

Kampagnenverwaltung

Kampagnenverwaltu

ng


Vorlage für

Konkurrentenverwaltung

Konkurrentenverwalt

ung


Produktkatalogsvorlage Produktkatalogsvorla

ge


Export in Excel Excel_Export ist_vorhanden_in SharePoint,

Dynamics CRM

Import aus CSV CSV_Import ist_vorhanden_in SharePoint,

Dynamics CRM


Verknüpfung beliebiger

Daten

Daten können_miteinander_verkn

üpft_werden_in

Dynamics CRM

Generierung von Reports Report kann_generiert_werden_in Dynamics CRM

Generierung von

Diagrammen

Diagramm kann_generiert_werden_in SharePoint,

Dynamics CRM

Vorlagen für Dashboards Dashboard kann_generiert_werden_in SharePoint,

Dynamics CRM

Ziele definieren Ziel kann_definiert_werden_in SharePoint,

Dynamics CRM

Übergeordnete Ziele

definieren

Übergeordnetes_Ziel kann_definiert_werden_in Dynamics CRM

Teamziele definieren Teamziel kann_definiert_werden_in Dynamics CRM

Ziele kontrollieren Zielerreichung kann_kontrolliert_werden_i

n

SharePoint,

Dynamics CRM

Anhang F – Codes zur Theoriegenerierung

- 121 -

Anhang F – Codes zur Theoriegenerierung Dokumentenmanagement

DM: IT und Unternehmensleitung können sich nicht auf ein Produkt einigen

DM: das Dokumentenkonzept ist nicht durchdacht

DM: der Nutzen ist den Unternehmern nicht bewusst

DM: die Nutzer wollen ihre Arbeitsweisen nicht ändern

DM: Bibliotheken werden nach der Einführung nicht mehr gepflegt

DM: Fileserver werden parallel betrieben

DM: es werden zu viele Systeme eingesetzt in denen Dokumente abgelegt werden können

DM: zu viele Regeln schrecken ab

DM: Funktionen eines DMS werden nicht genutzt (langsamer Fileserver)

DM: die Chancen eines DMS werden nicht gesehen

DM: das System verlangt beim Hochladen einer Datei nach zu vielen Pflichtmetadaten

DM: es wird keine Beratung auf der Geschäftsebene eingeholt

DM: das System reagiert zu langsam

DM: klare Strukturen

DM: klare Begrifflichkeiten

DM: Schnittstellen zu anderen Systemen

Kollaboration

K: es herrscht kein kollektives Bewusstsein

K: Wikis müssen gepflegt werden

K: verschiedene Abteilungen wollen nicht zusammenarbeiten

K: es gibt zu viele Regeln für das Social Network

K: Nutzer sind nicht an die privaten Tätigkeiten anderer Nutzer interessiert

K: Informationen werden über Mail verteilt

K: Nutzung der CRM-Wissendatenbank ist sehr umständlich

K: IT-Abteilung hängt hinterher die privaten Gewohnheiten der Mitarbeiter zu nutzen

K: Nutzen ist für den Unternehmer nicht klar

K: es wird nicht gezeigt, wie ein Unternehmen von Social Media profitieren kann

K: Informationen werden an zu vielen verschiedenen Stellen veröffentlicht

K: es ist nicht bekannt, dass es ein Wiki gibt

K: Es gibt niemanden der das Wissen Pflegt

K: Wissen ist nicht aktuell

K: die Umsetzung wird zu technisch betrachtet

K: die organisatorische Betrachtung ist zu Zeitaufwändig

K: es gibt nur wenige Motivierte Nutzer

K: motivierte Nutzer verlieren die Motivation, weil niemand mit macht

K: organisatorische Einbettung fehlt

K: es wurde nur ein Workshop mit Führungspersonen zur Anforderungsanalyse gemacht

K: die Systeme wurden nicht ausreichend angepasst

K: Nutzer wurden bei der Anforderungserhebung nicht berücksichtigt

Anhang G – Kausalketten der Benutzerakzeptanz

- 122 -

K: Nutzer wurde nicht mit involviert bei der Einführung

K: IT-Abteilung hat nach eigenem Gefühl agiert und nicht nach den Nutzern

K: es wird nicht auch die Prozesse und Nutzer eingegangen

K: Arbeit wird als Mittel zum Zweck verstanden

K: es gibt zu viele Systeme

Business intelligence

BI: zu hoher Aufwand der Datenerfassung

BI: die Datenaufnahme geschieht nicht immer automatisch

BI: Anbieter brechen die Software auf KMU runter

BI: Software wird als Werkzeug zum Probleme lösen verstanden

BI: Prozesse müssen dokumentiert und bewusst sein, um die Auswertungen nutzen zu können

BI: Daten müssen aus vielen Quellen zusammengetragen werden

Geschäftsprozesse

GP: die Geschäftsprozesse sind unbekannt

GP: die Geschäftsprozesse wurden vor der Implementierung nicht komplett aufgenommen

GP: Geschäftsprozesse sind nicht definiert

GP: Nutzer zweifeln die Geschäftsprozesse an

GP: Nutzer werden dadurch gebremst

GP: Software wurde nicht genügend angepasst

GP: zu geringe Betreuung und Anpassungen nach der Umsetzung

GP: nur Unternehmensführung und IT-Abteilung sind bei der Umsetzung beteiligt


- 123 -


Entwicklung eines Einführungsplans für SharePoint und CRM ... · Zusammenfassung - 3 -...

Documents

Transcript of Entwicklung eines Einführungsplans für SharePoint und CRM ... · Zusammenfassung - 3 -...