Kako validirati plan sistema preduzeća?

Novi sistemski plan često izgleda uverljivo kada je dijagram toka uredan, lista integracija deluje kompletno, i svako odeljenje je odobrilo svoj ekran. Problemi se obično javljaju kasnije: kada skladište mora da se nosi sa delimičnom isporukom, klijent izmeni svoju porudžbinu, pogrešan broj artikla stigne iz webshopa, ili fakturisanju trebaju drugačiji podaci od onih koje čuva komercijalni sistem. Stoga, pitanje nije samo kako validirati plan preduzeća, već i da li plan zaista može da izdrži realnost svakodnevnog poslovanja.

Validacija sistemskog plana nije formalni krug potpisivanja. To je proces provere tokom kojeg tražimo dokaze da planirano poslovanje podržava poslovne ciljeve, upravlja izuzecima i ne stvara nove manuelne zaobilaznice. U rastućoj kompaniji ovo je posebno važno: loše validiran sistem može ugraditi godine administracije, nesigurne izveštaje i zavisnost od ključnih osoba u poslovanje.

Sistemski plan nije isto što i plan ekrana

Mnogi projekti prerano postaju tehnološke rasprave. Da li treba ERP, poseban proizvodni modul, nova veza za webshop, prilagođena aplikacija ili automatizovana obrada dokumenata? Sve ovo ima smisla tek kada se razjasni kako posao prolazi kroz kompaniju.

Uzmimo jednostavan komercijalni proces. Webshop prosleđuje porudžbinu, kolega proverava zalihe, skladište priprema, fakturista izdaje račun, prevoznik dobija podatke, a finansije prate izvršenje. Ako svi sistemi „rade“, ali kolega svakodnevno kopira podatke između njih, kompanija koristi ljudsku integraciju umesto funkcionalnog sistema.

Prvo pitanje validacije nije da li se plan može napraviti. Već, koji poslovni proces menja, čiji rad pogađa i na kojim informacijama se zasniva. Tehnički elegantno rešenje može biti pogrešno ako digitalizuje korak odobravanja koji zapravo nije potreban, ili ako iz procesa izostavi odluku koja se danas donosi na osnovu iskustva.

Počnimo sa stvarnim poslovanjem, a ne sa željenim stanjem

Sistemski planovi često prikazuju idealan proces. Porudžbina je kompletna, osnovni podaci o artiklima su čisti, sva prava su ažurirana, podaci o partnerima su ujednačeni. U stvarnosti, međutim, isti kupac može biti naveden pod više imena, proizvod stiže pod zamenskim brojem artikla, ili proizvodnja tek kasnije obaveštava da se dogovoreni rok ne može ispoštovati.

Dobra validacija stoga počinje posmatranjem trenutnog procesa. Nije dovoljno pitati menadžera kako bi porudžbina trebala da funkcioniše. Treba pratiti nekoliko stvarnih porudžbina, proizvodnih naloga, reklamacija ili nabavki od početka do kraja. Postaju vidljivi mali koraci koji obično nedostaju u dokumentaciji: telefonski pozivi, Excel liste, e-mail dogovori, sopstvene beleške i pravila tipa „svi znaju da se ovo radi ovako“.

Ovo nisu nužno greške. Neke manuelne odluke su poslovno opravdane, na primer, kod jedinstvenog određivanja cena ili kontrole kvaliteta. Zadatak validacije je da razlikuje ljudsku procenu koja stvara vrednost od mehaničkog prenosa podataka i ponavljajućih provera.

Izuzeci pokazuju kvalitet plana

Sistemski plan preduzeća gotovo uvek izgleda dobro za normalne slučajeve. Rizik predstavljaju izuzeci. Šta se dešava ako nema zaliha? Ko dobija obaveštenje ako integracija nije prosledila porudžbinu? Koji sistem je vlasnik podataka ako se adresa isporuke razlikuje na dva mesta? Ko i pod kojim uslovima može da poništi automatsku odluku?

Izuzetke nije moguće potpuno eliminisati. Cilj je da budu vidljivi, upravljivi i da se mogu pratiti. Ako se greška otkrije tek kada se klijent žali, sistemski plan nema odgovarajuću operativnu kontrolu. Ako za svako odstupanje treba pozvati istog iskusnog kolegu, kompanija ostaje zavisna od pojedinaca.

Kako validirati sistemski plan preduzeća poslovnim scenarijima?

Najkorisnija metoda je korišćenje poslovnih scenarija od početka do kraja. To nisu opšti test slučajevi, već konkretne situacije preuzete iz poslovanja kompanije. Scenarij treba da pokaže odakle informacija potiče, ko je može izmeniti, kroz koje sisteme prolazi, koje se odluke donose i šta se smatra uspešnim završetkom.

