Lastenheft für ein integriertes Zutrittskontrollsystem

In diesem Abschnitt werden funktionale Module eines zeitgemäßen Zutrittskontrollsystems für das beschriebene Industrieareal erläutert. Die Beschreibung erfolgt produktneutral, jedoch so detailliert, dass klare Anforderungen für jede Funktionseinheit formuliert sind. Das Ziel ist ein ganzheitliches System, das physische Sicherheit, Prozessautomatisierung und Benutzerfreundlichkeit verbindet. Im Einzelnen umfasst das ZKS folgende Module:

Die Zutrittssteuerung bildet das Kernmodul des Systems. Sie regelt wer wann wo Zugang erhält und gewährleistet, dass ausschließlich berechtigte Personen definierte Bereiche betreten können. Zentral ist ein Berechtigungsmanagement, in dem für alle Personen (Mitarbeiter, Externe, Besucher) individuelle Zutrittsprofile hinterlegt sind.

• Elektronische Ausweismedien: Jeder Nutzer erhält ein Identifikationsmedium (z. B. kontaktlose RFID-Smartcard, Schlüsselanhänger oder ein mobiles Credential auf dem Smartphone). Diese Ausweise dienen als transponderbasiertes Identifikationsmerkmal und müssen hochsicher (moderne Verschlüsselung, Manipulationsschutz) sein. Alternativ oder ergänzend können Biometrie-Verfahren (z. B. Fingerabdruck, Handvenenscanner oder Iriserkennung) für Hochsicherheitsbereiche eingesetzt werden, um 2-Faktor-Authentifizierung zu realisieren (Karte und Biomerkmal). PIN-Codes können ebenfalls als zusätzlicher Faktor dienen, sind aber als alleinige Methode in modernen Anlagen selten geworden. Die Wahl der Identifikationsmethoden richtet sich nach dem Sicherheitsgrad der Bereiche gemäß DIN EN 60839-11-1, die Risikograde von 1 (niedrig) bis 4 (hoch) definiert in hochsensiblen Zonen sind Kombinationen (Karte+PIN oder Karte+Biometrie) vorzusehen, während in niedrigeren Risikostufen der Ausweis allein genügt.

• Lesegeräte und Türsteuerungen: An allen relevanten Zugängen werden elektronische Kartenleser installiert, die die Ausweismedien auslesen. Diese Leser müssen wetterfest und vandalensicher ausgeführt sein (insbesondere an den Außenbereichen und Werkstoren). Sie unterstützen moderne Schnittstellen (bevorzugt OSDP v2 gegenüber klassischem Wiegand) für eine durchgängig verschlüsselte Kommunikation in Echtzeit. Jeder Zutrittspunkt (Tür, Tor, Schranke) ist mit einer geeigneten Türsteuerungseinheit oder Zutrittskontrollpanel verbunden, die die Zugriffsentscheidung lokal umsetzt (Ansteuerung von elektrischen Türschlössern, Drehkreuzen oder Schrankenmotoren). Dabei müssen Türzustände (offen/geschlossen, Verriegelungsstatus) überwacht werden. Im Falle eines unautorisierten Türöffnungsversuchs oder Sabotage am Leser sollen Alarmmeldungen an das zentrale Managementsystem und ggf. an den Sicherheitsleitstand gesendet werden.

• Zentralsoftware und Entscheidungslogik: Die Entscheidung über Zutritt (Freigabe oder Verweigerung) erfolgt anhand von Regeln, die in der zentralen ZKS-Software hinterlegt sind. Hier werden Zutrittsberechtigungen verwaltet: z. B. darf Mitarbeiter X mit Profil "Labor" von Mo–Fr 8–18 Uhr die Laborgebäude A und B betreten, aber keine Produktionshallen, etc. Besucher Y hat nur am Besuchstag von 9–16 Uhr Zugang durch das Haupttor und ins Besprechungszentrum. Diese Regeln sollen flexibel konfigurierbar sein (Kalender, Schichtmodelle, Feiertage, Besuchszeitfenster etc.). Die Software prüft bei jeder Anmeldeanfrage am Leser die Gültigkeit des Ausweises (z. B. nicht abgelaufen oder gesperrt) und das Zutrittsrecht für den spezifischen Bereich und Zeitpunkt. Aufgrund der Größe des Areals und möglicher Netzwerkausfälle ist es erforderlich, dass Entscheidungen dezentral gepuffert werden können: d. h. lokale Türcontroller sollen bei Verbindungsverlust zum Server temporär autonom weiterarbeiten (mit zwischengespeichertem Berechtigungsbestand), um einen hochverfügbaren Betrieb zu gewährleisten.

• Anti-Passback und Zonenverwaltung: Für bestimmte Bereiche mit hohem Sicherheitsbedarf (z. B. Reinstraumlabore oder Hochsicherheitsarchive) soll das System Anti-Passback-Regeln unterstützen. Das bedeutet, ein Ausweis kann nicht zweimal hintereinander ohne Verlassen der Zone genutzt werden (verhindert Weiterreichen der Karte an Unbefugte). Hierfür ist eine Zonenverwaltung nötig, welche erkennt, ob sich ein Ausweisinhaber bereits innerhalb einer definierten Zone befindet. Ebenso sollen Bereichszähler eingerichtet werden können, um z. B. Personenanzahlen in einem Sektor zu beschränken oder im Evakuierungsfall die im Gebäude anwesenden Personen feststellen zu können.

• Notfall- und Fluchtkonzept: Die Zutrittssteuerung muss sich in das Sicherheitskonzept für Notfälle einfügen. Türen an Rettungswegen müssen auch bei aktivierter Zutrittskontrolle jederzeit von innen ohne Hilfsmittel zu öffnen sein (Paniktür-Funktion nach DIN EN 179/Normen für Notausgänge) – hier ist eine Integration mit der Brandmeldeanlage vorgesehen (siehe weiter unten), sodass im Brandfall alle elektrisch verriegelten Türen auf Fail Safe-Stellung gehen (Entriegelung zur sicheren Evakuierung). Gleichzeitig sollen kritische Außenbereiche bei Stromausfall oder Systemausfall gegen unkontrolliertes Eindringen abgesichert bleiben (z. B. Außentore in Fail Secure verriegelt bleiben, sofern rechtlich zulässig). Mechanische Notschlüssel oder Überbrückungs-Schalter sind für den Fall eines Systemausfalls bereitzuhalten (siehe Notfallkonzepte). Das Systemprotokoll muss im Nachgang eines Ereignisses nachvollziehbar aufzeigen, welche Türen wann automatisch entriegelt wurden und wer evtl. welche Notfallbedienung vorgenommen hat.

• Ausweiserstellung und -verwaltung: Als Teil der Zutrittssteuerung ist ein Ausweismanagement vorzusehen. Neue Mitarbeitende oder Besucher müssen einfach und effizient einen Ausweis erhalten. Das System soll eine Ausweiserstellung mit Fotoerfassung, Personalisierung (Druck von Namen/Firmenlogo) und Kodierung des RFID-Chips ermöglichen. Idealerweise werden Mitarbeiterausweise zugleich für mehrere Funktionen genutzt (Single Badge Konzept): Zutritt, Zeiterfassung, ggf. Kantine, Spind- oder PC-Zugang. Die Software muss die Ausstellung, den Tausch (bei Defekt) und die Deaktivierung (bei Verlust oder Ausscheiden) von Karten lückenlos dokumentieren. Im Verlustfall ist eine sofortige Sperrung im System mit nachgelagerter Info an den Finder (falls die Karte wieder auftaucht) erforderlich – entsprechende Betriebsrichtlinien (z. B. Meldepflicht des Verlusts binnen 24h) werden organisatorisch festgelegt. Auch Besucherausweise (temporäre Karten) sollen verwaltet werden, inklusive automatischer Ablaufsteuerung (z. B. Deaktivierung nach Ende des Besuchstags).

Insgesamt gewährleistet das Modul Zutrittssteuerung, dass alle Türen und Zugänge elektronisch kontrolliert und protokolliert werden. Es bildet die technische Umsetzung des Wer-darf-wo-wann–Prinzips und schafft Transparenz darüber, welche Person sich wann in welchem Bereich aufgehalten hat. Damit wird nicht nur Sicherheit erhöht, sondern es werden auch Compliance-Vorgaben (z. B. Nachvollziehbarkeit für Audits, Nachweis von Unterweisungen vor Zutritt, usw.) erfüllt.

Das Besuchermanagement umfasst alle Funktionen zur Verwaltung von Besuchern, Kunden und Gästen, die das Werksgelände temporär betreten. Angesichts der bisherigen Excel-Lösung soll ein professionelles, digitales Besuchermanagement-Modul eingeführt werden, das den Prozess vom Einladungsschreiben bis zum Auschecken abbildet.

• Vorabregistrierung und Einladung: Interne Mitarbeiter (als Gastgeber) sollen Besuche vorab im System anmelden können, idealerweise via Outlook-Integration oder Web-Portal. Dabei werden die Besuchsdaten erfasst (Name, Firma, Besuchsdatum, Uhrzeit, Ansprechperson, Besuchszweck). Automatisiert soll eine Einladung per E-Mail an den Besucher versendet werden können, die z. B. einen QR-Code oder einen PIN für den Selbst-Check-in enthält. Durch diese Vorabregistrierung wird der Empfang entlastet und Wartezeiten reduzieren sich.

• Check-in und Ausweisausgabe: Beim Eintreffen meldet sich der Besucher am Empfang oder an einem Self-Service-Terminal an. Optionen: Self-Check-in-Kiosk mit Touchscreen, an dem der Besucher den QR-Code scannt oder seinen Namen eingibt. Der Empfangsterminal druckt automatisch einen Besucherausweis aus und kann die Sicherheitsunterweisung sowie Betriebsregeln anzeigen, die der Besucher bestätigen muss (digitale Unterschrift). Alternativ oder ergänzend betreut ein Empfangsmitarbeiter den Prozess mit der Besuchermanagement-Software. Der Besucherausweis wird entweder als Papierbadge mit Clip oder als temporäre RFID-Karte ausgegeben. Letztere kann im Zutrittssystem für die Dauer des Besuchs freigeschaltet werden (z. B. Zutritt nur durch das Haupttor und Zugang zu bestimmten Gebäudeteilen wie Besprechungsräume). Nach Unterschrift aller erforderlichen Dokumente (z. B. Datenschutz- oder Geheimhaltungserklärungen) wird der Ausweis aktiviert. Das System muss revisionssicher dokumentieren, welcher Besucher wann angemeldet wurde, welche Unterweisungen er erhalten hat und welche Bereiche er betreten durfte.

• Sicherheitsunterweisung und Einweisung: Besucher in Industriebetrieben müssen in der Regel vor Betreten des Werks eine Sicherheitsunterweisung erhalten (z. B. Verhaltensregeln, Notfallmaßnahmen, PSA-Pflichten) gemäß den einschlägigen Unfallverhütungsvorschriften (DGUV). Das Besuchermanagement-Modul soll diese Unterweisungen digital unterstützen: entweder durch Vorauszusendung eines E-Learning-Links oder direkt am Terminal vor Ort. Die Unterweisung sollte mehrsprachig verfügbar sein (für internationale Gäste) und idealerweise mit Überprüfung (Quiz oder Zustimmung) abschließen. Das System speichert die Bestätigung (Unterschrift digital auf dem Terminal) zusammen mit Zeitstempel, um nachweisen zu können, dass der Besucher ordnungsgemäß belehrt wurde. Diese Daten unterliegen dem Datenschutz und sollen nach einer definierten Frist gelöscht werden (siehe Datenschutz-Kapitel), aber bis dahin auditierbar bereitstehen.

• ID-Check und Zugangsregeln: Bei Besuchen in sicherheitskritischen Bereichen kann es erforderlich sein, die Identität des Besuchers amtlich zu überprüfen (ID-Check). Das System soll daher die Möglichkeit bieten, Ausweisdokumente wie Personalausweis/Reisepass einzuscannen oder die Ausweisnummer zu hinterlegen. So kann z. B. an Hochsicherheitslaboren verlangt werden, dass nur Besucher mit vorherigem Sicherheitscheck zugelassen werden. Ebenso sind Regeln möglich wie "Besucher dürfen nur in Begleitung ihres Ansprechpartners die Produktion betreten". Solche Abläufe müssen organisatorisch geklärt und technisch unterstützt werden (etwa durch Benachrichtigung an den Mitarbeiter, sobald sein Besuch eintrifft, oder durch Erfordernis, dass der Mitarbeiter mit seiner Karte die Tür mit freigibt).

• Besucherdatenverwaltung und -auschecken: Das System speichert alle relevanten Besucherdaten während des Besuchsvorgangs. Nach Ende des Besuches soll ein Check-out erfolgen – entweder automatisch (durch Abgabe des Ausweises am Ausgang oder Einwurf in eine Rückgabebox mit Leser) oder manuell durch den Empfang. Dabei wird der Besucherausweis deaktiviert. Das System protokolliert die tatsächliche Besuchszeit (Ankunfts- und Austrittszeit). Im Sinne der DSGVO dürfen Besucherdaten nicht unbegrenzt aufbewahrt werden; es sind Löschfristen zu definieren (z. B. automatische Anonymisierung/Löschung personenbezogener Besucherdaten nach 6 oder 12 Monaten, sofern keine gesetzlichen Aufbewahrungspflichten entgegenstehen). Für regelmäßige Besucher oder Besuchergruppen (z. B. Lieferanten, die täglich kommen) sollte das System Stammdaten führen können, um den Anmeldeprozess bei jedem Besuch zu beschleunigen.

• Besucherstatistiken und Reporting: Zur Auswertung und für das betriebliche Sicherheitsmanagement soll das Modul Berichte erzeugen können, z. B. Anzahl Besucher pro Tag/Woche, Spitzenzeiten, durchschnittliche Besuchsdauer, usw. Diese Informationen helfen bei der Personalplanung am Empfang und können im Kontext der Gefährdungsbeurteilung relevant sein (etwa um die Auslegung von Versammlungsstätten und Rettungswegen zu prüfen, falls regelmäßig viele Externe anwesend sind).

Durch ein modernes Besuchermanagement wird der Empfangsprozess effizienter und sicherer. Gäste fühlen sich professionell betreut, Wartezeiten sinken, und alle rechtlichen Vorgaben (Dokumentationspflichten, Unterweisungen) werden digital und nachvollziehbar umgesetzt. Im Störungsfall (z. B. Systemausfall) muss ein manueller Notprozess definiert sein (z. B. Besucherliste auf Papier führen), siehe Notfallkonzepte.

Die Zufahrtskontrolle für Fahrzeuge deckt alle Funktionen im Bereich der Werkszufahrten und Parkplätze ab, insbesondere die drei Einfahrten des Areals, die für PKW und LKW genutzt werden. Hier gilt es, autorisierte Fahrzeuge schnell und sicher einzulassen, unberechtigte fernzuhalten und Logistikprozesse zu optimieren.

• Schrankenanlagen und Tore: An jeder Einfahrt sind bereits Schranken oder elektrische Tore vorhanden (derzeit teils manuell bedient). Diese sollen in das neue System integriert werden, sodass eine automatisierte Schrankensteuerung möglich ist. Jede Schranke wird mit einer Zutrittskontrollkomponente versehen: etwa einem Fahrzeugkartenleser, einer Kennzeichenerkennungskamera oder einem Pin-Code-Keyboard für LKW. Mitarbeiter-PKW könnten z. B. einen langreichweitigen RFID-Transponder (UHF-Windshield-Tag) erhalten, der vom System aus einigen Metern Entfernung gelesen wird, um die Schranke zu öffnen, ohne aus dem Fahrzeug auszusteigen. Alternativ oder ergänzend kann videobasierte Kennzeichenerkennung eingesetzt werden: Kameras erfassen das Kennzeichen ankommender Fahrzeuge und gleichen es mit einer hinterlegten Zulassungsliste ab. Das System soll dabei auch kombinierte Logiken erlauben (etwa Kennzeichen + Zeitfenster, oder Kennzeichen + Fahrerkarte für höhere Sicherheit). Für Fremdfirmen-LKW oder Besucher-PKW, die nicht im Besitz eines firmeneigenen Transponders sind, müssen andere Mechanismen greifen (z. B. Anmeldung am Terminal, s.u.). Die Schrankensteuerung ist so zu gestalten, dass Unfälle vermieden werden (Schranke nur schließen, wenn Schleifendetektor keine Fahrzeuge mehr erkennt; Berücksichtigung von DGUV-Vorschriften für kraftbetätigte Tore bzgl. Scherstellen etc.). Integrierte Ampeln oder Signalgeber können den Fahrern anzeigen, wann die Durchfahrt erlaubt ist.

