Wie man einen Compliance-zentrierten Entwicklungsprozess aufbaut

Bei der Einführung eines neuen Systems wird die Compliance oft erst dann thematisiert, wenn die erste Version bereits fertiggestellt ist und rechtliche oder informationssicherheitsbezogene Prüfungen Mängel aufdecken. Dann folgen späte Änderungen, erneute Tests, unklare Verantwortlichkeiten und Verzögerungen beim Start. Die Frage ist daher nicht nur, wie man einen entwicklungszentrierten Compliance-Prozess aufbaut, sondern auch, wie man Compliance zu einem überprüfbaren Bestandteil des täglichen Betriebs macht, ohne die Entwicklung unnötig zu verlangsamen.

Compliance ist kein separates Dokumentenbündel. In einem Lagersystem bedeutet es, dass Bestandsbewegungen nachvollziehbar sind und nicht nachträglich spurlos geändert werden können. In einem E-Commerce-Prozess bedeutet es, dass die Verarbeitung personenbezogener Daten zweckgebunden und protokolliert ist. In der Produktion bedeutet es, dass eine Qualitätsabweichung, Genehmigung oder Rezepturänderung eindeutig einer verantwortlichen Rolle zugeordnet werden kann. Der gemeinsame Punkt ist in jedem Fall die Kontrollierbarkeit.

Compliance ist nicht das letzte Tor der Entwicklung

In vielen Unternehmen beginnt der Entwicklungsprozess mit einer einfachen Formel: Das Geschäft formuliert ein Bedürfnis, das Entwicklungsteam erstellt die Funktion, und jemand prüft, ob sie nutzbar ist. Dies funktioniert akzeptabel, wenn der Prozess mit wenigen Systemen verbunden ist, wenig Daten verarbeitet und ein Fehler keine ernsthaften betrieblichen oder vertraglichen Konsequenzen hat.

Bei wachsenden Unternehmen bleibt eine Änderung jedoch selten innerhalb der Grenzen einer einzigen Anwendung. Ein neuer Bestellstatus kann Auswirkungen auf den Webshop, das ERP, die Rechnungsstellung, die Kurierintegration und die Managementberichte haben. Wenn es keine klaren Regeln gibt, wer Daten ändern darf, welches System der Datenverantwortlicheist, was als genehmigte Änderung gilt und wie eine fehlerhafte Veröffentlichung zurückgesetzt werden kann, wird das Compliance-Risiko tatsächlich zu einem Betriebsrisiko.

Das Ziel ist also nicht, für jede Entwicklungsaufgabe unverhältnismäßige Bürokratie zu schaffen. Das Ziel ist, dass Entscheidungen, kritische Kontrollen und Prüfungsnachweise dort im Prozess vorhanden sind, wo sie wirklich benötigt werden.

Wie baut man einen compliance-zentrierten Entwicklungsprozess ausgehend vom Geschäftsprozess auf?

Der richtige Ausgangspunkt ist nicht die Richtlinie und auch nicht die Entwickler-Toolchain. Zuerst muss man verstehen, welches Geschäftsergebnis das System verarbeitet, wer Entscheidungen trifft, auf welcher Datenbasis und was passiert, wenn ein Schritt fehlerhaft ist oder fehlt.

Nehmen wir ein einfaches Beispiel: Ein Kundendienstmitarbeiter ändert die Lieferadresse einer Bestellung. Auf den ersten Blick scheint dies eine kleine Funktion zu sein. Die betrieblichen Fragen sind jedoch wichtig: Bis wann ist die Änderung zulässig, ist eine Begründung erforderlich, wer genehmigt bei Bestellungen mit hohem Wert, wird die Änderung an den Spediteur weitergeleitet und ist später ersichtlich, wer sie durchgeführt hat? Wenn es darauf keine Antworten gibt, kann der Entwickler höchstens ein Datenfeld und eine Speichertaste erstellen. Einen kontrollierten Prozess nicht.

