Na internetu možete pronaći mnoge preglede i rasprave o notacijama za modeliranje poslovnih procesa. Konsultanti i poslovni analitičari vode duge rasprave o tome koju notaciju je najbolje koristiti prilikom modeliranja poslovnih procesa preduzeća. Sa naše tačke gledišta, nema smisla raspravljati o notacijama bez pozivanja na softverski proizvod. Na kraju krajeva, grafički dijagram je samo vrh ledenog brega sva poslovna logika i veze pohranjene su „unutar“ blokova notacije i nisu vidljive na dijagramu.
Na primjer, sada popularna BPMN notacija će zaista otkriti svoje prednosti samo u sprezi sa BPM sistemom koji može „razumjeti“ i „izvršiti“ nacrtani dijagram poslovnog procesa u realnom vremenu. Odnosno, koristeći ovu notaciju možete automatizirati i kontrolirati izvršenje procesa. Ako jednostavno nacrtate proces u BPMN notaciji u Visio-u i sačuvate ga kao sliku, izgubit ćete gotovo sve prednosti ove notacije u odnosu na bilo koju drugu.
Danas su se na tržištu pojavili mnogi softverski proizvodi koji navodno podržavaju nekoliko notacija odjednom, ali činjenica je da je u stvari logika rada ovih programa ista za bilo koju od ovih notacija. U pravilu se odgovornosti i dokumenti dodjeljuju unutar bloka, a zatim, da bi se vizualno ispunili zahtjevi jedne od notacija, dijagramu se mogu dodati grafički blokovi, čije prisustvo ni na koji način ne utječe na funkcionalnost. Odnosno, u suštini gradite dva modela: jedan prema logici programa, a drugi da ispuni zahtjeve notacije, a istovremeno se ovi modeli možda neće poklapati (ono što vidimo ne odgovara šta je sačuvano u bazi podataka).
Ispod je primjer sistema poslovnog modeliranja koji na papiru podržava ARIS eEPC notaciju, ali u stvarnosti je odgovornost dodijeljena funkcijskoj kartici, a grafički blokovi se koriste „za ljepotu“.
Ali nemojmo kritizirati razvoj drugih ljudi, već dosljedno pogledati najpopularnije notacije na tržištu za modeliranje poslovnih procesa, kao i njihovu implementaciju u programu Fox Manager.
Procesi najvišeg nivoa
Najčešći zapisi za izgradnju procesa najvišeg nivoa danas su IDEF0(metodologija funkcionalnog modeliranja) i ARIS VAD(lanac vrijednosti).
U Fox Manager-u se nismo pridržavali strogih zahtjeva bilo koje notacije, već smo jednostavno kreirali dijagram interakcije procesa, koji se sastoji od blokova i strelica i prikazuje veze, kao i ulaze i izlaze procesa u vizualnom grafičkom dijagramu. Prednost našeg pristupa modeliranju procesa najvišeg nivoa je u tome što Fox Manager može automatski generirati takve dijagrame da pogledate kratak video kako bi shvatili kako funkcionira.
Koja je razlika između naše šeme i IDEF0? Prije svega, IDEF0 ima zahtjeve na koju stranu bloka koja strelica treba ići:
- strelica za ulaz uvijek pada na lijevu ivicu aktivnosti
- kontrolna strelica - do gornje ivice
- mehanizam strelica - donja ivica
- izlazna strelica - desna ivica
Da li je ovo važna razlika koja ovoj notaciji daje prednost u odnosu na naš pristup? Sa naše tačke gledišta, ne, ali ako želite, možete shemu interakcije u Fox Manager-u dovesti u striktno usklađivanje sa zahtjevima ove notacije (iznad je originalna šema u IDEF0, ispod je njen analog u Fox Manager-u).
Kao što vidite, ako želite, možete modelirati IDEF0 kola u Fox Manager-u.
IDEF0 notacija ima i druge zahtjeve (koje, međutim, poslovni analitičari obično ne poštuju) - ovo je ograničenje broja blokova na dijagramu (6-8) i princip dominacije (većina važna funkcija treba da bude u gornjem levom uglu). Opet, u našem programu nema prepreka za slaganje blokova po ovom principu.
Što se tiče ARIS VAD notacije, sve je još jednostavnije: dovoljno je izgraditi procese duž lanca vrijednosti i po želji pokazati odgovorne i interakcije.
Na slici je prikazan primjer takvog dijagrama u našem programu (iznad je originalni ARIS VAD dijagram, ispod je njegov analog u Fox Manager-u). Naravno, možete naći grešku u obliku blokova, strelica ili isticanja, ali općenito, nema sumnje da u našem programu, po želji, možete graditi dijagrame u skladu sa zahtjevima ARIS VAD notacije.
Procesi nižeg nivoa
U Fox Manageu koristimo jednostavnu, vizualnu i vrlo fleksibilnu notaciju za modeliranje procesa niskog nivoa. Njegove mogućnosti možete vidjeti iz videa.
Postoje mnoge notacije za modeliranje poslovnih procesa nižeg nivoa: Osnovni dijagram toka, Međufunkcionalni dijagram toka, EPC i drugi. Većina njih ima manje razlike jedna od druge.
Na primjer, ako u programu Fox Manager skupimo blokove odgovornih ljudi, dokumenata i resursa na dijagramu, dobit ćemo analognu notaciju Osnovni dijagram toka(desno je originalni proces, lijevo je analogni u Fox Manager-u).
Ako proširimo sve blokove na dijagramu, onda ćemo dobiti analogni proces u notaciji EPC. Odlična stvar je što kada koristite Fox Manager notaciju, blokovi se mogu sažimati i dinamički proširivati bez potrebe za kreiranjem nove verzije procesa u drugoj notaciji. Slika desno prikazuje originalni proces, a lijevo analogni u Fox Manager-u.
Da, naravno, postoje razlike, na primjer, koristili smo kontrolnu funkciju za prikaz događaja, a također nemamo odvojene blokove "Logički I" i "Logički OR", ali ih je lako zamijeniti drugim blokom ( dijamant) sa slovom “X” ili “V” unutra.
Podrška za notaciju Unakrsni funkcionalni dijagram toka je dodan u program u jednom od naših besplatnih ažuriranja. Ova notacija se razlikuje od zapisa o kojima smo već raspravljali po tome što može prikazati odgovorne u stazama, a ne pored bloka. Nažalost, ova metoda ima svoje nedostatke kada je mnogo odgovornih, proces postaje nejasan i težak za čitanje. Problemi nastaju i kada je potrebno podijeliti odgovornost za funkciju na dvije ili više pozicija odjednom. Ispod je primjer takvog procesa u Fox Manageru.
Što se tiče notacije BPMN, onda smatramo da su njegove mogućnosti suviše suvišne za potrebe opisivanja, analize i regulacije poslovnih procesa. Ova notacija predstavlja oko 100 različitih blokova i njihovih podtipova koji se koriste u automatizaciji procesa, ali su beskorisni za sisteme poslovnog modeliranja koji ne mogu da „izvršavaju“ procese u realnom vremenu, već uzimaju informacije od njih za generisanje regulatornih dokumenata.
Naravno, vjerovatno možemo svesti skup elemenata ove notacije na potrebni minimum i pokušati ga prilagoditi za regulatorne svrhe, ali time ćemo izgubiti njegovu glavnu prednost – mogućnost izvršavanja procesa sa BPM motorom. U isto vrijeme, ako ostavite samo 5-10 potrebnih blokova, tada će, najvjerovatnije, izgled takvih procesa biti vrlo sličan notacijama koje smo već razmotrili.
Zaključak
Vjerujemo da je program Fox Manager odabrao optimalne notacije za modeliranje poslovnih procesa, koje su lako razumljive i visoke funkcionalnosti.
Podrška za notaciju je implementirana na osnovu jezgra programa, ne koristimo Visio ili druge komponente treće strane, tako da je brzina obrade podataka iz ovakvih blok dijagrama vrlo visoka.
Dijagram može prikazati mnogo dodatnih informacija, na primjer, pored naziva funkcije možete prikazati njen tip, učestalost, vrijeme, pa čak i cijenu, koja se izračunava dinamički u realnom vremenu kako se proces završi. Istovremeno, izgled dijagrama se može prilagoditi svakom korisniku pojedinačno.
A u našem uređivaču procesa možete pratiti promjene koje su napravili korisnici i prikazati ih u tabeli ili ih prikazati grafički u dijagramu.
Ako nemate dovoljno standardne funkcionalnosti, tada možete proširiti osnovni skup blokova za modeliranje poslovnih procesa. Na primjer, možete kreirati blokove rizika ili indikatora i prikazati ih na grafičkom dijagramu procesa.
Ali svjesni smo da neki poslovni analitičari ne vjeruju novim razvojima i radije koriste stare oznake koje su im poznate. Svrha ovog članka je pokazati fleksibilnost programa Fox Manager i mogućnost prilagođavanja izgledšeme koje ispunjavaju zahtjeve većine notacija dostupnih na tržištu. Izgradite modele poslovnih procesa onako kako vama odgovara!
Najpopularnija notacija modeliranja poslovnih procesa zasnovana na SADT metodologiji strukturne analize. IDEF0 metodologija je metodologija modeliranja koja vam omogućava da kreirate funkcionalni model koji prikazuje strukturu i funkcije sistema, kao i tokove informacija i materijalnih objekata koji povezuju ove funkcije (slika prikazuje grafički dijagram u IDEF0 notaciji - primjer je implementiran u Business Studio sistemu koji uključuje programske funkcije za izgradnju IDEF0). Poslovni procesi u IDEF0 notaciji predstavljeni su u obliku pravougaonika, a strelice odražavaju odnos sa drugim procesima i spoljašnje okruženje. Karakteristike notacije:
- Sposobnost dekomponovanja procesa na podprocese i na taj način izgradnje hijerarhijskih modela poslovnih procesa;
- Identificiranje četiri tipa strelica: tri vrste ulaza - ulaz, kontrola i mehanizam (ovo vam omogućava da fleksibilnije opišete logiku korištenja ulaza u procesu u svrhu naknadne analize) i izlaz.
IDEF0 notacija se koristi za kreiranje najvišeg nivoa modela poslovnog procesa. Izgradnja IDEF0 dijagrama najvišeg nivoa daje najopštiji ili apstraktniji opis objekta modeliranja. Na nižem nivou, da bi se opisao algoritam (scenarij) za izvršavanje procesa, dozvoljeno je promijeniti IDEF0 standard u Proces, Procedure, EPC ili BPMN 2.0 notaciju.
SADT metodologija se može detaljno pronaći u monografiji “SADT Structural Analysis and Design Methodology” autora Davida A. Marka i Clementa McGowana.
BPMN (Business Process Management Notation) je jezik modeliranja poslovnih procesa koji je posredna karika između formalizacije/vizualizacije i implementacije poslovnog procesa.
Pojednostavljeno rečeno, ova notacija je opis grafičkih elemenata, koji se koristi za izradu dijagrama toka poslovnog procesa.
U najmanju ruku, takva šema je potrebna da bi se poslovni proces izgradio u skladu sa njom i jasno regulisao za sve učesnike.
Maksimalno vam omogućava da naknadno automatizujete poslovne procese u skladu sa postojećom šemom.
Istorija BPMN-a
Prva verzija BPMN notacije objavljena je u maju 2004. (BPMN 1.0). Sledeća verzija se pojavila u januaru 2011. (BPMN 2.0). Konačno, u januaru 2013. OMG je objavio verziju koja se danas najviše koristi - BPMN 2.0.2.Osnovna BPMN grafika
BPMN proces je svaki poslovni proces koji se odražava upotrebom notacije. Procesi se sastoje od elemenata, od kojih je svaki označen na dijagramu posebnom ikonom.Elementi BPMN notacije su elementi grafičkog dijagrama, ali i elementi samog poslovnog procesa.
Zapis se zasniva na sljedećim osnovnim grafičkim elementima:
- Bazen i ulice
- Akcije
- Gateways ili Forks
- Događaji
- Streams
- Artefakti
BPMN elementi “Pool” i “Track”
Cijeli poslovni proces se sastoji od pulova: skup operacija + osobe koje te operacije obavljaju.
Na primjer, skup će biti cijeli skup akcija za učitavanje robe i njeno slanje klijentu.
U ovom slučaju identifikuju se takozvane „trake“, koje čine bilo koji bazen. Na primjer, jedan od kolosijeka će biti priprema dokumenata koji se odnose na utovar i otpremu robe, drugi kolosjek će biti fizički utovar potrebne pošiljke na automobil i odlazak automobila do klijenta. Oba ova puta se međusobno nadopunjuju, odvijaju se paralelno, ali općenito služe za završetak iste faze poslovnog procesa.
BPMN element “Akcija”
„Akcija“ je jedinica rada koja se obavlja tokom izvršavanja poslovnog procesa. Radnje mogu biti ili elementarne (zadatak) ili složene (podproces). Postoji nekoliko vrsta elementarnih radnji koje se razlikuju po uslovima izvršenja:
- Ponovljeno izvršavanje akcije unutar jednog procesa. Na primjer, ista radnja se može izvršiti paralelno za svaku stavku u prodajnom nalogu.
- Ciklična akcija se izvršava više puta sve dok je specificirani uslov istinit.
 |
