Konzeption einer Bewertungsdatenbank für Fremdfirmenverstöße und Beurteilungen

Die Erfassung von Verstößen (Incidents) erfolgt idealerweise zeitnah und standardisiert, um ein vollständiges Lagebild pro Fremdfirma zu erhalten. Typische Vorgänge bei einem Verstoß – z.B. einem Sicherheitsvorfall – wären: Ein HSE-Manager oder technischer Betreuer dokumentiert den Vorfall im System, kategorisiert ihn und stößt ggf. Maßnahmen an.

• Kategorisierung: Jeder Vorfall wird einer der Hauptkategorien der Master-Checkliste zugeordnet. Beispiele: Ein Arbeitsunfall oder das Nichteinhalten einer Sicherheitsvorschrift zählt zur Kategorie Arbeitssicherheit; eine mangelhafte Ausführungsqualität oder Produktschutzverletzung zur Kategorie Qualität; das Versäumnis einer Frist zur Termintreue; Verstöße gegen gesetzliche Auflagen oder Verhaltenskodizes zur Compliance; Umweltvergehen zur Nachhaltigkeit usw. Nicht jeder Kategorie entspricht zwangsläufig ein typischer „Verstoß“ (z.B. Innovationsfähigkeit und Flexibilität betreffen eher Performancebewertungen als akute Vorfälle). Daher konzentrieren sich die Vorfalltypen auf die Aspekte, bei denen Abweichungen auftreten können – besonders Arbeitssicherheit, Qualität, Termine, Compliance, Dokumentation (z.B. fehlende Dokumente oder Protokolle) und ggf. Leistungserfüllung. Die Kategorie wird im Vorfall-Datensatz als Pflichtfeld erfasst, um spätere Auswertungen je Kriterium zu ermöglichen.

• Schweregrad und Bewertung des Verstoßes: Neben der Kategorie wird der Schweregrad festgehalten. Dieser kann z.B. abgestuft sein in gering, mittel, hoch oder numerisch (1–3), um anzuzeigen, wie gravierend der Verstoß ist. Praktisch kann man etwa definieren: hoch = meldepflichtiger oder schwerer Unfall, erheblicher Qualitätsmangel oder bewusster Compliance-Verstoß (z.B. Arbeitsschutzregeln grob verletzt); mittel = Beinaheunfall oder moderater Verstoß (z.B. Nicht-Tragen von PSA einmalig, einmalige Terminüberschreitung mit geringen Folgen); gering = geringfügige Abweichung (kleiner Mangel ohne Auswirkungen). Diese Einordnung erlaubt es, in der Bewertung Punkteabzüge oder Gewichtungen vorzunehmen: So können z.B. für jeden meldepflichtigen Unfall 20 Punkte abgezogen werden, für jeden schweren dokumentierten Verstoß 10 Punkte, während Bagatellen evtl. nur einen geringen Abzug bedeuten. Das System kann hierzu Regelwerke hinterlegen, die automatisiert Punkteabzüge je nach Verstoßart/-schwere vergeben.

• Zeitbezug und Kontext: Jeder Verstoß sollte mit seinem Datum (und Uhrzeit) gespeichert werden, optional auch mit dem Ort oder Projektkontext (z.B. Baustelle/Anlage, Projektname). Dies ermöglicht es, Vorfälle in Zeitleisten darzustellen und etwa Trends zu erkennen (z.B. Häufung von Vorfällen in einem bestimmten Zeitraum). Zudem kann ein Zeitraum-Feld genutzt werden, um den Vorfall einem definierten Bewertungszyklus zuzuordnen (z.B. Quartal/Jahr, falls man Berichtsperioden auswerten will).

• Beschreibung und Dokumentation: Ein Freitextfeld ermöglicht die Beschreibung des Vorfalls (Was ist passiert? Welche Regel wurde verletzt?). Zudem können Belege wie Fotos, Unfallmeldungen, Prüfberichte oder E-Mails als Anhänge verknüpft werden – entweder direkt in der Datenbank (Dateiblob oder Link) oder besser via Dokumentenmanagementsystem (DMS). Viele Unternehmen nutzen bereits EHS-Software bzw. Unfallmeldesysteme, in denen solche Vorfälle erfasst werden. Die Bewertungsdatenbank sollte daher Schnittstellen vorsehen, um solche extern erfassten Vorfälle zu importieren (siehe Schnittstellen). Wichtig ist, dass für jeden Verstoß auch festgehalten wird, welche Maßnahme ergriffen wurde: z.B. Unfall untersucht am Datum X, Ursache analysiert, Mitarbeiter nachgeschult, Maschine optimiert. Diese Informationen können in einem eigenen Feld oder via Verknüpfung zu einem Maßnahmen/Ticket erfasst werden. So bleibt die Nachverfolgung gewährleistet: ein Manager kann später sehen, ob auf einen Verstoß reagiert und das Problem behoben wurde.

• Bewertung von Einzelverstößen: Nicht jeder Vorfall fließt gleich stark in die Gesamtbeurteilung ein – hier kommt die Schweregradklassifizierung ins Spiel. Ein schwerwiegender Verstoß (rote Kategorie) wirkt sich auf den Score der Fremdfirma deutlich aus, evtl. durch einen sofortigen Score-Drop oder das Auslösen eines Eskalationsprozesses. Kleinere Vorfälle werden zwar dokumentiert, summieren sich aber ggf. zu Trends. Die Bewertungslogik kann so gestaltet sein, dass z.B. wiederholte kleinere Verstöße ähnlich zu gewichten sind wie ein einzelner schwerer – etwa durch Schwellenwerte (z.B. 3 Gelb = 1 Rot). Diese Details gehören zur Scoring-Konfiguration, die in der Datenbank hinterlegt wird.

• Es dient die Erfassung der Einzelverstöße dem Früherkennungssystem: Alle Abweichungen werden zentral gesammelt statt in verschiedenen Excel-Listen oder Insellösungen, was bislang oft zu Inkonsistenzen führte. Durch die Vereinheitlichung (ein System, ein Prozess) steigt die Transparenz, und man kann z.B. mit einem Klick alle Vorfälle einer bestimmten Firma im letzten Jahr anzeigen oder vergleichen, welche Fremdfirma die meisten Sicherheitsverstöße hatte.

Neben der laufenden Vorfallerfassung finden periodische Gesamtevaluierungen der Fremdfirmen statt. Diese Beurteilungen greifen die genannten Bewertungskategorien (Arbeitssicherheit, Qualität, Termintreue, etc.) auf und bewerten die Leistung der Fremdfirma über einen definierten Zeitraum oder Projektabschluss hinweg.

