Poglavlje 4: Modelovanje poslovnih procesa
Priča za početak. Početkom dvadesetog vijeka automobil je bio igračka bogatih. U fabrici Henryja Forda u Highland Parku, kraj Detroita, jedan automobil Model T sklapala je grupa radnika na jednom mjestu: šasija je stajala, a ljudi su oko nje donosili dijelove. Jedan automobil trajao je oko dvanaest i po sati. Ford i njegovi inženjeri nisu izmislili novi motor ni novi materijal. Uradili su nešto što danas zovemo modelovanje procesa: rastavili su posao na male korake, poredali ih i zapitali se gdje se gubi vrijeme. Zaključak je bio da radnici više hodaju i čekaju nego što rade. Godine 1913. okrenuli su logiku: umjesto da ljudi idu do automobila, automobil je na pokretnoj traci išao od radnika do radnika, a svaki je radio jedan korak. Prema muzeju The Henry Ford, novi način sklapao je Model T za oko 93 minute. Automobil je postao jeftiniji, a fabrike širom svijeta počele su crtati svoje procese. Ista ideja, da se posao prvo nacrta pa onda popravlja, i danas je prvi korak svakog informacionog sistema.
U poglavlju 3 zapisali smo šta zainteresovane strane traže od DeliveryApp, kao korisničke priče. Priče su korisne, ali svaka opisuje jedan komad posla. Ne vidi se redoslijed: šta se dešava prvo, ko čeka koga, gdje se posao grana i gdje se gubi vrijeme. To pokazuje model procesa. U ovom poglavlju prvo opisujemo kako narudžba teče danas, telefonom, i mjerimo gdje se gubi vrijeme. Zatim crtamo dijagram toka i proces u standardnom jeziku BPMN, s plivačkim stazama za kupca, DeliveryApp, restoran i dostavljača. Na kraju crtamo kako podaci teku kroz sistem (DFD). Na praktičnoj nastavi crtamo BPMN u draw.io i dijagram toka u Mermaidu.
Literatura. Osnovna literatura predmeta:
- B. Popović, K. Kuk: Informacioni sistemi, Kriminalističko-policijski univerzitet, Beograd, 2017.
- J. S. Valacich, J. F. George: Modern Systems Analysis and Design, 9th ed., Pearson, 2020.
- L. Jelenković: Sustavi za rad u stvarnom vremenu – skripta, FER, Zagreb, 2015.
- D. Milićev: Programiranje u realnom vremenu – skripta, Beograd, 2002.
- V. Kovačević, M. Popović: Sistemska programska podrška u realnom vremenu 1, FTN, Novi Sad, 2013.
Riječi ovog poglavlja.
- Poslovni proces – niz aktivnosti kojim organizacija od ulaza (narudžba) dođe do rezultata (hrana na vratima).
- Aktivnost – jedan korak procesa koji neko ili nešto obavi (npr. „pripremi pizzu”).
- AS-IS i TO-BE – proces kakav jeste danas i proces kakav će biti s novim sistemom.
- Vrijeme rada i vrijeme čekanja – vrijeme u kojem se nešto korisno radi, i vrijeme u kojem posao samo stoji.
- Efikasnost toka – udio vremena rada u ukupnom trajanju procesa.
- Dijagram toka – crtež koraka i odluka jednog postupka (oval, pravougaonik, romb, strelica).
- BPMN (Business Process Model and Notation) – međunarodni standard za crtanje poslovnih procesa.
- Događaj – nešto što se desi i pokrene, prekine ili završi proces (krug u BPMN-u).
- Kapija (gateway) – mjesto grananja ili spajanja toka (romb u BPMN-u).
- Bazen i staza (pool, lane) – „plivački” pojasevi koji pokazuju ko radi koju aktivnost.
- DFD (data flow diagram) – dijagram toka podataka: odakle podaci dolaze, ko ih mijenja i gdje se čuvaju.
- Kontekstni dijagram – DFD najvišeg nivoa: cijeli sistem kao jedan krug, okružen vanjskim učesnicima.
- Skladište podataka – mjesto u DFD-u gdje podaci miruju (tabela, fajl, fascikla).
Ciljevi poglavlja. Nakon poglavlja možete: definisati poslovni proces i navesti njegov ulaz, aktivnosti, izlaz i vlasnika; opisati AS-IS proces narudžbe telefonom i označiti probleme; izračunati efikasnost toka procesa prije i poslije DeliveryApp; nacrtati dijagram toka s odlukama za obračun dostave; prepoznati i nacrtati osnovne elemente BPMN-a (događaj, aktivnost, kapija, tok, bazen i staza); razlikovati ekskluzivnu i paralelnu kapiju; nacrtati BPMN proces narudžbe DeliveryApp sa četiri staze; nacrtati kontekstni dijagram i DFD prvog nivoa; prepoznati grešku „crna rupa” i „čudo” u DFD-u; iz aktivnosti procesa izvesti korisničke priče.
Plan poglavlja – Sedmica 4: tri časa teorije i tri časa praktične nastave
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 4.1–4.3 Proces, AS-IS i TO-BE, mjerenje | Narudžba telefonom: 50 minuta, efikasnost 54 % |
| Teorija 2 | 4.4–4.6 Dijagram toka i BPMN | Odluka o dostavi; četiri staze narudžbe |
| Teorija 3 | 4.7–4.9 Kontekstni dijagram, DFD, od procesa do zahtjeva | Gdje miruje narudžba? |
| Praksa 1–3 | draw.io BPMN; Mermaid dijagram toka; DFD | Proces narudžbe DeliveryApp |
Dio 1 – Šta je proces i kako ga mjerimo
4.1 Poslovni proces
Poslovni proces je niz aktivnosti kojim organizacija od nekog ulaza dođe do rezultata koji nekome ima vrijednost. Svaki proces ima pet stvari:
- Okidač ili ulaz – šta ga pokreće (kupac zove telefonom).
- Aktivnosti – koraci koje neko obavlja (primi narudžbu, pripremi, spakuj, odvezi).
- Učesnike – ko obavlja koji korak (konobar, kuhar, dostavljač).
- Rezultat – šta na kraju postoji (topla hrana na vratima, plaćen račun).
- Vlasnika – osobu odgovornu da proces radi dobro (vlasnik restorana).
Slika iz života: proces je kao recept. Ima sastojke (ulaz), korake redom (aktivnosti), kuhara (učesnik) i jelo na kraju (rezultat). Ali za razliku od recepta, poslovni proces često ima više kuhara koji jedan drugom dodaju posao, i baš na tim „dodavanjima” se posao najčešće zaglavi.
Zašto informacioni sistem počinje od procesa? Zato što sistem nije cilj sam po sebi. Cilj je da proces radi bolje: brže, s manje grešaka, jeftinije. Ako ne znamo kako proces teče danas, ne znamo ni šta sistem treba da popravi. Sjetite se Forda: prvo su nacrtali posao, pa tek onda izmislili traku.
Ukratko.
- Poslovni proces je niz aktivnosti koji od ulaza dovodi do rezultata s vrijednošću.
- Svaki proces ima okidač, aktivnosti, učesnike, rezultat i vlasnika.
- Posao se najčešće zaglavi tamo gdje ga jedan učesnik predaje drugom.
- Sistem se projektuje da bi proces radio bolje, pa se prvo mora znati kako proces teče danas.
4.2 AS-IS i TO-BE
Analitičar uvijek crta dvije verzije procesa. AS-IS (engleski „kako jeste”) je proces kakav se danas zaista radi, sa svim prečicama, papirićima i problemima. TO-BE („kako će biti”) je proces kakav želimo s novim sistemom.
AS-IS se crta po posmatranju i intervjuima (poglavlje 3), a ne po tome kako bi proces „trebao” izgledati. Ako vlasnik kaže „konobar uvijek ponovi narudžbu kupcu”, a posmatranje pokaže da to radi rijetko, u AS-IS ide ono što je posmatranje pokazalo.
Evo AS-IS procesa narudžbe telefonom u Piceriji R-1, kako ga je analitičar zapisao jednog podneva:
| Korak | Ko | Šta radi | Problem koji je uočen |
|---|---|---|---|
| 1 | kupac | zove restoran | zauzeta linija u vrijeme ručka |
| 2 | konobar | zapisuje narudžbu i adresu na papir | pogrešno čuje broj kuće |
| 3 | konobar | računa cijenu „od oka” | dostava različita za istu ulicu |
| 4 | konobar | nosi papir u kuhinju | papir se zaturi među druge |
| 5 | kuhar | priprema jela | ne zna koja narudžba je prva |
| 6 | konobar | zove dostavljača | dostavljač je na drugoj vožnji |
| 7 | dostavljač | traži adresu | zove kupca s puta |
| 8 | dostavljač | naplaćuje gotovinom | nema sitnog novca |
TO-BE s DeliveryApp mijenja skoro svaki korak: kupac sam bira jela i vidi tačnu cijenu (koraci 1–3 nestaju za konobara), narudžba se pojavi na ekranu kuhinje redom (koraci 4–5), DeliveryApp sam nudi narudžbu slobodnom dostavljaču s adresom na mapi (koraci 6–7), a plaćanje je karticom unaprijed (korak 8).
Česta zabluda. „Novi sistem treba samo ubrzati stari proces.” Ako se loš proces samo kompjuterizuje, dobija se brži loš proces. Ford nije napravio brža kolica za radnike, nego je promijenio ko se kreće. Zato se TO-BE crta tek kad je AS-IS shvaćen, i pita se koji koraci uopšte trebaju postojati.
Ukratko.
- AS-IS je proces kakav se danas zaista radi, a TO-BE kakav želimo sa sistemom.
- AS-IS se crta po posmatranju, a ne po tome kako bi proces trebao izgledati.
- Kompjuterizovan loš proces je samo brži loš proces; TO-BE preispituje koji koraci trebaju postojati.
4.3 Mjerenje procesa: vrijeme rada i vrijeme čekanja
Da bismo znali je li TO-BE zaista bolji, proces treba izmjeriti. Najkorisnija mjera je trajanje, podijeljeno na dva dijela:
- vrijeme rada – minute u kojima se nešto korisno dešava s narudžbom (pizza se peče, dostavljač vozi);
- vrijeme čekanja – minute u kojima narudžba samo stoji ili se nešto radi što kupcu ne donosi vrijednost (papir čeka u kuhinji, konobar prepisuje).
Analitičar je u Piceriji R-1 izmjerio prosječnu narudžbu telefonom:
| Korak | AS-IS (min) | TO-BE (min) | Vrsta |
|---|---|---|---|
| prijem narudžbe | 3 | 1 (restoran prihvati na ekranu) | čekanje |
| prepisivanje i računanje | 2 | 0 | čekanje |
| čekanje da kuhar počne | 10 | 3 | čekanje |
| priprema | 15 | 15 | rad |
| čekanje dostavljača | 8 | 4 | čekanje |
| vožnja | 12 | 12 | rad |
| ukupno | 50 | 35 |
Vrijeme rada je u oba slučaja isto: 15 + 12 = 27 minuta. DeliveryApp ne peče pizzu brže i ne vozi brže. Smanjuje samo čekanje: s 3 + 2 + 10 + 8 = 23 na 1 + 0 + 3 + 4 = 8 minuta.
Udio rada u ukupnom vremenu zove se efikasnost toka:
\[ E = \frac{t_{\text{rad}}}{t_{\text{ukupno}}} \times 100\ \% \]
Čemu služi. Efikasnost toka pokazuje koliki dio vremena kupčeve narudžbe je zaista posvećen njoj. Za AS-IS: E = 27 / 50 × 100 % = 54 %. Za TO-BE: E = 27 / 35 × 100 % ≈ 77 %. Kupac dobija hranu 15 minuta ranije, a da niko u kuhinji nije morao raditi brže. U mnogim stvarnim procesima (odobrenje kredita, prijem u bolnicu) efikasnost toka je ispod 10 %: dokument devet dana čeka, a jedan dan se na njemu radi.
Broj za pamćenje. S DeliveryApp prosječna narudžba traje 35 minuta umjesto 50, a efikasnost toka raste s 54 % na 77 %. Ovo su brojevi koje vlasnik restorana razumije bez ijednog dijagrama.
Ukratko.
- Trajanje procesa dijeli se na vrijeme rada i vrijeme čekanja.
- DeliveryApp ne ubrzava pečenje ni vožnju; smanjuje čekanje s 23 na 8 minuta.
- Efikasnost toka je udio vremena rada: 54 % telefonom, oko 77 % sa DeliveryApp.
- Izmjeren proces daje brojeve koje naručilac razumije.
Provjeri se.
- Šta je AS-IS proces? – Proces kakav se danas zaista radi, prema posmatranju.
- Koliko traje narudžba telefonom, a koliko kroz DeliveryApp? – 50 i 35 minuta.
- Kako se računa efikasnost toka? – Vrijeme rada podijeljeno ukupnim vremenom, puta 100 %.
Dio 2 – Dijagram toka i BPMN
4.4 Dijagram toka
Dijagram toka (engleski flowchart) je najstariji i najjednostavniji način da se nacrta postupak. Koristi četiri simbola:
| Simbol | Oblik | Značenje |
|---|---|---|
| početak / kraj | oval | gdje postupak počinje i završava |
| radnja | pravougaonik | jedan korak („izračunaj artikle”) |
| odluka | romb | pitanje s odgovorima da/ne („iznos ≥ 30 €?”) |
| tok | strelica | šta slijedi poslije čega |
Dijagram toka je idealan za jedno pravilo s odlukama, kao što je obračun dostave DeliveryApp. Evo pravila PP-1 do PP-4 kao Mermaid dijagram:
flowchart TD
S(["Početak"]) --> A["Saberi artikle"]
A --> B{"Iznos < 5,00 €?"}
B -- da --> X1(["Odbij: manje od najmanje narudžbe"])
B -- ne --> C{"Udaljenost > 10 km?"}
C -- da --> X2(["Odbij: izvan zone"])
C -- ne --> D{"Iznos ≥ 30,00 €?"}
D -- da --> F["Dostava = 0,00 €"]
D -- ne --> E["Dostava = 2,00 € + 0,50 € × započeti km preko 3"]
F --> K(["Prikaži ukupno"])
E --> KPročitajmo dijagram kao rečenicu za N-1001: saberi artikle (21,50 €); je li manje od 5,00 €? Ne. Je li udaljenost veća od 10 km? Ne (4,2 km). Je li iznos 30,00 € ili više? Ne. Dostava je 2,00 + 0,50 × 2 = 3,00 €; prikaži ukupno 24,50 €.
Primijetite da dijagram natjera da odlučimo redoslijed provjera. Ako je narudžba 4,50 € na 11 km, koju poruku kupac vidi? Po ovom dijagramu „manje od najmanje narudžbe”, jer se iznos provjerava prvi. To je projektna odluka koju treba dogovoriti s vlasnicima, a dijagram ju je izbacio na vidjelo.
Ukratko.
- Dijagram toka koristi oval za početak i kraj, pravougaonik za radnju, romb za odluku i strelicu za tok.
- Dobar je za jedno pravilo s odlukama, kao obračun dostave.
- Crtanje natjera tim da odluči redoslijed provjera, npr. šta kupac vidi kad je narudžba i premala i predaleko.
4.5 BPMN: zajednički jezik za procese
Dijagram toka nema dogovoren način da pokaže ko radi koji korak, šta se dešava istovremeno i kako učesnici razmjenjuju poruke. Za to je napravljen BPMN (Business Process Model and Notation), međunarodni standard koji održava organizacija OMG. Verzija 2.0 objavljena je 2011. godine i od tada je najrašireniji jezik za poslovne procese: crtaju ga i analitičari i ljudi iz posla, a neki programi ga mogu i izvršavati.
BPMN ima mnogo simbola, ali za devet desetina dijagrama dovoljno je pet grupa:
| Grupa | Oblik | Primjeri |
|---|---|---|
| Događaj | krug: tanak = početni, dvostruk = srednji, debeo = završni | „kupac otvorio aplikaciju”, „prošlo 10 minuta”, „narudžba isporučena” |
| Aktivnost | zaobljen pravougaonik | „pripremi jela”, „naplati karticom” |
| Kapija | romb: s X = ekskluzivna, s + = paralelna | „prihvata li restoran?”, „istovremeno: kuhinja i traženje dostavljača” |
| Tok | puna strelica = redoslijed u istoj organizaciji; isprekidana = poruka između organizacija | |
| Bazen i staza | veliki pravougaonik (bazen) podijeljen na pojaseve (staze) | bazen „DeliveryApp” sa stazama „Aplikacija”, „Restoran”, „Dostavljač” |
Dvije vrste kapija
Kapije zbunjuju početnike, pa ih razdvojimo:
- Ekskluzivna kapija (romb s X, engleski XOR) – tok ide samo jednim putem, zavisno od uslova. „Restoran prihvata narudžbu?” Ili da, ili ne.
- Paralelna kapija (romb s +, engleski AND) – tok se dijeli na sve puteve istovremeno, a druga paralelna kapija ih kasnije sačeka i spoji. Kad restoran prihvati narudžbu, kuhinja počinje pripremu i istovremeno DeliveryApp traži dostavljača. Dalje se ide tek kad su oboje gotovi: jela su spremna i dostavljač je stigao.
Slika iz života: ekskluzivna kapija je raskrsnica na kojoj vozač bira jedan put. Paralelna kapija je porodica koja se na ulazu u tržni centar razdvoji: jedni idu po hranu, drugi po odjeću, i svi se nađu na izlazu prije nego što krenu kući.
Bazeni i staze
Bazen (pool) predstavlja jednog samostalnog učesnika, obično organizaciju: DeliveryApp, sistem plaćanja. Staze (lanes) dijele bazen po ulogama unutar te organizacije. Ime dolazi od plivačkog bazena podijeljenog na staze: svaki plivač ostaje u svojoj stazi, a tok preko staza pokazuje kako se posao predaje.
Važno pravilo: puna strelica (tok redoslijeda) ne prelazi granicu bazena. Između bazena idu samo poruke (isprekidane strelice), jer jedna organizacija ne može drugoj narediti redoslijed rada; može joj samo poslati poruku.
Ukratko.
- BPMN je međunarodni standard za crtanje poslovnih procesa; verzija 2.0 je iz 2011.
- Pet grupa simbola: događaj (krug), aktivnost (zaobljen pravougaonik), kapija (romb), tok (strelica) te bazen i staza.
- Ekskluzivna kapija bira jedan put, a paralelna pokreće sve puteve istovremeno i čeka da se završe.
- Između bazena idu samo poruke, a ne tok redoslijeda.
4.6 BPMN proces narudžbe DeliveryApp
Spojimo sve u jedan TO-BE proces. U bazenu DeliveryApp su četiri staze: Kupac (koristi aplikaciju), Aplikacija DeliveryApp (sistem), Restoran i Dostavljač. Sistem plaćanja je poseban bazen, jer je to druga firma.
Proces, rečenicu po rečenicu:
- Početni događaj: kupac otvori aplikaciju.
- Kupac bira jela i adresu; aplikacija računa ukupnu cijenu (dijagram toka iz 4.4).
- Ekskluzivna kapija: je li narudžba ispravna (iznos ≥ 5,00 €, adresa ≤ 10 km)? Ako ne, kupac vidi poruku i vraća se na izbor.
- Kupac potvrđuje; aplikacija šalje poruku sistemu plaćanja i čeka odgovor.
- Ekskluzivna kapija: plaćanje odobreno? Ako ne, završni događaj „narudžba nije plaćena”.
- Aplikacija prikaže narudžbu restoranu (stanje NOVA).
- Ekskluzivna kapija: restoran prihvata? Ako ne, aplikacija vraća novac i obavještava kupca; završni događaj „odbijena”.
- Paralelna kapija (dijeli): restoran priprema jela, istovremeno aplikacija nudi narudžbu slobodnom dostavljaču.
- Paralelna kapija (spaja): kad su jela spremna i dostavljač stigao, dostavljač preuzima narudžbu.
- Dostavljač vozi; aplikacija kupcu pokazuje da je narudžba na putu.
- Dostavljač predaje hranu; završni događaj „isporučena”.
U BPMN-u ovaj proces crtamo u alatu draw.io (praktična nastava), koji ima sve BPMN simbole. Mermaid nema BPMN simbole, ali staze i tok možemo približno pokazati njegovim dijagramom toka s grupama (subgraph); slika 4.4 je nacrtana tako.
Na času. Gdje u ovom procesu može doći do čekanja koje kupca nervira? Šta bi aplikacija mogla uraditi ako restoran ne odgovori na narudžbu ni nakon 5 minuta? (Jedna mogućnost: srednji događaj „prošlo 5 minuta” automatski odbije narudžbu i vrati novac. To je novi zahtjev za backlog.)
Ukratko.
- Proces narudžbe ima staze Kupac, Aplikacija, Restoran i Dostavljač, a sistem plaćanja je poseban bazen.
- Ekskluzivne kapije provjeravaju ispravnost narudžbe, plaćanje i prihvatanje u restoranu.
- Paralelna kapija pušta kuhinju i traženje dostavljača da rade istovremeno.
- Crtanje procesa otkriva nove zahtjeve, npr. šta ako restoran ne odgovori.
Provjeri se.
- Čemu služi romb u dijagramu toka? – Označava odluku s odgovorima da ili ne.
- Koja je razlika između ekskluzivne i paralelne kapije? – Ekskluzivna bira jedan put, a paralelna pokreće sve puteve istovremeno.
- Zašto sistem plaćanja crtamo kao poseban bazen? – Jer je to druga organizacija, s kojom razmjenjujemo samo poruke.
Dio 3 – Kako teku podaci
4.7 Kontekstni dijagram
BPMN pokazuje ko šta radi i kojim redom. Ali ne pokazuje dobro koji podaci putuju i gdje se čuvaju. Za to postoji dijagram toka podataka, skraćeno DFD (data flow diagram). DFD je stariji od UML-a i BPMN-a (nastao je sedamdesetih godina dvadesetog vijeka), ali je i danas koristan, jer na jednoj slici pokaže gdje podaci ulaze u sistem, gdje se mijenjaju i gdje miruju.
DFD ima četiri simbola:
| Simbol | Oblik | Značenje | Primjer |
|---|---|---|---|
| vanjski entitet | pravougaonik | ko daje ili prima podatke, a nije dio sistema | Kupac, Restoran |
| proces | krug ili zaobljen pravougaonik | ono što podatke mijenja | „Izračunaj cijenu” |
| skladište podataka | dvije paralelne linije ili otvoren pravougaonik | gdje podaci miruju | D1 Narudžbe |
| tok podataka | strelica s nazivom podatka | koji podatak putuje | „stavke i adresa” |
Najviši nivo DFD-a zove se kontekstni dijagram (ili DFD nivoa 0). Na njemu je cijeli sistem jedan krug, a oko njega su vanjski entiteti i podaci koje razmjenjuju sa sistemom. Kontekstni dijagram odgovara na pitanje: gdje su granice sistema? Šta je unutra (što mi pravimo), a šta je vani (s čim samo razgovaramo)?
Za DeliveryApp su vani: Kupac, Restoran, Dostavljač, Sistem plaćanja i Servis mapa. Ovaj dijagram smo zapravo nacrtali još u poglavlju 1 (slika 1.4), samo sada svaku strelicu imenujemo podatkom.
Ukratko.
- DFD pokazuje koji podaci putuju, ko ih mijenja i gdje se čuvaju.
- Simboli su vanjski entitet, proces, skladište podataka i imenovani tok.
- Kontekstni dijagram prikazuje cijeli sistem kao jedan krug i odgovara na pitanje gdje su granice sistema.
4.8 DFD prvog nivoa
Kad je granica jasna, krug „DeliveryApp” otvaramo i gledamo unutra. DFD prvog nivoa dijeli sistem na glavne procese i pokazuje skladišta podataka:
- 1.0 Primi narudžbu – od kupca prima stavke i adresu; čita jelovnik iz D2.
- 2.0 Izračunaj cijenu – od servisa mapa dobija udaljenost; računa dostavu i ukupno po PP-1 do PP-5.
- 3.0 Naplati – šalje iznos sistemu plaćanja i prima potvrdu.
- 4.0 Proslijedi restoranu – upisuje narudžbu u D1 i prikazuje je restoranu; prima prihvatanje ili odbijanje.
- 5.0 Organizuj dostavu – nudi narudžbu dostavljaču i bilježi preuzimanje i isporuku u D1.
Skladišta: D1 Narudžbe, D2 Jelovnik, D3 Kupci (adresa i telefon).
Brojevi procesa (1.0, 2.0…) nisu redoslijed, nego oznake, da bi se proces 2.0 kasnije mogao otvoriti u još detaljniji dijagram s procesima 2.1, 2.2…
Dvije česte greške u DFD-u
- Crna rupa – proces koji prima podatke, a ništa ne daje. Ako „2.0 Izračunaj cijenu” prima stavke i udaljenost, a nijedna strelica ne izlazi, gdje je cijena završila? Nešto je zaboravljeno.
- Čudo – proces koji daje podatke, a ništa ne prima. Ako „5.0 Organizuj dostavu” šalje dostavljaču adresu, a ne prima je ni iz D1 ni iz D3, odakle mu adresa? Ništa se ne stvara iz ničega.
Treće pravilo: podaci ne idu direktno iz jednog skladišta u drugo, niti od vanjskog entiteta u skladište. Uvijek ih neki proces premjesti. Tako se zna ko je odgovoran za promjenu.
Ukratko.
- DFD prvog nivoa otvara sistem na glavne procese i skladišta podataka.
- DeliveryApp ima pet procesa (primi, izračunaj, naplati, proslijedi, organizuj dostavu) i tri skladišta (narudžbe, jelovnik, kupci).
- Crna rupa je proces bez izlaza, a čudo proces bez ulaza; oba su greška.
- Podatke između skladišta i entiteta uvijek premješta neki proces.
4.9 Od procesa do zahtjeva
Model procesa nije sam sebi cilj. Iz njega se provjeravaju i dopunjuju zahtjevi iz poglavlja 3. Pravilo je jednostavno: svaka aktivnost u stazi „Aplikacija DeliveryApp” i svaki proces u DFD-u mora imati bar jednu korisničku priču, a svaka kapija i svaki događaj mogu otkriti novu.
| Element modela | Postojeća priča? | Nova priča ili pitanje |
|---|---|---|
| aktivnost „izračunaj ukupnu cijenu” | da (kupac vidi cijenu dostave) | – |
| kapija „restoran prihvata?” | da (restoran prihvata ili odbija) | Šta kupac vidi dok čeka odgovor? |
| događaj „prošlo 5 minuta bez odgovora” | ne | Kao kupac, želim da mi se novac automatski vrati ako restoran ne odgovori za 5 minuta. |
| paralelna kapija „kuhinja i dostavljač” | ne | Kao dostavljač, želim dobiti ponudu dok se jela još pripremaju, da ne bih čekao. |
| skladište „D3 Kupci” | ne | Kao kupac, želim sačuvati adresu, da je ne kucam svaki put (uz NZ-5 o brisanju). |
Ovako model i backlog rastu zajedno. Ako postoji priča koja se ne vidi ni u jednom modelu, i to je signal: ili model nije potpun, ili priča ne pripada ovom sistemu.
Ukratko.
- Svaka aktivnost sistema i svaki proces u DFD-u mora imati bar jednu korisničku priču.
- Kapije i događaji često otkriju nove priče, npr. automatski povrat novca nakon 5 minuta.
- Priča koja se ne vidi ni u jednom modelu znak je nepotpunog modela ili pogrešne priče.
Provjeri se.
- Šta prikazuje kontekstni dijagram? – Cijeli sistem kao jedan krug, vanjske entitete i podatke na granici.
- Šta je „crna rupa” u DFD-u? – Proces koji prima podatke, a ništa ne daje.
- Koja nova priča izlazi iz događaja „prošlo 5 minuta bez odgovora restorana”? – Automatski povrat novca kupcu ako restoran ne odgovori.
Praktična nastava – proces narudžbe DeliveryApp
Cilj je nacrtati proces narudžbe DeliveryApp na tri načina (dijagram toka, BPMN, DFD) i izmjeriti AS-IS i TO-BE. Svi fajlovi idu u repozitorij deliveryapp-projekat, u novi folder modeli/.
Korak 1 – Dijagram toka obračuna dostave (Mermaid)
- U fajl
modeli/dostava.mdprepišite Mermaid dijagram iz 4.4 (prvi red bloka mora bitimermaid). - Pogledajte pregled u VS Codeu. Ako se ne iscrta, provjerite navodnike oko natpisa sa znakovima
<,≥i zagradama. - Dodajte korak za popust PP-5: poslije „Saberi artikle” pitanje „Ima li kod STUDENT10?” i radnju „Popust = min(10 % artikala, 5,00 €)”. Pazite: besplatna dostava gleda iznos prije popusta.
- Pratite dijagram prstom za tri narudžbe i zapišite rezultat: N-1001 (24,50 €), N-1001 sa STUDENT10 (22,35 €), N-1003 (odbijena, 4,50 €).
Korak 2 – BPMN u draw.io
- Otvorite app.diagrams.net ili ekstenziju Draw.io Integration u VS Codeu (fajl
modeli/narudzba.drawio). - U lijevom panelu uključite biblioteku BPMN General (More Shapes → BPMN).
- Nacrtajte bazen „DeliveryApp” sa četiri staze (Kupac, Aplikacija, Restoran, Dostavljač) i poseban bazen „Sistem plaćanja”.
- Nacrtajte proces iz 4.6: početni događaj, aktivnosti, tri ekskluzivne kapije, par paralelnih kapija i tri završna događaja (isporučena, odbijena, nije plaćena).
- Između DeliveryApp i sistema plaćanja nacrtajte poruke (isprekidane strelice), ne pune.
- Dodajte srednji vremenski događaj „5 minuta bez odgovora” na kapiju restorana i granu „vrati novac”.
- Izvezite sliku (File → Export as → PNG) u
modeli/narudzba.png.
Korak 3 – Kontekstni dijagram i DFD prvog nivoa
- U
modeli/dfd.mdnacrtajte kontekstni dijagram kao Mermaidflowchart LR: DeliveryApp kao krug(( )), pet vanjskih entiteta kao pravougaonici, svaka strelica s nazivom podatka. - Ispod nacrtajte DFD prvog nivoa s pet procesa i tri skladišta. Skladište u Mermaidu možete nacrtati oblikom
[("D1 Narudžbe")](cilindar). - Za svaki proces provjerite: ima li bar jedan ulaz i jedan izlaz (nema crne rupe ni čuda)?
Korak 4 – AS-IS i TO-BE u brojevima
U modeli/proces.md napravite tabelu koraka iz 4.3 i izračunajte efikasnost toka za AS-IS i TO-BE. Zatim zamislite da restoran ne prihvata narudžbu odmah, nego prosječno za 4 minute umjesto 1: kolika je tada TO-BE efikasnost?
Korak 5 – Nove priče iz modela
Za svaki događaj i kapiju u svom BPMN dijagramu provjerite postoji li korisnička priča u GitHub Issues. Dodajte bar dvije nove priče koje je crtanje otkrilo, s kriterijima Dato–Kada–Tada.
Korak 6 – AI kao provjera modela (opcionalno)
Dajte AI asistentu tekstualni opis procesa iz 4.6 i svoj Mermaid DFD, i zatražite: „Nađi procese bez ulaza ili izlaza i tokove koji idu direktno između skladišta.” Svaku prijavljenu grešku provjerite sami na dijagramu prije nego što je ispravite.
Rezultat koji se predaje: folder modeli/ s dijagramom toka (dostava.md), BPMN dijagramom (narudzba.drawio i narudzba.png), DFD-om (dfd.md) i tabelom mjerenja (proces.md), te bar dvije nove korisničke priče.
Vježbe
Vježba za studenta 1 – dijelovi procesa.
Za proces „upis na fakultet” navedite okidač, tri aktivnosti, učesnike, rezultat i vlasnika.
Rješenje. Okidač: kandidat preda prijavu. Aktivnosti: provjera dokumenata, prijemni ispit, objava rang-liste (i upis). Učesnici: kandidat, studentska služba, komisija za prijemni. Rezultat: upisan student s indeksom. Vlasnik: prodekan za nastavu ili sekretar fakulteta (zavisno od organizacije). Prihvatljivi su i drugi tačni primjeri.
Vježba za studenta 2 – efikasnost toka.
U Roštilju R-2 narudžba telefonom traje: prijem 4 min, prepisivanje 2, čekanje roštilja 6, pečenje 12, pakovanje 2, čekanje dostavljača 10, vožnja 8. Pečenje, pakovanje i vožnja su vrijeme rada. Izračunajte efikasnost toka. Šta bi se desilo kad bi DeliveryApp smanjio prijem na 1 minutu, prepisivanje na 0 i čekanje dostavljača na 3?
Rješenje. Ukupno 4 + 2 + 6 + 12 + 2 + 10 + 8 = 44 min. Rad 12 + 2 + 8 = 22 min. E = 22 / 44 = 50 %. Sa DeliveryApp: 1 + 0 + 6 + 12 + 2 + 3 + 8 = 32 min, E = 22 / 32 ≈ 69 %.
Vježba za studenta 3 – vrsta kapije.
Ekskluzivna ili paralelna? a) „Plaćanje odobreno?” b) „Poslije isporuke: pošalji kupcu račun mailom i zatraži ocjenu restorana.” c) „Je li adresa dalje od 10 km?”
Rješenje. a) ekskluzivna (ili da, ili ne); b) paralelna (oba se rade, nezavisno jedno od drugog); c) ekskluzivna.
Vježba za studenta 4 – greška u DFD-u.
U DFD-u postoje tokovi: „Kupac → D3 Kupci: adresa” i „4.0 Proslijedi restoranu → Restoran: narudžba”, a proces 4.0 nema nijedan ulaz. Koje su dvije greške i kako ih ispraviti?
Rješenje. Prva greška: vanjski entitet piše direktno u skladište; ispravka je da adresu primi proces (npr. 1.0 Primi narudžbu) i on je upiše u D3. Druga greška: proces 4.0 je „čudo” (daje narudžbu, a ništa ne prima); ispravka je dodati ulaz, npr. „D1 Narudžbe → 4.0: plaćena narudžba” ili tok od 3.0 Naplati.
Vježba za studenta 5 – dijagram toka.
Nacrtajte (na papiru ili u Mermaidu) dijagram toka pravila PP-6: kupac traži otkazivanje; ako je narudžba u stanju NOVA ili PRIHVAĆENA, otkazuje se i novac vraća; inače kupac vidi poruku. Pratite dijagram za narudžbu u stanju U_PRIPREMI.
Rješenje. Početak → „Kupac traži otkazivanje” → romb „Stanje je NOVA ili PRIHVAĆENA?” → da: „Postavi stanje OTKAZANA” → „Vrati novac” → kraj; ne: „Prikaži: priprema je počela, otkazivanje nije moguće” → kraj. Za U_PRIPREMI odgovor na romb je „ne”, pa kupac vidi poruku i narudžba ostaje u pripremi.
Sažetak u pet rečenica
- Poslovni proces je niz aktivnosti od okidača do rezultata, s učesnicima i vlasnikom, a sistem se projektuje da bi proces radio bolje, kao što je Ford 1913. promijenio proces i sklapao automobil za 93 minute umjesto 12,5 sati.
- AS-IS opisuje proces kakav jeste, a TO-BE kakav želimo; mjerenje vremena rada i čekanja pokazuje da DeliveryApp skraćuje narudžbu s 50 na 35 minuta i podiže efikasnost toka s 54 % na oko 77 %.
- Dijagram toka s ovalom, pravougaonikom, rombom i strelicom dobar je za jedno pravilo s odlukama, kao obračun dostave.
- BPMN je standard za procese s događajima, aktivnostima, ekskluzivnim i paralelnim kapijama, tokovima, bazenima i stazama, a između bazena idu samo poruke.
- DFD pokazuje kako podaci teku od vanjskih entiteta kroz procese do skladišta, kontekstni dijagram crta granicu sistema, a svaki element modela provjerava se prema korisničkim pričama.