Uno stabilimento pesa il peso dei rifiuti sulla pesa a ponte. Un altro stabilimento lo stima in base al volume dei container. Entrambi forniscono un dato per la stessa riga del rapporto. Nessuno ha mentito, nessuno ha commesso un errore. Solo che non è mai stato fissato quale sia esattamente la definizione di quel dato, e quindi ogni divisione ha scelto l'interpretazione più logica disponibile in quel momento.
Questo non è un'eccezione. È lo stato normale di un'organizzazione in cui la stessa metrica viene fornita da team diversi, con sistemi di origine diversi e storie diverse. La domanda non è come eliminare questa differenza prima che si manifesti. La domanda è cosa farne una volta individuata.
Il passaggio che di solito viene saltato è che la definizione stessa venga registrata da qualche parte. Non nella testa del controller che lo fa così da anni, ma in un registro: questo dato significa questo, si misura così, e queste unità rientrano o non rientrano nel conteggio. Cosa sia un valore valido all'interno di questa definizione e chi se ne accorga quando una fornitura di dati non rientra in essa è descritto nella pagina su cos'è un valore valido e chi se ne accorge quando un valore non lo è. Senza questa registrazione, ogni somma tra divisioni è una somma di cose che non sono proprio uguali, racchiuse in un unico numero che sembra univoco ma non lo è.
Questa registrazione è esattamente il lavoro della Data Readiness Scan: non riscrivere il rapporto, ma costruire il registro dei dati in cui, per ogni dato, sia indicato cos'è, da dove proviene e chi ne è responsabile. Quel registro è il luogo in cui la differenza tra divisioni diventa visibile, invece di diventare visibile solo dopo che il numero è già stato somm ato.
Una volta che vedete che la divisione A e la divisione B intendono qualcosa di diverso per lo stesso dato, esistono grosso modo tre percorsi.
Il primo è armonizzare: imporre un'unica definizione per tutta l'organizzazione, con tutti gli adeguamenti di sistema che ciò comporta. Questa è spesso la strada giusta nel lungo periodo, ma non è qualcosa che si realizza dall'oggi al domani.
Il secondo è documentare e correggere: lasciare la deviazione dov'è, ma registrarne l'entità e, tramite una conversione fissa, garantire che il totale sia comunque corretto. Funziona quando la differenza è stabile e conosciuta — ad esempio quando una sede utilizza strutturalmente un metodo di misurazione diverso ma riconducibile.
Il terzo è segnalare: non correggere, ma alzare una bandiera non appena una fornitura di dati si discosta dal pattern abituale di quella divisione. Come impostare una tale segnalazione di deviazione e chi ne venga informato è descritto nella pagina su come impostare una segnalazione di deviazione e chi se ne accorge quando accade. Questo percorso non serve a risolvere il problema, ma a evitare che passi inosservato mentre lavorate verso una soluzione strutturale.
Quale percorso sia appropriato dipende da quante divisioni si discostano, da quanto sia stabile tale deviazione e da quanto tempo resta prima che il numero entri in un periodo di rendicontazione. È una valutazione che varia da organizzazione a organizzazione e che questo registro non fa per voi — ma rende visibile che la valutazione va fatta.
La differenza di definizione è uno degli errori più silenziosi che esistano, perché ogni divisione, presa singolarmente, ha ragione. La sede che stima in base al volume dei container non fa nulla di sbagliato all'interno del proprio processo. Il problema nasce solo al livello in cui i numeri si incontrano, e proprio lì spesso nessuno è designato a verificare se le definizioni sottostanti siano anche solo comparabili.
È questa la ragione per cui la responsabilità per ogni singolo dato è tanto importante quanto la definizione stessa. Quali controlli spettino a un dato e chi se ne accorga quando uno di questi controlli viene saltato è descritto nella pagina su quali controlli spettano a un dato e chi se ne accorge quando ne manca uno. Senza un responsabile designato, la domanda 'ma chi se ne accorge, in realtà' resta senza risposta, anche quando la definizione è scritta sulla carta.
È tentante voler risolvere questo problema con un sistema che normalizzi automaticamente le forniture di dati. Ma uno strumento posto sopra un insieme di dati non definiti non normalizza nulla — racchiude le stesse differenze in un'interfaccia più ordinata. La sequenza che regge è prima fissare la definizione e la responsabilità, e solo dopo valutare quale sistema si adatti a questo. Il motivo per cui questa sequenza non è casuale è approfondito nella pagina su comprare prima uno strumento o organizzare prima il processo.
Una volta che per ogni dato è fissata la definizione, chi ne è il responsabile e quali deviazioni vengono segnalate, emerge un altro tipo di domanda: chi svolgerà poi il lavoro legato a questi controlli — il riconteggio, la verifica presso la divisione che si discosta, la manutenzione del registro stesso. Parte di questo lavoro è sufficientemente ripetibile da poter essere affidata a un passaggio automatico, parte richiede una valutazione che resta compito umano. La scan del lavoro di FTE TO AI calcola per ogni compito quale parte possa essere presa in carico dall'AI, basandosi sullo stesso tipo di concretezza di questo registro: non la domanda se l'automazione sia possibile, ma quale parte di quale compito ne rientri.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.