Abazhur Group on spetsialiseerunud EPC / EPCM lepingutel põhinevate erinevate ehitusprojektide elluviimisele ... Kuid neile, kes otsivad ja ei tea veel, mis on EPC ja EPCM, pakume materjalide kogumit, mis loodetavasti on abiks meie koostööpartneritele ja klientidele kodumaise praktika suhteliselt uute instrumentidega nagu EPC-, EPC(M)-lepingud.

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

Abazhur Group on spetsialiseerunud EPC / EPCM lepingutel põhinevate erinevate ehitusprojektide elluviimisele, aga ka muudele individuaalsete tingimustega ehituslepingutele. , rakendab ehituses süsteemseid lahendusi kasutades BIM modelleerimist, loob madalat 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 töölepingu tüüp võib kaasa tuua märkimisväärse muutuse suurte ja suurte ehitiste ehitamisega seotud kulude ja riskide tasemes. Kulude tase on proportsionaalne kliendi poolt võetud riskidega. Omaniku võetavate äririskide vähenemisega suurenevad rajatise ehitamise ja haldamise kulud. Igas äris kinnitab seda loogiliselt riski-tulu seos.

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 teostamiseks vajalike seadmete ja materjalide valik, ostmine ja tarnimine;
• Objekti ehitamine (Ehitus)– ehitamine, montaaž ja kasutuselevõtt;
• Kõigi ehitusprotsesside juhtimine (ehitusjuhtimine).

Lepingustrateegia suurte ehitusprojektide elluviimisel

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 ehitustööde teostamisega projekteerimis- ja töödokumentatsiooni välja töötada ja väljastada. paigaldustööd.

Näiteks, ei pruugi EPC töövõtja oodata kogu projekti dokumentatsiooni väljatöötamist ja kinnitamist, et alustada seadmete hankimist pikaks tootmistsükliks.

Paralleelprojekti tõhus kasutamine paljudel juhtudel võimaldab 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, milleks ajaks tuleb ehitada gaasipuhastusjaam, vastasel juhul on projekti üldine kasumlikkus tõsiselt halvenenud. Sellistel juhtudel on põhjendatud projekti elluviimise EPC mudeli kasutamine, mis vaatamata suuremale maksumusele võimaldab ehituse valmis saada lühema ajaga.

Iga lepingustrateegia on "traditsiooniline" kliendi jõudude juhtimise mudel ning EPC mudelil on 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 riskijagamise mõttes jääb mitme partii 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 ega sõlmi enda nimel allhankelepinguid.

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 sisse ka asjaolu, et ükski juhtiv rahvusvaheline organisatsioon (FIDIC, ICC Orgalime) ei ole välja andnud EPC(M) lepingu proformi.

* 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, tarnimine, ehitusjuhtimine". EPC(M) mudelis viitab sõna juhtimine kõige sagedamini konkreetselt ehitusele selle sõna kitsas tähenduses, s.t. teostada objektil ehitus- ja paigaldus- ning muid töid.

Arvestades eelnevalt tehtud reservatsioone terminoloogia ebamäärasuse osas:

EPCM-lepingut mõistetakse kõige sagedamini sellise struktuurina, kui EPC(M) töövõtja omal käel või jõud 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 ainult tellija nimel tellija palgatud töövõtjaid.

Põhiline erinevus EPC(M) lepingu ja EPC lepingu vahel seisneb selles, et EPC leping on kokkulepe "vastutuse ja riskide võtmise kohta"

EPC lepingu sõlmimisega klient lükkab riskid ja vastutuse suures osas üle EPC töövõtjale mis peab selle vastutuse varustama 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 seetõttu on see eranditult stimuleeriv.

EPC(M) lepingus on hinna struktureerimiseks erinevaid võimalusi, kuid see pole kunagi kindel. Sageli on hind kombinatsioon ajamääradest (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 tellija jaoks läbipaistval viisil ja tema esindajate osalusel;
• töövõtja avalikustab oma üldkulude struktuuri ja eeldatava kasumi suuruse ning sellised üldkulud/kasumid kas fikseeritakse teatud summas või lisatakse protsendilise lisatasuna iga tarnelepingu maksumusele.

Nagu juba märgitud, on EPC(M) töövõtja vastutus väga piiratud ja sarnaneb rohkem konsulteeriva inseneri (kes vastutab ainult oma teenuste ebaausa või ebakompetentse osutamise eest) kui peatöövõtja vastutusega.

Samas on üsna sageli EPC(M) lepingutes ette nähtud töövõtja motiveerimismehhanismid, kasutades põhimõtteid. boonus/malus (nn kasumi jagamine / valu jagamine).

Näiteks, võib lepingus ette näha, et rajatise kasutuselevõtt rohkem kui varajane tähtaeg töövõtja saab lisatasu, hilinemise korral jääb töövõtja vastupidiselt osa kasumist ilma.

Samamoodi saab soodustusi ehitada kogusumma suhtes: pooled saavad seada kindla sihteelarve ning kui ehitust efektiivselt juhtides saavutab töövõtja kokkuhoidu, siis see kokkuhoid jagatakse osapoolte vahel kokkulepitud proportsioonis. Samas ei ole EPC(M) töövõtja boonuse/malus kokkuleppimisel tavaliselt valmis kogu tasuga riskima ja seetõttu ei anna see mehhanism tellijale täielikku mugavust maksumuse ja ehitusaja osas, vaid on ainult suunatud. töövõtjas olulise huvi tekitamisel projekti edukaks elluviimiseks.

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

EPC ühekordse pakkumise mudeli järgi pakkudes tuleb tellijal seevastu koostada üksikasjalik lähteülesanne ja nõuded (ebapiisava läbitöötamise taseme korral võivad töövõtjad kas üldse keelduda fikseeritud hinnaga pakkumiste esitamisest või hinnata riske väga suures koguses); samuti vajab töövõtja suurusjärku rohkem aega, et koostada fikseeritud hinnaga, kõiki riske arvestav pakkumine.

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

Tingimused:

EPC töövõtja- see teeb suurema osa investeerimisprojekti töödest fikseeritud hinnaga ja võtab kõik selle elluviimisega seotud riskid alates projekteerimise hetkest kuni valmisobjekti kliendile üleandmiseni (sh garantii täitmiseni). kohustused), mille eest ta Kliendi ees rahaliselt vastutab.

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

