Verslo modeliavimo įrankiai. Verslo procesų modeliavimas – žymėjimų apžvalga. Nuo modeliavimo iki automatizavimo

• Holistinio organizacijos gyvenimo vaizdo susidarymas, skirtingų požiūrių į nuolat besivystantį ir besikeičiantį verslą derinimas.
• Abipusio supratimo užtikrinimas visuose organizacijos lygiuose, atotrūkio tarp vadovaujančios ir atliekančios pusės mažinimas.
• Gamybos kaštų mažinimo ir kokybės bei paslaugų lygio gerinimo užtikrinimas.

Verslo modeliavimo procese vyksta perėjimas nuo sąvokos „ką“ reikėtų padaryti prie „kaip“ sąvokos. Modeliavimo rezultatas turėtų būti dokumentas, kuris kūrimo komandai aiškiai suprastų projekto apimtį, taip pat kliento programinę ir techninę įrangą. Gauti duomenys atsispindi projekto specifikacijoje, kurią gali sudaryti šie skyriai:

• pagrindinių programos duomenų subjektų aprašymas;
• oficialus paraiškos specifikacijos aprašymas;
• verslo logika ir verslo taisyklės;
• funkciniai reikalavimai;
• nefunkciniai reikalavimai;
• paraiškos forma/puslapio šablonai;
• žodynas arba santrumpų sąrašas;
• pagalbos diagramos.

Verslo modeliavimo įrankiai ir jų raida

Verslo modeliams kurti naudojami informacinių sistemų projektavimo įrankiai ir juos atitinkančios aprašymo kalbos (garsiausia iš jų yra UML – Unified Modeling Language). Tokių kalbų pagalba kuriami grafiniai modeliai ir diagramos, demonstruojantys organizacijos verslo procesų struktūrą, žmonių tarpusavio sąveikos organizavimą ir būtinus pokyčius, siekiant pagerinti visos organizacijos veiklą. Verslo modeliavimo įrankiai nuolat tobulinami. Iš pradžių tokių įrankių pagalba buvo galima apibūdinti tik įmonės verslo funkcijas (darbą) ir duomenų judėjimą jų įgyvendinimo procese. Be to, jei ta pati verslo funkcija buvo naudojama įvairiems darbams atlikti, buvo sunku suprasti, ar turima omenyje ta pati verslo funkcija, ar kita. Nesugebėjimas aiškiai apibrėžti verslo procesų hierarchijos (pavyzdžiui, „vertės grandinė“, „verslo procesas“, „poprocesas“, „darbas“, „funkcija“) sukėlė problemų naudojant tokius aprašymus. Patys aprašymai tebuvo paveikslėlių rinkinys. Vėliau pradėjo atsirasti įrankiai, kurie leido apibūdinti organizaciją ne tik iš verslo funkcijų, bet ir iš kitų pusių. Taigi atsirado galimybė kurti atskiras diagramas, atspindinčias įmonės organizacinę struktūrą, duomenų srautus organizacijoje, verslo funkcijų, sudarančių vieną verslo procesą, seką, su galimybe naudoti loginius simbolius ir kt. vis augant verslo modeliavimo įrankiams keliamiems reikalavimams, atsirado vis daugiau diagramų, apibūdinančių įvairius organizacijos veiklos aspektus, todėl modelio kūrimas tapo vis sudėtingesnis. Šiuo atžvilgiu kitas svarbus verslo modeliavimo įrankių kūrimo etapas yra susijęs su idėja naudoti vieną objektų saugyklą (saugyklą) ir galimo pakartotinio objektų panaudojimo skirtingose ​​diagramose idėja. Kad ir koks įrankis būtų pasirinktas, jis turi užtikrinti vietinių informacinių sistemų tarpusavio sąveiką. Iki šiol moderniausias ir tuo pačiu visuotinai priimtas verslo procesų valdymo organizavimo standartas yra BPEL (Business Process Execution Language). Remdamiesi šiuo produktu, galite sukurti vieną integravimo platformą visoms savo programoms. Sumodeliavus procesus viename iš modeliavimo įrankių, modeliui pritaikyti BPEL standartui naudojami specialūs vertėjai.

Verslo modeliavimo pavyzdžiai ir jo rezultatai

• Kainos sumažinimas. Verslo modelis suteiks idėją, kur galite išvengti nereikalingų išlaidų ir kaip optimizuoti išteklių naudojimą. Remiantis verslo modeliu, atliekama funkcinių kaštų analizė, skirta produkto ar paslaugos savikainai apskaičiuoti, sukonstruota biudžeto valdymo sistema, leidžianti kontroliuoti įmonės kaštus.
• Efektyvumo gerinimas. Galimybė sumažinti personalo prisitaikymo ir mokymo išlaidas. Reguliacinė dokumentacija, paremta parengtu verslo modeliu, atitinka esamą organizacijos padėtį, paskirsto pareigas, kuria hierarchinę karjeros augimo sistemą.
• Plėsti įtakos sferą, didinti tinklą, organizuoti filialus. Verslo modelio buvimas sumažins išlaidas ir leis apibūdinti naujų įmonės filialų organizavimo struktūrą.
• Investicijų adekvatumas. Verslo modeliavimo pagalba galima pakankamai tiksliai nustatyti kapitalo investicijų dydį, sumažinti riziką ir finansinius nuostolius naujo projekto pradžios stadijoje.
• EDMS diegimas. Įmonės verslo modelis standartizuoja įmonės dokumentų sudėtį ir nustato dokumentų judėjimo maršrutus.
• ERP, SCM, CRM ar kitos programinės įrangos klasės sistemų automatizavimas ir diegimas. Remdamiesi verslo modeliu, galite suformuluoti geresnius reikalavimus sistemai ir pasirinkti optimalų kainos bei funkcionalumo atžvilgiu sprendimą.
• Kokybės vadybos sistemos sertifikavimas. Plėtra verslo modeliusįmonė leidžia žymiai sumažinti kokybės vadybos sistemos kūrimo, diegimo ir sertifikavimo laiką ir išlaidas bei gauti rinkinį reikalingi dokumentai Norėdami sėkmingai sertifikuoti, sumažinkite kokybės vadybos sistemos išlaikymo išlaidas.

Verslo modeliavimo ypatybės

Verslo modelio sukūrimas, įgyvendinimas ir palaikymas – brangus investicinis projektas. Ir, kaip ir bet kuris projektas, prieš kuriant verslo modelį turi būti atlikta jo įgyvendinimo pagrįstumo ir pagrįstumo analizė. Dideliems projektams reikalingi galingi verslo modeliavimo įrankiai su gerai išvystyta funkcionalumu: galimybe kaupti informaciją vienoje saugykloje, bendradarbiauti vykdant modeliavimo projektą ir patikrinti sukurto modelio vientisumą, pusiau automatinio diagramų generavimo, integravimo su kita programine įranga, analizės ir modelio dokumentacija – tuo tarpu mažuose projektuose dėl išlaidų protingiau būtų naudoti mažiau funkcionalius įrankius. Norint išanalizuoti veiklą, plėtoti esamą struktūrą, iš pradžių būtina sukurti adekvatų verslo modelį. Tai yra, iš pradžių teorija, o tik po to – jos įgyvendinimas.

Sprendimai

Šiandien yra daug programinės įrangos produktų, skirtų apibūdinti organizacijos architektūrą. Remiantis analitinės bendrovės „Gartner“ ataskaitomis, šio segmento lyderiams galima priskirti šias įmones.

Dabar, bendrai išaiškinus bendruosius funkcinius uždavinius, išspręstus nagrinėjamomis priemonėmis, reikėtų palyginti ir šių priemonių teikiamas galimybes.

Tolesnėje analizėje bus atsižvelgta tik į programų ARIS ToolSet (toliau ARIS), BP-Win - Erwin (toliau BP-Win) ir ORG-Master (toliau ORG-Master) charakteristikas. „Rational Rose“ programa – kaip labiausiai orientuota į vien tik programinės įrangos, o ne organizacinių sistemų kūrimą, siekiant supaprastinti pateikimą, išbrauksime iš svarstymo, juo labiau, kad UML metodika, kuria ji grindžiama, dabar įdiegta ARIS).

Verslo sistemų modeliavimo įrankių funkcionalumas

Lyginant įvairius verslo sistemų modeliavimo įrankius, patartina atsižvelgti į jų savybes pagal šias funkcionalumo grupes:

• verslo sistemų modelių kūrimo įrankiai;
• modelių analizės įrankiai;
• modeliuojamų sistemų optimizavimo pagal jų modelius priemones;
• standartinių modelių bibliotekų palaikymas;
• reglamentų ir dokumentų registravimas;
• parama duomenų bazių modelių ir programinės įrangos priemonių kūrimui;
• integracija su kitais programinės įrangos produktais (CASE įrankiais, ERP sistemomis, taikomosiomis programomis).

• bendras verslo procesų organizavimas ir organizacinių vienetų (atlikėjų) sąveikos tvarka,
• paskirstyti atsakomybę už atskirų funkcijų įgyvendinimą ir sistemos išteklių išlaidas,
• įkelti į sistemą organizacinius vienetus, atlikėjus ir instrumentinius išteklius,
• pagrindiniai modeliuojamos sistemos laiko ir sąnaudų parametrai,
• sistemoje vykstančių procesų resursų palaikymo reikalavimai.

Analizė bendras verslo procesų organizavimas ir organizacinių vienetų sąveikos tvarka sistemoje atliekama tiesiogiai tiriant sukurtus verslo procesų modelius. Kokybinė analizė taip pat atskleidžia vaidmenis, kuri tam tikromis sąlygomis gali būti pašalinta iš proceso. Kuriame modelio matomumas ir galimybė atsekti sistemoje egzistuojančius ryšiusįgauna itin didelę reikšmę.

