Gestione dei progetti di automazione: guidare progetti di PLC, SCADA e sistemi di controllo dall’URS alla messa in servizio

Che cos’è la gestione dei progetti di automazione

La gestione dei progetti di automazione è la disciplina che pianifica, esegue, coordina e consegna progetti di automazione industriale che installano, configurano e integrano sistemi di controllo (PLC, SCADA, DCS, sistemi di sicurezza) in uno stabilimento produttivo o in un impianto di processo. Si colloca all’incrocio tra la gestione dei progetti di ingegneria, la gestione dei progetti IT e la gestione dei progetti di esercizio, attinge a tutte e tre senza ridursi a nessuna, perché i progetti di automazione hanno tratti propri che gli approcci generici di gestione dei progetti non coprono del tutto.

La definizione e la collocazione dei progetti di automazione

Un progetto di automazione inizia quando un’organizzazione produttiva decide di installare nuova tecnologia di controllo o di modernizzare i sistemi di controllo esistenti, e termina quando il sistema installato funziona in modo sicuro e affidabile in produzione e soddisfa i requisiti di esercizio definiti all’inizio. L’ambito comprende in genere la selezione e l’approvvigionamento dell’hardware, la configurazione e la programmazione del software, l’integrazione con i sistemi di stabilimento esistenti, i collaudi in più fasi, la validazione della sicurezza e della cybersicurezza, la formazione degli operatori e la consegna formale all’esercizio. I tipi di progetto frequenti sono le installazioni greenfield (impianto nuovo, senza eredità), le modernizzazioni brownfield (sostituzione di sistemi di controllo obsoleti su un impianto in marcia), gli ampliamenti di capacità (nuove linee di produzione entro un’architettura di automazione esistente) e gli aggiornamenti dei sistemi di sicurezza (portare installazioni esistenti alle norme vigenti come la IEC 61511 Edizione 2).

In cosa si distinguono dai progetti di produzione abituali

Un progetto di automazione non è un progetto di produzione abituale, anche se si svolge all’interno di un’azienda di produzione. Quattro differenze sono decisive. Primo, il risultato è un sistema e non un prodotto: si ottiene un’architettura di automazione funzionante, non un singolo prodotto pronto per la vendita, così che i criteri di successo riguardano le prestazioni di esercizio e non le caratteristiche di un prodotto. Secondo, il lavoro è multidisciplinare per natura in un modo che i progetti di produzione ordinari non sono: meccanica, elettrica, software di controllo, infrastruttura IT e ingegneria di processo devono convergere sulla stessa data di installazione, spesso con appaltatori diversi responsabili di discipline diverse. Terzo, l’ordine di validazione è obbligatorio e irreversibile: FAT prima del SAT prima della messa in servizio, senza scorciatoie possibili, perché le dipendenze fisiche impongono la sequenza. Quarto, i requisiti di sicurezza e conformità portano spesso un peso normativo che i progetti di produzione generici non affrontano con la stessa intensità, dalle norme di sicurezza funzionale ai requisiti di cybersicurezza fino alle regolamentazioni di settore.

In cosa si distinguono dai progetti IT

A volte i progetti di automazione vengono gestiti erroneamente come progetti IT, perché entrambi includono software. Le differenze sono considerevoli. I progetti IT consentono di norma il rilascio iterativo, il rilascio per fasi a sottoinsiemi di utenti e le correzioni rapide dopo il rilascio. I progetti di automazione si rilasciano in un impianto fisico dove il software comanda processi fisici con conseguenze reali: applicare una patch a caldo a un PLC in un reattore chimico non è lo stesso tipo di modifica di una patch a un’applicazione web. I progetti IT si possono mettere in pausa; gli impianti in marcia spesso no. Il fallimento di un progetto IT provoca di norma perdita di dati o disagio per l’utente; il fallimento di un progetto di automazione può provocare incidenti di sicurezza, rilasci ambientali o violazioni normative. Per questo esiste la disciplina FAT-SAT-messa in servizio e per questo accorciarla genera conseguenze costose che i responsabili di progetti IT all’inizio possono non riconoscere.

Le sei fasi di un progetto di automazione: dall’URS alla messa in servizio

I progetti di automazione seguono una struttura consolidata in sei fasi diventata standard in tutti i settori: chimica, farmaceutica, alimentare e bevande, energia e produzione generale. Le fasi sono: specifica dei requisiti utente (URS), specifica di progettazione funzionale e di dettaglio (FDS, DDS), ingegneria e costruzione, collaudo di accettazione in fabbrica (FAT), installazione e collaudo di accettazione in sito (SAT), e messa in servizio. Ogni fase ha input, output e criteri di gate definiti, e la disciplina di far rispettare i criteri di gate tra le fasi separa i progetti di automazione consegnati in tempo da quelli che esauriscono il budget in rilavorazioni tardive.

Fase 1: specifica dei requisiti utente (URS)

L’URS definisce cosa deve realizzare il sistema di automazione dal punto di vista dell’esercizio: portata produttiva obiettivo, specifiche di prodotto, filosofia di controllo, requisiti di sicurezza, vincoli normativi, aspettative dell’interfaccia operatore e punti di integrazione con i sistemi di stabilimento esistenti e con l’IT aziendale. Un’URS ben scritta, come un project charter, è funzionale e non tecnica: descrive il risultato desiderato senza prescrivere la soluzione tecnica. La qualità dell’URS è il migliore predittore singolo dei risultati di un progetto di automazione, perché ogni fase successiva eredita l’ambiguità o la completezza di quel documento. I progetti che saltano l’URS o la trattano come una formalità scoprono ripetutamente, al SAT o alla messa in servizio, che diversi portatori di interesse avevano ipotesi diverse su funzioni di base, e a quel punto il costo dell’allineamento è di ordini di grandezza superiore a quello che sarebbe stato in fase di URS.

Fase 2: specifica di progettazione funzionale e di dettaglio (FDS, DDS)

La FDS traduce l’URS in una progettazione funzionale: quale PLC, quale SCADA, quale topologia di rete, quali anelli di regolazione, quali funzioni di sicurezza, quali allarmi e come si collegano tra loro e con l’infrastruttura di stabilimento. La DDS scende poi al livello di dettaglio tecnico necessario all’ingegneria e all’approvvigionamento: modelli hardware precisi, conteggi di I/O, schemi di cablaggio, disposizione dei quadri, architettura software, layout delle schermate HMI. Le fasi FDS e DDS comprendono revisioni di progettazione con il cliente, e l’approvazione al termine della DDS è l’equivalente del congelamento della progettazione del progetto di automazione. Le modifiche successive a questo punto richiedono una gestione formale delle modifiche e allungano di norma il cronoprogramma.

