CRM sistemos

TURINYS

ĮŽANGA 2

1. Bendras Ryšių su klientais valdymo sistemų supratimas 3

1.1 CRM sistemos – kas tai? 3

1.2 Operacinio ir analitinio CRM sistemos 5

1.3 CRM sistemų šeima 6

1.3 Ryšių su klientais valdymo sistemų taikymai 7

2. Ryšių su klientais valdymo sistemų architektūra 9

2.1 Architektūros vertinimo kriterijai 10

2.2 CRM architektūros struktūra 10

2.3 Architektūrų tipai 12

2.4 Architektūros realizavimo technologinės priemonės 14

2.5 Esamų produktų architektūrų palyginimas 15

3. Ryšių su klientais valdymo sistemos kūrimas 17

3.1 Saugios aplinkos sukūrimas 17

3.2 Realizavimo proceso valdymas 18

3.2.1 Pirma stadija – reikalavimų analizė 19

3.2.2 Antra stadija – Personalizacija ir Prototipavimas 20

3.2.3 Trečia stadija – Dislokavimas 20

3.2.4 Ketvirta stadija – patirinimas po įdiegimo 21

4. CRM ir esamų innformacinių sistemų integracija 21

4.1 Integracijos reikalavimai 22

4.2 Integracijos metodai 23

4.2.1 Failų integracijos metodas 23

4.2.2 Programavimo metodas 23

4.2.3 Tarpinės Programinės įrangos metodas 24

4.3 Integruotos sistemos pavyzdys 24

4.3.1 Ryšių su klientais valdymo sistemos pavyzdys 24

4.3.2 CRM sistema informacinėje sistemoje 26

Išvados 29

Naudotos literatūros sąrašas 30

PRIEDAI 32

ĮŽANGA

Gyvenimas nestovi vietoje – jis dinamiškas ir nuolat kintantis. Tai, kas
buvo nesvarbu vakar, gali būti ypač reikšminga šiandien ir tai nieko
nuostabaus – pažanga yra gamtos dėsnis (Volteras) ir mes negalime jos
išvengti. Pamažu į verslo pasaulį žengia nauja filosofija, nauji procesai
bei technologijos. Dar nesenai verslas žymiai labiau domėjosi daiktais, o
ne žmmonėmis – savo klientais. Įmonės skyrė didžiausią dėmėsį pardavimų
apimčių didinimui ir nesivargino galvodamos, kas gi jų produktus perka.
Šiandien, gyvenant postmoderniame amžiuje, augant konkurencijai padėtis
keičiasi. Vartotojai gali rinktis iš vis didesnio skaičiaus prekių ir
paslaugų tiekėjų, todėl tradiciniai konkurencijos metodai darosi
neefektyvūs. Dabartinė ekonomika yr

ra nulemta informacinių procesų, kurie
iššaukia naujų veiklos sričių, susijusių su rinkoje veikiančiais procesais,
atsiradimą.
Viena tokių naujų verslo sričių, grindžiančių naujos ekonomikos pradžią,
yra „į klientą orientuota vadyba“, arba ryšių su klientais valdymas,
dažniau žinoma trumpiniu CRM (ang. Customer Relationship Management).
Kadangi Verslo atstovai pradeda suprasti, kad jei nebus klientų, tai nebus
ir verslo, jų susidomėjimas šia sritimi sparčiai auga, o Ryšių su klientais
valdymo sistemų arba paprasčiau CRM sistemų diegimas daugelyje įmonių tampa
verslo strategijos dalimi.
Šiandien apie ryšių su klientais valdymo sprendimus kalbama bene tiek pat
daug, kiek kažkada apie interneto prekybą, tai jau tampa lyg dar viena
“panacėja”. Žmonės tampa lyg užburti šios naujos koncepcijos ir puola
stačia galva diegti šias sistemas mažai ką apie jas žinodami, todėl
dažniausiai patiria didžiules nesėkmes. Taigi, noras sužinoti daugiau apie
ryšių su klientais valdymą bei appie priemones užtikrinančias efektyvų tokių
sistemų funkcionavimą ir paskatino paanalizuoti šią temą.
Kadangi ryšių su klientais valdymas yra labai plati sąvoka, apimanti
daugybę sričių, todėl visko apžvelgti yra neįmanoma. Šiame darbe aš
pasirinkau detaliau apžvelgti ryšių su klientais valdymo sistemų
architekūrą, jų įdiegimą ir integraciją su kitomis įmonės sistemomis, bei
bendriausiais bruožais paaiškinti, kas gi yra tas magiškas trumpinys CRM,
pasitelkusi tokią struktūrą:

• Pirmame skyriuje pabandysiu trumpai paaškinti, kas tai yra CRM,

supažindinsiu su pagrindiniais tikslais bei ryšių su klientais sistemų

rūšimis;

• Antrasis skyrius bus skirtas aptarti tokių sistemų architektūrai,

išsiaiškinant jos st
truktūrą, pagrindinius tipus, vertinimo kriterijus

bei palyginant esamų produktų architektūras;

• Trečiajame skyriuje supažindinsiu su CRM sistemų diegimu, diegimo

etapais bei fazėmis;

• Ir ketvirtasis skyrius bus skirtas apžvelgti CRM sistemų integraciją

su kitomis sistemomis, integracijos metodus ir reikalavimus bei bus

pateikiamas integruotos sistemos pavyzdys.

1. Bendras Ryšių su klientais valdymo sistemų supratimas

Prieš kuriant ir diegiant Ryšių su klientais valdymo sistemą, t.y.,
kompleksinę sistemą, kurios pagrindiniai komponentai yra žmonės, duomenys
bei technologijos, ir kuri leidžia įvertinti ir maksimizuoti kiekvieno
įmonės kliento ekonominę vertę, bei taikyti veiksmingus vertingiausių
klientų lojalumo skatinimo metodus, yra būtina išsiaiškinti tokius dalykus:

• Kas yra ryšių su klientais valdymas, bei ryšių su klientais valdymo

sistemos arba CRM sistemos;

• Kuo skiriasi analitinės ir operacinės ryšių su klientais sistemos;

• Kokios gali būti šios sistemos;

• Bei kur yra taikomos ryšių su klientais valdymo sistemos.
Taigi, dabar kiekvieną aptarkime detaliau.

1.1 CRM sistemos – kas tai?

Įmonėms augant, intymūs santykiai su klientais pradeda blėsti ir galiausiai
visai nutrūksta – jų vietą užima masinė rinkodara ir standartizuotų
produktų srautas. Įmonės nebepažįsta savo klientų, o klientai nustoja
pasitikėti įmonėmis. Iš tiesų, kaip dešimtis ar šimtus tūkstančių klientų
turinti bendrovė gali kiekvieną jų atpažinti ir pasiūlyti individualizuotą
aptarnavimą?

Būtent čia į pagalba ir ateina Ryšių su klientais valdymas arba CRM.
Ryšių su klientais valdymas turi padėti įmonei atgal į vieną gabalą
surinkti išsibarsčiusias savo verslo dalis ir susikurti plieninius saitus
su geriausiais savo klientais bei padėti optimizuoti pelningumą, pajamas ir
patenkiniti kl

lientų poreikius. (2)
Be to, toks valdymas turėtų padėti pardavėjams geriau prognozuoti savo
pardavimus, klientus, galimybes bei kontaktinę informaciją. (12)
Matome, kad reikalavimai yra keliami labai dideli, todėl Ryšių su klientais
valdymas yra įgalinamas tik sistemos pagalba. Būtent dėl šios piežasties jo
principai, kurie jau buvo žinomi prieš penkiolika metų, taikyti pradėti tik
prieš pora metų. Tai atsitiko todėl, kad informacinės technologijos arba
IT (ang. Information technology), kurių reikia sėkmingam Ryšių su klientais
valdymo sistemų įdiegimui įmonėse, atsirado tik prieš dvejus metus – iki
tol nei programinė, nei kompiuterinė įranga nebuvo pakankamai galinga, kad
leistų įmonėms pakankamai operatyviai analizuoti dešimčių ar šimtų
tūkstančių klientų elgsenos duomenis ir ta analize remti tolesnius
operacinius sprendimus. Atsiradus šiems IT sprendimams ir kilo tokių
sistemų diegimo banga. Tačiau svarbu prisiminti, kad IT tėra tik viena iš
Ryšių su klientais valdymo sistemų sudedamųjų dalių. Gera CRM programinė
įranga yra būtina, bet ne pakankama sąlyga sėkmei užtikrinti.(3) Taigi, kas
visgi yra ryšių su klientais valdymo sistema?
Įvairiuose literatūros šaltiniuose susidūriau su nemažu skaičiumi
apibrėžčių, ir man priimtiniausia pasirodė, ši: CRM sistema – tai
kompleksinė sistema, kurios pagrindiniai komponentai yra kompiuterinė
sistema (IT platforma), žmonės, procedūros, duomenys bei ryšio priemonės,
ir kuri leidžia įvertinti ir maksimizuoti kiekvieno bendrovės kliento
ekonominę vertę, bei taikyti veiksmingus vertingiausių klientų lojalumo
skatinimo metodus. Tačiau svarbu pridurti, kad modernios IT platformos
negali pačios išspręsti klientų pritraukimo, išsaugojimo ar a
aptarnavimo
problemų – jos tik padeda automatizuoti bendrovės verslo procesus. Todėl
įmonės turi žiūrėti į ryšių su klientais valdymą ne kaip į izoliuotą
projektą, o kaip į visą įmonę apimančią verslo filosofiją.(10)
Taigi, apibendrinant galime sakyti, kad Ryšių su klientais valdymo sistema
nėra “problemų sprendikas”, o ji padeda priimti kokybiškesnius sprendimus,
nukreiptus į vartotojus.
Pagrindiniai naudojimosi Ryšių su klientais valdymo sistemomis tikslai yra
tokie:

• Nuodugniai išsiaiškinti savo klientų poreikius dar prieš tai, kol jie

suvokia juos patys;

• Padidinti klientų pasitenkinimą ir taip sumažinti vidutinį jų kaitos

tempą;

• Skatinti klientus savo iniciatyva užmegzti bendrovei pajamas

kuriančius verslo kontaktus;

• Padidinti tikimybę, kad vartotojo reakcija į pasiūlymus bus tokia,

kokios reikia;

• Pakelti klientų aptarnavimo lygį;

• Patraukti naujus ir senus pirkėjus labiau individualizuotu bendravimu.

Kaip matome, sėkmingo gali būti daug skirtingų vizijų, tačiau bendra

idėja išlieka visur: CRM sistemos padeda pažinti savo klientus taip

gerai, kad įmonė galėtų aiškiai suprasti, kuriuos jų būtina išsaugoti, o

kuriuos galima be didelio nuostolio prarasti. (2) Tačiau vien vizijos

nepakanka tam, kad CRM sistema funkcionuotų tinkamai. Kad būtų

įgyvendinti visi keliami tikslai būtina parinkti tinkamiausią įmonei CRM

sistemos tipą, todėl dabar išsiaiškinkime kokie jie gali būti.

1.2 Operacinio ir analitinio CRM sistemos

Pagal savo veikimo pobūdį CRM sistemos skirstomas į Operacines bei
Analitines-Strategines pagal tai, koks yra Ryšių su klientais valdymas –
Operacinis ar Analitinis-Strateginis. Šis skirstymas svarbus, nes nuo jo
priklauso, kokios taktikos įmonė laikysis kurdama bei diegdama savo ryšių
su klientais valdymo sistemą. Griežtai atskirti nepavyks, kadangi dabar
dauguma gamintojų į operacinio CRM sistemas įdiegia analitines funkcijas
arba atvirkščiai, tačiau apytiksliais bruožais galima išskirti dvi grupes.
Operacinis CRM apima sritis, kuriose įmonė tiesiogiai susiliečia su
klientu. Sąlyčio tašku gali būti “įeinantys” kontaktai, kaip skambučiai,
laiškai ir pan., arba “išeinantys” kontaktai, kaip, sakykime, el. paštu
išsiųstas reklaminis pranešimas klientui. Didžioji CRM programinės įrangos
produktų dalis patenka būtent į operacinio CRM kategoriją.
Operacinis CRM padaro bendravimą su klientu tiesesniu ir efektyvesniu,
tačiau tai nebūtinai reiškia tobulesnį aptarnavimą. Tai, kad banko klientas
tikrina savo sąskaitos likutį internete, dar nereiškia, kad operacijas
atlikinėti banko filiale jam nėra smagiau. (2,3)
Analitinis CRM, dar vadinamas “strateginiu”, leidžia suprasti kliento
veiksmus ir yra skirtas informacijai, gaunamai iš vartotojo, kaupti,
apdoroti ir kurti atatinkamą analitinę CRM informacinę produkciją. Jis taip
pat leidžia naudotis kitų IT (ang. Information Technology) ar verslo
analitinės

