Outcome-basierts Betriibsmodell

Stell dir vor, du füehrsch es Shared-Services-Finance-Team. Sit Jahre wird dis Team dermit gmässe, wie viel Rächnige pro Analyst verarbeitet werde, wie lang d'Ticket-Bearbeitig im Durchschnitt isch, und wie voll d'Terminkaländer vo de Teammitglieder sind. All die Metrike sind sinnvoll gsi, solang fascht alli Arbeit vo Mensche gmacht worden isch.

Jetz fangt dis Team a, Agenten yzsetze, zum d'Close-Orchestrierig z'unterstütze, Abstimmlige vorzbereite und Usnahm-Rächnige z'triage. Uf einisch verschwindet de gröscht Teil vo de administrative Arbeit. Wenn du immer no die alte Metrike bruchsch, gseisch nume "d'menschlich Aktivität isch zruggange." Heisst das aber, dass d'Leistig vom Team schlächter worden isch?

D'Frag, wo würkli zellt, isch ehr: Wärde d'Rächnige korrekter verarbeitet? Wärde d'Usnahme schneller glöst? Gönd d'Backlogs zrugg? Verbesseret sich d'First-Pass-Resolution? Cha sich s'menschlich Team jetzt uf die Fäll konzentriere, wo würkli es Urteil bruuche?

Das isch de Chärn vom Problem, wo vili Unternehmen händ, wenn Agenten aafönd, i d'Workflow yzgriffe. Masseinheite wie Schaffstunde, Ufwand oder d'Zahl vo Lüt pro Prozess wärde immer weniger repräsentativ. Nümm so wichtig isch, wie vil Aktivität gmacht wird, sondern weli Outcome würkli erreicht werde.

Wiso di alti Art afo wanket

Wenn Agenten aafönd, d'Arbeit vom Läse vom Kontext, vom Rute vo Fäll, vom Vorbereite vo Handlige, vom Ufruefe vo Tool, und sogar vom Erledige vo bestimmte Transaktione z'übernäh, veränderet sich d'Arbeitsstruktur fundamental. Im Finanzwesen chönd Agenten bi de Close-Orchestrierig hälfe. Im Iikauf chönd Agenten d'Intake klassifiziere und d'Policy prüefe. Im IT-Betrieb chönd Agenten es Incident-Triage mache. Im Kundebetrieb chönd Agenten eifachi Fäll löse, ohni dass en Mensch mues ygriffe.

Wenn d'Füehrig sich immer no uf d'Aktivität konzentriert, wird d'Organisation de Wert falsch läse. D'Aktivität wird zu enere Zwöitvariable, nöd zum Hauptzyl. Wichtiger sind d'Outcome, wo würkli en Iifluss ufs Gschäft händ.

Es outcome-basierts Betriibsmodell entstoot us däm Bedürfnis: s'Unternehmen uf Basis vo Dienstleistigsergebnis und Gschäftsiifluss z'füehre, nöd i erschter Linie uf Basis vo Aktivität und Arbeitskapazität. Das isch nöd nume en KPI-Wächsel. Das isch en Veränderig i de Art, wie me Dienstleistige konzipiert, Verantwortlichkeite zuewiist, interni und externi Verträg ufsetzt, und entscheidet, weli Use Cases sich lohne z'skaliere.

Outcome nöcher am Gschäftswert

Was heisst outcome-basiert konkret? Jedi Funktion muess die Ergebnis definiere, wo würkli wichtig sind. Im Finanzwesen chönnts en schnelleri und kontrollierteri Close sii, korrekt verarbeiteti Rächnige, oder weniger Abstimmligs-Usnahme. Im Iikauf sinds Aafrage, wo vo Aafang a uf em richtige Wäg sind, verbesserti Cycle-Zyte bi de Bschaffig, und höcheri Policy-Compliance. Im Kundebetrieb sinds Fäll, wo bim erschte Kontakt erledigt werde, weniger Widerholigskontakt, und verbesserti Kundezfrideheit. Im IT-Betrieb sinds schneller behobeni Störige, weniger Falscheskalatione, und besser vorbereiteti Changes vor em Release.

Soni Outcome sind vil nützlicher, als nume z'zelle, wie vil Task automatisiert worde sind. No wichtiger: s'Outcome-basierte Dänke zwingt d'Unternehmen, z'frage: brucht's dä Task überhaupt?

Vili Enterprise-Prozess sind voll vo alte Aktivitäte. Widerholti Prüefige, wo me eigentli chönnt wegla, wenn d'Date besser wäred. Übergäb, wo nume wäge de alte Organisationsstruktur existiere. Genehmigige, wo nümm adäquat zum Risiko sind. Manuelli Berichterstattig, wo nöd für würkliche Entscheidige bruucht wird. Wenn es Unternehmen nume d'Automatisierig vo Aktivitäte verfolgt, wirds d'Verschwendig nume beschlünige. Agentic AI macht das Risiko no grösser, wil d'Technologie jetzt no meh Sache cha automatisiere. Ohni d'Disziplin vom Outcome chönnt d'Organisation sehr effizient sii im Usfüehre vo de falsche Prozess.