• Bewertungskriterien und Scorecard: Für jede Kategorie existiert ein Kriterienkatalog. Beispielsweise beinhaltet Termintreue Kennzahlen wie Prozentsatz pünktlich eingehaltener Termine; Qualität umfasst Fehlerquoten oder Reklamationszahlen; Arbeitssicherheit berücksichtigt Unfallzahlen oder Beinaheunfälle; Compliance erfasst festgestellte Regelverstöße oder Audit-Findings; Dokumentation prüft Vollständigkeit von Berichtswesen; Kommunikation und Flexibilität werden häufig qualitativ anhand der Zusammenarbeit bewertet, etc. Diese einzelnen Kriterien werden in der Datenbank entweder durch Direkteingaben der Fachbetreuer oder – wo möglich – durch automatisierte Berechnung aus den vorhandenen Daten befüllt. So kann das System z.B. aus den erfassten Vorfällen berechnen, wie viele Sicherheitsverstöße im Zeitraum X passiert sind, oder aus den SAP-Bestelldaten die Lieferterminabweichungen ermitteln, um die Termintreue als KPI zu bewerten. Die endgültige Bewertung jeder Kategorie erfolgt dann auf einer einheitlichen Skala (z.B. 1=sehr gut bis 5=schlecht, oder 0–100 Punkte). Gewichtungen steuern den Einfluss der Kategorien auf den Gesamtscore – zum Beispiel kann man Arbeitssicherheit höher gewichten als Innovationsfähigkeit, insbesondere bei risikoreichen Arbeiten. Das Scorecard-Modell ist idealerweise flexibel konfigurierbar, sodass Anpassungen an Branchenbesonderheiten oder veränderte Prioritäten möglich sind.

• Zusammenfluss quantitativer und qualitativer Daten: Die Scorecard vereint Hard Facts (messbare KPI) und Soft Facts (subjektive Bewertungen). Quantitative Werte stammen aus den Systemdaten: z.B. On-Time-Delivery-Quote, Mängelanzahl, Unfallrate pro 1.000 Arbeitsstunden etc. Qualitative Einschätzungen kommen durch Benutzerfeedback hinzu: Nach Auftragsende geben Fachabteilungen (Projektleiter, Einkäufer, Qualitätsstellen) oft Bewertungen ab. In der Datenbank kann dies über Bewertungsformulare je Kategorie erfolgen – z.B. vergibt der Projektleiter Noten oder Sterne für Kommunikation, Flexibilität, Kooperation usw. Diese subjektiven Urteile werden im System erfasst und gemäß definierten Regeln in den Gesamtscore überführt. Beispielsweise könnte das System den Durchschnitt der letzten 3 Projektbewertungen einer Firma bilden oder aktuelle Bewertungen höher gewichten als ältere. Wichtig ist eine Standardisierung der Skalen und Fragen, um Vergleichbarkeit sicherzustellen: Oft wird mit einem gewichteten Punktesystem gearbeitet, bei dem aus Einzelnoten ein Gesamtindex berechnet wird. Eine exemplarische Umsetzung: Jede der 10 Kategorien liefert 0–10 Punkte, gewichtet nach Wichtigkeit, summiert zu einem Gesamtscore 0–100. Alternativ das Schulnotensystem 1–5 je Kriterium, gemittelt zu einer Gesamtnote. Das System sollte transparent machen, wie sich der Score zusammensetzt, damit die Bewertung nachvollziehbar bleibt.

• Verknüpfung von Vorfällen mit Bewertungen: Die erfassten Einzelverstöße beeinflussen die periodischen Bewertungen direkt. So kann die Datenbank z.B. automatisch Punktabzüge in der entsprechenden Kategorie vornehmen: Jeder gemeldete Sicherheitsvorfall reduziert den Score im Bereich Arbeitssicherheit um einen bestimmten Wert. Ebenso könnten z.B. 3 rote Qualitätsabweichungen dazu führen, dass die Qualitätsnote um eine Stufe schlechter wird. Durch diese Kopplung fließen objektive Ereignisse unmittelbar in die Scorecard ein, was Manipulation vorbeugt und eine evidenzbasierte Bewertung ermöglicht. Neben Abzügen für Negativereignisse können auch positive Befunde einfließen – etwa ein besonders gutes Audit-Ergebnis der Fremdfirma führt zu einem Punktezuschlag. Die genauen Regeln sind Teil des Scoring-Modells. In der Datenstruktur wird dies umgesetzt, indem die Bewertungseinträge entweder direkt beim Berechnen auf die Vorfall-Tabelle zugreifen oder (performanter) bestimmte aggregierte Kennzahlen pro Lieferant und Zeitraum in der Datenbank abgespeichert werden (z.B. Anzahl Unfälle letztes Jahr, Durchschnittliche Lieferverzögerung in Tagen etc.). Solche Aggregationsfelder können in der Bewertungstabelle oder einer speziellen KPI-Tabelle geführt und beim Bewerten herangezogen werden.

• Scorecard-Output und Verwendung: Nach Eingabe aller Kriterien errechnet das System den Gesamt-Score bzw. eine Rating-Klasse (z.B. >90 = “A-Status”, 70–90 = “B”, <70 = “C kritisch”). Diese Ergebnisse werden in der Datenbank persistiert und für Berichte und Dashboards bereitgestellt. Gleichzeitig können sie für Entscheidungen im Lieferantenmanagement genutzt werden – etwa ob ein Bonus/Malus gemäß Vertrag fällig wird oder ob eine Firma gesperrt werden sollte (Integration in Vertrags-KPIs). Wichtig ist die zeitliche Verbindung: Die Scorecards werden typischerweise turnusmäßig erstellt (z.B. jährlich) oder anlassbezogen (Projektende, Vertragsverlängerung). Die Datenbank sollte für jede Bewertung den Gültigkeitszeitraum speichern, um Entwicklungen über die Zeit darzustellen (Trend pro Kategorie, siehe Dashboards).

Die Bewertungsdatenbank wird von verschiedenen Nutzergruppen verwendet, die jeweils spezifische Sichten und Berechtigungen benötigen. Ein klares Rollen- und Rechtekonzept stellt sicher, dass jeder Nutzer nur das sieht und bearbeitet, was er soll.

