Specijalizacija Abazhur Group of Companies je provedba različitih građevinskih projekata temeljenih na EPC/EPCM ugovorima... Ali za one koji su u potrazi i još ne znaju što su EPC i ERSM, nudimo zbirku materijala koji, mi Nadamo se da će poslužiti kao pomoć našim partnerima i klijentima u radu s takvim relativno novim instrumentima za domaću praksu kao što su EPC, EPC (M) ugovori.

Strukturiranje, sklapanje i izvršenje EPC i EPC(M) ugovora

Grupa tvrtki Abazhur specijalizirana je za provedbu različitih građevinskih projekata na temelju EPC/EPCM ugovora, kao i drugih građevinskih ugovora s pojedinačnim uvjetima. , primjenjuje sistemska rješenja u graditeljstvu korištenjem BIM modeliranja, izrađuje nacrte objekata koji postižu nisku kapitalnu intenzivnost.

EPC/EPCM ugovori najčešća su vrsta ugovora u građevinskoj industriji

Prilikom odabira jednog ili drugog oblika, važno je zapamtiti da vrsta ugovora može dovesti do značajne promjene u razini troškova i rizika koji su povezani s izgradnjom velikih i velikih građevina. Visina troškova proporcionalna je rizicima koje klijent preuzima. Kako se smanjuju komercijalni rizici koje preuzima vlasnik, rastu troškovi izgradnje objekta i upravljanja njime. U svakom poslu to logično potvrđuje odnos rizika i nagrade.

Obveze koje preuzima generalni izvođač najčešće uključuju pružanje četiri vrste usluga:

• Inženjering– izviđački radovi, izrada projekta, suglasnost na dokumentaciju;
• Nabava– izbor, nabava i nabava opreme i materijala potrebnih za izvođenje svih radova;
• Izgradnja objekta– građevinski, montažni i puštački radovi;
• Upravljanje svim procesima izgradnje (Construction Management).

Ugovorna strategija za realizaciju velikih građevinskih projekata

Skraćivanje vremena izgradnje često je moguće zbog činjenice da EPC izvođač, kao jedina osoba odgovorna kupcu, može izraditi i izdati projektnu i radnu dokumentaciju paralelno s nabavom materijala i opreme, kao i građevinskim i instalacijskim radovima.

Na primjer, EPC izvođač ne mora čekati izradu i odobrenje cjelokupne projektne dokumentacije kako bi započeo ugovaranje opreme s dugim ciklusom proizvodnje.

Učinkovito korištenje paralelnog dizajna omogućuje u nekim slučajevima značajno smanjenje ukupnog vremena izgradnje. Ovo posebno vrijedi za neke plinske projekte, posebno za projekte prerade/obrade pratećeg naftnog plina, gdje može doći do vrhunca proizvodnje u kojem se mora izgraditi postrojenje za obradu plina, inače će ukupna profitabilnost projekta biti ozbiljno pogođena. U takvim je slučajevima za realizaciju projekta opravdano koristiti EPC model koji, unatoč većoj cijeni, omogućuje završetak izgradnje u kraćem vremenu.

Svaka ugovorna strategija - "tradicionalni" model upravljanja snagama kupca i EPC model ima svoje snage i slabosti. Za usporedbu nudimo tablice u kojima se sistematiziraju negativni i pozitivni aspekti svake strategije.

EPC(M)-ugovor

EPC(M) - struktura je ugovorno rješenje, koje se sa stajališta raspodjele rizika nalazi u sredini između multilot i EPC modela ugovora. Treba odmah napomenuti da ne postoji jedinstveno i nedvosmisleno razumijevanje onoga što se smatra EPC(M) ugovorom. Takav se sporazum može shvatiti, na primjer, kao situacija u kojoj EPCM izvođač djeluje isključivo kao konzultant koji ne sklapa ugovore o podizvođaču u svoje ime.

Jednako tako, EPC(M) ugovor se može nazvati općim ugovorom punog ciklusa, ali u kojem se cijena utvrđuje prema načelu “ otvori knjigu"(otvorena knjiga) ili "nadoknada" (trošak + naknada, nadoknadivo)*. Složenost u terminologiju unosi i činjenica da niti jedna od vodećih međunarodnih organizacija (FIDIC, ICC Orgalime) nije izdala proforma EPC(M) ugovor.

* Po našem mišljenju ispravnije je takve ugovore nazvati
EPC otvorena knjiga i EPC s povratom ili trošak plus naknada

EPC(M) je engleska kratica za Engineering Procurement Construction Management. Istodobno, točan prijevod ove kratice na ruski je "Projektiranje, opskrba, upravljanje izgradnjom". U EPC(M) modelu riječ menadžment najčešće se odnosi upravo na građenje u užem smislu riječi, tj. izvođenje građevinskih, instalacijskih i drugih radova na gradilištu.

Podložno prethodno navedenim rezervama o dvosmislenosti u terminologiji:

EPCM ugovor se najčešće shvaća kao takva struktura kada EPC(M) izvođač sami ili silom podruznica tvrtke provodi projektiranje, samostalno obavlja poslove ugovaranja opreme i materijala, ali u pogledu građevinskih i instalacijskih radova obavlja samo poslove upravljanja, tj. ne angažira izvođače građevinskih i instalacijskih radova u svoje ime, već samo upravlja izvođačima koje naručitelj angažira u ime naručitelja.

Temeljna razlika između EPC(M) sporazuma i EPC ugovora je u tome što je EPC ugovor sporazum o "prihvaćanju odgovornosti i rizika".

Sklapanjem EPC ugovora, kupac uvelike prebacuje rizike i odgovornost na EPC izvođača, koji ovu odgovornost mora osigurati likvidnom imovinom. EPC(M) ugovor je sporazum o profesionalne usluge, kupac “kupuje” kompetencije, odgovornost EPC(M) izvođača za vremenski raspored i proračun projekta izostaje ili je zanemariva u usporedbi s troškom projekta te je stoga isključivo stimulativne prirode.

moguće razne opcije strukturiranje cijene u EPC(M) ugovoru, ali nikada nije čvrsto. Često je cijena kombinacija vremenskih stopa (za one funkcije koje EPCM izvođač obavlja osobno - projektiranje, upravljanje nabavom, upravljanje izgradnjom) i principa "otvorene knjige".

Ovo načelo znači da

• podugovaranje se provodi na način transparentan za kupca i uz sudjelovanje njegovih predstavnika;
• izvođač objavljuje vlastitu strukturu općih troškova, kao i iznos očekivane dobiti, a takvi režijski troškovi/dobit su ili fiksni na određeni iznos ili dodani kao postotna marža na trošak svakog ugovora o opskrbi.

Kao što je već navedeno, odgovornost EPC(M) izvođača vrlo je ograničena i više podsjeća na odgovornost inženjera konzultanta (koji je odgovoran samo za nepošteno ili nekompetentno pružanje vlastitih usluga) nego na odgovornost glavnog izvođača .

Istodobno, vrlo često u EPC(M) ugovorima postoje mehanizmi za stimuliranje izvođača korištenjem načela bonus/malus (tzv. dijeljenje dobiti / dijeljenje bola).

Na primjer, ugovorom se može predvidjeti da je puštanje u rad objekta u više rani datum izvođač dobiva dodatnu naknadu; ako dođe do kašnjenja, izvođač, naprotiv, gubi dio dobiti.

Na sličan način mogu se graditi poticaji u odnosu na opće: strane mogu postaviti određeni ciljani proračun i ako učinkovitim vođenjem izgradnje izvođač ostvari uštede, tada se te uštede dijele između stranaka u dogovorenom omjeru. Međutim, EPC(M) izvođač pri dogovaranju bonusa/malusa obično nije spreman riskirati cjelokupnu nagradu i stoga ovaj mehanizam ne daje kupcu potpuni komfor u pogledu cijene i vremena izgradnje, već je usmjeren samo na stvaranje materijalnog interesa za izvođača uspješna implementacija projekt.

