Nell’articolo “Project Portfolio Management (PPM): la scelta del Tool” ho fornito alcune linee guida, utili per districarsi nel complesso mondo dei pacchetti Software, dedicati alla gestione di una o più commesse.
Con questo breve Paper torno sull’argomento, considerata la sua complessità, anche in relazione all’interesse suscitato dall’articolo “Project Portfolio Management: gestire i progetti con Primavera P6.1”.
I modelli e gli algoritmi
Occorre distinguere i modelli deterministici da quelli probabilistici.
Per esempio, Primavera Risk Analysis di Oracle è un vero e proprio strumento di Risk Management, mentre la gestione del rischio è sostanzialmente assente nella Suite di Enterprise Project Portfolio Management (EPPM)/Professional Project Management (PPM) Primavera P6, giunta alla Release 8.2 (R 8.2) e proposta dalla medesima azienda (Oracle).
In un modello deterministico, a ogni Task di una certa Activity Network corrisponde una Original Duration (per esempio: “1 d”, “2 d”, “3,5 d”, “5 d” o “10 d”). Questa corrispondenza non è biunivoca, bensì di tipo “molti a uno” (“molti → 1”), poiché più attività possono avere la medesima durata.
In un modello probabilistico, invece, la durata di ciascun compito da svolgere è caratterizzata da una distribuzione di probabilità, che può essere continua o discreta.
Nel caso di una funzione di densità di probabilità discreta, si ha:
P(x = 0 d) = a, con 0 ≤ a ≤ 1
P(x = 1 d) = b, con 0 ≤ b ≤ 1
P(x = 2 d) = c, con 0 ≤ c ≤ 1
P(x = 3 d) = d, con 0 ≤ d ≤ 1
…
P(x = n d) = z, con 0 ≤ z ≤ 1
Inoltre:
= P(x = 0 d) + P(x = 1 d) + P(x = 2 d) + P(x = 3 d) + … + P(x = n d) =
= a + b + c + d + … + z = 1
Per ogni attività, x è la durata del compito da svolgere, pari a un multiplo intero della giornata lavorativa (Working Day) o di calendario (Calendar Day):
x = k d, con k = 0, 1, 2, 3, …, n
n è un intero non negativo (come k, del resto).
Nel caso di una funzione di densità di probabilità continua, invece, si ha:
Per ogni attività, x è la durata del compito da svolgere. Per questo, occorre che la condizione seguente sia sempre soddisfatta:
x ≥ 0
Queste considerazioni permettono di distinguere i Tool con cui è possibile costruire modelli probabilistici da quelli che, invece, si basano su motori di calcolo meramente deterministici.
La schedulazione dei compiti da svolgere si basa sempre su un insieme di calendari. Anche in questo caso, la corrispondenza fra i Task e i calendari non è biunivoca, bensì di tipo “molti a uno”, poiché più attività possono condividere il medesimo calendario.
In ogni caso, si ha sempre:
Working Days = Calendar Days – Days Off
Per quel che concerne gli algoritmi impiegati per la schedulazione dei compiti da svolgere, si possono ricordare i seguenti:
1) Critical Chain (CC);
2) Critical Path Method (CPM);
3) Program Evaluation & Review Technique (PERT).
Con ogni probabilità, il secondo rappresenta l’algoritmo più conosciuto e maggiormente utilizzato.
Il Critical Path (CP), che non è necessariamente unico, individua il percorso “più lungo” all’interno dell’Activity Network, che costituisce il modello reticolare del progetto. Di conseguenza, la lunghezza del cammino critico determina la durata dell’intera commessa.
Un pacchetto italiano di recente introduzione, basato sull’approccio noto come Critical Chain e la Theory of Constraints (ToC), elaborata da Eli Goldratt, è Galileo Project Management (GPM) di Sanmarco Informatica, un’azienda veneta conosciuta per il suo gestionale: Galileo ERP.
L’integrazione e le dimensioni aziendali
Ecco un argomento estremamente importante: l’integrazione Enterprise Resource Planning (ERP) – Project Management e le sue ripercussioni sul Sistema Informativo (SI) aziendale. Da questo punto di vista, ci sono due possibilità:
- acquistare l’ERP y, realizzato dal produttore Y, e il Tool di Project Management z, realizzato dal produttore Z, provvedendo alla loro successiva integrazione, se ritenuta importante, necessaria o strategica;
- rivolgersi a chi offre una soluzione integrata, in cui l’ERP e il Tool di Project Management sono stati concepiti, progettati, sviluppati e messi a punto dal medesimo produttore, in modo tale che possano interagire fra loro con particolare efficacia ed efficienza.
In realtà, come spesso accade, anche in questo caso esiste una sorta di via di mezzo, poiché diversi produttori di Software propongono dei moduli destinati all’integrazione fra il gestionale y, realizzato dal produttore Y, e il Tool di Project Management z, realizzato dal produttore Z. Due esempi in tal senso sono costituiti da Primavera Inspire for SAP di Oracle e da Provision di Altitudo, capace di far comunicare bidirezionalmente Microsoft Project e Microsoft Business Solutions Navision.
Per quel che concerne l’integrazione a monte (o sul nascere), una possibilità è l’offerta integrata Galileo ERP – Galileo Project Management, proposta da Sanmarco Informatica.
A torto si potrebbe credere che l’esigenza di una crescente integrazione fra gli strumenti di Enterprise Resource Planning e quelli di Project Management sia appannaggio soltanto delle Project Based Enterprise (PBE) più grandi e maggiormente strutturate. Anche le aziende piccole e flessibili, infatti, sono sempre più inclini a “ragionare per progetti”, al fine di fronteggiare le esigenze imposte da un mercato dinamico e, talvolta, a dir poco imprevedibile. Di conseguenza, nel mondo di oggi, il ricorso a consolidate tecniche di Project Management, abbinato all’adozione di strumenti (anche Software) adeguati, rappresenta un elemento sempre più diffuso, spesso del tutto indipendente dalle dimensioni aziendali. Si pensi, per esempio, all’importanza assunta dal cosiddetto Project Management Office (PMO), oggi presente anche in contesti di piccole o medie dimensioni. In parte, ciò è legato al passaggio, storicamente assodato, dalla Mass Production alla Mass Customization, che sposta l’interesse dall’Operations Management al Project Portfolio/Program/Project Management.
Per non sbagliare
Ecco alcune domande, che costituiscono una sorta di Check List, da considerare nella scelta del Software per la gestione dei progetti:
- Si è interessati a un modello deterministico, oppure se ne vuole realizzare uno probabilistico?
- Per la schedulazione dei compiti da svolgere, a che algoritmo ci si vuole affidare? Critical Chain? Critical Path Method? Program Evaluation & Review Technique?
- Se si sta utilizzando un certo ERP, si desidera o si ritiene conveniente che il Tool di Project Management sia integrato con il gestionale?
- Se l’integrazione è ritenuta importante, necessaria o strategica, si vuole integrare il Tool di Project Management con l’ERP in uso, oppure si preferisce migrare verso una soluzione integrata a monte (o sul nascere)?
Tirando le somme
Si tenga presente che i modelli e gli algoritmi sono strettamente correlati: in un certo senso, scegliere gli uni limita i gradi di libertà nella scelta degli altri.
Non si commetta l’errore di pensare che l’integrazione Enterprise Resource Planning – Project Management sia sempre assolutamente indispensabile, indipendentemente dal particolare contesto preso in considerazione. Ogni singola realtà, infatti, è un caso a sé, da studiare attentamente, prima di giungere a delle conclusioni avventate.
Quanto all’ultimo quesito della Check List del paragrafo precedente, si tratta di prendere una decisione attentamente ponderata, basata sui più moderni approcci di analisi degli investimenti. A questo proposito, ricordo come i cosiddetti Sunk Cost NON siano una variabile decisionale. Pertanto, essi non vanno considerati, cosa non sempre facile, soprattutto per via di inevitabili implicazioni di carattere “psicologico”. Ben difficilmente, infatti, molti Manager di oggi sono disposti a riconoscere i propri errori, accantonando quella che, sino al giorno prima, sembrava essere la soluzione ai problemi operativi della Performing Organization.
