Einleitung

Seit dem es den Micosoft Office SharePoint Server 2007 (MOSS) gibt, erfreut er sich zunehmender Beliebtheit in Unternehmen aller Größenordnungen. Wo der SharePoint Portal Server 2003 und die Windows SharePoint Services 2.0 (WSS) noch mehr oder weniger ein Schattendasein führten, hat sicherlich die Marketingstrategie Microsofts sehr dazu beigetragen, dass nun der MOSS 2007 in beinahe aller Munde ist. Interessiert man sich für ein mit Microsoft Office verbundenes Thema, so wird man inzwischen beinahe überall auch auf das Thema MOSS stoßen und ist beinahe schon gezwungen sich mit dem Thema zu befassen.

Wie es eigentlich auch schon bei seinem Vorgänger der Fall war ist der MOSS 2007 jedoch kein Werkzeug, welches einfach mal so mit einem Fingerschnippen implementiert ist. Natürlich ist ein Testsystem schnell aufgesetzt und ein simples Setup ist wahrlich kein Hexenwerk, plant man jedoch den Produktivbetrieb wird man schnell auf vielerlei Dinge stoßen, die schon von der rein technischen Seite zu bedenken sind. Beschäftigt man sich noch ein wenig tiefer mit der Implementierung, so wird man auch auf eine ganze Menge von organisatorischen Punkten treffen, die ebenfalls nicht unbedacht bleiben sollten.

Dieser Artikel versucht sich nun mit einem kleinen Rundumblick zu befassen, der einen Eindruck und eine kleine Hilfestellung liefern soll, was bei der Implementierung eines MOSS zu bedenken, zu beachten, zu organisieren und vorzubereiten ist, um ein erfolgreiches Projekt daraus zu machen, und nicht einfach nur ein weiteres Werkzeug zur Verfügung zu stellen, welches in einem Unternehmen nur ein Werkzeug unter vielen anderen Werkzeugen ist.

Es wird hier jedoch nicht auf die verschiedenen Begriffe der SharePoint-Welt eingegangen. Der Artikel ist also im Wesentlichen für Leser geeignet, die sich bereits mit den Grundlagen der Microsoft SharePoint-Technologien beschäftigt haben.

Philosophische Sichtweise und Appell

Natürlich ist jedem Projektleiter, der schon einmal ein neues Tool, Programm oder Programmpaket in einem Unternehmen ausgerollt hat, klar, dass kein Rollout-Projekt so einfach durchzuführen ist, wie die Marketingstrategen des Herstellers es glaubhaft zu versichern versuchen.

Ein MOSS Projekt hat jedoch noch einige besondere Tücken. Dies ist sicherlich nicht nur beim MOSS 2007 so, sondern auch bei vielen anderen Produkten. Was macht ein MOSS-Projekt jedoch so tricky?

Zunächst einmal bieten die Microsoft SharePoint Produkte einen verlockenden Teaser. Dabei handelt es sich um die Windows SharePoint Services 3.0 in Verbindung mit dem SQL-Server Express. Beide Produkte sind Lizenzkostenfrei zu beziehen und erleichtern auch für kleine IT-Umgebungen einen ersten Einstieg in die SharePoint-Welt.

Dies verlockt jedoch dazu, sich dem Gedanken hinzugeben Kostet ja nix, da ist es nicht so schlimm, wenn es kein großer ruhmreicher Erfolg wird. Bitte folgen Sie diesem Gedanken nicht! SharePoint-Technologien sind in jeder ihrer Ausprägungsstufen ein mächtiges Werkzeug und sollten nicht wie irgendeine Freeware behandelt werden, die man mal ausprobiert. Man sollte nie außer Acht lassen, dass Anwender durchaus auch am finanziellen Wert einer Software deren Brauchbarkeitsgrad abzulesen versuchen.

Allgemeines

Im Folgenden werden die 1000 Dinge, die zu beachten sind, wenn Microsoft Office SharePoint implementiert werden soll in verschiedene Bereiche unterteilt werden. Dies werden die Bereiche:

Technik und technisch administratives
Features, Prozesse und organisatorisches
Marketing und Indoktrination
Wartung, Support und Zukunftsperspektiven

sein. Diese Bereiche werden sich ein wenig miteinander vermischen, da manche Themen nicht wirklich genau einzuordnen sind und eigentlich in mehrere Bereiche fallen.

Technik und technisch administratives

Hardware-Setup und Farm-Architektur

