26.3. Kā modelēt kopīgās rindas
Aplūkosim situāciju, kad ražotājs ražo detaļas, un liek tās kādā krātuvē. Šī krātuve ir kopīga uzdevumiem Task_A un Task_B, kas šīs detaļas patērē. Šī situācija shematiski ir attēlota Zīm. 26.3.
Zīm. 26.3. Kopīgā rinda, problēmas formulējums
Zīm. 26.4. Kopīgā rinda, modelēta kā tehnoloģisks uzdevums
Kā šo situāciju attēlot valodā GRAPES-BM ? Viens no veidiem, kā to izdarīt, ir parādīts Zīm. 26.4. Rindas aprakstīšanai tiek ieviests speciāls uzdevums (tam atkal nav konkrēta izpildītāja), pie kura saražotās detaļas krājas rindā. Tālāk šis uzdevums sazarojas divās daļās - detaļa no ieejas rindas tiek nosūtīta uzdevumam Task_A, ja uzdevums Task_A šo detaļu pieprasa, un uzdevumam Task_B, ja uzdevums Task_B šo detaļu pieprasa.
26.4. Pārtraukumu modelēšana
Valodā GRAPES-BM 4.0 ar trigerēšanas nosacījumiem definē, kad uzdevums sāk izpildīties.
Dažreiz svarīgi ir arī nosacījumi, kad uzdevuma izpilde tiek pārtraukta. Zīm. 26.6 shematiski ir attēlots viens šāds gadījums.
Zīm. 26.5. Pārtraukuma problēmas formulējums
Rodas jautājums, vai ar pašreizējiem valodas līdzekļiem mēs varam pietiekami adekvāti aprakstīt šādu situāciju. Izrādās, ka varam.
Šajā nolūkā pati uzdevuma izpilde ir jāuztver kā notikums un iepriekšējā zīmējumā ieskicētā situācija ir jāattēlo atbilstoši Zīm. 26.7. Citiem vārdiem sakot, sākotnējais uzdevums Task_X ir jāaizstāj ar trim elementiem: trigerēšanas uzdevumu (Start), pārtraukšanas uzdevumu (Terminate) un notikumu X, kas atbilst sākotnējam uzdevumam. Viegli redzēt, ka šāda diagramma samērā adekvāti apraksta mums vajadzīgo situāciju.
Zīm. 26.6. BP fragments, kas modelē uzdevuma Task_X pārtraukšanu
Aplūkosim vēl vienu piemēru - situāciju, kas attēlota Zīm. 26.8.
Zīm. 26.7. Izpildes laiks un pārtraukums, problēmas formulējums
Ar Task_Y šeit ir apzīmēts uzdevums, kas normāli izpildās 15 min. Taču tiek pieņemts, ka jebkurā brīdī var ienākt ziņojums g, kas to pārtrauc. Zīm. 26.9 ir parādīts, kā šo situāciju nomodelēt ar esošajiem GRAPES-BM līdzekļiem. Šajā gadījumā uzdevums Task_Y tiek attēlots kā ziņojums Y un uzdevums Execute_Y.
Ja tālākā darbība ir atkarīga no tā, vai Task_Y ir beidzies normāli, vai ticis pārtraukts, tad arī to var aprakstīt, tikai jāizmanto zarošanās nosacījumi, kā tas parādīts Zīm. 26.10.
Zīm. 26.8. Pārtraukums uzdevumam ar noteiktu izpildes laiku, BP fragments
Zīm. 26.9. Pārtraukums ar divām izejām
Principā šeit lietotais mehānisms ir pietiekami universāls, lai tiktu galā ar praktiski jebkura veida pārtraukumiem.
26.5. Laika kontrole
Aplūkosim gadījumu, kad sekretāre nodod kalpotājam (klerkam) vēstules, kalpotājam šīs vēstules ir jāapstrādā, pie tam tas ir jāizdara ne ilgāk kā 20 dienās. Ja kalpotājs to neizdara, tad pēc šī kantora darbības nolikuma sekretāre sūta atgādinājumu. Šo situāciju var attēlot tā, kā tas ir parādīts Zīm. 26.11.
Zīm. 26.10. BP ar laika kontroli
Sekretāre, nosūtot vēstuli, reizē inicializē arī uzdevumu Delay, kurš atkal ir tehnisks uzdevums bez izpildītāja, un tam ir norādīts vienīgi, ka tā izpildes laiks ir 20 dienas. Nākamais uzdevums, uz kuru sekretāre nodod vadību, ir Pieņemt_mērus (Follow_Up). Šeit viņa gaida, ka vai nu atnāks rezultāts, vai arī nostrādās Timeout.
Ņemsim vērā vēl kādu niansi. Gadījumā, kad apstrādātā vēstule no kalpotāja ir saņemta pirms Timeout, šis notikums Timeout varētu palikt rindā bezgalīgi ilgi. Lai tas tā nenotiktu, mēs transakcijas beigas šeit norādām tiešā veidā ar END palīdzību. Rezultātā visi notikumi ar dotās transakcijas TIDu tiek izmesti no rindām.
26.6. Kā modelēt skaitītājus
Aplūkosim vienkāršu piemēru ar skaitītāju. Pieņemsim, ka uzdevums Order producē detaļu pasūtījumu, X_times nozīmē detaļu skaitu. Lai attēlotu detaļu izgatavošanu, varam vienkārši izmantot REPEAT X_times, pierakstot to izejas notikumam, kā tas parādīts Zīm. 26.12.
Zīm. 26.11. Skaitītājs ar REPEAT
Līdz ar to pirmajā brīdī mēs varam iztikt bez skaitītāja. Taču nepieciešamības gadījumā attiecīgo skaitītāju mēs varam arī nomodelēt, kā tas parādīts Zīm. 26.13.
Zīm. 26.12. Skaitītājs ar ciklu
Zīm. 26.14 ir attēlota vēl viena vērā ņemama nianse, kas ir saistīta ar transakcijas jēdzienu.
Zīm. 26.13. Skaitītāja sinhronizācija ar 'materiāliem' notikumiem
Zīm. 26.14. Skaitītāja sinhronizācija ar jauna darba sākumu
Dotajā gadījumā tiek pieņemts, ka pasūtījums satur arī ziņojumu Part_P, kurā ir aprakstīts, kāda detaļa mums īsti ir jāražo X_times eksemplāros. Šādā situācijā, ja ienāk vairāki pasūtījumi, t.i. vairāki pāri (Part_P, X_times), mums ir jāgarantē, lai uzdevums Izvieto_pasūtījumu (Organize_Production) turpmāk trigerētos tikai ar tiem pāriem (Part_P, X_times), kuriem X_times attiecās uz doto Part_P. Transakcijas definīcija mums šeit ļoti palīdz - tā jau automātiski garantē minētās prasības izpildi.
Tiesa, dotajā gadījumā Part_P un X_times varēja apvienot vienā record tipa ziņojumā un tad iepriekš minētie transakcijas smalkumi nebūtu jāizmanto.
Nākamajā Zīm. 26.15 ir parādīts, kā attēlot prasību, lai katrs uzsāktais pasūtījums (pāris Part_P, X_times) tiktu izpildīts līdz galam pirms ķeramies pie nākamā pasūtījuma (nākamā pāra Part_P, X_times).
Principā kā skaitītāju varētu izmantot arī mainīgo. Te jāievēro vienīgi, ka mainīgie visi ir globāli, un stingri jāseko, lai viens un tas pats mainīgais netiktu izmantots vairākās transakcijās vienlaicīgi. Ja izmantojam notikumus (kā Zīm 26.14), mums šajā ziņā palīdz pats transakcijas jēdziens.
26.7. Kādos gadījumos biznesa modelēšanu nevajag lietot
Kā jebkura valoda, arī GRAPES-BM ir pietiekoši ērta, lai aprakstītu to sistēmu klasi, kurai tā ir domāta. Tajā pašā laikā ir sistēmu klases, kurām šī valoda principā ir lietojama, taču no praktiskā viedokļa tā nav visai ērta, un to lietot nevajadzētu.
Biznesa modelēšanas valoda ir orientēta (un sevi attaisno) tādu sistēmu aprakstīšanai, kuru darbība vairāk vai mazāk notiek pēc noteikta scenārija. Piemēram, ja mēs aplūkojam labi organizētu ražošanas procesu, tad parasti tajā jau ir pietiekami precīzi definēta atsevišķu ražošanas uzdevumu izpildes secība. Protams, zarošanās šajā procesā ir iespējama, taču parasti tā ir pietiekami ērti aprakstāma.
Bez šādām sistēmām ir arī sistēmas, kas izteikti darbojas dialoga režīmā. Šādām sistēmām, kā likums, izteikti vadošu scenāriju nav, tos lielā mērā formē pats šis sistēmas lietotājs. Kā šāda veida piemēru aplūkosim lidmašīnas biļetes pasūtīšanu (ne visu šīs biļetes piegādes procesu, bet pašu pasūtīšanu pie kases lodziņa). Ja mēs šo procesu aprakstām ar vienu uzdevumu, tad viss ir labi. Tajā pašā laikā pati šī pasūtīšana ir tik maz pakļauta kādam konkrētam scenārijam, ka šo vienu uzdevumu sadalīt sīkākos uzdevumos, izmantojot biznesa modelēšanas valodu, jau ir ļoti grūti.
Sarežģīti dialogi, kuriem biznesa modelēšana nav ērta, parādās arī tādās programmu sistēmās, kur vairākas programmas darbojas paralēli un starp tām notiek komplicēti dialogi. Tieši tā tas notiek arī rīkā GRADE-BM, par to ies runa nākamajā nodaļā. Taču tas tomēr neizslēdz iespēju aprakstīt ar biznesa procesu palīdzību raksturīgākos scenārijus, kam varētu būt principiāla nozīme pie sistēmas darbības izpratnes.
27. Īss pārskats par rīku GRADE-BM
Zīm. 27.1 ir attēlota rīka GRADE-BM struktūra GRAPES-86 komunikāciju diagrammas (CD diagrammas) izskatā. Kā atsevišķs elements šeit parādās arī Lietotājs (User_1 un User_2). Šī diagramma parāda, no kādām apakšsistēmām GRADE-BM sastāv un kādi ziņojumi cirkulē starp šīm apakšsistēmām.
Zīm. 27.1. GRADE-BM komponentes
Tajā pašā laikā Zīm. 27.1 vāji atspoguļo iespējamos darbības scenārijus. Varētu mēģināt šos scenārijus attēlot ar biznesa procesa palīdzību. Viens šāds mēģinājums ir demonstrēts Zīm. 27.2. Šajā zīmējumā ir attēlots tipisks rīka GRADE-BM lietošanas scenārijs, ignorējot simts un vienu detaļu. Protams, arī šāds vienkāršots scenārijs dod zināmu priekšstātu par rīka GRADE-BM darbību. Taču precīzs GRADE-BM darbības scenārijs biznesa procesa izskatā iznāktu pārāk sarežģīts un nepārskatāms. Tādēļ šoreiz mēs esam spiesti palikt pie CD diagrammas (Zīm. 27.1) un ar tās palīdzību dot neformālu sistēmas darbības aprakstu.
Kā jau minējām, diagrammā ir attēlots arī lietotājs. User_1 attēlo lietotāju, kurš izveido modeli. Šis lietotājs sadarbojas ar rīka redaktoriem un ar modeļa vadības logu. Šīs sadarbības ir tipiska dialoga formā. Modeļa kokā lietotājs var iekārt jaunu diagrammu vai izvēlēties jau esošu, ko viņš vēlētos mainīt. Atbilstošais redaktors ļauj veidot vai mainīt diagrammu, izmantojot peli un klaviatūru. Šīs darbības rezultāts pēc tam tiek noglabāts repozitorijā (pie tam, redaktors tieši neraksta repozitorijā, starpā ir programmas komponente, kas nodarbojas ar repozitorija vadību). Principā ne tikai redaktoru, bet arī jebkura cita sadarbība ar repozitoriju notiek caur šo programmas komponenti (lai gan lietotājs drīkst to arī nezināt).
Nākošo soli ērtāk būtu attēlot biznesa procesā: modelis ir uzbūvēts, tālāk tas ir sintaktiski jāanalizē. Komunikāciju diagrammā nav iespējams labi attēlot to, ka šī analīze notiek pēc biznesa modeļa izveidošanas - mēs varam vienīgi novietot analīzes daļu zemāk par to, kas apraksta modeļa veidošanu.
Tātad, modelis ir izveidots. Sintakses analizators (caur modeļa vadības mehānismu) atgriež analizētās diagrammas statusu (vai tā ir sintakstiski pareiza vai aplama - modeļa logā tas attiecīgi parādās kā zaļš vai sarkans aplītis pie atbilstošās diagrammas). Ja kāda diagramma ir aplama, tad sintaktiskais analizators ir atzīmējis kļūdas un ir iespējams, dialogā ar redaktoru, šo diagrammu izlabot.
Tad, kad sintakses kļūdas ir novērstas, biznesa modeli var tālāk izmantot imitācijai. Šo darba fāzi, saskaņā ar mūsu diagrammu, veic cits lietotājs - User_2.
Arī šis lietotājs sadarbojas ar modeļa logu, kur viņš izvēlas komandas. Šāda komanda var būt, piemēram, Sākt imitāciju (Simulate). Vispirms notiek no ārpuses it kā ne sevišķi redzama darbība - diagrammas tiek sagatavotas imitācijai. Analīzes laikā katrai diagrammai tika izveidots t.s. S-kods, kas arī tika noglabāts repozitorijā. Tagad S-kodi tiek savākti kopā un starp tiem nodibinātas nepieciešamās saites. Šis apvienotais starpkods tiek noglabāts, lai to tālāk varētu izpildīt. Šī procesa rezultātā varētu parādīties arī daži ziņojumi par sintaktiskām kļūdām (kuras nevar īsti pamanīt analizējot katru diagrammu atsevišķi).
Pēc tam sāk strādāt imitātors, ar kura palīdzību biznesa modelis tiek izpildīts. Šeit pirmo reizi parādās situācija, kad programmas strādā paralēli - imitācijas laikā ir iespējams izmantot t.s. animācijas režīmu, kurš vizuāli parāda, kā šie biznesa procesi notiek, respektīvi, tiek parādīts, kuri uzdevumi strādā, pa kādiem ceļiem pārvietojas notikumi, cik garas ir rindas, utt. No sistēmas iekšējā viedokļa ar šo animāciju nodarbojas pavisam cita programma, ne tā, kas ar imitāciju. Abas šīs programmas savstarpēji sadarbojas ar dialoga palīdzību. Neviena no tām nav galvenā, un abas ir tieši pieejamas lietotājam.
Protams, lai noskaņotu biznesa modeli, ar animāciju parasti nepietiek, tādēļ imitātoram ir pieejami arī daudzi citi līdzekļi, kurus lietotājs var izvēlēties. Imitācijas rezultātus var ierakstīt t.s. trasē, kuru pēc tam ir iespējams apskatīties ar papildrīku - Trace Browser. Ir iespēja izvēlētus datus (piem. notikumu plūsmu u.c.) ierakstīt teksta failā.
Zīm. 27.2. BM modeļa izstrādāšanas galvenie soļi
Tad, kad imitāciju lieto, lai pētītu kādu biznesa procesu, ir iespējams savākt statistikas tabulas, kuras atkal var apskatīties ar jau minēto Trace Browser Šos statistikas rezultātus ir iespējams arī saglabāt repozitorijā atkārtotai caurskatei, rezultātu salīdzināšanai un tml. GRADE pieļauj arī iespēju tekstuālo trasi tieši importēt Excel Spreadsheetā un šajā rīkā veikt dažādus pēcizpildes statistikas novērtējumus.
Iepriekšējā nodaļā sniedzām īsu pārskatu par biznesa procesu modelēšanu ar rīka GRADE palīdzību. Neesam vēl pieskārušies jautājumam par to, kā notiek sistēmas projektēšana, kādi ir sistēmas dzīves cikla posmi jeb fāzes, kur šajā procesā ir vieta biznesa modelēšanai. Aplūkosim Zīm. 28.1, kur attēlotas sistēmas dzīves cikla trīs sākotnējās fāzes. Rīks GRADE atbalsta visas šīs fāzes.
Zīm. 28.1. Sistēmas dzīves cikla galvenās fāzes
Zīmējumā redzam,ka Biznesa Modeļa Izstrāde kā tāda atrodas vidū starp divām citām fāzēm : Sistēmas Statiskās Struktūras Modelēšanu (Objektu modelēšanu ar Klašu diagrammām) un Sistēmas Modeļa Izstrādi. Pēdējā fāze ir nepieciešama tikai tad, ja tiek izstrādāta vai pārprojektēta Informatīvā Sistēma (IS). Tipisks GRADE 4.0 pielietojums ir Biznesa Procesu Pārbūve (Reengineering), kādu izpilda daudzas konsultāciju firmas visā pasaulē. Šajā gadījumā dzīves cikls beidzas ar biznesa modelēšanu (kā likums, ietverot arī imitāciju). Rezultātā tiek izstrādātas rekomendācijas uzņēmuma pārstruktūrēšanai, biznesa procesu plūsmu vienkāršošanai u.t.t. Kā programmistiskāko rezultātu šajos gadījumos var minēt darbu plūsmu pārkārtošanu, ko var viegli attēlot ar BP diagrammām valodā GRAPES-BM.
Tagad atgriezīsimies pie pirmās fāzes - sistēmas statiskās struktūras modelēšanas. Šīs fāzes rezultāts ir sistēmas objektu modelis - klašu diagramma (vai diagrammu kopa) atbilstoši OMT/UML likumiem. Šāds modelis atspoguļo pirmo priekšstatu par sistēmu - esošo (kā ir) vai konstruējamo (kā jābūt).
Detalizēti klašu diagrammas šajā grāmatā neaplūkosim.
Kā lietot objektu modeli biznesa modelēšanas un nākošajā fāzē? Kas attiecas uz biznesa modelēšanu, tad objektu modelis lielā mērā kalpo kā uzmetums orgstruktūras modelim (ORG diagrammām) un datu modelim (DD un ER diagrammām). Tomēr, ja objektu modelis ir pietiekami detalizēts, tas pats par sevi var būt pietiekams biznesa modelēšanas vajadzībām, nemaz nezīmējot ne ORG, ne DD un ER (protams tikai gadījumos, kad mūs neinteresē biznesa modeļa imitācija).
Pietiekami detalizēts sistēmas objektu modelis satur arī ziņojumu (pārsūtāmo objektu) aprakstus, piemēram:
Šāds apraksts ir pilnīgi pietiekams ziņojuma Order izpratnei, un nav nepieciešams ievest speciālu datu tipu Order ar DD diagrammas palīdzību. Vēl lielākā mērā tas attiecas uz ER modeļiem, kuru pietiekami precīziem prototipiem ir jābūt jau sistēmas objektu modelī. Iepriekš teiktais, protams, neizslēdz DD un ER diagrammas kā vispār nevajadzīgas - sistēmas detalizētai projektēšānai tās būs nepieciešamas, sevišķi sistēmas izstrādes fāzē. Ja šāds nepabeigts biznesa modelis (kur ORG un DD diagrammu saturs ir ietverts klašu diagrammās) ir jāpārveido imitācijai, tad ar GRADE var automātiski uzbūvēt ORG un DD sagataves no klašu diagrammām.
Pāriesim tagad pie biznesa modeļa izstrādes fāzes, kas ir mūsu grāmatas galvenais priekšmets.
Aplūkosim detalizētāk biznesa modeļa izstrādes fāzi. Biznesa modelēšana tiek lietota gan, lai analizētu esošus procesus, gan, lai izstrādātu jaunus. Katrā no šiem gadījumiem modeļa izstrādes un imitācijas principi nedaudz atšķiras.
Zīm. 28.2 attēlotā BP diagramma parāda BM metodoloģijas galvenos principus un uzsver atšķirības starp:
Galvenie soļi abās diagrammas daļās patiesībā ir tie paši.
Zīmējumā redzamajai BP diagrammai ir divi sākuma punkti. Viens no tiem ir ārējais uzdevums Improve existing system (Uzlabot esošo sistēmu). Šajā gadījumā ir jāsāk ar esošās sistēmas analīzi un šauro vietu atklāšanu, lai atrastu, kā darbību uzlabot. Otrs sākuma uzdevums ir Develop new system from scratch (Izstrādāt jaunu sistēmu no sākuma). Šajā gadījumā uzdevumu ķēdes pirmuzmetums parasti būs vairākkārt jāpārprojektē un jāuzlabo.
Pirmais iekšējais uzdevums paredz aprakstīt Organizatorisko struktūru esošai sistēmai ar ORG diagrammas palīdzību. Tas jādara atbilstoši principiem, kas doti 4. un 14. nodaļās.
Nākošais uzdevums ir - ietverot lietu būtību, aprakstīt esošos Biznesa Procesus (uzdevumu ķēdes) BP diagrammu izskatā. Tas jādara atbilstoši principiem, kas izklāstīti 3., 5. un 6. nodaļā.
Zīm. 28.2. Biznesmodelēšanas galveno soļi
Zīm. 28.3.A atgādina ieteikto BP diagrammu veidošanas secību. Sākam ar BP diagrammu, iezīmējot uzdevumus un notikumus, kas tos saista.
Rīks nodrošina automātisku notikumu tabulas ET aizpildīšanu un TD diagrammu veidošanu katram iezīmētam uzdevumam (zīmējumā tas nosaukts par BP sinhronizāciju ar TD un ET). Ja laika gaitā BP diagramma tiek labota, tad ET tabulā un TD ārējos interfeisos var palikt lieki uzdevumi un saites. Šādus liekus elementus izslēdz, lietojot rīka funkcijas Delete events unused in BPs un Delete unused tasks.
Zīm. 28.3.B atspoguļo otru iespējamo BP izstrādes ceļu. Tas ir (samērā retais) gadījums, kad biznesa procesu projektējot, informācija ir pieejama tikai lokāli, katram atsevišķam uzdevumam par viņa saitēm ar kaimiņiem. Tādā gadījumā šie uzdevumi ir jāsakārto modeļa kokā un iegūtā interfeisu informācija jāieraksta uzdevumu TD diagrammās. Kad tas ir izdarīts, lieto GRADE funkciju Build BP from TDs. Rīks uzbūvē BP no definētiem uzdevumiem savietojot ierakstītos ieejas un izejas notikumus. Pēc tam jāveic uzbūvētās BP diagrammas pieslīpēšana ar roku.
Zīm. 28.3. BP diagrammas izstrāde: A) Tipiskais gadījums, sāk ar BP, sinhronizē ET un TD, B) Retākais gadījums, uzbūvē BP no TD
Šajā biznesa procesu apraksta solī tiek definētas arī nepieciešamās datu noliktavas un datu objekti.
Trešais uzdevums - aprakstīt esošās sistēmas uzdevumu un notikumu Atribūtus - ietver sevī:
Nākošais uzdevums ir - Analizēt modeļa korektību un pilnību, jo tikai tādu modeli var un ir vērts imitēt.
Esošā modeļa Imitācijai varam sekot līdzi arī ar animatora palīdzību. Imitācijas rezultātā iegūstam virkni statistisku rādītāju un/vai pilnu imitācijas trasi. Tos var lietot, lai skaņotu un uzlabotu modeli, kā arī lai novērtētu esošās vai iespējamās sistēmas uzvedību pie dažādiem parametriem.
Statistiskie imitācijas rezultati ietver izpildīto uzdevumu atribūtu summas, to maksimālās, vidējās un minimālās vērtības, izpildītāju aizņemšanu un atbrīvošanu (no uzdevumu puses), notikumu raksturojumus (laiks, kas pavadīts rindā, rindas garums, notikuma biežums), izpildītāju gaidīšanas un darbošanās laikus, uzdevumu izmaksas; un citus raksturojumus.
Imitācijas rezultātu novērtēšana ir heiristiski iteratīva procedūra. Tai ir divi iespējamie mērķi: modeļa novērtēšana un pilnīgošana (vispirms) un sistēmas analīze (pēc tam). Šeit jāpievērš uzmanība esošās sistēmas šaurām vietām un vājiem punktiem.Tos var viegli noteikt, izmantojot statistiskos rādītājus par garākajām rindām, neaizņemtiem izpildītājiem, pārslogotiem izpildītājiem vai pārāk garu notikuma virzīšanās laiku cauri uzdevumu ķēdei.
Kā alternatīvu imitācijai var veikt ekspertu statisku modeļa novērtējumu. Tā ir vienīgā iespēja gadījumos, kad uzdevumu un notikumu skaitliskās vērtības nav pieejamas vai tās nav iespējams iegūt, piemēram, laika trūkuma dēļ.
Nākošā uzdevumu grupa ir ietverta rāmī Modify for the new system (Modificēt jaunajai sistēmai). Šīs grupas galvenais mērķis ir uzlabot pastāvošo biznesa modeli. Šeit tipiskas ir sekojošās aktivitātes :
Pēc tam kad šādas izmaiņas ir izdarītas, ir jāizdara nākošais imitācijas eksperiments. Ir jāsalīdzina vecās un jaunās imitācijas rezultāti. Lai ērtāk būtu novērtēt un salīdzināt, ieteicams rezultātus eksportēt, piem., Excel Spreadsheet formatā, lai lietotu formālās salīdzināšanas procedūras un starprezultātu glabāšanu.
Šīs grupas pirmajā uzdevumā Modificēt Biznesa Procesus jaunajai sistēmai modificē attiecīgos biznesa procesus ar roku. Šie modificējumi tiek balstīti uz esošo biznesa procesu statiskās analīzes, kā arī uz imitācijas rezultātiem. Statiskās analīzes principi tiks aprakstīti un paskaidroti ar piemēru šīs nodaļas beigās.
Modificēšanas uzdevuma alternatīva ir Radīt Biznesa Procesus no sākuma. Tas ir gadījums, kad vai nu biznesa procesi vēl neeksistē, vai arī tos nevar ņemt par pamatu tālākajam darbam. Tas bieži nozīmē revolucionāru pieeju biznesa procesu attīstībai (atšķirībā no iepriekšējās, evolucionārās pieejas). Evolucionārajā pieejā sāk ar ieejas (starta) punktu un cauri uzdevumu ķēdei virzās uz izejas (rezultāta) punktu. Revolucionārajā pieejā mērķis ir - radīt īsāko ceļu uz rezultātu, tādēļ šeit iesaka būvēt uzdevumu ķēdi otrādi: no vēlamā rezultāta atpakaļ uz iespējamo sākumu, lai šo rezultātu sasniegtu.
Nākošais uzdevums Izpildītāji pieraksta BP uzdevumiem esošus vai, iespējams, jaunus izpildītājus. Šajā solī vēl var nedomāt par galīgo hierarhiju ORG diagrammā.
Tālāk piešķir Atribūtus uzdevumiem un notikumiem un Analizē iegūtā modeļa korektību.
Jaunā BM imitācijai parasti nepieciešamas vairākas iterācijas līdz iegūst apmierinošus rezultātus. Katrā iterācijā var tikt mainīti uzdevumu vai notikumu atribūti, pievienoti vai izmesti izpildītāji, mainīta BP struktūra.
Pēdējais uzdevums Uzbūvēt Sistēmas Modeli ietver ORG diagrammas radīšanu ar īsto hierarhiju. Atzīmēsim GRADE iespēju, kas palīdz iegūt labu ORG diagrammu. Rīkam ir funkcija Build system model (Uzbūvēt sistēmas modeli) no biznesa modeļa. Rodas CO diagrammas, kas ietver visus izpildītājus un saites starp tiem. No šīm diagrammām ir viegli konstatēt:
Tas palīdz sakārtot organizācijas hierarhisko struktūru. Tas palīdz arī pareizi izvietot. piemēram, informatīvo sistēmu apkalpojošos datorus un citus kopīgi izmantojamus resursus. Tipiskas maiņas ORG diagrammās ir sekojošas:
Šīs izmaiņas atspoguļo pilnīgo sasaisti uzdevumu ķēdēm ar izpildītāju lietošanu tajās. Piemēram, izpildītāju pārvietošana nozīmēs ziņojumu pārsūtīšanas laika samazināšanu; lai samazinātu uzdevuma izpildes laiku, tiks palielināts izpildītāju skaits vai izmantoti izpildītāji ar augstāku kvalifikāciju u.t.t.
Jebkurā projekta izstrādes fāzē noderīga ir rīka Datu Vārdnīca. Vārdnīca ir viena visam modelim un parāda katra elementa definīcijas un lietojuma vietas. No tās var viegli atrast, piemēram, visus kāda uzdevuma vai notikuma lietojumus u.c.
Biznesa modeļa statiskās analīzes principi ir heiristiski. Tie ir pilnīgi saprotami no veselā saprāta viedokļa. Šeit mēs sniegsim pamatprincipu apkopojumu.
I. Labāk, kur vien tas ir iespējams, uzdevumu virknes izpildes vietā lietot paralēlo izpildi. Tas saīsina uzdevumu izpildes laiku. Praktiskos projektos sasniegt 50% laika ietaupījumu ir pilnīgi reāls mērķis;
II. Jāizvairās no organizatoriskiem pārrāvumiem, cik vien tas ir iespējams. Tas nozīmē, ka pēc iespējas tie uzdevumi, kas seko viens otram virknē, jāpilda vienam un tam pašam izpildītājam, ja vien nav nepieciešama speciāla kvalifikācija. Tādēļ:
III. Jānodrošina, lai informācijas mēdijs starp uzdevumiem būtu homogēns:
IV. Katram uzdevumam jānodrošina informatīvās sistēmas atbalsts;
V. Jāizslēdz funkciju lieka izpilde.
Saprātīga šo principu lietošana statiskās analīzes fāzē palīdz atrast vājos punktus un šaurās vietas.
Aplūkosim biznesa procesa piemēru Kursu Plānošana un Organizēšana, kas attēlots ar BP diagrammu Zīm. 28.4. Šī diagramma ir viena daļa no Darbinieku Izglītošanas Kursu Sistēmas un apraksta, kā Vadītājs (Manager), Kursu Izstrādes Nodaļa (Training Delivery Department) un Informatīvā Sistēma (MTR System) ,- šie trīs ir uzdevumu izpildītāji,-izveido, plāno un organizē uzņēmuma darbinieku izglītošanu.
Tikai divi izpildītāji (Vadītājs un Kursu Izstrādes Nodaļa) ir iesaistīti iekšējo apakšuzdevumu izpildē. Saprotot, ka kursu plānošana un pasniegšana prasa īpašas zināšanas un pieredzi, varam teikt, ka prasība (2) šajā gadījumā ir izpildīta.
Tomēr informācijas mēdijs no uzdevuma uz uzdevumu mainās :
Bez tam, Vadītājam ar roku jāievada darbinieku uzvārdi un kursu kodi, lai gan informācija ir noglabāta datu bāzē un ietverta Licenču Izbeigšanās Atskaitē un Kursu Katalogā. Vēl vairāk, šīs pašas informācijas ievads ir nepieciešams, sagatavojot ziņojumus darbiniekiem; pat ja Vadītājs lieto copy/paste datu pārnešanai no e-vēstules uz Kursu Stundu Plānu, tad tas tomēr ir roku darbs.
Zīm. 28.4. BP diagramma uzdevumam Kursu Plānošana un Organizēšana
Tā mēs secinām, ka biznesa process, kas attēlots ar BP diagrammu Zīm. 28.4 nav pietiekami efektīvs attiecībā pret prasībām (3) līdz (5).
Biznesa procesa modificēta versija redzama Zīm. 28.5.
Zīm. 28.5. Modificēta BP diagramma uzdevumam Kursu Plānošana un Organizēšana
Galvenās atšķirības starp pirmo un otro versiju ir sekojošas:
Novērtējot Zīm. 28.5 biznesa procesu, varam secināt, ka:
Līdzīgā veidā biznesa procesu statiskās analīzes principus var lietot jebkuram citam biznesa modelim.