E nterprise K nowledge D evelopment ( EKD ) Modelēšanas metode

1. Enterprise Knowledge Development (EKD) Modelēšanas metode Pēc Zviedrijas Karaliskajā Tehnoloģiju Institūtā (KTH)izstrādātajiem materiāliem

2. EKD metode tiek lietota ES projektos: • ELEKTRA • HYPERBANK • F3 • NATURE • FP5 HyperKnowledge • Achieving SI thoug the application of E-learning solutioins in College RRC Organizācijās: • Astrakan, Vattenfall, PostGirot, Volvo, Telia (S) • PPC, Singular, National Bank of Greece (GR) • Capital Bank, British Aerospace, Datel (UK); • Sema Group (F) • Verbundplan (AU) • Rīgas Dome (LV) Projektos Latvijā: • Augstākās izglītības kvalitāte • Augstskolu sadarbība E-izglītības attīstībai • Valsts Sociālās Aprošināšanas aģentūra • A/S “Dati” Universitātēs: • Royal Institute of Technology • Stockholm School of Economics, Univ. of Skövde, Univ. of Kalstad, (S) • Univ. of Paris-1, Sorbonne (F) • UMIST, Manchester (UK) • Rīgas Tehniskā Universitāte (LV)

3. Kā mēs redzam pasauli? Kopīga aina savstarpēji pieņemtāun atzītā valodā. Rezultātā - efektīvs modelis

4. Modelēšanas process Pasaules atspoguļojums modelī Reālā pasaule Abstrahēšana Strukturēšana Kategorizēšana Uzņēmums, organizācija “Modelētājs” Modelēšanas process Modelis

5. EKD praktiķi uzskata, ka modelēšana grupā ir • Efektīvs veids kā izmainot aizņemtu cilvēku laiku; • Nopietns darbs; • Efektīvs analīzes darbarīks; • Efektīvs veids kā grupai nonākt pie konsensa; • Modelēšana ir demokrātiska, katrs piedalās ar savām zināšanām uz vienlīdzīgiem noteikumiem; • Aktivizējoša; • Precīza: šeit nav pieņemami gari un neskaidri teikumi; • Prasīgs: divas vai trīs dienas modelēšanas procesa var izrādīties nogurdinošas; • Interesanta un aizraujoša.

6. EKD modelēšanas rezultāti • EKD modelēšanas procesa gaitā rodas trīs potenciāli svarīgi rezultāti: • Izveidoti modeļi– dod ieguldījumu tālākajā organizācijas attīstībā un darbībā: • tie ir kvalitatīvi - iesaistītas maksimāli daudz ieinteresēto pušu; • tos vieglāk realizēt - ieinteresētās puses intensīvi iesaistītas lēmumu pieņemšanā. • Mainīti dalībnieku uzskati unuzlabotas zināšanas; • Saskaņoti dalībnieku viedokļi (viedokļu nesaskaņas modelēšanas laikā izpaužas atklātā diskusijā un var vienoties par labākiem variantiem -> konsenss). • Modeļos atspoguļojās arī netveramās zināšanas (tacit knowledge), kas citādos apstākļos paliktu arī neaprakstītas. "It actually happens that people can do quite a lousy job where they are happy as birds after modelling sessions. "Hallelujah", they cry and embrace each other. Then nothing happens …" [A.Persson, PhD thesis p197,2001]

7. EKD metodes modeļi

8. EKD metodes modeļupiemērs

9. Iteratīvā modeļu veidošana Ievērojiet: veidojamie modeļi pilnībā ir atkarīgi no modelēšanas MĒRĶIEM!

10. Mērķu modelis Mērķis: • Aprakstīt, ko organizācija un tās darbinieki grib sasniegt, vai no kā izvairīties un kad; • aprakstīt organizācijas mērķus kopā ar problēmām, kas saistītas ar to sasniegšanu; • Izskaidrot, kāpēc procesi, likumi un prasības eksistē vai neeksistē.

11. Mērķu modelis Sastāvdaļas: • mērķis – tiek izmantots mērķu aprakstīšanai attiecībā uz organizācijas darbību vai tās stāvokli, ko darbinieki vai pati organizācija grib sasniegt. Tie var būt izteikti kā izmērāmu stāvokļu secība, vai kā vispārīgi mērķi, vīzijas vai instrukcijas. Mērķiem var būt vairākas nozīmēs, tādas kā mērķi, vajadzības, prasības, vēlamie stāvokļi, utt. • problēma – tiek izmantota organizācijas stāvokļu aprakstīšanai, kas kavē mērķu sasniegšanu. Izšķir 2 veidu problēmas - draudiun vājās vietas • ierobežojums – izmanto, lai aprakstītu darbības ierobežojumus, noteikumus, likumus, politiku no apkārtējās pasaules, kas ietekmē sastāvdaļas un to saites organizācijas modelī. • iespēja – izmanto, lai aprakstītu situācijas, kuras mēs varētu izmantot. Ja iespēja tiek izmantota, tā transformējas par mērķi.

