Es wird viel geschrieben und berichtet zum Thema Lieferketten-Compliance, ob zum deutschen Lieferkettensorgfaltspflichtengesetz (LkSG), der entsprechenden EU-Direktive, die dazu in Vorbereitung ist, oder den international schon länger gültigen und ebenfalls die Lieferkette betreffenden exterritorialen Gesetze wie den UK Bribery Act (UKBA) oder den US Foreign Corrupt Practices Act (FCPA). Meine Kolleginnen haben sich bereits inhaltlich mit den einzelnen Richtlinien wie auch den weiteren Kontext zu Bestechung, Korruption und ESG auseinandergesetzt und dies in anderen Blogbeiträgen veröffentlicht. [👉Pinar Karacinar-Gehweiler: Compliance-Anforderungen aufgrund des Lieferkettensorgfaltspflichtengesetzes; 👉Lea Ilina: ESG im Spannungsfeld der Korruption]. Dieser Blogbeitrag skizziert nun ein entsprechendes IT-System zur Unterstützung der Lieferketten-Compliance und zeigt auf, welche Komponenten wie und warum Teil eines solchen Systems sein sollten.

Auch wenn die oben genannten Regulatorien auf den ersten Blick wenig gemein zu haben scheinen, so verbinden sie doch alle mindestens die nachfolgenden Punkte:

• Risikoanalyse: Die Basis für die Erfüllung der Regulatorien ist die Erstellung einer unternehmensspezifischen Risikoanalyse, die u.a. die Lieferanten, deren Beziehung zum eigenen Unternehmen, Regionen, Produkte und Services, Vertragsarten und weitere Risikoobjekte abdeckt. Es erscheint sinnvoll, dies einmal für alle Regelwerke zu erstellen, falls noch nicht geschehen, oder die bestehende Risikoanalyse entsprechend zu erweitern.
• Lieferanten-Screening: Der offenkundigste Teil eines Systems für die Lieferketten-Compliance ist die Prüfung der Lieferanten nach dem „Know Your Customer“ (KYC)-Prinzip. Dieser Teil wird im Markt unterschiedlich bezeichnet: KYV („Know Your Vendor“), KYBP („Know Your Business Partner“), etc. Wir übersetzen das „C“ gerne mit Counterpart und können ohne Probleme mit dem KYC-Prinzip auskommen. Abgesehen von der Begriffsverwirrung geht es hier darum, den Geschäftspartner an sich und die gegebenenfalls relevanten Akteure des Partners zu kennen und gegen einschlägige Listen zu prüfen. Neben Sanktionslisten sind auch PEP-Listen (PEP = Politisch Exponierte Personen) sowie weitere Informationen wie negative Nachrichten („Adverse Media“) einzusetzen. Hier sind drei Stufen zu beachten: Identitätsprüfung, Integritätsprüfung sowie die spezifische Risikoprüfung gegen die in der Risikoanalyse identifizierten Risiken. Dieses Screening erfolgt initial bei der Anfrage/Entscheidung, ob eine Geschäftsbeziehung eingegangen werden kann/darf/soll sowie fortlaufend und risikobasiert.

Daraus ergibt sich kurz folgende Prozesssicht auf die Thematik:

Abb. 1: Prozessuale Sicht Geschäftspartner-Screening

Die Zusammenlegung der skizzierten Themen ermöglicht das Heben von Effizienz- und Produktivitätsvorteilen. Es lässt sich so ein einheitliches System für die Geschäftspartner-Compliance herstellen, welches die diesbezüglichen unternehmensspezifischen Risiken ganzheitlich abdeckt und darstellt. Neben Transparenzvorteilen ergibt sich hieraus vor allem eine Redundanzvermeidung in der Bearbeitung unternehmensintern wie auch auf Seiten des Geschäftspartners, also des Lieferanten. Die Unterstützung durch ein flexibles IT-System, der Einfachheit halber Lieferketten-Compliance-Lösung genannt, trägt weiter zur Kostensenkung durch Vermeidung von IT-Silos, redundanter Datenaufbereitung und -haltung und zur Verringerung der sonstigen direkten und indirekten Kosten einer solchen Softwarelösung im Vergleich zu mehreren Einzellösungen bei.

Aus den oben angeführten Überlegungen im Zusammenhang mit der prozessualen Sicht auf einen Geschäftspartner-Lebenszyklus ergibt sich für den Aufbau einer solchen, flexiblen Softwarelösung folgender schematischer Aufbau, angefangen mit den Kernprozessen:

• Identitätsprüfung (Überprüfung der Stammdaten von Geschäftspartnern): Neben legalem Namen und Adresse sind beispielsweise die Mitglieder der Organe (Geschäftsführer, Beiräte, Vorstände, etc.) wie auch die Eigentumsverhältnisse (Stichwort: Wirtschaftlich Berechtigte) zu erfassen. Diese Informationen spielen bei der automatisierten Weiterverarbeitung aus unterschiedlichen Gründen eine wichtige Rolle. Diese Prüfung muss während des Onboarding-Prozesses, aber auch zur kontinuierlichen Überwachung durchgeführt werden. Wie der Prozessname es erahnen lässt, geht es hierbei um die Identitätsfeststellung des Geschäftspartners in all seinen Facetten. Anbindungen an Auskunfteien und Intermediäre, wie z. B. Dun & Bradstreet oder ähnliche, können den Automatisierungsgrad erhöhen. Die Verwendung von flexiblen, dynamischen, digitalen Fragebögen kann ebenfalls positiv auf die Effizienz wirken. Sie helfen Redundanzen zu reduzieren und sind als Self-Service-Komponente beispielsweise im Bieterprozess nutzbar.
• Integritätsprüfung (Überprüfung der identifizierten Stammdaten von Geschäftspartnern anhand einer Reihe von Listen (direkte wie indirekte/sektorale Sanktionen, PEP, Unternehmen mit schlechter Presse/unfreundlichen Medien, etc.)): Dieser Listensatz unterscheidet sich von dem, der für die Identitätsprüfung verwendet wird. Üblicherweise kommen hier Compliance-spezifische Listen zum Einsatz. Natürlich kann im Bereich des Sanktionsmanagements auch mit den öffentlich bereitgestellten Listen der EU, USA, UK und beispielsweise der Weltbank gearbeitet werden. Im Rahmen einer Make-or-Buy-Betrachtung sind aber sowohl Aufwand wie auch Risiken des Datenmanagements zu beachten. Neben der Prüfung im Onboarding eines Geschäftspartners ist dies auch kontinuierlich zu prüfen, da sich das Integritätsrisiko ständig verändern kann.
• Spezifische Risikoprüfung: Zur Überprüfung der erweiterten Daten von Geschäftspartnern auf Beziehungsrisiken bezüglich regulatorischer Aspekte (nicht operativer Risiken) werden aus der Risikoanalyse abgeleitete Regeln definiert, die dann zu sogenannten „Red Flags“ führen können, also risikorelevanten Sachverhalten, die es zu bewerten und zu bearbeiten gilt. Es gebietet sich, diese Prüfung beim Onboarding des Geschäftspartners durchzuführen und nach Entscheidung der Aufnahme einer Geschäftsbeziehung periodisch auf Basis der Risikoeinstufung zu überprüfen. Es empfiehlt sich weiter, das Risikomodell flexibel gestalten zu können. Damit ist einerseits die Möglichkeit gemeint, beliebig weitere Prüfregeln zu definieren – am besten durch die jeweilige Fachabteilung – sowie andererseits auch die Veränderung des Risikobewertungsmodells vorzunehmen. Ein Risiko-Scoring-Modell mit dominierenden Risiken hat sich hier als effektiv wie effizient herausgestellt. Auch hat sich in der Vergangenheit die bereits angesprochene digitale Fragebogenkomponente als vorteilhaft erwiesen, solange sie flexibel im Aufbau und dynamisch interaktiv bei der Beantwortung agieren kann.
• Event- & Transaktionsprüfung: Die Event- und Transaktionsprüfung kann in unterschiedlichen Komplexitätsstufen umgesetzt werden. Neben einigen Standardprüfungen bei Hochrisikotransaktionen kann hier beispielswiese auch auf Basis eines bereits im Einsatz befindlichen Betrugspräventionssystems gearbeitet werden. Auch wenn dies nicht zu empfehlen ist, wird dieser Bereich bei einer Software-gestützten Lösung oftmals nachrangig behandelt. Dies hat nicht zuletzt mit der Komplexität der Sache in Verbindung mit der umgesetzten Prozessrealität in Unternehmen und in deren ERP-Systemen zu tun. Gerne wird diese Prüfung daher transaktionsspezifisch per Organisationsanweisung auf die sogenannte „First Line of Defence“ (Operative Kontrollen) und „Third Line of Defence“ (Interne Revision) sowie Hinweisgebersysteme ausgelagert und nachrangig mittels IT unterstützt. Hier ergeben sich durch künstliche Intelligenz sowie Process-Mining-Funktionalitäten aber neue, sehr effiziente Möglichkeiten einer IT-Unterstützung und Automatisierung, die das in diesem Bereich liegende Risiko von Bestechung und Korruption deutlich mindern können.
• Fallmanagement: Alle Warnungen und generierten Fälle aus Identitäts-, Integritäts- und Risikoprüfungen müssen analysiert und entschieden werden, gegebenenfalls erst nach einer erweiterten Prüfung, die man auch „Enhanced Due Diligence“ (EDD) nennt. Ein Fallmanagement macht dies alles transparent, ermöglicht die Sicherstellung der notwendigen Bearbeitungsqualität sowie die komplexitätsgesteuerte Verteilung bzw. Delegation von Hinweisen, Fällen oder Teilaspekten davon. Typischerweise generiert die Softwarelösung auf Grund der bisherigen Prüfschritte einen Vorschlag für das initiale Risiko, welches es zu bestätigen oder zu verwerfen gilt. Das wiederum definiert, dass das Risiko idealerweise wie folgt zu unterteilen ist:
  • Initiales Risiko, welches initial beim Onboarding identifiziert und bestätigt wird.
  • Laufendes Risiko, welches sich kontinuierlich durch die Zusammenarbeit ergibt und verändert (vor allem durch risikorelevante Stammdatenänderungen oder entsprechende Events und Transaktionen).
  • Manuelles Risiko, welches durch einen entsprechend berechtigten Mitarbeiter manuell eingesteuert wird.
  • Vererbtes Risiko, welches z. B. durch Firmenzusammengehörigkeit bzw. wirtschaftlich Berechtigte besteht. Im Gegensatz zu den vorgenannten drei ist diese Risikoart optional im Zusammenhang mit der Geschäftspartner-Compliance zu sehen.
