UNIVERZA V LJUBLJANI EKONOMSKA FAKULTETA

Transcription

1 UNIVERZA V LJUBLJANI EKONOMSKA FAKULTETA MAGISTRSKO DELO RAZVOJ IN UVAJANJE STRATEŠKEGA INFORMACIJSKEGA SISTEMA KORPORACIJE LJUBLJANA, BOŠTJAN TUŠAR

2 IZJAVA Študent Boštjan Tušar izjavljam, da sem avtor tega magistrskega dela, ki sem ga napisal pod mentorstvom prof. dr. Andreja Kovačiča in skladno s 1. odstavkom 21. člena Zakona o avtorskih in sorodnih pravicah dovolim objavo magistrskega dela na fakultetnih spletnih straneh. V Ljubljani, dne Podpis:

3 POVZETEK Magistrsko delo obravnava projekt izgradnje strateškega informacijskega sistema korporacije za pokrivanje področja industrijske prodaje. Izzivi v projektu so heterogena informacijska okolja v korporaciji in vsebinsko nedefinirano področje. Posebnost informacijskega sistema je modul za spremljanje investicij, ki so vezane na prodajne projekte. Ključne besede: vodenje projektov / strateški management / analiza / management / poslovanje podjetja / vrednote / cilj / B2B / industrijska prodaja / strateški informacijski sistem / ERP / CRM / PIS / outsourcing / projekt / OLAP / BI /.NET / baze podatkov / ključni uporabniki / prožilci / EBITDA / šifranti / investicije SUMMARY This work deals with the project of building a strategic corporate information system for industrial sales support. The challenges in project are heterogeneous IT environments in corporation and undefined contents in sales logistics. Speciality of information system is a module for managing investments that are connected to sales projects. Key words: project management / strategic management / analysis / management / company performance / values / goal / B2B / industrial sales / strategic information system / ERP / CRM / BIS / outsourcing / project / OLAP / BI /.NET / databases / key-users / triggers / EBITDA / lists / investments

4 KAZALO POGLAVIJ 1. UVOD PODROČJE DELA CILJI IN NAMEN DELA METODA DELA OPIS PROBLEMATIKE DEFINICIJA INFORMACIJSKIH SISTEMOV SISTEM ERP STRATEŠKI INFORMACIJSKI SISTEM INFORMACIJSKI SISTEM ZA PODPORO PRODAJNI FUNKCIJI INFORMACIJSKI SISTEM ZA PODPORO POSLOVNEMU ODLOČANJU ORGANIZACIJA KORPORACIJE HIDRIA ORGANIZACIJA PRODAJNE FUNKCIJE V KORPORACIJI ORGANIZACIJA INFORMACIJSKEGA SISTEMA ANALIZA POSLOVNE UPRAVIČENOSTI SIS PROJEKT RAZVOJA IN UVAJANJA STRATEŠKEGA INFORMACIJSKEGA SISTEMA V KORPORACIJI HIDRIA SESTAVA PROJEKTNE SKUPINE TERMINSKA IN STROŠKOVNA OPREDELITEV PROJEKTA Terminski plan Analiza stroškov Nadzor izvajanja PREGLED OBSTOJEČIH PROGRAMSKIH REŠITEV ZA PODPORO PRODAJNI FUNKCIJI Infor BaaN CRM Microsoft Dynamics CRM Samostojno razviti CRM program PROJEKT IZDELAVE PILOTNE APLIKACIJE IZBIRA ZUNANJEGA IZVAJALCA ZA IZDELAVO APLIKACIJE UPORABLJENE TEHNOLOGIJE Platforma Razvojno orodje Baza podatkov Povezava z obstoječimi uporabljanimi tehnologijami Varnost USKLADITEV ZAHTEV IN POTREB Z BODOČIMI UPORABNIKI SISTEMA Pregled obstoječih individualnih baz podatkov Individualni razgovori z uporabniki Definicija matrike uporabnikov Priprava šifrantov Predstavitev rešitve uporabnikom IZDELAVA APLIKACIJE IN TESTIRANJE Diagram uporabe Strukturni diagram Podatkovni model Kodiranje DODATNI MODUL INVESTICIJE IN POTRJEVANJE PROJEKTOV Vzroki za nastanek modula Pristop k implementaciji Dodatek - potrjevanje projektov DEFINIRANJE UPORABNIŠKIH IZPISOV V APLIKACIJI Osnovni izpisi Izpeljani izpisi Izpisi v modulu Investicije Servisni izpisi UPORABNIŠKA DOKUMENTACIJA OCENA USPEŠNOSTI PROJEKTA...76

5 7. ZAKLJUČEK...79 SLOVAR KRATIC...82 UPORABLJENA LITERATURA...83 UPORABLJENI VIRI...86 KAZALO TABEL Tabela 1: Najbolj razširjeni tuji in domači ERP sistemi na slovenskem trgu:... 6 Tabela 2: Uporabljana orodja BI v Sloveniji Tabela 3: BaaN moduli v uporabi Tabela 4: Subjektivno in objektivno odločanje glede na stopnjo gotovosti Tabela 5: Predstavniki širše projektne skupine po prodajnih programih v korporaciji Tabela 6: Aktivnosti na projektu s predvidenim trajanjem Tabela 7: Uteženi parametri za izbiro zunanjega izvajalca Tabela 8: Običajne slabosti zunanjega izvajalca Tabela 9: Prožilci po dogodkih in vlogah - projekti Tabela 10: Objektivna lestvica verjetnosti izvedbe projekta Tabela 11: Matrika uporabnikov - vloge Tabela 12: Šifrant Group-Program-Product Tabela 13: Šifrant Division-Application-System-Complex Tabela 14: Modul za investicije: predhodna opredelitev vnosnih polj Tabela 15: Prožilci po dogodkih in vlogah - investicije Tabela 16: Okvirni pregled enkratnih stroškov projekta KAZALO SLIK Slika 1: Shema evidenc o prodajnih projektih korporacije... 4 Slika 2: Ghordiantov pogled na CRM... 9 Slika 3: Struktura uporabnikov sistemov poslovne inteligence Slika 4: Organizacija prodajne funkcije perspektiva korporacije Slika 5: Organizacija prodajne funkcije - perspektiva družbe Slika 6: Aktivnosti izdelave ocene poslovne upravičenosti Slika 7: Vrste sistemov za podporo odločanju glede na stopnjo uporabnosti in poslovne vrednosti Slika 8: Stopnje v racionalnem modelu odločanja Slika 9: Pilotna aplikacija: prva vnosna maska Slika 10: Pilotna aplikacija: konsolidiran vpogled Slika 11: Povezljivost strežnika SQL z drugimi aplikacijami Slika 12: Grožnje varnosti informacijskemu sistemu Slika 13: Obveščanje o spremembah po elektronski pošti Slika 14: Definiranje pravic uporabnikov Slika 15: Diagram uporabe (Use-Case) Slika 16: Strukturni diagram Slika 17: Konceptualna podatkovna shema Slika 18: E-R diagram Slika 19: Obrazec za vnos investicijskega zahtevka Slika 20: Algoritem potrjevanja investicijskih zahtevkov Slika 21: Povezovanje investicij s projekti Slika 22: Potrjevanje projektov, ki so v fazi razvoja Slika 23: Potrjevanje projektov, ki so v fazi podpisovanja pogodbe... 70

6 Slika 24: Osnovni tabelarični izpis Slika 25: Uporabniška navodila... 75

7

8 1. Uvod Kadar se v podjetju s strani ključnih zaposlenih pojavi potreba po novem»programu«, ki bo podpiral ali kako drugače optimiziral določene poslovne procese, je projekt že napol poti do uspeha. Sledeče delo predstavlja enega od takšnih projektov, ki se je odvijal v slovenskih globalni korporaciji Hidria. Glede na to, da v korporaciji obstajajo številna podjetja z različnimi informacijskimi sistemi ali pa vsaj z različnimi viri podatkov, se je na nivoju korporacije oblikovala zavest, da je potrebno posamezna področja obvladati, torej imeti nad njimi pregled. Konkretno se je potreba po informacijskem sistemu za obvladovanje heterogenih virov podatkov pokazala najprej na prodajnem področju, natančneje, na področju strateške industrijske prodaje. Nedopustno je namreč dejstvo, da se z istim zunanjim kupcem pogovarjata dve podjetji iz skupne korporacije, ne da bi bili medsebojno usklajeni. Še bolj pomembno kot to pa je, da je za uspešno rast industrijske prodaje in s tem rast korporacije pomemben verodostojen pregled zgodovine, sedanjosti in predvsem prihodnosti. Konkretno želimo z novim informacijskim sistemom imeti transparenten pregled nad vsemi planiranimi prodajnimi projekti in se na podlagi tega ustrezno strateško odločati o nadaljnjih investicijah ali eventuelno opustitvah določenih prodajnih programov. Kot bomo videli v nadaljevanju, se je v informacijski sistem vključilo tudi spremljanje investicij, sprva tistih, ki so neposredno vezane na prodajne projekte, kasneje vseh investicij v korporaciji. Povezava investicij s prodajnimi (in tudi razvojnimi) projekti je zelo pomembna, saj nam da nujno potrebno informacijo o profitabilnosti projektov na dolgi rok, še posebej pa je ta informacija kakovostna, če imamo v sistemu zabeležene natančne napovedi prodaje za prihodnja leta. V nadaljevanju omenjeni projekt obravnavamo strukturirano in s pomočjo teoretičnih dognanj s področja informacijskih sistemov ter vodenja projektov Področje dela Naloga obravnava projekt vzpostavitve informacijskega sistema, ki bo v korporaciji podprl, organiziral in v večjem delu poenotil pregled nad prodajnimi projekti in omogočil tudi strateško načrtovanje prihodnjih aktivnosti tako na nivoju prodajnega programa, strateške poslovne enote, družbe, divizije in celotne korporacije. V sklopu projekta so obravnavani terminski, stroškovni, kadrovski, tehnični in vsebinski vidiki, ki jih je potrebno upoštevati ob gradnji vsakega informacijskega sistema

9 1.2. Cilji in namen dela Pri izdelavi magistrske naloge sem se osredotočil na celotni življenjski cikel projekta vzpostavitve informacijskega sistema, od začetne faze definiranja zahtev, do končne faze testiranja in vzdrževanja aplikacije. Raziskal sem: - tehnike projektnih pristopov, - managerski vidik, - strateške informacijske sisteme, - tehnološke dispozicije za vzpostavitev primernega informacijskega sistema. Raziskava zajema uvajanje informacijskega sistema z osnovnimi vprašanji: - ali res potrebujemo takšen sistem? - ali naj kupimo sistem na ključ ali naj ga izdelamo po meri? - kakšna naj bo projektna skupina, kakšen terminski plan, kakšna investicija v SIS (Strateški informacijski sistem)? - kakšne tehnologije bomo uporabili pri izdelavi, kako je z varnostjo? - na katere obstoječe module IS (informacijskega sistema) bomo vezali novi SIS? - kakšen bo odziv uporabnikov, kako bomo izdelek promovirali za uporabo? - kakšne bodo v končni fazi pridobitve novega sistema? Cilj raziskave je na izbranem primeru s pomočjo teoretičnih dognanj pokazati življenjski cikel implementacije strateškega informacijskega sistema in pokazati na odstopanja od teorije, ki so posledica specifik v realnem okolju Metoda dela Raziskava magistrskega dela v enem delu temelji na študiju domače in tuje strokovne literature ter različnih spletnih virov, v drugem delu pa je na podlagi obravnavane teorije prikazan praktični primer implementacije SIS, pri katerem aktivno sodelujem tudi sam kot član projektne skupine, zadolžen za tehnologije, dialog z izvajalcem in uporabniki ter za testiranje aplikacije v testnem okolju. 2. Opis problematike Slovenska globalna korporacija Hidria s petimi hčerinskimi družbami in znotraj tega trinajstimi različnimi prodajnimi programi ter ključno usmeritvijo v dve diviziji (Automotive, Klima) presega mejo, znotraj katere je obvladovanje podatkov in pregled nad dogajanjem na področju (večinoma industrijskih) prodajnih projektov še možno na tak način, kot do sedaj

10 V izhodišču ugotavljamo, da: vsaka hčerinska družba na svoj način vodi evidence o prodaji in o stanju prodajnih projektov, so evidence, poleg IS BaaN, večinoma vodene v Excelovih tabelah, je način vodenja evidenc in različnost tabel različen tudi znotraj ene družbe, so podatki, ki se evidentirajo različni, nekaj postavk pa se pojavlja pri večini prodajnih programov, je edina skupna točka podjetij IS BaaN, ki pa ne vsebuje podatkov, potrebnih za strateško načrtovanje in odločanje na področju prodaje, vseh možnosti, ki jih ponuja BaaN za planiranje prodaje, ne uporabljajo vsi nosilci prodajnih projektov. Iz naštetega sledi, da: tudi znotraj ene družbe ni možna enostavna in verodostojna analiza podatkov, ni kakovostne povezave med projekti oz. kupci, ki se pojavljajo na večih prodajnih programih, ni ustrezne komunikacije med tistimi prodajniki, ki se srečujejo pri istih kupcih, na nivoju korporacije ni sistema, ki bi omogočal pregled nad trenutnim stanjem, ne v družbah, ne na nivoju korporacije ni orodja, ki bi podprl analitični pristop za strateško odločanje o prodajnih projektih. Potreba po organiziranosti področja je privedla do odločitve o izgradnji informacijskega sistema, ki bo podprl, organiziral in v večjem delu poenotil pregled nad prodajnimi projekti in omogočil tudi strateško načrtovanje prihodnjih aktivnosti tako na nivoju prodajnega programa, strateške poslovne enote, družbe, divizije in korporacije. Informatika se v tem trenutku pojavlja kot ključno orodje za ugotavljanje poslovnih priložnosti na področju trženja, ki korporaciji poveča njeno konkurenčno prednost (Kovačič, 2004). Tak informacijski sistem bo poleg sistema ERP (Enterprise Resource Planning) del strateško-operativnega segmenta aplikacij, ki so kritične za vzdrževanje poslovne strategije v prihodnosti (Turban, 2004)

11 Slika 1: Shema evidenc o prodajnih projektih korporacije Vir: dokumentacija projekta Hidria SARA, 2007 Slika 1 ponazarja delitev odločanja glede prodajnih projektov na strateški in operativni nivo. Operativni nivo spremljanja projektov v korporaciji je že vzpostavljen, manjka strateški pregled (vrh piramide), ki je osnova za strateško odločanje. Način dela v projektu implementacije strateškega informacijskega sistema za spremljanje industrijskih prodajnih projektov v korporaciji je sledeč: vzpostavitev in organizacija projekta, preučitev zmožnosti obstoječega sistema ERP BaaN in drugih rešitev CRM na ključ, izbira zunanjega izvajalca za izdelavo aplikacije, uskladitev zahtev in potreb z bodočimi internimi uporabniki sistema, ki je posebej zahtevna v primeru mednarodne zasnove aplikacije in zahteva veliko večjo mero organiziranosti ter upoštevanje mednarodnih razlik (Turban, 2004), izdelava aplikacije, testiranje in produkcija, vzdrževanje in nadgradnje aplikacije. Cilji projekta so: Vzpostavitev centralnega pregleda nad strateškimi projekti, Aktivno spremljanje projektov na višjem nivoju, tudi skozi delovne tokove, ki se prožijo avtomatsko ali ročno in odkrivajo morebitne slabe člene v verigi ustvarjanja skupnih dobrih rezultatov (Kovačič, 2004), - 4 -

