Straipsniai apie verslo procesų valdymą


Norime pasidžiaugti, kad Lietuvos verslo procesų valdymo profesionalų patirtis vertinama pasauliniu mastu. Pagal VPVP 2010 konferencijos dalyvių geriausiai įvertintą pranešimą parengtas straipsnis „Refactoring BPMN Models“ kuris publikuotas leidinyje „BPMN 2.0 Handbook“. Šis pranešimas taip pat atrinktas į programą prestižinėse verslo procesų valdymo konferencijose Europoje ir JAV: „BPM Europe 2011“, „Business Analysis 2011” bei „Business Process Forum 2011“. Visose paminėtose konferencijose  sulaukėme puikių įvertinimų.


Mes tikime, kad lietuviškoji VPVP konferencija ne tik prisidėda prie Lietuvos verslo procesų valdymo profesionalų bendruomenės augimo tiek kokybiniu, tiek kiekybiniu požiūriu, bet daro įtaką ir tarptautinėje bendruomenėje. 

Malonaus skaitymo.

 

 

 

Verslo procesų modelių tobulinimas: anti-pavyzdžių pertvarkymas pritaikant gerąsias praktikas

Dr. Darius Šilingas ir Edita Milevičienė, No Magic Europe

 

Įvadas

 

Verslo procesų modeliavimo kalba BPMN (Business Process Model and Notation) yra pakankamai jaunas, tačiau jau labai plačiai naudojamas standartas verslo procesų aprašymui. Šiuo metu tai yra populiariausia kalba, skirta verslo procesams aprašyti. Tačiau nepaisant to, kad modeliavimo kalba yra labai paplitusi, vis dar trūksta rekomendacijų, kaip pasirinkti tinkamą procesų struktūrą, kokį vardų stilių pasirinkti, kaip pateikti išsamų ir tuo pačiu gerai suprantamą procesų vizualizavimą ir aprašymą. BPMN kalbos elementai bei jų simboliai yra aprašyti BPMN specifikacijos dokumente [1]. Kalbos naudojimo pavyzdžiai pateikti standartą papildančiame dokumente [2]. Taip pat yra ir knygų [3,4], pateikiančių pavyzdžius, kaip tinkamai naudoti BPMN elementus, kokį modeliavimo stilių pasirinkti. Tačiau nepaisant viso šito, dauguma veiklos procesus modeliuojančių žmonių daro tipines klaidas, dėl kurių jų sukurti veiklos procesų aprašymai yra labai sudėtingi, juos sunku suprasti bei atnaujinti.

 

Visi žinome, jog geriau mokytis iš svetimų klaidų nei iš savų – tad šiame straipsnyje aptarsime dažniausiai sutinkamas modeliavimo klaidas ir parodysime, kaip galima jų išvengti. Daugumą šių klaidų veiklos procesų aprašyme nesunkiai galima pastebėti patiems arba surasti naudojant automatizuotus įrankius. Paprastai tokios klaidos yra taisomos pertvarkant procesų modelį. Pertvarkant modelį galima pasinaudoti gerosiomis modeliavimo praktikomis ir procesų modeliavimo šablonais, kurie pasako, kaip geriausiai aprašyti tipines situacijas. Pagrindiniai verslo procesų modeliavimo šablonai yra aprašyti [6]. Deja, šie šablonų aprašymai verslo procesus modeliuojantiems žmonėms atrodo pernelyg abstraktūs, neaišku, kaip šiuos šablonus taikyti praktikoje. Modeliuotojams daug geriau suprantami realūs pavyzdžiai. Ypač efektyvus mokymo būdas yra pateikti realius pavyzdžius su identifikuotomis dažnai pasitaikančiomis klaidomis bei paaiškinimais, kokios gerosios praktikos ar šablonai gali būti pritaikyti šioje konkrečioje situacijoje, kaip būtų galima ištaisyti modelį.

 

Šiame straipsnyje pateiksime 5 praktinius verslo procesų modelių pavyzdžius su identifikuotomis klaidomis bei patarimais, kaip patobulinti modelius. Pateikiami pavyzdžiai atspindi realius modelius, su kuriais straipsnio autoriai dirbo konsultuodami įvairių valstybių organizacijas iš bankininkystės, telekomunikacijų, gynybos bei programinės įrangos kūrimo sektorių. Pavyzdžiai iliustruoti BPMN diagramomis – originaliomis, kuriose yra modeliavimo klaidų, bei pertvarkytomis pagal gerųjųjų praktikų patarimus ir modeliavimo šablonus. Pateikiami analizės lygio verslo procesų pavyzdžiai be techninių detalių, reikalingų procesų automatizavimui. Siekiant išlaikyti paprastumą, pavyzdžiuose naudojame nedidelį BPMN elementų poaibį: užduotis, subprocesas, sąlyginis bei įvykių išsišakojimo taškai, pradžios ir pabaigos įvykiai, tarpiniai laiko ir pranešimo laukimo įvykiai bei duomenų objektas. Tokio elementų kiekio pakanka norint identifikuoti dažniausiai pasitaikančias klaidas bei pademonstruoti jų sprendimo būdus.

 

BPMN 2.0 kalba pateikia daugiau nei 100 grafinių elementų, skirtų procesams aprašyti. Pradedant modeliuoti verslo procesus tikrai nereikia stengtis išmokti jų visų. 1 paveiksle matome mūsų apibrėžtą minimalų BPMN elementų poaibį. Kiek teko pastebėti praktikoje, tokio kiekio elementų pakanka aprašyti daugumai verslo procesų. Procesų diagramas su minimaliu elementų poaibiu galima išmokti braižyti per vieną dieną.

 

Minimalus BPMN_elementu poaibis.PNG

Paveikslas 1.    Verslo procesų diagrama su minimaliu BPMN elementų poaibiu

 

 

1 klaida. Netikslūs pavadinimai

Modeliuojant verslo procesus labai svarbu yra teisingai parinkti modelio elementų vardus. Labai dažnai pasitaiko, jog modeliuotojai veikloms įvardinti naudoja daiktavardžius (ypač populiarūs žodžiai – valdymas, tvarkymas, koordinavimas). Taip pat dažnai modelyje nėra išlaikomas vientisumas, ir to paties tipo elementai skirtingose vietose yra vadinami naudojant skirtingą stilių. Lietuvių filosofas Vydūnas kažkada yra pasakęs, jog kalba formuoja mūsų mąstymą. Šis posakis puikiai tinka ir kalbant apie verslo procesų modeliavimą – dažnai modeliuotojai neteisingai naudoja BPMN elementus, o tai atsispindi elementų varduose. Paprastai nevieningas elementų vardų stilius rodo, kad aprašydami verslo procesus BPMN kalba, nežinome, kokius elementus ir kaip reikia naudoti. Žemiau pateiktoje lentelėje pateikiame keletą tipinių neteisingo vardų parinkimo pavyzdžių, ir gerųjų praktikų patarimais paremtų paaiškinimų, kokius vardus reikėtų naudoti šiose situacijose.

 

1 lentelė. Tipinės vardų parinkimo klaidos ir gerųjų praktikų patarimai

 

Tipinės klaidos Gerosios praktikos
Veiklos pavadinimas yra daiktavardisrodo, kad šioje vietoje turėtų būti naudojamas kitas elementas (pvz. įvykis ar duomenų objektas), o ne veikla. Veiksmažodžio bendratis + daiktavardispabrėžia, kad atlikus nurodytą darbą bus pasiektas tam tikras rezultatas.
Išsišakojimo taškas pavadintas kaip veiklarodo, kad išsišakojimo taškas vaizduoja ir užduotį, apsprendžiančią kuria šaka eiti toliau. Išsišakojimo taškas be pavadinimoišsišakojimo taškas yra elementas, kuris neatlieka jokio darbo, tad jis turėtų būti be pavadinimo (nebent pavadinimas reikalingas elemento identifikavimui)
Žodžiai „Ir“, „Arba“ veiklos pavadinimerodo, kad vienas veiksmas naudojamas vietoje keleto veiksmų. Pavadinimai be jungiamųjų žodeliųišvengti jungiamųjų žodelių padeda abstraktesni pavadinimai arba veiklos išskaidymas į kelias vieną po kitos einančias arba lygiagrečiai vykdomas veiklas.
Ilgas veiklos vardasrodo kad vietoje veiklos tikslo yra pabrėžiamos detalės. Diagrama tampa panaši į tekstinį dokumentą. Trumpas vardas + dokumentacijaveiklos vardas turi pabrėžti norimą pasiekti  tikslą. Detalesnė informacija apie veiklą gali būti pateikta dokumentacijoje.

 

Patyrusiems verslo procesų modeliuotojams gali atrodyti, jog parinkti tikslius elementų vardus yra labai paprasta. Tačiau konsultuodami įvairias įmones pastebime, jog beveik visos organizacijos, pradėjusios verslo procesus modeliuoti BPMN kalba, susiduria su vardų parinkimo problema. Netgi pačiame BPMN standarto dokumente [1] ir jį lydinčiuose pavyzdžių dokumentuose [2] galima rasti netikslių elementų pavadinimų. 2 paveiksle pateikiame procesų diagramą su klaidomis, išvardintomis 1 lentelėje, ir pagal gerųjųjų praktikų patarimus pertvarkytą tą pačią diagramą.

 

BPMN_Process_Diagram__Pateikti_paskolos_pasiūlym�_blogi_vardai__Pateikti_paskolos_pasiūlym�_blogi_vardai.png BPMN_Process_Diagram__Pateikti_paskolos_pasiūlym�__Pateikti_paskolos_pasiūlym�.png

 

Paveikslas 2.     Verslo proceso „Priimti paskolos paraišką“ su elementų įvardinimo klaidomis ir pagal gerąsias praktikas/šablonus pataisyta diagramos versija

 

