Come organizzare la collaborazione tra integratore, software house e reparto manutenzione in un unico progetto?

Perché questo tema è oggi rilevante

La collaborazione tra integratore, software house e reparto di manutenzione non è più una semplice questione di comodità organizzativa. In pratica, oggi determina se il progetto possa partire senza controversie sull’ambito, se una modifica software possa bloccare il collaudo tecnico e se lo stabilimento sarà in grado di gestire la soluzione in sicurezza dopo l’implementazione. Quanto più la logica di processo viene spostata verso il livello software, lasciando meno spazio alle funzioni standard di controllori e dispositivi, tanto più diventano decisive le delimitazioni di responsabilità. Se non vengono definite fin dall’inizio, il costo del progetto di solito non cresce in modo lineare, ma attraverso correzioni introdotte nel punto sbagliato: l’integratore modifica le interfacce, la software house ricostruisce la logica applicativa e la manutenzione esplicita solo alla fine requisiti operativi che nessuno aveva formalizzato prima.

È anche un tema di budget, non solo tecnico. In molti progetti, la domanda su come collaborino le parti si trasforma molto rapidamente nella domanda su che cosa rappresenti davvero il software dedicato per l’industria nel budget d’investimento: una componente dell’investimento, un costo operativo o una combinazione di entrambi. Se l’architettura della soluzione prevede che funzioni chiave del processo, della reportistica, delle ricette, della tracciabilità dei lotti o dell’integrazione con i sistemi di stabilimento vengano sviluppate al di fuori del perimetro standard dell’automazione, questo va riconosciuto prima dell’ordine, non dopo il primo prototipo. Il criterio pratico è semplice: se l’assenza di un unico responsabile decisionale per il confine tra automazione, applicazione ed esercizio impedisce di attribuire in modo univoco requisiti, test e costi delle modifiche, allora il progetto è già entrato in un’area di rischio elevato e richiede una correzione del modello di collaborazione.

Lo si vede con particolare chiarezza nel caso di un revamping di linea in cui l’integratore è responsabile del controllo e della messa in servizio, la software house del livello applicativo e dello scambio dati, e la manutenzione dovrà poi prendere in carico il sistema per il funzionamento continuo. Se il reparto di manutenzione viene coinvolto solo in fase di collaudo, di norma emergono problemi che non sono “difetti”, ma lacune decisionali: assenza di una procedura di ripristino dopo guasto, mancanza di requisiti per gli account di servizio, finestre di aggiornamento non definite, dipendenza non prevista da un fornitore esterno o osservabilità insufficiente degli errori. A quel punto la controversia non riguarda più la qualità del codice o la correttezza del quadro elettrico, ma chi debba sostenere il costo di adeguamento del sistema alle condizioni reali dello stabilimento. Qui il tema si collega naturalmente ai costi nascosti del progetto e della conformità, perché il ritardo del collaudo oppure una modifica tardiva delle funzioni di sicurezza, della documentazione tecnica o della validazione è spesso la conseguenza di una collaborazione organizzata male, e non di un singolo errore esecutivo.

L’aspetto della conformità entra in gioco quando la ripartizione delle attività incide sulle caratteristiche del prodotto, sulle funzioni legate alla sicurezza, sulla documentazione o sulle modalità di messa in servizio della soluzione. Non tutte le integrazioni tra applicazione e macchina comportano gli stessi obblighi, ma già la sola mancanza di chiarezza su chi sia responsabile della descrizione delle funzioni, della gestione delle modifiche e della completezza della documentazione costituisce un segnale d’allarme. Ciò riguarda in particolare i progetti realizzati all’interno del proprio stabilimento, gli ammodernamenti eseguiti per fasi e le soluzioni costruite per uso interno, dove il confine tra “attività di manutenzione” e realizzazione o modifica sostanziale può avere rilevanza giuridica. Per questo la decisione sul modello di collaborazione va presa non quando emerge il primo conflitto, ma quando si definisce il perimetro: chi descrive i requisiti operativi, chi approva l’architettura, chi è responsabile dei test tra i diversi livelli e chi prende in carico il sistema dopo la messa in servizio con una reale capacità di mantenerlo nel tempo. In questi casi diventano rilevanti anche gli obblighi e le conseguenze legati alla modifica di una macchina.

Dove più spesso aumentano i costi o i rischi

