Un fornitore chiede prima o poi: cosa deve saper fare il sistema? La risposta non sta nel fornitore né in un elenco di funzionalità che anche altre aziende hanno spuntato. La risposta sta nel proprio processo: quali punti dati raccoglie, chi li fornisce, da dove provengono e cosa va storto se nessuno controlla.
Il percorso comune è: selezionare uno strumento, configurarlo, e solo dopo scoprire quali dati devono provenire da dove. Quest'ordine funziona al contrario, perché uno strumento non ha un'opinione sul suo processo. Chiede input, e quell'input deve provenire da qualcosa. Se quel qualcosa — il registro dei punti dati, la titolarità, le fonti — non esiste ancora, la configurazione dello strumento diventa una ricerca che nessuno aveva pianificato.
L'altro ordine parte dal processo. Prima si mappa quali punti dati sono necessari, chi li fornisce, da quale sistema o foglio di calcolo provengono, e quali regole di qualità si applicano. Solo dopo diventa chiaro quali requisiti uno strumento deve effettivamente soddisfare. Non requisiti astratti come "facile da usare" o "scalabile", ma requisiti concreti come: deve collegarsi a questo specifico sistema sorgente, deve poter distinguere tre titolari all'interno di un unico punto dato, deve segnalare una deviazione quando una cifra esce da un margine prestabilito.
L'ordine non è una preferenza metodologica; deriva da ciò che precede logicamente e funzionalmente lo strumento. Uno strumento può ricevere requisiti solo se esiste qualcosa da cui derivarli. Quel qualcosa è il processo: il flusso di dati dalla fonte al report, con tutti i passaggi manuali, i trasferimenti e le assunzioni che lo accompagnano. Senza questa visione d'insieme, un'organizzazione stabilisce i requisiti in base a ciò che lo strumento sa fare, non in base a ciò di cui il processo ha bisogno. Sembra una differenza sottile, ma determina se lo strumento in futuro si allineerà alla realtà o si porrà accanto ad essa.
Questo si collega alla domanda come scegliere uno strumento senza pentirsene in seguito: il pentimento spesso non nasce da uno strumento scadente, ma da uno strumento che ha dovuto indovinare i requisiti perché nessuno li aveva messi per scritto.
Se lo strumento arriva prima e il processo dopo, si generano due tipi di costi. Il primo è la riconfigurazione diretta: funzionalità che non si adattano, collegamenti che devono comunque essere costruiti, campi che restano vuoti perché nessuno sa chi deve compilarli. Il secondo costo è meno visibile ma più pesante: lo strumento inizia a produrre report che appaiono più ordinati, mentre le cifre sottostanti restano ancora non riconducibili a una fonte o a un titolare. Questo rischio è descritto più ampiamente nella pagina su cosa costa collocare uno strumento sopra un processo disorganizzato: lo strumento nasconde il problema invece di risolverlo.
La domanda su quale ordine risulti più economico dipende da quanti punti dati, sistemi e titolari esistono già e quanti di questi non sono ancora stati documentati. Per un processo piccolo con poche fonti, il danno dell'ordine inverso è limitato. Per un processo distribuito su più reparti, sistemi e fogli di calcolo, quel danno cresce con ogni punto dato non chiarito prima che lo strumento lo richieda. Questa valutazione è approfondita nella pagina comprare prima uno strumento o impostare prima il processo: cosa costa questa differenza.
Prima che uno strumento possa ricevere dei requisiti, deve esistere una panoramica di quali punti dati sono necessari per il reporting, da dove proviene ciascun punto dato, chi è responsabile della correttezza e quale regola determina se un valore è plausibile. Questa panoramica non è un documento tecnico né uno strumento in sé; è un registro che costituisce la base per ogni passo successivo, sia che questo passo successivo sia uno strumento, un processo manuale, o una combinazione dei due.
La domanda su quali requisiti funzionali ne derivino è quindi in realtà la domanda: cosa contiene quel registro, e cosa manca ancora? Finché questa domanda non trova risposta, ogni requisito posto a uno strumento resta un'ipotesi. Questa relazione tra requisiti e processo sottostante è ulteriormente approfondita nella pagina su quali requisiti funzionali derivano dal proprio processo e cosa costa un ordine sbagliato.
Una volta che il registro dei punti dati e la titolarità sono a posto, la domanda si sposta da cosa deve saper fare uno strumento a cosa succede alle persone che oggi svolgono questo lavoro: raccogliere, controllare e ricopiare cifre da fogli di calcolo e sistemi. Parte di questi compiti è ripetitiva e segue regole fisse, ed è esattamente il tipo di lavoro di cui una parte può essere trasferita all'IA. La [scansione del lavoro di FTE TO AI](https://ftetoai.nl) calcola per ciascun compito quale parte può essere automatizzata, in modo da chiarire dove le persone restano necessarie e dove il lavoro può essere affidato a un sistema che controlla e fornisce secondo regole fisse.
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.