• Auftraggeber / Fachabteilung (z.B. Projektleiter): Diese interne Rolle umfasst Mitarbeiter, die Fremdfirmen beauftragen und vor Ort betreuen. Sie nutzen das System vor allem, um vor einer Beauftragung die bisherigen Bewertungen einer Fremdfirma einzusehen (Eignungsprüfung) und nach Abschluss eines Auftrags ihr Feedback und eine Leistungsbeurteilung einzugeben. Beispielsweise kann ein Projektleiter nach Projektende im System die Qualität der Arbeit, die Einhaltung der Sicherheitsregeln und die Zuverlässigkeit der Fremdfirma bewerten und dokumentieren. Ihre Eingaben fließen in die Scorecard ein. Zugriff: sieht die Bewertungen der von ihm betreuten Firmen/Projekte, kann neue Bewertungen anlegen, aber keine globalen Einstellungen ändern.

• Technische Betreuer / HSE- und QS-Manager: Dies umfasst Rollen aus Arbeitssicherheit (HSE), Qualitätsmanagement (QS) oder operativer Technik, die Fremdfirmen vor Ort überwachen. Sie dokumentieren im System sicherheitsrelevante Ereignisse (Unfälle, Beinaheunfälle, Arbeitsschutzverstöße) ebenso wie Qualitätsmängel oder festgestellte Dokumentenlücken. Zudem überwachen sie die Einhaltung von Auflagen – z.B. prüfen sie, ob alle Fremdfirmenmitarbeiter unterwiesen wurden, ob PSA getragen wird, ob Prüfprotokolle vorliegen. Diese Nutzergruppe ist oft erste Meldende bei Verstößen und stößt entsprechende Sanktionsprozesse an. Zugriff: kann Vorfälle erfassen und alle relevanten Vorfälle einsehen (ggf. standort- oder bereichsübergreifend, je nach Berechtigung), sieht sicherheits- und qualitätsbezogene Daten. Evtl. keine Einsicht in vertrauliche kaufmännische Informationen.

• Zentrale Stelle (Kontraktorenmanagement/Einkauf/Sicherheit): Häufig richtet man eine administrative Rolle ein, angesiedelt entweder im Zentraleinkauf, in einer dedizierten Fremdfirmenmanagement-Abteilung oder gemeinsam von Einkauf und HSE. Diese Einheit übernimmt die übergeordnete Administration der Bewertungsplattform: Sie definiert die Bewertungskriterien und Scoring-Modelle, pflegt die Stammdaten der Fremdfirmen (Neuanlage, Qualifizierungsnachweise prüfen), führt regelmäßige Audits und Qualifizierungen der Lieferanten durch und verwaltet das Sanktionsmanagement. Nutzer in dieser Rolle können die Datenbank global auswerten, d.h. Berichte für die Geschäftsleitung erstellen, Rankings aller Lieferanten einsehen usw., und sie stellen sicher, dass das System konsistent angewandt wird (Prozessverantwortung). Sie dienen auch als Ansprechpartner für die Fremdfirmen bei Fragen zur Bewertung oder bei Einsprüchen. Zugriff: Vollzugriff auf alle Daten (Lesen), Schreibrechte für Stammdaten und Bewertungskriterien, Reportingrechte.

• IT-Administration: In geringem Umfang nutzen auch IT-Fachkräfte das System, primär für die technische Betreuung. Sie verwalten Benutzerberechtigungen, betreuen Schnittstellen und sorgen für Datensicherheit. Sie haben typischerweise Admin-Rechte, um im Hintergrund Konfigurationen vorzunehmen (z.B. Anbindung ans Single Sign-On, Backup/Recovery, Performance Monitoring). Zudem achten sie auf die Einhaltung von Datenschutz- und Informationssicherheitsrichtlinien in der Anwendung.

• Externe Dienstleister (Fremdfirmen): Die bewerteten Firmen selbst sind Stakeholder, erhalten aber in der Regel keinen direkten Zugriff auf die interne Bewertungsdatenbank. Die Ergebnisse ihrer Beurteilungen werden ihnen mittelbar mitgeteilt, z.B. in regelmäßigen Jahres- oder Projektabschlussgesprächen, via Lieferantengespräche oder Auditberichte. Einige Unternehmen erwägen jedoch, ausgewählten Fremdfirmen einen gelesenen Zugang zu ihren eigenen Daten im Rahmen eines Portals zu gewähren – z.B. könnten sie ihre hinterlegten Stammdaten prüfen und die für sie erfassten Verbesserungspunkte einsehen. Falls so etwas umgesetzt wird, muss das Rechtemodell strikt sicherstellen, dass jede Firma nur die eigenen Daten sieht. Alternativ erhalten die Fremdfirmen PDF-Berichte oder Auszüge. Wichtig ist aus externer Sicht Transparenz und Fairness: Jede Fremdfirma sollte prinzipiell nachvollziehen können, warum sie ein bestimmtes Rating erhalten hat.

• Betriebsrat/Datenschutzbeauftragter: Diese internen Stakeholder sind keine operativen Nutzer, aber ihr Einbezug ist essenziell, da die Datenbank auch personenbezogene Daten (z.B. Name von Fremdfirmenmitarbeitern in Unfallberichten, Zutrittszeiten) verarbeiten kann. Der Betriebsrat wird frühzeitig in das Konzept eingebunden, um die Wahrung von Arbeitnehmerrechten sicherzustellen (z.B. keine unzulässige Verhaltensüberwachung). Ebenso achtet der Datenschutzbeauftragte darauf, dass Funktionen wie Videobilder, Lokalisierungsdaten o.ä. nicht ohne Rechtsgrundlage erfasst werden. Zugriff: Diese Rollen erhalten bei Audits oder Revisionen Auskunftsrechte, aber keinen ständigen Zugriff auf operative Funktionen.

Das System muss sicherstellen, dass jeder Nutzer nur das sieht, was seinem Rollenprofil entspricht. Ein Projektleiter darf z.B. nur Bewertungen eingeben und Berichte seiner Projekte einsehen, aber keine Stammdaten fremder Firmen ändern. Ein HSE-Manager sieht sicherheitsrelevante Vorfälle aller Fremdfirmen, aber möglicherweise nicht die vertraulichen Finanzdaten der Lieferanten. Entsprechend werden Sichten und Berechtigungen definiert: Leserechte vs. Schreibrechte, modulare Rechte (z.B. Modul „Vorfall erfassen“ nur für HSE). Idealerweise ist das Berechtigungssystem hierarchisch (Rollen: Admin, Power-User, Fachuser, Read-Only etc.) und integriert ins bestehende Unternehmens-Login. Über Single Sign-On (SSO) können Nutzer sich mit ihrem AD/LDAP-Konto anmelden. Die Rollenverteilung kann durch AD-Gruppen gesteuert werden (z.B. Gruppe „Einkauf_Fremdfirmen_Admin“ mappt auf Adminrolle im System). Durch SSO und AD-Integration wird die Benutzerverwaltung vereinfacht und zugleich werden Unternehmensrichtlinien (Passwortrichtlinien, Multifaktor-Authentifizierung) eingehalten.