Fase 3: ingegneria e costruzione

Ingegneria e costruzione comprendono l’approvvigionamento dell’hardware, l’assemblaggio dei quadri, lo sviluppo del software (codice PLC, schermate SCADA, logica di sicurezza, configurazione dell’historian), l’installazione dell’infrastruttura di rete e il montaggio meccanico ed elettrico in sito. Questa fase procede in parallelo tra più discipline e fornitori, ed è qui che il coordinamento interdisciplinare consuma la maggior parte dell’attenzione del project manager. I componenti a lunga consegna individuati durante la FDS (strumenti speciali, controllori certificati di sicurezza, apparati di rete specializzati) devono essere stati ordinati con sufficiente anticipo perché l’ingegneria avanzi senza attendere l’hardware. Lo sviluppo del software per PLC e SCADA avviene di norma dopo la DDS, in parallelo con l’approvvigionamento dell’hardware, così che entrambi siano pronti insieme per il FAT.

Fase 4: collaudo di accettazione in fabbrica (FAT)

Il FAT si svolge presso il fornitore o l’integratore, prima della spedizione al sito. Il sistema di controllo completo (hardware PLC, software SCADA, sistemi di sicurezza) viene montato e collaudato in un ambiente controllato con ingressi e uscite simulati. Il FAT valida che l’hardware sia conforme alla DDS, che il software implementi correttamente la logica funzionale, che allarmi e interblocchi si comportino come progettato, che le schermate HMI mostrino le informazioni specificate e che l’integrazione tra sottosistemi funzioni. Il FAT è l’ultima occasione conveniente per rilevare difetti: le correzioni al FAT costano circa dieci volte meno delle stesse correzioni al SAT e cento volte meno dei difetti rilevati alla messa in servizio. Saltare o accorciare il FAT è la singola causa più frequente di costosi sforamenti nell’automazione.

Fase 5: installazione e collaudo di accettazione in sito (SAT)

Dopo l’approvazione del FAT, il sistema viene spedito al sito, installato da appaltatori meccanici ed elettrici e passa il SAT. Il SAT verifica che l’installazione sia conforme ai disegni, che gli I/O fisici siano correttamente collegati a strumenti e attuatori, che l’integrazione con i sistemi di stabilimento esistenti funzioni come progettato e che i collaudi funzionali end-to-end superino le condizioni reali di installazione. Per i progetti SCADA e di processo continuo, il SAT comprende spesso una prova prolungata di una o due settimane per dimostrare un funzionamento stabile senza inconvenienti maggiori. Quando più sottosistemi di fornitori diversi devono essere collaudati insieme, dopo i SAT individuali si esegue un collaudo di integrazione in sito (SIT), introdotto formalmente nella IEC 62381:2024, per dimostrare il funzionamento integrato.

Fase 6: messa in servizio

Alla messa in servizio, il sistema validato viene trasferito alla produzione in marcia. La messa in servizio a freddo collauda i sistemi senza materiale di processo o con fluidi innocui. La messa in servizio a caldo introduce gradualmente materiale di processo reale, con taratura degli anelli di regolazione e delle sequenze e ottimizzazione verso le prestazioni obiettivo. La messa in servizio si conclude con la consegna formale all’esercizio, che richiede la formazione completa degli operatori, la consegna della documentazione (disegni as-built, manuali di esercizio, istruzioni di manutenzione), la disponibilità dei ricambi e il rispetto dei criteri di accettazione concordati. I periodi di supporto dopo la messa in servizio (di norma da 30 a 90 giorni) permettono all’integratore di risolvere i problemi che emergono solo nelle condizioni reali di produzione.

La spina dorsale della validazione: FAT, SAT, SIT e messa in servizio

Le fasi di validazione tra la fine dell’ingegneria e l’inizio della produzione stabile costituiscono la disciplina che definisce la gestione dei progetti di automazione. Il loro ordine è obbligatorio e non si può accorciare: hardware e software devono prima essere validati in un ambiente controllato (FAT), poi verificati nell’ambiente installato (SAT), poi integrati con i sottosistemi vicini (SIT) e infine dimostrati nelle condizioni reali di processo (messa in servizio). Ogni fase ha obiettivi distinti, criteri di accettazione distinti e un’economia radicalmente diversa nel rilevare e correggere i difetti.

FAT: rilevare i difetti nel punto meno costoso

Il collaudo di accettazione in fabbrica si svolge presso il fornitore, alla presenza del cliente o di un ispettore indipendente. Il sistema di controllo completo, o un sottoinsieme funzionalmente completo, viene montato sul banco di prova del fornitore e collaudato rispetto a un ambiente di stabilimento simulato con simulatori di I/O, stimolazione dell’HMI e script di collaudo funzionale derivati dalla FDS. L’ambito tipico del FAT copre la verifica degli I/O e la verifica degli anelli (ogni canale di ingresso e uscita funziona ed è correttamente assegnato), i collaudi della logica di controllo e delle funzioni (interblocchi, permissivi, allarmi, sequenze validati rispetto ai P&ID e alla specifica funzionale), l’ispezione di hardware e cablaggio (dimensioni dei quadri, marcatura dei conduttori, messa a terra, montaggio dei componenti), i controlli di taratura e strumenti e la validazione di cybersicurezza per i sistemi connessi in rete. Un FAT eseguito correttamente dura di norma da uno a cinque giorni presso il fornitore, a seconda della complessità del sistema. La ragione economica di un FAT rigoroso è chiara: correggere un difetto in fabbrica costa di norma ordini di grandezza in meno che sul campo, perché la correzione in fabbrica non incide sul cronoprogramma dell’impianto, non genera costi logistici di sito, non interrompe l’esercizio e non richiede di rimobilitare le squadre.

SAT: verificare l’installazione reale e l’integrazione

