Far parlare i programmi che avete già

In breve. Collegare due programmi vuol dire far passare dati tra loro in modo controllato, senza nulla di magico. Le decisioni da prendere sono due: se il sistema nuovo legge soltanto o può anche scrivere, e chi ha il permesso di farlo. I tempi si stimano in ordini di grandezza, non in date secche. Questa guida è scritta per chi governa il lavoro, non solo per chi gestisce i server.

Collegare significa che un programma chiede dati a un altro, o gliene scrive, seguendo regole scritte. Per esempio, un cliente chiede lo stato di una pratica: l'assistente legge lo stato dal gestionale e risponde con quel dato, senza inventare nulla.

Ogni collegamento ha tre elementi: la fonte dei dati, un canale sicuro e il controllo su chi può vedere o cambiare le informazioni. Se ne manca anche uno, è meglio non partire, perché una riunione senza questi elementi produce soltanto diapositive.

Collegare non significa «mettere tutto insieme», ma scegliere un flusso preciso: un dato, in una direzione. Quando quel flusso funziona, se ne aggiunge un altro. Chi chiede dieci collegamenti il primo giorno, di solito, non riesce a chiuderne nessuno.

Flussi adatti al primo collegamento:

• stato di un ordine o di una pratica, in sola lettura;
• orari liberi in agenda, con conferma di una persona prima della scrittura;
• scadenze di un mezzo o di un contratto, in sola lettura;
• anagrafica minima per riconoscere chi scrive, limitata a pochi campi.

Gli stessi collegamenti servono a molti lavori ripetuti in ufficio: la fattura del fornitore confrontata con l'ordine, la disponibilità di magazzino letta prima di confermare una consegna, il sollecito preparato partendo dalle scadenze del gestionale. Trovate altri esempi, divisi per reparto, in cosa possiamo fare.

Da evitare all'inizio:

• pagamenti automatici;
• cancellazioni di massa;
• modifiche ai contratti;
• qualsiasi azione che sposta denaro senza l'approvazione di una persona.

Sola lettura. Il sistema nuovo guarda i dati ma non li cambia. È la scelta ideale per rispondere ai clienti, alimentare un cruscotto o fare controlli. Se qualcosa va storto basta spegnere il collegamento e tornare al modo di lavorare precedente, senza dover riparare dati.

Scrittura. Il sistema nuovo crea o aggiorna informazioni: apre una pratica, sposta una data, aggiunge una nota. Serve un permesso limitato e spesso anche il via libera di una persona prima di ogni scrittura.

Conviene partire in sola lettura e misurare i risultati. Solo dopo si apre la scrittura, un campo alla volta e mai dieci campi il primo giorno. Ogni campo in scrittura ha un proprietario, che firma l'autorizzazione.

La domanda da porsi è sempre la stessa: se il collegamento sbaglia, che cosa succede al cliente? Se la risposta preoccupa, conviene restare in sola lettura più a lungo, perché quella preoccupazione è un segnale utile e non un ostacolo.

Quando aprite la scrittura, stabilite prima come tornare indietro: come si annulla un'operazione, chi va avvisato e quanto tempo c'è per intervenire. Mettetelo per iscritto prima del giorno dell'accensione.

Molte aziende usano programmi privi di canali moderni per scambiare dati, ma si possono collegare lo stesso. Cambiano i modi e i tempi, mentre i doveri di controllo restano identici.

• File periodici. Ogni notte arriva un file con gli aggiornamenti: va bene quando i dati non servono al secondo.
• Lettura delle schermate. Si usa solo se non esiste un'altra strada e solo in ambienti controllati, perché non è mai la prima scelta.
• Archivio interno con viste dedicate. Si prepara una vista in sola lettura, senza scrivere direttamente nelle tabelle in uso.

Un sistema vecchio non è un motivo per rinunciare, ma pone dei limiti. Scriveteli nel piano e dite chiaramente quali dati non saranno aggiornati in tempo reale, così da evitare sorprese nella riunione con la direzione.

Documentate anche i periodi di fermo tipici, come chiusure, elaborazioni notturne e finestre di manutenzione. L'assistente deve sapere cosa dire quando la fonte è ferma: «non ho il dato aggiornato» è sempre meglio di un numero vecchio presentato come fresco.

I permessi stabiliscono chi può vedere i dati e chi può cambiarli. Non si decidono a voce: si scrivono e si fanno firmare da chi è responsabile del dato.

• Identità. Ogni azione ha un autore riconoscibile, che sia una persona o un sistema con un nome preciso.
• Minimo necessario. Si danno solo i campi utili al flusso, senza aprire l'intero elenco clienti quando serve un solo ordine.
• Scadenza. Gli accessi di prova hanno una data di fine, dopo la quale si rinnovano o si chiudono.
• Registro. Si annota chi ha letto o scritto, quando e su quale dato, sia per i controlli sia per sapere cosa spegnere.
• Revoca. Deve esistere un modo chiaro per togliere l'accesso entro un giorno lavorativo.

