Customizing von Zutrittskontrollsystemen

Große Industrieunternehmen setzen häufig auf Fremdfirmenportale, um externe Dienstleister und Besucher in ihre Sicherheits- und Zutrittsprozesse zu integrieren. Im Rahmen des Customizings eines Zutrittskontrollsystems ist die nahtlose Anbindung oder Anpassung eines solchen Portals ein zentraler Baustein.

• Anmeldung und Auftragsabwicklung: Im Portal können Fremdfirmen vor einem Einsatz ihre Mitarbeiter anmelden und den geplanten Auftrag hinterlegen. Dadurch kennt das Zutrittskontrollsystem bereits im Voraus die relevanten Personaldaten (Name, Firma, geplante Aufenthaltsdauer, Einsatzort etc.) und kann z.B. temporäre Ausweise vorbereiten oder Zugangscodes generieren. Gleichzeitig lassen sich Auftragsdaten aus ERP oder Instandhaltungssystemen (etwa SAP PM/CS) integrieren, sodass nur für autorisierte Aufträge Zugänge erstellt werden. Durch Customizing kann das Portal so gestaltet werden, dass es die Workflow-Schritte der jeweiligen Firma widerspiegelt – etwa Freigaben durch interne Auftraggeber oder Sicherheitsbeauftragte, bevor ein externer Techniker tatsächlich Zugangsberechtigungen erhält.

• Unterweisungsmanagement: Ein essenzieller Bestandteil ist die Verwaltung von Sicherheitsunterweisungen. Gesetzlich und regulatorisch ist vorgeschrieben, dass alle Personen – Mitarbeiter wie Fremdfirmen – vor Betreten des Betriebsgeländes in den geltenden Sicherheits- und Verhaltensregeln unterwiesen werden. Das Portal ermöglicht es, diese Unterweisungen online durchzuführen, z.B. mittels E-Learning-Module oder Videos mit anschließendem Verständnistest. Das Customizing stellt sicher, dass die Inhalte der Unterweisung branchenspezifisch und aktuell sind (etwa besondere Gefahren in einer Chemieanlage) und dass der Abschluss lückenlos dokumentiert wird. Nur wer alle erforderlichen Schulungen absolviert hat, erhält vom System das Go für den Zutritt. Es ist üblich, externe Firmen jährlich oder vor jedem neuen Auftrag neu zu verpflichten, die Sicherheitsregeln zu bestätigen – hierzu kann das Portal automatische Erinnerungen versenden. In der Praxis wird in einem solchen Sicherheitshandbuch für Fremdfirmen ausdrücklich auf die Unterweisungspflichten hingewiesen und festgelegt, dass die verantwortliche Führungskraft der Fremdfirma für die Schulung ihrer Mitarbeiter Sorge tragen muss. Das System kann diese Bestätigung elektronisch einholen und revisionssicher speichern.

• Dokumentationspflichten und Compliance: Über das Portal lassen sich auch alle weiteren notwendigen Nachweise und Dokumente verwalten. Dazu zählen z.B. Arbeitserlaubnisse, Zertifikate (etwa Schweißerlaubnis, Ersthelfer-Nachweis), Versicherungsbestätigungen oder polizeiliche Führungszeugnisse, falls erforderlich. Das Customizing ermöglicht, je nach Art des Einsatzes, unterschiedliche Dokumente anzufordern und deren Gültigkeit zu prüfen. Beispielsweise kann das System sperren, dass ein Fremdarbeiter ohne gültige arbeitsmedizinische Untersuchung oder ohne PSA-Nachweis (Persönliche Schutzausrüstung) einen Ausweis erhält. Dieses regelbasierte Prüfverfahren lässt sich flexibel an rechtliche Änderungen anpassen. Sobald alle Dokumentationspflichten erfüllt sind, generiert das Portal einen Zutrittscode oder einen Abholschein für den Besucherausweis. Rechtskonforme Workflows – etwa die Prüfung, ob ein Subunternehmer zugelassen ist (Stichwort: Nachweis nach Mindestlohngesetz, Akkreditierung nach Lieferkettengesetz etc.) – können hier ebenfalls hinterlegt werden. Das Ziel ist, 100% Compliance sicherzustellen, bevor eine externe Person physisch Zugang erhält. Damit schützt das Unternehmen sich vor haftungsrechtlichen Risiken, denn es kann jederzeit nachweisen, dass alle Fremdkräfte ordnungsgemäß unterwiesen und überprüft wurden.

• Durch ein gut angepasstes Fremdfirmenportal werden Sicherheitsprozesse automatisiert und verschlankt: Wartezeiten am WerksTor reduzieren sich, weil viele Schritte vorab online erfolgen. Gleichzeitig steigt die Sicherheit, da das System kein Schlupfloch zulässt – nur wer wirklich alle Bedingungen erfüllt, gelangt ins Gelände. Dies entspricht gängigen Best Practices in sicherheitskritischen Branchen (etwa Chemie, Energie), wo externe Dienstleister vor Arbeitsaufnahme vollständig registriert und instruiert sein müssen.

Neben den großen Integrationspunkten (SAP, Portale) gibt es zahlreiche weitere Bereiche, in denen ein Zutrittskontrollsystem über Customizing an die Bedürfnisse des Unternehmens angepasst werden kann. Dazu zählen insbesondere die Benutzeroberfläche, spezifische Workflow-Anpassungen im System sowie das Rollen- und Berechtigungskonzept.

• Benutzeroberfläche (UI): Die Benutzeroberfläche des Systems – sei es eine Desktop-Software für die Security-Leitstelle, ein Web-Frontend für Self-Service oder ein Terminaldisplay am Werkstor – lässt sich oft im gewissen Umfang individuell gestalten. Auf Expertenniveau bedeutet UI-Customizing mehr als nur Logos austauschen: Es geht darum, die Usability für verschiedene Nutzergruppen zu optimieren. Beispielsweise kann für Wachpersonal ein vereinfachtes Dashboard erstellt werden, das auf einen Blick Alarmmeldungen und Besucheranmeldungen zeigt, während für Administratoren komplexere Konfigurationsmasken verfügbar sind. Multi-Language-Unterstützung ist ein weiterer Aspekt: In international tätigen Unternehmen sollte die Softwareoberfläche mehrsprachig anpassbar sein (Deutsch, Englisch, ggf. weitere Sprachen für ausländische Wachleute oder Besucher). Auch die Darstellung auf mobilen Geräten (Tablets für Security-Mitarbeiter vor Ort) kann Teil des UI-Customizings sein. Ein konsistentes Corporate Design stärkt zudem die Akzeptanz – das System fügt sich optisch in die IT-Landschaft des Unternehmens ein. Insgesamt zielt UI-Customizing darauf ab, die Benutzerfreundlichkeit und Effizienz der Bedienung zu maximieren, was besonders in Stresssituationen (z.B. Alarmfall, hohes Besucheraufkommen) relevant ist.

• Workflows: Zutrittskontrollsysteme bringen standardmäßig einige Workflows mit (etwa Badge-Erstellung, Sperrung verlorener Ausweise, Besucheranmeldung). In der Praxis müssen diese Abläufe jedoch häufig modifiziert oder erweitert werden. Customizing ermöglicht die Definition eigener Workflow-Regeln. Ein Beispiel ist der Genehmigungsprozess für Zutrittsrechte: Anstatt dass ein Sicherheitsadministrator allein entscheidet, kann der Workflow so angepasst werden, dass zunächst der Fachvorgesetzte des Mitarbeiters elektronisch zustimmen muss, bevor die Sicherheitsabteilung die Freigabe erteilt. Solche mehrstufigen Freigaben erhöhen die Sicherheit und stellen sicher, dass Prinzipien wie das Vier-Augen-Prinzip eingehalten werden. Weitere Workflows könnten die automatische Deaktivierung von Zutrittsberechtigungen nach Ende eines Projekts oder Benachrichtigungen sein (z.B. E-Mail an den Verantwortlichen, wenn ein Externer das Gelände betritt oder verlässt). Auch der oben beschriebene Abgleich von Zeitdaten mit Rechnungen ist letztlich ein systemübergreifender Workflow. Durch Customizing lässt sich definieren, welche Systemaktionen auf welche Ereignisse erfolgen – etwa dass ein Alarm ausgelöst und eine Kamera aufgeschaltet wird, wenn jemand versucht, mit einem gesperrten Ausweis einzutreten. Wichtig ist, dass diese Workflows eng an die organisatorischen Prozesse gekoppelt sind: Das Customizing macht die Software prozessgeführt passend zum Unternehmen.

