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 SSaugios 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ų informacinių 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 žmonė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 yra 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ų aarba 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 apie 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 struktū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 vvaldymo 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 klientų 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ų ddiegimo 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 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 iir 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 ssavo 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 kkitą 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 ppasiruošę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 ddė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?

• KKokia 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 IIT 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 vveikmui.

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 aarchitektū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ų vvykdymas 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 – ttai 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

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 bbesinaudotų. 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 ddiegimą. 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);

• DDislokavimas (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 vvaldymo 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 ggauti 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:

• SSistemos 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 bbei 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ų iintegracijos 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ą – iinternetą.

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 sserver) 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 iir 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 vvisus 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“ – ttiesiogiai 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ą, nnaudojama 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 sstadijomis 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 ppadaryti, 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. KKhanna 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)

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”

|pavadinimas | |a | |

| |e-industrijos | |bei

lengvas |

| | |2000“, o |kitam paslaugą – per|

| | |os |nuotolinių būdu |

| | |. |Universitete“ bei |

5 Priedas. Geriausių rinkoje siūlomų integruotų sisteminių ppaketų

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

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

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 aarchitektū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

Peradresuotojas

Vertimo įrenginys

Tinklo serveris

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: