1. Biznesa modelēšana un tās mērķi
Vairums iepriekšējās paaudzes specifikāciju valodu un uz tām balstītie rīki bija orientēti uz datu apstrādes sistēmām. Šādas sistēmas parasti sauc par informatīvām sistēmām.
Biznesa modelēšanas valodas un rīki ir orientēti uz daudz plašāku sistēmu klasi, kuras parasti sauc par biznesa sistēmām.
Ar biznesa sistēmām saprot jebkuras sistēmas, kuras veic kaut kādas aktivitātes. Šīs aktivitātes var būt kā ražošanas procesi, tā arī tīri informācijas apstrādes procesi. Šīs aktivitātes var būt arī jaukti procesi, kas ietver kā ražošanu, tā arī informācijas apstrādi. Par tipisku biznesa sistēmu var uzskatīt jebkuru kantori, kas apkalpo klientus, piemēram, bankas, apdrošināšanas sabiedrības, biļešu rezervēšanas sistēmas un tml. Par biznesa sistēmu var uzskatīt arī fabriku, kura ražo kaut kādu produkciju. Tāpat par biznesa sistēmu var uzskatīt jebkuru informatīvo sistēmu.
Kas ir biznesa modelēšana? Tā ir šādu biznesa sistēmu formāla vai pusformāla aprakstīšana lietojot dažādus viegli uztveramus formālismus.
Kas ir valoda GRAPES-BM, kas ir aprakstīta šajā grāmatā? Tā ir pusformāla valoda ar saviem jēdzieniem un grafiskiem līdzekļiem, kas ļauj viegli uztveramā formā precīzi aprakstīt biznesa sistēmas - to organizatorisko struktūru un darbību.
Ko nozīmē precīzi aprakstīt? Tas nozīmē aprakstīt tā, lai cilvēkam šis apraksts būtu viennozīmīgi saprotams. Patiesībā biznesa modelēšanas mērķis ir nedaudz plašāks - lai arī datoram liela daļa no šī apraksta būtu saprotama un līdz ar to imitējama (pārbaudāma darbībā).
Kādēļ ir vajadzīga biznesa modelēšana? Tā ir vajadzīga tādēļ, lai iegūtu esošās vai projektējamās sistēmas (kantora, bankas, apdrošināšanas sabiedrības, fabrikas u.t.t.) precīzu struktūras un funkcionēšanas aprakstu. Tikai pateicoties šādam aprakstam varēs īsti saprast, kā funkcionē iestāde, pēc kādiem algoritmiem tiek veikti attiecīgie informācijas apstrādes vai ražošanas procesi, ko dara katrs tās darbinieks, kā tiek izmantoti iestādes resursi, kādas ir šo apstrādes procesu šaurās vietas u.t.t. Protams, vairumā gadījumu aizvien paliks darbinieku iniciatīva, radošais moments, kuru nevar formalizēt, taču, lai iestāde sekmīgi funkcionētu, formalizētajai daļai ir jābūt pēc iespējas lielākai.
Var teikt, ka biznesa modelēšanas valoda ir tas leksikons, kas dod iespēju šo formalizēto, precīzo iestādes darbības daļu pierakstīt viegli saprotamā formā, kuru pēc tam var izmantot iestādes vadības, analīzes un pārbūves (reengineering) vajadzībām.
Viens no biznesa modelēšanas blakus mērķiem ir arī precīzi izdalīt informatīvās sistēmas vietu un funkcijas.
Noslēgumā atzīmēsim, ka biznesa modelēšanas valoda GRAPES-BM 4.0 kopā ar tās rīku kopu GRADE-BM 4.0 ir domāta biznesa sistēmu modelēšanai un imitēšanai dažādos to būves etapos - sākot ar pašu augšējo - loģisko līmeni un beidzot ar pašu zemāko - fizisko līmeni, ieskaitot programmatūras struktūru un tās funkcijas.
2. Biznesa modelēšanas pamatjēdzieni
Biznesa modelēšana lielā mērā balstās uz diviem fundamentāliem jēdzieniem: uzdevums un notikums.
WEBSTER-a vārdnīcā uzdevums (task) tiek definēts kā "a piece of work". Biznesa modelēšanā uzdevuma jēdziens tiek tālāk precizēts. Tam tiek pierakstīta virkne formālu rādītāju, kas to sīkāk raksturo: trigerēšanas (uzdevuma uzsākšanas) nosacījums, izpildītājs, izpildes laiks utt.. Viena no galvenajām uzdevuma īpašībām, kas tiek likta pamatā biznesa modelēšanas koncepcijai, ir pieņēmums, ka uzdevums ieejā saņem noteiktus objektus un, tā izpildes rezultātā, izstrādā citus objektus. Šie objekti var būt gan materiāli objekti, gan arī tīri informatīvi objekti.
Uzdevumu mēs grafiski attēlosim kā četrstūri ar ieapaļiem stūriem un uzreiz atzīmēsim, ka uzdevumam vienmēr būs vārds un parasti tiks norādīts arī izpildītājs:
Tiks šķiroti divu veidu uzdevumi - parastie uzdevumi un zarotie uzdevumi. Zarotais uzdevums nozīmē to, ka tā izpildes laikā tiek izvērtēti tālākas darbības iespējamie ceļi (zarojumi):
Katram zaram vienmēr tiek norādīts vārds (Correct, Wrong, OK un tamlīdzīgi) un grafiski to attēlo kā sešstūri.
Ja uzdevums attiecībā pret pētāmo sistēmu ir ārējs (external), t.i. tas kalpo tikai dotās sistēmas apkārtnes aprakstīšanai, tad grafiski tas tiek attēlots ar pārtrauktas līnijas palīdzību:
WEBSTER-a vārdnīcā notikums (event) tiek definēts kā a thing that happens or takes place, the fact of a things occurring, the outcome, issue or result of anything.
Visas šīs definīcijas ir lietojamas arī biznesa modelēšanas kontekstā. No biznesa modelēšanas viedokļa raugoties notikumi ir tie, kas izsauc uzdevumu izpildi, t.i. trigerē uzdevumus atbilstoši to trigerēšanas nosacījumiem (par trigerēšanas nosacījumiem runāsim nedaudz vēlāk).
Valodā GRAPES-BM ir vairāku veidu notikumi, to var attēlot sekojoši:
1. Pirmais notikumu veids ir objektu pārsūtīšana (transfer of object). Šī veida notikums - tas ir kāda objekta (materiāla vai tīri informatīva) nosūtīšanas vai saņemšanas fakts. Biznesa modelēšanas gadījumā objektu sūtītāji un saņēmēji ir uzdevumi. Ja uzdevums A nosūta objektu E uzdevumam B, tad saka, ka E attiecībā pret uzdevumu A ir izejas notikums, bet attiecībā pret uzdevumu B - ieejas notikums. Vienkāršības labad, kā mēs jau tikko to izdarījām, objektu pārsūtīšanas notikumus identificēsim ar pašiem objektiem.
Šie objekti, kā jau tas minēts, var būt kā materiāli, piemēram, kāda detaļa, tā arī tīri informatīvi, piemēram, rēķins.
Notikumus mēs attēlosim ar bultiņu, kas ved no viena uzdevuma uz otru:
Objektu pārsūtīšanas notikumiem vienmēr ir vārds, kurš ir pierakstīts šai bultiņai. Ja mēs gribam būt precīzāki, tad jāsaka, ka šīs bultiņas sākums attēlo izejas notikumu uzdevumam Task_A, un bultiņas beigas attēlo ieejas notikumu uzdevumam Task_B. Līdz ar to bultiņu var uzskatīt par šī notikuma (jeb, precīzāk, objekta, saistīta ar šo notikumu) plūsmas ceļu.
Pie pirmā veida notikumiem mēs pieskaitīsim arī saturīgi saprotamus stāvokļus, kuros sistēma var nonākt veicot kādu uzdevumu. Piemēram, ja uzdevums ir Sildīt_ūdeni, tad kā izejas notikums šim uzdevumam varētu būt Ūdens_sāk_vārīties. Ja par šo faktu tiek paziņots kādam citam uzdevumam, piemēram, Izslēgt_elektrību, tad attiecībā pret šo uzdevumu dotais notikums ir ieejas notikums:
Notikumu definējot norāda tā kategoriju.
Objektu pārsūtīšanas notikumiem ir iespējamas sekojošas kategorijas:
Jebkuri pārsūtīšanas notikumi var nest sev līdzi informāciju, kuru raksturo ar datu tipu, kas šim ziņojumam tiek piekārtots. Formāli visi notikumi tiek reģistrēti Notikumu Tabulā (Event Table), tieši tur katram notikumam var pierakstīt datu tipu. Sīkāk par to runāsim vēlāk.
Vēl par notikumu vārdiem. Jācenšas veiksmīgi izvēlēties notikumu vārdus, lai pēc vārda jau būtu skaidra notikuma saturiskā jēga. Piemēram, ja uzdevums Task_A formē pasūtījumu, kuru pēc tam nodod uzdevumam Task_B, tad attiecīgo notikumu dabiski būtu saukt par Order:
Arī uzdevumu vārdiem ir jābūt pēc iespējas saturīgākiem. Piemēram, dotajā piemērā Task_A vietā dabīgāk būtu rakstīt Send_order vai Prepare_and_send, vai vienkārši Prepare, bet Task_B vietā Receive_order vai Receive_and_Process, vai vienkārši Process (atkarībā no tā, kāds "piece of work" ar doto uzdevumu tiek domāts):
Turpmāk, kur tas neradīs domstarpības, jebkurus objektu pārsūtīšanas notikumus mēs sauksim vienkārši par ziņojumiem.
2. Otrais notikumu veids ir vadības plūsma (control flow):
Arī to attēlo ar bultiņu no viena uzdevuma uz otru. Saturīgi tas nozīmē to, ka uzdevums, no kura iziet šī bultiņa, ir beidzis savu darbu. Bultiņas virziens norāda, kādam uzdevumam tālāk tiek nodota vadība. Vadības plūsmas notikumus patiesībā var uzskatīt par ziņojumu notikumu paveidu, kuri nekādu citu informāciju, izņemot faktu, ka šis notikums ir noticis, nenes. Svarīgi ievērot, ka vadības plūsmas notikumiem netiek rakstīts vārds. Arī vadības plūsmas notikumus, līdzīgi kā pārsūtīšanas notikumus, mēs dažreiz sauksim vienkārši par ziņojumiem.
3. Trešais notikumu veids ir laika notikums, jeb taimeris (timer). Laika notikumus raksturo tas, ka tos nerada nekāds uzdevums, tie rodas paši no sevis - noteiktos laika momentos, kas norādīti šī notikuma definīcijā. Šos notikumus mēs apzīmēsim ar pulkstenīti un bultiņu. Bultiņas virziens norāda uzdevumu, uz kuru šis notikums ceļo:
Lai būtu skaidrāk, aplūkosim dažas precīzas laika notikumu definīcijas (šīs definīcijas tiek ierakstītas Notikumu Tabulā):
Šeit ir definēts laika notikums ar vārdu EveryMorning, un šī precīzā definīcija (skat. kolonnu Data Type) nozīmē to, ka notikums notiek katra gada un mēneša katru dienu pulksten 9.00.
Nākamais ir laika notikums From5to6pm, tas notiek katru dienu pulksten 17.00 un turpinās vienu stundu. Turpināšanās ilgums tiek definēts kolonnā Persistence Interval.
Nākamais ir notikums Every2min, tas tiek definēts kā notikums, kas periodiski iestājas ik pēc 2 minūtēm.
Šajā nodaļā sīkāk nekavēsimies pie laika notikumu precīzas definīcijas, plašāk par to runāsim 16. nodaļā.
Atzīmēsim, ka arī laika notikumu vārdiem ir jābūt veiksmīgi izvēlētiem - tā, lai bez precīzās definīcijas jau daudzmaz būtu skaidrs, ko attiecīgais notikums nozīmē. (Iepriekšējos piemēros laika notikumu vārdi, liekas, ir izvēlēti pietiekoši veiksmīgi).
Būvējot biznesa modeļus augšējā līmenī, kurā mēs aprakstām modelējamo sistēmu tikai aptuveni, var veidoties situācija, kad laika notikumu mēs vēl precīzi negribam specificēt. Piemēram, mēs nezinām, vai tas būs Every_Morning, vai Every_Monday. Šajā gadījumā ir ieteicams lietot kādu neitrālu vārdu, kā, piemēram, Appropriate_moment, vai Timely.
Noslēdzot šo apakšnodaļu par notikumiem, atzīmēsim vēl, ka no viena un tā paša uzdevuma var iziet vairāki izejas notikumi, turklāt viens un tas pats notikums var aiziet uz vairākiem citiem uzdevumiem. Līdzīgi, ieejas notikumi vienam uzdevumam var pienākt vairāki, pie tam tie var būt arī ar vienādiem vārdiem:
Pie uzdevuma detalizācijas pamatjēdzieniem pieder uzdevuma trigerēšanas nosacījums (triggering condition). Tā ir loģiska izteiksme, kas apraksta nosacījumus uz ieejas notikumiem, lai dotais uzdevums sāktu izpildīties.
Aplūkosim piemēru:
Dotajā gadījumā trigerēšanas nosacījums ir E & F & G (& vietā lieto arī AND). Šo pašu nosacījumu var pierakstīt arī īsāk:
Tas nozīmē, ka tiek AND-oti visi zīmējumā redzamie ieejas notikumi. Uzdevums sāks pildīties, ja būs ienākuši visi trīs notikumi E, F, G.
Lai precīzāk paskaidrotu trigerēšanas nosacījumu, mums ir jāaplūko tāds jēdziens kā notikumu rindas. Proti, notikumi (jeb precīzāk - šo notikumu eksemplāri) pie tā uzdevuma, kurā tie ir ieejas notikumi, veido rindu (katram notikumam sava rinda, pēc principa FIFO - "pirmais rindā, pirmais ārā no rindas"). Šo rindu ir viegli saprast, ja notikumus mēs uztveram kā fiziskus objektus.
Atšķirībā no ziņojumu notikumiem taimeris kā tāds (ja persistences intervāls nav norādīts) notikumu rindā neuzkavējas. Vai nu uzdevums to momentā patērē, vai arī tas pazūd no rindas bez pēdām. Lai liktu taimeram uzkavēties rindā noteiktu laika intervalu, tam pieraksta persistences intervālu. Iepriekšējā piemērā bija laika notikums From5to6pm ar persistences intervālu 1h, tas nozīmē, ka šis notikums stāv pie attiecīgā uzdevuma no pulksten 5 līdz 6 pēcpusdienā, un pēc tam pats pazūd (ja uzdevums viņu jau nepatērē ātrāk).
Atgriežoties pie piemēra - trigerēšanas nosacījums E & F & G izpildās, ja rindā atrodas vismaz pa vienam notikumu E, F, G eksemplāram. Tādā gadījumā uzdevums patērē pirmos atbilstošā nosaukuma notikumu eksemplārus no ieejas rindas. "Patērē " nozīmē to, ka uzdevums izņem šos eksemplārus no notikumu rindas un pārstrādā atbilstoši savai specifikācijai. Piemēram, ja E, F, G ir kādas detaļas un uzdevums Task_B ir Samontēt, tad no rindas izņemtās detaļas E, F, G tiek samontētas un rezultātā izveidots kāds Mezgls, kurš tālāk parādīsies kā uzdevuma Task_B izejas notikums.
Ja rindās nav notikumu, kas izpilda trigerēšanas nosacījumu, tad šis uzdevums gaida, kamēr tādi notikumi parādās.
Ir atļauti arī OR tipa trigerēšanas nosacījumi. Tas nozīmē: jebkurš viens no notikumiem E, F, G ir pietiekams, lai uzdevums Task_B sāktu izpildīties. To pieraksta
vienā no sekojošiem veidiem (OR vietā var rakstīt |):
Trigerēšanas nosacījumos ir atļautas AND un OR kombinācijas, piemēram, E & (F | G), bet nav atļauta negācija no notikumiem.
Atzīmēsim vēl vienu samērā bieži lietojamu trigerēšanas nosacījumu:
Šajā piemērā uzdevumā Task_B ienāk divi notikumi E un G un trigerēšanas nosacījums ir E & ALL G . Atslēgas vārds ALL nozīmē, ka uzdevums sāk darbu, ja rindā ir vismaz viens notikuma E eksemplārs, un vismaz viens notikuma G eksemplārs. Izpildoties trigerēšanas nosacījumam šis uzdevums "apēdīs" vienu notikuma E eksemplāru un visus notikuma G eksemplārus, kas tajā brīdī atradīsies rindā.
Vēl viena noruna ir par vadības plūsmas notikumiem. Aplūkosim šādus divus piemērus:
Pirmajā piemērā ir divas notikuma E ieejas. Atbilstoši teiktajam dotais uzdevums trigerēsies, ja ieejas rindā būs vismaz viens notikuma E eksemplārs (vienalga, pa kuru ieeju tas ir atnācis!) un vismaz viens notikuma G eksemplārs. Otrajā piemērā ir divas vadības plūsmas ieejas. Šajā gadījumā uzdevums Task_B trigerēsies tikai tad, ja pa abām vadības plūsmas ieejām būs pienākusi vadība, t.i., vadības plūsmas gadījumā tiek pieņemts, ka katra vadības plūsmas notikuma ieeja veido savu rindu, un, ja ir divas vadības plūsmas ieejas un AND nosacījums, tad šis nosacījums izpildīsies tikai tad, ja abas vadības plūsmas rindas būs netukšas.
Vēl dažus vārdus par izejas notikumiem. Jau iepriekš bija atzīmēts, ka no viena un tā paša uzdevuma var iziet daudzi izejas notikumi. Ir vēl kāda noruna, kuru mēs jau nākamajā piemērā lietosim. Proti, ja izejas notikums ir ar to pašu vārdu kā ieejas notikums, tad tiek uzskatīts, ka dotais uzdevums ienākušo objektu (ieejas notikumu) nemainītā veidā nosūta tālāk. Šī situācija ir raksturīga informācijas apstrādē. Piemēram, notikums E varētu būt kāds dokuments, kuru uzdevums izpēta, un pēc tam nodod tālāk.
Līdzīga noruna ir arī ALL gadījumā - ja parādās izejas notikums ar vārdu, kāds trigerēšanas nosacījumā ir aiz ALL, tad visi ieejas notikumi ar šo vārdu tiek nemainītā veidā nodoti tālāk.
Nākamais jēdziens, kas attiecas uz uzdevumu detalizāciju, ir uzdevuma izpildītājs (performer).
Pie uzdevuma var pierakstīt tā izpildītāju (vai izpildītājus):
Šajā piemērā ir redzams, ka dotajam uzdevumam trigerēšanas nosacījums ir &, bet izpildītājs ir Clerk & PC. Piemērs ir raksturīgs ar to, ka izpildītājs šeit ir gan cilvēks, gan ierīce.
Vispārīgā gadījumā izpildītājs var būt kā viena vienība, tā arī vesela loģiska izteiksme no dažādiem izpildītājiem. Loģiskās izteiksmēs ir atļauts lietot AND un OR, bet nav atļauts lietot negāciju (tāpat kā trigerēšanas nosacījumos).
Saturīgi, lai uzdevums startētu, ir nepieciešams, lai izpildītos trigerēšanas nosacījums un būtu pieejami vajadzīgie izpildītāji.
Vēl viens jēdziens, kas attiecas uz uzdevumu detalizāciju - uzdevuma izpildes laiks (duration):
Dotajā piemērā tas ir "2h" - 2 stundas.
Līdz ar to mēs īsumā esam raksturojuši galvenās formālās uzdevuma sastāvdaļas:
Patiesībā ar uzdevumu ir saistīta pati galvenā tā sastāvdaļa, proti, darbība ("piece of work"), ko šis uzdevums veic. Taču biznesa modelēšanā tā, kā likums, netiek līdz galam formalizēta. Tas, ko šis uzdevums veic, ir jāsaprot saturiski. Parasti, dodot uzdevumam vārdu, ir jācenšas, lai šis vārds jau aptuveni aprakstītu, ko uzdevums veiks. Piemēram, pasūtījumu apstrādes gadījumā labs vārds varētu būt Order_processing.
Tomēr, bieži vien ar uzdevuma vārdu nepietiek, lai uzdevumu pietiekami precīzi saprastu. Tāpēc ir iespēja zem uzdevuma vārda sīkākā fontā ierakstīt komentāru - patvaļīgu tekstu, piemēram:
Datu manipulācija, ko veic uzdevums, tiek aprakstīta izmantojot datu noliktavas un datu objekta jēdzienu.
Ar datu noliktavu (data store) mēs sapratīsim kādu persistentu (neatkarīgu no dotā uzdevuma) datu vai materiālu glabātavu. Tad, kad mēs runāsim par informatīvām sistēmām, datu noliktava, kā likums, pārvērtīsies par datu bāzi ar noteiktu struktūru (ER modeli).
Projektēšanas augšējos līmeņos datu noliktavas jēdziens netiek saistīts ar īstiem, reāliem datiem. Informatīvas sistemas gadījumā šo datu noliktavu var iedomāties vienkārši kā dokumentu kaudzi, ražošanas procesa gadījumā - kā fizisku materiālu un detaļu krātuvi.
Datu noliktavu mēs apzīmēsim ar simbolu
kuram iekšpusē raksta viņa vārdu. Šim vārdam arī ir jābūt saturīgam, piemēram, Iesniegumu_arhīvs, Ziņas_par_pasūtītāju, A_tipa_detaļas un tml. (Ir iespēja zem vārda sīkākā fontā ierakstīt komentāru - patvaļīgu tekstu.)
Šeit parādās kāda ļoti raksturīga biznesa modelēšanas iezīme: augšējos projektēšanas līmeņos datu noliktavas simbolu mēs saprotam kā fizisku objektu glabātavu, bet, nolaižoties līdz informatīvai sistēmai, tas pārvēršas par datu glabātavu jeb datu bāzi.
Datu noliktavas simboli vienmēr ir saistībā ar vienu vai vairākiem uzdevumiem. Gadījumā, kad mēs neprecizējam, kādā virzienā notiek sadarbība starp doto uzdevumu un doto datu noliktavu, mēs savienosim šos simbolus ar neorientētu nogriezni:
Ja mēs gribam parādīt, ka materiāli (vai informācija) šajā noliktavā tiek likti iekšā, mēs nogriežņa galā zīmējam mazu aplīti:
Līdzīgi, ja materiālus (vai informāciju) ņem ārā no noliktavas, tad aplīti zīmējām pie uzdevuma:
Uz šiem pieejas (access) nogriežņiem var rakstīt arī vārdus, ar kuriem mēs nosaucam vai raksturojam sadarbības formu starp uzdevumu un noliktavu, piemēram:
Datu objekts ir līdzīgs datu noliktavai, bet atšķiras ar to, ka, pirmkārt, tas ir jāuztver kā viens atsevišķs objekts, un, otrkārt, tas pastāv ("dzīvo") tikai vienas biznesa transakcijas laikā (par transakciju skat. 10. nodaļā). Tad, kad mēs esam nonākuši jau līdz programmu sistēmai, datu objekti visbiežāk atbilst kopējiem failiem - viens uzdevums aizpilda doto failu ar noteikta veida informāciju, nākamais uzdevums izmanto šo informāciju. Projektēšanas augšējos līmeņos, it sevišķi, ja mēs aprakstām kādu ražošanas procesu, datu objekts parasti ir jāsaprot kā fizisks objekts (piemēram, konkrēta detaļa), ko viens uzdevums izveido un nākamais uzdevums izmanto.
Arī datu objektiem piemīt iepriekš minētā divdabība - tie var būt gan fiziski objekti, gan tīri informācijas objekti. Datu objektus mēs apzīmēsim ar simbolu:
Arī datu objektiem var uzrādīt sadarbības formu ar attiecīgajiem uzdevumiem pēc tiem pašiem likumiem kā datu noliktavai:
Dotajā zīmējumā ir attēlota sekojoša situācija: uzdevums Task_A savas darbības rezultātā izveido objektu Letter un pēc tam nodod vadību uzdevumam Task_B. Task_B, savukārt, paņem izveidoto objektu Letter un to apstrādā.
Viegli saprast, ka šo pašu situāciju var attēlot arī objekta Letter vietā ieviešot ziņojumu Letter:
Šie piemēri parāda, ka starp datu objektiem un ziņojumiem pastāv līdzība un ka zināmā nozīmē tie cits citu var aizstāt. Taču datu objekts un ziņojums kā divi atsevišķi jēdzieni ir ieviesti tādēļ, ka ir gadījumi, kad ērtāk ir domāt ziņojumu terminos, un ir gadījumi, kad ērtāk ir domāt datu objektu terminos. Ja runā par GRAPES-BM imitācijas iespējām versijā 4.0, tad tās ir orientētas uz notikumu imitāciju, datu noliktavai un datu objektam ir tikai komentāra loma.
3. Pirmais priekšstats par biznesa procesu (BP diagramma)
Vispārīgā gadījumā ar biznesa procesu saprot darbu virkni, kas jāveic, lai iegūtu kādu noteiktu rezultātu, kam ir saturīga jēga no tiešā lietotāja viedokļa. Valodā GRAPES-BM ar biznesa procesu saprot kāda lielāka uzdevuma aprakstu (detalizāciju) ar mazāku (un vairāk vai mazāk pašu par sevi saprotamu) uzdevumu, notikumu un, ja nepieciešams, datu noliktavu un datu objektu palīdzību, izmantojot tos līdzekļus, kas iepriekš tika pieminēti. Šo aprakstu valodā GRAPES-BM sauc arī par BP diagrammu (Business Process Diagram)
Sāksim ar piemēru.
Piemērs 3.1. Aplūkosim konsultāciju biroju, kuru mēs vienkāršības labad sauksim par Kantori. Mūsu aplūkotajā kantorī strādās divi darbinieki - Priekšnieks un Sekretāre, tiem būs arī dators - PC :
Mēs aplūkosim tikai vienu kantora darbības aspektu - vēstuļu apstrādi. Kantoris no klientiem saņem vēstules, sekretāre tās iereģistrē, pēc tam priekšnieks kopā ar sekretāri gatavo atbildi. Tad sekretāre, izmantojot PC, noformē atbildi un nosūta klientam.
Zīm. 3.1. Biznesa process Vēstuļu apstrāde
Zīm. 3.1 šī vēstuļu apstrāde ir attēlota biznesa procesa izskatā. Lūk, tas arī ir pirmais biznesa procesa (BP diagrammas) piemērs, kurš ir pierakstīts atbilstoši GRAPES-BM sintaksei. Šis pieraksts ir tik dabīgs, ka, pat izlaižot iepriekšējās nodaļas skaidrojumu, bez grūtībām var uztvert, kas šeit ir domāts. Ar pārtrauktu līniju ir attēloti uzdevumi, kurus veic ārējie izpildītāji - dotajā gadījumā klienti (šādus uzdevumus mēs norunājām saukt par ārējiem jeb eksternāliem).
Zīm. 3.2 šī pati vēstuļu apstrāde ir attēlota jau daudz detalizētāk. Arī šis attēlojums ir sintaktiski pareizs biznesa process valodā GRAPES-BM.
Uzdevumu un notikumu vārdi mums palīdz pietiekoši viennozīmīgi izprast doto procesu.
Vispirms sekretāre iereģistrē saņemto vēstuli. Pēc tam viņa analizē saņemto vēstuli un nosaka, vai tā ir parasta vai steidzama. Parastās vēstules viņa nodod priekšniekam dienas beigās - At_5_PM, steidzamās - tūlīt. Priekšnieks, saņēmis vēstuli, nosaka, vai ir nepieciešama papildinformācija, lai sagatavotu atbildi. Ja tāda ir nepieciešama, tad viņš izvēlas iespējamo informācijas avotu un nosūta tam atbilstošo jautājumu. Kad no informācijas avota ir saņemta atbilde, priekšnieks analizē šo atbildi un nosaka, vai vēl ir nepieciešama papildinformācija. Ja ir nepieciešama, tad tiek atkārtota iepriekš aprakstītā informācijas iegūšanas procedūra. Ja atsūtītā informācija ir pietiekoša, priekšnieks gatavo atbildes melnrakstu, kuru pēc tam sekretāre ar datora palīdzību attiecīgi noformē un nosūta klientam. Pašu vēstuli un atbildes kopiju sekretāre ieliek arhīvā un pēc tam piešķir sev kafijas pārtraukumu.
Zīm. 3.2. Sīkāks Vēstuļu apstrādes izvērsums
4. Īsumā par organizatoriskās struktūras attēlošanu
Lai izprastu kādu sistēmu, mums parasti ir jāsāk ar tās organizatoriskās struktūras aprakstu. Tieši tā mēs arī darījām iepriekšējās nodaļas Piemērā 3.1, kad skaidrojām, kas ir Kantoris.
Valodā GRAPES-BM ir paredzēta t.s. ORG diagramma, ar kuras palīdzību var attēlot sistēmas orgstruktūru. Piemērā 3.1 kantora organizatoriskā struktūra ir attēlota atbilstoši GRAPES-BM ORG diagrammas sintakses prasībām.
Šis attēlojums ir dabisks, un pat neko nezinot par GRAPES-BM ORG diagrammu, tas ir saprotams.
Tomēr dažos vārdos raksturosim galvenos GRAPES-BM ORG diagrammas elementus.
ORG diagramma sastāv no kokiem, ko veido šāda tipa elementi:
 |