• Rollen- und Rechtekonzepte: Ein professionelles Zutrittskontrollsystem muss ein feingranulares Berechtigungsmodell bieten. Hierbei gilt es, zwei Ebenen zu unterscheiden: Zum einen die physischen Zutrittsberechtigungen (wer darf welche Tür passieren – das wird über Zutrittsprofile, Bereiche und Zeitpläne gesteuert), zum anderen die Benutzerrechte innerhalb der Management-Software (wer darf welche Funktionen im System bedienen oder administrieren). Letzteres ist hier im Fokus. Ein Rollen- und Rechtekonzept wird typischerweise im Rahmen des Customizing erstellt, um genau festzulegen, welche Benutzergruppe welche Aktionen ausführen darf. Beispielsweise könnte eine Rolle „Empfang“ nur berechtigt sein, Besucher anzulegen und Besucherausweise zu drucken, aber keine Einstellungen zu Türen vorzunehmen. Die Rolle „Sicherheitsadministrator“ darf Ausweise sperren, Profile ändern und Alarme quittieren, wohingegen eine „HR-Rolle“ vielleicht Lesezugriff auf die Anwesenheitsprotokolle hat, um Arbeitszeiten nachzuvollziehen. Diese Trennung folgt dem Prinzip der geringsten Privilegien: Jeder Nutzer bekommt nur die Rechte, die er zur Aufgabenerfüllung benötigt. Das erhöht die Sicherheit und verhindert Fehlbedienungen oder Datenmissbrauch.

Best Practices in diesem Bereich empfehlen rollenbasierte Zugriffskontrolle (RBAC) klar umzusetzen. Durch das Customizing können Standardrollen angepasst oder neue Rollen definiert werden, die exakt zur Aufbauorganisation der Firma passen. Zu beachten ist ferner die Nachvollziehbarkeit: Alle administrativen Aktionen (z.B. das Ändern von Rechten) sollten vom System protokolliert werden. Das Rollen- und Rechtekonzept sollte zudem regelmäßig überprüft und an organisatorische Änderungen angepasst werden. In Kombination mit den oben erwähnten Workflows (z.B. Freigabeprozesse) entsteht so ein internes Kontrollsystem, das Manipulationen erschwert und Verantwortlichkeiten klar zuordnet.

Die Einführung oder tiefgreifende Anpassung eines Zutrittskontrollsystems ist nicht nur ein IT-Projekt, sondern ein organisatorisches Veränderungsprojekt.

• Prozessdefinition und -dokumentation: Zu Beginn steht eine Analyse der bestehenden Prozesse rund um den Zutritt: Wie läuft aktuell die Vergabe von Ausweisen? Welche Stellen sind involviert, wenn ein Besucher kommt? Wie werden Zutrittsrechte beantragt und genehmigt? Auf Basis dieser Analyse sollten Soll-Prozesse definiert werden, die effizienter sind und durch das System unterstützt werden. Diese neuen Prozesse (z.B. „Onboarding eines neuen Mitarbeiters mit automatischer Zutrittsprofil-Zuweisung“) müssen dokumentiert und in Arbeitsanweisungen festgehalten werden. Das Customizing des Systems bildet dann diese Soll-Prozesse technisch ab (via Workflows, Rollen etc. wie oben beschrieben). Wichtig ist, Medienbrüche zu vermeiden – d.h., Prozesse ganzheitlich zu denken, damit nicht an irgendeiner Stelle doch wieder manuelle Zwischenschritte oder Insellösungen nötig sind.

• Verantwortlichkeiten: Parallel dazu sind organisatorische Verantwortlichkeiten festzulegen. Ein Betrieb eines Zutrittskontrollsystems erfordert klare Zuständigkeiten: Wer ist Systemowner (oft die Sicherheitsabteilung in Kooperation mit IT)? Wer pflegt die Benutzerdaten (z.B. HR für Mitarbeiter, Fachabteilungen für externe Partner)? Wer überwacht die Einhaltung von Regeln (z.B. Datenschutzbeauftragter hinsichtlich Löschung von Zutrittslogs)? Durch das Customizing können Verantwortlichkeiten auch im System verankert werden – etwa indem bestimmte Aktionen nur durch definierte Rollen (die bestimmten Abteilungen zugewiesen sind) erfolgen können. Beispielsweise könnte die Erstellung eines neuen Zugangsbereichs nur durch die Zentrale Sicherheitsstelle erfolgen, während das Anlegen neuer Personen sowohl durch HR (Mitarbeiter) als auch durch den Empfang (Besucher) erfolgen kann. Solche Feinabstimmungen spiegeln die organisatorische Governance wider. Falls ein Security Operations Center (SOC) oder ähnliches vorhanden ist, wird dieses meist die Überwachung der Zutrittsanlage übernehmen (Live-Monitoring, Alarmreaktion). Insgesamt sollte ein Betriebskonzept erstellt werden, das Mensch (Organisation) und Technik (System) integriert.

• Einbindung von Stakeholdern: Ein kritischer Erfolgsfaktor ist die frühzeitige und transparente Einbindung aller Stakeholder. In Deutschland spielt hier insbesondere der Betriebsrat eine Rolle, da ein elektronisches Zutrittskontrollsystem auch zur Überwachung von Mitarbeitern verwendet werden könnte. Gemäß § 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz unterliegt die Einführung technischer Einrichtungen, die geeignet sind, das Verhalten oder die Leistung von Mitarbeitern zu überwachen, der Mitbestimmung des Betriebsrats. Ein Zutrittskontrollsystem fällt typischerweise unter diese Regelung. Daher sollten Betriebsratsgremien von Anfang an in die Planung einbezogen werden, um eine Betriebsvereinbarung auszuarbeiten, die den zulässigen Rahmen der Datennutzung definiert (z.B. „Zutrittsdaten werden nicht zur Leistungskontrolle, sondern nur zur Sicherheit und Arbeitszeiterfassung verwendet“). Ebenso wichtig ist die Einbindung des Datenschutzbeauftragten, der sicherstellt, dass alle Datenschutzvorgaben eingehalten und dokumentiert werden (dazu im Abschnitt Normen/Standards mehr). Weitere Stakeholder sind die IT-Abteilung (für Infrastruktur, Netzwerk, evtl. Serverbetrieb des Systems), das Facility Management (für die physischen Komponenten wie Türanlagen, Drehkreuze, Sensoren) sowie ggf. die Rechtsabteilung (für Vertragsprüfungen mit dem Anbieter und Rechtskonformität).

• Change-Management und Schulung: Die beste Technik nützt wenig, wenn die Anwender nicht mitziehen. Daher sollte das Customizing-Projekt ein begleitendes Change-Management haben. Dazu gehört es, frühzeitig über Ziele und Nutzen des neuen Systems zu kommunizieren und Ängste oder Widerstände abzubauen – etwa die Befürchtung der Mitarbeiter, nun lückenlos überwacht zu werden. Durch Informationsveranstaltungen kann verdeutlicht werden, dass das System primär der Sicherheit dient und welche Schutzmechanismen (z.B. Datenschutzrichtlinien, begrenzte Aufbewahrungsfristen der Logs) eingebaut sind. Nach der technischen Umsetzung sind umfassende Schulungsmaßnahmen essenziell: Sicherheitsmitarbeiter müssen lernen, die neue Software zu bedienen; HR und andere Abteilungen müssen wissen, wie sie Personen anlegen oder Berichte ziehen; Endnutzer (Mitarbeiter) brauchen evtl. Einweisungen, z.B. in Self-Service-Funktionen oder neue Ausweisträger (falls z.B. von alten Stempelkarten auf RFID-Badges umgestellt wird). Handbücher, FAQs und ein Supportkonzept (wer hilft bei Fragen zum System?) runden dies ab.

