Lo Standard Activity ID Dictionary

Prima di redigere il Construction Network Analysis Schedule (NAS), bisogna definire lo schema di codifica alfanumerica degli Schedule Activity ID/Number.

La corrispondenza fra i Task e gli Schedule Activity ID/Number deve essere biunivoca (1 ↔ 1): a ogni attività corrisponde un solo codice alfanumerico (sequenziale o parlante), riferito a un unico Task.

In caso contrario, si avrebbero delle ambiguità, che vanno assolutamente evitate.

Lo Schedule Activity ID/Number è dunque la chiave per la corretta identificazione dei Task:

In genere, i vari Scheduling Software propongono gli Schedule Activity ID/Number in base a uno schema di codifica alfanumerica predefinito, eventualmente modificabile dall’utente. Se si utilizza Oracle Primavera P6 Professional Project Management (PPM) Release 8.2 (R8.2), è possibile intervenire sugli Auto-numbering Defaults, presenti nel Tab Defaults dei Project Details. In questo modo, si possono modificare i cosiddetti Activity ID Prefix e Activity ID Suffix, definendo un opportuno Increment.

Supponiamo che sia: Activity ID Prefix = A, Activity ID Suffix = 1000 e Increment = 10. Al primo Task creato verrebbe assegnato lo Schedule Activity ID/Number A1000, eventualmente modificabile (manualmente) dall’utente. Per quel che concerne le altre attività, Oracle Primavera P6 PPM R8.2 proporrebbe A1010 per il secondo Task, A1020 per il terzo e così via per quelli a seguire.

Si noti che gli Schedule Activity ID/Number possono essere modificati in qualsiasi momento: questo comporta sempre una verifica di coerenza, nel senso che lo Scheduling Software controlla il rispetto della già citata corrispondenza biunivoca, impedendo la creazione di doppioni (vale a dire due Task con il medesimo Schedule Activity ID/Number).

Codice alfanumerico sequenziale o parlante?

Come si è visto, gli Auto-numbering Defaults di Oracle Primavera P6 PPM R8.2 si basano su una logica sequenziale. Essa può essere alterata da un intervento manuale.

Il campo Increment Activity ID based on selected activity, spuntabile dall’utente, aggiunge grande flessibilità. Supponiamo, infatti, che a un certo punto sia necessario introdurre nel Construction Network Analysis Schedule un Project Change (PC).

Per fare questo, si potrebbe creare un ramo della Work Breakdown Structure (WBS) avente PC-01 come WBS Code e Project Change #01 come WBS Name. L’utente può decidere di evidenziare i Task presenti nel nuovo ramo della struttura di scomposizione del lavoro, ricorrendo a un particolare prefisso e ripartendo da 1000 con la numerazione del suffisso.

Per fare questo, occorre modificare manualmente lo Schedule Activity ID/Name della prima attività, che si sta creando nel ramo della Work Breakdown Structure corrispondente alla variante in corso d’opera. Per esempio, si può decidere di utilizzare la seguente codifica alfanumerica: PC-01 XYZW, dove XYZW è un numero sequenziale (suffisso).

Selezionato il Task così creato, il campo Increment Activity ID based on selected activity permette di associare automaticamente lo Schedule Activity ID/Number PC-01 1010 al secondo compito da svolgere, proponendo in maniera automatica PC-01 1020 per il terzo Task (sempre che sia Increment = 10).
Si tratta, in sostanza, di una logica sequenziale, ma non rigidamente sequenziale, in quanto alterabile dall’utente: ciò offre la possibilità di sfruttare “l’intelligenza” del pacchetto, mantenendo un certo livello di automatismo (utile, anzi utilissimo, quando le attività da creare sono centinaia o diverse migliaia).

Il codice alfanumerico proposto per la variante in corso d’opera (PC-01 XYZW con Increment = 10) non è più sequenziale, ma parlante. Incappando nello Schedule Activity ID/Number PC-01 1150, infatti, l’utente sa immediatamente, senza consultare la Work Breakdown Structure o dover leggere l’Activity Name, che il Task in questione si riferisce al primo Project Change.

Analogamente, se si avesse a che fare con un progetto di Engineering, Procurement, Construction & Installation (EPC & I) coinvolgente tre edifici, chiamati A, B, e C, si potrebbe utilizzare un codice alfanumerico parlante, costruito nel modo seguente:

• G-XYZW per i Task riguardanti tutti e tre gli edifici (G sta per General);
• ABXYZW per le attività inerenti agli edifici A e B;
• BCXYZW per i Task riguardanti gli edifici B e C;
• ACXYZW per le attività inerenti agli edifici A e C;
• A-XYZW per i Task riguardanti il solo edificio A;
• B-XYZW per le attività inerenti all’edificio B;
• C-XYZW per i Task riguardanti il solo edificio C.

Activity Code e User Defined Field

In realtà, l’utilizzo di un codice alfanumerico sequenziale abbinato a un Activity Code (o a un User Defined Field) consente di ottenere un risultato analogo a quello appena illustrato.