Toliau pateikiamos pastabos, susijusios su modelių matomumu. Tačiau čia taip pat reikėtų pažymėti, kad svarbus modelio reikalavimas yra galimybė jį išanalizuoti prieš užbaigiant statybą. Iš tiesų, jei sistemoje galima nustatyti tarpusavio ryšius (taip pat ir jų nebuvimą) tik sukūrus visą jos modelį, tada tai pasirodo labai nepatogu pradiniuose darbo etapuose, kai gaunama informacija apie vykstančių procesų ypatybes. sistemoje vis tiek gali iš dalies nebūti arba ji gali būti netiksli.

Čia ORG-Master yra laimėjusioje padėtyje, nes jame verslo proceso modelis nėra tiesiogiai sukurtas IDEF diagramos forma. Ši diagrama gali būti automatiškai sugeneruota sukūrus ir užpildžius modelį formuojančius klasifikatorius (verslo funkcijas, organizacinius ryšius, išteklius ir kt.) ir nustačius visas reikalingas prognozes (ryšius pagal išteklius, atlikėjus, įrankius, reglamentus ir faktinius ryšius). tarp verslo operacijų). Taigi, dar prieš gaunant pilną (ar dalinį) verslo proceso modelį, pagrindiniai ryšiai, apibrėžiantys modeliuojamą procesą, jau yra nustatyti ir gali būti analizuojami.

Skirtingai nuo šio požiūrio, verslo procesų modeliai ARIS ir BP-Win yra kuriami tiesiogiai, o esami proceso komponentų ryšiai turi būti paruošti analizei dėl atitinkamų procedūrų.

Taigi, pavyzdžiui, sukūrus verslo procesų modelį BP-Win, naudojant ERwin, sukuriamas atskiras duomenų modelis, kuriame užmezgami ryšiai tarp sistemos komponentų (duomenų modelio subjektų pagal metodiką). Tada šie modeliai sujungiami mechanizmu, iš esmės panašiu į ORG-Master naudojamą projekcijos konstravimo mechanizmą (žr. 1 priedą. ORG-Master programinės įrangos ir metodinio komplekso modelių komponentai).

Atsižvelgiant į tai, antroji iš svarstytų modelio analizės galimybių: analizė atsakomybės paskirstymas už atskirų funkcijų įgyvendinimą ir sistemos išteklių sąnaudas, automatiškai diegiamas verslo proceso modelio kūrimo procese ORG-Master sistemoje. Iš tiesų, tipo organizacinės nuorodos – funkcijos ir funkcijos – ištekliai, nurodytos kuriant verslo procesų modelius ORG-Master, tiesiogiai parodo asmenis, atsakingus už tam tikrą darbo ar išteklių sritį (ir leidžia analizuoti bet kokį jų derinį). ). Be to, ORG-Master leidžia eksportuoti matricines projekcijas į MS Excel, kur jų pagrindu formuojamos organizacinės analizės diagramos.

Šiuo tikslu ARIS ir BP-Win reikia arba rankiniu būdu atsekti visas nuorodas verslo procesų diagramose (ir duomenų modeliuose BP-Win), arba specialiai sukurti atitinkamus sąrašus ar ataskaitas.

Klausimas apie atlikėjų ir instrumentinių išteklių įkėlimą į sistemą, taip pat gauti pagrindinių modeliuojamos sistemos laiko parametrų įverčius, gali būti nuspręsta remiantis kiekybiniais duomenimis apie jų įgyvendinamų funkcijų sudėtingumą (arba tiesiog trukmę). Norint išspręsti šią problemą, būtina tokius duomenis vienaip ar kitaip įvesti į sistemą, taip pat numatyti priemones suvestiniams įverčiams gauti. IDEF3 metodologijos (BP-Win), ABC metodų ARIS ir BP-Win ir ARIS modeliavimo priemonių (ir iš dalies BP-Win) palaikymas suteikia tam tikrą šių įvertinimų apdorojimą. Kalbant apie pačius pirminius duomenis, juos nustato vartotojas, todėl jis yra atsakingas už galutinį rezultatą.

Tačiau gauti pakankamai reprezentatyvius įverčius naudojant statistinį (modeliavimo/įvykių) modeliavimą (ir, juo labiau, naudojant ABC metodus, kai laikas laikomas ištekliu) sistemos komponentų įkėlimui sunku dėl šių veiksnių.

Šiuolaikiniai bet kokio proceso analizės metodai ( darbo eiga) padalyti jo įgyvendinimo laiką iš faktinio operacijų atlikimo laikotarpio ir jų rezultatų perdavimo laiko. Tuo pačiu metu biuro procesuose ar paslaugų teikimo procesuose faktinis darbas vidutiniškai užima apie 10% laiko, o likusį laiką praleidžiama arba fizinis judėjimas užduoties rezultatą (reikalaujama pasirašyti sutarties tekstą, kurį reikia dar kartą išplauti) ir laukti eilėje, kol kitas atlikėjas turės laiko tęsti procesą. Todėl metodai, pagrįsti paprastu operacijų laiko sumavimu šiuo metu, paprastai nesuteikia tikslaus supratimo apie proceso laiko parametrus.

Tinkamesnius rezultatus galima gauti imituojant sistemos elgesį. Tačiau dėl paslaugų vėlavimo laiko reikia daryti arba labai apytiksles prielaidas apie jų pasiskirstymo laike dėsnį, arba atlikti gana brangias ir daug laiko reikalaujančias laiko nustatymo procedūras ir vėlesnį statistinį apdorojimą. Tuo pačiu metu gautų rezultatų patikimumas nebus per didelis arba pareikalaus didelių papildomų išlaidų. Todėl atrodo pagrįstas požiūris, kad: „modeliavimo, siekiant gauti bet kokią informaciją, kaina neturi viršyti jos panaudojimo rezultatų vertės (kaštų). Be to, visada reikia turėti omenyje Pareto dėsnį, iš kurio, atsižvelgiant į nagrinėjamą problemą, išplaukia, kad 20% modeliavimo pastangų suteikia 80% efekto.

Todėl, mūsų požiūriu, prieš pereinant prie sudėtingų ir daug laiko bei resursų reikalaujančių modeliavimo metodų, susijusių su kiekybiniais laiko ir sąnaudų parametrų įvertinimais, verta sutelkti dėmesį į efekto gavimą įgyvendinus ryškesnius verslo modeliavimo rezultatus. Kiekybinis optimizavimas turėtų būti atliekamas atsižvelgiant į matavimus ir faktinių procesų analizę.

ORG-Master turi funkcinį ABC analizės įrankių analogą – Biudžeto sudarymo vedlį, kuris sukuria paprastą biudžeto sudarymo sistemą. Vienas iš šios sistemos rezultatų – kiekybinis verslo procesų diegimo kaštų įvertinimas ( veiklos biudžetus), kurio vertė bent jau palyginama su duomenimis, gautais naudojant ABC kaštų nustatymo palaikymo priemones.

Be to, ORG-Master šeimoje taip pat yra programinės įrangos paketas Time-Master, kurio vienas iš komponentų, užtikrinantis procesų valdymą (darbo eigą), leidžia kaupti statistiką jų vykdymo metu, kuri pateikia laiko parametrų įvertinimus. analizei reikalingi procesai.

• Verslo sistemų optimizavimo įrankiai (verslo procesai), be modelių analizės galimybių, suteikia: valdymo įrankį.
• kelių alternatyvų generavimas;
• planavimas;
• pasirinkti geriausią veiksmų kryptį;
• išteklių paskirstymas;
• prioritetų nustatymas.

Paprastai išvardytų funkcijų įgyvendinimas yra susijęs su specialių gana sudėtingų ar sudėtingų optimizavimo problemų sprendimo algoritmų naudojimu. Į ARIS sistemą įtraukta nemažai tokių galimybių. Tačiau jų įgyvendinimas apskritai neatrodo tinkamas iki verslo proceso sureguliavimo stadijos, pasiekus jo restruktūrizavimo rezultatus paprastesniais metodais.

Bendrųjų modelių bibliotekų palaikymas leidžia naudoti anksčiau sukurtus pokyčius kuriant naujus modelius. Ši galimybė numatyta visuose trijuose svarstomuose įrankiuose. Visų pirma, „ORG-Master“ palaiko abu įmonių etaloninius verslo modelius, gautus įgyvendinant realius projektus Rusijos įmonės, ir „bibliotekiniai“ klasifikatoriai, apibūdinantys tipišką atskirų veiklos aspektų organizavimą.

dekoras, pagal pastatytus modelius, įmonės nuostatai atrodo labai svarbi savybė, užtikrinanti dokumentinio verslo sistemos aprašymo vientisumą ir nuoseklumą. Šio komponento svarbą verslo modeliavimo priemonėms galima suprasti žiūrint į reglamentus kaip į įmonės valdymo įrankį. Iš tiesų, jei įmonė dirba stabiliai, tai reiškia, kad jos verslo procesai yra nusistovėję ir beveik formaliai reguliuojami. Vidinė kultūra, kuri turi būti tokioje įmonėje, prireikus leis greitai perstatyti sistemą ar verslo procesų parametrus keičiant atitinkamų padalinių ir atlikėjų darbo reglamentus.

Dokumentų-reglamentų buvimas visiems įmonės veiklos aspektams yra viena iš pagrindinių reguliaraus, sistemingo valdymo koncepcijos nuostatų. Anot jos, gerai organizuotame versle apie 80% vadovų sprendimų priimami pagal iš anksto nustatytas procedūras, o tik likusieji, susiję su nestandartinėmis situacijomis ir įvairiomis naujovėmis, pasikliauja darbuotojų kūrybiškumu ir didvyriškumu.

Įmonės (įmonės) veiklos organizavimą, skirtą tam tikriems tikslams pasiekti, šiuo metu reglamentuoja toks standartinis pagrindinių organizacinių dokumentų rinkinys:

• poziciją dėl organizacinės ir funkcinės struktūros, atspindinčios įmonėje remiamų verslų ir funkcijų sudėtį bei jų pasiskirstymą įmonėje;
• nuostatas dėl įmonės politikos (buhalterinės apskaitos, investicijų ir kt.);
• įmonės pagrindinių verslo ir valdymo posistemių organizavimo nuostatai, kuriuose detaliai aprašomos funkcijos veiklos srityse;
• dokumentuotos procedūros – verslo procesų aprašymai tokia forma, kuri leistų tiek pristatyti procesą išoriniam stebėtojui, tiek vadovautis šiuo dokumentu proceso operacijų vykdytojams;
• ir galiausiai tradiciniai „padalinių reglamentai“ ir „ pareigybių aprašymai» personalas su funkcinių pareigų, atsakomybės rūšių, darbuotojų teisių ir įgaliojimų sąrašais.

Be to, turėtų būti galima sukurti specialias ataskaitų formas įvairių funkcinių sričių dokumentams kurti: Įmonės valdymo informacinės sistemos techninę užduotį, Kokybės vadovą (žr., pvz., 3 priedą) ir kitus specialius dokumentus pagal ISO9000 standartą. ir kt.

Visa informacija, leidžianti sugeneruoti šiuos dokumentus, turi būti vientisos ir nuoseklios sistemos forma visame įmonės (įmonės) verslo modelyje. Be to, daugelis sukurtų dokumentų turėtų kiek įmanoma labiau atitikti visuotinai priimtus Rusijos standartus (akivaizdu, kad ARIS ir BP-Win sistemos mažiausiai atitinka paskutinį reikalavimą).

ORG-Master aplinkoje tokios nuostatos ir instrukcijos generuojamos automatiškai kaip tekstinės formos procedūroms aprašyti, pavaizduotos atitinkamais klasifikatoriais ir projekciniais ryšiais tarp jų. Grafinės formos (įvairūs digrafai ir proceso diagramos) puikiai papildo šiuos dokumentus.

ARIS aplinkoje pareigybių aprašymai ir procesų aprašymai remiasi procesų įvykių diagramomis ir iš esmės analizuojant procesų modelius ir organizacijos struktūras galima kurti įvairius tekstinius dokumentus. Nors čia daugiau vaizdas yra atvirkštinis - sistema daugiausia orientuota į grafikos kūrimą, o norminių dokumentų kūrimo funkcija yra aiškiai pagalbinė ir dėl to neišplėtota.

BP-Win tiesioginė galimybė gauti įvairius reglamentus nenumatyta.

Santykiuose projekto dokumentacija gali būti nagrinėjamos dvi pusės: verslo procesų aprašymas ir informacinės sistemos, skirtos palaikyti verslo procesus, aprašymas tolesniam jo vystymui. Pirmąjį iš jų beveik vienodai suteikia kiekvienoje nagrinėjamoje aplinkoje galimybė kurti įvairias ataskaitų formas remiantis sukurtais verslo procesų modeliais.

Kalbant apie informacinės sistemos kūrimo dokumentaciją, tradiciškiausias funkcijas suteikia BP-Win / ERwin aplinka, kuri iš tikrųjų buvo sukurta tam.

ARIS galimybės yra maždaug vienodos: pirmosiose duomenų modelio versijose jos buvo aprašytos pagal esybės ir ryšio schemą, vėlesnėse – UML kalba. Tačiau ARISToolset įrankis suteikia pažangesnių informacinių sistemų kūrimo funkcijų.

„ORG-Master“ galimybės leidžia visiškai reprezentuoti duomenų struktūras, reikalingas modeliuojamų verslo procesų informacinei palaikymui organizuoti, naudojant savo universalius įrankius - klasifikatorius ir projekcijas. Nėra formalizmų, tokių kaip ER diagramos, nors naujausiose versijose tai galima vizualizuoti DFD standarte. Be to, IDEF0 diagramose tapo įmanoma atspindėti funkcinių blokų sąveiką ne tik naudojant tiesioginį dokumentų ir failų perdavimą, bet ir per bendras duomenų bazes!

Pagalba kuriant duomenų bazių modelius ir programinės įrangos priemones paprastai reiškia CASE tipo įrankių ar susijusių įrankių, skirtų įmonės valdymo informacinėms sistemoms (pavyzdžiui, ERP klasės sistemoms) nustatyti, galimybes. Tokia pagalba gali suteikti šias funkcijas:

• informacijos valdymo sistemų architektūros analizė ir projektavimas,
• duomenų bazių ir failų dizainas,
• programavimas (programos kodo generavimas),
• priežiūra ir pertvarkymas,
• projektų valdymas.

Klausimai informacinių sistemų architektūros analizė ir projektavimas, paprastai baigiasi sistemos reikalavimų ir susijusių specifikacijų apibrėžimu. Šis etapas, taikant sisteminį požiūrį į dizainą, turėtų tiesiogiai remtis verslo sistemų modeliais ir iš tikrųjų juos detalizuoti. Todėl čia galioja visi aukščiau pateikti argumentai, apimantys sistemos modelių konstravimą, analizę ir optimizavimą, taip pat reglamentų ir dokumentacijos projektavimą.

Duomenų bazių ir failų dizainas(koncepcinis ir vidinis lygiai), duomenų modelių transformavimas, failų formatų aprašymas nagrinėjamuose įrankiuose yra pilnai palaikomas tik BP-Win (ERwin), nes ši aplinka yra specialiai sukurta tokioms problemoms spręsti.

ARIS aplinkoje tokia galimybė yra numatyta ARIS Toolset pakete projekto specifikacijos ir duomenų bazės parametrų apibrėžimo lygiu.

ORG-Master aplinkoje sukurtas metodas daro prielaidą (nors nebūtinai), kad modeliuojamose verslo sistemose gali būti naudojamos informacinės sistemos, kurios jau turi duomenų bazes. Tokiu atveju jų nereikia perdaryti, nebent būtų pakeista naudojama sistema. Tačiau, nesant informacinių sistemų, ORG-Master sukuria pagrindą koncepciniam duomenų modeliui ir duomenų failų struktūroms. Šį pagrindą reprezentuoja verslo procesų modeliuose naudojamų informacinių objektų ir dokumentų sudėties ir santykių aprašymai.

Programų arba sistemos įrankių programų kodų generavimas ARIS ir ORG-Master sistemos nepateikiamos, nes tai verslo sistemų projektavimo įrankiai, o ne programinė įranga. Tam tikru mastu ši funkcija įdiegta tik BP-Win.

Techninė priežiūra ir pertvarkymas. Šios funkcijos dažniausiai įgyvendinamos dokumentuojant, analizuojant programas, jas pertvarkant ir pertvarkant. Aukščiau pateiktos pastabos dėl dokumentavimo priemonių yra visiškai taikomos šiam svarstymui.

Funkcijos projektų valdymas duomenų bazių ir programinės įrangos įrankių kūrimas yra būdingas programinės įrangos produktų kūrimui. Tokia forma jie yra įdiegti BP-Win. Projektų valdymas ORG-Master šeimoje visiškai palaiko Time-Master programinės įrangos paketą. (Nors, griežtai kalbant, šios funkcijos nėra privalomos aptariamai įrankių klasei).

Integracija su kitais programinės įrangos produktais apima aptariamo įrankio taikymo srities išplėtimą ir gali būti atliekama tiek kuriant suderinamos programinės įrangos įrankių grupę (pvz., Platinum Technologies), tiek naudojant programinės įrangos įrankiai kiti kūrėjai (trečiųjų šalių programinė įranga).

Integracija su „trečiųjų šalių“ programinės įrangos produktais atliekama vienu iš šių tikslų:

• naudojant integruoto gaminio funkcionalumą išplėsti jo gaminio apimtį,
• suteikiant galimybę įtraukti savo produktą į trečiosios šalies produktą,
• daugiau ar mažiau universalios sąsajos suteikimas jūsų produktui, jei konkreti trečioji šalis nėra žinoma iš anksto.

Funkcinės orientacijos požiūriu integracija su:

• CASE reiškia,
• ERP sistemos,
• taikomosios programos.

ARIS turi sąsajų su kai kuriais CASE įrankiais ir taip pat yra modelių kūrimo įrankis, skirtas tiesioginiam tokių įmonių valdymo sistemų, pirmiausia SAP R/3, pritaikymui. Kaip minėta aukščiau, sistema remiasi savo žymėjimu, kad atspindėtų verslo procesus, todėl ji naudoja integruotus modeliavimo įrankius ir įrankį. kaštų analizė, kurių rezultatus galima eksportuoti į MS Excel formatus.

ORG-Master ir BP-Win sistemos palaiko IDEF0 žymėjimą, kad apibūdintų atstovaujamus verslo procesus. Iš esmės tai yra tam tikras ryšys tarp šių įrankių ir komunikacijos su kitais programinės įrangos produktais naudojant šią metodiką. Tačiau čia neatsižvelgiant į IDEF0 žymėjimo „amžiaus“ klausimus, reikia pažymėti, kad kiekvienoje sistemoje vidinis duomenų atvaizdavimas yra skirtingas, o IDEF0 sistemos „lizdų“ tipo arba klasių standartinė sąsaja yra skirtinga. nėra nurodyta. Tačiau yra standartizuotas failo formatas IDEF diagramoms pavaizduoti. Todėl nors jo pagalba sukurti aprašymai nėra labai patogūs tiek žmogui, tiek kompiuteriui, tačiau, esant atitinkamiems tokio formato keitikliams, juos galima panaudoti kaip apsikeitimo modeliais priemonę. Toks keitiklis pateikiamas šiose ORG-Master versijose.