• Kontinuierliche Verbesserung: Organisation ist nie statisch – Personalwechsel, Umstrukturierungen oder neue Standorte erfordern laufende Anpassungen. Entsprechend sollte ein Prozess etabliert sein, um das Zutrittssystem kontinuierlich zu pflegen und weiterzuentwickeln. Änderungsanforderungen (Change Requests) an das System sollten z.B. über ein definiertes Verfahren (Change Advisory Board) geprüft und priorisiert werden. Nur so bleibt das System über Jahre hinweg aktuell und akzeptiert. Das Customizing-Projekt sollte also nicht als einmaliges Ereignis gesehen werden, sondern als Beginn eines dauerhaften Optimierungsprozesses, der regelmäßige Reviews beinhaltet.

Die technische Perspektive des Customizings von Zutrittskontrollsystemen ist vielschichtig. Sie umfasst die Integrationstechnologie (Schnittstellen/APIs), die System- und Netzwerkarchitektur, das Datenmodell sowie nicht zuletzt die technische Sicherheit und Stabilität des Gesamtsystems.

• Schnittstellen und APIs: Wie bereits im SAP-Integrationsabschnitt beschrieben, sind offene Schnittstellen der Schlüssel, um ein Zutrittskontrollsystem in die bestehende IT-Landschaft einzubetten. Neben SAP können dies auch andere Systeme sein: z.B. LDAP/Active Directory für den Abgleich von Personaldaten, Systeme für Besuchermanagement, Zeiterfassungsterminals oder Gebäudemanagement-Systeme. Moderne Zutrittslösungen bieten RESTful APIs oder SOAP-Webservices an, über die externe Applikationen Daten abrufen oder einspeisen können. Ein Beispiel: Über eine API-Abfrage kann das Intranet-Portal anzeigen, welche Kollegen gerade im Gebäude anwesend sind (sofern datenschutzrechtlich zulässig). Das Customizing sollte prüfen, welche Datenflüsse relevant sind – etwa täglicher Import neuer Personalstammdaten aus SAP, Export der Zutrittslogs an ein Data Warehouse, Live-Benachrichtigung an ein Alarmierungssystem bei kritischen Events etc. Für jeden solchen Fluss ist die passende Schnittstellentechnologie zu wählen: Batch-Importe via CSV/XML, Event-basierte Übertragung via Message Queue oder direkte Datenbank-Links sind gängige Varianten. Standardisierte Schnittstellen sind vorzuziehen, um Wartbarkeit zu gewährleisten. Gibt es keinen Standard, muss ggf. individuell programmiert werden – dann ist auf ausführliche Dokumentation zu achten, damit bei Updates (siehe weiter unten) kein Bruch entsteht. Insgesamt ermöglicht eine durchdachte Schnittstellen-Architektur, dass das Zutrittskontrollsystem kein isolierter „Sicherheitsdaten-Silo“ bleibt, sondern ein integraler Baustein der digitalen Infrastruktur wird.

• Systemarchitektur: Unter Systemarchitektur fallen sowohl die Software-Architektur (Server, Clients, Dienste) als auch die Hardware-Architektur (Kontroller, Leser, Verkabelung, Netzwerk). Ein anpassbares Zutrittskontrollsystem sollte skalierbar sein – d.h. es muss sich an die Größe und Verteilung des Unternehmens anpassen lassen. In einem zentralen Gebäude reicht vielleicht ein einzelner Server und lokal angebundene Leser; ein internationaler Konzern hingegen benötigt verteilte Systeme mit mehreren regionalen Servern, die untereinander synchronisieren. Customizing kann hier bedeuten, bestimmte Module zu- oder abzuschalten (z.B. ein Modul für Videoüberwachung nur dort zu aktivieren, wo Kameraintegration gewünscht ist). In Bezug auf Ausfallsicherheit kann entschieden werden, ob ein Redundanzkonzept umgesetzt wird: Etwa zwei parallel laufende Serversysteme in unterschiedlichen Rechenzentren für Hochverfügbarkeit, oder lokale Pufferspeicher in Türcontrollern, die bei Netzwerkverlust offline weiterarbeiten. Die Netzwerkarchitektur muss Sicherheitsanforderungen genügen – z.B. Trennung des Zutrittsnetzes (an dem Türcontroller hängen) vom allgemeinen Büronetz, um Manipulation zu erschweren. Gegebenenfalls kommen verschlüsselte Protokolle zum Einsatz, z.B. OSDP (Open Supervised Device Protocol) mit Secure Channel für die Kommunikation zwischen Kartenleser und Controller. Die Systemarchitektur sollte auch zukünftige Erweiterungen berücksichtigen (Stichwort: IoT und Smart Building könnten Zutrittssysteme ergänzen, z.B. mit sensorbasierten Raumbelegungsdaten). Durch Customizing kann zudem die Integration in eine gesamtheitliche Gebäudeleittechnik erfolgen, etwa über OPC UA Schnittstellen oder proprietäre Integrationsplattformen wie z.B. Siemens DESIGO oder Honeywell BMS, je nach Branche. Wichtig ist, dass die Architektur performant bleibt – z.B. auch bei zehntausenden Mitarbeitern und sehr vielen Buchungen pro Minute darf das System nicht in die Knie gehen. Tests in der Implementierungsphase sollten dies verifizieren.

• Datenmodelle und Konfiguration: Jedes Zutrittskontrollsystem hat ein zugrunde liegendes Datenmodell – typischerweise mit Entitäten wie Personen, Ausweise/Medien, Zutrittsberechtigungen, Leser/Türen, Zonen/Bereiche, Ereignislogs usw. Customizing kann an zwei Stellen ansetzen: Erstens bei der Grundkonfiguration dieser Datenobjekte, zweitens bei der Erweiterung des Datenmodells um firmenspezifische Felder. Die Grundkonfiguration umfasst z.B. das Anlegen der Standort- und Türstruktur (z.B. welche Türen gehören zu welchem Bereich), die Definition von Zeitprofilen (z.B. Arbeitszeit Mo–Fr 6–20 Uhr, Wochenendsperre) und Zutrittsprofilen (Kombination aus Bereichen und Zeiten, z.B. „Büroangestellte“ dürfen Bereich Büro zu Arbeitszeiten). Diese müssen exakt auf die Organisationsstruktur passen. Das Customizing-Team sollte daher eng mit der Sicherheitsabteilung und den Fachbereichen die Access-Matrix erarbeiten: Welche Rolle (z.B. „IT-Administrator“, „Produktion-Schichtarbeiter“, „Lieferant“) benötigt Zugang zu welchen Zonen zu welchen Zeiten. Dieses Konzept wird dann im System abgebildet. Ein gutes Datenmodell erleichtert auch Auswertungen – etwa kann man darüber definieren, welche Gruppen in Notfällen welche Evakuierungslisten erhalten.
  Zweitens kann es nötig sein, das standardmäßige Datenmodell zu erweitern. Beispielsweise möchte man vielleicht pro Person zusätzlich das KFZ-Kennzeichen erfassen, um Parkplatz-Zutritt zu steuern, oder externe Mitarbeiter einem Auftrag oder einer Fremdfirma zuordnen. Viele Systeme bieten hierfür Custom-Fields oder freie Attributfelder an. Beim Customizing ist zu beachten, dass solche Erweiterungen kompatibel mit Updates bleiben (idealerweise durch vom Hersteller vorgesehene Mechanismen, nicht durch direkte Datenbankmanipulation). In jedem Fall ist die Datenintegrität zu gewährleisten: Beziehungen (z.B. wer hat welchen Ausweis, wer gehört zu welcher Firma) müssen durch das Customizing konsistent gehalten werden. Bei der Integration mit SAP oder anderen Systemen ist zudem auf Schlüsselidentifikatoren zu achten – z.B. sollte im Zutrittssystem die Personalnummer aus SAP hinterlegt werden können, um eindeutige Zuordnung zu ermöglichen.

