Umestitev aplikacije za pošiljanje sporočil SMS v obstoječi sistem CRM

Univerza v Ljubljani Fakulteta za elektrotehniko

Gašper Možina

Umestitev aplikacije za pošiljanje sporočil SMS v obstoječi sistem CRM

Diplomsko delo

Visokošolski strokovni študijski program prve stopnje Aplikativna elektrotehnika

Mentor: izr. prof. dr. Anton Kos

Ljubljana, 2021

Zahvala

Iskreno se zahvaljujem svojemu mentorju, izr. prof. dr. Antonu Kosu za vso pomoč in usmerjanje pri pisanju diplomske naloge ter hitre odgovore na vsa moja vprašanja. Prav tako se za pomoč zahvaljujem sodelavcem in podjetju A1 Slovenija, d.d., ki mi je omogočilo sodelovanje pri izdelavi diplomskega dela.

Za vso podporo med študijem ter pisanjem diplome pa se še prav posebno zahvaljujem svoji družini, zaročenki Tamari, ter hčerki Zarji za motivacijo.

Povzetek

V časih, ko sta v polnem razmahu uporaba in razvoj informacijske tehnologije so tudi vsa večja podjetja prepoznala dolgoročne prednosti vlaganja v informacijsko tehnologijo. Podjetja, ki imajo večjo bazo strank, za upravljanje z njimi praviloma uporabljajo za to namenjene sisteme, ki jih imenujemo sistem za upravljanje s strankami (v nadaljevanju CRM). Prav tako se komuniciranje s strankami vse bolj izvaja preko sodobnih komunikacijskih kanalov, kot so SMS, e-mail, Facebook in drugi.

V tem diplomskem delu predstavljam, kako lahko v podjetju izboljšamo komunikacijo s strankami z uporabo SMS aplikacije, ki jo umestimo v obstoječ sistem CRM. Z umestitvijo aplikacije v obstoječ sistem CRM so namreč mogoči veliki prihranki na času zaposlenih, v večini primerov pa je lahko sporočilo SMS tudi bolj prijazno do uporabnika kot je na primer klic.

V prvem delu diplomske naloge nazorno opisujem tehnologije in arhitekturo, ki smo jih uporabili pri izdelavi naše aplikacije, v drugem delu pa načrtovanje ter postopek njene izdelave.

Aplikacijo smo, kot že rečeno, umestili v obstoječ sistem, zato predstavljam tudi določene dele obstoječega sistema, ki se navezujejo nanjo. Opišem tudi delovanje aplikacije, v prilogi pa dodajam navodila za njeno uporabo. V sklepnem delu predstavim rezultate oziroma uporabo aplikacije po določenem časovnem obdobju ter prikažem njen prihranek.

Ključne besede: Aplikacija, razvoj aplikacije, HTML, SQL, JavaScript, Bootstrap, CRM, SMS,…

iii

Abstract

At a time when the use and development of information technology is in full swing, all major companies have also recognized the long-term benefits of investing in information technology. Companies that have a larger customer base typically use dedicated systems called Costumer Relationship Management's (in further CRM) to manage them. Also communication with customers is increasingly carried out through modern communication channels such as SMS, e-mail, Facebook,…

In this thesis, I present how we can improve communication with customers in the company by using an SMS application that we place in the existing CRM system. By installing the application in the existing CRM system, large savings on employee time are possible, and in most cases, just an SMS message can also be more user-friendly than for example a call.

In the first part of the degree thesis I clearly describe which technologies and arhitecture we used in programming our application, and in the second part the planning and process of creating the application. As already mentioned, we have installed the application in the existing system, so I also introduce you to certain parts of the existing system that relate to our application. I am also describing the operation of the application, and attach instructions for its use in the attachment. In the concluding part, I present the results or use of the application after a certain period of time and show the barriers by using the application.

Key words: Application, Application Development, HTML, SQL, JavaScript, Bootstrap, CRM, SMS,…

Vsebina

1 Uvod…... ………1

2 Sistem CRM ... 4

2.1 Opis obstoječega sistema CRM ... 5

2.2 Arhitektura sistema CRM ... 9

3 Uporabljene tehnologije ... 14

3.1 Hyper Text Markup Language (HTML) ... 14

3.2 Cascading Style Sheet (CSS) ... 15

3.3 Javascript ... 15

3.4 Bootstrap ... 16

3.5 Active Server Pages (ASP.net) ... 16

3.6 Structured Query Language (SQL) ... 17

4 Proces uvajanja nove aplikacije... 19

4.1 Poslovni proces ... 19

4.1.1 Zahteva za razvoj aplikacije ... 19

4.1.2 Načrtovanje aplikacije ... 19

4.1.3 Razvoj aplikacije ... 20

4.1.4 Test aplikacije ... 21

4.1.5 Prenos kode na produkcijo ... 21

4.2 Delovanje aplikacije in umestitev v obstoječ sistem CRM ... 22

4.2.1 Upravljanje uporabnikov sistema CRM ... 22

v

4.2.2 Umestitev aplikacije v obstoječ sistem ... 23

4.2.3 Podatki o stranki ... 23

4.2.4 Vnaprej nastavljena besedila ... 25

4.2.5 Preverjanje pravilnosti vpisanih podatkov ... 26

4.2.6 Zapis v zgodovino stranke ... 28

4.2.7 Postopek pošiljanja sporočila SMS ... 29

4.3 Navodila uporabnikom ... 31

5 Rezultati ... 33

5.1 Število poslanih sporočil SMS ... 33

5.2 Primerjava števila poslanih sporočil SMS po četrtletjih ... 33

5.3 Prihranek na času in denarju ... 34

5.4 Število napak ... 35

5.5 Zadovoljstvo uporabnikov ... 35

6 Zaključek ... 37

Literatura ... 38

Seznam slik

Slika 1: Izgled aplikacije za pošiljanje sporočil iz obstoječega sistema CRM ... 2

Slika 2: Komunikacija s strankami iz sistema CRM... 5

Slika 3: Obstoječ sistem CRM ... 7

Slika 4: Dostopi v obstoječemu sistemu CRM ... 8

Slika 5: Arhitektura sistema CRM ... 10

Slika 6: SQL komponente ... 17

Slika 7: Ukaz za kreacijo tabele STUDENTI ... 18

Slika 8: Poizvedba za prikaz podatkov iz tabele STUDENTI ... 18

Slika 9: Izpis poizvedbe iz baze ... 23

Slika 10: Strankini podatki v aplikaciji, ko je v sistemu CRM odprta mobilna stranka24 Slika 11: Vnaprej nastavljena besedila ... 25

Slika 12: Ukaz za kreacijo tabele »SMS_TEMPLATE« ... 26

Slika 13: Ukaz za vpis podatkov v tabelo »SMS_TEMPLATE« ... 26

Slika 14: Poizvedba za prikaz podatkov iz tabele »SMS_TEMPLATE« ... 26

Slika 15: Opozorilo, da številka ni prave dolžine oziroma se ne začne s 386 ... 27

Slika 16: Opozorilo da številka ni v pravem formatu ... 27

Slika 17: Opozorilo »prazen tekst« ... 27

Slika 18: Opozorilo, da manjka podatek oziroma ni pravilen ... 28

Slika 19: Obvestilo da je bilo sporočilo SMS uspešno poslano stranki, ter narejen zapis v zgodovino stranke ... 28

Slika 20: Izgled zapisa v zgodovini stranke v sistemu CRM ... 29

Slika 21: Ukaz za vpis podatkov v tabelo »SMS_LIST«... 30

vii Slika 22: Ukaz s katerim naredimo avtomatsko opravilo ... 30

Slika 23: Zajem slike zaslona prejetega sporočila SMS na mobilnem aparatu ... 31

Seznam grafov

Graf 1: Število poslanih sporočil SMS po četrtletjih ... 34

1 Uvod

CRM je razširjena angleška kratica za Customer Relationship Management, kar v slovenskem prevodu pomeni upravljanje odnosov s strankami (v nadaljevanju CRM). Kot nam pove že ime je to sistem oziroma strategija v podjetju, ki nam olajša odnos ter delo s strankami.

Za lažjo predstavo si lahko najenostavnejši primer CRM-ja predstavimo z zvezkom ali razpredelnico s strankami. V sodobnem času in v večjih podjetjih, pa so primeri CRM-jev seveda kompleksnejši računalniški programi, ki so namenjeni izključno delu s strankami.

Začetki sistemov CRM, oziroma njihovih predhodnih konceptov, segajo v začetek šestdesetih let 20. stoletja, ko so podjetja zadovoljstvo strank ocenjevala na podlagi uporabe letnih raziskav in sprotnega povpraševanja strank. Cilji so bili sicer podobni kot danes - to je iskanje novih strank ter optimizacija obstoječih. Pomembno je da vemo katerim strankam je smiselno ponuditi kateri produkt. Če strankam ponudimo prave produkte to vodi v njihovo večje zadovoljstvo, hkrati pa lahko ustvarimo tudi višje prihodke in dobiček. Ker pa v preteklih časih ni bilo na voljo primerne informacijske tehnologije, kakršna je na voljo danes, takšni sistemi niso bili tako razširjeni, saj je bila njihova uspešnost glede na vložena finančna sredstva relativno nizka.

