Persona-Clustering: Warum 1.000 Arbeitsplätze keine 1.000 Desktops brauchen
Die Frage vor jeder Technologieentscheidung lautet nicht „Welche Plattform?“, sondern „Wie arbeitet der Mensch?“. Von den Interviewfragen über die Architekturphasen bis zum Betriebsmodell — ein durchgehender Pfad, an dessen Ende regelmäßig weniger Infrastruktur steht als geplant.
Digital-Workplace-Vorhaben starten häufig mit einer gesetzten Antwort: eine Plattform, ein Bereitstellungsmodell, ein Lizenzpaket — ausgerollt über die gesamte Belegschaft. Das ist einfach zu planen und teuer im Betrieb, weil es Anforderungen erfüllt, die es so nicht gibt.
Persona-Clustering dreht die Reihenfolge um. Zuerst wird das Arbeitsmuster erhoben, danach die Technologie zugeordnet. Entscheidend ist dabei ein Detail, das über die Qualität des Ergebnisses bestimmt: geclustert wird nach Arbeitsverhalten, nicht nach Jobtitel. Zwei Personen in derselben Abteilung mit identischer Stellenbezeichnung können in völlig unterschiedliche Personas fallen — und zwei Personen aus Buchhaltung und Vertrieb in dieselbe.
Dieser Beitrag beschreibt den vollständigen Pfad: welche Daten am Anfang stehen, mit welchen Fragen sie erhoben werden, wie die Cluster entstehen, wo sie in der Architekturarbeit nach TOGAF andocken, welche Abhängigkeiten sie erzeugen — und was daraus für Betrieb und Technik folgt.
Schritt 1 — Datengrundlage
Was vor dem Clustering erhoben wird
Gespräche statt Annahmen
HR, Teamleitungen, Betriebsrat, Geschäftsführung — und vor allem die Mitarbeitenden selbst. Wer nur mit der IT spricht, bekommt die IT-Sicht auf die Arbeit, nicht die Arbeit.
Gebäude- und Standortpläne
Feste Arbeitsplätze, Desk-Sharing-Quoten, Produktionsflächen, Schichtbereiche. Der Grundriss verrät, ob ein persistenter Desktop überhaupt sinnvoll ist.
Bestehende Mitarbeiterbefragung
Meist bereits vorhanden und selten für IT-Zwecke ausgewertet. Sie enthält Reibungspunkte im Arbeitsalltag, die kein Inventar-Tool erfasst.
Geräte- und Applikationsbestand
Welche Anwendungen laufen tatsächlich, wie oft, auf welchem Endgerät — und welche davon sind längst SaaS und brauchen kein Windows mehr im Rücken.
Schritt 2 — Fragenkatalog
Vier Fragenfelder, um die Arbeit zu zerlegen
Ein Fragenkatalog ist keine Checkliste, die abgehakt wird. Er ist so gebaut, dass dieselbe Sache aus verschiedenen Blickwinkeln beschrieben wird — und dass Widersprüche zwischen den Blickwinkeln sichtbar werden. Genau dort liegen die interessanten Befunde: wenn die Teamleitung eine Arbeitsweise beschreibt, die im Alltag längst durch einen Workaround ersetzt wurde.
Wie wird heute gearbeitet?
Der Ist-Zustand, beschrieben aus dem Arbeitsalltag heraus — nicht aus dem Organigramm.
- Welche Anwendung wird morgens als erste geöffnet, welche ist abends noch offen?
- Wie lange dauert eine typische Sitzung — Minuten oder der ganze Tag?
- Wird das Gerät mit anderen geteilt, und wenn ja, wie oft wechselt die Person?
- An wie vielen Orten wird in einer normalen Woche gearbeitet?
- Welche Peripherie ist unverzichtbar — Scanner, Waage, Etikettendrucker, Headset, Signaturpad?
- Was passiert, wenn das Netz für eine Stunde ausfällt?
Was trägt, was reibt?
Die Frage, die am häufigsten übersprungen wird — und die vor Verschlimmbesserung schützt.
- Was funktioniert heute gut und darf auf keinen Fall verschwinden?
- Wo geht täglich Zeit verloren, und wie viel?
- Welche Workarounds haben sich etabliert — Exporte, private Geräte, Papierlisten, Zweitkonten?
- Welche Störung führt zum Anruf beim Service Desk, welche wird stillschweigend hingenommen?
- Welche Anwendung wird ungern genutzt, obwohl sie vorgeschrieben ist — und warum?
Wohin will die Organisation?
Ohne Zielbild wird das Clustering zur Momentaufnahme — und die Architektur veraltet vor der Umsetzung.
- Welche Geschäftsziele der nächsten drei Jahre berühren die Arbeitsweise unmittelbar?
- Sind Standorte, Flächen oder Schichtmodelle in Veränderung?
- Welche Fachanwendungen wandern absehbar in die Cloud, welche bleiben dauerhaft on-premises?
- Welche regulatorischen Anforderungen kommen hinzu — Branche, Datenresidenz, Auditpflicht?
- Gibt es Betriebsvereinbarungen, die Bereitstellungsmodelle oder Monitoring einschränken?
- Wie sind Wachstum, Zukäufe oder Ausgründungen geplant?
Wie will sich die Arbeitsweise ändern?
Die Zielvorstellung der Mitarbeitenden selbst — sie entscheidet über die Akzeptanz der späteren Lösung.
- Wie möchten Sie in zwei Jahren arbeiten, wenn Sie es frei wählen könnten?
- Was wäre für Sie ein klarer Rückschritt gegenüber heute?
- Welche Einschränkung wären Sie bereit hinzunehmen, wenn dafür etwas anderes besser wird?
- Welche Aufgabe würden Sie gern an ein System abgeben?
- Welche Erfahrung aus einer früheren Umstellung hat Vertrauen gekostet?
Erhebungen dieser Art berühren Mitbestimmung und Datenschutz. Umfang, Freiwilligkeit und Auswertungslogik gehören vor dem ersten Gespräch geklärt — insbesondere, wenn Telemetrie als Gegenprobe herangezogen wird.
Schritt 3 — Cluster
Sieben Personas als typisches Ergebnis
Die folgenden Muster treten in mittelständischen und großen Organisationen regelmäßig auf. Die konkrete Ausprägung — und ob es vier, sechs oder acht Cluster werden — ergibt sich aus den erhobenen Antworten, nicht aus der Vorlage. Die siebte Gruppe ist neu und wird bislang selten mitgedacht — dabei wächst sie derzeit am schnellsten.
Knowledge Worker
Fester Arbeitsplatz, zwei Monitore, Office-Suite plus ein bis zwei Fachanwendungen. Hohe Anpassung der eigenen Arbeitsumgebung, geringe Ortswechselrate.
Hybrid Worker
Drei Tage Büro, zwei Tage remote, wechselnde Plätze im Desk-Sharing. Der Arbeitsplatz muss dem Menschen folgen, nicht umgekehrt.
Frontline Worker
Produktion, Lager, Schichtbetrieb. Kurze Sitzungen an geteilten Terminals, oft mit Handschuhen oder unter Zeitdruck. Zwei bis drei Anwendungen, sonst nichts.
Power User
CAD, Videoschnitt, Softwareentwicklung. Grafiklast, hoher Arbeitsspeicherbedarf, lange Sessions und geringe Toleranz gegenüber Latenz.
Task Worker
E-Mail, ein ERP-Zugang, ein Browser-Tool. Klar abgegrenzter Aufgabenzuschnitt, wenig Individualisierung nötig.
Der sechste Fall
Das Cluster, das keine Virtualisierung braucht: Wer den Arbeitstag vollständig in SaaS-Anwendungen verbringt, benötigt keinen virtuellen Windows-Desktop — sondern einen sicheren, verwalteten Browser-Zugang.
KI-Agenten und autonome Systeme
Die Gruppe ohne Mensch dahinter. Aus Sicherheitssicht verhalten sich Agenten wie spezialisierte Mitarbeitende: Sie melden sich an, greifen auf Anwendungen und Daten zu und führen Aktionen aus. Nur schneller, in größerem Umfang und ohne dass jemand in Echtzeit zusieht.
Zur siebten Gruppe: Es ist überfällig, das Clustering nicht länger auf Menschen zu beschränken. Was ein Agent im Alltag tut, unterscheidet sich aus Sicht der Zugriffskontrolle kaum von dem, was eine Sachbearbeiterin tut — er meldet sich an, öffnet Anwendungen, liest und schreibt Daten. Der Unterschied liegt in Geschwindigkeit, Menge und darin, dass niemand in Echtzeit danebensteht.
Daraus folgt eine schlichte Konsequenz: Bedingter Zugriff, Konformitätsregeln, Anwendungs-Governance und Datenklassifizierung müssen für nicht-menschliche Identitäten genauso sauber definiert werden wie für jeden Knowledge Worker oder Frontline-Mitarbeitenden. Wer diese Gruppe nicht in die Architektur aufnimmt, sammelt schneller blinde Flecken als Transparenz — und merkt es erst, wenn ein Agent etwas getan hat, das niemand zuordnen kann.
Der unbequeme Befund
Der größte Hebel liegt in dem, was nicht gebaut wird
Sobald das Clustering steht, zeigt sich in vielen Organisationen dasselbe Bild: Ein erheblicher Teil der Belegschaft arbeitet bereits vollständig in Cloud-Diensten. ERP im Browser, CRM als SaaS, Fachanwendung beim Dienstleister gehostet. Für diese Gruppe ist ein virtueller Desktop eine Zwischenschicht ohne Nutzen — mit eigenen Kosten, eigenem Betriebsaufwand und eigener Angriffsfläche.
ursprünglichen Planung
Browser-Zugang genügt
virtueller Bereitstellung
Illustrative Beispielrechnung zur Veranschaulichung der Methodik — keine Darstellung eines konkreten Projekts. Reale Verhältnisse variieren je nach Branche, Applikationslandschaft und Cloud-Reifegrad erheblich.
Das Ergebnis sind Server, die nie bestellt werden mussten — und Komplexität, die nie hätte entstehen müssen.
Schritt 4 — Einordnung
Wo Personas im TOGAF ADM andocken
Persona-Clustering ist keine Methode neben der Architekturarbeit, sondern eine Zulieferung in sie. Der Fragenkatalog speist das Requirements Management im Zentrum des Architecture Development Method — und wird dort über alle Phasen hinweg fortgeschrieben, nicht einmalig abgelegt.
Management
Schritt 5 — Abhängigkeitsarchitektur
Keine Persona lässt sich isoliert entscheiden
Jede Persona hängt an einer Kette. Wird eine Entscheidung am Ende der Kette getroffen, ohne den Anfang zu kennen, entstehen genau die Sonderfälle, die später den Betrieb teuer machen.
Ortsbindung
Client-Typ
Residenz
Berechtigung
Latenz
Peripherie
Geteilte Abhängigkeiten
Die Fachanwendung des Power Users und das Browser-Tool des Task Workers greifen häufig auf dieselbe Datenquelle zu. Wird sie verlagert, sind beide Cluster betroffen — auch wenn nur eines davon migriert werden sollte.
Peripherie als harte Grenze
Ein Etikettendrucker, ein Signaturpad oder eine Waage entscheiden über das Bereitstellungsmodell mit. Peripherie ist die häufigste Ursache dafür, dass eine theoretisch passende Lösung im Alltag scheitert.
Identität vor Infrastruktur
Anmeldeverfahren und Berechtigungsmodell wirken über alle Cluster hinweg. Eine Persona mit Badge-Anmeldung erzwingt Entscheidungen, die alle anderen mittragen müssen.
Latenz ist standortgebunden
Dieselbe Persona kann an zwei Standorten unterschiedliche Anforderungen haben. Die Kette endet deshalb nicht bei der Persona, sondern bei der Kombination aus Persona und Standort.
Schritt 6 — Betriebsmodell
Was der Betrieb je Cluster bedeutet
Personas verschwinden häufig nach dem Rollout — der Betrieb kehrt zur Einheitsbehandlung zurück, und die eingesparte Komplexität kommt über den Service Desk zurück. Deshalb gehört das Betriebsmodell in dieselbe Struktur.
| Persona | Servicezeit & Priorität | Änderungsrhythmus | Monitoring-Tiefe |
|---|---|---|---|
| Knowledge Worker | Regelarbeitszeit, Standardpriorität | Geplante Wartungsfenster, Nutzer kann verschieben | Applikationsverfügbarkeit, Anmeldedauer |
| Hybrid Worker | Erweiterte Servicezeit, ortsunabhängiger Support | Image-basiert, Aktualisierung ohne Nutzerbeteiligung | Zusätzlich Verbindungsqualität aus dem Homeoffice |
| Frontline Worker | Schichtabdeckung, hohe Priorität — Stillstand ist Produktionsstillstand | Nur außerhalb der Schicht, kurzes Fenster, Rückfallgerät nötig | Gerätestatus und Peripherie, nicht nur Sitzung |
| Power User | Regelarbeitszeit, spezialisierter Support | Individuell abgestimmt, Testinstanz vor Änderung | Ressourcenauslastung, Grafiklast, Reaktionszeit |
| Task Worker | Regelarbeitszeit, Standardpriorität | Zentral, ohne Abstimmung mit Einzelnutzern | Sammelmetriken, keine Einzelbetrachtung |
| SaaS-nativ | Support verlagert sich auf Identität und Endgerät | Vom Anbieter getaktet — Aufgabe ist Beobachtung, nicht Planung | Zugriffs- und Gerätekonformität statt Sitzungsmetriken |
| KI-Agenten | Keine Servicezeit im klassischen Sinn — dafür Eskalation bei auffälligem Verhalten | Versionsstand und Berechtigungen turnusmäßig prüfen, Rücknahme jederzeit möglich | Welche Aktion, auf welche Daten, in wessen Auftrag — lückenlose Nachvollziehbarkeit |
Drei Punkte entscheiden darüber, ob die Struktur den Regelbetrieb überlebt: Erstens muss jede Persona eine benannte fachliche Verantwortung haben, nicht nur eine technische. Zweitens braucht es eine Regel für Abweichungen — wer entscheidet, wenn jemand aus dem Cluster herausfällt, und wird daraus ein Einzelfall oder eine neue Persona. Drittens gehört ein fester Überprüfungsturnus dazu, weil sich Arbeitsmuster schneller ändern als Infrastruktur.
Schritt 7 — Technische Anforderungen
Vom Arbeitsmuster zur technischen Größe
Jede Zeile dieser Tabelle lässt sich auf eine Antwort aus dem Fragenkatalog zurückführen. Das ist der eigentliche Zweck der Methodik: Eine technische Anforderung, deren Herkunft niemand mehr benennen kann, ist im Zweifel keine.
| Anforderung | Abgeleitet aus | Wirkung auf die Architektur |
|---|---|---|
| Sessiontyp | Sitzungsdauer, Gerätewechsel, Individualisierungsbedarf | Persistent, non-persistent oder Multi-Session — bestimmt Dimensionierung und Imaging |
| Profilverfahren | Anpassungsgrad, Anmeldehäufigkeit, Anmeldedauer-Erwartung | Profil-Container, Roaming oder bewusst kein Profil |
| Rechen- und Grafikbedarf | Applikationsprofil, Datenvolumen, Darstellungsanforderung | Instanztypen, GPU-Bedarf, Skalierungsverhalten |
| Latenzbudget | Standort, Interaktionsart, Toleranz gegenüber Verzögerung | Regionswahl, Protokollkonfiguration, Netzanbindung |
| Peripherie-Unterstützung | Unverzichtbare Geräte am Arbeitsplatz | Umleitungsfähigkeit — häufigstes Ausschlusskriterium für ein Modell |
| Authentifizierung | Gerätewechselrate, Umgebungsbedingungen, Schutzbedarf | Badge/NFC, PIN, mehrstufige Verfahren, bedingter Zugriff |
| Identitätsart | Handelt ein Mensch oder ein System — und in wessen Auftrag? | Menschliche gegenüber nicht-menschlicher Identität: eigene Berechtigungslogik, eigene Lebensdauer, eigene Protokollierung |
| Datenresidenz | Regulatorik, Branchenanforderung, Betriebsvereinbarung | Region, Speicherort, Trennung von Datenbeständen |
| Verfügbarkeit | Folgen eines Ausfalls für den Geschäftsprozess | Redundanz, Rückfallebene, Offline-Fähigkeit |
| Lizenzierung | Nutzungsintensität, Funktionsbedarf, Nutzungszeit | Lizenzstufe je Persona statt einheitlicher Höchststufe |
| Skalierung | Tages- und Schichtverlauf der Nutzung | Automatisiertes Hoch- und Herunterfahren, Kapazitätsplanung |
Vorgehen
Sieben Schritte, in dieser Reihenfolge
Daten sammeln
Bestehende Quellen zuerst: HR-Struktur, Grundrisse, Geräte- und Applikationsbestand, vorhandene Mitarbeiterbefragung. Neue Erhebungen nur dort, wo eine Lücke bleibt.
Fragenkatalog führen
Dieselbe Arbeitssituation aus mehreren Perspektiven beschreiben lassen. Widersprüche sind kein Störgeräusch, sondern das eigentliche Ergebnis.
Arbeitsmuster identifizieren
Ortsbindung, Sitzungsdauer, Geräteteilung, Applikationsprofil, Schutzbedarf. Nicht nach Abteilung gruppieren — das erzeugt Cluster, die es im Alltag nicht gibt.
Personas definieren
Jede Persona über vier Dimensionen beschreiben: Anwendungen, Endgerät, Sicherheits- und Compliance-Anforderung, Lizenzbedarf. Erst wenn alle vier belastbar sind, ist das Cluster fertig.
Abhängigkeiten aufnehmen
Die Kette von der Persona bis zum Endgerät je Cluster durchziehen und die geteilten Elemente markieren. Sie bestimmen später die Reihenfolge der Umsetzung.
Technologie zuordnen — oder verwerfen
Jetzt erst fällt die Plattformentscheidung, je Persona getrennt. Ein legitimes Ergebnis lautet: keine Virtualisierung erforderlich.
Betriebsmodell festlegen
Servicezeiten, Änderungsrhythmus, Monitoring, Verantwortlichkeiten und Überprüfungsturnus je Cluster — bevor der erste Nutzer migriert wird.
Wie viele Personas sind bei Ihnen definiert?
Die praktische Probe ist einfach: Lässt sich für jede Nutzergruppe in einem Satz sagen, warum sie genau dieses Bereitstellungsmodell erhält — und lässt sich diese Begründung auf eine erhobene Antwort zurückführen? Wenn die Begründung für alle Gruppen gleich lautet, ist es keine Persona-Struktur, sondern ein Rollout.
Weiterdiskutieren
Dieser Artikel ist Teil von Workplace Decoded.
Ich teile Analysen, Frameworks und Vergleiche zum digitalen Arbeitsplatz — herstellerneutral und evidenzbasiert. Wer das Persona-Clustering kommentieren, ergänzen oder mit eigener Erfahrung anreichern möchte, findet den Austausch am schnellsten über LinkedIn.
Oder per E-Mail: kontakt@sofianesalmi.com