©BeNeering

In vielen Softwareprojekten wird Total Cost of Ownership (TCO) implizit mit den Lizenz- bzw. Abonnementkosten gleichgesetzt. Moderne Lösungen werden fast durchgängig im Jahresabonnement angeboten – der Vergleich fällt leicht, die Entscheidung scheint klar. Diese Kosten bilden jedoch längst nicht das gesamte Bild ab – in der Praxis können zusätzliche, häufig übersehene Kostenfaktoren die eigentlichen Abonnementkosten deutlich übersteigen. Von einer TCO-orientierten Sicht kann man erst sprechen, wenn weitere Kostenblöcke berücksichtigt werden: Implementierungsaufwände, Integrationskosten – inklusive zusätzlicher Softwarekomponenten –, laufender Betrieb, Wartung und notwendige Weiterentwicklungen. Hinzu kommen interne Kapazitäten, die durch Betrieb, Fehlerbehebung und Releasewechsel gebunden werden. Zwei Lösungen mit vergleichbarer Subskription können deshalb völlig unterschiedliche Gesamtbetriebskosten verursachen.

Für Unternehmen, die SAP ERP und S/4HANA einsetzen, ist die Rolle des ERP als führendes System (System of Record) zentral: Stammdaten, Transaktionen, Berechtigungen und Geschäftsregeln werden hier gepflegt und müssen in Beschaffungsprozessen konsistent wiederverwendet werden. Werden die tatsächlichen Kosten der Integration in SAP ERP nicht bereits frühzeitig bei der Auswahl zusätzlicher Lösungen berücksichtigt, verlagert sich die Komplexität in die Integrationsschicht – mit entsprechenden Auswirkungen auf Projektlaufzeiten, Prozessstabilität und den TCO.

Implementierung und Standardfähigkeit als Kostentreiber

Implementierung ist einer der sichtbarsten TCO-Blöcke – und gleichzeitig einer der variabelsten. In der Praxis reichen die Spannweiten von Projekten, die in rund hundert Tagen live gehen, bis zu Vorhaben, für die mehrere hundert oder gar tausend Beratungstage angesetzt werden. Entscheidend ist weniger die abstrakte Komplexität des Unternehmens, sondern die Frage, wie leistungsfähig die Lösung im Standard ist.

Je mehr Beschaffungsprozesse – einschließlich kundenspezifischer Besonderheiten – ohne zusätzliche Entwicklungen abgebildet werden können, desto geringer fallen Implementierungsaufwand und spätere Anpassungen aus. Umgekehrt führt ein enger „Fit-to-Standard“-Ansatz dazu, dass Abweichungen vom vorgegebenen Prozess schnell in individuelle Erweiterungsprojekte münden. Viele Unternehmen unterschätzen die daraus entstehenden Entwicklungs-, Test- und Wartungsaufwände über den gesamten Lebenszyklus einer Lösung.

Für die Ausschreibungspraxis bedeutet dies: Es reicht nicht aus, auf allgemeine Aussagen zur „Standardfähigkeit“ zu vertrauen. Beschaffungsorganisationen sollten gezielt hinterfragen, welche Prozesse im Auslieferungszustand unterstützt werden, wie mit abteilungs- oder länderspezifischen Abläufen umgegangen wird und welche Erfahrungswerte es zu typischen Projektlaufzeiten in vergleichbaren Umgebungen gibt. Dies erfordert in der Regel eine frühzeitige Einbindung des Anbieters, detaillierte Produktdemonstrationen, eine sorgfältige Prüfung der Anforderungen sowie Referenzprüfungen.

Integrationsarchitektur, Middleware und Datenkopien

Der zweite große TCO-Block ist die Integration. Kaum eine Beschaffungslösung läuft isoliert; sie muss mit einem ERP wie etwa SAP und weiteren Systemen Daten austauschen. In klassischen Architekturen wird dazu eine zusätzliche Integrationsschicht aufgebaut: Das ERP übermittelt Stammdaten, Organisationsstrukturen und Transaktionen an die Beschaffungsapplikation. Diese liefert wiederum Bestellungen, Wareneingänge oder Rechnungsdaten zurück an das ERP – häufig auf Basis periodischer Datenkopien.

Technisch wäre ein Abgleich in sehr kurzen Intervallen möglich, was aber mit hohen Infrastruktur- und Lizenzkosten verbunden ist. In der Praxis wird daher oft nur einmal täglich oder seltener synchronisiert. Ändern sich Daten im ERP zwischen zwei Läufen – etwa wenn ein Lieferant oder eine Kostenstelle gelöscht oder eine Lieferadresse angepasst wird –, entsteht ein Bruch: Die Beschaffungslösung arbeitet mit veralteten Informationen, Integrationsprozesse schlagen fehl, und Vorgänge bleiben in der Middleware hängen. Solche Fehler müssen im Integrationsmonitoring manuell bereinigt werden, binden Zeit und bergen zusätzlich Compliance-Risiken, wenn auf Basis falscher Daten bestellt wird.

Ein Architekturansatz, der konsequent auf das ERP als führendes System setzt und ohne zusätzliche Middleware zwischen Beschaffungslösung und SAP auskommt, reduziert diese Effekte erheblich. Damit entfallen nicht nur Lizenz- und Betriebskosten für eine zusätzliche Integrationsplattform, sondern auch ein großer Teil des aufwändigen Integrationsmonitorings. Daten werden nicht doppelt gehalten, Aktualisierungen greifen unmittelbar im führenden System, und die Fehleranfälligkeit an den Schnittstellen sinkt.