Il collaudo di accettazione in sito si svolge dopo l’installazione presso il cliente. Conferma che l’installazione sia conforme ai disegni, che gli I/O fisici siano correttamente collegati a strumenti e attuatori nell’impianto reale, che l’integrazione con i sistemi di stabilimento esistenti (processi a monte e a valle, interfacce MES, ERP) funzioni come progettato e che i collaudi funzionali end-to-end superino le condizioni reali di installazione. Il SAT porta spesso alla luce problemi che il FAT non ha potuto cogliere: strumenti mal cablati, configurazioni errate dei dispositivi di campo, discrepanze di integrazione con i sistemi ereditati, interferenze elettromagnetiche da impianti vicini. Per le installazioni SCADA e di processo continuo, il SAT comprende di norma una prova di stabilità prolungata di una o due settimane per dimostrare che il sistema funziona in continuo senza inconvenienti maggiori. L’approvazione del SAT è il gate verso la messa in servizio.

SIT: integrare più sottosistemi

Gli impianti industriali moderni si basano raramente su un’unica piattaforma di automazione. Un impianto di processo tipico integra più PLC, controllori DCS, sistemi di sicurezza, sistemi di rilevamento incendio e gas, unità a pacchetto, centri di controllo motori, azionamenti a frequenza variabile, analizzatori, sistemi di protezione elettrica, historian, sistemi di gestione degli asset e postazioni operatore, spesso di fornitori diversi. Ogni sottosistema può superare il FAT e il SAT separatamente, ma non appena i sistemi iniziano a scambiare dati di processo reali emergono spesso problemi di integrazione. Il collaudo di integrazione in sito (SIT), introdotto formalmente come fase standard nella IEC 62381:2024, collauda tutti i sottosistemi di automazione che agiscono insieme come un’unica soluzione di controllo di processo. Il SIT è la risposta adeguata alla complessità multifornitore che i singoli FAT e SAT non possono affrontare.

Messa in servizio: dimostrare l’idoneità alla produzione

La messa in servizio trasferisce il sistema validato alla produzione in marcia. La messa in servizio a freddo verifica il sistema senza materiale di processo o con simulanti innocui: le pompe girano, le valvole manovrano, le sequenze si eseguono, gli allarmi segnalano, ma nessun prodotto è in gioco. La messa in servizio a caldo introduce gradualmente materiale di processo reale, tara gli anelli di regolazione (parametri PID, configurazioni in cascata, anticipazione) e ottimizza le sequenze (ricette di lotto, procedure di avviamento e arresto) verso le prestazioni obiettivo. La messa in servizio è il momento in cui diventa visibile la qualità accumulata di URS, FDS, ingegneria, FAT e SAT: un progetto che ha svolto bene le fasi precedenti viene messo in servizio in giorni o settimane, mentre un progetto che ha saltato o accorciato le fasi precedenti può passare mesi nella messa in servizio a risolvere problemi che avrebbero dovuto essere rilevati prima.

Coordinamento multidisciplinare nei progetti di automazione

I progetti di automazione sono multidisciplinari per natura in un modo che i progetti di produzione ordinari non sono, un ambito in cui aiutano i principi del lean management applicato alla gestione dei progetti. Un progetto di automazione di medie dimensioni tipico coinvolge almeno cinque discipline di ingegneria distinte che lavorano in parallelo, spesso di aziende diverse, che devono convergere sulle stesse date di installazione e messa in servizio. Coordinare i passaggi di consegne tra queste discipline assorbe la maggior parte dell’attenzione del project manager dell’automazione, e ridurre l’attrito nei passaggi di consegne è la leva più grande sulla durata complessiva del progetto.

Ingegneria meccanica e costruzione

Gli appaltatori meccanici installano l’infrastruttura fisica da cui dipende l’automazione: tubazioni, valvole, attuatori, supporti dei motori, supporti degli strumenti, passerelle per cavi. Il loro lavoro precede l’installazione elettrica e di controllo, e i ritardi della costruzione meccanica si propagano a ogni disciplina a valle. L’ambito meccanico comprende anche la fornitura dell’aria e dell’idraulica di cui hanno bisogno strumenti e attuatori, che va coordinata con la selezione e l’installazione degli strumenti per evitare discrepanze alla messa in servizio.

Ingegneria elettrica e installazione

Gli appaltatori elettrici installano la distribuzione dell’energia, i centri di controllo motori, la posa dei cavi, il cablaggio dei quadri e i collegamenti dei dispositivi di campo. La loro sequenza segue la costruzione meccanica e precede la messa in servizio del sistema di controllo. Gli appaltatori elettrici sono di norma responsabili anche dello schema di messa a terra ed equipotenzialità, decisivo sia per la sicurezza (protezione elettrica) sia per l’affidabilità del sistema di controllo (soppressione dei disturbi sui cavi di segnale). Il coordinamento tra appaltatori elettrici e integratori di sistemi di controllo attorno a liste dei cavi, disposizione dei quadri e liste dei morsetti è una fonte di attrito permanente nel progetto, attorno alla quale i project manager esperti dell’automazione pianificano.

Ingegneria e integrazione del sistema di controllo

L’integratore del sistema di controllo è responsabile della selezione e programmazione dell’hardware PLC, della configurazione SCADA e dello sviluppo delle schermate, della progettazione e validazione del sistema di sicurezza, dell’architettura di rete e della configurazione dell’historian e della reportistica. È la disciplina che consegna nel modo più diretto la funzionalità di automazione che userà l’esercizio. Gli integratori di sistemi di controllo affidano spesso in subappalto elementi specifici (programmazione del sistema di sicurezza, valutazione di cybersicurezza, progettazione di rete) a società specializzate, aggiungendo un ulteriore livello di coordinamento che il project manager deve gestire.

Ingegneria delle reti IT e OT

I sistemi di automazione moderni sono integrati in rete e richiedono una propria infrastruttura di rete, separata dall’IT aziendale, con interfacce definite dove si sovrappongono. L’ingegneria delle reti IT/OT comprende l’architettura della rete di controllo (di norma varianti di Ethernet industriale), la segmentazione tra la zona di controllo e quella aziendale, le misure di cybersicurezza conformi alla IEC 62443, le politiche di accesso remoto e l’integrazione con l’historian di stabilimento e i sistemi MES. Gli ingegneri IT/OT restavano storicamente fuori dai progetti di automazione e venivano coinvolti tardi, ma i progetti moderni traggono vantaggio dal coinvolgerli fin dall’URS, perché le decisioni di rete influenzano la progettazione fisica dei quadri e la posa dei cavi.

Ingegneria di processo ed esercizio