EPC leping hõlmab seetõttu teeb EPC töövõtja suurema osa töödest ise ei mingit erilist tasu kaasatud madalama tasandi vastaspoolte töö korraldamiseks ja juhtimiseks.

EPCM töövõtja võib sõlmida enda nimel lepinguid alltöövõtjatega või hallata tellija poolt konkreetsete töövõtjatega sõlmitud lepinguid.

EPCM leping näeb ette ja projekti kogumaksumus, arvestades EPCM-i töövõtja tasu ja objekti kasutuselevõtu tähtajaline tähtaeg, saavutades rajatise peamised tehnilised parameetrid. EPCM-meetod (lähenemine) võimaldab hallata projekti, mitte konkreetseid töid. Konkreetseid töid teostavad spetsialistid. EPCM-i ülesanne on hinnata valitud töövõtjate/tarnijate vajalikke omadusi (võimed, professionaalsus, ressursid jne), jaotada korrektselt tööd ja vastutusvaldkonnad nende vahel. Edasi - koordineerida oma tegevust, lahendada vastuolulisi küsimusi, kavandada projekti üldskeem, muuta plaane minimaalsete tagajärgedega kriitiliste muudatuste korral ja seejärel kõigi peatustega.

Ülemaailmne investeerimisprojektide elluviimise praktika tõstab keerukate tööstusprojektide elluviimise kõige perspektiivikamate strateegiatena esile EPC ja EPCM lepingud, mis moodustavad ligikaudu 80% teostatavatest projektidest.

Täpsemalt lugege koostatud väljaannet.

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).

Protsessi käigus toimuvad sündmused ja funktsioonid peavad vahelduma. Protsessi edasise käigu kohta teevad otsused 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 mudel vajab parandamist.

Sündmused ja funktsioonid peavad sisaldama täpselt ühte sissetulevat ja üht väljaminevat ühendust, mis peegeldab protsessi kulgu.

Ülekattediagrammis funktsiooni ümbritsevad sündmused ja avaldused peavad olema funktsioonide jaotusdiagrammi algus-/tulemussü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, hargneval operaatoril peab olema ainult üks sissetulev 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äljaminev ühendus elemendiga "funktsioon" ja vastupidi. Ühele sündmusele ei tohi järgneda operaatorid "OR (OR)" või "XOR (Exclusive OR)". 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 Aktsepteeritava olukorra näide 3	Riis. 2.64 Aktsepteeritava olukorra näide 4

Näide kehtetust olukorrast.

Riis. 2.65 Vastuvõetamatu olukorra näide

Statistilised meetodid protsesside juhtimine

Tuuakse näiteid populaarseimatest statistilise analüüsi meetoditest ja pakutakse välja nende hindamise mehhanism.

Pareto diagrammi analüüs

peal tööstusettevõtted pidevalt tekivad igasugused probleemid: abielu ilmumine, seadmete talitlushäired jne. Enamasti tekib valdav osa defektidest ja nendega seotud kahjudest suhteliselt vähestel põhjustel, kusjuures materjalikulude osakaal on ca 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 peamised põhjused, mis uuritavat probleemi mõjutavad. Pareto diagramme on kahte tüüpi: tegevuse tulemuste ja põhjuste järgi.

Jõudlusdiagramm on loodud peamise probleemi tuvastamiseks ja kajastab järgmisi ebasoovitavaid tulemusi.

Maksumus: kahjude maht, kulud;

· Ohutus: õnnetused, õnnetused;

· Tarnetingimused: tähtaegade ebaõnnestumine, laovarude nappus.

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

· Töö tegija: vahetus, meeskond jne;

· 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. etapp. Tehke kindlaks, milliseid probleeme on vaja uurida ja kuidas andmeid koguda; kuidas neid klassifitseerida. Määra andmete kogumise meetod ja periood.

2. samm: koostage andmete salvestamise kontroll-loend, milles loetletakse kogutud teabe tüübid.

Samm 3. Täitke andmesisestusleht ja arvutage kogusummad.

4. samm. Töötage andmete kontrollimiseks välja tabelimall, mis sisaldab graafikut iga kontrollitud objekti kogusummade kohta eraldi, defektide arvu akumuleeritud summa, protsendid kogusummast ja kogunenud protsendid. Järjesta andmed tähtsuse järjekorda.

Tabel 3.1.1 Pareto diagrammi koostamine

Samm 5. Joonistage üks horisontaalne ja kaks vertikaalset telge. Vertikaalsed teljed: vasakul teljel rakendage skaalat 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. samm. 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 on kõige tõhusam, 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;

 Diagrammi koostamine peaks toimuma süstemaatiliselt. Pareto sama protsessi jaoks, mis võimaldab teil jälgida iga teguri defektide arvu trendi (joonis 3.1.1).

Märkused äri jaoks

Muusika on meid sidunud
Sai meie saladuseks

Kõik selle artikli epigraafid on võetud grupi Mirage laulust "Muusika on meid ühendanud".

Klassikalises muusikas on muusik helilooja käes olevaks instrumentiks ja mängib noote. Levimuusikas kirjutavad muusikud enamasti ise muusikat ja improvisatsioonikunstis ei ole noote üldse kaasas. Tõsi, klassikaks saanud kuulsad improvisatsioonid nihutatakse siis nootidele ja on uus elu: Aranžeering muutub, lisandub uus kõla ja meeleolu.

Nii ka oskusliku improvisatsioonina kasvanud äri uuele tasemele liikumiseks nõuab faktide paberile panemist, et toimuvat analüüsida ja parendusotsuseid teha.