• LKW-Terminals und Lieferverkehr: Für den schweren Lieferverkehr (LKW) ist ein spezielles Terminalsystem vorzusehen. Häufig kommen LKW-Fahrer außerhalb der normalen Arbeitszeiten und sprechen nicht immer Deutsch, daher ist ein mehrsprachiges Fahrer-Terminal an den LKW-Einfahrten sinnvoll. Dieses Terminal (robuste Outdoor-Säule in LKW-Fensterhöhe) verfügt über Touchscreen oder Tastenbedienung, optional Sprechanlage, Scanner und Drucker. Der Workflow könnte wie folgt aussehen: Ein anliefernder LKW fährt vor die Schranke und hält am Terminal. Dort identifiziert er sich z. B. mittels Liefercode oder QR-Code, der ihm vorab mitgeteilt wurde (bei erwarteten Lieferungen), oder er meldet sich über eine Ruftaste beim Werkschutz. Das System könnte auch einen Sprachdialog anbieten. Nach erfolgreicher Identifikation (oder Freigabe durch den Werkschutzmitarbeiter per Fernentriegelung) öffnet sich die Schranke. Das Terminal kann dem Fahrer auch Anweisungen geben (z. B. "Fahren Sie zu Laderampe 3. Bitte bleiben Sie im Fahrzeug bis ein Mitarbeiter Sie einweist."). Außerdem kann das Terminal vor Ort Dokumente wie Lieferscheine scannen oder einen Besucherausweis für den Fahrer drucken, falls der Fahrer das Fahrzeug verlassen und ins Gebäude muss (z. B. zum Wartebereich oder WC). In die Terminals ist nach Möglichkeit das Sicherheitsunterweisungssystem integriert: Fahrer sollen ebenfalls die grundlegenden Verhaltensregeln bestätigen (evtl. per Tastendruck "Ich habe die Sicherheitsanweisungen gelesen und akzeptiert"). Das System muss den gesamten LKW-Zufahrtsvorgang ebenfalls protokollieren.

• Zufahrtsberechtigungen und Parkraummanagement: Analog zur Personenzutrittssteuerung werden auch für Fahrzeuge Berechtigungen verwaltet. Beispielsweise haben registrierte Mitarbeiterfahrzeuge permanent Zutritt zu definierten Parkplätzen, während Lieferanten nur in definierten Zeitfenstern Einlass erhalten. Besucher könnten im Vorfeld einen temporären Parkplatzcode erhalten. Das System soll in der Lage sein, diverse Merkmale zur Entscheidungsfindung heranzuziehen: Kennzeichen, RFID-Tag, Fahrer-ID, Uhrzeit, Fahrzeugtyp etc.. Gegebenenfalls ist das Zufahrtskontrollmodul mit einer Datenbank der Fahrzeugstammdaten verknüpft (z. B. in SAP oder im Besuchersystem werden KFZ-Kennzeichen mit hinterlegt). Für betriebsfremde Fahrzeuge wie Zulieferer ist eine enge Verzahnung mit dem Fremdfirmenmanagement (siehe nächster Abschnitt) sinnvoll, etwa indem externe Dienstleister bei Bedarf auch eine Zufahrtsberechtigung in ihrer Einladung erhalten.

• Integration von Speditionsterminen (Zeitfenster-Management): Das System soll idealerweise ein Zeitfenster-Management für Anlieferungen unterstützen. Über ein Lieferantenportal können Speditionen vorab Zeitfenster buchen, welche im System hinterlegt werden. Das Zutrittskontrollsystem gewährt dem LKW dann nur im gebuchten Zeitraum Zugang (oder mit definierter Toleranz). Verspätete oder verfrühte Ankünfte könnten abgewiesen oder in eine Warteschleife geschickt werden. Dies optimiert die Hoflogistik und vermeidet Staus an den Toren.

• Videoüberwachung und Gegensprechanlage: Jedes Tor sollte mit einer Videokamera und einer Gegensprechanlage gekoppelt sein. Das erlaubt dem Sicherheitszentrum, bei Unklarheiten mit dem Fahrer zu sprechen und visuell zu verifizieren, wer vorfährt. Die Videointegration (siehe separates Video-Modul) kann auch Kennzeichen erfassen und als zusätzlicher Trigger dienen. Alle Videobilder an den Toren müssen aus Datenschutzgründen angemessen gespeichert und nach kurzer Frist überschrieben werden, außer bei sicherheitsrelevanten Vorfällen (siehe Datenschutz).

• Notfallpläne für Zufahrt: Im Falle eines Ausfalls der automatischen Steuerung (z. B. Netzwerk down) muss ein manuelles Notfallverfahren greifen: etwa Öffnung der Schranken durch den Wachdienst (vor Ort Schlüsselschalter oder Handauf-Aufschaltung). Ebenso im Falle einer Evakuierung: Schranken sollten im Alarmfall ggf. offen bleiben, um Rettungsfahrzeugen Einlass zu gewähren und die Flucht nicht zu behindern. Solche Details werden im Notfallkonzept festgelegt.

Durch diese Komponenten wird die Fahrzeug-Zutrittskontrolle wesentlich automatisiert. Sie erlaubt einen schnelleren Durchsatz an den Werkszufahrten, reduziert Personalkosten (Wachpersonal muss nicht jede Schranke manuell bedienen) und erhöht gleichzeitig die Sicherheit, da alle Einfahrten lückenlos überwacht und gesteuert sind. Die Option der Kennzeichenerkennung und RFID-Longrange-Leser stellt sicher, dass berechtigte Fahrzeuge nahezu ohne Halt einfahren können. Gleichzeitig werden alle Einfahrten – analog zu Personenbewegungen – protokolliert, was im Bedarfsfall (Untersuchung eines Vorfalls, Nachvollziehen wer auf dem Gelände war) von großem Nutzen ist.

Neben regulären Besuchern gibt es im Industrieareal zahlreiche externe Firmen (Fremdfirmen, Subunternehmer), die für Wartungsarbeiten, Bauprojekte oder Dienstleistungen zeitweise vor Ort tätig sind. Diese Personengruppe erfordert ein eigenes Fremdfirmen-Management-Modul, da sie weder dauerhaft vor Ort sind wie Mitarbeiter noch lediglich kurzfristige Besucher. Die Herausforderungen liegen hier in der kontinuierlichen Betreuung über einen längeren Zeitraum, speziellen Sicherheitsanforderungen und der Integration mit anderen Prozessen (z. B. Arbeitssicherheit).

• Registrierung und Portal für Fremdfirmen: Externe Firmen, die einen Auftrag am Standort ausführen, sollen über ein Online-Portal verwaltet werden können. Eine beauftragte Fremdfirma kann im Vorfeld ihre Mitarbeiter, die auf das Werksgelände müssen, im System registrieren (Name, Geburtsdatum, ggf. Ausweisnr., Firmenname, Auftrag/Projekt, Einsatzdauer etc.). Dabei können Zugangsdauern definiert werden (z. B. Monteur der Firma X erhält vom 01.06. bis 30.06. Zutritt wochentags 08–17 Uhr). Dieses Portal dient auch als Kommunikationsplattform: Die Fremdfirma kann notwendige Unterlagen einreichen (Versicherungsnachweise, Zertifikate) und erhält im Gegenzug standortspezifische Informationen.

• Sicherheitsüberprüfungen und Zugangsfreigabe: Für bestimmte Branchen oder kritische Anlagen ist evtl. eine Sicherheitsüberprüfung der Fremdfirmen-Mitarbeiter nötig (z. B. Background-Check, Polizeiliches Führungszeugnis bei Arbeiten in sensiblen Bereichen). Das System sollte unterstützen, dass entsprechende Nachweise hinterlegt und vom Sicherheitsbeauftragten geprüft werden, bevor ein Zugang gewährt wird. Erst nach Freigabe in der Software werden die Ausweise für diese Personen aktiviert.

• Unterweisungen für Fremdfirmenmitarbeiter: Noch wichtiger als bei normalen Besuchern ist hier die Arbeitssicherheits-Unterweisung. Fremdfirmen müssen meist jährlich oder vor Arbeitsaufnahme eine ausführliche EHS-Unterweisung durchlaufen (z. B. Gefahren am Einsatzort, Verhaltensregeln, Werksordnung). Das System soll ein Online-Unterweisungssystem bieten, mit dem Fremdfirmenmitarbeiter bereits vor dem ersten Zutritt die Schulung absolvieren können. Idealerweise kann der Mitarbeiter nach Login im Fremdfirmen-Portal oder via zugesandtem Link eine E-Learning-Präsentation mit anschließenden Testfragen durchgehen. Das Ergebnis (Bestanden/Nicht bestanden) und die Zustimmungserklärung werden dokumentiert. Nur wer die Unterweisung erfolgreich abgeschlossen hat, erhält Zutrittsrechte. Alternativ kann vor Ort am Terminal eine Unterweisung stattfinden, was jedoch bei großen Gruppen ineffizient ist. Wichtig ist die rechtssichere Dokumentation: Wer (Name, Firma) hat wann welche Unterweisung absolviert und bis wann ist diese gültig. Das ZKS soll rechtzeitig erinnern, wenn z. B. ein Jahr vorbei ist und eine Nachunterweisung fällig wird.

• Ausweiserstellung und Berechtigungen für Fremdfirmen: Externe Mitarbeiter erhalten in der Regel personalisierte Ausweise für die Dauer ihres Einsatzes. Diese Ausweise werden ähnlich wie Mitarbeiterkarten erstellt (mit Foto und Namensaufdruck sowie Firmenname "Firma X"). Sie sind jedoch zeitlich begrenzt gültig. Das System muss automatisch das Ablaufdatum überwachen und die Karte sperren, wenn der Auftrag beendet ist oder spätestens nach Ablauf der Gültigkeit. Die Zutrittsberechtigungen werden auf die benötigten Bereiche beschränkt (Least Privilege Prinzip: z. B. Zugang nur zu bestimmten Technikräumen oder Gebäuden, in denen gearbeitet wird, evtl. nur in Begleitung je nach Regel). Ggf. erhalten Fremdfirmen-Beschäftigte auch Zufahrtsrechte (wenn sie mit eigenem Fahrzeug kommen, Kennzeichen registrieren oder temporären Parkplatz zuweisen). Das System sollte interne Verantwortliche (Auftraggeber der Fremdfirma) in den Freigabeprozess einbeziehen, so dass klar ist, welcher interne Mitarbeiter den Zutritt für welche Fremdfirmenperson genehmigt hat.

• Tagesanmeldung und Kontrolle: Wenn eine Fremdfirma mit mehreren Kräften anreist, kann am Tag selbst eine Sammelcheck-in stattfinden. Beispielsweise meldet sich der Teamleiter am Werkschutz an und die anderen werden gesammelt erfasst. Eine Schnittstelle zum Werksschutz-Leitstand oder Empfang ist daher nötig, um z. B. die tagesaktuelle Liste der erwarteten Fremdfirmen zu sehen. Das System kann z. B. Zutrittsberechtigungsausweise vordrucken basierend auf den Voranmeldungen, um sie morgens schnell aushändigen zu können. Denkbar ist auch ein Gruppen-Check-in: Der gesamte Trupp einer Fremdfirma wird in einem Rutsch eingecheckt, was das Handling erleichtert.

• Überwachung der Aufenthaltszeiten und -orte: Aus Arbeitsschutz- und Sicherheitsgründen möchte man auch bei Fremdfirmen im Blick haben, wer aktuell wo im Werk unterwegs ist. Das System protokolliert die Zutritte ohnehin; zusätzlich könnte es Warnungen geben, wenn z. B. eine Fremdfirmenperson noch im Gelände ist außerhalb der erlaubten Zeiten oder wenn jemand einen Bereich betritt, der für ihn nicht vorgesehen ist (hier eventuell Verknüpfung mit dem Alarmmodul – unautorisierter Zutritt).

• Abmeldung und Projektende: Sobald der Auftrag abgeschlossen ist, müssen alle Zutrittsmedien der Fremdfirma eingesammelt und deaktiviert werden. Das System sollte hierzu Auswertungen liefern ("Liste aller aktiven Fremdfirmen-Ausweise, sortierbar nach Gültigkeit"). Außerdem muss es unterstützen, die Zugänge nachzuverfolgen – z. B. falls eine Firma das Gelände verlassen hat, aber jemand vergessen hat auszuchecken, soll dies erkannt werden. Im Portal können projektweise Statistiken abgerufen werden: wie viele Personenstunden waren vor Ort, gab es Zwischenfälle etc.

Mit einem umfassenden Fremdfirmen-Management wird die Sicherheit und Compliance im Umgang mit externen Dienstleistern gewahrt. Risiken (wie ungeschulte Arbeiter oder unkontrollierter Zugang) werden minimiert. Gleichzeitig steigt die Effizienz, denn viel manuelle Koordination an der Pforte entfällt. Das System fügt sich in den betrieblichen Workflow ein, etwa durch Anbindung an ein Fremdfirmenportal oder an SAP-Module für Vertragsmanagement, sodass Daten nicht doppelt gepflegt werden müssen.

In vielen Unternehmen – insbesondere in der Industrie – ist die Zeiterfassung der Mitarbeiter eng mit der Zutrittskontrolle verknüpft. Oft nutzen Mitarbeiter denselben Ausweis sowohl zum Öffnen von Türen als auch zum Buchen ihrer Arbeitszeit (Kommen/Gehen). Am vorliegenden Standort ist eine Anbindung an SAP Zeitwirtschaft (SAP HCM Time Management) gewünscht, um Arbeitszeiten zentral zu erfassen.

• Zeiterfassungsterminals: An strategischen Punkten (Haupteingänge, Kantine, Umkleiden, etc.) werden Zeit-Erfassungsterminals installiert. Diese Geräte ähneln den Zutrittslesern, haben aber meist ein Display und eventuell Funktionstasten (z. B. für Kommen/Gehen, Dienstgang, etc.). Mitarbeiter halten ihren Ausweis daran, um z. B. Arbeitsbeginn und -ende zu buchen. Moderne Terminals können mehrere Modi haben (Touchscreen-Menü) oder sind integriert mit der Zutrittskontrolle. Die Terminals müssen offlinefähig sein, sodass Buchungen gepuffert werden, falls die Verbindung zum Server unterbrochen ist.

• Datenfluss zu SAP: Die erfassten Buchungen sollen nahtlos in SAP HCM (bzw. das Zeitwirtschaftsmodul) übertragen werden. Optimal ist der Einsatz einer SAP-zertifizierten Schnittstelle (HR-PDC), die sicherstellt, dass Stammdaten und Buchungsdaten korrekt synchronisiert werden. SAP wird als führendes System die Personalstammdaten bereitstellen (Mitarbeiternummer, Name, Abteilung, Sollarbeitszeitmodell etc.), während das Zutritts/Zeit-System die Ist-Zeiten sammelt. Diese Synchronisation muss regelmäßig und automatisiert erfolgen (z. B. Stammdatenabgleich mehrmals täglich oder bei Änderungen sofort), damit neue Mitarbeiter sofort buchen können und ausgeschiedene keine Buchungen mehr durchführen können (Zutrittskontrolle an SAP | PCS). Die SAP-Schnittstelle sollte bidirektional sein: z. B. können vom ZKS System Ereignisse (wie Zutrittsverletzungen) an SAP übergeben werden, falls dort eine weitere Verarbeitung (etwa Abmahnprozess) stattfinden soll; hauptsächlich jedoch fließen Zeitbuchungen an SAP und Stammdaten an das ZKS.

• Ausweis als einzigen Identifikator: Es ist darauf zu achten, dass Mitarbeiter idealerweise einen einzigen Ausweis verwenden. Doppellösungen (separate Stechuhr-Karten) sollen vermieden werden. Daher muss das System die Ausweiskarten so verwalten, dass sowohl die Zutrittsleser als auch die Zeitterminals sie erkennen. Meist wird intern ein eindeutiger Karten-ID-Code verwendet, der sowohl im Zutrittssystem als auch in SAP hinterlegt ist. Beim Onboarding eines Mitarbeiters wird die Kartennummer im SAP-Personalstamm erfasst oder via Schnittstelle vom ZKS gemeldet.

• Buchungsregeln und Plausibilitätsprüfung: Das Zeitmodul sollte grundlegende Plausibilitäten prüfen können (z. B. doppelte Kommt-Buchung verhindern, weil bereits eine kommt vorhanden, etc.) – oft übernimmt SAP diese Logik, aber das Terminal könnte Hinweise geben ("Sie haben sich schon angemeldet"). Für Sonderfälle (z. B. vergessene Buchung) braucht es organisatorische Lösungen, aber auch z. B. Korrekturbuchungen durch berechtigte Personen.

• Überstunden und Schichtbetrieb: Da auf dem Gelände Schichtbetrieb in der Produktion herrscht, muss das System Schichtwechsel reibungslos abbilden. Das bedeutet, dass um Mitternacht oder Schichtende keine ungewollten Automatismen passieren (etwa Sperren der Karte). Eventuell sollen Mitarbeiter bei Schichtende ausstempeln müssen, bevor der Ausgang öffnet – dies könnte via Workflow erzwungen werden (z. B. Tür öffnet erst, wenn eine Gehen-Buchung gemacht wurde, um Vergessen zu reduzieren). Solche Mechanismen sind jedoch sensibel und bedürfen der Abstimmung mit Betriebsrat.

• Self-Service und Auswertungen: Den Mitarbeitern könnte über Web oder Terminal ein Self-Service ermöglicht werden (z. B. Abfrage von Salden, Resturlaub, Gleitzeitkonten). Das ist eher Teil der Zeitwirtschaft (SAP ESS/MSS Module), aber das ZKS soll die nötigen Daten liefern. Vorgesetzte und HR sollen Berichte ziehen können, wer wann da war, Abwesenheiten etc., entsprechend den Zugriffsrechten. Hier greifen wiederum Datenschutz und Mitbestimmung: Keine unzulässige Überwachung, nur zulässige Auswertungen gemäß Betriebsvereinbarung.