• Technische Sicherheit: Eng verknüpft mit Architektur und Schnittstellen sind die Anforderungen der IT-Sicherheit. Ein Zutrittskontrollsystem darf nicht zum Einfallstor für Hacker werden, sonst könnten schlimmstenfalls Türen ferngesteuert werden oder personenbezogene Daten entwendet werden. Technisch sind daher härtende Maßnahmen zu treffen: Das System sollte z.B. in einem isolierten Netzwerksegment laufen, Firewalls schützen die Kommunikation zu Schnittstellen. Daten, die über unsichere Netzwerke laufen (z.B. Web-Portal für Fremdfirmen über das Internet, oder Cloud-Anbindung) müssen stark verschlüsselt und mit aktuellen Protokollen gesichert sein. Administratorenzugriffe sollten nur mit Multi-Faktor-Authentifizierung erfolgen (z.B. neben Passwort noch ein Zertifikat oder Token). Das Prinzip der gestuften Sicherheit („Defense in Depth“) gilt auch hier: Kritische Bereiche sollten nicht nur durch das Zutrittssystem allein geschützt sein, sondern etwa zusätzlich durch Personenkontrollen oder Videoüberwachung – eine Kombination mehrerer Sicherheitsmaßnahmen erhöht die Gesamtsicherheit.

Die europäische Norm DIN EN 60839-11-1 legt technische Mindeststandards für elektronische Zutrittskontrollsysteme fest (u.a. Verfügbarkeit, Failsafe, Protokollierung). Diese Normen sollten bei der technischen Konzeption berücksichtigt und nach Möglichkeit durch das System erfüllt werden. Im Customizing bedeutet das z.B., entsprechende Verschlüsselungsmodi zu aktivieren, sichere Schlüsselverwaltung zu nutzen und die vom Hersteller empfohlenen Hardening-Leitfäden zu befolgen. Ferner ist ein Logging-Konzept Teil der technischen Sicherheit: Alle sicherheitsrelevanten Ereignisse müssen aufgezeichnet und regelmäßig auf Anomalien geprüft werden. Bei Integrationen mit IT-Systemen sollte auch das Monitoring eingebunden sein (etwa dass das zentrale Monitoring einen Alarm schlägt, wenn der Zutrittsserver ausfällt oder keine Logs mehr sendet).

Nicht zu vernachlässigen ist das Testen der technischen Lösungen. Vor dem produktiven Einsatz sollten umfangreiche Tests durchgeführt werden – einschließlich Penetrationstests aus Sicht der IT-Security, um Schwachstellen aufzudecken. Das Customizing darf keine Hintertüren öffnen; z.B. muss selbst erstellter Code für Schnittstellen sicher programmiert sein (keine SQL-Injections etc.). Ebenso sind Performance- und Lasttests sinnvoll, vor allem wenn Schnittstellen zu SAP oder andere Systeme in kurzen Intervallen große Datenmengen übertragen. So wird sichergestellt, dass die technische Integrität und Leistungsfähigkeit des Gesamtsystems auch im realen Betrieb den Anforderungen entspricht.

Neben den fachlichen und technischen Aspekten spielen auch kaufmännische Überlegungen eine entscheidende Rolle beim Customizing von Zutrittskontrollsystemen. Die Einführung oder Erweiterung eines solchen Systems ist mit Investitionen verbunden – in Softwarelizenzen, Hardware, Integration und laufenden Betrieb.

• Lizenzmodelle: Hersteller von Zutrittskontrolllösungen bieten unterschiedliche Lizenzierungsansätze. Üblich sind z.B. gestaffelte Lizenzen nach Anzahl der Nutzer (Personen, die im System verwaltet werden) oder nach Anzahl der Zutrittspunkte (Türen/Leser). Einige Modelle kombinieren beides oder bieten Module als separate Lizenzen an (z.B. ein Modul für Besucherverwaltung, ein Modul für Videointegration). Im Customizing-Projekt sollte früh geklärt werden, welches Modell am besten zum Unternehmen passt. Hat man z.B. sehr viele Personen, aber relativ wenige Türen, könnte eine Door-basierte Lizenz wirtschaftlicher sein als eine User-basierte – oder umgekehrt. Enterprise-Lizenzen (Pauschallizenzen für alle Standorte) können bei großen Unternehmen mit vielen Standorten sinnvoll sein, um nicht für jeden Standort separat zu lizenzieren. Auch zeitbasierte Lizenzen (Abonnements) gewinnen an Bedeutung, insbesondere wenn es sich um Cloud-Services handelt. Hier kommen OPEX-Kosten (laufende Miet-/Abogebühren) statt CAPEX (einmaliger Kauf) auf das Unternehmen zu. Diese Entscheidung hängt von der Finanzierungsstrategie ab. Wichtig beim Customizing ist zudem, im Blick zu haben, ob gewisse Integrationen oder APIs extra lizenziert werden müssen – manche Anbieter verlangen z.B. separate Gebühren für einen „SAP-Connector“ oder für die Nutzung der API über eine gewisse Anzahl Calls. Alle diese Punkte gehören in die Kostenplanung.

• Kostenoptimierung: Um die Kosten im Rahmen zu halten, sollte das Customizing auf effiziente Lösungen setzen. Das bedeutet etwa, möglichst viel mit Standardfunktionen abzudecken und teure Individualentwicklung nur dort einzusetzen, wo der Nutzen klar höher ist als die Kosten. Oft bieten Hersteller bereits umfangreiche Konfigurationsmöglichkeiten, die man voll ausschöpfen sollte, bevor man zum Programmierer greift. Zudem ist auf Skaleneffekte zu achten: Wenn z.B. Hardware gebraucht wird (Kartenleser, Controller), können größere Abnahmemengen Rabatte bringen – eine koordinierte Beschaffung für alle Standorte ist oft günstiger als Stück-für-Stück. In den Kostenbetrachtungen sind nicht nur Anschaffungskosten, sondern auch laufende Kosten relevant: Wartungsverträge, Updates, Betrieb (Strom für Türen, Netzwerk etc.), Schulungen des Personals, ggf. Hosting-Kosten (bei Cloud oder eigenem Server). Eine TCO-Rechnung (Total Cost of Ownership) über mehrere Jahre ist empfehlenswert. Hier kann man auch potentiale Einsparungen gegenrechnen: Automatisierte Workflows sparen Arbeitszeit, effiziente Rechnungskontrolle vermeidet Überzahlungen – solche Nutzenwirkungen sollten monetär bewertet und gegengestellt werden.

• Ein Beispiel zur Kostenoptimierung durch Customizing: Wenn das Zutrittssystem so integriert wird, dass Mitarbeiterausweise zugleich als Kantinen- und Druckerkarte fungieren, könnte man separate Systeme einsparen. Oder wenn durch das Fremdfirmenportal weniger Sicherheitspersonal für Besucherbetreuung nötig ist, sind Personalkosten reduzierbar. Diese indirekten Effekte gehören in eine ganzheitliche Betrachtung.

• Service-Level-Agreements (SLAs): Da Zutrittskontrollsysteme meist geschäftskritisch sind (im Extremfall hängt der komplette Betriebsablauf davon ab, ob Türen öffnen oder nicht), müssen klare SLAs mit dem Hersteller oder Dienstleister vereinbart werden. Im Vertrag mit dem Softwareanbieter sollte ein Wartungs- und Supportvertrag enthalten sein, der Reaktionszeiten im Problemfall regelt. Typische SLAs definieren Kategorien von Störungen (kritisch = Systemausfall, hoch = wichtige Funktion gestört, mittel, gering) und zugehörige Reaktions- und Lösungszeiten (z.B. Reaktion bei kritisch innerhalb 1 Stunde, Lösung innerhalb 4 Stunden). Je nach Bedürfnis kann 24/7-Support notwendig sein – etwa wenn ein Werk im Schichtbetrieb rund um die Uhr läuft, muss auch nachts ein Ansprechpartner verfügbar sein, falls das System ausfällt und niemand mehr aufs Gelände käme. Solche High-Availability-Vereinbarungen sind meist mit Aufpreis verbunden, aber essentiell, wenn das Risiko eines Ausfalls große Schäden verursachen könnte (z.B. Produktionsstillstand, Sicherheitsrisiko).

