di Simone Oliva, Maurizio Cassiano e Alessio Grassi

Immagine di copertina generata da Microsoft Copilot Designer con tecnologia OpenAI Dall-E 3

L’importanza della flessibilità delle gerarchie derivate da matrici in sistemi multi-stakeholder

Strutturare le informazioni per la gestione dei progetti

Nella vita di un consulente aziendale ci sono argomenti che ricorrono e rappresentano il fil rouge di un’intera carriera. Analizzandoli, essi rappresentano la cartina al tornasole sullo stato dell’arte di un certo tema e sulle sue evoluzioni nel tempo.

L’utilizzo delle strutture logiche con cui vengono caratterizzate le informazioni di progetto e come queste vengano aggregate e messe a disposizione dei più svariati stakeholder, è sicuramente rappresentativo dello stato di maturità con cui essi sono gestiti e di quali traguardi ulteriori possano essere consigliati e raggiunti.

È per questo, che a distanza di ben dodici anni da un convegno a cui partecipammo (1), in occasione del quale proponemmo una riflessione sul tema della necessità di una sempre maggiore integrazione tra i processi e le informazioni dei progetti lungo tutto il loro ciclo di vita, oggi, utilizziamo questo forum di discussione per capire a che punto siamo.

Cos’è la WBS e perché si utilizza

Muoviamo da un’affermazione posta senza intenti provocatori ovvero che ancora oggi, nel 2024, non sia chiaro a molti cos’è la Work Breakdown Structure o, meglio, come in troppi tendano a “tirarla per la giacchetta” rendendola la struttura “all porpouse” con cui soddisfare le brame informative di qualcuno.

Ricavando il minimo comune denominatore delle definizioni che ne danno i vari standard internazionali, la WBS altro non è che la struttura funzionale alla suddivisione del lavoro dal generale al particolare.

Se, per esemplificare, utilizziamo la tipica struttura WBS di un progetto infrastrutturale, vediamo come essa serva a scomporre il 100% dello Scopo del Lavoro (SOW – Scope of Work) in parti più facilmente gestibili, dove si possa arrivare a raggruppare attività tra loro omogenee e si possa individuare una responsabilità univoca per la loro realizzazione (Figura 1 – La scomposizione dello Scope Of Work).

Figura 1 – La scomposizione dello Scope Of Work

Oltre alla scomposizione per fase appena citata, sono ammesse tutte le considerazioni sulle modalità di disaggregazione delle “cose da fare”: per disciplina, per deliverable, per area geografica, mista, mista dal terzo livello in giù… Tutto ammissibile.

Se, da un lato, la struttura WBS serve per scomporre il lavoro, dall’altro serve per aggregare le informazioni relative alle attività da svolgere e ciò che a nostro giudizio rappresenta un limite è l’abitudine a definirla basandosi, di volta in volta, sulla CBS (Cost Breakdown Structure), sulla PBS (Product Breakdown Structure), sulla LBS (Localization Breakdon Structure), ovvero, sulle esigenze di un singolo stakeholder, perché così facendo uno lo accontenteremo ma tanti altri non saranno soddisfatti!

Il tema si sposta, quindi, su un altro piano.

È una questione culturale o, forse, semplicemente di potenzialità dei sistemi informativi a supporto di un business che fa quel che può, con gli strumenti che gli vengono messi a disposizione, che spesso non sono bene integrati tra di loro, ed hanno come output complessi fogli di calcolo?

L’importanza dell’informazione di base

L’informazione di base non deve essere mai ridondata, moltiplicata tante volte quante sono le necessità/richieste di aggregazione e reporting. L’informazione è sempre la stessa, evolve e si “veste” nel corso del tempo e viene richiamata ogni qualvolta serva.

Avvalendoci dello schema riportato in figura (Figura 2 – Le informazioni di base) vorremmo chiarire cosa intendiamo.

Le aziende, attraverso svariati sistemi, gestiscono un’enormità di informazioni.

Alcune risiedono in sistemi documentali, altre vengono gestite negli ERP, altre nei sistemi di Project Management e molto spesso i sistemi sono tra loro slegati. Mancando vere e proprie mappe logiche dei legami tra le informazioni, vengono conseguentemente a mancare i possibili link informativi e ciò provoca serie inefficienze ogni volta che un dato serva per prendere decisioni.

