Service-Portal Maschinenbau

Ein Service-Portal für Anlagen, Tickets, Ersatzteile und Dokumente

Projektbeschreibung

Für einen mittelständischen Maschinenbauer haben wir ein Kundenportal für Maschinenbau-Service entwickelt. Der Kunde betreut industrielle Anlagen über mehrere Werke hinweg. Vor dem Projekt liefen viele Serviceprozesse über E-Mail, Telefon, PDF-Anhänge, ERP-Auszüge und persönliche Rückfragen. Für Kunden war dadurch oft schwer erkennbar, welches Ticket offen ist, wann ein Ersatzteil geliefert wird, welche Dokumentation aktuell ist oder ob eine Anlage aus Service-Sicht besondere Aufmerksamkeit braucht.

Entstanden ist eine digitale Plattform, die Anlagen, Tickets, Ersatzteile, Live-Daten, Dokumente, Verträge und Rechnungen in einem gemeinsamen Arbeitskontext verbindet. Das Portal ist nicht nur ein Self-Service-Bereich, sondern bildet die Beziehung zwischen Maschinenbauer und Betreiber ab: vom laufenden Ticket bis zur Ersatzteilbestellung, vom Wartungsvertrag bis zur Rechnung.

Das Projekt war wichtig, weil Service im Maschinenbau nicht nur Support ist. Service entscheidet über Anlagenverfügbarkeit, Kundenzufriedenheit, Ersatzteilumsatz und langfristige Bindung. Ein Portal, das Status und Zuständigkeiten sauber abbildet, reduziert nicht nur Rückfragen. Es macht die Serviceleistung des Herstellers sichtbar.

Zielbild

Das Business-Ziel war, Serviceprozesse zentraler steuerbar zu machen und Kunden mehr Transparenz zu geben. Statt einzelne Vorgänge manuell zu erklären, sollte der Kunde im Portal sehen, was gerade passiert, welche nächsten Schritte geplant sind und welche kaufmännischen Informationen dazugehören. Gleichzeitig schafft das Portal eine Grundlage für digitale Serviceangebote, Ersatzteilumsatz und datenbasierte Wartungsmodelle.

Das Nutzerziel war Klarheit für Instandhaltung, Werkleitung und Einkauf. Ein Instandhaltungsleiter möchte nicht zwischen Ticketnummer, Seriennummer, Handbuch, Bestellung und Rechnung springen. Er möchte von der Anlage ausgehen und dort alle relevanten Informationen finden. Deshalb wurde die Plattform konsequent um Werke und Anlagen herum strukturiert.

Das technische Ziel war ein Datenmodell, das industrielle Beziehungen sauber abbildet. Ein Werk hat Anlagen, Anlagen haben Seriennummern, Ersatzteile, Dokumente, Live-Daten, Tickets, Wartungen und Verträge. Tickets können Bestellungen auslösen. Bestellungen können Rechnungen erzeugen. Dokumente gehören zu bestimmten Anlagen und Versionen. Diese Zusammenhänge mussten stabil modelliert werden, damit das Portal später an ERP, Dokumentenmanagement, Live-Datenquellen und weitere Kunden angebunden werden kann.

Herausforderungen

Die größte Komplexität lag in der Verbindung von Service- und Maschinendaten. Ein Ticket ist nicht nur eine Nachricht. Es hat SLA, Status, Priorität, Anlage, Standort, mögliche Ersatzteile, Historie, interne Zuständigkeit und Kommunikation mit dem Kunden. Wenn diese Zusammenhänge im System fehlen, wird aus einem Portal nur ein Postfach mit schöner Oberfläche. Für den Maschinenbauer musste die zugrunde liegende Geschäftslogik deshalb zuerst sauber verstanden und modelliert werden.

Eine zweite Herausforderung war der Ersatzteilprozess. Kunden sollten nicht in einem allgemeinen Shop suchen müssen, sondern Teile sehen, die zu ihren Anlagen passen. Das ist fachlich anspruchsvoller als ein normaler Produktkatalog. Kompatibilität, Stücklisten, Lieferzeit, Vertragsrabatte, Kostenstelle, Expressversand und Bestellhistorie beeinflussen die Entscheidung. Wenn ein falsches Teil bestellt wird, entstehen Stillstand und zusätzlicher Serviceaufwand. Deshalb wurde der Ersatzteilbereich als anlagenbezogener Prozess gestaltet.