Nei progetti gestiti congiuntamente da integratore, software house e reparto di manutenzione, i costi raramente aumentano a causa di un unico grande errore. Di solito crescono nei punti di contatto tra le responsabilità, cioè dove nessuno ha il compito pieno di portare la questione fino in fondo. I fattori più costosi non sono gli errori tecnici in sé, ma le decisioni rinviate o prese senza un responsabile: assenza di un’architettura di comunicazione concordata, confini non descritti tra logica di controllo e livello applicativo, modalità di test dopo una modifica non definite e presa in carico del sistema per l’esercizio senza una reale capacità di manutenerlo. In pratica, questo significa correzioni eseguite già dopo la messa in servizio, controversie sull’ambito contrattuale e spostamento della responsabilità per i fermi a una fase in cui ogni modifica è la più costosa. Un criterio semplice per valutare la situazione è chiedersi se, per ogni funzione critica, sia possibile indicare una parte responsabile del requisito, una dell’esecuzione e una del collaudo. Se la risposta è “dipende”, il progetto è già gravato da un rischio organizzativo.

Una seconda area di perdite emerge quando le decisioni di progetto vengono prese senza il coinvolgimento della manutenzione oppure, al contrario, quando la manutenzione impone soluzioni comode dal punto di vista dell’assistenza ma incoerenti con l’architettura del sistema. L’integratore guarda di norma all’avviamento e all’interazione con i dispositivi, il software house alla logica di business e alle interfacce, mentre la manutenzione si concentra su disponibilità, diagnostica e tempi di ripristino. Se queste prospettive non si incontrano nella fase di definizione dei requisiti, riemergono più avanti sotto forma di costi di modifica: segnali aggiuntivi, revisione dei permessi, assenza della registrazione degli eventi necessari alla diagnostica, impossibilità di eseguire aggiornamenti in sicurezza oppure mancanza di una procedura di bypass in caso di guasto. È in questo momento che il tema porta naturalmente al ruolo del project manager ingegneristico, perché il problema non è più una singola decisione tecnica, ma la gestione delle dipendenze, delle scadenze di allineamento e delle responsabilità di escalation.

Un esempio pratico tipico è un’implementazione in cui l’applicazione di supervisione deve gestire ordini, ricette e reportistica, mentre l’integratore è responsabile del controllore, degli azionamenti e della sequenza della macchina. Se il confine delle responsabilità viene descritto solo in termini funzionali, senza indicare stati intermedi, condizioni di errore e comportamento in caso di perdita di comunicazione, ciascuna parte costruirà a modo proprio ipotesi “sicure”. La software house riterrà che la mancata conferma significhi ripetere il comando, l’integratore assumerà che il comando sia monouso, e la manutenzione si troverà con un sistema che non è possibile diagnosticare durante il fermo. L’esito è prevedibile: avviamento lungo, errori ambigui, correzioni delle interfacce e tensioni attorno alla domanda su chi sia responsabile del fermo non pianificato. Nella valutazione di una situazione del genere vale la pena misurare non solo la data di consegna, ma anche il numero di modifiche alle interfacce dopo l’approvazione del progetto, il numero di anomalie rilevate solo in campo e il tempo necessario per ricostruire la causa del guasto. Se questi indicatori crescono nonostante l’avanzamento dei lavori, il problema di solito sta nell’organizzazione della collaborazione, e non nelle prestazioni del singolo fornitore.

Un’ulteriore fonte di rischio è considerare test e documentazione come un sottoprodotto dell’avviamento. Laddove il sistema influisce sul funzionamento della macchina, sull’accesso dell’operatore, sulla diagnostica, sui parametri di processo oppure sulle funzioni legate alla sicurezza, una modifica tardiva non è una semplice correzione software. Può richiedere una nuova valutazione delle ipotesi di progetto, l’aggiornamento della documentazione tecnica, la ripetizione di parte delle prove e, in determinate situazioni concrete, anche una nuova analisi degli obblighi a carico dell’utilizzatore o del soggetto che introduce la modifica. Questo non può essere deciso in astratto allo stesso modo per ogni progetto, ma la regola pratica è semplice: quanto più la modifica incide sul comportamento del sistema in condizioni normali e anomale, tanto meno è ammissibile gestirla con “accordi operativi”. Qui inizia anche l’area degli errori tipici che si riscontrano nella costruzione e nell’ammodernamento delle macchine: assenza di blocchi contro configurazioni errate, mancata imposizione della sequenza delle operazioni e assenza di meccanismi che prevengano l’errore dell’operatore o del servizio di assistenza. Se queste misure non vengono incluse nel perimetro fin dall’inizio, ritornano in seguito sotto forma di costo, fermo impianto o controversia sulle responsabilità.

Come affrontare il tema nella pratica