Viimasel ajal võite üha sagedamini leida äriprotsesside (BP) kirjeldusi, mis on tehtud, nagu öeldakse, "omapead". See asjaolu ajendas mind seda artiklit kirjutama. Paraku oli enamikust nägema juhtunud dokumentidest tõsise asja puhul vähe kasu. Ei saa öelda, et nad oleksid põhimõtteliselt eksinud, kuid mitmed tegematajätmised rikkusid neid nii ära, et tahtis nende olemasolu kohe unustada. Mis need väljajätmised 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 ma olen omaette
Ma ei leia kõiki vastuseid

See artikkel on adresseeritud neile, kes soovivad säästa äriprotsesside kirjeldamisel, usaldades dokumendi koostamise sisespetsialistidele. Äriprotsesside kirjeldamine ei ole ju ettevõtte jaoks kohustuslik asi ja kõik toimib ilma selleta. Kuid igas stabiilses ettevõttes on volituste delegeerimise mehhanism, mida nimetatakse " töökirjeldus". Kui äri on keeruline ja positsioon võtmetähtsusega, siis on kasulik koostada ametijuhendid, et hõlbustada tajumist. Äriprotsesside koondamine üldkirjeldusse on vajalik äri läbipaistvamaks muutmiseks, eriti selle müümiseks .

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

1. Märkige sellel, nagu lahingukaardil, kavandatud ümberkujundamise olemus,
2. Tutvustage muudatustes osalejat ajakohaselt,
3. Pliiatsiga ja mitte sõrmede peal seadke ülesanne osakonnajuhatajate ja välisspetsialistide jaoks.

Dokumendi iseseisval koostamisel on eeliseid:

• See tuleb välja odavamalt;
• Sisespetsialist, kes on paremini kursis oma kodumaise äritegevusega.

Kolmanda osapoole konsultant peab esmalt uurima teema terminoloogiat ja põhijooni, valdkonna standardeid. See võtab aega. Tõsi, tema teab paremini, kuidas ja mida kirjeldada. Kehtivad teatud reeglid, üldtunnustatud märgid ja spetsiaalne tarkvara. Sellise tähise näidet võib näha joonisel fig. 1 ja fig. 2.

IDEF0 märge

Näide BP kirjeldamisest IDEF0 abil

Ärge pidage meile loenguid

Ära loe mulle
Ema, see on kasutu

Kas see on see, mida me vajame? - Direktor küsib, eeldades, et kõigi standardite järgimine suurendab oluliselt tulemuse maksumust. Üks tuttavatest direktoritest arutles nii: "Välisspetsialisti kutsumine on kallis äri, kuid meie ülesanded on lihtsad - milleks meil kõiki neid märke vaja on. Ja selle eest peate maksma."

Olen nõus, kui ülesanded on lihtsad, siis milleks aeda tarastada. Ja kui need on keerulised, siis tuleb neid lihtsustada, mitte teha keeruliseks väljamõeldud märgetega. Ilusate konksude kasutamisel pole ju ilmselgeid eeliseid. Kui ilmselgeid pole, ei tähenda see, et neid poleks. Need reeglid ja tähistused ei ole välja mõeldud selleks, et konsultandil igav ei hakkaks... Igaüks, kes asjaga tegeleb, teab väga hästi, et kõik kasulik pole ilmselge. Noh, otsime peidetud positiivset ja selleks uurime teema ajalugu.

PSU kirjeldusturg on eksisteerinud väga pikka aega. Viimase pooleteise aastakümne jooksul on ta aga teinud kiire läbimurde tänu uue tööstusharu – raamatupidamise ja juhtimise automatiseerimisele ettevõtetes – tekkimisele. Kasvav turg andis võimaluse uustulnukatele, kes tulid välja uute tähistega, läbi murda ja oma kohta välja tuua. Näiteks peal Venemaa turg mõne jaoks Viimastel aastatel IDS Scheeri (ARIS-i peamise tarnija – vt joonis 3) ulatuslikud reklaami- ja teabekampaaniad lõid automatiseeritud protsesside kirjeldamisel spetsialistide kihi.

ARIS-i tähistuse kasutamine nõuab äriprotsessides palju detailsust.

ERP (ressursihaldus), CRM (kliendisuhted), MRP (tootmise planeerimine) klassisüsteemide kasutuselevõtt toob paratamatult kaasa protsesside muutuse ning kui seda ette ei planeerita, võib tulemus olla kehvem kui soovid. Lisaks on automatiseerimine töö infoga, mis tähendab, et on kasulik teada, millist infot kes genereerib, kust see tuleb ja kuhu läheb. Kuid automatiseerimise kasutuselevõtu erimärgid pole meil juurdunud ja neid kasutatakse harva.

Venemaa äriprotsesside kirjeldus on suhteliselt hiljutine trend, vaatamata muljetavaldavale GOST-ide arvule selles valdkonnas (3.1109, 34, ISO jne). Nüüd, kus oma äriprotsesse kirjeldatakse kvaliteetselt, 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 regulatsioonide ranges raamistikus. Pank tegutseb igapäevase juhtimise põhimõttel. Selle tulemusena osutub isegi panga äriprotsesside lihtsustatud kirjeldus (vene keeles ilma tähistusi kasutamata) üksikasjalikumaks, sest tugineb vundamendile, mis on üles ehitatud regulatsioonidele, mis määratlevad standardid, terminoloogia, rollid ja reeglid. Need standardid on panganduskeskkonnas levinud keel ja äriprotsesside kirjeldus on hõlpsasti loetav igale spetsialistile.

IN kaubanduslikud struktuuridäriprotsesside kirjeldamiseks on vaja esialgset terminite sõnastikku. Ja alustades selle ettevalmistamist ja kooskõlastamist, seisavad paljud silmitsi tõsiasjaga, et erinevates osakondades nimetatakse samu asju erinevalt. Detailidesse laskudes selgub, et erinevad nimed kannavad tõepoolest erinevaid tähendusvarjundeid. Terminoloogia ühtlustamine on üks aeganõudvamaid protsesse BP kirjeldamisel. Oluline on seda protsessi alustada ja käivitada. Suurema osa tööst saan võtta ettevõtte enda allüksustelt, sest vajadus nende 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 "kuum jälitamise teel" ning on üks süsteemi dokumentatsiooniga.