Schließlich ist das Rechtekonzept eng mit dem Datenschutz verzahnt: personalisierte Daten, z.B. Namen von Fremdfirmen-Mitarbeitern oder Zutrittsprotokolle, dürfen nur für berechtigte Rollen sichtbar sein (HSE-Manager für Unfallberichte, aber nicht jeder Einkaufssachbearbeiter). So wird Need-to-know-Prinzip gewährleistet.

Die Bewertungsdatenbank soll sich nahtlos in die bestehende Systemlandschaft einfügen. In Industriebetrieben sind dies meist ERP-Systeme (z.B. SAP) und ggf. Supplier-Relationship-Management-(SRM)-Portale wie SAP Ariba oder Fieldglass für externe Dienstleister.

• SAP ERP (MM/QM Modul): SAP verwaltet die zentralen Lieferantenstammdaten, Bestellungen und Wareneingänge. Die Bewertungsplattform kommuniziert bidirektional mit SAP. Konkret bedeutet das: Wenn im ERP ein neuer Lieferant angelegt wird, soll automatisch ein entsprechender Stammdatensatz in der Bewertungsdatenbank erzeugt werden (Initialanlage mit Basisdaten). Umgekehrt meldet die Bewertungsplattform einen kritischen Status zurück an SAP – etwa wenn ein Lieferant gesperrt wird, damit im ERP ein Bestellstopp hinterlegt werden kann. Diese Synchronisation sollte möglichst in Echtzeit erfolgen (z.B. via REST-API oder RFC), zumindest aber regelmäßig (Batch-Abgleich), um Dateninkonsistenzen zu vermeiden. Darüber hinaus können relevante Leistungsdaten aus SAP einfließen: z.B. Termintreue lässt sich ermitteln, indem bestätigte Liefertermine mit tatsächlichen Wareneingangsdaten verglichen werden. SAP S/4HANA bietet hier moderne Fiori-Apps und Kennzahlen (z.B. On-Time Delivery), die man direkt nutzen oder per Schnittstelle übernehmen kann. Ebenso können Qualitätsmeldungen aus SAP QM (Qualitätsmanagement-Modul) übernommen werden, falls dort Reklamationen erfasst sind. Wenn das Unternehmen bereits die SAP-Lieferantenbewertung einsetzt, kann die neue Datenbank daran anknüpfen – SAP erlaubt z.B. das Hinterlegen von Noten 1–5 oder Punkten je Kriterium und verrechnet diese zu Scores. Geplant ist jedoch oft, detailliertere Daten in der spezialisierten Bewertungsdatenbank zu halten und nur aggregierte Ergebnisse zurück nach SAP zu spielen (z.B. den Gesamt-Score, der dann in SAP für Einkauf sichtbar ist).

• Lieferantenportal / Fremdfirmen-Portal: Viele Firmen haben ein webbasiertes Portal für Lieferanten oder speziell für Fremdfirmen. Das kann ein SAP Ariba Supplier Lifecycle Management, SAP Fieldglass (für Zeiterfassung und Management von externem Personal) oder ein SharePoint-basiertes Portal sein. In unserem Kontext wird erwähnt, dass bereits ein SAP-basiertes Fremdfirmenportal existiert. Darüber registrieren sich Dienstleister, laden Dokumente hoch (z.B. Unterweisungsnachweise, Zertifikate) und ggf. erfassen sie dort ihre Arbeitszeiten. Die Bewertungsdatenbank sollte dieses Portal einbinden, sodass bestimmte Funktionen über das Portal abgewickelt werden können. Beispielsweise könnten Fremdfirmen in einem geschützten Bereich des Portals Selbstauskunfts-Fragebögen ausfüllen (z.B. jährliche Compliance-Selbstevaluation, Sicherheitskultur-Umfragen) und Dokumente aktualisieren. Diese Daten fließen dann via Schnittstelle in die Bewertungsdatenbank ein. Wichtig ist, Doppelpflege zu vermeiden: Wenn ein Zertifikat im Portal hochgeladen wird, soll es automatisch auch in der Bewertungs-DB erscheinen (Verknüpfung herstellen statt manueller Eingabe). Ebenso könnte das Portal ausgewählte Auswertungen der Bewertungsdatenbank anzeigen, z.B. den aktuellen Status einer Firma (sofern gewünscht). Für Fieldglass-spezifische Integration: Falls das Unternehmen Fieldglass für die Steuerung von Werkvertragsmitarbeitern nutzt, könnten z.B. Qualifikationsprofile und Einsatzstunden von dort übernommen werden – die Bewertungsdatenbank könnte prüfen, ob alle eingesetzten Personen im Fieldglass die erforderlichen Qualifikationen haben und wie viele Stunden geleistet wurden (was z.B. für Unfallraten benötigt wird). Ariba wiederum könnte genutzt werden, um Lieferantenbeurteilungs-Workflows oder Freigabelisten zu verwalten – die Scores aus der Datenbank könnten dort einfließen, um z.B. nur A-Lieferanten zur Ausschreibung einzuladen. Insgesamt muss die Lösung also interoperabel mit gängigen SRM-Tools sein und sich in die bestehende IT-Architektur harmonisch eingliedern.

• Weitere ERP-Integration: Über SAP hinaus kann auch eine Anbindung an SAP PM/PS (Instandhaltungs-/Projektmodul) sinnvoll sein, damit Projektabschlüsse oder Instandhaltungsaufträge einen Trigger für eine Bewertung liefern. Beispielsweise könnte beim technischen Abschluss eines Wartungsauftrags automatisch der zuständige Ingenieur per Workflow aufgefordert werden, die Fremdfirma-Leistung zu beurteilen. Ebenso könnte SAP Fieldglass Events (Ende eines Werkvertrags) auslösen, um eine Bewertung zu starten.

Es soll die Bewertungsdatenbank kein isoliertes Werkzeug sein, sondern mit den zentralen Systemen vernetzt arbeiten. Neue oder geänderte Stammdaten kommen aus dem ERP; die zurückgemeldeten Scores können im ERP/SRM sichtbar gemacht werden. Dies erhöht die Akzeptanz bei Einkauf und Management, da man in gewohnten Systemen Ergebnisse sieht (z.B. im Lieferantenstamm ein Feld „Qualitätsrating“). Zudem ermöglicht die Integration automatische KPI-Berechnungen, wie z.B. Terminabweichungen aus SAP-Bestelldaten, ohne manuelle Doppelarbeit.