Gli ingegneri di processo forniscono la filosofia di controllo che PLC e SCADA implementano: quali anelli necessitano di quale strategia di regolazione, quali interblocchi proteggono da quali modi di guasto, quali allarmi gli operatori devono vedere. L’esercizio apporta la conoscenza operativa che diventa il contenuto dell’URS: come funziona davvero l’impianto, cosa serve agli operatori sulle loro schermate, quali sequenze richiedono quali opzioni, quali informazioni aiutano nella diagnosi dei guasti alle tre del mattino. I progetti di automazione che mantengono coinvolti ingegneria di processo ed esercizio dall’URS alla messa in servizio superano sistematicamente i progetti che li trattano come portatori di interesse consultati e non come partecipanti attivi del progetto.

Insidie frequenti nei progetti di automazione

Cinque schemi di fallimento si ripetono nei progetti di automazione, qualunque sia il settore, e ognuno può essere prevenuto con contromisure concrete. Dare un nome agli schemi permette di riconoscerli prima nei progetti futuri, quando possono ancora essere intercettati per una frazione del costo di risolverli alla messa in servizio.

URS insufficientemente specificata portata in ingegneria

Il primo schema è trattare l’URS come una formalità iniziale anziché come la base su cui poggia l’intero progetto. L’URS viene redatta in fretta per liberare l’ingegneria, le ambiguità restano nel documento con l’ipotesi che verranno chiarite più tardi, e l’ingegneria avanza rispetto a un insieme di requisiti mal definito. Le conseguenze emergono al SAT e alla messa in servizio: l’esercizio scopre che il sistema non fa qualcosa che dava per scontato, o fa qualcosa che non ha mai voluto, e la correzione richiede una riprogettazione che un’URS solida avrebbe evitato. La contromisura è investire il tempo di calendario in un’URS rigorosa con approvazione esplicita dei portatori di interesse e criteri di accettazione definiti prima dell’inizio dell’ingegneria, anche se sembra ritardare il progetto.

FAT accorciato o saltato

Il secondo schema è trattare il FAT come un passo opzionale che si può accorciare quando il cronoprogramma è sotto pressione. Il fornitore ha completato il software e l’hardware è montato, ma il cliente decide che il FAT è inutile perché il fornitore collauda bene internamente, oppure che il FAT può ridursi a una dimostrazione anziché a un collaudo funzionale completo. Le conseguenze emergono al SAT e alla messa in servizio, dove ogni difetto che il FAT avrebbe intercettato costa ora da dieci a cento volte di più da correggere. La contromisura è trattare il FAT come non negoziabile a prescindere dalla pressione sui tempi e strutturare l’ambito del FAT in modo tanto concreto che una dimostrazione non possa passare per un collaudo.

Lacune nel coordinamento multifornitore senza SIT

Il terzo schema è dare per scontato che i singoli FAT e SAT dei fornitori bastino quando più sottosistemi devono lavorare insieme. Il sistema di ogni fornitore supera i propri collaudi, ma le interfacce tra i sistemi non sono state validate congiuntamente, e i problemi di integrazione emergono durante la messa in servizio, quando risolverli è più costoso. La contromisura è pianificare un collaudo di integrazione in sito esplicito quando il progetto comprende più sottosistemi di fornitori diversi, e definire l’ambito del SIT già durante l’URS, così che i fornitori sappiano di essere contrattualmente tenuti a partecipare a collaudi integrati e non solo a validare il proprio sottosistema.

Ritardi delle discipline vicine che si riversano sull’automazione

Il quarto schema è trattare la durata del progetto di automazione come se fosse indipendente dalle altre discipline del sito. La costruzione meccanica ritarda, l’installazione elettrica ritarda, e il team di automazione arriva per iniziare il SAT solo per scoprire che l’impianto non è pronto ad accoglierlo. I cronoprogrammi del team di automazione di norma non possono slittare nella stessa direzione, perché le finestre di messa in servizio sono legate a fermi impianto o a finestre di avviamento fissate con largo anticipo. La contromisura è integrare esplicitamente i cronoprogrammi del progetto di automazione con quelli meccanico ed elettrico, con milestone di prontezza di ogni disciplina per le attività di automazione e con inneschi di escalation quando una disciplina slitta oltre il margine.

Validazione di sicurezza e cybersicurezza rinviata

Il quinto schema è trattare i collaudi di sicurezza funzionale e la validazione di cybersicurezza come attività cerimoniali finali anziché come flussi di lavoro continui lungo tutto il progetto. Le funzioni di sicurezza richiedono validazione rispetto alla specifica dei requisiti di sicurezza lungo tutto il ciclo di vita, dalla progettazione al FAT e al SAT fino alla messa in servizio, e la cybersicurezza conforme alla IEC 62443 richiede allo stesso modo misure in fase di progettazione anziché un audit a fine progetto. La contromisura è definire flussi di lavoro di sicurezza e cybersicurezza con deliverable espliciti per fase, dotarli di risorse separate dai collaudi funzionali e trattare l’accettazione di sicurezza e cybersicurezza come gate propri anziché come punti di una lista di accettazione generale.

Sicurezza e conformità nei progetti di automazione

I progetti di automazione operano entro quadri normativi e di norme che i progetti di produzione generici raramente affrontano con la stessa intensità. Sicurezza funzionale, cybersicurezza, regolamentazioni di settore e norme industriali pongono tutte requisiti che vanno integrati nella struttura del progetto fin dall’URS, non aggiunti alla messa in servizio. Un mancato rispetto della conformità alla consegna è nella migliore delle ipotesi costoso e nella peggiore blocca l’esercizio, e la disciplina di integrare la conformità nel flusso del progetto separa i project manager dell’automazione che consegnano in tempo da quelli che passano l’ultimo mese a cercare evidenze per l’audit.

Sicurezza funzionale secondo IEC 61511 e IEC 61508

I sistemi di sicurezza nell’industria di processo seguono la IEC 61511 (con la IEC 61508 come norma di base). I requisiti del ciclo di vita comprendono l’analisi dei pericoli e dei rischi, l’assegnazione delle funzioni di sicurezza a funzioni strumentate di sicurezza (SIF) con livelli di integrità di sicurezza (SIL), la specifica dei requisiti di sicurezza, la progettazione e l’ingegneria con verifica del SIL, la validazione in installazione e messa in servizio e le procedure di esercizio e manutenzione. La sicurezza non si può aggiungere alla messa in servizio; deve essere presente in ogni fase. I progetti di automazione che trattano la sicurezza come flusso di lavoro proprio fin dall’URS producono evidenze pronte per l’audit come risultato naturale del progetto, mentre i progetti che trattano la sicurezza come attività di accettazione finale scoprono di norma tardi che lacune di documentazione o problemi di progettazione richiedono rilavorazioni.

