IAM-Beratung:
Warum Die eigentliche
Arbeit vor der
Technik beginnt

IAM. konkret. verständlich.
Umgesetzt.

Wenn Unternehmen ein IAM-Projekt starten, denken die meisten an Software, Lizenzen und Implementierung. Das ist nachvollziehbar, aber es greift zu kurz. Ein IAM-Projekt ist in erster Linie ein Organisationsprojekt mit technischem Anteil. Es berührt Prozesse, Verantwortlichkeiten und Etnscheidungsstrukturen in Bereichen, die auf den ersten Blick wenig mit IT zu tun haben: HR, Fachbereiche, Compliance, Revision, manchmal auch der Betriebsrat. Entscheidend ist nicht nur, welches System am Ende steht – sondern vor allem, was vorher geklärt wird. Und was nachher funktionieren muss.

Was vor dem Projekt passieren Muss; und was die Meisten überspringen

Die Phase vor dem eigentlichen Projektstart entscheidet über den Verlauf des gesamten Vorhabens. In der Praxis wird sie regelmäßig abgekürzt oder übersprungen – nicht aus Nachlässigkeit, sondern weil vielen Unternehmen schlicht nicht klar ist, was in dieser Phase zu tun wäre.

Bevor ein IAM-System irgendetwas steuern kann, braucht es eine verlässliche Quelle für Identitäten und deren Attribute, Vor- und Nachname, Abteilung, Standort, Rolle, Eintrittsdatum, Vorgesetzter. In den meisten Unternehmen ist das HR-System diese Quelle. Aber in der Realität sind die Daten dort oft unvollständig, veraltet oder nicht für IAM-Zwecke strukturiert. Externe Mitarbeitende, Dienstleister oder Berater tauchen im HR-System häufig gar nicht auf.

Wenn diese Grundlage nicht stimmt, scheitert das Projekt nicht an der Technik, sondern an den Daten, die sie füttern. Ein IAM-System kann nur so gut steuern, wie die Informationen sind, die es bekommt.

Ein pragmatischer erster Schritt: Prüfen Sie, ob Ihr HR-System heute vollständig und aktuell genug ist, um als führendes System für Identitäten zu dienen. Wenn nicht, ist das kein Showstopper, aber es muss vor Projektstart adressiert werden, nicht währenddessen.

Was in der Praxis oft unterschätzt wird: Viele Unternehmen können ihre eigenen Zugriffsprozesse nicht vollständig beschreiben. Wer beantragt heute wie einen Zugang? Wer genehmigt ihn? Was passiert, wenn jemand die Abteilung wechselt, werden die alten Rechte entzogen? Wer ist verantwortlich für die Berechtigungen in einer bestimmten Anwendung?

In den meisten Fällen gibt es darauf keine einheitliche Antwort, sondern viele verschiedene, je nach Abteilung, System oder Einzelperson. Das ist keine Ausnahme, sondern der Normalfall. Aber es muss vor der Implementierung sichtbar gemacht werden. Ein IAM-System kann Prozesse automatisieren, aber nur Prozesse, die definiert sind.

Es kommt regelmäßig vor, dass Unternehmen bereits eine Produktentscheidung getroffen haben, bevor die Anforderungsanalyse abgeschlossen ist, manchmal sogar bevor sie begonnen hat. Die Gründe sind vielfältig: ein Hersteller hat ein überzeugendes Versprechen gemacht, eine Empfehlung kam aus dem Netzwerk, oder der Einkauf hat den günstigsten Anbieter gewählt.

Die Konsequenz: Wenn das Produkt feststeht, bevor die Anforderungen klar sind, wird die Beratung zur Anpassungsübung. Statt die passende Lösung für die eigenen Prozesse zu finden, werden die eigenen Prozesse an die Möglichkeiten des Produkts angepasst. Das funktioniert in manchen Fällen. In vielen führt es zu einem Projekt, das deutlich teurer und langwieriger wird als geplant.

Unser Rat: Halten Sie die Produktentscheidung offen, bis Sie wissen, was Sie tatsächlich brauchen. Das ist der wichtigste einzelne Hebel, den Sie haben.

Wie ein IAM Projekt in der Praxis abläuft; und wo es kritisch wird

Gemeinsam mit Ihnen klären wir, wo Sie stehen und wohin Sie wollen. Das klingt selbstverständlich, ist es aber nicht. Die Analyse umfasst nicht nur technische Bestandsaufnahme, sondern vor allem: Welche Prozesse existieren? Welche Rollen und Verantwortlichkeiten sind definiert, und welche nur informell gewachsen? Wo liegen Ihre größten Risiken?

Ergebnis: Ein dokumentiertes Zielbild und eine ehrliche Einschätzung des Aufwands. Keine Hochglanz-Roadmap, sondern ein Fahrplan, der die Realität Ihres Unternehmens abbildet.

Hier werden die Anforderungen in ein konkretes Lösungsdesign übersetzt. Rollen- und Berechtigungskonzepte entstehen, Joiner-Mover-Leaver-Prozesse werden definiert, Schnittstellen zu Quell- und Zielsystemen werden geplant.