BP-Win palaiko metodikas IDEF0, DFD ir IDEF3 ir integruojamas su šiais programinės įrangos produktais (dažniausiai to paties gamintojo):

• ERwin duomenų modeliavimo įrankis (Platinum Technology),
• ModelMart projektų valdymo ir saugojimo sistema (Platinum Technology),
• specializuotas ataskaitų generatorius, pagrįstas RPTwin modeliu (Platinum Technology),
• modeliavimo sistema BPSimulator (System Modeling Corporation),
• EasyABC išlaidų analizės įrankis (ABC Technologies).

(*Platinum Technology – „Computer Associates“ dalis nuo 1999 m.)

ORG-Master iš pradžių yra išdėstyta kaip organizacinė klasės sistema, orientuota į verslo procesų ir struktūrų modeliavimo ir projektavimo bei organizacinių sprendimų priėmimo palaikymą. Tai suteikia galimybę integruotis su savo kūrėjų paketais („BIG-SPB Software“), orientuotais į įvairių funkcinių užduočių sprendimą. ORG-Master sistemoje, jei reikia, MS Office aplinkoje automatiškai sukuriamos paprastos vykdomosios informacinės sistemos:

• Biudžeto sudarymo sistema (tai paprasta valdymo apskaitos, įmonės pelningumo ir mokumo valdymo sistema).
• Marketingo sistema (kaupianti operatyvią kiekybinę informaciją apie įmonės rinką, taip pat integruojanti su savo CRM sistema, skirta palaikyti ryšius su klientais).

Šių programų įdiegimas į įmonės veiklą leidžia greitai įsisavinti šiuolaikines valdymo technologijas, o tai labai palengvina perėjimą prie sudėtingesnių vykdomųjų sistemų.

Galima (ir buvo išbandyta projektuose) susieti duomenis per mainų failus kuriant integruotas informacines sistemas su partnerių įmonių vykdomosiomis ir analitinėmis programomis: 1C, AiT:Soft, Intalev, Comteh +, INEK ir kt., taip pat su integruotomis valdymo sistemomis įmonės ištekliais (pavyzdžiui, IPS gamyba).

Naujojoje versijoje taip pat numatyti mechanizmai verslo procesų aprašymams eksportuoti į „Time-Master“ programinį paketą, kuris apjungia Projektų valdymo, WorkFlow ir Asmeninės informacijos sistemos sistemų savybes ir yra paremtas interneto/Intraneto technologijomis.

Skyriaus santrauka:

Pagrindinės lyginamų priemonių funkcinės galimybės pateiktos 2 lentelėje, kur funkcijų ar savybių įgyvendinimo laipsnio vertinimai nurodyti penkių balų skalėje.

Kaip matyti iš 2 lentelės, tiesioginis įverčių suskirstymas sudaro apie ±4%. Toks išsibarstymas slypi pačių įverčių paklaidoje. Be to, pačios priemonės, kurios skiriasi savo funkcine orientacija, buvo vertinamos artimai dėl to, kad tiesiogiai skaičiuojant skirtingų priemonių stipriosios ir silpnosios pusės kompensuoja viena kitą.

Tačiau aptariant funkcionalumą buvo pabrėžta, kad tiesiogiai verslo inžinerijos problemoms spręsti atskiros funkcionalumo grupės turi skirtingas reikšmes. Šį faktą atspindi 2 lentelės stulpelyje „Svoris“ įrašyti koeficientai. Atsižvelgiant į šį faktorių, matyti, kad bendras ORG-Master komplekso įvertinimas yra šiek tiek pranašesnis už ARIS.

Tačiau vėlgi, tai gali būti skirtingų pasirinkimų ir prioritetų, susijusių su numatomu gaminio naudojimu, rezultatas. Pavyzdžiui, dėl mažesnio esamų kiekybinės modelių analizės priemonių (modeliavimo ir įvykių modeliavimo), taip pat optimizavimo įrankių reikšmingumo vertinimo, kurie vis dėlto yra menkai reprezentuoti visose nagrinėjamose sistemose. Kartu labai vertinamos savidokumentacijos modelių savybės arba įvairių modeliavimo aspektų vaizdavimo universalumas.

Apskritai, vertinant ir renkantis modeliavimo įrankį, rekomenduojama savarankiškai nuspręsti, kurie iš sistemos įrankių yra svarbiausi sprendžiant konkrečią jo taikymo problemą ir atitinkamai sudėti „svorius“.

Be to, 2 priedėlyje pateikiama formalizavimo standartų ir įrankių, skirtų tam tikriems modeliams, kurie naudojami nagrinėjamose sistemose, konstravimui ir (arba) analizei, apžvalga.

Verslo procesų modeliavimas yra efektyvi priemonė ieškant būdų optimizuoti įmonės veiklą, leidžianti nustatyti, kaip veikia visa įmonė ir kaip organizuojama veikla kiekvienoje darbo vietoje. Verslo proceso modelio (aprašo) kūrimo metodika (žymėjimas) suprantama kaip visuma būdų, kuriais realaus pasaulio objektai ir ryšiai tarp jų atvaizduojami modelio pavidalu. Kiekvienas objektas ir saitai pasižymi daugybe parametrų ar atributų, atspindinčių tam tikras realaus objekto charakteristikas (objekto numeris, pavadinimas, aprašymas, vykdymo laikas (funkcijoms), kaina ir kt.).

Verslo procesų aprašymas atliekamas tolesnei jų analizei ir pertvarkymui. Reorganizavimo tikslas gali būti informacinės sistemos įdiegimas, sąnaudų mažinimas, klientų aptarnavimo kokybės gerinimas, darbo ir darbo instrukcijų sukūrimas ir pan., o detalus procesų aprašymas pats savaime nėra vertingas.

Pertvarkymas verslo procesai (angl. Business process reengineering) – tai esminis verslo procesų permąstymas ir radikalus pertvarkymas siekiant maksimalaus gamybos, ūkinės ir finansinės bei ekonominės veiklos efektyvumo, įforminamas atitinkamomis organizacinėmis ir administracinėmis bei norminiai dokumentai. Verslo inžinerija susideda iš verslo procesų modeliavimo (modelio „kaip yra“ kūrimas, jo analizė, modelio „kaip“ kūrimas) ir perėjimo į būseną „kaip reikia“ plano kūrimo ir įgyvendinimo.

Daugelio šiuolaikinių verslo procesų modeliavimo metodikų pagrindas buvo SADT metodika (Structured Analysis and Design Technique – struktūrinės analizės ir projektavimo metodas), IDEF standartų šeima (Icam DEFinition, kur Icam yra Integrated Computer-Aided Manufacturing) ir algoritminė. kalbomis.

Pagrindiniai verslo procesų modeliavimo ir analizės metodikų tipai:

Verslo procesų modeliavimas ( verslo procesų modeliavimas). Plačiausiai naudojama verslo procesų apibūdinimo metodika yra IDEF0 standartas. IDEF0 žymėjimo modeliai yra skirti aukšto lygio įmonės veiklos apibūdinimui funkciniu aspektu.

Darbo eigos aprašymas ( Darbo srauto modeliavimas). IDEF3 standartas skirtas darbo eigoms aprašyti ir yra artimas algoritminiams struktūrinių schemų kūrimo metodams.

Duomenų srautų aprašymas ( Duomenų srauto modeliavimas). DFD žymėjimas ( Duomenų srauto diagrama), leidžia atspindėti proceso metu atliekamų darbų seką, tarp šių darbų cirkuliuojančius informacijos srautus.

kitos metodikos.

Kalbant apie produkto ar paslaugos pridėtinę vertę, galima išskirti šias procesų klases:

Pagrindiniai verslo procesai (pvz., rinkodara, gamyba, tiekimas ir paslaugų priežiūra Produktai).

Verslo procesų palaikymas neprideda produkto vertės, o padidina jo vertę (pavyzdžiui, finansinė parama veiklai, personalui, teisinė pagalba, administravimas, saugumas, komponentų tiekimas, remontas ir Priežiūra ir tt).

Verslo procesų valdymas.

Verslo modelis yra formalizuotas (grafinis, lentelinis, tekstinis, simbolinis) verslo procesų aprašymas. Pagrindinė verslo modelių taikymo sritis yra verslo procesų pertvarkymas.

Verslo procesų modeliavimo tikslai paprastai formuluojami taip:

Suteikti supratimą apie organizacijos struktūrą ir joje vykstančių procesų dinamiką;

Suteikti supratimą apie aktualias organizacijos problemas ir jų sprendimo galimybes;

Įsitikinkite, kad klientai, vartotojai ir kūrėjai turi vienodą supratimą apie organizacijos tikslus ir uždavinius;

Sukurti bazę formuoti reikalavimus programinei įrangai, automatizuojančiai organizacijos verslo procesus (programinės įrangos reikalavimai formuojami verslo modelio pagrindu).

Svarbus verslo proceso modelio elementas yra verslo taisykles arba domeno taisyklės. Tipiškos verslo taisyklės yra įmonės politika ir valstybės įstatymus. Verslo taisyklės dažniausiai suformuluojamos specialiame dokumente ir gali būti atspindėtos modeliuose.

Skilimas bendrąja prasme tai yra metodas, leidžiantis vienos didelės problemos sprendimą pakeisti eilės mažesnių problemų sprendimu, padalinant objektą į jo sudedamąsias dalis pagal nustatytą kriterijų. Praktikoje dekompozicija naudojamas verslo modeliams tobulinti.

Verslo proceso aprašymo etapai:

Aprašymo tikslo nustatymas.

Aplinkos aprašymas, verslo proceso įėjimų ir išėjimų apibrėžimas, IDEF0 diagramų konstravimas.

Funkcinės struktūros aprašymas (proceso veiksmai), IDEF3 diagramų konstravimas.