Jedna od prednosti EPCM ugovora u odnosu na EPC model je važna činjenica da se natječaj za odabir EPCM izvođača može pripremiti i provesti mnogo brže od natječaja za dodjelu EPC paušalnog ugovora. Činjenica je da se u prvom slučaju od kupca traži manja razina sigurnosti u pogledu opsega posla, granica isporuke i rizika; a izvođač samo treba pripremiti prijedlog cijene za vremenske stope, režijske troškove i vlastitu dobit - nije dužan pripremiti čvrsti prijedlog cijene za ukupne troškove projekta.

Kod nadmetanja prema EPC paušalnom modelu, naprotiv, naručitelj se treba detaljno pripremiti tehnički zadatak i zahtjevi (ako je razina razrade nedovoljna, izvođači mogu ili odbiti predati ponude s fiksnom cijenom ili procijeniti rizike na vrlo visokoj razini); Isto tako, izvođaču treba red veličine više vremena da pripremi ponudu s čvrstom cijenom koja uzima u obzir sve rizike.

Suvremene metode graditeljstvo, visokokvalitetni materijali i tehnologije, funkcije kontrole građenja i generalnog izvođača, industrijske i poslovne zgrade, montaža montažnih konstrukcija. Izgradnja objekata bilo koje složenosti!

Pojmovi:

EPC izvođač- to je osoba koja obavlja glavni dio posla investicijskog projekta za fiksnu cijenu i preuzima sve rizike njegove provedbe od trenutka projektiranja do trenutka prijenosa gotovog objekta kupcu (uključujući ispunjenje jamstva obveze), za koje snosi financijsku odgovornost prema Kupcu.

Koristi se, u pravilu, u onim projektima u kojima se može s dovoljnim stupnjem točnosti procijeniti veličina svojih troškova, kao i stupanj rizika.

EPC ugovor zahtijeva da EPC izvođač glavninu posla izvodi sam, dakle nije predviđena posebna naknada za organiziranje i vođenje rada uključenih izvođača niže razine.

EPSM izvođač može u svoje ime sklapati ugovore s podizvođačima ili upravljati ugovorima koje naručitelj sklapa s određenim izvođačima radova.

EPSM ugovor predviđa i ukupnu cijenu projekta, uzimajući u obzir naknadu izvođača EPSM, te fiksni rok puštanja objekta u pogon, postizanje glavnih tehničkih parametara objekta. EPSM metoda (pristup) omogućuje upravljanje projektom, a ne konkretnim radom. Specifične radove obavljaju profesionalci. Zadatak EPSM-a je procijeniti potrebna svojstva (sposobnosti, profesionalnost, resurse itd.) odabranih izvođača/dobavljača te pravilno raspodijeliti poslove i područja odgovornosti među njima. Dalje - koordinirajte svoje radnje, riješite kontroverzna pitanja, planirajte cjelokupnu shemu projekta, promijenite planove u slučaju kritičnih promjena s minimalnim posljedicama, a zatim sa svim zaustavljanjima.

Svjetska praksa provedbe investicijskih projekata ističe EPC i EPSM ugovore kao najperspektivnije strategije za provedbu složenih industrijskih projekata, koji čine oko 80% provedenih projekata.

Pročitajte detaljnije publikaciju koju je pripremio.

Ako imate bilo kakvih pitanja ili komentara, možete - sve ćemo ih sa zahvalnošću razmotriti.

Funkcijski dijagram EPC mora započeti s najmanje jednim početnim događajem (početni događaj može slijediti sučelje procesa) i završiti s najmanje jednim završnim događajem (završni događaj može prethoditi sučelju procesa).

Događaji i funkcije moraju se izmjenjivati ​​kako proces napreduje. Odluke o daljnjem tijeku procesa donose funkcije.

Preporučeni broj funkcija na dijagramu nije veći od 20. Ako broj funkcija na dijagramu značajno premašuje 20, tada postoji mogućnost da su procesi na najvišoj razini netočno identificirani te je potrebno prilagoditi model.

Događaji i funkcije moraju sadržavati striktno jednu dolaznu i jednu odlaznu vezu, odražavajući napredak procesa.

Događaji i izjave koje okružuju funkciju u gornjem dijagramu trebaju biti početni/rezultirajući događaji i izjave u dijagramu dekompozicije funkcije.

Dijagram ne bi trebao sadržavati objekte bez jedne veze. Svaki operator spajanja mora imati najmanje dvije dolazne veze i samo jednu odlaznu vezu, a svaki operator grane mora imati samo jednu dolaznu vezu i najmanje dvije izlazne veze. Operateri ne mogu imati više dolaznih i odlaznih veza u isto vrijeme. Ako operator ima dolaznu vezu iz elementa "događaj", tada mora imati odlaznu vezu s elementom "funkcija" i obrnuto. Nakon jednog događaja ne smije slijediti operator OR ili XOR. Operatori mogu spajati ili granati samo funkcije ili samo događaje.

Riža. 2.62 Primjer dijagrama procesa u EPC notaciji

Riža. 2.63 Primjer prihvatljive situacije 3	Riža. 2.64 Primjer prihvatljive situacije 4

Primjer neprihvatljive situacije.

Riža. 2.65 Primjer neprihvatljive situacije

Statističke metode procesno upravljanje

Daju se primjeri najpopularnijih metoda statističke analize i predlaže mehanizam njihove evaluacije.

Analiza Pareto grafikona

Na industrijska poduzeća Stalno se pojavljuju razni problemi: kvarovi, kvarovi opreme itd. U većini slučajeva veliki broj nedostataka i pripadajućih gubitaka nastaje zbog relativno malog broja razloga, a udio materijalnih troškova iznosi oko 70 - 80%. Kako bismo saznali koji su od ovih razloga ili čimbenika glavni, izrađuje se Pareto dijagram.

Pareto dijagram je alat koji vam omogućuje da objektivno predstavite i identificirate glavne uzroke koji utječu na problem koji se proučava. Postoje dvije vrste Pareto grafikona: prema rezultatima aktivnosti i prema uzrocima.

Grafikon izvedbe osmišljen je za prepoznavanje glavnog problema i odražava sljedeće nepoželjne rezultate izvedbe:

· Trošak: obujam gubitaka, troškovi;

· Sigurnost: nezgode, nezgode;

· Vrijeme isporuke: propušteni rokovi, nedostatak zaliha.

Pareto dijagram uzroka odražava uzroke problema koji se javljaju tijekom proizvodnje:

· Izvršitelj posla: smjena, tim i dr.;

· Oprema: strojevi, jedinice, alati itd.;

· Metode rada: redoslijed operacija, proizvodni uvjeti;

· Mjerenja: točnost, obnovljivost, stabilnost.

Konstruiranje Pareto grafikona sastoji se od sljedećih koraka.

Korak 1. Odrediti koje probleme treba istražiti i kako prikupiti podatke; kako ih klasificirati. Postavite način prikupljanja podataka i razdoblje.

Korak 2: Razvijte popis za provjeru snimanja podataka s popisom vrsta informacija koje treba prikupiti.

Korak 3. Ispunite obrazac za bilježenje podataka i izračunajte ukupne iznose.

Korak 4. Razvijte proračunsku tablicu za provjere podataka, uključujući grafikon za ukupne iznose za svaku stavku koja se zasebno provjerava, akumulirani zbroj broja nedostataka, postotak ukupnog iznosa i akumulirane kamate. Pritom rasporedite podatke po važnosti.

Tablica 3.1.1 Konstrukcija Pareto dijagrama

Korak 5: Nacrtajte jednu vodoravnu i dvije okomite osi. Vertikalne osi: na lijevoj osi postavite ljestvicu s intervalom od 0 do broja koji odgovara ukupnom zbroju; na desnoj osi – skala s intervalom od 0 do 100%. Podijelite vodoravnu os s brojem kontroliranih značajki.

Riža. 3.1.1 Pareto dijagram