• Ebenso wichtig ist der Update-/Upgrade-Service: Die SLA sollte beinhalten, dass der Anbieter regelmäßige Updates bereitstellt (z.B. Security-Patches, Fehlerbehebungen) und Upgrades auf neue Versionen unterstützt. Falls das Customizing durch den Hersteller erfolgt ist, sollte im SLA stehen, dass kundenspezifische Anpassungen bei Updates berücksichtigt werden. Oft bieten Anbieter jährliche Softwareupdates im Rahmen des Wartungsvertrags an – es ist dann intern sicherzustellen, dass Ressourcen bereitstehen, um diese Updates einzuspielen und das System aktuell zu halten. Teil der Kostenplanung ist hier, den Aufwand für Tests und eventuelle Nacharbeiten nach Updates einzukalkulieren.

• Schließlich gehören auch Service-Level für Hardware dazu: Wenn Türterminals oder Controller ausfallen, gibt es entweder Ersatzteillager beim Kunden oder man vereinbart mit einem Dienstleister entsprechende Vor-Ort-Servicezeiten. Beispielsweise könnte man festlegen, dass im Störfall binnen 8 Stunden ein Techniker vor Ort das defekte Gerät ersetzt. Für wirklich kritische Einrichtungen (z.B. Zutritt zu einem Rechenzentrum) wird man Redundanzen einplanen und eventuell einen noch schnelleren Austausch (2-4 Stunden) vertraglich festhalten.

Transparenz über die Einhaltung der SLAs wird durch Reporting gewährleistet. Viele Anbieter liefern quartalsweise Reports, wie viele Tickets es gab, wie die Reaktionszeiten waren etc. – so kann man die Servicequalität überwachen. Sollte der Anbieter wiederholt SLAs verletzen, können Vertragsstrafen greifen, sofern vereinbart. All dies dient dazu, das wirtschaftliche Risiko eines Systemausfalls oder einer mangelhaften Betreuung gering zu halten. Das Customizing-Projekt sollte solche Themen von Anfang an mitdenken und entsprechende Anforderungen im Pflichtenheft festhalten, um sie dann in Verträgen mit Anbietern oder Implementierungspartnern abzusichern.

Im Kontext eines umfassenden Customizings sind klare vertragliche Regelungen mit dem Systemanbieter bzw. Integrationspartner fundamental.

• Anforderungen an den Anbieter: Bereits in der Ausschreibungs- oder Auswahlphase eines Zutrittskontrollsystems sollten die gewünschten Customizing-Fähigkeiten als Anforderungen definiert werden. Der Anbieter sollte nachweisen, dass sein System die benötigten Schnittstellen und Funktionen bietet (z.B. SAP-Anbindung, Portalmodul, Custom-Fields, Workflow-Engine etc.). Idealerweise präsentiert er Referenzen ähnlicher Projekte in der Industrie, um Vertrauen in seine Lösung zu schaffen. All diese Punkte können in einem Lastenheft festgehalten werden, auf das der Anbieter mit einem Pflichtenheft antwortet. In letzterem verpflichtet er sich, die Anforderungen umzusetzen. Wenn umfangreiche Individualanpassungen durch den Anbieter vorgenommen werden (z.B. Entwicklung einer speziellen Schnittstelle), sollte klar vereinbart werden, ob diese Teil des Standardprodukts werden (was vorteilhaft sein kann, da dann zukünftige Pflege vom Standard-Upgrade-Prozess abgedeckt ist) oder ob es sich um kundenspezifische Sonderentwicklungen handelt. Im Falle von Letzterem ist wichtig zu regeln, wem die Nutzungsrechte am Quellcode gehören und wie langfristig sichergestellt ist, dass das Customizing auch in Zukunft funktioniert (z.B. Quellcode-Hinterlegung in Escrow, falls der Anbieter insolvent wird, oder vertragliche Zusage, Custom-Code bei neuen Versionen kompatibel zu halten).

• Support-Verträge und Verantwortlichkeiten: Wie im SLA-Abschnitt erwähnt, sollten Support und Wartung vertraglich fixiert sein. Darüber hinaus ist abzugrenzen, wer welche Verantwortung trägt: Macht das Unternehmen selbst Teile des Customizings (z.B. eigenentwickelte Scripts oder Datenbank-Views), dann wird der Hersteller dafür in der Regel keinen Support bieten. Hier könnte ein externer Systemintegrator ins Spiel kommen, der als Partner fungiert und die kundeneigenen Anpassungen betreut. Mit diesem Integrator wären dann separate Verträge zu schließen. In jedem Fall muss klar sein, an wen man sich wendet, wenn ein Problem auftritt – insbesondere wenn Standard und Customizing ineinandergreifen. Empfehlenswert ist ein Single Point of Contact Prinzip: Der Kunde meldet alle Probleme an einen zentralen Service (des Herstellers oder Integrators), und dieser koordiniert intern die Lösung, egal ob es den Standard oder die Anpassung betrifft. Das verhindert Zuständigkeitsgerangel.

• Update- und Upgrade-Strategien: Verträge sollten regeln, wie mit neuen Versionen der Software umgegangen wird. In der IT-Security ist es z.B. wichtig, immer die unterstützten Versionen mit aktuellen Sicherheitsupdates zu verwenden. Daher sollte der Anbieter mindestens für einen festgelegten Zeitraum (z.B. 5 Jahre) Updates für die eingesetzte Version bereitstellen oder entsprechende Migrationspfade aufzeigen. Wenn größere Upgrades (Versionssprünge mit neuen Funktionen) veröffentlicht werden, stellt sich die Frage, wie die kundenseitigen Customizings migriert werden. Im Idealfall unterstützt der Anbieter die Migration als Teil des Wartungsvertrags – etwa durch Migrationswerkzeuge oder Dienstleistungen, die angeboten werden. Es kann sinnvoll sein, regelmäßige Upgrade-Projekte einzuplanen (z.B. alle 2-3 Jahre auf die neueste Hauptversion zu gehen), statt das System 10 Jahre unverändert zu lassen und dann einen aufwändigen Sprung machen zu müssen. Vertraglich kann vereinbart werden, dass Rückwärtskompatibilität gewährleistet ist, zumindest für die wichtigsten Schnittstellen. Beispielsweise wenn man die SAP-Integration nutzt, sollte der Anbieter zusichern, dass bei einem Upgrade der Schnittstelle (etwa auf S/4HANA) unterstützt wird oder Migrationsskripte bereitstehen.

• Leistungsverzeichnis und Abnahmen: Falls der Anbieter individuelle Leistungen erbringt, gehört in den Vertrag auch ein detailliertes Leistungsverzeichnis der Customizing-Arbeiten mit Meilensteinen und Abnahmekriterien. So kann das Unternehmen prüfen, ob alles vertragsgemäß umgesetzt wurde (z.B. ob der Fremdfirmenportal-Workflow wie beschrieben funktioniert, ob die Rollenrechte korrekt greifen etc.). Zahlungspläne werden oft an diese Abnahmen geknüpft. Wichtig ist, eine Testphase einzuplanen, in der das System im Beisein des Anbieters pilotiert wird, bevor die finale Abnahme erfolgt. In dieser Phase können Mängel festgestellt und behoben werden. Verträge sollten auch Gewährleistung für die geleisteten Anpassungen enthalten – d.h. der Anbieter muss eine gewisse Zeit nach Abnahme noch für Fehler einstehen, die trotz Tests übersehen wurden.