Bei der Erkundung sollte bei jeder wesentlichen Änderung drei Dinge geklärt werden: Welche Verpflichtung oder interne Regel ist damit verbunden, welcher Fehler oder Missbrauch kann durch die Kontrolle verhindert werden und was wird der überprüfbare Nachweis sein, dass die Kontrolle funktioniert hat. Dies kann ein Berechtigungsprotokoll, ein Genehmigungsrekord, ein versioniertes Dokument, ein Testergebnis oder ein Wiederherstellungsprotokoll sein. Nicht in jedem Fall ist alles erforderlich, aber die Entscheidung muss bewusst getroffen werden.

Die Anforderungen müssen testbar sein

Sätze wie „soll sicher sein“ oder „soll den Vorschriften entsprechen“ sind als Entwicklungsanforderung nicht geeignet. Daraus geht nicht hervor, was gebaut werden soll, wer es überprüft und wann die Erwartung als erfüllt gilt.

Die nutzbare Anforderung ist konkret. Zum Beispiel: Der Benutzer kann nur die Warenbewegung an seinem eigenen Standort sehen; die Menge der genehmigten Bestellung kann ohne neue Genehmigung nicht geändert werden; die Erstellung des finanziellen Exports ist protokolliert; die Änderung systemkritischer Einstellungen erfordert zwei separate Rollen. Daraus können Planungsentscheidungen, Testfälle und spätere Überprüfungen erstellt werden.

Es ist wichtig, verpflichtende Kontrollen von Komforterwartungen zu trennen. Wenn eine interne Genehmigung von einem einzigen Vertriebsadministrator abhängt, der im Urlaub nicht ersetzt werden kann, kann das System zwar einer dokumentierten Regel entsprechen, aber das Geschäft kann stillstehen. Gute Compliance ist nicht nur streng, sondern auch umsetzbar.

Entwicklungsdisziplin sollte risikobasiert unterschiedlich sein

Es ist nicht gerechtfertigt, das gleiche Kontrollniveau auf eine Änderung des Layouts eines internen Berichts und die Änderung einer Rechnungsdatenübertragung anzuwenden. Ein zu einheitlicher Prozess verlangsamt kleinere Korrekturen, sodass die Mitarbeiter im Laufe der Zeit Umgehungswege suchen. Ein zu lockerer Prozess lässt jedoch gerade bei kritischen Änderungen Lücken offen.

Es ist nützlich, Änderungen mindestens aus drei Perspektiven zu bewerten: Betrifft es personenbezogene, finanzielle oder geschäftlich sensible Daten; ändert es Berechtigungen, Genehmigungen oder Protokollierungen; und kann es Betriebsstörungen in mehreren verbundenen Systemen verursachen. Für eine Änderung mit geringem Risiko kann die übliche Entwicklerüberprüfung und geschäftliche Abnahme ausreichen. Bei höherem Risiko kann eine separate fachliche Genehmigung, ein Integrationstest, ein Wiederherstellungsplan und eine dokumentierte Freigabeentscheidungerforderlich sein.

Dies ist keine Bürokratie, sondern Kapazitätsschutz. Die Aufmerksamkeit des Teams konzentriert sich dort, wo eine schlechte Entscheidung später zu Datenkorrekturen, Kundenbeschwerden, fehlerhaften Rechnungen oder Produktionsunterbrechungen führen kann.

Bei der Planung müssen Kontrollen zu Systemfunktionen werden

Die Erfüllung einer Compliance-Anforderung wird nicht dadurch erreicht, dass sie in einem Projektordner enthalten ist. Die kritische Regel muss in den Prozess integriert werden. Wenn ein Schritt eine Genehmigung erfordert, muss das System den Status, die genehmigende Rolle, den Zeitstempel und die Ausnahmefälle verwalten. Wenn Rückverfolgbarkeit erforderlich ist, muss das Protokoll auch festhalten, was sich geändert hat, nicht nur, dass jemand eingeloggt ist.