12 Pregled nad planom prodaje, Pregled nad planiranimi in realiziranimi investicijami, Elektronsko potrjevanje zahtevkov za investicije. 3. Definicija informacijskih sistemov V literaturi obstaja zelo veliko različnih definicij informacijskega sistema, navajamo nekaj od teh: - informacijski sistem je sistem, ki vključuje tri komponente: človeka, nalogo s podatki in aplikacijo. S tega stališča človek na podlagi interpretiranih podatkov (informacije) skozi aplikacijo pridobi dodatno znanje (Goltez, EF, 2005), - s tehnološkega stališča je informacijski sistem skupek naprav, ki avtomatsko ali na ukaz uporabnika procesirajo vhodne podatke v izhodne (Černetič, EF, 2006), - ena od grobih definicij pravi, da je informacijski sistem sistem atributov in njihovih vrednosti ( - informacijski sistem je v primerjavi s terminom»informacijske tehnologije«podsistem le-tega ( - verjetno najširše uporabna definicija pa je, da je informacijski sistem skupek uporabnikov, metod in naprav, s katerimi zbiramo, obdelujemo, prenašamo in interpretiramo podatke, ki uporabnikom pomenijo neko uporabno informacijo (ANS, ATIS, 2001). Ljudje torej z uporabo informacijskih tehnologij pridobivamo in prenašamo podatke, z namenom, da z njimi oblikujejo nove uporabne informacije, konkretno informacije v zvezi s poslovnimi procesi, če govorimo o poslovnih informacijskih sistemih (PIS). Dodatno lahko k tem definicijam pridamo še to, da je za dober informacijski sistem pomembno, da so procesi zajema, posredovanja in interpretacije podatkov časovno učinkoviti, da je kakovost informacije velika (torej da ni anomalij) ter da je splošna uporabnost pridobljenih informacij velika (kar je v konvencionalnih informacijskih sistemih odvisno od intuicije uporabnikov) Sistem ERP Sistem ERP je celovita programska rešitev; v najbolj osnovni definiciji je to konkretno sistem medsebojno povezanih aplikacij za planiranje virov v podjetju (Enterprise Resource Planning, S sistemom ERP upravljamo različna (ne nujno vseh) funkcionalna področjia v podjetju: materialno poslovanje, človeški viri, finančno poslovanje

13 Pomembna prednost sistemov ERP v primerjavi s klasičnimi informacijskimi sistemi je v modularnosti. To konkretno pomeni, da se lahko podjetje odloča, da svoj celoviti informacijski sistem gradi po delih, glede na potrebe. Če je podjetje na primer striktno proizvodno usmerjeno, z malo logističnega kadra, potem je zanj smotrno v prvih fazah uporabiti modul sistema ERP, namenjen materialnemu poslovanju. Šele sčasoma, ko podjetje raste, je smotrna in potrebna dograditev sistema z modulom za kadre in finance (upravljanje človeških virov in financ). Vsi različni moduli sistema ERP so med seboj kompatibilni, podatkovna baza je skupna in praviloma ena sama. Govorimo torej o sestavljanju in ne nadgrajevanju celovitega IS. Posebnost sistemov ERP je, da so zaradi uporabnosti za podjetja razširjeni po vsem svetu in zato prevedeni v različne jezike, imajo na desettisoče inštalacij, proizvajajo jih velika podjetja z velikim naborom različnih strokovnjakov tako s področja informacijskih tehnologij (IT) kot s področja poslovnih ved. Ostale specifike sistemov ERP: - dodelane dokumentacija in obstoječe znanje pospeši in poceni uvajanje sistema ERP, - skupni stroški lastništva sistema ERP so transparentni, - z nakupom sistema ERP kupimo veliko bazo znanja prejšnjih uporabnikov, ki je vgrajena v samo logiko sistema, - zunanja podpora sistemu ERP je praviloma dobra, - sistemi ERP so nadgradljivi zaradi že omenjene modularnosti, - po drugi strani pa so veliki»zacementirani«sistemi ERP nefleksibilni, ko se je potrebno prilagajati specifikam podjetja. Sisteme ERP je sicer možno sorazvijati z razvojnimi orodji (Developer Tools), toda poseganje v strukturo sistema ERP je lahko povzročitelj težav pri servisnih nadgradnjah (service upgrade, service pack), - prej omenjena zunanja podpora je lahko tudi slabost, saj to zahteva nenehno sodelovanje in usklajevanje zahtev podjetja preko predstavnikov. Tabela 1: Najbolj razširjeni tuji in domači ERP sistemi na slovenskem trgu: ERP sistem BaaN Oracle/PeopleSoft SAP ERP Grad skupina Microsoft Dynamics Bus. Sol., Navision Orkester SAOP ERP, SAOP PIS Perftech Largo Proizvajalec / ponudnik INFOR, S&T Oracle, Oracle Slovenija SAP, SAP Slovenija Grad d.d. Microsoft, Microsoft Slovenija MIT Inženiring SAOP Perftech Vir: Korenjak, EF,

14 3.2. Strateški informacijski sistem V preteklosti so bili informacijski sistemi notranje usmerjeni, kar pomeni, da so podpirali procese, ki so se po vertikali odvijali med posameznimi enotami v podjetju. Sčasoma dobijo informacijski sistemi tudi širino, tako da po horizontali omogočajo pretok informacij širšemu krogu zainteresiranih subjektov (tudi kupcem in dobaviteljem). Ta prenos informacij je eden od dejavnikov, ki nudi podjetju nadaljnji razvoj in konkurenčnost. Strateški informacijski sistem opredelimo (Debelak, 2002) kot sistem, ki podpira konkurenčno strategijo podjetja. Najpomembnejše je, da je SIS že sam po sebi konkurenčna prednost oziroma ključni dejavnik konkurenčnosti. Strateški informacijski sistem ima sposobnost temeljite spremembe načina poslovanja podjetja; lahko spreminja cilje, operacije, storitve, izdelke in razmerja v okolju, z namenom, da bi podjetje doseglo konkurenčno prednost. V osnovi so strateški informacijski sistemi zunanje usmerjeni, torej obravnavajo ali bolje rečeno podpirajo konkurenčnost podjetja napram zunanjim konkurentom. Kasneje se prično razvijati strateški IS, ki izboljšujejo notranje procese in s tem še vedno prispevajo k konkurenčnosti podjetja na račun izboljšanih notranjih procesov (npr. informacijski sistem, ki podpira sistem kakovosti 6-sigma je lahko za podjetje strateškega pomena). Poseben vidik strateškega informacijskega sistema predstavljajo povezave, kjer si eno ali več podjetij deli skupen SIS. Tak je tudi v nadaljevanju obravnavani primer, kjer si več podjetij, ali bolje rečeno, prodajnih programov znotraj korporacije deli en prodajno-analitični informacijski sistem. Z vidika strateške usmerjenosti podjetja mora biti SIS prilagodljiv sistem, saj v prvotni obliki ne more zagotavljati dolgoročne konkurenčne prednosti. Podjetje namreč lahko za krajši čas doseže konkurenčno prednost na trgu, npr. z diferenciacijo, hitrostjo, cenami, osredotočenjem ali prilagajanjem. Toda to so le kratkoročne konkurenčne prednosti, ki jih lahko konkurenca hitro posnema, ali pa jih prehitijo inovacije in zakonitosti trga. Zato mora imeti podjetje dodelano dolgoročno prednost pred konkurenti, to pa je strateška prednost. To prednost mora ohranjati in zato je tudi SIS sistem, ki ga je potrebno glede na čas spreminjati. Po (Debelak, 2002) so temeljni cilji strateškega informacijskega sistema naslednji: - nadzor nad izvajanjem poslovne strategije, - usmerjenost k strankam in konkurenčni prednosti podjetja, - podpora podjetju pri zagotavljanju uspešnega poslovanja, - sposobnost hitrega odzivanja na nastale spremembe v poslovnem okolju, - podpora poslovnim povezavam (navidezne organizacije), - 7 -

15 - podpora horizontalni in vertikalni povezavi z okolico, - optimalno prilagajanje prenovljenim poslovnim procesom, - zagotavljanje kakovostnih, verodostojnih in pravih informacij ob pravem času na pravem mestu, - podpora hitremu in učinkovitemu poslovnemu poročanju in odločanju, - zagotavljanje poslovnega obveščanja, - podpora upravljanju znanja (sposobnost hitrejšega učenja od konkurence), - vsestransko obvladovanje in učinkovito upravljanje virov poslovnega sistema, - možnost izrabe sodobnih informacijskih konceptov (skladišča podatkov, portali, elektronsko poslovanje) Informacijski sistem za podporo prodajni funkciji V osnovi je lahko sistem ERP kot osnovni sistem podjetja že kategoriziran kot sistem za podporo prodajni funkciji. Izdajanje računov kupcu, vpogled v zapadle terjatve, kupčevi naslovi ipd. so podatki, ki jih hrani centralni informacijski sistem. Toda ko govorimo o celovitem obvladovanju prodajne funkcije, potrebujemo sistem, ki bo kompletno podpiral vse aktivnosti povezane s kupci, od analiz trga s kupci, do organiziranja prodajne enote v podjetju. Takšnemu sistemu pravimo sistem za upravljanje odnosov s strankami (CRM - Customer Relationship Management). Samih definicij CRM-a je veliko, dosti manj pa definicij informacijskih sistemov za podporo CRM. Ena od zelo nazornih je (Mihelčič, 2001):»CRM je logični razvoj trženja podatkovnih zbirk in trženja na podlagi pridobljenih informacij o vedenju strank, ki jih hranimo v podatkovnih skladiščih. Če k temu dodamo še določeno stopnjo individualnosti oziroma aktivnosti, ki jih zahteva osebna obravnava strank skozi različne tržne poti (osebni stik, elektronska pošta, telefon, videokonference...), pa kmalu ugotovimo, da CRM povezuje številne procese in različne tehnologije v določeno logično celoto. Gre torej za globalno obravnavo vseh interakcij, v katere organizacija vstopa s stranko.«crm je torej zelo podoben sistemu ERP, le da je sistem ERP namenjen back-office integraciji (podpora zalednih procesov znotraj podjetja), sistem CRM pa je namenjen front-office integraciji, torej podpori procesom, ki se odvijajo med podjetjem in njegovo okolico. Pomembna razlika med sistemoma ERP in CRM pa je v tem, da sistem ERP lahko obstaja samostojno, medtem ko sistem CRM (vsaj v konvencialnih poslovnih okoljih) nujno sloni na sistemu ERP. V nadaljevanju si na sliki 2 poglejmo Ghoriandtov pogled na CRM, ki prikazuje interakcije podjetja s kupci skozi posamezne procese

16 Slika 2: Ghordiantov pogled na CRM KOLABORATIVNI CRM Neposredna interakcija Kiosk / ATM Spletna konferenca Večkanalno usklajena integracija Glasovna Elektronska pošta Neposredni dobavitelji Agenti Posredniki Partnerji Interakcija s stranko Tržne poti Usklajena integracija preko tržnih poti Trženje Prodaja Servis / podpora Front-office OPERATIVNI CRM ERP/ERM Upravljanje nabavne verige Procesi terjatev Integracija aplikacij Administracija Računovodstvo Operativa Back-office Integracija aplikacij ANALITIČNI CRM Analitika poslovne inteligence Podatkovni trg o aktivnostih stranke Podatkovni trg o stranki Podatkovni trg o izdelku / storitvi Splošno podatkovno skladišče stranke Vir: Greenberg,

17 Ghoriandtov pogled v grobem deli upravljanje s strankami v tri skupine: kolaborativno, operativno in analitično. V prvi skupini se odvijajo aktivnosti, ki so preko klasičnih in sodobnih tržnih poti neposredna interakcija s kupcem. V drugi skupini so aktivnosti, ki se tipično odvijajo znotraj podjetja in so potrebne za izvajanje interakcij s stranko (npr. administracija in računovodstvo). Ti dve skupini v našem primeru že obvladamo, ne obvladamo pa tretje skupine aktivnosti po tem modelu analitičnega dela. Zato bomo z aplikacijo za analitiko CRM napolnili podatkovno skladišče stranke z vključenimi informacijami o prodajnih programih (produktih) Informacijski sistem za podporo poslovnemu odločanju Informacijski sistem za podporo odločanju oz. sistem poslovne inteligence je širok pojem, ki označuje posamezne programske produkte ali skupke produktov, katerih naloga je uporabniku prikazovati izvorne podatke v obliki, ki ima za uporabnika čim višjo prezentacijsko vrednost. S kakovostnim BI orodjem bo uporabnik (tipično vodja, manager) imel boljšo predstavo o stanju v podjetju nasploh ali pa o stanju na posameznem segmentu poslovanja, npr. v financah. Sistemi za poslovno inteligenco tipično izkoriščajo slabosti sistemov ERP, ki so usmerjeni v transakcije in nudijo podatke na nižjem, operativnem nivoju. Kaj hitro management ugotovi, da to ni dovolj za njihovo kakovostno odločanje na višjem nivoju, zato se nekateri poslužujejo BI orodij, čeravno je res, da so nekatera takšna orodja že vgrajena v sklope ERP (tudi imenovani Direktorski informacijski sistemi). Slabost sistemov za poslovno inteligenco je v tem, da so relativno kompleksni za uporabo, sploh za višji management. Zato uporabo orodij BI (Business Intelligence) zasledimo predvsem pri operativnih managerjih, npr. vodjah proizvodnje, vodjah financ in računovodstva ipd. To so lahko orodja OLAP (OnLine Analytical Processing), orodja za podatkovno rudarjenje ali specifični informacijski sistemi, označeni kot»direktorski informacijski sistemi«. Razlogi za vpeljavo sistema poslovne inteligence so (Lesjak, 2005): - strategija zadrževanja strank, - manj investicij, optimizacija infrastrukture, - nadgradnja in razvoj novih storitev, - ustvarjanje vrednosti z dodajanjem novih vsebin, - razširitev uporabe na nova področja, - avtomatizacija poslovanja (manj poročil), - ukvarjanje z vsebino

18 Slika 3: Struktura uporabnikov sistemov poslovne inteligence IT razvijalci; 3,00% Poslovni analitiki; 13,00% Poslovni (netehnični); 84,00% Vir: Jaklič, Štemberger, EF, 2004/2005 Tabela 2: Uporabljana orodja BI v Sloveniji Orodja Business Intelligence v Sloveniji MS SQL 2005 Oracle Express MS OLAP Crystal Report (Business Objects) Discoverer MCE Report Smith MicroStrategy Navision Reports MS Excel Knosis Proclarity Seagate Analysis DSS Agent Gold Mine Lotus Notes Vir: Jaklič, Indihar, 2004/5 Na področju poslovne inteligence naj bi se 40% vseh projektov sploh nikoli ne končalo, od končanih pa jih 30% ni prispevalo dodane vrednosti ( Razloge za tako slabe razultate pripisujejo na eni

19 strani temu, da področje poslovne inteligence še ni zrelo (pomanjkanje kakovostnih ponudnikov, nezrelost uporabnikov), po drugi strani pa predvsem temu, da je za kakovosten sistem BI (Business Intelligence) potrebno imeti kakovostno podatkovno bazo, torej urejene podatke, kar pa v celotnem projektu vzpostavitve sistema poslovne inteligence predstavlja del ledene gore, ki je pod gladino. Dodatna dejstva v zvezi s sistemi za podporo poslovnemu odločanju (Lesjak, 2005): - kakovost informacij je odvisna od kakovosti vhodnih podatkov, - podatkovno skladišče ne rešuje težav transakcijskih sistemov (kontrole), - podatkovno skladišče ni namenjeno kot vir za nek drug transakcijski sistem (problem časovnega zamika in kakovosti podatkov), - sama izdelava rešitve predstavlja le 1/3 celotnega projekta. Bistvene pridobitve z uporabo sistemov poslovne inteligence (Jaklič, Indihar, 2004/5): - povečana produktivnost managerjev, analitikov in celotne organizacije (zaradi fleksibilnosti in hitrega dostopa do strateških informacij), - hitrejši razvoj informacijskih rešitev in bolj kakovostne storitve službe za informatiko, - hitrejši odziv na zahteve trga. 4. Organizacija korporacije Hidria Korporacija Hidria se osredotoča na razvoj, proizvodnjo in trženje sistemov in komponent za klimatizacijo, gretje in hlajenje, avtomobilsko industrijo ter električnih ročnih orodij. Prepoznavnost in ugled korporacije na globalnem tržišču gradi zaposlenih v 33 družbah na domala vseh svetovnih celinah. Stalna rast in dviganje konkurenčnosti temeljita na intenzivnih vlaganjih v lasten razvoj in raziskave ter snovanju inovativnih visokotehnoloških rešitev. Korporacija Hidria se uvršča med pet vodilnih svetovnih proizvajalcev lamel za elektromotorje, med štiri največje svetovne proizvajalce čepnih svečk za dizelske motorje ter med prve štiri evropske proizvajalce sistemskih rešitev za klimatizacijo, gretje in hlajenje velikih zgradb. Korporacija je drugi največji evropski proizvajalec elektromotorjev za polhermetične kompresorje. Divizije in programi Vodilo Hidriinih razvojnih prizadevanj so želje in potrebe kupcev, ki narekujejo ustvarjanje novih rešitev za hitro rastočo avtomobilsko industrijo, industrijo klimatizacije, gretja in hlajenja ter električnih ročnih orodij. Z visokotehnološkimi komponentami in sistemi za avtomobilski motor ter sistemom upravljanja z vozilom Hidria uspešno nastopa na hitro rastočem trgu avtomobilske industrije. Sodi v vrh

20 evropskih ponudnikov celovitih rešitev in komponent za industrijo klimatizacije, gretja in hlajenja, o čemer pričajo eminentne reference po vsem svetu. Električna ročna orodja odlikujejo zanesljivost, tradicija in kakovost, zaradi česar je Hidria cenjena tako med profesionalni uporabniki kot tudi mojstri, ki se obdelavi različnih materialov posvečajo v prostem času. Najsodobnejše rešitve korporacija Hidria razvija v treh divizijah: - Hidria Automotive, - Hidria Klima, - program Električna ročna orodja. Inovativni center Hidriini raziskovalci, inženirji in tehnologi se vsak dan ukvarjajo z razvojem novih izdelkov in storitev ter inovativnih proizvodnih procesov. Njihovo delo je usmerjeno tudi v stalno izboljševanje obstoječih izdelkov. V korporaciji je zavedanje, da je mogoče konkurenčnost na globalnem trgu ohranjati le z razvojem tehnološko dovršenih proizvodnih programov z višjim deležem vgrajenega znanja. Vsi ti izzivi so narekovali oblikovanje Inovativnega centra Hidrie, ki postaja vse močnejši povezovalni člen na področju razvoja inovativnega okolja za podporo razvoju novih izdelkov in tehnologij, uvajanju novih programov in razvoju inovacijske dejavnosti v vseh družbah korporacije. Inovativni center Hidrie združuje inštitute, tehnološke centre, inkubatorje za razvoj novih programov ter Hidriino Akademijo znanja. V korporaciji se spodbuja, redno spremlja in nagrajuje inovacijsko dejavnost vseh zaposlenih. Vizija korporacije Hidria v posameznih tržnih segmentih prevzema vodilno vlogo med najbolj prepoznavnimi in uglednimi evropskimi in svetovnimi korporacijami. Uspešnost poslovanja korporacija dosega s skupnim delom kreativnih in motiviranih sodelavcev, ki s svojim znanjem in strokovnostjo ustvarjajo inovativne rešitve za industrijo klimatizacije, gretja in hlajenja, avtomobilsko industrijo ter industrijo električnih ročnih orodij. Hidria je globalna, inovativna in odlična korporacija, ki z bogatimi izkušnjami preteklosti ustvarja najsodobnejše izdelke za prihodnost. V sodelovanju s kupci po vsem svetu išče kakovostne in zanesljive rešitve ter tako gradi dolgoročna poslovna partnerstva. Korporacija se zaveda, da je odgovorna tudi za prihodnje rodove, zato v skladu z načeli visoke družbene odgovornosti proizvaja okolju prijazne izdelke ter vlaga v razvoj lokalnih skupnosti, v katerih posluje. Vrednote v korporaciji Medsebojno spoštovanje: Zaposleni v Hidrii ustvarjajo ozračje odprtosti, zaupanja in sodelovanja. Prizadevajo si za visoko stopnjo medsebojnega spoštovanja

21 Pričakujejo odprto, iskreno in pravočasno komunikacijo. Kot globalna korporacija sprejema in ceni raznolikost zaposlenih. Moč sodelovanja: Zaposleni v Hidrii sodelujejo v timih in hkrati ohranjajo svojo individualnost. Cilj je ohranjanje svobode, ki jo posameznik potrebuje za uresničevanje osebnega zadovoljstva. Enotnost korporacije ustvarjajo zaposleni. Prava enotnost pomeni več kot združitev interesov posameznikov. Je rezultat ciljev in vrednot, ki jih delijo. Želja po odličnosti: Strategija Hidrie je: biti vodilna - v odnosih z našimi poslovnimi partnerji in stalnem izboljševanju tehnologij. Za zaposlene sta pomembna vsak poslovni izziv in priložnost. Spremembe predvidijo in jih izkoristijo sebi v prid. Spodbujajo nove ideje, nagrajujejo inovativnost, v razvoj korporacije vključujejo konstruktivne predloge vseh zaposlenih. Za ohranjanje svoje vodilne vloge nenehno iščejo poti do izboljšav na vseh področjih. Osebna poštenost: Zaposleni v Hidrii spoštujejo visoke etične standarde, ki predstavljajo vodilo vsega, kar delamo in govorimo. Zavezani so k odgovornemu ravnanju v vseh okoliščinah. So spoštovanja vredna korporacija s spoštovanja vrednimi ljudmi. Odgovornost do skupnosti: Hidria se zavezuje visoki stopnji družbene odgovornosti. Po svojih najboljših močeh spodbuja razvoj lokalnih skupnosti, v katerih posluje, tako s financiranjem najrazličnejših dejavnosti, kot tudi s svojim delom, družbenim udejstvovanjem in talenti zaposlenih. Zgodovina korporacije Hidria Zgodovina Hidrie sega v daljno leto 1936, ko je bil v švicarski družbi Perles of Switzerland izdelan prvi električni vrtalnik. Tudi v Sloveniji, natančneje v Kranju, ima proizvodnja Hidriinih električnih ročnih orodij dolgo tradicijo, saj so prvi izdelki nastali že leta Generacije strokovnjakov ter nenehno iskanje novih, boljših rešitev so ustvarili kakovostno in zanesljivo električno ročno orodje mednarodno priznanih blagovnih znamk Perles of Switzerland in Iskra ERO. Več kot petdesetletno zgodovino beležijo tudi Hidriini programi za industrijo klimatizacije, gretja in hlajenja. V začetku 60. let se je v Idriji začela proizvodnja in montaža instalacij centralnega ogrevanja, vodovodnih instalacij in klimatizacije. V 70. letih so začeli v Godoviču nastajati prvi prezračevalni elementi, v 80. pa so iz Spodnje Idrije v Združene države Amerike stekle prve dobave motorjev za hermetične kompresorje. V zadnjih letih Hidria Klima beleži hitro rast in pomeni enega največjih evropskih igralcev na svojem področju. Svoje razvojne potenciale usmerja v ustvarjanje celovitih rešitev za klimatizacijo, gretje in hlajenje zgradb ter komponent za sisteme klimatizacije, gretja in hlajenja

22 Čeprav je leta 1955 po slovenskih cestah vozil komaj kak avtomobil, se je v Tolminu drzno in vizionarsko pričela proizvodnja avtomobilskih svečk. V zgodnjih 70. letih so bile izdelane prve ogrevalne svečke za dizelske motorje, nekaj let kasneje še magnetni vžigalniki za male bencinske motorje. Pred desetletjem so v Spodnji Idriji za avtomobilsko industrijo začeli proizvajati program lamel, kasneje še komponent iz aluminija. Danes Hidria Automotive predstavlja vse pomembnejšega evropskega ponudnika celovitih inovativnih rešitev za avtomobilski motor ter sistem upravljanja z vozilom. Izdelki Hidrie so vgrajeni v avtomobile vodilnih evropskih blagovnih znamk. 4.1 Organizacija prodajne funkcije v korporaciji Zgodovinsko pogojeno je Hidria nastajala s prevzemi družb, od katerih je prevzela zelo heterogeno okolje v vseh oddelkih podjetij, tudi v prodaji. Z leti skupnega delovanja se je v Hidrii uveljavil koncept centralnega generalnega pokrivanja oz. koordiniranja prodajnih aktivnosti na področju poslovanja B2B. Področje poslovanja s končnimi kupci je ostalo nepokrito s strani korporacije, torej v domeni posameznih družb. Kljub temu, da govorimo o skupnem pokrivanju aktivnosti na področju trgovanja B2B, je to pokrivanje zelo generalno, torej omejeno predvsem na ključne (strateške) partnerje, in še to pretežno v diviziji Automotive. Slika 4 ponazarja organizacijo prodajne funkcije s perspektive korporacije. Iz nje je razvidno, da imajo posamezne v korporacijo povezane družbe svoje lastne prodajne oddelke, ki se delijo na B2C (Business to Customer) ter B2B (nekatere družbe imajo oboje), B2B pa dodatno na strateško prodajo in ostalo. Tisti prodajni programi, ki so opredeljeni kot strateški programi B2B, so vodeni s strani Hidriinega pooblaščenca. Ostali prodajni programi so domena posameznih družb

23 Slika 4: Organizacija prodajne funkcije perspektiva korporacije Hidria Družba 1 Družba 2 Družba 3... B2B Prodaja B2B Prodaja Koordinacija B2C Prodaja in trženje Vir: dokumentacija projekta Hidria SARA, 2007 Prodajna funkcija v posamezni družbi je organizirana klasično: prodajni oddelek je samostojen, ponekod združuje marketing in trženje, ponekod je to ločeno. Vsaka družba ima vodjo prodaje za svoj program. To organizacijo prikazuje slika 5. Skozi takšno organizacijo prodajne funkcije je takoj razvidno, da gre za hierarhično urejenost, kar pomeni slabši prenos znanja, informacij in izkušenj kot bi bilo v primeru matrične ureditve. Kot bomo videli v nadaljevanju, bo strateški informacijski sistem zgradil most tako med vodjami prodaje po programih kot med prodajniki samimi. Konkretno to pomeni, da bodo prodajniki iz enega programa družbe videli še ostale prodajne projekte in kupce iz sodenjih programov znotraj družbe. Še več, vodje prodaje bodo imeli generalni vpogled med prodajnimi programi različnih družb znotraj korporacije

24 Slika 5: Organizacija prodajne funkcije - perspektiva družbe Družba X Prodajni program 1 Prodajni program 2 Prodajni program X Vodja prodaje Vodja prodaje Vodja prodaje Prodajnik 1 Prodajnik 2... Prodajnik 1 Prodajnik 2... Prodajnik 1 Prodajnik 2... Vir: dokumentacija projekta Hidria SARA, Organizacija informacijskega sistema IS BaaN Večinski uporabljani informacijski sistem v korporaciji je zasnovan na celoviti programski rešitvi Infor BaaN. IS BaaN se je v korporaciji pojavil prvič leta 1999 v eni od družb, sledila je implementacija v sosednjih družbah v letih 2000, 2003, Posamezni osnovni moduli sistema so se razširili tudi po hčerinskih družbah v tujini, tako da je trenutna pokritost s sistemom okoli 90-odstotna. Ker je proizvajalec skozi čas nadgrajeval sistem ERP BaaN, obstajajo v družbah tri različne verzije sistema: - BaaN IV, - BaaN ERP, - Infor BaaN 6.1ln. IS BaaN je skozi zgodovino menjal tudi lastnike. Od prvotne družbe BaaN se je lastništvo v zadnjih letih preneslo preko korporacije SSA Global na korporacijo INFOR. INFOR ponuja integrirane poslovne rešitve za različne industrije, samostojne produkte na področjih kot so upravljanje z viri podjetja, planiranje in izvajanje verige preskrbe, upravljanje s kupci in dobavitelji, upravljanje z osnovnimi sredstvi, upravljanje z življenjskim ciklusom proizvoda, upravljanje s financami in učinkovitostjo podjetja kot tudi rešitve poslovne inteligence

25 Poleg BaaNa se za podporo poslovanju v eni družbi uporablja samostojno razviti IS i4 na platformi Windows. V BaaNu se znotraj korporacije uporabljajo naslednji moduli, ki jih prikazuje tabela 3: Tabela 3: BaaN moduli v uporabi Modul (področje) Proizvodnja Distribucija Vodenje nabave Vodenje prodaje Nabavne pogodbe Nabavna povpraševanja Statistika nabave Vodenje lokacij Finance Servis Plače in kadri Transport V teh modulih ni posebej podprta prodaja. Vse, kar osnovni ERP ponuja v zvezi s prodajo so fakture, na katere so vezani zneski, kupci, datumi in podobne postavke. Infor BaaN sicer ponuja modul CRM, toda v našem primeru se ne uporablja. Tudi podrobneje specificirani modul Distribucija se ne uporablja v celoti, temveč samo v naštetih podsklopih). Kot bomo videli v nadaljevanju, je prevladala odločitev za razvoj aplikacije po lastnih potrebah namesto dokupa modula CRM. BaaN arhitektura IS BaaN v vseh primerih sloni na: - podatkovni bazi Oracle Standard ter Oracle Enterprise, - HP strežniški platformi n4000, rp4440, rp5470, - operacijskih sistemih HP UX 11. Uporablja se tudi BaaNovo razvojno orodje BaaN Development Tools in specifični modificirani moduli za slovenski trg: - ITS ZT (zunanja trgovina), - ITS Blagajna, - ITS Plače in kadri

26 Na nivoju korporacije se podatki iz različnih informacijskih sistemov BaaN oz. iz različnih baz posameznih podjetij niso nikjer neposredno združevali. V zadnjem času sta se na področju poslovne analitike zgodila dva projekta: - OLAP - Pregled prodaje na nivoju korporacije OLAP V tem primeru je šlo za tri testne podprojekte, kjer so se iz podatkovnih baz Oracle pripravili podatki v podatkovno bazo MS SQL za potrebe analitike OLAP. Konkretno sta se izgradili dve OLAP kocki: kocka za analitiko kupcev in terjatev ter kocka za analizo procesov v proizvodnji (analiza zastojev delovnih operacij). Podatki so se zbirali na nivoju posamezne družbe iz njenih poslovnih enot. Arhitektura je bila zastavljena tako, da se podatki združujejo naprej na nivoju korporacije, a do realizacije ni prišlo. Za vpogled v podatke se je uporabljalo programsko orodje ProClarity. Pregled prodaje V tem primeru je prišlo do prvega avtomatskega enotenja podatkov iz informacijskih sistemov na nivoju korporacije. Šlo je za zahtevo po enostavnem pregledu celotne realizirane prodaje po posameznih časovnih obdobjih za posamezne družbe in seštevek na nivoju korporacije. Posebnosti pri enotenju ni bilo, saj je šlo za združevanje enostavnih podatkov, kot so ime kupca, datum fakture, znesek. Ostali sistemi za zbirne evidence Znotraj korporacije obstaja kvartalno finančno poročanje, katero se vodi v orodju Microsoft Excel. Definirane datoteke s predlogami prejmejo družbe, kjer služba za kontroling izvlečke iz svojih informacijskih sistemov ročno prepiše v zbirno datoteko Excel. Na področju prodaje zbirnih evidenc v preteklosti ni bilo, največ kar se je evidentiralo, so bili npr. seznami kupcev in zapisniki o prodajnih aktivnostih na nivoju posameznih družb. V redkih primerih je bila dokumentacija o prodaji združena za več poslovnih enot skupaj v eni družbi. 5. Analiza poslovne upravičenosti SIS Zaradi visokih stroškov postavitve sistema poslovne inteligence za podporo poslovnim odločitvam (angl. Business Intelligence) se morajo podjetja najprej vprašati ali je projekt vpeljave takšnega sistema upravičen in ali je v skladu s postavljeno strategijo podjetja. To pomeni preučitev stroškov in koristi, ki jih takšen sistem prinaša. Takšni sistemi prinašajo koristi podjetju iz večih vidikov. Koristi pa so ne samo kvantitativne (zniževanje stroškov, povečevanje prodaje, vsesplošno boljše

27 poslovanje podjetja) temveč tudi kvalitativne, ki so težko merljive vendar jih je potrebno identificirati in vzeti v obzir (Moss, 2003). V nasprotnem primeru (če ne izvedemo ocene poslovne koristi) obstaja nevarnost nezadovoljstva vodilnih v podjetju kljub sicer uspelemu projektu, ki pa ne prinaša poslovne koristi. To pa lahko doprinese v prihodnosti k manjšim naložbam v druge informacijske sisteme oz. informacijsko tehnologijo nasploh v podjetju. Za poslovno upravičenost naložbe v projekt vpeljave sistema poslovne inteligence pa je potrebno izhajati predvsem iz poslovnih in ne tehničnih usmeritev. Identifikacija poslovne upravičenosti se deli na več faz. Prva faza je identifikacija poslovnih zahtev, ki jo v grobem sestavljajo (Moss, 2003) analize: trenutnih sistemov za podporo odločanju v podjetju, možnosti dostopa do podatkovnih virov in procedur, uporabe orodij BI pri konkurenci. Iz zgoraj navedenih analiz sledi faza določitve kriterijev, ki vplivajo na uspešnost projekta uvedbe sistema poslovne inteligence. Ta faza je sestavljena iz treh korakov: predlog rešitve sistema BI, izdelava analize prednosti in slabosti, izdelava anlize tveganja izvedbe projekta. V končni, zadnji fazi, izdelamo kratko poročilo, ki vsebuje glavne izhodiščne točke projekta. Vse omenjene faze z vključenimi podaktivnostmi, ki lahko potekajo vzporedno znotraj posamezne faze, prikazuje slika

28 Slika 6: Aktivnosti izdelave ocene poslovne upravičenosti Identifikacija poslovnih zahtev Analiza trenutnih DSS v podjetju Možnost dostopa do podatkov in procedur Uporaba BI sistema pri konkurenci Določitev kriterijev uspešnosti projekta Predlog rešitve BI sistema Analiza prednosti in slabosti Analiza tveganja Poročilo o upravičenosti projekta Vir: Moss, 2003 Za uvedbo informacijskega sistema za podporo odločanju moramo najti razloge, med katerimi so lahko naslednji (Lesjak, 2005): - strategija zadrževanja strank, - manj investicij, optimizacija infrastrukture, - nadgradnja in razvoj novih storitev, - ustvarjanje vrednosti z dodajanjem novih vsebin, - razširitev uporabe na nova področja, - avtomatizacija poslovanja (manj poročil), - ukvarjanje z vsebino. Lesjak tudi navaja naslednjo preglednico vrst sistemov za podporo odločanju glede stopnjo uporabnosti in poslovne vrednosti (slika 7):

29 Slika 7: Vrste sistemov za podporo odločanju glede na stopnjo uporabnosti in poslovne vrednosti preprosta Poročila (pripravljena) Poročila (ad hoc) uporaba Interaktivno poizvedovanje Analitične aplikacije Rudarjenje zahtevna Vpogled: kdo?, kaj?, kje?, kdaj? Odgovori: Zakaj?, Kje smo?, Ste vedeli, da...? Vir: Lesjak, 2005 nizka relativna poslovna vrednost visoka Pogosta poslovna vprašanja: - skupna, povprečna, največja, najmanjša prodaja/profitabilnost glede na o skupino izdelkov, o regijo, o časovno enoto, o divizijo, o program, o družbo. - primerjave: prodaja skupine izdelkov v prvem četrtletju lani in letos, - primerjava prodaje po regijah za vse izdelke in za vsak izdelek posebej, - uspešnost: o posameznih prodajalcev, o vodij prodajnih programov, o prodajnih programov, o družb. - kupci: najboljši in najslabši, najbolj obetavni, katere grupacije kupcev (korporacije...), - iskanje izstopajočih primerov (max, min...)

30 V odločanju nasploh nastopajo gotovost, negotovost in tveganje. Manjša, ko je gotovost, večje je tveganje, ko se odločamo z intuicijo to prikazuje tabela 4 (Možina, 2002). Gledano skozi stopnjo gotovosti in negotovosti govorimo o subjektivnem in objektivnem odločanju. Subjektivno odločanje je odločanje na podlagi intuicije, ko primanjkuje dejstev; vhodnih podatkov. Objektivno odločanje nastopi takrat, ko ima odločevalec dovolj vhodnih podatkov. Po raziskavah, ki jih omenja (Možina, 2002), se v svetu managerji odločajo v enakem deležu tako subjektivno kot objektivno. Tabela 4: Subjektivno in objektivno odločanje glede na stopnjo gotovosti Gotovost Tveganje negotovost vemo veliko vemo malo Ne vemo nič objektivno odločanje subjektivno odločanje Vir: Možina, 2002 Ker vemo, da je v objektivnem odločanju večja verjetnost pravilne odločitve, si v našem primeru poskušamo zagotoviti čim manjšo stopnjo negotovosti, torej povečati gotovost z nudenjem dodatnih informacij iz sistema za podporo strateški prodaji. Nadalje delimo objektivno odločanje na rutinsko in racionalno. V primeru rutinskega odločanja področje (v našem primeru prodaja) ne pridobi nobene dodane vrednosti, saj je rutinsko odločanje tiste vrste odločanje, ki je lahko avtomatizirano (Možina, 2002). Dodano vrednost dobimo pri racionalnem odločanju, ko bi se brez pomoči nekega dodelanega sistema lahko kaj hitro odločali napačno (npr.»ne širimo prodaje v Rusijo, ker so tam razmere nestabilne«). Po drugi strani pa bi nam sistematičen sistem spremljanja prodaje po trgih hitro pokazal najvišjo rast prodaje ravno v tej regiji. Za racionalno odločanje potrebujemo torej med drugim inštrumente za ugotavljanje stanja (v našem primeru SIS), ki so v naslednjem diagramu na sliki 8 označeni s temnejšo barvo. Slika 8: Stopnje v racionalnem modelu odločanja nova potreba po odločanju potreba po odločitvi preučitev stanja določitev cilja(ev) opredelitev alternativnih rešitev izbira med alternativami izvajanje odločitve Vir: Možina,

31 Razlogi za implementacijo strateškega informacijskega sistema za poslovno odločanje na področju prodajnih projektov, po pomemebnosti navzdol: - povečani prihodki zaradi večje prodaje in tržnih analiz, - izboljšanje poslovnih odločitev, - hitrejše in natančnejše poročanje, - organizirano nastopanje do kupcev (vedenje o trenutnem stanju na nivoju korporacije), - izboljšanje zadovoljstva strank (mini-crm), - zmanjšanje zunanjih IT stroškov na račun manjšega prilagajanja osnovnih informacijskih sistemov za pripravljanje različnih izpisov, - zmanjšanje zaposlenih v poslovnih oddelkih (ne potrebujemo»programerjevizpisovalcev poročil«. 6. Projekt razvoja in uvajanja strateškega informacijskega sistema v korporaciji Hidria V sledečem razdelku opisujem potek projekta razvoja in uvajanja informacijskega sistema za spremljanje strateške prodaje v korporaciji. V projekt sem bil osebno vključen že od prvih dogovorov dalje. Po teh aktivnostih se je vzpostavil projekt, za katerega je bila določena projektna skupina, terminski plan, analiza stroškov, kontrola izvajanja. Vse te aktivnosti opisujem v ločenih poglavjih. Posebna poglavja so namenjena samemu razvoju aplikacije (s predhodnim pregledom obstoječih rešitev na trgu), še posebej pa so opisana izgradnja dodatnega modula za potrjevanje investicij v korporaciji, saj je modul razširil uporabo aplikacije na bistveno več uporabnikov Sestava projektne skupine Za uspešnost projekta je potrebno poleg obstoječe organiziranosti podjetij vzpostaviti vzporedno tudi projektno organizacijo. Ta je začasne narave in se po zaključku projekta razpusti. Iniciator projekta je Vodja strateške prodaje v korporaciji, ki je sestavil tudi prvotno skupino, kasneje Nadzorni odbor projekta. Nadzorni odbor projekta - vodja strateške prodaje, - vodja IT, - vodja projektov v korporaciji, - vodja kontrolinga v korporaciji (vključena kasneje v projektu)

32 Opredelili smo naloge nadzornega odbora: - opredeli projektne cilje, - spremlja napredovanje, kakovost in stroške projekta, - sprejme GRE ali NE-GRE odločitve, - odobri prilagoditve projektnega plana, - zagotavlja potrebne resurse (sredstva, čas, ljudje). Vodja projekta Za vodjo projekta je bila imenovana oseba, ki je po funkciji vodja projektov v korporaciji in ima večletne delovne izkušnje z delom v prodajni funkciji. Naloga vodje projekta je, da vodi in nadzira projekt uvajanja v celoti ter da odgovarja za izvajanje projektnih aktivnosti po tabeli odgovornosti. Vodja projekta ima v takšnem projektu nalogo, ki je primerljiva z vodenjem običajnih informacijskih sistemov. Vseeno pa ugotavljamo, da ima opravka z bolj spremenljivim okoljem, ker: - sta vsebina in obseg obravnavane teme zelo obširna (posegamo v vse plasti poslovanja), - so uporabljena orodja in tehnologije bolj kompleksni, - je področje poslovne inteligence ljudem manj blizu kot npr. logika ERP, - so zaradi»non-core«statusa takšnega sistema denarna sredstva omejena, - so uporabniške zahteve velike in presegajo skupne okvire enega sistema (zahteve npr. posegajo na operativni nivo ERP, ki ga s poslovno inteligenco ne rešujemo). Predstavnik zunanjega izvajalca V tesnem sodelovanju z vodjo projekta in vodjo IT je zunanji aplikativni specialist, ki je hkrati tudi uradni predstavnik zunanjega izvajalca. Notranji aplikativni specialist S strani korporacije je bil za tehnična usklajevanja določen vodja IT. Naloge notranjega aplikativnega specialista so: - nudi tehnično pomoč ključnim in končnim uporabnikom, - sodeluje pri pripravi plana prenosa podatkov in izvaja prenos podatkov, - skupaj z zunanjim izvajalcem pripravlja prilagoditve po zahtevah ključnih uporabnikov. Širša projektna skupina V nadaljnih korakih, to je po predstavitvi osnutka projekta vodstvu korporacije, se je formirala širša projektna skupina, v kateri so bili ključni predstavniki posameznih prodajnih programov v korporaciji, ne glede na družbo. V skoraj vseh primerih so bili za člane širše projektne skupine imenovani vodje prodaje na programih (tabela 5)

33 Tabela 5: Predstavniki širše projektne skupine po prodajnih programih v korporaciji Program Predstavnik Program1 Oseba1 Program2 Oseba Program13 Oseba13 Definirali smo naslednje naloge širše projektne skupine: - določa in razporeja kadre v podjetju za delo v delovnih skupinah - ključne in končne uporabnike, - koordinira postopke programskega paketa med poslovnimi funkcijami, - razrešuje konfliktne situacije med delovnimi skupinami in/ali poslovnimi funkcijami, - predlaga obravnavo in sprejetje ključnih dokumentov projekta Nadzornemu odboru, - spremlja delo delovnih skupin po mejnikih, - rešuje organizacijska ozka grla. Ključni uporabniki Ključni uporabniki niso bili posebej poimensko navedeni, razen takrat ko so se organizirale skupne delavnice (npr. ob uvajanju aplikacije). Ključne uporabnike so določili člani širše projektne skupine. Ključnim uporabnikom smo definirali zastavili naloge: - definira postopke v programskem paketu na svojem področju, - sodeluje z drugimi ključnimi uporabniki pri postopkih, ki se izvajajo v različnih oddelkih, - izdeluje delovna navodila za delo končnih uporabnikov, - vodi delo svoje delovne skupine, - kontrolira pravilnost vnešenih oziroma prenešenih podatkov in po potrebi poskrbi za odpravljanje napak, - znotraj svojega oddelka (delovne skupine) deluje kot prvi nivo pomoči končnim uporabnikom, - definira avtorizacije končnih uporabnikov in izgled menijev za končne uporabnike, - definira eventualne pomanjkljivosti v programski opremi in v sodelovanju s svetovalci poišče ustrezne rešitve, - predlaga in utemeljuje organizacijske spremembe, - predlaga in utemeljuje programske prilagoditve,

34 Končni uporabniki Končni uporabniki so tisti, ki uporabljajo aplikacijo samo za vnose podatkov in vpoglede na najnižjem nivoju. Ne sodelujejo pri razvoju aplikacije in nimajo pravic na višjih nivojih, kot jih imajo ključni uporabniki (kot npr. urejanje šifrantov, definiranje novih uporabnikov, konsolidirani vpoglegi). Skupno število uporabnikov aplikacije je okoli 250, od tega približno polovica končnih uporabnikov. Naloge končnih uporabnikov so definirane takole: - izvajajo svoje delo po delovnih navodilih ključnega uporabnika, - skrbijo za pravilnost vnešenih oziroma avtomatsko pridobljenih podatkov, - v primeru težav, ki presegajo njegovo usposobljenost poiščejo pomoč pri ključnih uporabnikih. Dinamika sestankov Zaradi geografske oddaljenosti udeležencev projekta so se sestanki vršili z manjšo pogostostjo v vnaprej določenih terminih na lokaciji z največ člani projekta. Nadzorni odbor se je sestajal po potrebi in ob zaključku implementacije. V projektni skupini določeni posamezniki nastopajo v večih vlogah, npr. vodja projekta nastopa v vlogi uporabnika (preizkuša rešitve v vmesnih fazah). Aktivnosti v projektu se med seboj časovno prepletajo, zato je potrebno tesno sodelovanje med naročnikom in izvajalcem ter znotraj naročnika med uporabniki, kar koordinira vodja projekta Terminska in stroškovna opredelitev projekta Terminski plan Plan aktivnosti je pripravila ožja projektna skupina. Zaradi nekaterih sočasnih aktivnosti je smotrna pravilna razporeditev aktivnosti na projektu, za to se uporabi orodje Microsoft Project. V grobem plan dela razdelimo na: - (vodenje projekta), - (definicije projekta), - analiza, - načrtovanje, - implementacija, - testiranje, - prehod v produkcijo, - analiza projekta

35 Konkretne naloge, ki jih v nadaljevanju dela tudi podrobneje opisujemo pa so v približno naslednjem zaporedju, pri čemer se nekatere aktivnosti sočasno vzporedno prekrivajo (tabela 6): Tabela 6: Aktivnosti na projektu s predvidenim trajanjem Aktivnost Sestava projektne skupine 1 Terminska in stroškovna opredelitev 1 Pregled obstoječih IS rešitev 2 Projekt izdelave pilota 4 Izbira zunanjega izvajalca 1 Uskladitev zahtev z bodočimi uporabniki 5 Izdelava aplikacije in testiranje 15 Izdelava dodatnega modula + aktivnosti 10 Izdelava izpisov 3 Izdelava dokumentacije 1 Skupaj Trajanje (tednov) 10 mesecev Vir: dokumentacija projekta Hidria SARA, Analiza stroškov V analizi stroškov tako kot v ostalih projektih informacijskih tehnologij v korporaciji nismo upoštevali internega dela zaposlenih znotraj korporacije. Zaradi razpoložljivosti zaposlenih na projektu se je predvidelo število človek/dni dela, naknadno pa se je tudi sproti evidentiralo število porabljenih internih človek/ur na projektu. V analizi stroškov smo upoštevali naslednje izdatke: - postavitve ustrezne strežniške infrastrukture o nakup strežnika, o licence za podatkovno bazo, - stroški zunanje izvedbe. Po prevzemu aplikacije v redno uporabo ni bilo rednih stroškov vzdrževanja, nastali pa so dodatni stroški specifičnih dodelav. Zaradi varovanja poslovne skrivnosti analize stroškov ne navajamo

36 Izdelava aplikacije je bila naročena na ključ s pavšalnim zneskom. Ocenjeno je bilo določeno število inženirskih dni dela. Z zunanjim izvajalcem je bila sklenjena pogodba o razvoju programskega paketa. Vse tehnične storitve so bile opravljene s strani interne informatike posameznih družb korporacije: povezave VPN (Virtual Private Network), inštalacija klientov, prenosi podatkov, deloma prilagoditve Nadzor izvajanja Že pri začetnem planiranju projekta se zavedamo, da je učinkovit nadzor poteka projekta ključen, saj le z ustreznimi preveritvenimi metodami poskrbimo, da se v projektu izvaja tisto, kar je bilo planirano in da se ne izvaja tisto, kar ni bilo planirano (Stjepanovič, 2005). Toda samo kontrola brez akcij saba sebi ni namen, zato moramo biti vnaprej odločeni, da morebitna odstopanja tudi hitro korigiramo. Nadzor izvedbe potemtakem ni samo ugotavljanje odstopanj v projektu, temveč tudi njihovo korigiranje. Proces nadzora projekta lahko po delimo v naslednje sklope (Stjepanovič, 2005). Spremljanje in dokumentiranje rezultatov Projektna dokumentacija s poglavjem o dokumentiranih rezultatih mora biti vedno na voljo vsem članom projekta, urejena in ažurna. To ne pomeni, da je vodja projekta edini, ki v dokumentaciji ažurira dosežene rezultate; zaželeno je, da skozi motivacijski vidik to počno projektni člani sami. Organiziranje in vodenje sestankov Vsak sestanek pomeni časovno ločnico, ki posameznika avtomatsko spodbuja k rezultatom. Ponavadi smo ljudje bolj produktivni v času pred sestankom, kjer bomo morali predstaviti svoje rezultate. Sestanki naj imajo vnaprej znano agendo, morajo biti učinkoviti in dovolj pogosti, da projekt teče tekoče. Objektivno spremljanje napredka Da bi se izognili opisnemu označevanju napredka projekta, je smiselno opredeliti razvojne točke projekta, kot npr. v odstotnih točkah. Ne da bi kaj posebej razlagali, lahko na projektnih sestankih vodja hitro ugotovi, kateri člen v verigi projekta je najpočasnejši. Spremljanje in vodenje stroškov projekta Bistvena naloga vodje projekta je, da dovolj pogosto spremlja stroške projekta in jih primerja s planiranimi. Seznanjen mora biti s stroški dela, stroški dodatne strojne opreme in podobno. Morebitna odstopanja vodja projekta predstavi podpornikom projekta oz. vodstvu

37 Vodenje in izvajanje zahtev za spremembe Vsi se zavedamo, da so spremembe stalnica, zato moramo vzpostaviti učinkovit sistem vodenja oz. nadziranja sprememb v projektu. S takšnim sistemom, ki ga ažurirajo vsi člani projekta, imamo pregled nad vsemi spremembami in lažje ugotavljamo, ali se nam na primer ključni cilji projekta spreminjajo (in se nam ne bi smeli). Nadzor tveganja Nenapovedani dogodki lahko prinesejo pozitivne ali, največkrat, negativne učinke na projekt. Odhod ključnega člana projektne skupine ali nepredvidena sprememba uporabljanih tehnologij lahko resno ogrozi projekt. Vodja projekta mora sproti ugotavljati nepredvidene dogodke in se nanje ustrezno odzvati. Zagotavljanje kakovosti izvedbe Tako kot člani projektne skupine stremijo k kakovostnemu delu v svojih rednih nalogah, naj se tega držijo tudi v projektu. Vodja projekta naj jih vzpodbuja k uporabi standardov kakovosti; k odličnosti v svojem delovanju Pregled obstoječih programskih rešitev za podporo prodajni funkciji Glede na to, da je večinski uporabljani informacijski sistem v korporaciji BaaN ERP, je tudi prva verjetna usmeritev v BaaNov modul za podporo prodaji, to je BaaN CRM (Infor CRM). Druga možnost je vpeljava splošno uporabljanega off-shelf CRM sistema, kot je npr. Microsoft Dynamics CRM. Tretja rešitev je razvoj lastne prilagojene programske rešitve CRM. Pred ogledom posameznih rešitev si oglejmo glavne postavke, ki jih vodstvo korporacije pričakuje od sistema za podporo prodajni funkciji: - sistem mora znati konsolidirati podatke o prodaji na nivoju korporacije, - sistem mora omogočati napovedovanje prodaje, - sistem mora znati na različne načine prikazati ključne strateške kupce in njihove pripadnosti večjim korporacijam, - sistem mora prikazovati sliko profitabilnosti posameznih prodajnih programov, - sistem mora znati prikazati posamično ali konsolidirano sliko o statusu prodajnih projektov (faza projekta), - sistem mora znati opozarjati na ključne anomalije v postopku vodenja kupca ali projekta (npr. alarm ob prekinitvi donosnega projekta), - sistem mora znati med seboj povezati prodajne projekte in investicije, ki so vezane nanje

38 Vodstvo korporacije od sistema za podporo prodajni funkciji ne pričakuje: - podrobnih podatkov o aktivnostih, ki jih prodajniki izvajajo s kupci, - podrobnih podatkov o kupcih, kot so npr. podatki o bonitetah in pogojih poslovanja, - skupne evidence kontaktnih podatkov o kupcih Infor BaaN CRM Infor CRM omogoča pregled vseh dogodkov na vsaki določeni točki z integriranim marketingom, prodajo in servisom. Današnje poslovno okolje deluje na podlagi potreb; vsaka interakcija s stranko pomaga k razumevanju le-te in k oblikovanju (naj)boljše poslovne prakse. Infor CRM pomaga optimizirati medsebojno delovanje s stranko. Ne glede na to, ali je cilj izboljšati položaj na trgu, bolje upravljati z marketinškimi aktivnostmi ali izboljšati učinkovitost prodajnih in servisnih operacij, rešitev pomaga izboljšati celoten proces upravljanja odnosov s strankami. Infor CRM po navedbah proizvajalca omogoča: - enoten, informativen vpogled v stranko, - navzkrižno in dodatno prodajo, - ohranjanje in pripadnost strank, - dvig povprečnega prihodka na stranko, - učinkovitost klicnih centrov ter - splošno prodajno učinkovitost. V splošnem Infor CRM podpira naslednja področja: - Marketing o profili strank, o upravljanje zunanjih marketinških aktivnosti, o notranji pregled in nadzor procesa marketinga. - Prodaja o avtomatizacija prodajne službe (t.i. Sales Force Automation), o interaktivna prodaja, o naročanje izdelkov v realnem času, o konfiguracije izdelkov. - Poprodajne storitve o Učinkovite vzdrževalne storitve strankam, o Samopomoč strankam (spletna baza znanja), o Povezava z mobilnim servisom na terenu, o Časovno in prostorsko optimiziranje vzdrževalnih storitev (planer). V našem primeru nas s strateškega stališča ne zanimajo skupne marketinške dejavnosti, niti vzdrževalne storitve oz. v našem primeru»reševanje reklamacij«. Ker so prodajni programi korporacije povečini tipa B2B (npr. prodaja velikih serijj ulitih

39 sestavnih delov za avtomobilsko industrijo, prodaja velikih serij fino štancanih delov za gospodinjske aparate itd.), je klasični CRM za uporabo vprašljiv, saj kot rečeno ponuja veliko operativnih evidenc, ki so usmerjene k kupcu. V našem primeru je, kot rečeno, želja spremljati strateško sliko prodajnih aktivnosti po programih in divizijah, ne pa operativno voditi marketinške dejavnosti in operativne vzdrževalne storitve. Rešitev Infor CRM nima skupnih korenin s sistemom ERP BaaN. Ima sicer isti koren v imenu in jo je prodajalec naknadno vezal na BaaN ERP, toda na tak način lahko medsebojno vežemo katerokoli»zunanjo«aplikacijo CRM. Zato Infor CRM smatramo kot enakovredno rešitev v primerjavi z ostalimi kompatibilnimi aplikacijami CRM na trgu, kot je Microsoft Dynamics CRM Microsoft Dynamics CRM Microsoft Dynamics CRM je rešitev, ki omogoča jasno sliko o strankah od prvega kontakta z njimi, skozi proces naročanja opreme in storitev, do poprodajnih aktivnosti. Enako kot Infor CRM vsebuje tri osnovne module: - modul za prodajo, - modul za marketing, - modul za podporo strankam (servis). Microsoft Dynamics CRM ima v primerjavi z nekaterimi drugimi sistemi CRM prednost intuitivnega uporabniškega vmesnika, ki sloni na filozofiji Microsoft.NET. Enako se MS CRM povezuje v sistem Microsoft Office, torej tudi v sistem elektronske pošte Microsoft Office Outlook, kar pomeni hitrejše uvajanje za uporabnike, ki že uporabljajo ta sistem elektronske pošte ( Microsoft Dynamics CRM 3.0 ponuja: - hiter in enostaven dostop do podatkov skozi različne drevesne strukture, - prilagojena namizja s priljubljenimi pogledi za različne uporabnike, - koledar servisov (podpore) za planiranje vzdrževalnih aktivnosti, - napredna orodja za poročanje in analize, - oddaljene dostope za mobilne uporabnike preko spletnih brskalnikov in mobilnih telefonov. Gledano s stališča razvoja aplikacije je Microsoft Dynamics CRM enostavna rešitev, saj omogoča že nekoliko bolj izkušenim uporabnikom hitro urejanje polj in objektov v aplikaciji z namenom čimvečje prilagodljivosti form za dejanske potrebe naročnika

40 Microsoft Dynamics CRM vsebuje nekaj zanimivih dodatkov v primerjavi z drugimi paketi CRM, ki bistveno olajšajo delo uporabnikom na področju prodaje: - modul za avtomatizacijo, ki omogoča upravljanje s prodajnimi/marketinškimi kampanjami, - čarovnik za pošiljanje obvestilnih mailing list, - kreiranje in upravljanje prilagojenih delovnih tokov (work-flow), - napreden sistem poročanja, ki je kompatibilen s paketoma MS Excel in MS SharePoint Portal Server (namizja za izvršni management) Samostojno razviti CRM program Tretja možnost pri izbiri ustrezne programske rešitve za podporo strateški prodaji v korporaciji je izdelava lastne aplikacije, prilagojene specifičnim zahtevam. Slabost lastnega razvoja je čas, ki je potreben za razvoj in pa kasnejše prilagajanje / nadgrajevanje aplikacije po potrebi uporabnikov. Prednost lastnega razvoja je popolna prilagojenost zahtevam in specifikam. Glede na to, da so zahteve korporacije zelo specifične (npr. zahteva po prodajnem planu za +5 let, zahteva po povezavi prodajnih projektov s potrebnimi investicijami, ki so vezane nanje...), je obveljala odločitev o razvoju lastne prilagojene aplikacije. Oba predhodno omenjena predstavnika sta za razliko od potreb korporacije ponujala bistveno bolj podporo B2C kot B2B, torej podrobno vodenje prodajnih, marketinških in servisnih aktivnosti, ne strateškega planiranja prodaje po prodajnih programih. Poenostavljeno rečeno so off-shelf rešitve pisane na kožo trgovinam in ne razvojnoprodajnim dobaviteljem B2B. Z upoštevanjem, da se bo za naročnika razvila specifična prilagojena aplikacija pa je vseeno obveljala zaveza, da naj bo aplikacija razvita v standardiziranem razvojnem okolju to je v nadaljevanju tudi podrobneje razloženo

41 6.4. Projekt izdelave pilotne aplikacije V prvih tednih odločanja za nov sistem spremljanja strateške prodaje se je manjša skupina, kasneje nadzorni odbor projekta, odločila za enostavno testno različico aplikacije z dvema osnovnima pogledoma: - vnos projekta in - primer izpisa. Dogovorjeno je bilo, naj se z izdelavo pilota ne izgublja preveč časa pilotna aplikacija naj bi bila namenjena pridobitvi pravega občutka za dejansko aplikacijo in pa za uvodne predstavitve v postopku odobritve projekta. Nalogo za izdelavo pilotne aplikacije je prevzel vodja IT področja. Uporabljeno orodje je bilo Microsoft Access. Izdelava polj je bila relativno enostavna, več dela je bilo z implementacijo grafov v osnovno vnosno formo. Nekatera polja so vsebovala šifrante, ki so bili tudi dejansko vidni in na uporabo vsaj tisti krajši in enostavnejši. Slika 9: Pilotna aplikacija: prva vnosna maska Vir: dokumentacija projekta Hidria SARA,

42 Že po prvem pregledu osnovne pilotne vnosne maske (slika 9) je bilo dogovorjeno, da nekatere podrobne podatke o kupcih izpustimo. Ne zanimajo nas podatki, kot so ulica in poštna številka naročnika/kupca ali destinacija dobave, ker lahko enemu (večjemu) kupcu dobavljamo na več različnih lokacij. Vse nepotrebne podatke se odstrani zato, da prodajniki ne bodo imeli preveč dela z vnašanjem podatkov. Že pred projektom se je izoblikoval slogan, ki je projekt spremljal tudi v nadaljevanju:»simple and logical«- takšna naj bo aplikacija za vse uporabnike, tako vnašalce kot vpogledovalce. V nadaljevanju se je vnosna maska za potrebe predstavitve vodstvu predelala v bolj enostavno obliko, kjer je bil že dodan grafični prikaz plana prodaje za prihodnja leta. Sočasno s predstavitvijo vnosne maske se je pripravilo tudi enega od osnovnih izpisov projektov, ki je podoben vnosni maski. Predizbira izpisa je bila tudi vnaprej definirana, in sicer z naslednjimi bistvenimi predpostavkami: - vpogledujemo enake izpise na nivoju: o korporacije (konsolidirano), o družbe (konsolidirano), o prodajnega programa (konsolidirano) ali o posameznega projekta. - uporablja se princip enostavnosti najbolj pogosti izpisi so poimensko definirani vnaprej in jih uporabnik izbere iz šifranta, - Vedno ob vpogledu v izpis definiramo časovno obdobje (od-do ali kasneje mesec/kvartal/leto). Kot omenjeno, je bila priprava izpisov tudi del pilotne aplikacije. Pripravili smo dva dejanska izpisa: - osnovni izpis (podatki o projektu), - konsolidirani izpis (seštevki in povprečja vrednosti, grupirano po družah ali na nivoju celotne korporacije). Da bi pripravili dejanske izpise, vključno z grafičnim prikazom, smo se v začetku odločili, da se pilotna aplikacija v Accessu napolni z dejanskimi podatki. Skupaj smo v prvi fazi s pomočjo prodajnikov po družbah zbrali 40 reprezentativnih projektov. Prodajnikom je bila datoteka Access poslana po elektronski pošti. Uporabniki so prejeto datoteko odprli lokalno na svojih računalnikih in izvozno datoteko poslali nazaj po elektronski pošti, nakar smo podatke združili. Za potrebe pilotne aplikacije je bilo oddvojeno delo sprejemljivo

43 Slika 10: Pilotna aplikacija: konsolidiran vpogled Vir: dokumentacija projekta Hidria SARA, 2007 Konsolidirani vpogled je bil izjema in ni bil narejen v Accessu, temveč v PowerPointu (slika 10) zgolj za potrebe prikaza vodstvu in lastno percepcijo izgleda izpisa. Potek izdelave pilotne aplikacije je bil sorazmeroma kratek, saj je zajemal samo prvotno dogovarjanje o vsebovanih poljih, realizacijo le-teh v enostavnem orodju Microsoft Access in vnos nekaj testnih izmišljenih osnovnih šifrantov. Skupna izdelava pilotne aplikacije je trajala 4 tedne oziroma 60 človek ur Izbira zunanjega izvajalca za izdelavo aplikacije Ko smo enkrat odločeni, da izdelave aplikacije ne bomo prepuščali lastnim kadrom, temveč specializiranemu zunanjemu izvajalcu, pride na vrsto pomemben trenutek, ko je potrebno izbrati ustrezno programsko hišo. Že v začetku se zavedamo specifik slovenskega trga, in sicer da razvoj aplikacije najpogosteje v končni fazi pade na eno osebo. Zato nam kot naročniku ni vseeno, kdo bo v končni fazi razvijal aplikacijo in kakšni so njegovi pogledi/nazori/vrednote

44 Glavni razlogi za odločitve podjetij za izbiro zunanjega izvajalca (Debelak, 2002) so: - podjetje se s predajo poslov lahko osredotoči na osnovno poslovanje (core business), - naraščajoči interni stroški, povezani z razvojem informacijskih sistemov, - hitro spreminjajoča se informacijsko-komunikacijska tehnologija (težko sledenje), - neustrezna in slaba kakovost storitev obstoječega oddelka informatike (nezadovoljstvo vodstva z internimi oddelki), - težko je zagotoviti vse specialiste po področjih znotraj podjetja, - prenos tveganja na zunanjega izvajalca (med največje dejavnike tveganja spada tehnologija), - izboljšana kakovost IS (zunanji izvajalec naj bi bil specialist na svojem področju), - boljša izkoriščenost tehnoloških virov (komunikacijska in strojna oprema). Ker se pri izbiri zunanjega izvajalca seveda ne moremo odločati zgolj intuitivno, si moramo postaviti neka merila, po katerih bomo izvajalca izbrali. V grobem rečeno, gledamo dve lastnosti: - kakovost izvedbe (dober indikator so pretekle reference), - ceno izdelave in vzdrževanja. Neprimerno večja teža je sicer na parametru kakovosti, kjer se vprašamo: - ali ima izvajalec ustrezna znanja in izkušnje; ne samo znanja o transakcijskih sistemih, temveč celostna znanja o poslovni inteligenci, - kakšna je razpoložljivost virov pri izvajalcu, - ali izvajalec uporablja standardna orodja in metodologije za razvoj, - kakšne reference s konkretnega področja ima izvajalec, - ali bo izvajalec sposoben razumeti našo organizacijo in naše specifike, - kakšne so možnosti nadaljnjega razvoja aplikacije s tem izvajalcem. Da bi se lahko odločali čimbolj objektivno, si izdelamo odločitveni model uteženih kazalnikov oziroma parametrov za izbiro zunanjega izvajalca, ki temelji na modelu (Štempihar, 2005):

45 Tabela 7: Uteženi parametri za izbiro zunanjega izvajalca Osnovne lastnosti Druga znanja Razvojne lastnosti Podpora uporabnikom Primernost izvajalca za podjetje naročnika Pristop (partnerski odnos) Vzdrževanje Kazalniki in parametri izbora izvajalca zadostno število zaposlenih, strokovnost, dostopnost, zanesljivost, odzivnost celovitost storitev 4 vajen timskega dela 4 varnost dolgoročnega sodelovanja 4 ali ima znanja s področja analize poslovnih procesov 5 ali ima znanja s področja kazalnikov uspešnosti poslovanja pozna teorijo projektov in uporablja projektni pristop oz. projektno metodo uvajanja ima sposobnosti ali se vsaj zaveda, kaj je potrebno za dobro timsko delo in za razumevanje kupca pri tujih rešitvah pozna vse ali vsaj večino funkcionalnosti in ni samo dober prodajalec ali ima lasten strateški razvojni plan 4 ali uporablja standardna odprta orodja za razvoj aplikacij (možnost integracije) ima razvojni oddelek in obvladuje razvoj novih tehnologij 5 omogoča in ima razvito metodologijo prilagoditev za posameznega naročnika vključuje uporabnike v razvoj rešitev 4 skrbi za izobraževanja svojih zaposlenih 5 ima stalno in lahko dosegljivo pomoč 5 zagotavlja pomoč pri uporabnikih 5 skrbi za šolanja uporabnikov 5 ima dobro obveščanje uporabnikov 5 dobre reference v panogi in dejavnosti (izkušnje in znanja o poslovnih procesih) dobre reference v enako velikih podjetjih (obvladovanje zahtevnosti) celovitost ponudbe storitev za potrebe projekta 4 dobro posluša in razume 5 samostojno prepozna konkretne težave 5 analizira in daje predloge, kako izboljšati poslovanje 4 ne vsiljuje svojega mnenja, temveč uporablja argumente 5 je točen in izpolnjuje dogovorjene zadeve 5 stroški sprememb in nadgradenj 5 Vzdrževalnina 5 optimizacija uporabe funkcionalnosti 5 Ocena Izvajalec3 (1-5) Druge prednosti brezplačna namestitev na test 5 v storitvah prenosi podatkov v fazi komercialnih predstavitev 5 5% Utež 15% 10% 10% 10% 20% 20% 10% Vir: Kocjan Stjepanovič, Sistem - priloga revije Monitor, oktober

46 S pomočjo teh kriterijev smo se izmed petih softverskih hiš odločili za podjetje B2 d.o.o., ki tem kriterijem najbolj ustreza. Čeprav s tem podjetjem v preteklosti na področju razvoja aplikacij nismo sodelovali, smo poznali njihovo organizacijo in sposobnosti aplikativnih specialistov. Izvajalec se je v širši zasedbi predstavil vodstvu naročnika. Sledila je sklenitev pogodbe o razvoju aplikacije in skladno s projektnim planom smo pričeli z aktivnostmi. Pri izbranem zunanjem izvajalcu pa se moramo ne glede na njegovo kakovost vseeno zavedati naslednjih potencialnih težav, ki jih s sabo prinaša zunanje izvajanje storitev. Potencialne slabosti zunanjih izvajalcev prikazuje tabela 8. Tabela 8: Običajne slabosti zunanjega izvajalca Običajne slabosti zunanjega izvajalca - Ne pozna dobro kupčevega poslovanja, še posebej ne njegovih specifik - Se ne poglobi v značilnosti delovanja in problemov, temveč vsiljuje standardne, neprilagojene in neprimerne rešitve - Ne»posluša«dobro in ne razume zahtev - Govori računalniški jezik in ne poslovnega - Ne išče boljših rešitev za poslovanje oz. ne razloži načrtovanih in izvedenih rešitev. - Ne spremlja interesov kupcev, njihovih želja, pričakovanj in zahtev - Ne deluje proaktivno - Ne drži se obljubljenih rokov - Ne nadzoruje programskih sprememb: - napačno dojemanje potrebnih sprememb - prekoračitev ur in rokov - nezadostno testiranje - Ne razume: - kaj dela kupec (kakšne so njegove odgovornosti) - ne pozna/razume načina, kako dela (procesa dela) - kakšen prispevek želi dati kupec sam (njegova pripravljenost in motivi) - kakšne rezultate želi doseči - Pomanjkljiva notranja komunikacija (npr. podpora programerji) Vir: Štempihar,

47 6.6. Uporabljene tehnologije V korporaciji se že nekaj let v celoti uporabljajo Microsoftove programske rešitve, od sistema Exchange za elektronsko pošto, do aktivnega imenika, podatkovnih baz SQL in pisarniške zbirke Office. Zato tudi ni bilo dileme glede tega, kakšno platformo izbrati za implementacijo aplikacije. V nadaljevanju si poglejmo poglavitne dele uporabljanih tehnologij: platformo, programsko orodje za razvoj aplikacije in podatkovno bazo Platforma Kot platforma je bilo uporabljena skupina orodij in tehnologij Microsoft.NET. Termin označuje široko zbirko Microsoftovih orodij, od katerih smo v našem primeru uporabili naslednja: - Microsoft.NET Framework, - Microsoft Visual Studio, - Microsoft SQL Server. Pomemben je.net Framework, v našem primeru verzija 2.0. Gre za komponento, ki je opcijski brezplačni dodatek k operacijskemu sistemu Windows (2000, XP, Vista). Za uspešno uporabo aplikacije je torej ogrodje potrebno namestiti pri vsakem uporabniku posebej. Ogrodje.NET Framework 2.0 ponuja veliko predkodiranih procedur oz. knjižnic, ki jih aplikacija tudi uporablja, od uporabniškega vmesnika, do povezljivosti s podatkovno bazo Razvojno orodje Kot omenjeno, je zunanji izvajalec za razvoj aplikacije uporabil Microsoftovo razvojno orodje Visual Studio 2005 (.NET je Microsoft iz imena produkta pričel izpuščati). Zgodovina paketa Visual Studio sega v leto 1997, ko je bila razvita prva verzija, Visual Studio 97. Sledila je verzija 6.0 za operacijske sisteme Windows 95 in Windows 98, kasneje pa prva verzija.net 2002, ki je tudi že omogočala zaganjanje napisanih aplikacij na kateremkoli klientu z nameščenim ogrodjem.net (.NET Framework). Trenutno je v pripravi verzija Visual Studio Visual Studio 2005 omogoča razvoj t.i. client aplikacij, ki so nameščene na uporabnikovem računalniku (v našem primeru je tako). Med drugim omogoča razvoj samostojnih spletnih aplikacij in spletnih strani (v ta namen je vključeno orodje ASP.NET). Poleg omenjenega ASP.NET za razvoj spletnih aplikacij podpira Visual Studio 2005 še programske jezike Visual Basic (.NET), Visual C++, Visual C# in Visual J#

48 Ena od posebnosti Visual Studia 2005 je ta, da ima vgrajen lokalni spletni strežnik, ki je ločen od IIS (Internet Information Services) namenjen internemu testiranju spletnih aplikacij. Visual Studio 2005 je tudi povezan s podatkovno bazo SQL Server 2005, kar pomeni, da lahko bazo kreiramo brez drugih orodij, neposredno iz Visual Studia. Druge novosti v verziji Visual Studia 2005 so: - podpora 64-bitnim procesorjem AMD in Intel (razvojno okolje ostaja 32-bitno), - dodano orodje Deployment Designer, ki omogoča testiranje novih aplikacij pred objavo (vključno s testiranjem obremenitev), - kot dodatek k VS2005 je Microsoft pripravil druge produkte, ki imajo v imenu Visual Studio, npr. Visual Studio Team System, ki je namenjen skupinskemu razvijanju aplikacij Baza podatkov Ob implementaciji smo se odločili za uporabo sistema za upravljanje baze podatkov Microsoft SQL Server MS SQL 2005 ima po novem dodana orodja za poslovno inteligenco (BI). Nudi podporo tako relacijskim podatkovnim zapisom kot formatu XML (extensible Markup Language). Microsoft je verzijo 2005 izdal novembra leta 2005, skupaj z razvojnim orodjem Visual Studio MS SQL Server uporablja različico strukturiranega poizvednega jezika T-SQL (Transact SQL), ki uporablja shranjene procedure iz okvirja.net. Podpira standard ODBC (Open DataBase Connectivity) in spletno povezljivost klientov preko protokola Web Services SOAP, kar je uporabno tudi za kliente, ki ne delujejo na osnovi operacijskega sistema Windows. Za napredne uporabnike je v MS SQL 2005 na voljo podpora gručam (cluster), kar pomeni delovanje logične podatkovne baze na večih fizičnih strežnikih, ki si porazdelijo delo. Naša ocena velikosti baze in frekvence branj/pisanj je bila takšna, da nam je popolnoma zadostoval strežnik HP Proliant DL380 G4. MS SQL Server 2005 ima vgrajene naslednje produkte s specifičnimi funkcionalnostmi: - SQL Server Integration Services (migracija podatkov na SQL), - SQL Server Analysis Services (večdimenzijsko vpogledovanje podatkov), - SQL Server Reporting Services (enostavnejša poročila oz. izpisi), - SQL Server Notification Services (razpošiljanje sporočil), - SQL Server Management Studio

49 Od teh produktov smo v povezavi z aplikacijo v prvi fazi uporabili produkta Reporting Services za izdelavo vnaprej pripravljenih statičnih in spletnih interaktivnih poročil ter Notification Services za razpošiljanje obvestil (prožilci). Notification Services pošilja redna obvestila na elektronsko pošto, izredna obvestila pa na GSM aparate preko vgrajene mobilne kartice. Na sliki 11 je nazorno prikazana struktura strežnika SQL Server Osrednji del predstavljajo že omenjena upraviteljska orodja, ki se povezujejo z drugimi aplikacijami (npr. MS Exchange Server), s strežnikom SharePoint Portal Server (v našem primeru ni v uporabi) in z zbirko Office, kar v našem primeru je v uporabi poročila se kreirajo tudi v Excel datotekah ter se skozi Notification Services preko Exchange vmesnika distribuirajo v uporabniške poštne račune. Celotna platforma (SQL Server, aplikacije, Office) so nameščeni na operacijskem sistemu Windows Server Slika 11: Povezljivost strežnika SQL z drugimi aplikacijami Office SharePoint Portal Server Druge aplikacije Visual Studio.NET MdeS SQL SQL Server SServer Integration Services Analysis Services OLAP in podatkovno rudarjenje Reporting Services Notification Services Replication Services Relational Database Upraviteljska orodja Windows Server 2003 Vir:

50 Povezava z obstoječimi uporabljanimi tehnologijami Bistvena prednost uporabljanih Microsoftovih tehnologij je v povezavi aplikacije do korporativnega direktorija LDAP (Lightweight Directory Access Protocol). Za LDAP je v korporaciji uporabljan Microsoftov imeniški sistem Active Directory, ki je v korporaciji zasnovan drevesno. V vrhu drevesa je glavna domena hidria.local, ki se veji v globino na domene glede na skupine družb, npr. rotomatika.hidria.local. Za kakovostno uporabo aplikacije je povezava na aktivni imenik bistvena, in sicer zaradi dveh razlogov: 1) Aplikacija pošilja uporabnikom obvestila o dogodkih na elektronsko pošto Elektronski poštni naslovi uporabnikov so zapisani v aktivnem imeniku in ne v šifrantu aplikacije. Pošto razpošilja posebni agent (t.i.»sara mail account«, ki je definiran na strežniku, kjer je nameščena aplikacija). 2) Varovani dostop do aplikacije je zasnovan na LDAP-ju Ob vsakem zagonu aplikacije se primerja trenutno prijavljenega lokalnega uporabnika na računalniku z definiranimi uporabniškimi imeni v aktivnem imeniku. Na tem nivoju je varovanje dvojno: - Varovanje dostopa do strežnika in podatkovne baze (uporabnik mora biti član posebne skupine v aktivnem imeniku, t.i.»sara Members«grupa), - Varovanje dostopa do aplikacije: v tem primeru je aplikacija tista, ki preverja uporabniško ime in geslo v ta namen so uporabniki dodatno prenešeni iz aktivnega imenika v šifrant aplikacije Varnost Zaradi strateškega pomena in zaupnosti podatkov moramo zagotavljati največjo možno varnost sistema z namenom preprečitve dostopa do ključnih podatkov nepooblaščenim osebam ali nepooblaščene distribucije le-teh navzven. Grožnje varnosti informacijskemu sistemu (Egan, Mather, 2001) so vsi elementi, ki bi lahko ogrozili celovitost, zaupnost ali razpoložljivost podatkov. To so dogodki, ki porušijo normalno delovanje informacijskega sistema. Posledica takih dogodkov je lahko velika finančna izguba v organizaciji. Intenzivnost posledic groženj pa se razteza od nizke, to je na primer izguba kakega manj pomembnega dokumenta, do katastrofalnih posledic, kar bi bilo uničenje informacijskega sistema. Pri grožnjah je

51 potrebno poudariti tudi grožnjo, ki preti od človeka, predvsem tistih, ki niso zadovoljni z delom, plačo ali ostalimi dejavniki. Veliko grožnjo predstavljajo tisti, ki imajo gesla in dostope do najbolj zaupnih podatkov in do strežnikov in imajo tudi pravico brisanja. To so predvsem sistemski administratorji, ki imajo vse te pravice in zelo dobro vedo, kateri so vitalni deli informacijskega sistema v njihovi organizaciji. Slika 12: Grožnje varnosti informacijskemu sistemu Grožnje varnosti informacijskemu sistemu Izredni dogodki - Ogenj - Voda (poplave) - Električna energija (izpadi, nihanja) Naključne odpovedi - Odpoved strojne opreme - Odpoved programske opreme - Odpoved človeka Dejavnost človeka - Vlom (kraja, vandalizem) - Sabotaža - Nepooblaščen logični dostop do informacijskega sistema - Programski vsiljivci Vir: Egan, Mather, 2001 Slika 12 prikazuje delitev groženj varnosti informacijskemu sistemu na izredne dogodke, naključne odpovedi in na človekovo dejavnost. Proti izrednim dogodkom je strateški informacijski sistem varovan tako kot ostali sistemi (sistem elektronske pošte, sistem ERP, dokumentni sistem...). Strežnik ima predpriklopljeno napravo UPS (Uninterruptible Power Supply), ki varuje v primeru izpada ali nihanja električne energije. Proti ognju je strežniška soba varovana s posebno plinsko celico in protipožarnimi vrati. Proti vodi strežniška soba ni zavarovana. Kar se tiče naključnih odpovedi, je sistem zavarovan slabše. Strateški informacijski sistem sloni, tako kot ostale aplikacije, na lastnem strežniku HP Proliant, ki sicer ima redundantno napajanje, hlajenje in diskovno polje, nima pa redundance na pomnilniku, procesorju ali matični plošči. Ravno tako aplikacija odpove v primeru izpada programske opreme: podatkovne baze SQL ali operacijskega sistema Windows Glede na to, da aplikacija ni nujno potrebna 24/7 za normalno delovanje podjetja, smo s to stopnjo razpoložljivosti zadovoljni. V prihodnosti se bo en strežnik verjetno postavilo v virtualno okolje z več fizičnimi strežniki - tako bo nevarnost izpada strežnika bližje 0, v primeru izpada programske opreme pa bo preklop v delujoče stanje trajal le nekaj sekund

52 Največje grožnje, ki jih imamo v tem primeru, prihajajo s strani človeka. Fizični vlom v strežniško sobo je malo verjeten. Možna je sabotaža ali zunanji vlom, še bolj pomembna pa je zaščita pred nepooblaščenim logičnim dostopom. Eden od pomembnih sklepov je ta, da je nujno potrebno dodelati logistiko izhodov zaposlenih iz podjetja. Ti zapuščajo podjetje iz različnih vzrokov in kaj lahko v novem (konkurenčnem) okolju poskusijo dostopati do aplikacije s svojim uporabniškim imenom in geslom, če to še ni bilo ukinjeno z njegovim odhodom. Kar se tiče drugih varnostnih mehanizmov, velja omeniti, da je aplikacija ščitena na nivoju dostopov do podatkovne baze kot tudi do aplikacije same skozi aktivni direktorij (AD). Sam strežnik se nahaja v internem strežniškem navideznem omrežju LAN (Local Area Network); je torej ločen od zunanjega internet/ekstranet okolja. Podatki se varnostno arhivirajo na kasete, občasno se dela analize arhiviranj in dostopov uporabnikov. Neke vrste dodatno varovanje je tudi v tem, da uporabnik za zagon aplikacije potrebuje predhodno nameščenega klienta, ki mu ga lahko na njegov računalnik namesti samo administrator sistema Uskladitev zahtev in potreb z bodočimi uporabniki sistema Bistvenega pomena pri gradnji prilagojenega informacijskega sistema je interakcija z bodočimi uporabniki. Z interakcijo pridobimo potrebno povratno informacijo, ki nam služi za optimalno izgradnjo sistema, med drugim pa je interakcija zelo pomembna tudi zaradi vključenosti bodočih uporabnikov v projekt že od začetka. S tovrstnim internim marketingom zmanjšamo klasičen odpor do novosti. Če opredelimo potencialne nevarnosti v projektu s tehnološkega in vsebinskega vidika, bi rekli, da so nevarnosti s tehnološkega vidika v našem primeru naslednje: - operativni sistemi zajemajo podatke na operativni ravni (ERP podatki o proizvodnji, Finance računovodski podatki: fakture, zapadlosti...), - imamo veliko bolj ali manj povezanih samostojnih IS (BaaN, idocs, podatki v Excelu), - različni IS na različnih platformah, - velike količine podatkov, - različni dostopi do podatkov brez avtorizacij, - točnost in povezljivost podatkov,

53 Z vsebinskega vidika vidimo naslednje nevarnosti: - imamo različne poglede in interpretacije podatkov, - naročnikove prioritete se spreminjajo, - sogovornik je neustrezen, - nerazumevanje zahtev, - prevelike zahteve, - nerealni izvedbeni roki. V postopku uskladitve zahtev in potreb z bodočimi uporabniki sistema moramo torej biti pozorni na vse navedene nevarnosti z vsebinskega vidika. Naloga projektnega tima je potemtakem, da skozi naslednje oblike komunikacije: - individialni intervjuji, - delavnice, - individualno in skupinsko korespondenco po elektronski pošti določi: - vse različne interpretacije podatkov, ki so povezani s prodajo, jih vsebinsko poenoti in na koncu predstavi v sprejem vsem uporabnikom, - določi prioritete / pričakovanja uporabnikov glede projekta (kaj je bolj in kaj manj bistveno, da se spremlja v strateškem informacijskem sistemu), - ustrezne ključne uporabnike za nadaljevanje projekta (tiste, ki se najbolj zavzamejo za problematiko in so kot taki v nadaljevanju primerni preizkuševalci aplikacije, na koncu pa glavni promotorji sistema), - ustrezne časovne okvire za poenotenje uporabnikovih zahtev Pregled obstoječih individualnih baz podatkov Uporabnikov s področja prodaje je bila poslano poizvedovanje o sistemih, s katerimi sedaj vodijo korespondenco o prodaji. Brez izjem smo prejeli naslednje oblike: - elektronska pošta + Outlook Tasks/Notes/Contacts, - Word (zapisniki, preproste zabeležke, ponudbe), - Excel (seznami kupcev, kalkulacije, analize prodaje, napoved prodaje), - ERP BaaN (fakture kupcem in operativno stanje naročil v proizvodnji), Iz tega sledi, da je povezljivost med podatki zelo slaba. V nekaterih primerih so se uporabljali skupni mrežni diski, kjer so bile objavljene skupne datoteke, nad katerimi pa ni bilo sistema upravljanja (spremljanje verzij, avtorizacije dostopov) Individualni razgovori z uporabniki Kljub splošnemu prepričanju, da imajo uporabniki odpor do sprememb uporabniki niso izražali nezadovoljstva nad novim sistemom spremljanja prodaje, temveč so, v nasprotju z razširjenim prepričanjem, že na začetku imeli več koristnih predlogov in so imeli visoka pričakovanja od novega sistema

54 Večurni individualni razgovori so se izvajali s posameznimi vodjami prodaje in operativnimi logisti v prodaji, torej tistimi, ki so imeli pregled nad celotnim postopkom prodaje, od sprejema povpraševanj, priprave ponudb, pogajanj, pilotskih serij in tekočimi projekti vključno z nadzorom izvajanja. Vsa obstoječa dokumentacija (predvsem Excel in Word obrazci) se je zbrala in jo je projektni tim naknadno obravnaval. Posebej velja izpostaviti predlog, da bi se v program vključilo modul za pripravo ponudb, katerega osnovni del je kalkulacija. Za posamezno povpraševanje kupca je namreč potrebno pripraviti kalkulacijo, ki se sedaj vrši v Excelu, v njej pa prodajniki skupaj z razvojniki in proizvodnimi logisti izračunajo stroške proizvajanja nekega izdelka, po katerem povprašuje kupec. Odločitev je bila, da se tega modula vsaj v začetku v aplikacijo ne vključuje, glavna razloga za to pa sta bila: - aplikacija je namenjena strateškemu pregledu prodajnih projektov in ne operativnemu delu (CRM); po tej logiki bi v aplikacijo morali vgraditi še bazo kontaktov vseh kupcev ipd., - Postopek izdelave kalkulacij se razlikuje od družbe do družbe, celo od programa do programa uniformne rešitve ni moč pripraviti. Z uporabniki je bilo v nadaljevanju dogovorjeno, da bo sistem omogočal tako vnos novih podatkov, kot tudi spreminjanje obstoječih. Že vnešeni projekti se bodo popravljali kadar se bo spremnila katerakoli postavka iz vnosnega obrazca. Za popravek podatkov bo odgovoren vodja projekta, popravek pa mora biti vnešen v roku 7 dni od nastanka. Poleg tega bodo o spremembah v bazi podatkov, torej o vnosu novega ali popravku obstoječega podatka obveščeni tudi nadrejeni po nivojih, ki so opredejeni glede na pomembnost vnosa ali spremembe. Oblikovani so tudi kriteriji za obveščanje po nivojih sistema. Prožilce za obveščanje prikazuje tabela 9:

55 Tabela 9: Prožilci po dogodkih in vlogah - projekti SporociloZadeva New project (nov projekt) Changed project expected sales (spremenjena pričakovana prodaja na projektu) Changed project yearly volume (spremenjen letni volumen prodaje na projektu) Changed project probability of implementation (spremenjena verjetnost projekta) Project agreement expires in 1 year period (pogodba o projektu poteče v roku 1 leta) Project sign of agreement passed (predvideni datum začetka projekta je minil) Project start of production passed (predvideni datum začetka proizvodnje je minil) Project data not commited (podatki o projektu niso potrjeni) Project data unchanged in 1 year period (podatki o projektu niso ažurirani že 1 leto) Changed project EBITDA (spremenjen EBITDA projekta) Changed project expected investment (spremenjena pričakovana investicija na projektu) Changed project ROI (spremenjena doba povrnitve investicije na projektu) Changed project phase (1-4) (spremenjena faza projekta) Changed project phase (5-9) (spremenjena nadaljnja faza projekta) Changed project phase (I to II) (spremenjena skupina faz projekta) Changed project phase (Lost project) (projekt je izgubljen) Changed project sign of agreement (spremenjen je predvideni datum podpisa pogodbe o projektu) Changed project start of production (spremenjen je pričetek proizvodnje) Changed project price per unit (spremenjena je cena kosa v izdelavi) Changed project agreed price cut (spremenjen je dogovorjeni popust na projektu) Rok Dni Kontrol. Kontrol. Pogoj Finance Finance Pogoj Direktor2 Direktor2 Pogoj > > >0 1 > >20% 1 >30% Vir: dokumentacija projekta Hidria SARA,

56 S temi prožilci na primer obvestimo ustrezne uporabnike, da: - je projekt že več kot 1 mesec v fazi pogajanj, - ni bilo na projektu že 1 leto nobenega popravka, - je nekdo popravil pričakovano investicijo na projektu za več kot X odstotkov, - je nekdo popravil pričakovani obseg projekta za več kot X odstotkov, - ipd. Slika 13: Obveščanje o spremembah po elektronski pošti Vir: dokumentacija projekta Hidria SARA, 2007 V odvisnosti od odstopanj pri popravkih vnosov so obveščeni posamezni vodje. Pri odstopanju ključnih podatkov projekta za 5 odstotkov odstopanje ni obveščen nihče. Pri 10-odstotnem odstopanju je obveščen vodja programa, pri 20- ali več- odstotnem odstopanju pa je obveščen direktor družbe oziroma vodstvo korporacije, če gre za prodajni projekt s pričakovanim prometom nad X EUR. Eden od primerov obveščanja o spremembah je prikazan na sliki 13: ob različnih stopnjah spremembe termina sklenitve projekta so po elektronski obveščeni različni uporabniki. Poleg prožilcev za obveščanje preko elektronske pošte vsebuje sistem tudi interne prožilce v samem sistemu, če: - je vnos napačen glede na pričakovano obliko vnosa (npr. MM/LL), - vrednost postavke»ostalo«vseh projektov enega programa presega 10%, - se pogodba izteče v teku enega leta, - je že minil ciljni termin sklenitve dogovora, - je že minil ciljni termin začetka rednih dobav,

57 Uravnotežena verjetnost realizacije projekta Skupaj s ključnimi uporabniki smo določili poseben parameter, s katerim ocenjujemo verjetnost realizacije projekta. Verjetnost realizacije je izračunana iz dveh postavk: a) subjektivna ocena vnašalca projekta, b) objektivna lestvica verjetnosti izvedbe projekta. Subjektivna ocena je ocena, ki jo vnese vnašalec projekta v sam projekt in se spreminja s časom glede na to, koliko je pač odgovorni na projektu prepričan v njegovo realizacijo. Objektivna lestvica verjetnosti izvedbe projekta je določena na podlagi statistike preteklih let in je zapisana v aplikaciji v obliki šifranta, kot ga prikazuje tabela 10. Tabela 10: Objektivna lestvica verjetnosti izvedbe projekta Z.št Faza projekta Request for quotation (sprejeto povpraševanje) Offer (oddana je bila ponudba) Negotiations (projekt je v fazi dogovarjanj) Agreement (podpisana je pogodba o izvedbi projekta) Samples (izdelani so bili vzorčni kosi) Pilot run (teče testna proizvodnja) Serial production (teče serijska proizvodnja) Closed project (projekt je zaključen) Verjetnost realizacije 5% 10% x% x% x% 100% 100% 0% Vir: dokumentacija projekta Hidria SARA, 2007 Kot je videti, se logično skozi nadaljevalne faze projekta statistična verjetnost izvedbe projekta veča. Če je na primer projekt v fazi oddane ponudbe (Offer, tabela 10), je njegova objektivna verjetnost izvedbe 10% (statistično se je v preteklosti 10% vseh oddanih ponudb realiziralo kot končna proizvodnja izdelkov po naročilu)

58 Končna ocena verjetnosti izvedbe projekta se izračuna takole: Ocena_verjetnosti = 1/3 * a + 2/3 * b; a=subjektivna ocena, b=objektivna ocena iz lestvice Ocena verjetnosti izvedbe projekta nam služi tudi kot napoved utežene (ponderirane) prodaje. Če imamo na primer EUR vreden projekt v fazi pogajanj z izračunano verjetnostjo izvedbe 90%, bomo imeli v uteženi (realistični) napovedi prodaje ta projekt zaveden kot EUR vreden projekt Definicija matrike uporabnikov Ker gre za informacijski sistem strateškega pomena za korporacijo, so tudi podatki v njem zaupne narave. Zato je potrebno skrbno definirati vrste dostopov uporabnikov do posameznih segmentov. Tako imajo nekateri uporabniki le omejen dostop samo do lastnih projektov ali investicij, ki so jih vnesli. Nekateri lahko vidijo vse projekte posameznega programa, direktorji družb pa denimo vse projekte v korporaciji. Tabela 11 razlaga vse vloge, ki smo jih definirali v aplikaciji. Tabela 11: Matrika uporabnikov - vloge Vloga Projects Investments Opis Adminstrator (Upravitelj aplikacije) User (uporabnik) Responsible Manager 1 (direktor programa 1) Responsible Manager 2 (direktor programa 2) Company Controller (vodja kontrolinga v družbi) Finance Manager (vodja financ v družbi) General Manager (glavni direktor družbe) Group Controller (vodja kontrolinga v korporaciji) Group Finance Manager (vodja financ v korporaciji) Da Da Upravitelj spreminja šifrante, ažurira uporabnike... Da Da Vsi uporabniki aplikacije Da Da Ima vpogled nad projekti v svojem prodajnem programu Da Da Nekateri prodajni programi imajo dve vodji Da Da Da Da Da Kontroling v družbi potrjuje investicijske zahtevke Finance v družbi potrjujejo investicijske zahtevke Direktor družbe potrjuje investicijske zahtevke in ima pregled nad vsemi prodajnimi projekti Kontroling korporacije potrjuje večje investicijske zahtevke Finance korporacije potrjujejo večje investicijske zahtevke

59 Group General Manager (predsednik korporacije) Investment Reviewer (nadzornik investicij) Project Sales Manager (vodja projektov) Project Reviewer (nadzornik projektov) Da Da Da Da Predsednik korporacije potrjuje večje investicijske zahtevke in ima pregled nad vsemi projekti v korporaciji Nadzornik investicij pregleduje vse investicije v družbi/korporaciji Vodja projektov sprejema obvestila/alarme o stanju projektov Nadzornik projektov pregleduje vse projekte v družbi/korporaciji Vir: dokumentacija projekta Hidria SARA, 2007 Vsakega posameznega uporabnika v korporaciji smo vključili v določene vloge. Vloga User (uporabnik) pomeni uporabnika, ki lahko samo vnaša projekte ali investicijske zahtevke. Responsible Manager (direktor programa) je vodja nekega programa, ki odobrava projekte ali investicije. Project Sales Manager () je vodja projektov na nekem programu ker je v tej vlogi, prejema obvestila, ki so vezana na projekte v njegovem prodajnem programu. Konkretni primer takšnega definiranja uporabnikov prikazuje slika 14. Slika 14: Definiranje pravic uporabnikov Vir: dokumentacija projekta Hidria SARA,

60 Določenega uporabnika dodamo neposredno iz aktivnega imenika korporacije (Active Directory). V primeru v tabeli 12 se vidi, da so nekatere vloge splošne in določene na nivoju družbe (kot npr. Hidria Rotomatika Group Projects Reviewer), nekatere pa so bolj specifično vezane na prodajni program (npr. Hidria Rotomatika Group Fans Projects Sales Manager (vodja projektov)). Uporabnik, ki je naveden v tem primeru, lahko kreira zapise o projektih in investicijah za skupino Hidria Rotomatika, obenem pa ima vlogo nadzornika investicij, kar pomeni, da lahko vidi vse investicijske zahtevke v skupini Hidria Rotomatika, ne glede na program Priprava šifrantov V aplikaciji uporabljamo naslednje šifrante, ki so se v sodelovanju s širšo projektno skupino oblikovali tekom prve polovice projekta, pred gradnjo podatkovnega modela: - Customers (šifrant kupcev/strank), - Units (merske enote), - Group-Program-Product (večnivojski), - Division-Application-System-Complex (večnivojski), - Countries (seznam držav, na katere vežemo stranke), - Project Phases (faze projekta), - Project Types (vrste projektov). V nadaljevanju malo podrobneje razložimo logiko šifrantov. Customers (stranke) Šifrant strank vsebuje poleg nazivov podjetij še ime korporacije, kateri podjetja pripadajo. Avtomobilska industrija, v kateri je korporacija zelo prisotna, je tipičen primer večnivojske oskrbovalne verige. Na takšnem trgu je zelo pomembno vedeti, katerim skupnim kupcem dobavljajo podjetja iz korporacije, torej katerim večjim korporacijam oz. ponudnikov sestavljenih sklopov za avtomobilsko industrijo. Nadalje v šifrantu stranko opredelimo z državo, v kateri se nahaja. Iz tega bomo kasneje lahko analizirali geografsko prisotnost prodaje. Z ostalimi postavkami v šifrantu stranko opredelimo kot interno ali zunanjo. Interna stranka je družba znotraj korporacije, torej gre za interno prodajo. Ker je interna prodaja v korporaciji prisotna, je dobro vedeti, koliko je te interne prodaje, čeravno je vsaka prodaja v finančnih izkazih pač prodaja, ne glede na to, ali se prodaja družbi, ki je lastniško povezana s korporacijo ali ne. Za vse interne družbe velja pravilo, da jim pripada t.i. koda BaaN (Code). To je šifra podjetja, s katero se to podjetje pojavlja v informacijskem sistemu BaaN. V korporaciji namreč velja dogovor, da ima vsako podjetje v korporaciji svojo trimestno kodo, s katero se predstavlja v informacijskih sistemih

61 Units (merske enote) Šifrant merskih enot je preprost in skrajšan za potrebe družb v korporaciji. Možno ga je spreminjati in dodajati. Vsebuje postavke: kilograms, liters, pieces, Sets (1.000 pcs) in pounds. Group-program-product (skupina-program-produkt) Ta večnivojski šifrant je namenjen delitvi projektov po programih in produktih, ki jih družbe v korporaciji tržijo. Vsaka od družb trži enega ali več prodajnih programov, v vsakem od prodajnih programov pa najdemo vsaj en končni produkt. V tabeli 12 npr. družba Hidria AET Group proizvaja in trži v sklopu programa Diesel Cold Start Systems produkt PTC Heater to je električni grelnik, ki pred vžigom ogreje motor (in kabino). S pomočjo takšnega šifranta se lahko pri strateških analizah poljubno posvetimo produktom, celotnim programom ali prodajnim rezultatom družb. Tabela 12: Šifrant Group-Program-Product Vir: dokumentacija projekta Hidria SARA, 2007 Division-Application-System-Complex Štirinivojski šifrant D-A-S-C je namenjen temu, da prodajni projekt širše opredelimo v Hidriino divizijo in znotraj nje v sklop, kamor se produkt vgrajuje. V primeru v tabeli 13 vidimo, da npr. druga vrstica opredeljuje tiste projekte, kjer tržimo kose (elektromotorje) za vodne črpalke za pogonski agregat v osebnih avtomobilih, ki spadajo v Hidriino divizijo Automotive

62 Tabela 13: Šifrant Division-Application-System-Complex Vir: dokumentacija projekta Hidria SARA, 2007 Countries (države) Gre za klasični mednarodni šifrant držav. Namenjen je analizi geografske razpršenosti prodajnih projektov. Project Phases (faze projekta) Zelo pomemben in zelo specifičen šifrant je šifrant faz projekta. Po dogovoru s ključnimi uporabniki aplikacije in vodstvom se je izdelal šifrant, s katerim opredelimo fazo, v kateri se projekt nahaja. Začetna faza je faza razvoja, sledijo faze ponudb, pogajanj, testne proizvodnje, redne proizvodnje in konca proizvodnje (zaprtje projekta). Vseh uporabljenih faz je 11. Posebnost vsake faze je»objektivna verjetnost«, ki ji pripada.»objektivna verjetnost«pomeni verjetnost realizacije projekta, kateri se ob izračunu skupne verjetnosti realizacije projekta doda še ustrezno (nižje) obtežena objektivna ocena vodje projekta. Projekt v fazi R&D-Presentation ima npr. objektivno verjetnost 40%, ki je bila dorečena na podlagi statistike predhodnih projektov (40% projektov v fazi razvoja se je v preteklosti uspešno prevesilo v proizvodnjo). Project Types (Vrste projektov) V korporaciji obstaja delitev programov in projektov na strateško bolj ali manj pomembne. Zaradi tega se je sprejel šifrant tipa projekta, ki opredeljuje njegovo strateško pomembnost. Namen šifranta je dobiti vpogled, koliko celotne prodaje se vrši znotraj strateških okvirov in koliko je projektov na prodajnih programih, ki niso strateško pomembni

63 Predstavitev rešitve uporabnikom Ko je bil definiran osnutek aplikacije, so bile organizirane revizijske delavnice s ključnimi uporabniki po področjih (vodje prodaje, ključni logisti, kontroling, finance). Na delavnicah se je predstavilo mapo projekta in se na podlagi zaslonskih mask diskutiralo o rešitvi. Bistvenih odstopanj od pričakovanj uporabnikov ni bilo, še največ je bilo pomislekov o tem, kako podrobno vnašati podatke o projektih (konkretno: ali vnesti vsako povpraševanje kupca kot projekt tipa»prejeto povpraševanje«?). Dogovor glede tega je bil, da se teži k čimbolj popolni sliki o projektih, a še vedno v razumskih mejah birokracije, zato naj vsak vodja prodaje sprejme pravilo o tem, kako podrobno se vnaša projekte (nekateri prodajni programi prejmejo le nekaj povpraševanj letno, medtem ko nekateri prejmejo sicer vrednostno nižja povpraševanja nekajkrat tedensko). Veliko vprašanj se je pojavilo še po delavnicah, preko elektronske pošte, navajamo primer vprašanja z odgovorom, ki ga je pripravil projektni tim. Vprašanje:»Bo pri vnosu imena projekta potrebno preverjati, če projekt s takim imenom že obstaja (za isto družbo, divizijo, program, )? Če da, kaj storiti? Uporabnika zgolj obvestimo in dovolimo vnos ali blokiramo vnos?«odgovor: Ne, ker je ime projekta le nek opis, ki koristi predvsem prodajniku in njegovemu nadrejenemu za lažje iskanje zadetkov/projektov. Ker je ime projekta opis, lahko oseba A vnese»audi A3 zglob volanski«, oseba B pa»audi A3 ulitki«. Načeloma je to lahko isto, samo tega ne more noben program kontrolirati. RAZEN, če se naredi tako, da vnosniku ob zaključku vnosa projekta program samo INFORMATIVNO izpiše zraven že vnešene projekte, ki imajo podobno ime (npr. če najde kje zapis, kjer je v imenu projekta tudi»audi«. V konkretnem primeru je bil ta razmislek tudi upoštevan v kodiranju aplikacije, tako da ta uporabniku avtomatsko prikaže seznam drugih projektov, ki vsebujejo enak črkovni niz v polju Project name (Ime projekta)

64 6.8. Izdelava aplikacije in testiranje Izdelava aplikacije je potekala na strani zunanjega izvajalca. V postopku izdelave ni bilo nobenih težav ali nesoglasij. Morebitne dodatne nejasnosti so se reševale sproti po elektronski pošti ali po telefonu s člani projektnega tima. Nedorečenosti je bilo vseeno zelo malo, kar je pokazatelj dobrih priprav, na katerih se je tudi dejansko porabilo precej več časa, predvsem v definiranju zahtev z bodočimi uporabniki. Razlog za dorečenost v logiki aplikacije je tudi skrben popis zahtev tako s strani projektnega vodje kot s strani zunanjega izvajalca. Kot je bilo omenjeno v predhodnem poglavju, se je za razvoj aplikacije kot gradnjo podatkovne baze uporabljalo orodje Microsoft Visual Studio 2005 v navezi z MS SQL V nadaljevanju si poglejmo nekaj najpomembnejših sklopov gradnje aplikacije, ki so logično sledili ročnemu popisu zahtev Diagram uporabe Diagram uporabe prikazuje vse logične interakcije med akterji; z njim grafično ponazorimo funkcionalne zahteve poslovnega modela. Diagram sestavljajo vloge (akterji) in primeri uporab (uses). Akterji so osebe ali sistemi, ki vzročno/posledično delujejo v povezavi z drugimi osebami ali sistemi. Z diagramom uporabe torej prikazujemo vse možne logične scenarije, ki naj bi se odvijali v poslovnem procesu, ki ga aplikacija v nadaljevanju poskuša realizirati. V sledečem primeru je na sliki 15 prikazan eden od enostavnih diagramov uporabe; v zgornjem delu ponazarja proces potrjevanja zahtevkov in pregleda prodajnih projektov, v spodnjem delu pa pove, da ima aplikacija dva administratorja glavnega administratorja in podadministratorja šifranta strank (kupcev). 1 V diagramih, ki sledijo, se večkrat pojavlja ime Histem, kar je razvojno ime za aplikacijo za spremljanje strateških in razvojnih prodajnih projektov ter investicij, ki je kasneje dobila končno ime SARA (Strategic Analysis and Research Application)

65 Slika 15: Diagram uporabe (Use-Case) Vir: dokumentacija projekta Hidria SARA,

66 Strukturni diagram S strukturnim diagramom razdrobimo celotni sklop (aplikacijo) na manjše podsklope (module) z namenom, da imamo pregled nad cilji in podcilji, ki jih moramo pri gradnji aplikacije doseči. Strukturni diagram je drevesnega tipa, kjer je v korenu glavni sklop (cilj), ki se veji do listov (v našem primeru posameznih vnosnih mask). Strukturni diagram služi izvajalcu in naročniku, da s ponazorjenimi delitvami sklopov dosežeta obojestransko potrditev predhodnih ustnih ali pisnih dogovorov. Na sliki 16 je prikazan strukturni diagram aplikacije, ki ponazarja delitev aplikacije na module Common (obvestila uporabnikom, tako kot neke vrste Inbox predal v Outlooku), Projects (seznam vseh projektov itd.), Investmenst (med drugim seznam investicij v teku (Requested), Lists (šifranti) in Settings (administratorske nastavitve: seznam uporabnikov, nastavljanje prožilcev ipd.). Slika 16: Strukturni diagram Vir: dokumentacija projekta Hidria SARA,

67 Podatkovni model Ena najpomembnejših faz gradnje aplikacije je izdelava podatkovnega modela. Ta nam prikazuje, kako je strukturirana podatkovna baza in kakšna so razmerja med podatkovnimi gradniki v njej. Predstopnja gradnje logičnega podatkovnega modela je definicija konceptualne podatkovne sheme, ki zopet med drugim služi interakciji z naročnikom in usklajevanje definicij delovanja aplikacije. Del konceptualne podatkovne sheme je prikazan na sliki 17. Slika 17: Konceptualna podatkovna shema Vir: dokumentacija projekta Hidria SARA, 2007 V nadaljevanju konceptualno podatkovno shemo razvijemo v logični podatkovni model, kjer so podrobno opisana razmerja med posameznimi objekti (entitetami). Uporabljena je bila tehnika modeliranja E-R (Entity-Relationship), kot je prikazana na sliki 18, kjer je definirano vsako vnosno ali izračunano polje v aplikaciji, vključno z njegovimi omejitvami (dolžina in tip zapisa). Glavna entiteta v primeru na sliki 18 je Projekt s primarnim ključem ProjektID. V relacijah vidimo, da lahko enemu projektu pripada maksimalno ena investicija, medtem ko na eno investicijo lahko vežemo več projektov

68 Slika 18: E-R diagram Vir: dokumentacija projekta Hidria SARA,

69 Kodiranje Samo kodiranje je bilo izvedeno v objektno-orientiranem jeziku MS Visual C#. V Visual C# lahko programiramo Windows aplikacije (kot v našem primeru), spletne aplikacije, mobilne aplikacije (PDA Personal Digital Assistant) in Office aplikacije (npr. Outlook Forms). Po raziskavi ( developmenttopics) naj bi 62 odstotkov vseh razvijalcev vsaj občasno programiralo v jeziku Visual C# (v praksi razvijalci pod pogovornim nazivom C# prazvaprav omenjajo konkretni Microsoft C#). Ker znak # na različnih spletnih straneh ni dovoljen, je informacije o jeziku možno najti pod nazivom Microsoft C Sharp. Izvajalec je skladno s priporočili skrbno uporabljal komentarje za posamezne odseke kode. Dodatnega kodiranja je bilo relativno veliko, saj je aplikacija imela veliko pogojenih scenarijev, vmesnih validacij polj in raznih prožilcev. Vse uporabniške vmesnike in objekte v njih je izvajalec oblikoval skupaj z naročnikom, kjer se je upoštevala filozofija sistema:»simple and logical« Dodatni modul Investicije in potrjevanje projektov Tekom projekta vzpostavitve aplikacije za spremljanje prodajnih projektov je prišlo do razširitve aplikacije še na področje spremljanja investicij. Do predstavitve dodatnih potreb je prišlo dovolj zgodaj, da to ni bistveno podaljšalo projekta ali celo ogrozilo uspeha vpeljave. V nadaljevanju je razložen pristop k reševanju dodatnih zahtev sredi projekta Vzroki za nastanek modula Ko je bila aplikacija za spremljanje prodajnih projektov tik pred fazo razvoja, je bila kot zasnova predstavljena vodstvu in ostalim članom korporacije, ki pokrivajo poslovne funkcije: vodenje kakovosti, informatiko, prodajo, nabavo, finance, proizvodnjo in korporativno komuniciranje. Iz skupine je bilo predlagano spremljanje dodatnih informacij v zvezi s projekti, in sicer informacij o investicijah, ki so potrebne za relizacijo nekega projekta. Pri industrijski prodaji gre največkrat za prodajne projekte, kjer je potrebno izvesti začetno investicijo, npr. v delovni stroj za večletno produkcijo nekega izdelka. Ključni podatek o profitabilnosti projekta je sicer izračunan posebej, z različnimi orodji, ki jih uporablja prodajno osebje, največkrat Excel. Ta podatek je vpisan med podrobnosti o projektu. Na strani izdatkov zajema vse, od potrebnih investicij, do stroškov dela in izrednih odhodkov

70 Investicije so torej le en del izdatkov v projektu, toda zanje v korporaciji že iz preteklosti velja poseben dogovor: potrebno jih je potrjevati v vnaprej določeni verigi. V preteklosti se je za to uporabljal obrazec Excel, ki ga je član projekta ročno izpolnil, natisnil in fizično oddal naslednjemu v verigi potrjevanja. Takšen postopek ima seveda svoje omejitve in slabosti. Največja slabost je ta, da se potrjevanje zahtevka na papirju lahko zavleče, saj se velikokrat zgodi, da potrjevalec v verigi na list pozabi ali ga celo izgubi. Dodatno je obrazec tog in neveščemu vnašalcu omogoča, da vnese pomanjkljive ali napačno interpretirane podatke. Ker je potrjevanje investicij vezano na vse investicije nad določenim zneskom, ne glede na to, ali gre za investicijo v računalniško opremo ali v delovni stroj za proizvodnjo komponente za večji prodajni projekt, je nujno potreben ustrezen razmislek o tem, ali se bo v aplikaciji za spremljanje strateških projektov spremljalo tudi raznorazne investicije v korporaciji. Končni razmislek je bil, da spremljanje vseh investicij (ne samo tistih, ki so vezane na projekte) ne more škoditi in da bi bilo nesmiselno določene investicije spremljati skozi aplikacijo, ostale pa še vedno v papirni obliki. Z novim načinom spremljanja investicij skozi aplikacijo želimo doseči naslednje: - imeti ažuren pregled nad vsemi odprtimi investicijami, - voditi statistiko vseh investicij v preteklosti, - spremljati razmerje napovedanih in realiziranih investicij na projektih, - točno definirati verigo potrjevanja investicijskih zahtevkov, - skrajšati čas potrjevanja zahtevkov Pristop k implementaciji Po dogovoru o realizaciji modula se je formiral ožji tim, sestavljen iz siceršnjih članov projekta: - vodja IT, - vodja projektov v korporaciji, - vodja kontrolinga v korporaciji (vključena kasneje v projektu). Naloga tima je bila v čim krajšem času: - izvesti potrebne formalnosti za dodelavo modula (pogodba z izvajalcem), - organizirati delavnice s predstavniki finančnih sektorjev družb korporacije, - preizkusiti delovanje modula in - z delegiranjem izobraziti večje število vnašalcev investicijskih zahtevkov

71 V tabeli 14 so oglejmo inicialno opredelitev dela vnosnih polj za dodatni modul Investicije. Vnosna polja so v osnovi definirana v angleškem jeziku, ker je aplikacija namenjena uporabi v družbah korporacije po svetu. Tabela 14: Modul za investicije: predhodna opredelitev vnosnih polj Ime vnosnega polja Vsebina vnosa Pomen vnosa Možnost ažuriranja Applicant (vnašalec) Oseba, ki vodi investicijo, ki je predmet vnosa. Možnost spremljanja investicij po posameznih vodjih Možnost osebe, ki vodi investicijo za dostop do svoje baze podatkov, izpisov, poročil, vpogledov... Razen izjemoma, se ime vodje projekta ne spreminja. Request ID Zaporedna številka investicije Project ID (zaporedna številka projekta) Številka, oz. oznaka projekta, ki se kreira avtomatično na osnovi sistema govoreče kode, iz nje pa je razvidna zaporedna številka vnosa projekta, program in kupec Možnosti analize podatkov s kritrijem zaporedne številke vnosa oz. Iskanje podatkov po zaporedni številki vnosa Številka projekta se nikoli ne spremeni Project name (ime projekta) Delovno ime celotnega projekta, kot ga poimenuje kupec ali kot ga poimenujemo sami Pomembno zaradi ločevanja posameznih projektov, kadar z enim kupcem delamo na več projektih Vnos se ne spreminja Project type (vrsta projekta) Izbor iz šifranta glede na uvrstitev produkta v ustrezen program Pomembno zaradi spremljanja strateškega fokusa Vnos se ne spreminja Vir: dokumentacija projekta Hidria SARA,

72 Rezultat dogovorjenih vnosnih polj je osnovni uporabniški vmesnik; obrazec za vnos investicijskih zahtevkov, ki je prikazan na sliki 19. Na obrazcu je razvidno, da se investicije delijo na splošne, vezane na projekt ter na investicije, ki jih sofinancira kupec. V odvisnosti izbire vrste investicije se obrazec dinamično prilagaja izbiri. V osrednji del obrazca uporabnik vnaša posamezne postavke v celotni investiciji, v spodnjem delu pa nastavljena zelo uporabna funkcija spremljanja statusa potrjevanja zahtevka v vnaprej določeni verigi potrjevalcev. Slika 19: Obrazec za vnos investicijskega zahtevka Vir: dokumentacija projekta Hidria SARA, 2007 Projektni tim je pregledal vse dotedanje načine potrjevanja investicij po družbah v korporaciji. Odkritih je bilo več različnih pristopov, zato so bila potrebna nadaljnja usklajevanja s predstavniki kontrolinga po družbah. Kljub temu smo obdržali nekaj specifik, ki so veljale po družbah, kot na primer mejne zneske pri potrjevanju investicije. Slika 20 prikazuje algoritem potrjevanja zahtevkov v odvisnosti od družbe, višine investicije in programa (spremenljivke X, Y, Z)

73 Slika 20: Algoritem potrjevanja investicijskih zahtevkov Nov zahtevek za investicijo Izbira družbe Podrejena družba ali divizija? Da (družba je član v skupini podrejenih družb»hidria Related Companies«) Dokončna potrditev Group President Da Družba = Hidria d.o.o.? Ne (core družba ali družba v grupi Hidria Corporation) Ne Dokončna potrditev Vloga* Ne Investicija > X EUR*? Ne Program = G&A Services? Da Da Dokončna potrditev General Manager Ne Investicija > Y? Ne Investicija > Z? Da Dokončna potrditev Group President Da Vir: dokumentacija projekta Hidria SARA, 2007 Nadaljnje je bilo potrebno določiti odvisnosti med projekti in investicijami. Imamo namreč že dva modula v aplikaciji, ki imata neko soodvisnost. Ugotovilii smo, da lahko pride do naslednjih situacij glede odvisnosti: - en projekt ima lahko nič ali več investicij, ki so zanj potrebne, - za projekt ni potrebne investicije (dodatne opreme ne potrebujemo, ker jo že imamo v podjetju), - investicija se ne nanaša na noben projekt (splošna investicija itd.), - ena ali več investicij se nanaša na enega ali več projektov

74 Določili smo, da se investicijski zahtevki pišejo ločeno od vnosa projektov, s tem da na posamezen investicijski zahtevek dodamo poljubno število že prej vnešenih projektov (projekt mora vedno obstajati pred investicijo, četudi šele v razvojni fazi kot razvojni projekt). S tem pokrijemo vse prej omenjene situacije. Slika 21 prikazuje primer dodajanja investicije na projekt. Slika 21: Povezovanje investicij s projekti Vir: dokumentacija projekta Hidria SARA, 2007 V primeru vidimo, da na investicijski zahtevek lahko dodamo poljubno število projektov, kjer opredelimo, koliko odstotkov investicije se nanaša na kateri projekt. Ta situacija je zelo pogosta, saj se večkrat investira v delovne stroje, s katerimi se proizvaja izdelke za več prodajnih projektov. Posebna oblika investiranja je Customer Property, kjer kupec investira v delovno opremo, kar je tudi pogosto. Prožilci in obveščanje Posebnost modula za investicije so prožilci. Ker je postopek potrjevanja investicij sam po sebi tokokrog, ga je treba v aplikaciji tako tudi realizirati. V ta namen so se določile matrike uporabnikov, ki so obveščeni o določenih dogodkih, odvisno glede na pomembnost vnosa ali spremembe. Definirali smo naslednje dogodke, ob katerih aplikacija pošlje sporočilo ustreznim uporabnikom po elektronski pošti (tabela 15)

75 Tabela 15: Prožilci po dogodkih in vlogah - investicije SporociloZadeva Investment audit report entered (vnešeno je bilo zaključno poročilo o investiciji) Investment approved (investicija je bila odobrena) Investment rejected (investicija je bila zavrnjena) Investment completion report entered (vnešeno je bilo zaključno poročilo o investiciji) Investment request (zahtevana je bila potrditev investicije) Investment completion report needed (potrebno je vnesti zaključno poročilo) Investment audit report needed (potrebno je vnesti zaključno poročilo) Investment request not send (zahtevek za investicijo še ni bil odposlan) Investment BaanID entered (vnešena je bila BaaN številka projekta) Investment BaanID needed (potrebno vnesti BaaN številko projekta) Investment postpone request (zahtevan je bil odlog investicije) Investment postponed (investicija je bila odložena) Rok Dni Kontrol. Kontrol. Pogoj Finance Finance Pogoj Direktor2 Direktor2 Pogoj 0 1 >x 1 >x 1 >x >y 1 >y 1 >y >6 0 > Vir: dokumentacija projekta Hidria SARA, 2007 V tabeli 15 so torej definirani vsi dogodki, ob katerih se proži alarm oz. obvestilo. Tabela 15 v osnovi pravi, da naj se pošlje opozorilo različnim uporabnikom, če: - je bil vnešen Draft investicijski zahtevek in ni bil oddan v potrjevanje 14 dni (obvestilo dobi vnašalec), - uporabnik v verigi ni potrdil ali zavrnil zahtevka več kot 7/14 dni (1. in 2. obvestilo), - vnašalec 1 mesec po predvidenem datumu investiranja ni vnesel podatkov o dejanskem realiziranem investiranju (post-completion), - itd Dodatek - potrjevanje projektov Glede na to, da so nekateri projekti s stališča dobičkonosnosti boljši in nekateri slabši, je smiselno v aplikacijo za strateško spremljanje projektov vgraditi mehanizem, ki bo opozarjal na odstopanja. S pomočjo tega mehanizma bodo tako vodstvo kot vodje projektov pravočasno opozorjeni na nedoseganje normativov, ki veljajo znotraj korporacije

76 Za ta namen se vsakemu prodajnemu programu opredeli t.i. planirano stopnjo EBITDA (Earnings Before Interest, Taxes, Depreciation and Amortization). Gre za stopnjo dobičkonostnosti, ki jo imajo nekatere branže že zaradi samih razmer na trgu boljšo, nekatere pa slabšo temu vsled se stopnje EBITDA razlikujejo po prodajnih programih. Ciljno stopnjo EBITDA se opredeli za vsak program posebej in za vsako prihodnje leto vnaprej. To upravlja kontroling služba v šifrantih aplikacije. Ker imamo v aplikaciji že vzpostavjen sistem pošiljanja opomnikov po elektronski pošti, je nadgradnja na opominjanje stopnje EBITDA enostavna. Toda odločili smo se, da poleg opominjanja po elektronski pošti vgradimo še mehanizem potrjevanja, ki bo, poenostavljeno povedano, onemogočal, da se slabi projekti sploh zavedejo v sistem. Za dosego mehanizma potrjevanja je potrebno opredeliti: - vse možne statuse projektov in - vse vloge, ki jih vodstvo in člani projektov zavzemajo v aplikaciji. Vse možne statuse projektov že imamo (faza razvoja, faza pogajanj, faza podpisa pogodbe itd.) Vse vloge pa tudi že imamo dorečene. Vloga projektnega vodje obstaja, ostale vloge (vodja Poslovne Enote, direktor družbe ipd.) pa so bile definirane tekom gradnje modula za potrjevanje investicij. Poglejmo si delovanje mehanizma potrjevanja projektov na primeru na sliki 22. Slika 22: Potrjevanje projektov, ki so v fazi razvoja Vir: dokumentacija projekta Hidria SARA, 2007 V tem primeru vidimo, da oddaja projekta v potrditev ni mogoča, če ta projekt dosega samo 60% pričakovanega EBITDA. To razmerje se izračuna tako, da

77 trenutno stopnjo projektovega EBITDA delimo s pričakovano stopnjo EBITDA, ki je vnešena v šifrantu *100. Če ima projekt razmerje EBITDA med 60 in 100 odstotki, je pogojno ustrezen in ga mora potrditi direktor poslovne enote. Če ga ne potrdi, takšen projekt ne obstaja niti v sistemu SARA in posledično nasploh ne obstaja, kar pomeni, da se aktivnosti na tem kupcu ne smejo več izvajati. Če je pričakovana vrednost projekta višja, potem morajo ta projekt poleg direktorja poslovne enote potrditi še glavni direktor družbe, vodstvo korporacije in direktor razvoja, saj gre za projekt, ki je v fazi razvoja. Slika 23 prikazuje, kako obravnavamo projekte, ki so že mimo faze razvoja, npr. projekte, ki so v fazi podpisovanja pogodbe. Slika 23: Potrjevanje projektov, ki so v fazi podpisovanja pogodbe Vir: dokumentacija projekta Hidria SARA, 2007 V takšnem primeru je meja upravičenosti še vedno 60% EBITDA. Za vse ostale nivoje pa morajo projekte potrditi tako člani projekta, kot vodstvo družbe in vodstvo korporacije. In to ne glede na to, ali je projekt ustrezen (razmerje med 100 in 110), ali profitabilen (nad 110)

78 6.10. Definiranje uporabniških izpisov v aplikaciji Bistveni del aplikacije so seveda raznovrstni izpisi, ki uporabnikom prinesejo dodano vrednost. V aplikaciji izpise delimo na: - osnovne izpise (razni pregledi že vnešenih podatkov), - izpeljane izpise (sumirani, povprečni, odstotkovni in podobni izpeljani analitični izpisi), - servisne izpise (izpisi, namenjeni upravljalcem aplikacije). Čeprav je v navadi, da se tekom gradnje informacijskega sistema izpisi definirajo zelo zgodaj, je v tem primeru do te definicije prišlo zelo pozno, to je na končnih delavnicah, ko je bila aplikacija predstavljena končnim uporabnikom v finalni verziji. Razlogov za kasnejšo definicijo izpisov je bilo več, med njimi najpomembnejši: - uporabniki do konca niso imeli jasne slike o tem, kaj lahko aplikacija ponudi in so si težje predstavljali možne izpise, - že od začetka je bil pripravljen osnovni tabelarični pregled vseh projektov, ki je dovolj za osnovne (ne analitične) preglede, - gledano s terminskega stališča je bilo potrebno aplikacijo čimprej spraviti v uporabo konkretno jo pričeti uporabljati za vnašanje projektov. Vsi izpisi so bili narejeni z orodjem Microsoft Reporting Services, ki je del podatkovne baze Microsoft SQL Značilnost orodja Reporting Services je, da iz različnih baz podatkov (v našem primeru SQL 2005) preko varnostnih mehanizmov (v našem primeru MS Active Directory) ustvari izhodne izpise v različnih datotečnih formatih: HTML, Excel, PDF..., uporabnik pa jih lahko na enostaven način distribuira po elektronski pošti, skozi datotečni sistem ali npr. skozi Outlookova Opravila (Tasks) Osnovni izpisi Najpomembnejši in za večino uporabnikov najbolj pogosto uporabljan izpis je osnovni tabelarični izpis vseh projektov, ki je sicer z zamegljenimi deli zaradi zaupnosti poslovnih podatkov prikazan na sliki 24. Ta izpis nudi prikaz projektov po vrsticah na način, kot so ga vajeni vsi uporabniki podobno kot tabela Excel. Možno je sortiranje seznama projektov po različnih stolpcih, padajoče in naraščajoče. Dodatno je možno filtriranje po predhodno definiranih poljih iz stolpcev in iskanje določenih nizov. Spodaj v seznamu imamo posebej izračunane konsolidirane (sumarne in utežene) podatke o napovedani prodaji za prihodnja leta. To je hkrati tudi bistvena informacija, zaradi katere se je aplikacija sploh razvijala

79 Slika 24: Osnovni tabelarični izpis Vir: dokumentacija projekta Hidria SARA, Izpeljani izpisi Izpeljani izpisi so analitičnega značaja zanje velja, da uporabniku dajo novo, dodatno informacijo, ki se je prej ni zavedal. Tak primer je stopnja rasti prodaje nekega programa po posameznih državah. Da bi ta podatek imeli v času pred aplikacijo, je bilo v navadi posebej definirati predlogo Excel, v katero so prodajniki vnesli ustrezne podatke in jo potem sešteti na nivoju korporacije, družbe ali programa. To je bilo dolgotrajno početje, podatki so se večkrat napačno interpretirali ali prirejali. V aplikaciji podatke imamo, potrebno je samo zagnati željeni izpis, kjer navadno najprej skozi filter omejimo izpis na obdobje, divizijo v korporaciji in na ostale parametre. Temu sledi izpis, ki se lahko razteza čez več strani. Možno ga je poslati po elektronski pošti, v obliki datoteke PDF ali HTML, možno ga je izvoziti kot datoteko na trdi disk

80 Izpisi v modulu Investicije Za modul Investicije veljajo pri izpisih ista pravila kot za glavni modul Projekti. Tako imamo na voljo osnovni tabelarični izpis, kjer lahko med drugim vidimo: - seznam vseh investicijskih zahtevkov na določenem programu, ki še niso bili potrjeni, - seznam investicijskih zahtevkov, ki že najdlje časa čakajo na odobritev, - seznam investicijskih zahtevkov točno določenega vlagatelja, - seznam zavrnjenih investicijskih zahtevkov v določeni družbi, - seznam investicijskih zahtevkov, ki bodo aktivni v naslednjem letu (Start-up date), - itd. Poleg osnovnih imamo ravno tako na razpolago tudi izpeljane izpise. Eden izmed njih je izpis vseh investicij, ki so bile odobrene, a še ne realizirane Servisni izpisi Za potrebe upravljanja aplikacije so bili definirani servisni izpisi. Ti izpisi omogočajo na enostaven način pridobiti naslednje informacije v obliki preglednih tabel: - matrika uporabnikov (prikaz uporabniških pravic po programih in družbah), - aktivnosti uporabnikov v aplikaciji (prijave, odjave, kreiranje vnosov, generiranje poročil ipd.), - izpisi šifrantov (podlaga za izvoz šifrantov v izvozne datoteke). Servisni izpisi prikazujejo matriko uporabnikov z vlogami, v katerih se pojavljajo. Tak izpis je uporaben za hitro odkrivanje nepravilnosti v definicijah uporabnikov (npr. če nek uporabnik nima dovolj pravic za vpogled v določene izpise). Servisni izpis služi tudi za ugotavljanje odvečnih uporabnikov, ki so eventuelno že zapustili podjetje (ker ustrezne logistike za ažuriranje prihodov/odhodov uporabnikov v korporaciji še ni) Uporabniška dokumentacija Posredovanje navodil za uporabo aplikacije do uporabnikov je pomemben del uvajanja aplikacije. Celotni proces uvajanja aplikacije, gledano s strani uporabnika, poskusimo v tem projektu opredeliti z naslednjimi fazami: - uvodni razgovori z uporabniki (pridobivanje informacij in neke vrste uvodno seznanjanje z novo aplikacijo - interni marketing), - delavnice s ključnimi uporabniki za oblikovanje šifrantov (uporabniki so že bili dodatno seznanjeni z logiko delovanja aplikacije),

81 - predstavitve prvih verzij aplikacije (namen pridobiti povratno informacijo od uporabnikov), - naknadna usklajevanja preko elektronske pošte in individualnih razgovorov, - predstavitev končne verzije v obliki enodnevne delavnice (najpomembnejši del uvajanja aplikacije), - predaja uporabniške dokumentacije v elektronski obliki. V nadaljevanju razložimo zadnji dve najpomembnejši aktivnosti v postopku uvajanja aplikacije. Predstavitev končne verzije Na celodnevni delavnici so se zbrali vsi ključni uporabniki ter celotni projektni tim. Ker je bilo ključnih uporabnikov preveč, se je delavnica razdelila na dva dneva, v dve skupini, kjer je bilo v vsaki skupini okoli 30 uporabnikov. Po začetni predstavitvi aplikacije v Power Pointu se je delavnica prevesila v praktični del. Skoraj vsak uporabnik je imel s seboj svoj prenosni računalnik, zato smo praktični del uvodoma izkoristili za namestitev aplikacije na uporabniške računalnike. Nato je sledilo praktično delo vsakdo je moral v svojo aplikacijo vpisati referenčni projekt, nanj vezati investicijo ipd. Sproti so se pojavljala vprašanja, na katera se je neposredno odgovarjalo. Delavnica se je upešno zaključila z dogovorom, da ključni uporabniki pridobljeno znanje prenesejo na svoje sodelavce, ki se bodo aplikacije tudi posluževali, predvsem za vnose. Predaja uporabniške dokumentacije Ker je vseh uporabnikov okoli 250, je nujno potrebno izdelati tudi pisna navodila za uporabo aplikacije ta zahteva je bila dogovorjena z izvajalcem že v začetku projekta. Izvajalec je pripravil podrobna navodila v obliki datoteke Microsoft HTML Help s končnico.chm. Datoteka je bila vgrajena v aplikacijo pod klasični meni Help. Dodatno so bila navodila optimizirana za tisk, tako da si lahko vsak uporabnik po potrebi navodila natisne na papir. Skladno z definirano strukturo zapisa MS HTML Help, so bila navodila razdeljena na poglavja, znotraj katerih je lahko uporabnik iskal s preprostim iskalnikom po ključnih besedah. V primeru na sliki 25 vidimo, da so navodila preprosta, jedrnata, kombinirana z grafiko in tekstom. Kljub temu, da je aplikacija napisana v angleškem jeziku, so navodila v slovenščini, saj je bilo v začetnem obdobju uporabe več kot 95 odstotkov uporabnikov slovensko govorečih. Ko se bo aplikacija širila na angleško govoreče uporabnike, se bo navodila enostavno prevedlo in v meni dodalo angleški jezik

82 Slika 25: Uporabniška navodila Vir: dokumentacija projekta Hidria SARA, 2007 Uporabniška navodila v grobem zajemajo: - informacije o strukturi aplikacije (meniji, filtriranja, bližnjice na tipkovnici,...), - informacije o rubriki Common (rubrika, v kateri so shranjena sporočila uporabnikom), - informacije o modulu Investicije (kako vpisati novo investicijo, kako vpogledovati po seznamu vseh investicij), - informacije o modulu Projects (kako vpisati nov projekt ipd.), - informacije o šifrantih in administratorskih rubrikah. Ažurna navodila v zvezi z aplikacijo so bila uporabnikom posredovana na posebej za ta namen narejeni spletni strani (obvestila o terminih delavnic, o novih verzijah aplikacije, povezave do namestitve aplikacije ipd.)