Drum, bevor me en Agent baut, sött di erschti Frag nöd sii "Welche Task cha me automatisiere?", sondern "Welche Outcome wott me verbessere, und weli Aktivitäte träged würkli zu däm Outcome bi?"

Vom FTE zum Service-Outcome

De nöchsti Wächsel passiert i de Art, wie Unternehmen interni und externi Dienstleistige alueget. Vili Shared Services, GCCs und Tech Services wärde no mit ere effort-basierte Logik gfüehrt: wie vil Lüt sind zuegwise, wie vil Schaffstunde wärde bruucht, wie vil Ticket wärde verarbeitet, oder wie vil Teamkapazität wird bruucht.

Das Modell verschwindet nöd ganz, aber es wird immer weniger usreichend, wenn digitali Arbet Teil vo de Lieferig wird. Im agentische Modell cha de Durchsatz stiige, ohni dass d'Personalzahl linear mitmacht. D'Kostestruktur veränderet sich au: es git Chöste für d'Platform, für Modell und Inferenz, für Integration, für Observability und Governance, aber es git en Rückgang bi manuellem Ufwand für bestimmti Volume.

Drum verlüüret d'Preisbildige uf Basis vo FTE oder Schaffstunde a Bedütig. Wenn en Dienst jetzt vo ere Kombination us Agent, Workflow-Engine und menschlichem Supervisor erledigt wird, isches irreführend, d'Chöste nume uf Basis vom menschliche Ufwand z'verrechne oder z'allokiere.

Es konkretes Bispil: Shared Services im Iikauf, wo früener en Chargeback uf Basis vo de Zahl vo Support-Mitarbeiter pro Gschäftseinheit gha händ, isches jetzt sinnvoller, wenn me si ahand vo Outcome wie erledigti Aafrage, Cycle-Zyt oder Compliance-Rate misst. IT-Services, wo früener ahand vo de Zahl vo Ticket uf Level 1 abgrächnet worde sind, chönd jetzt uf Metrike wie "Incident resolved within target", "Service-Restoration-Zyt" oder "Change-Success-Readiness" umschwenke. Finanz-Opérations, wo früener mit eme FTE-pro-Transaktionsvolume-Verhältnis grechtfertigt worde sind, müend jetzt d'Chöste pro korrekt verarbeiteti Rächnig oder pro glösti Usnahm aluege.

Dä Wächsel betrifft au d'Vendore-Verträg. I de agentische Dienstleistig chauft es Unternehmen eigentli nümm es "Werkzüüg" oder "zuesätzlichi Arbet", sondern immer hüfiger es Dienstleistigs-Outcome. Managed-Services- und Outsourcing-Verträg müend sich vo input-basierte Preisbildige, Time-and-Material oder blossem Headcount-Leverage wegbewege, zu Modelle, wo nöcher a qualitativ hochwertigem Durchsatz, Resolution-Outcome, Compliance-Outcome oder bestimmte Gschäfts-KPIs sind.

Das isch natürlich nöd immer eifach. Nöd alli Dienstleistige lönd sich rein outcome-basiert vertragle. Wenn de Prozess starch vo externe Faktor oder de eigene Date vom Kunde no schlecht sind, wirds für de Vendor schwirig, s'volle Risiko z'übernäh. Aber d'Richtig isch klar: je meh d'agentischi Lieferig usgreift, desto schwächer wird d'Logik vo de rein effort-basierte Preisbildig. I Situatione, wo me de Outcome nonig klar cha definiere, d'Qualitäts-Baseline fehlt, externi Faktor z'dominant sind, oder d'Kontrolle über Date und Prozess no verteilt isch, cha s'Unternehmen mit eme hybride Modell aafo: en Teil fixi Chöste uf Basis vo Kapazität, en Teil uf Basis vom vereinbarte Outcome.

Wär het d'Entscheidig und d'Verantwortig

Es outcome-basierts Betriibsmodell tönt attraktiv, aber es verlangt en höcheri organisatorischi Disziplin. Sobald de Fokus uf Ergebnis goht, muess s'Unternehmen ganz klar sii, wär wa darf entscheide, und wär verantwortlich isch, wenn de Outcome nöd erreicht wird.

Im agentische Enterprise git's mindestens drei Rolle, wo me underscheide muess.

