Einführung von Microsoft Sharepoint Portal Server als zentrale Informationsplattform

Inhaltsverzeichnis

Anmerkungen

Verzeichnis der Abkürzungen und Akronyme

Abbildungsverzeichnis

1 Einleitung
1.1 Motivation und Zielsetzung
1.2 Das Unternehmen

2 Grundlagen
2.1 Microsoft Sharepoint
2.1.1 Microsoft Windows Sharepoint Services
2.1.2 Microsoft Sharepoint Portal Server
2.2 Systementwicklung
2.2.1 Analyse-Phase
2.2.2 Entwurf und Realisierung
2.2.3 Systemeinführung
2.3 Wirtschaftlichkeitsanalyse

3 Entwicklung eines Fachkonzepts
3.1 Ist-Zustand des Unternehmens
3.1.1 Situation in der Supportdienstleistungsabteilung
3.1.2 Situation in der Qualitätsunterstützungsgruppe
3.2 Sollzustand
3.2.1 Sollzustand aus Sicht der SDA-Leitung
3.2.2 Soll-Zustand aus Sicht der QUG

4 Realisierung und Einführung
4.1 Der Abteilungsbereich
4.2 Der Arbeitsbereich der QUG
4.3 Einführung und Schulungen

5 Analyse der Zielerreichung
5.1 Ergebnisbetrachtung
5.2 Wirtschaftlichkeitsanalyse

6 Kritische Würdigung und Ausblick
A Vorgehensmodell zur Einführung von Standardsoftware
B Anforderungen der SDA-Leitung an das neue einzuführende System
C Anforderungen der QUG an das neue einzuführende System

Literaturverzeichnis

Anmerkungen

Es gibt Benutzerinnen und Benutzer, Administratorinnen und Administratoren, Mitarbeiterinnen und Mitarbeiter etc.. Wenn in dieser Arbeit weitestgehend auf die Femenin-Endungen „in“ und „-innen“ verzichtet wird, dann nur, weil eine konsequente orthographisch korrekte Umsetzung dieser Schreibweise zu Satzungeheuern, größerer Seitenzahl und schlechterer Lesbarkeit führen würde, ohne dabei ein Mehr an Wissen zu liefern.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen etc. in dieser Arbeit berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- oder Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen.

Verzeichnis der Abkürzungen und Akronyme

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 2-1: Logische Struktur von Server und Sites

Abb. 2-2: Vorgehensmodell bei der Systementwicklung

Abb. 4-1: Struktur von SPS und verwendeten Teamsites in der Realisierung

Abb. 5-1: Amortisationszeit in Abhängigkeit der jährlichen Serverkosten

Abb. A.1: Phasen zur Einführung von Standardsoftware

Abb. B.1: UML Use-Case-Diagramm der Anforderungen der SDA-Leitung

Abb. C.1: UML Use-Case-Diagramm der Anforderungen der QUG

1 Einleitung

Die Bedeutung der Informations- und Kommunikationstechnologie hat in den vergangenen Jahren stark zugenommen. Dienten Computer in den Anfängen der Entwicklung eher als Hilfsmittel für einfache, standardisierte Aufgaben wie z.B. die Buchführung, sind sie mittlerweile aus kaum einem Unternehmensbereich mehr wegzudenken. Im Dienstleistungssektor sind in der Bundesrepublik Deutschland nach offiziellen Erhebungen mittlerweile ca. 84% der Arbeitsplätze mit Computern ausgestattet – mit steigender Tendenz.^[1]