pulk

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

Kummalisel kombel on tähistusviisi valik ja kirjelduse õigsus kriitilisem just väike- 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 on taandatud 2-3 otsustajale, võib protsessi marsruudi ebaõige näitamine põhjustada põhimõtteliselt vale lahenduse kontseptsiooni. Kuna tulemus on kriitiline, on oluline ka tööriist, aga kuidas seda valida?

Iga märge on kohandatud konkreetsele ülesannete vahemikule. Käsitleme juhtimise automatiseerimise projekti osana kõige pakilisema ülesandena äriprotsesside muutmist. Nendel eesmärkidel on olemas hea tööriistade komplekt, mida kasutatakse laialdaselt: need on Venemaa GOST-id, samad ARIS ja IDEF, samuti EPC (joonis 4 ja joon. 5).

EPC tähistus

Äriprotsessi kirjeldus EPC abil

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

Noodivalikul on oluliseks kriteeriumiks ka 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. Seda juhul, kui on parem valida midagi muud - mitte ainult, keegi ei tea On-Target tähistust, vaid ka tarkvarakeskkond võtab selle uurimiseks aega. Positiivseks näiteks nimetaksin IDEF-i tähistuse kasutamist ja Visio programmi, mis on väga levinud ja millel on IDEF-diagrammide joonistamiseks vajalik komplekt tööriistu (joonis 6).

IDEF-i äriprotsessid, mis on tehtud Visios

Muidugi võib BP kirjelduse teha lihtsalt sõnadega, samuti joonistada erinevate sümbolitega (enda väljamõeldud), nagu see arusaadav tundub. Sellise kirjelduse olemasolu on parem kui mitte midagi, kuid standardid on siiski kasulikud.

Heli täius ja sügavus

Ma ei tea, mis mind siia tõmbab

1. võtab kaua aega
2. osa üksikasju muutub dokumendi loomise käigus.

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

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

Meloodia on helide jada, mitte noodid

unusta see päev ära
Keegi ei vaja võitlust

Nii et saate kirjeldada BP-d ja lihtsalt sõnu, ilma märkusteta. Tähistusega on see muidugi õigem, aga 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 isetegemisdokumentide peamine probleem on nende kasutamise ebamugavus. Näiteks üks selline dokument koosnes Microsoft Wordis tehtud kirjeldusest ja PowerPointis tehtud joonistest, programmist programmi hüppamine oli jube ebamugav, pidin kulutama suur hulk aeg koondada see kõik ühte dokumenti. Selgub, et dokumendil peaksid olema järgmised omadused:

1. Omama selget sektsioonide järjestust ja rühmitamist, st. olema kontseptuaalselt terviklik (tavaliselt tähendab see seda, et kui sa oled mõiste, siis oled õppinud seda kasutama);
2. Määrake selgelt äriüksused ning andke neile arusaadavad nimed ja nummerdamine;
3. Tehke äriprotsessid selgelt kindlaks ning andke neile ka selge nimi ja nummerdamine;
4. Elemendid tuleks nummerdada nii, et vältida segadust (see hõlbustab oluliselt otsingut): näiteks osakonnal nr 1 peaks dokumendis olema number Otd001 ja äriprotsessil nr 1 olema number BP001;
5. Dokumendil peab olema puustruktuuriga sisuosa;
6. Ettevõte on terviklik organism ja ükski äriprotsess ei jää õhus rippuma – see on alati seotud teiste äriüksustega, äriüksuste ja osakondadega. Nende linkide kajastamiseks saab kasutada hüperlinke – see hõlbustab teabe otsimist ja üleminekut ühelt objektilt teisele.

Võite kasutada mis tahes tekstiredaktor toetavad hüperlinke.

Mõned usuvad seda professionaalselt muusikaline kollektiiv piisab ühest või kahest pärismuusikust. Sellega ei nõustu ükski siiras muusikatundja. Need vestlused tekivad professionaalide ja loominguliste isikute puudumise tõttu.

Ettevõtetel on sarnased väljakutsed. 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 pole võimalik toiteploki kirjeldamiseks parimaid ära rebida. Rutiini võib usaldada madalama järguga 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 dokumendi koostamisel on võimalik liidus, võtmespetsialistis ja kogenud konsultandis. Tulemuseks on kokkulepitud keel äriprotsesside kirjeldamiseks (st ettevõtte äritegevuse terminoloogia) ja kirjeldus ise, millest piisab edasiste probleemide lahendamiseks.

Kordan vastuseks kogu veenmist
Meid ei lahutata, ei

Tuletame meelde, et kõik selle artikli epigraafid on võetud Mirage grupi laulust "Music Tied Us"

Väliskonsultant kirjutab dokumendi noodikeeles, millest teised konsultandid aru saavad ja mis on sageli antud juhtumi jaoks sobivam. Kas te ei mõista kõiki neid konkse? Aga need tähistused pole sugugi rasked, ehk tasub neid õppida?

Protsessimudel on funktsionaalsete, käitumuslike, informatiivsete ja organisatsiooniliste perspektiivide omavahel seotud integreeritud kogum, kuid paljud tänapäeval reengineeringu 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 annavad ebatäieliku ettekujutuse. modelleerimisobjekti ja need 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 jms võimalusi, kuid tähistuste ja äriprotsesside kirjelduskeelte võrdlemine on vale nende funktsionaalsust analüüsides - kas mudel on funktsionaalne või protsess, määrab mitte ainult tähistuse, 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 mõningaid omadusi, mis on konkreetse modelleerimise jaoks olulised, ja jättes välja muud mitteolulised 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 peab vastama. Äriprotsesside mudelist paistavad silma neli vaatenurka (vt joonis).

Funktsionaalne: Mida osalejad teevad? Kirjeldab tehtavate tööde ulatust.

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

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

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

Mingit vaatenurka kirjeldav mudel vastab mitmele küsimusele, kuid nende hulgas on alati põhiline, millele mudel peab andma ammendava vastuse ja lisaküsimused ei pruugi saada täielikku vastust. Viimasel juhul tuleb olla eriti ettevaatlik, mudeli perspektiivi määrab täpselt põhiküsimus, mitte abiküsimus.