Grundsätzlich gilt, dass MOSS frei skalierbar ist, was die reine Gestaltung der Farm-Architektur angeht. Man sollte sich jedoch von Anfang an darüber klar werden, welche Ausbaustufen es in den unterschiedlichen Projektphasen geben soll. Dazu zählt auch sich darüber zu informieren, bzw. festzustellen, wie viele Benutzer mit dem SharePoint-System arbeiten sollen. Dabei ist weniger wichtig, wie viele Mitarbeiter insgesamt den MOSS nutzen werden, sondern vielmehr, mit welcher Intensität die Benutzer das System nutzen werden.

Um hierzu eine Richtgröße zu ermitteln kann eine relativ überschaubare Faustformel benutzt werden. Nutzen Sie dazu folgendes Fallbeispiel:

Das Unternehmen hat 100 Mitarbeiter, die SharePoint nutzen werden. Nun gilt es ein durchschnittliches Nutzerverhalten zu Grunde zu legen, um festlegen zu können, welche Architektur zu Einsatz gebracht werden muss. Man kann die 100% SharePoint-Nutzer grob in folgende Benutzertypen aufteilen:

30% Leser, Surfer, Browser (mit ca. 10 Zugriffen pro Stunde auf die Seiten)30% Normal-Nutzer, Sucher und Bearbeiter (mit ca. 50 Zugriffen pro Stunde auf Seiten, Dokumente)30% Power-User (100 Zugriffe pro Stunde, lesend, schreibend, suchend)10% Super-Power-User (120 Zugriffe pro Stunde, Suchläufe, Dantenimporte, lesen, schreiben)

Daraus lässt sich bei 100 Usern die Faust-Formel entwickeln:(30*10 + 30*50 + 30*100 + 10*120)/60 = 100

Die bedeutet, dass mit ca. 100 gleichzeitigen Zugriffen auf SharePoint pro Minute zu rechnen ist. Anhand dieser Kennzahl erfahrungsgemäß eine Serverarchitektur abgeleitet werden:

1-50 = Einzelner Server (single server)

51-100 = Kleine Farm (small farm)

101-500 = mittlere Farm (medium sized farm)

501 2000 = große Farm (large farm)

>2000 = Unternehmens- Farm (enterprise farm)

Dabei bedeutet:

Single server

Ein einzelner Server, auf dem sowohl die Datenbank, als auch der Webserver, als auch die gemeinsamen Dienste(shared services) installiert werden.

Small farm

Die Datenbank wird auf einen eigenen Server ausgelagert. Der eigentliche MOSS mit Webserver und gemeinsamen Diensten ist auf einem zweiten Server installiert.

Medium sized farm

Es wird eine Dreiteilung des gesamten Systems vorgenommen. Datenbankserver, Dienste-Server und Webserver sind auf drei Hardware-Maschinen installiert.

Large farm

Das Prinzip der medium sized farm wird um einen order mehrere zusätzliche Web-Frontend-Server erweitert, die Load-Balancing ausführen, um der erhöhten Zugriffzahl auf die Webseiten des MOSS gerecht zu werden. Die Front-End-Webserver sind meist die Stelle, an der es zu erst zu Performance-Engpässen kommt. Datenbank und Dienste sind meist nachrangig von höherer Benutzerzahl betroffen.

Enterprise farm

Die large farm Architektur wird erweitert und die einzelnen Dienste der shared services werden auf eigene Server ausgelagert. Dabei sollte vorrangig der Search- und Indexing-Dienst ausgelagert werden.

Weitere Hinweise auch unter:

http://technet.microsoft.com/en-us/library/cc789337.aspx

Hardware-Erweiterung der Server

Geht man generell von einer Server-Hardware-Ausstattung aus, die in etwas so aussieht:

DualCore CPU 2,6 GHz
8 GB RAM
Gigabit Netzwerkkarte
Raid 10 Plattensystem

So hat sich in verschiedenen Studien und Performance-Tests herausgestellt, dass im Unterschied zu früheren Doktrinen primär die Anzahl an Prozessorkernen für Performance-Unterschiede verantwortlich ist. Sekundär die Menge an Arbeitsspeicher und tertiär die Festplattenperformance.

Die Erweiterung um zwei weitere CPU-Kerne bringt in etwa eine Leistungssteigerung um das 1,7 fache, während eine Verdopplung des Arbeitsspeichers nur etwa eine 1,2 fache Leistungssteigerung bewirkt. Dies ist insbesondere dann interessant und zu bedenken wenn SharePoint in virtuellen Umgebungen (etwa VM-Ware) betrieben wird. Zuerst sollten stets die Web-Frontend-Server erweitert werden.