Cybersicurezza secondo IEC 62443

I sistemi di automazione e controllo industriale affrontano minacce di cybersicurezza che i quadri di sicurezza IT non coprono del tutto. La IEC 62443 definisce i requisiti di cybersicurezza per l’automazione industriale, tra cui la segmentazione della rete tra le zone IT e OT, l’accesso remoto sicuro, la gestione delle patch dei sistemi di controllo, la registrazione degli eventi di sicurezza e la gestione delle vulnerabilità. I requisiti di cybersicurezza vanno definiti durante l’URS e declinati in FDS, DDS e ingegneria. Aggiungere la cybersicurezza alla messa in servizio è costoso e raramente dà risultati soddisfacenti, perché le decisioni fondamentali di architettura sono già state prese.

Regolamentazioni di settore

Diversi settori industriali aggiungono ai progetti di automazione requisiti di conformità specifici. I progetti farmaceutici e delle scienze della vita seguono l’Allegato 15 delle GMP dell’UE, che riconosce espressamente il ruolo di FAT e SAT nella qualifica ed esige evidenza documentata della strumentazione critica, della taratura e della verifica di processo. La FDA 21 CFR Part 11 si applica ai registri e alle firme elettroniche nelle scienze della vita. I progetti alimentari e delle bevande seguono i principi HACCP con norme di settore per la progettazione igienica e la tracciabilità. I progetti di energia e utility seguono la NERC CIP per la cybersicurezza della rete. I progetti dell’industria generale richiedono l’evidenza della marcatura CE e le norme ISO pertinenti di sicurezza, prestazioni e specifiche tecniche. I requisiti di settore vanno individuati durante l’URS, e il cronoprogramma del progetto deve tenere conto delle attività di audit e documentazione che essi impongono.

Gestire più progetti di automazione a livello di portfolio

Una società di ingegneria che consegna progetti di automazione, o un produttore con più iniziative di automazione simultanee, raramente ha un solo progetto in corso. Più tipicamente, il portfolio comprende più progetti in fasi diverse che si contendono gli stessi talenti di ingegneria, gli stessi mezzi di collaudo, la stessa capacità di integrazione e le stesse finestre di messa in servizio. La vista di portfolio è il punto in cui la gestione dei progetti di automazione passa da disciplina di progetto a capacità organizzativa, e dove sono disponibili i maggiori guadagni di throughput complessivo.

La dashboard di portfolio dei progetti di automazione

Una dashboard di portfolio dei progetti di automazione mostra tutti i progetti attivi classificati per fase (URS, FDS, ingegneria, FAT, SAT, messa in servizio), con visibilità su quali progetti si avvicinano alle revisioni di gate, quali sono bloccati e quanti sono in ciascuna fase. La dashboard rivela schemi che le viste di singolo progetto nascondono: colli di bottiglia sistematici nella pianificazione del FAT con lo stesso integratore, finestre di messa in servizio che si addensano in fasce di calendario strette, competizione per risorse su competenze specializzate come la programmazione dei sistemi di sicurezza. Il riconoscimento di schemi a livello di portfolio alimenta il miglioramento sistemico anziché lo spegnimento reattivo degli incendi progetto per progetto.

Competizione per risorse su competenze specializzate

I progetti di automazione dipendono da competenze specializzate spesso scarse: programmatori di sistemi di sicurezza, specialisti di cybersicurezza, architetti di rete, esperti di determinate piattaforme PLC, ingegneri di messa in servizio con esperienza di settore. Le risorse condivise diventano la maggiore fonte di ritardi non pianificati su un portfolio di più progetti. La competizione per risorse, invisibile a livello di progetto, diventa visibile a livello di portfolio, dove lo stesso specialista che compare contemporaneamente in più cronoprogrammi di progetto mette in luce la doppia prenotazione che i singoli project manager non possono vedere. Una gestione di portfolio efficace individua presto questi colli di bottiglia e o aggiunge capacità, o sequenzia i progetti per ridurre la competizione, o accetta i ritardi come decisioni di portfolio visibili.

Standardizzazione tra progetti

I portfolio maturi di progetti di automazione standardizzano gli elementi ricorrenti: modelli di URS per tipo di progetto, strutture di FDS, formati di script di collaudo FAT, criteri di accettazione SAT, liste di controllo di messa in servizio, modelli di documentazione di sicurezza, procedure di valutazione di cybersicurezza. La standardizzazione evita di reinventare gli elementi di routine in ogni progetto e libera l’attenzione di ingegneria per le parti che davvero differiscono. La standardizzazione abilita anche l’apprendimento tra progetti: uno schema di difetto emerso al FAT di un progetto aggiorna i modelli, così che i progetti successivi intercettino prima la stessa classe di difetti. Le società di ingegneria con una standardizzazione matura consegnano progetti più rapidamente e con minore variabilità delle aziende in cui ogni progetto reinventa il proprio approccio.

Pianificazione della capacità e decisioni di offerta a livello di portfolio

La visibilità a livello di portfolio sul carico attuale dei progetti e sulla disponibilità prevista delle risorse sostiene le decisioni commerciali che le società di ingegneria prendono di continuo: a quali gare rispondere, quali date di consegna impegnarsi a rispettare, quando assumere, quando dire di no a certe opportunità. Le società senza dati di capacità a livello di portfolio di norma si sovraccaricano nelle fasi ottimistiche e si trattengono in quelle prudenti, e la variabilità di consegna che ne risulta deteriora le relazioni con i clienti e la fidelizzazione del personale. Le società con dati di portfolio possono prendere decisioni di offerta a partire dalla capacità di consegna reale anziché dall’ottimismo su quanto il team può assorbire.

Caso di studio A: Smart Automation, esecuzione disciplinata del portfolio

Smart Automation è una società di ingegneria di Olsztyn, in Polonia, attiva nell’automazione industriale dal 2009. La società progetta e consegna sistemi di automazione completi, dai concept di macchina e dalle analisi di fattibilità alla programmazione dei sistemi di controllo e ai sistemi di visione artificiale, passando per l’automazione robotizzata dei processi e la costruzione di macchine specializzate. L’esperienza del team somma oltre 300 anni in automazione, robotica e meccatronica. La società ha completato oltre 1.000 progetti per clienti come IKEA, Michelin, Siemens Energy, Unilever e Danone, il che in pratica significa diverse decine di progetti simultanei in qualsiasi momento, diversi per ambito, complessità e ubicazione.

