Introduzione

Nella serie [1] sulla Business Process Architecture (BPA), quando si è approfondito una delle sue componenti principali, il sistema di misurazione delle performance dei processi di business, abbiamo detto che questo è una componente essenziale della BPA in quanto non solo fornisce gli strumenti per allineare le misurazioni degli strategic goal a quelle dei processi di business dei diversi livelli gerarchici, ma permette anche di definire le priorità di intervento sulla base delle misurazioni che individuano i processi che non performano come definito.

Negli articoli di questa nuova serie andremo ad approfondire alcune delle tematiche che si incontrano quando devono essere attivati una riprogettazione e miglioramento di un processo di business (Process Redesign and Improvements Project) per fare in modo che le prestazioni di un processo siano soddisfacenti, cioè in linea con gli obiettivi strategici della organizzazione.

Business Process Change: quando è necessario?

Iniziative di business process change, tese alla progettazione, riprogettazione e miglioramento dei processi di business, non riguardano solo le organizzazioni process-centric mature che hanno una BPA formalizzata, ma anche quelle organizzazioni che hanno un problema o una esigenza di business e vogliono risolverlo adottando un approccio per processi. Per problema o esigenza, intendiamo una serie di condizioni in cui l’azienda può venire a trovarsi per motivazioni interne o esterne: necessità di un cambiamento derivante da inefficienze interne, adeguamento a norme o nuove leggi, impatto di fattori ambientali, desiderio di cogliere opportunità di business, ristrutturazioni organizzative, introduzione di novità tecnologiche e così via.

Definire problema e ambito

Il primo problema che in questo caso si incontra, e a cui bisogna dare risposta, è quello della definizione chiara del problema e dell’ambito del progetto: scoping process problem [2]. In altri termini, la prima attività da realizzare è quella di capire in maniera precisa la natura del problema e di individuare gli interventi necessari per risolverlo, quindi rispondere alla domanda: “what’s in? what’s out?”.

Domanda che nel mondo dei progetti non è di poco conto perché permette di definire cosa è incluso nel progetto e cosa invece non lo è, e deve restarne fuori. Di conseguenza, permette di determinare esattamente quali attività il progetto deve realizzare, quali saranno le risorse, l’effort e il budget che serviranno per risolvere il problema.

Non confondere le cause dei problemi con i sintomi

Come si può intuire, non è sempre banale definire la natura del problema, perché spesso questo viene espresso in maniera informale, in termini generici, vaghi, confondendo cause ed effetti:

• “sforiamo sempre i tempi di consegna”
• “abbiamo un numero di reclami eccessivo”
• “i resi negl’ultimi anni sono cresciuti esponenzialmente”

Questi sono solo alcuni esempi del modo in cui un problema avvertito dal management aziendale può essere espresso, ma non necessariamente rappresentano il problema, quanto invece ne descrivono l’effetto.

Esistono a tal proposito delle metodiche e degli strumenti che ci consentono di evidenziare i problemi in maniera più compiuta e ragionata. Li vediamo di seguito.

Gap Model

Un primo strumento che può essere utile in questa prima fase di definizione del problema è il Gap Model, schematizzato dalla figura 1.

Il modello esprime bene come il gap può essere di due tipologie diverse: un gap di prestazione e un gap di capacità. I gap vengono esposti con una formula “As is / To be” che indica la situazione attuale in confronto alla situazione auspicata in un dato periodo.

Performance Gap

Esempi di gap di performance possono essere I seguenti:

• As is / To be: Oggi i reclami sono 3500 all’anno; i reclami devono essere dimezzati.
• As is / To be: Oggi il tempo medio di redazione di una offerta è 5 giorni; questo tempo medio deve essere di 2,5 giorni.
• As is / To be: Oggi il tempo medio del time to market dei nostri prodotti è di 3 anni; questo tempo medio deve essere di 2 anni.

Capabilities Gap

Esempi di gap di capabability possono essere I seguenti:

• As is / To be: La selezione del personale oggi non è fatta seguendo delle procedure definite; è necessario adottare delle procedure internazionali standardizzate per la selezione e l’inserimento del personale.
• As is / To be: Gli ordini vengono inseriti da persone dipendenti dell’azienda; bisogna sviluppare o acquistare un sistema software che permetta al cliente di inserire direttamente gli ordini.
• As is / To be: Oggi i dati sulla manutenzione degli automezzi vengono inseriti in tre sistemi software differenti; bisogna adottare un sistema di manutenzione modulare e integrato.

Individuare il gap

Come si può intuire, determinare qual è il tipo di gap che preoccupa l’organizzazione può fornire indicazioni su quale tecnica di analisi e di riprogettazione può essere più utile nelle fasi successive del progetto [2].

Una volta definito il gap, il team di progetto deve passare a intervistare il management della organizzazione per comprendere qual è, secondo il loro punto di vista, il problema. Sulla base del contesto in esame, il team deve fare uno sforzo per capire quando si sta parlando di problema, quando di causa o di effetto finale. Non è sempre cosa semplice. Al termine di questo lavoro può essere disegnato uno schema come quello presentato nella figura 2.

Un ulteriore passo in avanti per fare chiarezza consiste nel tracciare anche le relazioni tra cause, problemi ed effetti.

Prima definizione del processo As is

Definito il problema, è il momento di determinare l’ambito del progetto, quindi qual è il processo (o i processi) As is che deve essere oggetto del progetto business process change e che dovrà quindi essere analizzato nelle fasi successive del progetto.

Il team di progetto può iniziare a chiedere al management qual è, a loro modo di vedere, il processo dove è presente il problema e quali sono gli input che danno il via al processo e quali sono gli output e i risultati alla conclusione dello stesso [2].

Il processo da riprogettare e le sue principali attività

Un primo diagramma, semplice, che si può ottenere è quello disegnato in figura 3.

A questo punto il team di progetto deve individuare le principali attività (sottoprocessi) che compongono il processo, gli input, gli output e le principali misurazioni che in nostri referenti aziendali possono aver citato durante le interviste. Il diagramma precedente può evolvere per esempio in una versione più dettagliata come quella presentata in figura 4.

Va notato che il diagramma ottenuto non adotta nessun formalismo standard ed è disegnato nella forma più semplice possibile: questo perché deve essere compreso facilmente e senza ambiguità da tutti gli attori che sono coinvolti a vario titolo nel progetto, che in questa fase devono essere intervistati per comprendere se la definizione data del problema è corretta, quali sono “a loro parere” i sottoprocessi che sono la causa del problema e che devono quindi essere successivamente analizzati. Per esempio si potrebbe scoprire che la causa del problema non è nella Schedulazione delle Consegne, come il management pensava, ma anche nella indisponibilità per rottura dei mezzi di trasporto: quindi, il processo di Manutenzione dei Veicoli deve essere incluso nell’ambito progetto.

Chi è interessato (d)al processo

Un’altra attività importante di questa prima fase è quella della individuazione di tutti gli stakeholder interessati al processo che deve essere cambiato o che devono comunque rientrare nell’ambito di progetto: i clienti, il management, il personale, i fornitori. Nella fase di analisi, i loro rappresentanti dovranno essere intervistati per comprendere il processo da tutti i punti di vista [2].

Approfondimento del Processo As is

Una volta ottenuta una definizione di base del problema e del processo, e degli eventuali sottoprocessi che lo compongono, è il momento di intervistare gli stakeholder individuati con lo scopo di precisare e comprendere meglio il processo e quindi il problema e l’ambito del progetto.

Process Scope Diagram e IDEF0

Uno strumento che può essere utile allo scopo è il Process Scope Diagram. Come si nota, non si sta parlando ancora di diagramma del flusso di processo che è invece più utile in una fase successiva di analisi di dettaglio, quando si ha la necessità di comprendere il funzionamento interno del processo. In questa fase, quando si è in una fase ancora di comprensione chiara del problema e del processo, risulta più utile il Process Scope Diagram, che focalizza più l’attenzione sulle relazioni tra il processo e l’ambiente esterno [2].