SQL-Server Datenbank

Auch die SQL-Server Datenbank sollte für eine ordentliche Performance des Gesamtsystems nicht in ihrem Standard-Zustand belassen werden. Beschäftigt man sich etwas mit diesem Thema, so findet man interessante Hinweise auch hier einiges in Sachen Performance-Optimierung tun zu können.

Tempdb

Die Anzahl der Tempdb-Daten-Dateien sollte im Allgemeinen der Anzahl der CPU-Kerne des Datenbankservers entsprechen. So empfiehlt es auch Microsoft selbst.

Die Tempdb ist eine System-Datenbank die überaus schreibintensiv ist. Daraus folgt, dass die Daten-Dateien der tempdb in einem RAID 10-System auf einer eigenen Platte (Raid set) abgelegt werden sollen. Werden unterschiedliche Festplatten innerhalb des RAID benutzt, so sollte hier die schnellste Platte benutzt werden.

Datenbank-Dateien aufteilen

Gemäß Service Level Agreement (SLA) unterstützt Microsoft SQL-Server keine Daten-Dateien, welche größer als 50 GB sind. Bei intensiver SharePoint-Nutzung werden Inhaltsdatenbanken jedoch sehr schnell größer als 50 GB. Dies ist auch nicht das eigentliche Problem, denn SQL-Server Datenbanken dürfen sehr wohl größer als 50 GB werden, jedoch sollten sie dann physikalisch auf mehrere Datenbank-Dateien aufgeteilt werden (Jene Dateien, die auf die Dateiendung .MDF hören). Wenn möglich sollten die aufgeteilten Datenbank-Dateien einer SQL-Datenbank in einem RAID 10 System nicht im gleichen RAID set abgelegt werden. Log-Dateien sollten ebenfalls getrennt abgelegt werden.

Features, Prozesse und organisatorisches

Mysite

Ein Schlüsselelement innerhalb eines SharePoint Systems ist die persönliche Webseite jedes einzelnen Benutzers. Sofern der Office Server eingesetzt wird, ist die Entscheidung zu treffen, ob diese persönlichen Websites gestattet werden, oder nicht. Die SharePoint Services unterstützen das Feature Mysite nicht.

Wenn Mysites gestattet sind, sind auch diesbezüglich eine ganze Reihe von Entscheidungen im Projektrahmen zu treffen.

Einheitliches Template

Um alle Benutzer bei der ersten Erstellung Ihrer Mysite mit einem einheitlichen Template für die Mysite zu versorgen, bietet es sich an, ein solches zu definieren. Das Standard-Template ist sicherlich für viele Zwecke ausreichend, stellt aber dennoch eher ein Beispiel dar, als das es sich für den Produktiveinsatz im Unternehmen eignet. Es viele Goodies denkbar, die den Benutzern auf ihren Mysites bereitgestellt werden. Hierzu zählen zu Beispiel: Outlook Webaccess, vorgefertigte RSS-Feeds, Bereitstellung wichtiger Formulare (Urlaub, Reisekosten, etc.), Webservices und Webparts für den Zugang zu anderen Unternehmensdaten, und noch viele mehr.

Profilpflege

Ein etwas kitzliges Thema, welches mit dem Betriebsrat abgestimmt werden sollte, wenn es denn einen solchen gibt.

Ansonsten ein sehr schönes Feature, das die Personensuche sehr erleichtert und auch dem Informationsaustausch unter den Nutzern fördert. In diesem Zusammenhang ist das Thema Profilimporte aus dem ActiveDirectory oder anderen Profildiensten zu beleuchten.

Es muss festgelegt werden, welche Profileigenschaften die Benutzer pflegen sollen, und welche Profileigenschaften eventuell noch ergänzt werden müssen.

Eventuell unerwünschte Features

Für die Mysite gibt es eventuell im Unternehmen unerwünschte Features, wie beispielsweise Blogs, Wikis, Diskussionen, Umfragen. Solche Features verführen natürlich die Benutzer etwas dazu ggf. auch damit zu spielen und hier eventuell nicht unternehmensrelevante Aktivitäten zu entwickeln. Diesbezüglich sollte eine entsprechende Betriebsanweisung entwickelt werden.

Benutzertraining

Da es sich bei der Mysite um den persönlichen Tummelplatz des Benutzers handelt, für den er auch entscheidet, welcher seiner Kollegen darauf Zugriff hat, sollten die Benutzer keinesfalls mit diesem allein und unvorbereitet konfrontiert werden. Auch hier sollte eine enge Einbindung der Projekt-Key-User gesucht werden.

