Dies ist ein Gastbeitrag von Bernhard Reiter von der ISPICO GmbH.
In diesem Beitrag vertrete ich zwei Thesen: Erstens, dass die oft isoliert geführten Softwarelösungen zum Compliance-Management (CMS), zum Internen Kontrollsystem (IKS) und nun zum „Steuer-IKS“ in einem einzigen System abgebildet werden sollten. Und zweitens, dass ein Ticketsystem wie Jira von Atlassian im weit überwiegenden Teil die ideale Lösung dafür darstellt.
Es ist ein langfristiger Trend, dass das Management einer Unternehmung immer stärker reguliert und in letzter Konsequenz auch zur Verantwortung gezogen wird. Ausgangspunkt war allgemein die Compliance – ein Begriff, der zuerst in der Medizin angewendet wurde und die Therapietreue des Patienten beschreibt. Im Unternehmenskontext bedeutet es pauschal die Einhaltung jeglicher Vorschriften durch die Mitarbeiter. Die Palette reicht von Schmiergeldzahlungen bis zum Umgang mit personenbezogenen Daten (DSGVO!). Konkreter wurden die Vorgaben in Deutschland durch den „Deutschen Governance Kodex“ [1] und das BilMoG, welches die Einführung eines Internen Kontrollsystems für die Sicherstellung der Richtigkeit der Finanzberichterstattung fordert. Und nun sollten die Unternehmen auch die steuerrelevanten Prozesse überwachen, um im Falle von objektiv falsch eingereichten Steuererklärungen den Vorwurf der Steuerverkürzung bzw. -hinterziehung plausibel entkräften zu können.
Allen drei Themen ist gemein, dass der Ausgangspunkt für die Überlegungen die Erstellung eines Risikokatalogs ist (bzw. sein sollte). Ein Risikokatalog führt zunächst jedes Risiko einzeln auf. Dazu zählen eine Beschreibung des Risikos, die Höhe des Risikos in Euro, die Eintrittswahrscheinlichkeit, der betroffene Unternehmensbereich und wer die Verantwortung für das dezidierte Risiko trägt. Und da sich die Parameter des Risikos im Zeitablauf ändern, muss es fortlaufend einem Review unterzogen und neu bewertet werden. Dabei ist es zunächst unerheblich, aus welchem der oben genannten drei Bereiche das Risiko entstammt. Das wird erst im nächsten Schritt relevant. Nämlich dann, wenn aus dem Risiko die Kontrolle abgeleitet wird. Im Sinne einer 1:n-Beziehung steht das Risiko im Zentrum und die damit verbundenen Kontrollen bilden die jeweiligen Sichten bzw. Regulatoriken ab. Das ist der Grund, warum unseres Erachtens nur eine gemeinsame Softwarelösung genutzt werden sollte.
Kontrollsysteme bestehen nun vereinfacht gesprochen aus zwei Teilen: dem einzelnen Risiko und einer bzw. mehreren zugehörigen Kontrollen. In beiden Fällen gibt es einen Verantwortlichen und etwas, das Personen in Intervallen oder mit gewissen Fristen erledigen müssen. Risiken müssen bspw. erfasst und regelmäßig bewertet werden. Und Kontrollen müssen durchgeführt und das Ergebnis sowie die Durchführung dokumentiert werden. Salopp gesprochen muss also irgendjemand, irgendetwas bis irgendwann erledigen, was wiederum exakt einem Jira-Ticket entspricht. Jira wiederum ist hinreichend flexibel im Customizing, um auch Prozesse außerhalb der Softwareentwicklung abbilden zu können, sodass sich in der Regel die Anschaffung einer dezidierten Softwarelösung vermeiden lässt. Über Filter und Dashboards lässt sich zudem der aktuelle Status der jeweiligen Kontrollbereiche elegant und zielgerichtet abbilden.
[1] Deutscher Governance Kodex
[2] Sven Hesselbach: Was ist denn jetzt im IKS für BilMoG zu machen?
