Fremdfirmenportal für Großunternehmen

Im Folgenden werden die funktionalen Anforderungen an das Fremdfirmenportal detailliert beschrieben. Dies umfasst alle benötigten Funktionen und Prozesse, die das System unterstützen muss.

Das Portal soll eine zentralisierte Verwaltung von Fremdfirmen ermöglichen. Jede externe Firma, die im Unternehmen tätig wird, wird im System als eigenständiger Partner erfasst mit Stammdaten (Firmenname, Adresse, Ansprechpartner, Vertragstyp etc.). Zu jeder Fremdfirma können beliebig viele Benutzerkonten gehören, die unterschiedliche Rollen einnehmen. Das Rollenmodell muss differenziert gestaltet sein, um den realen Verantwortlichkeiten gerecht zu werden.

• Koordinator des Auftraggebers: Auf Seiten des eigenen Unternehmens gibt es typischerweise einen Fremdfirmenkoordinator oder eine auftragsverantwortliche Person, die als Hauptansprechpartner fungiert. Diese Person trägt die Verantwortung für die Kommunikation mit der Fremdfirma und die Überwachung der ordnungsgemäßen Durchführung der Arbeiten. Im Portal soll der interne Koordinator Fremdfirmen auswählen/beauftragen können, Unterweisungen planen, Zugangsfreigaben erteilen und Leistungen abnehmen. Er hat Einblick in alle relevanten Daten der ihm zugeordneten Fremdfirmeneinsätze.

• Verantwortlicher der Fremdfirma (Externer Koordinator): Jede Fremdfirma soll mindestens einen eigenen Verantwortlichen als Portalnutzer benennen. Diese Person hat adminstrative Rechte im Kontext der eigenen Firma. Sie kann die Stammdaten der Fremdfirma pflegen, Mitarbeiter der eigenen Firma im Portal anlegen/verwalten, Dokumente hochladen und ist für die Einhaltung aller Pflichten (z.B. Schulungen, PSA-Ausstattung) verantwortlich. Sie dient als zentraler Ansprechpartner auf Fremdfirmenseite.

• Disponent / Einsatzplaner der Fremdfirma: Optional kann eine Fremdfirma zusätzlich Disponentenrollen anlegen. Disponenten koordinieren operative Mitarbeiter und planen Einsätze. Im Portal können sie z.B. konkrete Mitarbeiter ihrer Firma bestimmten Aufträgen oder Schichten zuweisen und Änderungen der Einsatzplanung mit dem Auftraggeber abstimmen. (Hinweis: In kleineren Fremdfirmen könnte der Verantwortliche diese Rolle mit übernehmen.)

• Operative Mitarbeiter (Externe Mitarbeiter): Dies sind die einzelnen Beschäftigten der Fremdfirma, die vor Ort im Unternehmen Aufgaben ausführen. Jeder dieser Mitarbeiter wird im Portal mit persönlichen Daten erfasst (Name, Geburtsdatum, ggf. Ausweisnummer, Qualifikationen etc.). Sie erhalten i.d.R. keine vollen Portalzugänge, können aber personalisierte Informationen abrufen – z.B. ihre Unterweisungen, Zugangsberechtigungen oder Einsatztermine. Alternativ kann vorgesehen werden, dass operative Mitarbeiter zumindest ein eingeschränktes Login (oder eine Mobile-App-Anmeldung) haben, um z.B. Check-ins zu bestätigen oder Unterweisungen online zu absolvieren.

• Interne Fachstellen: Neben dem primären Koordinator sind weitere interne Rollen zu berücksichtigen. Beispielsweise die Arbeitssicherheit/HSE-Abteilung, die im Portal Unterweisungsinhalte bereitstellt und die Einhaltung von Sicherheitsauflagen überwacht, oder die Werksicherheit, welche Zugriff auf die Zutrittssteuerung und aktuelle Anwesenheitsübersichten hat. Auch Einkauf/Vertragsmanagement und Buchhaltung sollten Zugang zu ihren jeweiligen Bereichen haben (Verträge, Leistungs- und Rechnungsprüfung).

• Systemadministrator: Zur Benutzer- und Rechteverwaltung im Portal selbst wird eine Admin-Rolle benötigt (vermutlich in der internen IT angesiedelt), welche z.B. neue Firmen freischaltet, Benutzerrechte zuteilt oder Systemkonfigurationen vornimmt. Für fremde Firmen sollte es keine Möglichkeit geben, ihre eigenen Rechte auszudehnen – d.h. Rollen und Rechte sind vom Betreiber vordefiniert und nur von Admins änderbar.

Jeder Portalbenutzer darf ausschließlich auf die Daten zugreifen, die in seinem Zuständigkeitsbereich liegen. Insbesondere muss sichergestellt sein, dass Fremdfirmen keinerlei Informationen über andere Fremdfirmen einsehen können und auch interne Personen nur die Fremdfirmendaten sehen, die für ihre Rolle relevant sind (Prinzip der minimalen Rechte). Das Rollenkonzept ist flexibel zu gestalten, um bei Bedarf neue Rollen oder geänderte Berechtigungen abbilden zu können (z.B. Einführung einer Rolle "Auditor" mit Lesezugriff auf alle Daten für interne Revisionen).

Ein Kernstück des Portals ist die Auftragsverwaltung für Leistungen, die Fremdfirmen erbringen. Hierbei sind verschiedene Ausgangssituationen möglich: Oft existiert ein Rahmenvertrag oder Werkvertrag mit der Fremdfirma, und konkrete Leistungen werden als Abrufe oder Einzelaufträge (Call-offs) abgerufen.

• Auftragserfassung: Neue Aufträge an Fremdfirmen können direkt im Portal erstellt oder aus dem ERP-System (z.B. SAP MM) übernommen werden. Ein Auftrag enthält Informationen wie Leistungsbeschreibung, Ort der Leistung, geplantes Zeitfenster oder Ausführungszeitraum, verantwortlicher interner Koordinator, beauftragte Fremdfirma, vertragliche Konditionen (Vertragstyp, Vergütung, SLA-Vorgaben) etc. Falls der Auftrag bereits in SAP existiert (z.B. als Bestellposition oder Serviceabruf), sollen diese Daten per Schnittstelle importiert werden, um Doppelerfassung zu vermeiden.

• Ressourcenplanung (Disposition): Für jeden Auftrag können konkrete Einsätze geplant werden. Der interne Koordinator kann im Portal angeben, wann und wo die Leistung stattfinden soll, welche Qualifikationen notwendig sind und ggf. wie viele Personen oder Stunden benötigt werden. Die Fremdfirma erhält eine Benachrichtigung und kann dann ihrerseits im Portal entsprechende Einsatzpläne hinterlegen: welche operativen Mitarbeiter eingesetzt werden, an welchen Tagen zu welchen Zeiten. Der Disponent der Fremdfirma trägt diese Informationen ein. Das Portal gleicht die Planung mit den Zugangsberechtigungen ab – nur Mitarbeiter, die gültige Unterweisungen und Freigaben haben (siehe nächste Abschnitte), können dem Einsatz zugeordnet werden.

• Änderungs- und Freigabe-Workflow: Änderungen an Aufträgen oder Einsatzplänen (z.B. andere Mitarbeiter, Terminverschiebungen, zusätzliche Arbeiten) sollen im Portal durch einen einfachen Workflow gehandhabt werden. Beispielsweise kann die Fremdfirma Änderungsvorschläge einstellen, die der interne Koordinator genehmigen oder ablehnen kann (mit Dokumentation der Entscheidung). So ist transparent nachvollziehbar, wer was wann geändert hat. Bei kritischen Änderungen (z.B. Arbeiten an einem anderen Tag oder Ort) könnten zusätzliche Genehmigungsschritte nötig sein (z.B. Zustimmung der Arbeitssicherheit, falls andere Gefährdungsbeurteilung nötig).

• Statusverfolgung: Jeder Auftrag/Abruf durchläuft Status wie geplant, in Ausführung, wartet auf Abnahme, abgeschlossen. Beide Seiten (Auftraggeber und Fremdfirma) können den aktuellen Status einsehen. Bei Abschluss eines Auftrags sollte der interne Verantwortliche im Portal eine formale Abnahme/Bestätigung der erledigten Leistung dokumentieren können. Dieser Schritt kann mit der Leistungsnachweis-Prüfung und Rechnungsfreigabe verknüpft werden (siehe automatisierte Prüfprozesse). Auch Teilleistungen oder laufende Projekte sollten abgebildet werden können (z.B. monatliche Leistungen im Dienstvertrag, Bauprojekte mit Teilabnahmen).

• SLA-Monitoring: Falls vertraglich Service-Level-Agreements definiert sind (z.B. Reaktionszeiten, Verfügbarkeiten, Qualitätskriterien), soll das System Mechanismen bieten, diese zu überwachen. Beispielsweise kann bei jedem Auftrag erfasst werden, ob die Fremdfirma innerhalb der geforderten Zeit begonnen hat, ob Arbeitsabschnitte fristgerecht fertiggestellt wurden, etc., und diese Daten gegen die SLA-Vorgaben prüfen. Bei SLA-Verstößen (z.B. verspäteter Beginn) könnte das Portal automatisch einen Hinweis oder Bericht erzeugen. Diese Informationen fließen ins Bewertungssystem der Fremdfirma ein (Teil der Auditierungs- und Compliance-Dokumentation).

• Benachrichtigungen: Das Portal soll wichtige Ereignisse im Auftragsprozess automatisiert mitteilen. Beispiele: Ein neuer Auftrag wird angelegt (Fremdfirma erhält Info), eine Einsatzplanung wurde vom Auftraggeber freigegeben (Fremdfirma erhält Info), ein Auftrag nähert sich dem Enddatum (Erinnerung an beide Seiten, evtl. Folgevertrag nötig), etc. Diese Benachrichtigungen können per E-Mail erfolgen und im Portal als Notification angezeigt werden. Langfristig könnte auch eine mobile App Push-Nachrichten liefern (siehe technische Details).

Durch die Abbildung der Auftrags- und Einsatzplanung im Portal wird der gesamte Prozess für beide Seiten transparenter und effizienter. Insbesondere Missverständnisse oder Verzögerungen in der Kommunikation sollen reduziert werden. Alle Beteiligten arbeiten auf derselben Datenbasis. Historische Auftragsdaten bleiben gespeichert und auswertbar (etwa zur Abschätzung zukünftiger Bedarfe oder zur Bewertung einer Fremdfirma anhand vergangener Performance).

Ein zentrales Element, um Sicherheit und Compliance zu gewährleisten, ist die Unterweisung aller externen Mitarbeiter in die relevanten Vorschriften und Gefährdungen.

• Unterweisungsmanagement: Das Unternehmen (typischerweise die HSE-Abteilung oder Fremdfirmenkoordinator) soll im Portal Unterweisungen anlegen und verwalten können. Dazu gehören allgemeine Sicherheitsunterweisungen, standortbezogene Einweisungen (z.B. Werkordnung, Notfallwege) sowie auftrags- oder tätigkeitsbezogene spezielle Unterweisungen (z.B. Explosionsschutz-Unterweisung, falls Arbeiten in explosionsgefährdeten Bereichen anstehen). Zu jeder Unterweisung werden der Inhalt (Beschreibung, Lernmaterialien), die Dauer/Gültigkeit (z.B. gültig für 1 Jahr), die Zielgruppe und die Form (Präsenztermin oder E-Learning) erfasst.

• Zuweisung und Terminierung: Das System soll erlauben, bestimmten Personen oder Personengruppen Unterweisungen zuzuweisen. Beispielsweise kann festgelegt werden, dass alle Mitarbeiter einer Fremdfirma vor dem ersten Einsatz eine allgemeine Sicherheitsunterweisung absolvieren müssen. Die Fremdfirma sieht im Portal, welche Schulungen für ihre Mitarbeiter erforderlich sind. Das Portal generiert automatisch Termine für anstehende Unterweisungen: Präsenzunterweisungen können als Termine geplant werden, an denen sich externe Mitarbeiter anmelden. Alternativ können Unterweisungen online im Portal durchgeführt werden (etwa als multimediales Lernmodul).

• Durchführung (E-Learning Integration): Falls Unterweisungen online durchgeführt werden, sollte das Portal entsprechende Inhalte bereitstellen oder integrieren (z.B. via LMS – Learning Management System). Externe Mitarbeiter können sich mit ihren Zugangsdaten einloggen und die ihnen zugewiesenen Unterweisungskurse absolvieren. Nach Durchlaufen der Inhalte kann ein kurzer Wissenstest eingebunden werden, um Verständnis zu überprüfen. Bei erfolgreichem Abschluss wird dies dokumentiert. Ggf. lässt sich hier eine digitale Unterschrift/Bestätigung einholen, dass der Mitarbeiter die Unterweisung verstanden hat.

• Dokumentation und Nachweis: Jeder absolvierte Unterweisungsdurchgang muss personengenau protokolliert werden (wer, was, wann, mit welchem Ergebnis). Das Portal führt pro Mitarbeiter der Fremdfirma ein Unterweisungskonto mit allen Pflichtunterweisungen und dem aktuellen Status (offen, bestanden am Datum X, fällig bis Datum Y). Sowohl die Fremdfirmen-Verantwortlichen als auch die internen Koordinatoren können diese Nachweise einsehen. Vor Zutritt zum Werksgelände kann so überprüft werden, ob die Person alle notwendigen Unterweisungen hat. Dokumentation und lückenlose Unterweisung der Fremdfirmen sind essenziell, um Qualitäts- und Sicherheitsstandards einzuhalten.

• Erinnerungen und Eskalationen: Das System soll automatisch erinnern, wenn Unterweisungen bald ablaufen oder noch nicht durchgeführt wurden. Beispiel: 4 Wochen bevor die Jahresunterweisung Arbeitsschutz einer Person abläuft, erhalten die Person selbst und ihr Fremdfirmen-Verantwortlicher eine Erinnerung, einen Auffrischungstermin zu absolvieren. Wird eine notwendige Unterweisung bis zum Stichtag nicht nachgewiesen, kann das Portal Eskalationen vorsehen – z.B. Zutrittsverbot für diese Person (automatisch im Zutrittssystem hinterlegt) oder Benachrichtigung an den Koordinator. So wird sichergestellt, dass keine externe Kraft arbeitet, ohne aktuell eingewiesen zu sein.

• Mehrsprachigkeit und Verständlichkeit: Da manche externe Mitarbeiter evtl. nicht perfekt Deutsch sprechen, sollen die Unterweisungsinhalte nach Möglichkeit mehrsprachig oder zumindest in Englisch verfügbar sein. Das Portal sollte die Möglichkeit bieten, Texte und Videos mehrsprachig zu hinterlegen. Zudem sollte bei der Gestaltung der E-Learnings auf Verständlichkeit (z.B. Piktogramme, einfache Sprache) geachtet werden, um die Wirksamkeit der Unterweisung sicherzustellen.

• Rechtssichere Archivierung: Die Nachweise von Unterweisungen stellen wichtige Belege dar, etwa bei behördlichen Prüfungen oder im Haftungsfall nach einem Unfall. Das Portal muss diese Nachweise daher revisionssicher speichern (Änderungen nachvollziehbar, Originaldaten unverfälscht). Jede Unterweisung könnte ein Zertifikat oder Protokoll als PDF generieren, das vom System archiviert wird. Bei Bedarf müssen diese Dokumente für Audits abrufbar sein.

Durch diese Funktionen wird der gesamte Unterweisungsprozess professionalisiert. Das Unternehmen kann so seiner Unterweisungspflicht effizient nachkommen und hat jederzeit einen Überblick, welche Fremdmitarbeiter auf dem aktuellen Stand sind. Die Fremdfirmen werden zugleich eingebunden und mitverantwortlich gemacht, ihre Leute rechtzeitig zu Schulungen zu schicken. Insgesamt reduziert dies Unfallrisiken und trägt zur Rechtssicherheit bei (im Sinne der dokumentierten Sorgfaltspflicht).

Im Betrieb externer Firmen müssen zahlreiche rechtliche Anforderungen eingehalten werden, die über Unterweisungen hinausgehen.

• Rechtliche Rahmenbedingungen: Zunächst muss das System die grundlegenden Gesetze und Vorschriften berücksichtigen, die für Fremdfirmeneinsatz relevant sind. Gemäß § 8 Arbeitsschutzgesetz sind Arbeitgeber verpflichtet, bei gemeinsamen Arbeitsstätten zusammenzuarbeiten, sich gegenseitig über Gefahren zu informieren und Schutzmaßnahmen abzustimmen). Praktisch heißt dies, das Unternehmen und die Fremdfirma müssen alle Risiken austauschen und eine koordinierende Person benennen. Letzteres wird auch von § 6 der DGUV Vorschrift 1 gefordert, wonach ein Fremdfirmenkoordinator bestellt werden muss, wenn eine gegenseitige Gefährdung nicht ausgeschlossen werden kann. Das Portal unterstützt diese Vorgaben, indem es die Benennung eines Koordinators pro Einsatz dokumentiert und allen Beteiligten transparent macht.