In pratica, la collaborazione tra integratore, software house e reparto manutenzione non dovrebbe essere organizzata attorno alle aziende, ma attorno ai confini di responsabilità per specifiche decisioni tecniche. È questo che stabilisce chi risponde della logica di controllo, chi del livello applicativo e della comunicazione, chi delle condizioni di assistenza, dei backup, del ripristino dopo guasto e dell’implementazione sicura delle modifiche in campo. Se questi confini restano descritti in modo generico, il progetto comincia a procedere per supposizioni: l’integratore presume che i requisiti di esercizio saranno forniti dallo stabilimento, la software house dà per acquisita la logica di processo, e la manutenzione riceve un sistema che non può essere gestito efficacemente senza l’autore del codice. La conseguenza non è solo organizzativa. Aumenta il costo dell’avviamento, si allungano i tempi di eliminazione dei guasti e, in caso di controversia, diventa più difficile stabilire se il problema derivi da un errore di implementazione, da ipotesi incomplete o da una modifica non controllata dopo il collaudo. In questi casi emergono spesso anche costi nascosti di progetto e conformità.

Per questo la prima decisione non dovrebbe essere la scelta dello strumento né il calendario dei workshop, ma l’adozione di un modello condiviso di responsabilità per l’intero ciclo di vita della soluzione. Per un manager il criterio pratico è semplice: ogni funzione che influisce sul funzionamento della macchina o della linea deve avere un responsabile identificato in quattro stati del progetto — progettazione, avviamento, accettazione e manutenzione. Se per una determinata funzione non è possibile rispondere in modo univoco a chi approva il requisito, chi esegue la modifica, chi ne verifica gli effetti e chi si assume la responsabilità del ripristino del funzionamento dopo un guasto, allora il perimetro non è pronto per l’esecuzione. È qui che emerge naturalmente il ruolo del project manager ingegneristico: non come figura “che si occupa delle scadenze”, ma come responsabile dell’ordine decisionale tra discipline e fornitori.

I problemi più frequenti nascono nel punto di contatto tra il controllo e il software dedicato. Un esempio tipico è un’applicazione che modifica il modo di selezionare le ricette, parametrizza la sequenza di lavoro oppure incide sui permessi dell’operatore. Per una software house può sembrare una normale modifica funzionale, ma per l’integratore e per la manutenzione significa intervenire sul comportamento del sistema, sulla diagnostica e sulle procedure di cambio formato. Se prima dell’implementazione non è stato definito dove termina la responsabilità per l’interfaccia e dove inizia quella per la logica di processo, una correzione eseguita “in produzione” può richiedere nuove prove, l’aggiornamento delle istruzioni e, talvolta, la revisione delle procedure di assistenza. È proprio qui che il tema entra anche nell’ambito del budget: il costo del software dedicato per l’industria non dipende solo dalla scrittura del codice, ma anche da quanta responsabilità il progetto trasferisce alla fase di validazione, alla documentazione e alla manutenzione successiva. Per questo vale la pena considerare anche i costi nascosti del progetto e della conformità.

Per evitare questa situazione, conviene valutare lo stato del progetto non in base alle dichiarazioni dei fornitori, ma agli elementi verificabili. Il set minimo comprende un elenco concordato delle interfacce, la descrizione del versionamento, una procedura per la segnalazione e l’autorizzazione delle modifiche, gli scenari dei test di accettazione e un piano di manutenzione dopo l’avviamento. In questo caso funziona bene un semplice filtro decisionale:

• se la modifica incide sulla logica di processo, sui parametri di lavoro o sul comportamento dell’operatore,
• se può essere riprodotta, testata e annullata senza il coinvolgimento dell’autore della soluzione,
• se la documentazione dopo l’implementazione consente allo stabilimento di mantenere il sistema senza dipendere da conoscenze “nascoste” nella casella e-mail dell’esecutore.

Se anche a una sola di queste domande la risposta è “no”, il progetto richiede una definizione più precisa del perimetro, non un’accelerazione delle attività. Solo a questo punto ha senso richiamare i requisiti formali: non per aggiungere clausole generiche al contratto, ma per verificare se la natura delle modifiche incida già sugli obblighi documentali, sulle attività di accettazione o sulla valutazione delle responsabilità lato utilizzatore. Questo aspetto è particolarmente importante quando lo stabilimento contribuisce direttamente alla soluzione, la sviluppa con risorse proprie oppure realizza parti del sistema per uso interno. In tal caso la collaborazione tra tre soggetti smette di essere solo una questione di organizzazione del progetto ed entra anche nell’ambito degli obblighi legali dello stabilimento, compresi quelli legati alla marcatura CE.

A cosa prestare attenzione durante l’implementazione