Legando le informazioni tra loro, invece, si riuscirebbe ad aggregare elementi temporali che risiedono in un pacchetto di lavoro (WP – Work Package) con i documenti di ingegneria sottesi ad una particolare lavorazione, ai costi necessari per svolgerla, magari gestiti in un sistema terzo dal reparto Finance.

Figura 2 – Le informazioni di base

Facciamo un esempio pratico.

Immaginiamo di essere una Stazione Appaltante e di dover affrontare un grande progetto. Dal suo punto di vista il progetto è unico e per fondate ragioni aziendali la WBS è scomposta per deliverables: Autorizzazioni, Viadotti, Tunnel, Impianti ecc.

Il progetto, che si svilupperà in 7 anni, ha 3 appaltatori principali ed una pletora di appaltatori secondari. Questi sono tutti abituati a ragionare (e quindi a fornire i loro dati) per fase (Engineering, Procurement and Construction) e magari per disciplina (Civile, Idraulica, Elettrica ecc.). I singoli appaltatori forniscono alla Stazione Appaltante le loro schedule, non meno di 3 e tutte costruite con logiche e codifiche diverse da quella con cui si è faticosamente traguardato l’Overall Master Schedule.

Per il PM della Stazione Appaltante è rilevante monitorare il progress fisico dei lavori in un’ottica Earned Value, il direttore del Finance ha il problema di allineamento a standard gestionali internazionali e ha l’interesse a poter agevolmente ottenere dati in funzione del Cost to Cost. Agli appaltatori interessa una valutazione delle performance legata alle misure: per loro non si può prescindere dal computo metrico.

Ogni mese si impiegano giornate intere a ricondurre i numerosi aggiornamenti ad uno che sia consistente per tutti.

Ad ogni avanzamento la gestione di tante fonti (files con tabulati fitti di numeri, e-mail, documenti di vario tipo ecc.) costituisce rischio di gravi imprecisioni e, non da ultimo, è foriera di crescente frustrazione degli operatori per non vedere i loro sforzi quotidiani sulla gestione di una grande mole di dati tradursi in scenari affidabili.

Soluzioni, oggi, sono possibili. Il paradigma gestionale di inizio anni 2000, che alla definizione di solidi processi aziendali dovesse far seguito uno sviluppo di soluzioni informative congruenti, a cui ha fatto seguito un aumento smisurato di implementazioni di sistemi ERP (2) anche in realtà non ancora “proceduralizzate” per accoglierli, con altissime percentuali di fallimento, deve essere, oggi, inteso in modo più pragmatico.

L’innovazione sta nell’individuare l’informazione nella sua dimensione atomica

fin da quando essa viene immessa nel circuito del ciclo di vita del progetto, e poi consentire agli strumenti informativi di catturarla ed aggregarla secondo le esigenze dei più svariati stakeholder.

Il modello deve essere solido sia dal punto di vista di processo sia dal punto di vista informativo, deve essere ispirato all’inclusione di tutti gli stakeholder e alla trasparenza dei dati che si prevede di condividere, e ciò deve avvenire con regole chiare e semplici fin dalle fasi di ingaggio.

Sappiamo bene quanta resistenza al cambiamento ci sia su questo tipo di progetti. Testimoniamo, però, che da quel lontano 2012 sono stati fatti passi enormi.

Quindi: WBS sì, ma, per voi, quale?

(1) 25° Convegno ANIMP – Punta Ala (GR) – 28 settembre 2012

(2) Statistiche Del Mercato ERP (https://marketsplash.com/statistiche-sul-software-erp/#link1).

• Secondo le indagini, fino al 53% dei dirigenti IT considera l’ERP una delle principali priorità di investimento.
• Il supporto post-implementazione e la manutenzione continua rappresentano una sfida per il 22% delle organizzazioni, con ripercussioni sulle prestazioni del sistema e sulla soddisfazione degli utenti.
• Le ricerche suggeriscono che i progetti ERP hanno tassi di fallimento che vanno dal 55 al 75%.
• Circa il 28% dei progetti ERP non raggiunge gli obiettivi originari, il che sottolinea l’importanza di una pianificazione adeguata e dell’allineamento con le esigenze aziendali.
• Circa il 26% della forza lavoro delle organizzazioni utilizza il software ERP dell’azienda
• I dipendenti di finanza, contabilità e IT emergono come i principali influenzatori del processo decisionale per l’acquisto di un software ERP.