Unsere Microsoft 365 Reise geht weiter: Wir wissen bereits, welche Produkte bzw. Produktbestandteile an welcher Stelle im Unternehmen zum Einsatz kommen sollen. Nun geht es endlich an die Umsetzung, aber wie?
Beim Reisen gibt es oft zwei Typen von Menschen: Die, die alles im Vorhinein ganz genau planen und für jeden Tag ein festes Programm zusammenstellen und die, die sich erst vor Ort spontan entscheiden, was gerade am besten passt und wonach ihnen ist. So ähnlich ist es auch bei der Projektumsetzung, wobei sich gerade letzteres in Form vom agilen Vorgehen in der IT weitgehend durchgesetzt hat. Doch was genau bedeutet „agil“ in diesem Zusammenhang eigentlich?
Viele Wege führen zum agilen Erfolg
Ganz einfach ausgedrückt soll mit einem möglichst geringen initialen Aufwand, möglichst flexibel und mit einer hohen Abstimmungsdichte in der Umsetzung auf die Wünsche des Auftraggebers eingegangen und das Projekt so möglichst schnell zum Erfolg gebracht werden. Neben den Leitsätzen und Prinzipien, die im Agilen Manifest festgehalten sind, gibt es verschiedenste Methoden, wie Scrum, Kanban oder Extreme Programming (XP), um nur die bekanntesten zu nennen. Die Vorteile liegen unter anderem in der Priorisierung auf das Wichtigste, einem raschen Rollout und schnellerem Nutzen und damit auch zeitnahem Feedback von echten Usern. Agiles Vorgehen eignet sich besonders gut für etwas Neues. Bei der Ablösung eines Altsystems kann es schwierig werden, da üblicherweise erstmal Funktionalitäten verloren gehen. Das schließt das Vorgehen aber nicht grundsätzlich aus.
Und so lief es bei uns: Zusammenarbeit in Kundenprojekten
Unser erster Anwendungsfall war die Zusammenarbeit in Kundenprojekten – sowohl während der Sales- als auch der Projektphase selbst. Die Grundfunktionalität liefert uns hier Microsoft Teams: Kommunikation, Dateiablage, Zusammenarbeit an und mit Dokumenten – und noch viel mehr mit zahllosen Apps. Hier wollten wir mit einem MVP-Ansatz starten, also „Minimum Viable Product“ – sprich, welche Funktionalität ist minimal notwendig, damit das Produkt Benutzern schon einen Mehrwert bietet.
Wir fragten uns also: Wie gestalten wir unsere Microsoft Teams Plattform, um …
- den Kollegen die Nutzung von Teams schmackhaft und attraktiv zu machen
- die Einstiegshürde gering zu halten
- das Ausufern von Teams in Teams zumindest etwas zu zügeln
- die Benutzer nicht mit den endlosen Möglichkeiten zu überfordern
- Konflikte mit anderen Systemen zu minimieren
Im nächsten Schritt planten wir einen Workshop, um uns mit den folgenden Fragen zu beschäftigen: Wie korrelieren ganz allgemein in Microsoft Teams die Teams und die Kanäle in zu unseren Projekten? Welche Funktionen sind in Kundenprojekten wirklich wichtig, weil sie essentiell sind, heute bereits durch ein System bereitgestellt werden oder ohne Risiko einen Mehrwert bringen? – die klassischen „low hanging fruits“. Außerdem sollte es darum gehen, in welchen Situationen neue Microsoft Teams-Strukturen und ggf. Kanäle benötigt werden und wer diese erstellen können soll, damit kein Wildwuchs entsteht? Und in dem Zusammenhang auch: Wie lassen sich die Verantwortlichkeiten für die Teams in Microsoft Teams sinnvoll festlegen?
Folgendes haben wir als Ergebnis aus dem Workshop festgehalten:
- Ein Microsoft Teams Team stellt die Kommunikation und die „Beziehung“ zu einem Kunden oder Fachbereich dar, d.h. die Kombination aus einem Kunden und ein Produkt bzw. einer Lösung (s. Grafik).
- Verfügbare Apps sollten auf die für Kundenprojekte elementaren Funktionen reduziert werden, so dass sie ohne große Schulung einfach zu nutzen sind.
- Das Anlegen von Teams und Kanälen erfolgt indirekt über unsere interne Projektadministrationslösung, um eine kleine Hürde zum Anlegen von Teams zu schaffen – und gleichzeitig die Funktion in einem Tool zur Verfügung zu stellen, welches jeder kennt und mit dem jeder bereits vertraut ist.
- Einfache Guidelines zur Nutzung erstellen, z. B.:
- Wir unterscheiden schon von jeher zwischen Produkt-bezogenen Informationen (Dokumentation, usw.), die über die gesamte Lebensdauer relevant sind und Projekt-bezogenen Informationen (Protokolle, Kommunikation, -…), die nur während der Laufzeit eines Projekts wichtig sind.
- Produktbezogene Information sollen nun im Kanal „Allgemein“ abgelegt werden
- Projektbezogene Information sollen im jeweiligen Projekt-Kanal abgelegt werden, der nach Abschluss des Projekts dann auch archiviert wird
- Wir unterscheiden schon von jeher zwischen Produkt-bezogenen Informationen (Dokumentation, usw.), die über die gesamte Lebensdauer relevant sind und Projekt-bezogenen Informationen (Protokolle, Kommunikation, -…), die nur während der Laufzeit eines Projekts wichtig sind.
Unser MVP bestand also aus:
- Microsoft Teams im Standard
- Etwas eingeschränkte Apps-Auswahl
- Der zu entwickelnden Funktionalität zum Anlegen von Teams und Kanälen
- User Guides
Die nächsten Iterationen sollen dann den externen Zugriff für Kunden, die Freischaltung weiterer Apps und natürlich das Dokumentenmanagement in Projekten umfassen.
Dokumentenmanagement in Projekten
Unsere DMS-Lösung, die schon viele, viele Jahre bei uns im Einsatz ist, deckt viele Use Cases ab. Vorranging geht es um die Dokumente aus Projekten und diesen Use-Case haben wir bereits durch unsere Teams Lösung abgedeckt. Mit Ausnahme von Dokumenten im Projekt, die im weitesten Sinne vertraglichen Charakter haben: diese sollten vorerst nicht in Teams abgelegt werden.
Des Weiteren wird unser DMS durchgängig von allen Abteilungen, also auch dem Vorstand, usw. genutzt, so dass teilweise sensible Informationen abgelegt sind, wie beispielsweise Personaldokumente. Außerdem nutzen wir es schlicht als Archiv, u. a. für Rechnungen, Bestellungen und Dokumentation aus alten Projekten. Aber auch die Verwaltung und Bereitstellung von Dokumentenvorlagen, genauso wie die Ablage persönlicher Dokumente machen einen wesentlichen Teil aus.
Unser DMS enthält Dokumente aus der gesamten Unternehmenshistorie, also aus mehr als 25 Jahren – wir haben bisher nur gelöscht, was wirklich zwingend gelöscht werden musste. Das finale Ziel dieses Teilprojekts lautet also: Unser umfangreiches DMS nach Microsoft SharePoint zu migrieren und das Bestandssystem abzuschalten.
Macht auch hier der MVP-Ansatz Sinn? Nur bedingt. Denn hier ist eine gute, genauere Vorabplanung unerlässlich. Wir müssen uns zunächst Gedanken machen über die folgenden Punkte:
- Grundstrukturen: wir wollen Sites, Subsites, Dokumentbibliotheken usw. unternehmensweit grundsätzlich einheitlich nutzen
- Berücksichtigung von Aufbewahrungsfristen und einfachere Lösung, um ggf. auch mal etwas Löschen zu können
- Berechtigungen – hier gibt es oft komplexe Anforderungen
- „Benutzerbefindlichkeiten“ 🙂
Diese Punkte widersprechen nicht zwingend dem agilen Ansatz – eine Entwurfsphase zu Beginn ist durchaus legitim. Dennoch haben wir diese bewusst sehr umfassend gestaltet. Wir wollen damit verhindern, dass wir später große Anpassungsaufwände haben, weil wir in der Anfangsphase (in Unkenntnis von später im Projekt auftauchenden Anforderungen) Entscheidungen getroffen haben.
Diesen Blog schreibe ich übrigens während sich unser Projekt gerade noch in der DMS-Phase befindet – und es wird uns sicher noch eine ganze Weile beschäftigen.
Dennoch: im nächsten Blogbeitrag soll es schon um die Lessons learned gehen – sind Sie dabei?
Begleiten Sie unsere Microsoft 365 Reise – Folgen Sie uns auf unseren Social Media Accounts um die weiteren Microsoft 365 Reiseberichte nicht zu verpassen.
0 Kommentare