---------------------------
doc. dr Milan Zdravković. Mašinski fakultet u Nišu, Inženjerski menadžment, studijski profil Industrijski menadžment, master studije, 1.godina
---------------------------
Pristup online kursu: http://ekursevi.masfak.ni.ac.rs:9000/courses/course-v1:MEF+UPRO+2019-20_S2/about
2. Uvod
• Modeli poslovnih procesa – koriste se u
različitim fazama životnog ciklusa BPM-a.
• Svrha modeliranja - različiti modeli
• Upoznavanje sa procesom i predstavljanje na
način koji većina razume
– Učesnici u procesu vide samo svoje aktivnosti
– Preduslov za njegovu analizu, redizajn i
automatizaciju.
2
3. Prednosti modeliranja poslovnih
procesa
• Bolje razumevanje postojećih poslovnih procesa
• Dokumentovanje poslovnih procesa
• Osnova za unapređenje postojećih poslovnih procesa
• Osnova za istraživanje uticaja organizacionih
promena
• Osnova za kreiranje poslovnih informacionih sistema
koji podržavaju odvijanje poslovnih procesa
4. Business Process Modeling Notation
Proces naručivanja proizvoda
• Događaji i aktivnosti
• Događaji – nešto što se dešava trenutno (primljen je ugovor),
• Aktivnosti - jedinice posla koje imaju neko trajanje (plaćanje ugovora).
• Logički povezani.
• Sekvenca – posle A sledi B
• Osnovni koncepti u BPMN-u su događaj, aktivnost i tok.
– Događaji se predstavljaju krugovima,
– aktivnosti pravougaonicima sa zaobljenim uglovima,
– tokovi se predstavljaju linijama sa strelicama.
4
5. Instance procesa
• Više instanci procesa – međusobno nezavisne
• Tokeni – prate instancu procesa
– Kreiraju se na početku instance procesa i prate tok
kroz proces,
– Tačke na modelu procesa.
5
6. Grananje i spajanje
• Sekvencijalne i druge aktivnosti
• Primer uslovnog grananja: zahtev za osiguranjem
– aktivnosti odobravanja i odbijanja zahteva isključuju jedna drugu.
– Ne mogu se obavljati paralelno.
– Uzajamno isključive
• Primer bezuslovnog grananja: Zahtev za osiguranjem
– kad se odobri, podnosilac o tome biva obavešten i vrši se isplata.
– Obaveštavanje i isplata
• Dva odeljenja
• Ne mora redom
• Da li može istovremeno?
– Kada aktivnosti nisu međusobno zavisne kaže se da su uporedne.
• Kapija (gateway)
– postoji mehanizam koji dozvoljava ili zabranjuje prolaz kroz nju.
– Kada do kapije stignu podaci, oni se mogu spojiti ili podeliti u zavisnosti od tipa
kapije.
6
7. Kapije
• Kapije se označavaju rombovima i postoje
kapije za spajanje i razdvajanje (engl. Split i
join).
• Split (razdvajanje)
• Join (Spajanje)
7
8. Uslovno grananje
• isključivi split (XOR) - Podela na dve ili
više alterativnih aktivnosti
• Isključivi join (XOR).
8
10. Paralelno izvršenje
• Ako između aktivnosti ne postoje zavisnosti
vezane za redosled – može paralelno.
• paralelna kapija tipa AND.
– paralelno izvršenja dve ili više grana se koristi AND
razdvajanje (engl. AND split),
– za sinhronizaciju izvršenja grana koristi AND
spajanje (engl. AND join).
10
13. Ponovno izvršenje posla i ponavljanje
• Linearne strukture - svaka aktivnost se obavlja najviše
jednom.
• Ponavljanje (ponovno izvršenje posla jer kontrola nije
dozvolila nastavak)
• Proces komunikacije sa ministarstvom
– Kada se primi zahtev, prvo se registruje od strane sistema.
– Zatim se zahtev ispiituje, tako da može da se pripremi odgovor
ministarstva.
– Odgovor priprema službenik ministarstva, ali pre slanja treba da
ga pregleda odgovorni sekretar.
– Ako sekretar ne odobri odgovor, on se vraća nazad do
službenika, koji ga je pripremao.
– Proces se završava kad se odgovor odobri.
13
14. Modeliranje ponavljanja posla
• Identifikacija aktivnosti koje se ponavljaju.
– Priprema odgovora ministarstva i Pregled odgovora
ministarstva.
– Blok koji se ponavlja.
• poslednja aktivnost u bloku mora biti aktivnost u kojoj se donosi
odluka.
• Odluka da li se proces vraća nazad, pre početka bloka koji se
ponavlja, ili se nastavlja dalje.
• Ova aktivnost ima dva izlaza.
• Pregled odgovora ministarstva, a izlazi iz nje su: "odgovor je
odobren" (u kom slučaju se proces nastavlja) i "odgovor nije
odobren" (u kom slučaju se počinje iz početka).
• Ovo se modelira pomoću kapije tipa XOR split, koja ima dva izlaza.
• Jedan izlaz omogućava nastavak procesa, a drugi vraćanje nazad.
14
16. Tokovi informacija
• Organizacioni aspekti poslovnog procesa
– funkcije, poslovni podaci, ljudi i softverski sistemi.
• Različiti aspekti se modeliraju iz različitih perspektiva.
• Funkcionalna perspektiva - obuhvata aktivnosti koje se
odvijaju u procesu,
• Perspektiva kontrole toka - ukazuje na redosled
odvijanja aktivnosti i događaja.
• Perspektiva podataka - pokazuje koje informacije
(poslovni dokumenti, datoteke) su potrebne za
obavljanje aktivnosti, kao i koje informacije nastaju kao
rezultat odvijanja aktivnosti.
16
17. Tokovi informacija
• Proces naručivanja sa podacima
• Provera zaliha – prva aktivnost u procesu
– Ulaz - naružbenica, jer pomoću nje proverava da li su
traženi proizvodi na zalihama.
• Narudžbenica – objekat podataka
• Opisuju tok informacija u i iz aktivnosti.
– fizički objekti (ugovor ili pismo)
– Digitalni format (elektronska poruka ili datoteka).
• Ikonica dokumenta sa savijenim uglom.
• Povezivanje sa aktivnostima tačkastim linijama, sa
otvorenim strelicama (veze podataka).
17
19. Tokovi informacija
• Ulaz ili izlaz – strelice
– Objekat Narudžbenica (Purchase order) je ulazni objekat za aktivnost
provere raspoloživosti zaliha.
– Više istih ikona ako je potrebno
• Izlaz iz jedne aktivnosti - ulaz u narednu
• Objekti podataka - modeliranje tok informacija između aktivnosti u
procesu.
• Objekti podataka i njihove veze sa aktivnostima ne mogu da
zamene tok izvršenja procesa.
• Čak i ako je neki objekat prosleđen od aktivnost A do aktivnosti B, i
dalje treba modelirati da iza aktivnosti A sledi aktivnost B.
• Skraćeno - objekat Shipment Address
• Složenost se povećava
• Napomene
19
20. Resursi
• Ukazuju na to ko ili šta obavlja aktivnost.
• opšti termin koji se odnosi na bilo koga ili bilo šta što
obavlja aktivnost.
• Učesnik u procesu (Petar Petrović)
• Softverski sistem (server ili aplikacija)
• Oprema (štampač ili mašina)
• aktivni resursi - resursi koji mogu da samostalno obave
aktivnost
• pasivni resursi - samo uključeni u obavljanje aktivnosti.
• Fotokopiranje (aparat i radnik)
• Posmatramo aktivne resurse
– Organizacione jedinice, uloge
20
21. Modeliranje resursa
• Pul - za modeliranje klase resursa
• Staza - za podelu pula na podklase i pojedinačne resurse.
• Pul se obično koristi za modeliranje cele organizacije
• Staza - za modeliranje odeljenja, tima ili softverskog sistema.
• Pulovi i staze - pravougaonici u okviru kojih se mogu da postave
aktivnosti, događaji, kapije i objekti podataka.
– Horizontalno ili vertikalno
• Aktivnosti u njihove staze
• Gneždenje staza
• Objekti podataka – bilo gde
• Kapije tipa XOR i OR - u istu stazu u kojoj su i aktivnosti koje im
prethode,
• Kapije tipa AND - bilo gde.
21
23. Predstavljanje podprocesa
• Složeno procesi – veliki i složeni modeli (prethodni primer + podaci,
napomene)
• Sakrivanje delova procesa – pojednostavljenje modela
• Podproces predstavlja samostalnu, složenu aktivnost, koja se može
podeliti na manje jedinice posla.
• Atomska aktivnost (zadatak) je aktivnost koja pokriva jednu jedinicu
posla koja se dalje ne može deliti.
• Identifikacija grupe povezanih aktivnosti koje zajedno postižu
konkretni cilj ili generišu konkretan izlaz.
• Primer: aktivnosti Provera raspoloživosti sirovina i Kupovina sirovina
od Snabdevača - zajedno čine nabavku materijala – podproces
• Dve paralelne grane za isporuku i fakturisanje narudžbe mogu da se
grupišu u okviru jedne aktivnosti (podprocesa) po imenu "Isporuka i
fakturisanje".
23
27. Kada koristiti podprocese
• Na primer, može se usvojiti pravilo da se na prvom
nivou modeliraju samo osnovne poslovne aktivnosti,
na drugom se dodaju tačke donošenja odluka itd., sve
dok se ne dođe do modeliranja izuzetaka i detalja koji
su relevantni samo za automatizaciju procesa.
• Kad model postane velik (30 objekata)
• Aspekti koji utiču na čitljivost modela
– gustina veza kod modela procesa,
– broj paralelnih grana,
– najduži put od početka do kraja,
– kozmetički aspekti kao što su raspored, stil označavana,
boje koje se koriste, debljina linija itd.
27
Modeli poslovnih procesa se koriste u različitim fazama životnog ciklusa BMP-a. Pre nego što se krene sa modeliranjem procesa vrlo je važno da se definiše svrha tog modeliranja. U zavisnosti od razloga modeliranja i modeli će izgledati različito. Od mnogih razloga za modeliranje prvi je pokušaj da se proces shvati i da se to predstavi na način da model mogu da razumeju i ljudi koji svakodnevno koriste taj proces. Učesnici u procesu najčešće uočavaju samo svoje aktivnosti, tako da često ne sagledavaju celinu procesa. Modeliranje procesa može da pomogne da se proces bolje shvati i da se identifikuju i spreče eventualni problemi. Potpuno upoznavanje sa procesom je preduslov za njegovu analizu, redizajn i automatizaciju.
Na slici 1 je prikazan niz aktivnosti koje modeliraju proces naručivanja. Proces počinje kad god se od kupca primi poružbenica. Prva aktivnost je potvrda narudžbe. Nakon toga se određuje adresa za isporuku, proizvod se isporučuje, posle čega se pravi ugovor, nakon čega sledi plaćanje i arhiviranje narudžbenice.
Sa slike se može videti da su dva događaja opisana sličnim, ali ipak pomalo različitim simbolima. Početak se obeležava krugom sa tanjom linijom, a kraj krugom sa debljom linijom. Ovi događaji označavaju početak i kraj instance procesa. U primeru sa narudžbenicom proces počinje kad god se primi nova narudžbenica i završava se njenim arhiviranjem.
Ako bi se ovo odvijalo u nekom preduzeću, onda bi svakog dana postojao određen broj instanci procesa, pri čemu su sve te instance međusobno nezavisne. Kad se jednom pokrene instanca procesa, za praćenje toka procesa se koristi pojam tokena. Tokeni se kreiraju na početku instance procesa i prate tok kroz proces, dok se ne dođe do kraja, kad se uništavaju. Tokeni se opisuju tačkama na modelu procesa. Na slici 2 su prikazane tri instance opisanog procesa. Jedna instanca je tek krenula (crni token kod početnog događaja), druga je kod isporuke proizvoda (crveni token kod aktivnosti isporuke) i treća je kod plaćanja (zeleni token).
Svakoj aktivnosti treba dati odgovarajuće ime. Isto se odnosi i na događaje. Ako se označi početni događaj, onda se lako može videti šta je to što taj proces pokreće, dok ime krajnjeg događaja omogućava da vidimo kada se i kako proces završava.
Aktivnosti i događaji ne moraju da se obavezno odvijaju sekvencijalno. Na primer, ako se radi o procesu rukovanja zahtevom za osiguranjem, aktivnosti odobravanja i odbijanja zahteva isključuju jedna drugu. To znači da se te dve aktivnosti ne mogu obavljati paralelno. Kada dve ili više aktivnosti predstavljaju alternative jedna drugoj, kaže se da se one uzajamno isključuju.
Razmotrimo drugačiju situaciju. U procesu rukovanja zahtevom za osiguranjem, kad se zahtev jednom odobri, podnosilac o tome biva obavešten i vrši se isplata. Obaveštavanje i isplata su dve aktivnosti koje obično obavljaju dva različita odeljenja, pošto su u pitanju aktivnosti koje su međusobno nezavisne i ne moraju da se obavljaju redom. One se mogu izvršavati istovremeno, odnosno paralelno. Kada aktivnosti nisu međusobno zavisne kaže se da su uporedne.
Kapije se označavaju rombovima i postoje kapije za spajanje i razdvajanje (engl. Split i join). Kapija tipa split je tačka u kojoj dolazi do razdvajanja procesa, dok je join mesto gde se tokovi procesa spajaju. Kapija tipa split ima jedan ulazni tok i više izlaznih, dok kapije tipa join imaju više dolaznih tokova, a jedan izlazni.
Za označavanje podele na dve ili više alterativnih aktivnosti koristi se isključivi split (XOR). Za spajanje se koristi XOR join. XOR kapija se predstavlja praznim rombom u kome se nalazi slovo X.
Pogledajmo na primer, proces provere ugovora (slika 3). Kada se od kupca primi ugovor on treba da se proveri za slučaj da u njemu postoji neka greška. Posle provere može da se desi da nema grešaka u kom slučaju ugovor može da se pošalje, da postoje greške koje se mogu ispraviti, u kom slučaju se ugovor ponovo šalje do kupca, kao i da postoje greške koje se ne mogu ispraviti u kom slučaju se ugovor blokira. Kad se izvrši jedna od ovih aktivnosti ugovor se skladišti i proces se završava.
Model procesa počinje aktivnošću Provera ugovora. Ova aktivnost je aktivnost u kojoj se donose odluke, što znači da iz nje vodi više izlaza. U primeru aktivnost ima tri različita moguća izlaza, koji su svi uzajamno isključivi. Ovo će se modelirati pomoću XOD splita koji ide iza aktivnosti. Izlazi vode do različitih aktivnost "Slanje ugovora", "Ponovno slanje ugovora do kupca" i "Stopiranje ugovora".
Grana koja vodi ka stopiranju ugovora je označena kosom crticom. Ovo se može koristiti za označavanje grane koja je podrazumevana, odnosno koja će se izvršiti ako svi uslovi koji izlaze iz kapije budu netačni.
Nakon što se izvrši jedna od tri alternative, one se spajaju u jedan tok pomoću aktivnosti skladištenje ugovora. Za ovo se koristi XOR join (spajanje).
Ako između dve ili više aktivnosti ne postoje nikakve zavisnosti vezane za redosled (ni jedna od njih ne mora da sledi posle druge), onda se one mogu izvršavati paralelno. Za modeliranje takve relacije se koristi paralelna kapija tipa AND. Za modeliranje paralelnog izvršenja dve ili više grana se koristi AND razdvajanje (engl. AND split), dok se za sinhronizaciju izvršenja tih grana koristi AND spajanje (engl. AND join). Kapija tipa AND se označava rombom sa znakom plus u sredini.
Na slici 4 je prikazan primer provere sigurnosti na aerodromu. Nakon što preuzmu karte, putnici idu na proveru. Tamo treba da prođu skeniranje tela i prtljaga. Nakon toga mogu da produže do aviona. Proces se sastoji od četiri aktivnosti. Počinje se aktivnošću Transport do provere sigurnosti, a završava aktivnošću Transport do terminala. Ove dve aktivnosti su očigledno zavisne jedna od druge. Putnik može da ode do terminala, samo ako je pre toga prošao sigurnosne provere. Posle prve, a pre poslednje aktivnosti treba da se izvrše još dve aktivnosti. Redosled po kojem će se one dve izvršavati nije bitan. To su aktivnosti Skeniranje osobe i skeniranje prtljaga. Ovo se modelira pomoću dve kapije tipa AND. Jedna se postavlja posle aktivnosti transport do provere sigurnosti, a druga pre aktivnosti transport do terminala.
Ovde treba obratiti pažnju na to da se aktivnost transport do terminala ne može izvršiti dok se ne završe obe aktivnosti koje se odvijaju paralelno.
Pretpostavka je da se narudžbenica popunjava samo ako deo postoji na zalihama. Ako dela nema na zalihama proces se završava odbijanjem narudžbe. Ako je narudžba potvrđena, prezima se adresa za isporuku i traženi proizvod se isporučuje. U isto vreme se šalje i ugovor i vrši plaćanje. Na kraju se narudžba arhivira, čime se proces završava.
Kao što se vidi u modelu postoje dve aktivnosti koje se uzajamno isključuju. To su aktivnosti Potvrda narudžbe i Odbijanje narudžbe. One se modeliraju pomoću XOR split kapije. Aktivnosti Preuzimanje adrese za isporuku i isporuka, kao i aktivnosti Slanje ugovora i prijem plaćanja mogu da se obavljaju nezavisno, pa su zbog toga modelirane pomoću AND split kapije i AND join kapije. Ove dve grupe aktivnosti obično u organizaciji obavljaju različiti resursi (prodavac i neko iz odeljenja finansija).
Ako se ova proširena verzija modela uporedi sa prvobitnom, vidi se da ovde postoje dva događaja koji označavaju kraj procesa. U BPMN modelu može postojati više događaja koji označavaju kraj procesa. Svaki od njih se odnosi na različit način završetka i izlaza iz procesa.
Modeliranje ponavljanja posla traži da se prvo identifikuju aktivnosti koje treba da se ponavljaju. U prethodnom primeru, to su aktivnosti Priprema odgovora ministarstva i Pregled odgovora ministarstva. Možemo ih nazvati blokom koji se ponavlja. Za ovaj blok važi da poslednja aktivnost u bloku mora biti aktivnost u kojoj se donosi odluka. To nam omogućava da odlučimo da li se proces vraća nazad, pre početka bloka koji se ponavlja, ili se nastavlja dalje. Ova aktivnost, prema tome, treba da ima dva izlaza. Aktivnost u kojoj se donosi odluka je u ovom slučaju Pregled odgovora ministarstva, a izlazi iz nje su: "odgovor je odobren" (u kom slučaju se proces nastavlja) i "odgovor nije odobren" (u kom slučaju se počinje iz početka). Ovo se modelira pomoću kapije tipa XOR split, koja ima dva izlaza. Jedan izlaz omogućava nastavak procesa, a drugi vraćanje nazad.
Poslovni proces obuhvata različite organizacione aspekte, kao što su funkcije, poslovni podaci, ljudi i softverski sistemi. Različiti aspekti se modeliraju iz različitih perspektiva. Do sada smo se upoznali sa funkcionalnom perspektivom, koja obuhvata aktivnosti koje se odvijaju u procesu, kao i sa perspektivom kontrole toka, koja ukazuje na redosled odvijanja aktivnosti i događaja. Još jedna vrlo važna perspektiva je perspektiva podataka. Ova perspektiva pokazuje koje informacije (poslovni dokumenti, datoteke) su potrebne za obavljanje aktivnosti, kao i koje informacije nastaju kao rezultat odvijanja aktivnosti.
Da pogledamo proces naručivanja, ali sada sa podacima. Prvo ćemo definisati koji su podaci potrebni za odvijanje svake aktivnosti, a onda i podatke koji nastaju kao rezultat izvršenja aktivnosti. Prva aktivnost u procesu je, na primer, Provera zaliha. Ona kao ulaz traži naružbenicu, jer pomoću nje proverava da li su traženi proizvodi na zalihama. Isti dokument je potreban i za aktivnost Provera raspoloživosti sirovina, ako proizvod treba da se napravi.
Pomoću strelica se označava da li objekat podataka ulazi ili izlazi iz aktivnosti. Na primer, objekat Narudžbenica (Purchase order) je ulazni objekat za aktivnost provere raspoloživosti zaliha. Ako je potrebno isti objekat se može više puta prikazati na dijagramu, da bi se izbegle mnogobrojne linije, koje bi presecale elemente dijagrama.
Često je izlaz iz jedne aktivnosti ulaz u narednu aktivnost. Objekti podataka omogućavaju modeliranje tok informacija između aktivnosti u procesu. Treba imati na umu da objekti podataka i njihove veze sa aktivnostima ne mogu da zamene tok izvršenja procesa. To znači da, čak i ako je neki objekat prosleđen od aktivnost A do aktivnosti B, i dalje treba modelirati da iza aktivnosti A sledi aktivnost B. Skraćena oznaka da se jedan objekat prosleđuje do druge je kad se objekat podataka poveže sa linijom toka koja povezuje te dve aktivnosti (objekat Shipment Address na slici).
Ubacivanje objekta podataka na dijagram procesa može da usloži dijagram, tako da se pdoaci prikazuju samo ako za to postoje dobri razlozi, na primer, ako treba pojasniti nešto u toku procesa ili ako se planira automatizacija.
Ponekad je potrebno da se u model procesa ubace dodatne informacije, koje povećavaju čitljivost modela. Na primer, u procesu sa prethodne slike, možemo definisati da aktivnost isporuka proizvoda obuhvata i pakovanje. Takve dodatne informacije se na model ubacuju pomoću tekstualnih napomena. Napomena se označava pravougaonikom bez jedne stranice i povezana je sa elementom procesa tačkastom linijom. Napomene nemaju nikakvo semantičko značenje, pa ne utiču na tokene koji se kreću kroz proces.
Još jedan aspekt na koji treba obratiti pažnju tokom modeliranja poslovnog procesa je perspektiva resursa. Resursi ukazuju na to ko ili šta obavlja aktivnost. Resurs je opšti termin koji se odnosi na bilo koga ili bilo šta što obavlja aktivnost. Resurs može biti:
Učesnik u procesu, odnosno pojedinac, kao što je na primer Petar Petrović.
Softverski sistem, na primer, neki server ili aplikacija
Oprema, kao što je štampač ili mašina.
Postoje aktivni resursi, odnosno resursi koji mogu da samostalno obave aktivnost i pasivni resursi, koji su samo uključeni u obavljanje aktivnost. Na primer, fotokopirni aparat će učesnik koristiti za kopiranje dokumenta. U tom slučaju je aparat pasivni resurs, dok je ranik aktivni.
Kad se govori o modeliranju procesa, obično se posmatraju aktivni resursi. Obično se u modelu ne prikazuju konrektne osobe, već se prikazuje grupa resursa koji su međusobno zamenljivi, tako da bilo koji član grupe može da obavi aktivnost. Takve grupe se nazivaju klasama resursa. Primeri grupa mogu biti organizacione jedinice ili uloge.
Za modeliranje resursa se u BPMN-u koriste dva elementa. To su pulovi i staze. Pul se koristi za modeliranje klase resursa, dok se staza koristi za podelu pula na podklase i pojedinačne resurse. Pul se obično koristi za modeliranje cele organizacije (kao što je prodavac u prethodnom primeru), dok se staza koristi za modeliranje odeljenja, tima ili softverskog sistema.
U primeru je pul Prodavac podeljen na dve staze. Jedna označava odeljenje skladištenja i distribucije, a druga odeljenje prodaje. Staze se mogu gnezditi jedna u okviru druge, čime se postiže dalje grananje. Na primer, ako treba da se modeliraju i odeljenje i uloge u tom odeljenju, za odeljenje se može upotrebiti jedna spoljašnja Staza, a onda se svaka uloga predstavlja jednom unutrašnjom stazom. U primeru naručivanja, unutar staze Skladištenja i distribucije je ubačena staza koja predstavlja ERP sistem u tom odeljenju.
Ako se modeliraju složeni poslovni procesi, model koji tom prilikom nastaje može biti suviše velik da bi ga bilo lako pratiti. Pogledajmo proces sa slike 12. Iako je u pitanju scenario koji je relativno jednostavan, model veš sadrži 14 aktivnosti, šest kapija i dva događaja. Ako se još dodaju objekti sa podacima i tok poruka, model postaje jo veći. U cilju poboljšanja čitljivosti modela proces se može pojednostaviti ako se, u okviru podprocesa, sakriju pojedini delovi procesa.
Da bi podproces mogao da se koristi potrebno je prvo identifikovati grupu povezanih aktivnosti, odnosno aktivnosti koje zajedno postižu konkretni cilj ili generišu konkretan izlaz. U primeru sa naručivanje, postoje aktivnosti Provera raspoloživosti sirovina i Kupovina sirovina od Snabdevača, koje zajedno čine nabavku materijala. Ove dve aktivnosti i kapije koje ih povezuju, mogu da se izdvoje u podproces. Drugim rečima, ove aktivnosti se mogu posmatrati kao interni koraci makro aktivnosti "Nabavka sirovina". Slično ovom dve paralelne grane za isporuku i fakturisanje narudžbe mogu da se grupišu u okviru jedne aktivnosti (podprocesa) po imenu "Isporuka i fakturisanje". Na slici 13 je prikazan novi model. Ove aktivnosti su na dijagramu predstavljene zaobljenim pravougaonikom koji okružuje interne aktivnosti. U okviru svakog podprocesa su dodati i događaji početka i kraja, čime se eksplicitno označava kada proces počinje i završava.
Pogledajmo primer sa slike 15. U pitanju je model procesa isplate stambenih kredita. Na prvom nivou postoje dva podprocesa. Jedan se koristi za proveru sposobnosti onog ko se prijavljuje i drugi za potpisivanje kredita. Na drugom nivou se zakazivanje isplate kredita unutar procesa potpisivanja izdvaja u poseban podproces.