RAZVOJ IN VPELJAVA ORODJA ZA UPRAVLJANJE … · Razvoj in vpeljava orodja za upravljanje nestrukturiranih procesov Stran 6 Slika 2.1: Življenjski cikel v BPM pristopu Po pridobljenih

Tadej Zel

RAZVOJ IN VPELJAVA ORODJA ZA UPRAVLJANJE NESTRUKTURIRANIH

PROCESOV

Diplomsko delo

Maribor, avgust 2016

I

Diplomsko delo visokošolskega strokovnega študijskega programa Računalništvo in

informatika

RAZVOJ IN VPELJAVA ORODJA ZA UPRAVLJANJE NESTRUKTURIRANIH PROCESOV

Študent: Tadej Zel

Študijski program: VS ŠP Računalništva in informatike

Smer: Informatika

Mentor: doc. dr. Boštjan Šumak, univ. dipl. inž. rač. in inf.

II

III

ZAHVALA

Zahvaljujem se mentorju za pomoč in vodenje pri

izdelavi diplomskega dela.

Posebna zahvala velja tudi staršem, ki so mi

omogočili študij in punci, ki me je spodbujala pri

pisanju diplomskega dela ter pomagala z nasveti.

IV

RAZVOJ IN VPELJAVA ORODJA ZA UPRAVLJANJE

NESTRUKTURIRANIH PROCESOV

Ključne besede: Upravljanje nestrukturiranih poslovnih procesov, Adaptive Case

Management, ACM, Case Management Model and Notation,

CMMN

UDK: 004.4'2(043.2)

Povzetek

V diplomskem delu obravnavamo strukturirano upravljanje procesov in

nestrukturirano upravljanje primerov, ter razliko med tema dvema pristopoma.

Natančneje je predstavljena analiza in načrtovanje orodja Adaptive Case

Management, ki smo ga razvili v podjetju internetnega ponudnika, z namenom

obvladovanja nestrukturiranih primerov. Prav tako smo predstavili standard oziroma

notacijo za strukturirano BPMN in nestrukturirano CMMN oblikovanje procesov

oziroma primerov.

V

DEVELOPMENT AND INTRODUCTION OF A TOOL FOR

MANAGING NON/STRUCTURED PROCESSES

Key words: Manage unstructed business processes, Adaptive Case

Management, ACM, Case Management Model and Notation,

CMMN

UDK: 004.4'2(043.2)

Abstract

The thesis represents structured processes management and unstructured case

management, and the difference between these two approaches. The thesis represents

the analysis and design tools of Adaptive Case Management, which was developed in

the company of internet service provider in order to manage unstructured situations.

We also introduced the standard for structured process modeling BPMN and

unstructured case modeling CMMN.

VI

VSEBINA

1 UVOD ...................................................................................................................... 1

2 POSLOVNI PROCESI .......................................................................................... 3

2.1 UPRAVLJANJE POSLOVNIH PROCESOV ................................................................ 3

2.2 UPRAVLJANJE STRUKTURIRANIH PROCESOV – BASE PROCESS MANAGEMENT .. 4

2.2.1 Življenjski cikel v BPM pristopu ................................................................... 4

2.2.2 Standard Business Process Management Notation (BPMN) ....................... 6

2.2.3 Primer poslovnega procesa v BPMN ......................................................... 15

2.3 NESTRUKTURIRANI – DINAMIČNI PROCESI OZIROMA PRIMERI .......................... 16

2.4 ADAPTIVE CASE MANAGEMENT (ACM) ......................................................... 17

2.4.1 Kaj je upravljanje prilagodljivih, nestrukturiranih primerov .................... 17

2.4.2 Razlika med orodjem ACM in BPM ........................................................... 19

2.4.3 Upravljalci ACM ........................................................................................ 22

2.4.4 Baza znanja in »učenje« iz primerov .......................................................... 23

2.4.5 Kako organizacije trenutno upravljajo svoje primere? .............................. 24

2.4.6 Kaj je pri pristopu dinamičnega upravljanja dela bolje v primerjavi z

ostalimi orodji? ...................................................................................................... 25

2.4.7 Načrtovanje z delom “design by doing” .................................................... 27

2.4.8 Notacija oziroma kaj je CMMN (Case Management Modeling Notation)?28

2.4.9 Primer poslovnega procesa v CMMN ........................................................ 35

2.4.10 Zgodovina in razvoj ideje dinamičnega in nestrukturiranega upravljanja

primerov 36

3 OBVLADOVANJE PRIMEROV V PODJETJU PRED VPELJAVO

ORODJA CASE MANAGEMENT ............................................................................ 38

3.1 ELEKTRONSKA POŠTA ...................................................................................... 39

3.2 KOMUNIKACIJA PREKO IM ORODIJ (SKYPE, GOOGLE TALK/HANGSOUT) ........ 42

3.3 OSTALA ORODJA ZA VODENJE DELA ................................................................ 43

4 NAČRTOVANJE IN RAZVOJ ORODJA ......................................................... 45

4.1 PRISTOP K RAZVOJU ORODJA ........................................................................... 46

4.2 TEHNIČNE ZAHTEVE ........................................................................................ 48

VII

4.2.1 Implementacija poslovne logike ................................................................. 49

4.2.2 Implementacija uporabniškega vmesnika ................................................... 50

4.3 FUNKCIONALNE ZAHTEVE ............................................................................... 51

4.3.1 Vpis primera: .............................................................................................. 53

4.3.2 Status in pod-status primera ....................................................................... 54

4.3.3 Tip primera ................................................................................................. 57

4.3.4 Dostopnost primera (zasebni/javni) ........................................................... 57

4.3.5 Prioriteta primera ...................................................................................... 58

4.3.6 Značke (#tag) .............................................................................................. 59

4.3.7 Oznaka šablone (template) ......................................................................... 59

Povezava s stranko CRM ........................................................................................ 60

4.3.8 Povezava z ostalimi primeri ....................................................................... 60

4.3.9 Skrbniki ....................................................................................................... 60

4.3.10 Skrbniški oddelki .................................................................................... 61

4.3.11 Opazovalci .............................................................................................. 61

4.3.12 Naloge (Aktivnost primera) .................................................................... 63

4.3.13 Iskanje primera ....................................................................................... 66

4.3.14 Seznami primerov ................................................................................... 67

4.3.15 Pregled statistik ...................................................................................... 68

4.4 UPORABNIŠKI VMESNIK ................................................................................... 69

4.5 VLOGE UPORABNIKOV V ORODJU ACM ........................................................... 76

5 ZAKLJUČEK ....................................................................................................... 79

6 VIRI, LITERATURA ........................................................................................... 81

7 PRILOGE .............................................................................................................. 83

7.1 SEZNAM SLIK ................................................................................................... 83

7.2 SEZNAM TABEL ................................................................................................ 85

VIII

UPORABLJENE KRATICE

ACM Adaptive Case Management

BPM Business Process Management

BPMI Business Process Management Initiative

BPMN Business Process Model (and) Notation

CM Case Management

CMMN Case Management Model Notation

CRM Customer Relationship Management

DCM Dynamics Case Manegement

EPC Event-driven process chain

ISO International Organization for Standardization

OMG Object Management Group

UI User Interface

UX User Experience

UML Unified Modelin Language

VIP Very Important Person

WfMC Workflow Management Coalition

XML Extensible Markup Language

XPDL XML Process Definition Language

SQL Structured Query Language

Razvoj in vpeljava orodja za upravljanje nestrukturiranih procesov Stran 1

1 UVOD

Uporaba pristopov procesne usmerjenosti v organizacijah postaja uveljavljena praksa.

Procesno usmerjenost delimo tako na strukturirano Business Process Management (BPM),

kjer je pot izvajanja naprej definirana in znana ter na nestrukturirano oziroma delno

strukturirano Adaptive Case Management (ACM), kjer pot izvajanja ni naprej določena,

ampak jo določajo podatki, ki so v danem primeru.

Podjetja se vse pogosteje spopadajo z nepredvidenimi stroški in izzivi, ki jih prinašajo delno

strukturirani in nestrukturirani procesi. To so redko ponovljivi postopki.. Te obravnavane

dogodke tako imenujemo primeri (Case). Reševanje teh primerov praviloma zahteva

intelektualno delo, katerega ni možno enostavno predvideti in tako določiti vpletenih

akterjev, nalog in izvedbenih poti. Njihova izvedbena pot se ustvarja postopoma, na podlagi

rezultatov že izvedenih nalog, komunikacije, novih podatkov in pridobljenega znanja.

Brez primernega orodja se tovrstni procesi in primeri rešujejo z uporabo različnih

komunikacijskih kanalov, preko katerih si udeleženci dodeljujejo naloge in izmenjujejo

podatke. Pri tem prihaja do izgube podatkov in sledi reševanja, vpletanja napačnih ljudi in

izgube že pridobljenega znanja. Orodje za upravljanje dinamičnih procesov Adaptive Case

Management tako zajemajo BPM, CRM, ECM, BRM in domeno projektnega vodenja.

Orodje ACM tako zagotavlja infrastrukturo za bazo znanja, ki je ostali sistemi niso zmožni

podpreti, saj nimajo podpore za dinamične in nestrukturirane procese.

V diplomskem delu bomo tako predstavili poslovne procese. Predstavili bomo klasične,

strukturirane poslovne procese, kako delujejo in kakšen je njihov standard za modeliranje.

Nato se bomo dotaknili njihovih pomanjkljivosti pri opravljanju dinamičnega in

nestrukturiranega dela. V naslednji točki bomo predstavili nestrukturirano upravljanje

primerov, kje so njihove prednosti in spoznali orodje Adaptive Case Management. Primerjali

bomo svetova strukturiranega in nestrukturiranega upravljanja. Spoznali bomo elemente

notacije za zapis in modeliranje nestrukturiranih primerov, in poiskali podobnosti s

standardom za strukturirane procese. V drugem delu diplomske naloge bomo predstavili

situacijo, s katero smo se pred vpeljavo orodja Adaptive Case Management srečevali v

našem podjetju, težave, ki smo jih imeli in kako smo poiskali rešitev ter prišli do ideje za


razvoj orodja. V zadnjem delu diplomskega dela se bomo posvetili analizi, načrtovanju in

razvoju orodja, ki smo ga razvili za obvladovanje nestrukturiranega dela v našem podjetju.


2 POSLOVNI PROCESI

Poslovni proces ali poslovna metoda je zbirka povezanih strukturiranih aktivnosti oziroma

opravil, ki zagotavljajo določeno storitev ali produkt (doseči določen cilj) za določene

naročnike. Pogosto je prikazan kot diagram aktivnosti z zaporednimi odločitvami ali kot

proces sekvenčnih matrik aktivnosti s pravili, ki slonijo na podatkih v procesu [1].

2.1 Upravljanje poslovnih procesov

Upravljanje poslovnih procesov je v podjetju oziroma organizaciji zelo pomemben proces.

V današnjem času je boj s konkurenco veliko ostrejši, zato je zelo pomembno, da podjetje

hitro reagira na konkurenco in s tem učinkovito odgovori na stanje, ki je v danem trenutku

na trgu.

Upravljanje poslovnih procesov ne pomeni samo načrtovanje poslovnega procesa in

izvajanje le tega. Zastavljenemu poslovnemu procesu ne moremo samo slepo slediti, ampak

ga je potrebno ves čas nadzirati, spreminjati in meriti, ter posledično prilagajati na stanje

trga. Kvalitetneje te stvari izvajamo, bolj je podjetje prilagojeno trgu, boju s konkurenco in

posledično uspešnejše je poslovanje. S takšnim upravljanjem poslovnih procesov skrbimo

za optimalno delovanje podjetja oziroma organizacije v danem trenutku.

Upravljanje in spreminjanje poslovnih procesov pa ni edina stvar, ki jo moramo spreminjati

in prilagajati. Tako kot se spreminja in optimizira proces se spreminjajo tudi drugi viri

»resources« v poslovnem procesu. Zraven sistemov, ki so vpleteni v proces so tukaj tudi

akterji, oziroma ljudje, ki ves čas izvajanja procesa dobivajo nova znanja in prakse. Tako

imamo zraven upravljanja in spreminjanja poslovnih procesov še drugo pomembno nalogo.

Ta naloga je, poznavanje oddelkov, ljudi, ki upravljajo te procese in naloge, in znanja teh

ljudi, njihove sposobnosti in izkušnje. Na ta način lahko ljudi primerno vključujemo v

procesne aktivnosti in opravila znotraj poslovnih procesov.

Za potrebe modeliranja poslovnih procesov se je razvilo več tehnik modeliranja; kot so

diagram poteka (flowchart), Pertijeve mreže (Petrines), EPC (Event-driven process chain),

diagram toka podatkov, UML (Unified Modelin Language), BPMN (Business Process


Model and Notation) in tehnika CMMN (Case Management Model Notation). Večina teh

orodji je namenjena abstraktnemu modeliranju procesov. Prav to abstraktno modeliranje pa

je privedlo do razvoja standarda BPMN in nato standarda CMMN, ki nekako dopolnjuje in

razširja BPMN [3].

Namen večine orodij za modeliranje poslovnih procesov ni samo v tem, da jih razumejo tisti,

ki jih modelirajo, oziroma ljudje na vodstvenih položajih, temveč so namenjeni vsem

vpletenim akterjem [4].

2.2 Upravljanje strukturiranih procesov – Base Process Management

Definicija upravljanja poslovnih procesov - Business Process Management (BPM) je nastala

skupaj z večjimi združenji (Workflow Management Coalition (WfMC), BPM.com,…) in se

glasi: BPM je disciplinirano vključevanje modeliranja, avtomatizacije, izvajanja,

upravljanja, merjenja in optimiziranja poslovnih aktivnosti, in služijo kot podpora poslovnim

ciljem, vpletenih sistemov, zaposlenih, strank in partnerjev zunaj poslovnih meja [2].

Tradicionalni pristop modeliranja procesov je načrtovanje in implementiranje procesa. S

pristopom kot je v orodju BPM pa je pristop modeliranja postavljen na višji nivo. V ta namen

imamo v orodju BPM pristop ponavljajočega se življenjskega cikla [5].

V tem življenjskem ciklu ves čas skrbimo, da poslovni proces izboljšujemo, merimo in

optimiziramo, saj s tem zagotavljamo optimalno delovanje podjetja oziroma organizacije.

2.2.1 Življenjski cikel v BPM pristopu

Kadar govorimo o upravljanju poslovnih procesov po pristopu BPM, poznamo pet

življenjskih ciklov (modeliranje, implementacija, izvajanje, spremljanje, opazovanje in

optimizacija). Življenjski cikli poslovnega procesa se tako ves čas ponavljajo, od prvega

modeliranja naprej, kot prikazuje spodnja slika [Slika 2.1]. S tem pa se ne izboljšujejo le

poslovni procesi, ampak delo celotne organizacije v kateri nastopajo [5].


Življenjski cikli:

- Modeliranje:

Prvi korak v življenjskem ciklu poslovnega procesa. Model, ki se oblikuje, je

abstrakten. Za načrtovanje se uporabi notacija BPMN, UML ali katera druga

modelirna tehnika.

- Implementacija:

Je korak v katerem definiramo vse potrebne podatke za implementacijo, tako da

proces postane izvedljiv.

- Izvajanje:

Poslovni proces imamo modeliran in implementiran, tako ga v tem koraku začnemo

izvajati v poslovnem okolju.

- Spremljanje in opazovanje:

Korak poteka ves čas izvajanja, tako da merimo učinkovitost izvajanja, najdemo

potencialne grožnje oziroma ozka grla, odvečne aktivnosti, pomanjkljive aktivnosti

in stvari, ki lahko izboljšajo poslovni proces.

- Optimizacija:

Vse stvari, ki smo jih zasledili kot šibkost ali pomanjkljivost poslovnega procesa,

poskusimo v tem koraku izboljšati.


Slika 2.1: Življenjski cikel v BPM pristopu

Po pridobljenih izkušnjah je življenjski cikel velikokrat zanemarjen ali počasen, kar v praksi

pripelje do tega, da se veliko procesnih aktivnosti preseli na druga orodja, preko katerih se

akterji obveščajo, komunicirajo in dodeljujejo »ročna« in ad-hoc opravila. Tako velikokrat

pridemo iz strukturiranega procesa v svet nestrukturiranih procesov ali primerov (več o

nestrukturiranih primerih v naslednjem poglavju in v razvoju naše aplikacije), saj uporabniki

s svojimi izkušnjami in znanjem začnejo sami z določeno optimizacijo poslovnega procesa.

2.2.2 Standard Business Process Management Notation (BPMN)

Standard Business Process Model Notation (BPMN) je postal vodilni standard za

modeliranje in upravljanje poslovnih procesov po BPM pristopu. Standard pokriva grafični

prikaz poslovnega procesa in omogoča implementacijo z IT sistemi. Standard, ki se je

razvijal v zadnjih letih, je sedaj, oziroma od leta 2005 pod okriljem konzorcija Object

Management Group (OMG), pred tem je razvoj začela in vodila iniciativa Business Process

Management Initiative (BPMI). Prikaz razvoja in povezav standarda BPMN, XPDL in

CMMN je prikazan v časovnici na spodnji sliki [Slika 2.2].


Tako je bil standard BPMN izdan v večih verzijah. Prva verzija BPMN 1.0 je bila izdana

leta 2001. Deset let kasneje, januarja 2011 pa kot BPMN 2.0, ki ga je International

Organization for Standardization (ISO) leta 2013 registriral kot standard ISO/IEC

19510:2013 [4].

Slika 2.2: Časovnica razvoja standarda BPMN


Kot smo že omenili je ena izmed pomanjkljivosti večine modelirnih tehnik prav preslikava

v izvajalno logiko. Ta pomanjkljivost je bila odpravljena pri izdaji verzije BPMN 2.0.

Povezavo med grafičnim svetom, kot ga vidimo v [Slika 2.3] in izvajalnim svetom je

omogočil standard XPDL, ki je prikazan v [Koda 2.1] in je bil razvit s strani Workflow

Management Coalition (WfMC). Tako ima standard BPMN definiran meta-model in

preslikavo v XPDL oziroma XML format, ki opisuje, kako se proces preslika v logično

izvedljivo kodo [2].

Standard XML – Process Definition Language (XPDL) je preprost XML dokument, v

katerem je možno shraniti in tako izmenjevati BPMN diagrame. Zasnovan je tako, da hrani

vse grafične elemente, kot tudi postavitev teh elementov (x,y koordinate elementov) [Koda

2.1]. Tako lahko rečemo, da je XPDL serializacija BPMN standarda [7].

Za predstavitev BPMN notacije in preslikave v XPDL zapis, smo uporabili preprost proces

[Slika 2.3] štirih aktivnostih in vejitve.

Slika 2.3: Primer BPMN aktivnosti (vir: http://www.omg.org/spec/BPMN/2.0.2/


Koda 2.1: Primer serializirane BPMN aktivosti v XPDL zapisu (vir: http://www.omg.org/spec/BPMN/2.0.2/)

2.2.2.1 Notacija v BPMN 2.0

Pri notaciji je potrebno poudariti, da je eden od gonilnikov razvoja standarda BPMN kreirati

preprost in razumljiv mehanizem za kreiranje modelov poslovnih procesov. Pri tem mora

biti omogočeno obvladovanje dedovanj kompleksnih poslovnih procesov. Ta pristop pa

zahteva obvladovanje konfliktov, ki se pojavijo v preslikavi iz grafičnega vidika notacije v

specifične kategorije elementov, ki služijo izvajanju. Obvladovanje tega konflikta zagotavlja

majhen nabor kategorij notacij – elementov, tako lahko v generiranem BPMN diagramu z

lahkoto prepoznamo tipe elementov in razumemo diagram. V te preproste kategorije

<Activities>

<Activity Id="3" Name="a1"/>

<Activity Id="4" Name="g1">

<Route GatewayType="Exclusive" MarkerVisible="TRUE"/>

<TransitionRestrictions>

<TransitionRestriction>

<Split Type=" Exclusive ">

<TransitionRefs>

<TransitionRef Id="9"/>



</TransitionRefs>

</Split>

</TransitionRestriction>

</TransitionRestrictions>

</Activity>




</Activities>

<Transitions>

<Transition Id="8" Name="" From="3" To="4" FlowType="SequenceFlow"/>

<Transition Id="9" Name="" From="4" To="5" FlowType="SequenceFlow">

<Condition Type="CONDITION">a<b</Condition>

</Transition>


<Condition Type="CONDITION">a>b</Condition>

</Transition>


<Condition Type="OTHERWISE"/>

</Transition>

</Transitions>


oziroma tipe elementov lahko dodamo informacije za podporo kompleksnih zahtev brez

dramatičnih sprememb osnovnega pregleda diagrama. Tako obstajajo štirje osnovni tipi

elementov v notaciji BPMN (Task, Getway, Start in End Event) [4].

Predstavili bomo samo nekaj osnovnih elementov, nekateri izmed njih se navezujejo in imajo

podobnosti z elementi CMMN standarda (nestrukturiranega načrtovanja), o katerem bomo

govorili v naslednjih poglavjih.

BPMN elementi [4]:

- Event (dogodek)

Dogodek je nekaj, kar se zgodi na začetku, med potekom in na koncu procesa.

Dogodki vplivajo na potek modela in so ponavadi kot prožilci, ki imajo vpliv na

rezultat. Obstajajo trije tipi dogodkov, ki se razlikujejo po tem, kje v procesu se

pojavljajo (začetek, konec ter vmesni dogodki) [Tabela 2.1].

Event (dogodek) ima tako podobno vlogo kot Event Listener (poslušalec dogodkov)

v CMMN notaciji.

Tabela 2.1: BPMN elementi dogodkov

StartEvent – začetna oblika dogodka

IntermediateEvent – vmesna oblika

dogodka

EndEvent – končna oblika dogodka

(vir: http://www.omg.org/spec/BPMN/2.0.2/)


- Activity/Task (Aktivnost)

Aktivnost je generičen izraz za neko potrebno delo ali aktivnost, ki se opravi znotraj

procesa. Aktivnost je lahko avtomatska, ali ne avtomatska oziroma ročna. Tako so

lahko tipi aktivnosti tudi podprocesi ali naloge [Tabela 2.2].

Activity/Task (Aktivnost) ima podobno vlogo kot Task (Opravilo) v CMMN

notaciji.

Tabela 2.2: BPMN elementi aktivnosti

Activity/Task – oblika aktivnosti

Sub-Proces – oblika pod-proces

Ločeno modeliran proces, v vlogi

aktivnosti.


- Getway (Prehod oziroma vejitev):

Prehodi se uporabljajo za razdruževanje in združevanje toka procesa. Tako določamo

poslovno logiko, s katero peljemo tok procesa. Notranji prehodi krmilijo izvajanje

procesa. V standardu imamo definiranih več tipov vejitev, od klasičnih krmilnih po

pogoju, do kompleksnih in ločitvenih na več vej procesa [Tabela 2.3].

V CMMN notaciji jih kot samostojne elemente ne uporabljamo, saj so v večini

združeni z drugimi elementi. V večini primerov tako nastopajo z aktivnostmi, kjer

določajo vstopne in izstopne pogoje.


Tabela 2.3: BPMN elementi vejitev

ExclusiveGetway – oblika klasične

vejitve (prvi ustrezen pogoj se izvede)

Inclusive Getway – oblika vejitve

(izvedejo se vsi izpolnjeni pogoji)

Complex Getway – oblika kompleksne

vejitve

Parallel Getway – oblika vzporedne

vejitve


- Sequence Flow (Tok zaporedja):

Zaporedje toka se uporablja za prikaz zaporedja aktivnosti, ki se izvajajo v procesu.

Lahko je predstavljen kot normalen tok, kar pomeni da povezuje elemente med seboj

in ponazarja smer izvajanja procesa. V standardu sta definirana še Conditional Flow

(pogojni tok), kateri ima na začetku postavljen pogoj za izvajanje toka in Default

Flow (privzeti tok), ki predstavlja privzeto pot izvajanja v primeru neizpolnjenega

pogoja. Oba tipa toka izhajata iz elementa Getway (vejitve) [Tabela 2.4].

Sequence flow (Tok zaporedja) ima podobno vlogo kot Links/Connectors

(povezava) v notaciji CMMN, vendar so tam te povezave brez usmeritev in

prikazujejo samo povezave oziroma asociacije med elementi. Prav tako pa tudi tam

srečamo pogoje (Conditionals), ki pa niso del povezav, ampak so na vhodih in

izhodih iz aktivnosti, kot smo omenili že v prejšnji točki.


Tabela 2.4: BPMN elementi toka zaporedja

Sequence Flow (Normal) – oblika

elementa za tok zaporedja

Conditional / Default Flow – oblika

elementa toka zaporedja


- Swimming Pool / Pool (Plavalna pot / Bazen):

Bazen je grafična predstavitev udeležencev v nekem sodelovanju. Predstavljen je kot

plavalna pot, ki deli aktivnosti na druge bazene [Tabela 2.5]. Ločeni bazeni oziroma

plavalne poti ponavadi predstavljajo B2B situacijo. Bazen lahko ima interne

informacije o procesu, ki se izvaja ali pa teh informacij nima, in deluje kot črna

skrinja (black box).

Lahko bi rekli, da je povezava med elementom Pool in elementom Case Model Plan

v notaciji CMMN. Oba elementa združujeta aktivnosti in druge elemente v skupine.

Razlika je v tem, da je elementov v bazenu lahko več, lahko pa je bazen brez

elementov (kot black box). Case Model Plan v CMMN pa ima v osnovi vsaj en ali

več elementov, in predstavlja celoten primer reševanja.

- Lane (Steza / pas):

Steza oziroma pas je pregrada – ločnica v procesu ali v bazenu (pool), in je razširjena

po celotni dolžini in širini procesa [Tabela 2.5]. Pasi se uporabljajo za organizacijo

in kategorizacijo aktivnosti. S stezo ponavadi želimo ponazoriti različne oddelke ali

skupine znotraj podjetja.

Lahko bi rekli, da je povezava med elementom Lane in elementom Stage (faza /

stanje) v notaciji CMMN. Oba elementa združujeta aktivnosti in druge elemente v

skupine. Razlika pa je v tem, da steza predstavlja vedno enak oddelek skozi celoten

proces, faza oziroma stanje v CMMN, pa se lahko znotraj primera zaključi poljubno,

ali se sploh ne uporabi.


Tabela 2.5: BPMN element bazena in steze

Pool – oblika elementa za bazen

Lane – oblika elementa za pas


- Ostali elementi v standardu BPMN notacije:

o Data Object (Podatkovni objekt):

Podatkovni objekt zagotavlja informacije, ki jih aktivnosti potrebujejo,

posredujejo ali ustvarijo. Podatkovni objekti so lahko samostojni objekti ali

množica objektov. Vhodni in izhodni podatki zagotavljajo vedno enake

informacije za izvajanje procesa.

o Message (Sporočilo):

Sporočilo se uporablja za prikazovanje komunikacije med dvema

udeležencema.

o Group (Skupina):

Skupina pomeni skupek grafičnih elementov, ki so skupaj v isti kategoriji

(elemente v toku procesa lahko označimo kot strankini elementi, podporni

elementi itd.…). Skupina ne vpliva na zaporedje toka v skupini. Namen

skupine je, da jih lahko uporabljamo za dokumentiranje ali analiziranje.

Skupine so eden od načinov, s katerimi lahko vizualno kategoriziramo v

diagramu.


o Text Annotation (Tekstovna oznaka):

Besedilni zapis je mehanizem za zapis dodatnega teksta, ki služi kot

informacija pri branju diagrama.

2.2.3 Primer poslovnega procesa v BPMN

Za primer poslovnega procesa smo uporabili preprost poslovni proces za vklop

elektronskega naslova, modeliran po standardu BPMN 2.0 [Slika 2.4].

Potek poslovnega procesa za vklop – kreiranje elektronskega naslova:

- Uporabnik vpiše podatke, kot so: elektronski naslov, uporabniško ime in geslo.

- Sistem preveri ustreznost podatkov (prost elektronski naslov, pravilen elektronski

naslov, prosto oziroma pravilno uporabniško ime in ustreznost gesla).

- Na podlagi prejšnje aktivnosti, vejitev usmeri tok procesa v ustrezno naslednjo

aktivnost:

o vrnitev – podatki niso pravilni, preusmeritev na ponoven vpis podatkov,

o nadaljevanje – podatki so pravilni, kreacija elektronskega naslova na

strežniku.

- Sistem na strežniku ustvari nov elektronski naslov.

- Sistem preveri, ali je naslov ustvarjen pravilno (vpliv drugih procesov za upravljanje

elektronskih naslovov – »ukraden« elektronski naslov ali uporabniško ime s strani

drugih vzporednih procesov).

- Na podlagi prejšnje aktivnosti, vejitev usmeri tok procesa v ustrezno naslednjo

aktivnost:

o vrnitev – podatki niso več ustrezni, preusmeritev na ponoven vpis,

o nadaljevanje – podatki so pravilni, obveščanje naročnika.

- Uporabnik obvesti naročnika o podatkih novega elektronskega naslova.

- Proces se zaključi.


Slika 2.4: Primer poslovnega procesa: ustvarjanje el. naslova v notaciji BPMN 2.0

2.3 Nestrukturirani – dinamični procesi oziroma primeri

V današnjem svetu ni ali je zelo malo tolerance za nepovezane pristope v delu. To velja tako

za ljudi, ki delo opravljajo, kot za ljudi za katere se delo opravlja. Dinamično vodenje

primerov tako postaja standard za upravljanje dela v organizaciji. Najpomembnejši cilj

dinamičnega upravljanja primerov je upravljanje vsega dela, ki je potrebno za obvladovanje,

oziroma obravnavo določene zadeve, ne glede na tip dela. Delo je tako lahko izvedeno preko

sistema avtomatsko ali ne avtomatsko – ročno. Ne avtomatsko se uredi preko ljudi, ad-hoc

in je lahko vezano samo na eno ali nekaj instanc določenega tipa dela.

V kolikor je to dinamično okolje v celoti sprejeto ali podprto, se ustvari prepletena mreža,

ki kot rezultat odseva dinamično okolje v katerem nastopa [8].


2.4 Adaptive Case Management (ACM)

Adaptive Case Management (ACM) je bil razvit v zadnjih letih kot definicija, metodologija

in orodje. Preprosta in formalna definicija, ki jo je predstavil Workflow Management

Coalition (WfMC) za pristop oziroma orodje ACM je:

Adaptive Case Management (ACM) je informacijska tehnologija, ki izpostavlja

strukturirane in nestrukturirane poslovne informacije (podatke in vsebine), in omogoča

strukturiranim poslovnim in nestrukturiranim socialnim organizacijam opravljati delo. Delo

je lahko rutinsko in procesno (v nastajanju), na varen vendar transparenten, pregleden način

[16].

2.4.1 Kaj je upravljanje prilagodljivih, nestrukturiranih primerov

Primer (Case) je usklajevanje večih opravil (planiranih in ne planiranih) za določen namen,

doseči zastavljen cilj. Primer oziroma instanca primera vsebuje podatke o točno določeni

instanci, zadevi oziroma primeru. Podatki se vključujejo v primer kot artefakte vsebine, ki

so potrebne za obdelavo primera ali se generirajo skozi obdelavo primera. Skoraj vse kar

obravnavamo lahko tretiramo kot primer [8].

Tako je orodje Adaptive Case Management podmnožica, definirana kot koncept

prilagodljivih procesov, ki zajema tudi Business Process Management (BPM), Customer

Relationship Management (CRM), Enterprise Content Management (ECM), Business

Relationship Management (BRM) in domeno projektnega upravljanja, kot je prikazano na

spodnji sliki [Slika 2.5]. Orodje ACM, tako zagotavlja infrastrukturo za delo z bazo znanja,

ki jo trenutni sistemi ne morejo podpreti, saj so ti primeri oziroma procesi preveč dinamični,

variabilni in nestrukturirani za ostala klasična orodja [9].


Slika 2.5: Prilagodljivi procesi

Orodje ACM je potrebno za procese oziroma primere, kateri [9]:

so nepredvidljivi v izvajanju,

slonijo na neznanih dogodkih,

potrebujejo akcije z nepredvidljivimi posledicami,

zahtevajo vključevanje ad-hoc akterjev in nalog,

uporabljajo akterjevo znanje, ki ga ni mogoče vgraditi v pravila in tok procesa,

imajo procese z nepoznanimi vhodnimi in izhodnimi vsebinami,

omogočanje vključevanja poslovnih uporabnikov, ki dodajajo pravila kadarkoli v

času izvajanja,

imajo potrebo po seznanitvi določenega akterja o določenem rezultatu,

imajo zahtevo po popolni transparentnosti in preglednosti procesa.


Prilagodljivo upravljanje primerov (ACM) je podmnožica razširjenih procesov in tako širi

BPM.

Funkcionalna definicija orodja ACM (glavnega arhitekta ISIS Papyrus - Max J. Pucher) [19]:

Orodje ACM je produktiven sistem, ki ne razvija samo organizacijo in procesne

strukture, ampak preko zalednih sistemov postane sistem zapisov za poslovne

podatkovne entitete in vsebine, ki v njem sodelujejo. Vsi procesi so v celoti

transparentni in preverljivi.

Orodje ACM omogoča ne tehničnim poslovnim uporabnikom ustvariti in utrditi

nestrukturirane procese iz osnovnih predefiniranih poslovnih entitet, vsebine,

socialno interakcijo in poslovna pravila brez načrtovanja toka procesnega diagrama.

Orodje ACM premakne naraščajočo bazo znanja v življenjski cikel iz

analiz/modeliranja/simuliranja (kot je to v BPM pristopu) v proces izvajanja. Orodje

ACM zbira znanja od poslovnih uporabnikov brez vmesnih faz analiz.

2.4.2 Razlika med orodjem ACM in BPM

Tako ACM kot BPM orodje se uporablja za pomoč zaposlenim v podjetjih ali organizacijah

za boljše koordiniranje, boljše in hitrejše doseganje ciljev, s katerimi zadovoljijo potrebe

svojih strank in olajšajo delo svojim zaposlenim.

Tako ACM kot BPM orodje vključuje podatke, procese, pravila, komunikacijo, integracijo

in analitiko.

Orodji ACM in BPM pa imata zelo drugačen pristop do dela, ki je učinkovito v različnih

poslovnih situacijah. BPM se približuje problemu z izboljševanjem dela v organizaciji, z

velikim poudarkom na procesih. Tako je prva stvar na katero pomislimo pri orodju BPM,

proces. Procesi se tako definirajo na točno določen način, in sicer, ali sta dva primera med

seboj podobna, ali se med seboj razlikujeta.

Podatkovni tok pri orodju BPM gre tako v proces in iz njega, kot je prikazano v spodnji sliki

[Slika 2.6]. Proces predstavlja cilj določenega zaporedja akcij, vendar cilj ni sam po sebi vir

podatkov. Procesna instanca vsebuje svoje podatke kot tudi aplikacijske podatke, vendar na


splošno prevzema podatke, ki so zunaj procesa in so med instancami drugačni. Glavna ideja

orodja BPM je povezovanje z zunanjimi viri podatkov, ki gredo vedno skoz enak proces do

cilja [10].

Slika 2.6: BPM proces upravlja s podatki (vir: http://www.xpdl.org/nugen/p/adaptive-case-management/public.htm)

Orodje ACM prav tako poskuša izboljšati delovanje organizacije, vendar je tukaj namesto

procesa, podatek primarnega pomena [Slika 2.7]. Razvoj procesa se prilagaja podatkom,

pridobljeni podatki pa tako postanejo baza znanja za podobne primere [10].

Slika 2.7: Podatki v ACM upravljajo s procesi reševanja (vir: http://www.xpdl.org/nugen/p/adaptive-case-management/public.htm)


Razvije se lahko tudi v obliki procesa, vendar se ta oblikuje na primeru in teče v kontekstu

s primerom, na obratni način kot pri orodju BPM [10].

2.4.2.1 Razlika med procesom in primerom

Osnova razlika:

Primer je določeno delo, ki ga je potrebno narediti.

Proces je ena ali več poti s katerimi zaključimo primer.

Vsi primeri imajo vsaj en proces, čeprav ta ni načrtovan. To drži v vseh primerih, tudi če je

prvi tip primera obravnavan kot uporabnikovo ročno delo. Uporabnik oziroma oseba, ki je

izvajalec procesa, se odloča kakšno delo bo opravil na primeru.

Proces in primer sta neodvisna drug od drugega. To je ena izmed ključnih razlik med

dinamičnim upravljanjem primerov v orodju ACM in tradicionalnim upravljanjem procesov

v orodju BPM. Tradicionalni proces v orodju BPM je skoraj vedno primer – ne obstaja brez

primera.

Ta ločitev primera in procesa je glavni razlog, zakaj je orodje za upravljanje dinamičnih

primerov tako močno orodje. Z ločevanjem teh dveh konceptov omogočamo celovito

upravljanje primerov. S tem omogočamo, da ima primer več izvedljivih procesov

(zaporednih ali vzporednih), prav tako lahko ima več pod-primerov, kateri imajo lahko več

izvedljivih procesov. Vsebina primera narekuje procese, ki podpirajo primer. V primeru se

sprememba vsebine primera lahko odraža na spremembi procesa, s katerim se izvaja primer.

Tako se mora proces prilagoditi spremembam na primeru ali sprožiti nov proces, ki bo

obvladoval nastalo oziroma spremenjeno situacijo na primeru. S pristopom upravljanja

dinamičnih primerov so tako vsi procesi tesno povezani s primerom in s pod-primeri ter

njihovimi procesi.

Namesto obravnave dela z večimi invidualnimi (ločenimi) procesi, dinamično upravljanje

primerov omogoča, da dobimo celosten pogled na delo, ki je bilo izvedeno na samem

primeru. Tako dobimo jasen pregled na celoten primer (in njegove pod primere), saj je to

delo organizirano v smiselnih enotah znotraj primera [8].


Ključna razlika med procesnim upravljanjem in upravljanjem primerov je prikazana v tabeli

[Tabela 2.6].

Tabela 2.6: Procesno upravljanje in upravljanje primera

Procesno upravljanje Upravljanje primera

Fokus Delo na trenutni aktivnosti Delo na celotnem primeru

Primarni pogon Delo na trenutni aktivnosti Podatki primera

Ločeni podatki primera in

procesa DA NE

Ločena avtorizacija in

distribucija NE DA

Tipi asociacij na

aktivnostih, nalogah Izvajanje po toku

Izvajanje, Preskoki,

Ponovitve

2.4.3 Upravljalci ACM

Težko je definirati osebe, ki delajo na primeru, saj ni mogoče naprej določiti, kdo točno bo

vpleten v delo nekega primera. Najbolje je, če rečemo, da lahko na primeru dela kdorkoli.

Najboljši način razumeti delovanja orodja ACM je, da razmišljamo tako: vsak oddelek ali

skupina ima svoje področje upravljanja (svojo bazo znanja), specializacijo. Različni ljudje

imajo različne nivoje vpletenosti v primere in tipi primerov določajo, kdo je vpleten in v

kakšni kapaciteti. Prav tako lahko v primeru nastopa sistem, ki hrani, zagotavlja ali obdeluje

podatke primera [8].

Kot je bilo omenjeno so v primeru vpleteni izvajalci, ki imajo določena znanja. Tako se

izvajanje procesa v orodju ACM oziroma dinamičnem upravljanju primerov proces izvajanja

zaupa vpletenim akterjem (specialistom na svojem področju), kar je še ena izmed razlik v

primerjavi s strukturiranim pristopom, kjer vlogo načrtovanja procesa prevzamejo poslovni

analitiki. Izvajanje primerov tako temelji na spoznanjih, ki jih je izrekel Peter Drucker: »You

can't manage knowledge. Knowledge is between two ears and only between two ears.«.


Peter Drucker je bil avstrijsko-ameriški svetovalec managementa, pedagog in avtor, katerega

pisanje je prispevalo k filozofskim in praktičnim temeljem modernih korporacij.

Razvoj procesa ali primera je kot se omenja odvisen od samih akterjev oziromanjihovih

odločitev, s katerimi ustvarjajo aktivnosti. Da se aktivnosti ustvarijo in da lahko začnemo z

izvajanjem primera ali procesa, potrebujemo definicijo primera. Definicija primera pomeni,

da imamo izbrane cilje oziroma probleme, ki jih želimo rešiti skozi primer. Tako primer brez

ciljev ne obstaja, saj brez njih ni mogoče ustvariti aktivnosti [11].

Kadar govorimo o »strankinih« oziroma »naročniških« primerih, je zelo pogosto zaključeno

delo prikazano kot naročniški nivo. Večino tega dela je opravljenega s strani avtomatiziranih

procesov, ki jih sproži naročnik. Vendar v primeru, ko naročnik pokliče v servisni center, se

nadaljnje delo na primeru prikaže kot delo z različnimi sistemi in ljudmi, ki nato delajo na

primeru [8].

2.4.4 Baza znanja in »učenje« iz primerov

S količino obdelave primerov se širi baza znanja. Tako dobimo na podlagi večjega števila

podobnih primerov uporabne informacije, ki nam služijo pri ostalih oziroma novih podobnih

primerih. Ključna pridobljena prednost teh informacij je uporabniški oziroma akterjev čas

in trud, ki se uporablja pri reševanju primerov. Ni pa ta prednost edina, ki jo lahko pridobimo

na podlagi podobnih primerov. Z obdelavo podobnih primerov pridobimo dobre prakse

reševanja v posamičnih domenah primera. Tako tudi širimo znanja in izkušnje uporabnikov,

ki lahko na tak način razumejo, kako se zadeve rešujejo, saj ne izvajajo samo načrtovanih

aktivnosti, ki jih je načrtoval poslovni analitik. Tako na podobnih primerih identificiramo

vzorce uporabljenih procesov, izvedenih nalog, uporabljenih artefaktov, vpletenih ljudi,

generiranih aktivnosti, ter razprav in interakcij skozi primer.

Te informacije lahko orodje zajamejo v formo procesne šablone (case template), ki

zagotavlja najboljšo prakso in smernice, kako izvajati delo v posamičnih domenah primera,

in s tem omogočati boljše razumevanje poslovnega vodstva, skrbnikov procesov in kot že

omenjenih vpletenih uporabnikov oziroma akterjev.


S šablonami lahko na ta način podobne primere identificiramo. Na podlagi identificiranih

primerov orodje uporabniku svetuje in omogoča primerjavo s trenutnimi primeri (na katerih

uporabnik trenutno dela). Prav tako lahko uporabniki z lastnim odločanjem vplivajo na

izboljšanje teh šablon [8].

2.4.5 Kako organizacije trenutno upravljajo svoje primere?

Odgovor na to vprašanje je odvisen od tega, kako organizacije definirajo svoje primere. V

kolikor je kot primer definirano vso delo, potrebno za obdelavo neke zadeve, potem je

odgovor, da večina organizacij upravlja različne dele primerov v različnih sistemih in je

večina dela opravljenega ročno. To pomeni, da je delo opravljeno zunaj sistemov, ki bi

dokumentirali proces dela. V veliko primerih to pomeni uporabo elektronske pošte,

telefonskih pogovorov in ostalih nepovezanih sistemov.

Naslednji graf [Graf 2.1] prikazuje rezultate ankete, ki so jo opravili v "Pagesystem of IT" z

večino direktorjev – "Fortune 1000" (združenje večjih podjetij v ZDA) z vprašanjem: "Kako

upravljate svoje primere?”


Graf 2.1: Kako podjetja upravljajo svoje primere

Od tukaj izhaja pomembnost razumevanja, kako upravljati delo na višji ravni – na ravni

primera. Ta trend se z 41 odstotki vprašanih kaže, da za upravljanje svojih primerov

uporabljajo več aplikacij oziroma sistemov, vendar trenutno nobena aplikacija ne ustreza

namenu, da bi omogočala točno to [8].

2.4.6 Kaj je pri pristopu dinamičnega upravljanja dela bolje v primerjavi z ostalimi

orodji?

Pristop dinamičnega upravljanja primerov je fokusirano na vso delo, ki je potrebno za

obvladovanje določene zadeve ne glede na način obdelave (procesi, ročno, ad-hoc,...),

medtem kot so ostala orodja za upravljanje dela fokusirana samo na določene dele primera.

Tako pridemo do ugotovitve, da tradicionalne rešitve upravljanja primerov v celoti ne

ustrezajo modernim organizacijam. Organizacije tako iščejo orodja za upravljanje primerov,

ki omogočajo upravljanje vsega dela na primeru, ne glede na to kako široko ali ozko so

Več razlčnih aplikacij, 41%

Ročno, 33%

Razvite aplikacije, 25%

Kupljene aplikacije, 14%


definirani procesi. Tako dobimo odgovor, zakaj tako velik delež vprašanih uporablja več

aplikacij za upravljanje svojih primerov.

Pristop dinamičnega upravljanja primerov tako omogoča, da se ustvari medsebojno

povezana mreža dela, kjer sprememba v nekem delu primera ustrezno reagira in se odzove

na vse ostale "dele" v primeru [8].

Kot smo že omenili je ACM primerno orodje za nestrukturirano upravljanje primerov.

Orodje bi naj omogočalo delo po principu, kjer koraki izvajanja niso (vedno) v naprej znani.

Tako orodje ACM predstavlja rešitev za področja, ki so bila težko obvladljiva s

tradicionalnim BPM pristopom. Orodje ACM se fokusira in sloni na znanjih uporabnika, ki

izvaja delo na primeru in tako sprejema odločitve, in reagira na zunanje dogodke kot so klici

strank in naročnikov. Orodje BPM tega ne omogoča in strogo sledi načrtovanemu procesu,

kot orodje ACM, ki nudi uporabniku različne vzvode, kot so nove in dopolnjene naloge

oziroma aktivnosti, dodajanje novih artefaktov in podobno, da doseže cilj primera. Na

spodnji sliki [Slika 2.8] vidimo vse aktivnosti, ki lahko sestavljajo primer [12].

Slika 2.8: Aktivnosti, ki pripeljejo primer do cilja (vir: http://www.avioconsulting.com/blog/5-scenarios-using-adaptive-case-management)


S pristopom dinamičnega upravljanja primerov se organizacijam omogoča celovito

upravljanje primerov, s katerim občutno izboljšajo rezultate svojega dela in storitev. Na ta

način zmanjšajo tveganja, saj se izognejo podvajanju in neskladjem pri delu, ter izboljšajo

sodelovanje ljudi in ostalih vpletenih sistemov znotraj organizacije.

Drug način kako razumeti to razliko med dinamičnim upravljanjem primerov in drugimi

pristopi dela je, da razumemo kaj dinamično upravljanjem primerov je [9].

Dinamično upravljanje primerov ni samo avtomatizacija invidualnih procesov

ampak tudi kompleksnih procesov. Dinamično upravljanje primerov postavi te

procese v okvirje primera.

Dinamično upravljanje primerov ni samo podpora ad-hoc delu. Podpora ad-hoc delu

je sicer ključna značilnost katerekoli programske platforme, ki želi podpreti

dinamično upravljanje primerov, saj je uporabna tako pri podpori avtomatiziranih

procesov, kot tudi vseh ostalih tipov dela. Vendar je samo en element podpore

dinamičnemu upravljanju primerov.

Dinamično upravljanje primerov ni samo še ena možnost, ki govori o vsebini

upravljanja, čeprav je vsebina zelo pomembna za dinamično upravljanje. Dinamično

upravljanje primerov gre nekoliko dlje v smislu svojih zahtev za proces in v pogojih

ustvarjanja inteligentne mreže dela.

2.4.7 Načrtovanje z delom “design by doing”

»Design by doing« - Načrtovanje z delom opisuje idejo načrtovanja preprostega dela -

pridobivanje modela in strukture na osnovi katerega je bilo delo opravljeno. Glavi cilj

dinamičnega upravljanja primerov je standardizirati primere, kolikor jih je mogoče.

Tako z uporabo orodja Adaptive Case Management pridobivamo nova znanja in s tem vedno

več vzorcev potencialnih strukturiranih procesov. Z analizo pridobljenih podatkov lahko

tako pridemo do ponavljajočih se vzorcev. S temi vzorci in analizami pa tako ugotovimo, ali

so kakšni uspešno zaključeni primeri dovolj podobni, da lahko iz njih modeliramo

strukturiran proces. Tega lahko nato implementiramo v proces in ga uporabimo v orodju

BPM, če le to ne vsebuje dinamičnega upravljanja [8].


2.4.8 Notacija oziroma kaj je CMMN (Case Management Modeling Notation)?

CMMN je notacija, ki je namenjana orodju oziroma pristopu Adaptive Case Managent.

Standard združuje elemente, ki jih orodje ACM uporablja na enak način kot orodje Base

Process Management (BPM) standard BPMN. Standard CMMN je bil ustvarjen s strani

konzorcija Object Management Group (OMG), pod katerim je prav tako standard BPMN.

Razvoj standarda se je pričel z objavo verzije 1.0 aprila 2014 in je trenutno v beta verziji 1.1

od marca 2016.

Standard CMMN zajema elemente, ki se uporabljajo kadar govorimo o pristopu

nestrukturiranega upravljanja, oziroma pristopu ACM.

Ti elementi so: Case (Primer), Milestone (Mejnik), Task (Opravila). Zajema pa tudi nekatere

druge elemente, kot so: Stage (Faze), Event (Dogodki) ter ostala dopolnilna označevanja

[15].

- Case Plan Model (Plan primera):

Plan primera je celotno okolje primera, sestavljeno in vsebuje vsaj enega ali več

elementov, ki predstavljajo evolucijo primera skozi izvajanje in planiranja

udeleženih akterjev. V planu se tako lahko pojavljajo štirje tipi elementov: opravila

(Tasks), stanja (Stages), dogodkovni prožilci (Event Listeners) in mejniki

(Milestones).

- Case File (Datoteka primera):

Predstavlja informacije ali reference na informacije, ki so potrebne za upravljanje

primera. Vsak primer je povezan z določeno datoteko primera. Datoteka primera

lahko vsebuje karkoli iz datoteke ali dokumenta shranjenega v CMIS (Content

Management Interoperability Services).


- Stages (Stanje / faza):

Stanja imajo izvajalno predstavitev v planu primera. Predstavljajo pot skozi CMMN

in tako določijo stanje, oziroma trenutni življenjski cikel primera. Stanja ali faze je

mogoče obravnavati tudi kot "epizode" primera, čeprav plan primera definira stanje,

ki je lahko planirano tudi vzporedno ali kot stanje, ki se nikoli ne izvede.

Tabela 2.7: Elementi CMMN notacije za CasePlanMode, Case File in Stage

CasePlanModel – Plan modela

Element predstavljen kot mapa, v

kateri so zbrani vsi elementi v

povezavi s primerom.

CaseFileItem – Datoteko primera

Datoteka primera je v notaciji

predstavljena kot ikona za list

papirja.

Stage – Stanje oziroma faza primera

Obstajata dve osnovni obliki stanja in

sicer združena (collapse), prikaz na

prvi sliki, kjer je vsebina stanja

zakrita in razširjena (expand), kjer je

vsebina stanja vidna.

(vir: http://www.omg.org/spec/CMMN/1.1/)


- Task (Opravila oziroma naloge):

Planiranje in upravljanja primerov je običajno ukvarjanje z odločitvami, katere

naloge se bodo uporabile, ali katero zaporedje nalog je zahtevano. Naloga je tako

atomska enota primera.

Skozi fazo načrtovanja primera, lahko poslovni analitik sodeluje v modeliranju, ki

vključuje definiranje nalog, katere so zmeraj del predefiniranega segmenta v modelu

primera in so na voljo akterju v uporabo. V času izvajanja pa lahko akterji izvajajo

plan primera, kot je načrtovano po nalogah ali dodajajo naloge po lastni presoji.

Obstaja velik nabor elementov, s katerimi povemo za kateri tip ali način uporabe

naloge (task) gre. Vsi najpogostejši elementi nalog, so prikazani v spodnji tabeli

[Tabela 2.8].

Tabela 2.8: Najpogostejši CMMN elementi nalog (Tasks) notacije

Task – Opravilo oziroma naloga

Klasična oblika elementa

Prikaz naloge s pogoji vstopa in

izstopa iz opravila

Non-blocking HumanTask

Oblika elementa za prikaz ne-

blokirajočega uporabniškega opravila

Blocking HumanTask

Oblika elementa za prikaz

blokirajočega uporabniškega opravila


ProcessTask

Oblika elementa, ki predstavlja

poslovni proces – povezavo z BPM

procesom

CaseTask

Oblika elementa za prikaz opravila v

obliki drugega povezanega primera


- Milestone (Mejnik):

Mejnik predstavlja nek vmesni cilj, kateri nam omogoča ocenjevanja napredka na

primeru. Vendar delo na primeru ni neposredno povezano z mejniki. K napredku in

posledično cilju primera vodijo vsa opravila, naloge in dosegljivost ključnih

rezultatov. Mejnik pa lahko imajo več kriterijev (ni pa nujno), ki definirajo, kdaj je

mejnik dosežen. Kako označimo takšne mejnike, je prikazano v spodnji tabeli

[Tabela 2.9].

Tabela 2.9: CMMN oblike elementa mejnik

Milestone – Mejnik

Klasična oblika elementa za prikaz

mejnika

Oblika elementa s kriteriji dosega

mejnika



- Event Listeners (Dogodki / Dogodkovni poslušalci):

V CMMN je dogodek, ko se nekaj zgodi v času izvajanja primera. Tako lahko

dogodki sprožijo vključevanje, aktiviranje, prekinitev stanja (Stage) in opravila

(Task). Lahko pa sprožijo tudi doseganje nekega mejnika. Element Time Event

Listener – časovnega dogodka. Časovni dogodek se uporablja za vnaprej določene

poteke časovnikov (timers). Element User Event Listeners – uporabniški prožilci pa

tako omogočajo direktno interakcijo uporabnika s primerom. V Spodnji tabeli [

Tabela 2.10] so tako zbrani vsi prožilci, ki nastopajo v notaciji CMMN.

Tabela 2.10: Oblike prožilcev v CMMN notaciji

EventListener – Dogodkovni prožilec

TimerEventListener – Časovni prožilec

UserEventListener – Uporabniški

prožilec



- Link (Povezave):

Nekatere odvisnosti med elementi so prikazane s pomočjo povezav (Link). Povezave

so tako znotraj plana primera (CasePlanModel) ali razširjenega stanja (Stage), kjer

povezujejo odvisne elemente. Oblika povezave je predstavljena s črto (prekinjajočo),

povezava na koncu ne sme imeti puščice, kot je to v BPMN standardu, saj ne

predstavlja toka izvajanja.

Tabela 2.11 Oblika povezav v CMMN notaciji

Link (Connection) – klasična povezava

za prikaz odvisnosti


V spodnji sliki [Slika 2.9] je prikazan primer odvisnosti. Vhodni kriterij v aktivnost

B (Task B) je odvisen od zaključka aktivnosti A (Task A).

Slika 2.9: Primer odvisnosti aktivnosti s stražarjem (Sentry)


- Dekoraterji:

Obstaja še nekaj vrst dekoraterjev, ki se uporabljajo na ostalih CMMN elementih, s

katerimi lahko povemo določene specifike.

o Planning Table – Tabela plana

o Entry Criterion (Sentry) – Vstopni kriteriji

o Exit Criterion (Sentry) – Izstopni kriteriji

o AutoComplete – Samo dokončanje

o Manual Activation – Ročno aktiviranje

o Required – obvezna zahteva

o Repetation – Ponavljanje

V spodnji matriki [Slika 2.10] so prikazani dekoraterji, ki se lahko uporabljajo na različnih

elementih notacije. Tako imamo v prvi – naslovni vrstici naštete vse možne dekoraterje in v

prvem stolpcu CMMN elemente. Iz matričnega modela pa je tako možno razbrati, kateri

elementi lahko imajo katere dekoraterje.

Slika 2.10: Dekoraterji CMMN (v možnih kombinacijah)


2.4.9 Primer poslovnega procesa v CMMN

Za prikaz ACM primera smo uporabili zavarovalniški primer, ki ga prikazuje spodnja slika

[Slika 2.11]. V primeru so prikazane vse osnovne aktivnosti, stanja oziroma faze, mejniki in

dogodki, ki se pojavljajo v primeru priprave zavarovanja.

- Povezave, ki nastopajo v primeru ne pomenijo toka izvajanja ampak predstavljajo

odvisnosti med elementi.

- Primer se začne ročno, s sprožitvijo procesa »Identifikacije odgovornosti

zaposlenih«, tako se primer nahaja v fazi »Identifikacija odgovornosti«.

- Primer doseže mejnik »Odgovornosti identificirane«, ko so identificirane

odgovornosti, ki jih lahko z ročno aktivnostjo »Sprememba odgovornosti«

uporabniki spreminjamo.

- Ko dosežemo mejnik »Odgovornosti identifikacije«, preide primer v fazo

»Dodajanje osnovnih podatkov«. V tej fazi je na razpolago uporabniška aktivnost

»Ustvari zavarovalniško polico«, proces v primeru nepopolne dokumentacije,

»Zahtevaj manjkajočo dokumentacijo«, ročno aktivnost »Pregled dokumenta«, ki se

sproži kadar dobimo nov dokument. Zbrani osnovni podatki tako pomenijo, da je

dosežen mejnik »Dodani osnovni podatki«.

- Dosežen mejnik »Dodani osnovni podatki« pomeni, da primer preide v naslednjo

fazo, »Proces zavarovalniških podrobnosti«, ki vsebuje aktivnost (pod)primera

»Ustvari in procesiraj zavarovanje« in dogodek, ki ga sproži uporabnik v primeru

zaključenih pripravljenih zavarovanj in pomeni, da smo dosegli mejnik

»Zavarovanja procesirana«.

- Mejnik »Zavarovanja procesirana« pomeni, da so pogoji za zaključek primera

izpolnjeni in se primer zaključi.

- Primer ima ves čas na razpolago,sprožitev uporabniškega dogodka za preklic

primera »Prekliči primer«.

- Primer ima ves čas na razpolago procesno aktivnost za procesiranja pisma »Ustvari

pismo«.


Slika 2.11: Primer priprave zavarovanja

2.4.10 Zgodovina in razvoj ideje dinamičnega in nestrukturiranega upravljanja primerov

Ideja o upravljanju nestrukturiranih in nepovezanih procesov ni nova, nov je bolj ali manj le

standard CMMN.

Sama ideja upravljanja primerov tako izhaja iz zahtev upravljanja finančnih, pravnih ali

sodnih in medicinskih, zdravstvenih svetov. Upravljanje primerov oziroma preučevanje in

analiziranje teh primerov, je v teh svetovih omogočalo finančno optimizacijo poslovanja,

krpanje zakonov ter prepoznavanje in zdravljenje bolezni.

Pri finančni optimizaciji, so podjetja tako s poznavanjem in analiziranjem svojih primerov

dobila ponavljajoče se vzorce svojih postopkov in s tem procese. S tem pa so omogočili

zaznavo napak, ozkih grl in opravil, kjer imajo težave.


V pravu in zakonodaji je to upravljanje in poznavanje primerov pomenilo, kakšne reforme

mora zakonodaja narediti, da izboljša svoje stanje.

Upravljanje primerov v zdravstvu in medicini je pomagalo analizirati in odkriti nove bolezni.

Z zbiranjem simptomov na večih primerih oziroma pacientih je tako pomagalo določiti,

identificirati bolezni in simptome bolezni.


3 OBVLADOVANJE PRIMEROV V PODJETJU PRED VPELJAVO

ORODJA CASE MANAGEMENT

Orodje Case Management smo vpeljali v telekomunikacijsko podjetje, ki ima v primerjavi z

ostalimi podjetji kompleksen nabor storitev in veliko vpletenih akterjev ter izredno

dinamično okolje.

Pred vpeljavo orodja Case Management je bila ena izmed večjih težav in povod za razvoj

orodja v sledenju in hitrosti reševanja (ne standardnih, ne strukturiranih) primerov. Takšni

primeri so se v veliki večini reševali preko elektronske pošte, različnih orodij, raznih

komunikacijskih programov, kot je Skype, telefonskih pogovorov in osebnih stikov, oziroma

obiskov po pisarnah zaposlenih. Takšno reševanje primerov predstavlja velike težave

službam, ki so v stiku z naročniki. Zaposleni so tako porabili veliko časa in napora, preden

so našli pravilne informacije o stanju primera ali tega sploh niso našli, kar je pogosto

pripeljalo do ponavljanj nekaterih aktivnosti in ponovnih prijav primerov. Takšno reševanje

primerov pa ima zraven nepotrebnega in zamudnega dela zaposlenih, zelo velik negativen

vpliv na stranko, saj privede do nezadovoljstva in možnosti izgube vpletenega naročnika.

Pri reševanju primerov z orodjem Case Management se v podjetju navezujemo predvsem na

primere, ki so nevsakdanji ali izredni primeri, kot so nove, neznane napake, raziskave

reklamacij, vklop oziroma sprememba nove, manjše storitve ali ad-hoc naloge,

poizvedovanja o nekem stanju ali storitvi in še. Za ključne oziroma standardne primere –

procese, kot je priklop ADSL, FTTH, vklop elektronske pošte, naročilo varnostnega

programa, sprememba hitrosti, vklop dodatnih TV programov in podobnih storitev se v

podjetju uporablja prav tako lastno orodje s pristopom Business Process Management

(BPM). V orodju BPM so vsi ti procesi načrtovani, modelirani in implementirani. Orodje

Case Management pa je zasnovan tako, da lahko vključuje tudi te standardne modelirane

procese.


3.1 Elektronska pošta

Reševanja primerov preko elektronske pošte je ena izmed najpogosteje uporabljenih tehnik

v podjetju. Elektronska pošta se tako uporablja za reševanje celotnih primerov, kot pomoč

pri reševanju z ostalimi orodji in predstavlja dodaten komunikacijski kanal, prek katerega se

poizveduje o stanju in rezultatih primera.

Glavni problem uporabe elektronske pošte predstavlja velika količina oziroma masa

sporočil, ki se nenehno povečujejo. Povečuje se tudi z rastjo podjetja, povečanim številom

zaposlenih, številom strank, ali širjenjem nabora storitev in produktov.

Pomanjkljivosti elektronske pošte:

- Velika masa sporočil privede do slabe sledljivosti. V večini primerih je vpletenih več

ljudi, kar v praksi privede do izgube informacij oziroma celotnih sporočil. Situacija

najpogosteje privede do tega, da v danem trenutku dve osebi rešujeta isti primer

istočasno. Dva akterja prejmeta in se vključita v zadnje sporočilo, sestavita odgovor

in pošljeta sporočilo. Naslednji akter, ki bo želel nadaljevati z delom, bo lahko hitro

spregledal eno izmed sporočil, saj se je nit reševanja razcepila. V praksi je to

pomenilo, da je eno sporočilo izviselo in ga bodo pri nadaljnjem reševanju ostali

akterji najverjetneje spregledali, kar je prikazano na spodnjem primeru elektronske

pošte [Slika 3.1].

- Naslednja pomanjkljivost je hranjenje pridobljenega znanja. S postopkom reševanja

primera smo velikokrat prišli do vzorca, kako reševati določen tip primera, ki se

večkrat ponovi. V reševanje postopka je ponavadi vpleten en akter iz določenega

oddelka. Ta akter si je mogoče zapomnil postopek ali ga bo v prihodnje znal poiskati

med svojimi sporočili. Vsi ostali zaposleni znotraj oddelka pa v elektronskih

sporočilih niso sodelovali, oziroma niso sodelovali aktivno aliniso bili niti med

prejemniki elektronskih sporočil, kar v veliki večini pomeni, da niso pridobili tega

znanja.

- Še ena izmed večjih pomanjkljivost je pomanjkanje informacij o reševanjem in

stanju primera. Ta pomanjkljivost se najbolj občuti v oddelkih, kjer zaposleni

komunicirajo s strankami (klicni center). Pri komunikaciji s stranko so nujno


potrebne informacije o napredku, trenutnem stanjem ali rešitvi primera.Reševanje

teh težav smo poskušali rešiti s skupinskimi elektronskimi naslovi, kar nekoliko

olajša oziroma omili te pomanjkljivosti, ni pa rešitev s katero bi se izognili vsem

omenjenim težavam.


Slika 3.1: Tok el. pošte – prikaz spregleda/izgube zaradi večnitnega sporočila


3.2 Komunikacija preko IM orodij (Skype, Google Talk/Hangsout)

Komunikacija preko instantnih sporočilnih orodij (IM) ima eno prednost pred elektronsko

pošto – hitrost reševanja oziroma odziv vpletenih akterjev. Zadevo lahko v tem primeru

rešujemo tako, da vključimo vse vpletene ali samo določene akterje, s katerimi lahko hitro

in izmenično obdelujemo informacije.

Težave, ki nastopijo tukaj so ponovno: sledljivost, izgubljeno pridobljeno znanje, akterji, ki

niso vključeni v razpravo o postopku in rešitvi primera, niso o zadevi seznanjeni.

Tako se ta orodja lahko uporabljajo samo in izključno v kombinacijah z elektronsko pošto,

ali še bolje, v kombinaciji z drugimi orodji za obdelavo primerov, kot je prikazano na spodnji

sliki [Slika 3.2], kjer se uporabniki sami opominjajo, usmerjajo ali informirajo. Tako ima

takšno orodje prednost izključno dokler gre za izmenjavo teh tipov sporočil, vendar tudi

tukaj samo v manjših primerih. Pri veliki masi ni mogoče nadzorovati in usklajevati vseh

zadev preko takšnega orodja.

Slika 3.2: Primer dobre uporabe orodja Skype


3.3 Ostala orodja za vodenje dela

Zraven elektronske pošte in orodij za instantno sporočanje (IM) smo imeli znotraj oddelkov

še druga orodja in aplikacije, preko katerih so oddelki vodili reševanje primerov, v katera so

bili vpleteni. V klicnih centrih in oddelkih, kjer je bilo veliko časa posvečenega komunikaciji

z naročnikom (Prodaja, Tehnika, Reklamacije in Svetovanje) se je uporabljalo orodje

Request Tracker/Ticket (RT), ki je prikazano na spodnji sliki [Slika 3.3]. Orodje ima

prednost, pred predhodno omenjenimi orodji, v večji sledljivosti pri komunikaciji preko

elektronske pošte. Tako je pod zadevo sporočila (subject mail in pošiljatelja) bila zbrana vsa

komunikacija s pošiljateljem (v veliki večini naročnikom). Sporočila pod isto zadevo so

kronološko urejena, ne glede na to, koliko uporabnikov preko sistema komunicira s

pošiljateljem oziroma naročnikom. Zraven te komunikacije z naročnikom ima orodje

možnost dodeljevanja teh zadev med uporabnike in oddelke. Sistem pa je prav tako imel

določene slabosti, kot je nepovezanost z ostalimi sistemi, kot so specializirani interni sistemi,

ki jih uporabljajo oddelki tehnike, reklamacije in svetovanja, nepovezanost s centralnim

sistemom naročnikov (CRM) in z orodjem za upravljanje strukturiranih procesov (BPM).

Slika 3.3: RT - Request Tracker


Drugo orodje je bilo Mantis Bug Tracker, katere glavni namen je bil obveščanje o napakah

v sistemih in bazah, kot je prikazano na spodnji sliki [Slika 3.4]. Uporaba je v večini bila

omejena na oddelek za vodenje procesov (IT), administracijo in reklamacije. Primeri in

zadeve, ki so se sporočale, so bile v veliki večini administrativne narave (kot na primer:

stranki se ni upošteval popust, vključena napačna akcija/popust, v priklop storitve je bil

vnešen napačen naslov/datum, naročniku se zaračunavajo promocijske stvari,…). Orodje

jeimelo nekaj uporabnih funkcionalnosti, kot je bilo dodeljevanje primerov po uporabnikih,

nastavljanje prioritete, status reševanja primera,… Orodje pa je prav tako imelo nekaj

pomanjkljivosti. V osnovi je bilo namenjeno samo enemu oddelku, ki je sprejemalo primere

iz ostalih oddelkov. Medoddelčno dodeljevanje ni bilo uporabljeno. Znotraj enega primera

ni bilo mogoče ustvariti več opravil/aktivnosti, kot v prejšnj omenjenem orodju. Tudi to

orodje ni bilo povezano z ostalimi internimi sistemi in orodji (CRM, BPM).

Slika 3.4: Mantis - Bug Tracker


4 NAČRTOVANJE IN RAZVOJ ORODJA

Ideja upravljanja dinamičnih in nestrukturiranih procesov tako izhaja iz razlogov, ki smo jih

večkrat omenili v prejšnjih poglavjih; to so izguba časa, informacij, znanja, sledi reševanja

in predvsem poenotiti delo v podjetju. Za razvoj lastnega orodja znotraj

telekomunikacijskega podjetja smo se tako odločili predvsem iz stališča stroškov,

poznavanja problematike, velikih posebnosti, specifik, pogostih sprememb in potreb po

prilagoditvah.

Kljub odločitvi za razvoj lastnega orodja, smo na začetku poskusili poiskati podobna orodja.

Namen iskanja podobnih orodij je bil predvsem pridobiti predstavo, kako se drugi soočajo s

podobnimi težavami in kako so reševali nastale probleme. Pri iskanju podobnega orodja smo

imeli kar nekaj težav, saj orodij v takšni obliki ni veliko. Podobne rešitve sicer lahko

najdemo v velikih informacijskih sistemih, ki jih ponujajo podjetja kot so IBM, Oracle,

Microsoft, SAP, vendar zaradi dragih licenčnin in podobnih težav nismo uspeli preizkusiti...

Večina orodij je tako plačljivih in zelo redki omogočajo uporabo demo različic, s katerimi

bi lahko spoznali orodje. Med iskanjem primerljivih aplikacij smo takrat našli aplikacijo

Asana, ki je prikazana na spodnji sliki [Slika 4.13]. (Kot zanimivost, idejni oče aplikacije je

soustanovitelj socialnega omrežja Facebook, Dustin Moskovitz). Aplikacija se promovira

kot orodje, ki ima možnost upravljanja z nalogami in dobro razvito komunikacijo, ter

sodelovanje med vpletenimi uporabniki in nalogami. Zraven upravljanja nalog je bila

izpostavljena še ena točka. Točka govori, da je z uporabo aplikacije možno nadomestiti

komunikacijo po elektronski pošti. Aplikacija je tako imela kar nekaj skupnih točk z našo

idejo in končno željo. Preizkusili smo demo aplikacijo in s tem dobili nekaj idej, kako in na

kaj je potrebno paziti pri razvoju naše ideje in aplikacije.

Med preizkusom demo aplikacije, s katero smo pridobili nekaj idej, smo največji fokus

posvetili našim uporabnikom oziroma zaposlenim v podjetju. Začeli smo podrobno

spremljati in opazovali delo vseh oddelkov, in tako pridobili veliko uporabnih informacij.

Po opazovanju dela v oddelkih, smo z nekaterimi zaposlenimi opravili intervju in tako dobili

še drugo sliko. Uporabniki so povedali, kje jih trenutna orodja omejujejo, kaj bi jim olajšalo

delo, in kako si predstavljajo idealno rešitev za njihove težave.


Z obdelavo zbranih informacij smo izdelali nekaj primerov uporabe (UML - Use Case

Diagram) in nekaj primerov uporabniškega vmesnika. Načrtovano in narejeno smo ponovno

preverili z uporabniki. Ta korak smo izvajali skozi celoten razvoj orodja, ki ga opisujemo v

naslednji točki.

Pri načrtovanju orodja smo morali upoštevati, da bo orodje uporabljalo veliko število

uporabnikov znotraj različnih oddelkov, tako smo morali paziti na različne stvari in sklepati

določene kompromise. Določene zadeve so nekaterim oddelkom pomenile lažje –

preglednejše delo, med tem so drugim oddelkom lahko predstavljale dodatno delo ali zmedo.

Da bi bilo orodje čim bolje sprejeto in bi prehod na novo orodje bil čim manj boleč, smo

razvoj orodja razdelili na več faz. Z razvojem po fazah smo lahko na podlagi povratnih

informacij uporabnikov videli, ali določena zadeve in funkcionalnosti prinašajo željen

rezultat, ali ne.

4.1 Pristop k razvoju orodja

Za razvoj orodja Adaptive Case Management smo uporabili model iterativnega pristopa.

Razvoj orodja smo tako razdelili v več iteracij, s katerimi smo postopoma poskušali

dopolnjevati orodje do željene oblike in funkcionalnosti. V prvi iteraciji oziroma verziji je

bil cilj, postaviti enoten sistem za beleženje, pregled in iskanje primerov. V naslednjih

iteracijah pa tako ustvariti celostno orodje, za upravljanje nestrukturiranih primerov. Tako

smo z vsako izdano verzijo sproti dopolnjevali funkcionalnosti in na podlagi povratnih

informacij uporabnikov določene funkcionalnosti odstranili ali dopolnili. S takšnim

pristopom smo poskušali nadzorovati razvoj orodja v pravilni smeri.

Razvoj aplikacij z iterativnim pristopom poteka v ponovitvah oziroma iteracijah. Vsaka

iteracija, kot prikazuje [Slika 4.1] vsebuje vse faze razvoja. Te faze so: zajem zahtev, analiza,

načrtovanje, implementacija, izdaja in vpeljava izdane verzije.


Slika 4.1: Pristop iterativnega razvoja

Razlika med klasičnim razvojem aplikacij, ki poteka na podoben način, vendar brez iteracij

je ta, da uporabnik pri klasičnem modelu razvoja do končne faze ne dobi delujočega sistema,

kot prikazuje prvi del slike [Slika 4.2]. Tak pristop lahko pomeni, da je razvojni sistem

načrtovan v napačni smeri ali vsebuje funkcionalnosti, ki ne dosegajo svojega namena. .To

ugotovimo šele na koncu razvoja oziroma po vpeljavi sistema. V primeru, da ne dosežemo

namena pri razvoju sistema, ima lahko tak pristop brez iteracij tudi usodne posledice na

podjetje. Pri našem izbranem modelu razvoja ima naročnik aplikacije ves čas pregled in

možnost uporabe razvojnega sistema, ki ima na začetku omejeno funkcionalnost, kot

prikazuje drugi del slike [Slika 4.2]. Naročnik pa tako vidi napredek in vpliva, usmerja na

nadaljnji razvoj [17][18].


Slika 4.2: Primerjava Agilne in klasične metode razvoja [18]

4.2 Tehnične zahteve

V podjetju imamo široko paleto orodij in aplikacij, s katerimi upravljamo storitve in

produkte, ki jih ponujamo našim naročnikom. Veliko večino teh orodij smo razvili znotraj

podjetja. Tako glede tehničnih zahtev, kot je izbira programskih jezikov, podatkovnih baz in

ostalih tehnologij, nismo imeli velikih pomislekov. Izbira je bila zaradi predhodnega znanja

samoumevna. S takšno izbiro tehnologije smo se prav tako izognili morebitnim dodatnim

stroškom. Prav tako pa smo s takšno izbiro sledili želji po integraciji z ostalimi večjimi

sistemi v podjetju. Tako smo novo nastalo orodje ACM združili, oziroma integrirali v

obstoječi informacijski sistem, v katerem smo predhodno že imeli CRM, BPM, razne

prodajne module, upravljanje z naročili in še, kot prikazuje spodnja slika [Slika 4.3].


Slika 4.3: Moduli informacijskega sistema

4.2.1 Implementacija poslovne logike

Pri implementaciji poslovne logike smo kot programski jezik uporabili PHP, s katerim smo

razvili celostno poslovno logiko našega orodja. Pri implementaciji smo si poskušali delo

lajšali z različnimi odprtokodnimi knjižnicami.

Največ dela smo si tako olajšali s knjižnico ADOdb za upravljanje podatkovne baze. Z

uporabo te knjižnice smo do baze dostopali na podoben način kot do ostalih objektov (Object

Relation Mapping). S tem smo se tako izognili nepotrebnim preprostim operacijam, kot so

branje in pisanje v osnovne entitete. S to knjižnico smo pridobili možnost za preprosto

zamenjavo podatkovne baze (v našem primeru MySQL), v kolikor z izbiro nebi bili

zadovoljni in pri tem ne bi posegali v poslovno logiko orodja ACM.

Še ena izmed knjižnic, ki nam je olajšala veliko dela je bila knjižnica LDAP. S to knjižnico

smo si olajšali dostop do Microsoftove storitve ActiveDirectory (AD). V tej storitvi imamo

hranjene podatke o uporabnikih, oddelkih ter celotni hierarhiji podjetja. Trenutni sistemi so

iz sistema AD preverjali, ali uporabniki imajo dostop ali ne, vse ostale pravice pa so bile

vezane na posamična orodja. Pri orodju ACM pa smo potrebovali hierarhijo podjetja

(oddelke, kateri uporabnik je v katerem oddelku, vodje oddelkov, hierarhijo oddelkov). Tako

smo razvili pomožen sistem za delo z uporabniki (User Manager), ki zagotavlja, upravlja in

hrani te podatke. Ta pomožen sistem je bil razvit na način, da ga lahko integrirajo oziroma


uporabijo tudi drugi obstoječi sistemi. Sistem za upravljanje uporabnikov je preko dnevnega

opravila (cron job) skrbel za sinhronizacijo podatkov s storitvijo AD.

V orodju ACM smo za potrebe sinhronizacije in povezovanja z drugimi sistemi razvili API

oziroma servis preko katerega smo navzven izpostavili določene funkcionalnosti orodja. Ena

izmed teh funkcionalnosti je bila možnost odprtja primera preko elektronske pošte (kot smo

že omenili v prejšnjem poglavju pri orodju RT) in nekaj drugih funkcionalnosti, predvsem z

namenom integracije z ostalimi orodji in sistemi. Glavni namen teh funkcionalnosti, kot

prikazuje slika [Slika 4.4] je bila povezava z naročniki, iskalniki in orodjem za strukturirano

upravljanje procesov (CRM, BPM).

4.2.2 Implementacija uporabniškega vmesnika

Uporabniški vmesnik je ključna enota vsakega sistema, saj omogoča interakcijo uporabnika

s sistemom. Za uspešno uporabo sistema je potreben pregleden in enostaven uporabniški

vmesnik, saj je lahko v nasprotnem primeru še tako dober sistem povsem neuporaben.

Pri razvoju uporabniškega vmesnika smo želeli čim manj invidualnega razvoja grafičnih

komponent, zato smo za osnovo izbrali ogrodje ExtJS, ki ima široko paleto komponent za

izgradnjo kvalitetnega grafičnega vmesnika (tabele, forme, hierarhična drevesa,…). Tako

smo celotno grafično osnovo uporabniškega vmesnika razvili z ogrodjem ExtJS.

V vmesniku tako zraven teh komponent nastopa še veliko »tekstovnih« podatkov, ki so v

veliki večini strukturirani v nekakšnih osebnih izkaznicah (naročnikov, lokacij, storitev,

produktov,…). Tekstovne podatke smo oblikovali s pomočjo HTML kode in ogrodja

Bootstrap. S tem smo zagotovili, da so vsi statusi, prioritete, uporabniki in ostale podobne

stvari prikazane na enak in transparenten način.


Slika 4.4: Podatkovna komunikacija

4.3 Funkcionalne zahteve

Upravljanje nestrukturiranih primerov smo v grobem razdelili na dve entiteti. Prva glavna

entiteta, ki ima tudi največ funkcionalnih zahtev, je primer. Druga entiteta oziroma pod

entiteta pa je tako postala aktivnost. Aktivnost smo za boljše upravljanje primera delili na

več tipov, kot so: naloge, komentarji in priloge. Vsakemu tipu aktivnosti smo tako definirali

drugačne funkcionalne zahteve. Naloga ima tako osnovne funkcionalnosti podobne primeru,

saj ima življenjski cikel in izvajalce, medtem ko je namen komentarja in priloge sprožiti

komunikacijo, ki služi kot pomoč pri reševanju in dopolnjuje podatke primera.


Slika 4.5: Primeri uporabe v orodju ACM


4.3.1 Vpis primera:

Primeri se v orodju ACM lahko ustvarijo na dva načina:

Prvi način in najpogostejši je preko vmesnika ACM orodja.

Praviloma se najprej preveri, ali je zadeva že vpisana v orodje., kar se naredi preko

iskalnika oziroma preko naročnika v orodju CRM (v kolikor je primer povezan z

naročnikom).

Drug način kreiranja je preko elektronske pošte.

Ko elektronska pošta prispe na naslov oddelka (vsak oddelek ima svojo elektronsko

pošto namenjeno ACM orodju), sistem TIBCO obdela sporočilo in preko

izpostavljene funkcionalnosti (API), ustvari nov primer. Zadeva elektronske pošte

tako postane zadeva primera, vsebina elektronske pošte postane vsebina in opis

primera. Pošiljatelj, v kolikor obstaja v sistemu (el. naslov) kot uporabnik, pa se doda

kot sporočitelj in opazovalec primera.

Slika 4.6: UML ustvarjanje primera

Za pregled in upravljanje primera smo uporabili skupen uporabniški vmesnik. V vmesniku

je mogoče pregledati vse aktivnosti in podatke primera ter sprožiti vse funkcionalnosti za

upravljanje primera in aktivnosti, ki so opisane v naslednjih točkah.


4.3.2 Status in pod-status primera

Status primera predstavlja življenjski cikel primera. Tako lahko s pregledom statusa takoj

ugotovimo, kaj se s primerom dogaja. V ta namen smo definirali pet statusov, ki so prikazani

na spodnji sliki [Slika 4.7]. Trije od prikazanih statusov (novo, v obdelavi in zaključeno)

predstavljajo tako imenovan »naravni« cikel primera, kar pa v določenih scenarijih ne

zadošča za optimalno seznanjanje s stanjem primera. Za takšne primere smo dodali še dva

dodatna statusa (preklicano in ponovno odprto).

Slika 4.7: Življenjski cikel primera

- Novo:

Prvi status primera, v času kreacije dobi primer status »Novo«. Ta status ima dokler

ne preide v obdelavo. Tako uporabnik takoj izve, da se obdelava primera še ni pričela.

- V obdelavi:

Status »V obdelavi« spremenimo ročno, kadar začnemo z delom oziroma

raziskovanjem na primeru. Namen statusa je, da ostalim zaposlenim ali vpletenim

povemo, da smo primer prevzeli. S tem prav tako zmanjšamo tveganje, da bi več

ljudi delalo isto delo. Uporabnik, ki spremeni status primera na »V obdelavi«, se

avtomatsko določi kot upravljalec primera.


- Zaključen:

Status zaključen pomeni, da je zadeva na primeru zaključena in je cilj primera

dosežen. To prav tako pomeni, da na primeru ne bo več novih aktivnosti (zgodi se

lahko le sprememba statusa v »ponovno odprt«). Tako kot prejšnja dva statusa, je

tudi tega potrebno določiti ročno. V kolikor na primeru obstajajo še nedokončane

aktivnosti, jih sprememba na ta status avtomatsko spremeni v zaključene oziroma

preklicane.

- Ponovno odprt:

Status je namenjen ponovnemu odprtju in nato ponovni obdelavi primera. Status je

ločen od statusa nov z namenom, da pri pregledu takoj vidimo, da je primer že imel

aktivnosti in se je na primeru najverjetneje ponovila težava.

- Preklican.

Status je namenjen označevanju primerov, za katere se ugotovi, da so brezpredmetni

in ne potrebujejo nadaljnje obravnave.


Slika 4.8: Diagram poteka spremembe statusa primera

Na podlagi statusa in tipa primera lahko določimo pod-status (v kolikor je na izbran status

in tip definirana množica pod-statusov). Pod-status primera omogoča podrobno definicijo

trenutnega statusa. Tako imamo v primeru, da je tip primera »Napaka« in status »V

obdelavi«, možnost določiti pod-status »Testiranje« ali »Čakanje povratne informacije


naročnika«. V primeru, ko je tip primera »Reklamacija« in status »Zaključen«, imamo

možnost nastaviti pod-status »Napaka na strani naročnika – neupravičena reklamacija« ali

»Napaka na naši strani – upravičena reklamacija«.

Pod-statusi v osnovi niso definirani in so opcijska lastnost primera. Definirajo in nastavljajo

se sproti po dogovoru z vodji oddelkov, glede na specifike dela v oddelkih.

4.3.3 Tip primera

Tip primera je opcijska lastnost, s katero lahko povemo kaj je glavna tema primera. V

začetku smo definirali samo dva oziroma tri glavne tipe.(Tipi so zasnovani na način, da lahko

v prihodnosti dodamo tudi nove). V začetku smo definirali tipe kot: reklamacija, tehnična

napaka in splošna prijava (tip ni izbran). Kot smo že omenili izbira tipa primera vpliva in

omogoča izbiro pod-statusa primera v kombinaciji s statusom. Tip primera je možno izbrati

samo ob kreaciji primera (na tip imamo vezane dodatne aktivnosti, kot so strukturirani BPM

procesi, ki se lahko prožijo iz orodja ACM) in ga po kreaciji ni mogoče spreminjati.

4.3.4 Dostopnost primera (zasebni/javni)

Določeni primeri lahko vsebujejo zaupne ali podatke občutljive narave. To pomeni, da ne

sme vsak uporabnik dostopati do teh podatkov. Vseeno pa je potrebno, da uporabniki vedo,

da se na teh primerih nekaj dogaja.

Primer občutljive vsebine je lahko: Stranko zanima, ali je reklamacija zaključena,

kar pomeni pravilen račun ali dobropis v naslednjem mesecu. Primer obravnava VIP

stranko in ima sklenjeno invidualno pogodbo, katere vsebina je omejena na določene

oddelke oziroma osebe.

Tako smo vsebino primera skrili, izpostavili pa smo samo ključne informacije za

poizvedovanje o stanju primera. Podatki, ki so tako javni ne glede na status primera so:

zadeva, tip, status (pod-status), prioriteta, datum vpisa, opazovalci, izvajalci in vpleteni

oddelki. Ostali podatki in vse aktivnosti primera so v teh primerih skriti.


4.3.5 Prioriteta primera

Je lastnost primera, ki narekuje hitrost in način obravnave primera. Določeni primeri lahko

imajo večji vpliv na samo podjetje (posredno ali neposredno), ali govorijo o težavah, ki

zajemajo večje število naročnikov, ki imajo določene invidualne pogodbe (VIP stranke). V

ta namen smo definirali tri prioritete (večje število prioritet po izkušnjah iz ostalih internih

sistemov izgubi pomen – vmesne prioritete postanejo neuporabne, uporabljajo se samo

skrajne, visoke). Tako smo uvedli prioritete: »Normalna«, »Visoka« in »Urgentna«.

Začetna in osnovna pravila uporabe in postavljanje prioritet:

- Primer, ki se prijavi ima v osnovi prioriteto »Normalna«.

- Primeri z vpleteno VIP stranko (lahko) imajo prioriteto »Visoka«.

- Kadar v primeru ugotovimo, da moramo primer obravnavati z večjo previdnostjo,

oziroma se v primeru ugotovi izredno stanje (velika težava, vpletenih več

naročnikov,…), se lahko prioriteta primera nastavi na »Urgentno«.

Pravila, kako reagirati in reševati, so interna pravila podjetja, lahko se spreminjajo in

prilagajajo sproti. V osnovi ne vplivajo na implementacijo orodja.


Slika 4.9: Primer uporabe, spremembe prioritete

4.3.6 Značke (#tag)

Namen značk na primerih je predvsem v označevanju obdelane vsebine primera. Te značke

tako služijo pri iskanju, kjer na podlagi iskalnih parametrov dobimo kot rezultat seznam

primerov, ki ustrezajo iskanim parametrom. V primeru dobro in smiselno uporabljenih

značk, lahko iskanje po značkah pomeni iskanje po bazi znanja.

4.3.7 Oznaka šablone (template)

Namen označevanja primerov kot šablone je dodatna funkcionalnost, kako na hiter in

preprost način definirati reševanje določenega tipa problema. Ideja izvira iz strukturiranega

upravljanja procesov, saj na nek način modeliramo proces oziroma aktivnosti, ki so potrebne

za rešitev nekega tipa problema. Tako lahko nek ponavljajoč problem označimo s šablono,

ki jo lahko naslednjič pri podobnem problemu uporabimo. Tako lahko na hiter in preprost


način kreiramo aktivnosti, ki so potrebne za reševanje problema. Kljub navidez

strukturiranemu procesu pa je proces dinamičen, kar pomeni, da lahko prosto dodajamo ali

odvzemamo aktivnosti, v kolikor ugotovimo, da so potrebne oziroma nepotrebne.

Primeri, ki so označeni kot šablone, se ne pojavljajo v ostalih seznamih in statistikah,

prikazani so samo v posebnem seznamu šablon. Prav tako je znotraj iskalnika mogoče

poiskati željeno šablono po zadevi in značkah, ki jih ima primer označen kot šablona.

Povezava s stranko CRM

Velika večina primerov (več kot 90%) je povezana z naročniki. Tako smo za lažje

povezovanje in raziskovanje, v osnovne podatke primera dodali opcijsko lastnost in na tak

način povezali z orodjem CRM. Tako so vsi primeri naročnika prikazani na enem mestu v

CRM orodju, kar olajša delo pri raziskovanju situacije naročnika. Predvsem je to pomembno

v oddelkih, ki so neposredno v kontaktu z naročniki.

4.3.8 Povezava z ostalimi primeri

Primer lahko povežemo tudi z drugimi primeri. Tipi povezav med primeri povedo, kako

bomo primer reševali. Tako smo definirali več tipov povezave.

- Dvojnik (duplikat): pomeni, da bomo primer katerega označimo tako, preklicali

(status preklic) in dodali referenco na primer, s katerim je ta primer dvojnik in v

katerem se primer rešuje.

- Dopolnjevanje: pomeni, da se določene zadeve rešujejo znotraj drugega primera, kar

je prikazano na modelu primera [Slika 4.10] v poglavju notacije CMMN.

4.3.9 Skrbniki

Skrbniki primera so uporabniki, ki skrbijo za izvajanje in nadzorujejo napredek primera.

Namen izvajalcev je beleženje in seznanjanje, kdo se ukvarja s primerom. Dodajanje

uporabnikov med izvajalce je ročno s klikom in avtomatsko. Avtomatski scenarij po katerem

se uporabniki dodajajo med izvajalce je trenutno samo eden, sprememba statusa v obdelavo.


4.3.10 Skrbniški oddelki

Skrbniški oddelki so oddelki, za katere se predvideva, da morajo biti vpleteni v izvajanje

aktivnosti in morajo tako biti seznanjeni s celotnim reševanjem, oziroma večino aktivnosti,

ki potekajo na primeru.

Tako so to oddelki, ki imajo v veliki večini neposreden stik z naročniki oziroma strankami,

saj bodo zaradi narave dela potrebovali informacije, ki jih bodo želeli naročniki in bodo tako

na nek način tudi koordinirali primer.

Ideja skrbniških oddelkov je v tem, da lahko v času izvajalčeve odsotnosti, upravljanje

primera prevzame drug uporabnik znotraj skrbniškega oddelka.

4.3.11 Opazovalci

Opazovalci primera so uporabniki, ki so kakorkoli povezani s primerom ali jih dogajanje na

primeru zanima. Namen opazovalcev je obveščanje o spremembah na primeru in njegovih

aktivnostih.

Opazovalce smo zasnovali na dva tipa. Prvi tip so klasični opazovalci oziroma uporabniki,

ki so obveščeni o vseh spremembah na primeru. Drug tip opazovalcev so uporabniki, ki so

obveščeni samo takrat, ko so dodani na primer kot opazovalci (kadar jih doda druga oseba),

ali je na primeru zahtevana urgentna obravnava, oziroma je primer zaključen, preklican ali

ponovno odprt.


Scenariji za avtomatsko dodajanje opazovalcev:

- Vpis novega primera kot opazovalca doda:

o kreatorja primera (1. tip opazovalca)

o skrbnika stranke (v kolikor je primer povezan s stranko in ima stranka

opazovalca) (2 tip opazovalca)

- Aktivnost na primeru kot opazovalca doda:

o uporabnika, ki kreira novo nalogo (2 tip opazovalca)

o odgovornega za rešitev nove naloge (v kolikor je uporabnik nastavljen)

o uporabnika, ki doda komentar

o uporabnika, ki je omenjen v komentarju

o uporabnika, ki je dodal prilogo

o uporabnika, ki spremeni status (v obdelavi, zaključeno, preklicano, ponovno

odprto)

Opazovalci se lahko poljubno dodajajo, odstranjujejo in spreminjajo tip opazovanja preko

uporabniškega vmesnika.


Slika 4.10: ER diagram primera

4.3.12 Naloge (Aktivnost primera)

Vsak primer lahko ima več nalog, ki jih ustvarjajo uporabniki in služijo lažjemu reševanju

ali upravljanju primera. Definirana imamo dva tipa nalog.

Prvi tip naloge je preprosta aktivnost s statusi, zadolženimi uporabniki in oddelki.

- Statusi:

Implementirani statusi so podobni kot na primeru: »Novo«, »V obdelavi«,

»Zaključeno«, »Preklicano« (brez statusa »Ponovno odprt«) in dodatnim statusom


»Blokiran«, kot je prikazano na spodnji sliki [Slika 4.11]. Status »Blokiran« nam

omogoča prikaz zaporedne odvisnosti med nalogami (reševanje ene naloga čaka

rešitev druge naloge).

- Izvajalci:

Izvajalci na nalogah imajo enak pomen kot skrbniki na primerih. Skrbijo, da je naloga

opravljena. Izvajalci se dodajajo ročno. Določitev izvajalca naloge spremeni status

naloge (v obdelavi).

- Izvajalni oddelki:

Izvajalni oddelki imajo enak pomen kot skrbniški oddelki na primeru. Tako vloga

izvajalnih oddelkov pomeni, kateri oddelki so zadolženi za izvedbo naloge (lažja

nadomeščanja uporabnikov, nadzor obremenitve oddelkov,…). Določanje izvajalnih

oddelkov na nalogah je mogoče nastaviti ročno ali samodejno. Kadar ustvarimo novo

nalogo in določimo samo izvajalca naloge, se avtomatsko nastavi njegov oddelek

med izvajalne oddelke.

Slika 4.11: Življenjski cikel naloge


Naloge so lahko preprosto definirane – medsebojno nepovezane, to pomeni, da vrstni red

reševanja nalog ni pomemben. Lahko pa naloge med seboj povežemo na dva načina.

- Zaporedna naloga, kar pomeni da je naloga, ki je označena kot zaporedna –

naslednja, v sistemu prikazana s statusom blokirana, kar pomeni, da potrebuje rešitev

predhodne (povezane) naloge.

- Vzporedna naloga je naloga brez povezave in brez dodatne nastavitve, vrstni red

reševanja takšnih nalog ni pomemben, vsebina naloge pa med seboj ni povezana.

Drug tip naloge je BPM proces, ki ima samo tri statuse (Aktivna, Zaključena in Preklicana

naloga) in se rešuje z internim BPM orodjem. Proces se sproži iz primera in ima referenco

primera. V zaključku procesa se preko reference primera sporoči, da je proces zaključen in

s tem spremeni status naloge v primeru.

Naloga se obravnava kot opravljena, ko ima status »zaključena« ali »preklicana«.

4.3.12.1 Komentarji (Aktivnost primera)

Vsak primer lahko ima več komentarjev, uporabniki lahko poljubno dodajajo komentarje.

Brisanje komentarjev je omejeno na avtorja in vodjo oddelka. Komentarji so prikazani

znotraj seznama aktivnosti (skupaj z nalogami in prilogami) in so kronološko urejeni, kar

omogoča hiter in enostaven pregled primera. V komentarjih lahko omenjamo druge

uporabnike in jih na tak način izzovemo na pomoč, pogovor o primeru, nalogi ali prilogi.

Tako je namen komentarjev sprožiti pogovor v sklopu primera in vpletene uporabnike

spodbuditi k hitrejšemu, učinkovitejšemu reševanju.

4.3.12.2 Priloge (Aktivnost primera)

Vsak primer lahko ima več prilog. Prilogo, ki jo dodamo se v uporabniškem vmesniku

prikaže v skupnem pregledu prilog, prav tako pa se prikaže v sklopu aktivnosti (komentarji

in naloge).

Namen prilog je pomoč in dopolnjevanje primera in njegovih aktivnosti. Priloga dopolnjuje

primer, oziroma nalogo z dodatnimi zunanjimi informacijami in dokazili.


Slika 4.12: ER diagram aktivnosti (Naloge, Komentarji in Priloge)

4.3.13 Iskanje primera

Iskanje primera je urejeno preko iskalnika v ACM orodju in znotraj generalnega iskalnika v

orodju CRM.

Z iskanjem znotraj ACM orodja je tako mogoče iskati primer po naprej definiranih iskalnih

lastnostih primera. Tako je iskanje omejeno na zadevo, tip primera in značke (#tags) primera.


Prav tako je omogočeno iskanje po lastnostih naročnika, ki so definirane znotraj CRM orodja

(naziv, naslov, elektronski naslov,…).

4.3.14 Seznami primerov

Pregled seznamov s primeri je ena izmed ključnih osnovnih funkcionalnosti s strani nadzora

in organizacije dela v oddelkih. Služijo tudi kot pregled stanja in trenda, ki je v danem

trenutku v določenem oddelku ali nasplošno v podjetju.

Tako smo za lažje upravljanje primerov pripravili nekaj seznamov, po katerih si uporabniki

lahko organizirajo delo. Seznami so deljeni tako po primerih kot po aktivnostih, oziroma

nalogah.

- Seznam opazovanih primerov:

V seznamu so zbrani vsi primeri, v katerih nastopa izbran uporabnik in je določen

kot opazovalec primera.

- Seznam skrbniških primerov:


kot skrbnik primera.

- Seznam kreiranih primerov:


kot kreator primera.

- Seznam primerov skrbniških oddelkov:

V seznamu so zbrani vsi primeri, v katerih nastopa izbran oddelka in je določen kot

skrbniški oddelek.

- Senam izvajalnih nalog:


kot izvajalec naloge.


- Seznam vpletenih aktivnosti

V seznamu so zbrani vsi primeri, kjer je izbran uporabnik povezan z aktivnostmi

(izvajalec/kreator naloge, avtor komentarja ali je v komentarju pozvan oziroma

nastopa kot uporabnik, ki je dodal prilogo k primeru).

- Seznam izvajalnih nalog oddelka:

V seznamu so zbrani vsi primeri v katerih nastopa izbran uporabnik in je določen kot

izvajalec naloge.

- Seznam šablon

V seznamu šablon so prikazani vsi primeri, ki so označeni kot šablonski primeri in

jih lahko uporabimo za lažje in hitrejše reševanje pogostih problemov.

Seznami imajo možnost klasičnega upravljanja, kar pomeni da lahko sezname sortiramo in

filtriramo po izbranih parametrih, ki niso zajeti v zgoraj definiranih seznamih. Ti parametri

so: status, prioriteta, tip in datum vpisa. Seznami (razen seznam šablon) imajo omogočene

dodatne funkcionalnosti. Tako imamo funkcionalnost masovnega določanja skrbnikov in

spreminjanja statusa primerov ( »zaključen«, »preklican«, »ponovno odprt«).

4.3.15 Pregled statistik

V seznamih in grafih je mogoče videti, koliko primerov je bilo v določenem časovnem

obdobju ustvarjenih, rešenih, preklicanih,… Namen funkcionalnosti je lažje upravljanje

primerov, dodeljevanje in splošen pregled stanja v danem obdobju. Tako lahko na preprost

način organiziramo delo, dopuste in ostale aktivnosti znotraj oddelkov.


4.4 Uporabniški vmesnik

Kot smo že omenili v začetku tega poglavja, je uporabniški vmesnik ključna komponenta

vsake aplikacije, orodja ali sistema. Preko uporabniškega vmesnika (UI) poteka glavna

interakcija med uporabnikom in sistemom. Vloga uporabniškega vmesnika pa ni

samoumevna, ampak igra ključno vlogo pri tem, ali določena aplikacija služi svojemu

namenu. Tako uporabnik prej sprejme sistem, če ima ta dober uporabniški vmesnik –

upošteva uporabniško izkušnjo (UX) in nima tako dobro poslovno logiko, kot če je ta zadeva

obratna.

Tako smo pri razvoju vmesnika dali velik poudarek na uporabniški izkušnji in na ta način

poskušali čim bolje modelirati uporabniški vmesnik. Kot osnovo za uporabniški vmesnik

smo vzeli orodje Asana, ki smo ga že omenili v prejšnjih točkah in je prikazan na spodnji

sliki [Slika 4.13]. Orodje ima preprosto minimalistično obliko (design), kar poveča njegovo

preglednost. Tudi sami smo pri razvoju našega orodja na začetku imeli podoben uporabniški

vmesnik, kar pa se z nadaljnjim razvojem ni izšlo. Z razvojem orodja se je povečalo število

funkcionalnosti, kar je postopoma vplivalo tudi na uporabniški vmesnik. Uporabniški

vmesnik je postajal vedno bolj natrpan in s tem vedno manj pregleden. Rešitev smo našli z

vpeljavo različnih tipov primera. Tako smo določene funkcionalnosti prestavili samo na

določene tipe (prijava tehnične napake, prijava reklamacije in splošen tip).

V času razvoja našega orodja se je pod okriljem konzorcija OMG razvijal tudi standard

CMMN, katerega člani so izdali primer vmesnika, kot so si ga zamislili sami in je prikazan

na spodnji sliki [Slika 4.14].

V zadnjih verzijah orodja smo tako identificirali in dodelali najbolj pomembno področje

primera. Ta področje so aktivnosti, ki smo jih razdelili na naloge, komentarje in priloge. Vse

te aktivnosti smo združiti v kronološko zaporedje, kjer so aktivnosti predstavljene kot

komunikacija in razvoj primera.


Vmesnik Asana:

- 1. Opazovalci primera

- 2. Dodajanje komentarjev in nalog

- 3. Zadeva in opis primera. Nad opisom se nahaja kreator, rok in nekaj

funkcionalnosti orodja Asana

- 4. Dodani komentarji in naloge, katere imajo na desni strani prikazanega izvajalca in

komentar, v kolikor ga imajo. Na levi strani je prikazan status naloge

(zaključen/nezaključen)

- 5. Zbrane aktivnosti – naloge, ki so vezane na uporabnika

Slika 4.13 Primer orodja Asana (vir: http://asana.com)


Primer vmesnika članov OMG in ACM Community:

- 1. Prikaz osnovnih podatkov primera

- 2. Prikaz mejnikov in vizualizacija doseženih mejnikov

- 3. Možne aktivnosti na primeru

- 4. Zgodovina opravljenih aktivnosti na primeru

- 5. Prihodnje aktivnosti na primeru

- 6. Pregled prilog primera

Slika 4.14: Primer ACM vmesnika (predlogu OMG in ACM Community) (Vir: http://www.opitz-consulting.com/fileadmin/redaktion/pdf/sonstiges/acm-in-practice_poster-a3_sicher.pdf)


Primer našega vmesnika (upravljanje primera):

- 1. Komentarji in priponke

- (v tej fazi vmesnika je še ločeno od nalog – točka 4.)

- 2. Osnovni podatki primera

- (v tej fazi je samo en skrbnik in en oddelek)

- 3. Povezan naročnik

- 4. Naloge primera

- 5. Opazovalci primera

- (v tej fazi razvoja, samo en tip opazovalcev)

- 6. Zgodovina primera (Audit log)

- 7. Povezani primeri

- 8. Status primera

- 9. Prioriteta primera


Slika 4.15: Uporabniški vmesnik za upravljanje primera


Drugi del implementacije uporabniškega vmesnika so seznami. Sami seznami niso bili

deležni posebnih namenskih prilagoditev in modifikacij.

Implementacije seznamov smo se tako lotili po tabelaričnem principu. Vsi podatki oziroma

instance primerov in nalog so razporejeni po vrsticah. Na vrhu seznama je tako filter in

funkcionalnost za sortiranje po željenih parametrih. Na dnu seznama pa tako prikazano

število primerov, oziroma nalog po izbranem kriteriju in število strani oziroma indikator, na

kateri strani seznama se nahajamo.

Primer našega vmesnika (seznami primerov):

- 1. Filter naprej definiranih seznamov, kot je predstavljeno v poglavju »Pregled

seznamov«

- 2. Filter po statusih primera (Novo, V obdelavi, Zaključeno, Preklicano, Ponovno

odprto)

- 3. Seznam vseh primerov, ki ustrezajo filtru seznama in statusa, z vsemi osnovnimi

podatki primera (status, prioriteta, skrbniki, zadeva, naročnik,…)

- 4. Izbran seznam primerov

- 5. Seznam nalog, ki je enak seznamu primerov

- 6. Seznam aktivnosti, ki jih prijavljen uporabnik opravi v orodju ACM (audit log

uporabnika)


Slika 4.16: Uporabniški vmesnik seznama primerov


4.5 Vloge uporabnikov v orodju ACM

V sistemu imamo implementiranih več vlog, ki so hierarhično prikazane na spodnji sliki

[Slika 4.17]. Namen vlog je čim bolje povezati sodelovanje pri reševanju primerov in

aktivnosti ter tako organizirati delo in obveščanje. Zelo je pomembno, da z obveščanjem ne

pretiravamo, saj s tem zmanjšamo odzivnost, sledljivost in pomembnost obvestil pri

uporabnikih orodja ACM.

Slika 4.17: Vloge in glavne enote sistema ACM


Vloge na primeru:

- Kreator:

Opcijski parameter – pri kreaciji preko maila ni nujno, da sporočitelj obstaja v

sistemu. Namen vloge je, da uporabnik prijavi zadevo in ne želi, oziroma nima niti

znanja, da bi kakorkoli aktivno sodeloval v obdelavi primera. Obstajajo različni

razlogi ali potrebe po iskanju primerov, ki jih uporabnik sproži.

- Opazovalci:

o Privzet: Klasičen opazovalec je obveščen o vseh aktivnostih na primeru –

dodana aktivnost (naloga, komentar, priloga), sprememba statusa primera,

sprememba prioritete…

o Nadzornik: Obveščanje je omejeno samo na spremembe statusa primera

(zaključen/preklican/ponovno odprt) in urgentno prioriteto.

- Skrbnik:

Je uporabnik, ki prevzame nalogo ali skrbništvo primera. Uporabnik s to vlogo skrbi,

da se stvari odvijajo, ter upravlja in posreduje, če se stvari ne odvijajo kot bi se

morale.

- Skrbniški oddelki (ročno ali avtomatsko dodana vloga preko dodanih skrbnikov):

Največji pomen vloge je v času, ko primer še nima določenega skrbnika. Primer se

dodeli oddelku, ki ima v veliki večini domensko znanje za upravljanje in znotraj

katerega se nato določi skrbnik (vpletenih oddelkov je lahko tudi več, odvisno od

narave primera). Skrbniški oddelek je lahko določen tudi preko skrbnika (oddelek

kateremu pripada skrbnik).


Vloge na aktivnostih (Naloga, Priloga, Komentar):

- Kreator (naloga, komentar, priponka):

Namen vloge je predvsem v interakciji pri reševanju aktivnosti. Aktivnost v veliki

večini sproži uporabnik, ki nekaj potrebuje. To aktivnost nekomu dodeli in ko bo

aktivnost zaključena, mora sistem vedeti, kdo potrebuje povratno informacijo. Služi

pa tudi temu, da izvajalec, ki je prejel oziroma obdeluje aktivnost in potrebuje

dodatno informacijo, ve na koga se je potrebno obrniti za dodatna pojasnila v kolikor

so potrebna.

- Izvajalci naloge / omenjeni v komentarju:

Namen vloge je, da vemo kdo izvaja nalogo. V primeru komentarja in omenjanja

uporabnika vemo, koga mora sistem obvestiti o dodanem komentarju.

- Izvajalni oddelki (ročno ali avtomatsko dodana vloga preko dodanih izvajalcev):

Namen vloge je, podoben kot pri skrbniških oddelkih na primeru. Naloga se dodeli

oddelku, ki ima v veliki večini domensko znanje za upravljanje in znotraj katerega

se nato določi skrbnik.


5 ZAKLJUČEK

V diplomskem delu smo se lotili reševanja problema, s katerim se srečuje velika večina

večjih podjetij. Reševanje in spopadanje s tem problemom v veliki meri predstavlja izziv

podjetjem, ki imajo večje število naročnikov, storitev ali produktov. Ta podjetja za hitrejše

in lažje prilagajanje razmeram na trgu, potrebujejo za opravljanje svojega dela, orodja, ki

omogočajo agilne pristope. Orodja za nestrukturirano upravljanje procesov pa s svojo

dinamiko omogočajo ravno ta pristop, ki omogoča reševanje vseh nepredvidenih, novih in

zapletenih primerov, na sledljiv in transparenten način.

V prvem delu diplomskega dela smo se dotaknili tradicionalnih pristopov upravljanja

procesov oziroma načrtovanja strukturiranih procesov s pomočjo BPMN notacije.

Predstavili smo idejo in delovanje upravljanja nestrukturiranih procesov, in CMMN

notacijo, s katero opisujemo nestrukturirane procese. Prav tako smo poiskali podobnosti in

razlike med strukturiranimi in nestrukturiranimi procesi.

Drugi del diplomske naloge smo posvetili razvoju in vpeljavi orodja za upravljanje

nestrukturiranih procesov. Reševanje, raziskovanje in razvoj aplikacije smo v našem primeru

uvedli v podjetje, ki ponuja široko paleto telekomunikacijskih storitev. Za razvoj aplikacije

smo imeli idealne pogoje, saj smo lahko hitro spreminjali in nadzorovali, v kakšni meri

določene funkcionalnosti vplivajo na reševanje primerov. Pri razvoju orodja smo se bolj kot

generičnemu razvoju, posvetili specifikam podjetja. V podjetju za reševanje primerov poteka

veliko medoddelčne komunikacije in dodeljevanja nalog. Tako smo pri razvoju aplikacije

dali velik poudarek komunikaciji, obveščanju in dodeljevanju nalog.

Brez tovrstne rešitve lahko podjetje hitro privede do točke, kjer se ne posveča rasti, strankam

in trgu, saj večino časa posveti obvladovanju lastne situacije. Težava je v veliki meri v tem,

da zaposleni v podjetju vse več časa posvetijo raziskovanju in poizvedovanju, kje so

določeni primeri obstali, oziroma kako daleč je njihov proces reševanja. Pri tem se izgubi

kakovosten čas, pridobljeno znanje, upada kakovost storitev in produktov, vse to pa vodi v

zaviranje rasti podjetja.

Izvor naših težav pri nestrukturiranih procesih je izviralo iz večih medsebojno nepovezanih

sistemov in uporabe različnih komunikacijskih kanalov. Prav to je povzročalo


nezadovoljstvo naročnikov in posledično stopnjevalo pritisk na zaposlene. Te težave pa so

v veliko primerih privedle do izpada planiranega dela. Z razvojem in vpeljavo orodja ACM

smo odpravili veliko večino teh težav. Z uvedbo orodja smo tako za več kot polovico

zmanjšali promet preko elektronske pošte, zmanjšala se je prav tako komunikacija preko

skype orodja in internih telefonskih pogovorov. Posledično se je tako zmanjšal tudi čas

reševanja vseh nestrukturiranih primerov.

Orodje ponuja reševanje nestrukturiranih kot tudi strukturiranih primerov, s shranjevanjem

tako imenovanih šablon oziroma vzorcev, kjer lahko določimo, kako se bo določena zadeva

reševala in katere naloge so v teh primerih potrebne. Z vpeljavo metode podatkovnim

rudarjenjem, bi lahko dosegli, da nam orodje samo predlaga optimalno pot reševanja

primerov, na podlagi podobnih predhodno rešenih primerov. Z nekaj manjšimi

spremembami in ločitvijo internih orodij bi lahko aplikacija postala uporabna tudi širšemu

trgu, kjer se podjetja spopadajo s podobnimi težavami.


6 VIRI, LITERATURA

1. »Business process«, Wikipedia, [spletni vir].

https://en.wikipedia.org/wiki/Business_process [dostopno: 30.1.2016]

2. »What is BPM?«, Workflow Management Coalition, [spletni vir].

http://wfmc.org/what-is-bpm [dostopno: 31.1.2016]

3. »BPMN Tools - A Comparative Analysis to Improve Interoperability«, Shefali N.

Pawar, [spletni vir].

http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1044&context=techmasters

[dostopno: 31.1.2016]

4. »Business Process Model And Notation«, Object Management Group, [spletni vir].

http://www.omg.org/spec/BPMN/2.0/ [dostopno: 1.2.2016]

5. »BPM Lifecycle«, PNMsoft Ltd., [spletni vir].

http://www.pnmsoft.com/resources/bpm-tutorial/bpm-lifecycle/ [dostopno:

3.2.2016]

6. »Learning BPMN 1 – What is BPMN?«, Roland Woldt, [spletni vir].

http://www.ariscommunity.com/users/roland-woldt/2010-11-28-learning-bpmn-1-

what-bpmn [dostopno: 5.2.2016]

7. »XML Process Definition Language (XPDL)«, WfMC, [spletni vir].

http://www.xpdl.org/standards/xpdl-2.2/XPDL%202.2%20(2012-08-30).pdf

[dostopno: 5.2.016]

8. Tom Koulopoulos, »Taming the Unpredictable, Real World Adaptive Case

Management: Case Studies and Practical Guidance«, 2011

9. »What is Adaptive Case Management (ACM)?«, Max J. Pucher, [spletni vir].

http://www.adaptive-case-management.com [dostopno: 11.2.2016]

10. »Adaptive Case Management«, Keith Swenson, [spletni vir].

http://www.xpdl.org/nugen/p/adaptive-case-management/public.htm [dostopno:

11.2.2016]

11. »Introduction to ACM«, Max J. Pucher, [spletni vir]. http://www.isis-

papyrus.com/e15/pages/videopages/videopage-ACM-intro.html [dostopno:

12.03.2016]


12. Hamid R. MotahariNezhad, Susan Spence, Claudio Bartolini,..., »Casebook: A

Cloud-Based System of Engagement for Case Management«, 2013

13. »WfMC Awards for Case Management«, WfMC, [spletni vir].

http://adaptivecasemanagement.org/ [dostopno: 14.3.2016]

14. »Case Handling: A New Paradigm for Business Process Support«, Wil M.P. van

der Aalst, Mathias Weske, Dolf Grunbauer, [spletni vir].

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.443.6257&rep=rep1&typ

e=pdf [dostopno 1.4.2016]

15. »Case Management Model And Notation«, Object Management Group, [spletni

vir]. http://www.omg.org/spec/CMMN/ [dostopno: 1.4.2016]

16. »5 Scenarios for Using Adaptive Case Management«, Kris Nelson, [spletni vir].

http://www.avioconsulting.com/blog/5-scenarios-using-adaptive-case-management

[dostopno: 2.4.2016]

17. »EMRIS - Enotna metodologija razvoja informacijskih sistemov«, Ministrstvo za

javno upravo, [spletni vir]. http://www2.gov.si/mju/emris.nsf [dostopno: 5.4.2016]

18. »Iterative and incremental Drupal development«, Vesa Palmu, [spletni vir].

http://www.wunderkraut.com/blog/iterative-and-incremental-drupal-

development/2015-01-08 [dostopno: 5.4.2016]

19. »Adaptive Case Management«, ISIS Papyrus Communication and process

platform, [spletni vir]. http://www.isis-papyrus.com/e15/pages/business-

apps/acm.html [dostopno: 5.4.2016]


7 PRILOGE

7.1 Seznam slik

Slika 2.1: Življenjski cikel v BPM pristopu .......................................................................... 6

Slika 2.2: Časovnica razvoja standarda BPMN ..................................................................... 7

Slika 2.3: Primer BPMN aktivnosti ....................................................................................... 8

Slika 2.4: Primer poslovnega procesa: ustvarjanje el. naslova v notaciji BPMN 2.0 ......... 16

Slika 2.5: Prilagodljivi procesi ............................................................................................ 18

Slika 2.6: BPM proces upravlja s podatki ........................................................................... 20

Slika 2.7: Podatki v ACM upravljajo s procesi reševanja ................................................... 20

Slika 2.8: Aktivnosti, ki pripeljejo primer do cilja .............................................................. 26

Slika 2.9: Primer odvisnosti aktivnosti s stražarjem (Sentry) ............................................. 33

Slika 2.10: Dekoraterji CMMN (v možnih kombinacijah).................................................. 34

Slika 2.11: Primer priprave zavarovanja ............................................................................. 36

Slika 3.1: Tok el. pošte – prikaz spregleda/izgube zaradi večnitnega sporočila ................. 41

Slika 3.2: Primer dobre uporabe orodja Skype .................................................................... 42

Slika 3.3: RT - Request Tracker .......................................................................................... 43

Slika 3.4: Mantis - Bug Tracker .......................................................................................... 44

Slika 4.1: Pristop iterativnega razvoja ................................................................................. 47

Slika 4.2: Primerjava Agilne in klasične metode razvoja [18] ............................................ 48

Slika 4.3: Moduli informacijskega sistema ......................................................................... 49

Slika 4.5: Podatkovna komunikacija ................................................................................... 51

Slika 4.6: Primeri uporabe v orodju ACM .......................................................................... 52

Slika 4.7: UML ustvarjanje primera .................................................................................... 53


Slika 4.8: Življenjski cikel primera ..................................................................................... 54

Slika 4.9: Diagram poteka spremembe statusa primera ...................................................... 56

Slika 4.10: Primer uporabe, spremembe prioritete .............................................................. 59

Slika 4.11: ER diagram primera .......................................................................................... 63

Slika 4.12: Življenjski cikel naloge ..................................................................................... 64

Slika 4.13: ER diagram aktivnosti (Naloge, Komentarji in Priloge) .................................. 66

Slika 4.14 Primer orodja Asana ........................................................................................... 70

Slika 4.15: Primer ACM vmesnika (predlogu OMG in ACM Community) ....................... 71

Slika 4.16: Uporabniški vmesnik za upravljanje primera ................................................... 73

Slika 4.17: Uporabniški vmesnik seznama primerov .......................................................... 75

Slika 4.18: Vloge in glavne enote sistema ACM ................................................................ 76


7.2 Seznam tabel

Tabela 2.1: BPMN elementi dogodkov ............................................................................... 10

Tabela 2.2: BPMN elementi aktivnosti ............................................................................... 11

Tabela 2.3: BPMN elementi vejitev .................................................................................... 12

Tabela 2.4: BPMN elementi toka zaporedja ........................................................................ 13

Tabela 2.5: BPMN element bazena in steze ........................................................................ 14

Tabela 2.6: Procesno upravljanje in upravljanje primera .................................................... 22

Tabela 2.7: Elementi CMMN notacije za CasePlanMode, Case File in Stage .................... 29

Tabela 2.8: Najpogostejši CMMN elementi nalog (Tasks) notacije ................................... 30

Tabela 2.9: CMMN oblike elementa mejnik ....................................................................... 31

Tabela 2.10: Oblike prožilcev v CMMN notaciji ................................................................ 32




Documents

RAZVOJ IN VPELJAVA ORODJA ZA UPRAVLJANJE … · Razvoj in vpeljava orodja za upravljanje nestrukturiranih procesov Stran 6 Slika 2.1: Življenjski cikel v BPM pristopu Po pridobljenih