Z razvojem tehnologije, kot so informacijski sistemi, podatkovne baze in interneta, se je močno povečala tudi uporaba sistemov CRM. Navedena tehnologija namreč omogoča lažje zbiranje, shranjevanje ter analizo podatkov. To v praksi pomeni lažjo prepoznavo navad strank, posledično pa lahko povečamo njihovo zadovoljstvo in seveda tudi dobičkonosnost, kar je cilj vsakega podjetja. Tehnologija omogoča tudi lažjo komunikacijo s strankami. Danes tako lahko s strankami komuniciramo tudi preko sporočil SMS, elektronske pošte in socialnih omrežij. V diplomskem delu se bomo podrobneje posvetili komunikaciji s strankami, konkretnejše preko kratkih sporočil SMS, ki se v našem primeru pošiljajo preko aplikacije, vgrajene v obstoječ sistem CRM. Bistvo uspešnega sistema CRM je namreč učinkovita komunikacija s strankami, tako obstoječimi, kot potencialnimi novimi. Prvi sistem kratkih sporočil, večini bolj poznan pod kratico SMS (angl. Short Message Service) je bil sicer standardiziran leta 1985 kot del serije protokolov GSM (angl. Global System for Mobile Communications). Prvo sporočilo SMS, pa je bilo uspešno poslano leta 1992. Protokol dopušča pošiljanje do 160 znakov na/iz aparata

GSM. Če je sporočilo daljše, mobilni operaterji razdelijo to sporočilo na več delov oziroma sporočil. Pošiljanje sporočil SMS pa je možno tudi preko računalnika povezanega na Internet.

Pošiljanje poteka s pomočjo protokola HTTP (angl. Hypertext Transfer Protocol), ki posreduje sporočilo na SMS center ponudnika storitev. Ta način pošiljanja pa si bomo tudi podrobneje pogledali v nadaljevanju naloge, v kateri bomo opisali podroben postopek pošiljanja sporočil kar iz aplikacije v obstoječem sistemu CRM. Izgled aplikacije pa je prikazan na sliki 1.

Slika 1: Izgled aplikacije za pošiljanje sporočil iz obstoječega sistema CRM [(vir slike: lastni)]

Razlog za izvedbo aplikacije za pošiljanje sporočil SMS v sistem CRM je predvsem v tem, da je pri tem načinu komunikacije v našem primeru še ogromno neizkoriščenega potenciala.

Določeni zaposleni v podjetju so sicer že uporabljali samostojno aplikacijo za pošiljanje sporočil SMS, je bilo pa to precej zamudno, dostopa do aplikacije pa niti niso imeli vsi. Z uporabo aplikacije, ki smo jo umestili v obstoječ sistem CRM, so tako zaposleni prihranili ogromno časa, določeni uporabniki pa sploh pridobili možnost te komunikacije, ki je precej prijaznejša do strank, v večini primerov pa je tudi hitrejša. Z analizo smo tudi potrdili, da je razvoj aplikacije na dolgi rok bolj smiseln, saj je čas za njen razvoj, v primerjavi s prihrankom časa na letni ravni, zanemarljiv. Točne čase in rezultate predstavim v poglavju »rezultati«.

Prihranki na času so precejšnji, saj aplikacija omogoča tudi druge funkcionalnosti, kot je na primer avtomatski zapis v zgodovino stranke, ki se je pred tem izvajal ročno. V večini primerov prav tako ni potrebno prepisovanje mobilne telefonske številke stranke, ki se prenese iz sistema CRM avtomatsko, kar poleg malenkostne pridobitve na času zmanjša tudi število možnih

3 napak. V aplikaciji so v spustnem meniju na izbiro tudi vnaprej nastavljena besedila, saj se nekatere vsebine, ki se jih pošilja strankam ponavljajo. Nezanemarljivo pa je vsekakor tudi zadovoljstvo strank, saj jih v nekaterih primerih ne motimo brez potrebe, prav tako pa imajo vsebino sporočila lahko shranjeno dlje časa, kar je še posebej koristno v primeru podajanja standardnih navodil. Prednost integracije aplikacije v obstoječ sistem je tudi v tem, da imajo uporabniki CRM aplikacije (zaposleni v podjetju, v nadaljevanju samo uporabniki), dostope do sistema CRM že omogočene, dodeli pa sej jim samo še dodatna funkcionalnost, ni pa potrebno dodajanje novih uporabniških imen ter kasneje njihovo upravljanje.

V diplomskem delu predstavimo potek načrtovanja in uvedbe aplikacije, katere tehnologije oziroma protokole smo uporabili pri razvoju ter na kakšen način izvedemo testiranje in prenos v produkcijo. Naloga vsebuje tudi opis delovanja aplikacije, v prilogi pa so podana še uporabniška navodila.

2 Sistem CRM

Namen sistema CRM je v lažji komunikaciji s strankami ter analizi navad strank, s tem pa seveda lahko povečamo dobičkonosnost podjetja, ter zadovoljstvo strank. Za podjetja, ki so pretežno osredotočena na delo s strankami, je dober sistem CRM bistvenega pomena za uspešnost podjetja. Za sistem je tudi zelo pomembno, da je sodoben in da omogoča enostavno nadgradnjo, ki se hitro prilagaja potrebam trga [1]. V sistemu imamo shranjene podatke o naših trenutnih in preteklih strankah, lahko pa tudi stike potencialnih novih strank. Glede na zbrane podatke strankam lahko ponudimo prilagojeno ponudbo, ki je odvisna od njihovih potreb. S sistemom CRM lahko strankam tudi spreminjamo podatke, vklapljamo razne storitve ali pa na primer vodimo reklamacije [1]. Vsi ti podatki so shranjeni v podatkovni bazi sistema na enem mestu, do katerega imajo hkraten dostop omogočen vsi uporabniki sistema CRM ki delajo s strankami. To je pomembno, saj se lahko z isto stranko hkrati ukvarja več različnih zaposlenih, sistem CRM pa omogoča aktualen pregled vsega dogajanja s stranko, saj se podatki v sistemu shranjujejo oziroma osvežujejo sproti, torej so na voljo v realnem času [2]. Kot prikazuje slika 2, komunikacija s strankami v sistemu CRM lahko poteka preko več različnih kanalov. V preteklosti je večinoma potekala preko navadne pošte ter tiskanega materiala, nato pa se je z razvojem tehnologije sprva prestavila na telefonske linije, kasneje pa tudi na spletne strani, elektronsko pošto in sporočila SMS. V zadnjem času pa se vse bolj seli tudi na socialna omrežja.

Pri tem pa ključno vlogo odigrajo sistemi CRM s pomočjo katerih s strankami navežemo komunikacijo preko ustreznega kanala [2].

Ena izmed možnih komunikacij s strankami, je komunikacija preko kratkih tekstovnih sporočil SMS (v nadaljevanju SMS). Na to komunikacijo, oziroma konkretneje na SMS aplikacijo, ki je del obširnejšega sistema CRM se bomo tudi osredotočili v nadaljevanju te naloge. Diplomska naloga namreč opisuje postopek uvedbe SMS aplikacije v obstoječ sistem CRM. Do sedaj je bila v našem obstoječemu sistemu CRM možna komunikacija s strankami preko klica ali elektronske pošte, sedaj pa smo izvedli še komunikacijo preko sporočil SMS, saj funkcionalnost omogoča prihranek na času ter tudi zadovoljstvu uporabnikov [1]. Do uvedbe SMS aplikacije v sistem CRM so nekateri uporabniki za pošiljanje sporočil SMS sicer že uporabljali drugo samostojno aplikacijo, ki je bila namenjena izključno pošiljanju sporočil SMS strankam, a zaradi specifičnosti aplikacije dostopa do nje niso imeli vsi uporabniki sistema

5 CRM. Prav tako je bilo še nekaj drugih manjših pomanjkljivosti. Uporabniki so morali strankino telefonsko številko (v nadaljevanju MSISDN) prepisovati oziroma kopirati iz sistema CRM v to staro aplikacijo, v novi aplikaciji, ki je del sistema CRM pa se le - ta prenese avtomatsko. Tudi pregled komunikacije s stranko v sistemu CRM je urejen avtomatsko.

Predtem je bilo potrebno pošiljanje sporočila SMS ročno zabeležiti tudi v zgodovino stranke v sistemu CRM, postopek pa je seveda zahteval nekaj več časa [2].

Slika 2: Komunikacija s strankami iz sistema CRM [(vir slike: lastni)]

Nova aplikacija izvedena v sistemu CRM je to poenostavila, saj se zapis v zgodovino naredi avtomatsko ob pošiljanju sporočila SMS. Odveč ni niti podatek, da se vsebina večine sporočil SMS ponavlja. Tako so imeli uporabniki ponavljajoče vsebine prej shranjene kar v Excelovem dokumentu, od koder so jih prepisovali oziroma kopirali v aplikacijo za pošiljanje, v novi aplikaciji pa jih enostavno izberejo v spustnem meniju. Vse skupaj torej pomeni poenostavljeno in hitrejše delo, ter tudi minimizirano število človeških napak [2].

2.1 Opis obstoječega sistema CRM

Kot smo že omenili je SMS aplikacija del že obstoječega sistema CRM, ki ga uporabljajo zaposleni v podjetju na različnih delovnih mestih. Uporabniki pa imajo v aplikaciji različne tipe profilov/dostopov, ki se razlikujejo glede na oddelek oziroma delovno mesto, od tipa profila pa

je nato tudi odvisno delovanje sistema CRM. Osnovna stran obstoječega sistema CRM, ki je podobna pri vseh tipih profilov je sestavljena iz več oken, kot prikazuje slika 3.

Na levi strani je okno z iskalnikom strank, kjer se tudi izpišejo osnovni podatki o stranki, določeni podatki pa se nato tudi avtomatsko prenesejo v SMS aplikacijo. Iskalnik strank imajo sicer vsi uporabniki, se pa razlikuje način iskanja. Slika 4 prikazuje dostope v sistemu CRM.