Il Process Scope Diagram, chiamato anche IGOE Diagram (Input, Guide, Output, Enabler Diagram) è stato sviluppato da Roger Burlton ed è uno di tool principali utilizzati nella metodologia di riprogettazione e miglioramento dei processi elaborata da Roger Burlton e Paul Harmon con la BPTrends Process Redesign Methodology [3].

Il Process Scope Diagram è stato derivato dal modello IDEF0 (Integration Definition for Function Modeling), nato su commissione dell’USAF (l’aeronautica militare statunitense), nell’ambito di una metodologia strutturata di analisi e progettazione dei sistemi software (SADT Structured Analysis and Design Technique): c’era infatti la necessità di poter disporre di un metodo formale per analizzare ed illustrare un sistema da un punto di vista funzionale.

I modelli IDEF0 aiutano proprio a organizzare il processo di analisi di un sistema dal punto di vista funzionale e a promuovere la comunicazione tra analista e cliente. Dal punto di vista della comunicazione, IDEF0 migliora la partecipazione degli esperti di dominio, coinvolgendoli nel processo decisionale attraverso rappresentazioni grafiche di semplice interpretazione.

La figura 5 mostra un modello esemplificativo del Process Scope Diagram finale che potrebbe essere ottenuto al termine di questa fase del progetto di riprogettazione e miglioramento.

Come si legge un Process Scope Diagram

Andiamo a descrivere il Process Scope Diagram nelle sezioni ed elementi che lo compongono. L’area centrale (Process Area) è l’area dove sono stati disegnati il processo e l’elenco dei sottoprocessi che è stato stabilito debbano essere analizzati nelle fasi successive del progetto.

L’area a sinistra (Inputs Area) è dove sono stati indicati gli input nella process area e da dove questi provengono: clienti, sistemi, altri processi, unità organizzative.

L’area in alto (Controls Area) è dove sono stati indicati i documenti, le regole di business, le organizzazioni, i processi di management che gestiscono e controllano i processi nella process area.

L’area in basso (Enablers Area) è dove sono stati indicati gli elementi di supporto e che abilitano i processi nella process area: risorse IT, risorse umane, macchinari, facilities.

L’area a sinistra (Outputs Area) è dove sono stati indicati gli outputs dai processi della process area e i destinatari: altri processi, sistemi, clienti, organizzazioni, unità organizzative.

Per ciascuna iterazione individuata e analizzata si è valutato se fuziona o se ci sono dei problemi; in base a questo, poi:

• è stato disegnato un pallino di colore bianco o è stata semplicemente ignorata, se funziona;
• si è messo un pallino blu se si sono evidenziati dei problemi nel processo, e se deve essere analizzato ma non si è certi che debba essere cambiato;
• si è messo un pallino rosso se si sono evidenziati dei problemi nel processo, e se deve essere analizzato e si è anche certi che debba essere cambiato.

Infine, la linea marcata rossa, che raggruppa oltre ai processi nella process area anche il processo Manutenere Veicoli, indica che nell’ambito del progetto deve essere incluso anche quel processo che inizialmente non era previsto come causa del problema e le note accanto all’interazione con quel processo danno una chiara evidenza della motivazione [2].

Il modello presentato in figura 5 è chiaramente esemplificativo: sul diagramma sono state disegnate solo alcune delle interazioni che è possibile identificare in un caso reale. Inoltre per ciascuna delle interazioni, sul diagramma sono stati annotate solo alcune delle considerazioni o problemi identificati.

Altre rappresentazioni dei processi

È anche possibile usare un documento (tabella Word, foglio Excel) che elenca tutti i processi in ambito e per ciascuno di questi si registrano le informazioni di rilievo ricavate durante le interviste, ad esempio manager responsabile, risorse usate, misurazione di successo, e l’elenco di tutte le interazioni con i problemi identificati per ciascuna di queste. In questo caso sul diagramma resterebbero tutti gli altri elementi grafici che abbiamo visto, ma questo non farebbe comunque perdere di valore il modello risultante.

