Gesamtbetriebskosten von Governance-Software: Änderungsaufwand und Update-Sicherheit bewerten

Bei der Auswahl einer Governance-Software bilden Lizenzpreis, Implementierung und Betrieb die Grundlage des wirtschaftlichen Vergleichs. Für eine Bewertung über mehrere Jahre sind zusätzlich die Kosten zu berücksichtigen, die durch fachliche, organisatorische und regulatorische Änderungen entstehen. Maßgeblich ist dabei, in welchem Umfang sich die Plattform konfigurieren lässt und ob kundenspezifische Anpassungen bei Produktupdates erhalten bleiben.

Neue Pflichtfelder, Rollen, Freigaben oder Berichte gehören zur Weiterentwicklung einer Governance-Organisation. Müssen solche Anforderungen regelmäßig durch den Hersteller programmiert werden, entstehen neben externen Entwicklungskosten auch interne Aufwände für Abstimmung, Beauftragung, Tests und Einführung. Ein niedriger Lizenzpreis kann deshalb mit höheren Gesamtbetriebskosten verbunden sein.

Änderungen während der Nutzungsdauer berücksichtigen

Softwareangebote weisen zunächst die unmittelbar erkennbaren Kosten aus: jährliche Lizenz, Implementierung, Hosting, Support sowie gegebenenfalls Schulung und Migration. Diese Positionen lassen sich vergleichsweise gut gegenüberstellen, erfassen jedoch nur einen Teil der wirtschaftlichen Auswirkungen einer mehrjährigen Plattformentscheidung.

Während der Nutzungsdauer verändern sich die Organisation und ihre Anforderungen. Neue Gesellschaften werden eingebunden, Zuständigkeiten angepasst und zusätzliche Sprachen benötigt. Zugleich können regulatorische Vorgaben, interne Prüfungen oder Anforderungen des Managements Änderungen an Datenmodellen, Abläufen und Auswertungen erforderlich machen.

Im Datenschutz betrifft dies beispielsweise die Struktur des Verzeichnisses von Verarbeitungstätigkeiten, eine angepasste Risikologik oder konzernweite Review-Prozesse mit lokalen Varianten. Hinzukommen können zusätzliche Freigaben bei der Einbindung von Dienstleistern, neue Kennzahlen, Prozesse für AI Governance, Anforderungen aus dem Informationssicherheitsmanagement oder ergänzende Nachweise für interne Audits.

Solche Anpassungen sind bei der wirtschaftlichen Bewertung als Bestandteil des laufenden Betriebs einzuordnen. Unternehmen sollten daher bereits vor der Auswahl prüfen, welche Änderungen durch eigene Administratoren vorgenommen werden können und welche eine Entwicklungsleistung des Anbieters voraussetzen.

Welche Kosten in eine TCO-Betrachtung gehören

Total Cost of Ownership (TCO) bezeichnet die Gesamtkosten über die Nutzungsdauer. Bei Governance-Software umfasst diese Betrachtung die Einführung, den laufenden Betrieb und die spätere Weiterentwicklung. Für einen strukturierten Vergleich lassen sich fünf Kostenblöcke unterscheiden:

Die Zuordnung dient dazu, die Kostenstruktur der Angebote vergleichbar zu machen. Ein Anbieter kann beim Vertragsabschluss günstiger erscheinen, während über mehrere Jahre erhebliche Aufwände für Änderungen hinzukommen. Umgekehrt kann eine höhere Lizenz wirtschaftlich vertretbar sein, wenn die Kosten für Betrieb und Anpassungen entsprechend niedriger ausfallen.

Dabei sind die externen Leistungen des Anbieters und die internen Aufwände des Unternehmens gemeinsam zu betrachten. Eine Bewertung, die ausschließlich die ausgewiesenen Angebotspreise erfasst, lässt einen wesentlichen Teil der späteren Kosten unberücksichtigt.

Externe und interne Aufwände bei Change Requests