Uporabnikom z več pravicami je dovoljeno iskanje strank z več različnimi vhodnimi podatki (telefonska številka, davčna, ime in priimek), tistim z manj pravicami pa samo po davčni številki stranke. Posebnost dostopa agentov v klicnem centru pa je tudi ta, da ob sprejemu klica stranko odpre samodejno. Spodaj na sredini se nahaja zgodovina strank, kjer se beležijo vse aktivnosti strank v sistemu CRM. Tu se tudi beleži pošiljanje sporočil SMS strankam.

Zgodovino stranke vidi večina uporabnikov enako. Prikaz zgodovine je odvisen od tega, kako je definirana vrsta zapisa v zgodovini, je pa pri večini zapisov definirano na način, da jih vidijo vsi. Lahko pa se pri določenih zapisih tudi definira, da niso vidni vsem uporabnikom oziroma profilom.

V zgornjem delu pa imajo uporabniki menijsko vrstico. Glede na tip profila je odvisno, kaj vse se nahaja uporabniku v meniju. Tako je tudi z dostopom do nove aplikacije za pošiljanje sporočil SMS. Dostop do menija za pošiljanje sporočil SMS, ki ga najdemo pod imenom

»Pošiljanje SMSa« je namreč omogočen samo uporabnikom v klicnem centru ter na prodajnih mestih, ostali pa SMS aplikacije sploh nimajo v meniju.

7 Slika 3: Obstoječ sistem CRM [(vir slike: lastni)]

Slika 4: Dostopi v obstoječemu sistemu CRM [(vir slike: lastni)]

V obstoječem sistemu CRM pa je več različnih profilov, kateri imajo tudi različne dostope.

Profili so sledeči:

 Upravljavski profil ima največ pravic in njegova posebnost je, da ima dostop do aplikacije, preko katere lahko upravlja s pravicami ostalih uporabnikov. Tako lahko dodajamo nove uporabnike, jim dodeljujemo ali spreminjamo dostope, ponastavimo pozabljeno geslo ter po potrebi onemogočimo uporabnika. Upravitelj ima zaradi potreb dela tudi dostop do večine funkcionalnosti in menijev.

 Agenti na prodajnih mestih imajo dostop do forme za aktivacijo novih naročniških razmerij, ponovnih vezav, nakupa novega aparata z vezavo, ter sprememb na obstoječih razmerjih.

Med spremembami imajo možnost spremembe tipa računa, menjavo paketa, prenos lastništva, vklop raznih opcij in ostalih sprememb, katere pa imajo uporabniki možnost spreminjati tudi preko portala. Na prodajnih mestih imajo tudi osnoven vpogled v splošne podatke o uporabniku kot so na primer prikaz klicev, analizo porabe in podatke o vezavi.

Agentje pa imajo tudi pregled oziroma statistike vseh svojih sprememb/prodanih storitev.

9

 V klicnem centru imajo vgrajeno avtomatsko odpiranje strank v sistemu CRM ob sprejemu klica. Prav tako imajo dostop do osnovnih podatkov o stranki (podobni kot prodajna mesta), opravljajo pa lahko tudi določene spremembe, za katere ni potreben podpis stranke.

 Oddelek za telefonsko prodajo je namenjen prodaji strank preko telefona. Oddelek ima podobno kot prodajna mesta možnost aktivacije novih pogodb ter ponovnih vezav (aneksov). Bistvena razlika pa je ta, da stranka pogodbo prejme na mail, podpis pogodbe pa nato opravi preko tablice dostavne službe, ki stranki dostavi pogodbo. V nekaterih primerih, kjer ni potrebna dostava opreme, pa stranke lahko potrdijo storitev tudi preko certifikata.

Pogodba se po podpisu na tablici avtomatsko aktivira.

 Naročniška služba, ki je tudi nekakšna podpora prodajnim mestom ter klicnemu centru, ima vse dostope kot oni ter dodatne možnosti reševanja reklamacij. Oddelek naročniške službe, ki skrbi za poslovne stranke ima tudi možnost za delo z večjimi strankami, ki sprememb ne morejo opravljati na prodajnih mestih, ampak samo preko svojih skrbnikov.

 Oddelek za preprečevanje zlorab se ukvarja z zlorabami oziroma preprečevanju le - teh. Ta oddelek tudi odobri nove aktivacije za potencialno tvegane stranke. Gre se predvsem za stranke, ki so bile v preteklosti že dolžniki, nova podjetja ustanovljena v zadnjih mesecih, ali pa stranke, ki v kratkem času sklenejo večje število pogodb.

 Marketing oddelek ima poleg osnovnega pregleda strank možnost kreacije novih promocij in ponudb, ki se nato aktivirajo pri strankah. To omogoča aplikacija, ki je del sistema CRM.

Preko te aplikacije lahko marketing sam naredi nove ponudbe in promocije za stranke brez pomoči IT oddelka, uspešnost ponudbe pa nato lahko spremlja v statistiki posameznih ponudb.

2.2 Arhitektura sistema CRM

Učinkovitost delovanja sistema CRM je v veliki meri odvisna tudi od zalednih sistemov.

Slika 5 prikazuje arhitekturo obstoječega sistema CRM s povezavami na vse zaledne sisteme.

Na njej pa je tudi že vidna na novo dodana povezava na SMS center, ki skrbi za pošiljanje sporočil SMS.

Slika 5: Arhitektura sistema CRM [(vir slike: lastni)]

11 Osnova vsakega sistema CRM sta sicer aplikacijski strežnik ter podatkovna baza. Za strežnik je v tem primeru uporabljen navidezen strežnik saj ima kar nekaj prednosti pred klasičnimi fizičnimi strežniki. Omogoča namreč, da na enem samem fizičnem strežniku poganjamo več navideznih enot hkrati, ki pa so medsebojno neodvisne, posledično je vir precej bolje izkoriščen [3, stran 3]. Velika prednost navideznih strežnikov, je tudi v primeru napak oziroma naravnih katastrof, saj se lahko naredi preklop na sekundarno lokacijo v teh primerih kar avtomatsko [3, stran 3-5]. Naš navidezni strežnik je sicer postavljen na operacijskem sistemu Windows 2008. Za shranjevanje strankinih podatkov pa sistem CRM potrebuje podatkovno bazo. Podatkovna baza je zbirka medsebojno logično povezanih podatkov shranjenih na računalniškem sistemu. Prednost podatkovnih baz je v nadzorovani redundanci podatkov (kar pomeni lažje vzdrževanje in večja varnost podatkov), omogočajo pa tudi skupno rabo podatkov neomejenemu številu uporabnikov. Slabša stran takšnega sistema pa je precej visok začeten strošek investicije v sistem, ter potreben čas za učenje in privajanje nanj [4]. Za upravljanje s podatkovnimi bazami potrebujemo namreč podatkovni sistem (v našem primeru Oracle), ki s pomočjo sistema za upravljanje podatkovne baze (SUPB oz. angl. DBMS - Database Management System) omogoča uporabo in upravljanje s podatki, ki so shranjeni v njih [5]. Dostop do podatkov v bazi se izvaja preko SQL poizvedb (vpis, brisanje, spreminjanje), ki so podrobneje opisane v poglavju nižje [6, stran 89]. Sistem CRM pa je povezan na vrsto drugih zalednih sistemov s katerimi deluje v soodvisnosti.

Eden najpomembnejših zalednih sistemov je sistem za zaračunavanje (angl. Billing). V sistemu za zaračunavanje so shranjeni vsi podatki o strankah ter njenih storitvah saj sistem skrbi za zaračunavanje storitev ter izdajo računov. Zahteve za spremembe podatkov oziroma storitev se iz sistema CRM pošiljajo v sistem za zaračunavanje v obliki XML ukazov (angl. Extensible Markup Language oziroma razširljiv označevalni jezik). Sistem CRM ima tudi direkten dostop do podatkovne baze za zaračunavanje, saj sta podatkovni bazi povezani preko Oracle podatkovnega linka, kar omogoča prikaz podatkov iz baze sistema za zaračunavanje tudi v sistemu CRM. Sistem CRM je povezan tudi na sistem TIBCO (angl. The Information Bus Company), ki deluje kot nekakšen usmerjevalnik oziroma povezava do drugih sistemov. Tibco namreč posreduje XML ukaze naprej na ustrezne zaledne sisteme. Tibco je povezan še na portal, kjer si lahko uporabniki, ki so registrirani v sistemu SSO (angl. Single Sign-on), na spletni strani oziroma portalu sami vklapljajo ali izklapljajo storitve. Tibco je usmerjevalnik

tudi proti sistemu, ki omogoča prenos mobilnih podatkov PCRF (angl. Policy and Charging Rules Function). Povezan je tudi na sistem za predplačnike (angl. Prepaid System), ki je potreben za delovanje ter zaračunavanje predplačniških uporabnikov, sistem HLR (angl. Home Location Register), ki skrbi za delovanje mobilne telefonije, klicanje, ter zaledne fiksne sisteme (linijski internet, TV ter fiksna telefonija). Za brezpapirno poslovanje pa so pomembni sistem ePodpis, ki kot že pove ime poskrbi za elektronski podpis stranke na tablici, sistem Streamserve pa poskrbi da se le - ta podpisan dokument shrani v dokumentnem sistemu DMS (angl.

Document Managment System - sistem za upravljanje z dokumenti). Sistem CRM ima nato tudi dostop do teh dokumentov in jih prikazuje v sistemu. Poleg pogodb pa so v dokumentnem sistemu shranjeni tudi vsi izdani računi. Materiale ter količino, ki so na voljo za prodajo sistem CRM dobi iz sistema SAP (angl. Systems Applications and Products). V našem primeru gre večinoma za SIM kartice ter mobilne aparate.

