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.
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.
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.