12. <īss nosaukums> <mērķa teksts> 14. Mērķis <1. mērķis> <1. mērķis> Iegūt papildus finansējumu 50000 LVL 2 gadu laikā <2.mērķis> <3. mērķis> <2. mērķis> <3. mērķis> Mērķu modeļa aprakstīšana Saites starp MM sastāvdaļām: MM sastāvdaļas: atbalsta/traucē(vāji/vidēji/stipri) kavē MM modeļa komponentes piemērs Dekompozīcija: UN (AND) VAI (OR)

13. Mērķa modeļa komponenšu izteikšana (1) • Izteikt mērķi pēc iespējas konkrētāk. Tos var izteikt ar pilnu teikumu, kas sākās ar: mērķis ir. • Izvairīties no frāzēm, kuras var viegli pārprast, vārdiem ar daudzām nozīmēm • Izvairīties no kārdinājuma “pabeigsim vēlāk” vai “mēs atcerēsimies, ko tas nozīmē” Neskaidri formulēts mērķis: Skaidri formulēts mērķis 17. Mērķis 17. Mērķis Mērķis ir iegūt ārēju papildus finansējuma avotu 50 000 LVL nākamajos 3 gados Papildus finansējums

14. 5. problēma Nav mācību centruVF organizācijas iekšienē 5. problēma Nav mācību centru VF organizācijas iekšienē (var piesaistīt konsultantusun mācībspēkus no ārienes) Mērķa modeļa komponenšu izteikšana (2) • Nerakstīt 2 dažādus izteikumus vienā modelēšanas komponentē Sākotnēji noformulēto problēmu... var pārveidot kā problēmu un iespēju 7. iespēja Mācībspēkus un konsultantus darbinieku apmācībai var piesaistīt no ārpuses

15. Mērķu modeļa piemērs Source:ELECTRUM Library Case

16. Jēdzienu (konceptu) modelis Mērķis: • definēt “lietas” un “parādības”, par kurām tiek runāts citos modeļos • precīzāk definēt izteikumus mērķu modelī, kā arī resursu saturu biznesa procesu modelī

17. Jēdzienu modeļa sastāvdaļas • Jēdziens (koncepcija) – lietas vai parādības, kuras mēs apskatam citos modeļos. Jēdzieni tiek definēti un skaidroti uzrādot tos kopsakarībā ar citiem jēdzieniem. • Atribūts tiek lietots, lai raksturotu jēdzienā pieminētās lietas vai parādības. Tā ir jēdzienā pieminēto objektu īpašība.

18. Jēdzienu modeļa pieraksts (1) Jēdziens: <īss nosaukums> <Jēdziena nosaukums> Jēdziena (koncepts): 25. jēdziens Klients Atribūts: <Atribūta nosaukums> Atribūta piemērs: Adrese

19. <1. jēdziens> <1. jēdziens> <2. jēdziens> <3. jēdziens> <2. jēdziens> <3. jēdziens> <1. jēdziens> <1. jēdziens> <2. jēdziens> <2. jēdziens> <3. jēdziens> <3. jēdziens> Jēdzienu modeļa pieraksts (2) Ģeneralizācija (pilnīga): Agregācija (pilnīga): Agregācija (daļēja): Ģeneralizācija (daļēja):

20. 47, jēdziens SLIKTS KLIENTS KLIENTS DOKUMENTS 49, jēdziens 48, jēdziens FIZISKA PERSONA ORGANIZĀCIJA KĀJENE SATURS 50, jēdziens 51, jēdziens SABIEDRISKAORGANIZĀCIJA NODAĻA PIELIKUMS FIRMA Jēdzienu modeļa pieraksta piemēri Agregācija Ģeneralizācija

21. Jēdzienu modeļa paraugs Agregācija Ģeneralizācija

22. Biznesa likumu modelis Mērķis: • Definēt un uzturēt skaidri formulētus biznesa likumus, saskanīgus ar mērķa modeli. • Biznesa likumi ir uzskatāmi par mērķu aktivizēšanu darbībā. Tie var būt sekojošā formā: • precīzi formulējumi, kas apraksta veidu kā organizācija ir izvēlējusies sasniegt savus mērķus, īstenot savus darbības plānus vai • dažādi ārējie biznesu (darbību) regulējoši noteikumi, piemēram, instrukcijas, nolikumi utt. • Biznesa likumu modelis parasti precizē tādus jautājumus kā: • Kādi noteikumi vai nolikumi ietekmē organizācijas mērķus? • Vai ir pieņemti kādi darbības plāni? • Kā biznesa likumi ir saistīti ar mērķi? • Kā mērķus atbalsta biznesa likumi?

