Uvođenje softvera u maloprodaji: šta me je naučilo jedno ERP uvođenje za dva meseca

Prvi poslovni sistem koji sam uveo napravio sam sa devetnaest godina, sam, za otprilike dva meseca. Kad se osvrnem na dvadeset godina uvođenja od tada, gotovo ništa od onoga što sam u ta dva meseca uradio kako treba nije imalo veze sa kodom.

Firma je distribuirala novine i časopise preko više od pedeset kioska širom jednog grada. Isporuke, zalihe, povraćaji, magacin, rukovanje gotovinom i obračuni sa dobavljačima, sve to sa proizvodom čiji je komercijalni vek surovo kratak. Novine gube vrednost brže od mleka, i svaki proces u tom poslu bio je oblikovan tom činjenicom.

Bio sam jedini programer. Jedan sistem administrator me je naučio da razložim problem i da držim kod u kakvom-takvom redu. Sve što je imalo veze sa uvođenjem (razgovor sa ljudima, menjanje načina na koji rade, to da se alat zaista prihvati) naučio sam tako što sam grešio pred svima.

Pedeset kioska, dva meseca i nikakva svest da je to nerazumno

Zadatak je bio da se postojeća softverska osnova proširi tako da pokrije operacije, zalihe i gotovinu u celoj firmi. Ono što me danas iznenađuje jeste kako je to vodio direktor. Od prvih razgovora pričao je sa devetnaestogodišnjakom o poslovnim procesima, o tome kako odeljenja jedno drugom predaju posao, gde se informacije zaglavljuju i šta je, po njemu, moglo bolje da se organizuje. Ne o specifikacijama. O poslu.

Deo razloga zašto je uspelo nije laskav: nisam znao dovoljno da bih znao da je zadatak nerazuman. Iskusan menadžer bi uradio procenu rizika, napisao plan, tražio tim i objasnio zašto su dva meseca skoro nemoguća. Često bi bio u pravu. Kada ne razumete veličinu problema, to ponekad daje energiju koju pravilno kalibrisana osoba nikada ne bi potrošila.

Kada ne znate koliko je zadatak nerazuman, to može biti pravi izvor energije. To nije plan, i ne preživljava susret sa drugom lokacijom.

Napisano noću, testirano ujutru

Metod, ako zaslužuje tu reč, bio je ovaj: noću napisati deo, ujutru ga staviti pred stvarne zaposlene koji rade stvaran posao, posmatrati ga tokom dana, pronaći zahtev koji sam propustio, ponoviti. Kada više nisam mogao, spavao sam u serverskoj sobi, gde je bilo osamnaest stepeni, što se u tim godinama preživi. Nisam to doživljavao kao pilot ni kao fazno uvođenje. Zvao sam to kodiranje noću, puštanje ujutru, popravljanje tokom dana.

Godinama kasnije pročitao sam rad Hekmana i Oldama iz 1976. o tome kako dizajn posla stvara motivaciju: autonomija, vidljivi rezultati, osećaj da posao ima smisla i trenutna povratna informacija. Sve četiri sam imao slučajno, jer nije bilo nikog drugog da ih ima. Razmak između odluke i njene posledice bio je nekoliko sati, a povratnu informaciju davali su ljudi koji su morali da žive sa onim što sam isporučio. Retko je bila diplomatska i nikada nije bila pogrešna.

To je najjači argument koji znam za to da ljudi koji uvode sistem budu blizu operacija. U većim firmama u kojima sam posle radio, odeljenja, primopredaje i nivoi odobravanja razvlačili su taj razmak na nedelje, a kvalitet povratne informacije opadao je celim putem.

Zašto herojstvo prestaje da radi na drugoj lokaciji

