Introduzione

Nell’articolo precedente abbiamo approfondito le attività, gli strumenti e i diagrammi usati nella fase di definizione del problema e dell’ambito del progetto, realizzata quando una iniziativa di business process change è intrapresa per risolvere dei problemi, rispondere a varie esigenze o cogliere delle opportunità di business mediante un approccio per processi.

Questa fase — le cui attività, o parte di queste, possono trovarsi in letteratura comprese nelle fasi dette di Process Discovery o Process Identification — è più chiaramente definita e rilevante, soprattutto quando l’organizzazione non è process-centric, dove quindi una delle attività fondamentali e necessarie è quella della individuazione e definizione del/dei processo/processi che sono nello scope del progetto di miglioramento e che devono essere successivamente analizzati nel dettaglio.

In un contesto organizzativo maturo nell’adozione di una gestione per processi, che ha per esempio una Business Process Architecture definita o per lo meno una mappatura dei processi di business, la fase di definizione del problema e del progetto probabilmente mancherà delle attività di individuazione e definizione dei processi, ma resteranno comunque le attività di definizione del problema e dell’ambito del progetto, soprattutto se i processi interessati alla riprogettazione sono importanti o complessi, e si vuole quindi affrontare l’impegno con efficacia e con un approccio strutturato e metodologico.

In questo articolo vedremo il ciclo di vita di un processo e le fasi che lo costituiscono, quindi approfondiremo l’analisi del processo, che è la prima attività che viene realizzata una volta che l’organizzazione ha stabilito di attivare un progetto di miglioramento e redesign di un processo di business. Parleremo della modellazione dei processi di business che, nella fase di analisi mira a definire tipicamente l’as-is e vedremo motivazioni e vantaggi che si ottengono nel modellare i processi di business di una organizzazione

Il ciclo di vita dei processi di business

Diversi sono i modelli proposti per rappresentare il ciclo di vita di un processo di business (Business Process Life Cycle). Personalmente quello che preferisco è raffigurato in figura 1 e presentato di seguito.

Questo modello ben evidenzia come la gestione di un processo di business è un processo continuo ed iterativo che ha come obiettivo il miglioramento continuo, il continuously improving. Il ciclo è composto da cinque fasi:

• analisi
• disegno
• implementazione
• rilascio
• esecuzione/monitoraggio

Vediamole di seguito nel dettaglio.

Analisi

In questa fase il Business Process Analyst realizza le attività di analisi di dettaglio del processo. L’analisi può essere realizzata in seguito all’attivazione di un progetto per realizzare un miglioramento, per risolvere un problema o per cogliere un’opportunità di business. Il progetto può essere relativo a un processo organizzativo in essere o, come abbiamo detto, il progetto può essere attivato per disegnare un processo nuovo, partendo da zero (“from scratch”), come quando una organizzazione decide di adottare un approccio per processi. I modelli realizzati in questa fase sono di norma riferiti all’as-is (current picture).

Disegno

In questa fase il Business Process Analyst realizza il progetto del nuovo processo di business che soddisfa i requisiti formalizzati nella fase precedente. I modelli realizzati in questa fase disegnano il to-be desiderato, quello che migliora il processo, che risolve le inefficienze rilevate nella fase precedente.

Implementazione

Vengono realizzati i cambiamenti organizzativi e gli interventi HR necessari (si parla di Organization Change Management) e vengono realizzati ex-novo, o adattati, i sistemi software nel caso di processi automatizzati.

Rilascio

il processo to-be viene rilasciato nella realtà organizzativa, è realizzato il roll-out e la conseguente adozione delle soluzioni implementate da parte di tutte le componenti organizzative.

Esecuzione/Monitoraggio

Una volta che il processo è stato rilasciato e portato a regime, questo viene monitorato per controllare se le performance sono in linea con i target definiti, in modo da individuare per tempo eventuali problemi e far ripartire il ciclo del continuously improving.

Le prime quattro fasi sono quelle affrontate con un approccio progettuale, attivando per l’appunto un progetto di miglioramento e redesign che, come tutti i progetti, deve essere realizzato con degli obiettivi ben precisi e in un timeframe ben definito. L’ultima fase comprende le attività che fanno parte della routine operativa quotidiana, attività dette anche ongoing activity o ongoing operation.

Approcci, ruoli, metodologie, attività, strumenti messi in campo in un caso e nell’altro sono diversi. In questo articolo approfondiremo alcuni argomenti relativi all’Analisi di Processo.

Fase di analisi e aspetti relativi agli approfondimenti

