Monitorizarea și semnalizarea sună ca un dashboard. De obicei este altceva: un sistem care primește continuu date, le compară cu o așteptare sau o valoare-prag, și emite un semnal de îndată ce ceva se abate. Poate fi o mașină care vibrează diferit față de normal, un stoc care se epuizează mai rapid decât planificat, o rețea prin care trece trafic neobișnuit, sau un proces de client la care timpul de procesare crește. Componenta AI se află în recunoașterea unor tipare pe care regulile fixe nu le pot prinde — nu în înlocuirea omului care reacționează la semnal.
Un sistem de monitorizare oferă trei lucruri: o măsurare continuă, o normă cu care această măsurare este comparată, și un semnal atunci când abaterea trece de o anumită limită. Ce se întâmplă după aceea depinde de modul de organizare. În forma cea mai simplă, o notificare ajunge la un om, care evaluează și acționează. Într-o formă mai avansată, semnalul declanșează automat un pas următor — o notificare către un furnizor, o ajustare într-o planificare, o blocare a unei tranzacții. Această a doua formă atinge domeniul lanțurilor în care pașii se succed unul pe altul: monitorizarea devine astfel punctul de start al unui proces care continuă fără intervenție, ceea ce necesită un tip diferit de încredere față de o notificare pe care cineva o mai poate ignora.
Diferența dintre aceste două forme nu este trivială. Un semnal care ajunge la un om poate fi greșit fără să provoace imediat daune — omul filtrează. Un semnal care declanșează o acțiune trebuie să fie corect, altfel organizația trebuie să aibă o modalitate de a anula acțiunea. Multe organizații începe astfel cu prima formă și se îndreaptă spre a doua abia după ce semnalul și-a dovedit valoarea.
Monitorizarea și semnalizarea cer, în primul rând, date continue și fiabile. Un sistem care primește săptămânal un export dintr-un alt sistem nu poate emite un semnal — poate doar raporta retroactiv. Trebuie să existe un flux: senzori, jurnale, tranzacții, evenimente, care sosesc continuu și a cărui calitate nu variază în funcție de cine face introducerea datelor.
În plus, este necesară o normă. O abatere este o abatere doar în raport cu ceva. La mașini, aceasta este de obicei o specificație tehnică; la procese, este mai frecvent o medie istorică sau o valoare-țintă stabilită de cineva. Unde această normă lipsește sau este instabilă — un proces care se schimbă constant, o piață care fluctuează — sistemul emite fie prea multe semnale, fie prea puține. Ambele situații subminează încrederea în el.
În al treilea rând, este necesară o rută stabilită pentru ce se întâmplă cu un semnal. Cine primește notificarea, în cât timp este evaluată, care este escaladarea dacă nu se reacționează. Fără această rută, un semnal ajunge într-o cutie poștală pe care nimeni nu o citește, și sistemul își pierde funcția. Acest lucru atinge aceeași întrebare ca la conversațiile care sunt înregistrate și urmărite: înregistrarea fără urmărire oferă doar o arhivă, nu o îmbunătățire.
Cea mai frecventă problemă este un sistem de monitorizare care emite prea multe semnale. Dacă fiecare abatere mică generează o notificare, oamenii învață să le ignore — efectul opus celui pentru care sistemul a fost conceput. Setarea valorii-prag este astfel o evaluare continuă între prea mult zgomot și avertizare prea târzie, iar acest echilibru se schimbă pe măsură ce intră mai multe date.
O a doua problemă este că semnalul se declanșează, dar nimeni nu este responsabil de urmărire. Acest lucru se întâmplă frecvent atunci când monitorizarea este organizată ca proiect IT fără implicarea departamentului care trebuie să lucreze cu semnalele. Tehnica funcționează, organizația nu.
O a treia problemă apare atunci când semnalul cere o decizie care este de fapt muncă umană — este această abatere acceptabilă, trebuie sunat clientul, merită acest risc întreruperea. Unde această evaluare devine prea complexă pentru ca o regulă fixă să o poată gestiona, monitorizarea se deplasează către suportul decizional, și se aplică alte cerințe de fundamentare și explicabilitate decât la un simplu semnal-prag.
Majoritatea proiectelor de monitorizare care nu decolează se blochează pe fluxul de date, nu pe model. Senzori care se defectează, jurnale inconsistente, sisteme care nu comunică între ele — acestea nu sunt probleme de AI, ci probleme de infrastructură care trebuie rezolvate întâi. Coordonarea joacă și ea un rol: un semnal care apare într-un departament trebuie adesea să ajungă la un alt departament pentru a avea vreo semnificație, iar acest lucru atinge întrebarea cum este organizată coordonarea între departamente.
Această pagină descrie ce poate oferi monitorizarea și semnalizarea, și ce trebuie să aibă organizația la punct înainte ca aceasta să funcționeze. O altă întrebare este ce parte a muncii din jurul acestor semnale — evaluarea, urmărirea, escaladarea — poate fi efectiv preluată de AI. Aceasta este o întrebare la nivel de sarcină, și la ea răspunde scanul de muncă al FTE TO AI: acesta calculează per sarcină ce parte a muncii poate fi preluată, în loc de a face acest lucru la nivelul unui proces întreg sau al unei funcții întregi.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.