Apstraktni problem | Koristi se za označavanje jednostavne akcije ili operacije koja nema daljnju dekompoziciju unutar trenutnog poslovnog procesa. |
 |
Podproces | Koristi se za prikaz dekomponovanog procesa uključenog u dotični proces. Potproces je detaljnije opisan u njegovom dijagramu. |
 |
Proces-link | Koristi se za označavanje upućivanja na jedan od procesa koji se najčešće ponavljaju. |
 |
Korisnički zadatak | Koristi se za prikaz zadatka koji osoba obavlja. |
 |
Zadatak izvršavanja skripte | Koristi se za prikaz koraka procesa nakon kojeg se skripta automatski izvršava. |
 |
Zadatak servisnog poziva | Koristi se za ilustraciju koraka procesa u kojem se poziva web usluga ili C# skripta. |
 |
Ugradna kutija | Koristi se za predstavljanje nerutinskog zadatka pod nadzorom odgovorno lice ili grupa ljudi. Slučajevi se koriste kada trebate brzo organizirati nestrukturirane ili polustrukturirane aktivnosti unutar procesa. |
BPMN elementi “Fork” ili “Gateway”
Gateway-i se shvataju kao elementi koji određuju grananje i spajanje radnih tokova.BPMN opisuje 7 tipova viljuški. Postoje 2 glavne vrste:
| Ekskluzivno-ili kapija | Koristi se za kreiranje alternativnih tokova procesa ili konvergentnih kontrolnih tokova. | |
| Parallel Gateway | Koristi se za kreiranje paralelnih staza bez evaluacije bilo kakvog stanja ili za konvergiranje niti i sinkronizaciju paralelnih niti izvođenja procesa. |
Primjer korištenja ekskluzivnog ili kapije za kreiranje alternativnih niti procesa:
- Faza 7. Pozivanje klijenta radi ocjene kvaliteta usluge.
- 1. Ako je klijent zadovoljan, zabilježiti pozitivnu ocjenu, zatvoriti poslovni proces.
- 2. Ukoliko je klijent nezadovoljan, saznajte razlog.
Dalja šema može se uvelike razgranati: ako je klijent nezadovoljan isporukom, onda treba da kontaktira šefa ove službe; a ako se radi o kvaliteti proizvoda, onda će sljedeća faza biti prebacivanje pritužbe na odjel proizvodnje, ili eskalacija (podići hijerarhijski nivo) kako bi se informacija o takvoj pritužbi prenijela višem rukovodstvu. U stvari, gatewayi su jedna od najkritičnijih i najsloženijih faza poslovnih procesa. Efikasnost čitavog sistema u velikoj meri zavisi od toga koliko su kompetentno formulisani svi uslovi i posledice po principu „Ako... onda”.
BPMN element “Događaj”
“Događaj” je jedan od glavnih elemenata BPMN-a i služi za opisivanje nečega što bi se trebalo dogoditi (za razliku od zadatka gdje bi se nešto trebalo uraditi). Događaj može biti, na primjer, potpisivanje ugovora ili razgovor sa klijentom.
Grafika događaja u BPMN-u se klasifikuje na dva načina:
- Ovisno o poziciji događaja na dijagramu procesa:
| Početak događaja (pokretanje poslovnog procesa) | |
| Intermediate event | |
| Završni događaj (završetak poslovnog procesa). |
- Klasifikacija prema vrsti događaja je sljedeća:
| Jednostavan događaj | Predstavlja događaj bez tipa. | |
| Događaj poruke | Označava da li je poruka poslana ili primljena. | |
| Tajmer događaj | Koristi se za modeliranje redovnih događaja. Tajmer se također može koristiti za simulaciju trenutaka u vremenu, vremenskih intervala i prekoračenja vremenskog ograničenja. |
BPMN elementi “Tokovi”
Tok je niz radnji, koji je označen strelicom. Element “flow” pokazuje koju radnju treba izvršiti nakon koje. |
Kontrolni tok | Na standardni kontrolni tok ne utiču uslovi i ne prolazi kroz gatewaye, tj. je nekontrolisano. |
 |
