AlfonsoStuardi.com

Secondo Michael Hammer[1], uno dei “guru” del BPR e fondatore del termine stesso, il Business Process Reengineering è un “ripensamento fondamentale ed una radicale riprogettazione dei processi, per raggiungere miglioramenti drammatici nelle misure delle prestazioni chiave, come costi, qualità, servizio e velocità”, realizzati solitamente attraverso il supporto delle tecnologie informatiche. In altre parole il BPR è un approccio strutturato di management che mira ad ottenere miglioramenti aumentando l’efficienza e l’efficacia dei processi intra e inter organizzativi. Hammer evidenzia quattro parole chiave nella definizione, che sono a suo parere le più significative: Fondamentale, Radicale, Drammatiche e Processi.

Fondamentale: Secondo Hammer il BPR serve a determinare “cosa” l’organizzazione deve fare e dopo a “come” farlo. Ci si deve concentrare su come le cose dovrebbero essere (to be) e non su come sono (as is). Le due domande fondamentali dunque sono: “Che cosa stiamo facendo?” e “Perché lo facciamo cosi?” (Cosa e Come). Forzare le persone a porsi queste due domande rende le regole esistenti obsolete, errate ed inappropriate. BPR significa ricominciare da capo, senza vincoli esistenti dati ed accettati per scontati.

Radicale: Una radicale riprogettazione dei processi di business significa andare alla radice del problema, non migliorare i processi e le procedure già esistenti. Secondo Hammer, “radicale riprogettazione” significa cancellare tutte le strutture e le procedure presenti e ripensare dei modi totalmente nuovi di lavorare.

Drammatiche: Il BPR non serve ad ottenere miglioramenti incrementali ma mira a produrre discontinuità nelle prestazioni dei processi. Ci sono tre possibili situazioni per le quali l’organizzazione ha bisogno di un progetto di BPR:

-        quando l’organizzazione è in una situazione disperata ed ha bisogno di miglioramenti straordinari per sopravvivere;

-        quando l’organizzazione va abbastanza bene, ma il management prevede serie e reali minacce per il suo successo futuro;

-        quando l’organizzazione va bene e non sono previsti problemi ma i manager, non appagati, vogliono fare ancora meglio ed aumentare il gap tra l’organizzazione e i suoi concorrenti.[2]

Processi: L’orientamento ai processi è considerato da alcuni l’aspetto principale del BPR. Hammer sostiene che la maggior parte delle organizzazioni è concentrata su compiti, persone e strutture piuttosto che sui processi. Esistono varie definizioni e classificazioni di processo: un processo può essere definito come un insieme di attività che utilizza input di varia natura per creare un output che è valore per il cliente finale [M. Hammer, J. Champy, 1993; M. Klein, 1993]. Similmente Thomas H. Davenport[3] lo definisce come un insieme organizzato di attività finalizzate alla realizzazione di un output per uno specifico cliente o mercato.

Diverse prospettive possono essere utilizzate per classificare i processi: funzionali, comportamentali, organizzative ed informative [B. Curtis et al., 1992]. Inoltre, i processi possono essere classificati, in funzione del loro scopo, come processi “core”, processi di supporto, processi della rete di business e processi gestionali [M. Earl, B. Khan, 1994]. Esistono, infine, tre macrocategorie di processi in relazione a dove questi si manifestano: processi inter-organizzativi, inter-funzionali ed inter-personali [T. H. Davenport, J. Short, 1990; K. D. Fiedler et al, 1994].

---

[1] Studente in EECS press oil MIT ha conseguito BS, MS e Ph.D. nel 1968, 1970 e 1973. Professore presso il Dipartimento di Computer Science del MIT ha pubblicato articoli su importanti periodici quali Harvard Business Review e The Economist. E’ il proponente della visione orientata del business management orientata ai processi.

[2] Avere il coraggio di cambiare anche quando le cose vanno bene è uno dei principi del Change Management che per molti aspetti si lega al BPR, soprattutto nella fase implementativa del progetto.

[3] Nato nel 1954 è un docente universitario ed autore specializzato in business process innovation e knowledge management. Attualmente ricopre il ruolo di President Distinguished Professor in Information Technology and Management al Babson College e quello di Director of Research per il Babson Executive Education. Ha coordinato numerosi programmi di ricerca sul knowledge management e sul process management.

Una delle perenni sfide nello sviluppo di sistemi a supporto del business è quella di fare in modo che gli sviluppatori implementino effettivamente quelli che sono i requisiti funzionali realmente necessari ai key users del processo.

La definizione dei requisiti di business è spesso compito esclusivo degli utenti finali, i quali la realizzano secondo il proprio formalismo e la propria prospettiva, in una modalità che può essere più o meno accurata, completa e chiara.

Gli sviluppatori, d’altro canto, non hanno la stessa prospettiva e la stessa conoscenza profonda del processo di business: non sempre, quindi, riescono a comprendere appieno i requisiti a loro inoltrati.

La soluzione, spesso adottata dal sottoscritto, è quella di riunire assieme i 2 gruppi (key users e sviluppatori) in sessioni di lavoro nelle quali  i requisiti funzionali potranno essere opportunamente tradotti in un modello. In queste sessioni è importante la presenza di un facilitatore, in grado da fungere da interfaccia tra il modello dei processi di business ed il modello tecnico, ed, eventualmente, un progettista esperto in grado di definire i modelli di base sui quali verranno incentrate le seguenti attività di design, sviluppo e test (spesso i due ruoli sono ricoperti da una sola figura).

E’ la comunicazione, in sostanza, la chiave per il successo di un progetto di sviluppo software. Accade molto più spesso di quanto si possa pensare che, banalmente, un progetto fallisca totalmente o sfori costi/tempi perchè nessuno si è preso il tempo necessario per riunire i diversi players in una stessa stanza, assicurandosi che tutti siano sulla stessa lunghezza d’onda.