Kundenportal an SAP anbinden: Architektur und Aufwand

Ein Kundenportal schafft dann Entlastung, wenn es konkrete Rückfragen und manuelle Arbeitsschritte übernimmt. Für die Planung sollten Vertrieb, Kundenservice und IT zunächst festhalten, welche Informationen Kunden heute per E-Mail anfordern: Auftragsstatus, Rechnungen, Liefertermine oder kundenspezifische Dokumente. Daraus entsteht ein begrenzter erster Nutzungsumfang. Ein Portal muss nicht alle ERP-Funktionen abbilden. Entscheidend ist, dass die ausgewählten Informationen verlässlich sind und zur richtigen Kundenorganisation gehören.

Ausgangslage und Projektgrenzen

• Trennen Sie reine Belegauskunft von Bestellungen, Reklamationen und Änderungen an Stammdaten; jeder schreibende Prozess benötigt eine eigene Freigabe.
• Benennen Sie Kundenorganisationen, Niederlassungen und Ansprechpartner, damit der Portalzugang zu den tatsächlichen Geschäftsbeziehungen passt.
• Erfassen Sie Rückfragen zu Lieferterminen oder Rechnungen getrennt: Häufigkeit und Klärungsaufwand bestimmen, welcher Self-Service zuerst Nutzen bringt.

Die Architektur beginnt bei der tatsächlichen SAP-Version und den verfügbaren, freigegebenen Schnittstellen. Eine Middleware kann das Portal vom ERP entkoppeln, Datenmodelle übersetzen und Ausfälle abfedern. Legen Sie fest, welches System führend ist, wie aktuell eine Anzeige sein muss und wie ein erneuter Auftrag nach einem Timeout erkannt wird. Die Anmeldung am Portal ersetzt keine Prüfung der Kunden- und Belegberechtigung im Backend.

Architektur, Risiken und Aufwandstreiber

• Ordnen Sie jedem angezeigten Wert ein führendes SAP-Objekt, eine erlaubte Aktualitätsgrenze und ein Verhalten bei fehlenden Daten zu.
• Prüfen Sie die freigegebenen SAP-Schnittstellen im konkreten System.

Ein vorhandener Endpunkt belegt noch nicht, dass alle benötigten Felder zugänglich sind.

• Trennen Sie Login und Belegberechtigung.

Ein serverseitiger Organisationsfilter muss auch Downloads, Suchergebnisse und zwischengespeicherte Antworten erfassen.

Ein mögliches Umsetzungsszenario ist der Einstieg mit lesendem Belegzugriff. Kunden erhalten ausschließlich Dokumente ihrer Organisation; zeitlich begrenzte Downloadlinks werden nach erfolgreicher Berechtigungsprüfung erzeugt. Erst in einer nächsten Ausbaustufe kommen Bestellungen oder Reklamationen hinzu. Für jeden schreibenden Vorgang werden fachliche Validierung, Rückmeldung und Wiederholung definiert. Dieses Beispiel beschreibt einen Architekturansatz und keine zusätzliche GSWE-Kundenreferenz.

Konkrete Prüffälle für den ersten Release

• Ein Kunde verändert die Belegnummer in einer Downloadanfrage. Das Portal darf dadurch keinen Beleg einer anderen Kundenorganisation herausgeben.
• SAP ist vorübergehend nicht erreichbar. Eine zwischengespeicherte Statusanzeige kennzeichnet ihren Stand; eine verbindliche Bestellung wird nicht fälschlich bestätigt.
• Eine Bestellantwort geht verloren. Ein erneuter Aufruf muss den ursprünglichen Vorgang erkennen und darf keinen zweiten Auftrag auslösen.

Prüfen Sie außerdem Testsysteme, interne Ansprechpartner und Einschränkungen bei ERP-Releases. Abnahmekriterien sollten konkrete Fälle enthalten: fremde Belege sind nicht abrufbar, ein ERP-Ausfall wird verständlich angezeigt, doppelt gesendete Aktionen erzeugen keinen zweiten Auftrag und der Support kann fehlerhafte Übertragungen nachvollziehen.

Für die Beauftragung sollten Sie drei Zugriffsarten getrennt abnehmen: Belege lesen, Stammdaten ändern und Bestellungen auslösen. Vereinbaren Sie je Vorgang eine eindeutige Kundenorganisation, die zulässige Datenaktualität und das Verhalten bei einem SAP-Ausfall. Lassen Sie sich den gleichen Test mit zwei unterschiedlichen Kundenkonten zeigen. Damit wird sichtbar, ob das Portal Daten tatsächlich im Backend trennt oder lediglich in der Oberfläche ausblendet.

Lassen Sie den Anbieter einen vollständigen Vorgang vom Portal bis zur ERP-Rückmeldung demonstrieren. Eine reine Oberflächenpräsentation zeigt nicht, ob Berechtigungen, Belegzuordnung und Fehlerbehandlung zusammen funktionieren. Vereinbaren Sie außerdem, wer Stammdatenprobleme klärt und wie Kunden nach einer fehlgeschlagenen Übertragung weiterarbeiten.

Entscheidungshilfe für die Beauftragung

• Fordern Sie eine Zuordnung von Portalaktionen zu SAP-Objekten sowie ein Rollenmodell für Kundenadministratoren, Mitarbeitende und interne Bearbeiter.
• Nehmen Sie Testmandant, Schnittstellenfreigaben und Verantwortliche für ERP-Anpassungen als Voraussetzungen in die Aufwandsschätzung auf.
• Vereinbaren Sie, wie Statusrückfragen, abgewiesene Zugriffe und fehlgeschlagene Bestellungen nach dem Start nachvollzogen werden.

Für ein vergleichbares Angebot

• SAP-System, verfügbare Schnittstellen und die ersten Self-Service-Vorgänge benennen.
• Kundenorganisationen, Ansprechpartner und zulässige Belegzugriffe eindeutig zuordnen.
• Mandantenfremde Belege, verzögerte SAP-Antworten und Änderungen an Stammdaten testen.

Der wirtschaftlich sinnvolle Einstieg ist meist ein klar abgegrenzter Self-Service-Prozess mit verlässlicher SAP-Anbindung. Eine zusätzliche Oberfläche allein reduziert noch keinen Abstimmungsaufwand. Erst Datenqualität, Rechteprüfung und ein definierter Betriebsprozess machen das Portal zu einem belastbaren Teil der Kundenbetreuung. Erfolg lässt sich etwa an manuellen Statusanfragen, Nutzungsquoten und der Bearbeitungsdauer konkreter Vorgänge messen.

Nutzen bewerten und den Ausbau begrenzen

• Bewerten Sie den Anteil selbst gelöster Status- und Beleganfragen und erfassen Sie, welche Rückfragen weiterhin beim Kundenservice landen.
• Prüfen Sie vor zusätzlichen Bestellfunktionen, ob Benutzerzuordnung, Belegzugriff und Datenaktualität im lesenden Portal zuverlässig funktionieren.
• Berücksichtigen Sie Pflegeaufwand für Benutzer und Kundenorganisationen: Ein Self-Service-Portal benötigt weiterhin fachlich verantwortliche Betreuung.

Wählen Sie die erste Aufgabe, die Ihre Kunden ohne Rückfrage in SAP erledigen sollen. GSWE prüft mit Ihnen Datenzugriff und Rollenmodell als Einstieg in die Entwicklung des Kundenportals.

Ein SAP-Kundenportal entwickeln lassen: Kundenportal an SAP per API anbinden.