Analitinio ryšių su klientais valdymo sistemos diegimui reikalingi tam
tikros IT, kaip pavyzdžiui OLAP (ang. On-line Analytical Processing),
leidžiantčios surinkti ir apdoroti kalnus analizei reikalingos klientų
informacijos. Tokioms sistemoms taip pat reikalingi nauji verslo procesai,
kuriais siekiama patobulinti klientų aptarnavimo praktiką, skatinant jų
lojalumą ir didinant pelningumą. Dauguma CRM programinės įrangos gamintojų
šiandien skuba patys sukurti analitinio CRM produktus arba mėgina įtraukti
šias galimybes į savo produktus sudarydami partnerystės susitarimus su
analitinės verslo informacijos IT sprendimų tiekėjais. (2)
Tačiau tai ne vienintelis skirstymas, egzistuoja dar vienas, šiek tiek
detalesnis, todėl dabar ir panagrinėkime šio skirstymo dėka susidariusią
CRM sitemų šeimą.

1.3 CRM sistemų šeima

e-CRM – taip įvardijamas santykių su klientais valdymas panaudojant
elektroninius komunikacijos kanalus, kur dažniausiai juo būna internetas.
Naudojimosi eCRM sistema geriausias pavyzdys būtų, prisijungus prie
interneto, laukiamos greitojo pašto siuntos buvimo vietos tikrinimas.
cCRM – Tiesioginio bendravimo arba “Kolaboratyvaus“ CRM modelis,
suteikiantis galimybę tenkinti masinius poreikius per gamybą. Taip kartais
žymimos interneto technologijomis paremtos sistemos, leidžiančios klientams
tiesiogiai keistis informacija su įmone. Pavyzdžiui, perkant automobilius
klientams paliekamos galimybes patiems susikomplektuoti norimos
komplektacijos automobilį, internetu nurodant norimus komponentus.
PRM (ang. Partner Relationship Management) – santykių su partneriais
valdymo sistema, leidžianti pagerinti aptarnavimo kanalų struktūrą,
bendrauti su tarpininkais, juos skatinti nuolaidomis bei kitomis
priemonėmis. Šios sistemos pagalba įmonė efektyviau valdo santykius su savo
prekybos partneriais, nukreipia klientus į optimalų aptarnavimo kanalą ir
“ištiesina” pardavimo procesą. PRM sistemos pavyzdys gali būti įmonės
naudojama sistema dinamiškai nustatanti marketingo partneriams teikiamų
nuolaidų, premijų dydžius priklausomai nuo kiekvieno partnerio atsiunčiamų
klientų pelningumo.
SRM (ang. Supplier Relationship Management) – siauresnės paskirties nei PRM
santykių su tiekėjais valdymo sistema. Tikslas čia siauresnis: padaryti
laimingais įmonės tiekėjus. SRM sistemos padeda įmonėms optimizuoti tiekėjų
pasirinkimo procesą, sudarydamos galimybes patogiau ir operatyviau
įvertinti ir kategorizuoti bendradarbiauti pageidaujančias kompanijas, ir
taip padidinti tiekimo grandinės efektyvumą.
mCRM –“mobilųjį CRM” reiškiantis sutrumpinimas kartais naudojamas kalbant
apie CRM sistemas, leidžiančias įmonės klientams, partneriams ir tiekėjams
pateikti duomenis per mobiliuosius telefonus ir kitokius mobiliuoju ryšiu
aprūpintus portabilius įrenginius. (1, 2)

1.3 Ryšių su klientais valdymo sistemų taikymai

Rinkodaros kampanijų automatizavimui skirtas CRM sistemas įsigyjančios
bendrovės paprastai ganėtinai tiksliai įsivaizduoja, kaip juos panaudos.
Apžvelkime keletą dažniau pasitaikančių klientų vertės ir lojalumo didinimo
taktikų, kurias įgyvendinti padeda ryšių su klientais valdymo sistemos.

• Kryžminiai pardavimai;

• Pelningesnės alternatyvos;

• Klientų išsaugojimas;

• Elgsenos prognozės;

• Klientų pelningumo ir vertės modeliavimas;

• Kanalų optimizavimas.

Kryžminis pardavimas (ang. Cross-selling) – tai bandymas kažką jau
nusipirkusiam klientui įsiūlyti kitą produktą ar paslaugą. Pavyzdžiu galėtų
būti sau drabužius besirenkanti jauna mama, kuri “tuo pačiu” nuperka kažką
ir savo kūdikiui.
Pelningesnės alternatyvos (ang. Up-selling) – tai bandymas įkalbėti klientą
iškeisti jau išsirinktą produktą į pardavėjui daugiau pelno atnešančią
alternatyvą. Kasdien sutinkamu pavyzdžiu galėtų būti restoranas
“McDonald’s”, kur užsakant bet kurį kompleksą, pardavėjas būtinai paklaus
ar nenorėtume pirkti didesnį kompleksą “XL”, kuris brangesnis tik vienu
litu. Taigi, abiejų metodų taikymo menas remiasi sugebėjimu nustatyti,
kurių produktų įsiūlymas padidins bendrą kliento pelningumą.
Klientų išsaugojimas (ang. Customer win-back) – tai taktika, kuri remiasi
sudėtingomis prognozavimo technologijomis, padedančiomis geriau pažinti
klientą ir jį išsaugoti.

Dirbant su tūkstančiais ar dešimtimis tūkstančių klientų, neretai sunku net
pastebėti, kad kažkuris klientas paspruko. Dar sudėtingiau išsiaiškinti,
kodėl.Todėl pirmiausia įmonės pradėjo aiškintis, kodėl klientai jas
palieka. Pagal išėjusių klientų profilius pradėta analizuoti esamų klientų
duomenų bazes. Šiandien įmonės naudoja sudėtingas prognozavimo
technologijas, lyginančias panašius vartotojų bruožus ir nurodančias tuos
klientus, kurie labiausiai linkę išeiti pas konkurentą.
Elgsenos prognozės – tai taktika, kuri modernių modeliavimo ir duomenų
analizės technologijų pagalba tyrinėja vartotojų elgesį praeityje ir
prognozuoja klientų ateities elgseną.Vartotojų elgsenos analizė apima
keletą variacijų:

• Polinkio pirkti analizė, kurią atliekame siekdami suprasti, kokius

produktus konkretus vartotojas apskritai būtų linkęs pirkti.

• Produktų sąsajų analizė, kurios dėka išsiaiškiname, kokie produktai

bus perkami drauge.

• Artimiausias pirkinys, kai prognozuojame, kokį sekantį produktą ar

paslaugą klientas pasiruošęs pirkti.

• Paklausos elastingumo kainai modeliavimas ir dinaminė kainodara, kai

siekiame nustatyti konkrečiam pirkėjui arba siauram segmentui

optimaliai tinkančią produkto kainą.
Klientų pelningumo ir vertės modeliavimas – tai taktika, kurioje tenka
daug dirbti su duomenimis modeliuojant klientų vertę ir vertės modeliavimo
tikslumas tiesiogiai priklauso nuo kliento duomenų pilnumo ir tikslumo bei
nuo analizėje naudojamų statistinių metodų stiprumo.

Kalbant apie kliento vertingumą, naudojamos “viso gyvenimo vertės” (VGV),
potencialios vertės arba konkurencinės vertės sąvokos. Daugelis įmonių
formalizavo klientų vertės modeliavimą, reitinguodamos klientus pagal jų
santykinę vertę įmonei per laiko tarpą. Derinant įmonės bendravimą su
klientu, tokie reitingai duoda apčiuopiamą naudą. Negalima kliento vertės
skaičiuoti remiantis vieninteliu rodikliu – taip besielgiančios bendrovės
rizikuoja klientui pateikti netinkamus pasiūlymus, kas atveda prie
mažėjančio kliento pasitenkinimo – o neretai gali ir paskatinti klientą
pereiti pas konkurentus. Klientų vertės analize būtina naudotis mėginant
diferencijuoti klientų aptarnavimo lygį ir formą.
Kanalų optimizavimas – šios taktikos esmę sudaro „tinkamo kanalo
pasirinkimas“, t.y., perdavimas tinkamo pasiūlymo tinkamam klientui
tinkamu metu bei tinkamiausiu būdu.

Pavyzdžiui, bendraudami su banku klientai vis dažniau gali parinkti jiems
patogiausią priemonę – telefoną, internetą, bankomatą, tradicinį filialą, o
kai kurie jau ir asmeninius finansinius patarėjus.(3, 9)

2. Ryšių su klientais valdymo sistemų architektūra

Išsiaiškinus, kas yra ryšių su klientais valdymo sistema, kokia ji gali
būti bei ką daryti, galime toliau gilintis į jos esmę. Sekantis žingsnis
būtų susipažinti su ryšių su klientais valdymo sistemos architektūra,
kadangi būtent ji apsprendžia kaip gerai CRM sistema galės patenkinti
verslo lūkesčius, automatizuoti procesus bei pateikti 360 laipsnių vaizdą
apie klientus bei kaip lengvai ji bus integruota su jau egzistuojančiomis
sistemomis. Tam, kad būtų sukurta ryšių su klientais valdymo sistema viskas
– technologija, duomenys bei uždaviniai (ang. Data and Applications),
paslaugos ir žmonės turi būti apjungti į vieningą visumą. Projektuojant
CRM sistemos architektūrą yra išskiriamos dvi projektavimo stadijos:
Pirmoji stadija – principais paremtos konceptualios, nepriklausomos nuo
technologijų architektūros sukūrimas, kur didžiausias dėmesys yra skiriamas
funkciniams komponentams ir sąveikai tarp jų.
Ši fazė leidžia suprasti pagrindinius projektavimo principus. Šie principai
leidžia suprasti bei pateikia tam tikrus rėmus, direktyvas technologijų
panaudojimui. Čia taip pat naudojant įvairius atskleidimo mechanizmus (ang.
Discovery mechanisms) apibrėžiama streteginė sąveikos su klientu vizija.
Antroji stadija– tai techninės bei fizinės ryšių su klientais valdymo
sistemos architektūros sukūrimas, kuri pateikia rekomendacijas ir sprendimo
metodologijas koncepcinės architektūros faktiniam išsidėstymui. (12)
Tam, kad detaliau išanalizuotume ryšių su klientais valdymo sistemos
architektūrą galime išsikelti tokius pagrindinius klausimus:

• Kokie yra architektūros vertinimos kriterijai?

• Kokia yra CRM sistemos architektūros struktūra?

• Kokie yra pagrindiniai architektūrų tipai?
Be to, tam, kad geriau suprastume architektūrų skirtumus pravartų palyginti
jau esamų ir klientams siūlomų produktų architektūras. Taigi, pradėkime nuo
pagrindinių reikalavimų ryšių su klientais valdymo sistemų architektūrai.

2.1 Architektūros vertinimo kriterijai