23. Biznesa likumu modeļa sastāvdaļas (1) • Atvasinājuma likumi – atvasinājuma likumi ir zināšanu apraksts, kas ir atvasināts no citām zināšanām ar secinājumu palīdzību vai veicot matemātiskas darbības.Izteiksmes un izteikumi, kas definē atvasinātās komponentes atrodas jau modelējamā uzņēmuma informācijas bāzē. Atvasinājuma likumi ir ieviesti kā veids strukturālā domēna zināšanu iegūšanai un tās vērtība nav jāglabā, bet gan ir iegūstama dinamiski izmantojot eksistējošo vai citu atvasināto informāciju. Atvasinājuma likums, piemēram, var būt “Slikts bibliotēkas klients ir klients, kas neatdod aizdoto materiālu divas nedēļas. • Notikumu-darbības likumi izsaka nosacījumus, kuriem iestājoties ir jāsāk darbība, t.i., jābūt izpildītiem palaides nosacījumiem pirms sākas darbība. Piemēram, ja bibliotēkas izsniegtā materiāla atgriešana tiek kavēta vairāk kā 4 dienas, sūtam atgādinājumu.

24. Biznesa likumu modeļa sastāvdaļas(2) • Ierobežojumu likumisaistās ar informācijas struktūras komponenšu integritāti vai ar plānoto darbību uzņēmuma darbību un tā pieļaujamo darbību. Ierobežojums, piemēram, “darbinieku algas nedrīkst samazināties”. • Statiski ierobežojumi pielietojami jebkuram sistēmas stāvoklim un nav atkarīgi no laika. Tie reprezentē stāvokļus, kuriem jāpastāv vienmēr. Statiska ierobežojuma piemērs “katrai grāmata ir tikai viena unikāla atrašanās vieta” • Pārejas ierobežojumi definē spēkā esošus informācijas sistēmas stāvokli. Pārejas ierobežojums ir piemēram “Grāmatas kopija tiek uzskatīta par pazudušu, ja atgriešanas termiņš nokavēts 2 mēnešus”

25. Dekompozīcija: UN (AND) <1. likums> <1. likums> <2. likums> <3. likums> <2. likums> <3. likums> Biznesa likumu modeļa pieraksts Komponenti: Saites: <īss nosaukums> atbalsta/konfliktē(vāji/vidēji/stipri) <komponentes teksts> kavē VAI (OR)

26. Biznesa likumu modeļa paraugs

27. Ja iespējams, biznesa likumus vajadzētu izteikt sekojošā veidā: When {event} If {preconditions on entities} then {processes} 1. likums: When Check_for_delayed_books If Today - Loan.Return_day 28 then Report_customer_as_bad(Loan.Customer_ID) Kā formulēt biznesa likumus? (1)

28. Biznesa procesu modelis Mērķis: • Izmanto, lai definētu procesus organizācijā, kā tie savstarpēji mijiedarbojas, apietas ar informāciju, materiāliem. • Vispār Biznesa procesu modelis ir līdzīgs datu plūsmu diagrammām IS.

29. Biznesa procesu modeļa sastāvdaļas (1) Process ir aktivitāšu kopums, kurš: • “patērē” kādu informāciju vai materiālu un “izdod” informāciju vai materiālu • to nosaka noteikumu kopums, kas parāda kā apstrādāt informāciju/materiālus, kas ienāk un kā veidot, kārtot izejošo informāciju/materiālus • ir saistība ar aktieru un resursu modeli, ir piesaistītas atbildīgās personas un izpildītāji • tiek pieņemts, ka biznesa procesu modelis “patērē”, kad sākts realizēt noteiktu daudzumu resursu un laika

30. Biznesa procesu modeļa sastāvdaļas (2) • Ārējs process ir darbību kopums, kurš: • atrodas ārpus organizācijas darbības lauka, • saistās ar procesiem, kas ir attēloti modelī • ir svarīgi pilnvērtīgam situācijas atspoguļojumam • ārējie procesi dažreiz ir uzskatāmi gan par uzņēmuma informācijas vai materiālu plūsmas avotiem vai to saņēmējiem. Tipisks piemērs ārējam procesam var būt klients, kas pieprasa kādu bibliotēkas pakalpojumu vai saņem šo pakalpojumu. • Informācijas vai materiālu kopa, kas tiek nosūtīta no viena procesa uz otru vai arī no/uz ārēju procesu.

31. Biznesa procesu modeļa pieraksts Process: Plūsmas <īss nosaukums> Plūsma <procesa nosaukums> UN (AND) savienojums Ārējs process: VAI (OR)savienojums <īss nosaukums> <Ārējā procesa nosaukums> VAI (OR)šķēlums Informācijas vai materiālu komplekts <īss nosaukums> <nosaukums>

32. Biznesaprocesu modeļa piemērs