• Gesetzliche Anforderungen (Arbeitszeitdokumentation): Durch ein Urteil des EuGH und nationale Umsetzung besteht Dokumentationspflicht der Arbeitszeiten. Das System muss daher so ausgelegt sein, dass es revisionssicher die Zeitdaten aufbewahrt (mindestens über die gesetzlich geforderten Zeiträume). Gleichzeitig sollte es flexibel genug sein, sich an ändernde Arbeitszeitmodelle anzupassen (Home-Office Regelungen, flexible Zeiten etc., wobei letztere eventuell mobil gebucht werden – siehe Mobile Credentials).

Zusammengefasst stellt das Zeitmodul sicher, dass die Zutrittskontrolle und die Arbeitszeiterfassung verknüpft sind, ohne sich gegenseitig zu behindern. Mitarbeiter profitieren von einem einheitlichen Ausweis für beide Zwecke und HR profitiert von automatisierten, genauen Zeitdaten. Wichtig ist die enge Integration mit SAP als führendem System, um Doppelpflege zu vermeiden und konsistente Daten zu haben. Dadurch kann das Unternehmen auch rechtliche Vorgaben wie die Arbeitszeitdokumentation effizient erfüllen.

Die Videoüberwachung (CCTV) ist zwar ein eigenständiges Sicherheitssystem, soll aber eng mit der Zutrittskontrolle gekoppelt werden, um ein umfassendes Lagebild zu erzeugen. An diesem Standort existieren bereits einige Kameras, vor allem an den Einfahrten. Das Lastenheft fordert eine Integration der Videoanlage in das Zutrittskontrollsystem bzw. in ein übergeordnetes Sicherheitsmanagement.

• Ereignisgesteuertes Video-Popup: Bei sicherheitsrelevanten Zutrittsereignissen soll automatisch der zugehörige Videofeed angezeigt werden. Beispielsweise versucht eine Person mit ungültigem Ausweis eine Tür zu öffnen (Zutrittsverweigerung); in diesem Moment soll im Sicherheitsleitstand automatisch die Kamera in diesem Bereich aufgeschaltet werden, damit der Wachhabende sofort sieht, was vor Ort passiert (möglicher Einbruchsversuch). Gleiches bei Alarmen: z. B. „Tür gewaltsam geöffnet“ – direkt Video einblenden. Dazu muss das Zutrittssystem die Kameras ansteuern oder einem Video-Management-System (VMS) entsprechende Trigger liefern.

• Video-Aufzeichnungen verknüpfen: Jedes Zutrittsevent (mindestens die kritischen an Außentüren und Toren) sollte mit einer kurzen Videosequenz verknüpft werden. D.h. im Log der Zutrittssoftware kann man später idealerweise einen Event anklicken („Herr X betrat um 8:05 Tor 1“) und bekommt das zugehörige Video (z. B. 10 Sekunden Clip) angezeigt. Dies erfordert, dass die Systeme zeitlich synchronisiert sind und Daten austauschen – entweder über eine Schnittstelle oder über ein integriertes PSIM (Physical Security Information Management). Die Speicherung der Videos erfolgt typischerweise im VMS/NVR (Network Video Recorder), aber das ZKS muss die Referenz darauf haben oder zumindest per Ereignis-ID ans VMS melden.

• Kamera an der Schranke: Insbesondere an den Schranken und Zufahrten ist Video hilfreich, um Fahrzeug und Fahrer zu identifizieren. Die Kameras dort können auch der Kennzeichenerkennung dienen. Das System soll so konzipiert sein, dass Kennzeichenerkennungs-Software entweder als Teil der VMS oder ZKS funktioniert und die erkannten Nummernschilder ans Zutrittssystem meldet, welches dann die Logik (öffnen oder nicht) ausführt. Einige ACS bieten modulare ANPR-Lösungen integriert, alternativ läuft es über die Videoanlage mit API zum Zutrittssystem.

• Übergeordnete Leitstandsoftware: In modernen Anlagen gibt es häufig ein Gefahrenmanagementsystem bzw. Security Management System, das verschiedene Gewerke bündelt (Zutritt, Einbruch, Video, Brand). Dieses Lastenheft fokussiert auf Zutritt, jedoch sollte das ZKS offene Schnittstellen zur Videoüberwachung bieten, z. B. OPC, ONVIF Profile C, oder proprietäre SDKs. Ziel ist eine zentralisierte Bedienoberfläche im Sicherheitszentrum, wo ein Operator z.B. eine Tür remote öffnen kann und gleichzeitig die Kamera dazu sieht. Die Interoperabilität zwischen Zutritts- und Video-System ist daher essenziell. Viele Hersteller erreichen dies durch Integrationsmodule oder gemeinsame Plattformen.

• Videoanlagen-Anforderungen: Während das Lastenheft für die Videoanlage selbst ggf. separat zu erstellen wäre, sind hier nur die Schnittstellenanforderungen relevant. Dazu gehört auch die Synchronisierung von Uhrzeit (alle Systeme an einem NTP-Zeitserver, damit Logs und Videos zeitlich passen) und ein gemeinsames Benutzerkonzept für Leitstand-Mitarbeiter (Single Sign-On in alle Sicherheitssysteme wünschenswert, z. B. via Active Directory Integration).

• Datenschutz bei Video: Das System muss DSGVO-konform betrieben werden, d.h. Kameras nur wo nötig, Kennzeichnung der überwachten Bereiche durch Schilder, begrenzte Aufbewahrungsdauer der Aufnahmen (typisch 72h bis max. 1 Woche, außer zu Ermittlungszwecken). Live-Einsicht und Auswertung von Video darf nur durch autorisiertes Personal erfolgen. Das Zutrittskontrollsystem sollte daher protokollieren, wenn jemand auf verknüpfte Videos zugreift (Nachvollziehbarkeit von "Video-Peepings" als Teil des Datenschutz-Logs). Diese organisatorischen Regelungen werden in der Datenschutz-Dokumentation festgehalten.

In Summe bietet die Video-Integration eine erhöhte Sicherheit: physische Vorfälle können schnell verifiziert werden, Falschalarme reduziert und echte Zwischenfälle mit Bildmaterial belegt. Das Zutrittssystem fungiert hier als Trigger für die Videoüberwachung. Wichtig ist, dass die Integration robust und in Echtzeit erfolgt (Latenzen könnten im Alarmfall kritisch sein). Durch Standard-Schnittstellen wie etwa ONVIF oder eine Gefahrenmanagement-Software lässt sich diese Verknüpfung erreichen. Das gesamte System wird dadurch ein vernetztes Sicherheitskonzept, in dem Zutrittssteuerung und Videoüberwachung sich gegenseitig ergänzen.

Das Industrieareal verfügt vermutlich bereits über eine Einbruchmeldeanlage (EMA) für Außenhautsicherung und ggf. über eine Brandmeldeanlage (BMA) für den Brandschutz. Die neue Zutrittskontrolllösung soll mit diesen Gefahrenmeldesystemen zusammenwirken, um Security und Safety zu vereinen.

• Arming/Disarming durch Zutritt: Die EMA sichert typischerweise außerhalb der Arbeitszeiten Türen und Bereiche durch Sensoren (Bewegungsmelder, Türkontakte). Wenn berechtigte Personen außerhalb dieser Zeiten einen Bereich betreten, muss entweder die EMA vorher unscharf geschaltet werden oder der Zutrittsversuch schlägt Alarm. Hier kann das ZKS integriert werden: bestimmte Ausweise können das Einbruchalarmsystem scharf/unscharf schalten. Zum Beispiel: Der erste Mitarbeiter, der morgens über Eingang A kommt, darf zugleich die Alarmgruppe „Büro Ost“ unscharf schalten (durch eine spezielle Leseberechtigung oder PIN-Eingabe). Das System soll entsprechende Schnittstellen zur EMA bieten – häufig sind EMA <-> Zutritt über I/O Module gekoppelt oder über serielle/IP-Protokolle je nach Hersteller. Eine tiefe Integration wäre, dass das Zutrittssystem weiß, welche Alarmbereiche gerade scharf sind und Zutritt ggf. verweigert, um Fehlalarm zu vermeiden. Realistischerweise wird aber der Alarm durch den Mitarbeiter mit einem zweiten Ausweis oder Code ausgeschaltet. In jedem Fall ist klar: Unautorisierte Zutrittsversuche in scharf geschaltete Bereiche sollen sofort einen Einbruchalarm auslösen, der an die EMA-/Leitstelle geht.

• Übernahme von Türzuständen: Viele Sensoren (Magnetkontakte) an Türen könnten sowohl vom Zutrittssystem genutzt (Tür offen/geschlossen) als auch an die EMA gemeldet werden. Um Doppelsensorik zu vermeiden, ist eine Koordination sinnvoll: entweder gemeinsame Nutzung oder zumindest Austausch der Zustandsinfos. Moderne Systeme verwenden OPC oder andere Protokolle, um solche Meldungen zentral zusammenzuführen. So kann im Leitstand auf einer Karte beispielsweise ein Türsymbol grün (zu) oder rot (offen) für beides gelten. Bei Tür-Aufbruch (Kontakt offen obwohl verriegelt) generiert das Zutrittssystem einen Sabotagealarm, den es an die EMA oder das Gefahrenmanagement weitergibt, um ggf. stillen Alarm auszulösen.

• Brandfallsteuerung (BMA-Anbindung): Im Brandfall müssen spezielle Abläufe erfolgen: Brandschutztüren, die normalerweise offen gehalten und im Zutrittssystem als Zugangspunkte zählen, schließen selbsttätig (durch BMA-Magnetabfall). Gleichzeitig müssen Notausgänge entriegelt werden. Hier ist die Anforderung, dass die BMA hart vorrangig ist – d.h. ein Feueralarm gibt direkt Steuerbefehle an Türen (über die Brandfallmatrix, i.d.R. Potentialsteuerung über Relais): Entriegeln aller Türen, die als Fluchtwege dienen. Das Zutrittssystem muss diese externen Befehle akzeptieren und darf sie nicht übersteuern. Es soll aber in der Lage sein, ein Fire Alarm Event zu registrieren, um z. B. die Zustände im System entsprechend zu markieren ("Tür X von BMA geöffnet") und nach Ende des Alarms ggf. automatisch den Normalzustand wiederherzustellen (wenn so konfiguriert). Zudem kann das ZKS einen Evakuierungsmodus unterstützen: z. B. indem es sofort die Liste aller anwesenden Personen am Sammelplatz-Terminal bereitstellt (wer hat nicht ausgecheckt?). Eine tiefergehende Integration zur BMA könnte sein, dass im System hinterlegt ist, welche Türen im Brandfall offen bleiben sollen und welche geschlossen – meist aber Aufgabe der BMA direkt.

• Gefahrenmanagement: Falls ein übergeordnetes Gefahrenmanagementsystem (GMS) vorhanden ist, werden EMA, BMA, Video und Zutritt dort integriert. Das Zutrittskontrollsystem muss hierzu eine Schnittstelle bereitstellen. In vielen Fällen wird OPC (Open Platform Communications) verwendet, ein verbreiteter Standard, um sicherheitstechnische Anlagen in Leitstellen zusammenzuführen. Darüber kann das GMS z. B. alle Türfreigaben steuern, Stati abfragen und Ereignisse erhalten. Alternativ proprietäre Protokolle je nach EMA-Hersteller oder Verwendung des Standardprotokolls nach VdS 2465 für EMA-Übergaben. Wichtig: Alle sicherheitskritischen Kommandos (wie Tür auf für Feuerwehr) müssen auch bei Integrationsausfall noch manuell möglich sein.

• Wechselseitige Verriegelungen / Schleusen: Wenn es Bereiche mit Schleusen (eine Tür erst öffnen, wenn andere zu) gibt, die auch an EMA/BMA hängen (z. B. Torschleusen am Eingang), muss das ZKS dies steuern können. Ebenfalls relevant bei Gefahr: eine Amok-Alarm-Funktion könnte definieren, dass bei bestimmten Alarmen alle Türen verriegeln (Lockdown). Solche Szenarien (in Industriebetrieben weniger üblich als in Behörden oder Schulen) sollten konfigurierbar sein.

Insgesamt stellt die EMA/BMA-Anbindung sicher, dass das Zutrittskontrollsystem nicht isoliert arbeitet, sondern Teil des ganzheitlichen Sicherheitskonzepts ist. Durch die Integration wird Security by Design umgesetzt, indem Sicherheitstechnik vernetzt und zentrale Gefahrenabwehrmechanismen berücksichtigt werden. Das System muss dabei hochzuverlässig sein – Fehler in diesen Kopplungen könnten gravierende Folgen haben (entweder Sicherheitslücken oder Behinderungen im Ernstfall). Daher werden bevorzugt ausgereifte, zertifizierte Schnittstellen genutzt und Testläufe (Szenarien wie "Alarm nachts – was passiert?") im Rahmen der Inbetriebnahme durchgeführt.

Mit fortschreitender Digitalisierung sollen moderne Zutrittskontrollsysteme auch Mobile Credentials unterstützen, d.h. die Möglichkeit, ein Smartphone als Zutrittsschlüssel zu verwenden. Dies bietet Flexibilität (kein physischer Ausweis nötig) und kann langfristig Kosten senken.

• Technologien (BLE/NFC): Mobile Zugangsberechtigungen können über NFC (Near Field Communication) oder BLE (Bluetooth Low Energy) realisiert werden. NFC ermöglicht eine ähnliche Nutzung wie klassische RFID-Karten (sehr nah ans Lesegerät halten), während BLE auch hands-free oder aus einigen Metern Entfernung funktionieren kann, je nach Implementierung. Das System sollte idealerweise beide unterstützen, um sowohl mit Android (häufig NFC) als auch iOS (Apple Wallet NFC oder proprietäre BLE Apps) kompatibel zu sein. Viele Anbieter liefern eigene Apps, die ein Soft-Token auf dem Handy speichern. Alternativ setzen sich offene Standards (z. B. BLE-Token nach OSS Standard) erst langsam durch.

• Provisionierung und Verwaltung: Das Mobile-Credential-Modul muss sicherstellen, dass nur autorisierte Geräte einen Schlüssel erhalten. Die Ausgabe eines virtuellen Schlüssels an ein Mitarbeiter-Handy erfolgt typischerweise über einen Cloud-Service des Anbieters, der eine Einladung per E-Mail oder SMS ans Gerät sendet. Der Nutzer installiert die App und erhält in dieser App – nach Authentifizierung – sein persönliches Zertifikat/Token. Das Zutrittssystem verwaltet diese Ausgabe ähnlich wie eine Kartenausgabe. Wichtig: Bei Verlust des Handys oder Ausscheiden des Mitarbeiters muss der mobile Zugang sofort widerrufen werden können. Dies geschieht durch Sperren des Credentials im System und idealerweise zieht die App oder der Cloud-Service dann das Zertifikat ein. Das ZKS sollte den Status der mobilen Ausweise in Echtzeit kennen.

• Leserkompatibilität: Bestehende Türleser müssen mobile IDs verarbeiten können. Entweder sind die Leser bereits BLE/NFC-fähig (viele moderne Leser haben z. B. Bluetooth integriert), oder sie müssen teilweise ausgetauscht/ergänzt werden. Für unser Projekt ist ein schrittweiser Übergang denkbar: klassische RFID-Karten laufen weiter, parallel werden mobile Credentials optional eingeführt. Die Software muss in der Lage sein, eine Person mit mehreren Identifikationsmedien zu führen (z. B. Max Mustermann hat eine Karte Nr. 123 und ein Handy-ID Nr. ABC, beide berechtigen gleich). Das Berechtigungssystem an sich ändert sich nicht, nur das Medium.

• Sicherheit und Datenschutz: Mobile Credentials eröffnen neue Angriffsflächen (z. B. Malware auf dem Handy, Kopierbarkeit etc.). Daher ist auf hohe Kryptographie zu achten: z.B. Verwendung von Secure Elements oder Trusted Execution Environment auf dem Phone für die Schlüsselspeicherung, Ende-zu-Ende-Verschlüsselung bei BLE (nicht nur einfache Beacon). Die Prinzipien Security by Design und Privacy by Design sind hier zentral: Das System darf z. B. nicht unnötig Standortdaten des Nutzers protokollieren, nur weil BLE genutzt wird (Datenschutz: Die App soll nicht dauernd tracken, wo sich der Mitarbeiter befindet, außer er hält ans Lesegerät). Eventuell muss eine Device Policy definiert werden: Dürfen Mitarbeiter private Handys nutzen oder werden Dienst-Smartphones gestellt? Wenn privates BYOD (Bring Your Own Device) erlaubt ist, muss eine Zustimmung der Mitarbeiter eingeholt werden, da ggf. private Geräte mit Unternehmens-Sicherheitsapp versehen werden (Betriebsvereinbarung notwendig). Technisch sollte die App so konzipiert sein, dass keine anderen Daten des Telefons abgegriffen werden (DSGVO-Konformität).

