01 · AUSGANGSLAGE
Kontext & Problemstellung
Photovate ist eine Branchensoftware (ERP) für Solar- und PV-Installationsbetriebe. Photovate 1.0 nutzt ein starres Role-Based-Access-Control-System (RBAC): Berechtigungen sind fest an vordefinierte Rollen gekoppelt und lassen sich weder unternehmens- noch personenspezifisch anpassen.
Kernprobleme
Komplexes Berechtigungskonzept und schlechte Übersicht
Die Kunden haben keine Übersicht über die Berechtigungen, die mit den Rollen zusammenhängen
Unpassende Beschreibung der Rollen
Die Kunden können sich unter den Rollenbezeichnungen nicht wirklich was vorstellen. Beispiel: Rolle “editor” oder Unterschied “Vertrieb” und “Vertrieb+”
Zu viele Rollen
Insgesamt zu viele Rollenoptionen
Unflexibles Berechtigungssystem
Berechtigungen können nicht von den Kunden angepasst werden
Ich sehe einer Rolle einfach nicht an, was sie darf. Und wenn ich etwas ändern will, muss ich es komplett neu denken.
Geschäftsführung, Solarunternehmen
Wir wachsen halt und es entstehen dauernd neue Strukturen (…) Dadurch, dass wir halt dauernd uns neu organisieren, ändert sich die Berechtigung die ganze Zeit.
Geschäftsführung, Solarunternehmen
Altes Rollen und Berechtigungssystem in Photovate 1.0
02 · VERANTWORTUNG
Meine Rolle & Team
Eigenständig
Planung und Durchführung der Research mit Hypothesenbildung, Wettbewerbsanalyse, Leitfaden Aufbau, Rekrutierung, Durchführung und Auswertung
Aufbereitung und Leitung von Entscheidungsworkshops auf inkl. Aufbereitung einer konkreten Handlungsempfehlung
Konzeption und Prototyping inkl. der verschiedenen Zugriffsberechtigungskombinationen auf jede Modulebene
Durchführung der Qualitätskontrolle (QA)
Im Team
Briefing vom Product Team
Gemeinsam mit dem Product Team und dem C-Level in zwei Entscheidungsworkshops (04.12. & 13.12.2024) die Research-Insights in ein konkretes, MVP-fähiges Konzept übersetzt
03 · Prozess
Herangehensweise
1
Interner Kick-Off
Hypothesen in internen Interviews mit C-Level, Customer Success, Tech Support & Marketing geschärft.
2
Wettbewerbsanalyse
Deep Research zu bestehenden Berechtigungssystemen und Clusterung (RBAC, MAC, …)
3
Externe Interviews
11 Interviews mit Bestandskunden inkl. Skalen-Einschätzung (sowohl Admins, als auch spezifischen Rollen) zur Identifizierung der Anforderungen.
4
Basierend auf der Auswertung Insights mit dem Product-Team gegen technische Machbarkeit & MVP-Scope abwägen.
5
Prototyping
Aufbau und Verantwortung eines flexiblen Rollen basierten Berechtigungskonzepts mit Implementierung der Berechtigungen auf jeder Ebene.
Affinity Mapping, um die häufigsten Standardrollen zu evaluieren
Brainstorming und Notizen vom Entscheidungworkshop (04.12.2024)
04 · Entscheidungen
Zentrale Entscheidungen
05 · Lösung
Das finale Modul
Kern Insights
Zuweisung muss flexibel sein, aber schnell
Berechtigungen müssen anpassbar sein, aber es sollte nicht bei jeder Einladung neu vergeben werden müssen.
Minimale Ansicht
Die User sollen nur die Module sehen, wo sie auch Aktionen machen können (ansonsten zu unübersichtlich und verwirrend)
Möglichkeit für multiple Hierarchiestufen geben
Lösung für Abteilungsleiter mitdenken (sollen nicht auf alle Datensätze zugreifen, sondern nur auf die aus der Abteilung
Extra Berechtigungen für sensible Daten
Sensible Unternehmensdaten wie Einkaufspreise oder Margen brauchen eine extra Berechtigungseinstellung
Lösung
Mischung aus RBAC (Role-Based-Access-Control) und MAC (Mandatory Access Control)
8 editierbare Standardrollen Templates, die in 80% der Interviews genannt wurden
2 Berechtigungsdimensionen:
Interaktionsrecht (lesen / bearbeiten)
Zugriffsradius (Keine/ nur eigene / Abteilung / alle)
Nur Admins und Owner können Berechtigungen einstellen (Owner hat Kontrolle über Admins)
Modulares Berechtigungssystem: Module können komplett an- oder ausgeschaltet werden, innerhalb der Module gibt es extra Berechtigungseinstellungen (z.B. Einkaufspreis)
Mit der Berechtigungsoption "Aus Abteilung" gibt es die Möglichkeit Hierarchiestufen aufzubauen (optional)
Drei Orte im System
Die Rollenberechtigungen können über drei Ebenen im Workflow gesteuert werden. Nur die Rollen Owner und Administrator (mehrere möglich) können auf diese drei Ebenen zugreifen, damit eine zentralisierte Steuerung gewährleistet ist.
1
Berechtigungs-Ebene
In den Einstellungen, hier ist der Ort, an dem Rollen, Templates & Berechtigungen global auf modularer Ebene bearbeitet werden.
2
Einladung
Bei einer Mitarbeitereinladung muss eine Rolle vergeben werden. Nur bestehende Rollen sind zuweisbar, kein Erstellen neuer Rollen. Das hält den Einladungsprozess schnell.
3
Mitarbeiter-Ebene
Auf der Mitarbeiterebene können Rollen nachträglich pro Mitarbeiter bearbeitet werden. Ebenfalls können hier Abteilungen optional gesetzt und hierarchisch aufgebaut werden.
07 · REFLEXION
Was ich mitnehme
Die zentrale Herausforderung bestand darin, die unterschiedlichen Komplexitätsanforderungen von kleinen und großen Unternehmen in einem konsistenten Konzept zu vereinen. Während größere Organisationen granulare Berechtigungen und Hierarchien benötigen, erwarten kleinere eine schnelle und einfache Vergabe. Die wichtigste Erkenntnis: Standards sollten möglichst schlank für den 80 %-Use-Case gestaltet sein, ergänzt durch optionale Erweiterungen für komplexere Anforderungen.
Besonders lehrreich war der Moment, in dem das Team gegen ein klares Research-Signal (Rollenhierarchie) entschieden hat: Gute UX-Arbeit bedeutet nicht, jedes Insight 1:1 umzusetzen, sondern es gegen technische Machbarkeit und Wartbarkeit abzuwägen und diesen Trade-off transparent zu machen.