Eine zunächst begrenzte fachliche Anforderung kann mehrere zusammenhängende Änderungen auslösen. Wird beispielsweise ein neues Feld benötigt, ist möglicherweise zugleich festzulegen, für welche Gesellschaften es verpflichtend ist. Eine bestimmte Antwort soll eine Prüfung auslösen, bei hohem Risiko ist der Datenschutzbeauftragte einzubinden und das Management benötigt eine nach Ländern und Business Units filterbare Auswertung. Für eine französische Gesellschaft kann zusätzlich eine Sprachfassung erforderlich werden.

Soweit diese Anforderungen nur durch individuelle Entwicklung umsetzbar sind, folgen auf die fachliche Abstimmung regelmäßig Spezifikation, Angebot, Beauftragung, Entwicklung, Test, Releaseplanung, Bereitstellung und Dokumentation. Diese Schritte verursachen Aufwand, auch wenn die technische Änderung selbst überschaubar erscheint.

Innerhalb des Unternehmens sind daran gegebenenfalls mehrere Stellen beteiligt. Fachbereiche beschreiben den Bedarf, Datenschutz oder Compliance konkretisieren die Anforderungen, die IT prüft Auswirkungen, der Einkauf beauftragt die Leistung und das Projektmanagement koordiniert die Umsetzung. Anschließend müssen Anwender testen und die Dokumentation angepasst werden.

Entwicklungsleistungen sind dabei als regulärer Kostenbestandteil zu berücksichtigen. Für die Wirtschaftlichkeit ist jedoch relevant, wie häufig sie für die laufende fachliche Weiterentwicklung benötigt werden. Wird jede Änderung auf diesem Weg umgesetzt, können sich auch moderate Einzelkosten über die Nutzungsdauer erheblich summieren.

Konfigurierbarkeit als wirtschaftliches Bewertungskriterium

No-Code kann es ermöglichen, fachliche Änderungen ohne individuelle Programmierung vorzunehmen. Bei Governance-Systemen betrifft dies insbesondere die Anpassung von Datenfeldern, Rollen, Formularen, Fragebögen, Workflows und Auswertungen. Der wirtschaftliche Nutzen hängt davon ab, welche dieser Elemente tatsächlich konfigurierbar sind und welcher Aufwand dafür entsteht.

Kann ein entsprechend qualifizierter Administrator eine Anforderung innerhalb weniger Stunden umsetzen, ergibt sich eine andere Kosten- und Zeitstruktur als bei einem mehrwöchigen Entwicklungsprojekt. Dies kann externe Entwicklungskosten, Wartezeiten und interne Projektaufwände reduzieren. Zugleich kann die Organisation bei der Weiterentwicklung ihrer Prozesse unabhängiger vom Hersteller werden.

Die allgemeine Angabe, eine Software sei „anpassbar“, reicht für die Bewertung deshalb nicht aus. Sie kann sowohl eine kostenpflichtige Herstellerentwicklung als auch eine eigenständig durchführbare Konfiguration bezeichnen. Im Auswahlverfahren ist zu klären, wer welche Elemente ändern kann, welche Kenntnisse dafür erforderlich sind und wie sich die Änderungen auf zukünftige Updates auswirken.

Für eine Enterprise-Governance-Plattform sind insbesondere folgende Konfigurationsmöglichkeiten zu prüfen:

• Felder und Pflichtfeldlogik: Ergänzung von Informationen sowie bedingte Pflichtangaben abhängig von Risiko, Rolle, Gesellschaft, Prozessstatus oder anderen Angaben.
• Rollen und Berechtigungen: Anpassung von Verantwortlichkeiten und Sichtrechten an die jeweilige Organisation.
• Workflows und Freigaben: Änderung von Prüf-, Review- und Freigabeabläufen einschließlich zusätzlicher Genehmigungsschritte.
• Fristen und Eskalationen: Konfiguration von Erinnerungen, Fristen und Eskalationswegen.
• Formulare und Fragebögen: Weiterentwicklung fachlicher Abfragen ohne gesondertes Produktrelease.
• Reports: Anpassung von Auswertungen und zusätzlichen Auswertungsdimensionen.
• Organisation und Mehrsprachigkeit: Einbindung weiterer Gesellschaften, Standorte, Teams und Business Units sowie zusätzlicher Sprachfassungen.
• Regulatorische Anpassungen: Änderung der betroffenen Governance-Prozesse, wenn neue Anforderungen zu berücksichtigen sind.