Faza 6. Konstruirajte stupčasti grafikon gdje svaka vrsta braka ima svoj pravokutnik.

Korak 7. Nacrtajte kumulativnu liniju.

Prilikom izrade dijagrama obratite pozornost na sljedeće točke:

· Dijagram se pokazuje najučinkovitijim ako je broj faktora 7 – 10;

· Prilikom obrade podataka potrebno ih je stratificirati prema pojedinim parametrima (vrijeme odabira podataka, vrsta proizvoda, serija materijala, operater itd.);

· Ako se faktor “ostalo” pokaže prevelikim, treba ponoviti analizu sadržaja tog faktora;

· Grafikon treba biti izrađen sustavno. Pareto za isti proces, što će vam omogućiti da pratite trend u broju nedostataka za svaki faktor (slika 3.1.1).

Notni zapisi za posao

Glazba nas je povezala
Postala je naša tajna

Svi epigrafi za ovaj članak preuzeti su iz pjesme “Music Has Connected Us” grupe Mirage.

U klasičnoj glazbi glazbenik je instrument u rukama skladatelja i svira prema notama. U popularnoj glazbi glazbenici najčešće sami pišu glazbu, a umjetnost improvizacije uopće ne uključuje note. Istina, poznate improvizacije koje su postale klasika potom se pretaču u note, i jesu novi život: mijenja se aranžman, dodaje se novi zvuk i ugođaj.

Tako je i s poslom koji je izrastao kao vješta improvizacija u koji se kreće nova razina zahtijeva stavljanje činjenica na papir za analizu onoga što se događa i donošenje odluka za poboljšanje.

U posljednje vrijeme sve češće možete pronaći opise poslovnih procesa (BP), napravljene, kako kažu, "na svoju ruku". Upravo je ta okolnost bila povod za pisanje članka. Nažalost, većina tih dokumenata koje sam slučajno vidio nisu bili od velike koristi za ozbiljan posao. To ne znači da su bili suštinski netočni, ali brojni propusti su ih toliko pokvarili da sam htio odmah zaboraviti na njihovo postojanje. Kakvi su to propusti i kako se s njima nositi, shvatit ćemo u ovom članku, postupno se približavajući suštini problema. Pokušat ćemo izbjeći velik broj tehničkih detalja, no ne možemo ih u potpunosti izbjeći, jer... predmet razgovora to zahtijeva.

Jesam li to stvarno ja
Ne mogu naći odgovor na sve

Ovaj je članak namijenjen onima koji žele uštedjeti na opisivanju poslovnih procesa povjeravajući pripremu dokumenta internim stručnjacima. Uostalom, opis poslovnih procesa nije obavezan za tvrtku, a sve funkcionira i bez njega. Ali u svakoj stabilnoj tvrtki postoji mehanizam za prijenos ovlasti, zove se " opis posla"Ako je posao složen i pozicija ključna, onda je korisno nacrtati opise poslova kako bi se lakše razumjeli. Akumulacija poslovnih procesa u Opći opis potrebno kako bi poslovanje postalo transparentnije, posebice za njegovu prodaju.

Dokument „Opis BP-a” postaje posebno relevantan čim se pojavi potreba za reorganizacijom (ili, kako je sada moderno reći, reinženjeringom) tvrtke. U ovom slučaju, dokument se koristi za:

1. Na njoj, kao na bojnoj karti, označite bit planiranih preobrazbi,
2. Informirajte sudionika transformacije,
3. Za dodjelu zadataka voditeljima odjela i vanjskim stručnjacima koristite olovku, a ne prste.

Postoje prednosti same pripreme dokumenta:

• Ispada jeftinije;
• Interni stručnjak, bolje upućen u praksu svog domaćeg poslovanja.

Vanjski konzultant prvo će morati proučiti terminologiju i glavne značajke predmet, industrijski standardi. Za ovo treba vremena. Istina, on bolje zna kako i što treba opisati. Postoje određena pravila, općeprihvaćene oznake i poseban softver. Primjer takve oznake može se vidjeti na sl. 1 i sl. 2.

IDEF0 zapis

Primjer opisa napajanja korištenjem IDEF0

Nemojte nam držati predavanja

Nemoj mi držati predavanja
Mama, ovo je beskorisno

Treba li nam ovo stvarno? – upitat će ravnatelj, opravdano pretpostavljajući da će poštivanje svih standarda značajno poskupjeti rezultat. Jedan od direktora koje poznajem razmišljao je ovako: "Pozivanje stručnjaka treće strane je skup posao, ali naši su zadaci jednostavni - zašto su nam potrebne sve te oznake. A stručnjak, ponekad nacrta nešto svojim kukama, ništa nije jasno, nije zgodno priznati, pa on je još uvijek iza Ovo je ono što morate platiti."

Slažem se, ako su zadaci jednostavni, zašto se truditi? A ako su složeni, onda ih treba pojednostaviti, a ne komplicirati otmjenim zapisima. Uostalom, nema očitih prednosti korištenja lijepih udica. Ako nema očitih, to ne znači da ih nema. Ova pravila i oznake nisu izmišljene da se konzultant ne dosađuje... Svatko tko se bavi biznisom dobro zna da nije sve korisno očigledno. Pa, potražimo skrivenu pozitivu i da bismo to učinili, pogledajmo u povijest problema.

Tržište opisa napajanja postoji već jako dugo. Međutim, u proteklom desetljeću i pol, napravio je brzi proboj, zahvaljujući pojavi nove industrije - automatizaciji računovodstva i upravljanja u poduzećima. Rastuće tržište dalo je novopridošlicama koje su osmislile nove oznake priliku da se probiju i zauzmu svoje mjesto. Na primjer na rusko tržište za nekoliko zadnjih godina masivne reklamne i informacijske kampanje od strane IDS Scheera (glavnog dobavljača ARIS-a - vidi sliku 3) stvorile su sloj stručnjaka za opisivanje automatiziranih procesa.

Korištenje ARIS notacije zahtijeva velike detalje poslovnih procesa.

Implementacija sustava poput ERP-a (upravljanje resursima), CRM-a (odnos s kupcima), MRP-a (planiranje proizvodnje) neminovno dovodi do promjena u procesima, a ako se to ne planira unaprijed, rezultat može biti lošiji od željenog. Osim toga, automatizacija je rad s informacijama, što znači da je korisno znati koje je informacije tko generirao, odakle dolaze i kamo idu. Ali posebne oznake za uvođenje automatizacije ovdje nikada nisu zaživjele i rijetko se koriste.

Opis poslovnih procesa u Rusiji relativno je novi trend, unatoč impresivnom broju GOST-ova u ovom području (3.1109, 34, ISO itd.). Sada, s kvalitetom opisa vlastitih poslovnih procesa, najbolje stoji u bankama. Činjenica je da je banka, za razliku od drugih komercijalnih struktura, infrastrukturna organizacija i stoga je u strogim okvirima propisa definiranih zakonom. Banka posluje po principu dnevnog upravljanja. Kao rezultat toga, čak i pojednostavljeni opis poslovnih procesa Banke (na ruskom bez upotrebe oznaka) ispada detaljniji, jer počiva na temeljima izgrađenim na svezacima propisa koji definiraju standarde, terminologiju, uloge i pravila. Ovi su standardi općeprihvaćeni jezik u bankarskom okruženju, a opis poslovnih procesa svakom će stručnjaku biti lako čitljiv.

U komercijalne strukture opis poslovnih procesa zahtijeva preliminarni rječnik pojmova. A kada ga počnu pripremati i usklađivati, mnogi se susreću s činjenicom da se iste stvari u različitim odjelima nazivaju drugačije. Ulaskom u detalje, ispada da različita imena zapravo nose različite nijanse značenja. Usklađivanje terminologije jedan je od najzahtjevnijih procesa u opisivanju poslovnog procesa. Važno je pokrenuti ovaj proces. Mogu preuzeti većinu posla iz vlastitih odjela tvrtke, jer potreba za reguliranjem njezinih aktivnosti dovodi do veće organizacije procesa i procedura.