33. Aktieru un resursu modelis Mērķis: • tiek izmantots, lai aprakstītu kā dažādi aktieri un resursi, kas pieejami organizācijā, ir saistīti cits ar citu; • lai aprakstītu kā tie ir saistīti ar komponentiem mērķu modelī, biznesa procesu modelī un biznesa likumu modelī.

34. Aktieru un resursu modeļa sastāvdaļas • Subjekts ir persona vai organizācija. • Organizācijas nodaļa var būt jebkura organizācijas daļa – darba grupa, nodaļa, departaments, struktūrvienība, filiāle, utt. • Materiālie resursiir dažādas iekārtas, sistēmas, aprīkojums, utt. • Lomas kādas var būt Subjektiem un Organizācijas nodaļām dažādos kontekstos. Organizācijas nodaļas var būt, piemēram, administratora un pilnvarotā lomā tajā pašā kontekstā. Ir svarīgi identificēt prasības atkarībā no lomas, kas piešķirta.

35. Aktieru un resursu modeļa saistība • Atbildība ir saistība starp aktieriem, starp aktieriem un biznesa procesiem, biznesa likumiem un mērķiem. Atbildība ir deleģējama vai pārnesama starp dažādiem aktieriem.Atbildība var būt tāda, kas attiecas uz organizāciju, vai uz darbu. • Atkarība ir attiecība starp uzņēmuma aktieriem. Aktieris ir atkarīgs no kāda cita kaut kādā ziņā, kas var būt vai nu resurss vai biznesa process. Izšķir 2 veidu atkarību – darba vai pilnvaru.

36. Aktieru un resursu modeļa paraugs

37. Tehnisko komponenšu un IS prasību modelis Mērķis: • palīdzēt definēt prasības informācijas sistēmu izstrādei • vērst uzmanību uz nepieciešamo tehnisko sistēmu, kas nepieciešama, lai atbalstītu mērķu sasniegšanu, procesus un aktierus organizācijā. • definēt uzņēmuma darbības atbalsta informācijas sistēmas vispārējo struktūru un īpašības, tādas kā definētas biznesa procesu modelī. • lai izveidotu struktūru, kas sadalītu informācijas sistēmu vairākās apakšsistēmās (moduļos) vai tehnoloģiskajās komponentēs.

38. Tehnisko komponenšu un IS prasību modelis Sastāvdaļas: (1) • Informācijas sistēmas mērķis tiek izmantots, lai noteiktu informācijas sistēmas augsta līmeņa mērķus attiecībā uz informācijas sistēmu un/vai apakšsistēmām vai komponentēm. Tie ir izsakāmi kā mērāmās, tā arī nemērāmās īpašībās, mērķos, vīzijās, instrukcijās. • Informācijas sistēmas problēma tiek izmantota, lai noteiktu nevēlamus biznesa vai apkārtējās vides stāvoļus, problemātiskus faktus par doto situāciju attiecībā uz informācijas sistēmu, kuras izstrāde varētu sākties.

39. Tehnisko komponenšu un IS prasību modelis Sastāvdaļas: (2) • Informācijas Sistēmas Prasība nosaka prasības kādai noteiktai izstrādājamās sistēmas īpašībai. • Informācijas sistēmas funkcionālās prasības tiek izmantotas, lai izteiktu noteiktas prasības attiecībā uz funkcionālo informācijas sistēmas īpašību vai kādu no tās apakšsistēmām. Funkcionālajām prasībām ir jābūt skaidri definētām atbilstoši Jēdzienu modelim. Funkcionālās prasības tieši atbalsta informācijas sistēmas mērķus, taču funkcionālās prasības nereti tos papildina. • Informācijas sistēmas nefunkcionālās prasības tiek izmantotas dažādu prasību aprakstīšanai, ierobežojumiem, vai citu nefunkcionālo izstrādājamās sistēmas prasību aprakstīšanai

40. Dekompozīcija: UN (AND) VAI (OR) <1. IS mērķis> <1. IS mērķis> <2. IS mērķis> <3. IS mērķis> <3. IS mērķis> <2. IS mērķis> Tehnisko komponenšu un IS prasību modeļa pieraksts Komponente: Saites: <īss nosaukums> atbalsta/konfliktē(vāji/vidēji/stipri) <komponentes nosaukums> kavē

41. Tehnisko komponenšu un IS prasību modeļa paraugs

42. Saites starp modeļiem

43. Saites starp apakšmodeļiem • tiek izmantotas, lai saistītu dažādu apakšmodeļu komponentes • ir svarīgi saprast, kā organizācija darbojas kopumā • paskaidro komponentes, kas definētas apakšmodeļos

45. Par modeļu sarežģītību ”Visam ir jābūt tik vienkāršam cik vien iespējams …bet ne vienkāršākam!” AlbertsEinšteins