Funktsionaalne perspektiiv

Funktsionaalne mudel kirjeldab süsteemi staatilises olekus, aitab vastata küsimusele "mida tuleks eesmärgi saavutamiseks teha?". Vastuseks on nimekiri kõigist tegevustest, mida on vaja kavandatud tulemuse saavutamiseks teha. Laialdaselt kasutatav projektijuhtimises tööjaotuse struktuur(Work Breakdown Structure) - selles loetletud toimingud ei ole seotud ajajadaga. Samamoodi on protsesside modelleerimisel väga kasulik luua struktuurne dekompositsioon, mis aitab mõista protsessi loogikat ja meeles pidada mõne olulise funktsiooni täitmist. Kui kaks erinevat organisatsiooni viivad läbi sama protsessi, on neil sama töö funktsionaalne jaotus, 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õrdluseks.

Sageli nimetatakse funktsionaalset mudelit ekslikult protsessikaardiks; näiteks SCOR (The Supply-Chain Operations Reference-model) ja ETOM (Enhanced Telecom Operations Map) mudelid sisaldavad funktsioonide hierarhiaid ja väärtusahelaid, kuid mitte mingil juhul protsesse. Isegi TeleManagement Forumi juhised nõuavad protsessi kui sooritatavate toimingute jada ja protsessi kui ettevõtte tegevuse suuna eristamist.

Käitumisperspektiivi aspektid

Käitumuslik perspektiiv, mis kirjeldab süsteemi dünaamikat, vastab küsimusele "kuidas osalejad töötavad?". Selle modelleerimiseks kasutatakse juhtimise vooskeemi. Põhikü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öö teostamise järjekorra protseduurilist kirjeldust, selle graafiliseks kuvamiseks kasutatakse töövoo diagrammi. Vastus teisele annab protsessi läbiviimise ajakava, mis määrab selle või teise töö tegemise aja, selle täitmiseks kulunud 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 moodustavat toimingute jada nimetatakse tavaliselt äriloogikaks ja selle kirjeldamiseks kasutatakse töövooskeemi (UML, EPC, ABC Flowchart – kirjeldused vooskeemidel). Ä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. Tihti ei eralda ärianalüütikud loogikat ja reegleid ning panevad diagrammile "haru" elemendi, vaid jätavad välja sellega seotud hargnemisreegli.

Äriloogikat kirjeldavad diagrammid on visuaalselt lihtsad ja selged, kuna need ei sisalda ärireegleid, täitmisgraafikut ega parandusmeetmeid, kui protsessiindikaatorid on väljaspool vastuvõetavat vahemikku, mistõttu paljud analüütikud kasutavad neid äriesindajatega kokkuleppimiseks. Lihtsus on aga petlik – IT-süsteemide arendajad peavad puuduvat infot uuesti kokku koguma ning nende arusaam protsessist võib analüütiku seisukohtadest vägagi erineda. Selle tulemusena ei kirjelda mudel protsessi täielikult, detailid pole selgelt fikseeritud, vaid eksisteerivad ainult programmeerijate peas. Selle tulemusena ei vasta paberil olev protsessimudel IT-süsteemi loogikale – just need ebatäpsused äriprotsessi esialgses kirjelduses toovad kaasa arvukaid täiustusi, mis ilmnevad infosüsteemide juurutamise etapis.

Ärireeglid

Ärireeglit mõistetakse tavaliselt kui väidet, mis määratleb või piirab ettevõtte mõningaid aspekte. Erinevalt protseduurikirjeldusest postuleerivad reeglid piiranguid protsessi läbiviimisele, kuid ei määratle täpselt, kuidas tulemus peaks saavutama. Ärireeglite ekspert Ronald Ross annab ärireeglitele järgmise klassifikatsiooni:

• käitumisreeglid määravad kindlaks asjakohase toimingu tegemise ja kontrolltoimingu teostamise vajaduse;
• määratlusreeglid kehtestavad ärikontseptsiooni, mida nimetatakse faktiks, kohaldatavuse kriteeriumi;
• arvutusreeglid aitavad välja selgitada vajalike koguste väärtused, mida nimetatakse faktideks; näiteks kaubandussoodustuse võib määrata teatud perioodi ostude kogumaht vms;
• klassifitseerimisreeglid aitavad kontrollida faktide õigsust; näiteks klient loetakse VIPiks, kui tal on kontol teatud summa ja tal ei olnud maksevõlgnevusi.

Protsessi hargnemine põhineb käitumisreeglil, 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 klassifikatsioon. reegel, mis omakorda peab saama sisendiks mingi arvutusreegli abil saadud väärtuse. Näiteks kujutage ette järgmist toimingute jada: arvutage allahindluse väärtus jooksva tellimuse suuruse funktsioonina (arvutusreegel); liigitage allahindluse suurus: suur, keskmine, madal (klassifikatsioonireegel); saata tehing kinnitamiseks vastava volituste tasemega juhile (käitumisreeglid). Levinud on aga tige praktika paigutada diagrammile “hargnev” element koos nii käitumisreeglite kui ka definitsioonireeglite kaasamisega, mis muudab diagrammi paindumatuks ja kirjelduse puudulikuks. Seega tuleks töövoo diagrammil kõik reeglid eraldi konstruktsioonides selgesõnaliselt esile tuua, mis aitab analüütikul vastavat loogikat selgelt lokaliseerida.

Täitmise ajakava

Materjali tootmise valdkonnas kasutatakse toote valmistamisele kuluva aja arvutamiseks laialdaselt töögraafikut. Äriprotsesside jaoks on töögraafikus rohkem keeruline vaade, kuna iga toimingut saab õigeaegselt teostada ja kogu protsessi – ümbertöötlemise tagasilükkamise tõttu viivitusega.

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

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

Äriloogika detailsus