- orgvienība (piemēram, kantoris, cehs, nodaļa u.t.t.) |
 |
- štata vieta (piemēram, sekretāre, priekšnieks, programmētājs u.t.t.) |
 |
- resurss (piemēram, automašīna, PC, konkrētā programma u.t.t.) |
Ja attiecīgo elementu skaits var būt lielāks par 1 (t.i. tie veido veselu klasi), tad to attēlo ar dubultrāmja palīdzību:
Zīm. 4.1 ir dots nedaudz sarežģītāks ORG diagrammas piemērs.
Šajā piemērā ir attēlots Kantoris, kas sastāv no 2 nodaļām. Kantorim ir Priekšnieks. Kantorim pieder 2 automašīnas. Tālāk, Nodaļai_A ir Vadītājs, 5 Kalpotāji, kā arī 3 PC. Līdzīgi, Nodaļai_B arī ir Vadītājs, 10 Kalpotāji un 12 PC.
Sīkāk skat. 14. nodaļu
Zīm. 4.1. ORG diagrammas piemērs
5. Sistēmas biznesa modelis: vispārīgs priekšstats
Iepriekšējās nodaļās mēs jau ieguvām priekšstatu par biznesa procesa (BP) diagrammu un ORG diagrammu. Šīs diagrammas neapšaubāmi ir galvenās biznesa modeļa sastāvdaļas. Taču bez tām ir nepieciešama vēl vesela virkne diagrammu, lai pietiekoši precīzi un strukturēti aprakstītu pētāmo (vai projektējamo) sistēmu. Visu šo diagrammu kopu tad arī sauc par sistēmas biznesa modeli. Šīs diagrammas veido noteiktu hierarhiju. Zīm. 5.1 un Zīm. 5.2 shematiski attēlota šī diagrammu hierarhija, izmantojot ORG diagrammas apzīmējumus (atgādināsim, ka taisnstūris ar dubultrāmi attēlo daudzkārtīgu elementu).
Kā redzams, sistēmas biznesa modelis satur trīs apakšmodeļus (jeb aprakstus):
Sistēmas organizatoriskās struktūras apraksts, kā redzams Zīm. 5.1 un Zīm. 5.2, tiek veikts ar divu veidu diagrammu palīdzību - ar iepriekšējā nodaļā pieminēto ORG un, nepieciešamības gadījumā, vēl vienu speciālu diagrammu - kompetenču tabulu (CMP). Sīkāk skat. 13. nodaļu.
Datu apraksta daļa definē datus modelēšanas un imitācijas vajadzībām.
Procesu aprakstu varam uzskatīt par galveno biznesa modeļa sastāvdaļu. Tas parāda sistēmas sadalījumu pa uzdevumiem, sistēmā izmantojamos notikumus un uzdevumu tipus.
Zīm. 5.1 redzams, ka sistēmas sadalījums pa uzdevumiem sākas ar primāro uzdevumu izdalīšanu. Ar primārajiem uzdevumiem saprot sistēmas galvenos uzdevumus, kuriem ir patstāvīga saturīga jēga un kuri ir vairāk vai mazāk neatkarīgi viens no otra. Katra primārā uzdevuma apraksts tiek veikts ar divu diagrammu - BP un TD palīdzību.
Primāra uzdevuma TD diagramma (pilnais nosaukums: Task Details Diagram) satur uzdevuma vispārīgo specifikāciju. Pirmā priekšstata līmenī pieminēsim vienīgi, ka TD diagramma satur neformālu uzdevuma aprakstu brīva teksta formā. Būtiska ir uzdevuma detalizācija ar BP diagrammas (pilnais nosaukums: Business Process Diagram) palīdzību. Šo detalizāciju ar BP diagrammas palīdzību mēs saucam par dotā uzdevuma biznesa procesu. Tas saskalda doto uzdevumu sīkākos apakšuzdevumos. Katram apakšuzdevumam atkal atbilst viņa vispārīgā specifikācija TD diagrammas izskatā. TD diagramas aizmetnis tiek izveidots automātiski, un vienkāršos gadījumos lietotājs par tās saturu var neinteresēties.
Zīm. 5.1 parāda gadījumu, kad primārie uzdevumi jau "pirmā līmeņa" biznesa procesos tiek saskaldīti elementāros uzdevumos.
Elementārie uzdevumi, protams, ir intuitīvs jēdziens, vienam lietotājam uzdevums var likties elementārs, citam nē, taču jebkurā gadījumā šī uzdevuma neformālajam aprakstam viņa TD diagrammā ir jābūt tik skaidram, lai tam lasītāju lokam, kam tas ir domāts, viņš būtu viennozīmīgi saprotams. Ja pirmā līmeņa biznesa procesi uzreiz primāros uzdevumus saskalda elementāros apakšuzdevumos (respektīvi modelī ir tikai viens detalizācijas līmenis), tad šādus biznesa modeļus un tiem atbilstošos biznesa procesus sauksim par plakaniem.
Zīm. 5.1. Plakana modeļa struktūra
Zīm. 5.2 ir aplūkots gadījums, kad apakšuzdevumi, kuros primāro uzdevumu saskalda pirmā līmeņa biznesa process, vēl nav elementāri. Šajā gadījumā katram šādam apakšuzdevumam tiek būvēta BP diagramma (biznesa process), kas saskalda doto apakšuzdevumu vēl sīkākos apakšuzdevumos. Zīm. 5.2 aplūkots gadījums, kad tādā veidā iegūtie apakšuzdevumi jau ir elementāri un tālāk vairs netiek skaldīti ar BP diagrammu palīdzību. Šāda veida biznesa modeļus un tiem atbilstošos "augšējā līmeņa" biznesa procesus sauksim par strukturētiem.
Zīm. 5.2 attēlotā struktūra ir dziļumā 2, vispārīgā gadījumā struktūra var būt jebkurā dziļumā, pie tam dažādiem primārajiem uzdevumiem struktūra var būt dažādā dziļumā.
Sīkāk par biznesa procesu strukturēšanu un TD diagrammām skat. 6. un 7. nodaļu.
Tagad aplūkosim atsevišķos diagrammu veidus un to saturu.
Sāksim ar notikumiem. Vispirms atzīmēsim, ka notikumi kā tādi parādās, zīmējot biznesa procesus. Taču biznesa procesa diagrammā "nav vietas", kur precīzi notikumu definēt. Precīza definīcija nozīmē, piemēram, datu tipa piekārtošanu attiecīgajam notikumam. Notikumu precīzai definēšanai ir paredzēta NotikumuTabula (Event Table, ET) (sīkāk skat. 16. nodaļā). Šī tabula ir tikai viena visam modelim, jo vispārīgā gadījumā notikumiem ir globāls raksturs, tie apraksta interfeisu starp dažādiem uzdevumiem, tāpēc šādu tabulu nevar piekārtot vienam atsevišķam uzdevumam.
Zīm. 5.2. Strukturēta biznesmodeļa struktūra
Ir Datu definēšanas diagrammas (Data Definition, DD), kurās var definēt datu tipus, un arī ER modeļus (sīkāk skat. 15. nodaļā).
Ir Pieeju tabulas (AT tables). Tāda tabula tiek piekārtota atsevišķam uzdevumam, to lieto, lai precizētu uzdevuma sadarbību ar datu noliktavu, ja tas ir nepieciešams (sīkāk skat. 15. nodaļā). Pieeju tabulas projektēšanas augšējos līmeņos, kā likums, netiek lietotas.
Ir Atribūtu tabulas (ATR tables), kurās tiek definēti uzdevumu atribūti. Lieta tāda, ka vispārīgā gadījumā uzdevumiem var būt arī atribūti, un, lai katram uzdevumam atsevišķi nebūtu jādefinē šie atribūti, tie tiek vienreiz nodefinēti atribūtu tabulā un pēc vajadzības piekārtoti uzdevumiem (sīkāk skat. 18. nodaļā).
PD (Process Diagram) diagrammas palīdz precīzi attēlot uzdevuma iekšējās darbības. Jāpiezīmē gan, ka valodā GRAPES-BM tām ir vienīgi komentāra loma.
Vēl biznesa modelis var saturēt Imitācijas parametru tabulu (Simulation Parameters, SP ), kuru lieto biznesa modeļa imitācijas vajadzībām.
Imitācijas vajadzībām var lietot arī Mainīgo tabulu (Variable Table, VT).
Līdz ar to visas diagrammas un tabulas, kas veido biznesa modeli, ir īsumā raksturotas.
Taču ir vēl viena speciāla diagramma, un proti, biznesa modeļa koks, kas kalpo biznesa modeļa loģiskās struktūras attēlošanai. Modeļa koks ir biznesa modeļa "oficiāla" sastāvdaļa, attiecīgajā rīkā (GRADE-BM) to mēs vispirms ieraugām uz ekrāna, kad sākam aplūkot (vai veidot) biznesa modeli. Biznesa modeļa koku var uzskatīt par biznesa modeļa satura rādītāju un reizē par diagrammu loģiskās hierarhijas aprakstu (atbilstoši Zīm. 5.1 un Zīm. 5.2). Zīm. 5.3 attēlo modeļa koku precīzā GRAPES-BM sintaksē, atbilstoši Zīm. 5.2 diagrammu loģiskai hierarhijai.
Kā redzams no Zīm. 5.3, tad katram uzdevumam modeļa kokā atbilst sava rindiņa, aiz kuras ar nobīdi seko šim uzdevumam atbilstošo apakšuzdevumu rindiņas. Katra uzdevuma rindiņa satur visas iespējamās viņam atbilstošās diagrammas. Pirmām kārtām tās ir TD un BP diagrammas. Tālāk seko jau iepriekš pieminētā AT tabula, kuru augšējos projektēšanas līmeņos, kā likums, nelieto. Kā pēdējā uzdevuma rindiņā parādās diagramma PD. No GRAPES-BM 4.0 viedokļa šī diagramma ir grafisks komentārs, kurā, atbilstoši GRAPES-86 vai GRAPES/4GL sintaksei, var zīmēt procesa diagrammu, kas precīzāk aprakstītu attiecīgā uzdevuma funkcionalitāti. Šajā grāmatā mēs šo iespēju sīkāk neaplūkosim. Katras modeļa koka rindiņas sākumā redzam komentāra diagrammu CMT, kurā lietotājs var ievadīt jebkuru sev vajadzīgo informāciju.
Noslēgumā vēl atzīmēsim, ka ne visām diagrammām, kas parādās modeļa kokā, ir jābūt obligāti aizpildītām, par aizpildījumu liecina ietonējums attiecīgo diagrammu rādītājos.
Zīm. 5.3. Modeļa koks
GRAPES-BM sintakses pilnīgākai izpratnei nozīmīgi ir sekojošie Zīm. 5.4.-Zīm. 5.11. Šajos zīmējumos ir aplūkots jau zināmais 3. nodaļas Piemērs 3.1, šoreiz ielikts precīzos GRAPES-BM sintakses rāmjos un attēlots plakana modeļa Office (Kantoris) izskatā.
Zīm. 5.4 ir attēlots modeļa koks. Ietonējums diagrammu rādītājos norāda, ka šīs diagrammas tiek izvērstas tālākajos zīmējumos. Un tās ir: ORG diagramma (Zīm.5.5), TD diagramma primārajam uzdevumam Query_Processing (Vēstuļu_apstrāde) (Zīm.5.7), pats biznesa process (BP diagramma) dotajam uzdevumam (Zīm.5.8), tad TD diagrammas elementārajiem uzdevumiem (Zīm.5.9 u.t.t.). Kaut arī notikumi šajā gadījumā netiek precīzi definēti, Notikumu Tabula tomēr parādās (Zīm. 5.6 - šādā izskatā rīks to aizpilda automātiski).
Atzīmēsim, ka Zīm. 5.8 attēlotā BP diagramma precīzi atbilst 3. nodaļā (Zīm. 3.2) attēlotajam biznesa procesam, vienīgā atšķirība, ka 3. nodaļā šis biznesa process tiek aplūkots lokāli ārpus kopējā sistēmas biznesa modeļa konteksta.
Vēl lasītājam var radīt neizpratni elementāro uzdevumu TD diagrammas, kas attēlotas Zīm. 5.9 u.t.t. Šajās diagrammās parādās speciāli simboli izskatā
kas apraksta interfeisu ar kaimiņuzdevumiem. Sīkāk to aplūkosim 7. nodaļā.
Zīm. 5.4. Kantora modeļa koks
Zīm. 5.5. Kantora modeļa ORG diagramma
Zīm. 5.6. Kantora modeļa ET tabula
Zīm. 5.7. TD diagramma primāram uzdevumam Query_Processing
Zīm. 5.8. BP diagramma uzdevumam Query_Processing
Zīm. 5.9. TD diagramma uzdevumam Register_Query
Zīm. 5.10. TD diagramma uzdevumam Forward_to_Chief
Zīm. 5.11. TD diagramma uzdevumam Analyze_Query
6.Biznesa procesu strukturēšana. Piemērs
Šajā nodaļā mēs sīkāk aplūkosim biznesa modeļa strukturēšanu. Kā jau teicām iepriekšējā nodaļā, strukturētais biznesa modelis no plakanā atšķiras ar to, ka primāro uzdevumu apakšuzdevumi savukārt tiek detalizēti. Ar biznesa procesa strukturēšanu saprot sekojošo. Vispirms mēs zīmējam rupju biznesa procesu (BP diagrammu), kas primāro uzdevumu saskalda lielos apakšuzdevumos. Pēc tam katram no šiem lielajiem apakšuzdevumiem zīmējam savu BP diagrammu, kas to saskalda sīkākos apakšuzdevumos u.t.t., kamēr nolaižamies līdz ļoti maziem apakšuzdevumiem, kuri ir paši par sevi saprotami. Tos mēs uzskatām par elementāriem uzdevumiem un tālāk vairs nedetalizējam.
Aplūkosim Piemēram 3.1 atbilstošos Zīm. 3.1 un Zīm. 3.2. Faktiski strukturēta apraksta metode jau šeit ir lietota. Tikai augšējā līmeņa apraksts (Zīm. 3.1) šajā piemērā uztverts kā palīgapraksts, lai pēc tam būtu vieglāk uzrakstīt detalizēto biznesa procesu (Zīm. 3.2).
Taču GRAPES-BM dod sintaktiski precīzus līdzekļus, kā, neaizmetot šo augšējā līmeņa aprakstu, turpināt tālāk tā detalizāciju. Galvenā problēma, kas šeit ir korekti jāatrisina - tā ir interfeisu aprakstīšana starp dažāda līmeņa uzdevumiem. Tagad attēlosim iepriekšminēto piemēru strukturētā formā atbilstoši GRAPES-BM sintakses prasībām. Iegūsim Zīm. 6.1 - 6.13 attēlotās diagrammas.
Kā redzams no modeļa koka (Zīm. 6.1), šajā piemērā ir viens primārais uzdevums - Query_Processing. Šī uzdevuma "rupjais" biznesa process ir attēlots Zīm. 6.5 (tas precīzi atbilst Zīm. 3.1, vienīgi ir ielikts pareizos GRAPES-BM rāmjos). Šis biznesa process saskalda doto primāro uzdevumu sekojošos "lielos" apakšuzdevumos: Register_and_Forward_Query, Prepare_Answer un Send_Answer.
Zīm. 6.9, 6.10 un 6.11 ir attēlota tālāka šo uzdevumu detalizācija, ieskaitot precīzu interfeisu atbilstoši GRAPES-BM sintaksei.
Interfeisa aprakstīšana tiek veikta ar t.s. references simbolu palīdzību. References simboli tiek attēloti ar raustītiem četrstūra rāmīšiem, kuros ieraksta to kaimiņuzdevumu vārdus (vai taimeru simbolus), ar kuriem iepriekšējā līmenī ir saistīts detalizējamais apakšuzdevums:
Kā tas redzams no zīmējumiem, tad ir paredzēti trīs veidu references simboli:
 |
