Softver po mjeri ili standardni softver? Kako odlučiti za svoju tvrtku

Voditelj skladišta ispravlja zalihe u tablici, dok se u uredu otpremnice ispisuju iz drugog sustava. Zaposlenik zove telefonom kako bi doznao status isporuke, jer se informacija u sustavu pojavi tek nakon završetka smjene. U takvim situacijama pitanje softvera po mjeri ili standardnog softvera nije načelna IT rasprava. Ono odlučuje hoće li radni koraci ubuduće biti jasniji - ili će novi alat samo stvoriti dodatne zaobilaznice.

Za mala i srednja poduzeća ne postoji opći odgovor. Standardni softver može biti brzo i ekonomično rješenje. Softver po mjeri može znatno pojednostaviti procese, ali veže proračun i odgovornost. Presudno nije koja varijanta zvuči modernije. Presudno je koliko dobro podupire stvarno poslovanje.

Softver po mjeri ili standardni softver: temeljno pitanje

Standardni softver razvija se za široko tržište. Donosi unaprijed definirane tijekove, uloge, ekrane i funkcije - primjerice za upravljanje robom, CRM, knjigovodstvo, otpremu ili upravljanje projektima. Dobavljač troškove razvoja raspoređuje na mnogo kupaca. To obično čini početak jeftinijim i bržim.

Softver po mjeri planira se i razvija za konkretnu tvrtku. On ne preslikava nužno svaki postojeći proces nepromijenjen. Dobar razvoj po mjeri najprije provjerava koji su koraci stručno nužni, koji su se povijesno nakupili i gdje nedostaju pravila. Tek potom nastaje aplikacija koja odgovara definiranim radnim tijekovima - primjerice za ulaz robe, premještaje, komisioniranje, isporučnu dokumentaciju ili planiranje ruta.

Razlika stoga nije samo u opsegu funkcija. Standardni softver često pita: „Kako ćete svoje poslovanje prilagoditi predviđenom procesu?“ Softver po mjeri pita: „Koji proces ubuduće treba pouzdano funkcionirati?“ Oba pitanja mogu imati smisla. Problematično postaje kad se na njih ne odgovori svjesno.

Kada je standardni softver bolji izbor

Ako je proces uobičajen u branši, jasno ograničen i nije ključan za konkurentnost, mnogo toga govori u prilog standardnom rješenju. Financijsko knjigovodstvo je tipičan primjer. Ni e-pošta, videokonferencije ili jednostavna evidencija radnog vremena rijetko se moraju graditi od nule. Tamo korist vlastitog razvoja obično nije razmjerna trudu, održavanju i odgovornosti.

Standardni softver je osim toga smislen kada tvrtka prvo mora stvoriti strukturu. Tvrtka koja danas vodi zalihe na papiru, u osobnim bilješkama i u više Excel datoteka ne treba nužno odmah skladišni sustav po mjeri. Možda je na početku dovoljan dobro uveden standardni proizvod s jednoznačnim šiframa artikala, skladišnim lokacijama i zaduženjima.

Prednost je u predvidljivosti: funkcije su vidljive, postoje reference i materijali za obuku, ažuriranja stižu redovito. Mnoga rješenja dobro pokrivaju 70 ili 80 posto uobičajene potrebe. Taj udio može biti posve dovoljan ako se preostali zahtjevi pojavljuju rijetko ili se mogu riješiti jednostavnim, stabilnim dodatnim procesom.

Česta je pogreška, međutim, miješanje troškova licence s ukupnim troškovima. Mjesečne naknade lako je usporediti. Manje su vidljivi savjetovanje pri uvođenju, čišćenje podataka, sučelja, dodatni moduli, prilagodbe po mjeri i radno vrijeme utrošeno na zaobilaznice. Jeftina licenca može postati skupa ako zaposlenici iste podatke prenose više puta ili svakodnevno ručno obrađuju iznimke.

Kada se softver po mjeri isplati

Softver po mjeri nije pravi odgovor zato što bi tim volio „nešto svoje“. Postaje isplativ kada ponavljajući tijek stvara znatan trud, pogreške ili kašnjenja, a standardni proizvodi taj tijek mogu prikazati samo uz trajne kompromise.

U skladištu to može izgledati vrlo konkretno: ulazi robe danas se fotografiraju, količine se kasnije upisuju u tablicu, a odstupanja razjašnjavaju telefonom. Ili otpremni tim izrađuje naljepnice u jednom portalu, otpremnice u drugom, a zatim ručno ažurira status narudžbe. Ako se ovakvi prekidi događaju svakodnevno, trud više nije malen. Vidi se u dodatnim upitima, vremenu traženja, pogrešnim knjiženjima, zakašnjelim informacijama i nedostatku transparentnosti među smjenama.

Aplikacija po mjeri može te korake objediniti. Skeniranje pri ulazu robe ažurira zalihu, kod odstupanja pokreće provjeru i informaciju izravno stavlja na raspolaganje dispoziciji i otpremi. Isporučni dokumenti nastaju iz istih podataka o narudžbi. Ovlasti osiguravaju da zaposlenici vide samo funkcije koje trebaju. Cilj nije maksimalan opseg funkcija, nego pouzdan tijek s manje prekida među medijima.

Četiri pokazatelja posebno govore u prilog ozbiljnom razmatranju opcije po mjeri:

• Zaposlenici iste podatke održavaju u više sustava ili tablica.
• Iznimke su dio svakodnevnog poslovanja i organiziraju se izvan sustava.
• Proces se namjerno razlikuje od uobičajenih branšnih tijekova i stvara stvarnu korist.
• Tim već može izraziti kašnjenja ili pogreške vremenom, novcem ili pritužbama kupaca.

