Abazhur Group of Companies spetsialiseerumine on EPC/EPCM lepingutel põhinevate eriilmeliste ehitusprojektide elluviimine... Aga neile, kes otsivad ja veel ei tea, mis on EPC ja ERSM, pakume materjalide kogumit, mida loodetavasti on meie partneritele ja klientidele abiks kodumaise praktika suhteliselt uute instrumentidega nagu EPC, EPC (M) lepingud.

EPC ja EPC(M) lepingute struktureerimine, sõlmimine ja täitmine

Abazhur Group of Companies on spetsialiseerunud EPC/EPCM lepingutel põhinevate erinevate ehitusprojektide elluviimisele, aga ka muudele üksikute tingimustega ehituslepingutele. , rakendab ehituses süsteemseid lahendusi kasutades BIM modelleerimist, loob madala kapitalimahukust saavutavaid hooneprojekte.

EPC/EPCM lepingud on ehitustööstuses kõige levinumad lepingutüübid

Ühe või teise vormi valimisel on oluline meeles pidada, et lepingu tüüp võib kaasa tuua oluliste muutuste kulude ja riskide tasemes, mis on seotud suurte ja suurte ehitiste ehitamisega. Kulude tase on proportsionaalne kliendi poolt võetud riskidega. Omaniku võetavate äririskide vähenedes suurenevad objekti rajamise ja haldamise kulud. Igas äris kinnitab seda loogiliselt riski-tulu suhe.

Peatöövõtja võetud kohustuste hulka kuuluvad enamasti nelja tüüpi teenuste osutamine:

• Tehnika– mõõdistustööd, projekti koostamine, dokumentatsiooni kinnitamine;
• Hanked– kõigi tööde tegemiseks vajalike seadmete ja materjalide valik, ostmine ja tarnimine;
• Objekti ehitamine– ehitus-, montaaži- ja kasutuselevõtutööd;
• Kõigi ehitusprotsesside juhtimine (ehitusjuhtimine).

Lepingustrateegia suurte ehitusprojektide elluviimiseks

Ehitusaja lühendamine on sageli võimalik tänu sellele, et EPC töövõtjal on ainsana tellija ees vastutaval isikul võimalik paralleelselt materjalide ja seadmete ostmisega, samuti ehitus- ja paigaldustöödega välja töötada projekteerimis- ja töödokumentatsiooni.

Näiteks, ei pea EPC töövõtja pika tootmistsükliga seadmete lepingute sõlmimiseks ootama kogu projekti dokumentatsiooni väljatöötamist ja kinnitamist.

Paralleelprojekti tõhus kasutamine võimaldab mõnel juhul oluliselt vähendada üldist ehitusaega. See kehtib eriti mõnede gaasiprojektide, eriti nendega seotud naftagaasi töötlemise/puhastusprojektide kohta, kus võib olla tootmise kõrgaeg, mil tuleb ehitada gaasipuhastusrajatis, vastasel juhul kahjustatakse tõsiselt projekti üldist kasumlikkust. Sellistel juhtudel on põhjendatud projekti elluviimisel kasutada EPC mudelit, mis vaatamata suuremale maksumusele võimaldab ehituse valmis saada lühema ajaga.

Igal lepingustrateegial on "traditsiooniline" kliendi jõudude juhtimise mudel ja EPC mudelil oma tugevad ja nõrgad küljed. Võrdluseks pakume tabeleid, mis süstematiseerivad iga strateegia negatiivseid ja positiivseid külgi.

EPC(M)-leping

EPC(M) - struktuur on lepinguline lahendus, mis riskijaotuse seisukohalt jääb multipartii ja EPC lepingumudelite keskele. Tuleb kohe märkida, et puudub ühtne ja üheselt mõistetav arusaam sellest, mida peetakse EPC(M) lepinguks. Sellist kokkulepet võib mõista näiteks olukorrana, kus EPCM-i töövõtja tegutseb üksnes konsultandina, kes ei sõlmi enda nimel ühtegi alltöövõtulepingut.

Samamoodi võib EPC(M) lepingut nimetada täistsükli pealepinguks, kuid mille hind määratakse põhimõttel „ avatud raamat"(avatud raamat) või "kompensatsioon" (kulu + tasu, hüvitatav)*. Terminoloogia keerukust toob kaasa ka asjaolu, et ükski juhtiv rahvusvaheline organisatsioon (FIDIC, ICC Orgalime) ei ole väljastanud proforma EPC(M) lepingut.

* Meie arvates on õigem selliseid lepinguid nimetada
Vastavalt EPC avatud raamat ja EPC hüvitatav või kulu pluss tasu

EPC(M) on ingliskeelne lühend sõnadest Engineering Procurement Construction Management. Samal ajal on selle lühendi õige tõlge vene keelde “Disain, tarne, ehitusjuhtimine”. EPC(M) mudelis viitab sõna juhtimine kõige sagedamini konkreetselt ehitusele selle sõna kitsas tähenduses, s.t. teostada objektil ehitus-, paigaldus- ja muid töid.

Arvestades eelnevalt esitatud reservatsioone terminoloogia ebaselguse kohta:

EPCM-lepingut mõistetakse kõige sagedamini sellise struktuurina, kui EPC(M) töövõtja omapäi või jõuga tütarettevõte teostab projekteerimist, teostab iseseisvalt seadmete ja materjalide tellimist, kuid ehitus- ja paigaldustööde osas teostab vaid juhtimist, s.o. ei palka enda nimel ehitus- ja paigaldustöövõtjaid, vaid juhib kliendi nimel ainult tellija palgatud töövõtjaid.

Põhiline erinevus EPC(M) lepingu ja EPC lepingu vahel seisneb selles, et EPC leping on leping “vastutuse ja riskide võtmisest”

EPC lepingu sõlmimisega klient lükkab riskid ja vastutuse suures osas üle EPC töövõtjale, mis peab tagama selle vastutuse likviidse varaga. EPC(M) leping on kokkulepe professionaalsed teenused, klient “ostab” kompetentse, puudub EPC(M) töövõtja vastutus projekti ajastamise ja eelarve eest või on projekti maksumusega võrreldes tühine ja on seega eranditult stimuleeriva iseloomuga.

Võimalik erinevaid valikuid hinna struktureerimine EPC(M) lepingus, kuid see ei ole kunagi kindel. Sageli on hind kombinatsioon ajatariifidest (nende funktsioonide puhul, mida EPCM-i töövõtja isiklikult täidab – projekteerimine, hangete juhtimine, ehitusjuhtimine) ja "avatud raamatu" põhimõttest.

See põhimõte tähendab seda

• alltöövõtt toimub tellijale läbipaistval viisil ja tema esindajate osalusel;
• töövõtja avalikustab nii oma üldkulude struktuuri kui ka oodatava kasumi summa ning selline üldkulu/kasum fikseeritakse kindlaksmääratud summas või lisatakse protsendimäärana iga tarnelepingu maksumusele.

Nagu juba märgitud, on EPC(M) töövõtja vastutus väga piiratud ja meenutab pigem konsultatsiooniinseneri vastutust (kes vastutab ainult oma teenuste ebaausa või ebakompetentse osutamise eest), mitte peatöövõtja vastutust. .

Samas on EPC(M) lepingutes üsna sageli olemas mehhanismid töövõtja stimuleerimiseks, kasutades põhimõtteid. boonus/malus (nn kasumi jagamine / valu jagamine).

Näiteks, võib lepingus ette näha, et rajatise kasutuselevõtt rohkem varajane kuupäev töövõtja saab lisatasu, hilinemise korral kaotab töövõtja vastupidi osa kasumist.

Sarnaselt saab stiimuleid üles ehitada üldise suhtes: osapooled saavad seada kindla sihteelarve ja kui ehitust efektiivselt juhtides saavutab töövõtja kokkuhoidu, siis jagatakse selline sääst osapoolte vahel kokkulepitud proportsioonis. Samas ei ole EPC(M) töövõtja boonuse/maluse kokkuleppimisel tavaliselt valmis kogu tasuga riskima ja seetõttu ei anna see mehhanism tellijale täielikku mugavust ehituse maksumuse ja ajastuse osas, vaid on suunatud ainult töövõtjale materiaalse huvi tekitamine edukas rakendamine projekt.