Čia aprašėme tik keletą dažniausiai pasitaikančių pavadinimų parinkimo klaidų. Modeliuodami verslo procesus, tikriausiai susidursite su panašiomis problemomis parinkdami įvykių, duomenų objektų, verslo dalyvių, pranešimų ir kitų elementų vardus. Kiekvienai organizacijai, pradedančiai verslo procesus modeliuoti BPMN kalba, mes patariame pasitvirtinti elementų įvardinimo taisykles ir periodiškai atlikti modelių peržiūras, siekiant užtikrinti šių taisyklių taikymą. Tokios prevencinės priemonės padeda sumažinti neteisingai parinktų vardų kiekį. BPMN modeliavimo įrankiai dažniausiai nepajėgūs automatiškai identifikuoti netikslių vardų modelyje, kadangi tam reikalinga sudėtinga lingvistinė analizė. Nebent kai kurios tipinės klaidos (pvz. per ilgi vardai) gali būti surandamos automatiškai.

 

 

2 klaida. Sudėtingos procesų diagramos

 

Antra labai svarbi tema, kurią verta aptarti šnekant apie verslo procesų modeliavimą, yra procesų diagramų sudėtingumas. Nors BPMN kalba leidžia modeliuoti procesus keliais detalumo lygiais, modeliuotojai labai dažnai nori viską sutalpinti į vieną lapą. Turint tokias dideles „viskas viename“ diagramas yra sunku pamatyti proceso esmę, skaityti ir suprasti diagramos elementus. Psichologai yra nustatę, kad žmogus geriausiai sugeba sukoncentruoti dėmesį, kada diagramoje pavaizduoti 5±2 elementai. Praktikoje šią taisyklę yra sunku įgyvendinti, todėl mūsų nuomone šį skaičių galima padidinti iki maždaug 7±4. Tokio dydžio diagramos gali puikiai atspindėti proceso esmę, ir kartu yra pakankamai kompaktiškos ir neperkrautos. Realiame gyvenime konsultuodami įvairias organizacijas matome, kad sudėtingos diagramos yra kuriamos dažnai – yra tekę matyti netgi tokių atvejų, kad procesų diagrama turėjo 450(!) užduočių. Tokias diagramas yra sunku perskaityti ir analizuoti, tad netenkame daugumos privalumų, kuriuos grafinė diagrama turi lyginant su tekstiniu aprašymu.

 

4 paveiksle matome didelės diagramos pavyzdį. Ši diagrama yra nubraižyta nekorektiškai, pavyzdžiui, trūksta veiklai „Atšaukti seminarą“simetriškos veiklos „Patvirtinti seminarą“, vaizduojamas niekada nesibaigiantis dalyvių registravimo ciklas po sprendimo apie seminaro vykdymą priėmimo, skirtingais detalumo lygiais aprašyta registracija į seminarą (pirmos keturios užduotys) bei seminaro atšaukimas (vienas sutrauktas subprocesas), nėra aiškaus atskyrimo tarp ankstyvosios ir vėlyvosios registracijos ir t.t. Šias ir panašias problemas yra sunku pastebėti analizuojant didelę ir sudėtingą procesų diagramą – juk vien tam, kad suprastum, kas ten pavaizduota, reikia įdėti nemažai pastangų. Naudojant modeliavimo įrankį, pernelys sudėtingas diagramas identifikuoti gana paprasta: tereikia automatiškai atrinkti diagramas, kuriose veiklų kiekis viršija nustatytą skaičių (tarkim 10). 3 paveiksle pateikiame pertvarkytą diagramą: diagrama turi kelis detalumo lygius. Pirmojoje diagramoje subprocesai pateikia abstraktesnį proceso vaizdą. Subprocesų detalės pateiktos jiems priskirtose diagramose.

BPMN_Process_Diagram__Suorganizuoti_seminar�__Suorganizuoti_seminar�.png BPMN_Process_Diagram__Paskelbti_seminar�__Paskelbti_seminar�.png

 

Paveikslas 3.    Pertvarkyta verslo proceso „Suorganizuoti seminarą“ diagrama su 7 subprocesais. Subproceso „Paskelbti seminarą“ detalės pateiktos atskiroje diagramoje

 

Vadovaujantis šiuo principu, netgi labai sudėtingus ir didelės apimties procesus aprašyti kaip paprastus procesus, susidedančius iš keleto detalumo lygių. Kaip pavyzdį galime pasakyti, jog vienas trimis detalumo lygiais aprašytas procesas, laikantis taisyklės, kad vienoje diagramoje vaizduojame iki 10 veiklų, gali turėti iki 103 = 1000 užduočių.

 

BPMN_Process_Diagram__Suorganizuoti_seminar�_didele__Suorganizuoti_seminar�_didele.png

 

Paveikslas 4.    Originali verslo proceso „Suorganizuoti seminarą“ nekorektiška diagrama su 16 veiklų

 

 

3 klaida. Nenuoseklus išsišakojimo taškų naudojimas


