Povrat poslovnog procesa nakon izmjene pokrenite prema unaprijed odobrenom okidaču, uz jasno imenovanog vlasnika odluke i plan za svaki zapis nastao nakon promjene. Vraćanje aplikacije ili konfiguracije na prethodnu verziju može zaustaviti tehnički problem, ali samo po sebi ne usklađuje narudžbe, knjiženja, zalihe, obračune i integracijske poruke nastale u međuvremenu.
Nova verzija procesa može obuhvatiti ERP konfiguraciju, pravila odobravanja, integraciju, obrazac za unos, automatizaciju ili AI potporu u radu tima. Kada takva promjena zakaže, pritisak za brzo vraćanje prethodnog stanja razumljiv je. Ipak, odluka o povratku verzije ima dvije odvojene dimenzije:
Tehnički povrat može ponovno otvoriti staru putanju rada. Ne može automatski utvrditi je li narudžba zaprimljena dvaput, je li zaliha rezervirana prema pogrešnom pravilu, je li račun proknjižen ili je li poruka prema vanjskom sustavu već isporučena.
Zato odluku o povratku verzije ne treba prepustiti samo osobi koja izvodi promjenu. Ona je poslovna odluka s tehničkom izvedbom, jasnim vlasnikom i zapisom razloga.
Okidač povratka treba biti konkretan, opažljiv i vezan uz poslovni rizik. Općenita formulacija poput "ako nešto ne radi" ostavlja previše prostora za različita tumačenja tijekom incidenta.
Primjeri provjerljivih okidača uključuju:
Svaki okidač treba navesti četiri elementa: što se prati, tko potvrđuje stanje, kada nastupa odluka i koji je dopušten privremeni postupak prije povratka. Ako je za procjenu potreban podatak iz više sustava, navedite izvor i vlasnika svakog ulaza.
U incidentu nije dovoljno znati tko ima pristup produkciji. Potrebno je razlikovati vlasnika poslovne odluke od izvršitelja tehničkog povrata.
Praktična podjela odgovornosti može izgledati ovako:
U ORKA pristupu Orkasta vodi svakodnevnu suradnju i službene ERP transakcije, a Trueforce preuzima specijaliziranu inženjersku izvedbu kada opseg promjene to traži. Takva podjela ne uklanja potrebu za vlasnikom procesa kod naručitelja: samo on može procijeniti poslovnu prihvatljivost posljedica.
Najteži dio plana obično nije vraćanje verzije nego razdoblje između objave promjene i stabilizacije prethodnog procesa. Za to razdoblje napravite popis svih vrsta zapisa koje promjena može stvoriti ili izmijeniti.
Za svaki zapis odredite:
Korektivna radnja nije uvijek brisanje. U mnogim poslovnim sustavima primjereniji je storno, korektivni dokument, ponovna obrada, ručna provjera ili zadržavanje zapisa uz jasno označen status. Izbor ovisi o pravilima procesa i stvarnom stanju zapisa. Plan treba opisati postupak, ne pretpostaviti ishod.
Pretpostavimo da izmjena pravila odobravanja narudžbe pogrešno propušta dio narudžbi u otpremu. Tehnički tim vraća prethodno pravilo. Narudžbe koje su u međuvremenu dobile status otpreme ne vraćaju se same u raniji poslovni status. Vlasnik procesa najprije treba dobiti popis tih narudžbi, provjeriti jesu li nastali povezani dokumenti ili poruke i odrediti korektivnu radnju po statusu.
Ovaj scenarij ne opisuje stvarni ORKA projekt. Njegova je svrha pokazati razliku između povrata pravila i usklađenja poslovnih događaja.
Dobra odluka o povratku verzije ima kratak, ali potpun zapis. Zabilježite:
Ne čekajte potpunu analizu svih uzroka ako je potreban brz prekid štetnog toka. Ipak, nemojte zatvoriti incident nakon uspješnog tehničkog povrata. Zatvaranje slijedi tek nakon provjere poslovnih zapisa i dogovorenih kontrola.
DORA istraživanje o AI potpomognutom razvoju softvera promatra AI u kontekstu organizacije i isporuke. Taj kontekst je koristan za pitanja o načinu rada timova i promjenama u isporuci, ali njegovi nalazi nisu obećanje učinka za pojedinog ORKA klijenta. Kod AI potpore posebno je važno odrediti osobu koja potvrđuje poslovnu odluku i vodi postupanje s iznimkama.
Brz povrat smanjuje vrijeme rada u neispravnom toku, ali može povećati broj zapisa za naknadnu obradu. Dulje promatranje nove verzije može dati više dokaza o uzroku, ali izlaže proces daljnjem riziku. Ne postoji univerzalni prag: vlasnik procesa treba usporediti poslovni učinak, mogućnost kontrole podataka, dostupnost ručnog postupka i opseg povezanih sustava.
Plan također mora navesti situacije u kojima tehnički povrat nije primjeren. To može uključiti nepovratnu promjenu strukture podataka, već poslane vanjske poruke, dovršenu fizičku otpremu ili zapis koji zahtijeva korektivni postupak umjesto izmjene izvornika. Takve iznimke traže unaprijed određenu eskalaciju, a ne improvizaciju tijekom incidenta.
Prije objave promjene pripremite ovaj popis:
Ako plan još nema vlasnike ulaza i iznimki, prvi korak nije tehnička skripta nego kratki pregled toka rada. Screening poslovnog procesa može pomoći strukturirati granice procesa, službene ERP transakcije i točke na kojima je potreban povrat ili korektivna radnja.