Software-Architektur für professionelle Begleitung: Anforderungen und Muster

In vielen Organisationen laufen Vertrieb, Finanzen und Personalverwaltung seit Jahren über integrierte Systeme. Professionelle Begleitung – Coaching, Mentoring, Supervision, Führungskräfteentwicklung – läuft dagegen häufig über eine Kombination aus Videokonferenz, E-Mail, Messenger, geteilten Dokumenten und Kalender.

Das ist nicht per se ein Fehler. Diese Analyse fragt, welche Anforderungen Begleitung an Software stellt, wie sich eine Architektur dafür in Schichten beschreiben lässt und welche Muster in der Praxis vorkommen. Sie vertieft damit die Säule Technologische Architektur aus unserer Arbeitsdefinition von Infrastruktur für professionelle Begleitung.

Warum Begleitung besondere Anforderungen stellt

Viele Geschäftsanwendungen bilden lineare Abläufe ab: Ein Ticket wird eröffnet und geschlossen, ein Lead wandert durch eine Pipeline. Begleitung verläuft anders – nicht linear, kontextabhängig und vertraulich. Daraus ergeben sich drei Anforderungen, die generische Werkzeuge nur teilweise erfüllen.

1. Kontinuität zwischen den Terminen. Ob Begleitung über die einzelne Person hinaus wirkt, hängt stark davon ab, was zwischen und nach den Gesprächen geschieht; die Forschung zum Lerntransfer beschreibt das seit Jahrzehnten.¹ Wenn Vereinbarungen, Reflexionsimpulse und Zwischenstände in Postfächern und Chatverläufen verteilt sind, ist dieser Faden schwer zu halten – vor allem, wenn Coach oder Rolle wechseln.

2. Der Vertraulichkeits-Konflikt. Organisationen wollen wissen, ob sich Begleitung lohnt. Die Inhalte einer Begleitung sind aber vertraulich. Werkzeuge, die nicht zwischen persönlichen Inhalten und aggregierten Kennzahlen unterscheiden, zwingen zu einer schlechten Wahl: entweder kein Einblick oder zu viel. Hinzu kommt, dass Gespräche Gesundheitsthemen berühren können; dann gelten die strengeren Regeln der DSGVO für besondere Kategorien personenbezogener Daten.²

3. Anschluss an die Systeme der Organisation. Wer Begleitung für viele Menschen anbietet, muss Zugänge anlegen, ändern und wieder entfernen – idealerweise automatisch aus den bestehenden Identitäts- und Personalsystemen. Fehlt dieser Anschluss, entstehen Handarbeit, veraltete Zugänge und Sicherheitslücken.

Vier Schichten einer Begleitungs-Architektur

Wir schlagen vor, Software für Begleitung in vier Schichten zu denken. Die Schichten beschreiben Aufgaben, keine Produkte. Sie können von einem System oder von mehreren abgedeckt werden. Als Faustregel gilt: oben flexibel, unten streng.

┌──────────────────────────────────────────────────────────┐
│ Interaktion      Gespräche · Reflexion · Material · Chat │  flexibel
├──────────────────────────────────────────────────────────┤
│ Ablauf & Kontext Phasen · Vereinbarungen · Impulse       │
├──────────────────────────────────────────────────────────┤
│ Daten & Rechte   Datenhoheit · Rollen · Aggregation      │  streng
├──────────────────────────────────────────────────────────┤
│ Integration      Anmeldung · Zugänge · Kalender · Export │
└──────────────────────────────────────────────────────────┘

Interaktionsschicht

Hier arbeiten Menschen: Termine vereinbaren, Gespräche vor- und nachbereiten, Materialien teilen, Nachrichten schreiben. Diese Schicht darf flexibel sein, denn Begleitung folgt keinem festen Skript. Sie wirkt dort am besten, wo Menschen ohnehin arbeiten – etwa als kurzer Impuls in der Kollaborationssoftware der Organisation statt als zusätzliche App, die man erst öffnen muss.

Prüffrage: Findet die begleitete Person an einem Ort, was vereinbart wurde und was als Nächstes ansteht?