Erstens, de Business Owner. Er isch verantwortlich für de Outcome vomene Dienst oder Prozess. Er legt d'Gschäftszyl, d'Prioritäte vo de Use Cases, d'Definition vom Erfolg, und die akzeptable operative Trade-offs fest. Bispil: de CFO oder Controllership-Lead für de Close-Outcome, de CPO oder Procurement-Opérations-Lead für de Intake-to-PO-Outcome, de COO Customer Operations für de Case-Resolution-Outcome, de CIO oder Head of Operations für de Incident-Recovery-Outcome.

Zweitens, de Agent Owner. Er isch verantwortlich für d'Konzeption und d'Leistig vom Agent im Workflow: wie de Agent schafft, weli Tool er ufrueft, weli Evaluierige bruucht werde, weli Thresholds aagwändet werde, und wie Veränderige veröffentlicht werde. Die Rolle isch hüfig bim Product Owner, Platform Owner oder Domain-Squad-Lead.

Drittens, de Risk Owner. Er stellt sicher, dass d'bounded autonomy innerhalb vo de Guardrails blibt: weli Policy gilt, weli Genehmigige nötig sind, uf weli Date zuegriffe werde darf, und wänn en Use Case müesst zruggghalte oder ygschränkt werde. I bestimmte Domäne cha de Risk Owner us de Compliance, em Internal Control, de Security, de Rechtsabteilig oder de operative Risikofunktion cho.

Eine vo de wichtigste Prüefstei für es outcome-basierts Modell isch, wenn d'Ergebnis nöd de Erwartige entspreched. Zum Bispil, wenn en Rächnig falsch verarbeitet wird, en Incident falsch groutet wird, en Forecast-Usnahm nöd behandlet wird, oder en Kunde-Fall z'schnell abgschlosse wird, aber s'Problem nöd glöst isch. I sonere Situation muess d'Organisation chönne unterscheide, ob d'Ursach bi falsche oder unvollständige Date liit, ere ambivalente oder nöd aktualisierte Policy, eme versagte Tool oder ere versagte Integration, eme schlechte Modell- oder Agent-Verhalte, oder eme grundsätzlich falsche Prozessdesign. Ohni die Unterscheidig landed alli Fähler imene Topf namens "AI-Fähler", obwohl d'Massnahme zum Behebe ganz underschiedlich sind.

Es git es Prinzip, wo nöd verwässeret werde darf: de Agent het kener Accountability. En Agent cha Handlige usfüehre, Empfählige gäh, oder Workflow orchestriere, aber d'Verantwortig blibt bi de Mensche und de Organisationsstruktur. Us Governance-Sicht cha s'Unternehmen d'Verantwortig nöd ufs System abwälze. Wenn's en materiale Fähler im Finanzwese git, en Policy-Verstoss im Iikauf, oder en Sicherheitsvorfall i de IT, wird de Prozessbesitzer und d'Organisation zur Verantwortig zoge. Operativ verhinderet d'Klarheit vo de Accountability d'Verwirrig. Wenn alli dänked "de Agent het's falsch gmacht", de macht niemerd würkli d'Date, d'Policy oder s'Prozessdesign besser.

Initative als Outcome-Portfolio manage

Sobald es Unternehmen vili agentischi Initiative het, isch d'Useforderig nümm nume, Use Cases z'baue, sondern es Outcome-Portfolio z'manage. Nöd alli Use Cases lönd sich witerverfolge, und nöd alli Quick Wins lönd sich skaliere.

Praktisch gsee muess es agentischs Portfolio normalerwiis vier Kategorie usbalanciere. Quick Wins: Use Cases mit klarem Wert, kontrolliertem Risiko und gnueg bereite Date. Zum Bispil Intake-Klassifizierig, Rächnigs-Triage oder Service-Desk-Resolution für Standardfäll. Strategic Bets: Use Cases, wo s'Betriibsmodell potenziell starch verändere, aber komplexer sind. Zum Bispil Close-Orchestrierig über Entitäte hinweg, Supply-Chain-Usnahm-Koordination, oder Multi-Agent-IT-Delivery-Workflow. Platform Investments: Initiative, wo nöd direkt i eim Prozess Wert zeiged, aber wichtig für d'Skalierig sind, wie Identity, Observability, Policy Engine, Integration Layer, Evaluation Harness. Risk Reduction Initiatives: Verbesserige vo Date, Kontrolle, Prüefbarkeit und Governance, wo anderi Use Cases sicher mached.

Wenn es Unternehmen nume Quick Wins verfolgt, wirds vili Pilotprojekt ha, aber wenig Transformation. Wenns nume Strategic Bets verfolgt, riskierts, z'langsam z'sii und de Schwung z'verlüüre. Es gsunds Portfolio brucht es Glichgwicht.

