Documentazione SOP dei servizi condivisi su scala: un framework in 7 passaggi

La documentazione SOP per i servizi condivisi su scala significa gestire la produzione delle procedure per un'intera operazione di servizi condivisi o GBS come un processo ripetibile, non come una serie di compiti di scrittura. Ciò significa un inventario dei processi per ogni divisione ed entità, l'acquisizione invece della redazione, un formato fisso, una coda di revisione gestita e un proprietario designato per ogni procedura con una cadenza di revisione.

I team dei servizi condivisi ne hanno bisogno più di chiunque altro. Un singolo centro può gestire centinaia di processi in finanza e contabilità, risorse umane, acquisti e IT, per decine di entità legali in diversi paesi e lingue. Ogni processo trasferito da una business unit o da un fornitore esterno ha bisogno di documentazione prima di poter essere avviato, ogni nuova risorsa deve apprenderlo da lì e ogni audit lo richiede. Produrre cinque SOP è un compito di scrittura. Produrne cinquecento su quattro divisioni è un problema operativo e la capacità di scrittura non è più il collo di bottiglia.

Questa guida spiega perché la documentazione SOP nei servizi condivisi fallisce, il framework in sette passaggi per documentare su scala, come Genpact ha utilizzato lo stesso approccio per produrre più di 500 materiali di formazione in tre mesi, una checklist completa e le metriche che indicano se il programma sta funzionando.

Perché la documentazione SOP nei servizi condivisi è diversa

Le basi di una buona SOP sono le stesse ovunque. Ciò che cambia nei servizi condivisi è la scala e la forma del problema:

• Molte divisioni, un solo centro. I processi di finanza, risorse umane, acquisti e IT devono essere documentati tutti secondo uno standard unico, da parte di team con abitudini diverse.

• Molte entità e paesi. Lo stesso processo spesso viene eseguito con varianti locali per entità, paese o cliente, e la documentazione deve mostrare quale versione si applica.

• Flusso continuo di lavoro. I processi continuano ad arrivare da business unit, acquisizioni e fornitori esterni, e ognuno necessita di documentazione prima di poter essere eseguito.

• Alto turnover del personale. I centri di servizi condivisi assumono continuamente, quindi le SOP sono anche il principale materiale di inserimento.

• Controlli e audit. Molti processi comportano controlli finanziari o normativi, quindi la documentazione costituisce una prova di audit, non solo una linea guida.

• Diverse lingue. I centri di erogazione dei servizi spesso lavorano in lingue diverse da quelle delle aziende che servono.

Il risultato è che la documentazione SOP nei servizi condivisi è meno simile alla scrittura di un manuale e più simile alla gestione di una linea di produzione, e deve essere gestita in questo modo.

Creazione tradizionale di SOP contro documentazione di SOP su scala

Un esempio pratico mostra il perché. Supponiamo che la stesura di una singola procedura di sistema con schermate richieda quattro ore, che è una media ragionevole. Un centro di servizi condivisi con 500 procedure su quattro divisioni avrebbe bisogno di 2.000 ore di redazione prima di qualsiasi revisione o manutenzione. A questo volume, la domanda non è se qualcuno sia in grado di scrivere una buona SOP. È se esista un sistema di produzione in grado di acquisire, revisionare, pubblicare e mantenere centinaia di procedure senza creare un arretrato permanente.

Dove fallisce la documentazione SOP nei servizi condivisi

I programmi SOP falliscono raramente all'inizio. Falliscono solitamente tra la cinquantesima e la duecentesima procedura, per quattro motivi prevedibili.

Il collo di bottiglia della redazione

Nel modello convenzionale, qualcuno intervista un proprietario del processo, lo osserva lavorare e scrive la procedura. Quella stesura è la parte costosa, e le persone in grado di farla bene sono solitamente le stesse che gestiscono il processo. L'output diventa subordinato al numero di redattori e la documentazione entra in diretta competizione con l'erogazione del servizio.

Il collo di bottiglia della revisione

Ogni procedura ha bisogno dell'approvazione di qualcuno che sappia se è corretta, e nei servizi condivisi si tratta spesso di un global process owner o di un team lead con un carico di lavoro già completo. Con dieci documenti, la revisione è una conversazione. Con duecento, diventa una coda, e una coda non gestita è il punto in cui i programmi si bloccano visibilmente, con un gran numero di procedure che restano in bozza senza portare alcun valore.

