Preskoči na sadržaj

POSLOVNE APLIKACIJE PO MJERI

Izrada poslovnih aplikacija za specifične procese

Izrada poslovnih aplikacija ima smisla kada tvrtka ima jedan jasno ograničen proces koji postojeći program ne podržava, a uvođenje cijelog ERP-a bilo bi nepotrebno. Dobra aplikacija po mjeri rješava određeni tok podataka, odgovornosti i odluka. Ne počinje popisom tehnologija ni zahtjevom da zamijeni sve postojeće sustave.

Opišite jedan proces
01

Ograničen proces

02

Definirane uloge

03

Provjerljiv rezultat

Standardni pristup

Fazna provedba

Provjereni poslovni podaci

MAXCODE izrađuje ciljane poslovne aplikacije i Odoo prilagodbe. Prije razvoja provjerava može li se problem riješiti standardnom funkcijom, jednostavnijom automatizacijom ili boljim pravilom rada.

Koji su dobri primjeri poslovne aplikacije po mjeri?

Dobar kandidat ima poznat početak, mjerljiv rezultat i ograničen broj odgovornih uloga. Proces se može objasniti na nekoliko stvarnih primjera, a korisnik može provjeriti je li aplikacija proizvela točan rezultat.

interna evidencija zahtjeva i odobravanja;
terenski zapisnik s fotografijama i radnim nalogom;
portal na kojem kupac prati zahtjev ili dostavlja podatke;
portal za dobavljača s potvrdom roka i dokumentacije;
poseban obračun ili izvještaj iz više postojećih izvora;
razmjena podataka između sustava koji se ne mogu izravno povezati.

Svaki primjer treba imati jasnu granicu. Portal za dobavljače ne mora odmah obuhvatiti cijelu nabavu. Terenska aplikacija ne mora zamijeniti financije, skladište i upravljanje projektima.

Kada ne trebate graditi novu aplikaciju?

Ne trebate novu aplikaciju kada standardni program već pokriva većinu procesa, ali ga ljudi ne koriste dosljedno. Tada su često važniji čišćenje podataka, prava pristupa, edukacija ili jednostavniji obrazac. Novi kod samo bi dodao još jedno mjesto za održavanje.

Razvoj nije prvi izbor ni kada zahtjev još nije stabilan. Ako tri osobe isti korak objašnjavaju na tri različita načina, prvo treba dogovoriti odgovornost i očekivani rezultat. Vodič posebno rješenje ili ERP pomaže odvojiti stvarnu posebnost od problema koji bi standardni sustav trebao riješiti.

Kako opisati proces prije razvoja?

Ne počinjite popisom ekrana. Opišite poslovni događaj koji pokreće proces, podatke koji ulaze, odluke koje netko mora donijeti i rezultat koji drugi korisnik treba dobiti. Zatim dodajte jednu redovnu i jednu iznimnu situaciju.

što pokreće proces;
tko unosi ili potvrđuje podatke;
koji su podaci obvezni;
koje odluke zahtijevaju odobrenje;
što se događa kada podatak nedostaje;
koji dokument, zapis ili obavijest završava proces.

Takav opis omogućuje procjenu bez opsežne tehničke dokumentacije. Također rano pokazuje postoji li jednostavnije rješenje.

Kako se aplikacija povezuje s postojećim sustavima?

Povezivanje treba imati vlasnika podataka i jasan smjer. Ako računovodstveni sustav vodi službeni podatak o kupcu, nova aplikacija ga ne bi trebala samostalno mijenjati bez pravila. Ako terenska aplikacija potvrđuje završeni rad, treba znati kojem sustavu šalje tu potvrdu i što se događa kada prijenos ne uspije.

Za svaku integraciju treba zapisati identifikator zapisa, dopuštene promjene, učestalost prijenosa i način obrade pogreške. Ručni izvoz može biti prihvatljiv u prvoj fazi ako je volumen malen. Izravna integracija ima smisla kada kašnjenje ili ponovni unos stvara stvaran operativni rizik.

Kako ograničiti opseg prve verzije?

Prva verzija treba dokazati najvažniji tok, ne sve buduće mogućnosti. Odaberite jednu skupinu korisnika, jedan izvor podataka i jedan završni rezultat. Funkcije koje ne mijenjaju uspjeh tog toka ostavite izvan prve isporuke.

Dobra granica može biti zaprimanje zahtjeva, odobrenje i obavijest korisniku. Napredna analitika, više vrsta portala i dodatne integracije mogu slijediti nakon što stvarni korisnici potvrde da osnovni proces radi. Ovakav pristup smanjuje rizik pogrešne pretpostavke i olakšava promjenu prije nego što postane skupa.

Kako provjeriti prava pristupa i odgovornost za podatke?

Svaka uloga treba vidjeti samo podatke koji su joj potrebni. Osoba koja podnosi zahtjev ne mora moći mijenjati odobrenje. Vanjski korisnik portala ne smije vidjeti zapise druge tvrtke. Administrator aplikacije ne treba automatski biti vlasnik poslovne odluke.

Test treba obuhvatiti barem običnog korisnika, odobravatelja, administratora i vanjskog korisnika kada postoji portal. Za svaku važnu promjenu treba biti vidljivo tko ju je napravio i kada. Posebna Odoo prilagođena rješenja imaju smisla kada se taj proces prirodno oslanja na podatke i prava koja već postoje u Odoou.

Što treba sadržavati početna procjena?

Početna procjena treba završiti preporukom, ne samo popisom funkcija. Preporuka može biti standardna funkcija, mala automatizacija, Odoo prilagodba, samostalna aplikacija ili odluka da razvoj još nema smisla.

Pripremite dva anonimizirana primjera, popis korisničkih uloga, sustave s kojima treba razmjenjivati podatke i jednu mjeru uspjeha. To može biti kraće vrijeme obrade, manje ručnog unosa ili bolja vidljivost statusa, bez izmišljanja unaprijed zajamčenog rezultata.

Počnite s jednim stvarnim procesom

Reprezentativan dokument otkriva stvarni opseg brže od generičkog popisa funkcija.