Il punto di partenza prima dell’adozione di FlexiProject era familiare alle società di ingegneria: i budget venivano gestiti in soluzioni attorno al sistema ERP, perché lì risiedono fatture, pagamenti e costi, ma ogni project manager aveva sviluppato un approccio personale al controllo finanziario. Gli strumenti di pianificazione del cronoprogramma, monitoraggio dei rischi e pianificazione delle risorse mancavano nella sostanza. Non c’era una visione completa né di un singolo progetto, tantomeno dell’intero portfolio. La società ha deciso di cercare un sistema di gestione dei progetti dedicato che riunisse cronoprogrammi, budget, rischi e risorse in un unico luogo e diventasse la fonte unica di informazione sui progetti.

L’adozione ha coperto tutta l’organizzazione. In tre mesi, i 51 progetti attivi di complessità varia sono stati trasferiti in FlexiProject. Oggi tutti i collaboratori e i subappaltatori chiave usano il sistema, 37 persone in totale, cosa resa praticabile da un pool di licenze flessibile. Ancora più importante: la società ha inteso l’adozione come un’occasione per costruire uno standard comune di gestione dei progetti, non solo per sostituire uno strumento. Ora ogni progetto inizia allo stesso modo: con un project charter che definisce obiettivi, ambito e responsabilità, e con un modello di fasi che ordina il lavoro dal concept alla consegna. I cronoprogrammi vengono creati da un modello comune con dipendenze di Gantt e milestone, e ogni programma viene salvato come baseline: un punto di riferimento approvato rispetto al quale si misurano gli scostamenti di tempo e costo.

I dati di budget dovevano restare coerenti con il sistema ERP, così FlexiProject è stato integrato con l’ERP in modo che le informazioni di costo fluiscano tra i sistemi senza doppia digitazione. Oltre ai progetti, la struttura flessibile ha permesso di rappresentare il processo di offerta e il servizio di garanzia e post-garanzia. Due fattori hanno spinto l’adozione. Primo, l’amministratore delegato ha agito come sponsor attivo del progetto, esigendo con costanza che tutte le informazioni di progetto vivessero in un unico sistema e attendendosi aggiornamenti regolari da ogni project manager. Secondo, la barriera d’ingresso era bassa: costruire cronoprogrammi e budget era abbastanza intuitivo perché ogni project manager, a prescindere dall’esperienza, potesse iniziare la formazione inserendo un proprio progetto reale anziché esercitarsi su esempi artificiali. I risultati si vedono nelle decisioni: scostamenti di budget con previsione fino al completamento, utilizzo delle risorse come input per le decisioni di offerta e i piani di assunzione, revisioni di progetto ogni due settimane per i progetti attivi e mensili per quelli in fase di pianificazione, tutto a partire dai dati del sistema anziché da presentazioni elaborate a mano.

Caso di studio B: la crisi di automazione del Model 3 di Tesla, 2017-2018

L’aumento di produzione del Model 3 di Tesla tra il 2017 e il 2018 è uno dei fallimenti di progetto di automazione meglio documentati pubblicamente nella storia industriale, insolito per la disponibilità di Elon Musk ad ammetterlo con parole proprie. Il Model 3 è stato annunciato nel 2016 come il primo veicolo di massa di Tesla, a un prezzo obiettivo di 35.000 USD, e nelle 24 ore successive al lancio 115.000 persone avevano effettuato prenotazioni. Tesla si è posta l’obiettivo ambizioso di produrre 5.000 Model 3 a settimana entro la fine del 2017 e ha seguito un approccio che Musk avrebbe poi descritto come «automatizzare tutto», scommettendo che un’automazione estesa avrebbe consentito il volume necessario a smaltire l’arretrato di preordini.

Il risultato è stato ciò che lo stesso Musk ha chiamato «l’inferno della produzione». Tesla ha mancato ampiamente l’obiettivo di fine 2017 e ha prodotto 2.425 Model 3 in tutto il quarto trimestre 2017 (a fronte di un obiettivo di 5.000 a settimana). Anche l’obiettivo rivisto per la fine del primo trimestre 2018, di 2.500 a settimana, è stato mancato, con Tesla che ha raggiunto 2.020 nell’ultima settimana del primo trimestre. Sia l’assemblaggio dei moduli batteria alla Gigafactory sia la linea di assemblaggio finale a Fremont avevano progetti di automazione rivelatisi inaffidabili al volume di produzione. Gli analisti di Bernstein hanno sostenuto pubblicamente che la sovrautomazione ha inciso gli errori di Tesla nella linea di produzione ed è costata più di quanto abbia reso. Il 13 aprile 2018, Musk ha ammesso pubblicamente su Twitter: «Sì, l’eccesso di automazione in Tesla è stato un errore. Per la precisione, un mio errore. Gli esseri umani sono sottovalutati.» In un’intervista alla CBS ha descritto lo smantellamento di una «folle e complessa rete di nastri trasportatori» che non funzionava, e Tesla ha finito per riportare parti della linea di assemblaggio a un’operazione manuale, inclusa la famosa linea di assemblaggio provvisoria sotto «tenda» a Fremont, che ha aggiunto capacità con il lavoro manuale anziché con ulteriore automazione.

Tre lezioni si trasferiscono direttamente a qualsiasi progetto di automazione. Prima, l’ambizione di automatizzare senza validazione pilota moltiplica il rischio anziché ridurlo: la decisione di Tesla di dispiegare nuova automazione su scala di produzione prima di validarla a volume pilota ha moltiplicato la difficoltà di ogni ciclo successivo di risoluzione dei problemi, mentre un aumento graduale avrebbe portato alla luce i problemi di automazione a costo minore. Seconda, sovrautomatizzare passi di sottoassemblaggio che richiedono adattabilità produce risultati peggiori delle alternative semiautomatizzate in cui le persone assumono la variazione e le macchine il lavoro ripetibile: è un principio noto della pratica manifatturiera giapponese che Tesla, di fatto, ha riscoperto sotto la pressione della produzione. Terza, gli impegni di cronoprogramma di progetto che danno per scontato che la tecnologia funzioni come previsto, senza margine sufficiente per portare alla luce i problemi di automazione, generano una pressione che rende la risoluzione disciplinata dei problemi più difficile anziché più facile. Tesla ha infine raggiunto l’obiettivo di 5.000 a settimana entro fine giugno 2018 e ha più che raddoppiato la produzione totale del 2017, ma il prezzo di averlo ottenuto attraverso una crisi anziché un aumento graduale disciplinato è stato considerevole.