Kada je za automatizaciju potreban opis, moguć je i obrnuti redoslijed. Promjene poslovnih procesa rade se usporedno s implementacijom informacijskog sustava, a opis novih poslovnih procesa provodi se “na vruće” i sastavni je dio dokumentacije sustava.

Osoblje

Sve sam zaboravio
Učili su nas tolike godine

Začudo, odabir notacije i ispravnost opisa važniji su za mala i srednja poduzeća. Velike tvrtke obično imaju veću elastičnost procesa zbog zamjenjivosti zaposlenika. Za malo poduzeće, gdje se izvršavanje kritičnih točaka svodi na 2-3 donositelja odluka, netočna indikacija rute procesa može dovesti do fundamentalno netočnog koncepta rješenja. Budući da je rezultat kritičan, alat je važan, ali kako ga odabrati?

Svaka notacija je prilagođena za određeni raspon zadataka. Najhitnijim zadatkom smatrat ćemo promjenu poslovnih procesa u okviru projekta automatizacije upravljanja. Za te svrhe postoji dobar skup alata koji su prilično rašireni: to su ruski GOST-ovi, isti ARIS i IDEF, kao i EPC (Sl. 4 i Sl. 5).

EPC notacija

Opis poslovnog procesa korištenjem EPC-a

Ako je knjiga napisana na nekom jeziku, onda je najvažnije imati čitatelja koji taj jezik poznaje i može ga čitati. Na temelju toga, najčešći standard za opisivanje BP je najbolji.

Pri odabiru notacije još jedan važan kriterij je mogućnost korištenja poznatog softverskog alata. Primjerice, Microsoft Business Solution je 2002. ponudio On-Target notaciju za informacijski sustav Navision, popraćenu posebnim programskim rješenjem. Ovo je upravo onaj slučaj kada je bolje izabrati nešto drugo - ne samo da nitko ne zna On-Target notaciju, nego će i softverskom okruženju trebati vremena da je prouči. Pozitivnim primjerom bih nazvao korištenje IDEF notacije i programa Visio koji je vrlo raširen i ima potreban set alata za crtanje IDEF dijagrama (slika 6).

IDEF poslovni procesi izvedeni u Visiu

Naravno, opis napajanja može se napraviti jednostavno riječima, kao i korištenjem raznih simbola (vašeg izuma) jer se čini razumljivim. Imati takav opis bolje je nego ništa, ali je održavanje standarda još uvijek korisno.

Punoća i dubina zvuka

Ne znam što me privlači ovdje

1. dugo će trajati
2. Neki detalji će se promijeniti tijekom izrade dokumenta.

Uobičajena pogreška je pokušaj prilagodbe opisa tako da odgovaraju notaciji. Na primjer, pokušavajući opisati postupke u ARIS formatu, tj. postići prividnu redundanciju u opisu kada to nije potrebno.

Ali više uobičajena pogreška je nedovoljna dubina dokumenta. Kao rezultat toga, rezultat je formalni dokument koji nije prikladan za rad, jer svi važni detalji moraju se razjasniti u procesu.

Melodija je niz zvukova, a ne nota.

Zaboravite na ovaj dan
Nikome ne treba svađa

To znači da se napajanje može jednostavno opisati riječima, bez ikakvih oznaka. Naravno, zapis je ispravniji, ali to nije ono što je bitno. Opis BP nije konačni proizvod, već samo alat za nova postignuća. To znači da se mora prilagoditi za daljnju aktivnu uporabu. Glavni problem s većinom dokumenata "uradi sam" je taj što su nezgodni za korištenje. Na primjer, jedan takav dokument sastojao se od opisa onoga što je učinjeno u Microsoft Wordu i crteža napravljenih u PowerPointu; skakanje s programa na program bilo je užasno nezgodno, morao sam potrošiti veliki broj vrijeme je da sve to stavite u jedan dokument. Ispada da dokument mora imati sljedeća svojstva:

1. Imajte jasan redoslijed i grupiranje odjeljaka, tj. biti konceptualno holistički (obično to znači da ako imate koncept, onda ste ga naučili koristiti);
2. Jasno identificirajte poslovne jedinice i dajte im jasna imena i brojeve;
3. Jasno istaknite poslovne procese i dajte im jasan naziv i numeraciju;
4. Elemente treba numerirati na način da se izbjegne zabuna (to znatno olakšava pretragu): npr. Odjel br. 1 treba imati u dokumentu broj Dept.001, a Poslovni proces br. 1 treba imati broj BP001 ;
5. Dokument mora imati odjeljak sadržaja sa strukturom stabla;
6. Tvrtka je cjeloviti organizam i niti jedan poslovni proces ne visi u zraku – uvijek je povezana s drugim poslovnim jedinicama, poslovnim jedinicama i odjelima. Da biste odražavali te veze, možete koristiti hiperveze - to će olakšati pronalaženje informacija i prelazak s jednog objekta na drugi.

Sve se može koristiti za posao uređivač teksta podržavajuće hiperveze.

Neki vjeruju da u profesionalnom glazbena grupa Dovoljno je imati jednog ili dva prava glazbenika. S ovim se neće složiti nijedan iskreni poznavatelj glazbe. Ovi razgovori nastaju zbog nedostatka profesionalaca i kreativnih pojedinaca.

Poduzeća imaju slične poteškoće. Malo je dobrih stručnjaka koji svoju tvrtku poznaju od glave do pete, a vrlo su zaposleni. Samostalnom analizom poslovnih procesa štedimo novac, a možda i vrijeme. Ali nije uvijek moguće odabrati one najbolje za opis napajanja. Rutinu možete povjeriti izvođačima nižeg ranga, ali tada postoji rizik od odgode procesa. Nepoznavanje načela konstruiranja takvih dokumenata nosi rizik neučinkovitosti (rezultat je neupotrebljiv, to je isto što i njegov izostanak).

Najkvalitetnija i brza priprema dokumenata moguća je u suradnji s ključnim stručnjakom i iskusnim konzultantom. Rezultat će biti dogovoreni jezik za opis poslovnih procesa (tj. terminologija poslovanja tvrtke) i sam opis dovoljno detaljan za rješavanje daljnjih problema.

Ponavljam kao odgovor na sva uvjeravanja
Neće nas razdvojiti, ne

Podsjećamo, svi epigrafi za ovaj članak preuzeti su iz pjesme “Music Connected Us” grupe Mirage

Konzultant treće strane će napisati dokument u notnom jeziku koji je razumljiv drugim konzultantima i često prikladniji za slučaj. Zar ne razumijete sve te udice? Ali ove notacije nisu nimalo komplicirane, možda ih vrijedi naučiti?

Procesni model predstavlja koherentan, integriran skup funkcionalnih, bihevioralnih, informacijskih i organizacijskih perspektiva, ali mnogi modeli koji se danas koriste u praksi reinženjeringa to ne zadovoljavaju.

10/12/2011 Igor Fedorov

Procesni model je međusobno povezani integrirani skup funkcionalnih, bihevioralnih, informacijskih i organizacijskih perspektiva, međutim, mnogi modeli koji se danas koriste u praksi reinženjeringa ne ispunjavaju zahtjeve za procesne modele i ne mogu se nazvati procesnim modelima, jer daju nepotpunu sliku procesa. modelirani objekt i ne sadrže sve informacije potrebne za stvaranje izvršnog modela.

Sporovi oko izbora notacije za modeliranje poslovnih procesa još uvijek ne jenjavaju. Analizirane su mogućnosti EPC (Event-driven Process Chains) i BPMN (Business Process Modeling Notation) notacija, sintaksa, skup primitiva jezika za opis itd. Međutim, netočno je uspoređivati ​​notacije i jezike za opisivanje poslovnih procesa analizom njihove funkcionalnosti – je li model funkcionalan ili proces određen je ne samo notacijom, već i metodologijom. Često se metodologija modeliranja zamjenjuje notacijom, što dovodi do ozbiljnih pogrešaka u dizajnu poslovnih procesa i pojave modela niske kvalitete.