Getrenntes Entwicklungssystem

Wenn man darüber spricht, so wird jeder sofort heftig nicken, wenn man sagt Neue Features und Entwicklungsarbeiten niemals am Produktivsystem!, aber wenn man sich hin und wieder umsieht, wird man vielerorts sehen, dass am offenen Herzen operiert wird.

Beim derzeitigen Stand der Hardware-Kosten und der Möglichkeiten zur Virtualisierung von Systemen gibt es jedoch kaum eine Entschuldigung dafür kein vom Produktivsystem getrenntes Entwicklungs- und Testsystem zu haben.

In den meisten Fällen ist ein virtualisiertes single server System schon vollkommen ausreichend, um für Adminstratoren, Schulungen und Entwicklung eine eigene Spielwiese bereit zu stellen, die nicht sofort Einfluss auf das Live-System hat.

Backup-Strategie

In den meisten Unternehmen wird sehr viel Wert darauf gelegt, dass ein lückenloses vollständiges Backup von allen Daten, die sich irgendwo auf den Unternehmens-Servern befinden, erstellt und sicher aufbewahrt wird.

Restore Tests

Es sollten jedoch nicht nur regelmäßig Sicherungen der Daten durchgeführt werden, sonder genauso in festgelegten Abständen auch überprüft werden, ob sich aus den Sicherungen die Daten auch wieder herstellen lassen. Das ist meist leichter gesagt, als getan, denn dies setzt voraus, dass entsprechende Systeme und Kapazitäten vorhanden sind, um einen Restore-Test durchführen zu können. Wer will schon an einem Live-System testen, ob sich die Datensicherung vom Vormonat (oder auch nur dem Vortag) wieder herstellen lässt? Und das im laufenden Betrieb? Oder an einem Wochenende?

Auch an dieser Stelle sei nochmals für virtuelle Testsysteme plädiert! Diese müssen ja nicht genauso stark ausgelegt sein, wie die Live-Systeme, sondern nur die Umgebungen simulieren und solche Restore-Tests möglich machen.

Besonders für SharePoint ist dies wichtig, da sich hier beinahe aus allen Bereichen unternehmenskritische Daten wiederfinden werden, sobald ein SharePoint System einmal adaptiert ist!

Ein interessanter Artikel dazu befindet sich hier:

http://searchwinit.techtarget.com/generic/0,295582,sid1_gci1319577,00.html

Was , wo, wie?

Im SharePoint-Umfeld finden sich Sicherungsmöglichkeiten für die Daten an zwei wesentlichen Stellen. Im SQL-Server und im SharePoint selbst.

Über die SQL-Server-Wartungsjobs können Sicherungen der reinen SQL-Server-Datenbanken erstellt werden. SharePoint selbst verfügt in der Zentraladministration ebenfalls über ein Backup-Tool und zusätzlich über das Kommandozeilentool STSADM, mit dem einzelne SiteCollections gesichert werden können.

In jedem Falle sollte man sich ein wenig Zeit nehmen, die verschiedenen Möglichkeiten für Backups miteinander in einer vernünftigen Kombination zu nutzen und zu konfigurieren. Man muss sich darüber klar werden, dass SQL-Server-Backups nur für den absoluten Katastrophenfall geeignet sind, während das STSADM Tool flexiblere Möglichkeiten eröffnet.

Grenzen und Workarounds

Falls der schlimmste Fall eintritt können mit Bordmitteln nur maximal ganze SiteCollections (Sammlungen von Webseiten, Bibliotheken, Listen etc.) wieder hergestellt werden. Einzelne Sites, oder gar ein einzelnes Dokument stellten dann eine Herausforderung dar.

Inzwischen bieten viele Hersteller professioneller Backup Software jedoch SharePoint-Schnittstellen an, über welche gegebenenfalls sogar einzelne Dokumente oder Listeneinträge wieder hergestellt werden können. Dies bedarf jedoch der Konfiguration und die Software selbst ist meist nicht eben ein Schnäppchen.

Mit geeigneter Vorbereitung lässt sich jedoch auch mit den Standard-Mitteln ein vertretbarer Mittelweg finden, um notfalls ein einzelnes Dokument herstellen zu können. Die Basis dafür sind:

Überlegte Aufteilung der Inhalte in SiteCollections
Regelmäßige Backups über Timerjobs und STSADM
Kenntnis von Rollback-Verfahren mit SQL-Server Datenbanken
Regelmäßige Backups der SQL-Daten (besonders auch der LOG-Dateien)