• Branchenspezifische Anforderungen: Je nach Branche können zusätzliche Spezialvorschriften gelten. In Industriebetrieben greifen z.B. das Arbeitssicherheitsgesetz (ASiG), die Arbeitsstättenverordnung (ArbStättV), die Betriebssicherheitsverordnung (BetrSichV) oder die Gefahrstoffverordnung (GefStoffV), welche ebenfalls Pflichten zur Vermeidung gegenseitiger Gefährdungen enthalten. In einem bergbaulichen Umfeld (Bergwerke, Tagebau, Untertagebau) kommen die Bestimmungen des Bergrechts hinzu, insbesondere das Bundesberggesetz (BBergG) und zugehörige Verordnungen. Diese schreiben in der Regel eine besonders strenge Aufsichtspflicht des Betreibers vor und verlangen oft behördlich genehmigte Betriebspläne, in denen auch der Einsatz externer Firmen geregelt ist. Das Portal muss die Erfüllung solcher branchenspezifischer Auflagen abbilden können. Beispielsweise könnte für einen Einsatz unter Tage verlangt werden, dass alle Fremdfirmenmitarbeiter eine spezielle Grubensicherheitsbelehrung nachweisen und in den behördlichen Betriebsplan eingetragen werden – das System müsste dies tracken und dokumentieren.

• Checklisten und Freigaben: Für bestimmte Arbeiten mit erhöhtem Risiko (Heißarbeiten, Arbeiten in Ex-Zonen, Arbeiten nach dem Bundesberggesetz etc.) sind oft Freigabeverfahren vorgeschrieben (z.B. Erlaubnisscheine, Permits). Das Portal soll die Verwaltung solcher Freigaben unterstützen. Es kann Checklisten hinterlegen, welche Voraussetzungen erfüllt sein müssen, bevor die Arbeit starten darf (z.B. Genehmigung der Gefährdungsbeurteilung, Vorhandensein bestimmter Zertifikate, Messungen durchgeführt). Der Fremdfirmenkoordinator oder eine verantwortliche Fachstelle kann diese Checkliste digital abhaken und final eine Freigabe im System erteilen. Ohne diese Freigabe sollte der Auftrag nicht den Status "freigegeben" erreichen. Alle ausgefüllten Checklisten werden gespeichert, sodass bei einer Auditierung die Einhaltung nachvollzogen werden kann.

• Qualifikationsnachweise: Bei Arbeiten, die spezielle Qualifikationen erfordern (Schweißer-Prüfungen, Elektroschein, Staplerschein, Sprengberechtigungen etc.), muss die Fremdfirma die entsprechenden Zertifikate der eingesetzten Mitarbeiter hinterlegen. Das Portal verknüpft diese mit den Mitarbeiterprofilen und stellt sicher, dass nur Personen mit gültiger Qualifikation eingeteilt werden können.

• Behördliche Genehmigungen: Falls für bestimmte Fremdfirmenarbeiten behördliche Genehmigungen erforderlich sind (etwa Sprengarbeiten im Bergbau, Arbeiten an genehmigungsbedürftigen Anlagen), können diese Dokumente ebenfalls im Portal hinterlegt werden, sodass bei einer Kontrolle alle Nachweise zentral abrufbar sind.

• Versicherungsnachweise: Fremdfirmen müssen meist nachweisen, dass ihre Mitarbeiter unfallversichert sind (Berufsgenossenschaft) und dass eine Haftpflichtversicherung besteht. Diese Bescheinigungen (z.B. BG-Bescheinigung) sollen im Portal hochgeladen und versioniert verwaltet werden.

• Ärztliche Bescheinigungen: In manchen Branchen (z.B. Chemie, Bergbau) sind Arbeitsmedizinische Vorsorgeuntersuchungen Pflicht. Das System sollte erfassen, ob für einen Mitarbeiter eine gültige G-Untersuchung (z.B. G25, G41 etc.) vorliegt, bevor dieser bestimmte Tätigkeiten ausführt. Ablaufdaten solcher Bescheinigungen werden überwacht.

• Vertragliche Vereinbarungen zu Sicherheit: Das BetrVG (§ 80) verlangt, dass ab einer gewissen Betriebsgröße der Betriebsrat der Nutzung von Fremdfirmen zustimmen muss und an Maßnahmen zu Arbeitsschutz beteiligt wird. Solche internen Abstimmungen (Betriebsratszustimmung, ggf. Dokumentation einer Betriebsvereinbarung zum Fremdfirmeneinsatz) sollten ebenfalls im System hinterlegt sein, um nachzuweisen, dass alle internen Regularien eingehalten wurden.

Das Portal soll aktiv dazu beitragen, die Verkehrssicherungspflichten des Unternehmens zu erfüllen. Nach § 823 BGB (Schadensersatzpflicht) hat das Unternehmen dafür zu sorgen, dass keine Person durch betriebliche Abläufe zu Schaden kommt; diese Pflicht erstreckt sich auch auf externe Personen auf dem Betriebsgelände. Entsprechend muss das Portal Funktionen zur Prävention bieten – wie oben beschrieben: Zutrittsbeschränkungen für Ununterwiesene, Prüf-Workflows, Qualifikationschecks. All diese Mechanismen dienen dazu, Risiken zu kontrollieren und im Ernstfall nachweisen zu können, dass das Unternehmen seinen Sorgfaltspflichten nachgekommen ist.

Abschließend sollte das System erlauben, Berichte über den Stand der Compliance zu erzeugen. Etwa eine Übersicht aller aktiven Fremdfirmen mit Status der Unterlagen (vollständig / fehlend), eine Liste aller Fremdmitarbeiter mit fehlenden Unterweisungen, Statistiken über dokumentierte Verstöße, etc. Dies unterstützt die Arbeitssicherheit und ggf. externe Aufsichtsbehörden bei der Überprüfung.

Eine wichtige Schnittstelle zwischen dem Fremdfirmenportal und der realen Welt ist die Zutrittskontrolle zum Betriebsgelände. Das Portal soll eng mit bestehenden Zutritts- und Sicherheitssystemen verzahnt werden, um sicherzustellen, dass nur autorisierte und vorbereitete Personen und Fahrzeuge das Gelände betreten.

• Zutrittskontrollsystem-Anbindung: Das Unternehmen hat vermutlich ein elektronisches Zutrittskontrollsystem (z.B. mit Ausweiskarten, Drehkreuzen oder Schranken). Das Fremdfirmenportal soll Daten an dieses System liefern. Konkret: Für jeden externen Mitarbeiter, der für einen bestimmten Zeitraum vorgesehen ist, muss ein Zutrittsprofil angelegt werden. Ideal ist eine automatische Übertragung – wenn ein Mitarbeiter einem Auftrag an einem bestimmten Tag zugeteilt und alle Voraussetzungen erfüllt hat (Unterweisungen, Dokumente), markiert der Koordinator ihn als "zugangsberechtigt". Daraufhin erstellt das Portal im Zutrittssystem einen temporären Ausweis bzw. aktiviert die Personalnummer für den besagten Zeitraum. So können Fremdfirmenmitarbeiter beim Eintreffen direkt ihren Ausweis erhalten oder an einem Self-Service-Terminal einen Tagesbadge ziehen. Das Portal und das Zutrittssystem tauschen Informationen aus: z.B. wer hat wann eingecheckt/ausgecheckt, um die Anwesenheit zu protokollieren.

• Kennzeichenerkennung (Zufahrtskontrolle): Viele Gelände kontrollieren auch die Einfahrt von Fahrzeugen mittels automatischer Kennzeichenerkennung (ANPR). Das Portal soll die Möglichkeit bieten, Fahrzeugdaten zu verwalten. Wenn Fremdfirmen mit eigenen Fahrzeugen anrücken (Servicewagen, LKW, etc.), können vorab deren Kennzeichen und ggf. Fahrer registriert werden. Diese Daten werden an das Erkennungssystem übertragen, sodass bei Ankunft das Kennzeichen automatisch erkannt und mit einer Erlaubnis verknüpft ist. Beispielsweise könnte die Schranke automatisch öffnen, wenn ein angemeldetes Kennzeichen zur geplanten Zeit eintrifft. Gleichzeitig wird ein Zeitstempel an das Portal zurückgemeldet. Fahrzeuge, die nicht vorangemeldet sind, können abgegewiesen oder manuell geprüft werden – ein Abgleich im Portal erlaubt dem Werkschutz, sofort zu sehen, ob ein Fahrzeug erwartet wurde.

• Videoüberwachung: Relevante Zugänge sind oft videoüberwacht. Eine Integration der Kameraüberwachung ins Portal kann hilfreich sein, etwa um bei Unklarheiten (z.B. ein Fremdfirmenmitarbeiter nutzt unbefugt einen fremden Ausweis) Bildmaterial zur Verfügung zu haben. Das Portal muss hierbei die strengen Datenschutzvorgaben für Videoüberwachung beachten – Live-Bilder sollten nur berechtigten Stellen (Werkschutz) angezeigt werden, Aufzeichnungen nur im Ereignisfall herangezogen werden. Eine Verknüpfung könnte so aussehen, dass das Portal bei sicherheitsrelevanten Events (z.B. Zutrittsversuch ohne Berechtigung) einen Marker setzt, sodass Verantwortliche im Videosystem die entsprechende Aufzeichnung leicht finden können. Dies ist jedoch optional – wichtiger ist die Aufnahme der Zutrittsdaten.

• Anwesenheitsübersicht und Notfallmanagement: Das Portal soll in Echtzeit eine Übersicht aller anwesenden Fremdfirmenmitarbeiter liefern können. Durch die Anbindung an das Zutrittssystem weiß es, welche Personen aktuell eingecheckt sind. Im Ereignisfall (z.B. Evakuierung bei Alarm) kann so auf Knopfdruck eine Liste aller externen Personen erzeugt werden, um z.B. an Sammelstellen abzugleichen. Ebenso kann ein Verantwortlicher jederzeit sehen, welche Fremdfirma sich gerade wo im Einsatz befindet. Dies unterstützt das Sicherheitsmanagement enorm.

• Zufahrtsplanung: Bei größeren Anlagen ist oft auch die Logistik- und Zufahrtsplanung relevant (z.B. koordinierte Anlieferungen, Vermeidung von Staus vor dem Werk). Das Portal könnte Erweiterungen bieten, um Zeitfenster für Anlieferungen durch Fremdfirmen zu buchen. So ließe sich z.B. steuern, dass nicht fünf Fremdfirmen-LKW gleichzeitig eintreffen. Denkbar ist auch eine Waagenintegration (falls etwa bei Ausgang das Fahrzeug verwogen werden muss – das Portal könnte Auftrag und Gewicht verknüpfen, ist aber sehr spezifisch und evtl. außerhalb des Kerns).

• IT-Sicherheit und Netzwerk: Da das Zutritts- und Videosystem meist Teil der internen OT (Operational Technology) ist, muss die Integration sicher erfolgen. In der Regel wird das Portal über definierte APIs oder Datenbank-Schnittstellen mit dem Zutrittssystem kommunizieren. Gegebenenfalls ist ein Security Gateway nötig, um die Verbindung vom Portal (ggf. in der Cloud oder DMZ) zum internen Sicherheitsnetz zu ermöglichen, ohne Angriffsflächen zu öffnen. Dies gehört zur Architekturplanung (siehe weiter unten), wird aber hier erwähnt, weil die Live-Kopplung mit physischen Sicherheitssystemen eines der technisch sensibelsten Integrationsstücke ist.

In Summe sorgt diese Integration dafür, dass nur autorisierte, geschulte und angemeldete Personen aufs Gelände kommen. Sie macht den Zutrittsprozess schneller (weniger manuelle Einlasskontrollen, da Vorab-Registrierung) und sicherer (automatische Abgleiche, keine manuellen Gästelisten). Zudem fallen wertvolle Daten zur Arbeitszeit und Präsenz an, die im nächsten Schritt für Prüfprozesse genutzt werden können. Wichtig ist, dass alle diese personenbezogenen Daten und Video-/Fotoaufzeichnungen mit höchster Sorgfalt und gemäß Datenschutz gespeichert werden – Details dazu im Abschnitt Datenschutz.

Das Fremdfirmenportal muss umfassende Audit- und Reportingfunktionen bereitstellen, um die Einhaltung aller Vorschriften und internen Regeln nachweisbar zu machen.

• Compliance-Checks und Berichte: Das System soll regelmäßig automatische Compliance-Prüfungen durchführen. Beispielsweise ein täglicher Check: "Alle heute anwesenden Fremdmitarbeiter haben gültige Unterweisungen und Qualifikationen?" – Falls nein, wird ein Bericht generiert oder die betreffenden Einsätze markiert. Ebenso könnten Berichte erstellt werden: "Welche Dokumente laufen in den nächsten 60 Tagen ab?", "Liste aller Fremdfirmen mit offenen Mängeln bei der Arbeitssicherheit". Solche Berichte helfen Verantwortlichen, proaktiv Maßnahmen zu ergreifen. Sie dienen auch als Beleg bei externen Audits (z.B. ISO-Zertifizierungen in Arbeitsschutz oder Umwelt) um zu zeigen, dass das Unternehmen systematisch überwacht.

• Aktions- und Änderungsprotokoll: Jegliche relevanten Aktionen im System sollen protokolliert werden. Dazu zählen z.B. Änderungen an Auftragsdaten (Wer hat wann was geändert?), Freigaben erteilt oder verweigert, Unterweisungen bestanden, Zutrittsereignisse, Dokumentenuploads etc. Diese Protokolleinträge sollten mit Benutzername, Datum/Uhrzeit und Beschreibung erfasst sein. Bei Bedarf muss man so einen Audit-Trail nachvollziehen können, etwa um festzustellen, ob vor einem Zwischenfall alle notwendigen Schritte korrekt durchgeführt wurden.

• SLA- und Leistungsberichte: Aus den Auftragsdaten und der Zeiterfassung können Leistungskennzahlen je Fremdfirma erzeugt werden. Das Portal sollte Dashboards oder Berichte anbieten, die z.B. zeigen: Einhaltung von Terminvorgaben (% pünktlich fertiggestellt), Qualität (Anzahl Nacharbeiten oder Reklamationen), Arbeitssicherheit (Anzahl Unfälle/Vorfälle pro geleistete Arbeitsstunde), usw. Auch die SLA-Erfüllung kann hier dokumentiert werden: Falls vertraglich Strafen oder Bonus bei bestimmten Leistungswerten vereinbart sind, lassen sich die Daten dafür aus dem System ziehen. Diese Berichte fließen ein in regelmäßige Bewertungen der Fremdfirmen (z.B. jährliches Lieferantengespräch, Entscheidung über Vertragsverlängerung).

• Audit-Export: Bei offiziellen Prüfungen (Behörden, Unfallversicherungsträger, interne Revision) sollte das System einen schnellen Export relevanter Unterlagen ermöglichen. Beispielsweise könnte auf Anforderung der gesamten Unterweisungsnachweis für eine bestimmte Fremdfirma als PDF/Paket bereitgestellt werden, oder alle Dokumente und Nachweise zu einem bestimmten Auftrag. Eine durchsuchbare Archivfunktion innerhalb des Portals ist auch wünschenswert, um gezielt nach Datensätzen zu suchen (z.B. Suche nach Name eines Fremdmitarbeiters liefert alle zugehörigen Datensätze).

• Zertifizierungsunterstützung: Viele Unternehmen streben Zertifizierungen (ISO 45001 für Arbeitsschutzmanagement, ISO 27001 für Informationssicherheit, ISO 9001 für Qualitätsmanagement etc.) an. Das Fremdfirmenportal kann dabei ein wichtiger Baustein sein, indem es die Erfüllung der jeweiligen Normforderungen unterstützt. Beispielsweise verlangt ISO 45001 die Berücksichtigung von vertraglich gebundenen externen Arbeitskräften im Arbeitsschutzmanagement – das Portal liefert hier evidenzbasierte Nachweise (Prozesse, Dokumentationen) für Auditoren. Ähnliches gilt für ISO 27001 in Bezug auf Zugriffskontrollen (Zutrittssystem-Logs) und ISO 9001 bezüglich Lieferantensteuerung. Das Konzept sollte diese Überschneidungen berücksichtigen und ggf. in der Dokumentation (Handbuch) hervorheben.

• Benutzerfreundliche Auswertungen: Trotz der Fülle an Daten sollte das Portal übersichtliche Visualisierungen bieten, etwa Ampelindikatoren (grün/gelb/rot) für den Compliance-Status einer Fremdfirma, Diagramme über Stunden vs. Rechnungsbeträge etc. So können auch Manager ohne Detailkenntnis schnell einen Eindruck bekommen. Wichtig ist jedoch, dass für tiefergehende Prüfungen die detaillierten Daten jederzeit abrufbar bleiben.

