Shared Services in Agentic Services verwandle

Stell der vor, dis Finance Operations-Team bechunnt jede Tag es Dutzend Invoice-Exceptions. Jede Fall muess ufgmacht, gläse, mit PO und Goods Receipt abgliche und denn entschide werde, öb er cha verarbeitet oder muess abglehnt werde. De gröscht Teil vo de Zit gaht für s Sueche vo Date i drei verschidene System druf, nöd für d Entscheidig sälber. Oder s HR Services-Team, wo immer wider di glyche Froge zu Ferie und Onboarding-Status beantwortet, obwohl d Antwort scho i de Knowledge Base steit. Oder de IT-Support, wo ständig Passwörter zruggsetzt, während komplexeri Incident länger warte müend.

Shared Services sind us eme logische Gedanke entstande: Prozäss standardisiere, Volume konsolidiere und Effizienz über Skala erziele. Finance, HR, Procurement, IT und Customer Operations sind zentralisiert worde, damit Transaktione konsistenter verarbeitet werde. Das Modell funktioniert no, zeigt aber langsam sini Grenze. S Volume stigt, d Variation vo de Exceptions nimmt zue, und d Erwartige vom Business bewege sich vo reiner Effizienz zu Gschwindigkeit und Qualität vo de Resultat. Ticket stapele sich. Handoff nähmed zue. SLA wärde administrativ erfüllt, aber d Erfahrig blibt schlecht. Vili Team sind schlussendlich demit beschäftigt, Arbeit z verschiebe, statt se z erledige.

Da isch de Punkt, wo Agentic Services als Antwort ufchömed – nöd als en zusätzlichi Chatbot-Schicht über em Service Desk, sondern als en Veränderig i de Art, wie Dienst erbracht werde. Nümm e Delivery, wo hauptsächlich uf menschlichi Arbet setzt, sondern en service-basierte Team-Ansatz us Mensch und Agent. I dem Modell list de Agent d Aafrog, verstoht de Kontext, rüeft System a, bereitet Handlige vor und löst eifachi Fäll direkt. De Mensch verschwindet nöd, sini Rolle verschiebt sich zur Bearbeitig vo Exceptions, zur Interpretation vo Policy, zum Stakeholder-Management und zur kontinuierliche Verbesserig. S Ziel isch nöd eifach d Reduktion vo FTE – wenn das s Hauptziel isch, baue d Firmene meischtens e brüchigi Automatisierig uf und verlüred s Vertraue. Es bessers Ziel isch, s Service-Modell sälber z verändere.

Worum Shared Services de richtig Startpunkt sind

Nöd alli Funktione sind en guete Startpunkt für en agentici Transformation. Shared Services sind oft en bessere Kandidat als Funktione, wo sehr strategisch oder sehr unstrukturiert sind. Es git drei Hauptgründ.

Erstens: Hohes Volume und sich widerholendi Arbeitsmuster. Shared Services handlet grossi Menege vo Arbeit ab: Invoice-Exceptions, Mitarbeiterfroge, Procurement-Intake, Passwort-Reset, Bestellstatus, Dispute, Onboarding-Ufgabe und vieli ähnlichi Fallvariante. Es hohes Volume bringt zwei Vorteil uf einisch. Es git gnueg historischi Date, um d Muster vo Fäll, Exceptions und Ergebnisse z verstoh. Und es git gnueg Widerholige, damit d Investition i en agentic Workflow wirtschaftlich sinnvoll isch.

Zweitens: D Prozäss sind relativ standardisiert, au wenn nöd eifach. Vili Shared-Services-Prozäss sind kei eifachi Arbeit, aber gnueg strukturiert, um i Schritt zerlegt z werde, wo orchestriert werde chönd: D Aafrog läse, de Intent klassifiziere, Date us em System hole, d Policy prüefe, de Weg bestimme, d Handlig vorbereite und denn abschlüsse oder eskaliere. Das isch anders als bi sehr strategischer oder sehr verhandlungsintensiver Arbeit, wo soziale Kontext und menschlichs Urteil vil dominanter sind.