• Datenschutz und Haftung: Vertraglich relevant sind ferner Klauseln zum Datenschutz: Wenn z.B. der Anbieter im Rahmen von Fernwartung Zugriff auf personenbezogene Daten (Zutrittslogs etc.) haben könnte, ist ein Auftragsverarbeitungsvertrag (AVV) nach DSGVO abzuschließen. Darin verpflichtet sich der Anbieter, die Daten nur für den definierten Zweck zu nutzen und angemessen zu schützen. Auch Haftungsfragen bei Sicherheitsvorfällen sollte man betrachten – etwa wenn das System wegen eines Softwarefehlers Türen nicht verriegelt und es zu einem Schaden kommt, oder wenn durch eine Sicherheitslücke im System personenbezogene Daten abfließen. In der Praxis versuchen Hersteller ihre Haftung stark zu begrenzen, aber aus Kundensicht sind wenigstens Haftungssummen für typische Schäden wünschenswert. Diese Aspekte gehören in Verhandlungen beleuchtet.

• Zukunftssicherheit und Exit-Strategie: Ein oft vernachlässigter Punkt ist, was passiert, wenn man den Anbieter wechseln will oder muss (z.B. weil das Produkt abgekündigt wird oder man nach vielen Jahren ein anderes System einführen will). Verträge sollten vorsehen, dass der Datenexport in gängigen Formaten möglich ist, damit man seine historischen Zutrittsdaten retten kann. Auch Dokumentationen der Customizings sollten Eigentum des Kunden sein. Falls der Anbieter während des Betriebs übernommen wird oder Produkte einstellt, sollten Notfallklauseln existieren, beispielsweise die oben erwähnte Escrow-Vereinbarung für Quellcode oder die Verpflichtung, bei Produktende noch X Jahre Support zu liefern.

In Summe helfen solide vertragliche Regelungen, die Zusammenarbeit mit dem Anbieter auf eine sichere Basis zu stellen. Sie bilden das Rückgrat des Customizing-Projekts, indem sie sicherstellen, dass alle Parteien ihre Pflichten kennen und einhalten. Ein Unternehmen sollte diese vertraglichen Aspekte mit derselben Sorgfalt behandeln wie die technischen – im Zweifel mit juristischer Beratung – um spätere Konflikte oder unkalkulierbare Risiken zu vermeiden.

Bei der Anpassung eines Zutrittskontrollsystems dürfen die gesetzlichen und normativen Rahmenbedingungen keinesfalls außer Acht gelassen werden. Insbesondere Datenschutz, IT-Sicherheit und Arbeitsrecht setzen Leitplanken, innerhalb derer sich technische Lösungen bewegen müssen. Die Beachtung aktueller Normen und Standards ist nicht nur eine Pflichtübung, sondern auch ein Qualitätsmerkmal – ein Zeichen dafür, dass das System state of the art und compliant ist.

• Datenschutz (DSGVO/BDSG): Ein Zutrittskontrollsystem verarbeitet personenbezogene Daten – namentlich die Identität von Personen und ihre Zutrittszeitpunkte, teilweise auch Fotos oder biometrische Daten (z.B. Fingerabdruck bei biometrischen Systemen). In der EU greift hier vollumfänglich die Datenschutz-Grundverordnung (DSGVO) sowie ergänzend das Bundesdatenschutzgesetz (BDSG). Grundprinzipien sind u.a. Datenminimierung, Zweckbindung und Speicherbegrenzung. Für die Praxis bedeutet das: Es sollen nur solche personenbezogenen Daten erhoben werden, die für den Zutrittszweck erforderlich sind, und sie dürfen nicht für andere Zwecke (etwa Leistungsüberwachung) missbraucht werden. Die Nutzung der Daten muss transparent sein – betroffene Personen (Mitarbeiter, Besucher) sind in einer Datenschutzerklärung über Art und Zweck der Datenerhebung zu informieren. Die Daten sind vor unbefugtem Zugriff zu schützen und nur einem eng begrenzten Personenkreis zugänglich (daher wieder das Rollen/Rechte-Konzept!). Zudem dürfen Zutrittslogs nicht unbegrenzt aufbewahrt werden. Die DSGVO schreibt vor, dass personenbezogene Daten zu löschen sind, sobald der Zweck erfüllt ist (Art. 5 Abs.1 lit. e DSGVO, „Speicherbegrenzung“). In vielen Unternehmen werden daher Aufbewahrungsfristen für Zutrittsdaten definiert – z.B. normale Zutrittsprotokolle nach 90 Tagen automatisiert löschen oder anonymisieren, sofern keine sicherheitsrelevanten Gründe für eine längere Aufbewahrung bestehen. Anders mag dies bei sicherheitsrelevanten Vorfällen sein (z.B. ein unautorisierter Zutrittsversuch), hier kann eine längere Aufbewahrung zu Beweiszwecken gerechtfertigt sein. Das Customizing des Systems sollte es ermöglichen, solche Löschkonzepte technisch umzusetzen (z.B. per Scheduler, der alte Logeinträge entfernt).

• Ein weiterer Aspekt sind sensible Daten: Wenn biometrische Merkmale verwendet werden (Fingerabdruck, Handvenenscan etc.), gelten noch strengere Maßstäbe, da es sich um besondere Kategorien personenbezogener Daten handelt. Hier ist meist eine ausdrückliche Einwilligung der Betroffenen erforderlich, und die Daten müssen hochverschlüsselt gespeichert werden. Einige moderne Systeme umgehen dies, indem sie z.B. den Fingerabdruck-Template nur auf der Karte des Benutzers speichern, nicht in der zentralen Datenbank – so verbleiben die biometrischen Daten bei der Person selbst. Dies wird als datenschutzfreundliche Technik betrachtet, da eine massenhafte zentrale Speicherung vermieden wird. Solche Privacy-by-Design-Maßnahmen sind im Customizing besonders zu würdigen.

• Auch bei der Einbindung von Fremdfirmen greift der Datenschutz: Externe Mitarbeiter müssen ebenfalls über die Verarbeitung ihrer Daten informiert werden. Im Fremdfirmenportal sollte also ein Datenschutzhinweis eingebunden sein, den die Nutzer akzeptieren müssen. Zudem ist mit jeder Fremdfirma, die im Portal Daten ihrer Mitarbeiter eingibt, ggf. ein Vertrag zur Auftragsverarbeitung zu schließen, wenn die Fremdfirma im Auftrag des Betreibers handelt. Hier verschwimmen die Rollen, daher ist juristische Beratung sinnvoll.

• Nicht zuletzt verlangt die DSGVO Rechenschaftspflicht: Das Unternehmen muss nachweisen können, dass es die Datenschutzgrundsätze einhält. In Audits sollte man also darlegen können, welche technischen und organisatorischen Maßnahmen zum Schutz der Zutrittsdaten ergriffen wurden. Ein Beispiel: Die Anlage von Zutrittsprotokollen kann als technische-organisatorische Maßnahme im Sinne von Art. 32 DSGVO gelten, um Zugriffe auf besonders sensible Bereiche zu kontrollieren (im früheren BDSG war die „Zutrittskontrolle“ sogar explizit als Maßnahme genannt). Gleichzeitig muss man aber auch zeigen, wie man die erhobenen Daten schützt – hier greifen dann die IT-Sicherheitsmaßnahmen.

• IT-Sicherheit und verwandte Standards: Neben den bereits erwähnten technischen Normen (DIN EN 60839, BSI-Richtlinien) gibt es auch übergeordnete Standards, die das Sicherheitsmanagement betreffen, z.B. ISO/IEC 27001 für Informationssicherheits-Managementsysteme. Ein Zutrittskontrollsystem leistet einen Beitrag zur physischen Sicherheit (ISO 27001 Annex A.11 „Physical and Environmental Security“ behandelt z.B. Zutrittskontrollen zu Betriebsstätten). Unternehmen, die zertifiziert sind oder eine Zertifizierung anstreben, sollten sicherstellen, dass ihr Zutrittssystem diesen Anforderungen entspricht. Dazu gehört z.B., dass Zutrittsberechtigungen regelmäßig überprüft werden (mindestens jährlich kontrollieren, ob noch alle Berechtigungen nötig sind), dass ein Widerrufsprozess existiert (bei Austritt eines Mitarbeiters werden alle Zugänge entzogen) und dass Besucher begleitet werden in sensiblen Bereichen. Zwar sind dies organisatorische Maßnahmen, doch ein flexibles Zutrittskontrollsystem kann deren Einhaltung technisch unterstützen (z.B. indem Besucherausweise automatisch ablaufen und nur in Begleitung gültig sind etc.).