• Schwachstellen- und Vorfallsmanagement: Optional kann das Portal auch genutzt werden, um Vorfallsmeldungen oder Beinaheunfälle mit Fremdfirmen zu erfassen. Sollte es z.B. zu einem Sicherheitsvorfall kommen (Unfall, gefährliche Situation), kann dies im System dokumentiert und der betreffenden Fremdfirma zugeordnet werden. So entsteht eine Historie, die bei zukünftigen Auftragsvergaben oder Audits berücksichtigt wird. Ggf. lassen sich daraus auch Maßnahmen ableiten (z.B. zusätzliche Unterweisung anordnen nach einem Beinaheunfall). Dieses Feature ist eher Erweiterung, zeigt aber die umfassende Sicht auf Auditierung: Nicht nur Soll-Zustand dokumentieren, sondern auch Abweichungen und deren Behandlung.

Letztlich soll das Fremdfirmenportal so gestaltet sein, dass es als Single Source of Truth für alle Belange rund um Fremdfirmen dient. Im Idealfall könnten externe Auditoren oder Aufsichtsbehörden temporären Read-Only-Zugang zu bestimmten Bereichen erhalten, anstatt Berge von Papier einzusehen – dies wäre modern und effizient. Die im Portal gepflegten Daten und Dokumente sind umfassend genug, um jede Prüfung zu bestehen und jede Frage zu Fremdfirmeneinsätzen beantworten zu können.

Da Fremdfirmen auf Basis von Verträgen tätig werden, muss das Portal grundlegende Funktionen des Vertrags- und Leistungsmanagements unterstützen:

• Vertragsdatenbank: Alle relevanten Verträge mit Fremdfirmen sollten im Portal hinterlegt oder verlinkt sein. Pro Fremdfirma können ein oder mehrere Verträge existieren (Rahmenvertrag, Einzelverträge, NDA etc.). Mindestens die Metadaten (Vertragsnummer, Art, Laufzeit, Kündigungsfrist, Ansprechpartner, finanzielle Konditionen, vereinbarte SLAs) werden im System erfasst. Idealerweise wird auch der Vertragstext als PDF im Portal abgelegt (ggf. in Integration mit dem Dokumentenmanagement, z.B. SAP DVS). So hat der Koordinator alle Vertragsdetails griffbereit, wenn er im Portal arbeitet.

• Laufzeit- und Fristenkontrolle: Das System soll an auslaufende Verträge oder wichtige Fristen erinnern. Beispiel: 90 Tage vor Vertragsende einer Fremdfirma erhält der Einkauf und der Koordinator einen Hinweis, um rechtzeitig über Verlängerung oder Ausschreibung zu entscheiden. Auch Erwähnungen von Verlängerungsoptionen oder Preisgleitklauseln können im System notiert und entsprechend getrackt werden. So geht keine vertragliche Obliegenheit verloren.

• SLA-Überwachung: Verträge mit Fremdfirmen enthalten oft Service Level Agreements (SLAs), z.B. Reaktionszeit bei Störfällen < 4 Stunden, Verfügbarkeit 98%, max. Ausfallquote etc. Das Portal soll die vereinbarten SLAs erfassbar machen. In Verbindung mit den zuvor erwähnten Leistungsdaten und Ereignissen kann dann automatisiert geprüft werden, ob die SLAs eingehalten wurden. Wird ein SLA verletzt (z.B. Fremdfirma hat 6 Stunden bis zur Störungsbehebung gebraucht statt 4), sollte das System dies registrieren und ggf. einen Eintrag in einen SLA-Verstoß-Report machen. Mehrere Verletzungen können z.B. Konsequenzen nach sich ziehen (Vertragsstrafe, Eskalationsgespräch); das Portal kann diese Statistik bereitstellen.

• Vertragsdokumentation von Sicherheitspflichten: Wichtig im Kontext dieses Portals ist, dass bestimmte Arbeitsschutzpflichten auch vertraglich vereinbart sind. Beispielsweise kann im Vertrag stehen, dass die Fremdfirma nur unterwiesenes Personal einsetzt, dass PSA getragen wird, dass Meldeketten bei Unfällen eingehalten werden etc. Das Portal kann diese Klauseln dem Koordinator sichtbar machen, und es kann Mechanismen geben, um die Einhaltung zu verifizieren (z.B. Abfrage an Fremdfirma vor Einsatzbeginn: "Bestätigen Sie, dass Ihre Mitarbeiter die nötige PSA tragen?"). Solche Bestätigungen könnten als Teil des Workflows vor Arbeitsbeginn eingefordert und protokolliert werden, um die vertragliche Absicherung ebenfalls digital zu untermauern (vgl. Checkliste: vertragliche Vereinbarung besonderer Arbeitsschutzbestimmungen).

• Änderungen und Nachträge: Sollte es zu Vertragsänderungen oder -nachträgen kommen (etwa Anpassung der Preise, Änderung des Leistungsumfangs), müssen diese auch im System aktualisiert werden. Der Vertragsmanager/Einkauf kann entsprechende Felder anpassen und Dokumente hochladen. Das Portal sollte Versionierung unterstützen, damit ältere Stände nachvollziehbar bleiben. Außerdem könnten kritische Vertragsänderungen an beteiligte Personen gemeldet werden (z.B. neuer Stundensatz – relevant für den Rechnungsprüfprozess).

• Lieferantenbewertung: Ergänzend zum reinen Vertragsmanagement kann das Portal helfen, qualitative Aspekte für künftige Vergaben zu erfassen. Nach Abschluss eines größeren Projekts könnte der interne Koordinator z.B. eine Bewertung im System hinterlegen (Sterne oder Score) hinsichtlich Qualität, Kommunikation, Einhaltung Regeln etc. Diese subjektiven Daten plus die objektiven KPIs (SLA-Fakten, Unfallzahlen) ergeben eine Lieferantenbewertung, die z.B. der Einkauf bei Vertragsverlängerungen nutzt. Dieses Feature ist nice-to-have, zeigt aber, wie das Portal ins Lieferantenmanagement integriert sein kann.

Durch diese Funktionen wird das Portal quasi zu einem Lieferantenportal für Fremdfirmen, mit speziellem Fokus auf die operativen und sicherheitsrelevanten Aspekte. Das Vertragsmanagement stellt sicher, dass das, was im Feld passiert, im Einklang mit den formal vereinbarten Bedingungen ist. Ebenso schafft es Transparenz für die Fremdfirmen: Sie sehen klar, was vertraglich von ihnen erwartet wird (SLAs, Pflichten) und wo sie stehen. Das kann auch die Beziehung verbessern, da objektive Kriterien vorliegen und weniger Missverständnisse entstehen.

Das Fremdfirmenportal soll keine losgelöste Anwendung sein, sondern intelligent mit bestehenden IT-Systemen integriert werden. Insbesondere die ERP-Module von SAP sind hier relevant, da dort typischerweise Personal- und Materialwirtschaft sowie Dokumente verwaltet werden. Die wichtigsten Integrationen:

• Stammdaten Abgleich: Mitarbeiter der Fremdfirma könnten in einem separaten Partner- oder Besucherregister geführt werden, evtl. angebunden an HR oder Identity Management. Wenn SAP HR solche Externe als "Leiharbeiter" oder über SAP Fieldglass als Datendrehscheibe verwaltet, sollte das Portal diese Informationen nutzen. Beispielsweise könnten Name, Firma, evt. Personalnummer (externe ID) aus SAP übernommen werden, um Doppeleingaben zu vermeiden.

• Organisationsdaten: Falls interne Betreuer (Koordinatoren) im Portal zugeordnet werden, könnten deren Stammdaten (Name, Abteilung, Kontaktdaten) aus SAP HR kommen, um stets aktuelle Infos zu haben (bei Personalwechsel automatisch aktuell).

• Berechtigungen über HR-Org: Eventuell kann die Organisationstruktur aus HR genutzt werden, um Freigabeworkflows im Portal zu steuern (z.B. Vorgesetzte vertretungsweise Freigaben erteilen).

• Zeiterfassung: Sollten externe Personen in SAP ZE (CATS) erfasst werden (was unüblich ist), könnte das Portal Daten liefern. Wahrscheinlicher ist jedoch, dass das Portal die Anwesenheitszeiten (via Zutritt erfasst) an SAP übermittelt, falls dort z.B. ein Projektcontrolling stattfindet.

• Das Portal selbst speichert Dokumente (z.B. PDFs von Zertifikaten) in einer eigenen Datenbank oder Filestore. Via Schnittstelle (BAPI oder Webservice) könnten diese an SAP DMS übertragen werden, wo sie z.B. an den Lieferantenstammsatz oder Bestellvorgang geheftet werden. So sind die Dokumente auch in SAP verfügbar, was z.B. für den Einkauf oder Auditoren, die SAP auswerten, hilfreich ist.

• Alternativ kann das Portal bei Bedarf Dokumente live aus SAP DMS laden (z.B. den Vertragstext) und anzeigen. In diesem Fall fungiert SAP als Master für Dokumente.

• Welche Variante gewählt wird, hängt von der IT-Strategie ab. Wichtig ist: keine doppelten Ablagen mit unterschiedlichem Stand. Evtl. kann man das Portal so einstellen, dass gewisse Dokumenttypen (Verträge, Bestellungen) nur als Link/Referenz auf SAP geführt werden, während andere (Unterweisungsnachweis, Versicherungsbogen) im Portal liegen.

• Technisch sind für SAP DMS Integrationen über RFC/BAPI (in On-Premise SAP) oder über neuere Schnittstellen (OData Services in S/4HANA) denkbar.

• Bestell- und Auftragsdaten: Wie bei der Auftragsverwaltung beschrieben, sollte das Portal im Idealfall Bestellpositionen aus SAP lesen können. Wenn z.B. ein Rahmenvertrag als SAP-Bestellung existiert mit Positionen für bestimmte Leistungen, könnte der Abruf über das Portal eine Service-Eintrittsmeldung in SAP generieren. Das Portal kann z.B. via SAP BAPI einen Serviceauftrag (eine Art Leistungsanforderung) anlegen oder einen bestehenden Abruf referenzieren.

• Leistungserfassung: In SAP MM gibt es für Dienstleistungen die Leistungs-/Serviceerfassung (Transaktionen ML81N für Service Entry Sheet). Das Portal könnte diese Funktionalität abbilden, indem nach geleisteter und abgenommener Arbeit eine entsprechende Leistungsfestschreibung an SAP übertragen wird. Dies wäre das Äquivalent zum Wareneingang bei Material: Für Dienstleistungen erfasst man einen Leistungsschein. Das Portal kann die Details (Leistungsart, Menge/Stunden, Datum, ggf. Bestellnummer) an SAP übermitteln, wo ein Eintrag entsteht, der später mit der Eingangsrechnung abgeglichen wird.

• Eingangsrechnungen: Eingehende Rechnungen von Fremdfirmen werden meist in SAP (Modul MIRO oder über ein Eingangsrechnungssystem) gebucht und geprüft. Hier soll das Portal die Vorkontrolle übernehmen (siehe nächster Abschnitt "Automatisierte Prüfprozesse"). Eine Integration ist nötig, damit das Portal die Rechnungsdaten erhält. Dies kann z.B. über einen regelmäßigen Datenimport geschehen: Sobald eine Rechnung in SAP erfasst wird (ggf. nach OCR-Scan), ruft das Portal die relevanten Felder (Rechnungsnummer, Datum, Betrag, Bestellbezug, Positionen) ab. Dann führt es seine Prüfungen durch und meldet das Ergebnis zurück. Im einfachsten Fall könnte das Portal nach erfolgreicher Prüfung einen Zahlungsfreigabe-Flag setzen, das in SAP von der Buchhaltung gesehen wird. Oder es wird direkt ins SAP ein Prüffeld aktualisiert.

• Stammdatenabgleich: Lieferantenstammdaten (Fremdfirma als Kreditor in SAP) sollten mit dem Portal synchron sein. Änderungen an Adresse oder Bankverbindung sollten nur einmal gepflegt werden. Hier empfiehlt sich SAP als führendes System für Firmastammdaten (Kreditorenstamm), während Personendaten eher im Portal geführt werden. Das Portal kann bei Neuanlage einer Fremdfirma eine Schnittstelle bieten, um in SAP einen neuen Kreditor anzustoßen oder umgekehrt.

• SAP-Integration Plattform: Für all diese Austauschvorgänge ist es oft sinnvoll, eine Middleware (z.B. SAP Process Orchestration/PI oder SAP Integration Suite) zu nutzen, die zwischen Portal und SAP vermittelt. Diese kümmert sich um Protokolle, Formate (IDoc, XML, RFC) und Fehlerhandling, sodass das Portal sich auf die Geschäftslogik konzentrieren kann.

• Zeiterfassungssystem: Falls das Unternehmen für Fremdfirmen ein separates Zeitwirtschaftssystem nutzt (z.B. eine Besuchererfassung oder eine Baustellen-App), sollte eine Schnittstelle geschaffen werden, um die dort erfassten Stunden/Anwesenheiten ins Portal zu übertragen, damit sie in den Prüfprozessen berücksichtigt werden können.

• E-Mail/Notification-System: Für Benachrichtigungen könnte ein bestehender SMTP-Server oder Notification-Service eingebunden werden.

• Active Directory/LDAP: Zur Authentifizierung (speziell für interne Nutzer) kann die Anbindung an das AD für SSO genutzt werden (siehe technische Details Authentifizierung).

• E-Signatur-Dienst: Falls digitale Signaturen für Dokumente genutzt werden (z.B. Vertrag digital unterschreiben lassen, Unterweisungsbestätigung signieren), könnte die Integration eines Dienstes wie Adobe Sign, DocuSign oder einer nationalen Lösung erfolgen. Das Portal übergibt das Dokument an den Signaturdienst und erhält das signierte Dokument zurück.

• Reporting/BI-Tool: Für sehr umfangreiche Auswertungen könnte das Portal die Daten an ein Data Warehouse oder BI-System liefern (z.B. SAP BW oder ein anderes Analytics-Tool), insbesondere wenn Daten über lange Zeit analysiert oder mit anderen KPIs verknüpft werden sollen.

Summa summarum wird das Portal als Drehscheibe fungieren, die Informationen aus verschiedenen Systemen zusammenführt und wieder verteilt. Dadurch entsteht ein integrierter Prozess ohne Medienbrüche. Die Architektur und Schnittstellenbeschreibungen sorgen dafür, dass diese Verbindungen stabil und sicher funktionieren, was im nächsten Abschnitt genauer beschrieben wird.

Eine der großen Stärken des Fremdfirmenportals soll die Automatisierung von Prüfungen sein, um sicherzustellen, dass nur korrekte und verifizierte Leistungen bezahlt werden und dass Abweichungen sofort auffallen.

• Abgleich geleisteter Zeiten: Über die Zutrittsintegration oder Zeiterfassung sammelt das Portal die tatsächlichen Anwesenheits- und Arbeitszeiten der Fremdfirmenmitarbeiter. Parallel erfassen Fremdfirmen oft eigene Stundennachweise oder Tätigkeitsberichte, die Grundlage der Abrechnung sind. Das Portal soll diese Ist-Daten mit den Soll- bzw. gemeldeten Daten abgleichen. Beispielsweise: Ein Mitarbeiter war laut Zugangssystem von 08:05 bis 16:15 Uhr vor Ort (Pausenzeiten bekannt), ergibt 8 Stunden Anwesenheit. Die Fremdfirma reicht aber einen Stundenzettel über 9 Stunden ein. Das System erkennt die Diskrepanz von +1 Stunde und markiert diese zur Prüfung. Dabei können Toleranzen definiert sein (z.B. ±15 Minuten werden ignoriert, um kleine Rundungsdifferenzen abzudecken). Der Zeitabgleich kann auf Personenebene und auf Auftragsebene erfolgen (Summe der Stunden aller Mitarbeiter auf Auftrag X). Stimmen gemeldete und erfasste Zeiten nicht überein, erzeugt das Portal einen Prüfvermerk. Vorteil: Erschlichene Mehrstunden oder irrtümliche Falscherfassungen werden so direkt entdeckt, noch bevor es zur Rechnung kommt.

