VIAGGIO NEL DNA DELLE ORGANIZZAZIONI
Il project management(r)
|
VIAGGIO NEL DNA DELLE ORGANIZZAZIONI Il project management(r)
|
|
|
L’Innovation/Project management. Fondamentalmente, il project management è uno strumento ed una tecnica gestionale per finalizzare risorse e competenze ad uno scopo. In questo capitolo, considereremo come noti i concetti di base inerenti tale approccio e concentreremo la nostra attenzione sull’estensione della cultura della gestione per progetti a tutta l’Organizzazione. Come abbiamo visto per la qualità, un approccio globale e condiviso da tutta l’organizzazione è identificato come Company-Wide. La stessa terminologia è utilizzata per le Organizzazioni che abbiano la necessità di operare per progetti o che, al proprio interno, svolgano notevoli attività di tipo progettuale. E’ il caso delle Imprese che operano per commessa, delle Aziende di consulenza, d’informatica, di progettazione e di costruzione in genere. Va però consolidandosi sempre di più tale cultura anche all’interno di Organizzazioni complesse quali Banche o Pubbliche Amministrazioni che sono chiamate sempre più frequentemente a progettare nuovi servizi o a rinnovare quelli esistenti attraverso l’uso di nuove tecnologie. Queste, inoltre, nel caso in cui dovessero affidare all’esterno l’esecuzione di progetti, devono pianificare tempi, costi e risorse per stabilire la fattibilità dei progetti, nonché controllare e monitorare la corretta esecuzione degli stessi. In tutti i casi, quindi, ove è necessario gestire più progetti o ove la progettazione costituisce il core business dell’Organizzazione, parleremo di gestione multiprogetto o, in termini ancora più moderni, di Company-Wide Project Management. Tale approccio non si limita alle imprese precedentemente individuate ma anche a quelle ove emerge un forte connotato di progettualità. Nel prossimo futuro le imprese, soprattutto quelle di servizi, saranno caratterizzate proprio da tale aspetto e saranno assimilabili sempre di più ad una fabbrica di progetti, integrati e coordinati. La qualità non è sufficiente a giustificare il costo di un ciclo continuo d’aggiornamento e mantenimento del sistema. Questo sarà giustificato dal fatto che l’impresa, per sopravvivere, dovrà innovare e considerare tale attività come un’arma competitiva, una strategia deliberata e pianificata. Occorrerà essere flessibili per coprire le sempre più mutevoli esigenze dei clienti e, per fare ciò, sarà necessario progettare la flessibilità ovvero gestire in modo sistemico il cambiamento. Sono stati identificati
tre ambiti d’applicazione del project management e più precisamente: o innovazione di prodotto/processo o
commesse
engineering to order o cambiamento strategico ed organizzativo-gestionale. Tutti e tre i suddetti ambiti d’intervento richiedono d’operare per progetti. Un progetto può essere definito come un insieme d’attività, complesse ed interrelate, aventi come fine un obiettivo ben definito, raggiungibile attraverso sforzi sinergici e coordinati, entro un tempo predeterminato e con un preciso ammontare di risorse umane e finanziarie a disposizione. La gestione di
un’Organizzazione può essere distinta in una gestione caratteristica ed in
una extra-caratteristica. La prima riguarda
le attività specifiche dell’Organizzazione, la seconda quelle indipendenti
dalla stessa, quali, per esempio, quelle relative alla finanza. La gestione caratteristica riguarda le funzioni aziendali quali la produzione, gli acquisti, il commerciale, il marketing, la distribuzione/erogazione, la progettazione, l’ingegneria dei processi produttivi, la ricerca e lo sviluppo. Non considerando, per semplicità le funzioni di supporto, le suddette funzioni della gestione caratteristica appartengono (fig. A79) ai processi logistici ed a quelli d’innovazione.
I primi sono caratterizzati da una marcata ripetitività e da specifici riferimenti standard, i secondi dal cambiamento e dalla mancanza di modelli da adottare. Per la ripetitività connessa al processo logistico, la sua gestione viene definita “operation management”. Tutte le attività connesse a tale processo fanno infatti riferimento alle specifiche definite a suo tempo come risultato del processo d’innovazione. La gestione di quest’ultimo processo è conosciuta come “project management”, con riferimento alla modalità attraverso cui viene raggiunta l’innovazione: il progetto.
In fig. A80 è rappresentato come, di fatto i due processi, logistico e d’innovazione siano ciclici. Il primo si ripete ogni qualvolta si presenta un ordine, e quindi con gli eventi di business, il secondo invece si attiva tutte le volte che l’Organizzazione deve mutare per adeguare il proprio modello organizzativo alle esigenze del mercato. L’innovation/project management deve consentire di produrre nuove specifiche per le attività di routine, ovvero determinate una tantum nuove e migliori specifiche per i prodotti-servizi (funzione progettazione) e per i processi produttivi degli stessi (funzione ingegneria dei processi). Il Project Management Institute nella sua “A guide of the project management Body of Knowledge” (1996) evidenzia come le “operations” abbiano diverse caratteristiche in commune con I “projects” (entrambi i macroprocessi sono realizzati da persone, dispongono di risorse limitate, sono pianificati, eseguiti e controllati), tuttavia “operations are ongoing and ripetitive while projects are temporary and unique” (le operazioni sono a cilo continuo e ripetitive mentre i progetti sono temporanei ed unici). Nella tabella a seguire
sono riportate le differenze più evidenti fra i processi logistici e quelli
d’innovazione:
La metodologia del Company Wide Project Management. Questo prevede
l’utilizzo il ricorso a sei
diverse strutture logico-gerarchiche (“breakdown structures”), collegate fra
loro in considerazione di tre variabili prestazionali fondamentali: tempi (T),
risorse (R), costi – (C), oltre alle variabili tecnico funzionali di qualità
(Q) del progetto: _
Product
function structure (Pfs) _
Product
breakdown structure (Pdbs) _
Process
breakdown structure (Pcbs) _
Work breakdawn
structure (Wbs) _
Project
organizational breakdown structure (Pobs) _
Project budget
breakdown structure (Pbbs). In Fig. A81 sono riportate le
sei strutture, le loro relazioni e le variabili gestionali di progetto.
Un progetto nasce da un’idea più o meno destrutturata in funzione del mercato e delle tecnologie esistenti che mette insiene motivo e modalità di realizzazione. Dalla concept idea è necessario articolare una struttura (Pfs - Product Function Structure) che definisca in modo strutturale-gerarchico le funzionalità che si intendono progettare. Se il prodotto si compone di più componente è possibile rappresentare lo stesso attraverso una visione anche in questo caso strutturale gerarchico che rappresenti il prodotto e l’esplosione nei suoi componenti (Pdbs – Product Breakdown Structure). Le due visioni danno una rappresentazione completa del prodotto. Se per produrre il prodotto occorre anche innovare il processo produttivo occorre descrivere anche questo e le sue fasi e sottofasi attraverso un albero di gerarchie (Pdbs – Process Breakdown Structure). In caso in cui non sia necessario modificare i processi produttivi va comunque prevista la correlazione fra la Pdbs e la preesistente Pcbs. A questo punto possono essere definite tutte le attività progettuali attraverso un altro albero gerarchico di rappresentazione (Wbs – Work breakdown structure). Anche i nodi di quest’albero devono essere correlati con quelli della Pdbs e della Pcbs (se presente). Tale metodo di scomposizione è estremamente efficace per scomporre il problema in argomenti affrontabili e per parallelizzare e quindi velocizzare le attività della progettazione. Il processo innovativo di prodotto che, a partire dalla concept idea, conduce al lancio in produzione (fig. A82), può essere scomposto in fasi cui associare le breakdown structures già descritte.
Il punto di partenza è la concept idea. Questa riassume in pochi elementi chiave il prodotto, le sue caratteristiche tecnico-funzionali di base e quelle di mercato. La fase, a seguire, denominata pianificazione di prodotto, consiste nella definizione, a livello di Pfs, delle funzionalità del prodotto. Successivamente, nella fase di progettazione del prodotto, viene definita la Pdbs che è anche conosciuta come distinta base, ovvero lo schema di scomposizione dello stesso in componenti. Queste sono ancora a livello teorico di progettazione e quindi rappresentano quanto di meglio è stato previsto, in termini di parti componenti il prodotto. La fase di ingegnerizzazione di prodotto ridefinisce la Pdbs in termini di distinta di produzione, ovvero la struttura di componenti che possono essere utilizzati correntemente per la produzione, garantendo i livelli di qualità standard stabiliti dall’organizzazione. La fase di prototipazione è necessaria per effettuare i test sia sul prodotto che sul processo di produzione. La successiva fase di ingegnerizzazione di processo consolida il processo di produzione, lo documenta, lo normativizza e, nei limiti del possibile lo automatizza. L’ingegnerizzazione non è però ancora in grado di portare alle specifiche finali di prodotto e di processo in quanto fino a quel momento la progettazione è stata soprattutto orientata a privilegiare l’efficacia piuttosto che l’efficienza.
Per tale motivo è necessaria una successiva fase d’industrializzazione che genererà uno stock di prodotti che saranno tenuti sotto stretta osservazione in una fase definita di preserie. Superati i collaudi della fase di preserie si passerà alla produzione vera e propria. Il grafico riportato fig. A83 evidenzia, nell’ambito delle varie fasi progettuali, la possibilità d’influenzare i risultati, il livello d’attenzione manageriale, il livello d’impegno delle risorse. Project Management e normative per la qualità. La normativa sulla qualità UNI EN 9000 deriva dalla corrispondente internazionale ISO 9000. Sino alla fine del 2000 comprendeva le norme 9000 (regole riguardanti la conduzione aziendale per la qualità e l’assicurazione della stessa), 9001 (criteri per l’assicurazione della qualità nella progettazione, sviluppo, fabbricazione, installazione ed assistenza), 9004 (criteri riguardanti la conduzione aziendale per la qualità ed i sistemi qualità aziendali in condizioni non contrattuali), oltre alle più ristrette norme 9002 e 9003, limitate rispettivamente alla sola fabbricazione/installazione ed al solo controllo/collaudo finale. La scelta fra le norme 9001, 9002 e 9003 era alternativa e si basava, oltre che sulle fasiin cui è necessario assicurare la qualità, sulla complessità dei processi di progettazione e di fabbricazione, sulle caratteristiche del prodotto e sui costi della non conformità. Come già descritto nel
capitolo relativo ai “sistemi di gestione per la qualità”, dopo un lungo
periodo di gestazione, le suddette norme sono state sostituite da quella che è
comunemente nota come Vision 2000 e più precisamente da: † ISO 9000:2000 – sistemi per la gestione per la qualità – fondamenti e terminologia, † ISO 9001:2000 – sistemi per la gestione per la qualità – requisiti, † ISO 9004:2000 – sistemi per la gestione per la qualità – linee guida per il miglioramento delle prestazioni. Le vecchie ISO 9002 e 9003 sono state soppresse. Senza ripetere quanto già
detto nel suddetto capitolo, ci limitiamo a ricordare che: † i requisiti del sistema di gestione per la qualità sono organizzati in quattro sezioni: § responsabilità della direzione (ISO 9001:2000 punto 5) § gestione delle risorse (ISO 9001:2000 punto 6) § realizzazione del prodotto (ISO 9001:2000 punto 7) § misure, analisi e miglioramento (ISO 9001:2000 punto 8); † nell’ambito del punto 7 della norma relativa alla “realizzazione del prodotto” è citato il sottopunto 7.3 dedicato alla progettazione e sviluppo. † esiste una guida ufficiale di riferimento la ISO 10006: linee guida per la qualità nella gestione del progetto. La norma ISO 10006 può essere considerata l’applicazione delle procedure per la gestione della qualità alla gestione dei progetti. La norma analizza le principali fasi di sviluppo di un progetto, identificando per ogni processo aziendale coinvolto le procedure ed i controlli necessari per la qualità. I processi aziendali coinvolti
sono:
La gestione del tempo nei progetti. Il tempo ha rappresentato la prima variabile gestionale del project management. Si deve ad Henry Gantt (1861-1919) la rappresentazione omonima oggi maggiormente usata atta a rappresentare lo sviluppo nel tempo delle fasi progettuali. In fig. A84 è riportata tale rappresentazione. Sempre nella stessa figura è riportato anche l’equivalente diagramma reticolare. Il diagramma di Gantt è fondamentalmente una tabella dove nella prima colonna è indicata l’attività, la seconda contiene, in genere la durata. Possono essere presenti anche altre informazioni in altre colonne quali le date d’inizio e fine, i costi, il numero di risorse ed altro ancora. Le altre colonne contengono invece gli intervalli temporali prescelti per rappresentare lo sviluppo nel tempo delle attività (mese, quindicina, giorno, altro). Il diagramma reticolare è costituito da una serie di nodi connessi fra di loro da dei legami con verso. Questo indica la sequenza delle attività ed il fatto che se un’attività è rappresentata al termine di un legame orientato, non può iniziare se non al termine di quella che la precede. In tale tipo di rappresentazione, se un’attività si trova al termine di due legami orientati e quindi successivamente a due attività che sono svolte in parallelo, questa non può iniziare prima del termine dell’attività che ha durata maggiore. Possiamo affermare che la rappresentazione reticolare è equivalente ad un processo semplificato. Non esistono infatti nodi decisionali (if) e nodi di and o di or.
In fig. A85 sono indicati i dati fondamentali che sono, in genere, propri dell’attività indipendentemente dal fatto che questa sia utilizzata in un Gantt o in un diagramma reticolare. Naturalmente è possibile passare dai tempi ad i costi assegnando il costo annuo alle risorse in una tabella apposita, ricavando il costo unitario giornaliero delle stesse ed infine valorizzando l’uso delle risorse nell’ambito delle singole attività. E’ anche possibile completare l’analisi e la stima dei costi di progetto assegnando alle attività oltre ai costi delle risorse umane anche quelli delle risorse strumentali e delle materie prime che vengono utilizzate o lavorate. La durata dell’attività è rappresentata nel grafico attraverso una barra orizzontale nel diagramma di Gantt, da un box nel diagramma reticolare se la rappresentazione è europeo o da un cerchio se la rappresentazione è americana.
Ultimamente, il Gantt si è evoluto in modo da comprendere anche l’indicazione delle sequenze d’attivazione delle attività (fig. A86) rendendo poco utilizzata la rappresentazione reticolare. In genere sia il Gantt che la rappresentazione reticolare devono essere in grado di gestire sia la pianificazione originaria (budget di progetto) che la situazione al momento (consuntivo di progetto). Ciò avviene anche graficamente (fig. A87). Le barre nel Gantt o i nodi nella rappresentazione reticolare, per le attività svolte totalmente o parzialmente sono indicati con colori diversi rispetto a quelli della pianificazione originaria. Nel caso di svolgimento parziale dell’attività, questa sarà colorata, con il colore che rappresenta l’attività svolta, solo per un’area pari al valore percentuale di quanto è stato fatto. Il processo di pianificazione, controllo e di ripianificazione è riportato in fig 88.
Le tecniche reticolari: Cpm, Mpm, Pert, Gert, Vert. Le tecniche reticolari sono utilizzate ne Project Management per la gestione del tempo. Queste sono utilizzate per effettuare lo scheduling delle attività e l’analisi dei ritardi. Le più utilizzate sono: _ il CPM (Critical Path Method) — presuppone che la durata delle attività sia considerate fissa, per ognuna di queste, così come le precedenze che devono essere del tipo fine-inizio (ovvero l’inizio dell’attività successiva viene collegato, in termini di vincolo, alla fine dell’attività definita come precedente; _ l’MPM (Metra Potential Method) — simile al CPM, ma caratterizzato dalle rimanenti tre possibilità di legame tra le attività ( ossia inizio-fine, inizio-inizio, fine-fine: può infatti essere utile fare in modo che due attività termino alla stessa data); _ il PERT (Program Evaluation & Review Technique) — è un CPM ma con le durate espresse in chiave probabilistica; _ il GERT (Graphical Evaluation & Review Technique) — è un PERT avente come probabilistici anche i percorsi, cioè i legami di precedenza fra le attività (contiene dei gate logici per designare i percorsi garantendo la possibilità di più conclusioni e di feedback fra le attività), _ il VERT (Venture Evaluetion & Review Technique), che considera contemporaneamente come variabili decisionali, tempi, costi, risorse e rischi, risultando particolarmente efficace nelle analisi what-if e nei problemi di valutazione e controllo di nuovi business o iniziative strategiche. In sintesi mentre il CPM e l’MPM sono tecniche deterministiche PERT, GERT e VERT sono tecniche probabilistiche. La definizione della durata probabilistica di un’attività è piuttosto difficile. Si passa infatti dall’assegnazione di un valore arbitrario stimato all’assegnazione di una vera e propria funzione probabilistica e quindi di una distribuzione (Poisson, Gauss). Per ovviare al conseguente esponenziale incremento dei calcoli , acui occorre aggiungere la difficoltà dovuta alla concatenazione di probabilità di attività fra loro collegate per ottenere la durata del progetto, si ricorre a metodi simulativi quali il Montecarlo o ad una formula derivata da quella che è chiamata distribuzione Betaper la stima della durata delle singole attività. Nel primo caso dalla distribuzione di probabilità di ogni attività si estrae, in modo csuale un certo valore. Dalle durate così estratte si ottiene una durata del progetto. Reiterando più volte il processo si ottiene un campione significativo delle durate del progetto da cui si può ricavare la curva di distribuzione, la media e la varianza. Nel secondo caso, utilizzando la distribuzione Beta (distribuzione di probabilità delle possibili durate), che è una funzione positiva che interseca l’asse delle ascisse nel punto di durata ottimistica (più breve) e nel punto di durata pessimistica (più lungo) e che ha un punto di massimo di probabilità che sta a sinistra della linea mediana, si può calcolare una durata probabilistica stimata pari alla pesata dei tre valori:
In questo modo ci si riconduce dal metodo probabilistico a quello deterministico. Introducendo la definizione probabilistica dei percorsi, i GERT opera in modo più complesso in quanto non esiste solo il computo delle probabilità delle attività ma quello inerente la gestione delle condizioni che possono verificarsi in input ed in output ad un’attività: AND (l’attività viene svolta se è pronto il risultato di tutte le attività precedeti), OR (l’attività viene svolta quando è pronto almeno un risultato delle attività precedenti), XOR (l’attività viene svolta quando è pronto solo un risultato delle attività precedenti). Il GERT considera le condizioni in input e le condizioni che possono generarsi in output. Per esempio la condizione AND/AND sta a significare che tutte le attività precedenti innescano tutte le successive mentre la condizione XOR/AND indica che inizieranno tutte le attività indicate come successive se si realizza almeno una delle attività precedenti. Il VERT con l’introduzione della variabile rischio e la considerazione congiunta di tutte le altre variabili (tempi, costi e risorse) è lo strumento di calcolo più complesso. Questo opera in modalità simulativa (what-if). Il suo reticolo deve essere alimentato con flussi d’informazioni fino ad aver conseguito un certo numero di soluzioni, tali da garantire una significatività statistica. Il risultato finale è una funzione o indice atto a rappresentare gli obiettivi di progetto (ROI, valore attuale netto, …). Le singole variabili sono pesate con le rispettive probabilità d’accadimento e l’andamento dell’output è determinato per via empirica, rilevando la curva di frequenza dal complessivo variare di tutte le variabili in gioco. La complessità dei sistemi di calcolo di tipo probabilistico fa sì che la maggior parte delle persone che impattano con il project management si riducano alla fine ai sistemi di tipo deterministico. Strutture organizzative per il project management. Per la gestione dei progetti la suddivisione organizzativa classica del lavoro risulta inadeguata ad operare correttamente per obiettivi ed a motivare le risorse.
La struttura organizzativa classica di tipo gerarchico funzionale o divisionale non è in grado, infatti, di assicurare un corretto utilizzo delle risorse e, nel contempo, un’alta coesione dei gruppi di progetto ed un orientamento degli stessi alle soluzioni dei problemi. Di fatto il manager di progetto, per l’intera durata dello stesso, essendo il garante de risultati, deve avere non solo le capacità ma anche il potere formale per poter operare nell’unico interesse del progetto e dei suoi obiettivi. Qualsiasi logica determinata da una struttura classica rischia d’essere d’intralcio al progetto ed alle sue necessità. Per tale motivo si utilizza una struttura a matrice dove le dipendenze dal project manager consentono a questi d’utilizzare e d’esercitare in pieno il suo potere indipendentemente dalle strutture a cui appartengono le risorse da questi coordinate (fig. A89). Il Cwpm quale strumento per l’integrazione d’impresa. In tale modo, i progetti nascono dalle esigenze di mercato e producono il meglio di quanto può essere offerto dall’Organizzazione. Ciò richiede una idonea struttura organizzativa atta a consentire agevolmente i distacchi delle risorse dalle Unità Organizzative d’appartenenza. Ovviamente questi dureranno quanto il progetto o le fasi di questo ove il contributo fosse stato ritenuto necessario, programmato ed approvato. Per l’intero periodo del distacco le risorse, pur appartenendo alle proprie Unità Organizzative saranno coordinate da un Project Manager. La forza del coordinamento dovrà essere sempre superiore rispetto alla dipendenza gerarchica prevista dall’organigramma proprio per salvaguardare i progetti e quindi gli investimenti deliberati. La struttura a matrice, precedentemente esaminata, nasce con questo scopo. Il project manager è il gestore del progetto ovvero la persona identificata all’interno dell’Organizzazione o anche all’esterno (un consulente acquisito per il tempo strettamente necessario al progetto è un’ottima soluzione poiché consente anche di importare skill e know-how chw può far crescere la struttura e le competenze interne) che individua, impegna e coordina le risorse per conseguire obiettivi di qualità, di costi e di tempi. E’ lui che coordina la struttura definita con la Project Breakdown Stucture. Il Team Working è un insieme di risorse interdipendenti, che interagiscono in un certo periodo ed in un determinato spazio, legate da un senso d’appartenenza, con valori, norme e ruoli dichiarati, negoziati ed in ogni caso condivisi. La gestione dei costi di budget e di consuntivo. 1. il cost estimating — ovvero la preventiva determinazione dei costi delle risorse che dovranno essere impegnate nel progetto e quindi del costo globale; 2. il cost budgeting — inerente l’ottimizzazione dei costi individuati nella fase di cost estimatine e la definizione della Pbbs; 3. il cost control — di fatto, il controllo periodico della spesa e degli scostamenti rispetto al budget prestabilito. Il cost estimatine analizza il costo delle risorse partendo dalle attività descritte nella Wbs. Va oltre le logiche classiche del controllo di gestionee si avvicina come concetti all’Activity Based Costing.
In fig. A90 è riportato il meccanismo di funzionamento dell’accounting dei costi nel controllo di gestione tradizionale. I costi diretti possono essere imputati direttamente o ai prodotti o ai centri di costo. Quelli indiretti invece devono essere imputati ai centri di supporto o meglio a quelli comuni (dei loro servizio si avvalgono più centri di costo) o a quelli ausiliari (supportano i centri di costo nelle loro attività o sono in ogni caso necessari a questi, anche se non direttamente – vedi Direzione Generale, Amministrazione e Contabilità, Servizio del Personale). A loro volta quest’ultimi devono essere ribaltati ai Centri di Costo direttamente o tramite parametri d’utilizzo o di equa ripartizione. Tale meccanismo è soprattutto di attribuzione dei costi e funzione nel momento stesso in cui, in fase di budget, questi sono stati distribuiti fra i vari centri di responsabilità. Nel project management invece il meccanismo di controllo è soprattutto legato al SAL ovvero al controllo dello stato d’avanzamento dei lavori. I costi sono controllabili nelle varie fasi ed in genere c’è poca influenza dei costi indiretti rispetto a quelli diretti per cui il metodo d’accounting è più vicino all’Activity Based Costing (ABC).
In fig. A91 è riportato il meccanismo di funzionamento per l’accounting del costo pieno tramite ABC. I costi delle risorse sono ricondotti alle attività e di qui ai prodotti. In tale metodo il punto di partenza è la Wbs. Poi si associano le risorse nella Pobs ricavandole dall’organigramma Obs. Per fare ciò sono utilizzati i resource drivers (nella prima fase (first stage)) e gli activity drivers (nella seconda fase (second stage)) dell’ABC. Ovvero i criteri d’assegnazione delle risorse alle attività e delle attività ai prodotti. Il cost estimatine permette di definire il budget globale di spesa per un progetto. Naturalmente questo deve trovare collocazione nell’ambito del budget complessivo di tutta l’Organizzazione sotto la voce investimenti destinati a progetti. Nel caso delle società di Engineering il budget complessivo può coincidere con quello destinato ai progetti se questi producono ricavi attraverso delle logiche di commessa. In questo caso i progetti saranno collocati all’interno del budget alla voce ricavi per la componente pagata dai clienti ed alla voce costi per le risorse che vengono spese all’interno di detti progetti. Per la gestione contemporanea del business e dei progetti possono essere utilizzati strumenti quali il CAGS (Cost Accounting by Goals and Objectives). Tale sistema utilizza, in analogia con la struttura matriciale, un budget matriciale. Dove in colonna troviamo le Unità organizzative ed in riga i progetti. La sommatoria lungo la colonna rappresenta quindi il budget proprio dell’Unitàò organizzativa (budget di funzione), la sommatoria lungo la riga rappresenta invece il budget di progetto (Pbbs). Tale impostazione metodologica consente il coordinamento delle Unità Organizzative per l’attuazione del portafoglio progetti. Il budget di progetto è uno strumento o programma di gestione, espresso in termini economici, riferito ad un singolo progetto, riguardante tutte le risorse necessarie coinvolte, fotografato nel tempo, attraverso uno strumento chiamato baseline, con controlli periodici. Questo è articolato in cost accounts ed è articolato in un conto economico, patrimoniale e finanziario.
Il budget di progetto è strutturato secondo la Pbbs e si consolida nel budget globale dell’Organizzazione attraverso la Bbs (Budget breakdown structure) (fig. A92). Con le baseline si definiscono dei sottobudget si periodo, si consolidano quelli di consuntivo e si confrontano per ricavare i livelli d’effort. I cost accounts sono contabilizzazioni di costi inerenti i WP (Working Pakages) ovvero i pacchetti di lavoro che devono essere svolti dalle risorse. I CA (Cost Accounts) si trovano all’intersezione fra la Pobs e la Wbs di ogni progetto (fig. A93)
In
un’Organizzazione sono sempre attivi più progetti contemporanei. E’
naturale quindi che si vogliano gestire tutti allo stesso modo, attraverso degli
standard che consentano il rispetto di regole comuni ed una migliore
utilizzazione delle risorse. Le logiche del multi-project
management presuppongono l’attivazione, da parte dell’organizzazione, di un
modello organizzativo, in termini di strutture-ruoli e di processi-norme, per
poter pianificare, eseguire, gestire e controllare in modo uniforme e
standardizzato più progetti, assicurando, per ognuno di essi un uniforme
livello di qualità. In genere, il multi-project
management è auspicabile che sia adottato da Organizzazioni che operano per
progetti quali: Imprese di costruzione, Imprese di progettazione, Società di
consulenza, Società di sviluppo software, ecc. All’origine dell’adozione
del multi-project management esistono almeno due ordini di ragioni: · la turbolenza ambientale che impone di contenere i rischi e di poter disporre con continuità di un set di innovazioni applicabile ai progetti ·
le interdipendenze fra progetti. Le interdipendenze a loro volta
possono essere inerenti:
Naturalmente le interdipendenze
sui contenuti possono riguardare:
L’approccio
multi-project management presuppone l’attivazione delle seguenti fasi
metodologiche: 1. l’identificazione delle famiglie dei progetti 2. la determinazione delle strutture di riferimento 3. la definizione del portafoglio progetti, in funzione degli obiettivi aziendali 4. la mappatura delle risorse necessarie e dei fabbisogni finanziari 5. l’organizzazione interprogettuale, in termini operativi e di controllo, di strutture-ruoli e di processi-norme 6. la messa a punto di un sistema di gestione dei progetti con la specifica di routines comuni e programmazione integrata dei progetti 7. la definizione delle priorità di esecuzione ed il controllo della saturazione e del livellamento delle risorse. Nel multi-project management è di fondamentale importanza il risk management ovvero la capacità di individuare, prevedere, definire, quantificare il rischio, nonché di studiare ed approntare idoneee azioni correttive per superare o rendere accettabili i fattori che lo determinano. Il rischio è sempre
determinato da fonti di incertezza o alee quali: · l’identificazione dei bisogni del cliente · la conoscenza ed il dominio della tecnologia · il comportamento dei concorrenti · la qualità e disponibilità delle risorse. I fattori di rischio
fondamentali che devono essere sempre monitorati e tenuti sotto controllo sono:
Il rischio è un elemento intrinseco del progetto ed è crescente col grado d’innovazione dello stesso. Gli approcci più utilizzati per la gestione del rischio sono noti come di tipo reattivo o proattivo. Il primo gestisce i momenti di crisi ed interviene per correggere gli errori, il secondo si preoccupa di prevedere i fattori di rischio e di prevenire l’insorgere dei problemi. In genere, i due approcci sono utilizzati in un approccio misto dove processi proattivi sono utilizzati per definire le azioni da adottare per prevenire i rischi prevedibili, processi reattivi sono definiti per rilevare, analizzare, correggere gli errori in corso d’opera. L’approccio proattivo
presuppone l’attivazione di cinque fasi metodologiche:
Le prime tre fasi metodologiche sono anche note come risk assessment.
In fig. A94 è riportato un esempio di processo semplificato di multi-project management che applica i concetti fin qui spiegati. In fig. A95 è riportata una semplice struttura per il multi-project management.
Ogni progetto del portafoglio progetti deve essere caratterizzato da una scheda sintetica standard che dovrebbe contenere informazioni su:
In genere il multi-project management è supportato da un sistema informativo e di knowledge. Il primo permette di gestire la pianificazione, l’accounting ed il controllo accentrato e distribuito dei progetti, rispettando le competenze e la sicurezza. Il secondo consente di mantenere la conoscenza sui progetti e di distribuirla in modo che questa sia patrimonio comune per altri progetti. Il management by objectives(MBO) e la gestione per processi. Le logiche del project management non si applicano solamente all’innovazione di prodotto e di processo ed all’ingegnerizzazione e produzione su comessa. Un contesto in cui tale approccio è fondamentale è quello che riguarda il cambiamento strategico dell’Organizzazione. A tale categoria appartengono lo “strategic change”, lo “stategic renewal” ed il “business reengineering”. Il cambiamento strategico richiede una prestazione nota come “flessibilità strategica”. Questa include le seguenti caratteristiche: _ rapidità di variazione delle priorità competitive — all’interno di un business è la capacità di riorientare l’operatività in funzione del livello di competitività richiesto; _ ampiezza e posizionamento delle opzioni strategiche — all’interno di un business il primo indice rappresenta il numero delle opzioni possibili, il secondo riguarda il loro posizionamento all’interno del ventaglio delle scelte strategiche; _ rapidità di spostamento da un business all’altro _ ampiezza dei potenziali business — è funzione ad un certo istante delle capacità-competenze disponibili. Il processo di management
ha due estremi: il “management by activities” in cui si guarda il tempo di
svolgimento delle attività e gli sforzi sostenuti ed il “management by
objectives” in cui si definiscono gli obiettivi da raggiungere ed i passi da
eseguire. Nelll’Mbo i managers sono ritenuti responsabili dei risultati
conseguiti piuttosto che delle attività svolte. La filosofia di base dell’Mbo è stata definita per la
prima volta nel 1954 da Peter Drcker nel suo libro the practice of management.
Il focus è posto sulla capacità del manager di definire gli obiettivi,
automotivarsi e promuovere dei piani finalizzati al conseguimento delle
prestazioni attraverso la leva della leadership manageriale, la conoscenza e
motivazione del proprio gruppo e delle persone motivate. Un programma Mbo può essere visto come l’insieme delle
dinamiche di conoscenza e di comprensione tra
superiori e subordinati in merito ad obiettivi e prestazioni. La gestione per processi wstende il concetto di lavoro
per obiettivi dalla direzione a tutta l’azienda in modo che, a vari livelli,
ogni persona è responsabile ed è garante delle attività, dei processi, degli
obiettivi. Questa, nata come soluzione organizzativa per superare le
rigidità dell’organizzazione funzionale, svolge il ruolo di catalizzatore di
programmi per la soddisfazione del cliente. La natura intrinseca della gestione per processi è
infatti orientata all’efficacia nell’ottenimento degli obiettivi finali di
soddisfazione del cliente piuttosto che all’efficienza della singola funzione. La gestione per processi, senza far venir meno la
struttura funzionale, che mantiene i suoi indubbi vantaggi di gestione
efficiente delle risorse, si sovrappone a questa per porre in maggior rilievo
l’accento sul cliente su cui focalizza l’attenzione di tutta
l’Organizzazione e la cui soddisfazione ispira la logica di coordinamento di
tutte le attività. Rummler e Brache (1990)
distinguono tre tipi di processi:
Secondo Earl e Khan (1994) i processi si possono distinguere per la loro strutturabilità e per l’impatto che hanno sulle prestazioni dell’Organizzazione. Quelli che hanno impatto diretto sull’efficacia e l’efficienza sono definiti come “core” se sono interni e “network” se coprono le relazioni esterne con i clienti ed i fornitori. Quelli chge invece impattano indirettamente con le prestazioni sono definiti come di “support” se sono necessari ad i processi core e di “management” se coprono le attività della direzione. Gilbreath (1986) distingue fra processi “a flusso”, come i processi produttivi che sono caratterizzati da ripetitività delle modalità d’esecuzione e standardizzazione e processi “ a impulso”, come i processi d’innovazione del prodotto. Questi sono gestibili attraverso le logiche del project management e, a loro volta, possonoi essere assimilati a dei processi veri e propri.Un processo può essere visto come una sequenza spazio temporale dove viene creato creato valore aggiunto. Ogni processo si rivolge in ultima istanza al cliente e contribuisce, assieme ad altri processi,alla sua soddisfazione. Scopo quindi di ogni processo è creare valore aggiunto. Tale creazione avviene lungo tutta la catena del valore: dalla progettazione, alla produzione, alla commercializzazione, all’assistenza post vendita. Bernardi e Piazzo (1995)
distinguono fra: _ il process management — consistente nella razionalizzazione dei processi finalizzato alla ricerca dell’efficacia e dell’efficienza, _ il process reengineering — consistente nella riprogettazione del funzionamento operativo finalizzato sempre alla ricerca dell’efficacia e dell’efficienza, _
il business reengineering — consistente nella riprogettazione
del funzionamento ma in un’ottica strategica di riposizionamento del business. Questi ultimi due (process e business reengineering) riguardano l’innovazione dell’organizzazione piuttosto che il semplice miglioramento dei processi e costituiscono quello che è noto come Business Process Reengineering. Questo è , a tutti gli effetti un progetto, e, in quanto tale, è soggetto a tutte le regole del Project Management. Il miglioramento dei processi project based. Risulta ormai chiaro come siano
presenti forti analogie e correlazioni fra gestione per processi (process
management) e gestione per progetti (project management). L’introduzione nell’Organizzazione di principi e pratiche per la gestione dei processi si configura come un progetto di riorganizzazione e quindi uno dei più delicati in quanto coinvolge strutture, ruoli e risorse. Per tale motivo non può che essere un progetto “company wide” cioè in grado di coinvolgere tutti i componenti dell’Organizzazione per far sì che il cambiamento non sia solo progettato ma attuato correttamente. I passi principali per
poter concretizzare un processo di introduzione della gestione per processi in
azienda possono essere così riassunti: † identificazione del processo, † definizione dei confini, † formalizzazione degli input e degli output scambiati, † formalizzazione delle attività del processo e delle relative procedure, † analisi e massimizzazione del valoraq aggiunto delle attività, † analisi degli eventi scatenanti le attività e delle loro durate attese, † valutazione delle prestazioni di risultatoe della loro origine interna ed esterna, † definizione delle responsabilità: ownership, † allocazione delle risorse al processo. Naturalmente poiché un processo può essere notevolmente complesso è opportuno che questo sia, a sua volta, esploso in sottoprocessi. Ad ogni sottoprocesso occorre applicare i passi precedentemente elencati. La definizione dei processi aziendali, sia di routine, che di cambiamento, costituisce una valida premessa per un’efficace gestione del miglioramento. Nello stesso tempo esaminare i processi di cambiamento e d’innovazione e quindi i progetti di attuazione degli stessi in termini di flussi di attività dà loro quella parte maggiormente procedurale e di riferimento che è tipica più del process che del project management. Considerare tutte le attività aziendali, anche quelle progettuali, come processi facilita la definizione dei progetti di miglioramento delle Organizzazioni.
A questo punto, non è assolutamente azzardato considerare i progetti di miglioramento di un processo quali dei veri e propri feedback ovvero delle retroazioni positive o negative, aventi budget, risorse e tempi d’esecuzione determinati, che hanno l’obiettivo d’agire su input ed attività del processo al fine di migliorarne gli output (fig.A96). Il miglioramento secondo questa visione è pilotato da un processo di revisione continua project-based e quindi è gestito secondo le pratiche ed i principi del project management. In tale tipo di organizzazione ai manager ed ai quadri aziendali può essere richiesto di assumere contemporaneamente più ruoli: § responsabile di unità organizzativa §
process owner §
project
manager. Naturalmente, in tale logica, deve essere adottato un modello di Company Wide Project Management dato l’alto livello di interrelazioni e di dipendenze che esistono nell’ambito di un modello basato sul miglioramento continuo dei processi. Conclusioni. Se a questo si aggiunge che lo strumento per pianificare le attività progettuali non è altro che un insieme di fasi poste in sequenza finalizzate al raggiungimento degli obiettivi progettuali ci si rende ben conto come il pattern che le rappresenta complessivamente non è altro che un processo con le sue fasi, le sue sequenze, i suoi percorsi paralleli ed alternativi. Quindi la rappresentazione del processo è sia il risultato della progettazione organizzativa sia lo strumento attraverso il quale è possibile pianificare e gestire il cambiamento organizzativo. Avvalora tale ipotesi anche il fatto che i dati che entrano in gioco nel processo organizzativo sono gli stessi che sono utilizzati nell’ambito della pianificazione e del controllo di progetto: tempi lavorati, durate, risorse, ruoli, costi, ecc. Su questa e su altre considerazioni già fatte torneremo quando parleremo di Change & Knowledge Management Organizzativo. |
|
|
|