• Erinnerungen an fällige Bewertungen: Das System überwacht Fristen und Ereignisse, die eine Bewertung erforderlich machen. Beispielsweise wird beim Abschluss eines Projekts (Trigger aus ERP oder manuell gesetzt) automatisch eine Aufgabe erzeugt: „Bewertung für Fremdfirma X für Projekt Y jetzt durchführen“. Ebenso kann ein Wiederholungszyklus hinterlegt werden: z.B. jährlich für Dauerdienstleister oder alle 6 Monate für kritische Lieferanten. Automatische E-Mail-Erinnerungen oder In-App-Notifications informieren den zuständigen Mitarbeiter rechtzeitig, dass eine Beurteilung ansteht. Dadurch wird sichergestellt, dass keine regelmäßige Neubewertung versäumt wird. Solche Erinnerungen sind konfigurierbar (Turnus pro Lieferant je nach Risikoklasse) und nachverfolgbar (offene vs. erledigte Bewertungsaufgaben im Dashboard).

• Automatische Score-Berechnung: Viele Kennzahlen werden ohne manuelles Zutun vom System berechnet. Beispiele: Die On-Time-Delivery-Rate (Termintreue) kann das System aus Soll-/Ist-Lieferdaten ermitteln. Die Unfallrate (z.B. Unfälle pro 200.000 Arbeitsstunden) berechnet sich aus gemeldeten Unfallzahlen und hinterlegten Arbeitsstunden. Letztere könnten z.B. aus dem Zutrittskontrollsystem stammen (Anwesenheitsstunden der Fremdfirma auf dem Werksgelände). Ebenso berechnet das System Trendindikatoren: z.B. „Qualitätsmängel nehmen zu – Anstieg um +20% im Vergleich zum Vorjahr“. Diese Berechnungen laufen im Hintergrund regelmäßig oder event-gesteuert und aktualisieren die entsprechenden Felder in der Scorecard. So hat der Nutzer stets aktuelle KPI im Blick, ohne händisch Excel-Tabellen führen zu müssen. Auch gewichtete Punktabzüge für Vorfälle erfolgen automatisch gemäß hinterlegter Logik: Meldet ein HSE-Manager einen Unfall (Vorfall-Datensatz mit Schweregrad „hoch“), reduziert das System unmittelbar den Sicherheits-Score um die definierte Punktzahl und markiert die Fremdfirma ggf. als „kritisch“.

• Eskalations-Workflows: Bei gravierenden Auffälligkeiten greift ein mehrstufiger Eskalationsprozess. Das System überwacht definierte Schwellenwerte und Bedingungen – z.B. ein schwerer Verstoß (Kategorie Rot) oder eine Häufung von z.B. >3 Vorfällen in 1 Monat. Wird ein solcher Trigger ausgelöst, startet automatisch die Eskalation. Typischer Ablauf: Stufe 1: Sofortige Benachrichtigung an den zuständigen Fachbereich und die zentrale Kontraktorenmanagement-Einheit (per E-Mail und/oder als High-Priority-Alert im Dashboard). So wissen alle Verantwortlichen zeitnah Bescheid. Stufe 2: Falls binnen definierter Zeit keine Verbesserung eintritt oder der Vorfall sehr kritisch war, automatische Info an höhere Managementebene (Abteilungsleiter, Management) – z.B. durch Eskalations-E-Mails oder Eintrag in monatlichen Qualitätsbericht. Stufe 3: Bei fortdauernder oder extremer Problematik veranlasst das System eine temporäre Sperre der Fremdfirma. Dies kann automatisch geschehen (etwa bei einem fatalen Unfall) oder manuell vom Kontraktorenmanager ausgelöst werden; technisch setzt das System einen Sperr-Flag, der via Schnittstelle ans ERP geht, sodass keine neuen Bestellungen mehr an die Firma erfolgen und ggf. das Werkszugangssystem die Ausweise der Firma blockiert. Stufe 4: Wirksamkeitsprüfung und Abschluss: Eine Eskalation gilt erst als beendet, wenn nachweislich Maßnahmen ergriffen und deren Wirksamkeit geprüft wurden. D.h. das System fordert z.B. nach einer Nachschulung einen Bericht an, ob die Fremdfirma jetzt compliant ist. Jede Eskalation und Sanktion wird im System protokolliert mit Angabe der ergriffenen Maßnahme und Entscheidung (z.B. „Sperre aufgehoben am DD.MM.YY durch HSE-Manager nach erfolgreich bestandener Sicherheitsüberprüfung“). Dieser Prozess stellt sicher, dass auf schwere Verstöße konsequent reagiert und die Ergebnisse dokumentiert werden.

• Routine-Benachrichtigungen und Aufgaben: Neben Eskalationen bietet die Plattform weitere Automatismen, die den Alltag erleichtern. Z.B. läuft ein Zertifikat ab, generiert das System 30 Tage vorher eine Aufgabe: „Neues Zertifikat von Firma XY einholen“. Oder es wird gemeldet: „Audit fällig für Firma Z – letzte Bewertung > 1 Jahr alt“. Diese Notifications können als E-Mail oder im internen Benachrichtigungscenter erscheinen. Auch eine Meldung wie „Score von Lieferant X hat sich stark verschlechtert“ kann als Hinweis erfolgen, damit der Einkauf proaktiv ins Gespräch geht. Automatische Sperrlisten-Updates sind ebenfalls denkbar: z.B. setzt das System Firmen mit Score „ungenügend“ automatisch auf eine Beobachtungsliste und informiert den Einkauf.

Alle Automatisierungsfunktionen sind parametrisierbar, um sie an interne Policies anzupassen (z.B. Schwellenwerte für Eskalationen). Sie sorgen dafür, dass nichts „durchrutscht“: Weder veraltete Dokumente noch vergessene Bewertungen. Gleichzeitig entlasten sie personelle Ressourcen – das System übernimmt Routineaufgaben und mahnt automatisch, während sich die Mitarbeiter auf die Analyse und Problemlösung konzentrieren können. Wichtig ist, dass alle automatischen Aktionen revisionssicher protokolliert werden (wer hat wann was automatisch ausgelöst) und im Zweifel manuell übersteuert werden können (z.B. kann ein Admin eine automatische Sperre aussetzen, falls erforderlich).