Küsimusele "kuidas?" vastamiseks peaks juhtskeem sisaldama protsessi moodustavate toimingute kõige üksikasjalikumat kirjeldust. Paljud analüütikud piirduvad funktsioonide loetlemisega, andmata nende täitmise üksikasju, eeldades, et teostaja teab, kuidas tööd teha. Kuid praktikas kalduvad töötajad tegema tööd oma individuaalseid kogemusi arvesse võttes, mis toob kaasa suure varieeruvuse protsessi teostamises. Modelleerimismärgid ei määratle kirjelduse detailsuse taset, jättes selle küsimuse analüütiku hooleks. Määratleme täpsustamise kriteeriumid.

Venemaa Gosstandarti juhtdokument "IDEF0 funktsionaalse modelleerimise metoodika" tutvustab mõisteid "tegevus" ja "operatsioon". Toiming on määratletud kui "materjali või teabeobjekti mõne omaduse muutmine teiseks omaduseks" ja toiming on määratletud kui "järjestikuste ja/või paralleelsete toimingute kogum".

Täpsustame neid määratlusi protsesside modelleerimise puhul. tegevust kutsume protsessi objektil osaleja tehtud tööd, mis muudab seda objekti, kuid ei too kaasa selle oleku muutumist; näiteks osaleja sisestas uued andmed, kuid see ei tähenda avalduse menetlemise lõppu. operatsiooni nimetame tegevuste kogumit, mis viib objekti oleku muutumiseni; Näiteks pärast kõigi kontrollide lõppu saab taotluse 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 viiakse läbi, omama toimingute üksikasjalikku taset. Selle tulemusena osutuvad sellised diagrammid liiga üksikasjalikuks, riskides detailidega üle koormata. See on aga pigem modelleerimisstiili küsimus – mitmetasandilised struktureeritud mudelid suudavad ühendada diagrammi ülaosas äriloogika lihtsuse ja allosas üksikute toimingute üksikasjaliku kirjelduse.

Protsessi äriloogika täielikkuse aste

Enamik töövoo diagramme kirjeldab piiratud komplekti täitmise stsenaariume, tuvastades ainult kõige ilmsemad marsruudid. Need ei sisalda harva täidetavaid skripte, need jätavad välja eri- ja erandolukorrad. 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 ülesehitamisel määrab toimingute järjekorra aga süsteem ise, mistõttu peab mudel katma kõik võimalikud täitmistsenaariumid, sh kontrolli naasmised eelmisele sammule või möödasõidud, mis mööduvad teatud töötlusetapid, arvestage probleemi eskaleerumise võimalusega, erandite käsitlemisega, muidu süsteem töötab. osutub võimatuks.

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

Oleme näidanud, et tuleks eristada töövoo diagramme, juhtimisvoo diagramme ja protsessimudelit. Töövooskeem määratleb äriloogika, toimingute teostamise järjekorra, sellel on operatsioonide üksikasjalikkuse tase, see ei sisalda protsessi täitmise ajakava ega pruugi protsessi ärireegleid täielikult määratleda. Juhtimise vooskeem täpsustab töövooskeemi täitmisgraafiku ja ärireeglite osas, omab toimingute detailsuse taset, peaks kirjeldama kõiki täitmisvõimalusi ehk teisisõnu kirjeldab tehnoloogiat, mis tagab planeeritud tulemuse saavutamise etteantud tulemusel. toimingute komplekt on täpselt tehtud. Vähemalt ühe komponendi puudumisel jääb kirjeldus puudulikuks, tehnoloogiat ei järgita. Protsessi mudel on omavahel seotud vaatenurkade kogum, millest igaüks kirjeldab protsessi käitumise eraldi aspekte ning koos moodustavad integreeritud, tervikliku ja tervikliku ülevaate protsessist ja selle toimimisest. Juhtimise vooskeemi kaasamine kirjeldab äriprotsessimudeli käitumisperspektiivi.

EPC märge on vahend protsessi äriloogika kirjeldamiseks. Nagu võrdlus näitab, võimaldab tähistus rakendada äriloogika põhimustreid, mis ei jää alla muudele protsessikirjelduste märkidele. EPC diagrammid ei sisalda sageli ärireegleid, kuid seda puudujääki ei tohiks seostada tähistusega kui sellisega, vaid selle rakendamise metoodikaga. Täitmise ajakava osas tuleb märkida, et täitmise ajaliste omaduste modelleerimiseks puuduvad vahendid. EPC tähistuses on konstruktsioon "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, mistõttu piirdutakse ainult toimingute taseme kirjeldamisega ega püüa tuvastada kõiki täitmisteid. EPC-tähistust kasutatakse sageli automatiseerimiseks, kasutades funktsioonidele orienteeritud süsteeme, kus inimene mängib juhtivat, suunavat rolli, nii et täitmisskripti puudumine pole ohtlik. Kõik see võimaldab liigitada EPC mudeleid töövoo diagrammiks.

ARISes sisalduvad tähistused omavad ülimalt laialdasi võimalusi protsesside modelleerimiseks, kuid neid ei toeta kasutajatele avatud ja kättesaadavad metoodikad. Dokumendis "ARIS Metoodika" ei ole kirjeldatud metoodikat, vaid tähistuse rakendamise reegleid, mis võimaldab modelleerimismeetodeid mitmeti "tõlgendada".

EPC probleem tuleneb sellest, et püütakse seda tööriista kohandada liiga paljude probleemide lahendamiseks, ilma konkreetse juhtumi kohaldamisreegleid selgitamata. Selle tulemusena rakendavad analüütikud paljusid konstruktsioone ja mehhanisme intuitiivselt ja alateadlikult. Mõnikord saab nende kavatsusest aru ülesande kontekstist, kuid on ebatõenäoline, et kaasaegne arvuti suudab diagrammi käivitatavasse vormingusse teisendamise ajal konteksti ise analüüsida.