Se un fornitore chiede un «accesso completo», la risposta è no. Chiedetegli invece l'elenco dei campi, la direzione in cui passano i dati, il modo per revocare l'accesso e il luogo in cui finiscono le eventuali copie.

Tenete separati gli accessi di prova da quelli definitivi, con nomi e scadenze diversi. Non riutilizzate mai la stessa chiave di accesso solo «per fare prima».

Senza gli elementi elencati qui sotto il collegamento resta sulla carta, ed è meglio dirlo all'inizio che scoprirlo a metà progetto.

1. Un referente del flusso, cioè chi conosce il lavoro reale e non solo il programma.
2. Un referente tecnico, che apre canali e permessi con tempi realistici.
3. Un ambiente di prova con dati finti o mascherati, perché la prima prova non si fa mai sui clienti veri.
4. Una regola su cosa si può scrivere: quali campi sì, quali no e chi approva.
5. Un criterio di spegnimento, cioè cosa misurate per decidere di fermarvi entro pochi giorni.
6. Gli orari di manutenzione, con quello che l'assistente deve fare quando i sistemi vecchi sono fermi.
7. Esempi di pratiche: tre casi tipici resi anonimi valgono più di dieci riunioni astratte.

Portate esempi di pratiche vere, privi di dati sensibili, perché una pratica tipica spiega più di un diagramma vuoto. Segnalate anche eccezioni e casi limite, che sono proprio quelli che mettono in crisi i collegamenti.

Se il referente tecnico manca per settimane, la colpa non è dello strumento. Il calendario di un collegamento dipende soprattutto dalla disponibilità delle persone interne.

I tempi dipendono dall'età del sistema, dalla qualità dei dati e da chi deve approvare i permessi. Per questo si ragiona per ordini di grandezza, mai con date secche inventate.

• Sola lettura su un programma moderno. Spesso settimane e non mesi, a patto che i permessi arrivino presto.
• Scrittura su un solo campo. Richiede più tempo per le prove, per il sistema di annullamento e per il via libera di chi è responsabile del dato.
• Sistema vecchio con file notturni. Può partire in poche settimane, ma i dati non saranno aggiornati al minuto.
• Più sistemi insieme. I tempi si sommano, perché ogni fonte nuova porta attese e controlli in più.

I ritardi più comuni non sono tecnici: dipendono da approvazioni ferme, campi non documentati e referenti assenti. Fissate quindi delle date anche per le decisioni, non solo per le attività di costruzione.

Alla direzione i tempi vanno comunicati come intervalli, per esempio «poche settimane per la sola lettura, a partire dalla firma dei permessi». Se la firma non arriva, il conto dei giorni non parte. Evitate promesse come «entro venerdì» quando non avete ancora tutti gli elementi.

In riunione bastano quattro informazioni: che cosa colleghiamo, in quale direzione, con quali campi e come si spegne. Se qualcuno propone di «collegare tutto», rispondete indicando il singolo flusso scelto. Se vi chiedono una data precisa senza i permessi firmati, date l'ordine di grandezza e la condizione da cui dipende, cioè la firma.

Scrivete anche che cosa non farete durante la prova. L'elenco dei «no» protegge il calendario e il gruppo di lavoro, ed evita che a metà strada tornino richieste fuori dal perimetro concordato.

• Chiedere di «collegare tutto» senza aver scelto un singolo flusso.
• Partire in scrittura perché sembra una soluzione più completa.
• Non avere un ambiente di prova.
• Lasciare accessi senza scadenza dopo la fine del pilota, cioè della prova misurata su un flusso vero.
• Promettere aggiornamenti al minuto su sistemi che lavorano con file notturni.
• Nascondere i limiti al consiglio di amministrazione o al cliente interno.
• Copiare dati in fogli paralleli «temporanei» che poi restano in uso per anni.
• Non provare lo spegnimento prima della partenza.
• Accettare accessi completi «per fare prima».
• Saltare il referente del flusso e parlare soltanto con chi gestisce i sistemi.

Prima di considerare concluso il lavoro, fate una prova di spegnimento. Togliete l'accesso, verificate che l'assistente dica di non avere il dato e controllate che il lavoro torni al modo precedente. Se non sapete spegnere il collegamento, non siete ancora pronti ad accenderlo.

Guide collegate: Il piano dei primi 90 giorni · Per l'IT e la sicurezza · Dati e analisi

• Un flusso solo scelto, con direzione chiara
• Scelta scritta tra sola lettura e scrittura
• Elenco dei campi e limiti documentati
• Ambiente di prova pronto
• Referente del flusso e referente tecnico nominati
• Permessi limitati al necessario, con scadenza
• Registro di chi legge o scrive
• Criterio e modo di spegnimento
• Comportamento in manutenzione definito
• Tempi comunicati come ordini di grandezza realistici