Wie lässt sich agentischer Self-Service begrenzt erproben?

Ausgangspunkt

Es ist noch nicht bekannt, wie weit Self-Service in der betrachteten Produktorganisation sinnvoll gehen kann. Ebenso fehlt bislang eine konkrete Klasse wiederkehrender Auswertungen oder kleiner Anwendungen, für die Anwender auf das Produktteam warten. Geeignete Kandidaten sollen deshalb gemeinsam mit Anwendern, Product Management beziehungsweise Product Ownern sowie Engineering, Operations und Security aus realen Reibungspunkten entwickelt werden.

Die Untersuchung darf nicht bereits voraussetzen, dass Self-Service die richtige Lösung ist. Sie soll prüfen, ob die risikobasierte Arbeitshypothese in einem konkreten Fall trägt.

Kandidaten finden

Zu suchen sind nicht zuerst gewünschte Apps, sondern beobachtbare Situationen:

• kleine Fragen oder Anpassungen, die regelmäßig auf das Produktteam warten;
• manuell oder außerhalb des Produkts erstellte Auswertungen;
• Wünsche, die einzeln zu klein für die Roadmap sind, zusammen aber häufig auftreten;
• bereits bestehende lokale Umgehungslösungen;
• explorative und zunächst lesende Arbeit ohne produktive Zustandsänderung.

Ein günstiger erster Kandidat hätte wiederkehrenden Nutzen, einen begrenzten Nutzerkreis, freigegebene Datenzugriffe, geringe Abhängigkeiten, beobachtbare Erfolgskriterien und interessierte Pilotanwender.

Technische Mindestbedingungen

Vor einem Pilotversuch braucht es keine allgemeine Self-Service-Plattform, sondern einen kleinen, beobachtbaren Lösungsraum mit harten Grenzen:

• eine vom produktiven Betrieb getrennte Umgebung;
• personenbezogene Identitäten und möglichst lesende Zugriffe nach Least Privilege;
• freigegebene Datenprodukte oder APIs mit verständlicher fachlicher Semantik;
• Protokollierung von Datenzugriffen, Agentenaktionen und erzeugten Artefakten;
• Zeit-, Kosten-, Daten- und Netzwerklimits;
• einen benannten Owner, ein Review- oder Ablaufdatum und eine Abschaltmöglichkeit.

Auch ein lesender Zugriff ist nicht automatisch unkritisch: Vertrauliche Daten können offengelegt und fachlich falsche Auswertungen als Entscheidungsgrundlage verwendet werden.

Mögliche Auswertung

Ein Experiment sollte mindestens Zeit bis zum nutzbaren Ergebnis, Qualität der unterstützten Entscheidung, notwendige Korrekturen, Betreuungsaufwand, Nutzung, Kosten, fachliche Fehler, Weitergabe und neu entstandene Abhängigkeiten erfassen. Vorab sind Abbruchkriterien und der Umgang mit dem Artefakt nach Versuchsende festzulegen.

Offene Fragen

• Welche realen Reibungspunkte eignen sich als Kandidaten?
• Welche Daten und Operationen können sicher freigegeben werden?
• Wann muss ein persönliches Artefakt in reguläre Produktverantwortung übergehen?
• Welche Governance-Kosten würden einen lokalen Nutzen aufheben?
• Zeigt das Experiment nur technische Machbarkeit oder tatsächlich bessere Produktentwicklung?