Šiandieniniai IT kūrėjai prieš pradėdami kurti CRM sistemos architektūrą ne
tik turi remtis CRM vertės grandine (žr. 1 Priedą), bet ir atkreipti dėmėsį
į tai kaip ji bus vertinama, taigi kokius kriterijus architektūra privalo
tenkinti. O pagrindiniai kriterijai yra tokie:
Aplinka ( ang. Environments) – tai paprasčiausias architektinis kriterijus,
elementariausias diferenciatorius, pagal kurį lengviausiai galima
pasirinkti tam tikrą architektūrą. Svarbiausios aplinkos yra serverių
platformos bei duomenų bazės. Esminis dalykas – kad CRM sistema veiktų jau
egzistuojančiose įmonėje aplinkose.
Organizacija (ang. Organization) – tai architektūros pagrindiniai
komponentai, tarp jų esantys interfeisai bei naudojami protokolai
komunikacijai. Šiuo kriterijumi vertinamas architektūros galimumo,
keičiamumo (ang. Scalability) bei valdymo galimybės.
Infrastruktūra (ang. Infrastructure) – tai sisteminio lygio paslaugos, kaip
bazinis susidorojimas su užklausa, maršrutizavimas ir tvarkymas (ang.
Dispatching), proceso ir transakcijų valdymas, atminties valdymas ir
daugybė kitų, kurios yra reikalingos deramam CRM veikmui.
Struktūra ( ang. Structure) – čia kalbama apie pagrindinius komponentus,
kaip ir iš ko jie yra suprojektuoti. Šis kriterijus leidžia įvertinti
integralumą, papildomų resursų įdiegimui poreikį, palaikymo lygį.
Dažniausia struktūra nusakoma duomenų modeliu bei programų logika.
Personalizacija (ang. Customization) – šio kriterijaus tenkinimas yra
būtinas, norint įkūnyti verslo procesą, verslo jauseną bei kompanijų
informacinę struktūrą.
Integracija (ang. Integration) – tai architektūros suderinamumo su
vidinėmis bei išorinėmis verslo sistemomis vertinimo kriterijus.(13)

2.2 Apibendrinta CRM sistemų architektūra

Ryšių su klientais valdymo sistemų architektūra gali būti kompleksiškesnė,
bet tam, kad geriau apžvelgti komponentus ir suprasti visą struktūrą
vertėtų panagrinėkime kiek įmanoma detaliau. CRM architektūros struktūra
pateikiama 2 paveiksle, kitame puslapyje:

Transakcijų duomenys

2 pav. CRM architektūros struktūra (14)

Transakcijų duomenys. Visa CRM architektūra prasideda pačiame viršuje – ten
kur yra surenkami transakcijų duomenys iš įvairių sąlyčio taškų. Duomenys
turi būti užfiksuojami skirtingose DB kiekvienam sąlyčio taškui. Duomenų
reikia surinkti kaip įmanoma daugiau, nes jie pasitarnaus kaip pagrindas
tolimesnei personalizacijai ir prisitaikymui prie kliento.
Klientų duomenų saugykla. Klientų duomenų saugykla ( ang. Customer Data
Warehouse) – tai lyg analitins CRM architektūros stuburas. Transakcijų
duomenys iš įvairių sąlyčio taškų yra transformuojami ir patalpinami į
duomenų saugyklą. Čia duomenys yra papildomi kliento demografiniais
duomenimis ir paruošiami analizei.
Analitinis procesas. Kai tik duomenys būna paruošti duomenų saugykloje,
galima atlikti analizę pačiais įvairiausiais pjūviais. Galima pasižiūrėti
kada vartotojas ruošiasi atlikti sekantį pirkimą (ang. propensity-to-buy-
analysis), koks sekantis produktas ar paslauga galėtų būti tinkamiausias
vartotojui (ang. product affinity analysis), kokiame kliento gyvavimo ciklo
lygmenyje yra konkretus vartotojas (angl. customer life time value
scoring), kada vartotojas gali atsisakyti įmonės teikiamų paslaugų ir
“perbėgti” pas konkurentus (angl. churn analysis). Šios analizės atliekamos
analitinių įrankių pagalba ir jos turi būti atliekamos reguliariai ir taip
plėtoti kliento profilį.
Klientų profilių duomenų bazė. Klientų profilių DB laikomas nuolat
atnaujinamas kiekvieno kliento portretas, kuris vėliau pasitarnauja kaip
pagrindas, pagal kurį yra atliekama personalizacija kiekvienam klientui.
Kiekvienas įrašas į kliento profilių DB yra charakterizuojamas tam tikru
rinkinių esminių atributų. Jie gali būti demografiniai, kaip amžius,
adresas, asmeniniai pomėgiai arba gauti iš analitinio proceso, kaip
polinkis atsakyti į pasiūlymą ir pan. Bendrai, kliento profilio įraše turi
būti visa informacija, reikalinga Taisyklių įrenginiui suformuluoti
pasiūlymą klientui.
Taisyklių įrenginys ir Kanalų programinė įranga.Taisyklių įrenginys (ang.
Rules Engine) yra turinio „gamintojas“ CRM sistemoje. Jis remdamasis
kliento profilio informacija nusprendžia, ką daryti.Taisyklių įrenginys ir
kanalų programinė įranga dirbdamos kartu pateikia klientui personalizuotą
pasiūlymą kiekviename kanale. Trumpai pažvelkime, kaip tai funkcionuoja.
Tinklo serveris siunčia kliento indentifikacijos informaciją į
personalizacijos įrenginį (ang. Personalization engine) , o šis susisiekia
su Taisyklių įrenginiu, kuris pasinaudodamas gauta informacija prieina prie
kliento profilio. Remdamasis atributais kliento profilyje Taisyklių
įrenginys „pasakys“ Personalizacios įrenginiui kokį personalizuotą turinį
pateikti klientui.
Taisyklių įrenginys privalo būti dinamiškas ir lankstus kliento profilio
pokyčiams bei remtis analitiniais rezultatais. Be to, jis turi nuolat
vystytis bei naudoti analizės modeliais, tam kad išvestų skirtingą turinį
bei pasiūlymus bei būti objektiškai orientuotas. Jam yra reikalinga
platforma, kaip J2EE (ang. Java 2 Enterprise Edition), CORBA ar pan., nes
tinklo personalizacijos įrankiai ar skambučių centrų programinė įranga yra
tik pristatymo mechanizmai.
Kai jau yra pateiktas personalizuotas pasiūlymas arba personalizuotas
turinys pristatytas vienu iš kanalų, kliento atsakymas ir sąveika su
turiniu pabaigia šį ciklą. Sąveika virsta duomenų transakcija, kuri papildo
iš naujo klientų duomenų saugyklą ir personalizacijos procesas prasideda iš
naujo. (14, 15)

2.3 Architektūrų tipai

Dažniausiai CRM architektūros yra suskirstomos į dvi dideles grupes – tai į
duomenis orientuotos architektūros ir į paslaugas orientuotos
architektūros.
Į Duomenis orientuota architektūra (ang. DAO – Data-Oriented Architecture)
buvo kuriama pačiame CRM sistemų „priešaušryje“, o dabar yra pasirenkama
labai retai, nes jos esmę sudaro daugybė fizinių duomenų bazių, kurių
išlaikymo kaštai yra labai dideli, o atskiros duomenų bazės yra
nekompleksiškos bei prastai veikiančios. Be to, šio tipo architektūra yra
labai nelaksti, sunkiai integruojama ir negalinti patenkinti vis didėjančių
poeikių. Todėl dabar nuo DAO yra pereinama prie SAO, t.y., prie į
Paslaugas orientuotos architektūros (ang. SAO – Sevice-Oriented
Architecture), kaip tai parodyta 3 pav.

3 pav. Perėjimas nuo į duomenis orientuotos architektūros prie į paslaugas
orientuotos architektūros (4)

Į paslaugas orientuota architektūra įgalina sistemą pateikti kaip seriją
interfeisų, kurie yra „prikabinti“ prie konkretaus komponento ir
interfeiso standartų. Ji palaiko sudėtinius paslaugų sąryšius su daugeliu
lygių. Nors į Paslaugas orientuota architektūra ir buvo geriausia bei
lankščiausia, bet dėl standartų ir specializuotų įrankių trūkumo, ši
architektūra negalėjo patenkinti labiau techniškai orientuotų projektų,
teikiančių interneto standartais paremtas paslaugas. Čia į pagalba ateina
nauja į Paslaugas orientuotos architektūros atšaka, tai į Tinklines
paslaugas orientuota architektūra (ang. Web Services Orientied
architecture) arba tiesiog Tinklo architektūra, kurios pagrindinis
privalumas yra tas kad ji įgalina realaus laiko transakcijas, garantuoja
pigų ir greitą duomenų rinkimą bei kolaboratyvų planavimą. Supaprastintas
pavyzdys, puikiai atspindintis šią architektūrą, pateikiamas 1 priede.
Tokia architektūra, įgalinanti tiesioginę rinkodarą, kuri dabar tapo
vyraujanti ir todėl planuojama, kad ateityje ji išstums visas kitas, iki
tol buvusias architektūras. Tačiau ir ši architektūra, kaip ir visos kitos
architektūros, be technologijų neegzistuotų. Todėl dabar trumpai apžvelkime
būtinas technologijas.(4, 8)

2.4 Architektūros realizavimo technologinės priemonės

Kadangi ateities vizija yra siejama su Tinkline architektūra, tai dėmesys
bus skiriamas daugiau būtent šiai architektūrai esminėms technologijoms.
Jos yra tokios:
Tinklo serveris – Pagrindinė tinklo serverio funkcija yra kliento užklausos
vydymas, tačiau jis dar gali atlikti ir kitokias funkcijas, pavyzdžiui,
reguliuoti priėjimą (kas gali ir kas negali naudotis tam tikromis
direktorijomis ir bylomis), gali analizuoti pagrindines vartotojų
charakteristikas (kokia naršykle naudojamasi, kokio turinio informacija
domimasi).
Uždavinių serveris (eng. Application Server) yra klasikinė programinė
įranga, supaprastinanti ryšį tarp atskirų sistemos dalių (eng. Middleware),
kuri dirba su įvairiais informacijos šaltiniais. Tai programinės įrangos
platforma, susiejanti varotojus su informacijos šaltiniu, kuriuo
paparastai būna Duomeų Bazė. (18)
Duomenų bazė – tai sistemos informacijos šaltinis, kur saugomi visi
duomenys apie klientą.
Duomenų saugykla – pridėtinė duomenų bazė, skirta paremti analizės vykdymą
tinkle bei kitus galutinio vartotojo veiksmus, kaip pavyzdžiui, ataskaitų
generavimas, užklausų vykdymas ar grafinės informacijos išvedimas.
Analitiniai įrankiai – skirti analizuoti turimiems duomenims. Jie yra
tokie: duomenų gavyba (ang. Data Mining), tiesioginis analitinis duomenų
apdorojimas (ang. OLAP – On-line Analytical processing) ir žinių paieška
duomenų bazėse (ang. KDD – Knowledge Discovery in Databases).
Saugūs protokolai – tai yra taisyklių ir procedūrų rinkinys, kuris valdo
duomenų perdavimą. Svarbiausi saugūs protokolai CRM užtikrinti yra šie: SSL
(eng. Secure Sockets Layer), SET (eng. Secure Electronic Transaction), S-
HTTP (eng. Secure HTTP), IPsec (eng. Internet Protocol security), PCT (eng.
Privat Communications Technology), TSL (eng. Transport Layer Security).
Dažniausiai yra vartojami SSL bei SET protokolai. (5)
Programavimo kalbos – tai dažniausia SGML (eng. Standart Graphic Markup
Language) poaibiai, kaip HTML bei XML, arba evoliucinė programavimo kalba
JAVA.
Be šių, išvardintųjų, taip pat yra būtina Operacinė sistema (pvz.
„Microsoft Windows 2000“,aukštesnio lygio sistemoms – UNIX), serverių
tinklas (dažniausia tai n-lygių į serverį orientuotas tinklas) bei severių
komponentai. (8)

2.5 Esamų sisteminių produktų architektūrų palyginimas