Ne opravdava svaki poseban slučaj razvoj. Ako se iznimka pojavljuje dvaput mjesečno, jasno dokumentiran ručni proces često je razumnije rješenje. Ako se pojavljuje dvadeset puta po smjeni, više ne bi smjela ovisiti o pamćenju, dovikivanju i krhkoj tablici.

Ispravno usporediti troškove

Usporedba „licenca nasuprot razvojnom projektu“ je preuska. Standardni softver ima tekuće troškove licence, uvođenja i prilagodbe. Softver po mjeri ima veće početne troškove te izdatke za rad, daljnji razvoj i podršku. Obje varijante trebaju vrijeme za migraciju podataka, obuku i stručne odluke.

Smislenije je promatranje kroz tri do pet godina. Pritom ne računaju samo računi, nego i operativni troškovi: koliko minuta traje jedna narudžba? Koliko se često ispravljaju podaci? Koje pogreške dolaze do kupaca? Koliko košta kad smjena čeka povratnu informaciju iz drugog područja? Kakva ovisnost nastaje kad dobavljač promijeni cijene, funkcije ili ugovorne uvjete?

Kod softvera po mjeri pojavljuje se još jedno pitanje: je li rješenje održivo? Dobra narudžba obuhvaća više od privlačnog sučelja. U to spadaju razumljiva arhitektura, dokumentirana isporuka, uređene sigurnosne kopije, uloge i prava, razumljivi modeli podataka te plan ažuriranja. Tehnologije poput PHP 8.4, modernog JavaScripta i MySQL 8 nisu sami sebi svrha. Smislene su kada omogućuju aplikaciju koja se dugoročno može održavati i za koju stručno znanje ostaje dostupno.

Jednako je važan opseg. Prvo izdanje ne mora digitalizirati cijelu organizaciju. Često je pametnije početi s tijekom koji donosi jasno mjerljivu korist - primjerice ulazom robe i kretanjem zaliha - a ostala područja priključiti tek nakon praktične uporabe. To smanjuje rizik i rano daje povratnu informaciju iz poslovanja.

Uklapanje u proces prije popisa funkcija

Mnogi projekti odabira softvera počinju dugim popisima želja. To je razumljivo, ali rijetko dovoljno. Popis kaže da sustav može „ispisivati naljepnice“. Ne kaže nastaje li naljepnica u pravom trenutku, provjeravaju li se podaci, ostaju li ponovni ispisi sljedivi i mora li otpremnik zbog toga mijenjati pet ekrana.

Bolje je proći kroz stvarne događaje. Ne idealizirani tijek iz organigrama, nego utorak ujutro kad isporuka kasni, artikl nedostaje, a dvoje zaposlenika istodobno ovisi o istoj informaciji. Tko radi kada s kojim podacima? Gdje se donose odluke? Koja je iznimka česta? Koja informacija mora biti odmah dostupna, a koja može stići kasnije?

Iz takve analize često proizlazi i mješovito rješenje. Standardni ERP ostaje vodeće rješenje za matične podatke, nabavu ili račune. Individualna web aplikacija nadopunjuje ga za skladišni proces, određeno odobrenje ili planiranje isporuka. Sučelja se tada moraju planirati svjesno: koji je izvor podataka vodeći? U kojem se smjeru podaci prenose? Kako se pogreške prepoznaju i ponovno obrađuju? Bez tih pravila problem se samo seli iz tablice u nejasan sustavni krajolik.

Kontrola, rad i odgovornost za podatke

Standardnim softverom tvrtka kupuje i ovisnost. To nije automatski loše. Specijalizirani dobavljač može učinkovitije brinuti o sigurnosnim ažuriranjima, zakonskim zahtjevima i infrastrukturi nego pojedino srednje poduzeće. Ipak, odgovorni bi trebali provjeriti trajanje ugovora, mogućnosti izvoza, kvalitetu sučelja i postupanje s vlastitim podacima.

Kod softvera po mjeri kontrola je veća, ali zahtijeva pouzdanog tehničkog partnera i jasna zaduženja. Tko pokreće aplikaciju? Kako se uvode sigurnosna ažuriranja? Kakvi pristupi postoje u slučaju podrške? Što se događa pri promjeni pružatelja usluge? Dokumentacija i uredne primopredaje nisu usputna stvar, nego dio sigurnosti ulaganja.

To vrijedi i za automatizirana testiranja. Čim nova funkcija dotakne zalihe, otpremu ili osjetljive podatke kupaca, kritični tijekovi trebaju se provjeravati ponovljivo. Upravo kod internih aplikacija može imati smisla samostalno hostirano testno okruženje, ako snimke zaslona, testni podaci i promet aplikacije ne pripadaju u vanjski oblak. Presudni su razumljivi testni slučajevi i dokumentirani rezultati - a ne AI oznaka na ponudi.

Bolja odluka počinje malo i konkretno

Prije nego što odaberete ili naručite softver, uzmite proces s velikim gubicima trenjem. Nekoliko tjedana mjerite vrijeme prolaza, pogreške, dodatne upite i ručne prijenose. Razgovarajte s ljudima koji taj tijek svakodnevno izvode. Oni često poznaju ne samo probleme, nego i iznimke na kojima teoretski dobar sustav u svakodnevici zakaže.

Ako standardni proizvod poboljšava tijek uz nekoliko prihvatljivih prilagodbi, to je dobra odluka. Ako bi poslovanje trajno moralo raditi zaobilazeći sustav, softver po mjeri zaslužuje čvrst izračun isplativosti. Najbolje rješenje nije ono s najvećim katalogom funkcija, nego ono koje u ponedjeljak ujutro pouzdano radi i skida posao s tima.