Un furnizor întreabă mai devreme sau mai târziu: ce trebuie să poată sistemul? Răspunsul nu se află la furnizor și nici într-o listă de funcționalități pe care alte companii le-au bifat deja. Răspunsul se află în propriul dumneavoastră proces: ce puncte de date colectați, cine le furnizează, de unde provin și ce se întâmplă când nimeni nu verifică.
Ruta obișnuită este: se selectează un instrument, se configurează instrumentul, și abia apoi se descoperă ce date trebuie să vină de unde. Această ordine funcționează invers, pentru că un instrument nu are o părere despre procesul dumneavoastră. El cere date de intrare, iar acele date trebuie să provină din ceva. Dacă acel ceva — registrul punctelor de date, proprietatea asupra lor, sursele — nu există încă, configurarea instrumentului devine o căutare pe care nimeni nu a planificat-o.
Cealaltă ordine începe de la proces. Se cartografiază mai întâi ce puncte de date sunt necesare, cine le furnizează, din ce sistem sau foaie de calcul provin și ce reguli de calitate le sunt asociate. Doar după aceea devine clar ce cerințe trebuie să îndeplinească de fapt un instrument. Nu cerințe abstracte precum „prietenos cu utilizatorul” sau „scalabil”, ci cerințe concrete precum: trebuie să se conecteze la acest sistem sursă specific, trebuie să poată distinge trei proprietari în cadrul unui singur punct de date, trebuie să semnaleze o abatere atunci când o cifră se situează în afara unei marje determinate anterior.
Ordinea nu este o preferință de metodă; ea rezultă din ceea ce precede logic, din punct de vedere funcțional, instrumentul. Un instrument poate primi cerințe abia atunci când există ceva din care să deriveze acele cerințe. Acel ceva este procesul: fluxul de date de la sursă la raport, cu toți pașii manuali, transferurile și presupunerile care le sunt asociate. Fără această imagine de ansamblu, o organizație stabilește cerințe pe baza a ceea ce poate face un instrument, nu pe baza a ceea ce are nevoie procesul. Aceasta poate suna ca o diferență subtilă, dar ea determină dacă instrumentul se va alinia la realitate sau va ajunge să stea alături de realitate.
Aceasta se leagă de întrebarea cum alegeți un instrument fără să regretați ulterior: regretul apare adesea nu din cauza unui instrument slab, ci din cauza unui instrument care a trebuit să ghicească cerințele pentru că nimeni nu le-a notat.
Dacă instrumentul vine primul și procesul mai târziu, apar două tipuri de costuri. Primul este reconfigurarea directă: funcționalitate care nu se aliniază, conexiuni care trebuie totuși construite, câmpuri care rămân goale pentru că nimeni nu știe cine trebuie să le completeze. Al doilea cost este mai puțin vizibil, dar mai grav: instrumentul va genera rapoarte care par mai ordonate, în timp ce cifrele din spatele lor tot nu pot fi trasate până la o sursă sau un proprietar. Acest risc este descris mai detaliat pe pagina despre cât costă să plasați un instrument peste un proces neorganizat: instrumentul ascunde problema în loc să o rezolve.
Întrebarea care ordine se dovedește mai ieftină depinde de câte puncte de date, sisteme și proprietari există deja și câte dintre acestea nu sunt încă documentate. La un proces mic, cu puține surse, daunele ordinei inverse sunt limitate. La un proces răspândit pe mai multe departamente, sisteme și foi de calcul, aceste daune cresc cu fiecare punct de date care nu a fost clarificat înainte ca instrumentul să îl solicite. Această analiză este dezvoltată pe pagina a cumpăra întâi un instrument sau a organiza întâi procesul: ce cost implică această diferență.
Înainte ca un instrument să poată primi cerințe, trebuie să existe o imagine de ansamblu asupra căror puncte de date sunt necesare pentru raportare, de unde provine fiecare punct de date, cine este responsabil pentru corectitudinea lui și ce regulă determină dacă o valoare este plauzibilă. Acea imagine de ansamblu nu este un document tehnic și nici un instrument în sine; este un registru care formează baza pentru fiecare pas următor, fie că acel pas următor este un instrument, un proces manual, sau o combinație a celor două.
Întrebarea ce cerințe funcționale rezultă din acesta este, deci, de fapt întrebarea: ce se află în acel registru și ce mai lipsește? Cât timp această întrebare rămâne fără răspuns, orice cerință pentru un instrument rămâne o presupunere. Această legătură între cerințe și procesul care le stă la bază este dezvoltată mai departe pe pagina despre ce cerințe funcționale rezultă din propriul dumneavoastră proces și ce costă o ordine greșită în acest sens.
Odată ce registrul punctelor de date și proprietatea asupra lor sunt puse la punct, întrebarea se deplasează de la ce trebuie să poată face un instrument spre ce se întâmplă cu persoanele care fac în prezent această muncă: colectarea, verificarea și transcrierea cifrelor din foi de calcul și sisteme. O parte din aceste sarcini este repetitivă și urmează reguli fixe, și acesta este exact tipul de muncă din care o parte poate fi preluată de AI. [Scanul de muncă al FTE TO AI](https://ftetoai.nl) calculează, pentru fiecare sarcină, ce parte din ea poate fi automatizată, astfel încât să devină clar unde oamenii rămân necesari și unde munca poate fi transferată către un sistem care verifică și furnizează date conform unor reguli fixe.
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.