Diese Möglichkeiten sind jeweils anhand der konkreten Anforderungen des Unternehmens zu bewerten. Für die Wirtschaftlichkeit ist maßgeblich, in welchem Umfang die im laufenden Betrieb zu erwartenden Änderungen damit abgedeckt werden können.

Update-Sicherheit und Erhalt kundenspezifischer Konfigurationen

Konfigurierbarkeit ist wirtschaftlich nur eingeschränkt nutzbar, wenn kundenspezifische Anpassungen nach einem Produktupdate erneut erstellt oder umfassend überarbeitet werden müssen. Neben den Möglichkeiten zur Änderung ist deshalb zu prüfen, wie sich diese Anpassungen bei späteren Releases verhalten.

Eine klare Trennung zwischen Produktstandard und kundenspezifischer Konfiguration soll ermöglichen, den Standard weiterzuentwickeln und bestehende Konfigurationen zu erhalten. Neue Produktfunktionen sollen genutzt werden können, ohne bereits eingerichtete Prozesse jeweils neu aufzubauen.

Fehlt diese Trennung, können zusätzliche Aufwände entstehen. Nach einem Update ist dann zu klären, welche Anpassungen weiterhin funktionieren, welche überschrieben wurden und welche neu entwickelt werden müssen. Im ungünstigen Fall erschweren oder verhindern kundenspezifische Änderungen ein Upgrade. Damit können aus der Individualisierung technische Abhängigkeiten und wiederkehrende Folgekosten entstehen.

Unternehmen sollten daher konkret erfragen, welche Konfigurationen erhalten bleiben, welche Regressionstests erforderlich sind und ob bestimmte Anpassungen zukünftige Releases blockieren können. Update-Sicherheit ist in diesem Zusammenhang ein Kriterium für den Erhalt der bereits getätigten Investitionen.

Vereinfachtes Kostenbeispiel über fünf Jahre

Die Bedeutung späterer Anpassungen lässt sich anhand eines vereinfachten Rechenbeispiels darstellen. Die folgenden Beträge sind Beispielannahmen:

Auf dieser Grundlage beträgt der Kostenvorteil von Anbieter A zunächst 170.000 Euro. Für die weitere Betrachtung wird angenommen, dass bei Anbieter A in jedem der vier Betriebsjahre nach dem Einführungsjahr folgende externe Änderungskosten entstehen:

• Vier kleinere Change Requests zu jeweils 8.000 Euro: insgesamt 32.000 Euro.
• Eine größere Workflow-Anpassung: 25.000 Euro.
• Anpassungen an Reports: 10.000 Euro.

Die externen Änderungskosten belaufen sich damit auf 67.000 Euro jährlich und auf 268.000 Euro über vier Jahre. Zusammen mit Lizenz und Implementierung ergeben sich für Anbieter A 698.000 Euro. Interne Aufwände, etwa für zusätzliche Release-Tests und Abstimmung, sind darin noch nicht enthalten.

Bei Anbieter B stehen dem zunächst 600.000 Euro für Lizenz und Implementierung gegenüber. Die Kosten der dort erforderlichen Konfigurationen und die internen Aufwände sind zusätzlich zu berücksichtigen. Lassen sich dieselben Änderungen mit ausreichend geringem Aufwand konfigurieren, kann sich der ursprüngliche Kostenvorteil von Anbieter A umkehren.