Proceso srautų (medžiaginių, informacinių, finansinių) aprašymas, DFD diagramų sudarymas.

Pastatas organizacinė struktūra procesas (skyriai, dalyviai, atsakingi).

IDEF0

Modelį sudaro diagramos, teksto fragmentai ir žodynėlis su nuorodomis viena į kitą. Diagramos yra pagrindiniai modelio komponentai, visos funkcijos ir sąsajos pateikiamos kaip blokai ir lankai.

Lanko sujungimo su bloku taškas nustato sąsajos tipą:

Valdymo informacija į bloką patenka iš viršaus.

Įvesties informacija įtraukta į bloką kairėje.

Rezultatai išeina iš bloko dešinėje.

Operaciją atliekantis mechanizmas (žmogaus arba automatizuota sistema) patenka į įrenginį iš apačios.

Kiekvienas modelio komponentas gali būti išskaidytas (išsamiau iššifruotas) kitoje diagramoje. Modeliavimą rekomenduojama nutraukti, kai modelio detalumo lygis atitinka jo paskirtį. Bendras modelio lygių skaičius neturi viršyti 5-6.

Diagramos kūrimas prasideda nuo visos sistemos vaizdavimo vieno bloko ir lankų, vaizduojančių sąsajas su funkcijomis už sistemos ribų, pavidalu. Tada blokas, vaizduojantis sistemą kaip vieną modulį, detalizuojamas kitoje diagramoje, naudojant kelis blokus, sujungtus sąsajos lankais. Kiekviena išsami diagrama yra bloko išskaidymas iš ankstesnio lygio diagramos. Kiekviename išskaidymo etape ankstesnio lygio diagrama vadinama pagrindine diagrama, skirta išsamesnei diagramai.

Tokios diagramos aiškiai nenurodo nei sekos, nei laiko. Metodas turi nemažai trūkumų: suvokimo sudėtingumas (daug lankų diagramose ir daug skaidymo lygių), sudėtinga susieti kelis procesus.

IDEF3

Šis metodas skirtas imituoti veiksmų seka ir tarpusavio priklausomybes tarp procesų. IDEF3 modeliai gali būti naudojami norint išgręžti IDEF0 funkcinius blokus, kurie neturi dekompozicijos diagramų.

Rodomos IDEF3 diagramos veiksmas stačiakampio pavidalu. Veiksmai įvardijami naudojant veiksmažodžius arba žodinius daiktavardžius, o kiekvienam veiksmui suteikiamas unikalus identifikavimo numeris (prieš veiksmo numerį dažniausiai rašomas pirminio veiksmo numeris, pvz., 1.1.).

Visos IDEF3 nuorodos yra vienakryptės ir išdėstytos iš kairės į dešinę.

IDEF3 nuorodų tipai:

Laikinoji pirmenybė, paprasta rodyklė. Šaltinio veikla turi būti baigta, kol gali prasidėti pabaigos veikla.

Objekto srautas, rodyklė su dviem galais. Pradinio veiksmo rezultatas yra galutinio veiksmo įvestis. Šaltinio veikla turi būti baigta, kol gali prasidėti pabaigos veikla. Srautinio perdavimo nuorodų pavadinimai turi aiškiai identifikuoti objektą, kuris perduodamas jų pagalba.

Neryškūs santykiai, taškinė rodyklė.

Vieno veiksmo atlikimas gali inicijuoti kelių kitų veiksmų vykdymo pradžią vienu metu arba atvirkščiai, tam tikram veiksmui prieš pradedant jo vykdymą gali prireikti atlikti keletą kitų veiksmų (proceso išsišakojimas).

Proceso išsišakojimas atspindimas naudojant specialius blokus:

- "Ir", blokas su ženklu &.

- "XOR" ("vienas iš"), blokas su X ženklu.

- "OR", blokas su ženklu O.

Jei veiksmai „IR“, „ARBA“ turi būti atliekami sinchroniškai, tai rodo dvi dvigubos vertikalios linijos bloko viduje, asinchroniškai – viena.
IDEF3 metodas leidžia išskaidyti veiklą kelis kartus, o tai užtikrina, kad alternatyvūs proceso srautai būtų dokumentuojami viename modelyje.

DFD

Šio pristatymo tikslas – parodyti, kaip kiekvienas procesas transformuojasi jų įnašas duomenis savaitgalį. Jis gali atspindėti ne tik informaciją, bet ir materialinius srautus. Taip pat, kaip ir kituose modeliuose, palaikomas skaidymas.

Pagrindiniai duomenų srauto diagramų komponentai yra šie:

Išoriniai subjektai (materialus objektas arba individualus, kurie yra informacijos šaltinis arba gavėjai, pavyzdžiui, klientai, darbuotojai, tiekėjai, klientai, sandėlis);

Sistemos ir posistemės (pavyzdžiui, darbo su asmenimis posistemis);

Procesai (įvesties duomenų srautų pavertimas išvesties pagal tam tikrą algoritmą; fiziškai tai gali būti, pavyzdžiui, organizacijos (skyriaus) padalinys, kuris apdoroja įvesties dokumentus ir išduoda ataskaitas, programa, aparatine įranga įdiegta logika. prietaisas ir kt.);

Duomenų saugojimo įrenginiai (abstrakčiai informacijos saugojimo įrenginiai);

Duomenų srautai (rodyklės diagramoje).

Kiekvienoje diagramoje būtina išdėstyti nuo 3 (mažiau nėra prasmės) iki 7 (daugiau – nesuvokiama) procesų, neužgriozdinus diagramų smulkmenomis, kurios šiame lygyje yra nereikšmingos.

Pirmasis žingsnis kuriant DFD hierarchiją yra konteksto diagramų kūrimas. Paprastai, projektuojant gana paprastas sistemas, statoma viena kontekstinė diagrama su žvaigždžių topologija, kurios centre yra vadinamasis pagrindinis procesas, prijungtas prie imtuvų ir informacijos šaltinių. Sudėtingoms sistemoms (dešimt ar daugiau išorinių objektų, paskirstytas sistemos pobūdis ir daugiafunkciškumas) sudaroma kontekstinių diagramų hierarchija. Tuo pačiu metu aukščiausio lygio kontekstinėje diagramoje yra ne vienas pagrindinis procesas, o rinkinys posistemių, sujungtų duomenų srautais.

Kiekvienas DFD procesas gali būti detalizuotas naudojant DFD arba (jei procesas yra elementarus) specifikaciją. Specifikacijos – tai procesų atliekamų užduočių algoritmų aprašymai. Specifikacijų kalbos gali būti nuo struktūrinės natūralios kalbos ar pseudokodo iki vizualinio modeliavimo kalbų.

Verslo procesų modeliavime duomenų srautų diagramos (DFD) naudojamos kuriant „TOKOKIA“ ir „TAIP BŪTI“ modelius, taip atspindinčius organizacijos esamą ir siūlomą verslo procesų struktūrą.

ARIS

Šiuo metu pastebima tendencija integruoti įvairius modeliavimo metodus, pasireiškiančius integruotų modeliavimo įrankių kūrimu. Vienas iš šių įrankių yra programinės įrangos produktas ARIS (Integruotų informacinių sistemų architektūra), sukurtas Vokietijos įmonės IDS Scheer.

ARIS palaiko keturių tipų modelius (ir daug kiekvieno tipo modelių), atspindinčius skirtingus tiriamos sistemos aspektus:

Organizaciniai modeliai, reprezentuojantys sistemos struktūrą – organizacijos vienetų, pareigybių ir konkrečių asmenų hierarchiją, sąsajas tarp jų, taip pat struktūrinių vienetų teritorinį susiejimą;

Funkciniai modeliai, kuriuose yra valdymo aparato tikslų hierarchija su funkcijų medžių rinkiniu, reikalingu tikslams pasiekti;

Informacijos modeliai, atspindintys informacijos, reikalingos visam sistemos funkcijų rinkiniui įgyvendinti, struktūrą;

Valdymo modeliai, atspindintys visapusišką verslo procesų įgyvendinimo sistemoje vaizdą.

Kuriant išvardytų tipų modelius, naudojami tiek ARIS modeliavimo metodai, tiek įvairūs gerai žinomi modeliavimo metodai ir kalbos, ypač UML. Modeliavimo procesą galima pradėti nuo bet kurio modelio tipo.

Pagrindinis ARIS verslo modelis yra eEPC (Extended Event-driven Process Chain, Extended Event-driven Process Chain Model). ARIS eEPC žymėjimas yra IDEF3 žymėjimo plėtinys. Verslo procesas eEPC žymėjime – tai nuosekliai atliekamų darbų (procedūrų, funkcijų) srautas, išdėstytas jų atlikimo tvarka. Tikroji procedūrų trukmė eEPC vizualiai neatspindi.

Norint gauti informaciją apie faktinę procesų trukmę, būtina naudoti kitus aprašymo įrankius, pavyzdžiui, MS Project.

ARIS modeliai yra diagramos, kurių elementai yra įvairūs objektų– „funkcijos“, „įvykiai“, „struktūriniai padaliniai“, „dokumentai“ ir kt. Galima nustatyti tarp tam tikrų tipų objektų jungtys tam tikrų tipų („atlieka“, „priima sprendimą“, „turėtų būti operatyviai informuotas apie rezultatus“ ir kt.). Kiekvienas objektas atitinka tam tikrą atributų rinkinį, leidžiantį įvesti Papildoma informacija apie konkretų objektą.

Pagrindiniai eEPC žymėjimo objektai yra šie:

Funkcija. Naudojamas įmonės padalinių / darbuotojų atliekamoms funkcijoms (procedūroms, darbams) apibūdinti. Kiekviena funkcija turi būti inicijuota įvykio ir turi baigtis įvykiu; Kiekviena funkcija negali įvesti daugiau nei vienos rodyklės, „pradedančios“ funkcijos vykdymą, ir išeiti iš daugiau nei vienos rodyklės, apibūdinančios funkcijos užbaigimą.