Come FlexiProject sostiene i progetti di automazione

FlexiProject sostiene il livello di esecuzione della gestione dei progetti di automazione con la visibilità di portfolio, la gestione del cronoprogramma, il monitoraggio dei rischi, le revisioni strutturate e i modelli standardizzati. Il coordinamento multidisciplinare dei progetti di automazione, in particolare il lavoro di armonizzare le funzioni di meccanica, elettrica, controllo, IT/OT e ingegneria di processo, resta responsabilità dell’organizzazione. FlexiProject fornisce l’infrastruttura operativa che rende gestibile l’esecuzione disciplinata dei progetti di automazione su larga scala, non un sostituto della collaborazione di ingegneria da cui dipende il successo di un progetto di automazione.

Vista di portfolio per progetti di automazione simultanei

FlexiProject offre una dashboard di portfolio che mostra tutti i progetti di automazione attivi in un’unica vista, classificati per fase (URS, FDS, ingegneria, FAT, SAT, messa in servizio) e per cliente o unità di business, con visibilità su quali progetti si avvicinano alle revisioni di gate e quali sono bloccati. La vista di portfolio porta alla luce schemi che le viste di singolo progetto nascondono, come finestre di messa in servizio che si addensano in fasce di calendario strette, competizione per risorse su competenze specializzate e ritardi sistematici nella pianificazione del FAT con determinati integratori. I comitati direttivi che prendono decisioni a livello di portfolio lavorano dalla stessa vista di portfolio, anziché riconciliare report di progetto distinti.

Cronoprogramma con diagramma di Gantt, elenco attività e kanban

Il cronoprogramma in FlexiProject combina una vista diagramma di Gantt per il monitoraggio delle milestone e la visualizzazione delle dipendenze, una vista elenco attività per il lavoro di esecuzione dettagliato e una vista kanban per la disciplina di flusso all’interno delle fasi. I progetti di automazione traggono vantaggio dalla combinazione: il diagramma di Gantt gestisce la struttura a livello di fase con le dipendenze dall’URS alla messa in servizio e le milestone di revisione di gate, gli elenchi attività gestiscono il lavoro dettagliato di ingegneria e collaudo all’interno delle fasi, e il kanban segue il flusso dei deliverable concreti attraverso la revisione e l’approvazione. Le icone di avviso sulle attività del cronoprogramma segnalano problemi di budget o di rischio senza richiedere report separati.

Registro dei rischi, collegato alle fasi del progetto

Il registro dei rischi in FlexiProject segue i rischi propri dell’automazione con responsabili, piani di mitigazione e ritmo di revisione. I rischi propri di ciascuna fase (disponibilità di componenti a lunga consegna durante l’ingegneria, prontezza del fornitore per il FAT, prontezza del sito per il SAT, disponibilità dell’impianto per la messa in servizio, validazione del sistema di sicurezza, valutazione di cybersicurezza) sono collegati alle milestone di fase pertinenti e rivisti al gate corrispondente. Il collegamento tra rischi, attività e cronoprogramma fa sì che un rischio che si materializza si ripercuota visibilmente sul tempo associato, anziché restare in un registro a parte che nessuno consulta al momento delle decisioni di tempo.

Revisioni di progetto come revisioni di gate

Le revisioni di progetto in FlexiProject possono essere strutturate come revisioni di gate formali dei progetti di automazione, con criteri definiti, presentazione strutturata delle evidenze e decisioni formali di procedere o non procedere messe a verbale del progetto. Il ritmo di revisione è pianificato (di norma alla fine di ogni fase di progetto e a ogni transizione FAT/SAT/messa in servizio), e i risultati delle revisioni alimentano i modelli standardizzati dei progetti successivi. I criteri di gate configurati nei modelli si applicano in modo coerente tra progetti dello stesso tipo, così che il gate di approvazione del FAT di un progetto usi la stessa struttura di criteri del gate di approvazione del FAT di un altro.

Modelli standardizzati per i progetti di automazione

FlexiProject offre modelli standardizzati per la struttura ricorrente dei progetti di automazione, con il modello a sei fasi, la spina dorsale di validazione FAT-SAT-messa in servizio, i deliverable standard per fase e criteri di gate standard adatti all’automazione. Le società di ingegneria possono estendere i modelli secondo le particolarità del tipo di progetto (greenfield, modernizzazione brownfield, ampliamento di capacità, aggiornamento di sicurezza) senza rinunciare alla struttura di base. La gestione dei progetti di automazione basata su modelli agisce come l’equivalente digitale della pratica di ingegneria standardizzata: evita di reinventare gli elementi di routine del progetto e libera l’attenzione di ingegneria per le parti di ogni progetto che davvero differiscono.

Cosa FlexiProject non fa

FlexiProject non esegue l’ingegneria (è il lavoro dell’integratore del sistema di controllo), non esegue né il FAT né il SAT (richiedono banchi di prova e strumentazione), non qualifica i fornitori (richiede processi di acquisto e qualità) e non sostituisce la disciplina di far rispettare i criteri di gate (richiede l’impegno della direzione). Fornisce la visibilità, la struttura e la tracciabilità che rendono gestibile l’esecuzione disciplinata dei progetti di automazione su un portfolio, ma la disciplina in sé è organizzativa.

Domande frequenti

In cosa la gestione dei progetti di automazione differisce dalla gestione dei progetti generale?

I principi generali di gestione dei progetti si applicano ai progetti di automazione, ma questi hanno tratti propri che gli approcci generali non coprono del tutto: una spina dorsale di validazione sequenziale e obbligatoria (FAT prima del SAT prima della messa in servizio), una complessità multidisciplinare inerente che copre meccanica, elettrica, software di controllo, IT/OT e ingegneria di processo, requisiti di sicurezza e conformità con peso normativo, e dipendenza da più fornitori esterni i cui ritardi si propagano in modo imprevedibile. I project manager dell’automazione hanno di norma una formazione ingegneristica ed esperienza specifica di settore, perché il contenuto tecnico delle decisioni influenza i risultati del progetto a un livello che la gestione dei progetti generale non può sostituire.

Quanto dura un progetto di automazione tipico?