Kritischer Punkt: In dieser Phase zeigt sich häufig, dass die Anforderungen umfangreicher sind als ursprünglich angenommen. Was als Standardprojekt gestartet ist, wird zur Customizing-Lösung, nicht weil jemand einen Fehler gemacht hat, sondern weil die tatsächliche Komplexität erst bei genauem Hinsehen sichtbar wird. Das ist normal. Aber es muss offen kommuniziert werden, damit Budget und Zeitplan angepasst werden können.

Die technische Umsetzung. Was hier entscheidend ist: Die Startphase ist die erste kritische Phase im Projekt. In den ersten Wochen tauchen fast immer zusätzliche Anforderungen auf, werden Abhängigkeiten sichtbar, die vorher nicht erkannt wurden. Das liegt nicht an schlechter Vorbereitung, sondern daran, dass manche Dinge erst sichtbar werden, wenn sie technisch konkret werden.

Was das für Sie bedeutet: Planen Sie Puffer ein, zeitlich und finanziell. Nicht weil etwas schiefgeht, sondern weil ein gewisses Maß an Nachjustierung zum normalen Projektverlauf gehört.

Hier liegt eine der häufigsten Bruchstellen. Tests scheitern regelmäßig nicht an der Technik, sondern daran, dass Fachbereiche ihre Prozesse nicht klar genug definiert haben, um Testfälle ableiten zu können. Wenn nicht klar ist, wie ein Prozess laufen soll, kann auch nicht getestet werden, ob er korrekt funktioniert.

Die letzte Phase vor dem GoLive ist erfahrungsgemäß die zweite kritische Phase. Hier verdichten sich offene Punkte, Unsicherheiten steigen, und häufig gibt es Widerstände in der Organisation. Mitarbeitende, die jahrelang Berechtigungen auf dem kleinen Dienstweg bekommen haben, müssen sich an neue Prozesse gewöhnen. Admins befürchten manchmal, dass ein automatisiertes System ihre Rolle entwertet.

Diese Widerstände sind menschlich verständlich und kein Zeichen für ein schlechtes Projekt. Aber sie müssen aktiv adressiert werden, durch Kommunikation, Schulung und eine Einführungsstrategie, die nicht nur die Technik, sondern auch die Menschen berücksichtigt.

Was nach dem Projekt passieren muss – und was die meisten vergessen

In vielen Projekten wird der Betrieb als letzter Punkt auf der Liste behandelt, oder gar nicht. Das Projektteam geht, die Organisation bleibt mit einer Lösung zurück, die sie nicht vollständig versteht. Updates werden verschoben, Konfigurationsänderungen laufen über Einzelpersonen, Dokumentation fehlt.

Nach ein bis zwei Jahren steht das Unternehmen vor einer Umgebung, die funktioniert, aber die niemand mehr sicher anfassen kann. Das ist der Moment, in dem ein Health Check oder ein externer Betrieb relevant wird.

Entscheidend ist: Planen Sie den Betrieb nicht am Ende des Projekts, sondern am Anfang. Wer wird die Lösung betreiben? Mit welchem Know-how? Welche Prozesse müssen für den laufenden Betrieb definiert sein? Diese Fragen gehören in die Konzeptionsphase, nicht in die letzte Projektwoche.

Nach dem GoLive beginnt die eigentliche Bewährungsprobe: Werden Rezertifizierungen durchgeführt? Prüfen die Verantwortlichen tatsächlich, ob die Berechtigungen noch passen, oder haken sie Listen ab, ohne hinzusehen? Gibt es einen Prozess für den Fall, dass jemand die Abteilung wechselt und alte Rechte liegen bleiben? Wenn diese Prozesse nicht gelebt werden, ensteht über Monate ein schleichender Rechtezuwachs, den niemand aktiv gesteuert hat. Im Tagesbetrieb fällt das nicht auf. Bei einem Audit oder einem Sicherheitsvorfall wird es zur Belastung.

Was sie durch unsere Beratung konkret gewinnen

  • Entscheidungen auf Basis einer vollständigen Analyse, nicht auf Basis von Annahmen oder Herstellerversprechen.
  • Ein Projektverlauf mit weniger Überraschungen – weil die typischen Bruchstellen frühzeitig adressiert werden.
  • Realistische Zeit- und Budgetplanung – weil wir den tatsächlichen Individualisierungsgrad von Anfang an einschätzen.
  • Nachweisfähigkeit gegenüber Revision Compliance, dokumentiert, nachvollziehbar, auditfest.
  • Eine Organisation, die die Lösung nach Projektende betreiben kann – weil der Betrieb von Anfang an mitgedacht wird.

Unsere Kompetenzfelder

  • Identity & Access management (IAM / IDM / IGA)
  • Privileged Access Management (PAM)
  • Cloud-basierte IAM-Lösungen (Public & Private Cloud)
  • Konzeption und Implementierung von IAM-Umgebungen
  • Betrieb von IAM-Umgebungen
  • Berechtigungskonzepte und Rollenmodelle
  • Compliance und Segregation of Duties (SoD)
  • Analyse von Geschäftsprozessen im IAM-Kontext
  • IAM Health Check (Performance & Konfiguration)
  • Optimierung bestehender IAM-Umgebungen