Vodič za poslovne aplikacije
Izrada poslovnih aplikacija: od tablice do sustava
Izrada poslovne aplikacije ima smislen početak kada možete pokazati koji posao treba urediti, tko u njemu sudjeluje i gdje podaci danas gube jasno značenje. Prije izrade popišite stanja procesa, ovlasti nad zapisima, pravila ispravka i podatke za prijenos. Zatim provjerite cjelovit tok na ograničenom primjeru, kroz probnu migraciju i pilot.
Prvo nacrtajte tok zapisa kroz posao
Tablica sama po sebi nije razlog za novu aplikaciju. Može dobro služiti malom timu koji ima jednostavna pravila. Procjena postaje korisna kada trebate urediti odgovornosti, različite pristupe ili povezanost više koraka koje više nije praktično pratiti postojećim načinom rada.
Ako je još otvorena odluka između kupnje, povezivanja i izrade, pogledajte vodič za odabir softverskog rješenja. Ovdje se bavimo sljedećim pitanjem: kako pripremiti poslovni proces za aplikaciju.
Prikupite posljednjih nekoliko dovršenih primjera i pronađite njihove zajedničke korake. Važno je uključiti i zapis koji je vraćen na dopunu, odbijen ili naknadno ispravljen. Upravo takvi slučajevi pokazuju pravila koja glavna tablica često ne otkriva.
Odredite događaj koji pokreće posao, uvjete za sljedeći korak i završetak. Razlikujte podatak koji je netko unio od podatka koji je ovlaštena osoba potvrdila.
U hipotetskom proizvodnom timu evidencija kontrole serija nalazi se u tablici, a fotografije i dopune u porukama. Nova poslovna aplikacija trebala bi povezati zapis, nalaz i odluku. Ovaj primjer ne opisuje stvarnu Noverovu isporuku niti obećava određeni poslovni rezultat.
| Stanje zapisa | Što znači u primjeru | Uvjet za sljedeći korak |
|---|---|---|
| Pripremljeno | Serija je spremna za pregled | Dodijeljen je kontrolor |
| U pregledu | Unose se nalazi i prilozi | Popunjene su obvezne provjere |
| Potrebna dopuna | Nedostaje podatak ili dokaz | Dopuna je dostavljena na ponovnu provjeru |
| Potvrđeno | Ovlaštena osoba prihvatila je nalaz | Daljnja izmjena slijedi dogovoreni postupak |
Nije dovoljno nacrtati strelice. Za svaku promjenu stanja navedite tko je pokreće i što aplikacija treba napraviti ako uvjet nije ispunjen.
Poslovna pravila odvojite od izgleda ekrana
Na jednom ekranu mogu se nalaziti pravila važna za nekoliko odjela. Primjerice, promjena šifre serije može utjecati na povezane nalaze i izvještaj koji je već izvezen.
Prije rasprave o bojama i rasporedu polja razjasnite:
- što jedinstveno označava zapis;
- koja se polja moraju unijeti, a koja potvrditi;
- tko ispravlja netočan unos i kako se vidi prethodna vrijednost;
- što se događa s prilozima i povezanim zapisima;
- koje su iznimke dopuštene i tko ih odobrava.
U proizvodnom primjeru možete dogovoriti da izmjena potvrđenog nalaza otvara novu verziju za provjeru. Drugi proces možda zahtijeva drukčije ponašanje. Bitno je da ono bude odluka poslovnog vlasnika procesa, jasno zapisana za razvoj i testiranje.
Uloge pretvorite u tablicu konkretnih ovlasti
Administrator koji upravlja računima ne mora imati poslovnu ovlast potvrditi kontrolu. Kontrolor može uređivati dodijeljeni zapis, a voditelj vidjeti rezultate više timova.
Pripremite ovlasti za radnju i podatke na koje se odnosi. OWASP-ove smjernice za autorizaciju preporučuju definiranje korisnika, resursa i dopuštenih operacija te provjeru takvih pravila testovima.
| Uloga u hipotetskom primjeru | Dopuštena radnja | Ograničenje koje treba provjeriti |
|---|---|---|
| Operater | Priprema zapis o seriji | Ne potvrđuje nalaz kontrole |
| Kontrolor | Unosi nalaz na dodijeljenoj seriji | Ne mijenja tuđi potvrđeni nalaz bez postupka ispravka |
| Voditelj kvalitete | Potvrđuje ili vraća nalaz | Razlog vraćanja ostaje vezan uz zapis |
| Administrator računa | Dodjeljuje dogovorene pristupe | Administracija nije prečac za poslovno odobravanje |
Tablica je prijedlog zahtjeva. Stvarna organizacija treba potvrditi odgovornosti i moguće zamjene, uključujući male timove u kojima ista osoba obavlja više poslova.
Očistite značenje podataka prije prijenosa
Nemojte automatski pretpostaviti da stupac iz stare tablice može postati istoimeno polje u novoj aplikaciji. Oznaka „završeno” možda je u jednom timu značila dovršen unos, a u drugom potvrđen rezultat.
Za svaki podatak zapišite izvor, značenje, dopuštene vrijednosti i osobu koja može razriješiti nejasnoću. Dogovorite treba li prenijeti povijest, otvorene stavke, priloge i veze među zapisima.
Microsoftove smjernice za migraciju u Dynamics 365 uključuju izvore, mapiranje, redoslijed, odgovornosti i provjeru kvalitete. To je koristan planerski uzor, uz prilagodbu konkretnim sustavima.
Mogućnost izvoza u CSV nije dokaz da je prijenos riješen. Treba provjeriti odnose između podataka, formate datuma, identifikatore, kodiranje znakova i postupanje s prilozima. Ako se podaci preuzimaju iz drugog poslovnog alata, procijenite i povezivanje postojećih sustava.
Provedite probnu migraciju i uskladite rezultat
Za probu odaberite podatke koji pokrivaju različita stanja i nekoliko poznatih problema. U testnom okruženju koristite prikladno zaštićene ili pripremljene podatke; nemojte nepotrebno dijeliti osobne ili poslovne tajne.
Pretpostavimo da testni skup ima 120 zapisa. Ako je preneseno 117, a tri su odbijena, taj rezultat može objasniti početni broj, ali migracija još nije potvrđena kao dovršena. Treba vidjeti zašto su tri zapisa odbijena i što se s njima odlučilo učiniti. Brojevi služe samo objašnjenju provjere.
Kontrolni popis za probu može uključivati:
- Usklađenje broja izvornih, prenesenih i odbijenih zapisa.
- Provjeru jesu li iste oznake ili šifre stvorile duplikate.
- Otvaranje odabranih zapisa i njihovih priloga.
- Provjeru veza među serijama, nalazima i korisnicima.
- Usporedbu važnih pregleda s dogovorenim izvornim podacima.
- Potvrdu odgovorne osobe da su odstupanja riješena ili dokumentirano prihvaćena.
Zbroj redaka nije jedina provjera. Jednaki brojevi mogu skrivati pogrešno povezane podatke ili različito tumačenje statusa.
Pilot vežite uz konkretne zadatke tima
Odaberite korisnike koji mogu obaviti cijeli tok, uključujući dopunu i ispravak. Dogovorite je li njihov rad probni ili već službeni te gdje se nalazi važeća evidencija za to razdoblje.
Tijekom pilota odvojeno bilježite poteškoće u razumijevanju, programske nedostatke i nova poslovna pravila. Korisnik koji ne zna zašto je zapis vraćen možda treba jasniju poruku. Zahtjev za dodatnim odobravanjem može tražiti promjenu opsega.
Prije prelaska cijelog tima provjerite pristupe, kratke radne upute, osobu za pitanja i postupak ispravka podataka. Za stari način rada dogovorite završetak unosa i pristup povijesti prema stvarnim potrebama; ne brišite je samo zato što je novi sustav pokrenut.
Prva verzija treba zatvoriti proces koji ste odabrali
Za početni opseg odaberite tok čiji se završetak može prepoznati. U primjeru kontrole to uključuje pripremu zapisa, nalaz, dopunu i potvrdu. Napredna analitika može pričekati ako nije uvjet tog rada.
Prilikom pripreme poslovne aplikacije po mjeri posebno označite neriješene odluke. Nepoznato pravilo ili nejasna evidencija podatak su za daljnju analizu, a ne razlog da izvođač sam pretpostavi kako poslujete.
Pošaljite Noveru jedan opisani radni tok i anonimiziran primjer postojeće evidencije. Uz popis uloga i otvorenih pitanja možete započeti razgovor o aplikaciji koja podržava stvaran posao.
Izvori
- OWASP: Authorization Cheat Sheet — definiranje korisnika, resursa i dopuštenih operacija te provjera pravila testovima.
- Microsoft: upravljanje podacima i migracija konfiguracijskih podataka u Dynamics 365 — planiranje izvora, mapiranja, redoslijeda, odgovornosti i provjere kvalitete.