EPCM-i lepingu üheks eeliseks võrreldes EPC-mudeliga on oluline asjaolu, et EPCM-i töövõtja valiku pakkumist saab koostada ja läbi viia palju kiiremini kui EPC ühekordse lepingu sõlmimise pakkumist. Fakt on see, et esimesel juhul nõutakse kliendilt väiksemat kindlustunnet tööde mahu, tarnepiiride ja riskide osas; ja töövõtja peab koostama ainult hinnapakkumise ajamäärade, üldkulude ja oma kasumi kohta - ta ei pea koostama kindlat hinnapakkumist projekti kogumaksumuse kohta.

EPC ühekordse summa mudeli järgi pakkumiste tegemisel tuleb tellijal vastupidi ette valmistada üksikasjalik tehniline ülesanne ja nõuded (ebapiisava läbitöötamise taseme korral võivad töövõtjad kas keelduda fikseeritud hinnaga ettepanekute esitamisest või hinnata riske väga kõrgel tasemel); Samuti vajab töövõtja suurusjärku rohkem aega, et koostada kindla hinnaga, kõiki riske arvestav pakkumine.

Kaasaegsed meetodid ehitus, kvaliteetsed materjalid ja tehnoloogiad, ehituskontrolli ja peatöövõtja funktsioonid, tööstus- ja ärihooned, kokkupandavate konstruktsioonide paigaldus. Igasuguse keerukusega objektide ehitamine!

Tingimused:

EPC töövõtja- see on isik, kes teeb investeerimisprojekti põhitöömahu fikseeritud hinnaga ja võtab kõik selle elluviimisega seotud riskid alates projekteerimise hetkest kuni valmisobjekti kliendile üleandmiseni (sh garantii täitmine). kohustused), mille eest kannab ta Kliendi ees rahalist vastutust.

Seda kasutatakse reeglina nendes projektides, kus ta suudab piisava täpsusega hinnata oma kulude suurust ja ka riskiastet.

EPC leping nõuab seetõttu teeb EPC töövõtja suurema osa töödest ise erilist tasu pole ette nähtud kaasatud madalama taseme töövõtjate töö korraldamise ja juhtimise eest.

EPSM töövõtja saab sõlmida enda nimel lepinguid alltöövõtjatega või hallata tellija poolt konkreetsete tööde tegijatega sõlmitud lepinguid.

EPSM leping näeb ette ja projekti kogumaksumus, võttes arvesse EPSM-i töövõtja tasu ja objekti kasutuselevõtu fikseeritud tähtaega, saavutades objekti peamised tehnilised parameetrid. EPSM-meetod (lähenemine) võimaldab hallata projekti, mitte konkreetseid töid. Konkreetseid töid teevad professionaalid. EPSM-i ülesanne on hinnata valitud töövõtjate/tarnijate vajalikke omadusi (võimed, professionaalsus, ressursid jne) ning jaotada nende vahel korrektselt tööd ja vastutusvaldkonnad. Järgmiseks - kooskõlastage nende tegevus, lahendage vastuolulisi küsimusi, kavandage projekti üldine skeem, muutke plaane minimaalsete tagajärgedega kriitiliste muudatuste korral ja seejärel kõigi peatustega.

Ülemaailmne investeerimisprojektide elluviimise praktika toob keeruliste tööstusprojektide elluviimise kõige perspektiivikamate strateegiatena esile EPC ja EPSM lepingud, mis moodustavad ligikaudu 80% teostatud projektidest.

Loe lähemalt koostatud trükist.

Kui teil on küsimusi või kommentaare, võite - kõik need võetakse tänuga arvesse.

EPC funktsiooniskeem peab algama vähemalt ühe algussündmusega (algussündmus võib järgneda protsessi liidesele) ja lõppema vähemalt ühe lõppsündmusega (lõppsündmus võib eelneda protsessi liidesele).

Sündmused ja funktsioonid peavad protsessi edenedes vahelduma. Protsessi edasise käigu kohta otsustavad funktsioonid.

Soovitatav funktsioonide arv diagrammil ei ole suurem kui 20. Kui funktsioonide arv diagrammil ületab oluliselt 20, siis on võimalus, et tipptasemel olevad protsessid on valesti tuvastatud ja mudelit on vaja korrigeerida.

Sündmused ja funktsioonid peavad sisaldama rangelt ühte sissetulevat ja ühte väljuvat ühendust, mis peegeldab protsessi edenemist.

Sündmused ja avaldused, mis ülaltoodud diagrammil funktsiooni ümbritsevad, peaksid olema funktsioonide jaotusdiagrammi algsed/tulemuslikud sündmused ja laused.

Diagramm ei tohiks sisaldada objekte ilma ühe ühenduseta. Igal ühendamisoperaatoril peab olema vähemalt kaks sissetulevat linki ja ainult üks väljaminev link ning igal haruoperaatoril peab olema ainult üks sissetulev link ja vähemalt kaks väljaminevat linki. Operaatoritel ei saa olla korraga mitut sissetulevat ja väljaminevat ühendust. Kui operaatoril on sissetulev ühendus elemendist “sündmus”, siis peab tal olema väljuv ühendus elemendiga “funktsioon” ja vastupidi. Ühele sündmusele ei tohi järgneda operaator VÕI ega XOR. Operaatorid saavad liita või hargneda ainult funktsioone või ainult sündmusi.

Riis. 2.62 Protsessi diagrammi näide EPC tähistuses

Riis. 2.63 Vastuvõetava olukorra näide 3	Riis. 2.64 Vastuvõetava olukorra näide 4

Näide vastuvõetavast olukorrast.

Riis. 2.65 Näide lubamatust olukorrast

Statistilised meetodid protsesside juhtimine

Tuuakse näiteid kõige populaarsematest statistilise analüüsi meetoditest ja pakutakse välja nende hindamise mehhanism.

Pareto diagrammi analüüs

Peal tööstusettevõtted Pidevalt tekivad igasugused probleemid: defektid, seadmete talitlushäired jne. Enamikul juhtudel tekib valdav arv defekte ja nendega seotud kahjusid suhteliselt väikese arvu põhjuste tõttu ning materjalikulude osakaal on umbes 70–80%. Et teada saada, millised neist põhjustest või teguritest on peamised, koostatakse Pareto diagramm.

Pareto diagramm on tööriist, mis võimaldab objektiivselt esitada ja tuvastada uuritavat probleemi mõjutavad peamised põhjused. Pareto diagramme on kahte tüüpi: tegevuste tulemuste ja põhjuste järgi.

Toimivusdiagramm on loodud peamise probleemi tuvastamiseks ja kajastab järgmisi ebasoovitavaid jõudlustulemusi:

· Maksumus: kadude maht, kulud;

· Ohutus: õnnetused, rikked;

· Tarneajad: tähtajad mööda lastud, laoseisu puudumine.

Põhjuste Pareto diagramm kajastab tootmise käigus tekkivate probleemide põhjuseid:

· Töö tegija: vahetus, meeskond vms;

· Varustus: masinad, agregaadid, tööriistad jne;

· Töömeetodid: toimingute järjestus, tootmistingimused;

· Mõõtmised: täpsus, reprodutseeritavus, stabiilsus.

Pareto diagrammi koostamine koosneb järgmistest sammudest.

1. samm. Tehke kindlaks, milliseid probleeme on vaja uurida ja kuidas andmeid koguda; kuidas neid liigitada. Määrake andmete kogumise meetod ja periood.

2. samm: koostage andmete salvestamise kontroll-loend, mis loetleb kogutava teabe tüübid.

Samm 3. Täitke andmete salvestusleht ja arvutage kogusummad.

4. samm. Koostage andmete kontrollimiseks tabel, mis sisaldab graafikut iga eraldi kontrollitud kauba kogusummade, defektide arvu akumuleeritud summa, protsent kogusummast ja kogunenud intresside kohta. Samal ajal järjesta andmed tähtsuse järjekorda.

Tabel 3.1.1 Pareto diagrammi koostamine

5. samm: joonistage üks horisontaalne ja kaks vertikaalset telge. Vertikaalsed teljed: asetage vasakule teljele skaala intervalliga 0 kuni üldsummale vastava arvuni; paremal teljel – skaala intervalliga 0 kuni 100%. Jagage horisontaaltelg juhitavate funktsioonide arvuga.

Riis. 3.1.1 Pareto diagramm

6. etapp. Koostage tulpdiagramm, kus igal abielutüübil on oma ristkülik.

7. samm. Joonistage kumulatiivne joon.

Diagrammi koostamisel peaksite pöörama tähelepanu järgmistele punktidele:

