ISO 19650 · Common data environment

Il CDE è un flusso, non una cartella.

Quasi tutti i progetti hanno un posto dove mettere i file. Molti meno sanno dire cosa deve essere vero perché un file passi da un posto al successivo, chi lo decide e come si chiama quando arriva. Quella differenza è tutto ciò che ISO 19650 intende per common data environment.

Fa parte degli strumenti ISO 19650.

Quattro stati, e cosa serve per uscire da ognuno

La ISO 19650-1 descrive il CDE come un processo gestito, non come un software. Ogni information container sta in uno solo di questi stati, porta con sé un codice di stato e una revisione, e si muove solo quando lo dice qualcuno con un ruolo definito.

01

Work in progress

Lo spazio del singolo task team. Qui l’informazione viene prodotta ed è visibile solo a chi la produce. Non esce niente senza un controllo di qualità rispetto all’information standard di progetto (denominazione, formato, metadati) e senza la revisione di chi risponde di quello che il team consegna (5.6.3, 5.6.4).

02

Shared

Visibile a tutto il delivery team, per il coordinamento e non per la costruzione. È qui che avviene la federazione, ed è qui che gli altri task team scoprono cosa stavi dando per scontato sul loro conto. Un container in questo stato è verificato ma non autorizzato: serve a coordinare un progetto, non a prendere una decisione che il committente pagherà.

03

Published

Autorizzato dall’incaricato principale e poi accettato dal committente (5.7.2, 5.7.4). L’informazione pubblicata è la versione su cui il progetto agisce, quindi il gate è esattamente il punto: qualcuno l’ha verificata rispetto agli exchange information requirements e ci ha messo la firma. Un CDE che lascia arrivare un container qui senza tutto questo ha tre stati e un’etichetta.

04

Archive

Ogni revisione superata, conservata con il suo audit trail invece che cancellata. È lo stato che quasi tutti saltano ed è quello che conta alla chiusura (5.8.1): la traccia di chi ha autorizzato cosa, e quando, è ciò che rende difendibile l’asset information model anni dopo, quando la domanda non è più cosa è stato costruito ma perché.

Il committente lo istituisce. Il delivery team ci deve lavorare dentro.

Secondo la ISO 19650-2 il CDE è un’attività della clausola 5.1: la 5.1.7, istituire il common data environment di progetto. Sta quindi in capo al committente, prima che esca l’invito a offrire. Cosa poi le due parti si devono a vicenda è la parte che quasi tutti i progetti lasciano implicita finché non diventa cara.

Committente

Cosa deve specificare l’EIR

Il CDE lo istituisci tu, e l’EIR è il punto in cui la filiera scopre quale sarà. Un requisito che nomina un prodotto e si ferma lì è un requisito che nessuno può quotare. L’Health Check EIR dedica a questo una sezione intera.

Clausola 5.1.7 · emesso con la gara

  • La piattaforma, o i criteri per approvarne una, e se la filiera debba portare la propria
  • I quattro stati per nome, con i codici di stato e di revisione che un container porta in ciascuno
  • Chi autorizza il passaggio tra due stati, per ruolo e non per persona
  • La convenzione di denominazione per intero, con un esempio svolto e non un rimando a un allegato
  • Accessi e permessi, comprese le scelte che un approccio security-minded impone su chi può vedere cosa
  • Cosa succede alla chiusura: cosa viene archiviato, in che formato, e chi lo conserva poi
Valuta il tuo EIR su questo

Entrambi i documenti nominano un common data environment. Nessuno dei due dichiara la convenzione di denominazione, i codici di stato o chi approva una transizione: così la piattaforma arriva, e la governance no.

Quello che mi chiedono davvero

SharePoint è un CDE?

Può esserlo, come può esserlo una piattaforma dedicata: nessuno dei due lo è appena installato. Un CDE è fatto dal flusso: i quattro stati, una convenzione di denominazione applicata a ogni container, codici di stato e revisione, un gate di approvazione con dietro un ruolo definito, e un audit trail che sopravvive a chi lascia il progetto. Ogni strumento configurato così va bene. Nessuno strumento usato come cartella condivisa va bene.

Un CDE solo, o uno per organizzazione?

Uno per progetto, istituito dal committente. I task team spesso tengono il proprio work in progress dentro i propri sistemi e la ISO 19650 lo prevede: il work in progress per definizione non è condiviso. Quello che non si può spezzare è la parte shared, published e archive. Due stati published sono due versioni della verità, ed è il guasto che la norma esiste per evitare.

Chi lo paga?

Lo istituisce il committente, il che di solito significa che tocca a lui procurarlo. Sul piano commerciale conta di più che l’EIR lo dica prima della gara: un delivery team che quota senza sapere se deve portare una piattaforma o pagare delle licenze su quella di un altro sta quotando un lavoro diverso da quello per cui sta gareggiando.

Sono a metà progetto e non è stato impostato niente. E adesso?

Parti dallo stato in cui sta un container, non dalla piattaforma. Metti per iscritto cosa è davvero published, cioè autorizzato, accettato e usato per costruire, e separalo da quello che è soltanto shared. Quella singola distinzione chiude gran parte della distanza e non richiede di migrare niente. La domanda sulla piattaforma viene dopo, ed è quasi sempre più piccola di come sembra da qui.

Dove si colloca rispetto al resto della ISO 19650?

A monte di quasi tutto. Il CDE si istituisce nella clausola 5.1, prima che l’EIR sia scritto; si testa in mobilitazione nella 5.5; ogni scambio della 5.6 e della 5.7 è una transizione tra i suoi stati; e la 5.8 archivia quello che resta. La pagina ISO 19650 disegna tutta la clausola 5 come figura interattiva, se vuoi vedere dove cade una singola attività.

Valuta il documento che hai davvero

Le due diagnostiche girano nel tuo browser e finiscono in un report che puoi passare a qualcun altro. Se la sezione CDE è quella dove il tuo punteggio è più basso, è mezz’ora di conversazione, non un progetto.

info@noeinsolutions.com