È importante notare che il punto di forza del Process Scope Diagram è la sua informalità. Questo permette in maniera semplice e veloce, sin dalle fasi iniziali del progetto, di registrare importanti informazioni sui problemi e sui processi che dovranno essere successivamente analizzati con più precisione e dettaglio.

Per realizzare un’analisi di dettaglio sono necessari altri tipi di modelli, quali i diagrammi del flusso delle attività di processo, che hanno bisogno di più tempo e sono più laboriosi da ottenere, perché usano dei formalismi codificati (quali per esempio quelli dello standard BPMN). D’altra parte un modello quale quello che mostra il flusso delle attività del processo non risulta adeguato per raggiungere gli obiettivi delle fase iniziale del progetto che sono, come detto, la definizione chiara del/dei problema/i e dell’ambito di progetto di business process change [2].

Business case

Al termine di questa fase, ottenuta una definizione del/i problema/i e del/i processo/i da cambiare, prima di partire a testa bassa nella realizzazione delle attività di progetto, è opportuno realizzare un Business Case del progetto.

“Il Business Case è un documento che fornisce le informazioni necessarie dal punto di vista commerciale per determinare se il progetto vale o meno l’investimento richiesto” [7]. È il documento quindi usato dal management per prendere la decisione se proseguire con il progetto o meno. Deve allora contenere al minimo le seguenti informazioni: le esigenze di business che hanno portato al business case, l’analisi dei costi-benefici e l’ambito del progetto.

Certo la versione realizzata in questa prima fase del progetto può non essere molto precisa e in alcune delle sezioni può contenere delle informazioni di massima, ma questo non esime il team di progetto dal fare ogni sforzo possibile per fornire al management dell’organizzazione il miglior business case per poter prendere le decisioni. D’altra parte si ricorda che il business case deve essere rivisto periodicamente, per esempio al temine di ogni fase di progetto, per determinare se rsussistono le esigenze e i problemi di business iniziali e se il progetto è allineato con il business case (di cui ricordiamo è responsabile il project manager titolare del progetto).

Business Case: come è composto

Ma va vediamo nel dettaglio quali sono le sezioni che possono comporre un modello di business case relativo a un progetto di riprogettazione e miglioramento di un processo di business, sulla base di quanto abbiamo detto sin ora. Questo potrebbe contenere le seguenti sezioni:

• nome del progetto;
• nome del project manager;
• esigenze/problema di business dato in forma descrittiva;
• descrizione del Processo As is;
• descrizione del Processo To be;
• definizione dell’Ambito di progetto;
• descrizione del performance e capability gap e descrizione delle attività e risultati che si vogliono raggiungere nel To be per colmare il gap;
• definizione delle fasi di progetto;
• risorse, tempi e costi del progetto;
• Master Schedule o Milestone Schedule del progetto;
• definizione dei rischi (minacce e opportunità) di progetto.

Conclusioni

Quando deve essere attivato un progetto di riprogettazione e miglioramento di un processo di business, la prima attività da realizzare è quella della definizione del problema e dell’ambito del progetto (scoping process problem).

In questo articolo abbiamo approfondito gli step, i principali strumenti e diagrammi utilizzati e i principali risultati raggiunti in questa fase. Abbiamo anche sottolineato che questa è un fase iniziale essenzialmente di comprensione, dove è importante che i modelli e lo stile usato siano semplici ed informali, con lo scopo di condividere e raccogliere il contributo di tutti quelli che sono interessati al processo da cambiare.

La fase successiva, di analisi di dettaglio, dove risulteranno più utili le tecniche di modellazione del flusso delle attività di processo, richiederà invece formalismi ben codificati e dettagliati quali quello dello standard BPMN. Le tecniche di modellazione del flusso di processo e dei formalismi ad hoc sviluppati nel corso degli anni sono un tema di un interesse tale che merita un approfondimento a sé stante.