Un centro servizi condivisi può rispettare tutti gli accordi sul livello di servizio (SLA) e al contempo generare costi superflui. Ciò accade solitamente quando i team sono diventati efficienti nella gestione delle eccezioni, nella correzione delle richieste incomplete e nell'ottimizzazione dei sistemi non integrati. Saper riprogettare i processi dei servizi condivisi significa affrontare questi problemi alla radice, non automatizzare più rapidamente le soluzioni alternative.
Per i responsabili di finanza, risorse umane, acquisti, IT e operazioni con i clienti, l'obiettivo non è semplicemente ridurre il numero di interazioni per transazione. Si tratta di un modello di servizio che offra risultati coerenti, chiara attribuzione di responsabilità, dati affidabili e la capacità di assorbire la crescita senza aumentare proporzionalmente l'organico. Raggiungere questo obiettivo richiede che processi, dati, tecnologia e governance vengano riprogettati come un unico sistema operativo.
Parti dalla domanda, non dal flusso di lavoro esistente
La maggior parte dei programmi di riprogettazione inizia con la mappatura dei processi. Queste mappe sono utili, ma possono anche perpetuare i presupposti che hanno generato il problema. Un punto di partenza migliore è la domanda: quali richieste arrivano al centro servizi, chi le inoltra, quanto sono complete, quanto sono variabili e quale risultato l'azienda necessita effettivamente.
Consideriamo la contabilità fornitori. Un flusso di lavoro tradizionale potrebbe iniziare quando una fattura raggiunge la coda di elaborazione della contabilità fornitori. Tuttavia, il problema operativo potrebbe insorgere molto prima, ad esempio in caso di ordini di acquisto mancanti, dati anagrafici dei fornitori incoerenti o regole di approvazione diverse tra le unità aziendali. Riprogettare il flusso di lavoro della contabilità fornitori solo dopo la ricezione della fattura migliorerà solo una parte limitata del ciclo, lasciando inalterato il costo delle eccezioni evitabili.
Segmentare la domanda prima di progettare lo stato futuro. Le transazioni ad alto volume e bassa variabilità dovrebbero seguire un percorso digitale standard. I casi complessi, di alto valore o che richiedono un'elevata capacità di giudizio necessitano di un percorso controllato da esperti. Le richieste che non dovrebbero mai raggiungere i servizi condivisi dovrebbero essere evitate attraverso un migliore self-service, una progettazione delle politiche più accurata o una convalida a monte.
Questa distinzione è importante perché la standardizzazione non equivale a imporre un unico percorso a ogni singolo caso. Il livello di standardizzazione appropriato dipende dal rischio, dal valore della transazione, dai requisiti normativi e dall'impatto sul cliente.
Stabilire una base di dati per la riprogettazione dei processi
Intervistare solo i responsabili dei processi non è sufficiente. Spesso le persone descrivono il processo previsto, mentre i dati operativi rivelano il processo effettivamente in esecuzione. Una base di riferimento credibile combina dati sul flusso di lavoro, registri degli eventi di sistema, report sulle code, registri di qualità e osservazione diretta da parte del personale operativo.
Misurare il tempo di consegna end-to-end, non solo il tempo di gestione. Una richiesta può richiedere dieci minuti di lavoro da parte del personale, ma rimanere aperta per dieci giorni perché in attesa di un responsabile, un fornitore, un dipendente o un altro sistema. Misurare anche i tassi di successo al primo tentativo, le rilavorazioni, i passaggi di consegne, i motivi delle eccezioni, l'anzianità del backlog e la quota di volume gestita al di fuori del percorso standard.
Le scoperte più preziose sono spesso nascoste nelle variazioni. Un'unità aziendale può generare un numero di eccezioni tre volte superiore a causa di dati di input incompleti. Un gruppo di approvatori può causare una quota sproporzionata di ritardi. Un'applicazione legacy può richiedere una riconciliazione manuale dopo ogni errore di interfaccia. Si tratta di problemi di progettazione con conseguenze misurabili, non di problemi isolati legati alle persone.
Un punto di riferimento pratico dovrebbe rispondere a tre domande: dove si ferma il lavoro, dove ritorna e dove esce dal processo controllato? Queste risposte forniscono una giustificazione più solida per l'investimento rispetto ad affermazioni generiche sull'inefficienza di un processo.
Riprogettare il lavoro prima di selezionare l'automazione
L'automazione può ridurre lo sforzo in un processo stabile. Tuttavia, non può risolvere problemi di responsabilità poco chiara, politiche contrastanti, dati anagrafici inadeguati o approvazioni non necessarie. Quando l'automazione viene implementata prima di una riprogettazione, le organizzazioni spesso creano bot fragili, duplicano le regole su diverse piattaforme e si trovano ad affrontare un onere di manutenzione maggiore.
La progettazione dello stato futuro dovrebbe eliminare alcuni passaggi prima di digitalizzarli. Bisogna mettere in discussione ogni passaggio di consegne, approvazione, verifica e attività di inserimento dati. Bisogna chiedersi se gestisce un rischio reale, contribuisce a una decisione o si limita a compensare la mancanza di informazioni altrove. Se non svolge nessuna di queste funzioni, è un candidato ideale per l'eliminazione.
Una riprogettazione efficace sposta inoltre i controlli più vicino al punto di origine della transazione. Ad esempio, i campi obbligatori, i controlli delle policy, il rilevamento dei duplicati e la convalida dei requisiti di ammissibilità possono essere applicati al momento dell'invio di una richiesta. Ciò impedisce che le richieste incomplete entrino in una coda di elaborazione e fornisce ai dipendenti un feedback immediato anziché un rifiuto ritardato.
Le procedure operative standard dovrebbero essere documentate al livello di competenza degli utenti: fattori scatenanti, input richiesti, regole aziendali, responsabili, criteri di eccezione e output attesi. Un diagramma a corsie di alto livello è utile per l'allineamento, ma non è sufficiente per la creazione di flussi di lavoro, integrazioni o automazioni.
Integrare i dati nella progettazione del processo
I processi dei servizi condivisi falliscono su larga scala quando il modello dati viene trattato come una questione IT esterna al modello operativo. In pratica, la qualità dei dati determina se le transazioni possono fluire automaticamente, se le dashboard sono affidabili e se i team sono in grado di identificare le cause principali.
Definisci gli elementi di dati critici per ogni processo: fornitore, dipendente, cliente, materiale, centro di costo, contratto, conto e informazioni sul caso. Quindi stabilisci dove viene creato ciascun elemento, chi ne è responsabile, quale sistema è autorevole e quale convalida è necessaria prima che possa essere utilizzato a valle.
Ciò è particolarmente importante nelle organizzazioni coinvolte in fusioni, con differenze regionali e molteplici ambienti ERP. Un unico standard globale per i dati potrebbe essere l'obiettivo giusto a lungo termine, ma un'armonizzazione forzata immediata può rallentare la realizzazione. In tali situazioni, un livello di mappatura governato e una chiara definizione della proprietà dei dati possono generare valore più rapidamente, mentre l'architettura generale viene migliorata gradualmente.
I dati dovrebbero essere visibili anche nella gestione delle prestazioni operative. Se una dashboard mostra solo il tempo medio di gestione, i responsabili potrebbero non accorgersi che richieste incomplete o dati anagrafici non validi sono la causa principale del carico di lavoro. Collegare le metriche di processo con le metriche di qualità dei dati rende l'attribuzione di responsabilità concreta e attuabile.
Progettazione dell'automazione in base al tipo di decisione
Una volta definiti i processi e le basi dei dati, le scelte di automazione diventano più mirate. I lavori ad alto volume basati su regole sono ottimi candidati per l'automazione dei flussi di lavoro, le integrazioni e l'elaborazione dei documenti. Le attività che richiedono classificazione, estrazione da documenti non strutturatio redazione di risposte possono trarre vantaggio dalle capacità dell'IA. Le decisioni con un impatto significativo a livello finanziario, di conformità o sui dipendenti richiedono regole di policy esplicite, soglie di confidenza e responsabilità umana.
L'obiettivo non è applicare l'IA ovunque sia possibile, bensì utilizzare la capacità più appropriata per il lavoro da svolgere. Un'integrazione ben progettata è spesso più affidabile di un'automazione robotica del desktop. Un modulo digitale standardizzato può eliminare la necessità di estrarre documenti. Una fase di revisione umana può rappresentare il giusto controllo quando la fiducia è bassa o un'eccezione comporta un rischio significativo.
Per ogni automazione, è fondamentale definire il percorso di gestione delle eccezioni prima della messa in produzione. Chi riceve le transazioni non riuscite? Quali informazioni sono necessarie per risolvere il problema? Come vengono classificati gli errori ricorrenti e come vengono utilizzati i dati per migliorare i processi o i dati? Senza questa progettazione, i team di gestione delle eccezioni diventano un ostacolo permanente tra l'automazione e il business.
Definire una governance che favorisca la scalabilità
La riprogettazione dei servizi condivisi trascende i confini funzionali. La finanza potrebbe essere responsabile di una politica, gli acquisti dei dati dei fornitori, l'IT di un'integrazione e il centro servizi condivisi dell'esecuzione quotidiana. Senza un modello decisionale, i miglioramenti si arrestano alla prima dipendenza interfunzionale.
La governance dovrebbe chiarire la responsabilità dei processi, dei dati, della tecnologia e dei controlli. Questi ruoli possono essere ricoperti da responsabili diversi, ma i confini devono essere espliciti. Il responsabile di un processo dovrebbe essere responsabile delle prestazioni end-to-end, comprese le cause a monte della domanda e i risultati a valle per il cliente, non solo del lavoro svolto all'interno del centro.
Creare una cadenza che separi la gestione operativa dalle decisioni di trasformazione. Le revisioni giornaliere o settimanali dovrebbero concentrarsi su backlog, livelli di servizio, eccezioni e capacità. Le revisioni mensili dovrebbero affrontare le cause profonde, l'efficacia dei controlli, la qualità dei dati, le prestazioni dell'automazione e la roadmap di miglioramento. Questo impedisce ai team di considerare i difetti ricorrenti come normali operazioni.
Testare il modello, poi industrializzarlo
Un progetto pilota dovrebbe testare un risultato di servizio completo, non una piccola funzionalità tecnica. Seleziona un segmento di processo con un volume significativo, un problema evidente, dati disponibili e dipendenze gestibili. Definisci una linea di base, stabilisci gli obiettivi e includi metriche di adozione e controllo insieme alle misure di efficienza.
Le metriche più comuni includono il tempo di ciclo, la percentuale di successo al primo tentativo, il costo per transazione, la percentuale di interventi manuali, il tasso di eccezioni, l'anzianità del backlog e la soddisfazione dell'utente. La giusta combinazione di metriche dipende dal servizio. Nell'ambito della gestione delle buste paga o dell'amministrazione sanitaria, l'accuratezza e la conformità possono essere più importanti della velocità. Nella gestione degli ordini dei clienti, il tempo di risposta e la qualità degli ordini possono avere un peso maggiore.
Dopo aver validato lo stato futuro, è opportuno industrializzare i componenti riutilizzabili: modelli di acquisizione, regole di convalida, standard di integrazione, controlli dei dati, modelli di automazione, dashboard di monitoraggio e materiali per la gestione delle modifiche. È in questa fase che i programmi aziendali acquisiscono scalabilità. Ogni nuovo processo non dovrebbe richiedere un nuovo metodo di erogazione.
La gestione del cambiamento richiede anche dettagli operativi. I team devono sapere cosa viene interrotto, cosa cambia, come vengono gestite le eccezioni e come verrà valutata la performance. I leader devono chiarire che la riprogettazione non è un progetto una tantum. I processi richiederanno degli aggiustamenti in base all'evoluzione della domanda, delle politiche, dei sistemi e delle priorità aziendali.
Rendere visibili le prestazioni e garantire un miglioramento continuo
Il processo riprogettato dovrebbe produrre un sistema di gestione, non solo un nuovo flusso di lavoro. La visibilità operativa in tempo reale consente ai responsabili di monitorare la domanda, la capacità, i colli di bottiglia, la qualità e i risultati dell'automazione prima che i livelli di servizio si deteriorino.
Evitate dashboard che riportano solo medie storiche. Abbinate indicatori ritardati, come il costo mensile per transazione, a indicatori anticipatori, come la completezza dei dati inseriti, il flusso di eccezioni, l'anzianità delle approvazioni e i modelli di errore di automazione. Questo dà ai responsabili dei processi il tempo di intervenire prima che si accumulino arretrati e insoddisfazione dei clienti.
Le organizzazioni di servizi condivisi più efficienti considerano ogni eccezione ricorrente come un segnale di progettazione. Alcune richiederanno formazione o chiarimenti sulle policy. Altre riveleranno una convalida mancante, un problema di integrazione o una lacuna nella proprietà dei dati. L'obiettivo è ridurre nel tempo la necessità di interventi operativi straordinari.
Un modello di servizi condivisi riprogettato acquisisce valore quando i team possono dedicare meno tempo a inseguire le transazioni e più tempo a gestire i risultati. Iniziate con un processo in cui le variazioni, le rilavorazioni e l'intervento manuale sono visibili. Costruite una solida base di dati, eliminate le cause del lavoro evitabile e utilizzate il risultato come base replicabile per una trasformazione più ampia.