• Prüfung von Leistungsnachweisen: Neben reinen Stunden können Fremdfirmen auch Leistungsnachweise erbringen, z.B. Montagenachweise, Prüfprotokolle, abgenommenes Werk. Solche Dokumente (oft vom Fremdfirmenpersonal oder Koordinator ausgefüllt und unterschrieben) sollen im Portal erfasst werden – idealerweise elektronisch. Das Portal könnte standardisierte Formulare bereitstellen, die der Fremdfirmen-Verantwortliche nach Abschluss einer Arbeit ausfüllt (z.B. "Arbeitspaket XY am Datum soundso fertiggestellt, Menge der ausgeführten Leistung: 5 Stk."). Der interne Koordinator bestätigt digital die Durchführung und Qualität. Dieser genehmigte Leistungsnachweis wird dann mit dem Auftrag verknüpft. Die Prüfung besteht hier darin, zu überprüfen, ob alle im Auftrag geforderten Leistungen nachgewiesen sind und ob ggf. nicht vereinbarte Leistungen auftauchen. Beispiel: Auftrag war "Reinigung von 100m² Fläche", Leistungsnachweis meldet "120m² gereinigt". Das Portal würde erkennen, dass 20m² über den Auftrag hinausgingen und könnte einen Prozess zur Nachtragsprüfung anstoßen (entweder separate Genehmigung bevor Abrechnung oder Ablehnung der Mehrleistung, je nach Policy).

• Vergleich mit Auftragsbelegen: Jede Abrechnung (ob Stunden oder Einheitspreise) sollte mit den beauftragten Mengen verglichen werden. Das Portal kennt aus der Auftragsverwaltung oder SAP-Bestellung die Soll-Menge (z.B. maximal 100 Stunden vereinbart, oder 10 Stück Equipment). Nun wird verglichen: Summe der geleisteten Stunden bzw. gemeldeten Leistungen. Überschreitungen werden sofort flaggt. Unterschreitungen sind unkritisch, aber ggf. für Kostenplanung relevant. Besonders bei Werkverträgen mit Festpreis ist wichtig, dass nicht mehr in Rechnung gestellt wird als vereinbart. Das Portal kann hier Schutz bieten, indem es z.B. eine Rechnung zurückweist, die Positionen enthält, die nicht im Auftrag stehen oder Mengen übersteigen. Dieser Abgleich entspricht einem 3-Wege-Abgleich: Auftrag – Leistung – Rechnung.

• Positionsabgleich: Die Rechnung wird elektronisch eingelesen (via Schnittstelle aus SAP oder manuell hochgeladen). Das Portal gleicht jede Rechnungsposition mit den im System vorhandenen Leistungsdaten ab. Stimmen Leistungsart, Menge und Preis mit dem Vertrag/Auftrag überein? Sind alle abgerechneten Leistungen vom Koordinator freigegeben? Jede Position erhält einen Status (OK / Abweichung). Beispiel: Rechnung position 1: 8 Stunden à 50€ = 400€. System findet: 8 Stunden geleistet und genehmigt, Preis laut Vertrag 50€ → OK. Position 2: Gefahrgutzuschlag 100€ (aber im Vertrag kein solcher Zuschlag vereinbart) → Abweichung, da keine Grundlage.

• Summen- und Steuerprüfung: Das Portal rechnet die Summen nach, prüft die Mehrwertsteuer (korrekter Satz? mathematisch richtig berechnet?). Dies ist zwar auch Standard in ERP, aber doppelte Sicherheit kann nicht schaden.

• Regel-Compliance: Evtl. Unternehmensrichtlinien können geprüft werden, z.B. "Rechnungen >X € benötigen 4-Augen-Freigabe" – das Portal könnte erkennen, ob diese Freigabe vorliegt (vielleicht analog eines Genehmigungs-Workflows) bevor es "grünes Licht" gibt.

• Freigabeprozess: Nach der automatischen Vorprüfung präsentiert das Portal dem zuständigen internen Freigeber (z.B. dem Auftraggeber oder einer Rechnungsprüferrolle) die Ergebnisse. Sind keine Abweichungen gefunden worden, kann er mit einem Klick die Zahlungsfreigabe erteilen. Diese Freigabe wird dann an SAP übermittelt, woraufhin die Rechnung regulär bezahlt werden kann. Wurden Abweichungen entdeckt, kann das Portal einen Klärungsprozess einleiten: z.B. markiert es die fehlerhaften Positionen und der Fremdfirmen-Verantwortliche bekommt über das Portal die Möglichkeit zur Stellungnahme oder Korrektur. Möglicherweise muss eine Gutschrift oder Korrekturrechnung erstellt werden – dieser Vorgang wäre aber bereits angestoßen, bevor Finance die Rechnung unbearbeitet zahlt.

• Historie und Mustererkennung: Langfristig könnte das System auf Basis der Rechnungsprüfung eine Statistik führen, welche Fremdfirmen wie oft Korrekturen benötigen. Das kann in die Lieferantenbewertung einfließen (z.B. Fremdfirma A stellt regelmäßig falsche Rechnungen → Minuspunkt). Auch wiederkehrende Abweichungsmuster (z.B. immer 1 Stunde mehr als per Zugang erfasst) könnten erkannt werden – möglicherweise sogar als Ansatz für betrugsähnliche Muster, worauf dann gezielt geachtet wird.

Die oben genannten Prüfprozesse machen das Portal zu einem zentralen Kontrollinstrument für Fremdleistungen. Es entlastet insbesondere die Buchhaltung und den Einkauf von zeitaufwändigen manuellen Abgleichen. Zudem schützt es das Unternehmen vor finanziellen Verlusten durch falsche Abrechnung. Im Idealfall führt die Automatisierung dazu, dass Rechnungen, die das System passieren, nahezu fehlerfrei sind und ohne lange Liegezeiten bezahlt werden können – was wiederum die Fremdfirmen zufriedenstellt (pünktliche Zahlung) und die Geschäftsbeziehung verbessert.

Neben den rein zahlenmäßigen Prüfungen trägt diese Automatisierung auch zur Compliance bei, indem es z.B. sicherstellt, dass nur zuvor genehmigte Leistungen bezahlt werden (vier-Augen-Prinzip) und dass etwa interne Kontrollsysteme (IKS) im Finanzbereich erfüllt werden. Es kann darüber hinaus das Risiko von Korruption oder Absprachen verringern, da systemisch transparent ist, welche Leistung von wem genehmigt und bezahlt wurde.

Neben den fachlichen Funktionen sind auch zahlreiche nicht-funktionale Anforderungen an das Fremdfirmenportal zu stellen, um eine zuverlässige, sichere und benutzerfreundliche Nutzung zu gewährleisten:

• Intuitive Bedienoberfläche: Das Portal muss eine webbasierte, moderne Benutzeroberfläche bieten, die auch für ungeübte Benutzer verständlich ist. Die Navigation soll klar strukturiert sein (Dashboard, Menüs für Aufträge, Unterweisungen, etc.), mit einer einheitlichen Designsprache gemäß Corporate Design. Wichtige Informationen sollen auf einen Blick erkennbar sein (z.B. Ampelstatus für Zutritt, ausstehende Aufgaben als Notifications). Durch kurze Ladezeiten und responsive Design soll das Portal sich wie eine Desktop-Anwendung anfühlen, auch wenn es im Browser läuft.

• Mehrsprachigkeit: Da potenziell internationale Fremdfirmen oder fremdsprachige Mitarbeiter das Portal nutzen, sollte zumindest eine zweisprachige Oberfläche (Deutsch/Englisch) unterstützt werden. Inhalte wie Unterweisungen könnten in mehreren Sprachen vorliegen, daher muss die UI dies unterstützen (Anzeige der jeweils passenden Sprachversion).

• Mobile Tauglichkeit: Viele Nutzer (z.B. Koordinatoren vor Ort, Fremdfirmenmitarbeiter) werden nicht immer am PC sitzen. Das Portal sollte daher mobilfähig sein. Entweder durch ein responsives Webdesign, das auf Tablets/Smartphones funktioniert, oder durch dedizierte Mobile Apps (iOS/Android) für bestimmte Funktionen (z.B. Check-in, Unterweisungsquiz, Notifications). Wichtig ist, dass Kernaktionen (z.B. Freigaben erteilen, Zutrittscodes anzeigen) auch unterwegs funktionieren.

• Barrierefreiheit: Die Anwendung sollte möglichst barrierefrei gestaltet werden (im Sinne von BITV/WCAG-Standards). Kontrastreiche Darstellungen, skalierbare Fonts und Bedienbarkeit mit Tastatur sind wünschenswert – auch wenn primär berufliche Nutzer zugreifen, könnten z.B. farbenblinde oder motorisch eingeschränkte Personen darunter sein.

• Konsistenz und Feedback: Überall im Portal soll der Nutzer sofortiges Feedback auf Aktionen erhalten (z.B. "Änderung gespeichert", Lade-Spinner während Verarbeitung). Fehler- und Hilfetexte sind in verständlicher Sprache anzugeben. Zudem sollten wo möglich Hilfefunktionen eingebaut sein (z.B. Info-Icons, die erklären was ein Feld bedeutet, oder ein Link zum Online-Handbuch).

• Konfigurierbarkeit für verschiedene Standorte: Wenn das Portal konzernweit für mehrere Werke eingesetzt wird, sollten Einstellungen wie lokale Notrufnummern, Standortnamen, Ansprechpartner etc. pro Standort konfigurierbar sein, damit jeder User die für ihn relevanten Infos sieht. Dies sollte zentral administrierbar sein.

• Performance: Das System soll auch bei hoher Nutzerzahl und großem Datenvolumen schnelle Antwortzeiten bieten. Als Richtwert sollen typische Benutzeraktionen (z.B. Auftragsliste laden, Personendaten abrufen) in <3 Sekunden erscheinen. Selbst komplexe Reports sollten <10 Sekunden generieren, ggf. mit asynchroner Bereitstellung. Diese Performanceziele gelten für eine Last, die dem realistischen Peak entspricht (z.B. Schichtbeginn morgens: viele Logins gleichzeitig, Tagesreports werden abgerufen etc.).

• Skalierbarkeit: Das Portal muss so entworfen sein, dass es mit dem Unternehmen mitwachsen kann. Anfangs werden evtl. nur wenige Werke und Fremdfirmen angebunden, doch das System sollte ohne Redesign auf Hunderte Fremdfirmen und Tausende externe Benutzer skalieren. Horizontal skalierbare Komponenten (z.B. verteilte Webserver, Datenbankcluster) sind in Betracht zu ziehen. Insbesondere die Verarbeitung von Zutrittsdaten (potenziell jedes Drehkreuz-Signal in Echtzeit) muss auch bei vielen Ereignissen stabil laufen. Cloud-Architekturen bieten hier Vorteile, da Ressourcen bei Bedarf dynamisch erhöht werden können.

• Stabilität und Verfügbarkeit: Für ein produktives Portal, das evtl. 24/7 Einsätze abbilden muss, ist hohe Verfügbarkeit essenziell. Ein Zielwert kann 99,5% Verfügbarkeit im Jahresmittel sein (entspricht max. ~1,8 Tage Ausfall pro Jahr). Geplante Wartungszeiten sollten möglichst kurz gehalten und außerhalb der Hauptnutzungszeiten liegen (z.B. nachts oder am Wochenende). Gegebenenfalls muss eine Cluster-Lösung oder Ausfallsicherung (Failover) implementiert werden, damit ein Serverausfall den Betrieb nicht unterbricht.

• Datenspeicherung: Das System muss große Datenmengen effizient handhaben können: Langjährige Archivierung von Unterweisungsdaten, zigtausende Dokumente (die z.B. als PDFs hochgeladen werden) und sehr viele Log-Einträge. Die Datenbank und der Storage sind entsprechend auszulegen (Stichworte: Partitionierung, Archivierungskonzepte, ggf. Auslagerung historischer Daten in ein Data Warehouse). Dennoch sollten auch ältere Daten schnell abrufbar bleiben, falls sie für Audits gebraucht werden.

• Authentifizierung: Der Zugang zum Portal muss streng gesichert sein. Für interne Nutzer soll Single Sign-On (SSO) angeboten werden, d.h. ein Mitarbeiter meldet sich mit seinem Firmenaccount (z.B. Windows-AD-Konto) an und ist automatisch im Portal authentifiziert. Dies kann via SAML oder OpenID Connect mit dem unternehmensinternen Identity Provider (z.B. Azure AD, Keycloak, ADFS) realisiert werden. SSO erhöht den Komfort und die Sicherheit, da weniger separate Passwörter nötig sind und zentrale Policies (Passwortrichtlinien, 2-Faktor-Authentisierung) auch für das Portal gelten ( Microservices vs. monolithic architecture | Atlassian ). Für externe Nutzer (Fremdfirmen) wird ein getrenntes Authentifizierungssystem bereitgestellt, idealerweise ebenfalls mit hohen Sicherheitsstandards. Jeder externe Benutzer erhält personalisierte Zugangsdaten. Empfohlen wird, Multi-Faktor-Authentisierung für externe Logins zu aktivieren (z.B. Einmal-Code per SMS/Authenticator-App), da der Zugriff übers Internet erfolgt und so besser abgesichert ist.

• Autorisierung: Das Berechtigungs- und Rollenkonzept (siehe oben) muss technisch enforced werden. Jeder API-Call und jede Seitenansicht muss prüfen, ob der Benutzer die nötigen Rechte besitzt. Datenbankabfragen sind so zu filtern, dass ein Nutzer wirklich nur seine erlaubten Datensätze bekommt (z.B. ein Fremdfirmen-Disponent sieht nur Aufträge, die seiner Firma zugeordnet sind). Es sind Rollenprofile zu definieren, die den beschriebenen Rollen entsprechen, und ggf. feingranulare Berechtigungen (z.B. getrennte Rechte für "sehen", "bearbeiten", "freigeben"). Autorisierung soll möglichst in einer zentralen Komponente erfolgen (z.B. im API-Gateway oder mittels eines Authorization Services), um Konsistenz zu gewährleisten.

• Datenverschlüsselung: Alle Kommunikation mit dem Portal erfolgt über TLS-verschlüsselte Verbindungen (HTTPS), insbesondere da sensible Personal- und sicherheitsrelevante Daten übertragen werden. Auch intern zwischen Microservices soll Verschlüsselung oder abgesicherte Netze eingesetzt werden. Darüber hinaus sollten kritische Daten auch verschlüsselt gespeichert werden, zumindest Passwörter (als Hash) und evtl. besonders sensible Dokumente. Wenn z.B. Personalausweiskopien oder Gesundheitsdaten gespeichert würden, könnte man eine Datenbankverschlüsselung in Betracht ziehen, so dass selbst bei einem DB-Dump die Daten geschützt sind.

• Penetration Testing und Härtung: Das Portal wird potentiell aus dem Internet erreichbar sein (für externe Firmen). Daher muss es gegen Cyberangriffe gehärtet sein. Regelmäßige Penetrationstests und Sicherheitsaudits sollten fest eingeplant werden, insbesondere vor dem Produktivstart und dann z.B. jährlich. Die Infrastruktur (Server, Container) ist nach aktuellen Empfehlungen abzusichern (aktuelle Betriebssystem-Patches, Firewall-Regeln, minimal notwendige Dienste). Ein Web Application Firewall (WAF) vor dem Portal kann helfen, gängige Angriffe (SQL Injection, XSS, etc.) abzuwehren.

• Sitzungssicherheit: Benutzer-Sessions sollten bei Inaktivität automatisch ablaufen (Timeout, z.B. 15 Minuten), um Missbrauch zu verhindern. Zusätzlich ist darauf zu achten, dass Session Cookies sicher gesetzt sind (HttpOnly, Secure, SameSite etc.). Falls externe Nutzer an öffentlichen PCs zugreifen, sollte das Portal einen Logout Button deutlich haben und evtl. eine Warnung, wenn man vergisst auszuloggen.

• Audit-Logs Sicherheit: Die erwähnten Audit-Logs müssen ebenfalls vor unbefugtem Zugriff geschützt sein, da sie z.B. Administratoraktionen und personenbezogene Daten enthalten. Idealerweise hat nur eine sehr limitierte Admin-Gruppe Zugriff auf die Roh-Logs, normale Nutzer bekommen sie nur in gefilterter Form (z.B. ihre eigenen Aktionen).

• Datensicherung: Backups der Daten sind natürlich obligat, aber hier auch relevant: Offline-Backups sollten geschützt gelagert sein, da sie sonst ein Leck für vertrauliche Daten wären. Zugriff auf Backups wiederum nur für berechtigte Admins.

(Da diesem Thema ein eigener Abschnitt gewidmet ist, werden hier nur technische/querschnittliche Aspekte angesprochen. Details folgen im Kapitel "Datenschutz- und Compliance-Betrachtung".) Wichtig ist zu betonen, dass das System so ausgelegt sein muss, dass es die Datenschutzgrundverordnung (DSGVO) und andere einschlägige Datenschutzgesetze voll erfüllt.

• Datenminimierung: Es sollen nur die wirklich notwendigen personenbezogenen Daten erhoben und gespeichert werden (Grundsatz der Datensparsamkeit). Die technischen Designs (DB-Schema etc.) berücksichtigen das.

• Zweckbindung: Daten von Fremdfirmen werden nur für die Zwecke verwendet, die im Portal abgebildet sind (Organisation des Fremdfirmeneinsatzes). Eine Nutzung darüber hinaus (z.B. Marketing) ist nicht vorgesehen und technisch unterbunden.