L'obsolescenza supera la creazione

Aggiornamenti ERP, modifiche ai controlli, nuove entità e riprogettazioni dei processi rendono le procedure obsolete. Ogni SOP pubblicata è una piccola passività di manutenzione e, oltre un certo volume, la manutenzione supera la capacità di creazione. Una libreria obsoleta al 40% è probabilmente peggiore di nessuna libreria, perché nessuno sa quale sia quel 40%.

Mancanza di reperibilità

Una libreria di cinquecento procedure archiviate in cartelle per divisione non è utilizzabile nel momento del bisogno. Un operatore impegnato in un'attività con una domanda sulla regola di approvazione di una specifica entità non navigherà all'interno di una gerarchia. Se non riesce a trovare la risposta in circa trenta secondi, chiederà a un collega, che è esattamente il comportamento che la SOP avrebbe dovuto evitare.

Come documentare le SOP dei servizi condivisi su scala in sette passaggi

1. Costruire un unico inventario dei processi in tutto il centro, a livello di attività, prima di scrivere qualsiasi cosa.

2. Selezionare spietatamente e decidere cosa non ha bisogno di una SOP.

3. Sostituire la redazione con l'acquisizione registrando le persone che svolgono il lavoro.

4. Fissare il formato e la tassonomia prima di scalare il volume.

5. Gestire la revisione come una coda, con revisori designati e un livello di servizio.

6. Risolvere la reperibilità per divisione, entità e sistema.

7. Assegnare la proprietà e una cadenza di revisione il giorno in cui ogni procedura viene pubblicata.

I passaggi due, quattro e sette sono quelli che i team tendono a saltare sotto pressione, e determinano se il programma sopravviverà al suo secondo anno.

Passaggio 1: Costruire un unico inventario dei processi in tutto il centro

Il primo risultato di un programma SOP di servizi condivisi non è una SOP. È un elenco. Fate l'inventario a livello di attività, utilizzando la vostra tassonomia di processo dal Livello 1 (divisione) fino al Livello 4 (attività). "Contabilità fornitori" non è una voce di inventario; "approvazione del pagamento fuori ciclo per l'entità del Regno Unito" lo è.

Per ogni attività, acquisite la divisione e l'entità, la frequenza, il numero di persone che la eseguono, le conseguenze di un errore, i sistemi coinvolti, se la documentazione esiste ed è affidabile, e un proprietario designato. Segnalate i singoli punti di conoscenza (single points of knowledge): le attività che solo una persona sa eseguire. Un process documentation template offre una struttura pratica.

Passaggio 2: Decidere cosa non ha bisogno di una SOP

L'istinto quando si lavora su scala è quello di documentare tutto. È l'istinto sbagliato, perché ogni procedura prodotta è una procedura da mantenere. Applicate questo filtro:

• Alta frequenza, alte conseguenze: documentare per primo, per intero, con i percorsi di eccezione.

• Bassa frequenza, alte conseguenze: documentare accuratamente; nessuno si ricorda il processo di chiusura di fine anno.

• Alta frequenza, basse conseguenze: un supporto al lavoro o un riferimento rapido sono solitamente sufficienti.

• Bassa frequenza, basse conseguenze: lasciare non documentato, come decisione dichiarata.

• Singolo punto di conoscenza, qualsiasi quadrante: documentare comunque, perché il rischio è la concentrazione della conoscenza.

È opportuno decidere il formato anche in questa fase. Vedere work instruction versus SOP per capire dove tracciare la linea di confine.

Passaggio 3: Sostituire la redazione con l'acquisizione

Questo è il passaggio che elimina il collo di bottiglia della redazione. Invece di spiegare un processo affinché qualcun altro lo scriva, il proprietario del processo esegue l'attività mentre lo schermo viene registrato, commentando man mano che procede. La registrazione viene convertita in una procedura strutturata con passaggi e schermate, che il proprietario esamina invece di doverla scrivere.