Išsišakojimo taškai verslo procesų modeliavime atlieka labai svarbų vaidmenį – jie apibrėžia verslo proceso tėkmę esant tam tikroms sąlygoms arba įvykus nurodytiems įvykiams. Išsišakojimo taškai taip pat naudojami sujungti subproceso pabaigos įvykius su kitais tėvinio proceso elementais. Praktikoje tenka matyti, jog išsišakojimo taškai diagramose yra naudojami labai įvairiai. Labai dažnai diagramoje išsišakojimo taškai yra praleidžiami, vietoje jų parodant kelis iš veiklos išeinančius (įeinančius) sekos ryšius. Toks modeliavimo būdas apsunkina diagramos skaitymą ir palieka vietos laisvam diagramos interpretavimui. Taip pat dažnai tenka matyti ant išsišakojimo taško užrašytą klausimą, ir sąlygas „Taip“ ir „Ne“ ant išeinančių sekos ryšių. Mūsų nuomone toks pavadinimų priskyrimas yra vengtinas, nes modeliuojant subprocesus tampa neįmanoma tiksliai ir nedviprasmiškai susieti prieš išsišakojimo tašką pavaizduoto subproceso pabaigos įvykių su sąlygomis užrašytomis ant sekos ryšių („Taip“ ir „Ne“ tikrai nėra tinkami subproceso pabaigos įvykio vardai). Konsultuodami klientus dažnai pastebime, jog modeliuotojai nežino, kaip reiktų naudoti įvykių laukimo išsišakojimo taškus. Čia jiems pagelbėtų tipinių situacijų modeliavimo šablonai. 3 lentelėje mes pateikėme tris dažniausiai pasitaikančias situacijas, kurios sukelia problemų modeliuojant išsišakojimo taškus. Taip pat pateikėme gerųjų praktikų patarimus bei šablonus, kurie nusako, kaip galima tinkamai panaudoti išsišakojimo taškus. 5 paveiksle yra pateiktas verslo proceso diagramos fragmentas su keliomis tipinėmis išsišakojimo taškų naudojimo klaidomis ir pasiūlytas pertvarkytas diagramos variantas.

 

2 lentelė. Tipinės klaidos modeliuojant išsišakojimo taškus ir gerųjų praktikų patarimai.

 

Tipinės klaidos Gerosios praktikos
Į veiklą ateina/išeina keletas sekos ryšių –sunku suprasti, kiek ryšių turi įeiti, kad veikla būtų pradėta vykdyti, ir kiek sekų turi būti aktyvuota pasibaigus veiklai. Visada proceso sekos iššakojimui/apjungimui naudoti išsišakojimo taškus – diagramą su išsišakojimo taškais lengviau skaityti, aiškiai matosi sprendimo priėmimo bei sekos išskaidymo/apjungimo vietos.
Iš įvykių laukimo išsišakojimo taško išeinantis sekos ryšys eina ne į įvykį – dviprasmiška situacija, kadangi neaišku kuomet reikia eiti tuo keliu. Pritaikyti atidėto laukimo (Deferred Choice) šabloną – visi sekos ryšiai išeinantys iš įvykių laukimo išsišakojimo tašku privalo būti prijungti prie įvykių. Jei norima pavaizduoti, kad laukiamas įvykis gali ir neįvykti – laukimo periodui nustatyti naudojamas
Išsišakojimo taško sąlygos nesusinchronizuotos su prieš jį einančio subproceso pabaigomis – detali subproceso diagrama nesuderinta su didesniu procesu. Neaišku kaip turi vykti procesas pasiekus pabaigą, kurios nėra stambesniame proceso aprašyme. Pritaikyti vidinės verslo klaidos (Internal Business Error) šabloną, susinchronizuojant pabaigas su sprendimo taško sąlygomis – tinkamai naudojamas išsišakojimo taškas padeda užtikrinti, kad procesas yra aprašytas korektiškai.

 

BPMN_Process_Diagram__Parduoti_licenzijas_klaidinga__Parduoti_licenzijas_klaidinga.png BPMN_Process_Diagram__Parduoti_licenzijas__Parduoti_licenzijas.png

 

Paveikslas 5.    Verslo proceso „Parduoti programinės įrangos licenzijas“ nekorektiškos diagramos fragmentas ir diagrama, gauta pertvarkius procesą, panaudojant šablonus ir gerųjų praktikų patarimus.

 

 

4 klaida. Nenuoseklus įvykių naudojimas


Modeliuojant verslo procesus įvykių modeliavimui reikia skirti ypatingą dėmesį. Įvykiai verslo procesų diagramose vaidina labai svarbų vaidmenį – kiekvienas procesas prasideda pradžios įvykiu, pasibaigia vienu ar daugiau pabaigos įvykių, reaguoja į tarpinius įvykius, kurie įvyksta proceso vykdymo metu. Nuspręsti, kokį įvykį reikia naudoti vienoje ar kitoje situacijoje, nėra sudėtinga. Daug sudėtingiau nuspręsti kokiame proceso lygyje įdėti procesą inicijuojantį įvykį, arba kokiame lygyje modeliuoti tarpinius įvykius. 3 lentelėje mes pateikėme dvi dažniausiai pasitaikančias įvykių modeliavimo klaidas ir siūlomus sprendimus, kaip šių klaidų galima būtų išvengti. 6 paveiksle pateikiame verslo procesų diagramos fragmentą su neteisingai panaudotais įvykiais, bei ištaisytą diagramos variantą. Modeliuojant verslo procesus programinės įrangos įrankio pagalba, netikslus įvykių naudojimas gali būti identifikuojamas automatiškai.

 