· Diagramm osutub kõige tõhusamaks, kui tegurite arv on 7 – 10;

· Andmete töötlemisel on vaja need kihistada üksikute parameetrite järgi (andmete valiku aeg, toodete liik, materjalipartii, operaator jne);

· Kui “muu” tegur osutub liiga suureks, tuleks korrata selle teguri sisu analüüsi;

· Diagramm tuleks koostada süstemaatiliselt. Pareto sama protsessi jaoks, mis võimaldab teil jälgida iga teguri defektide arvu trendi (joonis 3.1.1).

Noodid äri jaoks

Muusika on meid sidunud
Sellest on saanud meie saladus

Kõik selle artikli epigraafid on võetud ansambli Mirage laulust “Music Has Connected Us”.

Klassikalises muusikas on muusik helilooja käes pill ja mängib nootide järgi. Levimuusikas kirjutavad muusikud kõige sagedamini muusikat ise ja improvisatsioonikunstiga ei kaasne üldse noote. Tõsi, klassikaks saanud kuulsad improvisatsioonid tõlgitakse seejärel nooditeks, ja seda on ka tehtud uus elu: korraldus muutub, lisandub uus kõla ja meeleolu.

Nii ka äri, mis on kasvanud oskusliku improvisatsioonina, kuhu liikuda uus tase nõuab faktide paberile panemist, et analüüsida toimuvat ja teha parendusotsuseid.

Viimasel ajal leiate üha sagedamini äriprotsesside (BP) kirjeldusi, mis on tehtud, nagu öeldakse, "omaette". Just see asjaolu ajendas artiklit kirjutama. Kahjuks oli enamikust nendest dokumentidest, mida juhtusin nägema, tõsiseks äritegevuseks vähe kasu. See ei tähenda, et need oleksid põhimõtteliselt valed, kuid mitmed väljajätmised rikkusid neid nii ära, et tahtsin nende olemasolu kohe unustada. Millised väljajätmised need on ja kuidas nendega toime tulla, selgitame välja selle artikli käigus, lähenedes järk-järgult probleemi olemusele. Püüame vältida suurt hulka tehnilisi detaile, kuid me ei saa neid täielikult vältida, sest... vestluse teema seda nõuab.

Kas see on tõesti mina
Ma ei leia kõigele vastust

See artikkel on adresseeritud neile, kes soovivad kokku hoida äriprotsesside kirjeldamisel, usaldades dokumendi koostamise sisespetsialistidele. Äriprotsesside kirjeldus pole ju ettevõttele kohustuslik ja kõik toimib ilma selleta. Kuid igas stabiilses ettevõttes on volituste üleandmise mehhanism, mida nimetatakse " töökirjeldus"Kui äri on keeruline ja positsioon võtmetähtsusega, siis on kasulik koostada ametijuhendid, et oleks lihtsam aru saada. Äriprotsesside kuhjumine üldkirjeldusäri läbipaistvamaks muutmiseks, eriti selle müügiks.

Dokument “BP kirjeldus” muutub eriti aktuaalseks kohe, kui tekib vajadus ettevõtte ümberkorraldamiseks (või, nagu praegu on moes öelda, ümberkujundamiseks). Sel juhul kasutatakse dokumenti:

1. Märkige sellel, nagu lahingukaardil, kavandatud ümberkujundamise olemus,
2. Viige transformatsioonis osaleja kurssi,
3. Kasutage osakonnajuhatajatele ja välisspetsialistidele ülesannete määramiseks pliiatsit, mitte sõrmi.

Dokumendi ise koostamisel on eeliseid:

• See tuleb odavam välja;
• Sisespetsialist, kes on paremini kursis oma koduettevõtte tavadega.

Väliskonsultant peab kõigepealt tutvuma terminoloogiaga ja põhijooned teema, tööstusstandardid. See võtab aega. Tõsi, tema teab paremini, kuidas ja mida on vaja kirjeldada. On teatud reeglid, üldtunnustatud märge ja spetsiaalne tarkvara. Sellise märgistuse näidet võib näha joonisel fig. 1 ja fig. 2.

IDEF0 märge

Näide toiteallika kirjeldamisest IDEF0 abil

Ära loe meile

Ära loe mulle
Ema, see on kasutu

Kas me tõesti vajame seda? - Direktor küsib, eeldades, et kõigi standardite järgimine suurendab oluliselt tulemuse maksumust. Üks minu tuttavatest direktoritest arutles nii: "Kolmanda osapoole spetsialisti kutsumine on kallis äri, kuid meie ülesanded on lihtsad - milleks meil kõiki neid märke vaja. Ja spetsialist, mõnikord ta joonistab midagi oma konksudega, mitte midagi pole selge, seda pole mugav tunnistada, nii et ta on endiselt taga. Selle eest peate maksma."

Olen nõus, kui ülesanded on lihtsad, siis milleks vaeva näha? Ja kui need on keerulised, siis tuleb neid lihtsustada ja mitte keerukaks teha väljamõeldud märgetega. Ilusate konksude kasutamisel pole ju ilmselgeid eeliseid. Kui ilmseid pole, ei tähenda see, et neid poleks. Need reeglid ja märgid pole välja mõeldud selleks, et konsultandil igav ei hakkaks... Kes asjaga tegeleb, see teab hästi, et kõik kasulik ei paista silma. Noh, otsigem peidetud positiivset ja selleks uurime probleemi ajalugu.

Toiteallika kirjeldusturg on eksisteerinud väga pikka aega. Viimase pooleteise aastakümne jooksul on see aga teinud kiire läbimurde tänu uue tööstusharu – raamatupidamise ja juhtimise automatiseerimisele ettevõtetes – tekkimisele. Kasvav turg andis uutele märkustele välja tulnud uustulnukatele võimaluse läbi murda ja oma koht välja tuua. Näiteks peal Venemaa turg paar Viimastel aastatel IDS Scheeri (ARIS-i peamise tarnija – vt joonis 3) massilised reklaami- ja teabekampaaniad lõid automatiseeritud protsesside kirjeldamise spetsialistide kihi.

ARIS-i tähiste kasutamine nõuab äriprotsesside üksikasjalikku teavet.

Selliste süsteemide nagu ERP (ressursihaldus), CRM (kliendisuhted), MRP (tootmise planeerimine) juurutamine toob paratamatult kaasa muutusi protsessides ning kui seda ette ei planeerita, võib tulemus olla soovitust kehvem. Lisaks on automatiseerimine infoga töötamine, mis tähendab, et on kasulik teada, millist infot kes genereerib, kust see tuleb ja kuhu läheb. Kuid automatiseerimise juurutamiseks mõeldud erimärgid pole siin kunagi juurdunud ja neid kasutatakse harva.

Venemaa äriprotsesside kirjeldus on suhteliselt hiljutine suundumus, vaatamata muljetavaldavale GOST-ide arvule selles valdkonnas (3.1109, 34, ISO jne). Nüüd, kui nende enda äriprotsesside kirjeldus on kvaliteetne, on pankades asjad kõige paremad. Fakt on see, et erinevalt teistest äristruktuuridest on pank infrastruktuuri organisatsioon ja seetõttu on see seadusega määratletud rangetes regulatsioonides. Pank tegutseb päevajuhtimise põhimõttel. Selle tulemusel osutub isegi panga äriprotsesside lihtsustatud kirjeldus (vene keeles ilma märke kasutamata) üksikasjalikumaks, sest toetub vundamendile, mis on rajatud normide, terminite, rollide ja reeglite määratlemise eeskirjadele. Need standardid on panganduskeskkonnas üldtunnustatud keel ja äriprotsesside kirjeldus on hõlpsasti loetav igale spetsialistile.

IN kaubanduslikud struktuuridäriprotsesside kirjeldamiseks on vaja esialgset terminite sõnastikku. Ja seda ette valmistama ja kooskõlastama asudes seisavad paljud silmitsi tõsiasjaga, et samu asju kutsutakse erinevates osakondades erinevalt. Detailidesse süvenedes selgub, et erinevad nimed kannavad tegelikult erinevaid tähendusvarjundeid. Terminoloogia kooskõlastamine on äriprotsessi kirjeldamisel üks töömahukamaid protsesse. Oluline on see protsess käima lükata. Suurema osa tööst saan võtta enda kanda ettevõtte enda divisjonidelt, sest vajadus tegevust reguleerida toob kaasa protsesside ja protseduuride suurema korralduse.