FMS (Fraud Managment System) je sistem za boj proti goljufijam, v katerem se shranjujejo ter preverjajo vsi podatki za preprečevanje zlorab. V realnem času se lovijo klici, ki strankam povzročajo ogromne stroške in le - te preprečujejo. Strankam pa v primeru visokih stroškov pošiljajo opozorila ali pa jim z blokadami še višje stroške tudi preprečijo. Preko sistema CRM se izvaja tudi prenos mobilnih ter stacionarnih številk med operaterji (NP – angl. Number Portabilty). V sistemu CRM se prožijo zahteve za prenos številk, ki jih sistem NP pošlje centralni bazi podatkov (CBP), ki beleži vse transakcije med postopkom prenosa številk in vsebuje podatke potrebne za usmerjanje klicev na prenesene številke [7]. Sistem NP tudi tehnično izvede prenos številke v sistemu za zaračunavanje, ter poskrbi za aktivacije številke v ostalih zalednih sistemih, ki so potrebni za delovanje številke (klici, sporočila SMS, prenos podatkov). Sistem CRM je na novo povezan tudi z SMS centrom (angl. Short Message Service Center). Sporočila SMS so tehnologija, ki omogoča izmenjavo kratkih sporočil med dvema uporabnikoma mobilnih naprav, omogoča pa tudi enosmerno komunikacijo oz. dvosmerno komunikacijo med SMS storitvami in mobilnim uporabnikom [8, stran 2-3]. Komunikacija med napravami oziroma dostavo sporočil SMS omogoča mrežni element SMSC (angl. Short Message Service Center), ki je odgovoren za sprejemanje, shranjevanje in posredovanje sporočil. Ko uporabnik pošlje sporočilo SMS, SMSC sporočilo shrani ter posreduje prejemniku.

Sporočilo se izbriše, ko ga prejemnik prejme. Ker pa je le – to časovno omejeno, se po pretečenem času avtomatsko izbriše, četudi prejemnik ni sporočila prejel [9, stran 8]. Za komunikacijo med SMS storitvami in uporabniki mobilnih naprav potrebujemo tudi prehod

13 med ponudniki storitvami in operaterji, ki ga imenujemo MGW (Message Gateway). Kot omenjeno obstajajo enosmerna komunikacija ter dvosmerna komunikacija. Pri enosmerni komunikaciji gre za pošiljanje sporočil SMS s strani ponudnikov raznih storitev mobilnim uporabnikom. Ponudnik storitev posreduje na sistem MGW podatke o vsebini sporočila in prejemnikih preko interneta (s HTTP zahtevo). HTTP oz. Hypertext Transfer Protocol je protokol aplikacijskega sloja za prenos spletnih dokumentov na osnovi katerega delujejo vse spletne aplikacije in je poizvedba/odgovor (angl. request/response) protokol. Primeri enosmerne komunikacije so na primer obveščanje o transakcijah na bančnem računu, ali pa razna masovna promocijska sporočila. Dvosmerna komunikacija pa je pri storitvah, kjer uporabnik zahteva storitev sam s pošiljanjem ključne besede na pravo številko, na poslano sporočilo pa pričakuje odgovor s strani ponudnika storitev, ki je v lahko tudi plačljiv.

3 Uporabljene tehnologije

V tej poglavju predstavimo tehnologije, ki smo jih uporabili za izdelavo naše aplikacije.

Uporabili smo HTML, ki je osnova vseh spletnih aplikacij, za oblikovanje smo uporabili CSS, in Bootstrap, ter na koncu tudi Javascript, ki je potreben za izvajanje funkcij v spletni aplikaciji.

Za izdelavo podatkovnega modela pa smo uporabili SQL poizvedbeni jezik.

3.1 Hyper Text Markup Language (HTML)

Kratica HTML izhaja iz angleških besed Hyper Text Markup Language, kar v slovenskem prevodu pomeni jezik za označevanje nadbesedila. S programskima jezikoma Javascript ter CSS, katera si bomo ogledali v naslednjih poglavjih, predstavljajo temeljno tehnologijo za svetovni splet WWW (angl. World Wide Web) [10]. HTML je označevalni jezik za izdelavo spletnih strani in spletnih aplikacij. Je zelo preprost za uporabo, ter posledično tudi zelo razširjen med uporabniki, saj s preprostimi ukazi prikažemo želeno vsebino na spletu [11]. S preprostimi oznakami HTML brskalniku namreč povemo, kako naj uredi, razporedi ali označi besedilo, določimo velikost, barvo in slog pisave ter dodajamo naslove. Prav tako lahko s HTML oznakami v brskalniku prikažemo slike, tabele, povezave do drugih spletnih strani, animacije, zvoke, video in druge vsebine kot so na primer interaktivni obrazci ter to prikažemo na spletni strani [12, stran IV]. Elementi HTML so označeni z oznakami, ki so napisane s kotnimi oklepaji (npr. <p>), brskalniki pa si z njimi razlagajo vsebino strani ter jo na podlagi teh podatkov prikažejo. HTML lahko vsebuje tudi programe, napisane v skriptnem jeziku, kot je JavaScript, kar vpliva na obnašanje in vsebino spletnih strani. Vključitev CSS določa videz in postavitev vsebine. HTML kodo po navadi pišemo v vsakem urejevalniku besedil, na primer beležnici, ker pa ta ne omogoča nobenega oblikovanja, navadno uporabimo katerega od zmogljivejših orodij, ki npr. barvajo izvorno kodo oziroma nam s predlogi tudi pomagajo pri pisanju kode (Notepad++, Adobe Dreamweaver, UltraEdit,…). Datoteko na koncu ustrezno poimenujemo ter shranimo s končnico .html. HTML dokumente nato spletni brskalniki berejo iz spletnega strežnika ali lokalnega pomnilnika in prikažejo na spletnih straneh [11].

15

3.2 Cascading Style Sheet (CSS)

CSS je bil razvit oziroma specifiran s strani organizacije W3C, prvič pa je bil predstavljen leta 1994. Pojavil se je zaradi potrebe po stiliranju dokumentov. Kratica CSS izhaja iz angleške besedne zveze Cascading Style Sheet [13]. V prevodu to pomeni kaskadne stilske podloge oz.

krajše kaskadni slogi. Je skriptni jezik, namenjen oblikovanju spletnih strani. Z njimi namreč definiramo stil html elementov, torej določimo kako naj brskalnik te elemente prikaže na spletni strani. S CSS določamo barve, velikosti, odmike in poravnave besedila, ozadja, menije tabele, obrobe in vrsto drugih atributov [12, stran 84]. Glavna prednost CSS-a je namreč ta, da se z njim izognemo okornemu oblikovanju besedil. Če smo tako, na primer želeli spremeniti barvo besedila na spletni strani brez uporabe CSS-a, smo morali popravljati HTML kodo na vseh mestih, kjer se je nahajal tekst. Z uporabo CSS-a pa videz oziroma slog besedila nastavimo samo enkrat. Po navadi imamo ta slog shranjen v samostojni datoteki. Če želimo spremeniti slog ali barvo pisave na celotni spletni strani, ni potrebno popravljanje kode na več mestih, ampak le - to popravimo samo enkrat. S tem tudi zmanjšamo ponavljanje kode, kar pomeni, da je kode manj in je bolj pregledna [12, stran 84].

3.3 Javascript

Javascript je skriptni jezik, ki omogoča izboljšanje in posodobitev oblike, izdelovanje piškotkov in še veliko več. Javascript je zelo uporaben, kar dokazuje tudi dejstvo, da je v spletu na milijone strani, ki vsebujejo JavaScript. To nam pove, da je najpopularnejši skriptni jezik, podpirajo pa ga večinoma vsi glavni brskalniki, kot so Internet Explorer, Firefox, Opera, Chrome,.. [12, stran 168]. JavaScript je sicer med oblikovalci spletnih strani, ki običajno niso dobri programerji, zelo priljubljen zaradi svoje preprostosti. Vsebuje nezapletene oznake in funkcije, ki se jih lahko nauči prav vsak. JavaScript lahko pišemo znotraj oznak <body> ali pa znotraj oznak <head>. Uporaben je predvsem za razna pojavna, opozorilna, potrditvena in vnosna okna. Uporablja se tudi za razne enostavnejše funkcije (računske operacije), stavke IF (na podoben način kot v jeziku C++ oz. PHP), funkcije loop in druge funkcije kot je na primer informacija o brskalniku. V Javascriptu lahko naredimo tudi animacijo gumba, ki spreminja svojo barvo v kolikor nanjo kliknemo, oziroma v primeru klika na gumb sprožimo določeno

funkcijo. Za uporabo jezika JavaScript je seveda predpogoj znanje uporabe jezika HTML [12, stran 168].

3.4 Bootstrap

Bootstrap je orodje za oblikovanje spletnih strani in aplikacij, ki temeljijo na tehnologijah HTML, CSS in Javascript. Orodje je odprtokodno in brezplačno. Prvotno je bil razvit s strani Twitter-ja, sedaj pa spada pod okvir GitHub-a. Javnosti je bil predstavljen leta 2011 in med programerji takoj postal zelo popularen saj je zelo fleksibilen ter enostaven za uporabo. Od prvotne izdaje do danes je bilo izdanih že več verzij Bootstrap-a, zadnja verzija je Bootstrap 4, ki je bila izdana leta 2018. V Bootstrap 2 je bila predstavljena 12 stolpcev velika odzivna mrežna postavitev ter nekaj drugih komponent, v Bootstrap 3 pa so bile narejene izboljšave za prikaz na mobilnih napravah [14]. Bootstrap je enostaven za uporabo in se ga je enostavno tudi naučiti. Združljiv je z večino glavnih internetnih brskalnikov. Ena njegovih prednosti je tudi ta, da je oblikovalsko odziven, kar pomeni, da se velikost spletne strani prilagodi vaši napravi (tablici, ekranu, mobilnemu aparatu). Bootstrap ponuja tudi številne možnosti konfiguracij spremenljivk, ki nadzorujejo stvari, kot so barva in oblika različnih komponent. Tako se lahko razvijalci osredotočijo predvsem na razvojen del kode, in jim ni potrebno skrbeti za oblikovanje strani. Na ta način lahko hitro izdelamo lepo in delujočo spletno stran [14]. Bootstrap je na voljo v dveh formah. Programerji imajo na voljo pred definirano verzijo 12 stolpčne mrežne postavitve sistema z odzivno zasnovo z velikostjo 1170 pikslov, ali pa uporabijo postavitev s spremenljivo širino. V obeh primerih ima orodje štiri različice za uporabo različnih resolucij in vrst naprav: mobilnih telefonov, portretov in pokrajin, tabličnih računalnikov in osebnih računalnikov. Vsaka sprememba prilagodi širino stolpcev [15].

3.5 Active Server Pages (ASP.net)

ASP.net je Microsoftova tehnologija, ki omogoča izdelovanje dinamičnih spletnih strani [16, stran 13]. Tehnologija ASP.NET je naslednica tehnologije ASP (Active Server Pages).

Tehnologijo ASP je sicer Microsoft razvil zaradi porasta uporabe interneta, in posledično potrebe za selitev aplikacij na internet. Internetne aplikacije imajo namreč veliko prednosti pred navadnimi (lokalnimi) aplikacijami, saj lahko vsi uporabniki sočasno dostopajo do iste aplikacije z vsemi zadnjimi posodobitvami oz. funkcionalnostmi preko spletnega brskalnika [17]. Tehnologija omogoča tudi preverjanje identitete uporabnikov, izvajanje aplikacije pa

17 posledično lahko prilagodimo tudi na podlagi identitete uporabnika. Uporabniki sicer lahko enostavno dostopajo do aktualnih podatkov na podatkovnih bazah oz. jih po potrebi tudi spreminjajo, spremembe pa so takoj vidne vsem. Prednost ASP strani je tudi ta, da so lahko sestavljene iz več različnih programskih jezikov, koda pa se izvede že na spletnem strežniku, preden je poslana uporabniku v brskalnik v obliki kode HTML. ASP.NET se izvaja na aplikativnem strežniku IIS (Internet Information Services) [16, stran 13].

3.6 Structured Query Language (SQL)

Allen G. Taylor [18, stran 168] je v svoji knjigi opisal SQL (Structured Query Language) kot strukturirani poizvedbeni jezik, ki se uporablja za delo s podatkovnimi bazami. Z njim lahko naredimo podatkovne baze, jih spreminjamo, vzdržujemo, ter obdelujemo shranjene podatke. Za upravljanje z njimi pa se uporablja zato namenjene programe. Deli se na štiri podjezike, kot je prikazano na sliki 6.

Slika 6: SQL komponente (vir slike: [19])

Z DDL (angl. Data Definition Language) lahko definiramo ali naredimo podatkovno bazo in njene elemente, jih spreminjamo ter po potrebi tudi odstranimo. Na sliki 7 lahko vidimo, kako izgleda ukaz za kreacijo tabele. Ukaz »CREATE« se uporablja za kreacijo objektov. Z ukazom »CREATE PROCEDURE« lahko naredimo novo proceduro, ali pa z ukazom

»CREATE TABLE« naredimo novo tabelo. Z ukazom »ALTER TABLE« spreminjamo obstoječe parametre tabele, v kolikor pa tabele ne potrebuješ več, pa jo lahko brišemo z ukazom

»DROP« [vir: lastni].