Ablauf- und Kontextschicht

Diese Schicht hält den Faden zwischen den Terminen. Sie kennt die Phase einer Begleitung (etwa Klärung, Vereinbarung, Erprobung, Auswertung), hält Vereinbarungen fest und löst Impulse zu passenden Zeitpunkten aus – zum Beispiel eine Reflexionsfrage einige Tage nach einem Gespräch oder eine Vorbereitung vor dem nächsten. Dadurch baut jedes Gespräch auf dem vorherigen auf, auch wenn Wochen dazwischen liegen oder die Begleiterin wechselt.

Wichtig ist das Maß: Automatische Impulse sollen Begleitung tragen, nicht ersetzen und nicht bedrängen. Die begleitete Person sollte Häufigkeit und Kanal selbst steuern können.

Prüffrage: Weiß die Software nach drei Monaten noch, was im ersten Gespräch vereinbart wurde – und nur die Personen, die es wissen dürfen?

Daten- und Berechtigungsschicht

Diese Schicht muss streng sein. Sie legt fest, wem welche Information gehört und wer sie sehen darf – mindestens getrennt für begleitete Person, Begleiter:in und Organisation. Auswertungen für die Organisation sollten nur aggregiert und ohne Rückschluss auf Einzelne möglich sein. Die DSGVO verlangt ohnehin Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen.³

Prüffrage: Kann technisch – nicht nur per Vereinbarung – ausgeschlossen werden, dass die Organisation persönliche Notizen einer begleiteten Person einsieht?

Integrationsschicht

Diese Schicht verbindet die Begleitung mit der Organisation: Anmeldung über das bestehende Firmenkonto (Single Sign-on über Standards wie SAML 2.0 oder OpenID Connect), automatisches Anlegen und Entfernen von Zugängen (etwa über SCIM) und Kalenderanbindung.⁴ Offene Standards sind hier wichtiger als einzelne Schnittstellen zu bestimmten Produkten, weil sie einen späteren Wechsel möglich halten. Dazu gehört auch, Daten vollständig exportieren zu können; für personenbezogene Daten sieht die DSGVO ein Recht auf Datenübertragbarkeit vor.⁵

Prüffrage: Was passiert mit Zugängen und Daten, wenn eine Person die Organisation verlässt – und wenn die Organisation den Anbieter wechselt?

Drei Architektur-Muster im Vergleich

In der Praxis begegnen uns drei Muster. Keines ist für alle Fälle richtig.

	Werkzeug-Kombination	Konfigurierte Allzweck-Plattform	Spezialisierte Begleitungs-Plattform
Beispiel	Videokonferenz, E-Mail, Kalender, geteilte Dokumente	CRM-, Projekt- oder Lernsystem, für Begleitung angepasst	Software, die für Begleitung gebaut ist
Stärken	geringe Kosten, vertraut, kein Anbieter-Lock-in	vorhandene Lizenzen und Integrationen, zentrale IT-Betreuung	Abläufe und Rollen passen, Vertraulichkeit oft eingebaut
Grenzen	kaum Kontinuität, Berechtigungen schwer steuerbar, Auswertung nur manuell	Rollen- und Vertraulichkeitsmodell selten passend, hoher Anpassungsaufwand	zusätzlicher Anbieter, Abhängigkeit, Integrationen prüfen
Passt, wenn	wenige Begleitungen, einzelne Coaches, klare Einzelaufträge	Begleitung ist Nebenprozess eines bestehenden Systems	Begleitung ist regelmäßiges Angebot für viele Menschen

Der Übergang ist fließend. Viele Organisationen beginnen sinnvoll mit einer Werkzeug-Kombination und stellen um, wenn Zahl der Begleitungen, Zahl der Begleiter:innen oder Anforderungen an Nachweis und Datenschutz steigen.

Reifestufen

Unabhängig vom gewählten Muster lässt sich die Entwicklung einer Begleitungs-Architektur in drei Stufen beschreiben. Jede Stufe ist für sich wertvoll; nicht jede Organisation braucht alle drei.