Tre cose cambiano. L'output smette di dipendere dalla capacità di redazione, perché registrare un processo richiede all'incirca lo stesso tempo necessario per eseguirlo. Il dettaglio a livello di schermata viene preservato, perché è stato acquisito invece di essere descritto. E il ruolo del proprietario del processo passa dalla spiegazione alla revisione, che è una richiesta molto più semplice per una persona impegnata. Acquisite i percorsi di eccezione nella stessa sessione: chiedete cosa succede quando l'input è errato, manca l'approvazione o il sistema restituisce un errore.

Nei servizi condivisi, questo è fondamentale soprattutto durante le transizioni. Quando un processo viene trasferito nel centro da una business unit o da un fornitore esterno, registrare ogni sessione di trasferimento di conoscenza significa che la SOP esisterà prima che le persone che conoscono quel lavoro vadano via. Anche le registrazioni esistenti di MS Teams possono essere convertite in SOP.

Passaggio 4: Fissare il formato e la tassonomia prima di scalare

L'incoerenza del formato è economica da prevenre ed estremamente costosa da correggere in un secondo momento. Duecento procedure scritte secondo quattro standard diversi da quattro divisioni rappresentano un progetto di normalizzazione per il quale nessuno ha budget. Bloccate prima di tutto queste decisioni:

• Un unico modello, con sezioni fisse in un ordine prestabilito, utilizzato da ogni divisione.

• Un solo livello di dettaglio, scritto o per un nuovo inserito o per un operatore esperto, non per entrambi.

• Un'unica tassonomia e convenzione di denominazione, allineata alla vostra gerarchia di processo.

• Metadati definiti: proprietario, divisione, entità, sistemi, data dell'ultima revisione e data della prossima revisione.

• Uno standard per le schermate e la rimozione dei dati sensibili (redaction) per le schermate che contengono dati personali o dei clienti.

Un standard operating procedure template o un SOP manual template costituiscono una base di partenza ideale.

Passaggio 5: Gestire la revisione come una coda, non come una catena di email

Definite stati espliciti (bozza, in revisione, modifiche richieste, approvato, pubblicato) e rendete visibile lo stato attuale. Assegnate un revisore designato per procedura, stabilite un livello di servizio di revisione (ad esempio cinque giorni lavorativi) e definite un'escalation in caso di violazione.

Due misure riducono notevolmente il carico di lavoro. Raggruppate le revisioni per area di processo, in modo che un unico global process owner possa esaminare dieci procedure correlate in una sola sessione. E separate la revisione della precisione tecnica, che richiede il proprietario del processo, dalla revisione editoriale, che non ne ha bisogno. Monitorate l'arretrato delle bozze come metrica principale.

Passaggio 6: Risolvere la reperibilità per divisione, entità e sistema

Una procedura ha valore solo nel momento in cui qualcuno ne ha bisogno, di solito durante un'attività, con una domanda precisa. Cosa funziona nei servizi condivisi:

• Una ricerca che restituisca il passaggio pertinente, non l'intero documento.

• Procedure indicizzate per divisione, entità e sistema, in modo che domande come "come posso registrare questo in SAP per l'entità tedesca" trovino subito risposta.

• Titoli coerenti, in modo che un tentativo di ricerca trovi il risultato corretto.

• Accesso direttamente nel flusso di lavoro, non in un portale separato.

• Accesso leggibile dalle macchine, in modo che assistenti e agenti IA interni possano rispondere utilizzando la stessa fonte.

Sulla parte tecnica, vedere how to auto-ingest and index SOPs into a knowledge base.

Passaggio 7: Pianificare la manutenzione fin dal primo giorno

La manutenzione è la differenza tra una libreria e un archivio. Quattro meccanismi sostengono la maggior parte del carico di lavoro: un proprietario designato per procedura, una persona fisica anziché un team; una cadenza di revisione in base alla criticità, trimestrale per le procedure ad alte conseguenze e annuale per il resto; attivatori di modifica (change triggers), in modo che un aggiornamento ERP, una modifica dei controlli o una nuova entità generino automaticamente un'attività di revisione; e la cronologia delle versioni, per poter dimostrare quale versione fosse in vigore in una determinata data ai fini di audit. Pubblicate la data dell'ultima revisione su ogni procedura.

