Analisi e descrizione dei processi aziendali: il caso di studio della Segreteria Studenti della facoltà di Ingegneria

 8
 
Ma, come in ogni altro contesto, è praticamente impossibile tentare di gestire, e ancor più di 
migliorare, ciò che non si conosce perfettamente; pertanto, il punto di partenza per ogni attività 
di miglioramento è l’analisi, la descrizione di un processo, tanto di uno già esistente per 
migliorarlo, quanto di uno nascente, per definirne preliminarmente le criticità e i punti di forza 
atti a guidarne la corretta gestione.  
L’intento del presente lavoro di tesi è stato proprio l’approccio alla descrizione dei 
processi, sfruttando la metodologia RUP, servendosi del linguaggio UML, in particolare  
della potenza descrittiva ed evocativa del modello dei Casi d’uso; rappresentare poi tutto 
questo mediante gli strumenti software della IBM Rational: RequisitePro e Rose. 
Questo lavoro si propone i seguenti obiettivi: 
 ξ  Definire e approfondire i concetti di Workflow management e descrizione di 
Processi aziendali; 
 ξ  Tracciare il percorso che ha fatto dello Unified Modeling Language (UML) uno 
standard OMG per la formalizzazione dei processi; 
 ξ  Descrivere la tecnica UML dei Casi d’uso e la rappresentazione dei sistemi tramite 
il Main Use Case Diagram 
 ξ  Introdurre la metodologia RUP e gli strumenti software della IBM Rational: 
Rational RequisitePro e Rational Rose 
 ξ  Definire il “Requirement Management” come elemento critico per la corretta 
gestione dei Processi 
 ξ  Considerare il Caso di studio della Segreteria Studenti della Facoltà di Ingegneria, 
scegliendo al suo interno il Processo “Piani di Studi” per analizzarlo e descriverlo 
Quando si vuole descrivere un Processo ancora da creare, non si può fare riferimento ad 
altro che ad una accurata analisi dei requisiti del sistema, dello scopo che il Processo 
dovrebbe raggiungere e dei vincoli che deve rispettare. Ma quando si vuole descrivere un 
processo già esistente, ma che non sia ancora stato formalizzato, come nel presente caso, i 
riferimenti da tenere in considerazione non mancano; infatti, per capire effettivamente 
come funziona un sistema ci sono almeno tre possibili vie:  
1. Utilizzare il sistema; 
2. Intervistare tutti i soggetti coinvolti; 
3. Studiare tutta la modulistica e il materiale cartaceo di ogni tipo relativo al processo 
stesso. 
 9
Le ultime due sono state le strade da me percorse, permettendomi, così, di avere un’idea 
abbastanza chiara di come il processo relativo ai Piani di Studi realmente funzionasse.  
Conclusa così la fase iniziale di analisi, ho effettuato la descrizione e la modellazione di 
quanto osservato; si inserisce qui l’utilizzo degli strumenti software della IBM Rational, 
RequisitePro e Rose. Con il primo ho potuto descrivere, in appositi documenti Word, i 
Casi d’uso individuati nella preliminare fase di analisi, e, cosa non meno importante, 
definire Requisiti e Features del Sistema fornendo una rappresentazione matriciale 
dell’impatto degli uni sulle altre; Rational Rose, mentre, mi ha supportato nella stesura del 
Main Use Case Diagram, una rappresentazione del sistema di immediata chiarezza per 
addetti ai lavori e non. 
Poiché il presente lavoro è stato svolto all’interno del Tirocinio intra moenia svolto presso 
il dipartimento di Informatica e Sistemistica, ho deciso analizzare il processo relativo ai 
Piani di Studi del Corso di Laurea in Ingegneria Informatica (anche perché, essendo questo 
uno dei Corsi di Laurea più affollati dell’intera Facoltà, presenta complessità di gestione 
maggiori rispetto ad altri Corsi, e riuscire modellare ciò che è più complicato, rende 
sicuramente più agevole fare lo stesso per ciò che è più semplice). 
L’elaborato si articola in sette capitoli: 
Nel primo capitolo si introducono i concetti di Workflow Management e di Processo 
aziendale, definendo per quest’ultimo l’importanza di un corretto approccio alla sua 
gestione e alla sua descrizione mediante metodologia RUP.  
Nel secondo capitolo, dopo un breve accenno all’approccio Object Oriented, è tracciato il 
percorso che ha fatto dello Unified Modeling Language (UML) dei “Tres Amigos” Boock, 
Rumbaugh e Jacobson uno standard OMG per la formalizzazione dei Processi; ne sono poi 
descritte le principali caratteristiche e i Diagrammi che rientrano nello standard.  
Il terzo capitolo è incentrato sui Casi d’uso come tecnica del linguaggio UML. 
Nel quarto capitolo  è presente ancora un’introduzione alla metodologia RUP e agli 
strumenti software Rational RequisitePro e Rational Rose. 
Il quinto capitolo è relativo al “Requirements managemnt”, con la definizione dei Requisiti 
all’interno di un progetto di sviluppo software come fattore critico, e la proposta di una 
metodologia per la gestione degli stessi. 
Infine, negli ultimi due capitoli, è presentato il Caso di Studio su cui è incentrato il 
presente elaborato: il processo relativo ai Piani di Studi all’interno della Segreteria Studenti 
della Facoltà di Ingegneria: 
 10