Slika 7: Ukaz za kreacijo tabele STUDENTI [(vir slike: lastni]

DML (angl. Data Manipulation Language) se uporablja za upravljanje s podatki v podatkovni bazi. Podatke z ukazi lahko vpisujemo v podatkovno bazo, spreminjamo, brišemo, ali pa samo beremo. Glavni ukazi so »SELECT«, »UPDATE«, »DELETE« in »INSERT«. Z ukazom »INSERT« zapisujemo nove podatke v tabelo, z ukazom »UPDATE« spreminjamo že obstoječe podatke, z ukazom »DELETE pa le te po potrebi izbrišemo. Ukaz »SELECT« pa se uporablja za prikaz podatkov iz tabele oz. kar več tabel hkrati. Z dodatnimi pogoji lahko tudi omejimo kaj želimo prikazati. Na sliki 8 je prikazana poizvedba za prikaz podatkov iz tabele.

Slika 8: Poizvedba za prikaz podatkov iz tabele STUDENTI [(vir slike: lastni]

DCL (angl. Data Control Language) je namenjen zagotavljanju varnosti na podatkovni bazi. Z ukazom »GRANT« se dodeljujejo pravice uporabnikom oziroma dostopi do posameznih objektov. Z ukazom »REVOKE« se le - te pravice odvzemajo. Tako določenim uporabnikom se lahko dodelijo pravice do vpogleda podatkov v tabelah, nekaterim lahko tudi spremembo oziroma vpis podatkov, ali pa celo spremembo objektov. TCL (angl. Transaction Control Language) je namenjen upravljanju s transakcijami na bazi. Z ukazom »COMMIT«

potrdimo spremembe, ki si jih prej na bazi naredil z DML ukazi, ali pa jih razveljaviš z ukazom

»ROLLBACK« [vir: lastni].

19

4 Proces uvajanja nove aplikacije

V tej razdelku si bomo podrobneje ogledali celoten postopek od oddane zahteve za nov produktu, pa do zadnje točke, ki je uporaba produkcijo. Opisan pa je tudi postopek načrtovanja aplikacije, razvoj ter test aplikacije, in postopek prenosa aplikacije na produkcijo.

4.1 Poslovni proces

4.1.1 Zahteva za razvoj aplikacije

Razvoj novega izdelka se vedno začne z idejo. V našem primeru se je pojavila ideja o razvoju nove aplikacije s katero bi izboljšali trenuten način dela zaradi prihranka na času zaposlenih, posledično tudi denarju in pa zadovoljstvu strank oziroma uporabnikov. Vsaka zahteva za nov produkt potrebuje tudi poslovni načrt. V poslovnem načrtu je potrebno predvideti strošek razvoja ter vzdrževanja novega produkta, ter prihranek z uvedbo tega produkta. V kolikor je strošek višji od dolgoročnega prihranka razvoj produkta namreč ni smiseln. Predvideti je potrebno tudi časovni plan izvedbe projekta, ter morebitna tveganja pri razvoju produkta.

V kolikor poslovni načrt potrdi smotrnost razvoja produkta je potrebno napisati zahtevo za razvoj produkta z vsemi potrebnimi specifikacijami. Delovanje produkta mora biti napisano natančno in jasno z vsemi podrobnostmi. Brez teh podatkov razvijalec težko načrtuje razvoj aplikacije, v primeru napačne interpretacije zahteve pa lahko pride tudi do napačnega delovanja aplikacije oziroma v neskladju z pričakovanji. Na podlagi zahtev se na koncu izvajajo tudi testi produkta.

4.1.2 Načrtovanje aplikacije

Pred pričetkom programiranja je potrebno pripraviti tudi načrt izvedbe produkta. Ta načrt tudi napišemo v dokument s tehnično specifikacijo. Ker bo zaradi načina delovanja naš novi produkt del že v obstoječega sistema CRM je zelo pomembno kako bomo te nove funkcionalnost umestili v obstoječ sistem. Podatke o stranki mora v naši aplikaciji namreč odpreti avtomatsko, torej moramo te podatke pridobiti iz sistema CRM. V sistem CRM pa mora aplikacija v zgodovino stranke zapisati vsebino ter čas poslanega sporočila SMS. Predvideti pa

moramo tudi v katerem meniju v sistemu CRM se bo nahajala aplikacija, ter kateri uporabniki bodo imeli dostop do katerih funkcionalnosti.

Potrebno se je tudi odločiti v katerem programskem jeziku se bo pisala koda. Glede nato, da je CRM narejen kot spletna aplikacija in večinoma napisan v jeziku ASP.net, smo se tudi sami odločili napisati aplikacijo v tem programskem jeziku, za oblikovanje pa uporabili CSS in Bootstrap. Za bazo smo uporabili obstoječo bazo sistema CRM, Oracle podatkovno bazo. Na baznem nivoju predvidimo dve novi tabeli ter eno proceduro. Potrebujemo novo tabelo za shranjevanje predlogov tekstov, saj nam ta način omogoča lažjo administracijo teh tekstov in pa tabelo v katero se bodo vpisovala poslana sporočila SMS teksti ter številka MSISDN. Na bazi pa je potrebna nova procedura, ki naredi HTTP poizvedbo za pošiljanje sporočila SMS.

Navodila za HTTP poizvedbo, ki pošilja sporočilo SMS smo sicer našli na spletni strani A1.si, saj smo za pošiljanje uporabili A1 SMS center.

4.1.3 Razvoj aplikacije

Razvoj aplikacije pomeni izvedbo načrtovane arhitekture aplikacije. Za pisanje kode aplikativnega dela uporabimo program Notepad++, ki omogoča preprosto in hitro pisanje kode v večini programskih jezikov, omogoča pa tudi dodatke, ki nam olajšajo pisanje kode. Za razvoj objektov na podatkovni bazi uporabimo program SQL Detective. SQL Detective je enostaven vmesnik za uporabo Oracle podatkovnih baz. Z njim lahko enostavno naredimo ter spreminjamo objekte na podatkovni bazi in upravljamo s podatki v tabelah.

Kodo najprej napišemo na razvojnem okolju, ki je namenjeno pisanju nove kode. V našem primeru, kjer na sistemu lahko hkrati dela več različnih razvijalcev, ima vsak razvijalec svoje okolje za razvoj. S tem preprečimo, da več programerjev hkrati programira v istem delu programa oz. kode, ter s tem spreminja oziroma briše kodo drug drugemu. Ko je koda pripravljena jo na test prenesemo s pomočjo orodja GIT. Uporaba orodja GIT je enostavna, orodje pa GIT omogoča hkratno delo več razvijalcev na istem delu kode. Omogoča tudi revizijo oziroma pregled vseh sprememb v kodi. GIT je sicer brezplačen sistem, v orodju pa se beležijo vse spremembe v kodi, tako na nivoju aplikacije kot tudi nivoju podatkovnih baz. Tako vidimo kdo je spreminjal določen del kode, kaj je spreminjal ter z katerim razlogom. Ko na testnem okolju prestane teste, GIT uporabimo tudi za prenos kode iz testnega sistema na produkcijo. V kolikor bi bilo na testu v našem delu kode več sprememb, ki niso naše, nam GIT omogoča preprost prenos na produkcijo le naše kode.

21 4.1.4 Test aplikacije

Ko je program napisan do konca, izvedemo vsaj osnovne teste na razvojnem okolju. Če vse deluje po pričakovanjih kodo prestavimo na testno okolje. Testiranje v našem primeru izvaja oddelek za testiranje. Testiranje izvajajo po predpisanih scenarijih, ki se pripravijo na podlagi zahtev za razvoj produkta. Preverja se torej, ali program omogoča vse zahtevane funkcionalnosti, oziroma če te funkcionalnosti delujejo kot je zahtevano, preveriti pa je potrebno tudi morebitno delovanje ob vpisu napačnih podatkov.

V oddelku za testiranje imajo tudi več izkušenj s testiranjem, so bolj natančni, posledično pa opazijo tudi kakšne druge manjše napake, ki smo jih sami mogoče spregledali. Tudi sicer je bolje, da testiranje izvede druga oseba kot je razvijala program, saj razvijalec že podzavestno pozna delovanje aplikacije ter njeno uporabo, posledično pa ne klika ostalih kombinacij, ki jih morebiti drugi uporabniki, ki aplikacije ne poznajo tako dobro. Ko so potrjeni vsi testni scenariji pa je koda pripravljena na prenos na produkcijo.

4.1.5 Prenos kode na produkcijo

Glede nato, da je naša aplikacija del večjega sistema CRM, za podporo sistema pa skrbi več ljudi, jim je pred prenosom na produkcijo potrebno predati potrebna znanja za upravljanje oziroma podporo aplikacije. Predamo jim tehnično specifikacijo produkta, pokažemo delovanje aplikacije z vidika uporabnika ter pokažemo tudi glavne dele kode.

Za prenos na produkcijo si že prej pripravimo plan prenosa, da prenos poteka brez težav, in da se prenese vso potrebno kodo. Pri tem nam je v pomoč GIT, saj imamo vse spremembe zabeležene pod istim zahtevkom. Prenos kode na produkcijske strežnike se praviloma izvaja izven delovnega časa oz. angleško »business hours«, da preprečimo vpliv na uporabnike v primeru kakršnihkoli težav pri prenosu kode. V našem primeru to naredimo v večernih urah, saj ima CRM takrat manj aktivnih uporabnikov kot na primer čez dan. Zaradi uporabe aplikacije na več virtualnih strežnikih, moramo biti obvezno pozorni, da spremembe prenesemo na vse strežnike. Za prenos sprememb na podatkovno bazo, pa se je potrebno o tem predhodno dogovoriti z administratorji podatkovne baze, ter jim posredovati uradno zahtevo za prenos kode. Sami namreč na produkciji nimamo vseh pravic. Koda se na produkcijsko podatkovno bazo prenaša iz testnega baze. Prav tako moramo obvestiti uporabnike z najavo del, da so seznanjeni o spremembah ter o morebitnih težavah. Ko je opravljen prenos na produkcijo

naredimo še osnovne teste delovanja tudi na produkciji. V kolikor karkoli ni kot smo pričakovali, moramo imeti pripravljen scenarij, da vse vrnemo v prejšnje stanje. Nova koda lahko namreč povzroči tudi nepričakovane težave ali pa celo na produkcijskem okolju ne deluje kot je bilo zahtevano. Zato je potrebni imeti pripravljen obratni scenarij prenosa na produkcijo, torej da vrnemo kodo nazaj v prvotno stanje.

4.2 Delovanje aplikacije in umestitev v obstoječ sistem CRM

Naša aplikacija je samo del celotnega sistema CRM. V aplikaciji smo uporabili veliko že prej razvitih funkcionalnosti. Uporabili smo podatke o strankah ter na primer obstoječo funkcionalnost prikazovanja zgodovine uporabnika. Tudi prijava v sistem CRM oziroma dostop do naše aplikacije je narejen na podlagi obstoječih uporabniških imen.

4.2.1 Upravljanje uporabnikov sistema CRM

Uporabnikom se dostop do sistema CRM dodeljuje na podlagi uradnega zahtevka, ki se ga odda preko zato namenjenega orodja. Nove dostope lahko zahtevajo samo vodje ali nadrejeni.

Uporabnika nato dodajamo preko aplikacije za administracijo, do katere imamo dostop v sistemu CRM kot administratorji sistema. Aplikacija za kreacijo uporabnika je preprosta. V aplikaciji imamo pred definirane različne tipe profilov za različne oddelke v podjetju (klicni center, prodajalec, IT, naročniška služba,…). Na podlagi zahtevka dodelimo pravi profil uporabnika, izberemo uporabniško ime, ter vpišemo še podatke kot so ime in priimek, e-mail naslov in telefonska številka. Aplikacija za administracijo avtomatsko naredi zapise v podatkovni bazi v potrebne tabele. V eni tabeli so zapisi o uporabniku, v drugi pa so definirani dostopi, ki jih ima uporabnik. Vsak uporabnik sistema CRM mora na tri mesece menjati geslo.

Le - to, mora biti dolgo vsaj osem znakov, vsebovati mora tudi vsaj eno veliko črko, en posebni znak ter dve številki. Če uporabnik pozabi svoje geslo, mora oddati zahtevek za ponastavitev gesla. Kot administratorji imamo le mi dostop, da lahko naredimo ponastavitev gesla za druge uporabnike. Geslo pa se potem ponastavi na privzeto geslo. Dostop do naše aplikacije za pošiljanje sporočil SMS sicer omogočimo samo določenim tipom profila v sistemu CRM, za katere je bil ta dostop zahtevan. V menijih v sistemu CRM se uporabnikom prikazujejo samo aplikacije do katerih imajo definirane dostope.

23 4.2.2 Umestitev aplikacije v obstoječ sistem

Aplikacijo umestimo v meni z zapisom v tabelo, kjer imamo zapise vseh menijev v sistemu CRM. Na sliki 9 je prikazan izpis poizvedbe. V to tabelo v polje »TXT« zapišemo ime aplikacije, kot jo bomo poimenovali v meniju, v drugo polje »URL« pa ime datoteke na strežniku, v katerem se nahaja koda aplikacije. V tej tabeli tudi definiramo kje v meniju se bo nahajala naša aplikacija. Meniji imajo namreč drevesno strukturo, v polju »LEVEL_NR«

določimo na katerem nivoju v meniju bo ta naš meni, ter v polju »PARENT«, kateri meni je nad njim. LEVEL_NR 1 pomeni, da je nad njim le en zapis, zapis, ki ima vrednost »NR« 26.

Definicija, kateri profili imajo dostop do tega menija pa je v drugi tabeli povezani z to po polju.

Slika 9: Izpis poizvedbe iz baze [(vir slike: lastni)]

Podatke o uporabniku sistema CRM ter njegovem profilu uvozimo tudi v našo aplikacijo.

Uporabniško ime namreč uporabimo pri zapisih v zgodovino stranke, ter pri zapisu v tabelo za pošiljanje sporočila SMS. Tip profila, ki ga pridobimo s klicem obstoječe funkcije na podatkovno bazo pa vpliva na delovanje aplikacije. Določene funkcionalnosti, kot je na primer poljuben zapis v zgodovino stranke je namreč na voljo le določenim profilom. V kolikor uporabnik nima tega profila se ta funkcionalnost enostavno ne odpre. Od profila je odvisen tudi prikaz vzorčnih sporočil SMS oziroma tekstov. Kateri teksti so vidni kateremu uporabniku je namreč odvisno od tipa profila.

4.2.3 Podatki o stranki

Sistem CRM je namenjen upravljanju s strankami. Podatke o strankah pa imamo shranjene v podatkovni bazi. Zaradi upravljanja s strankami te podatke nato prikazujemo uporabnikom sistema.

Slika 10: Strankini podatki v aplikaciji, ko je v sistemu CRM odprta mobilna stranka [(vir slike: lastni)]

Podatki o strankah se prikažejo na podlagi iskalnika, kjer lahko iščemo stranke po različnih parametrih. Na sliki 10 je primer prikaza, ko je v sistemu CRM odprta mobilna stranka. Dva izmed teh podatkov, ki ju nato tudi uporabimo v naši aplikaciji sta davčna številka in mobilna številka ali uporabniško ime. Posebnost prikaza podatkov pa je pri agentom klicnega centra, kjer sistem ob prejemu klica avtomatsko odpre podatke o stranki.

V naši aplikaciji od vseh podatkov, ki so nam na voljo uporabimo le davčno številko ter mobilno številko (v nadaljevanju številka MSISDN) ali v primeru stranke s fiksno tehnologijo uporabniško ime. Ko odpremo našo aplikacijo se ta dva podatka preneseta avtomatsko v aplikacijo. S tem vsaj v primerih, kjer se prenese številka MSISDN zmanjšamo možnost napak pri vnosu številke za pošiljanje sporočila SMS, pri strankah s fiksno tehnologijo pa je potreben vnos telefonske številke še vedno ročen. Da naredimo prenos podatkov o stranki v našo novo aplikacijo pa moramo raziskati pod katerimi parametri v sistemu CRM najdemo te podatke. V našem primeru so to parametri »msisdn«, »lineusername« ter »vat«. S spodnjo kodo preverimo če kateri podatki o stranki obstajajo, in v kolikor obstajajo jih uporabimo v naših spremenljivkah »sms_msisdn«, »line_username« ter »vat«. Preverba o tem ali podatek obstaja naredimo na enostaven način, s preverbo dolžine znakov parametra. V kolikor preverjamo ali obstaja številka MSISDN, lahko preverimo po dolžini 11 znakov, saj je številka MSISDN v obliki 386xxxxxxxx; V kolikor pa za uporabniško ime, pa naredimo preverbo, ali je dolžina podatka več kot 0. Če pa v sistemu CRM nimamo odprte nobene stranke, se ne prenese noben podatek, v tem primeru se vsi podatki vpisujejo ročno.

25 4.2.4 Vnaprej nastavljena besedila

Ker se nekatere vsebine sporočil, ki se jih pošilja strankam ponavljajo, je v aplikaciji funkcionalnost, da so določeni predlogi vsebin sporočil na izbiro v spustnem meniju. Slika 11 prikazuje primer vnaprej nastavljenih predlogov za pošiljanje sporočil.

Slika 11: Vnaprej nastavljena besedila [(vir slike: lastni)]

Vsebine sporočil imamo shranjene v podatkovni bazi, kjer smo v ta namen naredili novo tabelo (ukaz za kreacijo tabele na sliki 12). Tabelo smo poimenovali »SMS_TEMPLATE«, vsebuje pa polja »ID«, ki je številka zapisa, »SMS_TYPE« na podlagi katerega je določena vidnost zapisa, »TITLE«, kjer je ime oz. naslov zapisa, v polju »TEXT« se nahaja tekst za sporočilo SMS, »ORDER_NR« je namenjen razvrščanju podatkov v aplikaciji, ter polje

»ENABLED« v katerem označujemo ali je tekst še aktualen oziroma v uporabi. Polja

»ID«,«ORDER_NR« in »ENABLED« so tipa »NUMBER«, kar pomeni da so v teh poljih lahko le številski zapisi. »NOT NULL« pa pomeni, da polje ne sme biti prazno. Pri zapisih

»SMS_TYPE«, »TITLE« in »TEXT« pa so polja tipa »VARCHAR2«, kar pomeni, da lahko polje vsebuje vse znake, tako črke kot številke. Številka v oklepaju pa označuje velikost polja.

Slika 12: Ukaz za kreacijo tabele »SMS_TEMPLATE« [(vir slike: lastni]

Vpis podatkov v tabelo naredimo s komando »INSERT INTO«, vpis pa naredimo v orodju SQL Detective, s katerim upravljamo bazo. Slika 13 prikazuje primer novega vpisa v tabelo.

Slika 13: Ukaz za vpis podatkov v tabelo »SMS_TEMPLATE« [(vir slike: lastni]

Za prikaz podatkov iz tabele v aplikaciji pa uporabimo SELECT stavek (prikazan na sliki 14), ki prikaže vse zapise, s poljem »ENABLED« katero je nastavljeno na 1, kar v našem primeru pomeni omogočeno, podatke pa razvrstimo glede na podatek v polju »ORDER_NR«, od najnižje številke do najvišje:

Slika 14: Poizvedba za prikaz podatkov iz tabele »SMS_TEMPLATE« [(vir slike: lastni]

4.2.5 Preverjanje pravilnosti vpisanih podatkov

Ker kljub navodilom uporabniki lahko vpisujejo kakšne nepravilne podatke moramo pred vpisom v tabele narediti preverbo vpisanih podatkov. V aplikaciji se ob kliku na gumb »Pošlji SMS« najprej naredi preverba teh podatkov. Naredimo preverbo, da je dolžina številke MSISDN, na katerega se pošlje sporočilo res 11 znakov, ter da se začne s 386. V kolikor se dolžina številke MSISDN ne ujema, ali se začne drugače kot s 386 aplikacija javi (kot je prikazano na sliki 15), da je podatek nepravilen, ter niti ne poskusi s pošiljanjem sporočila SMS.

27 Slika 15: Opozorilo, da številka ni prave dolžine oziroma se ne začne s 386 [(vir slike: lastni)]

Preverja pa se tudi, da številka na katero pošiljamo sporočilo SMS ni fiksna številka, saj le - te, ne morejo prejeti sporočila SMS. To preverbo naredimo s klicem že obstoječe funkcije na podatkovno bazo, ki preverja ali se gre za fiksno ali mobilno številko. Funkcija preverja ali se gre za fiksno ali mobilno številko na podlagi tega, pri katerem operaterju se nahaja številka. Ta podatek pa pridobimo iz baze za prenos številk med operaterji (NP – number portability), saj je v sistemu CRM izveden tudi prenos številk med operaterji. V kolikor se nahaja številka pri fiksnem operaterju in ne mobilnem dobimo opozorilo, kot je prikazano na sliki 16.

Slika 16: Opozorilo da številka ni v pravem formatu [(vir slike: lastni)]

Naredili smo tudi preverbo po dolžini zapisa v polju, kjer se nahaja vsebina za pošiljanje sporočila. Če je vsebina dolžine 0, pomeni, da je polje prazno in sporočilo najverjetneje ni bilo mišljeno za pošiljanje, zato se izpiše obvestilo kot je prikazano na sliki 17.

Slika 17: Opozorilo »prazen tekst« [(vir slike: lastni)]

V primeru, da smo za zapis v zgodovino izbrali podatek »line_username« ali pa davčna številka, in je le - ta na formi prazen se nam izpiše obvestilo, kot je prikazano na sliki 18.

Slika 18: Opozorilo, da manjka podatek oziroma ni pravilen [(vir slike: lastni)]

Če pa so vsi ti podatki pravilni, pa aplikacija sporoči, da je bilo sporočilo SMS uspešno poslano, ter se naredi zapis v zgodovino stranke, kar je razvidno iz slike 19.

Slika 19: Obvestilo da je bilo sporočilo SMS uspešno poslano stranki, ter narejen zapis v zgodovino stranke [(vir slike: lastni)]

4.2.6 Zapis v zgodovino stranke

V sistemu CRM se ob tem, ko odpremo stranko avtomatsko pokaže tudi zgodovina stranke za zadnje tri mesece. Če želimo videti večje časovno obdobje le - to lahko prikažemo tako, da izberemo večje časovno obdobje. Krajše avtomatsko trimesečno obdobje se sicer prikaže zaradi manjšega obremenjevanja podatkovne baze. Prikaz zgodovine stranke je namenjen, da se vidi kaj točno je stranka delala v preteklosti. Tu se beležijo vse morebitne spremembe ali vklopi raznih opcij na stranki, ki jih stranka naredi sama preko portala, preko SMS sprememb, ali pa agentje te spremembe opravijo v sistemu CRM na podlagi zahteve stranke. Beležijo se tudi morebitne nove vezave, klici v klicni center, odprte tehnične pritožbe stranke, obvestila o novih ponudbah ter obvestila o spremembi pogojev. Večino zapisov se dodaja avtomatsko ob spremembi, vpis pa je možen tudi ročno s strani agenta. Uporabniki sistema CRM imajo tako celoten vpogled nad zgodovino stranke. Prikaz teh podatkov je pomemben predvsem v primeru reševanja reklamacij s strani strank, ali pa na primer pri preprečitve podvajanja dela.

Zapis v zgodovino se lahko naredi na več nivojih:

 Na nivoju naročnika,

 številke MSISDN,

29

 uporabniškega imena ter,

 na nivoju davčne številke.

V kolikor se naredi zapis na nivoju davčne številke, se le - to vidi v zgodovini vseh strank (številk MSISDN), ki imajo zabeleženo to davčno številko. V kolikor se naredi na nivoju naročnika, se zgodovina pokaže samo pri tej konkretni stranki. V to zgodovino naredi zapis (prikazan na sliki 20) tudi naša aplikacija za pošiljanje sporočila SMS. V aplikaciji nam tudi ponudi izbiro na kateri nivo se bo dodajal zapis, torej na nivo naročnika ali pa davčne številke.

Privzeto se v zgodovino stranke naredi zapis, da je bilo stranki poslano sporočilo SMS, ter njegova vsebina. Lahko pa namesto vsebine sporočila zapišemo tudi kak drug poljuben tekst.

V aplikaciji imamo namreč možnost vpisa v zgodovino poleg teksta za sms tudi poljuben tekst.

V aplikaciji se nato v primeru, da je tekst za zgodovino prazen, naredi zapis v podatkovno bazo z vsebino sporočila SMS, v nasprotnem primeru pa se naredi zapis z obema podatkoma. V zgodovino se vpišejo tudi podatki o času vpisa v zgodovino, o uporabniku, ki je delal zapis, ter podatek o naročniku, in nivo vpisa, ki pove ali se gre za vpis na davčno ali naročnika. Vpiše pa se tudi podatek, za kateri tip zapisa se gre v zgodovini. Zapis naredimo pod tipom »SMS Obvestilo«.

Slika 20: Izgled zapisa v zgodovini stranke v sistemu CRM [(vir slike: lastni)]

4.2.7 Postopek pošiljanja sporočila SMS

Ker imamo v sistemu CRM že podprta nekatera avtomatska pošiljanja sporočil SMS obstoječe funkcionalnosti izkoristimo tudi sami. Za potrebe pošiljanja sporočil moramo narediti vpis v obstoječo tabelo z imenom »SMS_LIST«. V tabelo in v polje »text« zapišemo podatke o vsebini sporočila, številko MSISDN stranke v polje »MSISDN«, podatek o času kreacije zapisa v tabelo naredimo v polje »REQ_DATE, vpišemo pa podatek »sysdate«, ki pomeni, da se vpiše trenuten čas in datum. V polje »STATE« zapišemo status sporočila, v našem primeru

1, kar pomeni da sporočilo SMS še ni bilo poslano. Podatek o tem kateri uporabnik je poslal sporočilo stranki se zapiše v polje »USERNAME«, kako pa se aplikacija kot pošiljatelj predstavi stranki, pa zapišemo v polje »FROM_ADDR«. V našem primeru se pošlje sporočilo SMS stranki z naslova »A1.si«. Podatek, kdo je pošiljatelj namreč ni nujno številka MSISDN, lahko se uporabijo tudi t.i. kratke številke ali pa krajše besedilo.

Aplikacija ob pritisku na gumb »Pošlji SMS« naredi zapis v to tabelo na podatkovni bazi.

Slika 21 prikazuje primer zapisa podatkov v bazo.

Slika 21: Ukaz za vpis podatkov v tabelo »SMS_LIST« [(vir slike: lastni)]

V tej tabeli nato zapis prebere procedura z imenom »PosljiSMS«, ki s HTTP zahtevo tudi izvede pošiljanje sporočila SMS. Procedura se izvaja vsaki 2 minuti, poganja pa jo »job« oz.

avtomatsko opravilo, ki je nastavljeno, da zažene proceduro na določen čas. V našem primeru na dve minuti, kar je narejeno z ukazom SYSDATE+2/1440. SYSDATE je trenutni čas, kateremu prištejemo dve minuti tako, da delimo 2 z številom minut v dnevu kar je 1440. Job se naredi s spodnjo komando, kar prikazuje slika 22.

Slika 22: Ukaz s katerim naredimo avtomatsko opravilo [(vir slike: lastni)]

Pošiljanje oziroma kreacijo HTTP komande naredi procedura, ki smo jo poimenovali

»PosljiSMS«. Procedura s pomočjo SELECT stavka iz tabele SMS_LIST prebere vse zapise, ki imajo v polju STATE zapis 1. Status 1 v našem primeru pomeni, da sporočilo SMS še ni bil poslan. Pošiljanje na SMS center se opravi s HTTP klicem na Web Service. V kolikor je odgovor »OK« se postavi procedura z »UPDATE« stavkom, zapis v naši tabeli v status 2, ki pomeni da je bilo sporočilo SMS uspešno poslano, v kolikor pa je odgovor drugačen od »OK«

pa se postavi status na 3, kar pomeni, da sporočilo SMS ni bil dostavljeno. Procedura sicer

31 sproži HTTP zahtevek s pomočjo sistemskega objekta, ki je del podatkovne baze Oracle, imenuje pa se Package UTP_HTTP. V Package-u se kliče funkcija z imenom »request«, z vhodnim parametrom »url«. Sporočilo SMS se pošlje na podoben način kot se vpiše URL naslov v brskalnik, torej z metodo GET. Navodila za obliko URL-ja v našem primeru najdemo na spletni strani A1.si, kjer so navodila javno dostopna. URL je sestavljen iz dveh delov, prvi del so podatki o strežniku, ki jih moramo pridobiti od ponudnika SMS centra in poleg protokola vsebujejo še podatke o omrežnem naslovu oziroma IP-ju, ter vrata in pot na strežniku. Drugi del pa so dinamični parametri »to« v katerem navedemo prejemnika, »from« kjer navedemo pošiljatelja ter tekst sporočila v parametru »text«. Stranka pa prejme SMS od »A1.si« (primer sporočila SMS na sliki 23).

Slika 23: Zajem slike zaslona prejetega sporočila SMS na mobilnem aparatu [(vir slike:

lastni)]

4.3 Navodila uporabnikom

Uporabnikom na koncu tudi pripravimo kratka navodila za uporabo. Ta navodila smo priložili v prilogo. Pojasnimo jim, da se aplikacija nahaja v sistemu CRM, ki ga uporabniki že poznajo, tako da jim v navodilih podamo samo podatke o uporabi aplikacije za pošiljanje sporočil SMS.

Na priloženih slikah jim tudi označimo kje najdejo to aplikacijo in povemo kakšno je osnovno delovanje aplikacije. Pokažemo kako izberejo vnaprej definiran tekst oziroma vpišejo poljuben tekst, pojasnimo postopek zapisa v zgodovino stranke, kje nato najdejo ta zapis, ter v kakšni obliki mora biti napisana številka MSISDN. Opišemo tudi kaj se zgodi, ko kliknemo

gumb »Pošlji SMS«. V tem primeru se namreč sproži preverba pravilnosti vpisanih podatkov, če pa je vse v redu, pa se stranki pošlje sporočilo SMS, ki pride z naslova »A1.si«. Pojasnimo jim tudi, da če bi želeli dodatne pred definirane tekste, naj nam to sporočijo nadrejeni.

33

5 Rezultati

V nadaljevanju predstavljamo naslednje rezultate:

 Koliko sporočil SMS pošlje naša aplikacija,

 primerjava poslanih sporočil SMS po četrtletjih,

 prihranek časa in denarja,

 število napak,

 vpliv na zadovoljstvo strank.

5.1 Število poslanih sporočil SMS

Analizo števila poslanih sporočil SMS smo izvedli eno leto po izvedbi produkta. S pomočjo poizvedbe v podatkovno bazo smo naredili povprečje poslanih sporočil v zadnjih treh mesecih.

Na ta način smo prišli smo do podatka, da je mesečno v povprečju z aplikacijo poslanih 10332 sporočil oziroma skoraj 344 dnevno. Od tega je vnaprej definiranih tekstov 8920, 1412 pa je takšnih kjer agentje tekst napišejo sami. Tu lahko ločimo še poslana sporočila SMS, ki so jih poslali agentje iz klicnega centra, tehnične pomoči, ki so sporočila pošiljali že do sedaj, ter zaposleni na prodajnih mestih, ki do sedaj tovrstne aplikacije niso uporabljali. Le - ti so do sedaj svoje stranke obveščali bodisi preko klica ali pa s pošiljanjem sporočila s telefona.

5.2 Primerjava števila poslanih sporočil SMS po četrtletjih

Spodnji graf prikazuje primerjavo števila poslanih sporočil SMS iz aplikacije po četrtletjih v zadnjih dveh letih odkar je bila aplikacija izvedena. Naj povemo tudi, da smo aplikacijo izvedli šele v sredini maja 2019, tako da je časovno obdobje pri prvem podatku (drugo četrtletje 2019) krajše. Iz podatkov pa je razvidno, da se je vsaj v začetku uporaba aplikacije povečevala, v zadnjih četrtletjih pa stabilizirala.

Graf 1: Število poslanih sporočil SMS po četrtletjih

5.3 Prihranek na času in denarju

Preden smo v naš sistem CRM uvedli aplikacijo za pošiljanje sporočil SMS, so uporabniki pošiljali sporočila SMS iz druge temu namenjene aplikacije. Vnaprej definirane tekste so imeli agentje shranjene v Excelovi datoteki, ki so jo imeli shranjeno na skupnem disku. Ob tem, so vedno morali narediti še zapis v zgodovino stranke. Postopek je bil tako zamudnejši. Glede na meritve, ki smo jih opravili je uporabnik za postopek pošiljanja sporočila, brez pisanja teksta, porabil v povprečju 25 sekund. V ta čas je všteto iskanje aplikacije na namizju in odpiranje ter uporabo aplikacije, v kar je vključeno tudi pisanje mobilne številke. Poleg tega je za zapis v zgodovino povprečno porabil še dodatnih 20 sekund. Z novo aplikacijo je skupen povprečen čas 15 sekund. Torej je prihranek pri enem samem sporočilu kar 30 sekund. Takšnih sporočil pa je v povprečju 1412 na mesec, kar pomeni da je prihranek na mesečni ravni 11,76 ur. Na letni ravni to znaša 140 ur. Še večja razlika pa je pri poslanih sporočilih SMS, kjer je tekst vnaprej definiran. Tu je število sporočil SMS višje, poleg tega pa je potrebno poiskati tekst v Excel datoteki. Če predpostavljamo, da imajo uporabniki Excel datoteko v 30 odstotkih primerov že odprto na namizju, ter jim jo ni potrebno iskati v skupni mapi, je skupen povprečen čas samo za iskanje teksta 20 sekund. Povprečen čas iskanja teksta v aplikaciji pa je 5 sekund.

Torej smo pri tekstu prihranili 15 sekund na sporočilo SMS. Če dodamo še dodatnih 30 sekund prihranka pri uporabi stare aplikacije za pošiljanje sporočil SMS v ter vpisu v zgodovino, lahko

4715

15310

11899

19663

30998

44988

34688

30069

0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000

2 četrtletje

2019 3 četrtletje

2019 4 četrtletje

2019 1 četrtletje

2020 2 četrtletje

2020 3 četrtletje

2020 4 četrtletje

2020 1 četrtletje 2021

Število poslanih sporočil SMS