Modeli i perspektive

Model- ovo je materijalni ili mentalni prikaz predmeta ili pojave, ponavljajući neka svojstva bitna za potrebe određenog modeliranja, a izostavljajući druga, nevažna svojstva po kojima se model može razlikovati od prototipa. Složeni objekt, na primjer poslovni proces, opisuje se skupom modela od kojih svaki prikazuje ograničen skup svojstava, a zajedno u potpunosti opisuju objekt modeliranja. Svaki od pojedinih modela povezan je s glavnim pitanjem na koje odgovarajući model treba odgovoriti. Identificirane su četiri perspektive modela poslovnih procesa (vidi sliku).

Funkcionalno:“Što sudionici rade?” Opisuje opseg obavljenog posla.

Ponašanje:“Kako rade sudionici?” Opisuje redoslijed, raspored izvršenja, poslovna pravila.

Informativno:"Što sudionici obrađuju?" Opisuje poslovne entitete procesne domene.

Organizacijski:"Tko radi?" Opisuje sastav i strukturu izvođača.

Model koji opisuje određenu perspektivu odgovara na nekoliko pitanja, ali među njima uvijek postoji glavno, na koje model mora dati iscrpan odgovor, a ne može u potpunosti odgovoriti na dodatna. U potonjem slučaju morate biti posebno oprezni; perspektiva modela određena je upravo glavnim pitanjem, a ne pomoćnim.

Funkcionalna perspektiva

Funkcionalni model opisuje sustav u statičkom stanju i pomaže odgovoriti na pitanje "što treba učiniti da se postigne cilj?" Odgovor je popis svih radnji koje je potrebno izvršiti da bi se postigao planirani rezultat. Široko korišten u upravljanju projektima struktura raščlambe rada(Struktura raščlambe rada) - radnje navedene u njoj nisu povezane vremenskim slijedom. Slično tome, kada modelirate procese, vrlo je korisno stvoriti strukturnu raščlambu koja vam pomaže razumjeti logiku procesa i zapamtiti obavljanje bilo koje važne funkcije. Ako dvije različite organizacije obavljaju isti proces, tada će njihova funkcionalna raščlamba posla biti ista, iako se redoslijed izvršenja posla može promijeniti uzimajući u obzir njihove razlike organizacijska struktura. Dakle, funkcionalni model slabo ovisi o organizacijskoj strukturi i može se smatrati referentnim modelom.

Često se funkcionalni model pogrešno naziva mapom procesa; na primjer, modeli SCOR (Referentni model operacija opskrbnog lanca) i ETOM (Mapa poboljšanih telekomunikacijskih operacija) sadrže hijerarhije funkcija i lanaca vrijednosti, ali ne i procese. Čak i smjernice TeleManagement Foruma pozivaju na razlikovanje procesa kao niza izvršenih radnji i procesa kao smjera aktivnosti tvrtke.

Aspekti bihevioralne perspektive

Bihevioralna perspektiva, koja opisuje dinamiku sustava, odgovara na pitanje "kako se ponašaju sudionici?" Za njegovo modeliranje koristi se dijagram toka upravljanja. Glavno pitanje je "kako?" može se podijeliti na tri: „Kojim redoslijedom se izvode operacije koje čine proces? U koliko sati se izvodi operacija? Zašto se operacije izvode određenim redoslijedom?"

Na prvo pitanje odgovor daje poslovna logika koja predstavlja proceduralni opis redoslijeda izvršenja posla, a za grafički prikaz koristi se dijagram tijeka rada. Odgovor na drugo daje raspored izvršenja procesa, koji određuje kada se obavlja ovaj ili onaj posao, vrijeme provedeno u neizvođenju i radnje poduzete u slučaju kršenja rasporeda izvršenja. Odgovor na treće pitanje daju poslovna pravila, koja su deklarativni opis ograničenja nametnutih procesu.

Poslovna logika procesa

Slijed operacija koje tvore proces obično se naziva poslovnom logikom, a dijagrami toka rada (UML, EPC, ABC Flowchart – opisi temeljeni na dijagramima toka) koriste se za njegov opis. Poslovna logika sadrži eksplicitne, preskriptivne informacije o putu izvršenja procesa, ali samo neizravno uzima u obzir kriterije za donošenje relevantnih odluka.

Dijagram procesa uključuje element "grananja", koji vam omogućuje usmjeravanje izvršenja procesa duž jedne od unaprijed definiranih ruta u skladu s unaprijed određenim uvjetima. Grananje je element poslovne logike, a uvjet po kojem se provodi grananje je poslovno pravilo. Često poslovni analitičari ne odvajaju logiku i pravila i postavljaju element grananja na dijagram, ali izostavljaju povezano pravilo grananja.

Dijagrami koji opisuju poslovnu logiku izgledaju vizualno jednostavno i jasno jer ne uključuju poslovna pravila, rasporede izvršenja i korektivne radnje koje se poduzimaju kada indikatori procesa padnu izvan prihvatljivih raspona, pa ih mnogi analitičari koriste za koordinaciju s poslovnim predstavnicima. Međutim, jednostavnost je varljiva - programeri IT sustava moraju ponovno prikupiti informacije koje nedostaju, a njihovo razumijevanje procesa može biti vrlo različito od stajališta analitičara. Kao rezultat toga, model ne opisuje u potpunosti proces; detalji nisu jasno zabilježeni, već postoje samo u glavama programera. Kao rezultat toga, model procesa na papiru ne odgovara logici IT sustava – upravo te netočnosti u početnom opisu poslovnog procesa dovode do brojnih modifikacija koje nastaju u fazi implementacije informacijskih sustava.

Poslovna pravila

Poslovno pravilo općenito se shvaća kao izjava koja definira ili ograničava neki aspekt poslovanja. Za razliku od proceduralnog opisa, pravila postavljaju ograničenja na izvršenje procesa, ali ne specificiraju kako se točno želi postići rezultat. Stručnjak za poslovna pravila Ronald Ross daje sljedeću klasifikaciju poslovnih pravila:

• pravila ponašanja određuju potrebu provođenja odgovarajuće radnje i provedbe kontrolnih radnji;
• pravila definicije uspostavljaju kriterij za primjenjivost bilo kojeg poslovnog koncepta koji se naziva činjenica;
• pravila izračuna pomažu da se saznaju vrijednosti željenih količina, koje se nazivaju činjenicama; na primjer, trgovački popust može se odrediti prema ukupnoj količini kupnje za određeno razdoblje itd.;
• pravila klasifikacije pomažu u provjeri istinitosti činjenica; na primjer, klijent se smatra VIP-om ako ima određeni iznos na svom računu i nema nepodmirenih plaćanja.

Grananje procesa provodi se na temelju pravila ponašanja koje mijenja rute u skladu s vrijednošću argumenta, koji ima vrijednosti "true" ili "false", ali što je "true", a što "false" je određeno pravilom klasifikacije, koje zauzvrat mora primiti kao ulaz neku vrijednost dobivenu pomoću pravila izračuna. Na primjer, zamislite sljedeći slijed radnji: izračunajte iznos popusta kao funkciju veličine trenutne narudžbe (pravilo izračuna); klasificirajte veličinu popusta: veliki, srednji, niski (pravilo klasifikacije); podnijeti transakciju na odobrenje menadžeru s odgovarajućom razinom ovlasti (pravilo ponašanja). Međutim, raširena je opaka praksa postavljanja "razgranatog" elementa na dijagram u koji su izravno uključena i pravila ponašanja i pravila definicije, što dijagram čini nefleksibilnim, a opis nepotpunim. Dakle, sva pravila trebaju biti eksplicitno odvojena u zasebne konstrukcije na dijagramu tijeka rada, što će pomoći analitičaru da jasno lokalizira odgovarajuću logiku.

Raspored izvršenja

