Kundenportal Maschinenbau: Standard oder Eigenbau?

Wenn Ihr Service täglich 40 bis 60 Anrufe zu Dokumenten, Ersatzteilen oder Ticketstatus bearbeitet, ist die Portalfrage eine Geschäftsentscheidung, keine IT-Nebensache. Sinnvoll ist es, die Wahl zuerst an drei Punkten festzumachen: Datenlage, Zeit bis zum ersten Nutzen und Aufwand im Betrieb über fünf Jahre.

Kurz gesagt:

• Eine Standardplattform passt meist, wenn Ihre installierte Basis sauber geführt ist und Sie zügig in den Betrieb wollen.
• Eine Eigenentwicklung passt nur, wenn Ihr Prozess klar vom Marktüblichen abweicht und Sie Wartung, Sicherheit und Weiterentwicklung auf Jahre selbst tragen wollen.
• Ohne maschinenbezogene Daten bleibt jedes Portal nur eine Oberfläche.
• 6 bis 8 Wochen bis zum ersten Portal sind bei einer Standardplattform oft machbar.
• 12 bis 18 Monate und 250.000 € bis 400.000 € sind für eine Eigenentwicklung eine typische Größenordnung (Erfahrungswert).
• Der saubere Einstieg ist oft nicht die Softwarewahl, sondern ein Installed Base Assessment.

Prüfen Sie das Thema am besten in dieser Reihenfolge:

• Ist die installierte Basis je Maschine sauber zugeordnet?
• Welche Vorgänge sollen Kunden selbst erledigen?
• Wer trägt Releases, Sicherheit und Support in 3 bis 5 Jahren?
• Ab wann spart das Portal im Service messbar Zeit?

Überblick im Schnellvergleich:

Der Artikel behandelt das daher als Make-or-buy-Frage: Welches Modell trägt Ihren Service im Alltag – und nicht nur beim Go-live? Das Reifegradmodell Digitalisieren → Vernetzen → Entscheiden → Automatisieren ist dafür der passende Rahmen. Ab Stufe 2 kann ein Portal greifen; ohne Stufe 1 nicht.

Was ein Portal kann – und was nicht

Das 4-Stufen-Modell: Digitalisieren – Vernetzen – Entscheiden – Automatisieren

Im 4-Stufen-Modell liegt das Kundenportal auf Stufe 2: Vernetzen. Dort macht es Maschinendokumentation, Servicefälle, Ersatzteile und Vertragsstatus zugänglich.

Diese Stufe setzt jedoch Stufe 1 voraus: Digitalisieren. Gemeint ist eine sauber aufgebaute installierte Basis. Maschinen müssen eindeutig identifiziert sein, Servicevorgänge der richtigen Anlage zugeordnet werden, und Dokumente müssen maschinenspezifisch vorliegen. Fehlt diese Grundlage, zeigt das Portal zwar Informationen an, steuert aber nichts verlässlich. Die Stufen 3 und 4 – Entscheiden und Automatisieren – bauen genau darauf auf. Erst dann trägt Self-Service im Tagesgeschäft.

In der Praxis ist das keine IT-Frage, sondern eine Servicefrage. Wenn die Zuordnung zwischen Maschine, Historie und Dokument nicht stimmt, landet die Anfrage trotz Portal wieder beim Innendienst. Das 4-Stufen-Modell hilft, diese Abhängigkeiten nüchtern einzuordnen.

Warum ein Portal ohne Maschinendaten nur eine Oberfläche bleibt

Verlässlicher Self-Service entsteht nur dann, wenn Maschine, Dokument und Servicevorgang eindeutig zusammenpassen und die Stammdaten konsistent gepflegt sind. Ohne diese Datenbasis bleibt ein Portal eine Fassade.

Die Digitale Maschinenakte (IOTAM) schafft genau diese maschinenspezifische Grundlage. Sie ordnet Informationen nicht nur einem Kundenkonto, sondern der einzelnen Maschine zu. Das ist der Punkt, an dem aus einer Ansicht ein nutzbarer Servicekanal wird.

Wenn Sie zuerst klären wollen, wie vollständig und konsistent Ihre installierte Basis heute ist, bietet das Installed Base Assessment einen strukturierten Einstieg. Häufig zeigt sich hier schon, warum Portale im Alltag hinter den Erwartungen bleiben: Meist liegt das Problem in der fehlenden Datenordnung dahinter, weniger in der Oberfläche selbst.