Stufe 1 – Absichern. Kanäle ablösen, die für vertrauliche Inhalte ungeeignet sind, etwa private Messenger oder unverschlüsselte Ablagen. Anmeldung über zentrale Firmenkonten, klare Regeln, wo Notizen liegen dürfen. Diese Stufe lohnt sich schon bei wenigen Begleitungen.

Stufe 2 – Verstetigen. Vereinbarungen, Vor- und Nachbereitung an einem Ort bündeln, Rollen und Berechtigungen festlegen, Regeln für aggregierte Auswertungen definieren. Ab hier wird Begleitung über Termine und Personen hinweg anschlussfähig.

Stufe 3 – Verbinden. Zugänge automatisch aus den Personalsystemen verwalten, Begleitung – mit Zustimmung und nur aggregiert – mit Entwicklungszielen der Organisation verknüpfen, KI-Funktionen kontrolliert einsetzen.

Kriterien für die Auswahl

Die folgenden Fragen helfen, unabhängig vom Muster zu prüfen, ob eine Lösung zur eigenen Begleitung passt:

1. Rollen: Bildet die Lösung begleitete Person, Begleiter:in, Koordination und Organisation als getrennte Rollen ab?
2. Datenhoheit: Gehören persönliche Inhalte technisch der begleiteten Person?
3. Aggregation: Sind Auswertungen für die Organisation nur zusammengefasst möglich – mit einer Mindestgröße, unter der nichts angezeigt wird?
4. Kontinuität: Lässt sich eine Begleitung bei Wechsel von Coach oder Rolle ohne Informationsverlust fortsetzen?
5. Standards: Werden Anmeldung und Zugangsverwaltung über offene Standards unterstützt?
6. Ausstieg: Können alle Daten in einem offenen Format exportiert werden?
7. Verarbeitung: Ist dokumentiert, wo Daten gespeichert werden und welche Unterauftragnehmer beteiligt sind?
8. KI: Werden Inhalte für KI-Funktionen verarbeitet – und wenn ja, wo, von welchem Modell, und ist ausgeschlossen, dass sie zum Training fremder Modelle verwendet werden?
9. Aufwand: Steht der Betriebsaufwand im Verhältnis zur Zahl der Begleitungen?

Offene Fragen

• Welche Kennzahlen sind für Organisationen aussagekräftig, ohne die Vertraulichkeit zu gefährden – und ab welcher Gruppengröße?
• Wie viel Standardisierung verträgt Begleitung, bevor sie ihre Wirkung verliert?
• Welche Rolle sollen KI-Funktionen in der Interaktionsschicht spielen dürfen?

---

Offenlegung: Guidance Observatory wird von BA Entertainment herausgegeben. BA Entertainment betreibt mit Co;Gether zugleich eine Plattform für professionelle Begleitung, die dem Muster „Spezialisierte Begleitungs-Plattform“ zuzuordnen ist. Diese Analyse beschreibt Anforderungen und Muster und nennt keine Anbieter von Begleitungs-Software.

Quellen

1. Siehe die Quellen in unserer Arbeitsdefinition, insbesondere Blume, B. D., Ford, J. K., Baldwin, T. T., & Huang, J. L. (2010). Transfer of training: A meta-analytic review. Journal of Management, 36(4), 1065–1105. https://doi.org/10.1177/0149206309352880 ↩

2. Art. 9 DSGVO (Verarbeitung besonderer Kategorien personenbezogener Daten, u. a. Gesundheitsdaten). Verordnung (EU) 2016/679, https://eur-lex.europa.eu/eli/reg/2016/679/oj ↩

3. Art. 25 DSGVO (Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen). ↩

4. OASIS Security Assertion Markup Language (SAML) 2.0; OpenID Foundation, OpenID Connect Core 1.0; Hunt, P. et al. (2015). System for Cross-domain Identity Management: Protocol (RFC 7644). https://www.rfc-editor.org/rfc/rfc7644 ↩

5. Art. 20 DSGVO (Recht auf Datenübertragbarkeit). ↩