Kui automatiseerimiseks on vaja kirjeldust, on võimalik ka vastupidine järjestus. Äriprotsesside muutmine toimub paralleelselt infosüsteemi juurutamisega ning uute äriprotsesside kirjeldamine toimub “kuumalt kannul” ning on süsteemi dokumentatsiooniga lahutamatu.

Personal

Ma unustasin kõik
Meid on nii palju aastaid õpetatud

Kummalisel kombel on tähistuse valik ja kirjelduse õigsus kriitilisemad väikeste ja keskmise suurusega ettevõtete jaoks. Suured ettevõtted on tavaliselt suurem protsessielastsus tänu töötajate vahetatavusele. Väikeettevõtte jaoks, kus kriitiliste punktide täitmine taandub 2-3 otsustajale, võib protsessi marsruudi ebaõige näitamine põhjustada põhimõtteliselt vale lahenduse kontseptsiooni. Kuna tulemus on kriitiline, siis tööriist on oluline, aga kuidas seda valida?

Iga märge on kohandatud teatud ülesannete vahemiku jaoks. Kõige pakilisemaks ülesandeks peame äriprotsesside muutmist juhtimise automatiseerimise projekti raames. Nendel eesmärkidel on olemas hea tööriistade komplekt, mis on üsna laialt levinud: need on Venemaa GOST-id ja samad ARIS ja IDEF, samuti EPC (joonis 4 ja joon. 5).

EPC märge

Äriprotsessi kirjeldus EPC abil

Kui raamat on kirjutatud kindlas keeles, siis on kõige tähtsam, et oleks lugeja, kes seda keelt oskab ja lugeda oskab. Selle põhjal on kõige levinum BP kirjeldamise standard parim.

Noodivalikul on teiseks oluliseks kriteeriumiks tuttava tarkvaratööriista kasutamise oskus. Näiteks Microsoft Business Solution pakkus 2002. aastal Navisioni infosüsteemi jaoks On-Target tähistust, millega kaasnes spetsiaalne tarkvaralahendus. See on täpselt nii, kui on parem valida midagi muud - mitte ainult ei tea keegi On-Target tähistust, vaid ka tarkvarakeskkond nõuab selle uurimiseks aega. Positiivseks näiteks nimetaksin IDEF-tähistuse ja programmi Visio kasutamist, mis on väga laialt levinud ja millel on IDEF-diagrammide joonistamiseks vajalik tööriistakomplekt (joonis 6).

IDEF-i äriprotsessid tehtud Visios

Muidugi saab toiteallika kirjeldust teha lihtsalt sõnadega, samuti kasutada erinevaid sümboleid (enda leiutatud), kuna see tundub arusaadav. Sellise kirjelduse olemasolu on parem kui mitte midagi, kuid standardite järgimine on siiski kasulik.

Heli täius ja sügavus

Ma ei tea, mis mind siia tõmbab

1. võtab kaua aega
2. Mõned üksikasjad muutuvad dokumendi loomise ajal.

Levinud viga on see, et püütakse kirjeldusi tähistusega sobitada. Näiteks püüdes kirjeldada protseduure ARIS-vormingus, s.t. saavutada kirjelduses näiline liiasus, kui seda ei nõuta.

Aga rohkemgi levinud viga dokumendi sügavus on ebapiisav. Selle tulemusena on tulemuseks ametlik dokument, mis ei sobi tööle, sest protsessi käigus tuleb selgitada kõik olulised üksikasjad.

Meloodia on helide jada, mitte noodid.

Unustage see päev
Keegi ei vaja argumente

See tähendab, et toiteallikat saab kirjeldada lihtsalt sõnadega, ilma igasuguste märkusteta. Muidugi on märge õigem, kuid see pole oluline. Kirjeldus BP ei ole lõpptoode, vaid ainult tööriist uuteks saavutusteks. See tähendab, et see tuleb kohandada edasiseks aktiivseks kasutamiseks. Enamiku isetehtavate dokumentide peamine probleem on see, et neid on ebamugav kasutada. Näiteks üks selline dokument koosnes Microsoft Wordis tehtu kirjeldusest ja PowerPointis tehtud joonistest, programmist programmi hüppamine oli kohutavalt ebamugav, pidin kulutama. suur hulk aeg panna see kõik ühte dokumenti. Selgub, et dokumendil peavad olema järgmised omadused:

1. Omama selget sektsioonide järjestust ja rühmitamist, st. ole kontseptuaalselt terviklik (tavaliselt tähendab see seda, et kui sul on mõiste olemas, siis oled õppinud seda kasutama);
2. Määrake selgelt äriüksused ning andke neile selged nimed ja nummerdamine;
3. Tõstke selgelt esile äriprotsessid ning andke neile ka selge nimi ja nummerdamine;
4. Elemendid tuleks nummerdada nii, et vältida segadust (see teeb otsingu palju lihtsamaks): näiteks osakonnal nr 1 peaks dokumendis olema number Dept.001 ja äriprotsessil nr 1 peaks olema number BP001 ;
5. Dokumendil peab olema puustruktuuriga sisujaotis;
6. Ettevõte on terviklik organism ja ükski äriprotsess ei jää õhku rippuma – see on alati seotud teiste äriüksuste, äriüksuste ja osakondadega. Nende seoste kajastamiseks võite kasutada hüperlinke – nii on lihtsam infot leida ja ühelt objektilt teisele liikuda.

Äritegevuseks võib kasutada kõike tekstiredaktor toetavad hüperlinke.

Mõned usuvad seda professionaalselt muusikarühm Piisab ühest või kahest pärismuusikust. Sellega ei nõustu ükski siiras muusikagurmaan. Need vestlused tekivad professionaalide ja loominguliste isikute puudumise tõttu.

Ettevõtetel on sarnased raskused. Häid spetsialiste, kes tunnevad oma ettevõtet pealaest jalatallani, on vähe ja nad on väga hõivatud. Äriprotsesse iseseisvalt analüüsides säästame raha ja võib-olla ka aega. Kuid alati ei ole võimalik toiteallika kirjeldamiseks valida parimaid. Võite usaldada rutiini madalama tasemega esinejatele, kuid siis on oht protsessiga edasi lükata. Selliste dokumentide koostamise põhimõtete mittetundmine toob endaga kaasa ebaefektiivsuse ohu (tulemus on kasutuskõlbmatu, see on sama, mis selle puudumine).

Parim kvaliteet ja kiirus dokumentide koostamisel on võimalik koostöös võtmespetsialisti ja kogenud konsultandiga. Tulemuseks on kokkulepitud keel äriprotsesside kirjeldamiseks (st ettevõtte äritegevuse terminoloogia) ja kirjeldus ise, millest piisab edasiste probleemide lahendamiseks.

Ma kordan vastuseks kõigile veenmistele
Nad ei lahuta meid, ei

Tuletame meelde, et kõik selle artikli epigraafid on võetud grupi Mirage laulust “Music Connected Us”

Kolmandast osapoolest konsultant koostab dokumendi noodikeeles, mis on teistele konsultantidele arusaadav ja sageli antud juhtumi jaoks sobivam. Kas sa ei mõista kõiki neid konkse? Kuid need tähistused pole sugugi keerulised, võib-olla tasub neid õppida?

Protsessimudel esindab ühtset, integreeritud funktsionaalsete, käitumuslike, informatiivsete ja organisatsiooniliste perspektiivide kogumit, kuid paljud tänapäeval ümberkujundamise praktikas kasutatavad mudelid seda ei rahulda.

12.10.2011 Igor Fedorov

Protsessimudel on funktsionaalsete, käitumuslike, informatiivsete ja organisatsiooniliste perspektiivide omavahel seotud integreeritud kogum, kuid paljud tänapäeval ümberkujundamise praktikas kasutatavad mudelid ei vasta protsessimudelitele esitatavatele nõuetele ja neid ei saa nimetada protsessimudeliteks, kuna need annavad ebatäieliku pildi protsessimudelitest. modelleeritud objekti ja ei sisalda kogu käivitatava mudeli loomiseks vajalikku teavet.

Vaidlused äriprotsesside modelleerimise tähistuse valiku üle ei vaibu endiselt. Analüüsitakse EPC (Event-driven Process Chains) ja BPMN (Business Process Modeling Notation) tähistuste, süntaksi, kirjelduskeele primitiivide komplekti jne võimalusi. Siiski on vale võrrelda tähistusi ja keeli kirjelduse kirjeldamiseks. äriprotsesse, analüüsides nende funktsionaalsust - kas mudel on funktsionaalne või protsessi määrab mitte ainult tähistus, vaid ka metoodika. Sageli asendub modelleerimismetoodika tähistusega, mis toob kaasa tõsiseid vigu äriprotsesside kavandamisel ja ebakvaliteetsete mudelite ilmumist.

