Promatranje sustava postaje poslovni alat kada svaki važan signal vodi do vlasnika procesa, odluke i praga reakcije. Sama količina tragova, metrika i zapisa ne rješava zastali tok između aplikacija. Vrijednost nastaje tek uz mogućnost rekonstruirati tijek, utvrditi poslovni učinak i pokrenuti odgovarajuću radnju.
Tragovi, metrike i zapisi služe razumijevanju ponašanja sustava. Oni mogu pokazati redoslijed poziva, trajanje obrade, pogrešku pri prijenosu ili rast broja poruka na čekanju. Međutim, tehnički signal sam po sebi često ne odgovara na pitanje koje je važno vlasniku procesa: je li narudžba zapela, koje dokumente zastoj obuhvaća, tko treba reagirati i kada zastoj postaje poslovni problem.
Zato poslovna upotreba observability podataka počinje izvan nadzorne ploče. Počinje definiranjem procesa, njegove službene transakcije i odgovorne osobe. Tek tada zapis o pogrešci može dobiti značenje, primjerice kao neuspjelo knjiženje, nepredana narudžba ili dokument koji nije stigao u sljedeću aplikaciju.
OpenTelemetry razlikuje tragove, metrike i zapise kao komplementarne izvore za razumijevanje ponašanja sustava. Njihova korisnost raste kada se mogu povezati u istom istraživanju, a ne promatrati kao odvojeni tehnički ekrani. OpenTelemetryjev uvod u observability daje osnovni okvir za tu podjelu.
Zastoj u integriranom procesu rijetko je vidljiv u samo jednoj aplikaciji. ERP može imati službenu transakciju dokumenta, integracijski sloj može zabilježiti poruku, a odredišna aplikacija može vratiti odgovor ili ne vratiti ništa. Bez zajedničkog ključa i vremenskog slijeda timovi dobivaju nepovezane dijelove priče.
Za rekonstrukciju toka korisno je povezati najmanje četiri elementa:
Povezivanje tehničkog i poslovnog signala nije poziv na upisivanje svih poslovnih podataka u svaki zapis. Potrebno je odabrati identifikatore i atribute koji su nužni za istragu, uz pravila pristupa i zadržavanja podataka koja organizacija već primjenjuje. Ako tehnički zapis ne smije sadržavati određeni podatak, veza može voditi preko kontroliranog identifikatora i službenog izvora u ERP-u.
Važna je i razlika između izvora istine i pomoćnog dokaza. ERP službena transakcija može potvrditi poslovni status dokumenta. Trag integracije može objasniti put do tog statusa ili mjesto prekida. Nadzorni prikaz pomaže uočiti obrazac, ali ne bi trebao samostalno preuzeti ulogu službenog poslovnog zapisa bez izričite odluke o tome.
Broj prikupljenih zapisa može govoriti o pokrivenosti, ali ne dokazuje sposobnost donošenja odluke. Sustav može stvarati velik volumen podataka, a procesni vlasnik i dalje može ostati bez odgovora na osnovna pitanja.
Korisnije je provjeriti sljedeće:
Ova pitanja premještaju fokus s telemetrije kao zbirke podataka na telemetriju kao podlogu za rad. Mjera prihvata zato ne mora biti unaprijed zadani broj. Može biti provjerljiv scenarij: za odabrani predmet tim može povezati korake kroz aplikacije, odrediti vlasnika iznimke, evidentirati odluku i potvrditi završni status u službenom sustavu.
Zamislimo proces u kojem ERP šalje dokument drugoj aplikaciji. Dokument je u ERP-u nastao, integracijski sloj prihvatio je poruku, ali odredišna aplikacija ne potvrđuje obradu u očekivanom poslovnom roku. Ovo je hipotetski scenarij, a ne opis rada konkretnog klijenta ili proizvoda.
Operativni tim može vidjeti tehničku poruku na čekanju. Vlasnik procesa, s druge strane, treba znati obuhvaća li zastoj predmet koji blokira daljnju obradu, može li se čekati sljedeći automatizirani pokušaj ili je potrebna ručna provjera.
Radni slijed može izgledati ovako:
Ovaj pristup ne uklanja sve neizvjesnosti. Vanjski sustav može kasniti, identifikatori mogu nedostajati, a poslovna pravila mogu biti nedovoljno precizna. Prednost je jasniji način rada u trenutku kad se problem pojavi.
Vlasnik signala nije nužno osoba koja održava integraciju. Vlasnik procesa određuje kada signal prelazi iz tehničkog događaja u poslovnu iznimku. Tehnička uloga može istražiti uzrok prijenosa, obnoviti vezu ili prilagoditi obradu. Računovodstvo, proizvodnja, prodaja ili druga procesna funkcija procjenjuje poslovnu posljedicu i potvrđuje prihvatljiv nastavak rada.
Praktično razdvajanje odgovornosti može uključiti:
Jedna osoba može imati više uloga u manjoj organizaciji. Bitno je imenovati odgovornost, a ne pretpostaviti je.
Šire prikupljanje podataka ne donosi automatski bolju odluku. Previše atributa može otežati istragu, povećati trošak obrade i otvoriti pitanja pristupa podacima. Premalo konteksta ostavlja tim bez veze između pogreške i poslovnog predmeta.
Povezivanje zahtijeva disciplinu u identifikatorima. Ako svaka aplikacija koristi drugačiji ključ bez mape odnosa, istraživanje će ostati ručno i nepouzdano. Također, automatizirano ponovno slanje nije uvijek ispravan odgovor. Neki procesi traže provjeru duplikata, provjeru stanja dokumenta ili odobrenje vlasnika procesa prije ponavljanja radnje.
Zato prvo treba odabrati nekoliko tokova s jasnim poslovnim učinkom, a zatim provjeriti funkcionira li odgovornost kroz stvarne ili kontrolirane scenarije. Screening poslovnog procesa može pomoći strukturirati taj početni pregled oko toka, službenih transakcija, ulaza i iznimaka.
Prije uvođenja ili proširenja promatranja sustava, prođite ovaj popis za svaki odabrani tok:
Kada su ti elementi imenovani, promatranje sustava prestaje biti samo tehnička vidljivost. Postaje radni alat za upravljanje procesom, s jasnim signalom, vlasnikom i provjerom ishoda. Za povezivanje tog rada sa svakodnevnim načinom suradnje i službenim ERP transakcijama, pregledajte ORKA operativni sustav .