Das Beispiel stellt keine vollständige TCO-Berechnung dar, verdeutlicht jedoch, weshalb ein belastbarer Vergleich auch Annahmen über die Häufigkeit und den Aufwand späterer Änderungen benötigt. Aus der Konfigurierbarkeit allein lässt sich noch keine bestimmte Kostenersparnis ableiten.

Anforderungen an die wirtschaftliche Bewertung im RFP

Bei einer mehrjährigen Plattformentscheidung lassen sich zukünftige Anforderungen nur begrenzt vorwegnehmen. Im Request for Proposal (RFP) sollte deshalb neben der Abbildung bestehender Prozesse auch deren spätere Änderung behandelt werden. Die Antworten müssen erkennen lassen, welche Leistungen im Standard enthalten sind und wann zusätzliche Kosten entstehen.

Für die Bewertung kommen insbesondere folgende Fragen in Betracht:

Konfiguration

Welche Felder können Administratoren selbst ergänzen? Lassen sich Pflichtfelder, bedingte Logiken, Workflows, Freigabeschritte, Erinnerungen und Eskalationen ohne Programmierung ändern?

Rollen und Rechte

Können eigene Rollen erstellt und Berechtigungen objekt-, status- oder organisationsbezogen angepasst werden?

Reporting

Welche Reports und Dashboards kann der Kunde selbst konfigurieren? Für welche Änderungen ist eine Leistung des Herstellers erforderlich?

Organisation

Wie werden neue Gesellschaften, Teams, Standorte und Business Units ergänzt? Welche zusätzlichen Implementierungskosten entstehen dabei?

Updates

Welche kundenspezifischen Konfigurationen bleiben bei Produktupdates erhalten? Welche Regressionstests sind erforderlich? Können Anpassungen ein zukünftiges Release blockieren?

Change Requests

Welche Änderungen gehören zur Standardkonfiguration und welche werden gesondert berechnet? Wie erfolgt die Abrechnung und mit welchen durchschnittlichen Vorlaufzeiten ist zu rechnen?

Administration

Welche Konfigurationen kann der Kunde eigenständig durchführen? Welche Qualifikation benötigen Administratoren und in welchen Fällen ist Entwicklerwissen erforderlich?

Diese Fragen sind vor Vertragsabschluss in die wirtschaftliche Bewertung einzubeziehen. Sie betreffen die laufenden Kosten, die Dauer späterer Anpassungen und die Abhängigkeit vom Anbieter.

Produktroadmap und Weiterentwicklung des Standards

Auch die Produktstrategie kann die Gesamtbetriebskosten beeinflussen. Werden fachliche Anforderungen im Standardprodukt weiterentwickelt, kann dies den Bedarf an kundenspezifischen Projekten verringern. Werden Erweiterungen dagegen überwiegend individuell umgesetzt, trägt der jeweilige Kunde die damit verbundenen Entwicklungskosten weitgehend selbst.

Im Auswahlverfahren sollte deshalb geklärt werden, welche Funktionen in den Standard aufgenommen werden sollen, wie häufig Releases erscheinen und wie regulatorische Änderungen berücksichtigt werden. Ebenso ist relevant, welche Erweiterungen allen Kunden zugutekommen und wie der Anbieter zwischen allgemeiner Produktentwicklung und kundenspezifischen Leistungen unterscheidet.

Die Roadmap ist damit als Bestandteil der Kostenbetrachtung einzuordnen, weil sie Hinweise darauf gibt, in welchem Umfang die Weiterentwicklung des Produkts spätere individuelle Anpassungen entbehrlich machen kann.

Kontrollierte Administration und zeitliche Anforderungen

Die Möglichkeit zur eigenständigen Konfiguration setzt geregelte Zuständigkeiten voraus. Nicht jeder Benutzer sollte Workflows, Pflichtfelder oder Berechtigungen verändern können, weil eine fehlerhafte Konfiguration die vorgesehenen Prüf- und Freigabeabläufe beeinträchtigen kann.

