Poslovna aplikacija rijetko propadne zato što joj nedostaje funkcionalnosti. Češći je problem to što je razvijena bez jasnog procesa, bez provjere stvarnih potreba korisnika ili bez plana za rad u postojećem IT okruženju. Ovaj vodič za razvoj poslovnih aplikacija namijenjen je tvrtkama koje žele urediti procese, smanjiti ručni rad i dobiti sustav koji se može sigurno održavati godinama.
Za direktora je aplikacija ulaganje u kontrolu nad poslovanjem. Za IT administratora ona je još jedan sustav koji mora imati upravljanje korisnicima, sigurnosne kopije, nadzor, dokumentaciju i predvidiv način oporavka nakon greške. Razvoj treba planirati tako da zadovolji obje perspektive.
Počnite od poslovnog problema, ne od popisa funkcija
Zahtjev poput „treba nam aplikacija za evidenciju” nije dovoljan za kvalitetan projekt. Potrebno je utvrditi gdje se podaci stvaraju, tko ih unosi, tko ih odobrava, gdje nastaju zastoji i koje su posljedice pogrešnog ili zakašnjelog unosa.
Primjerice, komercijalni tim može voditi ponude u tablicama, financije provjeravati podatke u drugom programu, a uprava tražiti izvještaje ručno na kraju mjeseca. U takvom slučaju cilj nije samo napraviti novi obrazac za unos podataka. Cilj je odrediti jedan pouzdan izvor podataka, pravila odgovornosti i tijek od ponude do izvještaja.
Dobra početna analiza obično odgovara na nekoliko konkretnih pitanja: koji se proces mijenja, koji su korisnici uključeni, koje odluke sustav treba podržati i kako će se mjeriti korist nakon uvođenja. Korist može biti kraće vrijeme obrade zahtjeva, manje duplog unosa, bolja sljedivost ili pouzdanije izvještavanje. Ako se to ne definira unaprijed, projekt lako preraste u niz pojedinačnih želja bez jasnog prioriteta.
Razdvojite nužno od poželjnog
U prvoj verziji aplikacije trebaju biti funkcije bez kojih proces ne može raditi: prijava korisnika, unos ključnih podataka, osnovna pravila obrade, pretraga i izvještaj koji upravi stvarno treba. Napredne analitike, dodatne automatizacije i specifični prikazi mogu doći kasnije, nakon što korisnici potvrde da je osnovni tijek ispravan.
To nije smanjenje ambicije, nego upravljanje rizikom. Ranije uvođenje ograničenog, ali upotrebljivog rješenja daje stvarne povratne informacije. Tako se izbjegava situacija u kojoj se mjesecima razvija opsežan sustav, a tek pri puštanju u rad otkrije da ne prati način rada odjela.
Vodič za razvoj poslovnih aplikacija kroz faze projekta
Razvoj poslovne aplikacije nije samo programiranje. Pouzdan projekt obuhvaća analizu, dizajn procesa, tehničku arhitekturu, razvoj, testiranje, uvođenje i kontinuirano održavanje. Preskakanje jedne od tih faza obično se kasnije plaća duljim zastojima, doradama ili sigurnosnim propustima.
1. Analiza procesa i specifikacija zahtjeva
U ovoj fazi opisuju se postojeći i ciljani procesi. Važno je dokumentirati iznimke, a ne samo idealan tijek rada. Što se događa kada nedostaje obvezan dokument? Tko smije poništiti odobrenje? Može li se zapis mijenjati nakon zaključenja? Kako se evidentira razlog promjene?
Specifikacija ne mora biti nepotrebno opsežna, ali mora biti dovoljno precizna da poslovni korisnici i razvojni tim jednako razumiju očekivani rezultat. Posebnu pozornost treba dati terminologiji. Ako odjeli različito tumače pojmove poput „narudžba”, „ugovor” ili „završeni predmet”, aplikacija će samo prenijeti postojeću nejasnoću u digitalni oblik.
2. Odabir arhitekture i integracija
Aplikacija mora odgovarati infrastrukturi u kojoj će raditi. To uključuje poslužitelje ili cloud okruženje, mrežna pravila, identitet korisnika, pristup udaljenim lokacijama, kapacitet pohrane i plan sigurnosnih kopija.
Posebno je važno rano odlučiti s kojim se sustavima aplikacija mora povezati. To mogu biti računovodstveni sustav, Microsoft 365, centralni direktorij korisnika, dokumentni repozitorij ili postojeća baza podataka. Integracija nije samo tehničko povezivanje. Treba odrediti koji sustav je vlasnik pojedinog podatka, koliko često se podaci razmjenjuju i što se događa kada prijenos ne uspije.
Ponekad je bolji izbor nadograditi postojeći sustav nego razvijati potpuno novu aplikaciju. To ovisi o kvaliteti postojećeg rješenja, mogućnostima integracije, trošku održavanja i tome koliko je poslovni proces specifičan. Standardni procesi često se mogu riješiti konfiguracijom postojećih alata, dok prilagođeni razvoj ima više smisla kada aplikacija nosi specifičnu poslovnu logiku ili povezuje više nepovezanih procesa.
3. Sigurnost se projektira prije prvog unosa podataka
Poslovne aplikacije često obrađuju osobne podatke, financijske informacije, ugovore, evidencije zaposlenika ili interne operativne podatke. Zato pristup ne smije biti zasnovan na zajedničkim korisničkim računima i neformalnim dogovorima o ovlastima.
Potrebno je definirati uloge korisnika, princip najmanjih potrebnih ovlasti i evidentiranje važnih radnji. Korisnik koji može pregledati podatak ne mora nužno imati pravo mijenjati ga, izvoziti ili brisati. Administratorski pristup treba biti ograničen, zaštićen višefaktorskom autentifikacijom gdje je to moguće i jasno dodijeljen odgovornim osobama.
Sigurnost obuhvaća i tehničke mjere: šifriranu komunikaciju, upravljanje zakrpama, zaštitu tajni i pristupnih podataka, odvojena razvojna i produkcijska okruženja te nadzor događaja. Jednako je važan backup. Sigurnosna kopija baze nije potpuna zaštita ako se oporavak nikada ne provjeri. Treba znati koliko se podataka smije izgubiti u najgorem slučaju i koliko dugo poslovanje može raditi bez aplikacije.
4. Razvoj uz redovitu provjeru s korisnicima
Najbolje rezultate daje rad u kraćim ciklusima. Nakon dovršetka pojedine cjeline korisnici trebaju vidjeti stvarni tijek rada, a ne samo tehnički opis. Primjer je unos zahtjeva, odobravanje, generiranje dokumenta ili pregled statusa predmeta.
Povratna informacija korisnika u toj fazi mora biti konkretna. Izjava da je ekran „nepregledan” korisna je kao signal, ali treba utvrditi zašto: nedostaje li važan podatak, jesu li nazivi nejasni, ima li previše koraka ili korisnik ne zna što se od njega očekuje. Takvi detalji izravno utječu na prihvaćanje aplikacije i kvalitetu podataka.
Testiranje mora obuhvatiti stvarne poslovne scenarije
Tehnički ispravna aplikacija nije nužno spremna za rad. Testirati treba i poslovna pravila, ovlasti, integracije, izvještaje te ponašanje kod neispravnih ili nepotpunih podataka. Posebnu vrijednost ima testiranje s korisnicima koji svakodnevno rade proces, jer oni najbrže prepoznaju iznimke koje nisu zapisane u specifikaciji.
Prije produkcijskog puštanja potrebno je pripremiti migraciju podataka ako se prelazi sa starih evidencija. Treba utvrditi koji se povijesni podaci prenose, tko provjerava njihovu točnost i kako će se postupati s duplikatima ili nepotpunim zapisima. Čišćenje podataka često zahtijeva više vremena nego što se očekuje, ali preskakanje tog koraka stvara nepovjerenje u novi sustav od prvog dana.
Uvođenje također treba imati plan povratka. Ako ključna funkcija ili integracija ne radi kako je predviđeno, odgovorne osobe moraju znati može li se postupak privremeno voditi starim načinom rada i tko donosi odluku o prekidu ili nastavku uvođenja.
Održavanje je dio razvoja, a ne naknadna obveza
Nakon puštanja aplikacije u rad počinje operativna faza. Korisnički računi se mijenjaju, poslovna pravila se dopunjuju, operativni sustavi i baze podataka dobivaju nadogradnje, a integrirani sustavi mogu promijeniti način rada. Bez održavanja aplikacija postupno postaje sigurnosni i operativni rizik.
Plan održavanja treba uključiti nadzor dostupnosti, pregled zapisa o greškama, redovite nadogradnje, provjeru sigurnosnih kopija i jasno definiran postupak prijave incidenata. Dokumentacija mora obuhvatiti tehničku arhitekturu, ovlasti, integracije, način oporavka i osnovne administrativne postupke. To je posebno važno za tvrtke s ograničenim internim IT resursima, gdje znanje ne smije ostati vezano uz jednu osobu ili vanjskog izvođača.
CarPen Rebuild razvoj informacijskih sustava promatra zajedno s infrastrukturom na kojoj oni rade. Aplikacija nema poslovnu vrijednost ako korisnici ne mogu pristupiti sustavu, ako sigurnosna kopija nije provjerena ili ako prekid mrežne veze zaustavlja ključni proces bez plana oporavka.
Kvalitetno razvijena aplikacija ne mora riješiti svaki proces odjednom. Mora pouzdano riješiti onaj proces koji je odabran, jasno evidentirati odgovornost i omogućiti siguran nastavak rada kada se poslovanje promijeni. Zato razvoj treba voditi kao dugoročnu poslovnu i IT odluku, uz partnera koji jednako razumije aplikaciju, podatke i okruženje u kojem sustav svakodnevno radi.