U e-trgovinskoj kompaniji, scenarij može biti porudžbina gde je jedan artikl odmah dostupan, a drugi može biti isporučen kasnije. Tokom validacije, ne treba samo proveriti da li je porudžbina kreirana u ERP-u. Treba videti i kakve informacije dobija klijent, da li skladište ima tačan zadatak, da li fakturisanje odgovara pravilima kompanije, da li se rezervacija zaliha ispravno menja i da li menadžerski izveštaj pravi razliku između izvršenih i čekajućih porudžbina.

U proizvodnoj kompaniji, scenarij može početi sa nedostatkom sirovina ili izmenjenom tehničkom specifikacijom. Ovde je pitanje da li promena stiže do planiranja, nabavke, radionice i računanja troškova bez stvaranja više različitih Excel verzija.

Scenarije treba proći sa vlasnicima procesa. Ne isključivo sa IT-jem i ne samo sa vođom projekta. Rukovodilac skladišta, finansijski kolega, korisnička podrška ili proizvodni menadžer poznaju detalje bez kojih plan može biti ispravan na papiru, ali nedostatan u praksi.

Ispitajmo podatke, odgovornost i prenose

Značajan deo sistemskih grešaka zapravo su greške u podacima i odgovornosti. Dva sistema čuvaju iste podatke o klijentima, ali nema jasnog pravila koji je izvor verodostojan. Status porudžbine se menja, ali promena ne stiže do fakturisanja. Radni tok se automatski pokreće, ali nema određene osobe koja upravlja izuzetkom.

Tokom validacije, za svaki važan podatak treba razjasniti tri stvari: gde nastaje, ko je odgovoran za njegov kvalitet i gde se koristi. Ovo je posebno kritično za osnovne podatke o artiklima, cene, zalihe, podatke o klijentima, proizvodne parametre i finansijske statuse.

Jednako su važni i sistemski okviri. Svaki prenos nosi rizik, bilo da se odvija putem API-ja, uvoza datoteka, e-maila ili ručnog unosa. Nije svaki odnos potrebno automatizovati u realnom vremenu. Dnevna sinhronizacija može biti dovoljna ako poslovne odluke to dozvoljavaju. Izbor zavisi od toga koliko je kašnjenje prihvatljivo, koliki je trošak greške i da li je potrebna trenutna intervencija.

Ne-funkcionalni zahtevi su takođe poslovna pitanja

Validacija sistemskog plana ne sme stati na funkcijama. Možda sistem ispravno obrađuje porudžbine, ali se usporava tokom kraja meseca. Ili se može povratiti nakon kvara servera, ali obnova traje osam sati, dok skladište ne može da podnese ni dva sata zastoja.

Dostupnost, bekap, upravljanje pravima, logovanje, performanse i model podrške su deo poslovanja. Njih treba formulisati sa poslovnim posledicama, a ne kao opšte tehničke zahteve. Koliko gubitka podataka je prihvatljivo? Ko može nastaviti sa radom ako centralni sistem padne? Koliko brzo fakturisanje, prikupljanje proizvodnih podataka ili obrada porudžbina u webshopu mora biti obnovljeno?

Odgovori pomažu u izboru proporcionalne arhitekture. Ne zahteva svaki proces isti nivo visoke dostupnosti, ali na kritičnim tačkama poslovanja, nesigurnost može biti skupa.

Rezultat validacije treba da bude osnova za donošenje odluka

Na kraju dobre validacije ne stoji nejasna oznaka „prošao“. Uprava treba da razume pod kojim uslovima plan funkcioniše, koji rizici ostaju, koje promene u procesu su potrebne pre implementacije i koje odluke još treba doneti.

Vredi posebno tretirati greške koje treba ispraviti, svesno prihvaćena ograničenja i kasnije mogućnosti razvoja. Ne opravdava svaka manjkavost zaustavljanje projekta. Retki izuzetak može se rešiti privremenim pravilom ako je poznat odgovorni i merljiv je njegov uticaj. Međutim, nije preporučljivo pokrenuti proces gde nije jasno ko je vlasnik podataka, gde ne funkcioniše detekcija grešaka ili gde svakodnevno poslovanje zavisi od prećutnog znanja jedne osobe.

Sistemski plan se smatra zrelim kada možemo reći ne samo kako funkcioniše u idealnom slučaju, već i ko šta radi u slučaju odstupanja. Ova vrsta discipline ne usporava razvoj. Smanjuje kasnije prepravke, hitne manuelne ispravke i nesigurno poslovanje, dok rast kompanije postaje manje administrativno opterećenje.