• Freigabemanagement: Die Akzeptanz einer bestimmten Risikoposition eines bestimmten Geschäftspartners muss von den Entscheidungsträgern des Unternehmens in enger Zusammenarbeit mit Compliance genehmigt werden. In den meisten Fällen tritt Compliance nur als Ratgeber auf, in anderen Fällen sollte es ein Entscheidungs- bzw. Vetorecht einfordern. Dies geschieht im Rahmen des Freigabemanagements. Im Zusammenhang mit dem oben genannten Risikomodell kann so ein identifiziertes Bruttorisiko, welches sich aus der Risikoanalyse ergibt, durch Maßnahmen im Zusammenhang mit der Geschäftsbeziehung und dem zugehörigen Vertragswesen reduziert werden − sofern man das zulassen möchte. In einem solchen Fall ergibt sich dann das Nettorisiko, über welches zu entscheiden wäre. Es versteht sich von selbst, dass alle Maßnahmen im Rahmen des Genehmigungsverfahrens mitprotokolliert werden müssen, um eine Revisionssicherheit gewährleisten zu können. Die prozessuale Darstellung oben zeigt auf, dass dies nicht nur für das Freigabemanagement gilt, sondern sich durch den Gesamtprozess zieht.
• Reporting: Neben Auditberichten sind hier vor allem die regulatorisch notwendigen Lageberichte zu nennen, die aus der Anwendung heraus, vorlagenbasiert unterstützt werden sollten, um Zeit und Aufwand zu sparen. Auch das Berichtswesen für das Management zur Risikosituation entlang der Lieferkette sowie die Governance über den gesamten Geschäftspartner-Prozess sind in diesem Zusammenhang anzuführen.

Nachdem die Kernprozesse grob beschrieben wurden, ergibt sich die Frage der Akteure, die an bzw. mit einem solchen System arbeiten müssen, also die Frage nach Schnittstellen und Benutzerrollen. Auch hier ist die Auflistung schematisch zu verstehen.

Schnittstellen:

• ERP-System(e): Hier ist vor allem das Stammdaten-führende System gemeint. Das kann ein ERP-System sein oder aber auch ein CRM-, SCM-, MDM-, Bieterportal oder ein ähnliches System, welches die Stammdaten, Ereignisse und Transaktionen von Geschäftspartnern verwaltet (z. B. Microsoft, Salesforce, SAP, u.a.). Nicht selten sind es mehrere Systeme. Die Art der Integration entscheidet über den Grad der Automatisierung und die Akzeptanz des Systems im Gesamtprozess.
• Auskunfteien/Research-Anbieter: Dies sind öffentliche oder lizenzierte Anbieter von relevanten Inhalten zu Geschäftspartnern, die zur Stammdatenpflege wie auch zur Risikoprüfung verwendet werden können/sollten (z. B. Dow Jones, Dun & Bradstreet, Moody’s, aber auch öffentliche Listen der EU, UK, USA usw.). Hier ist aus Risikogesichtspunkten zu definieren, mit welchen Anbietern und Datenquellen gearbeitet werden soll. So gibt es spezielle Anbieter, die auf Geschäftspartner aus bestimmten Regionen, z. B. die vormaligen GUS-Staaten oder auch die arabisch sprechende Welt, spezialisiert sind, sowie Generalisten. Je nach Risikoappetit kann für die einfache Risikoprüfung der eine, für die erweiterte Risikoprüfung oder die Qualitätssicherung ein anderer Anbieter gewählt werden.
• Internet: Für eine tiefere Onlinerecherche über einen bestimmten Geschäftspartner sollte eine protokolierbare Internet-Recherche bereitgestellt werden.
• Whistleblower/Beschwerdemanagement: Eine Beschwerdemöglichkeit über direkte/indirekte Geschäftspartner ist z. B. nach LkSG einzurichten und abzudecken. Es muss dann eine Untersuchung und Risikoneubewertung durchgeführt werden. Dies kann als Schnittstelle zu einem existierenden System umgesetzt werden oder durch eine Organisationsanweisung und manuelle Erfassung eines entsprechenden Hinweises im Rahmen des Kernprozesses zum Fallmanagement.

Zu den Schnittstellen ist zu bemerken, dass hier nicht auf spezielle, landes- oder industriespezifische Berichtsanforderungen zu Aufsichtsbehörden eingegangen wird, die gegebenenfalls eine weitere Schnittstellenanforderung darstellen können.

Benutzerrollen:

• GP-Antragsteller: Diese Rolle beantragt einen neuen Geschäftspartner/Lieferant und/oder eine neue Geschäftspartnerbeziehung.
• GP-Eigentümer: Diese Rolle „besitzt“ einen bestimmten Geschäftspartner und/oder eine bestimmte Geschäftspartnerbeziehung und ist für diese verantwortlich.
• Compliance: Diese Rolle soll nur exemplarisch Compliance als Anwenderrolle darstellen. Gerne wird diese noch beliebig unterteilt.
• Genehmiger: Diese Rolle steht exemplarisch für die geschäftlichen Entscheidungsträger, welche die Aufnahme eines bestimmten Geschäftspartners und/oder die Änderung des Risikopotenzials eines bestehenden Geschäftspartners prüfen und genehmigen/verweigern können.
• Geschäftspartner: Der Geschäftspartner bzw. Lieferant kann in den Prozess direkt im Rahmen eines Self-Service miteinbezogen werden.

Zu den Rollen ist zu bemerken, dass diese immer unternehmensspezifisch einzurichten sind und sich diese wie auch die Rollenbezeichnungen durchaus anders darstellen können.

Daraus ergibt sich grob das folgende Use-Case-Diagramm für ein IT-gestütztes Lieferketten-Compliance-System:

Abb. 2: Use-Case-Diagramm eines IT-gestützten Systems für die Lieferketten-Compliance (ohne Ereignis-/Transaktionsmonitoring)

Die skizzierte IT-gestützte Umsetzung eines Geschäftspartner-Compliance-Systems ist generisch und kann in dieser Form die regulatorischen Compliance-Anforderungen zur Zusammenarbeit mit Geschäftspartnern allgemein (Vertriebspartner, Joint-Ventures, Forschungsinitiativen, HR-Partner, etc.) sowie Lieferanten im Speziellen unterstützen. Auf aufsichtsrechtliche Spezifika wurde aus Gründen der Übersichtlichkeit ebenso verzichtet wie auf industriespezifische Anforderungen. Im Rahmen dieser Blogreihe werden wir in Kürze auch Einblicke bzw. Beispiele geben zu Risikomodell, Prüfstrategie und Reporting. Es lohnt sich also, dem #rethinkcompliance Blog zu folgen und dranzubleiben.