Renginys. Naudojamas apibūdinti tikriems įvykiams, turintiems įtakos funkcijų vykdymui.

Organizacinis vienetas. Pavyzdžiui, vadovybė ar skyrius.

dokumentas. Atspindi tikrąją laikmeną, pvz., popierinius dokumentus.

Taikymo sistema.

informacijos klasteris. Apibūdina esybių rinkinį ir ryšius tarp jų.

Bendravimas tarp objektų. Ryšio tarp objektų tipas, pavyzdžiui, funkcijos vykdymo suaktyvinimas dėl kurio nors įvykio.

Būlio operatorius. „AND“, „OR“ arba išskirtinis „OR“ operatorius leidžia apibūdinti proceso išsišakojimą.

Jei kurdami modelį eEPC nurodysite tik procedūrų seką, nesirūpindami kontrolės dokumentų ir informacijos atspindžiu, gauti modeliai bus menkos vertės analizės ir tolesnio naudojimo požiūriu.

Objektas DBVS naudojamas modeliams saugoti ARIS, o kiekvienam projektui sukuriama nauja duomenų bazė. Teikiamos įvairios duomenų bazių administravimo funkcijos, pavyzdžiui, prieigos kontrolė. Duomenų bazė yra hierarchinė modelių saugykla.

Modelio kūrimo darbas turėtų būti reglamentuojamas griežtomis ir didelėmis modeliavimo sutartimis (standartais), ARIS palaiko metodinį filtravimo mechanizmą, leidžiantį vartotojui naudoti tik tam tikrą schemų ir objektų rinkinį. Tokių sutarčių sudarymas reikalauja nemažai laiko ir aukštos kvalifikacijos specialistų. Jei projektas naudojant ARIS pradedamas detaliai neplanuojant tokių sutarčių, tada tikimybė sukurti verslo procesų modelius, neatsakančius į pateiktus klausimus, yra labai didelė.

Verslo procesų modeliavimas tapo klasikiniu daugelio verslo analitikų darbu, kuris yra verslo procesų optimizavimo ir Rusijos įmonių veiklos standartizavimo dalis. Tam tikrais atvejais naudojama daugybė žymenų. Šis straipsnis skirtas verslo procesų modeliavimo žymėjimų apžvalgai.

VAD (vpridėtinės vertės grandinės diagrama)

VAD žymėjimas, kurį pasiūlė Michaelas Porteris savo darbe apie įmonės strategiją, yra skirtas modeliuoti verslo procesus, kurie „kuria vertę“ paslaugų ar produktų forma klientui. Verslo proceso modelis, sukurtas naudojant VAD žymėjimą, suteikia bendrą, nedetalų verslo procesų vaizdą.

Naudodami VAD žymėjimą galite aprašyti verslo procesų sąrašą ir ryšį aukščiausiu lygiu, nes šis žymėjimas leidžia atvaizduoti visus įmonės verslo procesus viename modelyje. VAD žymėjime galite naudoti ryšius, kurie parodo verslo procesų ryšį vienas kito atžvilgiu, o proceso eiga šioje žymėjime daugeliu atvejų yra nukreipta iš kairės į dešinę.

Įvairiuose įrankiuose įdiegta daugybė VAD žymėjimo parinkčių, kurių kiekviena turi savo simbolių rinkinį, tačiau jos visos atrodo maždaug vienodai - verslo procesų rinkinys, dažnai susietas „pirmtako ir pasekėjo“ nuorodomis.

Pavyzdžiui, šio žymėjimo išplėtimas ARIS įrankių rinkinyje leidžia parodyti verslo proceso modelio vykdytojus, riziką, dokumentus, duomenis ir daug daugiau.

VAD žymėjimas leidžia ne tik modeliuoti organizacijos verslo procesų žemėlapį, bet ir modeliuoti verslo procesus nuo galo iki galo jų pradinio apibrėžimo metu. Tačiau reikia suprasti, kad VAD nėra sukurtas tam, kad modeliuotų logines proceso sąlygas, todėl vadovybė jį gerai priima. Praktiškai sumodeliavus verslo procesus aukščiausiu lygiu VAD notacijoje, seka smulkesnis verslo procesų modeliavimas kitose notacijose, kurias plačiau aptarsime toliau.

VAD žymėjimo modelį galima nubraižyti įvairiais įrankiais, tokiais kaip MS Visio ir daugelis kitų verslo procesų modeliavimo įrankių.

Verslo procesų modeliavimas – EPC (įvykiais valdoma proceso grandinė)

EPC žymėjimą sukūrė profesorius Augustas Wilhelmas Scheeris pagal ARIS priemonių rinkinio metodiką. Su pagalba verslo procesas modeliuojamas kaip proceso veiksmų, kuriuos suaktyvina įvykiai, sąrašas. Žymėjimas patogus tolimesniam verslo proceso reguliavimui, taip pat verslo proceso informacijos srauto (gaunamų/išsiunčiamų dokumentų) analizei.

laisvė EPC žymėjimas leidžia aprašyti papildomus objektus verslo procesų modeliavimo rėmuose, tokius kaip veiklos rizika, valdymo procedūros, ekrano formos, informacinės sistemos, rodikliai ir daug daugiau.

EPC notacijos rėmuose procesas modeliuojamas „iš viršaus į apačią“, o verslo proceso žingsnių/funkcijų/veiksmų/operacijų atlikimo tvarka nustatoma per įvykių ir loginių sąlygų sistemą. Kaip įvykiai EPC žymėjime laikomi proceso etapų pradžia ir pabaiga, taip pat išoriniai įvykiai, į kuriuos reikia reaguoti iš organizacijos.

Verslo procesų modelis susideda iš sekų „įvykis-funkcija-įvykis“ ir loginių operatorių „AND“, „ARBA“, „išskirtinis ARBA“, kurie rodo sprendimus, būklės patikrinimą, modeliuojamo verslo proceso srautų lygiagretavimą ir konvergenciją.

Yra daug EPC žymėjimo parinkčių, stulpelių, eilučių formatu, taip pat su skirtingais naudojamų objektų sąrašais, tačiau visos šios parinktys yra prieinamos tik ARIS įrankių rinkinyje, o kitose priemonėse, pavyzdžiui, MS Visio ar Business Studio, galimas tik EPC verslo procesų modeliavimas.klasikiniu formatu.

Verslo proceso modeliavimas EPC žymėjimu leidžia vėliau gauti tekstinį arba lentelę verslo proceso reglamentą, nes teisingai nubraižytas EPC modelis gali būti paverstas įprastos kalbos sakinių seka, kuri tampa reguliavimo pagrindu. Štai kodėl šis žymėjimas laikomas patogiausiu modeliuojant verslo procesus tolesnei analizei ir reguliavimui.

Modeliavimas verslui— procesus– BPMN (verslo proceso modelis ir žymėjimas 2.0)

BPMN žymėjimą sukūrė objektų valdymo grupė (OMG) ir yra skirta verslo procesų modeliavimui, siekiant vėliau juos automatizuoti. BPMN žymėjimas naudojamas detaliam verslo proceso modeliavimui, o objektų skaičius šioje žymėjime viršija 100, kas leidžia aprašyti visus verslo procesų elgsenos niuansus, kad informacinė sistema sukurtą modelį galėtų paversti vykdomuoju. kodas.

Dėl BPMN žymėjimo atvirumo ir daugelio verslo procesų modeliavimo ir automatizavimo įrankių palaikymo šis žymėjimas tapo verslo procesų modeliavimo lyderiu.

BPMN žymėjime, be verslo proceso žingsnių, galite modeliuoti pradžios, tarpinius ir galutinius proceso įvykius, informacijos srautus ir pranešimų srautus. Iš žymėjimo ypatybių galima išskirti numatytąjį plaukimo takelių modeliavimo stiliaus (plaukimo takelių) naudojimą, kai atlikėjas parodomas kaip vertikali arba horizontali juostas primenanti juosta baseine, ir būtent šiame takelyje. yra šio atlikėjo atliekami veiksmai / operacijos.

Verslo proceso supaprastinimas Swim Lane formatu padaro atsakomybės ir darbo eigos perkėlimą tarp proceso dalyvių vizualų, tačiau tuo pačiu apsunkina modeliavimą, kai vienoje operacijoje yra keli bendrai vykdytojai.

BPMN žymėjimu nubraižytus modelius dažnai sunku sujungti į nuoseklią hierarchiją, nes metodika iš pradžių buvo sukurta siekiant automatizuoti „nuo galo iki galo“ verslo procesus.

BPMN žymėjimo taikymas reikalauja tam tikros patirties, kuri dažnai riboja šių modelių kūrėjų skaičių iki sistemų ir verslo analitiko. Verslo padalinių atstovai retai modeliuoja verslo procesus BPMN žymėjimu.

Nepaisant grafinių skirtumų, BPMN ir EPC žymėjimai yra labai panašūs vienas į kitą, o ARIS įrankių rinkinyje juos jau galima konvertuoti vienas į kitą, nors ir su tam tikrais metodiniais apribojimais.

Verslo procesų modeliavimas – srautinė diagrama

Žymėjimo pavadinimas yra Flow Charting, jį lengviausia išversti kaip struktūrines diagramas. Šis žymėjimas iš pradžių pasirodė ANSI standarte 1970 m., jame yra labai paprastas simbolių rinkinys.

Per daugelį Flow Charting notacijos egzistavimo metų buvo nubraižyta daug schemų variantų, kuriuose yra simboliai, skirti įvairioms problemoms spręsti, pavyzdžiui, aprašyti medžiagų srautus, vaidmenis ir darbus, įrangą, analizuoti funkcijų įvestis ir išvestis.

