Servizio di progetto

Un blueprint di servizio è un diagramma che mappa il percorso del cliente attraverso un servizio, includendo tutto ciò che lo supporta: le azioni visibili al cliente, le attività del personale che può vedere, le attività del personale che non può vedere, i processi interni coinvolti e i sistemi da cui dipende ogni fase. Estende la mappa del percorso del cliente verso il basso, fino all'operazione che eroga il servizio.

La sua struttura utilizza fasce orizzontali separate da linee definite. Le azioni del cliente si trovano nella parte superiore. Sotto la linea di interazione si trovano le azioni front-stage, ovvero le attività del personale percepite dal cliente. Sotto la linea di visibilità si trovano le azioni back-stage, che supportano il servizio senza essere visibili. Sotto la linea di interazione interna si trovano i processi e i sistemi di supporto. Leggendo una fase verticalmente si può osservare tutto ciò che deve accadere affinché quel momento funzioni.

Il valore diagnostico deriva da questa lettura verticale. Quando si esamina un problema che riguarda direttamente il cliente, il diagramma mostra le azioni del personale, i processi e i sistemi sottostanti, rivelando spesso che la causa non si trova dove si manifesta il sintomo. Una risposta lenta in un punto può avere origine in una fase di approvazione tre livelli più in basso; l'incapacità di un operatore di rispondere a una domanda può essere ricondotta a un sistema che non contiene le informazioni.

I punti critici e i tempi di attesa sono le annotazioni che rendono un blueprint operativamente utile. Indicare dove il processo si interrompe più frequentemente, dove avvengono i passaggi di consegne e dove il cliente attende, permette di identificare sia i meccanismi di recupero necessari sia le concentrazioni di tempo trascorso. Nella maggior parte dei servizi, l'attesa tra le fasi rappresenta una parte di gran lunga maggiore della durata totale rispetto alle fasi stesse, e questo non è visibile in una mappa del percorso del cliente che registra solo le azioni.

La realizzazione di un progetto richiede un contributo di cui il team di progettazione non dispone. Il personale in prima linea sa dove il processo effettivamente fallisce e quali soluzioni alternative consentono di mantenerlo funzionante, il personale operativo conosce i vincoli e i team tecnici sanno cosa i sistemi possono e non possono supportare. I progetti elaborati senza il contributo di queste figure descrivono il processo come documentato piuttosto che come effettivamente eseguito, e la differenza tra i due è solitamente il punto in cui si trovano le opportunità di miglioramento.

Questo strumento si rivolge a diverse categorie di utenti, oltre a quelli addetti alla progettazione. Il team operativo lo utilizza per identificare inefficienze e duplicazioni, i team tecnologici per capire quali sistemi supportano quali fasi del processo e dove si trovano le lacune di integrazione, e la dirigenza per comprendere perché un impegno nei confronti del cliente non può essere rispettato senza apportare modifiche strutturali. È proprio questa ampiezza di utilizzo che gli conferisce maggiore rilevanza a livello organizzativo rispetto a una semplice mappa del percorso del cliente.

I progetti sono utili anche in prospettiva, non solo a scopo diagnostico. Elaborarne uno per un servizio che non esiste ancora impone decisioni esplicite su chi esegue ciascuna azione, quali sistemi devono fornire quali informazioni e dove avverranno i passaggi di consegne, prima ancora che il servizio venga realizzato. Progettare l'operazione in modo deliberato è considerevolmente più economico che scoprire, al momento del lancio, che l'esperienza cliente promessa non è supportata da alcun processo.

La disciplina nell'ambito di applicazione è fondamentale, perché i progetti diventano inutilizzabili quando tentano di coprire ogni aspetto. Un progetto che si concentra su un singolo percorso significativo, con un livello di dettaglio coerente, è leggibile e attuabile. Un progetto che cerca di rappresentare l'intero portfolio di servizi in tutte le sue varianti diventa un semplice rivestimento murale che fa colpo durante un workshop ma non viene mai utilizzato in seguito. Selezionare il percorso con il volume maggiore o con il tasso di errore più elevato produce risultati migliori rispetto a una copertura esaustiva.

Poiché l'output in genere identifica i cambiamenti nei processi e nei sistemi piuttosto che nelle interfacce, agire su di esso richiede un'autorità che va oltre la funzione di progettazione. In pratica i progetti vengono prodotti attraverso Audit dell'esperienza utente e lavoro di progettazione dei servizi con prove da ricerca dell'utente compresi i colloqui con il personale e le dipendenze di sistema che espongono diventano spesso un input per la roadmap di consegna detenuta da sviluppo del prodotto.