BPMN-i märge kirjeldab protsessi loogikat. Natuke parim tugiäriloogika mustrid, võrreldes EPC-ga, ei ole otsustav eelis. Tähistus opereerib mõistetega "sündmus" ja "ajavahemik", sisaldab vahendeid protsessiharude omavaheliseks ja protsesside omavaheliseks sünkroniseerimiseks. Märkus ise ei sisalda soovitust loogika ja reeglite eraldamiseks, kuid õige modelleerimisstiili juhised sisaldavad sellist soovitust. BPMN-i tähistust kasutatakse protsessile orienteeritud süsteemide loomiseks, kus inimene 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 teha ja on seetõttu vastuvõetamatu. BPMN-i mudelid hõlmavad vastavalt kõiki täitmise stsenaariume. BPMN-i mudelid on käivitatavad mudelid, nii et need kirjeldavad kõiki üksikasju kuni elementaarsete toiminguteni. Kõik ülaltoodud võimaldab klassifitseerida BPMN diagrammi juhtimisvoo mudeliks.

BPMN-i tähistusega seotud probleemid on seotud sellega, et diagrammid kipuvad olema detailide ja detailidega üle koormatud ning seetõttu raskesti loetavad. Väljapääsu nähakse hierarhilise konstrueerimise metoodika väljatöötamises mitmetasandilised mudelid, kus ülemine tase kirjeldab kogu protsessi täitmiskonteksti, keskmine tase kirjeldab täitmisloogikat ja alumine tase kirjeldab üksikute toimingute rakendamise üksikasju.

Huvi BPM-i ja BPMS-i (Business Process Management Suite) vastu on jõudnud küpsuspunkti, mil moest pole enam vaja rääkida. Lisaks on standardisõda lõppenud ja BPMN-i tähistus on pälvinud tunnustuse kõigi suuremate tegijate seas, saades de facto standardiks. Seda sündmust saab võrrelda SQL-i tekkega, millest sai tänapäevaste infosüsteemide aluseks.

BPMS moodustati lõpuks klassina tarkvaraäriprotsesside graafilise modelleerimise, äriprotsessimudelite teostamise, monitooringu ja analüüsi toetamiseks (Business Activity Monitoring, BAM). Erinevad tooted rakendavad seda funktsionaalsust aga erineval viisil ning konkreetse BPMS-i valimisel tuleks esmalt tähelepanu pöörata järgnevale.

• BPM 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 esindusele - ainult sel juhul on võimalik praktikas rakendada pidevat äriprotsesside täiustamist.
• Protsesside ja andmete vaheline suhtlus. Eelistatav on salvestada atribuute umbes
protsessi maksimaalselt avatud vorm- relatsioonilise DBMS-i tabelites ja veergudes, mis tagab viiteterviklikkuse, kõrge tööjõudluse ja juurdepääsuvabaduse väljastpoolt tulevatele andmetele, erinevalt näiteks atribuutide salvestamisest XML-stringina.
• Kasutajaliides. Liides peaks olema funktsionaalne, ergonoomiline
ja arendada kiiresti, võimalusel ilma programmeerimiseta. Süsteem peaks võimaldama ärianalüütikul luua töötava kasutajaliidese, mille saab soovi korral programmeerija kaasamisel lõplikult vormistada.
• süsteemi platvorm. Olenevalt ettevõtte tehnilisest poliitikast, valik
võib piirduda Java platvormiga või. Net – mõlemat platvormi toetav BPMS on haruldane.
• Litsentsiskeem. Shareware süsteemid võimaldavad säästa kas
litsentsid, kuid nõuavad suuri arendusressursse; mõned kommertssüsteemid nõuavad märkimisväärseid investeeringuid isegi minimaalse konfiguratsiooni korral.
• Esinduse või partneri olemasolu Venemaal.

Ei tasu unustada, et BPMS on vaid üks BPM-i komponente ning äriprotsesside juhtimissüsteemi projekti õnnestumine eeldab ka metoodika- ja agiilse projektijuhtimise kompetentse.

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äitmist, jättes välja harva kasutatavad alternatiivsed marsruudid: nende diagrammidelt leiate 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 viimistleda.

Analüütikud ei pööra tähelepanu protsessi kontrolliobjekti muutumisele. Kujutage ette kirjeldust tehnoloogiline protsess sealhulgas komponentide valmistamine. Kui komponendid on valmistatud 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, millel on oma juhtimisobjekt. Analüütik peab protsessi juhtimisobjekti hoolikalt jälgima, kuna selle muutumine on märk täieliku protsessi võimalikust jagunemisest interakteeruvate protsesside ahelaks.

Protsessi ebapiisav detailsus toob kaasa vajaduse väljatöötatava IT-süsteemi nõuete koostamise etapis puudujäänud üksikasjad uuesti selgitada ja kirjeldada.

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

Seega võib öelda, et EPC probleemid peituvad selle rakendamise metoodika valdkonnas ja kui oleks olemas modelleerimisleping, mis määraks kõik arendatava mudeli detailid, siis enamik probleeme, välja arvatud täitmise ajastus. , saaks vältida.

Mitte tähistus, vaid metoodika määrab, kas mudel on funktsionaalne või protsess. Protsessi mudel on kihiline kirjeldus, mis sisaldab omavahel seotud funktsionaalsete, käitumuslike, informatiivsete ja organisatsiooniliste perspektiivide kirjeldusi. Käitumisperspektiivi kirjeldamiseks kasutage juhtimisvooskeemi, mis annab põhjaliku vastuse küsimusele "kuidas protsess toimib?", sealhulgas toimingute jada, ärireeglite ja täitmisgraafiku määratlemine, tegevustaseme üksikasjad ja kõik võimalikud. täitmise stsenaariumid. Töövoo diagramm, mida põhjendamatult nimetatakse protsessimudeliks, ei kirjelda kõiki protsessi käitumise üksikasju ega ole protsessiskeem.

Paljud ümberprojekteerimises kasutatavad mudelid ei vasta kõigile ülaltoodud 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. IDEF0 funktsionaalse modelleerimise metoodika. 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]) – protsessijuhtimise kompetentsikeskuse MESI direktor (Moskva).

Äriprotsesside modelleerimine, modelleerimise perspektiiv, funktsionaalne ja protsesside modelleerimine