il sesto costituisce un breve excursus sulla Normativa universitaria Nazionale e di Ateneo 
che guida la definizione del Piano di Studi del Corso di Laurea in Ingegneria Informatica. 
nel settimo è descritto tutto il lavoro di descrizione e rappresentazione del processo “Piani 
di Studi”, partendo dalla fase delle interviste ai soggetti coinvolti, fino alla descrizione dei 
casi d’uso individuati a mezzo dello Strumento RequisitePro, e la rappresentazione del 
Main Use Case Diagram mediante lo strumento Rational Rose. 
Come già anticipato, il presente lavoro è iniziato con la fase delle interviste ai soggetti 
coinvolti nel processo. Pertanto, è per me doveroso citare la preziosa collaborazione della 
direttrice della Segreteria Studenti della Facoltà di Ingegneria, la dott.ssa Seccia, e di tutti 
gli impiegati che hanno esaurientemente risposto ad ogni mio interrogativo circa il 
funzionamento del Processo; a loro va il mio sentito ringraziamento.  
 
 11
Capitolo 1 
1 WORKFLOW MANAGEMENT E DESCRIZIONE DEI PROCESSI 
AZIENDALI 
 
1.1 Introduzione 
 
 Per WORKFLOW, o automatizzazione dei processi si intende: 
“Un sistema che in modo completo definisce, gestisce ed esegue un flusso di lavoro 
attraverso l’esecuzione di un software, secondo un ordine e regole guidati da una 
rappresentazione automatica del flusso logico del processo”. 
Il Workflow può inoltre essere considerato come uno strumento per la definizione, 
l’esecuzione e il monitoraggio dei Processi. Come supporto per la definizione dei processi, 
è innanzitutto uno strumento di organizzazione aziendale, in quanto ogni organizzazione ha 
caratteristiche diverse che si evolvono nel tempo. La definizione dei processi rappresenta 
anche un aspetto estremamente importante del Knowledge Management, ed un importante 
strumento di diffusione. Inteso come supporto per l’esecuzione dei progetti, il Workflow 
gestisce: 
 ξ  i cicli produttivi; 
 ξ  i flussi di informazioni. 
 I flussi di informazioni richiedono: 
 ξ  interattività  
 ξ  integrazione con l’esterno 
 ξ  possibilità di accesso a tutte le infrastrutture, compreso il WEB. 
Quindi, un efficace sistema di Workflow dovrebbe: 
 ξ  Consentire una definizione dei processi semplice, intuitiva e “scalabile” secondo i 
gradi di complessità presenti; 
 ξ  Permettere una forte “elasticità” nel governo dell’applicazione (esigenza della 
P.A.). 
 ξ  Essere facilmente diffondibile tra gli utenti (anche per favorire la “customer 
satisfaction”); 
 ξ  Presentare un alto grado di possibilità di integrazione con tutti i diversi possibili 
flussi informativi; 
 ξ  Essere economico; 
 12
Va però considerato che i prodotti di workflow normalmente mancano di flessibilità dato 
che è estremamente improbabile che gli strumenti forniti possano coprire tutte le casistiche 
che si possono verificare modellando i flussi informativi di un’organizzazione; inoltre, gli 
stessi prodotti tendono a “coprire” del tutto le applicazioni rendendole di fatto non 
esportabili su altri supporti o in diversi contesti, ed abbassando anche la qualità media delle 
realizzazioni informatiche, in quanto risulta impossibile inserire soluzioni diverse più 
avanzate in punti strategici delle stesse. 
 