Dabei wird die Informationsinfrastruktur jedoch nicht immer von vornherein detailliert geplant und fortwährend der Struktur und den Aufgaben eines Unternehmens angepasst. Häufig werden aus einem akuten Bedarf heraus kurzfristig neue Anwendungssysteme beschafft oder selbst realisiert, ohne dass diese in die vorhandene Informationsinfrastruktur eingegliedert oder integriert werden. Für den einzelnen Anwender kann dies zur Folge haben, dass er einen beträchtlichen Teil seiner Arbeitszeit dafür aufwenden muss, die für seine Arbeit benötigten Informationen aus mehreren Systemen zusammenzusuchen. Auch die Einführung eines Enterprise-Ressource-Planning-Systems kommt dabei für viele Unternehmen aufgrund der meist hohen Kosten nicht in Frage. Große Standardsoftwarehersteller haben diesen Bedarf erkannt und bieten mittlerweile diverse Produkte zur Zentralisierung von Informationen und Arbeitsplattformen für Teams an, die den Informationsfluss zu bessern versprechen. Eines dieser Produkte ist die Sharepoint-Technologie aus dem Hause Microsoft.

1.1 Motivation und Zielsetzung

Hat sich ein Unternehmen erst einmal für die Einführung eines entsprechenden Anwendungssystems zur Unterstützung seiner Mitarbeiter entschieden, stellt sich die Frage nach der Umsetzung. Kaum ein Unternehmen stellt nach einem erfolgreichen oder missglückten IT-Projekt seine Erfahrungen der Öffentlichkeit zur Verfügung – entweder, um einen Wissensvorsprung vor den Mitbewerbern zu halten oder um das Image des Unternehmens in der Öffentlichkeit nicht zu beeinträchtigen. Somit existieren bislang außer oberflächlichen Informationen der Hersteller kaum öffentlich zugängliche Studien und jedes Unternehmen ist gezwungen, wieder bei Null anzufangen und die Umsetzung seinen IT-Fachkräften anzuvertrauen. Die vorliegende Studienarbeit soll einen Beitrag dazu leisten, aufzuzeigen, wie anhand ingenieurswissenschaftlicher Methoden die Microsoft Sharepoint-Technologie im Unternehmensalltag eingeführt und wirtschaftlich eingesetzt werden kann.

1.2 Das Unternehmen

Das betrachtete Beispielunternehmen ist mit über 500 Angestellten und Praktikanten nach eigenen Angaben mittlerweile zu einem der führenden Softwaredienstleister in der Volksrepublik China geworden. Neben Dienstleistungen in anderen Bereichen liegt sein Kerngeschäft mit seiner Supportdienstleistungsabteilung auf dem telefonischen Support für die Produkte eines namhaften Softwareherstellers für die Volksrepublik China und den Online-Support für dessen USA-Geschäft. Darüber hinaus werden auch verschiedene Support-Dienstleistungen für namhafte Unternehmen aus verschiedenen anderen Branchen betrieben.

Aufgrund des großen Firmenerfolges innerhalb der letzten Jahre ist das Unternehmen stark gewachsen. Davon war besonders die Supportdienstleistungsabteilung betroffen. Neue Verträge mit weiteren Partnern wurden geschlossen und Aufgaben der bestehenden Struktur angegliedert. Wie in der Praxis häufig vorkommend, war die ursprüngliche Organisationsstruktur jedoch nicht für größeres Wachstum ausgelegt. Auch die IT-Infrastruktur hatte sich zu einem bunten Flickenteppich an eingesetzter Anwendungssoftware und Arbeitsweisen entwickelt, viele Aufgaben und Prozesse wurden in Ermangelung bequemerer Vorgehensweisen durch „Workarounds“, also durch provisorische Verfahrensweisen, irgendwie gelöst. Gerade neue Mitarbeiter taten sich schwer, alle Informationsquellen im Gedächtnis zu behalten und zu nutzen. Dies hatte nicht selten zur Folge, dass ein Mitarbeiter manchmal erst nach Wochen in einem zufälligen Gespräch mit einem Kollegen eine Informationsquelle oder ein Anwendungssystem entdeckte, welches seine tägliche Arbeit nicht unerheblich unterstützen konnte.

Diese Probleme waren seit längerem auch der Abteilungsleitung bekannt. Sie beschloss daher, eine abteilungsinterne Kommunikations- und Arbeitsplattform mittels der Microsoft Sharepoint-Technologie, die als geeignet und flexibel genug angesehen wurde, einzuführen.

Die vorliegende Ausarbeitung bietet ein Praxisbeispiel eines Einführungsprozesses in der Supportdienstleistungsabteilung dieses Unternehmens.