Come Genpact ha documentato su scala con sessioni registrate

La sfida di Genpact era il rollout di Workday a livello aziendale, ma il problema della documentazione era lo stesso che ogni centro di servizi condivisi affronta su scala. Davetta Harper, VP Organizational Change Leader, doveva preparare 140.000 dipendenti in 40 paesi su un nuovo sistema che spaziava tra HCM, finanza e dati.

Ciò significava più di 500 materiali di formazione su 20 flussi di lavoro, in cinque lingue, per i team in Giappone, Brasile, Spagna, Thailandia e Cina. Creare ogni SOP manualmente, schermata dopo schermata, e inviarla a traduttori umani avrebbe richiesto almeno un anno.

Il team ha registrato le sessioni di progettazione dei processi esistenti su Microsoft Teams e i walkthrough delle PMI, le ha caricate su Trupeer e ha ottenuto SOP e video dimostrativi tradotti in tutte e cinque le lingue, con modelli che hanno mantenuto coerente il formato fin dal primo output.

• Oltre 500 materiali di formazione su 20 flussi di lavoro

• 140.000 dipendenti in 40 paesi

• 5 lingue

• 3 mesi per realizzare un programma di 12 mesi

"Dovevamo formare 140.000 persone in 40 paesi su un sistema completamente nuovo. Trupeer ci ha fornito un modo concreto per raggiungere questo obiettivo." Davetta Harper, VP Organizational Change Leader, Genpact

Read the full Genpact story

Gestisci un programma di documentazione di servizi condivisi? Scopri come si applica il flusso di lavoro Genpact al tuo centro. Prenota una demo

Scalare tra entità, sedi e lingue

Una libreria per una singola sede e una libreria multi-entità e multi-paese sono problemi diversi. Due domande decidono la struttura.

In primo luogo, il processo è davvero identico tra le varie entità e sedi? Spesso non lo è, e fingere il contrario produce una procedura che nessuno segue. Il modello praticabile è una procedura globale centrale (global core), di proprietà del global process owner, con varianti locali documentate per ogni entità o paese.

In secondo luogo, in quale lingua lavorano effettivamente le persone? L'inglese di lavoro di solito copre il percorso principale ed è meno affidabile proprio dove la precisione è fondamentale: eccezioni, passaggi di controllo e terminologia normativa. La traduzione deve rimanere legata al documento di origine. Qualsiasi cosa richieda una ritraduzione manuale a ogni revisione finirà per divergere, e una documentazione tradotta obsoleta è peggiore di nessuna perché le persone vi fanno affidamento. Trupeer traduce SOP, voci fuori campo e didascalie in oltre 65 lingue a partire da un unico master.

Checklist per la documentazione delle SOP dei servizi condivisi

Prima dell'inizio della produzione

• Inventario dei processi completato a livello di attività per ogni divisione ed entità

• Criterio di selezione applicato, con decisioni esplicite su cosa non verrà documentato

• Singoli punti di conoscenza (single points of knowledge) segnalati e pianificati per primi

• Modello, tassonomia e convenzione di denominazione concordati e bloccati tra le divisioni

• Livello di dettaglio concordato: per nuovo inserito o operatore esperto

• Campi dei metadati definiti, inclusi divisione, entità e data della prossima revisione

• Standard di rimozione dei dati sensibili concordato per i dati personali e dei clienti

• Stati del flusso di lavoro di revisione definiti, con revisori designati e un livello di servizio

Durante la produzione

• Sessioni di acquisizione registrate anziché scritte a partire da appunti

• Percorsi di eccezione acquisiti nella stessa sessione del percorso principale

• Sessioni di trasferimento di conoscenza per i processi in entrata registrate come standard

• Arretrato delle bozze monitorato settimanalmente come metrica principale

• Revisioni raggruppate per area di processo e global process owner

• Metadati inseriti al momento della pubblicazione, non aggiunti successivamente

• Versioni tradotte prodotte dalla stessa fonte per ciascuna lingua

Dopo la pubblicazione

• Proprietario designato registrato per ogni procedura pubblicata

• Cadenza di revisione impostata in base alla criticità

• Attivatori di modifica collegati ad aggiornamenti ERP, modifiche dei controlli e nuove entità

