Trupeer Blog
Riassumi
Spostare le attività di finanza, risorse umane, approvvigionamento o IT in un centro di servizi aziendali globali (GBS) è uno dei più grandi cambiamenti operativi che un'azienda possa compiere. Il caso aziendale è solitamente chiaro: costi inferiori, processi standard e un servizio migliore. La parte difficile è la transizione stessa, ovvero i mesi che intercorrono tra l'approvazione del progetto e l'esecuzione del lavoro a regime.
La maggior parte dei programmi GBS segue una metodologia ben definita, con fasi, stage gate e una struttura di governance. Tuttavia, le transizioni subiscono ancora ritardi e i livelli di servizio calano dopo l'avvio. Nella maggior parte dei casi, la metodologia non è il problema. Il punto debole è il trasferimento della conoscenza, e in particolare la conoscenza che non è mai stata scritta.
Questa guida spiega la metodologia di transizione GBS fase per fase, la governance che la tiene unita, i punti in cui il trasferimento di conoscenza (KT) si interrompe e il modo in cui i team GBS registrano ora il KT in modo che la conoscenza tribale arrivi nel nuovo centro.
Che cos'è una transizione GBS?
Una transizione GBS è il processo strutturato di trasferimento dei processi aziendali da team locali, unità aziendali o un fornitore di outsourcing a un'organizzazione di servizi aziendali globali. Tale organizzazione può essere un centro captive, un global capability center (GCC), un partner di outsourcing o un ibrido di tutti e tre.
Una transizione può essere di tipo lift and shift (solleva e sposta), in cui i processi vengono spostati così come sono e migliorati in seguito, oppure transform and shift (trasforma e sposta), in cui i processi vengono riprogettati prima o durante il trasferimento. La maggior parte dei programmi sposta il lavoro a ondate (waves), raggruppando i processi per funzione, regione o complessità in modo che il centro GBS possa assorbirli per fasi.
La metodologia di transizione GBS: 6 fasi
Le metodologie variano tra società di consulenza e fornitori, ma quasi tutte seguono le stesse sei fasi. Ogni fase si conclude con uno stage gate: una verifica formale del soddisfacimento dei criteri di uscita prima dell'inizio della fase successiva.
Fase 1: Valutazione e progettazione della soluzione
Il programma definisce cosa si sposta, dove si sposta e perché. I team creano un inventario dei processi, definiscono i volumi, i costi e i livelli di servizio attuali e progettano il futuro modello operativo: sedi, organizzazione, tecnologia e modello di erogazione del servizio.
Risultati chiave: inventario dei processi, metriche di riferimento, modello operativo target, business case, piano delle ondate di alto livello.
Fase 2: Pianificazione della transizione
La pianificazione trasforma la progettazione in una pianificazione temporale. Viene istituito l'ufficio di gestione della transizione (TMO), i piani delle ondate vengono dettagliati e ogni processo riceve un proprietario, un esperto della materia (SME) e un responsabile della ricezione. L'assunzione e l'onboarding per il centro GBS iniziano qui, perché il KT non può iniziare finché non esiste il team ricevente.
Risultati chiave: piano di transizione dettagliato, RACI, piano e calendario del KT, registro dei rischi, piano di comunicazione, criteri di prontezza per ogni ondata.
Fase 3: Trasferimento della conoscenza (Knowledge Transfer)
Gli esperti della materia (SME) del team attuale spiegano e mostrano ogni processo al team GBS ricevente. Il KT di solito combina sessioni in aula, procedure guidate sui sistemi e domande e risposte, e il suo risultato è la documentazione: SOP (procedure operative standard), procedure desktop, mappature dei processi e guide operative. Questa è la fase che decide l'andamento di tutto ciò che segue.
Risultati chiave: SOP e procedure desktop documentate e approvate dallo SME, tracker del KT che mostra la copertura per processo, team ricevente formato.
Fase 4: Esecuzione in parallelo (Shadow e Reverse Shadow)
Durante la fase di shadowing, il team GBS osserva il team attuale svolgere il lavoro. Durante la fase di reverse shadowing, il team GBS svolge il lavoro mentre il team attuale osserva e corregge. Errori, lacune nella documentazione ed eccezioni mancanti emergono qui e dovrebbero essere integrati nelle SOP.
Risultati chiave: registri di shadowing e reverse shadowing, tassi di errore e rielaborazione, SOP aggiornate, valutazione go/no-go.
Phase 5: Go-Live e Hypercare
Al momento del passaggio (cutover), il centro GBS assume la proprietà del processo. L'hypercare è un periodo di supporto extra, in genere di diverse settimane, in cui il team originale rimane disponibile, i problemi vengono analizzati quotidianamente e i livelli di servizio vengono monitorati attentamente.
Risultati chiave: checklist per il cutover, registro dei problemi, reportistica SLA giornaliera o settimanale, criteri di uscita dall'hypercare.
Fase 6: Stabilizzazione e regime (Steady State)
Una volta che i livelli di servizio sono stabili, il processo passa alla governance ordinaria. L'attenzione si sposta sul miglioramento continuo, sulla standardizzazione tra le regioni e, spesso, sull'automazione dei processi che sono stati trasferiti.
Risultati chiave: SLA e KPI a regime, cadenza delle revisioni del servizio, backlog dei miglioramenti, proprietà della knowledge base.
Governance della transizione GBS
La governance è ciò che impedisce a una transizione multi-ondata di trasformarsi in un insieme di progetti separati. La maggior parte dei programmi GBS utilizza tre livelli:
Comitato direttivo (Steering committee): sponsor senior dell'azienda e dell'organizzazione GBS. Sono i proprietari del business case, approvano gli stage gate e risolvono le escalation.
Ufficio di gestione della transizione (TMO): gestisce il programma giorno per giorno. È proprietario del piano, monitora i rischi e le dipendenze, riporta i progressi e si assicura che ogni ondata segua lo stesso metodo.
Responsabili dei flussi di lavoro e dei processi: un responsabile per l'invio e uno per la ricezione per ogni funzione o ondata, supportati dagli SME. Gestiscono il KT, firmano la documentazione e gestiscono lo shadowing.
Gli elementi di governance che contano di più sono il piano di transizione, la RACI, il registro dei rischi, il tracker del KT e i criteri go/no-go per ciascun stage gate. Le metriche tipiche includono il completamento delle sessioni di KT, il tasso di approvazione delle SOP, i tassi di errore di shadow e reverse shadow, i livelli di backlog e il raggiungimento degli SLA durante l'hypercare.
In molti modelli di governance appare una lacuna: monitorano se il KT è avvenuto, non se la conoscenza è stata effettivamente acquisita. Un tracker del KT può mostrare il 100% delle sessioni completate mentre la documentazione alle spalle è scarsa, non aggiornata o priva delle eccezioni che contano.
Dove si interrompe il trasferimento della conoscenza
Il KT fallisce raramente perché le persone saltano le sessioni. Fallisce perché gran parte di ciò che fa funzionare un processo risiede nella testa delle persone, non nei documenti. Si tratta della conoscenza tribale: le soluzioni alternative, le valutazioni discrezionali e le eccezioni che una persona esperta gestisce senza pensarci.
Questi sono i punti più comuni in cui il KT si interrompe in una transizione GBS:
Le eccezioni non vengono documentate. Le SOP descrivono il percorso standard. I casi che causano errori, come un fornitore insolito, una rettifica manuale o un percorso di approvazione specifico, vengono spiegati una volta in una sessione, se mai lo vengono.
Le mappature dei processi non corrispondono alla realtà. Il processo documentato e il processo effettivamente seguito dalle persone si sono allontanati, e il divario è visibile solo quando qualcuno svolge il lavoro.
Le sessioni di KT non vengono registrate. Un SME spiega un processo dal vivo. Il team ricevente prende appunti e tutto ciò che sfugge agli appunti va perso una volta terminata la sessione.
La documentazione richiede molto tempo per essere prodotta. Trasformare le sessioni in SOP ricche di screenshot richiede tempo, quindi la documentazione ritarda rispetto al KT e il team ricevente inizia lo shadowing con materiale incompleto.
Gli SME se ne vanno o perdono interesse. Le persone nell'organizzazione mittente potrebbero andarsene, essere ricollocate o essere insoddisfatte del cambiamento. La loro conoscenza ha una data di scadenza, e spesso è più ravvicinata di quanto ipotizzato nel piano.
Divari linguistici e geografici. I centri GBS multi-regionali servono team che potrebbero non condividere una prima lingua, e la documentazione prodotta in una lingua non sempre è adatta a ogni sede.
La documentazione diventa obsoleta dopo il go-live. I processi cambiano durante l'hypercare, ma le SOP non vengono aggiornate, quindi i nuovi assunti nel centro GBS imparano una versione superata.
Il risultato si manifesta dopo il cutover: tassi di errore più elevati, un backlog in crescita, livelli di servizio inferiori a quelli di riferimento e un team GBS che continua a rivolgersi al team originale per avere risposte. Questa dipendenza è il segno che la conoscenza è stata trasferita, ma la documentazione no.
Come i team GBS registrano il KT oggi
La soluzione non consiste in un maggior numero di sessioni di KT. Si tratta di catturare le sessioni che già svolgete e trasformarle in documentazione abbastanza rapidamente da essere utili. Sempre più team GBS considerano ora la registrazione come parte del metodo KT stesso:
Registrare ogni sessione di KT. Acquisire le sessioni di MS Teams o Zoom e le procedure guidate degli SME come prassi standard, non come un extra opzionale.
Catturare il vero lavoro sullo schermo. Chiedere agli SME di eseguire il processo nel sistema reale, comprese le eccezioni, utilizzando un registratore di schermo come il registratore di schermo AI di Trupeer.
Trasformare le registrazioni in SOP e video. Caricare le registrazioni su uno strumento di documentazione AI. Trupeer trasforma ciascuna di esse in una SOP passo-passo con screenshot e un video narrato, nel vostro modello e con il vostro kit del brand.
Far convalidare gli SME, non scrivere. Gli SME esaminano e correggono le bozze, aggiungendo le eccezioni mancanti, invece di scrivere i documenti da zero.
Tradurre per ciascuna sede. Utilizzare la traduzione di video e documenti in modo che ogni sede GBS lavori sulla stessa versione, nella propria lingua.
Pubblicare in un'unica knowledge base. Memorizzare ogni SOP e video in una knowledge base ricercabile organizzata per ondata e processo, e utilizzarla durante lo shadowing.
Aggiornare durante l'hypercare. Quando un passaggio cambia, registrare nuovamente quel passaggio e aggiornare la documentazione, in modo che la knowledge base rimanga la fonte di verità.
Genpact ha utilizzato questo approccio per un'implementazione di Workday a livello aziendale. Il team ha registrato le sessioni di progettazione dei processi esistenti su MS Teams e le guide degli SME, le ha caricate su Trupeer e ha ottenuto SOP e video dimostrativi in cinque lingue. Ha fornito più di 500 materiali di formazione in 20 flussi di lavoro per 140.000 dipendenti in 40 paesi in 3 mesi, un programma che avrebbe richiesto 12 mesi con il metodo tradizionale. Leggi la storia del cliente Genpact.
La registrazione del KT fornisce alla governance anche qualcosa che di solito manca: le prove. Il tracker del KT può mostrare non solo che una sessione è avvenuta, ma che esistono una SOP e un video approvati per ogni processo dell'ondata.
Come Trupeer aiuta in una metodologia di transizione GBS
Trupeer si inserisce nella metodologia di transizione GBS nel punto in cui la maggior parte delle transizioni fatica: trasformare il trasferimento della conoscenza in documentazione che il team ricevente può utilizzare. Ecco come supporta ogni fase:
Valutazione e progettazione della soluzione: registra le procedure guidate di come vengono eseguiti i processi oggi, in modo che l'inventario dei processi e la linea di base riflettano il lavoro reale, non solo la versione documentata.
Pianificazione della transizione: imposta i modelli, un kit del brand e una struttura di knowledge base per ondata e processo prima dell'inizio del KT, in modo che ogni output segua lo stesso formato.
Trasferimento della conoscenza: registra le sessioni di KT e le procedure guidate degli SME con il registratore di schermo AI, oppure carica le registrazioni di MS Teams e Zoom, e ottieni una SOP passo-passo e un video narrato da ciascuna di esse.
Esecuzione in parallelo: fornisci al team GBS i video dei processi da guardare prima dell'inizio dello shadowing e aggiorna le SOP con le eccezioni e gli errori riscontrati durante lo shadow e il reverse shadow.
Go-live e hypercare: gli operatori effettuano ricerche in un'unica knowledge base invece di inviare messaggi al team originale, e le SOP vengono aggiornate registrando nuovamente solo il passaggio modificato.
Stabilizzazione e regime: la knowledge base diventa la libreria di onboarding per i nuovi assunti nel centro GBS, così la conoscenza non se ne va con le persone.
Per i centri GBS multi-regionali, la traduzione produce SOP, voci fuori campo e didascalie nella lingua di ciascuna sede a partire dalla stessa fonte. Per la governance, ogni processo nel tracker del KT può essere collegato a una SOP e a un video approvati, fornendo al TMO e al comitato direttivo la prova che la conoscenza è stata catturata, e non solo che le sessioni si sono svolte.
Checklist di prontezza del KT GBS
Prima che un'ondata passi dal KT allo shadowing, verificare che:
Ogni processo dell'ondata abbia uno SME e un responsabile della ricezione designati.
Ogni sessione di KT sia stata registrata.
Ogni processo disponga di una SOP e di un video, esaminati e approvati dallo SME.
Le eccezioni e le soluzioni alternative note siano documentate, non solo il percorso standard.
La documentazione sia disponibile nelle lingue di ogni sede ricevente.
Tutte le SOP e i video siano pubblicati in un'unica knowledge base che il team GBS può consultare.
Un proprietario sia assegnato per mantenere aggiornata ogni SOP durante l'hypercare e a regime.
Per saperne di più su come catturare la conoscenza che risiede nella testa delle persone, consulta le nostre guide sul trasferimento della conoscenza tribale, sull'indicizzazione dei video dei processi per gli operatori BPO e sulla riduzione dei tempi di transizione con la documentazione AI.
Conclusione
Una metodologia di transizione GBS fornisce le fasi, i gate e la governance per spostare il lavoro in sicurezza. Ma la metodologia è tanto forte quanto lo è il trasferimento di conoscenza al suo interno. Quando il KT dipende da sessioni dal vivo e appunti, la conoscenza tribale rimane al team originale e il divario si manifesta sotto forma di errori e SLA mancati dopo il go-live.
Registrare il KT e trasformarlo in SOP, video e in una knowledge base ricercabile colma questo divario. Inizia gratuitamente con Trupeer e trasforma la tua prossima sessione di KT in documentazione che il tuo team GBS potrà utilizzare fin dal primo giorno.
Domande frequenti
Che cos'è una metodologia di transizione GBS?
Una metodologia di transizione GBS è un approccio strutturato per spostare i processi aziendali in un'organizzazione di servizi aziendali globali. Di solito copre sei fasi: valutazione e progettazione, pianificazione, trasferimento di conoscenza, esecuzione in parallelo, go-live e hypercare, e stabilizzazione, ciascuna con uno stage gate.
Quali sono le fasi di una transizione GBS?
Le fasi comuni sono la valutazione e la progettazione della soluzione, la pianificazione della transizione, il trasferimento di conoscenza, l'esecuzione in parallelo (shadow e reverse shadow), il go-live e l'hypercare, e la stabilizzazione a regime.
Qual è il ruolo di un ufficio di gestione della transizione (TMO)?
L'ufficio di gestione della transizione (TMO) gestisce la transizione giorno per giorno. È proprietario del piano, tiene traccia dei rischi e delle dipendenze, riferisce sui progressi al comitato direttivo e si assicura che ogni ondata segua lo stesso metodo.
Cosa si intende per shadowing e reverse shadowing?
Nello shadowing, il team GBS ricevente osserva il team attuale svolgere il lavoro. Nel reverse shadowing, il team GBS svolge il lavoro mentre il team attuale osserva e corregge gli errori prima del go-live.
Perché il trasferimento della conoscenza fallisce nelle transizioni GBS?
Il KT di solito fallisce perché la conoscenza tribale, come eccezioni, soluzioni alternative e decisioni discrezionali, non viene mai documentata. Le sessioni non vengono registrate, la documentazione ritarda rispetto al KT e gli SME potrebbero andarsene prima che la loro conoscenza venga catturata.
Come si cattura la conoscenza tribale durante una transizione?
Registrando le sessioni di KT e le spiegazioni degli SME del lavoro reale, comprese le eccezioni. Trasformando le registrazioni in SOP e video, facendole convalidare dagli SME e pubblicando tutto in una knowledge base ricercabile.
È possibile creare SOP dalle registrazioni delle sessioni di KT?
Sì. Strumenti come Trupeer trasformano le registrazioni delle sessioni di KT o delle spiegazioni degli SME in SOP dettagliate con screenshot, oltre a video narrati, che gli SME possono rivedere e modificare.
Quanto tempo richiede una transizione GBS?
Dipende dalla portata, dal numero di ondate e dal livello di trasformazione coinvolto. Il trasferimento della conoscenza e la documentazione sono spesso sul percorso critico, quindi catturare il KT più velocemente può abbreviare i tempi complessivi.