• Im Bereich der Safety (Arbeitssicherheit, z.B. nach den Vorgaben der DGUV in Deutschland) spielen Zutrittssysteme ebenfalls eine Rolle: Bei Gefahrenlagen (Feueralarm etc.) müssen Systeme z.B. „offen“ failen (Türen auf, damit Evakuierung nicht behindert wird) – solche Verhaltensweisen sind oft normativ vorgeschrieben (Stichwort Notausgangsregelungen). Normen wie DIN EN 60839-11-2 definieren Anwendungsregeln, die z.B. fordern, dass im Brandfall die elektronische Verriegelung freigibt. Ein konformes System sollte also mit der Brandmeldeanlage gekoppelt sein. Aus Customizing-Sicht ist zu beachten, dass solche Kopplungen getestet und dokumentiert werden (z.B. im Sicherheitskonzept des Gebäudes). Ebenso sollte das Zutrittssystem regelmäßig gewartet und geprüft werden, wie es Sicherheitsnormen verlangen – man denke an die VdS-Richtlinien (z.B. VdS 2359 Prüfmethoden für Zutrittskontrollanlagen), die beschreiben, wie man die Funktionsfähigkeit sicherstellt.

• Arbeitsrecht: Das Arbeitsrecht überschneidet sich teilweise mit Datenschutz (Arbeitnehmerdatenschutz) und Mitbestimmung (BetrVG, s.o.), hat aber noch eigene Facetten. Ein hochaktuelles Thema ist die Arbeitszeiterfassung: Nach einem Urteil des Europäischen Gerichtshofs und einer Entscheidung des Bundesarbeitsgerichts 2022 besteht für Arbeitgeber die Pflicht, ein System zur Erfassung der Arbeitszeit bereitzustellen. Ein Zutrittskontrollsystem kann – sofern es entsprechend konzipiert ist – diese Pflicht erfüllen, indem die Kommen/Gehen-Buchungen als Zeiterfassung dienen. Allerdings muss dabei sichergestellt sein, dass alle relevanten Zeiten erfasst werden (z.B. Pausen kennt ein reines Zutrittssystem u.U. nicht automatisch, wenn Mitarbeiter das Gelände nicht verlassen). Hier kann durch Customizing eine Verzahnung mit Zeitwirtschaftssystemen oder eine Ergänzung um Pausenerfassung erfolgen. Arbeitsrechtlich relevant ist ferner die Einhaltung von Arbeitszeitgrenzen (tägliche Höchstarbeitszeit, Mindestruhezeiten zwischen Schichten). Ein angepasstes System könnte z.B. Warnungen ausgeben, wenn ein Mitarbeiter sich nach zu kurzer Ruhezeit wieder anmeldet, oder einem Schichtarbeiter nach 10 Stunden kein Zutritt mehr gewähren (sofern gewollt). Solche Funktionen müssen aber sorgfältig mit den betrieblichen Vereinbarungen abgestimmt sein, um keine ungewollten Arbeitsblockaden zu verursachen.
  Auch das Arbeitsschutzgesetz fordert in §8 die Kooperation von Arbeitgebern, wenn Beschäftigte verschiedener Firmen am selben Arbeitsplatz tätig sind. Das heißt, der Gastgeber (Auftraggeber) und der Fremdfirmen-Arbeitgeber müssen zusammenwirken, um Sicherheit zu gewährleisten. Das Fremdfirmenportal und die Zutrittssteuerung tragen dazu bei, diesen Koopera­tionspflichten nachzukommen, indem z.B. klare Regeln für den Zugang nur bei erfüllten Sicherheitsauflagen gesetzt werden.

• Best Practices und Compliance-Nachweise: Letztlich sollte das Zutrittssystem so angepasst sein, dass es nicht nur den Gesetzen genügt, sondern dass es auch Auditanforderungen besteht. Interne Audits, Kundenaudits (z.B. bei kritischer Infrastruktur), Zertifizierungen (TISAX in der Automobilbranche, ISO 27001 etc.) – all diese Prüfungen legen Wert auf gelebte Prozesse. Ein erfolgreiches Customizing bringt das Unternehmen in die Lage, jederzeit zeigen zu können: „Wer darf wo rein und warum? Wie ist das genehmigt worden? Wie stellen wir sicher, dass nur Berechtigte reinkommen? Was passiert mit den Daten?“ Wenn all diese Fragen schlüssig beantwortet und im System hinterlegt sind, ist man bestens für jegliche Überprüfung gewappnet. Dokumentationen (für Datenschutz-Folgenabschätzung, für IT-Sicherheitsaudits etc.) sollten im Projekt gleich mit erstellt werden.

Zur Veranschaulichung der erläuterten Konzepte sollen abschließend einige praktische Beispiele und bewährte Vorgehensweisen aus der Industrie betrachtet werden, die den erfolgreichen Einsatz von Customizing bei Zutrittskontrollsystemen demonstrieren.

Große Chemie- und Pharmaunternehmen gehören zu den Vorreitern bei der strikten Kontrolle von Fremdfirmen auf ihrem Gelände. Ein Best-Practice-Beispiel ist ein Chemiepark, in dem alle Fremdfirmenmitarbeiter vorab online registriert und geschult werden. Das Unternehmen führte ein spezialisiertes Fremdfirmenportal ein, das vollständig mit dem Zutrittskontrollsystem verknüpft ist. Customizing-Highlights in diesem Projekt: Das Portal prüft automatisch, ob jede externe Person die erforderlichen Sicherheitsschulungen absolviert hat und ob alle Dokumente (Auftragsdaten, Gesundheitsnachweise, Sicherheitsunterweisungen) vorliegen. Erst dann wird im Zutrittssystem ein temporäres Zugangsprofil freigeschaltet. Ein Fremdfirmenbeschäftigter, der z.B. seine jährliche Sicherheitsunterweisung nicht gemacht hat, erhält am Werkstor keinen Zutritt – das Drehkreuz bleibt für ihn gesperrt, bis die Unterweisung nachgeholt ist. Dieses Vorgehen hat zu messbaren Erfolgen geführt: Die Zahl der Zwischenfälle mit Fremdfirmen sank deutlich, da nun jeder auf dem Gelände anwesende Externe nachweislich die Sicherheitsregeln kannte. Zudem konnten interne Abläufe optimiert werden – Sicherheitsingenieure müssen nicht mehr jede Unterweisung manuell kontrollieren, das System übernimmt die Überwachung der Gültigkeiten. Das erwähnte Sicherheitshandbuch für Fremdfirmen wird hier digital als Teil des Workflows eingesetzt; es gilt als Bestandteil jeder Beauftragung und wird bei der Online-Registrierung vom Fremdfirmenverantwortlichen bestätigt. Dieses Beispiel zeigt, wie durch konsequentes Customizing (Portal+Zutritt gekoppelt, Regeln strikt implementiert) sowohl Compliance als auch Effizienz gesteigert wurden.