Mudelid ja perspektiivid

Mudel- see on objekti või nähtuse materiaalne või vaimne esitus, mis kordab teatud omadusi, mis on konkreetse modelleerimise jaoks olulised, ja jättes välja muud ebaolulised omadused, mille poolest mudel võib prototüübist erineda. Keerulist objekti, näiteks äriprotsessi, kirjeldatakse mudelite komplektiga, millest igaüks kuvab piiratud hulga atribuute ja koos kirjeldavad nad modelleerimisobjekti täielikult. Iga konkreetne mudel on seotud põhiküsimusega, millele vastav mudel peaks vastama. Tuvastatakse neli äriprotsessi mudeli perspektiivi (vt joonis).

Funktsionaalne:"Mida osalejad teevad?" Kirjeldab tehtud töö ulatust.

Käitumine:"Kuidas osalejad töötavad?" Kirjeldab järjekorda, täitmise ajakava, ärireegleid.

Informatiivne:"Mida osalejad töötlevad?" Kirjeldab protsessi domeeni äriüksusi.

Organisatsiooniline:"Kes teeb tööd?" Kirjeldab esinejate koosseisu ja struktuuri.

Teatud vaatenurka kirjeldav mudel vastab mitmele küsimusele, kuid nende hulgas on alati üks peamine, millele mudel peab andma ammendava vastuse, mitte aga ei pruugi täielikult vastata täiendavatele. Viimasel juhul peate olema eriti ettevaatlik, mudeli perspektiivi määrab täpselt põhiküsimus, mitte abiküsimus.

Funktsionaalne perspektiiv

Funktsionaalne mudel kirjeldab süsteemi staatilises olekus ja aitab vastata küsimusele "mida on vaja eesmärgi saavutamiseks teha?" Vastuseks on nimekiri kõigist toimingutest, mida tuleb kavandatud tulemuse saavutamiseks teha. Laialdaselt kasutatav projektijuhtimises tööjaotuse struktuur(Work Breakdown Structure) - selles loetletud toimingud ei ole seotud ajalise jadaga. Samamoodi on protsesside modelleerimisel väga kasulik luua struktuurne jaotus, mis aitab mõista protsessi loogikat ja meeles pidada mis tahes olulise funktsiooni täitmist. Kui kaks erinevat organisatsiooni teostavad sama protsessi, siis on nende funktsionaalne tööjaotus sama, kuigi tööde teostamise järjekord võib nende erinevusi arvestades muutuda organisatsiooniline struktuur. Seega on funktsionaalne mudel nõrgalt sõltuv organisatsiooni struktuurist ja seda võib pidada võrdlusmudeliks.

Sageli nimetatakse funktsionaalset mudelit ekslikult protsessikaardiks; Näiteks mudelid SCOR (The Supply-Chain Operations Reference-mudel) ja ETOM (Enhanced Telecom Operations Map) sisaldavad funktsioonide ja väärtusahelate hierarhiat, kuid mitte protsesse. Isegi TeleManagement Forumi juhised nõuavad eristama protsessi kui sooritatavate toimingute jada ja protsessi kui ettevõtte tegevuse suunda.

Käitumusliku vaatenurga aspektid

Käitumuslik perspektiiv, mis kirjeldab süsteemi dünaamikat, vastab küsimusele "kuidas osalejad toimivad?" Selle modelleerimiseks kasutatakse juhtimise vooskeemi. Peamine küsimus on "kuidas?" võib jagada kolmeks: „Mis järjekorras tehakse protsessi moodustavad toimingud? Mis kell operatsioon tehakse? Miks tehakse toiminguid etteantud järjekorras?

Esimesele küsimusele annab vastuse äriloogika, mis kujutab endast tööde teostamise järjekorra protseduurilist kirjeldust, selle graafiliseks kuvamiseks kasutatakse töövooskeemi. Teisele annab vastuse protsessi teostamise ajakava, mis määrab selle või teise töö tegemise aja, selle tegemata jätmise aja ja toimingud, mida tehakse täitmisgraafiku rikkumise korral. Kolmandale küsimusele annavad vastuse ärireeglid, mis on protsessile seatud piirangute deklaratiivne kirjeldus.

Protsessi äriloogika

Protsessi moodustavate toimingute jada nimetatakse tavaliselt äriloogikaks ja selle kirjeldamiseks kasutatakse töövooskeeme (UML, EPC, ABC Flowchart – kirjeldused vooskeemide alusel). Äriloogika sisaldab selgesõnalist, ettekirjutavat teavet protsessi teostamise marsruudi kohta, kuid ainult kaudselt võtab arvesse asjakohaste otsuste tegemise kriteeriume.

Protsessi diagramm sisaldab "hargnemise" elementi, mis võimaldab teil protsessi täitmist mööda ühte etteantud marsruutidest vastavalt etteantud tingimustele suunata. Hargnemine on äriloogika element ja tingimus, mille järgi hargnemine toimub, on ärireegel. Sageli ei eralda ärianalüütikud loogikat ja reegleid ning panevad diagrammile hargneva elemendi, vaid jätavad sellega seotud hargnemisreegli vahele.

Äriloogikat kirjeldavad diagrammid tunduvad visuaalselt lihtsad ja selged, kuna need ei sisalda ärireegleid, täitmisgraafikuid ega parandusmeetmeid, mida võetakse, kui protsessinäitajad jäävad väljapoole vastuvõetavaid vahemikke, mistõttu paljud analüütikud kasutavad neid äriesindajatega kooskõlastamiseks. Lihtsus on aga petlik – IT-süsteemide arendajad peavad puuduva info uuesti kokku korjama ning nende arusaam protsessist võib analüütiku seisukohtadest vägagi erineda. Selle tulemusena ei kirjelda mudel protsessi täielikult, üksikasjad pole selgelt salvestatud, vaid eksisteerivad ainult programmeerijate peades. Sellest tulenevalt ei vasta paberil olev protsessimudel IT-süsteemi loogikale – just need ebatäpsused äriprotsessi esialgses kirjelduses toovad kaasa arvukalt muudatusi, mis tekivad infosüsteemide juurutamise etapis.

Ärireeglid

Ärireeglit mõistetakse üldiselt kui väidet, mis määratleb või piirab ettevõtte mõnda aspekti. Erinevalt protseduurikirjeldusest postuleerivad reeglid piiranguid protsessi läbiviimisele, kuid ei täpsusta, kuidas täpselt tulemust soovitakse saavutada. Ärireeglite ekspert Ronald Ross annab ärireeglitele järgmise klassifikatsiooni:

• käitumisreeglid määravad kindlaks asjakohase toimingu tegemise ja kontrolltoimingute rakendamise vajaduse;
• määratlusreeglid kehtestavad mis tahes ärikontseptsiooni, mida nimetatakse faktiks, kohaldatavuse kriteeriumi;
• arvutusreeglid aitavad välja selgitada soovitud koguste väärtused, mida nimetatakse faktideks; näiteks kaubandussoodustuse saab määrata teatud perioodi ostude kogumahu järgi jne;
• klassifitseerimisreeglid aitavad kontrollida faktide õigsust; Näiteks loetakse klienti VIPiks, kui tal on kontol teatud summa ja tal pole tasumata makseid.

Protsessi hargnemine toimub käitumisreegli alusel, mis vahetab marsruute vastavalt argumendi väärtusele, mis võtab väärtused "true" või "false", kuid mis on "tõene" ja mis on “false” määrab klassifitseerimisreegli, mis omakorda peab saama sisendina mingi arvutusreegli abil saadud väärtuse. Näiteks kujutage ette järgmist toimingute jada: arvutage allahindlussumma jooksva tellimuse suuruse funktsioonina (arvutusreegel); liigitage allahindluse suurus: suur, keskmine, madal (klassifikatsioonireegel); esitama tehingu kinnitamiseks vastava volituste tasemega juhile (käitumisreeglid). Levinud on aga tige praktika paigutada diagrammile “hargnev” element, millesse on otseselt lisatud nii käitumisreeglid kui ka definitsioonireeglid, mis muudab diagrammi paindumatuks ja kirjelduse puudulikuks. Seega tuleks kõik reeglid töövooskeemil selgesõnaliselt eraldada eraldi konstruktsioonideks, mis aitavad analüütikul vastavat loogikat selgelt lokaliseerida.