Drittens: D Betriebsdaten sind umfassend. Shared Services laufed normalerwys scho uf ERP, CRM, HRIS, ITSM, Knowledge Base, SOP und Workflow-Engine. D Grundlag für en agentic Service isch eigentli scho da, au wenn si oft verteilt und nöd integriert parat isch. Finance Shared Services händ Date zu Invoice, PO, Goods Receipt, Vendor Master und Zahligspolicy. HR Services händ HRIS, Wissensartikel, Fallhistorie und Benefit-Policy. Procurement Operations händ Intake-Formular, Verträg, Vendor-Status und Approval-Matrix. IT Support händ Ticketing, CMDB, Runbook und Telemetrie. Customer Operations händ CRM, Bestellhistorie, Entitlement-Regle und Interaktions-Transkript.

Aber es isch wichtig z verstoh: Shared Services sind nöd en Startkandidat, wills eifach z automatisieren sind, sondern wills räich gnueg sind, um neu designt z werde. Wenn es Unternehmen nume uf Personalabbau uus isch, wirds tendenziell de engscht und sicherst Fall uswähle und denn bi de partielle Automatisierig stoppe. Das bringt lokali Effizienz, aber veränderet s Service-Modell nöd.

Vom Ticket-Management zur Orchestrierig vo de Lösig

Di grundlegendsti Veränderig i de agentische Shared Services isch de Wechsel vom Managen vo Arbeitswarteschlange zur Orchestrierig vo de Lösig. Im alte Modell nimmt de Service Desk es Ticket a, list de Inhalt vo de Aafrog, suecht Date i mehrere System, prüeft d Policy und entscheidt denn, öb de Fall cha glöst werde oder muess wiitergleit werde. Vili Zit gaht nöd für hochwertigi Entscheidige druf, sondern für administrativi Arbeit und s Sueche vo Kontext.

Im agentische Modell chönd die meiste vo dene erschte Schritt zum Agent verschobe werde. Für Fäll, wo gnueg klar und es niedrigs bis mittlers Risiko händ, cha de Agent d E-Mail, s Formular, de Chat oder s Ticket läse, d Art vo de Aafrog klassifiziere, de Kontext us de Knowledge Base und de Transaktionssystem hole, de Status, d Entitlement oder d Policy prüefe, e Handlig wie en Entwurf vo de Antwort oder es Status-Update vorbereite und under bestimmte Bedingige d Lösig usfüere.

Es Bispiel im IT-Support. Für Aafroge wie Passwort-Reset, Standard-App-Zuegriff oder de Status vo allgemeine Incident cha de Agent d Aafrog läse, d Identität und de Kontext verifiziere, s passende Tool ruefe und de Fall löse, ohni uf en menschliche Analyst z warte. Im HR-Service für Froge zu Ferie, Onboarding-Status oder Policy-Dokument cha de Agent Date us em HRIS und de Knowledge Base hole und e personalisierti Antwort gäh. Wenns e eifachi administrativi Handlig bruucht, cha de Agent se vorbereite oder usfüere, innerhalb vo de definierte Autorisierig. I de Procurement Operations für en standardisierte Procurement-Intake cha de Agent de Bedarf klassifiziere, prüefe, öb de Artikel im Katalog isch, de Vendor-Status prüefe und denn en Entwurf für en Purchase Request mache oder de Requester uf de richtig Weg leite. I de Finance Operations für e eifachi Invoice-Exception cha de Agent d Invoice mit PO und Goods Receipt abgliche, grundlegendi Mismatch identifiziere und denn zum richtige Weg leite oder e Lösigsempfählig vorbereite.