• Nutzerakzeptanz und Fallback: Nicht alle Mitarbeiter werden sofort ein Smartphone nutzen wollen oder können (etwa Produktionsarbeiter, die das Handy im Spind lassen). Daher bleiben physische Karten parallel im Einsatz. Mobile Access ist eher ein Add-on für Führungskräfte, Büroangestellte, die ihr Smartphone stets dabei haben, oder als Backup falls Karte vergessen (dann könnte man per Handy rein). Es ist zu definieren, ob z. B. nur eine der beiden Methoden aktiv sein darf oder beide gleichzeitig. In der Regel kann man beide aktiv lassen für Komfort. Für Besucher und Fremdfirmen wäre Mobile Access eher unüblich (dort bleiben temporäre Karten Standard, außer bei sehr regelmäßigen Partnerfirmen).

• Zukünftige Entwicklungen: Es zeichnet sich ab, dass Technologien wie Apple Wallet (Support von Firmenausweisen in Apple Wallet/Google Wallet) an Bedeutung gewinnen. Ein modernes System sollte daher offen für zukünftige Standards sein, um Investitionsschutz zu gewährleisten (Erweiterbarkeit). Wenn z. B. Apple ihre Schlüsselverwaltung öffnet, könnte das System via API auch so etwas unterstützen. Ein planbarer Pfad wäre die vorhandene BLE-Lösung später auf solche Standards umzustellen.

Mobile Credentials erhöhen die Flexibilität des Zutrittssystems und untermauern den innovativen Charakter (Stichwort digitale Transformation). Gleichzeitig ist deren Implementierung komplexer in Bezug auf IT (Device Management, App-Support) und erfordert hohe Sicherheitsmaßnahmen. Im Kontext dieses Lastenhefts wird mobile Access als Option eingeplant (für zukunftssicheres Design), jedoch wird der Schwerpunkt weiterhin auf bewährten physischen Ausweisen liegen, um die Robustheit des Systems nicht zu gefährden. Nichtsdestotrotz sollen die Kosten und Aufwände für die mobile Option mit betrachtet werden (siehe Wirtschaftlichkeitskapitel), um bei Bedarf eine fundierte Entscheidung treffen zu können.

Eine Besonderheit in weitläufigen Bestandsarealen ist, dass nicht jeder Zugangspunkt online verkabelt werden kann. Es gibt ggf. nebensächliche Türen, Archive, Schränke oder Außenposten, wo die Installation eines Online-Lesers unverhältnismäßig teuer oder technisch schwierig wäre. Für solche Fälle bietet das System Offline-Zylinder bzw. mechatronische Schließsysteme an, die ins Gesamtkonzept integriert sind.

• Funktion und Einschränkungen: Ein Offline-Zylinder ist ein batteriebetriebener elektronischer Schließzylinder oder Türdrücker, der im Wesentlichen wie ein normales Türschloss aussieht, aber mit einem RFID-Leser ausgestattet ist. Er ist nicht ständig mit der Zentrale vernetzt. Zutrittsrechte werden darauf übertragen, und Ereignisse werden lokal gespeichert, bis man sie ausliest. Damit ist kein Echtzeit-Zutrittsentzug möglich, solange keine Synchronisation erfolgt. Diese Einschränkungen sind zu beachten: Geht ein Ausweis verloren, muss man entweder zum Zylinder hin und ihn manuell sperren/programieren oder abwarten, bis der Ausweis seine Gültigkeit verliert (Zeitbegrenzung). Daher sollten Offline-Lösungen nur dort eingesetzt werden, wo die Sicherheitsanforderung moderat ist und wo selten Berechtigungsänderungen vorkommen.