Tiesą sakant, struktūrinės schemos buvo šiuolaikinių verslo procesų modeliavimo žymėjimų pirmtakės ir iki šiol buvo mokomos daugelyje švietimo įstaigų kaip informacinių technologijų disciplinų dalis.

Flow Charting notacija neturi griežto standarto, leidžiančio modeliuoti verslo procesus iš skirtingų požiūrių, prireikus į modelį įtraukti tam tikrus objektus. Tokiu būdu šis žymėjimas labai panašus į EPC, tačiau turi dar daugiau laisvės taikymo atžvilgiu. Laisvė naudoti srauto diagramą ir daugumos nebrangių ir net nemokamų verslo procesų modeliavimo įrankių palaikymas padarė šį žymėjimą pritaikytą daugelyje įmonių.

Tarp „Flow Charting“ trūkumų galima išskirti tipinio objektų ir atributų sąrašo nebuvimą, o tai yra atvirkštinė šio žymėjimo „laisvės“ pusė. Tai leidžia modeliuoti tą patį verslo procesą šioje žymoje taip, kad modeliai labai skirsis vienas nuo kito.

Nepaisant to, kad verslo procesų modelius srautinės diagramos žymėjime galima rasti gana dažnai, greičiausiai tai taps praeitimi, užleis vietą „griežtesniems užrašams“.

Modeliavimas verslui— procesus– IDEF (integruotos apibrėžimo kalba)

IDEF žymėjimas atsirado aštuntajame dešimtmetyje kaip JAV vyriausybės standartas, orientuotas į verslo proceso įvestis, išvestis, mechanizmus ir valdymą bei susiejantis organizacijos procesus į hierarchiją. Pagrindinis šio žymėjimo elementas yra funkcija, o visi kiti objektai ir sąveikos modeliuojami naudojant ryšius.

Žymėjimui naudojamas labai paprastas simbolių rinkinys: proceso stačiakampiai ir rodyklės, vaizduojančios įvestis, išvestis, valdiklius ir mechanizmus, šis žymėjimas išsiskiria „įtaisyta“ verslo proceso žingsnių numeravimo sistema, leidžiančia atsekti ryšius tarp pirminių ir vaiko procesai.

Atsižvelgiant į šio standarto istoriją ir gana plačiai paplitusį naudojimą, jis yra įdiegtas daugelyje modeliavimo įrankių, tačiau vis tiek šis žymėjimas gali būti priskirtas išeinančiajai kartai, nes jis turi vis mažiau šalininkų, o verslo atstovai dažnai elgiasi su šiomis „mikro grandinėmis“ skepticizmas.

UML (vieninga Modeliavimas Kalbos)

Vieningoji modeliavimo kalba (UML) yra žymėjimų ir modeliavimo metodų rinkinys, skirtas apibūdinti reikalavimams Informacinės sistemos, tačiau tarp UML žymėjimų yra ir specializuotas žymėjimas, sukurtas specialiai verslo procesams modeliuoti. UML palaiko Object Management Group (OMG), todėl ši metodika tapo gana paplitusi tarp IT specialistų.

Šis žymėjimas labai panašus į EPC ir BPMN, skiriasi tik loginių teiginių ir įvykių rodymas, ir nors yra daug knygų apie UML žymėjimą ir ją palaiko daugelis modeliavimo įrankių, UML Activiti diagrama daugiausia naudojama sistemų analizei. ir dizainas, ir tik nedidelė dalis įmonių naudoja UML verslo procesams modeliuoti

VSM (vertė Srautas Žemėlapių sudarymas)

VSM žymėjimo pavadinimas gali būti išverstas į rusų kalbą, nurodantis kliento vertės srautą. Originalus šio užrašo pavadinimas Toyota korporacijoje, kur, kaip manoma, jis sugalvojo, yra medžiagų ir informacijos srauto žemėlapis.

VSM žymėjimas buvo sukurtas kaip Lean metodikos dalis ir naudoja konkrečių simbolių rinkinį, rodantį išteklių ir laiko sąnaudų elementus, kad būtų galima analizuoti verslo proceso efektyvumą Lean 6Sigma projektuose. Vertės srauto žemėlapis vaizduoja fizinę aplinką ir medžiagų bei produktų srautą gamybos procese ir yra naudojamas išteklių ir laiko sąnaudoms susieti su procesu ir taip suteikti įžvalgų apie našumą.

Šio žymėjimo tikslas – įtraukti jo dalyvius į verslo proceso analizę, siekiant paskatinti juos savarankiškai ieškoti optimizavimo galimybių. Paprastai VSM modeliai braižomi projektuose ant Flip Chart ir nereikalauja rimtų verslo procesų modeliavimo įrankių, nes jo pagrindu priimami sprendimai, o pats modelis netampa nei reglamentavimo, nei IT sprendimo pagrindu.

Pagrindinis dalykas kuriant modelį VSM žymėjime yra užpildyti laikinus atributus pagal procesą, ieškoti „kliūčių“ ir perteklinio atsargų saugojimo vietų.

Šis užrašas turi ribotą sekėjų ratą, o tarp plačių verslo analitikų masių artimiausiu metu dėl jo pagalba sprendžiamų užduočių specifikos jis nebus paplitęs. Tačiau tuo pat metu daugelis verslo procesų modeliavimo įrankių, pvz., ARIS, jau sukūrė plėtinius, kad palaikytų verslo procesų modeliavimą šioje žymėjime.

SIPOC

Santrumpa SIPOC reiškia: Tiekėjas (tiekėjas), Input (input), Process (process), Output (output), Klientas (vartotojas). Tai yra Six Sigma metodikoje perimtas proceso dokumentacijos šablonas, iš tikrųjų tai net ne modelio žymėjimas, o lentelės formatas, leidžiantis aprašyti verslo procesą aukščiausiu lygiu. SIPOC modelis efektyviausiai taikomas apibrėžiant verslo procesų ribas, sąveikaujančias šalis ir proceso įvestis/išvestis.

SIPOC žymėjimo nėra, nes tai paprasta lentelė su atitinkamomis antraštėmis, leidžianti struktūrizuoti pasirinktą verslo procesą tolesnei analizei ir optimizavimui.

SIPOC, skirtingai nuo kitų diagramų, naudingumas slypi galimybėje jį naudoti verslo padalinių darbuotojams, nes jame nėra sudėtingos logikos ir daugybės objektų, tokių kaip EPC ar BPMN žymėjimai.

Verslo procesų modeliavimas – išvados

Taigi, aš pažvelgiau į kai kuriuos verslo procesų modeliavimo ženklus, kuriuos galima rasti Rusijos rinka(Jie išsamiau aprašyti BPM CBOK skyriuje apie verslo procesų modeliavimą). Kurį iš žymėjimų pasirinkti naudoti – atviras klausimas, pavyzdžiui, modeliuojant organizacijos verslo procesus aukščiausiu lygiu, naudoju VAD žymėjimą, pirminiam optimizavimui pasirinkto verslo proceso modeliavimui lengviau naudoti SIPOC arba VAD. Sukurti detalius verslo procesų modelius – supaprastintą BPMN tarpfunkcinei sąveikai modeliuoti arba EPC detaliam modeliavimui, siekiant formalizuoti informacijos srautą ir su verslo procesu susijusių objektų rinkinį. Na, o jei jums reikia automatizuoti verslo procesą BPMS sistemoje, tuomet neapsieisite be BPMN žymėjimo.

Verslo procesų modeliavimas yra vienas iš būdų pagerinti organizacijos kokybę ir efektyvumą. Šis metodas pagrįstas proceso aprašymu per įvairius procesui būdingus elementus (veiksmus, duomenis, įvykius, medžiagas ir kt.). Paprastai verslo procesų modeliavimas apibūdina loginį visų proceso elementų ryšį nuo jo pradžios iki pabaigos organizacijoje. Sudėtingesnėse situacijose modeliavimas gali apimti procesus ar sistemas, esančias už organizacijos ribų.

Verslo procesų modeliavimas leidžia suprasti darbą ir analizuoti organizaciją. Tai pasiekiama dėl to, kad modelius galima sudaryti įvairiems valdymo aspektams ir lygiams. Didelėse organizacijose verslo procesų modeliavimas yra detalesnis ir įvairiapusiškesnis nei mažose, o tai susiję su daugybe tarpfunkcinių ryšių.

Paprastai verslo procesams modeliuoti naudojami įvairūs kompiuteriniai įrankiai ir programinė įranga. Taip lengviau valdyti modelius, stebėti jų pokyčius ir sutrumpinti analizės laiką.

Verslo procesų modeliavimo tikslai

Galutinis verslo procesų modeliavimo tikslas yra pagerinti našumą. Norėdami tai padaryti, analizė orientuota į pridėtinės vertės pridėjimą prie proceso rezultatų ir išlaidų bei laiko, skirto veiklai užbaigti, mažinimą.

Verslo procesų modeliavimas turi keletą tikslų:

• Pirma, tai yra procesų aprašymo tikslas. Modeliuojant galima atsekti, kas vyksta procesuose nuo pradžios iki pabaigos. Modeliavimas leidžia gauti „išorės“ vaizdą apie procesus ir nustatyti patobulinimus, kurie padidins jų efektyvumą.
• antra, procesų normavimas. Verslo procesų modeliavimas nustato procesų vykdymo taisykles, t.y. kaip jie turėtų būti daromi. Jei laikomasi modeliuose nustatytų taisyklių, gairių ar reikalavimų, tuomet galima pasiekti norimą procesų našumą.
• trečia, tarpusavio santykių užmezgimas procesuose. Verslo procesų modeliavimas nustato aiškų ryšį tarp procesų ir reikalavimų, kuriuos jie turi atitikti.

Verslo procesų modeliavimo etapai

