Il dato arriva, ma il numero resta da chiarire

Per chi dirige l’IT, questa verifica conta più del semplice funzionamento delle interfacce. Un’integrazione può consegnare un dato nei tempi previsti, mentre il sistema che lo riceve attribuisce un significato diverso allo stato, al cliente o alla data di decorrenza. Il trasferimento è riuscito. L’interpretazione no.

Ecco perché le riconciliazioni possono sopravvivere anche a un progetto di integrazione riuscito. Qualcuno deve stabilire quale dato faccia fede, interpretare le eccezioni e decidere quando un numero sia definitivo. Questo lavoro può finire in un foglio di calcolo, in una riunione o nella conoscenza tacita di chi sa quale schermata consultare. Nel budget software non si vede facilmente, perché viene pagato con il tempo e l’attenzione delle persone.

Questo non significa che integrare sia un errore. Spesso esistono buone ragioni per mantenere sistemi distinti. Ma limitarsi ai canoni e al costo iniziale delle interfacce significa ignorare il lavoro continuo necessario a far concordare le definizioni.

Ogni collegamento resta esposto al prossimo cambiamento

Un’interfaccia non è conclusa quando passa il primo dato. Cambia un campo, si sposta una regola di approvazione, si restringe un permesso o un report richiede una nuova definizione. A quel punto serve qualcuno che sappia ricostruire le conseguenze sui due lati del collegamento. Un altro strumento può aggiungere un altro punto da cui iniziare questa indagine.

Qui sta la differenza tra integrare meglio i sistemi e avere meno integrazioni da gestire. La prima strada è preziosa quando il confine deve rimanere. Può renderlo più affidabile e più facile da controllare. Da sola, però, non elimina quel confine e non risolve definizioni concorrenti dello stesso oggetto aziendale.

L’obiettivo non è dichiarare superflue tutte le interfacce. Servizi esterni, applicazioni specialistiche e partner continueranno a creare confini. Vale invece la pena chiedersi se alcuni confini all’interno dello stesso lavoro siano stati accettati come inevitabili senza esaminarli.

Un modello dati unico cambia ciò che va verificato

“One platform, one data model” è un’alternativa concreta solo se quel modello governa il lavoro prima diviso tra i quattro strumenti. Cliente, ordine e stato dell’approvazione devono mantenere lo stesso significato mentre le persone passano da una funzione all’altra. Permessi, regole e report devono riferirsi a quel contesto comune, senza copie nascoste da riconciliare in seguito.

Un’interfaccia grafica comune non basta a dimostrarlo. Non basta neppure chiamare suite un insieme di prodotti. Chi dirige l’IT dovrebbe seguire una modifica lungo la piattaforma proposta e chiedere dove nasce la sua definizione, dove può essere cambiata e quali gruppi dovranno gestirne gli effetti. Le risposte mostrano se l’architettura ha eliminato un passaggio oppure lo ha soltanto nascosto.

Anche il modello unico richiede governo. Se una definizione è sbagliata, condividerla diffonde l’errore. Il vantaggio è che il disaccordo ha un luogo visibile in cui essere risolto, anziché obbligare ogni collegamento a portarsi dietro una propria traduzione.

L’acquisto va giudicato sul prossimo cambiamento

Scegliere quattro strumenti o una piattaforma non significa soltanto confrontare quattro fatture con una. Significa decidere dove verranno assorbite le modifiche future. In un insieme di sistemi, il prossimo cambiamento potrebbe attraversare più definizioni prima che qualcuno possa fidarsi della risposta. In una piattaforma con un modello davvero condiviso, l’organizzazione può modificare una definizione e governarne gli effetti sul lavoro circostante.

La domanda più utile in fase di acquisto potrebbe quindi arrivare dopo la dimostrazione: quando cambieranno questo cliente, questa regola o questo processo, in quanti punti dovremo tornare a farli significare la stessa cosa?