• Programmierung und virtuelle Vernetzung: Die Verwaltung erfolgt zentral in der Software ähnlich wie bei Online-Türen, jedoch müssen Änderungen der Berechtigungen zu den Zylindern gebracht werden. Dafür gibt es zwei Konzepte: manuelle Programmierung („Schwarzes Buch“/Programmiergerät, d.h. ein Techniker geht mit einem Programmiergerät von Tür zu Tür und aktualisiert die Schließpläne – auch scherzhaft Turnschuh-Administration genannt oder virtuelle Vernetzung. Bei virtueller Vernetzung fungieren Online-Leser als Update-Station: Jedes Mal, wenn ein Benutzer seinen Ausweis an einem Online-Leser präsentiert, schreibt das System aktuelle Berechtigungen auf den Chip. Geht der Mitarbeiter dann zu einer Offline-Tür, erkennt der Zylinder, ob die Schließberechtigung (verschlüsselt auf dem Ausweis gespeichert) gültig ist, und gewährt Zutritt. Gleichzeitig kann der Zylinder seinem Teil der Daten (Türereignisse, Batteriestatus) auf den Ausweis zurückschreiben, und beim nächsten Kontakt des Ausweises mit einem Online-Leser fließen diese Informationen zurück ins System. Dieses Update-on-Card-Prinzip vermeidet, dass man jeden Zylinder manuell ansteuern muss, und spart insbesondere bei vielen verteilten Türen viel Aufwand. Das System sollte diese virtuelle Vernetzung unterstützen, da es dem Stand der Technik entspricht und herstellerübergreifend oft als "virtuelle Netzwerk" oder "Cardnet" bezeichnet wird.

• Einsatzbereiche bestimmen: Im Rahmen dieses Projekts ist festzulegen, wo Offline-Zylinder wirtschaftlich und sinnvoll sind. Typische Einsatzfälle: selten genutzte Technikräume, Außenlager, Container, Möbeltresore oder Innentüren, bei denen die Verkabelung schwierig ist (Denkmalschutz?). An stark frequentierten Zugängen sollten sie nicht eingesetzt werden, da dort der Batteriewechsel (alle 1-2 Jahre) großen Aufwand bedeutet und das Zugangsmanagement zu unflexibel wäre. Das Lastenheft geht davon aus, dass vielleicht 10-20% der Türen im gesamten System als Offline-Komponenten realisiert werden können, um Kosten zu sparen, aber die kritischen 80-90% online verkabelt werden. Diese Annahme muss in der Planung anhand konkreter Türlisten verifiziert werden.

• Kompatibilität und Standards: Offline-Schließsysteme verschiedener Hersteller sind oft proprietär, doch es gibt Initiativen wie den OSS Standard Offline (OSS-SO), bei dem mehrere Hersteller einen gemeinsamen Datenstandard nutzen. Das System sollte nach Möglichkeit OSS-kompatibel sein oder zumindest sicherstellen, dass eine Herstellerbindung vermieden wird (z. B. Auswahl eines Herstellers mit breiter Produktpalette und langfristigem Support). Wichtig ist auch, dass die Offline-Komponenten mechanisch passen (Profilzylinder nach Euro-Profil für Türen etc.) und im Bestand ohne große Umbauten eingesetzt werden können.

• Betrieb und Wartung: Batteriewechsel und Funktionsprüfungen der Offline-Zylinder müssen organisiert werden. Das System soll den Batteriestatus jedes Zylinders überwachen – sei es durch Meldung beim Update-on-Card (der Status wird über das Ausweis-Feedback ans System gemeldet oder via vereinzelter Funkverbindung (manche Offline-Zylinder können periodisch Info abgeben, wenn in Reichweite eines Hubs). Sinkt die Batterie unter einen Schwellwert, muss rechtzeitig Alarm ausgegeben werden, damit der Service die Batterie tauscht. Weiterhin sollte es Mechanismen geben für Notfallöffnung, falls ein Zylinder ausfällt oder Batterie leer ist (z. B. per Notbestromung von außen oder Notschlüssel – je nach System verschieden gelöst).

In Summe ergänzt das Offline-Modul das Zutrittskontrollsystem, indem es auch abseitige Punkte wirtschaftlich integrierbar macht. So kann ein durchgängiges Schließkonzept auf dem gesamten Gelände umgesetzt werden, ohne Inseln mit mechanischen Schlüsseln. Allerdings ist stets abzuwägen, ob der Administrationsaufwand noch vertretbar ist; bei sehr vielen Offline-Türen kann die ständige Nachpflege irgendwann teurer werden als eine Verkabelung. Daher wird eine gesunde Mischung angestrebt. Dieses Lastenheft verlangt vom Anbieter, entsprechende Konzepte und Erfahrungswerte einzubringen, um die optimale Aufteilung von Online- und Offline-Lösungen zu finden.

Ein zentrales Merkmal des geforderten Zutrittskontrollsystems ist seine Integrationsfähigkeit. Es darf nicht als Insellösung konzipiert sein, sondern muss sich in die bestehende IT- und Systemlandschaft einbetten.

• SAP-Anbindung: Wie bereits betont, ist die Verbindung zu SAP HCM und ggf. weiteren SAP-Modulen essentiell. Die Mitarbeiter-Stammdaten (Personalnummer, Name, Abteilung, Status) sollen aus SAP übernommen werden, sodass neue Mitarbeiter automatisch im Zutrittssystem angelegt werden können (automatisierte Zuweisung von Zutrittsrechten beim Onboarding ist als Workflow-Ziel genannt. Umgekehrt können Zutrittsereignisse (z. B. Kommen/Gehen-Buchungen für die Zeiterfassung) zurück an SAP gemeldet werden. Die Schnittstelle sollte SAP-zertifiziert und updatefähig sein (Stichwort S/4HANA-Kompatibilität). Technisch setzt man entweder auf das klassische HR-PDC (eine IDoc/Batch-Schnittstelle) oder moderne Webservice-APIs, falls verfügbar. Neben HCM könnte auch SAP Identity Management (falls vorhanden) ein Koppelungspunkt sein, um digitale Identitäten konsistent zu verwalten. Auch SAP Visitor Management existiert in Ansätzen – hier ist zu prüfen, ob das genutzt wird oder durch die eigene Besuchersoftware ersetzt (wahrscheinlich letzteres, da Excel bisher genutzt wurde).

• Verzeichnisdienste (AD/LDAP): Für die Administration des Systems und ggf. für Single Sign-On könnte das ZKS an Microsoft Active Directory (AD) oder LDAP angebunden werden. Beispielsweise damit Admin-Berechtigungen an Benutzerkonten gekoppelt sind, oder um Personaländerungen mitzutracken. Auch können Karten-IDs im AD hinterlegt werden, um PC-Login via Badging zu ermöglichen, wenn dies gewünscht ist (Randnotiz). AD/LDAP-Schnittstelle ist kein Muss, aber ein Plus an Integration.

• Fremdfirmen- und Besucherportale: Sollte der Betreiber bereits separate Portallösungen für Besucherregistrierung oder Fremdfirmenmanagement haben (z. B. ein Contractor Management System in der HSE-Abteilung), so muss das Zutrittssystem hierzu kompatibel sein. Beispielsweise könnte ein Fremdfirmenportal (wie in EHS-Software Quentic o.ä.) die Schulungen managen und dann via API dem Zutrittssystem melden "Person X hat Schulung bestanden, darf Zutritt erhalten". Oder ein Besuchervoranmeldesystem aus dem Unternehmensintranet speist die Daten ins ZKS, um Doppelarbeit zu sparen. Daher sind offene Programmierschnittstellen (REST API, SOAP, o. ä.) gefordert, mit denen man externe Systeme anbindet. Diese sollten dokumentiert und möglichst standardisiert sein, um zukünftige Integrationen zu erleichtern.

• Video, EMA, BMA, Leitstand: Wie im jeweiligen Abschnitt erläutert, sind Schnittstellen zu Videoüberwachungssystemen, zur Einbruch-/Brandmeldeanlage und zum zentralen Gefahrenmanagement vorzusehen. Gewünscht ist eine bidirektionale Kommunikation: Zutritt liefert Events an den Leitstand (z. B. Türzustände, Alarme) und empfängt umgekehrt Befehle (Tür öffnen, Alarm setzen/entsetzen). Dazu eignet sich z. B. ein OPC UA Server im ZKS, der von der Leitstandsoftware ausgelesen/gesteuert wird. Auch HTTP-basierte Schnittstellen können zum Einsatz kommen (manche Systeme bieten REST/JSON APIs). Wichtig ist, dass keine proprietäre Black Box entsteht, sondern dass der Auftragnehmer verpflichtet wird, die Schnittstellenfunktionalität offen zu legen und mitzuliefern.

• Zeitwirtschaft extern: Falls neben SAP weitere Zeitsysteme existieren (z. B. eine Payroll-Software, Schichtplanungstools), könnte auch dorthin eine Verbindung nötig sein. Tendenziell läuft aber alles über SAP, sodass keine doppelte Anbindung nötig wird.

• Physische Peripherie: Integration bedeutet auch, die bestehende Hardware weitestmöglich weiterzuverwenden. Das könnte betreffen: elektronische Türschlösser oder Motoren, die evtl. schon an einigen Türen montiert sind; Verkabelungskanäle oder Leerrohre; bestehende Drehkreuze oder Schranken (die Mechanik kann bleiben, nur die Steuerung wird neu angebunden). Auch Ausweisdrucker am Empfang (für Besucherkarten) sollten integriert werden, ebenso evtl. vorhandene Key-Management-Automaten (Schlüsselausgabe-Systeme) sofern vorhanden. Letzteres: Sollte es im Werk einen Schlüsselausgabe-Automaten geben (für Fahrzeugschlüssel oder Werkzeuge), könnte man diesen ans ZKS anbinden, sodass nur Berechtigte ein Fach öffnen können und das Ereignis im Zutrittsprotokoll mitgeführt wird. Das Lastenheft hält fest, dass derartige Integrationen (auch wenn optional) vom System grundsätzlich unterstützt werden müssen.

• IT-Infrastruktur: Das Zutrittskontrollsystem muss in die bestehende IT-Landschaft integriert werden im Sinne von Netzwerk und Servern. Es wird gefordert, dass das System auf aktueller Standard-Hardware oder virtuellen Maschinen laufen kann, kompatibel zu gängigen Betriebssystemen und Datenbanksystemen. Eine Datenbankschnittstelle (z. B. ODBC/SQL) zur internen Verwendung kann hilfreich sein, um eigene Auswertungen zu fahren. Zudem soll die Netzwerkkommunikation der Komponenten IT-sicher sein (VLAN-Abtrennung für Security-Systeme, Verschlüsselung, Zertifikatsmanagement). Die Systemintegration umfasst daher auch Zusammenarbeit mit der IT-Abteilung, um z. B. Firewall-Regeln, Portfreigaben und Sicherheitsupdates zu koordinieren.

• Zukünftige Erweiterungen: Das System soll so ausgelegt sein, dass auch künftige Module integrierbar sind. Beispielsweise eine Aufzugsteuerung (Zutrittssystem steuert, welche Stockwerke im Fahrstuhl freigeschaltet werden für welchen Ausweis), eine Spindsteuerung (Mitarbeiter öffnen persönliche Schließfächer mit dem Ausweis oder die Anbindung von Mustering-Systemen für Evakuierung. Das Lastenheft erwartet vom Bieter eine Beschreibung, wie sein System erweitert werden kann – sei es durch standardisierte Module oder durch Customizing. Entscheidend ist, dass offene Architekturen bevorzugt werden, die Interoperabilität erlauben.

Abschließend ist festzuhalten, dass die Integrationsfähigkeit ein Schlüsselkriterium dieses Lastenhefts darstellt. Ein Zutrittskontrollsystem entfaltet den maximalen Nutzen, wenn es Daten mit anderen Systemen austauschen kann und in die betrieblichen Workflows eingebettet ist. Dadurch entsteht ein intelligentes Gebäudesicherheitssystem, das weit über das bloße Öffnen von Türen hinausgeht. Risiken bei der Integration (Inkompatibilitäten, hohe Anpassungsaufwände) sind möglichst durch die Wahl etablierter Standards und modularer Schnittstellen zu minimieren.

In diesem Kapitel wird die praktische Integration aller Systeme – bestehende Hardware, Software und Infrastruktur – näher beleuchtet und es werden realistische Aufwandsschätzungen für die Umsetzung angegeben. Dies ermöglicht, den Implementierungsumfang besser abzuschätzen und in eine Projektkalkulation zu überführen.

Das Industrieareal ist ein Bestandsobjekt, sodass bereits vielfältige Hardware installiert ist: Türanlagen, Drehkreuze, Schranken, Verkabelung, Serverräume, etc. Die neue Zutrittslösung soll so weit wie möglich darauf aufbauen, um Investitionsschutz zu gewährleisten.

• Tür-und Tor-Hardware: Viele Türen besitzen bereits elektrische Türöffner oder motorische Verriegelungen (z. B. Motorschlösser, Türschließer mit Feststellanlage in Labs, Fluchttür-Terminals). Diese Komponenten können oft weitergenutzt werden, indem man sie an die neuen Zutrittscontroller anklemmt. Aufwandsschätzung: Die Anpassung pro Tür, falls Verkabelung vorhanden, ist gering (ca. 1–2 h pro Tür für Umbau und Test). Bei Türen ohne Verkabelung muss hingegen Kabel gezogen oder auf Funklösungen ausgewichen werden – dort steigt der Aufwand (8+ Stunden pro Tür inkl. baulicher Maßnahmen). Insgesamt ist im Werk mit geschätzt 50–100 Türen zu rechnen, die zu integrieren sind. Die vorhandenen Schrankenanlagen haben Motoren und Induktionsschleifen, die ebenfalls übernommen werden können – hier ist v.a. eine neue Steuerlogik (Controller + Leser/Kamera) zu installieren. Aufwand: pro Tor etwa 1–2 PT (Personentage) für Installation und Inbetriebnahme, da hier auch Tiefbau (Kabelschacht für Bodenschleifen, Montage des LKW-Terminals) berücksichtigt werden muss.

• Bestehende Ausweistechnologie: Falls im Alt-System bereits Ausweise im Umlauf sind, stellt sich die Frage, ob diese übernommen werden können. Beispiel: Mitarbeiter haben Karten mit 125kHz-Technologie (unsicher, veraltet) – hier würde man eher auf neue DESFire EV2 o.ä. umstellen. Wenn es jedoch schon MIFARE DESFire gibt, könnte man dieselben Karten weiterverwenden und nur umcodieren. Aufwand: Bei Wechsel der Kartentechnologie müssen neue Ausweise ausgegeben werden, was logistisch (Foto, Druck, Verteilung) ca. 10 min pro Mitarbeiter bedeuten kann. Bei z.B. 500 Mitarbeitern wären das 500*10 min = ~83 Stunden = rund 10 PT rein für Ausweistausch-Aktion (über einige Tage verteilt). Dafür involviert man idealerweise die Personalabteilung. Technisch muss das neue System beide Technologien parallel lesen können während der Übergangsphase (daher Leser dual einsetzen). Dieser Migrationsaufwand sollte im Projektplan berücksichtigt werden.

• Netzwerk und Verkabelung: Da es sich um einen Bestandsstandort handelt, gibt es ein bestehendes Firmennetzwerk. Typischerweise wird ein dediziertes Security-VLAN eingerichtet, in das alle Zutrittscontroller, Kameras etc. kommen. Die Abstimmung mit der IT (IP-Adressierung, Switch-Ports) erfordert ca. 1 PT Planungsaufwand und während der Installation nochmal Support (ggf. gemeinsam Tests mit IT, Firewall-Regeln setzen). Wenn LWL-Verbindungen zwischen Gebäuden existieren, kann man diese nutzen; falls Lücken bestehen, müssen evtl. Funkstrecken oder neue Kabel gezogen werden. Pro neu zu verkabelndem Weg können mehrere Tausend Euro Material/Arbeitskosten anfallen – daher große Wichtigkeit der Bestandsaufnahme vorab. Aufwandsrahmen: Für die IT-Integration und Verkabelungsplanung kalkuliert man ca. 15 PT (inkl. eines detailierten Infrastrukturplans, Patchfeld-Planung, USV-Einbindung etc.). Die physische Kabelzugarbeit hängt stark vom örtlichen Aufwand ab (kann in die Ausschreibung separat in Leistungspositionen gefasst werden).

• Server-Hardware: Es wird ein zentrales Serversystem benötigt, auf dem die ZKS-Software läuft. Idealerweise wird hierfür eine virtuelle Maschine auf vorhandener VM-Infrastruktur genutzt, was Hardware-Kosten spart. Abstimmung: 0,5 PT für Koordination mit IT (welches OS, welche DB, Backup-Konzept). Installation der Software durch den Anbieter: ~1 PT. Hochverfügbarkeitskonzepte (Cluster, Redundanzserver) erhöhen Aufwand, könnten aber angesichts der sicherheitskritischen Natur sinnvoll sein (Kalkulationsposten optional vorsehen).

• Re-Use vs. Neukauf: Generell rechnet man damit, dass mechanische Komponenten (Schrankenbäume, Türblätter, Riegel) bleiben, aber die Elektronik (Leser, Controller) weitgehend neu kommt. Dennoch lohnt eine Prüfung vorhandener Komponenten: z. B. sind eventuell schon Türkontakte eingebaut, dann braucht man keine neuen. Oder vorhandene Brandmeldeanlage-Meldungen können genutzt werden – das spart Sensoren. Dieser Prüfschritt (Bestandsaufnahme aller Türen/Tore) ist meist Teil der Planungsphase, wofür man ~5 PT (eine Woche) ansetzt.

Summiert man obige Schätzungen für Hardwareintegration, kommt man überschlägig auf z. B. 100 Türen * 2h + 3 Tore * 16h + 10 PT Verkabelung/IT + 5 PT Bestandsanalyse + Puffer = ~40–50 PT Installations-/Integrationsaufwand nur für Hardware. Genaue Werte hängen aber stark von der örtlichen Situation ab.

• SAP-Integration Aufwand: Viele Anbieter haben Standard-Connectoren zu SAP. Dennoch muss die Abstimmung der Datenfelder (welche Felder in SAP entsprechen welchen Rechten im Zutrittssystem) erfolgen. Dazu Workshops mit HR: ~2 PT. Einrichtung der Schnittstelle am System: ~3 PT (Installation, Konfiguration, Mapping). Tests und Fehlerbehebung: ~3 PT. Summe ca. 8 PT. Falls unerwartete Abweichungen (z. B. kundenspezifische Infotypen in SAP) kommen, etwas mehr. Dieser Aufwand lohnt sich, weil danach vieles automatisch läuft.

• Datenmigration Altsystem: Wenn vom alten Zutrittssystem Daten übernommen werden sollen (z. B. bestehende Zutrittsprofile oder Ausweiskarten), muss man Migrationsskripte schreiben. Je nach Kompatibilität Aufwand 2–5 PT. Ggfs. auch manuelle Übernahme, wenn Alt nicht digital exportierbar (dann eher in Personalzeitaufwand, Zuarbeit vom Kunden).

• Besucher-/Fremdfirmen-Portal: Falls neu eingeführt innerhalb des Systems, ist es Standardteil der Software (Konfiguration ~2 PT für Layouts, Formulare, E-Mail-Templates). Falls Anbindung an vorhandenes Portal nötig, muss ein individuelles Interface programmiert werden (z. B. Webservice zwischen Quentic und ZKS) – da können leicht 5–10 PT an Softwareentwicklung einfließen. Das Lastenheft legt deshalb nahe, möglichst einen Anbieter zu wählen, der ein integriertes Besuchermanagementmodul schon mitliefert, um Schnittstellenaufwand zu sparen.

• Video-/EMA-Anbindung: Die Koppelung an das Videosystem kann je nach Kompatibilität von "Plug&Play" (wenn gleiche Hersteller-Plattform) bis "großes Integrationsprojekt" variieren. Planwert: 5 PT für Einrichten der Schnittstelle, Mappen der Kamera-IDs zu Türen, Testing. EMA: wahrscheinlich viel über I/O, d.h. Hardware-Einrichtung (im obigen Hardwareaufwand enthalten). Sollte ein Software-Gateway nötig sein, ~3 PT. BMA: typischerweise nur Relaisansteuerung, was in Hardware beinhaltet ist, plus 1 PT Test mit Brandschutzbeauftragten für Schleifen und Auslösung.

• Weitere Integrationen: AD-Anbindung (falls gemacht): 1 PT. OPC to Leitstand: 2 PT.

In der Summe könnten für Softwareseitige Integration und Customizing etwa 20–30 Personentage veranschlagt werden. Dies schließt auch Konfigurationen wie Berechtigungsprofile, Zeitmodelle etc. mit ein, die man zusammen mit dem Kunden erarbeitet.

• Komponententest: Jede installierte Komponente (Leser, Tür, Schranke) wird einzeln getestet (Funktionstest, Öffnen/schließen, Alarmierung). Zeitbedarf: ca. 0,5–1h pro Tür, 1–2h pro Schranke mit allen Szenarien. Bei ~100 Türen und 3 Schranken -> ~60–120h, entsprechend 8–15 PT nur für Komponentenabnahme vor Ort.

• Integrationstest: Danach Test der zusammenspielenden Funktionen: z. B. Mitarbeiter anlegen in SAP -> kommt an Zutritt an? Besuchereinladung -> Code funktioniert an Schranke? Alarm -> poppt Video auf? Diese End-to-End-Tests erfordern diverse Szenarien, Testnutzer etc. Hierfür sind mind. 5 PT einzuplanen (mit Beteiligung aller Stakeholder: IT, Security, HR, etc.).

• Pilotbetrieb: Es ist sinnvoll, einen Pilotbereich vor vollständigem Rollout zu machen. Z.B. erst nur eine Eingangspforte und ein Gebäude mit einigen Nutzern testen, bevor das ganze Werk umgestellt wird. Pilotphase: 2–4 Wochen. Aufwand für Betreuung: 3–5 PT (Anpassungen, Bugfixing, Feinjustierung Parameter). In dieser Phase wird eventuell parallel das Altsystem noch genutzt – Übergangsregelungen müssen gemanagt werden.

• Abnahme und Abstellmaßnahmen: Nach erfolgreichem Gesamttest erfolgt die formale Abnahme. Eventuell verbleiben Restleistungen (Punch-List: kleine Nachbesserungen), die noch erledigt werden (1–2 PT). Dann Übergabe an Betrieb.

Insgesamt könnte man für Tests/Inbetriebnahme ca. 20 PT kalkulieren, was im Verhältnis zur Implementierung durchaus üblich ist (ca. 20–30% der Gesamtaufwände). Gerade weil ein fehlerhaftes System im Live-Betrieb hohe Risiken birgt (Zutritt verwehrt oder unkontrolliert gewährt), ist hier nicht zu sparen.

Basierend auf obigen Teilbetrachtungen liegt der Gesamtaufwand (Planung, Installation, Konfiguration, Test, Schulung) schnell im Bereich mehrerer Personenmonate. Überschlägig aus Hardware (50 PT), Software (25 PT), Tests (20 PT) summiert ~95 PT für den Anbieter plus noch interner Aufwand (Mitarbeiter für Abstimmungen, Datenbereitstellung, Schulungen).

• Planung und Feinentwurf (inkl. Bestandsanalyse, Abstimmung Lasten-/Pflichtenheft): ~1–2 Monate.

• Installation Hardware (kann gestaffelt pro Bereich erfolgen): ~3–6 Monate je nach Personalstärke und baulichen Gegebenheiten.

• Konfiguration/Customizing parallel: ~1–2 Monate.

• Inbetriebnahme/Test/Pilot: ~1–2 Monate.

• Schulung und Übergabe: am Ende der Inbetriebnahmephase (s. organisatorischer Teil) etwa innerhalb 1 Monats.

Insgesamt ergibt sich eine Projektdauer von ungefähr 6–9 Monaten vom Auftrag bis zum vollständigen Betrieb, wobei Puffer für unvorhergesehene Hindernisse einzukalkulieren sind. Bei straffer Koordination und wenn wenig Baumaßnahmen erforderlich sind, wäre evtl. 6 Monate machbar; realistischer sind eher 9 Monate, insbesondere weil z. B. Betriebsferien oder Sicherheitsprüfungen in den Zeitplan mit einzurechnen sind.

Diese Aufwandsschätzungen sind als Richtschnur zu verstehen. Sie beruhen auf Annahmen über die Größenordnung (z. B. ~100 Türen) – sollten es deutlich mehr oder weniger Türen sein, skaliert der Aufwand entsprechend linear mit. Eine genaue Mengenermittlung (Stückliste aller Komponenten) wird Teil des Pflichtenhefts bzw. der Angebotsphase sein. Hier wurden bewusst konservative Ansätze gewählt, um sicherzugehen, dass genug Ressourcen eingeplant werden und das Projekt ohne Qualitätseinbußen abgeschlossen werden kann.

Neben der technischen Umsetzung sind die organisatorischen Rahmenbedingungen für ein erfolgreiches Zutrittskontrollsystem entscheidend. Dieses Kapitel behandelt die Anforderungen an den laufenden Betrieb, die Schulung der Beteiligten, Verantwortlichkeiten und Regelungen im Umgang mit dem System, Datenschutzbelange sowie Notfall- und Ausnahmeprozeduren. Ein tragfähiges Betreiberkonzept stellt sicher, dass das System nicht nur technisch, sondern auch organisatorisch effektiv und rechtlich einwandfrei funktioniert.

• Systemverantwortung: Es ist festzulegen, welche Abteilung die Hauptverantwortung für das ZKS trägt. Oft liegt sie beim Werkschutz/Sicherheitsdienst oder in Kooperation zwischen der IT-Abteilung (für Server/Software) und der Facility Management/Werksicherheit (für physische Komponenten). Im vorliegenden Fall empfiehlt sich ein gemeinsames Betreiberteam: Die IT verantwortet Serversystem, Software-Updates, Datensicherung; die Sicherheitsabteilung verantwortet die operationelle Nutzung (Vergabe von Berechtigungen, Reaktion auf Alarme, Wartung der Türhardware). Dies sollte in einer schriftlichen Betriebsrichtlinie festgehalten werden.

• Security-Admin: Mitarbeiter der Sicherheit, die Ausweise erstellen/löschen, Zutrittsprofile verwalten und Auswertungen vornehmen.

• IT-Admin: zur Betreuung der technischen Komponenten, z.B. Nutzerverwaltung im System, Einstellungen der Schnittstellen, Problembehebung bei Kommunikationsstörungen.

• Helpdesk/Operative Nutzer: z.B. Empfangspersonal, das Besucher eincheckt (eingeschränkte Rechte nur im Besuchermodul), oder Schichtleiter, die Zeiten korrigieren dürfen.

Diese Rollen und ihre Berechtigungen im System müssen gemäß Minimalprinzip konfiguriert werden (kein Admin hat mehr Rechte als nötig, um Missbrauch zu vermeiden).

• Betriebszeiten und Monitoring: Da das Werk vermutlich 24/7 in Betrieb ist, muss auch das ZKS rund um die Uhr laufen. Es sollte definiert sein, ob stets jemand im Leitstand sitzt (Werkschutz 24h) – in vielen Industriebetrieben ist eine 24/7-Besetzung vorhanden, die auch die Alarme des Systems im Blick hat. Das System sollte über eine Monitoring-Funktion verfügen (Herzschlag der Controller, Systemmeldungen), die entweder im Leitstand sichtbar ist oder an einen IT-Monitoring (SNMP Traps etc.) angeschlossen wird, sodass Störungen sofort bemerkt und gemeldet werden. Reaktionszeiten z.B.: Bei einem kompletten Systemausfall (kein Zutritt möglich) muss binnen z.B. 1 Stunde ein Admin vor Ort sein (siehe SLA im Wartungsvertrag).

• Wartung und Inspektion: Organisatorisch muss geklärt sein, wer regelmäßige Wartungsaufgaben übernimmt. Dazu zählt: jährliche Prüfung aller Notfallöffnungen und Türfunktionen (ggf. nach DIN 31051 bzw. entsprechend VdS-Empfehlungen für Sicherheitstechnik). Ein externer Serviceanbieter kann im Rahmen eines Wartungsvertrags diese Aufgabe wahrnehmen, oder interne Techniker, sofern ausgebildet. Wichtig: Die Kosten dafür sind im TCO kalkuliert (siehe Wirtschaftlichkeit). Im Betriebskonzept soll festgehalten sein, dass z.B. zweimal jährlich ein Funktionstest aller sicherheitsrelevanten Funktionen durchgeführt wird (inkl. Alarmanbindungen, Akkupuffer etc.).

• Änderungsmanagement: Das Zutrittssystem wird sich über die Jahre ändern (neue Türen, geänderte Zutrittsbereiche, neue Mitarbeiterprofile). Es braucht einen Prozess, wie Änderungen beantragt und umgesetzt werden. Z.B.: eine Fachabteilung will, dass Mitarbeiter X zusätzlich ins Labor darf -> schriftlicher Antrag an Sicherheitsabteilung -> Freigabe durch zuständigen Manager -> Umsetzung im System durch Security-Admin. Solche Workflows können teils im System unterstützt werden (digitale Anträge) oder als Organisationsanweisung festgelegt sein. Ein Berechtigungskonzept sollte erstellt werden, das genau dokumentiert, wer welche Zugangsrechte haben darf und wer darüber entscheidet (Vier-Augen-Prinzip bei sensiblen Bereichen etc.). Dieses Konzept hilft auch beim Audit (z. B. ISO 27001 fordert dokumentierte Zugriffsrechte-Vergabe).

• Dokumentation im Betrieb: Alle relevanten Unterlagen (Schaltpläne, Türlisten, Parameterlisten, Software-Dokumentation) müssen aktuell gehalten und für den Betrieb verfügbar sein. Bei Systemübergabe sollte der Anbieter ein vollständiges Dokumentationspaket liefern. Im Laufe des Betriebs ist es ratsam, ein Änderungslogbuch zu führen, wann welche Komponente getauscht oder welcher Softwarestand eingespielt wurde. Ebenso soll jeder sicherheitsrelevante Vorfall dokumentiert werden (z. B. "22.07.: Tür 17 war defekt, manuell offen gehalten von 10-12 Uhr zur Reparatur, protokolliert durch Sicherheitsdienst").

Die Schulung aller beteiligten Personen ist ein kritischer Erfolgsfaktor, um das System fachgerecht zu bedienen und zu warten.

• Administratoren-Schulung (Intensiv): Die Haupt-Administratoren (Security-Admins und IT-Admins, insgesamt voraussichtlich 3–5 Personen) benötigen eine ausführliche Schulung durch den Systemanbieter. Diese Schulung sollte vor Ort nach Installation durchgeführt werden und alle Module abdecken: Bedienung der Software (Benutzeranlage, Rechtevergabe, Monitoren von Alarmen), Konfiguration (wie neue Türen anlegen, wie Schnittstellen bedienen), Reportingfunktionen, Backup-Wiederherstellung, etc. Umfang: je nach Systemkomplexität ca. 3–5 Tage intensives Training. Alternativ könnten Security und IT getrennte Schwerpunkte erhalten (z. B. 3 Tage Bedienung für Security, 2 Tage Technik für IT). Wichtig ist, dass hinterher ein sicheres Wissen vorhanden ist, da das System über Jahre betrieben wird. Im Angebot sollte diese Schulung inkl. Unterlagen (Benutzerhandbücher, evtl. Video-Tutorials) enthalten sein.

• Benutzerschulung (Endanwender): Die Endnutzer des Systems im weiteren Sinne sind alle Mitarbeiter, da sie mit den Ausweisen und Terminals umgehen müssen. Hier braucht es keine Schulung im klassischen Sinne, aber eine Unterweisung/Information: z. B. per E-Mail-Rundschreiben oder Betriebsversammlung wird erklärt, wie das neue System funktioniert, was zu beachten ist (z. B. Ausweis nicht verleihen, Verluste melden, beim Durchgang durch Drehsperren nur eine Person pro Karte etc.). Insbesondere Besucheranmelder (diejenigen, die im Voraus Gäste einladen) und Fremdfirmen-Betreuer sollten in kleinen Workshops eingeführt werden, wie sie das neue Web-Portal nutzen. Dies kann intern durch die geschulten Admins weitergegeben werden (Train-the-Trainer-Prinzip). Aufwand: ca. 0,5 PT Vorbereitung Infomaterial, 1 PT Durchführung kurzer Sessions mit Sekretariat/Empfangspersonal etc.

• Wach- und Empfangspersonal: Die Sicherheitsmitarbeiter, die im Leitstand sitzen oder an den Toren Dienst tun, benötigen ebenfalls gezielte Einweisung. Sie müssen z. B. wissen, wie man im System einen Alarm quittiert, wie man im Notfall eine Tür ferngesteuert öffnet (oder verriegelt), wie man Besucherausweise druckt etc. Diese Zielgruppe ist evtl. 24/7 in Schichten aktiv, daher muss die Schulung so geplant werden, dass alle Schichten abgedeckt sind (mehrere Termine oder Multiplikatoren). Umfang: 1–2 Tage Training, eventuell aufgeteilt in 2-h-Module je Schicht.

• Techniker/Wartungsschulung: Falls interne Haustechnik kleinere Wartungen übernimmt (z. B. Batteriewechsel an Offline-Zylindern, Justage von Türkontakten), sollten diese Mitarbeiter vom Errichter eingewiesen werden. Das kann im Zuge der Abnahme erfolgen: z. B. zeigt der Techniker dem Haustechniker, wie ein Zylinder gewechselt wird, oder wie man einen Leser tauscht. Dokumentation dazu (Servicehandbuch) ist mitzugeben. Hier reichen meist ein paar Stunden praktische Demonstration vor Ort.

• Schulung neuer Mitarbeiter: Organisatorisch ist festzulegen, wie neu eintretende Mitarbeiter mit dem System vertraut gemacht werden. In der Onboarding-Checkliste sollte stehen: Übergabe Ausweis und kurze Erklärung. Ggf. erstellt man ein kurzes Merkblatt oder ein Intranet-Video "So benutzen Sie Ihren neuen Firmenausweis". Dies fällt in den Regelbetrieb (Aufwand per Einzelfall minimal, aber in Summe relevant).

• Wiederholung und Updates: Bei größeren Software-Updates (Upgrades) in der Zukunft muss evtl. eine Nachschulung erfolgen, wenn sich Bedienung oder Funktionen ändern. Dies sollte Teil des Wartungsvertrags sein, dass der Anbieter z. B. bei Versionwechsel eine Schulungseinheit für Admins anbietet. Zudem jährliche Notfallübungen (z. B. Evakuierung simulieren) können gleich genutzt werden, um den Umgang mit dem System in Stresssituationen zu trainieren (etwa wer drückt den "Evakuierungsknopf" und wer checkt die Sammelplatz-Liste).

In der Kalkulation sollte für Schulungen ein Aufwand von ca. 5–7 PT für den Anbieter eingeplant werden (Vorbereitung und Durchführung). Betrieblich sollten auch interne Ressourcen für Schulungen reserviert werden (z. B. Admins nehmen sich Zeit, Kollegen einzuweisen). Ein gut geschultes Team garantiert, dass das System sicher bedient wird und Benutzerfehler (z. B. falsche Rechtevergabe) minimiert werden. Damit trägt Schulung wesentlich zum Erfolg und zur Sicherheit-by-Design bei – denn auch der Mensch als Faktor muss "mitdesignt" werden.

• Dateneigentümer und Datenschutz: Laut DSGVO und guter Governance muss ein Verantwortlicher für personenbezogene Daten benannt sein. Da das ZKS zahlreiche personenbezogene Daten verarbeitet (Mitarbeiter- und Besucherdaten, Zutrittsprotokolle), sollte der Datenschutzbeauftragte des Unternehmens eingebunden sein. Er überwacht, dass die Datennutzung nur im erlaubten Rahmen erfolgt und z. B. Löschfristen eingehalten werden. Der Datenverarbeitungsprozess ist in einem Verzeichnis zu dokumentieren. Formal bleibt das Unternehmen (vertreten durch Geschäftsführung) Verantwortlicher im Sinne DSGVO; operativ kann die Sicherheitsabteilung als Process Owner bestimmt werden.

• Rollen und Zugriffsrechte intern: Es braucht klare Regeln, wer welche Auswertungen fahren darf. Beispielsweise darf der Werkschutz-Leiter Einsicht in Zutrittslogs nehmen, um Sicherheitsvorfälle zu untersuchen; die Personalabteilung darf auf Arbeitszeitbuchungen zugreifen, aber nicht unbedingt auf Zutrittswege; der Vorgesetzte eines Mitarbeiters darf i.d.R. nicht routinemäßig sehen, wann dieser gekommen und gegangen ist (Überwachungsverbot, es sei denn im Rahmen berechtigter Interessen und vereinbart mit Betriebsrat). Diese Grenzen müssen in Betriebsvereinbarungen festgelegt sein (siehe Mitbestimmung).

• Betriebsvereinbarungen und Mitbestimmung: In Deutschland unterliegen Systeme der Mitarbeiterkontrolle der Mitbestimmung durch den Betriebsrat. Für Zutritt, Video und Zeitwirtschaft sind meist separate Betriebsvereinbarungen (BV) oder eine kombinierte BV zu schließen. Das Lastenheft schreibt vor, dass alle Funktionen so ausgelegt sein müssen, dass sie im Rahmen dieser Vereinbarungen betrieben werden können. Übliche Inhalte einer BV Zutritt/Zeit: Zweck des Systems (Zutrittskontrolle, nicht Verhaltenskontrolle), keine Auswertung individueller Bewegungsprofile außer bei konkretem Verdacht und mit Zustimmung Betriebsrat, Protokolllöschung nach X Monaten, Zugriffsrechte nur eng definierte Personen. Das System muss technisch ermöglichen, diese Vorgaben umzusetzen (z. B. Löschkonzepte, Audit-Trail wer Daten angesehen hat. In der Verantwortlichkeitsmatrix sollte stehen: Betriebsrat hat ein Mitbestimmungsrecht bei Änderungen am System, sprich bei Erweiterungen oder neuen Auswertungsarten ist er frühzeitig einzubeziehen.

• Verantwortung für technische Sicherheit: Wer ist dafür verantwortlich, dass das System sicher konfiguriert ist (z. B. keine offenen Standardpasswörter auf den Controllern)? Meist die IT-Security in Zusammenarbeit mit dem Anbieter. Themen wie Patch-Management (regelmäßige Updates einspielen) und Schwachstellen-Management gehören hierzu. Wenn das System auf Windows-Server läuft, muss klar sein, wer die Windows-Updates einspielt (IT) und dass der Anbieter die eigene Software zeitnah kompatibel hält. Diese Verantwortlichkeiten sollten in einem Betriebskonzept dokumentiert werden. Ggf. orientiert man sich an ISO 27001, wo genau solche Zuständigkeiten für Systeme definiert sein sollen.

• Aufgabentrennung: Ein Prinzip in sicherheitsrelevanten Prozessen ist die Trennung von Aufgaben, um Missbrauch zu vermeiden (Vier-Augen-Prinzip). Z.B. sollten Personen, die Zutrittsberechtigungen vergeben, nicht die gleichen sein, die logs manipulieren könnten. Oder die Bestellung neuer Ausweise erfordert Genehmigung durch Vorgesetzten. Im Alltag kann man das pragmatisch halten, aber für hochsichere Zonen ist es ratsam, mehrere Personen im Prozess zu haben. Das Konzept sollte daher z.B. definieren, dass die Vergabe von Masterkarten (Generalschlüssel-Karten) nur mit zwei Personen zusammen erfolgt, etc.

• Notfall-Verantwortlichkeiten: In Notfällen (Brand, Amok, IT-Ausfall) ist vorab zu regeln, wer Entscheidungen trifft. Beispiel: Bei einem Cyber-Angriff auf das ZKS, wer hat die Kompetenz, das System vom Netz zu trennen? Bei Ausfall, wer initiiert Notöffnung der Türen? Diese Szenarien gehören ins Notfallkonzept (siehe dort), aber hier wird festgelegt, wer jeweils der verantwortliche Entscheider ist (im Brandfall meistens Einsatzleiter Feuerwehr in Absprache mit Werkleitung; im IT-Fall der CISO oder IT-Leiter etc.).

Das Betreiberkonzept und die Verantwortlichkeitsregeln sollten schriftlich fixiert und allen Beteiligten bekannt gemacht werden. Sie bilden den organisatorischen Unterbau für den Systembetrieb. Nur wenn alle wissen, wer was darf und soll, kann das Zusammenspiel funktionieren – Technik allein genügt nicht. Daher ist ein Kickoff mit allen Stakeholdern sinnvoll, um diese Punkte abzustimmen, idealerweise vor der Inbetriebnahme, damit ab Tag X klare Verhältnisse herrschen.

Datenschutz ist bei Zutrittskontrollsystemen ein zentrales Thema, da personenbezogene Daten verarbeitet werden (Name, Zutrittszeiten, Bewegungsprofile).

• Datensparsamkeit und -zweckbindung: Das System soll nur solche personenbezogenen Daten erheben, die für den definierten Zweck notwendig sind (Privacy by Design). Das bedeutet z. B., es müssen nicht zwingend Privatadressen der Mitarbeiter im Zutrittssystem stehen – es reicht die Personalnummer und Name. Besucherdaten sollen auf den Zweck "Zutrittsverwaltung" beschränkt bleiben; eine Nutzung der Daten für Marketing oder andere Zwecke ist ausgeschlossen. Im System sollten Felder, die nicht benötigt werden, deaktivierbar sein, um gar keine Versuchung aufkommen zu lassen, mehr zu erfassen als nötig.

• Einwilligung oder Rechtsgrundlage: Für Mitarbeiterzugang gilt in der Regel das berechtigte Interesse des Arbeitgebers an der Sicherheit als Rechtsgrundlage, ergänzt durch die Betriebsvereinbarung (die quasi eine Einwilligung der Belegschaftsvertretung darstellt). Für Besucher und Fremdfirmen muss spätestens beim Check-in eine Datenschutzinformation erfolgen (z. B. als Text am Terminal oder auf Papier zum Unterschreiben), die darüber aufklärt, welche Daten wofür gespeichert werden. Das System sollte die Möglichkeit bieten, diese Einwilligung zu dokumentieren (z. B. digital signiert vom Besucher am Tablet).

• Logging und Zugriffsschutz: Alle Zugriffe auf personenbezogene Daten im System müssen protokolliert werden (wer hat wann welches Datensatz eingesehen/bearbeitet), damit ein Audit-Trail entsteht. Dies schützt vor internem Missbrauch und ist in der DSGVO Teil von Art. 5 (Integrität, Vertraulichkeit). Außerdem muss das System selbst gegen Unbefugte geschützt sein: Administrationszugänge nur mit starken Passwörtern, idealerweise 2-Faktor-Authentifizierung für Administratoren, Session-Timeouts, Verschlüsselung der Datenbank etc. Das Konzept Security by Design greift hier: z. B. sollten personenbezogene Daten bei der Übertragung verschlüsselt sein, und in der Datenbank sollten kritische Daten (Passwörter, biometrische Daten falls gespeichert) nur gehasht oder verschlüsselt liegen.

• Aufbewahrungsfristen: Gemäß DSGVO dürfen personenbezogene Daten nicht länger als nötig aufbewahrt werden.

• Zutrittsprotokolle (Log der Türöffnungen) sollten nach einer definierten Frist automatisch anonymisiert oder gelöscht werden, sofern kein Sicherheitsvorfall die längere Aufbewahrung rechtfertigt. In vielen BVs sind z. B. 3 Monate festgelegt, maximal 6 Monate.

• Besucherdaten können kürzer gehalten werden (vielleicht 1 Monat), da ihr Zweck nach dem Besuch entfällt.

• Mitarbeiterstammdaten werden bei Ausscheiden des Mitarbeiters entfernt bzw. inaktiv gesetzt; eventuell bleiben Name und Personalnr. noch in historischen Logs stehen, aber das kann man anonymisieren (statt Name nur "Mitarbeiter ID12345 ausgeschieden").

Das System muss konfigurierbare Löschfristen unterstützen und idealerweise automatisieren (Auto-Delete routines). Wenn das nicht verfügbar ist, muss ein Admin definiert regelmäßig alte Daten entfernen – das wäre fehleranfällig, daher besser technische Unterstützung.

• Betroffenenrechte: DSGVO fordert, dass betroffene Personen Auskunft über ihre gespeicherten Daten erhalten können und ggf. Berichtigung oder Löschung verlangen dürfen. Für Mitarbeiter wird das über den Arbeitgeber laufen (Betriebsrat etc.), aber technisch muss es möglich sein, z. B. alle Zutrittszeiten von Person X rauszusuchen, falls ein Auskunftsersuchen kommt. Das System sollte entsprechende Exportfunktionen haben, um Daten pro Person zusammenzustellen. Löschverlangen von Mitarbeitern sind tricky, da der Arbeitgeber gewisse Daten behalten darf (z. B. um Fehlzeiten nachzuweisen). In der BV wird meist geregelt, dass die Daten zur Zutrittskontrolle nicht zur Leistungs- oder Verhaltenskontrolle genutzt werden, somit erledigen sich häufig Individualbegehren – aber man muss vorbereitet sein.

• ISO 27001 / IT-Grundschutz: Als Teil der Unternehmens-IT sollte das Zutrittssystem ins Informationssicherheits-Managementsystem (ISMS) eingebunden sein. ISO 27001 fordert physische Zugangssicherheit (Kontrollmaßnahmen z. B. in Annex A.11 Physical Security) – das System adressiert das direkt. Gleichzeitig muss das System selbst sicher betrieben werden (Annex A.13 Kommunikation – Verschlüsselung, A.12 Betriebssicherheit – Backup etc.). Es sollte also regelmäßige Backups der Konfiguration und Datenbank geben, die sicher gespeichert werden. Ebenso müssen Notfallpläne existieren (die auch Teil der ISO-Dokumentation sind), wie der Betrieb weitergeht, wenn das System ausfällt (Manual Override, siehe Notfallkonzepte). Das Zutrittssystem kann ISO-27001-Konformität unterstützen, etwa indem es eine klare Liste liefert, wer Zugang zu welchen Bereichen hat (was der Normpunkt A.11.2.1 "Physical entry controls" verlangt). Im Idealfall wird das System jährlich im Rahmen interner/externer Audits geprüft – d.h. der Betreiber muss Nachweise liefern können, dass das System gem. Richtlinien betrieben wird (Up-to-date, keine unkontrollierten Adminaccounts, etc.).

• Weitere Compliance: Je nach Branche könnten noch weitere Vorschriften greifen, z. B. Betriebssicherheitsverordnung (BetrSichV) hinsichtlich elektrischer Schlösser an Türen: eine Gefährdungsbeurteilung muss die Schließanlagen betrachten (Thema im rechtlichen Teil). Oder DGUV Vorschrift 17/18 für Veranstaltungsstätten, falls Besucherbereiche vorhanden. Das System muss so betrieben werden, dass es diesen Vorschriften entspricht – meist durch organisatorische Maßnahmen (z. B. Unterweisungspflichten, die wir ja erfüllen über das System, oder die Sicherstellung, dass Notausgänge bei Stromausfall aufgehen). Insofern hat das System auch eine Compliance-Funktion: es hilft, gesetzliche Pflichten nachweisbar zu erfüllen (z. B. lückenlose Zeiterfassung nach ArbZG oder lückenlose Unterweisung nach ArbSchG). Die entsprechenden Reports (Wer hat Unterweisung X gemacht? Wer war wie lange auf dem Gelände?) sollten im Bedarfsfall abrufbar sein, um Behörden oder Auditoren gegenüber Nachweise zu haben.

Zusammengefasst muss der Betrieb unter Datenschutz- und Compliance-Aspekten transparent, kontrollierbar und regelkonform sein. Das Lastenheft verlangt, dass der Anbieter Funktionen bereitstellt, die diese Anforderungen unterstützen (Löschkonzepte, Protokollierung von Administratoraktionen, Rollenberechtigungen, etc.). Die Einhaltung der DSGVO ist nicht verhandelbar – sie ist gesetzlicher Rahmen. Ebenso ist die Orientierung an ISO 27001 empfohlen, da viele Mutterunternehmen oder Kunden dies fordern; das Zutrittssystem sollte daher als asset im ISMS betrachtet werden, mit Risikoanalyse und entsprechenden Maßnahmen (physische und cyber Sicherheit). Security und Privacy by Design bedeutet hier, dass schon in der Konzeptionsphase all diese Punkte bedacht und implementiert werden, nicht erst im Nachhinein.

Trotz aller sorgfältigen Planung muss man auf Notfälle und Störungen vorbereitet sein.

• Systemausfall (IT-Notfall): Was passiert, wenn die Zutrittskontroll-Server oder die Vernetzung ausfällt? Das Konzept sieht vor, dass die Türcontroller autonom weiterarbeiten (eine Zeit lang) – dies muss getestet sein. Dennoch, wenn der Ausfall länger als X Stunden dauert, gibt es einen Notfallmodus: Entweder man schaltet Türen auf dauerhaft offen (falls Sicherheitslage es zulässt) oder man geht auf mechanische Schließung über (z. B. Wachdienst postiert an wichtigen Toren und verteilt mechanische Generalschlüssel aus einem Not-Tresor). Solche physischen Backups (Schlüsseldepots) sind i.d.R. vorhanden und sollen weiterhin vorgehalten werden. Das Notfallhandbuch sollte genaue Anweisungen enthalten: z. B. "Bei Totalausfall ZKS benachrichtige IT-Leiter und Werkschutzleiter; öffne Schlüsseltresor XY (Code bekannt); informiere Bereichsleiter, dass Zutritt manuell kontrolliert wird, etc.".

• Stromausfall: Ein Spezialfall des Systemausfalls – hier greifen USV (Unterbrechungsfreie Stromversorgung) für Server und evtl. zentrale Komponenten. Aber lange Blackouts (>30min) werden USVen nicht überbrücken. Daher: alle sicherheitsrelevanten Türen sind entweder mechanisch begehbar oder haben Batteriepuffer (z.B. die Drehkreuze könnten manuell entsperrt werden). Im Notfallplan definieren: "Bei Stromausfall länger 10 min – Sicherheitszentrale besetzt Eingänge manuell" etc. Auch die Alarmanlage/Notbeleuchtung etc. spielt rein, aber das geht ins Gebäude-Notfallmanagement über. Wichtig: Nach Wiederkehr der Spannung startet das System automatisch neu und synchronisiert.

• Brandfall/Evakuierung: Hier überschneidet sich mit BMA-Integration: Das Notfallkonzept Brand muss sicherstellen, dass alle Personen das Gebäude verlassen können. Also Türen auf, Drehkreuze entriegeln (oder Sonder-Fluchtdurchgang bereitstellen). Danach am Sammelplatz wird anhand der Anwesenheitsliste aus dem System geprüft, wer vermisst wird. Das erfordert, dass idealerweise ein Evakuierungsreport mit einem Klick generierbar ist, der bspw. zeigt: "Noch im Gebäude angemeldet: 3 Personen, Namen ..." (sofern sie nicht durch Notausgang entkommen sind – 100% genau geht’s nicht ohne Auslese am Sammelpunkt). Notfalls müssen Bereichsleiter wissen, wen sie erwarten, aber das System hilft zumindest mit Daten. All das gehört in die Brandschutzordnung integriert. Übungen (Feueralarm-Drills) sollten auch das ACS einbeziehen.

• Amok-Alarm und Lockdown: In der heutigen Zeit wird auch das Szenario eines aktiven Gewalttäters (“Amoklauf”) mitbedacht. Das Zutrittssystem sollte in ein entsprechendes Notfallkonzept eingebunden sein. Beispielsweise könnte ein Amok-Alarm (durch manuelle Panikknöpfe oder aus dem Leitstand ausgelöst) das System veranlassen, sensible Bereiche sofort zu verriegeln (um einen Täter einzuschließen oder zu verlangsamen) und gleichzeitig den Zugang für Unbeteiligte zu blockieren. Alternativ kann es Fälle geben, in denen man alle Türen entriegelt, damit Personen fliehen können – dieses Vorgehen ist sorgfältig mit Sicherheitsbehörden abzustimmen. In jedem Fall muss klar sein, wer in solch einer Ausnahmesituation Entscheidungen trifft und Befehle gibt. Das System sollte technisch ermöglichen, entweder zentral einen “Lockdown” Modus zu aktivieren (d.h. alle oder definierte Türen sofort schließen oder öffnen). Diese Funktion muss gegen Missbrauch geschützt sein (z. B. nur im Leitstand möglich, unter best. Bedingungen). Auch eine stille Alarmierung an die Polizei kann integriert sein (Panikknopf an der Pforte, der nach außen meldet, ohne intern Alarm auszulösen). Organisatorisch sind regelmäßige Übungen angeraten, um die Abläufe im Ernstfall zu proben.

• Sabotage und Cyber-Angriffe: Als “Worst-Case” gilt, wenn ein Angreifer gezielt das Zutrittssystem manipuliert (physisch oder IT-seitig). Vorbeugend sind daher Hardening-Maßnahmen (gehärtete Controller, Zugriffsschutz, keine offenen Schnittstellen ohne Authentifizierung) umzusetzen. Im Notfallkonzept sollte stehen: Wenn ein Cyber-Angriff vermutet wird (z. B. systematische Fehlbuchungen oder Fehlalarme), ist das System vom Netzwerk zu trennen und in einen sicheren Zustand zu versetzen (z. B. alle Türen verriegeln und manuell überwachen). Das erfordert enge Zusammenarbeit zwischen IT-Security und physischer Security. Auch Sabotage an Hardware (abgeschnittene Kabel, zerstörte Leser) muss erkannt (z. B. Sabotagekontakte am Gehäuse) und behandelt werden: etwa indem sofort der Wachdienst den betreffenden Eingang inspiziert, während andere Zugänge höher alarmiert werden.

• Kommunikation im Notfall: Teil des Notfallkonzepts ist auch, wie die Information verbreitet wird. Wenn das System ausfällt oder in speziellen Alarmmodus geht, müssen die Mitarbeiter informiert werden (z. B. Durchsagen oder Alarmierungssystem). Für externe Helfer (Feuerwehr, Polizei) ist vorab zu klären, wie sie ins Gelände kommen, falls das System versagt – z. B. Hinterlegung von Feuerwehrschlüsseln in Tresoren mit Feuerwehrschließung (FSD – Feuerwehr-Schlüsseldepot) an den Toren.

Alle diese Szenarien sollten in einem Notfallhandbuch dokumentiert sein, das sowohl technische Maßnahmen (Systemkonfiguration für Notfälle) als auch organisatorische Schritte enthält. Wichtig ist, dass Mitarbeiter geschult sind und wissen, wie sie sich verhalten sollen, denn die beste technische Vorbereitung nützt wenig, wenn im Ernstfall Unsicherheit herrscht. Durch regelmäßige Überprüfung und Aktualisierung der Notfallkonzepte (mind. jährlich) wird sichergestellt, dass das Zutrittssystem auch in Ausnahmesituationen seinen Beitrag zur Sicherheit leistet.

Die Gesamtkosten eines Zutrittskontrollsystems setzen sich aus Investitionskosten (CAPEX) und laufenden Betriebskosten (OPEX) zusammen. Für die 10-Jahres-Betrachtung werden folgende Posten berücksichtigt:

• Hardware: Leser, Türcontroller, Schließzylinder, Verkabelungsmaterial, Serverhardware, Netzwerkkomponenten, Terminals (z. B. LKW-Säulen, Kiosks). Für unser Areal mit ca. 100 Online-Zutrittspunkten, 50 Offline-Zylindern, 3 Schrankenanlagen und zugehörigen Komponenten lässt sich ein Mengengerüst aufstellen. Typische Einzelpreise (Schätzwerte): Ein Standard-Kartenleser ~300–500 €, ein Türcontroller (für 2–4 Türen) ~800–1200 €, ein Funkzylinder ~300 €, ein Schranken-Terminal (Kamera, Säule) mehrere Tausend Euro. Insgesamt könnte man initial für Hardware im niedrigen sechsstelligen Euro-Bereich rechnen. (Diese Zahl variiert je nach Anbieter und gewählter Technologie – das Lastenheft bleibt bewusst produktneutral, daher werden keine festen Preise genannt.)

• Software-Lizenzen: ZKS-Server-Software, Module (Besuchermanagement, Video-Integration, SAP-Schnittstelle etc.). Oft werden diese nach Anzahl Türen oder Ausweise lizenziert. Angenommen 100 Türen = 100 Lizenzpunkte, plus Module, könnte die Softwarelizenz initial z. B. 50.000–100.000 € ausmachen. Bei Cloud-Modellen entfallen hohe Initialkosten, dafür gibt es laufende Gebühren (siehe unten).

• Implementierung: Planung, Installation, Konfiguration, Datenmigration – im obigen Kapitel wurden rund 95 Personentage Aufwand für den Anbieter geschätzt. Bei einem Tagessatz (inkl. Reisekosten) von grob 1000 € wären das ~95.000 € Dienstleistungskosten. In der Praxis wird der Errichter/Integrator ein Gesamtangebot machen, in dem Hardware, Software und Dienstleistungen gebündelt sind.

• Schulungskosten: Oft Teil des Implementierungsangebots, aber hier hervorzuheben: Die Schulungen (Admins, Benutzer) sind Teil der Investition in die Betriebsfähigkeit. Diese Kosten (vielleicht 5–10 k€ in Form von Kursen/Workshops) zahlen sich durch weniger Fehler und effizientere Bedienung aus.

• Wartungsvertrag: Es ist üblich, einen Wartungs- und Servicevertrag mit dem Anbieter abzuschließen. Dieser deckt Software-Updates, telefonischen Support und vielleicht ein Kontingent an Vor-Ort-Einsätzen ab. Häufig wird er als Prozent des Auftragsvolumens berechnet (z. B. 10–15% der Investitionssumme pro Jahr). In unserem Fall könnte das z. B. 20.000 € pro Jahr sein. Über 10 Jahre summiert sich das auf 200.000 €, wobei darin auch Upgrades auf neue Softwareversionen enthalten sein sollten – was wichtig für Investitionsschutz ist.

• Instandhaltung: Austausch von Verschleißteilen, Batterien in Offline-Zylindern (ca. alle 2–3 Jahre, Batteriekosten und Arbeitszeit einrechnen), ggf. Leser, die nach 8–10 Jahren defekt gehen. Hier kann man einen Pauschalansatz pro Jahr nehmen (z. B. 2% der Hardwarekosten als Abschreibung pro Jahr zurücklegen). Für 100.000 € Hardware wären das 2.000 € p.a. rein an Materialersatz. Komplexere Teile wie Schranken haben eigene Wartungsintervalle (Schrankenantriebe müssen alle paar Jahre justiert, Federn getauscht werden – meist vom Spezialfirma).

• Betriebspersonal: Der tägliche Betrieb verursacht interne Kosten: z. B. Zeit des Sicherheitsdienstes, der z. T. ohnehin da ist; ein Administrator, der vielleicht 0,2 VZÄ (Vollzeitäquivalent) seiner Arbeitszeit der Pflege des Systems widmet (Ausweismanagement, Rechteupdates, Reporting). Diese Personalkosten (die trotzdem anfallen, ob neues System oder altes) sollte man berücksichtigen: 0,2 VZÄ eines Mitarbeiters mit z. B. 60 k€/Jahr = 12.000 € pro Jahr. Über 10 Jahre 120.000 €. Allerdings bringt das System Effizienzgewinne, die anderswo Personalkosten sparen (z. B. weniger manuelle Besucherabfertigung, weniger Wachdienst an Schranken). Diese Einsparungen können gegen gerechnet werden.

• Sonstiges: Energiekosten für die Geräte (vernachlässigbar gering, Leser und Controller verbrauchen sehr wenig Strom), Netzanbindung (vorausgesetzt Firmennetz vorhanden), eventuelle Gebühren für Cloud-Dienste (wenn z. B. Mobile Credential Service jährlich kostet pro Nutzer, oder Kennzeichenerkennungssoftware Lizenz pro Jahr).

• Initial: Hardware+Software 250 k€, Dienstleistungen 100 k€ = 350 k€ Startinvest.

• Laufend: Wartung+Support 20 k€/Jahr, Ersatzteile 2 k€/J, Personal 12 k€/J = ~34 k€/Jahr.

• Über 10 Jahre Laufend: 340 k€.

• Gesamt 10 Jahre: 690 k€.

Daraus ergibt sich ein durchschnittlicher Jahresaufwand von ~69 k€, wobei erfahrungsgemäß in Jahr 1 der Peak (Installation) ist, dann flacht es auf die genannten ~34 k€ jährlich ab. Diese Beispielzahlen müssen natürlich projektspezifisch validiert werden. Dennoch verdeutlichen sie: Die laufenden Kosten übersteigen oft die initiale Investition im Lauf der Zeit, was die Bedeutung eines guten Lifecycle-Managements zeigt.

Ein wichtiger Aspekt für die Wirtschaftlichkeit ist der Investitionsschutz – das System soll auch in mehreren Jahren technisch aktuell und erweiterbar sein, damit die getätigten Investitionen nicht vorzeitig entwertet werden.

• Modularität und Skalierbarkeit: Die ausgewählte Lösung soll so modular sein, dass zukünftige Erweiterungen (z. B. ein neues Gebäude, zusätzliche Türen oder Funktionen) ohne Systemwechsel integriert werden können. Dies war bereits eine Grundforderung im funktionalen Teil. Investitionsschutz bedeutet hier: Heute angeschaffte Module bleiben kompatibel. Beispiel: neue Leser sind rückwärtskompatibel zu alten Controller, Software-Updates unterstützen alte Hardware weiter (zumindest für einen gewissen Zeitraum). Idealerweise committen sich Hersteller zu Supportzyklen von 10+ Jahren für ihre Produkte (insbes. Hardware). Das verhindert, dass z. B. Offline-Zylinder nach 5 Jahren nicht mehr hergestellt werden und man alles tauschen muss.

• Upgrade-Fähigkeit: Die Software sollte regelmäßige Upgrades erfahren (Sicherheitsupdates, neue Features). Wichtig ist, dass diese Upgrades im Wartungsvertrag enthalten sind – es wäre unwirtschaftlich, wenn man nach 5 Jahren eine komplett neue Softwarelizenz kaufen müsste. Upgrades können aber Aufwände erzeugen (Test neuer Version, evtl. Datenbankmigration). Daher plant man vielleicht alle 2–3 Jahre ein größeres Software-Upgrade ein (Aufwand 2–3 PT Test+Durchführung). In 10 Jahren also 3–4 Upgrades. Das Systemdesign (z. B. Virtualisierung) erleichtert Upgrades, weil man Snapshots und Testinstanzen nutzen kann.

• Lifecycle der Ausweise: Investitionsschutz betrifft auch die Ausweismedien. Wenn z. B. jetzt auf eine sichere RFID-Technologie gewechselt wird, sollte diese mindestens 10 Jahre Markterhältlich sein. Kartendefekte treten auf (ca. 2–5% der Karten pro Jahr müssen ersetzt werden), aber der Bulk der Karten sollte nicht abrupt obsolet werden. Deshalb eher Standard-Technologien (MIFARE DESFire evtl. oder LEGIC advant etc.) als Exoten. Auch bei Mobile Credentials: ein offener Standard (wie BLE oder FIDO) bietet mehr Investitionsschutz als eine proprietäre Lösung, die in 3 Jahren evtl. vom Markt verschwindet.

• Dokumentation und Know-how: Ein oft übersehener Punkt des Investitionsschutzes ist die Verfügbarkeit von Wissen. Wenn das System gut dokumentiert ist und mehrere Personen geschult sind, ist man weniger abhängig von Einzelpersonen (Bus-Faktor) oder vom Lieferanten. Sollte z. B. der Dienstleister in einigen Jahren nicht mehr verfügbar sein, muss die Doku ausreichen, dass ein anderer übernehmen kann. Das ist gerade in Langfristperspektive wichtig – daher vertraglich festhalten, dass eine umfassende Dokumentation geliefert wird, die Eigentum des Betreibers ist.

• Technologiebeobachtung: Im Lifecycle-Management soll das Unternehmen auch die technologische Entwicklung verfolgen. Zum Investitionsschutz gehört nämlich auch zu wissen, wann eine Erneuerung sinnvoll wird. Z. B. könnten in 8–10 Jahren völlig neue Authentifizierungstechniken verfügbar sein. Ein radikaler Techniksprung könnte ein Reinvest rechtfertigen (was aber über TCO-Plan hinausgeht). Daher Teil des Managements: regelmäßig bewerten, ob das System noch State-of-the-Art und sicher ist (z. B. wenn bis 2030 Quantencomputer RSA brechen könnten, müssten evtl. neue Karten mit Quantum-safe Crypto eingeführt werden – das nur als Gedankenexperiment).

Zusammengefasst soll die Ausschreibung sicherstellen, dass die Lösung langfristig tragfähig ist. Hersteller, die nur proprietäre und kurzlebige Produkte anbieten, werden hier Nachteile haben. Besser sind Lösungen, die auf Standards setzen (z. B. OSDP bei Lesern, OSS-SO bei Zylindern, etablierte Schnittstellen), weil diese auch von Drittherstellern im Zweifel unterstützt werden könnten. Investitionsschutz ist auch ein Teil des Risikomanagements – man will vermeiden, in wenigen Jahren erneut hohe Investitionen tätigen zu müssen, weil man in eine Sackgasse geraten ist.

• Regelwartung und Service Level: Im Vertrag sollte ein Service-Level-Agreement (SLA) definiert sein: z. B. Reaktionszeit 4 h bei kritischer Störung (Türe lässt sich nicht schließen), 24 h bei mittlerer (einzelner Leser defekt, aber redundant zugänglich), etc.. Auch Verfügbarkeitsziele können festgelegt werden (z. B. System 99,5% im Jahr verfügbar). Die Wartung umfasst auch präventive Maßnahmen: jährlicher Check der Anlagen vor Ort, Firmwareupdates für Controller einspielen, Prüfung der USV-Batterien, etc. Mit einem guten Wartungskonzept bleibt das System stabil und Ausfälle werden minimiert. Es ist sinnvoll, dem Dienstleister KPIs vorzugeben (Key Performance Indicators wie mittlere Reparaturdauer), um die Qualität messbar zu halten.

• Betriebsmodell: Cloud vs. On-Premises: Heutzutage bieten manche Hersteller Zutrittskontrolle als Cloud-Service an.

• Cloud-Modell: Die Software läuft in der Cloud des Anbieters oder eines Rechenzentrums, der Betreiber muss keine Server stellen. Vorteile: Weniger eigene IT-Wartung, Updates werden vom Anbieter automatisch eingespielt, meist hohe Verfügbarkeit garantiert. Kosten sind OPEX (Mietmodell, monatliche Gebühr pro Tür/Nutzer). Nachteile: Abhängigkeit von Internet und Anbieter, evtl. Datenschutzbedenken (personenbezogene Daten außer Haus, erfordert Auftragsverarbeitungsvertrag nach DSGVO), mögliche Einschränkungen bei individueller Anpassung.

• On-Premises: Klassisch lokale Installation im Firmennetz. Vorteile: Volle Kontrolle über Daten, Integration in lokale Systeme (z. B. direkter DB-Zugriff), keine laufenden Mietkosten außer Wartung. Nachteile: eigene IT-Infrastruktur muss betrieben werden, Verantwortung für Updates teils beim Betreiber, evtl. höhere Anfangsinvestition.

Für ein sicherheitskritisches Industrieareal tendiert man oft zu On-Prem (auch weil eine Offline-Fähigkeit bei Cloud stets das Risiko Verbindungsverlust birgt – wobei gute Cloud-Lösungen auch lokale Gateways nutzen). Eine Hybridlösung wäre denkbar: z. B. Besucherregistrierung in der Cloud, Kern-Zutrittssteuerung lokal. In der 10-Jahres-Kostenbetrachtung muss man Cloud-Gebühren vs. Abschreibung abwägen. Das Lastenheft sollte beide Konzepte zulassen, aber hohe Anforderungen an Verfügbarkeit und Datenschutz stellen, so dass ein Cloud-Anbieter diese erfüllen muss (z. B. Rechenzentrum zertifiziert, Datenhaltung in EU, VPN-Anbindung ans Werk für Ausfallsicherheit etc.).

• Erweiterbarkeit und Upgrade-Pfade: Im Laufe der Nutzungszeit könnte das System erweitert werden. Erweiterungen können horizontal (mehr vom Gleichen, z. B. neues Lagergebäude mit 20 Türen hinzufügen) oder vertikal (neue Module/Funktionen hinzufügen, z. B. Handvenenscanner für Hochsicherheit, oder Integration von Kantinenabrechnung auf dem Ausweis) sein. Das Lastenheft fordert die Bieter auf, solche Erweiterungsmöglichkeiten darzustellen und ggf. preislich zu indizieren (z. B. Einheitspreise für zusätzliche Türen, Tagessatz für Implementierung neuer Module). So kann das Unternehmen die Skalierungskosten abschätzen. Ein gutes System wird mit minimalem Mehraufwand erweiterbar sein (Plug-and-Play neuer Controller, Freischalten von Softwaremodulen ohne Neuinstallation). Beispiel Mengengerüst: Typischerweise kann man pro 100 Türen einen weiteren Server nötig haben (falls Performancegrenzen), aber die meisten Systeme schaffen auch 1000 Türen pro Server. Wichtig ist auch die Lizenzpolitik: Man sollte möglichst “auf Vorrat” kaufen können (z. B. Lizenzen für 150 Türen, nutzt aber erst 100), damit man nicht bei jeder Erweiterung in Nachverhandlungen muss. Oder ein transparenter Preis pro Tür, der schon im Vertrag fixiert ist (Investitionsschutz gegen Preissprünge).

• Betriebsmodelle (intern/extern): Das Unternehmen muss entscheiden, ob der Betrieb intern gestemmt wird oder teilweise outgesourct. Beispielsweise könnte man den 24/7-Leitstand an einen externen Sicherheitsdienst vergeben, oder die IT-Betrieb des Servers an einen Cloud/Managed Service. Das Lastenheft sollte diese Optionen nicht vorwegnehmen, aber so schreiben, dass sowohl interne als auch externe Operatoren damit arbeiten können. Aus wirtschaftlicher Sicht ist Outsourcing oft eine Kostenfrage vs. Qualität: Externe haben Routine und Tools, kosten aber laufend Gewinnaufschläge; interne kennen das Werk besser, sind aber evtl. nicht 24/7 verfügbar ohne Schichtbetrieb. Hier kann modular entschieden werden (z. B. Werkschutz intern, aber Systemwartung extern). Für die Kalkulation empfiehlt es sich, Vergleichsangebote intern vs. extern einzuholen, gerade im Kontext Cloud vs. on-prem.

• Gerätebedarf pro Zutrittspunkt: Pro typische Tür benötigt man 1 Leser außen (optional 1 innen für Auslasskontrolle oder Anti-Passback), 1 Türcontroller-Port, 1 Elektroschloss (sofern nicht vorhanden), 1 Türkontakt, Verkabelung. Kosten: Leser ~400 €, Controller-Port umgelegt ~300 €, Schloss+Kontakt ~200 €, Kabel+Montage ~300 € => grob ~1.200 € pro Tür in Hardware+Montage. Bei motorisierten Türen oder Schleusen höher. Drehsperren kosten mehr (ein Drehkreuz kann 5–10 k€ kosten). Schranken inkl. Steuerung und Long-Range-Leser/Kamera können 10–20 k€ pro Einfahrt liegen. Diese Zahlen dienen als Hausnummern zur Budgetierung.

• Softwarelizenzen pro Modul: Einige Anbieter lizenzieren Besuchermanagement separat (vielleicht 5–10k), Zeiterfassungsschnittstelle separat (~5k), Video-Integration modulweise (~5k). Genaue Kosten variieren extrem, aber man sollte im Hinterkopf haben, dass jedes Zusatzmodul einen Mehrpreis bedeutet, der in der Bewertung berücksichtigt werden muss.

• Schulungsaufwand: Wie oben beschrieben, initial ~1 Woche für Admins, plus interne Einweisungen. Zusätzlich kann man ansetzen: bei Personalwechsel oder Wachstum braucht es Nachschulungen (Budget dafür vorsehen, z. B. 2 PT pro Jahr für Schulung neuer Admins/Nutzer).

• Betriebsaufwand: Falls interne Stellen geschaffen/umgewidmet werden müssen (z. B. ein Zutrittsmanager 50% Stelle), sollte man diese Personalkosten anteilig mitrechnen, aber sie könnten durch Wegfall anderer Tätigkeiten kompensiert werden (etwa weniger manuelle Wachen).

• Cloud vs. Lokal Kostenvergleich: Ein Rechenbeispiel: On-Prem hat Anfangsinvestition für Server ~10 k€ plus Software ~50 k€, Cloud hätte keine Serverkosten, aber Software ggf. als Subscription: z. B. 1 € pro Mitarbeiter pro Monat oder 10 € pro Tür pro Monat. Bei 500 Mitarbeiter wären das 500 € mtl. = 6.000 € p.a., auf 10 Jahre 60 k€ – das klingt wenig, aber oft kommen Basiskosten und Module dazu. Es kann durchaus 15–20 k€ p.a. sein, also über 10 Jahre 150–200 k€, was ähnlich dem On-Prem (wo man Wartung zahlt) ist. Cloud rechnet sich, wenn man interne IT-Kosten reduziert und schnell skalieren will; on-prem rechnet sich, wenn man bereits Infrastruktur hat und datenschutzkonforme Eigenlösung bevorzugt. Diese Abwägung sollte in der Entscheidungsfindung mit Zahlen untermauert werden.

• Kosten-Nutzen-Betrachtung: Über die reinen Kosten hinaus sollte man qualitative Nutzen in Wert fassen: z. B. vermiedene Verluste durch unbefugten Zutritt (die sind schwer zu beziffern, aber ein Sicherheitsvorfall kann sehr teuer werden), Effizienzgewinne (Weniger Zeit am Empfang – rechnerisch: wenn Empfang je Besucher 5 Min spart, bei 5.000 Besuchern/Jahr sind das ~400 Stunden, was x Euro entspricht). Ein weiterer Aspekt: die Einhaltung von Gesetzen (z. B. Arbeitszeiterfassungspflicht) schützt vor rechtlichen Risiken (Stichwort: DSGVO-Strafen oder Bußgelder ArbZG). Solche „Kosten“ werden oft nicht direkt gesehen, aber ein Verstoß könnte erheblich teurer werden als das System. So gesehen trägt das System zur Wertschöpfung bei, indem es Risiken senkt (Versicherungstechnisch evtl. auch relevant: gut gesicherte Werke zahlen niedrigere Prämien).

Insgesamt soll dieser wirtschaftliche Abschnitt Entscheidern ermöglichen, die Investition zu rechtfertigen und Budgets einzuplanen. Ein gut kalkuliertes Lastenheft zeigt Transparenz in den Kosten und Signal an die Anbieter, dass eine sorgfältige Kostenplanung erwartet wird. Das schließt ein, dass Bieter vielleicht Alternativen aufzeigen können (z. B. Mietmodell oder Leasing der Anlage statt Kauf), was im Verhandlungsverfahren geprüft werden könnte. Das Lastenheft ist modular genug, um solche Varianten (Cloud vs. on-prem, Kauf vs. Miete) zuzulassen und objektiv zu bewerten.

• DSGVO (Datenschutz-Grundverordnung): Sie ist rechtlich bindend, aber kann auch als Best-Practice-Leitlinie gesehen werden, wie mit personenbezogenen Daten umzugehen ist. Konzepte wie Privacy by Design, Zweckbindung, Datenminimierung haben wir umgesetzt. In einer wissenschaftlichen Betrachtung kann man DSGVO als Ausdruck europäischer Werte (Privatsphäre) interpretieren, was die Systemgestaltung direkt beeinflusst. So fließen gesellschaftliche Normen in technische Normen über – ein typisches Thema der Technikphilosophie.

• ISO/IEC 27001: Dieser internationale Standard für Informationssicherheits-Management gibt einen Rahmen, um IT-Systeme (und hier auch physische Sicherheit, da eng verwoben) systematisch abzusichern. Für unser System relevant sind z. B.: Asset Management (alle Türen und Komponenten als Werte betrachten), Access Control (physischer Zutritt ist sogar eigenes Control in Annex A), Cryptography (wir nutzen Verschlüsselung), Operations Security (Patche einspielen), Communications Security (Netzwerksegmentierung für Zutrittssystem), Supplier Relationships (Vertrag mit Errichter, SLA – Anhang A.15), und Continuity Management (Notfallkonzept – Anhang A.17). Wenn das Unternehmen ISO 27001 zertifiziert ist oder sein will, liefert das Zutrittskontrollsystem viele Controls, um Anforderungen zu erfüllen. Beispielsweise A.11.1.2 (Physical entry controls) fordert Zutrittskontrollmechanismen und Protokollierung – was implementiert wird. A.11.2.4 (Equipment maintenance) – wir haben Wartungskonzept. A.9 (Access Control) – hier decken wir einen Teil (Network/IT-Zugriff steuert die IT, physischer Zugriff unser System). Somit unterstützt das Projekt das übergeordnete ISMS des Unternehmens.

• DIN EN 60839-11-1 und -2 (früher 50133): Diese Normenreihe legt Anforderungen an elektronische Zutrittskontrollsysteme und deren Anwendung fest. Sie ist zwar nicht brandneu (2013/2015), aber gibt ein gutes Begriffsgerüst und definiert Sicherheitsgrade. Gemäß 60839-11-1 gibt es Grade 1 bis 4 für Zutrittssysteme (analog zu Einbruchalarmanlagen), je nach Risikolevel. Unser System dürfte in Teilbereichen Grade 3 (Risiko mittel bis hoch) bis 4 (hoch) erreichen müssen, etwa Labore mit sensiblen Daten = Grad 4.

• definierte Reaktionszeiten,

• Sabotageschutz (Grade 3/4 verlangen Schutz gegen Abhören der Kommunikation – daher OSDP Secure),

• RZ-Sicherheit (Zentraleinheit muss in gesichertem Bereich sein),

• Alarmierung bei bestimmten Ereignissen (z. B. zwei unberechtigte Zutrittsversuche hintereinander).

Außerdem gibt’s in Teil 11-2 Richtlinien für Planung (z. B. Schleusenlogik). Wir haben versucht, all das zu berücksichtigen (z. B. Anti-Passback, Sabotagemeldungen, etc.). Ein normgerechtes System nach DIN EN 60839 ist auch ein Qualitätsmerkmal, daher könnte man das in der Ausschreibung als Muss-Kriterium nennen: System muss mindestens Grad 3 gemäß DIN EN 60839-11-1 erfüllen.

• DIN 1450 (Schriftgrößenlesbarkeit) und DIN 32975 (barrierefreie visuelle Informationen): Relevant für z. B. Beschriftung von Terminals, Display-Anzeigen groß genug, guter Kontrast – unser System muss diese ergonomischen Anforderungen erfüllen, um barrierefrei zu sein.

• DIN 33400/DIN 32984 (taktiles Leitsystem): Wenn im Gebäude blinde Personen navigieren, brauchen sie tastbare Hinweise. Unser Zutrittssystem z. B. könnte an Terminals taktile Markierungen haben (z. B. Startknopf mit Braille-Schrift). Dies sind Details, aber erwähnenswert um vollumfänglich zu sein.

• BetrSichV (Betriebssicherheitsverordnung): Reguliert Betrieb von Arbeitsmitteln, hierzu zählen auch elektrische Türantriebe. Wir müssen sicherstellen, dass z. B. Drehkreuze den Anforderungen genügen (Quetschstellenabsicherung etc.), und dass Gefährdungsbeurteilungen durchgeführt werden. Das System unterstützt dies indirekt, indem es z. B. dokumentiert, wer wann an welchem kritischen Tor gearbeitet hat (Nachvollziehbarkeit bei Unfall).

• DGUV-Vorschriften: Etwa DGUV Regel 208-022 für Türen, oder DGUV V17 für Veranstaltungen – generell der Unfallversicherungsträger fordert sichere Ausgestaltung. ZKS hilft, unberechtigten Zutritt zu verhindern (Unfälle durch unbefugte Personen vermeiden) und steuert Anlagen (Tore nur öffnen, wenn keine Person im Gefahrenbereich). Insofern fließt Arbeitssicherheit direkt ein.

• ISO 22301 (Business Continuity): Zwar kein Muss, aber unser Notfallkonzept entspricht dem Gedanken der betrieblichen Kontinuität. Ein umfassendes Sicherheitskonzept muss auch die Wiederanlaufstrategie haben (was wir geplant haben).

• IT-Grundschutz (BSI): Falls relevant, bietet das BSI-Grundschutz-Kompendium auch Bausteine für physische Sicherheit und Zutrittskontrolle. Unser System würde da als Maßnahme für diverse Anforderungen dienen. In Kontext Behörden wäre das konkret anzuwenden, in der Industrie freiwillig aber empfehlenswert.

Durch all diese Normen und Standards bewegt sich das Projekt in einem gut abgesteckten Rahmen. Die Theorie fundiert die Praxis: Wir wenden anerkannte Prinzipien an, um ein System zu schaffen, das nicht nur praktisch funktioniert, sondern auch normativ legitimiert ist. Gerade in einem Verhandlungsverfahren nach VgV ist die Verweisbarkeit auf Normen wichtig, um die Vergleichbarkeit der Angebote sicherzustellen (z. B. alle bieten entsprechend DIN 60839 an) und um dem Prüfungsamt zu zeigen, dass Standards eingehalten werden.