2 Grundlagen

Vor der weiteren Erörterung des Themas soll zunächst das eingesetzte Produkt vorgestellt und theoretische Grundlagen gelegt werden, um dem Leser die späteren Schritte bei der Auswahl der Komponenten nachvollziehbar zu machen.

2.1 Microsoft Sharepoint

Bereits seit 2001 engagiert sich Microsoft mit seinen beiden Sharepoint Produkten (Windows Sharepoint Team Services und Sharepoint Portal Server 2001) im Markt der „integrierten Arbeitsumgebungen“ für Teams in Unternehmen. Während der Sharepoint Portal Server 2001 sich jedoch eher als verbessertes Dokumentenmanagementsystem präsentierte^[2] und damit die Fachwelt irritierte^[3], stellt sich der Nachfolger mit seinem Release im Jahr 2003 nun eindeutig als Software zur Erstellung und zum Betrieb von Portalen dar. Dabei besteht die Sharepoint Technologie aus zwei verschiedenen Komponenten: Den Windows Sharepoint Services (WSS) und dem darüber liegenden Sharepoint Portal Server 2003 (SPS). Die Grundidee ist jedoch bei beiden gleich: Informationen, die die Mitarbeiter bei ihrer täglichen Arbeit benötigen, an der richtigen Stelle zusammenzuführen und den Zugang dazu zu vereinfachen.^[4]

2.1.1 Microsoft Windows Sharepoint Services

Die WSS bilden die Grundlage für den SPS 2003. Sie sind als kostenloses Add-On unter Windows Server 2003 installierbar und bieten die Möglichkeit Websites für Arbeitsgruppen zu erstellen. Diese so genannten Teamsites bestehen standardmäßig bereits aus einer Grund-Infrastruktur (Menüleiste und Verwaltungsbereich), die für den weiteren Bedarf angepasst werden kann. Eine Teamsite kann durch Listen, die Datenbanktabellen ähneln und einen frei definierbaren Inhalt besitzen, erweitert werden, um Informationen zu speichern und darzustellen.^[5] Standardmäßig sind bereits Templates für Kalender, Aufgaben, Kontaktdaten, Diskussionsforen, Ankündigungen uvm. vorhanden^[6], die sich mit dem Microsoft Office 2003-Paket verbinden lassen.^[7] Darüber hinaus existieren Dokumentbibliotheken, Bildbibliotheken und Formularbibliotheken. Deren wesentlicher Unterschied zu den Listen besteht darin, Inhalte versionieren zu können, begrenzte Workflows aufzunehmen^[8] und virtuelle Ordner zu besitzen.^[9] Für jede einzelne Liste bzw. Bibliothek ist es möglich, verschiedene Ansichten (Views) zu erstellen, um den verschiedenen Informationsbedürfnissen der Mitarbeiter in unterschiedlichen Arbeitsschritten Rechnung zu tragen.^[10] Eine Bearbeitung mittels Microsoft Excel 2003 ist in einer „Datenblattansicht“ möglich.^[11]

Doch so vielfältig die Möglichkeiten mit Listen sind, bleiben dennoch etliche Anwendungsfälle, in denen Daten von außerhalb genutzt werden müssen oder die gewünschten Operationen zu komplex für die vorgegebenen Listen und Bibliotheken sind. Für diese Fälle kann die Teamsite mit so genannten „WebParts“ erweitert werden. Dabei handelt es sich um ASP.NET-Webcontrols, mit denen beliebige Daten z.B. über Webservices oder andere Datenbanken im Unternehmen verarbeitet und dargestellt werden können, wobei auch Kommunikation zwischen den einzelnen WebParts möglich ist.^[12] Es gibt bereits eine unüberschaubare Anzahl an WebParts von Drittanbietern, von Data Warehouse-Oberflächen bis hin zum Online-Wetterdienst. Damit kann jede Teamsite beliebig erweitert und dem Bedarf entsprechend angepasst werden.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Laahs et al. (2005), S. 18.