Tam, kad pilnai išanalizuotume galimas architektūras, būtina paanalizuoti
ir palyginti pagrindinių gamintojų siūlomas architektūras, nes jie gali
gaminti produktus su savitomis, izoliuotomis architektūromis, kartais net
apeinant ar nepaisant tam tikrų standartų. Skirtingų gamintojų essamų
produktų architektūros pateiktos 1 lentelėje:
1 lentelė. Esamų produktų architektūrų palyginimas
|Gamintojas |Klientas |Serveris |Duomenys |
|Siebel |„Protingas |Apletai generuojami |Fizinė |
| |tinklas“(ang. |C++, veikia tik savo |operacinė DB, |
| |SmartWeb) – TC ( |uždavinių serveryje. |duomenų centras|
| |ang. Thin |Skriptas VM.Veikia |(ang. Data |
| |Client),JavaScript |ant Microsoft |Mart), |
| |įrankiai ir |NT/2000, IBM AIX, Sun|Metaduomenų |
| |apletai. Siūlo savo|Solaris serverių |modelis ir |
| |portalą, bet veikia|platformų. |nauja |
| |ir su kitais. V.8 | |pagrindinių |
| |jau siūloma .NET | |klientų DB. |
| |aplinka | | |
|SAP |Kliento serveris |Apletai ABAP, kai |Fizinė |
| |SAP GUI. Siūlo savo|kurie J2EE, |operacinė DB ir|
| |portalą ir neveikia|konfigūruojama su |verso |
| |su kitais |ABAP ir J2EE. Veikia |informacijos |
| |portalais. |su SAP WAS uždavinių |saugykla kuria |
| | |serveriu. Gali veikti|kolaboratyvų |
| | |su Sun Solaris, |duom. valdymą |
| | |Microsoft NT/2000 | |
|ORACLE |Formos, Java VM, |Ap. J2EE, „Java |Fizinė |
| |apletai.Neveikia |Servlets“. |operacinė DB, |
| |ant kitų portalų |Konfigūruojama su |TCA duomenų |
| | |formomis,PL/SQL. |modelis, |
| | |Veikia tik Oracle |Logika DB |
| | |9iAS užd.serveryje |trigeriuose ir |
| | | |PL/SQL |
|Onyx |ActiveX arba |Ap. C++, DNA/Com+ |Fizinė |
| |Microsoft Client |Objektinis modelis, |operacinė DB |
| |serveris, |Konfigūruojama su VB | |
| |„Enterprise studio“|skrimtu, veikia tik | |
| | |savo užd. serveryje | |
|PeopleSoft |TC, JSP (ang. Java |Ap. C++, „Tuxedo“, |Fizinė |
| |Server Pages), |J2EE, Konfigūruojama |operacinė DB |
| |Siūlo savo portalą,|su „People Tools“, |bei duomenų |
| |bet suderinamas ir |veikia ant BEA+Tuxedo|saugykla gerai |
| |su kitais. |arba J2EE ar |suderinamos su |
| | |Microsoft NT/2000 |kitom klientų |
| | |serverių platformų. |valdymo DB |
|E.piphany |Siauras klientas |Ap. J2EE – |Virtualių |
| |tik per JSP, |generuojami iš |duomenų modelis|
| |portalas |Metaduomenų. Gali |skirtas |
| |nesiūlomas, veikia |veikti ant BEA, IBM |operaciniam |
| |su kitomis |J2EE ir Microsoft |CRM. |
| |Metaduomenų |NT/2000 uždavinių |Metaduomenų |
| |varomosiomis |serverių |„Mepingas“ bei |
| |priemonėmis | |Duomenų centras|
| | | |analitiniams |
| | | |procesams |

Pažvelgę į lentelę galima išvysti tendencijas, kad pamažu skirtingų
gamintojų architektūros ima venodėti, kadangi dabar įmonės dažniausia nori
integruoti CRM sistemą į jau įmonėje egzistuojančių sistemų visumą. Ko
gero, būtent tai suprasdami, gamintojai pradėjo venodinti architektūras.
Žiūrint labai glaustame lygyje iš lentelėje pateiktos informacijos galima
palyginti pateiktų gamintojų architektūras pagal architektūros vertinimo
kriterijus, pateiktus 2.1 skyriuje.
Žvelgiant pagal aplinkos kriterijų, būtina, kad architektūros palaikytų
labiausiai paplitusias serverių platformas, kaip „Microsoft NT/2000“,
„Microsoft SQL“, „Sun Solaris Server“ bei „Oracle Sever“ duomenų bazę.
Matome, kad visos architektūros šį kriterijų tenkina, išskyrus „Oracle“ bei
„Onyx“, kurios veikia tik savose platformose. Didesnių problemų tai gali
sukelti nebent į severius orientuotai „Onyx“ architektūrai, nes „Oracle“
standartai yra žymiai plačiau paplitę. Dėl šios priežasties „Onyx“ žada
pereiti prie populeresnės „Microsoft .NET“ platformos.
Žiūrint pagal organizacinį kriterijų, visos architektūros turi tokius
komponentus: Klientą, Uždavinių serverį bei Duomenų bazę. Skirtumai
atsiranda kliento organizavime. „E.piphany“, „Oracle“ ir „Siebel“
architektūros turi atskirus „ single-user“ tinklo serverius, kurie įgalina
suteikti klientui tą patį vartotojo vardą (ang. UI – User Indentification)
, kokiu kanalu jis besinaudotų. O štai „PeopleSoft“ ir „SAP“ architektūrose
uždavinių serveriai įdiegti taip, kad Tinklo UI ir darbalaukio (ang.
Desktop) UI nesutampa. Pranašumas – turtingumas ir interaktyvumas.
Pagal infrastruktūros kriterijų pagrindiniai pateiktų architektūrų
skirtumai slypi infrastruktūrų diegimo principuose. Pagrindinis pažangumo
rodiklis čia – portalo turėjimas, kuris suteikia papildomą uždavinių
serverio infrastruktūrą, kurios pagalba vartotojas gali pasiekti eilę
įvairiausių duomenų. Portalo neturi tik „Onyx“, o visos kitos architektūros
siūlo savo, arba yra suderinamos su kitais portalais. Portalai daugumoje
panašūs, skiriasi tik „SAP“ portalas, kuris yra lakstesnis ir galingesnis
nei kiti.
Lyginant pagal struktūros kriterijų, galima pastebėti du panašumus ir daug
skirtumų. Abu panašumai yra duomenų struktūroje – tai bendrame duomenų
modelyje ir kliento duomenų modelyje. Visos architektūros turi lankščius ir
vietisus modelius. Skirtumai pasireiškia Metaduomenyse, programų logikoje
bei kanalų teikiamose paslaugose. „PeopleSoft“ , „Siebel“ ir
„E.piphany“architektūros yra pilnai paremtos metaduomenimis, o „SAP“
„Oracle“ – ne pilnai. Štai „SAP“ programų logika yra labiausia objektiškai
orientuota iš visų, o „Siebel“ programų logika paremta patentuotu
objektiniu modeliu BOM (ang. Business Object Model). „PeopleSoft“
architektūros programų logika paremta modulinėmis procedūromis.
Pagal personalizacijos kriterijų pranašumą turi „PeopleSoft“ ir „Siebel“
„E.piphany“ nes yra pilnai paremtos metaduomenimis.
Ir paanalizavus pagal paskutinį, integracijos kriterijų , matome, kad nei
viena architektūra dar neturi išsamaus (ang. Comprehensive) įdiegimo, nes
nors visos palaiko HTTP (ang. Hyper Text Markup Languag ) , XML(ang.
Extensible Markup Language) ir SOAP (ang. Simple Object Access Protocol),
tačiau nė viena nepalaiko UDDI ( ang. Universal Description, Discovery and
Integration) ir WSDL (ang. Web Services Description Language) standartų.
Apibendrinant galima teigti, kad „PeopleSoft“ architektūra yra lengviausiai
integruojama nei kitos, nes ji siūlo plačiausią spektrą integravimo būdų
(sinchroninį ir asinchroninį, tinklinį, Java bei daugelį kitų).
„PeopleSoft“ ir „SAP“ architektūros yra ypač atviros, o „Oracle“ „Onyx“ ir
„Siebel“ ne tokios atviros, jos turi savitus interfeisus, dėl to jų
suderinamumas truputi problemiškesnis.
(4, 17, 18)

3. Ryšių su klientais valdymo sistemos kūrimas

Dabar jau galime pradėti kalbėti apie sistemos diegimą. Programinės įrangos
bendrovės, siūlančios “įdiegti CRM sistmą per 60 dienų” iš tiesų rengiasi
palikti įmonę su nenaudojamos programinės įrangos krūva – o pati sprukti
pro duris su pinigais, kadangi ryšių su klientais valdymo sistemos diegimas
iš tikrųjų yra ilgas ir nuodugnus procesas, sukuriantis įmonei būtent jai
vienai tinkamą sistemą.

CRM sistemos diegimą galima suskirstyti į dvi dideles dalis: planavimą ir
realizavimą. Sistemos planavime dalyvauja ir pati įmonė ir specialistai, o
antrojoje dalyje – tik specialistai. Pirmoji dalis dar gali būti įvardinta,
kaip saugios aplinkos sukūrimas ir yra būtina prieš pradedant bet kokius
diegimo darbus. O antroji gali apibrėžiama, kaip realizavimo proceso
valdymas, kur visą realizavimo procesą logiškai galima suskirstyti į
keturias stadijas, kurios yra tokios:

• Reikalavimų analizė (ang. Requirements Analysis);

• Personalizacija ir prototipavimas ( ang. Personalisation and

Prototyping);

• Dislokavimas (ang. Deployment);

• Patirinimas po įdiegimo (ang. Post-Implementation Audit). (20)

3.1 Saugios aplinkos sukūrimas

Prieš pradėdant ryšių su klientais valdymo sistemos kūrimą (ang.
Implementation), įmonė pati privalo žengti keletą žingsnių, kad sukurtų
saugią aplinką diegimui. Visos CRM sistemas sėkmingai įsidiegusios
didžiausios pasaulio kompanijos pradėjo būtent nuo to.
Visų pirma, prieš imantis ryšių su klientais valdymo sistemos kūrimo bei
diegimo, verta žengti pora žingsnių atgal ir apžvelgti padėtį iš šalies.
Svarbiausias dalykas yra projekto ribų apibrėžimas ir ryšių su klientais
valdymo verslo plano sudarymas, nes CRM programos tikslai turi remtis
realia padėtimi. Įmonė privalo pažvelgusi iš šalies įvertinti savo
stipriąsias ir silpnąsias puses, studijuojant rinką surinkti kaip įmanoma
daugiau informacijos apie savo klientus, konkurentus ir rinkos tendecijas.
Pasiremiant surinkta informacija, atrasti būdus, kaip galima sukurti
papildomą vertę savo klientams ir pačiai įmonei. Ir galiausiai, kadangi
ryšių su klientais valdymo sistemos kūrimas yra
ilgas procesas, privalu pasirinkti kuriuos žingsnius žengti pirma, o
kuriuos – vėliau. Kai visa tai atlikta, įmonė privalo užduoti sau tokius
pagridinius klausimus:
1. Ar nustatytas ir patvirtintas projekto įgyvendinimui skirtas biudžetas?
Nėra prasmės planuoti CRM diegimo, jei nėra tam lėšų.
2. Ar atrastos ryšių su klientais valdymo sistemos diegimui trukdančios
organizacinės arba politinės kliūtys? Reikia iš anksto suplanuoti, ką
daryti, kilus neaiškumams dėl projekto priklausomybės arba dėl nesutarimų,
kurioms sistemos funkcijoms reikia skirti daugiausia dėmesio.

3. Kas bus pagrindinis ryšių su klientais valdymo sistemos kūrimo bei
diegimo projekto rėmėjas? Ruošiantis pradėti ryšių su klientais valdymo
sistemos projektavimą ir diegimą, turi būti aišku, kas prisiėmė “projekto
sponsoriaus” vaidmenį, nes Jis turės dalyvauti apibrėžiant ir tvirtinant
reikalavimus, nustatant sėkmės matus.

