CRM sistemos - Mokslai.lt

Turinys

Įžanga
1. Bendras Ryšių su klientais valdymo sistemų supratimas
1.1 CRM sistemos – kas tai?
1.2 Operacinio ir analitinio CRM sistemos
1.3 CRM sistemų šeima
1.3 Ryšių su klientais valdymo sistemų taikymai
2. Ryšių su klientais valdymo sistemų architektūra
2.1 Architektūros vertinimo kriterijai
2.2 CRM architektūros struktūra
2.3 Architektūrų tipai
2.4 Architektūros realizavimo technologinės priemonės
2.5 Esamų produktų architektūrų palyginimas
3. Ryšių su klientais valdymo sistemos kūrimas
3.1 Saugios aplinkos sukūrimas
3.2 Realizavimo proceso valdymas
3.2.1 Pirma stadija – reikalavimų analizė
3.2.2 Antra stadija – Personalizacija ir Prototipavimas
3.2.3 Trečia stadija – Dislokavimas
3.2.4 Ketvirta stadija – patirinimas po įdiegimo
4. CRM ir esamų informacinių sistemų integracija
4.1 Integracijos reikalavimai
4.2 Integracijos metodai
4.2.1 Failų integracijos metodas
4.2.2 Programavimo metodas
4.2.3 Tarpinės Programinės įrangos metodas
4.3 Integruotos sistemos pavyzdys
4.3.1 Ryšių su klientais valdymo sistemos pavyzdys
4.3.2 CRM sistema informacinėje sistemoje
Išvados
Naudotos literatūros sąrašas
Priedai

Įž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ų 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 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 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 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ų 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 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

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)

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

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

| | |os |nuotolinių būdu |

| | |. |Universitete“ bei |

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

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

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:

Įžanga

Integruotos sistemos pavyzdys

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

1.1 CRM sistemos – kas tai?

1.2 Operacinio ir analitinio CRM sistemos

1.3 CRM sistemų šeima

1.3 Ryšių su klientais valdymo sistemų taikymai

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

Architektūrų tipai

2.1 Architektūros vertinimo kriterijai

2.4 Architektūros realizavimo technologinės priemonės

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

3.1 Saugios aplinkos sukūrimas

3.2 Realizavimo proceso valdymas

3.2.1 Pirma stadija – reikalavimų analizė

3.2.2 Antra stadija – Personalizacija ir Prototipavimas

3.2.3 Trečia stadija – Dislokavimas

3.2.4 Ketvirta stadija – patirinimas po įdiegimo

4. CRM ir esamų informacinių sistemų integracija

4.1 Integracijos reikalavimai

4.2 Integracijos metodai

Programavimo metodas

Tarpinės Programinės įrangos metodas

4.2.1 Failų integracijos metodas

4.3.1 Ryšių su klientais valdymo sistemos pavyzdys

4.3.2 CRM sistema informacinėje sistemoje

Išvados

Naudotos literatūros sąrašas

Priedai

Panašūs darbai

ERP sistemos

Informatikos špera egzaminui

Linux šeimos OS priežiūra

Dazniausiai sutinkamos klaidos svetainiu kurime

Ekonominė Informatika – egzaminas

ĮMONĖS INFORMACINIŲ IŠTEKLIŲ SAMPRATA