Wo der Portalnutzen in der Praxis beginnt

Der Nutzen zeigt sich bei wiederkehrenden Servicefragen. Im Alltag geht es oft um drei Dinge:

• Wo ist meine Dokumentation?
• Wie ist der Stand meines Servicefalls?
• Welches Ersatzteil passt zu meiner Konfiguration?

Wenn ein Portal diese Fragen verlässlich beantwortet, sinkt die Zahl der Anrufe und E-Mails. Der Innendienst wird entlastet, und der Kunde erhält die Antwort direkt im Self-Service. Ausschlaggebend sind dabei die sauber geführten Maschinendaten im Hintergrund, weniger die Oberfläche selbst. Eine strukturierte Anforderungssicht liefert die Checkliste für Self-Service-Portale.

Ein typisches Szenario zeigt das Muster: Ein Hersteller stellt Dokumente zentral bereit, aber nicht maschinenspezifisch. Der Kunde findet mehrere Versionen, kennt den Freigabestand nicht und fragt doch wieder beim Service nach. Generische Inhalte erzeugen dann neue Rückfragen statt Entlastung. Genau deshalb ist Datenqualität der Maßstab für den Portalnutzen.

Standardplattform oder Eigenentwicklung: ein direkter Vergleich

Auf Basis einer sauberen Datenstruktur fällt an dieser Stelle die eigentliche Richtungsentscheidung: Soll das Portal zügig in den Betrieb gehen, oder bauen Sie sich schrittweise ein eigenes Produkt mit dauerhaftem Betriebsaufwand? Für diese Abwägung zählen vor allem drei Punkte: Time-to-Value, TCO und Betriebssicherheit.

Standardplattform mit Branchentiefe

Eine Standardplattform mit Branchentiefe bringt ein vorkonfiguriertes Datenmodell mit. Maschinenakte, Servicefall, Ersatzteil und Vertragsstatus sind in der Regel bereits angelegt. Das verkürzt die Projektphase und senkt das Risiko, dass Grundlogiken im Service erst im laufenden Betrieb nachgeschärft werden müssen.

Der praktische Nutzen zeigt sich beim Start: Ein erstes produktives Portal ist erfahrungsgemäß in sechs bis acht Wochen machbar – vorausgesetzt, die installierte Basis ist sauber strukturiert. Gerade für Serviceleiter ist das ein handfester Punkt. Sie sehen früh, ob Kunden Dokumente finden, Fälle sauber einstellen und Ersatzteile ohne Umwege anfragen können.

Auch der Betrieb ist klarer planbar. Updates, Sicherheit und neue Funktionen kommen im Produktzyklus des Anbieters. Ihr Team muss also keinen eigenen Wartungsrückstand aufholen. Dokumente, Tickets und Ersatzteile lassen sich direkt im Portal verknüpfen. Wenn das Portal in Salesforce eingebettet ist, entsteht daraus ein Arbeitsmittel für Kunden und Service statt eines isolierten Zugangskanals.

Wenn Standard: eigene Portal-Plattform oder Salesforce?

Innerhalb der Standard-Option gibt es noch eine zweite Weiche. Eine dedizierte Portal- oder Digital-Experience-Plattform (DXP) wie Liferay oder Adobe Experience Manager ist ebenfalls Standardsoftware, aber nicht an Ihr CRM gebunden. Liegen Kundendaten, Serviceprozesse und Maschinenakte bereits in Salesforce, kommt bei einer separaten DXP eine Integrationsschicht zwischen Portal und CRM hinzu, die gebaut und über Jahre gepflegt werden muss. Das ist genau der Dauerbetrieb, der weiter oben über die eigentlichen Kosten entscheidet.

Eine CRM-native Standardplattform auf der Salesforce Experience Cloud vermeidet diesen Zwischenlayer. Das Portal greift auf dieselben Datensätze zu wie der Service: Maschine, Servicefall, Serviceauftrag, Bestellung. Ein Ticket aus dem Portal läuft durch denselben Prozess wie ein intern erfasstes, und die Sicht „dieser Kunde sieht nur seine Maschinen“ folgt den Salesforce-Freigaberegeln.