U području materijalne proizvodnje široko se koristi raspored rada za izračunavanje vremena utrošenog na proizvodnju proizvoda. Za poslovne procese raspored rada ima više složen izgled, budući da se svaka operacija može dovršiti na vrijeme, ali cijeli proces može biti odgođen zbog vraćanja na ponovnu obradu.

Ontologija vremena koja se koristi za opisivanje poslovnih procesa sadrži dva osnovna pojma: događaje i intervale. Događaj je točka na vremenskoj ljestvici koja nema trajanja. Događaji se koriste za koordinaciju izvođenja različitih procesa ili grana istog procesa. Interval se shvaća kao segment na vremenskoj skali između početnog i završnog događaja. Intervali vam omogućuju određivanje vremenskog ograničenja dodijeljenog za izvršenje pojedine operacije ili grupe operacija.

Kada uspoređujete oznake modeliranja poslovnih procesa, trebali biste analizirati rade li one s osnovnim konceptima "događaja" i "vremenskog intervala". To pomaže razumjeti omogućuje li vam notacija modeliranje vremenskih karakteristika procesa i koordinaciju izvršenja procesa i njihovih grana. Naša opažanja pokazuju da mnoge notacije modeliranja poslovnih procesa ne koriste ove osnovne koncepte.

Stupanj detalja poslovne logike

Da bi odgovorili na pitanje "kako?", kontrolni dijagram mora sadržavati isto toliko Detaljan opis radnje koje čine proces. Mnogi se analitičari ograničavaju na navođenje funkcija, bez navođenja pojedinosti o njihovom izvršenju, pretpostavljajući da izvođač zna kako posao treba obaviti. Međutim, u praksi zaposlenici teže obavljanju posla na temelju vlastitog iskustva, što dovodi do velike varijabilnosti u provedbi procesa. Notacije modeliranja ne određuju razinu detalja opisa, prepuštajući ovo pitanje analitičaru. Definirajmo kriterije za detaljizaciju.

Vodeći dokument Ruskog državnog standarda, “Metodologija funkcionalnog modeliranja IDEF0” uvodi koncepte “radnje” i “operacije”. Radnja se definira kao "transformacija bilo kojeg svojstva materijalnog ili informacijskog objekta u drugo svojstvo", a operacija se definira kao "skup uzastopnih i/ili paralelnih radnji koje se izvode."

Pojasnimo ove definicije za slučaj modeliranja procesa. Akcijski nazvat ćemo rad koji sudionik obavlja na objektu procesa koji mijenja ovaj objekt, ali ne dovodi do promjene njegovog stanja; npr. sudionik je unio nove podatke, ali to ne znači kraj obrade prijave. Operacija nazvat ćemo skup radnji koje dovode do promjene stanja objekta; na primjer, nakon što su sve provjere dovršene, zahtjev može biti odobren.

Dijagram tijeka rada obično je ograničen na razinu aktivnosti. Vjeruje se da pretjerani detalji otežavaju razumijevanje logike procesa. Kontrolni dijagram trebao bi dati sveobuhvatan odgovor na pitanje kako se proces izvodi i imati detaljne razine akcija. Kao rezultat toga, takvi dijagrami ispadaju pretjerano detaljni i postoji opasnost da budu pretrpani detaljima. No, to je prije stvar stila modeliranja - višerazinski strukturirani modeli mogu kombinirati jednostavnost poslovne logike na gornjoj razini dijagrama i detaljan opis pojedinačnih radnji na dnu.

Stupanj dovršenosti poslovne logike procesa

Većina dijagrama tijeka rada opisuje ograničen skup scenarija izvršenja, identificirajući samo najočitije rute. Ne uključuju scenarije koji se rijetko izvode i zanemaruju posebne i iznimne situacije. Takav nepotpuni opis implementacije ima pravo postojati kada se planira razviti funkcionalni informacijski sistem, gdje osoba određuje redoslijed izvršenja operacija. Međutim, kada se gradi procesno orijentirani sustav, redoslijed operacija određuje sam sustav, stoga model mora pokriti sve moguće scenarije izvršenja, uključujući vraćanje kontrole na prethodni korak ili preuzimanje prijelaza koji zaobilaze određene korake obrade, uzimaju uzeti u obzir mogućnost eskalacije problema, rukovanje iznimnim situacijama, inače će se rad sustava pokazati nemogućim.

Usporedna analiza EPC i BPMN notacija

Pokazali smo da je potrebno razlikovati dijagrame tijeka rada, dijagrame tijeka upravljanja i dijagrame modela procesa. Dijagram tijeka rada definira poslovnu logiku, redoslijed izvršavanja operacija, ima detalje na razini aktivnosti, ne uključuje raspored izvršenja procesa i možda neće u potpunosti definirati poslovna pravila procesa. Kontrolni dijagram tijeka pojašnjava dijagram tijeka rada u smislu rasporeda izvršenja i poslovnih pravila, ima detaljnu razinu radnji, mora opisati sve mogućnosti izvršenja, drugim riječima, opisuje tehnologiju koja jamči postizanje planiranog rezultata u događaj točnog izvršenja unaprijed određenog skupa radnji. U nedostatku barem jedne komponente, opis će biti nepotpun i tehnologija se neće slijediti. Model procesa skup je međusobno povezanih perspektiva, od kojih svaka opisuje pojedinačne aspekte ponašanja procesa, a zajedno tvore integrirani, sveobuhvatni i cjelovit pogled na proces i njegovo izvođenje. Između ostalog, dijagram toka kontrole opisuje perspektivu ponašanja modela poslovnog procesa.

EPC notacija je sredstvo za opisivanje poslovne logike procesa. Kao što usporedba pokazuje, notacija vam omogućuje implementaciju osnovnih obrazaca poslovne logike bez da bude inferiorna u odnosu na druge notacije opisa procesa. EPC dijagrami često ne uključuju poslovna pravila, ali taj nedostatak ne treba pripisivati ​​samoj notaciji, već metodologiji primjene. Što se tiče rasporeda izvršenja, treba napomenuti da ne postoje alati za modeliranje vremenskih karakteristika izvršenja. EPC notacija sadrži konstrukciju "događaj", ali se koristi za opisivanje stanja kontrolnog objekta, a ne za sinkronizaciju izvršenja. EPC metodologija ne fokusira se na stupanj detalja i potpunosti dobivenih dijagrama, prepuštajući to pitanje analitičaru. U nedostatku stroge regulative, analitičari nastoje osigurati jednostavnost i čitljivost dijagrama, stoga se ograničavaju na opisivanje razine operacija i ne nastoje identificirati sve rute izvršenja. EPC notacija se često koristi za automatizaciju pomoću sustava orijentiranih na funkcije, gdje osoba igra vodeću, usmjeravajuću ulogu, tako da odsutnost bilo kakve izvršne skripte nije opasna. Sve nam to omogućuje klasificiranje EPC modela kao dijagrama tijeka rada.

Notacije uključene u ARIS imaju iznimno moćne mogućnosti modeliranja procesa, ali nisu podržane otvorenim i korisniku dostupnim metodologijama. Dokument “ARIS metodologija” ne opisuje metodologiju, već pravila korištenja notacije, što omogućuje široke mogućnosti “tumačenja” metoda modeliranja.

Problem s EPC-om je pokušaj prilagodbe ovog alata za rješavanje preširokog spektra problema, bez objašnjenja pravila primjene za konkretan slučaj. Kao rezultat toga, analitičari primjenjuju mnoge dizajne i mehanizme intuitivno i nesvjesno. Ponekad se njihova namjera može razumjeti iz konteksta problema, ali malo je vjerojatno da će moderno računalo moći analizirati sam kontekst kada pretvara dijagram u izvršni format.