Oracle Primavera P6 PPM R8.2 permette di creare/definire (prima) e utilizzare (poi) degli Activity Code, che possono essere di tipo Global, EPS o Project:

Infatti, ciascuno di essi potrebbe essere utilizzato per gestire tutte le commesse (Global), una porzione dell’Enterprise Project Structure (EPS) o un singolo progetto (Project).

In ogni caso, gli Activity Code vanno prima creati/definiti:

Poi vanno valorizzati:

Dopo di che diventa possibile assegnarli ai singoli Task, tramite una corrispondenza “uno a molti” (1 → molti).

Gli Activity Code permettono di costruire dei filtri in maniera particolarmente semplice e rapida:

Grazie agli Activity Code, la creazione/definizione di un filtro che consenta di visualizzare soltanto le attività inerenti all’edificio B si rivela particolarmente semplice e molto rapida.

La figura illustra la creazione/definizione di un filtro, per mezzo del quale è possibile visualizzare soltanto le attività inerenti all’edificio B. Utilizzando un codice alfanumerico parlante, al posto di uno sequenziale abbinato ad almeno un Activity Code, la corretta visualizzazione delle sole attività inerenti all’edificio B potrebbe rivelarsi ben più onerosa. Nulla vieta, comunque, d’impiegare un codice alfanumerico parlante insieme a un Activity Code.

Gli User Defined Field possono essere abbinati sia a un codice alfanumerico parlante o sequenziale sia a degli Activity Code:

Gli User Defined Field possono riferirsi ad Activities, Activity Resource Assignments, Activity Steps, Issues, Project Expenses, Projects, Resources, Risks, WBS e Work Products and Documents.

Rispetto a questi ultimi, non è necessario valorizzare gli User Defined Field prima di assegnarli.

Codice alfanumerico parlante: un Case Study

La Tabella 1 illustra una possibile struttura di scomposizione del lavoro, adoperabile per la gestione di una commessa di EPC & I, avente come Scope of Work (SoW) l’installazione di tre campi fotovoltaici sul tetto di altrettanti edifici. Come si può notare, i rami della Work Breakdown Structure di 3° livello sono esattamente gli stessi per ciascuno dei tre edifici, poiché i compiti da eseguire sono molto simili (rimozione delle tegole, installazione delle strutture e dei pannelli fotovoltaici, collegamento alle cassette di stringa, …), pur con delle piccole differenze da un edificio all’altro.

Queste analogie possono essere sfruttate per la definizione di un codice alfanumerico parlante, con lunghezza variabile da 5 a 8 Digit, strutturato nel modo seguente:

Schedule Activity ID/Number: X(Y)ABCD(Z)(W)

Il primo Digit (X) è sempre alfabetico e, in base al ramo della struttura di scomposizione del lavoro (di 2° livello) al di sotto del quale si trova l’attività in questione, può assumere uno dei valori seguenti:

• M (Contractual Milestones);
• G (Project Management & General Activities);
• E (Engineering);
• A (Building A);
• B (Building B);
• C (Building C).

Il secondo Digit (Y), sempre alfabetico, viene utilizzato soltanto quando X è uguale ad A, B o C. In base al ramo della struttura di scomposizione del lavoro (di 3° livello) al di sotto del quale si trova l’attività in questione, Y può assumere uno dei valori seguenti:

• S (Submittals);
• M (Manufacturing);
• P (Procurement);
• Q (Construction Quality Management);
• C (Construction & Installation);
• T (Test & Commissioning);
• O (Other Activities).

I successivi quatto Digit (ABCD) sono sempre numerici. Poiché il progetto in questione comprende tre Work Breakdown Element (WBE) sostanzialmente identici, con le medesime attività (riferite, però, a edifici diversi), è possibile sfruttare queste analogie, definendo un (Project) Activity Code denominato Item e legato ai compiti da svolgere per ciascuno dei tre edifici. Così, per esempio, se il valore 1200 del (Project) Activity Code denominato Item corrisponde al cosiddetto Safety Line System, si ha:

• AP1200 → fornitura della linea vita per l’edificio A;
• AC1200 → installazione del Safety Line System sul tetto dell’edificio A;
• BP1200 → fornitura della linea vita per l’edificio B;
• BC1200 → installazione del Safety Line System sul tetto dell’edificio B;
• CP1200 → fornitura della linea vita per l’edificio C;
• CC1200 → installazione del Safety Line System sul tetto dell’edificio C.

Gli ultimi due Digit (Z e W), che possono anche mancare, permettono di sintetizzare delle informazioni aggiuntive, come l’area di lavoro (può essercene più di una per ciascun edificio).

Ovviamente, questo è soltanto un esempio, anche se legato a un caso reale. Ciascun modello dovrebbe rappresentare un buon Trade Off tra le opposte esigenze di esaustività e praticabilità, senza la pretesa d’individuare la soluzione ottima, non sempre implementabile a basso costo e in tempi ragionevoli.

Tabella 1. Una possibile struttura di scomposizione del lavoro, adoperabile per la gestione di una commessa di EPC & I, avente come Scope of Work l’installazione di tre campi fotovoltaici sul tetto di altrettanti edifici.