3 lentelė. Tipinės klaidos modeliuojant įvykius ir gerųjų praktikų patarimai.

 

Tipinės klaidos Gerosios praktikos
Įvykis naudojamas ir subproceso viduje, ir išorėje – įvykių kartojimas yra perteklinis. Skaitant diagramą formaliai, įvykis turėtų įvykti du kartus. Inicijuojantis įvykis nerodomas subproceso viduje, vaizduojamas išorinėje diagramoje – diagramą lengviau skaityti ir suprasti, kai matome, kodėl reikia vykdyti vieną ar kitą subprocesą.
Pasikartojančių įvykių modeliavimas – apsunkina diagramos skaitymą ir palaikymą. Įvykis piešiamas ant subproceso  –diagramoje aiškiai matyti, kada gali įvykti įvykis.

 

BPMN_Process_Diagram__Administruoti_pradelst�_paskol�_klaidinga__Administruoti_pradelst�_paskol�_klaidinga.png BPMN_Process_Diagram__Administruoti_pradelst�_paskol�__Administruoti_pradelst�_paskol�.png

 

Paveikslas 6.    Verslo proceso „Administruoti pradelstą paskolą“ nekorektiškos diagramos fragmentas ir diagrama, gauta pertvarkius procesą panaudojant šablonus.

 


5 klaida. Prastas diagramos elementų išdėstymas


Paskutinė klaida, kurią aptarsime šiame straipsnyje, yra elementų išdėstymas BPMN diagramose. Nors šią klaidą aptariame paskutinę, tačiau ji yra labai svarbi -  elementų išdėstymo klaidos yra daromos labai dažnai. Diagramose to paties tipo elementai vaizduojami skirtingo dydžio ikonomis, piešiama daug ilgų, lenktų, besikertančių linijų, tarp modelio elementų paliekami skirtingo dydžio tarpai. Visos šios klaidos nekeičia diagramos turinio, tačiau blogai išdėstytas BPMN diagramas yra sunkiau skaityti ir suprasti.



Yra apibrėžta daug gerųjų praktikų patarimų kaip nubraižyti suprantamas UML veiklos diagramas [8] - daugumą šių patarimų galima pritaikyti verslo procesų diagramoms. 7 diagramoje matome tipinį verslo procesų diagramos pavyzdį, kuriame elementai yra išdėstyti nesilaikant gerųjų praktikų patarimų. Pertvarkytą to paties procesų diagramą mes jau matėme – ji pateikta 3 paveiksle. Viena iš svarbiausių klaidų, kurią matome 7 paveiksle, vadinama „slalomu“ – diagramoje nėra aiškios skaitymo krypties, nėra aiškiai išskiriami pagrindinis ir alternatyvūs scenarijai.



Vakarų kultūroje yra priimta, kad veiksmų seka turi būti braižoma arba iš viršaus į apačią, arba iš kairės į dešinę (taip skaitoma rašytinė kalba). Mes rekomenduojame diagramas braižyti iš viršaus žemyn. Toks diagramos išdėstymo būdas leidžia efektyviau išnaudoti vietą: veiklų vardai yra rašomi iš kairės į dešinę, o sekos ryšiai yra brėžiami iš viršaus žemyn. Kita problema iškyla, kai modeliuotojas braižydamas diagramą bando iš karto identifikuoti visas proceso detales. Tuomet diagramoje susimaišo pagrindinis ir alternatyvūs scenarijai, neaišku, kaip procesas vyksta dažniausiai. Procesą aprašyti bus daug lengviau, jei aprašymą pradėsite iš viršaus žemyn nubraižydami pagrindinį scenarijų, ir po to į šonus iššakosite alternatyvius scenarijus.

Suorganizuoti seminar�_slalom.png


Paveikslas 7.    Verslo proceso „Suorganizuoti seminarą“ diagrama su prastu elementų išdėstymu: matome „slalomą“, skirtingo dydžio simbolius, skirtingus tarpus tarp elementų, lankstytas linijas. Pataisytą diagramą galite pamatyti 2 paveiksle.


Išvados


Straipsnyje išnagrinėjome penkis praktinius BPMN diagramų anti-pavyzdžių pertvarkymo atvejus, parodydami, kaip pasinaudojant gerųjų praktikų patarimais galima ištaisyti dažniausiai sutinkamas modeliavimo klaidas. Aptarėme, jog dažniausiai pasitaikančios modeliavimo klaidos yra neteisingai parinkti elementų vardai, per didelės diagramos, neteisingai naudojami išsišakojimo taškai, nevieningas įvykių naudojimas, bei prastas elementų išdėstymas diagramoje.