„Lohed, pimedate blufid ja sildid
Peitust, pallid, hüppekonn ja hüppenöörid,
Ja lihtne ja lihtne ja lihtsalt hüppenöörid,
Noh, lihtsalt, lihtsalt, lihtsalt hüppenöör!!!”

A.Vratarev

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

Ja 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 isa on professor Wilhelm-August Scheer, kelle nimi üksi äratab võhikutes aukartust (öelge seda valjusti ja tunnetage seda). Mida öelda selle teaduskonna nime kohta, kus see lugupeetud onu töötas: Institut für Wirtschaftsinformatik of the University Universität des Saarlandes.

EPC tähistuse loomise eesmärk oli võime kirjeldada protsesse nii, et nende sees täidetavatel funktsioonidel oleks diagrammi sees 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 sooritamise lõpetamine genereerib omakorda veel ühe sündmuse ja nii edasi, kuni süsteem jõuab olekusse, mille ilmumist protsessi sees loetakse lõppsündmuseks.

Tähistusvõimaluste visuaalseks demonstreerimiseks kasutan igapäevast näidet, mis on inspireeritud äsja lõppenud puhkusest soojemas kliimas. Lugupeetud hotelli registratuuritöötaja Ivo Petkov saab ühelt külaliselt palve kiiremas korras välja vahetada toas olevad vannitoatarbed. On täiesti selge, et tema ülesanne on täita kliendi soovi ning EPC mõttes - viia süsteem olekust "Kliendilt saadud pesutarvikute vahetamise taotlus" olekusse "Kliendi soov on rahuldatud".

Esitame 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 on ümarate servadega rohelised ristkülikud ja esinejad on kujutatud kollaste ovaalidena.

Niisiis, tagasi näite juurde. Ivo peab kohe peale kliendilt päringu saamist saatma toateenijale palve kliendi soovi täitmiseks, mis viib süsteemi olekusse "Täitetaotlus saadetud". Neiu, kasutades laos olevaid varusid, täidab Ivo soovi. Ja siin ilmneb esimest korda meie protsessi paralleelsus: kui neiu saab aru, et vajalikke pesemistarvikuid (näiteks dušigeel) pole hetkel laos, siis annab ta ise võib-olla tahtmatult süsteemi üle riigile. Taotluse täitmine on võimatu”, millest järeldub, et Ivo ei pea kliendiga just kõige meeldivamat vestlust pidama ning see, millisesse olekusse süsteem edasi läheb, sõltub ainult kliendi tujust ja kaklemiskalduvusest. Kui laos on kõik külalisele vajalikud tarvikud olemas, siis neiu täidab edukalt talle saadetud soovi, teavitab täitmisest Ivot, kes omakorda teavitab sellest klienti. Ja kõik elavad õnnelikult elu lõpuni ja surevad samal päeval.

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

Riis. 1. EPC-skeem kliendi taotluse menetlemise protsessist hotellis

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

Kui ma esimest korda EPC diagrammidega kokku puutusin, nagu ma juba varem mainisin, oli mul väga hea meel, kui lihtne on neid lugeda: iga plokk on kuju ja värvi poolest esile tõstetud, väga lihtne on näha esinejaid, vajalikke materjale, esile tuua võimalike süsteemi olekud, protsessi funktsioonide käigus käivitatud loend. See on kahtlemata suur pluss: kliendil ei teki EDMS-i juurutamisel raskusi äriprotsesside skeemi lugemisega, kui see on esitatud EPC-tähistuses. Küll aga on võimalik, et selline tohutu hulk olekuid ajab kliendi segadusse, sest tegelikult kasvab nende tõttu ringkond kõvasti. Isegi meie näites: mingid 4 funktsiooni genereerisid koguni 5 olekut (arvestades algset). Mõnikord mõtlete: miks need kõik ära näidata. Ütleme pärast lepingu kokkuleppimist, miks see vajalik on tegevdirektor märkida eraldi lahtrisse “Leping kokku lepitud” ja pärast allkirjastamist – “Leping allkirjastatud”, kui protsess jääb siiski lineaarseks. Ausalt öeldes pole seda vaja, välja arvatud juhul, kui olete Captain Obvious.

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

EPC-diagrammide eeliseks on asjaolu, et sarnaselt IDEF0 diagrammidele on neil võimalik näidata iga funktsiooni sisend- ja väljundandmeid, jälgida sisend- ja väljundandmete liikumise loogikat plokist plokki. Lisaks, erinevalt samast IDEF0-st, sai võimalikuks protsessi paralleelsus, suunates selle ainult mööda ühte alternatiivsetest harudest (IDEF0-s, kui lisada täitmisel paralleelsus, täidetakse kõik paralleelsed funktsioonid üheaegselt). Plussiks tundus mulle ka võimalus iga etapi (loe: funktsioonide) jaoks esitaja täpsustada.

Aga! IDEF0-s määratakse täitja igal dekomponeerimistasemel üks kord ja selle nimel joonistatakse nooled kõikidele selle käivitatavatele plokkidele. EPC-s tuleb täitja sooritatavate toimingute arvutamiseks läbida kõik toiminguplokid ja kontrollida, kas meile vajalik täitja on sellel märgitud.

See märge tundus mulle protsessi täitmise jälgimise seisukohalt väga mugav: iga funktsioon viib kindlasti süsteemi uude olekusse, mis tähendab, et pärast iga funktsiooni täitmist saab süsteemist kontrollida, kas üleminek soovitud olek on tõesti saavutatud. Siis aga tekkis küsimus: kas see on tõesti vajalik? Näiteks mul on harva selline soov =)

Nii et üldiselt tundub EPC tähistus mulle äriprotsesside kirjeldamiseks ebamugav: liiga palju tähelepanu sündmustele, liiga vähe tähelepanu tegevustele ja eelkõige nende rühmitamisele vastavalt kunstnikule või kasutatud materjalidele. Jah, ta on lihtne, jah, ta on ilus ja jah, kahjuks on see kõik, mida ma tema, nagu ilmselt paljude teiste inimeste kohta öelda saan. =)

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

(4,14 - hinnatud 21 inimese poolt)