Abb. 2 - 1: Logische Struktur von Server und Sites.

Um z.B. eine Teamsite nicht zu überladen oder sinnvoll zu untergliedern und zu strukturieren, können eine oder mehrere „Subsites“ angelegt werden, die sich separat verwalten lassen und wiederum jeweils eine Teamsite sind. So lässt sich bei Bedarf eine Baumstruktur aufbauen. (sieheAbb. 2-1)

Die Benutzerverwaltung setzt auf Windows NT-Zugängen auf - in Unternehmen meist unter Nutzung einer vorhandenen Active-Directory-Domäne. Dabei können Berechtigungen anhand von vorhandenen Domänengruppen, eigens in WSS definierten Gruppen oder einzelnen Benutzern entweder auf die gesamte Teamsite oder auch für jede Liste einzeln konfiguriert werden.^[13]

Als weiteres Merkmal existiert eine Teamsite-weite Volltextsuche, die den Benutzer beim Wiederfinden von Dokumenten oder anderen Informationen unterstützt.

Da Sharepoint als Website umgesetzt ist und die meisten Benutzer bereits mit Webanwendungen vertraut sind, dürfte der Schulungsaufwand tendenziell geringer ausfallen als bei Systemen mit eigener Oberfläche.

2.1.2 Microsoft Sharepoint Portal Server 2003

Mit WSS lassen sich beliebig viele Teamsites erstellen und verwalten. Nichtsdestotrotz bleiben es Insellösungen. Um dieses Manko zu beheben, bietet Microsoft den kostenpflichtigen SPS 2003 an, der auf den WSS aufsetzt und die Teamsites in einem Portal integriert und um weitere Funktionen ergänzt. Dabei werden Informationen in Listen oder mittels eigener WebParts auf Seiten platziert, die auf dem SPS 2003 „Themen“ (engl. „Areas“) genannt werden. Diese können auch mehrdimensional eingeordnet werden, um den Benutzern auch aus verschiedenen Blickwinkeln den Weg zu den gesuchten Informationen aufzuzeigen.^[14] Zur weiteren Personalisierung wird für jeden Benutzer eine „Persönliche Site“ (engl. „Personal Site“) zur Verfügung gestellt, die sich in zwei Bereiche unterteilt: einem privaten Teil als Ersatz für die persönliche Dateiablage auf dem lokalen Arbeitsplatz^[15] und einem öffentlichen Teil, auf dem er z.B. Dokumente veröffentlichen und mittels Bild und Beschreibung über seine Person informieren kann.^[16]

Da die Sharepoint-Idee darauf abzielt, möglichst viele Informationen aus den unterschiedlichsten Quellen zusammenzuführen, wurde ein „Single Sign-On“ eingeführt, mittels dem die Authentifikation gegenüber dem SPS 2003, aber auch gegenüber anderen Systemen, durchgeführt wird. Dadurch kann dem Benutzer ein mehrfaches Anmelden an den unterschiedlichen Systemen erspart werden.^[17] Darüber hinaus stellt der SPS 2003 eine verbesserte Suchfunktion bereit, die u.a. sämtliche Teamsites erfasst und neben der Volltextsuche auch Meta-Informationen auswertet.^[18]

Die Praxis hat gezeigt, dass sich die Benutzer in der Regel recht schnell mit einem Sharepoint-System anfreunden und dieses intensiv nutzen.^[19] Bei der Planung der Infrastruktur ist es nicht nötig, sich von vornherein auf eine bestimmte Hardwarekonfiguration festzulegen, sondern diese kann zu einem späteren Zeitpunkt nach Bedarf ausgebaut werden.^[20][21] Ein Schrittweiser Aufbau ist daher ebenso möglich wie eine „Big Bang“-Einführung.

Die Sharepoint-Technologie eignet sich insbesondere im Einsatz in Unternehmen, die bereits Microsoft Office - möglichst ab Version 2003 - verwenden, da sie sich nahtlos in die bestehen Abläufe integriert und dort ihr Potenzial voll entfalten kann.^[22]

2.2 Systementwicklung

