SAP im Haus, Berater zu teuer: Was darfst du selbst mit Access und Power Apps bauen?

Von /

Im Mittelstand höre ich oft denselben Satz: „SAP läuft, aber für jede Kleinigkeit ruft uns das Systemhaus einen Tagessatz auf.“ Eine Liste, die das Standardmenü nicht hergibt. Eine Auswertung über zwei Standorte. Ein kleines Erfassungstool für einen Prozess, den SAP gar nicht kennt. Und jedes Mal dieselbe Frage: Können wir das nicht selbst bauen, mit Bordmitteln, mit Access oder Power Apps?

Bei den meisten Altsystemen und ERPs lautet meine Antwort schlicht: ja. Bei SAP lautet sie: kommt darauf an, und zwar mehr als irgendwo sonst.

Warum SAP der Sonderfall ist

Mein Geschäft ist das Bauen um Altsysteme herum, nicht der Austausch. Bei einer alten Warenwirtschaft, bei Dynamics NAV, bei eGECKO ziehe ich Daten heraus, lege ein Auswertungs-Frontend daneben und synchronisiere dort, wo es nötig ist. Der Hersteller berechnet mir dafür nichts. Das Drumherum ist frei.

SAP ist die Ausnahme. SAP hat gegen genau diesen Trick eine Mautstelle eingebaut. Sie heißt Indirect Access.

Indirect Access bezeichnet jede Nutzung von SAP-Daten über ein Nicht-SAP-System, also über ein selbstgebautes Frontend statt über die SAP-Oberfläche. SAP wertet das vertraglich als Nutzung der eigenen Software, die lizenziert werden muss. Genau hier liegt der Denkfehler vieler Eigenbau-Ideen: Der technische Service-User, über den dein Frontend läuft, ist kein Schlupfloch. Er ist der Auslöser.

Die gute Nachricht: Die Maut steht nicht überall. Sie steht an einer bestimmten Stelle. Wer weiß, wo, kann den günstigen Teil gefahrlos selbst bauen. Die folgenden vier Stufen gehen von einfach und sicher bis schwer und teuer.

Stufe 1: Lesen und auswerten. Hier bist du sicher.

Das ist deine Heimatzone, und es ist gleichzeitig die unterschätzte. Du ziehst Daten aus SAP heraus, per OData oder RFC, kippst sie in einen SQL Server als Datendrehscheibe und baust darauf Auswertungen. Access-Masken, Excel-Reports, ein Standort-Dashboard. SAP wird zu einer Datenquelle unter mehreren, genau wie die anderen Altsysteme im Haus.

Lizenzrechtlich ist das der harmlose Teil. SAP rechnet das moderne Indirect-Access-Modell, „Digital Access“, nach erzeugten Geschäftsdokumenten ab, nicht nach Usern. Wer aus SAP nur liest, erzeugt keine abrechenbaren Belege. Reines Reporting bewegt keine Maut.

Ein ehrlicher Vorbehalt: Im alten Named-User-Sinn kann auch lesender Zugriff als „indirekte Nutzung“ gelten. Das ist eine Grauzone und hängt komplett am konkreten SAP-Vertrag. Praktisch ist das Risiko bei reinem Lesen aber gering, und es ist die Stelle, an der ein Mittelständler am meisten Systemhaus-Tagessätze spart.

Stufe 2: Ein Frontend neben SAP, das SAP nicht anfasst

Viele teure Spezialprozesse haben mit SAP gar nichts zu tun. Eine Schadenserfassung, ein Prüfprotokoll, eine Vor-Erfassung für die Werkstatt. SAP kann das nicht oder nur umständlich, und das Systemhaus baut es ungern, weil es klein ist.

Hier passt das klassische Spontan-Frontend: eine Access-Maske mit eigenem SQL Server dahinter, sauber für den Prozess gebaut. Die Ergebnisse landen erst später im DWH, neben den SAP-Daten, für die Gesamtauswertung. Solange dieses Frontend nichts in SAP zurückschreibt, berührt es die Maut nicht. Du baust neben dem System, nicht hinein.

Das ist exakt der ERP-Vermeider-Gedanke, nur eben im SAP-Umfeld: nicht das große System anfassen, sondern den Seitenprozess wirtschaftlich danebenstellen.

Stufe 3: Power Apps an SAP. Achtung, zweite Maut.

Jetzt wird es interessant, denn hier kommt eine zweite Mautstelle ins Spiel, und die hat nichts mit SAP zu tun, sondern mit Microsoft.

Power Apps hat einen SAP-ERP-Connector und einen neueren SAP-OData-Connector. Technisch ist das solide: Der ERP-Connector ruft RFC- und BAPI-Funktionen über ein On-Premises Data Gateway auf, der OData-Connector spricht die SAP-OData-Services an. Für den Aufbau brauchst du das Gateway, den SAP .NET Connector und einen gültigen SAP-S-User aus dem SAP-Team.