• Management-Dashboards: Eine aggregierte Übersicht auf hoher Ebene, die z.B. in Ampel- oder Kennzahlenform den Gesamtstatus des Fremdfirmenportfolios zeigt. Typische Inhalte: Anzahl aktiver Fremdfirmen, Aufteilung nach Risikoklassen (wie viele A-, B-, C-Lieferanten), aktuelle kritische Vorfälle und Trends über die Zeit. So könnte ein Vorstandsdashboard z.B. zeigen: „Unfallrate letzte 12 Monate: 3,2 Unfälle/Mio Std (Trend fallend um 10%)“ oder „5 von 50 Firmen mit roter Bewertung – Liste der roten Firmen“. Grafiken visualisieren Entwicklungen, etwa die Score-Entwicklung einer Top-10-Lieferantenliste über die letzten Jahre, oder ein Trenddiagramm der durchschnittlichen Termintreue pro Quartal. Ampeldarstellungen (Rot/Gelb/Grün) werden genutzt, um auf einen Blick Problemfälle zu markieren. Beispielsweise könnte jede Fremdfirma im Überblick eine Ampel pro Hauptkategorie haben – ist z.B. Arbeitssicherheit = Rot, sieht man sofort Handlungsbedarf, auch wenn Gesamtscore evtl. noch gelb ist. Das Ampelsystem erleichtert Führungskräften die Fokussierung auf kritische Punkte.

• Operative Dashboards: Für Fachanwender (HSE, Einkaufssachbearbeiter, Projektleiter) gibt es personalisierte Sichten. Ein Projektleiter sieht z.B. eine Liste „meine laufenden Fremdfirmen-Einsätze“ mit Statusampel je Firma. Diese Ampel könnte grün bedeuten „alles ok“, gelb „Achtung, ein Dokument läuft bald ab“ oder rot „Handlungsbedarf, Score hat sich verschlechtert oder Vorfall eingetreten“. Über ein solches Dashboard sieht der Nutzer sofort, wo er nachfassen muss (z.B. Unterweisung erneuern für Firma X). Kacheln oder Widgets zeigen Key KPIs: z.B. „Tage seit letztem Unfall“ bei jeder betreuten Firma, „aktuelle Gesamtbewertung“, „Anzahl offene Maßnahmen“. Dashboards sollen einerseits vorkonfigurierte KPIs bieten, andererseits anpassbar sein. Ein HSE-Manager kann sich etwa ein Widget „Top 5 Unfallursachen“ hinzufügen; ein Einkäufer interessiert sich eher für „Ø Lieferabweichung in €“.

• Standardberichte: Die Datenbank liefert druckbare oder exportierbare Berichte für verschiedenste Zwecke. Einige Beispiele: Lieferanten-Scorecard (eine Übersicht pro Fremdfirma mit allen Kennzahlen, Ampeln, Trends und Kommentaren – quasi ein Steckbrief), Vergleichsbericht (Ranking aller Fremdfirmen nach Score, evtl. gefiltert nach Gewerken oder Regionen), Zeitreihen-Report (Entwicklung der Bewertung einer bestimmten Firma über die letzten n Perioden, grafisch mit Trendpfeilen). Auch Berichte für Audits sind vorgesehen, etwa ein Report „Nachweis der Lieferantenbewertung gemäß ISO 9001“ mit allen Bewertungsterminen und -kriterien. Viele Unternehmen nutzen Ampelreports auch in Management-Meetings – etwa eine Tabelle aller Lieferanten mit farbiger Markierung pro Kategorie (Grün=ok, Gelb=mittel, Rot=schlecht). Diese Berichte können zyklisch (z.B. monatlich) vom System generiert und per E-Mail an definierte Empfänger verschickt werden.

• Ad-hoc-Analysen: Über eine Such- und Filterfunktion können berechtigte Benutzer flexible Auswertungen fahren. Beispielsweise: „Zeige alle Fremdfirmen mit mehr als 2 Unfällen im letzten Jahr“ oder „Top 10 und Flop 10 Lieferanten nach Gesamtscore im letzten Bewertungszyklus“. Die Software sollte Abfragen nach beliebigen Feldern erlauben (volltext- oder feldbasiert) und die Ergebnisse für den Export (CSV/Excel) bereitstellen, damit tiefergehende Analysen möglich sind. Power-User können so auch spezielle Korrelationen prüfen (z.B. Zusammenhang zwischen bestimmter Zertifizierung und Performance).

Die Dashboards sind webbasiert und interaktiv. Der Nutzer kann von Übersichten tiefer in Details springen (Drill-down): Etwa von der Ampel eines Lieferanten zur Detailansicht dieses Lieferanten. In dieser Profil-Ansicht werden alle wichtigen Kennzahlen und Infos der Firma bündelt – Stammdaten, aktueller Score, offene Maßnahmen, zuständige Betreuer etc. – auf einen Blick gezeigt. Von dort aus gelangt man tiefer in Untersektionen, z.B. Liste aller Vorfälle dieser Firma, hinterlegte Dokumente, Auditberichte. Die UI muss trotz des Umfangs übersichtlich und intuitiv sein. Klare Visualisierungen (Balken, Ampeln, Trendpfeile) und Filtermöglichkeiten (z.B. zeige nur aktive/geperrte Firmen, filter nach Branche) erhöhen die Nutzbarkeit.

Berichte werden typischerweise als PDF oder Excel bereitgestellt. Eine Ampelübersicht kann z.B. als PDF generiert werden, die an das Management verteilt wird. Durch die vollständige und einheitliche Datenbasis können solche Berichte auditgerecht gestaltet werden – inklusive Legenden zu Kriterien und Datum der letzten Aktualisierung, damit Prüfer sehen, dass Bewertungen regelmäßig erfolgen.

In Summe unterstützen Reports und Dashboards die steuerungstechnische Transparenz: Probleme werden früh sichtbar, Fortschritte messbar (z.B. Senkung der Vorfallszahlen über 3 Jahre) und Entscheidungen werden mit Daten untermauert (etwa Weiterbeschäftigung vs. Austausch eines Dienstleisters anhand seines Scores).

Bei der Konzeption der Datenbank sind Datenschutz und Compliance essenziell. Externe Firmenbewertung tangiert teils personenbezogene Daten (z.B. Namen von Fremdfirmen-Mitarbeitern, die an Schulungen oder Unfällen beteiligt sind) und muss hohen rechtlichen Standards genügen. Zudem müssen alle Bewertungen auditierbar und als Nachweis im Konfliktfall belastbar sein.