Nella fase di definizione del problema e dell’ambito del progetto, abbiamo visto che una delle attività realizzate è quella di approfondimento del processo as-is. In questa fase l’attenzione è posta sulle relazioni tra il processo e l’ambiente esterno. Infatti sono state approfondite le interazioni tra il processo e gli altri processi, sistemi, clienti e unità organizzative con il fine di comprendere meglio il problema e identificare quali sono i processi che rientrano nell’ambito del progetto [1].

Stabilito che un progetto di miglioramento e redesign deve essere realizzato, l’analisi è la prima fase del progetto vero e proprio: è il momento in cui si entra nei dettagli, si va a guardare all’interno del processo per approfondire tipicamente i il flusso delle attività del processo e la gestione del day-to-day per identificare eventuali problemi [1].

Il risultato principale di questa fase è la formalizzazione dei requisiti che devono essere soddisfatti per realizzare i risultati definiti nel Business Case che ha giustificato e autorizzato il progetto di miglioramento.

Process Relationship Diagram

Prima di scendere definitivamente nell’analisi di dettaglio di ciascun processo, se non è stato già realizzato nella fase precedente, può essere utile iniziare la fase di analisi realizzando un Process Relationship Diagram.

Questo diagramma mostra, ancora in maniera informale, le principali relazioni, con input e output, tra i processi che rientrano nell’ambito del progetto di miglioramento. Questo diagramma fornisce una visione d’insieme che può essere utile in varie situazioni e concorre a facilitare le interviste con il management dell’organizzazione.

Un esempio di Process Relationship Diagram che potrebbe essere realizzato è quello presentato dalla figura 2.

Come si nota, il diagramma non mostra tutte le relazioni possibili tra i processi, ma solo quelle che nel contesto del progetto è stato ritenuto utile evidenziare per condurre la fase di analisi.

Approfondimento del flusso

Realizzato un diagramma di insieme dei processi, come il Process Relationship Diagram, si passa ad analizzare il flusso delle attività di ciascuno dei processi disegnati nel diagramma.

A questo scopo vengono i realizzati i modelli dei processi, i diagrammi che formalizzano il flusso delle attività del processo, che rappresentano uno strumento per realizzare l’analisi del processo e al contempo uno dei risultati della fase stessa.

Gli aspetti approfonditi per individuare dove ci sono dei problemi e quindi intervenire per colmare il gap fra i processi esistenti e quelli richiesti dal management, sono relativi alle tematiche riportate di seguito

Completezza logica

Alcune attività non sono connesse alle attività relative.

Alcuni output non hanno una destinazione.

Alcuni input non hanno una destinazione.

Sequenza e duplicazione

Alcune attività sono realizzate in un ordine sbagliato.

Alcune attività sono realizzate in sequenza mentre potrebbero essere realizzate in parallelo.

Alcune attività realizzano dei risultati che restano in repository in attesa di essere elaborati.

Alcune attività sono ripetute più del dovuto.

Non ci sono regole di business per determinare il flusso o la priorità tra certe attività.

Input/output nei sottoprocessi

Gli input e gli output di alcuni sottoprocessi sono sbagliati o inadeguatamente specificati.

Gli input e gli output di alcuni sottoprocessi sono di una qualità inadeguata, di una quantità insufficiente o non sono disponibili al momento necessario (untimely).

Alcuni sottoprocessi ricevono input, o producono degli output che non sono necessari.

Alcuni sottoprocessi fanno cose che causano più lavoro ad altri sottoprocessi.

Definizione delle decisioni

Il processo, o alcuni suoi sottoprocessi, è chiamato a prendere decisioni senza adeguate informazioni o queste sono del tutto assenti.

Il processo, o alcuni suoi sottoprocessi, è chiamato a prendere decisioni senza un’adeguata o completa guida da parte della value chain o dell’organizzazione, per esempio, senza policy o business rules.

Misure dei sottoprocessi

Non ci sono — o sono inadeguate — le misure che definiscono la qualità, la quantità degli output o il tempo entro cui devono essere prodotti

Approfondimento della gestione del day-to day

Nella fase di analisi si va ad approfondire anche la gestione del processo nella sua operatività quotidiana. Gli aspetti approfonditi per individuare se ci sono dei problemi, sono tipicamente relativi alle areee che riportiamo di seguito.

Pianificazione e allocazione delle risorse

Al manager del processo sono disponibili solo misurazioni di tipo lagging e non di tipo leading [7] quindi non riesce a pianificare per tempo il lavoro e lo scheduling delle attività

Monitoraggio, feedback e controllo

I dipendenti che lavorano sul processo non sono responsabilizzati sul raggiungimento di uno o più obiettivi chiave del processo.

I dipendenti che lavorano sul processo, e raggiungono uno o più obiettivi chiave del processo, non sono premiati o sono penalizzati per il raggiungimento (p.e.: gli viene assegnato più lavoro).

