entwicklung eines einführungsplans für sharepoint und crm ... · zusammenfassung - 3 -...
Post on 25-Aug-2019
214 Views
Preview:
TRANSCRIPT
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 -
Abbildungsverzeichnis
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 -
Abbildungsverzeichnis
- 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
(vgl. Schmidt, 2013, S. 38ff)
Auch für die Websites bietet SharePoint Vorlagen an, die bereits eine Vorauswahl an Listen
und Bibliotheken bereitstellen. (vgl. Tabelle 3.3) Jede Website kann individuell angepasst
werden, indem Listen oder Bibliotheken entfernt, hinzugefügt oder bearbeitet werden.
Tabelle 3.3: SharePoint Websitevorlagen
Vorlagen 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
(vgl. Schmidt, 2013, S. 45ff)
Reichen die Funktionalitäten der gewählten Listen, Bibliotheken oder Websites nicht aus,
können diese vollständig angepasst werden, wenn der Benutzer die nötigen Rechte dafür
besitzt. Aus angepassten Bibliotheken, Listen oder Websites können Vorlagen erstellt werden.
Vorlagen können, laut Melanie Schmidt, nicht ohne Programmieraufwand bearbeitet werden.
(vgl. Schmidt, 2013, S. 257)
Microsoft hat die FAST-Search aufgekauft und SharePoint mit dieser umfassenden Such-
Engine erweitert. Dadurch kann in SharePoint ein unternehmensweites Suchcenter aufgebaut
werden, welches neben SharePoint-Inhalten auch Websites und Dateifreigaben eines Servers
durchsuchen kann. (vgl. Larisch, 2013, S. 303) Da die FAST-Search kein Kernthema dieser
Arbeit ist, wird auf weiterführende 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
Zielgruppenanalyse und Anforderungserhebung
- 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:
RQ6: Warum ist die Benutzerakzeptanz dieser Systeme so gering?
Das zweite und letzte Sampling wurde durch Consultants erweitert. Es ergaben sich 5 neue
Interviewsituationen mit folgenden Befragten:
- Zwei Consultants für kleine Unternehmen mit weniger als 100 Beschäftigten und mit
dem Schwerpunkt auf Infrastrukturbereitstellung.
- Ein Consultant für größere Unternehmen ab 100 Beschäftigten und mit dem
Schwerpunkt auf Bereitstellung von Unternehmenssoftware.
- Ein Teamleiter, welcher als Vertriebler und Consultant tätig ist. Er betreut große
Unternehmen ab 100 Beschäftigten bei der Auswahl und Bereitstellung von
Unternehmenssoftware.
- Ein Vertriebler für kleine Unternehmen mit weniger als 100 Beschäftigten.
- Ein Vertriebler für größere Unternehmen mit mehr als 100 Beschäftigten.
Der Leitfaden wurde bezüglich der hinzugefügten Forschungsfrage erweitert und an das neue
Sampling angepasst.
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)
Zielgruppenanalyse und Anforderungserhebung
- 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.
Zielgruppenanalyse und Anforderungserhebung
- 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.
Zielgruppenanalyse und Anforderungserhebung
- 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
Zielgruppenanalyse und Anforderungserhebung
- 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.
Erstellung des Anforderungskatalogs
- 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.
Erstellung des Anforderungskatalogs
- 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.
Erstellung des Anforderungskatalogs
- 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.
Erstellung des Anforderungskatalogs
- 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.
Erstellung des Anforderungskatalogs
- 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.
Erstellung des Anforderungskatalogs
- 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
Erstellung des Anforderungskatalogs
- 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.
Erstellung des Anforderungskatalogs
- 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
Erstellung des Anforderungskatalogs
- 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:
RQ6: Warum ist die Benutzerakzeptanz dieser Systeme so gering?
6.1 Auswahl der Methode
Zwei bekannte Methoden zur Theoriegenerierung sind Grounded Theory und heuristische
Sozialforschung an. Beide basieren unter anderem auf die Nutzung der durch Interviews
erhobenen Daten zur Theoriegenerierung.
In der Grounded Theory werden Transkripte codiert und kategorisiert und es werden Memos
geschrieben, welche bei dem weiteren Verlauf der Interviews und Auswertungen helfen.
Durch mehrere Zyklen wird die Theorie immer weiter verfeinert, bis keine neuen
themenrelevanten Daten erhoben werden können.
Die heuristische Sozialforschung richtet sich nach Fragen, wodurch neue Bereiche des
Forschungsgebiets erschlossen und weitere Interviews geführt werden. In der Datenerhebung
soll ein möglichst breites Feld genutzt werden. Die erhobenen Daten werden nicht codiert,
sondern es wird versucht Fragen zu beantworten, um eine Theorie zu generieren.
Die Auswertung der Interviews soll in diesem Fall nach Grounded Theory erfolgen, da die
Fragen der heuristischen Sozialforschung das Risiko beinhalten, sich zu sehr auf detaillierte
Fragen zu beziehen und dadurch den Fokus auf die Forschungsfragen zu verlieren.
6.2 Vorgehen nach Grounded Theory Durch die vorherige Zusammenfassung der Transkripte wurde folgende relevante 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.
Erstellung des Projektplans
- 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.
Erstellung des Projektplans
- 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
(vgl. Plass, Rehmann, Zimmermann, Janssen, & Wibbing, 2013 S.122ff)
Das Kernteam ist für die technische Einführung des Systems zuständig. Es bereitet die
Hardware auf, installiert die Systeme und passt diese den Anforderungen an. Das Team
besteht aus Mitarbeitern des zur Einführung des Systems bestimmten Unternehmens und des
Systemanbieters.
Die Key User sind die Vertreter des Fachbereichs und stellen sicher, dass die Anforderungen
an das neue System umgesetzt werden. Dazu erfüllen sie folgende Aufgaben:
- Fachliche Unterstützung des Customizings
- Mitarbeit bei der Erstellung der Benutzungsdokumentation
- Erarbeiten von Testfällen
- Unterweisen der Benutzer in das neue System
(vgl. Plass, Rehmann, Zimmermann, Janssen, & Wibbing, 2013 S.122ff)
Zur Gewährleistung der Erfüllung dieser Aufgaben kann hier nach der Entwicklungsmethode
On-Site Customer gearbeitet werden. Dies beschreibt eine agile Methode, bei der ein Vertreter
des auftraggebenden Unternehmens ein Teil des Entwicklungsteams ist und für Fragen
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.
Erstellung des Projektplans
- 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
Erstellung des Projektplans
- 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.
Erstellung des Projektplans
- 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
KonzeptionBereitstellung/
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
Erstellung des Projektplans
- 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.
Erstellung des Projektplans
- 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
Erstellung des Projektplans
- 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
Erstellung des Projektplans
- 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)
Erstellung des Projektplans
- 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
(Felkai & Beiderwieden, 2013 S.234)
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.
Erstellung des Projektplans
- 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
(Felkai & Beiderwieden, 2013 S.242)
31 U.a. Hard- und Software
Erstellung des Projektplans
- 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
KonzeptionBereitstellung/
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 -
Literaturverzeichnis
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.
Literaturverzeichnis
- 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.
Literaturverzeichnis
- 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 -
Anhang A – Charakterisierung von Klein-, Mittel- und Großbetrieben
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
klein bis 9 bis 500.000 €
mittel 10 – 199 500.000 -25 Mio. €
groß 200 und mehr 25 Mio. € und mehr
Einzelhandel
klein bis 2 bis 250.000 €
mittel 3 – 49 250.000 – 5 Mio. €
groß 50 und mehr 5 Mio. € und mehr
Verkehr und Nachrichtenübermittlung
klein bis 2 bis 50.000 €
mittel 3 – 49 50.000 -1 Mio. €
groß 50 und mehr 1 Mio. € und mehr
Dienstleistungen von Unternehmen und freien Berufen
klein bis 2 bis 50.000 €
mittel 3 – 49 50.00 – 1 Mio. €
groß 50 und mehr 1 Mio. € und mehr
(Pfohl, 2013, S. 10)
Unternehmensführung
Klein- und Mittelbetriebe Großbetriebe
Anhang A – Charakterisierung von Klein-, Mittel- und Großbetrieben
- 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
Klein- und Mittelbetriebe Großbetriebe
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
Anhang A – Charakterisierung von Klein-, Mittel- und Großbetrieben
- 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
Klein- und Mittelbetriebe Großbetriebe
schwache Position am Beschaffungsmarkt starke Position am Beschaffungsmarkt
häufig auftragsbezogene Materialbeschaffung überwiegend auftragsunabhängige
Materialbeschaffung, abgesichert durch
langfristige Verträge mit Lieferanten
Produktion
Klein- und Mittelbetriebe Großbetriebe
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
Klein- und Mittelbetriebe Großbetriebe
Anhang A – Charakterisierung von Klein-, Mittel- und Großbetrieben
- 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
Klein- und Mittelbetriebe Großbetriebe
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
Klein- und Mittelbetriebe Großbetriebe
keine dauernd institutionalisierte Forschungs- und
Entwicklungsabteilung
dauernd institutionalisierte Forschungs- und
Entwicklungsabteilung
kurzfristig-intuitiv ausgerichtete Forschung und
Entwicklung
langfristig-systematisch angelegte Forschung und
Entwicklung
Anhang A – Charakterisierung von Klein-, Mittel- und Großbetrieben
- 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
Klein- und Mittelbetriebe Großbetriebe
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 -
Anhang B – Funktionsliste
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
Anhang B – Funktionsliste
- 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
Dokumentenmanagement
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
Anhang B – Funktionsliste
- 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
Anhang B – Funktionsliste
- 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
Anhang B – Funktionsliste
- 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
Business Intelligence
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 -
Anhang C – Interviewdokumente
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?
Dokumentenmanagement
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?
Business Intelligence
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?
Anhang C – Interviewdokumente
- 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
Anhang D – Liste der Anforderungen gruppiert nach Themengebieten
- 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
Anhang D – Liste der Anforderungen gruppiert nach Themengebieten
- 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
Business Intelligence
- 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
Anhang D – Liste der Anforderungen gruppiert nach Themengebieten
- 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
Anhang D – Liste der Anforderungen gruppiert nach Themengebieten
- 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
Anhang D – Liste der Anforderungen gruppiert nach Themengebieten
- 114 -
- System soll an die Projektgröße anpassbar sein
Anhang E – Tripel der Funktionsontologie
- 115 -
Anhang E – Tripel der Funktionsontologie
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
Anhang E – Tripel der Funktionsontologie
- 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
Dokumentenmanagement
Erstellen von Bibliotheken Bibliothek kann_erstellt_werden_in SharePoint
Anhang E – Tripel der Funktionsontologie
- 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
ist_vorhanden_in SharePoint
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
ist_vorhanden_in SharePoint
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
ist_vorhanden_in SharePoint
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
Anhang E – Tripel der Funktionsontologie
- 118 -
Vorlage für Listen mit
Problemen und offenen
Punkten
Problemlistenvorlage ist_vorhanden_in SharePoint,
Dynamics CRM
Vorlage für
Pojektaufgabenliste
Projektaufgabenliste
nvorlage
ist_vorhanden_in SharePoint
Vorlage für
Projektwebsites
Projektwebsitevorlag
e
ist_vorhanden_in SharePoint
Vorlagen für
Ankündigungslisten
Ankündigungslistenv
orlage
ist_vorhanden_in SharePoint
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
ist_vorhanden_in Dynamics CRM
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
Anhang E – Tripel der Funktionsontologie
- 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
ist_vorhanden_in Dynamics CRM
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
ist_vorhanden_in Dynamics CRM
Vorlage für statische
Marketinglisten
Statische_Marketingl
iste
ist_vorhanden_in Dynamics CRM
Vorlage für dynamische
Marketinglisten
Dznamische_Marketi
ngliste
ist_vorhanden_in Dynamics CRM
Anhang E – Tripel der Funktionsontologie
- 120 -
Vorlage für
Kampagnenverwaltung
Kampagnenverwaltu
ng
ist_vorhanden_in Dynamics CRM
Vorlage für
Konkurrentenverwaltung
Konkurrentenverwalt
ung
ist_vorhanden_in Dynamics CRM
Produktkatalogsvorlage Produktkatalogsvorla
ge
ist_vorhanden_in Dynamics CRM
Export in Excel Excel_Export ist_vorhanden_in SharePoint,
Dynamics CRM
Import aus CSV CSV_Import ist_vorhanden_in SharePoint,
Dynamics CRM
Business Intelligence
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
top related