Eine eigenständige DXP bleibt sinnvoll, wenn das Portal viele Zielgruppen weit über den Service hinaus bedient, ein On-Premises-Betrieb Pflicht ist oder eine content-getriebene öffentliche Website im Zentrum steht. Für ein After-Sales-Portal rund um Maschine, Servicefall und Ersatzteil ist die Zweitplattform aber meist der teurere Betriebsweg – aus demselben Grund, der auch gegen die Eigenentwicklung spricht: entscheidend ist, wer den Dauerbetrieb trägt.

Eigenentwicklung: Flexibilität mit versteckten Betriebskosten

Eigenentwicklungen wirken am Anfang oft attraktiv, weil sich jeder Prozess nach Wunsch abbilden lässt. In der Praxis wird jedoch genau dieser Vorteil später teuer.

Ab dem Go-live liegen Wartung, Sicherheitsmanagement und Weiterentwicklung komplett beim eigenen Team. Dazu kommen typische Folgekosten: Sicherheitslücken müssen geschlossen, neue Anforderungen aus dem Service eingebaut und Wissen bei Personalwechseln neu aufgebaut werden. Das bindet nicht einmalig Budget, sondern Jahr für Jahr Arbeitszeit.

Als Richtwert nennen Erfahrungswerte aus vergleichbaren Projekten 250.000 bis 400.000 Euro Projektkosten sowie 12 bis 18 Monate Umsetzungszeit. Diese Werte sind keine feste Regel, zeigen aber die Größenordnung. Für viele Unternehmen ist der kritische Punkt der Betrieb über mehrere Jahre, nicht die Programmierung.

„Die eigentliche Frage ist nicht ‚programmieren oder kaufen‘, sondern: Wer trägt in fünf Jahren Wartung, Sicherheit und Weiterentwicklung – und wie schnell steht der erste messbare Nutzen?“

Vergleichstabelle: Standardplattform, Eigenentwicklung und SAP-basierter Aufbau

Ein SAP-basierter Aufbau kann sinnvoll sein, wenn das Portal vor allem bestehende ERP-Daten sichtbar machen soll und SAP im Serviceprozess ohnehin eine zentrale Rolle spielt. Sollen Kunden jedoch selbstständig mit Maschinendokumentation, Servicefällen und Ersatzteilen arbeiten, fehlt häufig die Vorkonfiguration für den Maschinenservice. Dann entsteht zusätzlicher Aufbauaufwand, obwohl die Grunddaten bereits im Haus sind.

Für die strategische Einordnung hilft das Reifegradmodell Digitalisieren → Vernetzen → Entscheiden → Automatisieren. Ein Portal entfaltet seinen Nutzen meist nicht schon dadurch, dass Daten sichtbar werden. Es muss auch in die Abläufe passen, damit aus Information eine konkrete Servicehandlung wird.

Welche Option passt zu welchem Hersteller?

Nach dem Vergleich der Modelle zählt der Alltag: Welche Option trägt Ihr Servicegeschäft im Betrieb? Die Entscheidung hängt vor allem an drei Punkten: Datenreife, Servicevolumen und Betriebsverantwortung. Aus der Portalfrage wird damit eine klare Make-or-buy-Entscheidung.

Wann eine Standardplattform die richtige Wahl ist

Ein typisches Szenario: Ein Serienfertiger betreut eine große installierte Basis, und das Serviceteam bearbeitet jeden Tag 40 bis 60 Anrufe zu Dokumentation, Ersatzteilen oder Störungsmeldungen. In diesem Fall liegt das Entlastungspotenzial auf der Hand. Je größer die installierte Basis, desto eher lohnt sich ein Kundenportal im Maschinenbau. Wenn Kunden Standardanliegen im Portal selbst lösen, sinkt die Last im Innendienst direkt. Dass große Serienfertiger diesen Weg gehen, ist öffentlich dokumentiert – etwa bei Heidelberg mit einem Kundenportal für Dokumentation, Ersatzteile und Servicefälle.

Voraussetzung ist eine saubere Datenbasis. Hersteller mit gut gepflegter installierter Basis können in Stufe 2 ein Portal deutlich schneller einführen. Wer Daten bereits erfasst und verbunden hat, kommt im Serviceportal schneller von der Idee in den Betrieb.

Wenn Sie kein eigenes Softwareprodukt über Jahre betreiben wollen, ist eine Standardplattform oft der passendere Weg. Betrieb, Sicherheitsupdates und neue Funktionen liegen dann beim Anbieter. In Salesforce lässt sich ein solches Portal eng mit Serviceprozessen, Fällen und der installierten Basis verbinden, ohne dass Sie daraus ein eigenes IT-Produkt machen müssen. Der Kernunterschied liegt am Ende in der Frage, wer den Dauerbetrieb trägt – weniger in der Funktionsliste.