Mes manome, kad tokia anti-pavyzdžių bei gerųjų praktikų analize paremtas mokymasis yra efektyviausias būdas susipažinti su verslo procesų modeliavimo šablonais ir gerosiomis modeliavimo praktikomis. Tikimės, kad šis straipsnis padės kelti verslo procesų modeliavimo kultūrą Lietuvoje. Norime atkreipti dėmesį, kad straipsnyje nėra surinktos visos verslo procesų modeliavimo klaidos, šablonai, bei gerosios praktikos – tačiau tikimės, kad straipsnis inicijuos gerųjų praktikų, skirtų verslo procesų aprašymui, specifikavimą ir paskatins kitus pasidalinti savo patirtimi.

 

Literatūra:

  1. OMG. Business Process Model and Notation (BPMN), v2.0 beta2, 2010. http://www.omg.org/cgi-­bin/doc?dtc/10-­06-­04.pdf
  2. OMG. BPMN 2.0 by Example, v. 1.0, 2010. http://www.omg.org/spec/BPMN/2.0/examples/pdf
  3. Bruce Silver. BPMN Method and Style: A levels-­based methodology for BPM process modeling and improvement using BPMN 2.0. Cody-Cassidy Press, 2009, ISBN-­10: 0982368100.
  4. Stephen A. White, Derek Miers. BPMN Modeling and Reference Guide: Understanding and Using BPMN. Future Strategies Inc., 2009, ISBN-10: 0977752720
  5. Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts. Refactoring: Improving the Design of Existing Code. Addison Wesley, 1999 ISBN­10: 0201485672
  6. Stephen A. White. Process Modeling Notations and Workflow Patterns, IBM, 2004 http://www.bpmn.org/Documents/Notations_and_Workflow_Patterns.pdf
  7. R. Laue and A. Awad. Visualization of business process modeling anti patterns. In VFfP, 2009.
  8. Scott W. Ambler. The Elements of UMLTM 2.0 Style. Cambridge University Press, 2005.

 

 


Verslo procesų valdymas: kas tai, kodėl ir kaip?

 

Dr. Darius Šilingas, No Magic Europe

Airidas Laugalis, Sprendimų idėjos

 

Įvairiuose informacijos šaltiniuose publikuojami pastebėjimai, kad Lietuvos organizacijos, lyginant su užsienio organizacijomis, dirba neefektyviai. Tai parodo ir pagrindiniai ekonominiai rodikliai – vidutiniškai vieno darbingo žmogaus per vieną darbo valandą generuojamas bendras vidaus produktas Lietuvoje yra žemiausias tarp visų(!) Europos Sąjungos narių. Šis pastebėjimas ypač aktualus dabartinio ekonomikos nuosmukio metu, kada daugybė organizacijų stengiasi restruktūrizuoti savo veiklą ir išgyventi krizės laikotarpį. Dauguma tiek valstybiniame, tiek komerciniame sektoriuje taikomų restruktūrizavimo būdų – darbuotojų atleidimai, algų mažinimas, investicijų stabdymas – leidžia pasiekti tik trumpalaikį teigiamą efektą, bet dažnai turi ilgalaikes negatyvias pasekmes. Nemažą dalį organizacijų tokios krizės paskatina iš esmės peržiūrėti savo veiklą, aiškiai įvardinti tikslus bei nustatyti, kaip juos pasiekti su sumažėjusiais resursais. Pasaulinėje organizacijų vadybos praktikoje didesnio našumo dažnai pasiekiama taikant verslo procesų valdymą, kurio suvokimas ir taikymas Lietuvoje dar nėra brandus. Tokią vadybos praktiką tik pradeda taikyti stambios, dažniausiai užsienio investuotojų valdomos organizacijos: bankai, telekomunikacijų įmonės, stambūs statybos darbų rangovai, gamybos organizacijos. Tačiau verslo procesų valdymas neabejotinai svarbus ir smulkioms bei vidutinio dydžio organizacijoms. Šiame straipsnyje supažindinsime su šios vadybos praktikos principais, aptarsime, kodėl ji padeda pasiekti didesnio našumo, bei patarsime, kaip ją įgyvendinti Lietuvos verslo organizacijose.

 

Kiekviena organizacija turi savo vidinę verslo architektūrą (žr. pav. 1), kurios svarbiausi elementai yra verslo motyvacijos modelis (vizija, misija, strategija, taktikos, tikslai) ir organizacijos vykdomi verslo procesai, naudojantys įvairius resursus: žmones, turtą, informacines sistemas. Būtent verslo procesai leidžia pasiekti tikslus, nustatytus verslo motyvacijos modelyje.

 

Paveikslas 1. Organizacijos architektūros modelis

image002.gif

 

 

Verslo procesas – susijusių veiksmų seka, kurianti vertę bei įgyvendinanti verslo tikslus.

Verslo procesų valdymasvadybos praktika, siekianti apibrėžti, reglamentuoti, analizuoti bei nuolatos tobulinti verslo procesus, siejant juos su organizacijos siekiamais tikslais.

 

Dažnoje organizacijoje nėra aiškaus supratimo, kokius verslo procesus ir kaip ji vykdo. Tai stipriai riboja organizacijos gebėjimus užtikrinti paslaugų ar gaminių kokybę, analizuoti procesų vykdymo rezultatus bei kaštus ir, remiantis analizės duomenimis, optimizuoti procesus, siekiant geresnių rezultatų. Verslo procesų valdymas siekia perorientuoti organizacijas nuo tradicinio funkcinio požiūrio („žmogui ieškoma darbo“) prie procesinio požiūrio („darbui ieškoma žmogaus“).

 