Täitmise ajakava

Materjalitootmise valdkonnas kasutatakse toote valmistamisele kuluva aja arvestamiseks laialdaselt kasutatavat töögraafikut. Äriprotsesside jaoks on töögraafikus rohkem keeruline välimus, kuna iga toimingu saab õigeaegselt lõpule viia, kuid kogu protsess võib viibida, kuna tagastatakse uuesti töötlemiseks.

Äriprotsesside kirjeldamiseks kasutatav ajaontoloogia sisaldab kahte põhimõistet: sündmused ja intervallid. Sündmus on punkt ajaskaalal, millel pole kestust. Sündmusi kasutatakse erinevate protsesside või sama protsessi harude teostamise koordineerimiseks. Intervalli mõistetakse ajaskaalal lõiguna alg- ja lõppsündmuste vahel. Intervallid võimaldavad teil määrata ajapiirangu, mis on määratud üksiku toimingu või toimingute rühma täitmiseks.

Äriprotsesside modelleerimise tähistuste võrdlemisel peaksite analüüsima, kas need toimivad põhimõistetega "sündmus" ja "ajavahemik". See aitab mõista, kas tähistus võimaldab modelleerida protsessi ajastuskarakteristikuid ning koordineerida protsesside ja nende harude täitmist. Meie tähelepanekud näitavad, et paljud äriprotsesside modelleerimise tähistused ei kasuta neid põhimõisteid.

Äriloogika detailsusaste

Küsimusele “kuidas?” vastamiseks peab juhtskeem sisaldama nii palju Täpsem kirjeldus toimingud, mis moodustavad protsessi. Paljud analüütikud piirduvad funktsioonide loetlemisega, täpsustamata nende täitmise üksikasju, eeldades, et teostaja teab, kuidas tööd tuleks teha. Kuid praktikas kalduvad töötajad tegema tööd oma individuaalsete kogemuste põhjal, mis toob kaasa suure varieeruvuse protsesside teostamisel. Modelleerimismärgid ei määra kirjelduse detailsust, jättes selle küsimuse analüütiku hooleks. Määratleme täpsustamise kriteeriumid.

Venemaa riikliku standardi juhenddokument "Funktsionaalse modelleerimise metoodika IDEF0" tutvustab mõisteid "tegevus" ja "operatsioon". Toiming on määratletud kui "materjali või teabeobjekti mis tahes omaduse muutmine teiseks omaduseks" ja toiming on määratletud kui "järjestikuste ja/või paralleelsete toimingute kogum".

Selgitagem neid definitsioone protsesside modelleerimise puhul. Tegevus kutsume protsessi objektil osaleja tehtud tööd, mis muudab seda objekti, kuid ei too kaasa muutust selle olekus; näiteks on osaleja sisestanud uued andmed, kuid see ei tähenda avalduse menetlemise lõppu. Operatsioon nimetame tegevuste kogumit, mis viib objekti oleku muutumiseni; Näiteks pärast kõigi kontrollide lõppu võidakse taotlus heaks kiita.

Töövoo diagramm piirdub tavaliselt tegevustasemega. Arvatakse, et liigne detailsus raskendab protsessi loogika mõistmist. Juhtskeem peaks andma ammendava vastuse küsimusele, kuidas protsess toimub, ja sellel peab olema üksikasjalik tegevustase. Selle tulemusena osutuvad sellised diagrammid liiga üksikasjalikuks ja võivad olla detailidega üle koormatud. See on aga pigem modelleerimisstiili küsimus – mitmetasandilised struktureeritud mudelid võivad kombineerida diagrammi ülaosas äriloogika lihtsust ja allosas üksikute toimingute üksikasjalikku kirjeldust.

Protsessi äriloogika täielikkuse aste

Enamik töövooskeeme kirjeldab piiratud komplekti täitmise stsenaariume, tuvastades ainult kõige ilmsemad marsruudid. Need ei hõlma harva täidetavaid stsenaariume ega ignoreeri eri- ja erandolukordi. Sellisel teostuse mittetäielikul kirjeldusel on õigus eksisteerida, kui plaanitakse funktsionaalsust välja töötada infosüsteem, kus isik määrab toimingute sooritamise järjekorra. Protsessile orienteeritud süsteemi ehitamisel määrab toimingute järjekorra aga süsteem ise, mistõttu peab mudel katma kõik võimalikud täitmisstsenaariumid, sh kontrolli naasmine eelmisele sammule või teatud töötlemisetappe mööda minevad üleminekud, Arvestage probleemi eskaleerumise võimalusega, erandolukordade käsitlemisega, vastasel juhul osutub süsteemi toimimine võimatuks.

EPC ja BPMN tähistuste võrdlev analüüs

Oleme näidanud, et tuleb eristada töövoo diagramme, juhtimisvooskeemi ja protsessimudeli diagramme. Töövooskeem määratleb äriloogika, toimingute teostamise järjekorra, on tegevustasandi üksikasjadega, ei sisalda protsessi teostamise ajakava ega pruugi protsessi ärireegleid täielikult määratleda. Juhtimise vooskeem selgitab töövooskeemi täitmise ajakava ja ärireeglite osas, sellel on üksikasjalik toimingute tase, peab kirjeldama kõiki täitmisvõimalusi ehk teisisõnu kirjeldab tehnoloogiat, mis tagab kavandatud tulemuse saavutamise etteantud toimingute komplekti täpse täitmise sündmus. Vähemalt ühe komponendi puudumisel jääb kirjeldus puudulikuks ja tehnoloogiat ei järgita. Protsessimudel on omavahel seotud vaatenurkade kogum, millest igaüks kirjeldab protsessi käitumise üksikuid aspekte ning koos moodustavad integreeritud, tervikliku ja tervikliku ülevaate protsessist ja selle teostamisest. Muuhulgas kirjeldab juhtimise vooskeem äriprotsessi mudeli käitumuslikku perspektiivi.

EPC-tähistus on vahend protsessi äriloogika kirjeldamiseks. Nagu võrdlus näitab, võimaldab tähistus rakendada põhilisi äriloogika mustreid, jäämata teistest protsessikirjelduste märkidest halvemaks. EPC diagrammid ei sisalda sageli ärireegleid, kuid seda puudujääki ei tohiks seostada tähistusega per se, vaid rakendusmetoodikaga. Täitmisgraafiku osas tuleb märkida, et täitmisaja karakteristikute modelleerimiseks puuduvad vahendid. EPC märge sisaldab konstruktsiooni "sündmus", kuid seda kasutatakse juhtobjekti oleku kirjeldamiseks, mitte täitmise sünkroonimiseks. EPC metoodika ei keskendu saadud diagrammide detailsusele ja täielikkusele, jättes selle küsimuse analüütiku hooleks. Range regulatsiooni puudumisel püüavad analüütikud tagada diagrammide lihtsuse ja loetavuse, seetõttu piirduvad nad toimingute taseme kirjeldamisega ega püüa tuvastada kõiki täitmismarsruute. EPC-tähistust kasutatakse sageli automatiseerimiseks, kasutades funktsioonidele orienteeritud süsteeme, kus inimene mängib juhtivat, suunavat rolli, seega pole täitmisskripti puudumine ohtlik. Kõik see võimaldab meil klassifitseerida EPC-mudeleid töövoo diagrammideks.

ARISes sisalduvatel tähistustel on äärmiselt võimsad protsesside modelleerimise võimalused, kuid avatud ja kasutajale juurdepääsetavad metoodikad neid ei toeta. Dokument “ARIS Metoodika” ei kirjelda metoodikat, vaid tähistuse kasutamise reegleid, mis võimaldab laialdasi võimalusi modelleerimismeetodite “tõlgendamiseks”.

EPC probleem seisneb katses kohandada seda tööriista liiga paljude probleemide lahendamiseks, ilma konkreetse juhtumi puhul kohaldamisreegleid selgitamata. Selle tulemusena rakendavad analüütikud paljusid kujundusi ja mehhanisme intuitiivselt ja alateadlikult. Mõnikord võib nende kavatsusest probleemi kontekstist aru saada, kuid on ebatõenäoline, et kaasaegne arvuti suudab diagrammi käivitatavasse vormingusse teisendamisel konteksti ise analüüsida.

