Zum Newsroom

Die Stolperfallen bei SharePoint-Projekten können sehr vielfältig sein. Nach den Erfahrungen von Nils Engel, Senior IT Consultant bei der msg services gmbh, haben sie jedoch häufig ähnliche Ursachen. Er beschreibt beispielhaft, wie die Erfolgschancen deutlich gesteigert werden können.

1. SharePoint-Projekte benötigen eine zuverlässige Infrastruktur
Das neue Projekt soll losgehen, die Beauftragung ist erfolgt, aber die Infrastruktur fehlt oder ist in einem undefinierten Zustand? Ein Kollege oder ein Dienstleister hat die Umgebung vor Jahren für einen völlig anderen Kontext aufgebaut, sie ist aber nie in die Wartung aufgenommen worden? Die Beseitigung der Infrastrukturprobleme wird sehr wahrscheinlich Ressourcen im Projektverlauf binden und damit Verzögerungen verursachen. Doch wenn grundlegende Voraussetzungen in der Infrastruktur fehlen, kann eine Verschiebung des Projektstarts möglicherweise günstiger sein. 

2. Vorsicht vor fehlendem SharePoint-Wissen
Vielleicht wird SharePoint gerade erst als System im Unternehmen ausgerollt. Deshalb sind die späteren Nutzer des Systems wahrscheinlich noch nicht an die Eigenheiten von SharePoint gewöhnt. Und wie so oft werden dann auch noch die Schulungen aus Kostengründen stark reduziert oder gestrichen. Auch dieses Zusammenspiel ist häufiger anzutreffen, stösst aber nicht bei allen Kollegen auf Zustimmung. Um dem entgegen zu wirken und die Akzeptanz zu erhöhen, kann ein Training oder eine individuelle Beratung sehr sinnvoll sein, um den Einsatz der neuen Software zu forcieren. 

3. Anforderungen und SharePoint-Technologie in Einklang bringen
Noch ein Klassiker ist, dass Lotus Notes, Livelink oder ein ähnliches System aktuell im Einsatz ist, jedoch aufgrund der Lizenzierungskosten abgelöst werden soll. Die neue Lösung möge aber bitte ohne Transformation, also 1:1, migriert werden. Dabei ist SharePoint eine ganz andere Technologie als der Vorgänger und die Stärken von Lotus Notes und SharePoint sind nicht zwangsläufig die gleichen. In der Konsequenz wird das Ergebnis ohne eine Transformation für den Anwender keine klare Struktur aufweisen und damit wahrscheinlich sogar eine ablehnende Haltung erzeugen. Auch die erhöhten Entwicklungs- und Wartungskosten solch eines Konstrukts sind nicht zu vernachlässigen. Besser ist es, bei der Konzeption die zugrunde liegende Technologie zu berücksichtigen. Wobei sich das Beispiel auch auf die Anpassung der GUI übertragen lässt. Auch eine Corporate Identity sollte die Mechanik des SharePoints kennen und berücksichtigen. 

4. SharePoint nicht als professionelle Datenbank missverstehen
Oft brauchen Unternehmen stark relationale Daten. Anwender mit Angeboten, Projekten und Terminen sind dafür ein hinreichendes Beispiel. SharePoint speichert Inhalte zwar in einer Datenbank, hat aber gegenüber relationalen Datenbanken entscheidende Nachteile, was die Referenzen untereinander angeht bzw. deren gemeinsame Darstellung in einer Ansicht, einem Report oder ähnlichem. Hier ist es oft besser, ein weiteres Produkt per Schnittstelle einzubinden, wobei die einfachste Form der Schnittstelle bereits ein Iframe mit einem SingleSignOn sein kann. 

5. Einen Zielkonflikt zwischen agilen Methoden und Kosten vermeiden
SharePoint kommt nach der Installation und Konfiguration ohne ein weiteres Customizing und ohne eine Zeile Code aus. Mit dieser hervorstechenden Eigenschaft eignet sich SharePoint technisch sehr gut für ein agiles Vorgehen. Auch bei den Anwendern kommt der Appetit häufig beim Essen. Dem gegenüber planen der Einkauf oder die Geschäftsleitung mit festen Zahlen und klaren Abgrenzungen, was sie für ihr Geld bekommen wollen. Dieser Zielkonflikt wird auch gerne in das Projekt verschleppt, anstatt davor richtig gestellt zu werden. Die besten Projekte macht man, wenn sich Einkauf, Geschäftsleitung und IT auf ein gemeinsames Vorgehen geeinigt haben. Eine feste Budget-Obergrenze ist untrennbar mit einem abgeschlossenen Konzept verbunden.