Nemažai organizacijų su verslo procesų valdymu susipažino diegdamos Lietuvoje populiarią ISO 9000 kokybės valdymo standartų sistemą. ISO 9000 sertifikavimui reikia tiksliai apibrėžti ir reglamentuoti pagrindinius organizacijos verslo procesus. Dauguma sertifikavimui besiruošiančių organizacijų aprašo verslo procesus, naudodamos tam nepritaikytus programinės įrangos įrankius – tekstinį redaktorių Microsoft Word, laisvos formos diagramų redaktorių Microsoft Visio, prezentacijų redaktorių Microsoft PowerPoint ar atitinkamas programas iš Open Office programinės įrangos paketo. Tokios veiklos rezultatas yra gana detalus dabartinių verslo procesų aprašymas. Tačiau kuriant ir diegiant būsimus verslo procesus, tokius aprašymus yra labai sudėtinga palaikyti, kadangi informacija yra netiksli, nestruktūrizuota, nėra semantinių informacijos ryšių. Todėl labai dažnai ši iniciatyva greitai numiršta – organizacijos pradeda dirbti kitaip, verslo procesų aprašymai lieka neatnaujinti, o gautas ISO 9000 sertifikatas naudojamas tik marketingo tikslams.

 

Siekiant įgyvendinti verslo procesų valdymą, reikėtų naudoti specializuotus  įrankius, tokius kaip verslo procesų valdymo aplinkos Aris, Lombardi, Tibco, Intalio, MagicDraw. Pastarasis įrankis kuriamas Lietuvoje, tačiau dauguma jo vartotojų – užsienio organizacijos (licenzijų parduota daugiau nei 70 šalių). Renkantis įrankį, labai svarbu pasirinkti tokį, kuris palaiko praktikoje taikomus standartus. Užsienio organizacijose de facto standartu jau laikoma sparčiai populiarėjanti verslo procesų modeliavimo kalba BPMN (Business Process Model and Notation), žr. pav. 2. BPMN suteikia galimybes specifikuoti procesų modelius, naudojant grafinį žymėjimą, kuris yra paprastas, tačiau vienareikšmis ir pakankamai tikslus – tinkamai paruoštus BPMN modelius galima automatiškai ar pusiau automatiškai transformuoti į informacinių sistemų servisus. BPMN modelį lengviau detalizuoti, analizuoti ir keisti. Todėl jis atveria galimybes tolesniems verslo procesų valdymo žingsniams: proceso vykdymo duomenų analizei, neefektyvių proceso vietų identifikavimui ir optimizavimui, naujų procesų modelių simuliavimui ir diegimui.

 

Paveikslas 2. BPMN kalba aprašytas verslo proceso „Vykdyti atvirą seminarą“ pavyzdys. Kiekvienas iš proceso žingsnių reprezentuoja atskirą procesą, kuris atvaizduojamas detalesne BPMN diagrama.

 

 

BPMN kalbą vysto organizacijų susivienijimas OMG (Object Management Group). OMG taip pat pasiūlė ir verslo procesų valdymo brandumo modelį, apibrėžiantį penkis brandumo lygius (pav. 3):

 

Pradinis, kuriame taikoma nenuosekli vadyba, paremta asmeninėmis darbuotojų savybėmis.

 

Valdomas, kuriame taikoma darbo vieneto vadyba, panaudojanti pasikartojančias praktikas ir jų pagrindu apibrėžianti skyrių ir darbuotojų kompetencijas, atsakomybes, darbo taisykles.

 

Standartizuotas, kuriame jau pradedama taikyti procesų vadyba, reikalaujanti apibrėžti ir reglamentuoti verslo procesus, siekiant kokybiškai teikti paslaugas ar gaminti produktus.

 

Nuspėjamas, kuriame atsiranda pajėgumų vadyba, naudojanti kiekinės vadybos praktikas – kaupiami ir analizuojami verslo procesų vykdymo duomenys, kurias remiantis galima prognozuoti ateities rezultatus, simuliuoti naujus modelius bei vertinti pokyčių įtaką.

 

Naujovių diegimas, kuriame vyksta pokyčių vadyba, taikanti nuolatinio gerinimo praktikas – verslo procesai yra reguliariai peržiūrimi ir keičiami, siekiant geresnių rezultatų.

 

 

Paveikslas 3. Verslo procesų valdymo brandumo modelis, pasiūlytas OMG organizacijos.

 

(c) 2009, Sprendimų idėjos, UAB 

 