Es outcome-basierts Modell verlangt au d'Disziplin, Initiative z'stoppe, wo nöd lohne. Jede Use Case sött klari Stage-Gates ha: isch s'Gschäftsproblem real, isch d'Baseline vorhande, sind d'Date und d'Policy gnueg bereit, zeigt de Pilot en verbesserete Outcome, sind d'Correction-Rate und s'Risk-Profil no akzeptabel, und sind d'Ökonomie gsund? Wenn d'Antwort nei isch, muess de Use Case gstoppt, ygschränkt oder nöi konzipiert werde. Das isch wichtig, wil Agentic AI eifach en Optimismus-Bias erzeugt. En gueti Demo macht's Organisatone hüfig schwirig, z'zuegäh, dass en bestimmte Use Case eigentli nöd gnueg Wert het oder z'risikoreich isch für de Moment.

Es Portfolio-Review sött nöd nume es Technologie-Forum sii. Es muess de Business Owner, de CIO oder CTO oder Platform Leader, d'Finanze, s'Risk oder d'Compliance oder d'Security, und wenn relevant de CHRO oder s'Transformation Office ybeziehe. D'Entscheidig zum Skaliere isch nöd nume d'Frag, ob de Agent schafft, sondern ob de Gschäfts-Outcome real isch, d'Governance usreichend, und d'Organisation bereit, d'Veränderig ufz'näh.

Nöchsti praktischi Schritt

Nachdäm du verstande hesch, wiso es outcome-basierts Modell wichtig wird, gits es paar Entscheidige, wo du jetzt muess träffe. Erstens, bestimm de primär Outcome pro prioretisiertem Workflow. Fang nöd mit ere Liste vo Task a, wo me cha automatisiere. Fang a mit de Ergebnis, wo du wetsch verbessere: Resolution-Zyt, Gnauigkeit, Compliance, Service-Level oder d'Qualität vo de Entscheidig.

Zweitens, überprüef s'Modell vom Chargeback, vo de Preisbildig oder vom Business Case. Wenn Dienstleistige immer no hauptsächlich ahand vo FTE und Ufwand gmässe werde, entscheid, weli Outcome-Metrike du aafo wetsch bruuche für Shared Services, GCCs, Tech Services oder Vendor-managed Services.

Drittens, leg d'Decision Rights explizit fest. Unterscheid zwüsche Business Owner, Agent Owner und Risk Owner. Stell sicher, dass klar isch, wär de Outcome het, wär d'Leistig vom Agent managed, und wär d'Guardrails setzt.

Viertens, bau Stage-Gates für s'agentische Portfolio. Jede Use Case muess Kriterie ha für Witerentwicklig, Nöidesign oder Stop. La nöd zuel, dass alli Pilotprojekt z'lang läbe ohni Entscheidig.

Fünftens, wechsle d'Review-Foren vo Aktivität zu Outcome. Im Steerig Committee oder Operating Review reduzier de Fokus uf d'Zahl vo Automatisierige und gsparti Schaffstunde. Erhöh de Fokus uf Qualität, Resolution, Vertraue, Risiko und Ökonomie pro Outcome.

Es paar Alarmzeiche söttsch im Auge behalte. S'AI-Programm wird immer no hauptsächlich mit Headcount-Reduktion oder Schaffstunde-Ersparnis grechtfertigt. Use Cases wärde usgwählt, wil si eifach z'demostriere sind, nöd wil de Gschäfts-Outcome wichtig isch. Es git kei klare Owner für Outcome, Agent-Leistig und Risiko. Fähler vom Agent wärde immer allgmein diskutiert, ohni Ursache-Analyse. Vendor oder interni Team wärde no fascht vollständig ahand vo Ufwand gmässe, nöd ahand vo Dienstleistigs-Ergebnis. S'Portfolio isch voll vo Pilotprojekt, aber es git wenig klari Entscheidige zum Skaliere, Nöidesign oder Stop. Es Governance-Board luegt nume uf d'Adoption vo Technologie, nöd uf d'Qualität vom Outcome und d'Kontrolle. D'Organisation isch nonig bereit z'akzeptiere, dass es es paar Aktivitäte sött abschaffe, nöd nume automatisiere.

Wenn morn de gröscht Teil vo de routinemässige Aktivitäte i dinere Funktion vo Agenten übernoh wird, wird dis Management-Modell no Sinn mache? Oder füehrsch du s'Unternehmen immer no uf Basis vo de Zahl vo Lüt und Schaffstunde, nöd uf Basis vo de Dienstleistigs-Ergebnis, wo würkli erschaffe wärde?

Das isch di zentrali Frog vom outcome-basierte Betriibsmodell. Im agentische Enterprise gwinnt nöd s'Unternehmen, wo am schnellschte Aktivitäte automatisiert, sondern das, wo am diszipliniertischte d'Ergebnis managed.