Je meh de Agent di routinemässige Arbeit übernimmt, desto klarer wird de Bereich, wo de Mensch eigentli wichtiger wird. Exception, wo nöd is Muster passed, Konflikt zwüsche Policy, Fäll, wo sensibli Stakeholder betreffed, Verhandlige mit Vendor oder Kunde, Entscheidige mit materielle Us- Wirkige und kontinuierlichi Prozässverbesserig bliibed im menschliche Domain. D Rolle vom Shared-Services-Team veränderet sich. Si sind nümm i erster Linie Ticket-Bearbeiter, sondern Exception-Resolver, Policy-Interpret, Service-Quality-Manager und Trainer vom System dur operativs Feedback.

I eme usgreifte Design isch de Service Desk nümm glych wie es Inbox oder e menschlichi Warteschlange. Er wird zu ere Orchestrierigsschicht, wo reglet, welli Aafrog automatisch chönd glöst werde, welli en Approval bruuched, welli direkt zum Mensch müend und wie de Fallback passiert, wenn de Agent versagt. Wenn es Unternehmen nume en Agent vor em alte Service Desk installiert, ohni de Ablauf z ändere, isch s Ergebnis meischtens en Chatbot plus de alti Rückstau. De Wert vo de Transformation isch chli. Autonomi Lösig isch guet für Fäll mit stabile Muster, verfüegbare Date, relativ klare Policy und begrenzter Us-Wirkig. Si isch nöd guet für Fäll, wo sehr mehrdütig, sehr emotional oder sehr materiell sind, ohni zuesätzlichi Kontrolle.

Neue Service-Katalog für d Betriebskontrolle

Sobald Shared Services zum Human-Agent-Team-Modell wächsled, cha d Betriebskontrolle nümm uf alte Service-Definitione verlah. D Firma bruucht en neue Service-Katalog, wo mindestens drei Service-Typen unterscheidet.

Erstens: Human-delivered Service. Das sind Dienst, wo hauptsächlich vo Mensche usgfüert werde, wils Urteil, Sensitivität oder es hohes Risiko bruucht. Bispiel sind grossi Kunde-Dispute, HR-Entscheidige, wo de Arbeitsstatus betreffed, materielli Accounting-Behandlig oder riskanti IT-Produktionsänderige.

Zweitens: Agent-assisted Service. Da hilft de Agent bim Läse vom Kontext, Vorbereite vo Entwürf oder Gäh vo Empfählige, aber de Mensch trifft di wichtigscht Entscheidig. Bispiel sind Entwürf für de Finance-Close-Kommentar, Empfählige für en Sourcing-Weg, Entwürf für d Antwort uf e Kunde-Beschwerde oder Incident-Triage für en Engineer.

Drittens: Agent-executed Service. Da cha de Agent de Dienst direkt innerhalb vo klare Policy-Grenze abschlüsse, mit eme Fallback zum Mensch, wenns nötig isch. Bispiel sind Passwort-Reset, Status-Order-Inquiry, Update vo bestimmte administrative Date, s Routing vo standardisierte Purchase Requests oder d Lösig vo eindeutige Policy-Froge.

Die Unterscheidig isch wichtig, wil jede Kategorie anderi Kontrolle bruucht. Jede agentische Service bruucht en relevante SLA – nöd nume d Antwortzit, sondern au d Lösigsziit. De SLA muess s Ergebnis abbildte, nöd nume d Bestätigung. Eskalationsregle müend explizit si: Wänn muess de Agent ufhöre, wänn muess de Fall zum Supervisor, wänn isch en Approval nötig? En Audit-Trail muess de Firma erlaube z gseh, vo wo d Aafrog cho isch, welne Kontext bruucht worde isch, weles Tool gruefe worde isch, welli Handlig usgfüert worde isch und wänn de Mensch übernoo het. Ohni Audit-Trail sind agentischi Shared Services schwirig gegenüber internem Audit, Compliance oder em Prozässverantwortliche z verantworte. Jede Service muess au Metrike ha, wo zu sim Service-Modus passed. En Agent-executed Service cha nöd uf di glych Art gmesse werde wie en Human-delivered Service.

