Die Kernaussage zuerst: Unklare Rollen und Rechte sind oft der echte Grund, warum Projekte verzögern, Compliance kippt oder Mitarbeitende frustriert werden. Klingt banal? In meiner Beratungspraxis sehe ich das jeden Monat. Und meistens ist das Problem kein technisches, sondern ein organisatorisches.
Warum Rollen & Rechte mehr sind als ein IT-Thema
Haben Sie je erlebt, dass ein Projekt stockt, weil «jemand» Entscheidungen blockiert? Rollen und Rechte betreffen Prozess, Sicherheit und Verantwortung zugleich. Wenn unklar ist, wer entscheiden, prüfen oder freigeben darf, entstehen Lücken. Diese Lücken kosten Zeit, Geld und Vertrauen. Was ich dabei sehe: Teams delegieren Verantwortung an «die IT» oder an «die Geschäftsleitung» – und genau dort bleibt sie liegen.
Die drei typischen Fehler, die wirklich schmerzen
Rollen nur technisch abgebildet: Berechtigungen werden in Gruppen oder Listen in einem System angelegt, ohne dass dokumentiert ist, welche Geschäftsaufgabe dahintersteht. Ergebnis: Zugriff stimmt technisch, aber niemand fühlt sich verantwortlich. Rollen per Ad-hoc-Entscheidung: Mitarbeitende bekommen Rechte «weil sie es gerade brauchen», ohne Prozess für Rückgabe oder Review. Nach einem Jahr hat jeder zu viele Freigaben — und keiner weiss mehr, warum. Keine Verantwortlichen für Rollenpflege: Wer aktualisiert Rollen bei Stellenwechseln, Kündigung oder Prozessänderung? Fehlt diese Verantwortung, bleiben veraltete Rechte hängen – ein Compliance-Risiko.
Wie Rollen, Rechte und Governance zusammenhängen
Stellen Sie sich Rollen & Rechte als Steuerungselemente Ihres Unternehmens vor. Sie sind nicht nur Zugangssteuer, sondern Governance: Wer prüft, wer genehmigt, wer auditiert? In meiner Arbeit hilft es, Rollen entlang konkreter Prozesse zu definieren (z. B. Rechnungsfreigabe, HR-Onboarding). So wird klar: Die Rolle «Rechnungsprüfer» ist nicht bloss ein IT-Label, sondern eine Geschäftsaufgabe mit klaren Pflichten.
Fragen statt Vorschriften – so sprechen Sie mit Ihrem Team
Kennen Sie die Reaktion: «Das ist kompliziert, wir regeln das später»? Fragen helfen mehr als Befehle. Fragen Sie Ihr Team: Wer braucht welchen Zugang für welche Aufgabe? Wer überprüft, dass Zugänge noch gerechtfertigt sind? Was passiert, wenn jemand ausfällt? In meinen Workshops sind solche Fragen der Startpunkt – und sie offenbaren oft Überraschendes: versteckte Prozesse, übernommene Sonderrechte, fehlende Kontrollen.
Schnell wirkt: Praktische Ansätze, die wirklich etwas bewegen
Sie brauchen keine monatelange Oracle-Initiative. Beginnen Sie klein und konkret: identifizieren Sie kritische Geschäftsprozesse, ordnen Sie klare Rollen zu, legen Sie einfache Genehmigungswege fest. Eine regelmässige Rollenprüfung (quarterly oder halbjährlich) ist oft wirksamer als komplizierte technische Lösungen. Und: Dokumentation darf simpel sein. Ein einziges, gepflegtes Spreadsheet oder ein zentrales Wiki ist besser als zehn verwaiste Dateien.
Konkrete Fehlerbeispiele aus Projekten
Fall 1: Ein KMU gab allen Projektleitern Admin-Rechte, damit Entscheidungen schneller gingen. Ergebnis: Sicherheitsvorfälle und Abstimmungschaos bei Releases. Ursache: Rechte ohne Prozessverantwortung. Fall 2: Bei einer Fusion übernahm die IT die bestehende Rechtevergabe beider Firmen, ohne Rollen zu harmonisieren. Folge: Doppelrollen, widersprüchliche Zuständigkeiten und Verzögerungen bei der Konsolidierung. Fall 3: Ein Team verteilte temporäre Zugriffe per E-Mail. Niemand löschte sie wieder. Monate später waren externe Berater noch immer mit Systemzugang aktiv.
Konnten Sie in diesen Beispielen Parallelen zu Ihrer Organisation erkennen?
Handlungsanleitung für die nächsten 14–30 Tage (konkret und umsetzbar) Tag 1–3: Identifizieren Sie 3 kritische Geschäftsprozesse (z. B. Rechnungsfreigabe, Nutzer-Onboarding, Produktfreigabe). Schreiben Sie kurz auf, welche Aufgaben jeweils nötig sind. Tag 4–7: Definieren Sie für jeden Prozess 2–4 Rollen (z. B. Prüfer, Genehmiger, Ausführender). Notieren Sie, welche Entscheidung oder welchen Zugriff jede Rolle zwingend braucht. Tag 8–12: Ernennen Sie für jede Rolle eine verantwortliche Person (Rollen-Owner). Diese Person prüft Zugangsberechtigungen und Änderungen. Tag 13–18: Führen Sie eine Stichprobe durch: Prüfen Sie 10 existierende Konten/Rechte gegen die neuen Rollen. Welche Rechte sind überflüssig? Wer hat temporäre Zugriffe? Tag 19–24: Vereinbaren Sie einen einfachen Review-Prozess: quartalsweise Role-Review durch die Rollen-Owner. Legen Sie fest, wie temporäre Rechte vergeben und entzogen werden. Tag 25–30: Dokumentieren Sie die Ergebnisse in einem einfachen, zentralen Dokument (Spreadsheet oder Wiki). Kommunizieren Sie die ersten Änderungen an alle Betroffenen und holen Sie Feedback ein.
Wollen Sie dabei Unterstützung? Ich gebe gern eine kurze Vorlagen-Checkliste oder schaue mir Ihre initiale Rollenliste an. Was wäre für Sie der wichtigste Prozess, den Sie zuerst angehen möchten?