Uslovni kontrolni tok | Koristi se da pokaže da će se dalje izvršavanje procesa dogoditi duž određene niti samo ako je ispunjen određeni uvjet. Romb u osnovi strelice se dodaje ako je tok uslovne kontrole iz procesa. Dijamant se ne dodaje ako je tok uslovne kontrole sa gateway-a. |
| Zadani tok kontrole | Koristi se kada je potrebno pokazati da će se dalje izvršavanje procesa odvijati duž određene niti samo ako nijedan od navedenih uslova nije ispunjen. | |
 |
Tok poruke | Koristi se za prikaz međuprocesne komunikacije - prikazuje prijenos poruka ili objekata iz jednog procesa u drugi proces ili eksternu referencu. |
 |
Udruženje | Koristi se za vizualizaciju odnosa između elemenata toka i objekata koji nisu elementi toka (artefakti). |
BPMN elementi “Artefakt”
U BPMN, artefakti se shvataju kao objekti koji ne utiču direktno na izvršenje poslovnog procesa. To mogu biti dokumenti, podaci, informacije.Glavne vrste artefakata:
 |
Grupa objekata | Koristi se za grupisanje grafičkih elemenata koji pripadaju istoj kategoriji i olakšavaju čitanje dijagrama. |
 |
Tekst napomena | Koristi se za pojašnjenja dijagrama - komentare i objašnjenja koja će povećati čitljivost dijagrama. |
| Objekat podataka | Koristi se za prikaz informacija o podacima koji se obrađuju tokom procesa. |
Prednosti BPMN-a
BPMN opis poslovnog procesa ima nekoliko prednosti.Prvi je jednostavnost prevođenja dijagrama u izvršne modele koristeći jezik za formalni opis poslovnih procesa.
Opis BPMN elemenata je jasan većini učesnika u poslovnim procesima i često ne zahteva dodatno objašnjenje. Koristeći jednostavan grafički izraz, možete kreirati specifične propise koje će se zaposleni pridržavati.
Uz činjenicu da opis BPMN 2.0 notacije omogućava zaposlenima da shvate kako se odvijaju poslovni procesi, ova notacija je podržana od strane većine savremenih alata za poslovno modeliranje, što omogućava uvoz gotovih dijagrama poslovnih procesa u BPM sisteme.
Elena Gaidukova, marketinški analitičar, brend menadžer rješenja zasnovanih na , specijalista za partnerske odnose.
Besplatan BPMN alat
Cawemo je besplatni online alat za razvoj, diskusiju i dijeljenje BPMN dijagrama sa vašim timom.
Besplatan BPMN alatPregled
Učili smo BPMN hiljadama ljudi i koristimo notaciju u svakodnevnom radu projektni rad od 2007. Ispod možete pronaći mnoge BPMN primjere uobičajenih problema modeliranja. Bez obzira na vaše konkretan projekat ili vaša industrija, ima ih mnogo opšta pitanja o korištenju BPMN-a. Prema našem iskustvu, većina BPMN primjera u nastavku je korisna za svakog korisnika BPMN-a.
Pridružili smo se OMG-u 2009. godine kao uticajni član. Od tada smo uključeni u razvoj BPMN 2.0.
BPMN primjeri
Poslovna pravila i BPMN
Scenario simulacije
Recimo da želimo modelirati proces u BPMN-u i proces poziva neka poslovna pravila. Koristićemo primjer kreiranja računa. Da biste kreirali fakturu, potrebno je da izračunate popust. Iznos narudžbe i tip kupca su relevantni kriteriji za izračunavanje popusta.
Ovo je vrlo jednostavan primjer koji će nam pokazati gdje koristiti BPMN, a gdje ne.
Uloge motora Kreiraj fakturu Zatraži fakturu Izračunaj popust Kreiraj fakturu Faktura je kreirana
Objašnjenje
Tokom simulacije fokusiramo se na tok procesa. U ovom primjeru, proces ima dva koraka. Popust se obračunava prije kreiranja računa. Rezultat je vrlo jednostavan proces.
Nema smisla modelirati izračun samog popusta u BPMN modelu (pogledajte primjer ispod). Za stablo odlučivanja pravila, za svaki dodatni kriterij, moći će rasti eksponencijalno. Ovo nije ono što želimo u BPMN modelu.
Stoga ima smisla razdvojiti procese i poslovna pravila.
Kreirajte fakturu Napravite 2% popusta Dodajte 1% popusta Ko je kupac?< 500 Тип A Тип A Тип A обычный обычный обычный
Iznos zahtjeva za fakturom?
Vrsta kupca?
Kreirajte fakturu Faktura je kreirana Napravite popust od 3% Napravite popust od 4% Ko je kupac?
dodaj 1% popusta dodaj 1% popusta 1000 - 1500 500 - 999 >2000
Zavisne instance
Scenario simulacije
Recimo da želimo modelirati proces sa odgovarajućim instancama. Koristit ćemo jednostavan primjer. Ako se vrši jedna provjera kreditne sposobnosti klijenta, ne želimo da se u isto vrijeme izvrši još jedna provjera kreditne sposobnosti za istog klijenta.
Razlog može biti taj što ukupan broj izvršenih provjera kreditne sposobnosti utiče na ishod provjere.
Objašnjenje
Recimo da vršimo provjeru kreditne sposobnosti za kupca i da u isto vrijeme primimo drugi zahtjev za istog kupca.
Ono što je zajedničko svim rješenjima je da svaka nova instanca mora provjeriti podudaranje instance na razini podataka prije nego počne stvarna provjera kreditne sposobnosti.
Rješenje signalnog događaja
Objašnjenje
Provjera kreditne sposobnosti Pogledajte upite Pogledajte pokrenute događaje (sa njima) pokrenute instance istog klijenta?
i isti klijent?
Provjera kreditne sposobnosti Provjera završena Provjera završena Zabilježeno u bazi podataka ne da
Objašnjenje
U ovom primjeru, nije nam potrebna veza između instanci. Instanca sama provjerava učestalost da li može nastaviti s provjerom kreditne sposobnosti. Loša strana je što ovo može uzrokovati kašnjenja i prekomjerne troškove zbog petlje.
Princip četiri oka
Vrsta kupca?
Želimo modelirati sljedeću situaciju koristeći BPMN 2.0. Zahtjev (na primjer, plaćanje) zahtijeva dvije dozvole od dvije različiti ljudi. Procesni mehanizam mora osigurati da su oba odobrenja zadovoljena prije nego što se zahtjev odobri. Ručne korake koje izvode dva odobravatelja također treba modelirati u BPMN dijagramu. Odluka o odobrenju se donosi pomoću portala liste zadataka.
Slučajevi upotrebe
Slučajevi upotrebe ovog predloška su brojni. Evo nekoliko primjera:
- Odobrenje plaćanja
- Odobrenje fakture
- Odobrenje ugovora
Rješenje kao BPMN 2.0 dijagram
1. odobrenje Zatraženo odobrenje Ocijenite zahtjev pročitajte i komentirajte Zadatak završen Procesi u motoru Potvrdite zahtjev potvrdite ili se složite (1. red) Potvrđeno?
Objašnjenje
Zahtjev odbijen (1. red) odbiti ili potvrditi (2. red) Potvrđeno?
Zahtjev odbijen (2. red) Zahtjev je potvrđen. 2. odobravatelj potvrđuje stopu zahtjeva Zahtjev pročitati i komentirati zadatak je završen ne da da ne
Koristimo odvojene grupe za Process Engine, za prvog odobravatelja i za drugog odobravatelja. Na taj način možemo jasno definirati ko kontrolira koji proces.
Grupa motora koristi prilagođene zadatke. Ovi prilagođeni zadaci odgovaraju zadacima koji su prikazani na 1. i 2. listi zadataka odobravatelja.
Interakcija između korisničkih zadataka u mašini i između ručnog procesa odobravatelja je modelirana korištenjem tokova poruka. Ovi tokovi poruka obuhvataju korake dokumentacije koje assertor mora završiti da bi dovršio korisnički zadatak.
Sama lista zadataka nije modelirana da smanji složenost.
Varijacije
Odobrenje kao srušeni bazeni
1. odobrenje za potvrdu zahtjeva za procjenu zahtjeva za čitanje i komentiranje Zadatak je završen LDAP Procesni mehanizam potvrdi zahtjev odbaci ili potvrdi (1. red) Potvrđeno?
Zahtjev odbijen (1. red) odbiti ili potvrditi (2. red) Potvrđeno?
Vrsta kupca?
Zahtjev odbijen (2. red) Zahtjev potvrđen utvrditi 1. i 2. odobravatelja 2. odobravatelj potvrditi stopu zahtjeva Zahtjev pročitati i komentirati zadatak je završen ne da da ne
Mjesečni obračun
Rješenje kao BPMN 2.0 dijagram
Ovaj primjer objašnjava vrlo čestu borbu sa strukturiranjem BPMN 2.0 dijagrama. Recimo da postoji advokat koji svojim klijentima nudi pravne savjete. Usluga funkcionira na sljedeći način: klijenti mogu tražiti pravni savjet kad god im zatreba. Advokat daje traženi savjet i stavlja naplative sate u radni list klijenta. Kada se mjesec završi, CPA utvrđuje naplative sate na osnovu rasporeda i kreira fakturu.
Objašnjenje
Ovaj primjer ilustruje vrlo opći scenario modeliranja. Nisu složeni koraci procesa, već struktura dijagrama. Advokat Konsultacija Zahtjev za konsultaciju Pružanje savjeta Vrijeme registracije Zahtjev obrađen Brojilo klijenata Klijent Zabilježite mjesečni prihod 1. dan u mjesecu Odredite sate naplate kreirajte i pošaljite fakturu primite novac Faktura završena 14 dana Pošalji podsjetnik Samo jedan mjesečno Nekoliko mjesečno Većina
važan aspekt
dijagrama je njegova struktura.
Proces pružanja pravnih savjeta odvija se više puta mjesečno. Proces mjesečnog obračuna se izvodi samo jednom mjesečno. Stoga se ova dva procesa moraju modelirati kao odvojeni skupovi.
Naravno, ova dva bazena nisu potpuno neovisna jedan od drugog. Za šta? Rade na istim podacima - vremenskom listu klijenta. Naša sposobnost da modeliramo takvu povezanost vezanu za podatke je vrlo ograničena u BPMN-u. To je zato što je BPMN orijentiran na tok kontrole, a ne na protok podataka.
Međutim, možemo koristiti element skladišta podataka za modeliranje ove veze na razini podataka.
Objašnjenje zašto je ovo pogrešno
U ovom primjeru, oba procesa su pomiješana u jedan. Ovo je - u najboljem slučaju - vrlo implicitan način modeliranja. To bi značilo da bi se za svaki pruženi pravni savjet jednom mjesečno slala faktura. Ova metoda modeliranja je u većini slučajeva netačna.
Dodatne informacije potrebne nakon korisničkog zadatka
Vrsta kupca?
Recimo da želimo modelirati sljedeći scenarij: Želimo izvršiti prilagođeni zadatak koji izvodi korisnik na portalu. Nakon što završite korisnički zadatak, možda ćete morati dodatne informacije. U tom slučaju, procesni procesor šalje zahtjev za informacijama drugom korisniku (rješenje 1) ili tehničkoj službi (rješenje 2).
Rješenje 1: Zatražite informacije od drugog korisnika
Korisnik je prijavljen Korisnik je prijavljen Procesni mehanizam Zadatak za korisnika Potrebne su dodatne informacije.
informacije? Zatražite informacije (od korisnika) ... ne da
Rješenje 2: Zatražite informacije od tehničke službe
Korisnik se prijavio na Neki mehanizam procesa tehničke usluge Zadatak za korisnika Treba dodatno.
informacije? Pošaljite upit Informacije primljene... ne da
Obrada serije narudžbi sa tržišta SituacijaŽelimo modelirati sljedeći scenario koristeći BPMN 2.0: Pretpostavimo da kompanija prima narudžbe od
Rješenje kao BPMN 2.0 dijagram
različitim kanalima distribucija. Jedan od tih kanala je tržište. U određenim intervalima, narudžbe sa tržišta se primaju u serijama. Svaka narudžba u ovoj seriji mora biti verificirana prije ulaska u ERP sistem. Tržište ERP sistema Uvoz naloga u ERP Svakih 10 minuta Sakupi sve narudžbe sa tržišta Proces narudžbe Nova pojedinačna narudžba Provjeri podatke o narudžbi Jesu li podaci tačni?
Objašnjenje
Uvezite narudžbu u
ERP sistem
Vrsta kupca?
Recimo da moramo biti sigurni da je određeni korisnički zadatak definitivno završen. Stoga se korisnički zadaci moraju preraspodijeliti čim je trenutni nositelj nedostupan, na primjer zbog godišnjeg odmora ili bolesti.
Rješenje 1: Usluga razmjene poruka i preusmjeravanje
Napomena
Ovo ima smisla ako motor pozove servis da odredi novog primaoca.
Rješenje 2: Pravila prosljeđivanja poruka i pravila preusmjeravanja
Korisnik se prijavio. Procesni mehanizam određuje nositelja zadatka korisnika... primalac nije dostupan
Napomena
Ovo ima smisla ako mehanizam poziva mehanizam pravila da odredi novog primaoca.
Rješenje 3: Događaj granice poruke i implicitno preusmjeravanje
Korisnik je prijavljen. Korisnički zadatak procesorskog mehanizma... dodijeljen je nedostupan
Napomena
Ovo ima smisla ako motor određuje najnovijeg primatelja, na primjer koristeći izraz.
Dvostepena eskalacija
Vrsta kupca?
Koristit ćemo sljedeći primjer da ilustriramo kako modelirati eskalaciju u dva koraka koristeći BPMN 2.0. Kada želimo pizzu, naručimo je. Ponekad dostava pice traje duže i traje više od 20 minuta. Zatim se žalimo na uslugu dostave. Nakon toga dajemo im još 30 minuta da dostave pizzu. Ako to ne urade na vrijeme, mi ćemo odbiti i otkazati našu narudžbu.
Rješenje 1: Dva prolaza zasnovana na događajima
Traže se pica Naručite picu Pizzu isporučena Pojedite picu Pizza pojedena 30 minuta Žalba na dostavu Pizza isporučena 20 minuta Narudžba otkazana Narudžba je otkazana
Prednosti ovog rješenja
Ovo rješenje vrlo jasno pokazuje kako funkcionira eskalacija u dva koraka. Tajmeri se modeliraju zasebno, a zatim i njihove odgovarajuće akcije eskalacije.
Nedostaci ovog rješenja
Gateway zasnovan na događajima nije intuitivan BPMN simbol BPMN standarda, potrebno je iskustvo.
Korištenje dva pristupnika zasnovana na događajima čini model većim i rezultira duplom porukom o Pizza događaju.
Rješenje 2: Prihvatite posao s uključenim tajmerima
Traži se pizza Naruči pizzu Pojedi pizzu Pizza pojedena Žalba službi dostave Narudžba je otkazana Narudžba je otkazana Čekaj pizzu Žalba na narudžbu 50 minuta 30 minuta
Prednosti ovog rješenja
Ovaj model je manji od prvog rješenja i vjerovatno je način na koji će većina programera riješiti problem u motoru. Budući da koristimo neprekidni priloženi događaj tajmera, ovo rješenje je fleksibilnije kada se bavimo višestrukim pritužbama (na primjer, želimo se žaliti svakih 5 minuta dok ne istekne 50 minuta).
Nedostaci ovog rješenja
Zadatak primanja obično nije intuitivan za "poslovne momke" koji bi radije koristili događaje primanja poruka za takvo stanje čekanja.
Način rada tajmera za prekid i bez prekida zahtijeva duboko razumijevanje pridruženih događaja.
Rešenje 3: Jedan gateway zasnovan na događajima sa zajedničkim tajmerom
Tražena pizza Naručite pizzu Pizzu isporučena Jedite pizzu Jedite pizzu Vrijeme je isteklo!
Prednosti ovog rješenja
Žalba na isporuku Narudžba je otkazana Narudžba je otkazana Da li je zadatak završen?
Nedostaci ovog rješenja
Tajmer je pokazao više da ne
Ovaj model pruža kompaktno i općenito rješenje problema. Ako govorite o eskalaciji u n koraka, trebat će vam ovaj opći pristup kako biste izbjegli ogromne grafikone.
Opšte rješenje je manje očigledno od ostalih rješenja. Ne vidimo stvarno trajanje tajmera jer se isti tajmer koristi za oba trajanja.
Ova metoda modeliranja nije prikladna za brzo razumijevanje dvostepene eskalacije.
BPMN stilovi modeliranja Pokušajte izbjegavati prelazak potoka što je više moguće. Ovo će povećati razumijevanje modela BPMN procesa - i za iskusne i za neiskusne BPMN korisnike. Naravno, nije uvijek moguće u potpunosti izbjeći ovaj problem. Imajte na umu da uvijek ima smisla uložiti nešto
dodatno vrijeme
u optimizaciji rasporeda tako da se eliminiše većina tokova koji se ukrštaju.
Primjeri u nastavku ilustriraju problem apstraktnim primjerom.
Dobar primjer rukovanja nitima
Započet proces izvođenje prvog zadatka Potrebna radnja?
završiti zadatak dva Proces završen izvršiti zadatak tri ok?
da Plan A Plan B br
Sam proces (pool) također mora uvijek biti označen. Ova oznaka mora naznačiti ime procesa i ulogu koja ga pokreće.
Zadaci moraju biti označeni objektom + glagolom. Ovo prisiljava osobu za uzor da se fokusira na ono što se zapravo radi tokom zadatka.
X-OR pristupnici moraju biti označeni pitanjem. Odlazni tokovi sekvenci moraju biti označeni mogućim odgovorima na ova pitanja (uslove).
Dobar primjer imenovanja
Provjerite datum narudžbe. Narudžba Usluga Primljena narudžba Provjerite narudžbu Provjerite narudžbu Da li je datum narudžbe tačan Da li je datum narudžbe tačan?
Datum narudžbe je netačan da ne
Opća verzija
Naziv procesa Uloga koja izvršava proces Okidač procesa Objekt + glagol Objekt + Particip Prvo krajnje stanje nakon završetka procesa Pitanja?
Drugo konačno stanje nakon završetka procesa odgovor 1 odgovor 2
Kontra primjer
Narudžbina postavljena Početak Provjera Upišite status u bazu podataka Kraj Greška Ok
Ovaj BPMN primjer govori o kreiranju dobrog izgleda modela procesa. Što je bolji raspored, to je veći stepen razumijevanja. To je ono što želimo postići kada kreiramo modele procesa.
Utvrdili smo da simetrične strukture povećavaju razumijevanje modela BPMN procesa - i za iskusne i za neiskusne BPMN korisnike.
Dobar primjer rukovanja nitima
Dobar primjer simetričnog modela
Pripremite salatu Osjetite glad Odaberite recept Koje jelo?
Kuvajte testeninu Jedite hranu Glad je zadovoljena Skuvajte odrezak Koji su sastojci?
Odaberite: - Salata - Tjestenina - Odrezak Odrezak Tjestenina Salata Topla hrana
Pripremite salatu Glad se pojavila Odaberite recept Koje jelo?
Kuvajte testeninu Jedite hranu Glad je zadovoljena Skuvajte odrezak Koji su sastojci?
Odaberite: - Salata - Tjestenina - Odrezak Odrezak Tjestenina Salata topla hrana
Dobar primjer simetričnog uzorka 2
Ovu zabunu možete lako izbjeći korištenjem istih veličina zadataka.
Dobar primjer jednakih veličina zadataka
Zadatak za čitanje zahtjeva za stopom zahtjeva za potvrdom i komentarom je završen
Dobar primjer rukovanja nitima
1. odobravatelj Potvrdi zahtjev Zahtjev napravljen dokument i komentar obrisani zadatak je završen
AS-IS model ili model “kao što je” je model poslovnih procesa u vrijeme istraživanja poduzeća i izgrađen je s ciljem razumijevanja kako dato preduzeće funkcionira iz perspektive analiza sistema. Ovaj model je izgrađen sa ciljem da se identifikuju greške i uska grla, kao i da se formulišu prijedlozi za poboljšanje situacije.
U drugom poglavlju ove radionice, proučavajući metodologije i tehnologije projektovanja, već smo izgradili model ovog poslovnog procesa. Stoga ćemo u ovom dijelu priručnika samo pojasniti ovaj model koristeći informacije dobijene tokom procesa prikupljanja.
Kontekstni model:
Naslov: Realizacija gotovih proizvoda iz skladišta.
Cilj: Povećati prodaju.
Tačka gledišta: Šef odjela prodaje.
Ulazni podaci: kopija računa, kopija ugovora, narudžba.
Izlazni podaci: zahtjev, faktura, izvod iz dnevnika, izvještaj, odbijanje ispunjenja naloga.
Menadžment: asortiman zatvarača, trenutna cijena zatvarača, statut preduzeća, propisi o odjelu prodaje.
Mehanizmi: djelatnik odjela prodaje.
Kontekstni model je predstavljen na slici 18.
Slika 18. Kontekst dijagram
Prijeđimo na konstruiranje dijagrama dekompozicije. Nakon obrade upitnika možemo identifikovati glavne funkcije: provjera spremnosti narudžbe, organiziranje plaćanja, organizacija isporuke, priprema izvještaja. Dijagram dekompozicije je prikazan na slici 19.
Slika 19. Dijagram dekompozicije
Hajde da analiziramo intervju i pogledamo stvarnu tehnologiju rada prodajnog djelatnika. Na osnovu ovih podataka glavne funkcije se mogu dekomponovati. Glavna funkcija “Provjera spremnosti narudžbe” može se razložiti na sljedeće radnje: odabir ugovora za tekući datum, prihvatanje narudžbi za tekući datum, usaglašavanje sa evidencijom gotovih proizvoda. Dekompozicija je prikazana na slici 20.
Glavna funkcija “Organizacija plaćanja” može se razložiti na sljedeće radnje: obračun iznosa plaćanja, izdavanje računa, plaćanje računa. Glavnu funkciju „Organizacija izdavanja“ dekomponujemo na sledeći način: izdavanje zahteva, obaveštavanje skladišta o pripremi robe, priprema izvoda za odeljenje ugovora, promena dnevnika prodaje. Glavnu funkciju „Priprema izveštaja“ dekomponujemo na sledeće radnje: analiza podataka, uzorkovanje podataka, štampanje izveštaja. Odgovarajući dijagrami su prikazani na slikama 21, 22, 23.
Fig.20. Dijagram dekompozicije A1
Fig.21. Dijagram razlaganja A2
Fig.22. Dijagram dekompozicije A3
Fig.23. Dijagram razlaganja A4
Budući da dizajneri imaju za cilj automatizaciju toka dokumenata, prije dekomponiranja procesa, ima smisla razmotriti model toka dokumenata. U ovom slučaju, možete ići na dva načina: razmotriti poseban model toka dokumenata i dekomponirati pojedinačne poslovne procese konstruiranjem DFD dijagrama.
⇐ Prethodno567891011121314Sljedeće ⇒
Povezane informacije:
Pretražite na stranici:
ARIS Value Added Chain Diagram (ARIS VAD) notacija
Na sl. 2.30 predstavlja jednu od najvažnijih ARIS notacija - ARIS VAD notaciju. Dijagram lanca procesa dodavanja vrijednosti koristi se za opisivanje poslovnih procesa organizacije na najvišem nivou. Po pravilu, konsultanti koji koriste ARIS preporučuju identifikaciju šest do osam poslovnih procesa najvišeg nivoa i njihovo opisivanje u ARIS VAD notaciji. Zatim se rezultujući procesi najvišeg nivoa dekomponuju u ARIS VAD ili ARIS eEPC notaciji.
Modeli AS-IS i TO-BE
Razmotrimo objekte ARIS VAD notacije prikazane na Sl. 2.30.
Glavni objekt notacije ARIS VAD je lanac dodane vrijednosti – proces ili neka grupa organizacijskih funkcija koja služi za dobijanje dodane vrijednosti. Objekti su međusobno povezani isprekidanom strelicom koja ima tip prethodnika („je prethodnik“). Ova vrsta komunikacije pokazuje da je jedan proces prethodnik drugog. Očigledno je, međutim, da su u praksi svi osnovni procesi ciklični. Osim toga, imaju linkove za povratne informacije. Stoga je termin prethodnik, po našem mišljenju, nesretan.
Između procesa prikazanih na sl. 2.30, streamovi se mogu prikazati materijalna sredstva i informacije, za čije opise možete koristiti objekte tipa Klaster i Tehnički termin. Za opis infrastrukture potrebne za izvršavanje procesa, u ovom primjeru su odabrani tipovi objekata Proizvod/Usluga i Informacijski servis. Izbor tipova objekata za prikaz stvarnih tokova je prilično proizvoljan. Vrlo je važno na početku rada na modeliranju procesa odlučiti koje vrste objekata će se koristiti i koje će objekte iz stvarnog svijeta predstavljati. Dakle, u slučaju primjera prikazanog na sl. 2.30, bilo bi moguće prikazati sve tokove (informacije i materijal) koristeći objekte tipa Tehnički termin.
Na sl. Slika 2.30 također prikazuje objekte organizacione jedinice, prikazujući jedinice koje obavljaju odgovarajuće procese.
Objekti su međusobno povezani pomoću veza određenog tipa (vidi sliku 2.30). Na primjer, tok informacija prikazan objektom Cluster ulazi se u prvi proces i pridružuje mu se pomoću strelice tipa je ulaz za. Drugi primjer je tip veze izvršava između lanca dodane vrijednosti i objekata organizacijske jedinice. Tip odnosa koji se koristi označava da proizvod/uslugu koristi proces itd. Dakle, u metodologiji ARIS najvažniji je zahtjev pravilan odabir i daljnja upotreba veza i objekata određenog tipa.
Na sl. Slika 2.31 prikazuje primjer modela najvišeg nivoa, koji se izvodi u ARIS VAD notaciji. Već ste upoznati sa ovim procesom. Gore, na sl. 2.16, isti proces je predstavljen u IDEF0 notaciji.
88__________________________ BB. Repin, V.G. Eliferov
Poglavlje 2 Izbor metodologije za opisivanje poslovnih procesa________________________________ 89
Principi konstruisanja dijagrama procesa najvišeg nivoa u ARIS VAD notaciji značajno se razlikuju od IDEF0 notacije. Dakle. u ARIS VAD notaciji, strelice mogu ići na bilo koju stranu objekta lanca dodane vrijednosti. (Podsjetite se da u IDEF0 notaciji, svaka strana objekta (funkcije) aktivnosti ima dubinu i značenje). Na sl. Slika 2.32 predstavlja moguću situaciju u ARIS VAD notaciji. kada dijagram procesa pokazuje mnogo povratne informacije, koji su razumljivi samo analitičaru koji je kreirao model.
Ovaj nedostatak ARIS VAD notacije može se eliminisati ako se unaprijed odredi mogućnost posebne upotrebe povratnih veza, kao što je, na primjer, na sl. 2.33. Imajte na umu da ovaj pristup može izazvati kritike među stručnjacima ARIS-a, jer je u suprotnosti s notacijom. Ali mi se držimo gledišta da je to sasvim prihvatljivo, budući da se modeli najvišeg nivoa u ARIS VAD notaciji zaista mogu koristiti samo kao najjednostavniji način da se grafički prikaže procesni lanac.
Završavajući osvrt na ARIS VAD notaciju, još jednom ističemo da je ova notacija u velikoj mjeri ilustrativna i nije namijenjena kreiranju složenih modela procesa na najvišem nivou organizacije.
90 V.V. Repin, V.G. Eliferov. Procesni pristup menadžmentu
2.7.2. ARIS eEPC notacija - proširenje IDEF3 notacije
ARIS eEPC notacija (prošireni lanac procesa vođen događajima) je prošireni lanac procesa vođen događajima.
Oznaku su razvili stručnjaci iz IDS Scheer AG, Njemačka, posebno profesor Scheer. U tabeli 2.2 prikazuje glavne objekte koji se koriste u notaciji.
Tabela 2.2 Glavni objekti koji se koriste u izgradnji eEPC dijagrama
Pored glavnih objekata navedenih u tabeli. 2.2, mnogi drugi objekti se mogu koristiti prilikom konstruisanja eEPC dijagrama. U praksi je korištenje velikog broja objekata različitih tipova nepraktično, jer to značajno povećava veličinu modela i otežava čitanje.
91
Da biste razumeli značenje ARJS cEPC notacije, razmotrite glavne tipove objekata i relacija koje se koriste (sl. 2.34-2.38). Na sl. Slika 2.34 predstavlja najjednostavniji ARIS eERS model, koji opisuje fragment poslovnog procesa preduzeća.
Od sl. Slika 2.34 pokazuje da veze između objekata imaju određeno značenje i odražavaju slijed funkcija unutar procesa. Strelica koja povezuje Događaj 1 i Funkciju 1 „aktivira“ ili inicira izvršenje Funkcije 1. Funkcija 1 „kreira“ Događaj 2, praćen simbolom Bulovog operatora „AND“, „pokreće“ izvršenje Funkcija 2 i 3.
Pažljiva analiza ARIS eEPC notacije pokazuje da se ona praktično ne razlikuje od IDEF3 notacije. Najvažnija razlika između ARIS eEPC-a je prisustvo „događajnog“ objekta. Ovaj objekt se koristi za prikaz u modelu mogućih rezultata izvršavanja funkcija, ovisno o tome koja se jedna ili druga naredna grana procesa izvršava. ARIS eEPC notacija se očigledno naziva proširenom upravo zbog prisustva objekta „događaja“ u njoj (u IDEF3 takvog objekta nema). Na sl. 2.35 daje primjere upotrebe logike i simbola događaja prilikom izgradnje modela u ARIS eEPC notaciji.
Prilikom izrade modela u ARIS eERS-u, moraju se poštovati sljedeća pravila:
1. Svaka funkcija mora biti pokrenuta događajem i prekinuta
događaj;
2. Svaka funkcija ne može uključivati više od jedne strelice, „Pokrećem
"shchi" njegovo izvršenje, i ne bi trebalo biti više od jedne strelice koja opisuje
završetak funkcije.
Osim ovih pravila, postoje i druga važnih zahtjeva do formiranja modela u ARIS-u. Mogu se proučavati koristeći metodološki materijal"ARIS metode". koji se instalira na računar istovremeno sa demo verzijom proizvoda, kao i u .
Na sl. Slika 2.36 prikazuje upotrebu različitih objekata ARIS eEPC notacije prilikom kreiranja modela poslovnog procesa.
92____________________________ BB. Repin, V.G. Eliferov.Procesni pristup menadžmentu
Od sl. 2.35 i 2.36 jasno je da je poslovni proces u ARIS eEPC notaciji niz procedura raspoređenih po redosledu njihovog izvršavanja. Treba napomenuti da se stvarno trajanje procedura u ARIS eERS-u ne može vizuelno odraziti. To dovodi do činjenice da su prilikom kreiranja modela moguće situacije kada će jednom izvođaču biti povjerena odgovornost za
Poglavlje 2 Odabir metodologije za opisivanje poslovnih procesa_______________________________________ 93
obavljanje dva zadatka u isto vrijeme. Logika korišćena u konstruisanju SIM-YULA modela omogućava nam da prikažemo grananje i spajanje poslovnog procesa. Da biste dobili informacije o stvarnom trajanju procesa i vizuelno prikazali opterećenje osoblja u procesu, možete koristiti druge alate za opis, na primjer, Ganttov grafikon u sistemu MS Project.
Pogledajmo primjere korištenja ARIS eEPC notacije za opisivanje poslovnih procesa. Na sl. 2.37. Prikazan je poslovni proces obrade narudžbe kupca. Isti proces je prikazan u IDEF3 notaciji na Sl. 2.23.
Proces počinje događajem „Narudžba kupca primljena“. Ovaj događaj pokreće funkciju „Pošalji narudžbu u sistem“, koju obavlja menadžer odjela prodaje. On koristi „Sistem obračuna naloga“ da završi posao. Rezultat izvršenja funkcije prikazuje se događajem “Obračun naloga je završen”. Nakon toga, rukovodilac odjela prodaje obavlja funkciju „Izvrši analizu usklađenosti proizvoda“. Rezultat izvršavanja funkcije su dva alternativna događaja: “Narudžba odgovara artiklu” i “Narudžba ne odgovara artiklu”. Proces se grana. Za prikaz grananja procesa koristi se simbol logičkog operatora - ekskluzivno "ILI".
Funkcija „Obavesti kupca da se narudžbina ne može ispuniti“ može se izvršiti u dva slučaja: 1) narudžba ne odgovara artiklu i 2) proizvodnja je nemoguća. Za prikaz ovih opcija na dijagramu procesa, koristi se simbol logičkog operatora “ILI” itd.
Kao što se može videti sa sl. 2.37, dijagram procesa u ARIS eERS-u razlikuje se od dijagrama u IDEF3 po prisutnosti objekata: događaja, dokumenata, aplikacijskih sistema i pozicija. Dijagram u ARIS eEPS vizualno je informativniji i bolje se percipira, ali je veličina ovog dijagrama znatno veća od veličine IDEF3 dijagrama.
Proces o kome se gore govori takođe može biti predstavljen u ARIS PCD (Process Chain Diagram) notaciji – varijaciji ARIS eEPC. Na sl. Slika 2.38 prikazuje poslovni proces obrade klijentove aplikacije u ARIS PCD notaciji. Pri opisu ovog procesa koriste se svi objekti koji čine proces prikazan na slici 1. 2.37, ali su raspoređeni u obliku kolona tabele. Prvi stupac predstavlja događaje i neke logičke simbole, drugi - funkcije, treći - dolazni i odlazni dokumenti, četvrti - vrste primijenjenih softver, u petom - pozicije zaposlenih uključenih u proces. Ovakav prikaz procesa je više „standardan“. Pogodniji je za potrebe dokumentacije procesa. Međutim, predstavljanje u ARIS PCD notaciji ima značajan nedostatak - može se efikasno koristiti za jednostavne (ne više od pet do osam funkcija), po mogućnosti linearne, procese. Nezgodno je prikazati složene procese sa razgranatom logikom koristeći ARIS PCD notacije, kao što se jasno vidi na Sl. 2.38.
94_________________________________ BB. Repin. V.G. Eliferov. Procesni pristup menadžmentu
Rice. 2.37. Primjer modela procesa
Poglavlje 2 Izbor metodologije za opisivanje poslovnih procesa________________________________ 95
u AR1S eEPC notaciji.
96____________________________ V.V., Repin, V.G. Eliferov.Procenat SUŠTINSKI PRISTUP UPRAVLJANJU
Rice. 2.38. Primjer obrade
Poglavlje 2 Izbor metodologije za opisivanje poslovnih procesa 9 7
AR1S PCD aplikacije i notacije.
98 V.V. Repin, U G. Eliferov Procesni pristup menadžmentu
AR1S notacija organizacione šeme
ARIS Organizacijski Chan notacija je jedna od glavnih ARIS notacija i namijenjena je za izradu dijagrama organizaciona struktura preduzeća. Obično se ovaj model gradi na početku projekta modeliranja poslovnog procesa. Model odražava postojeće podjele preduzeća u obliku hijerarhijske strukture, kao što je prikazano na Sl.
Model se gradi od objekata Organizaciona jedinica, Pozicija, Interno lice itd.
Tipovi veza uključeni u notaciju vam omogućavaju da razmislite razne vrste odnosi između objekata organizacione strukture. U onom prikazanom na sl. U primjeru 2.39, preduzećem upravlja direktor, a tip veze je Upravitelj organizacije za. Hijerarhija odjela je izgrađena korištenjem odnosa tipa je sastavljena od. Pored toga, mogu se naznačiti pozicije - Pozicija i imena stvarnih zaposlenih koji ih zauzimaju - Interno lice, vrsta veze koju zauzima.
Pored modela hijerarhije odjela, mogu se graditi i modeli hijerarhije subordinacije u projektnim timovima, grupama i sl. Svi objekti prikazani u modelima mogu se koristiti u budućnosti prilikom kreiranja modela poslovnih procesa. Prilikom konstruisanja složenih hijerarhijskih struktura može se koristiti dekompozicija, na primjer, struktura odjela može se predstaviti detaljnije.
Poglavlje 2 Izbor metodologije za opisivanje poslovnih procesa_________________________________ 99
Prethodna78910111213141516171819202122Sljedeća
Model AS-IS– ovo je model „kao što jeste“, tj. model već postojećeg procesa/funkcije. Istraživanja procesa su suštinski dio svakog projekta stvaranja ili razvoja sistema. Izgradnja funkcionalni model AS-IS vam omogućava da jasno zabilježite koji se procesi provode u preduzeću, koji informacijski objekti se koriste prilikom obavljanja funkcija na različitim nivoima detalja.
Na osnovu modela AS-IS Postiže se konsenzus između različitih faza procesa o tome „ko je šta uradio“ i šta svaka faza dodaje procesu. AS-IS funkcionalni model je polazna tačkaanalizirati potrebe preduzeća, identifikovanje problema i uskih grla i razvoj projekta za unapređenje poslovnih procesa. AS-IS model nam omogućava da shvatimo “šta i kako radimo sada” prije nego što odredimo “šta i kako ćemo raditi sutra”. Analiza AS-IS funkcionalnog modela nam omogućava da shvatimo gdje je problemska situacija, koje će biti prednosti novih procesa i koje promjene će se izvršiti u postojećoj strukturi organizacije procesa. Potrebno istraživanje restrukturiranje(identifikacija i otklanjanje nedostataka) u postojećim procesima postiže se korištenjem dekompozicije (analize), koja se provodi i tamo gdje je funkcionalnost očigledna na prvi pogled.
Funkcionalni model AS-IS
Tako, na primjer, znakovi neefikasnost postojećih procesa može biti:
- beskorisne, neupravljive i duplicirane funkcije;
- neefikasan protok dokumenata ( potreban dokument ne biti na pravom mjestu u pravo vrijeme);
- nedostatak povratnih informacija o kontroli (na funkciju ne utiče njen rezultat), unosu (objekti ili informacije se koriste neracionalno) itd.
Prilikom kreiranja AS-IS modela, neiskusni analitičar može napraviti prilično čestu grešku – kreirati idealizirani model, posebno kada se model kreira pod utjecajem znanja (gledišta) menadžera. Obično je menadžer upoznat sa načinom na koji bi se funkcija trebala obavljati prema priručnicima i opisi poslova i često ne zna kako podređeni zapravo obavljaju tražene funkcije. Stoga su modeli tzv TREBA BITI(kao što bi trebalo da bude), i nose lažne informacije i koje se ne mogu dalje koristiti za analizu.