iekšējā uzdevuma reference |
 |
ārējā (eksternālā) uzdevuma reference |
 |
taimera reference. |
Aplūkojam uzdevuma Prepare_Answer detalizāciju (Zīm. 6.10). Redzam, ka šajā gadījumā referencēšanās notiek uz "lielajiem" kaimiņuzdevumiem Register_and_Forward_Query un Send_Answer. Abi šie kaimiņuzdevumi ir iekšējie, tādēļ to attēlošanai arī tiek lietoti iekšējo uzdevumu references simboli.
Viegli saprast, ka caur šādu referenču mehānismu mēs varam atjaunot t.s. plakano diagrammu, kura ir tikai vienā līmenī.
Pieņemsim tagad, ka visi citi uzdevumi ir jau paši par sevi saprotami ("elementāri"), izņemot vienu uzdevumu - Coffee_Break, kuru detalizēsim tālāk. Šī detalizācija ir attēlota Zīm. 6.13.
Šajā gadījumā referencēšanās notiek uz kaimiņuzdevumu Archive_Answer, kas ir tā paša līmeņa uzdevums kā Coffee_Break.
Šī detalizācija ir pamācoša vēl tādā nozīmē, ka šeit tiek attēlots "ražošanas tipa" biznesa process. Pirmais elementārais uzdevums ir Pour_Water_in_Heater (to veic sekretāre). Tālāk vadības plūsmas notikums aizved uz diviem citiem uzdevumiem. Viens ir Prepare_Coffee_for_Coffeepot, otrs - Heat_Water (pēdējo veic sildītājs).
Tālāk seko uzdevums Brew_Coffee, kas beidzas ar notikumu Coffee_Ready.
Šeit parādās arī interesants datu noliktavas lietojums - lai attēlotu nevis datu glabātavu, bet gan materiālu (dotajā gadījumā - kafijas) glabātavu. Šāds noliktavas lietojums ir samērā raksturīgs ražošanas tipa uzdevumiem. Kā jau tas bija atzīmēts 2. nodaļā, ar datu noliktavām un datu objektiem ir jāsaprot ne tikai datu noliktavas un objekti.
Vēl šeit parādās arī īpatnēji ziņojumu notikumi Water_Boils un Coffee_Ready, kas patiesībā ir īpaši sistēmas stāvokļi, kuru iestāšanās tiek uztverta kā notikums. Kā jau tas bija atzīmēts 2. nodaļā, ziņojumu notikumi ne vienmēr ir jāsaprot kā kāda fiziska ziņojuma sūtīšana, ziņojumu notikumi bieži tiek lietoti daudz abstraktākā nozīmē.
Zīm. 6.1. Kantora strukturētā modeļa koks
Zīm. 6.2. ORG diagramma Kantora modelim
Zīm. 6.3. ET tabula Kantora modelim
Zīm. 6.4. BP diagramma uzdevumam Query_Processing
Zīm. 6.5. BP diagramma uzdevumam Register_and_Forward_Query
Zīm. 6.6. BP diagramma uzdevumam Prepare_Answer
Zīm. 6.7. BP diagramma uzdevumam Send_Answer
Zīm. 6.8. BP diagramma uzdevumam Coffee_Break
Šajās BP diagrammās esam nodemonstrējuši vēl vienu GRAPES-BM iespēju - pierakstīt uzdevumu simboliem īsos jeb alternatīvos vārdus. Šie vārdi parādās uzdevumu simbolu augšējos labējos stūros. Parasti tie ir skaitļi vai skaitļu virknes, atdalītas ar punktiem, kas palīdz noteikt uzdevuma līmeni un vietu diagrammu hierarhijā.