Eine vo de hüfigste Design-Fehler isch d Aanahm, dass en Fallback zum Mensch möglichscht vermide werde sött. I Shared Services isch das genau en wichtige Kontrollmechanismus. En Fallback isch nötig, wenn d Date nöd usreichend sind, d Policy kollidiert, d Confidence nidrig isch, s Risiko z hoch isch oder de Benutzer s Ergebnis vom Agent ablehnt. Es gsunds Design isch nöd eis, wo de Agent zwingt, alli Fäll z löse, sondern eis, wo weiss, wänn es sicher isch ufzuhöre. Wenn de Fallback nöd guet designt isch, chönd zwei Sache passiere: De Agent isch z aggressiv und macht tüüri Fehler, oder de Agent isch z konservativ, so dass alli Fäll doch bim Mensch landed und de Gschäftswert verlore gaht. D Betriebskontrolle muess nöd nume regle, was de Agent darf, sondern au, weles Vertraue mer ihm gäbig isch.

Wert messe: vo Effizienz zu Ergebnisqualität

Agentischi Shared Services werded oft mit em Narrativ vo de Produktivität verchauft. Das isch nöd falsch, aber z eng. De wichtigere Wert isch d Veränderig vo de Servicequalität. Einigi vo de nützlichste Metrike sind d First-Contact-Resolution, also wie vili Fäll bi de erste Interaktion glöst werded. De Touchless-Processing-Rate, wie vili Fäll ohni menschlichi Berüehrig glöst werded. D Cycle-Time, wie lang s vo de Aafrog bis zur Lösig duuret. De Exception-Backlog, ob schwirigi Fäll sich staupled oder abnehmed. Und d Cost-per-Case, was en Fall würkli koschtet. Die Metrike hälfed z gseh, öb sich s Service-Modell würkli veränderet het, nöd nume, öb en Agent im Isatz isch.

Effizienz ohni Qualität zerstört s Vertraue. Drum müend agentischi Shared Services au mit Error-Rate, Compliance-Findings, User-Satisfaction und eme Trust-Score oder eme Indikator für s Vertraue vo de Benutzer i d Agent-Ergebnis gmesse werde. De Trust-Score muess nöd kompliziert si. Er cha mit de Acceptance-Rate, de Override-Rate oder em Feedback vo de Benutzer zu de Agent-Empfählige aafoo. Wichtig isch, dass d Firma nöd nume misst, wie vil automatisch isch, sondern au, öb d Lüt vertraued und öb d Ergebnis richtig sind.

Bispiel-Blueprint: Agentic Finance Shared Service

Finance Shared Services sind es guets Bispiel, wil d Prozäss gnueg strukturiert sind, s Volume hoch isch, aber es trotzdem klar Bereich für menschlichs Urteil git. Stell der vor, e Organisation fangt mit Accounts Payable und Close Support aa.

Dienst, wo agent-assisted si chönnte, sind d Klassifizierig vo Invoice-Exceptions, s Sammle vo Beleg us em ERP, en Entwurf für d Erklärig vo Varianze und e Zämmefassig vo Aging-Issues für de Reviewer. Da entscheidt de Mensch immer no de letschte Schritt, aber d Zit, wo für s Sueche vo Date und s Vorbereite vo Erklärige bruucht wird, sinkt signifikant.

Dienst, wo agent-executed si chönnte, sind s Beantworte vo Froge zum Invoice- oder Payment-Status, s Leite vo Vendor-Query zum richtige Weg, s Verarbeite vo Low-Risk-Fäll mit sehr klare Regle und s automatische Ufmache oder Update vo Fäll.