Die Einführung einer integrierten Arbeitsumgebung, wie sie die Sharepoint Technologie darstellt, muss sorgfältig geplant und vorbereitet werden, um den Erfolg der Unternehmung nicht dem Zufall zu überlassen. Daher ist es zweckmäßig, sich wissenschaftlicher Methoden zu bedienen.

Jede Software besitzt einen Softwarelebenszyklus, einen „Zeitraum von der Begründung und Planung über die Entwicklung, Einführung und Nutzung bis zur späteren Ablösung durch ein neues System“.^[23] Dieser besteht aus den beiden Hauptabschnitten: der Systementwicklung und dem sich anschließenden Systembetrieb.^[24] Der Fokus für die Einführung der Sharepoint-Technologie liegt auf dem Abschnitt der Systementwicklung. Diese wird auch als „Vorgehensweise verstanden, um nicht nur Software, sondern auch alle anderen Komponenten und Dokumente eines […] [Informations- und Kommunikationssystems (IKS)] ingenieurmäßig, pünktlich und wirtschaftlich zu entwickeln, einzuführen und zu pflegen“.^[25] In der Regel ist der Einführungsprozess eines neuen Anwendungssystems derartig komplex, dass es zweckmäßig ist, ein Vorgehensmodell, welches „den Lebenszyklus eines Softwareproduktsin Form von Aktivitäten“^[26] beschreibt und die zulässige Reihenfolge der Aktivitäten bzw. der zulässigen Überschneidungen festlegt^[27], zu verwenden. Ein bekanntes Beispiel dafür ist das Wasserfallmodell.^[28]

Die Einführung einer Anwendungssoftware im Unternehmen ist in der Regel ein
IT-Projekt, welches sich definitionsgemäß „mit der Entwicklung von Informations- und Kommunikationssystemen“^[29] befasst. Dadurch ergibt sich die Notwendigkeit einer Phase vor dem Start der Systementwicklung, die häufig Vorphase genannt wird, die neben der Projektbegründung^[30] auch noch Aktivitäten wie z.B. eine Machbarkeitsstudie beinhalten kann.

Für die Durchführung eines solchen Projektes schlagen Stahlknecht/Hasenkamp die inAbb. 2-2 dargestellte Vorgehensweise vor.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Stahlknecht/Hasenkamp (2005), S. 218.

Abb. 2 - 2: Vorgehensmodell bei der Systementwicklung

In der ursprünglichen Reinform sind die einzelnen Phasen streng nacheinander zu durchlaufen und jeweils vollständig und definitiv abzuschließen. Da dies jedoch gerade zu Beginn des Projektes zu hohe Anforderungen bzgl. Vorstellungskraft und Abstraktionsvermögen an das beteiligte Personal stellt, wird das oben aufgeführte Modell häufig mittels Zyklen modifiziert, in denen Teilsysteme gebildet werden und diese jeweils in kleinen Einheiten entwickelt werden. Eine derartige, zyklische, inkrementelle Vorgehensweise schlagen Alpar et al. vor.^[31] Im Rahmen der Grundlagen dieser Ausarbeitung sollen die einzelnen Phasen lediglich anhand des linearen Wasserfallmodells aufgezeigt werden, da diese analog auf die daran angelehnten Modelle übertragbar sind.

2.2.1 Analyse-Phase

Nach Abschluss der Vorphase folgt die Phase der Analyse. Diese teilt sich in die beiden Unterphasen Istanalyse und Sollkonzept auf.

In der Istanalyse soll der bisherige Zustand erhoben und mit Schwerpunkt auf die Schwachstellen, analysiert und bewertet werden.^[32] Dazu muss zunächst festgelegt werden, in welchen organisatorischen Einheiten die Erhebung durchgeführt werden soll und welche Geschäftsprozesse bzw. Arbeitsabläufe untersucht werden sollen.^[33] Für die Erhebung können die unterschiedlichsten Methoden, wie z.B. schriftliche Befragungen (Fragebögen), Interviews und Besprechungen, Beobachtungen oder ggf. vorhandenes Dokumentationsmaterial, verwendet werden.^[34] Die Erkenntnisse werden z.B. in Grafiken, Tabellen oder Texten, aber auch Modellen wie z.B. UML-Use-Case-Diagrammen festgehalten^[35] und münden in einem schriftlichen Bericht, der den Abschluss der Istanalyse bildet.^[36]

