PIAM lässt sich nicht vollständig im Voraus definieren. Die eigentlichen Anforderungen entstehen erst im Betrieb. Organisationen brauchen Tooling, das kontinuierliche Veränderungen aufnehmen kann, ohne an Zuverlässigkeit einzubüßen. Genau dafür ist IDfunction PIAM gebaut.
Jede große Organisation, die ein Physical Identity and Access Management System aufbauen möchte, startet mit derselben vernünftigen Annahme: Anforderungen definieren, Design abstimmen, aufbauen und in Betrieb nehmen. So werden die meisten ernsthaften Projekte durchgeführt. Das Problem ist, dass PIAM sich nicht wie ein Projekt verhält, das abgeschlossen werden kann — und diese Annahme bereitet dem gesamten Vorhaben still und leise eine Enttäuschung vor.
Der Grund liegt weniger in der Technologie als in der Ungewissheit. Wenn eine Organisation ein neues PIAM-System entwirft, muss sie die Sichtweisen vieler Menschen in Einklang bringen, die selten zusammen in einem Raum sitzen: Compliance, Regulierung, Sicherheit, IT, Facility Management, HR und die Geschäftsbereiche, die täglich mit den Zugangsregeln leben. Jeder von ihnen hat einen Teil des Bildes. Niemand hat das vollständige Bild. Und egal wie gründlich die Workshops sind — es ist nahezu unmöglich, das Denken aller Beteiligten zu Papier zu bringen, bevor der Aufbau beginnt.
Etwas Vorhersehbares passiert in dem Moment, in dem ein Design zu einem funktionierenden Produkt wird. Menschen sehen es, nutzen es und reagieren darauf — und die Reaktionen widersprechen dem, was sie in der Designphase gesagt haben. Jemand stellt fest, dass er einen Prozess nicht vollständig verstanden hat, als er ihn abgezeichnet hat. Jemand anderes hat jetzt eine bessere Idee, da das Produkt real ist. Und fast immer stellt sich heraus, dass eine als verbindlich erklärte Regel Ausnahmen hat.
Man hört es in Sätzen wie: „Ich sagte, dieser Genehmigungsschritt sei erforderlich, aber eigentlich kann man ihn in diesem Fall überspringen, und in jenem Fall — ehrlich gesagt in den meisten Fällen." Das ist kein Versagen der Sorgfalt. Es ist das natürliche Ergebnis einer Organisation, die herausfindet, was sie wirklich braucht, indem sie sich selbst beim Arbeiten beobachtet.
Bei einer kleinen Implementierung ist das eine kleine Unannehmlichkeit. Bei einer großen ist es das prägende Merkmal des Projekts. Das Hin und Her ist kein Zeichen dafür, dass etwas schiefgelaufen ist — es ist strukturell nicht vorherzusagen und hört nicht auf, wenn der Go-live erklärt wird. Der Umfang wächst weiter. Die Feinabstimmung geht weiter. Und der einzige Weg, damit umzugehen, ist Tooling, das flexibel genug ist, Veränderungen schnell aufzunehmen — zu den Bedingungen der Organisation, nicht nach dem Zeitplan des Entwicklungsteams.
Flexibilität allein reicht nicht aus, denn PIAM ist kein Bereich, in dem man Qualität gegen Geschwindigkeit eintauschen kann. Zugriffsentscheidungen haben Konsequenzen: eine Tür, die sich für die falsche Person öffnet, ein Badge, der aktiv bleibt, nachdem jemand das Unternehmen verlassen hat, eine Genehmigungskette, die still aufgehört hat, die Richtlinie widerzuspiegeln. Schnelle Veränderungen müssen mit der Zuverlässigkeit und Qualität einhergehen, die man normalerweise nur von gut getestetem Software bekommt.
Genau hier scheitern die meisten offensichtlichen Abkürzungen. Prototyping-Tools ermöglichen schnelles Arbeiten, wurden aber nie dafür gebaut, ein System zu betreiben, das man über Jahre hinweg prüfen und auf das man sich verlassen kann. No-Code-Plattformen versprechen Flexibilität, schränken einen aber in dem Moment ein, in dem ein Prozess über die vorgesehenen Grenzen hinausgeht. Die eigentliche Anforderung ist anspruchsvoller als beides: schnell ändern und dabei vertrauenswürdig bleiben.
Es hilft, ein PIAM-System als etwas mit einem Lebenszyklus zu betrachten — nicht mit einem Startdatum. Am Anfang ist die Änderungsrate hoch: Jede Woche bringt neue Anforderungen, Korrekturen und Kurskorrekturen. Im Laufe der Zeit, wenn die Organisation sich auf das konzentriert, was wirklich funktioniert, sinkt diese Änderungsrate. Schließlich erreicht das System eine Art Reife, in der es sich kaum noch verändern muss — und niemand es anfassen möchte, es sei denn, eine Compliance-Verpflichtung oder eine harte Regel zwingt dazu.
Dieser ausgereifte, veränderungsarme Zustand ist das Ziel. Aber der schwierige Teil ist der Weg dorthin. Ein PIAM-System von Grund auf aufzubauen und es durch die turbulente, veränderungsreiche Phase zu führen, bis die Änderungsrate gegen null geht, ist ein grundlegend anderes Problem als die Wartung eines bereits stabilen Systems. Ein bestehendes System zu verändern ist eine eigene Disziplin; ein brandneues System bis zu diesem Stabilitätspunkt zu bringen ist der Bereich, in dem die meisten Schwierigkeiten entstehen — und es ist das Problem, das IDfunction PIAM löst.
Ab dem ersten Tag ist das Wertvollste, was man einer Organisation geben kann, ein meinungsstarker Ausgangspunkt. Die meisten Unternehmen kommen mit umfangreichen Prozessdefinitionen und einer klaren Vorstellung davon, wie die Dinge funktionieren sollen. Aber diese Definitionen werden in der Regel innerhalb der IT verfasst, in einer Sprache, die darauf ausgelegt ist, ein gemeinsames internes Verständnis aufzubauen — und diese Sprache lässt sich nicht sauber in testbare, hochwertige Software übersetzen. Die Lücke zwischen „wie wir den Prozess beschreiben" und „wie sich der Prozess verhalten muss, um zuverlässig zu sein" ist der Punkt, an dem viele Projekte ins Stocken geraten.
IDfunction PIAM überbrückt diese Lücke mit gebrauchsfertigen Workflows und Vorlagen, die abbilden, wie die Arbeit tatsächlich abläuft: wie das Onboarding verläuft, wie Besuchergenehmigungen gehandhabt werden, wie das Ganze sauber in die DSGVO passt. Anstatt mit einem leeren Blatt und einem Stapel Dokumente zu beginnen, erhält jeder in der Organisation einen konkreten ersten Entwurf, auf den er reagieren kann. Das ist einer der wertvollsten Beiträge, die wir leisten — Menschen früh etwas Reales zu geben, mit dem sie arbeiten können, damit das unvermeidliche Hin und Her gegen ein funktionierendes System stattfindet und nicht gegen eine Präsentation.
Sobald ein Entwurf zur Verfeinerung vorliegt, sollte die Arbeit um den Prozess selbst gehen — nicht um technische Details. Ein No-Code-Workflow-Builder ermöglicht es Teams, Workflows anzupassen und zusammenzustellen, ohne Workflow-Ingenieure zu werden. Keine Vorannahmen zum Datenschema bedeuten, dass Organisationen nicht gegen das System ankämpfen müssen, was den Speicherort oder die Struktur von Informationen betrifft. Herstellerneutrale Integrationen in Multi-Vendor-Umgebungen ermöglichen das Einbinden und Synchronisieren von Daten, ohne alles um das Modell eines einzigen Anbieters herum neu aufzubauen.
Um diesen Kern herum liegen die Bausteine, die schnelle, zuverlässige Veränderungen praktikabel machen: Formular-Builder, Automatisierungen, geplante Aufgaben und KI-gestützte Konfiguration. Zusammen ermöglichen sie es einer Organisation, die veränderungsreiche Phase schnell zu durchlaufen, ohne die Zuverlässigkeit aufzugeben, die PIAM verlangt — genau die Kombination, die Prototypen und No-Code-Plattformen allein nicht liefern können.
Es gibt einen letzten Grund, der in diesem Zusammenhang wichtig ist — und den Organisationen in der Regel zu spät entdecken. Fast jedes Unternehmen kann ein fähiges Team einstellen, um schnell individuelle Software zu entwickeln. Die Liefergeschwindigkeit ist selten die eigentliche Einschränkung. Die Einschränkung ist die Unterstützung — dieses System über Jahre hinweg gesund und weiterentwickelt zu halten.
Ein talentiertes Projektteam ist von Natur aus schwer zu halten. Je besser die Mitglieder sind, desto wahrscheinlicher wechseln sie zum nächsten Projekt — und die Menschen, die die Logik des Systems verstanden haben, gehen mit ihnen. Ein Team, das an einem Produkt arbeitet, hat jeden Anreiz, es langfristig zu unterstützen und zu verbessern. PIAM als Produkt statt als einmalige individuelle Entwicklung zu behandeln ist der Unterschied zwischen einem System, das besser wird, und einem, das langsam zu einer Belastung wird, die niemand mehr vollständig versteht.
PIAM zu liefern ist keine punktuelle, sequenzielle Übung, bei der man den Umfang festlegt, den Zeitplan setzt und liefert. Es ist ein System, das sich mit den Bedürfnissen und dem sich verändernden Denken der gesamten Organisation weiterentwickelt — bis es zur besten Lösung für die Art und Weise konvergiert, wie diese Organisation tatsächlich arbeitet — und danach als Produkt langfristig weiter unterstützt wird.
Die Ungewissheit, die Widersprüche, das Hin und Her — nichts davon ist ein Fehler im Prozess. Es ist der Prozess. Die einzige wirkliche Frage ist, ob Ihr Tooling und Ihr Liefermodell dafür ausgelegt sind, eine Organisation durch ihn zu führen — von null bis zu einem System, das so gut passt, dass es sich kaum noch verändern muss. Dafür ist IDfunction PIAM.
PIAM lässt sich nicht vollständig im Voraus spezifizieren. Große Organisationen müssen Compliance, Regulierung, Sicherheit, IT und das Business in Einklang bringen — und kein Workshop erfasst das Denken aller Beteiligten vor Beginn des Aufbaus.
Die eigentlichen Anforderungen entstehen, sobald das System in Betrieb ist. Menschen widersprechen früheren Entscheidungen, stellen fest, dass sie etwas missverstanden haben, und entdecken, dass „verbindliche" Schritte Ausnahmen haben — oft in den meisten Fällen.
Bei großen Implementierungen ist dieses Hin und Her nicht vorherzusagen und hört nach dem Go-live nicht auf. Man braucht Tooling, das flexibel genug ist, schnell zu den Bedingungen der Organisation zu wechseln.
Geschwindigkeit allein reicht nicht aus. PIAM braucht die Zuverlässigkeit von gut getesteter Software. Prototypen sind nicht für den Dauerbetrieb gebaut, und No-Code-Plattformen schränken ein.
PIAM sollte als Lebenszyklus betrachtet werden: Die Änderungsrate ist zunächst hoch, sinkt dann, bis das System sich kaum noch verändert. Der schwierige Teil ist, ein brandneues System durch diese turbulente Phase bis zur Reife zu führen.
IDfunction startet mit einem meinungsstarken Entwurf — gebrauchsfertige Workflows und Vorlagen für Onboarding, Besuchergenehmigungen und DSGVO — damit Menschen ein funktionierendes System verfeinern, anstatt über Dokumente zu diskutieren.
Ein No-Code-Workflow-Builder, keine Vorannahmen zum Datenschema und herstellerneutrale Multi-Vendor-Integrationen — ergänzt durch Formular-Builder, Automatisierungen, geplante Aufgaben und KI-gestützte Konfiguration — halten den Fokus auf dem Prozess, nicht auf der Technik.
PIAM wird am besten als Produkt behandelt, nicht als individuelle Entwicklung. Projektteams sind schwer zu halten; ein Produktteam unterstützt und verbessert das System über Jahre hinweg.