Unternehmen sollten deshalb festlegen, wer Änderungen vornehmen darf und wer sie prüft. Bei der Plattformbewertung ist außerdem zu klären, ob Konfigurationsänderungen versioniert werden, welche Testmöglichkeiten bestehen und ob eine frühere Konfiguration wiederhergestellt werden kann. No-Code verändert die Art der Umsetzung; die Notwendigkeit einer kontrollierten Administration bleibt bestehen.

Daneben ist die Umsetzungsdauer als wirtschaftlicher Faktor zu berücksichtigen. Muss eine regulatorisch bedingte Prozessänderung kurzfristig umgesetzt werden, kann die vorherige Beauftragung eines Herstellerprojekts zu Verzögerungen führen. Vergleichbare Abhängigkeiten können bei internen Organisationsänderungen oder zusätzlichen Anforderungen aus Audits entstehen.

Die wirtschaftlichen Folgen einer Verzögerung können über den Preis des Change Requests hinausgehen. Änderungsfähigkeit ist daher auch im Hinblick darauf zu bewerten, ob erforderliche Anpassungen innerhalb der jeweils maßgeblichen Fristen möglich sind.

Anforderungen an eine Plattform wie Ailance

Die beschriebenen Kriterien sind auch bei einer Plattform wie Ailance anzulegen. Governance-Prozesse bestehen aus Objekten, Feldern, Rollen, Workflows, Entscheidungen, Aufgaben, Reviews, Reports und den Beziehungen zwischen diesen Elementen. Soweit diese Bestandteile kontrolliert konfiguriert werden können, lässt sich der Bedarf an individuellen Entwicklungsprojekten für fachliche Änderungen begrenzen.

Ziel ist ein Standardprodukt mit Konfigurationsmöglichkeiten, die bei späteren Updates erhalten bleiben. Neue Anforderungen sollen auf der bestehenden Plattform umgesetzt werden können, ohne deren weitere Produktentwicklung zu blockieren. Bei langfristigen Enterprise-Einführungen ist dieses Verhältnis zwischen Standard, kundenspezifischer Ausgestaltung und Update-Sicherheit besonders zu berücksichtigen.

Praktische Prüfung im Auswahlverfahren

Die Bewertung sollte die Perspektiven von Fachbereich, Einkauf, IT und Unternehmensleitung zusammenführen. Während der Fachbereich die Abbildung seiner Prozesse beurteilt, betrachtet der Einkauf die Preise und die IT den Betrieb sowie die Integration. Für die Finanzverantwortlichen sind die Gesamtkosten über mehrere Jahre relevant; aus Sicht der IT-Leitung ist zusätzlich die künftige Abhängigkeit vom Anbieter zu bewerten.

Zur Konkretisierung können fünf Anforderungen aus dem laufenden Betrieb herangezogen werden:

1. Ein neues Pflichtfeld wird ergänzt.
2. Eine bestimmte Antwort löst eine zusätzliche Prüfung aus.
3. Eine weitere freigabeberechtigte Person wird in einen Workflow eingebunden.
4. Das Management benötigt einen neuen Report.
5. Eine Tochtergesellschaft benötigt eine lokale Variante eines Prozesses.

Für jede Anforderung ist zu klären, ob das Unternehmen sie selbst umsetzen kann, wie lange die Änderung dauert, welche Kosten entstehen und ob ein Herstellerprojekt erforderlich ist. Zusätzlich ist zu prüfen, wie sich die geänderte Konfiguration beim nächsten Produktupdate verhält.

Diese Prüfung macht die wirtschaftlichen Folgen der angebotenen Anpassungsmöglichkeiten konkreter und ergänzt den Vergleich der vorhandenen Funktionen um den Aufwand für deren spätere Weiterentwicklung.

Einordnung für die Beschaffungsentscheidung

