Agile Business Process Management! Perché conviene “agilizzare” la gestione per processi.

La gestione per processi è ormai da anni una prassi consolidata all’interno delle aziende. Una recente esperienza mi ha portato a rivederne alcuni concetti in ottica Agile. In questo post descriverò come sono giunto alla conclusione che anche il Business Process Management può trarre valore dall’approccio agile.

Antefatto

Circa un anno fa ho iniziato una collaborazione con il neo team della comunicazione digital di una grande multinazionale nel settore utility. Durante lo scorso anno le molteplici attività portate avanti dal team hanno richiesto un coordinamento puntuale e un supporto continuo alle operazioni, lasciando molto poco spazio all’individuazione e applicazione di processi strutturati. Le emergenze e le richieste dell’ultimo momento in priorità elevata avevano sempre la meglio su una pianificazione organizzata. Anche se, grazie ad una gestione con modelli di Agile Program Management, il team, oggi composto da 11 persone, ha comunque traguardato una serie di importanti obiettivi, ci si è chiesti se e come fosse possibile eliminare gli evidenti sprechi presenti, migliorando i flussi di lavoro.

A novembre del 2016, insieme al mio collega Federico Fasciani, abbiamo quindi preso in considerazione l’opzione più classica: il Business Process Reengineering.

L’opzione classica

Lo strumento del BPR prevede dei prerequisiti e una serie di fasi. Ne faccio un breve elenco senza pretendere di essere esaustivo.

Prerequisiti

• Mission / Vision / Strategia chiare
• Indicatori di performance definiti
• Obiettivi dei processi individuati

Fasi

• Definizione del team che si occuperà del ridisegno
• Mappatura dei processi as-is
• Identificazione dei minus e dei plus dei processi as-is
• Progettazione e ridisegno dei processi to-be
• Validazione dei nuovi processi
• Formazione del personale che dovrà utilizzare i nuovi processi
• Applicazione parallela dei nuovi e dei vecchi processi
• Valutazione in base gli indicatori di performance
• Applicazione di migliorie
• Dismissione dei vecchi processi in favore dei nuovi

Per capire se questo modello fosse adatto al team e alla situazione corrente abbiamo svolto una sorta SWOT analysis, che riporto in maniera riassuntiva:

Strengths: approccio strutturato che consente di individuare tutti i processi interni core e di supporto.

Weaknesses: difficoltà di applicazione in un ambiente fortemente dinamico con sovrallocazione delle risorse.

Opportunities: copertura completa delle necessità di interfacciamento verso l’esterno in modalità Big Bang.

Threats: probabilità elevata di non poter applicare correttamente tutte le fasi e quindi di arrivare ad un risultato finale non in linea con le attese.

Stante queste considerazioni abbiamo capito che, se pur valido, il modello BPR avrebbe portato ad un elevato dispendio di energie a fronte di un risultato poco probabile sia verso l’interno sia verso le altre divisioni aziendali.

Era quindi necessario trovare un’alternativa. Avendo gestito tutti i progetti del 2016 in Lean-Agile, così come la program direction (Nexus e SAFe), ci siamo chiesti se la realizzazione di un Agile Business Process Management non potesse essere la giusta soluzione.

La scelta innovativa

Possiamo applicare i principi delle metodologie Lean e Agile alla reingegnerizzazione dei processi?

Prima di rispondere a questa domanda abbiamo verificato le condizioni a contorno utilizzando il Cynefin Framework (vi rimando a questo post per capire di cosa si tratta e come applicarlo). Secondo il framework ci trovavamo nel dominio del “complesso”, che sappiano essere rappresentato dalla possibilità di identificare dei pattern solo dopo una sperimentazione, quindi l’ambiente nel quale le metodologie molto strutturate falliscono, mentre quelle più “liquide” hanno una buona probabilità di successo.

Questa è stata un’ulteriore conferma che un approccio Agile poteva essere la giusta soluzione.

La necessità di introdurre dei processi a valle di una sperimentazione all’interno di un’ambiente “complesso” è sicuramente primaria, con l’obiettivo di portarlo a diventare almeno “complicato”, se non, nel tempo, addirittura “semplice”. Il come farlo, senza incidere negativamente sulle attività in corso, è il punto dolente. Abbiamo quindi ipotizzato uno scenario così composto: se l’ecosistema in cui lavora il team fosse il “mercato di riferimento”, il team il nostro “target” e i processi il “prodotto” da introdurre, potremmo applicare le pratiche di Lean Startup per soddisfare il bisogno del cliente nel minor tempo ad un costo contenuto.

A queste condizioni la risposta alla precedente domanda non può che essere si!

Ci siamo così dati alcune linee guida:

• Utilizzare cicli Learn – Build – Measure per qualsiasi attività.
• Farsi guidare dalle necessità del team piuttosto che dalle metodologie.
• Lavorare secondo reali priorità e capacità operative.
• Eliminare gli sprechi, mantenendo le best practice in essere.
• Applicare il miglioramento continuo con iterazioni e feedback costante.

Ecco quindi come abbiamo (ri)definito le fasi dell’Agile Business Process Management (ABPM):

Fase 0 – Definizione degli ambiti di intervento

Fase 1 – Discovery [processi as-is]

1.1 Workshop: Process Discovery

1.2 Incontri one-to-one

1.3 Discovery Map: realizzazione e condivisione

Fase 2 – Design [processi to-be]

2.1 Identificazione aree a priorità maggiore

2.2 Definizione processi pilota e processi secondari

2.3 Pianificazione programma di applicazione

Fase 3 – Implementation I [applicazione processi pilota]

3.1 Workshop: Process Implementation

3.2 Pratiche di continuous improvement

Fase 4 – Implementation II [applicazione processi secondari]

4.1 Definizione processi secondari

4.2 Pianificazione programma di applicazione

4.3 Applicazione processi secondari e Continuous Improvement

Dove siamo arrivati

A distanza di 3 mesi dall’avvio siamo alla fase 3.2. Abbiamo iniziato ad applicare i processi a priorità maggiore contestualizzandoli alle attività e alle capacità del team. In base alla configurazione generale (interna ed esterna) abbiamo individuato tre processi pilota:

• Demand Management
• Project Management
• Operation Management

Anche se i nomi rimandano a processi più che conosciuti, analizzati e descritti è importante ribadire che l’approccio Agile prevede una forte componente di contestualizzazione. Nel caso specifico abbiamo voluto utilizzare il naming classico per facilitare la comunicazione verso l’esterno (le altre divisioni aziendali). Ma non abbiamo applicato i processi classici (per intenderci tipo quelli del PMI), bensì abbiamo creato delle personalizzazioni specificamente studiate per l’ecosistema in cui agisce quotidianamente il team della global digital communication. Ma cosa fanno questi processi e come lo fanno sarà oggetto di un futuro post che condividerò con voi non appena avremo eseguito alcuni cicli Learn-Build-Measure!

Alla prossima.