A monitorozás és jelzés dashboardnak hangzik. Rendszerint valami másról van szó: egy rendszerről, amely folyamatosan adatokat kap, azokat egy elvárással vagy küszöbértékkel veti össze, és jelez, amint valami eltér. Ez lehet egy gép, amely másképp vibrál, mint normál esetben, egy készlet, amely gyorsabban csökken, mint tervezték, egy hálózat, amelyen keresztül szokatlan forgalom megy, vagy egy ügyfélfolyamat, amelynél a átfutási idő megnő. Az AI-komponens a mintázatok felismerésében rejlik, amelyek fix szabályokkal nem foghatók meg — nem az emberrel helyettesítésében, aki a jelzésre reagál.
Egy monitorozó rendszer három dolgot ad: egy folyamatos mérést, egy normát, amellyel ezt a mérést összevetik, és egy jelzést, amikor az eltérés egy bizonyos határt meghalad. Ami ezután történik, a kialakítástól függ. A legegyszerűbb formában egy értesítés megy egy emberhez, aki megítéli és intézkedik. Egy továbbmenő formában a jelzés automatikusan elindít egy következő lépést — egy értesítést egy beszállítónak, egy módosítást egy tervezésben, egy tranzakció blokkolását. Ez a második forma érinti az egymást követő lépésekből álló láncok területét: a monitorozás akkor egy olyan folyamat kiindulópontjává válik, amely beavatkozás nélkül fut tovább, és ez másfajta bizalmat igényel, mint egy értesítés, amelyet valaki még el tud kattintani.
A két forma közötti különbség nem elhanyagolható. Egy jelzés, amely egy emberhez megy, lehet hibás anélkül, hogy azonnal kárt tenne — az ember szűr. Egy jelzésnek, amely egy műveletet indít, helyesnek kell lennie, vagy a szervezetnek kell egy módja legyen a művelet visszafordítására. Sok szervezet ezért az első formával kezdi, és csak akkor lép a második felé, ha a jelzés bebizonyította magát.
A monitorozás és jelzés mindenekelőtt folyamatos, megbízható adatokat igényel. Egy rendszer, amely hetente kap egy exportot egy másik rendszerből, nem tud jelzést adni — csak utólag tud jelentést készíteni. Kell egy folyamatos áramlásnak lennie: szenzoroknak, logoknak, tranzakcióknak, eseményeknek, amelyek folyamatosan érkeznek, és amelyeknek a minősége nem változik attól, ki végzi a bevitelt.
Ezenkívül egy norma szükséges. Egy eltérés csak valamihez viszonyítva eltérés. Gépeknél ez gyakran egy technikai specifikáció; folyamatoknál gyakrabban egy historikus átlag vagy egy célérték, amelyet valaki meghatározott. Ahol ez a norma hiányzik vagy instabil — egy folyamat, amely folyton változik, egy piac, amely ingadozik — a rendszer vagy túl sok jelzést ad, vagy túl keveset. Mindkettő aláássa a benne való bizalmat.
Harmadrészt egy rögzített útvonalat igényel arra, hogy mi történjen a jelzéssel. Ki kapja az értesítést, milyen időn belül ítélik meg, mi az eszkaláció, ha nincs reakció. Ez az útvonal nélkül egy jelzés egy postafiókban végzi, amelyet senki nem olvas, és a rendszer elveszti a funkcióját. Ez ugyanazt a kérdést érinti, mint a rögzített és nyomon követett beszélgetéseknél: a rögzítés nyomon követés nélkül csak egy archívumot eredményez, nem javulást.
A leggyakoribb hiba egy monitorozó rendszer, amely túl sok jelzést ad. Ha minden kis eltérés egy értesítést eredményez, az emberek megtanulják figyelmen kívül hagyni azokat — ez az ellentétes hatás annak, amire a rendszer szolgál. A küszöbérték beállítása ezért egy folyamatos mérlegelés a túl sok zaj és a túl késői figyelmeztetés között, és ez a mérlegelés eltolódik, ahogy több adat érkezik.
Egy második hiba az, hogy a jelzés ugyan kimegy, de senki nem tulajdonosa a nyomon követésnek. Ez gyakran akkor történik, amikor a monitorozást IT-projektként alakítják ki anélkül, hogy az osztály, amelynek a jelzésekkel kell dolgoznia, bekapcsolódna. A technika működik, a szervezet nem.
Egy harmadik hiba akkor keletkezik, amikor a jelzés egy döntést igényel, amely valójában emberi munka — elfogadható-e ez az eltérés, kell-e hívni az ügyfelet, megéri-e ez a kockázat a leállítást. Ahol ez a mérlegelés súlyosabbá válik, mint amit egy fix szabály elbír, a monitorozás döntéstámogatás felé csúszik, és más követelmények érvényesek az alátámasztásra és a magyarázhatóságra, mint egy egyszerű küszöbjelzésnél.
A legtöbb monitorozási projekt, amely nem indul be, az adatáramláson akad el, nem a modellen. Szenzorok, amelyek kiesnek, logok, amelyek inkonzisztensek, rendszerek, amelyek nem beszélnek egymással — ezek nem AI-problémák, ezek infrastruktúra-problémák, amelyeket előbb meg kell oldani. A koordináció is szerepet játszik: egy jelzés, amely az egyik osztályon keletkezik, gyakran egy másik osztályon kell landolnia, hogy jelentsen valamit, és ez érinti azt a kérdést, hogy hogyan van kialakítva az osztályok közötti koordináció.
Ez az oldal leírja, mit hozhat a monitorozás és jelzés, és mit kell rendbe tennie a szervezetnek, mielőtt ez működik. Egy másik kérdés, hogy a jelzések körüli munka mekkora része — az elbírálás, a nyomon követés, az eszkaláció — valóban átvehető AI által. Ez egy feladatszintű kérdés, és erre a FTE TO AI munkaszkennere ad választ: az feladatonként számolja ki, a munka mekkora része vehető át, nem egy teljes folyamat vagy egy teljes funkció szintjén.
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.