Veraltete Informationen in nachgelagerten Systemen erhöhen nicht nur den Aufwand, sondern auch das Risiko, finanzielle Vorgaben zu verfehlen. ERP-nahe Ansätze mit wenigen Datenkopien erhöhen die Prozesssicherheit und reduzieren Korrekturen.

Betrieb, Wartung und Skills: Aufwand im Alltag sichtbar machen

Nach dem Go-Live beginnt der längste Abschnitt des Softwarelebenszyklus – und oftmals der teuerste. Im laufenden Betrieb fallen Aufgaben an, die in TCO-Kalkulationen häufig nur pauschal berücksichtigt werden, wie das Monitoring von Schnittstellen, die Bearbeitung von Fehlermeldungen, Anpassungen an geänderte Prozesse, Tests und das Rollout von Releases. Je mehr Komponenten und Technologien beteiligt sind, desto höher ist der laufende Aufwand.

Ein weiterer Faktor sind die benötigten Skills. Unterschiedliche Technologien erfordern unterschiedliche Qualifikationen – eine Person, die SAP betreut, kann nicht automatisch eine separate Middleware oder proprietäre Plattformen administrieren. Ein deutlicher TCO-Vorteil entsteht dort, wo Implementierung, Setup, Betrieb und Weiterentwicklung einer Beschaffungslösung von denselben Teams verantwortet werden können, die bereits das ERP betreuen.

Für Beschaffungsorganisationen lohnt es sich daher, den laufenden Aufwand konkret zu beziffern: Wie viele Stunden pro Woche fließen in Monitoring und Fehlerkorrektur? Welche Aufgaben kann die interne IT leisten, und wo müssten dauerhaft externe Partner eingebunden werden? Welche neuen Technologien werden eingeführt – und welche Skills sind dafür notwendig?

Auswahlprozesse und Vergleichbarkeit: TCO in RFPs sichtbar machen

In Ausschreibungen werden häufig sehr unterschiedliche Ansätze miteinander verglichen: standardisierte, ERP-nahe E-Procurement-Lösungen auf der einen Seite und weitgehend individuelle Entwicklungen auf generischen Plattformen oder Low-Code-Stacks auf der anderen. Auf den ersten Blick lassen sich diese Wege über Lizenzpreise und Funktionslisten gegenüberstellen. In der TCO-Perspektive handelt es sich jedoch oft um „Äpfel und Birnen“: Ein hoher Anteil kundenspezifischer Entwicklung pro Projekt führt zu entsprechend hohen Implementierungs-, Wartungs- und Migrationskosten.

Spätere Überraschungen – sowohl im Projekt als auch im laufenden Betrieb – lassen sich deutlich reduzieren, wenn Unternehmen in ihren RFPs (Request for Proposals) funktionale, technische und betriebliche Anforderungen in einem detaillierten Katalog erfassen und mit potenziellen Anbietern Punkt für Punkt durchgehen. In solchen Auswahlprozessen werden nicht nur Funktionen diskutiert, sondern auch Integrationsprinzipien, notwendige Zusatzsoftware, Datenflüsse, Wartungsaufwände sowie erforderliche Kenntnisse und Fähigkeiten.

TCO-Fragen sollten daher fester Bestandteil jeder Ausschreibung sein: von der Zahl der Implementierungstage über die benötigte Integrationsarchitektur bis hin zu Betriebskonzept, Release-Management und Skillprofilen. Entscheidend ist nicht nur die schriftliche Antwort, sondern die gemeinsame Durchsprache und das kritische Hinterfragen von Annahmen.

Einordnung und Ausblick

TCO im digitalen Einkauf ist mehr als eine finanzielle Kennzahl – er spiegelt Architektur- und Organisationsentscheidungen wider. Ob eine Lösung wirtschaftlich betrieben werden kann, entscheidet sich daran, wie sie in die bestehende ERP-Landschaft eingebettet ist, wie viele zusätzliche Technologien und Datenkopien sie benötigt und wie aufwändig Implementierung, Integration und Betrieb ausfallen. Plattformen, die für SAP-basierte Landschaften konzipiert sind und eine direkte Kopplung an SAP ohne zusätzliche Middleware ermöglichen, können diese Aufwände spürbar reduzieren. Ein Beispiel ist die Digital Procurement Plattform von BeNeering [1]. Ihre Architektur ermöglicht einen Echtzeit-Datenaustausch mit SAP und deckt dabei sowohl Standard- als auch kundenspezifische Daten ab. Dadurch ist keine separate Integrationsschicht erforderlich. Implementierung und Anpassungen können mit vorhandenen SAP-Ressourcen umgesetzt werden, was den Bedarf an zusätzlichen spezialisierten Rollen reduziert.

Beschaffungsorganisationen, die den Blick über den Subskriptionspreis hinaus auf diesen Gesamtzusammenhang richten, schaffen eine belastbare Basis für ihre Digitalisierungsprojekte. Sie vermeiden unerwartete Folgekosten, halten ihre Architektur schlank und stellen sicher, dass Beschaffungsprozesse nicht nur funktional, sondern auch wirtschaftlich überzeugen – im Go-Live und im laufenden Betrieb über viele Jahre hinweg. Lösungen, die das ERP als System of Record konsequent nutzen, Middleware vermeiden und mit bestehenden ERP-Teams betrieben werden können, zeigen, wie sich Funktionstiefe und niedriger TCO verbinden lassen.

[1] https://www.beneering.com/

Disclaimer:
„Für den oben stehenden Beitrag sowie für das angezeigte Bild- und Tonmaterial ist allein der jeweils angegebene Nutzer verantwortlich. Eine inhaltliche Kontrolle des Beitrags seitens der Seitenbetreiberin erfolgt weder vor noch nach der Veröffentlichung. Die Seitenbetreiberin macht sich den Inhalt insbesondere nicht zu eigen.“