BPMN notacija opisuje logiku procesa. Malo najbolja podrška obrazaca poslovne logike, u usporedbi s EPC-om, nije presudna prednost. Notacija radi s konceptima "događaja" i "vremenskog intervala" i sadrži sredstva za sinkronizaciju grana procesa jedne s drugima i procesa međusobno. Sama notacija ne preporuča odvajanje logike od pravila, ali smjernice za pravilan stil modeliranja uključuju takvu preporuku. BPMN notacija koristi se za stvaranje procesno orijentiranih sustava, gdje osoba igra podređenu ulogu, a sustav ima vodeću ulogu, tako da preskakanje jednog, čak i najrjeđeg scenarija, neće dopustiti da se posao završi i, stoga, je neprihvatljivo; prema tome, BPMN modeli pokrivaju sve scenarije izvršenja. BPMN modeli su izvršni modeli, pa opisuju sve detalje, do najosnovnijih radnji. Sve gore navedeno omogućuje nam da klasificiramo BPMN dijagram kao model tijeka upravljanja.

Problemi s BPMN notacijom povezani su s činjenicom da su dijagrami u pravilu preopterećeni detaljima i detaljima, pa ih je stoga teško čitati. Čini se da je rješenje razvoj metodologije za izgradnju hijerarhijskog višeslojni modeli, gdje najviša razina opisuje kontekst izvršenja cijelog procesa, srednja razina opisuje logiku izvršenja, a donja razina opisuje detalje implementacije pojedinih operacija.

Zanimanje za BPM i BPMS (Business Process Management Suite) doseglo je razinu zrelosti kada više nije potrebno govoriti o modi. Osim toga, rat standarda je završio i BPMN notacija je dobila priznanje od svih glavnih igrača, postavši de facto standard. Ovaj se događaj po značaju može usporediti s pojavom SQL-a koji je postao temelj modernih informacijskih sustava.

BPMS se konačno pojavio kao klasa softver za podršku grafičko modeliranje poslovnih procesa, izvođenje modela poslovnih procesa, praćenje i analiza (Business Activity Monitoring, BAM). Međutim, različiti proizvodi implementiraju ovu funkcionalnost na različite načine, a pri odabiru određenog BPMS-a prvo biste trebali uzeti u obzir sljedeće.

• BPMN podrška. Koja je verzija BPMN-a podržana (1.x ili 2.0)? Koliko je potpuna implementacija: jesu li podržane poruke, signali, podprocesi transakcija?

• Vrsta BPMN procesnog motora. Izravna izvedba je poželjnija od prevođenja u neki drugi prikaz - samo u tom slučaju moguće je u praksi implementirati kontinuirano poboljšanje poslovnih procesa.
• Komunikacija između procesa i podataka. Poželjno je pohraniti atribute oko
obraditi do maksimuma otvorena forma– u tablicama i stupcima relacijskog DBMS-a, koji osigurava referentni integritet, visoke operativne karakteristike i slobodu pristupa podacima izvana, za razliku od, primjerice, pohranjivanja atributa kao XML niza.
• Korisničko sučelje. Sučelje treba biti funkcionalno i ergonomično
i da se razvijaju brzo, po mogućnosti bez programiranja. Sustav bi trebao omogućiti poslovnom analitičaru kreiranje radnog korisničkog sučelja, koje se po želji može modificirati uz uključivanje programera.
• Platforma sustava. Ovisno o tehničkoj politici tvrtke, izbor
može biti ograničen na Java platformu ili. Net – rijetki su BPMS-ovi koji podržavaju obje platforme.
• Shema licenciranja. Shareware sustavi omogućuju vam uštedu novca
licence, ali zahtijevaju velike razvojne resurse; Neki komercijalni sustavi su skupi čak i uz minimalne konfiguracije.
• Dostupnost predstavništva ili partnera u Rusiji.

Ne treba zaboraviti da je BPMS samo jedna od komponenti BPM-a, a za uspjeh projekta kreiranja sustava upravljanja poslovnim procesima potrebne su i kompetencije u metodologiji te u agilnom upravljanju projektima.

Anatolij Belajčuk ([e-mail zaštićen]) – predsjednik tvrtke “Business Console” (Moskva).

Problemi s prevođenjem EPC dijagrama u izvršni format

Rezultati modeliranja u EPC notaciji ne dovode uvijek do stvaranja modela koji se može pretvoriti u izvršni BPM format bez značajnih izmjena.

Nabrojimo tipične pogreške modeliranja.

Za analitičare početnike, EPC model opisuje najvjerojatnije opcije izvršenja, izostavljajući rijetko korištene alternativne rute: u njihovim dijagramima rijetko vidite opise akcija u nestandardnim i iznimnim situacijama.

Vrlo često modeli ne obuhvaćaju u potpunosti sve kriterije donošenja odluka. Kao rezultat toga, model se mora ponovno razviti kako bi se poboljšala poslovna pravila.

Analitičari ne obraćaju pozornost na promjene u objektu upravljanja procesom. Zamislimo opis tehnološki proces, uključujući proizvodnju komponenti. Ako se komponente proizvode po narudžbi, tada možete uključiti opis njihove proizvodnje u glavni proces, ali ako se komponente proizvode asinkrono s glavnim dijelom, tada bi njihova proizvodnja trebala biti zaseban proces s vlastitim kontrolnim objektom. Analitičar mora pažljivo pratiti objekt upravljanja procesom, budući da je njegova promjena znak moguće podjele procesa od kraja do kraja u lanac procesa koji međusobno djeluju.

Nedovoljan stupanj detalja u procesu dovodi do potrebe za ponovnim pojašnjenjem i opisom detalja koji nedostaju u fazi pripreme zahtjeva za IT sustav koji se razvija.

EPC dijagrami ne opisuju rasporede izvršenja i izostavljaju pitanja sinkronizacije grana jednog procesa međusobno is drugim vanjskim procesima.

Dakle, može se reći da problemi EPC-a leže u području metodologije njegove primjene, a uz postojanje sporazuma o modeliranju koji bi definirao sve detalje modela koji se razvija, većina problema, s iznimka vremenskih parametara izvršenja, može se izbjeći.

Nije notacija, već metodologija ta koja određuje je li model funkcionalan ili proces. Model procesa je višeslojni opis koji uključuje međusobno povezane opise funkcionalnih, bihevioralnih, informacijskih i organizacijskih perspektiva. Da biste opisali perspektivu ponašanja, trebali biste koristiti dijagram tijeka kontrole, koji daje sveobuhvatan odgovor na pitanje "kako se proces izvršava?", uključujući definiranje redoslijeda operacija, pravila poslovanja, raspored izvršenja, detalje razine radnji i opisujući sve moguće scenarije izvršenja. Dijagram tijeka rada, koji se neopravdano naziva modelom procesa, ne opisuje sve detalje ponašanja procesa i nije dijagram procesa.

Mnogi modeli koji se koriste u praksi reinženjeringa ne zadovoljavaju sve navedene zahtjeve i stoga se ne mogu nazvati modelima procesa. Postavlja se pitanje: možda upravo u tome leži neuspjeh ovih projekata reinženjeringa poslovnih procesa?

Književnost

1. B. Curtis, M. Kellner, J. Over. Modeliranje procesa, 1992. (enciklopedijska natuknica).
2. eTOM, Reprezentativni tokovi procesa. ITU. s.l.: Telecommunication Standardization Sector Of ITU, 2004.
3. R. Ross. Načela pristupa poslovnom pravilu. Addison-Wesley Professional (2003).
4. C. Pedrinaci, Domingue, A. Alves de Medeiros. Core Ontology for Business Process Analysis, Proceedings of the 5th European Semantic Web Conference on The Semantic Web: Research and Applications, Springer-Verlag Berlin, Heidelberg, 2008.
5. Metodologija funkcionalnog modeliranja IDEF0. Moskva: Gosstandart Rusije, 2000.
6. N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Uzorci tijeka rada.
7. Metode ARIS 7.0. Saarbrucken: IDS Scheer AG, 2005.
8. B. Srebro, BPMN metoda i stil. Cody-Cassidy Press, 2009.

Igor Fedorov ([e-mail zaštićen]) – direktor Centra kompetencija za upravljanje procesima pri MESI (Moskva).