Ai dipendenti che lavorano sul processo non sono fornite adeguate informazioni sulle perfomance del processo.

Ai dipendenti che lavoranoo sul processo vengono fornite solo misurazioni di tipo lagging e non di tipo leading quindi non riescono a pianificare per tempo il proprio lavoro e lo scheduling delle attività.

Conflitto tra obiettivi e incentivi

Al manager del processo vengono assegnati obiettivi funzionali/dipartimentali che sono incompatibili con gli obiettivi del processo.

Il manager non ha l’autorità, il budget o le risorse richieste per gestire concretamente il processo.

Responsabilità del manager

Il manager del processo non ha la responsabilità per raggiungere uno o più obiettivi del processo.

Il manager è penalizzato per il raggiungimento di uno o più obiettivi chiave del processo.

Al manager del processo non sono fornite adeguate informazioni sulle perfomance del processo di cui è responsabile.

Perché analizzare e realizzare un modello dei processi?

Sembra una domanda dalla risposta scontata, ma forse non lo è del tutto. Andiamo a vedere alcune delle risposte che possono essere date alla domanda, con l’aiuto dell’inforgrafica [6] riportata in figura 3.

Documentare i processi esistenti (as-is)

Per conoscere i processi di business correnti dell’organizzazione (current picture). Questo permette di far venire alla luce eventuali aspetti sconosciuti che magari causano dei problemi.

Passaggi di mano

Molti processi sono interdipartimentali: avere una visione completa, end-to-end del flusso di processo può contribuire a colmare gap, ridondanze, colli di bottiglia, aspettative non corrette.

Linguaggio comune

Per consentire di adottare un linguaggio comune evitando il proliferare di notazioni che per essere comprese da tutti gli interessati hanno bisogno di essere tradotte con inevitabilmente perdita di significato.

Gerarchia dei processi

Creare un modello gerarchico dei processi consente di avere a disposizione diversi livelli di astrazione che permettono di comunicare le informazioni con il giusto livello di dettaglio a seconda dell’interlocutore che si ha di fronte.

Catalogo dei processi dell’organizzazione

Realizzare i modelli dei processi dell’intera organizzazione consente di avere un repository condiviso e accessibile da chiunque nell’organizzazione che ha accesso allo stesso.

Benchmarks

Quando i processi sono modellati possono essere definiti gli indicatori di performance per ciascuno di questi che permettono il benchmarking con gli standard interni e di settore.

Enterprise architecture

Realizzare l’architettura dei modelli dei processi consente di mettere in relazione i processi con gli altri elementi delle altre architetture dell’organizzazione, in primis HR e sistemi IT. Questa informazione è estremamente utile durante il change management per rilevare quali processi possono essere impattati da cambiamenti al sistema e viceversa.

To-be

Modellare l’as-is è solo il primo passo per individuare problemi, colli di bottiglia, ridondanze, gaps che possono essere superati progettando un nuovo processo to-be, ipotizzando anche l’automazione dei processi che possono essere monitorati per garantire così un continuo miglioramento.

Conclusioni

In questo articolo abbiamo approfondito l’analisi del processo, la prima attività realizzata quando un progetto di miglioramento e redesign è attivato per risolvere problemi, concretizzare delle opportunità mediante un approccio per processi. Abbiamo visto che in questa fase il Business Process Analyst solitamente approfondisce il flusso delle attività del processo per identificare eventuali inefficienze e azioni di miglioramento. Allo scopo realizza dei modelli formali del processo as-is dell’organizzazione per avere in forma chiara, e comprensibile per tutti gli interlocutori, un quadro di come l’attuale processo lavora. Si sono visti quali sono i vantaggi che l’organizzazione trae dall’avere i modelli dei propri processi organizzati.

Nel prossimo articolo, affronteremo il tema della notazione, ossia la Business Process Model Notification (BPMN), che rappresenta ad oggi lo standard de facto per la realizzazione dei modelli dei processi di business.

Eustachio Nicoletti

Sono sposato, ho due figlie e, per non soffrire troppo la situazione di minoranza, ho imposto la presenza in famiglia di Balu‘: un derivato setter inglese maschio. Sono laureato in Informatica e certificato PMP-PMI. Nella mia carriera professionale ho ricoperto i ruoli di responsabile di prodotto, responsabile di unità di business, tecnico-pre sales, progettista, delivery manager, business process analyst, software architect e project manager. I principali ambiti applicativi in cui ho maturato esperienze sono automazione dei reparti di neonatologia, human capital management, gestione dei processi della qualità, per aziende e organizzazioni piccole, medie e di dimensione internazionale. Attualmente lavoro come Business Process Analyst e Project Manager presso una azienda di Reggio Emilia esperta nello sviluppo di Sistemi Informativi per la Qualità.