Der Haken: Beide sind Premium-Connectors. Premium bedeutet, jeder Nutzer, der die App anfasst, braucht eine kostenpflichtige Power-Apps-Lizenz. Nach aktueller Microsoft-Preisliste sind das rund 20 US-Dollar pro Nutzer und Monat im Per-User-Plan oder etwa fünf US-Dollar pro Nutzer, App und Monat im Per-App-Plan. Das Gateway selbst fällt ebenfalls in die Premium-Klasse.

Heißt konkret: Eine Power App auf SAP-Daten ist nie wirklich „kostenlos selbst gebaut“, selbst wenn sie nur liest. Du zahlst die Microsoft-Maut pro Kopf, oben drauf zur SAP-Frage. Wenn dir das zu viel Maut ist und du ohnehin Reporting willst, ist Access mit ODBC oder ein VBA-Zugriff direkt auf die OData-Endpunkte oft der ehrlichere Weg. Der umgeht die Microsoft-Lizenzschranke, kostet dich dafür mehr Eigenarbeit beim Anbinden.

Stufe 4: In SAP zurückschreiben. Hier wird es teuer und riskant.

Die letzte Stufe ist die, vor der ich am deutlichsten warne. Ein Frontend, das in SAP schreibt, also Aufträge, Bestellungen oder Buchungen anlegt, erzeugt genau die Dokumente, nach denen Digital Access abrechnet. SAP kennt dafür neun Kern-Dokumenttypen, darunter Verkaufsbelege, Bestellungen, Finanzbelege und Warenbewegungen. Gezählt wird pro erzeugtem Beleg, unabhängig davon, über welche Schnittstelle er entstanden ist.

Das ist die teure Falle. Du sparst die Systemhaus-Tagessätze beim Bauen und holst dir dafür ein Dokumentvolumen ins Haus, das beim nächsten SAP-Audit auf dem Tisch liegt. Und dieses Volumen schätzt man systematisch zu niedrig, weil eine einzige Nutzeraktion oft mehrere Belege auslöst. Aus genau diesem Grund hört man von Architekten den Satz: Lizenz-Clearance ist Schritt null, nicht Schritt zehn.

Das Risiko trägt zuerst der Kunde, in Form einer Nachforderung. Und damit, wenn der Eigenbau von außen kam, auch der, der ihn gebaut hat. Schreibende SAP-Frontends gehören deshalb nie ohne Lizenz-Klärung gebaut.

Wo dieser Ansatz an Grenzen stößt

Ich bin ehrlich: SAP ist nicht mein Heimatrevier. Ich habe es über 25 Jahre bewusst gemieden, weil mein Modell bei kleineren Branchensystemen und Eigenbauten besser greift. Dort baue ich frei drumherum. Bei SAP gilt die Maut, und ihre genaue Höhe steht im individuellen Vertrag, nicht in einem Blogartikel.

Daraus folgt eine klare Aufteilung. Lesende Auswertungen und Prozesse neben SAP kann ein erfahrener Datenmensch sauber selbst bauen. Alles Schreibende gehört mit jemandem zusammen gemacht, der SAP-Vermessung beherrscht. Wer beides vermischt, spart am Anfang und zahlt am Ende.

Was das für dein Geschäft heißt

Die günstige Zone ist real. Reporting, Auswertungen über mehrere Standorte, kleine Erfassungstools neben SAP: Das löst man oft um eine Größenordnung günstiger als das Sechs-Wochen-Angebot vom Systemhaus, und ohne dass jemand SAP selbst anfasst.

Die teure Zone braucht eine Rechnung vorher, nicht hinterher. Sobald ein Eigenbau in SAP schreibt, ist die Lizenzfrage Teil der Wirtschaftlichkeitsrechnung, nicht ein Detail für später. Faustregel: Lesen ist Sparpotenzial, Schreiben ist Verhandlungssache.

Wenn du in deinem Haus SAP hast und nicht sicher bist, auf welcher Stufe eine geplante Auswertung oder ein Tool eigentlich liegt, lohnt sich ein nüchterner Blick vorab. Wer das einmal einordnen lassen möchte, erreicht mich über sesoft.de/kontakt.

Quellen

Über den Autor

Sönke Schäfer ist selbstständiger IT-Berater und Datenarchitekt aus Sierksdorf in Ostholstein. Er baut seit über 25 Jahren mit Microsoft Access, VBA und SQL Server pragmatische Lösungen um bestehende Branchen- und ERP-Systeme herum, statt teurer Komplettmigrationen. Sein Schwerpunkt liegt auf der DWH-Klammer über mehrere Altsysteme und auf der Anbindung von Bestandsdaten, ohne das laufende System anzufassen. Mehr unter Datenschäfer, Sönke Schäfer.

Ähnliche Beiträge

Nach oben scrollen