Die Soll-Konzeption widmet sich der Frage, ob und wie die in der vorherigen Teilphase ermittelten Mängel behoben oder zumindest reduziert werden können und welche wirtschaftlichen Vorteile das neue Anwendungssystem voraussichtlich einbringen wird^[37] (mehr siehe Abschnitt2.3). Dabei sollte auch entschieden werden, ob eine am Markt verfügbare Standardsoftware oder eine eigens entwickelte Individualsoftware zum Einsatz kommen soll, sofern dies nicht bereits durch die Informatik-Strategie des Unternehmens vorgegeben ist.^[38] Als Erhebungs- und Darstellungstechniken werden meist die bereits in der Istanalyse eingesetzten Techniken verwendet.^[39] Das Ergebnis der Soll-Konzeption ist das Fachkonzept, welches „die Datenstrukturen, Funktionen, Abläufe und Leistungen des zu entwickelnden Systems […] aus fachlicher Sicht detailliert“^[40] beschreibt.

[...]

---

^[1] Vgl. Statistisches Bundesamt (2005), S. 119.

^[2] Vgl. Popper (2002), S. 71.

^[3] Vgl. Markl (2003), S. 74.

^[4] Vgl. Weisbrod/Ganser (2004), S. 3.

^[5] Vgl. Weisbrod/Ganser (2004), S. 6.

^[6] Vgl. Laahs et al. (2005), S. 22.

^[7] Vgl. Laahs et al. (2005), S. 78.

^[8] siehe auch Microsoft (2005).

^[9] Vgl. Weisbrod/Ganser (2004), S. 118f.

^[10] Vgl. Laahs et al. (2005), S. 27.

^[11] Vgl. Laahs et al. (2005), S. 67ff.

^[12] Vgl. Boddenberg (2005), S. 203.

^[13] Vgl. Boddenberg (2005), S. 204.

^[14] Vgl. Markl (2003), S. 73f.

^[15] Vgl. Boddenberg (2005), S. 205.

^[16] Vgl. Weisbrod/Ganser (2004), S. 406f.

^[17] Vgl. Weisbrod/Ganser (2004), S. 407.

^[18] Vgl. Ganser (2005), S. 125.

^[19] Vgl. Ganser (2005), S. 127.

^[20] Vgl. Ganser (2005), S. 124.

^[21] siehe auch Microsoft (2004).

^[22] Vgl. Markl (2003), S. 74.

^[23] Stahlknecht/Hasenkamp (2005), S. 214.

^[24] Vgl. Stahlknecht/Hasenkamp (2005), S. 214.

^[25] Alpar et al. (2005), S. 278.

^[26] so zitiert in Alpar et al. (2005), S. 283.

^[27] Vgl. Alpar et al. (2005), S. 283.

^[28] siehe auch Dumke (2001), S. 104.

^[29] Wieczorrek/Mertens (2005), S. 9.

^[30] Vgl. Stahlknecht/Hasenkamp (2005), S.

^[31] Vgl. Alpar et al. (2005), S. 286f.

^[32] Vgl. Stahlknecht/Hasenkamp (2005), S. 210.

^[33] Vgl. Stahlknecht/Hasenkamp (2005), S. 227.

^[34] Vgl. Stahlknecht/Hasenkamp (2005), S. 232.

^[35] Vgl. Stahlknecht/Hasenkamp (2005), S. 235.

^[36] Vgl. Stahlknecht/Hasenkamp (2005), S. 244.

^[37] Vgl. Stahlknecht/Hasenkamp (2005), S. 245.

^[38] siehe auch Heinrich (2002), S. 105ff.

^[39] Vgl. Stahlknecht/Hasenkamp (2005), S. 246.

^[40] Alpar et al. (2005), S. 285.