Sistem je pušten u rad i počeo je da vodi knjige za posao sa više od pedeset kioska i nekoliko stotina veleprodajnih kupaca. Dobio sam bonus od 300 dolara i potrošio ga na bicikl, što je sa devetnaest godina bila odbranjiva alokacija kapitala. Rad se nastavio i posle puštanja u rad: logika popune zaliha, generisanje porudžbina dobavljačima, preporuke za otpis povraćaja i na kraju magacinski modul koji je ljudima govorio kuda da idu. Pridružio se drugi programer i postao sam mentor bez ikakve ideje kako se to radi.

Što me dovodi do ispravke koju bih dao sebi sa devetnaest godina. Lična odgovornost odnese prvi projekat iznenađujuće daleko, a onda stane. Nijedna organizacija ne bi smela da zavisi od toga da li je jedna osoba spremna da se odrekne sna. To mora da se pretvori u procese, dokumentaciju, znanje koje ima više od jedne osobe i sisteme koji nastavljaju da rade bez spasavanja. Srodna tema, konkretno o sloju izveštavanja koji ne može jednom da se specifikuje i ostavi godinama, obrađena je u tekstu zašto vaše izveštavanje ne može biti jednokratan projekat.

Pitanja koja vam govore da je uvođenje uspelo

Iskušenje je da se uvođenje oceni po tome da li je isporučeno po planu i da li je inženjerski čisto. Arhitektura jeste važna, i loša arhitektura na kraju postane poslovni problem, samo na sporijem satu. Ali tehnički tim ne može sebe da ocenjuje samo po tome koliko je dobro organizovan njegov sopstveni proces. Ovo su pitanja koja umesto toga postavljam, mesec ili dva posle puštanja u rad:

• Da li je broj grešaka zaista pao, i vidi li se to u podacima, a ne u utiscima?
• Da li ljudi isti posao završavaju brže, ili je posao samo prešao na nekog drugog?
• Da li menadžment iste informacije dobija ranije, ili samo u lepšem formatu?
• Da li su zalihe razumljivije nego ranije, po lokaciji, kategoriji i periodu?
• Koji su ručni koraci potpuno nestali, a koji su samo promenili ruke?
• Da li se neka poslovna odluka promenila zbog sistema, i možete li da navedete tu odluku?

Ako ni na jedno od tih pitanja nema odgovora, sistem je pušten u rad. To nije isto što i uveden, i u razmaku između ta dva gubi se najveći deo novca u ovakvim projektima.

Softver postaje deo poslovanja, a ne alat pored njega

Rad Erika Trista o sociotehničkim sistemima, stariji od većine softvera o kome raspravljamo, to kaže bolje nego što ja mogu. Novi sistem ne zamenjuje samo alat. Menja odnose, ko o čemu odlučuje, kako je raspoređena odgovornost, koliko ljudi veruju onome što gledaju i oko čega na kraju raspravljaju.

Ako ljudi ne veruju osnovnim podacima, ne mogu da prate zašto sistem nešto preporučuje ili deo svakog dana provode ispravljajući ga, šteta je izašla iz softvera i ušla u radne odnose oko njega. Dolazak veštačke inteligencije učinio je taj argument oštrijim, a ne blažim. Preporuka koju niko ne može da proveri problem je poverenja pre nego što je problem korisničkog iskustva.

Šta smo poneli u marql

marql je sloj iznad POS, računovodstvenih i e-commerce sistema koje maloprodajni lanac, grupa restorana ili franšizna mreža već koristi: čita ih bez zamene, a hostovan je u EU. To što ne zamenjuje POS ni ERP namerna je odluka o tome koliki deo poslovanja jedno uvođenje sme da poremeti odjednom.

Obaveza koju preuzimamo namerno je uska: kvalifikovan pregled vaših sistema, prvi prikaz uživo u roku od 24 sata i cene od 200 EUR mesečno. Ono po čemu bismo radije bili ocenjeni jeste lista iznad: da li operativni rukovodilac dobija odgovor ranije nego pre, i da li to išta menja. Jedan konkretan primer kako to izgleda kada neki broj krene naopako nalazi se u tekstu kako istražiti manjak u zalihama.