• Data dell'ultima revisione visibile su ogni procedura

• Ricerca testata con domande reali degli operatori, non con i titoli dei documenti

• Tasso di consultazione monitorato, non solo i documenti prodotti

• Audit annuale per procedure obsolete o ridondanti

Come capire se il programma sta funzionando

I documenti prodotti sono la metrica riportata dalla maggior parte dei programmi SOP, ed è la meno informativa. Più utile per i servizi condivisi:

• Copertura delle attività critiche: la percentuale di attività ad alta frequenza e ad alte conseguenze con una procedura approvata e aggiornata.

• Dimensione ed età dell'arretrato delle bozze: un arretrato in crescita segnala un problema di capacità di revisione.

• Tasso di aggiornamento: la quota della libreria in linea con la propria cadenza di revisione. Al di sotto di circa l'80%, i lettori smettono di fidarsi della libreria.

• Tasso di consultazione: quali procedure vengono aperte e quali non lo sono mai.

• Deviazione delle domande (question deflection): se le domande rivolte ai proprietari dei processi e ai team lead diminuiscono all'aumentare della copertura.

• Tempo di autonomia per i nuovi assunti: il test finale, nonché uno dei costi più elevati in un centro ad alto turnover. Stima il tuo con il time to proficiency calculator.

Copertura e aggiornamento sono le due metriche principali da tenere d'occhio. Per costruire il business case, vedere l' ROI of SOP digitisation.

Errori comuni

• Documentare tutto: ogni procedura creata è una procedura da mantenere.

• Lasciare che ogni divisione scelga il proprio formato: normalizzare in un secondo momento costa più che concordare uno standard adesso.

• Iniziare con i processi facili: iniziare con i singoli punti di conoscenza e il lavoro ad alte conseguenze.

• Lasciare la proprietà non assegnata al momento della pubblicazione: le procedure senza proprietario si deteriorano dal giorno stesso in cui vengono pubblicate.

• Documentare solo lo scenario ideale (happy path): le eccezioni generano la maggior parte delle escalation.

• Misurare la produzione invece del consumo: copertura, aggiornamento e consultazione sono i risultati che contano.

In che modo Trupeer supporta la documentazione SOP dei servizi condivisi

Il collo di bottiglia nella produzione convenzionale di SOP è la stesura. La registrazione dello schermo combinata con la documentazione automatizzata elimina questo problema. Il proprietario del processo esegue l'attività una volta durante la registrazione; la registrazione diventa una procedura dettagliata con screenshot, che il proprietario esamina invece di doverla scrivere. L'output scala quindi con il numero di proprietari di processo, non con il numero di redattori tecnici.

Trupeer trasforma le registrazioni dello schermo e le registrazioni di riunioni esistenti in SOP, istruzioni di lavoro e video di formazione, applica un modello e un brand kit in ogni divisione, le traduce per ogni centro di erogazione e le conserva in una knowledge base ricercabile con cronologia delle versioni e accesso basato sui ruoli. Le pagine SOP creator, SOP generator e convert screen recording to SOP coprono i flussi di lavoro specifici, mentre global business services copre il caso d'uso più ampio.

Se il compito consiste nel migrare un catalogo esistente di documenti Word e PDF piuttosto che produrre nuove procedure, si tratta di un esercizio diverso: vedere how to digitise thousands of legacy SOPs e how to prioritise which legacy SOPs to digitise first.

Sintesi

La documentazione SOP dei servizi condivisi su scala è limitata da quattro elementi, e la capacità di scrittura non è tra questi: capacità di redazione, capacità di revisione, obsolescenza e reperibilità. Ognuno di essi ha una soluzione strutturale. Acquisite il lavoro invece di scriverlo. Gestite la revisione come una coda controllata. Progettate la manutenzione prima che la libreria diventi di grandi dimensioni. E trattate la reperibilità per divisione, entità e sistema come un requisito di primaria importanza.

I programmi di servizi condivisi che resistono nel corso degli anni tendono ad essere quelli che hanno documentato meno di quanto avrebbero potuto, seguendo un unico standard in ogni divisione, con un proprietario assegnato a ciascuna procedura. Prenota una demo per scoprire come funzionano le SOP registrate per il tuo centro.