4. Ar apibrėžti projekto sėkmės matai? Jie reikalingi tam, kad būtų galima
įvertinti įdiegimo sėkmingumą.

5. Kokie bus duomenų šaltiniai? Nepakanka žinoti, kokių duomenų apie
klientus reikės kuriamai sistemai – būtina aiškiai nustatyti, iš kur jie
bus gaunami. Būtina taip pat apibrėžti, kokio lygio (asmens, namų ūkio ar
kt.) duomenys bus naudojami.

6. Ar įmonės viduje sutarta dėl norimos klientų elgsenos? Ar aišku, kokiais
būdais įmonė skatins tą norimą klientų elgseną?

7. Ar visi įmonės funkciniai padaliniai vienodai supranta “kliento” sąvoką?
Skirti įmonės skyriai klietą gali suvokti skirtingai.
Jeigu atlikus išvardintus žingsnius bei atsakius į pateiktus klausimus
įmonė neatsisako minties įsigyti CRM sistemą, tuomet diegimas yra
perduodamas į specialistų rankas. (6)

3.2 Realizavimo proceso valdymas

Įvairūs šaltiniai bei įvairūs CRM sistemų kūrėjai siūlo įvairias diegimo
proceso valdymo strategijas (dažniausia tai trijų fazių strategijos). Šiame
darbe aš aptarsiu otimaliausią – keturių fazių diegimo proceso valdymo
strategiją, kaip pavaizduota 4 pav.:

Tam, kad nuodugniai išsiaiškintume diegimo procesą, reikėtų detaliai
apžvelgti šias fazes. Taigi, pradėkime nuo pirmosios.

3.2.1 Pirma stadija – reikalavimų analizė

Ši stadija prasideda nuo verslo bei projekto tikslų nustatymo ir
patvirtinimo. Tuomet yra ypač nuodugniai išanalizuojami įmonės verslo
procesai, o gauti rezultatai yra panaudojami susieti juos su reikalinga
programine įranga. Atlikus šiuos būtinus veiksmus sukuriami planai
konkrečioms diegimo dalims. Ši stadija yra pabaigiama susitarimu
projektuoti bei planų rinkinio ir biudžeto patvirtinimu. Stadija susideda
iš tokių darbų:

• Tikslų, galimybių bei barjerų nustatymas;

• Verslo, pardavimų bei klientų aptarnavimo procesų išanalizavimas ir

dokumentavimas;

• Verslo reikalavimų ir procesų susiejimas su CRM programine įranga;

• Reikalavimų bei reikalingos dukumentacijos, dokumentų formatų bei

laiko sąnaudų indentifikavimas;

• Spragų indentifikacija ir Sprendimo pasiūlymo rengimas, užtikrinantis

kliento pritarimą;

• Sąryšio su kitomis sistemomis indetifikavimas ir dokumentavimas, jų

tarpusavio sąveikos nustatymas;

• Nutolusių vartotojų sinhronizacijos ir priėjimo indentifikavimas;

• Reikalingų personalizacijų dokumentavimas bei susitarimas dėl

interfeiso projektavimo;

• Esamos techninės aplinkos įvertinimas, pirkimo/atnaujinimo

rekomendacijų parengimas;

• Informacijos rinkimas atsižvelgiant į duomenų virsmus;

• Susitarimas dėl galutinių vartotojų apmokymų apimties bei informacijos

pateikimo formatų;

• Testavimo scenarijaus ir reikalavimų dokumentavimas;

• Palaikymo reikalavimų po įdiegimo nustatymas;

• Projekto dokumentacijos, galutinio projekto plano bei biudžeto

paruošimas ir pristatymas.
Be to, ši stadija duoda ir papildomą naudą. Kadangi Analizės metu
akivaizdžiai aprašomi pagrindiniai verslo procesai, specialistai gali
pasiūlyti pagerinti tam tikras procedūras. Taip galima patobulinti verslo 
procesus, o to pasekmė – laiko ir pinigų ekonomija. (6, 21, 22)

3.2.2 Antra stadija – Personalizacija ir Prototipavimas

Šios stadijos tikslas yra instaliuoti reikalingą programinę įrangą bei
personalizuoti ją taip, kad atitiktų kliento reikalavimus. Šios stadijos
metu taip pat atliekamas testavimas, duomenų migracijos nustatymas bei
integracija su egzistuojančiomis įmonėje programinės įrangos sistemomis.
Taigi, šios stadijos metu yra pristatoma visapusiška bei pilna ryšių su
klientais valdymo sistema, kuri turėtų tenkinti visus verslo įmonės
keliamus reikalavimus. Antrosios fazės darbai yra tokie:

• Techninės įrangos, duomenų bazių bei komunikacijų sukūrimas;

• Programinės įrangos instaliavimas, organizacijos struktūros išbaigimas

bei saugumo parametrų nustatymas,

• Vartotojo interfeiso personalizacijų, lentelių užpildymo bei procesų

išbaigimas;

• Ataskaitų ir reikalavimų parengimas;

• Reikalingos integracijos programavimas;

• Programinės įrangos aplikacijų testavimas;

• Duomenų migracijos įrankių ir rezultatų testavimas;

• Nuotolinio priėjimo ir sinchronizacijos testavimas;

• Rastų nesklandumų sutvarkymas;

• Galutinių vartotojų apmokymų medžiagos parengimas;

• Priėmimo scenarijų bei dokumentacijos parengimas;
Kai ši stadija yra pabaigiama, tuomet pereinama jau prie priešpaskurinės –
Dislokavimo Fazės.(20)

3.2.3 Trečia stadija – Dislokavimas

Šios stadijos metu, programinės įrangos aplikacijos yra perkeliamos į
gamybos aplinką, taip pat apmokomi galutiniai vartotojai, į sistemą yra
perkeliama visi surinkti duomenys ir užpildomos visos priėmimo formos.
Šioje stadijoje atliekami darbai yra tokie:

• Galutinių vartotojų apmokymas;

• Vidinių darbinių (ang. Operational) procedūrų revizija;

• Vartotojų tinkamumo darbui su sistema patikrinimo atlikimas;

• Veikimo/neveikimo (ang. Go/No-Go) sprendimo padarymas bei perėjimo

prie sistemos naudojimo plano paruošimas;

• Sistemos palaikymo plano sukūrimas, supažindinimas su palaikymo

komanda bei mechanizmais;

• Galutinis duomenų perkėlimas į sistemą bei jų sutvarkymas;

• Perėjimo prie sistemos naudojimo darbų atlikimas;

• Priežiūros po perėjimo atlikimas, maždaug dvi savaites.
Po šios stadijos įmonė jau disponuoja būtent jai sukurta ryšių su klientai
svaldymo sistema, bet tam, kad diegimas būtų pilnai išbaigtas, būtina dar
viena stadija.(20)

3.2.4 Ketvirta stadija – patirinimas po įdiegimo

Ši stadija paprastai yra atliekama po šešiasdešimties – devynesdešimties
dienų po sistemos paleidimo datos. Šioje paskutinėje fazėje yra atliekami
tokie darbai:

• Sistemos naudojimo patikrinimo atlikimas;

• Papildomų galimybių patobulinimams indentifikavimas;

• Plano parengimas;

• Susitikimas su įmonės vadovais bei naujų atradimų ir rekomendacijų

pateikimas.
Po šios stadijos sistema jau yr apilnai įdiegta bei pasirengusi darbui.
Tačiau dažniausia įmonė nepasitenkina tik šia viena sistema, nes įmonės
savo veiklai optimizuoti beveik visuomet turi įmonės informacinę sistemą,
todėl būtų pravartu aptarti CRM sistemos integraciją į įmonės informacinę
sistemą bei vietą joje. (20)

4. CRM ir esamų informacinių sistemų integracija

Nors CRM sistema paprastai apjungia informaciją apie klientą, kuri yra
reikalingą rinkodarai, pardavimui bei ryšiams su klientais, tačiau dažnai
tai nėra pakankama informacija efektyviai sąveikai su klientu bei prasmingų
analitinių ataskaitų parengimui. Tam gali prireikti tam tikros informacijos
iš apskaitos sistemos ar bet kokios kitos įmonės informacinės sistemos.
Vienintelė išeitis – sistemų integracija, kuri užtikrina duomenų ir procesų
mainus geresniam verslo darbų atlikimui. Integracijos pagalba atskiros
sistemos yra sujungiamos į vieną bendrai funkcionuojančią visumą. Kad
integracija būtų galima, būtina apbrėžti, kurie sistemų duomenys bei
procesai bus naudojami mainams tarp sistemų.
Seniau integracijos buvo vengiama, nes tai buvo sunkus ir brangus, pagal
„Meta Group“atliktus tyrimus kainuojantis net 1/3 visos CRM sistemos
diegimo sumos, o kartai ir sunkai pagrindžiamas procesas. Dabar patogios
metodologijos, lanksčios architektūros bei įvairių įrankių visumos pagalba
integracija tampa jau pasiekiamu tikslu. Geriausia sistemų integraciją
atlikti stadijomis, kaip pavaizduota 2 Priede.
Sistemos yra integruojamos pagal tam tikrus metodus, o integracija turi
tenkinti tam tikrus reikalavimus, kuriuos dabar ir apžvelgsime. (25, 26)

4.1 Integracijos reikalavimai

Pakartotinas panaudojimas (ang. Re-Use) – sėkminga integracija turi
užtikrinti pakartotiną funkcijų panaudojimą, kuris leidžia sumažinti kūrimo
kaštus bei užtikrina trumpesnę sistemos integravimo trukmę.
Supaprastinimas (ang. Simplification) – integruojant daug skirtingų
sistemų, reikalingas sprendimo techninis rafinuotumas. Integruota sistema
privalo veikti su skirtingomis techninėmis įrangomis, atrodytų
nesuderinamomis tinklų topologijomis, operacinėmis sistemomis ir pan.,
todėl
norint išvengti nepageidaujamų komplikacijų ir nepaveikti verslo funcijų
būtina maksimaliai supaprastinti integruotą sistemą.
Prisitaikymo galimybės (ang. Scalability) – integracijos proceso
architektūra turi galėti prisitaikyti prie kintančios aplinkos bei
didėjančių reikalavimų.
Valdymo galimybės (ang. Manageability) – integruota sistema privalo būti
lengvai valdoma. Būtina tiksliai apibrėžti galutinės sistemos visas
funkcijas bei veiksmus, o integruotos sistemos valdymas turi būti paremtas
bet kurios kitos iš integruojamų sistemų valdymu.
Saugumas (ang. Security) – turi būti griežtai apibrėžtas priėjimas prie
skirtingų sistemų duomenų bei paslaugų. Turi būti nustatyti saugumo
lygmenys reikalingi duomenų integralumui, priėjimo kontrolei ir
autentifikacijai. Ten kur yra integruojamos ir išorinės sistemos, saugumo
politika (ang. security policy) turi užtikrinti, kad pranešimas buvo
išsiųstas/gautas.
Atstatomumas (ang. Recoverability) – labai svarbu, kad integruotą sistemą
būtų galima atstatyti po gedimų. Atstatymo lygis bei kontrolė privalo būti
paremti verslo reikalavimais.
Plėtros galimybės (ang. Extensibility) – kadangi integruota sistema yra
gyvuojanti esybė, tai ji turi tendenciją plėstis. Naturaliai lanksčios bei
pratęsiamos sistemos sukūrimas yra pagrindinis integracijos
tikslas.Apibrėžti duomenų formatai, sistemų ribos, interfeisai bei aiški
dokumentacija garantuoja greitą ir lengvą sistemos plėtrą.
Naudojimo paprastumas (ang. Ease of Use) – nauja integruota sistemos
architektūra privalo leisti lengvai įdiegti, keisti bei naikinti naujas
paslaugas. Paslaugos turi būti įvardijamos pagal funkcijas, tam kad visam
personalui būtų lengva suprasti ir naudoti.(23)

4.2 Integracijos metodai