Das Berechtigungsmanagement ist ein besonders häufiger Schwachpunkt. In vielen Systemen erhalten Benutzer im Laufe der Zeit „vorübergehend“ breitere Zugriffsrechte, die dann dauerhaft bleiben. Bei der Planung ist es sinnvoll, in Rollen statt in Personen zu denken und Initiierung, Überprüfung und Genehmigung dort zu trennen, wo dies geschäftlich relevant ist. In kleinen Unternehmen ist eine vollständige Trennung der Aufgaben nicht immer möglich. In solchen Fällen kann ein kompensierender Kontrollmechanismus erforderlich sein, wie z. B. eine nachträgliche Überprüfung durch die Führungskraft oder eine regelmäßige Protokollüberprüfung.

Das Ausnahmehandling ist mindestens genauso wichtig. Im realen Betrieb gibt es fehlerhafte Importe, dringende Bestellungen, ausgefallene externe Dienste oder fälschlicherweise abgeschlossene Arbeitsaufträge. Ein System unterstützt die Compliance, wenn die Ausnahme keine versteckte Umgehung bedeutet, sondern einen festgelegten, protokollierten und nachträglich überprüfbaren Prozess.

Das Testen muss auch den Nachweis überprüfen

Der Funktionstest prüft, ob das System das tut, was es soll. Bei compliance-zentrierter Entwicklung muss auch überprüft werden, ob es verhindert, was es nicht darf, und ob es das aufzeichnet, was später nachgewiesen werden muss.

Ein Test des Genehmigungsprozesses darf daher nicht damit enden, dass die Genehmigungstaste funktioniert. Es muss geprüft werden, ob ein unberechtigter Benutzer den Schritt starten kann, ob der Inhalt nach einer Genehmigung geändert werden kann, ob das Protokoll korrekt angezeigt wird und in welchem Zustand die Transaktion bei fehlerhafter Integration bleibt. Negative Tests sagen oft mehr über die Qualität der Kontrollen aus als die gewohnten, erfolgreichen Prozesse.

Die geschäftliche Abnahme sollte nicht als formale Unterschrift behandelt werden. Die Aufgabe des Prozessverantwortlichen ist nicht, allgemein zu erklären: „Es ist in Ordnung“. Es muss bestätigt werden, dass das System in den tatsächlichen Betriebssituationen, einschließlich der Ausnahmen, die festgelegten Regeln unterstützt. Dazu müssen die Testdaten auch authentische Szenarien widerspiegeln.

Die Freigabe und der Betrieb sind Teil desselben Prozesses

Die Entwicklung endet nicht mit der Live-Bereitstellung. Die beste Planungs- und Testarbeit ist wenig wert, wenn nicht klar ist, wer über die Freigabe entscheidet, wie die ersten Betriebsverarbeitungen überprüft werden und was im Fehlerfall passiert.

Bei jeder wesentlichen Freigabe sollte es einen Verantwortlichen für die geschäftliche Akzeptanz der Änderung, die technische Durchführung und die nachträgliche Überprüfung geben. Der Wiederherstellungsplan darf kein theoretisches Dokument sein. Es muss bekannt sein, welche Datenbewegungen während der Freigabe stattfinden können, was automatisch wiederhergestellt werden kann und ab welchem Punkt auch eine geschäftliche Datenkorrektur erforderlich ist.

Zu den Betriebskontrollen kann die regelmäßige Überprüfung der Berechtigungen, die Behandlung fehlerhafter oder wiederholter Integrationsnachrichten, die Aufbewahrung von Protokollen und die nachträgliche Überprüfung außergewöhnlicher Änderungen gehören. Die Häufigkeit hängt von der Bedeutung des Systems ab. Ein System, das die Produktion oder den Versand direkt unterstützt, erfordert andere Aufmerksamkeit als ein selten genutztes internes Register.

Nachhaltige Compliance zeigt sich nicht daran, dass es viele Regeln gibt. Sondern daran, dass ein neuer Mitarbeiter seine Rolle versteht, ein Vorgesetzter kritische Entscheidungen rückblickend nachvollziehen kann und eine fehlerhafte Änderung das Team nicht zu manueller Datensuche zwingt. Wenn bei der nächsten Entwicklungsanforderung zuerst der betroffene Prozess, die Verantwortlichkeiten und die überprüfbaren Kontrollen geklärt werden, wird Compliance nicht zur Bremse, sondern zur Grundlage eines berechenbaren Betriebs.