Wann eine Eigenentwicklung noch sinnvoll sein kann

Eigenentwicklung ist ein Sonderfall, kein Standardweg. Sinnvoll ist sie nur, wenn Ihr Serviceprozess stark vom Marktüblichen abweicht, ein belastbares internes Team den Betrieb auf Dauer absichert und Maschinendaten das eigene Netzwerk nicht verlassen dürfen.

Das ist keine reine IT-Frage. Es ist eine Führungsentscheidung mit Folgen für Budget, Personal und Haftung. Eine Standardplattform senkt den eigenen Betriebsaufwand. Eine Eigenentwicklung verschiebt diesen Aufwand in Ihr Haus: Releases, Sicherheit, Fehlerbehebung, Weiterentwicklung und personelle Absicherung.

Unter diesen Bedingungen kann Eigenentwicklung funktionieren. Sie ist dann eine bewusste Entscheidung zur dauerhaften Betriebsverantwortung, keine rein technische Freiheitsfrage.

Entscheidungstabelle: Datenlage, Servicevolumen und empfohlener Weg

Die folgende Tabelle ordnet die Entscheidung nach Datenlage, Anfragevolumen und Betriebsfähigkeit.

Fazit: Wählen Sie das Portalmodell, das Ihre Organisation dauerhaft trägt

Die wichtigsten Erkenntnisse für Geschäftsführung, IT und Serviceleitung

Nach dem Vergleich von Datenlage, TCO und Betriebsaufwand bleibt am Ende eine nüchterne Frage: Trägt das gewählte Portalmodell Ihren Alltag auch in drei oder fünf Jahren noch? Ein Kundenportal ist kein Projekt mit sauberem Endpunkt. Es ist ein Betriebsmodell mit dauerhafter Verantwortung für Wartung, Sicherheit, Releases und Fehlerbehebung.

Für Geschäftsführung, IT und Serviceleitung sind dabei drei Punkte maßgeblich:

• Ohne strukturierte, maschinengebundene Daten bleibt jedes Portal eine Oberfläche.
• Die größten Kosten fallen nach dem Go-live an: durch Updates, Releases und Fehlerbehebung. Bei Eigenentwicklung liegt diese Last vollständig bei Ihnen.
• Entscheidend ist, wer die Betriebsverantwortung dauerhaft und verlässlich trägt – weniger die Länge der Funktionsliste.

In der Praxis scheitern Portale selten an der ersten Version. Probleme entstehen später, wenn Daten fehlen, Zuständigkeiten unklar sind oder Anpassungen im Betrieb zu viel Zeit und Budget binden. Deshalb lohnt sich der Blick zuerst auf die Belastbarkeit des Modells und erst danach auf einzelne Funktionen.

Im strategischen Kontext hilft ein klares Reifegradbild. Das Modell Digitalisieren → Vernetzen → Entscheiden → Automatisieren macht sichtbar, wo Ihr Service heute steht und welche Form von Portalbetrieb dazu passt. Wer zu früh in die letzte Stufe springt, baut oft mehr Oberfläche als Nutzwert.

Nächster Schritt: Datenlage prüfen, bevor Sie ein Portalmodell wählen

Bevor Sie sich auf eine Architektur festlegen, sollten Sie die Datenbasis prüfen. Wie gut ist Ihre installierte Basis erfasst? Liegen Maschinendaten strukturiert und zentral vor, oder verteilen sie sich über PDFs, Dokumente und ERP-Systeme?

Genau hier setzt ein Installed Base Assessment an. Es prüft Datenreife, Serviceprozesse und Portalfähigkeit, bevor Sie eine Technologieentscheidung treffen. Das legt das eigentliche Risiko offen: die Lücke zwischen gewünschter Funktion und vorhandener Datenlage.

Zwei pragmatische Wege für den Einstieg:

• Installed Base Assessment – wenn Sie zuerst Datenreife, Serviceprozesse und Portalfähigkeit klären wollen, bevor eine Architektur feststeht.
• Erstgespräch – wenn Sie die Make-or-buy-Entscheidung für Ihr Servicegeschäft konkret durchsprechen wollen.