Integracija gali būti dviejų tipų: orientuota į duomenis (ang. Data driven)
bei orientuota į procesus (ang. Process driven). Į procesus orientuotuotos
integracija nebus plačiau analizuojama, nes integruojamos sistemos turėtų
būti orientuotos į procesus, o mus domina į duomenis bei informaciją
orientuotos sistemos – informacinės sistemos. Galima trumpai paminėti, kad
į procesus orientuota integracija vyksta DB bei aplikacijų lygmenyje, o
integracijai naudojami tokie produktai, kaip „Geneva Enterprise
Integrators“ ir „Integration Brokers“ bei „Constellar“ siūlomi produktai.

Dabar plačiau paanalizuokime keturis pagrindinius į duomenis orientuotos
integracijos metodus, kurie yra:

• Bylų integracijos metodas;

• Programavimo metodas;

• Tarpinės Programinės įrangos metodas.

4.2.1 Failų integracijos metodas

Bylų integracija (ang. Flat File Integration) – tai yra pats papraščiausias
integracijos būdas. Jis yra tinkamiausias ten, kur nereikalingas realaus
laiko atnaujinimas ( ang. Real-time updating), nors esant poreikiui būtų
galima vykdyti artimą realiam laikui atnaujinimą, bei kur procesai
atnaujinimo metu yra mažai arba visai neparemiami verslo logika. Tai pat,
vienas iš reikalavimų yra, kad duomenų mainų struktūra nebūtų sudėtinga.
Šio metodo pavyzdys galėtų būti toks: CRM sistema kasnakt generuoja
tekstinį failą, kur pažymimi dieną atlikti pakeitimai, o atitinkama įmonės
informacinė sistema jį perskaičiusi galėtų atlikti pakeitimus savo
paskyrose (ang. Accounts).
Šio metodo privalumai yra: reikalingas minimalus programavimas, sistemose
atliekami programinės įrangos atnaujinimai nepaveikia mainų, be to vietoj
bylų įmanomas tarpinės duomenų bazės naudojimas.(22)

4.2.2 (Programavimo) metodas

Programavimo metodas (ang. Custom Programming) – tai metodas,
besiremiantis objektiniu programavimu. Objektiškai orientuotas
programavimas gali būti panaudotas tam, kad suvaldyti komunikaciją tarp
sistemų. Nors šis metodas nereikalauja pirkti jokios papildomos programinės
įrangos, tačiau jis reikalauja daug programavimo. Naudojant šį metodą,
pokyčiai atlikti vienoje sistemoje pastebimi bei tiesiogiai įrašomi kitoje
sistemoje naudojant specialiai suprogramuotus kodus. Šis metodas yra
daugiausia laiko sąnaudų reikalaujantis metodas, palyginus su kitais, nes
jei kuri iš sistemų yra atnaujinama, taip pat gali reikėti atnaujinti
specialų kodą. Programavimo metodą tikslingiausia naudoti, kai duomenų
struktūros yra pernelyg sudėtingos, kad būtų galima pasinaudoti bylų
metodu.(22)

4.2.3 Tarpinės Programinės įrangos metodas

Tarpinės Programinės Įrangos metodas (eng. Middleware) – tai pats
lanksčiausias integracijos metodas, naudojant tokią tarpinę įrangą, kaip
„Microsoft BizTalk” arba “Scribe Integrate”. Tarpinė programinė įranga
valdo duomenų transformavimą, laukų žymėjimą (ang. Field mapping) bei
verslo procesų programavimą, kuris gali būti reikalingas duomenų
pasikeitimo tarp sistemų metu.

Daugelis sistemų turi tarpinės programinės įrangos adapterius, kurie ypač
palengvina komunikaciją. Pastarieji leidžia grynesnę bei paprastesnę
sąveiką tarp sistemų bei tarpinės programinės įrangos. Tarpinės programinės
įrangos metodo naudojimas yra panašus į programavimo metodo, tik naudojant
šį, galima dirbti su daugiau nei dviem DB dialogo tarp sistemų metu.
Tarpinė programinė įranga ypač palengvina programuotojų darbą, adaptoriai
žymiai sumažina programavimo apimtis. Taigi, norint naudoti šį metodą
telieka iškelti klausimą, ar įmonei planuojama nauda kompensuos nemažas
šios programinės įrangos kainas. (22)

4.3 Integruotos sistemos pavyzdys

Aptarus ir išanalizavus Ryšių su klientais valdymo sistemų architektūrą,
diegimą bei integraciją galima pateikti CRM sistemos pavyzdį bei
pasižiūrėti, kaip atrodo integruota informacinė sistema.
Aš pasirinkau paanalizuoti kelionių agentūros „Kelrodis“ integruota
sistemą, nes kelionių agentūroms, aptarnaujančioms daugybę klientų, yra
ypač svarbu turėti integruota informacinę sistemą, kur CRM sistema yra
labai svarbus komponentas.
Taigi, visų pirma detaliau panagrinėkime, kaip veikia Ryšių su klientais
valdymos sistema.

4.3.1 Ryšių su klientais valdymo sistemos pavyzdys

Kadangi ateities architektūra yra laikoma Tinklinė architektūra, todėl
aptariamame pavyzdyje pasirinkau aptarti būtent tokia architektūra paremtos
sistemos veikimą. Aplinka pasirinkta tokia: „Microsoft IIS“ tinklo serverio
platforma, Oracle duomenų bazė bei J2EE standartu paremtas uždavinių
serveris. Be to, analizės paprastumui pasirinktas tik vienas kanalas –
klientas su sistema sąveikauja per interneto puslapį. Toks kanalas
pasirinktas todėl, kad kelionių agentūrai šis kanalas yra vienas
naudingiausių, kadangi jai reikia palaikyti ryšius su labai dideliu klientu
skaičiumi.
Uždavinių serveryje yra spec.įdiegtų servletų (ang. Servlet) – serverio
plėtinių, kurie veikia kaip užklausos/atsakymo mechanizmai, bei perima ir
nukreipia kliento užklausą puslapiui, tam kad būtų prieita prie DB ir
verslo logikos dėka pateiktas dinamiškas turinys atgal į puslapį. J2EE
platforma įgalina lankstų daugelio lygių (ang. Multi-tier) orientuotą į
serverį taikomajį modelį (ang. Application model), o tai reiškia, kad
taikomoji logika yra išskirstyta į komponentus pagal atliekamas funkcijas.
Tokia platforma pasirinkta, nes ji garantuoja lengvą papildomų komponentų
įdiegimą, nesvarbu ar jie būtų specialiai suprojektuoti ar gamintojų
siūlomi bendri paketai, t.y. todėl, kad platforma yra ypač atvira,
nepririšta prie produktų ir taikomųjų programų interfeisų bei
[pic]

5 pav. Ryšių su klientais valdymo sistemos veikimo procesas (8)

Kelionių agentūros klientas nori užsirezervuoti vietą kelionei į Bulgaria
ir pasirenka sau priimtiniausią bendravimo su agentūra kanalą – internetą.
Visą sistemos veikimą galima suskirstyti į septynis žingsnius:

1. Klientas standartiniais metodais, tinklo serverio pagalba priena prie

sistemos internetinio puslapio. Nagrinėjamu atveju jis yra sukurtas

HTML pagalba, ir pasiunčia savo užklausą apie norimą kelionę;

2. Tinklo uždavinių serveris (ang. Application server) perima užklausą ir

nukreipia ją peradresuotojo (ang. Re-director) pagalba puslapio

tvarkyklei (ang. Page Handler), kuri pradeda veikti, aktyvavus

internetinį puslapį.

3. Puslapio tvarkyklė gali pasinauduoti bet kuriais esamais komponentais,

tam kad atliktų visas reikalingas operacijas susijusias su užklausos

įvykdymu. Tam, kad jais pasinaudotų, ji kreipiasi į Verslo logikos

komponentą, kuris atlieka reikalingos informacijos apdorojimą, kaip

pareikalauta, o paskui pateikia informaciją atgal, taigi, yra kaip

jungiamasis komponentas;

4. Verslo logikos komponentas susisiekia su CRM sistemos komponentais,

išoriniais duomenų šaltiniais, anksčiau įdiegtais pritaikymais (ang.

Legacy applications) ir netgi su išorinias paslaugų tiekėjais, tam kad

atliktų pareikalautą darbą. Nagrinėjamu atveju, jis susisiekia su DB

ir ten gauna kliento profilį, pasinaudodamas savo analitiniais

įrankiais išsiaiškina ar klientas turi nuolaidų, koks jo vertės

indeksas ir t.t., tam, kad parinktų atitinkamą pasiūlymą. Susisiekęs

su “Lietuvos avialinijų” duomenų baze jis išsiaiškina ar yra bilietų

pareikalautai datai, o susisiekęs su tarptautine rezervacijų sistema

gauna informaciją apie tai datai galimus viešbučių pasirinkimus.

Tuomet, pasinaudodamas anksčiau įdiegtais pritaikymais jis atlieka

užsakymo formos patvirtinimą bei pirkimo proceso valdymą;

5. Puslapio tvarkyklė, remdamasi informacija gauta iš verslo komponentų,

atnaujina pareikalauto turinio pakeitimus palaikomus tinklo serverio;

6. Kai visa tai atlikta, uždavinių severio vertimų servletas “perskaito”

reikalingą puslapį iš tinklo serverio, apjungia visus reikalingus

turinio pakeitimus ir rezultatą pristato klientui;

7. Klientas gauna statndartinį internetinį puslapį, kuris atrodo lygiai

taip pat, kaip puslapiai statiškose svetainėse, nors jis yra

dinamiškai apdorotas ir personifikuotas specialiai Jam, pagal jo

atliktą užklausą, t.y., pamato specialiai Jam parengtą kelionės

pasiūlymą, kurį patvirtinęs jis atlieka savo norima rezervaciją –

belieka tik sumokėti pingus ir keliauti į Bulgariją. (8 )

4.3.2 CRM sistema informacinėje sistemoje

Integruotą įmonės informacinę sistemą gali sudaryti daugybė apjungtų
sistemų, posistemių, kaip apskaitos, žmogiškųjų resursų, produkcijos
kontrolės bei kitų. Tokios integruotos informacinės sistemos vienu
svarbiausių posistemų dabar jau tampa ir ryšių su klientais valdymo
sistema, o ši integracija turi abipusės naudos. (24)

