Sprechen wir
Intralogistik · Microsoft 365
Ein Ort pro Projekt: ein Projekt-Hub in SharePoint und Teams für ein Intralogistik-Unternehmen.
Für ein deutsches Intralogistik- und Warehouse-Automatisierungs-Unternehmen haben wir einen Projekt-Hub in Microsoft 365 entworfen: Status, Team, Meilensteine, Berichte und Dokumente jedes Kundenprojekts an einem Ort. Gebaut aus nativen SharePoint- und Teams-Komponenten, damit das Unternehmen den Hub selbst betreibt und erweitert.
- Kunde
- Deutsches Intralogistik- und Warehouse-Automatisierungs-Unternehmen (anonymisiert)
- Branche
- Intralogistik · Warehouse-Automatisierung · Anlagenprojekte
- Rolle
- Product/UX-Design: Research, Informationsarchitektur, UI, Übergabe an Engineering
- Systeme
- Microsoft 365 · SharePoint · Teams · Power BI (Daten aus SAP)
Kurz gesagt
Ein deutsches Intralogistik- und Warehouse-Automatisierungs-Unternehmen wickelt große Kunden-Installationsprojekte parallel ab. Status, Team, Meilensteine, Berichte und Dokumente jedes Projekts lagen in verschiedenen Tools und Ordnern; eine gemeinsame, berechtigungsgesteuerte Sicht auf ein Projekt gab es nicht. Wir haben einen Projekt-Hub in Microsoft 365 entworfen: eine Projektübersicht und eine Projektsicht in SharePoint, Projektkanäle und eine geschützte Bibliothek für sensible Daten in Teams, eingebettete Power-BI-Berichte aus SAP. Alles aus nativen Komponenten, ohne Custom-Entwicklung, damit das Team des Kunden den Hub selbst pflegt. Das Ergebnis: ein Ort pro Projekt statt einer Suche über mehrere Systeme.
Relevant ist das für projektgetriebene Engineering-Unternehmen, die Microsoft 365 schon im Haus haben und keine weitere Projektmanagement-Software einführen wollen. Der Case zeigt, welche Entscheidungen in Informationsarchitektur, Berechtigungen und Übergabe darüber bestimmen, ob so ein Hub nach dem Go-live gepflegt wird oder zur nächsten vergessenen SharePoint-Seite wird.
Ausgangslage
Was war die Ausgangslage? Ein Unternehmen, das Projekte liefert, nicht Produkte, und dessen Projektinformation über Tools und Ordner verteilt war.
Wer Lager automatisiert, liefert kein fertiges Produkt, sondern ein Projekt: Fördertechnik, Regalsysteme, Steuerung und Software werden beim Kunden geplant, installiert und in Betrieb genommen. Jedes Kundenprojekt läuft über Monate, hat eigene Meilensteine, ein eigenes Projektteam aus mehreren Gewerken und einen eigenen Stand in SAP. Das Unternehmen in diesem Case führt viele solcher großen, komplexen Installationsprojekte parallel.
Die Menschen, die den Hub später nutzen, sind in erster Linie Projektleiterinnen und Projektleiter sowie die Mitglieder der Projektteams. Ihre Alltagsfragen sind einfach: Wo steht Projekt X? Wer gehört dazu, und wer ist für welches Thema verantwortlich? Welcher Meilenstein ist der nächste? Wo liegt der aktuelle Bericht, und wo das freigegebene Dokument? Hinzu kommen Führungskräfte, die über alle Projekte hinweg wissen wollen, welche Projekte Aufmerksamkeit brauchen.
Vor dem Projekt waren die Antworten auf diese Fragen an verschiedenen Orten zu finden. Status, Team, Meilensteine, Berichte und Dokumente lebten in unterschiedlichen Tools und Ordnerstrukturen. Es gab keine einzige, berechtigungsgesteuerte Sicht, in der ein Projekt auf einen Blick lesbar war. Die Folge waren Medienbrüche im Alltag: Wer ein Projekt verstehen wollte, setzte sich die Information aus mehreren Quellen selbst zusammen, und wer sie pflegte, tat das an mehr als einer Stelle.
Die Rahmenbedingung, die alles prägte: Der Hub musste innerhalb von Microsoft 365 entstehen, aus nativen SharePoint-Komponenten und Teams. Es gab keine freie Design-Fläche und keine Custom-App. Die eigentliche Aufgabe war also nicht, ein schönes Konzept zu zeichnen, sondern innerhalb eines bestehenden Komponentensystems eine klare, schnell erfassbare Oberfläche zu entwerfen, die das Engineering des Kunden tatsächlich bauen und danach selbst pflegen kann.
Auf dem Spiel stand mehr als Komfort. Ein Unternehmen, das sein Geld mit Projekten verdient, braucht pro Projekt eine verlässliche Antwort auf die Frage nach dem Stand. Liegt sie in fünf Systemen, kostet sie Zeit in jeder Besprechung, und sensible Daten wandern in Mails und geteilte Ordner, weil es keinen definierten Ort für sie gibt.
Das Problem
Was war das Problem? Projektinformation war verstreut, die Navigation folgte Dokumentbibliotheken statt Projekten, und die Plattform ließ kein freies Design zu.
Projektinformation verstreut
Status, Team, Meilensteine, Berichte und Dokumente lagen an unterschiedlichen Orten. Wer ein Projekt verstehen wollte, öffnete mehrere Tools und Ordner und baute sich das Bild selbst zusammen. Jede Quelle wurde separat gepflegt, mit dem Risiko doppelter Datenpflege und widersprüchlicher Stände.
Navigation nach Bibliotheken statt nach Projekten
Die Menschen im Unternehmen denken in Projekten und Kunden, nicht in Dokumentbibliotheken. Sie kennen Projektnummer, Angebotsnummer und Projektleitung. Die bestehende Ablage war nach Technik und Ordnern strukturiert, sodass jede Suche eine Übersetzungsleistung verlangte.
Kein freies Canvas
Der Hub musste mit SharePoint- und Microsoft-365-Komponenten gebaut werden. Eine eigene Oberfläche oder App war keine Option, weil das Engineering des Kunden das Ergebnis mit Bordmitteln bauen und langfristig pflegen sollte. Das Design musste innerhalb der Grenzen der Plattform klar und scannbar werden.
Sensible Daten ohne definierten Ort
Manche Projektdaten dürfen nicht für alle sichtbar sein. Ohne einen definierten, berechtigungsgesteuerten Ort landen sie dort, wo es gerade praktisch ist. Der Hub brauchte eine eigene Schicht für sensible Daten, ohne dafür ein zweites System einzuführen.
Organigramm nur dekorativ
Die Frage „Wer gehört zu diesem Projekt, und wen rufe ich an?“ wurde im Alltag ständig gestellt. Ein statisches Organigramm als Bild beantwortet sie nicht. Es musste handlungsrelevant sein: Rolle, Teamzugehörigkeit und Kontakt einer Person im Fluss der Arbeit, ohne die Seite zu verlassen.
Wie wir vorgegangen sind
Wie sind wir vorgegangen? Vom Research mit dem Product Owner über die Informationsarchitektur bis zu einer Übergabe, die das Engineering innerhalb von Microsoft 365 bauen konnte. Jede Entscheidung haben wir als Problem, Entscheidung und Begründung festgehalten.
- 1
Ist-Analyse mit Product Owner und Projektbeteiligten
Zuerst haben wir verstanden, wie Projekte im Unternehmen tatsächlich laufen und wo Projektleitungen heute nach Information suchen. In enger Abstimmung mit dem Product Owner haben wir die Alltagsfragen gesammelt, die der Hub beantworten muss, und die Identifikatoren, mit denen Menschen ein Projekt benennen: Projektnummer, Angebotsnummer, Projektleitung. Dabei wurde auch klar, welche Daten sensibel sind. Ergebnis war die Liste der Facetten, die pro Projekt an einem Ort stehen müssen: News, Meilensteine, Organigramm, Berichte, Dokumente.
- 2
Informationsarchitektur: Projekt → Kunde
Die Struktur des Hubs folgt der Arbeitsweise des Unternehmens, nicht der Technik: eine Projektübersicht mit allen Kundenprojekten als Karten, darunter die Projektsicht für ein einzelnes Projekt, darunter dessen Facetten Projektorganigramm, Projektberichte, Projektfortschritt und Projektdokumente. Die Übersicht ist nach den echten Identifikatoren filterbar und durchsuchbar, Karten sind in laufende und abgeschlossene Projekte gruppiert, und der Status ist auf der Karte sichtbar, bevor jemand etwas öffnet. Parallel dazu haben wir eine Teams-Schicht definiert: Projektkanäle für die Zusammenarbeit und eine geschützte Bibliothek für sensible Daten.
- 3
Projektsicht aus nativen SharePoint-Komponenten
Statt einer eigenen Oberfläche haben wir die Projektsicht aus den Web Parts zusammengesetzt, die SharePoint mitbringt: oben die Projektnews, also was sich seit dem letzten Besuch geändert hat; darunter der Meilensteinplan; am Rand das Projektorganigramm; dann der eingebettete Power-BI-Bericht mit Daten aus SAP; unten Dokumente, Quicklinks, Standort und 3D-Gebäudeansicht. Die Designarbeit bestand darin, Reihenfolge, Gewichtung und Dichte so zu wählen, dass eine Projektleitung die Seite in Sekunden scannt, und nur Komponenten zu verwenden, die das Engineering ohne Sonderentwicklung konfiguriert.
- 4
Organigramm, das Fragen beantwortet
Das Projektorganigramm haben wir in zwei Darstellungen angelegt: als Liste mit Name, Rolle und Kontakt direkt in der Projektsicht und als interaktives Organigramm. Jeder Knoten ist ein echtes Teammitglied mit Rolle und Teamzugehörigkeit. Ein Rechtsklick öffnet ein Kontextmenü mit Schnellaktionen, ein Klick ein Personen-Modal mit Rolle, Zugehörigkeit und Kontakt, ohne Seitenwechsel. So wird aus dem Organigramm ein Werkzeug für die Frage „Wen spreche ich an?“ statt eines Bildes für die Präsentation.
- 5
Teams-Schicht und Schutz sensibler Daten
Die Zusammenarbeit findet dort statt, wo das Team ohnehin ist: in Teams, mit einem Kanal pro Projekt für Beiträge und Abstimmungen. Der Meilensteinplan aus der Projektsicht erscheint auch in Teams, als dieselbe Quelle auf einer zweiten Oberfläche, nicht als Kopie, damit keine doppelte Datenpflege entsteht. Für sensible Projektdaten haben wir eine separate Bibliothek „Sensible Daten“ mit eigenen Berechtigungen angelegt. Wer was sieht, liegt damit in der Struktur des Hubs, nicht in Absprachen, und braucht kein zweites System.
- 6
BI im Projekt und über alle Projekte
Berichte aus SAP sollten nicht in einem separaten Reporting-Tool liegen. Wir haben den Power-BI-Bericht eines Projekts direkt in die Projektsicht eingebettet, dazu eine Seite Projektfortschritt, die den Stand gegen den Meilensteinplan zeigt, und aggregierte Dashboards für die Portfolio-Ebene, mit denen Führungskräfte sehen, welche Projekte Aufmerksamkeit brauchen, bevor sie in ein einzelnes Projekt einsteigen.
- 7
Übergabe an Engineering und Betrieb durch den Kunden
Zum Schluss haben wir das Konzept so übergeben, dass das Engineering des Kunden es innerhalb von Microsoft 365 umsetzen konnte: Struktur der Sites und Kanäle, Konfiguration der Komponenten, Berechtigungsmodell für die geschützte Bibliothek und die Begründung hinter jeder Entscheidung. Nur eintragen, was belegt ist.]]
Artefakte
Weitere Screens aus dem Hub, aus Vertraulichkeitsgründen unscharf: Logos, Projektnummern und Markierungen sensibler Daten sind nicht lesbar.
Ergebnis
Was ist das Ergebnis? Ein Ort pro Kundenprojekt über SharePoint und Teams hinweg, vollständig aus nativen Microsoft-365-Komponenten, damit das Team des Kunden ihn besitzt und weiterentwickelt. Messbare Nutzungszahlen liegen uns aus diesem Projekt nicht vor; wir nennen deshalb keine.
| Aspekt | Vorher | Nachher |
|---|---|---|
| Projektstand abfragen | Mehrere Tools und Ordner öffnen, Bild selbst zusammensetzen | Projektsicht öffnen: News, Meilensteine, Team, BI und Dokumente auf einer Seite |
| Ein Projekt finden | Durch Ordnerstrukturen navigieren, die nach Technik aufgebaut sind | Übersicht nach Projektnummer, Angebotsnummer oder Projektleitung filtern, Status auf der Karte |
| Team und Ansprechpartner | Nachfragen oder ein statisches Organigramm aufrufen | Organigramm mit Kontextmenü und Personen-Modal: Rolle, Zugehörigkeit, Kontakt per Klick |
| Meilensteine | An verschiedenen Orten gepflegt, Stände können abweichen | Ein Meilensteinplan, sichtbar in SharePoint und in Teams |
| Berichte aus SAP | Im separaten Reporting-Tool, Kontextwechsel nötig | Power-BI-Bericht in der Projektsicht eingebettet, Portfolio-Dashboards darüber |
| Sensible Projektdaten | Kein definierter Ort, Weitergabe per Mail oder geteiltem Ordner | Geschützte Bibliothek „Sensible Daten“ in Teams mit eigenen Berechtigungen |
Ein Ort pro Projekt
Drei Oberflächen von Microsoft 365, SharePoint als Portal, Teams für Zusammenarbeit und Governance, Power BI für die Berichte aus SAP, laufen pro Projekt zusammen. Niemand verlässt die Tools, in denen er ohnehin arbeitet, und niemand muss die Information zu einem Projekt mehr selbst zusammensuchen.
Eine Quelle, mehrere Oberflächen
Meilensteinplan, Berichte und Dokumente erscheinen dort, wo sie gebraucht werden, in der Projektsicht und in Teams, ohne an zwei Stellen gepflegt zu werden. Das ist der Unterschied zwischen einer Portalseite und einem Hub: Die Medienbrüche verschwinden, nicht nur die Links.
Governance in der Struktur
Wer welche Projektdaten sieht, ist über die geschützte Bibliothek in Teams und ihre Berechtigungen geregelt. Das Unternehmen braucht dafür kein zweites System und keine Absprache, die jeder neue Projektbeteiligte erst lernen muss.
Vom Kundenteam betreibbar
Weil der Hub aus nativen Komponenten besteht, kann das Engineering des Kunden neue Projekte anlegen, Komponenten anpassen und den Hub erweitern, ohne auf eine Agentur oder eine Custom-Codebasis angewiesen zu sein. Genau das war die Bedingung des Projekts.
Was wir gelernt haben
- 01
Die Struktur folgt der Arbeitsweise, nicht der Plattform
SharePoint legt nahe, in Sites und Bibliotheken zu denken. Die Menschen im Unternehmen denken in Projekten, Kunden und Projektnummern. Die wichtigste Entscheidung war, die Informationsarchitektur konsequent nach Projekt und Kunde aufzubauen und die echten Identifikatoren als Filter zu nutzen; Komponenten, Berechtigungen und Teams-Kanäle hängen sich an diese Struktur. Wer mit der Technik beginnt, baut eine Ablage; wer mit den Fragen der Projektleitung beginnt, baut einen Hub.
- 02
Native Komponenten sind eine Entscheidung, keine Einschränkung
Es ist verlockend, die Grenzen von SharePoint mit Custom-Entwicklung zu umgehen. Der Preis zeigt sich nach dem Go-live: Jede Anpassung braucht dann Entwickler, und der Hub veraltet, sobald niemand mehr zuständig ist. Innerhalb der nativen Komponenten zu entwerfen war anstrengender, hat aber ein System ergeben, das der Kunde selbst betreibt. Für Einführungsprojekte in Microsoft 365 halten wir das für die Regel.
- 03
Governance gehört in die Struktur, nicht in die Schulung
Eine Regel wie „sensible Daten bitte nicht in den Projektordner“ hält genau bis zum nächsten Projekt. Eine geschützte Bibliothek mit eigenen Berechtigungen hält, weil sie den richtigen Weg zum einfachsten macht. Wir würden in jedem Projekt dieser Art zuerst klären, welche Daten einen definierten, geschützten Ort brauchen, und diesen Ort anlegen, bevor die erste Seite gestaltet wird.
- 04
Akzeptanz messen, von Anfang an
In diesem Projekt haben wir die Nutzung nicht instrumentiert. Ob Projektleitungen tatsächlich zuerst im Hub landen und wie lange sie brauchen, um eine Kerninformation zu finden, wissen wir deshalb nicht belastbar. Beim nächsten Mal würden wir diese beiden Fragen vor dem Rollout definieren und nach dem Go-live messen, denn ohne diese Zahlen bleibt jeder Erfolg eine Behauptung.
- 05
Vorlage statt Einzelstück, Key User statt Rundmail
Ein Hub, bei dem jedes neue Projekt Designaufwand erzeugt, wird nicht gepflegt. Die Projektsicht gehört als Vorlage angelegt, damit ein neues Projekt ohne Gestaltungsarbeit entsteht. Für den Rollout hat sich in unseren Projekten bewährt, pro Bereich einen Key User zu benennen, der den Hub zuerst nutzt und Rückfragen beantwortet, und die ersten Wochen nach dem Go-live als Hypercare zu planen, in der Struktur und Berechtigungen noch angepasst werden.
Was wir geliefert haben
- Ist-Analyse: Alltagsfragen der Projektleitung, Suchwege und Identifikatoren, in Abstimmung mit dem Product Owner
- Informationsarchitektur des Hubs: Projektübersicht → Projektsicht → Facetten, plus Teams-Schicht
- Entwurf der Projektübersicht mit Suche, Filtern nach Projektnummer, Angebotsnummer und Projektleitung und Status auf den Karten
- Entwurf der Projektsicht aus nativen SharePoint-Komponenten: News, Meilensteinplan, Organigramm, eingebettetes BI, Dokumente, Quicklinks, Standort und 3D-Gebäudeansicht
- Interaktives Projektorganigramm mit Kontextmenü und Personen-Modal sowie Listenansicht
- Konzept der Teams-Schicht: Projektkanäle, Meilensteinplan in Teams, geschützte Bibliothek „Sensible Daten“ mit Berechtigungsmodell
- Eingebettete Power-BI-Berichte aus SAP in der Projektsicht, Seite Projektfortschritt und Portfolio-Dashboards
- Entscheidungsdokumentation nach dem Muster Problem → Entscheidung → Begründung
- Übergabe an das Engineering des Kunden als pflegbares, erweiterbares System innerhalb von Microsoft 365
Häufige Fragen
- Geht so ein Projekt-Hub ohne Custom-Entwicklung?
- Ja, in diesem Case war das die Bedingung. Projektübersicht, Projektsicht, Organigramm, Dokumentbibliotheken und eingebettete Power-BI-Berichte sind mit den Komponenten umgesetzt, die SharePoint und Teams mitbringen. Die Designarbeit verlagert sich von der Oberfläche auf die Struktur: welche Facetten auf eine Seite gehören, in welcher Reihenfolge, mit welchen Filtern und Berechtigungen. Der Vorteil: Das Unternehmen betreibt und erweitert den Hub selbst.
- Wie läuft die Einführung bei den Projektteams?
- In diesem Case haben wir das Konzept an das Engineering des Kunden übergeben. Für den Rollout empfehlen wir den Weg, den wir in Einführungsprojekten generell gehen: mit ein bis zwei laufenden Projekten als Pilot starten, pro Bereich einen Key User benennen, die Projektsicht als Vorlage anlegen und die ersten Wochen nach dem Go-live als Hypercare planen, in der Struktur und Berechtigungen noch angepasst werden. Eine Rundmail mit Link ersetzt das nicht.
- Warum SharePoint und Teams statt einer Projektmanagement-Software?
- Weil das Unternehmen Microsoft 365 schon im Haus hatte und die Projektteams ohnehin in Teams arbeiteten. Ein weiteres Tool hätte einen weiteren Ort geschaffen, an dem Information gepflegt werden muss, und damit genau das Problem vergrößert, das gelöst werden sollte. Ein Hub in Microsoft 365 nutzt die bestehenden Lizenzen, Berechtigungen und Gewohnheiten. Ob das auch für Ihr Unternehmen gilt, klären wir in einer Ist-Analyse.
- Wie werden sensible Projektdaten geschützt?
- Über eine separate Bibliothek „Sensible Daten“ in Teams mit eigenen Berechtigungen. Projektkanäle und Projektsicht bleiben für das Projektteam offen; die geschützte Bibliothek sehen nur die Personen, die dafür freigeschaltet sind. Die Governance liegt in der Struktur der Plattform, nicht in einer Regel, die jeder neue Projektbeteiligte erst lernen muss.
- Was passiert mit den Daten aus SAP?
- Die Berichte aus SAP erscheinen als Power-BI-Berichte direkt in der Projektsicht und in der Seite Projektfortschritt, dazu aggregiert in Portfolio-Dashboards über alle Projekte. Der Hub ersetzt SAP nicht und pflegt keine eigenen Kopien der Daten; er zeigt die Berichte dort, wo die Projektleitung sie im Kontext des Projekts braucht, ohne Wechsel in ein separates Reporting-Tool.
- Werden Kunden- oder Endkundennamen genannt?
- Nein. Der Case ist anonymisiert: echte Arbeit, keine Namen. Die Screens zeigen wir unscharf, sodass Logos, Projektnummern und Markierungen sensibler Daten nicht lesbar sind. Was wir zeigen, sind die Struktur des Hubs und die Entscheidungen dahinter.
Microsoft 365 im Haus, Projektinformation trotzdem verstreut?
Wir entwerfen Projekt-Hubs und Fachportale innerhalb der Plattform, die Sie schon haben, mit einer Struktur, die Ihre Teams selbst pflegen. Erzählen Sie uns in einem Erstgespräch, wie Ihre Projekte heute laufen.
Erstgespräch vereinbaren