1.2 Workflow Management 
 
Con il termine Workflow Management (WfM) s’intende la semplificazione o automazione 
tramite tecnologie informatiche di un processo di business o di parte di esso. 
Una definizione sufficientemente esaustiva di WfM è la seguente: 
“L’automazione, in tutto o in parte, di un processo aziendale ( business process ) nel quale, 
documenti, informazioni e compiti sono inviati (elettronicamente) da un partecipante ( 
risorsa umane e/o IT ) ad un altro per essere eseguiti o elaborati, secondo un insieme 
predefinito di regole procedurali, per raggiungere un obiettivo comune di business ( 
business goal )”.  
Da quanto detto si evince quindi che il  WfM si basa su un sistema IT, definito Workflow 
Management System (WfMS), che costituisce un supporto informatico per l’automazione 
procedurale. 
Un WFMS è un sistema che definisce, crea, gestisce ed esegue workflow  attraverso uno o 
più “workflow engine” capaci di interpretare la definizione dei processi, interagire con i 
partecipanti e utilizzare applicazioni e strumenti software esterni, provvedendo quindi 
all’automazione di processi di business attraverso la gestione di sequenze d’attività di 
lavoro e l’invocazione di appropriate risorse umane e/o IT associate alle varie attività. 
Dunque un WfMS è un software che si rivolge ad un gruppo di individui operanti in 
un’impresa; in particolar modo interessa tutti i procedimenti che trattano un fatto, interno 
od esterno, dal momento del suo avvenimento fino al termine del suo trattamento. Per ogni 
fase di un procedimento, il sistema di workflow crea un caso poiché è a conoscenza delle 
funzioni da svolgere e della procedura da applicare per i casi di sua competenza. Questo 
caso obbedirà ad una procedura che descrive con precisione le tappe del trattamento, la 
 13
loro concatenazione, la responsabilità di ciascun oggetto, e per ogni tappa, le operazioni 
necessarie. 
Dal momento in cui questo caso è stato creato, il WfMS presenta le fasi da eseguire 
conformemente alla procedura alla quale il caso obbedisce. Inoltre esso distribuisce le 
varie fasi agli agenti secondo le regole di gestione determinata dalla procedura stessa. 
Terminata una tappa, il sistema di workflow crea quelle che seguono e le destina agli 
agenti in funzione delle regole prestabilite. Questo ciclo prosegue fino al termine del caso. 
Questo è il motivo del perché l’introduzione del workflow costituisce un cambiamento 
netto nell’organizzazione di lavoro delle imprese: una applicazione di questo tipo influenza 
direttamente i processi alla base, ne segue l’evoluzione, attribuisce compiti agli attori, 
tratta le eccezioni, segue le scadenze. 
Interessandosi alle procedure dell’impresa, il workflow prende in considerazione i processi 
di produzione corrispondenti alle finalità dell’impresa stessa, ad esempio dalla domanda 
del cliente fino alla sua completa soddisfazione. Inoltre, durante tutto il processo, registra i 
dati che permettono di effettuare l’analisi dei costi e dei carichi di lavoro. 
Per questi motivi il workflow trasforma le attività legate all’informazione in vere e proprie 
attività industriali: misurabili, pianificabili e controllabili nel tempo; il guadagno in 
produttività che una applicazione di workflow può apportare si attesta dal 30 al 50 % 
relativamente ai compiti che essa automatizza. 
Molti produttori di software al giorno d’oggi offrono prodotti di WfMS, tuttavia, l’assenza 
di uno standard in materia, non consente la cooperazione e l’interoperabilità di differenti 
prodotti di WFM, il che porta, come conseguenza, all’esistenza di isole incompatibili di 
automazione di processo.  Sulla base di tale problema, nell’agosto del 1993 è stata fondata 
la Workflow Management Coalition  (WfMC), un’organizzazione internazionale no-profit 
che comprende venditori di tecnologia WfMS, utenti ed analisti, il cui obiettivo 
predominante è quello di favorire l’uso di WfMS definendo  una terminologia standard  di 
interconnessione tra diversi WfMS  con applicazioni esterne. Si è infatti riconosciuto che 
tutti i prodotti di WfM hanno delle caratteristiche comuni che li rendono potenzialmente in 
grado di raggiungere un certo grado d’interoperabilità attraverso l’uso di standard comuni 
su varie funzioni. La WfMC si è posta l’obiettivo di identificare queste aree funzionali e di 
sviluppare specifiche appropriate per l’implementazione di prodotti di WfM. Tali 
specifiche dovrebbero consentire l’interoperabilità tra prodotti di WfM eterogenei e 
potenziare l’integrazione tra tali prodotti ed altri servizi IT quali la posta elettronica, i 
sistemi di document management, ecc. 
 14