Verslo procesų modeliavimas, kaip taisyklė, apima kelių nuoseklių etapų įgyvendinimą. Nes galutinis modeliavimo tikslas – tobulinti procesus, jis apima tiek „projektavimo“ darbo dalį, tiek procesų modelių diegimo darbus.

Etapų, apimančių verslo procesų modeliavimą, sudėtis yra tokia:

• procesų nustatymas ir pradinio modelio kūrimas „toks, koks yra“. Norint patobulinti procesą, būtina suprasti, kaip jis veikia šiuo metu. Šiame etape apibrėžiamos proceso ribos, nustatomi pagrindiniai jo elementai, renkami duomenys apie proceso veikimą. Dėl to sukuriamas pradinis proceso modelis „toks, koks yra“. Šis modelis ne visada adekvačiai atspindi proceso veikimą, todėl šio etapo modelį galima vadinti „pirmuoju juodraščiu“ arba pradiniu „kaip yra“ modeliu.
• pradinio modelio peržiūra, analizė ir tobulinimas. Šiame etape nustatomi proceso prieštaravimai ir veiksmų dubliavimasis, nustatomi proceso apribojimai, proceso santykis, poreikis keisti procesą. Dėl to susidaro galutinė modelio versija „toks, koks yra“.
• modelio „kaip turėtų būti“ kūrimas. Išanalizavus esamą situaciją, būtina nustatyti pageidaujamą proceso būseną. Ši norima būsena pavaizduota „kaip turėtų būti“ modelyje. Toks modelis parodo, kaip procesas turėtų atrodyti ateityje, įskaitant visus būtinus patobulinimus. Šiame verslo procesų modeliavimo etape tokie modeliai kuriami.
• modelio „kaip turi būti“ testavimas ir pritaikymas. Šis modeliavimo etapas siejamas su sukurto modelio įdiegimu į organizacijos praktiką. Verslo proceso modelis išbandomas ir jame atliekami būtini pakeitimai.
• tobulinti modelį „kaip ir turi būti“.. Verslo procesų modeliavimas neapsiriboja modelio „kaip turėtų būti“ sukūrimu. Kiekvienas iš procesų nuolat keičiasi ir tobulėja, todėl procesų modeliai turėtų būti reguliariai peržiūrimi ir tobulinami. Šis modeliavimo etapas siejamas su nuolatiniu procesų tobulėjimu ir verslo procesų modelio tobulėjimu.

Verslo procesų modeliavimo rūšys

Verslo procesų modeliavimas gali skirtis. Tai priklauso nuo to, kokias problemas jis turėtų išspręsti su jo pagalba. Atsižvelgus į absoliučiai visas proceso įtakas, modelis gali labai apsunkinti ir proceso aprašymas gali būti perteklinis. Siekiant to išvengti, verslo procesų modeliavimas skirstomas pagal tipą. Modeliavimo tipas parenkamas atsižvelgiant į tiriamo proceso ypatybes.

Proceso tobulinimo tikslais naudojami šie modeliavimo tipai:

• funkcinis modeliavimas. Šio tipo modeliavimas reiškia procesų aprašymą tarpusavyje susijusių, aiškiai struktūrizuotų funkcijų forma. Tuo pačiu metu nėra būtina griežta laikinoji funkcijų seka, tokia, kokia ji egzistuoja realiuose procesuose.
• Objektų modeliavimas– reiškia procesų, kaip sąveikaujančių objektų visumos, aprašymą – t.y. gamybos padalinių. Objektas yra bet koks objektas, kuris transformuojamas vykdant procesus.
• Modeliavimas- naudojant šio tipo verslo procesų modeliavimą, siekiama modeliuoti procesų elgesį įvairiomis išorinėmis ir vidinėmis sąlygomis, analizuojant procesų dinamines charakteristikas ir išteklių paskirstymo analizę.

Modeliavimo skirstymas pagal tipus atliekamas siekiant supaprastinti darbą ir sutelkti dėmesį į tam tikras proceso charakteristikas. Tokiu atveju galima taikyti tą patį procesą Skirtingos rūšys modeliavimas. Tai leidžia dirbti su vieno tipo modeliais nepriklausomai nuo kitų.

Verslo procesų modeliavimo principai

Verslo procesų modeliavimas remiasi keletu principų, leidžiančių sukurti tinkamus procesų modelius. Jų laikymasis leidžia aprašyti proceso būsenos parametrų rinkinį taip, kad viename modelyje komponentai būtų glaudžiai tarpusavyje susiję, o atskiri modeliai liktų pakankamai nepriklausomi vienas nuo kito.

Pagrindiniai verslo procesų modeliavimo principai yra šie:

• Skilimo principas– kiekvienas procesas gali būti pavaizduotas hierarchiškai išdėstytų elementų rinkiniu. Pagal šį principą procesas turi būti suskirstytas į jo sudedamąsias dalis.
• Fokusavimo principas– norint sukurti modelį, būtina abstrahuotis nuo daugelio proceso parametrų ir sutelkti dėmesį į pagrindinius aspektus. Kiekvienam modeliui šie aspektai gali skirtis.
• Dokumentacijos principas– į procesą įtraukti elementai turi būti formalizuoti ir fiksuoti modelyje. Skirtingiems proceso elementams turi būti naudojami skirtingi pavadinimai. Elementų tvirtinimas modelyje priklauso nuo modeliavimo tipo ir pasirinktų metodų.
• Nuoseklumo principas- visi į proceso modelį įtraukti elementai turi turėti nedviprasmišką interpretaciją ir neprieštarauti vienas kitam.
• Išbaigtumo ir pakankamumo principas- prieš įtraukiant vieną ar kitą elementą į modelį, būtina įvertinti jo poveikį procesui. Jei elementas nėra būtinas procesui vykdyti, tada jo įtraukti į modelį nepatartina, nes tai gali tik apsunkinti verslo proceso modelį.

Verslo procesų modeliavimo metodai

Šiandien yra gana daug verslo procesų modeliavimo metodų. Šie metodai priklauso skirtingiems modeliavimo tipams ir leidžia sutelkti dėmesį į skirtingus aspektus. Juose yra ir grafinių, ir tekstinių įrankių, per kuriuos galite vizualizuoti pagrindinius proceso komponentus ir pateikti tikslius parametrų ir elementų ryšių apibrėžimus.

Verslo procesų modeliavimas atliekamas šiais metodais:

• Flow Chart Diagram (darbo eigos diagrama) yra grafinis proceso vaizdavimo būdas, kuriame operacijos, duomenys, proceso įranga ir kt. vaizduojami specialiais simboliais. Metodas naudojamas loginei proceso veiksmų sekai atvaizduoti. Pagrindinis metodo privalumas yra jo lankstumas. Procesą galima pavaizduoti įvairiais būdais.
• Duomenų srauto diagrama (duomenų srauto diagrama). Duomenų srauto diagrama arba DFD naudojama norint parodyti informacijos (duomenų) perdavimą iš vienos proceso operacijos į kitą. DFD aprašo operacijų ryšį per informaciją ir duomenis. Šis metodas yra struktūrinės procesų analizės pagrindas, nes leidžia suskaidyti procesą į loginius lygius. Kiekvienas procesas gali būti suskirstytas į smulkesnius procesus. DFD naudojimas leidžia atspindėti tik informacijos srautą, bet ne medžiagų srautą. Duomenų srauto diagrama parodo, kaip informacija patenka į procesą ir iš jo išeina, kokie veiksmai keičia informaciją, kur informacija saugoma procese ir pan.
• Vaidmenų veiklos diagrama (vaidmenų diagrama). Jis naudojamas procesui modeliuoti pagal atskirus vaidmenis, vaidmenų grupes ir vaidmenų sąveiką procese. Vaidmuo yra abstraktus proceso elementas, atliekantis organizacinę funkciją. Vaidmenų diagrama parodo „atsakomybės“ už procesą ir jo operacijas laipsnį bei vaidmenų sąveiką.
• IDEF (Integrated Definition for Function Modeling) – tai visas metodų rinkinys, skirtas įvairiems verslo procesų aspektams apibūdinti (IDEF0, IDEF1, IDEF1X, IDEF2, IDEF3, IDEF4, IDEF5). Šie metodai yra pagrįsti SADT (Structured Analysis and Design Technique) metodika. Verslo procesams modeliuoti dažniausiai naudojami IDEF0 ir IDEF3 metodai.
• IDEF0 – leidžia sukurti proceso funkcijos modelį. IDEF0 diagramoje pavaizduotos pagrindinės proceso funkcijos, įėjimai, išėjimai, valdymo veiksmai ir įrenginiai, susiję su pagrindinėmis funkcijomis. Procesas gali būti suskaidytas į žemesnį lygį.
• IDEF3 – šis metodas leidžia sukurti „elgesio“ proceso modelį. IDEF3 sudaro dviejų tipų modeliai. Pirmajame rodinyje pateikiamas darbo eigos aprašymas. Antrasis – objektų pereinamųjų būsenų aprašymas.
• Spalvoti Petri tinklai- šis metodas atvaizduoja proceso modelį grafiko pavidalu, kur viršūnės yra proceso veiksmai, o lankai – įvykiai, dėl kurių procesas pereina iš vienos būsenos į kitą. Petri tinklai naudojami dinamiškai modeliuoti proceso elgesį.
• Unified Modeling Language (UML) – tai į objektą orientuotas procesų modeliavimo metodas. Jį sudaro 9 skirtingos diagramos, kurių kiekviena leidžia modeliuoti skirtingus statinius arba dinaminius proceso aspektus.

Dauguma šių metodų yra įdiegti programinėje įrangoje. Tai leidžia palaikyti verslo procesus arba juos analizuoti. Tokios programinės įrangos pavyzdžiai yra įvairūs CASE procesų modeliavimo įrankiai.