Auch Live-Daten und Predictive-Hinweise mussten vorsichtig behandelt werden. Produktionsdaten wie Stückzahl, OEE, Sensorabweichungen oder Stillstand wirken nur dann vertrauenswürdig, wenn sie im richtigen Kontext angezeigt werden. Ein Sensor-Drift darf nicht wie eine dramatische Störung erscheinen, wenn er nur ein Hinweis für das nächste Wartungsfenster ist. Die Oberfläche musste deshalb zwischen akuten Tickets, geplanten Wartungen und beobachteten Anomalien unterscheiden.

Die Rollenlogik war ebenfalls relevant. Instandhaltung, Einkauf, Werksleitung, Service-Team und kaufmännische Ansprechpartner brauchen unterschiedliche Informationen und Rechte. Nicht jeder Nutzer soll Rechnungen sehen, Ersatzteile bestellen oder Tickets freigeben können. Diese Rechte mussten in der Produktstruktur mitgedacht werden, auch wenn die Referenz vor allem die Kundensicht zeigt.

Umsetzung

Wir haben die Plattform um den natürlichen Einstieg des Kunden herum aufgebaut: Werk, Anlage, Vorgang. Das Dashboard zeigt die aktuelle Lage eines Werks mit offenen Tickets, aktiven Anlagen, Lieferungen, SLA und anstehenden Terminen. Nutzer erkennen sofort, welche Vorgänge heute relevant sind und welche Themen geplant weiterlaufen.

Im Anlagendetail wurden die wichtigsten Informationen zusammengeführt. Stammdaten, Seriennummer, Modell, Wartungsvertrag, Verantwortliche, Live-Stückzahl, OEE, offene Vorgänge und Predictive-Hinweise liegen an einem Ort. Diese Entscheidung war wichtig, weil die Anlage der gemeinsame Nenner fast aller Serviceprozesse ist. Wer von der Anlage ausgeht, kann Tickets, Ersatzteile, Dokumente und Wartung logisch verbinden.

Der Ersatzteilbereich wurde nicht wie ein klassischer Shop entwickelt. Die Produktsicht folgt der Frage: Welche Teile passen zu meinen Anlagen und was bedeutet die Bestellung für Betrieb, Vertrag und Lieferzeit? Deshalb zeigen die Karten Kompatibilität, Lagerstatus, Expressoptionen, Vertragsrabatt und Bestellmenge. Der Warenkorb enthält Lieferort, Kostenstelle und Netto-Summe, weil diese Informationen im B2B-Prozess nicht optional sind.

Für Tickets wurde eine Master-Detail-Struktur gewählt. Links stehen Vorgänge und Prioritäten, rechts die Kommunikation, Systemevents und nächsten Schritte. So können Nutzer Status und Verlauf verstehen, ohne den Kontext zu verlieren. SLA, automatische Ereignisse und interne Hinweise lassen sich dadurch später mit Benachrichtigungen, Monitoring oder Service-Automation verbinden.

Auch der Betrieb wurde als Teil des Produkts gedacht. Ein solches Portal muss mit ERP-Daten, Dokumentversionen, Rollenrechten und Live-Datenquellen umgehen können. Dafür braucht es klare Schnittstellen, nachvollziehbare Fehlerzustände und eine Umgebung, in der Service-Teams Änderungen kontrolliert ausrollen können. Die Architektur wurde so angelegt, dass weitere Werke, Anlagenklassen, Dokumenttypen, Rollen und Integrationen ergänzt werden können, ohne den Kernprozess neu zu entwerfen.

Ergebnis

Entstanden ist ein Portal, das den industriellen Serviceprozess nicht vereinfacht, indem es Details weglässt, sondern indem es sie richtig ordnet. Kunden können von ihrem Werk zur Anlage gehen und dort sehen, welche Tickets offen sind, welche Ersatzteile verfügbar sind, welche Dokumente gelten, welche Live-Daten auffällig sind und welche Rechnungen oder Verträge dazugehören.

Für Nutzer bedeutet das weniger Rückfragen und weniger Suche nach Statusinformationen. Für den Kunden bedeutet es eine zentralisierte Servicekommunikation und einen besseren Zugang zu digitalen Umsatzkanälen wie Ersatzteilen, Wartungsverträgen und datenbasierten Serviceangeboten. Für den Betrieb entsteht eine klarere Datenlage, weil Tickets, Bestellungen, Dokumente und Anlagen nicht mehr als getrennte Vorgänge behandelt werden.

Technisch bildet das Portal eine Grundlage für weitere Produktstufen. Neue Kunden, Werke, Anlagen, Rollen, ERP-Schnittstellen oder Predictive-Maintenance-Funktionen können auf einem vorhandenen Modell aufbauen. Genau darin liegt der eigentliche Wert der ersten Version: Sie kann schnell live gehen, ohne nur ein Portal-Prototyp zu sein.

Produktansichten