Modeliranje poslovnih procesa, perspektiva modeliranja, funkcionalno i procesno modeliranje

"Zmajevi, blind man's buff and tag
Žmurke, loptice, skakaonica i užad za preskakanje,
I jednostavno, i jednostavno, i samo preskakanje užadi,
Pa jednostavno, jednostavno, samo preskačite užad!!!”

A. Vratarev

Pripremajući ovaj članak otkrio sam nevjerojatnu činjenicu: o EPC notaciji, tako jednostavnoj, a tako popularnoj (postoje mišljenja da je čak popularnija od BPMN-a), na Wikipediji postoje članci na samo 4 jezika: engleskom, njemačkom, češkom i uzbečki. Štoviše, ti su članci prilično kratki. Možda ćemo do kraja članka ti i ja, dragi čitatelju, shvatiti zašto.

Dopustite mi da počnem s činjenicom da je EPC notacija razvijena ranih 1990-ih. tijekom razvoja ARIS metodologije, kao, recimo, njene procesne komponente. Utemeljiteljem EPC-a smatra se profesor Wilhelm-August Scheer, čije samo ime izaziva strahopoštovanje kod prosječne osobe (izgovorite to naglas i osjetite inspiraciju). Što tek reći o nazivu fakulteta na kojem je ovaj uvaženi momak radio: Institut für Wirtschaftsinformatik of the University Universität des Saarlandes.

Svrha stvaranja EPC notacije bila je mogućnost opisivanja procesa tako da funkcije koje se unutar njih izvode imaju globalnu semantiku unutar dijagrama, što znači da izvođenje funkcije na EPC dijagramima nije nužno jasno definirano, ali može ovisiti o stanje drugih čvorova dijagrama, ponekad vrlo udaljenih jedan od drugog.

Naziv notacije je kratica za Event-driven Process Chain, što jasno ukazuje da su središnji element EPC notacijskih dijagrama događaji. Događaji dovode do izvođenja određenih radnji od strane određenih sudionika. Završetak radnji pak generira još jedan događaj, i tako dalje, sve dok sustav ne dosegne stanje čija se pojava unutar procesa smatra konačnim događajem.

Kako bih jasno pokazao mogućnosti notacije, poslužit ću se svakodnevnim primjerom, inspiriranim nedavno završenim odmorom u toplijim krajevima. Recepcioner uglednog hotela Ivo Petkov prima zahtjev jednog od gostiju za hitnom zamjenom potrepština za pranje u sobi. Sasvim je jasno da je njegova zadaća ispuniti zahtjev klijenta, odnosno u smislu EPC-a dovesti sustav iz stanja „Zaprimljen zahtjev klijenta za promjenu umivaonika“ u stanje „Zahtjev klijenta je zadovoljen“.

Prikazujemo dva navedena stanja na nacrtu dijagrama i odmah primjećujemo kako će naš dijagram biti lako čitljiv, jer svaki njegov element ima ne samo svoj oblik, već i svoju boju. Tako su događaji crveni šesterokuti, funkcije zeleni pravokutnici sa zaobljenim rubovima, a izvođači su prikazani žutim ovalima.

Dakle, vratimo se primjeru. Odmah po primitku zahtjeva od klijenta, Ivo mora sobarici poslati zahtjev za ispunjenje zahtjeva klijenta, čime sustav dovodi u stanje "Zahtjev za ispunjenje poslan". Sobarica, koristeći zalihe dostupne u skladištu, ispunjava Ivin zahtjev. I tu se prvi put pojavljuje paralelizacija našeg procesa: ako spremačica shvati da potrebne potrepštine za pranje (recimo, gel za tuširanje) trenutno nema na zalihama, onda ona sama, možda i nesvjesno, prebacuje sustav na “Ispunjavanje zahtjev je nemoguć" stanje. iz čega prirodno proizlazi da će Ivo morati imati ne baš ugodan razgovor s klijentom, a u kakvo će stanje sustav doći ovisi samo o raspoloženju klijenta i njegovoj sklonosti borbi. Ako u skladištu ima svih potrepština potrebnih za gosta, sobarica uspješno ispunjava zahtjev koji joj je prenesen, prijavljuje ispunjenje Ivi, koji pak o tome izvještava klijenta. I svi žive sretno do kraja života i umiru na isti dan.

Ovaj jednostavan proces odražava se u tako radosno trepćućem crvenom, zelenom i žutom dijagramu kao na slici 1.

Riža. 1. EPC dijagram procesa obrade zahtjeva kupca u hotelu

A sada, prema tradiciji, prednosti i nedostaci notnog zapisa.

Kad sam se prvi put susreo s EPC dijagramima, kao što sam ranije spomenuo, bio sam vrlo zadovoljan njihovom lakoćom čitanja: svaki blok je istaknut oblikom i bojom, vrlo je lako vidjeti izvođače, potrebne materijale, istaknuti popis mogućih stanja sustava, popis onih koji se izvode tijekom procesa funkcija. Ovo je nedvojbeno veliki plus: kupac neće imati poteškoća u čitanju dijagrama poslovnog procesa kada implementacija EDMS-a, ako je točno prikazan u EPC notaciji. Međutim, možda će kupca zbuniti takav gigantski broj stanja, jer zapravo zbog njih krug jako raste. Čak iu našem primjeru: neke 4 funkcije generirale su čak 5 stanja (ne računajući početno). Ponekad se pitate: zašto isticati sve njih. Reći ćemo vam zašto je to potrebno nakon dogovora oko ugovora Generalni direktor u zasebnom bloku označite „Sporazum dogovoren”, a nakon potpisivanja - „Sporazum potpisan”, ako dalje proces i dalje ostaje linearan. Iskreno govoreći, nema potrebe, osim ako niste Captain Obvious.

A ponekad nije jasno kako prepoznati stanje u koje će funkcija prebaciti sustav. Još dok sam pripremao ovaj jednostavan primjer, iskusio sam određene poteškoće vezane upravo za ovaj trenutak.

Prednost EPC dijagrama je činjenica da, poput IDEF0 dijagrama, možete naznačiti ulazne i izlazne podatke svake funkcije na njima, te pratiti logiku kretanja ulaznih i izlaznih podataka od bloka do bloka. Osim toga, za razliku od istog IDEF0, postalo je moguće paralelizirati proces, usmjeravajući ga duž samo jedne od alternativnih grana (u IDEF0, ako dodamo paralelizam u izvršavanju, tada će se sve paralelne funkcije izvršavati istovremeno). Također mi se činilo kao prednost što mogu odrediti izvođača za svaku pozornicu (čitaj: funkcije).

Ali! U IDEF0, izvršitelj je naznačen jednom na svakoj razini dekompozicije, a strelice su nacrtane u njegovo ime za sve blokove koje je on izvršio. U EPC-u, da bismo izračunali koliko radnji izvršava izvršitelj, moramo proći kroz sve akcijske blokove i provjeriti je li u njima naznačen izvršitelj koji nam je potreban.

Ova notacija mi se učinila vrlo zgodnom sa stajališta praćenja izvršavanja procesa: svaka funkcija sigurno prebacuje sustav u novo stanje, iz čega slijedi da se nakon izvršenja svake funkcije može provjeriti je li sustav prešao u željeno stanje. stanje zapravo je provedeno. Ali odmah se postavilo pitanje: je li to stvarno potrebno? Na primjer, ja rijetko imam takvu želju =)

Dakle, općenito, EPC notacija čini mi se neprikladnom za opisivanje poslovnih procesa: previše pozornosti na događaje, premalo pozornosti na akcije i posebno njihovo grupiranje na temelju izvođača ili korištenih materijala. Da, jednostavna je, da, lijepa je, i da, nažalost, to je sve što mogu reći o njoj, kao vjerojatno i mnogi drugi ljudi. =)

A članci o UML i BPMN notacijama sve su bliže i bliže.

(4,14 - ocijenjeno od 21 osobe)