In einem internationalen Automobilkonzern wurde das konzernweite Zutrittskontrollsystem mit SAP HCM und dem unternehmensweiten Identity Management verknüpft, um personelle Veränderungen sofort in Zutrittsberechtigungen zu übersetzen. Konkret bedeutet das: Sobald im SAP-System ein Mitarbeiter angelegt wird, erhält er automatisch in der Zutrittssoftware ein Benutzerkonto mit Basisberechtigungen für seinen Standort. Ändert sich die Abteilung oder Rolle (z.B. Beförderung zum Manager), so wird über das Identity Management ein geänderter Berechtigungsdatensatz ans Zutrittssystem geschickt, welches daraufhin z.B. die Zutrittsprofile (etwa nun Zugang zum Management-Parkplatz und zur Vorstandsetage) aktualisiert. Beim Ausscheiden eines Mitarbeiters wird in dem Moment, wo HR im SAP das Austrittsdatum einträgt, automatisch das Ablaufdatum des Ausweises gesetzt und alle Profile werden zum letzten Arbeitstag entzogen. Dieses Ende-zu-Ende Customizing verhindert Sicherheitslücken durch vergessene Berechtigungen und reduziert den Administrationsaufwand drastisch – die Sicherheitszentrale muss nicht mehr jeder Personaländerung nachtelefonieren, sondern agiert im Ausnahmefall (z.B. bei Sonderberechtigungen) unterstützend. Möglich wurde dies durch eine Kombination aus standardisierten Schnittstellen (SAP HR-PDC) und Zusatzlogik im Identity Management. Der Anbieter des Zutrittssystems (Interflex IF-6040) stellte die zertifizierte SAP-Schnittstelle bereit, um alle notwendigen Buchungs- und Stammdaten zuverlässig austauschen zu können. Damit konnte das Projekt in kurzer Zeit umgesetzt werden, ohne individuelle Schnittstellenprogrammierung von Grund auf. Der Konzern berichtet von höherer Transparenz: Auditberichte können nun jederzeit zeigen, welcher Mitarbeiter wann welche Zutrittsrechte hatte und wer dies genehmigt hat – eine wichtige Grundlage für interne Audits und die ISO-27001-Zertifizierung, die das Unternehmen anstrebt.

In einem hochsicheren Rechenzentrum wurden durch Customizing die physischen Zutrittskontrollen mit organisatorischen Maßnahmen verknüpft. Das Zutrittssystem wurde so angepasst, dass bestimmte Hochsicherheitsbereiche (z.B. Serverraum) nur im Vier-Augen-Prinzip betreten werden können: Es müssen sich zwei berechtigte Personen nahezu zeitgleich anmelden, erst dann entriegelt die Schleuse. Dazu wurde ein spezieller Workflow konfiguriert, der die Buchungen von zwei verschiedenen Ausweisen innerhalb von 30 Sekunden an einem Doppelleser verlangt. Außerdem ist eine Escort-Funktion eingerichtet: Externe Wartungstechniker erhalten nur zusammen mit einem internen Mitarbeiter Zutritt. Realisiert wurde dies, indem das System bei einer geplanten Wartung automatisch einen temporären Besucherausweis generiert, der aber technisch an den Ausweis des begleitenden Mitarbeiters gekoppelt ist – sobald der Mitarbeiter auscheckt, erlischt auch die Zugangsberechtigung des Besuchers. Solche komplexen Logiken erforderten tiefes Customizing in der Software. Glücklicherweise stellte der Hersteller ein SDK (Software Development Kit) zur Verfügung, mit dem Erweiterungen implementiert werden konnten. Das Rechenzentrum hat so seine speziellen Anforderungen (die über Standardfunktionen hinausgingen) erfolgreich umgesetzt. Im Zuge dessen wurden natürlich auch höchste Datenschutz- und IT-Sicherheitsmaßnahmen berücksichtigt: Alle Zutritte sind lückenlos dokumentiert und werden im SIEM (Security Information and Event Management) überwacht. Das Beispiel verdeutlicht, dass man durch Customizing sogar außergewöhnliche Sicherheitskonzepte abbilden kann – wichtig ist jedoch, dass solche Lösungen gut getestet sind und im Ernstfall zuverlässig funktionieren. Die Audits der Kunden (Banken, Versicherungen) hat das RZ mit diesen Maßnahmen stets ohne Befund bestanden, da es nachweisen konnte, dass Best Practices wie das Vier-Augen-Prinzip strikt und technisch unumgehbar implementiert sind.

Ein anderes Beispiel stammt von einem großen Technologie-Campus mit mehreren tausend Beschäftigten und täglichen Besuchern. Hier lag der Fokus des Customizing auf der Benutzerfreundlichkeit und Akzeptanz. Das Unternehmen führte eine Mitarbeiter-Self-Service-App ein, über die Beschäftigte z.B. Besuchereinladungen selbst erstellen können (die dann vom Empfang nur noch bestätigt werden) oder temporäre Zugangsrechte beantragen können, wenn sie bereichsübergreifend arbeiten. Diese App greift über die offene API auf das Zutrittssystem zu. Das Customizing betraf vor allem die UI/UX-Gestaltung dieser App sowie die Definition, welche Anträge automatisch genehmigt werden und welche eskaliert werden müssen. Ergebnis: ein deutlich verschlankter Prozess für Besucheranmeldungen – keine E-Mails oder Formulare mehr, sondern ein paar Klicks in der App, was insbesondere von der jungen Belegschaft sehr gut angenommen wurde. Um die Akzeptanz weiter zu erhöhen, wurden auch datenschutzfreundliche Voreinstellungen getroffen: In der App sieht man z.B. nicht die Anwesendheitsliste aller Kollegen (aus Datenschutzgründen), sondern kann nur den Status der eigenen Besucher oder Anträge verfolgen. Gleichzeitig wird transparent angezeigt, welche persönlichen Zutrittsdaten gespeichert sind, und es gibt die Möglichkeit, bei HR eine Datenauskunft zu beantragen per Klick. Diese freiwillige Transparenz schaffte Vertrauen und nahm Befürchtungen vor Überwachung. Die Best Practice hier ist, Mitarbeiter früh einzubeziehen – schon bei der Entwicklung der App wurden Mitarbeiterumfragen gemacht, um das Design zu optimieren. Die Kombination aus technischer Raffinesse (App-Integration, API-Nutzung) und konsequenter Ausrichtung auf den Endnutzer führte dazu, dass das System breit akzeptiert wurde und die Sicherheitskultur am Campus stärkte (z.B. melden Mitarbeiter Fremdpersonen ohne Ausweis schneller, da ihnen die Wichtigkeit bewusster ist).

Diese vier Beispiele – aus Chemie, Automotive, Datacenter und Tech-Campus – zeigen verschiedene Facetten von Customizing-Projekten. Gemeinsam ist ihnen, dass unternehmensspezifische Anforderungen in den Vordergrund gestellt und mit technischen Lösungen untermauert wurden.

• Enges Zusammenwirken von Fachabteilungen und IT/Security: In allen Fällen war die Kooperation zwischen den späteren Nutzern (Sicherheitsingenieuren, HR, Facility Management) und den technischen Teams (IT, Hersteller) entscheidend, um passgenaue Lösungen zu finden.

• Nutzung vorhandener Standards mit kluger Erweiterung: Wo immer möglich, wurden bestehende Schnittstellen und Module genutzt (SAP-Connector, SDK, API), um Stabilität zu gewährleisten. Nur wo nötig, wurde spezialisierte Funktionalität hinzugefügt.

• Schulung und Kommunikation: Die Belegschaft und auch Fremdfirmen wurden aktiv mitgenommen – sei es durch Sicherheitshandbücher, Schulungen oder nutzerfreundliche Apps. So wurde aus einer technischen Änderung ein gelebter Prozess.

• Überprüfung und Auditierung: Alle Projekte wurden durch interne oder externe Audits begleitet, um sicherzustellen, dass die Ziele erreicht wurden (z.B. Reduktion von Zwischenfällen, Einhaltung der Normen). Das Feedback floss wiederum in Verbesserungen ein.

Kurzum: Die Industrieerfahrungen zeigen, dass ein gut geplantes und durchgeführtes Customizing-Projekt die Sicherheit erhöht, manuelle Aufwände reduziert und oft auch nebenbei die Unternehmenskultur positiv beeinflusst (Stichwort: Sicherheitsbewusstsein, Vertrauen durch Transparenz). Diese Best Practices können als Leitfaden für zukünftige Projekte dienen.