Dipende dall’ambito, dalla complessità e dal settore. Un’installazione greenfield semplice con integrazione limitata può concludersi in sei-nove mesi. Una modernizzazione brownfield tipica con integrazione nei sistemi di stabilimento esistenti dura di norma dai dodici ai diciotto mesi. I grandi progetti di investimento con tecnologia inedita o elementi critici di sicurezza possono durare da due a tre anni. Il maggiore fattore singolo di cronoprogramma spesso non è la complessità di ingegneria ma la complessità di coordinamento: i progetti con molti fornitori e discipline durano più a lungo di quelli con meno partecipanti, anche se il lavoro tecnico è simile.

Di chi è il progetto di automazione?

Un project manager dell’automazione è responsabile del cronoprogramma, del coordinamento, delle revisioni di gate e dell’allineamento tra discipline, ma il lavoro è multidisciplinare per natura e nessuna funzione lo controlla da sola. Gli appaltatori meccanici sono responsabili dell’infrastruttura fisica, quelli elettrici dell’alimentazione e del cablaggio, l’integratore del sistema di controllo della consegna di PLC e SCADA, gli ingegneri IT/OT dell’infrastruttura di rete, gli ingegneri di processo della filosofia di controllo, e l’esercizio dei requisiti che il sistema deve soddisfare. Il project manager dell’automazione è il coordinatore e integratore tra queste funzioni. Il sostegno dell’alta direzione è indispensabile, perché le decisioni di gate hanno implicazioni commerciali e di sicurezza che eccedono l’autorità del project manager.

Qual è la differenza tra FAT e SAT?

Il FAT (collaudo di accettazione in fabbrica) si svolge presso il fornitore o l’integratore prima della spedizione al sito, con ingressi e uscite simulati, per validare hardware e software in un ambiente controllato. Il SAT (collaudo di accettazione in sito) si svolge dopo l’installazione presso il cliente e verifica che l’installazione sia conforme ai disegni, che gli I/O fisici siano correttamente collegati a strumenti e attuatori reali e che l’integrazione con i sistemi di stabilimento esistenti funzioni. Il FAT intercetta i difetti nel punto meno costoso del ciclo di vita; il SAT intercetta i problemi che emergono solo nell’ambiente reale di installazione. Nessuno dei due può sostituire l’altro, e di norma entrambi sono necessari.

FAT e SAT sono obbligatori per legge?

Dipende dal settore. I progetti farmaceutici e delle scienze della vita richiedono FAT e SAT di fatto secondo l’Allegato 15 delle GMP dell’UE, che ne riconosce espressamente il ruolo nella qualifica. Per gli impianti dell’industria generale, la marcatura CE e le norme ISO pertinenti esigono l’evidenza che l’impianto soddisfi le specifiche di sicurezza, prestazioni e tecniche, e FAT e SAT sono i meccanismi standard per fornire tale evidenza. Anche dove non sono strettamente obbligatori per legge, FAT e SAT sono pratica comune nella maggior parte dei settori industriali, perché la ragione economica di intercettare i difetti nel punto più precoce possibile è ben documentata.

I progetti di automazione possono seguire metodi agili?

I progetti di automazione hanno dipendenze fisiche che limitano l’applicabilità dei metodi puramente agili: l’hardware richiede tempo di approvvigionamento, la messa in servizio richiede finestre di disponibilità dell’impianto, la validazione di sicurezza segue sequenze normative che non si possono iterare. Elementi del pensiero agile si adattano bene, in particolare il raffinamento iterativo dell’URS con i portatori di interesse prima del congelamento della progettazione e il debug iterativo durante il FAT e la messa in servizio. Ma la struttura a fasi dall’URS alla messa in servizio è una spina dorsale a cascata, perché i vincoli fisici e normativi la impongono, e i tentativi di applicare metodi puramente agili ai progetti di automazione danno di norma risultati peggiori dell’approccio disciplinato a fasi e gate.

La gestione dei progetti di automazione è la disciplina che consegna progetti di automazione industriale dalla specifica dei requisiti utente, passando per ingegneria, FAT, SAT e messa in servizio, fino alla produzione stabile, distinta dalla gestione dei progetti di produzione generica per la sua spina dorsale di validazione sequenziale e obbligatoria, la sua complessità multidisciplinare inerente, l’intensità della sicurezza e della conformità e la dipendenza dal coordinamento di più fornitori. La struttura a sei fasi dall’URS alla messa in servizio fornisce il quadro, e la spina dorsale di validazione FAT-SAT-SIT-messa in servizio fornisce la disciplina che la definisce, con i difetti rilevati al FAT che costano un ordine di grandezza in meno che al SAT e due ordini di grandezza in meno che durante la messa in servizio. Il coordinamento multidisciplinare tra le funzioni di meccanica, elettrica, controllo, IT/OT e ingegneria di processo assorbe la maggior parte dell’attenzione del project manager, e ridurre l’attrito nei passaggi di consegne è la leva singola più grande sulla durata complessiva del progetto. Cinque schemi di fallimento (URS insufficientemente specificata, FAT accorciato, lacune nel coordinamento multifornitore senza SIT, ritardi delle discipline vicine che si riversano, e sicurezza e cybersicurezza rinviate) possono essere prevenuti con contromisure nominate. I requisiti di sicurezza e conformità, tra cui IEC 61511, IEC 62443 e le regolamentazioni di settore, vanno integrati nel flusso del progetto fin dall’URS. La visibilità a livello di portfolio sui progetti di automazione simultanei abilita le decisioni di risorse, standardizzazione e capacità che le società di ingegneria prendono di continuo. Il caso Smart Automation mostra che una società di ingegneria di medie dimensioni può costruire in mesi uno standard di progetto disciplinato attorno a un sistema comune, mentre il caso del Model 3 di Tesla mostra che l’ambizione di automatizzare senza validazione pilota né esecuzione disciplinata a fasi e gate genera «l’inferno della produzione» alla massima scala possibile. FlexiProject sostiene il livello di esecuzione della gestione dei progetti di automazione con la visibilità di portfolio, la gestione del cronoprogramma che combina le viste diagramma di Gantt, elenco attività e kanban, un registro dei rischi collegato alle fasi, revisioni strutturate come revisioni di gate e modelli di progetto standardizzati. Il coordinamento multidisciplinare di ingegneria e il rispetto disciplinato dei criteri di gate restano responsabilità organizzative. Quando il portfolio di progetti di automazione di una società di ingegneria ha superato i fogli di calcolo e richiede un sistema che sostenga la disciplina tra più progetti simultanei e team multidisciplinari, trenta giorni di accesso completo senza carta di credito sono un modo pratico di verificare se è adatto.