Il denominatore comune dei sistemi di gestione documentale in azienda è rappresentato 
dall'esigenza di consultazione in tempi rapidi dei documenti. Tale esigenza è effetto (mai 
causa) di analisi che conducono alla consapevolezza della criticità dell'informazione: dalla 
sua gestione all'interno dell'azienda (back office) e nei confronti dell'esterno (front office).  
Il documento elettronico, che in quest'ottica costituisce l'oggetto dell'archivio digitale, 
rispetto al documento cartaceo ha un'evidente caratteristica: la facile reperibilità e la 
disponibilità immediata dell'informazione, ovviamente a condizione che l'archivio digitale 
sia strutturato con opportune chiavi di ricerca che sintetizzino i meccanismi logici di 
reperimento dell'informazione stessa. Inoltre il documento elettronico può essere facilmente 
condiviso: pensiamo ad una rete locale o ad un archivio su WEB in cui l'accesso alle 
informazioni, che fisicamente risiedono presso il fornitore del servizio, avviene da qualsiasi 
parte del mondo tramite un normale browser Internet. L'informazione può essere quindi 
facilmente condivisa (pensiamo a una rete locale o ad un archivio on-line tramite web 
browser), duplicata, resa disponibile a più persone con diversi livelli di accesso e di 
possibilità di modifica della stessa.  
 
1.3 Ragionare per Processi 
 
Il punto fondamentale di ogni progetto di sviluppo software è il “ragionare per processi”, 
vale a dire mettere il cambiamento dei processi al centro dell’analisi e della progettazione. 
Tradizionalmente i processi erano invece considerati invarianti rispetto all’intervento di 
reingegnerizzazzione, rappresentando talvolta addirittura un vincolo.  
Per processo (o “processo di servizio”, nei contesti, come la Pubblica Amministrazione, 
tesi all’erogazione di servizi) si intende un insieme di attività tra loro interrelate, svolte da 
una o più unità organizzative, finalizzate alla realizzazione di un risultato definito e 
misurabile (il prodotto/servizio) che contribuisce al raggiungimento della missione 
dell’amministrazione e che trasferisce valore al fruitore del servizio (il cliente). Ogni 
processo di servizio è caratterizzato dalla compresenza di una pluralità di componenti (o 
dimensioni) tra le quali:  
 ξ  la natura e le caratteristiche del prodotto/servizio erogato;  
 ξ  il flusso operativo del processo (le attività componenti e le loro relazioni);  
 ξ  le strutture organizzative coinvolte e la distribuzione delle responsabilità;  
 15
 ξ  le regole (norme) a cui deve obbedire il processo;  
 ξ  le varie risorse utilizzate (risorse umane coinvolte, la logistica, le risorse materiali e 
strumentali, le informazioni, le tecnologie dell'informazione e della 
comunicazione).  
 
“Ragionare per processi” significa pertanto individuare prodotti/servizi e processi 
tesi alla loro produzione ed erogazione, diagnosticarne le criticità e successivamente 
intervenire per cambiare e migliorare. Intervenire su un processo di servizio 
significa modificare una delle sue componenti o un insieme di esse.  
In genere si definisce “intervento tecnologico” una modifica (o l’introduzione) di 
tecnologie dell’informazione e della comunicazione (più rari, nei contesti caratterizzati 
dall’erogazione di servizi, sono infatti gli interventi sulle risorse materiali o su altre risorse 
strumentali), mentre si usa chiamare “intervento organizzativo” una modifica che agisce 
sulle altre componenti del processo.  
La fase di riprogettazione costituisce un passaggio non schematizzabile 
completamente in attività predefinite, ma è fortemente legato all’esperienza e alle 
capacità soggettive. È dunque indispensabile un contributo originale di intelligenza 
degli analisti nell’utilizzo dei sistemi diagnostici  e una elevata capacità di interagire 
con gli attori coinvolti ai diversi livelli.  
È ovviamente possibile che emergano più soluzioni alternative, ed una delle attività della 
fase di riprogettazione è pertanto quella di confrontare le varie alternative e scegliere in base 
a determinati criteri di valutazione.  
Numerose sono le tecniche di valutazione che è possibile impiegare e la scelta sarà 
principalmente influenzata dagli obiettivi dell’intervento. Appare evidente che se l’obiettivo 
dell’intervento è il tempo di completamento del processo, la tecnica del Critical Path Method 
(CPM) che mira ad individuare il cammino critico in termini di tempo, è una delle tecniche 
più indicate, così come l’Activity Based Costing (ABC), il cui scopo è identificare e 
quantificare le principali componenti di costo di un prodotto e a correlarle alle attività, è una 
delle tecniche utilizzabili per valutare l’efficienza del processo in termini di costi. 
Se invece l’obiettivo è fornire una migliore qualità del servizio particolarmente utili possono 
essere le tecniche di Customer Satisfaction e di Quality Function Deployment. 
 
 
 16
 
1.4 Efficace gestione dei Processi 
 
Con l’attuale interesse alla gestione dei processi e con la moderna tendenza a vendere 
vecchie idee sotto nuovi nomi, è necessario riesaminare l’approccio tradizionale alla gestione 
dei processi. 
Per mettersi d’accordo su dove si incastrano i processi all’interno dello schema generale, 
aiuta partire dall’alto (v. figura 1.1), con quella che si chiamava “gestione dei sistemi”, e che 
ora si chiama con una moltitudine di nomi, quali “gestione integrata dei sistemi” o “gestione 
dei sistemi aziendali”. La gestione dei sistemi è semplice. Cerca di far sì che:  
 ξ  Tutti i requisiti esterni specificati negli statuti, nei regolamenti, nelle licenze per il 
commercio e tutte le esigenze dei clienti vengano trattati nel sistema di gestione 
come “requisiti definiti del sistema”;  
 ξ  Il personale rilevante riceva la formazione nei requisiti di sistema;  
 ξ  Siano definite le misure delle prestazioni per i requisiti del sistema;  
 ξ  Siano prodotte evidenze che i requisiti del sistema siano stati eseguiti;  
 ξ  Sia monitorata l’estensione della conformità alle misure delle prestazioni e che ne sia 
fatto rapporto;  
 ξ  I cambiamenti dei requisiti esterni siano monitorati e rispecchiati nei cambiamenti 
dei “requisiti definiti del sistema”, quando applicabile;  
 ξ  Il sistema di gestione e i suoi processi siano misurati, verificati e regolati;  
 ξ  Siano stabiliti una cultura e un processo per cercare opportunità per migliorare le 
prestazioni, prevenire il riverificarsi di errori e per condividere l’esperienza; 
 17
 
Figura 1-1 Modello di sistema di gestione 
 
Le ragioni per attuare la gestione dei sistemi sono varie. Tradizionalmente, gli sproni più 
efficaci per la produzione di un sistema di gestione che aggiunga valore a un’organizzazione 
sono il miglioramento delle prestazioni e un incremento dell’utile netto, una gestione efficace 
dei rischi, l’assicurazione della qualità, il prodotto o il servizio per il cliente e l’attuazione di 
una cultura per le opportunità. Più di recente, è stato considerato come sprone il bisogno di 
acquisire un simbolo di riconoscimento internazionale.  
Un modello di un sistema di gestione a base di processi ha tre importanti aspetti:  
1. Analisi del divario tra requisiti esterni e struttura della direzione: i processi (e le 
competenze e le procedure che li sostengono) permettono a un’organizzazione di 
gestire la propria esposizione al rischio efficacemente  
2. Il modello introduce l’idea che i processi sono sostenuti dalla documentazione 
istruttiva e/o dalle competenze  
3.  Questo modello introduce anche la necessità di identificare le attività associate ai 
processi. Il modo tradizionale di vedere un processo, vale a dire che le attività siano 
trasformate in attività aumentate, sarà discusso sotto.  
Avendo stabilito il modello di sistemi di gestione (quello sopra è solo uno dei modi per 
farlo), un’organizzazione identificherà i processi che portano guadagno e le attività che li 
sostengono. La struttura dei processi aziendali individuali può essere trattata in maggiore 
dettaglio, considerando tre stadi chiave:  
 ξ  Specificare e definire il processo;  
 18
 ξ  Costruire il processo;  
 ξ  Gestire il processo.  