Ein niedriger Einstiegspreis kann mit günstigen Gesamtbetriebskosten verbunden sein, wenn die Plattform ausreichend konfigurierbar ist und der laufende Betrieb geringe Aufwände verursacht. Ebenso kann eine höhere Lizenz durch niedrigere Änderungskosten wirtschaftlich gerechtfertigt sein. Ein höherer Preis begründet für sich genommen keine bessere Wirtschaftlichkeit.

Für die Beschaffungsentscheidung sind daher die Kostenstruktur über die Nutzungsdauer, die erwartbaren Änderungen und die damit verbundenen Abhängigkeiten maßgeblich. Konfigurierbarkeit, Update-Sicherheit und Produktroadmap gehören in diese Bewertung, weil sie beeinflussen, mit welchem Aufwand das Unternehmen seine Governance-Prozesse später weiterentwickeln kann.

Fragen und Antworten

Wie bewertet man die Gesamtbetriebskosten von Governance-Software?

Zu berücksichtigen sind Lizenz, Einführung und Betrieb sowie die Kosten für Änderungen, Updates und organisatorische Erweiterungen. Externe Leistungen und interne Aufwände sollten über denselben Betrachtungszeitraum erfasst werden.

Warum reicht der Lizenzpreis für einen Softwarevergleich nicht aus?

Nach der Einführung können zusätzliche Kosten für fachliche Anpassungen, Tests und Administration entstehen. Häufige Änderungen können den ursprünglichen Preisvergleich über mehrere Jahre wesentlich verändern.

Welche Folgekosten können bei Governance-Software entstehen?

Dazu gehören Change Requests, kundenspezifische Entwicklung, Regressionstests nach Updates, zusätzliche Reports, Workflow-Anpassungen, neue Rollen, weitere Sprachfassungen und regulatorisch bedingte Anpassungen.

Unter welchen Voraussetzungen kann No-Code die TCO reduzieren?

Wenn benötigte Änderungen ohne individuelle Softwareentwicklung konfiguriert werden können, lassen sich externe Entwicklungskosten und interne Projektaufwände begrenzen. Der tatsächliche Konfigurationsaufwand bleibt zu berücksichtigen.

Warum ist Update-Sicherheit wirtschaftlich relevant?

Bleiben kundenspezifische Konfigurationen bei Produktupdates erhalten, müssen bereits eingerichtete Prozesse nicht bei jedem Release neu erstellt werden. Zu prüfen ist zugleich, welche Tests und Anpassungen weiterhin erforderlich sind.

Welche Änderungen sollten ohne Entwicklungsprojekt möglich sein?

In Betracht kommen insbesondere Felder, Pflichtfeldlogiken, Rollen, Workflows, Freigaben, Erinnerungen, Eskalationen und Fragebögen sowie möglichst viele Reporting-Anpassungen. Der erforderliche Umfang richtet sich nach den Prozessen des Unternehmens.

Welche Fragen gehören zu Change Requests in ein RFP?

Zu klären sind die Abgrenzung zur Standardkonfiguration, die durch den Hersteller auszuführenden Leistungen, die Abrechnung und die üblichen Vorlaufzeiten.

Welche Bedeutung hat die Produktroadmap für die TCO?

Die Weiterentwicklung des Standards kann kundenspezifische Projekte entbehrlich machen. Relevant ist, welche Funktionen und regulatorisch bedingten Anforderungen in das Standardprodukt einfließen sollen.

Ist eine teurere Governance-Plattform automatisch wirtschaftlicher?

Nein. Maßgeblich ist die Gesamtkostenstruktur über die Nutzungsdauer. Eine günstigere Plattform kann bei ausreichender Konfigurierbarkeit und niedrigen Betriebskosten wirtschaftlich überlegen sein.

Welche Frage steht bei der Bewertung späterer Änderungen im Mittelpunkt?

Zu klären ist, welcher externe und interne Aufwand entsteht, wenn sich ein abgebildeter Prozess ändert, und ob die Anpassung bei zukünftigen Updates erhalten bleibt.