Migration eines SAP-integrierten Zutrittskontrollsystems?

In der Ausgangssituation betreibt das Unternehmen ein etabliertes Zutrittskontrollsystem das seit Jahren an zahlreichen Standorten im In- und Ausland im Einsatz ist und tief in die SAP HR und Zeitwirtschaft integriert wurde. Die physische Infrastruktur umfasst hunderte von Türterminals, Kartenlesern (z.B. RFID-Leser an Türen, Drehkreuzen, Zufahrten), biometrische Scanner in Hochsicherheitsbereichen, elektronische Schließzylinder sowie Server und Datenbanken zur Verwaltung der Berechtigungen. Zahlreiche Mitarbeiterausweise (Badge-Karten) sind im Umlauf. Das System protokolliert täglich tausende Zutrittsereignisse, steuert Schranken und Vereinzelungsanlagen und ist teils auch mit Alarmanlagen und Videoüberwachung verknüpft.

• Veraltete Technologie oder Herstellerstrategie: Möglicherweise ist das bestehende System technologisch in die Jahre gekommen. Hersteller stellen ältere Systeme oft zugunsten neuer Produktgenerationen ein. Es fehlen regelmäßige Software-Updates, und der Support wird eingeschränkt oder teuer. Ein Indiz hierfür sind zunehmende Fehlfunktionen und Schwierigkeiten, Ersatzteile zu bekommen. Viele Altsysteme bieten keine modernen Features (z.B. Web-Interfaces, Mobile Access, Cloud-Optionen) und lassen sich nicht mehr gut erweitern oder integrieren. Der Hersteller selbst hat wenig Anreiz, proaktiv auf die Ablösung hinzuweisen. In einem solchen Fall drohen Wartungsstau und Sicherheitslücken, was ein Unternehmen dazu zwingt, nach zukunftsfähigen Alternativen zu suchen.

• Geänderte Anforderungen: Das Unternehmen hat sich u.U. verändert – neue Standorte, geänderte Organisationsstrukturen, gestiegene Sicherheitsanforderungen (z.B. durch KRITIS-Einstufung). Das bestehende System erfüllt diese neuen Anforderungen nicht mehr vollständig. Beispielsweise erfordert die Unternehmensstrategie nun Cloud-Fähigkeit oder ein zentrales Management aller internationalen Standorte, was die alte Lösung nicht leisten kann. Oder man möchte innovative Funktionen wie smartphone-basierte Ausweise, Besucher-Self-Service oder KI-gestützte Anomalieerkennung einführen[26], die vom aktuellen Anbieter (noch) nicht angeboten werden.

• Kosten- und Vertragsgründe: Eventuell läuft der Wartungsvertrag oder eine Lizenzperiode aus, was die Gelegenheit bietet, Alternativen zu prüfen. Der bisherige Anbieter könnte hohe laufende Kosten verursachen (z.B. teure proprietäre Hardware oder Softwarelizenzen). Ein Wechsel des Anbieters eröffnet die Chance, Betriebskosten zu senken oder bessere Konditionen auszuhandeln. Zudem verringert ein offeneres System u.U. die Vendor-Lock-in-Abhängigkeit. Allerdings ist ein Migrationsprojekt anfangs investitionsintensiv – ein wichtiger Punkt für die kaufmännische Abwägung.

• Sicherheits- und Compliance-Lücken: Sollte das alte System bestimmten gesetzlichen Vorgaben nicht (mehr) genügen – z.B. fehlende DSGVO-konforme Funktionen (Datenexport, Löschfristen) oder keine Unterstützung von BSI-Kryptostandards – kann dies ein unmittelbarer Migrationsdruck sein. In KRITIS-Unternehmen sind regelmäßige Audits erforderlich; wenn das ZKS die notwendigen technischen und organisatorischen Maßnahmen nicht gewährleistet, drohen Auflagen von Behörden. Ein neues System könnte hier Abhilfe schaffen, indem es Stand der Technik erfüllt (z.B. aktuelle Verschlüsselung, Multifaktor-Authentifizierung, Sicherheitszertifizierungen).

Zusammenfassend liegen im vorliegenden Szenario ausreichend Gründe vor, einen Systemwechsel in Betracht zu ziehen. Das aktuelle, weit verbreitete System stößt an Grenzen hinsichtlich Funktionalität, Support oder Compliance. Gleichzeitig bieten moderne Zutrittskontrollsysteme eine Vielzahl von Vorteilen: höhere Flexibilität, Interoperabilität mit anderen Systemen und eine bessere Zukunftssicherheit. Dennoch ist die Migration ein komplexes Unterfangen, das neben Chancen auch Risiken birgt.

Bevor auf die konkrete Planung eingegangen wird, ist klar zu definieren, welche Ziele mit der Migration verfolgt werden. Diese Zielsetzungen dienen als Leitplanken bei allen weiteren Entscheidungen (z. B. Auswahl des neuen Systems, Budget, Zeitplan) und als Kriterien für Stop-or-Go-Meilensteine.

• Sicherheit und Zuverlässigkeit erhöhen: Das neue Zutrittskontrollsystem soll ein mindestens ebenso hohes, vorzugsweise höheres Sicherheitsniveau gewährleisten. Unbefugter Zutritt soll weiter minimiert werden, und moderne Technologien (z.B. Biometrie, Verschlüsselung, KI-Auswertung von Zutrittsmustern) sollen genutzt werden. Gleichzeitig ist eine hohe Verfügbarkeit anzustreben (Redundanz, Ausfallsicherheit), da in kritischen Bereichen ein Ausfall des Systems schwere Folgen haben könnte.