I problemi più numerosi non emergono quando il team non ha competenze, ma quando le parti del progetto operano correttamente entro i propri confini e nessuno gestisce il punto di interfaccia tra loro. In un progetto in cui l’integratore è responsabile del livello esecutivo e dei collegamenti con l’automazione, la software house della logica applicativa e la manutenzione della continuità operativa dello stabilimento, una cattiva organizzazione dell’implementazione finisce quasi sempre per spostare il rischio alla fase di avviamento. È proprio in quel momento che si vede se le decisioni progettuali sono state prese pensando all’intero ciclo di vita della soluzione oppure solo alla chiusura del perimetro di ciascun fornitore. Per il progetto questo di solito significa una di tre cose: correzioni costose dopo l’avviamento, una controversia sulle responsabilità in caso di guasti oppure il ritardo dell’accettazione, perché il sistema funziona solo in condizioni di laboratorio e non nel processo reale.

La trappola principale sta nel fatto che l’implementazione viene spesso trattata come una fase tecnica, mentre in pratica è il momento in cui si verificano decisioni organizzative. Se l’integratore può introdurre modifiche nel controllo senza una piena conoscenza degli effetti lato applicazione, la software house sviluppa funzioni senza conferma dei vincoli dei dispositivi e della rete industriale, e la manutenzione viene coinvolta solo al momento dell’accettazione, allora il problema non è la comunicazione, ma una ripartizione difettosa delle responsabilità. Un criterio pratico di valutazione è semplice: prima dell’ingresso in impianto, ogni parte dovrebbe essere in grado di indicare quali modifiche può eseguire autonomamente, quali richiedono un’autorizzazione congiunta e chi prende la decisione di fermare i lavori se emerge un rischio per il processo, per la sicurezza o per la ripristinabilità della configurazione. Se la risposta dipende da “accordi da definire di volta in volta”, l’implementazione non è ancora pronta, anche se il cronoprogramma formalmente è corretto.

Un esempio tipico riguarda una modifica apparentemente minima: il cambiamento della sequenza di lavoro di una postazione che, dal punto di vista della software house, è una correzione della logica, per l’integratore comporta tempi di risposta diversi dei dispositivi e per la manutenzione incide sulla diagnostica e sulle procedure dopo un guasto. Se una modifica di questo tipo arriva in impianto senza una revisione congiunta degli effetti, dopo l’avviamento diventa difficile stabilire se l’origine del problema sia il codice, la configurazione del controllore, i parametri dell’azionamento oppure il modo in cui l’operatore utilizza il sistema. A quel punto il costo aumenta non solo per la correzione in sé, ma anche per il tempo di fermo, per i test aggiuntivi e per il coinvolgimento di persone che prima non dovevano partecipare all’analisi. Per questo è utile misurare non solo la data di avviamento, ma anche il numero di modifiche introdotte in implementazione senza un iter completo di approvazione, il tempo necessario per ripristinare la versione precedente e la quota di anomalie rilevate solo dopo la consegna del sistema all’esercizio. Questo fornisce un quadro reale per capire se la collaborazione tra le tre parti è governata oppure semplicemente mantenuta in modo estemporaneo.

In questa fase emerge naturalmente anche il confine tra una normale implementazione e una situazione in cui lo stabilimento inizia a co-sviluppare la soluzione in modo tale da incidere sui propri obblighi formali. Se il reparto di manutenzione non si limita a esprimere un parere, ma modifica direttamente la logica, seleziona i componenti del sistema o assume parte delle decisioni progettuali, il tema non riguarda più soltanto l’organizzazione della collaborazione, ma rientra anche nell’ambito delle obblighi e conseguenze legati alla modifica di una macchina e delle macchine realizzate per uso proprio. Non è possibile stabilirlo con un’unica regola valida per tutti i progetti; contano l’estensione dell’intervento, il grado di autonomia dello stabilimento e chi, di fatto, definisce le caratteristiche della soluzione. Lo stesso vale per l’analisi dei rischi: se la modifica incide sulla funzione del processo, sul comportamento dell’operatore, sulle condizioni di intervento in assistenza oppure sulla sequenza degli stati di emergenza, allora non si tratta più soltanto di “se implementare”, ma anche di “se rivalutare il rischio e aggiornare i presupposti di accettazione”. Nella pratica è proprio qui che si vede con maggiore evidenza il ruolo di chi guida il progetto: non come semplice intermediario che gestisce gli stati di avanzamento, ma come responsabile della decisione su dove finisca una comoda semplificazione e dove inizi la responsabilità tecnica e giuridica.