Dienst, wo human-delivered bliibed, sind d Entscheidig über materielli Accounting-Behandlig, Exception, wo en Fraud-Verdacht betreffed, Vendor-Dispute, wo Verhandlige bruuched, und d Approval vo hochwertige Zahlige.

Kontrolle, wo vorhande si müend, sind en Service-Katalog, wo die drei Service-Modi unterscheidet, SLA pro Service-Typ, Thresholds für Wert und Risk-Tier, en Audit-Trail für jede Tool-Call und Empfählig, en Fallback zum AP-Analyst oder Controller und e wöchentlichi Überprüefig vo Override- und Correction-Muster.

Relevanti Metrike sind de Touchless-Rate für Vendor-Inquiry, d Cycle-Time für Invoice-Exceptions, d First-Contact-Resolution für Status-Query, d Correction-Rate bi Entwürf, de Exception-Backlog, wo uf de Mensch wartet, und Compliance-Issues, wo nach de Implementierig uftauche.

So en Blueprint zeigt, dass en agentic Finance Shared Service nöd Finance ohni Mensch bedütet. Was sich veränderet, isch, wer was macht, wänn de Mensch iistigt und wie de Service gmesse wird.

Wänn Shared Services no nöd bereit sind für d Veränderig

Nöd alli Shared Services sind sofort bereit für d Skalierig. Es git e paar Warnsignaal, wo mer beachte sött. De Basisprozäss isch sälber no nöd stabil oder nöd dokumentiert. D Knowledge Base isch voll mit veraltete Dokumänt und sich widersprechende Policy. D Integration zu ERP, CRM, HRIS oder ITSM isch no brüchig. Es git kei klar Service-Besitzer zwüsche Operations, IT und Risk. D Service-Metrike sind nume uf Ticket-Volume basiert, nöd uf Ergebnis. D Exception-Rate isch sehr hoch und d Ursache sind nöd verstande. D Organisation gseht de Agent immer no nume als es Tool zum Personal spare.

Under sonige Bedingige isch e agentici Transformation riskant. Si wird zu ere neue Schicht über em alte Chaos. S Ergebnis isch meischtens e Automatisierig, wo usgseht wie usgreift, aber schwirig z vertraue und schwirig z skaliere isch.

Entscheidige, wo jetzt troffe werde müend

Nachdem mer das Thema verstande het, gits es paar Entscheidige, wo mer sött treffe. Erstens: Wähl de erst Domain vo de Shared Services us, wo am meiste Sinn macht. Priorisier Bereich mit hohem Volume, relativ standardisierte Muster, verfüegbare Betriebsdaten und eme klare Prozässverantwortliche. Zweitens: Leg de Service-Modus pro Use-Case explizit fescht – weli sind human-delivered, agent-assisted und agent-executed. Drittens: Design de Fallback und d Eskalation vo Aafang aa, wart nöd, bis de Agent i de Produktion versagt, um z überlege, wänn de Mensch überneh sött. Viertens: Änder de Service-Katalog und d Service-Metrike, wil agentischi Shared Services nöd mit alte Service-Definitione chönd gmanagt werde, wo nume uf Ticket und Headcount fokussiert sind. Fünftens: Leg e funktionsübergriffendi Governance fescht, wil COO, CIO, Prozässverantwortlichi, Risk und HR müend sich einig si, dass das es Redesign vom Operating Model isch, nöd nume es Tool-Projekt.

E reflektivi Frog für d Füehrig isch: Sind d Shared Services i ihrem Unternehmen immer no als menschlichi Ticket-Verarbeitigs-Maschine designt, oder wird scho agfange, se als es Portfolio vo ergebnisorientierte Dienst z denke, wo vo Human-Agent-Teams mit neue Kontrolle, Metrike und Verantwortlichkeite betriebe werded? Das isch d Frog, wo entscheidt, ob agentici AI nume en zuesätzlichi Effizienz-Schicht wird oder würkli d Art veränderet, wie s Unternehmen interni und operativi Dienst erbringt.