La tendenza attuale nella descrizione dei processi aziendali è quella di usare definizioni 
concise, ma siccome in questo contesto viene riesaminato l’approccio tradizionale, si 
dovrebbe cercare una definizione appropriata:  
“I Processi aziendali sono catene di attività ricorrenti, chiaramente identificabili, con un 
esito pianificato, che si estendono per tutta l’organizzazione e attraverso i quali gli input sono 
trasformati in output, di qualità, costo e tempo di consegna definiti, per clienti interni ed 
esterni”. 
Questa descrizione mette immediatamente in luce tre aspetti vitali di un processo:INPUT, 
OUTPUT, ed ESITI  o RISULTATI. Alcuni potrebbero chiedersi perché non siano stati usati 
i termini dell’ingegneria: attività e attività aumentate; ma quelli erano termini per coloro ai 
quali piaceva l’implicazione che un processo fosse un processo solo se apportava valore. A 
difesa della terminologia moderna, alcune attività attuali non accettano così prontamente la 
terminologia tradizionale: cercare di persuadere il servizio di assistenza tecnica per software 
che gli input (un’infinita serie di problemi) dovrebbero essere classificati come attività non è 
consigliabile, anche se – strettamente parlando – qualunque fonte di entrata potenziale è 
un’attività. 
Può essere d’aiuto il chiarimento della differenza tra output di un processo ed esito o risultato 
di un processo. Prendendo il “Servizio di assistenza tecnica” come esempio, si può dire che 
l’output di questo processo è una soluzione al problema originario, il suo esito pianificato è 
la fornitura di una soluzione appropriata, data in maniera professionale, entro una tabella 
temporale predeterminata e con costi predeterminati, che soddisfa le aspettative del cliente.  
Un output è il risultato tangibile della trasformazione di input (hardware, software, proprietà 
intellettuale o altro); si può descrivere un esito come la consegna di un output secondo 
predeterminati requisiti (solitamente di costo, di qualità e di data di consegna).  
 
1.4.1 La responsabilità e il processo 
 
Il modo secondo cui le organizzazioni assegnano gli individui a vari ruoli e responsabilità 
dipende:  
 ξ  dalle loro dimensioni e dal loro tipo;  
 19
 ξ  dalla loro complessità;  
 ξ  dalla loro percezione dei rischi.  
Ciò che è importante è che siano esaminate e assegnate tutte le responsabilità associate ai 
vari ruoli (v. figura 1.2). La prima componente del processo solitamente è la persona o il 
gruppo (nelle grandi organizzazioni può trattarsi di un consiglio o di un comitato) con la 
responsabilità dell’esito del processo. Il consiglio di un club di football è responsabile per la 
posizione finale del gruppo nel campionato e anche se il responsabile di processo (il direttore 
del club o l’allenatore) può avere una responsabilità secondaria o accessoria, la responsabilità 
del consiglio non può essere delegata. In una piccola organizzazione, il responsabile di 
processo e la persona responsabile per gli esiti del processo possono essere lo stesso 
individuo, laddove in organizzazioni di dimensioni medie la società può essere responsabile 
per l’esito del processo e il responsabile di processo può essere uno dei soci. Spetta al 
responsabile di processo fornire gli scopi e le mire del processo e identificare i suoi clienti 
interni o esterni. Chiaramente, bisogna capire le aspettative del cliente quando si 
determinano gli esiti del processo. Il responsabile di processo deciderà anche chi è 
responsabile per l’integrità tecnica e commerciale degli esiti.  
La responsabilità per l’integrità tecnica sarà importante nello sviluppo della logica del 
processo per assicurarsi che siano stati inclusi i controlli appropriati e che siano stati 
determinati gli specifici requisiti tecnici e le relative misure per l’esito. In una compagnia di 
piccole o medie dimensioni, la stessa persona può essere responsabile per l’integrità tecnica 
degli input, per gli stadi di trasformazione intermedia e per gli output. A seconda delle 
dimensioni della compagnia e delle risorse disponibili, la responsabilità per la preparazione 
delle specifiche tecniche per gli input e le relative misure applicate agli input può essere 
delegata al personale che lavora nel processo. Solitamente intrapreso dai membri del gruppo, 
uno degli aspetti più importanti della definizione del processo è l’identificazione e la 
progettazione degli stadi di trasformazione chiave del processo (talvolta noti come “logica 
del processo”). Un aspetto della trasformazione degli input in output è che gli input non sono 
sempre richiesti all’inizio, ma a vari stadi di tutto il processo, particolarmente nei processi di 
assemblaggio dove si introducono componenti continuamente. Lo stesso può essere vero per 
gli output.  
Facendo riferimento ancora una volta alla figura 1.2, gli input sono stati descritti come 
“attività“ o come “problemi“ e gli output sono stati descritti come “attività aumentate“ o 
“soluzioni“, per cercare di coprire sia processi collegati ai prodotti sia quelli collegati ai 
 20