• Speicherbegrenzung: Es werden Konzepte benötigt, wann Daten gelöscht oder anonymisiert werden (z.B. Personaldaten von Fremdmitarbeitern X Jahre nach dem letzten Einsatz automatisch löschen, sofern keine rechtliche Aufbewahrungspflicht mehr besteht). Das System soll eine entsprechende Löschfunktion bzw. Archivierungsfunktion bieten.

• Consent und Information: Ggf. muss beim ersten Registrieren einer externen Person diese einer Datenschutzerklärung zustimmen. Das Portal könnte dies erzwingen (z.B. "Bitte akzeptieren Sie die Datenschutzbedingungen, bevor Sie fortfahren").

• Logging des Datenzugriffs: Wer hat wann welche personenbezogenen Daten eingesehen? Das kann relevant sein, um unberechtigte Zugriffe zu erkennen. Das System sollte zumindest von Administratoren-Aktionen Protokoll führen (z.B. Admin schaut sich Personalakte eines Fremden an – warum?). Möglicherweise muss sowas dem Datenschutzbeauftragten reportbar sein.

• Offene Schnittstellen: Das Portal selbst sollte (neben den spezifischen Integrationen) auch API-Schnittstellen nach außen bieten, um ggf. weitere Applikationen anzubinden. Beispielsweise könnte ein mobiles Workforce-Management-Tool der Fremdfirma Daten aus dem Portal abrufen (wenn autorisiert) – dafür wären gut dokumentierte REST APIs sinnvoll. Dies erhöht die Interoperabilität. Bei der Architektur-Planung (nächstes Kapitel) wird vorgeschlagen, dass das Portal intern ohnehin auf APIs basiert, was das Bereitstellen externer APIs erleichtert.

• Modularität: Die Funktionalitäten sollten möglichst modular aufgebaut sein, sodass zukünftige Erweiterungen oder Änderungen lokal vorgenommen werden können, ohne das gesamte System umzuschreiben. Zum Beispiel könnte man das Unterweisungsmodul getrennt vom Auftragsmodul gestalten. Falls später neue Anforderungen kommen (etwa Integration eines neuen Sicherheits-Scanners am Tor), kann dies als eigenes Modul hinzugefügt werden.

• Konfigurierbarkeit: Unterschiedliche Unternehmensteile oder Standorte haben evtl. leicht unterschiedliche Prozesse. Das System sollte ausreichend konfigurierbar sein, um solche Unterschiede abzubilden, ohne dass der Quellcode geändert werden muss. Zum Beispiel: Checkliste A gilt nur in Werk 1, in Werk 2 eine andere. Oder: Für Dienstleistungsverträge will Abteilung X keine Stundenerfassung, Abteilung Y schon. Solche Dinge sollten durch Einstellungen steuerbar sein (wenn möglich).

• Wartbarkeit: Der Code und die Deployments des Systems müssen so gestaltet sein, dass Updates (Fehlerbehebungen, neue Features) leicht eingespielt werden können. Das erfordert einerseits saubere Softwarearchitektur (Trennung von Anliegen, Tests, Dokumentation), andererseits auch eine geeignete Infrastruktur (Staging-System für Tests, Deployment-Automatisierung).

• Dokumentation: Für Administrierung und für Endnutzer sollte eine ausreichende Dokumentation bereitstehen. Ein Online-Help im Portal für Nutzer (FAQs, Hilfetexte) und eine technische Dokumentation (für Entwickler, Administratoren) sind erforderlich.

Zusammenfassend sollen die nicht-funktionalen Anforderungen gewährleisten, dass das Fremdfirmenportal zuverlässig, sicher und effizient betrieben werden kann und von den Nutzern akzeptiert wird. Gerade Aspekte wie Benutzerfreundlichkeit und Performance sind entscheidend dafür, dass alle Beteiligten das System auch gern verwenden und die analogen Notlösungen (Papier, Excel) ersetzen. Sicherheits- und Datenschutzanforderungen sind in diesem Kontext nicht nur gesetzliche Pflicht, sondern auch wichtig, um Vertrauen zu schaffen – sowohl intern als auch bei den Fremdfirmen, die ihre Daten anvertrauen.

Für die Umsetzung des Fremdfirmenportals wird eine robuste und zukunftsfähige Systemarchitektur vorgeschlagen. Diese muss den oben genannten Anforderungen entsprechen, insbesondere hinsichtlich Integration in bestehende Systeme, Skalierbarkeit und Sicherheit. Im Folgenden werden Architekturüberlegungen präsentiert, u.a. die Eignung eines Microservices-Ansatzes vs. monolithischer Architektur sowie Cloud vs. On-Premises Bereitstellung.

• Präsentationsschicht (Frontend): Eine Web-Portal-Oberfläche, entwickelt mit modernen Webtechnologien (z.B. HTML5/JavaScript mittels React, Angular oder Vue.js). Diese läuft im Browser der Nutzer oder als mobile App und kommuniziert ausschließlich über definierte APIs mit der Backend-Logik. Für bestimmte Nutzer (interne) kann es Single-Sign-On in das Frontend geben; für andere (externe) eine Login-Seite. Die GUI ist responsiv für Desktop und mobil.