• Integration in Geschäftsprozesse und IT: Die bestehende SAP-Integration muss nahtlos vom neuen System übernommen oder verbessert werden. Personalstammdaten, Rollen und Berechtigungen sollen bidirektional synchronisiert werden. Ebenso wichtig ist die Anbindung an weitere Systeme: z.B. Identity Management (AD/LDAP, ggf. SAP IDM, Zeiterfassung, Besucher-Management, Alarmanlage, Gebäudeleittechnik. Offene API-Schnittstellen sollen zukünftige Integrationen erleichtern.

• Zukunftsfähigkeit und Skalierbarkeit: Die neue Lösung muss skalierbar sein, um zukünftige Erweiterungen (neue Standorte, mehr Nutzer) zu bewältigen. Modularität ist wichtig, um bei geänderten Anforderungen (z.B. Einbindung neuer Technologien) flexibel reagieren zu können. Idealerweise unterstützt das System Cloud-Optionen ebenso wie On-Premise-Betrieb, um je nach Standortanforderung entscheiden zu können. Ein zentrales, globales Management aller Liegenschaften soll möglich sein, inkl. Mandantenfähigkeit für regionale Besonderheiten.

• Benutzerfreundlichkeit und Betrieb: Sowohl für Administratoren/Sicherheitspersonal als auch für Endnutzer (Mitarbeiter, Besucher) soll die Bedienung intuitiv sein. Self-Service-Funktionen (z.B. Mitarbeitende beantragen zeitweise Zugänge für bestimmte Räume selbst) könnten den Verwaltungsaufwand senken. Die Verwaltung der Zutrittsrechte soll dezentral delegierbar sein (z.B. können Standortleiter Berechtigungen für ihre Mitarbeiter verwalten). Im Betrieb soll das neue System idealerweise weniger Wartungsaufwand verursachen, z.B. durch automatische Updates oder Managed-Service-Optionen.

• Compliance und Datenschutz gewährleisten: Das System muss die Einhaltung aller relevanten gesetzlichen Vorgaben sicherstellen – insbesondere DSGVO und nationales Datenschutzrecht, Arbeitsrecht (z.B. Mitbestimmungspflichten) sowie branchenspezifische Auflagen. Funktionen zur Datenschutzkonformität (Audit-Logs, differenzierte Zugriffsrechte für Admins, konfigurierbare Löschfristen) sollen vorhanden sein. Für ein KRITIS-Unternehmen sollte die Lösung zudem BSI-Grundschutz-konform bzw. nach Stand der Technik sein. Zertifizierungen oder Referenzen in sicherheitssensiblen Umgebungen wären wünschenswert. Ziel ist es, durch die Migration Rechtskonformität nicht nur zu erhalten, sondern proaktiv zu verbessern (Stichwort: Compliance by Design im neuen System).

• Kosteneffizienz über Lebenszyklus: Obwohl initial hohe Investitionen anfallen können, soll mittelfristig der Total Cost of Ownership (TCO) sinken. Das neue System soll effizienter zu betreiben sein (geringere Ausfallkosten, weniger manuelle Verwaltung, evtl. geringere Lizenzkosten). Zudem kann standardisierte Hardware (falls der neue Anbieter offene Hardware-Protokolle erlaubt) den Einkauf erleichtern. Ein wichtiges Ziel ist es, langfristige Investitionssicherheit zu gewinnen: Das System sollte über viele Jahre nutzbar und erweiterbar sein, ohne dass ein vollständiger Austausch nötig wird.

Sekundäre Ziele: Daneben gibt es weitere, begleitende Ziele wie: Verbesserung der Transparenz (bessere Berichte, Auswertungen und Audit-Möglichkeiten), Erhöhung der Mitarbeiterzufriedenheit (reibungsloser Zutritt, weniger Störungen), Vereinheitlichung von Prozessen über Standorte hinweg, und Innovation (z.B. Pilotierung neuer Zugangstechnologien wie Mobile Credentials, die eventuell im bisherigen System nicht verfügbar waren).

Diese Zielsetzungen bilden den Maßstab, an dem der Erfolg der Migration gemessen wird. Bei Konflikten zwischen Zielen (z.B. Kosten vs. maximale Funktionalität) müssen Prioritäten festgelegt werden. Im Weiteren wird der Prozess der Migration unter Berücksichtigung dieser Ziele geplant.

Die Migration eines unternehmenskritischen Systems dieser Größenordnung erfordert ein strukturiertes Projektmanagement. Bewährt hat sich eine Aufteilung in Phasen mit klar definierten Meilensteinen, an denen Stop-or-Go-Entscheidungen getroffen werden können. Im Folgenden wird das Vorgehen in Schritten erläutert:

In dieser initialen Phase wird das Projekt formal aufgesetzt.

• Stakeholder-Identifikation: Es ist essenziell, frühzeitig alle relevanten internen Interessengruppen einzubeziehen. Dazu zählen IT-Abteilung (zuständig für Netzwerk, Server, Cybersecurity), Personal/HR (da Stammdaten und Prozesse betroffen sind), Gebäudemanagement/Facility Management (Verantwortung für physische Sicherheit und Gebäudeinfrastruktur) sowie natürlich die Werksicherheit/Security selbst. Auch die Rechtsabteilung sollte konsultiert werden bezüglich Verträgen und Compliance. Diese Stakeholder müssen ein gemeinsames Verständnis für Ziele und Anforderungen entwickeln. In großen deutschen Unternehmen ist zudem der Betriebsrat frühzeitig einzubinden (Informations- und Beratungsrechte bei technischen Änderungen, die Mitarbeiterüberwachung tangieren könnten).

• Ist-Analyse des bestehenden Systems: Eine detaillierte Bestandsaufnahme schafft die Grundlage für alle weiteren Schritte. Dazu gehört:

• Technische Bestandsaufnahme: Auflistung aller vorhandenen Hardware-Komponenten (Leser, Türcontroller, Verkabelung, Server), Software-Versionen, Schnittstellen und Integrationen. Wichtig ist zu dokumentieren, welche technischen Abhängigkeiten existieren (z.B. verwendet das aktuelle System proprietäre Ausweistechnologien, spezielle Datenbanken, etc.).

• Nutzer- und Berechtigungsinventar: Anzahl der aktiven Karten/Ausweise, definierte Zutrittsprofile, Nutzergruppen und Rollen. Dies ist relevant für die Migration der Daten.

• Prozesse & Organisation: Erhebung, wie aktuell Berechtigungsvergabe, Badge-Ausstellung, Besuchermanagement etc. organisiert sind. Welche Abteilungen tun was? Gibt es Betriebsvereinbarungen oder Richtlinien, die beachtet werden müssen (z.B. Aufbewahrungsfristen von Logs)?

• Verträge und Kosten: Prüfung des Vertragsstatus mit dem bisherigen Anbieter (Kündigungsfristen, Wartungsverträge, etwaige Exit-Klauseln). Analyse der laufenden Kosten (Wartungsgebühren, Lizenzkosten, Personalaufwand) als Referenz für die Wirtschaftlichkeitsrechnung.

• Identifikation von Schwachstellen und Verbesserungsbedarfen: Basierend auf der Ist-Analyse werden die Gaps zwischen der aktuellen Situation und den definierten Zielsetzungen herausgearbeitet. Beispielsweise könnte festgestellt werden, dass das alte System keine Mobile App unterstützt oder dass für neue Standorte keine Lizenzen mehr verfügbar sind. Ebenso können Schwachstellen dokumentiert werden, etwa dass Fehlbuchungen häufig auftreten oder dass Berichte nur mit großem Aufwand erstellbar sind. Diese Liste fließt in das Anforderungsprofil des neuen Systems ein.

Am Ende von Phase 1 sollte ein Projektsteckbrief vorliegen, der Ziele, Scope, grobe Timeline und Team definiert. Zudem ist ein Go/No-Go Meilenstein einzubauen: Das Management entscheidet auf Basis der Analyse und eines initialen Business Case, ob das Projekt fortgeführt wird. Kriterien: ausreichender Nutzen erkennbar, Risiken vertretbar, Ressourcen verfügbar.

Stop-or-Go Decision 1: Weiterführung nach Analyse? Wenn z.B. der Business Case negativ wäre oder unüberwindbare Hürden in der Ist-Analyse auftauchen (etwa ein Standort mit nicht ersetzbarer Speziallösung), müsste hier eventuell der Stop gezogen oder das Projekt neu justiert werden.

In Phase 2 werden die fachlichen und technischen Anforderungen an das neue System präzisiert und mögliche Anbieter evaluiert.

• Lastenheft erstellen: Ein Lastenheft für das Zutrittskontrollsystem wird erarbeitet, das alle Muss- und Wunschkriterien festhält. Es enthält typischerweise:

• Funktionale Anforderungen: z.B. Verwaltung verschiedener Nutzergruppen (Mitarbeiter, Besucher, Dienstleister) mit jeweils differenzierten Zutrittsrechten, Unterstützung von Mehr-Faktor-Authentifizierung (z.B. Karte + PIN oder Biometrie) für bestimmte Türen, Besuchermanagement-Modul, Evakuierungsmanagement (Anwesenheitslisten im Notfall), usw.

• Technische Anforderungen: Systemarchitektur (zentrale Server vs. verteilte Server, Cloud-Unterstützung), Datenbanksystem, Performance (Anzahl der Türen/Nutzer, Echtzeitfähigkeit), Schnittstellen (SAP, Active Directory, Video, etc.), Skalierbarkeit und Redundanz, Unterstützung bestehender Ausweistechnologien (z.B. MIFARE, DESFire, Legic), IoT-Integration (z.B. Auslösen von Licht/Klima beim Zutritt), mobile Zugangsoptionen (Smartphone als Schlüssel) etc.

• Sicherheitsanforderungen: Einhaltung von Kryptostandards, Penetrationstests, Berechtigungs- und Rollenmodell für Administratoren (least privilege Prinzip), Protokollierung und Auditfunktionen (z.B. lückenloses Audit-Log aller Rechteänderungen), Datenschutz (z.B. automatische Löschung personenbezogener Zutrittsdaten nach definierter Frist, Pseudonymisierungsmöglichkeiten).

• Regulatorische Anforderungen: z.B. Konformität mit genannten Normen (DIN EN 60839 usw.), BSI-Vorgaben für KRITIS, Barrierefreiheit (Zugangssysteme für behinderte Menschen, z.B. gemäß BITV), Mitbestimmung (das System muss Einstellungen erlauben, die mit einer Betriebsvereinbarung vereinbar sind – z.B. keine unerlaubte Leistungskontrolle).

• Organisatorisches: Anforderungen an Schulungen, deutschsprachiger Support (gerade wichtig in dt. Kontext), Service-Level (Reaktionszeiten bei Störungen), etc.

Als Hilfestellung kann man sich an bestehenden Lastenheften orientieren, wie z.B. dem Muster-Lastenheft Zutrittskontrollsystem von FM-Connect, das zahlreiche Anforderungen auflistet[3][46]. Hier wird z.B. betont, dass moderne Lösungen eine zentrale Verwaltung, Protokollierung aller Zutritte und flexible Anpassbarkeit bieten sollten[3].

• Marktrecherche und Vorauswahl: Parallel zum Lastenheft wird der Markt nach potenziellen Anbietern sondiert. In unserem Szenario, wo dormakaba das Altsystem stellt, könnten als Alternativen z.B. Nedap (AEOS), Siemens (SiPass), Honeywell, LenelS2, Genetec (Synergis) oder andere internationale Anbieter in Frage kommen. Wichtig ist zu prüfen, welche Lösungen SAP-Integration unterstützen – einige Anbieter haben zertifizierte SAP-Connectoren, andere bieten generische APIs. Zudem lohnt der Blick, ob die Systeme offene Hardware-Unterstützung bieten (z.B. nicht-proprietäre Leser und Controller). Ein Migrationsvorteil ist es, wenn bestehende Leser oder Verkabelung weitergenutzt werden können, was oft der Fall ist, wenn Standard-Protokolle wie Wiegand oder OSDP unterstützt werden. Die Marktanalyse umfasst typischerweise auch das Einholen von Informationen zu Referenzen (hat der Anbieter bereits ähnlich große Projekte in Deutschland umgesetzt? Gibt es Referenzkunden in der gleichen Branche?), und eventuell ein Request for Information (RFI) an die engere Auswahl der Hersteller.

• Kaufmännische Vorüberlegungen: Noch vor der Ausschreibung sollte intern geklärt werden, welches Beschaffungsmodell favorisiert wird. Optionen sind klassischer Kauf mit Wartungsvertrag, Mietmodelle oder SaaS (Software as a Service, Cloud-Lösung). Gerade im Sicherheitsbereich setzen viele deutsche Großunternehmen weiterhin auf On-Premise aus Kontroll- und Datenschutzgründen[33], doch hybride Ansätze (Cloud-Management mit lokalem Failover) könnten interessant sein. Die Entscheidung beeinflusst die Bewertung der Anbieter (nicht jeder bietet alle Modelle). Zudem muss das Budget grob abgesteckt werden.

• Ausschreibungsverfahren einleiten: Handelt es sich beim Unternehmen um einen öffentlichen Auftraggeber oder unterliegt es aus anderen Gründen (z.B. Versorger im Energiebereich) dem Vergaberecht, ist ein formales EU-weites Ausschreibungsverfahren nötig. Andernfalls kann dennoch eine strukturierte Ausschreibung mit Pflichtenheft und Bewertungskriterien sinnvoll sein, um Vergleichbarkeit zu gewährleisten. In jedem Fall wird das Lastenheft den potenziellen Anbietern übermittelt, die daraufhin ein Pflichtenheft bzw. Angebot erstellen.

Am Ende von Phase 2 steht typischerweise eine Lieferantenauswahl: anhand definierter Kriterien (fachliche Eignung, Erfüllung der Muss-Anforderungen, Kosten, Supportkonzept, Referenzen, ggf. Proof-of-Concept) wird der neue Anbieter und das System ausgewählt. Meilenstein/Decision 2: Freigabe zur Vertragsverhandlung mit dem favorisierten Anbieter. Hier kann ein Stop erfolgen, wenn z.B. kein Anbieter die kritischen Anforderungen erfüllt oder Angebote das Budget sprengen. Dann müsste evtl. das Lastenheft angepasst werden oder das Vorhaben verschoben/abgebrochen werden.

• Vertragsgestaltung: Zunächst wird der Vertrag mit dem neuen Lieferanten finalisiert. Dabei sind Leistungsumfang, Liefer- und Installationsplan, Service Level Agreements (SLA) und ggf. Vertragsstrafen bei Nichterfüllung festzuhalten. Wichtig im Vertrag: Regelungen zur Datenmigration (der Anbieter muss möglicherweise Tools oder Unterstützung liefern, um die vorhandenen Berechtigungsdaten aus System A in System B zu überführen), zur Schulung des Personals, und zur Abnahme (Kriterien, wann das System als erfolgreich eingeführt gilt). Auch Rücktrittsklauseln können relevant sein, falls sich im Projektverlauf unlösbare Probleme zeigen (so kann das Unternehmen im Worst Case vom Vertrag zurücktreten).

• Detailplanung Migration: Gemeinsam mit dem Anbieter und internen Experten wird ein Migrationskonzept erstellt. Darin ist festgelegt:

• Migrationsstrategie: Parallelbetrieb oder Direktumschaltung? In vielen Fällen ist ein schrittweiser Parallelbetrieb ratsam: System B wird aufgebaut und getestet, während System A weiterläuft. Ein "Big Bang"-Umstieg an einem Stichtag für alle Standorte wäre riskant. Stattdessen kann man Standorte oder Regionen phasenweise umstellen.

• Reihenfolge und Prioritäten: Entscheidung, welche Standorte zuerst migriert werden. Oft wählt man einen Pilot-Standort (oder eine kleinere Einheit) als Testlauf. Dieser Pilot sollte repräsentativ sein (z.B. ein mittlerer Standort mit typischen Anforderungen), aber nicht gerade der kritischste Standort (um anfängliche Probleme nicht gleich in sicherheitssensitivster Umgebung zu haben).

• Technische Infrastruktur: Planung der Beschaffung und Installation der neuen Hardware. Welche bestehenden Komponenten können weiterverwendet werden? Ein positiver Aspekt moderner Systeme ist oft, dass bestehende Infrastruktur nicht komplett ausgetauscht werden muss – Beispiel: „Bestehende Infrastruktur lässt sich weiterverwenden oder auf eine kabellose Umgebung umbauen“, wie es beim Kaba exos Konzept CardLink hieß[48]. Im Idealfall können Leser, Verkabelung oder Ausweiskarten weiter genutzt werden. Falls das neue System andere Kartenformate verwendet, muss der Tausch der Ausweise (Rebadging) geplant werden – inkl. Fotoaufnahmen, Druck neuer Karten, Verteilung an Mitarbeiter. Dies ist ein erheblicher organisatorischer Aufwand und sollte vermieden werden, wenn nicht nötig.

• Datenmigration: Planung, wie die Daten aus System A exportiert und in System B importiert werden. Hierzu gehören Benutzerstammdaten, Ausweiskarten-IDs, bestehende Zutrittsprofile/Rechte. Möglichst soll dies automatisch oder skriptgesteuert erfolgen, um Fehler zu minimieren. Auch historische Zutrittslogs könnten migriert oder archiviert werden. Es empfiehlt sich, exemplarisch ein paar Datensätze durchzuspielen, um Mapping-Probleme aufzudecken (z.B. unterschiedliche Feldformate, Kodierungen).

• Integrationstests: Vor dem produktiven Einsatz sind alle Schnittstellen zu testen. Besonders kritisch: die SAP-Integration. Der Anbieter muss nachweisen, dass z.B. die bidirektionale Kommunikation wie vorgesehen funktioniert – z.B. durch einen Test mit dem QA-System von SAP. Gleiches gilt für Schnittstellen zu Active Directory (Sync von Benutzern), Alarmanlage, etc. Hier sollte genügend Testzeit einkalkuliert werden.

• Fallback-Plan: Was passiert, wenn während oder nach der Migration schwerwiegende Probleme auftreten? Ein Rollback-Konzept sollte erarbeitet werden. Beispielsweise könnte man vorsehen, dass im Notfall das alte System A reaktiviert wird (solange parallel betrieben, wäre das möglich) oder dass zumindest eine Not-Zutrittskontrolle manuell/mit Wachdienst erfolgt, falls beide Systeme ausfallen. Gerade für KRITIS-Bereiche muss ein Notfallplan existieren, um die physische Sicherheit jederzeit zu gewährleisten (z.B. Notöffnung bestimmter Türen mit mechanischem Schlüssel etc.).

• Organisation & Personal: In dieser Planungsphase werden auch Rollen im Projektteam verteilt. Ein Migrationsprojektleiter koordiniert intern, der Hersteller stellt i.d.R. einen Projektleiter auf seiner Seite. Es sollte lokale Site Coordinators je Standort geben, die die Besonderheiten vor Ort kennen. Außerdem müssen frühzeitig Schulungspläne entwickelt werden: Administratoren, Security-Mitarbeiter (Empfang, Werkschutz) und ggf. Endanwender (wie beantrage ich zukünftig Zugänge?) müssen in System B eingewiesen werden. Schulungen können parallel zur technischen Umstellung pro Standort stattfinden.

Am Ende von Phase 3 steht ein abgestimmter Migrations-Masterplan. Meilenstein/Decision 3: Managementfreigabe zur Implementierung. Hier wird das endgültige Go gegeben, tatsächlich Hardware zu beschaffen, Verträge final zu unterschreiben und in die Ausführung zu gehen. Ein No-Go an dieser Stelle käme eher selten vor, außer es zeigen sich unakzeptable Bedingungen – z.B. der Anbieter kann vertraglich doch nicht garantieren, was zugesagt war, oder neue externe Umstände (Budgetkürzungen, Sicherheitsvorfälle) erzwingen ein Einfrieren des Projekts.

• Pilot-Inbetriebnahme: Das neue System B wird zunächst in einem Pilotbereich installiert. Das beinhaltet das Aufbauen der Server (Produktivsystem, eventuell auch Testsystem), Einspielen der notwendigen Software und Konfiguration nach den zuvor definierten Einstellungen. Es werden einige Türen/Leser im Pilotbereich an System B angebunden – entweder durch Umrüstung der Hardware oder (falls parallel möglich) durch Doppelbestückung von Türen. Im Pilot wird auch die SAP-Schnittstelle erstmals produktiv angebunden, aber vielleicht zunächst nur für eine kleine Benutzergruppe. Wichtig: Echtzeit-Tests durchführen – z.B. ein Testmitarbeiter wird in SAP angelegt und man prüft, ob dieser automatisch im Zutrittssystem erscheint mit korrekten Rechten[5]. Ebenso testet man, ob Zutrittsbuchungen korrekt an SAP zurückgemeldet werden (z.B. für Zeiterfassung).

• Test und Abnahme Pilot: Der Pilotbetrieb sollte für einen gewissen Zeitraum (z.B. 2-4 Wochen) laufen, um genügend Erfahrungen zu sammeln. In dieser Zeit werden Fehler und Schwachstellen dokumentiert. Typische Probleme könnten sein: einzelne Leser funktionieren nicht zuverlässig, die Performance ist schlechter als erwartet, Berechtigungsmappings stimmen noch nicht exakt mit den bisherigen Regelungen überein, oder Benutzer finden die Bedienung der neuen Software schwierig. Diese Pilot-Erkenntnisse sind Gold wert, um Korrekturen vorzunehmen bevor der große Rollout startet. Am Ende der Pilotphase findet eine Abnahmeprüfung statt: Wurden die vordefinierten Erfolgskriterien erreicht? Dazu können gehören:

• Eine definierte Anzahl von Testfällen wurde erfolgreich durchgeführt (z.B. Neuanlage Mitarbeiter -> Zugangsrecht erteilt; Austritt -> Zugang gesperrt; zeitgesteuerte Rechte funktionieren; Alarmfälle werden korrekt gemeldet).

• Benutzerfeedback ist eingeflossen und es gibt keine unlösbaren Usability-Probleme.

• Schnittstellen laufen stabil und ohne Fehlermeldungen im Log.

• Der Betriebsrat hat dem Pilotbetrieb zugestimmt und keine ungeklärten Datenschutzfragen offen (ggf. Anpassungen in Betriebsvereinbarung falls neue Features).

Meilenstein/Decision 4: Go für Rollout? An diesem Punkt entscheidet das Steuerungsgremium, ob mit der breiten Ausrollung auf alle Standorte fortgefahren wird. Ein Stop würde bedeuten, dass z.B. das neue System die Erwartungen nicht erfüllt und man den Vertrag eventuell kündigt (wenn vertraglich vorgesehen) oder das Projekt neu verhandelt.

• Schrittweiser Rollout: Bei positivem Entscheid wird System B schrittweise im gesamten Unternehmen ausgerollt. Hierbei kann man nach Standorten oder Regionen vorgehen. Wichtige Punkte beim Rollout:

• Lokale Begebenheiten: Vor Ort muss oft Hardware getauscht werden – z.B. Zugangskontrollschränke, Controller oder Leser. Dies erfordert kurze Zutrittsunterbrechungen pro Tür, was mit den lokalen Verantwortlichen abgestimmt sein muss (z.B. Umbau außerhalb der Kernarbeitszeiten, Bereitstellung von Aufsichts- oder Wachdienst während Umschaltung).

• Duale Systeme temporär: Häufig laufen während des Rollouts beide Systeme parallel: Solange nicht alle Türen eines Standortes umgerüstet sind, muss eventuell ein Mitarbeiter zwei Ausweise tragen (den alten für Bereiche noch unter System A, den neuen für bereits migrierte Bereiche). Alternativ können, wenn technisch möglich, die neuen Leser sowohl alte als auch neue Ausweiskarten lesen (z.B. Multi-Technology-Reader). Übergangsszenarien sollten klar definiert sein, um Verwirrung oder Sicherheitslücken (z.B. jemand hat schon alten Ausweis abgegeben, aber neuer Bereich noch nicht aktiv) zu vermeiden.

• Datenmigration fortsetzen: Vor jedem Standort-Rollout werden die Nutzerdaten für diesen Standort aus dem alten System extrahiert und ins neue importiert, damit am Tag X alle Berechtigungen vorhanden sind. Eventuell kann man die Datenmigration auch zentral einmal durchführen, wenn es technisch und organisatorisch machbar ist, aber meistens muss man sukzessive vorgehen, um Änderungen während der Übergangszeit zu berücksichtigen.

• Schulung und Change Management: Bei der Umstellung jedes Standorts sollte geschultes Personal vor Ort sein, um on the fly zu unterstützen – sowohl vom Anbieter als auch eigene Key-User. Mitarbeitende müssen informiert werden, wie der neue Ausweis funktioniert, ob PINs neu gesetzt werden müssen, wo sie sich bei Problemen melden etc. Ein gutes Change Management ist hier entscheidend, damit die Akzeptanz hoch bleibt. Kommunikation (z.B. interne Newsletter, FAQs auf dem Intranet) begleiten den Rollout.

• Monitoring: Während des Rollouts werden engmaschig Statistiken und Logs geprüft, um etwaige Fehler sofort zu erkennen. Der Anbieter sollte idealerweise vor Ort sein oder per Remote alle Systeme überwachen. Auch regelmäßige Abstimmungen im Projektteam (z.B. tägliche Standup-Meetings während kritischer Phasen) helfen, den Überblick zu behalten.

• Zwischenstop/Review: Falls der Rollout viele Etappen hat, können nach bestimmten Meilen (z.B. nach Umstellung der ersten 5 Standorte oder nach der Hälfte der Türen) weitere Review-Meetings stattfinden. Hier kann entschieden werden, ob das Tempo gehalten werden kann oder ob Anpassungen nötig sind (mehr Ressourcen, geänderter Plan, oder in extremen Fällen ein Stopp, falls unerwartete gravierende Probleme auftreten, die erst gelöst werden müssen).

• Abschaltung des Altsystems: Sobald alle vorgesehenen Bereiche migriert sind und stabil auf System B laufen, wird das alte System A abgeschaltet. Dies sollte koordiniert und dokumentiert erfolgen. Vor Abschaltung ist zu prüfen, ob alle benötigten historischen Daten aus System A exportiert oder archiviert wurden (Zutrittslogs, Reporting-Daten für Audits). Ggf. wird System A noch eine Zeit lang im read-only Modus belassen, falls z.B. Ermittlungen oder Prüfungen der alten Logs nötig sind. Schlussendlich erfolgt die Entsorgung oder Rückgabe alter Hardware (hier wiederum auf Datenschutz achten: Festplatten von alten Servern löschen, Konfigurationsdaten in Controllern zurücksetzen etc.). Verträge mit dem alten Anbieter werden gekündigt oder laufen aus. Damit endet technisch die Migrationsphase.

Nach dem Rollout beginnt die Stabilisierungsphase im Betrieb: - Übergabe an Betrieb/Support: Das Projektteam übergibt die Verantwortung an die Linienorganisation (z.B. Security Operations oder IT-Betrieb). Alle Systemdokumentationen müssen final erstellt sein, Administratorhandbücher, Betriebshandbücher usw. Der neue Anbieter hat hoffentlich während der Implementierung auch einen Wissenstransfer geleistet. - Feintuning: In den ersten Wochen/Monaten Echtbetrieb kann weiteres Feintuning nötig sein. Beispielsweise stellt man fest, dass gewisse Zutrittsrollen noch optimiert werden können, oder dass Berichte angepasst werden müssen. Das System B bietet eventuell viele neue Möglichkeiten – hier lohnt es sich, nach und nach die erweiterten Funktionen auszunutzen (z.B. Dashboards, KI-Analysen). - Projektabschluss: Nach einer definierten Abnahmezeit wird das Projekt formell abgeschlossen. In einer Abschlussbetrachtung werden die Zielerreichung geprüft (wurden alle eingangs definierten Ziele erfüllt?) und Lessons Learned dokumentiert.

Meilenstein/Decision 5: Projektabschlussfreigabe. Der Lenkungsausschuss entscheidet, ob das Projekt erfolgreich abgeschlossen ist oder ob noch Nacharbeiten vor einer offiziellen Abnahme nötig sind. In der Regel ist dies ein Go mit kleineren Restaufgaben oder einer Gewährleistungsphase, in der der Anbieter für auftretende Mängel noch geradestehen muss.

Die technische Dimension einer Zutrittskontrollsystem-Migration ist äußerst komplex. Hier werden die wichtigsten Punkte behandelt:

Die Zielarchitektur des neuen Systems sollte bereits in der Planungsphase festgelegt worden sein. Wahrscheinlich wechselt man von einer etablierten On-Premise-Lösung (z.B. dormakaba Exos oder Matrix) zu einer modernen Architektur, die sowohl On-Premise als auch Cloud-Komponenten haben kann. Wichtig ist, die Netzwerkanbindung aller Standorte sicherzustellen: Geographisch verteilte Liegenschaften (Deutschland, Niederlande, Kanada etc.) werden meist über WAN/VPN angebunden. Die Latenz muss niedrig genug sein, damit Zutrittsentscheidungen in Echtzeit erfolgen.

• Hardware-Komponenten: Ein kritischer Aspekt ist die Kompatibilität oder Austauschbarkeit der Tür-Hardware. Falls das alte System proprietäre Leser und Controller einsetzt, müssen diese durch neue Geräte ersetzt werden. Moderne IP-fähige Türcontroller vereinfachen die Architektur, da sie direkt ins Netzwerk gehen und zentral konfiguriert werden können. Althergebrachte serielle oder CAN-Bus Verkabelungen könnten zu Flaschenhälsen werden. Es empfiehlt sich, auf Standard-Protokolle zu setzen: Beispielsweise werden RFID-Leser zunehmend mit OSDP (Open Supervised Device Protocol) angebunden statt dem alten Wiegand-Protokoll, da OSDP verschlüsselt, bidirektional und standardisiert ist. Wenn die alten Leser OSDP unterstützen, kann man sie eventuell weiterverwenden. Auch die Ausweistechnologie ist relevant: benutzt das alte System z.B. MIFARE Classic (mit bekannten Sicherheitslücken), könnte die Migration eine Chance sein, auf sicherere Transponder wie DESFire EV2/EV3 umzusteigen. Allerdings erfordert das Tausch der Karten, was organisatorisch aufwendig ist. Ein Mittelweg kann sein, Dual-Technology-Karten auszugeben, die sowohl alt als auch neu funktionieren, um einen gleitenden Übergang zu ermöglichen.

• Daten und Schnittstellen: Technisch heikel ist die Datenmigration. Benutzerstammdaten aus System A müssen in System B importiert werden. Idealerweise stellt System A Exportmöglichkeiten (CSV, SQL dumps, etc.) bereit. Manchmal sind Altsysteme geschlossen, und man muss kreativ werden – z.B. DB-Dumps ziehen oder sogar Skripte schreiben, die APIs des alten Systems nutzen, falls vorhanden. In unserem Fall, da System A in SAP integriert war, könnten viele Daten sowieso in SAP liegen (wer hat welche Zutrittsrolle). Es kann überlegt werden, das neue System initial komplett aus SAP "befüllen" zu lassen: D.h. SAP wird als Master genommen, alle Mitarbeiter neu an System B geschickt mit passenden Rollen (sofern definierbar). Diese Variante erfordert aber, dass in SAP schon alle Zugangslogik sauber gepflegt ist, was nicht immer 100% der Fall ist. Wahrscheinlich wird es ein kombiniertes Vorgehen: Bestandsdaten migrieren und dann mit SAP abgleichen.

Für Schnittstellen gilt: ein guter Test und Übergangsplan ist entscheidend. Z.B. Active Directory Sync – möglicherweise konnte das alte System Benutzer via LDAP einlesen; das neue macht es anders (neuer Mechanismus oder Cloud-AD). Das heißt, die IT muss diese Integrationen neu einrichten. Speziell bei SAP: existieren SAP-AddOns oder Middleware vom alten Anbieter, die nun wegfallen? Dormakaba hatte z.B. eigene SAP-AddOn Module (Kaba b-comm etc.). Diese müssten deinstalliert werden, wenn das neue System direkt via z.B. SAP CPI (Cloud Platform Integration) oder andere API kommuniziert. Der SAP-Basis-Bereich muss involviert sein, um keine Kollateralschäden im ERP zu verursachen.

• IT-Security: Bei der technischen Umsetzung muss das Security-Team ein Auge darauf haben, dass die Cybersecurity des neuen Systems auf höchstem Niveau ist. Ein neues System, vor allem wenn Cloud-Komponenten genutzt werden, muss vom Informationssicherheits-Beauftragten (CISO-Team) abgenommen werden. Punkte: - Verschlüsselung: Alle Datenübertragungen (Leser <-> Controller, Controller <-> Server, Server <-> SAP) sollten nur verschlüsselt erfolgen (TLS, VPN, OSDP Secure Channel etc.). Standard-Passwörter in Geräten sind zu ändern. - Zugriffsschutz: Die Server von System B (Applikationsserver, DB) müssen in entsprechend gesicherten Netzsegmenten platziert werden, Firewalls müssen angepasst werden. Administrator-Zugänge zum System sollten in das bestehende IAM (z.B. AD Accounts, MFA für Admins) integriert werden. - Penetrationstest: Es ist empfehlenswert, vor dem Go-Live einen Pen-Test oder zumindest eine Vulnerability-Analyse des neuen Systems durchzuführen. Hersteller liefern häufig Sicherheitshinweise; eventuell existiert ein BSI-Zertifikat oder ähnliches, das geprüft werden kann. - Notfallbetrieb: Wie im Plan erwähnt, muss sichergestellt sein, dass auch bei Teil-Ausfällen (Netzwerk weg, Server down) die kritischen Türen aufgehen oder zumindest von Sicherheitspersonal geöffnet werden können. Fail-Safe vs Fail-Secure: z.B. Außentüren mögen im Fehlerfall zu bleiben (Fail secure), Fluchttüren aber auf (Fail safe) – die Konfiguration ist wichtig in Abstimmung mit Brandschutz.

• Datenschutz: Während der Migration dürfen personenbezogene Daten nicht unkontrolliert verlorengehen oder in falsche Hände gelangen. Der Datenschutzbeauftragte sollte das Projekt begleiten. Wenn Daten aus dem alten System exportiert werden, sind diese vor Zugriff zu schützen (Verschlüsselung, sichere Löschung nach Gebrauch). Eventuell ist eine Datenschutz-Folgenabschätzung (DSFA) erforderlich, insbesondere wenn das neue System zusätzliche Funktionen einführt, die die Privatsphäre berühren (z.B. biometrische Daten, detailliertere Auswertungen über Mitarbeiterbewegungen). Unter DSGVO ist zu prüfen, ob die Rechtsgrundlage "berechtigtes Interesse" oder "Vertrag" für die Zutrittskontrolle weiterhin trägt, und ob zusätzliche Maßnahmen (Informationspflichten, Einwilligungen bei Biometrie) nötig sind. Die neue Software sollte, wie erwähnt, Datenschutz by Design aufweisen: z.B. rollenbasierte Zugriffe auf Logs (nur befugte Personen können personenbezogene Zutrittslogs einsehen), automatische Löschkonzepte, Pseudonymisierung wo möglich (z.B. Besucherdaten werden nach X Tagen anonymisiert).

Zudem ist mit dem Betriebsrat zu verhandeln, ob die vorhandene Betriebsvereinbarung Zutritt angepasst werden muss. Oft beinhalten solche Vereinbarungen genaue Regelungen, wer welche Daten einsehen darf und wie lange sie gespeichert werden. Ein neues System könnte technisch mehr können (z.B. Standortübergreifendes Tracking), was ggfs. eingeschränkt werden muss, um Arbeitnehmerrechte zu wahren. Hier gilt es, Transparenz zu schaffen und gemeinsam mit dem Betriebsrat Lösungen zu finden (etwa bestimmte Module nicht zu aktivieren, oder neue Schutzmaßnahmen zu etablieren).

Die organisatorische Seite der Migration wurde im Phasenplan teilweise schon adressiert.

• Change Management: Die Migration eines so grundlegenden Systems kann bei Mitarbeitern Verunsicherung auslösen ("Werde ich morgen noch ins Büro kommen? Was, wenn mein neuer Ausweis nicht geht?"). Hier ist Kommunikation der Schlüssel. Frühzeitig sollte das Unternehmen informieren, dass ein neues Zutrittssystem kommt, warum es gemacht wird (Vorteile erklären, z.B. "mehr Sicherheit, moderner Ausweis, eventuell bald auch Handy als Schlüssel" – je nachdem). Man kann Teststationen aufbauen, wo Mitarbeiter den neuen Badge ausprobieren können, bevor umgestellt wird. Ein Helpdesk (oder die Security-Leute) sollten in der Anfangszeit gut erreichbar sein für Problemchen.

• Schulung: Nicht nur die Security-Mannschaft, auch andere Abteilungen brauchen Schulung. Beispielsweise die HR-Abteilung, wenn sie etwa im SAP etwas anders machen muss oder neue Prozesse hat (vielleicht gibt es ein Web-Portal zur Vergabe von Zutrittsrechten an Fremdfirmen). Oder das Empfangspersonal, das Besucheranmeldungen nun im neuen System macht – hier sollte mit praxisnahen Trainings gearbeitet werden.

• Mitbestimmung und Mitarbeitereinbindung: Bereits erwähnt wurde die Einbindung des Betriebsrats. Positiv kann sein, wenn man diesem zeigt, dass das neue System Datenschutz-Features hat, die das alte nicht hatte – z.B. bessere Kontrolle, wer Logdaten sieht, oder dass man einstellen kann, dass Vorgesetzte keine detailierten Bewegungsprofile ihrer Mitarbeiter einsehen können usw. So wird deutlich, dass die Migration auch im Sinne der Mitarbeiter erfolgen kann. Im Sinne der Akzeptanz können auch Key-User aus verschiedenen Bereichen ins Projekt einbezogen werden, die Feedback geben aus Anwendersicht. Dies erhöht die Identifikation mit dem neuen System.

• Übergang Alt-zu-Neu in Prozessen: Neben der Technik müssen auch alle betroffenen Prozesse angepasst werden: z.B. Prozess neuer Mitarbeiter: bisher füllte HR ein Formular aus und schickte es an die Werksicherheit, jetzt evtl. läuft es elektronisch im Self-Service. Oder der Prozess Zutrittsmedien verwalten: wie werden verlorene Ausweise im neuen System gesperrt und ersetzt? Alle solche Abläufe sind zu überprüfen und zu schulen.

• Kultur und Änderungen in Zuständigkeiten: Ein neues System bringt oft auch neue Möglichkeiten der Aufgabenverteilung. Vielleicht können künftig Standort-Manager selber Besucher anlegen oder Zutrittsrechte vergeben (delegated administration)[36], wo früher zentral die Sicherheitsabteilung alles machte. Solche Änderungen müssen organisatorisch flankiert werden (Policy: wer darf was? Braucht es Schulungen/Rezertifizierungen für diese dezentralen Admins?). Eine klar definierte Governance für das Berechtigungsmanagement ist weiterhin notwendig, um keinen Wildwuchs zuzulassen.

• Budget und Kostenkontrolle: Ein Projekt dieser Größe erfordert ein erhebliches Budget, das vorausschauend geplant und laufend kontrolliert werden muss. Kostenblöcke sind: - Anschaffungskosten für Hard- und Software: neue Controller, Leser, Server, Lizenzen. Ggf. auch Netzwerkupgrades oder neue Ausweiskarten (nicht trivial – tausende Karten nebst Druck kosten u.U. sechsstellige Beträge). - Dienstleistungskosten: des neuen Anbieters (Implementierung, Customizing, Schulung) und evtl. externer Berater. In dem Zusammenhang: Viele Unternehmen nehmen für solche kritischen Sicherheitssysteme einen Sicherheitsberater hinzu, der herstellerneutral berät, das Pflichtenheft mit erstellt und während der Umsetzung Qualität sichert. Das ist zwar ein zusätzlicher Kostenpunkt, kann aber helfen, Risiken zu reduzieren. - Interne Personalkosten: Das Projektteam arbeitet oft über Monate intensiv – diese Arbeitszeit ist in Opportunitätskosten zu betrachten. Evtl. müssen Vertreter eingestellt oder Aufgaben umverteilt werden, damit das Tagesgeschäft nicht leidet. - Doppelkosten in Übergangsphase: Während der Parallelbetriebsphase zahlt man möglicherweise doppelt – Lizenz/Wartung fürs alte System läuft noch, während das neue schon Kosten verursacht. Dies im Budget einplanen, eventuell kann man mit dem alten Anbieter über reduzierte Wartungskosten verhandeln, falls nur noch Restbetrieb.

• Wirtschaftlichkeitsrechnung: Letztlich muss der Return on Investment (ROI) bzw. Business Case darstellbar sein. Die Nutzen sind teilweise "weich" (höhere Sicherheit, Compliance) und schwer in Euros zu messen; andere sind monetärer Natur (z.B. weniger manuelle Arbeit = Personalkostenersparnis, oder Vermeidung von Strafzahlungen durch bessere Compliance). Im Kontext KRITIS könnte man argumentieren: Ein Sicherheitsvorfall wegen veralteter Technik könnte Millionen kosten, die Investition beugt dem vor. In der kaufmännischen Bewertung sollten verschiedene Szenarien betrachtet werden: Bleiben vs. Wechsel (dazu unten mehr im Vergleich).

• Vertragsmanagement: Neben dem neuen Vertrag (bereits erwähnt) ist auch an alte Verträge zu denken: Kündigung beim bisherigen Hersteller rechtzeitig aussprechen, um keine verlängerten Wartungsverträge zahlen zu müssen. Falls Leasingverträge für Hardware bestanden, diese beenden oder Geräte ablösen. Wenn das Personal des alten Systemanbieters evtl. vor Ort war (z.B. embedded Techniker), muss man den Übergang regeln (Übernahme? Freistellen?).

• Abschreibungen: Die noch nicht abgeschriebenen Altinvestitionen (z.B. alte Hardware in den Büchern) müssen gehandhabt werden. Gegebenenfalls führt man sie weiter bis Lebensende oder schreibt sie vorzeitig ab (Ausmusterung). Für die neuen Investitionen wieder passende Abschreibungszeiträume festlegen (z.B. Hardware 5-7 Jahre, Software 3-5 Jahre). Bei internationalem Einsatz ist auch die Währungsfrage zu beachten (Kauf in Euro, Dollar? Wechselkursschwankungen könnten Budget beeinflussen).

• Fördermöglichkeiten: Am Rande – es gibt zwar selten Förderungen für Zutrittskontrollsysteme, aber in manchen Sicherheitsforschungs- oder Innovationsprogrammen könnte es Zuschüsse geben (z.B. für KMU oder im Rahmen von Forschungsprojekten). Für ein Großunternehmen vermutlich weniger relevant, dennoch sollte man alle Optionen prüfen.

• Versicherung und Haftung: Nach der Migration sollte geprüft werden, ob die Versicherungsverträge (Gebäudeversicherung, Betriebshaftpflicht) angepasst werden müssen bzw. ob das neue System weiterhin allen Auflagen der Versicherer entspricht. Manche Versicherer fordern z.B. VdS-zertifizierte Anlagen für bestimmte Riskoklassen. Wenn das neue System das nicht hat, muss verhandelt oder nachgerüstet werden. Haftungsfragen: Der Anbieter sollte vertraglich für Schäden durch grobe Mängel haften. Aber intern muss man auch definieren, wer etwa haftet, wenn durch die Migration ein Produktionstopp passiert (z.B. weil keiner in die Fabrik kam morgens) – solche Risiken müssen im Projekt bewusst gemanagt werden, eventuell durch Pufferzeiten (Migration nur am Wochenende etc.).

• Vertrags- und Vergaberecht: Wenn das Unternehmen kein öffentlicher Auftraggeber ist, hat es mehr Freiheiten, aber dennoch müssen Compliance-Regeln bei der Beschaffung eingehalten werden. In DE gibt es z.B. interne Einkaufsrichtlinien, ab bestimmten Summen mehrere Angebote einzuholen usw. Rechtlich wichtig ist, dass keine bestehenden Verträge verletzt werden – z.B. ein laufender Wartungsvertrag mit dem alten Anbieter, der bis Jahresende geht, sollte entweder erfüllt oder einvernehmlich aufgehoben werden. Sonst drohen Vertragsstrafen.

• Datenschutzrecht: Wie ausführlich schon behandelt, greift hier v.a. die DSGVO. Unter Umständen ist eine DSFA (Datenschutz-Folgenabschätzung) vorgeschrieben, da es um umfangreiche systematische Überwachung öffentlich zugänglicher Bereiche oder umfangreiche Verarbeitung von Beschäftigtendaten gehen könnte. Die Zutrittskontrolle betrifft Beschäftigtendaten, daher ist §26 BDSG (Bundesdatenschutzgesetz) einschlägig – wonach Verarbeitung für Beschäftigungsverhältnis erlaubt ist, wenn zur Sicherheit erforderlich. Das neue System darf jedoch nicht ohne weiteres z.B. Bewegungsprofile zu Leistungszwecken erstellen, sonst droht ein Konflikt mit Persönlichkeitsrechten. Daher sollten Betriebsrat und Datenschutzbeauftragter gemeinsam definieren, welche Auswertungen zulässig sind und welche nicht. Eine klare Zweckbindung "Zutritt aus Sicherheitsgründen" muss erkennbar bleiben.

• Arbeitsrecht/Mitbestimmung: Der Betriebsrat hat nach BetrVG Mitbestimmungsrechte bei technischen Einrichtungen, die Verhalten oder Leistung überwachen können (§87 Abs.1 Nr.6 BetrVG). Ein modernes ZKS kann theoretisch zur Leistungskontrolle missbraucht werden (z.B. wann kommt Mitarbeiter X und geht). Entsprechend wird die Betriebsvereinbarung regeln, dass solche Daten nicht zu disziplinarischen Zwecken genutzt werden dürfen, sondern nur für Sicherheit/Nachvollziehbarkeit, außer im Missbrauchsfall etc. Wichtig ist, diesen rechtlichen Rahmen einzuhalten, sonst könnte der Betriebsrat das Projekt stoppen. In der Praxis heißt das: Einbindung, Transparenz und Einvernehmen erzielen. Ggf. muss eine neue BV abgeschlossen oder die alte angepasst werden, bevor der Rollout startet.

• KRITIS-Regularien: Sollte das Unternehmen unter das IT-Sicherheitsgesetz fallen, muss es alle zwei Jahre gegenüber dem BSI nachweisen, angemessene Security-Maßnahmen umgesetzt zu haben. Ein Zutrittssystem fällt zwar primär unter physische Sicherheit, aber z.B. für Strom- oder Telekommunikationsnetz-Betreiber kann auch physische Zugangssicherheit Teil der Auditprüfung sein. Die Migration eines so zentralen Sicherheitssystems sollte dem BSI ggf. mitgeteilt werden, insbesondere wenn es temporär vielleicht ein anderes Sicherheitsniveau bedeutet. Außerdem sind die Branchenstandards (B3S) mancher KRITIS-Branchen relevant, die oft physische Zugangskontrolle als Maßnahme definieren. Das neue System sollte dabei helfen, diesen Standard besser zu erfüllen. Auch müsste ein Sicherheitsvorfall (z.B. Totalausfall der Zutrittskontrolle, der länger als x Zeit dauert und die Versorgungssicherheit gefährdet) ggf. als Meldung an die Behörde abgesetzt werden – hier sollte das Unternehmen vorbereitet sein.

• Normen und Zertifizierungen: Aus juristischer Sicht sind Normen zwar "nur" Stand der Technik-Beschreibungen, aber in Verträgen werden sie oft als verbindlich vereinbart. Das Unternehmen kann z.B. vertraglich fordern, dass das System DIN 60839 konform installiert wird und VdS-Richtlinien erfüllt. Sollte es zu Schadenfällen kommen (z.B. Einbruch, obwohl Zutrittssystem vorhanden), können solche Normen bei der Beurteilung der Sorgfaltspflicht relevant werden. Daher ist es im Eigeninteresse, nach Norm zu arbeiten. Auch Arbeitsschutzvorschriften spielen hinein: eine Zutrittskontrolle ist Teil der betrieblichen Sicherheit, und wenn sie z.B. in Fluchtwege eingreift, müssen Arbeitsstättenrichtlinien erfüllt bleiben (Tür öffnet im Notfall usw.). Die Juristen im Team müssen darauf achten, dass keine Vorschrift verletzt wird und alle Genehmigungen eingeholt sind (manchmal brauchen z.B. elektromechanische Verriegelungen an Fluchttüren eine Abnahme durch Sachverständige).

• Internationaler Kontext: Da Standorte auch im Ausland liegen, müssen dortige Gesetze und Standards berücksichtigt werden. In der EU sind DSGVO und viele Normen ähnlich in jedem Land. In den Niederlanden etwa gibt es vergleichbare Datenschutzgesetze (Umsetzung DSGVO) und Arbeitsgesetze. Im angelsächsischen Ausland (z.B. Kanada) gelten ggf. andere Vorgaben: UK hat im Wesentlichen die GDPR im UK Law überführt, in den USA gibt es je nach Branche Regularien (z.B. NERC CIP für Energieversorger, was physische Sicherheit von Critical Assets vorschreibt). Auch hier sollte man lokale Legal Teams einbeziehen, um Compliance global sicherzustellen.

Es sind die rechtlichen Aspekte ebenso vielfältig wie die technischen, dürfen aber keinesfalls vernachlässigt werden, um keine bösen Überraschungen in Form von Rechtsverstößen oder Strafen zu erleben.

Die Entscheidung, ein umfangreiches Zutrittskontrollsystem auf einen neuen Hersteller umzustellen, ist von weitreichender Bedeutung. Eine SWOT-Analyse beleuchtet die internen Stärken und Schwächen dieses Vorhabens sowie die externen Chancen und Risiken (Gefahren) im Kontext.

• Modernisierung und Zukunftsfähigkeit: Durch die Migration erlangt das Unternehmen ein modernes System, das state-of-the-art Technologie und aktuelle Sicherheitsstandards nutzt. Dies erhöht die Robustheit und Skalierbarkeit und schützt vor den Nachteilen eines veralteten Systems (wie Ausfällen oder Sicherheitslücken).

• Verbesserte Integration: Das neue System kann nahtloser in die bestehende IT-Landschaft integriert werden (z.B. bessere SAP-Integration, offene APIs). Dadurch werden automatisierte Abläufe gestärkt und manuelle Schnittstellen eliminiert, was Effizienz schafft.

• Erhöhte Sicherheit & Compliance: Durch neue Funktionen (z.B. Echtzeit-Überwachung, KI-gestützte Alarmierung, Verschlüsselung) werden Sicherheitsvorfälle unwahrscheinlicher erkannt und verhindert. Zugleich können gesetzliche Vorgaben (DSGVO, KRITIS) leichter eingehalten werden, da das System entsprechende Features mitbringt. Das reduziert das Risiko von Compliance-Verstößen und daraus resultierenden Strafen.

• Effizienzgewinne: Moderne Systeme ermöglichen automatisierte Prozesse in der Berechtigungsverwaltung (z.B. Selbstverwaltung durch Fachabteilungen) und konsolidierte Administration aller Standorte. Dadurch sinkt der Aufwand für die Security-Teams; Personal kann für wertschöpfendere Aufgaben eingesetzt werden. Auch der Support wird einfacher, da einheitlichere, vielleicht cloudgestützte Tools genutzt werden.

• Positives Image & Vertrauen: Intern wie extern signalisiert ein neues, sicheres Zutrittssystem, dass das Unternehmen in Sicherheit und Innovation investiert. Bei Kunden, Partnern oder Audits kann dies Vertrauen stärken (wichtig z.B. wenn Kunden Einrichtungen besuchen – sie sehen ein modernes Sicherheitsmanagement).

• Hohe Anfangsinvestitionen: Die Migration verursacht erhebliche Kosten upfront, sowohl finanziell (neue Hardware/Software, Projektkosten) als auch personell (gebundene Ressourcen im Projekt). Das kann kurzfristig die Bilanz belasten und muss finanziell gestemmt werden.

• Komplexität & Know-how-Bedarf: Ein so großes Projekt ist technisch und organisatorisch komplex. Möglicherweise fehlt intern zu Beginn das Know-how für das neue System. Die Lernkurve für Mitarbeiter ist steil, es braucht umfassende Schulungen. Bis alles rund läuft, kann es zu Effizienzverlusten im Tagesgeschäft kommen (z.B. anfangs mehr Supportfälle).

• Übergangsrisiken: Während der Migration läuft man mit zwei Systemen. Die Übergangsphase ist fehleranfällig – Daten müssen konsistent gehalten werden, Doppelarbeit kann entstehen (z.B. Berechtigung in altem und neuem System pflegen bei Parallelbetrieb). Mitarbeiter sind eventuell verwirrt durch zwei Ausweise oder geänderte Prozesse. Ohne straffes Management kann hier Chaos entstehen.

• Widerstände und Akzeptanz: Intern gibt es evtl. Widerstände gegen Veränderung – nach dem Motto "never change a running system". Besonders, wenn der bisherige Ablauf eingespielt war, können Sicherheitsmitarbeiter oder andere Betroffene die Notwendigkeit eines Wechsels in Frage stellen. Motivationsarbeit und Überzeugung sind nötig, sonst drohen Produktivitätsverluste oder sogar Sabotage der Neuerungen (im Sinne von Nicht-Nutzung der neuen Funktionen etc.).

• Abhängigkeit vom neuen Anbieter: Man begibt sich in eine neue Lieferantenbeziehung. Anfangs ist man auf den Support und die Kompetenz des neuen Herstellers stark angewiesen. Sollte dieser enttäuschen, hat man bisherige Beziehungen gekappt – eine kritische Phase, bis Vertrauen aufgebaut ist.

• Technologische Innovationssprünge: Das Projekt kann als Enabler für Innovation dienen. Man hat die Chance, gleich noch angrenzende Systeme zu modernisieren – z.B. die Einführung von biometrischen Zugängen an sehr sensiblen Bereichen, was vorher nicht möglich war, oder Mobile Access via Smartphone-App für flexible Officekonzepte. So kann das Unternehmen in der Sicherheitsinfrastruktur einen Sprung nach vorn machen, der auch zukünftige Trends (IoT, Smart Building) integriert.

• Prozessoptimierung konzernweit: Die Migration zwingt dazu, alle Prozesse rund um Zutritt, Besuchermanagement, Schlüsselverwaltung zu überdenken. Dadurch können Ineffizienzen aufgedeckt und behoben werden. Vielleicht erkennt man, dass man den Ausweiserstellungsprozess zentralisieren kann, oder dass man durch Analytics die Gebäudenutzung optimieren kann (wenn z.B. Zutrittsdaten zeigen, welche Räume kaum genutzt sind, was FM-Kosten beeinflusst).

• Stärkung der Sicherheitskultur: Durch die erhöhte Aufmerksamkeit auf das Thema Zugangssicherheit im Rahmen des Projekts kann generell die Awareness steigen. Mitarbeiter nehmen Sicherheitsschulungen ernster, weil sie sehen, es tut sich was. Evtl. führt die neue Technik (z.B. personalisierte Ausweise mit Foto, die vorzeigen zu müssen) zu einer besseren Sicherheitsdisziplin.

• Wettbewerbsvorteil: Wenn das Unternehmen z.B. in einer Branche tätig ist, wo Kunden oder Partner Wert auf nachgewiesene Sicherheit legen (etwa bei Aufträgen in der Verteidigungsindustrie, Pharma, etc.), kann ein modernes ZKS als Alleinstellungsmerkmal dienen. Zertifikate oder Auditergebnisse lassen sich nutzen, um Vertrauen zu vermarkten.

• Skaleneffekte international: Die Vereinheitlichung auf ein System über alle internationalen Standorte kann mittelfristig Kosten sparen (z.B. nur ein Schulungsprogramm, zentrale Lizenz statt diverser Insellösungen, besseres Volumen bei Hardwarekauf). Zudem ermöglicht es konsolidierte Sicherheitsrichtlinien weltweit umzusetzen, was sonst schwierig wäre.

• Projektverzögerungen und Kostenüberschreitungen: Wie bei vielen Großprojekten besteht das Risiko, dass Zeitplan und Budget nicht eingehalten werden. Unerwartete technische Probleme oder unterschätzter Aufwand können zu erheblichen Verzögerungen führen. Dies ist nicht nur finanziell problematisch, sondern verlängert auch den Zeitraum der doppelten Systemführung mit all den verbundenen Schwächen.

• Technisches Scheitern: Es besteht die Gefahr, dass das neue System nicht die Leistung oder Stabilität bringt wie erwartet. Sei es durch Softwarefehler, Unzuverlässigkeit der neuen Hardware oder unklare Anforderungen. Im schlimmsten Fall könnte das gesamte Projekt scheitern, was nicht nur verlorene Investitionen bedeutet, sondern auch die Sicherheit gefährden würde (wenn das alte System vielleicht schon abgebaut ist und das neue nicht funktioniert).

• Sicherheitslücken während der Umstellung: Kriminelle oder unbefugte könnten die Umstellungsphase auszunutzen versuchen. Beispielsweise, wenn Übergangsweise Sicherheitsprozesse gelockert sind (Tür offen während Umbau, Aufsicht vielleicht unkonzentriert). Oder falls es im neuen System anfangs Konfigurationsfehler gibt, könnten Sicherheitsvorfälle passieren (z.B. jemanden übersehen bei Rechteentzug). Solche Vorfälle könnten realen Schaden (Diebstahl, Spionage) verursachen und das Unternehmen haftbar machen.

• Negative Mitarbeiterreaktionen: Sollte die Einführung des neuen Systems schlecht laufen (viele Fehlalarme, oft Probleme beim Zutritt, z.B. Karte funktioniert nicht morgens, was Stau am Werkstor erzeugt), kann die Stimmung der Belegschaft leiden. Dies könnte sich in schlechterer Arbeitsmoral oder erhöhten Beschwerden niederschlagen. In extremen Fällen könnte auch der Betriebsrat intervenieren und Nachbesserungen erzwingen, was Druck auf das Projekt ausübt.

• Änderungen im externen Umfeld: Mögliche externe Risiken sind auch Marktänderungen – etwa der neue Hersteller wird übernommen oder gerät in finanzielle Schwierigkeiten, was Support unsicher macht. Oder gesetzliche Änderungen: Sollte z.B. kurz nach Implementierung eine neue Datenschutzregel strengere Auflagen machen, müsste man gleich wieder nachrüsten. Auch Eskalationen im Bereich Security (erhöhtes Terror-Risiko etc.) könnten dazu führen, dass plötzlich zusätzliche Anforderungen an das Zutrittskontrollsystem gestellt werden, die nicht eingeplant waren.

• Nicht-Erreichen des ROI: Wenn beispielsweise die erwarteten Einsparungen nicht eintreten (vielleicht muss doch mehr Personal bleiben als gedacht, oder neue laufende Kosten entstehen wie Cloud-Fees), könnte am Ende finanziell kein Vorteil entstehen. Dann würde das Projekt sich vor dem Management schwer rechtfertigen lassen und als Fehlschlag gelten.

Die SWOT-Analyse zeigt, dass dem Migrationsvorhaben bedeutende Stärken und Chancen gegenüberstehen, aber auch interne Schwächen und externe Risiken existieren, die es zu adressieren gilt. Eine sorgfältige Planung, Überwachung und Steuerung des Projekts ist daher unerlässlich, um Stärken zu nutzen und Risiken zu minimieren.

Im Folgenden wird eine Chancen- und Risikomatrix präsentiert, welche die wichtigsten Risiken der Migration und die damit korrespondierenden Chancen bzw. positiven Aspekte gegenüberstellt. Zudem werden Eintrittswahrscheinlichkeiten, potenzielle Auswirkungen sowie Maßnahmen skizziert. Diese Matrix dient der Übersicht und Bewertung der kritischen Erfolgsfaktoren.

Die Fortführung mit dem bisherigen Anbieter erscheint oberflächlich risikoärmer und kostengünstiger in der kurzen Frist, adressiert eventuell aber nicht die strategischen Langfristziele des Unternehmens. Gerade im Kontext KRITIS und einem sich rasant entwickelnden Technologiefeld ist Stehenbleiben oft auch ein Risiko – ein schleichendes, aber reales. Die Migration zu einem neuen System ist eine Investition in die Zukunftsfähigkeit und kann viele Vorteile bringen, birgt allerdings ein hohes Maß an initialer Herausforderung.

Abschließend lässt sich sagen, dass die Migration eines großflächigen, SAP-integrierten Zutrittskontrollsystems auf ein System eines anderen Herstellers zwar ein äußerst anspruchsvolles Vorhaben ist, jedoch mit gründlicher Planung und Durchführung bewältigt werden kann. Alle Aspekte – technisch, organisatorisch, kaufmännisch, juristisch – müssen ganzheitlich betrachtet und gemanagt werden, um einen erfolgreichen Ausgang zu gewährleisten.

Die Analyse hat gezeigt, dass ein modernes Zutrittskontrollsystem dem Unternehmen erhebliche Mehrwerte bieten kann: Steigerung der Sicherheit, Effizienzgewinne durch Automatisierung, bessere Compliance und Skalierbarkeit für zukünftige Anforderungen. Im Kontext deutscher Großindustrie und KRITIS kommt hinzu, dass aktuelle Bedrohungslagen und regulatorische Vorgaben den Einsatz von State-of-the-Art-Sicherheitslösungen nahezu unerlässlich machen. Ein Systemwechsel oder der Ausbau ermöglichen es, Security by Design neu aufzusetzen und Altsystem-Restriktionen hinter sich zu lassen.

Den Chancen stehen beträchtliche Risiken gegenüber – doch diese können durch ein strukturiertes Projektvorgehen, gutes Risk-Management und Einbindung aller Stakeholder deutlich reduziert werden. Die vorliegende Arbeit hat hierfür konkrete Empfehlungen gegeben, darunter die Definition von Stop-or-Go-Meilensteinen, an denen das Projekt auf Kurs geprüft wird, sowie die Erstellung einer Risikomatrix zur proaktiven Steuerung potenzieller Probleme. Besonders hervorgehoben wurde die Bedeutung der Pilotphase und der Einbeziehung von IT, HR, Facility und Rechtsabteilung von Anfang an, um technische und organisatorische Fallstricke frühzeitig zu erkennen.

Im direkten Vergleich mit der Alternative, das bestehende System durch Lieferantenentwicklung weiterzuführen, schneidet die Migrationsstrategie eventuell unter langfristigen und strategischen Gesichtspunkten besser ab. Kurzfristig mag die Beibehaltung verlockender erscheinen (weniger Umbruch, geringere Sofortkosten), doch würde sie die bestehenden Probleme evtl. nur verzögern und möglicherweise verschlimmern. Angesichts der Indikatoren für Veralterung (fehlende Updates, Erweiterungsgrenzen, Supportende) erscheint eine Ertüchtigung mit Blick auf die nächsten 5-10 Jahre unvermeidlich – und proaktiv geplant ist dieser deutlich kontrollierbarer, als zu warten, bis man eventuell unter Zugzwang gerät.

Das Zutrittskontrollsystem wird so zu einem Baustein, der Sicherheit, Compliance und Effizienz im Facility Management in Einklang mit den Geschäftsprozessen (SAP-Integration) optimal unterstützt. Die Transformation verlangt zwar Umsicht und Expertise, doch die gewonnenen Vorteile und die Abwendung zukünftiger Risiken rechtfertigen diesen großen Schritt.