Die Verarbeitung personenbezogener Daten erfolgt nur soweit nötig und auf Rechtsgrundlage (z.B. berechtigtes Interesse an Arbeitssicherheitsnachweisen). Es gelten die Grundsätze der DSGVO – Datenminimierung, Zweckbindung, Transparenz und Sicherheit. Insbesondere wenn im System z.B. Name, Ausweisnummer oder Gesundheitsdaten (Unfallverletzungen) erfasst würden, ist höchste Sorgfalt geboten. Maßnahmen umfassen: - Zugriffskontrolle: Nur berechtigte Personen sehen persönliche Angaben (Need-to-know-Prinzip). Bspw. sind detaillierte Unfallberichte nur HSE-Managern zugänglich, während Einkäufer nur aggregierte Scores sehen. - Pseudonymisierung/Anonymisierung: Wo möglich, werden persönliche Felder pseudonymisiert (z.B. statt Mitarbeitername ein Code, und Klarnamen nur in separater Referenz). Statistische Auswertungen erfolgen anonymisiert. Persönliche Daten, die für den Zweck nicht nötig sind, werden gar nicht erst gespeichert. - Speicherdauer: Es gibt Konzepte zur Löschung/anonymisierung personenbezogener Daten nach Ablauf der Aufbewahrungsfristen. Z.B. könnten detaillierte Vorfallsdaten nach X Jahren anonymisiert werden, um die Person nicht mehr identifizieren zu können, während der Vorfall als solcher für die Statistik erhalten bleibt. - Betriebsratsbeteiligung: Wie erwähnt wird der Betriebsrat einbezogen, um sicherzustellen, dass keine unzulässige Verhaltenskontrolle stattfindet. Evtl. wird eine Betriebsvereinbarung zur Nutzung der Plattform erstellt, die den Umgang mit personenbezogenen Daten regelt.

Technisch wird die Anwendung nach ISO/IEC 27001 Grundsätzen (Informationssicherheit) betrieben, d.h. mit Rollen- und Berechtigungssystem, sicheren Protokollen, regelmäßigen Penetrationstests etc.. Alle Datenübertragungen (z.B. Portal <-> Datenbank) erfolgen verschlüsselt. Zudem muss das System den Konzern-IT-Vorgaben genügen, z.B. Richtlinien für Validierung, falls

Eine Kernanforderung ist, dass sämtliche Bewertungen nachvollziehbar und manipulationssicher dokumentiert sind. Für interne und externe Audits (ISO 9001, ISO 45001, LkSG etc.) muss die Firma belegen können, dass sie die Fremdfirmen regelmäßig bewertet und bei Verstößen angemessen reagiert hat. Das System unterstützt dies durch: - Audit-Trail: Jede Änderung kritischer Daten wird protokolliert – mit Benutzer, Zeit, altem und neuem Wert. Dies gilt für Stammdaten (z.B. Einpflegen eines neuen Zertifikats), Bewertungen (Änderung einer Note) und Risiko-Parameter. Der Audit-Trail ist so implementiert, dass er unveränderbar ist (z.B. in der Datenbank als WORM – Write Once Read Many – gespeichert oder durch Checksummen gesichert). Bei Prüfungen kann man so lückenlos nachweisen, wer welche Bewertung eingegeben oder geändert hat. Gerade in streng regulierten Branchen (GMP-Umfeld) ist ein solcher Audit-Trail vorgeschrieben. - Revisionssichere Archivierung: Alle wichtigen Dokumente und Abschlüsse werden revisionssicher abgelegt. Z.B. werden fertiggestellte Bewertungsreports, Auditberichte oder Korrespondenzen im Dokumentenmanagementsystem (DMS) archiviert. Das DMS gewährleistet unveränderte Aufbewahrung (Versionierung, Archivstempel). In der Datenbank wird die Verknüpfung gehalten (z.B. Dokument-ID im DMS), sodass man später jeden Nachweis direkt abrufen kann. So könnte man bei einer Streitigkeit mit einem Lieferanten genau den Bewertungsbogen vom Quartal Q1 2025 inklusive aller Kommentare aus dem Archiv ziehen. - Vollständigkeit und Konsistenz: Durch Integration der Datenquellen (siehe Schnittstellen) wird vermieden, dass Vorfälle „vergessen“ werden. Alle Unfälle aus dem Unfallmeldesystem sind auch in der Bewertungs-DB; alle Qualitätsmeldungen aus CAPA-Tool ebenfalls. So kann ein Auditor sicher sein, dass er nicht zwei getrennte Listen abgleichen muss – es gibt eine konsolidierte Wahrheit. Die Anwendung ermöglicht es zudem, Nachweise gemäß rechtlichen Vorgaben zu führen, etwa Berichte fürs Lieferkettensorgfaltspflichtengesetz (Nachhaltigkeits- und Compliance-Prüfungen von Dienstleistern) abzurufen. - Berichte für Audits: Wie 7 erwähnt, sind spezielle Audit-Reports möglich. Beispielsweise kann für ISO 9001 ein Report gezogen werden: „Liste aller Lieferantenbewertungen der letzten 2 Jahre mit Datum, Bewertungsverantwortlichem und Ergebnis“. Oder für ISO 45001: „Statistik der Arbeitsunfälle mit Fremdfirmen, zugeordnet pro Lieferant“. Diese Berichte dienen als Nachweis der Wirksamkeit des Fremdfirmenmanagements und können externen Prüfern vorgelegt werden.

Plausibilitäten (z.B. Score nur veränderbar durch berechtigte Rolle, Wertebereich validiert) und ggf. ein 4-Augen-Prinzip für kritische Freigaben (etwa muss die initiale Qualifizierung einer neuen Fremdfirma von einer zweiten Person geprüft werden, bevor sie aktiv wird). All diese Maßnahmen stellen sicher, dass die Bewertungsdatenbank gerichtsfest ist – d.h. im Zweifel belegen kann, dass Bewertungen objektiv und nach festen Kriterien erfolgten, ohne nachträgliche Manipulation.