servizi. Si dovrebbe anche menzionare che il termine attività viene usato, nel suo contesto 
più ampio, per includere beni, merci di consumo, servizi, proprietà intellettuale, software e 
materie prime.  
 
 
Figura 1-2 Modello di un processo 
 
Avendo specificato il processo, il prossimo stadio è definirlo e fornire visibilità di processo e 
chiarezza di istruzioni a coloro che sono associati ad esso (le parti in causa). Anche se 
definire le competenze e la documentazione d’istruzione che sostiene i processi è al di fuori 
degli obiettivi di questo articolo, i processi essenzialmente sono “ciò che deve essere fatto, 
chi deve farlo e l’evidenza che è stato fatto”.  
Le procedure e gli altri documenti d’istruzione (istruzioni di lavoro / funzionamento) 
definiranno come dovrebbe essere svolta un’attività. L’estensione in cui un’organizzazione 
dettaglierà tutto questo nella propria documentazione dipenderà:  
 ξ  da ciò che è richiesto per mantenerne l’esposizione al rischio a un livello accettabile;  
 ξ  dal punto in cui la chiarezza diventa descrizione eccessiva;  
 ξ  dalle dimensioni e dal tipo di organizzazione;  
 21
 ξ  dalla complessità dei processi;  
 ξ  dai livelli definiti di competenze necessarie.  
Una definizione di successo permetterà al gruppo del processo di fornire facilmente visibilità 
di processo e chiarezza di istruzioni, e il processo potrà essere cambiato rapidamente, se 
necessario.  
 
1.4.2  Ereditare un processo o costruirlo dal nulla 
 
La maggior parte dei responsabili di processo ereditano un processo piuttosto che costruirlo 
dal nulla; pertanto, costruire un processo spesso viene detto “ri-crearlo”, “ri-costruirlo” o “ri-
progettarlo”. Ci sono comunque alcuni passi di base per assicurare un’efficace 
trasformazione di input in output. A partire da un processo completamente definito e 
dall’esperienza delle parti in causa, si farà una stima delle risorse necessarie per eseguireil 
processo con ottima efficienza. 
Quando la qualità dell’esito di un processo fa affidamento sulle competenze, queste 
dovrebbero essere definite attentamente e le risorse umane dovrebbero combaciare con i 
requisiti. La fornitura delle necessarie infrastrutture del processo – in termini di strutture, 
impianti ed equipaggiamento – è parimenti importante e probabilmente è più facilmente 
misurabile così come lo è la fornitura di merci di consumo per il processo. Le risorse 
finanziarie richieste dovrebbero essere prese in considerazione perché devono essere 
registrate quando si misurano i costi di consegna degli esiti del processo.  
Un aspetto significativo della costruzione del processo è determinare gli input con fonte 
interna e quelli che dovranno essere ottenuti dai fornitori. Una volta presa questa decisione, 
bisogna definire e concordare con i fornitori quali siano i requisiti tecnici, commerciali e 
relazionali. È stato svolto molto lavoro di recente sul valore delle relazioni con i fornitori e 
alla fine è stato riconosciuto che “relazioni con i fornitori mutuamente benefiche” sono la 
chiave per il successo degli esiti del processo.  
A seconda del tipo di processo, lo si dovrebbe collaudare per assicurarsi che il livello di 
risorse sia il migliore per consegnare gli esiti del processo entro i parametri specificati. 
Aggiustare il livello di risorse è un’attività continua, perché la maggior parte dei processi 
consegnano una quantità fluttuante di output.