BPMN-i tähistus kirjeldab protsessi loogikat. Natuke parim tugiäriloogika mustrid, võrreldes EPC-ga, ei ole otsustav eelis. Tähistus toimib mõistetega "sündmus" ja "ajavahemik" ning sisaldab vahendeid protsessiharude ja protsesside omavaheliseks sünkroonimiseks. Märgistus ise ei soovita loogikat reeglitest eraldada, kuid õige modelleerimisstiili juhised sisaldavad sellist soovitust. BPMN-i tähistust kasutatakse protsessile orienteeritud süsteemide loomiseks, kus isik mängib alluvat rolli ja süsteem mängib juhtivat rolli, nii et ühe, isegi kõige haruldasema stsenaariumi vahelejätmine ei võimalda tööd lõpetada ja seetõttu on vastuvõetamatu; sellest tulenevalt katavad BPMN-i mudelid kõik täitmisestsenaariumid. BPMN-i mudelid on käivitatavad mudelid, nii et need kirjeldavad kõiki üksikasju kuni kõige elementaarsemate toiminguteni. Kõik ülaltoodu võimaldab meil klassifitseerida BPMN-i diagrammi juhtimisvoo mudeliks.

Probleemid BPMN-i tähistusega on seotud sellega, et diagrammid on reeglina detailide ja detailidega ülekoormatud ning seetõttu raskesti loetavad. Lahendusena näib olevat hierarhilise konstrueerimise metoodika väljatöötamine mitmetasandilised mudelid, kus ülemine tase kirjeldab kogu protsessi täitmiskonteksti, keskmine tase kirjeldab täitmisloogikat ja alumine tase kirjeldab üksikoperatsioonide rakendamise üksikasju.

Huvi BPM-i ja BPMS-i (Business Process Management Suite) vastu on jõudnud küpsusastmeni, kus moest pole enam vaja rääkida. Lisaks lõppes standardite sõda ja BPMN-i tähistus pälvis tunnustuse kõigilt suurematelt tegijatelt, saades de facto standardiks. Seda sündmust võib olulisuselt võrrelda SQL-i tekkega, millest sai tänapäevaste infosüsteemide alus.

BPMS on lõpuks kujunenud klassiks tarkvara toetuse eest graafiline modelleerimineäriprotsessid, äriprotsessimudelite teostamine, monitooring ja analüüs (Business Activity Monitoring, BAM). Erinevad tooted rakendavad seda funktsionaalsust aga erineval viisil ning konkreetse BPMS-i valikul tuleks esmalt arvestada järgnevaga.

• BPMN tugi. Millist BPMN-i versiooni toetatakse (1.x või 2.0)? Kui täielik on juurutamine: kas sõnumid, signaalid, tehingute alamprotsessid on toetatud?

• BPMN-i protsessimootori tüüp. Otsene täitmine on eelistatavam kui tõlkimine mõnele muule esitusviisile - ainult sel juhul on võimalik praktikas rakendada pidevat äriprotsesside täiustamist.
• Suhtlus protsesside ja andmete vahel. Eelistatav on salvestada atribuute umbes
protsessi maksimaalselt avatud vorm– relatsioonilise DBMS-i tabelites ja veergudes, mis tagab viiteterviklikkuse, kõrged tööomadused ja juurdepääsuvabaduse andmetele väljastpoolt, erinevalt näiteks atribuutide XML-stringina salvestamisest.
• Kasutajaliides. Liides peaks olema funktsionaalne ja ergonoomiline
ja arendada kiiresti, võimalusel ilma programmeerimiseta. Süsteem peaks võimaldama ärianalüütikul luua toimiva kasutajaliidese, mida saab soovi korral programmeerija kaasamisel muuta.
• Süsteemi platvorm. Olenevalt ettevõtte tehnilisest poliitikast, valik
võib piirduda Java platvormiga või. Net – mõlemat platvormi toetavad BPMS-id on haruldased.
• Litsentsiskeem. Shareware süsteemid võimaldavad säästa raha
litsentsid, kuid nõuavad suuri arendusressursse; Mõned kommertssüsteemid on kallid isegi minimaalsete konfiguratsioonidega.
• Esinduse või partneri olemasolu Venemaal.

Ei tasu unustada, et BPMS on vaid üks BPM-i komponentidest ning äriprotsesside juhtimissüsteemi loomise projekti õnnestumiseks on vajalik ka metoodika ja agiilse projektijuhtimise pädevus.

Anatoli Belaitšuk ([e-postiga kaitstud]) – ettevõtte “Business Console” president (Moskva).

Probleemid EPC diagrammi tõlkimisel käivitatavasse vormingusse

EPC-märgistuses modelleerimise tulemused ei vii alati mudeli loomiseni, mida saab ilma oluliste muudatusteta teisendada käivitatavasse BPM-vormingusse.

Loetleme tüüpilised modelleerimisvead.

Algajate analüütikute jaoks kirjeldab EPC mudel kõige tõenäolisemat täitmisvõimalust, jättes välja harva kasutatavad alternatiivsed marsruudid: nende diagrammides näete harva ebastandardsete ja erandlike olukordade toimingute kirjeldusi.

Väga sageli ei hõlma mudelid täielikult kõiki otsustuskriteeriume. Seetõttu tuleb ärireeglite täpsustamiseks mudel uuesti välja töötada.

Analüütikud ei pööra tähelepanu protsesside juhtimisobjekti muutustele. Kujutagem ette kirjeldust tehnoloogiline protsess, sealhulgas komponentide tootmine. Kui komponente toodetakse eritellimusel, siis saab põhiprotsessi lisada ka nende valmistamise kirjelduse, aga kui komponente toodetakse põhiosaga asünkroonselt, siis peaks nende valmistamine olema eraldi protsess oma juhtimisobjektiga. Analüütik peab protsessi juhtimisobjekti hoolikalt jälgima, kuna selle muutumine on märk kogu protsessi võimalikust jagunemisest interakteeruvate protsesside ahelaks.

Protsessi ebapiisav detailsus toob kaasa vajaduse puuduvaid detaile uuesti selgitada ja kirjeldada arendatava IT-süsteemi nõuete koostamise etapis.

EPC diagrammid ei kirjelda täitmisgraafikuid ja jätavad välja ühe protsessi harude omavahel ja teiste väliste protsessidega sünkroniseerimise probleemid.

Seega võib öelda, et EPC probleemid seisnevad selle rakendamise metoodika valdkonnas ja modelleerimislepingu olemasolus, mis määratleks kõik arendatava mudeli detailid, enamik probleeme, välja arvatud täitmise ajastuse parameetrid, saaks vältida.

Mitte tähistus, vaid metoodika ei määra, kas mudel on funktsionaalne või protsess. Protsessi mudel on mitmekihiline kirjeldus, mis sisaldab omavahel seotud funktsionaalsete, käitumuslike, informatiivsete ja organisatsiooniliste perspektiivide kirjeldusi. Käitumusliku perspektiivi kirjeldamiseks tuleks kasutada kontrolli vooskeemi, mis annab ammendava vastuse küsimusele “kuidas protsess toimub?”, sh määratleb toimingute jada, ärireeglid, täitmise ajakava, kirjeldab üksikasjalikult tegevuste taset ja kirjeldades kõiki võimalikke teostusstsenaariume. Töövooskeem, mida põhjendamatult nimetatakse protsessimudeliks, ei kirjelda kõiki protsessi käitumise üksikasju ega ole protsessiskeem.

Paljud ümberprojekteerimises kasutatavad mudelid ei vasta kõigile loetletud nõuetele ja seetõttu ei saa neid protsessimudeliteks nimetada. Tekib küsimus: võib-olla siin peitubki nende äriprotsesside ümberkujundamise projektide ebaõnnestumine?

Kirjandus

1. B. Curtis, M. Kellner, J. Over. Protsessi modelleerimine, 1992.
2. eTOM, esindusprotsesside vood. ITU. s.l.: ITU telekommunikatsiooni standardimise sektor, 2004.
3. R. Ross. Ärireeglite lähenemisviisi põhimõtted. Addison-Wesley Professional (2003).
4. C. Pedrinaci, Domingue, A. Alves de Medeiros. A Core Ontology for Business Process Analysis, Proceedings of the 5th European semantical web Conference on The semantical web: research and applications, Springer-Verlag Berlin, Heidelberg, 2008.
5. Funktsionaalse modelleerimise metoodika IDEF0. Moskva: Venemaa Gosstandart, 2000.
6. N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Workflow control-flow patterns.
7. Meetodid ARIS 7.0. Saarbrücken: IDS Scheer AG, 2005.
8. B. Hõbe, BPMN meetod ja stiil. Cody-Cassidy Press, 2009.