Mit einem Testsystem und einem Datenbank-Rollback lassen sich SiteCollections auf einen bestimmten Bearbeitungszustand/Zeitpunkt wieder herstellen. Das gleiche funktioniert zumindest Tagesgenau mit STSADM Backups.

Danach können über Standard Kopierfunktionen (z.B. WebDAV) einzelne Dokumente wieder vom Testsystem auf das Produktivsystem kopiert werden.

Zur wieder Herstellung einzelner Webseiten oder Bibliotheken eignet sich ein Open Source Tool wie z.B. der SPContentDeploymentWizard (http://spdeploymentwizard.codeplex.com/)

Migration und/oder Dokumentablage

Der Umstieg von der herkömmlichen ordnerbezogenen Ablagestruktur in einem Dateisystem auf ein Bibliothekssystem in SharePoint ist sicherlich eine der größten Herausforderungen in einem SharePoint-Projekt. Um diesen Schritt erfolgreich zu bewältigen, sollte genau überlegt sein, wie der Umstieg zu vollziehen ist. Dabei sind vor allem die Vorteile vom SharePoint-Bibliotheken gegenüber dem Filesystem im Fokus zu halten:

Dateien in SP-Bibliotheken können mit beliebigen zusätzlichen Metadaten versehen werden (Verschlagwortung, Kategorisierung, Statusvergabe, uvm.)
Versionierung
Checkin Checkout Funktionen
Volltextsuche über Dokumente
Dokumentenworkflows
Freigabe-Workflows
Teamarbeit an einzelnen Dokumenten

Um diese Vorteile nicht zu verlieren und nicht einfach ein Ablagesystem gegen ein anderes einzutauschen sollte eine Planung unter Einbeziehung der folgenden kleinen Checkliste durchgeführt werden:

Harte Migration oder Schnitt-Migration?
- Alle Dokumente nach SharePoint migrieren?
- Dokumente ab einem definierten Zeitpunkt nur noch in SharePoint ablegen?
Wie sollen die Dokumenten-Metadaten aufgebaut sein?
- Einheitlich oder nach fachlichen Bereichsanforderungen?
- Welche Metadaten werden Pflichtvorgaben?
Wie und in welchem Umfang soll Versionsverwaltung genutzt werden?
Welche Workflow-Typen sollen Verwendung finden?
- Einheitliche Standard-Workflows einsetzen?

Je nachdem welche SharePoint Version eingesetzt wird (Lizenzvariante) sollte daran gedacht werden, dass die SharePoint-Suche auch auf bestehende Dateisysteme ausgeweitet werden kann.

Benutzer abholen

Siehe dazu die Abschnitte:Business Need oder Nice To HaveBenutzertrainingMut zum Delegieren

Suchen neu gelernt und gefördert

Die SharePoint Suche ist ein Element, an welches die Benutzer große Erwartungen knüpfen werden. Daher sollte unbedingt dafür gesorgt werden, dass die Suche entsprechend sorgfältig konfiguriert ist und auch organisatorisch die Suche ständig verbessert und gepflegt wird.

Regelmäßig analysieren

Die SharePoint Zentraladministration (MOSS 2007, nicht WSS 3.0) bietet die Möglichkeit zum Zugriff auf die Suchprotokolle, die Auskunft darüber geben, was gesucht wird (welche Schlagworte, mit wie vielen Ergebnissen, mit welchen Klicks, etc.). Daraus lassen sich Rückschlüsse ziehen, wie die Suche verbessert und angepasst werden muss.

Beste Suchergebnisse (Best bets)

Ein wichtiges Hilfsmittel für eine akzeptierte Suche ist die Pflege und ständige Ergänzung von besten Suchergebnissen, die dem Benutzer für bestimmte Suchworte ausgewählte beste Ergebnisse vorschlagen (ähnlich wie die Google-Bezahl-Links am rechten Rand des Browsers). Diese bedürfen aber, wie schon erwähnt einer ständigen Pflege und Ergänzung. Die Verantwortung dafür kann beispielsweise den SiteCollection-Administratoren übertragen werden.

Suchbereiche (Scopes)

Auch das Aufgliedern der Suche in Suchbereiche ist für Benutzer sehr hilfreich. Besonders wenn die SharePoint Inhalte im laufenden Betrieb ständig anwachsen. So kann der Benutzer schon bevor er die Suche startet einen ersten Filter auf bestimmte Inhaltsbereiche setzen und erhält nicht tausende von Treffern, mit denen er nichts anfangen kann.

Auch die Suche im SharePoint will entsprechend gelernt sein, um die besten und eindeutigsten Suchergebnisse zu erhalten. Man sollte sich nicht davor scheuen auch Erweiterungen zu SharePoint Suche zu evaluieren, wie beispielsweise:

http://facetedsearch.codeplex.com/

http://searchrelevancy.codeplex.com/

http://spwildcardsearch.codeplex.com/

Security Trimming

Bei der Konzeption der Suche ist stets zu berücksichtigen, dass die Darstellung der SharePoint Suchergebnisse einem Security Trimming unterliegt. Dies bedeutet, dass der suchende benutzer nur die Suchergebnisse angezeigt bekommt, zu denen er an ihrem Speicherort mindestens auch lesenden Zugriff hat. Dies kann die Suchergebnisse für unterschiedliche Benutzer sehr unterschiedlich ausfallen lassen.

Rechte und Berechtigungen

SharePoint verfügt über ein eigenes Berechtigungssystem. Es können Berechtigungen auf Seiten- , Listen- und Listeneintragsebene vergeben werden.

Von der Grundidee her ist SharePoint ein eher offenes System zum Informationsaustausch. Es geht von vererbten Rechten für alle Benutzer aus. Das bedeutet, dass ein Benutzer, der auf Seitenbene Leserechte besitzt, diese Leserechte auch auf allen untergeordneten Ebenen dieser Seite besitzt.

Das Sicherheitsbedürfnis in einem SharePoint-Projekt ist häufig jedoch wesentlich komplexer aufgebaut. Um ein komplexes Berechtigungssystem in einer SharePoint Umgebung zu realisieren, ist ein nicht unbeträchtlicher Verwaltungsaufwand zu berücksichtigen.

Einige Hinweise, die helfen könnten, dies etwas einfacher zu gestalten:

Benutzen Sie AD-Gruppen auch innerhalb des SharePoint
Vergeben Sie Berechtigungen an einzelne (namentliche) Nutzer nur in Ausnahmefällen
Bilden Sie übergreifende SharePoint-Berechtigungsgruppen
Vergeben Sie Berechtigungen auf Listeneintrags-Ebene nur in Ausnahmefällen
Dokumentieren Sie das Berechtigungskonzept

Business need und Nice to have

Da SharePoint mit all seinen Möglichkeiten, der Programmierbarkeit und dem Baukastenprinzip nur al seine echte eierlegenden Wollmilchsau zu bezeichnen ist, ist eine wichtige Aufgabe in einem SharePoint-Projekt die Unterscheidung zwischen echter Anforderung und einem Nice to have zu treffen.

Aufgrund der Möglichkeiten Features selbst zu entwickeln und Workflows einzubinden sowie der zahllosen weiteren Eigenschaften (Business Data Catalog, Excel Services, Enterprise Search, Infopath-Forms, Forms-Server, etc.) kann man nur sagen Alles ist möglich. Hier ein paar einfache Empfehlungen, wie relativ einfach zwischen Need und Nice unterschieden werden kann:

Sprechen Sie mit den Benutzern nicht nur mit dem Management
Nehmen Sie Anforderungen nicht von Einzelpersonen, sondern immer von Gruppen auf
Zeigen Sie, was im Standard machbar ist
Drücken Sie sich immer klar aus, was Aufwände zu Anpassungen und Features betrifft
Seien Sie sich immer darüber bewusst, dass jedes Feature beim Benutzer eine Lernkurve hat und schätzen Sie diese möglichst genau ab
Wägen Sie stets ab, ob ein neues Feature notwendig ist, oder ob mit einer kleinen Prozessänderung eventuell auch schon eine Standard-Funktion die Anforderungen erfüllen kann

Workflows

Ein integraler Bestandteil SharePoints ist die Möglichkeit mit Workflows zu arbeiten. Diese Workflows können mit den Hilfsmitteln SharePoint Designer 2007 oder mit Visual Studio erstellt werden. Auch Out Of The Box bringt SharePoint schon einige Workflows mit, die sofort eingesetzt werden können.

Sofern in einem SharePoint-Projekt Workflows geplant werden, so ist zu bedenken, welches Werkzeug eingesetzt werden soll. SP-Designer-Workflows sind an sich schon sehr mächtig und vor allem einfach zu erstellen, beherrschen jedoch einige Dinge nicht::

Schleifen (Durchlauf einer Liste mit allen Einträgen, wie in einer FOR-Schleifen, wie sie in Programmiersprachen zu finden ist)
Wiederverwendbarkeit (an anderen Listen und Seiten, als an denen, an denen sie erstellt wurden)
Reaktion auf Systemereignisse (automatischer Start zu einem bestimmten Zeitpunkt)
Programmierbarkeit (es müssen vorgefertigte Workflow-Aktionen genutzt werden)

Workflows, die mit Visual Studio erstellt werden, beherrschen all diese Dinge und noch einige mehr. Es muss jedoch berücksichtigt werden, dass VS-Workflows programmierkenntnisse voraussetzen und die Erstellung keinesfalls intuitiv ist. Ein VS-Workflow bringt immer einen nicht zu unterschätzenden Aufwand mit sich.

Zusätzlich zu den vorgenannten Möglichkeiten gibts es Workflow-Tools, welche die Vorteile beider Welten miteinander verbinden. Hierzu zählt beispielsweise : http://www.nintex.com/en-US/Products/Pages/Workflow2007.aspx

Es sei jedoch angemerkt, dass bei Verwendung solcher Tools der Kostenfaktor teilweise nicht unbeträchtlich ist.

In der Abfolge eines Projekts sollte die Entwicklung von Workflows in der Regel erst zum Ende berücksichtigt werden. Ausnahmen bilden dabei echte Business-Needs.

Andere Systeme und Unternehmensdaten

Auch schon in der kleinen SharePont-Variante WSS 3.0 gibts es Möglichkeiten lesend auf Unternehmensdatenbanken zuzugreifen und diese mit SharePoint Daten in Beziehung zu setzen (z.B. Über DataViews). Die MOSS 2007 Enterprise Version enthält das Feature der Business Data Kataloge (BDC) mit dem externe Datenbanken mittels XML Transformation in SharePoint eingebunden werden können.

Die Erstellung von BDCs und DataViews erfordert entsprechend tiefe Kenntnisse des SharePoint-Systems. In der Konsequenz müssen die Aufwände im Projekt mit einkalkuliert werden.

Die Planung der Einbindung von Unternehmensdaten sollte berücksichtigen:

Art der Datenquellen
Aufwand zur Aufbereitung (Erzeugen von Views, Transformationen, etc.)
Zugriffssteuerung (Sicherheit, Single Sign Logon)
Performance
Verknüpfung mit SharePoint Daten

Marketing und Indoktrination

Interne Werbetrommel

Nicht zu unterschätzen ist die Bedeutung des unternehmensinternen Marketings für die Plattform SharePoint. Benutzer neigen dazu SharePoint zunächst nur als ein weiteres Tool unter den vielen anderen zu sehen, die sie bereits erlernen und einsetzen mussten.

Da die Entscheidung für die Plattform SharePoint meisten eine strategische Entscheidung ist, ist es ebenso strategisch wichtig jedem einzelnen Mitarbeiter dies auch bewusst zu machen und ihn für das Projekt zu begeistern. Dies gelingt erfahrungsgemäß am besten, wenn Entscheidungen offen getroffen und diskutiert werden. Benutzer aus allen Bereichen sollten wissen, was da auf sie zu kommt und die getroffenen Entscheidungen mit tragen.

Viele erfolgreiche Projekte sind dabei gezielt in folgenden Schritten des internen Marketings vorgegangen:

Vorstellung und Diskussion im Management-Kreis
- Gewinnung von Förderern im mittleren Management
Identifizierung von Meinungsträgern und Key-Usern im gesamten Nutzerumfeld (hier ist wirklich auch der feine Unterschied zu beachten!)
- Je größer die Schnittmenge, desto besser
- Daraus wird dann die Gruppe der Projekt-Key-User (PKUs)
Vorstellung und Diskussion der Projektziele und der SharePoint-Technologie im Kreis der PKUs
Identifizierung der echten Business-Needs bei Management und PKUs
Priorisierung der Anforderungen
Produktion eines Türken (also eines Dummies, oder Prototypen), für die 3-4 am höchsten priorisierten Anforderungen
Erst wenn sowohl Management, als auch PKUs von den vorgestellten Lösungen überzeugt sind, Bereitstellung eines Spielsystems

In den weiteren Schritten des internen Marketings müssen vor allem die PKUs dabei begleitet werden, die gesamte Nutzergemeinschaft zu trainieren und buchstäblich an ihren Arbeitsplätzen abzuholen.

Keine halben Sachen

Es sollte vermieden werden, eine SharePoint-Lösung nur mit bestimmten Ausnahmen umzusetzen. Ein kleines Beispiel dafür, was gemeint ist:

Die Dateiablage im Filesystem soll durch SharePoint-Bibliotheken abgelöst werden. Alle Vor- und Nachteile sind erörtert. In diesem Fall sollten die betroffenen Bereiche im Filesystem rigoros für Bearbeitung und Neuanlage von Dateien gesperrt werden. Es wird nur einen sehr langsamen Projektfortschritt geben, wenn man sagt: Ab sofort sollen alle Dokumente in SharePoint abgelegt werden. Aber übergangsweise gestatten wir auch noch die Benutzung der alten Dateiablage auf dem Server XYZ

Solche halben Sachen führen dazu, dass Benutzer diese Ausnahmeregelung auch nutzen werden und eine Umstellung erschwert wird oder gar vollkommen ausgebremst wird. Für jede Regel lässt sich eine Ausnahme finden, aber man sieht am deutschen Steuergesetz, was daraus dann resultiert.

Mut zum Delegieren

SharePoint ist von seinem Wesen und von seinen Grundideen her ein System zur Zusammenarbeit, welches offene Informationsstrukturen unterstützt. Insbesondere wird auch die Delegation von Verantwortung für die verschiedenen Informationsbereiche unterstützt und von SharePoint gefördert.

Leider bestehen gerade in deutschen Unternehmen recht große Vorbehalte gegenüber der Delegation von Rechten und Verantwortung über Informationen und Daten an Mitarbeiter, die nicht dem Bereich der Unternehmens-IT angehören.

Sofern nicht die Bereitschaft besteht einem Mitarbeiter eines Teams die Verantwortung für de Administration der Teamseite zu übertragen, muss man sich darüber klar sein, dass druch das Bestehen auf einer zentralen Administration ein kaum abzuschätzender personeller Aufwand für die Administration entsteht.

Ganz radikal könnte man formulieren:Ohne Bereitschaft zur Delegation von Verantwortung bleibt SharePoint weit hinter seinen Möglichkeiten zurück!

Um Verantwortlichkeiten klar zu definieren und den künftigen administrativen SharePoint bezogenen Aufwand in möglichst kleinem Rahmen zu halten, bietet es sich an, die zusätzliche Zeit im Projekt zu kalkulieren, die notwendig ist, um ein Betriebs und Support-Konzept zu etablieren.

Wartung, Support und Zukunftsperspektiven

Das nächste SharePoint

Schon jetzt sind einige Features des nächsten SharePoint (14) bekannt oder zumindest relativ sicher, da bereits erste Alpha-Versionen in Umlauf sind, wenn auch mit einer Veröffentlichung sicherlich nicht vor Ende 2010 zu rechnen ist.

Das führt dazu, bereits jetzt für zukünftige Migration auf neue SharePoint-Versionen Vorbereitungen treffen zu können.

Schon jetzt auf 64 Bit Version installieren, zukünftig wird es nur noch 64 Bit Versionen geben.
Anwendungsentwicklung auf .Net Framework 3.0 basieren lassen. Künftige Versionen werden vermutlich auf .Net 3.0 oder höher basieren.
Wenn möglich Datenbank SQL-Server 2008 verwenden.
Bereits jetzt die Features von MS-Groove in der Planung berücksichtigen. Künftige Versionen werden wahrscheinlich einen hohen Grad an MS-Groove-Integration besitzen

Aufgaben im Support

Der Support in SharePoint-Projekten wird üblicherweise etwas unterschätzt. Auch wenn die SharePoint-Oberfläche und die Features für Anwender durchaus leicht zu erfassen und zu bedienen sind, so entstehen die meisten Support-Anfragen aus eben dieser Tatsache. Nutzer wenden sich weniger mit Anfragen zu Problemen an den Support, als vielmehr mit Anregungen zur Erweiterung und Ideen.

Daher sollte eine Support-Struktur entwickelt werden, die dem System gerecht wird. Dazu ist eine Aufteilung in einen rein technischen Support und einen Anwendersupport zu empfehlen.

Mehrere Anlaufstellen

Ein mehrstufiges Support-Konzept bewirkt sowohl eine Reduzierung der Anforderungen an die Mitarbeiter des IT-Bereichs, als auch eine erhöhte Marketingwirkung.

Key-User sollte für die Anwender die erste Anlaufstelle bei auftretenden Problemen sein.

Die entsprechenden Webseiten-Verantwortlichen mit Unterstützung der IT-Abteilung sollten akzeptierte Ansprechpartner für erweiterte fachliche Anforderungen werden.

Erst an letzter Stelle der Support-Kette sollte dann als technischer Anlaufpunkt die IT-Abteilung stehen.