• Unterweisungstools / Schulungssysteme: Arbeitssicherheit erfordert, dass Fremdfirmen-Mitarbeiter vor Einsatz unterwiesen werden (Sicherheitsbriefings, Zertifikate). Oft werden solche Unterweisungen über E-Learning-Plattformen oder spezielle Unterweisungsterminals am Werkstor durchgeführt. Die Bewertungsdatenbank sollte prüfen können, ob alle eingesetzten Personen unterwiesen sind. Dies gelingt durch Schnittstelle zum Unterweisungstool: z.B. meldet das Tool zurück, dass Person X der Firma Y am Datum Z die Sicherheitsschulung bestanden hat. In der Bewertungs-DB könnte auf Firmenebene ein Feld „% unterwiesene Mitarbeiter“ geführt werden. Alternativ, falls keine direkte Personendatenintegration gewünscht ist, kann die Fremdfirma im Portal selbst Unterweisungsnachweise hochladen (Zertifikate, Teilnahmebestätigungen), welche dann von HSE geprüft und in der DB vermerkt werden. Bei fehlenden oder ablaufenden Unterweisungen erzeugt das System eine Warnung (z.B. „5 von 20 Mitarbeitern der Firma nicht unterwiesen – Einsatz nicht zulässig!“). In modernen Anlagen gibt es auch Zutrittskontroll-Verknüpfungen: Das System der Zutrittskontrolle kann vor Betreten prüfen, ob ein Mitarbeiter gültig unterwiesen ist, und nur dann Zutritt gewähren. Die Bewertungsdatenbank liefert dazu die nötigen Informationen bzw. fragt sie ab. Insgesamt wird so gewährleistet, dass Schulungs- und Qualifikationsdaten nahtlos einfließen.

• Dokumentenmanagement-System (DMS): Wie bereits erwähnt, ist ein DMS die Quelle und Senke für alle wichtigen Dokumente. Die Schnittstelle zum zentralen DMS erlaubt es, dass die Bewertungsplattform Dokumente nicht doppelt speichert, sondern per Link referenziert. Beispielsweise liegt ein ISO-Zertifikat im DMS unter einer bestimmten ID. Im Fremdfirmen-Stammdatensatz wird vermerkt: „ISO 9001 Zertifikat gültig bis 12/2024, Dokument-ID 12345“. Über die Schnittstelle (z.B. REST-API oder WebDAV) kann das Dokument aus der Bewertungsoberfläche heraus angezeigt werden, ohne es extra hochzuladen. Umgekehrt können Berichte oder Auditprotokolle, die die Bewertungssoftware generiert, automatisch ans DMS übergeben und dort revisionssicher gespeichert werden. Dies erleichtert die zentrale Archivierung. Im Datenmodell gibt es für jedes Dokumenten-gebundene Feld einen Verweis (Link/ID), so dass bei einem Audit alle Nachweise schnell auffindbar sind. Die Nutzung eines etablierten DMS (z.B. OpenText, SharePoint oder ein SAP DVS) stellt sicher, dass Dokumente versionskontrolliert und mit Berechtigungen versehen sind, was die Compliance erleichtert.

• Ticketing- und Workflowsysteme: Bei erkannten Verstößen oder notwendigen Maßnahmen wird oft ein Ticket in einem separaten System erstellt, um die Abarbeitung zu verfolgen (z.B. ein CAPA im Qualitätsmanagement-System, ein Vorfallticket in der HSE-Software oder ein Task in einem Workflow-Tool wie ServiceNow, JIRA o.ä.). Die Bewertungsdatenbank sollte in der Lage sein, solche Tickets zu initiieren und den Status zurückzulesen. Beispiel: Wird ein schwerer Qualitätsmangel gemeldet, erzeugt das Qualitätsmanagement-System ein CAPA-Ticket (Corrective Action/Preventive Action). Über die Schnittstelle wird dieses Ticket der Fremdfirma und dem Vorfall in der Bewertungs-DB zugeordnet. Felder wie Maßnahmenbeschreibung, Verantwortlicher, Zieldatum könnten synchronisiert werden. Wenn das CAPA-Tool meldet „Maßnahme erledigt am 10.10.2025“, aktualisiert die Bewertungsdatenbank den Vorfall als „geschlossen“. Ebenso könnten Audit-Feststellungen aus einem Audit-Management-System importiert werden, damit sie in die Bewertung einfließen (Compliance-Verstöße, die bei internen Audits entdeckt wurden, zählen ja ebenfalls). Standardformate (CSV, XML) und APIs erleichtern diesen Austausch. Sollte kein spezialisiertes Ticket-System vorhanden sein, kann die Bewertungsplattform zumindest einfache Maßnahmenlisten führen, aber die Integration in etablierte Tools ist vorzuziehen (Praxisnähe: viele Firmen haben z.B. ein separates Incident-Management).

• Zutritts- und Zeit­erfassungssysteme: Angrenzend sei erwähnt: In vielen Fällen gibt es elektronische Zutrittskontrollsysteme am Werksgelände, die registrieren, wann Fremdfirmen-Mitarbeiter ein- und austreten. Diese Daten sind wertvoll für die Bewertungsplattform: Zum einen kann man die geleisteten Arbeitsstunden einer Fremdfirma ermitteln (Summierung der Anwesenheitsstunden), was zur Berechnung von Kennzahlen dient (z.B. Unfallrate = Unfälle / 1.000 Std). Zum anderen lässt sich prüfen, ob nur autorisierte Personen Zugang hatten (z.B. solche mit gültiger Unterweisung). Die Schnittstelle ermöglicht der Bewertungs-DB, das Zutrittssystem abzufragen (z.B. Gesamtstunden pro Firma in Zeitraum X). Umgekehrt kann bei einer Firmen-Sperre das System dem Zutrittssystem signalisieren, dass Mitarbeiter dieser Firma keinen Zutritt mehr erhalten (“Lockout”). Dies wurde bereits unter Automatisierung/Eskalation behandelt – erfordert aber diese Echtzeitkopplung. Ein weiteres System ist die Zeiterfassung/Buchung von Leistungen (etwa in SAP CATS oder Fieldglass): Daraus könnte die Bewertungs-DB z.B. entnehmen, ob eine Fremdfirma ihre Soll-Stundenzettel pünktlich und korrekt einreicht (ein Kriterium für Zuverlässigkeit).

Insgesamt wird ein offenes Schnittstellendesign angestrebt. Die meisten Integrationen erfolgen idealerweise über moderne APIs (REST/JSON oder SOAP/XML Webservices) für Echtzeit-Updates, ergänzt um Bulk-Import/Export-Funktionen (CSV) für Massenoperationen oder Altdatenübernahmen. Offene Standards stellen sicher, dass das System mit typischer Industrie-IT (SAP, SharePoint, Ariba, EHS-Systemen etc.) zusammenarbeitet, ohne proprietäre Insellösung zu sein. Die Schnittstellen sind so ausgelegt, dass zukünftige Erweiterungen – z.B. Anbindung eines neuen Learning-Management-Systems – leicht möglich sind.