• Logikschicht (Backend-Services): Statt einer einzigen großen Anwendung wird empfohlen, den Backend-Server in Microservices aufzuteilen, die jeweils einen abgegrenzten Funktionsbereich abdecken (z.B. Service Unterweisungsmanagement, Service Auftragsmanagement, Service Zutrittskontrolle, Service Rechnungsprüfung etc.). Jeder Microservice kapselt die Geschäftslogik seines Bereichs und hat Zugriff auf die nötigen Daten. Die Microservices kommunizieren untereinander über gut definierte Schnittstellen (in der Regel REST/HTTP oder Messaging). Ein Vorteil dieses Microservice-Ansatzes ist die Unabhängigkeit der Komponenten: neue Versionen eines Services können ausgerollt werden, ohne das gesamte System neu zu deployen, und einzelne Services können bei hoher Last separat skaliert werden. Außerdem ermöglicht es die Technologieflexibilität – jeder Service könnte in der passenden Technologie/Programmiersprache umgesetzt sein (z.B. ein Service in Java, ein anderer in Node.js), solange die Schnittstellen passen (. Das erhöht zwar die Komplexität, bietet aber Agilität und Zuverlässigkeit (ein Fehler in einem Service legt nicht das ganze System lahm).

• Datenhaltung (Persistenzschicht): Hier kommen eine oder mehrere Datenbanken zum Einsatz. Möglich ist ein zentrales relationales DBMS (z.B. PostgreSQL, MS SQL) für die Kerndaten, oder auch pro Microservice eine separate DB (das würde strikt der Microservice-Idee folgen, aber man verliert etwas Konsistenz, wenn Transaktionen über Services gehen). Dokumente (PDFs, Bilder) werden entweder in einem Dateispeicher (mit Backup) oder in einem Objektspeicher (z.B. bei Cloud: S3) gesichert, idealerweise mit Metadaten in der DB. Für bestimmte Anwendungsfälle könnten NoSQL-Datenbanken sinnvoll sein (z.B. eine Zeitreihen-DB für Logdaten oder ein LDAP für Nutzer). Wichtig ist, dass die Daten redundant gesichert und bei Bedarf verschlüsselt sind.

• Integrationsschicht: Um mit SAP und anderen Systemen zu kommunizieren, wird eine Integrationskomponente vorgeschlagen. Dies kann ein dedizierter SAP-Integrationsservice sein, der z.B. alle SAP-bezogenen Calls bündelt. Oder die Integration wird über einen Enterprise Service Bus / Middleware realisiert, der zwischen Portal und SAP vermittelt. In modernen Architekturen könnte man auch auf die API-Economy von SAP setzen (z.B. Nutzung von OData-APIs in SAP S/4HANA oder Cloud Integration in SAP BTP). Da das Portal wahrscheinlich On-Premise-SAP-Systeme ansprechen muss, käme klassisch auch die SAP PI/PO in Frage, die als Middleware fungiert. Entscheidend ist: Diese Schicht entkoppelt die Portal-Entwicklung von SAP-spezifischen Formaten (IDocs, RFC) – der Integrationsservice übernimmt die Übersetzung und Fehlerbehandlung. Ähnliches gilt für die Zutrittskontrolle: dort mag es ein eigenes System mit DB geben – ein Integrationsmodul spricht direkt mit dessen DB oder API, und stellt dem Portal die Funktionen zur Verfügung (z.B. "erstelle Badge für Person X").

• API-Gateway: Vor den Backend-Services wird ein zentrales API-Gateway platziert. Dieses fungiert als einziger Eingangspunkt für alle Client-Anfragen (Browser, App) zum Backend. Das Gateway routet die Anfragen an die zuständigen Microservices und kann weitere Aufgaben übernehmen: Authentifizierung prüfen (z.B. JWT-Token-Validierung), Autorisierung (Zugriffskontrolle), Request-Throttling (Schutz vor Überlast oder Missbrauch), sowie Protokollierung. Für externe APIs kann es das gleiche Gateway nutzen oder ein getrenntes. Die Verwendung eines API-Gateways erhöht die Sicherheit und erleichtert Änderungen (z.B. kann man einen Service-URL ändern, ohne dass die Clients davon wissen – das Gateway leitet einfach um). Typische Implementierungen wären z.B. Kong, Apigee, AWS API Gateway oder NGINX mit entsprechenden Plugins.

• Identitäts- und Zugriffsmanagement: Für SSO und Benutzerverwaltung wird ein Identity Provider benötigt. Im Unternehmenskontext existiert oft ein Microsoft Active Directory oder Azure AD. Dieses kann über Standards (SAML2, OAuth2/OIDC) angebunden werden. Möglicherweise wird eine separate Instanz für externe Nutzer aufgesetzt (z.B. Azure B2B/B2C oder ein IdentityServer), damit externe nicht im internen AD geführt werden müssen. Dieser IdP kümmert sich um die Authentifizierung und stellt Tokens/Claims bereit, welche das Portal (bzw. das API-Gateway) zur Autorisierung nutzt. Passwort-Reset-Funktion für Externe, Multi-Faktor-Optionen, etc. werden hierüber realisiert.

• Monitoring & Logging: Zur Architektur gehört auch ein Monitoring-System (z.B. Prometheus + Grafana, oder CloudWatch, etc.), welches Metriken der Microservices sammelt (CPU, Memory, Responsezeiten) und Alarme generiert bei Problemen. Ebenso ein zentrales Log-Management (z.B. ELK-Stack – Elasticsearch, Logstash, Kibana) um die verteilten Logs zusammenzuführen. Diese Infrastruktur läuft parallel und dient dem Betriebsteam zur Überwachung der Gesundheit des Portals.

Architekturdiagramm (gedanklich): Man kann sich vorstellen: Die Benutzer greifen per Browser durch das Internet/Intranet auf das API-Gateway zu (HTTPS). Das Gateway leitet z.B. einen Aufruf "/orders" an den Auftragsservice weiter, welcher ggf. den Datenbank- und SAP-Integrationsservice anfragt, dann eine Antwort zurückgibt, die der Gateway an den Client schickt. Andere Aufrufe "/training" gehen an den Unterweisungsservice usw. Alle Services registrieren sich beim Gateway mit ihren Routen. Im Hintergrund kommuniziert z.B. der Zutrittsservice mit dem lokalen Zutrittssystem und der Rechnungsservice mit SAP. Alle diese Komponenten könnten in Containern laufen (Docker) orchestriert durch Kubernetes – was eine portable Deployment-Einheit ergibt, die sowohl on-premises auf einem Kubernetes-Cluster als auch in der Cloud (z.B. AWS, Azure) betrieben werden könnte.

Es ist zu prüfen, ob die Komplexität des Microservice-Ansatzes gerechtfertigt ist oder ob ein monolithisches Portal (eine einzige Anwendung, ggf. modular aufgebaut) ausreichen würde.

• Microservices-Vorteile: In einem großen Unternehmen mit vielen Integrationen kann Microservices helfen, Komplexität zu beherrschen. Funktionen können schrittweise implementiert und ausgerollt werden, Teams können parallel an unterschiedlichen Services arbeiten (agile Entwicklung) und das System kann gezielt skaliert werden (z.B. wenn die Zutrittslogs viel Last erzeugen, skaliert man nur den Zutrittsservice hoch). Zudem erhöhen Microservices die Ausfallsicherheit, da ein Fehler in einem Modul (z.B. der Rechnungsprüfung) nicht zwingend das Portal für Unterweisungen beeinträchtigt. Auch Updates werden risikoärmer: neue Version eines Services wird deployt, während andere Services unverändert weiterlaufen, und wenn etwas schiefgeht, kann man gezielt zurückrollen. Unternehmen wie Netflix haben vorgemacht, dass Microservices bei großen Anwendungen Agilität und Skalierung fördern. Für unser Portal bedeutet das: wenn in Zukunft neue Module (vielleicht ein Besucher-Management oder ein Werkzeug-Tracking) hinzukommen, können sie als weitere Services ergänzt werden, ohne die Kernanwendung zu gefährden.

• Microservices-Nachteile: Allerdings bringt dieser Ansatz auch Mehr-Aufwand: Die Infrastruktur mit Gateway, Service Discovery, Container-Orchestrierung etc. muss eingerichtet und beherrscht werden. Entwickler müssen verteilte Systeme entwerfen können (Transaktionen über Service-Grenzen, Resilienz bei Ausfällen, etc.). Das Monitoring und Debugging ist komplexer, da man Logs aus mehreren Orten zusammenführen muss. Für sehr hohe Integrität der Daten kann es auch schwieriger sein, wenn eine Aktion mehrere Services betrifft (Stichwort verteilte Transaktion). Wenn das Entwicklerteam eher klein ist und das Unternehmen keine Erfahrung mit Microservices hat, könnte ein modularer Monolith eine gangbare Alternative sein: d.h. eine einzige Anwendung, aber intern in Module strukturiert. Diese könnte initial schneller umzusetzen sein und weniger Betriebsaufwand bedeuten.

• Cloud-Ansatz vs. On-Premises: Eng verwoben mit der Architekturdiskussion ist die Frage der Deployment-Umgebung. Ein Cloud-Ansatz (z.B. Nutzung einer Public Cloud oder einer Private-Cloud-Infrastruktur) kann Vorteile bringen: automatische Skalierung, weniger eigenes Server-Hardware-Management, einfache Anbindung externer Nutzer. Insbesondere wenn man Microservices wählt, lassen sich diese gut in Cloud-Container-Services oder Kubernetes-Cluster deployen. Cloud-Services könnten auch spezielle Funktionen liefern – etwa hochverfügbare Datenbanken als Managed Service, AI-Services für Bilderkennung (vielleicht Kennzeichenerkennung in Microsoft Azure Custom Vision?).

On-Premises hingegen könnte bevorzugt werden, wenn z.B. aus Datenschutz- oder Konzernsicherheitsgründen keine Cloud erlaubt ist für diese Daten. Die Integration mit den internen Systemen (SAP, Zutritt) ist on-prem oft einfacher, weil die Latenzen gering sind und nicht so viele Tunnel/VPNs nötig. Ein möglicher Kompromiss ist ein Hybrid-Modell: Das Portal (Webserver, App, einige Services) läuft in einer DMZ oder Cloud, aber die Daten bleiben im Unternehmen. Über sichere Kanäle (VPN, API-Gateway mit Tunnel) ruft das Portal intern die SAP-Services ab. So sind die kritischen Datenwege geschützt, während externe Nutzer bequem auf die Portal-UI zugreifen können.

Für dieses Konzept empfehlen wir tendenziell Microservices in einer Hybrid-Cloud: Das Fremdfirmenportal-Frontend und API-Gateway könnten in einer Cloud oder DMZ laufen, sodass externe Zugriffe gut gehandhabt werden. Die Microservices könnten teils in der Cloud laufen, teils on-prem (dort wo Daten es erfordern). Z.B. ein Service, der tiefe SAP-Eingriffe macht, könnte innerhalb des Firmennetzes laufen und vom Gateway angesprochen werden. Andere Services (Unterweisung, Planung) könnten in der Cloud laufen mit regelmäßiger Synchronisation ins Firmennetz.

Für dieses Konzept empfehlen wir tendenziell Microservices in einer Hybrid-Cloud: Das Fremdfirmenportal-Frontend und API-Gateway könnten in einer Cloud oder DMZ laufen, sodass externe Zugriffe gut gehandhabt werden. Die Microservices könnten teils in der Cloud laufen, teils on-prem (dort wo Daten es erfordern). Z.B. ein Service, der tiefe SAP-Eingriffe macht, könnte innerhalb des Firmennetzes laufen und vom Gateway angesprochen werden. Andere Services (Unterweisung, Planung) könnten in der Cloud laufen mit regelmäßiger Synchronisation ins Firmennetz.

• Programmiersprachen/Frameworks: Backend-Services könnten in einer verbreiteten Enterprise-Sprache wie Java (Spring Boot) entwickelt werden – was robust und SAP-nah (SAP nutzt selbst Java in Teilen) sein kann. Alternativ .NET Core (C#) oder Node.js für spezifische Services. Wichtig ist die Langzeitwartbarkeit; daher eher Mainstream-Technologien nutzen, für die es breiten Support gibt. Das Frontend könnte mit Angular oder React gebaut werden; Angular hat z.B. den Vorteil eines klaren Strukturgerüsts, React mehr Flexibilität – hier wäre der Skill der Entwickler ausschlaggebend.

• Datenbank: Ein relationales DBMS ist sinnvoll für die strukturierte Speicherung (z.B. PostgreSQL, da Open Source und sehr zuverlässig; oder Oracle/SQL Server falls Konzernstandard). Für Audit-Logs könnte eine ElasticSearch oder MongoDB parallel genutzt werden, um massenhaft Logs effizient zu speichern und zu durchsuchen.

• API-Standards: RESTful APIs mit JSON sind heutzutage Standard und gut kompatibel. Wo es Sinn ergibt, kann GraphQL erwogen werden (bei komplexen Abfragen, um Daten aggregiert zu holen). Für die SAP-Seite werden vermutlich SOAP (ältere Webservices) oder OData verwendet – dies übernähme aber die Integrationskomponente.

• SSO/Security: Für SSO SAML2.0 oder OIDC – gängige Bibliotheken gibt es für alle Frameworks. JWT (JSON Web Token) könnte als Authentifizierungs-Token zwischen Frontend und Backend verwendet werden. Das Gateway sollte die Token prüfen. Rollen/Claims können im Token enthalten sein.

• Dokumente: Mögliche Integration eines DMS: Falls SAP DVS nicht genutzt wird, könnte das Portal auch ein eigenes Dokumentenrepository haben. Open-Source-DMS wie Alfresco oder direkt SharePoint-Integration sind Optionen, aber vermutlich Overkill, wenn SAP DMS zur Verfügung steht.

• Plattform: Containerisierung mit Docker und Orchestrierung mit Kubernetes (oder OpenShift, wenn schon im Unternehmen). Alternativ Platform-as-a-Service (PaaS) nutzen: z.B. Azure App Services für Web und separate DB-Service.

• API-Gateway: Je nach Budget und vorhandener Tools: Apigee (Google) oder Azure API Management sind mächtige Tools, aber man kann auch in Kubernetes einfache Ingress-Controller + OAuth2-Proxy etc. kombinieren. Wichtig ist, es zentral zu halten.

• Messaging: Für asynchrone Prozesse (z.B. Event "Zutritt erfolgt" in Warteschlange zur Verarbeitung) könnte ein Message-Broker wie RabbitMQ oder Apache Kafka verwendet werden. So könnten Peaks abgefangen und lose Kopplung gefördert werden.

• Reporting: Evtl. Integration von Reporting-Tools oder Verwendung von z.B. Grafana/ Kibana für bestimmte Dashboards. Aber für Enduser-Berichte evtl. PDF-Generierung via Reporting-Engine (JasperReports o.ä.) oder einfach serverseitig generierte PDFs.

Ein externer Mitarbeiter scannt morgens seine Karte am Werkstor. Das Zutrittssystem erkennt ihn und sendet ein Event oder schreibt DB-Eintrag. Der Zutritts-Microservice (on-prem) liest dies und aktualisiert seinen Status, speichert in der Portal-DB "anwesend". Er sendet auch eine Nachricht über den Message-Bus "Person X checked in". Der Zeiterfassungs/Prüfservice bekommt das Event und beginnt Timer. Im Frontend sieht der Werkschutz sofort im Dashboard die Person als anwesend (weil das Frontend z.B. alle 30s die Anwesenheitsliste vom Service abruft oder via WebSocket ein Push bekommt). Der Mitarbeiter geht arbeiten. Im Hintergrund registriert das Portal vielleicht stündlich den Stand. Am Tagesende erfasst die Fremdfirma 8h für ihn im Portal (oder lädt gesammelt eine CSV hoch). Der Prüfservice vergleicht mit Check-in/out – passt. Koordinator sieht in seinem Frontend "Arbeit erledigt, 8h angefallen" und klickt auf Abnahme. Das Portal erzeugt daraus einen Service-Eintrag in SAP (via Integrationsservice). Später kommt die Rechnung; der Rechnungsprüfservice ruft via SAP-Integration die Rechnung ab, vergleicht mit den 8h, passt, markiert alles grün. Der Finanzbuchhalter bekommt im Portal eine Ansicht "Rechnung 4711: alle Prüfungen OK, freigeben?" – er klickt frei. Der Integrationsservice setzt in SAP den Rechnungsstatus auf "frei zur Zahlung". Zahlung läuft wie üblich.

Parallel dazu hat das Unterweisungsmodul vielleicht gemerkt, dass die Person X in einer Woche eine Sicherheitsunterweisung erneuern muss und schickt automatisch eine Erinnerung an die Fremdfirma. Im Portal-Frontend sieht die Fremdfirma zudem bei Person X ein gelbes Warnsymbol (Unterweisung läuft ab). Der Koordinator sieht das ebenfalls. So wird sichergestellt, dass bis zum nächsten Einsatz das erledigt ist.

Dieses Szenario zeigt das Zusammenspiel verschiedener Module und Integrationen, das durch die Architektur orchestriert wird.

Die folgenden Schnittstellen werden vom Fremdfirmenportal bedient bzw. benötigt, um mit anderen Systemen zu interagieren. Für jede Schnittstelle werden Art, Zweck und ggf. verwendete Protokolle umrissen:

• Art: bidirektional, periodisch (evtl. On-Demand bei Personalanlage).

• Zweck: Abgleich von relevanten Personaldaten und Organisationsinformationen zwischen Portal und SAP HR (HCM oder SuccessFactors).

• Mitarbeiterdaten (intern): Das Portal ruft aus SAP HR die Stammdaten der internen Mitarbeiter ab, die als Koordinatoren oder sonstige Benutzer im Portal fungieren. Hierzu kann ein Export aus PA/PD (Personalstamm, Organisationsstruktur) genutzt werden. Mögliches Format: SAP stellt OData-Services zur Verfügung (bei SuccessFactors) oder IDoc/CSV-Exports (bei klassischem HCM). Wichtige Felder: Personalnummer, Name, Abteilung, E-Mail, eventuell Funktion. Diese Daten werden genutzt, um z.B. Ansprechpartnerlisten zu füllen und um Berechtigungen eventuell an der Orga festzumachen. Die Übertragung könnte täglich erfolgen, um neue Mitarbeiter aufzunehmen oder ausgeschiedene zu deaktivieren.

• Externe als Affiliates: Falls SAP HR ein Konzept für externe Personen hat (z.B. "HCM Infotyp 105 – Communication" oder externe Kennungen), könnte das Portal neu registrierte Fremdfirmen-Mitarbeiter an SAP melden. Wahrscheinlicher ist aber, dass diese nur im Portal bleiben, da HR primär interne Mitarbeiter abdeckt.

• Sicherheitsüberprüfung: In manchen Unternehmen müssen externe Personen in einer Sicherheitsdatenbank stehen (z.B. Kontrolle gegen Sanktionslisten oder Werksausweise verwaltet über HR-Subsystem). Sollte so etwas via SAP HR laufen, bräuchte man eine Schnittstelle, um das Ergebnis dieser Prüfungen ans Portal zu geben (z.B. "Person X darf Gelände betreten"). Das könnte als Flag in den Personaldaten kommen.

Protokolle/Technik: RFC/BAPI (SAP On-Prem) oder OData API (SAP Gateway/SuccessFactors). Möglicherweise via SAP PI, die z.B. täglich einen XML-Feed generiert, den das Portal abholt.

• Art: bidirektional (Dokument speichern und laden), on demand.

• Zweck: Ablage von Dokumenten (z.B. Verträge, Zertifikate) im zentralen DMS und Abruf bei Bedarf.

• Dokument Ablage: Wenn ein Nutzer im Portal ein Dokument hochlädt (z.B. neuen Versicherungsnachweis.pdf), kann das Portal via Schnittstelle dieses Dokument in SAP DVS speichern. SAP DVS identifiziert Dokumente meist mit einer Dokumentart und Schlüssel (z.B. DOKAR, DOKNR, DOKVR, DOKTL). Man könnte pro Fremdfirma eine Dokumentnummer in SAP führen. Das Portal ruft z.B. einen BAPI_DOCUMENT_CREATE auf【Imagined】, übergibt das File (vielleicht als Base64) und Metadaten. SAP DVS speichert es in seinem Content Repository. Es liefert eine Dokument-ID zurück, die im Portal gespeichert wird, um später das Dokument wiederzufinden.

• Verknüpfung: Zusätzlich könnte SAP DVS das Dokument an einen SAP-Objektlink hängen (etwa an den Kreditor (Lieferantennummer) oder an einen Equip.-Nr). Das erfordert den entsprechenden Parameter im BAPI.

• Dokument Abruf: Will ein Benutzer im Portal ein bereits gespeichertes Dokument ansehen, fragt das Portal via BAPI_DOCUMENT_CHECKOUT (o.Ä.) das Dokument an. Das SAP-System sendet die Datei, welche dann im Browser zum Download angeboten wird. Alternativ könnte man einen WebDAV-Zugriff realisieren, falls DVS das erlaubt, aber BAPIs sind üblicher.

• Performance: Da Dokumente oft groß sein können, ist auf Performance zu achten. Evtl. caching beliebt: Das Portal könnte zuletzt abgerufene Dokumente zwischenpuffern, wenn das Volumen groß wird.

Protokolle/Technik: SAP RFC über NetWeaver RFC SDK oder WebServices, ggf. via SAP PI. BAPI_DOCUMENT_CREATE2 und BAPI_DOCUMENT_CHECKOUT2 sind Kandidaten. Moderne Alternative: SAP CMIS Adapter (falls vorhanden).

• Art: bidirektional, transaktional.

• Zweck: Austausch von Auftrags-/Bestelldaten, Leistungsrückmeldungen und Rechnungsinformationen zwischen SAP MM und dem Portal.

• Abruf von Bestellungen/Aufträgen: Das Portal kann offene Bestellungen oder Outline Agreements, die für Fremdfirmen relevant sind, aus SAP abrufen. Dazu könnte es z.B. einen IDoc ORDERS Eingang geben oder einen gezielten BAPI-Aufruf (BAPI_PO_GETDETAIL o.ä.) für eine bestimmte Bestellnummer. Diese Daten werden genutzt, um im Portal Auftragsdetails auszufüllen (Positionen, Preise, Limits).

• Anlage Leistungsbuchung: Nach Abschluss eines Auftrags will das Portal einen Service Entry Sheet (Leistungsnachweis) in SAP anlegen (Tcode ML81N normalerweise manuell). Über BAPI_ENTRYSHEET_CREATE kann das Portal die genehmigten Leistungen nach SAP melden. Dabei wird referenziert: Bestellnummer, Leistungsart, Menge, Datum, ggf. Kurztext. SAP erstellt einen Leistungsbeleg mit Nummer, der intern zur Rechnung genutzt wird. Das Portal sollte diese Nummer speichern, um bei Rechnungsprüfung darauf zu referenzieren.

• Rechnungsdaten holen: Sobald eine Eingangsrechnung in SAP erfasst wurde (z.B. via MIRO oder OCR-Tool), kann SAP ein IDoc INVOIC generieren, das die Rechnung und Positionen beschreibt. Das Portal empfängt dieses IDoc (entweder push oder holt es ab) und speichert die Rechnung zu Prüfzwecken. Alternativ bietet SAP auch hier BAPIs (BAPI_INCOMINGINVOICE_GETDETAIL). Wichtig ist, die Verbindung zwischen Rechnung und Auftrag herzustellen (via Bestellnummer und Leistungsbeleg). Das Portal nutzt diese Daten, um seine Prüfregeln anzuwenden.

• Freigabestatus zurückmelden: Wenn das Portal entscheidet, dass eine Rechnung freigegeben werden kann, muss dieser Entscheid nach SAP. Das könnte erfolgen, indem das Portal BAPI_INCOMINGINVOICE_RELEASE aufruft oder einen Workflow-Schritt in SAP abschließt. Je nach SAP-Konfiguration (manche haben das Vier-Augen-Prinzip mit Workflows) könnte man via RFC den entsprechenden Workflow-Event auslösen. In einfacheren Fällen reicht ein Buchungsflag (z.B. das Portal bucht in SAP direkt die Rechnung als geprüft).

• Stammdatenabgleich: Die Kreditorennummer (Lieferantennummer) wird genutzt, um Fremdfirmen im Portal dem SAP zuzuordnen. Das Portal kann via LFA1 Tabelle (Kreditor Stammdaten) zumindest Leserechte haben, um Adressdaten, Bankverbindungen etc. anzuzeigen. Änderungen aus dem Portal (z.B. Fremdfirma aktualisiert Adresse) könnten als Änderungsantrag an SAP gehen – in vielen Firmen will man Lieferantenstammdaten nur über den Einkauf pflegen lassen. Evtl. erzeugt das Portal dann eine Nachricht "bitte in SAP aktualisieren".

• Materialentnahme (optional): Falls Fremdfirmen Material aus dem Lager entnehmen (Werkzeug, Ersatzteile), und man das Portal auch dafür nutzen will: Dann könnte eine Schnittstelle zu SAP MM/WM notwendig sein, um diese Entnahmen zu registrieren. Allerdings ist das möglicherweise außerhalb des Fokus (eher interne Logistikthema).

Protokolle/Technik: Starke Nutzung von IDocs und BAPIs. SAP liefert Standard-IDoc-Typen: ORDERS05, INVOIC02 etc. Diese können via PI oder direkte RFC-Verbindungen ausgetauscht werden.

• Art: bidirektional, teils Echtzeit (für Events).

• Zweck: Synchronisation von Berechtigungen und Abfrage von Zutrittsereignissen zwischen Portal und Zutrittssystem.

• Berechtigungsvergabe: Das Portal sendet an das Zutrittssystem die Information, dass Person X (mit bestimmter ID, z.B. Ausweisnummer) vom Datum/ Uhrzeit A bis B Zutritt hat. Je nach System gibt es dafür APIs oder man schreibt direkt in die DB des Systems. Wenn ein Zutrittskontrollsystem wie Lenel, Kaba, Bosch etc. im Einsatz ist, bieten diese oft SDKs/Webservices. Das Portal müsste Personendaten (Name, Firma, evtl. Foto) und die Berechtigungslevel (welche Türen/Zonen) übergeben. Möglicherweise wird vorab im Zutrittssystem ein Profil "Besucher" oder "Fremdfirma" angelegt, das nur bestimmte Zonen erlaubt. Das Portal würde die Person diesem Profil zuordnen.

• Ausweisdruck: Falls Ausweise gedruckt werden, könnte das Portal den Druck anstoßen (Druckdaten ans Kartendruck-System senden). Oder es wird bei Registratur vor Ort gedruckt mit den vom Portal bereitgestellten Daten.

• Event-Abholung: Das Portal möchte wissen, wer eingecheckt hat. Viele Zutrittssysteme speichern jedes Ereignis (Karte gelesen, Zutritt gewährt/verweigert) in einer Datenbank oder loggen es an einen Syslog. Die Portal-Schnittstelle könnte z.B. alle 1 Minute die DB-Tabelle nach neuen "Zutritt OK"-Events abfragen (gefiltert auf Fremdfirmen, z.B. nach Ausweisnummern). Besser ist evtl. ein Push: Manche Systeme erlauben Trigger oder eine Socket-Verbindung, um Events in Echtzeit zu liefern. Das Portal-Service würde dann pro Event eine kleine Verarbeitung machen (Status setzen, Loggen). Alternativ kann, falls direkte DB-Queries unsicher sind, ein Middleware-Service im Sicherheitsnetz diese ausführen und ans Portal schicken.

• Zufahrts-Kennzeichenerkennung: Hier wird vermutlich ein separates System (LPR-System) genutzt, das erkannte Kennzeichen in eine DB schreibt. Das Portal könnte im Voraus eine Liste erlaubter Kennzeichen an dieses System schicken (Whitelist mit Zeitfenster). Und wiederum Events "Kennzeichen XY erkannt -> Schranke geöffnet" abholen. Oft sind LPR-Systeme mit dem Zutrittskontrollsystem gekoppelt, dann findet die Integration indirekt statt (Kennzeichen wird vom Zutrittssystem wie ein Ausweis behandelt). In dem Fall reicht die obige Person-Berechtigungs-Integration plus im Zutrittssystem hat jeder Fahrzeughalter evtl. eine Dummy-Person mit Kennzeichen als ID.

• Video/CCTV: Keine direkte Schnittstelle notwendig, außer evtl. ein URL-Link. Das Portal könnte pro sicherheitskritischem Ereignis einen Link zu einer Kameraaufnahme generieren, aber dafür muss es die Kamera ansprechen können. Möglicherweise gibt es RTSP-Streams, die ins Portal eingebettet werden könnten, aber das wäre tiefgehend. Wahrscheinlicher: Nur meta-integriert (Portal speichert Kamera-ID und Timestamp, ein Sicherheitsmitarbeiter nutzt das dann manuell im Videosystem).

Protokolle/Technik: Herstellerabhängig. Datenbankzugriff (ODBC/JDBC) oder REST API falls vorhanden. Eventuell OPC UA Standard in Industrieumgebungen (zur Maschinendatenauslese, aber bei Zutritt selten). Wenn das Zutrittssystem keine Schnittstelle hat, müsste man kreativer werden (CSV-Exporte importieren, etc., was unsauber wäre). Daher bei Systemauswahl drauf achten.

• Art: ausgehend (vom Portal zum Mail/SMS-System).

• Zweck: Versenden von Benachrichtigungen an Benutzer.

• E-Mail: Das Portal verbindet sich mit dem unternehmenseigenen SMTP-Server, um E-Mails zu verschicken (z.B. noreply@firma.de). Hierzu braucht es die Serveradresse, Port, Authentifizierungsmethode (sofern nötig). E-Mails können HTML-Format haben, um ansprechende Benachrichtigungen zu senden. Alternativ könnte ein Mail-Microservice (z.B. auf Basis von SMTP libraries) implementiert sein.

• SMS: Falls kritische Meldungen per SMS gewünscht sind (z.B. Alarm, Sperrung), wird ein SMS-Gateway-Service benötigt. Das kann ein externer Provider sein (angebunden über HTTPS API) oder eine interne SMS-Server. Das Portal ruft diese API mit Zielnummer und Text auf, wenn eine SMS versendet werden soll.

• Push Notifications: Falls Mobile App, die Push nutzt: Dann Schnittstelle zu Apple APNS und Google FCM nötig. Evtl. übernimmt das der mobile Teil direkt.

Protokolle/Technik: SMTP (für Mail, via TLS). REST/HTTP for SMS provider (JSON payload).

• Art: eingehend (Portal nutzt ID-Provider), Protokoll-getrieben.

• Zweck: Single Sign-On für interne Benutzer, Auth für Externe.

• SSO intern: Das Portal ist beim unternehmensweiten Identity Provider (z.B. ADFS oder Azure AD) als Service Provider registriert. Wenn ein interner Nutzer das Portal aufruft, wird er zum IdP umgeleitet (SAML Request). Nach erfolgreicher Windows-Auth bekommt das Portal ein SAML Assertion mit den User-Claims (Name, Email, Rollen evtl.). Das Portal erstellt daraus eine Session/JWT. Alle weiteren Requests sind dann authentifiziert. Ähnlich mit OAuth2: Das Portal könnte OIDC nutzen, wo es einen Authorization Code Flow mit dem IdP durchläuft.

• Externe Nutzer-Auth: Für Fremdfirmen-Nutzer, die keinen AD-Account haben, muss das Portal selbst Benutzer verwalten oder einen externen IdP nutzen. Eine Option: Nutzung von Azure AD B2C, wo externe sich registrieren und anmelden können (mit E-Mail + Passwort oder Social Login). Das Portal würde auch hier OIDC nutzen. Alternativ ein eigenständiger Nutzerstamm im Portal (Datenbank mit Passwort-Hashes) – dann aber auf sichere Passwortspeicherung achten und ggf. 2FA implementieren.

• Provisionierung: Wenn z.B. ein interner Mitarbeiter erstmalig das Portal nutzt, muss er in Portal-Datenbank als Benutzer angelegt werden. Das könnte on-the-fly passieren: SSO liefert seine Kennung, Portal checkt "kennt ich nicht" und legt Grunddaten an (Name, E-Mail aus SAML). Rollen müssten ggf. ein Admin später zuteilen. Oder man koppelt es mit HR-Position (z.B. jeder in Arbeitssicherheit bekommt automatisch Rolle X).

• Abmeldung: Es sollte eine Single Logout Implementierung geben – zumindest Portal-Session invalidieren, optional auch IdP-Logout.

Protokolle/Technik: SAML 2.0 (XML over HTTP Redirect/POST), OAuth2/OIDC (JSON over HTTP). Libraries: z.B. Spring Security SAML, or MSAL for .NET.

• Mobile Device Management (MDM): Falls eine App verwendet wird, und Geräte verwaltet, könnte eine Schnittstelle zu einem MDM (z.B. Microsoft Intune) relevant sein, aber wahrscheinlich out-of-scope.

• Enterprise Service Bus (ESB): Wenn vorhanden (TIBCO, MuleSoft etc.), könnte das Portal statt direkt mit SAP/others zu reden, an den ESB publizieren. Dann bräuchte es definierte JMS-Queues oder SOAP-Endpoints auf dem ESB.

• External Web Services: Eventuell Rechtsdaten (z.B. Prüfung auf Sanktionslisten via Webservice des Bundesanzeigers) – eher unwahrscheinlich, aber falls, dann entsprechender API-Call.

• Active Directory LDAP: Für den Fall man will doch externe im AD führen, gäbe es LDAP-Sync – aber das ist unüblich, man trennt das lieber.

Die Schnittstellen sind insgesamt so zu gestalten, dass sie fehlertolerant arbeiten. D.h. wenn SAP mal nicht erreichbar ist, sollte das Portal nicht abstürzen, sondern z.B. eine Wartemeldung zeigen oder es später erneut versuchen (Queueing). Insbesondere beim Event-Handling (Zutritt) muss man Puffern (z.B. falls Portal offline, Ereignisse später nachladen).

Jede Schnittstelle sollte in einer technischen Dokumentation konkret beschrieben werden (genaue Feld-Zuordnungen, IDoc-Formate, Endpoint-URLs etc.), was aber den Rahmen des Fachkonzepts hier überschreiten würde. Wichtig ist: Die Integrationen tragen wesentlich zum Nutzen des Portals bei, daher müssen sie sehr sorgfältig geplant und getestet werden.

Der Umgang mit personenbezogenen Daten und sensiblen Betriebsinformationen im Fremdfirmenportal erfordert strikte Beachtung von Datenschutzgesetzen (insb. DSGVO) sowie internen Compliance-Regeln. Nachfolgend werden die wichtigsten Aspekte und Maßnahmen dargelegt:

Rechtsgrundlagen: Die Verarbeitung personenbezogener Daten im Portal (Namen, Kontaktdaten, Qualifikationen, Zutrittszeiten, evtl. Kfz-Kennzeichen und Videoaufnahmen) bedarf einer Rechtsgrundlage nach DSGVO. In der Regel ist dies Art. 6(1)(b) DSGVO (Vertragserfüllung), da die Datenverarbeitung zur Erfüllung des Dienstleistungsvertrags mit der Fremdfirma notwendig ist (z.B. Person X darf nur arbeiten, wenn unterwiesen). Teilweise greift auch Art. 6(1)(c) DSGVO (rechtliche Verpflichtung), etwa für Arbeitsschutzvorschriften, oder Art. 6(1)(f) (berechtigtes Interesse) des Betreibers an Sicherheit und Schutz seines Eigentums. Bei besonderer Kategorie Daten (Gesundheitsdaten wie Vorsorgeuntersuchungen) wäre Art. 9(2)(b) relevant (Arbeitsrecht, Arbeitsschutz). Das Unternehmen sollte einen Verarbeitungsverzeichnis-Eintrag für das Portal anlegen, in dem Zweck, Datenarten, Rechtsgrundlagen etc. dokumentiert sind.

Einwilligung: Soweit möglich, sollte man ohne Einwilligung auskommen, indem man sich auf obige Grundlagen stützt – denn Einwilligungen von Mitarbeitern sind oft problematisch (Abhängigkeitsverhältnis). Allenfalls bei optionalen Daten (z.B. Foto für Ausweis) könnte man eine freiwillige Einwilligung einholen.

Informationspflichten: Gemäß Art. 13 DSGVO müssen die betroffenen Personen (also externe Mitarbeiter) über die Datenverarbeitung informiert werden. Praktisch bedeutet das: Es wird eine Datenschutzerklärung fürs Portal erstellt, die dem Nutzer bei erster Registrierung angezeigt wird. Diese erläutert, welche Daten zu welchem Zweck erhoben werden, wer Verantwortlicher ist, wie lange gespeichert, und welche Rechte die Person hat. Die Fremdfirma sollte zudem in ihren Verträgen regeln, dass sie ihre Mitarbeiter über die Weitergabe der Daten an unser Portal informiert – idealerweise werden die Infos aber direkt an die Person gegeben (Portal-Login-Seite könnte einen Link "Datenschutzinformationen" haben).

Zweckbindung und Umgang mit Daten: Die im Portal erhobenen Daten dürfen ausschließlich für die Zwecke des Fremdfirmenmanagements verwendet werden. Es ist insbesondere untersagt, die Daten zu anderen Zwecken zu nutzen, z.B. Marketing oder völlig fachfremde Analysen. Eine Auswertung könnte z.B. an Grenzen stoßen, wenn plötzlich personenbezogene Leistungsdaten für etwas anderes genutzt würden. Das sollte intern durch Richtlinien geregelt sein (ggf. Betriebsvereinbarung, siehe unten).

• Personenbezogene Daten von Fremdfirmenmitarbeitern: Können gelöscht werden, sobald klar ist, dass diese Person nicht mehr aufs Gelände kommen wird und keine gesetzlichen Aufbewahrungsfristen entgegenstehen. Z.B. könnte man definieren: 2 Jahre nach dem letzten Einsatz werden Personalprofile anonymisiert oder gelöscht. Allerdings muss man beachten, dass z.B. Unfallberichte oder sicherheitsrelevante Vorfälle länger aufbewahrt werden sollten (ggf. 5-10 Jahre, orientiert an Verjährungsfristen).

• Zutrittsdaten und Video: Videoaufzeichnungen sind nach diversen Vorgaben sehr kurz aufzubewahren, meist nur wenige Tage, sofern kein Vorfall. Kennzeichendaten ebenfalls nicht länger als nötig (z.B. Löschung nach einem Tag, wenn rein zur Einfahrtsteuerung genutzt). Zutrittslogs könnten länger aufbewahrt werden (für Zeitabrechnung oder Nachvollziehbarkeit), jedoch sollte man auch hier eine Grenze ziehen (vielleicht 1-2 Jahre). Das Portal sollte daher automatische Löschroutinen haben: z.B. täglicher Job, der alle Ereignisdaten älter 2 Jahre aus der DB entfernt, außer markierte Vorfallsdaten.

• Vertrags- und Abrechnungsdaten: Unterliegen handels- und steuerrechtlichen Aufbewahrungspflichten (i.d.R. 6 bzw. 10 Jahre in Deutschland). Diese Daten (Rechnungen, Leistungen, Verträge) müssen so lange gespeichert bleiben, ggf. in Archiv. Das Portal kann hier mit dem DMS/SAP zusammenarbeiten (SAP FI sichert Rechnungen 10 Jahre).

• Unterweisungsnachweise: Arbeitsschutzrechtlich ist es sinnvoll, Nachweise lange aufzubewahren (um bei Spätfolgen noch belegen zu können). Aber personenbezogen darf man nicht ewig alles halten. Eine mögliche Lösung: nach Ausscheiden einer Person werden Unterweisungsdaten in Statistik überführt (entpersonalisiert) und der Personenbezug gelöscht nach einigen Jahren.

Datensicherheit (Art. 32 DSGVO): Technische und organisatorische Maßnahmen (TOMs) müssen das Schutzniveau garantieren. Hier hatten wir schon vieles in Architektur und Security: Zugriffsbeschränkung (Role-Based Access Control), Verschlüsselung, regelmäßige Backups, Schutz vor unbefugtem Zugang (Netzwerk-Security). Ein wichtiger Aspekt ist Privacy by Design und by Default (Art. 25 DSGVO): Das Portal ist so zu gestalten, dass Datenschutzvoreinstellungen wirksam sind – z.B. sind sensible Felder standardmäßig verborgen, Admins sehen nur was nötig. Logs anonymisieren wenn möglich (vielleicht zeigt man im Frontend dem Koordinator nicht die vollen Besuchernamen anderer Aufträge, etc.).

Auftragsverarbeitung: Die Fremdfirmen geben Daten ihrer Mitarbeiter ins Portal ein, was von uns betrieben wird – streng genommen sind wir für diese Daten Verantwortlicher (da es unser Portal ist und wir Zweck bestimmen). Allerdings könnten wir auch als Dienstleister für die Fremdfirma fungieren? Diese Konstruktion ist tricky: Wahrscheinlich gilt unser Unternehmen als Verantwortlicher, weil es um den Zutritt zum eigenen Werk geht. Dennoch, falls ein externer Cloud-Dienst beteiligt ist (z.B. Cloud-Hosting des Portals), dann wären die ein Auftragsverarbeiter für uns und es bräuchte entsprechende Verträge (AVV). Auch mit Fremdfirmen sollte im Vertrag geregelt sein, dass wir Daten ihrer Mitarbeiter verarbeiten – das fällt aber unter Vertragserfüllung. Eine genaue Abstimmung mit dem Datenschutzbeauftragten ist hier nötig.

• Auskunft (Art. 15 DSGVO): Wenn ein externer Mitarbeiter wissen will, welche Daten über ihn gespeichert sind, muss das Unternehmen dies innerhalb 1 Monat liefern. Das Portal sollte hierfür einen Export bereitstellen können (alle seine Personaldaten, Einsätze, Zeiten, etc.). Wahrscheinlich würde die Anfrage formal über die Fremdfirma oder direkt an uns gehen, der DSB wertet dann Portal-Daten aus. Ein Self-Service "Meine Daten exportieren" wäre benutzerfreundlich, aber hier evtl. zu viel.

• Berichtigung (Art. 16): Personen haben Recht auf Korrektur falscher Daten. Das Portal soll ermöglichen, Stammdaten leicht zu ändern (idealerweise tun das ja die Fremdfirmen selbst aktuell halten). Kritische verifizierte Daten (z.B. Zertifikate) kann man natürlich nicht einfach ändern, da müsste ein neues Dokument hochgeladen werden.

• Löschung (Art. 17): Wenn jemand Löschen verlangt, muss geprüft werden, ob Aufbewahrungspflichten dem entgegenstehen. Ggf. kann man die Person sperren (nicht mehr einsetzbar) und Daten nach Frist löschen.

• Einschränkung (Art. 18): Könnte vorkommen, wenn Streit über Richtigkeit besteht – eher selten in diesem Kontext.

• Widerspruch (Art. 21): Wenn auf berechtigtem Interesse basiert, könnten Personen Widerspruch einlegen gegen z.B. Video/Tracking. Dann muss man im...ng:** Sollte ein externer Mitarbeiter Widerspruch gegen bestimmte Verarbeitungen einlegen (Art. 21 DSGVO) – etwa gegen dauerhafte Speicherung seiner Zutrittszeiten – wird das Unternehmen diesen prüfen. Da die Datenverarbeitung hier jedoch meist der Sicherheit und Vertragsabwicklung dient, kann in der Regel ein zwingendes berechtigtes Interesse geltend gemacht werden, um die Verarbeitung fortzuführen. Dennoch müssen solche Anfragen sorgfältig und einzelfallbezogen vom Datenschutzbeauftragten bewertet werden.

Datenschutz-Folgenabschätzung: Aufgrund der umfangreichen Überwachungstätigkeiten (Zutrittskontrolle, Leistungsdaten, ggf. Video) ist eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO angezeigt. Eine DSFA analysiert die spezifischen Risiken für die Rechte der Betroffenen und beschreibt Maßnahmen, diese Risiken zu mindern. Beispielsweise wird bewertet, ob die kombinierte Auswertung von Leistungsdaten und Zutrittszeiten eine Profilbildung darstellt und wie Missbrauch ausgeschlossen wird. Die DSFA sollte idealerweise vor Live-Schaltung des Systems durchgeführt werden, inkl. Konsultation des Datenschutzbeauftragten und ggf. der Aufsichtsbehörde, falls hohe Risiken nicht anders beherrschbar sind.

Betriebsrat und interne Compliance: Die Einführung des Fremdfirmenportals berührt auch die Mitbestimmungsrechte des Betriebsrats. Gemäß § 80 BetrVG muss der Betriebsrat Maßnahmen zur Unfallverhütung und Gesundheitsschutz mit überwachen, und insbesondere nach § 87 Abs. 1 Nr. 6 BetrVG hat er ein Mitbestimmungsrecht bei Einführung von technischen Einrichtungen, die dazu geeignet sind, das Verhalten oder die Leistung von Mitarbeitern zu überwachen. Auch wenn das Portal primär fremde Mitarbeiter erfasst, so verarbeitet es doch Daten im Betriebsablauf und könnte indirekt zur Überwachung interner Abläufe genutzt werden (z.B. Kontrolle, welcher Koordinator etwas wann freigab). Daher wird von Beginn an eine enge Einbindung des Betriebsrats erfolgen. Idealerweise wird eine Betriebsvereinbarung zum Fremdfirmenportal abgeschlossen, die Zweck, Umfang und Grenzen der Datennutzung festlegt. Darin kann z.B. geregelt werden, welche Daten genau erfasst werden, wer Zugriff hat, wie lange sie gespeichert werden und dass keine Verhaltenskontrolle der Stammbelegschaft beabsichtigt ist. Diese transparente Regelung stellt sicher, dass die Einführung sozialverträglich geschieht und Akzeptanz findet. Der Betriebsrat wird so seiner Rolle gerecht, eine ordnungsgemäße Integration der Fremdfirmen zu unterstützen.

Interne Richtlinien und Schulungen: Organisatorisch ist sicherzustellen, dass alle Beteiligten die Vertraulichkeit der im Portal einsehbaren Daten wahren. Internen Nutzern ist bewusst zu machen, dass z.B. personenbezogene Daten der Fremdfirmenmitarbeiter nur für den definierten Zweck verwendet werden dürfen. Eine entsprechende Schulung in Datenschutz und Informationssicherheit ist Teil der Einführungsmaßnahmen. Zudem müssen Fremdfirmen vertraglich verpflichtet werden, die erhaltenen Daten (z.B. Einsatzpläne) nicht zweckfremd zu nutzen.

Das Portal unterstützt Compliance-Anforderungen in vielerlei Hinsicht: Es erleichtert die Einhaltung von Arbeitsschutzgesetzen, dokumentiert die Erfüllung von Betreiberpflichten (wichtig bei behördlichen Überprüfungen) und verbessert die Kontrolle im Finanzwesen (Vier-Augen-Prinzip bei Rechnungsfreigaben, was auch im Sinne interner Kontrollsysteme und ggf. SOX-Compliance relevant ist). Gleichzeitig müssen die Entwickler und Betreiber des Systems gewährleisten, dass diese Daten nicht selbst neue Compliance-Probleme schaffen – daher die strenge Beachtung von Datenschutz und Mitbestimmung.

Nach der Implementierung muss das Fremdfirmenportal zuverlässig betrieben und gewartet werden. Dieser Abschnitt beschreibt, wie der laufende Betrieb organisiert wird, inklusive Support, Wartung, Weiterentwicklung und Kostenaspekte

Je nach zuvor getroffener Architekturentscheidung wird das Portal entweder on-premises im Rechenzentrum des Unternehmens oder in einer Cloud-Umgebung betrieben. In beiden Fällen sind Hochverfügbarkeit und Ausfallsicherheit zu gewährleisten. Bei on-premises Hosting wird man vermutlich virtuelle Server oder ein Kubernetes-Cluster auf vorhandener Infrastruktur nutzen. Ein Cluster aus mindestens zwei Knoten kann die Microservices tragen, sodass bei Wartung eines Knotens der andere den Betrieb auffängt. Bei Cloud-Deployment (z.B. Microsoft Azure, AWS oder einer Private Cloud) sollte auf verteilte Zonen geachtet werden – das Portal könnte in zwei geografisch getrennten Rechenzentren gespiegelt laufen, um auch vor Standortausfällen sicher zu sein.

Je nach zuvor getroffener Architekturentscheidung wird das Portal entweder on-premises im Rechenzentrum des Unternehmens oder in einer Cloud-Umgebung betrieben. In beiden Fällen sind Hochverfügbarkeit und Ausfallsicherheit zu gewährleisten. Bei on-premises Hosting wird man vermutlich virtuelle Server oder ein Kubernetes-Cluster auf vorhandener Infrastruktur nutzen. Ein Cluster aus mindestens zwei Knoten kann die Microservices tragen, sodass bei Wartung eines Knotens der andere den Betrieb auffängt. Bei Cloud-Deployment (z.B. Microsoft Azure, AWS oder einer Private Cloud) sollte auf verteilte Zonen geachtet werden – das Portal könnte in zwei geografisch getrennten Rechenzentren gespiegelt laufen, um auch vor Standortausfällen sicher zu sein.

• Die IT-Abteilung (bzw. ein dediziertes DevOps-Team für das Portal) ist für die technische Verfügbarkeit zuständig. Dazu gehören das Infrastruktur-Management (Server, Netzwerk, Datenbanken), die Überwachung der Systemgesundheit, das Einspielen von Updates und Security-Patches sowie das Backup/Restore-Management.

• Ein oder mehrere Anwendungsbetreuer auf Fachseite (z.B. aus der Arbeitssicherheit oder Werkssicherheit) fungieren als Key User. Sie kennen die fachlichen Prozesse genau und stehen als Ansprechpartner zur Verfügung, wenn Nutzer Fragen haben oder Probleme melden (z.B. „Mein Mitarbeiter kann sich nicht registrieren“ oder „eine Unterweisung wird nicht als erledigt angezeigt“). Sie leiten auch Anforderungen für Verbesserungen an die IT weiter.

• Es sollte ein Support-Konzept definiert sein: z.B. First-Level-Support bei einfachen Nutzerfragen (Passwort vergessen, Bedienungsfragen) könnte beim zentralen IT-Helpdesk liegen. Dieser sollte mit FAQ-Lösungen zum Portal vertraut sein. Zweiter Level wären dann die Anwendungsbetreuer oder Administratoren, die tiefere Probleme untersuchen. Kritische Incidents (z.B. Systemausfall, Integrationsfehler mit SAP) gehen direkt an das DevOps-Team, das 3rd-Level-Support bietet.

• Für externe Nutzer (die nicht direkt den internen Helpdesk kontaktieren können/wollen) sollte es ebenfalls eine Supportmöglichkeit geben. Das könnte eine spezielle Support-Hotline oder E-Mail für Fremdfirmen sein, die von den Anwendungsbetreuern betreut wird. Alternativ kann man im Portal ein Ticket-System integrieren, wo Fremdfirmen Fragen einstellen.

Updates und Patches: Die Software des Portals (sowie die darunterliegende Plattform) benötigt regelmäßige Updates. Sicherheitsupdates (z.B. für das Betriebssystem, Datenbank, Webserver) sollten zeitnah eingespielt werden – hierfür können festgelegte Wartungsfenster definiert werden, z.B. am Wochenende nachts. Falls die Anwendung dafür kurz gestoppt werden muss, sind Nutzer rechtzeitig zu informieren. Bei Microservices kann man Rolling Updates nutzen, um Downtime zu minimieren (Service für Service neu starten). Funktionsupdates (neue Features) wird man eher gesammelt in Releases ausrollen, nachdem sie getestet und vom Fachbereich abgenommen wurden. Je nach Bedarf könnte es quartalsweise Releases geben oder nach agil entwickelten Sprints häufiger.

Monitoring: Ein kontinuierliches Monitoring ist eingerichtet, um den Gesundheitszustand des Systems zu beobachten. Diverse Metriken (CPU-Auslastung, Speicher, Antwortzeiten der wichtigsten API-Calls, Anzahl gleichzeitiger Nutzer, Fehlerraten) werden überwacht. Bei Abweichungen (z.B. plötzlich sehr hohe Antwortzeiten oder Ausfall einer Komponente) lösen automatische Alarme aus, die das Bereitschaftsteam informieren (per SMS/Monitoring-App). So kann oft proaktiv eingegriffen werden, bevor Benutzer stark beeinträchtigt sind. Ebenso werden Integrationspunkte überwacht – z.B. wenn 10 Minuten lang keine Verbindung zu SAP möglich ist, sollte ein Alarm erfolgen, da sonst z.B. Rechnungsprüfungen steckenbleiben.

Backup und Recovery: Alle relevanten Datenbanken und Dokumentenspeicher werden in regelmäßigen Abständen gesichert (Backup). Üblich wäre tägliches inkrementelles und wöchentlich volles Backup, mit Aufbewahrung für X Tage. Kritische Konfigurationsdaten des Systems (z.B. API-Schlüssel, IdP-Zertifikate) werden ebenfalls gesichert. Ein Disaster-Recovery-Plan existiert: darin ist festgelegt, wie im Falle eines Totalausfalls (z.B. Serverraum-Brand oder schwerer Systemfehler) vorzugehen ist, um das Portal schnellstmöglich wiederherzustellen. Man könnte z.B. innerhalb 4 Stunden ein Ersatzsystem in der Cloud hochfahren, die Backups einspielen und dann wieder online gehen. Diese Verfahren sollten regelmäßig getestet werden (mindestens jährlich eine Notfallübung "Recovery-Test"), um sicherzustellen, dass im Ernstfall alles klappt.

Performance Tuning und Kapazitätsmanagement: Über die Zeit können sich Nutzungsmuster ändern (vielleicht steigen die Fremdfirmen-Einsätze an, oder neue Module belasten die DB stärker). Das Betriebsteam muss daher regelmäßige Kapazitätsplanungen durchführen. Monitoring-Auswertungen zeigen Trends (z.B. Speicher wird knapp, Datenbank reagiert langsamer bei >1 Mio Datensätzen). Gegebenenfalls werden Skalierungsmaßnahmen ergriffen: Weitere Server hinzufügen, Datenbank aufrüsten oder Archivierungen einführen, um Performance stabil zu halten. Lasttests könnten nach größeren Änderungen gefahren werden, um sicher zu sein, dass das System weiterhin Reserven hat.

Störungsmanagement und Kontinuität: Im Falle einer Störung gibt es klar definierte Prozesse (Incident-Management gemäß ITIL oder interner Standards). Jeder Vorfall wird dokumentiert, analysiert und nach Möglichkeit Verbesserungsmaßnahmen abgeleitet (Problem-Management), um Wiederholung zu vermeiden. Beispielsweise, wenn die Schnittstelle zum Zutrittssystem öfter hakt, könnte man eine bessere Fehlertoleranz implementieren oder mit dem Hersteller des Zutrittssystems nachbessern. Das Ziel ist ein verlässlicher Dauerbetrieb, da das Portal zu einer kritischen Anwendung wird (wenn Zutrittssteuerung dranhängt, würde ein Ausfall im schlimmsten Fall bedeuten, dass Fremdfirmen nicht aufs Gelände kommen können – was Produktionsverzögerungen verursacht).

Weiterentwicklung: Wartung umfasst nicht nur das Beheben von Fehlern, sondern auch das Evolving des Systems. Gesetzesänderungen (z.B. neue Vorschriften in Arbeitsschutz) müssen zeitnah eingearbeitet werden. Ebenso wird es Nutzerfeedback geben, das sinnvolle Verbesserungen anregt. Dafür sollte ein Change-Management-Prozess etabliert sein: Fachseite sammelt Anforderungen, priorisiert sie, die IT schätzt Aufwand ab und implementiert in künftigen Releases. Es bietet sich an, ein steuerndes Gremium einzurichten, z.B. ein kleiner "Product Governance Board" aus Vertretern von HSE, Einkauf, IT, Betriebsrat, das halbjährlich die Weiterentwicklung priorisiert, damit das Portal stets den aktuellen Bedürfnissen entspricht.

Kosten und Ressourcen: Im Betrieb fallen Kosten für Infrastruktur (Server, Cloud-Abos), Lizenzen (falls kommerzielle Software im Einsatz, z.B. Datenbank oder API-Gateway), sowie Personalressourcen für Support/Wartung an. Diese sind im Budget einzuplanen. Möglicherweise können gewisse Synergien genutzt werden – z.B. läuft das Portal auf vorhandenen Kubernetes-Clustern mit, oder teilt sich die Datenbank-Server mit anderen Anwendungen – das wäre aber nur, wenn Performance nicht leidet. Auch der Aufwand für Support der externen Nutzer sollte nicht unterschätzt werden; hier kann es saisonale Spitzen geben (z.B. viele Fremdfirmen gleichzeitig bei Revisionen im Werk -> viele neue Konten auf einmal). Darauf sollte das Supportteam vorbereitet sein.

Durch einen professionellen Betrieb und kontinuierliche Wartung wird sichergestellt, dass das Fremdfirmenportal langfristig zuverlässig arbeitet und die gesteckten Ziele nachhaltig erfüllt. Außerdem bleibt es so stets konform mit neuen Anforderungen, sei es technisch (Security-Updates) oder fachlich (Gesetzesänderungen), was essentiell für die Akzeptanz und den Nutzen des Systems ist.

• Fremdfirma / Fremdunternehmen: Externes Unternehmen, das im Auftrag des Betriebs Leistungen vor Ort erbringt (z.B. Handwerksfirma, Service-Dienstleister). Mitarbeiter von Fremdfirmen unterstehen nicht dem Weisungsrecht des Auftraggebers, müssen aber die betrieblichen Regeln einhalten.

• Fremdfirmenkoordinator: Interner Mitarbeiter, der die Einsätze von Fremdfirmen koordiniert und als Ansprechpartner sowie Aufsichtsführender dient. Sorgt für Abstimmung der Arbeiten und Einhaltung der Sicherheitsmaßnahmen (.

• Unterweisung: Vermittlung von Wissen über Gefahren und Regeln an Mitarbeiter. Fremdfirmenmitarbeiter müssen vor Einsatz über die spezifischen Gefährdungen im Betrieb unterrichtet werden (Sicherheitsunterweisung). Die Unterweisung ist zu dokumentieren (Nachweispflicht).

• Werkvertrag: Vertragstyp, bei dem eine Fremdfirma einen bestimmten Erfolg/ein Werk schuldet (z.B. Bau eines Tanks). Abgerechnet wird nach Ergebnis, nicht nach Zeit.

• Dienstvertrag: Vertrag, bei dem eine laufende Dienstleistung erbracht wird (z.B. regelmäßige Wartung, Gestellung von Personal). Hier wird nach Aufwand/Zeit bezahlt.

• SLAs (Service Level Agreements): Im Vertrag definierte Leistungskennzahlen, die der Dienstleister erreichen muss (z.B. Reaktionszeit, Verfügbarkeit). Dient zur Qualitätssicherung und kann mit Sanktionen/Bonifikationen verknüpft sein.

• PSA (Persönliche Schutzausrüstung): Schutzkleidung oder -ausrüstung, die Mitarbeiter tragen müssen (z.B. Helm, Sicherheitsschuhe, Schutzbrille). Fremdfirmen müssen ihre Mitarbeiter entsprechend ausrüsten; dies wird oft vertraglich festgehalten.

• API (Application Programming Interface): Programmierschnittstelle, über die Software-Systeme miteinander kommunizieren können. Das Portal stellt APIs bereit (z.B. REST-Endpoints), über die Frontend und Integrationen Daten austauschen.

• Microservice: Architekturstil, bei dem eine Anwendung in viele kleine, unabhängige Dienste aufgeteilt ist. Jeder Microservice erfüllt einen speziellen Zweck und kommuniziert über definierte Schnittstellen mit anderen. Vorteile sind u.a. bessere Skalierbarkeit und Zuverlässigkeit.

• Monolith: Eine einheitliche, große Software-Anwendung, in der alle Funktionalitäten integriert sind. Einfacher zu entwickeln am Anfang, aber schwieriger zu skalieren und zu warten bei sehr großem Funktionsumfang.

• Single Sign-On (SSO): Verfahren, bei dem ein Nutzer sich einmalig anmeldet und dann Zugang zu mehreren Systemen erhält, ohne sich erneut einloggen zu müssen. Ermöglicht komfortablen Zugriff und zentrale Authentifizierung.

• DSGVO (Datenschutz-Grundverordnung): Europäische Verordnung zum Schutz personenbezogener Daten und Privatsphäre. Regelt u.a. Rechte der Betroffenen, Pflichten der Datenverarbeiter und hohe Strafen bei Verstößen.

• Betriebsvereinbarung: Vereinbarung zwischen Arbeitgeber und Betriebsrat, die bestimmte Themen der Betriebsordnung regelt. Eine Betriebsvereinbarung zum Fremdfirmenportal würde z.B. Datenschutz, Zugriffsrechte und Nutzungszwecke verbindlich festlegen.

• Werkschutz: Werksicherheit/Security des Betriebs. Zuständig für Zugangskontrolle, Überwachung des Geländes, Notfallmanagement. Enger Nutzer des Portals für Zutrittsverwaltung und Anwesenheitskontrolle.

• Audit-Trail: Lückenlose Protokollierung von Änderungen und Zugriffen, um nachträglich nachvollziehen zu können, wer was wann getan hat. Wichtig für Compliance und Untersuchungen.

• Kollaborationsplattform: Allgemein ein System, das Zusammenarbeit erleichtert – hier bezogen auf die Plattform, die Auftraggeber und Auftragnehmer (Fremdfirma) gemeinsam nutzen, um Informationen auszutauschen.