Bei der Migration von Zutrittskontrollsystemen können Datenlücken, Produktionsprobleme und Sonderfälle dazu führen, dass Ausweise nicht funktionieren. Der Beitrag zeigt drei typische Ursachen und wie sich Migrationen kontrollierter planen lassen.
Betrachten wir als Beispiel einen großen Industriepark: Ein Mitarbeiterausweis ist dort in den seltensten Fällen nur einem einzigen System zugeordnet.
Der Personaldatensatz hat seinen Ursprung möglicherweise in SAP, Active Directory oder einer HR-Plattform. Eine separate Anwendung speichert das Foto. Die Ausweisproduktionssoftware weist Kartendesign und Kodierprofil zu. Das physische Zutrittskontrollsystem überträgt die relevanten Informationen an Controller und Leser an mehreren Standorten. Derselbe Ausweis kann außerdem für Zeiterfassung, Secure Printing, Bezahlung oder Maschinenzugriff verwendet werden.
Häufig sind unterschiedliche interne Teams und externe Integratoren für einzelne Teile dieser Umgebung verantwortlich. Dabei gleicht kaum eine Systemlandschaft der anderen.
Während einer Migration müssen alle beteiligten Komponenten weiterhin zur richtigen Zeit die richtigen Informationen austauschen. Eine Störung an irgendeinem Übergabepunkt zeigt sich am Ende oft in einem scheinbar einfachen Symptom: Der Mitarbeiterausweis funktioniert nicht.
Nach unserer Erfahrung können mehrere Ursachen hinter diesem Symptom stecken. Drei davon verdienen bei der Planung einer Migration besondere Aufmerksamkeit.
Bei Migrationen von Zutrittskontrollsystemen kommen häufig geplante Importe, SFTP-Übertragungen, APIs, Verzeichnissynchronisierungen und Datenbankprozesse zum Einsatz. Ein technisch abgeschlossener Transfer führt jedoch nicht automatisch zu einem vollständigen operativen Ergebnis.
Wir haben Importdateien gesehen, die als verarbeitet gekennzeichnet waren, obwohl einzelne Datensätze weiterhin geprüft werden mussten. In einem anderen Fall wurde der zentrale Mitarbeiterdatensatz aktualisiert, während die zugehörige Standortzuordnung unverändert blieb. Doppelte Einträge haben die Synchronisierung einzelner Personen verhindert. Auch eine PIN ist bereits mit einem abweichenden Wert im Zutrittskontrollsystem angekommen, sodass der Ausweisinhaber das Gelände nicht betreten konnte.
Um solche Probleme zu erkennen, prüfen wir die Daten auf Feld- und Beziehungsebene. Wir erfassen, wie eine Person in der gesamten Systemlandschaft identifiziert wird, definieren das führende System für jedes relevante Feld und überprüfen, wie Änderungen an verknüpfte Datensätze weitergegeben werden.
Für UIDs, Kartennummern, Standorte, Profile, PINs und Ausweisstatus braucht es dokumentierte Zuordnungs- und Konvertierungsregeln. Das Monitoring muss außerdem zeigen, welche Datensätze fehlgeschlagen sind und ob sich ein Prozess sicher wiederholen lässt.
An diesem Punkt wird die Zusammenarbeit der Integratoren entscheidend. Der HR-Anbieter kann bestätigen, dass die richtigen Daten versendet wurden. Die Identity-Plattform kann bestätigen, dass die Person vorhanden ist. Beim Anbieter des Zutrittskontrollsystems kann trotzdem ein unerwarteter Wert ankommen. Um die Ursache zu finden, benötigen alle Beteiligten einen gemeinsamen Blick auf den vollständigen Datenweg.
Mitarbeiterstammdaten bilden nur einen Teil der Informationen ab, die für die Ausweisproduktion erforderlich sind.
Die Produktionsumgebung benötigt möglicherweise zusätzlich ein Foto, ein Ausweisprofil, ein Layout, eine UID, eine Credential-Zuordnung, einen Aktivierungsstatus und die bisherige Produktionshistorie. Manche dieser Informationen befinden sich noch in einer separaten Bildplattform oder im bisherigen Ausweisproduktionssystem.
Eine Person kann deshalb im neuen Verwaltungssystem korrekt angezeigt werden, während ihr Foto für die Produktion nicht verfügbar ist. Das erforderliche Ausweisprofil kann fehlen. Bestehende UIDs müssen möglicherweise noch importiert werden. Produktionsdaten können weiterhin ausschließlich in der vorherigen Umgebung liegen.
Auch die Reihenfolge der Migration spielt eine Rolle. Fotos, Personendatensätze, Profile und Credential-Zuordnungen müssen so übertragen werden, dass ihre Beziehungen erhalten bleiben. Das Projektteam muss außerdem festlegen, wie aktive, inaktive, verlorene und bereits produzierte Ausweise im Zielsystem abgebildet werden.
Die Produktion eines echten Ausweises ist deshalb ein wichtiger Migrationstest. Sie zeigt, ob der Mitarbeiterdatensatz zum richtigen Foto, Kartendesign, Kodierprofil und Ausweisstatus führt. Anschließend muss der produzierte Ausweis genau den Identifikator bereitstellen, den das Zutrittskontrollsystem erwartet.
Das reguläre Onboarding erhält bei der Planung meist die größte Aufmerksamkeit. Ersatzausweise, Statusänderungen und andere Lifecycle-Ereignisse bringen fehlende Abhängigkeiten häufig schneller ans Licht.
Verliert ein Mitarbeiter seinen Ausweis, bleiben seine persönlichen Daten möglicherweise unverändert. Die Ersatzanforderung muss dennoch den bisherigen Ausweis deaktivieren oder ersetzen, einen neuen Produktionsauftrag auslösen, das richtige Profil anwenden und den neuen Identifikator an das Zutrittskontrollsystem übertragen.
Wir haben bereits erlebt, dass eine Ersatzanforderung den Integrationsprozess erreichte, ohne einen neuen Produktionsauftrag auszulösen. Da sich keine persönlichen Daten geändert hatten, behielt der Produktionsstatus seinen vorherigen Wert. Der nachgelagerte Prozess erkannte deshalb nicht, dass der Ausweis erneut produziert werden musste.
Ähnliche Probleme können entstehen, wenn ein Mitarbeiter den Standort wechselt, ein Credential deaktiviert wird, ein temporärer Ausweis keinen dauerhaften Inhaber hat oder eine bestehende Karte eine weitere RFID-Applikation erhält.
Diese Prozesse überschreiten mehrere Verantwortungsbereiche. Das Identity-Team verwaltet Personen- und Credential-Datensätze. Das Produktionsteam steuert Druck und Kodierung. Der Zutrittsintegrator betreut das Zielsystem. Ein weiterer Partner kann für Leser, Controller und physische Zutrittspunkte verantwortlich sein.
Jeder Prozess benötigt deshalb einen klar definierten Auslöser, eine erwartete Systemreaktion und einen verantwortlichen Ansprechpartner. Migrationstests sollten neben dem ersten erfolgreichen Pilot-Ausweis auch häufige Sonderfälle abdecken. Damit stellt sich ebenfalls die Frage nach dem führenden System. Dieses Thema verdient jedoch einen eigenen Beitrag.
Zwei bereits veröffentlichte evolutionID-Projekte zeigen, wie sich diese Abhängigkeiten beherrschen lassen, während Ausweisproduktion und Zutrittsbetrieb weiterlaufen.
In einer Umgebung mit mehreren Standorten stammten die Mitarbeiterdaten aus SAP und versorgten eine zentrale Identity-Management-Plattform. Fotos, Zutrittsrechte, Ausweisapplikationen und Produktionsprozesse mussten über die dezentralen Standorte hinweg aufeinander abgestimmt bleiben. Bestehende und neuere Lesertechnologien waren gleichzeitig im Einsatz. Multitechnologie-Credentials ermöglichten deshalb einen schrittweisen Rollout.
In einem weiteren Projekt wurde eine neue Identity- und Ausweisproduktionsumgebung in ein bestehendes physisches Zutrittskontrollsystem integriert. Vorhandene Mitarbeiterfotos wurden migriert und ein Bestand vorkodierter MIFARE-DESFire-Karten weiterverwendet. Nachdem dieser Bestand aufgebraucht war, übernahm die neue Umgebung den vollständigen Kodierungsprozess. Auch UID-Konvertierungen, Nummernkreise und Schnittstellen zu Secure Printing waren Teil des Projekts.
Beide Projekte folgten denselben praktischen Grundsätzen: geeignete bestehende Komponenten weiterverwenden, die Migration in kontrollierte Phasen aufteilen und sich kontinuierlich mit den beteiligten Zutritts- und Technologiepartnern abstimmen.
Am Anfang steht ein präzises Bild der bestehenden Umgebung. Dazu gehören Identity-Quellen, Ausweisproduktionssysteme, RFID-Technologien, Credential-Applikationen, Integrationen in die Zutrittskontrolle und die dazugehörigen Betriebsprozesse.
TAG-Analyzer unterstützt die technische Analyse vorhandener RFID-Credentials. Das Tool dokumentiert unter anderem Kartentechnologie, UID, Applikationen und zugängliche Daten. Auf dieser Grundlage lässt sich bestimmen, welche Ausweisgruppen weiterverwendet werden können, welche aktualisiert werden müssen und bei welchen ein Austausch erforderlich ist.
Anschließend bildet das Migrationsteam die Beziehungen zwischen den Systemen ab. Es legt für jedes Datenelement das führende System, die erforderlichen Transformationen und die erwarteten Reaktionen auf Ereignisse wie Onboarding, Ersatz und Deaktivierung fest.
Wenn bestehende Credentials technisch für die weitere Nutzung geeignet sind, kann IDkiosk eine kontrollierte Aktualisierung oder Neukodierung unterstützen. Der Rollout kann anschließend in definierten Migrationsgruppen erfolgen. Nach jeder Phase werden die Daten abgeglichen, die Ausweisproduktion getestet und repräsentative Zutrittspunkte überprüft.
evolutionID behält während des gesamten Projekts den Überblick über Identity-Daten, Ausweisproduktion, RFID-Credentials und die Integration in das Zutrittskontrollsystem. Wir arbeiten mit den Integratoren für HR-Systeme, Zutrittskontrolle, Leser, Controller und Standortinfrastruktur zusammen, damit Entscheidungen über die gesamte Umgebung hinweg aufeinander abgestimmt bleiben.
Das Gesamtsystem im Blick behalten
Komplexe Migrationen von Zutrittskontrollsystemen verbinden Technologien und Verantwortungsbereiche, die über viele Jahre gewachsen sind.
evolutionID vereint Erfahrung in Identity Management, Ausweisproduktion, RFID-Analyse, Credential-Aktualisierung und Systemintegration. So können wir Abhängigkeiten frühzeitig erkennen, die beteiligten Spezialisten koordinieren und eine Migration planen, die den laufenden Ausweis- und Zutrittsbetrieb schützt.