Skirtinguose organizacijos gyvavimo etapuose reikalingas skirtingas verslo procesų brandumo lygis. Organizacijos gyvavimo pradžioje reikia dinamiškai ir lanksčiai reaguoti į verslo aplinką, todėl griežtai reglamentuoti verslo procesai gali ne tik nepadėti, bet netgi trukdyti. Tačiau augant organizacijai, turi augti ir verslo procesų valdymo brandumas. Jeigu plečiantis veiklai ir kolektyvui nėra reglamentuojami verslo procesai, organizacijos vadovai dažniausiai tampa „gaisrininkais“ – jie sprendžia dažnas darbuotojų problemas užuot susikoncentravę į organizacijos veiklos analizę ir optimizavimą. Dauguma organizacijų pereina šį etapą, kuriame įvyksta svarbus pokytis – subręsta poreikis verslo procesų valdymui dėka nepasitenkinimo esama situacija. Tai lūžio taškas, kuriame parodytą iniciatyvą galima paversti verslo procesų valdymo diegimo projektu. Rekomenduojamą tokio projekto vykdymo eigą apibūdina žemiau pateikta schema ir jos nurodytų žingsnių aprašymas.

 

Paveikslas 4. Verslo procesų valdymo diegimo projekto eigos schema.

 

 (c) 2009, Sprendimų idėjos, UAB

1.      Apibrėžti organizacijos strategiją: aiškiai suformuoti organizacijos verslo viziją, nustatyti ilgalaikius tikslus bei kaip jų planuojama siekti.

2.      Formuoti procesų architektūrą: nustatyti pagrindines veiklos sritis, verslo procesus bei darbuotojų pareigybes.

3.      Paruošti starto aikštelę: pasirinkti veiklos sritį, kurioje reikalingi pakeitimai, įvardinti siekiamus tikslus ir suformuoti pirmąjį verslo procesų valdymo diegimo projektą.

4.      Suprasti esamą būseną: išanalizuoti, kaip dirbama šiandien, identifikuoti kritines verslo procesų vietas, kuriose reikalingi pokyčiai.

5.      Kurti naujoves: įvardinti reikiamus pokyčius, kurie padės pasiekti užsibrėžtus tikslus.

6.      Pasiruošti diegimui: paruošti visas reikiamas priemones pokyčių įgyvendinimui.

7.      Dirbti su žmonėmis: supažindinti darbuotojus su artėjančiais pokyčiais, aiškiai perteikti, kokią vertę suteiks naujovės, bei užtikrinti jų palaikymą.

8.      Įdiegti naujoves: įgyvendinti numatytus pokyčius organizacijos veikloje.

9.      Realizuoti vertę: šis žingsnis tęsiamas ankstesniais projekto etapais, bet pabaigoje turi būti užakcentuojama, kokia vertė gauta.

10.  Išlaikyti patikimą funkcionavimą: projekto metu pasiekti rezultatai neturi suprastėti perėjus į kasdieninį režimą.

 

Kaip ir kiekvienam projektui, verslo procesų valdymo diegimui reikalinga pastovi projekto valdymo veikla, tačiau taip pat reikia užsitikrinti verslo procesų valdymo lyderystę organizacijoje bei daug dėmesio skirti žmonių pokyčių valdymui.

 

Žmonės, susitelkę bendram tikslui, tačiau nepaklūstantys gerai sudaryto proceso tvarkai nieko nepasieks … panašiai ir geriausiai sukurtas procesas neturi jokių galimybių išlikti, jeigu žmonės nesusitelkę tam procesui ir jo tikslams.Michael Hammer

 

Verslo procesų valdymas tai sudėtinė organizacijos vadybos dalis. Vadovams svarbu įsisąmoninti, kad nėra finišo linijos, tobulinant verslo procesus. Tai veikla, kuri vykdoma nuolat, ir kurios dėka pasiekiami organizacijos tikslai.

 

 

Užbaigiant straipsnį, norime akcentuoti šias pagrindines mintis:

 

  • Verslo procesų valdymas atveria galimybes sėkmingam organizacijų vystymui;
  • Verslo procesų modelis suteikia galimybes struktūriškai analizuoti ir optimizuoti veiklą;
  • Verslo procesų valdymo diegimo projektus būtina pritaikyti konkretiems įmonės tikslams įgyvendinti ir parodyti gaunamą vertę;
  • Renkantis įrankius ir sprendimus, reikia atsižvelgti į standartus ir ateities perspektyvas – visų pirma nepamiršti, kad verslo procesai turės keistis;
  • Žmogus iškelia tikslus, o vadybos praktikos ir įrankiai tik padeda juos pasiekti, todėl verslo procesų valdymo sėkmei būtina lyderystė ir aktyvus darbas su žmonėmis.

 

Naujienos

Lapkričio 16.
Sudėjome konferencijos akimirkų nuotraukas, Jūsų atsiliepimus bei vertinimus, o taip pat - skaitytų pranešimų skaidres.

Spalio 28.
Ačiū visiems, dalyvavusiems! Tikimės, kad žinios, gautos konferencijos metu, visiems Jums nuo šiol leis dirbti efektyviau!
Iki susitikimo VPVP 2012!

Konferenciją organizuoja:

Partneriai:

Swedbank Maxima Ism Omnitel Toc Urm Si KV Bpo Pwc Ovc Global Innovation Studio Efektyvūs sprendimai Ūkio ministerija