Kelionių agentūra integruoti savo informacinę sistemą su CRM sistema
pasirinko dėl kelių priežasčių.
Visų pirma, Ryšių su klientais valdymo sistema paverčia informacinę sistemą
orientuotą į klientą, nes leidžia geriau palaikyti ryšius su jais bei
partneriais pasiūlydama žymiai platesnį kanalų pasirinkimą. O tai yra ypač
svarbu į klientus orientuotai kelionių agentūrai „Kelrodis“.
Be to, didesnis kanalų pasirinkimas užtikrina efektyvesnius informacijos
apie produktus (siūlomas paslaugas), klientus, užsakymus ir t.t., mainus.
„Kelrodis“ naudoja šiuos kanalus: „veidas į veidą“ bendravimo, kai klientas
aptarnaujamas konsultanto pačioje agentūroje, telefoninio ryšio, interneto
per pesonalinį kompiuterį, paprasto pašto, elektroninio pašto bei mobilaus
ryšio (trumposios žinutės).
Kita priežastis yra ta, kad klientų valdymo posistemis integruotoje
sistemoje atlieka visas taip vadinamo „Front-office“ – tiesiogiai su
klientu sąveikaujančio biuro funkcijas: klientų valdymą, pritraukimą, visų
kliento pageidavimų kaupimą ir t.t., o visa čia sukaupta informacija yra
efektyviai panaudojama kituose integruotos informacinės sistemos
posistemiuose, kaip pavyzdžiui, užsakymų ir pardavimų orderių formavimui,
kainų korekcijai ar galutinio kelionės paketo konfiguracijai.
Kelionių agentūroje šią „Front-office“ funkciją atlieka kontaktų centras.
Kontaktų centras – tai fizinė ar virtuali darbo vieta, skirta įvairių
klientų pageidavimų įgyvendinimui bei informacijos, gaunamos įvairiais
kanalais kaupimą ir jos teikimą klientui tų pačių kanalų pagalba. Per
kontaktų centrą klientas visais kanalais susisiekia su įmone, taigi tokio
centro turėjimas užtikrina kelionių agentūrai konkurencinį pranašumą. Tokio
centro pavyzdys galėtų būti skambučių centras, kurį turi „Kelrodis“, o jo
veikimo principas pavaizduotas 4 Priede. Kontaktų centro veikimą užtikrina
darbo srautų technologija ( ang. Workflow technology), kuri leidžia
automatizuoti verslo procesus, o tai yra panaudojama sąveikų valdymui tarp
kontaktų centro ir kanalų bei autorizacijai.
Dar viena priežastis yra ta, kad integruota sistema suteikia daug naudos
Ryšių su klientais valdymo sistemai. Įmonės informacinė sistema teikia jai
daug naudingos informacijos, kuri yra panaudojama tam, kad būtų kaip
įmanoma efektyviau atlikta klientų analizė, įvertinta kliento vertė pagal
jo paskutinius pirkimus, taikomos nuolaidos ir pan. Daugiausia naudingos
informacijos suteikia informacinės sistemos Apskaitos posistemis.
Kelionių agentūra taip pat dar turi taip vadinamų papildomų ryšių su
klientais valdymo sistemų (ang. Peripherical CRM systems), kaip CMS (ang.
Content Management System) – turinio valdymo sistemą, naudojama turinio
keitimui ar naikinimui pristatymo kanaluose (paprastai interneto puslapyje)
bei GIS (ang. Geographic Information Systems), kurios įgalina geografiškai
susietos informacijos valdymą.
Ryšių su klientais sistemą bei esamą informacinę sistemą (su prieiga prie
išorinių sistemų) kelionių agentūra „Kelrodis“ pasirinko integruoti
tarpinės programinės įrangos pagalba, kadangi informacinės sistemos
posistemiai, kaip apskaitos, personalo ir t.t., veikia ant skirtingų
platformų bei operacinių sistemų, o šis metodas kaip tik tam yra ypač
tinkamas. Buvo renkamasi iš trijų produktų: „Oracle9iAS InterConnect“, „The
IBM MQSeries Integrator “ bei „TIBCO ActiveEnterprise“. Buvo pasirinktas
paskutinysis, kadangi jo kainos ir funkcijų santykis buvo optimaliausias,
be to jis užtikrina realaus laiko komunikaciją bei tai, jog atlikus
pakeitimą vienoje sistemoje, jo nebereikia atlikti kitose.
Taigi, matome, kad įmonės informacinė sistema ir Ryšių su klientais sistema
yra viena kitą papildančios sistemos, kurios yra integruojamos
integratoriaus pagalba, ir tokiu būdu garantuoja efektyvesnį viena kitos
darbą bei panaudojimą ir, žinoma, geresnį verso lūkesčių pateisinimą.
Kaip ir kelionių agentūra „Kelrodis“, vis daugiau kompanijų pradeda
integruoti savo sistemas, o kad būtų paprasčiau, dažniausia nusiperka
siūlomus integruotų sistemų paketus, kurių palyginimas pateikiamas 5
Priede. (12, 30, 31, 32, 33)

Išvados

Viską išanalizavus galima padaryti išvadas, kad Ryšių su klientais valdymo
sistemos – tai taikomosios sistemos, kurių pagrindiniai komponentai yra
kompiuterinė sistema (IT platforma), žmonės, procedūros, duomenys bei ryšio
priemonės, ir kurios yra skirtos didinti efektyvumą bei automatizuoti
veiklą, susijusią su klientų aptarnavimu ir ryšiais su jais.

Automatizuotą, nuoseklų ir geresnį vartotojų poreikių, elgesio ir
pelningumo supratimą bei numatymą, teisingos strategijos vartotojų
atžvilgiu pasirinkimą, resursų optimizavimą įgalina gerai pasirinkti
sistemos komponentai, o ypač ryšių su klientais valdymo sistemos
architektūra bei naudojamos technologinės priemonės.

Būtent CRM sistemų architektūra, jos teisingas pasirinkimas, įvertinus
pagal atitinkamus kriterijus, ir apsprendžia kaip gerai sistema galės
patenkinti verslo lūkesčius, kaip lengvai ji bus integruota į jau
egzistuojančias sistemas, o teisingas technologijų pasirinkimas įgalina
greitesnį bei efektyvesnį šių lūkesčių pasiekimą.

Dažniausiai CRM architektūros yra suskirstomos į dvi dideles grupes – tai į
duomenis orientuotos architektūros (DAO) ir į paslaugas orientuotos
architektūros (SAO), iš kurių geriausiai lūkesčius patenkina nauja į
paslaugas orientuotos architektūros atšaka, tai į Tinklines paslaugas
orientuota architektūra.

Tam kad sistema pradėtų teikti naudą, pasirinkus jos architektūrą būtina
sistemą sukurti bei įdiegti. Tai iš tikrųjų yra ilgas ir nuodugnus
procesas, atliekamas tam tikromis stadijomis bei sukuriantis įmonei būtent
jai vienai tinkamą sistemą.

Kitas svarbus aspektas užtikrinant efektyvų sistemos funkcionavimą yra CRM
sistemos integracija su kitomis įmonės sistemomis, kuri užtikrina duomenų
ir procesų mainus geresniam verslo darbų atlikimui. Integracija taip pat
gana ilgas procesas, kuris vykdomas stadijomis bei atliekamas tam tikrais
metodais.

Todėl apibendrinus visą tai, kas pasakyta, galima teigti, kad CRM sistemos
projekto plėtojimas negali būti atliktas per mėnesį ar metus, norint, kad
sistema funkcionuotų efektyviai – tai permanentinis procesas, kuris
reikalauja pastovių teik žmogiškųjų intelektualių resursų, tiek
technologinių priemonių jiems realizuoti. Sistemos introdukcija bei
tolimesnis palaikymas reikalauja sudėtingo planavimo, analizės,
projektavimo bei įdiegimo proceso, o tai reikalauja gana nemažo biudžeto,
todėl daugeliui įmonių tokios sistemos kol kas lieka žydra svajone.

Naudotos literatūros sąrašas

1. Sūdžius V., Sodžiūtė L. „Elektroninė komercija: prielaidos, strukūra

ir procesai“. – Vilnius: Petro Ofsetas. – 2003 m.

2. Krivaitis A. CRM iššūkis: veidu į klientą// NK verslas. – 2001m.

spalis. Nr.2

3. Krivaitis A. CRM keičia rinkodarą – tinkamas pasiūlymas tinkamam

klientui// NK verslas. – 2001m. Nr.3

4. Radcliffe J., Wood B.CRM Architecture and Integration Challenges in

the Real-Time Enterprise. Gartner European Syposium 10-12 March. –

Florencija, 2003 m.

5. Kontrimas V. Saugumo protokolai elektroninės komercijos srityje//

Kompiuterija. – 2001m. Gegužė

6. Kirvaitis A. CRM: prieš startą – ką reikia padaryti, prieš pradedant

ką nors daryti// Vadovo pasaulis. – 2002 m. Nr. 1.

7. Buttle F. The CRM Value Chain.//straipsnis. Macquarie University. –

Sydney. 2000 m. Balandis

8. Enterprise Series CRM Architecture. – Haverhill MA. January 2001

9. CRM – panacėja ar dar vienas burbulas?. Žiūrėta: 2003.05.01. Prieiga

per internetą: http://www.ebiz.lt/article.php3/22/2478/4

10. Krivaitis A. CRM – langas į milijono klientų protus. Žiūrėta:

2003.02.01. Prieiga per internetą:

http://www.ebiz.lt/article.php3/22/2227/1

11. Rytel T. Praktiniai patarimai diegiantiems CRM. Žiūrėta: 2003.04.30.

Prieiga per internetą: http: //www.ebiz.lt/article.php3/22/2768/6

12. HP technical white paper. Žiūrėta: 2003.04.30. Prieiga per internetą:

http://www.hp.com/solutions1/oracle/downloads/CRM_arch_tech_wp.pdf

13. Customer Relationship Management and Data Mining. Žiūrėta: 2003.03.20.

Prieiga per internetą: http://www.salford-

systems.com/crm.html?source=goto

14. Sankaran V. The Anatomy of a CRM Architecture. Žiūrėta: 2003.03.15.

Prieiga per

internetą:!http://www.gantthead.com/article/1,1380,27606,00.html

15. Rytel T.Ar programinė įranga jau ir yra CRM sprendimai? Žiūrėta:

2003.03.15. Prieiga per internetą:

http://www.ebiz.lt/article.php3/22/4854/4

16. Value Chain white paper. Žiūrėta 2002.04.25. Prieiga per internetą :

http://www.crmaudit.com/crm_value_chain.asp

17. Michel I. Kramer. Comparing CRM architectures. Žiūrėta: 2003.05.01.

Prieiga per internetą:

http://www.epiphany.com/e/seybold/downloads/Comparing_CRM_Architecture.pdf

18. Seybold B. P. Why IT Architecture Is Important in the Selection of a

CRM Solution. Žiūrėta: 2003.05.01. Prieiga per internetą:

http://www.psgroup.com/services/forewords/CRMARCH10-02foreword.html

19. Kevin Reichard. Application Servers and Linux: The Enterprise Awaits

A Quick Application-Server Review. 2002 05 18. Prieiga per internetą:

http://www.linuxplanet.com/linuxplanet/reports/1146/2/

20. CRM Implementation – The Steps for Success. Žiūrėta: 2003.05.01.

Prieiga per internetą:

http://siebel.ittoolbox.com/groups/groups.asp?v=CRM-SELECT

21. Metodologija. Žiūrėta: 2003.04.29. Prieiga per internetą:

http://www.navision.com/lt/view.asp?documentid=388,3

22. Hagerman D. CRM integration with existing systems. Žiūrėta 2003.04.27.

Preiga per internetą: http://www.hagerman.com/newsletters/ebul6-

CRM.htm

23. Clarity Integration White Paper, Summer 2001. Integration Framework.

Žiūrėta 2003.04.27. Preiga per internetą: http://www.clarity-

integration.com/d-man/download.phps

24. Types of CRM. Žiūrėta 2003.04.28. Preiga per internetą:

projects.bus.lsu.edu/independent_study/ vdhing1/crm/

25. Dash L. CRM evolution. Žiūrėta: 2003.05.01. Prieiga per internetą:

http://siebel.ittoolbox.com/groups/groups.asp?v=CRM-SELECT

26. Khanna S. Integrating CRM applications with enerprise. Žiūrėta

2003.04.28. Prieiga per internetą:

http://siebel.ittoolbox.com/groups/groups.asp?v=CRM

27. Product profile. Žiūrėta 2003.05.05. Prieiga per internetą:

http://www.homercomputer.com.au/homer_software_guide/PP/vantage_pp1.htm

28. Microsoft Navision Axaptaimplementation guide. Žiūrėta 2003.05.05.

Prieiga per internetą:

http://technet.navision.com/usered/Axapta%203.0/IG/ImplementationGuide.

htm

29. Sentai Trax review. Žiūrėta 2003.05.05. Prieiga per internetą:

http://www.2020software.com/products/Sentai_Trax.asp

30. Guide to implementing CRM in local government. Approach & methodology.

Žiūrėta 2003.05.14. Prieiga per internetą:

http://www.lgolpathfinder.gov.uk/en/images/CRM%20Guide%20Approach%20&%2

0Methodology%20v1.1_303.pdf

31. Ohioedge.Product specification. Žiūrėta 2003.05.14. Prieiga per

internetą:

http://www.ohioedge.com/kb/oesales/docs/product_specification.pdf

32. MQSeries Integrator agent for CICS – product overview. Žiūrėta

2003.05.14. Prieiga per internetą: http://www-

3.ibm.com/software/htp/cics/mqiac

33. TIBCO product overview. Žiūrėta 2003.05.14. Prieiga per internetą:

http://www1.tibco.com/products/enterprise.html

PRIEDAI

1 Priedas. Principais paremta vertės grandinė arba CRM-VC( tai modelis,
kuriuo sekama kuriant bei diegiant CRM sistemas.Tam, kad būtų sukurta CRM
sistema viskas – technologija, duomenys bei uždaviniai (ang. Data and
Applications), paslaugos ir žmonės turi būti apjungtii visuose įmonės
lygmenyse). (7, 12)

v

2 Priedas. N-lygių (ang. N-tier) tinklinė architektūra sudaryta iš kliento
lygmens, pristatymo lygmens (ang. Presentation Tier), Taikymų lygmens (ang.
Application Tier) bei Duomenų lygmens (ang. Data Tier) (16)

2 Priedas. N-lygių (ang. N-tier) tinklinė architektūra sudaryta iš kliento
lygmens, pristatymo lygmens (ang. Presentation Tier), Taikymų lygmens (ang.
Application Tier) bei Duomenų lygmens (ang. Data Tier) (8)

4 Priedas. Skambučių centro veikimas kelionių agentūroje “Kelrodis”

|Produkto |Moduliai |Technologij|Pranašumai |
|pavadinimas | |a | |
|„Microsoft |Inventory and Order |Parašyta |Geriausias įmanomas |
|Great Plains |Processing, Project |naudojant |integruotas |
|Enterprise“ |Management, Microsoft|C++, HTML, |produktas, tačiau ir|
| |CRM, E-Commerce, |XML, |pats brangiausias. |
|Gamintojas:“Mi|Human Resource |„Visual |Jis įgalina |
|crosoft |Management, |Basic“, |informacijos mainus |
|Business |Customization & |„Dexterity“|visse organizacijos |
|Solutions“ |Integration Series, |. MS-SQL |dalyse, apjungia |
|Kaina: |Manufacturing Series,|Server yra |„back-end“ ir |
|$50,000 – |Field Service |„back-end“ |„Front-end“ ofisus |
|$250,000 ir |Management, Financial|ofiso |bei e-verslo |
|daugiau |Management, |RDBMS. |sprendimus. |
| |Enterprise Reporting,| | |
| |Analytics and | | |
| |Reporting | | |
|„Vantage by |Turto valdymo, |Parašyta C,|Didžiausio vidutinei|
|Epicor“ |Apskaitos, sąskaitų |C++ ir |rinkai skirtų |
| |tvarkymo, Užsakymų |„Visual |produktų gamintojas |
|Gamintojas: |valdymo, Pikimų |Basic“. |suteikia įmonei |
|„Epicor |valdymo, MRP, CRM, |Naudoja |pilnai interneto |
|Software |„StoreFront“, Valiutų|Microsoft |galimybėmis paremtą |
|Corporation“ |kursų valdymo, |SQL RDBMS. |integruotą įmonės |
|Kaina: |Produkto |Naudoja „ |sistemą. |
|$12,000 – |konfiguravimo, FRx, |Microsoft |Pagrindinis |
|$500,000 ir |Dokumentų valdymo, |Windows“ |privalumas lyginant |
|daugiau |Kokybės užtikrinimo, |aplinką,“ |su kitais |
| |Kalendoriaus, |Progress |produktais: galimybė|
| |Personalo valdymo, |data |palaikyti IS ypač |
| |EDI, APS, BI, Klientų|server“ bei|žemais kaštais, taip|
| |ePortalas, e- |„SQL „ |pat l.papras tas |
| |Aprūpinimo, Medžiagų |serverį. |vartojimas, greitas |
| |valdymo, | |įdiegimas, |
| |E-komercijos, | |nereikalingas ilgas |
| |„E-Intelligence“ bei | |vartotojų apmokymas |
| |e-industrijos | |bei lengvas |
| |moduliai | |modifikavimas. |
| | | |Pagrindinis |
| | | |trūkumas, kaip ir |
| | | |„Microsoft Great |
| | | |Plains Enterprise“ –|
| | | |aukšta kaina. |
|„Microsoft |Finansų valdymo, CRM,|Naudoja |Unikalus dizainas – |
|Navision |„Enterprise Portal“, |„Microsoft |viena DB, viena |
|Axapta“ |Distribucijos, |Windows“ |įrankių juosta, |
| |Tiekimo grandinės |aplinką bei|viena programinė |
|Gamintojas: |valdymo, Projektų |ASP |logika ir šaltinio |
|“Microsoft |valdymo, Gamybos, |interfeisą.|kodas – visa tai |
|Navision“ |Žmogiškųjų išteklių |Duomenys |išskiria šį produktą|
|Kaina: |valdymo, Verslo |saugomi |iš kitų. Šie |
|$100,000 – |analizės bei žinių |„MS SQL“ ir|privalumai |
|$300,000 |analizės moduliai. |„Oracle |garantuoja lengvą |
| | |DBMS“ |personalizaciją, |
| | |sistemose |atnaujinimą bei |
| | | |žemus aptarnavimo |
| | | |kaštus. Dar vienas |
| | | |privalumas – MSDE |
| | | |(“Microsoft data |
| | | |engine”) duodamas |
| | | |nemokamai. |
| | CRM, „Enterprise |Sistema |Privalumai: |
|„Made2Manage“ |Portal“ (M2M VIP), |sukurta |palyginti neaukšta |
| |Įmonės resursų |naudojant |kaina, produkto |
|Gamintojas: |planavimo (ERP), |„Microsoft |platforma yra |
|„Made2Manage |Įmonės integracijos, |Visual |lengviausia plečiama|
|Systems“ |tiekimo grandinės |Studio“ |bei turi atvirą |
|Kaina: |valdymo, bei verslo |plėtros |architektūrą |
|$24,000 – |logikos (Business |kalbas, bei|.Pagrindinis |
|$100,000 ir |Intelligence) |„Microsoft.|skirtumas, |
|daugiau |moduliai. |NET „ |išskiriantis šį |
| | |platformą, |produktą iš kitų – |
| | |„Microsoft |„Made2Manage“ |
| | |SQL Server |neprilygstamą niekam|
| | |2000“, o |kitam paslaugą – per|
| | |tai įgalina|M2MExpert.com |
| | |pilną visos|tinklapį įmonės |
| | |organizacij|klientai gali |
| | |os |nuotolinių būdu |
| | |integraciją|mokytis M2M |
| | |. |Universitete“ bei |
| | | |naudotis kitomis |
| | | |vertę didinančiomis |
| | | |paslaugomis. |
| „Sentai |Apskaitos, sąskaitų |Naudoja |Tai pats |
|Trax“ |valdymo, Turto |„Microsoft |lanksčiausias iš čia|
| |valdymo, Pirkimų |Windows“ |analizuojamų |
|Gamintojas: |užsakymų, Pardavimų |aplinką |produktų, kurį būtų |
|„Sentai Trax“ |orderių, |priėjimui |galima pavadinti |
|Kaina: |e-verslo,serviso |prie DB, |„chamelionu“, |
|$10,000 – |darbuotojų apskaitos,|serveriai: |sistema būtent taip |
|$80,000 |Pardavimų RMA, |Windows NT,|paprastai prisitaiko|
| |Komisinių valdymo, |UNIX. |adaptuojasi prie |
| |turto vertinimo, | |kintančios aplinkos.|
| |Duomenų saugyklos, | |Tai įmanoma dėka |
| |„Captains Bridge“ bei| |ypač gilaus |
| |EDI moduliai | |funkcionalumo bei |
| | | |lankstaus |
| | | |interfeiso. Dar |
| | | |vienas privalumas – |
| | | |žemiausia iš čia |
| | | |lyginamų kainų. |
| | | |Pagrindinis |
| | | |trūkumas: kol kas |
| | | |dar naujas mažai |
| | | |žinomas gamintojas, |
| | | |neturintis daug |
| | | |reklamos. |

5 Priedas. Geriausių rinkoje siūlomų integruotų sisteminių paketų
palyginimas (28, 29, 30)

———————–

informacijos tiekėjų paslaugomis, leidžiančiomis vadovybei priimti
strateginius sprendimus. (1) analitio ryšių su klientais valdymo sistema
pateikta 1 pav.:

4 pav. Diegimo fazės

3 Priedas. Sistemų Integracijos stadijos (23)

1 pav. Analitinio ryšių su klientais valdymo sistema (34)

„Web“ duomenys

Skambučių

centro duomenys

El.pašto
duomenys

Atsakymų
duomenys

Apsilankymų

duomenys

• Palaikymas

• „Click-thru“ technologija

• Pirkimai

• Pirmenybės

• Palaikymas

• Pirkimai

• Pirmenybės

• Info. Pareikalavimas

• Pirkimai

• Paskatinimai

• „Click stream“

• On-line prekyvietė

• Pirkimai

• Pirmenybės

Personalizacijos
įrankiai

Skambučių centro programinė įr.

„In-store“
Duomenų bazė

Tiesioginio pašto personalizacijos programos

El.pašto valdymo programinė įr.

Internetas

Skambučių

centras

El.paštas

Paprastas

paštas

Žmogaus

kontaktas

Personalizacija, Individualizuotas aptarnavimas, Personalinės
rekomendacijos, Specialiai parengti pasiūlymai

Taisyklių įrenginys (ang.Rules Engine)

Klientų profilių
Duomenų bazė

Klientų duomenų
saugykla (ang. Warehouse)

Kanalai

Reikalavimų
Analizė

Pesonalizacija

ir

Prototipavimas

Priežiūra po
įdiegimo

Dislokavimas

Nuodugni analizė,

diegimo plano ir

biudžeto

tvirtinimas

Sistemos projektavimas,
programavimas ir testavimas

Vartot. apmokymas,

duomenų

konvertavimas,

sistemos paleidimas

Tolimesnė priežiūra

HTML arba
kliento plėtinys

Pvz. MS IIS 5.0

Duomenys

DB

HTML

Duomenų lygmuo

Pristatymo lygmuo

Taikymų lygmuo

Klientas

Uždavinių serveris

(J2EE)

Tinklo serveris

Kliento naršyklė

Komponentai

DARBAI

FAZĖ

Tolimesnė priežiūra, atsiradusių nesklandumų

šalinimas, paildomų f-jų diegimas

Pagrindinių reikalavimų (lankstumo, plėtros, suderinamumo ir t.t.)
tenkinimo patikrinimas

Sistemų apjungimas, reikalingos įrangos instaliavimas ir sistemos
paleidimas

Fizinių reikalavimų bei sistemų sąveikos aprašymas

Inerakcijų ir procesų srautų, reikalingų verslo bei techniniams tikslams
pasiekti, aprašymas

Svarbiausių funkcijų bei paslaugų
reikalingų integracijai nustatymas

Tolimesnis aptarnavimas

Testavimas

Itegruotos sistemos paleidimas

Fizinis projektavimas

Loginės architektūros projektavimas

Struktūros apibrėžimas

Anksčiau įdiegti pritaikymai (ang. Legacy applications)

Duomenų komponentai

Integracijos komponentai

Aptarnavimokomponentai

Ryšių su klientais valdymo sistema

Klientas

Susidorojimo su
Užklausa
komponentai

Verslo logikos

komponentai

HTML puslapis

HTML puslapis

Peradresuotojas

Vertimo įrenginys

Tinklo serveris

HTML puslapis

HTML puslapis

HTML puslapis

Tinklo naršyklė

HTML puslapis

Uždavinių serveris

Privilegijuotos ir
Nepriviligijuotos
Paslaugos

Duomenys

(DB)

6 pav. Integruota įmonės informacinė sistema

Nagrinėjamu atveju integruota įmonės informacinė sistema atrodytų taip:

ypač gerai tenkina kelionių agentūros poreikius. Kad procesus būtų lengviau
suprasti, pasitelktas 5 paveikslas:

1 thought on “CRM sistemos”

  1. Galimos problemos dėl integracijos – tai kitų sistemų grėsme pasenti. Todėl čia jau kaštai tik augs 🙂

    Reply

Leave a Comment