Igor Fedorov ([e-postiga kaitstud]) – MESI (Moskva) protsessijuhtimise kompetentsikeskuse direktor.

Äriprotsesside modelleerimine, modelleerimise perspektiiv, funktsionaalne ja protsesside modelleerimine

"Lohed, pimeda mehe buff ja silt
Peitust, pallid, hüppekonn ja hüppenöörid,
Ja lihtne ja lihtne ja lihtsalt hüppenöörid,
Noh, lihtne, lihtne, ainult hüppenöörid!!!”

A. Vratarev

Seda artiklit ette valmistades avastasin uskumatu fakti: nii lihtsa ja populaarse EPC tähistuse kohta (on arvamusi, et see on isegi populaarsem kui BPMN) on Vikipeedias artikleid ainult neljas keeles: inglise, saksa, tšehhi keeles. ja usbeki keel. Pealegi on need artiklid üsna lühikesed. Võib-olla mõistame artikli lõpuks teie ja mina, kallis lugeja, miks.

Alustan sellest, et EPC tähistus töötati välja 1990. aastate alguses. ARISe metoodika kui näiteks selle protsessikomponendi väljatöötamise käigus. EPC asutaja isaks peetakse professor Wilhelm-August Scheeri, kelle nimi üksi tekitab keskmises inimeses aukartust (öelge see valjusti ja tundke inspireerituna). Mida öelda selle teaduskonna nime kohta, kus see lugupeetud tüüp töötas: Saarlandi Ülikooli Universität des Institut für Wirtschaftsinformatik.

EPC tähistuse loomise eesmärk oli võime kirjeldada protsesse nii, et nende sees täidetavatel funktsioonidel oleks diagrammis globaalne semantika, mis tähendab, et funktsiooni täitmine EPC diagrammidel ei pruugi olla selgelt määratletud, vaid võib sõltuda diagrammi teiste sõlmede olek, mõnikord üksteisest väga kaugel.

Märke nimi tähistab Event-driven Process Chain, mis näitab selgelt, et EPC tähistusskeemide keskne element on sündmused. Sündmused põhjustavad teatud osalejate teatud toiminguid. Toimingute lõpetamine genereerib omakorda teise sündmuse ja nii edasi, kuni süsteem jõuab olekusse, mille ilmnemist protsessi sees loetakse lõppsündmuseks.

Märkimisvõimaluste selgeks demonstreerimiseks kasutan igapäevast näidet, mis on inspireeritud hiljuti lõppenud puhkusest soojemas kliimas. Lugupeetud hotelli administraator Ivo Petkov saab ühelt külaliselt palve tema toas kraanikausid kiiresti välja vahetada. On täiesti selge, et tema ülesanne on täita kliendi soov ja EPC mõistes viia süsteem olekust “Kliendilt saabunud taotlus kraanikausi vahetamiseks” olekusse “Kliendi soov on rahuldatud”.

Kuvame kaks näidatud olekut diagrammi mustandil ja märkame kohe, kui lihtne on meie diagrammi lugeda, sest igal selle elemendil pole mitte ainult oma kuju, vaid ka oma värv. Seega on sündmused punased kuusnurgad, funktsioonid rohelised ümarate servadega ristkülikud ja esinejad on kujutatud kollaste ovaalidena.

Nii et lähme tagasi näite juurde. Kohe peale kliendilt päringu saamist peab Ivo saatma toateenijale palve kliendi soovi täitmiseks, viies sellega süsteemi olekusse “Täitmisnõue saadetud”. Neiu, kasutades laos olevaid tarvikuid, täidab Ivo palve. Ja siin ilmneb esimest korda meie protsessi paralleelsus: kui neiu saab aru, et vajalikke pesuvahendeid (näiteks dušigeeli) pole hetkel laos, siis ta ise, võib-olla tahtmatult, üle kanda süsteemi " taotlus on võimatu” olek. millest loomulikult järeldub, et Ivo peab kliendiga pidama mitte just meeldivat vestlust ning see, millisesse olekusse süsteem läheb, sõltub ainult kliendi meelelaadist ja kaklemiskalduvusest. Kui laos on kõik külalisele vajalikud varud olemas, siis neiu täidab edukalt temale üle kantud soovi, teatab täitmisest Ivole, kes omakorda annab sellest kliendile teada. Ja kõik elavad õnnelikult elu lõpuni ja surevad samal päeval.

See lihtne protsess kajastub sellises rõõmsalt pilgutavas punases, rohelises ja kollases diagrammis nagu joonisel 1.

Riis. 1. EPC diagramm kliendi päringu menetlemise protsessist hotellis

Ja nüüd, vastavalt traditsioonile, noodikirja eelised ja puudused.

Kui ma esimest korda EPC diagrammidega kokku puutusin, olin ma, nagu juba varem mainisin, väga rahul sellega, kui lihtne neid lugeda oli: iga plokk on kuju ja värvi poolest esile tõstetud, väga lihtne on näha esinejaid, vajalikke materjale, nimekirja esile tõsta. võimalikest süsteemi olekutest, funktsioonide protsessi käigus sooritatavate olekute loend. See on kahtlemata tohutu pluss: kliendil ei teki raskusi äriprotsesside diagrammi lugemisega EDMSi rakendamine, kui see on esitatud täpselt EPC-tähistuses. Küll aga võib-olla ajab klient segadusse nii hiiglaslik olekute arv, sest tegelikult nende tõttu vooluring kõvasti kasvab. Isegi meie näites: mingid 4 funktsiooni genereerisid koguni 5 olekut (arvestades algset). Vahel mõtled: miks neid kõiki välja tuua. Miks see vajalik on, räägime pärast lepingu kokkuleppimist peadirektor märkida eraldi lahtrisse “Leping kokku lepitud” ja pärast allkirjastamist – “Leping allkirjastatud”, kui edaspidi jääb protsess siiski lineaarseks. Ausalt öeldes pole vaja, välja arvatud juhul, kui olete Captain Obvious.

Ja mõnikord pole selge, kuidas tuvastada olekut, millesse funktsioon süsteemi üle kannab. Isegi seda lihtsat näidet valmistades kogesin teatud raskusi, mis olid seotud just selle hetkega.

EPC diagrammide eeliseks on asjaolu, et sarnaselt IDEF0 diagrammidele saab neil näidata iga funktsiooni sisend- ja väljundandmeid ning jälgida sisend- ja väljundandmete liikumise loogikat plokist plokki. Lisaks, erinevalt samast IDEF0-st, sai võimalikuks protsessi paralleelsus, suunates selle ainult ühte alternatiivsetest harudest (IDEF0-s, kui lisada täitmisel paralleelsus, täidetakse kõik paralleelsed funktsioonid üheaegselt). Samuti tundus mulle eeliseks see, et sain iga etapi (loe: funktsioonid) tegija määrata.

Aga! IDEF0-s näidatakse täitjat üks kord igal lagunemistasemel ja tema nimel tõmmatakse nooled kõikidele tema poolt täidetavatele plokkidele. EPC-s peame selleks, et arvutada, kui palju toiminguid täitja teeb, läbima kõik toiminguplokid ja kontrollima, kas selles on märgitud meile vajalik täitja.

See märge tundus mulle protsessi täitmise jälgimise seisukohalt väga mugav: iga funktsioon kannab kindlasti süsteemi uude olekusse, millest järeldub, et peale iga funktsiooni täitmist saab süsteemist kontrollida, kas üleminek soovitud režiimile riik viidi tegelikult läbi. Kuid kohe tekkis küsimus: kas see on tõesti vajalik? Näiteks mul on harva selline soov =)

Nii et üldiselt tundub mulle EPC tähistus äriprotsesside kirjeldamisel ebamugav: liiga palju tähelepanu sündmustele, liiga vähe tähelepanu tegevustele ja eriti nende grupeerimisele sooritaja või kasutatud materjalide alusel. Jah, ta on lihtne, jah, ta on ilus ja jah, kahjuks, see on kõik, mida ma tema kohta öelda saan, nagu ilmselt paljud teisedki. =)

Ja artiklid UML-i ja BPMN-i tähistuste kohta tulevad üha lähemale.

(4,14 - hinnatud 21 inimese poolt)