Euer Identity-Access-Managment-Projekt ist nicht gescheitert. Es hat nur sichtbar gemacht, was vorher niemand aussprechen und entscheiden wollte. Ich sage es, wie es ist: 80 % aller Identity-Management-Projekte scheitern nicht an der Technik. Sie scheitern an euch, an eurer Organisation, an euren ungeklärten Zuständigkeiten, an Entscheidungen, die seit Jahren niemand treffen will. IAM ist nur das Brennglas.
Wir begleiten seit Jahren Unternehmen bei der Einführung zentraler Berechtigungssysteme. Und das Muster ist immer dasselbe: Das Projekt startet mit Architektur-Workshops, Tool-Evaluierungen und Konnektor-Konzepten. Alle sind motiviert. Dann kommt Phase 2, das Rollendesign, und plötzlich wird es still.
Warum? Weil Rollendesign bedeutet: Wir müssen definieren, wer was darf. Und damit definieren wir, wer was nicht mehr darf. Das ist kein IT-Thema. Das ist ein Machtthema, in manchen Organisation Silo A gegen Silo B.
Hier sind die fünf Wahrheiten, aus unserer Praxis.
Das Tool ist irrelevant
SailPoint, Tenfold, Omada. Alles solide Produkte. Keines davon löst euer Problem, wenn ihr nicht wisst, wer in eurem Unternehmen entscheiden darf, welche Rechte ein Sachbearbeiter in der Schadenregulierung braucht. Ihr kauft ein Schlüsselsystem, aber keinen Raumplan. Das IAM-Tool verwaltet Schlüssel – aber welche Person welche Tür öffnen darf, definiert nur euer Rollenmodell.
Rezertifizierung ist nur eine Show
Jedes Quartal klicken Führungskräfte auf „Bestätigen“ bei einer Liste von Berechtigungen, die sie nicht verstehen, für Mitarbeiter, deren aktuelle Aufgaben sie nicht kennen, in Systemen, von deren Existenz sie zum ersten Mal hören. Das ist keine Kontrolle. Das ist Compliance-Simulation. Und jeder Prüfer, der diesen Prozess akzeptiert, macht sich mitschuldig.
Eure „historische gewachsenen“ Berechtigungen sind kein Erbe, sie sind technische Schulden
Jeder Mitarbeiter, der die Abteilung gewechselt hat und seine alten Rechte behalten durfte, ist eine offene Flanke. Nicht irgendwann. Jetzt. Das kumulative Risiko aus zehn Jahren „lassen wir ihm erstmal, er braucht das vielleicht noch“ ist in den meisten Unternehmen so groß, dass ein ehrliches Berechtigungsaudit den Vorstand nervös machen muss. Zu Recht, laut BaFin ist selbst bei Finanzinstituten die strenge Vorgaben schon viele Jahre haben, nicht erst seit DORA, bei jeden zweiten Institut das Berechtigungsmanagement mit gewichtigen oder schwerwiegenden Mängeln implementiert.
IAM-Projekte ist Organisationsentwicklung, die zu oft als IT-Projekt behandelt werden
Kein CIO wird dem Vorstand sagen: „Wir machen ein Projekt zur Klärung von Zuständigkeiten, Machtstrukturen und Entscheidungsblockaden.“ Aber genau das passiert, wenn man ein zentrales Berechtigungssystem einführt. Der Projektantrag heißt „IAM-Implementierung“, die Realität heißt „Wir zwingen jede Abteilung, ihre Verantwortung schwarz auf weiß zu dokumentieren.“ Wer das nicht versteht, plant ein Zwölf-Monats-Projekt und wundert sich nach 24 Monaten, warum er noch in Phase 2 steckt.
Der teuerste Satz im IAM-Projekt „Das klären wir später“
Jede Entscheidung, die im Rollendesign vertagt wird, blockiert nicht eine Applikation, sondern jede Applikation, die auf dieses Rollendesign aufsetzt. In einer Factory mit 200 anzubindenden Applikationen kostet eine einzige vertagte Designentscheidung Wochen. Nicht weil die Technik wartet, sondern weil niemand weitermachen kann, ohne zu wissen, ob der Teamleiter Schadenregulierung auch Zahlungen freigeben darf.
Was funktioniert stattdessen?
Drei Dinge, die kein Budget kosten, aber fast nie passieren:
Vor dem ersten Architektur-Workshop eine Entscheidungsmatrix aufsetzen, die regelt, wer Rollenkonflikte final entscheidet. Mit Namen, nicht mit Organigramm-Kästchen. Wer „der Fachbereich entscheidet“ schreibt, hat schon verloren, weil „der Fachbereich“ keine E-Mail-Adresse hat.
Jede Applikation, die angebunden werden soll, muss einen Application Owner benennen, der mandatiert ist, Rechte zu entziehen. Nicht zu vergeben. Vergeben kann jeder. Entziehen erzeugt Konflikt. Und genau dafür braucht es ein Mandat.
Aufhören, IAM als IT-Projekt zu staffeln. Das Projektteam braucht mehr Organisationsentwickler als Softwareentwickler für Konnektoren. Wer das Verhältnis umdreht, baut schnelle Schnittstellen zu Systemen, in denen niemand weiß, welche Rechte überhaupt vergeben werden sollen.
Wir erlebe es immer wieder die Technik steht nach drei Monaten. Die Organisation braucht 24 Monate oder blockiert sich bis zum Stillstand. Wer dieses Verhältnis bei der Planung ignoriert, erzeugt ein Projekt, das offiziell „in der Implementierung“ ist und inoffiziell an fehlenden Entscheidungen scheitert.
IAM ist der Moment, in dem eine Organisation ehrlich zu sich selbst sein muss.
Wer das verstanden hat, kann jedes Tool erfolgreich einführen. Wer das nicht verstanden hat, scheitert mit jedem.
Jetzt mehr im Video erfahren:
